Iterative development and changing requirements lead to continuously changing models. In particular, this leads to the problem of consistently co-evolving different views of a model-based system. Whenever one model undergoes changes, related models should evolve with respect to this change. Domain engineers are faced with the huge challenge to find proper co-evolution rules which can be finally used to assist developers in the co-evolution process. In this paper, we propose an approach to learn about co-evolution steps from a given co-evolution history using an extensive analysis framework. We describe our methodology and provide the results of a case study on the developed tool support.
The multi-view paradigm is a well-established methodology to manage complexity in the construction of large-scale software systems. In Model-driven Engineering (MDE), this paradigm leads to the concept of multi-view modeling; different modeling notations are used to describe different aspects such as structure, behavior, performance, reliability etc. of a system.
Iterative development and changing requirements lead to continuously
changing models. Consequently, this entails the special challenge to consistently
coevolve different views of a system [
We assume a setting as shown by the bottom-left part of Figure 1, the
terminology is partly adopted from related work on model synchronization and model
co-evolution [
However, due to the multitude of different modeling notations, the manual
specification of co-evolution rules is a tedious and challenging task. Domain
engineers, who have to find proper co-evolution rules, are faced with two essential
questions: (1) Do certain changes on a source model correlate with changes on
the target model? (2) If so, how are the changes coupled with each other? There
are several domains for which no simple and straightforward co-evolution exists.
The only viable solution is to pre-define possible co-evolution rules which can be
offered to developers as possible options. For instance, this is the case for software
architecture and quality of service models [
This paper reports on our ongoing work on the semi-automated co-evolution of models of arbitrary source and target domains. The general process is illustrated by Figure 1. We propose to observe the co-evolution history in order to learn about developer decisions and to finally predict the co-evolution steps with a certain degree of probability. The more evolution steps are analyzed, the more accurate prediction results are expected. The contribution of this paper is the coevolution analysis framework which serves as a foundation for this co-evolution process. The analysis results can be used to generate co-evolution rules for a recommender system to interactively support model co-evolution. We describe our approach in Section 3. Tool support and early evaluation results which demonstrate the feasibility of our approach are briefly discussed in Section 4. Related work is analyzed in Section 5. We draw some conclusions and give an outlook on future work in Section 6. 2
Component diagrams and state charts are widely used notations to model structure and behavior in component-based software engineering. Intuitively, there are several relations between model elements of both views. For example, every state usually has a relation to a component, not necessarily the other way round. Transitions between states somehow reflect the interfaces and connections of the corresponding components in the component diagram. The hierarchy of composite states is expected to correspond to the hierarchical structure of components and their respective sub-components. Despite those rather intuitive relationships, consistently co-evolving both views is not a straight forward process, which is illustrated by the following example.
Customer
Reservation Payment
Booking Cancellation
Trace Trace Trace Trace
Check Room [Available/Yes] 3 2 [Available/No]
Reservation Book Room
Pay the bill 1
6 ? Cancel 4 5 components, namely Customer, Booking and Payment. Relations between corresponding states and components are explicitly given by trace links. The system evolves at some point of time because it requires a new function to cancel a reservation process. In general, we assume that models are edited by means of a set of language-specific edit operations. An edit step invokes an edit operation and supplies appropriate actual parameters, which are also referred to as arguments. In our example, the revised version of the component model is obtained in three edit steps, namely the creation of the component Cancellation and two connectors. The new component and its connections to other components are highlighted in Figure 2 by doubled lines.
State chart elements printed in doubled lines indicate the developer’s intention of co-evolution steps in response to the changes in the component diagram (1,2). We discuss several additional co-evolution steps which are possible on the state chart (Mtgt) in response to the changes in the component diagram (Msrc). Note that these co-evolution steps are only assumptions which are based on domain knowledge, they are not meant to be a result of an empirical analysis.
Elements printed in dotted lines represent expected co-evolution steps which are, however, not intended by the user (3,4,5). Finally, a dotted line with spiral indicates an unexpected co-evolution step which is nonetheless intended by the user (6). We do not claim the set of possible options (1)-(6) to be complete. Nevertheless, it demonstrates the huge challenge of predicting the proper coevolution steps: – As the component Cancellation is added as a sub-component of reservation, a new state called Cancel is expected to be created as a sub-state of the corresponding composite state Reservation. – The creation of transition (1) is expected due to the creation of port and interface relations of the corresponding components in the component model. – Although there is no explicit relation between the components Cancellation and Customer, the creation of transition (2) is expected. Because the newly created relation between the composite component Reservation and the toplevel component Customer, as a result of the creation of Cancellation. However, the new component may lead to an interaction between the components Booking and Customer indirectly via interfaces as well, therefore we should also consider the transition (3) with a small expectation. – The required information for the proposed transitions (4) and (5) cannot be gathered from the component diagram. However, taking general state chart semantics into account, they can be presented to the developer as a possible option. – Finally, we point out transition (6). The developer wants to create a loop between the states Book Room and Cancel which cannot be clearly anticipated from the component diagram since we observe only one direction for communication. Nonetheless, this option can be offered to the developer with a low probability.
We can conclude that each edit step on the component model may lead to many arbitrary co-evolution steps on the state chart. Some forward propagations can be expected with a high probability based on the changes in the component diagram, others can only be offered as a set of possible choices. 3
In Section 2, we have demonstrated a running example as a motivation of our analysis framework. We have presented possible co-evolution steps and observed that there are highly expected, less expected and unexpected changes for state charts when the component diagram evolves.
To study such changes and their relations, our co-evolution analysis framework takes a co-evolution history as illustrated by Figure 1 as input. Each pair of successive versions i → i + 1 from the given history is referred to as evolution scenario evi→i+1. We assume that the co-evolution history includes consistent views for every evolution scenario. We further assume a model differencing engine to be available, which, given a set of possible edit operations for instances of a meta-model M M and successive model versions Mi and Mi+1, calculates a difference diff(Mi, Mi+1). A difference diff(Mi, Mi+1) is defined to be a partially ordered set of edit steps s1 . . . sk. We finally offer two kinds of analysis functions; the correlation analysis is described in Section 3.1, the additional coupling analysis is presented in Section 3.2. 3.1
Correlation Analysis We use the well-known Pearson correlation coefficient to assess the dependency between edit operations which are applicable to the source and target models. The basic processing steps of our correlation analysis are shown by Figure 3. For each evolution scenario evi→i+1 of the co-evolution history, we first compute the differences diff(Msrc,i,Msrc,i+1) and diff(Mtgt,i,Mtgt,i+1). Subsequently, we count the edit steps contained by each of the obtained differences and group them by evolution scenarios and edit operations invoked by the respective edit steps. The sets of edit operations, which are available for instances of M Msrc and M Mtgt, are given as additional input parameters of the correlation analysis.
Based on the calculated differences, we basically construct two matrices. For source model changes, we construct an e-×-s matrix where e denotes the number of evolution scenarios in the history (i.e., e = n−1), s denotes the number of edit operations available for instances of M Msrc. A variable ai,j (i ∈ {1, ..., e}, j ∈ {1, ..., s}) represents the number of edit steps of type j (i.e. edit steps invoking edit operations represented by j, e.g. createComponent in our running example) in evolution scenario i. Analogously, an e-×-t matrix is being constructed for target model changes, where t denotes the number of edit operations available for instances of M Mtgt.
Let X = hx1, x2, ..., xei be a column vector of the e-×-s matrix, and Y = hy1, y2, ..., yei be a column vector of the e-×-t matrix. Then we can compute the Pearson correlation coefficient rX,Y for each combination of column vectors X and Y in order to quantify the linear relationship between edit operations that have been applied to the source and target models. The correlation analysis has the advantage that it only requires the source and target models of each evolution scenario evi→i+1. Thus, this approach can also be applied to study the co-evolution history in cases where no explicit trace links between the observed source and target model exist. However, a correlation between edit operations does not imply that the respective edit steps are actually coupled. In other words, they can have a dependency by coincidence such that none of the involved arguments are actually related by a trace. Hence, we also provide a second analysis function which is capable of identifying coupled changes. Such an analysis can provide knowledge about user’s modeling intentions enhancing correlation analysis results, for example learning of the loop intention by the user, as provided in Figure 2 with transition (6). In general, a coupled change identifies a pair of edit steps which have happened in the same evolution scenario. It also identifies the changed model elements which are connected (either directly or indirectly) to each other and were not just coincidentally changed in the same evolution scenario. We assume here that trace links identify related model elements of the source and target model. These are, together with the model differences for each evolution scenario, provided as additional input parameters of the coupling analysis (see Figure 4).
Let args(s) be the set of arguments of an edit step s. Basically, a pair of edit steps (ssrc, stgt) is considered to be a coupled change, if we can find a pair of arguments (asrc, atgt), with asrc ∈ args(ssrc) and atgt ∈ args(stgt), which are connected via a trace link.
Additionally, domain-specific trace impact patterns can be specified as optional inputs of Trace the coupling analysis. These patterns allow to extend the search for coupled edit steps cc st to the “neighborhood” of elements which are directly connected by a trace link. Consider Trace for instance our running example shown in Figure 2. Here, trace links are only provided for related states and components. However, Fig. 5. Example of a trace impact component connectors and state transitions pattern are also to be considered as related if the connected components/states are related. This can be specified by a trace impact pattern as shown in Figure 5, i.e. the component connector labelled as cc and the state transition labelled as st are implicitly related. Consequently, a pair of edit steps modifying occurrences of cc and st, respectively, are to be considered as coupled.
Coupled changes are summarized over all evolution scenarios of the history as follows: We construct a s-×-t matrix where s denotes the number of edit operations available for instances of M Msrc and t denotes the number of edit operations available for instances of M Mtgt. A variable ai,j (i ∈ {1, ..., s}, j ∈ {1, ..., t}) is computed as the fraction of coupled edit steps of types i and j (i.e. edit steps invoking edit operations represented by i and j, respectively) with respect to all edit steps of type i being observed in the source model history. 4
We have prototypically implemented the analysis framework proposed in
Section 3 on the widely used Eclipse Modeling Framework (EMF) and the model
differencing engine SiLift [
Adaption of the generic framework. In order to adapt the generic framework to
new modeling languages, i.e., to adapt it to a given source and target domain,
one has to configure the SiLift differencing tool chain. Primarily, suitable edit
operations for the source and target domain have to be provided. In SiLift, we
use the model transformation language and system Henshin [
Optionally, a set of trace impact patterns can be specified as additional input
for the coupling analysis. Trace impact patterns are also specified in Henshin.
We refer to these pattern specifications as trace impact rules. Trace impact rules
do not implement in-place transformations, but serve as specifications of graph
patterns which are to be found by the Henshin matching engine. Obviously, trace
impact rules have to be specified manually by a domain engineer.
PPU Case Study. In order to demonstrate the feasibility of our approach, we
have adapted the analysis framework to be used in the PPU(Pick and Place
Unit) case study [
All configuration artifacts which are needed to adapt the analysis framework
to SA and FT models are available at the EnSure website2. In summary, we
identified 82 edit rules available for FT models, 69 of them could be generated
with SERGe. For SA models, we identified 42 suitable edit rules of which only
one had to be specified manually, all other 41 edit rules could be generated with
SERGe. In addition, we specified 6 trace impact rules serving as additional input
of the coupling analysis. Consequently, we were able to automatically generate
the results that have been produced by a manual analysis in our previous work
[
Most approaches to model co-evolution address the migration of different types of
MDE artifacts in response to meta-model adaptions. MDE artifacts which have
to be migrated are, for example, instance models [
Only a few approaches address the evolution of multi-view models, which is
most often considered as a model synchronization problem. Solutions are often
based on the principle of bidirectional model transformations which are used to
derive incremental change propagation rules, e.g., [
In contrast to our approach, TGG rules and change-driven transformations must be specified manually, whereas we intend to generate our co-evolution rules. In fact, we believe that existing approaches based on TGGs, change-driven transformations or similar techniques, can be also supported by our co-evolution analysis framework. Up to the best of our knowledge, we are not aware of any approach providing a framework to empirically study co-evolution by analyzing the history of co-evolving models. 6
Many approaches for consistently co-evolving models and other related MDE artifacts have been proposed recently. Some are tailored to fixed source and target domains while others are more generic and adaptable.
However, correlation and coupling of changes has not been researched indepth for many types of co-evolving (sub-)models. In order to close this research gap, we focus on establishing a co-evolution analysis framework to analyze the history of co-evolving models of arbitrary types. This will provide the foundation for synthesizing co-evolution rules in an automated way. Although the analysis framework still needs some configuration data as input, we conclude from the PPU case study that this adaption to a dedicated source and target domain can be done with moderate effort. Currently, the co-evolution rules which we finally intend to use as input of a co-evolution framework (see Figure 1) still have to be manually synthesized based on the information which is produced by the analysis framework. Larger case studies are needed to evaluate how far we can push the generation of co-evolution rules and how much training data is needed to derive appropriate co-evolution rules.
On the one hand, these co-evolution rules can be used to configure existing model synchronization frameworks in cases of domains where the co-evolution process can be fully automated. On the other hand, co-evolution rules serve as basis for a recommender system, which is able to handle semi-automated co-evolution of models. The latter one is subject to our future work. Acknowledgments. This work is supported by the DFG (German Research Foundation) under the Priority Programme SPP1593: Design For Future - Managed Software Evolution. The authors would like to thank Andr´e van Hoorn, Matthias Tichy and Lars Grunske for the initial discussions and valuable reviews.