Een mogelijk knelpunt in het project is dat er op het raak
vlak van XML/GML en objectmodellering weinig kennis be
schikbaar is - net zo min bij ProRail als in de markt. Deze
kennis moet dus tijdens het project worden ontwikkeld.
Hier moet een belangrijk risico worden onderkend: wat als
de gevraagde kennis te diepgaand of specifiek is om zelf
standig op te bouwen? Om dit risico te verminderen, wordt
de mogelijkheid open gehouden om externe kennis van
buiten ProRail in te zetten.
De uitvoering van de pilot wordt vervolgens ingericht aan
de hand van de volgende stappen:
1. ontwerp van het gegevensmodel;
2. inrichting van een database;
3. opstellen van een GML-schema;
4. ontwikkelen van een export-script;
5. exporteren van gegevens naar GML;
6. opstellen en versturen van de wijzigingsopdracht naar
leveranciers;
7. importeren van gewijzigde GML-gegevens.
Alvorens er geëxporteerd kan worden, moet er een database
zijn met gegevens over de railinfrastructuur. Zoals eerder
geconstateerd, is er binnen ProRail niet één database met
gestructureerde gegevens die daarvoor als uitgangspunt kan
dienen: er zijn juist vele databases die vaak eerder CAD- en ras-
terbestanden bevatten, dan objectgerichte gegevens voorzien
van syntax en semantiek. Er moet dus een database worden
ontworpen die als bron kan dienen voor de gegevensexport.
De volgende belangrijke constatering is dat het best gemak
kelijk zou zijn wanneer het gegevensmodel van de database
en het gegevensmodel van het GML-bestand overeen zou
den komen. Binnen de pilot wordt daarom al snel besloten
om eerst een gegevensmodel te ontwerpen dat als basis zal
dienen voor zowel de database als het exportbestand.
Gelukkig is het project voor dat gegevensontwerp niet volle
dig op zichzelf aangewezen. Er is namelijk binnen ProRail een
zogenaamde 'Objectenstructuur' beschikbaar. Deze objecten
structuur zou de basis moeten zijn voor de grootscheepse ob-
jectisering van de informatiesystemen. Theoretisch dus een
mooie basis voor het gegevensmodel voor de pilot.
Na enig onderzoek wordt vervolgens besloten om het gege
vensmodel te definiëren in de UML-schematielc (Unified Mo
delling Language). Deze beslissing is genomen op basis van
de volgende argumenten:
vastleggen in een strak omlijnde standaard als UML voor
komt onduidelijkheden en vaagheden. Dubieuze of mul-
ti-interpretabele constructies komen in UML vrij snel
bovendrijven - dit zou wellicht anders pas bij het tech
nisch ontwerp van de database of het GML-schema aan
het licht komen;
Het gegevensmodel zou omwille van uitwisselbaarheid
van gegevens, met andere grote civiele opdrachtgevers,
moeten aansluiten op de NEN3610-standaard. Deze stan
daard is op het moment dat de pilot start net definitief ge
worden - en vastgelegd in UML. Dit werlc is grotendeels uit
gevoerd op de TU Delft, waar ProRail ook contacten heeft
en daarmee de aanwezige kennis en hulp kan gebruiken;
via de TU Delft wordt ook ontdekt
dat er een open source Java-pro-
gramma beschikbaar is dat UML-be-
standen direct converteert naar een
GML-schema.
Fig. l.Aanslui- Gegevensmodel: hoe de theorie de praktijk
ting RailGML en ontmoette
NEN3610. Het pilotproject gaat vervolgens hoop
vol aan de slag om de ProRail-objec
tenstructuur vast te leggen in UML.
Het uitgangspunt daarbij zijn de docu
menten in Microsoft Word en Excel die
tot dat moment zijn gebruikt. Tijdens
het proces van omzetting naar UML
blijkt hoe strak de eisen zijn die UML
stelt: verschillende onduidelijkheden
en zaken die voor meerdere uitleg vat
baar zijn, blijken hun weg gevonden te
hebben naar de objectenstructuur. Het
zijn voor een informatie-analist her
kenbare zaken:
wat is in de oorspronkelijke struc
tuur de relatie tussen elementen
en direct ondergelegen elementen?
Het blijkt de ene keer te gaan om de
Stap 1: Ontwerp van het gegevensmodel
class Aansluiting NEN3610 J7"
O.."
realisatie; lange teimijn
buiten bedrijf, buiten gebruik. geslotei
niet meer aanwezig
beginTijd: DateTime [0..1)
eindTijd: DateTime [0..1J
geometriePoint: GM_Point (01
geometrieCurue: GM_Cun/e [0..1J
geometrieSurface: GM_Surface [0..1]
identificatie; CharacterStiing
locatie: Locatie
naam: ScopedName [0..*l
object8eginTijd: DateTime (0..1j
objectEindTijd: DateTime (0..1J
status: Status [0..1)
versieBeginTijd: DateTime [0..1J
veisieEindTijd: DateTime (0..1)
Aanschafdatum: Date [0..1J
Aansch afwaaide: Integer {0..1]
AantalSamenstellendeElementen: Integer {0..1J
bouwdatum: Date J0..1)
Buitendienststellingdatum: DateTime (0..1)
EconomischeLevensduur. Integer p..t]
Eigenaar: CharacterStiing {0..1]
Fabrikant: CharacteiString [0..1]
Indienststellingsdatum: DateTime £0..1]
Leverancier: CharacterStiing JQ..1)
QbjectlD: Integer [0..1J
Objectnaam: CharacterString [0..1]
SpoorbaanObjectStatus: SpoorbaanObjectStatus [0.1]
TechnischeLevensduur: Date [0..1]
Tekeningnummer: Integer [01
«FeatureType»
SpoorbaanObjecI
GEO-INFO 2007-7/8
