EN 
DE Effectively prevent model erosion
Authors: Ingo Battis, Sennheiser electronic GmbH & Co. KG and Thomas Eisenbarth, Axivion GmbH
Contribution – Embedded Software Engineering Congress 2015
The promises of UML modeling with subsequent code generation include significantly higher maintainability, error-free operation, and flexibility compared to manual coding. In this scenario, the UML model, as an implementation model, takes over tasks from the coding process. Therefore, the UML model must be treated as if it were replacing code and protected accordingly from software erosion and implementation errors. An implementation must always follow an architecture, which consequently cannot be contained within the implementation model itself. Only then can the model be checked for various types of correctness.
Deployment scenario at Sennheiser
For the development of a new project, we decided to rely heavily on modeling using UML and subsequently generating code from the models. Manual coding will only be used in the driver layer. To this end, the design and implementation will be carried out entirely in Rhapsody.
Furthermore, we maintain an architecture that serves as the blueprint for design and implementation.
Hierarchically structured models
In the project under consideration, software development proceeds as the creation of a hierarchy of models. These models are linked to one another through relationships between their respective elements. One of these relationships is called refinement. In our example, the models are Architecture, Design, and Coding. The models become increasingly detailed and concrete from top to bottom in the hierarchy. In our specific use case, the Architecture contains the layers, the Design considers components and further details within the layers, and the Coding finally represents concrete elements of the target language, such as C functions.
The elements of a model are refined in the hierarchically lower-level model. The architecture is manually refined into a design, which in our case is largely automated and implicitly refined for implementation by a generator.
In Fig. 1 (see PDF) is, for example, the refinement of a UML package from the architecture (model). Mn)) in two UML packages in the design (model) Mn+1(As shown): This refinement is important for later verification. The refinement is done manually and, in our example, follows a naming convention, which is desirable for traceability but generally not necessary. The procedure described here is independent of the specific element types and therefore not limited to UML.
For our approach, the order in which the models are created and modified is irrelevant. The models can be subsequently modified and extended. Therefore, it is not necessary to implement the models and refinements in a strictly sequential and top-down manner (analogous to a waterfall model); an iterative-incremental approach is always possible. In fact, the applied testing methodology utilizes the models and the refinement relationships, but not knowledge of the sequence in the development process.
When using UML tools to define the models discussed here, the problem arises that UML itself only contains one UML model. Diagrams serve only for representation and otherwise have no effect on the structure of the UML model.
To verify correct refinement within the hierarchy of models, the models must be disjoint and connected via the refinement relation. Otherwise, verification is impossible. For example, suppose the same UML package entities are used in both the architecture and the design.
In Fig. 2 (see PDF) is in model Mn a UML dependency between two packages A and B introduced because in Mn+1 The classes contained in these packages derive from each other. This dependency could have been incorporated into the architecture from the outset. It is no longer possible to verify whether this dependency was correctly refined from the architecture into the design.
This example also shows that a system where a change in one model automatically leads to a change in another model does not allow for consistency checks between the models. This coupling is often seen as an advantage ("the overall model is always correct"), but it only makes sense from the perspective of reverse engineering and simple program understanding ("I see what is"). From the perspective of planning, traceability, and abstract program understanding ("I see where the differences lie between what is and what should be"), this approach is counterproductive.
To ensure the integrity of the architecture, we decided to model the architecture in Enterprise Architect, but the design in Rhapsody. This way, it is technically impossible for unintended relationships to pass from one model to another.
The architectural review itself
The comparison between two models in the model hierarchy is performed as a graph operation in which each entity and relationship from the concrete model is assigned an entity or relationship from the more abstract model [1].
If this fails, a violation has occurred. The following situations may arise:
When creating the refinement (see Fig. 3, PDF):
- An abstract element is not refined into a more concrete form.
- A concrete element is not a refinement of a more abstract one.
Every refinement between two models Mn and Mn+1 must the relations of the model Mn in the model Mn+1 retained in the refinement. If this is not the case, then the mapping between the models is not meaningful. This situation indicates a modeling error, see Fig. Z (PDF).
During the actual testing process (see Fig. Z, PDF):
- There is a relationship a ® b in Mn+1, where a a refinement of A and b a refinement of B, however, there is no relationship A ® B in Mn (We call this situation divergence).
- There is a relationship A ® B in Mn, however, no refinement a from A and refinement b from B, so that a ® b This applies (we call this situation absence).
For the architecture review, we need to determine which UML elements (entities and relationships) may be used in the architecture and design, and how they correspond to each other.
For example, a dependency with stereotype „use“ in the architecture of our case study corresponds to a whole series of dependencies and associations in the design, e.g., generalization, use dependency, and association.
The refinement relationship between architecture and design is calculated by a Python script that reads the specifications and creates the refinement relationships based on them. In our case, the refinement relationship is defined by naming conventions: A package named "A" in the architecture corresponds exactly to a package named "PkgA" in the design. This relationship is particularly simple as a one-to-one relationship, but in general, one-to-one relationships are more common.n-Relationships are possible. The error conditions listed above for creating the refinement are also diagnosed. This allows for the detection of user errors and misinterpretations in tool usage.
Success of the intervention: Examples of erosion uncovered
In daily practice, the test has proven its worth and uncovered situations that would otherwise have led to a long-term erosion of the architectural description, see Fig. 6 (PDF).
The analyses are performed in a continuous build environment. The individual necessary steps are:
- Importing the architecture from Enterprise Architect
- Import the design from Rhapsody
- Preparatory steps: Interpretation of the models, calculation of the refinement relation
- Conducting the examination
- Visualization of the results
The imports, preparatory steps, and checks are performed using the Axvion Bauhaus Suite. Any violations found are visualized either graphically or, in daily use, via the Axvion Bauhaus Suite dashboard. Thanks to the process-oriented approach, it is possible to directly rebuild the problematic areas in accordance with the architecture or to adapt the architecture accordingly.
literature
[1] Koschke, Rainer; Simon, Daniel: Hierarchical Reflection Models. In: Proc. of the Working Conference on Reverse Engineering, IEEE Computer Society Press, 2003.
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
