One can see that global consistency and conservation are dual. Changes applied by users require RTE techniques both to reestablish a consistent state and to conserve relevant properties of the involved models. Consistency is a property of the state of models, whereas conservation is a property of the changes applied to models.
2.6 Traceability
The term traceability is defined in [121] as follows:
The degree to which a relationship can be established between two or more products of the development process, especially products having a predeces- sor-successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software compo- nent match.
A trace can therefore be considered as a single link between two related artifacts or elements thereof. In the context of MDSD, traceability has also been defined as the runtime footprint of transformation execution [66].
In general, traceability amounts to the quantity and quality of traces established during the development of a software system. A high degree of traceability is established if the relations among different artifacts are very well known. On the contrary, traceability is only accomplished to a very limited degree, if few relations are known or none of them are known at all. Poorly developed systems do have no documented information about the dependencies between artifacts. For example, the connection between the system’s implementation and the requirements that were recorded upfront is lost.
If requirements do not change during development and after deployment, traceability may not seem an important goal to achieve. Unfortunately, few systems are static in this sense. Most do have changing requirements during development (e.g., because new knowledge about the system’s domain is acquired) and after their initial start of operation (e.g., because the system’s environment does change). Thus, traceability is an important aspect of software development, in particular when changes need to be applied to artifacts and the implications of these changes need to be known.
As traceability is concerned with relations among artifacts, one question is which kinds of relations exist. The corresponding literature reveals that there are various different types of relations. Starting with the very simple and generic trace typetraceTo, one can add more types likedependsOn,modifies,responsibleOf,rationaleOf,validatedBy, verifiedBy andassignedTo [122]. Some authors even propose the usage of much more types of traces [123] or facet-based trace information [124].
The selection of trace types that are needed within a particular development process heavily depends on the application domain, the size of the application, its predicted lifetime and external constraints such as governmental obligations. It does also depend
2 Background
on the kinds of analysis that are performed on software artifacts. If one wants to run a change impact analysis [125], trace links that allow such evaluation (e.g., dependsOn links) are required.
This specificity posed on the trace information is reflected by the variety of metamodels that have been proposed for modeling trace information over the last years [123, 126, 127]. These show that no single model for traceability information will suffice all needs. Rather, configuration and extension mechanisms must be employed to provide flexible and adaptive means to trace relations across artifacts.
Once appropriate trace information is available, a variety of applications can use this information. The well known change impact analysis is only one application for trace- ability [128]. Trace information can also foster the comprehension of systems, enable a coverage analysis (e.g., to compute which requirements are covered by an implementa- tion), help to find unused artifacts (i.e., to conduct an orphan analysis), be employed while debugging transformations and assist model synchronization approaches [66, 129]. The last application area is particularly important in the scope of this thesis.
Trace information can be either acquired automatically or provided manually. For example, trace links can be created automatically while executing model transforma- tions [124]. If artifacts are derived manually (e.g., when creating use case diagrams ac- cording to a requirements document), traces must be established by hand. Even though the second option is tedious, it can be inevitable for some applications.
In the scope of this thesis, trace links are used to capture the relations between derived (i.e., obtained by a transformation) and copied (i.e., obtained by a composition) artifacts. We will see that these kinds of trace links can store the relation between redundant pieces of data and how it can be used for synchronization purposes. In particular the RTE approach that is based on backpropagation and presented in Chap. 6 heavily relies on trace information.
3
Problem Analysis
The need to synchronize software artifacts to enable the integrated usage of multiple heterogeneous tools has been present since the early days of software engineering. The term RTE, which encloses this problem area, has been identified as a key enabler for MDSD [120]. Consequently, various approaches have been proposed to provide solutions for model synchronization or model-based tool integration (cf. Chap. 10). While many approaches target specific RTE applications and most of them provide a reasonable solution w.r.t. their objectives, the overall support for RTE is still in its infancy.
To determine the reasons for this discrepancy between the large number of approaches targeting RTE and the limited availability of generic solutions, a more extensive analysis of the problem is needed. As it will turn out over the course of this chapter, there is multiple, orthogonal aspects of the problem as a whole. Each section in this chapter will elaborate on one of these aspects.
We will start with a general analysis of the reasons that cause redundancy in software development. These are shown as part of Fig. 3.1 and will be examined in Sect. 3.1. A particular set of reasons is inherently connected to MDSD, which is why we will conduct a separate, more close inspection of these in Sect. 3.2.
In general, there are two possibilities to address problems that are implied by redun- dancy found in software artifacts. First, one can try to avoid redundancy. Second, one can employ synchronization techniques to deal with unavoidable redundancy. Both approaches are complementary and they expose their own sets of problems. These are analyzed in the next sections. Section 3.3 particularly presents the blocking factors when trying to avoid redundancy during software development. In Sect. 3.4 we discuss problems that are related to the synchronization of artifacts.
3 Problem Analysis Technology related Complexity related MDSD related Iterative Multistage Development Missing Separation of Concerns for Metamodels
Different Technical Spaces
Performance Comprehensibility Redundancy
Figure 3.1: Causes for introducing redundancy.
After analyzing problems of RTE in detail, we will draw conclusions in Sect. 3.5 and identify the most relevant parts that must be addressed to obtain more generic solutions to RTE. Thus, the analysis performed in this chapter is the basis for our conceptual framework in Chap. 4 and the concrete approaches to RTE proposed in Chap. 6, 7 and 8. Chapter 5 builds the foundation required to apply these and other approaches to RTE in different technical environments. Thus, it does not present a particular solution approach to RTE, but rather enables more widespread applicability or RTE technology.
3.1 General Causes for Redundancy in Software Development
In this section, we will briefly present some general causes for redundancy in software artifacts that are not particularly bound to MDSD, but can potentially be observed in any development process. The following is a (incomplete) list of scenarios where duplicate information is introduced for different reasons.
• Limitations of single tools
A very simple but common reason for the introduction of redundancies are tech- nical limitations of tools. For example, a programming language without support for aspect-orientation can enforce developers to duplicate and scatter code. Con- sequently, multiple instances of one and the same fact exists. Since the choice of tools is often restricted by external parameters, the resulting redundancies can hardly be avoided.