Onduidelijkheid over paragraaf 1.8 van het MIM

[melsk-r]

In de MIM community bijeenkomst van 6-7-2023 ontstond er enige spraakverwarring over het OMG vier lagen model. Daaruit bleek dat niet voor iedereen even duidelijk was waar elke laag nu eigenlijk precies voor stond, wat voor modellen nu eigenlijk in de diverse lagen terug te vinden zouden zijn en in het bijzonder waar de extensie op het MIM, waar Danny over vertelde, precies in dat model gepositioneerd moest worden. Ik had niet het idee dat de spraakverwarring in de bijeenkomst werd opgelost.

In gesprekken die ik de afgelopen weken al met mijn collega hierover heb gevoerd bleek ook al dat over dat vier lagen model veel onduidelijkheid bestond. Die verwarring werd in mijn gesprekken met mijn collega's nog eens verhoogd omdat daarbij de eveneens in het MIM ter sprake gebrachte onderverdeling in model types om de hoek kwam kijken. Veel onduidelijkheid dus, bij mij, bij mijn collega maar dus blijkbaar ook bij anderen.

Volgens mij is er m.b.t. paragraaf 1.8 en misschien 1.6 van het MIM nog wat werk aan de winkel. Mij lijkt het heel nuttig om meer duiding te geven aan wat elke laag nu precies bevat en daarbij aan te geven hoe dat dan relateert aan de typering van de modellen.

Hieronder even zoals ik het OMG vier lagen model nu interpreteer.

Het model kent de lagen M3, M2, M1 en M0.

• De M3 laag bestaat uit het MOF, wat een meta-metamodel is voor het model op de M2 laag. Ik denk dat er over deze laag weinig onduidelijkheid bestaat;
• De M2 laag bevat het basale UML-metamodel, een model waarin modelelementen als 'UML class' en 'UML association' zijn gemodelleerd. Ik denk dat rondom deze laag veel onduidelijkheid leeft. Overigens niet rondom de toepassing van 'UML class' en 'UML association' die herkennen we immers wel in onze modellen. Duidelijk is ook dat deze laag de basis vormt voor de modellen op de M1 laag;
• In de M1 laag worden de modellen gepositioneerd waaraan wij een groot deel van onze tijd besteden. Modellen als het IMKAD, IMBAG en RGBZ;
• In de M0 laag tenslotte bevinden zich de instanties van de modellen in de M1 laag. Ik vermoed dus dat je hier de JSON en XML instanties moet plaatsen met de objecten, hun properties en de waardes van die properties.

Waar ik, en misschien ook anderen, mee worstel is waar het MIM model dan ergens gepositioneerd zou moeten worden. Ik zou verwachten dat zich dat ergens tussen laag M2 en M1 bevindt. De volgende alinea's van paragraaf 1.8 van het MIM gaan hier denk ik over:

Het UML metamodel (M2) is een ‘read only’ model. Dat wil zeggen dat we geen bestaande metaclass mogen aanpassen en we dus geen nieuw basis metaclass voor een bestaande UML metaclass mogen specificeren. Maar via Profiles (van de InfrastructureLibrary) kunnen bestaande metaclasses uitgebreid worden zonder dat er nieuwe metaclasses gedefinieerd hoeven te worden en dus zonder aanpassing van het basale UML-metamodel (M2). De extensiemechanismen hiervoor zijn stereotypes, tagged values en constraints.

Nadrukkelijk moet daarbij worden vermeld dat het MIM metamodel geen semantiek overneemt van UML. Met het uitdrukken van het MIM metamodel in een UML profiel wordt het alleen mogelijk gemaakt om, zonder verlies van de originele semantiek van het MIM, een MIM model uit te drukken in UML.

maar bieden wat mij betreft te weinig houvast. Daarnaast roept de volgende tekst:

It should be noted that we are by no means restricted to only these four meta-layers, and it would be possible to define additional ones.

op deze pagina nog wat vragen op. Ik heb helaas geen documentatie op de OMG site gevonden die deze stelling bevestigd maar als het klopt is het dan niet zo dat het vier lagen model in ons geval juist een vijf lagen model moet zijn? Dat heeft dan denk ik de volgende vorm:

• de M4 laag bestaat uit het MOF;
• de M3 laag bevat het basale UML-metamodel;
• het MIM is terug te vinden op de M2 laag;
• in de M1 laag zitten onze eigen modellen;
• en in de M0 laag tenslotte de instanties van onze eigen modellen.

Dan nog de verwarring die speelt m.b.t. de typering van de modellen. In die typering worden 4 types onderkend:

1. Model van begrippen
2. Conceptueel informatiemodel
3. Logisch informatie- of gegevensmodel
4. Fysiek of technisch gegevens- of datamodel

Binnen VNG Realisatie kennen wij de volgende 3 type modellen:

• Conceptuele Informatie Modellen (CIM);
• Uitwisselings Gegevens Modellen (UGM);
• Bericht Structuur Modellen (BSM).

Een UGM is een vertaling van een CIM naar een technische structuur. Daarin slaan we bijv. groepen of relaties plat als dat technische voordelen oplevert. M.b.v. een BSM plaatsen we vervolgens de technische structuur van een UGM in een model waarmee we berichten waarmee die gegevens worden verstuurd modelleren zodat daaruit (in ons geval) OAS specificaties gegenereerd kunnen worden.

De mapping van een CIM is duidelijk en een UGM is volgens mij niets anders dan een Logisch gegevensmodel. De neiging bestaat om een BSM vervolgens te mappen op een Fysiek of technisch gegevensmodel maar volgens mij is dat niet correct. Paragraaf 1.6.4 van het MIM stelt immers:

Specificeert de structuur en eigenschappen van de technologie waarin de informatie wordt vastgelegd of uitgewisseld.

Het is dus geen modellering wat het BSM wel is en dat wordt bevestigd door de eerste zin van de 3e bullet van paragraaf 1.6.5:

Het voorliggende metamodel voor het modelleren van informatie (MIM) is bedoeld voor niveau 2 en niveau 3: t.b.v. een zuiver conceptueel informatiemodel (2) en t.b.v. een logisch informatiemodel (3).

Wat volgens mij onder een Fysiek of technisch gegevensmodel wordt verstaan is bijv. een XML-, JSON- en YAML-schema. De vraag is dus waar we een BSM dan kunnen positioneren. Dat lukt dus niet met de 4 genoemde types en mij lijkt dus dat daar een vierde type aan toegevoegd moet worden, een 'Berichtstructuur model'.

Wat we nu zouden kunnen proberen is beide indelingen met elkaar te combineren. Hieronder doe ik een poging:

Hierin komen 2 termen voor die ik nader moet verklaren. MUG staat voor Metamodel Uitwisselings Gegevens. Binnen VNG Realisatie gebruiken wij voor het modelleren van een UGM niet dezelfde modelelementen als in een CIM. Zo onderkennen we daarin een Entiteittype i.p.v. een Objecttype. Daarnaast zijn er in het MUG een aantal metagegevens gedefinieerd die in het MIM niet bestaan. MBG staat voor Metamodel Berichtstructuur Gegevens. Een metamodel waarmee we binnen VNG Realisatie een BSM modelleren. Beide modellen bestaan nog niet formeel maar aan een MBG wordt nu gewerkt.

[Gtrouborst]

Zie ook: issue #320

[melsk-r]

@Gtrouborst @PalmJanssen N.a.v. de consulatie van versie 1.2 van het MIM heb ik nog eens goed gekeken naar de paragrafen 1.7 en 1.8. Ik denk dat met een aantal kleine wijzigingen/toevoegingen het verhaal net even duidelijker wordt. Hierbij mijn voorstel. Paragraaf 1.9 heb ik daar niet in betrokken aangezien ik te weinig kennis heb van LD.

Om het verhaal nog duidelijker te maken en verwarring te voorkomen adviseer ik overigens wel dat in paragraaf 1.6 en onderliggende subparagrafen niet meer gesproken wordt over niveau's maar over types. Ten eerste geeft de titel van paragraaf 1.6 al aan dat het om verschillende types gaat dus waarom zou je dan later het begrip niveau's hanteren. Ten tweede denk ik dat dit verwarrend werkt i.r.t. de niveau's in de paragrafen 1.8 en 1.9 waar n.m.m. met meer recht over niveau's wordt gesproken.

Bovenstaande zal ik natuurlijk ook melden in mijn review op versie 1.2 van het MIM.