object interaction modeling yonglei tao sequence diagrams 2

Object Interaction Modeling

Yonglei Tao

2

Sequence Diagrams

: 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

3

Return Values

: Register : Sale

d1 = getDate

getDate

doX

aDate

4

Conditional Messages

[ color = red ] calculate

: Bar

yy

xx

: Foo

5

Conditional Messages

calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

6

Conditional Messages

: B: A

calculate

doX

: C

calculate

[ x < 10 ]alt

[ else ]

7

Iterations

enterItem(itemID, quantity)

: B

endSale

a UML loop frame, with a boolean guard expression description, total

makeNewSale

[ more items ]loop

: A

8

Communication Diagrams

: Amsg1 : B1: msg2

: C

1.1: msg3not numbered

legal numbering

9

Conditional Messages

1 [ color = red ] : calculate: Foo : Bar

message1

conditional message, with test

10

Conditional Paths

1a [test1] : msg2

: A : B

: C

1a.1: msg3

msg1

: D

1b [not test1] : msg4

1b.1: msg5

: E

2: msg6

unconditional after either msg2 or msg4 1a and 1b are mutually

exclusive conditional paths

11

Iterations

1 * [i = 1..n]: st = getSubtotal: Salet = getTotal

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 comes from the message clause.

lineItems[i]:SalesLineItem

this iteration and recurrence clause indicates we are looping across each element of the lineItems collection.

1 *: st = getSubtotal: Salet = getTotal lineItems[i]:SalesLineItem

Less precise, but usually good enough to imply iteration across the collection members

12

Communication Diagrams

A Case Study – Point Of Sale POS System

computerized application typically used to record sales and handle payments in a retail store

includes also hardware, e.g., bar code scanner interfaces with various service applications,

e.g., third-party tax calculator and inventory control

Iterative development cycles 1 - some core business functions 2 & 3 - expansion

Use Case Diagram

POST

NextGen POS

Cashier

Handle CashPayment

Process Rental

Process Sale

Handle CheckPayment

Handle Returns

«include» «include»

«include»

«include» «include»«include»

«actor»Accounting

System

«actor»Credit

AuthorizationService

Manage Users

...

UML notation:the base usecase points tothe included usecase

Handle CreditPayment

POST

Use Case Diagram - Inclusion

Use Cases – A Basic Format

Use case: Process Sale

Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payments. On completion, the Customer leaves with the items

Concepts

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Expanded Use Case “Process Sale”

Actor Action

1. A customer arrives at a POS checkout with items to purchase

2. Cashier starts a new sale 3. The cashier records the

identifier from each item. If there is more than one of the same item, the cashier can enter the quantity as well

5. On completion of item entry, the cashier indicates to the POS that item entry is complete

7. The cashier tells the customer the total and handles payment

System Response

4. Determines the item price and adds the item information to the running sales transaction

6. Calculates and presents the sale total

: Cashier:System

Sim ple cash-only Process Sale scenario:

1. Custom er arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier starts a new sale.

3. Cashier enters item identifier.4. System records sale line item andpresents item description, price, andrunning total.

Cashier repeats steps 3-4 until indicatesdone.

5. System presents total with taxescalculated.

6. Cashier tells Custom er the total, andasks for paym ent.7. Custom er pays and System handlespaym ent....

enterItem (item ID,quantity)

endSale()

m akePaym ent(am ount)

description,total

total withtaxes

change due,receipt

* [m ore item s]

m akeNewSale()

Message makeNewSale

:Register

makeNewSale

:Salecreate

create lineItems :List<SalesLineItem>

Message enterItem

2: makeLineItem(desc, qty)enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>

: Map<ProductDescription>

2.2: add(sl)

Message makePayment

: Registerm akePaym ent() 1: create() p:Paym ent

:Sale2:addPaym ent(p)

: Registerm akePaym ent() 1: m akePaym ent() :Sale

:Paym ent

1.1 Create()

Message getTotal

:Saletot = getTotal 1 *[ i = 1..n]: st = getSubtotal

:ProductDescription

1.1: pr = getPrice

lineItems[ i ] :SalesLineItem

«method»public void getTotal(){ int tot = 0; for each SalesLineItem, sli tot = tot + sli.getSubtotal(); return tot}

Message getBalance

s :Sale pmt: Payment1: amt = getAmountbal = getBalance

2: t = getTotal

{ bal = pmt.amount - s.total }

Message makePayment with Logging

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register s :Sale

:Payment

makePayment(cashTendered)

:Store

2: addSale(s)

completedSales: List<Sale>

2.1: add(s)

POS – Creating Objects

:Store :Register

pc:ProductCatalog

create 2: create(pc)

1: create

1.2: loadProdSpecs()

descriptions:Map<ProductDescription>

1.1: create

1.2.2*: put(id, pd)

1.2.1*: create(id, price, description)

pd:ProductDescription

28

Object Interaction Modeling helps the development team

understand the existing business processes design object interaction behaviors to support

29

Actor-System Interaction & Object Interaction

Foreground processing of use case.

Acquiring actor input and actor action.

Displaying system responses.

Background processing of use case by objects.

Designing high-level algorithms to process actor requests.

Producing system responses.

Actor-system interactionObject interaction

30

Steps for Interaction ModelingStep 1. Collecting information about business

processesStep 2. Describing scenarios

1. Identify nontrivial steps in the right column of each use case. A nontrivial step is one that requires background

processing. It goes beyond the presentation layer (i.e., the user

interface).2. For each nontrivial step, describe:

How objects interact to process the actor request. Begin with the step on the left column of the nontrivial

step.

Step 3. Convert the scenario into a scenario table (optional).

Step 4. Convert the scenarios/scenario table into a sequence diagram.

Step 5. Check the model for desired properties.

31

Example

nontrivialstep

*

32

Scenarios A scenario describes how a background

operation is performed Each sentence in a scenario is consisting of

1. a subject, 2. an action of the subject, 3. an object that is acted upon, and 4. possibly other objects required by the action.

A scenario table is to facilitate scenario description and facilitate translation into a sequence diagram

33

From Scenario Table to Sequence Diagram

for each line of the scenario table:

Case 1: subject is an Actor.

Actor

:object acted upon

action + other objects/data

objectacted upon

Patron

card scanner:

<<slide card>>

Example:

34

From Scenario Table to Sequence Diagram

object:

<<message>>

actor

Case 2: subject is an object and object acted upon is an actor.

<<confirmation message>>

Subject Object Acted Upon

Other Data / Objects

Subject Action

system displays confirmation message

Patron

system:

Patron

35

From Scenario Table to Sequence Diagram

Case 3: both subject and object acted upon are objects.

: Subject :object acted upon

actionperforming

action + other objects/data

cards canner:

device control:

actionperformingsend pid

Example

36

From Scenario Table to Sequence Diagram

Case 4: both subject and object acted upon are the same (a special case of case 3).

action + data / objects

object1:

return value if any

Subject Object Acted Upon

Other Data/ ObjectsSubject Action

shipment compute base rate

shipment

shipment:

compute base rate

37

Patron presents id card to librarian.

:Librarian

Patron

<<id card>>

Librarian pulls out patron’s folder using id number.

:Librain

Patron

<<uid, pass-word>>

:PatronFolders

get folder using patron id

patron folder

Modeling a Manual Library System

38

Patron submits uid and passwordto LoginGui.

LoginGui calls LoginController toverify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron.

:LoginGui

Patron

<<uid, pass-word>>

:LoginController

verify uid and password

<<msg>><<msg>>

Analysis/Informal Sequence Diagram

:LoginGui

Patron

<<uid, password>>

39

msg := verify (uid:String, password: Password) : String

<<uid, pass-word>>

verify uid and password

From Analysis to Design

:LoginGui

Patron

:LoginController

<<msg>>

function callreturn value return type

LoginGui calls LoginController toverify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron.

:LoginGui

Patron

<<uid, pass-word>>

:LoginController

<<msg>><<msg>>

parameter & type

40

Sequence Diagram: Flow of Control

:LoginGui

Patron

<<uid, pass-word>>

:LoginController

msg := verify (uid:String, password: Password) : String<<msg>>

1

(1) Patron submits uid and password to LoginGui object.

2

(2) LoginGui object calls the verify function of a LoginController object. The called function returns msg of type String.

3

(3) The LoginGui object shows msg to patron.

41

An Analysis Sequence Diagram

:Librarian

id card, book

patron folder f

:Patron Folder

get patron folder w/id

[patron folder found] get book card

[patron folder not found] error msg, id card

book:Book

book card

f:Patron Folder

[patron folder found] insert book card into patron folder

collection

patron

real world object within the library system

outsidelibrarysystem

[patron folder found] return patron folder

[patron folder found] id card, book

This an analysis sequence diagram models the current, manual operation, little design decision is made.

42

A Design Sequence Diagram:CheckoutG

UI

<<uid,call# list>>

:DBMgr l:Loan

[a]create(u,d)

[a]saveLoan(l)

d:Document

[a]setAvailable(false)

[a]save-Document(d)

[u!=null] process(callNumList)<<msg>>

loop

conditionalcall

Loop(for each cn in callNumList)

Patron

d:=getDocument(cn):Document

u:=getUser (uid):User

[d!=null]a:=isAvailable():boolean