System Sequence Diagrams: Understanding Artifact for System Behavior

undefined
 
LECTURE 5
 
SEQUENCE DIAGRAM
1
 
I
N
T
R
O
D
U
C
T
I
O
N
 
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
D
I
A
G
R
A
M
 
A 
system sequence diagram
 is a fast and easily created
artifact that illustrates input and output events related to the
systems under discussion
 
Before proceeding to a logical design of how a software
application will work, we should investigate and define the
system behavior as a "
black box
“.
 
 
2
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
 
A system sequence diagram
 (SSD) is a picture that shows, for
a particular scenario of a use case
, the events that external
actors generate, their order, and inter-system events.
 
An SSD is generated from inspection of a use case
Suggestion:
One SSD – one Use Case
3
4
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
 
V
S
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
 
A System Sequence Diagram is an artifact that illustrates input
and output events related to the system under discussion.
 
System Sequence Diagrams are typically associated with use-
case realization in the logical view of system development.
 
Sequence Diagrams (Not 
System
 Sequence Diagrams) display
object interactions arranged in time sequence.
5
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
S
 
Sequence Diagrams depict the objects and classes involved
in the scenario and the sequence of messages exchanged
between the objects needed to carry out the functionality of
the system.
6
 
S
S
D
S
Y
S
T
E
M
 
B
E
H
A
V
I
O
R
 
System behaves as 
Black Box
.
Interior objects are not shown, as they would be on a Sequence
Diagram.
 
:
System
7
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
S
 
   For a particular scenario of use-case an SSD shows-
The external actors that interact directly with the system.
The System (as a black box).
The system events that the actors generate.
8
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
S
 
The operations of the system in response to the events
generated.
System Sequence Diagrams depict the sequential order of the
events.
System Sequence Diagrams should be done for the main
success scenario of the use-case, and frequent and
alternative scenarios.
9
 
 
 
 
N
O
T
A
T
I
O
N
 
Object:
  Objects are instances of classes. Object is
represented as a rectangle which contains the name of the
object underlined.
Because the system is instantiated, it is shown as an object.
 
:
Object1
10
 
NOTATION (2)
 
Actor:
 An Actor is modeled using the usual symbol, the stick figure.
 
 
actor1
11
 
N
O
T
A
T
I
O
N
 
(
3
)
 
Lifeline:
 The LifeLine identifies the existence of the object
over time. The notation for a Lifeline is a vertical dotted line
extending from an object.
12
 
N
O
T
A
T
I
O
N
 
(
4
)
 
Message:
 Messages, modeled as horizontal arrows between
Activations, indicate the communications between objects.
 
 
messageName(argument)
13
 
E
X
A
M
P
L
E
 
O
F
 
A
N
 
S
S
D
 
Following example shows the success scenario of the
Process Sale use case.
Events generated by cashier (actor)-
   
  
   
makeNewSale
    
enterItem
     
endSale and
     
makePayment.
14
 
S
S
D
 
F
O
R
 
P
R
O
C
E
S
S
 
S
A
L
E
 
S
C
E
N
A
R
I
O
 
15
 
S
Y
S
T
E
M
 
S
E
Q
U
E
N
C
E
 
D
I
A
G
R
A
M
S
 
A
N
D
 
U
S
E
 
C
A
S
E
S
 
System Sequence Diagram is generated from inspection of a use
case.
Constructing a systems sequence diagram from a use case-
     1
.
Draw a line representing the system as a black box.
      2.Identify each actor that directly operates on the system. Draw a
line for each such actor.
3
.
F
r
o
m
 
t
h
e
 
u
s
e
 
c
a
s
e
,
 
t
y
p
i
c
a
l
 
c
o
u
r
s
e
 
o
f
 
e
v
e
n
t
s
 
t
e
x
t
,
 
 
i
d
e
n
t
i
f
y
 
t
h
e
s
y
s
t
e
m
 
(
e
x
t
e
r
n
a
l
)
 
e
v
e
n
t
s
 
t
h
a
t
 
e
a
c
h
 
a
c
t
o
r
 
g
e
n
e
r
a
t
e
s
.
 
T
h
e
y
 
w
i
l
l
c
o
r
r
e
s
p
o
n
d
 
t
o
 
a
n
 
e
n
t
r
y
 
i
n
 
t
h
e
 
r
i
g
h
t
 
h
a
n
d
 
s
i
d
e
 
o
f
 
t
h
e
 
t
y
p
i
c
a
l
 
u
s
e
c
a
s
e
.
 
I
l
l
u
s
t
r
a
t
e
 
t
h
e
m
 
o
n
 
t
h
e
 
d
i
a
g
r
a
m
.
 
 
16
 
S
S
D
S
 
A
R
E
 
D
E
R
I
V
E
D
 
F
R
O
M
 
U
S
E
 
C
A
S
E
S
.
 
 
 
 
17
 
S
Y
S
T
E
M
 
E
V
E
N
T
S
 
A
N
D
 
S
Y
S
T
E
M
 
B
O
U
N
D
A
R
Y
 
Identifying the System events-
1.
Determine the actors that directly interact with the
system.
2.
In the process Sale example, the customer does
not directly interact with the POS system. Cashier
interacts with the system directly. Therefore
cashier is the generator of the system events.
 
18
 
N
A
M
I
N
G
 
S
Y
S
T
E
M
 
E
V
E
N
T
S
 
A
N
D
 
O
P
E
R
A
T
I
O
N
S
 
S
y
s
t
e
m
 
e
v
e
n
t
 
 
External input event generated by an actor.
 
 
Initiates a responding operation by system.
S
y
s
t
e
m
 
o
p
e
r
a
t
i
o
n
 
 
Operation invoked in response to system event.
19
 
N
A
M
I
N
G
 
S
Y
S
T
E
M
 
E
V
E
N
T
S
 
A
N
D
 
O
P
E
R
A
T
I
O
N
S
 
System events and their associated system operations should
be expressed at the level of intent rather than in terms of the
physical input medium or widget.
 
In order to improve the clarity, it is appropriate to start the name
of the system event with a verb (for example-
add….,enter….,end….,make…. etc.,). It also emphasizes the
command origination of these events.
20
 
N
A
M
I
N
G
 
S
Y
S
T
E
M
 
E
V
E
N
T
S
 
A
N
D
 
O
P
E
R
A
T
I
O
N
S
 
 
For example 
enterItem
 is better than 
scan
 as it captures
the intent of operation rather than what interface is used to
capture the system event (design choice).
 
 
21
 
C
H
O
O
S
E
 
E
V
E
N
T
 
A
N
D
 
O
P
E
R
A
T
I
O
N
 
N
A
M
E
S
 
A
T
 
A
N
A
B
S
T
R
A
C
T
 
L
E
V
E
L
 
22
 
S
H
O
W
I
N
G
 
U
S
E
 
C
A
S
E
 
T
E
X
T
 
 
It is desirable to show at least fragments of use case text for
the scenario.
The text provides the details and context, while the diagram
visually summarizes the interaction.
23
 
S
S
D
 
W
I
T
H
 
U
S
E
 
C
A
S
E
 
T
E
X
T
 
24
 
C
O
N
C
L
U
S
I
O
N
 
System Sequence Diagrams provide a way for us to visually step
through invocation of the operations defined by Use-Cases.
It is not necessary to create SSDs for all scenarios of all use-
cases,at least not at the same time.
 
Slide Note
Embed
Share

System Sequence Diagrams (SSDs) are vital artifacts that visually illustrate input and output events related to a system. They help define system behavior and interactions, making them essential during the logical design phase of software applications. By depicting events in sequential order, SSDs offer insights into how external actors interact with a system and the corresponding system responses. This guide explores the significance of SSDs, their differences from Sequence Diagrams, and the fundamental principles behind creating them effectively.


Uploaded on Aug 14, 2024 | 3 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. 1

  2. INTRODUCTION SYSTEM SEQUENCE DIAGRAM A system sequence diagram is a fast and easily created artifact that illustrates input and output events related to the systems under discussion Before proceeding to a logical design of how a software application will work, we should investigate and define the system behavior as a "black box . 2

  3. SYSTEM SEQUENCE DIAGRAM A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events. An SSD is generated from inspection of a use case Suggestion: One SSD one Use Case 3

  4. SYSTEM SEQUENCE DIAGRAM VS SEQUENCE DIAGRAM A System Sequence Diagram is an artifact that illustrates input and output events related to the system under discussion. System Sequence Diagrams are typically associated with use- case realization in the logical view of system development. Sequence Diagrams (Not System Sequence Diagrams) display object interactions arranged in time sequence. 4

  5. SEQUENCE DIAGRAMS Sequence Diagrams depict the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the system. 5

  6. SSDSYSTEM BEHAVIOR System behaves as Black Box . Interior objects are not shown, as they would be on a Sequence Diagram. :System 6

  7. SYSTEM SEQUENCE DIAGRAMS For a particular scenario of use-case an SSD shows- The external actors that interact directly with the system. The System (as a black box). The system events that the actors generate. 7

  8. SYSTEM SEQUENCE DIAGRAMS The operations of the system in response to the events generated. System Sequence Diagrams depict the sequential order of the events. System Sequence Diagrams should be done for the main success scenario of the use-case, and frequent and alternative scenarios. 8

  9. NOTATION Object: Objects are instances of classes. Object is represented as a rectangle which contains the name of the object underlined. Because the system is instantiated, it is shown as an object. :Object1 9

  10. NOTATION (2) Actor: An Actor is modeled using the usual symbol, the stick figure. actor1 10

  11. NOTATION (3) Lifeline: The LifeLine identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object. 11

  12. NOTATION (4) Message: Messages, modeled as horizontal arrows between Activations, indicate the communications between objects. messageName(argument) 12

  13. EXAMPLE OF AN SSD Following example shows the success scenario of the Process Sale use case. Events generated by cashier (actor)- makeNewSale enterItem endSale and makePayment. 13

  14. SSD FOR PROCESS SALE SCENARIO 14

  15. SYSTEM SEQUENCE DIAGRAMS AND USE CASES System Sequence Diagram is generated from inspection of a use case. Constructing a systems sequence diagram from a use case- 1.Draw a line representing the system as a black box. 2.Identify each actor that directly operates on the system. Draw a line for each such actor. 3.From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram. 15

  16. SSDS ARE DERIVED FROM USE CASES. 16

  17. SYSTEM EVENTS AND SYSTEM BOUNDARY Identifying the System events- 1. Determine the actors that directly interact with the system. 2. In the process Sale example, the customer does not directly interact with the POS system. Cashier interacts with the system directly. Therefore cashier is the generator of the system events. 17

  18. NAMING SYSTEM EVENTS AND OPERATIONS System event External input event generated by an actor. Initiates a responding operation by system. System operation Operation invoked in response to system event. 18

  19. NAMING SYSTEM EVENTS AND OPERATIONS System events and their associated system operations should be expressed at the level of intent rather than in terms of the physical input medium or widget. In order to improve the clarity, it is appropriate to start the name of the system event with a verb (for example- add .,enter .,end .,make . etc.,). It also emphasizes the command origination of these events. 19

  20. NAMING SYSTEM EVENTS AND OPERATIONS For example enterItem is better than scan as it captures the intent of operation rather than what interface is used to capture the system event (design choice). 20

  21. CHOOSE EVENT AND OPERATION NAMES AT AN ABSTRACT LEVEL 21

  22. SHOWING USE CASE TEXT It is desirable to show at least fragments of use case text for the scenario. The text provides the details and context, while the diagram visually summarizes the interaction. 22

  23. SSD WITH USE CASE TEXT 23

  24. CONCLUSION System Sequence Diagrams provide a way for us to visually step through invocation of the operations defined by Use-Cases. It is not necessary to create SSDs for all scenarios of all use- cases,at least not at the same time. 24

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#