Patterns are recurring design solutions that have been refined over the years by many practitioners to address common design problems. Patterns are usually informally described in the literature for the purpose of education. However, for tools to work with patterns, they need to be formally specified in a machine consumable format. Once formalized, patterns can be either applied or detected in user models.
Pattern detection is one of the fundamental kinds of analysis that can be performed on structured models. Several approaches for pattern detection are available in today's tools based on the way patterns are formalized. In the most rudimentary case, patterns are not formalized and their algorithms are manually coded for every specific pattern. This approach, although flexible, is usually complex to implement, costly to maintain in addition to being error-prone. A better approach is to model an algorithm as a decision tree (Sauve, Alex, “Systems and Computer Engineering,” Masters Thesis, Carleton University, 2005). Although at a higher level of abstraction than code, it still suffers from the same problem, namely the unobvious correspondence between the structure of the pattern and its detection algorithm. The benefits of algorithm flexibility are usually offset by the costs of algorithm validation and maintenance.
When patterns are formalized, detection algorithms tend to be more rigorous. For example, patterns specified with a mathematical notation are usually detected by solvers that employ pattern detection algorithms (see Eden, A. H. et al., “LePUS—A declarative pattern specification language,” Technical Report 326/98, Department of Computer Science, Tel Aviv University, 1998). Although this approach mitigates the need to explicitly think about a detection algorithm, it still suffers from few disadvantages. First, models created in most modeling tools need to be converted to this notation before being analyzed; usually at a performance cost. Another disadvantage is the inherent complexity of the used notation to average modelers.
Another approach to pattern formalization is to specify pattern elements as extensions to their domain meta-model elements (see France, R. B. et al., “A UML-Based Pattern Specification Technique, IEEE Transactions on Software Engineering 30(3)193-206, March 2004). Patterns defined in such fashion can be detected by an algorithm that traverses the input model guided by the pattern meta-model. This approach mitigates the conversion problem of the mathematical notation. However, it lacks the ability to configure the detection algorithm. It also lacks a context to the pattern definition that is required to reuse the definition and to represent detected pattern instances. Finally, it forces the definition to have the same complexity as the related part of the domain meta-model complicating pattern detection.
A new pattern specification formalism called Epattern has been recently defined by the same assignee of the present invention. The new formalism is proposed as an extension of the Ecore meta-model for the purpose of pattern specification. Epattern adds to Ecore new semantics inspired from the composite structure semantics of UML 2.0. As a meta-modeling approach, Epattern focuses mainly on the specification of patterns rather than on their detection algorithms and has simpler semantics than those of the mathematical approaches. What is lacking in Epattern is a configurable pattern detection strategy that integrates with all the semantics of the formalism and allows the pattern author to use some knowledge from the target domain to make it more efficient and scalable.
Pattern specification is a common denominator to most work in applied pattern research. Various approaches have been proposed for pattern specification (Baroni, A. et al., “Design Patterns Formalization”, Ecole Notionale Superieure des Techniques Industrielles, Research Report 03/3/INFO, 2003 and Technical Report 2002). One category of approaches, that Applicant's work also belongs to, uses meta-modeling techniques. The work presented in Guennec, A. et al., “Precise Modeling of Design Patterns,” Proceedings of UML 2000, Vol. 1939 of LNCS, pp. 482-496, Springer Verlag 2000 and Mak, J. “Precise Modeling of Design Patterns in UML,” in Proceedings of the 26th International Conference on Software Engineering, 2004, proposes specifying a pattern as a UML 1.5 meta-collaboration with pattern roles typed with M1 classes stereotyped <<meta>> and named after meta-classes. This obviously prevents writing constraints for such roles as their type information is not available at level M1. Also the binding between a role and an element playing that role is modeled with an explicit dependency relationship. This is in contrast to Applicant's approach which depends on a natural binding between an attribute of a class (the role) and its value (the bound element).
The work in Kim, D., “A UML-Based Metamodeling Language to Specify Design Patterns”, in Proceedings of WISME, UML Conference, October 2003, introduces the RBML language, which is used to specify UML patterns as specialized UML meta-models. Pattern roles are specified as sub-classes of their base meta-classes in UML and are related to each other through new meta-associations. One problem with specifying a pattern as a meta-model, rather than a meta-class as in Applicant's approach, is the inability to inherit or compose the pattern which hinders scalability. Another disadvantage is that role binding is done through a generic mapping scheme and is not conveniently an instantiation of the pattern meta-class and an assignment of role values.
Restated, Applicant finds that use of domain model data (model objects) instead of meta-data (as in the present invention) to describe a pattern limits the expression of the pattern to the semantics of the domain model. This poses a problem if the domain does not have sufficient semantics to completely specify a pattern. Also, this complicates building domain-independent tools that read and process pattern definitions for the purposes of application or detection.
Another proposal is found in Maplesden, D. et al., “Design Pattern Modelling and Instantiation using DPML,” in Proceedings of Tools Pacfic 2002, p. 18-21, Sydney, Australia, February 2002, where the DPML language is used to visually specify patterns as a collection of participants, dimensions (multiplicities), relationships and constraints. One drawback is the non-standard notation adopted by the language. Another problem is the restriction of the participants and relationships to predefined types from the UML domain, which limits the scope of the patterns definable by the language. Also, there is no mention of complexity management features.
Another approach (Albin-Amiot, H. and Y. G. Gueheneuc, “Metamodeling Design Patterns: Application to Pattern Detection and Code Synthesis”, in Proceedings of the ECOOP 2001 Workshop on Adaptive Object-Models and MetaModeling Techniques, 2001) provides a meta-model to specify patterns. This meta-model is first specialized with pattern domain meta-classes (i.e., meta-classes for every role) before being instantiated to produce an abstract model (pattern specification). Then that model is either instantiated to create a concrete model (pattern instance) or parameterized to use in pattern detection. The provided meta-model contains pattern-domain meta-classes in addition to meta-classes from a target domain (e.g., UML) defined as their subclasses. This need to redefine required meta-classes from the target domain in the pattern meta-model greatly limits the generality and practicality of the approach.
To summarize the key differences with Applicant's pattern modeling framework (PMF), most of the above approaches lack the ability to specify patterns for languages other than UML or viewpoints other than the class diagram. They also lack features (e.g., user-defined associations and composition) that help alleviate the complexity of pattern specification. Additionally, some specify M2-level patterns at M1 which deprives them from using free features like pattern constraints and role binding through pattern instantiation. Finally they lack a well-defined process that allows pattern authors the tools to build, refine and simplify patterns in a stepwise manner.