Software development processes involve a variety of tools. The number of these tools can be very small, but also scale up to several dozens. Ideally, all these tools should understand one language thus communicating to each other via a unified file format or database. In reality, different tools handle different input formats. For example, word processors or spreadsheet calculators that are used to collect requirements store data that is also collected in issue tracking systems. But, both use completely different means to store data (e.g., files vs. databases). To integrate such tools one must map the corresponding formats to each other, thereby replicating the description of the software.
• Performance limitations
The structure and layout of a system specification can be different depending on its purpose. High level specifications are used for analysis and verification, while low or medium level descriptions can be executed or optimized. Depending on the complexity of the specific task and the overall system specification, representations may need to be condensed or extracted to ease performing a particular develop- ment step. For example, a call graph analyzer extracts the control flow from a program and stores it in a call graph before running the actual analysis. Again, in- formation is duplicated. This practice is intended and reasonable, but also implies an increased amount of redundancy.
• Comprehensibility boundaries
Software artifacts can grow large and may therefore be difficult to understand or process. Extracting specific (smaller) parts from a (huge) artifact is a well known technique to conquer complexity. Creating such views on artifacts introduces re- dundancy because facts are replicated from the original artifact. This is similar to the previous item, but the client that demands a partial view on the system specification is the developer, instead of a particular tool.
Besides these very general reasons for the introduction of redundancies, there are more specific causes which are particularly related to MDSD. We will elaborate on these in the next section.
3.2 Redundancy in MDSD
3.2.1 Duplication in Iterative Multistage Software Development
For decades the majority of research in software engineering was focused on forward engineering. Development processes were specialized to quickly implement systems, of- ten without considering the tremendous costs of maintaining and evolving these systems in the future. Today we are faced with a multitude of existing systems which are not
3 Problem Analysis
only subject to maintenance, but also need to be extended. Thus, the existing im- plementations often need to be reverse engineered [130]. In parallel, new development methodologies (e.g., MDSD and Model-Driven Architecture (MDA) [131]) have emerged, which do explicitly connect artifacts that are created in different stages of software de- velopment. Both the ignorance of the importance of Reverse Engineering and the new multistage paradigms heavily increase the need for synchronizing software artifacts. This section will shed more light on the implications induced by this change of mind.
MDSD puts emphasis on chains of models. One starts with abstract descriptions of a system and performs refinements yielding more concrete models and finally executable code. This procedure exposes similarities to the linear nature that can be observed in early development process models. Similar to the processes, the steps (i.e., the creation and refinement of models) are considered to be executed sequentially—one after another. However, this is not feasible for the same reasons processes were redesigned to support iterating in cycles and returning to previous steps as needed. The closer a system gets to its concrete implementation, the more likely design faults are detected. Once a new system is actually used by people (or test personnel), change requests are filed and parts of the design and the implementation may need to be modified.
In both cases (i.e., returning to an earlier development stage and going back to change a more abstract model) the effort spent previously should not be lost. A system’s implementation should not be completely redone when the design is changed partially. Refinements made to models must be kept even if more abstract models are modified. In other words, the artifacts created in all stages of a development process need to be synchronized. When running a linear process, the synchronization issue does not arise, because people can stop caring about artifacts created earlier. But, if these early artifacts (e.g., abstract models) are used for any other purpose, they must be in sync with any derived and potentially changed documents.
For example, if the UML model of a system is used to generate the implementation for a new platform, it must be synchronized with the code that is actually running on existing platforms. On the contrary, if the UML model is not used at all after code generation, synchronization is not needed.
To summarize, one can ascertain that the historical forward orientation of software de- velopment methodologies yielded linear sequences of artifacts. Once a subsequent stage of development was reached, the documents of the previous one were obsolete. Duplica- tion of data was not problematic and synchronization among artifacts was therefore not a main concern. However, the shift toward iterative, cyclic and multistage development changes this. Now, artifacts of all development stages are kept and duplication needs to be dealt with. Artifacts must be kept in sync across development stages and abstraction levels. Redundancy cannot be resolved by discarding artifacts anymore. What has been ignored or at best handled manually in the past grows to a new magnitude within the context of evolving systems, iterative processes and MDSD.
3.2 Redundancy in MDSD
3.2.2 Absence of Concern Separation in Metamodeling
In [132] the term Separation of Concerns was first mentioned. Edsger W. Dijkstra wrote this essay to emphasize the importance of studying different aspects of complex problems in isolation rather than looking at all of them at once. If one mixes various issues, the result will be confusion rather than gaining valuable insights about the matter of subject. Creating software systems is a complex problem. Thus, separating concerns while designing and implementing such systems is good advice. However, for different reasons this advice is often not taken seriously (e.g., by mistake) or cannot be followed easily (e.g., because of present technical restrictions). Sometimes, developers may basically not be aware of the fact that they are mixing up concerns. They might try to get things done quickly without worrying about the consequences. At other occasions, they might be well aware of the fact that they are mixing concerns, but technical constraints force them to do so. For example, in the absence of an aspect-oriented language a cross-cutting concern may yield duplicated information in a system description.
If one does violate the Separation of Concerns principle—for one reason or the other— redundancy arises. If artifacts that contribute to the specification or implementation of a software system address the same concern, facts are duplicated and changing one artifact causes the need to change another. If, on the contrary, every artifact targets exactly one concern, which is not targeted by another, system information is much more isolated and less duplication can be observed. There are less dependencies across artifacts if they address separate concerns and consequently there is less redundant data.
Paradoxically, in the context of MDSD separating concerns if often not supported by the employed languages and tools. Common object-oriented metamodeling languages (e.g., EMOF) do not provide built-in support for concern separation. Rather, distinct patterns must be used to implement metamodel composition [97]. These patterns allow to create, extend and thereby reuse metamodels, but there is no first-class support for a strict separation of elements that belong to a specific concern. One cannot easily split metamodels into different concerns, establishing a logical grouping of elements. As a consequence, there is no support for merging sets of concerns. Composition of different orthogonal parts of a metamodel similar to the use of hyperspaces [133] is not available in common, widespread languages. This shortcoming has been identified and addressed by recent publications [134].
If systems were fully designed and implemented in terms of separating concerns, devel- opment artifacts would exhibit much less redundancy, fewer dependencies and relations that one must take care of. Or to put it the other way round, the extent to which a system description violates the principle of concern separation accounts for the amount of synchronization needed [135]. While there is good reason to strive for perfect separa- tion when developing software, some mixed concerns—at best only the ones present for technical reasons—will always remain.
3 Problem Analysis