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
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
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
Formal Methods:
• Well-defined language
• Set of rules for reasoning
Formal Specifications:
+ Automated Analysis
•Consistency, completeness
•Rapid Prototyping
•Behavior Simulation
+ Design Transformations
+ Automated Test Case generation
- May be difficult to construct/modify
3
Overview




Introduction
Background
Formalization Framework
Validation:




Tool Support
Case Study
Related Work
Conclusions and Future Investigations
4
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
6
Domain: Embedded Systems
7
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
8
Informal Modeling Notation
9
Background: UML
Unified Modeling Language

“General-purpose” visual modeling language


(At least) nine different diagrams


use case, class, state, interaction (2), implementation (2), etc
Diagrams described by metamodels:


de facto Standard
A graphical model that describes syntax of model
Therefore, nine different metamodels
10
UML Class Diagram
Named association
“type of”
indicator
Class A
Talks-to
1
0..1
Class X
multiplicities
Class A1
Class A2
Class A3
Contains aggregations
of Class B
Class B
Contains components
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..*
Compound
Statement
Block
Simple
Statement
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
Target Formalization
Languages
15
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.
16
Background: Promela
(SPIN)

Promela is language for SPIN model checker


SPIN: commonly used in telecommunication
domain




Simulation and model checking of concurrent systems
Developed by Bell Labs (now Lucent part)
Protocol verification
Guarded Command Language + CSP + C
Collection of processes, channels, and variables
18
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
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}
Channel
read
Channel
write
19
General Formalization
Framework
20
Homomorphisms
Preserve operations, hence structure
and semantics
With the mapped objects
h(a  b)  h(a )  h(b)
This operation in this system
with these objects (a & b)
Does the “same thing” as this operation
in this system
21
Metamodel mapping
UML
metamodel
Homomorphism
Describes
instance
UML
diagram
Formal language
metamodel
Describes
instance
Mapping Rules
Formal description
of system
22
Unified Class/Dynamic
Metamodel
Model
Class related
Dynamic related
Behavior
State Vertex
Class
Instance
Variables
Relationships
Aggregation
Generalization
Transition
Association
Rest of dynamic model
23
Dynamic Model Portion of
Unified Metamodel
To Class
Behavior
Guard
1..*
1
State Vertex
1
0..1
0..1
Transition
0..1
0..1
0..1
Pseudostate
State
ActionSequence
0..1
0..1
0..1
CompositeState
Start
Final
SimpleState
Event
Join
History
SignalEvent
TimeEvent
ChangeEvent
24
Example Metamodel
Mapping
Target
Source
h:
h:
A
R
B
h:
B’
hasComp(A,C)
R’
A’
D’
h:
C
hasPart(A’,C’)
h:
C’
25
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
26
Promela Class Diagram
Mapping Rules

Classes (objects) map to proctypes.

Relationships map to channels.

Instance variables map to global typedef
structures.
31
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
32
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
33
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
34
Tool Support
35
Tool Support
Analysis results
UML
MINERVA
Diagram
reports
HIL
Hydra
Spec*
Analysis
Tool*
Analysis
reports
37
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)
38
Hydra Translation Tool
Modular per
formal language
Uses library and parser
to implement rules
HIL
Minerva
Hydra
parser
Language
Language
Specific
Class
Specific
Class
Library
Library
Formal
Specifications
Implements mapping rules
for specific language
39
Industrial Case Study
40
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
42
Class - Context Diagram
Control
Target acquisition
target loss
distance
System boundary
Radar
Warnings
“set”
Distance
brakes
Car speed
throttle control
Car
Car speed
Target
Brakes
Throttle
Control
43
Smart Cruise Class Model
Control
•Target acquisition
•target loss
•distance to target
Radar
Car speed
Car speed
throttle control
Car
44
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
45
Car Dynamic Model
Set cruise speed
car1
car3
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
car4
car1
Get-speed^speed
Unset speed
dogetspd
dounset
46
High Level Control Dynamic
Model
target
Wait for target
Get speed
and
distance
set
Check bounds
Wait for “set”
[exceed
bounds]
Ack
from car
Warning
or Alarm
[trailing]
Maintain
Trail
position
[closing]
Closing on target
47
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 nondeterministic execution paths.
48
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
49
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
50
State Reachability for
Normal Scenario
(Establish target trail)
= reached
target
control
dynamic
model
Wait for target
Get speed
and
distance
set
Check bounds
Wait for “set”
[exceed
bounds]
Ack
from car
Warning
or Alarm
[trailing]
Maintain
Trail
position
[closing]
Only unreached
state, as expected
Closing on target
51
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

52
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
53
Progress Loop Checks
1. Green states reported as cycle when unmarked
target
Wait for target
set
Wait for “set”
Ack
from car
Get speed
and
distance
Check bounds
Warning
or Alarm
shut off system
[trailing]
Maintain
Trail
position
[closing]
Closing on target
None of
these reported
2. After marked, no other cycles appeared
(complement of first check)
54
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
55
Ensure Target is Never Missed
Demonstrate Check Works
Target acquired
Control
Radar
acknowledgement
Remove this message to force
claim to fail
This check failed (as expected)
60
Related Work

Object-Orientation and Embedded
Systems

Formalization of UML

Formalization of OO Modeling Techniques
66
Embedded System Methodologies

Ad Hoc (frequently used in industry)

Structured methods - RTSA



Hybrid OO -- RTOOSA [Ellis]


Still structured, semi-formal - little object use
OO, non-UML (ROOM) [Selic, Gullekson]


[Ward & Mellor, Hatley & Pirbhai]
RTSA models semi-formal, uses top-down
Formal, but unusual OO model
OO, UML based [Douglass]

Semi-formal. No behavior verification
67
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
68
Other OO Formalizations

OCL shown to have problems



Fusion well-defined process, but informal
semantics [Coleman, et al]
TROLL formally defined, but no checkers or
simulation capability


[Mandel & Cengarle]
[Jungclaus, Saake, Hartman, Sernadas]
Formalized OMT with rules but no general
mapping framework [(Wang & Cheng), (Bourdeau & Cheng)]

Rules specific to LOTOS
69
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.
70
Where does this all fit in Big
Picture?
71
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.
Increasing interest fueled by:
•The World-Wide Web.
•Middleware technology (e.g., CORBA, DCOM,
JavaBeans).
•New network services and protocols.
72
Meridian Research goals

Improve quality of IDAs.



Advance state of automated software-engineering (ASE)
practice.



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.
73
Meridian Practical goals

To have techniques adopted in practice:



Implications:



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.
74
Meridian Vision
IDA Models
IDA Constraints
IDA Interface
Requirements
Refined
Specifications
Requirements
Specifications
Model
Editing
Specification
Analysis
Design
Processing
IDA Reuse
Repository
IDA External
Parameters
Code
Testing/
Simulation
Feedback
User
Test Cases
75
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
76
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?
77
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
78
Discussion…
79