Formele Technieken in SWE - Petri Nets

16 feb 2007

Formele modellen

De systematische ontwikkeling van een complex software-systeem vergt beschrijvingen op verschillende niveaus.

Model = abstracte, vereenvoudigde beschrijving

Design:

- Van requirements naar initieel model

- Van initieel model naar steeds gedetailleerder modellen

- Van domein naar applicatie

Geschikte talen om die modellen uit te drukken?

Formele modellen: gewenste eigenschappen

• Eenvoud: de modellen moeten frequent aangepast worden.• Visuele voorstelling: dienen ook als communicatiemiddel • Precisie: moeten een nauwkeurige analyse toelaten, en geen dubbelzinnigheid bevatten• Uitvoerbaar: maakt simulatie en verificatie mogelijk• Formeel: laat het bouwen van ondersteunende tools toe.

Het feit dat de initiele modellen al in een formeel model gegoten worden dwingt je ertoe grondiger na te denken over de requirements

Modelleringstalen

- Min of meer gebaseerd op automaten, maar met concurrency

- LOTOS, PDL- Proces Algebra- UML (niet voldoende formeel?) - Petri nets- ...

Petri Nets

Visuele taal voor modellering en analyse van systemen:

- voldoende eenvoudig om visuele representatie toe te laten

- uitvoerbaar, geschikt voor verificatie

- noties van verfijning, modulariteit

- concurrency

- ook gebruikt buiten informatica (productieprocessen)

- genoemd naar C. A. Petri (1962)

- vele varianten:

Place/Transition systemen

Condition/Event systemen

Coloured Nets

...

Petri Nets: basisideeën

• Het modelleren gebeurt door middel van twee soorten entiteiten: passieve (plaatsen) en actieve (transities).

• Een transitie brengt een verandering aan in een beperkt aantal plaatsen: haar werking is locaal. Ook om te bepalen of een transitie actief kan worden (vuren) is maar een beperkt aantal plaatsen nodig.

• Transities die werken op disjuncte verzamelingen van plaatsen zijn onafhankelijk van elkaar en kunnen concurrent gebeuren.

• Petri nets hebben een grafische en een algebraische voorstelling.

Petri Nets: basisideeën

• Een globale toestand wordt gezien als een verzameling van resources: plaatsen.

• De locale toestand van een plaats wordt gekarakterizeerd door het feit dat er 0,1 of meerdere tokens aanwezig zijn in die plaats.

• De toestand van die resources wordt veranderd door transities: elke transitie heeft een beperkt aantal invoer-plaatsen en een beperkt aantal uitvoer-plaatsen.

• De uitvoering van een transitie (het vuren ervan) heeft als gevolg dat er tokens weggenomen worden uit de invoerplaatsen van die transitie, en dat er token bijkomen in de uitvoerplaatsen ervan.

• Of een transitie kan vuren (enabled is) kan locaal beslist worden: het hangt enkel af van het aantal tokens in de bij die transitie betrokken plaatsen ( haar invoer- en uitvoerplaatsen). Ook het effect van het vuren is locaal.

Basiselementen

Plaats:

Plaats met tokens:

Transitie:

invoerplaatsen

uitvoerplaatsen

Vuren van transities

t3

t2

t1

vuren van t1

Vuren van transities

t3

t2

t1

vuren van t2

Vuren van transities

t3

t2

t1

Vuren van transities

t3

t2

t1

vuren van t3

Vuren van transities

t3

t2

t1

Vuren van transities

t3

t2

t1

Concurrency: vuren van { t1 , t2 } - dit kan op voorwaarde dat er tussen t1 en t2 geen conflict is: de sets van betrokken plaatsen moeten disjunct zijn.

Vuren van transities

t3

t2

t1

Toestand na het vuren van {t1,t2}

Plaats/transitie systemen

Bij een P/T systeem kan een plaats een willekeurig (niet-negatief) aantal tokens bevatten.

Gewoonlijk kiest men en vaste nummering voor de (n) plaatsen en noteert men een toestand (markering) als een n-tupel.

P/T systemen: Definities

• Een net is een 3-tupel (S,T,F) waar S en T eindige verzamelingen zijn, S en T zijn disjunct, en F (S x T) (S x T). S is de verzameling van plaatsen, T is de verzameling van transities, F is de flow relatie.

• Een markering van het net N is een functie m: S Nat.

• Een systeem is een net met een beginmarkering, dus een 4-tuple (S,T,F,m0).

• Voor een transitie t is = { p | (p,t) F } de verzameling van invoerplaatsen van t , en = { p | (t,p) F } de verzameling van uitvoerplaatsen van t.

• Voor een markering m en een transitie t, t is enabled in m als m(p) ≥ 1 voor elke plaats p in . Dit betekent dat t kan vuren in markering m.

t

t

t

Definities

• Voor markeringen m en m’. En een transitie t, geldt dat m [t> m’ als t enabled is in m en, voor elke plaats p:

Het vuren van t zet m dus om in m’.

• Een markering is bereikbaar (reachable) als er een rij van transities t1, … ,tn bestaat die m0 omzet in m, maw. Er bestaat een rij van markeringen b0, … ,bn zodat m0 = b0 , bn = m en

b0 [t1> b1 [t2> … [tn> bn

de rij transities mag ook leeg zijn, dus m0 is bereikbaar.

t

m(p) als p en p

m(p) als p m(p) -1 als p en p m(p) +1 als p en p

m’(p) = t t

t

t

t

t

t

Condition/Event systemen

In een C/E systeem wordt de aanwezigheid van een token in een plaats geïnterpreteerd als het gelden van een conditie. Dat heeft maar zin als er nooit een situatie optreedt waarbij een plaats meer dan één token bevat. Het net is dan safe.

Als het net geen self-loops heeft (i.e. geen transities waarvan de sets van input- en output-plaatsen mekaar overlappen), dan garandeert safeness dat een transitie maar enabled zal zijn als haar output-plaatsen leeg zijn.

In het geval van C/E systemen spreekt men van condities, cases en events ipv. plaatsen, markeringen en transities, resp.

Voorbeeld: access controle

We modelleren een systeem waarin een client proces een resource gebruikt (bv een buffer). Afhankelijk van de vraag of de resource vrij is moet het proces eventueel wachten.

Zichtbaar moeten dus zijn: het client proces, deresource, het verschil tussen wachten of niet, vrij of niet,en het "gebruiken" als actie.

Voorbeeld: access controle

t1 t2 t3

s4s2

s1 s3

s1: wait for access

s2: process

s3: device available

s4: device busy

Client proces Resource manager

Dit is een condition/event systeem

S-Invarianten

Om aan te tonen dat dit net safe is, kunnen we bv.bewijzen dat er in de twee delen steeds precies ééntoken aanwezig is: voor elke bereikbare markering m geldt dat m(s1) + m(s2) = 1 en dat m(s3) + m(s4) = 1

Voor P/T netten geeft dit aanleiding to de definitie van het begrip S-invariant (of kortweg invariant):

Voor een P/T net (S,T,F,K,W) is een s-invariant een

functie i:S Z waarvoor het getal constant blijft, dus voor elke transitie t geldt dat:

∑s in S i(s) * m(s)

∑s in S i(s) * W(s,t) = ∑s in S i(s) * W(t,s)

Vaak worden de pijlen van de flow relatie F voorzien van multipliciteiten of gewichten (als de multipliciteit 1 is wordt ze weggelaten).

Bovendien worden de plaatsen vaak voorzien van capaciteiten (als de capaciteit +∞ is wordt ze weggelaten).

Multipliciteiten en Capaciteiten

Definities

• Een net is nu een 5-tupel (S,T,F,K,W) met S,T,F als voordien, K: S Nat de capaciteitsfunctie en W: E Nat de gewichts- (of multipliciteits-) functie.

• Voor een markering m en een transitie t, t is enabled in m als

• m(p) ≥ W(p,t) voor elke plaats p in , en

• m(p) ≤ K(p) - W(t,p) voor elke plaats p in .

t

Dit betekent dat t kan vuren in markering m.

t

Beide zijn niet enabled

• Voor markeringen m en m’. En een transitie t, geldt dat m [t> m’ als t enabled is in m en, voor elke plaats p:

m(p) als p en p

m(p) - W(p,t) + W(t,p) als p en p

m(p) - W(p,t) als p en p m(p) + W(t,p) als p en p

m’(p) = t

t

t

t

t

t

t

t

Voorbeeld: access controle (2)

We zoeken nu een wat meer gecompliceerd systeem, waarin processen een gemeenschappelijke buffer gebruiken om ofwel te lezen ofwel te schrijven. Er zijn meerdere processen. Tot 3 processen kunnen gelijktijdig lezen, maar als een proces schrijft, dan heeft het exclusief toegang tot de buffer. We gebruiken deze keer een place/transition net.

Voorbeeld: access controle

3

3

readingwriting

ready to readready to write

access control

reader processingwriter processing

Tot 3 processen kunnen gelijktijdig lezen.Als een proces schrijft, dan heeft het exclusief toegang.

Voorbeeld: access controle

Om te bewijzen dat dit systeem aan de voorwaarde voldoet kunnen we een geschikte invariant zoeken; m.a.w. uit het feit dat een zekere vector i een invariant is , moet volgen dat er nooit meer dan 3 tokens in plaats "reading" zijn, dat er altijd ten hoogste 1 in "writing" is, en dat er nooit tegelijk een in "writing en in "reading" is.

Voorbeeld: access controle

Om te bewijzen dat dit systeem aan de voorwaarde voldoet kunnen we een geschikte invariant zoeken; m.a.w. uit het feit dat een zekere vector i een invariant is , moet volgen dat er nooit meer dan 3 tokens in plaats "reading" zijn, dat er altijd ten hoogste 1 in "writing" is, en dat er nooit tegelijk een in "writing en in "reading" is.

oplossing:orde van de plaatsen: rtw,wp,w,ac,r,rtr,rp. i = (0,0,3,1,1,0,0) is dan een invariantbewijs: bekijk het effect van elke transitie apart.

Access controle (met capaciteiten)

s0: niet actiefs1: klaar om te lezen s2: bezig met lezens3: klaar om te schrijvens4: bezig met schrijven s5: synchronizatie

n t1

t0

s5

s4

s3

s2

s1

s0

K = n

k

t5

t4

t3

t2

k

K = 1

K = n

K = n

K = k

K = k

Banker’s problem met n clients

Een bank heeft n klanten en een vast kapitaal g. Elke klant i heeft een bedrag fi nodig. Hij vraagt af en toe een deel van dat geld op, en de bank geeft het als zij nog voldoende kapitaal heeft. Anders moet de klant wachten. Als klant i het hele bedrag gekregen heeft, geeft hij het na enige tijd helemaal terug.De bank moet een strategie hebben die ervoor zorgt dat zo mogelijk alle klanten hun geld krijgen, en zij moet situaties vermijden waarbij zij onvoldoende geld heeft om de klanten te voldoen.

Banker’s problem met n clients

Banker’s problem met n clients

We bekijken bv een instantie (2, (8,6),10) - dus 2 klanten , f1=8,f2=6, g=10. (fig a)

Is dat een goede oplossing - m.a.w. voldoet dit model aan de eisen?

Een manier om daarachter te komen is een diagram te maken van de bereikbare toestanden (markeringen).Maar dat zij er op het eerste gezicht erg veel (5 plaatsen met tot 10 tokens). Invarianten laten ons toe de zaak te vereenvoudigen.

Banker’s problem met n clients

Er geldt (in alle bereikbare markeringen m):

m(Bank) + m(Credit1) + m(Credit2) = 10m(Claim1) + m(Credit1) = 8m(Claim2) + m(Credit2) = 6

Bijgevolg kan elke bereikbare markering m voorgesteld worden door slechts 2 getallen, bv door (Claim1 , Claim2)Dat geeft dus een 2-dimensionale matrix.

Bereikbare markeringen van (2,(8,6),10)

Probleem: deadlock

Voldoet dit nu aan de gestelde eisen?

Er is een probleem met, bv de markering (3,1),of voluit m(Bank) = 0, m(Credit1) = 5, m(Claim1) = 3, m(Credit2) = 5, m(Claim1) = 1,

want we kunnen dan niet meer verder. Dergelijke states heten deadlock states. Sommige states zijn zelf geen deadlocks, maar leiden er onvermijdelijk toe - cfr de zwarte states in het diagram, bv (3,3). Ook die moeten vermeden worden.

Oplossing: zie fig(b): splitsen van Granti en strengere pre-condities

Een tweede instantie: (3,(8,3,9),10)

Een tweede instantie: (3,(8,3,9),10)

Deze instantie leidt tot een nieuw probleem:er zijn nu markeringen die niet noodzakelijk tot een deadlock leiden, maar waarin toch bepaalde transacties niet kunnen beëindigd worden, bv (4,3,6) - dus de claims zijn 4,3 en 6. (zie schema)

Er zijn dan in Bank nog 3 tokens beschikbaar, en dus kan de tweede klant verder, maar de andere twee klanten zitten vast.

Met synchronizatie

De verwerking bestaat nu uit “rounds” waarin telkens aan één request van elke klant voldaan wordt.