Refactory

Abstract

Complex systems consist of a multitude of heterogeneous, interconnected models. When one of these models evolves due to changing demands, dependent models have to be co-evolved in order to maintain consistency of the system. In this work, we develop an approach for co-evolution of models in complex systems. We investigate how performed modifications in one model can be propagated to dependent models. Using a reasonable set of atomic evolution operators, we propose an approach for derivation of co-evolution steps that can be adapted when new models enter a complex system.

Introduction

We face such complex systems in many areas of software development such as Cyber-Physical Systems (CPSs), the semantic web or Software Product Line (SPL) engineering. Within those systems, a large number of models with interdependencies exists. When one model in a complex system evolves, it is very likely that related models are affected by this change and have to be updated in order to maintain consistency. In the area of refactoring [1], only semantic preserving modifications are considered. Nevertheless, these modifications may still affect dependent models so that they have to be propagated as well. In this work, refactorings are considered as a special subset of evolutions. Combining the initial evolution with the modification of dependent models can be considered as co-evolution. We define co-evolution as subsequent update of dependent models on the same abstraction layer. Subsequent updates may have to be performed over multiple stages and branches, which is illustrated in Fig. 1.

Figure1. Extract of the successive progression of model co-evolution. The different colours of the model elements indicate different metamodels.

The process of propagating the initial changes to dependent models over multiple stages can be very complex. The main problem we see is the heterogeneity regarding the different metamodels in such systems. As a consequence, we see a strong risk that users of complex systems have to be involved too heavily in the co-evolution process, which can be both tedious and error prone. Due to the different participating languages, users must be prevented from specifying each possible language interaction as it might lead to exponential explosion of potential combinations. Therefore, we aim at the derivation of co-evolution steps in dependent models to aid users as far as possible.

Refactory Approach

We investigate co-evolution of models in a particular subset of complex systems we call Controlled Open Domain Systems (CODSs) and implement the concepts in our tool Refactory (http://www.modelrefactoring.org). We define CODSs as systems that may dynamically be extended by new models with potentially previously unknown metamodels but never without informing the system about the change. In a CODS, models not yet known are situated outside the system but can potentially enter the system. This process must be controlled with an appropriate mechanism that informs about new models entering the system.

In the process of co-evolution, an initial evolution of a model prompts for subsequent modifications of dependent models. As prerequisite for this procedure, all relevant model dependencies need to be determined. We distinguish four different categories of interdependencies between models as depicted in Fig. 2.

Figure 2. Categories of model dependencies. In explicit dependencies, physical and logical connections are aligned.

  • Direct dependency of a model A on another model B is established if there is an explicit reference from model A to model B.
  • Inverse dependency from model A to model B exists if a model A is referenced by another model B but is itself unaware of the connection. An inverse dependency can be perceived as the opposite of a direct dependency.
  • Mapping dependency exists between two models A and B if an external mapping model relates elements of model A to those of model B. More than two models may participate in a mapping dependency.
  • Transformation dependency between two models A and B is established if specific concepts of model B can be obtained by applying particular rules of transformation to concepts of model A.

In order to modify models in CODSs, individual evolution operations need to be defined. To be independent from specific metamodels and the particular evolution operations for their instances, we specify evolutions only based on a reasonable set of generic atomic evolution operators. As discussed in[2], abstractions on metamodel level is not suitable. In particular, these operators are: create, delete, assign, set, move, split and merge.

When new models entering the CODS may have connections to previously existing models. Thus, modifications of a model may prompt the need for co-evolution steps on the newly added models to maintain consistency of the system. However, in CODSs, there might be no apriori knowledge of the metamodels of the newly added models. Nevertheless, evolutions and their co-evolution steps can only be specified and performed when at least a minimal level of knowledge about the new metamodels is present. We entitle the complete knowledge about a new metamodel required for the evolution system Domain-Specific Evolution Specification (DSES). The DSES has to be provided when a model enters the CODS and it consists of three constituents:  1) the metamodel the new model conforms to, 2) the Evolution Definition (ED), used to define evolutions that can be performed directly on models being instances of the specified metamodel, 3) the Co-Evolution Definition (CoED), defining the modification steps that need to be applied as a consequence to an evolution of another connected model.

If a model was not provided with a DSES, a new one is generated automatically, containing the corresponding metamodel and an empty ED and CoED. Additionally, it has to be possible that new links of evolutions in one model and co-evolutions in another model can be established dynamically. Furthermore, entirely new modifications may have to be defined dynamically in order to react to changes in models with previously unknown metamodels.

The outcome of a modification is a sequence of atomic operators, each annotated with the concrete modified model element. To determine in a subsequent model which co-evolution steps have to be applied, the already performed operator sequence must be transferred to dependent models. To automatically determine the adequate co-evolution steps in a dependent model, only the transferred information from the evolution stream is available. Except for inverse dependencies, the previous metamodels are not necessarily known statically to be used in the DSES of the model to be co-evolved. Due to this reason, adequate co-evolution actions may have to be established during operation of the CODS. When a co-evolution process is blocked in the case that a dependent model is known but the modifications to be made depending on previous modifications are not, users can decide which elements must be traced and which modifications have to be performed. With regard to the premise of preventing users from being integrated into the co-evolution process too heavily, CODS must have a learning mechanism. With such a mechanism, users have to be consulted only in those cases where a DSES that contains a metamodel and empty ED and CoED was contributed to the CODS. Once users made a decision, definitions for the ED and the CoED are generated and added. For future co-evolution cycles, the needed information is present and can be used as usual so that users do not need to intervene again.

References

  1. M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts. Refactoring – Improving the Design of Existing Code. Addison Wesley, USA, 1999.
  2. J. Reimann, M. Seifert, and U. Aßmann. Role-Based Generic Model Refactoring. In D. C. Petriu, N. Rouquette, and Ø. Haugen, editors, 13th MODELS Conference, Springer, 2010.

Comments are closed.