To keep semantically interrelated and physically separated artifacts consistent to each other is challenging. Consistency between such artifacts, described by models and conforming to metamodels, targets mainly synchronizing overlapping information and additional relations between them. This paper depicts an approach to synchronize models by integrating models together with their metamodels into an integrated (meta)model using special operators. These operators are used to keep all models consistent to each other, which is discussed for two consistency rules along three use cases.
JavaASG
RequirementsSpecifcation
container[
ClassType
+name
classes[*]
class[
Requirement
+rowNumber
+id
+author
+text
associations[*]
class[
Association
usedBy[*]
type[
Class ClassDiagram
In modern software systems the heterogeneity of languages describing certain aspects of systems grows. This includes models, domain specific languages for diferent but overlapping concerns, and data produced by tools in arbitrary data formats. All these languages produce data, which are often separated technically from each other by diferent data formats, diferent technical spaces, or diferent tools, because of historical growth, or diferent users with diferent working locations, concerns or access rights. In this paper, all artifacts are described by models and conforming metamodels.
These technical separations rise issues, if these models describe information which are interrelated contentwise: If two models are overlapping and describe the same information, this information has to be kept consistent to each other. If two models describe diferent information which are related to each other, these relations have to be described, changed and stored. These interrelations between models are specific to each project and are called consistency rules. If all consistency rules are fulfilled, the models are consistent to each other. Therefore, the goal of this paper is to depict an approach that ensures model consistency for arbitrary models conforming to arbitrary, but appropriate metamodels, by using an integrated data structure containing all information of all models.
As ongoing example throughout this paper (the transferability is discussed in Section 4.3), a strongly simplified software development project environment is depicted: Requirements are described textually. The design is developed by class diagrams, while the sourcecode is written in Java. These three languages are supported by three diferent tools and result in three technically separated models and metamodels. Figure 1 shows three simplified metamodels for the ongoing example. Requirements are depicted by a set of Requirements with an id and its requirements sentence stored in text (top left). Class diagrams contain Classes with their classNames and Associations which are unidirectional, have a role name and point to one class as type (top right). Java sourcecode depict ClassTypes representing classes with name and containing Methods with name and calling-calledBy-relationship (bottom). methods[*] +name
Method calledBy[*] calling[*] Since these three models describe three diferent concerns originating in diferent tools within the same project, there are the following two illustrative consistency rules:
Consistency Rule 1: Data classes are described by class diagrams as well as by Java: If an instance of asgjava.ClassType has the same value for name like an instance of umlclasses.Class for className, these two instances describe the same information and should be renamed in parallel. Sourcecode and class diagram are consistent to each other, if they describe the same set of data classes, identified by their class names.
Consistency Rule 2: Requirements describe functionality, which is realized by business logic written in Java. Since the manager wants to know, which requirements are already fulfilled in Java, requirements should be linkable with Java methods. Requirements and sourcecode are consistent to each other, if (at least) each requirement is linked with all methods whos names are contained in the text of the requirement.
Up to now, the required consistency assurance is often done with hand-written glue transformations or even manually. In the latter case, even the consistency rules are not made explicit, which causes potential misunderstandings between users and introduces new inconsistencies. Therefore, an elaborated approach is required to ensure consistency automatically between technically separated models and will be presented in Section 3. As preparation, there are the following four main challenges to overcome for model consistency approaches, which are used for the design of the new approach of Section 3 and form its main characteristics:
Formalize Consistency Rules (Challenge 1): All consistency
rules have to be specified explicitly and formally. This is required
for the automation of consistency assurance. This formalization has
to be done on metamodel level to support all conforming models.
This is done by a stakeholder called methodologist who knows the
current project like the ongoing software development example
with its consistency rules and who has modeling experience [
Create explicit SUM(M) (Challenge 2): An integrated model
and conforming integrated metamodel describing all information
of all initial and independent models has to be developed. This
integrated model is called Single Underlying Model (SUM) [
Support initial (Meta)Models (Challenge 3): Reusing existing models and conforming metamodels is the normal case, since there are already lots of metamodels for domain specific languages and legacy models. In particular, already existing models have to be reused in ongoing projects, which requires follow-up challenges:
Reuse initial Models (Challenge 3a): Initially, these models have to be imported into the new SUM.
Fix initial Inconsistencies (Challenge 3b): Since these initial models are synchronized by hand or even not synchronized at all, they can contain inconsistencies, which have to be fixed.
Consistent initial Models (Challenge 3c): Since existing tools and environments work only with these initial (meta)models due to missing tool interoperability, they have to be kept up-to-date and should be changable, as discussed in the next challenge.
Ensure Model Consistency after User Changes (Challenge 4): If users, who work with the initial models or the SUM, change something, these changes have to be propagated to all other models to keep them consistent to the changed model. Additionally, these user changes can lead to inconsistent models afterwards, which have to be fixed according to the consistency rules. As result, all models reflect the changes of the users, are consistent to each other and fulfill all consistency rules.
Contribution of this paper is the description of a new approach ensuring model consistency regarding explicit consistency rules, supporting initial (meta)models, and providing an integrated (meta) model. Section 2 discusses advantages and disadvantages of existing model consistency approaches along the challenges. Section 3 describes the new approach, which is applied to the ongoing example with discussion in Section 4 and summarized in Section 5. 2
Following ISO Standard for Architecture Description 42010:2011 [
projectional OSM Vitruvius yes yes explicit virtual no yes – no – yes yes yes Projectional approaches introduce a new data structure containing all information of all models (Challenge 2), which is used to synchronize all models only with this integrated data structure (Challenge 4). Additional to the reduced amount of consistency rules between (meta)models, another benefit of projectional approaches is the integrated data structure, which allows analyses, refactorings, and visualizations using all information of all models in an integrated manner (Challenge 2).
The Orthographic Software Modeling (OSM) approach [
The Vitruvius approach [
Figure 2 summarizes the main characteristics of the mentioned approaches. Since OSM does not support initial separated models, while Vitruvius and all synthetic approaches have no explicit SUMs, which are helpful for analyses, refactorings, and visualizations targeting information from more than only one model, this paper describes a new projectional approach with explicit SUM and support for the initial models, presented in Section 3. This includes ifxes of inconsistencies in the initial models (Challenge 3b) shown in Section 3.2 and support for changing the SUM directly by users in contrast to OSM and Vitruvius depicted in Section 3.3. 3
The new approach of this paper follows the idea of having a
projectional and explicit SUM [
Use Case 1: Configuration of Operators The challenges overcome by this first use case are the formalization of consistency rules (Challenge 1) and the bottom-up definition of the SUMM (Challenge 2). Therefore, preconditions for this use case are the initial metamodels and the consistency rules. Initial metamodels are reused as starting points. After that, the methodologist selects step-wisely special operators which are provided by the approach, and applies them to the current metamodel to form an improved metamodel. After selecting and configuring enough operators, the current metamodel is used as final SUMM (Challenge 2).
A possible chain of configured operators for the example is shown in Figure 3: Starting with the metamodels for Requirements and Java , the first step is to include the two metamodels 1 . This is done only for technical reasons and results in a new container class ProjectData, but changed nothing regarding the contentwise integration. The same counts for ClassDiagram included at 3 . Operators are selected and configured, which are denoted along the edges of the operator chain and introduce 2 , 5 , and 6 . Each sign i describes one stable and consistent metamodel with one conforming model, which is created by executing all previous operators starting with the initial metamodels.
The methodologist selected the operator AddAssociation 1 → 2 to fulfill the second consistency rule (Section 1), which requires to link requirements and methods fulfilling them. Since links are represented by an association on metamodel level, which is missing in the initial metamodels (Figure 1), a new association between Requirement and Method has to be created. This new association is drawn in red in the final SUMM in Figure 8. Conforming to the consistency rule, on model level links have to be created between each requirement and that methods whose names are contained in the text of the requirement.
The operator ChangeMultiplicity is applied twice 5 ( 4 is hidden because of space) which change the multiplicities for the associations asg and diagram (red in Figure 8). They change nothing in the model and provide the basis for the next operator.
The methodologist selected the operator MergeClasses 5 → 6 to fulfill the first consistency rule (Section 1), which requires the same set of data classes described by class diagrams and in Java. Since data classes are described by two diferent classes ( ClassType and Class), in the SUMM only one class should be used (ClassType, marked red in Figure 8). Doing the same on model level unifies duplicated instances representing the same data classes and prevents inconsistencies in the SUM. After applying the last operator MergeAttributes, the final SUMM is available in Figure 8.
MM
M
Decisions
Operator
MM’
M’
To support this, the used operators have the following five characteristics, depicted along the signature of operators in Figure 4. To create a new association into the metamodel for the first consistency rule along the operator AddAssociation 1 → 2 , each operator executes a small (1) change in the metamodel on the given input metamodel MM and changes it in-place with MM ′ as result. Thus the initial metamodels are changed step by step along the operator chain resulting finally in the SUMM.
Since initial models should be reused and transferred into the
SUM (Challenge 3a), additional (2) changes in the model are
required to migrate the input model M in-place into the output
model M ′. These model changes keep the model conform to the
changed metamodel and solve the model-co-evolution problem.
Additionally, these model changes reflect the consistency rules. As
example, the operator AddAssociation has to do nothing regarding
model-co-evolution, but could create links following consistency
rules 1 → 2 (discussed later). These two characteristics are the
same as in coupled operators introduced in [
Since theses operators should be provided as library by the approach and reused by methodologists for arbitrary projects, the operators are designed in generic way to work with arbitrary metamodels and models. Therefore, they provide (3) metamodel decisions which describes the metamodel changes in more detail. The operator AddAssociation provides metamodel decisions to control source and target class of the new association together with wanted role names and multiplicities. In the example for the second consistency rule, the methodologist configures AddAssociation with Requirement as source class and Method as target class ( 1 → 2 ).
The (4) model decisions describe, how the corresponding change
on model level look like in detail regarding degrees of freedom
during model-co-evolution and consistency rules. Here in the strongly
simplified example, a link should be created automatically between
one requirement and one method, if the name of the method is
contained in the text of the requirement. Therefore, the
methodologist adds a model decision to AddAssociation 1 → 2 which
checks all methods and links them with requirements according to
this consistency rule. While the metamodel decisions are also used
in [
The last characteristic, (5) bidirectionality is required to keep the initial models up-to-date (Challenge 3c): Up to now, the operators are configured by the methodologist, while these operators are executed later to keep all models consistent to each other (Sections 3.2, 3.3). While the operator chain of Figure 3 shows, how the initial (meta)models are transferred into the SUM(M), also changes in the SUM has to be propagated into the initial models.
To support this “backward direction”, bidirectionality is required for all operators, which is realized by supplemented each operator by an inverse operator. As example, AddAssociation is supplemented by the operator DeleteAssociation which removes one configurable association from the current metamodel and removes all links conforming to this association from the current model. After executing one operator and then its inverse operator, the current metamodel should be the same as before both executions. An inverse operator is always configured together with its forward operator. This bidirectionality is requested only for the metamodel, but not for the model to allow repairing model inconsistencies, as described in Section 3.2 in more detail. Regarding these five char
Name .le Add/DeleteClass /D Add/DeleteAssociation dd Add/DeleteAttribute A RenameClassifier
RenameFeature eg ChangeAttributeType hn ChangeMultiplicity a C
MakeClass(Non)Abstract
Merge/SplitClasses ign Merge/SplitAssociations r o t ca Merge/SplitAttributes f e R Extract/InlineSubClass
Description creates / deletes a class creates / deletes an association creates / deletes an attribute renames a class renames an association or attribute exchanges the type of an attribute changes the multiplicity of an attribute or association adds / removes abstract to / from a class merges two classes into one / splits one class into two merges two associations into one / splits one association into two merges two attributes into one / splits one attribute into two extracts /inlines a sub-class acteristics, the approach provides several operators. The currently available operators are depicted in Figure 5 and are still increasing.
Summarizing, in this use case the methodologist specifies by configuring operators, how the SUMM is created out of the initial metamodels. Thereby, the consistency rules for the current project are specified explicitly within the decisions of the used operators. The result is a chain of configured operators in form of a tree, as shown exemplary in Figure 3. Therefore, postconditions for this use case are having the operator chain containing the formalized consistency rules, and the derived SUMM. 3.2 Use Case 2: Initialization of SUM The challenges overcome by this second use case are to create the SUM (Challenge 2) reusing the initial models (Challenge 3a) and to ifx inconsistencies within the initial models (Challenge 3b), both corresponding to the operator chain containing the consistency rules. Therefore, preconditions for this use case are the initial models and the operator chain (Section 3.1). Since this is done automatically, this use case is started by either the methodologist or users.
For creating the SUM reusing the initial models, the configured operators are executed in forward direction one after another, in the order shown in Figure 3. The edges without operator names include the additional model into the current model technically. The contentwise integration is done using the operators AddAssociation 2 which adds links between requirements and Java methods (more details in Section 3.3), MergeClasses and MergeAttributes, which are described in more detail later. The ifnal SUM is reached after executing all operators and conforms to the SUMM depicted in Figure 8. Since all information of all initial models are stored in the explicit SUM, the initial models can be thrown away, because they are reconstructable always out of the SUM, or can be kept for performance issues.
The other challenge, fixing inconsistencies within the initial models following the consistency rules, is fulfilled during the execution of operators and will be described using the operator MergeClasses 5 → 6 , whose changes are depicted in Figure 6: The input for MergeClasses (top left) has the data classes “University” and “Student” of the current software development project in the Java sourcecode (column “Java”, ClassType), but only “University” as part of the class diagram (column “ClassDiagram”, Class). Therefore “Student” is missing in the class diagram and should be fixed regarding the consistency rule, that class diagram and sourcecode should contain the same data classes (Section 1). This inconsistency is solved in the output of MergeClasses (column “SUM(M)”, top “Model Changes”), because there is no distinction between data classes in class diagrams and sourcecode any more. Therefore, the output model contains only two objects, one for “University” and another one for “Student”, since the model decisions specified, that University : ClassType and University : Class describe the same information and should be merged. Since the resulting model contains now the name of the class twice in the slots name and className, this duplicated information is removed using the operator MergeAttributes 6 → 7 (details skipped). This is done during the execution in forward direction to create the SUM.
To solve this inconsistency also in the initial models, the complete operator chain is executed in backward direction from SUM to all initial models using the inverse operators afterwards: Now, the inverse operator SplitClass (bottom part of Figure 6) takes the current model stemming from the SUM as input (bottom right) and produces the output (bottom left). This output now contains “University” and “Student”, both for the sourcecode and the class diagram, because the methodologist specified for the model decision of SplitClass, that each input data class should be used both in class diagram and sourcecode. Therefore, the additional object is created (marked in red in Figure 6) and makes the model consistent.
In general, inconsistencies are fixed during the model-co-evolution following the consistency rules, which are specified within the model decisions by the methodologist. These fixes of inconsistencies are possible, because bidirectionaly is requested only for metamodels, but not for models (Section 3.1). Therefore, postconditions for this use case are having the fixed initial models and the newly ion M trecxduE tteeahSU raw rce oF to s l iton eod ecxu liaM E it rcaakdBw iteoxfihn t
ClassType name : String
: ClassType name = “University”
: ClassType name = “Student”
: ClassType name = “University”
: ClassType name = “Student”
name : String
Class className : String
: Class className = “University” : Class className = “University” : Class className = “Student”
className : String
Merge Classes r e h t o h c a e o t e s r e v n i Split Class
ClassType name : String className : String
: ClassType name = “University” className = “University”
: ClassType name = “Student” className =
: ClassType name = “University” className = “University”
: ClassType name = “Student” className = “Student”
ClassType name : String className : String After configuration (Section 3.1) and initialization (Section 3.2) of the SUM once, this use case is triggered by users who change one of the models or the SUM itself, which might introduce new inconsistencies in both cases. Therefore, the challenges overcome by this third use case are to propagate the changes into all other models and to fix new inconsistencies according to the operator chain and its consistency rules (Challenge 4). This includes the SUM as well as all initial models to keep them up-to-date (Challenge 3c). Preconditions for this use case are current versions of initial models and SUM and the operator chain.
The user changes are propagated into the SUM and all other models automatically by executing the chain of operators. This execution is done in both directions, because all operators including inverse operators can have model decisions which ensure model consistency. Since changes in the initial models can be mapped to changes in the SUM by executing the operators between this model and the SUM, only the case of changes in the SUM is discussed here. Since the SUM provides all information of all initial models in an integrated way, the SUM itself form a model which can be seen as new view containing all information and which can be changed by users as they are changing the initial models.
The ideas of this model change propagation are depicted along the operator AddAssociation 1 → 2 and Figure 7. Fulfilling the consistency rule, that methods should be linked with requirements, if the text of the requirement contains the name of the method, the execution of AddAssociation during the initialization (Section 3.2) integrates Requirements (left column “Requirements”) and Methods (column “Java”) by adding a new association between them in the SUMM (right column “SUM(M)”, marked in red) on the metamodel level (row “Metamodel Changes”). In the model (row “Model Changes”), one link between requirement R1 and method M1 is created in the SUM due to the keyword “register” (marked in red in row “1. Initialization”). Now the user does two changes the SUM (depicted in row “2. Run” and column “SUM(M)”, in red), with following expected impacts due to the consistency rule: 1. The user creates a new and additional link between requirement R2 and method M2 in the SUM. Since these links conform to the new association which exists only in the SUM, no changes will appear the initial models for Java and Requirements .
2. The user renames the method M1 from “register” to “enrole” in the SUM. Since Methods are part of the initial model for Java , the method should be renamed also in this initial model (column “Java”, marked in red). To realize that, the operator chain has to be executed in backward direction, here with the inverse operator DeleteAssociation. According to the consistency rule inside the model decision of AddAssociation, the SUM should be enriched by a link between requirement R2 and the renamed method M1 due to the “enrole” keyword (row “3. Run”, column “SUM(M)”, marked in red). At the same time, the existing link between R1 and M1 has to be deleted in the SUM , since there is no match regarding the methods name anymore. To realize that, the operator chain is executed again in forward direction, now using AddAssociation.
In general, to handle changes in the SUM, the operator chain has to be executed in backward direction using the inverse operators to update the initial model. Since also the operators in forward direction realize consistency rules, the operator chain has to be executed in forward direction afterwards. This rises the problem not to loose information, which is persisted only in the SUM, but not in the initial models: An example is the manually added link between R2 and M2. During the 2. Run, it is deleted by DeleteAssociation. ) d r a w r o f ( n o i t a z i l a i t i n I . 1 ) d r a w k c a b ( n u R . 2 ) d r a w r o f ( n u R . 3
text : String
text = “. . . register . . . ”
text = “. . . enrole . . . ”
text = “. . . register . . . ”
text = “. . . enrole . . . ”
text = “. . . register . . . ”
text = “. . . enrole . . . ”
name : String
name = “register”
name = “start”
name = “enrole”
name = “start”
name = “enrole”
name = “start”
Add Association to reh rse to ievn ecah to reh rse to ievn ecah
Delete Association
Add Association 1. Create Link between R2 “enrole” and M2 “start” 2. Rename Method M1 from “register” to “enrole” ΔUser
text : String fulfilled ∗ Method ∗ fulfilledBy name : String
text = “. . . register . . . ” fulfilled fulfilledBy name = “register”
text = “. . . enrole . . . ”
name = “start”
text = “. . . register . . . ” fulfilled fulfilledBy name = “enrole”
text = “. . . enrole . . . ” fulfilled M2 : Method fulfilledBy name = “start”
text = “. . . register . . . ”
text = “. . . enrole . . . ” M1 : Method name = “enrole” fulfilled fulfilledBy fulfilled M2 : Method fulfilledBy name = “start” During the 3. Run, is is not recreated directly, since this link does not base on a keyword triggering the consistency rule and is not contained within the initial models. To solve this problem, missing information which is stored only in the SUM and not in the current model has to be added again. This missing information is calculated by comparing the model diferences which are recorded during the previous execution of DeleteAssociation (2. Run) and the current execution of AddAssociation (3. Run). In the example, this recreates the link between requirement R2 and method M2, which was added manually to the SUM and was temporary gone.
Additionally, it also recreates the link between R1 and M1, which should be deleted, since it was introduced automatically basing on the keyword “register”, which was changed to “enrole” now. This problem is caused by the design of the operators to work with complete models and not only with model diferences, which is required for the initial creation and clean-up of the SUM (Section 3.2). That means, the operators react only on existing and added information, but not on changed and removed information. To solve this problem, the execution of operators is more complex as suggested up to now: After executing AddAssociation the second time (row “3. Run”) and recreating missing information (see paragraph before), the model diferences of the current execution of AddAssociation (3. Run) are compared with the model diferences of the previous execution of AddAssociation (1. Initialization). Changes of the previous run of this operator in this direction which are not created again by the current run of this operator, are not valid any more. Therefore, these diferences have to be inverted. For this example, the old creation of that link between R1 and M1 leads now to a deletion of that inconsistent link.
In general, after executing the operator, adding missing information and reverting previous changes which are invalid now, the resulting model is consistent and complete, so that the next operator can be executed. Since the SUM contains all information, the step to add missing information is required only on the way from models to the SUM. In the end, postconditions for this use case are updated versions of initial models and the SUM.
To solve the motivated consistency problems in the ongoing software development example, the methodologist selected and conifgured the operators depicted in Figure 3 according to Section 3.1. Linking requirements and methods with each other is supported by the operator AddAssociation 1 → 2 , as described in more detail in Section 3.3. Since the two meta-classes describing data classes are merged by the operator MergeClasses 5 → 6 (detail in Section 3.2), possible inconsistencies between class diagram and sourcecode are fixed. Additionally, this prevents new inconsistencies in the SUM, because this information is stored only once.
The resulting SUMM is shown in Figure 8 and represents the complete content of the three initial metamodels shown in Figure 1. Additionally, it contains the new association between Method and Requirement, and the two classes umlclasses.Class and asgjava.Class are merged into data.ClassType which represents now data classes both in sourcecode and class diagrams. data
If the user want to change information which is new in the SUM and represented in none of the initial models, he has to change the SUM directly. Although that is possible as shown, it is not very feasible, since the SUM contains all information and not only the information the user is interested in. As example, the links between requirements and methods are neither contained in the requirements model nor in the Java model, but only in the SUM. Since the SUM contain also all information about classes and class diagrams, which are not required here, the user wants to use a new view like exemplary depicted in Figure 9: It lists all requirements together with their linked methods as subset of the SUM. Now, users can easily change links between requirements and methods.
Therefore, new viewpoints have to be specified by the methodologist showing parts of the SUMM, in particular, information stemming from more than one initial model. This new viewpoint is specified again by selecting and configuring some more operators on top of the SUMM, which defines an additional chain of operators to describe SUM(M) ←→ New View(Point) . The same set of operators can be reused and configured according to the concerns for the viewpoints here again. The users change the corresponding new views and the changes are synchronized with the SUM and all other models by executing the operators (Section 3.3). 4.2
Up to now, only the evolution of models by user changes was
discussed roughly in Section 3.3. Additionally, the metamodels of
Requirements , Java and ClassDiagram as well as of the SUMM
could change [
Reasons for changes in the SUMM can be fixes for found bugs, refactorings or new information to store. As before, where the SUMM was created bottom-up in step-wise way by applying operators, these changes can be realized by selecting and configuring additional operators. Finally, the methodologist describes with operators the relationship SUMM ←→ SUMM’ , resulting in an explicit SUMM’ and further consistency rules.
Changes in the metamodels of the initial artifacts arise because of updates of the tools providing these metamodels or because of new versions for Java or UML. The realization efort for the methodologist depends on the amount of changes and its impact on already integrated structures: If the changes contain only additional 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 complete integration has to be specified again. 4.3
The approach was demonstrated using only one simplified example stemming from a software development project. This section discusses, why the complete approach is transferable to other software development projects and even to other application domains.
Diferent software development projects will have diferent consistency rules or diferent initial metamodels. This issue is handled by the methodologist, who specifies diferent chains of configured operators for diferent projects, with diferent SUMMs as result. The model decisions are substantiated regarding project-specific consistency rules. As example, in another project with the same set of initial metamodels as in the ongoing example, no links between requirements and methods should be created automatically 1 → 2 : Then the methodologist specifies the corresponding model decision to create no links automatically. As contrast, arbitrary complex algorithms stemming from research of the requirements community can be included into model decisions. Another case, same consistency rules with slightly diferent initial metamodels, is discussed in Section 4.4.
Other application scenarios are traceability issues, solvable by
this approach [
The approach is intended to work even in application domains outside of software development. This is possible, since the operators to specify the integration are independent from concrete metamodels, because the metamodel decisions of the operators are designed to be generic for reuse and to be substantiated regarding the predefined degrees of freedom. Therefore, precondition for the approach are not specific application domains, but the representation of artifacts in form of models and conforming metamodels. This technical issue can be overcome by developing adapters realizing the transformation of artifacts into models and vice-versa. 4.4 Integration on Reference Level The example integrates requirements and Java by supporting links between Java methods and textual requirements. If another project uses C++ instead of Java with the same consistency rules, the result is the same operator chain like in Figure 3, but with C++ instead of Java , since the current integration uses Java methods and not C++ methods. Now the methodologist spends again efort to realize the same consistency rules for similar models.
Instead of integrating concrete Java methods or C++ methods,
Java methods and C++ methods are shifted to “reference” methods
representing methods written in arbitrary programming languages.
Instead of using concrete metamodels (CMM) for Java or C++, a
reference metamodel (RMM) describing object-oriented general
purpose programming languages is required. An example reference
metamodel is the Dagstuhl Middle Model [
Instead of integrating concrete metamodels (CMM) into the SUMM like in Figure 3, reference metamodels (RMM) are integrated into a Reference SUMM (RSUMM) using operators, resulting in a similar operator chain. Instead of linking textual requirements with Java methods, now arbitrary requirements are linked with methods of arbitrary programming languages. The methodologist describes the required mappings CMM ←→ RMM again by configuring operator chains with the CMM like Java as starting point and the RMM like the Dagstuhl Middle Model as end point.
To get the SUMM , for each RMM one mapped CMM is selected. Since the integration of the RSUMM is defined on reference level using the RMM, the integration is executable again using the mapping between CMM and RMM and the wanted SUMM is created automatically together with its consistency rules.
In general, for similar integration projects, the integration should
be done once on reference level using reference metamodels and
not on concrete level using concrete metamodels as before.
Therefore, the integration on reference level eases the configuration of
SUMMs for the methodologist compared to Section 3.1 [
To ensure the consistency of technical independent and separated models conforming to diferent metamodels, which are overlapping and have relations to each other contentwise, a new bottom-up approach was depicted in this paper. The central idea is to create a Single Underlying (Meta)Model containing all information of all initial (meta)models as single point-of-truth. Additionally, the initial (meta)models are not thrown away, but migrated to projectional view(points) on this SUM(M) and kept up-to-date. This is reached by introducing operators which, formed as chain, define, how the SUMM is created out of the initial metamodels, and which executes transformations to ensure consistency between all initial models and the SUM. Since these operators are generic regarding metamodel and model changes and support arbitrary consistency rules explicitly, these operators are reusable for new viewpoints on top of the SUMM, for integrations on reference level and for ensuring model consistency in diferent application domains.
A prototypical framework to support this approach for model
consistency ensured by metamodel integration is currently under
development with Java, ECore as language to describe metamodels,
reuse of parts of the model migration structure of Eclipse EDapt
and extension of coupled operators described by [