A General Framework for Formalizing Object-Oriented Modeling Techniques

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 1 1

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

Bridge the Gap Between Informal and Formal Methods Informal specifications, • graphical models, • easy for humans to formulate, • may be inconsistent and incomplete. Apply Formalization Framework 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 3 3

Overview Introduction l Background/Related Work l Formalization Framework l Validation: l u u l Tool Support Case Study Conclusions and Future Investigations 5 5

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

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

Additional Results l Provide precise semantics for diagrams l Establish consistency of mapping rules l Allow choice of formalization language 8 8

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

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

UML Class Diagram Named association “type of” indicator Class A 1 Talks-to 0. . 1 Class X multiplicities Class A 1 Class A 2 Class A 3 Contains aggregations of Class B Contains components 11 11

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

Example Meta. Model Program 0. . * Compound Statement Block Simple Statement 13 13

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

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

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

Background: Promela Example declarations “initial” procedure Guarded statement Proctype declaration do-od loop if-fi block 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() } “structure” typedef Channel declaration Instantiation of “A_type” Executed as one stmt Proctype instantiation Basic 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 skip 1 fi} Channel read Channel write 18 18

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

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

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

Dynamic Model Portion of Unified Metamodel To Class Behavior Guard 1. . * 1 State Vertex 1 0. . 1 Transition 0. . 1 State 0. . 1 Pseudostate 0. . 1 Action. Sequence 0. . 1 Composite. State Start Final Simple. State Event Join History Signal. Event Time. Event Change. Event 22 22

Example Metamodel Mapping Target Source h: h: A R B h: B’ has. Comp(A, C) R’ A’ D’ h: C has. Part(A’, C’) h: C’ 23 23

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

Promela Dynamic Model Mapping Rules l Simple states map to blocks of Promela statements. Transitions map to goto and run() l Composite states map to proctypes l Events map to channel writes/receives l Pseudo-states map to blocks of various Promela statements l 30 30

SPIN Analyses l Random simulation l Exhaustive search of states u u u l 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 31 31

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

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

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

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 Safe zone Maintain proper trail distance - speeds match This is what we want Closing speed too high. Issues warnings to avoid this condition 38 38

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

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

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

$Car Dynamic Model Set cruise speed car 1 car 3 Get-speed[real=set]^speed Get-speed[real set]/{adjust real$

Car Dynamic Model Set cruise speed car 1 car 3 Get-speed[real=set]^speed Get-speed[real set]/{adjust real speed}^speed updatex Supply speed to radar Supply speed to control Set-speed updatespd Unset cruise speed car 4 car 1 Get-speed^speed Unset speed dogetspd dounset 42 42

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

SPIN Analyses Performed l Random simulation l State reachability with assertions l Progress loop analysis (cycle checks) l Model checking with temporal claim and nondeterministic execution paths. 44 44

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

State Reachability Analysis l Reachability is exhaustive (unlike simulation) l For common scenarios, ensure state set correct and u exception states not entered u l For exception scenarios, u ensure exception states entered 46 46

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

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

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

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

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

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 } 52 52

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 acceptance cycles invalid endstates + + (if within scope of claim) + (fairness disabled) - (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 No mention of failing claim hash conflicts: 72 (resolved) (max size 2^18 states) or “acceptance cycles”. 4. 565 memory usage (Mbyte) Implies claim succeeded. 53 53

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

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 55 55

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

Check Demonstration: target leads-to ack failing 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. v 9. pr. trail (Spin Version 3. 3. 1 -- 11 July 1999) Warning: Search not completed Acceptance cycle in never claim. + Partial Order Reduction Full statespace search for: never-claim assertion violations acceptance cycles invalid endstates Implies claim has failed. + + (if within scope of claim) + (fairness disabled) - (disabled by never-claim) State-vector 500 byte, depth reached 299, errors: 1 134 states, stored (135 visited) Never claim is p leads-to q. 1 states, matched 136 transitions (= visited+matched) p is target, 32 atomic steps q is acknowledgement. hash conflicts: 0 (resolved) (max size 2^18 states) 57 57

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

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 59 59

First Test of Brake Signal Behavior <<<<<START OF CYCLE>>>>> 616: proc 0 (NEVER) line 471 "never" 616: proc - (: never: ) line 471 "sc. v 9. 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. x 1 = 3700 control_V. vc = 1100 control_V. x 2 = 3500 control_V. vt = 900 This signal is blocking -control_V. z 1 = 1620 control_V. z 2 = 1800 This one and stopping control_V. xhit = 1333 transition to idle control_V. tinc = 1 control_V. closing = 0 result: deadlock 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. 60 60

Correcting Brake Behavior getspd calc Normal trail loop brakes Brake application path Analysis shows model stopped in this state. Had to add this event to pick up ackcar caroff ackcar To state idle Dist(x 1) lost target brakes carspeed(vc) (control_q=[carspeed][ackacr]) 61 61

Related Work l Object-Orientation and Embedded Systems l Formalization of UML l Formalization of OO Modeling Techniques 62 62

Embedded System Methodologies l Ad Hoc (frequently used in industry) l Structured methods - RTSA u u l Hybrid OO -- RTOOSA [Ellis] u l Still structured, semi-formal - little object use OO, non-UML (ROOM) [Selic, Gullekson] u l [Ward & Mellor, Hatley & Pirbhai] RTSA models semi-formal, uses top-down Formal, but unusual OO model OO, UML based [Douglass] u Semi-formal. No behavior verification 63 63

Formalization of UML Precise UML (p. UML) based UML on Z [Evans, Clarks, Bruel, France, Lano] u Attempts to provide direct manipulations of diagrams u But no dynamic behavior mapping u No way to verify behavior or properties, other than potential theorem prover 64 64

Other OO Formalizations l OCL shown to have problems u l l Fusion well-defined process, but informal semantics [Coleman, et al] TROLL formally defined, but no checkers or simulation capability u l [Mandel & Cengarle] [Jungclaus, Saake, Hartman, Sernadas] Formalized OMT with rules but no generic mapping framework [(Wang & Cheng), (Bourdeau & Cheng)] u Rules specific to LOTOS 65 65

Overview of Contributions l General framework for providing semantics. l Unified UML Class/Dynamic metamodel. l Mapping to VHDL and Promela. l Means to perform simulation and model checking from semi-formal diagrams. l Systematic process for developing OO graphical models for embedded systems. 66 66

Where does this all fit in Big Picture? 67 67

MERIDIAN: An Integrated Toolkit for Developing Interactive Distributed Applications l Examples: u u u On-board driver/pilot navigation systems. Computer-supported collaborative work environments. Distributed interactive simulation. Increasing interest fueled by: • The World-Wide Web. • Middleware technology (e. g. , CORBA, DCOM, Java. Beans). • New network services and protocols. 68 68

Meridian Research goals l Improve quality of IDAs. u u l Advance state of automated software-engineering (ASE) practice. u u l Better IDAs (reliable, maintainable, extensible). Better development (faster, cheaper). Incorporate ASE techniques into mainstream development. Apply various formal methods in a new domain. Identify end-to-end automation techniques that take advantage of multiple phases of development. 69 69

Meridian Practical goals l To have techniques adopted in practice: u u l Implications: u u l Must complement existing design methods and notations. Otherwise, acceptance must overcome stiff economic hurdles. Designers should not reformulate designs in a formal notation. Designers should not have to view the output of a formal analysis tool. We chose (UML) for representing IDA designs. 70 70

Meridian Vision IDA Models IDA Constraints IDA Interface Requirements Refined Specifications Requirements Specifications Model Editing User Specification Analysis Design Processing IDA Reuse Repository Code IDA External Parameters Testing/ Simulation Feedback Test Cases 71 71

Summary of Contributions l General framework for constructing mappings of diagrams to formal target languages u Framework enables use of rigorous techniques to establish completeness, consistency, and correctness of mapping rules. l A set of rules for generating VHDL and Promela specifications from UML l Enable behavior simulation and analysis on informal diagrams via their formal specifications l Systematic process for developing OO graphical models for embedded systems 72 72

Current and Future Research l Consider other UML Diagrams: u u Use Case: provide high-level user goals Interaction Diagrams (Sequence and Collaboration): model behavior of specific scenarios l Add temporal and real-time constraints l Explore modified UML semantics u Adapt semantics to application? 73 73

Current/Future Research l Mapping to SMV u Different temporal logic (CTL) u Different analysis capabilities (e. g. , fairness) l Explore the use of specification patterns to guide analysis capabilities l Domain-specific refinement of UML diagrams u Move closer towards implementation u Use of Design Patterns and Frameworks 74 74

Discussion… 75 75

END OF REGULAR SLIDES The rest are backup 76 76

Control dynamic model template target Wait for target set Wait for “set” Ack from car Get speed and distance Check bounds [trailing] Maintain Trail position Warning or Alarm [closing] Closing on target 78 78

Future Work: Extended Metamodel Model Use Cases Behavior Class Relationships Sequence Diagrams Scenarios Can easily add Use Cases to unified metamodel, and extend mapping to include Use Cases. 79 79

Example Static VHDL Skeleton structure for object A Skeleton structure for object D use std. textio. all; Primary association use std. textio. all; use work. easyio. all; use work. pk_A. all use work. pk_D. all Inherited association entity obj_A is entity obj_D is port(r 1: inout integer); end entity; architecture abstract of obj_A is architecture abstract of obj_D is shared variable var A : integer; begin end architecture; l 1: entity obj_C(abstract) port map(r 1=>r 1); Instantiation resulting from end architecture; aggregation in class model 80 80

Tunable Semantics To Fit Application Domain Mapping Options Semantic Property Message passing between objects Transition interleaving Eventless, guarded transitions (e. g. ) [a & b]^object. evt • Queued - any order • Queued FIFO • Non-Queued • Must Complete • Interleaved • Waits on guard, like “WHEN” • Hangs if guard false 81 81

Example entity for state D architecture abstract of cs_d is use std. textio. all; begin use work. easyio. all; -- body of composite state follows. . . use work. pk_top. all; entity cs_d is port(state: inout rs_st; State ‘bus’ to select state t 1: inout boolean; t 2: inout boolean; All relevant event variables t 3: inout boolean; t 4: inout boolean; Port signature external information t 5: inout boolean; to composite state. t 6: inout boolean; t 7: inout boolean; ins_cp 1: in st; Passes state status of cp 1 and cp 2 ins_cp 2: in st; instate: out st); Send our state value out end entity; 82 82

Example process for state D 2 S_d 2: process begin Guard entry into state wait until state=st’(d 2); say(“In state d 2”); Purpose of loop is to wait for guard loop wait until t 3 or t 4 Wait for transition events or t 1; if t 3 and g 1 then state <= st’(d 1), null after 1 fs; exit; elsif t 4 then Transition initiations state <= st’(join 1), null after 1 fs; exit; elsif t 1 then state <= st’(e), null after 1 fs; exit; end if; end loop; end process 83 83

Example Dynamic Model CP 1 H T 1 B T 2 A T 3 T 5 T 4 C F CP 2 D D 1 T 3[G 1] D 2 T 1 T 3 T 4 E 84 84

Example object “top” architecture abstract of obj_top is signal state : rs_st; signal ss_cp 1 : rs_st; signal ss_cp 2 : rs_st; Instantiation of composite state cp 1 signal ins_cp 1 : st; signal ins_cp 2 : st; from the object top level signal ins_d: st; begin l 2: entity cs_cp 1(abstract) port map(state=>ss_cp 1, t 1=>t 1, t 2=>t 2, t 3=>t 3, t 4=>t 4, t 5=>t 5, t 6=>t 6, t 7=>t 7, instate=>ins_cp 1, ins_cp 2=>ins_cp 2, ins_d=>ins_d); ss_cp 1 <= st’(cp 1), null after 1 fs when state=st’(cp 1) or state=st’(cp 2); Start concurrent state 13: entity cs_cp 2(abstract) port map(state=>ss_cp 2, t 1=>t 1, t 2=>t 2, t 3=>t 3, t 4=>t 4, t 5=>t 5, t 6=>t 6, t 7=>t 7, ins_cp 1=>ins_cp 1, instate=>ins_cp 2, ins_d=>ins_d); ss_cp 2<= st’(cp 2), null after 1 fs when state=st’(cp 1) or state=st’(cp 2); 85 85

Sample Class Model A Var A: integer C R 1 B D Maps to 86 86

Validation: Furnace Example 87 87

UML Dynamic Metamodel 88 88

The Problem Computer programs have become too large and complex to be encompassed within the human mind. Therefore: OR The job of a development method is to make it so method is to show people how programs can fit within our minds to discipline their work so 500 by using more powerful, mediocre programmers can flexible ideas. join together to produce a program that meets its Adapted from Simply Scheme specifications. by Harvey and Wright 89 89

VHDL Dynamic Metamodel 90 90

Furnace Dynamic Model 91 91

Mapping to Kripke Structure (these are Kripke structures) Then, And, (model and driving scenarios are separable) So, If Then, Is a temporal predicate testing a property, Is the validity of the property, and u is modular. 92 92

Application of Extended Model Clearly shows Use Cases and model are separable l Can generate function g with respect to u also: l Might provide insight into exact nature (and requirements) for h l 93 93

Design Process Data Flow Model Checking Requirements System Component Delineation Develop Use Cases Develop Context Model context delineation scenarios Develop Class Model class model Scenarios Develop Responsibility List Develop Use Case Scenarios Develop Sequence Charts responsibility list Write Dynamic Model class model Write dynamic model 94 94

Design Process Data Flow Develop Class Model Develop Use Case Scenarios Develop Sequence Charts Write Dynamic Model responsibilities Scenarios Develop Responsibility List Class model Formal Language Specs Simulation Hydra Model Checking UML Model 95 95

Ambiguous Semantics 1 Is F transition ever taken? How? A E F B [G] 96 96

Ambiguous Semantics 2 What happens when G is false after event E? A E B [G] Are we stuck here? 97 97

Ambiguous Semantics 3 How many threads are running in here? A B F J G C D E K H What does this mean? 98 98

Ambiguous Semantics 4 A B F J G C D E K H Does this component get started? 99 99