3.3 Relations between Software Architecture Descriptions and Code Models
As stated in the beginning of this chapter, a software architecture description and the implementing program code are artifacts of a software system that contain overlapping information. This information has to be kept consistent. A concrete consistency concept is first explained in section 4.1. Nevertheless, in this section we give an informal introduction to the relations between elements of an architecture description and the implementing Java code, which represent overlapping information and have to be kept consistent.
No natural mapping of architecture descriptions to program code of a software system exists. The mapping of elements from one of the models to the other has to be prescribed, which can be realized in different ways. For example, components can be either mapped to Java packages or to Eclipse plugins. Some of them are explained by Langhammer and Krogmann [60].
An extract of the initial mappings proposed by Langhammer and Krogmann, which is sufficient for the simple examples we provide, is introduced in the following. It is the basis for the example transformations in this thesis.
3.3.1 Repository Mapping
A repository of a PCM model is mapped to three Java packages. One package represents the repository itself and serves as the root package for anything in the PCM repository.
Two further packages are intended to contain the realization of the interfaces and data types of the repository. A contracts package within the repository package contains the interfaces of the repository. They define the contracts between components that provide or require them. A data types package inside the repository package contains the data type realizations.
: Repository name = “someRepository”
: Package name = “someRepository”
: Package name = “contracts”
: Package name = “datatypes”
PCM Model Java Model
subpackage subpackage corresponds to
corresponds to corr
esponds to
corresp onds
to
Figure 3.3: Mapping of a PCM repository to Java packages
The name of the repository package is the same as the name of the repository within the PCM model. The names of the contracts and data types packages are intended to be statically defined ascontractsanddatatypes. An example mapping for a repository is shown in Figure 3.3. The repository calledsomeRepositoryis mapped to a package with the same name and the two mentioned sub-packages.
To achieve consistency between a repository and its representation in program code, the modification of any element that corresponds to another has to be monitored. If a repository is created, deleted or if its name is changed, appropriate modifications in the Java code are required. Vice versa, the deletion of any of the packages or the renaming of the repository package require an update of the PCM repository.
3.3.2 Component Mapping
Components that are added to a repository are mapped to a package and a facade class in the Java code. The component package is inserted into the package which the repository was mapped to, and the facade class is added to that component package. Both the package and the class have the same name as the component, except that the class name starts with an upper case letter and the package name starts with a lower case latter, according to the Java language constraints. From now on, the facade class of a component is simply be referred to as the component class.
The component mapping is exemplified in Figure 3.4. A component named someCompo-nentis mapped to a package and a class with the same names. This mapping relies on the
: Repository name = “repository”
: Component name = “someComponent”
: Package name = “repository”
: Package name = “someComponent”
: Class
name = “SomeComponent”
PCM Model Java Model
component subpackage
classifier corresponds to
corresponds to
corresponds to corr
esp onds
to corr
esponds to
Figure 3.4: Mapping of a PCM component to a Java package and class
3.3 Relations between Software Architecture Descriptions and Code Models mapping of the repository that contains the component because the component package has to be inserted into the package which the repository is mapped to.
For preserving consistency between a component and its code representation, the modifications of any element having correspondences have to be investigated, as described for the repository mapping. Modifications in this mapping can require cascading updates.
Changing the class name in the Java code requires an update of the component name in the PCM model, which in turn requires the adaption of the package name. Finally, the name of the class implicitly corresponds to the name of its package as well. Nevertheless, we only consider relations between the different models, which implicitly also define correspondences within a model, as this example shows.
3.3.3 Interface Mapping
The mapping of an interface within a PCM repository is straightforward. It is mapped to a Java interface with the same name, which is added to the contracts package of the repository.
This interface mapping is exemplified in Figure 3.5, where an interfacesomeInterface within a PCM repository is mapped to a Java interface of the same name. It is placed in the contracts package of the containing repository, which requires the repository mapping to be existent.
: Repository name = “repository”
: Interface name = “someInterface”
: Package name = “contracts”
: Interface name = “someInterface”
PCM Model Java Model
interface classifier
corresponds to
corresponds to
corresponds to
Figure 3.5: Mapping of a PCM interface to a Java interface
3.3.4 Data Type Mapping
The mapping of a data type in a PCM model depends on its concrete type. Data types are separated into collection data types, composite data types and primitive data types.
The latter ones represent a special case, which is discussed later, because a concrete primitive type is represented in the Java metamodel instead of a Java model. Collection and composite data types are mapped to simple Java classes with the same name, which
are added to the data types package of the repository. Collection and composite data types also contain inner types, which actually have to be mapped, but are not considered here.
In Figure 3.6, the mapping of a composite data type calledsomeDataTypeto a Java class is shown. Both have the same name, except that the class name has to start with an upper case letter. For inserting the class into the correct data types package, which the repository is mapped to, it has to be existing and must be retrieved through the repository mapping.
: Repository name = “repository”
: CompositeDataType name = “someDataType”
: Package name = “datatypes”
: Class name = “SomeDataType”
PCM Model Java Model
dataType classifier
corresponds to
corresponds to
corresponds to
Figure 3.6: Mapping of a PCM composite data type to a Java class
4 Model Changes and Model Consistency
In this chapter, we introduce the basic terminology and concepts in the context of model changes and model consistency. After specifying the term model consistency, we explain model changes and change descriptions. Based on the specification of changes, the re-quirements for change-driven model transformation environments are derived. Finally, we join the different topics to the concept of change-driven model consistency repair.
Several approaches give a more formal definition of changes and consistency [46, 98].
In contrast, our definitions focus on the comprehensibility by a methodologist who has to specify the consistency between models, rather than on the theoretical provability of the applicability of a consistency-preserving mechanism.