Ontwerpen
O1
Beschrijving
Ik kan een ontwerp opstellen voor een (deel van een) softwaresysteem en ik maak hierbij gebruik van bestaande componenten en libraries.
Bewijs volgens Stageplan
Gemaakte UML-diagrammen, zoals klasse diagram, waarin het gebruik van bestaande componenten en libraries terugkomen, om de samenwerking van deze onderdelen weer te geven.
Notitie: In plaats van een klasse diagram waarin de samenwerking van de onderdelen weergegeven worden, maak ik gebruik van activiteitendiagrammen. Dit heeft de reden dat een klasse diagram van het systeem veel te veel inhoud zou krijgen, waardoor het onduidelijk zou worden hoe de samenwerking in elkaar zit, omdat het systeem inmiddels een hele grote vorm aangenomen heeft.
Bewijs
RiverScout heeft vier modules: core, api, graphhopper en graph-visualizer.
Core
Core is hier de belangrijkste module, alle andere modules hangen namelijk af van de werking en componenten binnen die module. De module is bijvoorbeeld verantwoordelijk voor alle handelingen met de Mongo database en heeft de belangrijkste logica in zich. Bijvoorbeeld de logica om grafieken op te bouwen vanuit verschillende bronnen en deze samen te voegen tot één grafiek. Ook zit alle informatieverwerking en opslag van gegevens over routes hierin geïmplementeerd.
API
API is de module die het belangrijkst is voor contact naar de buitenwereld. Hier zijn namelijk controllers geïmplementeerd die verschillende aanvragen kunnen afhandelen. Zoals het opvragen van routes, gegevens over objecten en lijnen in verschillende grafieken en beheergegevens.
De API is gebouwd op Spring Boot en gebruikt Swagger om de API van documentatie te voorzien.
GraphHopper
GraphHopper is de module die de implementatie heeft van de route engine, namelijk graphhopper. Hierin worden de grafieken en indexes geladen om daadwerkelijk routes te kunnen genereren aan de hand van de aanvraag bij de API.
Graph-visualizer
De graph-visualizer is een module waarin de desktop-applicatie die gebruik maakt van JavaFX staat geïmplementeerd. In deze applicatie kunnen alle gegevens van de grafiek worden ingezien om te controleren of de grafiek en zijn gegevens correct zijn.
Ontwerpen
Context diagram van de verschillende onderdelen in en buiten RiverScout
Context diagram met opsplitsing van RiverScout modules
De afhankelijkheid van verschillende modules in RiverScout
Component diagram van de verschillende componenten in RiverScout
Samenwerking
In de activiteitendiagrammen die hieronder zijn weergegeven is de samenwerking van de verschillende delen van RiverScout te zien. Hierin zijn ook het gebruik van bestaande componenten en libraries te zien, zoals Spring Boot, Swagger en GraphHopper.
Initialiseren van RiverScout
Bij het initialiseren van RiverScout worden alle modules in het project gebruikt. Op het moment dat RiverScout opgestart wordt op een systeem dan wordt als eerste de API geïnitialiseerd.
Vervolgens wordt de core aangeroepen, hierin wordt de informatie verkregen van de database voor de huidige te gebruiken grafiek. Daarna wordt de gesimplificeerde grafiek ingeladen, de indexes van GraphHopper aangemaakt en vervolgens wordt een sandbox aangemaakt met de informatie die GraphHopper gemaakt heeft. Hierna wordt de informatie van de sandbox ververst en wordt deze op 'live' gezet. Ten slotte wordt voor de API aangegeven dat alle informatie gecached is en er aanvragen gedaan kunnen worden hiernaar.
Opvragen, verwerken en teruggeven van routes
Bij de aanvraag voor routes worden ook alle modules in het project gebruikt. Als eerste doet een gebruiker de aanvraag om routes terug te krijgen, hiervoor moet de gebruiker een aantal gegevens meesturen. Eenmaal verstuurd ontvangt de API deze aanvraag en vraagt de sandbox op van de core, deze sandbox kan de 'live' sandbox zijn of een andere sandbox die ingeladen is (de gebruiker kan dit zelf aangeven en anders is het standaard de 'live' sandbox).
De API verwerkt de input en kijkt of alle ingegeven locaties gebruikt kunnen worden, als dit niet het geval is stuurt de API een bericht terug naar de gebruiker dat er een fout opgetreden is. Als alle locaties wel correct zijn worden in GraphHopper de routes berekend. De API ontvangt deze berekende routes en als er geen routes gevonden zijn geeft deze het aan de gebruiker aan, anders gaat de API verder met de verwerking.
Vervolgens een belangrijk deel van de verwerking, verzekeren dat het schip daadwerkelijk op die routes kan varen. Hiervoor worden alle gesimplificeerde routes omgevormd naar gedetaileerde routes, hierna wordt gecontroleerd of het schip over de routes kan varen. Ten slotte worden de routes verwerkt, zodat alleen nuttige en valide routes teruggegeven worden voor de schipper. De API maakt vervolgens de resultaten in orde en geeft deze terug aan de gebruiker.
Updaten van de grafiek
Voor het updaten van een grafiek wordt alleen de core module gebruikt. Er zijn verschillende stappen die de module ondergaat om de grafiek op te bouwen.
Als eerst worden alle standaardgrafieken ingeladen, als de versie van de standaardgrafiek verschilt dan wordt deze nieuwe versie opgeslagen. Daarna worden de opgeslagen grafieken gecombineerd om één grafiek te maken die alle gegevens bevat. Voor het schrijven van de uiteindelijke grafiek wordt de opgeslagen grafiek ingeladen samen met de handmatige input en gecombineerd om de volledige grafiek gereed te maken. De volledige grafiek wordt dan opgeslagen in de database en worden er routes voor gegenereerd. Ten slotte wordt een KML bestand gegenereerd en het proces afgesloten.
Feedback
Tijdens de demo's worden de delen van het software systeem besproken met de product owner. Hiervoor worden deze delen gevisualiseerd door bijvoorbeeld het maken van schetsen op het whiteboard voor het RiverScout project. Daarnaast valt de keuze van technology stack goed binnen Teqplay.
Reflectie
Ik heb heel veel gebrainstormd voor het maken van het ontwerp en vervolgens het implementeren hiervan. Bij het ontwerp heb ik gelet op de wensen van de product owner en de opgestelde requirements. Zo let ik bijvoorbeeld op de schaalbaarheid, onderhoudbaarheid en efficiëntie van de routeplanner.
O2
Beschrijving
Ik kan een validatie voor m’n ontwerp uitvoeren op basis van specificaties uit de (eerder gemaakte) analyse.
Bewijs volgens Stageplan
Het gemaakte ontwerp valideren met de opgestelde requirements en dit verwerken in een verslag.
Bewijs
Het ontwerp van Riverscout moet voldoen aan de genoemde requirements bij Analyseren 2.
Hieronder worden de verschillende requirements benoemd met de specificaties in het ontwerp, eindigend met een conclusie voor de validatie van het ontwerp.
Het aanmaken van de grafiek door middel van bronnen van onder andere Rijkswaterstaat
Het aanmaken (en updaten) van de grafiek gebeurd door het samenvoegen van verschillende bronnen. Om deze samenvoeging goed te kunnen beheren zijn er verschillende lagen waardoor de grafieken zich vervormen tot de volledige grafiek.
De werking hiervan staat bij de volgende delen beschreven:
- de uitleg over het samenvoegen van verschillende grafieken in RiverScout
- het samenvoegen van verschillende grafieken van verschillende versies en bronnen
De werking hiervan staat in dit ontwerp.
De volledige grafiek beschikbaar stellen via een API
De volledige grafiek is beschikbaar gesteld via de API module in RiverScout en wordt voornamelijk gebruikt voor het visualiseren van de grafiek in de frontend van RiverScout.
Het visualiseren in de frontend is te zien bij het resultaat van RiverScout.
De werking hiervan staat in dit ontwerp.
Het beschikbaar stellen van het opvragen van routes door middel van een API
Het opvragen van routes gebeurd via het sturen van een aanvraag naar de API module van RiverScout.
De werking hiervan staat in dit ontwerp.
De aanvraag voor routes snel afhandelen en routes teruggeven, rekening houdend met bijvoorbeeld de dimensies van een schip
Bij het opvragen van routes wordt de input van een gebruiker, zoals de dimensies van een schip, verwerkt in de aanvraag voor routes.
De verwerking van deze input gebeurd bij de acties 'Process input' en 'Process results' in dit ontwerp.
Soortgelijke (of betere) resultaten krijgen in vergelijking met de huidige routeplanner
Deze requirement is niet direct te valideren door middel van een ontwerp. Echter is de mogelijkheid om zelf grafieken op te sturen en aan te passen en de mogelijkheid om handmatige input te combineren, een functionaliteit die de huidige routeplanner niet biedt aan Teqplay. Een uitleg van het beheersysteem staat beschreven bij het samenvoegen van verschillende grafieken van verschillende versies en bronnen.
Bij het ontwerpen en implementeren is wel rekening gehouden met het zelf kunnen maken van grafieken en zijn de resultaten en het gedrag van de huidige routeplanner gebruikt als vergelijkingsmiddel. Als bewijs dat RiverScout goed ontworpen is, volgt uit het resultaat van RiverScout.
Het openstellen van alle routes in de grafiek, het ingeven van zelfgemaakte routes en het aanpassen van routes
Alle routes en de bijbehorende informatie zijn opengesteld door middel van de API module, daarnaast kunnen zelfgemaakte routes ingegeven worden en alle routes uit de grafieken worden aangepast.
De werking hiervan staat in dit ontwerp.
De gebruiker kan alle operaties zelf versturen maar kan deze ook via de frontend van RiverScout gebruiken.
Het kunnen testen van zojuist aangemaakte routes
Het kunnen testen van routes zit verwerkt in het aanmaken en updaten van een sandbox. Deze sandbox kan dan gebruikt worden om de volledige grafiek te testen inclusief de veranderingen die gemaakt zijn.
De werking hiervan staat in dit ontwerp.
Conclusie
Concluderend voldoen de ontwerpen aan alle requirements, daarnaast zijn aan de requirements en de implementatie van RiverScout ook te herleiden welke ontwerpen daarvoor gemaakt zijn. De verschillende ontwerpen die gemaakt zijn voor RiverScout dekken de verschillende onderdelen voor de routeplanner. Van het aanmaken en updaten van de grafiek tot het beschikbaar stellen hiervan en het aanvragen en testen van routes.
Feedback
De applicatie voldoet aan de kwaliteitseigenschappen van Teqplay.
De realisatie van de gemaakte ontwerpen hebben ervoor gezorgd dat de applicatie stabiel kan draaien en voldoet aan de requirements en verwachtingen van de product owner.
Reflectie
Bij het ontwerpen van het systeem voor de routeplanner heb ik constant gelet op de requirements en waar nodig de ontwerpen bijgesteld om aan deze requirements te voldoen. Om dit te bereiken heb ik veel gelet op de wensen van de product owner en de stabiliteit van de implementatie en eventueel ontwerpen aangepast.