Discussion

when additional functionality is added to the extension, cohesion may increase while coupling is still at a low level.

Software Design Patterns should be selected carefully. If the full spectrum of patterns Pattern Selection

collected in Gamma et al. (1995) is applied, expert knowledge is required to understand the software. The two patterns, Abstract Factory and Observer, can be understood with relative ease, especially compared to other patterns, as, e.g., Visitor. They are the standard solution for many problems and are among the best known and most frequently used patterns in OO languages.

The patterns encourage use of interfaces instead of implementations. The existence of ^Modularity a Java-interface communicates a certain level of design thoughts for a module. The

mental barrier to jump over the hurdle to change an Java-interface seems to be higher than just to change some implementation. With the use of Java-interfaces it is more likely that a new module is added instead of inflating existing modules by not cohe-sive functionality. Thus, the development towards principal software design goals and especially Modularity is encouraged.

The chapter shows how extensibility can be provided up to a certain extent without Limits of Extensibility

changing core components. But the approach is limited. Code applying Abstract Fac-tory and delegation gets hard to understand if several modules are interlaced and used together. The rise of complexity, however, is not a result of the proposed approach.

Rather, the complexity is the outcome of the joint usage of several components with interlacing functionality that is hidden by one or more layers of abstraction.

The Observer pattern lacks the definition of the sequence which Observer implemen-tations are informed about changes of the Subject. This might be seen as drawback, but is actually the quintessence of Observer pattern — encapsulating functionality in modules that can be used independently. Thereby, control flow between the modules is reduced to a minimum. The subject informs its observer in a not defined sequence about changes, i.e., “you don’t want these objects tightly coupled”(Gamma et al., 1995, p. 294). This strong decoupling results in plug-ins that do not depend on each other.

Completely independent plug-ins are advantageous compared to the monolithic struc-ture MATSim had in 2007. This limitation of the approach could be resolved in further steps, e.g., by use of spring.

The transition of the current design to spring’s dependency injection could be real- ^Spring ized with relatively little effort. Mainly, some top-level factories are no longer needed.

Though springs dependency injection must be learned by developers, overall complex-ity is reduced further. Spring provides a standardized definition for plug-ins. In the current state of MATSim each plug-in is configured differently. Spring’s dependency injection mechanism could further improve the plug-in architecture.

Overall, still not all work is done. In comparison to the 2007 release, however, the ^Overall software design of MATSim was improved. MATSim is a living project with growing

user and developer community.

0 5 10 15 20 25 30

01-2010 07-2010 01-2011 07-2011 01-2012 07-2012 01-2013 07-2013

number of changes

[mm-yyyy]

org.matsim org.matsim.signalsystems

(a) Changes per day

0 5 10 15 20 25 30

01-2010 07-2010 01-2011 07-2011 01-2012 07-2012 01-2013 07-2013

number of changes

[mm-yyyy]

org.matsim org.matsim.signalsystems

(b) Changes per day, without some bug-fixes

Figure 4.9.: Changes on package org.matsim and org.matsim.signalsystem 4.8.2. Traffic Signals Extension

MATSim now comes with a traffic signal module containing a default

implementa-Low Coupling

tion for fixed-time traffic signal control. The chapter explains how the module is at-tached to MATSim with the current software design. The architecture of the module follows the same concepts as the core software in order to reduce complexity. The mod-ule requires the mobility simulation of MATSim to implement a single Java-interface (SignalizeableItem). All other communication between the MATSim core and the traf-fic signal module can be realized by use of the different Observer implementations.

Thus, the extension features a high cohesion while coupling is low.

All components of the traffic signal module can be customized, replaced, or extended

Extensibility

without changing the default implementation or core components of MATSim. Due to the use of Java-interfaces, delegation, and Abstract Factory each component can be exchanged separately. The default traffic signal module provides an implementation for fixed-time traffic signal control. For Chapter 5 an extension modeling a responsive signal control is added by solely implementing the algorithm for traffic-responsive control and the code for the assembly of the components. For the represen-tation of real-world infrastructure, compurepresen-tation of amber times, and coupling to MAT-Sim the code of the default implementation is reused and not rewritten from scratch.

Thus, the chosen architecture provides reusable software components and seems to have the required flexibility for extensions.

Maintenance of the implementation was quite cheap during the last years. Fig. 4.9a

Stability & Maintenance

shows in blue the changes recorded by the version control system (subversion) to all core code of MATSim within the packageorg.matsimbetween 2010 and 2012. Changes to the packageorg.matsim.signalsystems, which contains the model specification and the fixed-time control implementation, are shown in red. Whileorg.matsimin total was changed quite frequently, changes toorg.matsim.signalsystemsare rare. This affirms

the low coupling between org.matsim.signalsystems and the rest of org.matsim. The changes to the traffic signal module occurred mainly due to feature improvements and bug fixes by the developer responsible for the extension. E.g., during the period 2010–

2012 a feature for visualization was added to the package, also the intergreen logic was developed. Fig. 4.9b shows same information as Fig. 4.9a, but removes all changes due to these bug fixes and improvements. Red changes nearly disappear, confirming the argument that coupling is low.

Overall, this shows that the chosen approach is modular, reusable, uses few patterns, but is extensible.