You are on page 1of 55

Pattern Classification

Imed Hammouda & Jakub Rudzki


imed@cs.tut.fi, jakub.rudzki@tut.fi 10.03.2004

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Outline
Introduction Pattern Classification Classification Criteria Example Classification Schemas Conclusions

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Introduction: What is a Pattern?


Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. [Alexander77] Each pattern is a three-part rule that expresses a relation between a certain context, a certain system of forces that occurs repeatedly in that context, and a certain software configuration that allows these forces to resolve themselves. [Gabriel] A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. [Buschmann96]
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Pattern Classification
The increase in the number of patterns made it very important to develop proper methodologies and techniques how to organize them.

Pattern classification techniques


Pattern classification is the organization of patterns into groups of patterns sharing the same set of properties. The kind of these properties is not fixed and may include criteria such as structure, intent, or applicability. Depending on the chosen criteria, we could define a classification schema.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Dimensions of Classification Schemas


Different classification schemas can have different dimensions. A two dimensional schema, for example, uses two criteria in the classification process. Usually, the more dimensions a schema has, the more useful the classification is. Better partitioning of the pattern space
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Dimensions of Classification Schemas


The same pattern can have different kinds of properties, it can be included in more than one category. Each property maps the pattern to the category of that property kind. In order for the classification to be efficient, we think that a pattern should not belong to more than two categories. Hint: Concentrate on the major attributes of patterns.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Purpose of Pattern Classification


The main goal of pattern classification is to make it easier for software developers to select the right pattern to apply. Example: In order to solve a certain design problem, the right design pattern, if available, should be selected. For selecting a specific pattern, i.e. pattern selection, the nature of the problem should be matched with the right pattern category. Hint: Match the description of the problem with the description of the pattern category, then with the description of the individual patterns.
Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

Purpose of Pattern Classification


Classification schemas can be used to understand and perceive the main properties of patterns. It is usually impractical to go through all the details of all the patterns before picking up the right pattern. Classification schemas can be used to structure a pattern system and highlight the relationships between the constituent patterns.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Properties of Classification Schemas


According to [Buschmann96]:
Simple and easy to learn: It should be easy to use the classification scheme to classify and select patterns. Few classification criteria: In order to reduce complexity and ambiguity, the classification schema needs to be as compact as possible in terms of the number of criteria. Reflecting pattern properties: Using the classification schema, it should be possible to represent the main properties of the patterns to be classified. Roadmap to pattern selection: The classification scheme should ease the pattern selection process. Openness to the integration of new patterns: Using the classification schema, it should be possible to classify new patterns.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Properties of Classification Schemas


Additional Properties:
Openness to new classification criteria: It should be possible to extend the classification scheme by either increasing its dimension or by modifying a given dimension. Reflecting the relationship between patterns: In addition to capturing their main properties, the classification schema should be able to highlight the relationships between the patterns.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Pattern Classification Criteria

Discipline

Scope

Domain

Criteria

Purpose

Paradigm

Granularity

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification Criteria: Discipline


A natural way to classify patterns is to categorize them according to the discipline when they are applied. Patterns have originated from the field of urban construction by Christopher Alexander. Patterns have been later applied in different fields such as software engineering, music and economy. It is unlikely that a pattern applied in one discipline becomes relevant to another.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Classification by Discipline: Example

A pattern system for conservation economy [ConservationEconomy04]


8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Classification Criteria: Domain


In software engineering, patterns are mostly known for, but not restricted to, solving problems of design and architecture. Different patterns have been proposed to solve design problems in various areas of software engineering. Patterns have been applied in the domain of real-time systems, communications, distributed systems, user interface, embedded systems, etc. Software developers tend to select patterns within the category matching their specific problem domain.
Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

Classification by Domain: Example


Real-time Design Pattens: [Douglass99] Pattern
Latch Polling Transaction

Description
Remember that a pre-conditional state has been achieved for later synchronization. Periodically perform an action. Model different quality-of-service transaction styles, such as remote communications. Execute a periodic liveness check to ensure the application is continuing properly by generating a stroke event for the watchdog orthogonal state component.
Tampere University of Technology Software Systems Institute

Thread Barrier Implements a barrier for n components or threads. Watchdog

8109103 Ohjelmistotuotannon Teoria

Classification Criteria: Paradigm


Patterns became a popular practice in the development of objectoriented software systems. Patterns apply to other paradigms as well. Imperative languages may provide their own imperative patterns. In the object oriented paradigm, patterns are described in terms of concepts like objects, classes, object composition, and class inheritance. In imperative programming, patterns are mainly expressed in terms of other concepts such as functions and procedures.
Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

Classification by Paradigm: Example


A pattern catalogue for functional logic languages: [Antoy02] Pattern
Constrained Constructor

Intent
Prevent invoking a constructor that might create invalid data.

Concurrent Distinct Choices Ensure that a mapping from indexes to values is injective. Incremental Solution Locally Defined Global Identifier Opaque Type Compute solutions in an incremental manner. Ensure that a local name is globally unique. Ensure that values of a datatype are hidden.
Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

Classification Criteria: Granularity


Patterns in a software system can be categorized depending on the level at which they address the system. It is sometimes difficult to draw the border line between different pattern categories. The same pattern could be classified in different granularity categories.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Granularity: Example


Widely used granularity-based classification: [Buschmann96]
Architectural patterns: refer to a software system at high level. Design patterns: focus on subsystems and components. Idioms (coding patterns): address the lowest level of a software system.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification Criteria: Purpose


An efficient method to classify patterns is to categorize them according to their purpose. The purpose represents the kind of problems the pattern solves. This criterion is the most useful since it describes the concrete situation where the pattern applies.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Purpose: Example


For designing real-time frameworks, the following purposes are defined: [Douglass99]
Architectural support patterns: represent the strategic decisions for the organization of real-time applications. Collaboration and distribution: patterns provide solutions to common application domain problems in real-time systems. Safety and reliability patterns: deal with common problems of safety and reliability. Behavioral patterns: provide different implementation solutions involving multiple objects.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Classification Criteria: Scope


Patterns can then be classified according to the features implementing them. Such a classification criteria is known as scope. In the object-oriented paradigm, design patterns can be implemented using either object composition or class inheritance.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Scope: Example


GOF classification uses the scope criterion: [Gamma95]
Class representation: uses class inheritance. Object representation: uses object composition.

The same pattern might be implemented either way. Example: Adapter.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Example Classification: GOF


The design patterns catalogue presented in [Gamma95] is one of the most widely known pattern classification schema. GOF classification is two dimensional. Patterns are classified by their purpose and scope.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Example Classification: GOF


Purpose:
Creational: related to object creation. Structural: concerning structures (compositions) created by classes and objects. Behavioral: deal with the way responsibilities in classes are distributed.

Scope:
Class representation: uses class inheritance. Object representation: uses object composition.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

GOF Classification: Singleton


Purpose: Creational Scope: Object
Singleton static Instance() SingletonOperation() GetSingletonData() static uniqueInstance singletonData
return uniqueInstance

Ensure that only one object of given class is created

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

GOF Classification: Adapter


Purpose: Structural Scope: Object or Class
TextView DrawingEditor Shape BuildingBox() CreateManipulator() GetExtent()

Line BuildingBox() CreateManipulator()

TextShape BuildingBox() CreateManipulator()

return text -> GetExtent()

return new TextManipulator

Convert the interface of a class into another interface clients expect


Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

GOF Classification: Strategy


Purpose: Behavioral Scope: Object
Composition Traverse() Repair() Compositor Compose()

SimpleCompositor
compositor -> Compose()

TeXCompositor Compose()

ArrayCompositor Compose()

Compose()

Define a family of algorithms, encapsulate each one, and make them interchangeable
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Example Classification: Buschmann


The work of Buschmann classifies patterns using two criteria: [Buschmann96] Buschmann classification is two dimensional. Patterns are classified by their granularity (pattern categories) and purpose (problem categories).

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Example Classification: Buschmann


Granularity:
Architectural patterns: specify the fundamental structure of applications. They specify structure of the system as subsystems, and their responsibilities, and define rules for relationships between them. Design patterns: focus on subsystems and components, the middle level of a software system. Design patterns describe common problems arising in a given context of particular subsystem. Coding patterns (idioms): use proven conventions and techniques during the implementation phase of applications.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Example Classification: Buschmann


Purpose:
From mud to structure patterns decompose overall system tasks into smaller collaborating subtasks. Distributed systems patterns provide solutions for applications where components are distributed over different processes and subsystems. Interactive systems patterns deal with human-computer interaction problems. Adaptable systems patterns represent solutions for application that are subject to extension and adaptation. Structural decomposition patterns decompose complex components into cooperating parts.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Example Classification: Buschmann


Purpose:
Organization of work patterns define solutions for solving complex services through component collaboration. Access control patterns manage access to services. Management patterns handle the management of collections of homogeneous objects, services, and components. Communication patterns manage the communication between components. Resource handling patterns manage shared components and objects.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Buschmann Classification: Blackboard


Granularity: Architectural. Purpose: From mud to structure.
Blackboard solutions controlData inspect update Control loop nextSource operate on +1 Knowledge Source updateBlackboard execCondition execAction +1 activates

Several specialized subsystems assemble their knowledge to build a possibly or approximate solution
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Zimmer Classification
Zimmer Classification [Zimmer95] : New classification of the GOF design patterns. Three kinds of relationship between patterns defined:
Pattern X uses pattern Y in its solution. Pattern X is similar to pattern Y. Pattern X can be combined with pattern Y.

These relationships describe new classification schema for the GOF design patterns.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Zimmer Classification - Example


Patterns specific to a given application domain Interpreter

Patterns for typical software problems Builder Prototype Visitor Composite

Objectifier Basic design patterns and techniques


X uses Y in its solution X is similar to Y
8109103 Ohjelmistotuotannon Teoria

Iterator

Flyweight

X can be combined with Y

Tampere University of Technology Software Systems Institute

Domain-Dependent Patterns - J2EE


J2EE design patterns can be implemented only in J2EE technology. Domain specific patterns may be based on other patterns Session Facade is based on the GOF Facade design pattern. They also may be completely domain dependent Value Object J2EE design pattern.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Session Facade Example


Clients directly accessing application components must deal with complexity of the implementation. Changes in the internal implementation affect clients. High number of calls needed to achieve a task.
Client Application Server

Client

Network

Client

Access Without Faade [Marinescu02]


8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Session Facade - Benefits


Access involving Session Faade:
Application internal complexity is hidden. Changes in the internal implementation do not affect clients. Number of calls is reduced.
Client Facade Application Server

Client

Network

Facade

Client

Access With Faade [Marinescu02]


8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Process Patterns
Address the problem of structures and processes in organisations especially in domain of software development. [Coplien94] Applicable to whole organisations or only particular projects. Used in many aspects of organisation structure:
Size of the organisation. Tasks scheduling. Assigning tasks to organisation (project) members. Information flow. Assuring quality level.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Process Patterns Example 1


Size of the organization pattern:
Answers the question how big should be the organisation (project group) for creation a product of 25000 lines of code. Considerations:
Too small organisation may not be able to deal with a task. Too big organisation may not be profitable enough at the beginning and may face communication problems.

Solution:
Create a team of about 10 selected members that number should ensure enough workforce, but should not affect communication and profit margins.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Process Patterns Example 2


Solo Virtuoso pattern:
Addresses small projects not likely to grow rapidly. Considerations:
Too big team may be too costly to maintain when the project is small.

Solution:
The team should be based on one or two members that are specialists in the domain.

Possible problems:
Absence of even one team member may cause challenges to the project.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Process Patterns Example 3


Firewalls pattern:
Addresses communication problems between the team and the outside world. Considerations:
Developers are being directly contacted too often by the outsiders - this distracts developers. Information flow from the outside world must be maintained .

Solution:
A manager role who shields developers from direct contact from outside, but sustains the information flow.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Analysis Patterns
Analysis patterns are used to analyse organisations structures and processes in order to model them in software. [Fowler97] Some Analysis Patterns may be applicable only to one domain (e.g. health care) but many can be used in various domains.

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Analysis Patterns Classification


Analysis Patterns can be classified in following groups:
Accountability describing relations between parties (organisations, people). Observations and measurement used to record information about the world. References to objects how unique to objects in real life can be created. Accounting used in accounting systems. Planning planning and recording of resources use. Trading used for trade analysis (e.g. the influence of changing prices on profits).

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Analysis Patterns - Party


The Party analysis pattern addresses the problem of relating information (phone number, email etc.) to many parties (people or organisations), which are similar to each other.
Telephone Number Person Party Organization Address

Person
Zero or more [0,*] Zero or one [0,1]

Party Analysis Pattern


8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Analysis Patterns - Quantity


The Quantity pattern deals with problem of storing measurement results. Results stored only as values may be difficult to interpret and prone to conversion errors. Without the Quantity pattern the values are interpreted based on an explicit contract with the client.
Person
height: Number weight: Number blood glucose level: Number
Measurement Without Quantity
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Analysis Patterns - Quantity


The Quantity analysis pattern advocates storing values along with units. Measurement results can be stored in units that were used in the measurement. Conversion rules to other units are stored with the results Results are not ambiguous.
Person
height: Quantity weight: Quantity blood glucose level: Quantity

Quantity
amount: Number units: Unit +, -, *, /, =, >, <

Measurement With Quantity


8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Analysis Patterns - Account


The Account pattern can be used to track changes of a value during time e.g. a bank account balance. Current value reflects all changes made in the past. The current value does not have to be recalculated each time it is requested, but it can be cached.
Constraint: balance = sum (entries.amount)

Account
balance: Quantity
Exactly one [1,1]

Entry
amount: Quantity whenCharged: Timepoint whenBooked: Timepoint
Zero or more [0,*]

Account Pattern
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Analysis Patterns - Planning


The proposed and implemented action pattern can be used to monitor plans. Plans consist of actions that may require certain order of execution. The proposed and implemented action pattern allows creating actions in any order when they are planned and then move to implementation. Both proposed and implemented actions are stored.
/
Action Action Status

[lmm]

Proposed Action

Implemented Action

Exactly one [1,1] Zero or more [0,*] Zero or one [0,1]

Proposed and Implemented Action

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Reengineering Patterns
The Reengineering Patterns are used to improve maintainability, performance and to allow further changes to legacy systems. [Demeyer03] For example the Split Up God Class pattern addresses the problem of application functionality being concentrated in only one class, which uses other classes as data structures. Suggested solution includes:
Incrementally moving some functionality of the god class to other classes. Creation of new classes. Finally the god class remains as a facade or can be removed.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Performance Patterns
Performance Patterns aim at improving performance and scalability of software. [Smith01] For example the Fast Path pattern improves the response time by reducing processing required to access main functionality. In case of an ATM, money withdrawal can have a shortcut to the withdrawal functionality where frequently used amounts are stored.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Maintenance Patterns
Maintenance Patterns or Evolution Patterns describe typical changes during lifetime of a software system. Maintenance Patterns differ from the Reengineering Patterns in a way that the first try to find common general rules how systems evolve, while the Reengineering Patterns describe problematic situations and solutions to them during systems evolution. Maintenance Patterns also document system-specific problems and code points where the system may be maintained.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

Conclusions
Patterns address various problems from urban architecture problems, through software engineering to organisation structures and management. Patterns can be classified depending on many criteria:
Discipline where they are used. Domain. Granularity.

Patterns can be classified in different ways; even the same patterns may be classified differently for example Zimmers classification of the GOF design patterns.
8109103 Ohjelmistotuotannon Teoria Tampere University of Technology Software Systems Institute

References
[Alexander77] C. Alexander. A Pattern Language. Oxford University Press, New York, (1977). [Antoy02] S. Antoy and M. Hanus. Functional Logic Design Patterns. In Proc. Of the 6th International Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002. [Barry03] E. J. Barry, C. F. Kemerer, and S. A. Slaughter. On the uniformity of software evolution patterns. In Proceedings of ICSE03, pages 106 113, Portland, Oregon, May 2003. [Buschmann96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. Wiley , (1996). [Brown00] W. J. Brown, H. W. McCornick III and S. W. Thomas. AntiPatterns in Project Management, Addison-Wesley 2000. [ConservationEconomy04] The Conservation economy WWW site. At URL http://www.conservationeconomy.net/. [Coplien94] J. O. Coplien. A Development Process Generative Pattern Language, In Proceedings of PloP/94, Monticello, 11 August 1994. [Demeyer03] S. Demeyer, S. Ducasse and O. Nierstrasz. Object-oriented Reengineering Patterns, Elsevier Science 2003. [Douglass99] B. P. Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns, Addison-Wesley, 19. [Fowler97] M. Fowler.Analysis Patterns, Addison-Wesley 1997. [Gabriel] R. Gabriel: A Timeless Way of Hacking, in Core J2EE Patterns, Pearson Education. [Gamma95] E. Gamma, R. Helm, R. Johnson and J. Vlissides. Design Patterns Elements of Reusable Object-Oriented Software, AddisonWesley 1995. [Marinescu02] F. Marinescu. EJB Design Patterns, Addison-Wesley 2002. [MacDonald02] S. MacDonald, D. Szafron, J. Schaeffer, J. Anvik, S. Bromling and K. Tan.Generative Design Patterns. In Proceedings of the 17th IEEE International Conference on Automated Software Engineering (ASE02) 2002. [Smith01] C. U. Smith and L. G. Williams. Performance Solutions A Practical guide to Creating Responsive, Scalable Software, Addison-Wesley 2001. [Trowbridge03] D. Trowbridge, D. Mancini, D. Quick, G. Hohpe, J. Newkirk and D. Lavigne. Enterprise Solution Patterns Using Microsoft .NET, Microsoft Corporation 2003. [Zimmer95] W. Zimmer. Relationships Between Design Patterns In Pattern Languages of Program Design, J. O. Coplien and D. C. Schmidt (eds.), Reading, MA: Addison-Wesley, 1995, pp. 345

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Thank You!

Questions?

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute