Model Consistency ensured by Metamodel Integration Johannes Meier Andreas Winter Software Engineering Group Software Engineering Group University of Oldenburg, Germany University of Oldenburg, Germany meier@se.uni-oldenburg.de winter@se.uni-oldenburg.de ABSTRACT data umlclasses To keep semantically interrelated and physically separated artifacts Requirement +rowNumber : EInt[0..1] Association RequirementsSpecifcation container[1] +name : EString[1] consistent to each other is challenging. Consistency between such content[*] +id : EString[0..1] +author : EString[0..1] +lowerBound : EInt[0..1] +text : EString[0..1] +upperBound : EInt[0..1] artifacts, described by models and conforming to metamodels, tar- gets mainly synchronizing overlapping information and additional associations[*] usedBy[*] asgjava relations between them. This paper depicts an approach to synchro- class[1] type[1] nize models by integrating models together with their metamodels ClassType Class +name : EString[1] into an integrated (meta)model using special operators. These op- +className : EString[1] erators are used to keep all models consistent to each other, which classes[*] class[1] classes[*] is discussed for two consistency rules along three use cases. methods[*] asg[1] diagram[1] calledBy[*] Method JavaASG ClassDiagram +name : EString[1] calling[*] 1 MOTIVATION In modern software systems the heterogeneity of languages de- Figure 1: Initial simplified Metamodels for Requirements scribing certain aspects of systems grows. This includes models, (top left), Class Diagrams (top right), and Sourcecode (below) domain specific languages for different but overlapping concerns, and data produced by tools in arbitrary data formats. All these languages produce data, which are often separated technically from Since these three models describe three different concerns orig- each other by different data formats, different technical spaces, or inating in different tools within the same project, there are the different tools, because of historical growth, or different users with following two illustrative consistency rules: different working locations, concerns or access rights. In this paper, Consistency Rule 1: Data classes are described by class dia- all artifacts are described by models and conforming metamodels. grams as well as by Java: If an instance of asgjava.ClassType These technical separations rise issues, if these models describe has the same value for name like an instance of umlclasses.Class information which are interrelated contentwise: If two models are for className, these two instances describe the same information overlapping and describe the same information, this information and should be renamed in parallel. Sourcecode and class diagram has to be kept consistent to each other. If two models describe differ- are consistent to each other, if they describe the same set of data ent information which are related to each other, these relations have classes, identified by their class names. to be described, changed and stored. These interrelations between Consistency Rule 2: Requirements describe functionality, which models are specific to each project and are called consistency rules. is realized by business logic written in Java. Since the manager If all consistency rules are fulfilled, the models are consistent to wants to know, which requirements are already fulfilled in Java, each other. Therefore, the goal of this paper is to depict an approach requirements should be linkable with Java methods. Requirements that ensures model consistency for arbitrary models conforming to and sourcecode are consistent to each other, if (at least) each re- arbitrary, but appropriate metamodels, by using an integrated data quirement is linked with all methods whos names are contained in structure containing all information of all models. the text of the requirement. As ongoing example throughout this paper (the transferability Up to now, the required consistency assurance is often done is discussed in Section 4.3), a strongly simplified software develop- with hand-written glue transformations or even manually. In the ment project environment is depicted: Requirements are described latter case, even the consistency rules are not made explicit, which textually. The design is developed by class diagrams, while the causes potential misunderstandings between users and introduces sourcecode is written in Java. These three languages are supported new inconsistencies. Therefore, an elaborated approach is required by three different tools and result in three technically separated to ensure consistency automatically between technically separated models and metamodels. Figure 1 shows three simplified meta- models and will be presented in Section 3. As preparation, there models for the ongoing example. Requirements are depicted by are the following four main challenges to overcome for model con- a set of Requirements with an id and its requirements sentence sistency approaches, which are used for the design of the new stored in text (top left). Class diagrams contain Classes with their approach of Section 3 and form its main characteristics: classNames and Associations which are unidirectional, have a Formalize Consistency Rules (Challenge 1): All consistency role name and point to one class as type (top right). Java sourcecode rules have to be specified explicitly and formally. This is required depict ClassTypes representing classes with name and containing for the automation of consistency assurance. This formalization has Methods with name and calling-calledBy-relationship (bottom). to be done on metamodel level to support all conforming models. projectional synthetic This is done by a stakeholder called methodologist who knows the OSM Vitruvius current project like the ongoing software development example 1. Formalize Consistency Rules yes yes yes with its consistency rules and who has modeling experience [1]. 2. Create explicit SUM(M) no explicit virtual Create explicit SUM(M) (Challenge 2): An integrated model 3a. Reuse initial Models yes no yes and conforming integrated metamodel describing all information 3b. Fix initial Inconsistencies yes – no 3c. Consistent initial Models yes – yes of all initial and independent models has to be developed. This inte- 4. Ensure Model Consistency yes yes yes grated model is called Single Underlying Model (SUM) [1] conform- ing to the Single Underlying MetaModel (SUMM). Since overlapping Figure 2: Comparison of Model Consistency Approaches models describe information twice, which leads to inconsistencies easily, the SUM contains such information only once without pos- Projectional approaches introduce a new data structure contain- sibility for inconsistencies and can be used as single point-of-truth. ing all information of all models (Challenge 2), which is used to SUMs are helpful for analyses, refactorings, and visualizations tar- synchronize all models only with this integrated data structure geting information from more than one initial model. (Challenge 4). Additional to the reduced amount of consistency Support initial (Meta)Models (Challenge 3): Reusing existing rules between (meta)models, another benefit of projectional ap- models and conforming metamodels is the normal case, since there proaches is the integrated data structure, which allows analyses, are already lots of metamodels for domain specific languages and refactorings, and visualizations using all information of all models legacy models. In particular, already existing models have to be in an integrated manner (Challenge 2). reused in ongoing projects, which requires follow-up challenges: The Orthographic Software Modeling (OSM) approach [1] intro- Reuse initial Models (Challenge 3a): Initially, these models duced the idea of a Single Underlying Model (SUM) conforming to a have to be imported into the new SUM. Single Underlying MetaModel (SUMM) which contains all informa- Fix initial Inconsistencies (Challenge 3b): Since these initial tion of the current project without any redundancies (Challenge 2). models are synchronized by hand or even not synchronized at all, Users change the SUM not directly but through views which are they can contain inconsistencies, which have to be fixed. subsets of the SUM and which correspond to the initial models to Consistent initial Models (Challenge 3c): Since existing tools integrate in this paper. Since OSM is a top-down approach starting and environments work only with these initial (meta)models due with the development of the SUMM with high quality, initial models to missing tool interoperability, they have to be kept up-to-date are not supported (Challenge 3). Therefore, there is no distinction and should be changable, as discussed in the next challenge. between initial views and newly created views. Ensure Model Consistency after User Changes (Challenge 4): The Vitruvius approach [6] follows the SUM idea, where users If users, who work with the initial models or the SUM, change change the initial views, but realizes the model consistency inter- something, these changes have to be propagated to all other models nally by a modular SUM which keeps the models separated and to keep them consistent to the changed model. Additionally, these which are synchronized (Challenge 4) by an own language for con- user changes can lead to inconsistent models afterwards, which sistency rules (Challenge 1). Since this language needs consistent have to be fixed according to the consistency rules. As result, all models as precondition, there is no build-in support to fix initial in- models reflect the changes of the users, are consistent to each other consistencies (Challenge 3b). In the end, the SUM exists only virtual and fulfill all consistency rules. and is not usable (Challenge 2). New views containing information Contribution of this paper is the description of a new approach of several initial views are defined with ModelJoin [2]. ensuring model consistency regarding explicit consistency rules, Figure 2 summarizes the main characteristics of the mentioned supporting initial (meta)models, and providing an integrated (meta) approaches. Since OSM does not support initial separated mod- model. Section 2 discusses advantages and disadvantages of existing els, while Vitruvius and all synthetic approaches have no explicit model consistency approaches along the challenges. Section 3 de- SUMs, which are helpful for analyses, refactorings, and visualiza- scribes the new approach, which is applied to the ongoing example tions targeting information from more than only one model, this with discussion in Section 4 and summarized in Section 5. paper describes a new projectional approach with explicit SUM and support for the initial models, presented in Section 3. This includes fixes of inconsistencies in the initial models (Challenge 3b) shown 2 RELATED WORK in Section 3.2 and support for changing the SUM directly by users in contrast to OSM and Vitruvius depicted in Section 3.3. Following ISO Standard for Architecture Description 42010:2011 [5], model synchronization approaches are split into synthetic and pro- 3 METAMODEL INTEGRATION jectional approaches. Synthetic approaches keep the models sep- The new approach of this paper follows the idea of having a pro- arated from each other and introduce pair-wise transformations jectional and explicit SUM [1] (Challenge 2) which takes the initial between them to ensure consistency between them. Therefore, models into account (Challenge 3). The main challenges, motivated initial models can be supported easily (Challenge 3), but no inte- in Section 1, are fulfilled by this new approach, which will be pre- grated model is used (Challenge 2). The transformations are the sented along three use cases applying this approach to the ongoing formalization of consistency rules (Challenge 1) and ensure model example. This approach is operator-based, since operators are used consistency (Challenge 4). Here, several approaches exist using dif- to describe transformations between the initial models and the SUM ferent transformation techniques like Triple Graph Grammars [12] (Use Case 1). Chains of operators are executed to initialize the SUM or QVT-R [11], or using explicit correspondences [3]. (Use Case 2) and to keep all initial models and the SUM consistent Java ClassDiagram 2x Requirements 1 2 3 5 6 SUM(M) Add As- Change Merge Classes Merge At- sociation Multiplicity tributes Figure 3: Chain of configured Operators for integrating Requirements, Class Diagrams, and Sourcecode to each other (Use Case 3). Operators split long transformations duplicated instances representing the same data classes and pre- into clear and manageable steps or mini transformations, which vents inconsistencies in the SUM. After applying the last operator allows for iterative development and simplifies debugging, because MergeAttributes, the final SUMM is available in Figure 8. the models before and after have to be consistent. As shown in detail later, the SUMM can be developed and improved step by step. Metamodel Decisions Model Decisions Additionally, the consistency rules can be assigned explicitly to MM MM’ single operators and are therefore distinguished from each other. Operator 3.1 Use Case 1: Configuration of Operators The challenges overcome by this first use case are the formalization M M’ of consistency rules (Challenge 1) and the bottom-up definition of the SUMM (Challenge 2). Therefore, preconditions for this use case Figure 4: Signature of Operators are the initial metamodels and the consistency rules. Initial meta- models are reused as starting points. After that, the methodologist To support this, the used operators have the following five char- selects step-wisely special operators which are provided by the acteristics, depicted along the signature of operators in Figure 4. approach, and applies them to the current metamodel to form an To create a new association into the metamodel for the first con- improved metamodel. After selecting and configuring enough oper- sistency rule along the operator AddAssociation 1 → 2 , each ators, the current metamodel is used as final SUMM (Challenge 2). operator executes a small (1) change in the metamodel on the A possible chain of configured operators for the example is given input metamodel MM and changes it in-place with MM ′ as shown in Figure 3: Starting with the metamodels for Requirements result. Thus the initial metamodels are changed step by step along and Java , the first step is to include the two metamodels 1 . This the operator chain resulting finally in the SUMM. is done only for technical reasons and results in a new container Since initial models should be reused and transferred into the class ProjectData, but changed nothing regarding the contentwise SUM (Challenge 3a), additional (2) changes in the model are integration. The same counts for ClassDiagram included at 3 . Op- required to migrate the input model M in-place into the output erators are selected and configured, which are denoted along the model M ′ . These model changes keep the model conform to the edges of the operator chain and introduce 2 , 5 , and 6 . Each sign changed metamodel and solve the model-co-evolution problem. i describes one stable and consistent metamodel with one con- Additionally, these model changes reflect the consistency rules. As forming model, which is created by executing all previous operators example, the operator AddAssociation has to do nothing regarding starting with the initial metamodels. model-co-evolution, but could create links following consistency The methodologist selected the operator AddAssociation 1 → 2 rules 1 → 2 (discussed later). These two characteristics are the to fulfill the second consistency rule (Section 1), which requires same as in coupled operators introduced in [4]. to link requirements and methods fulfilling them. Since links are Since theses operators should be provided as library by the ap- represented by an association on metamodel level, which is missing proach and reused by methodologists for arbitrary projects, the in the initial metamodels (Figure 1), a new association between operators are designed in generic way to work with arbitrary meta- Requirement and Method has to be created. This new association models and models. Therefore, they provide (3) metamodel deci- is drawn in red in the final SUMM in Figure 8. Conforming to the sions which describes the metamodel changes in more detail. The consistency rule, on model level links have to be created between operator AddAssociation provides metamodel decisions to control each requirement and that methods whose names are contained in source and target class of the new association together with wanted the text of the requirement. role names and multiplicities. In the example for the second con- The operator ChangeMultiplicity is applied twice 5 ( 4 is sistency rule, the methodologist configures AddAssociation with hidden because of space) which change the multiplicities for the as- Requirement as source class and Method as target class ( 1 → 2 ). sociations asg and diagram (red in Figure 8). They change nothing The (4) model decisions describe, how the corresponding change in the model and provide the basis for the next operator. on model level look like in detail regarding degrees of freedom dur- The methodologist selected the operator MergeClasses 5 → 6 ing model-co-evolution and consistency rules. Here in the strongly to fulfill the first consistency rule (Section 1), which requires the simplified example, a link should be created automatically between same set of data classes described by class diagrams and in Java. one requirement and one method, if the name of the method is Since data classes are described by two different classes (ClassType contained in the text of the requirement. Therefore, the method- and Class), in the SUMM only one class should be used (ClassType, ologist adds a model decision to AddAssociation 1 → 2 which marked red in Figure 8). Doing the same on model level unifies checks all methods and links them with requirements according to this consistency rule. While the metamodel decisions are also used rules. Therefore, preconditions for this use case are the initial models in [4], the model decisions are newly introduced in this approach. and the operator chain (Section 3.1). Since this is done automatically, Both decisions allow the methodologist to create individual con- this use case is started by either the methodologist or users. figurations fulfilling the specific consistency rules of the current For creating the SUM reusing the initial models, the config- project, while the operators are designed in general only once. ured operators are executed in forward direction one after an- The last characteristic, (5) bidirectionality is required to keep other, in the order shown in Figure 3. The edges without oper- the initial models up-to-date (Challenge 3c): Up to now, the oper- ator names include the additional model into the current model ators are configured by the methodologist, while these operators technically. The contentwise integration is done using the opera- are executed later to keep all models consistent to each other (Sec- tors AddAssociation 2 which adds links between requirements tions 3.2, 3.3). While the operator chain of Figure 3 shows, how the and Java methods (more details in Section 3.3), MergeClasses and initial (meta)models are transferred into the SUM(M), also changes MergeAttributes, which are described in more detail later. The in the SUM has to be propagated into the initial models. final SUM is reached after executing all operators and conforms to To support this “backward direction”, bidirectionality is required the SUMM depicted in Figure 8. Since all information of all initial for all operators, which is realized by supplemented each operator models are stored in the explicit SUM, the initial models can be by an inverse operator. As example, AddAssociation is supple- thrown away, because they are reconstructable always out of the mented by the operator DeleteAssociation which removes one SUM, or can be kept for performance issues. configurable association from the current metamodel and removes The other challenge, fixing inconsistencies within the initial mod- all links conforming to this association from the current model. els following the consistency rules, is fulfilled during the execution After executing one operator and then its inverse operator, the of operators and will be described using the operator MergeClasses current metamodel should be the same as before both executions. 5 → 6 , whose changes are depicted in Figure 6: The input for An inverse operator is always configured together with its forward MergeClasses (top left) has the data classes “University” and “Stu- operator. This bidirectionality is requested only for the metamodel, dent” of the current software development project in the Java source- but not for the model to allow repairing model inconsistencies, as code (column “Java”, ClassType), but only “University” as part described in Section 3.2 in more detail. Regarding these five char- of the class diagram (column “ClassDiagram”, Class). Therefore “Student” is missing in the class diagram and should be fixed re- Name Description garding the consistency rule, that class diagram and sourcecode Add / Del. Add/DeleteClass creates / deletes a class Add/DeleteAssociation creates / deletes an association should contain the same data classes (Section 1). This inconsistency Add/DeleteAttribute creates / deletes an attribute is solved in the output of MergeClasses (column “SUM(M)”, top RenameClassifier renames a class “Model Changes”), because there is no distinction between data RenameFeature renames an association or attribute classes in class diagrams and sourcecode any more. Therefore, the Change ChangeAttributeType exchanges the type of an attribute ChangeMultiplicity changes the multiplicity of an attribute or output model contains only two objects, one for “University” and association another one for “Student”, since the model decisions specified, that MakeClass(Non)Abstract adds / removes abstract to / from a class Merge/SplitClasses merges two classes into one / splits one University : ClassType and University : Class describe class into two the same information and should be merged. Since the resulting Refactoring Merge/SplitAssociations merges two associations into one / splits one association into two model contains now the name of the class twice in the slots name Merge/SplitAttributes merges two attributes into one / splits one and className, this duplicated information is removed using the attribute into two operator MergeAttributes 6 → 7 (details skipped). This is done Extract/InlineSubClass extracts /inlines a sub-class during the execution in forward direction to create the SUM. To solve this inconsistency also in the initial models, the complete Figure 5: Current Set of Operators operator chain is executed in backward direction from SUM to all initial models using the inverse operators afterwards: Now, the acteristics, the approach provides several operators. The currently inverse operator SplitClass (bottom part of Figure 6) takes the available operators are depicted in Figure 5 and are still increasing. current model stemming from the SUM as input (bottom right) Summarizing, in this use case the methodologist specifies by and produces the output (bottom left). This output now contains configuring operators, how the SUMM is created out of the initial “University” and “Student”, both for the sourcecode and the class metamodels. Thereby, the consistency rules for the current project diagram, because the methodologist specified for the model decision are specified explicitly within the decisions of the used operators. of SplitClass, that each input data class should be used both in The result is a chain of configured operators in form of a tree, as class diagram and sourcecode. Therefore, the additional object is shown exemplary in Figure 3. Therefore, postconditions for this created (marked in red in Figure 6) and makes the model consistent. use case are having the operator chain containing the formalized In general, inconsistencies are fixed during the model-co-evolution consistency rules, and the derived SUMM. following the consistency rules, which are specified within the model decisions by the methodologist. These fixes of inconsisten- 3.2 Use Case 2: Initialization of SUM cies are possible, because bidirectionaly is requested only for meta- The challenges overcome by this second use case are to create the models, but not for models (Section 3.1). Therefore, postconditions SUM (Challenge 2) reusing the initial models (Challenge 3a) and to for this use case are having the fixed initial models and the newly fix inconsistencies within the initial models (Challenge 3b), both corresponding to the operator chain containing the consistency Java ClassDiagram SUM(M) Metamodel Changes ClassType Class ClassType className : String name : String name : String Forward Execution className : String to create the SUM Merge Classes : ClassType : Class : ClassType name = “University” className = “University” name = “University” Changes Model className = “University” inverse to each other : ClassType : ClassType name = “Student” name = “Student” className = : ClassType : Class : ClassType name = “University” className = “University” name = “University” Changes to fix the initial Models Model className = “University” Backward Execution : ClassType : ClassType : Class name = “Student” name = “Student” className = “Student” className = “Student” Split Class Metamodel Changes ClassType Class ClassType className : String name : String name : String className : String Figure 6: Operator MergeClasses 5 → 6 fixes Inconsistencies during the Initialization created SUM. After executing these first two use cases only once, them in the SUMM (right column “SUM(M)”, marked in red) on the users change the SUM and the models often in the last use case. metamodel level (row “Metamodel Changes”). In the model (row “Model Changes”), one link between requirement R1 and method 3.3 Use Case 3: Consistency Assurance M1 is created in the SUM due to the keyword “register” (marked in After configuration (Section 3.1) and initialization (Section 3.2) red in row “1. Initialization”). Now the user does two changes the of the SUM once, this use case is triggered by users who change SUM (depicted in row “2. Run” and column “SUM(M)”, in red), with one of the models or the SUM itself, which might introduce new following expected impacts due to the consistency rule: inconsistencies in both cases. Therefore, the challenges overcome 1. The user creates a new and additional link between re- by this third use case are to propagate the changes into all other quirement R2 and method M2 in the SUM. Since these links models and to fix new inconsistencies according to the operator conform to the new association which exists only in the SUM, no chain and its consistency rules (Challenge 4). This includes the SUM changes will appear the initial models for Java and Requirements . as well as all initial models to keep them up-to-date (Challenge 3c). 2. The user renames the method M1 from “register” to “en- Preconditions for this use case are current versions of initial models role” in the SUM. Since Methods are part of the initial model for and SUM and the operator chain. Java , the method should be renamed also in this initial model (col- The user changes are propagated into the SUM and all other umn “Java”, marked in red). To realize that, the operator chain has to models automatically by executing the chain of operators. This be executed in backward direction, here with the inverse operator execution is done in both directions, because all operators including DeleteAssociation. According to the consistency rule inside the inverse operators can have model decisions which ensure model model decision of AddAssociation, the SUM should be enriched consistency. Since changes in the initial models can be mapped to by a link between requirement R2 and the renamed method M1 due changes in the SUM by executing the operators between this model to the “enrole” keyword (row “3. Run”, column “SUM(M)”, marked and the SUM, only the case of changes in the SUM is discussed here. in red). At the same time, the existing link between R1 and M1 Since the SUM provides all information of all initial models in an has to be deleted in the SUM , since there is no match regarding integrated way, the SUM itself form a model which can be seen as the methods name anymore. To realize that, the operator chain is new view containing all information and which can be changed by executed again in forward direction, now using AddAssociation. users as they are changing the initial models. In general, to handle changes in the SUM, the operator chain has The ideas of this model change propagation are depicted along to be executed in backward direction using the inverse operators the operator AddAssociation 1 → 2 and Figure 7. Fulfilling the to update the initial model. Since also the operators in forward consistency rule, that methods should be linked with requirements, direction realize consistency rules, the operator chain has to be if the text of the requirement contains the name of the method, executed in forward direction afterwards. This rises the problem the execution of AddAssociation during the initialization (Sec- not to loose information, which is persisted only in the SUM, but not in tion 3.2) integrates Requirements (left column “Requirements”) the initial models: An example is the manually added link between and Methods (column “Java”) by adding a new association between R2 and M2. During the 2. Run, it is deleted by DeleteAssociation. Requirements Java SUM(M) Metamodel Changes Requirement Method Requirement fulfilled ∗ Method text : String name : String text : String ∗ fulfilledBy name : String Add 1. Initialization (forward) Association R1 : Requirement M1 : Method R1 : Requirement fulfilled M1 : Method text = “. . . register . . . ” name = “register” text = “. . . register . . . ” name = “register” fulfilledBy each other inverse to R2 : Requirement M2 : Method R2 : Requirement M2 : Method text = “. . . enrole . . . ” name = “start” text = “. . . enrole . . . ” name = “start” 1. Create Link between R2 “enrole” and M2 “start” 2. Rename Method M1 from “register” to “enrole” ∆User 2. Run (backward) R1 : Requirement M1 : Method R1 : Requirement fulfilled M1 : Method Changes Model text = “. . . register . . . ” name = “enrole” text = “. . . register . . . ” name = “enrole” fulfilledBy Delete Association R2 : Requirement M2 : Method R2 : Requirement fulfilled M2 : Method text = “. . . enrole . . . ” name = “start” text = “. . . enrole . . . ” fulfilledBy name = “start” each other inverse to 3. Run (forward) R1 : Requirement M1 : Method R1 : Requirement M1 : Method text = “. . . register . . . ” name = “enrole” text = “. . . register . . . ” name = “enrole” Add d dBy lle lle lfi lfi Association fu fu R2 : Requirement M2 : Method R2 : Requirement fulfilled M2 : Method text = “. . . enrole . . . ” name = “start” text = “. . . enrole . . . ” fulfilledBy name = “start” Figure 7: Operator AddAssociation 1 → 2 ensures Model Consistency during Consistency Assurance During the 3. Run, is is not recreated directly, since this link does the old creation of that link between R1 and M1 leads now to a not base on a keyword triggering the consistency rule and is not deletion of that inconsistent link. contained within the initial models. To solve this problem, missing In general, after executing the operator, adding missing infor- information which is stored only in the SUM and not in the current mation and reverting previous changes which are invalid now, the model has to be added again. This missing information is calculated resulting model is consistent and complete, so that the next opera- by comparing the model differences which are recorded during tor can be executed. Since the SUM contains all information, the the previous execution of DeleteAssociation (2. Run) and the step to add missing information is required only on the way from current execution of AddAssociation (3. Run). In the example, models to the SUM. In the end, postconditions for this use case are this recreates the link between requirement R2 and method M2, updated versions of initial models and the SUM. which was added manually to the SUM and was temporary gone. Additionally, it also recreates the link between R1 and M1, which 4 APPLICATION should be deleted, since it was introduced automatically basing on To solve the motivated consistency problems in the ongoing soft- the keyword “register”, which was changed to “enrole” now. This ware development example, the methodologist selected and con- problem is caused by the design of the operators to work with com- figured the operators depicted in Figure 3 according to Section 3.1. plete models and not only with model differences, which is required Linking requirements and methods with each other is supported for the initial creation and clean-up of the SUM (Section 3.2). That by the operator AddAssociation 1 → 2 , as described in more means, the operators react only on existing and added information, detail in Section 3.3. Since the two meta-classes describing data but not on changed and removed information. To solve this prob- classes are merged by the operator MergeClasses 5 → 6 (detail lem, the execution of operators is more complex as suggested up in Section 3.2), possible inconsistencies between class diagram and to now: After executing AddAssociation the second time (row “3. sourcecode are fixed. Additionally, this prevents new inconsisten- Run”) and recreating missing information (see paragraph before), cies in the SUM, because this information is stored only once. the model differences of the current execution of AddAssociation The resulting SUMM is shown in Figure 8 and represents the (3. Run) are compared with the model differences of the previous complete content of the three initial metamodels shown in Fig- execution of AddAssociation (1. Initialization). Changes of the ure 1. Additionally, it contains the new association between Method previous run of this operator in this direction which are not created and Requirement, and the two classes umlclasses.Class and again by the current run of this operator, are not valid any more. asgjava.Class are merged into data.ClassType which repre- Therefore, these differences have to be inverted. For this example, sents now data classes both in sourcecode and class diagrams. data Requirement ProjectData +rowNumber : EInt[0..1] +id : EString[0..1] integrator[0..1] +author : EString[0..1] +text : EString[0..1] integrator[0..1] integrator[0..1] fulflled[*] content[*] fulflledBy[*] containsJavaASG[*] containsDiagrams[*] container[1] containsRequirements[*] Association calledBy[*] Method +name : EString[1] JavaASG ClassDiagram RequirementsSpecifcation +lowerBound : EInt[0..1] +name : EString[1] usedBy[*] methods[*] calling[*] +upperBound : EInt[0..1] asg[0..1] diagram[0..1] associations[*] classes[*] type[1] classes[*] ClassType class[1] class[1] +name : EString[1] Figure 8: Single Underlying MetaModel (SUMM) integrating Requirements, Class Diagrams and Sourcecode Now the user can change the models for Requirements , Java Requirements , Java and ClassDiagram as well as of the SUMM and ClassDiagram as well as the SUM : The SUM and all models could change [9]. The methodologist handles this evolution of the will be updated and possible inconsistencies will be fixed according metamodels by updating the existing operator chain accordingly. to Section 3.3, like discussed along Figure 7. Reasons for changes in the SUMM can be fixes for found bugs, refactorings or new information to store. As before, where the 4.1 New Viewpoints SUMM was created bottom-up in step-wise way by applying oper- If the user want to change information which is new in the SUM ators, these changes can be realized by selecting and configuring and represented in none of the initial models, he has to change additional operators. Finally, the methodologist describes with oper- the SUM directly. Although that is possible as shown, it is not ators the relationship SUMM ←→ SUMM’ , resulting in an explicit very feasible, since the SUM contains all information and not only SUMM’ and further consistency rules. the information the user is interested in. As example, the links Changes in the metamodels of the initial artifacts arise because between requirements and methods are neither contained in the of updates of the tools providing these metamodels or because requirements model nor in the Java model, but only in the SUM. of new versions for Java or UML. The realization effort for the Since the SUM contain also all information about classes and class methodologist depends on the amount of changes and its impact on diagrams, which are not required here, the user wants to use a new already integrated structures: If the changes contain only additional view like exemplary depicted in Figure 9: It lists all requirements elements in the metamodel without any additional consistency rules, the current operator chain stays the same. If the changes can be mapped to the old version of the metamodel, the methodologist can describe this mapping by additional operators, for example Java’ ←→ Java . More advanced changes require changes of the configured operator chain, which means in the worst case, that the Figure 9: New View to manage Requirement-Method-Links complete integration has to be specified again. together with their linked methods as subset of the SUM. Now, 4.3 Transferability users can easily change links between requirements and methods. The approach was demonstrated using only one simplified example Therefore, new viewpoints have to be specified by the methodol- stemming from a software development project. This section dis- ogist showing parts of the SUMM, in particular, information stem- cusses, why the complete approach is transferable to other software ming from more than one initial model. This new viewpoint is development projects and even to other application domains. specified again by selecting and configuring some more operators Different software development projects will have different con- on top of the SUMM, which defines an additional chain of opera- sistency rules or different initial metamodels. This issue is handled tors to describe SUM(M) ←→ New View(Point) . The same set of by the methodologist, who specifies different chains of configured operators can be reused and configured according to the concerns operators for different projects, with different SUMMs as result. for the viewpoints here again. The users change the corresponding The model decisions are substantiated regarding project-specific new views and the changes are synchronized with the SUM and all consistency rules. As example, in another project with the same set other models by executing the operators (Section 3.3). of initial metamodels as in the ongoing example, no links between requirements and methods should be created automatically 1 → 2 : 4.2 Evolution of Metamodels Then the methodologist specifies the corresponding model decision Up to now, only the evolution of models by user changes was to create no links automatically. As contrast, arbitrary complex al- discussed roughly in Section 3.3. Additionally, the metamodels of gorithms stemming from research of the requirements community can be included into model decisions. Another case, same consis- SUMMs for the users. This is another example, where the generic tency rules with slightly different initial metamodels, is discussed operators can be reused and applied even to different levels on in Section 4.4. abstraction. Other application scenarios are traceability issues, solvable by this approach [10]: Traceability links between, for example, meth- 5 CONCLUSION ods and requirements can be stored and maintained within the SUM To ensure the consistency of technical independent and separated by new associations, introduced by operators like AddAssociation. models conforming to different metamodels, which are overlapping The approach is intended to work even in application domains and have relations to each other contentwise, a new bottom-up outside of software development. This is possible, since the op- approach was depicted in this paper. The central idea is to create a erators to specify the integration are independent from concrete Single Underlying (Meta)Model containing all information of all ini- metamodels, because the metamodel decisions of the operators are tial (meta)models as single point-of-truth. Additionally, the initial designed to be generic for reuse and to be substantiated regarding (meta)models are not thrown away, but migrated to projectional the predefined degrees of freedom. Therefore, precondition for the view(points) on this SUM(M) and kept up-to-date. This is reached approach are not specific application domains, but the representa- by introducing operators which, formed as chain, define, how the tion of artifacts in form of models and conforming metamodels. This SUMM is created out of the initial metamodels, and which executes technical issue can be overcome by developing adapters realizing transformations to ensure consistency between all initial models the transformation of artifacts into models and vice-versa. and the SUM. Since these operators are generic regarding meta- model and model changes and support arbitrary consistency rules 4.4 Integration on Reference Level explicitly, these operators are reusable for new viewpoints on top of the SUMM, for integrations on reference level and for ensuring The example integrates requirements and Java by supporting links model consistency in different application domains. between Java methods and textual requirements. If another project A prototypical framework to support this approach for model uses C++ instead of Java with the same consistency rules, the result consistency ensured by metamodel integration is currently under is the same operator chain like in Figure 3, but with C++ instead development with Java, ECore as language to describe metamodels, of Java , since the current integration uses Java methods and not reuse of parts of the model migration structure of Eclipse EDapt C++ methods. Now the methodologist spends again effort to realize and extension of coupled operators described by [4]. Currently, the the same consistency rules for similar models. configuration of the operator chain is supported by a Java API and Instead of integrating concrete Java methods or C++ methods, model decisions are implemented in Java. In future work, both steps Java methods and C++ methods are shifted to “reference” methods could be supported by domain specific languages. representing methods written in arbitrary programming languages. Instead of using concrete metamodels (CMM) for Java or C++, a REFERENCES reference metamodel (RMM) describing object-oriented general [1] Colin Atkinson, Dietmar Stoll, and Philipp Bostan. 2009. Supporting View-Based purpose programming languages is required. An example reference Development through Orthographic Software Modeling. Evaluation of Novel metamodel is the Dagstuhl Middle Model [7], because it describes Approaches to Software Engineering (ENASE) (2009), 71–86. [2] Erik Burger, Jörg Henss, Martin Küster, Steffen Kruse, and Lucia Happe. 2014. only essential elements like packages, classes and methods, but View-based model-driven software development with ModelJoin. Software & ignores specific aspects like pointer handling. Systems Modeling (2014). Instead of integrating concrete metamodels (CMM) into the [3] Mahmoud El Hamlaoui, Sophie Ebersold, Bernard Coulette, Mahmoud Nassar, and Adil Anwar. 2014. Heterogeneous models matching for consistency management. SUMM like in Figure 3, reference metamodels (RMM) are integrated In 2014 Int. Conf. on Research Challenges in Information Science. IEEE, 1–12. into a Reference SUMM (RSUMM) using operators, resulting in a [4] Markus Herrmannsdoerfer, Sander D. Vermolen, and Guido Wachsmuth. 2011. An Extensive Catalog of Operators for the Coupled Evolution of Metamodels similar operator chain. Instead of linking textual requirements with and Models. Software Language Engineering LNCS 6563 (2011), 163–182. Java methods, now arbitrary requirements are linked with methods [5] IEEE. 2011. ISO/IEC/IEEE 42010:2011 - Systems and software engineering - of arbitrary programming languages. The methodologist describes Architecture description. 2011, March (2011), 1–46. [6] Max E Kramer, Erik Burger, and Michael Langhammer. 2013. View-centric the required mappings CMM ←→ RMM again by configuring op- engineering with synchronized heterogeneous models. 1st VAO (2013), 1–6. erator chains with the CMM like Java as starting point and the [7] Timothy C. Lethbridge, Sander Tichelaar, and Erhard Ploedereder. 2004. The RMM like the Dagstuhl Middle Model as end point. Dagstuhl Middle Metamodel: A schema for reverse engineering. Electronic Notes in Theoretical Computer Science 94, 1 (2004), 7–18. To get the SUMM , for each RMM one mapped CMM is selected. [8] Johannes Meier and Andreas Winter. 2016. Towards Metamodel Integration Since the integration of the RSUMM is defined on reference level Using Reference Metamodels. 4th Workshop VAO (2016), 19–22. [9] Johannes Meier and Andreas Winter. 2018. Towards Evolution Scenarios of using the RMM, the integration is executable again using the map- Integrated Software Artifacts. Softwaretechnik-Trends 38, 2 (2018), 63–64. ping between CMM and RMM and the wanted SUMM is created [10] Johannes Meier and Andreas Winter. 2018. Traceability enabled by Metamodel automatically together with its consistency rules. Integration. Softwaretechnik-Trends 38, 1 (2018), 21–26. [11] J. R. Romero, Juan Ignacio Jaén, and Antonio Vallecillo. 2009. Realizing corre- In general, for similar integration projects, the integration should spondences in multi-viewpoint specifications. EDOC 2009 (2009), 163–172. be done once on reference level using reference metamodels and [12] Andy Schürr and Felix Klar. 2008. 15 Years of triple graph grammars: Research not on concrete level using concrete metamodels as before. There- challenges, new contributions, open problems. LNCS 5214 (2008), 411–425. fore, the integration on reference level eases the configuration of SUMMs for the methodologist compared to Section 3.1 [8], while their use for initializing the SUM (Section 3.2) and for ensuring model consistency (Section 3.3) is the same as for regularly created