Download Lecture 2 for Chapter 8, Object Design: Reusing Pattern Solutions

A Game: Get-15
• The game starts with nine numbers 1,2,3,4,5,6,7,8 and 9
• You and your opponent take alternate turns, each taking a
number
• Each number can be taken only once: If you opponent has
selected a number, you can no longer take it
• The first person to have any three numbers that total 15
wins the game
• Example:
You:
1
5
3
8
Opponent:
Bernd Bruegge & Allen H. Dutoit
6
9
7
2
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Opponent
Wins!
5
Characteristics of Get-15
• Hard to play
• The game is especially hard, if you are not allowed to
write anything down
• Why?
• All the numbers must be scanned to see if you have won/lost
• It is hard to see what the opponent will take if you take a
certain number
• The choice of the next number depends on all the previous
numbers (your and your opponent’s numbers)
• Not easy to devise a simple strategy.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Another Game: Tic-Tac-Toe
Source: http://boulter.com/ttt/index.cgi
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
A Draw Sitation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Strategy for determining a winning move
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Winning Situations for Tic-Tac-Toe
Winning
Patterns
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Tic-Tac-Toe is “Easy”
Why? Reduction of complexity through patterns and
symmetry
Patterns: Knowing the following three patterns, the
player can anticipate the opponents move.
Symmetry:
The player needs to remember only these three
patterns to deal with 8 different game situations
The player needs to memorize only 3 opening
moves and their responses.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Get-15 and Tic-Tac-Toe are identical problems
♦
♦
♦
Any sequence of three numbers that wins the Get-15 game also
wins at Tic-Tac-Toe
Any Tic-Tac-Toe solution is also a solution the to Get-15 problem
To see the relationship between the two games, we simply
arrange the 9 digits into the following pattern
8
1
6
3
5
7
4
9
2
.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
You:
1
Opponent:
6
8
1
6
3
5
7
4
9
2
Bernd Bruegge & Allen H. Dutoit
5
3
9
8
7
2
8
1
6
3
5
7
4
9
2
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
Stays simple !
• During object modeling we do many transformations
and changes to the object model
• It is important to make sure the system model stays
simple during these model transformations
• After all, the goal of a model is to be an abstraction, that is, a
simplification, not a complication
• Design patterns keep the system model simple.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Heuristics for Good Models
• Modeling must address our mental limitations:
• Our short-term memory has only limited capacity (7+-2)
• Good models deal with this limitation, because …
… they do not tax the mind
• A good model requires a minimal mental effort to understand
… they reduce complexity
• Use of patterns
• Use of symmetries
… they use abstractions
• Taxonomies
… they have organizational structure
• Memory limitations are overcome with an appropriate
representation (“natural model”).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Outline of the Lecture
 Two games
 Patterns and symmetry help to win the game
 Heuristics for good models
• Reducing the complexity of models
• Patterns covered in this lecture
•
•
•
•
Composite: Model dynamic aggregates
Facade: Interfacing to subsystems
Adapter: Interfacing to existing systems (legacy systems)
Bridge: Interfacing to existing and future systems
• Next lecture (January 8)
•
•
•
•
Factory and Abstract Factory
Proxy
Observer
Strategy
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Review: Design pattern
A design pattern is…
…a reusable template for solving a recurring design
problem
• Basic idea: Don’t re-invent the wheel!
… design knowledge
• Knowledge on a higher level than classes, algorithms or data
structures (linked lists, binary trees...)
• Lower level than application frameworks
…an example of modifiable design
• Learning how to design starts by studying other designs.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Why are modifiable designs important?
A modifiable design…
…enables an iterative and incremental development
• concurrent development
• risk management
• flexibility to change
… minimizes the introduction of new problems when
fixing old ones
… allows to easily add more functionality after the
delivery of the system
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
What makes a design modifiable?
• Low coupling and high cohesion
• Clear dependencies
• Explicit assumptions
How do design patterns help?
• They are generalized from existing systems
• They provide a shared vocabulary to designers
• They provide examples of modifiable designs
• Abstract classes
• Delegation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Recall: Finding Objects
• The hardest problems in object-oriented system
development are:
• Identifying objects
• Decomposing the system into objects
• Requirements Analysis focuses on application
domain:
• Object identification
• System Design addresses both, application and
implementation domain:
• Subsystem identification
• Object Design focuses on implementation domain:
• Additional solution objects.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Recall: Techniques for Finding Objects
• Requirements Analysis
• Start with Use Cases. Identify participating objects
• Textual analysis of flow of events (find nouns, verbs, ...)
• Extract application domain objects by interviewing client
(application domain knowledge)
• Find objects by using general knowledge
• System Design
• Subsystem decomposition
• Try to identify architectural style
• Object Design
• Find additional objects by applying implementation domain
knowledge
• Try to identify design patterns.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
COMPOSITE PATTERN
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
What is common between these definitions?
• Definition Software System
• A software system consists of subsystems which are either
other subsystems or collection of classes
• Definition Software Lifecycle
• A software lifecycle consists of a set of development
activities which are either other actitivies or collection of
tasks.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
What is common between these definitions?
• Definition Software System
• A software system consists of subsystems which are either
other subsystems or collection of classes
• Composite: Subsystem (A software system consists of
subsystems which consists of subsystems, which consists of
subsystems, which...)
• Leaf node: Class
• Definition Software Lifecycle
• A software lifecycle consists of a set of development
activities which are either other actitivies or collection of
tasks
• Composite: Activity (A software lifecycle consists of
activities which consist of activities, which consist of
activities, which....)
• Leaf node: Task.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Introducing the Composite Pattern
• Tree structures that represent part-whole hierarchies
with arbitrary depth and width can be used in the
solution of many problems
• The Composite Pattern lets a client treat individual
objects and compositions of these objects uniformly
Component
Client
Operation()
Leaf
Operation()
*
Composite
Operation()
AddComponent()
RemoveComponent()
GetChildren()
Children
Modeling a Software System with a
Composite Pattern
Software
System
User
*
Class
Subsystem
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Children
26
Modeling the Software Lifecycle with a
Composite Pattern
Software
Lifecycle
Manager
*
Task
Activity
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Children
27
The Composite Patterns models Dynamic
Aggregates
Fixed Structure:
Car
*
*
Doors
Wheels
Battery
Engine
Organization Chart (variable aggregate):
*
University
*
School
Department
Dynamic tree (recursive aggregate):
Program
Composite
Pattern
*
Compound
Statement
Bernd Bruegge & Allen H. Dutoit
*
Block
Simple
Statement
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Graphic Applications use the Composite Pattern
• The Graphic Class represents
both primitives (Line, Circle) and
containers (Picture).
Graphic
Client
*
Draw()
Line
Draw()
Bernd Bruegge & Allen H. Dutoit
Circle
Draw()
Picture
Draw()
Add(Graphic g)
RemoveGraphic)
GetChild(int)
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Children
29
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
The Java‘s AWT library can be modeled with
the component pattern
Graphics
Component
*
getGraphics()
Text
Component
TextField
Bernd Bruegge & Allen H. Dutoit
Button
Label
Container
add(Component c)
paint(Graphics g)
TextArea
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Reducing the Complexity of Models
• Modeling is about communication
• To a human being as well as to a tool
• To communicate a complex model to a human being
we use navigation and reduction of complexity
• Navigate through the model so the user can follow it
• Start with a very simple model
• Identify the key abstractions
• Then decorate the model with additional classes
• To reduce the complexity of the model further
• Look for inheritance (taxonomies)
• If the model is too complex, taxonomies should be
placed in separate UML packages
• Then identify or introduce patterns in the model
• Make sure to use the name of the patterns.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Example: Modeling a Project
Equipment
Project
Facility
*
Resource
Schedule
*
Outcome
Work
Breakdown
Structure
*
*
consumes
Organization
desWork
cribes Package
*
produces
*
*
Fund
Work
depends
*
Organizational
responUnit
*
sible plays
for
Role
Set of Work
Work
Products
Product
Activity
Project
Internal
Work Product Deliverable
Bernd Bruegge & Allen H. Dutoit
Task
Participant Staff
Project Function
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Department
33
Team
How to reduce the Complexity of the Model
1. Look for the key abstractions
• Project, Outcome, Schedule, Work, Resource
2. Identify patterns: For example, the project model has 3
composite patterns
*
3. Find all the application domain taxonomies
• Start with the taxonomies for the key abstractions
4. Key abstractions, patterns and/or taxonomies are
candidates for separate UML packages.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
1. Find the Key Abstractions in the Model
Key Abstractions
Equipment
Project
Facility
*
Resource
Schedule
*
Outcome
Work
Breakdown
Structure
*
*
consumes
Organization
desWork
cribes Package
*
produces
*
*
Fund
Work
depends
*
Organizational
responUnit
*
sible plays
for
Role
Set of Work
Work
Products
Product
Activity
Project
Internal
Work Product Deliverable
Bernd Bruegge & Allen H. Dutoit
Task
Participant Staff
Project Function
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Department
35
Team
Key Abstractions in the Project Model
Project
Outcome
Bernd Bruegge & Allen H. Dutoit
Schedule
Work
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Resource
36
2. Find Patterns used in the Model
Equipment
Project
Facility
*
Resource
Composite Patterns
Schedule
*
Outcome
Work
Breakdown
Structure
*
*
consumes
Organization
desWork
cribes Package
*
produces
*
*
Fund
Work
depends
*
Organizational
responUnit
*
sible plays
for
Role
Set of Work
Work
Products
Product
Activity
Project
Internal
Work Product Deliverable
Bernd Bruegge & Allen H. Dutoit
Task
Participant Staff
Project Function
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Department
37
Team
Composite Patterns in the Project Model
Outcome
*
*
*
Set of Work
Products
Organizational
Unit
Work
Work
product
Bernd Bruegge & Allen H. Dutoit
Activity
Task
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Participant
Staff
38
3. Find the Taxonomies used in the Model
Taxonomies
Equipment
Project
Facility
*
Resource
Schedule
*
Outcome
Work
Breakdown
Structure
*
*
consumes
Organization
desWork
cribes Package
*
produces
*
*
Fund
Work
depends
*
Organizational
responUnit
*
sible plays
for
Role
Set of Work
Work
Products
Product
Activity
Project
Internal
Work Product Deliverable
Bernd Bruegge & Allen H. Dutoit
Task
Participant Staff
Project Function
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Department
39
Team
Step 4: Package based on Key Abstractions
Project
Project
Outcome
Bernd Bruegge & Allen H. Dutoit
Schedule
Work
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Resource
40
Step 4 continued:
Additional Packages based on Patterns
Work
Outcome
Organizational
Unit
Work
Outcome
*
*
*
Set of Work
Products
Organization
Work
product
Bernd Bruegge & Allen H. Dutoit
Activity
Task
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Participant
Staff
41
Step 4 continued:
Additional UML Packages based on Taxonomies
Resource
Resource
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
Summary
• Design patterns are template solutions for common
design problems such as
• separating an interface from a number of alternate
implementations
• Accessing a set of legacy classes
• protecting a caller from changes associated with specific
platforms
• A design pattern consists of a small number of classes
• uses delegation and inheritance
• provides a modifiable design solution
• These classes can be adapted and refined for the
specific system under construction
• To provide the reuse of existing solutions
• Customization of the system.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Additional Readings
• E. Gamma et.al., Design Patterns, 1994.
• M. Fowler, Analysis Patterns: Reusable Object Models, 1997
• F. Buschmann et. Al., Pattern-Oriented Software Architecture: A
System of Patterns, 1996
• T. J. Mowbray & R. C. Malveau, CORBA Design Patterns, 1997
• S. W. Ambler, Process Patterns: Building Large-Scale Systems
Using Object Technology, 1998.
• Dependency management: P. Feiler & W. Tichy, “Propagator: A
family of patterns,” in Proceedings of TOOLS-23'97, Santa
Barbara, CA, Aug, 1997.
• Configuration management: W. J. Brown et. Al., AntiPatterns and
Patterns in Software Configuration Management, 1999.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
Backup Slides
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Notation used in the Design Patterns Book
• Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides, Design Patterns: Elements of Reusable
Object-Oriented Software, Addison Wesley, 1995
• Based on OMT (a precursor to UML). Notational
differences between the OMT notation and UML:
Attributes come after the Operations
Associations are called acquaintances
Multiplicities are shown as solid circles
Dashed line: Instantiation Association (Class can instantiate
objects of associated class) (In UML it denotes a
dependency)
• UML Note is called Dog-ear box (connected by dashed line
to class operation): Pseudo-code implementation of
operation.
•
•
•
•
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53