Chapter 4, Object - جامعة نزوى€¦ · · 2016-04-17Bernd Bruegge & Allen H. Dutoit...

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!


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


Another Game: Tic-Tac-Toe

Source: http://boulter.com/ttt/index.cgi

http://boulter.com/ttt/index.cgi


A Draw Sitation


Strategy for determining a winning move


Winning Situations for Tic-Tac-Toe

Winning

Patterns


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.


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


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


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


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


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


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


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


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


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


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


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.


Modeling a Software System�� with a Composite Pattern

Software System

Class

Subsystem

Children

* User


Modeling the Software Lifecycle with a Composite Pattern

Software Lifecycle

Task

Activity

Children

* Manager


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


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)


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.


*

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


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.


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


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


Four Example Patterns

1. MVC (Model View Controller)

2. Adapter

3. Facade

4. Factory

30


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


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


Example MVC

a b c a

b c


Views

Controller

Model a b c

50 30 20

a = 50% b = 30% c = 20%

See

Interact

33


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


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


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


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


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


Illustration of Adapter Pattern

Client Old

package

Old

interface

Client Adapter

Old

interface

New

package

New

interface

39


Implementing Adapter Pattern Using Object Composition

Client Old Interface

Request()

New Interface

SpecificRequest()

Adapter

Request() SpecificRequest()

adaptee inherit

40


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


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


Structure of the Facade Pattern

43

Subsystem

Classes

Facade



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


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


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


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

Chapter 4, Object - جامعة نزوى€¦ · · 2016-04-17Bernd Bruegge & Allen H. Dutoit...

Documents

Transcript of Chapter 4, Object - جامعة نزوى€¦ · · 2016-04-17Bernd Bruegge & Allen H. Dutoit...