State Diagrams / System Sequence Diagrams (SSDs) Lesson 9

Agenda Weekly Schedule-SLATE Solutions to ICE’s posted on SLATE Today Assignment No 2 Rubric Posted Quiz No 3 next week Solutions to ICE’s posted on SLATE Today State charts – continued... I-C-E-06 Two ways of modelling Summarize Requirements Gathering Process Car Rental System – Case Study Introduce System Sequence Diagrams (SSDs) Quiz No 2 ICE-07 © Sheridan College

The Big Picture © Sheridan College

Typical Amazon Package Tracking Status Report © Sheridan College

Review I-C-E-06 Two Versions – check SLATE © Sheridan College

ICE-06 - Option A © Sheridan College

ICE06-Option B © Sheridan College

State Transition Diagrams - Review What is a State Diagram? Purpose: To model the various states that a system, user, or object can be in, including initial and final states. From a business perspective, tracking the state of an object provides users with important status information on key elements. © Sheridan College

State Transition Diagrams State: Some behavior of a system that is observable and that lasts for some period of time. A state is when a system is: Doing something – e.g., heating oven, mixing ingredients, accelerating engine, Waiting for something to happen – Waiting for user to enter password, waiting for sensor reading. Transition: (Virtually) instantaneous change in state (behavior). © Sheridan College

Here’s a simple example State Transition Diagram for a washing machine. Condition Action © Sheridan College

Typical Washing Machine User Interface © Sheridan College

A condition is typically some kind of event, e.g.: Signal Arrival of an object (data/material), Etc… An action is the appropriate output or response to the event, e.g.: Signal or message Transfer of an object, Calculation, Etc… Condition Action © Sheridan College

Something we might be more familiar with! © Sheridan College

A Typical Grocery POS[1] Login Screen User: PW: © Sheridan College

A Typical Grocery POS[2] Ready to Scan next Order © Sheridan College

A Typical Grocery POS[3] © Sheridan College

A Typical Grocery POS[4] Logging OFF © Sheridan College

State Tables [1] State Transition Diagrams often don’t show all possible combinations of states and events. Often they overlook things that can’t or shouldn’t happen. A state table overcomes that limitation by combining every known state with every event[condition] combination that can occur. You can then specify the correct action or next state. If you find a combination of state, event, and condition for which the attendant action and subsequent state are not specified, congratulations. You have found a bug! © Sheridan College

State Tables [2] To design a set of functional tests from a state transition diagram, the rules are simple: Visit every state. Cover every transition. Ensure that no states are unreachable or unleavable. © Sheridan College

Summarize: Rules for Developing Statecharts [1] Select the classes that will require statecharts [2] List all the status conditions for each group [3] Specify transitions that cause object to leave the identified state [4] Sequence state-transition combinations in correct order © Sheridan College

Rules for Developing Statecharts (continued) [5] Identify concurrent paths. [6] Look for additional transitions [7] Expand each transition as appropriate [8] Review and test each statechart © Sheridan College

Review Exercise – POS (model of the state of a Point of Sale device) First. Examine the diagram carefully. How many different state can the POS be in? Logging in Waiting Scanning Charging Logging out Second. List all of the Events and Event[Conditions] on the diagram that can trigger a change in state. 1.   Password[Valid] 2.   Password Entry[Invalid] 3.   Customer wants to check out 4.   Scan[item(s)] 5.   Customer pays[Valid] 6.   Customer pays[Invalid] 7.   Scan[last item] End of shift/Close Register The next step is to check each of these against each event to confirm that the transitions are correct. © Sheridan College

The Big Picture © Sheridan College

Identifying Inputs and Outputs—the System Sequence Diagram System sequence diagram (SSD) Describes flow of information Identifies interaction between actors and system Message oriented The System Sequence Diagram—Identifying Inputs and Outputs In the object-oriented approach, the flow of information is achieved through sending messages either to and from actors or back and forth between internal objects. A system sequence diagram (SSD) is used to describe this flow of information into and out of the automated system. Thus, an SSD documents the inputs and the outputs and identifies the interaction between actors and the system. An SSD is a type of interaction diagram. © Sheridan College

SSD Notation Actor “interacts” with the system via input/output SSDs use object notation Box (rectangle) refers to individual object Name of the object underlined Messages sent/received by objects, not classes   Lifeline Extension of object or actor for duration of the SSD Indicates sequence of the messages sent/received © Sheridan College

Sample System Sequence Diagram SSD Notation Figure above shows a generic SSD. As with a use case diagram, the stick figure represents an actor—a person (or role) that interacts with the system. In a use case diagram, the actor “uses” the system, but the emphasis in an SSD is on how the actor “interacts” with the system by entering input data and receiving output data. The box labeled :System is an object that represents the entire automated system. In SSDs and all other interaction diagrams, analysts use object notation instead of class notation. In object notation, a box refers to an individual object, not the class of all similar objects. The notation is simply a rectangle with the name of the object underlined. The colon before the under- lined class name is a frequently used but optional part of the object notation. In an interaction diagram, the messages are sent and received by individual objects, not by a class. In an SSD, the only object included is one representing the entire system. Underneath the actor and :System are vertical dashed lines called lifelines. A lifeline, or object lifeline, is simply the extension of that object—either actor or object—during the use case. The arrows between the lifelines represent the messages that are sent by the actor. Each arrow has an origin and a destina- tion. The origin of the message is the actor or object that sends it, as indicated by the lifeline at the arrow’s tail. Similarly, the destination actor or object of a message is indicated by the lifeline that is touched by the arrowhead. The pur- pose of lifelines is to indicate the sequence of the messages sent and received by the actor and object. The sequence of messages is read from top to bottom in the diagram. A message is labeled to describe its purpose and any input data being sent. The message name should follow the verb-noun syntax to make the purpose clear. The syntax of the message label has several options; the simplest forms are shown in Figure 5-6. Remember that the arrows are used to represent a message and input data. But what is meant by the term message here? In a sequence diagram, a message is an action that is invoked on the destination object, much like a command. Notice in Figure 5-6 that the input message is called inquireOnItem. Sample System Sequence Diagram © Sheridan College

SSD Notation (continued) Message syntax can take several forms Depends on send/return direction Message semantics: actions (like commands) invoked on destination object     © Sheridan College

Frequently, the same message is sent multiple times Frequently, the same message is sent multiple times. For example, when an actor enters items on an order, the message to add an item to an order may be sent multiple times. Figure 5-7(a) illustrates the notation to show this repeating operation. The message and its return are located inside a larger rectangle called a loop frame. In a smaller rectangle at the top of the frame is the descriptive text to control the behavior of the messages within the larger rectangle. The condition loop for all items indicates that the messages in the box repeat many times or are associated with many instances. Figure 5-7(b) shows an alternate notation. Here, the square brackets and text inside them are called a true/false condition for the messages. The asterisk (*) preceding the true/false condition indicates that the message repeats as long as the true/false condition evaluates to true. Analysts use this abbreviated notation for several reasons. First, a message and the returned data can be shown in one step. Note that the return data is identified as a return value on the left side of an assign- ment operator —the := sign. This alternative simply shows a value that is returned. Second, the true/false condition is placed on the message itself. Note that in this example, the true/false condition is used for the control of the loop. True/false condi- tions are also used to evaluate any type of test that determines whether a message is sent. For example, consider the true/false condition [credit card payment]. If it is true that the thing being tested is a credit card payment, the message is sent to the system to verify a credit card number. Finally, an asterisk is placed on the message itself to indicate the message repeats. Thus, for simple repeating messages, the alternate nota- tion is shorter. However, if several messages are included within the repeat or there are multiple messages—each with its own true/false condition—the loop frame is more explicit and precise. Here is the complete notation for a message: [true/false condition] return-value := message-name (parameter-list) © Sheridan College

SSD Message Syntax *[true/false condition] return-value := message-name (parameter-list) Any part of the message can be omitted. In brief, the notation components do the following: ■ An asterisk (*) indicates repeating or looping of the message. ■ Brackets [ ] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent. ■ Message-name is the description of the requested service. It is omitted on dashed-line return messages, which only show the return data parameters. ■ Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. ■ Return-value on the same line as the message (requires :=) is used to describe data being returned from the destination object to the source object in response to the message. © Sheridan College

Sequence diagrams use two additional frames to depict processing logic, as shown above. The opt frame in (a) is used when a message or a series of messages is optional or based on some true/false condition. The alt frame is used with if-then-else logic, as shown in (b). The alt frame in this figure indicates that if an item is taxable, then add sales tax; oth- erwise, add a tax exemption code for a sales tax exemption. © Sheridan College

Developing a System Sequence Diagram Begin with detailed description of use case Fully developed form Activity diagrams (4) step process for turning activity diagram into SSD   [1] Identify the input messages [2] Describe messages from external actor to system [3] Identify/apply special conditions to input messages [4] Identify and add the output return messages  © Sheridan College

A Simplified Diagram of the Telephone Order Scenario © Sheridan College

An SSD of the Simplified Telephone Order Scenario for the Create New Order Use Case © Sheridan College

Developing a System Sequence Diagram (continued) Names of messages reflect services performed Important principle for identifying data parameters Base the list on the class diagram Attributes from the classes listed as parameters   Iteratively define input/output parameters around workflows Objective: discovery and understanding © Sheridan College

Practice Exercise ICE07 See SLATE for a ICE07 © Sheridan College

For Next Class Read & Study Chapter 6 Pages 237 -246 What comes next? Sequence Diagrams © Sheridan College

Class example… Car Rental System – Posted on SLATE Week10 © Sheridan College