Sequence Diagram & Pattern Visitor. California State University , Los Angeles Dr. Jiang Guo Fall 2010 Presented by : Sanaz Bonakdar Behin Behdinian Kate Dehbashi Amee Joshi Monali Bhavsar. Sequence Diagram. Sequence Diagram Sanaz Bonakdar Behin Behdinian Kate Dehbashi. Outline.
California State University , Los Angeles
Dr. Jiang Guo
Presented by :
Figure 1: An example of the Student
class used in a lifeline whose instance
name is freshman
Figure 2: An example of messages being sent between objects
A message that is sent synchronously assumes that the receiver is ready and listening and the caller waits for the completion of the operation and the return. It does not continue with the next steps in its execution until the receipt of a return.
-invoking a subroutine.
Sequence diagrams are typically used to model
Can be used to explore the logic of a complex operation, function, or procedure. One way to think of sequence diagrams, particularly highly detailed diagrams, is as visual object code.
A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. This includes web-services as well as business transactions implemented by a variety of technologies such as CORBA-Compliant Object Request Brokers(ORBs).
(vector of student object)Enroll in seminar Use case
Build SQL Select
List of all potential matches
Student data structure
13. The system informs the student the enrollment was successful
14. The system bills the student for the seminar
15. The system asks the student if he wants a printed statement of the enrollment.
16. The student indicates that he does want a printed statement.
17. The system prints the enrollment statement
18. The use case ends when the student takes the printed statement.
The student is not eligible to enroll in seminars
The student does not have the prerequisites
The student decides not to enroll in an available seminar
Shopping in the store
item for purchase (ProductID, amount)
invoice (inv#,description,total amount)
Use case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
Cashier: Wants accurate and fast entry, no payment errors, …
Salesperson: Wants sales commissions updated.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions):
Sale is saved. Tax correctly calculated…
Main success scenario (or basic flow): [see next slide]
Extensions (or alternative flows): [see next slide]
Special requirements: Touch screen UI, …
Technology and Data Variations List:
Identifier entered by bar code scanner,…
Open issues: What are the tax law variations? …
Main success scenario (or basic flow):
The Customer arrives at a POS checkout with items to purchase.
The cashier records the identifier for each item. If there is more than
one of the same item, the Cashier can enter the quantity as well.
The system determines the item price and adds the item information to
the running sales transaction. The description and the price of the current
item are presented.
On completion of item entry, the Cashier indicates to the POS system
that item entry is complete.
The System calculates and presents the sale total.
The Cashier tells the customer the total.
The Customer gives a cash payment (“cash tendered”) possibly greater
than the sale total.
Extensions (or alternative flows):
If invalid identifier entered. Indicate error.
If customer didn’t have enough cash, cancel sales transaction.
How to name system events and operations
System events should be expressed at the
level of intention
To improve clarity, start the name of a system event with a verb
enterItem(itemID) instead of scan(itemID)
Captures the intention
Respects design choices regarding the input device used to capture system event
Keep the system response at an
“Description, total” instead of “descrition and total”
In the example we can see the following actors:
Iterator is intended to be used on collections. Usually collections contain objects of the same type.
The iterator is used by the client to iterate through the objects form a collection and the operations are defined by the client itself.