Integratie met PTV Developer
Maiko Kingma
Recent heeft het R&D team de integratie van PTV Developer op zich genomen. Dit product levert net als xServer2 belangrijke functies voor een ritplanning tool zoals geocoderen, rit berekenen en rit optimalisatie. Als opvolger van xServer1 (TALIS) en xServer2 (IMPACT) zal PTV Developer uiteindelijk beide systemen permanent vervangen.
Het TALIS-team was genoodzaakt de integratie direct op te pakken vanwege de korte levensduur van xServer1. Voor xServer2 is dit voorlopig nog niet het geval. Toch hebben beide teams de implementatie van PTV Developer opgepakt om zo meer profijt te kunnen maken van kennisdeling en meer te leren over hoe IMPACT hier gebruik van maakt.
Kennisbehoud
Een van de grootste uitdagingen bij het ontwikkelen van software is het behouden van kennis en kunde. Tegelijkertijd wil je ook dat het product zo min mogelijk onderhoud nodig heeft, zodat de focus op nieuwe functionaliteiten gelegd kan worden. Hierdoor kan je wel eens in de situatie komen dat oude functies na een paar jaar en een aantal verschillende ontwikkelaars uit het oog worden verloren. En dat brengt een aantal risico’s met zich mee. Zo wordt het lastiger om functies uit te breiden als je niet bekend bent met het originele ontwerp en kost het meer tijd om te reageren op veranderingen van een derde partij.
Hierbij geeft de introductie van PTV Developer een unieke kans om tijd te investeren in het toepassen van een routeplanningsysteem van PTV en daarbij de lessen die we de afgelopen jaren hebben geleerd toe te passen. Zo vervangen we niet alleen het achterliggende systeem, maar verversen we ook de kennis van het team.
Ontwerp
Bij het ontwerpen van softwaresystemen met een lange levensduur is het niet altijd mogelijk om te voorzien welke wensen er over een paar jaar onthuld worden. Zo kan de ontwikkeling van IMPACT worden beïnvloed door wetgeving, partners en klanten. Een goed voorbeeld hiervan zijn de nieuwe wetgevingen rondom emissie berekeningen.
De truc hierbij is om de applicatie op te zetten als een collectie aan puzzelstukjes die mooi in elkaar passen.
Zo is deze strategie ook toegepast bij het vervangen van het implementeren van PTV Developer. We zijn gestart met het toevoegen van een nieuwe interne interface genaamd Routing. Net als de Application Programming Interface (API) van PTV specificeert deze interface welke informatie op en neer gestuurd kan worden om bepaalde acties uit te voeren. In ons geval specificeert dit welke informatie IMPACT beschikbaar heeft om een berekening te starten en welke informatie IMPACT verwacht als resultaat.
In tegenstelling tot de vorige versie van het design, waarbij het resultaat van xServer2 direct werd toegepast op de IMPACT rit, brengt dit twee voordelen met zich mee. Als eerste geeft het ons de mogelijkheid om de code uniek voor xServer2 te scheiden van de rest. Nu bevat onze xServer2 en PTV Developer implementatie dus alleen het vertalen van de PTV-data naar de Routing interface en niet het verwerken van de data. Hierbij is het verwerken significant meer werk dan het vertalen.
Als tweede specificeert de interface ook een relatief kleine dataset die van belang is voor IMPACT waardoor de complexiteit behoorlijk verminderd en het begrijpen van deze code een stuk gemakkelijker wordt. Je hoeft tenslotte niet meer een grote API van PTV te begrijpen, omdat deze binnen IMPACT al wordt vertaald naar een kleine interface, gemaakt met terminologie zoals elders in de applicatie al gebruikt wordt. Hierdoor wordt niet alleen het implementeren van PTV Developer gerealiseerd, maar wordt ook het toekomstig onderhoud verminderd en krijgen we de optie om functionaliteiten te vervangen of toe te voegen wanneer nodig.
Een les geleerd
Een goed voorbeeld van een geleerde les is hoe we de informatie omtrent locaties met PTV delen. PTV verwacht een lijst van wat zij waypoints noemen. Een waypoint is een specificatie van waar de locatie is, hoe laat je daar zou kunnen aankomen (openingstijden/afgesproken levertijden) en hoe lang je daar bezig bent. Bij de xServer2 implementatie werd dit gedaan door van elke stop een waypoint te maken met als duur een optelsom van alle taken in die stop.
Voor lange tijd is dit voldoende geweest voor IMPACT omdat de functies die wij nu willen toevoegen in het originele ontwerp niet van toepassing waren. Zo hebben wij nu locatie onafhankelijke taken (bijvoorbeeld pauzes) en willen we wachttijden (lege ruimte) zichtbaar maken. Hierdoor is het nu gewenst dat elke taak die PTV voor ons moet plannen een uniek waypoint wordt, waardoor PTV kan begrijpen dat er ruimte is tussen taken en deze eventueel te gebruiken is om een wettelijke verplichte pauze te plannen.