Toevoegen van de mogelijkheid dat een Gegevensgroeptype een Relatiesoort mag "bezitten" (bronkant)

[architolk]

Een Gegevensgroeptype kan op dit moment geen relatiesoort "bezitten". Het gevolg daarvan is dat slecht eenvoudige Attribuutsoorten zijn toegestaan, terwijl het prima denkbaar is dat een Gegevensgroeptype uitgaande relaties heeft (gezien de betekenis van Gegevensgroeptype lijkt het niet logisch dat een Gegevensgroeptype ook inkomende relaties heeft, dus niet aan de "doel" kan en de relatiesoort zou dan ook altijd unidirectioneel moeten zijn).

Ik ben dit tegen gekomen in een MIM model dat gebruikt wordt bij RWS, opgesteld door Danny Greefhorst. Bij navraag gaf Danny aan dat hij hier gekozen had voor een Gegevensgroeptype, omdat het geen Objecttype was (conform de regels van MIM), maar dat hij wel de behoefte had om vanuit dit Gegevensgroeptype te verwijzen naar een ander Objecttype.

In dit specifieke geval was het Gegevensgroeptype een classificatie, die bestond uit enkele attribuutsoorten, plus een relatie naar een bedrijfsbegrip (het Objecttype waar naar werd verwezen).

(NB: mijn voorkeur zou het hebben om het metamodel van MIM sterk te vereenvoudigen door een supertype te introduceren van Objecttype, net zoals in UML, waarbij dan Objecttype, Relatieklasse, Gegevensgroeptype en Gestructureerd Datatype allen van overerven: je kunt het dan een stuk eenvoudiger houden - maar da's wellicht wat voor een ander issue, die hier voorgesteld wijziging is feitelijk niet zo groot en voegt alleen wat toe, zou in een .Z versie kunnen worden doorgevoerd)

[lennartvanbergen]

Het is uitdrukkelijk wel de bedoeling dat een gegevensgroep een relatie mag bezitten. Heeft altijd gemogen. Lijkt me een documentatie hiaat.

@PalmJanssen eens toch?

(mbt de opm tussen ( ) dat is een andere casus, apart punt)

[lennartvanbergen]

In H3 UML staat al dat het mag, we gebruiken het bij Kadaster al 5+ jaren zo. Beetje gek dat het dan in een Kadaster extensie zou moeten.

Gegevensgroeptype

| heeft relatiesoort | 0.. | Binding aan een relatiesoort of relatieklasse. | owned element = UML-Relationship | | association | | | heeft externe koppeling | 0.. | Binding aan een externe koppeling. | owned element = UML-Relationship | | association | |

[architolk]

Deze tekst is er bij gekomen in deze onderhand versie. Het zit echter niet in het plaatje dat daarvoor als de geldende bron was, vandaar... Als het origineel ook altijd al de bedoeling is geweest, dan moeten we dat er nog wel aan toevoegen idd in H4. Kan ik vandaag nog wel ff doen als jullie dat goed vinden. Overigens geldt iets soortgelijks voor Relatieklasse: daar lijkt 't mij in ieder geval wenselijk dat attribuut moet kunnen, maar wellicht ook relatiesoort?

[lennartvanbergen]

Relatieklasse zonder attributen is een hiaat, dat hoort uiteraard wel te kunnen, dat is het hele bestaansrecht van de relatieklasse. Deze heb ik alvast toegevoegd aan H3. Dit issue 229 kan dus blijven gaan over gegevensgroeptype.

Terughoudender bij relatiesoort van een relatieklasse, dat zijn de zogenaamde tertiaire relaties eigenlijk. Die zou ik nu niet willen meenemen.

[architolk]

@lennartvanbergen-kadaster : ik heb Relatieklasse - attribuutsoort nog niet toegevoegd aan H4: zal ik dat alsnog doen?

[PalmJanssen]

Je zou deze verwachten: Relatieklasse heeft attribuut Relatieklasse heeft gegevensgroep Relatieklasse heeft keuzeattribuut en deze zijn complexer en mogelijk niet nodig: Relatieklasse heeft externe koppeling Relatieklasse heeft relatiesoort

[lennartvanbergen]

ja eens met die eerste 3.

[lennartvanbergen]

Kortom:

verbinden gegevensgroeptype met

• relatiesoort
• externe koppeling
• en ook de 3 keuze mogelijkheden

H2 + H3 tekst --> L, gereed H2 en bijlage diagram --> P H4 --> M

[PalmJanssen]

De toepassing van Keuze geeft nu in UML een boel gedoe. Heeft ook weer met het ontbreken van een superklasse te maken. Ik stel voor om het in de tabel wel te doen, maar in het UML nog niet op te nemen. Wel met tekst dat Relatieklasse voor Keuze hetzelfde patroon volgt.