Paper Title (use style: paper title)



Towards A Catalogue of Design Patterns Variants

Ghulam Rasool, Hassan Akhtar

Department of Compute Science, Comsats Institute of IT Lahore

Email:grasool@ciitlahore.edu.pk

Abstract---With increasing applications of design patterns and their variations for development of software applications, the accurate recovery of patterns from existing applications remained active research area in the last decade. The variations in standard patterns hamper accuracy of pattern recovery techniques and tools. There is no standard catalogue on all variants of Gang of Four(GoF) design patterns in literature. We present a catalogue on variations of GoF design patterns in this paper that are discussed in different publications, venues and forums at different levels of abstraction. The presented catalogue with 100 plus variants of standard patterns will serve as a knowledgebase for the design pattern research community and it may be used to specify GoF patterns and their variants. We evaluated three state of the art design patterns recovery tools on variants of selected design patterns and realize that state of the art tools are not capable to recognize all variants of GoF patterns. The critical analysis and observations on GoF design patterns and their variants are presented based on the whole study and our experience.

Index Terms— Design Patterns, Reverse Engineering, Variants of Patterns, Pattern detection, Program comprehension

Introduction

Design Patterns gained popularity first time with the publication of GoF[1] book and they are classified into creational, structural and behavioral categories with respect to the purpose of each pattern and into class and object categories with respect to scope of an individual pattern. Some patterns have been incorporated into widely used architectures and frameworks [2]. It is a common consensus that proper application of patterns enhances the productivity of developers depending upon their experience and skill levels. Each pattern has unique intent and they are applied in different applications as proven solutions. Since GoF book was the first book with standard catalogue of 23 patterns but recently developers also apply variants of standard patterns in different scenarios to solve problems. These variants follow the same intent as defined by the GoF, but developers use different implementations of a same pattern that better suits to the situation. The variations in standard design patterns are one of the most challenging problem for accurate recovery of patterns from source code [38, 51]. A pattern X can have Y number of implementations based on the requirements and decision of the developer at the time of implementation. The major dilemma is that one can precisely define a pattern but there is still no agreed upon single definition for each variant of a standard pattern. Design patterns discussed by GoF are presented with different structural and implementation variants by different authors [3, 4, 5, 6, 11, 20, 23].

Structural variants are visible in the UML diagrams of patterns. For example, a structural variant of the proxy pattern is realized when Subject class plays the dual role of Subject as well as realsubject class. Similarly, Composite design pattern has number of structural variants as discussed in [29, 32]. The implementation variants of design patterns are due to implementation of a same concept using different methods. These variants are also seen due to new programming language constructs. Modern programming languages features such as generics, code annotations, reflection, dynamic types and lambdas give developers a choice for the implementation of similar features using different constructs. These new features of programming languages make developers task easier for implementation of patterns but creates problems for the pattern recovery approaches and tools. The automated tools based on hard coded algorithms are not capable to recognize these variations and as a result their accuracy is affected. The combinations of structural and implementation features of standard patterns also create new variants of same patterns. The knowledge of specification of all patterns with all possible variants is required for design pattern recovery tools to solve this problem.

There is still limitation of mature literature in the form of books, conference proceedings and journals on variations of design patterns. Most variants are discussed at different blogs, websites and discussion forums. Variants discussed at different sources are scattered and there is still no standard catalogue on all discussed variants that is enviable for design pattern research community. Such a catalogue will be beneficial for the existing and new design pattern recovery tools for incorporating knowledge of new discovered variants in their tools. In last decade, different pattern recovery techniques and tools [8, 9, 10, 12] are presented and applied to recover patterns from legacy applications for the purpose of reverse engineering, re-engineering and maintenance of different applications. To the best of our knowledge, there is still no pattern recovery technique that claimed 100 % accuracy in recognized patterns due to different constraints and limitations. The accuracy of pattern recovery techniques vary due to system size, selected baselines, precision/recall, incomplete roles and variants [7]. We did manual analysis of different open source systems[18, 19] that are developed using different design patterns and realized that variations in definitions of standard patterns are major cause of disparity in results rendered by different pattern recovery techniques. The major causes in the low accuracy of recent pattern recognition tools is that they take standard definitions of patterns during pattern recovery process but they do not take all variants of a pattern into consideration during pattern recovery process. Formal specification techniques are also used to define structural and behavioral features of patterns to solve this problem but these techniques also require knowledge of all variants for specification of patterns and their variants. A number of papers [3, 4, 5, 6, 11, 20, 23] are presented on the variants of different design patterns in literature, but we did not find any single complete catalogue with standard format of all variants at one place that is agreed upon by all researchers.

A catalogue on the different structural and implementation variants of creational, structural and behavioral design patterns is presented in this paper. The presented catalogue helps in better understanding of applications of the variants of design patterns which were originally discussed in GoF. The catalogue includes all possible variants discussed in different publications and at other discussion forums [13, 14, 15, 16]. The variants discussed in previous publications are at an abstract level and they are not presented in a standard format. The complete catalogue of all variants also forms a knowledgebase that helps to assess the accuracy of pattern detection techniques and tools. We selected the Singleton, Composite and Command design patterns as examples for discussing motivation of the study throughout the paper. These patterns are selected due to their variations and to cover each category from creational, structural and behavioral classification of GoF. We published detailed information about all other variants on the web [24]. We also evaluated existing state of the art tools on variants of Singleton, Composite, Command, Adapter, Decorator, Proxy and Abstract Factory design patterns. We present our observations and recommendations based on the review of literature on variants of design patterns. The rest of paper is organized as follows:

Section 2 presents the background and motivation for the paper. A catalogue of variants is presented in section 3. The evaluation of selected variants through state of the art design pattern recovery tools is discussed in section 4. The critical analysis and observations based on the whole study are presented in section 5. Finally, conclusion and future work is discussed in section 6.

background and motivation

We discuss motivation of presenting design patterns variant catalogue using three design patterns namely Singleton, Composite and Command throughout this paper for better comprehension and information flow. We publish detailed information about catalogue on web in order to curtail space [24]. We discuss factors that cause variations in these patterns.

Reference [6] presented implementation variants of the Singleton design pattern. Authors discussed different implementation variants of the Singleton and came up with single formal definition of Singleton that is used to recognize all variants of that pattern. They discussed eight variants of the Singleton and existing state of the art tools are not capable to recognize all variants of that pattern. Authors claimed accurate detection of all discussed variants in their pattern detection approach [6], but the tool applied for detection of patterns and their variants is not available publically to validate their claim. Through an intensive analysis of literature, we found 4 more variants of the same pattern as presented in Table 1. The number of variants in Singleton motivated us to explore the variants of other patterns that are discussed in the next section. We want to clarify that scope of this paper is limited only to variants of GoF design patterns. Figure 1 highlights key features in source code snips that vary for each variant of the Singleton pattern. We briefly discuss variants of Singleton in this section. We created definitions for all of these variants using features types presented in [8] and evaluated these definitions using different tools. The detail about detection and evaluation of these variants is given in section 4. Moreover, the variants in Figure 1 are ordered as listed in Table 1.

[pic]

Figure 1: Source code snips for variants of Singleton

1) Eager Instantiation [6]

Eager Instantiation variant involves the creation of instance in an initialization block that is precalled when a class is loaded. It benefits runtime performance particularly in the case when shared objects are preloaded into memory awaiting to be called. This variant is beneficial in thread safe scenarios, but it has a demerit when there are limited number of resources e.g. database connections. Figure 1 presents key source code snip for Eager Instantiation variation of Singleton.

2) Lazy Instantiation (non – thread safe) [6] [16]

Lazy instantiation is one of the most commonly used variant of the singleton pattern that provides an access method to look for any existing singleton object and create an object if not found. This variant is an extension of eager instantiation. Source code snip for Lazy Instantiation(non-thread safe) variation of Singleton is given Figure 1.

3) Lazy Instantiation (thread safe) [16]

A second version of lazy instantiation specifically focuses on the thread safe implementation of the singleton. This implementation makes use of the idea of critical region in operating systems when different threads simultaneously access a certain region that is bound to a shared resource that can be accessed one at a time. Similarly using this implementation we lock the singleton instance creation region. It ensures that during a certain time only one thread will be executing the block. Major part of source code snip for this variant is given in Figure 1.

4) Lazy Instantiation with double lock mechanism [16] [17]

A best thread safe implementation of the singleton provides another mechanism for in-depth handling of instance creation. At the same time it is discouraged as well because it can yield performance issues due to mutual-exclusion lock on a certain object [81]. Double locking mechanism is generally avoided in ‘lock’ types(classes) that can cause threading issues [81]. Figure 1 depicts key code snip for this variant.

5) Replaceable Instance [6]

There are situations when a singleton instance is replaced at runtime. The best way to symbolize this is changing Graphical User Interface of the application as discussed in [6]. Key source code snip for Replaceable Instance of singleton is given in Figure 1.

6) SubClassed Singleton [6] [11]

Singleton classes are usually considered non-extendable due to the fact that they have the private constructor. The implementation of subclassed singleton involves some extra management to handle the ensurity of sole instance. Sometimes, it may be the case to extend the default behaviour of the singleton class e.g platform dependent configurations that are usually diverse in nature [6]. In this implementation, the private constructor is made protected so that classes should be derived from it but there is an issue with the static self- instance that will be shared among all the derived classes. Figure 1 depicts major part of code snip for this variant.

7) Delegated Construction[6]

Delegated construction variant uses the delegation technique to create the sole instance of the singleton pattern. Delegation is basically passing on the duty of a certain task(method call) to another object to do it on the owner’s behalf [81]. The program must ensure the correct instance to be assigned during delegated calls. The usage of delegation in the singleton class or its access method occur when singleton is implemented with other patterns e.g Factory pattern for paramterized construction of singleton [6]. Key source code snip for Delegated Construction variant of Singleton is given in Figure 1.

8) Different Placeholder [6]

This variant discusses a nested class inside singleton class that holds the responsibility of the instance creation. The nested class acts a placeholder for the singleton. This method benefits the developer to use language features to ensure a fully lazy initialization in multi-threaded environment. Key source code snip for different placeholder variant of singleton is given in Figure 1.

9) Different Access Point [6]

Different Access Point variant focuses on scenario where singleton instance is created by different classes and singleton class is an access point(static method) to access that instance. This variant is used in abstract factory implementation where the products are created and holded for future reuse. A major part of source code snip for this variant of singleton is given in Figure 1.

10) Limiton [6]

Limiton variant extends the concept of a sole instance singleton to limited number of singleton’s instances. This variant can be better differentiated by a solar system (single star system) and Sirius system (binary star system) [6]. Key source code snip for Limiton variant of singleton is given in Figure 1.

11) Social Singleton [5]

The idea of social network is applied to implement singleton classes. The benefit of using social singleton is that static resources are shared among singleton objects that have a relationship (friends) with each other. One object can have access to a resource owned by any other only if it is an authorized friend object. It can be better related to a scenario when there are similar resources scattered across different locations and can be served a centralized source of access. Key source code snip for Social Singleton variant of GoF Singleton is given in Figure 1.

12) Generic Singleton using Reflection [15]

Major motivation for this variant is application of reflection technique that is one of the powerful features provided by any modern programming languages. With the extensible support of using code that is not available at runtime, which includes information that is in the metadata of .Net Assemblies i.e. types, constructors, private methods etc. as described by [80]. A major part of source code snip for this variant of singleton is given in Figure 1.

Composite design pattern is selected as second example due to its number of variations and composition with other design patterns. Composite pattern is used in GUI containers, HTML/XML parsing and File management utilities with slightly different variations. One major feature for variation of Composite is the inheritance hierarchy of objects. The variants presented in Figure 2 are successors to the canonical form of composite pattern and dramatically change the structure (model) or implementation (programming prospect) in one or either ways. The comparison can be clearly seen how they evolved from the basic intent. The 10 variants of Composite are discussed in references [29, 31, 32, 33, 46] as shown in Table 1. Figure 2 highlights the variants of Composite in the form of their UML structures. These variants are:

• Composites of Composites [26]

• I-,N Relationship using arrays[29]

• I-N Relationshipusing Has Tables[29]

• I-N Relationship using Generics[29]

• Composite composed of other leaves[31]

• Memorization of all elements at component level[32]

• Reference Participant[32]

• Sole Leaf / Sole Composite[32]

• Supplementary Relationship[32]

• Reflexive connection between lead and Composite[33]

• Association Implementation[46]

We published detail information about these variants including their motivation, UML structure and source code example on the web [24]. Variants with 1-N relationships using array, hashtable and generic are presented with single UML structure labeled as 8,9,10 because of same structure for each variant. The central part of Figure 2 shows the GoF structure of Composite and arrows reflect that how different variants are evolved from standard structure of the Composite. The evaluation results for variants of composite are presented in Table 2.

[pic]

Figure 2: UML structures for variants of Composite

A last variant of the Composite design pattern provides compound implementation of Composite. This variant is defined in Java AWT library that has two levels of the hierarchy i.e. the composites and leaves are abstract classes that have further concrete implementation. The calls are delegated to different objects through aggregation. Figure 3 presents the UML structure of this variant.

[pic]

Figure 3: UML Diagram of compound implementation of Composite in Java AWT Library [26]

Command design pattern is selected from the category of behavioral design patterns due to its structural and implementation varying features. Command pattern is used to manage algorithms, relationships and responsibilities between objects. This pattern is often a matter of discussion in menu systems and applications where client requests an operation and the object that perform it. Being versatile in nature the Command pattern can be used in multiple ways. Figure 4 depicts the variants of command design patterns. These variants are given below:

• Façade Command [56]

• Combined Command [56]

• Distributed Command Pattern [57]

• Command Revisited [58].

[pic]

Figure 4: UML structures for variants of Command Design Pattern

Design Patterns Variant Catalogue

The motivation for documenting design patterns variant catalogue stems from variants of three design patterns discussed in section 2 and disparity of results rendered by different design pattern detection tools on the same examined systems. We also realized the importance of such catalogue during manual analysis of source code of open source libraries such as JUnit and JHotDraw [18 19]. In this section, we present a catalogue of variants that includes creational, structural and behavioral design patterns that are scattered across various sources. Such a catalogue is not available in the literature to the best of our knowledge. The standard information including intent, specification, UML diagram, source code example and applications of each discussed variant is not available at any single source. It is an imperative to assemble and organize information about scattered variants at a single location for the research community. The need for such catalogue is also realized by other authors [4, 8, 51, 52]. It is pointed out by some authors that they do not intend to apply a pattern for solving a problem, but they came across the variant of a standard pattern just by accident, which later on became a common practice. The major concern that requires further research from community is rating, recommendations and discussion on each variant presented in our catalogue.

Creational design patterns advocate the fact that how new objects are created, composed and presented. The scope of their usage depends on Class and Object. Class creational patterns use inheritance to instantiate a class and object creational patterns advocates the usage of composition and delegation. Variations are very common in creational design patterns. For example, the factory method uses nested classes in the factory class that cause up to 15.1% false positives during its detection as reported in [78]. 28 variants of creational patterns are listed in Table 1. Structural design patterns focus on how classes and objects are composed to form larger or complex structures. They also formulate ways to compose objects to get new functionality. Structural variations are comparatively easy to recognize, but recursive structures in the form of inheritance trees in some patterns pose challenges for pattern detection tools. Therefore, the documentation of all possible variants of such patterns is essential. We report 38 variants of structural design patterns in Table 1. Behavioral patterns focus on how objects communicate and interact with each other. Behavioral patterns are used to solve problems such as serializing/deserializing objects without penetrating data encapsulation, delegating behavior, responding to stage changes etc. We document 35 variants of behavioral design patterns as presented in Table 1 and rigorous discussion about

documented variants is available on the web [24] for readers.

We explain by an example of social Singleton variant about specification of each variant on the web [24] as:

Variant Name: Social Singleton

Definition: One object can have access to a resource owned by any other only if it is an authorized friend object

Application Example: an integrated environment with multiple processes/ machines to execute a job [5]

UML Class Diagram: is given below in Figure 5

Source Code Example: is given below in Figure 6

[pic]

Figure 5: UML Structure of Social Singleton[5]

Currently, there is not any single catalogue where one can find all the existing variants of creational, structural and behavioral design patterns with complete information. The scattered variants of all GoF patterns are assembled and organized to provide an initial catalogue. 106 variants of creational, structural and behavioral patterns are listed in Table 1. The standard form of each pattern originally discussed in GoF book is not included in Table 1. We publish detail explanation about each variant including context, UML structure and applications on the web source for readers [24].

[pic]

Figure 6: Source Code Snip of Social Singleton

Table 1: Variants of GoF Design Patterns

|Categor|Pattern |Variants |Total |

|y |Name | | |

|Creatio|Singleton |Eager Instantiation[6],Lazy Instantiation (non – thread safe)[6] [16], Lazy Instantiation (thread safe) [16], |12 |

|nal | |Lazy Instantiation (thread safe) [16], Lazy Instantiation with double lock mechanism [16][17], Replacable | |

| | |Instance [6], SubClassed Singleton [6] [11], Delegated Construction [6], Different Placeholder [6], | |

| | |Different Access Point [6], Limiton [6], Social Singleton[5], Generic Singleton using Reflection [15]. | |

| |Abstract Factory |Factories as Singleton [47], Pluggable Factories[20][21], Industrial Strength Pluggable Factories[22], |6 |

| | |Abstract Factory as back up twins[53], Generic Factories [22] | |

| |Factory Method |Different Product types inside factory class [50], Default Product Implementation[50], Parameterized Factory |9 |

| | |Method[50], Delegated construction of products from Factory method[50], No concrete factory class [20], | |

| | |Product creation from repository types using delegation [50], One concrete creator for all[50], Single | |

| | |concrete class for product selection without client [50] | |

| |Prototype |Prototype Compound[44] |1 |

| |Builder |Nested Builder [48] |1 |

|Structu|Adapter |Read only and Write only Adapter[53], Pluggable Adapters [45], Two way Adapters [45] |3 |

|ral | | | |

| |Composite |Composites of Composites[26], I-,N Relationship using arrays[29], I-N Relationshipusing Has Tables[29], I-N |11 |

| | |Relationship using Generics[29], Composite composed of other leaves[31], Memorization of all elements at | |

| | |component level[32], Reference Participant[32], Sole Leaf / Sole Composite[32], Supplementary | |

| | |Relationship[32], Reflexive connection between lead and Composite[33], Association Implementation[46] | |

| |Decorator |Delegation between abstraction and implementation[33], Decorators with factories [36], Added responsibility to|6 |

| | |run botto up and top down[36], Self-Dressed Decorator[53], Omitting the abstract Decorator[1], Mediate | |

| | |Decorator[37] | |

| |Bridge |Cheshire Cat Idiom[1], Casading Bridge[25], Folded cascading Bridg[25], Partialy Folded Cascading Bridge[25], |8 |

| | |Architectural Cascading Bridge[25], Bi-Directional cascading bridge[25], Single Protocol Cascading Bridge[25],| |

| | |Dynamic Switcher Bridge[26] | |

| |Facade |Encapsulating layered Façade[47], Wrapper Façade[35], Sub System Façade[49] |3 |

| |Flyweight |Constrainedly Shared Flyweight [28], Externalizing Extrinsic State[28] |2 |

| |Proxy |Proxy associated with Subject [37][38], Aggregation relation of Proxy and Subject [37], Proxy in heterogeneous|9 |

| | |environment [39], Pipe and filter implementation [40], Reverse Proxy [40], Generic Proxy Implementation using | |

| | |reflective architecture [42], Proxy associated with Subject [37][38], Dynamic Proxies [43], Interchangeable | |

| | |Proxy[53] | |

|Behavio|Template method |Template Method – Factory Method Compound Pattern [72], Enhanced Template Design Pattern [73] |2 |

|ral | | | |

| |Visitor |Visitor Combinators [74], Distributed Monitoring using Visitor Pattern [75], Extended Visitor Pattern [76] |3 |

| |Chain of |Handling strategy [41], Forwarding Strategy [41 ], Bureaucracy pattern [55] |3 |

| |Responsibility | | |

| |Mediator |Flight System Mediator [63], Traffic Generator Mediator [63], Mediator: Isolating associations between the |3 |

| | |Meta Objects [64] | |

| |Interpreter |Single Interpretation [59], Strategized Interpretation [59] |2 |

| |Iterator |External Iterators [60], Static Structure Iterators [60], Nested Object Iterator [60], Single Integral | 9 |

| | |Iterator [60], Multiple Integral Iterator [60], Magic Cookie [60], External Magic Cookie Iterator [60], | |

| | |Internal Iterator [60], Super Iterator [62] | |

| |Observer |Multiple Instance Observer [65], Compound Implementation [66] |2 |

| |Memento |HybridPrM [65] |1 |

| |State |State Machine Pattern [67], StateMaps [68], Three-Level Finite State Machine [69], Reflective State [69] [70],| 5 |

| | |Persistent State Machine [71] | |

| |Strategy |Flexible Strategy Pattern [77] |1 |

| |Command |Façade Command [56], Combined Command [56], Distributed Command Pattern [57], Command Revisited [58] |4 |

|Total Variants |106 |

Evaluation of Variants

It is an imperative to evaluate existing state of the art tools that are used to recognize design patterns from source code of different applications on the variants presented in Table 1. As a first test case, we selected variants of Singleton, Composite and Command design patterns for comparing and evaluating different tools. Design patterns recovery tools such as DPD [12], Fujaba [30] and our prototyping tool [8] are selected for evaluating variants of these patterns. DPD [12] is a design pattern recovery tool that recovers patterns from source code based on similarity scoring method. We found this tool a robust, scalable and efficient among state of the art design pattern recovery tools. It is available publically for experimentation but is limited only to Java language. Fujaba[30] is an open source CASE tool with support of round-trip engineering including design patterns recovery. It is developed in the university of Paderborn Germany and has gone through number of extensions. It is also user-friendly, powerful, reliable tool and has been used by number of research groups. Finally, our prototyping tool [8] is developed as a research tool for recovery of design patterns. The distinguishing features of this tool is multiple language support for design patterns recovery and support for customization of design patterns definitions based on feature types. It uses multiple searching techniques such as SQL queries, Regular expressions and source code parsers for recovery of patterns from source code of C/C++, Java and C#.

All variants of Singleton, Composite and Command design patterns are implemented as mentioned in Table 1 using Java programming language. We applied three selected tools on all variants as a first test case. It is worthwhile to mention that our results are based on single definitions of these variants. The results in Table 2 reflect that first two tools are not capable to detect all variants of the Singleton pattern. Initially prototyping tool was also not able to recognize social Singleton [16] and the Singleton with different access point [6]. Due to easy customization of patterns definitions in our prototyping tool [8], we added new features of these variants in pattern definition of Singleton for the recovery of these variations.

Table 2: Experimental Results on Variants of Singleton, Composite and Command Design Patterns

|Variants | Variants |DPDv4.5 |Fujaba |Prototype |

|of | |[12] |[30] |[8] |

|Singleton| | | | |

| |Eager Instantiation [6] |X |√ |√ |

| |Lazy Instantiation (non – |√ |√ |√ |

| |thread safe) [6] [8] | | | |

| |Lazy Instantiation (thread |√ |√ |√ |

| |safe) [8] | | | |

| |Lazy Instantiation with |√ |√ |√ |

| |double lock mechanism [8] [9]| | | |

| |Replaceable Instance [6] |√ |√ |√ |

| |SubClassed Singleton [6] [11]|√ |√ |√ |

| |Delegated Construction [6] |√ |√ |√ |

| |Different Placeholder [6] |X |X |√ |

| |Different Access Point [6] |X |X |√ |

| |Limiton [6] |√ |√ |√ |

| |Social Singleton [14] |X |X |√ |

| |Generic Singleton using |X |√ |√ |

| |Reflection [15] | | | |

|Variants |Composites of Composites [26]|X |X |X |

|of | | | | |

|Composite| | | | |

| |I-N Relationship using |X |X |√ |

| |arrays[29] | | | |

| |I-N Relationship using Has | |X |X |

| |Tables[29] | | | |

| |I-N Relationship using |X |X |√ |

| |Generics[29] | | | |

| |Composite composed of other |X |X |X |

| |leaves[31] | | | |

| |Memorization of all elements |X |X |X |

| |at component level[32] | | | |

| |Reference Participant[32] |X |X |X |

| |Sole Leaf / Sole |X |X |X |

| |Composite[32] | | | |

| |Supplementary |X |X |X |

| |Relationship[32] | | | |

| |Reflexive connection between |X |X |X |

| |lead and Composite [33] | | | |

| |Association |X |X |√ |

| |Implementation[46] | | | |

|Variants |Façade Command[56] |√ |√ |√ |

|of | | | | |

|Command | | | | |

| |Combined Command[56] |√ |X |√ |

| |Distributed Command[57] |X |X |√ |

| |Command Revisited[58] |X |X |X |

In general Singleton is considered the simplest pattern but number of its variants makes its recovery challenging for design pattern recovery tools. The complexity in the case of other patterns is augmented depending upon varying features of the variants. The variants of other patterns threaten the validity of results rendered by design pattern recovery tools.

Similarly, experiments were performed on variants of Composite design pattern using three selected tools. The extracted results are presented in Table 2. It is visible from results that first two tools are not able to recognize any variant of the Composite design pattern. The key reason is that developers of these tools do not have knowledge about these variations during implementation of these tools. The prototyping tool [8] was able to recognize only a few variants of the Composite as given in Table 2. It is a key concern for authors of existing tools to upgrade their pattern definitions which can handle these variations. Researchers can evaluate design pattern recovery tools on different open source systems using definitions of these variants. Finally, the variants of Command design patterns are evaluated by using selected tools and results are presented in Table 2. The selected state of the art tools are not capable to detect all variants of the Command pattern, which reflect the need for incorporation of knowledge about these variants in the pattern definitions of existing tools.

As a second test case we selected open source software libraries such as (JHotDraw 5.1 [19], JRefactory 2.6.24[79], and JFreeCharts 0.8.1 [54]) for recovering variants of Adapter, Decorator, Proxy and Abstract Factory patterns from these libraries. Each pattern is categorized into standard GoF and its new variations. We presented new variations of these patterns in our previous work [53] and results of variants in Table 3 are based only on new variants of these four patterns. The (-) in [30] means that the tool did not return any result during experimentation. The extracted results are presented in Table 3.

Table 3: Experimental Results on Adapter, Decorator, Proxy and Abstract Factory Patterns

|Libraries/Pattern |JHotDraw5.1 |JRefactory2.6.24 |JFreeChart 0.8.1 |

|Names | | | |

|[8] |[12] |[30] |[8] |[12] |[30] |[8] |[12] |[30] | |Adapter |GoF |22 |23 |67 |17 |27 |- |6 |3 |- | | |Variants |5 |0 |0 |18 |0 |- |1 |0 |- | |Decorator |GoF |3 |3 |2 |0 |0 |- |5 |0 |- | | |Variants |0 |1 |0 |0 |1 |- |0 |1 |- | |Proxy |GoF |0 |0 |0 |15 |10 |- |5 |0 |- | | |Variants |0 |0 |0 |4 |0 |- |0 |1 |- | |Abstract Factory |GoF |0 |0 |0 |2 |0 |- |0 |1 |- | | |Variants |0 |0 |0 |0 |0 |- |5 |0 |- | |

Critical Analysis AND LESSONS Learned

Design patterns variations can be categorized in Structural, Behavioral and Implementation aspects. All variations obey the pattern intent strictly as defined by GoF. Structural and behavioral variations are very well known in the practice. Most submissions [37 38 39 40 42 43] in the literature discussed these two categories which has added knowledge to the existing solutions and are initial attempt for building variants catalogue. Structural and behavioral variations tweak the participant classes or their behavior to achieve the goal. Implementation variants that are very common are discussed by few authors and these variants hamper accuracy of pattern detection tools. Pattern detection tools must be aware of such implementations that might exist in source code extensively because developers tend to reproduce the issues with such solutions. It covers language constructs that provide an additional way to reach the solution. The need for using such constructs indeed becomes a liability when we talk about thread safe and synchronized environments. These constructs also come on board in the form of language keywords, delegation carriers etc. We criticize the proven practices of design patterns variants in the following key points:

1. There is no existence of single complete catalog on all variants of GoF patterns in literature that is highly required.

2. There is a lack of consensus on definitions of patterns variants because of their diverse implementations.

3. A number of publications [8, 9, 10, 12, 52] focused on creating benchmark systems for results of design pattern recovery tools but benchmarks for definitions of patterns and their variants cannot get attention of research community that are important for accurate recovery of patterns.

4. The community effort is required for rating of discussed variants based on their real applications.

5. Variants are an outcome of sub-problems called micro- patterns that exist within patterns.

6. Some of the variations according to authors are an accidental birth that later on became a part of micro- pattern.

7. Most implemented variants are an underlying situation in different applications that are modeled as best practices in computer programming.

8. The new variants append features to the existing pattern definitions.

9. Variations based on language constructs are usually ignored by the pattern detection tools because of infinite in nature.

10. Industry always terms a variation that brings change in the structural canonical form of a design pattern.

11. Implementations that do not break intent of the pattern but abuse programming practices are always non-candidates.

12. Current state of the art tools are not cable for automatically generating detection algorithms to handle variations in pattern detection process.

13. Most authors of patterns detection tools conduct performance and recovery tests on open source frameworks and they did not perform experiments on industrial applications.

14. Most pattern detection tools are limited to a single language for pattern recovery and support for multi-language pattern recovery is limited.

15. The scope of overlapping of patterns in which participants share the role of each other is still an area under consideration. Variations also exist in overlapping patterns.

16. Delegation mechanism is no longer restricted to traditional implementations that cause variations in number of patterns.

Since there is always a room for improvement, we present an initial catalog of available variants with intent, UML diagram and applications that will help design pattern research community to evaluate accuracy of their presented pattern recovery techniques and tools. The catalog is unique in nature and discusses the aspects of implementations provided in solutions given by the community. An effort is required to streamline the catalog to append other practices that are hidden. It is also important to rate each variant based on its real applications and how it vary from the original implementation. We urge a global solution and online repository of variant catalog where a governing body should evaluate the existing and new implementations that further become part of pattern detection tools. A mutual agreed solution by the jury should be marked as a standard benchmark. In order to achieve such goal, we request feedback from experts on presented catalogue of variants for its evolution and acceptance as a benchmark for patterns specifications, detection and comparisons of results.

Conclusion and Future Work

Variants of GoF design patterns are presented and discussed by different authors, but they are not available at a single location in standard format as a catalogue that can be used by all researchers. The variants of same patterns affect the accuracy of pattern detection techniques and tools. We evaluated variants of Singleton, Composite, Command, Adapter, Decorator, Proxy and Abstract Factory design patterns using state of the art pattern recognition tools and realized the importance of presenting a catalogue that includes all discussed variants in the literature. We collected and analyzed variants of all GoF design patterns available in literature and presented a standard catalogue containing all variants on the web [24] with description and UML diagram of each variant. The presented catalogue of all variants may be used by design pattern research community for evaluation of existing tools and for the development of new tools. The catalogue is utmost important for the new tool developers that they can incorporate knowledge of all variants during development of new tools. The presented catalogue is the initial attempt and we do not claim that it is 100% complete. The community effort will be required to rate, analyze and evolve the catalogue. In future, the existing catalogue will be extended by adding variants of other types of design patterns. The future work will also focus on formal specifications of presented variants and their evaluation on different other open source and industrial applications. We also plan to create a repository of all variants on the web for insertion, deletion and updating of new variants for the community.

REFERENCES

[1] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides, Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley Publishing Company, Reading, MA, 1995.

[2] M. Vokac, An efficient tool for recovering design patterns from C++ code, Journal of Object Technology, Volume 5, No. 1, pp. 139–157, Jan-Feb 2006.

[3] K. Stencel and P. Wegrzynowicz, Detection of Diverse Design Pattern Variants, In Proceedings of 15th Asia-Pacific Software Engineering Conference, pp. 25-32, Beijing, China ,3-5 December 2008.

[4] I. Bayley and H. Zhu, Formal specification of the variants and behavioral features of design patterns, The Journal of systems and Software, Volume 83, Issue 2, pp. 209-221, 2010.

[5] S. K. Saho, Social Object A Software Design Pattern, Software Engineering and Service Science (ICSESS), 2011 IEEE 2nd International Conference, pp. 580 – 581, 2011.

[6] K. Stencel and P. Wegrzynowicz, Implementation Variants of the Singleton Design Pattern, Lecture Notes in Computer Science, Volume 5333, pp. 396-406, November 19, 2008.

[7] N. Pettersson, W. Löwe and J. Nivre, Evaluation of Accuracy in Design Pattern Occurrence Detection, IEEE Transactions on Software Engineering, pp. 575-590, Volume 36, No. 4, July/August 2010.

[8] G. Rasool and P. Mader, Flexible Design pattern detection based on feature types, Automated Software Engineering (ASE), 2011 26th IEEE/ACM International Conference, pp. 243-252 , 6-10 Nov. 2011.

[9] A. D. Lucia, V. Deufemia, C. Gravino, M. Risi, Design pattern recovery through visual language parsing and source code analysis, The Journal of Systems and Software, Vol 82 (2009), pp. 1177–1193.

[10] Y-G. Guéhéneuc, G. Antoniol, DeMIMA: A Multilayered Approach for Design Pattern Identification, IEEE Transactions on Software Engineering, Vol, 34 No.5, pp. 667–684, 2008.

[11] C. GAO, Application of Design Patterns to Control System of Digital Photofinishing Machine, Intelligent Information Technology Application, Third International Symposium, Volume: 3, pp. 439-441 , 21-22 Nov, 2009.

[12] N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, S.T. Halkidis, Design Pattern Detection Using Similarity Scoring, IEEE Transaction on Software Engineering, Vol. 32, No. 11, pp. 896–909, 2006.

[13] .NET MSDN Website: Reflection in the .NET Framework,

[14] Code Project Website: Reflection in .Net .

[15] Creational Design Patterns, MSDN Website:

[16] Implementing the Singleton Pattern in C#, CSharp in Depth, Website:.

[17]Singleton Pattern, OODesign Website: .

[18] Junit Home Page:

[19] JHotDraw Home Page:

[20] D. Kharrat., Self-registering plug-ins an architecture for extensible Software, Electrical and Computer Engineering, 2005. Canadian Conference, pp. 1324 - 1327,1-4 May 2005.

[21] J. Vlissides, Pluggable Factory An Object-Creational Compound Pattern, 1999.

[22] T. Culp , Industrial Strength Pluggable Factories, C++ Report, 11(9), Oct. 1999.

[23] H-R. Chong, Context-aware Reuse in Modelling Instructional Design and Assembly of Learning Objects, Sensor Networks, Ubiquitous, and Trustworthy Computing, 2006. IEEE International Conference, Vol. 2, pp. 110 - 117, June 2006

[24]Web source :

[25] Suzuki, J., OpenWebServer, an adaptive Web server using software patterns, Communications Magazine, IEEE, pp. 46-52, April 1999.

[26] J. Seemann, J. Wolff von Gudenberg, Pattern-based design recovery of Java software, SIGSOFT '98/FSE-6 Proceedings of the 6th ACM SIGSOFT international symposium on Foundations of software engineering, Volume 23 Issue 6, Nov. 1998.

[27] Abstract Window Toolkit,

[28] Do Factory Website:

[29] J. Niere, Towards pattern-based design recovery, Software Engineering, In Proceedings of the 24rd International Conference", pp. 338 - 348 25-25 May 2002.

[30] Fujaba Home Page :<

[31] C. Bouhours, H. Leblanc and C. Percebois, Bad smells in design and design patterns, In Journal of Object Technology, vol. 8, no. 3, pp. 43-63, May-June 2009.

[32] C. Bouhours, H. Leblanc and C. Percebois, Sharing Bad Practices in Design to Improve the Use of Patterns”, Pattern Languages of Programs Conference, 2010.

[33] E. B. Duffy, J. P. Gibson and B. A. Malloy, Applying the Decorator Pattern for Profiling Object-Oriented Software, In Proceedings of the 11 th IEEE International Workshop on Program Comprehension, pp 84 - 93,10-11 May 2003.

[34] M. Völter, M. Kircher and U. Zdun, Object-Oriented Remoting–Basic Infrastructure Patterns, In Proceedings of 5th European Conference on Pattern Languages of Programs (EuroPLoP 2000), Irsee, Germany,

[35] D. C. Schmidt. Wrapper facade: A structural pattern for encapsulating functions within classes, C++ Report, SIGS, 11(2), February 1999.

[36] Z-X. Zhang, A new method for design pattern mining, Machine Learning and Cybernetics, In Proceedings of 2004 International Conference, pp. 1755-1759 vol.3, 26-29 Aug. 2004.

[37] K. Soundararajan and R. W. Brennan, A Proxy Design Pattern to Support Real-Time Distributed Control System Benchmarking, Lecture Notes in Computer Science, ISSN: 1611-3349, Volume 3593/2005, pp. 133-143, August 29, 2005.

[38] G. Rasool, Customizable feature based design pattern detection integrating multiple techniques, PhD thesis, Technical University of Ilmenau, Germany, 2010.

[39] B. Goldsmith, Z. Laszlo, M. Doller and H. Kosch, Mobile agents in a distributed heterogeneous database system, Parallel, Distributed and Network-based Processing, 2002. Proceedings. 10th Euromicro Workshop, pp. 123-128 ,2002

[40] I. Wentzlaff and H. Schmidt, Preserving software quality characteristics from requirements analysis to architectural design, In Proceedings of the Third European conference on Software Architecture, Volume:4344 pp.189-203, 2006

[41] S. Stelting and O. Maassen, "Applied Java Patterns", Published by Prentice Hall Professional, 2001, ISBN:0130935387.

[42] J. Suzuki and Y. Yamamoto, Dynamic Adaptation in the Web Server Design Space using Open Web Server, In Proceedings of SPA '99, March 1999.

[43] J. Suzuki and Y. Yamamoto, "Extending UML for Modeling Reflective Software Components", LNCS, Vol 1723, pp.220-235,1999, , 1999

[44] G. Aranda and R. Moore, Formally modelling compound design patterns, Technical Report 225, UNU / IIST, P.O.Box 3058, Macau,iist.unu.edu/www/docs/techreports/reports/report225.ps.gz,December 2000.

[45] J. Noble, Classifying relationships between object-oriented design patterns, In Australian Software Engineering Conference (ASWEC), pp 98-107, 1998.

[46] J. Niere,, J. P Wadsack and L. Wendehals Design pattern recovery based on source code analysis with fuzzy logic", Technical Report tr-ri-01-222, University of Paderborn, 2001.

[47] J. Shi , Design patterns applied to computer network virtual lab system design , Software Engineering and Service Science (ICSESS), 2011 IEEE 2nd International Conference, pp.124-127, 2011.

[48] K. Bloch, Effective Java 2nd Edition, Addisen Wesely , ISBN-13: 978-0-321-35668-0,pp. 37,2008.

[49] J. Coldewey, Decoupling of Object-Oriented Systems, Revision of the document - The ARCUS project sd&m AG, Munich 1996,, July 2000.

[50] V. D. and J-P. Corriveau, Making Patterns Better Design Tools: Requirements Analysis for a Family of Navigators for Design Pattern Catalogs, In Proceeding of IASTED Conference on Software Engineering, pp. 349-354, Innsbruck, Austria, February 15-17, 2005.

[51] J. Dong, Y. Zhao and T. Peng, A Review of Design Pattern Mining Techniques, The International Journal of Software Engineering and Knowledge Engineering (IJSEKE), Volume 19, Issue 6, pp. 828-855, September 2009.

[52] F. A. Fontana, A. Caracciolo, and M. Zanoni, DPB: A benchmark for design pattern detection tools, In Proceedings of the 16th European Conference on Software Maintenance and Reengineering, CSMR 2012, pp. 235-244, Szeged, Hungary, March 2012.

[53] G. Rasool, H. Akhtar, Discovering Variants of Design Patterns, Journal of Basic and Applied Scientific Research, pp: 139-147, Vol: 3, Issue: 1, 2013.

[54] JfreeChart Home Page:

[55] D. Riehle, Composite design patterns, In Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pp .218-228, October 05-09, 1997.

[56] J. Rudzki, and T. Systa, Performance Implications of Design Pattern Usage in Distributed Applications – Case Studies in J2EE and .NET, ROSATEA ’06, Portland Maine, USA, July 2006.

[57] CodeProject, Distributed Command Pattern, .

[58] M. Kircher and M. Voelter, Command Revisited Pattern, EuroPLoP 2004 conference, Kloster Irsee, July 7-11, 2004.

[59] J. H. Hill and A. Gokhale, Using Template Metaprogramming to Enhance Reuse in Visitor-Based Model Interpreters, Engineering of Computer Based Systems (ECBS), IEEE 19th International Conference and Workshops, pp. 5-14, 2012.

[60] J. Noble, Iterators and Encapsulation, In Proceedings of the Technology of Object-Oriented Languages and Systems (TOOLS 33), pp.431, 2000.

[61] E. Raymond and G. L. Steele, The New Hacker's Dictionary. MIT Press, second edition, 1993.

[62] A. Oboler, C. Twardy and D. Albrecht, Super Iterator A design pattern for Algorithm and Data structure collections, In Proceedings of International Conference on Information Technology, pp. 677-678, 2007.

[63] S. Zheng, S. Zheng, J. He, and J. Han, An Optimized Distributed Real-time Simulation Framework for High Fidelity Flight Simulator Research ,Information and Automation, International Conference, pp.1597-1601, 2009.

[64] D. J. Ram , P. J. Kumar Reddy , M. S. Rajasree, Pattern hybridization: breeding new designs out of pattern interactions, ACM SIGSOFT Software Engineering Notes, Vol .29, No.3, pp. 1-10, May 2004 .

[65] V. Nguyen-Cong, and Y. Wang, Specification of Design Patterns using Real-Time Process Algebra (RTPA), Electrical and Computer Engineering, 2004. Canadian Conference , pp. 1545-1548 Vol.3, 2004.

[66] Z. Yueping, L. Yuefan and X. Kesheng, The Compound Pattern on the Chain of Responsibility and Observer, In Proceedings of the International Forum on Computer Science-Technology and Applications, Volume 03, pp. 420-422,2009.

[67] A. Shalyto, N. Shamgunov and G. Korneev, State Machine Design Pattern, Informational and Controlling Systems, 2004, Vol. 5, in “Articles” section, 2004.

[68] A. Sane and R. Campbell, Object-oriented state machines: subclassing, composition, delegation, and genericity, In Proceedings of the tenth annual conference on Object-oriented programming systems, languages, and applications, pp. 17-32,1995.

[69] P. Adamczyk, The Anthology of the Finite State Machine Design Patterns, .

[70] L. L. Ferreira, and C. M.F Rubira, The Reflective State Pattern, In Proceedings of the 5th Pattern Languages of Programs Conference (PLoP’98), Monticello, Illinois, USA,1998.

[71] A. V. Saúde, Ricardo A. S. S. Victório, Gabriel C. A. Coutinho, Persistent State Pattern, Pattern Languages of Programs Conference 2010,.

[72] G. Aranda and R. Moore, A Formal Model for Verifying Compound Design Patterns, In Proceedings of 14th SEKE conference, pp. 213-214,2002.

[73] D. E. Stevenson and A. T. Phillips, Implementing object equivalence in Java using the template method design pattern, In Proceedings of the 34th SIGCSE technical symposium on Computer science education, pp. 278-282, 2003.

[74] J.M.W. Visser, "Visitor combination and traversal control", In Proceedings of the 16th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pp. 270-282, 2001.

[75] D-K. Kim, Software Quality Improvement via Pattern-Based Model Refactoring, High Assurance Systems Engineering Symposium, 2008. HASE 2008. 11th IEEE, pp. 293-302, 2008.

[76] D. Z. Nguyen, M. Ricken and S. Wong, Design Patterns for Parsing, In Proceedings of the 36th SIGCSE technical symposium on Computer science education, pp. 477-481,2005..

[77] C. Jiang, Design and Implementation of the Flexible Form Based on Strategy Pattern, Service Systems and Service Management (ICSSSM), 2012 9th International Conference, pp.110- 113, 2012.

[78] M. Vokac, Defect Frequency and Design Patterns: An Empirical Study of Industrial Code, IEEE Transactions in Software Engineering, Vol. 30, No. 12, pp. 904–917, 2004.

[79] JRefactory Home Page:

[80] UML profile for interaction variants of design patterns, IEEE Software Journal, vol, no., pp. 64-72, 2012.

[81] C# lock Statement, MSDN Website : (v=vs.80).aspx

[82] Delegation Programming. Wikipedia Website: (programming)

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download