Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 1/39 June 17, 2005...

40
June 17, 2005 Building Verifiable Software Prototypes Using Coloured Petri Nets Qualifying Exam 1/39 Building Verifiable Software Prototypes Using Coloured Petri Nets Michael Westergaard Department of Computer Science University of Aarhus Denmark

Transcript of Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 1/39 June 17, 2005...

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