Concurrency Forår 2005, Q3

Transkript

1 Concurrency Forår 2005, Q3 Mini Project Railroad Crossing Gruppe Klaus Leth Pedersen Jan Egberg Lauritzen Mads Pedersen Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 1 af 21

2 Indholdsfortegnelse Indholdsfortegnelse Model Indledning Processer SENSOR_ARRAY GATE CAR TRAIN LIGHT CROSSING ( Task a ) SAFE_CROSSING ( Task d ) RAILROAD Properties Safety property ( Task c ) Liveness property ( Task f ) Struktur ( Task g ) Test Usikker CROSSING ( Task b ) Sikker SAFE_CROSSING Verifikation Safety check med usikker CROSSING Safety check med sikker SAFE_CROSSING ( Task e ) Liveness check Implementation Struktur ( Task h ) Java-implementation ( Task i ) Crossing Train Car Light Gate Railroad Test Konklusion...21 Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 2 af 21

3 1 Model 1.1 Indledning Systemet består af følgende processer: SENSOR_ARRAY Array af sensorer GATE Modellerer bommen, som biler skal passere for at komme ind i crossing area CAR Modellerer bilerne i systemet TRAIN Modellerer systemets tog LIGHT Modellerer togets lyssignal, som kan være rødt eller grønt CROSSING Modellerer den usikre jernbaneoverskæring, dvs. hvor der kan ske kollisioner mellem tog og biler SAFE_CROSSING Modellerer den sikre jernbaneoverskæring, dvs. hvor controlleren sikrer, at der ikke sker kollisioner Derudover er der følgende properties: NO_CRASH En safety property, der sikrer, at der ikke sker kollisioner LIVE_TRAIN En liveness property, der sikrer, at et tog engang vil kunne enter crossing area Til sidst er der: RAILROAD Modellerer det samlede Raiload Crossing -system Det er valgt, at CAR og TRAIN er aktive processer, mens de resterende er passive. Alternativt kan controlleren SAFE_CROSSING være aktiv og dermed styre alle andre processer. Grunden til dette valg skal ses i, at det logisk set er biler og tog, der er aktive entiteter og de andre passive. Det diskuteres senere, hvilke implikationer dette har for Java-implementationen. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 3 af 21

4 1.2 Processer SENSOR_ARRAY SENSOR_ARRAY SENSOR_ARRAY = (car_enter -> SENSOR_ARRAY // sensor #1 car_exit -> SENSOR_ARRAY // sensor #2 train_enter -> SENSOR_ARRAY // sensor #3 train_exit -> SENSOR_ARRAY // sensor #4 train_arrival -> SENSOR_ARRAY // sensor #5 ). SENSOR_ARRAY bruges til at have et samlet sted at angive de actions, der laves af sensorerne, dvs. at biler kan enter og exit samt at toget kan lave arrival samt enter og exit. Disse actions deles med de andre processer, der har brug for at synkronisere med sensorerne GATE GATE = OPEN, OPEN = (close_gate -> CLOSED pass_gate -> OPEN), CLOSED = (open_gate -> OPEN). GATE GATE-processen modellerer bommen, der stopper biler i at komme ind i crossing area, når et tog er på vej CAR CAR CAR = (car_enter -> pass_gate -> car_exit -> CAR). Systemets biler modelleres ved at kunne passere bommen. Mens de er inde i crossing area, må der ikke komme tog ind på samme tid. car_enter og car_exit er synkroniseret med SAFE_CROSSING. pass_gate er synkroniseret med både SAFE_CROSSING og GATE TRAIN TRAIN TRAIN = (train_arrival -> light_green -> train_enter -> train_exit -> TRAIN). Toget modelleres, så det giver besked om, at det ankommer. Herefter ventes på grønt signal, som sættes fra controlleren SAFE_CROSSING, når eventuelle biler har forladt området. Endelig kan toget passere ved enter og exit. Toget tager ikke eksplicit hensyn til, hvis lyssignalet er rødt, men skal have grønt signal, inden det passerer. SAFE_CROSSING sørger i forvejen for, at toget ikke kører ind, hvis det ikke må (dvs. hvis der er biler i området). Lyssignalet kan derfor bare ses som et ekstra tjek, som afspejler virkeligheden, da et tog her vil vente på, at lyssignalet skifter til grønt. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 4 af 21

5 1.2.5 LIGHT LIGHT = LIGHT[Red], LIGHT[state:State] = (when(state==red) LIGHT turn_on_green -> light_green -> LIGHT[Green] when(state==green) turn_on_red -> light_red -> LIGHT[Red]). LIGHT-processen bruges til at modellere lyssignalet med. Lyssignalet styres med input fra SAFE_CROSSING-controlleren ( turn_on_green og turn_on_red ). Toget vil vente på grønt signal ( light_green ), hvilket kun kan forekomme, hvis signalet tidligere har været rødt (det sættes rødt, når toget har passeret) CROSSING ( Task a ) CROSSING CROSSING = (car[car_id].car_enter -> CROSSING train_arrival -> close_gate -> train_exit -> open_gate -> CROSSING). Dette er opgavens Task a. CROSSING-processen udgør den usikre jernbaneoverskæring. Som det ses i FSP-koden, er der ikke noget tjek på, om der i forvejen er biler inde i crossing area, når toget passerer, hvilket vil kunne resultere i en kollision. Bommen lukkes godt nok, men eventuelle biler inde i området tvinges ikke til at lave exit, inden toget passerer. I opgavens Task b skal der observeres, at der kan ske kollisioner med denne usikre CROSSING. Der laves et eksempel på en kollision i punkt I opgavens Task c skal det formelt verificeres, at der kan ske kollisioner med CROSSING. Til dette laves en safety property, som omtales nærmere i punkt og som verificeres i SAFE_CROSSING ( Task d ) SAFE_CROSSING SAFE_CROSSING = SAFE_CROSSING[0][False], SAFE_CROSSING[cars:Int][arriving:Bool] = (when (cars==0 && arriving==true) turn_on_green -> train_enter -> train_exit -> turn_on_red -> open_gate -> SAFE_CROSSING[0][False] when (cars<max_cars && arriving==false) car[car_id].car_enter -> car[car_id].pass_gate -> SAFE_CROSSING[cars+1][arriving] when (cars>0) car[car_id].car_exit -> SAFE_CROSSING[cars-1][arriving] train_arrival -> close_gate -> SAFE_CROSSING[cars][True]). Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 5 af 21

6 Opgavens Task d går ud på at modellere en sikker controller (SAFE_CROSSING). Denne controller skal sikre, at der ikke sker kollisioner mellem tog og biler i crossing area. Dette sikres ved at indføre passende guards, der ud fra antallet af biler i crossing area og en boolean angivende, om der er tog på vej, kan tillade et tog at passere. Generelt bemærkes, at når toget ankommer (som kan ske til et vilkårligt tidspunkt, da der ikke er guard herfor), så lukkes bommen. Først når alle biler har forladt crossing area, sættes lyset på grønt, hvorefter toget får lov at passere og efterfølgende åbne bommen igen. Alternativt kunne det modelleres, at lyset kunne sættes på grønt, når der ikke er nogen biler i området. Vi har dog valgt kun at sætte lyset grønt, når et tog har meldt sin ankomst. Dette svarer mest til virkeligheden, hvor der kun er grønt lys, når et tog er på vej. Detaljer om hver enkelt guard findes herunder: (when (cars==0 && arriving==true) turn_on_green -> train_enter -> train_exit -> turn_on_red -> open_gate -> SAFE_CROSSING[0][False] Når der ikke er biler i crossing area og et tog er observeret, sættes lyssignalet til grønt, toget passerer ved train_enter og train_exit. Til sidst sættes lyssignalet på rødt (så der ikke kommer flere tog igennem) og bommen åbnes igen. when (cars<max_cars && arriving==false) car[car_id].car_enter -> car[car_id].pass_gate -> SAFE_CROSSING[cars+1][arriving] Når der ikke er et tog på vej og der er plads i crossing area, får bilerne lov til at enter. Herefter får bilen lov at passere bommen ved pass_gate. when (cars>0) car[car_id].car_exit -> SAFE_CROSSING[cars-1][arriving] Så længe der er biler i crossing area, får de lov til at forlade ved exit. Bemærk at der her ikke restringeres på arriving -boolean en. Det er nemlig sådan, at biler skal kunne forlade området, selvom et tog er meldt ankommende. train_arrival -> close_gate -> SAFE_CROSSING[cars][True]). Når et tog ankommer, lukkes bommen. Bemærk at f.eks. arriving==true kan forkortes til arriving og arriving==false kan forkortes til!arriving. Vi har valgt at gøre det som vist, idet vi finder det mest logisk. Denne SAFE_CROSSING skal som sagt bruges til at sikre, at der ikke kan ske kollisioner. I opgave Task e skal dette formelt verificeres vha. den i punkt omtalte safety property NO_CRASH. Denne verifikation findes i punkt Vha. den sikre SAFE_CROSSING laves et succesfuldt trace, som findes i punkt Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 6 af 21

7 1.2.8 RAILROAD RAILROAD RAILROAD = (SENSOR_ARRAY car[car_id]:car TRAIN GATE LIGHT SAFE_CROSSING NO_CRASH) /car[car_id].car_enter/car_enter, car[car_id].car_exit /car_exit, car[car_id].pass_gate/pass_gate. Det samlede system samles ved at sammensætte processerne (inkl. safety property ). Her vises sammensætningen med SAFE_CROSSING. 1.3 Properties For at verificere modellen, kan man indføre såkaldte properties, både til at tjekke safety og liveness : Safety property ( Task c ) Jf. Task c konstrueres en safety property NO_CRASH, som kan verificere, at der kan ske kollisioner med den usikre CROSSING-proces. Property en NO_CRASH verificerer, at en bil vil forlade crossing area, før et tog kan passere. NO_CRASH property NO_CRASH = (train_enter -> train_exit -> NO_CRASH car[car_id].car_enter -> CAR_CONTROLLER[1] ), CAR_CONTROLLER[cars:CAR_ID] = (when (cars<max_cars) car[car_id].car_enter -> CAR_CONTROLLER[cars+1] when (cars>1) car[car_id].car_exit -> CAR_CONTROLLER[cars-1] when (cars==1) car[car_id].car_exit -> NO_CRASH). Hvis et tog laver enter, kommer exit herefter (uden der kan komme andre actions mellem). Hvis en bil derimod laver enter, går property en ned i sin sub-process, der sikrer, at der ikke returneres til NO_CRASH, inden den sidste bil er kørt ud. Denne NO_CRASH bruges i både Task c og Task e til at verificere modellen hhv. vha. den usikre CROSSING (1.6.1) og den sikre SAFE_CROSSING (1.6.2) Liveness property ( Task f ) I Task f laves en liveness property, der verificerer, at et tog på et tidspunkt i fremtiden vil kunne passere crossing area (dvs. udføre action train_enter ). LIVE_TRAIN progress LIVE_TRAIN = train_enter Denne liveness property verificeres formelt i punkt progress LIVE_CAR LIVE_CAR = car[car_id].car_enter Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 7 af 21

8 Vi har lavet en ekstra liveness property, som sikrer, at biler også på et tidspunkt i fremtiden får lov at komme ind i crossing area. Denne verificeres i punkt Vi har her valgt at betragte CAR og TRAIN som to processer, som hver især ikke må udsultes. 1.4 Struktur ( Task g ) I Task g fremstilles et strukturdiagram for modellen (dog uden de nævnte properties), se figur 1 neden for. Diagrammet findes desuden i vedlagte model-structure.pdf. Figur 1: Strukturdiagram På figur 1 ses strukturdiagrammet for RAILROAD. Der er tre biler i vores implementation og det er derfor nødvendigt med renaming af car_enter, car_exit og pass_gate, da vi gerne vil have nummereret bilerne, dvs. prefixet med (car.1..3). Vi har desuden valgt, at alle actions skal være synlige i Railroad-processen. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 8 af 21

9 1.5 Test LTSA-tool et giver mulighed for at teste modellen ved at lave et såkaldt trace. Et trace skal ses som ét muligt gennemløb af modellen. Det er her relevant at lave både et trace, hvor det går galt (dvs. hvor der sker kollision), samt et succesfuldt trace (hvor der ikke sker kollision) Usikker CROSSING ( Task b ) I Task b skal det observeres, at der kan ske kollisioner, når den usikre CROSSING benyttes. Den usikre CROSSING kan give følgende trace: car.1.car_enter train_arrival turn_on_green light_green train_enter Der ses her i nederste linje, at toget får lov at enter crossing area, mens der stadig er en bil i området, hvilket kan føre til en kollision mellem bilen og toget. Dette kan forhindres ved at indføre SAFE_CROSSING som omtalt i At det går galt med denne usikre CROSSING kan også verificeres formelt med LTSA-tool et, som kan finde korteste vej til deadlock. Dette gøres i punkt Sikker SAFE_CROSSING Med den sikre SAFE_CROSSING (lavet i Task d ) kan toget sikkert passere crossing area, idet controlleren sikrer, at eventuelle biler er væk, inden toget får lov at passere. Følgende viser et eksempel, hvor et tog ankommer, mens en bil er i området. Som det ses, bliver bommen lukket (så der ikke kan komme flere biler ind), bilen skal forlade området, og endeligt får toget grønt lys til at lave enter og efterfølgende exit, fulgt af at bommen åbnes igen. car.1.car_enter car.1.pass_gate train_arrival close_gate car.1.car_exit turn_on_green light_green train_enter train_exit turn_on_red open_gate Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 9 af 21

10 1.6 Verifikation LTSA-tool et giver mulighed for at lave en formel verifikation af modellen ud fra et antal properties (som angivet i punkt 1.3) Der kan verificeres i forhold til safety properties og liveness properties Safety check med usikker CROSSING I Task c skal det verificeres, at der kan ske kollisioner med den usikre CROSSING (fra 1.2.6). Følgende sammensatte RAILROAD-proces benyttes til verifikationen: RAILROAD = (SENSOR_ARRAY car[car_id]:car TRAIN GATE LIGHT CROSSING NO_CRASH)... LTSA giver ved at vælge Check Safety følgende meddelelse: Trace to property violation in NO_CRASH: car.1.car_enter train_arrival turn_on_green light_green train_enter Som nævnt i går det galt, når et tog passerer, mens en bil stadig er i området Safety check med sikker SAFE_CROSSING ( Task e ) I Task e skal det formelt verificeres, at der ikke kan ske kollisioner, når den sikre SAFE_CROSSING (fra 1.2.7) benyttes. RAILROAD = (SENSOR_ARRAY car[car_id]:car TRAIN GATE LIGHT SAFE_CROSSING NO_CRASH)... Ved i LTSA igen at vælge Check Safety fås nu følgende meddelelse: Composition: RAILROAD = SENSOR_ARRAY car.1:car car.2:car car.3:car TRAIN GATE LIGHT SAFE_CROSSING NO_CRASH State Space: 1 * 3 * 3 * 3 * 4 * 2 * 6 * 29 * 5 = 2 ** 20 Analysing... Depth States: 115 Transitions: 238 Memory used: 2327K No deadlocks/errors Analysed in: 0ms Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 10 af 21

11 Det er hermed verificeret, at modellen er sikker, når SAFE_CROSSING benyttes som controller Liveness check I Task f laves en liveness property. Denne skal sikre, at et tog på et tidspunkt får lov til at passere crossing area. Denne LIVE_TRAIN findes i I LTSA-tool et vælges Check Progress, der giver følgende resultat: Composition: RAILROAD = SENSOR_ARRAY car.1:car car.2:car car.3:car TRAIN GATE LIGHT SAFE_CROSSING NO_CRASH State Space: 1 * 3 * 3 * 3 * 4 * 2 * 6 * 29 * 5 = 2 ** 20 Progress Check States: 115 Transitions: 238 Memory used: 2378K No progress violations detected. Progress Check in: 10ms Det er hermed verificeret, at modellen tillader, at toget på et tidspunkt får lov at passere. For yderligere at sikre os, at et tog får lov at passere og at property en LIVE_TRAIN virker efter hensigten, har vi forsøgt at give train_enter -action lav prioritet ved at skrive (>>train_enter) efter RAILROAD-processen. Dette gav ikke anledning til nogen progress violation, så LIVE_TRAIN virker efter hensigten. Det bemærkes endvidere her, at den ekstra liveness property LIVE_CAR også er verificeret korrekt. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 11 af 21

12 2 Implementation 2.1 Struktur ( Task h ) I Task h laves implementationsstrukturen for Raiload Crossing. Se figur 2 neden for. Det kan også ses i vedlagte implementation-structure.pdf. Figur 2: Klassediagram 2.2 Java-implementation ( Task i ) I Task i implementeres modellen i Java. Grundlæggende er teknikken her: FSP-processer er implementeret i hver sin klasse Aktive FSP-processer er i Java implementeret som tråde (implements Runnable) Actions i FSP implementeres i de passive Java-klasser som synchronized metoder Som tidligere nævnt er CAR og TRAIN valgt som aktive, da det afspejler virkeligheden mest muligt, idet biler og tog udfører noget aktivt. Alle andre processer er passive. Man kunne have valgt at gøre Crossing aktiv i stedet, og så gøre TRAIN og CAR passive. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 12 af 21

13 Dette valg bevirker, at Java-koden for Car og Train afspejler FSP-koden direkte. I controlleren (SAFE_CROSSING, som i Java implementeres i klassen Crossing) bliver FSP-koden derimod sværere at genkende, men den er dog stadig oversat til Java efter et fast system. Der følger her en forklaring til hver af klasserne: Crossing, Train, Car, Light, Gate og Railroad. Der er desuden klassen Helper, der stiller en statisk waitfornotify- og en statisk sleep-metode til rådighed for at gøre koden simplere. Vi undgår bl.a. at fylde koden med try-catch -statements, så fokus bevares på selve implementationen. FSP-processen SENSOR_ARRAY er ikke implementeret i Java. Grunden til dette valg skal ses i, at den ikke vil tilføje systemet noget yderligere i Java-koden. Alle de passive klasser Crossing, Light og Gate er lavet som Singletons, dvs. så der kun er én instans af hver klasse (jf. Gang of Four -designmønstret) Crossing public class Crossing private int cars; private boolean arriving; private static Crossing instance; public static synchronized Crossing getinstance() if (instance == null) instance = new Crossing(); return instance; private Crossing() cars = 0; arriving = false; public synchronized void train_enter() // As long as there are cars in crossing area, // the train should wait while (!(cars == 0 && arriving == true)) Helper.waitForNotify(this); Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 13 af 21

14 public synchronized void train_exit() Light.getInstance().turn_on_red(); Gate.getInstance().open_gate(); // Allow cars to enter cars = 0; arriving = false; // To represent the train has just exited notifyall(); public synchronized void train_arrival() Gate.getInstance().close_gate(); // Close the gate so no cars can enter arriving = true; // Set the state change notifyall(); public synchronized void car_enter() // Only continue if there is room and no train is arriving while (!(cars < Railroad.MAX_CARS && arriving == false)) Helper.waitForNotify(this); cars++; notifyall(); public synchronized void car_exit() // Cars should always to allowed to exit if (cars > 0) cars--; else // The following println should never occur, since cars cannot exit // unless they have entered. System.out.println("car_exit when no cars in crossing area"); // Since Train is waiting for green, and Crossing is passive, we need to // check whether we need to turn to green light if (cars == 0 && arriving == true) Light.getInstance().turn_on_green(); notifyall(); Crossing er implementationen af SAFE_CROSSING-processen i FSP. Den er implementeret som en Singleton (et GoF-designmønster). Den benyttes af Car- og Train-trådene til at synkronisere i forhold til. Guards fra FSP er lavet som while(!<guard>) wait() -løkker, og låser derved den kaldende proces, indtil dens guard er opfyldt. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 14 af 21

15 2.2.2 Train public class Train implements Runnable private static final int SLEEP_TRAIN_ARRIVAL = 600; private static final int SLEEP_TRAIN_EXIT = 2500; public void run() Light light = Light.getInstance(); // TRAIN = (train_arrival -> light_green -> train_enter -> train_exit -> TRAIN). while (true) train_arrival(); light.light_green(); train_enter(); train_exit(); public void train_arrival() System.out.println("train_arrival"); Crossing.getInstance().train_arrival(); Helper.sleep(SLEEP_TRAIN_ARRIVAL); // Inserted to enforce thread switch public void train_enter() Crossing.getInstance().train_enter(); System.out.println("train_enter"); public void train_exit() System.out.println("train_exit"); Crossing.getInstance().train_exit(); Helper.sleep(SLEEP_TRAIN_EXIT); // Inserted to enforce thread switch Train-klassen indeholder implementationen af FSP-processen TRAIN. Som før nævnt er denne lavet som en tråd (aktiv). Den er lavet meget simpel med en while(true), der udfører togets actions. Alle actions synkroniseres med Crossing ved at kalde den tilsvarende metode i Crossing-klassens Singleton-instans. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 15 af 21

16 2.2.3 Car public class Car implements Runnable private int id; private static final int SLEEP_CAR_PASS_GATE = 500; private static final int SLEEP_CAR_EXIT = 2000; public Car(int id) this.id = id; public void run() // CAR = (car_enter -> pass_gate -> car_exit -> CAR). while (true) car_enter(); pass_gate(); car_exit(); private void car_enter() System.out.println("car." + id + ".car_enter"); // The car_enter action is synchronized with Crossing Crossing.getInstance().car_enter(); public void pass_gate() System.out.println("car." + id + ".pass_gate"); // The pass_gate action is synchronized with Crossing Gate.getInstance().pass_gate(); Helper.sleep(SLEEP_CAR_PASS_GATE); // Inserted to enforce thread switch private void car_exit() System.out.println("car." + id + ".car_exit"); // The car_exit action is synchronized with Crossing Crossing.getInstance().car_exit(); Helper.sleep(SLEEP_CAR_EXIT); // Inserted to enforce thread switch Car er ligeledes implementeret som en tråd. Og ligesom Train laves der ikke andet end at kalde actions i en while(true). Disse actions er også synkroniseret med Crossing for at få præcis kontrol af, hvornår man må udføre de forskellige actions. Hver bil har desuden fået et id, så der kan skelnes Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 16 af 21

17 mellem dem. Dette er lavet lidt anderledes end i FSP, hvor CAR-processen ikke har et id, da dette først tilføjes i den sammensatte RAILROAD-proces Light public class Light private static Light instance; public static final int RED = 0; public static final int GREEN = 1; private int state; public static synchronized Light getinstance() if (instance == null) instance = new Light(); return instance; private Light() state = GREEN; public synchronized void turn_on_green() System.out.println("turn_on_green"); state = GREEN; notifyall(); public synchronized void turn_on_red() System.out.println("turn_on_red"); state = RED; notifyall(); public synchronized void light_red() while (state!= RED) Helper.waitForNotify(this); System.out.println("light_red"); public synchronized void light_green() while (state!= GREEN) Helper.waitForNotify(this); System.out.println("light_green"); Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 17 af 21

18 Light er også lavet som en Singleton-instans. Her styres lysets tilstand, og der er mulighed for at sætte tilstanden samt at vente på en bestemt tilstand. Tilstanden sættes via turn_on_green- og turn_on_red-metoderne, og der ventes på disse tilstandsskift via light_green- og light_red-metoderne. Vi har lavet et valg med hensyn til at huske lysets tilstand. I FSP husker vi på, om det røde eller grønne lys er tændt. I Java har vi indført to ekstra tilstande ved at huske på, om lysene er tændt eller slukkede. Dette har dog ikke nogen praktisk betydning Gate public class Gate public static final int OPEN = 0; public static final int CLOSED = 1; private int state; private static Gate instance; public static synchronized Gate getinstance() if (instance == null) instance = new Gate(); return instance; private Gate() state = OPEN; public synchronized void open_gate() if (state == OPEN) System.out.println("open_gate while already open"); else System.out.println("open_gate"); state = OPEN; public synchronized void pass_gate() if (state == CLOSED) //System.out.println("pass_gate while gate closed"); else //System.out.println("pass_gate"); Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 18 af 21

19 public synchronized void close_gate() if (state == CLOSED) System.out.println("close_gate while already closed"); else System.out.println("close_gate"); state = CLOSED; Gate-klassen er ligeledes lavet som en Singleton. Dens eneste opgave er at holde styr på, om bommen er åben eller ej. Der tjekkes desuden på, om der forsøges at åbne en allerede åben port (og omvendt for en lukket). I FSP-koden huskes tilstandene OPEN og CLOSED og i Java-kode har vi oversat det til en integer state-variabel, som kan være OPEN eller CLOSED Railroad public class Railroad public static final int MAX_CARS = 3; public static void main(string[] args) // Start the car processes Car[] cars = new Car[MAX_CARS]; for (int i = 0; i < cars.length; i++) cars[i] = new Car(i + 1); Thread carthread = new Thread(cars[i]); carthread.start(); // Start the train process Train train = new Train(); Thread trainthread = new Thread(train); trainthread.start(); Railroad er systemets main-klasse, dvs. hvor main-metoden findes, der står for at starte bil- og togtrådene. Ækvivalensen i FSP er den samlede RAILROAD-proces. Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 19 af 21

20 2.3 Test Der er indført passende System.out.println( ), således at en kørsel af Java-programmet vil ligne et trace i LTSA mest muligt. For at lave nedenstående programkørsel er der efter pass_gate i Car-klassen og efter train_arrival i Train-klassen indført en Tread.sleep( ) for at fremtvinge trådskift. Følgende viser programudskriften fra en kørsel af Java-programmet, der præcis er magen til trace et af FSP-modellen i punkt 1.5.2: car.1.car_enter car.1.pass_gate train_arrival close_gate car.1.car_exit turn_on_green light_green train_enter train_exit turn_on_red open_gate Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 20 af 21

21 3 Konklusion Vi har i denne opgave været igennem en proces, hvor vi er begyndt med at definere hovedprocesserne og herefter lavet en model for systemet i FSP-kode. Modellen er trinvis blevet forfinet, bl.a. ved at lave et strukturdiagram, som giver et meget præcist billede af, hvorledes processerne interagerer. Vi er efterfølgende gået fra model til en implementation i Java, dels fordi det var krævet i opgaven, men også fordi sproget letter implementeringen af condition synchronization samt trådoprettelse. Det har været en lærerig proces at modulere Railroad-systemet, selvom vi har lavet opgaven før. Det har især været givtigt at se, hvorledes koden bliver struktureret, når man følger en model, fordi man ikke forfalder til at lave busy waiting, som bare står og bruger en masse ressourcer til ingen verdens nytte. Vi har ifølge vores model nogle passive og aktive klasser, hvor de passive klasser blokerer de aktive, så vi netop undgår spild af processortid. En anden del af opgaven var at finde et passende abstraktionsniveau for modellen, så man undgår unødvendige detaljer, men samtidig medtager de væsentlige detaljer. Vi synes selv, at vi har fundet et passende abstraktionsniveau i modellen. Det var dog var straks lidt sværere, da modellen skulle implementeres i Java, da det flere steder var et tolkningsspørgsmål om, hvordan modellen skulle implementeres. F.eks. er implementationen af Crossing-klassen (som svarer til SAFE_CROSSINGprocessen i FSP) ikke helt givet ud fra FSP-koden. Derimod er Car- og Train-klasserne direkte implementeret ud fra FSP. Modellen er blevet verificeret formelt, dvs. ved graf-farvning i LTSA-tool et. Safety property en NO_CRASH sikrer yderligere, at SAFE_CROSSING virker og dermed at der ikke kan ske sammenstød mellem biler og tog. Vores LIVE_TRAIN-property sikrer som nævnt, at et tog på et eller andet tidspunkt i fremtiden kan komme forbi jernbaneoverskæringen. For at overbevise os selv om, at model og implementation stemmer overens, har vi sammenlignet et trace fra model og implementation og konstateret, at de er ens. Dette er i sig selv ikke nogen garanti, men set i lyset af de enkelte valg, der er gjort i translation fra model til implementation, giver det alligevel en god forsikring om, at modellen er korrekt og at systemet virker. Klaus Leth Pedersen Jan Egberg Lauritzen Mads Pedersen Klaus Leth Pedersen, Jan Egberg Lauritzen, Mads Pedersen Side 21 af 21