The lifecycle of a software architecture spans the overall software development process, because it represents the earliest working artefact that evolves along the process, even after the software release. A software architecture can support different tasks, like test case generation, traceability, non-functional validation, etc. Hence, the architecture is subject to changes induced by decisions taken along the process.
Architectural changes driven by non-functional requirements are particularly difficult to identify because they attain quantitative analyses that often cannot take place in the same context (i.e., languages and tools) where the architecture is designed. For example, very few ADLs embed constructs that allow specifying performance attributes, and even fewer ones are equipped with solvers leading performance indices out of an architecture specification.
Hence, in order to validate non-functional requirements on a software architecture, a considerable number of approaches, mostly based on model transformations, have been proposed in the last decades to generate non-functional models from software architectural descriptions. This generation step is also called forward path.
However, the solution of generated models does not necessarily produce indices that satisfy the requirements, thus an iterative process is often required to modify/refactor the generated model on the basis of solution results. This process (hopefully) ends up when satisfactory indices are produced.
Thereafter, changes applied to non-functional models for sake of requirement satisfaction have to be propagated back to the software architecture. However, analyses results do not straightforwardly suggest what changes have to be made on the software architecture, hence this propagation is often based on the ability of experts that interpret the results. This clear lack of automation in the backward path represents a heavy limitation towards the construction of a round-trip process for non-functional validation of a software architecture.
The basic idea beyond our approach [1] is to exploit the power of bidirectional model transformations. They are based on transformation languages that, once defined a transformation from a source to a target metamodel, with the help of traceability links, enable the inverse transformation from target to source metamodel. We introduce a forward path based on a bidirectional transformation between two specific modeling notations (i.e., one for architectural modeling and the other one for availability modeling), so that the backward path simply reduces to apply the inverse transformation to the availability model that satisfies the requirements. The changes made during the refactoring driven by analysis results are thus propagated back to the software architecture.
Our Approach: bidirectional transformations to evolve architecture descriptions along with the non-functional requirements
Model Driven Engineering (MDE) [2] leverages intellectual property and business logic from source code into high-level specifications enabling more accurate analyses. In general, an application domain is consistently analyzed and engineered by means of a metamodel, i.e., a coherent set of interrelated concepts. A model is said to conform to a metamodel: it is expressed by the concepts encoded in the metamodel. Constraints are expressed at the meta-level, and model transformations are based on source and target metamodels. With the introduction of model-driven techniques in the software lifecycle, the analysis of quality attributes has become effective by means of automated transformations from software artifacts to analysis models.
We propose a model-driven approach to support designers in their availability analysis process that involves the backpropagation of results to the software architecture. The approach makes use of bidirectional model transformations written in JTL [3] (that will be presented in the next section). In contrast to unidirectional languages, bidirectional transformation languages allow describing both forward and backward transformations simultaneously, so that the consistency of the transformation can be guaranteed by construction.
Our approach focuses on analysis models designed by means of GSPN [4], whereas the software architecture is modeled by means of UML [5] and, in particular, for the behavioral aspects, State Machines annotated via DAM [6] are considered (UMLSM).
The UMLSM-GSPN bidirectional transformation is defined once, and it is embedded into the JTL engine that enables its execution in both forward and backward directions.
In order to execute the UMLSM-GSPN in the forward direction, a DAM-annotated SM model is taken as input to the JTL engine, and a GSPN model is produced as output. The generated GSPN model is solved in order to obtain a set of indices that have to be interpreted. Thereafter, the GSPN model is iteratively refactored until availability requirements are satisfied. In order to propagate changes applied to the GSPN model back to the software architectural model, the UMLSM-GSPN bidirectional transformation is executed in backward direction. In this case, the JTL engine takes as input the modified GSPN model and produces as output DAM-annotated SM models.
Janus Transformation Language (JTL)
JTL is a constraint-based model transformation language specifically tailored to support bidirectionality and non-determinism. The implementation relies on the Answer Set Programming (ASP) [7], which is a form of declarative programming oriented towards difficult (primarily NP-hard) search problems and based on the stable model (answer set) semantics of logic programming.
The language supports object pattern matching, and implicitly creates trace instances to record what occurred during a transformation execution.transformation between candidate models is specified asset of relations that must hold for the transformation to be successful: in particular, it is defined by two domains and includes a pair of when and where predicates that specify the pre- and post- conditions that must be satisfied by elements of the candidate models. When a bidirectional transformation is invoked for the enforcement, it is executed in a specific direction by selecting one of the candidate models as the target by means of a run configuration. The JTL engine finds and generates, in a single execution, all the possible models which are consistent with the transformation rules by a deductive process.
The JTL tool [3] has been implemented within the Eclipse IDE [8] and mainly exploits the Eclipse Modeling Framework (EMF) [9]. Moreover, it makes use of the DLV solver [10] (which has been wrapped and integrated in the overall environment) to execute transformations in both forward and backward directions.
Vittorio Cortellessa, Romina Eramo, Michele Tucci
University of L’Aquila, Italy
References
- V. Cortellessa, R. Eramo, and M. Tucci, “Availability-driven Architectural Change Propagation through Bidirectional Model Transformations between UML and Petri Net Models”, International Conference on Software Architectures, ICSA 2018.
- D. Schmidt, “Guest Editor’s Introduction: Model-Driven Engineering,” Computer, vol. 39, no. 2, pp. 25–31, 2006.
- Janus Transformation Language (JTL) – http://jtl.di.univaq.it/
- M. A. Marsan, G. Balbo, G. Conte, S. Donatelli, and G. Franceschinis, “Modelling with generalized stochastic petri nets,” SIGMETRICS Perform. Eval. Rev., vol. 26, no. 2, pp. 2–, Aug. 1998.
- Object Management Group (OGM) “Unified Modeling Language” – https://www.omg.org/spec/UML/2.5.1/
- S. Bernardi, J. Merseguer, and D. C. Petriu, “A dependability profile within MARTE,” Software and System Modeling, vol. 10, no. 3, pp. 313–336, 2011.
- M. Gelfond and V. Lifschitz, “The Stable Model Semantics for Logic Programming,” in Procs of ICLP. Cambridge, Massachusetts: The MIT Press, 1988, pp. 1070–1080.
- Eclipse IDE – http://www.eclipse.org/
- Eclipse Modeling Framework (EMF) – http://www.eclipse.org/modeling/emf/DLV-Complex
- DLV-Complex – https://www.mat.unical.it/dlv-complex