Master Thesis Software Engineering Thesis no: MSE-2005-13 June 2005
School of Engineering
Blekinge Institute of Technology Box 520
Toward Tool Support for Usage of Object- Oriented Design Patterns Expressed in
Unified Modeling Language
Daniel Bohdanowicz
This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies.
Contact Information:
Author:
Daniel Bohdanowicz
Address: K.I. Gałczy skiego 17 57-100 Strzelin
Poland
E-mail: danielboh@poczta.onet.pl External advisor:
Prof. Zbigniew Huzar
Wroclaw University of Technology, Faculty of Computer Science and Management Address: Wybrze e Wyspia skiego 27, 50-370 Wrocław, Poland
Phone: +48 71 320 24 42
University advisor:
PhD Ludwik Ku niarz
Department of Software Engineering and Computer Science
School of Engineering
Blekinge Institute of Technology Box 520
Internet : www.bth.se/tek Phone : +46 457 38 50 00 Fax : +46 457 271 25
A BSTRACT
Design patterns describe solutions that can be used in a particular context for commonly recurring problems at the detailed design level of a software system. Patterns have become an important concept in object-oriented development and their usage is a widely accepted practice.
This thesis investigates issue of tool support for design patterns usage that can be offered by UML modelling tools, and proposes UML based method and notation for specification of the patterns, and documentation of their instances in a design model, facilitating such support. Different ways of such support are presented and classified, and comparison of tools offering assistance for patterns usage is depicted.
UML profile supporting specification of structural aspects of solutions proposed by design patterns, and documentation of their instances is specified in the thesis.
Keywords: design patterns, tool support, UML profile, design patterns description
C ONTENTS
ABSTRACT ...I CONTENTS ...II INDEX OF TABLES ...IV INDEX OF FIGURES ... V
1 INTRODUCTION ... 1
1.1 SCOPE... 1
1.2 PURPOSE... 1
1.3 RESEARCH QUESTIONS... 1
1.4 RESEARCH GOALS AND OBJECTIVES... 1
1.5 GUIDANCE TO THE READER... 2
2 OBJECT-ORIENTED DESIGN PATTERNS... 3
2.1 DEFINITION OF OBJECT-ORIENTED DESIGN PATTERN... 3
2.2 PURPOSES OF USING DESIGN PATTERNS... 5
2.2.1 Design Reuse ... 5
2.2.2 Higher Level of Abstraction... 5
2.2.3 Design Documentation ... 5
2.2.4 Building Complex Systems... 6
2.2.5 Improve Maintenance and Increase Reusability... 6
2.3 LEVEL OF ABSTRACTION OF OBJECT-ORIENTED DESIGN PATTERNS... 6
2.4 DESIGN PATTERNS AND FRAMEWORKS... 7
2.5 COLLECTIONS OF PATTERNS... 8
2.6 RELATIONSHIPS BETWEEN OBJECT-ORIENTED DESIGN PATTERNS... 8
2.7 CLASSIFICATION OF OBJECT-ORIENTED DESIGN PATTERNS... 9
2.8 EXAMPLE OF DESIGN PATTERN... 14
3 TOOL SUPPORT FOR DESIGN PATTERNS USAGE... 17
3.1 CLASSIFICATION OF WAYS OF SUPPORTING DESIGN PATTERNS... 17
3.2 TOOL SUPPORT AT THE PATTERN LEVEL... 18
3.2.1 Handling Design Pattern Specification ... 18
3.2.2 Handling Design Patterns Collection... 19
3.2.3 Handling Design Patterns Classification Schema ... 19
3.2.4 Support for Selection of the Right Design Pattern... 20
3.3 TOOL SUPPORT AT THE DESIGN LEVEL... 21
3.3.1 Support for Design Pattern Instantiation... 21
3.3.2 Documentation of a Design Pattern Instance ... 22
3.3.3 Edition of a Design Pattern Instance... 22
3.3.4 Detection of Design Patterns Instances ... 23
3.3.5 Validation of a Design Pattern Instance... 23
3.3.6 Automatic Adaptation of a Design Pattern Instance to Changes in a Design Model ... 23
3.3.7 Prevention from Unintentional Violation of a Design Pattern Instance Structure ... 24
3.4 CLASSIFICATION OF WAYS OF TOOL SUPPORT FOR DESIGN PATTERNS USAGE... 24
3.5 SURVEY OF AVAILABLE CASETOOLS SUPPORTING DESIGN PATTERNS... 25
3.5.1 Support at the Pattern Level Offered by CASE/IDE Tools ... 26
3.5.2 Support at the Design Level Offered by CASE/IDE Tools... 29
3.6 COMPARISON OF CASETOOLS SUPPORTING USAGE OF DESIGN PATTERNS... 33
4 EXISTING APPROACHES TO DESIGN PATTERNS DESCRIPTION... 36
4.1 NATURAL LANGUAGE SPECIFICATIONS... 36
4.1.1 Flaws of Natural Language Specifications... 37
4.2 PRECISE SPECIFICATION OF DESIGN PATTERNS... 38
4.2.1 Which Aspects of Design Patterns Should Be Precisely Specified... 38
4.2.2 Requirements for Notation for Design Pattern Description ... 39
4.3 OVERVIEW OF FORMAL APPROACHES TO DESIGN PATTERNS SPECIFICATION... 40
4.3.1 Language for Pattern Uniform Specification “LePUS” ... 40
4.3.2 Flaws of Formal Approaches to Design Patterns Specifications... 41
4.4 MODELING OF DESIGN PATTERNS IN UML... 41
4.4.1 UML Parameterized Collaborations ... 42
4.4.2 Role-Elements of Pattern “REP” Diagrams... 43
4.4.3 Tagged Pattern Annotation... 44
4.4.4 Role Based Metamodeling Language “RBML”... 46
5 PROPOSAL OF UML PROFILE FOR DESIGN PATTERNS DESCRIPTION... 48
5.1 CONCEPT OF MODEL ROLES... 48
5.2 SPECIFICATION OF DESIGN PATTERNS BASING ON MODEL ROLES... 50
5.2.1 Description of Model Roles Needed for Design Pattern Specification ... 51
5.3 PROFILE –UMLEXTENSION MECHANISM... 53
5.4 SPECIFICATION OF PROFILE FOR DESIGN PATTERNS SPECIFICATION AND INSTANTIATION.. 55
5.4.1 Concept of Profile for Design Patterns Specification and Instantiation... 55
5.4.2 Description of Profile for Design Patterns Specification and Instantiation ... 56
5.4.3 Description of Stereotypes ... 64
5.4.4 Description of Tagged Values... 67
5.4.5 Definitions of Constraints... 67
5.5 EXAMPLE OF DESIGN PATTERN SPECIFICATION WITH USAGE OF THE PROFILE FOR DESIGN PATTERN SPECIFICATION... 72
5.5.1 Specification and Instance of the Object Adapter Design Pattern... 72
5.5.2 Specification and Instance of the SingletonFacade Compound Design Pattern... 75
6 DESCRIPTION OF PROTOTYPE OF PLUG-IN SUPPORTING DESIGN PATTERNS USAGE ... 78
6.1 CONCEPT OF A PLUG-IN BASING ON THE PROPOSED PROFILE... 78
6.2 IMPLEMENTATION OF “DPSUPPORTER”PLUG-IN... 79
6.3 FUNCTIONALITY OF THE DEVELOPED PLUG-IN... 80
6.4 COMPARISON OF “DPSUPPORTER” WITH OTHER TOOLS SUPPORTING DESIGN PATTERNS USAGE 81 7 CONCLUSIONS, FUTURE WORK... 85
8 GLOSSARY ... 87
9 REFERENCES... 88
APPENDIX A... 92
I NDEX OF T ABLES
Table 2.7.1 Classification of design patterns according to Gamma et al.[1995] ...10 Table 2.7.2 Classification of patterns according to their functionality [Buschmann et al.
1996]...12 Table 3.4.1 Classification of possible ways of tool support for design patterns usage at the
pattern level ...25 Table 3.4.2 Classification of possible ways of tool support for design pattern usage at the
design level ...25 Table 3.5.1 Support for design patterns and profiles in UML modeling tools ...26 Table 3.6.1. Comparison of CASE tools supporting usage of design patterns at the pattern
level ...34 Table 3.6.2. Comparison of CASE tools supporting usage of design patterns at the design
level ...35 Table 5.4.1 Purposes of stereotypes defined in profile for design patterns specification...56 Table 5.4.2 Description of stereotypes defined in the proposed profile for design pattern
specification and instantiation ...66 Table 5.4.3 Description of tagged values defined in the proposed profile for design pattern
specification and instantiation ...67 Table 6.4.1 Comparison of ‘DPSupporter’ and other tools supporting usage of design
patterns at the pattern level ...82 Table 6.4.2 Comparison of ‘DPSupporter’ and other tools supporting usage of design
patterns at the design level...83
I NDEX OF F IGURES
Figure 2.1.1 System representations and transformation processes [van Gurp 2000]...4
Figure 2.6.1 Relationships between GoF design patterns [Zimmer 1995] ...9
Figure 2.7.1 Taxonomy of design patterns for architecture integration [Keshav and Gamble 1998]...13
Figure 2.8.1 Example of a design pattern - Object Adapter ...15
Figure 2.8.2 Structure of the Object Adapter Design Pattern...15
Figure 2.8.3 Structure of the Class Adapter Design Pattern...16
Figure 3.5.1 Choosing the desired design pattern to apply in the top-down approach realized in UMLStudio...29
Figure 3.5.2 Instance of the Adapter design pattern created in the top-down approach realized in UMLStudio ...30
Figure 3.5.3 Automatically created instance of the Adapter design pattern after manual customization...30
Figure 3.5.4 Existing design model elements before application of the Adapter design pattern ...31
Figure 3.5.5 Typical wizard for design pattern instantiation provided by the tool realizing the mixed-approach (MagicDraw 9.5)...31
Figure 3.5.6 Instance of the Adapter design pattern generated with usage of the wizard supporting the mixed-approach (MagicDraw 9.5)...31
Figure 4.4.1 Example of usage of Tagged Pattern Annotation [Dong 2004] ...45
Figure 5.4.1 The concept of the proposed approach...55
Figure 5.4.2 Example of design patterns catalogue modeled with usage of the proposed profile...58
Figure 5.4.3 Example of usage of the proposed profile...60
Figure 5.4.4 Example of usage of constraints on relationships in the proposed profile ...62
Figure 5.4.5 Example of specification and instance of a compound design pattern in the proposed profile...63
Figure 5.5.1 Specification of the ObjectAdapter design pattern in the proposed profile ...74
Figure 5.5.2 Example of ObjectAdapter Instance in Design Model...75
Figure 5.5.3 Specification of the SingletonFacade compound design pattern...76
Figure 5.5.4 Instance of the SingletonFacade compound design pattern ...77
Figure 6.1.1 The concept of a plug-in basing on the proposed technique for design patterns description ...78
Figure 6.3.1 ‘DPSupporter’ dialog box ...80
Figure 6.3.2 Instance of the Decorator pattern called ‘D1’ generated by ‘DPSupporter’ ...81
1 I NTRODUCTION 1.1 Scope
Design patterns describe solutions that can be used in a particular context for commonly recurring problems at the detailed design level of a software system (Gamma et al.1995). Design patterns are described by means of software design constructs, such like for example classes, inheritance or aggregations. That is why usage of Unified Modelling Language (UML), which became informal standard for documentation of object-oriented systems, in design pattern specification seems to be the most natural and convenient approach to description and using design patterns.
Design patterns have become an important concept in object-oriented development, and nowadays their usage is a widely accepted practice. Along with their increasing popularity, there appears a question: how design patterns can be supported by UML modelling tools, and how should they be described to facilitate such support.
1.2 Purpose
The purpose of this research is to identify possible ways of tool support for effective usage of object-oriented design patterns within UML modelling tool, and to develop UML-based notation for design pattern description facilitating such support.
The results of this research are addressed to software engineers and software designers interested in development of tools supporting usage of design patterns and UML-based methods for precise specification of design patterns and documentation of their instances in a design model. This thesis can be treated as a first step towards development of an UML modelling tool offering complex support for usage of design patterns.
1.3 Research Questions
The following research questions are posed in this study:
1. How are design patterns supported in available CASE tools?
2. What features are the most desirable in CASE tools supporting design patterns?
3. Which aspects of design patterns can be expressed in UML?
4. How can those aspects be expressed in UML to facilitate effective usage of design patterns within UML tool?
1.4 Research Goals and Objectives
The main aim of this research is identification of possible ways of tool support for effective usage of object-oriented design patterns within UML modelling tool, and elaboration of UML-based notation for design patterns description facilitating such support.
To achieve the abovementioned goals the following objectives are set to this research:
1. To perform a survey of available on the market CASE tools offering support for design patterns usage.
2. To perform a survey of literature concerning ways of design patterns description and tool support for usage of design patterns.
3. To identify the most desirable features of a CASE tool supporting design patterns usage.
4. To develop an UML based method and notation for design patterns description facilitating effective usage of patterns within UML modelling tool.
5. To develop a prototype of plug-in for UML modelling tool supporting usage of design patterns, basing on the elaborated method and notation for description of design patterns and demonstrating some features presented in point 3.
1.5 Guidance to the Reader
According to taxonomy of computing project types presented by Dawson [2000]
the thesis can be classified as a research-based and problem solving project. Research- based project involves an investigation of a particular area and impose some structure on a field of interest [Dawson 2000]. In this thesis the issue of tool support for design patterns usage and the problem of design patterns description are thoroughly investigated (chapters 3 and 4).
According to Dawson [2000] problem solving project can involve the development of a new technique, or improvement of existing approaches, to solve a problem. In the context of the thesis, the problem was lack of consistent technique for specification of design patterns and documentation of their instances in UML. In this thesis the existing approach to design pattern specification and the existing technique of documentation of patterns instances have been improved and merged, what resulted in the new UML-based method and notation for design patterns specification and documentation of patterns instances.
This thesis is structured as follows. The next chapter introduces the basic definitions and notions concerning object-oriented design patterns, it investigates different ways of patterns classification, and presents an example of representative design pattern in order to bring the reader closer the nature of patterns.
Chapter 3 focuses on the issue of tool support for design patterns usage. It presents identified ways of the tool support that can be provided by UML modeling tools, and depicts proposal of their classification. The chapter presents also survey of available on the market UML modeling/IDE tools offering support for design patterns, and their comparison.
Chapter 4 is an outline of different attitudes to design patterns specification and documentation of their instances. It discusses advantages and disadvantages of existing approaches to description of the patterns.
Chapter 5 presents proposal of the UML based method and notation for specification of structural aspects of solutions offered by object-oriented design patterns, and for documentation of their instances in a design model. Presented approach is realized via elaborated UML profile specified in this chapter.
Chapter 6 describes the developed prototype of plug-in for UML modeling tool MagicDraw 9.5, basing on the proposed approach to design patterns description. It also presents comparison of the plug-in with existing tools.
Chapter 7 presents conclusions summarizing experiences gained during this research, and gives suggestions in the area.
Appendix A presents diagrams specifying GoF structural design patterns [Gamma et al. 1995] with usage of the proposed profile for design patterns specification and instantiation.
All references in this thesis are presented in the Harvard Referencing System [Dawson 2000].
2 O BJECT -O RIENTED D ESIGN P ATTERNS
In this chapter basic definitions and notions concerning object-oriented design patterns are presented. Definition of design patterns and purposes of their usage are investigated in Sections 2.1 and 2.2. Granularity of design patterns is analyzed in Section 2.3, and differences between the patterns and frameworks are indicated in Section 2.4. Different kinds of collections of patterns are presented in Section 2.5.
Relationships among design patterns are depicted in Section 2.6. Different ways of classification of the patterns are investigated in Section 2.7. At the end, in Section 2.8 example of a typical design pattern is presented in order to bring the reader closer the nature of patterns.
2.1 Definition of Object-Oriented Design Pattern
The concept of design patterns has it origins in works of the architect Christopher Alexander [1979], who identified and described in consistent format recurring themes in architecture, which he called “patterns”. Alexander [1979] gives the following definition of pattern:
“Each pattern is three part rule, which express a relation between a certain context, a problem and a solution.
As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.
As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes is relevant.”
Patterns presented by Alexander are described in natural language. Each pattern has name, it presents the problem in a given context, acting forces, and the solution.
The concept of pattern presented by Alexander was adapted by software community in the early 1990’s. Since that time, patterns have become an important concept in object- oriented development as a way of documenting the best design practices for solving known design problems. Software patterns have become the main subject of many conferences (such as for example PLoP, EuroPLoP, or SugaLoafPLoP1), journal publications and books.
Gabriel [2005] adapted definition of pattern proposed by Alexander to a software engineering field. Gabriel defines software pattern as follows:
“Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves.”
Riehle and Züllighoven [1996] proposed definition which highlights abstract nature of pattern:
“A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts.”
1 More information about conferences on design patterns can be found on the Hillside Group home page: http://hillside.net/conferences/
Object-oriented design patterns gained popularity after publication of the book
“Design Patterns: Elements of Reusable Object-Oriented Software” by Gamma, Helm, Johnson and Vlissides, referred as the “Gang of Four” (or just “GoF”) [Gamma et al.
1995]. In this book design patterns ware distinguished from other software patterns and defined in the following way:
“The design patterns […] are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design.”
According to Buschmann et al. [1996], design patterns are applicable in the detailed design when refining software architecture and specifying local design aspects, such as the required support for multiple implementations of a component.
Each pattern presents solution to a problem in a particular context. Solutions described by object-oriented design patterns are expressed in terms of classes, objects, interfaces, and different relationships among them. Design patterns describe structure and behavior of elements that together make a pattern.
Figure 2.1.1 System representations and transformation processes [van Gurp 2000]
Development of a software system can be presented as a process transforming requirements into a working software system. Figure 2.1.1 [van Gurp 2000] presents the concept of such process. It depicts particular system representations and performed transformations during the development process. Design pattern are used during detailed design process and find their representation in the design documentation, which is used as an input to implementation process.
According to Gamma et al. [1995] each design pattern has four essential elements, as identified by Alexander [1979]:
1. The pattern name – a handle describing a design problem, its solution, and consequences;
2. The problem – explanation of the problem and its context describing when to apply the pattern;
3. The solution – description of the elements (classes and objects) that make up design, their relationships, responsibilities, and collaboration.
4. The consequences – results and trade-offs of applying the pattern.
Design patterns are typically described in natural language in rather informal way.
However, patterns authors usually use some kind of template for their description (see Section 4.1). Such templates organize each depiction into sections addressed to particular aspects of a pattern.
Design patterns are means for capturing experience in designing object-oriented software. They give names and describe in a systematic way recurring problems and their solutions. However, precise definition of a design pattern does not exist. Decision about what is and what is not a design pattern is subjective and depends on one’s point of view. As noticed by Gamma et al. [1995] “one’s person’s pattern can be another person’s primitive building block”. That is why interpretation of what is a design pattern should be left to person that uses it.
2.2 Purposes of Using Design Patterns
2.2.1 Design Reuse
Design patterns are means for capturing the experience of expert designers. They describe recurring design problems that arise in specific situations, and present their solutions. Therefore design patterns can be seen as one of the ways for reuse of software design. As stated by Agerbo and Cornils [1998] patterns encapsulate designers’ experience.
Patterns document well-proven design experience, thus proposed by them solutions can be applied immediately to design problems without having to rediscover them [Gamma et al. 1995]. According to Buschmann et al. [1996] understanding and applying well-specified design pattern takes less time than searching for solutions on someone’s own.
According to Coplien [1996] design-level reuse offered by patterns can reduce the amount of time needed to build solution structures, and thus reduce development interval. Moreover, he noticed that patterns increase productivity because they provide domain expertise, and, what is more important, they help to avoid rework that comes from inexpert design decisions.
2.2.2 Higher Level of Abstraction
Design patterns name specified abstractions that are above the level of single classes and instances [Buschmann et al. 1996]. Therefore, they provide a common design vocabulary, which facilitates effective communication, documentation, and exploration of design alternatives [Gamma et al. 1995]. Design patterns raise the level of abstraction of the design and thus make a discussion about a system design less complex. Moreover, patterns can be seen as larger building blocks encapsulating participating classes and objects.
2.2.3 Design Documentation
Design patterns are a means of documenting software design. They help to express designer’s vision and motivation, which he had in mind when designing a software
system. Knowing design patterns makes it easier to understand, and to follow the flow of control of the existing systems [Gamma et al. 1995].
However, after a design pattern is applied in a model its recognition may be hard for a designer if pattern-related information is not kept [Dong 2004]. Therefore, explicit information about occurrence of a design pattern in a model can facilitate its understanding, and prevent from unintentional violation of the design pattern structure during modifications of the original design, or during modifications of the source code of the system [Buschmann et al. 1996].
2.2.4 Building Complex Systems
A design pattern presents not only solution for a design problem in a particular context, but also consequences imposed by this solution. Thus, design patterns support the construction of software with defined properties [Buschmann et al. 1996].
Design patterns can be used to specify different aspects of concrete software design. Each pattern provides predefined set of elements; define their roles and relationships among them. It describes a proven solution to the problem it addresses and explains how this solution works. Therefore, design patterns help to manage software complexity and build complex and heterogeneous software architectures [Buschmann et al. 1996].
2.2.5 Improve Maintenance and Increase Reusability
Software systems during their lifecycle often have to be reorganized or refactored in order to fulfill ever-changing requirements, and to be more reusable. According to Gamma et al. [1995] design patterns can be treated as targets for refactorings [Opdyke 1992, Fowler et al. 1999]. Problem of refactoring towards design patterns was investigated e.g. by Zannier [2002] and Kerievsky [2004]. Design patterns help to determine how to reorganize a design, and thus they can reduce costs of refactoring transformations that would be needed to do later.
According to Coplien [1996] patterns provide road maps to the structure of existing systems. Therefore, they may help inexperienced designers to understand and navigate existing software. This can reduce costs of “designer’s activities to find out how the current system works as a basis for maintenance changes” [Coplien 1996].
2.3 Level of Abstraction of Object-Oriented Design Patterns
Taking into consideration levels of abstraction and detail, design patterns can be layered at the intermediate level, between architectural patterns and idioms [Buschmann et al. 1996].
According to Buschmann et al. [1996] architectural patterns express a fundamental structural organization of software systems. They define subsystems, specify their responsibilities, and provide guidelines for organizing the relationships between them.
Bosch [2000] divides architectural patterns category proposed by Buschmann et al.
[1996] into architectural styles and architectural patterns. In his definition architectural styles are layered above architectural patterns, and express predominant structural organization of software systems, affecting their whole architecture. As examples of the most common architectural styles Bosch [2000] presents among others layered architectural style, pipe and filters or object-oriented style. Architectural patterns, in contrast to architectural styles, are not predominant and can be merged with them without problems. In Bosch [2000] depiction architectural patterns affect the larger parts of software architecture (if not the complete architecture) and that differs them from design patterns. Architectural patterns specify how the architecture
of the system will deal with particular aspects of systems functionality, such as for example persistence or concurrency.
According to Buschmann et al. [1996] design patterns provide a scheme for refining the subsystems or components of a software system, or the relationships between them. They describe commonly recurring structures of communicating components which solve a general design problem within a particular context. Riehle and Züllighoven [1996] define design patterns as patterns which are described by means of software design constructs, like for example classes, objects, aggregations and inheritance.
Idioms, also called coding patterns, are defined by Buschmann et al. [1996] as low-level patterns specific to a programming language. Idioms describe ways of implementation of particular aspects of components or the relationships between them in the given programming language. According to Gil and Lorenz [1998] idioms are features of some existing languages, but not the ones in which they are being applied.
Catalogues of idioms ware elaborated among others by Coplien [1992] and Buschmann et al. [1996].
Riehle and Züllighoven [1996] propose category called programming patterns which is equivalent to idioms. Gil and Lorenz [1998] suggest an additional category for design patterns called cadets, layered just above idioms. Cadets are defined as design patterns which candidate for introducing them into a programming language, but are not yet a feature of any language.
However there is no clear borderline between design patterns, architectural patterns and idioms. Together with evolution of programming languages boundary between design patterns and idioms blurs. For example, when using multimethod object-oriented languages, like CLOS or Cecil, the visitor pattern may be treated as an idiom [Gil and Lorenz 1998]. Situation is very similar in case of architectural patterns.
According to Buschmann et al. [1996] the broker design pattern can be implemented as an architectural pattern at the system level. CORBA [OMG 2004] is one the best known examples of broker architecture [Bosch 2000].
2.4 Design Patterns and Frameworks
According to Gamma et al. [1995] framework can be defied as a set of cooperating classes that together make up a reusable design for a specific class of software. The nature of framework is expressed in the definition of Bosch et al. [1999] who describe framework as “a partial design and implementation for an application in a given domain”. It is set of classes partially implementing an application in a certain domain.
Frameworks may for example be geared to build compilers for different programming languages [Johnson et al. 1992], or to build web applications (e.g.
Apache Cocoon2 web development framework). Frameworks usually define the whole architecture of an application. They specify design of the application and define variation points in this design which are used to customize the framework to the particular application. Frameworks include partial implementation of the proposed solution. Customization of a framework is typically realized by creating application- specific subclasses of abstract classes from the framework.
Frameworks support design reuse and in some way they are similar to design patterns. However, according to Gamma et al. [1995] frameworks and design patterns differ in three ways:
2 Home page of the Apache Cocoon project: http://cocoon.apache.org
1. “Design patterns are more abstract than frameworks” – Frameworks can be embedded in code and reused directly, while design patterns have to be implemented each time they are used.
2. “Design patterns are smaller architectural elements than frameworks” – a framework may contain several design patterns but the reverse is not true.
3. “Design patterns are less specialized than frameworks” – Frameworks are always specialized in a particular application domain, while design patterns usually can be used in almost any kind of application. Even domain-specific design patterns (see Section 2.7) do not have predominant influence on application architecture like a framework does.
Design patterns are used by majority of frameworks to increase the variability and quality of the proposed solution. Descriptions of used design patterns are a common way to enhance the framework’s documentation.
2.5 Collections of Patterns
According to Buschmann et al. [1996] different pattern collections can be classified as pattern catalogues, systems, and languages when take into consideration degree of structure and interdependencies between patterns.
1. Patterns Catalogues – they are somehow structured and organized collections of patterns. It usually does not show relationships between patterns. Typically it divides patterns into a small number of broad categories.
2. Patterns Systems - a pattern system is a collection of related patterns supporting the construction and evolution of software systems. Pattern system consists of descriptions of patterns in uniform and consistent style, descriptions of various relationships between patterns and their groupings, and guidelines for their combination, implementation and practical use in software development. It organizes constituent patterns into related groups and subgroups at multiple levels of granularity in a way, which enable quick location of pattern solving concrete design problem and patterns offering alternative solutions. One of the most widely known pattern system was written by Buschmann et al. [1996].
3. Pattern Languages - according to Buschmann et al. [1996] a pattern language is a collection of patterns which covers every aspect of importance in a particular domain, i.e. for every aspect of the construction and implementation of software systems there must exist available pattern. Pattern languages exist for some small and well-known domains. Two examples are Crossing Chasms [Brown and Whitenack 1996] for connecting object-oriented applications to relational databases, and CHECKS [Cunningham 1995] for information integrity.
2.6 Relationships between Object-Oriented Design Patterns
In catalogue of patterns proposed by Gamma et al. [1995] authors highlighted that patterns may refer to each other in different ways. Relationships among GoF patterns ware analyzed by Zimmer [1995] and organized into different categories. He identified three categories of relationships between the pairs (X, Y) of design patterns:
1. X uses Y in its solution – the design pattern X uses in its solution the design pattern Y, thus the solution of Y is a part of the solution of X. To simplify description of the pattern X reference to the pattern Y can be made. In order to raise the abstraction level, internal implementation details of the pattern Y can be visualized as one element.
2. Variant of X uses Y in its solution – some variants of the design pattern X may use the design pattern Y in their solutions (i.e. the usage of Y by X is optional). So related deign patterns may be used as larger building blocks in design, raising in this way the abstraction level.
3. X is similar to Y – the design patterns X and Y address a similar kind of problem (but not a similar kind of solution). This relationship may be helpful in choosing the right pattern to solve a certain kind of problem. However, similarity between design patterns is subjective. Patterns similar for one designer may seem completely dissimilar to another.
Relationships between GoF design patterns identified by Zimmer [1995] are presented in Figure 2.6.1.
!
"
#
$
% &
% &
% &
% &
" #% &
% &
Figure 2.6.1 Relationships between GoF design patterns [Zimmer 1995]
Classification of the relationships into categories proposed by Zimmer [1995]
depends partly upon subjective assessment. However, those categories clearly reflect nature of relationships between design patterns.
2.7 Classification of Object-Oriented Design Patterns
The main goal of design patterns classification is to facilitate selection of the right pattern to apply; it should be a roadmap to pattern selection. Classification should help in understanding the main properties of pattern, without the need of familiarization with its details. Classification schemas are used to structure pattern systems and catalogues. Classification schemas can be also used to highlight the relationships between patterns.
One design pattern usually have different properties, thus it can be included in many categories. According to Buschmann et al. [1996] in order to minimize complexity and ambiguity of classification schema there should be only few classification criteria. Classification schema should enable easy selection and classification of pattern. It should also allow for categorization of new patterns and extension of the classification schema by adding new criteria.
One of the most widely known and commonly used design patterns classification was proposed by Gamma et al. [1995].
Gamma et al. [1995] classified design patterns using two criteria. The first criterion is purpose in which the pattern is used, i.e. it reflects what a pattern does.
They distinguished three types of design patterns: creational, structural and behavioral.
Creational patterns relate to the process of object creation. Structural patterns concern the composition of classes or objects. Behavioral patterns describe how classes or objects interact with each other, and how do they distribute responsibility. There is no clear boundary line between structural, behavioral and creational design patterns. Each pattern has its structure; however the structural aspects of the pattern may not be predominant. In situations when behavioral aspects of the pattern are more important than structural aspects (taking into consideration intent of the pattern) the pattern is categorized as behavioral pattern. When structure and behavior described by the pattern concentrate on the process of object creation the pattern is classified as a creational pattern.
The second criterion used by Gamma et al. [1995] is scope, which specifies whether the pattern applies primary to classes or to objects. Class patterns relates to static (fixed at compile-time) relationships between classes and their subclasses.
Object patterns concerns object relationships which are more dynamic and can be changed at run-time.
Classification of design patterns proposed by Gamma et al. [1995] is presented in Table 2.7.1.
Purpose
Scope Creational Structural Behavioral
Class Factory Method Adapter Interpreter Template Method
Object
Abstract Factory Builder
Prototype Singleton
Adapter Bridge Composite Decorator Facade Proxy
Chain of Responsibility Command
Iterator Mediator Memento Flyweight Observer State Strategy Visitor
Table 2.7.1 Classification of design patterns according to Gamma et al.[1995]
Buschmann et al. [1996] found classification presented by Gamma et al. [1995]
too vague and useless for developers when selecting a pattern because scope criterion does not relate to any specific design situation. That is why they proposed classification of patterns basing on two criteria: problem solved by a pattern, and pattern granularity. This classification covers only patterns that are of general applicability in software development.
In problem criterion Buschmann et al. [1996] distinguished following categories:
1. From Mud to Structure – patterns supporting decomposition of an overall system task into cooperating subtasks.
2. Distributed Systems – patterns providing infrastructures for systems that have components located in different processes or in several subsystems and components.
3. Interactive Systems – patterns that help to structure systems with human- computer interaction.
4. Adaptable Systems – patterns providing infrastructures for the extension and adaptation of applications in response to evolving and changing functional requirements.
5. Creation – patterns that help with instantiating objects and recursive object structures.
6. Structural decomposition – patterns supporting decomposition of subsystems and complex components into cooperating parts.
7. Organization of Work – patterns defining how components collaborate to provide a complex service.
8. Access Control – patterns that guard and control access to services or components.
9. Service Variation – patterns supporting changing the behavior of an object or component.
10. Service Extension – pattern that help to add new services to an object or object structure dynamically.
11. Management – patterns for handling homogenous collections of objects, services and components in their entirety.
12. Adaptation – patterns that help with interface and data conversion.
13. Communication – patterns organizing communication between components.
14. Resource Handling – patterns helping in managing shared components and objects.
Granularity criterion relates to the level of abstraction of the pattern (described in Section 2.3) and distinguishes categories: architectural patterns, design patterns, and idioms.
Classification of patterns presented by Buschmann et al. [1996] is presented in Table 2.7.2, which presents patterns described by Buschmann et al. [1996] and GoF patterns (shown in italics).
Granularity
Problem Architectural
Patterns Design Patterns Idioms From Mud to Structure Layers
Pipes and Filters Blackboard
Interpreter
Distributed Systems Broker
Pipes and Filters Microkernel Interactive Systems MVC
PAC Adaptable Systems Microkernel
Reflection
Creation Abstract Factory
Prototype Builder
Singleton Factory Method
Structural Decomposition Whole-Part
Composite
Organization of Work Master-Slave
Chain of Responsibility
Access Control Proxy
Façade Iterator
Service Variation Bridge
Strategy State
Template Method
Service Extension Decorator Visitor
Management Command Processor
View Hander Memento
Adaptation Adapter
Communication Publisher-Subscriber
Forwarder-Receiver Client-Dispatcher- Server
Resource Handling Flyweight Counted Pointer
Table 2.7.2 Classification of patterns according to their functionality [Buschmann et al.
1996]
Buschmann and Meunier [1995] presented criterion for design patterns categorization which bases on structural principles. They identified following categories:
1. Abstraction – patterns providing an abstract or generalized view of a particular element of design, such as Abstract Factory or Decorator [Gamma et al. 1995];
2. Encapsulation – patterns encapsulating details of a particular element of design to remove dependencies on it from its clients or to protect these details from access, such as Forwarder-Receiver [Buschmann et al. 1996];
3. Separation of concerns – patterns factoring out specific responsibilities into separate objects or components, such as Proxy [Buschmann et al. 1996];
4. Coupling and cohesion – patterns removing or relaxing the structural and communicational relationships and dependencies between otherwise strongly coupled objects, such as Bridge or Adapter [Gamma et al. 1995].
Zimmer [1995] adopted the idea of design patterns classification based on relationships between patterns proposed by Gamma et al. [1995]. He analyzed GoF design patterns and defined three kinds of relationships between them: pattern X uses pattern Y in its solution, pattern X can be combined with pattern Y, and pattern X is similar to pattern Y [see Section 2.6]. Basing on observed relationships, Zimmer [1995] identified three layers of GoF design patterns:
1. Basic design patterns and techniques – very general design patterns that are heavily used by other patterns, such as Singleton, Mediator, Façade, Iterator or Template Method;
2. Design patterns for typical software problems – design patterns used for more specific design problems, but not typical for a certain application domain.
Examples are Abstract Factory, Builder, Observer, Adapter, Bridge, Strategy, Decorator or Proxy;
3. Design patterns specific to a given application domain – the most specific design patterns that can be assigned to one or more application domains, such as Interpreter, which main application domain is compiler construction.
Schmidt et al. [1996] denote that patterns can be categorized on patterns focused on object-oriented design and programming, and object-oriented modeling, and on patterns which focus on particular problems, such as efficiency, reliability, concurrency, parallel, and distributed programming. To this classification a new category called domain-dependent patterns can be added, which deals with patterns that can be implemented only in given technology. EJB design patterns [Marinescu 2002], which can be implemented only in J2EE technology, can be classified to domain-dependent category.
Basing on observations of Schmidt et al. [1996] we can organize design patterns into two broad categories: domain-independent design patterns and domain-specific design patterns:
1. Domain-independent design patterns - contain general-purpose patterns focused on object-oriented design, such as for example GoF patterns [Gamma et al. 1995] or patterns presented by Buschmann et al. [1996].
2. Domain-specific design patterns - cover patterns focused on a particular problem domain. This category can be divided into two subcategories:
a. Platform-independent patterns – patterns focused on particular problems such as efficiency, concurrency or exception-handling, which can be used independently on technology.
b. Platform-specific patterns – patterns that can be implemented only in a given technology, such as for example J2EE design patterns [Marinescu 2002].
In some cases it might be reasonable to make a subset of design patterns addressing to a particular kind of problem and to create special taxonomy only for this group of patterns. Such taxonomy does not have to be applicable for all design patterns. However, it may be very useful in finding the proper pattern. An example of such approach is the classification proposed by Keshav and Gamble [1998], which bases on architectural integration strategies. They analyzed software component integration strategies whose details may be expressed in the form of design patterns, and suggested three main categories for architectural integration strategies, which are applicable to deign patterns: translator, controller and extender, and their combinations. Translators deal with incompatible data forms or interfaces and embrace such patterns like Adapter or Bridge [Gamma et al. 1995]. Controllers coordinate communication between objects or classes, such like e.g. Broker or Façade [Gamma et al. 1995]. Extenders are used to extend features of classes or objects; this category includes such patterns like Decorator or Proxy [Gamma et al. 1995]. Classification proposed by Keshav and Gamble [1998] is presented inFigure 2.7.1 on example of GoF patterns.
'
!
Figure 2.7.1 Taxonomy of design patterns for architecture integration [Keshav and Gamble 1998]
2.8 Example of Design Pattern
In this section example of the Adapter design pattern is presented in order to bring the reader closer the nature of patterns. Adapter is a typical domain-independent structural design pattern.
Depicted here description of the Adapter pattern bases on the one presented in Gamma et al. [1995].
Name: Adapter
Intent: The intent of the Adapter design pattern is to convert the interface of a class into another interface required by client. Adapter let classes work together that couldn’t otherwise because of incompatible interfaces.
Also Known As: Wrapper Motivation:
Sometimes existing class realizes desired functionality but it cannot be reused because its interface does not match the domain-specific interface required by application.
Consider for example a drawing editor which uses graphical objects that have editable shape and can draw themselves. Interface for these objects is defined by an abstract class called ‘Shape’. For each kind of graphical object editor defines a subclass of ‘Shape’, i.e. a ‘LineShape’ class for lines etc.
If we have to create a ‘TextShape’ subclass that has to realize difficult to implement displaying and edition of text, and already existing class ‘TextView’
realizing such functionality, we would like to use ‘TextView’ to implement
‘TextShape’. However, ‘TextView’ has different interface than ‘Shape’ and object of these classes cannot be used interchangeably.
The problem is how unrelated classes like ‘TextView’ can work in an application that requires classes with different and incompatible interface, without changing these classes.
This problem can be solved by defining ‘TextShape’ class so that it adapts the
‘TextView’ to interface to “Shape’s”. It can be done in two ways:
1. by inheriting “Shape’s” interface and “TextView’s” implementation;
2. by composing a ‘TextView’ instance within a ‘TextShape’ and implementing
‘TextShape’ in terms of “TextView's” interface.
These two solutions correspond to the class and the object version of the Adapter pattern, in which class ‘TextShape’ is called ‘adapter’. The diagram depicting the solution using the object adapter version is presented in Figure 2.8.1
Adapter can be responsible for functionality that is not provided by the adapted class. In the example ‘TextShape’ supply implementation for operation
‘createManipulator’ which is not supported by ‘TextView’.
Figure 2.8.1 Example of a design pattern - Object Adapter Applicability:
Adapter pattern can be used when:
• you want to use an existing class, but its interface in incompatible with the required one;
• you want to create a reusable class cooperating with classes that do not necessarily have compatible interfaces;
• (only object adapter) you need to use several existing subclasses, but it’s impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.
Structure:
Object adapter relies on object composition. Its structure in presented in Figure 2.8.2.
Figure 2.8.2 Structure of the Object Adapter Design Pattern
Class adapter uses multiple inheritance to adapt one interface to another. Its structure is depicted in Figure 2.8.3.
Figure 2.8.3 Structure of the Class Adapter Design Pattern Participants:
• ‘Target’ – defines the interface used by ‘Client’;
• ‘Client’ – collaborates with objects conforming to the ‘Target’ interface;
• ‘Adaptee’ – defines existing interface that needs adapting;
• ‘Adapter’ – adapts the interface of ‘Adaptee’ to ‘Target’ interface.
Collaborations: ‘Client’ calls operations on an ‘Adapter’ instance. In turn, the
‘Adapter’ instance calls ‘Adaptee’ operations that carry out the request.
Consequences:
Class Adapter trade-offs:
• Class Adapter will not work when we want to adapt a class and all its subclasses;
• Adapter can override some of Adaptee’s behavior;
• Introduces only one object, and no additional pointer indirection is needed to get to an instance of the ‘Adaptee’ class.
Object Adapter trade-offs:
• A single ‘Adapter’ can work with many ‘Adaptees’, i.e. with the
‘Adaptee’ and all its subclasses. It can add functionality to all ‘Adaptees’
at once;
• makes it harder to override Adaptee behavior.
Related patterns:
• Bridge – its structure is similar to an object adapter, but Bridge has different intent;
• Decorator – enhances another object without changing its interface, it supports recursive composition which is impossible in pure adapters;
• Proxy – defines a representative or surrogate for another object and does not change its interface.
3 T OOL S UPPORT FOR D ESIGN P ATTERNS U SAGE
Along with increasing popularity of design patterns in the software community, different concepts of tool support for their usage have appeared since the middle of nineteen ninety’s. However, even now the idea of automation of pattern connected activities may be regarded as a contentious issue. It is caused by complex and rather informal nature of the design patterns which may be treated as an essay expressing the abstract concept of solution for recurring design problems that has to be adapted by designer to a particular situation. James Coplien [1996] wrote:
“Patterns guide humans, not machines. They will not generate code; they do not live inside CASE tools. They are literature that aids human decision-making processes.
Patterns should not, cannot, and will not replace the human programmer.”
Tools cannot automate all processes connected with design patterns usage. The final decision which pattern should be applied and how it should be customized have to be made by the human designer, who is conscious of all consequences of his decision. However, it does not mean that tools cannot provide any support for usage of design patterns. They cannot replace the designer, but they can assist him in choosing the right pattern to apply, help him in the complex task of the pattern implementation, and discharge him from performing some recurrent and tedious activities associated with documentation of the pattern instance. Tools can ensure that pattern constraints are respected and relieve the designer of some implementation burdens, and therefore they allow him to concentrate on more important tasks [Le Guennec et al. 2000].
In the following sections different ways of tool support for design patterns usage are presented. This research focuses on support that can be provided by UML modeling tools during detailed design phase of software system development.
Therefore, issues connected with design patterns usage at the source code level are not investigated.
Classification of ways of tool support for design pattern usage is presented in Section 3.1. Tool support for activities connected with handling of design pattern specification and design patterns catalogue is investigated in Section 3.2, and support for activities connected with the process of a design pattern instantiation and maintenance of pattern instances in a design model is analyzed in Section 3.3.
Classification of identified ways of the tool support is presented in Section 3.4.
Survey of available on the market UML modeling/IDE tools offering support for design patterns usage is presented in Section 3.5. Comparison of analyzed tools in accordance with the classification of possible ways of tool support for design patterns usage is presented in Section 3.6.
3.1 Classification of Ways of Supporting Design Patterns
Kim and Benner [1995] suggested splitting the design into two levels: the design level and situated above pattern level. Design level refers to classes, associations etc.
taking part in a design pattern instance, while pattern level refers to definition of the design pattern. This distinction may be applied to tool support for design patterns.
Florijn et al. [1997] has worked on tool support for design pattern instantiation and validation at the source code level. They suggested that pattern-based development environment should provide three mutually consistent views:
1. The pattern level – referring to introduction of new patterns into the system, linking them together, replacing one pattern instance with another;
2. The design level – referring to visualization of a structure of a design pattern;
3. The code level – allowing for edition of source code implementing a particular design pattern instance in a particular programming language.
Basing on concepts presented by Kim and Benner [1995] and Florijn et al. [1997]
tool support for design pattern usage that can be provided by UML modeling tools can be divided into three levels:
1. The pattern level – refers to support for design pattern specification, (including relationships between patterns), organization and maintenance of design patterns catalogues (including creation and maintenance categorization schemas), help in choosing the right design pattern.
2. The design level – refers to process of design pattern instantiation, keeping track of design pattern instance, pattern visualization, pattern validation, and recognition of the design pattern instance in a design model.
3. The code level – refers to the process of generation of source code from the design model and identification of design pattern instances during reverse engineering process, and traceability between design model and source code [Albin-Amiot and Guéhéneuc 2001]. Problem of tool support at this level is beyond the scope of this work.
3.2 Tool Support at the Pattern Level
Tool support for design patterns usage at the pattern level embraces support for all activities connected with handling of design pattern specification and design patterns catalogue.
3.2.1 Handling Design Pattern Specification
Each design pattern describes a solution to a recurring design problem in a particular context, and thus is a mean for encapsulation of a designer’s experience.
Patterns provide not only the structure of a solution, but also explain the concept of the pattern and consequences of its application. Therefore, they contain aspects that can be described only with usage of the natural language (see Section 4.2.1). Tool offering support for design patterns should provide textual description of a design pattern in one of the commonly accepted formats (e.g. format proposed by Gamma et al. [1995], see Section 4.1) in order to facilitate comprehension of the pattern by a designer. Tool should provide at least a reference to comprehensive description of a design pattern.
Tool should also provide structural diagram presenting the abstract structure of the solution proposed by a design pattern. Visualization of such structure facilitates understanding of the pattern and gives an outlook of the pattern participants.
Tool should supply specification of the structure of the solution described by the pattern, and specification of the behavior defined by the pattern. Design pattern specifications within a tool should not only define the structure of the pattern solution, but also, if necessary, constraints that have to be obeyed by design model elements taking part in the pattern instance.
Design pattern specifications used by a tool should be expressed in a way allowing for their interchange among different UML modeling tools with usage of the standard XMI mechanism [OMG 2003]. Therefore, such information should be expressed with usage of constructs specified in the UML Specification [OMG 2004b] such as for example mechanism of profiles.
3.2.2 Handling Design Patterns Collection
No design pattern collection is exhaustive, thus tool supporting design pattern usage should allow for adding specifications of new design patterns. Consequently, it should also allow for edition and specification of new variants of already existing design patterns, and removing of outdated patterns.
When adding a new design pattern to the collection, a tool should allow for creation of the complete design pattern description, i.e. for creation of the textual description of the pattern, precise specification of the structural aspects of the pattern solution and specification of its behavioral aspects. Textual descriptions of design patterns should have uniform format (see Section 4.1), and a tool should enforce usage of a particular one (e.g. format proposed by Gamma et al. [1995], see Section 4.1).
However, it might be reasonable to provide tool support for many different formats for design pattern description in order to enable usage of already existing patterns descriptions. Such solution could prevent from labor-intensive rewriting existing descriptions into desired format, but on the other hand it may obstruct comparison of design patterns specifications.
A tool should allow for specification of constraints that have to be obeyed by design model elements taking part in the pattern instance. Tool should also support specification of the compound design patterns. A tool ought to allow for classification of a design pattern specification in the classification schema defined it the tool (see Section 3.2.3). A tool should also allow for defining relationships between design patterns.
There are two possible ways of handling a design patterns catalogue within a tool:
1. Administration of the design patterns catalogue from the level of the user interface of the tool – in this approach addition of a new design pattern specification, its edition, etc. is realized via tool’s user interface, e.g. in special dialog boxes;
2. Administration of the design pattern catalogue is not accessible from the level of the tool’s user interface and is realized by special configuration files or via external API providing access to the patterns catalogue.
A tool should also support import and export of design patterns specifications among different tools.
3.2.3 Handling Design Patterns Classification Schema
Likewise the case of a design patterns catalogue there are two possible ways of handling a classification schema within a tool:
1. Administration of the classification schema from the level of the user interface of the tool;
2. Administration of the classification schema is not accessible from the level of the tool’s user interface and is realized by special configuration files or via external API providing access to the classification schema.
A tool supporting design patterns should organize them along with some classification schema. There are two main approaches to tool support for design pattern classification schema:
1. Support for hierarchical classification schema – in this approach a single design pattern can belong to only one pattern category; optionally pattern categories may have subcategories.
2. Support for multidimensional classification schema – in this approach a single design pattern may belong to many categories at the same time. This solution is in accordance with the nature of the classification schemas developed for design patterns (see Section 2.7), and thus it is more desirable than the hierarchical approach. For example, the Composite [Gamma et al. 1995]
design pattern may simultaneously belong to category referring to structural
