Stochastic Process Algebras - Informatics Homepages Server

Introduction

Model Analysis

Tool Support

Stochastic Process Algebras Jane Hillston and Mirco Tribastone. LFCS, University of Edinburgh 29th May 2007

Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Conclusion

Introduction

Model Analysis

Tool Support

Modelling with Markov chains

In his lecture on Monday Billy Stewart said that there are three steps to modelling with Markov chains:


Conclusion

Introduction

Model Analysis

Tool Support


In his lecture on Monday Billy Stewart said that there are three steps to modelling with Markov chains: 1. Conceptualise your system as a Markov chain;


Conclusion

Introduction

Model Analysis

Tool Support


In his lecture on Monday Billy Stewart said that there are three steps to modelling with Markov chains: 1. Conceptualise your system as a Markov chain; 2. Construct your Markov chain — construct an infinitesimal generator matrix Q.


Conclusion

Introduction

Model Analysis

Tool Support


In his lecture on Monday Billy Stewart said that there are three steps to modelling with Markov chains: 1. Conceptualise your system as a Markov chain; 2. Construct your Markov chain — construct an infinitesimal generator matrix Q. 3. Solve your Markov chain to derive quantitative information about the system.


Conclusion

Introduction

Model Analysis

Tool Support


In his lecture on Monday Billy Stewart said that there are three steps to modelling with Markov chains: 1. Conceptualise your system as a Markov chain; 2. Construct your Markov chain — construct an infinitesimal generator matrix Q. 3. Solve your Markov chain to derive quantitative information about the system.


Conclusion

Introduction

Model Analysis

Outline

Introduction Model Analysis Tool Support Conclusion


Tool Support

Conclusion

Introduction

Model Analysis

Outline



Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I

Models consist of agents which engage in actions.

* action type or name


α.P H Y

HH

agent/ component

Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I




α.P H Y

HH

agent/ component

Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I




α.P H Y

HH

agent/ component

Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I



I

α.P H Y

HH

agent/ component

The structured operational (interleaving) semantics of the language is used to generate a labelled transition system.


Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I



I

α.P H Y

HH

agent/ component


Process algebra model


Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I


* action type

α.P H Y

HH

or name

I

agent/ component



SOS rules -


Conclusion

Introduction

Model Analysis

Tool Support

Process Algebra I


* action type

α.P H Y

HH

or name

I

agent/ component



SOS rules -


Labelled transition system

Conclusion

Introduction

Model Analysis

Tool Support

Example Consider a web server which offers html pages for download: def

Server = g et.download.r el.Server


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


Server = g et.download.r el.Server Its clients might be web browsers, in a domain with a local cache of frequently requested pages. Thus any display request might result in an access to the server or in a page being loaded from the cache. def

Browser = display .(cache.Browser + g et.download.r el.Browser )


Introduction

Model Analysis

Tool Support

Conclusion


Server = g et.download.r el.Server Its clients might be web browsers, in a domain with a local cache of frequently requested pages. Thus any display request might result in an access to the server or in a page being loaded from the cache. def

Browser = display .(cache.Browser + g et.download.r el.Browser ) A simple version of the Web can be considered to be the interaction of these components: def

W EB =

Browser k Browser | Server


Introduction

Model Analysis

Tool Support

Dynamic behaviour I

The behaviour of a model is dictated by the semantic rules governing the combinators of the language.


Conclusion

Introduction

Model Analysis

Tool Support

Dynamic behaviour I


I

The possible evolutions of a model are captured by applying these rules exhaustively, generating a labelled transition system.


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Dynamic behaviour I


I


I

This can be viewed as a graph in which each node is a state of the model (comprised of the local states of each of the components) and the arcs represent the actions which can cause the move from one state to another.


Introduction

Model Analysis

Tool Support

Conclusion

Dynamic behaviour I


I


I

This can be viewed as a graph in which each node is a state of the model (comprised of the local states of each of the components) and the arcs represent the actions which can cause the move from one state to another.

I

The language is also equipped with observational equivalence which can be used to compare models.


Introduction

Model Analysis

Tool Support

Conclusion

Dynamic behaviour def



Introduction

Model Analysis

Tool Support

Conclusion



α

α.P −→ P α

P −→ P 0 α

P + Q −→ P 0 α

Q −→ Q 0 α

P + Q −→ Q 0


Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H

HH display ? H cache.Browser + g et.downloadr el.Browser HH

α

P −→ P 0 α

P + Q −→ P 0

H r el

g et ? download.r el.Browser

α

Q −→ Q 0 α

P + Q −→ Q 0


download ? r el.Browser

Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H


α

P −→ P 0 α

P + Q −→ P 0

H r el


α

Q −→ Q 0 α

P + Q −→ Q 0



Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H


α

P −→ P 0 α

P + Q −→ P 0

H r el


α

Q −→ Q 0 α

P + Q −→ Q 0



Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H


α

P −→ P 0 α

P + Q −→ P 0

H r el


α

Q −→ Q 0 α

P + Q −→ Q 0



Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H


α

P −→ P 0 α

P + Q −→ P 0

H r el


α

Q −→ Q 0 α

P + Q −→ Q 0



Introduction

Model Analysis

Tool Support

Conclusion



Browser cache

α

α.P −→ P

HH Y H


α

P −→ P 0 α

P + Q −→ P 0

H r el


α

Q −→ Q 0 α

P + Q −→ Q 0



Introduction

Model Analysis

Tool Support

Conclusion

Qualitative Analysis I

The labelled transition system underlying a process algebra model can be used for functional verification e.g.: reachability analysis, specification matching and model checking.


Introduction

Model Analysis

Tool Support

Conclusion



Will the system arrive in a particular state?


e - e e - ee - e e h ? e e

Introduction

Model Analysis

Tool Support

Conclusion



Does system behaviour match its specification?

e e - e 6 ? e - e - e≡ e - ee - e e ? ? e e e


Introduction

Model Analysis

Tool Support

Conclusion



Does a given property φ hold within the system?


e e φ P e -e e - e PP PP e PP ? e eP

Introduction

Model Analysis

Tool Support

Performance Evaluation Process Algebra I

Models are constructed from components which engage in activities.

(α, r ).P H Y

action type or name

*

6

HH

activity rate (parameter of an exponential distribution)


component/ derivative

Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH




Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH




Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH




Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling.


Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling. PEPA MODEL


Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling. PEPA SOS rules MODEL


Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling. PEPA SOS rules - LABELLED TRANSITION MODEL SYSTEM


Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling. state transition PEPA SOS rules - LABELLED TRANSITION MODEL diagram SYSTEM


Conclusion

Introduction

Model Analysis

Tool Support



(α, r ).P H Y

action type or name

*

6

HH



I

The language is used to generate a CTMC for performance modelling. state transition PEPA SOS rules - LABELLED - CTMC Q TRANSITION MODEL diagram SYSTEM


Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A

C P | P/L P ::= S | P B L


Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A

C P | P/L P ::= S | P B L PREFIX:

(α, r ).S


designated first action

Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A


(α, r ).S


CHOICE:

S +S

competing components (race policy)


Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A


(α, r ).S


CHOICE:

S +S


CONSTANT:

A=S

def


assigning names

Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A


(α, r ).S


CHOICE:

S +S


CONSTANT:

A=S

assigning names

COOPERATION:

CP PB L

α∈ / L concurrent activity (individual actions) α ∈ L cooperative activity (shared actions)

def


Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A


(α, r ).S


CHOICE:

S +S


CONSTANT:

A=S

assigning names

COOPERATION:

CP PB L


def


Conclusion

Introduction

Model Analysis

Tool Support

PEPA S

::= (α, r ).S | S + S | A


(α, r ).S


CHOICE:

S +S


CONSTANT:

A=S

assigning names

COOPERATION:

CP PB L


HIDING:

P/L

abstraction α ∈ L ⇒ α → τ

def


Conclusion

Introduction

Model Analysis

Tool Support

Example revisited The behaviour of the server is the same but now quantitative information is recorded for each operation: def

Server = (g et, >).(download, µ).(r el, >).Server


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


Server = (g et, >).(download, µ).(r el, >).Server In addition to duration we also incorporate information about the relative frequencies of the different actions which take place after a display request: Browser

def

=

(display , p1 λ).(cache, m).Browser + (display , p2 λ).(g et, g ).(download, >).(r el, r ).Browser


Introduction

Model Analysis

Tool Support

Conclusion



def

=


The configuration is recorded as before; using the PEPA cooperation the actions which must be shared are explicitly named: def C Server W EB = Browser k Browser B L L = {g et, download, rel} Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion



def

=


The configuration is recorded as before; using the PEPA cooperation the actions which must be shared are explicitly named: def C Server W EB = Browser k Browser B L L = {g et, download, rel} Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification:


Conclusion

Introduction

Model Analysis

Tool Support

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification: Reachability analysis

How long will it take for the system to arrive in a particular state?


e - e e - ee - e e h ? e e

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification: Specification matching

With what probability does system behaviour match its specification?

e 6

e

? e


e - e

? e - e - e∼ ee - e = e -e

? e

Introduction

Model Analysis

Tool Support

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification: Specification matching

Does the “frequency profile” of the system match that of the specification?

e - e 0.5 0.6 e - e - e e - ee - e 0.4 e ? ? e 0.5 e e


e 6

Conclusion

Introduction

Model Analysis

Tool Support

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification: Model checking

Does a given property φ hold within the system with a given probability?


e - e φ ee - e PP e - PP PPe P? e eP

Conclusion

Introduction

Model Analysis

Tool Support

Integrated analysis

I

Qualitative verification can now be complemented by quantitative verification: Model checking

For a given starting state how long is it until a given property φ holds?


e - e φ ee - e PP e - PP PPe P? e eP

Conclusion

Introduction

Model Analysis

SPA Languages

SPA


Tool Support

Conclusion

Introduction

Model Analysis

SPA Languages

integrated time

SPA @ @ @ @ @

orthogonal time


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

SPA Languages exponential only

integrated time

exponential + instantaneous @ @ @ @ general distributions

SPA @ @ @ @ @

orthogonal time


Introduction

Model Analysis

Tool Support

Conclusion

SPA Languages exponential only

integrated time


SPA @

exponential only

@ @ @ @

orthogonal time Q

Q Q Q general distributions


Introduction

Model Analysis

Tool Support

Conclusion

SPA Languages exponential only PEPA, Stochastic π-calculus

integrated time


SPA @

exponential only

@ @ @ @

orthogonal time Q



Introduction

Model Analysis

Tool Support

Conclusion


integrated time

exponential + instantaneous EMPA, Markovian TIPP @ @ @ general distributions

@

SPA @

exponential only

@ @ @ @

orthogonal time Q



Introduction

Model Analysis

Tool Support

Conclusion


integrated time

exponential + instantaneous EMPA, Markovian TIPP @ @ @ general distributions TIPP, SPADES, GSMPA

@

SPA @

exponential only

@ @ @ @

orthogonal time Q



Introduction

Model Analysis

Tool Support

Conclusion


integrated time


@

SPA @

exponential only IMC

@ @ @ @

orthogonal time Q



Introduction

Model Analysis

Tool Support

Conclusion


integrated time


@

SPA @


@ @ @ @

orthogonal time Q

Q Q Q general distributions IGSMP, Modest


Introduction

Model Analysis

Tool Support

Conclusion


integrated time


@

SPA @


@ @ @ @

orthogonal time Q

Q Q Q general distributions IGSMP, Modest


Introduction

Model Analysis

Tool Support

The Importance of Being Exponential (α, r ).Stop k (β, s).Stop (α, r )

Stop k (β, s).Stop

@ (β, s) @ R @

(α, r ).Stop k Stop

@

(α, r )

(β, s)@ @ R Stop k Stop


Conclusion

Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )



Conclusion

Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )



Conclusion

Introduction

Model Analysis

Tool Support


(α, r ) (β, s)

Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )

(β, s)@

? @ R Stop k Stop


Conclusion

Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )



Conclusion

Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )



Conclusion

Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )



Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )


The memoryless property of the negative exponential distribution means that residual times do not need to be recorded.


Introduction

Model Analysis

Tool Support


Stop k (β, s).Stop

@ (β, s) @ R @


@

(α, r )


We retain the expansion law of classical process algebra: (α, r ).Stop k (β, s).Stop = (α, r ).(β, s).(Stop k Stop) + (β, s).(α, r ).(Stop k Stop) only if the negative exponential distribution is assumed. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Conclusion

Introduction

Model Analysis

Tool Support

Parallel Composition

I

Parellel composition is the basis of the compositionality in a process algebra


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


I

Parellel composition is the basis of the compositionality in a process algebra — it defines which components interact and how.


Introduction

Model Analysis

Tool Support

Conclusion


I


I

In classical process algebra is it often associated with communication.


Introduction

Model Analysis

Tool Support

Conclusion


I


I

In classical process algebra is it often associated with communication.

I

When the activities of the process algebra have a duration the definition of parallel composition becomes more complex.


Introduction

Model Analysis

Tool Support

Who Synchronises...? Even within classical process algebras there is variation in the interpretation of parallel composition:


Conclusion

Introduction

Model Analysis

Tool Support

Who Synchronises...? Even within classical process algebras there is variation in the interpretation of parallel composition: CCS-style I I

I

Actions are partitioned into input and output pairs. Communication or synchronisation takes places between conjugate pairs. The resulting action has silent type τ .


Conclusion

Introduction

Model Analysis

Tool Support


I



Conclusion

Introduction

Model Analysis

Tool Support


I



Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


I



CSP-style I I

I

No distinction between input and output actions. Communication or synchronisation takes place on the basis of shared names. The resulting action has the same name.

Introduction

Model Analysis

Tool Support

Conclusion


I



CSP-style I I

I


Introduction

Model Analysis

Tool Support

Conclusion


I



CSP-style I I

I


Introduction

Model Analysis

Tool Support

Conclusion


I


CSP-style I I

I


Most stochastic process algebras adopt CSP-style synchronisation. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Timed Synchronisation I

The issue of what it means for two timed activities to synchronise is a vexed one....


Conclusion

Introduction

Model Analysis

Tool Support


P1

P2

The issue of what it means for two timed activities to synchronise is a vexed one.... r1 s1

r2 s2


r? s?

Conclusion

Introduction

Model Analysis

Tool Support


P1

P2

The issue of what it means for two timed activities to synchronise is a vexed one.... r1

r1

s1

s1 s = max(s 1, s 2)

r2

r2

s2

s2

Barrier Synchronisation


Conclusion

Introduction

Model Analysis

Timed Synchronisation


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support


P1

P2


r1

s1

s1 s = max(s 1, s 2)

r2

r2

s2

s2

s is no longer exponentially distributed


Conclusion

Introduction

Model Analysis

Tool Support


P1

P2

The issue of what it means for two timed activities to synchronise is a vexed one.... r1 s1

r? s?

r2 s2

algebraic considerations limit choices


Conclusion

Introduction

Model Analysis

Tool Support


P1

P2


r1

s1

s1 r = r1x r 2

r2

r2

s2

s2

TIPP: new rate is product of individual rates


Conclusion

Introduction

Model Analysis



Tool Support

Conclusion

Introduction

Model Analysis

Tool Support


P1

The issue of what it means for two timed activities to synchronise is a vexed one.... r1 =?

r1 =? r = r2

P2

r2

r2

s2

s2

EMPA: one participant is passive


Conclusion

Introduction

Model Analysis

Tool Support

Timed Synchronisation UNLEADED PETROL

UNF 738 S


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


P1

P2


r1

s1

s1 r = min(r1 , r 2)

r2

r2

s2

s2

bounded capacity: new rate is the minimum of the rates


Introduction

Model Analysis



Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Cooperation in PEPA

I

In PEPA each component has a bounded capacity to carry out activities of any particular type, determined by the apparent rate for that type.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation in PEPA

I


I

Synchronisation, or cooperation cannot make a component exceed its bounded capacity.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation in PEPA

I


I

Synchronisation, or cooperation cannot make a component exceed its bounded capacity.

I

Thus the apparent rate of a cooperation is the minimum of the apparent rates of the co-operands.


Introduction

Model Analysis

Outline



Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

PEPA Case Studies (1) I

Multiprocessor access-contention protocols (Gilmore, Hillston and Ribaudo, Edinburgh and Turin)

I

Protocols for fault-tolerant systems (Clark, Gilmore, Hillston and Ribaudo, Edinburgh and Turin)

I

Multimedia traffic characteristics (Bowman et al, Kent)

I

Database systems (The STEADY group, Heriot-Watt University)

I

Software Architectures (Pooley, Bradley and Thomas, Heriot-Watt and Durham)

I

Switch behaviour in active networks (Hillston, Kloul and Mokhtari, Edinburgh and Versailles)


Introduction

Model Analysis


Locks and movable bridges in inland shipping in Belgium (Knapen, Hasselt)


Tool Support

Conclusion

Introduction

Model Analysis



I

Robotic workcells (Holton, Gilmore and Hillston, Bradford and Edinburgh)


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion



I


I

Cellular telephone networks (Kloul, Fourneau and Valois, Versailles)


... ... ... ... ... ... ... ...

... ... ... ...

... ... ... ... ... ... ... ...

Introduction

Model Analysis



I


I

Cellular telephone networks (Kloul, Fourneau and Valois, Versailles)

I

Automotive diagnostic expert systems (Console, Picardi and Ribaudo, Turin)


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Tool Support Imperial PEPA Compiler/Dnamaca and Hydra

PEPA Workbench (Edinburgh University)

(Imperial College)

@ I @

M¨ obius modelling platform

@

PEPA

(University of Illinois)

-

PEPAroni simulation engine

(Edinburgh University) ?

PRISM model checker (Birmingham University)


Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support



(Imperial College)

@ I @


@

PEPA


-





Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Roland the Gunslinger

I

This sequence of small examples are based around a character called Roland Deschain.


Introduction

Model Analysis

Tool Support

Conclusion


I


I

Roland is a gunslinger and his life consists of wandering around firing his gun.


Introduction

Model Analysis

Tool Support

Conclusion


I


I


I

We will consider Roland in a number of different scenarios.


Introduction

Model Analysis

Tool Support

Conclusion


I


I


I

We will consider Roland in a number of different scenarios. These are not intended to be serious but they serve to

I


Introduction

Model Analysis

Tool Support

Conclusion


I


I


I


I

I

illustrate the main features of the language,


Introduction

Model Analysis

Tool Support

Conclusion


I


I


I


I

I I

illustrate the main features of the language, give you some experience of how models are constructed, and


Introduction

Model Analysis

Tool Support

Conclusion


I


I


I


I

I I I

illustrate the main features of the language, give you some experience of how models are constructed, and demonstrate a variety of solution techniques.


Introduction

Model Analysis

Tool Support

Roland alone In the first scenario we consider Roland alone, with the single activity of firing his gun which is a six-shooter. When his gun is empty Roland will reload the gun and then continue shooting. def

Roland6 = (fire, rfire ).Roland5 def





Roland1 = (fire, rfire ).Rolandempty Rolandempty

def

= (reload, rreload ).Roland6


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Roland with two guns All self-respecting gun-slingers have one gun in each hand. A simplistic way to model this is two instances of Roland in parallel: Roland6 k Roland6


Introduction

Model Analysis

Tool Support

Conclusion

Roland with two guns All self-respecting gun-slingers have one gun in each hand. A simplistic way to model this is two instances of Roland in parallel: Roland6 k Roland6 But this model does not capture the fact that Roland needs both hands in order to reload either gun. Thus we might assume that Roland only reloads both guns when both are empty.

BC Roland6 Roland6 {reload}


Introduction

Model Analysis

Tool Support

Conclusion

Roland with two guns All self-respecting gun-slingers have one gun in each hand. A simplistic way to model this is two instances of Roland in parallel: Roland6 k Roland6 But this model does not capture the fact that Roland needs both hands in order to reload either gun. Thus we might assume that Roland only reloads both guns when both are empty.

BC Roland6 Roland6 {reload} From now on we restrict Roland to his shotgun, which has two bullets and requires both hands for firing.


Introduction

Model Analysis

Tool Support

Conclusion

Roland meets an Enemy I

Upon his travels Roland encounters some enemies and when he does so he must fight them.

I

Roland is the wildest gunslinger in the west so we assume that no enemy has the skill to seriously harm Roland.

I

Each time Roland fires he might miss or hit his target.

I

But with nothing to stop him he will keep firing until he successfully hits (and kills) the enemy.

I

We assume that some sense of cowboy honour prevents any enemy attacking Roland if he is already involved in a gun fight.


Introduction

Model Analysis

Tool Support

The model

def

Rolandidle = (attack, rattack ).Roland2 def

Roland2 = (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Roland1 def

Roland1 = (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Rolandempty def

Rolandempty = (reload, rreload ).Roland2


Conclusion

Introduction

Model Analysis

Tool Support

Parameter settings for the Roland2 model parameter rfire

value 1.0

phit-success rhit rmiss rreload

0.8 0.8 0.2 0.3

rattack

0.01

explanation Roland can fire the gun once per-second Roland has an 80% success rate rfire × phit-success rfire × (1 − phit-success ) It takes Roland about 3 seconds to reload Roland is attacked once every 100 seconds


Conclusion

Introduction

Model Analysis

Tool Support

Steady state analysis We can calculate the probability that at arbitrary time Roland is involved in a battle based on the steady state probability that Roland is in any of the states in which a battle is on-going, i.e. Roland2 , Roland1 and Rolandempty .


Conclusion

Introduction

Model Analysis

Tool Support

Steady state analysis We can calculate the probability that at arbitrary time Roland is involved in a battle based on the steady state probability that Roland is in any of the states in which a battle is on-going, i.e. Roland2 , Roland1 and Rolandempty . Or we can calculate the probability that Roland is in the state Rolandidle and subtract it from 1.


Conclusion

Introduction

Model Analysis

Tool Support

Steady state analysis We can calculate the probability that at arbitrary time Roland is involved in a battle based on the steady state probability that Roland is in any of the states in which a battle is on-going, i.e. Roland2 , Roland1 and Rolandempty . Or we can calculate the probability that Roland is in the state Rolandidle and subtract it from 1. State Measure ’roland peaceful’ mean 9.5490716180e-01 State Measure ’roland in battle’ mean 0.0450928382e-01


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Passage-Time Analysis

Passage-time analysis allows us to calculate measures such as the probability that Roland has killed his enemy at a given time after he is attacked.


Introduction

Model Analysis

Tool Support

Conclusion

Passage-Time Analysis

Passage-time analysis allows us to calculate measures such as the probability that Roland has killed his enemy at a given time after he is attacked. This would involve calculating the probability that the model performs a hit action within the given time after performing an attack action.


Introduction

Model Analysis

Tool Support

Conclusion

Passage-Time Analysis results Probability that Roland will have hit after an attack 1 0.9 0.8 0.7

Pr

0.6 0.5 0.4 0.3 0.2 0.1 0 0

1

2

3

4

5 time

6

7

8

9

10

The probability that Roland will successfully perform a hit action a given time after an attack.


Introduction

Model Analysis

Tool Support

Conclusion

Passage-Time Analysis results Probability that Roland will have missed after an attack 0.09 0.08 0.07 0.06 Pr

0.05 0.04 0.03 0.02 0.01 0 0

1

2

3

4

5 time

6

7

8

9

10

The probability that Roland has performed a miss action a given time after an attack action.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation

I

In the previous model Roland’s enemies were represented only implicitly.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation

I


I

We now consider a model in which the enemies appear explicitly and allow them to fight back.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation

I


I


I

However for now we still assume that there are rather ineffectual and so they never seriously injure Roland.


Introduction

Model Analysis

Tool Support

Conclusion

Cooperation

I


I


I

However for now we still assume that there are rather ineffectual and so they never seriously injure Roland.

I

This model can be used to calculate properties such as the likelihood that an enemy will manage to fire one shot before they are killed by Roland.


Introduction

Model Analysis

Tool Support

Revised Model def

(attack, >).Roland2 (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Roland1 (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Rolandempty (reload, rreload ).Roland2

Rolandidle Roland2

= def =

Roland1

=

Rolandempty

=

Enemiesidle Enemiesattack

= def =

def

(attack, rattack ).Enemiesattack (fire, re-miss ).Enemiesattack + (hit, >).Enemiesidle

BC

Enemiesidle

Roland2

def

def

{hit}


Conclusion

Introduction

Model Analysis

Tool Support

Additional parameters

parameter rattack re-miss

value 0.01 0.3

explanation Roland is attacked once every 100 seconds Enemies can fire only once every 3 seconds


Conclusion

Introduction

Model Analysis

Tool Support

Levels of abstraction I

Notice that in this model the behaviour of the enemy has been simplified.


Conclusion

Introduction

Model Analysis

Tool Support



I

There is no running out of bullets or reloading.


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion



I


I

This model can be thought of as an approximation to a more complicated component similar to the one which models Roland.


Introduction

Model Analysis

Tool Support

Conclusion



I


I


I

Here the rate at which the enemy fires encompasses all of the actions, including the reloading of an empty gun.


Introduction

Model Analysis

Tool Support

Conclusion



I


I


I

Here the rate at which the enemy fires encompasses all of the actions, including the reloading of an empty gun.

I

We may choose to model a component in such an abstract way when the focus of our modelling is really elsewhere in the model.


Introduction

Model Analysis

Tool Support

Conclusion

Model Validation

It is also sometimes useful to carry out a validation of the model by calculating a metric which we believe we already know the value of.


Introduction

Model Analysis

Tool Support

Conclusion

Model Validation

It is also sometimes useful to carry out a validation of the model by calculating a metric which we believe we already know the value of. For example in this model we could make such a sanity check by calculating the probability that the model is in a state in which Roland is idle but the enemies are not, or vice versa.


Introduction

Model Analysis

Tool Support

Conclusion

Model Validation

It is also sometimes useful to carry out a validation of the model by calculating a metric which we believe we already know the value of. For example in this model we could make such a sanity check by calculating the probability that the model is in a state in which Roland is idle but the enemies are not, or vice versa. This should never occur and hence the probability should be zero.


Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis I

Sensitivity analysis studies how much influence particular parameter values, such as activity rates, have on performance metrics calculated for the system as a whole.


Introduction

Model Analysis

Tool Support

Conclusion



I

A single activity in a PEPA model may have a significant impact on the dynamics of the model, or, conversely, may exert very little influence.


Introduction

Model Analysis

Tool Support

Conclusion



I


I

Sensitivity analysis is performed by solving the model many times while varying the rates slightly.


Introduction

Model Analysis

Tool Support

Conclusion



I


I

Sensitivity analysis is performed by solving the model many times while varying the rates slightly.

I

For this model we chose to vary three of the rates involved and measured the passage time between an attack and a hit activity, for each combination of rates.


Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of cumulative distribution function to hitSuccess

Pr

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

0.2

0.3

0.4 0.5 hitSuccess

0.6


0.7

0.8 0

1

10 89 7 6 45 Time 3 2

Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of cumulative distribution function to fireRate

Pr

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

0.4

0.5

0.6 0.7 fireRate

0.8


0.9

1 1 0

10 89 7 6 45 Time 3 2

Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of cumulative distribution function to reloadRate

Pr

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

0.1

0.15

0.2 0.25 reloadRate

0.3


0.35

0.4 0

1

10 89 7 6 45 Time 3 2

Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of the effect of reloadRate against hitSuccess

Pr

1 0.9 0.8 0.7 0.6 0.5 0.4

1 0.9 0.8 0.7 0.6 0.5 0.4

0.1

0.15

0.2 0.25 reloadRate

0.3


0.35

0.40.2

0.3

0.8 0.7 0.6 0.5 hitSuccess 0.4

Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of the effect of reloadRate against fireRate

Pr

0.85 0.8 0.75 0.7 0.65 0.6 0.55

0.85 0.8 0.75 0.7 0.65 0.6 0.55

0.1

0.15

0.2 0.25 reloadRate

0.3


0.35

0.40.4

0.5

1 0.9 0.8 0.7 fireRate 0.6

Introduction

Model Analysis

Tool Support

Conclusion

Sensitivity Analysis: Results Sensitivity of the effect of hitSuccess against fireRate

Pr

1 0.9 0.8 0.7 0.6 0.5 0.4

1 0.9 0.8 0.7 0.6 0.5 0.4

0.4

0.5

0.6 0.7 fireRate

0.8


0.9

1 0.2

0.3

0.8 0.7 0.6 0.5 hitSuccess 0.4

Introduction

Model Analysis

Tool Support

Conclusion

Accurate Enemies I

We now allow the enemies of Roland to actually hit him. This means that Roland may die. It is important to note that this has the consequence that the model will always deadlock. The underlying Markov process is no longer ergodic.


Introduction

Model Analysis

Tool Support

Conclusion

Accurate Enemies I


I

We assume that the enemies can only hit Roland once every 50 seconds. This rate approximates the rate of a more detailed model in which we would assign a process to the enemies which is much like that of the process which describes Roland.


Introduction

Model Analysis

Tool Support

Conclusion

Accurate Enemies I


I

We assume that the enemies can only hit Roland once every 50 seconds. This rate approximates the rate of a more detailed model in which we would assign a process to the enemies which is much like that of the process which describes Roland.

I

The only new parameter is re-hit which is assigned a value 0.02 to reflect this assumption.


Introduction

Model Analysis

Tool Support

New Roland def

Rolandidle = (attack, >).Roland2 def

Roland2 = (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Roland1 + (e-hit, >).Rolanddead def

Roland1 = (hit, rhit ).(reload, rreload ).Rolandidle + (miss, rmiss ).Rolandempty + (e-hit, >).Rolanddead def

Rolandempty = (reload, rreload ).Roland2 + (e-hit, >).Rolanddead def

Rolanddead = Stop Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Conclusion

Introduction

Model Analysis

Tool Support

New Enemy

Enemiesidle

=

def

(attack, rattack ).Enemiesattack

Enemiesattack

def

=

(e-hit, re-hit ).Enemiesidle

+

(hit, >).Enemiesidle

BC

Enemiesidle

Rolandidle

{hit,attack,e-hit}


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Model Analysis Steady-State Analysis Since there is an infinite supply of enemies eventually Roland will always die and the model will deadlock.


Introduction

Model Analysis

Tool Support

Conclusion

Model Analysis Steady-State Analysis Since there is an infinite supply of enemies eventually Roland will always die and the model will deadlock. Transient Analysis Transient analysis on this model can be used to calculate the probability that Roland is dead after a given amount of time. As time increases this should tend towards probability 1.


Introduction

Model Analysis

Tool Support

Conclusion

Model Analysis Steady-State Analysis Since there is an infinite supply of enemies eventually Roland will always die and the model will deadlock. Transient Analysis Transient analysis on this model can be used to calculate the probability that Roland is dead after a given amount of time. As time increases this should tend towards probability 1. Passage-Time Analysis Passage-time analysis could be used to calculate the probability of a given event happening at a given time after another given event, e.g. from an attack on Roland until he dies or wins the gun fight. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Roland makes a friend In the next revision of the model we introduce an accomplice who is befriended by Roland and who, when Roland is attacked, fights alongside him.


Introduction

Model Analysis

Tool Support

Conclusion

Roland makes a friend In the next revision of the model we introduce an accomplice who is befriended by Roland and who, when Roland is attacked, fights alongside him. In this scenario cooperation is used to synchronise between components of the model such that they observe events which they neither directly cause nor are directly affected by.


Introduction

Model Analysis

Tool Support

Conclusion

Roland makes a friend In the next revision of the model we introduce an accomplice who is befriended by Roland and who, when Roland is attacked, fights alongside him. In this scenario cooperation is used to synchronise between components of the model such that they observe events which they neither directly cause nor are directly affected by. Whenever either Roland or the accomplice kills the enemy the other must witness this action, so as to stop firing at a dead opponent (it would be a waste of ammunition!).


Introduction

Model Analysis

Tool Support

A new component for Roland def

Rolandidle = (attack, >).Roland2 + (befriend, rbefriend ).Rolandidle def

Roland2 = (hit, rhit ).Rolandhit + (miss, rmiss ).Roland1 + (a-hit, >).Rolandidle def

Roland1 = (hit, rhit ).Rolandhit + (miss, rmiss ).Rolandempty + (a-hit, >).Rolandidle def

Rolandhit = (reload, rreload ).Rolandidle def

Rolandempty = (reload, rreload ).Roland2 + (a-hit, >).Rolandhit Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Conclusion

Introduction

Model Analysis

Tool Support

Synchronising Roland and the Accomplice I

When there is an accomplice, he and Roland fight together against the enemy — this involves some cooperation.


Conclusion

Introduction

Model Analysis

Tool Support


I

I

When there is an accomplice, he and Roland fight together against the enemy — this involves some cooperation. This could leave Roland vulnerable when there is no accomplice present. To prevent this we introduce a dummy component representing the absence of an accomplice.


Conclusion

Introduction

Model Analysis

Tool Support


I

I

When there is an accomplice, he and Roland fight together against the enemy — this involves some cooperation. This could leave Roland vulnerable when there is no accomplice present. To prevent this we introduce a dummy component representing the absence of an accomplice.


Conclusion

Introduction

Model Analysis

Tool Support


I

I

I

When there is an accomplice, he and Roland fight together against the enemy — this involves some cooperation. This could leave Roland vulnerable when there is no accomplice present. To prevent this we introduce a dummy component representing the absence of an accomplice. In this state the accomplice component will passively participate in any attack which Roland makes.


Conclusion

Introduction

Model Analysis

Tool Support


I

I

I

When there is an accomplice, he and Roland fight together against the enemy — this involves some cooperation. This could leave Roland vulnerable when there is no accomplice present. To prevent this we introduce a dummy component representing the absence of an accomplice. In this state the accomplice component will passively participate in any attack which Roland makes. def

Acmplabs = (befriend, rbefriend ).Acmplidle + (hit, >).Acmplabs + (attack, >).Acmplabs


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Component for the Accomplice

def

Acmplidle = (attack, >).Acmpl2 def

Acmpl2 = (a-hit, ra-hit ).Acmplhit + (hit, >).Acmplidle + (miss, rmiss ).Acmpl1 + (enemy-hit, >).Acmplabs def

Acmpl1 = (a-hit, ra-hit ).Acmplhit + (hit, >).Acmplhit + (miss, rmiss ).Acmplempty + (enemy-hit, >).Acmplabs def

Acmplhit = (reload, ra-reload ).Acmplidle def

Acmplempty = (reload, ra-reload ).Acmpl2 + (hit, >).Acmplhit


Introduction

Model Analysis

Tool Support

Parameter Settings for the Accomplice parameter rbefriend

value 0.001

ra-fire

1.0

pa-hit-success

0.6

ra-hit ra-miss ra-reload

0.6 0.4 0.25

explanation Roland befriends a stranger once every 1000 seconds the accomplice can also fire once per second the accomplice has a 60 percent accuracy rfire × phit-success rfire × (1.0 − phit-success ) it takes the accomplice 4 seconds to reload


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Component for the Enemy The component representing the enemy is similar to before. def

Enemiesidle = (attack, rattack ).Enemiesattack def

Enemiesattack = (enemy-hit, re-hit ).Enemiesattack + (hit, >).(enemy-die, re-die ).Enemiesidle + (a-hit, >).(enemy-die, re-die ).Enemiesidle

The system equation is as follows: (Rolandidle

B C

{attack,hit,a-hit,befriend}

BC Acmplabs ) {attack,hit,a-hit,enemy-hit} Enemiesidle


Introduction

Model Analysis

Tool Support

Model Analysis Steady-State Analysis I

As before we can determine the probability that Roland is involved in a gun battle at an arbitrary time.


Conclusion

Introduction

Model Analysis

Tool Support



I

We could also determine the likelihood that Roland has an accomplice at an arbitrary time.


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion



I


I

Since Roland cannot perform a befriending action while currently involved in a battle, the probabilty that Roland is in such a battle clearly affects the probability that he is alone in his quest.


Introduction

Model Analysis

Tool Support

Conclusion



I


I

Since Roland cannot perform a befriending action while currently involved in a battle, the probabilty that Roland is in such a battle clearly affects the probability that he is alone in his quest.

I

For example, if Roland’s success rate is reduced, gun battles will take longer to resolve and Roland will be involved in a gun battle more often. Consequently he will befriend fewer accomplices.


Introduction

Model Analysis

Tool Support

Conclusion

Model Analysis Transient Analysis An example transient analysis would be to determine the expected time after Roland has set off before he meets his first accomplice.


Introduction

Model Analysis

Model Analysis


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Model Analysis Passage-Time Analysis I

An example analysis would be to calculate the passage-time from an attack action until the death of the enemy or of the accomplice.


Introduction

Model Analysis

Tool Support

Conclusion



I

Since all gun battles now end in the enemy being killed stopping the analysis there would give us the expected duration of any one gun battle.


Introduction

Model Analysis

Tool Support

Conclusion



I

Since all gun battles now end in the enemy being killed stopping the analysis there would give us the expected duration of any one gun battle.

I

There is also the possibility to start the analysis from the befriend action and stop it with the death of the accomplice.


Introduction

Model Analysis

Tool Support

Conclusion

Hiding I

Currently there is nothing in the model to stop an enemy from disrupting the interaction between Roland and his accomplice, e.g. by performing a befriend action.


Introduction

Model Analysis

Tool Support

Conclusion

Hiding I


I

One way to avoid this is to ‘hide’ those actions only Roland and the accomplice should cooperate on.


Introduction

Model Analysis

Tool Support

Conclusion

Hiding I


I

One way to avoid this is to ‘hide’ those actions only Roland and the accomplice should cooperate on.

I

To do this for our model we can simply change the system equation:

C Acmpl)/{befriend}) BC Enemiesidle ((Rolandidle B L L 1

where L1 = {attackhit, a-hit, befriend} and L2 = {attack, hit, a-hit, enemy-hit}. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

2

Introduction

Model Analysis

Outline



Tool Support

Conclusion

Introduction

Model Analysis

SPA Tool Support


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

SPA Tool Support

Several software tools supporting Stochastic Process Algebras have been developed over the years:


Introduction

Model Analysis

Tool Support

Conclusion

SPA Tool Support

Several software tools supporting Stochastic Process Algebras have been developed over the years: I

MoDeST


Introduction

Model Analysis

Tool Support

Conclusion

SPA Tool Support


MoDeST

I

TIPP-Tool


Introduction

Model Analysis

Tool Support

Conclusion

SPA Tool Support


MoDeST

I

TIPP-Tool

I

TwoTowers


Introduction

Model Analysis

PEPA Tool Support


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools.


Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools. I The PEPA Workbench offers support for Markovian steady-state analysis, allowing computation of performance measures such as throughput and utilisation.


Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools. I The PEPA Workbench offers support for Markovian steady-state analysis, allowing computation of performance measures such as throughput and utilisation. I The Imperial PEPA Compiler translates PEPA models into the input format for Dnamaca, providing both steady-state and passage time analysis.


Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools. I The PEPA Workbench offers support for Markovian steady-state analysis, allowing computation of performance measures such as throughput and utilisation. I The Imperial PEPA Compiler translates PEPA models into the input format for Dnamaca, providing both steady-state and passage time analysis. I Model checking via Continuous Stochastic Logic is available in PRISM which has built-in support for PEPA.


Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools. I The PEPA Workbench offers support for Markovian steady-state analysis, allowing computation of performance measures such as throughput and utilisation. I The Imperial PEPA Compiler translates PEPA models into the input format for Dnamaca, providing both steady-state and passage time analysis. I Model checking via Continuous Stochastic Logic is available in PRISM which has built-in support for PEPA. I PEPA has been integrated into the M¨ obius multi-paradigm modelling tool.


Introduction

Model Analysis

Tool Support

Conclusion

PEPA Tool Support PEPA is amenable to several analysis techniques through a number of supporting tools. I The PEPA Workbench offers support for Markovian steady-state analysis, allowing computation of performance measures such as throughput and utilisation. I The Imperial PEPA Compiler translates PEPA models into the input format for Dnamaca, providing both steady-state and passage time analysis. I Model checking via Continuous Stochastic Logic is available in PRISM which has built-in support for PEPA. I PEPA has been integrated into the M¨ obius multi-paradigm modelling tool. I The PEPA Plug-in Project permits Markovian steady-state analysis and stochastic simulation. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

The PEPA Plug-in Project


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

The PEPA Plug-in Project I

The PEPA Plug-in Project is built on top of the Eclipse technology and it is deployed as a collection of plug-ins for the Eclipse IDE released under GPL.


Introduction

Model Analysis

Tool Support

Conclusion



I

It has been successfully tested on Eclipse 3.2 running on various Linux distributions, Mac OS X, and Windows XP


Introduction

Model Analysis

Tool Support

Conclusion



I


I

The tool is available for download at: http://homepages.inf.ed.ac.uk/mtribast/


Introduction

Model Analysis

Tool Support

Conclusion



I


I

The tool is available for download at: http://homepages.inf.ed.ac.uk/mtribast/

I

The examples discussed throughout this presentation are available at the PEPA Home Page: http://www.dcs.ed.ac.uk/pepa/


Introduction

Model Analysis

Key Plug-ins


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Key Plug-ins

I

PEPAto provides core services for PEPA. It can be used as a library by third-party applications.


Introduction

Model Analysis

Tool Support

Conclusion

Key Plug-ins

I


I

Eclipse Core makes PEPA tools available within the Eclipse framework.


Introduction

Model Analysis

Tool Support

Conclusion

Key Plug-ins

I


I

Eclipse Core makes PEPA tools available within the Eclipse framework.

I

Eclipse UI implements a rich graphical user interface including an editor for PEPA descriptions and views for performance evaluation.


Introduction

Model Analysis

Services Available in PEPAto


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support


I

In-memory model representation either programmatically or through parsing.


Conclusion

Introduction

Model Analysis

Tool Support


I


I

Static analysis.


Conclusion

Introduction

Model Analysis

Tool Support


I


I

Static analysis.

I

State space derivation.


Conclusion

Introduction

Model Analysis

Tool Support


I


I

Static analysis.

I


I

Calculation of steady-state probability distribution.


Conclusion

Introduction

Model Analysis

Tool Support


I


I

Static analysis.

I


I


I

Throughput and utilisation analysis.


Conclusion

Introduction

Model Analysis

Tool Support


I


I

Static analysis.

I


I


I

Throughput and utilisation analysis.


Conclusion

Introduction

Model Analysis

Tool Support

Static Analysis

Static analysis checks the well-formedness of a model prior to inferring the derivation graph of the system.


Conclusion

Introduction

Model Analysis

Tool Support

Static Analysis

Static analysis checks the well-formedness of a model prior to inferring the derivation graph of the system. The output of this tool is a list of messages grouped into two categories:


Conclusion

Introduction

Model Analysis

Tool Support

Static Analysis

Static analysis checks the well-formedness of a model prior to inferring the derivation graph of the system. The output of this tool is a list of messages grouped into two categories: I

Error messages prevent further model analysis (e.g. state space derivation)


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Static Analysis

Static analysis checks the well-formedness of a model prior to inferring the derivation graph of the system. The output of this tool is a list of messages grouped into two categories: I

Error messages prevent further model analysis (e.g. state space derivation)

I

Warning messages are less severe and allow further processing


Introduction

Model Analysis

Basic Analysis An Error message is reported for:


Tool Support

Conclusion

Introduction

Model Analysis

Basic Analysis An Error message is reported for: I

Rate not declared


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined

I

Multiple rate definitions


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined

I


I

Multiple process definitions


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined

I


I


A Warning message is reported for:


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined

I


I


A Warning message is reported for: I

Rate not used


Tool Support

Conclusion

Introduction

Model Analysis


Rate not declared

I

Process not defined

I


I


A Warning message is reported for: I

Rate not used

I

Process definition not used


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Local Deadlock A local deadlock is a condition that may occur in a synchronisation when a shared action can never be performed by one of the involved components.


Introduction

Model Analysis

Tool Support

Conclusion

Local Deadlock A local deadlock is a condition that may occur in a synchronisation when a shared action can never be performed by one of the involved components. P1 P2 Q1 Q2 P1

def

= def = def = def =

BC {α}


(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1

Introduction

Model Analysis

Tool Support

Conclusion

Complete Action Type Set The complete action type set A(P) of a component P is the set of all the action types which may be performed by the component during its evolution.


Introduction

Model Analysis

Tool Support

Conclusion

Complete Action Type Set The complete action type set A(P) of a component P is the set of all the action types which may be performed by the component during its evolution. I

def

Constant A = P: A(A) = A(P)


Introduction

Model Analysis

Tool Support

Conclusion


I

def

Constant A = P: A(A) = A(P) Choice P + Q: A(P + Q) = A(P) ∪ A(Q)


Introduction

Model Analysis

Tool Support

Conclusion


I

I

def

Constant A = P: A(A) = A(P) Choice P + Q: A(P + Q) = A(P) ∪ A(Q) C Q: Cooperation P B L C Q) = A(P) ∪ A(Q) A(P B L


Introduction

Model Analysis

Tool Support

Conclusion


I

I

I

def

Constant A = P: A(A) = A(P) Choice P + Q: A(P + Q) = A(P) ∪ A(Q) C Q: Cooperation P B L C Q) = A(P) ∪ A(Q) A(P B L Prefix (α, r).P: A (α, r ).P = {α} ∪ A(P)


Introduction

Model Analysis

Tool Support

Conclusion


I

I

I

I

def

Constant A = P: A(A) = A(P) Choice P + Q: A(P + Q) = A(P) ∪ A(Q) C Q: Cooperation P B L C Q) = A(P) ∪ A(Q) A(P B L Prefix (α, r).P: A (α, r ).P = {α} ∪ A(P) Hiding P\{L}: A P\{L} = A(P) − L


Introduction

Model Analysis

Example P1 P2 Q1 Q2 P1

def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support


def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1


A(P1 ) = {α, γ}

Conclusion

Introduction

Model Analysis

Tool Support


def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1


A(P1 ) = {α, γ} A(P2 ) = {α, γ}

Conclusion

Introduction

Model Analysis

Tool Support


def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1


A(P1 ) = {α, γ} A(P2 ) = {α, γ} A(Q1 ) = {β, }

Conclusion

Introduction

Model Analysis

Tool Support


def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1


A(P1 ) = {α, γ} A(P2 ) = {α, γ} A(Q1 ) = {β, } A(Q2 ) = {β, }

Conclusion

Introduction

Model Analysis

Tool Support


def

= def = def = def =

B C {α}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1

A(P1 ) = {α, γ} A(P2 ) = {α, γ} A(Q1 ) = {β, } A(Q2 ) = {β, }

Local Deadlock Detection

C Q gives rise to a local deadlock if A cooperation P B L ∃ α ∈ L : α 6∈ A(P) ∩ A(Q), α ∈ A(P) ∪ A(Q)


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Redundant Action A redundant action is an action type specified in a cooperation set which cannot be carried out by either of the components involved.


Introduction

Model Analysis

Tool Support

Conclusion

Redundant Action A redundant action is an action type specified in a cooperation set which cannot be carried out by either of the components involved. P1 P2 Q1 Q2 P1

def

= def = def = def =

BC

{α,δ}


(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1

Introduction

Model Analysis

Tool Support

Conclusion


def

= def = def = def =

BC

{α,δ}


(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1

Introduction

Model Analysis

Tool Support

Conclusion


def

= def = def = def =

BC

{α,δ}

(α, r ).P2 (γ, t).P1 (β, s).Q2 (, v ).Q1 Q1

Redundant Action Detection

C Q has a redundant action type α if A cooperation P B L ∃ α ∈ L : α 6∈ A(P) ∪ A(Q) Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Non-guarded Recursive Definition Consider the following model snippet: ... def P1 = P2 k P3 def P2 = (γ, t).P1 ...


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Non-guarded Recursive Definition Consider the following model snippet: ... def P1 = P2 k P3 def P2 = (γ, t).P1 ... The derivation graph of component P1 gives rise to infinite-depth left recursion: P1

(γ,t)

→

(γ,t)

→

(γ,t)

→

(γ,t)

→

P2 k P3 k P3 P2 k P3 k P3 k P3 P2 k P3 k P3 k P3 k P3 ···


Introduction

Model Analysis

Tool Support

Conclusion

Used Definition Set The used definition set U(P) of a component P is the set of all the constants used by P during its evolution. It is computed as follows:


Introduction

Model Analysis

Tool Support

Conclusion

Used Definition Set The used definition set U(P) of a component P is the set of all the constants used by P during its evolution. It is computed as follows: I

def

Constant A = P: U(A) = {A} ∪ U(P)


Introduction

Model Analysis

Tool Support

Conclusion


I

def

Constant A = P: U(A) = {A} ∪ U(P) Choice P + Q: U(P + Q) = U(P) ∪ U(Q)


Introduction

Model Analysis

Tool Support

Conclusion


I

I

def

Constant A = P: U(A) = {A} ∪ U(P) Choice P + Q: U(P + Q) = U(P) ∪ U(Q) C Q: Cooperation P B L C Q) = U(P) ∪ U(Q) U(P B L


Introduction

Model Analysis

Tool Support

Conclusion


I

I

I

def

Constant A = P: U(A) = {A} ∪ U(P) Choice P + Q: U(P + Q) = U(P) ∪ U(Q) C Q: Cooperation P B L C Q) = U(P) ∪ U(Q) U(P B L Prefix (α, r).P: U (α, r ).P = U(P)


Introduction

Model Analysis

Tool Support

Conclusion


I

I

I

I

def

Constant A = P: U(A) = {A} ∪ U(P) Choice P + Q: U(P + Q) = U(P) ∪ U(Q) C Q: Cooperation P B L C Q) = U(P) ∪ U(Q) U(P B L Prefix (α, r).P: U (α, r ).P = U(P) Hiding P\{L}: U P\{L} = U(P)


Introduction

Model Analysis

Example

... def P1 = P2 k P3 def P2 = (γ, t).P1 ...


Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Example

Non-guarded Definition Detection ... def P1 = P2 k P3 def P2 = (γ, t).P1 ...


def

For each process definition A = P compute U(P). A has infinite recursion if it defines a cooperation and A ∈ U(P)

Introduction

Model Analysis

Tool Support

Conclusion

Example


U P2 k P3 = {P1 , P2 , P3 , . . .}


def


Introduction

Model Analysis

Tool Support

Conclusion

Example


U P2 k P3 = {P1 , P2 , P3 , . . .} U (γ, t).P1 = {P1 , P2 , P3 , . . .}


def


Introduction

Model Analysis

Tool Support

Conclusion

Example


U P2 k P3 = {P1 , P2 , P3 , . . .} U (γ, t).P1 = {P1 , P2 , P3 , . . .}


def


Introduction

Model Analysis

Tool Support

Web Service Composition: Introduction We consider an example of a business application which is composed from a number of offered web services.


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Web Service Composition: Introduction We consider an example of a business application which is composed from a number of offered web services. A user accesses the application via an SMS message requesting directions to the nearest facility (post-office, restaurant, bank etc.) and receives a response as an MMS message containing a map.


Introduction

Model Analysis

Tool Support

Conclusion

Web Service Composition: Introduction We consider an example of a business application which is composed from a number of offered web services. A user accesses the application via an SMS message requesting directions to the nearest facility (post-office, restaurant, bank etc.) and receives a response as an MMS message containing a map. Since the application involves a users’ current location there is an access control issue since it must be ensured that the web service consumer has the requisite authority to execute the web service it requests.


Introduction

Model Analysis

Tool Support

Conclusion

Web Service Composition: Introduction We consider an example of a business application which is composed from a number of offered web services. A user accesses the application via an SMS message requesting directions to the nearest facility (post-office, restaurant, bank etc.) and receives a response as an MMS message containing a map. Since the application involves a users’ current location there is an access control issue since it must be ensured that the web service consumer has the requisite authority to execute the web service it requests. Moreover the service provider imposes a restriction that only one request may be handled for each SMS message received. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Schematic view Web Service Consumer Application Logic WS SMS notification

Policy Access Provider

Location request Location result

MMS delivery

Session Manager Start Session

WS component for SMS WS component for MMS WS component for location

Web Service Provider


SMS

End Session

Check request validity

Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery





SMS

1

End Session


Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery

2 Start Session




SMS

End Session


Session Manager

Introduction

Model Analysis

Tool Support

Conclusion

Schematic view Web Service Consumer Application Logic

3 WS SMS notification



MMS delivery





SMS

End Session


Introduction

Model Analysis

Tool Support

Conclusion



4 Location request Location result

MMS delivery





SMS

End Session


Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery





SMS

End Session

5 Check request validity

Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery

6




Session Manager Start Session SMS

End Session


Introduction

Model Analysis

Tool Support

Conclusion



Location request

7 Location result

MMS delivery





SMS

End Session


Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery





SMS

8 End Session


Introduction

Model Analysis

Tool Support

Conclusion




MMS delivery





SMS

End Session


Introduction

Model Analysis

Tool Support

The PEPA model The PEPA model of the system consists of four components:


Conclusion

Introduction

Model Analysis

Tool Support

The PEPA model The PEPA model of the system consists of four components: I

The user;

I

The web service provider;

I

The web service consumer, and

I

The policy access provider.


Conclusion

Introduction

Model Analysis

Tool Support


The user;

I


I


I


The Web Service Provider consists of three distinct elements but the web service consumer is associated with a session which accesses each element in sequence.


Conclusion

Introduction

Model Analysis

Tool Support


The user;

I


I


I


The Web Service Provider consists of three distinct elements but the web service consumer is associated with a session which accesses each element in sequence. Concurrency is introduced into the model by allowing multiple sessions rather than by representing the constituent web services separately. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Component Customer The customer’s behaviour is simply modelled with two local states.


Introduction

Model Analysis

Tool Support

Conclusion


Customer

def

= (getSMS, r1 ).Customer 1 def

Customer 1 = (getMap, >).Customer + (get404 , >).Customer


Introduction

Model Analysis

Tool Support

Conclusion


Customer

def

= (getSMS, r1 ).Customer 1 def

Customer 1 = (getMap, >).Customer + (get404 , >).Customer

We associate the user-perceived system performance with the throughput of the getMap action which can be calculated directly from the steady state probability distribution of the underlying Markov chain. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Component WSConsumer Once a session has been started, it initiates a request for the user’s current location and waits for a response.


Introduction

Model Analysis

Tool Support

Conclusion

Component WSConsumer Once a session has been started, it initiates a request for the user’s current location and waits for a response. For valid requests, location is returned and used to compute the appropriate map, which is then sent via an MMS message, using the web service.


Introduction

Model Analysis

Tool Support

Conclusion

Component WSConsumer Once a session has been started, it initiates a request for the user’s current location and waits for a response. For valid requests, location is returned and used to compute the appropriate map, which is then sent via an MMS message, using the web service. WSConsumer

def

= (notify , >).WSConsumer 2 def

WSConsumer 2 = (locReq, r4 ).WSConsumer 3 def

WSConsumer 3 = (locRes, >).WSConsumer 4 + (locErr , >).WSConsumer def

WSConsumer 4 = (compute, r7 ).WSConsumer 5 def

WSConsumer 5 = (sendMMS, r9 ).WSConsumer


Introduction

Model Analysis

Tool Support

Component WSProvider The use of sessions restricts a user’s access to the services of the Web Service Provider to be sequential.


Conclusion

Introduction

Model Analysis

Tool Support

Component WSProvider The use of sessions restricts a user’s access to the services of the Web Service Provider to be sequential. We assume that there is a distinct instance of the component WSProvider for each distinct session.


Conclusion

Introduction

Model Analysis

Tool Support

Component WSProvider The use of sessions restricts a user’s access to the services of the Web Service Provider to be sequential. We assume that there is a distinct instance of the component WSProvider for each distinct session. The checkValid action is represented twice, to capture the two possible distinct outcomes of the action.


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Component WSProvider The use of sessions restricts a user’s access to the services of the Web Service Provider to be sequential. We assume that there is a distinct instance of the component WSProvider for each distinct session. The checkValid action is represented twice, to capture the two possible distinct outcomes of the action. I

If the check is successful the location must be returned to the Web Service Consumer in the form of a map (getMap).


Introduction

Model Analysis

Tool Support

Conclusion

Component WSProvider The use of sessions restricts a user’s access to the services of the Web Service Provider to be sequential. We assume that there is a distinct instance of the component WSProvider for each distinct session. The checkValid action is represented twice, to capture the two possible distinct outcomes of the action. I

If the check is successful the location must be returned to the Web Service Consumer in the form of a map (getMap).

I

If the check revealed an invalid request (locErr ) then an error must be returned to the Web Service Consumer (get404 ) and the session terminated (stopSession).


Introduction

Model Analysis

Tool Support

Component WSProvider

WSProvider

def

= (getSMS, >).WSProvider 2 def

WSProvider 2 = (startSession, r2 ).WSProvider 3 def

WSProvider 3 = (notify , r3 ).WSProvider 4 def

WSProvider 4 = (locReq, >).WSProvider 5 def

WSProvider 5 = (checkValid, 99 · >).WSProvider 6 + (checkValid, >).WSProvider 10


Conclusion

Introduction

Model Analysis

Tool Support

Component WSProvider cont.

def

WSProvider 6 = (locRes, r6 ).WSProvider 7 def

WSProvider 7 = (sendMMS, >).WSProvider 8 def

WSProvider 8 = (getMap, r8 ).WSProvider 9 def

WSProvider 9 = (stopSession, r2 ).WSProvider def

WSProvider 10 = (locErr , r6 ).WSProvider 11 def

WSProvider 11 = (get404 , r8 ).WSProvider 9


Conclusion

Introduction

Model Analysis

Tool Support

Component PAProvider

We consider a stateless implementation of the policy access provider. PAProvider

def

= (startSession, >).PAProvider + (checkValid, r5 ).PAProvider + (stopSession, >).PAProvider


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Model Component WSComp The complete system is composed of some number of instances of the components interacting on their shared activities: def

WSComp =

C WSProvider [NWSP ]) (Customer [NC ] B L1 BC WSConsumer [NWSC ] L2 BC PAProvider [NPAP ] L 3

where the cooperation sets are L1 = {getSMS, getMap, get404 } L2 = {notify , locReq, locRes, locErr , sendMMS} L3 = {startSession, checkValid, stopSession} Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Parameter Values param r1 r2 r3

value 0.0010 0.5 0.1

r4 r5

0.1 0.05

r6

0.1

r7 r8

0.05 0.02

r9

10.0 ∗ r8

explanation rate customers request maps rate session can be started notification exchange between consumer and provider rate requests for location can be satisfied rate the provider can check the validity of the request rate location information can be returned to consumer rate maps can be generated rate MMS messages can be sent from provider to customer rate MMS messages can be sent via the Web Service


Introduction

Model Analysis

Tool Support

Conclusion

Steady State Analysis for System Tuning I

Suppose that we want to design the system in such a way that it can handle 30 independent customers.


Introduction

Model Analysis

Tool Support

Conclusion



I

Some parameters such as the network delays may be constrained by the available technology.


Introduction

Model Analysis

Tool Support

Conclusion



I


I

However, there are a number of degrees of freedom which let her vary, for example, the number of threads of control of the components of the system.


Introduction

Model Analysis

Tool Support

Conclusion



I


I


I

The aim of the analysis is to deliver a satisfactory service in a cost-effective way.


Introduction

Model Analysis

Tool Support

Conclusion



I


I


I

The aim of the analysis is to deliver a satisfactory service in a cost-effective way.

I

The simplest example of a cost function may be a linearly dependency on the number of copies of a component or the rate at which an activity is performed.


Introduction

Model Analysis

Tool Support

Conclusion

Throughput of the getMap action 0.014

Throughput getMap

0.012 0.01 0.008 0.006 0.004 Number of WSProviders=1 Number of WSProviders=2 Number of WSProviders=3 Number of WSProviders=4

0.002 0 0

5

10

15

20

25

30

Number of Customers

as the number of customers varies between 1 and 30 for various numbers of copies of the WSProvider component. Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Throughput of the getMap action

I

Under heavy load increasing the number of providers initially leads to a sharp increase in the throughput. However the gain deteriorates so that the system with four copies is just 8.7% faster than the system with three.

I

In the following we settle on three copies of WSProvider .


Introduction

Model Analysis

Tool Support

Conclusion

Throughput of getMap action 0.022 0.02

Throughput getMap

0.018 0.016 0.014 0.012 0.01 0.008 0.006 Number of WSConsumers=1 Number of WSConsumers=2 Number of WSConsumers=3

0.004 0.002 0

0.005 0.01 0.015 0.02 0.025 0.03 0.035 0.04 0.045 0.05 Rate r1

as the request arrival rate (r1 ) varies for differing numbers of WSConsumer . Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion

Throughput of getMap action

I

Every line starts to plateau at approximately r1 = 0.010 following an initial sharp increase. This suggests that the user is the bottle next in the system when the arrival rate is lower. Conversely, at high rates the system becomes congested.

I

Whilst having two copies of WSConsumer , corresponding to two operating threads of control, improves performance significantly, the subsequent increase with three copies is less pronounced.

I

So we set the number of copies of WSConsumer to 2.


Introduction

Model Analysis

Tool Support

Conclusion

Optimising the number of copies of PAProvider

I

Here we are particularly interested in the overall impact of the rate at which the validity check is performed.

I

Slower rates may mean more computationally expensive validation.

I

Faster rates may involve less accuracy and lower security of the system.


Introduction

Model Analysis

Tool Support

Conclusion


Throughput getMap

0.014 0.012 0.01 0.008 0.006 0.004 Number of PAProviders=1 Number of PAProviders=2 Number of PAProviders=3

0.002 0 0

0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.11 Rate r5

as the validity check rate (r5 ) varies for differing numbers of PAProvider . Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion


I

A sharp increase followed by a constant levelling off suggests that optimal rate values lie on the left of the plateau, as faster rates do not improve the system considerably.

I

As for the optimal number of copies of PAProvider , deploying two copies rather than one can increase the quality of service of the overall system.

I

With a similar approach as previously discussed, the modeller may want to consider the trade-off between the cost of adding a third copy and the throughput increase.


Introduction

Model Analysis

Tool Support

Conclusion

An alternative design for PAProvider I

The original design of PAProvider is stateless.

I

Any of its services can be called at any point, the correctness of the system being guaranteed by implementation-specific constrainsts such as session identifiers being uniquely assigned to the clients and passed as parameters of the method calls.


Introduction

Model Analysis

Tool Support

Conclusion

An alternative design for PAProvider I

The original design of PAProvider is stateless.

I

Any of its services can be called at any point, the correctness of the system being guaranteed by implementation-specific constrainsts such as session identifiers being uniquely assigned to the clients and passed as parameters of the method calls.

I

Alternatively we may consider a stateful implementation, modelled as a sequential component with three local states.

I

This implementation has the consequence that there can never be more than NPAP WSProvider which have started a session with a PAProvider


Introduction

Model Analysis

Tool Support

Component PAProvider — Stateful Version

It maintains a thread for each session and carries out the validity check on behalf of the Web Service Provider. PAProvider

def

= (startSession, >).PAProvider 2 def

PAProvider 2 = (checkValid, r5 ).PAProvider 3 def

PAProvider 3 = (stopSession, >).PAProvider


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion


Throughput getMap

0.014 0.012 0.01 0.008 0.006 0.004 Number of PAProviders=1 Number of PAProviders=2 Number of PAProviders=3

0.002 0 0

0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.11 Rate r5

as the validity check rate (r5 ) varies for differing numbers of PAProvider (stateful version). Hillston and Tribastone. LFCS, University of Edinburgh. Stochastic Process Algebras

Introduction

Model Analysis

Tool Support

Conclusion


I

In this case the incremental gain in adding more copies has become more marked.

I

However, the modeller may want to prefer the original version, as three copies of the stateful provider deliver about as much as the throughput of only one copy of the stateless implementation.


Introduction

Model Analysis

Outline



Tool Support

Conclusion

Introduction

Model Analysis

Tool Support

Some concluding remarks...

The incorporation of stochastic quantitative information into process algebras has been extremely fruitful:


Conclusion

Introduction

Model Analysis

Tool Support

Conclusion

Some concluding remarks...

The incorporation of stochastic quantitative information into process algebras has been extremely fruitful: I

For performance modelling the rigour of the formal description technique has had benefits for both practice and theory, and lead to enhanced analysis capabilities.


Introduction

Model Analysis

Tool Support

Acknowledgements

The PEPA project has been funded by SERC, EPSRC and the CEC. In particular Jane Hillston and Mirco Tribastone are supported by the SENSORIA project We would like to thank our co-authors, Allan Clark and Stephen Gilmore for help with these slides.


Conclusion

Introduction

Model Analysis

Thank you


Tool Support

Conclusion