SSD from UC

V1.0
November 2012
Ferreiras

1
 E07 1

• Para cada uno de los escenarios, de cada uno de los casos de

uso de su proyecto, preparar su SSD.
• 1
NOMBRES COMPONENTES DEL E07:
• Diagramas de Secuencia del Sistema
• ENTREGA: 20-03-2016
• LUGAR: felix.ferreiras@gmail.com
• HORA: Antes de 2400

Analysis, UC from Events Table 22

 What is a SSD ?
• A System Sequence Diagram ( SSD), is a
visual summary of one of the scenarios of a
use case.

• Displays events sequentially inputted from

an external source to the system.

• Will define the system events and

operations.

3
 What is a SSD ?
• System sequence diagrams are a timeline
drawing of an use case.

• Events are related by time with the top

events occurring first.

• System events are the important items.

• These are events that cause a system

response.
4
 What is a SSD ?
• Is a sequence diagram that shows, for a
particular scenario of a use case, the events
that external actors generate, their order, and
possible inter-system events.

• If it is desired [ In this course, democrately,

you must] use case text may be placed on the
left side of the system sequence diagram.
• …
5
 What is a SSD ?
• There may be more than one actor to the system. An
actor may be an external automated system that the
system may communicate with.
•
• If icon notation of stick figure is used, automated
actors or robots are shown as actors with a line
horizontally through the head.

• The diagram places emphasis on events that cross the

system boundary from actors to systems.

6
 How is made a SSD?
• Represents the actor with the UML notation:
<<actor>>
unActor

• Draw a dashed vertical line ( call a lifeline) which extends

downward from the actor;
mySystem: SistemInDeveloping

• Represents the system as an instance of the system

being developed:

• Draw a dashed vertical line ( call a lifeline) which

extends downward from this instance of the system in
developing; 7
 How is made a SSD?
• Displays the message from the initiating actor to the
system as an arrow from the actor who sends the
message to the system instance;

• Display the message from the system to actor as a

dashed arrow. ( A system output associated with the
previous message ) . It is recommendable to show all the
messages between the actors and the system instance.

• A single repeated message is preceded by an asterisk

().

• A repeated sequence of messages is enclosed in a

rectangle.
8
 How is made a SSD?
• Display each actor and draw a lifeline for each
of them.

• Optionally include use case text on left.

9
 How is made a SSD?
• A simple generic SSD :
<<actor>> mySystem: SistemInDeveloping
unActor
message1Actor()

message2Actor( arg1, arg2, arg3)

message3Actor(arg)
messageSystem( )

message4Actor(arg, arg2)
returnedValue

10
 What shows a SSD ?
• The interaction between an actor and a
system for one use case scenario.

• In this course:

• One SSD per use case scenario

11
 What show a SSD ?
• The initiating actor of the use case;
• The messages from the initiating actor to the
system;
• May also show messages from the system to
actors;
• Each external system which sends a message
to the system;

12
 What show a SSD ?
• Messages between the system and other
systems required in responding to the business
event;
• The order in which these messages occur; And
• A system instance;
“Because only external events result in system
inputs, the only system sequence diagrams of
interest deal with use cases corresponding to
external events.”
13
 What show a SSD ?
• Messages between the system and other
systems required in responding to the business
event;

• The order in which these messages occur; And

• A system instance;

14
 What show a SSD ?
• Actor, Presentation Options:
An actor may also be shown as a class rectangle
with the keyword «actor», with the usual
notation for all compartments. For example:
<<actor>> In this course we will be using
unActor this notation for actor, in all
sequence diagrams

Source: Page 588, OMG Unified Modeling Language (OMG UML), Superstructure,
V2.1.2

15
 from where coming the information to
construct a SSD?
1. For each actor that directly operates on
the System, draw his notation and a lifeline.

2. For each System events that each actor

generates in use case, draw a message.

3. Optionally, include use case text to left of

diagram.

16
 from where coming the information to
construct a SSD?
• From formal use case identify system events
that each actor generates.

• Identify each actor that directly operates on the

system.

• Actor may be participants in a use case even

when they do no initiate the use case. For
example, a Credit Card Bank must be contacted
before a credit card purchase may be completed.

17
 from where coming the information to
construct a SSD?
• In this situation ( above ) the actor figure for the
bank appears on the right in the SSD ( See fig.4-
25, page 120, Stumpf ).

18
 How is made a SSD?
• A simple generic SSD :
<<actor>> : SistemInDeveloping
unActor
message1Actor()

message2Actor( arg1, arg2, arg3)

message3Actor(arg)
messageSystem( )

message4Actor(arg, arg2)
returnedValue

19
 What is a SSD ?
• The SSD places emphasis on events that cross the system boundary from
actors to systems.

A system sequence diagram should be done for the main success scenario of
the use case, and frequent or complex alternative scenarios.

A system sequence diagram should specify and show the following:

• External actors
• Messages (methods) invoked by these actors
• Return values (if any) associated with previous messages
• Indication of any loops or iteration area

20
 What is a SSD ?
♦ Determine system events and operations
♦ Derived from Use Cases –Typical course of events
♦ Identify system functionality (operations) to be designed
♦ System boundary is critical

♦ Illustrate events from actors to systems

♦ System sequence diagrams describe scenarios

* a scenario is an instance of a use case
* a real example of the enactment of a use case
e.g. Process Sale

♦ Some UML notation for a sequence diagram is shown on the next slide

How is it made?

♦ Draw a line representing the system as a black box.

♦ Identify each actor that directly operates on the system.
Draw a line for each such actor.
♦ From formal use case identify system events that each actor generates.
Illustrate them.
♦
Optionally include use case text on left.

21
 System Sequence Diagram (SSD)
For a use case scenario, an SSD shows:
• The instance of the system in developing.
• The external actors that interact with System
• The System events that the actors generate
• SSD shows operations of the System in response
to events, in temporal order
• Develop SSDs for the main success scenario of a
selected use case, then frequent and salient
alternative scenarios
22
SSD for Process Sale scenario

23
 From Use Case to
Sequence System Diagram
How to construct an SSD from a use case scenario:
1. Draw System as black box on right side
2. For each actor that directly operates on
the System, draw a stick figure and a lifeline.
3. For each System events that each actor
generates in use case, draw a message.
4. You must include use case text to left of diagram.

24
Example: use cases to SSD

25
 Identifying the right Actor

• In the process Sale example, does the customer

interact directly with the POS system?
• Who does?
• Cashier interacts with the system directly
• Cashier is the generator of the system events
• Why is this an important observation?

26
 Naming System events & operations
• System events and associated system operations
should be expressed at the level of intent
• Rather than physical input medium or UI widget
• Start operation names with verb (from use case)
• Which is better, scanBarCode or enterItem?

27
 Point of Sale
• Point of sale (POS) or checkout is the location where
a transaction occurs in exchange for goods or services.
The point of sale often refers to the physical
electronic cash register or dedicated POS hardware (or
"terminal") used for checkout, but the POS is simply the
location where the sale is conducted, money changes
hands and a receipt is given, which can also occur on a
smartphone, tablet, laptop, or mobile POS device when
the right hardware and POS software is combined with
the mobile device.
• The combined software, hardware, and peripheral
devices at a POS station manage the selling process,
typically driven by a sales associate or cashier. 

28
 Point of Sale
• POS includes features such as:
• Inventory tracking,
• credit card processing,
• Cash management,
• Customer loyalty,
• Employee time clock;
• Labor scheduling,
• And a detailed reporting interface to make smarter business
decisions.

29
 Point of Sale
• Caso de estudio: Punto de Venta.

• Un punto de venta (PDV) es una aplicación informática utilizada:

• Para registrar las ventas y el cobro / pago de mercancías al detalle.

• Interfaces para calculadora de ITBIS y registro de inventario.

• Soporte del lado del cliente para interfaces y terminales variadas.

• - Proporcionar flexibilidad y personalización ( procesamiento de

diferentes reglas de negocio por ejemplo, cuando una nueva venta
se inicia y se debe aplicar una condición especial en su cobro.)-

30
 System Sequence Diagram from Use Case
Description

Obviando detalles …
…
Descripción A customer arrives at a checkout with items to purchase. The
cashier uses the POS system to record each purchased item.
The system presents a running total and line-item details. The
customer enters payment information, which the system
validates and records. The system updates inventory. The
customer receives a receipt from the system and then leaves
with the items.

31
System Sequence Diagram from Use Case
Description Pay by Cash.

32
 System Sequence Diagram from Use Case
Description Pay by Cash.

For the simple Cash-only scenario of the Process Sale

use case, the cashier is the only actor that directly
interacts with the system. It, the actor, generates the
events ( messages to the system, -ff- ):

– makeNewSale()
– enterItem(itemID, quantity)
– endSale()
– makePayment(amount)

33
System Sequence Diagram from Use Case
Description Pay by Cash.

FLUJO DE EVENTOS
FLUJO PRINCIPAL DE EVENTOS
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1 Customer arrives at a POS
checkou with goods and/or
services to purchase
2 Cashier enters item identifier 3 System records sale line item
and presents item
description, price, and
tunning total.
4 Cashier repeats step 3 5 System repeats step 4
6 System presents total with
taxes calculated
34
System Sequence Diagram from Use Case
Description Pay by Cash.

FLUJO DE EVENTOS
FLUJO PRINCIPAL DE EVENTOS
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
7 Cashier tells Customer the total, 8 System handles payment
and asks for payment. The and presents receipt.
Customer pays by cash

35
System Sequence Diagram from Use Case
Description Pay by Cash.

• The actor sends to the system

the messages:

• makeNewSale()
• enterItem(itemID, quantity)
• endSale()
• makePayment(amount)

36
 System Sequence Diagram from Use Case
Description
• System sequence diagrams are important! They
serve for:

• Connecting the application logic layer to other

layers:
• If the actor is human – connection to the
presentation layer.
• If the actor is an external service – interface.

• Implementing the use case scenarios.

37
 References
Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development; Craig Larman; Prentice Hall; 3
edition, 2004.

38