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 t3t3 t2t2 t1t1 vuren van t 1

Vuren van transities t3t3 t2t2 t1t1 vuren van t 2

Vuren van transities t3t3 t2t2 t1t1

t3t3 t2t2 t1t1 vuren van t 3

Vuren van transities t3t3 t2t2 t1t1

t3t3 t2t2 t1t1 Concurrency: vuren van { t 1, t 2 } - dit kan op voorwaarde dat er tussen t 1 en t 2 geen conflict is: de sets van betrokken plaatsen moeten disjunct zijn.

Vuren van transities t3t3 t2t2 t1t1 Toestand na het vuren van {t 1,t 2 }

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,m 0 ). 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 t 1, …,t n bestaat die m 0 omzet in m, maw. Er bestaat een rij van markeringen b 0, …,b n zodat m 0 = b 0, b n = m en b 0 [t 1 > b 1 [t 2 > … [t n > b n de rij transities mag ook leeg zijn, dus m 0 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, de resource, het verschil tussen wachten of niet, vrij of niet,en het "gebruiken" als actie.

Voorbeeld: access controle t1t1 t2t2 t3t3 s4s4 s2s2 s1s1 s3s3 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 één token aanwezig is: voor elke bereikbare markering m geldt dat m(s 1 ) + m(s 2 ) = 1 en dat m(s 3 ) + m(s 4 ) = 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 reading writing ready to read ready to write access control reader processing writer 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 invariant bewijs: bekijk het effect van elke transitie apart.

Access controle (met capaciteiten) s 0 : niet actief s 1 : klaar om te lezen s 2 : bezig met lezen s 3 : klaar om te schrijven s 4 : bezig met schrijven s 5 : synchronizatie n t1t1 t0t0 s5s5 s4s4 s3s3 s2s2 s1s1 s0s0 K = n k t5t5 t4t4 t3t3 t2t2 k K = 1 K = n K = k

Banker’s problem met n clients Een bank heeft n klanten en een vast kapitaal g. Elke klant i heeft een bedrag f i 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

We bekijken bv een instantie (2, (8,6),10) - dus 2 klanten, f 1 =8,f 2 =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(Credit 1 ) + m(Credit 2 ) = 10 m(Claim 1 ) + m(Credit 1 ) = 8 m(Claim 2 ) + m(Credit 2 ) = 6 Bijgevolg kan elke bereikbare markering m voorgesteld worden door slechts 2 getallen, bv door (Claim 1, Claim 2 ) 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(Credit 1 ) = 5, m(Claim 1 ) = 3, m(Credit 2 ) = 5, m(Claim 1 ) = 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 Grant i en strengere pre-condities

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.