1Spring 2005 Specification and Analysis of Information Systems Modeling Behavior with UML Sequence Diagrams Eran Toch erant

1Spring 2005Specification and Analysis of Information Systems

Modeling Behavior with UML Sequence Diagrams

Eran Toch

http://www.technion.ac.il/~erant

Spring 2007

2

Outline

• Introduction

• Basic notation

• Alternating paths

• Modularity

3

Modeling Process

Introduction | Basics | Alternations | Modularity

PhaseActionsOutcome

InitiationRaising a business needBusiness documents

RequirementsInterviewing stakeholders, exploring the system environment

Organized documentation

SpecificationAnalyze the engineering aspect of the system, building system concepts

Formal specification

DesignDefine architecture, components, data types, algorithms

Formal Specification

ImplementationProgram, build, unit-testing, integrate, documentation

Testable system

Testing & Integration

Integrate all components, verification, validation, installation, guidance

Testing results, Working sys

MaintenanceBug 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?


5

Behavioral Modeling

• Where are people coming from?

• Where are they going?

• How do they move from one space to the other?


6

Behavior Modeling

In process

supplied

OrderCheckoutManager

Order

message: changestatus

Add to cart

Check availability

Supply Order

Notify User

[okay][problem]

Sequence Diagrams Activity Diagrams State Diagrams


* We will not talk about collaboration diagrams

Inventory

message: create

7

Outline

• Introduction

• Basic elements


• Modularity

8

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.

therefore Sequence = Objects + messages


9

Sequence Diagrams

p : Product : ShooppingCart

addProduct (p)

customer

display)(

getPrice)(

checkout ()

sd Product Buyingobjects

message

Life line

activation )focus of control(

Diagram Name

• A simple sequence diagram:


10

Object Control

obj1 : Class1 obj2 : Class2

do (…)

: Class3create (…)

obj1 : Class1

useroperate)( Object

Creation

Object Destruction

Return Message

foo()Messages to

self


Illustration

11

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.


12

Sequences and Use-Cases

p : Product : ShooppingCart

addProduct (p)

: Ordercreate (…)

customer

display)(

getPrice)(

checkout ()


Hidden partVisible part

13

14

Full Message Attributes

C3.1: res := getLocation )fig(

sequence number

return value

message name argument list

[sequence-expression][return-value :=] [message-name] [(argument-list)]


15

Different Kinds of Messages

Synchronous Message

asynchronous Message

Return Message


16

Synchronous & Asynchronous Messages

teller : Order : Article

Nested Flow

getValue

price

setID

appl err handl 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


Example Example

17

Outline

• Introduction

• Basic elements


• Modularity

18

Flow Constructs

When we tell a scenario, which types of alternatives do we need?


IfElseLoopRepeatJump

19

Example

Options

archive)msg(

msg : Message :Database

opt

Do something...

[msg.status=confirmed]

Fragment

Condition


Used for modeling simple optional blocks.Has one operand; no "else" guard.

20

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.


21

Loops

Display)(

: OS :Folder :File

loop

loop

Display)(

[for each Folder]

[for each File]

Loop Fragment

Condition

Nested Loop Fragment


22

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


23

Examples of Guards

• [for each Object]

• [5]

• [i=1..5]

• [status = okay]

• No guard means an infinite loop


24

Outline

• Introduction

• Basic elements


• Modularity

25

Modularity

We need ways to create modular scenarios


26

Referencing a diagram

login)name,pass(

: User :User Manager : Policy

Login Handling)user,pass( :bool

ref

Do something…

Do something …

Reference Gate


27

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


28

Parallel Fragments

provideDetails)…(

: User :Checkout

Handler : Shipping

Handler

performCheckout)(

: Transaction Handler

parShip)address,products(

provideDetails)…(

chargeMoney)CC,sum(


29

Critical Fragment

• the region is treated atomically by the enclosing fragment )i.e. parallel fragment(

• No other operations can interfere while a critical region is executed


30

Summary

Behavior ModelingSequence models interaction

LanguageObjects + lifeline

Messages

AlternationsLoops

Alternatives

ModularityReferencing

Parallel


Documents

1Spring 2005 Specification and Analysis of Information Systems Modeling Behavior with UML Sequence Diagrams Eran Toch erant