Onderhoudsplanner Nedtrain

Transcriptie

1 Technische Universiteit Delft IN Bachelorproject Onderhoudsplanner Nedtrain Edwin Bruurs ebruurs@gmail.com Cis van de Louw cisvdlouw@msn.com 22 augustus 2011 Examencommissie: Prof. dr. C. Witteveen (Technische Universiteit Delft, begeleider) B. Huisman (Nedtrain, begeleider) Ir. B.R. Sodoyer (Technische Universiteit Delft, coördinator)

2 Voorwoord Als afsluiting van onze bachelorface aan de Technische Universiteit Delft moet een zelfstandig project uitgevoerd worden waarbij de kennis vergaard in de bachelorfase wordt toegepast. Dit kan in de vorm van een opdracht aan de universiteit of bij een externe opdrachtgever. Voor dit eindproject is een volledig kwartaal gereserveerd. Aan het eind van het kwartaal dient er een product afgeleverd te worden dat voldoet aan de gestelde eisen door de opdrachtgever. Ons eindproject heeft plaatsgevonden bij Nedtrain waar we een grafische schil hebben ontwikkeld voor een planningsalgoritme. Tijdens dit project werden wij begeleid door Bob Huisman, opdrachtgever en begeleider vanuit Nedtrain, en Cees Witteveen, begeleider vanuit de universiteit. Via deze weg willen wij beide dan ook bedanken voor hun goede begeleiding. Naast Bob Huisman en Cees Witteveen willen we ook Ronald Evers bedanken voor de uitleg over zijn geschreven algoritme en voor het leggen van de basis voor ons project. i

3 Samenvatting De opdrachtgever wil graag een applicatie die om een al bestaand scheduling algoritme heen wordt gemaakt. Het doel hiervan is dat een gebruiker met weinig ervaring planningen kan maken met de applicatie en inzicht moet krijgen in het achterliggende algoritme. Na beraad met de opdrachtgever is besloten dat een aantal dingen een hoge prioriteit hadden en af moesten zijn. Hieronder vielen: een goede datatstructuur om planning op te slaan, een goede grafische weergave van planningen, aanpassingen moeten in planningen kunnen worden gemaakt en vervolgens opgeslagen worden. Vanwege de beperkte tijd van het project is besloten dat de applicatie per functionaliteit ontwikkeld zal worden. Dit leidde er echter in het begin van het project toe dat er te weinig rekening werd gehouden met de latere stadia. Dit had uiteindelijk tot gevolg dat na een aantal weken de code opnieuw geschreven moest worden om het project overzichtelijk te houden en werkend te krijgen. Er werd besloten om een model te introduceren waarin een planning op een makkelijke manier kan worden weergeven. Aan het einde van het project zijn de volgende functionaliteiten ontworpen: SQL database, in deze database worden planningen opgeslagen. Ook wordt in de database verschillende gegevens opgeslagen die nodig zijn om planningen te maken, denk hierbij bijvoorbeeld aan beschikbare resources. Model, het model is ontworpen om de code overzichtelijk te houden en interactie met de database simpel te houden. Een complete planning kan in één keer in het model worden ingeladen. Viewer, de viewer geeft een planning die in het model is opgeslagen grafisch weer. In de viewer heeft men een aantal mogelijkheden om zowel gegevens in de database te veranderen, als gegevens in een planning. Zo kan men planningen toevoegen, verwijderen, activteiten veranderen, activiteiten als voltooid aanvinken, standaard activiteiten en servicing maken etc. Al deze functionaliteiten zijn modulair opgebouwd. Dit houdt in dat elke functionaliteit gemakkelijk te verwijderen of vervangen is en dat makkelijk nieuwe functionaliteiten kunnen worden toegevoegd. Na aanleiding van een rapport van de Software Improvement Group hebben we nog een aantal dingen in de code verandert om deze nog beter onderhoudbaar te maken. Zo hebben we van een aantal methoden de parameters verminderd en hebben we geprobeerd de methoden in kleinere methoden op te breken om de code overzichtelijk te houden. De implementatiefase heeft helaas langer geduurd dan voorzien was waardoor het project ongeveer een week uitliep na de geplande datum van 30 juni. Dit had ook tot gevolg dat er weinig tijd over was voor testen. Dit is dus slechts in een beperkte mate uitgevoerd. ii

4 Inhoudsopgave 1 Introductie 1 2 Opdrachtomschrijving & analyse Opdracht Analyse Uitvoering Deliverables Eisen Beperkingen Gebruikte tools Planning Fasen Tijdsplanning Ontwerp & implementatie Database Planning maken en verwijderen Model Viewer Data Aanpassen Afvinken Proces C Model Software Improvement Group Qt Gnome versus Unity Conclusie 18 7 Aanbevelingen Nieuwe functies Optimalisatie A Opdrachtomschrijving 20 B Oriëntatieverslag 24 C Plan van Aanpak 37 D Requerements and Analysis Document 47 E Software Improvement Group 81 F Documentatie broncode 84 iii

5 1 Introductie Op de afdeling Algoritmiek van de Technische Universiteit Delft is men druk bezig met het ontwikkelen van een algoritme om planningen op te kunnen lossen. Deze opdracht wordt uitgevoerd in samenwerking met Nedtrain. Nedtrain is een dochteronderneming van de NS die het onderhoud van aan de vloot van de NS verzorgt. Om dit te kunnen doen dient er regelmatig een planning gemaakt te worden om alle reparaties in het dienstrooster te plannen. Op dit moment wordt deze planning gemaakt door een personeelslid van Nedtrain. Dankzij het algoritme zou een planner in staat zijn om efficiënter te werken. Onze opdracht bestaat uit het ontwikkelen van een applicatie zodat een planner het algoritme kan toepassen. In dit document zal beschreven worden hoe het project verlopen is en wat het eindresultaat is. In hoofdstuk 1 zullen we uitgebreid beschrijven wat onze opdracht precies is. In hoofdstuk 2 zullen we bespreken wat de planning voor de implementatie was en hoe de planning uiteindelijk is gelopen. In hoofdstuk 3 zullen we laten zien hoe ons ontwerp voor de uiteindelijke applicatie eruit ziet en zullen we uitleggen waarom bepaalde ontwerpkeuzes zijn gemaakt. In het hoofdstuk 4 zullen we uitleggen hoe we te werk zijn gegaan, waar we tegen problemen aan liepen en hoe we deze hebben opgelost. Vervolgens zullen we in hoofdstuk 7 een conclusie schrijven. Als laatste zal in hoofdstuk 8 nog een aantal aanbevelingen gedaan worden voor eventuele studenten die met ons werk verder gaan. Aan het einde van dit document zijn een aantal bijlagen bijgevoegd die dit document ondersteunen met extra informatie. 2 Opdrachtomschrijving & analyse In dit hoofdstuk zal beschreven worden wat de opdracht inhoud en wat de opdrachtgever van ons verwacht. Voor de uitgebreide versie van de opdrachtomschrijving verwijzen we naar bijlage A. 2.1 Opdracht Zoals in de inleiding al vermeld staat heeft de Technische Universiteit Delft in opdracht van Nedtrain een algoritme ontwikkeld dat in staat is om uit een aantal gegevens een optimale planning te genereren. Het algoritme dient rekening te houden met onder andere beschikbare resources, tijd en volgorden. De opdracht van het project bestaat uit het maken van een applicatie die ervoor zorgt dat een planner het ontwikkelde algoritme kan gebruiken. Zo moet er een makkelijke manier komen om data aan het algoritme mee te geven, data op te slaan en moeten de resultaten aan te passen zijn door de planner. De opdrachtgever vindt het belangrijk dat de applicatie de planner niet gaat vervangen, maar eerder dient ter ondersteuning. Het door ons af te leveren product is dus niet bedoeld als automatisering voor het maken van een planning maar als een ondersteunende tool die het werk van de planner eenvoudiger en efficiënter moet maken. Vandaar ook dat één van de eisen is dat de planner zoveel mogelijk vrijheid moet krijgen in de applicatie om een planning naar zijn wens aan te passen. 2.2 Analyse Ronald Evers, de persoon die zich heeft bezig gehouden met het ontwikkelen van het algoritme, had al een eenvoudige interface om zijn algoritme heen gemaakt. Deze ontwikkelde interface laat duidelijk zien wat voor planning het algoritme terug geeft, maar geeft de gebruiker geen vrijheid tot het aanpassen van een planning. Naast de beperkte vrijheid van de planner had deze interface ook geen enkele mogelijkheid om data op een eenvoudige manier in te voeren. Invoeren van data gebeurde via een.txt-bestand, dat zonder enige kennis niet te lezen en/of aan te passen was. Naast het niet kunnen lezen was de kans op het maken van fouten bijzonder groot omdat er veelal met veel parameters gewerkt diende te worden. 1

6 2.3 Uitvoering Aan het begin van het project hebben wij voor onszelf en in overleg met de opdrachtgever een lijst van prioriteiten opgesteld die als eerste dienden te worden ontwikkeld: De opslag van data dient in een gangbare database plaats te vinden. De oplossing van een bepaalde planning moet duidelijk grafisch weergeven worden. Deze grafische weergave moet op een makkelijke manier aan te passen zijn. De gebruiker moet de gegevens in de database via het programma kunnen aanpassen. 2.4 Deliverables Het in te leveren product bestaat uit een aantal executable files. We proberen voor zoveel mogelijk operating systems een executable te maken. We garanderen deze voor Linux voor zowel 32-bit als 64-bit. Ook moet de source code worden ingeleverd en deze code moet voorzien zijn van commentaar zodat eventuele opvolgers de code gemakkelijk kunnen begrijpen en gewoon verder kunnen werken zonder dat ze helemaal opnieuw te moeten beginnen. Vervolgens zal ook nog uitgebreide documentatie worden geleverd waaronder ook dit verslag valt. 2.5 Eisen De belangrijkste eis is dat het programma werkt zonder onverwachte resultaten te geven, dit om de planner een vertrouwd gevoel te geven. Ook is het belangrijk dat de gebruiker zo veel mogelijk vrijheid krijgt en dat deze zich niet door de software bedreigd voelt. 2.6 Beperkingen Tijdens het plannen en programmeren zijn we tegen een aantal problemen aangelopen die te maken hebben met het algoritme. Omdat onze opdracht niet is om het algoritme aan te passen hebben we daarom een aantal beperkingen opgesteld: Omdat het algoritme alleen constraints accepteert en geen posities van activiteiten kunnen we activiteiten niet vastzetten in een planning als deze door het algoritme opgelost wordt. Het algoritme staat niet toe dat aan een job meerdere activiteiten tegelijkertijd worden uitgevoerd. De planner is in staat om meerdere activiteiten per job te plannen, maar door de werking van het algoritme zal deze informatie verloren gaan en wordt de informatie aangepast naar een volgorde waarbij telkens maar één activiteit per keer wordt gepland. Deze beperkingen lijken momenteel misschien nietszeggend maar ze zullen in het volgende hoofdstuk nog uitgebreider aan bod komen. 2.7 Gebruikte tools Tijdens dit project is gebruik gemaakt van Eclipse als ontwikkelomgeving. Om Eclipse te laten werken met C++ en Qt is de Qt plugin voor Eclipse geïnstalleerd samen met de C++ plugin. Alle code wordt opgeslagen op de svn-server van de Technische Universiteit Delft. Integratie van svn in Eclipse gebeurt middels de plugin Subclipse. 2

7 3 Planning Kort na de orientatiefase van dit project hebben we een plan van aanpak opgesteld. In dit hoofdstuk zullen we kijken in hoeverre we de planning hebben kunnen aanhouden en hoe de planning echt is verlopen. Om te zien hoe onze planning er van tevoren uitzag verwijzen we naar bijlage C. 3.1 Fasen We hebben ons goed gehouden aan de fasen indeling die we van tevoren hebben gemaakt. Zo hebben we eerst de oriëntatiefase afgerond. Hierna zijn we begonnen aan het ontwerpen en daarna aan het implementeren. Vanwege de opzet van ons project hebben we echter wel de ontwerpen implementatiefase meerdere malen doorlopen. Hiermee bedoelen we dat we telkens een functionaliteit hebben ontworpen, deze vervolgens hebben geïmplementeerd waarna we deze stappen opnieuw herhaalde voor de volgende functionaliteit. Waar het helaas fout is gegaan, is onze testfase. We hadden veel minder tijd dan we hadden gepland voor het gehele project. We hebben in plaats van de week die we gepland hadden maar twee dagen de tijd om te testen. In deze dagen hebben we wel een aantal bugs weten te verwijderen maar we hadden graag wat meer tijd genomen om intensiever te testen. 3.2 Tijdsplanning Als je de planning zoals die uiteindelijk is gelopen vergelijkt met de planning van het plan van aanpak dan is duidelijk te zien dat de implementatiefase is uitgelopen met ongeveer een week. Met als gevolg dat we te weinig tijd hebben gehad om goed te kunnen testen. Dit heeft er uiteindelijk ook toe geleidt dat we onze presentatie die gepland stond voor 30 juni hebben moeten uitstellen. We hebben dus ongeveer een week te weinig tijd gehad. Waarom de implementatiefase is uitgelopen zal in het hoofdstuk 4 verder worden toegelicht. 4 Ontwerp & implementatie In dit hoofdstuk wordt het uiteindelijke ontwerp van de applicatie besproken. Het uiteindelijke ontwerp wordt vergeleken met het ontwerp dat is besproken in bijlage D. De verschillende secties in dit hoofdstuk vertegenwoordigen elk een apart deelsysteem van de applicatie. Al deze deelsystemen zullen op klassenniveau worden besproken, voor een uitgebreidde beschrijving van elke functie. Zie de documentatie van de code, welke te lezen is in bijlage F. Elke sectie bestaat uit het uiteindelijke klassendiagram en uit een beschrijving met de belangrijkste verschillen tussen het RAD en het uiteindelijke ontwerp. 4.1 Database Deze sectie beschrijft het ontwerp van de database. Daarnaast wordt er ook beschreven hoe de applicatie uiteindelijk met de database communiceert Databaseontwerp De database is opgezet in een MySQL database. Het ontwerp van de database is te zien in figuur 1 en figuur 2. Het totale ontwerp is opgesplitst in twee delen om het databaseontwerp overzichtelijk te houden. In figuur 1 is het ontwerp te zien dat in het opslaan van een planning voorziet. Figuur 2 is het ontwerp dat voorziet in het opslaan van overige gegevens. Omdat ook beide delen praktisch niets met elkaar te maken hebben hoeven beide delen niet via een tabel aan elkaar gelinkt te worden. De tabel constraints wordt op dit moment nog niet gebruikt. De reden hiervoor is dat de solver voor elke activiteit een earliest start time (est) terug geeft. Omdat een est nauwkeuriger is dan een constraint hebben we ervoor gekozen om geen constraints te gebruiken maar est s. Een est 3

8 Figuur 1: Databaseontwerp om een planning in op te slaan Figuur 2: Databaseontwerp om overige gegevens in op te slaan 4

9 geeft namelijk een heel specifiek starttijdstip aan terwijl een constraint alleen maar een volgorde aanduidt. Hierdoor heeft een activiteit bij gebruik van constraints een bereik waarin de activiteit kan plaatsvinden. Er is wel besloten om de tabel constraint te behouden voor eventueel later gebruik. Het databaseontwerp is sinds dat het model is ontworpen niet meer veranderd. Als we kijken naar het eerste ontwerp van de database zien we dat bijna alle tabellen zijn veranderd. De opdrachtgever kwam namelijk tijdens het implementeren met een aantal nieuwe verzoeken (standaard onderhoudsbeurten) welke hij graag opgenomen zag worden in de applicatie en de database. Naast de nieuwe tabellen voor het bijhouden van een onderhoudsbeurt diende de tabellen die betrekking hadden tot het bijhouden van een planning te worden aangepast naar het model, zodat het opslaan van een planning een stuk gemakkelijker werd. Zo is ervoor gekozen om alle elementen van een planning te voorzien van zijn planning id, zodat het veel makkelijker is om een planning in zijn geheel te verwijderen Bewerkingen op de database Om bewerkingen op de database uit te voeren dienden we een klasse te hebben die verbinding maakt met de database. Voor het maken van een verbinding hebben we gebruik gemaakt van een aantal standaard functies van Qt. Er is gekozen om slechts eenmaal verbinding te maken met de database, en wel op het moment dat de applicatie wordt gestart. Wij hebben hiervoor gekozen omdat de applicatie op een standalone computer zal worden gedraaid en er dus geen andere processen zijn die simultaan verbinding met de database willen maken. Het kan dus niet voorkomen dat de verbinding van onze applicatie wordt geweigerd omdat de database aan zijn maximale aantal connecties zit. Bij het sluiten van de applicatie wordt de verbinding verbroken, zodat ook de database na afloop netjes wordt gesloten. Nu er een verbinding tot stand is gebracht met de database is het van belang om queries uit te kunnen voeren op deze database. In het ontwerp hadden we ervoor gekozen om een algemene klasse te schrijven die queries kan uitvoeren. De aanroeper van deze klasse moest zelf voorzien in de query. Uiteindelijk zijn we van dit idee afgestapt omdat het niet verstandig was om de aanroeper zelf zijn query te laten opstellen. Hierdoor dient de aanroeper namelijk ook in staat zijn tot het opvangen van verkeerde resultaten. Er is nu gekozen om gebruik te maken van een klasse databaseactions die een aantal functies heeft die specifieke zaken met de database regelt. Een voorbeeld hiervan is de functie databaseactions::saveplanning(planning *p). Een willekeurige functie kan gebruik maken van de saveplanning(planning *p) functie, om zo een planning op te slaan in de database. Hiertoe dient de aanroeper een instantie van een planning mee te geven. De klasse databaseactions dient er nu voor te zorgen dat de meegegeven planning wordt opgeslagen. Omdat er een groot aantal verschillende queries nodig zijn, is de klasse databaseactions groot geworden. Om deze klasse toch overzichtelijk te houden is ervoor gekozen om de klasse op te splitsen in een aantal verschillende.cpp-bestanden. 4.2 Planning maken en verwijderen Voor het toevoegen en verwijderen gebruiken we verschillende controllers die de GUI aansturen. Alle informatie die in de GUI wordt ingevoerd wordt verwerkt door deze controllers. Deze controllers roepen ook de database-klassen die onder het kopje data-opslag zijn besproken aan. De volgende stappen worden doorlopen om een planning toe te voegen: De controller creëert een addplanningui scherm en de gebruiker voert een naam, start- en einddatum voor een planning in. Vervolgens klikt de gebruiker op Volgende. De controller creëert nu een scherm addjobsui waarin een gebruiker verschillende treinen kan toevoegen, met de knop Voeg nieuwe rij toe voegt de gebruiker meer treinen toe. De gebruiker geeft per trein een naam, startdate, enddate, het type trein en het soort onderhoudsbeurt voor de trein. De gebruiker klikt weer op Volgende. 5

10 Figuur 3: Klassendiagram database 6

11 Figuur 4: Klassendiagram planning toevoegen/verwijderen 7

12 De controller creëert nu een addactivityui scherm. In dit scherm zijn de activiteiten die standaard bij een beurt horen al aangevinkt. Alle overige activiteiten voor dit treintype zijn niet aangevinkt. De gebruiker kan nu alle gewenste activiteiten en gebruikte resources bij deze activiteiten aangeven. Zodra er op Volgende wordt geklikt wordt de planning opgeslagen. Als deze stappen met het orginele design in het RAD worden vergeleken valt op dat bijna alles naar ontwerp is gemaakt behalve het jobsui scherm. Terwijl we bezig waren met programmeren kwamen we erachter dat het handig was om buiten de start- en einddatum van een job ook een treintype en standaardservicing mee te geven. Het idee hierachter is vooral gebruiksgemak, voor een standaard onderhoudsbeurt wil je als gebruiker niet elke keer dat een bepaald type trein binnenkomt dezelfde activiteiten selecteren. Omdat we deze standaardservicing wilden inbouwen moesten we de gebruiker ook gelijk een treintype laten selecteren, een standaardservicing kan namelijk voor twee verschillende typen treinen dezelfde naam hebben maar voor een trein meer resources vereisen dan voor de andere. Er moet dus onderscheidt gemaakt worden. De volgende stappen worden doorlopen om een planning te verwijderen: De controller creëert een scherm voor verwijder planningen, waarin de gebruiker een planning kan selecteren uit alle opgeslagen planningen om te verwijderen. De gebruiker kan hierbij zoeken naar een planning op naam of start- en einddatum opgeven waarbinnen de planning ligt. Vervolgens klikt de gebruiker op de knop Verwijder. Er wordt vervolgens gevraagd of de gebruiker zijn actie wil bevestigen en de geselecteerde planning definief wilt verwijderen. De gebruiker kan nu de planning definitief verwijderen of hij kan zijn actie annuleren. Het uiteindelijke ontwerp van dit deelsysteem is niet veel veranderd met het ontwerp beschreven in het RAD. De belangrijkste wijziging is het toevoegen van een zoekfunctie. Tijdens de eindfase hadden we een medestudent gevraagd om de applicatie te testen, deze merkte op dat als je veel planningen maakte de lijst ontzettend lang zou worden. Er moest dus een manier komen om planningen in deze lijst te zoeken. Daarop hebben we besloten deze zoekopties toe te voegen. 4.3 Model In eerste instantie was er geen model geïmplementeerd. Dit zorgde ervoor dat er op veel plaatsen grote en moeilijk te lezen stukken code onstonden. Uiteindelijk is er toen voor gekozen om een model te implementeren. Het ontwerp van dit model is te zien in bijlage D. Het model is vervolgens zo opgebouwd dat de hoofdentiteit planning is. Een planning heeft beschikking over een lijst met resources, constraints en jobs. Een resource bevat alle gegevens over de beschikbare resources. Dit betekent dat er van een resource wordt bijgehouden wat de naam is en wat de maximale beschikbare capaciteit is. Constraints geven een volgorde aan tussen verschillende activiteiten. In tegenstelling tot de tabel constraints wordt de klasse constraint wel gebruikt omdat de solver constraints aan het algoritme meegeeft en geen est. Job is de representatie van een trein of treinstel welke binnenkomt voor reparatie en bestaat naast een aantal gegevens van deze trein of treinstel ook uit de verschillende activiteiten die moeten worden gedaan aan de trein. Een job kan meerdere activiteiten bevatten. Elke activiteit houdt weer een lijst bij met de verschillende requirements. Een requirement bestaat uit een resource en de gevraagde capaciteit van de resource voor de activiteit. Een requirement geeft dus aan hoeveel capaciteit er van een resources worden gebruikt door de activiteit. Aan de andere kant van het model heb je de verschillende standaard (default) klassen. Deze klassen zorgen ervoor dat verschillende gegevens in de database opgeslagen kunnen worden die nodig zijn om een plannig te maken. Voorbeelden hiervan zijn onderhoudsbeurten en standaard activiteiten. De meeste van deze modellen worden niet veel gebruikt, omdat het veel zaken zijn die niet altijd met elkaar in combinatie gebracht kunnen worden. Het is namelijk beter om eerst standaard activiteiten aan te maken voordat een onderhoudsbeurt wordt aangemaakt. Echter om later veel aanpassingen in één keer door te kunnen voeren zijn deze modellen al wel geïmplementeerd. 8

13 Figuur 5: Klassendiagram model 9

14 Het model is sinds de tweede aanpassing in het RAD niet veel veranderd. We waren bij de implementatie al redelijk ver gevorderd om een goed beeld te hebben hoe we het model moesten implementeren. 4.4 Viewer Om een planning grafisch weer te geven maken we gebruik van een controller die alle data uit de GUI klassen moet verwerken. Het aanroepen van de solver gebeurt ook vanuit dit scherm. De volgende stappen worden doorlopen om een grafische representatie te openen: De controller maakt, zodra in het menu op Show planning wordt geklikt, een scherm aan waarin de gebruiker kan kiezen welke planning geopend moet worden. In dit scherm wordt een lijst met planningen weergeven. Vervolgens wordt een planning geselecteerd en kan op Volgende worden geklikt. De controller construeert nu een viewer met de geselecteerde planning. Het viewer scherm is in principe in 4 gedeeltes op te delen. Elk gedeelte bestaat uit bepaalde typen objecten. In figuur 7 is duidelijk te zien hoe dit is opgedeeld. Links bovenenin (groen) is voor elke job in de planning een jobname object gemaakt waarin de naam wordt weergeven en die het mogelijk maakt het object te vergroten. Rechts daarvan (rood) is een aantal scheduleobjecten toegevoegd. Elk schedule object bestaat uit een grafische representatie van een job. De groene balk geeft de start- en einddatum weer en de blokjes geven de activiteiten per job weer. Links onderin (blauw) zijn de resourcename objecte te zien, deze geven de namen en de beschikbare capaciteit van de resource weer. Rechts hiervan (geel) zijn de resource- Schedule objecten te zien. Deze geven weer hoeveel een resource op elk tijdstip gebruikt wordt. Nu is een planning geopent en is er een eerste grafische representatie weergeven. De gebruiker kan nu de start- en einddatum van de jobs aanpassen door in de buurt van het begin of eind van het groene balkje te klikken en vervolgens te slepen. Ook kunnen de activiteiten in de balk worden verschoven om zo maximale flexibiliteit aan de gebruiker te geven. Constraints aanmaken voor activiteiten gebeurt door ze te verslepen. We hebben ervoor gekozen om deze constraint alleen per job te houden. Zodra je binnen een job een activiteit voorbij een andere activiteit sleept wordt er een constraint aangemaakt die zegt dat de ene activiteit voor de andere moet komen. We hebben gekozen om constraints per job te doen en niet per planning omdat we anders per activiteit die we verschuiven een constraint krijgen voor alle andere activiteiten terwijl dit niet nodig hoeft te zijn. Bij het aanroepen van de solver wordt de planning die in de viewer is opgeslagen in zijn geheel doorgestuurd naar de solver. De solver creëert van deze planning vervolgens bytearray die wordt doorgegeven naar het algoritme. Het algoritme geeft vervolgens een planning terug aan de solver en deze geeft de planning weer aan de controller en deze laadt het in de viewer. Het ontwerp van deze functionaliteit is vrijwel naar specificatie geïmplementeerd. De wijzigingen die zijn aangebracht hebben betrekking op het toevoegen van een progressbar. De progressbar is toegevoegd omdat we tijdens het testen tegen een aantal instanties aanliepen die voor het algoritme moeilijker oplosbaar waren en dus langer duurden. Om dit aan te geven hebben we dus de progressbar geïmplementeerd. 4.5 Data Aanpassen Voor het aanpassen van data zijn verschillende schermen nodig. Voor elke scherm hebben we weer een controller gemaakt die alle informatie in en naar het scherm verwerkt. Er zijn drie soorten data die bewerkt kunnen worden. Je kan nieuwe standaard activiteiten aanmaken, nieuwe onderhoudsbeurten aanmaken, aanpassen en verwijderen en resources toevoegen en aanpassen. Het maken van een standaard activiteit: 10

15 Figuur 6: Klassendiagram grafische weergaven van een planning 11

16 Figuur 7: Weergave in viewer 12

17 Figuur 8: Klassendiagram om data aan te passen 13

18 De controller opent het scherm voor het maken van de activiteit. Je kan nu een naam, trein type, duur en de verschillende gebruikte resources invullen. Vervolgens kan je kiezen voor Opslaan om op te slaan of Voeg nog een toe om nog een standaard activiteit toe te voegen. In beide gevallen wordt de activiteit opgeslagen. Het maken van een onderhoudsbeurt: De controller opent het scherm voor het maken van een onderhoudsbeurt. Je kan nu de onderhoudsbeurt een naam geven en kiezen voor welk treintype deze beurt is. In dit scherm zie je ook alle activiteiten die voor dit treintype zijn gemaakt. Een onderhoudsbeurt bestaat uit een aantal van deze activiteiten die je kan kiezen door ze aan te aanvinken. Het aanpassen van een onderhoudsbeurt: Nadat de controller dit scherm opent kan je kiezen uit een treintype en dan krijg je alle onderhoudsbeurten die je voor deze trein kunt kiezen te zien. Kies één van deze beurten en je kan vervolgens de verschillende standaard activiteiten aanpassen. Het verwijderen van een onderhoudsbeurt: De controller opent een scherm waarin je een treintype kiest en vervolgens krijg je een lijst met alle onderhoudsbeurten voor dit type te zien. Selecteer de juiste beurt uit en klik op Verwijder. Het toevoegen van resources: De controller opent het scherm en je kan voor een nieuwe resource de naam en de hoeveelheid opgeven. Klik vervolgens op Opslaan om de informatie op te slaan. Het wijzigen van resources: De controller opent een scherm waarin alle resources worden weergeven en de maximale beschikbare capaciteit. Je kan nu de naam van de resource en maximale beschikbare capaciteit aanpassen. Bij resources moet een kanttekning gemaakt worden. Het is namelijk zo dat het op dit moment niet mogelijk is om resources te verwijderen. Dit is een keuze die we gemaakt hebben om te voorkomen dat zowel de solver als ons programma zelf niet meer werken. Het probleem is namelijk dat als je een resource verwijdert er nog steeds planningen zijn die die resource nodig zullen hebben, sommige planningen krijgen dan overwachte resultaten Om het verwijderen van resources toe te staan kunnen dan met sommige planningen onverwachte resultaten gebeuren. 4.6 Afvinken Het afvinken van activiteiten is een verlenging van de functionaliteiten van de viewer. Er is een klasse toegevoegd welke een scherm opent waarin extra informatie over de activiteit getoond wordt. In dit scherm kan je een acticviteit vervolgens afvinken. De volgende stappen worden doorlopen om een activiteit af te vinken: De gebruiker dubbelklikt op een activiteit en een nieuw scherm met extra informatie wordt geopend. In dit scherm worden de naam van de activiteit en de gebruikte resources weergeven. Ook is er een checkbox waarin de gebruiker kan selecteren of een activiteit afgerond is of niet. Zodra de gebruiker klaar is klikt deze het scherm weg. Dit lijkt op zich een simpele implementatie. Dat is het ook, maar we moesten nu wel rekening houden met het feit dat de activiteit niet meer in de solver of constraints meegenomen mag worden. De activiteit staat echter nog wel in de planning. Omdat er nu in de telling van de planning een gat valt en de solver alleen met opeenvolgende getallen overweg kan hebben we de methoden voor het genereren van constraints en het aanroepen van de solver zo moeten aanpassen dat afgevinkte activiteiten niet meer worden meegenomen naar het algoritme. 14

19 Figuur 9: Klassendiagram voor het afvinken van activiteiten 15

20 5 Proces In dit hoofdstuk wordt het proces wat we hebben door gelopen tijdens het bachelorproject beschreven. We zijn tijdens het ontwikkelen van de applicatie tegen een aantal problemen aangelopen die we in dit hoofdstuk zullen bespreken. Naast het bespreken van de problemen zullen ook de oplossingen worden besproken. Ook zullen we uitleggen hoe we hebben geprobeerd onze code te verbeteren met het commentaar dat we van de Software Improvement Group(SIG) hebben gekregen. Voor het volledige rapport van SIG verwijzen we naar bijlage E. 5.1 C++ Het bachelorproject was voor ons beide het eerste project waar we in aanraking kwamen met de programmeertaal C++. In eerste instatie leverde de syntax van deze taal wat problemen op. Het werken met bijvoorbeeld pointers en forward declarations liep in het begin niet optimaal, waardoor zeker in het begin van het project heel wat code is geschreven die later op een veel simpelere manier werd herschreven. Het gevolg hiervan was dat de planning anders liep dan dat we in eerste instantie hadden gepland. Het bleek dat we in het begin van het project, waar nog relatief simpele functionaliteiten zijn geschreven, veel meer tijd kwijt waren met het implementeren dan verwacht. Uiteindelijk heeft dit ook voor een groot deel bijgedragen aan de totale uitloop van het project. Naast C++ werd ook gebruik gemaakt van het framewerk Qt. Qt was relatief gemakkelijk te leren, en hierdoor waren wij in staat om op een snelle manier goed werkende gebruikersinterfaces te maken. Het gebruik van Qt maakt het bijvoorbeeld heel gemakkelijk om events aan objecten te hangen, verbinding te leggen met een database en de grafische stijl van het besturingssysteem te benutten. Door de problemen die we vooral in het begin ondervonden met C++ waren we genoodzaakt om vaker terug te grijpen naar de literatuur. Hierdoor hebben we veel nieuwe zaken over C++ geleerd. Uiteindelijlk viel dit ook op te merken aan het tempo waarin we nieuwe functionaliteiten konden opleveren. Dit tempo lag in het begin van het project veel lager dan aan het eind van het project, terwijl de kwaliteit aan het eind van het project veel hoger lag dan aan het begin van het project (code vanuit het begin is vaker herschreven dan code later uit het project). 5.2 Model Aan het begin van het project hadden we vooral per functionaliteit ontwikkeld. Echter hebben we niet goed gekeken hoe het geheel er uit zo komen te zien. We hadden bedacht hoe alle functionaliteiten aan elkaar werden gekoppeld maar er werd geen rekening gehouden met de onderliggende objecten. Het gevolg hiervan is dat er een moment kwam waarop de code onoverzichtelijk werd, er veel dubbele code ontstond en veel objecten overbodig complex werden. Een voorbeeld hiervan was de klasse die het opslaan van een planning voor zijn rekening nam. Deze klasse bestond uit 10 tot 15 queries om alle gegevens uit de database te halen en de nieuwe gegevens weer weg te schrijven. Naast het groot aantal queries dat moest worden geschreven merkte we ook dat we steeds vaker niet precies meer wisten wat en waarom we iets deden. De klasse was te complex geworden. Uiteindelijk hadden we de klasse goed werkend gekregen en konden we beginnen aan een volgende klasse. Deze klasse bevatte veel code die ook in de vorige klassen was geschreven en uiteindelijk dubbel in het project zouden voorkomen. Op dit moment hebben we besloten om heel het project om te gooien. Na overleg met Cees Witteveen en Bob Huisman is er besloten om een goed model te ontwerpen en deze te implementeren (Zie bijlage D voor het ontwerp van het model). Dit model zorgde ervoor dat we veel code konden hergebruiken door simpelweg objecten aan te roepen. Naast het hergebruiken van code waren we ook in staat om code gemakkelijker op te schrijven en te begrijpen. Het model bestaat uiteindelijk uit een aantal objecten die entiteiten uit het probleem bevatten. Voorbeelden hiervan zijn planning, job, activity en train. Daarnaast is er ook een goede klasse geschreven die verschillende queries kan uitvoeren op de database. Elke 16

21 mogelijke klasse kan beschikking hebben over de databaseactions klasse. Deze klasse zorgt er vervolgens voor dat de juiste gegevens naar de database worden geschreven of worden uitgelezen. Terugkijkend op het hele project is het een goede beslissing geweest om het model te implementeren. Mochten we deze keuze niet hebben gemaakt dan zouden we waarschijnlijk geen goed werkend product hebben kunnen opleveren. Helaas heeft ook het implementeren van het model veel extra tijd gekost (ongeveer 40 manuren). Maar ook hier geldt dat we uit de gebeurtenissen veel hebben kunnen leren en een soortgelijke fout waarschijnlijk nooit meer maken. 5.3 Software Improvement Group Een onderdeel van het bachelorproject is een beoordeling van de geschreven code door de Software Improvement Group (SIG). SIG schrijft een rapport met aanbevelingen over hoe we onze code kunnen verbeteren. Er wordt in het rapport vooral gekeken naar de onderhoudbaarheid van de code. In Bijlage E staat het volledige rapport van SIG. Het resultaat van SIG was zeer positief. Naast de verwachte opmerking dat er testklassen ontbraken, gaf SIG ook het advies om naar het aantal parameters te kijken van bepaalde klassen en de grootte van sommige functies te herzien Testklassen De opmerking van SIG over de ontbrekende testklassen is inderdaad terecht. Wij hebben ervoor gekozen om testklassen niet te implementeren omdat een groot deel van de applicatie uit een grafische interface bestaat, welke lastig te testen door middel van unittesting. Echter is dit geen reden om de onderliggende klassen niet grondig te testen. Ook hiervoor is gekozen om geen unittests te schrijven, omdat we al veel tijd kwijt waren dankzij het herschrijven van het model en goed gebruiken van de programmeertaal. Het ontbreken van testklassen is dus grotendeels te wijten aan tijdsgebrek Sommige klassen maken gebruik van een aardig aantal parameters. SIG adviseert om het aantal parameters van een klasse die nodig zijn voor het creëren van een instantie flink te reduceren. Ook het gebruik van het algemene type int om een bijvoorbeeld een Job aan te geven raadt SIG sterk af. Om het aantal parameters van een klasse te reduceren moet er veel code worden herschreven. Deze opmerking van SIG is op dit moment lastig door te voeren hierdoor, maar is wel een opmerking die bij latere projecten goed gebruikt kan worden. De opmerking om specifiekere parameters te gebruiken in plaats van een algemeen type int is wel aangepast. Hierdoor bevatten verschillende klassen die eerst een int id als parameter nodig hadden nu het specifieke object. Een concreet voorbeeld hiervan is de klasse Activity. Deze klasse maakte gebruik van een parameter int jobid. Deze is nu vervangen door een pointer naar de juiste Job. Int jobid is nu dus vervangen door Job* job Lengte functie Het aantal regels code dat een functie bevat is in sommige gevallen inderdaad erg lang. Voor een aantal functies is dit aangepast. De overige functies waren zijn niet aangepast, omdat in deze gevallen het zou gebeuren dat functies weer veel extra parameters mee zouden krijgen. 5.4 Qt Qt is een handig framework om grafische interfaces te programmeren. Omdat een aantal belangrijke onderdelen van Qt abstracter werken (het gebruik van SLOT en SIGNAL) dienden we regelmatig terug te grijpen op literatuur. Ook foutmeldingen die door verkeerd gebruik van Qt werden veroorzaakt waren niet altijd even duidelijk en ook niet rechtstreeks naar Qt te herleiden. 17

22 Echter ook hierbij was het een kwestie van ervaring opdoen, zodat het steeds makkelijker werd om met Qt te programmeren. 5.5 Gnome versus Unity Een ander probleem waar we tegen aan liepen was een mogelijke bug in de combinatie Qt en de Gnome desktop omgeving. Deze combinatie zorgde ervoor dat instanties van een planning niet goed werden weergegeven en dat teruggekregen resultaten niet goed werden weergegeven. Helaas hebben we geen verwijzing kunnen vinden naar bugreports over hetzelfde probleem, maar we hebben aangenomen dat dit inderdaad een bug is omdat exact dezelfde instantie en code andere resultaten teruggeven bij gebruik van andere desktopomgevingen (Unity en Windows). 6 Conclusie Ons doel tijdens dit project was: Het maken van een programma waarmee een willekeurige persoon een planning kan maken en waarmee we de resultaten van een algoritme duidelijk weergeven kan worden. Om dit doel te bereiken hebben we een interface gemaakt die het gemakkelijk maakt om gegevens in te voeren in een database en ook weer op te halen uit een database. Bovendien hebben we de interface zo gemaakt dat de gebruiker zo veel mogelijk vrijheid krijgt in het maken van keuzes voor een planning. Zo kan een planner meerdere planning op verschillende manieren onder verschillende condities samenstellen en vergelijken. We kunnen het doel opdelen in twee stukken, één deel dat bestaat uit het maken van een functionele datastructuur die het mogelijk maakt gemakkelijk nieuwe data van nieuwe functionaliteiten op te slaan. Dit deel is vooral belangrijk voor programmeurs die aan onze applicatie verder gaan werken. Deel twee is belangrijk voor de gebruiker, dit deel bestaat uit het duidelijk weergeven van een eenvoudige interface om planningen te creëren. We hebben deel 1 bereikt door de database en het model in het programma zo veel mogelijk op elkaar te laten lijken. Als er dus een functie bij het programma wordt bijgeschreven, dan hoeft de database alleen maar te worden aangepast daar waar het model ook moet worden aangepast. Dit zorgt voor makkelijke uitbreidbaarheid en opdeling van het programma. Het tweede deel hebben we bereikt door een in onze ogen intuïtieve en duidelijke grafische interface op te zetten waarbij acties in een zo minimaal mogelijk aantal handelingen kunnen worden uitgevoerd. We hebben er ook op gelet dat in de grafisch representatie bijna alles aan te passen is door middel van drag & drop zodat geen extra schermen geopend hoeven te worden. De conclusie is dus dat we de kerneisen die aan ons programma gesteld werden hebben kunnen bereiken. Vanwege tijdgebrek zijn er echter nog een aantal veelal kleine functionaliteiten die we niet af hebben kunnen maken. Deze zullen we kort beschrijven in het hoofdstuk 7. 7 Aanbevelingen Dit hoofdstuk zal aanbevelingen bevatten om de applicatie uit te breidden. Deze aanbevelingen zullen vooral bestaan uit functionaliteiten waar geen tijd meer voor was om te implementeren of te optimaliseren. 7.1 Nieuwe functies Er zijn een aantal functies die we graag hadden willen implementeren maar waar we vanwege tijd beperking gewoon niet aan zijn gekomen: Het aanpassen van een planning, dus het toevoegen en verwijderen van jobs in een bestaande planning. Hetzelfde geldt voor het toevoegen en verwijderen van activiteiten. 18

23 Een manier om bij activiteiten duidelijk te maken wat de naam van de activiteit is. We hebben hier zelf een aantal dingen geprobeerd maar deze zijn afgewezen omdat het niet praktisch bleek. Zo hebben we geprobeerd de tekst in het activiteitblok zelf te zetten. Het probleem hierbij was dat als het blokje te klein was de activiteitnaam werd afgesneden. Ook het laten verschijnen van een naam als je je muis stil houdt over een activiteit was niet mogelijk omdat dan het object vergroot moest worden wat grafisch lelijke resultaten gaf. De enige manier om op dit moment de naam van een activiteit te zien is via het extra informatie scherm. Een duidelijkere feedback van de applicatie naar de gebruiker is gewenst. Op dit moment wordt er een beperkte laadbalk weergegeven als de applicatie de solver heeft aangeroepen en nog wacht op resultaten. Het zou een mooie uitbreiding zijn als ook tijdens het tekenen van een instantie betere feedback naar de gebruiker wordt gegeven. Één van de dingen die we graag geïmplementeerd hadden gezien was het mogelijk maken van het vergelijken van planningen. Dus een manier om twee planningen op een scherm te weergeven. 7.2 Optimalisatie Er zijn een aantal functies in het programma die naar verhouding veel tijd kosten en die beter te schrijven zouden moeten zijn. We zullen hier een overzicht geven van de functies waarvan wij denken dat ze nog effeicienter of beter geschreven kunnen worden calculatedemandprofile De klasse resourcewidget bevat een functie om de te gebruiken resources te tekenen. Deze functie bestaat uit de functies calculatedemandprofile, createpoints en updatepixmap. Op dit moment wordt in calculatedemandprofile de hoogte van elke punt x dat ligt tussen de eerste relevante activiteit voor een resource en de laatste berekent. Vervolgens wordt voor elk punt in de create- Points methode een punt gemaakt. Dit is nodig om in de updatepixmap metode deze punten toe te voegen aan een polygon. In Qt is de enige manier om een polygon te tekenen door er punten in te stoppen. Verrassend genoeg kosten de eerste twee methoden weinig tot geen tijd. Het probleem zit in het tekenen van het polygon. We hebben geprobeerd dit op verschillende manieren te verbeteren. Zo hebben we geprobeerd alleen punten toe te voegen op de uiteinden van activiteiten, dus verhoog de y op de plek van de eerste x van een activiteit en verhoog het op de laatste x van een activiteit. Naar onze verbazing had dit geen effect op de performance. De enige manier die wij kunnen bedenken om deze methode te verbeteren is om een andere manier te vinden om te tekenen, dus niet met behulp van een polygon. Vanwege de tijd hebben we echter helaas moeten besluiten dit achterwege te laten en aan de volgende personen over te laten Algoritme Als het algoritme een instantie heeft opgelost en we gebruiken het resultaat als invoer om het algoritme een tweede keer te draaien, blijkt dat dit veelal een optimaler resultaat geeft dan wanneer we het algoritme slecht één maal laten draaien. Omdat het oplossen van een instantie door het algoritme vaak maar slechts enkele seconden duurt, is het een idee om het algoritme standaard twee keer te laten draaien. Het nadeel hiervan is dat de gebruiker langer moet wachten, maar hierdoor wel de kans bestaat dat er een betere oplossing wordt gegenereerd. Een ander alternatief is om het algoritme zo aan te passen dat deze eerder neigt naar de meest optimale oplossing. Echter deze oplossing valt buiten de scope van een bachelorproject. 19

24 A Opdrachtomschrijving 20

25 Bachelorproject - Opdrachtomschrijving Edwin Bruurs ebruurs@gmail.com Cis van de Louw cisvdlouw@msn.com

26 Het bacheloreindproject zal worden uitgevoerd in opdracht van Nedtrain. Nedtrain heeft in samenwerking met de Technische Universiteit Delft een algoritme ontwikkeld voor het plannen van resources die benodigd zijn tijdens reparaties aan treinen. Voorbeelden van deze resources zijn personeel, putspoor en kuilwielbank. Het algoritme maakt gebruik van een door een planner gemaakt masterplan om zo verbeteringen te adviseren over dit masterplan. De opdracht zal nu bestaan uit het ontwikkelen van een grafische schil voor het algoritme waarmee een planner op een makkelijke manier kan werken. Het doel van de te ontwikkelen software is niet om de planner te vervangen maar om de planner te ondersteunen in het maken van beslissingen. Naast de ondersteunende functie van de te maken applicatie is het ook de bedoeling dat de applicatie voor leerdoelen gebruikt kan worden. Omdat het te ontwikkelen systeem geaccepteerd dient te worden door een planner moet met het volgende rekening worden gehouden: De software dient niet gebruikt te worden als vervanger voor de planner. De software die ontwikkelt gaat worden moet door de planner gebruikt kunnen worden ter ondersteuning. De planner moet het gevoel hebben dat hij belangrijk is voor het maken van een planning. Hierdoor voelt hij zich meer betrokken tot het bedrijf. De software moet doen waar de software goed in is. Indien de software vaak onrealistische planningen maakt, neemt het vertrouwen van de planner in de software af. Hierdoor zal hij eerder neigen om zijn ervaring te vertrouwen dan af te gaan op de adviezen van de software. De software dient meerdere optimale adviezen te geven. De kennis van omgevingsfactoren kan van essentieel belang zijn voor het accepteren van een planning. De optimale oplossing hoeft namelijk niet altijd de best haalbare oplossing te zijn. De software moet inzicht geven in de gemaakte keuzen. Als de planner uiteindelijk een planning heeft opgesteld op basis van adviezen van het systeem moet het voor de planner duidelijk zijn hoe het systeem tot deze adviezen is gekomen. De planner moet inzicht kunnen verkrijgen in de keuzes die het algoritme heeft gemaakt om tot de adviezen te komen. De functionaliteiten die het te ontwikkelen systeem moeten bevatten zijn: Advies geven. De primaire taak van de software dient om advies te geven aan de planner op basis van een bestaand masterplan. Suggesties van planner doorberekenen. De software dient in staat te zijn adviezen van de planner te verwerken en op basis daarvan nieuwe adviezen te genereren. Deze functionaliteit vertoont grote overeenkomsten met de functionaliteit Advies geven omdat er in feite een advies wordt gevraagd over een aangepast masterplan. Voortgang huidig plan aangeven. Op het moment dat er activiteiten zijn afgewerkt dient dit geadministreerd te worden in het systeem. Hierdoor kan de planning eventueel aangepast worden. Aangeven van knelpunten. Indien blijkt dat er geen mogelijke planning te produceren is dient het systeem de knelpunten aan te geven. Geschiedenis betrekken bij een nieuw masterplan Als er een nieuw masterplan wordt ingevoerd dienen openstaande zaken van het vorige masterplan meegenomen te worden. Een voorbeeld hiervan is dat als er op vrijdagavond werkzaamheden nog niet zijn afgerond dan dienen deze in het masterplan voor de volgende week te worden opgenomen. 22

27 Koppeling met externe gegevens. Het te ontwikkelen systeem dient zo te worden ontworpen dat het mogelijk is om gegevens uit externe databronnen te gebruiken. Een voorbeeld hiervan is dat het systeem gebruik moet kunnen maken van gegevens over de personeelsbezetting. Inzicht geven. Het systeem dient inzicht te geven in het algoritme. Het is dus noodzakelijk om het algoritme stap voor stap uit te kunnen voeren om zo de gemaakte stappen te analyseren. Overige eisen: Aanpasbaar De userinterface dient gebruik te maken van de beschikbare interface van het algoritme. Mocht er uiteindelijk een nieuw algoritme worden ontwikkeld dan dient dit algoritme nog steeds gebruik te kunnen maken van de door ons ontwikkelde userinterface. Uitbreidbaar De userinterface dient gemakkelijk uit te breiden zijn zodat nieuwe functionaliteiten eenvoudig toegevoegd kunnen worden. Schaalbaar Het uiteindelijke systeem dient op een willekeurige stand-alone computer te draaien, ongeacht besturingssysteem of hardware. 23

28 B Oriëntatieverslag 24

29 Bachelorproject - Oriëntatieverslag Edwin Bruurs ebruurs@gmail.com Cis van de Louw cisvdlouw@msn.com

30 Voorwoord In dit document zullen we verslag doen van de oriëntatiefase van 2 weken die we aan het begin van ons bachelorproject hebben moeten doorlopen. In deze fase hebben we vooronderzoek gedaan op een aantal vlakken die van belang zijn voor de software die wij gaan ontwikkelen. Denk hierbij bijvoorbeeld aan onderzoek naar de programmeertaal waarin gewerkt gaat worden, maar ook aan het algoritme waar wij een grafische schil omheen moeten maken. 26

31 Samenvatting Nedtrain is een dochterberijf van de Nederlandse Spoorwegen (NS) dat onderhoud van de treinen verzorgt. Daarbij zijn er 3 belangrijke onderhoudsafdelingen; service, onderhoud en refurbishment & overhaul. Het maken van schema s voor dit onderhoud van treinen is een ingewikkeld probleem waarbij rekening gehouden moet worden met verschillende beperkte resources en onverwachte omstandigheden zoals onderhoud dat kan uitlopen of bepaalde activiteiten die voor andere moeten plaatsvinden. Er is een algoritme ontwikkeld dat gebruik maakt van simple temporal netwerken en het ESTA+ algoritme om deze schema s te ontwikkelen en daarbij rekening houdt met de hierboven genoemde problemen. Nadat het algoritme zijn werk heeft gedaan is het belangrijk om ervoor te zorgen dat een planner kan begrijpen wat het algoritme doet en dus gebruik kan maken van een duidelijk interface die weergeeft hoe het algoritme werkt en tot aanbevelingen komt. Dit is de uiteindelijke applicatie die wij moeten gaan ontwikkelen. Hiervoor gaat gebruik gemaakt worden van de programmeertaal C++ met de toolkit Qt die handig is om interfaces mee te ontwerpen. Qt is handig doordat de beschikbare klassen in deze IDE de implementatie van grafische interfaces vereenvoudigen. 27

32 Inhoudsopgave 1 Introductie 29 2 Nedtrain Organisatie Onderhoud Planning Probleemomschrijving Algoritme Grafische schil Solver Algoritme Interface Grafische user interface C, C++ en Qt C en C Qt

33 1 Introductie Nedtrain heeft in samenwerking met de Technische Universiteit Delft een algoritme ontwikkeld dat een schema kan maken voor het plannen van resources en personeel op een zo efficiënt mogelijke manier. Het is de bedoeling dat er een applicatie wordt ontwikkeld die de planner van Nedtrain kan ondersteunen in het maken van planningen. Onze opdracht bestaat uit het ontwikkelen van een grafische interface zodat de planner het algoritme kan gebruiken om planningen te maken. Het is hierbij belangrijk dat het alleen maar om suggesties gaat en dat het inzicht in het algoritme met behulp van de grafische interface wordt vergroot. In dit document zullen we kort rapporteren over het vooronderzoek dat we gedaan hebben over gebieden die raakvlakken hebben met onze opdracht. In hoofdstuk twee zullen we kort beschrijven wat Nedtrain voor bedrijf is en hoe dit bedrijf georganiseerd is. Hoofdstuk drie zal een tweetal problemen beschrijven die Nedtrain is tegengekomen en die voor ons van belang zijn. Vervolgens zal in hoofdstuk vier de huidige oplossingen voor deze problemen worden besproken. Als laatste hoofdstuk, hoofdstuk 5, zullen we de te gebruiken programmeertalen en programma s die we gebruiken kort bespreken. 2 Nedtrain In dit hoofdstuk wordt de organisatie en werkwijze van Nedtrain worden besproken. We richten ons hierbij vooral op dat gedeelte van Nedtrain waar wij mee te maken krijgen. Er zal eerst worden begonnen met het kort bespreken van de organisatiestructuur van Nedtrain. Vervolgens gaan we in de tweede sectie kijken naar de werkwijze voor het onderhoud aan treinen. In de laatste sectie wordt er gekeken naar het gebruik van planningen bij Nedtrain. 2.1 Organisatie In deze sectie zal eerst kort worden ingegaan op de NS en dochterbedrijf Nedtrain. In de eerste paragraaf zal de organisatie van de NS worden besproken en gekeken worden hoe Nedtrain in deze organisatie past. Vervolgens wordt er in het tweede gedeelte de organisatiestructuur van Nedtrain besproken NS Nedtrain is het dochterbedrijf van de NS. De NS is Nederlands grootste spoorwegexploitant, en bestaat uit twee afdelingen. De eerste afdeling verzorgt de knooppuntontwikkeling en -exploitatie, de tweede afdeling verzorgt het reizigersvervoer. Nedtrain valt onder de afdeling reizigersvervoer en verzorgt het onderhoud aan treinen van zowel de vloot van de NS als van andere spoorwegexploitanten. Figuur 1 geeft een overzicht van de organisatie van de NS weer Nedtrain Nedtrain bestaat uit een aantal afdelingen waarvan Operations het daadwerkelijke onderhoud voor zijn rekening neemt. Operations verdeelt het onderhoud in drie afdelingen namelijk; Service, Onderhoud en Refurbishment & Overhaul. In sectie wordt dieper ingegaan op de drie afdelingen. Figuur 2 geeft de organisatiestructuur van Nedtrain schematisch weer. 2.2 Onderhoud Bij het onderhoud komen twee belangrijke aspecten naar voren, het soort onderhoud en de beschikbare resources. Beide zullen in de volgende paragrafen worden besproken. 29

34 Figuur 1: Organisatiestructuur NS [5] Figuur 2: Organisatiestructuur Nedtrain [4] 30

35 2.2.1 Soorten onderhoud Nedtrain heeft het onderhoud verdeeld in drie afdelingen; Service, Onderhoud en Refurbishment & Overhaul. Elke afdeling heeft zijn eigen taken die hieronder kort staan beschreven. Service: om de dag komt een trein bij service langs om schoon te worden gemaakt en kleine technische mankementen te repareren. Onderhoud: een paar keer per jaar moet een trein naar onderhoud, hier wordt onder andere gecontroleerd of de trein voldoet aan de gestelde veiligheidseisen, wordt onderhoud en herstellingen uitgevoerd en worden onderdelen vervangen (bijvoorbeeld wielen). Refurbishment & Overhaul: een paar keer per levensduur van een trein dient deze naar refurbishment & overhaul te gaan. Hier wordt onder andere de trein gemoderniseerd en gereviseerd. Ook het herstellen van schade aan treinen wordt door deze afdeling verzorgd. De opdracht waar wij naar zullen kijken is vooral gericht op het onderhoud van de treinen Resources Voor het onderhoud aan treinen heeft Nedtrain beschikking over een aantal resources. Deze zijn op te delen in werkplekken en personeel. Er kunnen in een onderhoudscentrum meerdere werkplekken van één type zijn en elk type werkplek heeft hierdoor een eigen capaciteit. De volgende opsomming geeft de belangrijkste typen werkplekken weer. Aardwind: deze werkplek is uitgerust met een lift om zo de draaistellen van de trein te kunnen inspecteren en vervangen; Automatische Trein Beïnvloeding (ATB): dit speciale spoor is ontwikkeld om de veiligheid van een trein te testen; Kuilwielbank: op dit spoor is het mogelijk om de wielen van treinen opnieuw vorm te geven; Putspoor: het putspoor is een spoor waarbij de vloer verlaagd is zodat monteur makkelijk aan de onderkant van de trein kan werken. Naast werkplekken heeft Nedtrain ook beschikking over monteurs die werkzaamheden aan treinen uitvoeren. 2.3 Planning De NS maakt gebruik van een globale planning van een half jaar. Hierin staat opgenomen wanneer welk type trein binnenkomt en wanneer deze klaar dient te zijn. Naast de start- en eindtijd staat er in de planning ook welk onderhoud aan de trein uitgevoerd moet worden. NS reizigers en Nedtrain hebben dit schema zo opgesteld dat het globale schema te verdelen is in een weekschema dat zich ieder half jaar herhaalt. Hierdoor kan Nedtrain gebruik maken van een basisschema van telkens een week. Twee weken voordat het schema wordt uitgevoerd worden de specifieke details bekend gemaakt. Met deze details bedoelen we welke treinen er precies in onderhoud komen en welk onderhoud uitgevoerd moet worden. 3 Probleemomschrijving Het maken van schema s voor het onderhoud aan treinen wordt op dit moment volledig gedaan door menselijke planners. Deze planners hebben beschikking over een optimale planning die gemaakt is aan de hand van de basisplanning. Zodra de wijzigingen aan de basisplanning bekend zijn, dient de planner de planning aan te passen. Er zijn in principe twee problemen waar Nedtrain tegenaan loopt. Het eerste is het probleem van de ontwikkeling van een algoritme dat planners kan ondersteunen in het maken van een 31

36 planning. Het tweede probleem is dat dit algoritme bruikbaar moet zijn voor mensen die niets van algoritmen af weten. Inmiddels is er een eerste versie van algoritme ontwikkeld, en zullen wij ons toespitsen op het tweede probleem. In de volgende paragraaf zal voor de volledigheid kort de werking van het algoritme worden besproken. 3.1 Algoritme Bij planningswerk is het maken van een basisplanning relatief eenvoudig. Eenmaal zo een basisplanning te hebben opgesteld kan deze vaak worden hergebruikt. Het wordt echter een stuk moeilijker deze planning aan te houden als je rekening moet gaan houden met onregelmatige werkzaamheden. In de basisplanning wordt opgenomen wanneer een trein binnen moet komen voor vast onderhoud en wanneer de trein gereed moet zijn. Bij treinen gebeurt het daarnaas ook nog eens dat ze op willekeurige tijdstippen kapot gaan, waardoor deze treinen vaak snel in onderhoud moeten. Dit zorgt ervoor dat het basisschema regelmatig helemaal veranderd moet worden. Ook vertraagde werkzaamheden kunnen natuurlijk voor een verstoring van het schema zorgen. Met andere woorden er is een hoge mate van onregelmatigheid. Om de planner te ondersteunen in het snel opstellen van nieuwe planningen is er een algoritme ontwikkeld. Dit algoritme is in staat om op een automatische manier, aan de hand van gegeven input, een nieuwe planning te genereren. 3.2 Grafische schil Het probleem waar wij ons op zullen richten is hoe je het algortme bruikbaar kan maken voor iemand die geen kennis over dit algoritme heeft. Een belangrijk onderdeel hiervan is dat je de mensen die al jaren ervaring hebben in plannen niet gaat vervangen maar ze ondersteunt. Om dit te bewerkstelligen is het belangrijk dat deze mensen inzicht krijgen in de werking van het algoritme. Dit is nodig omdat de planners hun keuzes moeten kunnen verantwoorden aan de productiechef; zeggen dat een planning goed is omdat het programma dit aangeeft zal dan niet voldoende zijn. Het programma moet dynamisch zijn, buiten zelf suggesties geven aan de planner moet het ook de suggesties van een planner kunnen verwerken in een nieuw schema. Bovendien kan in de loop van de tijd het algoritme vervangen worden door een beter werkend algoritme. Dit betekent dat de applicatie uiteindelijk modulair opgebouwd dient te worden. 4 Solver In dit hoofdstuk zal de huidige oplossing, die ontwikkeld is door Ronald Evers, worden besproken. Deze oplossing zal de basis worden voor dit project. Als eerste zullen we kort het ontwikkelde algoritme bespreken. Vervolgens komt de interface van het algoritme aan bod en zal dus de input en output van het algoritme worden besproken. Als laatste zal de grafische user interface aan bod komen die is ontwikkeld om de resultaten van het algoritme te visualiseren. 4.1 Algoritme De oplossing die voor het algoritme is gekozen bestaat uit het maken van een Simple Temporal Netwerk (STN)[2]. In een STN is het makkelijk de constraints tussen verschillende activiteiten aan te geven. Zo kan je bijvoorbeeld zeggen dat een trein eerst op een verhoogd spoor moet worden gezet voordat een activiteit aan de wielen van de trein kan beginnen. Al dit soort constraints worden dus opgenomen. In figuur 3 zie je bijvoorbeeld voor 1 trein het STN. In de figuur staat een begintijd z die vaak standaard 0 is. Er staat een due date (dd) die 10 uur na deze begintijd is, dit is de tijd waarop het onderhoud klaar moet zijn. En de trein heeft een release date (rd) 32

37 Figuur 3: STN van één trein[2] 1 uur na de begintijd, dit is het moment waarop de trein op de werkplaats binnen komt. Verder zijn er 2 activeiteiten waarbij activiteit 1 gelijk na aankomst kan beginnen, er staat namelijk een 0 als constraint. Deze 0 betekent dat de activiteit 0 uur na binnenkomst kan beginnen, zou hier -3 staan dan betekent het dat de activiteit 3 uur na binnenkomst kan beginnen. Deze activiteit heeft een duur heeft van 3 uur. In het STN zijn op dit moment alleen maar de constraints op de activiteiten opgenomen. Met behulp van het ESTA+ algoritme dat ontwikkeld is kunnen vervolgens resource constraints worden toegevoegd[2]. Er zijn andere algoritmen mogelijk maar ESTA+ lijkt het meest geschikt omdat dit de runtime binnen perken houdt. Het ESTA+ algoritme voegt voor een bepaald STN netwerk resource constraints toe om ervoor te zorgen dat de resources dus niet overgebruikt worden. Als er dus een conflict in het schedule wordt gevonden tussen resource, beschikbaarheid en de beschikbaarheid van materiaal wordt een extra constraint toegoevoegd om deze fout eruit te halen. Dit gebeurt net zolang totdat er geen constraints meer mogelijk zijn, in dit geval kan het algoritme wel of juist geen schema maken en stopt. Het algoritme produceert dus op basis van een STN en een resource map een nieuw verbetert STN waar vervolgens een schema uit kan worden afgeleid. Het algoritme geeft geen optimale oplossing omdat algoritmen die een optimale oplossing zoeken zoals het Integer Lineair Programming algoritme er veel te lang over doen om deze oplossing te vinden[2]. Er is daarom gekozen voor het heuristieke algoritme van ESTA+ dat een zo goed mogelijk lokaal optimum geeft, dus een optimum gegeven de constraints die het algoritme heeft. 4.2 Interface De interface van het algoritme bestaat uit twee delen, de input en de output. Beide delen zullen hieronder aan bod komen Input De input voor de solver bestaat uit een simpel tekstbestand. Elk tekstbestand bevat een enkele instantie en bestaat uit meerdere regels met statements. Een statement bestaat altijd uit een letter om aan te geven wat voor soort statement het is. De letter wordt gevolgd door een getal wat het id aangeeft. Afhankelijk van de eerste letter worden er nog meer waarden toegekend aan een statement. Hieronder staat het totale overzicht van alle soorten statement en de bijbehorende waarden. Resource: R <resource id> <capacity> "<name>" 33

38 Job: J <job id> <release date> <due date> "<name>" Activity: A <job id> <activity id> <duration> "<name>" Requirement: Q <job id> <activity id> <resource id> <required capacity> Precedence: P <job 1 id> <activity 1 id> <job 2 id> <activity 2 id> Job id s dienen aaneenvolgend te zijn, omdat het algoritme deze id s gebruikt om arrays door te lopen en mochten de id s niet aaneengesloten zijn dan kunnen hierdoor onverwachtte resultaten verschijnen Output De output van het algoritme ziet er als volgt uit. Instance solved total: parsing: stn: esta+: chaining: leveling constraints before chaining: 125 leveling constraints after chaining: 306 robustness: throughput: 759 Voor dit project is alleen de eerste regel bruikbaar, omdat hier wordt aangegeven of er wel of geen oplossing van de ingevoerde instantie is. Verder zullen er ook vaak extra precedence regels worden geven als output (voor de layout van precedence zie sectie 4.2.1). Door deze precedence regels is het uiteindelijk mogelijk om een planning te maken. 4.3 Grafische user interface Om de output van de solver te analyseren is er een simpele versie van een grafische user interface (gui) ontwikkeld. Deze gui is in staat om instanties via een tekstbestand in de solver te laden en de output van de solver grafisch weer te geven. Tevens is het mogelijk om verschillende solvers te kiezen indien deze aanwezig zijn. De grafische weergave van output bestaat uit een overzicht van de verschillende treinen (jobs) met daar weergegeven de verschillende activiteiten (activity) en de bezetting van de verschillende resources (putspoor, aardwind enzovoorts). Figuur 4 laat de bestaande gui zien. 5 C, C++ en Qt In dit hoofdstuk zal kort worden beschreven voor welke programmeertaal er is gekozen en welke ontwikkelomgeving (IDE) zal worden gebruikt. 5.1 C en C++ De applicatie wordt geschreven in C en C++. Deze twee talen liggen qua syntax zeer dicht bij elkaar, alleen verschillen ze nogal van elkaar in programmeerparadigma. C is een imperatieve programmeertaal terwijl C++ een object georiënteerde programmeertaal is. Er is voor deze programmeertalen gekozen omdat de uiteindelijke applicatie platform onafhankelijk dient te zijn. Tevens is er op het netwerk bij Nedtrain geen Java geïnstalleerd. Het laatste 34

39 Figuur 4: Grafische user interface van de solver argument voor de keuze voor C en C++ is dat het algoritme geschreven is in C en de gebruikersinterface in C++. Omdat in het curriculum de aandacht vooral is gericht op het programmeren in Java was het voor ons noodzakelijk om tijdens de oriëntatiefase van het bachelorproject ons te verdiepen in C en C++. Er is gekozen om gebruik te maken van het boek The C Programming Language [3]. 5.2 Qt Qt is een grafische toolkit geschreven in C++, die ontwikkeld is door Trolltech en uiteindelijk overgenomen is door Nokia. Qt voorziet ontwikkelaars van een groot aantal klassen die het implementeren van grafische interfaces vereenvoudigt. Naast de verschillende klassen van Qt is het ook mogelijk om een grafische interface te gebruiken om grafische interfaces te ontwikkelen. Hiervoor kan gebruik worden gemaakt van Qt s eigen IDE maar kan er ook gekozen worden voor een plugin voor de meest gebruikelijke IDE s (bijvoorbeeld Eclipse, Microsoft Visual Studio). Er is voor dit bachelorproject gekozen om gebruik te maken van Qt omdat het een makkelijk te gebruiken en goed gedocumenteerde toolkit is om een profesioneel ogende interface te ontwikkelen. Vanwege onze ervaring met Eclipse is er dan ook gekozen om te gaan werken met de Qt plugin voor Eclipse. Om de werking en gebruik van Qt te leren is er gekozen voor het boek C++ GUI Programming with Qt 4 [1]. 35

40 Figuur 5: Screenshot Eclipse met de Qt-plugin Referenties [1] Jasmin Blanchette and Mark Summerfield. C++ GUI Programming with Qt 4. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2nd edition, [2] R.P. Evers. Algorithms for scheduling of train maintenance. Master s thesis, Delft University of Technology, Electrical Engineering, Mathematics and Computer Science, [3] Brian W. Kernighan. The C Programming Language. Prentice Hall Professional Technical Reference, 2nd edition, [4] Nedtrain. Organisatie. Website, [5] NS. Organisatiestructuur ns. Website,

41 C Plan van Aanpak 37

42 Bachelorproject - Plan van Aanpak Edwin Bruurs ebruurs@gmail.com Cis van de Louw cisvdlouw@msn.com

43 Voorwoord In dit document zullen we een plan van aanpak uitschrijven. Hiermee maken we duidelijk wat precies onze opdracht is en hoe we deze opdracht willen gaan vervullen. Verder wordt vastgesteld wat de vereisten aan het product zijn en wat de verplichtingen van de opdrachtgever en projectleden zijn. Ook zal duidelijk worden gemaakt hoeveel tijd wij denken nodig te hebben voor elke fase van het project. 39

44 Samenvatting Het is de bedoeling dat er een grafische schil wordt gemaakt die op een overzichtelijke en transparante wijze suggesties kan weergeven aan een planner. Het is hierbij de bedoeling dat de schil makkelijk uit te breiden is en schema s makkelijk kan aanpassen. Het product moet goed werken en inzicht geven in het onderliggende algoritme om ervoor te zorgen dat de planner het product niet alleen kan gebruiken maar ook weet hoe het werkt en hoe de suggesties tot stand komen. Bij het ontwikkelen van het product gaan we ervan uit dat we elke week feedback krijgen van de opdrachtgever op het product zelf en over de wijze waarop wij te werk gaan. 40

45 Inhoudsopgave 1 Introductie 42 2 Projectopdracht Projectomgeving Doelstelling project Opdrachtformulering Op te leveren diensten Eisen en beperkingen Voorwaarden Aanpak en tijdsplanning Aanpak Fase 1: Oriëntatiefase Fase 2: Globale ontwerpfase Fase 3: Gedetailleerd ontwerp van functionaliteit Fase 4: Implementatie Fase 5: Testen Fase 6: Documentatie Tijdsplanning Projectinrichting Organisatie Rapportering Administratie Techniek en Software Kwaliteitsborging Proceskwaliteit Productkwaliteit

46 1 Introductie Nedtrain heeft in samenwerking met de Technische Universiteit Delft een algoritme ontwikkeld dat een schema kan maken voor het plannen van resources en personeel op een zo efficiënt mogelijke manier. Het is de bedoeling dat er een applicatie wordt ontwikkeld dat de planner van Nedtrain kan ondersteunen in het maken van planningen. Onze opdracht bestaat uit het ontwikkelen van een grafische interface zodat de planner het algoritme kan gebruiken om planningen te maken. Het is hierbij belangrijk dat het alleen maar om suggesties gaat en dat het inzicht in het algoritme met behulp van de grafische interface wordt vergroot. We zullen in dit document in hoofdstuk 2 duidelijk beschrijven wat het project precies inhoudt en wat de eisen aan het door ons te leveren product zijn. In hoofdstuk 3 zullen we vervolgens beschrijven welke fasen tijdens het project doorlopen worden en zullen we voor elke fase een tijdsbestek geven. In hoofdstuk 4 zal beschreven worden hoe de inrichting van het project is vastgelegd. Als laatste zal in hoofdstuk 5 nog beschreven worden hoe de projectleden gecontroleerd worden op hun werk en op welke manier de kwaliteit van het product zo hoog mogelijk wordt gehouden. 2 Projectopdracht In het volgende hoofdstuk wordt er een beknopte beschrijving van het project te realiseren project gegeven. Voor een uitgebreide beschrijving van dit project zie Opdrachtomschrijving [1]. 2.1 Projectomgeving Om reparaties aan treinen te plannen maakt Nedtrain gebruik van een planning. Elke periode (meestal één keer per week) wordt er een planning gemaakt door een planner. De planner heeft beschikking over een beperkt aantal verschillende soorten resources (putspoor, kuilwielbank, aardwind en automatische trein beïnvloeding) en personeel. De planner dient uiteindelijk een zo efficiënt mogelijke planning op te stellen zodat alle geplande treinen ook daadwerkelijk op tijd klaar zijn met het onderhoud. Nedtrain heeft in samenwerking met de Technische Universiteit Delft een algoritme ontwikkelt dat voorziet in het automatisch opstellen van een planning. Het ontwikkelde algoritme heeft als nadeel dat over de gegeven oplossing nooit met honderd procent zekerheid kan worden gezegd of de uiteindelijke oplossing ook daadwerkelijk de meest haalbare en beste oplossing is. Zie voor een complete analyse van het ontwikkelde algoritme Algorithms for scheduling of train maintenance van Ronald Evers [2]. Om het algoritme te gebruiken is er tevens door Ronald Evers een beperkte interface ontwikkeld. 2.2 Doelstelling project Nedtrain zou het algoritme graag willen gebruiken om een planner advies te geven over een door hem gemaakte planning en hem inzicht willen bieden in gegeven oplossingen van het algoritme. Hiervoor dient een nieuwe interface te worden ontwikkeld die deze mogelijkheden aan de planner biedt. Het is voor Nedtrain van belang dat de te ontwikkelen software wordt geaccepteerd door de huidige planners. 2.3 Opdrachtformulering De opdracht zal bestaan uit het ontwikkelen van een interface waarmee de planner advies kan worden geboden. Het is dus niet de bedoeling dat een definitief schema wordt gegeven maar alleen een advies. Dit advies kan vervolgens door de planner worden aangenomen of hij kan het advies aanpassen naar eigen inzicht. Verder dient de software inzicht te geven in het onderliggende algoritme zodat de planner goed onderbouwd aan productie kan uitleggen hoe hij tot het gekozen 42

47 schema is gekomen. Ook moet het dus via deze grafische interface duidelijk worden voor de planner hoe het algoritme precies werkt en hoe hij invloed kan uitoefenen op de output van het algoritme. Bovendien dient het advies van het algoritme zich aan te passen naar veranderende activiteiten, defecten in treinen zijn immers niet gepland maar moeten toch snel opgelost worden. 2.4 Op te leveren diensten Het eindresultaat zal bestaan uit een applicatie (grafische interface en het al bestaande algoritme) die geaccepteerd wordt door de planner en die makkelijk gebruikt kan worden door de planner. De applicatie dient niet als doel te hebben de planner uiteindelijk te vervangen maar wel te assisteren in het maken van een planning, volledige automatisering is niet het doel. 2.5 Eisen en beperkingen Het eindproduct dient ervoor te zorgen dat de resultaten uit het algoritme worden aangenomen door de planner. Dit houdt in dat de planner keuzes moet kunnen maken en inzicht moet krijgen in de suggesties van het algoritme. De applicatie moet makkelijk uitbreidbaar zijn met extra functionaliteit en algoritmen. De prioriteiten tijdens de ontwikkeling zullen liggen op het duidelijk maken van de werking van het algoritme en het helder weergeven van de verschillende suggesties die het programma levert. 2.6 Voorwaarden De opdrachtgever dient regelmatig feedback te geven op het ontwikkelde product, dit leidt ertoe dat het product voldoet aan de gestelde eisen. Van de projectleden wordt verwacht dat zij een werkend en netjes product afleveren. Van derden wordt er verwacht dat we uitleg krijgen over de scheduler en dat er een interface beschikbaar is waarmee we de scheduler kunnen aanroepen. 3 Aanpak en tijdsplanning In dit hoofdstuk zal besproken worden welke fases we tijdens het project zullen doorlopen en hoeveel tijd dat verwacht wordt aan elke fase kwijt te zijn. Tijdens elke fase zal er indien nodig terugkoppeling plaatsvinden naar voorgaande fasen. 3.1 Aanpak Fase 1: Oriëntatiefase Tijdens de oriëntatiefase worden de eisen van de opdrachtgever geformuleerd in de vorm van het Plan van aanpak en Opdrachtomschrijving. Naast het schrijven van dit document dient er ook gekeken te worden naar de werking van de ontwikkelomgeving (Eclipse met de Qt plugin) en de bijbehorende programmeertalen (C en C++). Verder verdiepen we ons in deze fase in de huidige status van het algoritme en de bijbehorende (gebruikers)interface, en zal er naar de globale werking van het algoritme worden gekeken Fase 2: Globale ontwerpfase Tijdens de tweede korte fase zal het systeem globaal ontworpen worden. Aan de hand van de verschillende functionaliteiten van de applicatie zullen usecases worden opgesteld. Een gedetailleerd ontwerp van de verschillende functionaliteiten volgt op een later tijdstip. Het is in de globale ontwerpfase de bedoeling om een globaal ontwerp te maken voor de hele applicatie met alle bijbehorende functionaliteit. Ook zal er regelmatig interactie plaatsvinden tussen de opdrachtgever en de projectleden. 43

48 3.1.3 Fase 3: Gedetailleerd ontwerp van functionaliteit In deze derde fase wordt er een gedetailleerd ontwerp van een functionaliteit gemaakt. Tijdens deze fase zal er veel interactie plaatsvinden tussen de opdrachtgever en de projectleden om ervoor te zorgen dat de uiteindelijke functionaliteit voldoet aan de gestelde eisen van de opdrachtgever Fase 4: Implementatie In de implementatiefase zal het uiteindelijk ontwerp uit de vorige fase worden vertaald naar broncode. Deze code wordt tijdens het implementeren zorgvuldig getest aan de hand van unittests. Aan het einde van deze fase is de functionaliteit die is ontworpen in de vorige fase geïmplementeerd en kan er worden begonnen aan het maken van het gedetailleerd ontwerp voor de volgende functionaliteit Fase 5: Testen De software wordt uiteindelijk uitgebreid getest door zowel de projectleden als door uiteindelijke planners en opdrachtgever. Deze testfase zal worden gebruikt om te kijken of het systeem niet alleen in zijn geheel aan de gestelde eisen voldoet maar ook dat het werkt zoals bedoeld op verschillende platformen. Er zal dus in deze fase vooral worden getest op correcte integratie Fase 6: Documentatie Voor zover mogelijk wordt elke fase afgesloten met een document. Deze laatste fase bestaat uit het afronden van alle verslagen en het eindverslag. 3.2 Tijdsplanning Er is besloten om aan het begin van het project een globale planning te maken waarin alle bovenstaande fasen staan vermeld. Aan het begin van elke fase wordt de exacte planning voor de fase gemaakt. Fase 3 en 4 zullen elkaar afwisselen zolang er nog openstaande functionaliteiten zijn. We ontwerpen eerst gedetailleerd een functionaliteit en gaan deze vervolgens implementeren. Figuur 1 geeft de globale planning weer en figuur 2 geeft de planning voor de oriëntatiefase weer. Figuur 1: Globale planning bachelorproject Figuur 2: Planning oriëntatiefase 44

49 4 Projectinrichting In het volgende hoofdstuk zal dieper worden ingegaan op de inrichting van het project. Er zal worden besproken hoe de begeleiding is georganiseerd, welke afspraken er tussen de projectleden zijn gemaakt en welke software voor het ontwikkelen van de applicatie wordt gebruikt. 4.1 Organisatie De begeleiding van het bachelorproject wordt verzorgd door: Ir. B.R. Sodoyer, Coördinator bachelorproject vanuit de Technische Universiteit Delft; Prof.dr. C. Witteveen, Begeleider vanuit de Technische Universiteit Delft; B. Huisman, Opdrachtgever vanuit Nedtrain. Tijdens het bachelorproject zal er op wekelijkse basis een overleg plaatsvinden met B. Huisman. Afspraken met C. Witteveen en B.R. Sodoyer worden enkel gemaakt indien dit gewenst is. 4.2 Rapportering De rapportage van het project zal bestaan uit een aantal zestal documenten: Opdrachtomschrijving Oriëntatieverslag Plan van Aanpak Requirements en Analyse document (RAD) Technische documentatie Eindverslag Bovenstaande documenten worden geschreven in LaTeX en aangeleverd als pdf-bestanden. 4.3 Administratie Alle documentatie en broncode zullen worden geplaatst op een SVN-server (versiebeheer) van de Technische Universiteit Delft. Alle commits zullen verder worden voorzien van duidelijke commentaar. 4.4 Techniek en Software Tijdens het project zal gebruik worden gemaakt van eigen laptops met als besturingssysteem Ubuntu en Windows. De te ontwikkelen applicatie zal worden geschreven met behulp van de IDE Eclipse en de Qt-plugin. 5 Kwaliteitsborging In dit hoofdstuk wordt duidelijk gemaakt op welke manier opdrachtgever en projectleden invloed kunnen uitoefenen op de kwaliteit van het product en de samenwerking tussen de groepsleden. 5.1 Proceskwaliteit Om de kwaliteit van het eindproduct te waarborgen zijn er op wekelijke basis korte bijeenkomsten gepland waarbij de voortgang wordt besproken. Alle aanpassingen kunnen worden teruggedraaid door gebruik te maken van SVN waardoor everntuele fouten kunnen worden teruggedraaid. 45

50 5.2 Productkwaliteit De kwaliteit van het product wordt onderverdeeld in de volgende zes categorieën Functionaliteit: De werking van het programma moet transparant zijn, zodat het voor de uiteindelijke gebruiker duidelijk is hoe het algoritme werkt en met behulp van de resultaten onderbouwde keuzes kan maken. Verder dient het programma robuust te zijn en van niet oplosbare problemen duidelijk aan te geven wat de oorzaak is. Betrouwbaarheid: Het systeem moet betrouwbaar zijn, de planner dient verantwoorde keuzes te kunnen maken aan de hand van de visuele resultaten. Onderhoudbaarheid: De code dient goed gedocumenteerd te worden zodat eventuele nieuwe functionaliteiten door derden toegevoegd kunnen worden. Efficiëntie: Voor het berekenen van aanpassingen mag enige tijd verstrijken, afhankelijk van het algoritme. Bruikbaarheid: Het systeem dient makkelijk en intuïtief te gebruiken zijn. Portabiliteit: Het systeem dient te werken op een willekeurige stand-alone pc, ongeacht OS en hardwareconfiguratie (32 of 64-bit). Eventueel met andere compiler een executable maken is geen probleem. Referenties [1] C. van de Louw E.J.A.M. Bruurs. Bachelorporject - opdrachtomschrijving, [2] R.P. Evers. Algorithms for scheduling of train maintenance. Master s thesis, Delft University of Technology, Electrical Engineering, Mathematics and Computer Science,

51 D Requerements and Analysis Document 47

52 Bachelorproject - Requirement and Analysis Document Edwin Bruurs ebruurs@gmail.com Cis van de Louw cisvdlouw@msn.com

53 Voorwoord Om tot een goed werkende applicatie te komen dient er een goed ontwerp gemaakt te worden. Tijdens de verschillende ontwerpfasen is dit document geschreven. Het Requirements Analysis Document (RAD) is geschreven aan de hand van verschillende gesprekken met de opdrachtgever. Naast deze gesprekken zijn er ook veel momenten geweest waarop er door de opdrachtgever feedback is gegeven op het geleverde ontwerp. Via deze weg willen we daarom ook onze opdrachtgever, Bob Huisman, bedanken voor de duidelijke feedback. Met behulp van dit document proberen wij de lezer duidelijk te maken hoe onze applicatie is ontwikkeld. Hierin worden de verschillende eisen en randvoorwaarden besproken en aan de hand hiervan worden er verschillende functionaliteiten beschreven. Vervolgens gaan we deze functionaliteiten ontwikkelen om zo tot het uiteindelijke product te komen. 49

54 Samenvatting In dit document zal het ontwerpproces van de applicatie worden beschreven. De applicatie zal ontwikkeld worden per functionaliteit. Om deze reden worden er een aantal verschillende functionaliteiten gedefinieerd. Als eerste functionaliteit die ontwikkeld gaat worden is gekozen om een goede basis te implementeren. Deze basis bestaat uit een heldere opslag van gegevens. Deze gegevens zullen worden opgeslagen in een MySQL database. Naast het ontwerpen en inrichten van de database wordt er in deze fase ook al een eerste opzet gemaakt om te kunnen communiceren met de database. De tweede functionaliteit bestaat uit een grafische omgeving om verschillende planningen toe te kunnen voegen aan de database. Functionaliteit drie bestaat uit het ontwerpen van een model om zo de werkelijkheid beter te representeren. Er is hierbij gekozen om gebruik te maken van een aantal klassen die verschillende objecten weergeven. Voorbeelden hiervan zijn planning, job, activity en resource. De bedoeling van deze klassen is om de te schrijven code overzichtelijk te houden en om veel dubbele code te voorkomen. Hierbij moet worden vermeld dat het ontwerpen van een model eigenlijk in een eerdere fase had moeten plaatsvinden, maar dat we dit over het hoofd hadden gezien. De volgende functionaliteit is het weergeven van een planning en de resultaten van het algoritme. Hiertoe is een interface ontwikkeld die makkelijk in gebruik is. Als uitgangspunt hebben we de interface van Ronald Evers gekozen, maar hebben deze van de grond af aan opnieuw opgebouwd. Als voorlaatste functionaliteit zijn er een aantal mogelijkheden ontwikkeld om de database verder aan te kunnen vullen. Naast het toevoegen van planning gerelateerde zaken is ook de mogelijkheid ontwikkeld om resources, standaard onderhoudsbeurten en standaard activiteiten toe te kunnen voegen. Naast het toevoegen van deze gegevens is het ook mogelijk om bestaande gegevens te wijzigen of te verwijderen. Als laatste is er een functionaliteit ontwikkeld om de voortgang van activiteiten bij te houden. Deze wijzigingen worden uiteindelijk ook meegenomen naar het algoritme, omdat het de bedoeling is dat het algoritme geen wijzigingen meer aanbrengt aan activiteiten die klaar zijn. 50

55 Inhoudsopgave 1 Introductie 53 2 Globaal ontwerp Requirements Overzichtelijke gebruikersinterface Database Planning maken of verwijderen Planning grafisch weergeven Voortgang van een planning bijhouden Dataopslag Planningen wijzigen Planningen vergelijken Geen oplossing Solver Werking solver Extra functionaliteiten Randvoorwaarden Advies Looptijd Knelpunten Volgorde Functionaliteiten Gebruikersinterface Database Planning maken en verwijderen Planning grafische weergave Grafische weergaven resultaten solver Dataopslag Voortgang bijhouden Vergelijken planningen Solvers toevoegen en verwijderen Inzicht in de solver geven Wizard Diagrammen Usecasediagram Klassendiagram Database Requirements Formaat Databaseontwerp Klassendiagram Planning maken en verwijderen Requirements Gebruiksvriendelijkheid Randvoorwaarden Wijzigen planning Usecases klassendiagram Interfaceontwerp

56 5 Model Requirements Overzichtelijk Vervanging Databaseontwerp Klassendiagram Grafische weergaven resultaten solver Requirements Gebruiksvriendelijkheid Vervangbaarheid Aanpasbaar Randvoorwaarden Runtime Usecases Klassendiagram Interfaceontwerp Aanpassingen Database Requirements Gebruiksvriendelijkheid Opties Meerdere toevoegen Usecases Klassendiagram Interfaceontwerp Voortgang bijhouden Requirements Overzichtelijkheid Usecases Klassendiagram Interfaceontwerp

57 1 Introductie Dit document zal bestaan uit een globaal ontwerp van de uiteindelijke applicatie en een gedetailleerd ontwerp van de verschillende functionaliteiten. Er is voor deze aanpak gekozen omdat de opdrachtgever de applicatie graag functionaliteit voor functionaliteit ontwikkeld ziet worden. De eisen die de opdrachtgever heeft gesteld aan de gehele applicatie zijn opgenomen in hoofdstuk 2, het globaal ontwerp. Naast de eisen zijn ook de verschillende functionaliteiten die mogelijk geïmplementeerd worden opgenomen in dit hoofdstuk. Ten derde bevat dit hoofdstuk nog een sectie met de verschillende randvoorwaarden. In sectie 2.4 worden er een aantal diagrammen toegevoegd om het globaal ontwerp visueel te ondersteunen. Vervolgens worden in hoofdstuk 3 tot en met hoofdstuk 8 achtereenvolgens de database, planning maken en verwijderen, het model, grafische weergaven van de solver, aanpassingen database en voortgang bijhouden besproken. In elk hoofdstuk zal voor zover mogelijk bestaan uit de volgende secties; requirements, randvoorwaarden, databaseontwerp, usecases, klassendiagram en interfaceontwerp. 2 Globaal ontwerp In dit hoofdstuk zal het globaal ontwerp worden besproken. Het globaal ontwerp zal voornamelijk bestaan uit een ruim opgestelde beschrijving van de uiteindelijke applicatie. In dit hoofdstuk zullen achtereenvolgens aan bod komen, de eisen die zijn opgesteld aan de applicatie, de randvoorwaarden, functionaliteiten en een aantal uml-diagrammen om het ontwerp te visualiseren. 2.1 Requirements Tijdens de analysefase zijn er een aantal eisen naar voor gekomen waaron de applicatie moet voldoen. Deze eisen zijn grotendeels op te delen in een overzichtlijke gebruikersinterface en anderzijds een heldere dataopslag. Naast deze eisen is het voor de opdrachtgever van belang dat de applicatie geaccepteerd wordt door de eindgebruiker. Hierdoor moeten we er in het hele systeem bewust van zijn dat de applicatie geen black box dient te worden voor de gebruiker, maar dat de applicatie zoveel mogelijk inzicht geeft aan de gebruiker Overzichtelijke gebruikersinterface De hele applicatie dient eenvoudig in gebruik te zijn en te beschikken over een duidelijke en heldere gebruikersinterface. Zonder al te veel instructies dient een planner met de applicatie te kunnen werken. Omslachtige handelingen moeten worden vermeden en functies dienen uitgevoerd te worden in een zo weinig mogelijk aantal handelingen Database Alle ingevoerde gegevens dienen opgeslagen te worden zodat deze op een later tijdstip opnieuw gebruikt kunnen worden. Gegevens moeten ook gewijzigd en verwijderd kunnen worden. De voorkeur gaat hierbij uit naar opslag in de vorm van een database, zodat het eventueel mogelijk is om andere applicaties toegang te geven tot de opgeslagen gegevens. Een ander voordeel is dat andere applicaties gegevens in de database kunnen wegschrijven. Een voorbeeld hiervan is dat de personeelsplanning vanuit de personeelsadministratie rechtstreeks het beschikbare aantal personeel kan aanpassen in de database. Zodat onze applicatie uiteindelijk met de nieuwe gegevens kan werken. De opslag van data is een systeemfunctionaliteit en geen gebruikersfunctionaliteit. De eindgebruiker krijgt dus niet direct te maken met de opslag van de data maar kan data opslaan door verschillende functionaliteiten aan te roepen vanuit de applicatie. 53

58 2.1.3 Planning maken of verwijderen Een gebruiker dient met de applicatie een planning te kunnen samenstellen. De planning dient uiteindelijk opgeslagen te worden in de database zoals is besproken in sectie Naast het kunnen maken van een planning moet de gebruiker ook de mogelijkheid hebben om gemaakte planningen te verwijderen Planning grafisch weergeven Voor een planner is het uiteindelijk van belang om een planning visueel zichtbaar te hebben. Aan de hand van een visuele representatie kan de planner beslissingen maken. Er dient dus een grafische interface gemaakt te worden waarmee het voor de planner gemakkelijk is om een planning visueel te maken. Als uitgangspunt zal de applicatie Ontrack gebruikt worden 1. Naast het visueel weergeven van een planning is het noodzakelijk om de gevolgen van het verschuiven van activiteiten zichtbaar te maken Voortgang van een planning bijhouden Als een planning wordt uitgevoerd gebeurt het regelmatig dat er wijzigingen zijn doorgevoerd. Bijvoorbeeld wanneer het onderhoud aan een trein langer of juist korter duurt als gepland. Als zo een situatie zich voordoet is het wenselijk dat de planner de mogelijkheid heeft om wijzigingen in de planning aan te brengen en vervolgens de solver een nieuwe planning te laten genereren Dataopslag Omdat tijdens het ontwikkelen van de applicatie maar met een kleine set data wordt gewerkt, is het voor de planner noodzakelijk om meer gegevens aan de database toe te kunnen voegen. Een voorbeeld van data die toegevoegd, gewijzigd of verwijderd zou kunnen worden is een nieuwe resources en de maximale beschikbare capaciteit van deze resource Planningen wijzigen Ingevoerde planningen dienen gewijzigd te kunnen worden. De planner dient op een makkelijke manier bestaande planningen te wijzigen en weer op te slaan. Onder het wijzigen van een planning hoort het toevoegen, wijzigen of verwijderen van jobs en activiteiten Planningen vergelijken De gebruiker dient een mogelijkheid te hebben om verschillende planningen met elkaar te kunnen vergelijken. Door meerdere planningen met elkaar te kunnen vergelijken is de gebruiker in staat om de meest optimale oplossing te kiezen en zijn gemaakt keuze te onderbouwen Geen oplossing Indien de solver geen oplossing kan vinden van een probleeminstantie, dient dit op een heldere manier duidelijk te worden gemaakt aan de planner. De planner dient deze instantie kunnen vergelijken met een instantie die wel op te lossen is. De niet oplosbare instantie moet dan voor zover mogelijk gevisualiseerd worden Solver Het moet mogelijk zijn om verschillende solvers te gebruiken. Er moet dus de mogelijkheid zijn om op een makkelijke manier van solver te wisselen. Er dient uiteindelijk een menu te ontstaan met daarin verschillende mogelijke solvers. Omdat de solvers uitvoerbare bestanden zijn is het niet 1 Ontrack is ontwikkeld door Ronald Evers ter demonstratie van zijn ontwikkeld algoritme[1] 54

59 mogelijk om zelf de solver aan te passen. Naast het toevoegen van solvers moet het ook mogelijk zijn om solvers te verwijderen Werking solver Om de applicatie te kunnen gebruiken als leermiddel dient er een mogelijkheid te bestaan om inzicht te geven in de werking van het algoritme. Hiertoe dienen de resultaten van de solver stapsgewijs doorlopen te kunnen worden Extra functionaliteiten Niet alle functionaliteiten zullen in de eerste versie van de applicatie worden geïmplementeerd. Hierdoor is het noodzakelijk dat het mogelijk is om op een makkelijke manier nieuwe functionaliteiten toe te voegen. 2.2 Randvoorwaarden Hieronder zullen de randvoorwaarden aan de uiteindelijke applicatie worden beschreven. Deze randvoorwaarden zijn opgesteld aan de hand van verschillende vraaggesprekken met de opdrachtgever en met Ronald Evers Advies Het algoritme geeft telkens maar één optimale oplossing per instantie terug. Als er een instantie van een probleem aan het algoritme wordt gegeven, en het algoritme gaat hiermee aan de slag, dan krijgen we van het algoritme een oplossing. Een oplossing is een nieuwe instantie waar door middel van voorwaarden een planning uit is ontstaan. Het kan dus gebeuren dat er meerdere optimale oplossingen zijn, echter van het algoritme krijgen we telkens dezelfde oplossing terug. Het is daarom niet mogelijk om de planner een keuze te kunnen geven tussen meerdere oplossingen. Als oplossing moet de planner dus een voorstel geven voor verbetering, bijvoorbeeld het aantal personeel met vijf man te verminderen voor een bepaalde week. Door vervolgens het algoritme opnieuw te laten lopen ontstaat dan een nieuwe planning die vergeleken kan worden met een andere planning Looptijd Omdat de looptijd van het algoritme afhangt van de grootte van een instantie (de complexiteit van het algoritme is O(n 3 )), kunnen we weinig invloed uitoefenen op de snelheid waarmee oplossingen worden bepaald en kan het dus gebeuren dat de gebruiker even moet wachten voordat er een oplossing op het scherm verschijnt Knelpunten Omdat het algoritme stopt op het moment dat het heeft bepaald dat een instantie niet oplosbaar is, kan uit de laatste constraint niet worden afgeleid wat het knelpunt is. Het algoritme geeft geen inzicht in zijn laatste handeling als deze niet leidt tot een oplossing. Hierdoor zal de eis besproken in sectie hoogstwaarschijnlijk op dit moment niet geïmplementeerd kunnen worden Volgorde Het algoritme maakt geen gebruik van starttijden hierdoor is het niet mogelijk om de exacte starttijden van verschillende activiteiten te definiëren. De planner is alleen in staat om een volgorde aan activiteiten toe te kennen. 55

60 2.3 Functionaliteiten In deze sectie worden de verschillende functionaliteiten van de applicatie besproken. Deze functionaliteiten zijn opgesteld aan de hand van de eisen (zie sectie 2.1) van de opdrachtgever en de randvoorwaarden (zie sectie 2.2) aan omgevingsfactoren. In dit hoofdstuk zullen we ons gehele systeem opdelen in losse functionaliteiten. We zullen eerst de meest balangrijke functionaliteiten noemen en kort uitleggen wat elk functionaliteit moet gaan doen. Voor de implementatie gaan we ook deze volgorde aanhouden Gebruikersinterface Er dient ten eerste een gebruikersinterface te worden ontwikkeld waar alle verschillende functionaliteit in ondergebracht kunnen worden. Er moet op een makkelijke manier nieuwe functionaliteit toegevoegd kunnen worden, zodat dat het systeem makkelijk uit te breiden is Database Deze systeemfunctionaliteit zorgt ervoor dat het mogelijk wordt op verschillende gegevens op te slaan in een database. Naast het opslaan van de gegevens in de database moeten deze ook gewijzigd en verwijderd kunnen worden Planning maken en verwijderen De tweede functionaliteit zal bestaan uit een editor om een planning toe te voegen aan de database. De gebruiker kan met behulp van deze editor makkelijk planningen aanmaken. Tevens kan hier ook het aantal beschikbare resources op een makkelijke manier worden aangepast. Naast het toevoegen van planningen aan de database, dient er ook de mogelijkheid te worden gemaakt om reeds gemaakte planningen te verwijderen Planning grafische weergave Het is voor een planner van groot belang om een planning te kunnen bekijken. Het makkelijkste gaat dit door een planning grafisch weer te geven. De planner moet in staat zijn om de verschillende activiteiten te kunnen verplaatsen, om zo de planning naar eigen inzicht aan te kunnen passen. Als de gebruiker een activiteit verplaatst dient hij ook meteen de gevolgen hiervan te zien. Resources moeten dus meteen worden geüpdate Grafische weergaven resultaten solver Na aanpassingen aan de planning dient de planner de solver aan te kunnen roepen om te kijken welk advies de solver geeft. De resultaten dienen grafisch te worden weergegeven op het scherm Dataopslag Om gegevens aan de database te kunnen toevoegen die niet in een planning staan, dienen hiervoor aparte functionaliteiten gemaakt te worden. Deze functionaliteit is onder te verdelen in het toevoegen en wijzigen van resources Voortgang bijhouden De planner dient de mogelijkheid te hebben om activiteiten te markeren als voltooid. Deze activiteiten worden door de solver niet meer mee genomen bij het opnieuw uitvoeren van de solver. Het is hierdoor voor de planner dus mogelijk om de gevolgen van wijzigingen in een lopend schema te bekijken. 56

61 2.3.8 Vergelijken planningen Een andere functionaliteit van de applicatie is het vergelijken van planningen. Een planner moet inzicht kunnen krijgen in het verschil tussen twee instanties om zo de meest geschikte oplossing te kiezen Solvers toevoegen en verwijderen Er dient een mogelijkheid te bestaan om desgewenst nieuwe solvers aan de applicatie te kunnen voegen. Mocht het nu zo zijn dat er een betere solver wordt ontwikkeld voor het probleem, dan kan de nieuwe solver gemakkelijk worden ingeladen en laten draaien in de te ontwikkelen applicatie. Naast het toevoegen van een nieuwe solver dient het ook mogelijk te zijn om een solver te verwijderen. Indien bijvoorbeeld een solver achterhaald is moet deze uit de applicatie verwijderd kunnen worden Inzicht in de solver geven Naast het hulp bieden aan een planner dient de applicatie ook geschikt te zijn om extra inzichten te geven in de werking van de solver. De applicatie dient gebruikt te kunnen worden als leermiddel. Hiervoor dient de applicatie de mogelijkheid te bieden om de solver stapsgewijs uit te kunnen voeren. De solver zal uiteindelijk niet stapsgewijs worden uitgevoerd, maar de visualisatie van de oplossing wordt stap voor stap uitgevoerd Wizard De wizard wordt een aparte functie in de applicatie die los staat van de main interface. Een gebruiker moet de keuze hebben om deze wel of niet te gebruiken. De wizard moet bestaande projecten kunnen openen en moet nieuwe projecten kunnen aanmaken. Bij nieuwe projecten moet na een aantal handelingen een instantie in de solver worden ingeladen. De wizard is dus feitelijk niets anders als een grafisch hulpmiddel voor een planner om veel verschillende losstaande stappen in één keer uit te voeren. 2.4 Diagrammen Deze sectie zal het globaal ontwerp visualiseren met behulp van verschillende diagrammen. De exacte functionaliteiten zijn nog niet ingevuld omdat die pas in een later stadium worden ontwikkeld. Zie voor het exacte ontwerp van de verschillende functionaliteiten hoofdstuk 3 en volgende Usecasediagram In figuur 1 is het usecasediagram weergegeven van de applicatie. De gebruiker start de applicatie en kan vervolgens een functionaliteit gebruiken om zo te werken met de applicatie Klassendiagram In figuur 2 is een eerste ontwerp van de uiteindelijke applicatie te zien. De basis van de applicatie bestaat uit de klassen main en MainWindow. De klasse main bevat alleen de functie main() welke nodig is om het geheel aan te roepen. Vanuit de functie main zal de klasse MainWindow worden aangeroepen. MainWindow zorgt er op zijn beurt voor dat er een basisinterface wordt getoont waarin later verschillende functionaliteiten aan toegevoegd kunnen worden. Al deze functionaliteiten zullen bereikbaar zijn vanuit de menubalk. Naast het aanmaken van de basisinterface zorgt de klasse mainwindow ook voor het aanroepen van de verschillende functionaliteiten. 57

62 Figuur 1: Usecase diagram van het te ontwikkelen systeem Figuur 2: Klassediagram van het te ontwikkelen systeem 3 Database Omdat de uiteindelijke applicatie moet beschikken over de mogelijkheid om planningen te vergelijken, dienen gemaakte planningen opgeslagen te worden. Het algoritme maakt gebruik van invoer door middel van tekstbestanden. Er dient per instantie één tekstbestand aangemaakt te worden. Als er een groot aantal planningen opgeslagen dienen te worden, groeit ook het aantal tekstbestanden. Er is daarom gekozen om gebruik te maken van een database om daar de verschillende instanties in op te slaan, zodat uiteindelijk het gebruik van een tekstbestand door de solver niet meer nodig is. Dit hoofdstuk zal het ontwerp van de database en bijbehorende klassen beschrijven. In de eerste sectie zullen de requirements van de database worden besproken, vervolgens in sectie twee wordt het ontwerp van de database toegelicht. Sectie drie zal dieper ingaan op het ontwerp van de verschillende klassen die nodig zijn om de database aan te spreken. Omdat deze functionaliteit voornamelijk een systeemfunctionaliteit is en geen gebruikersfunctionaliteit worden usecases achterwegen gelaten. 3.1 Requirements Formaat De informatie wordt opgeslagen in een MySQL database zodat op een eenvoudige wijze nieuwe informatie kan worden toegevoegd en bestaande informatie kan worden verwijderd. Er is gekozen voor een MySQL database omdat deze database een opensource database is en omdat we hier de meeste ervaring mee hebben opgedaan tijdens onze bachelorfase. Tevens is er voor MySQL een handige grafische interface genaamd phpmyadmin 3.2 Databaseontwerp Het ontwerp van de database is te zien in figuur 3. Er is gekozen voor vijf tabellen; planning, job, activity, constraint en resource. planning Deze tabel bevat de informatie van de verschillende planningen (weekschema s). Er wordt bijgehouden wat de start- en einddatum is van een planning. Tevens krijgt elke planning ook een naam om zo de verschillende planningen van elkaar te kunnen onderscheiden. job De tabel job bevat alle informatie over de uit te voeren jobs. Het gaat bij een job om de informatie over de treinen. De naam van een job zal veelal het nummer van een trein zijn. De start- en einddatum zijn de data wanneer een trein binnenkomt en klaar moet zijn met onderhoud. Verder wordt ook bijgehouden bij welke planning de records horen. activity In activity staan alle activiteiten van alle jobs beschreven. Elke activity wordt gekenmerkt door een naam en uniek id. Verder wordt bijgehouden hoeveel resources er worden gebruikt door een activity en hoelang een activity duurt (in hele uren). 58

63 Figuur 3: Databaseontwerp Figuur 4: Klassendiagram voor het opslaan van data in de database In de tabel constraint wordt bijgehouden wat de volgorde van verschillende activi- constraint teiten zijn. resource De tabel resource bevat voor elke resource de maximale beschikbare capaciteit. 3.3 Klassendiagram In figuur 4 staat het aangepaste klassendiagram voor de opslag van data uitgewerkt. Naast de klassen main.cpp, mainwindow.cpp en functionality zijn er de klassen databaseconnector.cpp en queryexecuter.cpp bij gekomen. De klasse functionality is in dit ontwerp niets anders als een invulling voor latere implementaties. De klassen databaseconnector.cpp en queryexecuter.cpp voorzien in de volgende functionaliteiten: databaseconnector.cpp De databaseconnector zorgt ervoor dat er een verbinding tot stand kan worden gebracht met de database. Naast het leggen van een verbinding zorgt deze klasse ook voor het verbreken van de verbinding. queryexecuter.cpp Op het moment dat een instantie van de queryexecuter wordt geïnstantieerd dient er een query te worden opgegeven (zo wordt voorkomen dat er een lege query wordt uitgevoerd). Met behulp van set- en getquery kunnen er nieuwe queries in het object worden geladen. De ingeladen query wordt uiteindelijk uitgevoerd door executequery() aan te roepen. 59

64 Figuur 5: Usecase diagram voor het toevoegen en verwijderen van een planning 4 Planning maken en verwijderen Nu de database is opgezet is het nodig om ervoor te zorgen dat het op een handige manier mogelijk is om gegevens in te voeren in de database. Dit dient te gebeuren via een grafische interface. Aangezien het belangrijker is om een planning te visualiseren dan om gegevens in de database te kunnen invoeren is ervoor gekozen om deze functionaliteit te beperken tot het invoeren en het verwijderen van een planning. In dit hoofdstuk zullen de eisen, randvoorwaarden, klassendiagrammen en de use cases voor het toevoegen en verwijderen van planningen worden beschreven. 4.1 Requirements Gebruiksvriendelijkheid De enige eis die gesteld is aan deze functionaliteit is dat het gemakkelijk moet zijn om een planning toe te voegen of te verwijderen. Dit houdt in dat de werking van deze functionaliteit logisch moet overkomen en zo dicht mogelijk bij de huidige werkwijze van een planner moet aansluiten. 4.2 Randvoorwaarden Wijzigen planning De functionaliteit voorziet alleen in het toevoegen en verwijderen van een planning. Het is via deze functionaliteit niet mogelijk om een enkele job of activiteit toe te voegen, wijzigen of te verwijderen. Het toevoegen, wijzigen of verwijderen hiervan dient te gebeuren via een later te ontwikkelen functionaliteit om planningen te wijzigen. 4.3 Usecases In figuur 5 zie je een usecase diagram van alle acties die een gebruiker in deze functionaliteit kan gebruiken. Hierna volgt kort de omschrijving per use case. Planning toevoegen De gebruiker kan een planning toevoegen door eerst in de bestandsbalk te kiezen voor Planning en vervolgens voor Voeg planning toe. Er zal vervolgens een scherm openen waarbij de user als eerste de naam, start- en einddatum van de planning moet invoeren. Door vervolgens op Volgende te klikken verschijnt het volgende scherm. In dit scherm moet de gebruiker de verschillende treinen invoeren. Hiertoe dienen de gegevens startdatum, einddatum en treinnaam ingevoerd te worden. Er bestaat de mogelijkheid om een willekeurig aantal treinen aan een planning toe te voegen door gebruik te maken van de knop Voeg rij toe. In het laatste scherm worden de verschillende activiteiten getoond en kan er een selectie uit deze activiteiten gemaakt worden. 60

65 Figuur 6: Klassendiagram voor het toevoegen en verwijderen van een planning Planning verwijderen De gebruiker kan een planning verwijderen door in de bestandsbalk onder Planning te kiezen voor Verwijder planning. Er wordt vervolgens een scherm getoont waarin de user een overzicht krijgt van alle gemaakte planningen. Door vervolgens de juiste planning te selecteren en op de knop Verwijder te klikken wordt de geselecteerde planning in zijn geheel verwijderd (inclusief alle jobs, activiteiten en constraints). Om tot het uiteindelijke verwijderen te komen dient de gebruiker de actie nog definitief te bevestigen. 4.4 klassendiagram In figuur 6 is het klassendiagram te zien voor het toevoegen en verwijderen van een planning. Controller Zowel voor het toevoegen als het verwijderen van een planning is er een controller. Deze controller heeft als taak het verloop van de functionaliteit te coördineren. Zo dient de controller de juiste schermen weer te geven, alle ingevoerde gegevens te verwerken en eventuele logica op de ingevoerde gegevens uit te voeren. De AddPlanningController heeft als doel om het toevoegen van een planning mogelijk te maken en de RemovePlanningController neemt het verwijderen van planningen op zich. Gebruikersinterface Naast de controllers bestaan deze klassen uit een aantal gebruikersinterfaces. Elke interface is een apart scherm dat getoont kan worden. Een interface bestaat uit een aantal get- en setmethoden die ervoor zorgen dat de juiste informatie wordt geschreven naar of uitgelezen uit de interface. Naast de public get- en setmethoden bevatten de interfaces een aantal private functies die de interface opbouwen. Deze worden vanuit de constructor al aangeroepen om 61

66 (a) Planning toevoegen 1 (b) Planning toevoegen 2 (c) Planning toevoegen 3 (d) Planning verwijderen Figuur 7: Grafische ontwerp om een planning toe te voegen (a, b, c) of te verwijderen (d) het construeren van een interface te vermakkelijken. 4.5 Interfaceontwerp Voor het toevoegen van een planning zal de grafisch interface bestaan uit drie opeenvolgende schermen. Het eerste scherm (figuur 7a) is nodig om een planning toe te voegen. Om jobs toe te voegen word gebruik gemaakt van het tweede scherm, figuur 7b. Als laatste worden de verschillende activiteiten toegevoegd aan een job, figuur 7c. Het verwijderen van een planning gebeurt met behulp van het scherm uit figuur 7d. Al deze functionaliteiten zijn te bereiken vanuit de menubalk. Planning toevoegen 1 Dit scherm bestaat uit drie invoervelden. In het eerste veld dient een naam voor een planning gegeven te worden. De naam is een verplicht veld omdat een gebruiker meerdere planningen met dezelfde start- en einddatum kan aanmaken. Met dit naamveld is de gebruiker in staat om onderscheid aan te brengen tussen verschillende planningen. De naam van een planning in combinatie met zijn start- en einddatum moet dus uniek zijn. Verder mag de naam van een planning ook niet leeg zijn, dit om te voorkomen dat er op een later tijdstip onduidelijk is over welke planning het nu gaat. Mocht de gebruiker toch een combinatie invullen die niet uniek is of waarvan de naam van de planning leeg is krijgt hij hier een melding van. Vervolgens kan de gebruiker op Volgende klikken om naar het tweede scherm te gaan of Annuleren om te stoppen met het invoeren van eeen planning. Alle ingevoerde resultaten worden in het tweede geval niet opgeslagen. Planning toevoegen 2 Bij dit scherm kan de gebruiker verschillende jobs toevoegen aan een planning. Het scherm begint met een enkele rij, maar door op de knop Add row te klikken kan de gebruiker een oneindig aantal rijen toevoegen. Naast een naam voor de job dient ook de start- en 62

67 eindtijd te worden meegegeven aan een job. Zowel de start- als eindtijd dient tussen de opgegeven start- en eindtijd van een planning te liggen. Planning toevoegen 3 In het laatste scherm dient de gebruiker verschillende activiteiten aan jobs toe te kennen. De gebruiker kan in dit scherm links de gewenste job opvragen en in het rechter gedeelte activiteiten voor deze job aanpassen. Dit kan hij doen door het plaatsen van een vinkje bij de activiteit. Naast het wel of niet selecteren van een activiteit is de gebruiker ook in staat om de gebruikte resources te bepalen. De gebruikte resources moeten gekozen worden uit het bereik van 0 tot en met 99. Met behulp van de knoppen Opslaan en Annuleren kan de gemaakte planning worden opgeslagen of kan het scherm worden verlaten zonder de planning op te slaan. Planning verwijderen Als de gebruiker een planning wilt verwijderen kan hij de te verwijderen planning selecteren. Vervolgens kan de gebruiker op Verwijder klikken om de geselecteerde planning te verwijderen. Voordat de planning definitief wordt verwijderd wordt er nog een waarschuwing getoond. 5 Model Na het ontwerpen van de eerste twee functionaliteiten is er besloten om een duidelijk model te implementeren van een planning. Hier is voor gekozen omdat tijdens het ontwerpen en implementeren van de eerste twee functionaliteiten er naar voren kwam dat een model voor planningen een goede aanvullig zou zijn en veel extra werk zou voorkomen. Om het model te implementeren dienen er wel wat aanpassingen te worden gedaan om alles goed te laten werken met hetgeen we tot nu toe hebben ontworpen. Er zullen een groot aantal aanpassingen in de database worden doorgevoerd om het model te ondersteunen. Naast de aanpassingen in de database zullen ook een aantal interfaces worden aangepast om zo het model beter zichtbaar te maken naar de gebruiker. Dit hoofdstuk zal bestaan uit een aantal secties. In de eerste sectie wordt beschreven wat de eisen zijn aan het model. In sectie twee komt het vernieuwde databaseontwerp aan bod en in sectie drie wordt het klassendiagram besproken. 5.1 Requirements Overzichtelijk De werking van het model dient helder geïmplementeerd te worden zodat het voor volgende functionaliteiten makkelijk toegankelijk is. Ook dient het model een laag te vormen tussen de database en het algoritme. Het model dient zo geïmplementeerd te worden dat deze zo dicht mogelijk bij de werkelijkheid ligt Vervanging Het model dient ook een groot aantal dubbel gebruikte code te vervangen. Code die voorheen diende om verschillende gegevens van een planning uit een database op te vragen dient nu op één lokale plek te worden geïmplementeerd. Hierdoor wordt uiteindelijk de code een stuk overzichtelijker. 5.2 Databaseontwerp In figuur 8 en 9 is het aangepaste databaseontwerp te zien. Het ontwerp is opgesplitst in twee delen om het overzichtelijk te houden. In de volgende paragraven zullen de verschillende tabellen worden toegelicht. 63

68 Figuur 8: Databaseontwerp van het model Figuur 9: Databaseontwerp van het model 64

69 Planning De database planning bevat een gehele planning. Een planning is het grootste geheel in het model. Een planning bevat alle gegevens over een planning. Al deze gegevens worden gekoppeld via een uniek id, het pid. Naast een pid wordt ook bijgehouden wat de naam, start-, en einddatum is van een planning. Jobs In de tabel Job worden de uiteindelijke voertuigen opgeslagen. Om een job te kunnen koppelen aan een planning wordt er gebruik gemaakt van de pid. Verder krijgt elke job een uniek id, het jid. Van een job worden verder nog de koppeling met een trein bijgehouden (door gebruik te maken van tid) en wordt er bijgehouden welke onderhoudsbeurt uitgevoerd dient te worden (door middel van sid). Daarnaast beschikt de tabel ook nog over de gegevens naam, start- en einddatum. Het modelid wordt gebruikt om activiteiten te kunnen koppelen aan jobs. Hier wordt geen gebruik gemaakt van id omdat het bij het aanmaken van een job nog onduidelijk is wat zijn id wordt. Om uiteindelijk alles aan elkaar te koppelen gebruiken we hier een nieuw id voor, het modelid. Activity Activiteiten worden bijgehouden in de tabel activity. Van een activiteit wordt de naam, earliest start time (est), duur (in uren), of de activiteit al is voltooid, de bijbehorende job (modelid van job) en planning bijgehouden. Naast deze gegevens wordt ook hier weer een modelid bijgehouden. Met dezelfde reden als beschreven in paragraaf 5.2 Requirement De requirement tabel is de tabel die bijhoudt welke activiteit welke resources en capaciteit benut. De kolom aid wordt gebruikt om de tabel activity (hiervoor wordt modelid) te koppelen met requirement. Naast deze gegevens wordt ook bijgehouden wat de jid (modelid van job) en de pid zijn. Resource Een resource wordt opgeslagen in de tabel resource en is de weergave van een beschikbare werkplaats of personeel. Elke resource heeft een maximale capaciteit en een naam om duidelijk te maken om welke resource het gaat. Constraint De tabel constraints houdt bij welk constraints er zijn aangemaakt. Train De tabel train bevat alle informatie over een bepaalde treintype. Onderhoud wordt altijd gekoppeld aan een treintype en niet aan een specifieke trein. ServicingName voor welke trein. In de tabel servicingname wordt bijgehouden welke onderhoudsbeurten er zijn Servicing Servicing zijn bepaalde groepen activiteiten die onder deze onderhoudsbeurt staan opgeslagen. Zo is het voor de gebruiker gemakkelijk om activiteiten te groeperen. Activity Default Een servicing bestaat uit een één of meerdere standaard activiteiten. Deze default activiteiten verschillen niet veel met een gewone activiteit. Het verschil zit hem in het feit dat een default activiteit nog niet specifiek ingevuld met gegevens over een planning. Bij een activiteit is dat wel het geval. Requirement Default Dit zijn de requirements die bij activity defaults horen, elke requirement geeft aan hoeveel van een bepaalde resource een bepaalde activity default vereist. 5.3 Klassendiagram Het model bestaande uit de verschillende klassen wordt weergegeven in figuur

70 Figuur 10: Klassendiagram voor het model Planning De klasse planning bevat een gehele planning. Een planning bestaat uit resources, jobs en constraints. Verder heeft een planning ook nog een aantal attributen die ervoor zorgen dat een planning uniek is (naam, startdatum en einddatum). Jobs De klasse jobs is een weergave van een voertuig dat in onderhoud gaat. Aan een job kunnen activiteiten worden uitgevoerd. Een job heeft ook nog een aantal attributen die specifieke gegevens bewaren over een job. Activity Activity geeft een activiteit van een job weer. Deze activiteiten bestaan uit een aantal requirements en een duur. Naast de requirements en duur worden er ook nog een aantal gegevens bijgehouden bij welke job een bepaalde activiteit hoort. Requirement Een requirement is een weergave van de benodigde resources voor deze activiteit. Elke requirement heeft beschikking over een amount en een resource. Resource Een resource is de weergave van een beschikbaar spoor of personeel. Een resource heeft een maximale capaciteit en een naam om duidelijk te maken om welke resource het gaat. Constraint vindt. Een constraint is een gegeven dat een activiteit voor een andere activiteit plaats Servicing Servicing zijn bepaalde groepen activiteiten die onder deze activiteiten staan opgeslagen. Zo kan een gebruiker eenvoudig veelgebruikte activiteiten groeperen. Activity Default Dit zijn de standaard activiteiten waaruit een servicing bestaat. Deze bevatten standaard requirements. 66

71 Requirement Default Dit zijn de requirements die bij activity defaults horen. Elke requirement default geeft aan hoeveel capaciteit er standaard van een resource wordt benut. 6 Grafische weergaven resultaten solver Nu dat de database ontworpen is moet er een ontwerp gemaakt worden voor het weergeven van planningen. Hieronder verstaan we zowel het inladen van planningen, het aanroepen van het algoritme en het verwerken van de resultaten van het algoritme tot visuele output. We kiezen ervoor om een opgeloste planning niet gelijk op te slaan in de database omdat de gebruiker dit schema nog moet kunnen aanpassen, vervolgens kan de gebruiker zelf de planning opslaan. De viewer wordt gebaseerd op het ontwerp van onze voorganger, Ronald Evers. We zullen zijn ontwerp overnemen maar deze op onze eigen manier implementeren en er extra functionaliteiten aan toevoegen. Dit hoofdstuk bevat achtereenvolgende de volgende secties; requirements, randvoorwaarden, usecases, klassendiagrammen en het interfaceontwerp. 6.1 Requirements Gebruiksvriendelijkheid Net als alle andere functionaliteiten die we ontwikkelen moet er ook hier rekening gehouden worden met de gebruiksvriendelijkheid. We willen het liefst in een zo min mogelijk aantal schermen de gewenste informatie tonen Vervangbaarheid We willen een interface ontwikkelen die onafhankelijk van de solver werkt. Hierdoor wordt het mogelijk om de solver gemakkelijk te kunnen vervangen. We gebruiken hiervoor een interface die alle informatie uit de database in een planning kan inladen en vervolgens deze informatie naar de solver kan sturen. De solver zorgt er voor dat een planning in het juiste formaat weer wordt teruggegeven aan de interface Aanpasbaar Een planning wordt door de gebruiker aangepast. Hiervoor moet de planning zo flexibel mogelijk worden weergegeven. De gebruiker moet naast de maximale hoeveelheid resources ook start- en eindtijden kunnen aanpassen. 6.2 Randvoorwaarden Runtime Omdat de grafische interface geen invloed uitoefent op het algoritme en omdat de interface moet wachten op output van de solver, is het niet mogelijk om een voorspelling te maken van de looptijd. Het kan dus voorkomen dat een gebruiker enkele minuten moet wachten op output van het algoritme. 6.3 Usecases In figuur 11 zijn de usecases zichtbaar gemaakt waar de gebruiker toegang tot heeft. In de volgende paragrafen lichten we de usecases kort toe. 67

72 Figuur 11: Usecases voor het grafisch weergeven van de resultaten van de solver Show planning In de menubalk komt een knop met Show planning. Als deze knop ingedrukt wordt krijgt de gebruiker een scherm te zien met opgeslagen planningen. De gebruiker kiest uit deze lijst de planning die hij wil openen. Alle activiteiten worden vervolgens zo geplaatst dat deze voldoen aan de starttijden van een activiteit. Dit houdt in dat als een planning voor het eerst geopend word alle starttijden van activiteiten gelijk zijn aan de starttijd van een job. Is een planning al vaker geopend zal deze de aangepaste starttijden van de activiteiten weergeven. Zodra een planning is geopend is de gebruiker in staat om de planning aan te passen, op te lossen of op te slaan (als...). Planning aanpassen De planner dient bepaalde activiteiten voor andere activiteiten te plannen. Dit dient uiteindelijk te gebeuren door middel van Drag & Drop. De gebruiker klikt op een activiteit en kan deze vervolgens verslepen, om zo de volgorde van activiteiten te veranderen. Activiteiten kunnen alleen worden verschoven tussen de start- en eindtijd van een job. Mocht de planner de activiteit nog eerder (of later) willen verplaatsen dient men eerst de start- of eindtijd aan te passen. Deze usecase is onder te verdelen in de usecases Adjust resources, Move timewindow of a job en Move activity, welke worden besproken in de volgende drie paragrafen. Adjust resources Door een spinbox is het voor de gebruiker mogelijk om de maximale capaciteit van resources aan te passen. Move timewindow of a job De gebruiker moet in staat zijn het tijdsspan van een job te kunnen verschuiven. Hierdoor is hij in staat om de starttijd, en daarmee ook de eindtijd, te verschuiven. Move activity Een van de belangrijkste functionaliteiten is de mogelijkheid om de activiteiten te kunnen bewegen binnen het timeframe van een job. De user kan op een activiteit klikken en vervolgens deze activiteit vrij te bewegen zolang de muis ingedrukt is. De resources moeten zich dan ook aanpassen aan de beweging van de activiteit. Solve Met de Solve knop welke te vinden is in het menu, wordt de solver aangeroepen. De gebruiker hoeft hier verder niets meer aan te doen omdat de solver gebruikt maakt van de planning die open staat. De solve knop is niet bruikbaar als er geen planning is ingeladen. 68

73 Save planning Met de Save planning knop uit het menu wordt een planning opgeslagen, dit betekent dat alle startposities van activiteiten naar de database worden geschreven. Naast de startposities worden ook gewijzigde gegevens opgeslagen. Save planning as... Met de save planning as... knop van het menu wordt een planning onder de meegegeven naam opgeslagen. Dit houdt in dat er een kopie van de planning wordt opgeslagen. 6.4 Klassendiagram In het vorige deel van het verslag hebben we functionaliteiten (toevoegen van planning aan de database en het verwijderen van planningen uit de database) ontworpen die we nu zullen vervangen als een package. We doen dit omdat het klassendiagram anders te groot en onoverzichtelijk wordt. In figuur 12 is het klassendiagram te zien. 69

74 Figuur 12: Klassendiagram om een planning grafisch weer te geven 70

75 OpenPlanningUi Grafische interface die gebruikt wordt om een bepaalde planning te selecteren die de viewcontroller moet weergeven. ViewController Controller die alle informatie uit de database ophaalt en in een planning zet. Zodra de planning is ingeladen maakt de controller alle vereiste ojecten aan om in de gui te plaatsen. De controller maakt dus jobname objecten met bijbehorende jobschedule objecten en resourcename met bijbehorende resourceschedule objecten aan. JobName Objecten die gebruikt worden ter identificatie van een bepaalde job in de interface. Aan elk jobname object is een jobschedule gekoppeld. JobSchedule Objecten die een bepaalde job grafisch representeren. In het object is het gedeelte van start- tot einddatum groen gemarkeerd zodat je kan zien waar de job begint en eindigd. Deze groene markering is verschuifbaar en dus zijn de data en tijden veranderbaar. ActivityBlock Grafische representatie van een activiteit in een job object. Een job bevat een aantal van deze blokken. Deze blokken kunnen handmatig versleept worden binnen de grenzen van de start- en einddatum van een job. ResourceName Een resourcename is een object dat de naam van een resource geeft en ook weergeeft hoeveel van een resource beschikbaar is. In dit object kan deze hoeveelheid ook aangepast worden. ResourceSchedule Een resourceschedule is gekoppeld aan een resourcename. In een resource- Schedule wordt grafisch weergeven hoeveel van de resource op elk moment in de planning vereist is. Deze wordt dynamisch aangepast bij een verschuiving van activityblocks. Solver De taak van de klasse solver is om het algoritme aan te roepen. Hiertoe dient er een executable te staan op de juiste locatie. Vervolgens zal de solver de planning aan het algoritme doorgeven. De solver zorgt verder ook voor de afhandeling van de resultaten uit het algoritme en geeft een planning terug aan de interface. 6.5 Interfaceontwerp Het ontwerp van de grafische interface zal voor een groot deel worden overgenomen van de Ontrack interface. Er wordt echter wel voor gekozen om deze interface vanaf de grond af aan opnieuw op te bouwen, omdat de Ontrack interface niet stabiel draait. Het eerste scherm dat de gebruiker te zien krijgt is bevat lijst met daarin de verschillende opgeslagen planningen (figuur 13a). Vervolgens krijgt de gebruiker een scherm met een onopgeloste planning te zien (figuur 13b) of een scherm met de opgeloste planning (figuur 13c). Open planning Met dit scherm is de gebruiker in staat om een gewenste planning te openen. Dit gebeurt door de gewenste planning te selecteren en vervolgens op Verder te klikken. Mocht de gebruiker terug willen keren naar het hoofdscherm kan hij hiervoor de knop Annuleren gebruiken. Nieuwe planning De gebruiker krijgt na het openen van een nieuwe planning dit scherm te zien. Hierin kan de gebruiker een planning naar eigen behoefte aanpassen. Zo is het mogelijk om de verschillende activiteiten te verplaatsen, de plaatsing van een job verschuiven, resources aan te passen, planning op te slaan (als...), planning te sluiten. Vervolgens kan de gebruiker de planning laten oplossen door gebruik te maken van de knop Solve. Vervolgens wordt de planning aangepast naar de resultaten van het algoritme. 71

76 (a) Open planning (b) Nieuwe planning (c) Reeds geopende planning Figuur 13: Grafische ontwerp om een planning grafisch te weergeven Reeds geopende planning Als de gebruiker een planning al een keer eerder heeft geopend zal het scherm er iets anders uitzien dan wanneer hij een planning voor de eerste keer opent. Omdat bij een opgeslagen planning al starttijden bekend zijn worden deze meegenomen in het grafisch weergeven van de planning. Naast deze extra functionaliteit heeft de gebruiker bij dit scherm dezelfde functionaliteiten als bij het scherm dat hij te zien krijgt als een planning voor de eerste keer wordt geopend. 7 Aanpassingen Database Nu dat de database ontworpen is, het model werkt en planningen grafisch kunnen worden weergegeven en aangepast is het noodzakelijk om andere informatie in de database te kunnen opslaan. Belangrijk is dat bijvoorbeeld standaard onderhoudsbeurten (servicing) en activiteiten kunnen worden toegevoegd aan de database. 7.1 Requirements Gebruiksvriendelijkheid Ook hier is de gebruiksvriendelijkheid weer erg belangrijk, het is nu echter ook zeer belangrijk dat alles voor de gebruiker duidelijk werkt. Als deze functionaliteit namelijk niet goed werkt of niet goed begrepen wordt is de gebruiker niet in staat op op een handige manier met de database te werken Opties De planner moet zoveel mogelijk vrijheid krijgen om informatie te kunnen veranderen en op te slaan. Dit om te voorkomen dat een planner vervreemd wordt van de software en deze niet meer gebruikt. Dit betekent dat de gebruiker resources, activiteiten, servicings en treinen vrij moet kunnen toegevoegd. 72

77 Figuur 14: Usecases om gegevens in de database te bewerken Meerdere toevoegen Om productiviteit van de gebruiker te verhogen is het nodig knoppen aan te maken om meerdere gegevens tegelijkertijd in te kunnen voeren. 7.2 Usecases Het usecase diagram is te zien in figuur 14. Add resource Om een resource toe te voegen dient de gebruiker te kiezen voor de optie Add resource. Vervolgens krijgt de gebruiker een scherm te zien waar een naam en een maximale capaciteit ingevoerd dient te worden. Er is gekozen om niet meer dan een resource tegelijkertijd in te kunnen voeren. Deze keuze is gemaakt omdat dit zelden zal voorkomen. Edit resource Om een resource aan te passen kan de gebruiker kiezen voor Edit resource. Hierin heeft hij de mogelijkheid om de naam en de maximale capaciteit van een resource aan te passen. Remove resource Er is voor gekozen om geen resources te verwijderen. Deze keuze hebben we gemaakt omdat het dan kan voorkomen dat een gebruiker een resource verwijdert die nog wel in planningen voorkomt. Om onverwachte resultaten te voorkomen is er dus voor gekozen om geen resources te verwijderen. Add Activity Default Het toevoegen van een default activity kan door de gebruiker worden aangeroepen vanuit de menubalk. De gebruiker krijgt nu een scherm te zien waarin hij de naam van de activiteit, het treintype van de activiteit en de benodigde resources invult. Add Servicing Als de gebruiker een onderhoudsbeurt wilt toevoegen kiest hij uit de menubalk de optie Add servicing. In het scherm dat nu verschijnt kan de gebruiker een naam aan de onderhoudsbeurt toekennen, een treintype kiezen en de verschillende default activiteiten kiezen. Remove Servicing In de menubalk kan de optie Remove servicing worden gekozen. Vanuit dit scherm is de gebruiker in staat om ingevoerde servicings te verwijderen. Het selecteren van een servicing gebeurt op basis van het geselecteerde treintype. Edit Servicing Om ervoor te zorgen dat onderhoudsbeurten ook gewijzigd kunnen worden is ook hiervoor een optie in de menubalk ingebouwd. In het scherm kan je de default activiteiten van een onderhoudsbeurt veranderen door deze aan of uit te vinken. 73

78 7.3 Klassendiagram De functionaliteiten ontworpen in de vorige hoofdstukken zullen ook weer vervangen worden door een package. Dit is weer puur visueel om het klassendiagram overzichtelijk te houden. De toegevoegde functionaliteiten zullen bestaan uit een aantal controllers die een aantal interfaceklassen aanstuurt. Voor een overzicht zie figuur

79 75 Figuur 15: Klassendiagram om gegevens in de database te bewerken

80 Controllers De verschillende controllerklassen worden gebruikt om de werking van de interfaces aan te sturen. De taak van de controller is om de juiste interface te tonen, de juiste gegevens weer te geven in de interface, de ingevoerde gegevens te verwerken en door te geven aan de databasecontroller. Interfaces De interfaceklassen zorgen voor het weergeven van de verschillende schermen. Elk scherm maakt zijn eigen objecten aan welke getoont dienen te worden. Een interfaceklasse zorgt ook zelf voor zijn eigen layout. Met behulp van get- en setmethoden is het voor de controller mogelijk om verschillende gegevens in de interface te plaatsen of uit te lezen. 7.4 Interfaceontwerp In figuur 16 zijn de verschillende interfaces te zien om zo verschillende gegevens te verwijderen uit, toe te voegen aan de database of te wijzigen. Add resource Met behulp van dit scherm is de gebruiker in staat om nieuwe resources toe te voegen. Hiertoe dient de gebruiker een nieuwe unieke naam en de maximaal beschikbare capaciteit op te geven. Door vervolgens op Opslaan te klikken krijgt de gebruiker een melding dat de resource is opgeslagen. Mocht de gebruiker een ongeldige invoer geven, een niet unieke naam of een lege naam, dan krijgt de hij hiervan een melding. Add servicing Een nieuwe standaard onderhoudsbeurt kan worden toegevoegd door gebruik te maken van het scherm uit figuur 16b. Omdat een onderhoudsbeurt afhankelijk is van een treintype is het noodzakelijk om naast een naam ook een treintype op te geven. Afhankelijk van het soort treintype worden de verschillende standaard activiteiten getoont. Uit deze activiteiten kan de gebruiker een keuze maken welke activiteit bij de te maken onderhoudsbeurt hoort. Vervolgens kan de gebruiker met drie knoppen zijn volgende actie bepalen (Opslaan, nog een onderhoudsbeurt invoeren of annuleren). Ook krijgt de gebruiker een melding als de onderhoudsbeurt is opgeslagen of een waarschuwing als er verkeerde invoer wordt meegegeven. Add activity default Via het scherm van figuur 16c is het mogelijk om nieuwe standaard activiteiten toe te voegen. Evenals bij het toevoegen van een onderhoudsbeurt dient hier een naam en een treintype ingevoerd te worden. Verder dient de gebruiker aan te geven wat de standaard duur is van de activiteit. Vervolgens kan de gebruiker de verschillende benodigde resources kiezen uit de lijst aan de rechterkant. Ook hier heeft de gebruiker weer toegang tot dezelfde knoppen als bij het scherm om nieuwe onderhoudsbeurten toe te voegen, en wordt er een melding weergegeven bij het opslaan en een waarschuwing afgegeven bij verkeerde invoer. Remove servicing Om een onderhoudsbeurt te verwijderen dient de gebruiker het juiste treintype te kiezen. Vervolgens zullen de beschikbare onderhoudsbeurten van het gekozen treintype worden weergegeven. Door een onderhoudsbeurt te selecteren en op de knop Verwijder te klikken wordt de beurt verwijderd. De gebruiker kan terugkeren met de knop Annuleer. Edit resource Een gebruiker is in staat om resources aan te passen. Hiertoe dient hij gebruik te maken van het scherm in figuur 16e. De gebruiker krijgt een lijst te zien met alle beschikbare resources. Vervolgens kan hij de naam en de beschikbare capaciteit van alle resources aanpassen. Ook hier geldt weer dat dubbele namen niet voor mogen komen. Edit servicing Om een onderhoudsbeurt aan te passen dient de gebruiker eerst het treintype waarbij de onderhoudsbeurt hoort te selecteren. Vervolgens kiest de gebruiker de gewenste onderhoudsbeurt. De gebruiker kan nu door middel van het verwijderen of plaatsen van vinkjes kiezen welke standaard activiteiten bij deze onderhoudsbeurt horen. De gebruiker kan alleen maar kiezen uit activiteiten die horen bij het geselecteerde treintype. Door vervolgens op Aanpassen te 76

81 (a) Add resource (b) Add servicing (c) Add activity Default (d) Remove servicing (e) Edit resource (f) Edit servicing Figuur 16: Grafische ontwerp om verschillende gegevens toe te voegen aan, te verwijderen uit de database of aan te passen. 77

82 Figuur 17: Uitgebreid usecase diagram met het bijhouden van de voortgang klikken wordt alles opgeslagen. Door Annuleren aan te klikken keert de gebruiker terug zonder wijzigingen aan te brengen. Ook bij dit scherm krijgt de gebruiker een melding zodra alles is opgeslagen. 8 Voortgang bijhouden De laatste functionaliteit die nog ontworpen moet worden is de mogelijkheid om de voortgang van activiteiten bij te houden. Als een activiteit afgelopen is moet je dit kunnen aangeven zodat deze activiteit niet meer meegenomen wordt in een eventuele nieuwe planning voor het algoritme. Hiertoe dienen activiteiten de mogelijkheid te hebben om te worden afgevinkt. Het bijhouden van de voortgang is een uitbreiding van de functionaliteit om een planning grafisch weer te geven. (zie hoofdstuk 6) 8.1 Requirements Overzichtelijkheid Activiteiten afvinken is noodzakelijk zodat je gemakkelijk bij kan houden welke activiteit wel en welke activiteit niet voltooid zijn. Er moet dus een duidelijke manier worden bedacht om aan te geven of een activiteit afgelopen is. Wel moet de activiteit ten alle tijden zichtbaar zijn in de grafiscche weergaven. 8.2 Usecases Er komen twee nieuwe usecases bij de usecases die we al hadden om een planning grafisch weer te geven. In figuur 17 worden deze usecases weer gegeven. Open Activity Info Als een planning in de viewer wordt weergeven kan je dubbelklikken op elke activiteit. Door dit de doen zal een scherm openen met extra informatie over de activiteit. Check/Uncheck Als de gebruiker het scherm met extra informatie over een activiteit heeft geopend heeft hij de mogelijkheid om deze activiteit te markeren als voltooid. Omdat het natuurlijk altijd mogelijk is dat per ongeluk een verkeerde activiteit wordt gemarkeerd is het ook mogelijk de markering uit te zetten. 8.3 Klassendiagram Aangezien dit een uitbreiding is van de viewer klassen hebben we het klassendiagram van de viewer uitgebreid met de extrainfowidget klasse zoals je kan zien in figuur

83 Figuur 18: Klassendiagram om de voortgang van activiteiten bij te houden 79

84 Figuur 19: Voortgang van een activiteit bijhouden extrainfowidget Een speciaal scherm dat gebruikt wordt om eventueel extra informatie te geven over een activiteit. Naast het weergeven van extra informatie is het in dit scherm ook mogelijk om een activiteit te markeren als voltooid. 8.4 Interfaceontwerp Dit interfaceontwerp bestaat maar uit een enkel scherm. Dit scherm geeft alle informatie weer over een activiteit en stelt de gebruiker in staat om activiteiten te markeren als voltooid. In figuur 19 is dit scherm te zien. Naast het markeren van een activiteit heeft de gebruiker ook de mogelijkheid om de te gebruiken resources aan te passen. Referenties [1] R.P. Evers. Algorithms for scheduling of train maintenance. Master s thesis, Delft University of Technology, Electrical Engineering, Mathematics and Computer Science,