MIM (Metamodel voor Informatiemodellen) beschrijft een methodiek voor het vastleggen van de structuur van informatie. Het MIM kan bijvoorbeeld worden gebruikt om een model voor fietswinkels vast te leggen. Dit document beschrijft hoe je zo’n model kunt opstellen, en refereert waar nodig naar de standaard zelf.
Na een algemene introductie op het MIM en de noodzaak daarvan worden de aspecten van een informatiemodel conform MIM besproken: vanuit informatiemodel en informatiedomeinen wordt afgedaald naar attributen, typen, en andere modelonderdelen, en gaandeweg worden de metagegevens daarvan behandeld. In een apart hoofdstuk worden thema’s besproken die de verschillende aspecten van het metamodel met elkaar gemeen hebben. Het document eindigt met een uitgebreid voorbeeld in UML.
In bijlagen worden enkele handige overzichten van modelelementen en metagegevens opgenomen.
Dit document nadert versie 1.0. Een review ronde is afgesloten op 15 febr 2022. De eindversie wordt gepresenteerd op het eerstvolgende MIM community overleg.
Dit document is beoordeeld door:
Thies Mesdag (Kadaster)
Danny Greefhorst (ArchiXL)
Jos van der Arend (Kennisnet)
Lennart van Bergen (Kadaster)
Paul Jansen (Geonovum)
Laatste bewerking op 2022-03-09 om 10:25:42.
Openstaande vragen zijn:
Moeten we 1/ Demonstrator screenshots opnemen in de lopende tekst (ter illustratie), 2/ naar een bijlage verplaatsten, of 3/ verwijderen uit deze Primer?
Moeten we referenties vanuit het Fietsenwinkel voorbeeld naar de Primer tekst opnemen?
Voldoet het referentiesysteem (visueel en functioneel)?
Inleiding
Een MIM informatiemodel beschrijft een deel van de werkelijkheid waarover we op een voorspelbare manier informatie willen inwinnen, registreren of uitwisselen. Dat kan in taal, op papier, of natuurlijk via ICT systemen. Onderdelen van een informatiemodel keren terug in elektronische berichten, databases, gebruikersinterfaces et cetera. Een helder en geaccepteerd informatiemodel staat aan de basis van een scala aan toepassingen, die daarmee de “echte” wereld en de technische ondersteuning daarvan verbindt.
Informatiemodellen kunnen bedoeld zijn om informatie in kaart te brengen, zonder daarbij rekening te houden met technische implicaties; deze modellen noemen we conceptueel. Daarnaast kunnen modellen bedoeld zijn om aan te sluiten bij de technische uitwerking in berichten, databases of anderszins. Deze noemen we logische modellen. Beide soorten modellen kunnen naast elkaar worden ontwikkeld en zijn doorgaans sterk gerelateerd.
In deze Primer gebruiken we een fictieve fietsenwinkel als onderwerp om de elementen van het MIM en hun toepassing in een informatiemodel te tonen. Terwijl fietsen worden gemaakt, verhandeld en bereden (de echte wereld) is er een technische, administratieve wereld die dit ondersteunt. In de techniek komen concepten voor die in de echte wereld zijn benoemd: Fiets, Klant, Framenummer, Verkoop. Het informatiemodel brengt deze met elkaar in verband.
In MIM zijn deze concepten getypeerd: een “Fiets” is een Objecttype; een “Framenummer” is een Attribuutsoort; “verkocht aan” is een Relatiesoort.
Deze concepten zouden we, als we met elkaar samenzitten om samen het interessedomein in kaart te brengen, waarschijnlijk tekenen met bolletjes, vakjes en pijltjes, of in een tabel opnemen, of anderszins een concrete vorm geven waar we met elkaar naar kunnen kijken. Die vorm is echter niet waar het MIM in eerste instantie over spreekt. Het MIM definieert welke modelelementen er zijn en hoe die samenhangen, onafhankelijk van de visuele representatie. Daarnaast wordt wel een visuele representatie daarvan besproken (UML). En een mogelijke technische serialisatie daarvan (LD).
Globale opzet van de standaard
De MIM standaard bestaat uit 3 delen, die op zich los van elkaar kunnen worden gelezen. Het eerste deel is de uitwerking van de soorten modelelementen en hun metagegevens. Bijvoorbeeld: een Objecttype (modelelement) heeft een definitie (metagegeven). Het tweede deel is de realisatie daarvan in de vorm van een UML klassendiagram. Bijvoorbeeld: Een objecttype wordt een UML klasse, de definitie een tekst in het notitieveld. Het derde deel is de Linked data serialisatie van deze constructies. Bijvoorbeeld: Een objecttype is een klasse in RDF Schema. Een definitie is een eigenschap van deze klasse.
Daarnaast zijn allerlei afspraken en regels opgenomen die MIM zelf beperken. Zo wordt vastgelegd welke primitieve datatypes MIM zelf al kent, en hoe je zelf nieuwe datatypes kunt afleiden van deze primitieve datatypes.
Naast de standaard zelf is een Handreiking Informatie Modelleren en een beheerplan beschikbaar. De Handreiking Informatie Modelleren is geschreven in de context van de DSO, en betreft het gebruik van UML voor logische informatiemodellen en de inrichting van het modelleringswerkproces van stakeholders. Het document stelt vast welke keuzes binnen DSO worden gemaakt in de vrijheden die MIM biedt en de software die beschikbaar is. Het MIM-beheerplan stelt vast op basis waarvan het beheer van het MIM wordt uitgevoerd. Dit plan geeft inzicht in de inhoud en omvang van de relevante beheerprocessen en welke middelen en functieprofielen hiervoor nodig zijn.
Deze Primer is een aanvulling op deze documentatie, en is niet normatief.
Over dit document
Het doel van dit document is om een redelijk compleet beeld van het MIM te geven, met voorbeelden uit de UML realisatie. Het gaat niet op alle aspecten in, maar geeft een goede introductie voor de analist, die wordt gevraagd een informatiemodel op te leveren conform deze standaard.
Dit document behandelt het MIM vanuit de structuur van een informatiemodel: we starten met de grove opbouw van het informatiemodel, dalen af naar de begrippen en hun relaties, en gaan als laatste in op de eigenschappen daarvan. We raden aan het document dan ook in deze opeenvolging te lezen.
In een apart hoofdstuk werken we allerlei detailaspecten uit zoals naamgevingseisen, identificatie van onderdelen, en historie.
We plaatsen veel verwijzingen in de tekst, in de verwachting dat de lezer daarmee gemakkelijker de complexe structuur “onder de knie” kan krijgen. De verwijzingen hebben de volgende vorm:
Verwijzing naar de MIM standaard. Bijv.: Objecttype
Verwijzing naar een eerder behandeld metagegeven. Bijv.: Begrip.
Verwijzing naar het voorbeeld model. Bijv. Fiets.typenummer.
Het voorbeeld UML model, de Fietsenwinkel, wordt volledig gedocumenteerd als bijlage opgenomen in deze Primer.
We hopen dat deze Primer de lezer op deze manier voldoende basis geeft voor het begrijpen en toepassen van de MIM standaard.
Voorbeeld informatiemodel: Fietsenwinkel
In deze Primer werken we met een voorbeeld informatiemodel. Dit informatiemodel is conceptueel van karakter: het beschrijft de concepten die een rol spelen in de administratie van een fietsenwinkel, zonder daaraan technische conclusies te verbinden.
In de MIM standaard wordt een voorschot genomen op hoe de MIM modelelementen (zoals objecttypen, relaties, waardenlijsten) moeten worden gerealiseerd (getekend in UML, omgezet in Linked Data RDF), maar op zich vormen het metamodel en de afspraken en regels voldoende basis voor consensus over wat we willen kunnen registreren of uitwisselen voor een willekeurig informatiemodel. Het is dan ook belangrijk om deze opbouw onafhankelijk van de uitwerking in UML of Linked data of welke (beeld)taal dan ook te begrijpen.
Fietsenwinkel in tekst
Wanneer we een informatiemodel willen maken van onze Fietswinkel kunnen we het domein beschrijven in tekst. Daarin treffen we de belangrijkste concepten/begrippen aan die rol gaan spelen in toepassingen van het model. De details volgen in een latere fase.
Citaat:
Fietsenwinkels zijn Winkels waarin Fietsen worden verhandeld. Deze Fietsen worden geleverd door Leveranciers, en verkocht aan Klanten. Dit zijn Contacten waarvan informatie wordt bijgehouden, waaronder de naam en het adres. Ook wordt een Betaalmiddel voor klanten en leveranciers vastgelegd. Klanten zijn Personen, Leveranciers zijn instellingen. Betaalmiddelen zijn Creditcard of Bankrekening; er wordt niet contant afgerekend.
Fietsen zijn onderdeel van de Inventaris. Er zijn allerlei soorten fietsen waaronder Sportfietsen en Stadsfietsen. Sommige fietsen hebben een hulpmotor met Batterij (e-bikes). De batterij is een apart te verhandelen item in de Inventaris, met een eigen garantienummer.
Als een Fiets wordt verkocht wordt dat als een Verkoop geregistreerd. De Verkoop heeft een Verkoopdatum en een Garantienummer.
Fietsenwinkel als plaatje
Wanneer we een informatiemodel willen maken van onze Fietswinkel kunnen we het domein ook meteen al als plaatje uitwerken. Dat kan op veel manieren (in gedachten, bierviltje, papier, elektronisch) maar grofweg zal het plaatje er na enig denkwerk er zo uit zien. Zoals je ziet komen de woorden terug uit de beschrijving die we eerder gaven. Wat er eerder was, de tekst of het plaatje, is niet relevant.
Vrije impressie van het model voor Fietsenwinkels
Tekst of plaatje?
De tekst noch het plaatje volgt een standaard, formele methode voor het beschrijven van aspecten van het model. Het helpt ons wel om na te denken over de opbouw daarvan.
Hoe ver we ook gaan in het uitwerken van het voorgaande plaatje, of de tekst die daar bij hoort, we houden hoe dan ook de volgende beperkingen:
De “beeldtaal” is niet breed bekend en ondersteund, en daarmee bron van verwarring.
Het model is niet gegarandeerd compleet dus informatie kan gemakkelijk weggelaten worden. Er is geen goede manier om je analyse te valideren.
Er is geen software die iets verstandigs kan doen met deze weergave van het model.
Door MIM te gebruiken als modelleertaal worden deze beperkingen ondervangen. Door het gebruik van MIM zijn er strakke definities voor de betekenis van de bouwstenen van het model, zoals Informatiemodel (Fietswinkel), Domein (Inventaris), Objecttype (Stadsfiets), Relatiesoort (Leverancier – Fiets) en dergelijke. Daarmee zijn die concepten ondersteund door toegankelijke en sluitende beschrijvingen in de standaard zelf, kan het model worden gevalideerd (klopt het? is het compleet?) en kan software worden gemaakt voor het omzetten van het model in bruikbare ICT componenten. We spreken dan van Model Driven Design/Development/Architecture .
Naast vastgestelde definities van de concepten gebruikt MIM o.a. UML als modelleertaal in de vorm van UML-klassediagrammen. De standaard geeft een compleet beeld van alle UML constructies die conform het MIM metamodel kunnen worden gebruikt. Het MIM sluit andere modelleertalen niet uit. Ook stelt MIM vast op welke manier een MIM model moet worden uitgedrukt in RDF constructies. Dit laatste heeft niet de focus van deze Primer.
MIM introduceert daarmee de constructies die wel gestandaardiseerd kunnen worden opgenomen en gedeeld met anderen. Als we dit relateren aan het getekende plaatje:
Het informatiemodel is “het plaatje”.
Domeinen zijn in het plaatje apart gekleurd opgenomen: Winkel (geel), Inventaris (blauw), Contacten en Verkoop (wit).
De Objecttypen die een rol spelen zijn als rechthoek ingetekend (Sportfiets).
Allerlei relaties zoals met Adres, en type-relaties (generalisatie) zoals Fiets-Stadsfiets zijn als pijlen getekend. De relatie met Batterij (fysiek onderdeel van fiets) is als lijntje getekend.
Andere eigenschappen hebben nog geen plek gekregen.
Bij het omzetten van de tekst/het plaatje in een MIM informatiemodel is het verstandig om te werken vanuit Informatiemodel naar domein, naar modelelementen (fietsen, klanten, relaties daartussen) in het domein, naar eigenschappen van die modelelementen, en uiteindelijk de eigenschappen dáárvan. Een soort top-down benadering: we modelleren een informatiemodel, identificeren de domeinen, plaatsen er objecttypen in, geven het attributen, en geven die modelelementen metagegevens, bijvoorbeeld:
Deze hiërarchie keert terug in modelleringsinstrumenten zoals de UML omgeving Sparx Enterprise en in de Demonstrator, die speciaal voor MIM 1.1 is ontwikkeld.
In Enterprise Architect:
Het metagegeven “identificerend” zoals getoond in Enterprise Architect
In Demonstrator:
Het metagegeven “identificerend” zoals getoond in de Demonstrator.
We werken in deze Primer vanuit het informatiemodel naar de details.
Opbouwen van het informatiemodel
Het MIM introduceert nogal wat termen in relatie tot modelelementen en metagegevens daarvan. De modelelementen hebben veelal een relatie tot elkaar. Het informatiemodel bestaat uit één of meer domeinen, nul of meer views, en vaak wel enkele externe packages. Binnen deze “packages” krijgen de andere modelelementen van MIM een plek. Deze “hiërarchie” van modelelementen tonen we hieronder. De linkjes zijn referenties naar de uitwerking van die modelelementen in deze Primer, dus naar aparte hoofdstukken die daarover gaan.
Informatiemodel, heeft:
Domein packages, heeft:
Objecttypen, hebben:
Attribuutsoorten
Relatiesoorten
Gegevensgroepen
Externe koppelingen
Gegevensgroeptypen, hebben:
Attribuutsoorten
Gegevensgroepen
Datatypes, dat zijn:
Primitieve datatypes
Gestructureerde datatypes, hebben Data elementen
Enumeraties
Codelijsten
Referentielijsten, hebben Referentie elementen
Keuzen, dat zijn:
Keuze tussen attribuutsoorten, heeft Attribuutsoorten
Keuze tussen datatypes, heeft Datatypes
Keuze tussen objecttypen, heeft Objecttypen
Views, heeft wat domeinen kunnen hebben.
Externe packages
Informatiemodel
Een Informatiemodel is een Package. Een package is een benoemde en begrensde verzameling/groepering van modelelementen. Het informatiemodel Fietswinkels tracht dus een model te vormen voor de administratie van winkels waarin fietsen worden verkocht. We nemen hierbij aan dat er een begrippenkader bestaat waarin de woorden/termen die we hanteren zijn beschreven. Zo’n begrippenkader heeft bij voorkeur een elektronische vorm. We kunnen naar begrippen verwijzen, bijv. http://www.fietswinkels.nl/begrippenkader/Fiets of door gewoon “Fiets” op te voeren. De lijn tussen begrippen in dat begrippenkader, en die welke worden gebruikt in informatiemodellen is vaak dun. De definitie van een begrip in een begrippenkader is vaak (bijna) gelijk aan die van het objecttype in het informatiemodel. Hoe dichter beide vocabulaires bij elkaar blijven, hoe beter het is.
We stellen eerst ons informatiemodel vast. Behalve de naam van het informatiemodel (Fietsenwinkel) moeten we ook een aantal andere kenmerken opgeven. Deze worden hieronder beschreven. We tonen meteen een voorbeeldwaarde die voor ons voorbeeld informatiemodel Fietsenwinkel geldt.
Deze naam is uniek binnen de lijst van alle informatiemodellen. MIM stelt geen speciale eisen voor welke karakters hierin mogen voorkomen.
Voorbeeld:
“Fietsenwinkel”
Vrijwel alle modelelementen in het MIM hebben een naam. Uitgangspunt is steeds dat de naam in haar context uniek is. Die context verschilt per modelelement.
Dit is een beschrijving die voldoende onderscheidend is van andere definities om te begrijpen waar het over gaat. De definitie is een vrij tekstveld, en daarin kunnen dus speciale karakters en enige opmaak in opgenomen worden. MIM zegt er niets over, je mogelijkheden worden bepaald door de tooling die je hanteert.
Voorbeeld:
“Dit is een model voor registratie van inventaris en betrokken producenten en klanten van fietsenwinkels.
Dit model heeft alleen tot doel de aard en toepassing van constructies te illustreren, en is opgezet als een UML realisatie van de in MIM besproken modelelementen.
Het is bijna een filosofische vraag wat een modelelement “definieert”. Over het algemeen zal een definitie bondig zijn, en aangeven waarin het modelelement zich onderscheid van andere modelelementen. Het is dus niet zinvol een Mountainbike te definiëren als “Een soort fiets”, want dat kun je ook van en stadfiets zeggen. MIM zegt niet hoe je moet definiëren. Maar neem nooit informatie daarin op die al via andere metagegevens beschikbaar zijn (begrip, toelichting e.d.).
Een aanduiding van het “functionele domein” van het model. Deze aanduiding kan gebruikt worden om formele referenties naar modelelementen te onderscheiden van gelijknamige modelelementen in andere modellen. Veelal wordt hier een afkorting gekozen.
Als je het informatiemodel samenstelt heb je een doel: je wilt het vanuit conceptueel of technisch perspectief opzetten. Beschrijf het type van dit model , d.w.z. Is het conceptueel of logisch/technisch van aard? Feitelijk dekt MIM alleen deze twee typen modellen af.
Conceptuele modellen richten zich met name op de modelelementen die niet technisch van aard zijn. Deze modelelementen keren terug in documentatie, gesprekken, en (dus) ook in begrippenkaders. Het informatiemodel slaat op deze manier een brug tussen de praktijk (“de business”) en de technische systemen.
De techniek kan zich baseren op een eigen logisch model, waarin keuzes zijn gemaakt op basis van praktische beperkingen of mogelijkheden bij de ondersteuning door IT-systemen. Zo kunnen personen, in het conceptueel model nog uitgesplitst in ingeschreven en niet-ingeschreven personen, worden samengevoegd in een logisch model tot “persoon”, dat de basis vorm voor technische modellen en –realisatie.
Is in dit model de rol van een relatie leidend, of de relatie zelf? Als de rol leidend is worden rollen benoemd, en metagegevens aan de rol gekoppeld.
Dit is feitelijk een keuze voor een modelleringsstijl. Bij de keuze voor "Relatiesoort leidend" is de naam van de relatie leidend, bij de keuze voor "Relatierol leidend" zijn de namen van de bron en het doel van de relatie leidend. Bijvoorbeeld in de relatie tussen een organisatie en een persoon kan de relatiesoort "is werkgever van" zijn of de bron naam is "werkgever" en de source naam is "medewerker".
De MIM specificatie die gebruikt is om het informatiemodel in uit te drukken. Nu alleen 1.1, maar in de toekomst kunnen er meerdere versies ondersteund worden.
Organisaties kunnen beperkt aanvullende of afwijkende constructies toepassen in hun modellering. Of dat zo is kan hier worden aangegeven, zodat software en de lezer hier rekening mee kan houden.
Voorbeeld:
(We gebruiken geen extensie in het Fietsenwinkel voorbeeld)
Dit is de aanduiding van de taal die gebruikt is voor de modelelementen. Kies voor een waarde uit ISO 639-1 .
Voorbeeld:
“NL”
Zo geeft je informatie over je informatiemodel als geheel. Misschien verwacht je op dit niveau dat hier ook de versie, bewerker, en andere metadata van het model zelf kan worden aangegeven. Zoals je ziet, en ook in andere packages en modelelementen bemerkt, is geen versie-informatie of informatie over de status van de ontwikkeling van de modelelementen opgenomen in MIM. MIM modelleert dus echt één “snapshot” van het model, onafhankelijk van de status daarvan, of de plek in het werkproces. In extensies is het gebruikelijk daarvoor metagegevens toe te voegen.
Domein package
Het Informatiemodel bestaat vooral uit Domeinen. Dit zijn aandachtsgebieden die een zekere interne consistentie hebben: zaken die bij elkaar horen (feitelijk dus ook een Package). Dat is vaak een subjectieve groepering. Het kan betekenen dat ze als groep een versiegeschiedenis hebben, en/of dat ze bij elkaar gedocumenteerd worden. Zeker als het om complexe modellen gaat is het zinvol domeinen te benoemen.
Voorbeeld:
Het kadaster hanteert o.a. de volgende domeinen voor haar IMKAD model:
- Onroerende zaak (w.o. Perceel)
- Teboekgestelde zaak (w.o. Schip)
- Zakelijk recht (w.o. Ondersplitsing)
- Persoon (w.o. Niet-natuurlijk persoon)
- Stuk en stukdeel (w.o. Ter inschrijving aangeboden stuk)
Op basis van onze analyse van Fietsenwinkel bepalen we dat er twee domeinen een rol spelen:
De Inventaris, w.o. Stadsfiets
De Contacten, w.o. Klant
Sommige modelelementen worden in meerdere domeinen gebruikt. Het kan voor het overzicht handig zijn om deze gemeenschappelijke modelelementen samen in een apart domein onder te brengen. We hebben in ons voorbeeld het Gemeenschappelijke typen domein opgenomen, wat feitelijk geen domein is maar een verzamelbak.
Van ieder Domein package leggen we het volgende vast:
Naast domeinen kunnen Views zijn opgenomen. Het betreft dan een package (sterk gelijkend op een domein package) dat eigenlijk gebaseerd is op een ander informatiemodel, maar met eigen beperkingen en uitbreidingen. Deze Views geven inzicht in welke gegevens van het externe model relevant zijn binnen het eigen informatiemodel.
Het introduceren van een view heeft veelal tot gevolg dat je in overleg treedt met de eigenaar van dat externe model.
We gebruiken in het fietsenwinkel voorbeeld een domein dat gebaseerd is op een extern model voor persoonsregistratie. Dit is de View Persoon, en deze is gebaseerd op Persoonsmodel detailhandel, dat door de brancheorganisatie is opgesteld. Voor de Fietsenwinkel hanteren we daarvan een variant.
Voorbeeld:
Het kadaster hanteert o.a. de volgende view voor haar IMKAD model:
Andere eerder besproken metagegevens van View zijn: Definitie en Herkomst.
Extern package
Als laatste kunnen Externe packages in het informatiemodel voorkomen. Deze packages bevatten verwijzingen naar modellen in de buitenwereld, zonder dat er een bepaalde interpretatie (zoals bij views) aan wordt gegeven. Een goed voorbeeld is een ISO 10107, het “Spatial schema”, dat ten grondslag ligt aan GML, waar we naar willen kunnen verwijzen (“Point zoals bedoeld in GML 3.2”).
In het fietsenwinkel voorbeeld zijn twee externe packages opgenomen voor MIM11 zelf, en voor GML Geometrie. MIM11 Primitieve typen zijn de typen zoals opgenomen in de standaard . Attribuutsoorten kunnen verwijzen naar deze typen, en we kunnen nieuwe typen introduceren die subtype zijn van deze typen. Bijvoorbeeld een Garantienummer is subtype van MIM CharacterString. GML (Geography Markup Language, d.i. ISO 19136) introduceert typen voor geometrische constructies, zoals oppervlak en lijn. Zo is de geolocatie van een Adres een GML Point. De manier waarop deze constructies moeten worden geïnterpreteerd ligt vast in de genoemde documenten.
Van het Extern package leggen we het volgende vast:
Andere eerder besproken metagegevens van Extern package zijn: Definitie, Herkomst.
Modelleren van concepten en hun relaties
Domeinen bevatten de modelelementen van het informatiemodel. De modellering draait met name om Objectypen met attribuutsoorten en relatiesoorten. We behandelen deze hieronder.
Objecttype
Een “object” is een ding, een tastbaar iets, in de werkelijkheid, zoals daarnaar gekeken wordt vanuit een bepaald toepassingsgebied. Voorbeeld is een specifieke Cube fiets, die onlangs aan mevrouw Jansen is verkocht. Ook mevrouw Jansen is een “object” in de wereld van de fietsenwinkel (het “domein”).
Een Objecttype is een typering van een groep objecten die binnen een domein relevant zijn en als gelijksoortig worden beschouwd. Mevrouw Jansen is van het objecttype Klant. De Cube fiets is van het objecttype Sportfiets.
Objecten hebben kenmerken. Zo is een persoon dat waar we het over hebben als onderwerp van gesprek en over personen houden we informatie bij zoals een naam en een geboortedatum. Een stukje informatie is altijd een kenmerk, en een kenmerk is altijd een kenmerk van een object.
Een objecttype is voor een domein relevant als kenmerken daarvan van belang zijn voor het functioneren van werkprocessen van dat domein. Bijvoorbeeld: als je het adres van een klant niet vastlegt kun je geen factuur opsturen.
Objecttypen kunnen abstract zijn, zoals Fiets. In dat geval zijn er concrete subtypen die als zodanig worden opgenomen in een administratie: de Sportfiets.
Een object heeft altijd een unieke aanduiding, die het onderscheid van alle andere objecten. Voorbeeld: het Burgerservicenummer van een Persoon. De attribuutsoort(en) die de unieke aanduiding realiseren zijn met het metagegeven identificerend herkenbaar bij een Objecttype opgenomen. Het is dus geen metagegeven van het object zelf.
Wanneer we een Domein of View hebben geïntroduceerd kunnen we daarin deze Objecttypen opnemen.
Wanneer de naam in het informatiemodel een technische vorm heeft, kan de alias worden gebruikt om de natuurlijke naam vast te leggen. Dus als in het informatiemodel gekozen is voor zgn. CamelCase namen (“GeografischeLocatie”) kan in de alias de bedoelde natuurlijke naam worden opgenomen (“Geografische locatie”) als dit de technische naam verduidelijkt.
Voorbeeld:
In het voorbeeld model is geen gebruik gemaakt van technische namen.
Achter het modelelement in het informatiemodel kunnen meerdere begrippen zitten die zijn vastgesteld in het begrippenkader, d.w.z. een ontologie, thesaurus of andere taxonomie, of een geheel andere min of meer formele lijst van begrippen. Wanneer je kiest voor een URI, of voor een term, moet deze herleid kunnen worden tot een eenduidige specificatie. Beste is een URL, maar soms kan dat niet. Er kunnen meerdere begrippen van toepassing zijn.
De URI komt uit bij een begrippenkader die gepubliceerd is in een begrippencatalogus of iets dergelijk. Het is niet noodzakelijk om een begrippenkader te publiceren, dus het aangeven van begrippen is optioneel. Maar als je een begrippenkader gepubliceerd hebt, vul dan bij voorkeur waar mogelijk de link tussen een informatiemodel element en een begrip in.
De definitie is onttrokken aan een informatiemodel dat al dan niet het huidige model is. In alle gevallen geef je aan waar de definitie voor het eerst is opgenomen. De definitie mag wel zijn veranderd of opgesplitst. De bron blijft relevant.
De waarde die je hier opgeeft is niet formeel, en je moet een eigen keuze maken.
Voorbeeld:
“FW” (Fietswinkel informatiemodel, dus dit is de bron)
De datum waarop dit objecttype is opgenomen in het informatiemodel. Er is geen formaat afgesproken voor deze datum, dus bijv. een ISO datum, een jaartal, of een korte omschrijving van een moment is acceptabel.
De beschrijving van de exemplaren van het gedefinieerde objecttype in de registratie die centraal staat in dit model. Het betreft dan met name objecttypen die deel uitmaken van een (basis)registratie. In andere modellen zal dit veelal niet worden ingevuld.
Voorbeeld:
“Winkels die bij de landelijke keten Fietsenhandel zijn aangesloten” (voor Winkel)
Of:
“De fietsen die verkrijgbaar zijn via de landelijke keten fietsenhandel” (voor Fiets).
Hoe volledig, juist, actueel, nauwkeurig en betrouwbaar worden de objecten geregistreerd in de registratie die centraal staat in dit model?
Voorbeeld:
“99% van alle data voor dit kenmerk is actueel juist. De informatie wordt maandelijks gecontroleerd en verwerkt voor de 1e van de maand.” (voor Winkel)
Het kan zijn dat het object type niet echt zo zal worden geregistreerd en gebruikt, maar dat het een meer ‘abstracte’ typering betreft. Subtypen daarvan zullen dat werkelijke objecten in de registratie beschrijven. Je geeft dat hier aan; in de UML wereld is een klasse abstract of niet; die eigenschap is deze “indicatie”.
Voorbeeld:
Voorbeeld is “Fiets” (abstract ) en subtype “Stadsfiets” (concreet).
Andere eerder besproken metagegevens van objecttype zijn: Definitie en Herkomst.
Een Objectype kan meerdere Supertype(n) hebben. De relatie met die supertypen is een vorm van generalisatie. In principe geldt dan dat het subtype altijd de plek kan innemen van het supertype (substitution ). Bovendien heeft het minimaal dezelfde verzameling kenmerken als het supertype. Bijvoorbeeld: als een Fiets verkoopbaar is, is ook een Stadsfiets verkoopbaar. En als een Fiets een batterij kan hebben, kan ook de Stadsfiets een batterij hebben.
Er is wel discussie geweest of een objecttype, of een ander modelelement meerdere supertypen mag hebben. Daar is weinig tegen, al kan het wel verwarrend werken, zeker als beide typen overlappen of elkaar op aspecten tegenspreken. Zulke problemen worden in tekst en/of in techniek (logische / technische modellen) opgelost.
Voorbeeld:
Stadsfiets is subtype van Fiets (supertype)
Objecttypen hebben veelal attributen, zgn. Attribuutsoorten. Het kan zijn dat er een keuze tussen zulke attributen is bedoeld. Men neemt in een object het ene of het andere attribuut op. Bijvoorbeeld: een Fiets heeft als attribuut ketting (met een type ketting als waarde) of als attribuut snaaraandrijving (met een type snaar als waarde).
Het feit dat beide typen fiets een andere aandrijving hebben heeft dan dus niet tot gevolg dat we over andere typen fietsen (andere Objecttypen) willen spreken in ons model. Introductie van nieuwe Objecttypen voor zulke situaties kan tot nogal onoverzichtelijke modellen leiden. Door het gebruik van een keuze tussen de attribuutsoorten wordt een verdere specialisatie van fiets in aparte objecttypen ("Kettingfiets" en "Snaarfiets") vermeden.
Voorbeeld:
Aandrijving van Fiets (Fiets.aandrijving)
Attribuutsoort
Een Attribuutsoort is een eigenschap van een Objecttype, welke per object wordt vastgelegd. Naam, omvang, prijs, straat zijn voorbeelden van Attribuutsoorten. Sommige Attribuutsoorten hebben een identificerend karakter, sommige Attribuutsoorten zijn optioneel of kunnen meermaals voorkomen. Dit is de kardinaliteit van het attribuutsoort.
Van een Attribuutsoort leggen we het volgende vast:
Een attribuutsoort beschrijft data, en die data heeft een datatype: “wat voor data kan hier worden opgegeven?”. Het datatype is een tekenreeks of een combinatie van tekenreeksen. Voorbeelden zijn “Amsterdam” (een waarde van Primitief datatype CharacterString), 9.5 (van Primitief datatype Decimal) of 10 meter (van Gestructureerd datatype Lengte).
Als een waarde aan een lijst wordt ontleend kan het ook een waarde zijn uit een Enumeratie, een Codelijst of een Referentielijst. Welke keuze ook wordt gemaakt, de waarde is een echt een “waarde”, niet een modelelement waar je naar kunt verwijzen.
Voorbeeld:
Datatype van verkoopdatum is een “Date” (Primitief datatype uit MIM).
Datatype van garantienummer is een “Garantienummer”, dat een subtype is van MIM CharacterString.
De lengte van de waarde van een attribuutsoort kan worden uitgedrukt in een geheel getal (exacte lengte) of een reeks zoals 1…8 (één tot 8 posities). Wat er exact in deze waarde wordt ingevuld blijft nog open. Dat kan door middel van een Patroon en/of Formeel patroon nader worden bepaald. De lengte heeft betrekking op tekenreeken en hele getallen; wanneer gebroken getallen bedoeld zijn wordt het aantal posities voor en achter de komma aangegeven als “3,2” (een eventueel plus- of minteken wordt niet meegerekend).
Voorbeeld:
“16” (de exacte lengte van kaartnummer van Creditcard)
Een patroon is een beschrijving van de mogelijke karakters in een tekenreeks. Hier gebruiken we natuurlijke taal. Wanneer een Formeel patroon wordt opgegeven moet dat formele patroon in lijn zijn met het opgegeven Patroon.
Voorbeeld:
Bijvoorbeeld: “vier cijfers, en dan twee letters in kapitaal, opgenomen in de post-nl postcodelijst ” (voor Adres.postcode).
Het formele patroon is een beschrijving van het patroon als een reguliere expressie, en volgt de Perl conventies . Een formeel patroon kan worden gespecificeerd voor alle datatypes die een tekenreeks representeren. Sommige aspecten kun je niet goed kwijt in een reguliere expressie, zoals minimum en maximum waarde. Daarvoor val je terug op patroon.
Voorbeeld:
“[A-Z]{4}[0-9]{2}” is een reguliere expressie die een postcode beschrijft (Adres.postcode).
Bekend moet zijn wat de waarde van een attribuut op een bepaald moment is. Wanneer is iets gebeurd, in de werkelijkheid of volgens opgave? Dit noemen we materiële historie. Wordt de tijdslijn geldigheid bijgehouden, die aangeeft vanaf wanneer de gegevens geldig zijn?
Materiële historie is een van de historie aspecten van het informatiemodel. Historie wordt in MIM 1.1 uitgewerkt in een apart hoofdstuk .
Voorbeeld:
“Nee” (Contact.adres, Indicatie materiële historie) De verhuizing van de klant wanneer deze in werkelijkheid plaatsvindt wordt niet geregistreerd. Een Fietsenwinkelier weet dat doorgaans niet.
Net als materiële historie registreert formele historie veranderingen door de tijd heen. Ook hier wordt bepaald of deze verandering wordt geregistreerd. Vanaf wanneer waren de gegevens bekend bij de instelling? Wordt dus de tijdslijn registratie bijgehouden, die aangeeft wanneer de gegevens geregistreerd zijn (en ook wanneer de eindgeldigheid van een gegeven geregistreerd is)? Dit is de formele historie. Dit wordt elders beschreven.
Voorbeeld:
“Ja” (Contact.adres, Indicatie formele historie) De verhuizing van de klant wanneer deze wordt doorgegeven wordt wel geregistreerd. De adressen van de klant door de jaren heen worden dus wel bijgehouden.
We moeten aangeven of bepaalde kenmerken optioneel of verplicht zijn, en misschien zelf meermaals kunnen worden gespecificeerd. Dit geven we aan als 0..1 (optioneel), 1..5 (1 tot 5 keer), 2..* (2 of meer keer) en zo voorts. De standaard kardinaliteit is 1. Kardinaliteit geven we op bij attribuutsoorten en relatiesoorten.
Voorbeeld:
“Adres.locatie = 0.1 Geografische locatie” - De locatie van een Adres kan een optionele geografische locatie bevatten. Het niet opnemen van een locatie is dus modelmatig niet nodig. Vergelijk dit met metagegeven Mogelijk geen waarde, zie elders.
In overheidsland worden allerlei gegevens opgenomen en uitgewisseld. Van een deel hiervan is vastgesteld dat de instelling die de gegevens registreert de “authentieke bron” is dan die gegevens. Kadaster registreert Percelen, BRP registreert personen, et cetera. De essentie is dat een instelling “de waarheid in pacht heeft” en dat deze instelling er dus op aangesproken kan worden. Andere instellingen nemen deze info mogelijk over in hun registratie en/of uitwisselingen. Deze overgenomen info is dan niet authentiek .
Mogelijke waarden voor dit metagegeven zijn aan de Stelselcatalogus ontleend: Authentiek (authentiek voor de instelling die het model opstelt), Basisgegeven (komt uit een basisregistratie), Wettelijk gegeven (komt uit een andere wettelijke registratie), Landelijk kerngegeven (komt uit een sector- en domein-overstijgend informatiemodel), of Overig (geen van voorgaande).
Door juridische eisen kan een bepaald kwaliteitsniveau verwacht worden over de juistheid en actualiteit van de data. Overig is een aanduiding dat het hier kwalitatief hoogwaardige gegevens betreft. Er is dan echter geen sprake van juridische eisen vanuit de overheid.
Voorbeeld:
“Overig” (Contact.naam Authentiek = “Overig”) - In het model voor de fietsenwinkels modelleren we binnen het detailhandel domein.
Soms neem je in het model “voor het gemak” modelelementen op die feitelijk afleidbaar zijn uit modelelementen die je op een andere plek al hebt opgenomen. Daarvoor moeten deze modelelementen op een specifieke manier worden begrepen, bij elkaar geplaatst en mogelijk omgezet. De waarde van een afleidbaar attribuutsoort zal daardoor ook veranderen als deze andere modelelementen veranderen van waarde in de registratie.
Het afleidingsalgoritme kan worden opgenomen in de toelichting. Dit kan onder AI en algoritmes vallen waardoor het nodig is om hiervoor een opname te doen in een “algoritmeregister”.
Voorbeeld:
“Ja” (Fiets.id afleidbaar = “Ja”) – De ID is afgeleid van Naam en typenummer.
De normale manier om classificatie aan te geven in informatiemodellen is via generalisatie: “een stadsfiets is een soort fiets”. Veelal is deze generalisatie bedoeld om eigenschappen en relaties uit te breiden: een racefiets heeft extra kenmerken die relevant zijn voor het informatiemodel.
Dit kan voor bepaalde toepassingen vrij overdreven uitpakken; er is eigenlijk niks extra te melden over de subtypen. Een methode is dan om een lijstje van namen van subtypen op te stellen en het “super-Objecttype” een attribuut te geven dat verwijst naar dat lijstje. In dat geval is dat attribuut classificerend bedoeld.
Voorbeeld:
Sportfiets.type is classificerend. “Cube” staat in een lijst Sportfiets typen en dat classificeert de sportfiets.
Van sommige modelelementen wordt vooraf al bepaald dat deze mogelijk geen waarde krijgen in registratie of uitwisseling. Reden kan zijn dat de informatie nog niet beschikbaar is, dat deze niet bekend mag worden gemaakt of wegens iets anders niet wordt opgenomen. Als dat op modelniveau al bekend is, wordt dat gesignaleerd door dit metagegeven op “Ja” te zetten.
Voorbeeld:
“Ja” (Adres.huisnummer) - Van een Contact kan het huisnummer wegelaten worden als deze informatie niet wordt gegeven door de klant, of in uitwisseling met derden. De informatie hoort er wel te zijn maar is niet beschikbaar.
Om te kunnen verwijzen naar een objecttype heb je iets nodig dat voldoende onderscheidend en stabiel is: een identificerende eigenschap. Soms betreft het zelfs een combinatie van eigenschappen, en in extreme gevallen kan zelfs een relatiesoort (mede-) identificerend zijn. Als een attribuutsoort of relatiesoort een rol speelt in de identificatie krijgt het dit metagegeven.
Wanneer het datatype van een Attribuutsoort ofwel het ene, of wel het andere datatype is, kan een keuze tussen die datatypes worden geïntroduceerd. Zo kan de geo-locatie van een winkel aangeduid worden als een punt op de kaart, of een vlak, of zelfs een polygoon. Hiervoor kunnen we een keuze introduceren. De keuze is een een UML datatype omdat het effectief altijd een waarde betreft van het attribuut.
Voorbeeld:
“Geografische locatie” staat keuze tussen GM_Point of GM_Polygon toe.
Gegevensgroeptype
Wanneer we een aantal samenhangende Attribuutsoorten als groepje willen gebruiken (bijvoorbeeld het groepje is als geheel optioneel) kunnen we het als Gegevensgroeptype opnemen. Het betreft dan niet een Objecttype: het is geen constructie waar we over praten als zelfstandig concept (het is dus ook typisch niet identificeerbaar), en we kunnen er ook geen relaties (Relatiesoort) naar toe leggen. Het betreft dus écht alleen maar een groepje attributen.
Voorbeeld is het Gegevensgroeptype Adres. Een adres is vanuit het perspectief van de fietsenwinkel geen “concept” waarover wordt gecommuniceerd; het is wel een groepje attributen: postcode, huisnummer, locatie. Als het adres verandert veranderen deze gegevens als groepje.
Het is mogelijk dat meerdere objecttypen een Gegevensgroeptype delen. Het is dus niet voorbehouden aan één Objecttype.
Van een Gegevensgroeptype leggen we het volgende vast:
Zie Naam. Deze naam is uniek binnen het Objecttype of Gegevensgroeptype waar het deel van uitmaakt. De naam van de gegevensgroep geeft aan welke “rol” de attributen hebben die als groep worden aangekoppeld.
Voorbeeld:
“postadres” (een Contact.postadres is een Gegevensgroep, en is van type Gegevensgroeptype)
Een relatie tussen twee objecttypen wordt een relatiesoort genoemd. Die relatie kan direct bestaan (een fiets wordt verkocht aan een klant) of via een keuze worden gerealiseerd (een contact kan betalen met Creditcard of Bankrekening). Het is niet mogelijk een relatie te leggen met een datatype, en het is ook niet mogelijk een objecttype te relateren met een ander objecttype middels een attribuutsoort. In deze zin vullen beide modelelementen elkaar aan.
Relaties kunnen exclusief zijn, maar ook gedeeld. In de UML wereld zijn dit compositie, aggregatie of gewone relaties. MIM legt hierin geen beperkingen op.
Voorbeeld:
In het Fietswinkel voorbeeld is een gewone relatie getrokken (een Relatiesoort) van Fiets naar Klant, en een compositie relatie (ook een Relatiesoort) van Fiets naar Batterij.
Een relatie tussen twee objecttypen kan alleen “zichtbaar” zijn vanuit één van beide. Een Fiets wordt verkocht aan een Klant, en van een Klant is bekend welke Fietsen zijn aangeschaft. De relatie is niet unidirectioneel. Een Klant kan ook een betaling doen met een Creditcard. Deze relatie gaat wel één richting op: Klant heeft een relatie met Creditcard. Dat in de werkelijkheid ook een andersom relatie bestaat is niet relevant voor het informatiemodel waar we naar kijken. Het is misschien mogelijk (in een technisch systeem) een bevraging te doen “welke personen horen bij deze creditcard” maar dat speelt voor het model geen rol. Om dat expliciet te maken wordt deze relatie gericht. MIM schrijft dus niet voor dat relaties gericht moeten zijn. Dat is per relatie vast te stellen.
De relatie heeft een bron en een doel. De relatie is gericht. Hij start bij de bron (een Objecttype of Koppelklasse) en wijst naar het doel (ook, altijd, een Objecttype of Koppelklasse). Beide kunnen een rol hebben, en afhankelijk van de wijze waarop relaties worden vastgelegd worden eigenschappen van de relatie aan de relatie zelf, of aan de rol van het doelobject gekoppeld.
Voorbeeld:
In Fiets “verkocht aan” Klant heeft de klant de rol van ontvanger.
Dit is de aanduiding of het doel een onderdeel is van de eigenaar. Aggregatietype is Geen, Gedeeld of Compositie, en dit principe volgt UML aggregatie. Standaard betreft de relatie tussen twee objecten niet deel/geheel: Een specifieke Eigenaar heeft een bepaalde Hond, beiden blijven bestaan als een van beiden wegvalt (we praten dus op data-niveau). De Hond heeft zijn Staart: dit is een compositie relatie. Als de hond wegvalt, valt de staart ook weg. Een deel kan niet exclusief voor het geheel zijn (gedeeld): meerdere Personen hebben dezelfde Betaalrekening maar als een Persoon wegvalt, vervalt niet per definitie ook de Betaalrekening.
Voorbeeld:
Fiets wordt aangedreven door Batterij (als een Fiets type vervalt, vervalt ook de Batterij.)
Zie Kardinaliteit. De kardinaliteit van een relatie wordt geplaatst op het doel van de relatiesoort. MIM stelt (nog) niet dat ook de bron een kardinaliteit kan hebben.
Wanneer een Objecttype is opgenomen in het model dat een interpretatie is van een objecttype in een extern model, dan wordt die relatie expliciet gelegd met een externe koppeling-relatie.
Een externe koppeling mag gelegd worden naar een objecttype in een View package of naar een objecttype in een Extern package.
Objecttypen, Gegevensgroeptypen en Gestructureerde datatypes hebben eigenschappen met waarden. Voor de eerste twee krijgt dat de vorm van attribuutsoorten; voor de laatste betreft het data elementen. Deze eigenschappen hebben een datatype: het typenummer van een fiets is een tekenreeks (CharacterString), de verkoopdatum is een datum (Date).
Het type van de data die kan worden toegekend kies je uit een reeks vooraf gedefinieerde typen, een waarde uit een lijst, of een eigen datatype:
Lijsten zijn Enumeratie, Codelijst, Referentielijst. Dat betekent: de waarde is een waarde onttrokken aan de opgegeven lijst.
Eigen datatypes zijn subtypen (cf. Generalisatie) van de primitieve of lijst-typen die je zelf binnen een model hebt gedefinieerd.
Je kunt ook bestaande datatypen nader specificeren, d.w.z. een beperktere verzameling van mogelijke waarden benoemen. Een goed voorbeeld is een datatype AN (“alfanumeriek”) waar bij (via een formeel patroon) is vastgelegd dat de karakters moeten voldoen aan de MES-1 specificatie .
Primitief datatype
Een primitief datatype is een datatype zonder verdere specificatie over haar structuur. Zo’n type representeert een waarde, zoals een integer getal of een datum. Je kunt zelf primitieve typen maken, en een aantal primitieve typen is voor gedefinieerd door de MIM standaard.
Van een Primitief datatype leggen we het volgende vast:
Een voorbeeld van een eigen gedefinieerd primitief type is het Garantienummer: een CharacterString. We willen garantienummers als zelfstandige concepten in het model kunnen gebruiken; dat is op zich voldoende basis voor het introduceren van zo’n type. Een ander voorbeeld is IBAN, waarvoor een zeer specifiek patroon is vastgesteld. Er is dan een meer technische reden om dit type te introduceren.
De MIM standaard definieert een aantal standaard typen, altijd beschikbaar voor ieder model. De MIM standaard behandelt deze datatypes in een aparte sectie . Enkele belangrijke typen zijn:
Datatype
Uitleg
CharacterString
Een tekenreeks. Een lege CharacterString is mogelijk.
Voorbeeld:
“Cube Attain SL” - De naam van een fiets (Fiets.naam)
Integer
Een geheel getal.
Voorbeeld:
“22” (Fiets.versnellingen) – Het aantal versnellingen.
Decimal
Een gebroken getal. Dit is een exact getal, zoals de prijs van een fiets in Euro’s.
Voorbeeld:
Verkoopprijs is “899,00” (Fiets.verkoopprijs)
Real
Een gebroken getal, dat niet exact vast te stellen is. Coördinaten op een kaart zouden als Real kunnen worden getypeerd, omdat die soms berekend worden op basis van andere coördinaten.
Boolean
Waar of niet waar. Dit zijn waarden True of 1, of False of 0. Er is besloten geen Ja of Nee te accepteren als booleaanse waarde.
Voorbeeld:
Nieuwsbrief = “True” (Klant.nieuwsbrief)
Date
Een datum. De datum heeft een vaste opbouw: yyyy-mm-dd.
Voorbeeld:
Verkoopdatum = “2020-11-07” (Verkoop.verkoopdatum) is 7 november 2020.
Andere typen zijn DateTime, Year, Day, Month, URI, deze behandelen we hier niet.
Gestructureerd datatype
Een Gestructureerd type heeft meerdere benoemde data elementen die samen een waarde vormen. Zo is “1 liter” opgebouwd uit “aantal” en “eenheid”. Hoe dan ook identificeert “1 liter” een waarde.
Een voorbeeld van een gestructureerd type in ons informatiemodel is de omvang van een Fiets (Fiets.omvang) als type Dimensies: lengte is 1900, breedte is 350, hoogte is 1200 (de dimensies van een fiets, in mm). Ook een Batterij kent een omvang.
MIM introduceert zelf geen gestructureerde datatypes. Deze moet je overnemen van andere modellen, of zelf maken, zoals we dat met Dimensies hebben gedaan.
Van een Gestructureerd datatype leggen we het volgende vast:
Een attribuut van een object heeft altijd een waarde. Deze kan zijn onttrokken aan een lijst van mogelijke waarden. Deze lijst kan zijn opgegeven binnen het informatiemodel, of daarbuiten ergens beschikbaar zijn, bijvoorbeeld op het web. Deze lijst kan, wanneer ze toegankelijk is voor een verwerkend systeem, worden uitgelezen, en er kan een check worden gedaan of de waarde acceptabel is. De waarde fungeert dan als “sleutelwaarde”. Aan deze sleutel kunnen andere waarden zijn gekoppeld.
Er worden drie soorten lijsten onderscheiden door het MIM, en deze worden hieronder besproken.
Sleutelwaarde is opgenomen in model
Aan sleutelwaarde hangen andere waarden
Model stelt vast welke waarden relevant zijn
Enumeratie
Ja
Nee
n.v.t.
Referentielijst
Ja
Ja
Ja
Codelijst
Ja
Mogelijk
Nee
Enumeratie
Een enumeratie is een vaste lijst van waarden die onderdeel is van het informatiemodel: als je de lijst aanpast ontstaat een nieuwe versie van het model. Je introduceert een enumeratie dus met name als de lijst niet uitbreidbaar is, en de waarden bepalend zijn voor het verwerken van de informatie.
Voorbeeld is de lijst Sportfiets typen. Er is slechts een beperkt aantal typen fietsen, en als in dat lijstje aanpassingen worden doorgevoerd kan dat effect hebben op de rest van het model. Bijvoorbeeld doordat daardoor nieuwe attributen op Batterij een rol zouden kunnen gaan spelen.
Al eerder besproken metagegevens van enumeratie zijn: Begrip, Definitie.
Enumeratiewaarde
De enumeratiewaarde is de “karakterreeks” die de betreffende waarde representeert. Voorbeeld is “man” (Geslacht), “Rood” (Kleur), of “Giant” (Fiets type).
Zie Naam. Deze naam is uniek voor de Enumeratie waar het in zit. De naam valt samen met het modelelement (er is maar één “Rood” in de lijst van kleuren).
Voorbeeld:
De waarde van Sportfiets.type komt uit de lijst Sportfiets typen
Een unieke code die je aan deze waarde koppelt, en die een rol speelt in de technische verwerking. De MIM standaard zegt niet wat voor code dat moet zijn, of hoe deze zich verhoudt tot de enumeratiewaarde.
Al eerder besproken metagegevens van enumeratie zijn: Definitie.
Referentielijst
Een waarde kan ook worden onttrokken aan een referentielijst. In dat geval heeft een verandering in die lijst geen invloed op de wijze waarop het model moet worden begrepen. De introductie van nieuwe kleuren in een kleurenstaal heeft geen effect op de wijze waarop je de kleurenstaal kunt gebruiken. In ons voorbeeld is een KvK lijst opgenomen: veranderingen in die lijst van bedrijven (toegankelijk via KvK nummer) hebben geen impact op het model.
Een referentielijst heeft Referentie elementen, die je je kunt voorstellen als kolommen in een tabel (de lijst). De kop van de kolom is het data element, de rijen beschrijven één waarde. Iedere cel is één aspect van die waarde, bijv. code, naam in het Nederlands, naam in het Engels, omschrijving.
Referentielijsten worden altijd buiten het model beheerd. Veelal is er een web-toegang tot die lijst (uitlezen via http connectie), maar ook andere technische of niet-technische representaties kunnen voorkomen.
Voorbeeld:
De locatie van de Referentielijst KvK Lijst is een webadres: https://services.kvk.nl/zoeken/handelsregister/ (fictief) d.w.z. door deze URL te volgen met de juiste parameters en rechten is bedrijfsinformatie op te vragen.
Er is altijd een kolom in de referentielijst die de sleutelwaarden bevat waaronder de gegevens op te halen zijn. Dat referentie-element kan men expliciet aanduiden d.m.v. het metagegeven “Identificerend”. Zo is in de referentielijst KvK lijst het element KvK lijst.nummer identificerend.
Een codelijst is een soort Referentielijst, maar de opbouw daarvan wordt niet nader gespecificeerd. In feite wordt van een codelijst alleen gesteld dat de waarden ergens buiten het model vastliggen, maar niet op welke manier (met “welke kolommen”, zoals bij referentielijst). De codelijst heeft, anders dan bij enumeraties, dus ook geen waarden die in het model zélf zijn opgenomen.
In de specificatie van het MIM zijn er allerlei “keuzen” opgenomen. In ons fietsenwinkel voorbeeld kan worden gekozen tussen een Klant of een Leverancier wanneer een Contact wordt bedoeld. Dit is inherent aan subtypering in MIM: een situatie waarin een supertype een rol speelt heeft ook betrekking op haar subtypen.
Een ander soort keuze is het opnemen van een betaling via een creditcard of een bankrekening. We kunnen dit modelleren door beide op te nemen als optioneel attribuutsoort van een objecttype (“betaling”). Feitelijk wordt hier dan een keuze bedoeld. We moeten dan een “constraint” opnemen dat een van deze gevuld moet zijn. In technische uitwerkingen (denk aan UML OCL Constraints ) is dat lastig te implementeren.
Het modelelement Keuze lost dit op door expliciet te maken dat er geen sprake is van optionele modelelementen, maar dat er een keuze moet worden gemaakt. We introduceren daarom meerdere soorten keuzen: keuzen tussen attribuutwaarden (lees: datatypes), keuzen tussen attributen, en tussen relaties. Dit houdt andere methoden om keuzen vast te stellen niet tegen.
Een keuze tussen datatypes houdt in dat de waarde van een attribuutsoort (of data element) ofwel van het ene datatype is, of van het andere (of van een derde…). Een typisch voorbeeld is: de geografische locatie van een adres is een punt op de kaart (de voordeur, of een middelpunt), of de omtrek van het pand. Welke het wordt is afhankelijk van welke gegevens beschikbaar zijn.
Voorbeeld:
Geografische locatie is een keuze tussen punt en vlak. Voor Adres.locatie kan deze keuze worden gemaakt.
N.B. Uitgangpunt is wel dat het type van het attribuut wel kan worden bepaald: is een ingevoerde waarde “20” een getal of een alfanumerieke waarde? Dat valt buiten de MIM standaard maar is in uitwisseling wel essentieel.
Keuze tussen attribuutsoorten
Het kan ook zijn dat de keuze niet het datatype van een attribuutsoort betreft, maar juist wélk attribuutsoort van toepassing is. Zoals eerder gesteld kun je twee attribuutsoorten optioneel maken en erbij documenteren dat men één van beide moet kiezen. Het is dan toch duidelijker om die keuze in het model expliciet te maken door middel van een modelelement Keuze.
De namen van de attribuutsoorten moeten uniek zijn binnen alle Objecttypen waarin de keuze wordt opgenomen.
Voorbeeld:
Fiets.aandrijving is een keuze tussen een ketting- of snaaraandrijving. Dit is vervat in de keuzeklasse Aandrijving. Elk van de attribuutsoorten heeft een eigen lijst van mogelijke waarden.
Keuze tussen objecttypen
Ook als een relatie wordt gemodelleerd waarin een keuze uit meerdere Objecttypen als relatie-doel wordt bedoeld, wordt een Keuze modelelement opgenomen. Dit modelelement heeft keuze-relaties met alle mogelijke objecttypen. Deze relaties hebben geen kardinaliteit maar wel een naam en andere metagegevens.
Voorbeeld:
Een voorbeeld is de Contact.betaling: dit is de keuze klasse Betaalmiddel.
Betaalmiddel.credit verwijst naar Creditcard, Betaalmiddel.bank verwijst naar Bankrekening.
Metagegevens
Metagegevens zijn gegevens over gegevens. Dit is een breed begrip waar binnen verschillende toepassingen een andere invulling aan wordt gegeven. Metagegevens van deze Primer zijn bijvoorbeeld de namen van auteurs of de URL waarop deze te lezen is. Een informatiemodel is niks anders dan een verzameling blokjes en lijntjes, wanneer we de betekenis (semantiek) van modelelementen niet vastleggen. Om deze reden schrijft MIM het gebruik van metagegevens zoals naam en definitie voor. Voor het invullen van deze gegevens zijn afspraken en regels nodig. Wanneer informatiemodelleurs allemaal op een eenduidige manier metagegevens vastleggen, levert dit meerdere voordelen op. Het vergelijken van informatiemodellen wordt bijvoorbeeld makkelijker, modellen worden beter te doorzoeken en er wordt een bepaalde kwaliteit van modelbeschrijvingen vastgesteld. De metagegevens die MIM onderkend worden in dit hoofdstuk verder toegelicht.
Naam, alias en begrip
De metagegevens naam , alias en begrip komen vaak terug in deze Primer. Het zijn drie metagegevens die elkaar aanvullen. In de MIM standaard is een aantal afspraken en regels opgesteld over de invulling van deze metagegevens.
Een naam geeft een korte omschrijving van het modelelement. De invulling van een naam moet volgens MIM voldoen aan een aantal naamgevingsconventies . Zo moeten bijvoorbeeld Objecttypen een unieke naam hebben binnen het informatiemodel. Ook kan er een keuze worden gemaakt tussen natuurlijke taal of machine leesbare taal. Het is gebruikelijk dat natuurlijke taal wordt gebruikt binnen een Conceptueel informatiemodel en machine leesbare taal binnen een Logisch informatiemodel . Binnen het conceptueel informatiemodel Fietsenwinkel wordt bijvoorbeeld natuurlijke taal gebruikt.
Voorbeeld:
Het gebruik van natuurlijke taal kun je bijvoorbeeld terug zien in informatiemodel Fietsenwinkel bij de Relatiesoort “verkocht aan”. In machine leesbare taal zou deze naam iets als “verkochtAan” worden. Hier betreft dat een naam die typisch terugkomt in afgeleide technische producten, zoals bijvoorbeeld XSD schema’s.
Een alias is een alternatieve benaming voor een modelelement. In de praktijk wordt dit metagegeven op verschillende manieren gebruikt. De bedoeling van MIM is dat dit metagegeven wordt gebruikt om zowel een natuurlijke als een machine leesbare naam in het model op te kunnen nemen. Het metagegeven alias wordt ook wel eens gebruikt om de naam in een andere taal op te nemen in het model, maar dit is niet conform de MIM specificatie. In dit laatste geval, kan er ook maar 1 extra taal worden opgenomen, aangezien het metagegeven alias maar maximaal 1 keer mag voorkomen. Het optionele metagegeven alias op veel verschillende manieren worden toegepast. Om deze reden is het goed om in de documentatie van het informatiemodel toe te lichten waarvoor het alias is gebruikt.
Voorbeeld:
Bij een conceptueel informatiemodel waarin je normale namen gebruikt voor een modelelement, speelt alias nooit een rol. Aangezien Fietsenwinkel een conceptueel informatiemodel is, is alias altijd leeg. Wanneer dit een logisch model zou zijn, dan zouden er geen spaties mogen worden gebruikt en dan zou bijvoorbeeld de attribuutsoort kvk nummer worden opgenomen als “KvkNummer”. De naam met een spatie ertussen zou dan kunnen worden opgeslagen in metagegeven alias.
Wanneer buiten het informatiemodel, ook een model van begrippen (bijvoorbeeld in de vorm van een thesaurus) wordt gehanteerd, bied MIM via het metagegeven begrip de optie om hier een relatie mee te leggen. In het begrip metagegeven wordt de URI opgenomen van 1 of meerdere begrippen waarmee het modelelement een semantische relatie heeft. Wanneer twee dingen een semantische relatie hebben, dan is er een verband tussen de betekenis van deze twee dingen. In MIM worden aanvullende regels voor het verwijzen naar begrippen nader toegelicht in de paragraaf: “Verwijzing van een modelelement naar een begrip uit het begrippenkader” .
Voorbeeld:
In het informatiemodel Fietsenwinkel zou voor de attribuutsoort met de naam “Fiets”, bijvoorbeeld worden verwezen naar de URI: “https://nl.wikipedia.org/wiki/Fiets ”.
Kardinaliteit en mogelijk geen waarde
Het metagegeven kardinaliteit in MIM geeft aan hoeveel keer waarden van een kenmerk mogen voorkomen binnen een objecttype. In de praktijk zien we dit metagegeven terug bij attribuutsoorten en relatiesoorten tussen objecttypen. De notatie [0..*] wordt in MIM bijvoorbeeld gebruikt om uit te drukken dat het kenmerk 0 of meerdere keren voorkomt.
De termen kardinaliteit en multipliciteit worden in het werkveld vaak door elkaar heen gebruikt. In de UML Reference Manual wordt multipliciteit gedefinieerd als een specificatie van het toegestane bereik van kardinaliteitswaarden. Wanneer we deze definitie aanhouden, is de notatie van “[0..*]” is multipliciteit met daar daarin de kardinaliteit “0” als ondergrens en de kardinaliteit “*” (lees “meer”) als bovengrens.
Voorbeeld:
Zie Domein Inventaris. In dit domein valt te zien dat het Objecttype “Winkel” een relatiesoort “verhandelt” heeft met het Objecttype “Fiets”. Het doel van deze relatiesoort “verhandelt” heeft een metagegeven kardinaliteit (multipliciteit) met de waarde “[0..*]”. Wanneer er niets wordt ingevuld is de kardinaliteit van een kenmerk 1. Bij de bron van Relatiesoort “verhandelt” is niets ingevuld, dus is de kardinaliteit “1”. Dit betekent dat 1 winkel 0 of meerdere fietsen verhandelt.
Als een kenmerk een kardinaliteit 0 heeft, is dit iets anders dan wanneer een kenmerk geen waarde heeft. De situatie dat een fietsenwinkel nog 0 fietsen verhandelt, kan bijvoorbeeld voorkomen wanneer een nieuwe winkel nog assortiment moet inkopen. Het metagegeven “mogelijk geen waarde” geeft aan dat een kenmerk in de werkelijkheid wel moet voorkomen, maar dat deze informatie mogelijk niet beschikbaar is.
Voorbeeld:
Zie voor meer toelichting over het gebruik van mogelijk geen waarde de paragraaf hierover in het hoofdstuk Afspraken & Regels.
Herkomst en datum opname
Bij het maken van een informatiemodel kan het zijn dat je een modelelement wil opnemen uit andere informatiemodellen. In dit geval kan de naam van de bron van dit modelelement worden vastgelegd in het metagegeven herkomst. Met de naam van de bron wordt doorgaans de naam van het informatiemodel bedoeld. Wanneer een modelelement zelf is bedacht, kan de naam van het eigen informatiemodel worden ingevuld. Voor de meeste modelelementen zal dit het geval zijn.
Let op:
Het metagegeven “herkomst” is iets anders dan het metagegeven herkomst definitie, ook al wordt hier vaak dezelfde waarde ingevoerd. Bij herkomst definitie gaat het namelijk over de bron van de definitie, terwijl het bij herkomst gaat over de bron van het modelelement.
Herkomst is een verplicht modelelement en moet altijd worden ingevuld bij Attribuutsoorten, Objecttypen, Relatiesoorten, Gegevensgroepen, Relatie doelen en alle soorten Datatypen.
Voorbeeld:
Zie bijvoorbeeld het Objecttype Fiets. Hier staat bij zowel herkomst definitie als herkomst de waarde “IMFW” ingevuld. Dit staat voor Informatiemodel Fietsenwinkel. Dit is overal binnen het IMFW op vergelijkbare manier gedaan. Wanneer de definitie, of het gehele modelelement bijvoorbeeld uit een standaard is gehaald, zal hier de naam van die standaard worden ingevuld. Deze metagegevens werken als een soort bronvermelding van het modelelement.
Het metagegeven datum opname wordt ingevuld met de datum dat een modelelement is toegevoegd aan het model. Zo is te achterhalen in welke versie van het informatiemodel een modelelement is toegevoegd. Over invulling van datum opname kan ook worden afgesproken dat hier de release datum van het informatiemodel wordt ingevuld. Datum opname is bij de meeste modelelementen een verplicht metagegeven. Uitgezonderd zijn datatype elementen, packages en overig. Vanuit MIM wordt er geen specifiek datatype genoemd voor het invullen van dit metagegeven. Een goed advies is om hier het primitieve datatype date te volgen.
Voorbeeld:
Binnen IMFW is voor ieder Objecttype initieel dezelfde datum opgenomen. Wanneer in een nieuwe release nieuwe modelelementen worden toegevoegd, dan zal dit terug te zien zijn in de waarde van datum opname.
Definitie en toelichting
Definities geven betekenis aan de modelelementen van een informatiemodel. Het opstellen van een goede definitie is een proces waarbij het vaak nodig is om inhoudelijke domeinexperts te betrekken. Wanneer al een model van begrippen bestaat kunnen definities uit dit model worden gebruikt. In het metagegeven herkomst definitie wordt dan de bron van deze definitie aangegeven. Wanneer de definitie zelf is opgesteld, wordt hier de naam van het eigen IM ingevuld.
Een toelichting geeft aanvullende informatie over de betekenis van het modelelement. Deze informatie moet de lezer helpen met het begrijpen van het informatiemodel.
Voorbeeld:
De attribuutsoort naam in het IMFW wordt gedefinieerd als: “de naam van het contact”. Deze definitie is afkomstig uit het informatiemodel fietsenwinkel (ons eigen model), dus wordt in herkomst definitie “IMFW” ingevuld. De lezer wordt geholpen met het begrijpen van de attribuutsoort met de toelichting: “Dit is de naam waaronder het contact uniek geïdentificeerd kan worden. Het is niet een-op-een afgeleid van de naam van de Persoon (wanneer het een persoon betreft) maar kan daar wel op zijn gebaseerd”.
Om verwarring te voorkomen moet ieder Object identificeerbaar zijn. Dit kan worden gedaan aan de hand van een natuurlijke sleutel . Dit zijn één of meerdere attribuutsoorten die er bij elkaar voor zorgen dat een object uniek is. Binnen een team zijn er misschien twee personen met dezelfde voornaam, waardoor je altijd de voor en achternaam moet gebruiken. De voor- en achternaam van een persoon zouden in dit geval kunnen worden aangewezen als de natuurlijke sleutel. Of attribuutsoorten deel uitmaken van een natuurlijke sleutel, kan binnen MIM worden aangegeven door gebruik te maken van het MIM metagegeven identificerend.
Als geen natuurlijke sleutel kan worden aangewezen kan een synthetische/technische sleutel worden gebruikt, een ID (identifier). Deze heeft meestal alleen betekenis voor IT systemen. In een logisch informatiemodel is het gebruikelijk om een extra attribuutsoort op te nemen bij een Objecttype waarin zo’n technische sleutel kan worden opgeslagen. Een voorbeeld van zo’n technische sleutel is een GUID. Sommige identifiers zijn inmiddels te beschouwen als natuurlijke sleutel, zoals: BSN, Studentnummer, Documentnummer paspoort, omdat deze nu ook buiten het systeem in de menselijke communicatie worden gebruikt.
Voorbeeld:
Het Objecttype Contact in het IMFW kan uniek geïdentificeerd worden met de waarde van de attribuutsoort naam.
Metagegeven indicatie classificerend geeft aan of de waarden van het attribuut gebruikt kunnen worden om onderscheid te maken tussen verschillende klassen van het Objecttype. Vaak wordt de waarde van deze attribuutsoort bepaald door een Enumeratie met vaste Enumeratiewaarden. Wanneer alle andere attribuutsoorten hetzelfde zijn, is het niet nodig om een nieuw Objecttype aan te maken voor dit nieuwe type.
Voorbeeld:
In Objecttype Sportfiets wordt de waarde van de attribuutsoort “type” bepaald door de Enumeratie “Sportfiets typen”. Dit maakt deze attribuutsoort classificerend.
Populatie en kwaliteit
Populatie geeft aan welke objecten wel en niet in scope zijn van je dataset. Het wordt ook gebruikt om modelelementen verder toe te lichten of te definiëren, en kan indirect verwijzen naar de inwinning en wat dit oplevert voor de populatie in de registratie. Er is dus niet één manier om dit metagegeven te gebruiken, de invulling is sterk afhankelijk van de behoefte en eigen afspraken. Het is tevens niet de bedoeling dit veld te gebruiken om individuen te beschrijven.
Het metagegeven Kwaliteit is, evenals Populatie, generiek opgesteld – en kan dus informatie bevatten over verschillende kwaliteitsaspecten. Dit metagegeven is ook van toepassing in het kader van (basis)registraties.
Voorbeeld:
Voor de invulling van het metagegeven ‘’Populatie’’ en ‘’Kwaliteit’’ kan worden gekeken naar het stelselcatalogus, zie voor een voorbeeld de metagegevens voor ‘’Natuurlijk persoon’’ .
Deze metagegevens zijn vaak bij (basis)registraties aan de orde en worden vrij generiek beschreven, zodat het gebruik niet eenduidig is. Om deze reden is het belangrijk deze metagegevens alleen toe te passen wanneer ze toegevoegde waarde hebben.
Domeinwaarden
Een domeinwaarde legt een beperking op het type van de gegevens van een bepaald modelelement. Domeinwaarden beschrijven aspecten van de structuur waaraan de data van objecten moet voldoen. Wanneer er binnen een veld bijvoorbeeld een mobiel telefoonnummer moet worden opgenomen, wil je dat de waarde van dit veld bestaat uit 10 cijfers en begint met “06”. In MIM gaat het vooral om classificaties (datatype, domein) en het aspect vorm (lengte, patroon, formeel patroon). De metagegevens met betrekking op deze aspecten worden hieronder kort toegelicht.
Het metagegeven Type legt een beperking op het datatype waarmee waardes worden vastgelegd. Dit metagegeven is van toepassing op verschillende modelelementen, zo lang ze een attribuut modelleren. MIM geeft tevens handvaten voor het toekennen van datatypes. Veelgebruikte datatypes uit externe modellen worden in MIM ‘’primaire datatypes’’ genoemd, en zijn beschreven in de standaard. Hierdoor kunnen ze op een eenduidige manier toegepast worden. Voor overige datatypes gelden andere regels en afspraken .
Voorbeeld:
In het informatiemodel Fietsenwinkel betreft de Gegevensgroep Adres een groepering van een aantal attributen, waaronder de attribuutsoorten postcode en locatie. Wanneer men adresgegevens wil representeren, zal de waarde van de ‘’postcode’’ een “CharacterString” moeten zijn. Bij ‘’locatie’’ is de waarde ofwel een ‘’GM_Point’’ of een ‘’GM_Polygon’. Het datatype “CharacterString” behoort tot de primaire datatypes in MIM. Dit zijn veelgebruikte datatypes uit externe modellen, die binnen MIM op eenduidige manier toegepast kunnen worden. De geografische datatypes “GM_Point” en “GM_Polygon” - ook afkomstig van een extern model (GML) – behoren niet tot de primitieve datatypes in MIM, maar worden wel aanbevolen vanuit de standaard .
Een attribuutsoort heeft altijd een waarde, en het kan voorkomen dat het bereik van deze waarden in het informatiemodel beschreven wordt aan de hand van een waardenlijst. Wanneer dit het geval is wordt bij het metagegeven Type een verwijzing opgenomen naar de naam van de desbetreffende waardenlijst (dit kan een MIM referentielijst, codelijst of enumeratie zijn). In het informatiemodel Fietsenwinkel is dit het geval bij het attribuut ‘’kvk nummer’’.
Het metagegeven Domein heeft ook te maken met classificeren. Echter gaat het hier niet om een beperking rondom waarden – zoals bij Type –, maar om een beperking op de context waarbinnen het model en de modelelementen van toepassing zijn. Door het specificeren van een domein kan onderscheid worden gemaakt tussen constructies uit verschillende modellen. Dit metagegeven is dus belangrijk bij het integreren van data uit verschillende modellen, die vanuit het perspectief van een eigen domein zijn beschreven. Het is alleen van toepassing op het niveau van het informatiemodel.
De metagegevens Patroon en Formeel patroon worden ook gebruikt om het bereik van waardes aan te duiden, zoals bij “Type”. Bij het specificeren van een patroon op een attribuutsoort is het verplicht een primitief datatype toe te kennen aan dit attribuutsoort: het patroon legt dan eigenlijk extra beperkingen op aan de invulling van waardes. Een patroon kan ook gespecificeerd worden op eigen primitieve datatypes die in het model zijn gedefinieerd. Meer hierover is te lezen in het hoofdstuk over primitieve datatypen. Bij het metagegeven “Patroon” wordt de structuur in woorden gespecificeerd, bij ‘’Formeel patroon’’ aan de hand van een reguliere expressie.
Voorbeeld:
Voorbeelden waarbij ‘’Patroon’’ bij attribuutsoorten in het informatiemodel Fietsenwinkel voorkomt zijn: ‘’postcode’’, ‘’verloopdatum’’ en ‘’kvk nummer’’. Zo is een postcode altijd een CharacterString, en heeft het aanvullend hierop een specifiek patroon met 4 cijfers en 2 letters. Daarnaast zijn ‘’Garantienummer’’ en ‘’IBAN’’ voorbeelden van eigen primitieve datatypes met patronen: een ‘’IBAN’’ is bijvoorbeeld een subtype van CharacterString, wat een specifiekere vorm kent met een lengte van maximaal 16 tekens.
Zoals in het voorbeeld hierboven genoemd, zou je de lengte van gegevens kunnen specificeren via het metagegeven Formeel patroon. Een andere mogelijkheid is om het metagegeven “lengte” te gebruiken. De betekenis van dit metagegeven hangt samen met het datatype dat van toepassing is. Wanneer het om gegevens gaat die uitgedrukt worden door middel van een tekenreeks of numerieke (hele) getallen, kan het metagegeven ‘’lengte’’ gebruikt worden om de exacte, minimale en maximale lengte van gegevens te bepalen. Als het om hele decimale (gebroken) getallen gaat, kan aan de hand van ‘’lengte’’ worden bepaald hoeveel cijfers voor en na de komma zijn toegestaan.
Let op:
In versie 1.1 van MIM wordt het gebruik van het metagegeven ‘’lengte’’ niet normatief beschreven, waardoor de invulling ervan zou kunnen afwijken. Echter zijn de bovengenoemde afspraken met betrekking tot de invulling wel leidend.
Historie
Historie speelt een belangrijke rol in veel registraties, aangezien het gebruikt kan worden om te achterhalen wanneer een gegeven ontstond (of wanneer bekend was dat deze ontstond). Het is dus in feite een specifieke soort metadata, wat vaak in een logisch model verder uitgewerkt wordt. Aangezien historie gegevens vaak van belang zijn, kan het ook baat hebben om het bijhouden van historie al in een conceptueel model te beschrijven. Het gaat dan niet zozeer om de vastlegging van historie (hier voorziet MIM niet in ), maar om het registreren van de aanwezigheid van historie in een onderliggend (logisch) model. Deze indicatie materiele historie of indicatie formele historie zijn van toepassing op modelelementen die een eigenschap kunnen zijn van een objecttype. Materiele historie geeft aan wanneer de gegevens bekend/geregistreerd zijn, en gaat dus over het administratieproces. Formele historie geeft aan wanneer iets in de (aangehouden) werkelijkheid is gebeurd.
Let op:
De termen ‘’materiele historie’’ en ‘’formele historie’’ kunnen respectievelijk worden vervangen door ‘’tijdstip registratie’’ en ‘’tijdlijn geldigheid’’. In een volgende versie van MIM worden deze waarschijnlijk hernoemd.
Relaties en rollen
Bij het leggen van relaties tussen modelelementen (veelal objecttypes) zijn naast meer algemene metagegevens (zoals ‘’naam’’, ‘’definitie’’, ‘’begrip’’ en ‘’herkomst’’) ook een aantal extra metagegevens van toepassing. Deze worden in het kort besproken.
Het metagegeven Unidirectioneel geeft aan of een relatie gericht is of niet. Een gerichte (unidirectionele) relatie) geeft aan dat de gegevens conform het model voornamelijk bevraagd/beschreven worden vanuit het perspectief van het zogenaamde bronobject van de relatie. Vanuit het bronobject wordt dan verwezen naar het doelobject. De metagegevens Bron en Doel geven aan wat het bronobject en het doelobject van de relatie is. (In Engelse modelleertools wordt ook wel gesproken over ‘’Source’’ en ‘’Target’’)
Het metagegeven Aggregatietype wordt gebruikt om een aggregatie relatie verder te specificeren. Er is sprake van een aggregatie relatie wanneer een object in het model (het doelobject) wordt gezien als onderdeel van een ander object in het model (het bronobject). Dit metagegeven wordt standaard ingevuld met de waarde ‘’Geen’’. Wanneer wel sprake is van een aggregatie kan via dit metagegeven worden gedeeld of het om een ‘’Compositie’’ of een “Gedeelde” aggregatie gaat. Bij een Compositie is het doelobject alleen onderdeel van het bronobject, maar bij een Gedeelde kan deze ook onderdeel zijn van meerdere bronobjecten.
Voorbeeld:
In het Fietsenwinkel model heeft het objecttype ‘’Fiets’’ een relatie “aangestuurd door” met het objecttype ‘’Batterij’’. De ‘’Relatie eigenaar (bron)’’ voor deze relatie is ‘’Fiets’’, en ‘’Relatie doel’’ is ‘’Batterij’’. Het ‘’Aggregatietype’’ van de relatie is ‘’Compositie’’, aangezien het wegvallen van de gegevens over een Fiets impliceert dat de gegevens betreffende de Batterij van deze fiets ook vervallen.
Er is een relatie die in MIM verder wordt gedefinieerd, namelijk de Generalisatie. Deze is altijd van toepassing tussen twee objecttypes of twee datatypes. Bij het specificeren van een Generalisatie relatie dienen de metagegevens ‘’Subtype’’ en ‘’Supertype’’ te worden ingevuld.
Wanneer de kenmerken van alle subtypen gelijk zijn is dit ook met een classificerend attribuuttype te modelleren. Er zijn verschillende redenen om voor deze optie te kiezen. Wanneer dit het geval is, wordt het metagegeven ‘’Indicatie classificerend’’ toegepast bij het attribuut dat naar de lijst verwijst. Voor de gegevens die worden vastgelegd is er geen verschil, maar in het bedrijfsproces is het onderscheid wel van belang. Dit wordt verder beschreven in de sectie Identificatie en afleidbaarheid.
MIM staat toe een relatie tussen objecttypes op twee manieren te beschrijven, namelijk via het benoemen van de relatiesoort of via het benoemen van de relatierol. Een overzicht met de metagegevens die van toepassing zijn bij de beschrijving vanuit Relatiesoort of vanuit Relatierol is te vinden in de MIM-Specificatie (voor relatiesoort leidend ) en (voor relatierol leidend ).
Uitbreiding van het metamodel
Een MIM model is een beschrijving van een snapshot van dat informatiemodel – een moment in de tijd waarop het model was vastgesteld. Maar inzichten veranderen en ook modellen veranderen. We hebben daarom in de praktijk vaak versie-informatie nodig op het informatiemodel, de domeinen en misschien zelfs op modelelementen zoals objecttypen en relaties. Dat vereist uitbreiding van het metamodel, bijvoorbeeld met een release naam, een versienummer, een fase waar deze versie in bevindt (klad, eindversie), auteursinformatie, e.d. Zulke constructies kunnen door middel van extensies worden toegevoegd. Ze vormen géén onderdeel van het MIM.
Uitbreidingen worden soms gerealiseerd door het toevoegen van kenmerken, bijvoorbeeld:
Positie. UML kent veelal geen “positie” van klassen, relaties e.d. terwijl dat voor een lezer wel relevant kan zijn. Voorbeeld: de positie in XML schema’s is relevant. (Nieuw kenmerk “positie”.)
Minimum/maximum waarde. In MIM 1.1 kan de een waardenbereik niet worden opgegeven. (Nieuwe kenmerken “minimum waarde” en “maximum waarde”.)
Relatie met andere modellen. Een model staat vaak niet alleen, maar is afgeleid van andere, meer fundamentele modellen, Zo is een productmodel misschien afgeleid van een bedrijfsobjectenmodel. In het product wordt een specifiek onderdeel opgenomen. (Nieuw kenmerk “afgeleid van”.)
Uitbreidingen kunnen ook de vorm van nieuwe modelelementen krijgen, bijvoorbeeld:
Een koppelklasse is een nieuw modelelement dat twee of meer objecttypen met elkaar verbindt, zonder dat deze objecttypen dat zelf registreren. (Nieuw modelelement “koppelklasse”.)
Een generalisatie relatie wordt gekenmerkt als statisch, waarmee wordt aangegeven dat alleen kenmerken van het supertype worden overgenomen door het subtype. (Nieuw modelelement “statisch”.)
Uitgangspunt is dat het aantal extensies beperkt blijft. Wanneer zo’n extensie wordt geïntroduceerd is het zaak dit in een breder verband aan te melden zodat nieuwere versies van MIM er hun voordeel mee kunnen doen.
Bijlage: Overzicht van metagegevens
In het volgende overzicht vind je alle modelelementen (horizontaal) en de metagegevens (vertikaal) die daar mogelijk op gespecificeerd moeten worden.
V is: verplicht.
O is: optioneel.
Andere metagegevens zijn niet van toepassing op het modelelement.
Attribuutsoort
Codelijst
Constraint
Data element
Domein
Enumeratie
Enumeratiewaarde
Extern
Externe koppeling
Gegevensgroep
Gegevensgroeptype
Generalisatie Datatypes
Generalisatie Objecttypes
Gestructureerd datatype
Informatiemodel
Keuze
Objecttype
Primitief datatype
Referentie element
Referentielijst
Relatieklasse
Relatierol - Relatierol leidend
Relatierol - Relatiesoort leidend
Relatiesoort - Relatierol leidend
Relatiesoort - Relatiesoort leidend
View
Aggregatietype
V
V
Alias
O
O
O
O
O
O
O
O
O
O
O
O
O
O
Authentiek
V
V
V
V
Begrip
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
Code
O
Datum opname
V
V
V
V
V
V
V
V
V
V
V
V
V
Definitie
V
V
O
V
O
V
V
O
V
V
V
V
O
V
V
V
V
O
O
V
V
Formeel patroon
O
O
O
O
O
Gegevensgroeptype
V
Herkomst
V
V
V
V
V
V
V
V
V
V
V
V
V
Herkomst definitie
V
V
O
V
V
V
Identificerend
O
O
Indicatie abstract object
V
Indicatie afleidbaar
V
V
Indicatie classificerend
V
Indicatie formele historie
V
V
V
V
Indicatie materiële historie
V
V
V
V
Informatiedomein
V
Informatiemodel type
V
Kardinaliteit
V
V
V
V
V
V
Kwaliteit
O
Lengte
O
O
O
O
Locatie
V
V
V
V
MIM extensie
O
MIM taal
O
MIM versie
V
Mogelijk geen waarde
V
V
V
Naam
V
V
V
V
V
V
V
V
O
V
V
O
V
V
V
V
V
V
V
V
V
O
O
V
V
Patroon
O
O
O
O
O
Populatie
O
Relatie doel
V
V
Relatie eigenaar
V
V
Relatiemodelleringtype
V
Specificatie formeel
O
Specificatie tekst
O
Subtype
V
V
Supertype
V
V
Toelichting
O
O
O
O
O
O
O
O
O
Type
V
V
V
Unidirectioneel
V
V
Bijlage: Demonstrator
De Demonstrator is een software product waarmee op eenvoudige manier een MIM informatiemodel kan worden bekeken, of zelfs kan worden opgebouwd. Het geeft een intuïtieve toegang tot deze Primer en de standaard. Het is niet bedoeld als productie-software.
Demonstrator screenshot
De Demonstrator heeft nu nog de alfa status, dus is functioneel en technisch nog in ontwikkeling. De Demonstrator is benaderbaar via:
Dit informatiemodel is een conceptueel model, dat de administratie van fietsenwinkels beschrijft. Centraal staat de Fiets, die door de Winkel wordt ingekocht van Leverancier en verkocht aan Klant.
Dit model is fictief en bedoeld om weer te geven welke modelelementen en metagegevens op welke plekken een rol kunnen spelen.
Nb. In het model komen gestippelde pijlen voor. Deze hebben geen rol in de MIM 1.1 aannames voor de inrichting van UML diagrammen. Ze duiden aan dat de bron van de pijl een afhankelijkheid heeft van het doel.
Gegevensdefinitie
Model Fietsenwinkel
Informatiemodel - overzicht
Informatiemodel - overzicht
Dit is het overzicht van Objecttypen die een rol spelen in het Fietswinkel informatiemodel.
De details zijn weergegeven in aparte diagrammen.
Domein Inventaris
Inventaris - overzicht
Inventaris - overzicht
Overzicht van alle constructies betreffende het Inventaris domein.
Objecttypen
Stadsfiets
Naam
Stadsfiets
Herkomst
IMFW
Definitie
Een fiets die is ingericht op gebruik in het stadsverkeer.
Herkomst definitie
IMFW
Toelichting
Een stadsfiets heeft typisch een bagagedrager, spatborden en verlichting.
De omvang van de fiets in dimensies vanaf voor tot achterband (opgepompt), uitersten
van trappers of bak of bagagedrager, en hoogste punt vanaf de weg (stuur, zadel).
De omvang van de fiets in dimensies vanaf voor tot achterband (opgepompt), uitersten
van trappers of bak of bagagedrager, en hoogste punt vanaf de weg (stuur, zadel).
Dit is de naam waaronder het contact uniek geindentificeerd kan worden. Het is niet
een-op-een afgeleid van de naam van de Persoon (wanneer het een persoon betreft) maar
kan daar wel op zijn gebaseerd.
