Pattern Classification Kal Vot

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
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.
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
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.
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.
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.
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.
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.
Pattern Classification Criteria
Discipline
Scope
Domain
Criteria
Purpose
Paradigm
Granularity
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.
Classification by Discipline: Example
A pattern system for conservation economy [ConservationEconomy04]

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.
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.
Thread Barrier Implements a barrier for n components or threads. Watchdog
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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

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
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).

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.

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.

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.
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
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.
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
Iterator
Flyweight
X can be combined with Y
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.
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]

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]

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.
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.

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.

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.
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.
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).
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

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
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

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
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
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.
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.
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.
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.
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
Thank You!
Questions?

Pattern Classification Kal Vot

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pattern Classification Kal Vot

Uploaded by

Copyright:

Available Formats

Pattern Classification

Imed Hammouda & Jakub Rudzki

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Introduction: What is a Pattern?

Pattern classification techniques

Dimensions of Classification Schemas

Dimensions of Classification Schemas

Purpose of Pattern Classification

8109103 Ohjelmistotuotannon Teoria

Purpose of Pattern Classification

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Properties of Classification Schemas

Properties of Classification Schemas

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Pattern Classification Criteria

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification Criteria: Discipline

Classification by Discipline: Example

A pattern system for conservation economy [ConservationEconomy04]

Classification Criteria: Domain

8109103 Ohjelmistotuotannon Teoria

Classification by Domain: Example

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

8109103 Ohjelmistotuotannon Teoria

Classification Criteria: Paradigm

8109103 Ohjelmistotuotannon Teoria

Classification by Paradigm: Example

8109103 Ohjelmistotuotannon Teoria

Classification Criteria: Granularity

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Granularity: Example

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification Criteria: Purpose

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Purpose: Example

Classification Criteria: Scope

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Classification by Scope: Example

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

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Example Classification: GOF

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

Example Classification: GOF

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

GOF Classification: Singleton

Ensure that only one object of given class is created

8109103 Ohjelmistotuotannon Teoria

Tampere University of Technology Software Systems Institute

GOF Classification: Adapter

Line BuildingBox() CreateManipulator()

TextShape BuildingBox() CreateManipulator()