A General Framework for Formalizing Object-Oriented Modeling Techniques

1. A General Framework for Formalizing Object-Oriented Modeling Techniques Betty H. C. Cheng Software Engineering and Network Systems Laboratory Department of Computer Science and Engineering Michigan State University East Lansing, Michigan 48824 Chengb@cse.msu.edu www.cse.msu.edu/~chengb

2. Acknowledgements • Joint work with the following people: • Robert Bourdeau • Laura Campbell • William McUmber • Enoch Wang • Ryan Stephenson • Sponsored in part by: • National Science Foundation Grants: • (CCR-9633391, CCR-9901017, EIA-0000433) • DARPA Grant (EDCS Program): F30602-96-1-0298 • Motorola • Eaton Corporation • Siemens Automotive • Detroit Diesel Corporation

3. Apply Formalization Framework Bridge the Gap Between Informal and Formal Methods Object-Oriented “Blueprints” Formal Representations • Objective: • formal specifications • executable code • that can be verified • for correctness • and completeness • Benefits: • Automated Analysis • Consistency, completeness • Rapid Prototyping • Behavior Simulation • Design Transformations • Test Case generation • Informal specifications, • graphical models, • easy for humans to • formulate, • may be inconsistent and • incomplete.

4. Overview • Introduction • Background/Related Work • Formalization Framework • Validation: • Tool Support • Case Study • Conclusions and Future Investigations

5. Motivation • Embedded systems are difficult to develop • Object-Oriented Design can be powerful for embedded systems • Diagrammatic notations facilitate abstraction • UML is de facto standard • Object-Oriented • Commonly used • More intuitive • But diagrams lack formality • precisely predicting behavior is difficult

6. Objectives and Results • Overarching goals: • Broaden base of developers who can use rigorous software engineering techniques • Provide palatable path to more rigorous SE techniques • Leverage existing expertise and technology • Enable use of intuitive diagrammatic notations (UML) for embedded system design • Provide path from UML to existing formal languages • Existing user base • Support Tools • Enable automated analyses of model • Simulation • Model checking

7. Additional Results • Provide precise semantics for diagrams • Establish consistency of mapping rules • Allow choice of formalization language

8. Background: Embedded Systems • Code difficult to design and analyze • Time-dependent • difficult to instrument • often highly concurrent • High level of robustness required • control real-world, physical processes

9. Background: UML • “General-purpose” visual modeling language • de facto Standard • (At least) nine different diagrams • Diagrams described by metamodels: • A graphical model that describes syntax of model • Therefore, nine different metamodels

10. Named association “type of” indicator Talks-to 1 0..1 multiplicities Contains aggregations of Class B Contains components UML Class Diagram Class A Class X Class A1 Class A2 Class A3 Class B

11. UML Metamodel • Metamodel defines UML syntax using class diagram notation. • Semantics not defined by metamodel • Note: Any language or diagram syntax can be defined with a metamodel

12. Example MetaModel Program 0..* Block Compound Simple Statement Statement

13. Specific diagram shows some aspect of the system being constructed Uses class diagram notation to describe diagram component relationships Metamodel - Diagram - System Relationship Metamodel UML Diagram Instance System Specifies aspect of Constrains syntax

14. Background: VHDL • IEEE standard language • Intended for abstract description of hardware • Uses multiple, concurrent, communicating processes • Communication through “signals” • Syntax is Ada-like, procedural in nature • Models can be “executed” in simulation.

15. Background: Promela (SPIN) • Promela is language for SPIN model checker • Simulation and model checking of concurrent systems • SPIN: commonly used in telecommunication domain • Developed by Bell Labs (now Lucent) • Protocol verification • Guarded Command Language + CSP + C • Collection of processes, channels, and variables

16. declarations Channel declaration Instantiation of “A_type” “initial” procedure Executed as one stmt Proctype instantiation Basic proctype Proctype declaration do-od loop Channel write if-fi block Channel read Background: Promela Example typdef A_type { int x; int y; bool unused; mtype vals; } chan queue=[3] of {mtype}; A_type A; mtype={on, off, none}; init { atomic {A.x = 1; A.y = 2} run abc() } proctype abc() { int I; do :: A.x > 1 -> A.y = A.y + 1; A.x = A.x + 1; od; queue!on; if :: queue?vals :: A.y > 4 -> goto skip1 fi} “structure” typedef Guarded statement

17. With the mapped objects This operation in this system with these objects (a & b) Does the “same thing” as this operation in this system Homomorphisms Preserve operations, hence structure and semantics

18. Describes instance Produces mapping Describes instance UML diagram Formal description of system Mapping Rules Metamodel mapping UML metamodel Formal language metamodel Homomorphism

19. Unified Class/Dynamic Metamodel Model Class related Dynamic related Behavior Class Relationships State Vertex Instance Variables Aggregation Generalization Transition Association Rest of dynamic model

20. Dynamic Model Portion of Unified Metamodel To Class Behavior Guard 1..* 0..1 1 1 0..1 State Vertex Transition 0..1 0..1 0..1 Pseudostate State ActionSequence 0..1 0..1 0..1 CompositeState SimpleState Event Start Join SignalEvent TimeEvent ChangeEvent Final History

21. h: Target Source h: A B R h: B’ A’ D’ R’ hasComp(A,C) h: C hasPart(A’,C’) h: C’ Example Metamodel Mapping

22. Promela Class Diagram Mapping Rules • Classes (objects) map to proctypes. • Relationships map to channels. • Instance variables map to global typdef structures.

23. Promela Dynamic Model Mapping Rules • Simple states map to blocks of Promela statements. • Transitions map to gotoandrun() • Composite states map to proctypes • Events map to channel writes/receives • Pseudo-states map to blocks of various Promela statements

24. SPIN Analyses • Random simulation • Exhaustive search of states • State transition system checked by temporal logic assertions • Often provides counter-examples (path to problem state) • “Easier” than theorem proving • Better than simulation when precise timing not required

25. Structure Ent/Arch Class proctype Relationship Port signature channels Labeled block of statements procedure State Composite State Ent/Arch proctype Channel assignment Write to signal Event Summary of Mappings VHDL Promela

26. Tool Support Analysis results UML HIL Spec* Analysis Tool* MINERVA Hydra Diagram reports Analysis reports

27. Architecture of Minerva Diagram reports Diagram in DoME format UML UML diagram editors HIL Plug-ins Visualization commands Analysis results (processed) Text processing scripts Analysis reports Analysis results (raw)

28. Smart Cruise Requirements Desired trail distance Safety zone Coast zone Closing zone About 400 ft - acquires target vehicle. Closing speed low enough to control. Starts coasting to match speed Maintain proper trail distance - speeds match Safe zone This is what we want Closing speed too high. Issues warnings to avoid this condition

29. Class - Context Diagram Target acquisition target loss distance System boundary Control Radar Warnings “set” Distance Car speed throttle control Car Car speed brakes Target Brakes Throttle Control

30. Smart Cruise Class Model • Target acquisition • target loss • distance to target Control Radar Car speed Car speed throttle control Car

31. High Level Radar Dynamic Model [target <= 400]^target-acquired Check distance [target > 400] Car-speed Get car speed Wait for ack Ack-from-control Turn-on Off Turn-off

32. Car Dynamic Model Set cruise speed car1 car3 Get-speed[real=set]^speed Get-speed[realset]/{adjust real speed}^speed Set-speed Supply speed to radar updatex updatespd Unset cruise speed Supply speed to control car4 car1 Get-speed^speed Unset speed dounset dogetspd

33. High Level Control Dynamic Model Wait for target Wait for “set” target set Ack from car [exceed bounds] Get speed and distance Check bounds Warning or Alarm [trailing] [closing] Maintain Trail position Closing on target

34. SPIN Analyses Performed • Random simulation • State reachability • State reachability with assertions • Progress loop analysis (cycle checks) • Model checking with temporal claim • Model checking with temporal claim and non-deterministic execution paths.

35. Use of Simulation • Check that model runs (does not deadlock) • Model appears to achieve basic requirements • Model not erratic (simulation is random) • Exercise common paths • Explore extremes for initial proper behavior • Basically, high level debugging strategy

36. State Reachability Analysis • Reachability is exhaustive (unlike simulation) • For common scenarios, • ensure state set correct and • exception states not entered • For exception scenarios, • ensure exception states entered

37. State Reachability for Normal Scenario (Establish target trail) = reached Wait for target Wait for “set” target set Ack from car [exceed bounds] Get speed and distance Check bounds Warning or Alarm control dynamic model [trailing] [closing] Maintain Trail position Only unreached state, as expected Closing on target

38. SPIN Progress Loop Analysis • Ensures no cycles of only unmarked states. • Reports cycles unless state(s) are marked. • If nothing marked, reports cycles • If known cycles are marked, reports unexpected cycles

39. Progress Cycle Analysis of Model • Liveness check: Ensure state cycle “follow target” established • Differs from reachability by ensuring cycle exists, not just state visit. • Safety check: Ensure no unexpected cycles encountered

40. Progress Loop Checks 1. Blue states reported as cycle when unmarked Wait for target Wait for “set” target set Ack from car Get speed and distance Check bounds Warning or Alarm shut off system [trailing] [closing] Maintain Trail position Closing on target None of these reported 2. After marked, no other cycles appeared (complement of first check)

41. Model Checking Tests • Car achieves trail position, and stays there. Three checks: • Once in idle, model never comes back • when target sent, ack replied • Remove ack to demonstrate check works • Brake application leads to return to idle state. • Revealed missed an event on transition

42. Hand Written Never Claim A never claim specifying that state idle is only entered once, at the start of execution. /* Verifies that at low enough closure speeds, the car comes up behind the target and stays there forever. If the trail loop is exited, we return to state idle */ 1: never 2: { /* wait until state idle is entered */ 3: do 4: :: skip 5: :: control[controlpid]@idle -> break 6: od; /* now wait until state idle is exited */ 7: do 8: :: skip 9: :: !(control[controlpid]@idle) -> break 10: od; /* and if we come back to state idle, it's an error */ 11: do 12: :: control[controlpid]@idle -> break 13: od }

43. Analysis Output From Hand-Written Never Claim warning: for p.o. reduction to be valid the never claim must be stutter-closed (never claims generated from LTL formulae are stutter-closed) (Spin Version 3.3.1 -- 11 July 1999) + Partial Order Reduction Full statespace search for: never-claim + assertion violations + (if within scope of claim) acceptance cycles + (fairness disabled) invalid endstates - (disabled by never-claim) State-vector 504 byte, depth reached 3114, errors: 0 6314 states, stored 2919 states, matched 9233 transitions (= stored+matched) 3445 atomic steps hash conflicts: 72 (resolved) (max size 2^18 states) 4.565 memory usage (Mbyte) No mention of failing claim or “acceptance cycles”. Implies claim succeeded.

44. SPIN Generated Never Claim for “p leads-to q” p leads-to q frequently used assertion for liveness never { /* !([](p -> <>q)) */ /* >>0,0<< */ T0_init: if :: (! ((q)) && (p)) -> goto accept_S4 :: (1) -> goto T0_init fi; accept_S4: if :: (! ((q))) -> goto T0_S4 fi; T0_S4: if :: (! ((q))) -> goto accept_S4 fi; accept_all: skip } p leads-to q which is the same as: Always(p implies eventually q)

45. Ensure target Never Missed Target acquired Control Radar acknowledgement Using: always(p implies eventually q) SPIN version for claim Never, not [always(p implies eventually q)] This check succeeded

46. Demonstrate Check Works Target acquired Control Radar acknowledgement Remove this message to force claim to fail This check failed (as expected)

47. Check Demonstration: target leads-to ackfailing never claim output warning: for p.o. reduction to be valid the never claim must be stutter-closed (never claims generated from LTL formulae are stutter-closed) pan: acceptance cycle (at depth 298) pan: wrote sc.v9.pr.trail (Spin Version 3.3.1 -- 11 July 1999) Warning: Search not completed + Partial Order Reduction Full statespace search for: never-claim + assertion violations + (if within scope of claim) acceptance cycles + (fairness disabled) invalid endstates - (disabled by never-claim) State-vector 500 byte, depth reached 299, errors: 1 134 states, stored (135 visited) 1 states, matched 136 transitions (= visited+matched) 32 atomic steps hash conflicts: 0 (resolved) (max size 2^18 states) Acceptance cycle in never claim. Implies claim has failed. Never claim is p leads-to q. p is target, q is acknowledgement.

48. Non-deterministic Paths(checking brake signal behavior) [tmode & x>400]^control.lost r3 [tmode & x<=400]^control.dist(x) Non-deterministic choice between these two transitions. Either is possible after x<=400 Matching guards [tmode & x<=400]^control.brakes New transition added for verification. Send brakes at random times.

49. Never Claim to Test Brakes Let p be defined as “brake signal in control’s queue ” Promela predicate control_q??[brakes] Let q be defined as “in state idle in object control” Promela predicate control[controlpid]@idle Use never claim generated for p leads-to q

50. First Test of Brake Signal Behavior <<<<<START OF CYCLE>>>>> 616: proc 0 (NEVER) line 471 "never" 616: proc - (:never:) line 471 "sc.v9.pr" (state 11) [(!((control[con trolpid]._p==idle)))] control_V.a = 15 control_V.xcoast = 3333 control_V.setspd = 1100 control_V.v = 200 control_V.tmin = 2 control_V.x1 = 3700 control_V.vc = 1100 control_V.x2 = 3500 control_V.vt = 900 control_V.z1 = 1620 control_V.z2 = 1800 control_V.xhit = 1333 control_V.tinc = 1 control_V.closing = 0 queue 2 (control_q): [carspeed][ackcar] radar_V.x = 3500 radar_V.tmode = 0 Claim failed with acceptance loop. This is a trace of the loop. This signal is blocking -- This one and stopping transition to idle result: deadlock