Object Oriented Analysis and Design: Instructor: Muhammad Ahmed MR Atif Jilani: OO Design Date: 29 October 2010

FAST National University of Computer and Emerging Sciences
Islamabad, Pakistan 1
OBJECT ORIENTED
ANALYSIS AND DESIGN
Instructor : Muhammad Ahmed
Mr Atif Jilani
FALL 2010 Lecture : OO Design
Date : 29th October 2010
Contents
2
 Introduction to Design Phase

 Static vs. Dynamic Design Modelling
 Interaction Diagrams
 Design Class Diagrams
OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

DESIGN PHASE
OOAD
Fall 2010
Design Phase
4
Real Usecases
Design Class
Use Case Diagrams
Model
Deployment
Diagrams
4

DESIGN PHASE: REAL

UCS
OOAD
Fall 2010
REAL USE CASES: Touching the
6
HOW part
 Real/Actual Design in terms of concrete I/O and its
implementation
 Only Storyboards (rough UI widgets required,
implementation later)
Window-1
Real Buy Items-Version 1 Object Store
Use cases: Buy Items with Cash UPC A Quantity E
Actors: Customers (initiator), Cashiers Price

B Desc F
Purpose: Capture a sale and its cash payment. Total C Balance G
Overview: A Customer arrives at a checkout with items Tendered D

to purchase. The cashier records the purchase Enter Item End Sale Make Payment
items and collects a cash payment. H I J
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,

Typical Course of Events
Window-1
7
Object Store
UPC A Quantity E
B F
Actor Action Price
Desc
Total C Balance G
1. This use case begins when Customer Tendered D
arrives at the POST checkout with Enter Item End Sale Make Payment
items to purchase. H I J
2. For each item, the Cashier types in System Response

the Universal Product Code (UPC) 3. adds the item information
in A of Window-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 of Window-1.
Cashier indicates to the POST that item
entry is complete by pressing. 5. Calculates and presents the
widget-I. sale total C.

ONTO OBJECT DESIGN

OOAD
Fall 2010
Read Chapter 14 Craig Larman
Designing Objects: What are Static and Dynamic Modeling?
9

Dynamic Object Modeling
10
 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

Static Object Modeling
11
 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 will
be drawing both interaction and class diagrams
concurrently
 Other support in the UML for static modeling includes
 package diagrams
 deployment diagrams
11

Summary
12
12

DYNAMIC OBJECT
MODELLING
OOAD UML Interaction Diagrams
Fall 2010 Chapter 15 Craig Larman
Dynamic Object Modeling
14
 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

Object Interaction: Message Passing
15
sender object
attributes:
receiver object
attributes:
operations:
operations:
message:
[sender, return value(s)]
message: [receiver, operation, parameters]

15

Interaction Diagram
16
 Interaction diagram is a generalization of two more

specialized 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

Sequence diagrams
17
 Sequence diagrams illustrate interactions in a kind

of fence format, in which each new object is added
to the right
public class A
{
private B myB = new
B();
public void doOne()
{
myB.doTwo();
myB.doThree();
}
// …
}
17

Communication/ Collaboration
18
diagrams
 Communication diagrams
 illustrate object interactions in a graph or network
format,
 objects can be placed anywhere on the diagram
18

Communication diagrams
19
1: message2()
message1() 2: message3()
:ClassAInstance :ClassBInstance
Sequence Diagrams
:ClassAInstance :ClassBInstance
message1()
message2()
message3()
19

Strengths and Weaknesses of Sequence vs. Communication
Diagrams?
20
Type Strengths Weaknesses

Sequence Clearly shows sequence or time Forced to extend to the right
ordering of messages when adding new objects;
Large set of detailed notation consumes horizontal space
options
Communicati Space economical Flexibility to add More difficult to see sequence of
on new objects in two dimensions messages
Fewer notation options
20

Guideline
21
 Spend time doing dynamic object modeling with

interaction diagrams, not just static object modeling
with class diagrams.
21

Interaction Diagrams
22
 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

BASIC
COMMUNICATION
DIAGRAM NOTATION
OOAD
Fall 2010
Illustrating Classes and
24 Instances
 For any kind of UML element (class, actor, …) an
instance uses the same graphic symbol as the type,
but the designator string is underlined.
Sale :Sale s1: Sale
class instance named instance
24

Illustrating Links*
25
 A link is a connection path between two objects; it indicates some form of navigation and
visibility between the objects is possible.
 More formally, a link is an instance of an association.
msg1()
:POST 1: addPayment(cashTendered) :Sale
link line
 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
allowing two-way message traffic.
25

Messages
26
Each message between objects is represented with a message expression and small
arrow indicating the direction of the message.
First message Message sequence #

not msg1() 1: message2()
numbered 2: message3()
3: message4()
:POST :Sale
all messages flow on the same link
26

Illustrating Parameters
27
parameters
msg1()
1: addPayment(amount: Money)
:POST :Sale
27

Illustrating Return Value
28
return value type
msg1(
)
1: tot := total(): Integer
:POST :Sale
return value name
28

Message Syntax
29
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)
msg1()
1: addPayment(cashTendered)
:POST :Sale
standard UML
message syntax
29

Illustrating Iteration
30
Indicated by an “*” after the sequence No.

iteration
recurrence values
omitted
msg1()
1*: li := nextLineItem(): SalesLineItem

:POST :Sale
iteration clause
recurrence values
msg1()
1*: [i := 1..10] li := nextLineItem(): SalesLineItem

:POST :Sale
30

And the implementation touch
31 …
msg1()
{
for i := 1 to 10
{
myB.msg2()
myC.msg3()
}
}
msg1()
1*: [i := 1..10] msg2()

:A myB :B
2*: [i := 1..10] msg3()

myC :C
note that iteration

clauses are equal
31

Illustrating Creation of Instances
32
create message, with
optional initializing
parameters
msg1()
1: create(cashier)
:POST :Sale
new created instance
«new»
:Sale
"«new»" is optionally
allowed for emphasis
32

Message number sequencing
33
 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 number
to the outgoing message number.
not numbered
2: msg5()
msg1() 1: msg2()
:ClassA :ClassB
1.1: msg3() 1.2: msg4()

2.1: msg6()
legal numbering
:ClassC
33

Exercise
34
first second
third
msg1() ;ClassA 1: msg2() :ClassB
1.1: msg3()
2.1: msg5()
2: msg4() :ClassC
fourth fifth
2.2: msg6()
sixth
:ClassD
Exercise: Write down the codes for all methods shown in the diagram
34

Conditional Messages
35
conditional message, with test
msg1()
1: [new sale] create()

:POST :Sale
1.1: create()
:SalesLineItem
35

Mutually Exclusive Conditional
36
Paths
unconditional after
either msg2 or msg4 :ClassE 1a and 1b are mutually
exclusive conditional paths
2: msg6()
1a: [test1] msg2()

msg1() :ClassA :ClassB
1b: [not test1] msg4() 1a.1: msg3()
:ClassD 1b.1: msg5() :ClassC
36

Collections of objects
37
Sale multiobject
sales : Sale
Messages to Multiobjects
message sent to the

collection object itself
msg1()
1: s := size() : int SalesLineItem

:Sale :SalesLineItem
37

Message to Multiobject and an element
38
msg1()
:Sale 1: create() sl: SalesLineItem
2: addElement(sl) SalesLineItem
:SalesLineItem
msg1()
2: print()
:Sale sl: SalesLineItem
1: sl := get(key) SalesLineItem
:SalesLineItem
38

Message to Class
39
message to class
msg1()
1: d1 := today(): Date
:Sale Date
not underlined,
therefore a class
39

BASIC SEQUENCE
DIAGRAM NOTATION
OOAD
Fall 2010
Illustrating Participants with Lifeline Boxes
41
41

Basic Message Expression
42 Syntax
 Interaction diagrams show messages between objects; the
UML has a standard syntax for these message expressions
 return = message(parameter : parameterType) : returnType

Parentheses are usually excluded if there are no parameters,
though still legal.
 Type information may be excluded if obvious or
unimportant.
 For example:
 initialize(code) initialize d = getProductDescription(id) d =
getProductDescription(id:ItemID) d =
getProductDescription(id:ItemID) : ProductDescription
42

Two ways to show a return result from a
message
43
43

Messages to "self" or "this"
44
 Messages to "self" or "this"

 A message can be sent from an object to itself. This
is illustrated by a link to itself, with messages
flowing along the link.
44

Diagram Frames in UML Sequence
Diagrams
45
 To support conditional and looping constructs (among many

other things), the UML uses frames. Frames are regions or
fragments of the diagrams; they have an operator or label
(such as loop) and a guard (conditional clause).
45

Frame Operator
46
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

Creation of Instances
47
Note that newly created
:Register :Sale objects are placed at their
creation “height”
makePayment(cashTendered) Create (cashTendered)
:Payment
Authorize()
An object lifeline (vertical dashed lines

underneath the objects)
47

Object Lifelines and Object Destruction
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.
:Sale
The “destroy”
stereotyped message,
Create(cashTendered) with the large X and
:Payment short lifeline indicates
explicit object
... destruction
“destroy”
Object destruction
48

Conditional Messages
49
 An OPT frame is placed around one or more

messages. Notice that the guard is placed over the
related lifeline
49

Mutually Exclusive Conditional
50
Messages
An ALT frame is placed around the mutually exclusive alternatives
50

Nesting of Frames
51
 Frames can be nested
51

Object Oriented Analysis and Design: Instructor: Muhammad Ahmed MR Atif Jilani: OO Design Date: 29 October 2010

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented Analysis and Design: Instructor: Muhammad Ahmed MR Atif Jilani: OO Design Date: 29 October 2010

Uploaded by

Copyright:

Available Formats

FAST National University of Computer and Emerging Sciences

 Introduction to Design Phase

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

DESIGN PHASE: REAL

Use cases: Buy Items with Cash UPC A Quantity E

Actors: Customers (initiator), Cashiers Price

Purpose: Capture a sale and its cash payment. Total C Balance G

Overview: A Customer arrives at a checkout with items Tendered D

On completion, the customer leaves with the

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

1. This use case begins when Customer Tendered D

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

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

ONTO OBJECT DESIGN

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 The most common static object modeling is with UML

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 The UML includes interaction diagrams to

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

message: [receiver, operation, parameters]

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 Interaction diagram is a generalization of two more

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 Sequence diagrams illustrate interactions in a kind

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

Type Strengths Weaknesses

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 Spend time doing dynamic object modeling with

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

 Interaction Diagrams are a Valuable Artifact

 Activities and dependencies

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

Sale :Sale s1: Sale

class instance named instance

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

:POST 1: addPayment(cashTendered) :Sale

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

First message Message sequence #

all messages flow on the same link

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

return value type

return value name

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

UML standard recommended to keep design independent of any language syntax:

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

Indicated by an “*” after the sequence No.

1*: li := nextLineItem(): SalesLineItem

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

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

1*: [i := 1..10] msg2()

2*: [i := 1..10] msg3()

note that iteration

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

new created instance

OOAD, Fall 2010 © Dr. Muhammad Ahmed and Atif Jilani

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

1.1: msg3() 1.2: msg4()