Download Slides from our Talk: Configuration Management for Modelbased Product Line Development
Abstract. Cost and innovation pressure are the central drivers for switching to model-based product line development. However, the hoped-for shortening of development cycles requires close cooperation between platform development and the various customer projects. If these are complex products with a large number of components and supporting specialist groups that previously worked on the basis of a common model, completely new challenges arise at model level. Establishing the so-called “basic software”, which forms the basis of the individual product lines, as an independent platform and adapting and extending it in individual customer projects, is not easily possible with today’s standard modeling tools. With MPMS (Model Package Management System), LieberLieber provides a new, industrial proven approach that aims to work on different model versions in a distributed manner while always keeping the “basic software platform” in a consistent state. The central idea of this concept is the application of already existing approaches that have established themselves in the area of source code configuration management. It becomes possible to use parts of the model from the platform development as components in the project development – and also to “merge” changes in both directions.
The goal of MPMS (Model Package Management System) is to provide a comprehensive solution for the modeling of complex systems in complex organizational and infrastructural environments. Modeling such systems in modeling tools such as Enterprise Architect from SparxSystems or others usually requires one monolithic model repository. The ability to connect the elements throughout the entire model (so-called “traceability”) is one of the most important advantages of a modeling approach. [ BCW17] This forces all modeling project participants to work directly in the central repository, and all modeling components and elements must be stored there. Nevertheless, different parts of the model may have different lifecycles and it should therefore be possible to model those parts independently from one another, driven by an existing change management process. [BMAWK17] These two needs generate a conflict, which will be explained in more details below.
2 Current Challenges
The following challenges could be identified together with many Systems Engineers from the automotive, railway or aviation domain – OEMs as well as 1st-tier or 2nd-tier suppliers:
2.1 Application of V-Model
The V-Model is often applied to the development of complex and safety-relevant systems. In this case, different model parts are assigned to different levels of the V-Model process (see Figure 1). These different parts depend on each other and therefore constitute a staggered effort timeline. The main conflict here – even if shifted in time in a project-management sense – is that the modelers have to work in parallel, and nevertheless the precondition for initiating work on every V-level is a stable (even if a draft) version of the model part from the higher abstraction level (from a V-Process point of view).
2.2 Platform Approach
The next example is platform-based (product line) development (see Figure 2).In this case, some model parts belong to the platform while other parts belong to products or customer projects. The platform development (including the corresponding model parts) must be naturally decoupled from the end-product and project development. The platform typically serves as a basis for multiple projects or product versions in different development stages. Nevertheless, all of them must be based on the stable state of the platform. Sometimes, however, it is necessary to customize the platform due to particular customer requirements and, if necessary, it should be possible to reintegrate that project/product specific version back into the platform later on. There are many further challenges that arise in this case – actually, all – which exist on the source code level also apply on the model level.
2.3 Interative Development
Another reason can be the iterative (or agile) development approach, whereby multiple teams work iteratively and independently from each other on different features or on change-requests. These tasks often include some modeling work on the corresponding model parts. Independent modeling in that context means every team can perform its feature related work in an isolated boxed environment without any interruptions or influences from other teams. Iterative modeling means that the results of the work of different teams must be integrated into the overall/central model in an iterative manner until the final result has been reached. [WLSWK13] A typical process is depicted in Figure 3.
There exists the necessity to connect elements from different model parts to each other, but on the other hand, there also exists the necessity to separate the model parts to enable parallel collaborative work. Assuming that typical built-in functionalities in state-of-the-art modeling tools in industry are available and once the users try to separate the monolithic model into multiple models, the connections that were created between the model parts get lost or corrupted. At the very latest, when users try to create and maintain multiple versions or even branches of the model parts, the challenges become practically unsolvable. This describes one of the hardest modeling challenges that currently exists, and which MPMS intends to resolve.
[BCW17] Marco Brambilla, Jordi Cabot, Manuel Wimmer: Model-Driven Software Engineering in Practice, Second Edition. Synthesis Lectures on Software Engineering, Morgan & Claypool Publishers 2017.
[BMAWK17] Luca Berardinelli, Alexandra Mazak, Oliver Alt, Manuel Wimmer, Gerti Kappel: Model-Driven Systems Engineering: Principles and Application in the CPPS Domain. Multi-Disciplinary Engineering for Cyber-Physical Production Systems 2017: 261-299
[WLSWK13] Konrad Wieland, Philip Langer, Martina Seidl, Manuel Wimmer, Gerti Kappel: Turning Conflicts into Collaboration. Computer Supported Cooperative Work 22(2-3): 181-240 (2013)