A Formal Semantics for Complete UML State Machines with Communications Shuang Liu 1, Yang Liu 2, Étienne André 3, Christine Choppy 3, Jun Sun 4, Bimlesh.

A Formal Semantics for Complete UML State Machines with Communications

Shuang Liu1, Yang Liu2, Étienne André3, Christine Choppy3, Jun Sun4, Bimlesh Wadhwa1 and Jin Song Dong1

Background1

(OMG) UML state machine is semi-formal language, with formal syntax and informal semantics.

Unclarities in the OMG UML2.0 state machines specification have been reported [FSKR’05].

The importance of providing formal semantics for UML state machines: Facilitate precise and efficient communications. Yield more rigorous and consistent models. Enable automatic verification, which uncovers of design flaws in an early

stage and dramatically reduces development costs.

Background2

Verfication tools

Formal semantics needed

We are devoted to solve the problem of automatic verification, especially model checking of UML state machine models.

Related Work3

Verification tools

Translation Based approach

Related Work4

Translation-based approach: convert UML state machines into some formal language.

Existing works: [BCR’00, BCR’03] translate UML state machines into Abstract State

Machines. [CKZ’11, ACK’12] translate UML state machines into Petri Net. [LMM’99Spin, SKM’01] translate UML state machines into Promela. [NB’03, ZL’10] translate UML state machines into CSP and CSP#.

Weaknesses: Redundant but undesired behaviors may be introduced due to the semantic

gaps. Heavily depends on the target language and fragile to changes. Knowledge of the target language may be required.

Related Work5

Verification tools

Related Work5

Verification tools

Operational Semantics for UML state machines

Related Work6

Operational semantics for UML state machines

Existing works: [LMM’99] uses EHA as intermediate format and LTS as semantic model. [Beeck’02] inspired by [LMM’99], use LTS as semantic model. [FS’07] use core state machine as semantic model.

Weaknesses: [LMM’99][FS’07] Intermediate formats are used. Only covers a subset of UML state machine features. It is not clear how to extend the work[LMM’99][Breek’02] to support more

features, such as choice, fork, join pseudostates. Syntax structure does not obey OMG UML state machine specifications.

Our Contributions

An operational semantics for complete UML state machines (v2.4.1), inspired by previous works [LMM’99] [Beeck’02] . Syntax structure follows OMG UML state machines specifications. Complex features such as orthogonal composite state, submachine state,

fork/join/choice pseudostates. Communications (synchronous and asynchronous) between different

state machines. Formalize event pool mechanisms.

Implementation of the operational semantics in a prototype tool, which facilitates model checking of safety and liveness properties on UML state machines.

7

Our Contributions8

1. Operational semanticsCovers all features of UMLState machines, communicationsand event pool mechanisms

USM2C

2. A self contained UML state machine model checker

Preliminary9

StateSimple, Composite

Orthogonal, Submachine

Region Transition Pseudostate

Fork, Join, Junction, Choice

Initial, Entry, Exit, Terminate,

Shallow history, Deep history

Compound Transition Run to completion

(RTC) step

D.Harel and E.Gery, Executable Object Modeling with Statecharts. In IEEE Computer, volume 30, pages 31-42

Our Approach--Syntax10

Follow UML state machines specifications A tuple contains all the attributes and

associations Extends well to future changes,

i.e., refinement.

Example DepartureSM = ({RD}; {EntryPoint1;

ExitPoint1}) Further refinement to region RD or any

attributes of RD will not change DepartureSM

Semantics—RTC rules11

Use Labeled Transition System (LTS) as semantic model

RTC Wandering Rule

RTC Deferral Rule 1

RTC Deferral Rule 2

RTC Progress Rule

RTC ProgressC Rule

(ks----current active states,P----current event pool,GV----global variables)

Semantics—RTC rules (illustration)

12

Example

({Crusing, Operating}, (Φ, Φ, {alert100}), {stopNum=1, mode=true})

alert100 (RTC Progress Rule)

({Watch, WaitEnter, WaitArrivalOK,Operating}, (Φ, Φ, {opend , arriveAck}), {stopNum=1, mode=true})

({Watch, WaitEnter, WaitArrivalOK,Operating}, (Φ, {opend} , {arriveAck}), {stopNum=1, mode=true})

opend (RTC Deferral Rule 2)

arriveAck (RTC ProgressC Rule)

({Watch, WaitDepart, WaitArrivalOK,Operating}, (Φ, Φ, {opend}), {stopNum=1, mode=true})

[mode==true]

({Watch, Choice1, WaitArrivalOK,Operating}, (Φ, Φ, {opend}), {stopNum=1, mode=true})

Semantics--communications13

Communications between different state machines SendSignal indicates asynchronous communication Call indicates synchronous communication

Semantics--communications (illustration)

14

(({Watch, WaitEnter, WaitArrivalOK, Operating}, (Φ, Φ, {alert80}), {stopNum=1, mode=false}),({WaitEnter}, {Φ, Φ, {moveCompleted}} , Φ))alert80

(RTC Progress Rule)

(({Alerted,WaitArrivalOK, WaitEnter, Operating}, (Φ,Φ,Φ),{stopNum=1,mode=false}),({WaitEnter}, {Φ, Φ, {moveCompleted}} , Φ))

moveCompleted(RTC Progress Rule, RTC ProgressC Rule)

[mode==false]

({Watch, Choice1, WaitArrivalOK,Operating}, (Φ, Φ, Φ), {stopNum=1, mode=false})

moveCompleted(RTC Progress Rule)

(({Alerted, WaitEnter, WaitArrivalOK,Operating}, (Φ, Φ, {alert80}), {stopNum=1, mode=false}))

[mode==false]

alert80 (RTC Progress Rule)

(({Final1,Operating}, (Φ, Φ, {alert80}), {stopNum=1, mode=false}))

(({Final1,Operating}, (Φ, Φ, Φ), {stopNum=1, mode=false}),({Parked}, {Φ, Φ, Φ} , Φ))

(({WaitStop,Operating}, (Φ, Φ, {alertStop})),({Parked}, {Φ, Φ, Φ} , Φ))

alertStop (RTC Progress Rule)

Handler state machine

Implementation and Evaluation15

USM2C, a model checker for UML state machines. Support model checking of safety and liveness properties.

Comparison with HUGO1

Prop1=[](alert100<>arriveAck), Prop2=[](retain(!cardValid /\ numIncorrect>=maxNumIncorrect))Prop3=[](TurnGreen <>carExit)

Scalability Evaluation Result

1. http://www.pst.informatik.uni-muenchen.de/projekte/hugo/index.html

UML @ PAT16

UML Modul

e

Conclusion and Future work17

Conclusion Operational semantics coving all features of UML (v2.4.1) state

machines. Communications, event pools are considered. Implementation and evaluation shows the effectiveness of our approach.

Future works Action language can be formalized. Consider real-time features. Consider object-oriented features, such as object construction and

destruction. State space reduction techniques can be developed.

PAT—current status18

PAT is available at http://www.patroot.com 1Million lines of code, 11 modules with 100+ build in examples Used as an educational tool in many universities. Attracted more than 2600 registered users from more than 600

organizations, e.g. Microsoft, HP, ST Elec, Oxford Univ., … Sony, Hitachi, Canon.

Japanese PAT User group formed in Sep 2009:

Thank you

19

References

[FSKR’05] H.Fecher, J. Schonborn, M. Kyas and W.P. de Roever. 29 new unclarities in the semantics of uml 2.0 state machines. In Formal Methods and Software Engineering. Pages 62-65, 2005.

[BCR’00] E. Börger and A. Cavarra and E. Riccobene. Modeling the Dynamics of UML State Machines. Abstract State Machines, Theory and Applications. Pages 223-241, 2000.

[BCR’03] E. Börger and A. Cavarra and E. Riccobene. Modeling the Meaning of Transitions from and to Concurrent States in UML State Machines. In proceedings of the 2003 ACM symposium on Applied computing. pages 1086-1091, 2003. 

[CKZ’11] C. Choppy, K. Klai and H. Zidani. Formal Verification of UML State Diagrams: A Petri net based Approach. ACM SIGSOFT Software Engineering Notes. volume 36, issue 1, pages 1-8 , January 2011. 

[ACK’12] E. André, C. Choppy and K. Klai. Formalizing Non-Concurrent UML State Machines Using Colored Petri Nets. ACM SIGSOFT Software Engineering Notes, volume 37, issue 4, pages 1-8 , July 2012 .

[LMM’99Spin] D. Lattela, I. Majzik and M. Massink. Automatic Verification of a Behavioural Subset of UML Statechart Diagrams Using the SPIN Model-checker. In Formal Aspects of Computing, volume 11, pages 637-644, 1999.

[SKM’01] T. Schäfer  and A. Knapp and S. Merz. Model Checking UML State Machines and Collaborations. Electronic Notes in Theoretical Computer Science, volume 55, issue 3, pages 357–369 , October 2001.

[NB’03] M.Y. Ng and M. Butler. Towards formalizing UML State Diagrams in CSP. 1st IEEE International Conference on Software Engineering and Formal Methods. Pages 138-147 , 2003.

20

References

[ZL’10] S. Zhang and Y. Liu. An Automatic Approach to Model Checking UML State Machines. Secure Software Integration and Reliability Improvement Companion (SSIRI-C), pages 1-6, 2010 .

[LMM’99] D. Lattela, I. Majzik and M. Massink. Towards A Formal Operational Semantics for UML Statechart Diagrams. Proceedings of the IFIP TC6/WG6, 1999.

[Beeck’02] M. von der Beeck. A Structured Operational Semantics for UML-statecharts. In Software and Systems Modeling, volume 1, pages 130-141, 2002.

[FS’07] H. Fecher and J. Schönborn. UML 2.0 State Machines: Complete Formal Semantics Via core state machine. In Formal Methods: Applications and Technology, volume 4346, pages 244-260, 2007.

21

Backup I1

Backup II1