A General Framework for Formalizing ObjectOriented 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_at_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

• Formal Specifications
• Automated Analysis
• Consistency, completeness
• Rapid Prototyping
• Behavior Simulation
• Design Transformations
• Automated Test Case generation
• - May be difficult to construct/modify

Informal specifications, graphical models,
easy for humans to formulate, - may be
inconsistent and incomplete.
4
Overview

• Introduction
• Background
• Formalization Framework
• Validation
• Tool Support
• Case Study
• Related Work
• 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
• Specific Goals
• 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
Domain Embedded Systems
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
Informal Modeling Notation
10
Background UML

• Unified Modeling Language
• General-purpose visual modeling language
• de facto Standard
• (At least) nine different diagrams
• use case, class, state, interaction (2),
  implementation (2), etc
• Diagrams described by metamodels
• A graphical model that describes syntax of model
• Therefore, nine different metamodels

11
UML Class Diagram
Class A
Class X
Class A1
Class A2
Class A3
Class B
12
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

13
Example Metamodel
Program
0..
Block
Simple
Compound
Statement
Statement
14
Metamodel - Diagram - System Relationship
System
Specifies aspect of
Constrains syntax
15
Target Formalization Languages
16
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.

17
BackgroundVHDL Structure
Static description of process interface
entity port (sig...)
entity port (sig)
architecture. begin process sig lt
value end process end
architecture. begin process end
process wait for sig end
One unit of execution containing
multiple processes
Dynamic description of entity behavior
18
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 part)
• Protocol verification
• Guarded Command Language CSP C
• Collection of processes, channels, and variables

19
Background Promela Example
typdef A_type int x int y bool unused mtype
vals chan queue3 of mtype A_type
A mtypeon, off, none init atomic A.x
1 A.y 2 run abc() proctype abc() int
I do A.x gt 1 -gt A.y A.y 1 A.x A.x
1 od queue!on if queue?vals A.y gt 4 -gt
goto skip1 fi
20
General Formalization Framework
21
Homomorphisms
Preserve operations, hence structure and semantics
22
Metamodel mapping
UML metamodel
Formal language metamodel
Homomorphism
23
Unified Class/Dynamic Metamodel
Model
Class related
Dynamic related
Class
Relationships
Behavior
State Vertex
Instance Variables
Aggregation
Generalization
Transition
Association
Rest of dynamic model
24
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
25
Example Metamodel Mapping
26
Introduction to Mapping Rules

• VHDL used for embedded systems
• VHDL contains timing notations
• Many commercial tools available
• Comprehensive simulation capability
• SPIN used in industry
• Spin provides model simulation and checking
• Concurrency is a feature of both

27
VHDL Class Diagram Mapping Rules

• Map static class structure to Ent/Arch structure
• Provide packages for VHDL syntactic details,
  instance variables
• Map class relationships to port signatures

28
VHDL Dynamic Diagram Rules

• Objects map to entity/architectures
• States map to processes
• each process dormant until state name on signal
• Transitions map to signal assignments
• Composite states map to entity/architectures
• Other pseudo-states map to special processes

29
VHDL Mapping Rules Summary
relationships
entity port (sig...)
architecture. begin process sig lt
value end process end
Class, composite state
Simple state
Transition/event mechanism
30
VHDL Analyses

• Widely understood by and available in embedded
  systems community
• Extensive simulation capability
• Signal tracing in some tools
• Good for timing dependent systems
• Good for hardware-coupled simulation (if hardware
  modeled in VHDL)

31
Promela Class Diagram Mapping Rules

• Classes (objects) map to proctypes.
• Relationships map to channels.
• Instance variables map to global typedef
  structures.

32
Promela Dynamic Model Mapping Rules

• Simple states map to blocks of Promela
  statements.
• Transitions map to goto and run()
• Composite states map to proctypes
• Events map to channel writes/receives
• Pseudo-states map to blocks of various Promela
  statements

33
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

34
Summary of Mappings
VHDL
Promela
35
Tool Support
36
High-Level Design Process Data Flow
Requirements
Develop Use case Context model
Develop Class Model
context
scenario-info
Develop Sequence Diagrams
class model
Develop Dynamic Model
sequence diagrams
refinements
Simulation Model checking
UML Diagrams
formal specs
Hydra
scenarios
37
Tool Support
Analysis results
UML
HIL
Spec
Analysis Tool
MINERVA
Hydra
Diagram reports
Analysis reports
38
Architecture of Minerva
Diagram reports
Diagram in DoME format
UML
HIL
UML diagram editors
Plug-ins
Visualization commands
Analysis results (processed)
Text processing scripts
Analysis reports
Analysis results (raw)
39
Hydra Translation Tool
Modular per formal language
Uses library and parser to implement rules
Language Specific Class Library
Minerva
Language Specific Class Library
Hydra parser
HIL
Formal Specifications
Implements mapping rules for specific language
40
Industrial Case Study
41
Case StudySmart Cruise Control

• Validate formalization and analyze diagrams
• Need simulation for initial testing
• Want to exercise model checking
• SPIN / Promela is target language
• Characteristics
• Multiple Objects (object communication)
• Concurrency (intra- and inter-object)

42
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
43
Class - Context Diagram
Target acquisition target loss distance
System boundary
Control
Radar
Warnings
set
Distance
Car speed throttle control
Car
Car speed
brakes
Target
Throttle Control
Brakes
44
Smart Cruise Class Model

• Target acquisition
• target loss
• distance to target

Control
Radar
Car speed
Car
Car speed throttle control
45
High Level Radar Dynamic Model
target lt 400target-acquired
Check distance
target gt 400
Car-speed
Get car speed
Wait for ack
Ack-from-control
Turn-on
Off
Turn-off
46
Car Dynamic Model
Set cruise speed
car1
car3
Get-speedrealsetspeed
Get-speedreal?set/adjust real speedspeed
Set-speed
Supply speed to radar
updatex
updatespd
Supply speed to control
Unset cruise speed
car4
car1
Get-speedspeed
Unset speed
dounset
dogetspd
47
High Level Control Dynamic Model
Wait for set
Wait for target
set
target
Ack from car
exceed bounds
Get speed and distance
Warning or Alarm
Check bounds
trailing
closing
Maintain Trail position
Closing on target
48
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.

49
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

50
State Reachability Analysis

• Reachability is exhaustive (unlike simulation)
• For common scenarios,
• ensure set of states is correct and
• exception states not entered
• For exception scenarios,
• ensure exception states entered

51
State Reachability for Normal Scenario
(Establish target trail)
reached
Wait for set
Wait for target
set
target
Ack from car
exceed bounds
Get speed and distance
Warning or Alarm
Check bounds
control dynamic model
trailing
closing
Maintain Trail position
Only unreached state, as expected
Closing on target
52
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

53
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

54
Progress Loop Checks
1. Green states reported as cycle when unmarked
Wait for set
Wait for target
set
target
Ack from car
Get speed and distance
Warning or Alarm shut off system
Check bounds
trailing
closing
Maintain Trail position
Closing on target
None of these reported
2. After marked, no other cycles
appeared (complement of first check)
55
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

56
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 controlcontrolpid_at_idle -gt
break 6 od / now wait until state idle is
exited / 7 do 8 skip 9
!(controlcontrolpid_at_idle) -gt break 10 od /
and if we come back to state idle, it's an error
/ 11 do 12 controlcontrolpid_at_idle -gt
break 13 od
57
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 ( storedmatched) 3445
atomic steps hash conflicts 72 (resolved) (max
size 218 states) 4.565 memory usage (Mbyte)
No mention of failing claim or acceptance
cycles. Implies claim succeeded.
58
SPIN Generated Never Claim for p leads-to q
p leads-to q frequently used assertion
for liveness
never / !((p -gt ltgtq)) / / gtgt0,0ltlt
/ T0_init if (! ((q)) (p)) -gt goto
accept_S4 (1) -gt goto T0_init fi accept_S4
if (! ((q))) -gt goto T0_S4 fi T0_S4 if
(! ((q))) -gt goto accept_S4 fi accept_all sk
ip
p leads-to q which is the same as
Always(p implies eventually q)
59
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
60
Ensure Target is Never MissedDemonstrate Check
Works
Target acquired
Control
Radar
acknowledgement
Remove this message to force claim to fail
This check failed (as expected)
61
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.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 ( visitedmatched) 32 atomic
steps hash conflicts 0 (resolved) (max size 218
states)
Acceptance cycle in never claim. Implies claim
has failed.
Never claim is p leads-to q. p is target, q is
acknowledgement.
62
Non-deterministic Paths(checking brake signal
behavior)
tmode xgt400control.lost
r3
tmode xlt400control.dist(x)
Non-deterministic choice between these two
transitions. Either is possible after xlt400
Matching guards
tmode xlt400control.brakes
New transition added for verification. Send
brakes at random times.
63
Never Claim to Test Brakes
Let p be defined as brake signal in controls
queue
control_q??brakes
Promela predicate
Let q be defined as in state idle in object
control
Promela predicate
controlcontrolpid_at_idle
Use never claim generated for p leads-to q
64
First Test of Brake Signal Behavior
ltltltltltSTART OF CYCLEgtgtgtgtgt 616 proc 0 (NEVER)
line 471 "never" 616 proc - (never) line
471 "sc.v9.pr" (state 11)
(!((controlcon trolpid._pidle)))
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) carspeedackcar
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
65
Correcting Brake Behavior
calc
getspd
Normal trail loop
brakes
Brake application path
caroff
ackcar
Analysis shows model stopped in this state.
To state idle
Dist(x1) lost target brakes carspeed(vc)
Had to add this event to pick up ackcar
(control_qcarspeedackacr)
66
Related Work

• Object-Orientation and Embedded Systems
• Formalization of UML
• Formalization of OO Modeling Techniques

67
Embedded System Methodologies

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

68
Formalization of UML

• Precise UML (pUML) based UML on Z
• Evans, Clarks, Bruel, France, Lano
• Attempts to provide direct manipulations of
  diagrams
• But no dynamic behavior mapping
• No way to verify behavior or properties, other
  than potential theorem prover
• Latella et al
• Formalized UML state diagram in terms of hybrid
  automata

69
Other OO Formalizations

• OCL shown to have problems
• Mandel Cengarle
• Fusion well-defined process, but informal
  semantics Coleman, et al
• TROLL formally defined, but no checkers or
  simulation capability
• Jungclaus, Saake, Hartman, Sernadas
• Formalized OMT with rules but no general mapping
  framework (Wang Cheng), (Bourdeau Cheng)
• Rules specific to LOTOS

70
Overview of Contributions

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

71
Where does this all fit in Big Picture?
72
Meridian Automating Development of IDAs

• PIs B. Cheng, L. Dillon, P. McKinley, K.
  Stirewalt
• Interactive Distributed Applications (IDAs)
• Examples
• On-board driver/pilot navigation systems.
• Computer-supported collaborative work
  environments.
• Distributed interactive simulation.

73
Meridian Research goals

• Improve quality of IDAs.
• Better IDAs (reliable, maintainable, extensible).
• Better development (faster, cheaper).
• Advance state of automated software-engineering
  (ASE) practice.
• 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.

74
Meridian Practical goals

• To have techniques adopted in practice
• Must complement existing design methods and
  notations.
• Otherwise, acceptance must overcome stiff
  economic hurdles.
• Implications
• 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.

75
Meridian Vision
Design Processing
Specification Analysis
Testing/ Simulation
Model Editing
76
Summary of Contributions

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

77
Current and Future Research

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

78
Current/Future Research

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

79
Discussion
80
END OF REGULAR SLIDES
The rest are backup
81
Build a Bridge
Automated formalization and integration of
the informal models can help properly bridge the
two sides

• Informal specifications,
• graphical models,
• easy for humans to
• formulate,
• may be inconsistent and
• incomplete.

• Objective
• formal specifications
• executable code
• that can be verified
• for correctness
• and completeness

82
Future Research/Investigations(continued 2)

• Code generation after analysis
• Just another mapping?
• Integrate GUI editor for diagrams
• Modify Hydra for diagram animation feedback
• Dynamic selection of Hydra language specific
  class library

83
Control dynamic model template
Wait for set
Wait for target
set
target
Ack from car
Get speed and distance
Warning or Alarm
Check bounds
trailing
closing
Maintain Trail position
Closing on target
84
Future WorkExtended Metamodel
Model
Use Cases
Class
Relationships
Behavior
Sequence Diagrams
Scenarios
Can easily add Use Cases to unified metamodel,
and extend mapping to include Use Cases.
85
Example Static VHDL
Skeleton structure for object A
Skeleton structure for object D
use std.textio.all use work.easyio.all use
work.pk_A.all entity obj_A is port(r1
inout integer) end entity architecture abstract
of obj_A is shared variable var A
integer begin l1 entity obj_C(abstract)
port map(r1gtr1) end architecture
Primary association
use std.textio.all use work.easyio.all use
work.pk_D.all entity obj_D is port(r1
inout integer) end entity architecture abstract
of obj_D is begin end architecture
Inherited association
Instantiation resulting from aggregation in class
model
86
Tunable SemanticsTo Fit Application Domain
Mapping Options
Semantic Property

• Queued - any order
• Queued FIFO
• Non-Queued

Message passing between objects
Transition inter- leaving

• Must Complete
• Interleaved

Eventless, guarded transitions (e.g.) a
bobject.evt

• Waits on guard, like WHEN
• Hangs if guard false

87
Example entity for state D
architecture abstract of cs_d is begin -- body
of composite state follows...
use std.textio.all use work.easyio.all use
work.pk_top.all entity cs_d is
port(state inout rs_st t1 inout
boolean t2 inout boolean
t3 inout boolean t4 inout
boolean t5 inout boolean
t6 inout boolean t7 inout
boolean ins_cp1 in st
ins_cp2 in st instate out
st) end entity
State bus to select state
All relevant event variables
Port signature external information to composite
state.
Passes state status of cp1 and cp2
Send our state value out
88
Example process for state D2
S_d2 process begin wait until
statest(d2) say(In state d2)
loop wait until t3
or t4 or t1
if t3 and g1 then state lt
st(d1), null after 1 fs
exit elsif t4 then
state lt st(join1), null after 1 fs
exit elsif t1 then
state lt st(e), null after 1
fs exit end
if end loop end process
Guard entry into state
Purpose of loop is to wait for guard
Wait for transition events
Transition initiations
89
Example Dynamic Model
CP1
H
B
T1
A
T2
T3
T5
C
F
T4
CP2
D
D1
D2
T3G1
T2
T1
T4
T3
E
90
Example object top
architecture abstract of obj_top is signal
state rs_st signal ss_cp1 rs_st
signal ss_cp2 rs_st signal ins_cp1
st signal ins_cp2 st signal
ins_d st begin l2 entity
cs_cp1(abstract) port
map(stategtss_cp1, t1gtt1, t2gtt2, t3gtt3,
t4gtt4, t5gtt5, t6gtt6, t7gtt7,
instategtins_cp1, ins_cp2gtins_cp2,
ins_dgtins_d) ss_cp1 lt st(cp1), null
after 1 fs when statest(cp1) or
statest(cp2) 13 entity
cs_cp2(abstract) port
map(stategtss_cp2, t1gtt1, t2gtt2, t3gtt3,
t4gtt4, t5gtt5, t6gtt6, t7gtt7,
ins_cp1gtins_cp1, instategtinsgtins_cp2,
ins_dgtins_d) ss_cp2lt st(cp2), null after
1 fs when statest(cp1) or statest(cp2)
Instantiation of composite state cp1 from the
object top level
Start concurrent state
91
Sample Class Model
A
B
R1
Var Ainteger
D
C
Maps to
92
Validation Furnace Example
93
UML Dynamic Metamodel
94
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 programs can fit within our minds by using
more powerful, flexible ideas.
The job of a development method is to show people
how to discipline their work so 500 mediocre
programmers can join together to produce
a program that meets its specifications.
Adapted from Simply Scheme by Harvey and Wright
95
VHDL Dynamic Metamodel
96
Furnace Dynamic Model
97
Mapping to Kripke Structure
(these are Kripke structures)
Then,
(model and driving scenarios are separable)
And,
So,
If
Is a temporal predicate testing a property,
Then,
Is the validity of the property, and u is
modular.
98
Application of Extended Model

• Clearly shows Use Cases and model are separable
• Can generate function g with respect to u also
• Might provide insight into exact nature (and
  requirements) for h

99
Design Process Data Flow
Model Checking
System Component Delineation
Requirements
Develop Use Cases
Develop Context Model
context delineation
scenarios
Develop Class Model
class model
Develop Use Case Scenarios
Develop Responsibility List
responsibility list
Develop Sequence Charts
class model
Write dynamic model
100
Design Process Data Flow
Develop Class Model
Develop Use Case Scenarios
Develop Sequence Charts
Develop Responsibility List
responsibilities
Write Dynamic Model
Class model
Model Checking
Simulation
Hydra
101
Ambiguous Semantics 1
Is F transition ever taken? How?
A
B
E
F
G
102
Ambiguous Semantics 2
What happens when G is false after event E?
G
A
B
E
Are we stuck here?
103
Ambiguous Semantics 3
How many threads are running in here?
F
A
B
J
G
D
C
K
H
E
What does this mean?
104
Ambiguous Semantics 4
F
A
B
J
G
D
C
K
H
E
Does this component get started?