building verifiable software prototypes using coloured petri netsqualifying exam 1/39 june 17, 2005...
Post on 16-Dec-2015
220 Views
Preview:
TRANSCRIPT
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
1/39
Building VerifiableSoftware Prototypes
Using Coloured Petri Nets
Michael WestergaardDepartment of Computer Science
University of AarhusDenmark
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
2/39
Overview
• Example• Towards a New State-space Tool• Model-based Prototyping and Animation• Towards an Interchange Format for
Coloured Petri Nets
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
3/39
Example (1/2)
• 2 runners in a race, halfway throughthe race is a stand with water
• Either run) a runner runs to the drink stand,win) a runner wins the race, orlose) a runner loses the race
• Only one runner can win the race• In the beginning neither of the runners
have finished any laps
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
4/39
Example (2/2)
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
5/39
Example (2/2)
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
6/39
Example (2/2)
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
7/39
Example (2/2)
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
8/39
Example (2/2)
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
9/39
Towards a New State-space Tool
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
10/39
Analysis
• We want to check that our model contains no errors (e.g. that at most one runner can win)
• Generate the state space, a directed graph with states as nodes and transitions as edges
• The problem: The state space is large• Solution: Make the state space smaller,
store only parts of it, or represent the state space in a clever way
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
11/39
The Sweep-Line Method• We assume a progress
measure, , that assigns to each state a progress value, such thats->s’ => (s)≤ (s’)
• Here, we take (n,m,b)=n
• All states to be processed are in front of the sweep-line
• All new states are added in front of the sweep-line
• We do not need the states behind the sweep-line; they can safely be removed from memory progress
0 1 32
Not yet discovered state
Discovered but unprocessed state
Processed state
sweep-line
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
12/39
A CondensedRepresentation
• We want to represent the entire state space• A state of the system is (n,m,b) with
n,m{0…3} and b {u,d}• Only some (10) of the syntactically possible states
(4·4·2=32) are reachable• At least ceil(log(32))=5 bits are used to store each
state, although ceil(log(10))=4 bits would suffice• In realistic examples, the number of syntactically
possible states is much larger than the number of reachable states, so distinguishing only between reachable states yields a good reduction
• Alas, we first know the number of reachable states, when we have constructed the reachability graph
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
13/39
Neighbor List• We assume that we can
enumerate the transitions
• Assign to each reachable state a number, 0…R-1
•
Number of transitions
Transition
Destination state
State number
0
1
0
2
0
0
1
11
11
2
0 1
2 3
54
6
9
8
7
0 = run
1 = win
2 = lose
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
14/39
On-the-fly Construction of the Condensed Representation
State number
Number of transitions
New header:
Number of bits used to represent the successor states
Transition
Destination state
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
15/39
Experimental Results
• In the report, I present an architecture of a state-space tool
• A prototypical implementation of the described method has been made in the state-space tool presented in the report
• The implementation does not take into account the different sizes of the numbers, and encodes everything in a machine word
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
17/39
Experimental Results(Database Managers)
0.0
2.5
5.0
7.5
10.0
12.5
3 4 5 6 7 8 9 10
size/mb
Database Managers
0.00
0.50
1.00
1.50
2.00
2.50ratio
Full sizeCondensed sizeSize ratioTime ratio
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
18/39
Experimental Results(Dining Philosophers)
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
0 5 10 15 20
size/mb
Philosophers
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0ratio
Full sizeCondensed sizeSize ratioTime ratio
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
19/39
Model-based Prototyping and Animation
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
20/39
Need for Visualization
• While the modeling language is graphical, the model is difficult to grasp unless you know Coloured Petri nets or some similar formalism
• It would be nicer to see the model like this:
• The goal of this work is to make this possible
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
21/39
Model-driven Prototype Approach
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
22/39
Model-View-Controller
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
23/39
Model-View-Controller
Animation GUICPN model
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
24/39
Architecture
View ViewController +
Model
AnimationPrototype
GUI
Model-driven prototypePrototype
GUI
Final product
Real
implementation
Test
driver
Verification
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
25/39
Case-study: Interoperability Protocol
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
26/39
Towards an Interchange Format for Coloured Petri Nets
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
27/39
Benefits of being Able to Interchange Coloured Petri Nets
• Repository of models– Teaching– Benchmarks
• It is possible to build tools are able to construct models and other tools that analyze the models
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
28/39
Difficulties
• Labels are not just non-negativeintegers, but can range over anarbitrary domain – is “1`r(1)++1`r(2)”the same as “<r(1)>+1*<r(2)>”?
• High-level Petri nets (HLPN) often support elaborate composition mechanisms, which have to be dealt with – should we extend PNML to support hierarchical nets? (See the report)
Start
1`r(1)++1`r(2)
RUNNER
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
29/39
Start
1`r(1)++1`r(2)
RUNNER
• Take as example a net witha place named Start withdomain RUNNER andinitial marking one tokenwith value r(1) and onetoken with value r(2)
• We notice1) Three labels, the domain, the initial marking, and
the name2) The initial marking is rather complex, and several
reasonable concrete syntaxes can express it, e.g.• CPN Tools: 1`r(1)++1`r(2)• CPN-AMI: <r(1)> + 1*<r(2)>
Labels
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
30/39
Example• We would store the initial marking as follows
(using the concrete syntax of CPN Tools):<initialMarking> <text>1`r(1)++1`r(2)</text></initialMarking>
Advantage• Very simple approach; easy to implement and
understand
Disadvantage• Different tools use different syntaxes to express the
same– CPN Tools: 1`r(1)++1`r(2), or– CPN-AMI: <r(1)> + 1*<r(2)>.and this makes interchange difficult
Start
1`r(1)++1`r(2)
RUNNER
Labels – Solution 1:Store as Concrete Syntax
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
31/39
Labels – Solution 2:Store as Abstract Syntax Tree
Example• We would store the initial marking as follows:
<initialMarking> <multiset> <value cardinality=”1”><text>r(1)</text></value> <value cardinality=”1”><text>r(2)</text></value> </multiset></initialMarking>
Advantage• Eliminates differences in concrete syntax
Disadvantages• Difficult to make simple editors that do not completely
parse and check inscriptions• Cumbersome to add new features, as a new AST node has
to be defined
Start
1`r(1)++1`r(2)
RUNNER
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
32/39
Labels – Solution 3:Mix Abstract and Concrete Syntax
Example• We would allowing the initial marking to be
stored as either:<initialMarking> <text>1`r(1)++1`r(2)</text></initialMarking>
or<initialMarking> <multiset> <value cardinality=”1”><text>r(1)</text></value> <value cardinality=”1”><text>r(2)</text></value> </multiset></initialMarking>
Advantages• Tools can save as much or as little using abstract syntax
as desired – trade-off between interchangeability and simplicity
• New features can easily be incorporated by using concrete syntax until an appropriate AST node is defined
Start
1`r(1)++1`r(2)
RUNNER
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
33/39
Labels – Solution 3:Mix Abstract and Concrete Syntax
Added benefits• Allows an incremental transition to the
interchange format, as tool implementers can choose to save only some (parts of) labels as ASTs
• Allows the format to be used as primary storageformat, as incorrect (and therefore unparsable) inscriptions can be saved using concrete syntax
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
34/39
Conclusion and Future Plans
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
35/39
ConclusionState-space Analysis
• We have seen an efficient representation of reachability graphs, and how this representation can be traversed for analysis
• We have seen how the efficient representation can be calculated efficiently using the sweep-line method
• We have seen how the method performs on some examples – basically, the method performs well when the sweep-line method performs well, i.e. for systems with a clear notion of progress
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
36/39
ConclusionModel-based Prototyping
• We have seen that animation of formal models may be beneficial
• We have introduced the architecture of a tool to support animation of formal models
• The architecture is based on the Model-View-Controller design pattern
• By interchanging parts, the animation tool supports– Animation of models– Model-based prototyping– The final product– Verification
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
37/39
ConclusionInterchange Format
• We have shown 3 different ways to represent labels:1) using concrete syntax only,2) using abstract syntax only, and3) using a mixture of concrete and abstract syntax.
• We have argued that the 3rd way is the best, as it is more flexible and allows interchange between tools not sharing concrete syntax
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
38/39
Main ContributionsState-space• Design/implementation of new state-space tool• Design/implementation/test of new reduction
technique• Design/implementation of state-space analysis of
Bigraphical Reactive SystemsModel-based prototyping/animation• Design/implementation of animation tool
– Very flexible architecture
• Use of animation tool in case-studyInterchange of Coloured Petri nets• Mix of concrete and abstract syntax for labels• Translations from common composition mechanisms
to Modular PNML
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
39/39
Future Work
• Work on model-based prototyping and interchanging Coloured Petri nets is done
• I will concentrate on state-space analysis during part B– Benchmark the sweep-line method– Visit to Aalborg– Modal logic for (Coloured) Petri nets– Partial state spaces– Telebit project– ...
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
41/39
Labels – Solution 3:Mix Abstract and Concrete Syntax
Not a clear-cut separation• E. Kindler proposes in the April 2004
proposal for ISO/IEC 15909-2 a similarapproach to the representation labels
• Kindlers proposal requires that a label is stored either using concrete syntax or using abstract syntax
• Our proposal allows <initialMarking> <multiset> <value cardinality=”1”><text>r(1)</text></value> <value cardinality=”1”><text>r(1+1)</text></value> </multiset></initialMarking> which clearly is a multi set even if function application is not standardized
• Thus not having a clear-cut separation of abstract and concrete syntax makes it easy to simulate new AST nodes
June 17, 2005
Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam
42/39
Composition Constructs• A number of composition constructs
exist for high-level Petri nets:– Hierarchical nets– Fusion places– Synchronous channels– etc.
• Composition mechanisms can be represented by adding new labels or special nodes– Example: Fusion places can be implemented by
adding a label fusionGroup, which indicates to what fusion group the place belongs
• In the report, I present a translation to Modular PNML
top related