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 [email protected]www.cse.msu.edu/~chengb
88
Embed
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 [email protected] www.cse.msu.edu/~chengb. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
A General Framework for Formalizing Object-Oriented Modeling
TechniquesBetty H. C. Cheng
Software Engineering and Network Systems Laboratory
Instance variables map to global typdef structures.
30
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
31
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
32
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
33
Tool Support
MINERVA HydraAnalysis
Tool*HIL
Analysis results
Diagramreports
Analysis reports
Spec*UML
35
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
38
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
39
Class - Context Diagram
Control
Car
Radar
Target acquisitiontarget lossdistance
Car speedthrottle control Car speed
Warnings
Target
Distance
System boundary
Throttle Control
Brakes
“set”
brakes
40
Smart Cruise Class Model
Control Radar
Car
Car speed
Car speedthrottle control
•Target acquisition•target loss•distance to target
41
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
42
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
43
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]
44
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.
45
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
46
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
47
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]
48
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
49
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
50
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. Blue states reported as cycle when unmarked
2. After marked, no other cycles appeared(complement of first check)
None ofthese reported
Ackfrom car
51
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
52
Hand Written Never Claim
/* 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: never2: {/* wait until state idle is entered */3: do4: :: skip5: :: control[controlpid]@idle -> break6: od;/* now wait until state idle is exited */7: do8: :: skip9: :: !(control[controlpid]@idle) -> break10: od;/* and if we come back to state idle, it's an error */11: do12: :: control[controlpid]@idle -> break13: od}
A never claim specifying that state idle is only entered once, at the start of execution.
53
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)
This check succeededNever, not [always(p implies eventually q)]
SPIN version for claim
56
Demonstrate Check Works
Control Radar
Target acquired
acknowledgement
This check failed (as expected)
Remove this message to forceclaim to fail
57
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)
work environments. Distributed interactive simulation.
69
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.
70
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.
71
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
72
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
73
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?
74
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
Can easily add Use Casesto unified metamodel, and extend mapping to includeUse Cases.
80
Example Static VHDL
use std.textio.all;use work.easyio.all;use work.pk_A.allentity 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(r1=>r1);end architecture;
use std.textio.all;use work.easyio.all;use work.pk_D.allentity obj_D is port(r1: inout integer);end entity;architecture abstract of obj_D isbeginend architecture;
Skeleton structure for object A Skeleton structure for object D
Primary association
Inherited association
Instantiation resulting fromaggregation in class model
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;
architecture abstract of cs_d isbegin-- body of composite state follows...
Port signature external informationto composite state.
State ‘bus’ to select state
Passes state status of cp1 and cp2
Send our state value out
All relevant event variables
83
Example process for state D2
S_d2: processbegin wait until state=st’(d2); say(“In state d2”); loop wait until t3 or t4 or t1; if t3 and g1 then state <= st’(d1), null after 1 fs; exit; elsif t4 then state <= st’(join1), null after 1 fs; exit; elsif t1 then state <= st’(e), null after 1 fs; exit; end if; end loop;end process
Guard entry into state
Wait for transition events
Transition initiations
Purpose of loop is to wait for guard
84
Example Dynamic Model
A
D1
C
B
D2
E
H
F
T1
T2
T3T4
CP1
CP2
T3[G1]
T5
T4T3
T1 T2
D
85
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(state=>ss_cp1, t1=>t1, t2=>t2, t3=>t3, t4=>t4, t5=>t5, t6=>t6, t7=>t7, instate=>ins_cp1, ins_cp2=>ins_cp2, ins_d=>ins_d); ss_cp1 <= st’(cp1), null after 1 fs when state=st’(cp1) or state=st’(cp2); 13: entity cs_cp2(abstract) port map(state=>ss_cp2, t1=>t1, t2=>t2, t3=>t3, t4=>t4, t5=>t5, t6=>t6, t7=>t7, ins_cp1=>ins_cp1, instate=>ins=>ins_cp2, ins_d=>ins_d);ss_cp2<= st’(cp2), null after 1 fs when state=st’(cp1) or state=st’(cp2);
Instantiation of composite state cp1from the object top level
Start concurrent state
86
Sample Class Model
A
DC
BVar A:integer
R1
Maps to
87
Validation: Furnace Example
88
UML Dynamic Metamodel
89
The Problem
Computer programs have become too large and complex to be encompassed within the human mind. Therefore:
The job of a developmentmethod is to show people howto discipline their work so 500mediocre programmers canjoin together to produce aprogram that meets its specifications.
The job of a developmentmethod is to make it soprograms can fit within our mindsby using more powerful, flexible ideas.
OR
Adapted from Simply Schemeby Harvey and Wright
90
VHDL Dynamic Metamodel
91
Furnace Dynamic Model
92
Mapping to Kripke Structure
''')( uRmuRmh
)(')()( uhRmhuRmh
) fixeda (for then let muRmuggmh ''')(,)(
Pt
))(( ugPt
Cases Use withoutmodel unified thebe Letm
Cases Use be Letu
Then,
And,
(model and drivingscenarios are separable)
So,
If
(these are Kripke structures)
Is a temporal predicate testing a property,
Then, Is the validity of the property, and u is modular.
93
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
))(( guh
94
Design Process Data Flow
Develop UseCases
Develop ContextModel
Develop UseCase Scenarios
Develop ClassModel
DevelopResponsibility
List
Scenarios
Write dynamic model
scenarios
class model
System Component DelineationModel CheckingRequirements