1 a general framework for formalizing object-oriented modeling techniques betty h. c. cheng software...

1

A General Framework for Formalizing Object-Oriented Modeling

TechniquesBetty 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

Bridge the Gap Between Informal and Formal Methods

Object-Oriented “Blueprints”

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

Ap

ply F

orm

aliza

tion

Fram

ew

ork

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

4

Overview

Introduction Background Formalization Framework Validation:

Tool Support Case Study

Related Work Conclusions and Future Investigations

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 A1 Class A2 Class A3

Class B

Class X

Contains components

Contains aggregationsof Class B

“type of”indicator

Named association

Talks-to1 0..1

multiplicities

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

SimpleStatement

CompoundStatement

Block0..*

14

Metamodel - Diagram - System Relationship

Constrainssyntax

Constrainssyntax

SystemSystemSpecifiesaspect of

Specifiesaspect of

MetamodelMetamodel

Uses class diagramnotation to describediagram componentrelationships

UML DiagramInstance

UML DiagramInstance

Specific diagram showssome aspect of the systembeing constructed

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.

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

“structure” typedef

Channel declaration

Basic proctype

do-od loop

if-fi block

Proctype instantiation

“initial” procedure

declarations

Instantiation of “A_type”

Executed as one stmt

Channelwrite

Channelread

Proctype declaration

Guardedstatement

20

General Formalization Framework

21

Homomorphisms

Preserve operations, hence structureand semantics

)()()( bhahbah

This operation in this systemwith these objects (a & b)

Does the “same thing” as this operationin this system

With the mapped objects

22

Metamodel mapping

UMLmetamodel

UMLmetamodel

Formal languagemetamodel

Formal languagemetamodel

UMLdiagram

UMLdiagram

Describes instance

Formal descriptionof system

Formal descriptionof system

Describes instance

Homomorphism

Mapping Rules

Producesmapping

23

Unified Class/Dynamic Metamodel

ModelModel

ClassClass RelationshipsRelationships

InstanceVariables

InstanceVariables AggregationAggregation GeneralizationGeneralization

AssociationAssociation

BehaviorBehavior

State VertexState Vertex

TransitionTransition

Rest of dynamic model

Class relatedDynamic related

24

Dynamic Model Portion of Unified Metamodel

BehaviorBehavior

State VertexState VertexTransitionTransition

GuardGuard

PseudostatePseudostate StateState

CompositeStateCompositeState SimpleStateSimpleState

ActionSequenceActionSequence

EventEvent

SignalEventSignalEvent TimeEventTimeEvent ChangeEventChangeEvent

StartStart

FinalFinal

JoinJoin

HistoryHistory

0..1

0..1 0..1

0..1

0..1

0..1

0..1

0..111

1..*

To Class

25

Example Metamodel Mapping

h:

h:

h:

h:

h:

AA BB

CC

R

hasComp(A,C)

Source

B’B’ A’A’

C’C’

D’D’

hasPart(A’,C’)

R’

Target

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

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

Ent/Arch proctype

Port signature channels

procedure Labeled blockof statements

Ent/Archproctype

Write to signalChannelassignment

Class

Relationship

State

CompositeState

Event

Structure

35

Tool Support

37

Tool Support

MINERVA HydraAnalysis

Tool*HIL

Analysis results

Diagramreports

Analysis reports

Spec*UML

38

Architecture of Minerva

UML

Diagram in DoME format

Diagram reports

Analysis reports

Visualizationcommands

HIL

Analysis results (raw)

Analysis results (processed)

UML diagrameditors Plug-ins

Text processingscripts

39

Hydra Translation Tool

HydraparserHydraparser

Implements mapping rulesfor specific language

Uses library and parser to implement rules

Modular performal language

Language Specific Class

Library

HIL

FormalSpecifications

Minerva Language Specific Class

Library

40

Industrial Case Study

42

Smart Cruise Requirements

Safety zone

Desired trail distance

Coast zone Closing zone

About 400 ft - acquires target vehicle. Closing speed low enough to control.

Starts coasting to match speed

Safe zoneMaintain proper trail distance - speeds match

Closing speed too high.

Issues warnings to avoid this condition

This is what we want

43

Class - Context Diagram

Control

Car

Radar

Target acquisitiontarget lossdistance

Car speedthrottle control Car speed

Warnings

Target

Distance

System boundary

Throttle Control

Brakes

“set”

brakes

44

Smart Cruise Class Model

Control Radar

Car

Car speed

Car speedthrottle control

•Target acquisition•target loss•distance to target

45

High Level Radar Dynamic Model

Get car speed

Check distance

Off

Wait forack

[target <= 400]^target-acquired

[target > 400]

Ack-from-control

Turn-off

Car-speed

Turn-on

46

car1

car1car4

car3

Get-speed[real=set]^speed

Get-speed[realset]/{adjust real speed}^speedSet-speed

Get-speed^speed

Unset speed

updatex updatespd

dogetspd dounset

Supply speed to radar

Supply speed to control

Set cruise speed

Car Dynamic Model

Unset cruise speed

47

High Level Control Dynamic Model

Get speedand

distance

Wait for “set”Wait for target

Warningor Alarm

Check bounds

Closing on target

Maintain Trail

position

settarget

[closing][trailing]

Ackfrom car

[exceed bounds]

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

Get speedand

distance

Wait for “set”Wait for target

Warningor Alarm

Check bounds

Closing on target

Maintain Trail

position

settarget

[closing][trailing]

Only unreachedstate, as expected

Ackfrom car

control dynamic

model

(Establish target trail)= reached

[exceed bounds]

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

Get speedand

distance

Wait for “set”Wait for target

Warningor Alarm

shut off systemCheck bounds

Closing on target

Maintain Trail

position

settarget

[closing][trailing]

1. Green states reported as cycle when unmarked

2. After marked, no other cycles appeared(complement of first check)

None ofthese reported

Ackfrom car

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

60

Ensure Target is Never MissedDemonstrate Check Works

Control Radar

Target acquired

acknowledgement

This check failed (as expected)

Remove this message to forceclaim to fail

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

Increasing interest fueled by:•The World-Wide Web.•Middleware technology (e.g., CORBA, DCOM, JavaBeans).•New network services and protocols.

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

Model Editing

SpecificationAnalysis

DesignProcessing

Testing/Simulation

IDA Models IDA Constraints IDA Interface Requirements

IDA ReuseRepository

IDA ExternalParameters

SpecificationsRefinedSpecifications

Code

FeedbackUser

Req

uire

men

ts

Test Cases

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…