Summary of Most Relevant Topic Papers
Models are central artifacts in model-driven software development (MDD). However, software changes over time and so do models. Many of the new requirements imposed by stakeholders, technology adaptations, or bug and performance improvements do not only affect the implementation, but also require an evolution, refinement or refactoring of the models describing the system. When models play a central role in the development process, it is therefore necessary to provide a well-founded, methodologically sound and tool-based assistance for evolving models according to changing needs. [CFJ+16] discusses several of the following.
Agile methods, such as XP or Scrum, rely to a large extent on the ability to evolve the system due to changing requirements, architectural improvements and incremental functional extensions. While agile methods use code as their central artifacts, a model-driven method concentrates on modeling artifacts.
In [Rum04c] and [Rum12] we describe an agile, model-based method that relies on iterated and fully automatic generation of larger parts of the code as well as tests from models, which in turn enables us to apply evolutionary techniques directly on the various kinds of models, e.g., the UML. We argue that combining automatic and repeatable code generation with tool-assistance for model transformation allows combining agile and model-based development concepts for a new and effective kind of development process.
An overview on current technologies for evolving models within a language and across languages is given in [LRSS10]. We refined this with a focus on evolving architecture descriptions for critical software-intensive systems [MMR10].
Refinement is a specialized form of transformation of models that adds informational details, while all conclusions a developer could derive from the abstract model still hold. Such an addition may for example be the structural refinement of the state space of state machine, but also the reduction of underspecification expressed as alternative behaviors. Stepwise refinement is therefore an important development technique as it prevents unwanted surprises when abstract models are implemented.
In [PR94] we developed a precise understanding of automaton refinement that is especially useful for software development, as it uses a loose semantics approach, where no implicit assumptions are made that need to be invalidated in the refinement steps. In [KPR97] we applied this refinement concept to feature specifications.
Finally, we developed a powerful set of refinement rules for pipe-and-filter architectures in [PR99]. Its rules allow us to refactor the internal structure of an architecture, while retaining respectively refining the externally promised behavior. We speak of “glass box” refinement as opposed to “black box” refinement, where only the external visible behavior is taken to consideration, and “hierarchical decomposition”, where a black box behavior is decomposed into a (forthwith immutable) decomposed architecture.
We refined and applied this to automated semantics-preserving parallel decomposition of finite component and connector architectures in [KRW20] and sketch the ideas for a synthesis technique from crosscutting and thus incomplete structural views in [MRR14a].
As performing a refinement step is error-prone, we present a language independent and fully automated method to repair failed model refinements [KR18a]. This is possible by identifying syntactic changes that does not lead to refined models.
Refactoring of Models
Refactoring aims to improve the internal structure while preserving its observable behavior and became prominent with agile development. In [PR01] we traced back refactoring of programs to related techniques, e.g., known from math or theorem provers. In [PR03] we have discussed the existing refactoring techniques for specifications and models.
We, e.g., found a number of well-defined refactoring techniques for state machines, logic formula, or data models that come from formal methods, but have not yet found their application in software development. In [Rum12] we therefore discuss refactoring techniques for various UML diagrams in detail. Additionally, libraries of reusable refactorings for class diagrams and MontiArc models were developed [Hoe18].
If a model refactoring is actually a refinement, then dependent artifacts are not affected at all. However, it may be that a refactoring does have effect on related artifacts. In [MRR11d] we discuss a technique to identify semantic differences for UML’s activity diagrams. It can be used to understand the effects of a refactoring resp. evolutionary change.
It is important to understand semantic differences between refactoring steps on data structures by exhibiting concrete data sets (object structures) as a witness of semantic differences. Thus, we provide a mapping of UML class diagrams to Alloy [MRR11e].
Understanding Model Differences
While syntactic differences of models are relatively easy to understand, it is an interesting question what the semantic differences between two given models are, where one evolved from the other, and what their clear semantics is. In [MRR10] we discussed the necessity for this and since then have defined a number of semantic-based approaches for this (see Semantics of Modeling Languages). We also applied compatibility checking of evolved models on Simulink, e.g., in [RSW+15], where we identified in which system context a component can be replaced safely by another version and still achieve the same functionality.
Delta Transformations to Describe Software Variability
Software product line engineering is most effective if planned already on the modeling level. For this purpose, we developed the delta approach for modeling. Each delta describes a coherent set of changes on a model. A set of deltas applicable to a base model thus describes a model variant (see also Variability & Software Product Lines (SPL)).
We successfully applied delta modeling for software architectures [HRRS11] and extended this into a hierarchical approach in [HRR+11]. Second, we discussed in [HRRS12], how to evolve a complete product line architecture, by merging deltas or extracting sub-deltas, etc., which allows us to keep a product line up to date and free of undesired waste. Third, based on the experience we gained from applying the delta approach to one particular language, we developed an approach to systematically derive delta languages from any modeling language in [HHK+13] and [HRW15].
Model Transformation Language Development
As we do deal with transformations on models in various forms, we are very much interested in defining these transformations in an effective and easily understandable form. Today’s approaches are focussing on the abstract syntax of a modeling language, which a typical developer should not be aware of at all. We heavily demand better transformation languages. Thus, in [Wei12] [HRW15] [Hoe18] we present a technique that derives a transformation language from a given base language. Such a transformation language reuses larger parts of the concrete syntax of the base language and enriches it by patterns and control structures for transformations. We have successfully applied this engine on several UML sub-languages and DSLs [HRW15] [HHR+15] [AHRW17] [AHRW17b] [Hoe18].
- Model transformation is a central concept for model driven development, that enables model-based evolution.
- Refactoring on models is effective, when assisted by appropriate tools.
- Refinement is a special form of refactoring, where the properties that can be derived from the old model are preserved.
- Semantic differencing helps to understand the impact of evolutionary refactoring on models.
- Using model transformations as individually applicable “deltas” allows describing
- model and therefore software variants.
- Language specific transformation languages can be systematically derived from given descriptions of modeling languages.
Selected Topic-Specific Publications
[KRW20]Automated semantics-preserving parallel decomposition of finite component and connector architectures.In: Automated Software Engineering, Volume 27, pp. 119-151, Springer, Apr. 2020.
[Hoe18]MontiTrans: Agile, modellgetriebene Entwicklung von und mit domänenspezifischen, kompositionalen Transformationssprachen.Aachener Informatik-Berichte, Software Engineering, Band 36, ISBN 978-3-8440-6322-6, Shaker Verlag, Dec. 2018.
[KR18a]In: Conference on Model Driven Engineering Languages and Systems (MODELS’18), pp. 289-299, ACM, Oct. 2018.
[AHRW17]In: International Conference on Robotic Computing (IRC’17), pp. 172-179, IEEE, Apr. 2017.
[AHRW17b]In: Journal of Software Engineering for Robotics (JOSER), Volume 8(1), pp. 3-16, 2017.
[CFJ+16]Chapman & Hall/CRC Innovations in Software Engineering and Software Development Series, Nov. 2016.
[HRW15]In: Conference on Model Driven Engineering Languages and Systems (MODELS’15), pp. 136-145, ACM/IEEE, 2015.
[RSW+15]In: Software Product Line Conference (SPLC’15), pp. 141-150, ACM, 2015.
[HHR+15]Generating Domain-Specific Transformation Languages for Component & Connector Architecture Descriptions.In: Workshop on Model-Driven Engineering for Component-Based Software Systems (ModComp’15), Volume 1463, pp. 18-23, CEUR Workshop Proceedings, 2015.
[MRR14a]In: Software Engineering 2014, W. Hasselbring, N. C. Ehmke (Eds.), Volume 227, pp. 63-64, LNI, Gesellschaft für Informatik, Köllen Druck+Verlag GmbH, 2014.
[HHK+13]In: Software Product Line Conference (SPLC’13), pp. 22-31, ISBN 978-1-4503-1968-3, ACM, 2013.
[Rum12]Springer Berlin, Jun. 2012.
[HRRS12]In: Large-Scale Complex IT Systems. Development, Operation and Management, 17th Monterey Workshop 2012, pp. 183-208, LNCS 7539, Springer, 2012.
[Wei12]Aachener Informatik-Berichte, Software Engineering, Band 12, ISBN 978-3-8440-1191-3, Shaker Verlag, 2012.
[MRR11e]In: Conference on Model Driven Engineering Languages and Systems (MODELS’11), pp. 592-607, LNCS 6981, Springer, 2011.
[HRR+11]In: Software Product Lines Conference (SPLC’11), pp. 150-159, ISBN 978-1-4577-1029-2, IEEE, 2011.
[MRR11d]In: Conference on Foundations of Software Engineering (ESEC/FSE ’11), pp. 179-189, ACM, 2011.
[HRRS11]In: Tagungsband des Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteterSysteme VII, pp. 1 - 10, fortiss GmbH, 2011.
[MMR10]In: IEEE Computer, Volume 43(5), pp. 42-48, IEEE, May 2010.
[LRSS10]In: Model-Based Engineering of Embedded Real-Time Systems Workshop (MBEERTS’10), pp. 241-270, LNCS 6100, Springer, 2010.
[MRR10]In: Proceedings Int. Workshop on Models and Evolution (ME’10), pp. 194-203, LNCS 6627, Springer, 2010.
[Rum04c]In: Workshop on Radical Innovations of Software and Systems Engineering in the Future (RISSEF’02), pp. 297-309, LNCS 2941, Springer, Oct. 2004.
[PR03]In: Practical Foundations of Business and System Specifications, Kilov, H. and Baclavski, K. (Eds.), pp. 281-297, Kluwer Academic Publishers, 2003.
[PR01]In: Tenth OOPSLA Workshop on Behavioral Semantics. Tampa Bay, Florida, USA, October 15, Kilov, H. and Baclavski, K. (Eds.), Northeastern University, 2001.
[PR99]In: Congress on Formal Methods in the Development of Computing System (FM’99), pp. 96-115, LNCS 1708, Springer, 1999.
[KPR97]In: Workshop on Feature Interactions in Telecommunications Networks and Distributed Systems, pp. 284-297, ISBN 90-5199-347-1, IOS-Press, 1997.
[PR94]In: Proceedings of the Industrial Benefit of Formal Methods (FME’94), pp. 154-174, LNCS 873, Springer, 1994.
- Agile Model-Based Software Engineering
- Domain-Specific Languages (DSLs)
- Generative Software Engineering
- MontiCore - Language Workbench
- Semantics of Modeling Languages
- Software Language Engineering (SLE)
- Unified Modeling Language (UML)
- Variability & Software Product Lines (SPL)