modeling behavior with sequence diagrams
DESCRIPTION
Modeling software interaction and behavior with sequence diagramsTRANSCRIPT
1Spring 2005Specification and Analysis of Information Systems
Session 5:
Modeling Behavior with UML Sequence Diagrams
Spring 2008
Analysis and Specification of Information Systems
Eran Tochhttp://www.technion.ac.il/~erant
2
Outline
• Introduction• Basic notation• Alternating paths• Modularity
3
Modeling Process
Introduction | Basics | Alternations | Modularity
Phase Actions Outcome
Initiation Raising a business needBusiness documents
Analysis Interviewing stakeholders, exploring the system environment
Organized documentation
Specification Analyze the engineering aspect of the system, building system concepts
Logical System Model
Implementation Program, build, unit-testing, integrate, documentation
Testable system
Testing & Integration
Integrate all components, verification, validation, installation, guidance
Testing results, Working sys
Maintenance Bug fixes, modifications, adaptationSystem versions
4
Why to Model Behavior?
• How do we use the SMS Server interface? What is the order of executing the operations?– sendMessage, getStatus, Resend?– getStatus, sendMessage, checkForMessages?
• When do we use resend?
Introduction | Basics | Alternations | Modularity
5
Behavioral Modeling
Introduction | Basics | Alternations | Modularity
Order of actions• How operations are
ordered• Execution Paths:
– Sequential – Parallel– Loops
Preconditions • When operations
are executed• How the outcome
of operations affects execution
Effects• What is the output
of operations• How operations
change the state of the system
Send message
Get StatusResend
[if getStutus == err]
Resend
Message queue
Adds a new msg
6
Outline
• Introduction• Basic elements• Alternating paths• Modularity
7
Building a Sequence Diagrams
Class AClass C
Class BClass D
Use Case 1
Use Case 2Use Case 3
Sequence diagrams capture the use-case behavior using the foundation of the classes.
Sequence = Objects + messages
Introduction | Basics | Alternations | Modularity
8
Sequence Diagrams
p : Product : ShooppingCart
addProduct (p)
customer
display)(
getPrice)(
checkout ()
sd Product Buyingobjects
message
Lifeline
activation )focus of control(
Diagram Name
• A simple sequence diagram:
Introduction | Basics | Alternations | Modularity
9
Object Control
obj1 : Class1 obj2 : Class2
do (…)
: Class3create (…)
obj1 : Class1
useroperate)( Object
Creation
Object Destruction
Return Message
foo()Messages to
self
Introduction | Basics | Alternations | Modularity
Illustration
10
Illustration
Corresponding Class Diagram
Notice that a dependency exists whenever messages are passed between instances of the class
Dependencies can be overridden by associations, aggregations etc.
Introduction | Basics | Alternations | Modularity
11
Sequences and Use-Cases
p : Product : ShooppingCart
addProduct (p)
: Ordercreate (…)
customer
display)(
getPrice)(
checkout ()
Introduction | Basics | Alternations | Modularity
Hidden partVisible part
12
13
Full Message Attributes
C3.1: res := getLocation )fig(
sequence number
return value
message name argument list
[sequence-expression][return-value :=] [message-name] [(argument-list)]
Introduction | Basics | Alternations | Modularity
14
Different Kinds of Messages
Synchronous Message
asynchronous Message
Return Message
Introduction | Basics | Alternations | Modularity
15
Synchronous & Asynchronous Messages
manager sensor eye
Nested Flow
check
check
operate
sensor manager alarm
Asynchronous Flow
unknown
ring
Price need to be finished, before teller can do another operation )getName(
Ring is executed, while the control flow is returned to err handle and appl
unknown
log
Introduction | Basics | Alternations | Modularity
Example Example
16
Outline
• Introduction• Basic elements• Alternating paths• Modularity
17
Flow Constructs
When we tell a scenario, which types of alternatives do we need?
Introduction | Basics | Alternations | Modularity
IfElseLoopRepeatJump
18
Example
Options
archive)msg(
msg : Message :Database
opt
Do something...
[msg.status=confirmed]
Fragment
Condition
Introduction | Basics | Alternations | Modularity
Used for modeling simple optional blocks.Has one operand; no "else" guard.
19
Alternatives
archive)msg(
msg : Message :Database
Condition
:Admin
alt
notify)msg.getID)((
wait)(
[msg.status=confirmed]
[msg.status=error]
[else]
Else condition)optional(
Alternative Fragment group
Execution regions. At most one will execute.
Introduction | Basics | Alternations | Modularity
20
Loops
Display)(
: OS :Folder :File
loop
loop
Display)(
[for each Folder]
[for each File]
Loop Fragment
Condition
Nested Loop Fragment
Introduction | Basics | Alternations | Modularity
21
Breaks
isLooged = login)name,pass(
: User :User Manager : Policy
addBadLogin)name(
break
[¬isLooged]
Do something…
Do something …
If the condition is met, the break fragment is executed, and the reminder of the sequence is ignored
Handy in model exception handling
Introduction | Basics | Alternations | Modularity
22
Examples of Guards
• [for each Object]• [5]• [i=1..5]• [status = okay]• No guard means an infinite loop
Introduction | Basics | Alternations | Modularity
23
Outline
• Introduction• Basic elements• Alternating paths• Modularity
24
MODULARITY
We need ways to create modular scenarios
Introduction | Basics | Alternations | Modularity
25
Referencing a diagram
login)name,pass(
: User :User Manager : Policy
Login Handling)user,pass( :bool
ref
Do something…
Do something …
Reference Gate
Introduction | Basics | Alternations | Modularity
26
Referenced Diagram
: User Manager :UserAccount
sd Login Handling
loop
cName -= getUseNamer)(
[for each UserAccount]
login)name,pass(
opt
[cName = name]
cName -= getUseNamer)(
isInSystem)true(
true
false
Diagram name
Input message
Output message
Introduction | Basics | Alternations | Modularity
27
Summary
Behavior ModelingSequence models interaction
LanguageObjects + lifeline
Messages
AlternationsLoops
Alternatives
ModularityReferencing
Introduction | Basics | Alternations | Modularity