Eran Toch technion.ac.il/~erant

1Spring 2005Specification and Analysis of Information Systems

Eran Toch

http://www.technion.ac.il/~erant

Winter 2007

Abstracting Solutions with Design Patterns

22

Agenda

• What are Design Patterns?

• Composite Pattern

• Façade Pattern

• 3-Tier Pattern

• Go Back to a Safe Place Pattern

• Summary

33

Patterns in Architecture

• Does this room makes you feel happy?

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

Intro | Composite | Façade | 3-Tier| Safe Place | Summary

44

What is a Design Pattern?

In Short, a solution for a typical

problem

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


55

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 prospective– Frees us from dealing with the details too early

• In short, it’s a “reference”


66

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


77

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


88

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


99

Classification of GoF Patterns

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


1010

Agenda



• Façade Pattern

• 3-Tier Pattern


• Summary

1111

An Example

Files

Folders

Client


1212

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:– What if there are

more types of elements (disks, CD, USB…)


1313

The Composite Solution


1414

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.


1515

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.


1616

Composite: When to Use?

• Tree structures that represent part-whole hierarchies.

• Uniform access.


1717

Composite: Known Uses

Window

Tab Another Tab

Another Window

OKCancel

ButtonCancel

OK

op 1

op 2

A * (B + (C * D))

A ()

*

+

B *

C D

Graphical User Interface Arithmetic Expressions


1818

Agenda



• Façade Pattern

• 3-Tier Pattern


• Summary

1919

Façade – an Example

• A robot has four classes:– Camera (that can identify objects)– Arm (that can move)– Pillars (that can grab)

Operator

Move(location)

Arm

Identify(object) : Location

Camera

open )(close )(

Pliers

Subsystem: operator

Subsystem: mechanics


2020

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.

• 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();


2121

Façade Pattern


2222

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.


2323

Façade Structure

Operator

move(location)

Arm

identify(object) : location

Camera

open()close()

Pliers

moveObject(object, newLocation)

Facade

Operator interacts only with the Façade class

The Façade Class knows and controls the subsystem objects


2424

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


2525

Façade – the System Level

• General patterns for constructing subsystems.

• Each subsystem is represented by a façade interface

• Inner details are encapsulated


2626

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


2727

Agenda



• Façade Pattern

• 3-Tier Pattern


• Summary

2828

Bank Services: Multiple Channels

Web SMS

Terminal Branch

Intro | Composite | Façade | 3-Tier | Safe Place | Summary

* Taken from a bank Leumi commercial* Taken from a bank Leumi commercial

2929

Managing Systems in Banks

Web Terminal• Doing things twice

– Same data?– Same processes?– Views similar?

• Agility– Legislation changes

processes.– Business needs drive

new services, new views

• Manageability– Different teams

working on views, processes, data.

DateDate


3030

3-Tier Pattern

• Intent– Breaking the application to three parts:

• Boundary (view)• Control (process)• Entity (data)

– Centralizing the business logic of the application from the scattered methods to the control classes

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

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


3131

3-Tier Structure

Represents the system’s interface to the outside world

Represents application processes

Represents consistent data


3232

Crossing from Use-Cases into 3-Tier

• 3-tier allow us to translate use-case requirements into an analysis model in a more intuitive way

• Let’s look at the following use-case:

Order handling

Sales person

Inventory reporting

Accounting system

Inventory system


3333

Step 1 – Boundary Tier

Accounting SystemRead Interface

Accounting SystemWrite Interface

Inventory SystemInterface

System API

Sales Interface

In the simplest form, each actor gets an interface:

However, it can be more complicated. Several interfaces can serve one actor, generalization can be used, and several actors can share interfaces

Accounting SystemInterface

Inventory SystemInterface

Sales Interface


3434

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


3535

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


3636

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


3737

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


3838

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


3939

3-Tier Consequences

• Good:– Re-use of Model

components– Flexible processes– Easier support for new

types of views

• Bad:– Increased design

complexity.

Web Terminal

Date

Stocks data

Money transfer


4040

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


4141

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


4242

Agenda



• Façade Pattern

• 3-Tier Pattern


• Summary

4343

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…


4444

Computers can be SCARY

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


4545

Solution

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

The "Home" button and the “Back”

The “undo" feature


4646

Agenda



• Façade Pattern

• 3-Tier Pattern


• Summary

4747

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


4848

Summary

Patterns learned:– Composite, Façade, 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.


4949

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


5050

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


51Spring 2005Specification and Analysis of Information Systems

Thanks!

Documents

Eran Toch technion.ac.il/~erant