09-OODesign-OBJECT ORIENTED ANALYSIS AND DESIGN

8/7/2019 09-OODesign-OBJECT ORIENTED ANALYSIS AND DESIGN

1/51

FALL 2010

FAST National University of Computer and Emerging Sciences

Islamabad, Pakistan

OBJECT ORIENTEDANALYSIS AND DESIGN

Instructor : Muhammad AhmedMr Atif Jilani

Lecture : OO Design

Date : 29th October 2010

1


2/51

2

OOAD, Fall 2010 Dr. Muhammad Ahmed and Atif Jilani

Contents

Introduction to Design Phase

Static vs. Dynamic Design Modelling

Interaction Diagrams Design Class Diagrams

2


3/51

OOAD

Fall 2010


Islamabad, Pakistan

DESIGN PHASE

3


4/51

4


Design Phase

Use Case Model

Real Usecases

Interaction Diagrams

SequenceDiagrams

CommunicationDiagrams

Design Class

Diagrams

Use Case Model

SupplementarySpecifications

Domain Model

Grasp

Logical Architecture

System Contracts

Object OrientedDesign

Deployment

Diagrams

4


5/51

OOAD

Fall 2010


Islamabad, Pakistan

DESIGN PHASE: REAL UCS

5


6/51

6


Real/Actual Design in terms of concrete I/O and its

implementation

Only Storyboards (rough UI widgets required, implementation

later)

Use cases: Buy Items with Cash

Actors: Customers (initiator), Cashiers

Purpose: Capture a sale and its cash payment.

Overview: A Customer arrives at a checkout with items

to purchase. The cashier records the purchase

items and collects a cash payment.On completion, the customer leaves with the

items.

Type: primary and real

Cross Reference: Functions: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1,

Real Buy Items-Version 1 Object Store

Enter I te m End Sale

UPC

Make Payment

Total

Quantity

Tendered

Balance

A

C

E

G

H I J

PriceDescB

D

F

Window-1

REAL USE CASES: Touching the HOW part6


7/51

7


Actor Action

1. This use case begins when Customer

arrives at the POST checkout with

items to purchase.2. For each item, the Cashier types in System Response

the Universal Product Code (UPC) 3. adds the item information

in A ofWindow-1. to the running sales transaction.

If there is more than one of an item,

the quantity may optionally be entered

in E. Then press H after each item entry. The description and price of the

current item are presented in B.

4. On completion of item entry, the and F ofWindow-1.

Cashier indicates to the POST that item

entry is complete by pressing. 5. Calculates and presents the

widget-I. sale total C.

Object Store

Enter It em End Sa le

UPC

Make Payment

Total

Quantity

Tendered

Balance

A

C

E

G

H I J

PriceDescB

D

F

Window-1Typical Course of Events

7


8/51

OOAD

Fall 2010


Islamabad, Pakistan

ONTO OBJECT DESIGN

Read Chapter 14 Craig Larman

8


9/51

9


Designing Objects: What are Static and Dynamic Modeling?

Two kinds of object models

Dynamic Object models

such as UML interactiondiagrams (sequence diagramsor communication diagrams)

how objects interact viamessages

Help design the logic, the

behavior of the code or themethod bodies

The more interesting, difficult,important diagrams to create.

Static models,

such as UML class diagrams

Help design the definition ofpackages, class names,attributes, and method

signatures (but not methodbodies)

9


10/51

10


Dynamic Object Modeling

People new to UML tend to think that the important diagram is the static-

view class diagram, but in fact, most of the challenging, interesting, useful

design work happens while drawing the UML dynamic-view interaction

diagrams.

It's during dynamic object modeling (such as drawing sequence diagrams)that "the rubber hits the road

in terms of really thinking through the exact details of what objects need to exist

how they collaborate via messages and methods

During dynamic modeling that we apply responsibility-driven design and

the GRASP principles.

Other dynamic tools in the UML kit

state machine diagrams

activity diagrams

10


11/51

11


Static Object Modeling

The most common static object modeling is with UML

class diagrams.

If the developers are applying the agile modeling

practice of Create several models in parallel, they willbe drawing both interaction and class diagrams

concurrently

Other support in the UML for static modeling includes

package diagrams

deployment diagrams

11


12/51

12


Summary

Object Design

Dynamic Object Models

InteractionDiagrams

Communication Diagrams

SequenceDiagrams

Others

ActivityDiagrams

StateTransitionDiagrams

Static ObjectModels

ClassDiagrams

PackageDiagrams

DeploymentDiagrams

12


13/51

OOAD

Fall 2010


Islamabad, Pakistan

DYNAMIC OBJECTMODELLINGUML Interaction Diagrams

Chapter 15 Craig Larman

13


14/51

14


Dynamic Object Modeling

The UML includes interaction diagrams to illustrate

how objects interact via messages.

They are used for dynamic object modeling.

Static OO design will be presented as Class

Diagram.

14


15/51

15


Object Interaction: Message Passing

sender object

attributes:

operations:

receiver object

attributes:

operations:

message: [receiver, operation, parameters]

message:[sender, return value(s)]

15


16/51

16


Interaction Diagram

Interaction diagram is a generalization of two morespecialized UML diagram types: sequence diagrams

Communication/collaboration diagrams

Both can express similar interactions

A related diagram is the interaction overview diagram; it provides a big-picture overview of how a set of

interaction diagrams are related in terms of logic and

process-flow. It's new to UML 2, and so too early to tell if it will be

practically useful.

16


17/51

17


Sequence diagrams

Sequence diagrams illustrate interactions in a kind

of fence format, in which each new object is added

to the rightpublic class A{

private B myB = new

B();

public void doOne()

{

myB.doTwo();

myB.doThree();}

//

}

17


18/51

18


Communication/ Collaboration diagrams

Communication diagrams

illustrate object interactions in a graph or network

format,

objects can be placed anywhere on the diagram

18


19/51

19


:ClassAInstance :ClassBInstance

essage2()

essage3()

essage1()

:ClassAInstance :ClassBInstance

1: essage2()

2: essage3()essage1()

Sequence Diagrams

Communication diagrams19


20/51

20


Strengths and Weaknesses of Sequence vs. Communication

Diagrams?

Type Strengths Weaknesses

Sequence Clearly shows sequence or time

ordering of messages

Large set of detailed notationoptions

Forced to extend to the right

when adding new objects;

consumes horizontal space

Communicatio

n

Space economical Flexibility to add

new objects in two dimensions

More difficult to see sequence of

messages

Fewer notation options

20


21/51

21


Guideline

Spend time doing dynamic object modeling with

interaction diagrams, not just static object modeling

with class diagrams.

21


22/51

22


Interaction Diagrams

Interaction Diagrams are a Valuable Artifact

Interaction diagrams are most important artifacts created in OOAD

The amount of time and effort spent on their generation should absorb

a significant percentage of the overall project effort.

Codified patterns, principals, and idioms can be applied to improve the

quality of their design.

Activities and dependencies From domain model-- may choose concepts as software classes. Objects of these classes

participate in interactions (in interaction diagrams).

System operation contract-- identifies the responsibilities and post-conditions that interaction

diagrams must fulfill.

Real (or essential) use cases -- information about what tasks the interaction diagrams fulfill, in

addition to what is in the contracts.

22


23/51

OOAD

Fall 2010


Islamabad, Pakistan

BASIC COMMUNICATIONDIAGRAM NOTATION

23


24/51


25/51

25


A link is a connection path between two objects; it indicates some form of navigation andvisibility between the objects is possible.

More formally, a link is an instance of an association.

Note

Note that multiple messages and both ways, flow along the same single link.

There isn't one link line per message; all messages flow on the same line, which is like a road allowingtwo-way message traffic.

1: addPay ent(cashTendered):POST :Sale

sg1()

link line

Illustrating Links*25


26/51

26


Each message between objects is represented with a message expression and small

arrow indicating the direction of the message.

1: message2()

2: message3()

3: message4():POST :Sale

msg1()

all messages flow on the same link

Message sequence #First message

not numbered

Messages26


27/51

27


Illustrating Parameters

1: addPayment(amount: Money):POST :Sale

msg1()

parameters

27


28/51

28


1: tot := total(): Integer

:POST :Sale

sg1()

return value type

return value na

e

Illustrating Return Value28


29/51

29


Message Syntax

1: addPayment(cashTendered):POST :Sale

msg1()

standard UMLmessage syntax

UML standard recommended to keep design independent of any language syntax:return := message (parameter: parameterType): return type

However little variation is acceptable (as in diagram)

29


30/51

30


1*: li := nextLineItem(): SalesLineItem:POST :Sale

msg1()

iterationrecurrence valuesomitted

1*: [i := 1..10] li := nextLineItem(): SalesLineItem:POST :Sale

msg1()

iteration clause

recurrence values

Indicated by an * after the sequence No.

Illustrating Iteration30


31/51


32/51


33/51

33


:ClassAmsg1()

:ClassB1: msg2()

:ClassC

1.1: msg3()

not numbered

legal numbering

1.2: msg4()

2: msg5()

2.1: msg6()

Message number sequencing

1. First message is not numbered; thus, msg1() is unnumbered.

2. Order and nesting of subsequent message by catenation.Nesting is denoted by prepending the incoming message numberto the outgoing message number.

33


34/51

34


;ClassAmsg1() :ClassB1: msg2()

:ClassC

1.1: msg3()

2.1: msg5()

2: msg4()

:ClassD

2.2: msg6()

first second

fourth

sixth

fifth

third

Exercise:Write down the codes for all methods shown in the diagram

Exercise34


35/51

35


1: [new sale] create():POST :Sale

:SalesLineItem

1.1: create()

msg1()

conditional message, with test

Conditional Messages35


36/51


37/51

37


Salsal s : Sal

multiobject

Messages toMultiobjects

1: s := size() : int:Sale

SalesLineItem:SalesLineItem

msg1()

message sent to the

collection object itself

Collections of objects37


38/51


39/51

39


1: 1 : t ay(): at:Sal at

msg1()

not underlined,

therefore a class

message to class

Message to Class

39


40/51

OOAD

Fall 2010


Islamabad, Pakistan

BASIC SEQUENCEDIAGRAM NOTATION

40


41/51

41


Illustrating Participants with Lifeline Boxes

41


42/51

42


Basic Message Expression Syntax

Interaction diagrams show messages between objects; theUML has a standard syntax for these message expressions

return = message(parameter : parameterType) : returnType

Parentheses are usually excluded if there are noparameters, though still legal.

Type information may be excluded if obvious orunimportant.

For example: initialize(code) initialize d = getProductDescription(id) d =

getProductDescription(id:ItemID) d =getProductDescription(id:ItemID) : ProductDescription

42


43/51

43


Two ways to show a return result from a

message43


44/51


45/51


46/51

46


Frame Operator

Frame

Operator Meaning

alt Alternative fragment for mutual exclusion conditional logic

expressed in the guards.

loop Loop fragment while guard is true. Can also write loop(n) to

indicate looping n times. There is discussion that the

specification will be enhanced to define a FOR loop, such as

loop (i, 1, 10)

opt Optional fragment that executes if guard is true.

par Parallel fragments that execute in parallel.

region Critical region within which only one thread can run.

46


47/51

47


An object lifeline (vertical dashed lines

underneath the objects)

:Register

:Payment

makePayment(cashTendered)

:Sale

Create (cashTendered)

Authorize()

Note that newly created

objects are placed at their

creation height

Creation of Instances

47


48/51

48


In some circumstances it is desirable to show explicit destruction of an object (as in C++, which

does not have garbage collection); the UML lifeline notation provides a way to express this

destruction.

Object destruction

:Payment

:Sale

The destroy

stereotyped message,

with the large X and

short lifeline indicates

explicit object destruction

Create(cashTendered)

destroy

. . .

Object Lifelines and Object Destruction

48


49/51


50/51

50


An ALT frame is placed around the mutually exclusive alternatives

Mutually Exclusive Conditional Messages50


51/51

51

OOAD Fall 2010 Dr Muhammad Ahmed and Atif Jilani

Nesting of Frames

Frames can be nested

51

Documents

09-OODesign-OBJECT ORIENTED ANALYSIS AND DESIGN