Produção Nacional
Revisado por pares
UML2Merge: a UML extension for model merging
2019; Institution of Engineering and Technology; Volume: 13; Issue: 6 Linguagem: Dinamarquês
10.1049/iet-sen.2018.5104
ISSN1751-8814
AutoresKleinner Farias, Toacy Cavalcante, Lucian José Gonçales, Vinícius Bischoff,
Tópico(s)Model-Driven Software Engineering Techniques
ResumoIET SoftwareVolume 13, Issue 6 p. 575-586 Research ArticleOpen Access UML2Merge: a UML extension for model merging Kleinner Farias, Corresponding Author Kleinner Farias kleinnerfarias@unisinos.br orcid.org/0000-0003-1891-3580 Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this authorToacy de Oliveira Cavalcante, Toacy de Oliveira Cavalcante COPPE, Federal University of Rio de Janeiro, Rio de Janeiro, BrazilSearch for more papers by this authorLucian José Gonçales, Lucian José Gonçales Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this authorVinicius Bischoff, Vinicius Bischoff Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this author Kleinner Farias, Corresponding Author Kleinner Farias kleinnerfarias@unisinos.br orcid.org/0000-0003-1891-3580 Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this authorToacy de Oliveira Cavalcante, Toacy de Oliveira Cavalcante COPPE, Federal University of Rio de Janeiro, Rio de Janeiro, BrazilSearch for more papers by this authorLucian José Gonçales, Lucian José Gonçales Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this authorVinicius Bischoff, Vinicius Bischoff Applied Computing Graduate Program (PPGCA), University of Vale do Rio dos Sinos, São Leopoldo, RS, BrazilSearch for more papers by this author First published: 01 December 2019 https://doi.org/10.1049/iet-sen.2018.5104Citations: 4AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Model merging plays a chief role in many software engineering activities, e.g. evolving Unified Modelling Language (UML) models for adding new features. Software developers may evolve UML models using merge relationships. However, given the growing heterogeneity of merge strategies and the UML limitations for expressing merge relationship, it is particularly challenging for them to specify merge relationships. Consequently, developers, end up expressing improperly merge relationships. Today, the UML can neither specify the semantics nor the order in which merge relationships must be performed. Developers are unable to specify the semantics and order in which merge relationships must be performed. This study, therefore, proposes UML2Merge, which is a UML extension for expressing merge relationship. The UML2Merge was evaluated through an empirical study with 10 participants for investigating its effects on the merge effort, the correctness of merge relationships, and the participant's acceptance. The collected data suggest that the UML2Merge is proper to express merge relationships by requiring a low merge effort, producing elevated correctness of merge relationships, and having a high acceptance of the participants. The results are encouraging and show the potential for using UML2Merge to express the evolution of UML models through merge relationships. 1 Introduction The Unified Modelling Language (UML) is the de facto standard for object-oriented software modelling [1-3] and has been widely used to represent evolving UML models (e.g. UML class diagrams), especially in scenarios where model merging is required. In collaborative software development, for example, separate virtual teams may concurrently work on a partial model of the overall architecture to allow developers to concentrate more effectively on parts of the architecture relevant to them. At some point, it is necessary to combine these models to produce a ‘big picture’ view of the overall architecture. For this reason, a significant body of research has been done in the field of collaborative software modelling [4], merge conflicts [5], model synchronisation [6], integration of heterogeneous models [7], and integration of feature models [8]. Regardless of the application field, developers usually need to specify how UML model elements should be combined. Bischoff et al. [8] highlight that there may be many different ways of combining design models. However, it is particularly challenging to specify how to merge input models, given the growing heterogeneity of the merge strategies, and mainly the limitations of UML to express specific merge semantics, or even the order of model merging. Hence, developers end up being unable to express how the parts of the input models should be combined. To date, the UML lacks constructs that help developers to express merge relationships. Previous empirical studies [9, 10] have identified a series of ambiguous and missing rules in the UML built-in merge mechanism, namely UML package merge [3]. Although many UML extensions have been proposed over the past years [11-13], this literature still fails, for example, to parameterise merge relationships with specific semantics. Guessi et al. [11] provide a thematic analysis of studies on UML extensions for supporting aspect-oriented modelling. Still, overcoming these challenges is crucial to address broader challenges in the context of software development in practice. Rubin and Rinard [14] point out some challenges related to efficient integration of software artefacts to support ‘building a large system while controlling interactions between all its different parts.’ Rubin and Chechik [15] also highlight those merging design models is an NP-hard problem. To sum up, developers end up having critical problems in employing UML constructs to support the evolution of architecture models using merging relationship. This paper, therefore, presents UML2Merge, which is a UML extension to express merge relationship. For this, we extend the UML metamodel with a set of constructs following the open–closed design principle [16] to ensure a conservative extension, thereby allowing developers to extend it with specific matching and merge semantics, e.g. override, merge, and union (but not limited to). The UML2Merge specification is based on the UML metamodelling standard for being more intuitive and pragmatic in real-world settings [3]. Note that our study introduces a UML extension rather than matching and merging strategies. The UML2Merge was evaluated through an empirical study with 10 participants for investigating its effects on the merge effort, the correctness of merge relationships, and the participants’ acceptance. The collected data suggest that the UML2Merge is appropriate to express merge relationships as it required a low merge effort, produced a high correctness of merge relationships, and having an elevated high acceptance of the participants. Our initial evaluation has also shown that the extension is (i) proper to express merge relationship and its execution order, as well as (ii) flexible to support new match and merge strategies by making the extension more adherent to the open–closed principle [16]. The results are encouraging and show the potential for using UML2Merge to express the evolution of UML models through merge relationship. In addition, it is important to highlight that this study is not an attempt to address all contexts in which model merging can be applied, since this would be extremely burdensome given the several meanings that it can assume in different contexts, e.g. merging of independently developed models, merging of models with common ancestors, merge of behavioural components (parallel and sequential merge), and weaving of aspects. Still, this study does not seek to provide expressiveness for supporting, e.g. join points for aspect models, even for the simple case where there is an individual diff model. Rather, this study is motivated by the need for specifying how UML models should be combined in evolution scenarios. Based on this merge relationship specification, the current tools can automate merge tasks, for instance. The remainder of the paper is organised as follows. Section 2 introduces the main concepts and knowledge that are going to be used and discussed throughout the paper. Section 3 presents the proposed UML extension for representing model merging. Section 4 describes the methodology used for evaluating the UML2Merge, and presents some results. Section 5 contrasts our work with the current literature. Finally, Section 6 presents some concluding remarks and future work. 2 Background This section discusses the main terms used throughout this paper. Section 2.1 introduces key concepts by presenting a comprehensive example of model merging. Section 2.2 outlines the metamodelling pattern. 2.1 Model merging 2.1.1 Merge relationship The term merge relationship might be briefly defined as a specification of an operation in which a set of tasks should be performed over two input models, and , to produce a desired merged model, . and represent the source and target of a merge relationship, respectively. has a set of increments that should be accommodated into to transform it into . Fig. 1 illustrates a merge relationship between and , and the role assumed by them (source and target model). Merging and means to match and (Section 2.1.2) for identifying their commonalities and differences. After that, model elements of and that are equivalent should be combined using a merge strategy (Section 2.1.3). Evidence from previous studies (such as [17]) has shown that and frequently suffer from conflict problems (Section 2.1.4). Also these conflicts are often solved improperly, giving rise to inconsistencies in the merged output model. This becomes the practice of merging models a highly error-prone task. Fig. 1Open in figure viewerPowerPoint Conceptual view of the merge relationship semantics (adapted from [3]) 2.1.2 Matching strategy Before producing a desired merged model, developers need to compare the input models so that the commonalities and differences between them may be identified. Matching strategies define the semantics about how the input models should be compared and contrasted, identifying their overlapping parts and differences. Developers can match the input models in different ways, e.g. following a named-based matching strategy [18] (default strategy), considering syntactic properties (partial strategy), or even considering both syntactic and semantic properties (complete strategy). To put all strategies in practice, developers may elaborate matching rules to implement and refine them. For example, developers might use the Epsilon Comparison Language [19] for coding such matching rules. After matching the input models, the next step is to put them together. For this, merging strategies can be used. Some examples of merging strategies are presented as follows. Note that the definition of matching and merging strategies is beyond the scope of this paper. This work just uses a set of merge strategies. 2.1.3 Merge strategy Based on the overlapping points between and , and their differences, identified by the matching strategies, merge strategy defines how to integrate the matching parts. We adopted (for convenience) in the proposed UML extension (but not limited to) three merging strategies (i.e. override, merge and union described in [20]). The matching and merging strategies were chosen because they have been applied to a wide range of merging scenarios [5] – evolution of design models, ontology merging, and conceptual model merge. Furthermore, they have been recognised as handy, helpful heuristics in evolving architectural models (e.g. [20]). Therefore, we present such strategies as part of the proposed UML extension (Section 3.2). In the following, we briefly introduce these three strategies, and assume and as the input models. Fig. 2 illustrates an example about how the matching and merging strategies are used to evolve a simple UML class diagram. plays the role of the source model, while plays the role of the target model. has the changes that should be inserted into to produce a new version of a UML class diagram, . To generate this desired new version, and are compared to identify their overlapping parts. The equivalence between the model elements can be obtained by using match-by-name matching strategies (e.g. [18, 21, 22]). Fig. 2Open in figure viewerPowerPoint Illustrative example of model merging Thus, the classes .Researcher and .Researcher have equivalent names. However, .Researcher is a concrete class (i.e. Researcher.isAbstract = false), whereas .Researcher is an abstract one (i.e. Researcher.isAbstract = true). The equivalent parts and differences between model elements can be combined following a particular merge strategy. The merge strategies considered in our study are briefly discussed as follows: Override: For all pairs of corresponding elements in and , the elements of should override the similar elements of . The different model elements remain unchanged, i.e. they are just inserted into the merged output model. For example, Fig. 2 shows an example of merged model, , which was produced using the override algorithm. In this case, the class .Researcher (concrete class) overrides .Researcher (abstract class), producing .Researcher (concrete class). Merge: For all pairs of corresponding elements in and , the elements should be combined. The fusion depends on the types of model elements, i.e. the only model element of the same type can be combined. If two model elements have same name but different types (e.g. Component and Class), then they cannot be merged. The model elements of and that are not equivalent remain unchanged and are directly inserted into the merged output model. For example, Fig. 2 depicts a merged model, , which was elaborated using the merge algorithm. In this case, the class .Researcher (concrete class) and .Researcher (abstract class) are merged, producing .Researcher (concrete class) with two attributes. Union: All pairs of corresponding elements in and are manipulated, having their names modified, and inserted into so that their identification can be preserved. This means that they coexist but with different identifiers or names in a merged output model. The elements of and that are not correspondent remain unchanged, being inserted into the merged output model, . In Fig. 2, the merged output model, produced using union strategy, has two classes, Researcher, which have the package name from which they come from, i.e. and . The classes, Assistant and Professor, were just inserted into without any modification. 2.1.4 Merge conflicts and inconsistency Merge conflicts consist of contradictions between values assigned to the properties of design models. Fig. 2 illustrates an example of a merge conflict. In the source model, the class .Researcher is defined as a concrete class (i.e. .Researcher.isAbstract = false), whereas in the target model it is set as an abstract one (i.e. .Researcher.isAbstract = true). These contradicting values assigned to isAbstract represent a conflict that must be solved by developers. This implies that developers should answer the following question: should class Researcher be abstract or not? Based on the desired merged model in Fig. 2, the correct answer for this question would be that Researcher should be abstract – i.e. Researcher.isAbstract = true. However, developers might assign false. This would generate an inconsistency, which can be briefly defined as divergences between model elements found in the merged output model and desired merged model. Fig. 2 presents two merged output models, which were produced using the override strategy and merge strategy. Both models have inconsistencies. We can observe that the produced models using the override and merge strategies present more problems as compared with the desired one. First, the model produced following the override algorithm has three inconsistencies: (i) the class Researcher is concrete, instead of abstract; (ii) the visibility of attribute Researcher.salary is private, instead of public; (iii) the methods Assistant.getSalary(): int and Professor.getSalary(): float cannot access Researcher.salary because the attribute s visibility is private. Second, the model produced using the merge algorithm has, in turn, two inconsistencies: (i) the class Researcher is concrete, instead of abstract; and (ii) the method Professor.getSalary():int cannot return a float, as would be expected. For this, developers need to be able to specify which merge strategy should be applied, and in which order they should be performed when two (or more) merge relationships are defined. If the merge semantics and its execution orders are not properly expressed, the model merging can become an error-prone and time-consuming task [20]. In fact, model elements of and can conflict with each other and developers need to be able to decide how the conflicts should be solved. Conflicts cannot be avoided at this stage, they can only be resolved. Unfortunately, developers tend to overlook conflict problems, given the problem at hand. Consequently, a model with inconsistencies, , is produced instead of the desired merged model, . If , then developers should invest some effort so that the inconsistencies in can be repaired, recovering . In practice, developers can be aided by traditional matching and merge strategies to produce a desired output model, or even a merged output model close to a desired output model. 2.2 Metamodelling pattern This section describes the UML metamodelling pattern [3] used to specify the proposed extension. According to OMG [3], the key role of a metamodel is to define the semantics for how model elements in a model get instantiated. The definition of UML2Merge (Section 3) follows the metamodelling pattern, presented in [3], due to some reasons. First, the UML metamodel specification pattern is the mainstream way to define the meaning of the constructs of the current UML extensions, such as [12, 13]. Secondly, it provides practitioners and researchers with a systematic but easy-to-read specification style [16], enabling an improved understanding of the meanings of the proposed extension, and reducing an inappropriate use in practice. Thirdly, it leverages the compliance with the semantics of UML metaclasses, their structural relationships, and constraints, thereby allowing a seamless integration between the UML specification and the proposed one. Finally, it is a well-established way for specifying the syntax and semantics of metamodel [3]. This can be perceived when reviewing the current literature (Section 5) that customises UML metamodel constructs, mainly ones proposed and maintained by OMG [3] in the past decade. For this, the following concepts guide the definition of the UML2Merge constructs: Abstract Syntax. It defines the metaclasses that represent the language constructs, e.g. Class, Attribute, Association, their relationships, multiplicity, and ordering constraints. These constructs and their relationships are described in natural language. Attributes and Associations. The attributes and associations are enumerated along with a short explanation. The multiplicity of the attributes is suppressed when it assumes a default value, i.e. the value of 1 (default in UML metamodel [3]). Semantics. It defines the meaning of each well-formed construct, while the static semantics defines how an instance of a construct should be connected to other instances to be meaningful; the dynamic semantics defines the meaning of a well-formed construct [3]. The meaning of a created model using the proposed extension is correctly defined, i.e. it is well-formed if and only if it achieves the rules defined in the static semantics. Well-formedness rules. It defines constraints that should be fulfilled to get instantiated a valid and meaningful model. The constraints concerning multiplicity and ordering are defined in the metamodel. Thus, the rules specify constraints over attributes and associations defined in the metamodel. For this, OCL (Object Constraint Language) expressions [23], along with an informal explanation of the expression, specify the proposed invariants. However, as far as possible, the invariants are expressed in natural language. 3 Proposed UML extension This section presents the UML2Merge, a UML extension to support the specification of merge relationship between UML models. The main contribution of this work is the proposed abstract syntax, constructors and notations to express merge relationships. Section 3.1 pinpoints the UML and UML2Merge constructs that may participate in a merge relationship. Section 3.2 specifies the UML2Merge s merge relationship. 3.1 Composable and composite Fig. 3 shows the abstract syntax of the UML2Merge regarding the constructs that are able to participate in the merge relationship. It shows which constructs are from UML, such as NamedElement, Parameter, and Property, and those constructs proposed in our extension, such as ComposableElement and CompositeElement. We highlight that the way that UML metamodel specifies the participants of the inheritance relationship in [3] was the basis to describe these elements. Moreover, we have used the composite design pattern [16] to organise the model elements. We have chosen this pattern for the following reasons. The first would be to represent part-whole hierarchies of objects, which might be to participate of a merge relationship. Next, merge relationship can treat uniformly all objects in the composite structure. Thirdly, new constructs, extending our approach, can be supported by just accommodating them in the composite structure; these constructs would need to extend the CompositeElement metaclass in Fig. 3. Fig. 3Open in figure viewerPowerPoint Constructs that participate in a merge relationship CompositeElement arranges the ComposableElements into tree structures by using a whole-part relationship. Usually, merge techniques are able to combine a set of UML diagrams, not all. Therefore, defining the model elements that can participate in a merge relationship is pivotal to create an alignment between the specification and the practice to combine UML diagrams. Merge techniques can read the specification, and then combine the input models based on this specification. ComposableElement. It is an abstract class and subclass of NamedElement, a central construct in the UML metamodel. It determines the basic semantics for constructs so that they may take part of a merge relationship. On the other hand, the CompositeElement is an abstract class that works as a container, i.e. bringing together the composable constructs seamlessly. It represents the UML constructs that contain other elements. Some constructs need to be analysed individually during the definition of similarity and integration of the model elements, including Parameter, EnumerationLiteral and Property. Thus, this extension defines construct hierarchies, which comprise primitive and composite constructs. While the composite can be decomposed into simpler ones, which in turn can be decomposed, recursively. Hence, merge techniques can deal with composite and primitive constructs indistinctly. This offers two advantages: (i) merge techniques can have more specific matching and merge rules for each construct, rather than generic ones, as for each model element the merge technique should have a rule describing how they should be combined; and (ii) the ease of adding new kinds of constructs, as well as extending merge techniques. In the following section, we present the merge relationship construct. 3.2 Merge relationship and its constructs This section presents the merge relationship itself and its constructs. Fig. 4 shows the abstract syntax of the proposed merge relationship. Fig. 4Open in figure viewerPowerPoint Proposed UML extension for expressing model merge 3.2.1 Merge relationship The MergeRelationship metaclass is a directed relationship between two CompositeElements. It extends the DirectedRelationship metaclass from the UML metamodel, and has two associations with the CompositeElement metaclass. This inheritance from MergeRelationship to DirectedRelationship represents one of the points where the UML2Merge is accommodated into the UML metamodel. The relationship is formed by two models – source and target –, which are CompositeElement constructs. A merge relationship produces a resulting merged model, or merged output model. It specifies how the content of a source model can be extended by the target model. The content of the target model is added to the source model to generate a merged output model. This relationship may be used to combine the content of different models that should represent a same concept, or even supply different meaning of a model element for different purposes. Each relationship aims at accommodating increments into the model elements found in the source model. With this in mind, using the merge relationship developers can evolve model elements with increments for different purposes, where each increment is defined in a particular target model. Creating a merge relationship means to establish a semantic interplay between the input models. This semantics may be defined by a merge strategy (Section 2.1.3), which can use, for example, a set of merge rules so that a desired merged model can be produced, . By using a merge relationship, developers can mitigate a critical problem previously mentioned – the UML incapacity of representing multiple merge relationships. Given that it is a DirectedRelationship, its navigability means that the merging should be established in a particular direction. 3.2.2 Associations The associations of MergeRelationship are introduced as follows: target: CompositeElement [1]. It specifies the target of a merge relationship, which is the model to be combined with the source one, the origin of the merge relationship. The multiplicity ‘1’ indicates that each merge relationship must have an instance of CompositeElement playing the role of target model. It also represents a subset of DirectedRelationship::target defined in the UML metamodel. source: CompositeElement [1]. It determines the source of a merge relationship. It is a CompositeElement, which is being extended with the contents of the target CompositeElement, and represents a subset of UML::Element::owner and UML::DirectedRelationship::source defined in the UML metamodel. merge: Merge [1]. It specifies the merge semantics must be applied to merge relationship. In Section 2.1.3, we suggest some strategies available in literature. match: Match [1]. It specifies the match strategy should be applied to merge relationship. The multiplicity ‘1’ determines that each merge relationship must have an instance of Match identifying how the input models (source and target ones) should be compared. transformation: Transformation[0..1]. It specifies a set of transformations that may be applied to resolve inconsistencies found in the merged output models. These transformations play an important role as they transform an output model with inconsistencies into a desired resulting model. The multiplicity ‘0..1’ indicates that the use of transformation is optional. The manner how these transformations are represented is out of the scope of this paper. 3.2.3 Semantics As previously mentioned (Section 2.1.3), a merge strategy is responsible for determining the semantics through which the content of the target model may be accommodated into the source model – in the same way that a subclass in a generalisation relationship consists of the aggregation of all features of all of its superclasses, and not only the increments attached by it. As a result of that, any reference to the content of the source model means to refer to the merged output model, rather than to the increment derived from the merged model. Fig. 5 shows this case by demonstrating that the packages and attach different contents to a particular model element of the merged output model. For example, the packages (source model) and (target model) determine different elements to the class Researcher, identified as .Researcher and .Researcher, respectively. Package merges the contents of package , which means to combine .Researcher and .Researcher. The package imports the contents of to define the subclass of Researcher, so-called Professor. Fig. 5Open in figure viewerPowerPoint Illustrative example of the merge relationship semantics. and represent the source and target models of the relationship, respectively. While is the source model, has a set of increments, which will be accommodated into to transform it into Thus, the class .Researcher represents the result of merging .Researcher and .Researcher, not just the model elements found in .Researcher upfront. The package imports the contents of . However, it refers to .Researcher rather than the .Researcher, resulting from the merge of .Researcher and .Researcher. As a result, the class .University has an attribute -people: Researcher[1..*], where the Researcher is derived from instead of . In contrast, Fig. 6 exhibits two merge relationships to demonstrate the need to express the order in which the merge relation
Referência(s)