Conflict Detection Specifications for the Singleton ...

Conflict Detection Specifications for the Singleton Design Pattern Antonio Cicchetti and Alessandro Rossini Dipartimento di Informatica Università degli Studi dell’Aquila, 67100 L’Aquila, Italy {[email protected], [email protected]}

Abstract. Increasingly, model driven development is being accepted as the new vision for designing software. In fact, shifting the focus from a code-centric standpoint to a model-centric one enables a better specification and understanding of domain specific concerns. Since a software system undergoes to several refinement steps during its life cycle, last years have witnessed a growing demand for model versioning support. In this respect, the operation of merging different modifications and the related conflict management are of crucial relevance. Usually, diverging modifications are detected by assuming a predefined set of issues; however, when the semantics plays a fundamental role it is not easy to predict all the problems. Hence, in this paper it is proposed to leverage conflict detection and resolution by adopting design-oriented descriptions endowed with custom conflict specification. Moreover, by using a running example, it is shown how to deal with a semantic problem which in general is not covered by current detection techniques.

1 Introduction In Model Driven Development (MDD) [15] models are intended as the primary artefacts of the development through techniques such as metamodeling and model transformations which play a central role. Problem descriptions are given by means of terms and concepts which are specific to a given application domain, allowing the experts to neglect the technological assets which are irrelevant for the functional description of the problems. The platform-specific knowledge is then opportunely encoded in model transformations which are used to glue the different levels of abstractions and enable the automated generation of the implementation. Similarly to common software artefacts, models are usually subjected to refactorings and updates during their own life cycles. Therefore the need for model versioning management is continuously increasing and some tools are already able to partly support it. In this respect, merging design documents representing modifications is one of the most important operations, both for its effectiveness and its technical complexity. For instance, in a distributed development environment could happen that more than one developer is going to modify the same document. Moreover, when dealing with relevant applications, there is often the concurrent development of several branches

2

Antonio Cicchetti and Alessandro Rossini

Fig. 1. An excerpt of the ZNF core design diagram.

of the same system. Consequently, conflict related issues can arise every time a unification procedure is performed. A number of works try to deal with such a problem (see Section 4 for further details); nevertheless they usually use implicit conflict detection mechanisms, i.e. methods which are based on a set of preconceived cases. This is mainly due to the inability to obtain an arbitrary accuracy method to deal with semantic interactions [9]. This work proposes a conflict definition technique by exploiting a domain-specific modeling language for describing conflict resolution criteria. In particular, on one hand it is possible to describe reconciliation criteria through weaving models [3]. On the other hand, the same specification can be interpreted as a declaration of further collisions between element manipulations, i.e. as an extension of the detected conflict spectrum. The aim is to propose a flexible conflict management approach by leveraging the abstraction level; this improvement can be considered as a step toward the support of domain specific versioning through customized conflict sets. Finally, the discussion is illustrated by a running example throughout the paper. The structure of the paper is as follow: next section introduces version management in the context of MDD, a conflict resolution mechanism, and presents the running example. Then, after the explanation of the motivating issue, Section 3 illustrates the proposed solution while Section 4 gives an overview of the related works about conflict detection and structural weaving techniques. Finally, Section 5 draws the conclusions and presents some perspective work.

Conflict Detection Specifications for the Singleton Design Pattern

3

2 Model Versioning and Conflicts Adhering more and more to the everything is a model vision [3] requires a growing set of instruments being able to support the whole system life cycle as the current objectoriented environments, for instance. Such instruments should necessarily deal also with the version management, since in general a model undergoes to several changes and refactorings during the application evolution. Current text-based version management tools | like Subversion version control system [2] for instance | provide with functionalities such as differencing, branching, merging and tagging which could be useful with models too. Despite it is possible to serialize models by means of the XMI specification [12], the just mentioned approaches present difficulties because of their low level of abstraction which makes them to neglect semantic details. Therefore, a number of tool is currently trying to face some aspects related to versioning like model differencing ([5,11,22] to mention a few). The various kinds of design-level structural modifications can be detected for specifying differences in subsequent versions of design documents. Increasingly, complex software systems are cooperatively designed in distributed environments. Thus, the interaction among such manipulations inevitably involves conflicts which must be reconciled. Some cases can be trivially solved, while others require a particular update ordering to apply (known as asymmetric conflicts [10]). On the contrary, the remaining need a direct intervention of the developers, who can be supported by automated reduction mechanisms (see [6] for example). Anyway, usually merging approaches are based on an implicit conflict detection capability, i.e. an a priori evaluation is made to understand which problems can come to light and what are the ones to be checked. The underlying limitation is the impossibility to build a technique endowed with arbitrary accuracy [9] which forces developers to look for a trade-off between false-positive and false-negative occurrences. Going deeper, if the specification of the conflicts is too precise there will be a lot of potential issues which will be discarded, i.e. a lot of false-negatives; on the other hand, a too wide typology will make the engine to recognize a lot of false-positives. The methodologies affected by such compromise tend to be not easily adaptable to different application domains. In fact, each domain has a set of its own semantic dependencies which need to be specified to obtain a useful detection and resolution method. Therefore this work proposes a model-driven conflict specification mechanism to enable the extension of predefined collision sets. The aim is to improve the flexibility of detection approaches, making it possible to relate the supervised issues to each particular context in order to give place to domain specific conflict management tools. In the sequel, an existing technique is introduced for automating version reconciliation which will be exploited as a starting point of our attempt. 2.1

A proposal of conflict resolution automation

In [6] it is described a proposal to deal with the automation of conflict resolution1 . It is supported by means of a UML profile through which it is possible to input weaving 1

For sake of space, it is provided only a brief introduction to highlight the important properties we exploited

4

Antonio Cicchetti and Alessandro Rossini

models to specify reconciliation criteria. Each version is represented by means of a delta document, i.e. the description of differences between an ancestor and one of its updates. Therefore, models conforming to the proposed profile are made up of two patterns, each of which can be matched against elements in the related delta, respectively. Each of the just mentioned couples represents conflicting manipulations which have to be solved, and appears in weaving models linked by an undirected association; further, it is decorated with three tagged values, namely appliedTo, rules and criteria. The first tag can be valued class, attributes, methods or attributes,methods (default), and is used to modulate the granularity of the rules application. The second one specifies the rules which will be used in the criteria; for example create: stereotype contains "create" declares a rule named create which returns true if the current element is ≪create≫ stereotyped. Finally, the third tag denotes the desired criteria by means of rules and boolean operators, and it is used to drive modifications composition. One of the useful mechanisms provided with the presented approach is the ability to specify, for instance, to match against all classes by means of ≪metaclass≫. Further, in such a case the name of the class is used as a reference which is bound to the values from the existing matches. In the following, after the description of the motivating example, our extension attempt is illustrated to deal with conflict specification.

2.2

A running example

The discussion will be illustrated by means of a running example, which will be used both to motivate and to clarify the proposed solution. ZNF [21] is an open-source framework for building enterprise PHP5 web applications based on the Model-ViewController design pattern (MVC) [8]. Even if it was initially inspired to the Apache Struts Project [1], now it can be considered a stand-alone architecture 2 . Figure 1 shows an excerpt of the version 0.7.0 of the core design diagram of the framework. The ZNF class acts as the front controller. It uses the Action::RequestProcessor that contains the processing logic flow and provides a single point of control for security and logging. Moreover, it encapsulates incoming data into an Action::ActionForm usable by the back-end MVC model. Action::Action is an adapter between the contents of an incoming request and the corresponding business logic. The Action::RequestProcessor selects for each request an appropriate Action::Action subclass, according to a set of rules that are provided at deployment time by means of configuration files. By only manipulating such files, which are parsed by the Config::ModulesConfig class, it is possible to change the control flow. At run-time, the controller is said to “execute actions”, which means that the class invokes the execute() method of each of the instantiated actions depending on the mapping specification represented by Action::ActionMapping. Finally, the controller redirects toward another action or a view according to an instance of Action::ActionForward, that is returned from the previous execution. 2

Due to space limitations this description can not be complete. For further details the reader can refer to [21]

Conflict Detection Specifications for the Singleton Design Pattern

a)

5

b)

Fig. 2. The delta documents resulting from the parallel version updates.

3 Towards a Flexible Conflict Management In the sequel, after the presentation of the motivating problem will be described an attempt to model custom conflicts by exploiting the existing reconciliation mechanism described above. 3.1

Motivation

Starting from the ZNF version briefly outlined in Section 2 it has been performed a branching to obtain the following enhancements: a) the operation devoted to the configuration parsing has to be moved from Config::ModulesConfig to a general purpose parser class, which taking the entered configuration file is able to return the result into a bi-dimensional array of strings; b) Config::ModulesConfig has to be refactored to enable the configuration sharing between the various components. Therefore, two developers (who will be called A and B, respectively) worked in parallel on the concurrent versions giving place to their own delta documents. Going into more details, the first developer added the Config::ConfigParser class implementing the parser function. Moreover, she/he decided to set the obtained configuration by passing it a parameter to the constructor of Config::ModulesConfig. Finally, the necessary relations have been added. The illustrated updates have been represented by means of the DSML exploited in [6] too, and the result is depicted in Figure 2.a. On the other hand, developer B has chosen to implement the singleton design pattern [7] to provide with a unique shared instantiation of Config::ModulesConfig. Consequently she/he updated that class modifying its constructor visibility, adding a new attribute for storing the shared class instance, and adding a getter method to retrieve such instance. In Figure 2.b can be seen the outcome of the just described refactoring. Once the single modifications have been successfully delivered, a merge operation should be performed to unify the concurrent branches. By examining the two delta documents it can be verified that there are conflicts which can be easily solved, since there are no diverging properties. However, the resulting configuration class (namely Config::ModulesConfig) will have two constructors: the default one with the private

6

Antonio Cicchetti and Alessandro Rossini

Fig. 3. The weaving model for the specification of conflicts related to the singleton design pattern

visibility from the manipulations in B, and the public overloaded one which takes as input the parsed configuration from delta A. Hence, taking into account the semantics behind the singleton, a problem comes to light. In fact, the accessibility of the latter constructor breaks that design pattern principles. Therefore, we will need a way to specify the just discovered non-canonical conflicts. In the following, it is described a proposal to extend the use of an existing conflict resolution technique to support a definition mechanism too. 3.2

Proposed approach

Our proposal starts from a simple consideration around the mechanism in [6]: when the developer specifies a pattern for the conflict resolution, in the meantime she/he is also pointing out to the reconciliation engine what issues to take care of. Hence, each weaving model conforming to the UML profile of the mentioned technique can have a twofold interpretation: on one hand it describe how to deal with diverging versions, on the other hand it implicitly declares patterns of conflicts. Therefore, we tried to describe the semantic problem related to the singleton which has been outlined above, by means of the existing profile. Figure 3 depicts the necessary pattern for the conflict specification: the left side of the figure shows modifications which are not allowed to preserve the singleton prescriptions. On the right side, such design pattern is visualized. Going into more details, the unwanted manipulations are represented by means of a structural pattern which means to match against all classes in the considered delta document which are ≪updated≫ stereotyped. Moreover, such update should either make public the class instance by an attribute (an:Cn), or provide with a public constructor from the same class (Cn()). On the other side, the pattern will make the resolution engine to look for an update in the differences such that the singleton is applied by means of ≪Singleton≫ stereotype. Finally the illustrated patterns are linked together by an undirected association, and the tagged values are used to particularize the mechanism intervention pointing out to choose the whole update (appliedTo={class}) which prescribes the singleton adoption.

Conflict Detection Specifications for the Singleton Design Pattern

7

It has to be noted that the name of the generic class used for the patterns acts as a variable which is instantiated each time a valid match is found. This particular is necessary to be sure that the diverging updates involve the same element, otherwise the risk is to pick up such kind of manipulations corresponding to different classes. The main advantage gained by using this approach is the ability to have a conflict resolution mechanism with a high flexibility ratio. For example, it could be possible to define domain specific conflicts and to map them to the corresponding weaving models as explained during the discussion above. In this respect, the specification of incoherent manipulations related to each kind of design pattern is enabled. From this point of view, an interesting property is the possibility to exploit the same delta document to validate a single modification itself. In fact, in the case of the singleton for instance, the left side of the specification would capture wrong updates, while the right side would every give priority to the pattern. Thus, it is automatically induced a correction of the changes. Finally, a further application could be attempted in the context of tool integration and chaining [19]. By using the weaving models could be pointed out where to link the tools each others and how to solve and to adapt conflicting data. By the way, the experiments shown in this work revealed some drawbacks about the chosen method. First of all, since a not predicate is missing it is not possible to describe the only allowed situation. This aspect forces the developer to enumerate all the wrong cases, which hampers the usability and scalability of the approach. Moreover, several circumstances could benefit of wild-card mechanisms to select a narrowed set of classes, attributes and all the other model components, similarly to the one proposed in [16].

4 Related Work The weaving operation [4] is a technique devoted to model composition. In general it is used to link semantically related elements between models and to elicit some properties from such relations as in metadata integration [13]. The presented conflict definition profile is based on weaving models; in fact, it is used to relate elements between models (delta documents), and by means of tagged values it is possible to derive useful information to build the results. To the best of our knowledge, composition of differences is only partly considered in few works which mainly focus on software refactoring; for example in [10] the authors propose a graph-based technique to discover couples of manipulation conflicts (critical pairs). Then, a set of conflict reduction heuristics is given, even if the developer can not specify her/his own resolution criteria. The work in [18] deals with differences occurring on systems developed in parallel; through the use of program slicing and system dependency graphs semantic interferences are detected. However, the level of abstraction is too low with respect to models. In [20] is illustrated a graph-based metamodeling framework to face some MOF issues. The interesting aspect of such paper is the introduction of a static consistency analysis technique which can be exploited to detect and partially resolve conflicts caused by model refinements. By using such property, a solution to the UML 2 merge operation between packages is shown. A way to describe how to deal with composition of

8

Antonio Cicchetti and Alessandro Rossini

structural diagrams is given in [17] through directives. Such technique could be useful to merge delta documents; also in this case, we think that it works at a low level of abstraction which does not allow to define reconciliation criteria based, for instance, on developers’ roles. Finally, in [14] a number of operators for model integration are described, both for a sequential and a parallel composition of models, i.e. for sewing and weaving operation, respectively. As said during the description of the approach, this paper is a contribution with respect to the work in [6]. That work is based, as well as the approaches briefly illustrated above, on what we called during this work implicit detection, i.e. a set of expected conflicts built by using authors’ experience and/or domain specific requirements. With respect of it, we try to deal with conflict specification; in fact, even if the previous approach contains an interesting automation for the reconciliation of concurrent versions, in our opinion the concern illustrated here is really important to complete the version merging. Because of the high level of abstraction and the fundamental relevance of the semantics, it is realistic to have several conflicting situations which can not be captured by a priori detection mechanisms.

5 Conclusion and Future Work A fully MDD support to the software life cycle should encompass model version management, since system development and evolution processes require to modify the involved artefacts several times. A number of approaches is currently trying to deal with such task starting from the difference calculation and the combination of the consequent results. In this context, this paper motivated the need for a conflict definition mechanism being able to make conflict resolution engines more flexible. In fact, usually they are based on implicit or predetermined sets of issues, often derived from the designer experience and/or domain specific point of views. Unfortunately, sometimes the abstraction level of models causes unforeseen semantic divergences come to light. Hence, starting from an existing technique for the specification of conflict reconciliation, it is proposed a way to extend such mechanism by adding models which will have a twofold interpretation: on one hand they depict a conflict pattern, and on the other hand they include criteria for the resolution. However, the adopted methodology has shown some limitations, especially from the expressiveness point of view. In fact, it is missing some construct to express negative conditions, causing the complete enumeration of positive cases. This problem could make the conflict definition an error prone task and could hamper the scalability of the approach. Therefore future works should include an improvement of the modeling language used to define/resolve conflicts; moreover, it is required a deeper investigation of relationships between design patterns and the related constraints. In fact, we think that could be possible to locate a set of well defined conflicts linked to each particular pattern.

References 1. Apache Struts: Project Web Site, http://struts.apache.org/

Conflict Detection Specifications for the Singleton Design Pattern

9

2. Apache Subversion: Project Web Site, http://subversion.apache.org/ 3. Bézivin, J.: On the unification power of models. Software and Systems Modeling 4(2), 171– 188 (2005) 4. Bézivin, J., Jouault, F., Valduriez, P.: First Experiments with a ModelWeaver. In: OOPSLA Workshop on Best Practices for Model-Driven Software Development (2004) 5. Borland Software Corporation: Borland Together, http://www.borland.com/us/ products/together/index.aspx 6. Cicchetti, A., Di Ruscio, D., Pierantonio, A.: Composition of Model Differences. In: Proceedings of CMT 2006: 1 st European Workshop on Composition of Model Transformations. pp. 9–14 (July 2006) 7. Gamma, E., Helm, R., Johnson, R., Vlissides, J.M.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional (1994) 8. Krasner, G.E., Pope, S.T.: A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming 1, 26–49 (August 1988) 9. Mens, T.: A State-of-the-Art Survey on Software Merging. IEEE Transactions on Software Engineering 28(5), 449–462 (2002) 10. Mens, T., Taentzer, G., Runge, O.: Detecting Structural Refactoring Conflicts Using Critical Pair Analysis. Electronic Notes in Theoretical Computer Science 127(3), 113–128 (2005) 11. No Magic Inc.: MagicDraw, http://www.magicdraw.com/ 12. Object Management Group: XML Metadata Interchange Specification (December 2007), http://www.omg.org/spec/XMI/2.1.1/ 13. Pottinger, R.A., Bernstein, P.A.: Merging Models Based on Given Correspondences. In: Proceedings of VLDB 2003: 29th International Conference on Very Large Databases. pp. 862– 873. VLDB Endowment (2003) 14. Reiter, T., Kapsammer, E., Retschitzegger, W., Schwinger, W.: Model Integration Through Mega Operations. In: Proceedings of MDWE 2005: International Workshop on Model-driven Web Engineering (2005) 15. Selic, B.: The Pragmatics of Model-Driven Development. IEEE Software 20(5), 19–25 (2003) 16. Stein, D., Hanenberg, S., Unland, R.: A Graphical Notation to Specify Model Queries for MDA Transformations on UML Models. In: Proceedings of MDAFA 2003 and MDAFA 2004: Workshop on Model Driven Architecture: Foundations and Applications. Lecture Notes in Computer Science, vol. 3599, pp. 77–92. Springer (2005) 17. Straw, G., Georg, G., Song, E., Ghosh, S., France, R.B., Bieman, J.M.: Model Composition Directives. In: Baar, T., Strohmeier, A., Moreira, A.M.D., Mellor, S.J. (eds.) Proceedings of UML 2004: 7th International Conference on The Unified Modeling Language, Modeling Languages and Applications. Lecture Notes in Computer Science, vol. 3273, pp. 84–97. Springer (2004) 18. Thione, G.L., Perry, D.E.: Parallel Changes: Detecting Semantic Interferences. In: Proceedings of COMPSAC 2005: 29th Annual International Computer Software and Applications Conference. pp. 47–56. IEEE Computer Society (2005) 19. Tratt, L.: Model transformations and tool integration. Software and Systems Modeling 4(2), 112–122 (2005) 20. Varró, D., Pataricza, A.: VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and UML (The Mathematics of Metamodeling is Metamodeling Mathematics). Software and Systems Modeling 2(3), 187–210 (2003) 21. ZNF: Project Web Site, http://www.zeronotice.org/ 22. Zündorf, A., Wadsack, J., Rockel, I.: Merging Graph-Like Object Structures. In: Proceedings of SCM-10: 10th International Workshop on Software Configuration Management (2001)