A single software program can be designed differently by different software developers. While one design is readable, robust and easy to maintain the other can be complex, hard to read and change. The quality of the design also depends on the experience of the developer. To overcome these issues software design patterns are used extensively in software engineering. Further software design patterns speed up the development without compromising the design quality. These patterns are documented and published by experienced and respected programmers [1,2,3,4].
However there exists some issues about the usability of the design patterns. One of these is the difficulty for the software developers to learn about all necessary design patterns [5]. It is also hard to memorize them all and it is inconvenient to refer these as and when you design software. To overcome these issues, researchers suggest that there should be some tool support regarding the application of software design patterns. For an example some researchers have created recommendation systems to suggest necessary design patterns [6,7]. There are also studies carried out to automatically detect the existence of design patterns in software designs/code [5,8,9].
But the main challenge in this regard has been to model and represent design patterns in a machine-readable form. This paper presents a survey of such knowledge representation techniques used to represent design patterns with an emphasis towards model transformations. Finally, the best option is chosen to be used for authors' ultimate goal, which is to automate/semi-automate application of a design pattern upon a given software model/design.
There is no common specification for documenting design patterns as different forms have been used so far by pattern authors. Fowler mentions some of these forms such as GoF, Portland Coplien, POSA and P of EAA [10]. GoF Form is the most comprehensive and nicely structured form among these. However, GoF patterns are quite large with many pages of descriptions.
Software developers usually first come up with the models for the business case and then manually refine the models applying the selected software design patterns. For example, software engineers initially design the class diagram for the underlying business case. Then they refine the class diagram by applying necessary design patterns. However, developers should be initially aware of a particular design pattern and its applicability in order to benefit from it. A developer is also responsible for properly implementing the suggested design pattern in his context.
Model transformation techniques can be used to automate or semi-automate this process. They can be utilized to validate the manually refined models as well. Modeldriven engineering (MDE) is considered as a well-established software development methodology that uses abstraction to bridge the gap between the problem space and the software implementation [11,12]. Model transformations constitute the essence of MDE [13].
3 Existing Knowledge Representation Techniques for Software Design Patterns
These approaches are based on the concepts and technologies of semantic web such as Web Ontology Language (OWL) [14] and Resource Description Framework (RDF) [15]. The major contribution in this category for coming up with a representation for software design patterns is from Dietrich and Elgar [16,17]. They have come up with an OWL ontology named Object Design Ontology Layer (ODOL) [18]. Then they have extended the ontology by adding pattern refinement [18]. Dietrich and Elgar have made a prototype of a Java client to show how ODOL can be used. This prototype software can access the ODOL based pattern definitions which are published online and can detect patterns in Java programs.
Initially ODOL has only supported structural properties of the design patterns. Later, Di Martino and Esposito have further extended ODOL to support dynamic behaviour of the design patterns and also to support cloud patterns [9]. They have revised original ODOL to support pattern categorization. Structure of this augmented ODOL is shown in Figure 1. Further OWL-S [18] has been used to describe behaviour of the pattern. OWL-S defines how the different participants communicate and relate to each other dynamically. Then, they have used this representation of design patterns to come up with a rule-based procedure to automatically recognize design patterns in UML diagrams. Each design pattern is individually converted to a set of first-order logic rules in Prolog by the use of Thea framework [19]. In parallel, the UML model which needs to be analyzed is converted to XMI (XML Metadata Interchange) with the use of existing tools and then converted to Prolog facts using their own tool. Then using Prolog based inference rules specified they could check whether a respective design pattern exists in the UML model under investigation. ODOL has been also used to represent design patterns in an attempt to automate the Sequence Diagram generation when realizing a particular design pattern [20]. In this case, the OWL based representation of design patterns are converted into Java Expert System Shell (Jess) facts by using a conversion tool, called SweetRules. Then the Jess rule engine is used for the execution of design pattern rules to produce an output sequence diagram.
Ontology based representations of design patterns have following aspects [16].
• Formal definition of patterns • Machine readable representation • Modular design that supports the separation of schema and instances • Compatibility with standard web
Formal approaches represent design patterns based on mathematics and formal logic. One of the earliest such approaches is Language for Pattern Uniform Specification (LePUS) [21]. This has only covered the structure of design patterns. On the contrary, Distributed Co-operation (DisCo) specification supports the behavioural aspect of patterns [22]. Taibi and Ngo, who have been inspired from both LePUS and DisCo have come up with Balanced Pattern Specification Language (BPSL) [23]. BPSL combines the First Order Logic (FOL) and Temporal Logic of Actions (TLA) to support both structural and behavioural aspects of design patterns.
Jeon et. al. have also come up with their own formal specification of design patterns [24]. Inference rules are derived for design patterns and then these rules are saved as Prolog rules. This Prolog rule base is used to find candidate spots in Java program code to apply a certain design pattern.
Formal approaches have been emerged in order to remove ambiguity, support reasoning about patterns and facilitate automation. However as per Khwaja and Alshayeb, formal specifications are not popular in the software industry [25]. They mention that formal specifications are hard to use with less tool support while requiring strong mathematical background from the user.
Design Pattern Modelling Language (DPML) is a visual language that can be used to represent software design patterns [26]. DPML can be used along with UML as it also supports instantiation of the design patterns into UML design models. However, DPML does not support dynamic aspects of design and meta-data of design patterns. Other drawbacks are the lacking tool support and notational differences from UML.
Role Based Metamodeling Language (RBML) is another UML based pattern specification language [27]. RBML specifies the pattern solutions as a specialization of the UML metamodel. RBML provides 3 types of specifications; Static, Interaction and StateMachine in order to handle both structural and behavioural aspects of the design patterns. Each RBML specification is an instance of the RBML metamodel. A tool called RBML-Pattern Instantiator (RBML-PI) has been also created to generate a UML model from an RBML pattern specification.
These approaches are complex and require dedicated tool support which is not abundant. Therefore, not many applications could be found in the literature leveraging these specifications. Further these approaches fail to represent the textual descriptions which describe design patterns.
Khwaja and Alshayeb have come up with Design Pattern Definition Language (DPDL) based on XML (Extensible Markup Language) to share design patterns between developers [25]. They have reviewed most of other techniques mentioned above and have chosen XML as it is popular and easy to understand. DPDL supports both structural and behavioural views of the design patterns. High level schema of DPDL is shown in Figure 2.
Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering [28]. The MOF 2.0 Queries Views and Transformations (QVT) provides a standard for expressing model transformations. Judson et. al. have come up with an approach to automate pattern-based transformations leveraging the MOF 2.0 standards in meta-model level [29]. Overview of their approach is depicted in Figure 3 The main drawback with their approach is the necessity to prepare a Source Pattern for each design pattern to be applied in a specific scenario. However, it is nice if the freedom is given to the developer to specify the Source Pattern. For an example the developer can choose artefacts from a UML model and ask the transformation engine to transform them by applying a certain design pattern. For an example he/she can mark a certain class in the UML diagram and apply Singleton pattern over it. Then transformation engine should be robust enough to transform the source model accordingly. However major challenge in this regard is to dynamically generate Transformation Schema and Transformation Constraints for a specific application of a design pattern. This will be not feasible unless the design patterns are represented in a machinereadable format. ODOL + OWL-S seems to be the best choice as per the review in section 4 and it is popularity. The represented design patterns will be not limited to a specific purpose as the definitions can be shared online for public access. Another advantage of this is the fact that OWL supports different syntaxes such as RDF/XML, OWL2/XML and Manchester. Therefore the developers get ample options to adjust according to their tool stack. DPDL also cannot be left out as it stands out with ease of use and shorter learning curve as a second choice.
In this paper, existing knowledge representation techniques for software design patterns were reviewed with a focus on using them for model transformations. Introductions about software design patterns and model transformations were also included to provide a complete overview of the subject domain. In the discussion, the importance of design pattern specification techniques for pattern based model transformations was presented with example usage. Finally, the best design pattern specification techniques were recommended for the tasks of model transformation.