Instructor: Dr.

Syed Ali Raza

Software
Chapter 7: Requirements Modeling: Flow, Behavior,
Patterns, and WebApps
 The Requirements Model and the
Analysis Model
The Requirements
Elicitation Functional/
Use Case Diagrams/
Process Nonfunctional
Sequence Diagrams
Requirements
(the system level)

The Object-Oriented
Analysis Static Analysis - Class Diagrams
Process Dynamic Analysis - State Diagrams/
Refined Sequence
Diagrams (The object
level)
Importance of Sequence Diagrams
• Depict object interactions in a given scenario identified for a given
Use Case
• Specify the messages passed between objects using horizontal
arrows including messages to/from external actors
• Time increases from Top to bottom
Notations in Sequence
Diagram
• Object
• An object in a sequence diagram is drawn as a rectangle containing the name of
the object, underlined.

• An object can be named in one of three ways: the object name, the object name
and its class, or just the class name (anonymous object).
• Everything in an object-oriented system is accomplished by objects. Objects take
on the responsibility for things like
• managing data,
• moving data around in the system
• responding to inquiries
• protecting the system.
• Objects work together by communicating or interacting with one another.
Notations in Sequence
Diagram
• Lifeline
• Entities of participants in a collaboration (scenario) are written horizontally
across the top of the diagram.
• A lifeline is represented by dashed vertical line drawn below each object.
• The lifeline indicate the existence of the object.
• Each object has its timeline represented by a dashed line below the object.
Notations in Sequence
Diagram
• Message
• Messages depict the invocation of operations and are shown horizontally.
• They are drawn from the sender to the receiver.
• Ordering is indicated by vertical position, with the first message shown at
the top of the diagram, and the last message shown at the bottom.
Notations in Sequence
Diagram
• Messages specified on interactions can be synchronous or asynchronous
• A synchronous call requires the sender (caller) to wait for the receiver (callee) to complete
the operation and return a result before continuing its process. It is represented by a solid
line with a filled arrowhead pointing towards the callee.
• A return message (dashed line with an open arrowhead) typically follows to indicate the
response.

Object1:C1 Object2:C2 Object3:C3 Object1:C1 Object2:C2

updateStatus( ) calcRoute( )
generateMessage( )

route

Implicit Returns Explicit Return

Synchronous call
Notations in Sequence
Diagram
Asynchronous call
• An asynchronous call does not require the sender to
wait for the receiver to complete the operation. The Object1:C1 Object2:C2
{active} {active}
sender continues executing its process immediately
after sending the request.
• There might not be a return message explicitly shown, asynchronous_Call ()
as the response can occur independently.
• The caller proceeds without waiting, improving
concurrency and responsiveness. callBack ()
• It is useful in event-driven systems or when the
response can be handled later (e.g., callbacks, messages
in a queue).
Notations in Sequence
Diagram
• Non instantaneous message
• Messages are often considered to be instantaneous, thus, the time it takes
to arrive at the receiver is negligible.
• The messages are drawn as a horizontal arrow. To indicate that it takes a
certain while before the receiver actually receives a message, a slanted
arrow is used.
Rules of Sequence Diagrams
• Identify objects needed to support use case
• Determine sequence of internal events following the external initiating
event
• Diagrams that are not initiated with an external actor represent
only a partial sequence
• Partial sequence diagrams should clearly identify the actor initiated
sequence diagrams from which they are launched
Rules of Sequence Diagrams
• Sequence Initiation

Object1:C1 Object2:C2

Click Update Button

updateStatus( )
User
Rules of Sequence Diagrams
• Display operation names on call arrows

factory:
c:client cmd_pktCToCHeaderFactory

header:
cmd_pktCToCCommandHeader
buildHeader( char * )
«create»

header
Rules of Sequence Diagrams
Compound and Simple Iteration
:Interface :DiscreteFD
:Subsystem :Resource :InterfaceContainer :Interface :DiscreteFD

getInterfaceContainer()

* [for all
Interfaces in

{
Container] Find( )

setState( )

amMasterSI( )

* [for all Interfaces in Container] publishState() setOn( ) / setOff( )

CMM:process target:process
Application Process
with CIF
<<includes>>
Process Command
Command Request Request sequence

Command Request

Command Response

Command Response
<<includes>>
Process Command
Response sequence
Showing alternate behavior in a sequence
diagram
:CmdHandler :CmdValidater :CmdRouter :EventLog :StatusDialog

issueCommand( )
validateCommand( )

User Application

[if valid command] routeCommand( )

[if invalid command] logError( )

display(status)
 Showing Extension
Point
:CmdHandler :CmdValidater :CmdRouter :StatusDialog

issueCommand( )
validateCommand( )

User Application

routeCommand( )
Extension Point
[invalid command]

abort command
request and send
system message display( status)
Specifying Timing Requirements

CMM : process target : process

User Application
a: Command

Create Transaction

b: Command
{b.receiveTime 
a.sendTime + 50ms}

c: Response

Remove Transaction
d: Response
{d.receiveTime 
a.sendTime + 1s}