Levensfasen - uitwerking 2 - gepland object (schaduw-objecttype)

[pmaria]

Deze modelleringen zijn uitwerkingen o.b.v. deze casus waarbij er voor objecttypes die onderhevig zijn aan planning een "geplande" variant van dat objecttype wordt geïntroduceerd. Deze heeft dezelfde eigenschappen als het normale objecttype, maar representeert altijd een geplande versie daarvan.

[pmaria]

Alternatief a - Gepland object met dezelfde id

In deze uitwerking wordt er naast het objecttype Verharding een objecttype GeplandeVerharding geïntroduceerd. Wanneer er een plan is voor een bepaald object is de afspraak dat er een instantie van GeplandeVerharding gemaakt wordt met dezelfde identificatie. Met behulp van de versie aanduiding op de bijbehorende Registratiegegevens kan onderscheid gemaakt worden tussen de instanties.

In deze uitwerking is het ook mogelijk om de het alternatieve plan mee te nemen in de data.

Voordelen (wordt bijgewerkt adhv discussie)

• Kan complexe situatie aan: meerdere plannen per object
• Statussen zijn natuurlijker gescheiden
• Objecttypes die niet te maken hebben met plannen hebben er geen last van
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Relatie tussen geplande verharding en verharding is geen expliciete relatie (afspraak via id)
• Een plan “schaduw-objecttype” per objecttype onderhevig aan planning is nodig (?: is dit een nadeel?)
• ?

[lvdbrink]

Dit is mijn favoriet voorlopig. Iets soortgelijks is al bij DSO en ruimtelijke plannen gedaan en NEN 3610 identificatie.versie is hiervoor bedoeld. We werken dan dus conform de standaarden en praktijk en vervullen de functionele behoeften.

[pmaria]

Alternatief b - Gepland object met relaties naar bestaand object

In deze uitwerking wordt er naast het objecttype Verharding een objecttype GeplandeVerharding geïntroduceerd. Wanneer er een plan is voor een bepaald object is de afspraak dat er een instantie van GeplandeVerharding gemaakt die gerelateerd wordt aan het bestaand object.

In deze uitwerking is het ook mogelijk om de het alternatieve plan mee te nemen in de data.

Voordelen (wordt bijgewerkt adhv discussie)

• Kan complexe situatie aan: meerdere plannen per object
• Statussen zijn natuurlijker gescheiden
• Objecttypes die niet te maken hebben met plannen hebben er geen last van
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Een plan “schaduw-objecttype” per objecttype onderhevig aan planning is nodig (?: is dit een nadeel?)
• Nodig om een identificatie te reserveren voor te realiseren object
• ?

[lvdbrink]

De vraag is bij deze uitwerkingen nog of je dan altijd een GeplandeVerharding introduceert, ook als er nog geen corresponderende bestaande Verharding is. Of doe je het zoals in EMSO staat, alleen een GeplandeVerharding als er al een bestaande Verharding is die significant verschilt (i.e. de geometrie verschilt).

De relatie tussen gepland en bestaande objecten zouden we gerealiseerdDoor kunnen noemen conform ISO2660.

Ik ben er zelf overigens voor om de relaties niet op te nemen (en dus voor 2a te kiezen). De relaties zijn afleidbaar.

[pmaria]

De vraag is bij deze uitwerkingen nog of je dan altijd een GeplandeVerharding introduceert, ook als er nog geen corresponderende bestaande Verharding is. Of doe je het zoals in EMSO staat, alleen een GeplandeVerharding als er al een bestaande Verharding is die significant verschilt (i.e. de geometrie verschilt).

IMO zou je niet met uitzonderingen moeten werken in een informatiemodel. Die uitzonderingen moeten je afnemers namelijk ook ondersteunen. Ik zou stellen dat je dus altijd een GeplandeVerharding zou moeten introduceren, wanneer is sprake is van een plan die levenscyclus-waardig is.

De relatie tussen gepland en bestaande objecten zouden we gerealiseerdDoor kunnen noemen conform ISO2660.

gerealiseerdDoor klinkt wel een beetje raar. Dekt dat inderdaad de lading? Ik ken de ISO2660 verder niet.

Ik ben er zelf overigens voor om de relaties niet op te nemen (en dus voor 2a te kiezen). De relaties zijn afleidbaar.

De relaties zijn in principe afleidbaar, echter heb je daar externe kennis voor nodig. Met expliciete relaties zit die kennis in je informatiemodel.

[RuudKathmann]

Deze uitwerking komt meer overeen met hetgeen gespecificeerd is in het conceptueel model voor de situatie dat sprake van een meer complexe verbouwing.
Indien er sprake is van een nieuw object, wordt gewoon dit object opgevoerd met de status ontwerp of bouw gepland.
In de tijd ontwikkelt dit object zicht tot het bestaande object en daarna weer tot de status "gesloopt".

Alleen in de situatie dat er sprake is van een complexere verbouwing zal er (tijdelijk) sprake zijn van een gerelateerd "parallel" object om de geplande nieuwe situatie weer te geven. Zodra de nieuwe situatie gereed is, wordt het planobject beëindigd en is de fysieke werkelijkheid te volgen via het hoofdobject. Alleen voor de tijdelijke plansituatie bestaat de verwijzing naar het planobject.

[lennartvanbergen]

Voordeel: de identificatie is hetzelfde. De requirement: hoe weten deze 2 objecten dat het over hetzelfde ding gaat, is eenvoudig te zien.

Voordeel: het is heel duidelijk wat gerealiseerd is (of zeker zo gaat worden in de nabije toekomst met een toekomstmutatie) en wat gepland is. Je kan er aparte kaartlagen van maken in een kaartviewer.

Voordeel: heel goed te implementeren in een registratie, er is geen relatie nodig van een plan object naar een gerealiseerd object en ook niet andersom. Maar het is wel afleidbaar, zodra gewenst in een product of API.

• Het plan object kan er dus dan ook eerder zijn dan het gerealiseerde object.
• Het gerealiseerd object zal nooit mutaties ondergaan als gevolg van een plan object.

Voordeel: er is geen uitzonderingssituatie als je 2 soorten objecten maakt - het is altijd op 1 manier (dus liever niet dat een plan object alleen wordt gemaakt bij uitzondering).

Nadeel: de objecttypes hebben een eigen naam. Dat voelt wat gekunsteld. Maar als we het ook echt als een apart object zien, die wat zegt over een ander object, dan is het juist goed dat het een andere naam heeft.

Nadeel: als een bronhouder per ongeluk het gerealiseerde object een andere identificatie geeft, dan is de relatie weg. Het vereist wel zorgvuldig werken. Dit is op te lossen als je he plan object een eigen identificatie geeft, en de identificatie van het te realiseren object reserveert, als eigenschap van het plan object.

[RiX012]

Ik zie ook een issue met 'business rules'. In theorie zou een Verharding met de status In aanbouw, gekoppeld kunnen worden aan GeplandeVerharding met status Sloop gepland. Dit zou dan softwarematig afgedwongen moet worden ofzo?

[RiX012]

Daarnaast is de semantiek van 'GeplandeVerharding' ook ingewikkeld voor mij. Ik vind lastig wat dit nu is? Is het nu een fysiek object of een toestand van een fysiek object. En als het een fysiek object is, dan is het dus iets 'conceptueels' want het representeert niet een fysiek object maar een plan voor een fysiek object. Niet persé een oplossing nog voor, maar vind het lastig uit te leggen.

[lennartvanbergen]

Deze is ook mijn favoriet. Vanwege dat de scheiding helder is, er 1 mechanisme is en niet soms het een, soms het ander, en het mij lijkt dat het gebruik ervan op deze manier fijn is.

Uitwerkpuntjes nog wel:

• wel of niet dezelfde identificatie? Ik neig naar niet.
  - Als niet, hoe weet je dan wat de identificatie van het gerealiseerde object is waar dit plan object bij hoort.
  - Hoe reserveer je een identificatie van het gerealiseerde object, is dat nodig/een requirement?
  Beide voorgaande: kan een attribuut zijn: (identificatie van) 'gerealiseerd object' : 123 ?

• Liever een postfix van een prefix, dus VerhardingGepland en GeplandeVerharding. Dat sorteert beter in documentatie en user interfaces.
  - Onderzoeken of deze discriminator in de naam niet in de naam hoeft, maar in een typering attribuut: planobject=ja/nee, of type object: plan. Zoals bedoeld in https://docs.geostandaarden.nl/disgeo/emso/#typering
  Wellicht weet inhoud hier een betere naam voor.

• Voldoet het ook om te modelleren:

  • een functioneel object _xyz met de attributen, exclusief de status (abstract). Aangevuld met:
  1. het gerealiseerde objecttype xyz en status: alleen gerealiseerde statussen, en
  2. het plan objecttype xyzGepland als een extensie van het functionele object, met als extra attribuut: planstatus (en eventueel: gereserveerde identificatie)

[lvdbrink]

Aanvullingen uit overleg van 15 april:

• Verduidelijking: als het geplande gerealiseerd is, sluit je het geplande object af en neem je de nieuwe gegevens over in het bestaande object.
• Paul: voordeel van 2b is dat je geen conventie over de id constructie af hoeft te spreken. Dit is een nadeel bij 2a.

Conclusie op 15 april: de consensus is om uitwerking 2 verder te gaan uitwerken. Daarbij 'simpele gevallen' meenemen, en brondocument meenemen in het model.