Software evolution encompasses all activities relatedto engineering software, from its inception to retirement.Propagating change across software models that are al-tered due to maintenance activities is a first step towardsmaintaining consistency between architectural, design, andimplementation models. Model synchronization techniquesinitially presented within the context of Model Driven Archi-tecture provide an instrument for achieving change trace-ability and consistency. In this paper, we present a frame-work whereby software artifacts at different levels of ab-straction such as architecture diagrams, object models, andabstract syntax trees are represented by graph-based MOFcompliant models that can be synchronized using modeltransformations. In such a framework model dependenciesare implicitly encoded using transformation rules and anequivalence relation is used to evaluate when two modelsbecome synchronized.
1. Introduction
One of the major problems the software industry is fac-ing is the drift of software designs and architectural descrip-tions from the source code that is constantly changed dueto evolution or maintenance activities. Evolution of soft-ware includes modifications performed at all stages of thesoftware development lifecycle, from inception to retire-ment. Such modifications are performed on a wide range
1 This work is funded in part by the IBM Canada Ltd. Laboratory,Center for Advanced Studies (CAS) in Toronto.
of software artifacts ranging from those at a high level ofabstraction, such as business processes, to architecture, de-sign, and source code-level artifacts, such as architecturegraphs, object models, and abstract syntax trees. Eachchange that is performed in any of these models is not al-ways carried out in a systematic fashion, and maintenanceproblems occur when a change on one artifact is not con-sistently mapped and applied to another artifact of a soft-ware system. The complexity of each change mapping isinherently compounded with decisions regarding potentialinformation loss or gain related to differing levels of ex-pressiveness of assorted artifacts.
In this paper, we investigate the problem of synchro-nization between software models when one is altered dueto evolution or maintenance activities. Furthermore, wepresent a framework for what we refer to as Model-DrivenSoftware Evolution (MDSE) paradigm that is based on prin-ciples of Model Driven Architecture (MDA) [7]. In thiscontext, our view of software is in terms of models, each ata different level of abstraction (i.e., requirements, architec-ture, design, implementation). Each such model conformsto and is an instance of a corresponding metamodel. [17]Our research is focused on metamodels that have a commongraph theoretical basis and are compliant with the Meta-Object Facility (MOF) [10].
Model synchronization can be explicit or implicit. Inexplicit approaches, the dependence relations between twomodels are directly defined and encoded (i.e., through astatic table). These approaches are rigid as they requirethe creation and maintenance of structures necessary totrack dependencies between models. For instance, relationsamong models that are once established would need to beupdated every time a source or target model is changed. In
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
implicit approaches however, the relations between mod-els are defined in higher-order terms (e.g., relations be-tween metamodels), and actual dependence relations be-tween models are hence implied. The implicit approacheswould offer definite advantages over explicit ones by per-mitting the establishment of dependency relations that aremore flexible, customizable, and easier to maintain. Suchrelations would not be updated every time a model instanceis changed, but would be updated when demands imposedon the synchronization method are changed. In practice, im-plicit synchronization will not suit all scenarios and a hybridapproach that emphasizes implicitness while supporting ex-plicit mappings would be desirable.
Our goal in this paper is to present a methodology formodel synchronization, where change traceability is its cen-tral part. For achieving this goal, we first aim to derivea framework that can be used to represent and map mod-els in a way that provides enough semantic information forsynchronization. Secondly, we aim to derive a traceabilityframework, compliant with our representation framework,for tracking changes so that each alteration action is viewedin terms of its atomic units. Finally, we intend to pro-vide a process by which our methodology can be appliedto achieve synchronization of models at different levels ofabstraction.
To realize the first goal, we introduce an intermediaryGraph Metamodel for Synchronization (GMS). This meta-model is an instance of MOF but is less abstract and morecapable of providing desired semantic detail. To address thesecond goal, we introduce a Transformation Metamodel forSynchronization (TMS), where we view each model alter-ation as a combination of graph changes: insert node/edge,modify node/edge, and delete node/edge. For the thirdobjective, we provide a synchronization algorithm that isbased on dependency relations implicitly defined by map-ping source and target metamodels as graphs using GMS.
The rest of this paper is organized as follows. Sec-tion 2 presents related research and discusses how our find-ings build on previously published results in the area ofmodel transformation and traceability management. Sec-tion 3 presents the basics of model synchronization andexamines related aspects. Section 4 introduces our ap-proach to model synchronization, including the represen-tation framework, the traceability framework, and the algo-rithm for model synchronization through traceability. Fi-nally, Section 5 gives the conclusions and directions for fu-ture research.
2. Related Research
Systematic change of software models is attainedthrough model transformation. Czarnecki and Helsen pro-vide a classification of model transformation approaches
[2]. Based on this classification, each model transforma-tion consists of transformation rules that are combined toachieve a particular change. Each transformation rule con-sists of two distinct parts: a left-hand side (LHS), whichrefers to the source model, and a right-hand side (RHS),which refers to the target model. Both LHS and RHS can berepresented as a combination of (1) patterns, such as string,term, and graph patterns; (2) logic, such as computationsand constraints on model elements; and (3) variables, whichhold model elements of source, target, or some intermediarymodel. Transformation rules can be unidirectional or bidi-rectional, and can be parameterized to allow configurationand tuning. In our approach, we do not focus on specifi-cation and analysis of model transformations, but insteadview transformations as components of the model synchro-nization framework. Based on the traceability classificationfrom [2], we intend to derive traces that are stored sepa-rately while the traceability control will be automatic for allrules and synchronization control semi-automatic (i.e., au-tomatic for some rules).
Engels et al. in [5] have discussed the transformation ofUML Class Diagrams and UML Collaboration Diagramsinto Java code. They have shown how to deal with both thestructural and behavioral (e.g., flow) mapping problems be-tween UML and Java using a pattern-based transformationalgorithm. The pattern used is an instance of a metamodelfrom which one can identify parts of the source diagram thatis to be transformed. The goal of this approach was preser-vation of semantic information through transformation butthere was no discussion on how the defined transformationscould be used in model synchronization.
Shen et al. [12] have used UML stereotypes to extendthe UML metamodel in order to support model refinement.They have shown how Object Constraint Language (OCL)expressions can be used to define synchronization rules.The limitation of their approach is that they only supportchanges of UML static models at different levels of abstrac-tion, without considerations of synchronization with othermodelling languages.
In the area of consistency checking, change synchro-nization is interpreted as synchronization of model views.Fradet et al. [6] consider synchronization of multiple viewsof software architecture by first defining each view for-mally and then algorithmically checking inter-view consis-tency. Wirsing et al. [15] have looked at synchronizationof views across the entire development lifecycle by creatingan intermediary comparison view. Engels et al. have usedthe Communicating Sequential Processes (CSP) languagefor checking behavioral consistency among views [4]. Fi-nally, Larsson and Burbeck [9] have shown a model-view-controller approach to consistency checking by insistingthat each transformation between a model and the views hasan inverse that can be automatically calculated. In our ap-
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
proach, we have decided to base our methodology on graphsas a common basis and view all synchronized models asgraphs. We have also decided to express our framework inless-formal terms (e.g., OCL) in order to facilitate its easieradoption and extension to practical application scenarios.
The importance of traceability and its relation to syn-chronization was discussed in the area of traceability man-agement. In [3], Desfray points out the importance of trace-ability management in the MDA-based approaches to en-sure consistency among models. The key aspects of trace-ability are identified as follows:
• Element identification, where using the name of the el-ement as an identifier, was said to be spurious. Instead,it is mentioned that assigning a universally uniqueidentifier to each model element should lead to a moresuccessful traceability management.
• Implicit traceability, where related tools should trans-parently maintain relations among model elementsbased on natural properties of models (i.e., traceabilitybased on inherent relations). For example, a messagein UML can be related to an operation or can link to anassociation.
• Explicit traceability, where it will be necessary in cer-tain cases to manually define explicit relations betweenelements. For example, a link could be created be-tween a Use Case and classes that implement it.
• Traceability and external elements, where external ar-tifacts such as documentation or source code are re-lated to model elements, but they themselves are man-aged externally. Under such conditions, it is crucialthat each external element is uniquely identified by themodelling environment in order to maintain traceabil-ity.
Kowalczykiewicz and Weiss confirm these points andalso reiterate the importance of traceability integration intosoftware development [8]. Cysneiros et al. [1] demon-strate how to use traceability to synchronize i* [16] withUML models. They also demonstrate how to implementmodel synchronization using XML. However, their frame-work uses synchronization rules that identify elements bytheir names and other lexicographical properties, and notbased on their unique identifiers as suggested above. Withinour approach, we follow the directions for traceability anddefine an unique identifier for each model element. We in-corporate implicit traceability through a mapping betweenmetamodels while leaving an opportunity for explicit rela-tions to be defined through explicit mapping tables.
3. On Model Synchronization
From the related work above [9], a definition of “modelsynchronization” can be inferred as the process of establish-ing an equivalence between two models when one of themis altered. The equivalence can be defined through a set ofdependency relations between model elements. Additionalconcerns that may apply include:
• Source and target models can be at the same (intra-model synchronization) or different (inter-model syn-chronization) level of abstraction. Out of the two, theintra-model synchronization in general would be sim-pler, as dependencies among model elements wouldbe implied through reflection of the same applicablemetamodel. The inter-model synchronization wouldin general require dependency mapping between dif-ferent metamodels; for example, as in synchronizationof software architecture models with design class dia-grams or source code models. We should also note theexistence of special cases such as UML, where modelsthat might be at different levels of abstraction wouldbe derived from the same UML metamodel.
• Source and target metamodels can be different and beused to express information at notably dissimilar levelsof abstraction (e.g., synchronization of use cases withabstract syntax trees). Mapping dependencies amongthese metamodels would be quite hard and meaningfulsynchronization without intermediary models mightnot be always possible.
• Source and target models may be initially synchro-nized and the applicable equivalence relation holds.We refer to this scenario as “Model SynchronizationThrough Traceability”, and this is the central topic ofthis paper. In this case, changes performed on thesource model are traced, translated, and then appliedto the target model. After each iteration, the corre-sponding equivalence relations are checked to verifythat synchronization was performed successfully; ifthe check fails, additional input will be required.
• Source and target models may also not be initially syn-chronized and the applicable equivalence relation doesnot hold. We refer to this scenario as “Model Syn-chronization Through Equivalence” and is a point offuture research. In this case, the source model is trans-formed into its equivalent representation in terms ofthe target’s metamodel. Additional elements of the tar-get model that do not violate the equivalence relationsare then added to the newly derived model. The newmodel once verified to be consistent with the sourcewould then replace the target model.
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
• Finally, when source and target models can not be syn-chronized for the given equivalence relation, additionalinput is required. To achieve synchronization, changesmust be made more elaborate or could be performedmanually to modify either the affected equivalence re-lation or one of the models. This topic is out of theimmediate scope of the paper where we assume thatthe models can be synchronized.
4. Model Synchronization ThroughTraceability
In order to derive a model synchronization methodology,our three principal objectives are as follows:
1. To introduce a graph formalism as a representationframework for model synchronization.
2. To derive a transformation framework for model syn-chronization based on GMS.
3. To derive a synchronization algorithm based on implic-itly defined dependence relations, as means by whichour methodology can be applied in practical problems.
4.1. Graph Metamodel for Synchronization
Towards our quest for defining a framework for modelsynchronization, a fundamental question that needs be an-swered is related to the formalism that should be used torepresent models that relate to software artifacts at differ-ent levels of abstraction. This formalism has to be concise,formal, yet easy to understand, use, and process.
The objective for such a formalism is not only to allowsimplification and enable model synchronization, but alsoto maintain enough semantic detail so that implicit depen-dencies among models could be formally established. Ourfirst attempt for a solution to this problem was to use MOF,which provides a solid foundation for the specification ofother models. However, we concluded that MOF is too ab-stract for purposes of synchronization, as it lacks a methodfor expressing relevant model semantics. In addition, es-tablishing dependency relations among models where MOFis a common method of representation is not trivial andis prone to ambiguity due to an inherently high abstrac-tion level. Instead of MOF, we have considered graphsas a common denominator for representing models. Thesegraphs can then be modelled in MOF for implementationand processing purposes. Graphs provide a simple structure— they represent an organization of nodes and edges —and allow easy establishment of dependencies among in-stances. Augmented with labels, types, attributes, and di-rections, graphs are also capable of supporting semantic de-tail that is required for synchronization. Other approaches
that were considered, such as formal logic, did not offer thewell suited balance between simplicity and expressivenessfound in graphs. As a result, we have decided to use graphsas the core of our representation approach.
To express GMS (Figure 1) and other metamodels in thispaper, we have utilized MOF / UML semantics [11]. GMSis represented in terms of MOF and it was derived to de-note directed, typed, labelled graphs with attributes [13].Each such graph G consists of a set of nodes and edgeswhere each element has its own Globally Unique IDen-tifier (GUID) and each edge connects exactly two nodes.Each node or edge has a label and type (e.g., “Customer ::UML Class” for a node, “Uses :: UML Association” foran edge) and can additionally have attributes with their ownnames, types, and values. Dependencies among graphs areestablished through dependency nodes, which contain ap-plicable constraints (e.g., expressed in OCL-compliant no-tation [14]). Dependency nodes could also contain a map-ping table, which allows explicit mapping among specificmodel elements using their GUIDs. This table would con-tain three columns: first for the identifier of the source ele-ment, second for the equivalence operator defined globallyfor all models or locally for specific dependency, and thirdfor the identifier of the target element. Examples of equiva-lence operator include (1) explicitly-existential, where nei-ther source nor target element can exist without the other,(2) existential, where only source cannot exist without thetarget, (3) containment, where source contains the target el-ement, etc. An example of the containment operator defini-tion is given in Figure 3.
To demonstrate the usage of GMS, we show a UMLClass Diagram Metamodel for Synchronization (Figure 2).This model, meant as a simplified example of the UMLmetamodel, includes the integral elements that are neces-sary for modelling UML classes and their relationships, and
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
+ name : String+ type : String+ stereotype : String+ constraint : OCL Expression
1 *
1
*
+ setMethod
+ getMethod
MethodParameter
+ name : String+ type : String+ kind : String+ initValue : String
1 *
UML Class Diagram Metamodelfor Synchronization
+ target
+ source
ModelElement
+ GUID : String
Figure 2. UML Class Diagram Metamodel forSynchronization
it can be mapped to GMS as shown below.
• Class, Relationship, Attribute, Method and Method-Parameter entities map to GraphNode, where type ofthe node (e.g., “UML Class”) maps to “type : String”and name of the attribute (if available) maps to “label :String”.
• Each of the other attributes (e.g., “stereotype : String”)maps to GraphAttribute, where the type (e.g., “visibil-ity”) maps to “type : String” and the value (e.g., “pub-lic”) maps to “label : String”.
• Associations among classes map to GraphEdge, whereassociation label (e.g., “source”) maps to “name :String” and association type (e.g., “aggregation”) mapsto “type : String”.
The mapping between the derived metamodel for syn-chronization and GMS is configurable and is based on thedesired level of semantic granularity required for synchro-nization of model elements. For instance, the metamodelpresented in Figure 2 is based on the assumption that thesynchronization of models instantiated from this metamodelwould demand the level of semantic detail presented here.Accordingly, each of the model elements that had severalattributes beside its name and type was mapped to a node,and its attributes were mapped to graph attributes. In com-parison, if some of the model elements did not warrant thesame level of detail and did not include attributes relevantto synchronization, they could themselves be represented asgraph attributes.
Based on this example, metamodels for other modelsthat are used to support evolution activities can be de-rived. Moreover, any two metamodels compliant with GMSthat represent models suitable for synchronization (e.g.,models from successive stages of development lifecycle)can be matched by establishing dependency relationships.Each dependency node in between two metamodels would,through its existence, indicate that two types are dependent.And, through constraints internal to the node, it would pre-cisely define the mapping between element types and theirrelated attributes. It is worthy to note that each dependencynode would connect to exactly one element from each meta-model. However, each metamodel element could have morethan one dependency node connected to it, thereby allowingone-to-many or many-to-many relations.
ModelElementUML Class Diagram Metamodelfor Synchronization (simplified)
Figure 3. An Example of Metamodel Mappingfor Synchronization
To demonstrate the mapping between GMS-based meta-models, we show a an example of Architectural Box-and-Arrow Diagrams and UML Class Diagrams (Figure 3). Thisinstance is based on the assumption that each class in theUML model must be a part of a package in the architecturalmodel and cannot exist otherwise. This assumption is en-coded as a containment relationship specified using OCL.
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
This condition would during synchronization imply that if apackage that contains a particular class is deleted, that classand all its attributes, operations and associations would alsobe deleted. Within the mapping, we make a reference to theexplicit mapping table that can be used to manually definecontainment relations among suitable elements. This tableis used to verify the assumption behind the dependence re-lation.
In our example (Figure 3), we utilize OCL to expressrelations between individual meta-classes. However, thisapproach can be adapted to express relations between pat-terns of meta-classes by choosing a different specificationlanguage (e.g., graph grammars).
Figure 4. Transformation Metamodel for Syn-chronization
The presented example underlies the configurability ofour approach, where the level of granularity and semanticdetail is left fully customizable. Software engineers adapt-ing this framework to their usage scenarios would not belimited by our approach and could easily instantiate theirown synchronization mapping.
4.2. Transformation Metamodel forSynchronization
Using GMS as the basis for representation of models, thenext goal is to derive a common transformation approachthat could be used to establish traceability capabilities forsynchronization. Given that all models in our problemscope are viewed as graphs, their changes at their most ba-sic (atomic) level could be viewed as simple graph changes(e.g., insert, modify, or delete node or edge). From there, theactual changes performed could be represented and tracedas combinations of graph changes. Hence, we define atransformation metamodel for synchronization, which is anabstraction of actual changes performed on models and isbased on GMS. Each (source) metamodel for synchroniza-tionMGMS instantiated from GMS would also have a com-plementary (target) metamodel MTMS , which would be aninstance of TMS and would define transformations for allinstances of MGMS . It also holds that all model trans-formations performed on models that comply with MGMS
would then have to comply with the matching MTMS .More specifically, TMS, as expressed in Figure 4, iden-
tifies basic graph operations as a hierarchy, and is based onthe assumption that performing a particular operation willnot violate the structural integrity of a graph. For that pur-pose, each graph transformation will have its own globallyor locally defined pre and postconditions, which would en-sure the preservation of the structural integrity. For exam-ple, a node that is removed should not leave dangling edges,but should be preceded with the removal of affected edges.
The mapping of TMS to an instance for UML Class Di-agram transformations is not complex and is described asfollows.
• Each change to one of the entities of the class dia-gram is mapped to its abstract representation in termsof graph changes based on the mapping of UML classdiagram metamodel with GMS. For example, opera-tion “InsertClass” is mapped to “InsertNode” and oper-ation “DeleteAssociation” is mapped to “DeleteNode”.Also, operation “SetClassName” is mapped to “SetN-odeLabel” and operation “SetAssociationMultiplicity”is mapped to “SetNodeAttribute”.
• To maintain structural integrity, required pre and post-conditions are set in the root of the transformationmodel hierarchy. These constraints specified in OCLcould, for example, ensure that class is not removeduntil its attributes, operations, or associations are re-moved or reassigned. Given that each operation inher-its properties from the top level “GraphTranformation”operation, these conditions would apply to all opera-tions across the transformation model.
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
This UML Class Diagram Transformation Metamodel inconjunction with similarly defined Architectural Box-and-Arrow Diagram Transformation Metamodel could be usedto map and enact changes between models of these twotypes, as discussed in the next subsection.
4.3. An Algorithm for Model SynchronizationThrough Traceability
Before specifying the synchronization algorithm and itsdetails, it is necessary to mathematically define the notationand the problem.
Let a model M be a set of typed nodes, edges, andproperties on these nodes and edges. Each M is an instanceof a corresponding GMS-compliant metamodel MM . Anode n of M is represented as a tuple ( GUID, label, type,A ) and an edge e of M as a tuple ( GUID, label, type,sourceNode, targetNode, A ). In each tuple, GUID is aGlobally Unique IDentifier used to unambiguously identifynodes and edges while type is an element of MM . Inaddition, let A be a set of attributes, where each attribute ais represented as a tuple ( label, type, value ).
The problem of synchronization can then mathemati-cally be described as follows: let M and G be two modelsat different levels of abstraction synchronized through anequivalence relation R (i.e., M R G). Given a sequence oftransformations T m that alters M to yield M′, the problemis to identify a corresponding sequence of transformationsT g that when applied to G yields G′ such that M′ R G′.We assume for simplicity that each transformation couldinsert, delete, or modify a node, an edge, or an attribute.
The solution based on GMS and TMS frameworkswould be a sequence of translations from T m to T g ,where each translation is mapped using one of the rulesfrom a set of applicable synchronization rules S. Eachsynchronization rule would apply to a particular operation(e.g., InsertNode), be based on a particular premise (i.e.,relevant preconditions), and would include correspondingactions. A rule could be expressed in a variety of notationsincluding OCL and graph grammars.
Synchronization rules would be based on dependenciesbetween the metamodels of M and G. Assuming thatType1 D Type2 for a dependency relation D where R ⊃ D,a simplified template for rules that map InsertNode trans-formations from M to G would be as follows. Note thatsimilar templates would apply for other transformations(e.g., DeleteNode, ModifyEdge).
Case 1. For each InsertNode ( label, Type1 ), assuming thatD is one-to-one mapping with no constraints, execute
Case 2. For each InsertNode ( label, TypeT ) where TypeT<> Type1, assuming that D is one-to-one mappingwith no constraints, execute <nothing>.
Case 3 and above. For each InsertNode ( label, Type1 ),assuming that D is a mapping with constraints, derive atransformation t that satisfies constraints. Else, if con-straints could not be satisfied, execute <nothing>.
As it can be seen in examples in Figure 5 and Figure 6,not all of these cases would apply at the same time. More-over, the rules could also contain implementation specificoperations (e.g., FindRelation, EstablishRelation) that areused to comply with the constraints as set in D.
The algorithm for Model Synchronization ThroughTraceability (abbreviated as MSTT) is as follows.
Algorithm: MSTT
Input:
1. Model M2. Model G3. Equivalence Relation R4. Set of Synchronization Rules S5. Sequence of Transformations T m
Output: 1. Model M′
2. Model G′
Steps:
Step 1. Let two models M and G be initiallysynchronized under an equivalence relationR (i.e., M R G ). Also, let S be a set ofapplicable synchronization rules.Step 2. Let M be modified through a se-quence of transformations T m resulting in amodel M′.Step 3. For each transformation tm from T m,use a corresponding synchronization rule s toobtain transformation tg . Make each tg be apart of T g in the order analog to T m.Step 4. Apply T g to G to obtain G′, and ver-ify that M′ R G′. Store the record of trans-formation, indicating the outcome of apply-ing T g.Step 5. If M′ RG′ does not hold, identify vi-olated constraints and either manually updatethe constraints or the model elements that vi-olate them, or declare failure.
To show the usage of the algorithm, we include the fol-lowing two examples. In Figure 5, M and G are two genericmodels where G is at a higher level of abstraction than Mand M R G for some relation R. The set of rules S forsynchronization of M and G is based on the dependency
Student :: Class
+ GUID
+uses
Account :: Class
+ GUID
AccountManager :: Class
+ GUID
+uses
StudentManagement ::Package
+ GUID
+uses
Tm:DeleteEdge ( AccountHistory, Stack)DeleteNode ( Stack, Class);InsertNode ( HashTable, Class); % from a libraryInsertEdge ( AccountHistory, HashTable );
Model M :: UML Class Diagram Model G :: Architectural Diagram
S:forEach InsertNode ( l1, Class ) if exists ( lli : Package | lli <contains> l1 and G <contains> lli ) execute <nothing> else if exists ( lli : Package | lli <contains> l1 ) execute InsertNode ( lli, Package ) else execute EstablishRelation ( <inputLabel>, l1, contains) execute InsertNode ( <inputLabel>, Package )forEach InsertNode ( l1, T ) where T <> Class execute <nothing>forEach InsertEdge ( l1 : Class, l2 : Class ) execute ll1 = FindRelation ( l1 ) execute ll2 = FindRelation ( l2 ) if exists ( edge | source = ll1 and target = ll2 ) then execute <nothing> else execute InsertEdge ( ll1 : Package, ll2 : Package )forEach InsertEdge ( l1 : T1, l2 : T2 ) where T1 <> Class or T2 <> Class execute <nothing>forEach DeleteNode ( l1, Class ) execute ll1 = FindRelation ( l1 ) if exists ( node : Class | ll1 <contains> node ) execute <nothing> else execute DeleteNode ( ll1, Package)forEach DeleteNode ( l1, T ) where T <> Class execute <nothing>forEach DeleteEdge ( l1 : Class, l2 : Class ) execute ll1 = FindRelation ( l1 ) execute ll2 = FindRelation ( l2 ) if not exists ( edge | source = li and target = lj and ll1 <contains> li and ll2 <contains> lj ) execute DeleteEdge ( ll1, ll2 ) else execute <nothing>forEach DeleteEdge ( l1 : T1, l2 : T2 ) where T1 <> Class or T2 <> Class execute <nothing>
relation D between types T3 and TT3. The relation D is il-lustrated at the top of Figure 5 and it denotes that for eachinstance of T3, there is an instance of TT3 such that T3 iscontained in the package of TT3; and that for each instanceof TT3, there is an instance of T3, such that T3 is containedin the package of TT3. For simplicity, we assume that inthis case D ⇔ R, while in general, D ⊂ R (i.e., otherconstraints beside the ones in D would be present). Themodel M is transformed using a sequence of transforma-tions T m into M′. The synchronization algorithm maps in-dividual transformations from the given transformation se-quence T m into transformations for a new sequence T g .Each mapping is based on a rule that matches the transfor-mation type. For example, InsertNode ( M4, T1 ) is mappedusing the first rule from S — forEach InsertNode ( l1, T1) execute <nothing> — into <nothing> (i.e., no executionnecessary). Similarly, InsertEdge ( M3, M4 ), where M3 isof type T3 and M4 is of type T1, is mapped using the sixthrule from S into <nothing>, as there is no link between M3and another node of type T3 through M4. The resulting se-quence T g is applied to G to obtain G′. Finally, it is verifiedthat M′ R G′ is true by checking that constraints of D aresatisfied.
Similarly, in Figure 6, we show two models M and G,where M is a low-level design model and G is an archi-tectural model. The model M is altered through T m, sothat the AccountHistory class is implemented not using theinternal Stack class but the external HashTable class fromDataStructures library. Since HashTable is not part of theexisting packages, as a result of the mapping of T m to T g ,a new package DataStructures is created to indicate the ex-ternal library with a new edge connecting it to the Account-Management package.
4.4. A Process for Model SynchronizationThrough Traceability
In this subsection, we identify a process that can be usedto instantiate our methodology for a practical synchroniza-tion scenario. The steps in this process would be as follows.
Step 1. For two models M and G that need to be kept syn-chronized, identify model types Mt and Gt.
Step 2. For identified model types, derive GMS-compliantrepresentation metamodels MMr and GMr withenough semantic detail for intended synchronization.
Step 3. Establish necessary dependencies among MMr
and GMr using dependency relationships. If necessary,manually insert tuples into explicit mapping tables toindicate dependencies among specific model elements.Modify MMr and GMr if necessary.
Step 4. For identified model types, derive TMS-complianttransformation metamodels MMt and GMt so thatthey are consistent with MMr and GMr respectively.To preserve structural integrity, define necessary pre-conditions and postconditions for those operations thatwarrant it.
Step 5. Implement traceability capability (e.g., throughtracing feature of an IDE, or a model repository) basedon MMt and GMt.
Step 6. Verify that M and G satisfy dependency conditionsand manually update them if not equivalent at the be-ginning.
Step 7. Assuming interactive synchronization (i.e., enduser requests synchronization), fragment the changesperformed into basic graph transformations and mapthem using an algorithm described in the previous sub-section. Ensure that a record of transformation isstored after each batch of transformations is processed.
For more automatic support of synchronization, it isclear that this algorithm would have to be implemented us-ing a modelling API and then would have to be integratedinto an overall development lifecycle (e.g., made part of theactive Integrated Development Environment (IDE)). Thisimplementation problem is out of the scope of this paper,and will be explored in future research.
5. Conclusions and Future Research
In this paper, we have introduced a methodology formodel synchronization to achieve traceability of changes ofsoftware models that occur during software evolution andmaintenance. As part of our theory, we have introducedframeworks for model representation and model transfor-mation that are based on the concept of graphs. Each modelthat is to be synchronized based on our methodology isviewed as a graph, and each change made on this modelis viewed as an instance of a graph change. Based on thisapproach, we are able to implicitly map changes betweenmodels that are based on different levels of abstraction.Within our theory, we have also shown an algorithm thatprescribes how our framework can be instantiated and ap-plied to solve concrete synchronization problems.
We have classified this approach as primarily implicit,where relations between model elements are implied fromdependency mappings between their metamodels. How-ever, in practice, implicit mappings will not suffice for allconditions. We have therefore incorporated as a first step,a facility for explicit mappings between model elements interms of mapping tables, which refers to model elements bytheir unique identifiers.
Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04)
The focus for this paper is to set the foundations for amethodology and to illustrate its capacity to handle struc-tural synchronization of compatible models (e.g., modelsfrom consecutive stages of development lifecycle). As partof on-going work, we have yet to demonstrate the suitabil-ity of our approach to handle behavioral synchronization;for instance, synchronization of complex flows. Never-theless, we believe that the proposed framework is a firststep towards establishing a formal, yet tractable frameworkwhereby software models and artifacts at different levels ofabstraction can be synchronized and can be maintained con-sistent with each other when one of these models is altereddue to evolution activities.
References
[1] G. Cysneiros, A. Zisman, and G. Spanoudakis. A traceabil-ity approach from i* and uml models. In Proceedings ofthe 2nd International Workshop on Software Engineering forLarge-Scale Multi-Agent Systems (SELMAS), Lecture Notesin Computer Science, Portland, OR, May 2003. Springer.
[2] K. Czarnecki and S. Helsen. Classification of model trans-formation approaches. In Proceedings of the 2nd OOPSLAWorkshop on Generative Techniques in the context of ModelDriven Architecture, Anaheim, CA, October 2003.
[3] P. Desfray. Mda when a major software industry trendmeets our toolset, implemented since 1994. Technical re-port, SOFTEAM, October 2001.
[4] G. Engels, R. Heckel, and J. M. Kster. Rule-based specifica-tion of behavioral consistency based on the uml meta-model.In Proceedings of the 4th International Conference on theUnified Modeling Language (UML), volume 2185 of Lec-ture Notes in Computer Science, Toronto, Canada, October2001. Springer.
[5] G. Engels, R. Huecking, S. Sauer, and A. Wagner. Umlcollaboration diagrams and their transformation to java. InProceedings of the Second International Conference on TheUnified Modeling Language (UML), volume 1723 of Lec-ture Notes in Computer Science, Fort Collins, CO, October1999. Springer.
[6] P. Fradet, D. Metayer, and M. Perin. Consistency checkingfor multiple view software architectures. In Proceedings ofthe 7th European engineering conference held jointly withthe 7th ACM SIGSOFT international symposium on Foun-dations of software engineering, Toulouse, France, October1999.
[7] A. Kleppe, J. Warmer, and W. Bast. The Model Driven Ar-chitecture: Practice and Promise. Addison-Wesley, 2003.
[8] K. Kowalczykiewicz and D. Weiss. Traceability: Taminguncontrolled change in software development. In Proceed-ings of the IV KKIO Conference, Tarnowo Podgrne, Poland,2002.
[9] H. Larsson and K. Burbeck. Codex - an automatic modelview controller engineering system. In Proceedings of theWorkshop on Model Driven Architecture: Foundations andApplications, Enschede, The Netherlands, June 2003.
[10] OMG. Meta object facility (mof) specification version 1.4.Technical report, Object Management Group (OMG), April2002. http://www.omg.org/docs/formal/02-04-03.pdf.
[11] OMG. Unified modelling language (uml) specification.Technical report, Object Management Group, March 2003.http://www.omg.org/docs/formal/03-03-01.pdf.
[12] W. Shen, Y. Lu, and W. L. Low. Extending the uml meta-model to support software refinement. In Proceedings of theSecond Workshop on Consistency Problems in UML-basedSoftware Development, San Francisco, CA, October 2003.
[13] D. Varro and A. Pataricza. Mathematical model transfor-mations for system verification. Technical report, BudapestUniversity of Technology and Economics, May 2001.
[14] J. Warmer and A. Kleppe. The Object Constraint Language:Precise Modeling with UML. Addison-Wesley, 1998.
[15] M. Wirsing and A. Knapp. View consistency in softwaredevelopment. In Proceedings of the 9th International Work-shop on Radical Innovations of Software and Systems Engi-neering in the Future (RISSEF), Venice, Italy, October 2002.
[16] E. Yu. Modelling Strategic Relationships for ProcessReengineering. PhD thesis, University of Toronto, 1995.
