Download presentation
Presentation is loading. Please wait.
1
Object Interaction Modeling
Yonglei Tao
2
Sequence Diagrams
3
Return Values
4
Conditional Messages
5
Conditional Messages
6
Conditional Messages
7
Iterations
8
Communication Diagrams
9
Conditional Messages
10
Conditional Paths
11
Iterations
12
Communication Diagrams
13
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
14
Use Case Diagram POST
15
Use Case Diagram - Inclusion
POST
16
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
17
Concepts
19
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
21
Message makeNewSale
22
Message enterItem
23
Message makePayment
24
Message getTotal
25
Message getBalance
26
Message makePayment with Logging
27
POS – Creating Objects
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.
30
Steps for Interaction Modeling
Step 1. Collecting information about business processes Step 2. Describing scenarios 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). 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 * nontrivial step
32
Scenarios A scenario describes how a background operation is performed
Each sentence in a scenario is consisting of a subject, an action of the subject, an object that is acted upon, and 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
Actor :object acted upon action + other objects/data object acted upon for each line of the scenario table: Case 1: subject is an Actor. Example: Patron card scanner: <<slide card>>
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:
35
From Scenario Table to Sequence Diagram
: Subject :object acted upon action performing action + other objects/data Case 3: both subject and object acted upon are objects. Example cards canner: device control: action performing send pid
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/ Objects Subject Action shipment compute base rate shipment:
37
Modeling a Manual Library System
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
38
Analysis/Informal Sequence Diagram
:LoginGui Patron <<uid, password>> Patron submits uid and password to LoginGui. :LoginGui Patron <<uid, pass-word>> :LoginController verify uid and password <<msg>> LoginGui calls LoginController to verify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron.
39
From Analysis to Design
:LoginGui :LoginController LoginGui calls LoginController to verify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron. <<uid, pass-word>> verify uid and password <<msg>> <<msg>> Patron :LoginGui :LoginController <<uid, pass-word>> msg := verify (uid:String, password: Password) : String function call parameter & type return type return value Patron <<msg>>
40
Sequence Diagram: Flow of Control
:LoginGui :LoginController 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. <<uid, pass-word>> msg := verify (uid:String, password: Password) : String <<msg>> Patron 3 (3) The LoginGui object shows msg to patron.
41
An Analysis Sequence Diagram
collection real world object within the library system :Patron Folder f:Patron Folder :Librarian book:Book id card, book get patron folder w/id outside library system patron folder f patron [patron folder not found] error msg, id card [patron folder found] get book card book card [patron folder found] insert book card into patron folder [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
:CheckoutGUI :DBMgr l:Loan d:Document <<uid,call# list>> u:=getUser (uid):User Patron <<msg>> [u!=null] process(callNumList) Loop (for each cn in callNumList) loop d:=get Document(cn): Document [d!=null]a:=isAvailable():boolean conditional call [a]create(u,d) [a]saveLoan(l) [a]setAvailable(false) [a]save- Document(d)
Similar presentations
