1

On To Object Design

Chapter 14

Applying UML and Patterns

-Craig Larman

2

Connection between SSDs, System Operations and Layers

In a well-designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward the request from the UI layer onto the domain layer for handling.

How design objects?

Code : Design while coding

Draw , then code : UML on a

whiteboard , then switch to code

Only draw: tools generate

everything from diagrams.

3

WSEP 06

Designing ObjectsStatic and dynamic modeling.

Two kinds of object models:

• Static models :• Class diagrams / Package diagram / Deployment diagram

Helps design definition of packages, class name, attributtes and method signature

• Dynamic models:• Interaction Diagrams/ (Sequence / comunication). State machine

diagrams/activity diagram

Illustrate how objects collaborate via messages and methdos . They help design the logic and method bodies

5

Agile modeling practice Create Models in parallel! ( interaction diagram and class diagram)Modeling with others

6

UML INTERACTION DIAGRAMS

Chapter 15

Applying UML and Patterns

-Craig Larman

Sequence Diagrams 7

A First Look at interaction Diagrams

Illustrate how objects interacts with each other.

Emphasizes time ordering of messages.

Can model simple sequential flow, branching, iteration (loop) , …etc

Sequence / communication

sequence diagram

: A myB : B

doTwo

doOne

doThree

Each new object is added to the right

Method of Object A

Class A has an attribute of type B to be able to call doTwo and doThree.

Methods of Object B

Code

public class A{ private B myB= new B();

Public void doOne(){ myB.doTwo();myB.doThree();}

}

Class A has an attribute of type B.

Class A has a method named doOne

Class B has methods named doTwo and doThree

Communication diagram

: A

myB : B

1: doTwo

2: doThree

doOne

Interaction Diagram notation

class instance named instance

:Sale s1:SaleSale

sales: ArrayList<Sale>

:Sale s1 : Sale

lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects

lifeline box representing an unnamed instance of class Sale

lifeline box representing a named instance

sales[ i ] : Sale

lifeline box representing one instance of class Sale, selected from the salesArrayList <Sale> collection

x : List

«metaclass»Font

lifeline box representing the class Font, or more precisely, that Font is an instance of class Class – an instance of a metaclass

related example

List is an interface

in UML 1.x we could not use an interface here, but in UML 2, this (or an abstract class) is legal

Common UML Interraction diagram notation

lifeline

Basic Sequence diagram notation

: Register : Sale

doA

doB

doX

doC

doD

typical sychronous message shown with a filled-arrow line

a found message whose sender will not be specified

execution specification bar indicates focus of control

How to illustrate a return result ?

: Register : Sale

d1 = getDate

getDate

doX

aDate

Is equivalent to

Messages sent to itself

: Register

doX

clear

Creation of Instances

: Register : Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

authorize

note that newly created objects are placed at their creation "height"

Dashed line

Sale class will invoke the new operator and call the constructor.

Object destruction

: Sale

: Paymentcreate(cashTendered)

...the «destroy» stereotyped message, with the large X and short lifeline indicates explicit object destruction

«destroy» X

Conditional message : OPT frame is placed around one or more messages.

calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

opt: Optional fragment that execute if guard [color=red] is true

Conditional message : UML1.x notation

[ color = red ] calculate

: Bar

yy

xx

: Foo

which notation do you prefer?

calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

[ color = red ] calculate

: Bar

yy

xx

: Foo

Loops (iteration over a collection)

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

[ i < lineItems.size ]loop

: Sale This lifeline box represents one instance from a collection of many SalesLineItem objects.

lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value refers to the same “i” in the guard in the LOOP frame

an action box may contain arbitrary language statements (in this case, incrementing ‘i’)

it is placed over the lifeline to which it applies

i++

Code page 234

22

Loops (iteration over a collection)

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

loop

: Sale

Which notation do you prefer

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

[ i < lineItems.size ]loop

: Sale This lifeline box represents one instance from a collection of many SalesLineItem objects.

lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value refers to the same “i” in the guard in the LOOP frame

an action box may contain arbitrary language statements (in this case, incrementing ‘i’)

it is placed over the lifeline to which it applies

i++

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

loop

: Sale

Nesting of frames

25

How relate Interaction diagram?

26

Invoke static (class)methods

27

Polymorphism in interaction diagrams?

28

UP artifacts influencing OO design

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

d = getProductDescription(itemID)

addLineItem( d, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

SupplementarySpecification

Glossary

starting events to design for, and detailed post-condition to satisfy

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.

inspiration for names of some software domain objects

functional requirements that must be realized by the objects

ideas for the post-conditions

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductDescription(...)...

1*

non-functional requirements

domain rules

item details, formats, validation

Questions?

30

aMember: BookBorrower

theLibraryMember:LibraryMember

theCopy: Copy theBook: Book

borrow (theCopy)1: okToBorrow

2: borrow2.1:borrowed

Can you guess the scenario from this interaction diagram ?

Collaboration diagram: Library System

BookBorrower

borrow()

2:borrow()

1:okToBorrow()

2.1: borrowed()

:LibraryMember theCopy:Copy

:Book