design patterns

1Spring 2005Specification and Analysis of Information Systems

Session 3:

Design Patterns

Winter 2008

Analysis and Specification of Information Systems

Eran Tochhttp://www.technion.ac.il/~erant

3

Patterns in Architecture

• Does this room makes you feel happy?

• Why? – Light (direction)– Proportions– Symmetry – And more...


4

What is a Design Pattern?


A description of a recurrent problem and of the core of possible solutions

A description of a recurrent problem and of the core of possible solutions

In short, a reference

In short, a reference

5

Why do we need Patterns?

• Reusing design knowledge– Problems are not always unique. Reusing existing

experience might be useful.– Patterns give us hints to “where to look for problems”.

• Establish common terminology– Easier to say, "We need a Façade here“.

• Provide a higher level of abstraction– Frees us from dealing with the details too early


6

History of Design Patterns

Christopher AlexanderThe Timeless Way of BuildingA Pattern Language: Towns, Buildings, Construction

1970’

1995’

2007’

Architecture

Object OrientedSoftware Design

Other Areas:HCI, Organizational Behavior,

Education, Concurent Programming…

Gang of Four (GoF)Design Patterns: Elements of Reusable Object-Oriented Software

Many Authors


7

Structure of a design pattern*

• Pattern Name and Classification• Intent

– a Short statement about what the pattern does

• Motivation– A scenario that illustrates where the pattern would be useful

• Applicability– Situations where the pattern can be used

*According to GoF


8

Structure – cont’d

• Structure– A graphical representation of the pattern

• Participants– The classes and objects participating in the pattern

• Collaborations– How to do the participants interact to carry out their

responsibilities?

• Consequences– What are the pros and cons of using the pattern?

• Implementation– Hints and techniques for implementing the pattern


9

Classification of GoF Patterns

Taken from Vince Huston’s site about Design Patternshttp://home.earthlink.net/~huston2/dp/patterns.html


10

Agenda



11

Façade – an Example

• A robot has four classes:– Camera (that can identify objects)

– Arm (that can move)

– Pillars (that can grab)

– Operator – managing other classes

Subsystem: mechanics


12

Problems

1. How much does the operator needs to know regarding the mechanics?

2. For instance, we want to identify an object and move it to some predefined location. The code would look like:

• Problem: No encapsulation– Operator needs to know a lot: structure + behavior

– Preconditions

– Agility

oldLocation = Camera.identify(object);Arm.move(oldLocation);Pliers.close();Arm.move(newLocation);Pliers.open();


13

The Façade Pattern


14

Façade - Definition

• Intent– Provide a unified interface to a set of interfaces in a

subsystem. – Façade defines a higher-level interface that makes the

subsystem easier to use.

• Applicability– Use the Façade pattern

• to provide a simple, default view of a complex subsystem.• to layer your subsystems. Use a façade as the entry point to

each layer.


15

Example

Façade Example

Operators interacts only with the Façade class

The Façade Class “knows” and controls the subsystem objects


16

Façade – the System Level

• Encapsulation at higher levels:– General patterns for

constructing subsystems. – Each subsystem is

represented by a façade interface

– Inner details are encapsulated


17

Façade - Consequences

• Good:– Shields clients from subsystem components– It promotes weak coupling between the subsystem and its

clients. – Façades help layer a system

• Bad:– Duplicated methods– Lower visibility of subsystem functionality


18

More Structural Patterns

• Adapter - Match interfaces of different classes • Bridge - Separates an object’s interface from its

implementation • Decorator - Add responsibilities to objects

dynamically • Flyweight - A fine-grained instance used for

efficient sharing • Proxy - An object representing another object


19

Agenda



20

Buying a Computer: Multiple Channels


An e-commerce system:–Products

–Customers

–Orders

21

Managing Shopping Systems

• Actions are specified twice

• Adding new actions is difficult

• Manageability– Different teams

working on store/web etc...

Example


22

3-Tier Pattern

• Intent– Separating application view, business logic and data

• Structural Pattern– Can be expressed using specialized sterotypes in class

diagram

• Origin– By Ivar Jacobson (not GoF)– Based on the MVC (Model-View-Controller) pattern

See: Rumbaugh et al, Object Oriented Modeling and Design, Prentice Hall, 1991.


23

Illustration

3-Tier Structure

Represents the system’s interface to the outside world

Represents application processes

Represents consistent data


This is a regular class diagram!

24

Step 1 – Boundary Tier

• In the simplest form, each actor gets an interface:

• However, it can be more complicated:– Dividing complex interfaces– Combining interfaces– Generalizing interfaces


25

Boundary Tier Member Distribution

• Boundary tier objects are created when the session starts and are destroyed when the session ends.

• Contains:– Methods operated by the user.– Attributes of the interface.

Pull messages

Push messages

Interface configuration properties


26

Step 2 – Control Tier

We add a control tier. Basically, every use-case gets a control class that handles it’s process

Controls can be decomposed into sub-processes. Again, inheritance can be used


27

Control Tier Member Distribution

• Control objects are created when the action (use-case) starts and are destroyed when it ends

• Contain mainly methods, some of them double the ones in the boundary tier objects

• May contain attributes that are used for the process’s flow management

Flow management of other control objects

Process state variables

Calling interface objects


28

Step 3 – Entity Tier

We add the Entity classes. These classes compose most of the classes in the regular class-diagram mode

Entity classes have mainly associations, rather than dependencies, because they are consistent through the processes


29

Entity Tier Member Distribution

• Entity tier objects represent the consistent data in the system. They are created and destroyed according to the processes that control them

• Contain mainly attributes and some data-handling methods

Example


30

3 Tier Usage patterns

“Y” StructureUsed for communication+ update / retrieve

“l” StructureUsed for date update / retrieve

“V” StructureUsed for communication


31

3-Tier Consequences

• Good:– Re-use of Model

components– Flexible processes– Easier support for new

types of views

• Bad:– Increased design

complexity.

Date

Transaction executing

Info viewing

Loan Manage


32

Behavioral Patterns

• Chain of Responsibilities - A way of passing a request between a chain of objects

• Command - Encapsulate a command request as an object

• Interpreter - A way to include language elements in a program

• Iterator - Sequentially access the elements of a collection

• Mediator - Defines simplified communication between classes

• Memento - Capture and restore an object's internal state


33

Behavioral Patterns – cont’d

• Observer - A way of notifying change to a number of classes

• State - Alter an object's behavior when its state changes

• Strategy - Encapsulates an algorithm inside a class

• Template Method - Defer the exact steps of an algorithm to a subclass

• Visitor - Defines a new operation to a class without change


34

Agenda



35

An Example

Files

Folders

Client


36

A Solution?

• Folder: – For each action

(delete, display, copy etc), there is special treatment for files and folders.

• Explorer:– Each type of object

is manipulated separately

• Scalability:– Handling larger

number of elements (disks, CD, USB…)

Example


37

The Composite Solution

Example


38

Composite: Structure

• An abstract base class (Component) specifies the uniform behavior.

• Primitive and Composite classes are subclassed. • Composite Manages components uniformly, using add and

remove.

Illustration


39

Composite: Consequences

• Good– It makes it easy to add new kinds of components.– It makes clients simpler.

• Bad– It makes it harder to restrict the type of components of a

composite.


40

Composite: Known Uses

A * (B + (C * D))

A ()

*

+

B *

C D

Graphical User Interface Arithmetic Expressions


41

Agenda



42

Human / Computer Interaction Patterns

• Human / Computer Interaction is about how users interact with computers

• Some interactions are recurrent and can be expressed by patterns:– Form– Control Panel – WYSIWYG Editor– Hierarchical Set – Map of Navigable Spaces– Go Back to a Safe Place– More…


43

Computers can be SCARY

Sometimes an innocent user gets into a state she don’t want to be in…And then, the terror!!!


44

Solution

• Provide a way to go back to a checkpoint of the user's choice.

The “undo" featureThe "Home" button

and the “Back”


45

Agenda

• What are Design Patterns?• Composite Pattern• Façade Pattern• 3-Tier Pattern• Go Back to a Safe Place Pattern• Summary


46

Summary

Patterns learned:– Façade, Composite, 3-Tier, Go Back to a Safe Place.

Advantages of Design Patterns:– They capture expertise and make it accessible to non-

experts. – They form a vocabulary that helps developers communicate

better. – They help people understand a systems more quickly when it

is documented with the patterns it uses.


47

Relevancy to the Course

• Most of the design patterns are relevant to the design and coding phases

• However, some of them are very relevant as a tool for the analysis phase

Analysis Design

Façade Composite

Chain of resp.

Singleton Prototype

Flyweight

3-Tier

Visitor


48

References

• Design Patterns: Elements of Reusable Object-Oriented Software, Gamma E. et el., 1995, Addison-Wesley.

• The original patterns for architecture by C. Alexanderhttp://www.enumerable.com/dev/leveltwo/patternsframe.htm?/dev/leveltwo/../apl/twopanel-apl-towns.htm

• A course from Bob Tarr from UMBC Universityhttp://www.research.umbc.edu/~tarr/dp/fall00/cs491.html

• The Design Patterns Java Companion, James W. Cooper (an online version of the book)http://www.patterndepot.com/put/8/JavaPatterns.htm

• A Site dedicated to Design Patterns by Vince Hustonhttp://home.earthlink.net/~huston2/dp/patterns.html


49

References – con’d

• Seven Habits of Successful Pattern Writers, John Vlissideshttp://hillside.net/patterns/papers/7habits.html

• COMMON GROUND: A Pattern Language for Human-Computer Interface Design, Jenifer Tidwell, http://www.mit.edu/~jtidwell/common_ground_onefile.html

• Design patterns for .NET: http://www.dofactory.com/Patterns/Patterns.aspx

• Patterns for Concurrent, Parallel, and Distributed Systemshttp://www.cs.wustl.edu/~schmidt/patterns-ace.html

• J2EE Patterns Cataloghttp://java.sun.com/blueprints/patterns/catalog.html


50Spring 2005Specification and Analysis of Information Systems

Thanks!