samenhang geborgd blijft tussen de af
geleide productmodellen.
De eerste stap in het ontwilckelpro-
ces van een nieuw product is het im
porteren van het IMKAD-model in de
Enterprise Architect werkomgeving.
Hiervoor bestaat een standaard UML-
uitwisselformaat, XMI. Nadat het IM-
KAD-model is geïmporteerd, kunnen
in het productmodel klassen uit IM
KAD gebruikt worden.
Ten behoeve van een duidelijke bericht-
structuur kan in het productmodel
een hiërarchie bovenop IMKAD-klassen
gelegd worden; dat wil zeggen, de IM
KAD-klassen kunnen gegroepeerd wor
den door overkoepelende klassen. In
onderstaand voorbeeld is een bericht
Hiërarchische struc
tuur productmodel
met IMKAD-klassen.
'plusklassen' populair geworden) definiëren. Deze plusklas
sen erven de attributen en relaties van de bovenliggende
klasse in IMKAD en kunnen daarnaast hun eigen attributen
en relaties toevoegen. KadastraleAanduidingPlus linksonder
in de afbeelding op de linkerkolom is hier een goed voorbeeld
van. In IMKAD is er een attribuut gemeente waarin de naam
van de gemeente wordt opgenomen maar in dit product was
het nodig om de gemeentecode op te nemen.
Een belangrijk onderdeel van informatiemodellen is de do
cumentatie. In de productmodellen wordt de documentatie
van alle klassen, attributen en relaties vastgelegd in Enter
prise Architect. Hieruit wordt documentatie gegenereerd in
RTF- en HTML-formaat.
De productmodellen modelleren informatie die uiteinde
lijk als XML-berichten wordt uitgewisseld. XML is hiervoor
zeer geschikt omdat het een generiek formaat is waarvan
de structuur en regels conform het eigen informatiemodel
kunnen worden bepaald. Deze structuur en regels worden
vastgelegd in een zogeheten XML-schema.
PostcodeTreffers gemaakt. Dit bericht
bevat informatie over onroerende za
ken op basis van een postcode. Het
bericht bevat een begin met wat gege
vens over het bericht, gevolgd door een
aantal onroerende zaken, een aantal
rechten en een aantal personen, met
tenslotte nog een afsluiting. De Onroe
rende Zaak, Recht, en Persoon klassen
komen uit IMKAD, terwijl de overkoe
pelende berichtklasse genaamd Postco
deTreffers en de klassen voor begin en
einde van het bericht uit het product
model komen.
In het productmodel kunnen attribu
ten en relaties waar nodig aan klassen
uit het IMKAD-model toegevoegd wor
den. Productmodellen mogen hiertoe
IMKAD niet wijzigen maar kunnen wel
specialisatieklassen (afgeleide klassen:
binnen het Kadaster is hiervoor de term
XML-schema genere
ren uit modellen.
Uit zowel IMKAD als de productmodellen worden XML-sche
ma's automatisch gegenereerd. Deze XML-schema's worden
gebruikt als technische specificatie van uitgaande berichten
en ter validatie van binnenkomende berichten van de ver
schillende producten. In eerste instantie werd voor het gene
reren van de XML-schema's de tooi ShapeChange gebruikt.
Bij de meest actuele IMKAD-versie is dit nog het geval. Bij
het definiëren van de productmodellen bleek het hanteren
van deze tooi echter veel (bruikbaarheids)problemen op te
leveren. ShapeChange is bovendien specifiek gericht op het
genereren van GML-Application Schema's, terwijl het voor
een deel van de producten nodig is om een XML-schema te
genereren dat niet op GML gebaseerd is. Daarom is overge
stapt op de standaard functionaliteit voor het genereren
van XML-schema's in Enterprise Architect. Deze functiona
liteit bleek voor de modelleurs gemakkelijker te gebruiken
en de resulterende XML-schema's zijn eenvoudiger.
De door Enterprise Architect gegenereerde XML-schema's
moeten nog wel een nabewerking ondergaan om helemaal
valide en waar nodig GML conform te worden. Deze nabe
werking is geautomatiseerd met XSLT, een programmeer
taal die speciaal bedoeld is voor het vertalen van XML struc
turen naar andere structuren.
MDA in de praktijk
XML-schema's
export
import
import
101
ip-OOÏlC&OWoflC'SO'
»XSOe«mpl«xTïp.
fciilJïtewMtijifis.
psom Koopsom *5.1)
JiiviKMippsRoul*' Lju-
«'KhUnflsfioole (O. tJ
.OjU1>po.
OruS«óelen:'.K»dwttaieAar>Oji<JrA9
GEO-INFO 2008-3
