object interaction modeling yonglei tao sequence diagrams 2
TRANSCRIPT
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