Chapter 3 shows that currently no general approach exists to bridge the gap between archi-tecture implementation and archiarchi-tecture specification languages, that fulfills the requirements stated in Section 1.6. This chapter gives an overview of the solution proposed in this thesis to fill this gap. Using the proposed approach, architecture model information is integrated with program code. The code will contain sophisticated structures, which represent architecture meta model and model elements, and their properties, while respecting the requirements, that architecture implementation languages have towards the program code.
Implementation Model
Program Code
Architecture Model Transformations
Specification Model Model
Integration Concept
Is Translated To Model Layer
Code Layer
Translation Model (IAL)
Figure 4.1: The parts of the proposed solution (underlined), the elements, and their interrela-tionships
Figure 4.1 gives an overview of the view types, that are subject to translation in the proposed solution, and their interrelationships. The figure will be subsequently described in the following chapters. The view types that are subject to translation are the following:
Program Code: the implementation of a software following the standards of an architecture implementation language
Implementation Model: an abstract model view upon the program code, that complies to an architecture implementation language
Translation Model: an intermediate model view for translating between an implementation model and a specification model
Specification Model: a specification of architectural concerns using an architecture specification language
4 Proposed Solution
Four research areas are part of the proposed solution:
1. A Model Integration Concept is used to integrate models and meta models with program code. It is used to create well-defined translations between program code structures, model elements, and meta model elements.
2. The proposed solution uses the translation model during the translation between archi-tecture implementation and archiarchi-tecture specification models, for reducing the number of required translation definitions. The Intermediate Architecture Description Lan-guage (IAL) is defined to express translation models.
3. Architecture Model Transformations are used for the translation between models of different languages, and for transformations within models of IAL.
4. The Explicitly Integrated Architecture Process describes how these areas are used to achieve the objective.
For all these research areas, concepts and implementations are developed in this thesis. In the following sections, these research areas are briefly described to give an overview of the approach. The research areas are then described in detail in the following chapters. The idea of the presented approach is to ensure the consistency between the architecture views at development time. The consistency with the run time has to be subject to an execution runtime environment, and is not in the focus of this thesis.
4.1 Model Integration Concept
The Model Integration Concept describes how model information1 is integrated with program code. In Figure 4.1 the concept provides vertical integration. It is used to integrate and extract architecture model information from an implementation model and the translation model with/from program code (see [KG12]). For doing so, within the Model Integration Concept it is defined how information of meta models and models thereof can be notated with program code structures. The code is statically analyzed for program code structures that identify implementation model elements, or adapted respectively when the model is changed.
It therefore derives a new view with bidirectional mappings. The Model Integration Concept is described in detail in Chapter 5.
4.2 Intermediate Architecture Description Language
The Intermediate Architecture Description Language (IAL) is a translation model language.
It is used to represent architecture information independently from the specification language that is used to describe the architecture and from the implementation model that is used to implement the architecture. It has the role to increase the interoperability of the proposed solution with different specification and implementation models, and to increase the evolvability of the approach. Chapter 6 describes the Intermediate Architecture Description Language.
Specification and implementation languages have different kinds of information that they are able to describe. E.g. in contrast to specification languages, implementation languages often
1Models in the term of this approach are always based on meta models. Other models, such as mathematical functions etc. are not meant here.
4.3 Architecture Model Transformations cannot describe a deep component hierarchy. The IAL handles these differences using a profile concept similar to UML profiles [Obj15, Chapter 12.3]. The IAL is described in detail in Chapter 6.
4.3 Architecture Model Transformations
In Figure 4.1 the architecture model transformations provide the horizontal integration. Two kinds of transformations are used within the proposed solution: First, specification models are synchronized with implementation models via a translation model. Second, translation models may have to be transformed to match the different kinds of information required by the targeted specification or implementation model language. Both kinds of transformations are described in Chapter 7.
4.4 Explicitly Integrated Architecture Process
The three parts above build the conceptual foundation for a process for automatically inte-grating architecture model information with program code and extracting this information.
Figure 4.2 shows a simple example of the Explicitly Integrated Architecture Process in action.
In this example an EJB Session Bean CashDesk is added to an existing bean BarcodeScanner.
The CashDesk is declared to be the parent of the BarcodeScanner.
(1) shows the program code for the bean BarcodeScanner.
(2) The implementation model is built by scanning the program code for well-defined struc-tures based on the Model Integration Concept. In this example a type declaration with an attached annotation Stateless is identified. The name of the declared type is identified as the name of the bean.
(3) The implementation model is translated into a translation model, an instance of the IAL.
(4) The translation model is translated to a specification model. The specification model in the example is represented using a UML component diagram. In an evolutionary step, a parent component named CashDesk is added.
The changes are propagated to the code as follows:
At (5) the architecture specification model is translated into the translation model. A new ComponentType with the name CashDesk is created, with a stereotype that allows to add children to a component type.
(6) The translation model is translated into an implementation model. In this model the hierarchy cannot be represented, because the EJB specification does not define component hierarchies.
At (7) the program code is adapted corresponding to the changes in the implementation model. I.e. the type CashDesk is created.
(8) The architecture information that has no representation in the implementation model is translated into the code using the Model Integration Concept. In this example, the hierarchy is translated as a field in the Java type declaration BarcodeScanner with the annotation EJB.
This is an annotation of the EJB framework, that specifies that an instance of the bean BarcodeScanner has to be injected. Additionally this field has the annotation ChildTypes, which marks the reference an instance of the childTypes reference. To remove the hierarchy the code could be translated to a model using the process. As an alternative, the respective code element could be removed.
4 Proposed Solution
It should be noted that the hierarchy could also have been created in the terms of the approach by simply adapting the code accordingly, because the models can be derived automatically. The Explicitly Integrated Architecture Process is described in detail in Chapter 8.
(2) (3)
(4) (5)
(6)
(7) (8)
Program Code
Implementation Model Translation Model Specification Model
Translation of Commonalities Translation of Differences
(1)
Model Evolution Step
@Stateless
public class BarcodeScanner { ... }
@Stateless
public class BarcodeScanner { ... }
@Stateless
public class CashDesk { @EJB
@ChildTypes
BarcodeScanner barcodeScanner;
}
Figure 4.2: An Example of the Explicitly Integrated Architecture Process
This chapter gave an overview of the proposed solution and sketched the parts of the solution and their interconnection. In the following chapters, these parts are described in detail.