chapter 4, object - جامعة نزوى€¦ · · 2016-04-17bernd bruegge & allen h. dutoit...
Post on 19-Apr-2018
225 Views
Preview:
TRANSCRIPT
Usi
ng
UM
L,
Pat
tern
s, a
nd J
ava
Ob
ject
-Ori
ente
d S
oft
wa
re E
ng
inee
rin
g Chapter 4, Object
Design Introduction to Design
Patterns
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
A Game: Get-15
• Start with the 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 cannot also take it.
• The first person to have any three numbers that total 15 wins the game.
• Example:
You:
Opponent:
1 5 8 3
6 9 2 7 Opponent
Wins!
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
Characteristics of Get-15
• Hard to play,
• The game is especially hard, if you are not allowed to write anything done.
• Why?
• All the numbers need to 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 number depends on all the previous numbers
• Not easy to devise an simple strategy
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
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 5
A Draw Sitation
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Strategy for determining a winning move
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
Winning Situations for Tic-Tac-Toe
Winning
Patterns
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
Tic-Tac-Toe is “Easy”
Why? Reduction of complexity through patterns and symmetries.
Patterns: Knowing the following three patterns, the player can anticipate the opponents move.
Symmetries: 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 9
Get-15 and Tic-Tac-Toe are identical problems
Any three numbers that solve the 15 problem also solve tic-tac-toe.
Any tic-tac-toe solution is also a solution the 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 10
8 1 6
3 5 7
4 9 2
1 5 8 3
6 9 2 7
You:
Opponent:
8 1 6
3 5 7
4 9 2
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
• During Object Modeling we do many transformations and changes to the object model
• It is important to make sure the object design model stays simple!
• In the next two lectures we show how to use design patterns to keep system models simple.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Modeling Heuristics
• 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 only a minimal mental effort to understand
• … reduce complexity
• Turn complex tasks into easy ones (by good choice of representation)
• Use of symmetries
• … use abstractions
• taxonomies
• … 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 13
Outline of the Lecture
• Design Patterns
• Usefulness of design patterns
• Design Pattern Categories
• 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
• Patterns covered in the next lecture
• Abstract Factory
• Proxy
• Command
• Observer
• Strategy
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
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 15
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 layers and partitions
• Object Design
• Find additional objects by applying implementation domain knowledge
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
Another Source for Finding Objects : Design Patterns
• What are Design Patterns?
• A design pattern describes a problem which occurs over and over again in our environment
• Then it describes the core of the solution to that problem, in such a way that you can use the this solution a million times over, without ever doing it the same twice
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
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:
• The 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 18
Introducing the Composite Pattern
• Models tree structures that represent part-whole hierarchies with arbitrary depth and width.
• The Composite Pattern lets client treat individual objects and compositions of these objects uniformly
Client Component
Leaf
Operation()
Composite
Operation()
AddComponent
RemoveComponent()
GetChild()
Children
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
What is common between these definitions?
• Software System:
• Definition: 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
• Software Lifecycle:
• Definition: The software lifecycle consists of a set of development activities which are either other actitivies or collection of tasks
• Composite: Activity (The 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 20
Modeling a Software System������ with a Composite Pattern
Software System
Class
Subsystem
Children
* User
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
Modeling the Software Lifecycle with a Composite Pattern
Software Lifecycle
Task
Activity
Children
* Manager
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
The Composite Patterns models dynamic aggregates
University School Department
Organization Chart (variable aggregate):
Dynamic tree (recursive aggregate):
Car Fixed Structure:
Doors Wheels Battery Engine
Compound Statement
Simple Statement
Program
Block
* *
* *
* *
Dynamic tree (recursive aggregate):
Composite
Pattern
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
Graphic Applications also use Composite Patterns
Client Graphic
Circle
Draw()
Picture
Draw()
Add(Graphic g)
RemoveGraphic)
GetChild(int)
Children Line
Draw()
• The Graphic Class represents
both primitives (Line, Circle) and
their containers (Picture)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
Reducing the Complexity of Models
• To communicate a complex model we use navigation and reduction of complexity
• We do not simply use a picture from the CASE tool and dump it in front of the user
• The key is navigate through the model so the user can follow it
• We start with a very simple model
• Start with the key abstractions
• Then decorate the model with additional classes
• To reduce the complexity of the model further, we
• Look for inheritance (taxonomies)
• If the model is still too complex, we show subclasses on a separate slide
• Then we identify or introduce patterns in the model
• We make sure to use the name of the patterns.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
*
Resource
Participant
Fund
Equipment
Schedule
Task
*
Activity
con-
Facility
*
Staff
Department Team
produces
Work Set of Work
*
ProductProducts
*
Internal Project
Work
respon-
sumes
Package
Role
*
des-
*
cribes
Deliverable
sibleplays
for
Organi-zation
Structure
**
depends
Work ProductProject Function
Project
Outcome WorkOrganizational
Unit
Work Breakdown
Example: A Complex Model
Composite Patterns
Taxonomies Basic Abstractions
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
What is this?
1.Nf3 d5 2.c4 c6 3.b3 Bf5 4.g3 Nf6 5.Bg2 Nbd7 6.Bb2 e6 7.O-
O Bd6 8.d3 O-O 9.Nbd2 e5 10.cxd5 cxd5 11.Rc1 Qe7
12.Rc2 a5 13.a4 h6 14.Qa1 Rfe8 15.Rfc1
This is a fianchetto!
The fianchetto is one of the basic building-blocks of chess
thinking.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
What is a Design Pattern
• A Design Pattern systematically names, explains, and implements an important recurring design.
• These define well-engineered design solutions that practitioners can apply when crafting their applications.
28
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
Why Design Patterns?
• Good designers do not solve every problem from first principles. They reuse solutions.
• Practitioners do not do a good job of recording experience in software design for others to use. Patterns help solve this problem.
29
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
Four Example Patterns
1. MVC (Model View Controller)
2. Adapter
3. Facade
4. Factory
30
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
1. MVC Pattern
(Model View Controller)
• There is a model (subject) which can be thought of as the application
• There are one or more views of the object (by observers)
• There is a controller that mediates between the model and the view(s).
31
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
Example MVC
a b c a
b c
[Mancoridis picture]
Views
Controller
Model a b c
50 30 20
a = 50% b = 30% c = 20%
32
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
Example MVC
a b c a
b c
[Mancoridis picture]
Views
Controller
Model a b c
50 30 20
a = 50% b = 30% c = 20%
See
Interact
33
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
Multiple View Problem
• Need to keep all the views consistent
• If user (or one of users) changes a view, all other views should be updated
34
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Information Hiding: Insulating Model from Presentation
• The model is the “back end” or “business logic”, or “application”
• To minimize complexity, the model should know as little as possible about
• How users interact with system
• How many users are there
• Any other models
35
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
Implementing MVC
• There are many choices
• Where is list of views (observers) kept?
• How is notification of change transmitted?
• How manage web interface?
• Should a view ask for (or should it be told of) details about changes?
36
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
What Kind of Pattern is MVC?
• Design pattern proper?
• Use it for structuring modest configurations
• Architectural pattern?
• Use it for overall structure of a software system, defining interactions among services, browsers etc.
37
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
2. Adapter Pattern
• You have an existing client (application) that uses an old interface to an existing support package.
• You are given a new interface to a new support package
• You need to produce an adapter so that:
• The client can use the new interface instead of the old one (without changing the client)
38
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
Illustration of Adapter Pattern
Client Old
package
Old
interface
Client Adapter
Old
interface
New
package
New
interface
39
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40
Implementing Adapter Pattern Using Object Composition
Client Old Interface
Request()
New Interface
SpecificRequest()
Adapter
Request() SpecificRequest()
adaptee inherit
40
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41
Advantages of Adapter Pattern
• Can change behavior of existing software without changing its source code
• Can be used for legacy software
• Do not need access to old source code
41
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42
3. Facade Pattern
• A facade provides a single simplified interface to a larger part of the system (a subsystem)
• The facade makes this subsystem more readable and easier to understand
• Having facades minimizes communication and dependencies between subsystems
42
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43
Structure of the Facade Pattern
43
Subsystem
Classes
Facade
[Mancoridis picture]
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44
Adapter vs. Facade
• An Adapter is used when the wrapper must respect a particular interface and must support a polymorphic behavior. On the other hand, a facade is used when one wants an easier or simpler interface to work with
44
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45
4. Factory Pattern
• A creational pattern dealing with creating objects without knowing their concrete class
• It defines an interface for creating an object, but let the subclasses decide which class to instantiate
• Useful when concrete class of object should be decided at runtime according to parameters
45
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46
How does it work
46
<abstract>
Product
<Implementation Class>
ProductA <Implementation Class>
ProductB
<static> ProductFactory
createProduct(in param) : Product
Produces different subclasses of Product according to parameters
inherits
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47
Summary II
• Composite Pattern:
• Models trees with dynamic width and dynamic depth
• Facade Pattern:
• Interface to a subsystem
• Distinguish between closed vs open architecture
• Adapter Pattern:
• Interface to reality
top related