Verschillende soorten generalisaties (bv. static liskov of mix in)

[lennartvanbergen]

Vanuit harmonisatie Imvertor profielen (facilitator FT) --> langslopen van modelelementen (stereotypes) die door meerdere organisaties gebruikt worden en waar meerdere organisaties (3+) behoefte aan hebben:

Vanuit https://github.com/Geonovum/MIM-Werkomgeving/issues/132

--

Behalve de normale generalisatie/specialisatie zijn er andere soorten generalisatie in gebruik.

static liskov - https://en.wikipedia.org/wiki/Liskov_substitution_principle mix in beide zijn een aanvulling om de algemene betekenis van generalisatie en hebben te maken met overerving. Ze zijn er om aan te geven dat eigenschappen van de superklasse na de subklasse moeten worden verplaatst in een implementatie, waarbij de superklasse wegvalt.

De aanleiding is meestal om multiple inheritance issues op te lossen in talen/specificaties die dit niet (of niet eenvoudig) ondersteunen. Als er gekozen moet worden voor 1 van de 2 overervingen (omdat een taal geen multiple inheritance ondersteund), dat je dan de deze nadere aanduiding/aanvulling volgt bij het bepalen welke generalisatie

Typisch zie je deze aanvulling bij MIM-niveau 3 - logische IMen.

Maar het is ook op zichzelf functioneel mogelijk, dus ook op MIM - niveau 2 en het is niet noodzakelijk om multiple inheritance te hebben om het toe te kunnen passen. Bv. als je ontologisch de generalisatie wilt aangeven, bv. naar een Europees Adres, zonder de superklasse Europees Adres in je eigen domein te trekken.

Er is ook nog een 'static', de vraag is of we static, static liskov en mix in nodig hebben of dat 1 of 2 van deze al volstaat.

De vraag is of deze vervolgens gedefinieerd kunnen worden en toegevoegd kunnen worden aan MIM.

[ArjanLoeffen]

Ik heb nu in lijn met deze discussies twee stereotypen toegevoegd:

<<Static Liskov>> Een generalisatie relatie waarin wordt aangenomen dat het subtype de plek kan innemen daar waar het supertype is gespecificeerd. Daarnaast neemt het structuur-eigenschappen over (attributen, relaties). Voorbeeld: Racefiets is Fiets. Ik neem aan dat Static Liskov feitelijk hetzelfde is als Generalisatie zoals in de MIM standaard bedoeld. Graag feedback.

<<Static>> Een generalisatie relatie waarin wordt aangenomen dat het subtype alléén structuur-eigenschappen overneemt van het supertype. Het subtype kan niet (per definitie) de plaats innemen van het supertype. Voorbeeld: Racefiets is Vervoermiddel-met-twee-wielen.

[dkrijtenburg-GNM]

conceptueel maakt dit niet uit maar op logisch model moet je hier iets mee

[PalmJanssen]

Deze is gerelateerd aan #132 voor wat betreft <<Static>>.

Ik zie geen verschil tussen <<Static Liskov>> zoals beschreven hierboven en een MIM <<Generalisatie>>. <<Static liskov>> hoeft dus niet in MIM.

<<Static>> zit nu niet in MIM maar zou er wel een plaats in moeten hebben. Het heeft dan de volgende definitie: <<Static>> Een generalisatie relatie waarin bij een implementatie het subtype alléén structuur-eigenschappen overneemt van het supertype.

Opmerking:

• Er is in de definitie bewust niet opgenomen dat de subklasse per definitie geen type conformiteit heeft. Daar wordt niets over gezegd.
• <<Static>> kan zowel bij MIM niveau 2 als 3 worden opgenomen.
• <<Static>> wordt toegepast als stereotype op een UML generalisatie relatie.
• de doelklasse van een <<Static>> relatie is heeft altijd een beperkte complexiteit is altijd abstract en heeft geen subtypes.
• <<Static>> is equivalent van de Inspire tagged value gmlMixin = trueop een FeatureType

[lennartvanbergen]

Ik kan goed leven met deze uitwerking.

[pmaria]

Ik wordt niet echt blij van deze toevoeging. Wat voor use cases zijn er hier voor? Waarom zouden we dit moeten toevoegen? Zijn er geen alternatieven?

We introduceren hier een manier om eigenschappen uit het ene objecttype te "'kopieren" naar een andere, zonder een is-deelverzameling-van relatie uit te drukken. Dit lijkt erg op waar gegevensgroepen voor bedoeld zijn.

Ik zie dat ik hetzelfde ook al eerder heb opgemerkt: https://github.com/Geonovum/MIM-Werkomgeving/issues/132#issuecomment-982577401

Ik denk dat we hier onnodig extra complexiteit introduceren.

Een aantal additionele vragen:

• <<Static>> kan zowel bij MIM niveau 2 als 3 worden opgenomen.

Wat is de betekenis van <<Static>> in een niveau 2 model? Ik zie geen noodzaak voor dit construct in een conceptueel model. Dit is een puur een gegevensstructuur gerelateerd iets, gezien er geen conceptueel verband bestaat tussen via <<Static>> relatie verbonden objecttypen.

• de doelklasse van een <<Static>> relatie is heeft altijd een beperkte complexiteit [...]

Wat betekent beperkte complexiteit?

[...] en heeft geen subtypes.

Dit snap ik niet. Er kunnen toch meerdere concrete types zijn die gebruikmaken van een objecttype als supertype?

[lennartvanbergen]

We willen niet graag de mogelijkheid ontnemen op conceptueel niveau, tenzij absoluut zeker is dat het nooit nodig gaat zijn.

Voorbeelden:

Bv. 2 bovenliggende abstracte objecttypes zoals: fysiek object en juridisch object. In het informatiedomein kan het dan vooral gaan om bv. het fysieke object.

Bv. 2 bovenliggende abstracte objecttypes zoals: onroerende zaak is een kadastraal object en onroerende zaak is een virtueel object (een ander kadastraal object is een appartementsrecht en dit is een juridisch object). Het kadastrale object is waar het om gaat in de BRK, dus de hiërarchische relatie naar virtueel object wordt static gemaakt.

Het komt denk ik ook voor bij generalisaties. Waarbij 2 objecttypes gegeneraliseerd worden tot een generieker objecttype. Zoals een natuurlijk persoon en een rechtspersoon worden gegeneraliseerd naar een persoon. In de wereld lopen geen personen rond, maar lopen ofwel natuurlijke personen rond, ofwel rechtspersonen (ok, deze laatste lopen niet echt). Bij generalisaties komt het ook voor dat je deze wilt doorknippen, omdat bv. de identificatie in natuurlijk persoon zit (bsn) en niet in persoon. In feite is persoon niet de resource, maar natuurlijk persoon is de resource (deze komt voor, over de abstracte persoon kunnen we het alleen in abstracte zin hebben).

Bij de uitwerking is het goed om voorgenoemde voorbeelden ook mee te nemen, om mensen te voorzien van begrip dmv voorbeelden.

De inschatting is dat classificatie op conceptueel niveau geen rekening zou moeten hoeven houden met het oplossen van multiple inheritance. Prima om iets 2x te classificeren op MIM 2 niveau.

Eens dat we static dus alleen voor MIM-2 doen.

In de toolbox zou ik niet te moeilijk gaan doen. Je kan controleren of iemand static niet op mim-2 gebruikt.

[PalmJanssen]

Static voor logisch model en niet voor conceptueel model

[PalmJanssen]

uitwerking voor 1.2 publicatie

2.3.2 Static overervingsrelatie

Definitie Static overervingsrelatie Een overervingsrelatie waarin het subtype alléén structuur-eigenschappen overneemt van het supertype.

Toelichting: Een static overervingsrelatie of kortweg een static relatie wordt bij UML toegepast op een generalisatie. De aanleiding is meestal om multiple inheritance issues op te lossen in talen/specificaties die dit niet (of niet eenvoudig) ondersteunen. Het subtype erft bij een static relatie alleen de kenmerken van een supertype en niet de type conformiteit. Bijvoorbeeld een static relatie tussen een objecttype Document als static subtype van Juridische informatie geeft aan dat een document de eigenschappen van Juridische informatie overerft maar zelf geen juridische informatie is. Omdat multiple inheritance op MIM niveau wel is toegestaan zal een static relatie vrijwel alleen op MIM niveau 3 voorkomen, het is immers een constructie om in het logische model geen implementatie issue te hebben.

Er gelden een paar eisen voor het supertype in de static overerving:

• het objecttype is abstract en kan dus niet geïnstantieerd worden.

Voorbeeld. Een objecttype Onroerende zaak is een subtype van Kadastraal object en heeft een static relatie met Virtueel object. Het kadastrale object is waar het om gaat in de BRK. Een onroerende zaak heeft daarmee een type conformiteit met Kadastraal object. De relatie naar Virtueel object wordt static gemaakt om aan te geven dat alleen de attribuutsoorten worden overerft.

@lennartvanbergen graag review voor dat ik het als pull request verwerk.

[PalmJanssen]

Paul maakt een pull request

[lennartvanbergen]

Ik vraag me dit sterk af, komt dit uit een standaard? en niet de type conformiteit. Bijvoorbeeld een static relatie tussen een objecttype Document als static subtype van Juridische informatie geeft aan dat een document de eigenschappen van Juridische informatie overerft maar zelf geen juridische informatie is.

Want hoe ik het zelf toepas, is om multiple inheritance op te lossen en niet meer dan dat.

De classificatie is dus wel terecht en blijft ook semantisch gezien zo, dus de typering en classificatie blijft wel bestaan.

Het document is en blijft juist juridische informatie, in een conceptueel informatiemodel zal de relatie er nog steeds zijn.

Ik zie 2 use cases:

1. in CIM wordt 1 van de 2 inheritance relaties van static voorzien. Dit geeft aan welke qua classificatie wel semantisch gezien blijft gelden maar op LGM niveau doorgeknipt kan worden, oftewel de static relatie wordt verwijderd en vervangen door de attributen op te nemen in het subtype (copy down)
2. in CIM staan beide overerving relaties en in het LGM wordt bij 1 door de opsteller van het LGM de static waarde toegevoegd, om aan te geven dat bij het maken van technische modellen het supertype kan worden genegeerd en de static relatie wordt verwijderd en vervangen door de attributen op te nemen in het subtype (copy down)

Zo kijk ik er althans tegenaan.

De tekst geeft nu echter aan dat classificatie/typering anders geinterpreteerd moet worden. Dat lijkt me net te sterk/niet de bedoeling.

[pmaria]

Ik zou dit nu oplossen door op MIM niveau 2 gebruik te maken van multiple inheritance en op MIM niveau 3, desgewenst, gebruik te maken van single inheritance van maar 1 van de superklasses waarbij ik de benodigde eigenschappen van de andere superklasse(s) gewoon opneem in de concrete/specialiserende klasse.

Daar heb ik geen static voor nodig.

Mijns inziens introduceert dit onnodige complexiteit in MIM.

Als gebruiker zul je uiteindelijk in het gebruik toch hetzelfde moeten doen met een static relatie in een MIM niveau 3 model. Namelijk de eigenschappen kopieren naar je concrete objecttype.

[PalmJanssen]

@lennartvanbergen akkoord. Ik heb het iets te mooi willen opschrijven en daarmee iets geintroduceerd wat niet nodig is. De type conformiteit. De use cases die je noemt zijn ook akkoord.

@pmaria Ik wil ook in een LGM kunnen vastleggen dat attributen ergens (de static generalisatie) vandaan komen. Dat kan inderdaad ook in het CM maar die exclusiviteit wil ik het CM niet geven.

Trouwens een Static generalisatie gebruik ik als ik twee modellen wil combineren en daaruit blijkt dat er multiple inheritance ontstaat. Die multiple inheritance wil ik dan laten zien (semantiek, ook op LGM) en ook kunnen implementeren.

[PalmJanssen]

Pull request voor review: #343

[ArjanLoeffen]

MIM 1.2 heeft nu mixin als tagged value. Een generalisatie heeft het stereotype <<generalisatie>> en niet <<static>>.

In de code wordt static nog steeds gebruikt als indicator van mixin/copydown. We gaan dat niet overal veranderen. Onder water blijft static gehandhaafd. Echter, het kan niet als "primair" stereotype worden opgenomen, maar moet als secundair (tweede) stereo worden geplaatst; dit gebeurt door het systeem op basis van de waarde van Mixin.