![8
SSD for a Process Sale scenario
enterItem (item ID , quantity)
:S ystem: C ashier
endS ale
m akeP aym ent(am ount)
a U M L loop
in teractio n
fram e, w ith a
boolean g u ard
expression
external actor to
system
P rocess S ale S cenario
system as black box
the nam e could be "N extG enP O S " but "S ystem " keeps it
sim ple
the ":" and underline im ply an instance , and are explained in a
later chapter on sequence diagram notation in the U M L
a m essage w ith
param eters
it is an abstraction
representing the
system event of
entering the
paym ent data by
som e m echanism
description , total
return value(s)
associated w ith the
previous m essage
an abstraction that
ignores presentation
and m edium
the return line is
optional if nothing is
returned
total w ith taxes
change due , receipt
m akeN ew S ale
[ m ore item s ]lo o p](https://image.slidesharecdn.com/lecture8systemsequence-180413173344/85/Lecture8-system-sequence-8-320.jpg)
![9
SSDs are derived from use cases;
they show one scenario.
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done.
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays and System handles
payment.
...
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario](https://image.slidesharecdn.com/lecture8systemsequence-180413173344/85/Lecture8-system-sequence-9-320.jpg)
Lecture8 system sequence
- 2. 2 O p e r a tio n : e n te r I te m ( … ) P o s t- c o n d it io n s : - . . . O p e r a t io n C o n t r a c t s S a le d a t e . . . S a le s L in e I te m q u a n t ity 1 . .*1 . . . . . . D o m a in M o d e l U s e - C a s e M o d e l D e s ig n M o d e l : R e g is te r e n te r It e m ( ite m ID , q u a n tit y ) : P r o d u c tC a ta lo g s p e c = g e tP r o d u c t S p e c ( it e m ID ) a d d L in e I te m ( s p e c , q u a n tity ) : S a le R e q u ir e - m e n t s B u s i n e s s M o d e lin g D e s i g n S a m p l e U P A r t i f a c t R e l a t io n s h ip s : S y s t e m e n t e r It e m ( id , q u a n t it y ) U s e C a s e T e x t S y s t e m S e q u e n c e D i a g r a m s m a k e N e w S a le ( ) s y s te m e v e n ts C a s h ie r P r o c e s s S a le : C a s h ie r u s e c a s e n a m e s s y s te m o p e r a tio n s U s e C a s e D ia g r a m V is io n S u p p le m e n ta r y S p e c ific a tio n G lo s s a r y p a r a m e te r s a n d r e t u r n v a lu e d e ta ils s ta r t in g e v e n t s to d e s ig n f o r P r o c e s s S a le 1 . C u s t o m e r a r r iv e s .. . 2 . C a s h ie r m a k e s n e w s a le . 3 . ...
- 3. 3 SSDs • The OOAD challenge • UCs are functional but System is OO • This is a modeling paradigm mismatch • How to make the functional-OO transition • Without losing any reqs • Being able to demonstrate no reqs are lost • End up with a correct, robust & flexible OO system • Ultimately, every req must be an assigned responsibility for some object!
- 4. 4 SSDs • A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events. • All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems. • System Events or System Operation • it is useful to investigate and define system’s behavior as a "black box." • System behavior is a description of what a system does, without explaining how it does it. • The UML does not define something called a "system" sequence diagram but simply a "sequence diagram."
- 5. 5 SSDs • SSDs are one of the books’s best ideas • SSD is the key model that • Links UCs with OO models (e.g., class & sequence) • Supported by operation contracts (next chp) • Establishes traceability of reqs into OO models
- 6. 6 SSDs • A UC specifies function-ality • A UC scenario is a time-ordered series of function calls that Actor invokes on System • Larman calls them system operations or system events • Key tasks are 1. Identify the functions in a UC scenario 2. Translate them into UML function syntax 3. Draw a sequence diagram (easy part) • Easier if you have simple, complete UCs
- 7. 7 SSDs • Can draw object model containing two objects • Actor & System • System operations are functions gleaned from UCs • Maps UC functionality onto OO models for further refinement
- 8. 8 SSD for a Process Sale scenario enterItem (item ID , quantity) :S ystem: C ashier endS ale m akeP aym ent(am ount) a U M L loop in teractio n fram e, w ith a boolean g u ard expression external actor to system P rocess S ale S cenario system as black box the nam e could be "N extG enP O S " but "S ystem " keeps it sim ple the ":" and underline im ply an instance , and are explained in a later chapter on sequence diagram notation in the U M L a m essage w ith param eters it is an abstraction representing the system event of entering the paym ent data by som e m echanism description , total return value(s) associated w ith the previous m essage an abstraction that ignores presentation and m edium the return line is optional if nothing is returned total w ith taxes change due , receipt m akeN ew S ale [ m ore item s ]lo o p
- 9. 9 SSDs are derived from use cases; they show one scenario. : Cashier :System Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. ... enterItem(itemID, quantity) endSale makePayment(amount) description, total total with taxes change due, receipt makeNewSale [ more items ]loop Process Sale Scenario
- 10. 10 Process Sale UC UC: Process Sale makeNewSale() 1. User selects new sale option (Request--invocation) 2. System requests item identifier (Response--return) enterItem(itemID, quantity) 3. User enters item identifier & quantity (Correct wrt quantity?) 4. System records sale of item, and 5. System displays item description, price, current total Steps 2-5 repeated until user finished endSale() 6. User selects sale finished option 7. System displays total and taxes due makePayment(amount) 8. User enters payment information 9. System handles payment recordSale() (Why not show this on SSD?) 10. System logs completed sale and sends sale information to Accounting System and Inventory System 11. System generates receipt
- 11. 11 Choose event and operation names at an abstract level enterItem(itemID, quantity) scan(itemID, quantity) : Cashier worse name better name :System