Behavior Modeling with UML 2 - uio.no€¦ · Context model with UML1.x class diagrams with plain...

1

2-Mar-05 Haugen / Møller-Pedersen

INF 5120

1

Behavior Modeling with

UML 2.0


INF 5120

2

UML standardization within OMG – for Ericsson

EricssonUML standardization

team

developersworld-wide

Requirements from

improved

contributing in cooperation

with tool vendors

issuing requirements in cooperation

with alllies

better tools

2


INF 5120

3

U2 Partners

Submitters– Alcatel, CA, Ericsson, Fujitsu, HP, IBM, I-Logix, IONA, Kabira,

Motorola, Oracle, Rational, SOFTEAM, Telelogic, Unisys

Supporters– Advanced Concepts Center LLC, Ceira Technologies,

Commissariat à L'Energie Atomique, Compuware, DaimlerChrysler, Embarcadero Technologies, Enea Data, France Telecom, Fraunhofer FOKUS, Gentleware, Intellicorp, Jaczone, Kennedy Carter, Klasse Objecten, KLOCwork, Lockheed Martin, Mercury Computer, MSC.Software, Northeastern University, Popkin Software, Proforma, Sims Associates, Syntropy Ltd., Sun Microsystems, University of Kaiserslautern, University of Kent, VERIMAG, WebGain, and 88solutions

2P2P


INF 5120

4

Why UML2.0?

for Ericsson, Motorola, Alcatel, Nokia (telecom, realtime) – SDL/MSC only one vendor– UML/ROOM (as by RoseRT) only one vendor

– UML2.0 combining features from these

for others– Scalability, modeling of large, complex systems– Improvement of existing concepts: activities, components,– Completeness: action semantics, formal/precise definition

in general– Experiences with UML1.x required an improvement– Model Based Development requires a good modeling language

3


INF 5120

9

Example - ATM

Domain statement– An Automatic Teller Machine (ATM) is a system with mechanical as

well as electronic parts. Its purpose is to provide a bank user with cash provided that the user can authenticate herself and she hasadequate funds in her bank account.

– She authenticates herself by presenting a card to the ATM cardreader, and a personal identification number (PIN) through the ATM keyboard.

– The ATM is connected electronically and possibly through some kind of network to the bank such that the account status may be checked online.

– The ATM is refilled with cash notes regularly or when the number of specific notes is below some limit.

– The ATM may also provide foreign currency to the customer


INF 5120

10

ATM: Domain Model I

CardAccount

User ATM Bank

1

*

1

*

* 1* *

myAccount

11

FromHaugen, Ø., B. Møller-Pedersen, and T. Weigert, Modeling Embedded Systems in UML 2.0, in The Embedded Systems Handbook, Richard Zurawski, Editor. 2005, CRC Press.

4


INF 5120

11

Domain Model II

Keyboard CashDispenserCardReader Screen

ATM


INF 5120

12

Use Case Model

ATM

«include»

«include»

UserBank

Withdrawal

CashRepository

Currency

Authentication

5


INF 5120

13

Context model with UML1.x class diagrams

with plain composition and no encapsulation with only provided interfaces on classes

User Bank

Keyboard CashDispenserCardReader Screen

ATM

User-ATM ATM-Bank


INF 5120

14

Composite class (incomplete)

with parts, ports and connectors

ATM

:CardReader

:CashDispenser:Keyboard

User-Reader

User-Keyboard

ATM-bank

User-Cash

:ScreenUser-Screen

part

port

connector

6


INF 5120

15

Context Model in UML2.0 - I

composite structure as part of a Collaboration

BankContext

:User :ATM :Bank

User-Reader

User-Keyboard

ATM-bank

User-Cash

User-Screen


INF 5120

16

Context Model in UML2.0 - II

Including multiplicities on parts

BankContext

:User[1..10000]

:ATM[1..100] :Bank

User-Reader

User-Keyboard

ATM-bank

User-Cash

User-Screen

multiplicity

7


INF 5120

17

BankContext

… as part of Packages?

:User[1..10000]

:ATM[1..100] :Bank

User-Reader

User-Keyboard

ATM-bank

User-Cash

User-Screen

No


INF 5120

18

Sequence Diagrams (Interactions)

Sequence Diagrams are– simple– powerful– readable– used to describe interaction sequences

History– Has been used for a number of years informally– Standardized 1992 in Z.120 (Message Sequence Charts - MSC)– Last major revision of MSC is from 1999 (called MSC-2000)– Formal semantics of MSC-96 is given in Z.120 Annex B

– Included in UML from 1999, but in a rather simple variant

8


INF 5120

19

Purpose

Emphasizes the interaction between objects indicating that the interplay is the most important aspect

– Often only a small portion of the total variety of behavior is described improve the individual understanding of an interactionproblem

Sequence Diagrams are used to ...– document protocol situations,– illustrate behavior situations,– verify interaction properties relative to a specification,– describe test cases,– document simulation traces.


INF 5120

20

(Simple) Sequence Diagram

Messages have one send event, and one receive event.– The send event must occur before the receive event.– The send event is the result of an Action

Events are strictly ordered along a lifeline from top to bottom

sd EnterPIN

:Bank:User :ATM

msg(”Give PIN”)

Digit

Digit

Digit

Digit

Code(cid, pin)

PIN OK

OK

The frame (UML 2)

The name of the interaction

Send Event

Receive Event

Message name

Continuation

9


INF 5120

21

Combined fragment example

combined fragment frame

operator

operand separator

sd EnterPIN

:Bank:User :ATM

msg(”Give PIN”)

Digit

Digit

Digit

Digit

Code(cid, pin)

alt

PIN NOK

PIN OK

NOK

OK


INF 5120

22

Combined fragments of Interaction

We want to express– choices: alternative, option, break– parallel merge– loops

We may also want to add other operators– negation– critical region– assertion

Other suggested operators that will not come in UML 2.0– interrupt– disrupt

10


INF 5120

23

:Bank:User

sd Authenticate

EnterPINref

loop(0,3)

EnterPINref

Idle

Cardid(cid)

msg("Try again!")

:ATM

PIN NOK

References (Interaction Use / Occurrence)

reference

Continuation


INF 5120

24

Nested combined fragments

:Bank:User

sd Withdrawal

Authenticateref

alt

PIN NOK

PIN OK

Withdrawal

msg("Give amount!")

ok

:ATM

amount(v) checkaccount(v)

alt money(v)

receipt(v)

nokmsg(”Amount too large”)

msg(”Illegal entry”)

card

card taken

Continuation

reference

combined fragment

nested fragment

11


INF 5120

25

sd Withdrawal

Authenticateref

PIN NOKPIN OK

okmoney(v)

receipt(v)

:Bank:User :ATM

sd


:Bank:User :ATM

sd


:User :ATM

sd

card

card taken

:User :ATM

sd

Withdrawal

msg("Give amount!")

amount(v) checkaccount(v)

:Bank:User :ATM

sd

Interaction Overview Diagram

Continuation

reference

combined fragment

nested fragment

Inline diagram


INF 5120

26

EnterPIN state machine

n:integerPIN: integer

<<statemachine>>EnterPIN

sm EnterPIN

enterDigit

send(msg(”Give PIN”)); n=0; PIN=0

waitOK

[n=4]digit/PIN=...send(Code(cid,PIN))

ok

[n<4]digit/n++;PIN= PIN+digit*10(4-n)

noknokok

definition of exit point

12


INF 5120

27

Statemachine for the ATMsm ATM

:Withdrawal

entry: send(card)

CardOut

:EnterPIN/authN=0

Idle

CardId(cid)

[authN<3]/authN++;send(msg(”Try again”))

/authN=0

[authN==3]/authN=0

send(msg( ”illegal entry”));

nok

ok

cancelledok

:Status

:Service

statusWithdrawal

cardTaken

use of exit point


INF 5120

28

Attributes of the ATM

Statemachine is a Classifier (that is class-like):– Attributes– Operations (local actions)

authN number of triescid card idsa selected amount

sendMoney(a:Amount)

authN: integercid: integersa: Amount

<<statemachine>>ATM

13


INF 5120

29

State machine Withdrawal

sm Withdrawal

:GetAmount cancelled

VerifyTransaction

send(CheckAccount(sa)) nok/send(msg(”Amount too large”))

ok

ok/sendMoney(sa);send(Receit(sa));

again

cancelled

use of entry point


INF 5120

30

Simple GetAmount

sm GetAmount

:SelectAmount

Send(msg(”select amount”))

amount(sa);

cancelcancelled

again

Send(msg(”select another amount”))

definition of entry point

14


INF 5120

31

sm GetAmount {extended}

:SelectAmount

:enterAmount

otherAmount/send(msg(”enter amount”))

cancel

again

cancelled

ok

Send(msg(”enter another amount”))

Extended GetAmount

inherited state

redefined transition

<<statemachine>>ATM

<<statemachine>>GetAmount

<<statemachine>>FlexibleATM

<<statemachine>>GetAmount {extended}


INF 5120

32

Another similar service: Currency

:Bank:User

sd Currency

Authenticateref

alt

PIN NOK

PIN OK

Currency

msg("Give currency!")

ok

:ATM

amount(e) checkaccount(v(e))

altEUR(e)

receipt(v)



card

EUR

msg("Give amount!")

[enough on account]

[inadequate funds]

card taken

15


INF 5120

33

Interactions are generalizable and redefinable

:Bank:User

sd GenWithdrawal

Authenticationref

alt

PIN NOK

PIN OK

ok

:ATM

checkaccount(v(e))

alt

receipt(v)



card

[enough on account]

[inadequate funds]

getAmount

ref

giveMoneyref

card taken

Currency

msg("Give currency!")

amount(e)

EUR

msg("Give amount!")

sd getAmount

:User :ATM

EUR(e)

sd giveMoney

:User :ATM

ok

sd getAmountsd giveMoney

GenWithdrawal

redefined getAmountredefined giveMoney

Withdrawal

redefined getAmountredefined giveMoney

Currency

formal gate

actual gate


INF 5120

34

ATM revisited - generalisedsm ATM

entry: send(card)

CardOut

:EnterPIN/authN=0

Idle

CardId(cid)

[authN<3]/authN++;send(msg(”Try again”))

/authN=0

[authN==3]/authN=0

send(msg( ”illegal entry”));

nok

ok

:Status

:Service

status

cardTaken

16


INF 5120

35

Extended state machinessm WithdrawalATM

:Withdrawal

CardOut

cancelledok

:Service{extended}

Withdrawal

sm CurrencyATM

:Currency

CardOut

cancelledok

:Service{extended}

Currency


INF 5120

36

:Bank:User

sd Authenticate

EnterPINref

loop(0,3)

EnterPINref

Idle

Cardid(cid)

msg("Try again!")

:ATMref ATM_Authenticate

PIN NOK

Decomposing a Lifeline wrt an Interaction

we want to look into this lifeline

this is the name of the diagram

where we find the decomposition

17


INF 5120

37

Decomposition

:Keyboard :Controller:CardReader

sd ATM_Authenticate

ATM_EnterPINref

loop(0,3)

ATM_EnterPINref

ATM_Idle

Cardid(cid)

msg("Try again!")

:CashDispenser

ATM_PIN NOK

msg("Try again!")

Cardid(cid)

:Screen

Code(cid, pin)

NOK

Code(cid, pin)

OK, NOK

:Bank:User

sd Authenticate

EnterPINref

loop(0,3)

EnterPINref

Idle

Cardid(cid)

msg("Try again!")

:ATMref ATM_Authenticate

PIN NOK

notice the correspondance!

notice the correspondance!


INF 5120

38

Composite (design) class

ATM

:CardReader


:Controller

User-Reader

User-Keyboard

ATM-bank

User-Cash

:ScreenUser-Screen

18


INF 5120

39

Structured Classes are like other Classes

Structured Classes may have– attributes & operations, interfaces, …

Internal structure is inherited, inherited parts may be redefined by extension

ATM

:CardReader


:Controller

User-Reader

User-Keyboard

ATM-bank

User-Cash

:ScreenUser-Screen


INF 5120

40

What about Components?

Components have all the properties of structured classes

Note that these are just derived, that is they are also

defined for classes

19


INF 5120

41

What is special for Components

Realization by a number of classes


INF 5120

42

... and

may be kind of ‘package’, i.e. it may have model elements that you would not have for classes

A component may have e.g. use cases, sequence diagrams,

packages, dependencies, components

20


INF 5120

43

Deployment of components

Artifacts, Nodes, Network of Nodes,...


INF 5120

44

Must be profiled for actual component models

21


INF 5120

45

Finally

Tools– IBM Rational Software Modeler (eller Architect)– Telelogic real-time, telecom, but moving towards general– I-Logix real-time, telecom, control systems– Softteam general, with emphasis on profiling– MagicDraw– Enterprise Architect

Books– Selic et al. (eds) UML for Real (Chapter 3)– Chonoles and Schardt: UML2.0 for Dummies– Fowler UML Distilled (Third Edition)– Rumbaugh: UML Reference Manual 2nd edition– Craig Larman: Applying UML and Patterns

Behavior Modeling with UML 2 - uio.no€¦ · Context model with UML1.x class diagrams with plain...

Documents

Transcript of Behavior Modeling with UML 2 - uio.no€¦ · Context model with UML1.x class diagrams with plain...