petri nets - mcmaster university · 2017. 3. 8. · petri net tools • graphical editor •...

PETRI NETSPRESENTED BYJUSTIN ROTH

Friday, March 11, 2011

OUTLINE• INTRODUCTION

• SIMPLE EXAMPLE

• LANGUAGE OF PETRI NETS

• PROPERTIES OF PETRI NETS

•MORE ADVANCED EXAMPLE

• ADVANTAGES OF PETRI NETS

•QUESTIONS

• PN TOOLS

• VARIATIONS ON PNFriday, March 11, 2011

INTRODUCTION

•Discovery by Carl Adam Petri at the age of 13 for the purpose of describing chemical reactions.

• Later formalized in his PHD

• Petri Nets have huge application scope

• Feel free to ask questions


SIMPLE EXAMPLE

• http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/trafficlight1.swf [2]


http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/trafficlight1.swf




LANGUAGE• Symbols

squarecirclearrowdot


LANGUAGE

• Symbols

• Places P={P1,P2,,...Pn)

• Transitions T = {T1,T2,...Tn}

• Arcs A={(Px,Ty),(Ty,Px)} Forall 0<x<#places 0<y<#transitions

• Token u = {u1(P),u2(P),...un(P)}


LANGUAGE

Places to Transitions Transition to Places

•Arcs can be between places and transitions or transitions and place•Never between places and places or transitions and transitions

t1


LANGUAGE• Functions

Fire(transition, input_p1...m, output_p 1...n, )HasToken(place) AddToken (place) RemoveToken (place)

arity = m+n+1arity = 1arity = 1arity = 1


LANGUAGE• Functions

Fire(transition, input_place 1...n, output_place 1...m)

if HasToken(input_place 1...n)AddToken(output_place 1...m)

HasToken(place)

AddToken (place)

RemoveToken (place)


LANGUAGE• Relators

input_transitions(place)

output_ transitions(place)

input_places(transition)

out_places(transition)


LANGUAGE•Other representation

• Vector (input + output)

[6]


PROPERTIES OF PETRI NETS• Sequential

• Synchronization

•Merging


PROPERTIES OF PETRI NETS• Concurrency

• Conflict


MORE ADVANCED EXAMPLE

• Concurrency http://cs.adelaide.edu.au/~esser/forkjoin.html [3]

• Assembly Line http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/assembly.swf [4]

• Invariant http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/trafficlight2_PI.swf [5]


http://cs.adelaide.edu.au/~esser/forkjoin.html


http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/assembly.swf




http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/trafficlight2_PI.swf




ADVANTAGES OF PETRI NETS

• Elegance of design

•Not implementation based

• Power tools

• Formal method

•Many proofs and theorems

• Visual learning\thinking

• Simplicity allows for huge application scope


PETRI NET TOOLS

• Graphical editor

• Interchange file format

• Simplification

• Fast simulation

• Automated transition and invariant calculations

• Support for extensions to Petri nets


VARIATIONS ON PETRI NETS

• Coloured petri nets (places have unique colour)

• Fuzzi petri nets (if A & if B then C)

• Timed nets (tmax & tmin for firing)

•Object oriented Petri Nets (modularity, reusability, maintainability)

• Stochastic Petri Nets (probability of firing)


QUESTIONS ?


REFERENCES• [1] http://www.scholarpedia.org/article/Petri_net

• [2] http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/trafficlight1.swf

• [3] http://cs.adelaide.edu.au/~esser/forkjoin.html

• [4] http://www.informatik.uni-hamburg.de/TGI/PetriNets/introductions/aalst/assembly.swf

• [5] http://www.informatik.uni-hamburg.de/TGI/PetriNets/f

• [6]http://en.wikipedia.org/wiki/Petri_netFriday, March 11, 2011

http://www.scholarpedia.org/article/Petri_net

http://www.scholarpedia.org/article/Petri_net















http://en.wikipedia.org/wiki/Petri_net

http://en.wikipedia.org/wiki/Petri_net

The TLA+ Specification LanguageTemporal Logic of Actions

Mohammed Alabbad and Lucas Beyak

McMaster University

March 29th, 2011

Mohammed and Lucas (McMaster) The TLA+ Specification Language March 29th, 2011 1 / 33

Outline

1 Introduction

2 Mathematical Foundations

3 Specifying in TLA+

4 Model Checking Tool - TLC

5 Language Assessment

6 Extensions

7 Conclusion


Introduction

TLA+ was designed by Leslie Lamport (currently working forMicrosoft Research)

Lamport’s research has laid the foundation for the theory ofdistributed systems

Lamport designed TLA+ in order to formally describe and reasonabout distributed algorithms


Introductory Example

Example (General Specification)SomeSpec , Init ∧�[Next]v ∧ L


TLA - Temporal Logic of Actions

The logic of time has its origins in philosophy and linguistics.

Temporal logic offered a framework for describing safety and livenessproperties of reactive systems.

Linear-time temporal logic includes the theory TLA


Transition Formulas - Syntax

Transition formulas describe states and state transitions.

They are ordinary formula of untyped first-order logic, plus moreconventions and notations.

The signature is: (LF ,LP ,V)LF Function symbolsLP Predicate symbolsV set of variables; VF flexible variables and VR rigid variables.VF ′ the set of primed flexible variablesVE the union V ∪ VF ′


Transition Formulas - Syntax - Continued

Example (Action (transition predicate))x ′ = x + 1

Example (State predicate)y = x + 1

Constant Formulas: are transition formulas whose free variables arerigid variables.

Transition formula E’ obtained from state formula E by replacing v byv’.


Transition Formulas - Semantics

Interpretation I defines a universe |I|

State; s : VF → |I|, t : VF ′ → |I|

Valuation; ξ : VR → |I|

Combined valuation; αs,t,ξ for the variables in VE

Semantics of a transition formula E written [[E ]]I,ξs,t

Transition predicate A; valid vs. satisfiable.


Transition Formulas - Semantics - Continued

Example (Action)[[x ′ = x + 1]]ξs,t , [[x ′]]t = [[x ]]s + 1

Example (State Formula)[[y = x + 1]]ξs , [[y ]]s = [[x ]]s + 1


Transition Formulas - Semantics - Continued

Definition (ENABLED)[[ENABLED A]]s , ∃t : [[A]]s,t

Definition (Stuttering)[A]t , A ∨ (t ′ = t)

Definition (Necessity)〈A〉t , A ∧ ¬(t ′ = t)


Temporal Formulas - Syntax

Temporal formulas to describe behaviours (sequences of states)

Definition (Temporal Formulas)F , P

| ¬F |F ∧ F |F ∨ F | . . .| �F| �[A]t where A is an action and t is a state function| ∃(x | x ∈ VR : F )| ∃(v | v ∈ VF : F )


Temporal Formulas - Semantics

Temporal formulas are evaluated with respect toσ = s0s1 . . . of states si : VF → |I| and valuation ξ : VR → |I|

Definition[[P]]I,ξσ = [[P]]I,ξσ0

The semantic of the Boolean operators

[[�F ]]I,ξσ = t iff [[F ]]I,ξσ|i= t for all i ∈ N

[[�[A]t ]]I,ξσ = t iff for all i ∈ N, either [[t]]I,ξσi= [[t]]I,ξσi+1

or [[A]]I,ξσi ,σi+1= t

[[∃ x : F ]]I,ξσ = t iff [[F ]]I,ησ = t for some valuation η : VR → |I| such thatη(y) = ξ(y) for all y ∈ VR\{x}


Temporal Formulas - Derived temporal formulas

Definition

�F always F♦F eventually F ¬�¬F♦〈A〉t eventually angle A sub t ¬�[¬A]tF G F leads to G �(F ⇒ ♦G)�♦F infinitely often♦�F always from some time onward


Temporal Formulas - Fairness

Fairness conditions assert that an action should eventually happen ifit is often enabled.

Definition (Weak fairness)WFt(A) , �(�ENABLED〈A〉t =⇒ ♦〈A〉t)

Definition (Strong fairness)SFt(A) , �(�♦ENABLED〈A〉t =⇒ ♦〈A〉t)


Building TLA+ from TLA

TLA is defined using predicate logic and an arbitrary interpretation

TLA+ “instantiates” the generic definition of TLA with the ZFC(Zermelo-Fraenkel set theory with choice) interpretation of first-orderlogic

Using a standard interpretation ensures unambiguous specifications

Every TLA+ value is a set

TLA+ introduces a module hierarchy, allowing declaration ofparameters and operators


TLA+ - Operators

Boolean operatorsChoose operatorConditionalsLet/In constructSet theory operatorsFunctionsRecordsTuplesStringsNumbers


TLA+ - Operators - Choose operator

Definition (Interpretation of a term CHOOSE x : P)[[CHOOSE x : P]]ξs,t , ε({d | [[P]]αs,t,ξ[d/x ] = t})

x ∈ VE is a variable and P is an action

Occurrences of x in CHOOSE x : P are bound

The TLA+ CHOOSE operator is analogous to mathematician’sHilbert’s choice operator

Example (Real number division)a/b , CHOOSE c ∈ Real : a = b ∗ c


TLA+ - Operators - Set theory operators

Definition (Enumerable sets){e1, ..., en} , CHOOSE S : ∀(x | : x ∈ S ≡ ∃(i | (1 ≤ i)∧ (i ≤ n) : x = ei))

Definition (Basic set-theoretic operators)UNION S , CHOOSE M : ∀(x | : x ∈ M ≡ ∃(T | T ∈ S : x ∈ T ))S ∪ T , UNION{S,T}S ⊆ T , ∀(x | : x ∈ S ⇒ x ∈ T )SUBSET S , CHOOSE M : ∀(x | : x ∈ M ≡ x ⊆ S)


TLA+ - Operators - Functions

The application of a function f to an expression e is written as f [e]

[x ∈ S 7→ e] denotes a function with a domain S that maps anyx ∈ S to e

The above is the TLA+ syntax for a lambda expression λx ∈ S : e

Example (Anonymous function)[n ∈ Nat 7→ 1/(n + 1)]

Example (Named function - factorial)factorial [n ∈ Nat] , IF n = 0 THEN 1 ELSE n ∗ factorial [n − 1]


TLA+ - Operators - Functions and Tuples

Definition (Function Update)[f EXCEPT! [t] = u] , [x ∈ DOMAIN f 7→ IF x = t THEN u ELSE f [x ]]

Tuples are represented as functions

Definition (Tuple)〈t1, ..., tn〉 , [i ∈ {j ∈ Nat : (1 ≤ j) ∧ (j ≤ n)} 7→ ei ]

i does not occur in any of the expressions ej

The update operation can be applied to tuples


Properties and Specifications

In TLA+ there is no formal distinction between properties and systemspecifications, both are represented using temporal formulas

Example (General Specification)SomeSpec , Init ∧�[Next]v ∧ L

Init is a state predicate to represent the initial condition

Next is an action that represents a next-state relation

L is a conjunction of formulas WFv (A) or SFv (A) that assert fairnessassumptions


Refinement

First a system is specified using a high level of abstraction

A series of intermediate models introduce details

Refinements must preserve system properties

Correctness properties can be proven early, and do not need to bereproved in a later refinement


Refinement - Continued

Definition (Refinement)A TLA formula C , refines an abstract specification A⇔∀(F |F is a formula : (A⇒ F )⇒ (C ⇒ F ))⇔C ⇒ A

Implementation is implication

C will typically contain transitions that are transparent to A(transitions that act on state variables not present in A)

Concept of stuttering steps is essential here


Composition of Specifications

A system that is composed of specifications A and B must satisfyboth A and B

Composition is conjunction

State transition of A will be the stuttering step of B and vice versa

If some synchronization is required, both A and B will have anon-stuttering state transition


Invariants

Invariants characterize the set of states that the system reaches.They are the basic form of safety properties.

Definition (INV1)I ∧ [N]t ⇒ I ′

I ∧�[N]t ⇒ �I

Definition (INV)Init ⇒ I I ∧ [Next]t ⇒ I ′ I ⇒ J

Init ∧�[Next]t ⇒ �J


Step Simulation

To prove the refinement between two TLA specifications.

Definition (TLA21)I ∧ I ′ ∧ [M]t ⇒ [N]u�I ∧�[M]t ⇒ �[N]u


Liveness Properties

Liveness properties assert that something good eventually happens

The following inference rule proves a “leads-to” formula for a weakfairness assumption

Definition (WF1)I ∧ I ′ ∧ P ∧ [N]t ⇒ P ′ ∨ Q′

I ∧ I ′ ∧ P ∧ 〈N ∧ A〉t ⇒ Q′

I ∧ P ⇒ ENABLED〈A〉t�I ∧�[N]t ∧WFt(A)⇒ (P Q)


Illustrative Example


Model Checking Tool - TLC

To find errors in a specification, properties that should hold must beverified

By default, TLC check’s a specification for deadlock

The goal in using TLC is NOT to verify a specification is correct, it isto find errors

TLC generates behaviors that satisfy a specification

The next-state relation can be computed when given values to thespecification’s constant parameters


TLC - Example


Usefullness and Limitations

UsefullnessAllows one to start abstractly and add details while retaining thetruthfullness of properties (refinement)

Provides the means to simply design concurrent, usually distributed,systems (composition)

LimitationsExpressing some algorithmic details might be difficult

May be impossible to discover a violation of a liveness property with afinite model


Extension - PlusCal (formerly +CAL)

Lamport designed an algorithm language PlusCal

PlusCal introduces standard programming constructsassignmentsequencingloopsconditionalsnon-deterministic choiceprocedures

PlusCal algorithms are translated to TLA+ specifications, and can bechecked with TLC


Conclusion

“A distributed system is one in which the failure of a computer youdidn’t even know existed can render your own computer unusable”- Leslie Lamport

Designing (correct) distributed systems is hard

The formalisms offered by TLA+ assists us in the difficult task ofanalyzing formal models

Expressiveness of TLA+ is helpful when new classes of systems areintroduced (real-time systems, for example)


Z Language, Z Logic and Its Applications

Ehsan Mohammad Kazemi

Department of Computing and SoftwareMcMaster University

April 8th, 2011

Ehsan M.Kazemi (McMaster) Z Language, Z Logic and Its Applications April 8th, 2011 1 / 40

Outline

1 Introduction to Z Language

2 Z Specification

3 Review of An Example in Z

4 Z Specification Language from A Logical Perspective

5 The Specification of Logic ZC

6 Conservative Extensions

7 More Advanced Materials

8 Language Assessment

9 Conclusion


Introduction

Z language is a model-based specification language making it easierto write mathematical description

Inspired by Jean-Raymond Abrial’s seminal work(1970’s), developedthrough the 1980’s in collaborative projects between Oxford andindustrial partners(IBM)

Is a set of conventions for presenting mathematical text, chosen tomake it more convenient

Based on Zermelo-Fraenkel set theory and first order predicate logic

Not a programming language and is intended to faciliate formalverification

Decompose specification into small pieces (Schemas)


Z Language

The main steps for the specification:

Create a model of the system using discrete mathematical structures(primarily sets), together with predicate logic

Using logic showing that how the model will be changed for eachoperation that the system can perform

The process is repeated to gradually refine the specification


Basic elements

There are three basic elements in Z:

SetsCollection of elements in which no sense of ordering of elements isinvolvedIn Z, there are some pre-defined set types such as Z and NUser may specify own set typesConvention is to use upper case italic letters for set types [AIRCRAFT]


Basic elements(continue)

Set of operationsSet membership operator ∈Cardinality(Prefix the set name with the # symbol)Equality =Subset ⊂ or ⊆Powerset PUnion ∪Intersection ∩Difference \Definition =̂Cross ×Function →Domain domRange ran


Basic elements(continue)

Logic: The operations and relations in a system are usually expressedusing the standard operators of

Not ¬And ∧Or ∨Implies ⇒Equivalence (if and only if) ⇔For all (universal quantifier) ∀There exists (existential quantifier) ∃There exists exactly one ∃1Precondition preSuch that |


Z specification

A Z description consists of a collection of structures called schemas.

A schema describes the static (states, invariant relationships) anddynamic (operations, relationships between input and output, statechanges that can happen) features of a system

The schema consists of:

Schema nameGroup of variable declarations(Declaration part)List of predicates that constrain values of variables(Predicate part)

NameDeclarations

Predicates


Schema Declaration part

Contains local declarations (types and variables)

Can import other types by listing their names

Status indicates if state space is changed or not

NameDeclaration{status}State space nameVariable DeclarationFunction Declaration

PredicatesOptional pre − conditionOptional post − condition


Schema Predicate part

Includes statements about the entities defined in the declaration partof the schema

These statements are assumed to be implicitly connected by a logicaland

Other logical connectives can be used explicitly in compoundstatements

NameDeclaration{status}State space nameVariable DeclarationFunction Declaration

PredicatesOptional pre − conditionOptional post − condition


Z specification(continue)

Creating New Schemas from Existing SchemasThe prefix ∆ (Delta) is used to create a new schema from an existingone

Is obtained by combining the before and after specifications of a state.Describes state space changes after operation

The prefix Ξ (Xi) is also used to create a new schema from anexisting one.

Is also obtained by combining the before and after specifications of astate.However, this schema is used to define specifications of operations thatdo not change the state space of a structure.


Z specification sections

Z specification consists of four sections:

A Z Specification begins with a list of given sets, data types, andconstants

State definition (shown as Z schema)

Operations (shown as Z schema)

Initial state: when the system is first turned on


Z specification example

Example (A class manager’s assistant)A specification that provides support for a class manaegr to admitstudents to a class, and to record who has done the midweek exercises.

The given sets for the specification:The notion of a student is represented by a given set Student [Student]The user of the system needs to specify a maximum class size| Size: NThe type definition for the responses to the operations is asResponse ::= success | notenrolled | nocert | cert | alreadyenrolled |alreadytested | noroom


Z specification example

State definition and related operations for the specification:

Classenrolled , tested : P Student

#enrolled ≤ sizetested ⊆ enrolled

The operations required are enrolling, testing, leaving and finallyenquiring a student respectively shown in Enrolok, Testok, Leaveokand Enquire schemas.

Initial states for the specification:ClassInit =̂ [ Class’ | enrolled’ = ∅ ]


Z specification example(continue)

Enrolling a student:

Enrolok∆Classs? : Studentr ! : Response

s? /∈ enrolled#enrolled ≤ sizeenrolled ′ = enrolled ∪ {s?}tested ′ = testedr ! = success

Note: The input names end with a question(?) mark and output namesend with an exclamation(!) mark



Testing a student:

Testok∆Classs? : Studentr ! : Response

s? ∈ enrolleds? /∈ testedtested ′ = tested ∪ {s?}enrolled ′ = enrolledr ! = success



Discharging a student:

Leaveok∆Classs? : Studentr ! : Response

s? ∈ enrolledenrolled ′ = enrolled \ {s?}((s? ∈ tested ∧ tested ′ = tested \ {s?} ∧ r ! = cert)∨ (s? /∈ tested ∧ tested ′ = tested ∧ r ! = nocert))


Z specification example(continue)Enquiring a student:

EnquireΞClasss? : Studentr ! : Response

((s? /∈ enrolled ∧ r ! = notenrolled)∨ (s? ∈ (enroled \ tested) ∧ r ! = alreadyenrolled)∨ (s? ∈ tetsed ∧ r ! = alreadytested))

NoRoomΞClassr ! : Response

#enrolled = sizer ! = noroom


Z In A Logical Perspective

The work is structured into three parts:

The least formal and most accessible one which explores initialconsiderations concerning the formalization of Vernacular Zconcerning Schema types and Bindings

A more formally presented account of Z logic that discuss how thatlogic may be extended by means of a series of conservative extensions

Contains the most advanced material by looking beyond Z as aspecification langauge and ZC as a logic for reasoning aboutspecification


Z Schemas and Bindings

At the heart of Z is the schema. Schemas are usuallay used in two ways:Describing the state space of a system

Describing operations which the system may be perform

Example (A jug of water)The informal state space is a jug of water of capacity 250ml having acurrent volume and a current temperature which can be written as:

JugVolume : Ntemp : N

Volume ≤ 250temp ≤ 100


Z Schemas and BindingsBindings:

The states which comprise a schema are called bindings

Each binding belonging to a schema is a legitimate state of the system

The schema describes a state space, that is, a set of legitimatesystem states

A schema does not describe a particular stateBindings are written like:

(| volume V n, temp V m |)

where n,m ∈ NPossiblity to extract the values assoiciated with observations from bindingsis called binding selection, like

(| volume V n, temp V m |).volume = n


Schema and Schema Type

Here is an unordered sequence of typed(indicated by superscripts)observations(the Zi )

[... zTii ...]

Then schemas are either schema sets:

[... zi : CP Tii ...]

or atomic schemas

[S | P]

where the Ci are sets, S is a schema and P is a predicate.



Since schemas are sets of bindings, so the logic of schema can be obtainedfrom the logic of sets and bindings. Hence, in ZC , for sets, we have

P[z/t][ {}+ ]

t ∈ {z | P}

t ∈ {z | P}[ {}− ]

P[z/t]

Note that ZC is strongly typed, and these typed set comprehensionsrepresent no technical difficulties.



And for bindings, ZC has

[V=0 ]

(| ...zi V ti ... |).zi = ti

[V=1 ]

(| ...zi V t.zi ... |) = t [...zTii ...]

The logical rules for schemas flow the following ZC definitions:

[... zi : Ci ...] =df {x | ... ∧ x .zi ∈ Ci ∧ ...}

and

[S | P] =df {z ∈ S | z .P}


Rules for Schema Derived in ZC

Rules for schema sets in ZC are:

... ti ∈ Ci ...

(| ...zi V ti ... |) ∈ [...zi : Ci ...]([]+)

t ∈ [...zi : Ci ...]

t.zi ∈ Ci([]−)

Rules for atomic schemas in ZC are:

t ∈ S t.Pt ∈ [S | P]

(S+)t ∈ [S | P]

t ∈ S (S−0 )t ∈ [S | P]

t.P (S−1 )


Schema Algebra and Filtered Bindings

Time to consider an operation from the schema calculus: SchemaConjunction (∧).

Filtering: the type restriction of a binding. We write as z � T

Roughly, the bindings we expect in the schema S0 ∧ S1 are thosecommon to S0 and S1.

But the story is more complicated: the types of S0 and S1 (say T0and T1) need not necessarily be the same.

In order for S0 ∧ S1 to be well-defined, these types must agree ontheir overlap.


Schema Algebra and Filtered Bindings

We write T0 g T1 (in the meta-theory) for the compatible type union(it is not defined if they are incompatible) of T0 and T1.

Note that when the types are disjoint, this is effectively a unionoperation.

Hence, the schema conjunction definition in ZC will be

SPT00 ∧ SPT1

1 =df {zT0gT1 | z � T0 ∈ S0 ∧ z � T1 ∈ S1}

t ∈ S0 t ∈ S1t ∈ S0 ∧ S1

(S+∧ )

t ∈ S0 ∧ S1t ∈ S0

(S−∧0)t ∈ S0 ∧ S1

t ∈ S1(S−∧1)


The Types of ZC Logic

ZC is an extension of higher order logic with the addition of the schematypes.We begin with the language of types

T ::= Υ | PT | T × T | [...zT ...]

whereTypes of the form Υ are the names of free types

Types of the form [...zT ...] are called schema types

No observation {...zi ...} may occur more than once in such a type

The symbols �,f,gand− denote the relation and operations.


The Types of ZC Logic(continue)

Since these relations and operations are defined only for schematypes, so any use of them is well defined only when the types inquestion are schema types.

Schema type union imposes an additional constraint, since it is onlydefined when its schema type arguments are compatible

Types are indicated by superscripting and can be omitted wheneverpossible


The Terms of ZC LogicFirst we have variables, bindings, pairs and their projections

tT ::= xT | t [...zT ...].z | tT×T1 .1 | tT0×T .2tT0×T1 ::= (tT0 , tT1)

t [...zT ...] ::= (| ...z V tT ... |)

Second, we have the filtered (restricted) bindings

tT0 ::= tT1 � T0 where T0 � T1

Third, the values of free type are

tΥ ::= ... tΥij ...

Finally, We have sets

tPT ::= {zT | P}


The Formulae of ZC Logic

The formulae of ZC delineate a typed bounded predicate logic:

P ::= false | tT = tT | tT ∈ CPT | ¬P | P ∨ P | ∃ zT ∈ CPT • P

The judgements of ZC have the form Γ ` P, where Γ is a set offormulae

The logic of ZC is classical, so the remaining logical operations areavailable by definition

A crucial observation is the unicity of types: every term of ZC has aunique type

A term of type T always belong to the carrier set of T: tT ∈ T


The Formulae of ZC Logic(example)

Example (Specialisation for N)As an example of the rules for free types, we can give the followingspecialisation for N,

zero ∈ Nn ∈ N

succ n ∈ Nn ∈ N

zero 6= succ n

succ n = succ mn = m

P[n/zero] m ∈ N, P[n/m] ` P[n/succ/m]

n ∈ N ` P


Conservative ExtensionsThe base logic ZC contains only rudimentary features of Z. We havealready indicated in overview how ZC can host more advanced features bymeans of conservative extensions

Schema Sets and Atomic Schemas:

SPT ::= [...zi : CPTii ...] | [SPT | P]

Schema Disjunction:

SPT00 ∨ SPT1

1 =df {zT0gT1 | z ∈ S0 ∨ z ∈ S1}

Schema Conjunction:

SPT00 ∧ SPT1

1 =df {zT0gT1 | z ∈ S0 ∧ z ∈ S1}

Schema Negation:

¬SPT =df {zT | z /∈ S}


Conservative Extensions(continue)

Schema Inclusion: Interpreting the separation of declarations in aschema as schema conjunction, like

[z : T ; S | P] is just [z : T ∧ S | P]

Schema Composition: considering operation schemas.Those schemas whose type is PT where T has the form T in g T out′

T in contains declarations of all before observations and T out′ containsdeclarations of all after observations

Note that the types T in and T out′ are always disjoint.

UP(T in0 gT out′

0 )0

o9 UP(T in

1 gT out′1 )

1 =df {(z0 ∗ z ′1)T in0 gT out′

1 |∃ yT out′

0 • z0 ∗ y ′ ∈ U0 ∧ y ∗ z ′1 ∈ U1}


Conservative Extensions(continue)

Schema Preconditions: The precondition of an operation schema isessentially the domain of the partial relation that the schema denotes.Let T in � V , then

pre U xV =df ∃ z ∈ U • x =T in z

In vernacular Z, the precondition is a schema(a set of bindings)


Equational Logic

It is interesting to note that the fundamental relation of Z is, in fact,equality.

In the absence of a logic, the informal explanation of schemaoperators has often been given in terms of certain equalities, like

[T0 | P0] ∧ [T1 | P1] = [T0 g T1 | P0 ∧ P1]

and

¬[T | P] = [T | ¬P]


Operation Refinment

One of the refinements that can be formalized in the core theory ZC isS-Refinement. There are two basic observations regarding the propertiesone expect in a refinement:

Postconditions do not weaken

Preconditions do not strengthenwritten as U0 ws U1 and is given by the definition which leads directly tothe following rules,

pre U1 z ` pre U0 z pre U1 z0, z0 ∗ z ′1 ∈ U0 ` z0 ∗ z ′1 ∈ U1U0 ws U1

(w+s )

U0 ws U1 pre U1tpre U0 t (w−s0)

U0 ws U1 pre U1 t0 t0 ∗ t ′1 ∈ U0t0 ∗ t ′1 ∈ U1

(w−s1)


Assesment

Makes use of a graphical construction known as a schema which canbe understood fairly easily

Easy to find faults in Z specification and Can prove correctness

Capability to express modular specifications using schema operators incomparison with B

Only high-school math needed to read Z

Decreases development time

In Model based Specification, system state is not hidden like it is inalgebraic specification

State changes are straight forward to define


Conclusion

Z is a general purpose specification language

VDM and Z are the most widely used model-based specificationlanguages

Z may be used to produce readable specifications and has beendesigned to be read by humans rather than computers.

Large specifications are manageable in Z

Z can be used to specify a more special purpose language whichmaybe designed to handle concurrency.


References

Dines Bjorner, Martin Henson, Logics of Specification Languages

J. B. Wordsworth, Software Development with Z


Abstract State Machine

Morteza Yousef Sanati

McMaster University

March 8, 2011

Morteza Yousef Sanati (2011) Abstract State Machine March 8, 2011 1 / 27

1 ASM Basic Idea and the Definition

2 Some Concepts

3 Example: Set Extension

4 Sequential Small-Step ASM Programs

5 Extensions

6 ASM Verification and Validation

7 ASM Advantages

8 ASM vs Others

9 Applications

10 Tools

11 Conclusion


ASM Basic Idea and the Definition

ASM is a technique for describing algorithms or, in general, discretesystems. In the basic form ASM is a set of conditional statements.

ASM can be considered as a formal basis for pseudocode.

Conventional computation concentrates on the transformation ofsymbols, not dwelling too deeply on what they stand for.


Some Important Concepts

Σ-SignitureΣ = (f1, ..., fl , a1, ..., al)

Type ≡ set of arities of functions(n1, ..., nn)

Ground Term ≡ Closed Formula

Σ-StructureS = (U, φ1, ..., φn)

Homomorphism and Isomorphismh : R → S

h(ψi (u1, ..., uni )) = φi (h(u1), ..., h(uni ))

A Point

Basic version of ASM have no variables.


Example: Set Extension

Formal Definition of Problem

Augment is a binary function to extend a set by an item:Augment(M,m) =def M ∪ {m}

P: beginX = +(X , x)X = +(X , y)

end.P has finite set Σ = < {X , x , y ,+}, {(X , 0), (x , 0), (y , 0), (+, 2)} >S =< dom(S),X S = M, xS = m, yS = n,+S = Augment >

S′

=< dom(S′),X S

′= M ∪ {m, n}, xS

′= m, yS

′= n,+S

′=

Augment >


Sequential Small-Step ASM Programs

Simple Assignment Statements

Sf :=t−−−→ S

′

fS ′ = tS

Example

Σ = (c , f , 0, 1)S = (N, 0, suc)

Sc:=f (c)−−−−−→ S

′

cS = 0, fS = suc → cS ′ = 1, fS ′ = suc



Updates of Functions

Sf (t1,...,tn):=t−−−−−−−−→ S

′

fS ′ (t1, ..., tn) = tSfS ′ (u1, ..., un) = fS(u1, ..., un)

(u1, ..., un) 6= (t1, ..., tn)⇒ ∀(g ∈ Σ|g 6= f : gS ′ = gS)

Example

Sf (c):=c−−−−−→ S

′

cS = 0⇒ fS ′ (0) = fS ′ (cS) = 0 ∧ fS = 0 + 1 = 1∀i ≥ 1, fS ′ (i) = fS(i) = suc(i) = i + 1



Assignment Consistencyf (t1, ..., fn) := t and f (u1, ..., un) := u are consistent at a state S:(u1S , ..., unS) 6= (t1S , ..., tnS)⇒ tS = uS

Generally, a set Z of assignment statements is consistent at a state Sif the elements of Z are pairwise consistent at S.



Formal Definition of AssignmentZ is set of Assignments i.e. have f (t1, ..., tn) := tu = (t1S , ..., tnS)v = tS

Assignment

fS ′ (u) =

{v if Z at S updates fS(u) by v

fS(u) Otherwise



Guards and Conditional Assignment Statements

if α then r∀t, u ∈ Σ, t = u is a guard over Σ andif α and β are guards over Σ, so are α ∧ β and ¬αTrue and False have been definedαS ∈ {True,False}r is f (t1, ..., tn) := t and f ∈ Σ and t1, .., tn, t ∈ TΣ


Sequential Small-Step ASM Programs and Sematics

A sequential small-step ASM program P over a signature Σ is a set ofconditional assignment statements over Σ

Formal Definition

For each Σ− structure S , the program P defines a successor structure S′,

usually written P(S), by a step

SP−→ S

′

To Define S′, let Z =def { r | ”if α then r” and αS = True}



Some Definitions

Static Constants and Functions

Never updated.As program Input

Constant Symbols as ”Program Variables ”

Non-static constantsUpdated at Initial State

Output Variables

Never on right hand side of assignment.


Sequential Large-Step ASM Algorithms

An Example: Node Reachability in a Graph

∀(x , y |(x , y) ∈ E ∧ R(x) ∧ ¬R(y) : extend R by y)

The amount of work executed in one step is unbounded.

Small-Step does not have quantifier


Sequential Large-Step ASM Algorithms

Quantified Varibales

Node Reachability in a Graph with Large-Step

∀(x , y |(x , y) ∈ E ∧ R(x) ∧ ¬R(y) : R(y) := True)

Large-Step ASM

An algorithm is large-step not only if the amount of change fails to bebounded. A step is also large if the number of items involved isbounded.


Non-deterministic Semantics

In a state where more than one assignment statement’s guard isevaluated as true, one may select one or a subset of them forexecution.

The Operator ”choose ”.

Example: Choose Operator

choose i,j in I with i< j and a[i]>a[j]do in-parallel

a[i]:=a[j]a[j]:=a[i]


Distributed ASM Programs

A distributed ASM is just a non-empty, finite set of ASM programs,all over the same signature Σ.

The programs are called components of the distributed ASM, andevery Σ− structure forms a state of the distributed ASM.

The components may be executed concurrently if they involve storeswith separate locations.


Some Other Extensions

Turbo ASMAtomicity of steps

Reactive ASMEnvironment updates constant or function

Hybrid ASM

Table ASM

Dynamic Systems

Large Typed ASM

Message-Passing Interacting ASM


ASM Verification and Validation

Code reviews

Using domain’s terms to describe system.Domain experts don’t have to be expert programmersMinimum the notational overhead in order to make easier analysis

Various forms of testing

Variety of tools available for such purposes (e.g. AsmL, XASM)Ability to test at almost any point in the development process

Formal proof

By hand in some situationsBy Theorem prover or Model checker


ASM Advantages

Precision

Use classical mathematical structures

Scalability (layers of abstraction)

Proving properties about systems also can be made easier

Generality

Wide variety of domains: sequential, parallel, and distributed systems

Faithfulness

Domain’s terms and conceptsMinimum of notational coding


ASM Advantages Cont.

Understandability

ASM programs use an extremely simple syntaxReadable even by novices as a form of pseudocode

Executability

Execute the specification directlyAllows one to test for errors in the specification


ASM Vs. VDM, Z

Executability

Methods such as VDM, Z, or process algebras are not directlyexecutable.

Faithfulness

Use of the terms and concepts of the problem domain immediately,with a minimum of notational coding.


What are ASMs good for?

Any situation where you need a precise, non-ambiguous way tospecify a computer system, either software or hardware.

Program managers, developers, and testers can all use an ASMtool(e.g. AsmL) specification to achieve a single, unifiedunderstanding.

Can execute it!

You wish you could have played with your design before coding.

By exploring your design, you can answer the following questions:Does it do everything you intended it to? How do the featuresinteract? Are there any unintended behaviors?


Applications

UML> Statechart and Activity Diagrams

Java> Bytecode Verification

Compiler Correctness> Test Suite Generation

Security> Abstract Encryption

Real-Time Systems> Group Membership Protocol

Software Engineering> Runtime Verification of .NET

Distributed Systems> Grid Computing

...


Tools

AsmL: The Abstract State Machine LanguageAsmL is an advanced ASM-based language taking advantage of the .NET

runtime. It is an executable specification language based on the theory of

Abstract State Machines, developed originally by Yuri Gurevich. AsmL

supports classes and interfaces in the same way as C# or Java do. In fact all

.NET structuring mechanisms are supported: enumerations, delegates,

methods, events, properties and exceptions. As AsmL is primarily a

specification language, it naturally support structures and features, like sets,

sequences, maps, pattern matching, bounded quantification, and set

comprehension.

CoreASMThe CoreASM project focuses on the design of a lean executable ASM

(Abstract State Machines) language, in combination with a supporting tool

environment for high-level design, experimental validation and formal

verification of abstract system models. This tool can be installed as a plugin

for Eclipse IDE.


Tools

XASM: The Open Source ASM LanguageXasm is an implementation of sequential ASMs focusing on the generation

of efficient executable programs simulating the run of the specified ASM.

Time ASM ToolsetThe Timed Abstract State Machine (TASM) toolset is a graphical

integrated development environment for real-time system engineering. The

toolset implements the features of the TASM language. The non-functional

properties that can be specified in TASM are time and resource

consumption. The toolset provides facilities to write, edit, simulate, and

analyze TASM specification. The simulation of specifications can be

achieved in a step-by-step fashion, with graphical depictions of time and

resource consumption.


Tools

ASM WorkbenckThe ASM Workbench provides a framework for the systematic development

of ASM tools. It is based on a specification language called ASM-SL (ASM

based Specification Language), which includes a typed version of the

language of Abstract State Machines.

Michigan Interpreter

ASM Gofer

AsmM: Abstract State Machine Meta model

ATGT: ASM Tests Generation Tool


Conclusion

The ASM method offers no fool-proof button-pushing, completelymechanical design and verification procedure, but it directly supportsthe concepts like ”building models for change”, stepwise detailingthem to compilable code and maintaining models and code in acost-effective and reliable way.


CafeOBJ Logic

Jamil Ahmed Khan

Outline

IntroductionBasic Specifcation Module declaration Signatures AxiomsReductionTransitionsBehavioural SpecifcationConclusion

Introduction

-CafeOBJ is developed under the direction of Prof. Kokichi Futatsugi

- Developed in Japan in Japan Advanced Inst of Science and Technology (JAIST)

-CafeOBJ is mainly for system specification, formal verification of specifications, rapid prototyping, and even programming

-CafeOBJ is a modern successor of OBJ.

Equational Specification - Equational specification and programming is inherited from OBJ

- It constitutes the basis of the language

- CafeOBJ is executable (by term rewriting).

Introduction

Behavioural Specification

-Provides a generalization of ordinary algebraic specification.

-It characterizes how objects (and systems) behave, not how they are implemented

- Achieved by using specification with hidden sorts and a behavioural concept of satisfaction.

-Is reflected at the execution level by the concept of behavioural rewriting

Introduction


CafeOBJ directly supports behavioural specification and its proof theory through special language constructs, such as

-hidden sorts (for states of systems),

-behavioural operations (for direct “actions” and “observations” on states of systems),

-behavioural coherence declarations for non-behavioural operations

-behavioural axioms (stating behavioural satisfaction).

The main behavioural proof method is based on coinduction principle.

Introduction

Preorder Algebra

-The logic of CafeOBJ transition is called Preorder algebra.

-Provides proof support for reasoning about the existence of transitions between states

-A preordered algebra is a set P together with a preorder “⊑” on P and a collection of operations on P (e.g. o) which are compatible with the preorder

-For all p, q ∈P, if p ⊑q, then o(p) ⊑o(q) (preorder-preserving)orFor all p, q ∈P, if p ⊑q, then o(q) ⊑o(p) (preorder-reversing)

Introduction

Hidden Algebra

-Hidden Algebra is designed to handle changeable "abstract machines"

-The hidden algebra approach takes as basic the notion of behavioural abstraction.

-Hidden algebra uses sorts in two distinct ways:

• visible sorts are used for data values• hidden sorts are used for states.

Introduction

Order-sorted Algebra

-Allows subtypes

-The main concept is all items of one sort are necessarily also items of some other sort

Example: Every natural number is an integer and every integer is a rational: Natural ≤ Integer ≤ Rational

Introduction

CafeOBJ Cube

Introduction

Basic Specification

mod!SIMPLE-NAT { [ Nat ]

op 0 : -> Natop s_ : Nat -> Natop _+_ : Nat Nat -> Natvars M N : Nateq N + (s M) = s(N + M) .eq N + 0 = N .

}

Signature

Axiom

Module Declaration

Basic Specification

Module Declaration

mod <module_name> {<module_element> * }-A module name is an arbitrary character string.

-A module element is either

(1) import declaration

(2) sort declaration (with ordering)

(3) operator declaration

(4) record declaration

(5) variable declaration

(6) equation declaration

(7) transition declaration

Basic Specification

Signatures

-The operation name

-Position of the argument defined by '_'

-The arity of the operation, which is a string of (declared) sorts. an empty string (as in the case of 0); such operations

are called constants only one sort (such as “Nat” in the case of s ), several sorts (such as “Nat Nat” in the case of + );

*Sorts may also be different.

-The sort of the operation, which is a declared sort.

Basic Specification

Operator Declaration

op <operator_symbol> : <list_of_sort_names>-> <sort_name>

op _+_ : Nat Nat -> Nat

ops (_+_) (_*_) : Nat Nat -> Nat

which means the same as


op _*_ : Nat Nat -> Nat

Operator overloading


op _+_ : NzNat Nat -> NzNat

Basic Specification

Behavioural Operator Declaration

bop <operator_symbol> : <list_of_sort_names>-> <sort_name>*[ Account ]*

bop deposit : Account Nat -> Account bop withdraw : Account Nat -> Account bop balance : Account -> Nat

The arity of behavioural operator contain at least one hidden sort.

Predicate Declaration

pred <operator_symbol> : <list_of_sort_names>pred _<_ : Nat Nat

has the same meaning as op _<_ : Nat Nat -> Bool

Basic Specification

Variable Declaration

var<variable_name> : <sort_name> vars<list_of_variable_names> : <sort_name>

-var N : Nat-vars A B C : Nat

Basic Specification

Equation Declaration

Unconditional:

eq[ <label> ] <term> = <term> .

Var X : Nateq X + 0 = X .

Conditional:

ceq[ <label> ] <term> = <term> if <boolean_term> .

op max : Nat Nat -> Natceq max(M:Nat, N:Nat) = M if (M > N) or (M == N).

Basic Specification

Behavioural Equation Declaration

beq [label ] term “=” term “.”bceq [label ] term “=” term if boolean term “.”

Transition Declarationtrans [ <label>] <term> => <term> . ctrans [<label> ] <term> => <term> if <boolean_term> .

module CHOICE {[ State ] ops a b : -> State op _|_ : State State -> State vars X Y : State

trans X | Y => X . trans X | Y => Y . }

Basic Specification

Equational Inference and Reduction

mod* GROUP {[ G ]op 0 : -> Gop + : G G -> G {assoc}op - : G -> GVar X : Geq 0 + X = X .eq (-X) + X = 0 .

}

In CafeOBJ reduction is done by rewriting of equations.

Reduction

Equational Inference and Reduction

GROUP> reduce (--a) + (-a) + a + (-a) .

gives the result 0 : G after three rewriting.

This reduction process can be visualized as follows:

(−−a) + (−a) + a + (−a)├ (−−a) + 0 + (−a) First rewrite, 2nd Axiom(−−a) + 0 + (−a)├ (−−a) + (−a) Second rewrite, 1st Axiom(−−a) + (−a)├ 0 Third rewrite, 2nd Axiom

A term can be at most rewritten to its normal form.

Reduction

mod* GROUP { [ G ] op 0 : -> G op + : G G -> G {assoc} op - : G -> G

var X : G eq 0 + X = X . eq (-X) + X = 0 .}

Transitions

Algorithm Specification

Rewriting rules can be used to specify algorithms by showing transitions between various states of the algorithm.

A crude version of bubble sort algorithm specification.

mod! SORTING-NAT {protecting(STRG-NAT)vars N N' : Natctrans (N . N') => (N' . N) if N' < N .

}

Transition

Transitions

Algorithm Verification

All reasoning about algorithm properties is done as the usual datatypereasoning.

s ==> s’ if and only if there exists at least one transition betweenthe state s and the state s’

SORTING-NAT> red (2 . 3 . 1) ==> (1 . 2 . 3) .gives true, while,SORTING-NAT> red (2 . 2 . 1) ==> (1 . 2 . 3) .gives false.

Transition


Sorts (types):• hidden , for the states of abstract machines (or objects), and• visible , for (ordinary) data types.

-Equality relation between “visible” (data type) elements is strict equality

-Equality between “hidden” elements is the (loose) behavioural (observational) equality.

-“Observations” are made via successive applications of behavioural operations ending with a visible sort.

Behavioural Specificaton

Specification of Bank Account

mod* ACCOUNT {protecting(INT)*[ Account ]*op init : -> Accountbop balance : Account -> Natbop deposit : Account Nat -> Accountbop withdraw : Account Nat -> Accountvar N : Natvar A : Accounteq balance(init) = 0 .eq balance(A deposit N) = balance(A) + N .cq balance(A withdraw N) = balance(A) -N if N <= balance(A) .cq balance(A withdraw N) = balance(A) if balance(A) < N .

}-Behavioural operations are required to have at least one hidden sort in

their arity. -Behavioural modules usually have loose denotations.

Hidden Sort


ACCOUNT : Model 1

eq init = 0

Here function minus is specified asop minus : Nat Nat -> Natcq minus(M:Nat,N:Nat) = M - N if N <= M .cq minus(M:Nat,N:Nat) = M if M < N .


ACCOUNT : Model 2

Here, p1 is the projection on the first component,eq init = < 0, 0 >

and the specification of d and w are as follows:op d : NatxNat Nat -> NatxNat .

op w : NatxNat Nat -> NatxNat .eq d(< N1:Nat, N2:Nat >, M:Nat) = < M + N1, N2 + 1 > .cq w(< N1:Nat, N2:Nat >, M:Nat) = < N1 - M, N2 + 1 > if M <= N1 .cq w(< N1:Nat, N2:Nat >, M:Nat) = < N1, N2 + 1 > if N1 < M .


Behavioural Equivalence

In the case of the states of an abstract machine, the meaningful equality is behavioural equality , denoted ∼ .

-Two states s and s'� (of the same hidden sort) are behaviourally equal (equivalent ) if and only if c (s ) = c (s' ) for all visible sorted behavioural contexts c .

-(a deposit 10 withdraw 5) ∼(a deposit 5)

Behavioural proof (Coinduction Principle)

-Define an equivalence relation R for each hidden sort.

-Prove that R is a hidden congruence.

-Prove that sRs' for the states s and s' which have to be proved behaviourally equivalent.


1. Definition of an equivalence relation _ R _

open ACCOUNT .pred _R_ : Account Account .

eq (A1:Account R A2:Account) = (balance(A1) == balance(A2)) .

2. Proof that _R_ is a hidden congruenceops a a’ : -> Account .ops n n’ : -> Nat .

Our hypothesis eq balance(a) = balance(a’) .

The preservation of _R_ by deposit,red (a deposit n) R (a’ deposit n) . gives true.

The preservation of _R_ by withdraw Case-1:case n <= balance(a):eq n <= balance(a) = true .eq n <= balance(a’) = true .red (a withdraw n) R (a’ withdraw n) . gives true.Case-2:.case balance(a) < n’:eq balance(a) < n’ = true .eq balance(a’) < n’ = true .red (a withdraw n’) R (a’ withdraw n’) . also gives true.

3. Proof of s R s'red (a deposit 10 withdraw 5) R (a deposit 5) .which gives true.

Prove: (a deposit 10 withdraw 5) ∼(a deposit 5)


Behavioural Coherence

-a ∼ a'� if and only if balance( a) = balance( a�)For all states a and a' of the object.

(a deposit n) ∼ (a'� deposit n) if a ∼ a'�and

(a withdraw n) ∼ (a'� withdraw n) if a ∼ a'�

Define deposit and withdraw as ordinary operation.

The signature of account object can be: *[ Account ]*op init : -> Accountbop balance : Account -> Natop _deposit_ : Account Nat -> Account { coherent }op _withdraw_ : Account Nat -> Account { coherent }


mod* BLIST { [ Elt ]

op err : -> ?Elt*[ List ]*op nil : -> Listbop cons : Elt List -> Listbop car : List -> ?Eltbop cdr : List -> Listvar E : Eltvar L : Listeq car(nil) = err .eq car(cons(E, L)) = E .beq cdr(nil) = nil .beq cdr(cons(E, L)) = L .

}

mod* BSET (X :: TRIV) { *[ Set ]*

op empty : -> Setop : Elt Set -> Set { coherent }

op U : Set Set -> Set { coherent } op & : Set Set -> Set { coherent } op - : Set Set -> Set { coherent } bop in : Elt Set -> Bool

vars E E’ : Eltvars S S1 S2 : Seteq E in empty = false .eq E in (E’ S) = (E == E’) or (E in S) .eq E in (S1 U S2) = (E in S1) or (E in S2) .eq E in (S1 & S2) = (E in S1) and (E in S2) eq E in (S1 - S2) = (E in S1) and not (E in

S2) .}

Behavioural Refinement


In our example, the behavioural sets are the “abstract” object and the behavioural lists are the “refined” object.

- extend BLIST with refinements of all operations of BSET

Refinement of behavioural sets to behavioural lists:• Hidden sort Set to the hidden sort List• Hidden constructor _ _ to the hidden constructor cons• The membership observation (E in L) to the derived observation (E ==car(L)) or-else (car(L) =/= err) and-also (E in cdr(L)) .


Proof of Refinement

To prove that BLIST’ refines BASIC-BSET, we have only to show that the equations

eq E in empty = false .eq E in (E’ S) = (E == E’) or (E in S) . are actually consequences of BLIST’:

open LIST’ .ops e e1 e2 : -> Elt .op l : -> List .

-For the first equation, we have the following proof score:red (e in nil) == false .which gives true. -For the second equation, the basic cases are as follows:eq e1 in l = true .eq e2 in l = false .

The proof score by case analysis is as follows:red e1 in cons(e,l) == true .red e2 in cons(e,l) == false .red e in cons(e,l) == true .All these proof scores evaluate to true.close

Thank You

Formal Specification Techniques

CASL

Common Algebraic Specification Language

Presented by : Prem Ramanujam

• CASL has been designed as a general-purpose algebraic specification language,

subsuming many existing languages.

• CASL is at the center of a family of languages.

• 1. Basic specifications provide the means to write specifications in a particular

institution, and provide a proof calculus for reasoning within such unstructured

specifications.

• 2. Structured specifications express how more complex specifications are built

from simpler ones . The semantics and proof calculus are given in a way that is

parameterized over the particular institution and proof calculus for basic

specifications.

• basic specifications: declarations, definitions, axioms

• structured specifications: translations, reductions, unions, extensions, freeness,

named specifications, generic specifications, views

• architectural specifications: implementation units, composition

• specification libraries: local, distributed

Basic Specification

• The semantics of a basic specification is a signature and a

class of models.

• CASL specifications may declare

Sorts

Subsorts

operations

predicates

Sorts

• A sort is a symbol which is interpreted as a set, called a carrier set

• The Elements of carrier sets are abstract representations of data: numbers, characters,

lists, trees, etc.

• A sort is approx. a type in a programming language

• CASL allows compound sort symbols, i.e. List[Int]

Subsorts

• Subsort declarations are interpreted as embeddings

• Set inclusion would be sufficient for, e.g. Nat < Int

• Embedding is necessary for, e.g. Char < String (Char and String are disjoint)

• An embedding is a 1-1 function

Operations

• Operations may be declared as total or partial

• An operation symbol consists of its name together with its profile

• Profile: number and sort of arguments, and result sort

• An operations is interpreted as a total or a partial function from the Cartesian product

of the carrier sets of the arguments to the carrier set of the result sort

• The result of applying an operation is undefined if any of the arguments is undefined

• Constant: operation with no arguments, interpreted as an element of the carrier set of

the result sort

Predicates

• A predicate symbol consists of a name and its profile

• Profile: number and sorts of the arguments, but no result sort

• Predicates are different from Boolean valued operations!!!

• Predicates are used to form atomic formulas, rather than terms

• A predicate symbol is interpreted as a relation on (i.e., a subset of) the Cartesian

product of the carrier sets of the argument sorts

• Predicates are never undefined, they just do not hold if any of the arguments is

undefined (two valued logic)

• For Boolean valued operations: three valued logic (true, false, undefined)

Atomic Formulas

• predicate applications

• equations (strong or existential)

• existential: both sides are defined and equal

• Strong: hold as well, if both sides are undefined

• defines assertions

• Subsort membership assertions

Axioms

• Axioms are formulas of first-order logic

• Logical connectors have usual interpretation

• Quantification: universal, existential, unique existential

• Interpretation of quantification: completely standard!

• Variables in formulas range over the carrier sets of specified sorts

• An axiom either holds or does not hold in a particular model: there is no “maybe” or

undefined about holding (regardless of whether the values of terms occurring in the

axioms are defined)

Semantic Concepts

The essential semantic concepts for basic specifications are well-known: signatures

(of declared symbols), models (interpreting the declared symbols), and sentences

(asserting properties of the interpretation), with a satisfaction relation between models

and sets of sentences. Defining these (together with some categorical structure, and

such that translation of symbols preserves satisfaction) provides a so-called institution.

A well-formed basic specification in Casl determines a signature and a set of sentences,

and hence the class of all models over that signature which satisfy all the sentences.

Institution

• A specification formalism is usually based on some notion of signature, model,

sentence and satisfaction.

• The theory of institutions assumes nothing about signatures except that they form a

class and that there are signature morphisms, which can be composed in some way.

• This amounts to stating that signatures form a category.

The CASL logic (institution)

• Signatures: a signature provides the vocabulary

• Signature morphisms: for extending and renaming

signatures

• Models: interpret the vocabulary of a signature with

mathematical objects (sets, functions, relations)

• Sentences (formulae): for axiomatizing models denote true

or false in a given model.

• Terms: parts of sentences, denote data values

• Satisfaction of sentences in models

CASL many-sorted signatures

CASL many-sorted models

CASL formulae

Satisfaction of atomic formulae

Satisfaction of compound formulae

Satisfaction of closed formulae

Language Construct

CASL syntax for declarations and axioms involves familiar

notation, and is mostly self-explanatory.

Specifications can easily be extended by new declarations and

axioms.

In simple cases, an operation (or a predicate) symbol may be declared and its

intended interpretation defined at the same time.

Symbols may be conveniently displayed as usual mathematical symbols by

means of %display annotations.

The %implies annotation is used to indicate that some axioms are supposedly

redundant, being consequences of others.

Attributes may be used to abbreviate axioms for associativity, commutativity,

idempotence, and unit properties.

Genericity of specifications can be made explicit using parameters.

Datatype declarations may be used to abbreviate declarations of sorts and

constructors.

Loose datatype declarations are appropriate when further constructors may be

added in extensions.

Sorts may be specified as generated by their constructors.

Generated specifications are in general loose.

Free datatype declarations are particularly convenient for defining enumerated

datatypes.

Partial functions are declared differently from total functions.

• Terms containing partial functions may be undefined, i.e., they may fail to denote any value.

• Functions, even total ones, propagate undefinedness.

• Predicates do not hold on undefined arguments.

• Equations hold when both terms are undefined.

• Special care is needed in specifications involving partial functions.

Domains of definition can be specified more or less explicitly.

Loosely specified domains of definition may be useful.

Subsorted Basic Specifications

Subsorted Signature

Models

Sentences

Satisfaction

Translation from subsorted to many-sorted signatures

Subsort declarations directly express relationships between carrier sets.

Operations declared on a sort are automatically inherited by its subsorts.

Subsort membership can be checked or asserted.

Datatype declarations can involve subsort declarations.

CASL Structured Specifications

Named and Parameterized Specifications and Views

Structured specifications may be named, so that a reuse of a specification may be

replaced by a reference to it through its name. A named specification may declare some

parameters, the union of which is extended by a body; it is then called generic. This is

written as spec SpName[ParSp] = BodySp, where BodySp is an extension of ParSp.

A reference to a generic specification should instantiate it by providing, for each

parameter, an argument specification together with a fitting morphisms from the

parameter to the argument specification.

Union and extension can be used to structure specifications.

Renaming may be used to avoid unintended name clashes, or to adjust names of sorts and change

notations for operations and predicates

Auxiliary symbols used in structured specifications can be hidden.

Parameters and Instantiation

• There must be no shared symbols between the argument specification and the body

of the instantiated generic

spec spec This_Is_Wrong = Generic_Monoid [Monoid] end

• The intended fitting of the parameter symbols to the argument symbols may have to

be specified explicitely.

spec Nat_Word_2 = Generic_Monoid [Natural_Subsorts fit Elem |-> Nat]

end

Architectural Specifications

• Architectural specifications in Casl provide a means for stating how implementation

units are used as building blocks for larger components.

• Units are represented as names with which a specification is associated.

• Units may be parameterized, whereby specifications are associated with both the

parameters and the result.

• The result specification is required to extend the parameter specifications.

• A parameterized unit is to be understood as a function which, given models of the

parameter specifications, outputs a model of the result specification; this function is

required to be persistent in the sense that reducing the result to the parameter

signatures reproduces the parameters.

• Units can be assembled via unit expressions, which may contain operations such as

renaming or hiding of symbols, amalgamation of units, and application of a

parameterized unit.

• for example, by renaming them to the same symbol or by amalgamating units that

have symbols in common, are also interpreted in the same way in all “collective”

models of the units defined so far.

• An architectural specification consists of declarations and/or definitions of a number

of units, together with a way of assembling them to yield a result unit.

The semantics of architectural specifications introduced above is split into static and model

semantics, in very much the same way as was done for structured specifications.

Unit terms are statically elaborated in a static context Cst = (Pst ,Bst ),where Pst maps

parameterized unit names to signature morphisms and Bst maps non-parametrized unit names

to their signatures.

We require the domains of Pst and Bst to be disjoint. The empty static context that consists of

two empty maps will be written as C∅ st .

Given an initial static context, the static semantics for unit declarations produces a static

context by adding the signature for a newly introduced unit, and the static semantics for unit

terms determines the signature for the resulting unit.

In terms of the model semantics, a (non-parametrized) unit M over a signature Σ is just a

model M ∈ Mod(Σ). A parameterized unit F over a parametrized unit signature τ : Σ1 → Σ2 is

a persistent partial function F : Mod(Σ1) Mod(Σ2) (i.e. F(M) τ = M for each M ∈ Dom(F)).

Architectural Models: An architectural

specification denotes a class of architectural

models which consist of:

a collection of named units, together with

the unit resulting from a particular composition

of those units.

As mentioned above, units are either Casl

models, or functions from Casl models to Casl

models. The unit functions are always persistent,

so that the results extend the unmodified

arguments When unit functions have more than

one argument, the arguments must be compatible,

in particular implementing any common symbols

in exactly the same way this follows immediately

from the requirement that a function should

extend each argument separately.

Verification

• The basic idea behind verification for architectural specifications is that we want to extend the static information about

units to capture their properties by an additional specification.

• However, we must also take into account sharing between various unit components, resulting from inheritance of some

parts of units via, for instance, parameterized unit applications.

• To capture this, we accumulate information about non-parameterized units into a single global signature ΣG, and

represent non-parameterized unit signatures as morphisms into this global signature, assigning them to unit names by a

map Bv .

• The additional information resulting from the unit specifications is then accumulated into a single global specification

SPG over this signature (i.e. we always have

• Finally, of course, we store the entire specification for each parameterized unit, assigning these specifications to

parameterized unit names by a map Pv . This results in the concept of a verification context Cv = (Pv ,Bv , SPG).

Refinement The standard development paradigm of algebraic specification postulates that formal software

development begins with a formal requirement specification (extracted from a software project’s

informal requirements) that fixes only some expected properties but, ideally, says nothing about

implementation issues; this is to be followed by a number of refinement steps that fix more and

more details of the design, so that one finally arrives at what is often termed the design

specification. The last refinement step then results in an actual implementation in a programming

language.

which expresses that the model class of Sp3 is included in that of Sp2, which is in turn included in the

model class of Sp1. On the other hand, it is possible to refine structured specifications into

architectural specifications, introducing a branching into the development:

Conclusions

• CASL is a complex specification language that provides both a complete formal semantics and a proof

calculus for all of its constructs.

• A central property of the design of CASL is the orthogonally between basic specifications and structured

and architectural specifications.

• Basic Specifications provide means to write theories in a specific logic, whereas Structured and

architectural specifications have a logic independent semantics.

• Logic for basic specifications can easily be changed while keeping the rest of CASL unchanged.

• CASL is the central language in a whole family of languages.

• CASL concentrates on specifications of abstract data types and functional requirements.

• Some extensions of CASL also consider the specification of higher order functions and of reactive and

object-oriented behaviour.

• Programming Languages are being integrated into CASL leading to a framework and environment for

formal software development.

•The Heterogeneous Tool Set (HETS) is the main analysis tool for CASL.

• CASL specifications can also be checked for well-formedness using a form-based webpage.

• HETS can be used for parsing and checking static well-formedness of specifications.

• HETS also displays and manages proof obligations, using development graphs.

• Nodes in a development graph correspond to CASL specifications.

Arrows show how specifications are related by the structuring constructs.

• Internal nodes in a development graph correspond to unnamed parts of a structured

specification.

•Currently, Hets integrates the following provers:

* Interactive higher-order provers

o Isabelle

* Automated first-order provers

o SPASS

o Vampire

o MathServe

Other tools

* CASL consistency checker (a prototype)

* CASL to PVS (a prototype)

* CATS, the CASL tool set (now out-dated and superseded by Hets)

* HOL-CASL (now out-dated and superseded by Hets)

Tools

IntroductionThe RSL Logic

Reasoning in RAISECASE Study

Conclusion and Bibliography

The Logic of RAISE Specification LanguageChris George and Anne E. Haxthausen

Hamid Mohammad-GholizadehSupervised by: Dr. Khedri

Department of Computing and softwareMcMaster University

April 2011

1 / 32 Hamid Mohammad-Gholizadeh The Logic of RAISE Specification Language




Outline1 Introduction

What is RAISE?The RAISE Specification Language(RSL)Refinment in RAISE

2 The RSL LogicEquivalence and EqualityDefinednesslogical ConectivesAxioms

3 Reasoning in RAISEReasoning Styleproof theoryThe Justification Editor

4 CASE StudyIntroductionStructure of SpecificationProof ObligationsOther techniques to proof properties

5 Conclusion and Bibliography






What is RAISE?Rigorous Approach to Industrial Software Engineering

Rigorous Approach to Industrial Software Engineering

A method for software development

A formal specification language: RSL

A set of supporting tools






RAISE HistoryWhen, Why and How Invented

Esprit I project: 1985-1990 �→ Formal specificationlanguage RSL and its tool set

Esprit II project: 1989-1992�→ RAISE successor project,concentrated on applying the RAISE method

ESPRIT (European Strategic Program on Research inInformation Technology)






The RAISE Specification Language(RSL)

RSL is a formal, wide-spectrum specification language

It is inspired by and unifies features of severalspecifications languages

Z, VDM → model based specification language.CLEAR, OBJ → algebraic specification language.CSP, CCS → laguage for describing cuncurreny.

Typical applications could be: system software,embedded system or safety critical software.






Refinment in RAISE






Refinment in RAISE

typeAccount, Transaction

valueadd : Transaction × Account ∼→ Account

. . .⇓type

Account = {� trl: Transaction* ● is_ordered(trl) �}Transaction ::

date : Date,amount : Amountinfo : Info

valueadd : Transaction × Account ∼→ Accountadd(tr, ac) ≡ �tr �̂ acpre can_add(tr,ac),

. . .






Refinement in RSL

class expression B′ refines class expression B provided

The signature of B′ includes that of B→ ensures that substituting B′ for B in some context will notgenerate type errors.

All the properties of B hold in B′→ anything that can be proved about a class can be provedabout a class that refines it.






Refinment in RAISEExample

problematic refinementtype T = Int-set Refinement ⇒ type T = Int∗ � Type error

solutiontype Tvalue setof: T → Int-set

Refined To:type T=Int∗value

setof: T → Int-setsetof(t) ≡ elems t





Equivalence and EqualityDefinednesslogical ConectivesAxioms

Equivalence≡(equivalence) VS =(equality)

A ≡ B

A and B has same effect and same result.

is reflexive, transitive and commutative and allow substitution

always defined i.e always returns true or false

A = B → just like any other infix operator, such as +

Evaluate A. If it is undefined so is the whole expression.

Otherwise, evaluate B. If it is undefined, so is the wholeexpression.

Otherwise, compare the results of evaluating A and B and return"true" if they are the same value, "false" otherwise.






Equivalence . . .

ExampleVariable

v : Intvalue

increment : Unit → write v Intincrement ≡ v ∶= v + 1; v

Now consider the two expressionsincrement() ≡ increment() ≡ trueincrement() = increment() ≡ false






Definedness

problematic expressions likewhile true do skip end

Possible approaches:All expressions denote(like Z and B languages)RSL, like VDM, allows in its logic for expressions that mightnot denote values in their types �→ you should provedefineness.

There are three basic undefined expressions in RSL:chaos �→ while true do skip end,stop, swap �→ specify a kind of deadlock in concurrency






logical Conectives

How to define ∧,∨,∼,⇒A ∧ B ≡ if A then B else false endA ∨ B ≡ if A then true else B endA⇒ B ≡ if A then B else true end∼ A ≡ if A then false else true end

All the laws of classical logic hold when expressions areconvergent → defined and having a unique value






logical Conectives . . .

Not commutative in some cases!

chaos ∧ false ≡ chaosbutfalse ∧ chaos ≡ false

� true false chaostrue true false chaosfalse false false falsechaos chaos chaos chaos






The RSL LogicAxioms

valuefactorial : Nat →̃ Natfactorial(n) ≡

if n = 1 then 1 else n ∗ factorial(n-1) endpre n ≥ 1

Above Spec. is a short form for:

valuefactorial : Nat →̃ Nat

axiom∀n ∶ Nat ●factorial(n) ≡

if n = 1 then 1 else n ∗ factorial(n-1) endpre n ≥ 1





Reasoning Styleproof theoryThe Justification Editor

Reasoning Style

Some methods use reasoning based on:Hoare logic or weakest preconditions (wp) for sequentialimperative descriptionsTemporal logic for concurrent descriptions

RSL use an axiomatic "equational" style.






proof theory

Purpose of the proof theoryprovide formation rules for determining whether aspecification is well-formed (type correct etc.)proof rules for reasoning about specifications, forexample:

deciding whether two RSL terms are equivalentdeciding whether an RSL specification is a refinement ofanother RSL specification.

The Form of the Definition of the Axiomatic Semantics

premise1...premisenconclusion






proof theory . . .

Formation Rulesprovide a decidable test for whether terms are well-formed.

context�true ∶�Bool

Context-independent Equivalence Ruleslike commutativity of the concurrency operator or Shorthandterms

�expr1∥exp2≅expr2∥exp1

�value_expr1∧value_expr2≅if value_expr1 then value_expr2 else false end






The Justification Editor

Type-checking, Simplifying rule language.Allow proof rules to be applied to the sub-expressions of agoal.

select a sub-expressionshow the applicable proof rulesselect and apply a rule

Not all steps to be proved formally: Accept informalassertion that is true or replace an expression by anotherasserted as equivalent.






The Justification EditorProof Rule Language

term1 � term2 when term3

[if_annihilation1]if eb then eb else true end � true

when convergent(eb) ∧ readonly(eb)

[let_int_choice]let b=e � e’ in e1 end �

let b=e in e1 end � let b=e’ in e1 end





IntroductionStructure of SpecificationProof ObligationsOther techniques to proof properties

CASE StudyHarbour System






Structure of Specification

Identify Objects:Ships, Berths, Pool

Identify Operations on Objects:arrive: to register the arrival of a ship;dock: to register a ship docking in a berth;leave: to register a ship leaving a berth.






Structure of Specification . . .

scheme TYPES = class ... end→ defining types and static properties for the basic objects.

object T : TYPES→ instantiation of TYPES.

scheme HARBOUR = class ... end→ the state of the harbour and the required top-level functions.






Schema TYPES

typeShip, Berth (leave it open whether ships and berths should have additional attributes.)

Index = {�i ∶ Int ● i ≥min ∧max ≥ i �}value

fits : Ship × Berth → Bool. (a ship may or may not fit a berth)

indx : Berth → Index (a function that observes the index of a berth)

min, max: Intaxiom

[berths indexable]∀b1,b2 ∶ Berth ● indx(b1) = indx(b2)⇒ b1 = b2[index not empty]max ≥min






Schema HARBOUR

typeHarbour ::

pool:T.Ship-setberths: T.Index m→ T.Ship

value/* observer (query) functions */

waiting:T.Ship × Harbour → Boolwaiting(s, h) ≡ s ∈ pool(h)is_docked : T.Ship × Harbour → Boolis_docked(s, h) ≡ s ∈ rng berths(h)...






Schema HARBOUR . . .

value /*generator functions */

empty : Harbour = mk_Harbour({}, [ ])

arrive: T.Ship × Harbour ∼→ Harbourarrive(s, h) ≡ mk_Harbour(pool(h) ∪ {s}, berths(h))pre can_arrive(s,h). . . /*guards*/

can_arrive : T.Ship × Harbour → Boolcan_arrive(s, h) ≡ ∼ waiting(s, h) ∧ ∼ is_docked(s,h)...






Invariants in HARBOUR Specification

at most one ship can be in any one berth.

a ship cannot be in two places at once.

a ship can only be in a berth that it fits.

consistent: Harbour → Boolconsistent(h) ≡

( ∀s ∶ T .Ship●∼ (waiting(s,h) ∧ is_docked(s,h)) ∧( ∀b1,b2 ∶ T .Berth●

is_occupied_by(b1,s,h) ∧is_occupied_by(b2,s,h)⇒ b1 = b2) ∧

( ∀b ∶ T .Berth●is_occupied_by(b,s,h)⇒ T.fits(s,b)) )






CASE studyProof Obligations

consistent(empty)

OR

∀h ∶ Harbour, s: T.Ship ●consistent(h) ∧ can_arrive(s,h)⇒ consistent(arrive(s,h))






Prove Using eden

we may use the definitions of that specification in the proof.�∀h : Harbour, s :T.Ship ●consistent(h) ∧ can_arrive(s,h)⇒ consistent(arrive(s,h)) �

all_assumption_inf, imply_deduction_inf1 :[gen_131] consitent(h) ∧ can_arrive(s, h) �� consistent(arrives(s,h)) �. . .[ imply deduction inf1 ]

[id]ro_eb�ro_eb′ro_eb⇒ro_eb′

when convergent(ro_eb) ∧ pure(ro_eb)






Proof via Translation

This new tool provides support for proof via translation toPVS.can provide only a limited proof system because PVS isapplicative.PVS also has a different logic from RSL → excludesundefinedness and nondeterminism.prove done in half the number of proof steps requiredwith edenRSL maps are like partial functions: we model a map asa total function that returns nil when applied to values notin the domain.An alternative for translating proof obligations into PVS isto translate them into Isabelle/HOL






Model Checking and Testing

Proof is ideal method but Expensive.model checking

a property such as maintenance of consistency being Truein every possible state of the system.translator from RSL to the language of the symbolic modelchecker SALFor harbour → 1015 nodes and 24 Boolean variableshave to reduce the problem to a finite model before we canuse model checking

Testingerrors such as incorrect implementation or wrongassumptions about the environment.The RAISE tools have translators to SML and to C++test_case [t1] empty(); arrive(s3); pool=s3 ∧ berths = [ ],. . .





Bibliography

C. Henson and Dines Bjorner (editors), "Logics of Specification Languages,"EATCS Monographs in Theoretical Computer Science, Springer, 2008.

H. Dang Van, C. George, T. Janowski, and R. Moore (Eds), Specification CaseStudies in RAISE, UNU-IIST, 2002.

C. George, "Lecture notes in Formal Software Development Using RAISE."

Soren Prehn,"From VDM to RAISE," Lecture Notes in Computer Science, 1987,Volume 252/1987, 141-150

Chris George. "A RAISE Tutorial," Technical Report, UNU-IIST, December 1998.


Duration Calculus

Vitalii Fedorenko McMaster University

Table of Contents

Buridan's LogicInterval LogicDuration CalculusExtensions

Buridan's Logic

T(I, p) : p is true wrt. the interval I given(I, p) : The truth of p is given for the interval I included(I', I) : The interval I' is included in I

Formalization

Truth

The truth of a proposition p wrt. an interval I:

T(I, p) = ∃I'.(included(I', I) ∧ given(I', p))

Given

given(I, p) ⇒ ∀I'.(included(I', I) ⇒ given(I', p))

Socrates is Alive

The present (now)

Contradiction?

T(I, p) ∧ T(I, ¬p) = ?

Interval Logic

Interval Logic

Predicates describes the set of times when the formula is true

Interval

An interval �ntv is the set of time intervals:

�ntv ≙ { [b,e] | b,e ∈ �ime ⋀ b ≤ e }

Syntax

� ::= x � ℓ � ƒn (�1,...,�n)

ϕ ::= X � Gn (�1,...,�n) �¬ϕ � ϕ ⋁ ψ � ϕ ◠ ψ � (∃x)ϕ

Semantics

Val ≙ GVar → ℝ

� �θ� : (Val x �ntv) → ℝ � �ϕ� : (Val x �ntv) → {tt,ff }

Example

(ℓ < x) ⋁ (ℓ > 5)

Chop

φ ◠ ψ (read as “φ chop ψ”) holds on [b, e] iff there exists an m, where b ≤ m ≤ e, φ holds on [b,m] and ψ holds on [m, e]

ϕ ψ

b m e

Possible-World Semantics

R ⊆ W x W x W

([t1, t'1],[t2, t'

2],[b, e]) ∈ R iff b = t1 ⋀ t'1 = t2 ⋀ t'

2 = e

Possible-World Semantics

R ⊆ W x W x W

([t1, t'1],[t2, t'

2],[b, e]) ∈ R iff b = t1 ⋀ t'1 = t2 ⋀ t'

2 = e

(W,R), �, V,w |= ϕ ◠ ψ

iff, for some w1, w2 ∈ W, where (w1, w2,w) ∈ R:

|(W, R), � , V, w1 |= ϕ and (W,R), �, V, w2 |= ψ

Dual-chop

ϕ ◡ ψ - dual-chop, for all m φ holds on [b,m] or ψ holds on [m,e]

ϕ ◡ ϕ ≙ ¬((¬ϕ) ◠ (¬ψ))

Derived Propositional Connectives

ϕ ⋀ ψ = ¬((¬ϕ) ⋁ (¬ψ))

ϕ ⇒ ψ = ((¬ϕ) ⋁ ψ) ϕ ⇔ ψ = (ϕ ⇒ ψ) ⋀ (ψ ⇒ ϕ) (∀x)ϕ = ¬((∃x)¬ϕ)

Interval Logic Axioms

ℓ ≥ 0

((ϕ ◠ ψ) ⋀ (¬ϕ ◡ φ)) ⇒ (ϕ ◠ (ψ ⋀ φ))

((ϕ ◠ ψ) ⋀ (φ ◡ ¬ψ)) ⇒ ((ϕ ⋀ φ) ◠ ψ)

((ϕ ◠ ψ) ◠ φ) ⇔ (ϕ ◠ (ψ ◠ φ))

Example

∃x, y > 0. (ϕ ◠ (ℓ = y ⋀ ψ) ◠ (ℓ = x + y ⋀ ϕ))

Inference Rules

if ϕ and ϕ ⇒ ψ then ψ if ϕ then (∀x)ϕ if ϕ then ϕ ◡ false if ϕ then false ◡ ϕ if ϕ ⇒ ψ then (ϕ◠φ) ⇒ (ψ◠φ) if ϕ ⇒ ψ then (φ◠ϕ) ⇒ (φ◠ψ)

(Modus ponens) (Generalization) (Necessity) (Monotonicity)

Rigid Expressions

Terms and formulas which do not depend on time intervals are called rigid

Predicate Logic Axiom

if θ is free for x in φ(x), and either θ is rigid or φ(x) is chop-free:

∀x.φ(x) ⇒ φ(θ)φ(θ) ⇒ ∃x.φ(x)

∀x.(((ℓ = x) ◠ (ℓ = x)) ⇒ ℓ = 2x)

((ℓ = ℓ) ◠ (ℓ = ℓ)) ⇒ ℓ = 2ℓ)

Deduction and Proof

ϕ ⇒ ψ ⊢ (ϕ ◡ φ) ⇒ (ψ ◡ φ) ϕ ⇒ ψ ⊢ (φ ◡ ϕ) ⇒ (φ ◡ ψ)

Other Modalities

◇ϕ ≙ true ◠ (ϕ ◠ true) - for some subinterval

Other Modalities

◇ϕ ≙ true ◠ (ϕ ◠ true) - for some subinterval

▢ϕ ≙ ¬◇(¬ϕ) - for all subintervals

Example

◇A = ¬▢¬ A

Theorems

▢(ϕ ⇒ ψ) ⇒ (▢ϕ ⇒ ▢ψ)

ϕ ⊢ ▢ϕ

▢ϕ⇒ ϕ

▢ϕ⇒ ▢▢ϕ

Duration Calculus

Boolean-value Function

true ↝ 1

false ↝ 0

Real Time System

A real-time system is a computing system with real-time constraints.

�ime → {0,1}

�ime ≙ ℝ

Example

Rdyi : �ime → {0,1}

Runi : �ime → {0,1}

Runi (t) ⇒ Rdyi (t)

Runi (t) ⇒ Λj≠i¬Runj (t)

Syntax

S ::= 0 �1� P �¬S1� S1 ⋁ S2

� ::= x � ℓ � ∫S � ƒn (�1,...,�n)

ϕ ::= X � Gn (�1,...,�n) �¬ϕ � ϕ ⋁ ψ � ϕ ◠ ψ � (∃x)

ϕ

Semantics

Duration

Duration of the state Runi in the interval [a, b]:

Requirements

∫(Rdyi Λ Runi) > 0

Requirements

k1 + k2 +... + kn ≤ 1

∫(Rdyi Λ Runi) > 0

Process Scheduler

Boolean State Model

Given(I,S): S - state expression ℓ - length of the current interval

|�S�| = ∫S = ℓ Λ ℓ > 0

Boolean State Model

Given(I,S): S - state expression ℓ - length of the current interval

|�S�| = ∫S = ℓ Λ ℓ > 0

▢(ℓ ≥ 1 ⇒ ◇(∫Runi = ki Λ |�Rdyi�|))

Socrates Again

◇ |�A�| Λ ◇ |�¬A�|

DC Axioms

∫0 = 0 ∫1 = ℓ ∫S ≥ 0 ∫S1 + ∫S2 = ∫(S1 ⋁ S2) + ∫(S1 Λ S2)

((∫S = x) ◠ (∫S = y)) ⇒ (∫S = x +y)

Theorems

∫S ≤ ℓ ∫S +∫¬S = ℓ

∫S1 ≥ ∫S2, if S2⇒ S1

Extensions

Allen's Interval Algebra

∀i1, i2, i3.(MEETS(i1, i2) ∧ DURING(i2, i3)

⇒ (OVERLAPS(i1, i3) ∨ DURING(i1, i3) ∨ MEETS(i1, i3)))

Neighbourhood Logic

Neighbourhood Logic

◇cl ϕ ≙ ◇r◇l ϕ read "for some left neighborhood of the

end point: ϕ" ◇c

r ψ ≙ ◇l◇r ψ read "for some right neighborhood of the

start point: ψ"

Liveness

inf(S) ≙ ▢r◇r ◇r |�S�|

inf(S) Λ inf(¬S)

Fairness

inf(¬|�Leak�|) ⇒ inf(|�Leak�|)

Justice

stabilize(S) ≙ ◇r ▢r|�S�|*

|�S�|* ≙ |��| v |�S�|

stabilize (S1) ⇒ inf(S2)

Justice

stabilize(S) ≙ ◇r ▢r|�S�|*

|�S�|* ≙ |��| v |�S�| stabilize (S1) ⇒ inf(S2)

Equal Distribution

∀e > 0. ∃T. ▢r(ℓ > T ⇒ |∫S1 - ∫S2| < e)

Signed Interval

Refined Models for Reactive Real-time Systems

e1 e2 ... en ∈ Event*

Refined Models for Reactive Real-time Systems

For a given interval [b, e], the trace variable gives the trace which is observed at the right end point e of the interval

e1 e2 ... en ∈ Event*

Tr : �ntv → Event*

Bibliography

1. Interval Temporal Logichttp://www.cse.dmu.ac.uk/STRL/ITL/

2. Logics of Specification LanguagesBjorner, Dines; Henson, Martin C., 2008

3. Neighborhood logic and Interval Algebra, the United Nations University, 1997

4. MIT OpenCourseWare | Electrical Engineering and Computer Science | 6.033 Computer System Engineering, Spring 2009

http://www.cse.dmu.ac.uk/STRL/ITL/

Outline

•  Introduc/on – Defini/on of the event-‐B Modeling Method

•  The event-‐B model Components •  Rela/onships in event-‐B •  Guards and Events •  Invariants •  Proofs •  Example

2

Introduc/on

•  The classical B-‐Method is a mathema/cal method for formal system specifica/on, design and implementa/on of soGware based on refinement.

•  Event-‐B is derived from classical B. It keeps the concepts of classical B-‐ Method but adds the concept of event. It is used model of discrete transi+on systems.

3

Classical B vs. event-‐B structures

4

CLASSICAL B MCHINE SETS sASSERTIONS A(x) CONSTANTS c PROPERTIES P(s,c) VARIABLES x INVARIANTS I(x) INITIALIZATION <sub.> OPERATIONS <list of op.>

EVENT B MCHINE SETS sCONSTANTS c PROPERTIES P(s,c) VARIABLES x INVARIANTS I(x) INITIALIZATION <sub.> EVENTS <list of events>Variant V(x)

Operation: has input/output parameters, only operation can change state variables. Precondition check for every operation. !

The event-‐B Model Components

•  Model has two kinds of components: Machine and Context.

5

Machine: name •  SEES context_name •  variables v •  INITIALISATION T •  invariants I(c,v) •  theorems •  events E(c,v) event_name = name_predicates (guards) then subsitu/on (S) E = WHEN G(c,v) THEN S(v) END!

•  variants V(c,w)!

Context: name •  Extends: context •  carries sets s •  constants c •  axioms A(c)!•  theorems

Dynamic part

Sta/c Part

The event-‐B Model Components

•  Carrier SETS (s) define sets and are represented by their name e.g. COLORS

•  CONSTANTS (c) are defined by a number of AXIOMS A(s,c) •  THEOREMS are required asser/ons for proving. •  VARIABLES define machine variables, which are used to

maintain state informa/on while performing events. •  INVARIANTS are used to define a property over the states

and context of the system that must be sa/sfied by all events.

•  INITIALISATION is used to specify the ini/al values of variables.

•  EVENTS define the units of behaviour that include possible state changes.

6

Machines and Contexts Rela/ons

•  Machines see contexts

•  Contexts can be extended •  Machines can be refined

•  A machine implicitly sees all contexts extended by a seen context.

•  A machine only sees a context either

explicitly or implicitly. •  No cycle in the "refines" or "extends" rela/onships. •  Machine and Context can be abstract or concert

7

M

M C

C sees

0-m!

sees

0-m!

0-1!refines

refines 0-1!

0-m! extends

extends 0-m!

Machines and Contexts Rela/ons

8

M0

M1

C01

C1

C02 sees

sees

sees

sees extends

refines

M0 sees C01 and C01 explicitly M1 sees C01 and C1 explicitly M1 sees C02 implicitly

Generalized Subs/tu/ons

•  GSL provides a way to express transforma/ons of the state variables of a

given model.

9

Name GSL S [S]P

Assignment x:=E P(E/x)

Skip Skip P

Parallel composi/on x:= E||y:=F [x,y:=E]P

Non-‐determinis/c choice x:∈S ∀v.(v∈ S ⇒ P(v/x))

Precondi/on pre G then T end G ⋀ [T]P

Sequen/al composi/on S;T [S][T]P

Guards and Event

•  Guards iden/fy lists of condi/ons for the event to occur. E = when G(v) then S(v) end!

•  Three types of Events: – A Simple structure declares an event that does not have a guard but ac/ons S(s, c, v)!

– A Guarded structure is used to iden/fy an event with guards G(s, c, v) and ac/ons S(s, c, v)

– A Non determinis/c structure is the general form of an event and used when the event has local variables l with guards G(l, s, c, v) and ac/ons S(l, s, c, v).

•  The guard of the skip event is true. 10

Guards and Event

•  Simple –  x:= E(v), e.g. x’=x+1

•  Determinis/c –  E=When G(v) then S(v) end, e.g. when x<10 then x=x+1 end

•  Non-‐determinis/c –  any t where P(t,v) then x := F(t,v) e.g. n’∈ {n+1,n+2}

•  Skip no change –  n’=n

11

Guard and Events

12

Event: E Guard: grd(E)

begin S end TRUE

When G(x) then T end G(x)

any t where G(t,x) then T end ∃t.G(t,x)

Before AGer Predicates

•  It describes the rela/on between the values of the variable(s) just before and just aGer the event occurrence. e.g. v’ = v +1

13

SubsOtuOon Before AQer Predicates

Determinis/c G(x) ⋀ P(x,x’)

skip P(x,x’)

Non-‐determinis/c ∃t . ( G(t,x) ⋀ P(x,x’,t) )

Event:E Before AQer Predicates

Begin x : P(x,x’) end P(x,x’)

When G(x) then x: P(x,x’) end G(x) ⋀ P(x,x’)

Any t where G(t,x) then T end ∃t . ( G(t,x) ⋀ P(x,x’,t) )

The Gluing invariant

•  A gluing invariant links the state of the concrete model to the states of its abstract model.

•  J(s,c,v,w) w is the variable of concert model, while v is in the abstract model.

14

Consistency Proofs

•  Event-‐B model has to perform consistency proofs to ensure the correctness of the model.

15

P (s, c) ∧ I(s, c, v) ∧ G(s, c, v) ∧ R(s, c, v, v’ ) ⇒ I(s, c, v’ ) invariant preservaOon statement (INV)

P (s, c) ∧ I(s, c, v) ∧ G(s, c, v) ⇒ ∃v’·∙ R(s, c, v, v’ ) feasibility statement (FIS)

P(s,c): proper/es of constants I(s,c,v): Invariant G(s,c,v): guard R(s,c,v,v’): before-‐aGer predicate

Other proofs: INC increments, DEC decrements

Different INV and FIS in the ini/aliza/on event. Don’t have to check invariants and guards

Event:E Feasibility: fis(E)

x: Init(x) ∃x .Init(x)

Begin x:P(x,x’) end I(x) =>∃x’.P(x,x’)

Refinement

•  The concept of refinement in Event-‐B allows more detail, and the expression of some design decisions, to be added, in a stepwise manner, into the model. –  Feature augmentaOon: a feature augmenta/on is a refinement in which exis/ng model features are maintained and addi/onal features are added, such as variables, invariant, events, addi/onal guards and ac/ons.

–  Structural refinement: this refinement is adding detailed design to the implementa/on. Examples of structural refinements are refining the algorithm of an event’s operators, event decomposi/on, and replacing an exis/ng event’s variable with new variables. Must use gluing invariant.

16

Deadlock free

•  A model is deadlook free if can run forever. •  The disjunc/on of the event guards always hold under the proper/es of constants.

17

P (s, c) ∧ I(s, c, v) ⇒ G1 (s, c, v) ∨ . . . ∨ Gn (s, c, v) DLF

Rela/ve Deadlock Freedom

•  There a no new deadlocks in the concrete model, that is, all dead-‐ locks of the concrete model are already present in the abstract model.

18

P (s, c) ∧ I(s, c, v) ∧ J(s, c, v, w) ∧ Gi (s, c, v) ⇒ H1 (s, c, w) ∨ . . . ∨ Hm (s, c, w) ∨ N1 (s, c, w) ∨ . . . ∨ Nn (s, c, w)

DLF

New Event

•  New Event may be introduced in refinement: – new event refines an implicit skip

– Should not run forever, variant is used. Each new event decreases the variant which is well founded structured e.g. (N,≤) .

19

P (s, c) ⇒∃ v’ ·∙ RI(s, c, v’ ) INI_FIS

P (s, c) ∧ RI(s,c,v’) ⇒ I(s, c, v’) INI_INV

RI(s,c,v’): the aGer predicate of the generalized subs/tu/on with ini/aliza/on INI_FIS: feasibility statement for ini/aliza/on INI_INV: invariant preserva/on statement for ini/aliza/on.

An/cipa/ng New Events

•  Skip and variant are used. •  Try to select a variant that check range of events. e.g. n = 2*(a+b)

20

Complexity of Systems

•  techniques can be used to master this complexity – Refinement allows us to build model gradually – Decomposi/on: Refinement does not solve alone the problem of complexity, A large model can be decomposed into smaller ones.

– generic instan/a/on: Models can be parameterized with carrier sets and constants, Constants are specified by means of proper/es, Analogy with algebraic theories.

21

Example

The system is controlling cars on a bridge between the mainland and an island

FUN-‐1

The system has two traffic lights with two colors: green and red EQP-‐1

The traffic lights control the entrance to the bridge at both ends of it EQP-‐2

Cars are not supposed to pass on a red traffic light, only on a green one EQP-‐3

The system is equipped with four car sensors each with two states: on or off EQP-‐4

The sensors are used to detect the presence of cars entering or leaving the bridge

EQP-‐5

The number of cars on the bridge and the island is limited FUN-‐2

The bridge is one way or the other, not both at the same /me FUN-‐3

22

Example: Refinement Strategy

•  Ini/al model: Limi/ng the number of cars (FUN-‐2)

•  First refinement: Introducing the one way bridge (FUN-‐3)

•  Second refinement: Introducing the traffic lights (EQP-‐1,2,3)

•  Third refinement: Introducing the sensors (EQP-‐4,5)

23

Example: Ini/al Model

24

Bridge and island

Mainland

ML-‐out

ML-‐in

ML-‐out: leave mainland ML-‐in: enter mainland

Example: Constants and Axioms

•  Context: constant d with axiom axm01 –  d is the maximum number of cars allowed on the Island-‐Bridge.

–  axm01 states that d ∈ N is a natural number

•  Machine: variable v with invariants inv01 and inv02. –  n is the effec/ve number of cars on the Island-‐Bridge.

–  n is a natural number (inv0 1). –  n is always smaller than or equal to d (inv0 2).

25

Example: Events

•  Event ML out increments the number of cars – ML_out n := n + 1

•  Event ML in decrements the number of cars. – ML_in n := n − 1

•  two invariants: –  inv01: n∈N

–  inv02: n≤d •  Thus, we need to prove four proof obliga/ons

26

PO for ML out and inv01 and inv02

•  ML_out n := n + 1 , (n′ = n + 1) – d∈N ∧ n∈N ∧ n ≤ d ⊢ n+1∈ N inv01

•  ML_out n := n + 1, (n′ = n + 1) – d∈N ∧ n∈N ∧ n≤d ⊢ n+1 ≤ d inv02

•  Proof fails: n ≤ d ⊢ n+1 ≤ d we cannot conclude with rule INC (n < d needed)

27

Reasons for Proof Failure

•  We needed hypothesis n<d to prove MLout /inv02/INV

•  We needed hypothesis 0<n to prove MLin /inv01/INV

•  We are going to add n < d as a guard to event ML_out

•  We are going to add 0 < n as a guard to event ML_in

28

Introducing Guards

•  ML out when n<d then n := n + 1 end •  ML in when 0<n then n := n − 1 end

29

RODIN

•  Run example in RODIN

30

References

1  Logic of Specification Languages, Dines Bjorner and Martin C. Henson, Springer 2008

2  Modeling in Event-BSystem and Software Engineering, Jean-Raymond Abrial, Cambridge University Press, 2010

3  Event-‐B Language, C. Métayer (ClearSy) J.-‐R. Abrial, L. Voisin (ETH Zürich), 2005

4  The event-B website. http://www.event-b.org/

31

McMaster University Department of Computing and Software

CAS707: Formal Specification Techniques The Typed Logic of Partial Functions

and VDM

Samir Al-Janabi April 5th, 2011

2

Outline

  Introduction   Big Picture of VDM Method   VDM-SL: Biased Queue Example-Introductory Example   VDM-SL   Motivation for Formal Proof   Formal Proof in VDM   A Proof Framework for VDM-Mural   Big Picture of Typed Logic of Partial Functions   The Typed Logic of Partial Functions   Theories Supporting VDM-SL   VDMTools   VDMTools of VDM-SL   Conclusion

3

Introduction

  VDM (Vienna Development Method) is a collection of techniques for the modeling, specification, and design of computer-based systems.

  It is one of the longest-established Formal Methods. Originating in work done at IBM's Vienna Laboratory in the 1970s.

  VDM’s roots lie in work on programming language definition, notably the attempt to give a formal definition of the semantics of the PL/I language using a notation that came to be known as the Vienna Definition Language (VDL).

4

Introduction (Continued)

  It has grown to include a group of techniques and tools based on a formal specification language - the VDM Specification Language (VDM-SL).

  VDM-SL is a model-oriented language.   It has an extended form, VDM++, which supports the

modeling of object-oriented and concurrent system.

5

Big Picture of VDM Method

6

VDM-SL: Biased Queue Example- Introductory Example

7

VDM-SL

 A model in VDM-SL consists of:   Data types   States   Functions:

  Implicit, i.e. specified in terms of pre- and post-conditions.

  Explicit: i.e. functions are expressions of input as in functional programming.

  Operations: change states of the model

8

VDM-SL: Basic Types

bool Boolean datatype nat natural numbers (including zero) nat1 natural numbers (excluding zero) int integers rat Rational numbers real Real numbers char characters token structureless tokens <A> the quote type containing the value <A>

9

VDM-SL: Type Constructors

T1 | T2 | ... | Tn Union of types T1,...,Tn

T1*T2*...*Tn Cartesian product of types T1,...,Tn

T :: f1:T1 ... fn:Tn Composite (Record) type

Example: The previous example. QUEUEB is a composite type

10

VDM-SL: Collections

  Sets   The set type constructor (written set of T

where T is a predefined type) constructs the type composed of all finite sets of values drawn from the type T.

Example: UGroup = set of UserId

11

VDM-SL: Collections (Continued)

  Sequences   The finite sequence type constructor

(written seq of T where T is a predefined type) constructs the type composed of all finite lists of values drawn from the type T.

Example: String = seq of char

12

VDM-SL: Collections (Continued)

  Mapping   The mapping type constructor in VDM-SL

(written map T1 to T2) whereT1 and T2 are predefined types) constructs the type composed of all finite mappings from sets of T1 values to sets of T2 values.

Example: Birthdays = map String to Date

13

VDM-SL: Functions

  Implicit Functions   Instead of a formula computing a result, the

precondition and postcondition together form a contract that to be satisfied by any program claiming to implement the function.

Example: SQRT(x:nat) r : real post r*r = n

14

VDM-SL: Functions

  Explicit Functions   The result is defined by means of an

expression over the inputs.

Example: SqList: seq of nat -> seq of nat SqList(s) == if s = [ ] then [ ] else [(hd s)**2] ^ SqList(tl s)

15

VDM-SL: Operations

  Functions do not change the state of a persistent global variable.

  Operations are used to change state variables.

Example: ENQUEUE(e:Qel) ext wr s : seq of Qel post s = s~ ^ [e];

16

Motivation for Formal Proof

  The aspect of model consistency that cannot be checked give rise to proof obligations.

Example: There is a satisfiability obligation on implicit operations

specifications.

  We also want to prove properties about our model, e.g. safety, liveness, etc.

  Formal proofs provide greater confidence because proofs are verified by machine.

17

Formal Proof in VDM

  In formal proof of Statisfiability, the inference is done, for example, at line 5 by appealing to a specific lemma.

....

18

A Proof Framework for VDM-Mural

  The mural system consists of two parts, a VDM support tool and a proof assistant.

  The mural interface is based around a series of tools. Each tool occupies a separate window and provides a means of creating, inspecting and interacting with the different types of object within the system.

19

A Proof Framework for VDM-Mural (continued)

  Symbols   Three kinds of symbols

1.  Variables 2.  Constants: represent value and type

constructors. Examples: singleton sequence [ _ ], empty set { }

3.  Binders Examples: ∀, ∃

20


  Expressions 1.  Variable symbol 2.  Constant symbol with the correct number

of argument instantiated 3.  Binder binding a variable in another

expression

21


  Rules of Inference   An inference rule consists of a set of

hypotheses, shown above a horizontal line, and a conclusion shown below the line. A name for the rule may be given in a box to the left of the line.

Example:

22


  Proofs   Proofs are represented as arguments from

hypotheses to the conclusion.   Each proof is organized into blocks bounded

by from and infer lines.   Each justification is an appeal to an

inference rule or a folding/unfolding of a syntactic definition.

23


The proof might have the following form:

Example: Consider the following Conjecture:

24


  Theories   A theory is a collection of constant and binder

definitions, axioms and derived results and their proofs.

Big Picture of Typed Logic of Partial Functions

25

26

The Typed Logic of Partial Functions

  The Logic of Partial Functions (LPF) is a first-order predicate logic which admits undefined terms resulting from the application of partial functions.

  Partial functions are commonplace in computing.

Example: Partial Function. pop( ): e:elem If pop( ) on empty stack? then the result is undefined.

27

The Typed Logic of Partial Functions: Propositional LPF

  Aside from the logical values true and false, LPF admits undefined terms, denoted by . Example: The expression A \/ B evaluates to true if either

disjunct evaluates to true, even if the other disjunct is undefined.

28

The Typed Logic of Partial Functions: Propositional LPF (Continued)

  True, \/ and ¬ are built-in logical constants. False, /\, etc. are defined by syntactic definitions

29


  The axioms are similar to those of classical propositional logic except for the absence of the law of the excluded middle:

  In order to recover the full power of classical logic for propositions and predicates that are well defined, a definedness judgment is added.

30


  This allow the derivation of the qualified version of the Deduction Theorem that holds in LPF:

  In general, theorems of classical logic can be formed into theorems of LPF by adding the necessary δ hypotheses.

The Typed Logic of Partial Functions: Predicate LPF with Equality

  The logical framework treats quantifiers as binders, with a type restricting the bound variable.

31

  Universal Quantification is defined by syntactic definition.

32

The Typed Logic of Partial Functions: Predicate LPF with Equality (Continued)

  LPF equality is weak in that it is only defined over denoting terms.

33

Theories Supporting VDM-SL

  Theories are necessary to reason about constructs in VDM-SL. For example, when we want to reason about naturals and sets in a VDM-SL model, we need a theories of nat and sets respectively.

  Two types:   Generic: General theories are provided for type

constructors which are used to build collection types including finite sets, sequences and mappings.

  Model-specific: Certain other constructors, such as records, are better handled on a per-model basis, translated into definitions and axiom sets in terms of the constructs in the VDM theories.

34

Theories Supporting VDM-SL: Generic Theories

 Example: Theory of finite sets.

  The axiomatisation is given in terms of constructors introduced as constants. In the case of sets these are the empty set ({ }) and an add operator.

35

Theories Supporting VDM-SL: Model-Specific Theories

 Example:   VDM type definition from Queueb example:

  The formation axiom for the selector .s is:

36

VDMTools

  VDMTools is a set of tools that provide supports for:   Syntax checker   Type checker   Integrity Examiner   Interpreter and debugger   Test coverage statistics tool   Rose - VDM++ link   Pretty Printer   VDM++ to C++ code generator (Optional)   VDM++ to Java code generator (Optional)   Java to VDM++ generator (Optional)   CORBA Compliant API (Optional)

  The models are expressed either in the VDM-SL standard language or in the object-oriented formal specification language VDM++.

37

VDMTools of VDM-SL: An Overview of the Functionality

38

VDMTools of VDM-SL : Example - Syntax Checking of VDM Specifications

39

Conclusion

  VDM has a VDM-SL specification language, supports formal proof based on Typed Logic of Partial Functions, and tools support, e.g VDMTools.

  VDM-SL is a Model-oriented Specification Language.   Typed Logic of Partial Functions is used to support

reasoning about models in VDM-SL.   The VDMTools supports software development based

on the specification which is written by formal specification language, VDM-SL or VDM++.

40

References

  Bjorner, D, Henson, M, Logics of Specification Languages, 2008 Springer-Verlag Berlin Heidelberg

  Muller, A, VDM - The Vienna Development Method, April 20, 2009, http://www.risc.jku.at/publications/download/risc_3820/main.pdf

  Wikipedia, http://en.wikipedia.org/wiki/VDM_specification_language

  VDMTools User Manual, (VDM-SL) http://www.vdmtools.jp/uploads/manuals/usermansl_a4E.pdf

petri nets - mcmaster university · 2017. 3. 8. · petri net tools • graphical editor •...

Documents