Figure 2.4: Different roles and their interaction with languages and artifacts for consistency preservation in the Vitruvius framework, adapted from [54]
produces executable change-driven transformations and registers them at the framework to react to appropriate model changes. The developer uses views to interact with concrete models in the VSUM of a Vitruvius instance. His interactions lead to changes that trigger the execution of the provided transformations. Whenever a change is performed, an instance of a change descriptions metamodel, which defines possible changes in the models, is created to parametrize the transformations. The transformations restore consistency constraints and update instances of a correspondence model, which describes the relations between elements of different models.
2.5 Change-Driven Development
Change-driven software development is a technique that focuses on the execution of program code whenever a specific change of data value occurs. Breu describes this principle in the context of changes in the development process [15]. Nevertheless, the statements can be transferred to the developed software.
In change-driven development, the occurrence of a data modification can trigger different kinds of reaction. In general, a particular piece of code is executed whenever a specific
change happens. This procedure is similar to the observer design pattern [36], which implements a notification mechanism in object-oriented software development. Change-driven development is more abstract than that because it does not specify a concrete realization of the mechanism and is not restricted to object-oriented software design.
Change-driven development can use two different evaluation mechanisms. Push-based systems use notification mechanisms that call other code whenever a change occurs.
Pull-basedsystems check for changes at specified points of time and call the appropriate routines if necessary [7]. Change-driven development techniques usually use a push-based approach.
In object-oriented development, a similar approach called event-driven programming is popular [77]. It is a paradigm that focuses on events and handlers that are called whenever an event occurs. The actual difference to change-driven development is the application context. Event-based programming is often used for graphical user interfaces, where the interaction with the user interface produces events that lead to the execution of handlers.
In that context, event-based systems are mostly pull-based. Except for that, there is no explicit distinction between change-driven and event-driven development. Finally, an event is potentially more generic than a change because it only requires a change of some kind of state, while a change is always also an event.
Reactive programming is another programming paradigm in this context [28]. Its purpose is similar to the event-driven approach but addresses some of its drawbacks.
Reactive programming facilitates the declarative development of event-driven programs, rather than the classical imperative approach [7]. Only data dependencies have to be specified declaratively and the environment decides when and in which order changes have to be propagated. The advantage is that the developer must not explicitly ensure that update routines are called when a change occurs because the propagation is automatically generated from the data dependencies. Furthermore, event-driven programs often use callback mechanisms with limited possibilities of parameter passing, which leads to side-effects performed by the callback routines. These problems are tackled by the reactive programming approach.
Reactive programming may not be mixed up with the term reactive system of the Reactive Manifesto [13]. There, the term reactive focuses on the responsiveness of a system which the user perceives, rather than the control flow of the program execution, on which reactive programming focuses.
The presented concepts can also be applied to the context of model-driven development.
Model modifications define changes that can be used to initiate arbitrary reactions. The reactions can reach from simple value changes to complete code routines and model transformations [10]. Finally, model changes can be used to trigger model transformations, similar to state changes triggering code routines in change-driven software development.
Reactive programming focuses on the declarative description of data dependencies, thus knowledge from this topic can especially be transferred to declarative model transforma-tions.
3 Running Example: Consistency of Software Architecture and
Implementation
In this thesis, we develop the concepts for a change-driven transformation language for restoring model consistency. The concepts are illustrated in example routines for restoring consistency, which are written in an exemplary concrete syntax for the language.
The presented examples, as well as the final evaluation of the work, rely on a case study of consistency between software architecture descriptions and the object-oriented code model that describes their implementation. A software architecture and the implementing code contain elements and features that are represented in both models and have to be kept consistent whenever they are changed. Because the prototypical implementation of the developed language relies on the Eclipse Modeling Framework, the architecture descriptions and the code models are based on the Ecore meta-metamodel.
This chapter first introduces the Palladio Component Model (PCM), which is an archi-tecture description language for software systems, and the Java Model Parser and Printer (JaMoPP), which provides a metamodel for the Java programming language. Afterwards, consistency relations between a PCM model and Java code are defined, which can be restored with change-driven transformation languages such as the one developed in this thesis.
3.1 A Software Architecture Description Metamodel
The Palladio Component Model (PCM) [8, 41] is a DSL for specifying component-based software architectures and their deployment on physical resources. It targets the prediction of certain quality aspects, especially the performance, of a software system before it gets implemented. For this purpose, different extensions are available, which allow the simulation of different design decisions to find a software architecture that fulfills the required quality constraints.
A PCM model of a software system can be used to automatically generate code stubs for the implementation of the system and, furthermore, can be used as a more abstract representation of the software system during its development. This allows to still analyze quality aspects of the system when design decision may need to be changed during the implementation. Consequently, the architecture model and the code have to be kept consistent.
Apart from the advanced capabilities of the PCM for simulating the system behavior, the core metamodel provides an architecture description language (ADL) that can be
Entity NamedElement name : String
Identifier id : String
Repository
Interface
Component DataType
CollectionDataType
PrimitiveDataType type : PrimitiveTypeEnum
CompositeDataType RequiredRole ProvidedRole
«enum»
PrimitiveTypeEnum INT
STRING BOOL repository
components *
repository
interfaces *
repository
dataTypes *
innerType 1
innerTypes requiringEntity *
requiredRoles *
requiredInterface providingEntity
providedRoles *
providedInterface
Figure 3.1: Simplified extract of the PCM metamodel
used to describe the software architecture on a more abstract level than code. The PCM relies on the Eclipse Modeling Framework and specifies its metamodel based on the Ecore meta-metamodel. The complete metamodel is discussed in [83]. For the evaluation of this thesis, we use a real subset of the PCM and map it to Java code. The examples in this these use a simplified version that is not completely conform to the PCM to ease its understanding. That metamodel is shown in Figure 3.1.
The diagram is split into two parts. The upper part shows the realization of theEntity element. This element is implemented by all elements in the lower part, except for the DataTypeandPrimitiveDataType. This implementation relation is not shown in the diagram for reasons of clarity. The implementing elements provide anameand anidattribute.
3.2 A Metamodel for the Java Programming Language