Onderhoudsplanner Nedtrain

Technische Universiteit Delft IN3405 - Bachelorproject

Onderhoudsplanner Nedtrain Edwin Bruurs - 1358200 [email protected] Cis van de Louw - 1358340 [email protected]

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)

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

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

Inhoudsopgave 1 Introductie 2 Opdrachtomschrijving & 2.1 Opdracht . . . . . . . 2.2 Analyse . . . . . . . . 2.3 Uitvoering . . . . . . . 2.4 Deliverables . . . . . . 2.5 Eisen . . . . . . . . . . 2.6 Beperkingen . . . . . . 2.7 Gebruikte tools . . . .

1 analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

1 1 1 2 2 2 2 2

3 Planning 3.1 Fasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Tijdsplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 Ontwerp & implementatie 4.1 Database . . . . . . . . . . . . 4.2 Planning maken en verwijderen 4.3 Model . . . . . . . . . . . . . . 4.4 Viewer . . . . . . . . . . . . . . 4.5 Data Aanpassen . . . . . . . . 4.6 Afvinken . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 3 5 8 10 10 14

5 Proces 5.1 C++ . . . . . . . . . . . . . . 5.2 Model . . . . . . . . . . . . . 5.3 Software Improvement Group 5.4 Qt . . . . . . . . . . . . . . . 5.5 Gnome versus Unity . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

16 16 16 17 17 18

. . . . .

6 Conclusie

18

7 Aanbevelingen 7.1 Nieuwe functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Optimalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 18 19

A Opdrachtomschrijving

20

B Ori¨ entatieverslag

24

C Plan van Aanpak

37

D Requerements and Analysis Document

47

E Software Improvement Group

81

F Documentatie broncode

84

iii

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

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

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. 4.1.1

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

Figuur 1: Databaseontwerp om een planning in op te slaan

Figuur 2: Databaseontwerp om overige gegevens in op te slaan

4

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. 4.1.2

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

Figuur 3: Klassendiagram database

6

Figuur 4: Klassendiagram planning toevoegen/verwijderen

7

• 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

Figuur 5: Klassendiagram model

9

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 resourceSchedule 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

Figuur 6: Klassendiagram grafische weergaven van een planning

11

Figuur 7: Weergave in viewer

12

Figuur 8: Klassendiagram om data aan te passen

13

• 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

Figuur 9: Klassendiagram voor het afvinken van activiteiten

15

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

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. 5.3.1

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. 5.3.2

Parameters

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. 5.3.3

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

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

• 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. ´ en van de dingen die we graag ge¨ımplementeerd hadden gezien was het mogelijk maken • E´ 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. 7.2.1

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 createPoints 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. 7.2.2

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

A

Opdrachtomschrijving

20

Bachelorproject - Opdrachtomschrijving Edwin Bruurs 1358200 [email protected]

Cis van de Louw 1358340 [email protected]

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

• 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

B

Ori¨ entatieverslag

24

Bachelorproject - Oriëntatieverslag Edwin Bruurs 1358200 [email protected]


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

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

Inhoudsopgave 1 Introductie

29

2 Nedtrain 2.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Onderhoud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 29 29 31

3 Probleemomschrijving 3.1 Algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Grafische schil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 32 32

4 Solver 4.1 Algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Grafische user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 33 34

5 C, C++ en Qt 5.1 C en C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 35

28

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. 2.1.1

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. 2.1.2

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 2.2.1 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

Figuur 1: Organisatiestructuur NS [5]

Figuur 2: Organisatiestructuur Nedtrain [4]

30

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. 2.2.2

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

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

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. 4.2.1

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 "" 33

• Job: J <job id> "" • Activity: A <job id> "" • Requirement: Q <job id> <required capacity> • Precedence: P <job 1 id> <job 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. 4.2.2

Output

De output van het algoritme ziet er als volgt uit. Instance solved. 0.002069 2.103799 5.312177 125 306 0.000000 759 total: 8.615520 parsing: 0.002069 stn: 1.063427 esta+: 2.103799 chaining: 5.312177 leveling constraints before chaining: 125 leveling constraints after chaining: 306 robustness: 0.000000 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

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

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, 2008. [2] R.P. Evers. Algorithms for scheduling of train maintenance. Master’s thesis, Delft University of Technology, Electrical Engineering, Mathematics and Computer Science, 2011. [3] Brian W. Kernighan. The C Programming Language. Prentice Hall Professional Technical Reference, 2nd edition, 1988. [4] Nedtrain. Organisatie. Website, 2007. http://www.nedtrain.nl/nl/2/organisatie.html. [5] NS. Organisatiestructuur ns. Website, 2011. http://ns.nl/cs/Satellite/ns2007/nl/artikel/include/1175591758511/organigram?p=1175176893549.

36

C

Plan van Aanpak

37

Bachelorproject - Plan van Aanpak Edwin Bruurs 1358200 [email protected]


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

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


42

2 Projectopdracht 2.1 Projectomgeving . . . 2.2 Doelstelling project . . 2.3 Opdrachtformulering . 2.4 Op te leveren diensten 2.5 Eisen en beperkingen . 2.6 Voorwaarden . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

42 42 42 42 43 43 43

3 Aanpak en tijdsplanning 3.1 Aanpak . . . . . . . . . . . . . . . . 3.1.1 Fase 1: Oriëntatiefase . . . . 3.1.2 Fase 2: Globale ontwerpfase . 3.1.3 Fase 3: Gedetailleerd ontwerp 3.1.4 Fase 4: Implementatie . . . . 3.1.5 Fase 5: Testen . . . . . . . . 3.1.6 Fase 6: Documentatie . . . . 3.2 Tijdsplanning . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . van functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

43 43 43 43 44 44 44 44 44

4 Projectinrichting 4.1 Organisatie . . . . . 4.2 Rapportering . . . . 4.3 Administratie . . . . 4.4 Techniek en Software

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

45 45 45 45 45

5 Kwaliteitsborging 5.1 Proceskwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Productkwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 45 46

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . .

41

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

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 3.1.1

Aanpak Fase 1: Ori¨ entatiefase

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. 3.1.2

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

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. 3.1.4

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. 3.1.5

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. 3.1.6

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

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

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, 2011. [2] R.P. Evers. Algorithms for scheduling of train maintenance. Master’s thesis, Delft University of Technology, Electrical Engineering, Mathematics and Computer Science, 2011.

46

D

Requerements and Analysis Document

47

Bachelorproject - Requirement and Analysis Document Edwin Bruurs 1358200 [email protected]


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

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


53

2 Globaal ontwerp 2.1 Requirements . . . . . . . . . . . . . . . . . . 2.1.1 Overzichtelijke gebruikersinterface . . 2.1.2 Database . . . . . . . . . . . . . . . . 2.1.3 Planning maken of verwijderen . . . . 2.1.4 Planning grafisch weergeven . . . . . . 2.1.5 Voortgang van een planning bijhouden 2.1.6 Dataopslag . . . . . . . . . . . . . . . 2.1.7 Planningen wijzigen . . . . . . . . . . 2.1.8 Planningen vergelijken . . . . . . . . . 2.1.9 Geen oplossing . . . . . . . . . . . . . 2.1.10 Solver . . . . . . . . . . . . . . . . . . 2.1.11 Werking solver . . . . . . . . . . . . . 2.1.12 Extra functionaliteiten . . . . . . . . . 2.2 Randvoorwaarden . . . . . . . . . . . . . . . 2.2.1 Advies . . . . . . . . . . . . . . . . . . 2.2.2 Looptijd . . . . . . . . . . . . . . . . . 2.2.3 Knelpunten . . . . . . . . . . . . . . . 2.2.4 Volgorde . . . . . . . . . . . . . . . . . 2.3 Functionaliteiten . . . . . . . . . . . . . . . . 2.3.1 Gebruikersinterface . . . . . . . . . . . 2.3.2 Database . . . . . . . . . . . . . . . . 2.3.3 Planning maken en verwijderen . . . . 2.3.4 Planning grafische weergave . . . . . . 2.3.5 Grafische weergaven resultaten solver 2.3.6 Dataopslag . . . . . . . . . . . . . . . 2.3.7 Voortgang bijhouden . . . . . . . . . . 2.3.8 Vergelijken planningen . . . . . . . . . 2.3.9 Solvers toevoegen en verwijderen . . . 2.3.10 Inzicht in de solver geven . . . . . . . 2.3.11 Wizard . . . . . . . . . . . . . . . . . 2.4 Diagrammen . . . . . . . . . . . . . . . . . . 2.4.1 Usecasediagram . . . . . . . . . . . . . 2.4.2 Klassendiagram . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

53 53 53 53 54 54 54 54 54 54 54 54 55 55 55 55 55 55 55 56 56 56 56 56 56 56 56 57 57 57 57 57 57 57

3 Database 3.1 Requirements . . 3.1.1 Formaat . 3.2 Databaseontwerp 3.3 Klassendiagram .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

58 58 58 58 59

4 Planning maken en verwijderen 4.1 Requirements . . . . . . . . . . 4.1.1 Gebruiksvriendelijkheid 4.2 Randvoorwaarden . . . . . . . 4.2.1 Wijzigen planning . . . 4.3 Usecases . . . . . . . . . . . . . 4.4 klassendiagram . . . . . . . . . 4.5 Interfaceontwerp . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

60 60 60 60 60 60 61 62

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

51

5 Model 5.1 Requirements . . . . 5.1.1 Overzichtelijk 5.1.2 Vervanging . 5.2 Databaseontwerp . . 5.3 Klassendiagram . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

63 63 63 63 63 65

6 Grafische weergaven resultaten solver 6.1 Requirements . . . . . . . . . . . . . . 6.1.1 Gebruiksvriendelijkheid . . . . 6.1.2 Vervangbaarheid . . . . . . . . 6.1.3 Aanpasbaar . . . . . . . . . . . 6.2 Randvoorwaarden . . . . . . . . . . . 6.2.1 Runtime . . . . . . . . . . . . . 6.3 Usecases . . . . . . . . . . . . . . . . . 6.4 Klassendiagram . . . . . . . . . . . . . 6.5 Interfaceontwerp . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

67 67 67 67 67 67 67 67 69 71

7 Aanpassingen Database 7.1 Requirements . . . . . . . . . . 7.1.1 Gebruiksvriendelijkheid 7.1.2 Opties . . . . . . . . . . 7.1.3 Meerdere toevoegen . . 7.2 Usecases . . . . . . . . . . . . . 7.3 Klassendiagram . . . . . . . . . 7.4 Interfaceontwerp . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

72 72 72 72 73 73 74 76

8 Voortgang bijhouden 8.1 Requirements . . . . . . . 8.1.1 Overzichtelijkheid 8.2 Usecases . . . . . . . . . . 8.3 Klassendiagram . . . . . . 8.4 Interfaceontwerp . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

78 78 78 78 78 80

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

52

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. 2.1.1

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. 2.1.2

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

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 2.1.2. Naast het kunnen maken van een planning moet de gebruiker ook de mogelijkheid hebben om gemaakte planningen te verwijderen. 2.1.4

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 worden1 . Naast het visueel weergeven van een planning is het noodzakelijk om de gevolgen van het verschuiven van activiteiten zichtbaar te maken. 2.1.5

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. 2.1.6

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. 2.1.7

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. 2.1.8

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. 2.1.9

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. 2.1.10

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

mogelijk om zelf de solver aan te passen. Naast het toevoegen van solvers moet het ook mogelijk zijn om solvers te verwijderen. 2.1.11

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. 2.1.12

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. 2.2.1

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. 2.2.2

Looptijd

Omdat de looptijd van het algoritme afhangt van de grootte van een instantie (de complexiteit van het algoritme is O(n3 )), 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. 2.2.3

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 2.1.9 hoogstwaarschijnlijk op dit moment niet ge¨ımplementeerd kunnen worden. 2.2.4

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

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. 2.3.1

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. 2.3.2

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. 2.3.3


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. 2.3.4

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¨ update. 2.3.5

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. 2.3.6

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. 2.3.7

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

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. 2.3.9

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. 2.3.10

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. 2.3.11

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. 2.4.1

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. 2.4.2

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

Figuur 1: Usecase diagram van het te ontwikkelen systeem

3

Figuur 2: Klassediagram van het te ontwikkelen systeem

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 3.1.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

Figuur 3: Databaseontwerp

Figuur 4: Klassendiagram voor het opslaan van data in de database constraint teiten zijn.

In de tabel constraint wordt bijgehouden wat de volgorde van verschillende activi-

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

Figuur 5: Usecase diagram voor het toevoegen en verwijderen van een planning

4


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 4.1.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 4.2.1

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

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¨ ordineren. 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

(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

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 5.1.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. 5.1.2

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

Figuur 8: Databaseontwerp van het model

Figuur 9: Databaseontwerp van het model

64

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 10.

65

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

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 6.1.1


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. 6.1.2

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. 6.1.3

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 6.2.1

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

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

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

70

Figuur 12: Klassendiagram om een planning grafisch weer te geven

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 resourceSchedule 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

(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 7.1.1


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. 7.1.2

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

Figuur 14: Usecases om gegevens in de database te bewerken 7.1.3

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

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 15.

74

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

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

(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

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 8.1.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 18.

78

79

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

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, 2011.

80

E

Software Improvement Group

81

Bachelorproject - Software Improvement Group Edwin Bruurs 1358200 [email protected]


1

Aanbevelingen

De code van het systeem scoort bijna 5 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De reden dat de perfecte score van 5 sterren niet is gehaald, wordt veroorzaakt door de Unit Interfacing en de Unit Size.

1.1

Unit Interfacing

Voor Unit Interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan abstractie. Daarnaast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen van de methode en in de meeste gevallen ook tot langere en complexere methoden. Voorbeelden van methodes met een bovengemiddeld aantal parameters in dit systeem zijn bijvoorbeeld de constructoren van de ’Activity’ en de ’Job’-classen. In beide gevallen worden er meerdere Integers verwacht waarvan sommige een verwijzing zijn naar een ander object, bijvoorbeeld de parameter ’jobId’ in de constructor van de Activity-class. Om de interface van deze methode duidelijker te maken zou hier wellicht het daadwerkelijke Job-object aan meegegeven kunnen worden i.p.v. alleen een id. Hierdoor wordt bijvoorbeeld ook voorkomen dat er een Activity geinstantieerd wordt met een id voor een niet bestaande Job.

1.2

Unit Size

Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de extreem lange methodes in dit systeem, zoals bijvoorbeeld de ’AddPlanningController::createDefaultPlanning()’methode, zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld ’//Set the activities from the servicing on true (servicingCheck).’ zijn altijd een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen.

1.3

Algemeen

Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau aan te houden tijdens de rest van de ontwikkelfase. Als laatste nog de opmerkingen dat er geen (unit)test-code is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen.

83

F

Documentatie broncode

84

’Bachelorproject Nedtrain’ Generated by Doxygen 1.7.3 Thu Jul 28 2011 16:44:01

Contents 1

Class Index 1.1 Class List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

Class Documentation 2.1 Activity Class Reference . . . . . . . . . . 2.2 ActivityBlock Class Reference . . . . . . . 2.3 ActivityDefault Class Reference . . . . . . 2.4 ActivityDefaultController Class Reference . 2.5 ActivityInfoWidget Class Reference . . . . 2.6 AddActivityDefaultUi Class Reference . . . 2.7 AddActivityUi Class Reference . . . . . . . 2.8 AddJobUi Class Reference . . . . . . . . . 2.9 AddPlanningController Class Reference . . 2.10 AddPlanningUi Class Reference . . . . . . 2.11 AddResourceUi Class Reference . . . . . . 2.12 AddServicingUi Class Reference . . . . . . 2.13 AddViewer Class Reference . . . . . . . . 2.14 ColorGenerator Class Reference . . . . . . 2.15 Constraint Class Reference . . . . . . . . . 2.16 DatabaseActions Class Reference . . . . . 2.17 databaseConnector Class Reference . . . . 2.18 EditResourceUi Class Reference . . . . . . 2.19 EditServicingUi Class Reference . . . . . . 2.20 Job Class Reference . . . . . . . . . . . . . 2.21 MainWindow Class Reference . . . . . . . 2.22 NameHeader Class Reference . . . . . . . 2.23 Planning Class Reference . . . . . . . . . . 2.24 ProgressUi Class Reference . . . . . . . . . 2.25 RemovePlanningController Class Reference 2.26 RemovePlanningUi Class Reference . . . . 2.27 RemoveServicingUi Class Reference . . . . 2.28 Requirement Class Reference . . . . . . . . 2.29 RequirementDefault Class Reference . . . . 2.30 Resource Class Reference . . . . . . . . . . 2.31 ResourceController Class Reference . . . . 2.32 ResourceHeader Class Reference . . . . . . 2.33 ResourceWidget Class Reference . . . . . . 2.34 SaveNameWidget Class Reference . . . . . 2.35 ScheduleWidget Class Reference . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

89 89 91 91 96 101 104 105 108 111 114 116 120 122 124 128 131 132 133 142 143 145 149 153 155 157 160 161 163 165 168 169 171 174 175 177 180 182

88

CONTENTS 2.36 2.37 2.38 2.39 2.40 2.41

SelectPlanningUi Class Reference . Servicing Class Reference . . . . . ServicingController Class Reference Solver Class Reference . . . . . . . TimeLine Class Reference . . . . . ViewController Class Reference . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. 186 . 190 . 191 . 194 . 195 . 196

Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

Chapter 1

Class Index 1.1 Class List Here are the classes, structs, unions and interfaces with brief descriptions: Activity . . . . . . . . . . ActivityBlock . . . . . . . ActivityDefault . . . . . . ActivityDefaultController ActivityInfoWidget . . . . AddActivityDefaultUi . . AddActivityUi . . . . . . AddJobUi . . . . . . . . . AddPlanningController . . AddPlanningUi . . . . . . AddResourceUi . . . . . . AddServicingUi . . . . . AddViewer . . . . . . . . ColorGenerator . . . . . . Constraint . . . . . . . . . DatabaseActions . . . . . databaseConnector . . . . EditResourceUi . . . . . . EditServicingUi . . . . . Job . . . . . . . . . . . . MainWindow . . . . . . . NameHeader . . . . . . . Planning . . . . . . . . . ProgressUi . . . . . . . . RemovePlanningController RemovePlanningUi . . . . RemoveServicingUi . . . Requirement . . . . . . . RequirementDefault . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

91 96 101 104 105 108 111 114 116 120 122 124 128 131 132 133 142 143 145 149 153 155 157 160 161 163 165 168 169

90

Class Index Resource . . . . . ResourceController ResourceHeader . ResourceWidget . SaveNameWidget . ScheduleWidget . SelectPlanningUi . Servicing . . . . . ServicingController Solver . . . . . . . TimeLine . . . . . ViewController . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

171 174 175 177 180 182 186 190 191 194 195 196


Chapter 2

Class Documentation 2.1 Activity Class Reference Public Member Functions • Activity (QString name, int est, int duration, Job ∗job, int id, bool checked, bool finished, QObject ∗parent) • bool getChecked () • bool getFinished () • int getDuration () • int getEst () • int getId () • int getJobId () • QString getName () • Requirement ∗ getRequirement (QString) • void setChecked (bool) • void setFinished (bool) • void setDuration (int newDuration) • void setEst (int newEst) • void setId (int newId) • void setJobId (Job ∗job) • void setName (QString newName) • void addRequirement (Requirement ∗) • void toString () • QString toSolveString (int jid, int tempId)

Public Attributes • QList< Requirement ∗ > requirements

92

Class Documentation

Private Attributes • • • • • • • •

2.1.1

QString name bool checked bool finished int startTime int duration Job ∗ job int id int est

Constructor & Destructor Documentation

2.1.1.1 Activity::Activity ( QString name, int est, int duration, Job ∗ job, int id, bool checked, bool finished, QObject ∗ parent )

Create a new Activity with the given parameters. Parameters name est job id checked finished

the name of the activity; the estimated start time; the parentJob of this activity; the id of this activity; the boolean for this activity if it is selected as an activity of this job the boolean for this activity is true iff activity is completed, else false (default). ∗parent the parent from this activity. This is the job. duration the duration of this activity

2.1.2

Member Function Documentation

2.1.2.1 void Activity::addRequirement ( Requirement ∗ newRequirement )

addRequirement adds the given requirement to the list. Parameters newRequire- Requirement∗ to be added to this activity. newRequirement != NULL. ment

2.1.2.2 bool Activity::getChecked ( )

getChecked returns an bool of this activity’s checked value. Returns checked (true / false) of this activity is selected as default activity Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.1 Activity Class Reference

93

2.1.2.3 int Activity::getDuration ( )

getDuration returns an int of this activity’s duration. Returns duration of this activity

2.1.2.4

int Activity::getEst ( )

getEst returns an int of this activity’s est. Returns estimated start time of this activity

2.1.2.5

bool Activity::getFinished ( )

getFinished returns the boolean of this activity. True iff this activity is finished else false Returns is this activity finished?

2.1.2.6

int Activity::getId ( )

getId returns an int of this activity’s id. Returns id of this activity

2.1.2.7

int Activity::getJobId ( )

getJobId returns an int of this activity’s job id. Returns job id of this activity its parent

2.1.2.8

QString Activity::getName ( )

getName returns a QString from this activity’s name. Returns name of this activity Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

94

Class Documentation

2.1.2.9 Requirement ∗ Activity::getRequirement ( QString name )

getRequirement returns a Requirement∗ of the given requirement name if this activity has this requirement, if there isn’t a requirement NULL is being returned. Parameters name a QString of the name of the requirement. name != "". Returns Requirement that have the resource with the given name. If this requirement isn’t fount NULL will be returned.

2.1.2.10

void Activity::setChecked ( bool newChecked )

setChecked sets the checked value to the new checked value. Parameters newChecked an bool of the new activity checked value.

2.1.2.11

void Activity::setDuration ( int newDuration )

setDuration sets the name to the new duration. duration will only be set if newDuration >0 Parameters newDura- an int of the new activity duration. newDuration > 0. tion

2.1.2.12

void Activity::setEst ( int newEst )

setEst sets the est to the new est. Est will only be updated if est > 0. Parameters newEst an int of the new activity est. newEst > 0.

2.1.2.13

void Activity::setFinished ( bool newFinished )

setFinished sets the finished value of this activity. True iff finished else false Parameters newFinished the new value of this activity.


2.1 Activity Class Reference

95

2.1.2.14 void Activity::setId ( int newId )

setId sets the id to the new id. Id will only be set if newId > 0 Parameters newId an int of the new activity id. newId >= 0.

2.1.2.15 void Activity::setJobId ( Job ∗ newJob )

setJobId sets the jobId to the new jobId. jobId will only be set if newJob != NULL Parameters newJob the job from which the id needs to be set. newJob != NULL.

2.1.2.16 void Activity::setName ( QString newName )

setName sets the name to the new name. Name will only be set if newName != "" Parameters newName a QString of the new activity Name. newName != "".

2.1.2.17 QString Activity::toSolveString ( int jid, int tempId )

toSolveString returns a QString of this activity in the form needed for the solver. Parameters jid an int that is the jid of this activity. jid >= 0 tempId the id of this activity, starting at 0 each job.

Returns QString that represents this activity.

2.1.2.18

void Activity::toString ( )

toString is used to test this activity. It returns an output in the console of the given activity. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

96

Class Documentation

2.1.3

Member Data Documentation

2.1.3.1 QList Activity::requirements

List of requirements that this activity contains. The documentation for this class was generated from the following files: • activity.h • activity.cpp

2.2 ActivityBlock Class Reference Public Slots • void activityIsFinished (int) • void changeDuration (int) • void updateResources ()

Signals • void shifted ()

Public Member Functions • • • • • • • • • • • • •

ActivityBlock (Job ∗, Activity ∗, QWidget ∗, int, int, QColor) QSize sizeHint () Activity ∗ getActivity () void setHeight (int) void correctPosition (int, bool) int getStartPos () void setStartPos (int) int getEndPos () void setEndPos () int getStartTime () void setStartTime (int) int getEndTime () void setEndTime (int)

Private Member Functions • • • •

void mouseReleaseEvent (QMouseEvent ∗) void mousePressEvent (QMouseEvent ∗) void mouseMoveEvent (QMouseEvent ∗) void mouseDoubleClickEvent (QMouseEvent ∗) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.2 ActivityBlock Class Reference

97

• void paintEvent (QPaintEvent ∗) • void moveBlock () • void setColor ()

Private Attributes • • • • • • • • • • • • • •

2.2.1

QWidget ∗ parent Activity ∗ activity Job ∗ job QColor color QColor notFinishedColor bool selected int startPos int endPos int startTime int endTime int start int height int numberInJobs ActivityInfoWidget ∗ info


2.2.1.1 ActivityBlock::ActivityBlock ( Job ∗ j, Activity ∗ a, QWidget ∗ p, int start, int end, QColor c )

Constructor that creates a block for a single activity in a job, gets the job A start and a end time of the job in pixel position to be able to know when it can’t move further on the screen Parameters j the job that this activity is part of a the activity that this block represents, it contains all the data needed for this representation p parent for this widget, needed to close widget when parent is closed start the startTime of the job in an integer position(not the same as a data that job object contains) end the endTime of the job in an integer position(not the same as a data that job object contains) c the color that this activity receives


98

Class Documentation

2.2.2


2.2.2.1 void ActivityBlock::activityIsFinished ( int i ) [slot]

When in the extra info screen the activity is set as finished or returned to not finished, set the state of the activity with this method accordingly, also change to correct color Parameters i returns 0 if not finished, otherwise finished

2.2.2.2 void ActivityBlock::changeDuration ( int newValue ) [slot]

Change the duration of the activity that belongs to this block. Parameters newValue the new duration

2.2.2.3 void ActivityBlock::correctPosition ( int newPos, bool calc )

Method used to change the position of this block whenever the job startdate is moved past the startdate of this activity, after the move the resources also need to be updated Parameters newPos the new startposition of this block calc boolean that contains info whether or not the shifting of the job is done

2.2.2.4 Activity ∗ ActivityBlock::getActivity ( )

method to return the activity this block represents Returns the activity of this block

2.2.2.5 int ActivityBlock::getEndPos ( )

method to get the endPos Returns the endPosition of this activity


2.2 ActivityBlock Class Reference

99

2.2.2.6 int ActivityBlock::getEndTime ( )

method to return the endTime of the job this activity is part of Returns the endTime of the job

2.2.2.7

int ActivityBlock::getStartPos ( )

method to get the startposition Returns the startPos of this block

2.2.2.8

int ActivityBlock::getStartTime ( )

method to return the startTime of the job this activity is part of Returns the startTime of the job

2.2.2.9

void ActivityBlock::mouseDoubleClickEvent ( QMouseEvent ∗ e ) [private]

If the mouse is double clicked open a widget that allows you to edit and view data from this activity Parameters e the mouse-event when the button is double clicked inside this widget

2.2.2.10 void ActivityBlock::mouseMoveEvent ( QMouseEvent ∗ e ) [private]

While the left mouse button is not released change the position of the widget by the amount the mouse has moved. Call method to resize to the correct position Parameters e the mouse-event when the button is moved inside this widget


100 2.2.2.11

Class Documentation void ActivityBlock::mousePressEvent ( QMouseEvent ∗ e ) [private]

Every time the mouse is pressed while on this widget set the position of the mouse and selected true to know a move might happen Parameters e the mouse-event when the button is clicked inside this widget

2.2.2.12

void ActivityBlock::mouseReleaseEvent ( QMouseEvent ∗ e ) [private]

If the mouse is release it is the end of the move, so selected becomes false When the mouse is released we also emit a signal that lets all attached resources know they need to update their pixmap Parameters e the mouse-event when the button is released inside this widget

2.2.2.13

void ActivityBlock::moveBlock ( ) [private]

Set the geometry of the widget to its new geometry, this is called after a mousemove event To be able to save the new position also write it to the planning where it will be written to the database later 2.2.2.14

void ActivityBlock::paintEvent ( QPaintEvent ∗ ) [private]

Paint the rectangle that represents the activity, when the activity is checked as finished the painted Paint rectangle changes to respresent this. For now it just turns white with a green block at the start 2.2.2.15

void ActivityBlock::setColor ( ) [private]

Special method to set the color of an activityBlock, color changes when activity is finished, remember the color when it is checked as finished, because user might check the wrong activity and you need to be able to rteurn the old color 2.2.2.16

void ActivityBlock::setEndPos ( )

method to set new endpos, calculates the position automatically, no intger needed 2.2.2.17

void ActivityBlock::setEndTime ( int newTime )

method to set the endTime of the job this activity is part of(only locally) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.3 ActivityDefault Class Reference

101

Parameters newTime the new endTime of the job

2.2.2.18 void ActivityBlock::setHeight ( int i )

After the expand button has been pushed the position of this block has to change in height 2.2.2.19

void ActivityBlock::setStartPos ( int newPos )

method to set a new startposition Parameters newPos the new position

2.2.2.20 void ActivityBlock::setStartTime ( int newTime )

method to set the startTime of the job this activity is part of(only locally) Parameters newTime the new startTime of the job

2.2.2.21 QSize ActivityBlock::sizeHint ( )

Returns the preferred size of the widget, the size of the widget is constantly the same 2.2.2.22 void ActivityBlock::updateResources ( ) [slot]

When an activity block is moved the resources need to be updated. The documentation for this class was generated from the following files: • activityBlock.h • activityBlock.cpp

2.3

ActivityDefault Class Reference

Public Member Functions • ActivityDefault (QString name, int duration, int trainId, QObject ∗parent) • QString getName () • int getDuration () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

102

Class Documentation • • • • • •

int getTrainId () void setName (QString) void setDuration (int) void setTrainId (int) void addRequirementDefault (RequirementDefault ∗newRequirementDefault) void toString ()

Public Attributes • QList< RequirementDefault ∗ > requirementDefaults

Private Attributes • • • •

2.3.1

QString name int duration int trainId QObject ∗ parent


2.3.1.1 ActivityDefault::ActivityDefault ( QString name, int duration, int trainId, QObject ∗ p )

Create a new ActivityDefault with the given parameters Parameters name duration trainId p

2.3.2

the name of this activityDefault the duration of this activityDefault the trainId of this activityDefault the parent of this activityDefault


2.3.2.1 void ActivityDefault::addRequirementDefault ( RequirementDefault ∗ newRequirementDefault )

Adds a default requirement to this default activity Parameters newRequire- the new default requirement for this default activity mentDefault


2.3 ActivityDefault Class Reference 2.3.2.2 int ActivityDefault::getDuration ( )

Returns the duration of this default activity.

2.3.2.3

QString ActivityDefault::getName ( )

Returns the name of this default activity.

2.3.2.4

int ActivityDefault::getTrainId ( )

Returns the trainid of this default activity.

2.3.2.5

void ActivityDefault::setDuration ( int newDuration )

Set the duration of this default activity Parameters newDura- the new value of the duration. newDuration > 0. tion

2.3.2.6 void ActivityDefault::setName ( QString newName )

Set the name of this default activity Parameters newName the new name of this activity. newName != "".

2.3.2.7 void ActivityDefault::setTrainId ( int newTrainId )

Set the trainid of this default activity Parameters newTrainId the new trainid. newTrainId > 0.


103

104

Class Documentation

2.3.2.8 void ActivityDefault::toString ( )

Debug string of this default activity.

2.3.3


2.3.3.1 QList ActivityDefault::requirementDefaults

List of requirementsDefaults that this activityDefault contains. The documentation for this class was generated from the following files: • activityDefault.h • activityDefault.cpp

2.4 ActivityDefaultController Class Reference Public Slots • void initializeAddActivityDefaultUi () • void buttonSaveClicked () • void buttonAnotherOneClicked ()

Public Member Functions • ActivityDefaultController (QWidget ∗p)

Private Member Functions • void saveInputToDb () • bool correctInput ()


AddActivityDefaultUi ∗ addActivityDefaultUi EditActivityDefaultUi ∗ editResourceUi RemoveActivityDefaultUi ∗ removeResourceUi QWidget ∗ parent

2.4.1


2.4.1.1

ActivityDefaultController::ActivityDefaultController ( QWidget ∗ p )

Create a new controller that can handle the add, edit and remove of default activities Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.5 ActivityInfoWidget Class Reference

105

Parameters p the parent of this controller

2.4.2


2.4.2.1 void ActivityDefaultController::buttonAnotherOneClicked ( ) [slot]

buttonAnotherOneClicked is called when the buttonAnotherOne from the ui is clicked. the input will be saved to the database and the screen won’t be closed. 2.4.2.2

void ActivityDefaultController::buttonSaveClicked ( ) [slot]

buttonSaveClicked is called when the buttonSave from the Ui is clicked. The input will be saved to the database and the screen will be closed. 2.4.2.3

bool ActivityDefaultController::correctInput ( ) [private]

Function that checks if the given input is correct Returns true iff all the input is correct else false

2.4.2.4

void ActivityDefaultController::initializeAddActivityDefaultUi ( ) [slot]

Initialize the ui to add default activities. 2.4.2.5

void ActivityDefaultController::saveInputToDb ( ) [private]

saves the input from the ui to the database. The documentation for this class was generated from the following files: • activityDefaultController.h • activityDefaultController.cpp

2.5

ActivityInfoWidget Class Reference

Public Member Functions • ActivityInfoWidget (ActivityBlock ∗, QWidget ∗) • int getResourceValue (int) • QString getResourceName (int) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

106

Class Documentation

Public Attributes • QWidget parent • ActivityBlock ∗ block

Private Member Functions • • • • • • •

void createLayout () void createLabels () void createCheckBox () void createSignals () void createButtons () void createSpinBox () void createResourceLayout ()

Private Attributes • • • • • • • • • • • • •

2.5.1

QFormLayout ∗ formLayout QHBoxLayout ∗ buttonLayout QVBoxLayout ∗ layout QLabel ∗ finishedLabel QLabel ∗ nameLabel QLabel ∗ activityNameLabel QLabel ∗ durationLabel QLabel ∗ resourceLabel QLabel ∗ resourceAmountLabel QSpinBox ∗ durationBox QCheckBox ∗ box QPushButton ∗ done QPushButton ∗ cancelButton


2.5.1.1 ActivityInfoWidget::ActivityInfoWidget ( ActivityBlock ∗ b, QWidget ∗ p )

Creates a qdialog where extra information can be viewed about the activity, at this moment it only allows you to either check an activity as finished or turn it to unfinished Calls on all the methods required to create the screen Parameters b the activityblock that contains the concerning activity p parent so that this window gets closed automatically when the parent is closed


2.5 ActivityInfoWidget Class Reference

2.5.2


2.5.2.1 void ActivityInfoWidget::createButtons ( ) [private]

Creates the buttons required in this screen 2.5.2.2

void ActivityInfoWidget::createCheckBox ( ) [private]

Creates the checkboxes requires in this screen 2.5.2.3

void ActivityInfoWidget::createLabels ( ) [private]

Creates the labels required in this screen 2.5.2.4

void ActivityInfoWidget::createLayout ( ) [private]

creates the layout of this screen also includes all the required widgets 2.5.2.5

void ActivityInfoWidget::createResourceLayout ( ) [private]

Create the layout for the resources. 2.5.2.6

void ActivityInfoWidget::createSignals ( ) [private]

Creates the sigannsl required in this screen 2.5.2.7

QString ActivityInfoWidget::getResourceName ( int i )

Returns the name of the requested resource Parameters i the resource that is requested Returns the name of the resource at location i.

2.5.2.8

int ActivityInfoWidget::getResourceValue ( int i )

get the value of the requested resource. Parameters i the resource that is requested


107

108

Class Documentation

Returns the amount of resource at location i. The documentation for this class was generated from the following files: • activityInfoWidget.h • activityInfoWidget.cpp

2.6 AddActivityDefaultUi Class Reference Public Member Functions • • • • • • • • •

AddActivityDefaultUi (ActivityDefaultController ∗c, QWidget ∗p) void addTrains (QStringList trainList) QString getTrain () void addRow (QString resourceName, int maxCapacity) QWidget ∗ getWidget (int row, int column) void clearInput () QString getLineEdit () int getCapacity () int getNumberOfRows ()

Public Attributes • QPushButton ∗ buttonAnotherOne • QPushButton ∗ buttonSave


void createButtons () void createLabels () void createLineEdit () void createSpinBox () void createComboBox () void createLayouts () void createSignals ()

Private Attributes • • • • •

int numberOfRows QLabel ∗ labelTitle QLabel ∗ labelExplanation QLabel ∗ labelName QLabel ∗ labelTrainType Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.6 AddActivityDefaultUi Class Reference • • • • • • • • • • • • • • • • •

QLabel ∗ labelDuration QLabel ∗ labelHeaderActivity QLabel ∗ labelHeaderResource QLabel ∗ labelResourceName QLabel ∗ labelCapacity QPushButton ∗ buttonClose QLineEdit ∗ lineEditName QSpinBox ∗ spinBoxCapacity QComboBox ∗ comboBoxTrainType QHBoxLayout ∗ hLayoutButtonContainer QFormLayout ∗ formLayout QGridLayout ∗ gridLayout QHBoxLayout ∗ hLayoutFormContainer QVBoxLayout ∗ vLayoutForm QVBoxLayout ∗ vLayoutGrid QVBoxLayout ∗ vLayoutMain ActivityDefaultController ∗ activityDefaultController

2.6.1 Constructor & Destructor Documentation 2.6.1.1

AddActivityDefaultUi::AddActivityDefaultUi ( ActivityDefaultController ∗ c, QWidget ∗ p )

Creating a new AddActivityDefaultUi. Parameters ∗c give the appropriate AddResourceController of this interface. ∗p the parent of this ui

2.6.2


2.6.2.1 void AddActivityDefaultUi::addRow ( QString resourceName, int maxCapacity )

addWidget adds the provided widget to the first place available in the gridlayout. Parameters resource- the name of the resource to be added Name maxCapac- the max available amount of this resource. ity

2.6.2.2 void AddActivityDefaultUi::addTrains ( QStringList trainList )

Add a train to the comboBox with the different traintypes. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

109

110

Class Documentation

Parameters trainList the name of the traintype to be added.

2.6.2.3 void AddActivityDefaultUi::clearInput ( )

Clears the given input 2.6.2.4 void AddActivityDefaultUi::createButtons ( ) [private]

Creating all the required buttons for this interface. 2.6.2.5 void AddActivityDefaultUi::createComboBox ( ) [private]

Creating all the required comboboxes. 2.6.2.6 void AddActivityDefaultUi::createLabels ( ) [private]

Creating all the required labels for this interface. 2.6.2.7 void AddActivityDefaultUi::createLayouts ( ) [private]

Creating all the required layouts for this interface. and set the layout of MainWindow to the final layout. 2.6.2.8

void AddActivityDefaultUi::createLineEdit ( ) [private]

Create all the required lineEdit. 2.6.2.9 void AddActivityDefaultUi::createSignals ( ) [private]

Creating all the required interface actions. Connecting signals to slots. 2.6.2.10

void AddActivityDefaultUi::createSpinBox ( ) [private]

Creating all the required spinbox. 2.6.2.11

int AddActivityDefaultUi::getCapacity ( )

Returns the value entered in the spinBox Returns the value of the capacity spinbox. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.7 AddActivityUi Class Reference 2.6.2.12 QString AddActivityDefaultUi::getLineEdit ( )

Returns the values entered in the lineEdit field Returns the value of the lineEdit.

2.6.2.13

int AddActivityDefaultUi::getNumberOfRows ( )

Returns the number of rows in the gridlayout Returns the number of rows in the gridlayout

2.6.2.14

QString AddActivityDefaultUi::getTrain ( )

Returns the selected traintype Returns the selected traintype as a QString

2.6.2.15

QWidget ∗ AddActivityDefaultUi::getWidget ( int row, int column )

getWidget returns the widget in the gridlayout at position row, column. Returns QWidget that is positioned in the gridlayout at (row, column) The documentation for this class was generated from the following files: • addActivityDefaultUi.h • addActivityDefaultUi.cpp

2.7

AddActivityUi Class Reference

Public Member Functions • • • • • • •

AddActivityUi (AddPlanningController ∗, QWidget ∗) void addWidget (QWidget ∗, int, int) void addWidget (QWidget ∗) QWidget ∗ getWidget (int, int) void addList (QStringList) int getSelectedListItem () void clear ()


111

112

Class Documentation

Private Member Functions • • • • •

void createButtons () void createLabels () void createLists () void createLayouts () void createSignals ()

Private Attributes • • • • • • • • • • • • • • • •

2.7.1

QPushButton ∗ buttonSave QPushButton ∗ cancelButton QLabel ∗ labelTitle QLabel ∗ labelExplanation QLabel ∗ labelSubtitleJob QLabel ∗ labelSubtitleActivity QListView ∗ listJob QVBoxLayout ∗ vLayoutMain QVBoxLayout ∗ vLayoutUp QVBoxLayout ∗ vLayoutLeft QVBoxLayout ∗ vLayoutRight QGridLayout ∗ gridLayout QHBoxLayout ∗ hLayoutDown QHBoxLayout ∗ hLayoutButtonContainer QStringListModel ∗ model AddPlanningController ∗ addPlanningController


2.7.1.1 AddActivityUi::AddActivityUi ( AddPlanningController ∗ c, QWidget ∗ p )

Constructor for the addActivityUi. When the constructor is called, we can already make and show the dialog. The contructor will call the methods that construct the various widgets on the screen.

2.7.2


2.7.2.1

void AddActivityUi::addList ( QStringList list )

Adds the given list to the model Parameters list the list with all the activity strings.


2.7 AddActivityUi Class Reference 2.7.2.2 void AddActivityUi::addWidget ( QWidget ∗ w, int row, int column )

adds a widget to the gridlayout Parameters w the widget to be added row the row in which the widget needs to be added column the column in which the widget needs to be added

2.7.2.3 void AddActivityUi::addWidget ( QWidget ∗ w )

Adds a widget to next index in the gridlayout Parameters w the widget to be added

2.7.2.4 void AddActivityUi::clear ( )

Clears the gridlayout

2.7.2.5 void AddActivityUi::createButtons ( ) [private]

creates the required buttons for this class

2.7.2.6

void AddActivityUi::createLabels ( ) [private]

creates the required labels for this class

2.7.2.7

void AddActivityUi::createLayouts ( ) [private]

creates the required layouts for this class

2.7.2.8

void AddActivityUi::createLists ( ) [private]

creates the required list for this class

2.7.2.9

void AddActivityUi::createSignals ( ) [private]

creates the required signals for this class Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

113

114

Class Documentation

2.7.2.10

int AddActivityUi::getSelectedListItem ( )

Returns the selected index of the list Returns int of the selected index.

2.7.2.11

QWidget ∗ AddActivityUi::getWidget ( int row, int column )

Returns the widget at the given position Parameters row the row were the widget is placed column the column were the widget is placed Returns QWidget∗ the widget at position (row,column) The documentation for this class was generated from the following files: • addActivityUi.h • addActivityUi.cpp

2.8 AddJobUi Class Reference Public Member Functions • • • •

AddJobUi (AddPlanningController ∗, QWidget ∗) QGridLayout ∗ returnGrid () void addWidget (QWidget ∗) QWidget ∗ getItemAt (int, int)


void createButtons () void createLabels () void createGridLayout () void createLayouts () void createSignals ()

Private Attributes • QLabel ∗ labelTitle Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.8 AddJobUi Class Reference • • • • • • • •

115

QLabel ∗ labelExplanation QPushButton ∗ nextButton QPushButton ∗ addRowButton QPushButton ∗ cancelButton QGridLayout ∗ gridLayout QHBoxLayout ∗ horizontalLayout QVBoxLayout ∗ totalLayout AddPlanningController ∗ addPlanningController

2.8.1


2.8.1.1

AddJobUi::AddJobUi ( AddPlanningController ∗ c, QWidget ∗ p )

addJobsUi.cpp Created on: May 10, 2011 Author: cis Constructor for the addJobsUi. When the constructor is called, we can already make and show the dialog. The contructor will call the methods that construct the various widgets on the screen.

2.8.2 Member Function Documentation 2.8.2.1

void AddJobUi::addWidget ( QWidget ∗ w )

Add the given QWidget to the first available place in the QGridLayout param w, the Widget to be added. 2.8.2.2

void AddJobUi::createButtons ( ) [private]

creates the required buttons for this class 2.8.2.3

void AddJobUi::createGridLayout ( ) [private]

Creates the basic gridLayout, with the required headers. 2.8.2.4

void AddJobUi::createLabels ( ) [private]

creates the required labels for this class 2.8.2.5

void AddJobUi::createLayouts ( ) [private]

creates the required layouts for this class 2.8.2.6

void AddJobUi::createSignals ( ) [private]

creates the required signals for this class Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

116

Class Documentation

2.8.2.7 QWidget ∗ AddJobUi::getItemAt ( int x, int y )

Returns the QWidget at place x,y param x, y position of the widget. 2.8.2.8 QGridLayout ∗ AddJobUi::returnGrid ( )

Returns the grid with all items return QGridLayout, pointer to the placed grid. The documentation for this class was generated from the following files: • addJobUi.h • addJobUi.cpp

2.9 AddPlanningController Class Reference Public Slots • • • • • • • • • •

void initializeAddPlanningUi () void planningUiButtonNextClicked () void initializeAddJobUi () void jobUiButtonNextClicked () void jobUiButtonAddRowClicked () void initializeAddActivityUi () void activityUiButtonSaveClicked () void connectBoxes () void controlDateTime () void updateActivityGrid ()

Public Member Functions • AddPlanningController (QWidget ∗)

Private Member Functions • • • • • • • • • • • •

bool existPlanning () void addRow () void createDefaultPlanning () bool existSameNames () void getDefaultServicingList () void getTrainTypes () void fillGrid () void fillGridHeaders () void fillGridContent () void fillListJob () void updatePlanning () void writePlanningToDatabase () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.9 AddPlanningController Class Reference

117


2.9.1

int numberOfRows int jid int pid int selectedItem int tid Planning ∗ planning QGridLayout ∗ gridLayout QList< int > aidList QStringList trainList QList< QString > ∗ servicingList QWidget ∗ parent AddPlanningUi ∗ addPlanningUi AddJobUi ∗ addJobUi AddActivityUi ∗ addActivityUi


2.9.1.1 AddPlanningController::AddPlanningController ( QWidget ∗ p )

Constructor for the AddPlanningController. When the constructor is called, we can already make and show the dialog. The first screen is being showed. Parameters ∗p QWidget of the parent, mostly mainWindow

2.9.2


2.9.2.1 void AddPlanningController::activityUiButtonSaveClicked ( ) [slot]

activityUiButtonSaveClicked is the function that is being called when the save button from the addActivityUi is clicked. 2.9.2.2

void AddPlanningController::addRow ( ) [private]

Adds a row to the grid from the addJobUi. 2.9.2.3

void AddPlanningController::connectBoxes ( ) [slot]

Connect all boxes that are added through the addRow button. In order to link the boxes we decided to just go through all boxes every time one changes TODO Making this more efficient is an option if time is left TODO remove query and use databaseActions


118

Class Documentation

2.9.2.4 void AddPlanningController::controlDateTime ( ) [slot]

controlDateTime makes shure that the entered endDate is after the entered startDate. 2.9.2.5 void AddPlanningController::createDefaultPlanning ( ) [private]

When a Job is created, the planningmodel can be entirely created. Every Job will get the default activities that belong to the specified traintype. All the requirement and resources are entered. TODO It is possible to enter two or more jobs with the same name. The application can handle this, but it isn’t smart as a user to create multiple jobs with the same name. Maybe let the application prevent this? TODO remove querys and use DatabaseActions. 2.9.2.6 bool AddPlanningController::existPlanning ( ) [private]

existPlanning checks if there exist already a give planning with the same values as being entered. Returns true iff there exist a planning with the given values, else return false.

2.9.2.7 bool AddPlanningController::existSameNames ( ) [private]

Returns true iff there is more then one job with the same name. Returns true iff more then one job exist with the same name

2.9.2.8 void AddPlanningController::fillGrid ( ) [private]

fillGrid fills the grid. This function makes sure that the headers of the grid are placed correctly and that the content of the grid is being filled with the right activities. 2.9.2.9 void AddPlanningController::fillGridContent ( ) [private]

fillGridContent fills the grid with the different QSpinBoxes. Each resource is being represented by a QSpinBox. The first column of the grid contains of checkboxes. These are used to select the activities for the selected job. If an activity is from the selected servicing from addJobUi then these activities are checked automatically. The second column of the grid contains a label with the activityname. Third column is a spinbox were you can adjust the duration. The next n columns (one for each resource) contains spinboxes the adjust the amount needed per resource (requirement). Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.9 AddPlanningController Class Reference

119

2.9.2.10 void AddPlanningController::fillGridHeaders ( ) [private]

fillGridHeaders fills the headers of the grid. These are the columnnames.

2.9.2.11

void AddPlanningController::fillListJob ( ) [private]

fillListJob fills the list with the available jobs.

2.9.2.12

void AddPlanningController::getDefaultServicingList ( ) [private]

getDefaultServicingList gets the default servicing for the first traintype. Without this function every addRow() call should query the database. TODO FIX remove this query and use databasActions

2.9.2.13

void AddPlanningController::getTrainTypes ( ) [private]

getTrainTypes gets the different types of trains from the database and saves it in a QList.

2.9.2.14

void AddPlanningController::initializeAddActivityUi ( ) [slot]

InitializeAddActivityUi have to be called to show the AddActivityUi.

2.9.2.15

void AddPlanningController::initializeAddJobUi ( ) [slot]

InitializeAddJobUi have to be called to show the AddJobUi.

2.9.2.16

void AddPlanningController::initializeAddPlanningUi ( ) [slot]

InitializeAddPlanningUi have to be called to show the AddPlanningUi.

2.9.2.17

void AddPlanningController::jobUiButtonAddRowClicked ( ) [slot]

jobUiButtonAddRowClicked is being called when the button ’Add Row’ is pressed from the addJobUi;

2.9.2.18

void AddPlanningController::jobUiButtonNextClicked ( ) [slot]

jobUiButtonNextClicked is being called when the button ’Next’ is pressed from the addJobUi; Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

120

Class Documentation

2.9.2.19

void AddPlanningController::planningUiButtonNextClicked ( ) [slot]

This action is called when the nextButton from the addPlanningUi has been clicked. When this happens there need to be checked if the given planning already exists. If so the user can’t add the given planning. If the given planning doesn’t exist the values from the fields are saved in the database. Also the enddate of the planning shouldn’t be before the startDate. The next screen will be showed. 2.9.2.20

void AddPlanningController::updateActivityGrid ( ) [slot]

updateActivityGrid is called when a user selects an other job from the list. If executed this function needs to 1. save the changed planning in the model 2. clear the addActivityUi screen 3. get the selected item from the list 4. build the new grid with the activities from the selected item. 2.9.2.21

void AddPlanningController::updatePlanning ( ) [private]

updatePlanning is being executed when a planning needs to be updated with new values. Everything that is entered in the grid have to be saved in the planningmodel. Requirements that didn’t exist before and exist at savingtime will be created with the given amount. 2.9.2.22

void AddPlanningController::writePlanningToDatabase ( ) [private]

Write the updated planning to the database The documentation for this class was generated from the following files: • addPlanningController.h • addPlanningController.cpp

2.10 AddPlanningUi Class Reference Public Member Functions • • • •

AddPlanningUi (AddPlanningController ∗, QWidget ∗) QDate getStartDate () QDate getEndDate () QString getName ()

Private Slots • void controlDate () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.10 AddPlanningUi Class Reference

121

Private Member Functions • • • • • •

void createButtons () void createDates () void createLabels () void createTextLines () void createLayouts () void createSignals ()

Private Attributes • • • • • • • • • • • • • • • • •

QPushButton ∗ nextButton QPushButton ∗ cancelButton QDateEdit ∗ startDate QDateEdit ∗ endDate QLabel ∗ titleLabel QLabel ∗ helpLabel QLabel ∗ startDateLabel QLabel ∗ endDateLabel QLabel ∗ nameLabel QVBoxLayout ∗ verticalLabelsLayout QVBoxLayout ∗ verticalDateBoxLayout QHBoxLayout ∗ dateAreaLayout QHBoxLayout ∗ buttonLayout QVBoxLayout ∗ totalLayout QLineEdit ∗ nameLine QWidget ∗ parent AddPlanningController ∗ addPlanningController

2.10.1


2.10.1.1

AddPlanningUi::AddPlanningUi ( AddPlanningController ∗ c, QWidget ∗ p )

Constructor for the addPlanningUi. When the constructor is called, we can already make and show the dialog. The contructor will call the methods that construct the various widgets on the screen.

2.10.2


2.10.2.1

void AddPlanningUi::createButtons ( ) [private]

creates the required buttons for this class 2.10.2.2

void AddPlanningUi::createDates ( ) [private]

creates the required dateboxes for this class Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

122

Class Documentation

2.10.2.3

void AddPlanningUi::createLabels ( ) [private]

creates the required labels for this class 2.10.2.4

void AddPlanningUi::createLayouts ( ) [private]

creates the required layouts for this class 2.10.2.5

void AddPlanningUi::createSignals ( ) [private]

creates the required signals for this class 2.10.2.6

void AddPlanningUi::createTextLines ( ) [private]

creates the required textlineedits for this class 2.10.2.7

QDate AddPlanningUi::getEndDate ( )

Returns the value of the field endDate return the value of the field endDate as a QDate

2.10.2.8

QString AddPlanningUi::getName ( )

Returns the value of the field name return the value of the field name as a QString 2.10.2.9

QDate AddPlanningUi::getStartDate ( )

Returns the value of the field startDate return the value of the field startDate as a QDate The documentation for this class was generated from the following files: • addPlanningUi.h • addPlanningUi.cpp

2.11 AddResourceUi Class Reference Public Member Functions • AddResourceUi (ResourceController ∗c, QWidget ∗p) • QString getName () • int getMaxCapacity () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.11 AddResourceUi Class Reference

123


void createButtons () void createLabels () void createLineEdit () void createSpinBox () void createLayouts () void createSignals ()

Private Attributes • • • • • • • • • • • •

QLabel ∗ labelTitle QLabel ∗ labelExplanation QLabel ∗ labelName QLabel ∗ labelMaxCapacity QPushButton ∗ buttonSave QPushButton ∗ buttonClose QLineEdit ∗ lineEditName QSpinBox ∗ spinBoxMaxCapacity QHBoxLayout ∗ hLayoutButtonContainer QFormLayout ∗ formLayout QVBoxLayout ∗ vLayoutMain ResourceController ∗ resourceController

2.11.1 Constructor & Destructor Documentation 2.11.1.1 AddResourceUi::AddResourceUi ( ResourceController ∗ c, QWidget ∗ p )

Creating a new AddResourceUi. Param ∗c, give the appropriate AddResourceController of this interface.

2.11.2 Member Function Documentation 2.11.2.1

void AddResourceUi::createButtons ( ) [private]

Creating all the required buttons for this interface. 2.11.2.2

void AddResourceUi::createLabels ( ) [private]

Creating all the required labels for this interface. 2.11.2.3

void AddResourceUi::createLayouts ( ) [private]

Creating all the required layouts for this interface. and set the layout of MainWindow to the final layout. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

124

Class Documentation

2.11.2.4

void AddResourceUi::createLineEdit ( ) [private]

Create all the required lineEdit. 2.11.2.5

void AddResourceUi::createSignals ( ) [private]


void AddResourceUi::createSpinBox ( ) [private]

Creating all the required spinbox. 2.11.2.7

int AddResourceUi::getMaxCapacity ( )

Return the maximal capacity this resource has Returns maximal capacity of new resource

2.11.2.8

QString AddResourceUi::getName ( )

Return the name of the new resource Returns name of new resource The documentation for this class was generated from the following files: • addResourceUi.h • addResourceUi.cpp

2.12 AddServicingUi Class Reference Public Slots • void clearForm ()

Public Member Functions • AddServicingUi (ServicingController ∗, QWidget ∗) • void addTrains (QStringList) • void addRow (QString) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.12 AddServicingUi Class Reference • • • • •

125

int getNumberOfRows () QString getSelectedTrain () QString getLineEdit () QWidget ∗ getWidget (int) void clearLineEdit ()


void createLayouts () void createLabels () void createLineEdit () void createComboBox () void createButtons () void createSignals ()


int numberOfRows QWidget ∗ parent QLabel ∗ titleLabel QLabel ∗ nameLabel QLineEdit ∗ nameLine QComboBox ∗ trainBox QPushButton ∗ cancelButton QPushButton ∗ saveButton QPushButton ∗ nextButton QVBoxLayout ∗ totalLayout QFormLayout ∗ formLayout QHBoxLayout ∗ infoLayout QHBoxLayout ∗ buttonLayout ServicingController ∗ controller

2.12.1


2.12.1.1

AddServicingUi::AddServicingUi ( ServicingController ∗ s, QWidget ∗ p )

Creates a Ui to add servicing, calls on all the appropriate methods to construct this ui Parameters p the parent of this dialog s the contoller that sends information to this widget


126

Class Documentation

2.12.2


2.12.2.1

void AddServicingUi::addRow ( QString activityDefaultName )

Adds a row to the formLayout. This row contains of a checkbox and a label with the provided QString Parameters activityDe- the name of the labal to be added in the row. faultName

2.12.2.2

void AddServicingUi::addTrains ( QStringList trainList )

Add a train to the comboBox with the different traintypes. Parameters trainList the name of the traintype to be added.

2.12.2.3

void AddServicingUi::clearForm ( ) [slot]

Clears the formlayout of this Ui. Removing all widgets and setting numberOfRows back to 0. 2.12.2.4

void AddServicingUi::clearLineEdit ( )

Removes the input from the lineEdit. 2.12.2.5

void AddServicingUi::createButtons ( ) [private]

Creates a close Button and save Button 2.12.2.6

void AddServicingUi::createComboBox ( ) [private]

Creates a comboBox that can be filled with traintypes 2.12.2.7

void AddServicingUi::createLabels ( ) [private]

Creates the labels required 2.12.2.8

void AddServicingUi::createLayouts ( ) [private]

Creates the appropriate layouts and adds widgets to these Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.12 AddServicingUi Class Reference 2.12.2.9 void AddServicingUi::createLineEdit ( ) [private]

Creates the linEdits needed to enter the name of a new servicing 2.12.2.10

void AddServicingUi::createSignals ( ) [private]

Creates signals and attaches them to buttons 2.12.2.11

QString AddServicingUi::getLineEdit ( )

Returns the values entered in the lineEdit field Returns the value of the lineEdit.

2.12.2.12

int AddServicingUi::getNumberOfRows ( )

Returns the number of rows the grid contains. Returns The number of rows the grid contains.

2.12.2.13

QString AddServicingUi::getSelectedTrain ( )

Returns the selected traintype Returns the selected traintype as a QString

2.12.2.14

QWidget ∗ AddServicingUi::getWidget ( int row )

getWidget returns the widget in the formlayout at position row, column. Returns QWidget that is positioned in the gridlayout at (row, column) The documentation for this class was generated from the following files: • addServicingUi.h • addServicingUi.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

127

128

Class Documentation

2.13 AddViewer Class Reference Public Member Functions • • • • • • •

AddViewer (ViewController ∗, QWidget ∗) void addNameLayout (NameHeader ∗) void addResourceNameLayout (ResourceHeader ∗) void addScheduleWidget (ScheduleWidget ∗) void addResourceWidget (ResourceWidget ∗) void addTimeLines () void listSpacers ()

Public Attributes • ViewController ∗ viewController

Private Slots • void moveSplitter ()


void createLayouts () void createScrollAreas () void createObjects () void createSplitters () void createSignals ()

Private Attributes • • • • • • • • • • • • • • •

QWidget ∗ nameHeader QWidget ∗ scheduleHeader QWidget ∗ resourceHeader QWidget ∗ resourceSchedule QWidget ∗ parent QSplitter ∗ splitJobResource QSplitter ∗ splitJobNameSchedule QSplitter ∗ splitResourceNameSchedule TimeLine ∗ t1 TimeLine ∗ t2 QVBoxLayout ∗ total QHBoxLayout ∗ jobsLayout QVBoxLayout ∗ jobsNameLayout QVBoxLayout ∗ jobsScheduleLayout QHBoxLayout ∗ resourceLayout Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.13 AddViewer Class Reference • • • • • •

129

QVBoxLayout ∗ resourceNameLayout QVBoxLayout ∗ resourceScheduleLayout QScrollArea ∗ jobsNameArea QScrollArea ∗ jobsScheduleArea QScrollArea ∗ resourceNameArea QScrollArea ∗ resourceScheduleArea

2.13.1


2.13.1.1

AddViewer::AddViewer ( ViewController ∗ c, QWidget ∗ p )

Constructor that assigns this ui class its controller and its parent widget Next calls on all methods required to set up widgets in this screen Parameters c the controller that create the addviewer p paret of this widget, when parent is closed this widget also closes

2.13.2


2.13.2.1 void AddViewer::addNameLayout ( NameHeader ∗ n )

Method called from outside the class to insert a nameHeader Parameters n received nameHeader to input into jobsNameArea

2.13.2.2 void AddViewer::addResourceNameLayout ( ResourceHeader ∗ r )

Method called from outside the class to insert a resourceHeader Parameters r received resourceHeader to input into resourceNameArea

2.13.2.3 void AddViewer::addResourceWidget ( ResourceWidget ∗ r )

method called from outside this class to insert a resourceWidget Parameters r received rsourceWidget to input into resourceScheduleArea


130 2.13.2.4

Class Documentation void AddViewer::addScheduleWidget ( ScheduleWidget ∗ s )

Method called from outside the class to insert a scheduleWidget Parameters s received scheduleWidget to input into jobsScheduleArea

2.13.2.5

void AddViewer::addTimeLines ( )

Method called from outside the class, receives two timelines to input into the layout of the schedule and resourceschedule 2.13.2.6

void AddViewer::createLayouts ( ) [private]

Creates the various layouts required, also adds margins and spacings to make sure the layout doesnt cross another layout 2.13.2.7

void AddViewer::createObjects ( ) [private]

Creates the objects that need to be entered into the scrollareas 2.13.2.8

void AddViewer::createScrollAreas ( ) [private]

Creates all the required qscrollareas that contains the information and the timelines Every scrollarea gets a widget assigned to it accept timeline scroller because it contains only one widget while the other scrollers contain multiple 2.13.2.9

void AddViewer::createSignals ( ) [private]

Creates the signals required to sync scrollerbars and splitters 2.13.2.10

void AddViewer::createSplitters ( ) [private]

Splits the screen in multiple views that can be made larger or smaller one splits resources and jobs, another splits nameheaders and associated schedules the last one splits resourceheaders and associated resourcerequirements 2.13.2.11

void AddViewer::listSpacers ( )

Method that is called from the controller and adds spacers after the widgets are added to create a nice layout Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.14 ColorGenerator Class Reference 2.13.2.12

131

void AddViewer::moveSplitter ( ) [private, slot]

Slot that tells one splitter how much the other splitter has moved and what its new position should be The documentation for this class was generated from the following files: • addViewer.h • addViewer.cpp

2.14

ColorGenerator Class Reference

Public Member Functions • ColorGenerator () • QColor next (int tid, QString name)

2.14.1


2.14.1.1

ColorGenerator::ColorGenerator ( )

Constructor of a color generator that generates random colors for activities each time it is made

2.14.2


2.14.2.1

QColor ColorGenerator::next ( int tid, QString name )

This method calculates a new random color if the tid and name combination entered does not already have one stored The color white is a special color in our application used for finished activities only, so this cannot be used. This color is 255,255,255 so whenever this appears get a new color When a color is generated at random that is already used recursively determine a new color till a free color is found Parameters tid the trainId of the job name the name of the activity Returns a new color or one that is already used if the tid/name combination is already used before The documentation for this class was generated from the following files: • colorGenerator.h • colorGenerator.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

132

Class Documentation

2.15 Constraint Class Reference Public Member Functions • Constraint (int jpreceeding, int preceeding, int jpreceeded, int preceeded) • void toString () • QString toSolveString ()

Public Attributes • • • •

int jpreceeding int preceeding int jpreceeded int preceeded

2.15.1


2.15.1.1

Constraint::Constraint ( int jpreceeding, int preceeding, int jpreceeded, int preceeded )

Creates a constraint with the given parameters Parameters jpreceeding preceeding jpreceeded preceeded

Jobid of the first activity the id of the first activity Jobid of the second activity the id of the second activity

2.15.2


2.15.2.1

QString Constraint::toSolveString ( )

toSolveString returns a QString of this constraint in the form needed for the solver. Returns QString that represents this constraint.

2.15.2.2

void Constraint::toString ( )

toString is used to test this constraint. It returns an output in the console of the given constraint. The documentation for this class was generated from the following files: • constraint.h Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.16 DatabaseActions Class Reference • constraint.cpp

2.16

DatabaseActions Class Reference

Public Member Functions • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

DatabaseActions (QObject ∗parent) void savePlanning (Planning ∗planning) Planning ∗ getPlanningFromDb (int pid) void saveResource (Resource ∗r) bool existResource (QString name) Resource ∗ getResourceByName (QString name) QList< Resource ∗ > getResources () void editResources () void editResource (Resource ∗r, QString oldName) int getTidByName (QString name) QStringList getTrainList () int addActivityDefault (ActivityDefault ∗a) QStringList getActivityDefaults (int tid) QStringList getActivityDefaultsByServicing (int tid, int sid) QStringList getActivityDefaultsNotByServicing (int tid, int sid) int getAdidByName (QString name, int tid) void addRequirementDefault (int adid, RequirementDefault ∗rd) bool existPlanning (QDate startDate, QDate endDate, QString name) QDate getFirstDateFromPlanningen () QDate getLastDateFromPlanningen () QStringList getPlanningList () QStringList getPlanningList (QString, QDate, QDate) int getPidFromName (QString name, QString startDate, QString endDate) void removePlanningFromDb (int pid) int saveServicingName (int tid, QString name) void saveServicing (int sid, int tid, QString name) bool existServicing (int tid, QString name) QStringList getServicing (int tid) void removeServicing (int tid, QString servicingName) void removeServicing (int sid, int tid, QString name) int getSidByName (QString name, int tid)


void saveJobs () void saveActivities (Job ∗job) void saveRequirement (Activity ∗activity, int j) void saveConstraints () void getJobsFromDb ()


133

134

Class Documentation • void getActivitiesFromDb (Job ∗job) • void getRequirementsFromDb (Activity ∗activity) • void getConstraintsFromDb ()

Private Attributes • Planning ∗ planning • int pid

2.16.1


2.16.1.1

DatabaseActions::DatabaseActions ( QObject ∗ parent )

Create a new DatabaseActions with the given parent.

2.16.2


2.16.2.1

int DatabaseActions::addActivityDefault ( ActivityDefault ∗ a )

Adds the provided activityDefault to the database and returns the given id of this activityDefault Returns the id of this activityDefault that is inserted into the database.

2.16.2.2

void DatabaseActions::addRequirementDefault ( int adid, RequirementDefault ∗ rd )

Adds a new requirementDefault to the database Parameters adid the activityDefault id of this requirement rd the default requirement that needs to be saved.

2.16.2.3

void DatabaseActions::editResource ( Resource ∗ r, QString oldName )

editResource updates a resource to new values. Parameters ∗r the new resource oldName the name of the old resource.


2.16 DatabaseActions Class Reference

135

2.16.2.4 void DatabaseActions::editResources ( )

editResource updates all the resources in the database. 2.16.2.5 bool DatabaseActions::existPlanning ( QDate startDate, QDate endDate, QString name )

Exist there a planning with the given parameters. Parameters startDate the startDate of the requested planning. endDate the endDate of the requested planning. name the name of the requested planning. Returns true iff there exist a planning with the given parameters, else false.

2.16.2.6

bool DatabaseActions::existResource ( QString name )

existResource checks if there exist a resource with the given name in the database Parameters name the name of the resource to be checked Returns true iff there exist a resource with name name in the database else false.

2.16.2.7

bool DatabaseActions::existServicing ( int tid, QString name )

Checks if there exist a servicing with the given tid and name Parameters tid the tid of the requested servicing name the name of the requested servicing

2.16.2.8 void DatabaseActions::getActivitiesFromDb ( Job ∗ job ) [private]

getActivitiesFromDb saves all the activities from job in the planning Parameters job the job from which the activities need to be saved.


136

Class Documentation

2.16.2.9

QStringList DatabaseActions::getActivityDefaults ( int tid )

Get all the activities that belongs to the provided tid. Parameters tid the trainId from which the activities are requested. Returns List with all the available default activities.

2.16.2.10

QStringList DatabaseActions::getActivityDefaultsByServicing ( int tid, int sid )

Get all the activities that belongs to the provided tid and sid. Parameters tid the trainId from which the activities are requested. sid the servicingId from which the activities are requested. Returns List with all the available default activities.

2.16.2.11

QStringList DatabaseActions::getActivityDefaultsNotByServicing ( int tid, int sid )

Get all the activities that don’t belong to the provided sid but belongs to the provided tid. Parameters tid the trainId from which the activities are requested. sid the servicingId from which the activities are requested. Returns List with all the available default activities.

2.16.2.12

int DatabaseActions::getAdidByName ( QString name, int tid )

Returns the adid of the provided default activity. Parameters name the name of the activity; tid the trainId of the activity;



137

Returns the adid of this default activity.

2.16.2.13

void DatabaseActions::getConstraintsFromDb ( ) [private]

getConstraintsFromDb saves all the contraints from the planning in the planning. 2.16.2.14

QDate DatabaseActions::getFirstDateFromPlanningen ( )

Returns the first startDate of the table planning. Returns QDate of the first startDate.

2.16.2.15

void DatabaseActions::getJobsFromDb ( ) [private]

getJobsFromDb saves all the jobs from the planning in the planning. 2.16.2.16

QDate DatabaseActions::getLastDateFromPlanningen ( )

Returns the last endDate of the table planning. Returns QDate of the last endDate.

2.16.2.17

int DatabaseActions::getPidFromName ( QString name, QString start, QString end )

getPidFromName returns the first pid that is found by the given name, startDate and endDate Parameters name QString from the planning name start QString of the startdate of the planning. Represented as dd-MM-yyyy. end QString of the enddate of the planning. Represented as dd-MM-yyyy.

Returns int the pid of the planning with the provided name, startDate and endDate.


138

Class Documentation

2.16.2.18 Planning ∗ DatabaseActions::getPlanningFromDb ( int pid )

getPlanningFromDb returns the planning with pid from the database. The entire planning will be returned in a Planning∗ object. Parameters pid the pid from the required planning. Returns Planning∗ of the planning with id pid

2.16.2.19

QStringList DatabaseActions::getPlanningList ( )

getPlanning returns a list of all available planning ∗ Returns QStringList with the list of all available plannings

2.16.2.20 QStringList DatabaseActions::getPlanningList ( QString name, QDate start, QDate end )

getPlanning returns a list of all available planning, where name LIKE ’name∗’ and startdate >= start and enddate <= end Parameters name the name of the requested plannings. There will be looked up with a wildcard. start the startdate of the requested plannings end the enddate of the requested plannings. Returns QStringList with the list of all available plannings

2.16.2.21

void DatabaseActions::getRequirementsFromDb ( Activity ∗ activity )

[private]

getRequirementsFromDb saves all the requirements from activity in the planning Parameters activity the activity from which the requirements need to be saved.



139

2.16.2.22 Resource ∗ DatabaseActions::getResourceByName ( QString name )

getResourceByName returns the resource that belongs to the provided name. Parameters name the name of the resource. Returns the resource of the provided resourceName.

2.16.2.23

QList< Resource ∗ > DatabaseActions::getResources ( )

getResources returns a list with all available resources. Returns a list with all available resources in the database.

2.16.2.24

QStringList DatabaseActions::getServicing ( int tid )

Returns a list with all available servicings for this kind of train. Parameters tid the trainid of which the servicings are requested. Returns QStringList with all the available servicings.

2.16.2.25

int DatabaseActions::getSidByName ( QString name, int tid )

Get the sid of the servicing with the given name and tid Parameters name the name of the servicing tid the tid of the servicing Returns the id of the servicing or -1 if there isn’t a servicing with the given parameters.

2.16.2.26

int DatabaseActions::getTidByName ( QString trainName )

Returns the tid of the train with the provided name Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

140

Class Documentation

Returns the id of this type of train

2.16.2.27

QStringList DatabaseActions::getTrainList ( )

Returns a list of all the traintypes Returns a QStringlist with all the traintypes

2.16.2.28

void DatabaseActions::removePlanningFromDb ( int p )

removePlanningFromDb removes the given planning from the database Parameters p the pid of the planning that needs to be removed

2.16.2.29

void DatabaseActions::removeServicing ( int tid, QString servicingName )

Removes the servicing with the given parameters. Servicing is removed from the table servicing and servicingName. ActivityDefaults aren’t removed because those can be used by other servicings. Parameters tid the id of the train the servicing belongs to. servicing- the name of the servicing that needs to be removed. Name

2.16.2.30

void DatabaseActions::removeServicing ( int sid, int tid, QString name )

Remove the provided servicing from the database Parameters sid the id of the servicing tid the id of the train that belongs to this servicing name the name of the servicing to be removed.

2.16.2.31

void DatabaseActions::saveActivities ( Job ∗ job ) [private]

saveActivities saves the activities of job Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen


141

Parameters ∗job the activities of job needs to be saved.

2.16.2.32

void DatabaseActions::saveConstraints ( ) [private]

saveConstraints saves the constraints from a planning to the database. 2.16.2.33

void DatabaseActions::saveJobs ( ) [private]

saveJobs saves the jobs from the planning in the database. 2.16.2.34

void DatabaseActions::savePlanning ( Planning ∗ p )

savePlanning save the planning in the database. After the planning is saved the jobs will be saved. Parameters ∗p the Planning to be saved

2.16.2.35

void DatabaseActions::saveRequirement ( Activity ∗ activity, int j )

[private]

saveRequirement saves the requirement of activity Parameters ∗activity the requirements of activity needs to be saved.

2.16.2.36

void DatabaseActions::saveResource ( Resource ∗ r )

saveResource saves the resource in the database. After the resource is saved Parameters ∗r the Resource to be saved

2.16.2.37

void DatabaseActions::saveServicing ( int sid, int tid, QString name )

saves the service to the database. Parameters sid the sid of the service tid the id of the train this servicing belongs to name the name of the activity that needs to be added to the servicing Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

142

Class Documentation

2.16.2.38

int DatabaseActions::saveServicingName ( int tid, QString name )

This function saves the servicingName to the database Parameters tid trainid of to where this servicing belongs to. name string of the name of this servicing Returns the int of the inserted servicingName The documentation for this class was generated from the following files: • • • • • • • • • •

databaseActions.h activityDefaultDb.cpp databaseActions.cpp getPlanningFromDb.cpp planningDb.cpp requirementDefaultDb.cpp resourceDb.cpp savePlanningToDb.cpp servicingDb.cpp trainDb.cpp

2.17 databaseConnector Class Reference Public Member Functions • databaseConnector () • bool connectDb () • void disconnectDb ()

2.17.1


2.17.1.1

databaseConnector::databaseConnector ( )

Create a databaseConnector

2.17.2


2.17.2.1

bool databaseConnector::connectDb ( )

connectDb opens a connection with the initialized database. If the functions fails to connect to the database a messagebox with the error being displayed. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.18 EditResourceUi Class Reference

143

Returns true iff connection is made, else false

2.17.2.2

void databaseConnector::disconnectDb ( )

disconnectDB closes the connection. After the database is closed, it will be removed from the connectionlist. The documentation for this class was generated from the following files: • databaseConnector.h • databaseConnector.cpp

2.18

EditResourceUi Class Reference

Public Member Functions • • • • •

EditResourceUi (ResourceController ∗c, QWidget ∗p) QString getNameAt (int row) int getMaxCapacityAt (int row) void addWidget (QString name, int maxCapacity) int getNumberOfRows ()


void createButtons () void createLabels () void createLayouts () void createSignals ()

Private Attributes • • • • • • • • •

int numberOfRows QLabel ∗ labelTitle QLabel ∗ labelExplanation QPushButton ∗ buttonUpdate QPushButton ∗ buttonClose QHBoxLayout ∗ hLayoutButtonContainer QFormLayout ∗ formLayout QVBoxLayout ∗ vLayoutMain ResourceController ∗ resourceController


144

Class Documentation

2.18.1


2.18.1.1

EditResourceUi::EditResourceUi ( ResourceController ∗ c, QWidget ∗ p )

Creates an edit resource screen that gets a controller and a parent, calls on all methods required to fill this screen Parameters c the controller that creates this class p parent of this class, whenever the parent gets closed so does this class

2.18.2


2.18.2.1

void EditResourceUi::addWidget ( QString name, int maxCapacity )

Method that is used to fill the screen with the resources available, also adds a new row for every resources that contains all information Parameters name the name of this resource maxCapac- the maximal capacity of this resource ity

2.18.2.2

void EditResourceUi::createButtons ( ) [private]

Creates the rewuired buttons 2.18.2.3

void EditResourceUi::createLabels ( ) [private]

Creates the required labels 2.18.2.4

void EditResourceUi::createLayouts ( ) [private]

Creates the required layouts 2.18.2.5

void EditResourceUi::createSignals ( ) [private]

Creates the required signals for this class 2.18.2.6

int EditResourceUi::getMaxCapacityAt ( int row )

Returns the maximum capacity that resource can have in a planning Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.19 EditServicingUi Class Reference Parameters row parameter that tells this class the capacity of which row is required Returns an integer representing the max capacity of that resource

2.18.2.7

QString EditResourceUi::getNameAt ( int row )

Returns the name of the resource at the specified row Parameters row parameter that tells this class the name of which row is required Returns a string containing the name of the resource in that row

2.18.2.8

int EditResourceUi::getNumberOfRows ( )

getNumberOfRows returns the number of rows in the formLayout Returns the number of rows in the formLayout The documentation for this class was generated from the following files: • editResourceUi.h • editResourceUi.cpp

2.19

EditServicingUi Class Reference

Public Member Functions • • • • • • • • • •

EditServicingUi (ServicingController ∗c, QWidget ∗p) void addTrainItems (QStringList trainList) void addServicingItems (QStringList servicingList) void addRow (bool checked, QString activityName) QString getSelectedTrain () QString getSelectedServicing () int getNumberOfRows () QString getActivityDefault (int row) void clearServicingItems () void clearFormLayoutDown ()


145

146

Class Documentation


void createButtons () void createLabels () void createLists () void createComboBox () void createLayouts () void createSignals ()

Private Attributes • • • • • • • • • • • • • • •

int numberOfRows QPushButton ∗ buttonUpdate QPushButton ∗ buttonClose QLabel ∗ labelTitle QLabel ∗ labelExplanation QLabel ∗ labelTrain QLabel ∗ labelServicing QComboBox ∗ comboBoxTrain QComboBox ∗ comboBoxServicing QVBoxLayout ∗ vLayoutMain QHBoxLayout ∗ hLayoutButtonContainer QHBoxLayout ∗ hLayout QFormLayout ∗ formLayoutTop QGridLayout ∗ gridLayoutDown ServicingController ∗ servicingController

2.19.1


2.19.1.1

EditServicingUi::EditServicingUi ( ServicingController ∗ c, QWidget ∗ p )

Create a new EditServicingUi. Parameters ∗c give the appropriate servicingController of this interface. ∗p the parent of this ui.

2.19.2


2.19.2.1

void EditServicingUi::addRow ( bool checked, QString activityName )

Adds a row to the formLayoutDown. This row contains of a checkbox and a label. Parameters checked true iff the activity belongs to the servicing, else false. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.19 EditServicingUi Class Reference

activity- the name of the activity Name

2.19.2.2 void EditServicingUi::addServicingItems ( QStringList servicingList )

Adds the provided item to the comboBoxServicing. Parameters servicingList QString that contains the list of trains.

2.19.2.3 void EditServicingUi::addTrainItems ( QStringList trainList )

Adds the provided item to the comboBoxTrain. Parameters trainList QString that contains the list of trains.

2.19.2.4 void EditServicingUi::clearFormLayoutDown ( )

Clears the formLayoutDown so that new rows can be added.

2.19.2.5 void EditServicingUi::clearServicingItems ( )

Clears the list with servicingItems.

2.19.2.6 void EditServicingUi::createButtons ( ) [private]

Creating all the required buttons for this interface.

2.19.2.7

void EditServicingUi::createComboBox ( ) [private]

Creating all the required comboboxes for this interface.

2.19.2.8

void EditServicingUi::createLabels ( ) [private]

Creating all the required labels for this interface. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

147

148

Class Documentation

2.19.2.9

void EditServicingUi::createLayouts ( ) [private]

Creating all the required layouts for this interface. and set the layout of this ui to the final layout. 2.19.2.10

void EditServicingUi::createSignals ( ) [private]


QString EditServicingUi::getActivityDefault ( int row )

Returns the text of the label Parameters row the row of the requested label Returns the text from the label if the checkbox is checked else return ""

2.19.2.12

int EditServicingUi::getNumberOfRows ( )

Returns the number of rows in the formLayoutDown. 2.19.2.13

QString EditServicingUi::getSelectedServicing ( )

Returns the name of the selected servicing. Returns the selected servicingName.

2.19.2.14

QString EditServicingUi::getSelectedTrain ( )

Returns the name of the selected train. Returns the selected trainName. The documentation for this class was generated from the following files: • editServicingUi.h • editServicingUi.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.20 Job Class Reference

149

2.20 Job Class Reference Public Member Functions • Job (QString name, QDateTime startDate, QDateTime endDate, int servicingId, int trainId, int id, QObject ∗parent) • Activity ∗ getActivity (QString) • QDateTime getEndTime () • int getId () • QString getName () • int getServicingId () • QDateTime getStartTime () • int getTrainId () • void setEndTime (QDateTime) • void setId (int) • void setName (QString) • void setServicingId (int) • void setStartTime (QDateTime) • void setTrainId (int) • void addActivity (Activity ∗) • void toString () • QString toSolveString (QDate planningStartTime)

Public Attributes • QList< Activity ∗ > activities

Private Attributes • • • • • •

QString name QDateTime startTime QDateTime endTime int id int trainId int servicingId

2.20.1


2.20.1.1

Job::Job ( QString name, QDateTime startTime, QDateTime endTime, int servicingId, int trainId, int id, QObject ∗ parent )

Create a new Job with the provided parameters. Parameters name QString of the name; Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

150

Class Documentation

startTime endTime servicingId trainId

QDateTime of the startTime; QDateTime of the endTime; int of the servicingId. This is the default list of activities on this job; int of the trainId. Together with the servicingId we can determine what the activities for this train are; id int of the id for this job. parent QObject of the parent for this job. This will be the planning.

2.20.2


2.20.2.1

void Job::addActivity ( Activity ∗ newActivity )

addActivity adds the provided Activity to this job. Parameters newActivity the new Activity to be added. newActivity != NULL

2.20.2.2 Activity ∗ Job::getActivity ( QString name )

getActivity returns the activity from this job with the provided name. Parameters name the name of the requested activity. name != ""

2.20.2.3

QDateTime Job::getEndTime ( )

getEndTime returns the endTime of this job. Returns endTime of the job.

2.20.2.4

int Job::getId ( )

getId returns the id of this job. Returns id of the job

2.20.2.5

QString Job::getName ( )

getName returns the name of this job. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.20 Job Class Reference Returns name of the job.

2.20.2.6

int Job::getServicingId ( )

getServicingId returns the servicingId of this job. Returns servicingId of the job.

2.20.2.7

QDateTime Job::getStartTime ( )

getStartTime returns the startTime of this job. Returns startTime of the job.

2.20.2.8

int Job::getTrainId ( )

getTrainId returns the trainId of this job. Returns trainId of the job.

2.20.2.9

void Job::setEndTime ( QDateTime newEndTime )

setEndTime sets the endTime of this job to the provided endTime. Parameters newEndTime QDateTime of the new endTime

2.20.2.10

void Job::setId ( int newId )

setId set the id of this job to the provided i. Parameters newId int of the new id, newId >= 0


151

152

Class Documentation

2.20.2.11

void Job::setName ( QString newName )

setName sets the name of this job to the provided name. Parameters newName QString of the new name, newName != "".

2.20.2.12

void Job::setServicingId ( int newServicingId )

setServicingId set the servicingId of this job to the provided servicingId. Parameters newSer- int of the new servicingId, newServicingId > 0 vicingId

2.20.2.13

void Job::setStartTime ( QDateTime newStartTime )

setStartTime sets the startTime of this job to the provided startTime. Parameters newStart- QDateTime of the new startTime Time

2.20.2.14

void Job::setTrainId ( int newTrainId )

setTrainId set the trainId of this job to the provided trainId. Parameters newTrainId int of the new trainId, newTrainId > 0

2.20.2.15

QString Job::toSolveString ( QDate planningStartTime )

toSolveString returns a QString of this job in the form needed for the solver. Parameters plan- QDate that indicates the startTime of the planning. ningStartTime Returns result that gives this job back as a stringrepresentation.


2.21 MainWindow Class Reference 2.20.2.16

void Job::toString ( )

toString returns a qDebug output of this Job.

2.20.3


2.20.3.1 QList Job::activities

List of activities that this job contains. The documentation for this class was generated from the following files: • job.h • job.cpp

2.21

MainWindow Class Reference

Public Slots • void planningOpened () • void resetViewerOptions ()

Public Member Functions • MainWindow ()

Private Member Functions • void createActions () • void createMenus ()

Private Attributes • • • • • • • • • • •

QMenu ∗ fileMenu QAction ∗ showPlanningAction QAction ∗ saveAction QAction ∗ saveAsAction QAction ∗ closePlanning QAction ∗ exitAction QMenu ∗ editMenu QAction ∗ planningAddAction QAction ∗ planningRemoveAction QAction ∗ addResourceAction QAction ∗ editResourceAction


153

154

Class Documentation • QAction ∗ addActivityDefaultAction • QAction ∗ addServicingAction • QAction ∗ editServicingAction

• QAction ∗ removeServicingAction • QMenu ∗ solverMenu

• QAction ∗ solveAction

• QAction ∗ aboutQtAction • QMenu ∗ helpMenu

• ViewController ∗ viewController

• ResourceController ∗ resourceController

• RemovePlanningController ∗ removePlanningController

• AddPlanningController ∗ addPlanningController

• ActivityDefaultController ∗ activityDefaultController • ServicingController ∗ servicingController

2.21.1


2.21.1.1

MainWindow::MainWindow ( )

Constructs a mainwindow, creates all controllers that are needed to use the various functions of the program Also calls the functions to create menus and actions attached to these menus

2.21.2


2.21.2.1

void MainWindow::createActions ( ) [private]

Creates the various actions that are needed and connects these to methods

2.21.2.2

void MainWindow::createMenus ( ) [private]

Creates the various menus and connects actions to these menus

2.21.2.3

void MainWindow::planningOpened ( ) [slot]

When a planning is opened the menuoptions Save and Solve should be enabled. The documentation for this class was generated from the following files: • mainwindow.h • mainwindow.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.22 NameHeader Class Reference

155

2.22 NameHeader Class Reference Public Slots • void changeNrOfActivities (int)

Signals • void expandedHeader (bool)

Public Member Functions • NameHeader (QWidget ∗, QString, int)

Private Slots • void expand (bool)


void createLayouts () void createButtons () void createLabels (QString) void paintEvent (QPaintEvent ∗) void createSignals () QSize sizeHint () const


QHBoxLayout ∗ layout QPushButton ∗ expandButton QLabel ∗ nameLabel bool expanded int nrOfWidgets

2.22.1


2.22.1.1

NameHeader::NameHeader ( QWidget ∗ p, QString name, int w )

Creates a new nameheader widget that contains a namelabel and needs to know the number of activities its corresponding job contains so that after the expandButton is pushed the geometry can be updates correctly Parameters Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

156

Class Documentation

p parent of this widget, when the parent is closed this also closes name the Name of the job that this widget represents w the numberOfActivities the job has

2.22.2


2.22.2.1

void NameHeader::changeNrOfActivities ( int nr ) [slot]

method to update the number of activities in the job Parameters nr the nr of activities curretly in the job

2.22.2.2

void NameHeader::createButtons ( ) [private]

Create the expandButton 2.22.2.3

void NameHeader::createLabels ( QString name ) [private]

Create the nameLabel 2.22.2.4

void NameHeader::createLayouts ( ) [private]

Create layout to add label and button 2.22.2.5

void NameHeader::createSignals ( ) [private]

When expandButton is pushed, expand this header and send a signal to the corresponding scheduleWidget 2.22.2.6

void NameHeader::expand ( bool e ) [private, slot]

Change the text in the button after being pushed and update the geometry to resize the this Parameters e boolean is true if button pushed and false if button pushed a second time

2.22.2.7

void NameHeader::paintEvent ( QPaintEvent ∗ e ) [private]

Draw the line that seperates this header from the following Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.23 Planning Class Reference Parameters e the paintevent that is called whenever the object needs updating

2.22.2.8 QSize NameHeader::sizeHint ( ) const [private]

recommended size for this widget The documentation for this class was generated from the following files: • nameHeader.h • nameHeader.cpp

2.23

Planning Class Reference

Public Member Functions • • • • • • • • • • • •

Planning (QObject ∗) void toString () void setName (QString) QString getName () void setStartDate (QDate) QDate getStartDate () void setEndDate (QDate) QDate getEndDate () void addJob (Job ∗) void addConstraint (Constraint ∗) void addResource (Resource ∗) Resource ∗ getResource (QString)

Public Attributes • QList< Job ∗ > jobs • QList< Constraint ∗ > constraints • QList< Resource ∗ > resources

Private Attributes • QString name • QDate startDate • QDate endDate Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

157

158

Class Documentation

2.23.1


2.23.1.1

Planning::Planning ( QObject ∗ parent )

Creates a new Planning object. A QObject is needed as parent. When a planning is being created it also adds all the resources to this planning.

2.23.2


2.23.2.1

void Planning::addConstraint ( Constraint ∗ newConstraint )

addConstraint adds the provided Constraint to this planning Parameters newCon- the Constraint that needs to be added. straint

2.23.2.2

void Planning::addJob ( Job ∗ newJob )

addJob adds the given job to the list. Parameters newJob Job∗ to be added to this planning.

2.23.2.3

void Planning::addResource ( Resource ∗ newResource )

addResource adds the provided Resource to this planning Parameters newRe- the Resource that needs to be added. source

2.23.2.4

QDate Planning::getEndDate ( )

getName returns a QDate from this planning its endDate. Returns endDate of this planning

2.23.2.5

QString Planning::getName ( )

getName returns a QString from this planning its name. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.23 Planning Class Reference Returns name of this planning

2.23.2.6 Resource ∗ Planning::getResource ( QString name )

getResource returns the Resource with the provided name. Parameters name QString of the name of the required Resource. Returns the resource of the given name

2.23.2.7

QDate Planning::getStartDate ( )

getName returns a QDate from this planning its startDate. Returns startDate of this planning

2.23.2.8

void Planning::setEndDate ( QDate newEndDate )

setEndDate sets the endDate of this planning to the provided QDate. Parameters newEndDate QDate of the new endDate for this planning

2.23.2.9 void Planning::setName ( QString newName )

setName sets the name of this planning to the provided QString Parameters newName QString of the new name for this planning.

2.23.2.10

void Planning::setStartDate ( QDate newStartDate )

setStartDate sets the startDate of this planning to the provided QDate. Parameters


159

160

Class Documentation

newStart- QDate of the new startDate for this planning Date

2.23.2.11

void Planning::toString ( )

toString is used to test this planning. It returns an output in the console of this planning.

2.23.3


2.23.3.1

QList Planning::constraints

List of constraints that this Planning contains. 2.23.3.2

QList<Job∗> Planning::jobs

List of jobs that this Planning contains. 2.23.3.3

QList Planning::resources

List of resources that this Planning contains. The documentation for this class was generated from the following files: • planning.h • planning.cpp

2.24 ProgressUi Class Reference Public Slots • void updateProgress (int)

Public Member Functions • ProgressUi ()

Private Member Functions • void createProgressBar () • void createLayout () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.25 RemovePlanningController Class Reference

Private Attributes • QProgressBar ∗ progressBar • QHBoxLayout ∗ horizontalLayout

2.24.1


2.24.1.1 ProgressUi::ProgressUi ( )

Creates a progressUi.

2.24.2


2.24.2.1 void ProgressUi::createLayout ( ) [private]

Create the layout for this dialog. 2.24.2.2

void ProgressUi::createProgressBar ( ) [private]

Creates the progressBar. 2.24.2.3

void ProgressUi::updateProgress ( int value ) [slot]

Set the progressBar to the given percentage Parameters value the new percentage that the progressBar needs to show. The documentation for this class was generated from the following files: • progressUi.h • progressUi.cpp

2.25

RemovePlanningController Class Reference

Public Slots • void initializeRemovePlanningUi () • void buttonRemoveClicked ()

Public Member Functions • RemovePlanningController (QWidget ∗) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

161

162

Class Documentation


bool removePlanningCheck () void fillList () void removeSelectedPlanning (QString) QString getSelectedItem ()

Private Attributes • RemovePlanningUi ∗ removePlanningUi • QWidget ∗ parent

2.25.1


2.25.1.1

RemovePlanningController::RemovePlanningController ( QWidget ∗ p )

RemovePlanningController.cpp Created on: 11 mei 2011 Author: ebruurs Constructor for the RemovePlanningController. When the constructor is called, we can already make and show the dialog. The list of the different plannings are showed. Parameters ∗p QWidget of the parent, mostly mainWindow

2.25.2


2.25.2.1

void RemovePlanningController::buttonRemoveClicked ( ) [slot]

This action is called when the button_remove from the removePlanningUi has been clicked. When this happens there need to be a warning to the user. The user then needs to confirm he definitively wants to remove the selected planning. After the user clicked ’Yes’ the selected planning is from the database removed. If clicked No nothing will happen.

2.25.2.2

void RemovePlanningController::fillList ( ) [private]

fillList() executes the query to select all available plannings. The results are converted to a QString which is being added to the list, with addItem from the class removePlanningUi.

2.25.2.3

QString RemovePlanningController::getSelectedItem ( ) [private]

Returns the selected planning to be removed from the removePlanningUi. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.26 RemovePlanningUi Class Reference

163

Returns QString, the selected planning to be removed.

2.25.2.4

void RemovePlanningController::initializeRemovePlanningUi ( ) [slot]

Initialize the ui to remove a planning. 2.25.2.5

bool RemovePlanningController::removePlanningCheck ( ) [private]

Shows a QMessageBox to ask the user if he definitively wants to remove the selected item. If ’Yes’ is pressed the selected item will be removed, if ’No’ is selected the user will return to the window with the list of plannings. Returns true iff the planning can be removed, else false.

2.25.2.6

void RemovePlanningController::removeSelectedPlanning ( QString selectedItem )

[private] Removes the selected planning from the database. Parameters selectedItem QString of the item to be removed. The documentation for this class was generated from the following files: • removePlanningController.h • removePlanningController.cpp

2.26

RemovePlanningUi Class Reference

Public Member Functions • • • •

RemovePlanningUi (RemovePlanningController ∗, QWidget ∗) void addItem (QStringList) QString getItem () int getNumberOfRows ()

Private Member Functions • void createButtons () • void createLabels () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

164

Class Documentation • void createLists () • void createLayouts () • void createSignals ()


QPushButton ∗ buttonRemove QPushButton ∗ buttonClose QLabel ∗ labelTitle QLabel ∗ labelExplanation QVBoxLayout ∗ vLayoutMain QHBoxLayout ∗ hLayoutButtonContainer QListView ∗ listSummary QStringListModel ∗ model RemovePlanningController ∗ removePlanningController

2.26.1


2.26.1.1

RemovePlanningUi::RemovePlanningUi ( RemovePlanningController ∗ c, QWidget ∗ p )

Creating a new RemovePlanningUi. Parameters ∗c give the appropriate removePlanningController of this interface. ∗p the parent of this Ui

2.26.2


2.26.2.1

void RemovePlanningUi::addItem ( QStringList list )

Adds the provided item to the list. param item QString that contains an item displayed in the list

2.26.2.2

void RemovePlanningUi::createButtons ( ) [private]

Creating all the required buttons for this interface.

2.26.2.3

void RemovePlanningUi::createLabels ( ) [private]

Creating all the required labels for this interface. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.27 RemoveServicingUi Class Reference

165

2.26.2.4 void RemovePlanningUi::createLayouts ( ) [private]


void RemovePlanningUi::createLists ( ) [private]

Creating all the required lists for this interface. 2.26.2.6

void RemovePlanningUi::createSignals ( ) [private]


QString RemovePlanningUi::getItem ( )

Returns a QString of the selected item. return QString, the selected item. 2.26.2.8

int RemovePlanningUi::getNumberOfRows ( )

Returns the number of rows that the list contains The documentation for this class was generated from the following files: • removePlanningUi.h • removePlanningUi.cpp

2.27

RemoveServicingUi Class Reference


RemoveServicingUi (ServicingController ∗c, QWidget ∗p) void addItem (QStringList) void addItems (QStringList) QString getItem () QString getSelectedTrain ()


void createButtons () void createLabels () void createLists () void createComboBox () void createLayouts () void createSignals ()


166

Class Documentation

Private Attributes • • • • • • • • • •

QPushButton ∗ buttonRemove QPushButton ∗ buttonClose QLabel ∗ labelTitle QLabel ∗ labelExplanation QComboBox ∗ comboBoxTrain QVBoxLayout ∗ vLayoutMain QHBoxLayout ∗ hLayoutButtonContainer QListView ∗ listSummary QStringListModel ∗ model ServicingController ∗ servicingController

2.27.1


2.27.1.1

RemoveServicingUi::RemoveServicingUi ( ServicingController ∗ c, QWidget ∗ p )

Creating a new RemoveServicingUi. Parameters ∗c give the appropriate servicingController of this interface. ∗p the parent of this ui.

2.27.2


2.27.2.1

void RemoveServicingUi::addItem ( QStringList list )

Adds the provided item to the list. Parameters list QString that contains an item displayed in the list

2.27.2.2

void RemoveServicingUi::addItems ( QStringList list )

Adds the provided items to the comboBox. Parameters list QString that contains an item displayed in the comboBox

2.27.2.3

void RemoveServicingUi::createButtons ( ) [private]

Creating all the required buttons for this interface. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.27 RemoveServicingUi Class Reference

167

2.27.2.4 void RemoveServicingUi::createComboBox ( ) [private]

Creating all the required comboboxes for this interface. 2.27.2.5

void RemoveServicingUi::createLabels ( ) [private]


void RemoveServicingUi::createLayouts ( ) [private]


void RemoveServicingUi::createLists ( ) [private]

Creating all the required lists for this interface. 2.27.2.8

void RemoveServicingUi::createSignals ( ) [private]


QString RemoveServicingUi::getItem ( )

Returns a QString of the selected item. Returns QString, the selected item.

2.27.2.10

QString RemoveServicingUi::getSelectedTrain ( )

Returns the selected index of the combobox. Returns the id of the selected train. This is the index of the combobox + 1. Since the database starts with id = 1 and the combobox start with index = 0. The documentation for this class was generated from the following files: • removeServicingUi.h • removeServicingUi.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

168

Class Documentation

2.28 Requirement Class Reference Public Member Functions • • • • • • •

Requirement (Resource ∗resource, int amount) Resource ∗ getResource () void setResource (Resource ∗) int getAmount () void setAmount (int) void toString () QString toSolveString (int jid, int aid)

Private Attributes • int amount • Resource ∗ resource

2.28.1


2.28.1.1

Requirement::Requirement ( Resource ∗ resource, int amount )

Creates a Requirement with the given parameters Parameters resource the requirement is about this resource amount the amount of capacity required of this resource by this activity

2.28.2


2.28.2.1

int Requirement::getAmount ( )

getAmount returns the amount of resources required by this requirement. Returns the amount of resources required by this requirement.

2.28.2.2 Resource ∗ Requirement::getResource ( )

getResource returns the resource of this requirement Returns the resource of this requirement.


2.29 RequirementDefault Class Reference

169

2.28.2.3 void Requirement::setAmount ( int amount )

setAmount sets the amount of required resources by this requirement. Parameters amount the amount to be set.

2.28.2.4 void Requirement::setResource ( Resource ∗ r )

setResource sets the resource for this requirement. Parameters r the resource to be set. r != NULL

2.28.2.5 QString Requirement::toSolveString ( int jid, int aid )

toSolveString returns a QString of this requirement in the form needed for the solver. Parameters jid an int that is the jid of this requirement. jid >= 0 aid an int that is the aid of this requirement. aid >= 0 Returns QString that represents this requirement.

2.28.2.6

void Requirement::toString ( )

toString is used to test this requirement. It returns an output in the console of the given requirement. The documentation for this class was generated from the following files: • requirement.h • requirement.cpp

2.29

RequirementDefault Class Reference

Public Member Functions • RequirementDefault (Resource ∗resource, int amount, QObject ∗p) • Resource ∗ getResource () • int getAmount () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

170

Class Documentation • void setResource (Resource ∗newResource) • void setAmount (int newAmount) • void toString ()

Private Attributes • Resource ∗ resource • int amount • QObject ∗ parent

2.29.1


2.29.1.1

RequirementDefault::RequirementDefault ( Resource ∗ resource, int amount, QObject ∗ p )

Creates a new RequirementDefault. Parameters resource the resource of this requirement amount the amount of this requirement p the parent of this object

2.29.2


2.29.2.1

int RequirementDefault::getAmount ( )

returns the amount of this resource. 2.29.2.2 Resource ∗ RequirementDefault::getResource ( )

Returns the resource of this requirement.

2.29.2.3

void RequirementDefault::setAmount ( int newAmount )

Set a new amount. Parameters newAmount the new amount


2.30 Resource Class Reference 2.29.2.4 void RequirementDefault::setResource ( Resource ∗ newResource )

Set a new resource. Parameters newRe- the new resource source

2.29.2.5 void RequirementDefault::toString ( )

Debug string of this default requirement. The documentation for this class was generated from the following files: • requirementDefault.h • requirementDefault.cpp

2.30

Resource Class Reference

Public Member Functions • Resource (QString name, int capacity, int id, int solveId, QObject ∗parent) • Resource (QString name, int capacity, QObject ∗parent)

• void setName (QString) • QString getName () • void setCapacity (int) • int getCapacity () • void setId (int) • int getId () • int getSolveId () • void toString ()

• QString toSolveString ()

Private Attributes • QString name • int capacity • int id • int solveId Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

171

172

Class Documentation

2.30.1


2.30.1.1

Resource::Resource ( QString name, int capacity, int id, int solveId, QObject ∗ parent =0 )

Create a new resource with the given parameters Parameters name capacity id parent∗ solveId

2.30.1.2

name of this resource the maximun capacity that is available for this resource the id of this resource the parent of this object. the id that is needed for the solver.

Resource::Resource ( QString name, int capacity, QObject ∗ parent )

Create a new resource with the given parameters Parameters name name of this resource capacity the maximun capacity that is available for this resource parent∗ the parent of this object.

2.30.2


2.30.2.1

int Resource::getCapacity ( )

getCapacity returns the maximum capacity of this resource Returns the maximum capacity of this resource

2.30.2.2

int Resource::getId ( )

getId returns the id of this resource Returns the id of this resource

2.30.2.3

QString Resource::getName ( )

getName returns the name of this resource Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.30 Resource Class Reference

173

Returns the name of this resource

2.30.2.4

int Resource::getSolveId ( )

getSolvedId returns the id that is needed by the solver. Because it isn’t possible to know the resource solveid in requirements, a resource need to ’remember’ his own solveId (starting at 0 till n, with n is the number of resources) Returns the solveId

2.30.2.5

void Resource::setCapacity ( int newCapacity )

setCapacity sets the maximum capacity of this resource Parameters newCapac- an int that represents the maximum capacity ity

2.30.2.6 void Resource::setId ( int newId )

setId sets the id of this resource Parameters newId an int that represents the new id

2.30.2.7 void Resource::setName ( QString newName )

setName sets the name of this resource Parameters newName a QString of the new name

2.30.2.8 QString Resource::toSolveString ( )

toSolveString returns a QString of this resource in the form needed for the solver. Returns QString that represents this resource.


174

Class Documentation

2.30.2.9

void Resource::toString ( )

toString is used to test this resource. It returns an output in the console of the given resource. The documentation for this class was generated from the following files: • resource.h • resource.cpp

2.31 ResourceController Class Reference Public Slots • • • •

void buttonSaveClicked () void buttonUpdateClicked () void initializeEditResourceUi () void initializeAddResourceUi ()

Public Member Functions • ResourceController (QWidget ∗p)

Private Member Functions • bool checkForSameNames ()


AddResourceUi ∗ addResourceUi EditResourceUi ∗ editResourceUi QList< Resource ∗ > list QWidget ∗ parent

2.31.1


2.31.1.1

ResourceController::ResourceController ( QWidget ∗ p )

Create a new Controller to handle the add and edit resouce ui Parameters p the parent of this controller


2.32 ResourceHeader Class Reference

2.31.2

175


2.31.2.1 void ResourceController::buttonSaveClicked ( ) [slot]

buttonSaveClicked is called when the button ’Opslaan’ is clicked and will save all entered information to the database. Checks will be given if there is incorrect information entered. Also an confirmation is given when the resource is saved. 2.31.2.2

void ResourceController::buttonUpdateClicked ( ) [slot]

buttonUpdateClicked is called when the button ’Opslaan’ is clicked and will update all entered information to the database. An confirmation is given when the resource is saved. 2.31.2.3

bool ResourceController::checkForSameNames ( ) [private]

Returns true iff there is more then one resource with the same name. Returns true iff more then one resource exist with the same name

2.31.2.4

void ResourceController::initializeAddResourceUi ( ) [slot]

Shows the addResourceUi. 2.31.2.5

void ResourceController::initializeEditResourceUi ( ) [slot]

Shows the EditResourceUi The documentation for this class was generated from the following files: • resourceController.h • resourceController.cpp

2.32

ResourceHeader Class Reference

Signals • void resourceAmountChanged ()

Public Member Functions • ResourceHeader (QWidget ∗, Resource ∗) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

176

Class Documentation

Private Slots • void changeAmount (int)


void createLayout () void createLabels () void createSpinBox () void createSignals () void paintEvent (QPaintEvent ∗) QSize sizeHint () const


QHBoxLayout ∗ layout QLabel ∗ nameLabel QSpinBox ∗ spinBox Resource ∗ resource

2.32.1


2.32.1.1

ResourceHeader::ResourceHeader ( QWidget ∗ p, Resource ∗ r )

Creates the resource header containing the name of the resource and the available amount Receives a resource from the planning containing all this information Next calls on all methods to create the required widgets in this widget Parameters p parent of this widget, when the parent is closed this is also closed r the resource this object represents

2.32.2


2.32.2.1

void ResourceHeader::changeAmount ( int value ) [private, slot]

Emit a signal when the value in the spinBox is raised, the resource schedule needs to be updated and the planning needs to be updates Parameters value set the amount of the resource that is available


2.33 ResourceWidget Class Reference

177

2.32.2.2 void ResourceHeader::createLabels ( ) [private]

Create the label containing the resource name 2.32.2.3

void ResourceHeader::createLayout ( ) [private]

Create the layout and add the boxes, add the stretch in the middle to make it look nice 2.32.2.4

void ResourceHeader::createSignals ( ) [private]

The connect needed to change the amount in the planning 2.32.2.5

void ResourceHeader::createSpinBox ( ) [private]

Create the spinBox containing the current available resources, this can be changed 2.32.2.6

void ResourceHeader::paintEvent ( QPaintEvent ∗ e ) [private]

Paint the line seperating this header and the next Parameters e the paintevent that is called whenever the object needs updating

2.32.2.7 QSize ResourceHeader::sizeHint ( ) const [private]

every headers has a size equal to geometry and height The documentation for this class was generated from the following files: • resourceHeader.h • resourceHeader.cpp

2.33

ResourceWidget Class Reference

Public Slots • void updateMap () • void updateResourceAmount ()

Public Member Functions • ResourceWidget (QWidget ∗, Resource ∗, ViewController ∗) • QSize sizeHint () const Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

178

Class Documentation


void paintEvent (QPaintEvent ∗) void resizeEvent (QResizeEvent ∗) void connectActivities () void calculateDemandProfile () void createPoints () void updatePixMap () void redetermineSize ()

Private Attributes • • • • • • • • • •

QWidget ∗ parent ViewController ∗ viewController2 Resource ∗ resource QList< ActivityBlock ∗ > activities QList< QPoint > demandProfile QMap< int, int > heights QPixmap pixMap int maximumTime int maximumDemand int endPos

2.33.1


2.33.1.1

ResourceWidget::ResourceWidget ( QWidget ∗ p, Resource ∗ r, ViewController ∗ v )

Create a new widget with its controller and a resource containing all the information that is required Upon creation make a connection between activityBlocks and this and also create the startPositions of the requirements for this resource Parameters p parent of this widget, if the parent is closed this also closes r the resource that this widget represents v the controller that contains certain important information to this widget

2.33.2


2.33.2.1

void ResourceWidget::calculateDemandProfile ( ) [private]

The map we make take tha pixelposition as a key and the height as its corresponding value In this method we calculate the height at each pixel position in the activities we add these to a map, whenever a activity overlaps an already existing height we first save the height, then remove it and the add it again+ the amount the activity requires of this Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.33 ResourceWidget Class Reference

179

resource 2.33.2.2 void ResourceWidget::connectActivities ( ) [private]

Make a list of all activities that require this resource to be used Also make the size of this widget to be as large as the biggest scheduleWidget, thus making scheduleWidgets and resourceWidgets the same size In this method we also already remove all activities thats are not required for this resource, if a activity has no requirement in for this resource it is not added to the list 2.33.2.3

void ResourceWidget::createPoints ( ) [private]

We can now create points from the heightmap that can be used to draw the map. For every position we create a point. For every point we look if the demand is now higher then before this point, if it is we have a new maximumdemand. We need this value later to draw. If time is left we would like to make this method more optimized, right now it is the bottleneck in our program because it needs to do a lot of calculations 2.33.2.4

void ResourceWidget::paintEvent ( QPaintEvent ∗ e ) [private]

Actually paint the created map Parameters e the paintevent that is called whenever the object needs updating

2.33.2.5 void ResourceWidget::redetermineSize ( ) [private]

jobs can be moved so the size of this widget needs to be recalculated whenever a job has moved, because the current endPos might not be up to date anymore 2.33.2.6

void ResourceWidget::resizeEvent ( QResizeEvent ∗ ) [private]

Whenever widget size is changed redraw map 2.33.2.7

QSize ResourceWidget::sizeHint ( ) const

return the size of this widget, endPos is made according to largest scheduleWidget 2.33.2.8

void ResourceWidget::updateMap ( ) [slot]

Whenever an activity is changed or a job is changed redetermine the size of this widget and recalculate the positions of the heightmap Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

180

Class Documentation

2.33.2.9

void ResourceWidget::updatePixMap ( ) [private]

In this method we actually visually represent the requirements for this resource in time.

2.33.2.10

void ResourceWidget::updateResourceAmount ( ) [slot]

Whenever the resourceCapacity is changed in the resourceHeader widget, redraw the pixmap The documentation for this class was generated from the following files: • resourceWidget.h • resourceWidget.cpp

2.34 SaveNameWidget Class Reference Public Member Functions • SaveNameWidget (QWidget ∗, ViewController ∗) • QString returnName ()


void createLabel () void createLineEdit () void createButtons () void createLayout () void createSignals ()


QWidget ∗ parent QLabel ∗ nameLabel QLineEdit ∗ nameLine QPushButton ∗ saveButton QPushButton ∗ cancelButton QHBoxLayout ∗ layout QHBoxLayout ∗ buttonLayout QVBoxLayout ∗ total ViewController ∗ controller Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.34 SaveNameWidget Class Reference

2.34.1


2.34.1.1 SaveNameWidget::SaveNameWidget ( QWidget ∗ p, ViewController ∗ v )

Create a dialog that will get popped up when ’Save as...’ is clicked. Parameters p the parent widget v the controller of this widget.

2.34.2


2.34.2.1 void SaveNameWidget::createButtons ( ) [private]

Create the buttons needed for this dialog. 2.34.2.2

void SaveNameWidget::createLabel ( ) [private]

Create the labels needed for this dialog. 2.34.2.3

void SaveNameWidget::createLayout ( ) [private]

Create the layout needed for this dialog. 2.34.2.4

void SaveNameWidget::createLineEdit ( ) [private]

Create the lineedits needed for this dialog. 2.34.2.5

void SaveNameWidget::createSignals ( ) [private]

Create the signals for this dialog. 2.34.2.6

QString SaveNameWidget::returnName ( )

Returns the entered name. Returns the entered name. The documentation for this class was generated from the following files: • saveNameWidget.h • saveNameWidget.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

181

182

Class Documentation

2.35 ScheduleWidget Class Reference Public Slots • void toggleSchedule (bool)

Signals • void nrOfActivitiesChanged (int) • void endPosChanged ()

Public Member Functions • ScheduleWidget (QWidget ∗, Planning ∗, int) • void addActivity (ActivityBlock ∗)

• QSize sizeHint () const • void setStartTime (int) • int getStartTime () • void setEndTime (int) • int getEndTime () • Job ∗ getJob ()

Public Attributes • QList< ActivityBlock ∗ > ∗ activityBlocks

Private Member Functions • void paintEvent (QPaintEvent ∗) • void createLayout () • void setTimes () • void mousePressEvent (QMouseEvent ∗)

• void mouseMoveEvent (QMouseEvent ∗)

• void mouseReleaseEvent (QMouseEvent ∗) • void updateDate ()

• void updateBlocks () • void fixHeights () • void updateWidget () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.35 ScheduleWidget Class Reference

183


QWidget ∗ parent Job ∗ job Planning ∗ planning QHBoxLayout ∗ layout QString name bool expanded bool selectedFront bool selectedBack bool recalculate int nrOfBlocks int nrOfActivities int start int startTime int endTime

2.35.1


2.35.1.1

ScheduleWidget::ScheduleWidget ( QWidget ∗ p, Planning ∗ plan, int i )

Constructor for a schedulewidget, receives a planning and an integer i so that it knows which job it needs. Standard it is not expanded. The planning is needed becaus ethis is the only object that knows when the planning actually starts, the job does not have this information by itself Parameters p parent of this widget, whenever the parent is closed this also closes plan the planning that this objects contains i the i’th job of the planning is the job in this widget

2.35.2


2.35.2.1 void ScheduleWidget::addActivity ( ActivityBlock ∗ block )

A planning contains all possible activities for a job, only those that were check need to be included so we check for a checked flag Parameters block add an activityBlock to this widget

2.35.2.2 void ScheduleWidget::createLayout ( ) [private]

Create layout for this widget Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

184

Class Documentation

2.35.2.3

void ScheduleWidget::fixHeights ( ) [private]

When expanded the heights of the various activities needs to be changed 2.35.2.4

int ScheduleWidget::getEndTime ( )

returns the endTime of this job Returns endTime

2.35.2.5 Job ∗ ScheduleWidget::getJob ( )

returns the job this widget represents Returns job the represented job

2.35.2.6

int ScheduleWidget::getStartTime ( )

Returns the startTime of this job Returns startTime

2.35.2.7

void ScheduleWidget::mouseMoveEvent ( QMouseEvent ∗ e ) [private]

If the mouse is moved while pressed without releasing then move the startTime of the job en also the endTime Updat both the activityblocks and dates Parameters e the mouse-event when the button is moved inside this widget

2.35.2.8

void ScheduleWidget::mousePressEvent ( QMouseEvent ∗ e ) [private]

If the mouse is pessed within 10 pixels of the beginning of this job starttime, then it can be moved Parameters e the mouse-event when the button is clicked inside this widget


2.35 ScheduleWidget Class Reference

185

2.35.2.9 void ScheduleWidget::mouseReleaseEvent ( QMouseEvent ∗ e ) [private]

If the mouseButton is released, recalculate resources and update the blocks and dates again Parameters e the mouse-event when the button is released inside this widget

2.35.2.10

void ScheduleWidget::paintEvent ( QPaintEvent ∗ e ) [private]

The paintevent for this class creates a light green block that starts at startTime and ends at endTime, it represents the timeframe of the job. It also draws a line at the bottom separating this widget from the following Parameters e the paintevent that is called whenever the object needs updating

2.35.2.11

void ScheduleWidget::setEndTime ( int newTime )

Sets a new EndTime for this job Parameters newTime the new endTime

2.35.2.12

void ScheduleWidget::setStartTime ( int newTime )

Sets a new startTime for this job Parameters newTime the new startTime

2.35.2.13

void ScheduleWidget::setTimes ( ) [private]

Before the timeframe for a job can be drawn we first need to turn the time from the database into positions in a widget We assume that every planning starts at 00.00. Then the distance is calculated from this startpoint to the start of the job and the distance from this startpoint to the end of this job. Everything is calculated and rounded to whole minutes Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

186

Class Documentation

2.35.2.14

QSize ScheduleWidget::sizeHint ( ) const

Returns the size needed for the object, everything is calculated in minutes, height in expanded state depends on the number of activities 2.35.2.15

void ScheduleWidget::toggleSchedule ( bool e ) [slot]

Toggles the schedule between expanded en normal Parameters e boolean that represents whether this widget should be expanded or not

2.35.2.16

void ScheduleWidget::updateBlocks ( ) [private]

Whenever the new startPos of a block <= the its startTime the blocks needs to be moved and resources recalculated The same also goes when the endPos >= its endTime 2.35.2.17

void ScheduleWidget::updateDate ( ) [private]

Update the dates after moving them by recalculating the distance in pixels from the start of the planning The startTime of this job is accurate in minutes so multiply it by 60 to get is to seconds, then add these seconds to the startDate of the planning and you get the new startDate of the job that can be saved EndTime is calculated in the same way After the date is updated all activity blocks need to be updates to know the new ranges in wgich they can be moved The documentation for this class was generated from the following files: • scheduleWidget.h • scheduleWidget.cpp

2.36 SelectPlanningUi Class Reference Public Slots • void controlDate ()


SelectPlanningUi (ViewController ∗, QWidget ∗) void addItem (QStringList) void setDates (QDate, QDate) void clearList () void clearLineEdit () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.36 SelectPlanningUi Class Reference • • • • •

187

QString getItem () QDate getStartDate () QDate getEndDate () QString getSearcParam () int getNumberOfRows ()


void createButtons () void createLabels () void createLists () void createDateEdits () void createLineEdits () void createLayouts () void createSignals ()


QPushButton ∗ buttonShow QPushButton ∗ buttonClose QPushButton ∗ resetButton QLabel ∗ labelTitle QLabel ∗ labelExplanation QVBoxLayout ∗ vLayoutMain QHBoxLayout ∗ hLayoutButtonContainer QHBoxLayout ∗ searchLayout QListView ∗ listSummary QStringListModel ∗ model QDateEdit ∗ startDate QDateEdit ∗ endDate QLineEdit ∗ searchLine ViewController ∗ viewController

2.36.1 Constructor & Destructor Documentation 2.36.1.1

SelectPlanningUi::SelectPlanningUi ( ViewController ∗ c, QWidget ∗ p )

Creating a new SelectPlanningUi. Param ∗c, give the appropriate SelectPlanningController of this interface.

2.36.2


2.36.2.1

void SelectPlanningUi::addItem ( QStringList list )

Adds the provided item to the list. param item QString that contains an item displayed in the list Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

188 2.36.2.2

Class Documentation void SelectPlanningUi::clearLineEdit ( )

Clears the input from the lineEdit. 2.36.2.3

void SelectPlanningUi::clearList ( )

Clears the list with plannings. 2.36.2.4

void SelectPlanningUi::controlDate ( ) [slot]

Update the endDate field if the startDate field is updated. Make sure that startDate <= endDate. 2.36.2.5

void SelectPlanningUi::createButtons ( ) [private]

Creating all the required buttons for this interface. 2.36.2.6

void SelectPlanningUi::createDateEdits ( ) [private]

Create the dateEdit for this ui. 2.36.2.7

void SelectPlanningUi::createLabels ( ) [private]


void SelectPlanningUi::createLayouts ( ) [private]


void SelectPlanningUi::createLineEdits ( ) [private]

Create the lineEdit for this ui. 2.36.2.10 void SelectPlanningUi::createLists ( ) [private]

Creating all the required lists for this interface. 2.36.2.11 void SelectPlanningUi::createSignals ( ) [private]

Creating all the required interface actions. Connecting signals to slots. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.36 SelectPlanningUi Class Reference 2.36.2.12

QDate SelectPlanningUi::getEndDate ( )

Returns the entered endDate. Returns the entered search endDate

2.36.2.13

QString SelectPlanningUi::getItem ( )

Returns a QString of the selected item. return QString, the selected item. 2.36.2.14

int SelectPlanningUi::getNumberOfRows ( )

Returns the number of rows that the list contains 2.36.2.15

QString SelectPlanningUi::getSearcParam ( )

Returns the entered searchParam Returns the entered seachString

2.36.2.16

QDate SelectPlanningUi::getStartDate ( )

Returns the entered startDate. Returns the entered search startDate

2.36.2.17

void SelectPlanningUi::setDates ( QDate s, QDate e )

Sets the date where between can be searched. Parameters s the startDate e the endDate The documentation for this class was generated from the following files: • selectPlanningUi.h • selectPlanningUi.cpp Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

189

190

Class Documentation

2.37 Servicing Class Reference Public Member Functions • • • • • • •

Servicing (QString name, int trainId, QObject ∗parent) QString getName () int getTrainId () void setName (QString newName) void setTrainId (int newTrainId) void addActivityDefault (ActivityDefault ∗newActivityDefault) void toString ()

Public Attributes • QList< ActivityDefault ∗ > activityDefaults

Private Attributes • QObject ∗ parent • QString name • int trainId

2.37.1


2.37.1.1

Servicing::Servicing ( QString name, int trainId, QObject ∗ parent )

Create a new servicing with the given parameters Parameters name name of this servicing trainId the trainId of this servicing parent the parent of this object.

2.37.2


2.37.2.1

void Servicing::addActivityDefault ( ActivityDefault ∗ newActivityDefault )

addActivityDefaults adds a new activityDefault to this servicing. Parameters newActivity- the new activityDefault to be added. Default


2.38 ServicingController Class Reference 2.37.2.2 QString Servicing::getName ( )

getName returns the name of this servicing. Returns the name of this servicing.

2.37.2.3

int Servicing::getTrainId ( )

getTrainId returns the trainId that belongs to this servicing. Returns the trainId that belongs to this servicing.

2.37.2.4

void Servicing::setName ( QString newName )

setName sets the name of this servicing. Parameters newName the new name of this servicing. newName != ""

2.37.2.5 void Servicing::setTrainId ( int newTrainId )

setTrainId sets the trainId of this servicing. Parameters newTrainId the new trainId of this servicing. trainId > 0

2.37.2.6 void Servicing::toString ( )

Debug string of this servicing. The documentation for this class was generated from the following files: • servicing.h • servicing.cpp

2.38

ServicingController Class Reference

Public Slots • void initializeAddServicing () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

191

192

Class Documentation • • • • • • • • • •

void buttonSaveClicked () void buttonAnotherOneClicked () void updateForm () void initializeRemoveServicing () void buttonRemoveClicked () void updateServicingList () void initializeEditServicing () void buttonUpdateClicked () void trainTypeChanged () void servicingTypeChanged ()

Public Member Functions • ServicingController (QWidget ∗p)

Private Member Functions • void saveServicing ()


QWidget ∗ parent int numberOfRows AddServicingUi ∗ addServicingUi RemoveServicingUi ∗ removeServicingUi EditServicingUi ∗ editServicingUi

2.38.1


2.38.1.1

ServicingController::ServicingController ( QWidget ∗ p )

Create a new ServicingController with the given parent Parameters p the parent of this controller

2.38.2


2.38.2.1

void ServicingController::buttonAnotherOneClicked ( ) [slot]

Function that is called when the anotherOneButton is clicked. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.38 ServicingController Class Reference

193

2.38.2.2 void ServicingController::buttonRemoveClicked ( ) [slot]

Removes the selected servicing. 2.38.2.3

void ServicingController::buttonSaveClicked ( ) [slot]

Function that is called when the saveButton is clicked. After the service is saved the ui is closed. 2.38.2.4

void ServicingController::buttonUpdateClicked ( ) [slot]

When the button Update is clicked this function will be called and makes shure everything is saved in the database. 2.38.2.5

void ServicingController::initializeAddServicing ( ) [slot]

initializeAddServicing is called when the ui addServicingUi needs to be showed. The list with trains will be send to the ui. And the formLayout of Ui is updated with the right activityDefaults. Default the first trainId is being showed. 2.38.2.6

void ServicingController::initializeEditServicing ( ) [slot]

Initialize the editServicingUi. Also adds the trains to this interface. 2.38.2.7

void ServicingController::initializeRemoveServicing ( ) [slot]

Shows the removeUi. 2.38.2.8

void ServicingController::saveServicing ( ) [private]

Save the servicing to the database. A servicing can’t have a empty name and it isn’t allowed to create a servicing with the same name and tid. 2.38.2.9

void ServicingController::servicingTypeChanged ( ) [slot]

If the user selects a different servicing this function is executed. And update the activities that belong to the selected train and servicing. 2.38.2.10

void ServicingController::trainTypeChanged ( ) [slot]

If the user selects a different train this function is executed. And update the servicing that belong to the selected train. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

194

Class Documentation

2.38.2.11

void ServicingController::updateForm ( ) [slot]

Updates the form with all the possible default activitynames. 2.38.2.12

void ServicingController::updateServicingList ( ) [slot]

Update the list with servicings that belongs to the selected train. The documentation for this class was generated from the following files: • servicingController.h • servicingController.cpp

2.39 Solver Class Reference Signals • void solved (Planning ∗) • void unsolvable () • void progressSignal (int)

Public Member Functions • void execute (Planning ∗p)

Public Attributes • Planning ∗ planning

Private Slots • void processOutput () • void processFinished (int exitCode, QProcess::ExitStatus exitStatus)

Private Member Functions • void executeBinary (QByteArray a)


QString arguments QString binary QProcess process bool solveble Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.40 TimeLine Class Reference

2.39.1

195


2.39.1.1 void Solver::execute ( Planning ∗ planning )

Create the file needed by the algorithm, save the file its location in arguments; Parameters planning planning for which planning you want to run the solver.

2.39.1.2 void Solver::executeBinary ( QByteArray array ) [private]

Executes the binary (Files/ontrack), and write the input file to the binary. When the binary is finished a signal will be emitted, and the output will be read. Parameters array the QBytearray with the input for the solver.

2.39.1.3 void Solver::processFinished ( int exitCode, QProcess::ExitStatus exitStatus )

[private, slot] processsFinished is called when the QProcess is finished. Parameters exitCode any exitcode the QProcess outputs. exitStatus any exitstatus the QProcess outputs

2.39.1.4 void Solver::processOutput ( ) [private, slot]

Process the output of the algorithm. And save the results in planning. The est’s will be saved to the right activity, so all activities that are flagged as finished or !checked will be ignored the others will be saved as a pointer in a list. This list will be used to save the est to the right activity. If a planning is not solveble a flag will be set. The documentation for this class was generated from the following files: • solver.h • solver.cpp

2.40

TimeLine Class Reference

Public Member Functions • TimeLine (QWidget ∗) Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

196

Class Documentation

Private Member Functions • void paintEvent (QPaintEvent ∗) • void createLayouts ()

Private Attributes • QVBoxLayout ∗ layout

2.40.1


2.40.1.1

TimeLine::TimeLine ( QWidget ∗ p )

Constructs a timeline Parameters p parent of this widget, whenever the parent is closed the widget is to

2.40.2


2.40.2.1

void TimeLine::createLayouts ( ) [private]

Create timeline object layout 2.40.2.2

void TimeLine::paintEvent ( QPaintEvent ∗ e ) [private]

Paint the timeline, because we round to whole minutes, every block has a size of 60, corresponding to 60 min in an hour Parameters e the paintevent that is called whenever the object needs updating The documentation for this class was generated from the following files: • timeLine.h • timeline.cpp

2.41 ViewController Class Reference Public Slots • void buttonShowClicked () • void savePlanning () • void planningNameUi () Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.41 ViewController Class Reference • • • • • • •

void saveAsPlanning () void solvePlanning () void solvedPlanning (Planning ∗) void planningUnsolvable () void showSelectPlanningUi () void renewList () void closePlannning ()

Signals • void planningOpened () • void planningClosed ()

Public Member Functions • ViewController (QMainWindow ∗)

Public Attributes • QList< ScheduleWidget ∗ > jobList


void addJobs () void addResourceNames () void addSpacers () void initializeAddViewer () void addActivities () void generateConstraints ()


QMainWindow ∗ parent Planning ∗ planning SelectPlanningUi ∗ selectPlanningUi AddViewer ∗ addViewer ColorGenerator ∗ generator SaveNameWidget ∗ name ProgressUi ∗ progress QList< ActivityBlock ∗ > activities int resourceWidgetSize


197

198

Class Documentation

2.41.1


2.41.1.1

ViewController::ViewController ( QMainWindow ∗ p )

The constructor which creates a new viewerWidget and calls on the method to create the view that allows you to select a saved planning from a list Parameters p the parent of this widget, if the parent is closed so is this

2.41.2


2.41.2.1

void ViewController::addActivities ( ) [private]

A planning contains all possible activities for a job, only those that were check need to be included so we check for a checked flag

2.41.2.2

void ViewController::addJobs ( ) [private]

After the addviewer was created and a planning was loaded, for each job a jobheader containing the jobs name needs to be made and added to the viewer. After this a widget containing the actual visual representation of the job needs to be added to the viewer. Because a job does not point to a planning a i is required to know which job is connected to the widget Whenever the expand button is pushed in the header, the schedule also needs to expand

2.41.2.3

void ViewController::addResourceNames ( ) [private]

Creates resourceHeader classes for every resources in a planning and sends this info to the viewer first creates a header containing the resource name and amount available Next creates a resource schedule showing the amounts used

2.41.2.4

void ViewController::addSpacers ( ) [private]

After all jobs and resources have been added, add spacers to each so that they all line up nicely

2.41.2.5

void ViewController::buttonShowClicked ( ) [slot]

buttonShowClicked is called when the user clicks the ’Toon planning’ button. There will be checked if there is a planning selected and if there is one selected if it is a correct planning. If this isn’t the case the user will get a warning. After this check the next userinterface will be showed with the selected planning. Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

2.41 ViewController Class Reference

199

2.41.2.6 void ViewController::generateConstraints ( ) [private]

Generates the constraints. This is done by creating a list with pointers to all activities that needs to be considered. These are activities that aren’t checked as finished and checked as checked (activity is for this job selected). For this newly created list all entries need to be checked if that entry needs a constraint. An activity needs a constraint if a1.startpos < a2.startpos (a1 starts before a2). 2.41.2.7

void ViewController::initializeAddViewer ( ) [private]

creates an addviewer object and sets it in the mainwindow, also calls on all the methods that fill the addviewer with required widgets 2.41.2.8

void ViewController::planningUnsolvable ( ) [slot]

The planning cannot be solved by this particular algorithm so give this feedback to teh user If made possible by the algorithm you can change this to give specific reasons for failure 2.41.2.9

void ViewController::savePlanning ( ) [slot]

Saves the planning when the savebutton is pushed 2.41.2.10

void ViewController::showSelectPlanningUi ( ) [slot]

showSelectPlanningUi shows the dialog that let the user select the planning he want to show. The list with plannings will be showed. 2.41.2.11

void ViewController::solvedPlanning ( Planning ∗ p ) [slot]

Show the new resolved planning in the GUI Parameters p whenever a planning is solved this is the solved planning

2.41.2.12

void ViewController::solvePlanning ( ) [slot]

Call the solver to solve a planning and connect solver and controller to make sure the GUI is changed when the solver gives an output The documentation for this class was generated from the following files: • viewController.h • viewController.cpp


Index activities Job, 153 Activity, 91 Activity, 92 addRequirement, 92 getChecked, 92 getDuration, 93 getEst, 93 getFinished, 93 getId, 93 getJobId, 93 getName, 93 getRequirement, 93 requirements, 96 setChecked, 94 setDuration, 94 setEst, 94 setFinished, 94 setId, 94 setJobId, 95 setName, 95 toSolveString, 95 toString, 95 ActivityBlock, 96 ActivityBlock, 97 activityIsFinished, 98 changeDuration, 98 correctPosition, 98 getActivity, 98 getEndPos, 98 getEndTime, 98 getStartPos, 99 getStartTime, 99 mouseDoubleClickEvent, 99 mouseMoveEvent, 99 mousePressEvent, 99 mouseReleaseEvent, 100 moveBlock, 100 paintEvent, 100 setColor, 100 setEndPos, 100

setEndTime, 100 setHeight, 101 setStartPos, 101 setStartTime, 101 sizeHint, 101 updateResources, 101 ActivityDefault, 101 ActivityDefault, 102 addRequirementDefault, 102 getDuration, 102 getName, 103 getTrainId, 103 requirementDefaults, 104 setDuration, 103 setName, 103 setTrainId, 103 toString, 103 ActivityDefaultController, 104 ActivityDefaultController, 104 buttonAnotherOneClicked, 105 buttonSaveClicked, 105 correctInput, 105 initializeAddActivityDefaultUi, 105 saveInputToDb, 105 ActivityInfoWidget, 105 ActivityInfoWidget, 106 createButtons, 107 createCheckBox, 107 createLabels, 107 createLayout, 107 createResourceLayout, 107 createSignals, 107 getResourceName, 107 getResourceValue, 107 activityIsFinished ActivityBlock, 98 activityUiButtonSaveClicked AddPlanningController, 117 addActivities ViewController, 198 addActivity

INDEX Job, 150 ScheduleWidget, 183 addActivityDefault DatabaseActions, 134 Servicing, 190 AddActivityDefaultUi, 108 AddActivityDefaultUi, 109 addRow, 109 addTrains, 109 clearInput, 110 createButtons, 110 createComboBox, 110 createLabels, 110 createLayouts, 110 createLineEdit, 110 createSignals, 110 createSpinBox, 110 getCapacity, 110 getLineEdit, 110 getNumberOfRows, 111 getTrain, 111 getWidget, 111 AddActivityUi, 111 AddActivityUi, 112 addList, 112 addWidget, 112, 113 clear, 113 createButtons, 113 createLabels, 113 createLayouts, 113 createLists, 113 createSignals, 113 getSelectedListItem, 113 getWidget, 114 addConstraint Planning, 158 addItem RemovePlanningUi, 164 RemoveServicingUi, 166 SelectPlanningUi, 187 addItems RemoveServicingUi, 166 addJob Planning, 158 addJobs ViewController, 198 AddJobUi, 114 AddJobUi, 115 addWidget, 115 createButtons, 115

201 createGridLayout, 115 createLabels, 115 createLayouts, 115 createSignals, 115 getItemAt, 115 returnGrid, 116 addList AddActivityUi, 112 addNameLayout AddViewer, 129 AddPlanningController, 116 activityUiButtonSaveClicked, 117 AddPlanningController, 117 addRow, 117 connectBoxes, 117 controlDateTime, 117 createDefaultPlanning, 118 existPlanning, 118 existSameNames, 118 fillGrid, 118 fillGridContent, 118 fillGridHeaders, 118 fillListJob, 119 getDefaultServicingList, 119 getTrainTypes, 119 initializeAddActivityUi, 119 initializeAddJobUi, 119 initializeAddPlanningUi, 119 jobUiButtonAddRowClicked, 119 jobUiButtonNextClicked, 119 planningUiButtonNextClicked, 119 updateActivityGrid, 120 updatePlanning, 120 writePlanningToDatabase, 120 AddPlanningUi, 120 AddPlanningUi, 121 createButtons, 121 createDates, 121 createLabels, 121 createLayouts, 122 createSignals, 122 createTextLines, 122 getEndDate, 122 getName, 122 getStartDate, 122 addRequirement Activity, 92 addRequirementDefault ActivityDefault, 102 DatabaseActions, 134


202

INDEX

addResource Planning, 158 addResourceNameLayout AddViewer, 129 addResourceNames ViewController, 198 AddResourceUi, 122 AddResourceUi, 123 createButtons, 123 createLabels, 123 createLayouts, 123 createLineEdit, 123 createSignals, 124 createSpinBox, 124 getMaxCapacity, 124 getName, 124 addResourceWidget AddViewer, 129 addRow AddActivityDefaultUi, 109 AddPlanningController, 117 AddServicingUi, 126 EditServicingUi, 146 addScheduleWidget AddViewer, 129 addServicingItems EditServicingUi, 147 AddServicingUi, 124 addRow, 126 AddServicingUi, 125 addTrains, 126 clearForm, 126 clearLineEdit, 126 createButtons, 126 createComboBox, 126 createLabels, 126 createLayouts, 126 createLineEdit, 126 createSignals, 127 getLineEdit, 127 getNumberOfRows, 127 getSelectedTrain, 127 getWidget, 127 addSpacers ViewController, 198 addTimeLines AddViewer, 130 addTrainItems EditServicingUi, 147 addTrains

AddActivityDefaultUi, 109 AddServicingUi, 126 AddViewer, 128 addNameLayout, 129 addResourceNameLayout, 129 addResourceWidget, 129 addScheduleWidget, 129 addTimeLines, 130 AddViewer, 129 createLayouts, 130 createObjects, 130 createScrollAreas, 130 createSignals, 130 createSplitters, 130 listSpacers, 130 moveSplitter, 130 addWidget AddActivityUi, 112, 113 AddJobUi, 115 EditResourceUi, 144 buttonAnotherOneClicked ActivityDefaultController, 105 ServicingController, 192 buttonRemoveClicked RemovePlanningController, 162 ServicingController, 192 buttonSaveClicked ActivityDefaultController, 105 ResourceController, 175 ServicingController, 193 buttonShowClicked ViewController, 198 buttonUpdateClicked ResourceController, 175 ServicingController, 193 calculateDemandProfile ResourceWidget, 178 changeAmount ResourceHeader, 176 changeDuration ActivityBlock, 98 changeNrOfActivities NameHeader, 156 checkForSameNames ResourceController, 175 clear AddActivityUi, 113 clearForm


INDEX AddServicingUi, 126 clearFormLayoutDown EditServicingUi, 147 clearInput AddActivityDefaultUi, 110 clearLineEdit AddServicingUi, 126 SelectPlanningUi, 187 clearList SelectPlanningUi, 188 clearServicingItems EditServicingUi, 147 ColorGenerator, 131 ColorGenerator, 131 next, 131 connectActivities ResourceWidget, 179 connectBoxes AddPlanningController, 117 connectDb databaseConnector, 142 Constraint, 132 Constraint, 132 toSolveString, 132 toString, 132 constraints Planning, 160 controlDate SelectPlanningUi, 188 controlDateTime AddPlanningController, 117 correctInput ActivityDefaultController, 105 correctPosition ActivityBlock, 98 createActions MainWindow, 154 createButtons ActivityInfoWidget, 107 AddActivityDefaultUi, 110 AddActivityUi, 113 AddJobUi, 115 AddPlanningUi, 121 AddResourceUi, 123 AddServicingUi, 126 EditResourceUi, 144 EditServicingUi, 147 NameHeader, 156 RemovePlanningUi, 164 RemoveServicingUi, 166

203 SaveNameWidget, 181 SelectPlanningUi, 188 createCheckBox ActivityInfoWidget, 107 createComboBox AddActivityDefaultUi, 110 AddServicingUi, 126 EditServicingUi, 147 RemoveServicingUi, 166 createDateEdits SelectPlanningUi, 188 createDates AddPlanningUi, 121 createDefaultPlanning AddPlanningController, 118 createGridLayout AddJobUi, 115 createLabel SaveNameWidget, 181 createLabels ActivityInfoWidget, 107 AddActivityDefaultUi, 110 AddActivityUi, 113 AddJobUi, 115 AddPlanningUi, 121 AddResourceUi, 123 AddServicingUi, 126 EditResourceUi, 144 EditServicingUi, 147 NameHeader, 156 RemovePlanningUi, 164 RemoveServicingUi, 167 ResourceHeader, 176 SelectPlanningUi, 188 createLayout ActivityInfoWidget, 107 ProgressUi, 161 ResourceHeader, 177 SaveNameWidget, 181 ScheduleWidget, 183 createLayouts AddActivityDefaultUi, 110 AddActivityUi, 113 AddJobUi, 115 AddPlanningUi, 122 AddResourceUi, 123 AddServicingUi, 126 AddViewer, 130 EditResourceUi, 144 EditServicingUi, 147


204

INDEX

NameHeader, 156 RemovePlanningUi, 164 RemoveServicingUi, 167 SelectPlanningUi, 188 TimeLine, 196 createLineEdit AddActivityDefaultUi, 110 AddResourceUi, 123 AddServicingUi, 126 SaveNameWidget, 181 createLineEdits SelectPlanningUi, 188 createLists AddActivityUi, 113 RemovePlanningUi, 165 RemoveServicingUi, 167 SelectPlanningUi, 188 createMenus MainWindow, 154 createObjects AddViewer, 130 createPoints ResourceWidget, 179 createProgressBar ProgressUi, 161 createResourceLayout ActivityInfoWidget, 107 createScrollAreas AddViewer, 130 createSignals ActivityInfoWidget, 107 AddActivityDefaultUi, 110 AddActivityUi, 113 AddJobUi, 115 AddPlanningUi, 122 AddResourceUi, 124 AddServicingUi, 127 AddViewer, 130 EditResourceUi, 144 EditServicingUi, 148 NameHeader, 156 RemovePlanningUi, 165 RemoveServicingUi, 167 ResourceHeader, 177 SaveNameWidget, 181 SelectPlanningUi, 188 createSpinBox AddActivityDefaultUi, 110 AddResourceUi, 124 ResourceHeader, 177

createSplitters AddViewer, 130 createTextLines AddPlanningUi, 122 DatabaseActions, 133 addActivityDefault, 134 addRequirementDefault, 134 DatabaseActions, 134 editResource, 134 editResources, 134 existPlanning, 135 existResource, 135 existServicing, 135 getActivitiesFromDb, 135 getActivityDefaults, 135 getActivityDefaultsByServicing, 136 getActivityDefaultsNotByServicing, 136 getAdidByName, 136 getConstraintsFromDb, 137 getFirstDateFromPlanningen, 137 getJobsFromDb, 137 getLastDateFromPlanningen, 137 getPidFromName, 137 getPlanningFromDb, 137 getPlanningList, 138 getRequirementsFromDb, 138 getResourceByName, 138 getResources, 139 getServicing, 139 getSidByName, 139 getTidByName, 139 getTrainList, 140 removePlanningFromDb, 140 removeServicing, 140 saveActivities, 140 saveConstraints, 141 saveJobs, 141 savePlanning, 141 saveRequirement, 141 saveResource, 141 saveServicing, 141 saveServicingName, 142 databaseConnector, 142 connectDb, 142 databaseConnector, 142 disconnectDb, 143 disconnectDb databaseConnector, 143


INDEX editResource DatabaseActions, 134 editResources DatabaseActions, 134 EditResourceUi, 143 addWidget, 144 createButtons, 144 createLabels, 144 createLayouts, 144 createSignals, 144 EditResourceUi, 144 getMaxCapacityAt, 144 getNameAt, 145 getNumberOfRows, 145 EditServicingUi, 145 addRow, 146 addServicingItems, 147 addTrainItems, 147 clearFormLayoutDown, 147 clearServicingItems, 147 createButtons, 147 createComboBox, 147 createLabels, 147 createLayouts, 147 createSignals, 148 EditServicingUi, 146 getActivityDefault, 148 getNumberOfRows, 148 getSelectedServicing, 148 getSelectedTrain, 148 execute Solver, 195 executeBinary Solver, 195 existPlanning AddPlanningController, 118 DatabaseActions, 135 existResource DatabaseActions, 135 existSameNames AddPlanningController, 118 existServicing DatabaseActions, 135 expand NameHeader, 156 fillGrid AddPlanningController, 118 fillGridContent AddPlanningController, 118

205 fillGridHeaders AddPlanningController, 118 fillList RemovePlanningController, 162 fillListJob AddPlanningController, 119 fixHeights ScheduleWidget, 183 generateConstraints ViewController, 198 getActivitiesFromDb DatabaseActions, 135 getActivity ActivityBlock, 98 Job, 150 getActivityDefault EditServicingUi, 148 getActivityDefaults DatabaseActions, 135 getActivityDefaultsByServicing DatabaseActions, 136 getActivityDefaultsNotByServicing DatabaseActions, 136 getAdidByName DatabaseActions, 136 getAmount Requirement, 168 RequirementDefault, 170 getCapacity AddActivityDefaultUi, 110 Resource, 172 getChecked Activity, 92 getConstraintsFromDb DatabaseActions, 137 getDefaultServicingList AddPlanningController, 119 getDuration Activity, 93 ActivityDefault, 102 getEndDate AddPlanningUi, 122 Planning, 158 SelectPlanningUi, 188 getEndPos ActivityBlock, 98 getEndTime ActivityBlock, 98 Job, 150


206

INDEX

ScheduleWidget, 184 getEst Activity, 93 getFinished Activity, 93 getFirstDateFromPlanningen DatabaseActions, 137 getId Activity, 93 Job, 150 Resource, 172 getItem RemovePlanningUi, 165 RemoveServicingUi, 167 SelectPlanningUi, 189 getItemAt AddJobUi, 115 getJob ScheduleWidget, 184 getJobId Activity, 93 getJobsFromDb DatabaseActions, 137 getLastDateFromPlanningen DatabaseActions, 137 getLineEdit AddActivityDefaultUi, 110 AddServicingUi, 127 getMaxCapacity AddResourceUi, 124 getMaxCapacityAt EditResourceUi, 144 getName Activity, 93 ActivityDefault, 103 AddPlanningUi, 122 AddResourceUi, 124 Job, 150 Planning, 158 Resource, 172 Servicing, 190 getNameAt EditResourceUi, 145 getNumberOfRows AddActivityDefaultUi, 111 AddServicingUi, 127 EditResourceUi, 145 EditServicingUi, 148 RemovePlanningUi, 165 SelectPlanningUi, 189

getPidFromName DatabaseActions, 137 getPlanningFromDb DatabaseActions, 137 getPlanningList DatabaseActions, 138 getRequirement Activity, 93 getRequirementsFromDb DatabaseActions, 138 getResource Planning, 159 Requirement, 168 RequirementDefault, 170 getResourceByName DatabaseActions, 138 getResourceName ActivityInfoWidget, 107 getResources DatabaseActions, 139 getResourceValue ActivityInfoWidget, 107 getSearcParam SelectPlanningUi, 189 getSelectedItem RemovePlanningController, 162 getSelectedListItem AddActivityUi, 113 getSelectedServicing EditServicingUi, 148 getSelectedTrain AddServicingUi, 127 EditServicingUi, 148 RemoveServicingUi, 167 getServicing DatabaseActions, 139 getServicingId Job, 151 getSidByName DatabaseActions, 139 getSolveId Resource, 173 getStartDate AddPlanningUi, 122 Planning, 159 SelectPlanningUi, 189 getStartPos ActivityBlock, 99 getStartTime ActivityBlock, 99


INDEX Job, 151 ScheduleWidget, 184 getTidByName DatabaseActions, 139 getTrain AddActivityDefaultUi, 111 getTrainId ActivityDefault, 103 Job, 151 Servicing, 191 getTrainList DatabaseActions, 140 getTrainTypes AddPlanningController, 119 getWidget AddActivityDefaultUi, 111 AddActivityUi, 114 AddServicingUi, 127 initializeAddActivityDefaultUi ActivityDefaultController, 105 initializeAddActivityUi AddPlanningController, 119 initializeAddJobUi AddPlanningController, 119 initializeAddPlanningUi AddPlanningController, 119 initializeAddResourceUi ResourceController, 175 initializeAddServicing ServicingController, 193 initializeAddViewer ViewController, 199 initializeEditResourceUi ResourceController, 175 initializeEditServicing ServicingController, 193 initializeRemovePlanningUi RemovePlanningController, 163 initializeRemoveServicing ServicingController, 193 Job, 149 activities, 153 addActivity, 150 getActivity, 150 getEndTime, 150 getId, 150 getName, 150 getServicingId, 151

207 getStartTime, 151 getTrainId, 151 Job, 149 setEndTime, 151 setId, 151 setName, 151 setServicingId, 152 setStartTime, 152 setTrainId, 152 toSolveString, 152 toString, 152 jobs Planning, 160 jobUiButtonAddRowClicked AddPlanningController, 119 jobUiButtonNextClicked AddPlanningController, 119 listSpacers AddViewer, 130 MainWindow, 153 createActions, 154 createMenus, 154 MainWindow, 154 planningOpened, 154 mouseDoubleClickEvent ActivityBlock, 99 mouseMoveEvent ActivityBlock, 99 ScheduleWidget, 184 mousePressEvent ActivityBlock, 99 ScheduleWidget, 184 mouseReleaseEvent ActivityBlock, 100 ScheduleWidget, 184 moveBlock ActivityBlock, 100 moveSplitter AddViewer, 130 NameHeader, 155 changeNrOfActivities, 156 createButtons, 156 createLabels, 156 createLayouts, 156 createSignals, 156 expand, 156 NameHeader, 155


208

INDEX paintEvent, 156 sizeHint, 157

next

ColorGenerator, 131

paintEvent ActivityBlock, 100 NameHeader, 156 ResourceHeader, 177 ResourceWidget, 179 ScheduleWidget, 185 TimeLine, 196 Planning, 157 addConstraint, 158 addJob, 158 addResource, 158 constraints, 160 getEndDate, 158 getName, 158 getResource, 159 getStartDate, 159 jobs, 160 Planning, 158 resources, 160 setEndDate, 159 setName, 159 setStartDate, 159 toString, 160 planningOpened MainWindow, 154 planningUiButtonNextClicked AddPlanningController, 119 planningUnsolvable ViewController, 199 processFinished Solver, 195 processOutput Solver, 195 ProgressUi, 160 createLayout, 161 createProgressBar, 161 ProgressUi, 161 updateProgress, 161 redetermineSize ResourceWidget, 179 removePlanningCheck RemovePlanningController, 163 RemovePlanningController, 161 buttonRemoveClicked, 162

fillList, 162 getSelectedItem, 162 initializeRemovePlanningUi, 163 removePlanningCheck, 163 RemovePlanningController, 162 removeSelectedPlanning, 163 removePlanningFromDb DatabaseActions, 140 RemovePlanningUi, 163 addItem, 164 createButtons, 164 createLabels, 164 createLayouts, 164 createLists, 165 createSignals, 165 getItem, 165 getNumberOfRows, 165 RemovePlanningUi, 164 removeSelectedPlanning RemovePlanningController, 163 removeServicing DatabaseActions, 140 RemoveServicingUi, 165 addItem, 166 addItems, 166 createButtons, 166 createComboBox, 166 createLabels, 167 createLayouts, 167 createLists, 167 createSignals, 167 getItem, 167 getSelectedTrain, 167 RemoveServicingUi, 166 Requirement, 168 getAmount, 168 getResource, 168 Requirement, 168 setAmount, 168 setResource, 169 toSolveString, 169 toString, 169 RequirementDefault, 169 getAmount, 170 getResource, 170 RequirementDefault, 170 setAmount, 170 setResource, 170 toString, 171 requirementDefaults


INDEX ActivityDefault, 104 requirements Activity, 96 resizeEvent ResourceWidget, 179 Resource, 171 getCapacity, 172 getId, 172 getName, 172 getSolveId, 173 Resource, 172 setCapacity, 173 setId, 173 setName, 173 toSolveString, 173 toString, 173 ResourceController, 174 buttonSaveClicked, 175 buttonUpdateClicked, 175 checkForSameNames, 175 initializeAddResourceUi, 175 initializeEditResourceUi, 175 ResourceController, 174 ResourceHeader, 175 changeAmount, 176 createLabels, 176 createLayout, 177 createSignals, 177 createSpinBox, 177 paintEvent, 177 ResourceHeader, 176 sizeHint, 177 resources Planning, 160 ResourceWidget, 177 calculateDemandProfile, 178 connectActivities, 179 createPoints, 179 paintEvent, 179 redetermineSize, 179 resizeEvent, 179 ResourceWidget, 178 sizeHint, 179 updateMap, 179 updatePixMap, 179 updateResourceAmount, 180 returnGrid AddJobUi, 116 returnName SaveNameWidget, 181

209 saveActivities DatabaseActions, 140 saveConstraints DatabaseActions, 141 saveInputToDb ActivityDefaultController, 105 saveJobs DatabaseActions, 141 SaveNameWidget, 180 createButtons, 181 createLabel, 181 createLayout, 181 createLineEdit, 181 createSignals, 181 returnName, 181 SaveNameWidget, 181 savePlanning DatabaseActions, 141 ViewController, 199 saveRequirement DatabaseActions, 141 saveResource DatabaseActions, 141 saveServicing DatabaseActions, 141 ServicingController, 193 saveServicingName DatabaseActions, 142 ScheduleWidget, 182 addActivity, 183 createLayout, 183 fixHeights, 183 getEndTime, 184 getJob, 184 getStartTime, 184 mouseMoveEvent, 184 mousePressEvent, 184 mouseReleaseEvent, 184 paintEvent, 185 ScheduleWidget, 183 setEndTime, 185 setStartTime, 185 setTimes, 185 sizeHint, 185 toggleSchedule, 186 updateBlocks, 186 updateDate, 186 SelectPlanningUi, 186 addItem, 187 clearLineEdit, 187


210

INDEX

clearList, 188 controlDate, 188 createButtons, 188 createDateEdits, 188 createLabels, 188 createLayouts, 188 createLineEdits, 188 createLists, 188 createSignals, 188 getEndDate, 188 getItem, 189 getNumberOfRows, 189 getSearcParam, 189 getStartDate, 189 SelectPlanningUi, 187 setDates, 189 Servicing, 190 addActivityDefault, 190 getName, 190 getTrainId, 191 Servicing, 190 setName, 191 setTrainId, 191 toString, 191 ServicingController, 191 buttonAnotherOneClicked, 192 buttonRemoveClicked, 192 buttonSaveClicked, 193 buttonUpdateClicked, 193 initializeAddServicing, 193 initializeEditServicing, 193 initializeRemoveServicing, 193 saveServicing, 193 ServicingController, 192 servicingTypeChanged, 193 trainTypeChanged, 193 updateForm, 193 updateServicingList, 194 servicingTypeChanged ServicingController, 193 setAmount Requirement, 168 RequirementDefault, 170 setCapacity Resource, 173 setChecked Activity, 94 setColor ActivityBlock, 100 setDates

SelectPlanningUi, 189 setDuration Activity, 94 ActivityDefault, 103 setEndDate Planning, 159 setEndPos ActivityBlock, 100 setEndTime ActivityBlock, 100 Job, 151 ScheduleWidget, 185 setEst Activity, 94 setFinished Activity, 94 setHeight ActivityBlock, 101 setId Activity, 94 Job, 151 Resource, 173 setJobId Activity, 95 setName Activity, 95 ActivityDefault, 103 Job, 151 Planning, 159 Resource, 173 Servicing, 191 setResource Requirement, 169 RequirementDefault, 170 setServicingId Job, 152 setStartDate Planning, 159 setStartPos ActivityBlock, 101 setStartTime ActivityBlock, 101 Job, 152 ScheduleWidget, 185 setTimes ScheduleWidget, 185 setTrainId ActivityDefault, 103 Job, 152 Servicing, 191


INDEX showSelectPlanningUi ViewController, 199 sizeHint ActivityBlock, 101 NameHeader, 157 ResourceHeader, 177 ResourceWidget, 179 ScheduleWidget, 185 solvedPlanning ViewController, 199 solvePlanning ViewController, 199 Solver, 194 execute, 195 executeBinary, 195 processFinished, 195 processOutput, 195 TimeLine, 195 createLayouts, 196 paintEvent, 196 TimeLine, 196 toggleSchedule ScheduleWidget, 186 toSolveString Activity, 95 Constraint, 132 Job, 152 Requirement, 169 Resource, 173 toString Activity, 95 ActivityDefault, 103 Constraint, 132 Job, 152 Planning, 160 Requirement, 169 RequirementDefault, 171 Resource, 173 Servicing, 191 trainTypeChanged ServicingController, 193

211 ServicingController, 193 updateMap ResourceWidget, 179 updatePixMap ResourceWidget, 179 updatePlanning AddPlanningController, 120 updateProgress ProgressUi, 161 updateResourceAmount ResourceWidget, 180 updateResources ActivityBlock, 101 updateServicingList ServicingController, 194 ViewController, 196 addActivities, 198 addJobs, 198 addResourceNames, 198 addSpacers, 198 buttonShowClicked, 198 generateConstraints, 198 initializeAddViewer, 199 planningUnsolvable, 199 savePlanning, 199 showSelectPlanningUi, 199 solvedPlanning, 199 solvePlanning, 199 ViewController, 198 writePlanningToDatabase AddPlanningController, 120

updateActivityGrid AddPlanningController, 120 updateBlocks ScheduleWidget, 186 updateDate ScheduleWidget, 186 updateForm Generated on Thu Jul 28 2011 16:44:01 for ’Bachelorproject Nedtrain’ by Doxygen

Onderhoudsplanner Nedtrain

Recommend Documents