Behavior Modeling with UML 2.0

Transcription

1 Behavior Modeling with UML Apr-04 Haugen / Møller-Pedersen 1 UML standardization within OMG for Ericsson better tools Requirements from improved developers world-wide Ericsson UML standardization team contributing in cooperation with tool vendors issuing requirements in cooperation with alllies 28-Apr-04 Haugen / Møller-Pedersen 2 1

2 Why UML2.0? for Ericsson, Motorola, Alcatel, Nia (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 28-Apr-04 Haugen / Møller-Pedersen 3 Very Short History December 1999 RFI (Request For Information) 29 Responses to the RFI Ericsson made a joint response with Motorola and Alcatel (and Nia) September 2000 RFP (Request For Proposal) October 2001 Initial submission August 2002 Revised submission June 2003 Recommended for adoption Now Finalization Task Force April 2004 Final spec 28-Apr-04 Haugen / Møller-Pedersen 4 2

3 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 has adequate 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 illed 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 28-Apr-04 Haugen / Møller-Pedersen 8 Domain Model I User * * ATM * 1 Bank 1 1 * * Card 1 1 myaccounts Account 28-Apr-04 Haugen / Møller-Pedersen 9 3

4 Domain Model II ATM CardReader Keyboard Screen CashDispenser 28-Apr-04 Haugen / Møller-Pedersen 10 Use Case Model ATM CashRepository Withdrawal <<uses>> Authentication User <<uses>> Bank Currency 28-Apr-04 Haugen / Møller-Pedersen 11 4

5 Context model with UML1.x class diagrams with plain composition and no encapsulation with only provided interfaces on classes User-ATM ATM-Bank User ATM Bank CardReader Keyboard Screen CashDispenser 28-Apr-04 Haugen / Møller-Pedersen 12 Composite class (incomplete) with parts, ports and connectors part ATM port User-Reader :CardReader User-Screen :Screen ATM-bank User-Keyboard :Keyboard :CashDispenser connector User-Cash 28-Apr-04 Haugen / Møller-Pedersen 13 5

6 Context Model in UML2.0 - I composite structure as part of a Collaboration BankContext User-Reader ATM-bank User-Screen User-Keyboard User-Cash 28-Apr-04 Haugen / Møller-Pedersen 14 Context Model in UML2.0 - II Including multiplicities on parts multiplicity BankContext User-Reader [ ] User-Screen [1..100] ATM-bank User-Keyboard User-Cash 28-Apr-04 Haugen / Møller-Pedersen 15 6

7 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 28-Apr-04 Haugen / Møller-Pedersen 16 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 interaction problem Sequence Diagrams are used to... document protocol situations, illustrate behavior situations, verify interaction properties relative to a specification, describe test cases, document simulation traces. 28-Apr-04 Haugen / Møller-Pedersen 17 7

8 (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 The frame (UML 2) sd EnterPIN The name of the interaction msg( Give PIN ) Receive Event Digit Digit Digit Continuation Digit Send Event Code(cid, pin) OK Message name PIN OK 28-Apr-04 Haugen / Møller-Pedersen 18 Combined fragment example sd EnterPIN combined fragment frame operator msg( Give PIN ) Digit Digit Digit Digit operand separator alt Code(cid, pin) NOK PIN NOK OK PIN OK 28-Apr-04 Haugen / Møller-Pedersen 19 8

9 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 28-Apr-04 Haugen / Møller-Pedersen 20 References (Interaction Use / Occurrence) sd Authenticate erence Idle Cardid(cid) EnterPIN Continuation loop(0,3) msg("try again!") PIN NOK EnterPIN 28-Apr-04 Haugen / Møller-Pedersen 21 9

10 Nested combined fragments sd Withdrawal erence combined fragment Authenticate nested fragment alt Withdrawal PIN OK Continuation msg("give amount!") amount(v) checkaccount(v) alt money(v) receipt(v) msg( Amount too large ) n msg( Illegal entry ) PIN NOK card card taken 28-Apr-04 Haugen / Møller-Pedersen 22 Interaction Overview Diagram sd Withdrawal erence combined fragment PIN OK Authenticate PIN NOK sd nested fragment Withdrawal msg("give amount!") amount(v) checkaccount(v) sd msg( Illegal entry ) Continuation sd sd money(v) receipt(v) msg( Amount too large ) n Inline diagram sd card card taken 28-Apr-04 Haugen / Møller-Pedersen 23 10

11 EnterPIN state machine <<statemachine>> EnterPIN n:integer PIN: integer sm EnterPIN send(msg( Give PIN )); n=1; PIN=0 enterdigit [n<4]digit/ n++; PIN= PIN+digit*10 (3-n) [n=4]digit/pin=... send(code(cid,pin)) n n waitok definition of exit point 28-Apr-04 Haugen / Møller-Pedersen 24 Statemachine for the ATM use of exit point sm ATM /authn=0 Idle CardId(cid) :EnterPIN /authn=0 :Service [authn<3]/ authn++; send(msg( Try again )) n Withdrawal status :Withdrawal :Status [authn==3]/ authn=0 send(msg( illegal entry )); CardOut entry: send(card) cancelled cardtaken 28-Apr-04 Haugen / Møller-Pedersen 25 11

12 Attributes of the ATM Statemachine is a Classifier (that is class-like): Attributes Operations (local actions) <<statemachine>> ATM authn:integer cid: integer sa: Amount aa: Amount sendmoney(a:amount) authn number of tries cid card id sa selected amount aa available amount 28-Apr-04 Haugen / Møller-Pedersen 26 State machine Withdrawal sm Withdrawal :GetAmount cancelled cancelled send(checkaccount(sa)) again n/ send(msg( Amount too large )) use of entry point VerifyTransaction / sendmoney(sa); send(receit(sa)); 28-Apr-04 Haugen / Møller-Pedersen 27 12

13 Simple GetAmount sm GetAmount Send(msg( select amount )) :SelectAmount cancel cancelled amount(sa); Send(msg( select another amount )) again definition of entry point 28-Apr-04 Haugen / Møller-Pedersen 28 Extended GetAmount <<statemachine>> ATM <<statemachine>> GetAmount inherited state <<statemachine>> FlexibleATM <<statemachine>> GetAmount {extended} sm GetAmount {extended} :SelectAmount otheramount/ send(msg( enter amount )) cancelled redefined transition :enteramount cancel Send(msg( enter another amount )) again 28-Apr-04 Haugen / Møller-Pedersen 29 13

14 Another similar service: Currency sd Currency Authenticate alt PIN OK Currency msg("give currency!") EUR msg("give amount!") amount(e) checkaccount(v(e)) alt EUR(e) [enough on account] receipt(v) msg( Amount too large ) n [inadequate funds] PIN NOK msg( Illegal entry ) card card taken 28-Apr-04 Haugen / Møller-Pedersen 30 Interactions are generalizable and redefinable sd GenWithdrawal actual gate GenWithdrawal sd getamount sd givemoney Authentication alt PIN OK Withdrawal Currency getamount sd getamount redefined getamount redefined givemoney redefined getamount redefined givemoney checkaccount(v(e)) alt givemoney [enough on account] Currency msg("give currency!") receipt(v) EUR msg( Amount too large ) n PIN NOK [inadequate funds] msg("give amount!") amount(e) formal gate msg( Illegal entry ) sd givemoney card card taken EUR(e) 28-Apr-04 Haugen / Møller-Pedersen 31 14

15 ATM revisited - generalised sm ATM /authn=0 Idle CardId(cid) :EnterPIN /authn=0 :Service [authn<3]/ authn++; send(msg( Try again )) n status :Status [authn==3]/ authn=0 send(msg( illegal entry )); CardOut entry: send(card) cardtaken 28-Apr-04 Haugen / Møller-Pedersen 32 Extended state machines sm WithdrawalATM sm CurrencyATM :Service {extended} :Service {extended} Withdrawal Currency :Withdrawal :Currency cancelled cancelled CardOut CardOut 28-Apr-04 Haugen / Møller-Pedersen 33 15

16 Decomposing a Lifeline wrt an Interaction sd Authenticate ATM_Authenticate Cardid(cid) Idle EnterPIN loop(0,3) PIN NOK we want to lo into this lifeline msg("try again!") EnterPIN this is the name of the diagram where we find the decomposition 28-Apr-04 Haugen / Møller-Pedersen 34 Decomposition sd Authenticate sd ATM_Authenticate ATM_Authenticate :CardReader :CashDispenser :Screen :Keyboard :Controller Idle ATM_Idle Cardid(cid) Cardid(cid) Cardid(cid) EnterPIN loop(0,3) PIN NOK msg("try again!") EnterPIN loop(0,3) ATM_EnterPIN ATM_PIN NOK msg("try again!") msg("try again!") ATM_EnterPIN Code(cid, pin) OK, NOK Code(cid, pin) NOK notice the correspondance! notice the correspondance! 28-Apr-04 Haugen / Møller-Pedersen 35 16

17 Composite (design) class ATM User-Reader :CardReader User-Screen :Screen :Controller ATM-bank User-Keyboard :Keyboard :CashDispenser User-Cash 28-Apr-04 Haugen / Møller-Pedersen 36 Structured Classes are like other Classes ATM User-Reader :CardReader User-Screen :Screen :Controller ATM-bank User-Keyboard :Keyboard :CashDispenser User-Cash Structured Classes may have attributes & operations, interfaces, Internal structure is inherited, inherited parts may be redefined by extension 28-Apr-04 Haugen / Møller-Pedersen 37 17

18 What about Components? Have all the properties of structured classes In addition: A kind of package, i.e. it may have model elements that you would not have for classes Realization by a number of classes Deployment Artifacts, nodes, Still to be stereotyped for e.g..net and EJB components 28-Apr-04 Haugen / Møller-Pedersen 38 Finally Tools IBM (Rational) general Telelogic real-time, telecom, but moving towards general I-Logix real-time, telecom, control systems Softteam general, with emphasis on profiling Bos Selic et al. (eds) UML for Real (Chapter 3) Chonoles and Schardt: UML2.0 for Dummies Fowler UML Distilled (Third Edition) Coming soon: Rumbaugh: UML Reference Manual 28-Apr-04 Haugen / Møller-Pedersen 39 18