Kontroller relasjoner i UML-diagrammene (Komposisjon vs. Aggregering)

[petterreinholdtsen]

---

       Prosjekt  NOARK 5 Tjenestegresesnitt
       Kategori  Noark 5.5.0 TG versjon 1.0
    Alvorlighet  kommentar
   Meldingstype  trenger klargjøring
Brukerreferanse  [email protected]
    Dokumentdel  alle
     Sidenummer  mange
    Linjenummer  n/a

---

Beskrivelse

Jeg lurer på om noen av relasjonene i UML-diagrammene som er utledet fra teksten i kapittel 7 går feil vei. Spesifikt lurer jeg på om fylte diamantrelasjoner (kalt Aggregation i relasjonstabellene) går feil vei. Et spesifikt eksempel som gjør at jeg stiller spørsmålet er diagrammet til Merknad.

Et relatert spørsmål er hvorvidt Aggregation er riktig navn på denne relasjonen. Jeg er ingen UML-ekspert, men ser endel beskrivelser kalle samme relasjon for Composition / Komposisjon. Noen med mer UML-peiling enn meg bør se på disse autogenererte diagrammene, samt de som er laget manuelt.

Ønsket endring

Hvis UML-diagrammene har feil relasjon, så må de korrigeres.

[petterreinholdtsen]

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/ har nyttig UML-informasjon.

[hanber]

For ordens skyld: Fylte diamanter angir komposisjoner, ikke fylte diamanter angir aggregeringer. Den artikkelen du viser til forklarer dette veldig godt. I modellene i Noark 5 er det bare benyttet aggregering, det er feil. For å bruke merknad som eksempel, er spørsmålet om samme merknad skal kunne knyttes til forskjellige arkivenheter. Jeg tror ikke det er meningen, slik at merknad like gjerne kunne vært et attributt av typen Merknad (0..*). I så fall skulle relasjonen mellom arkivenhet og merknad vært en komposisjon. En frittstående merknad gir ingen mening i seg selv, bare når den er knyttet til et objekt, hvilket også er en indikasjon på at det bør være en aggregering. Dette gjelder mange av relasjonene i modellene.
Jeg har ikke tatt hensyn til navigasjonsretning, men i tilfellet merknad, er det tvilsomt om det er noen nytte i å kunne navigere fra en merknad til arkivenheten den er en merknad til (med mindre samme merknad kan knyttes til flere arkivenheter).
Vi har diskutert dette før i forbindelse med hvilke objekter som skal ha en systemID, og det synes unødvendig at objekter som inngår i en komposisjon trenger systemID.

Jeg ser forresten at i modellene er det bare en navigeringspil, og ikke en klasse/subklasse-pil fra subklassene til superklassene (f.eks. fra saksmappe til mappe).

[petterreinholdtsen]

Jeg endret nettopp text2uml og snudde Association (kilde/mål -> kilde/mål) til å ha fylt diamant i motsatt ende av streken, og nå ser det litt mer korrekt ut. Lurer fortsatt på om det kan være lurt å endre navn på relasjonen i teksten til Composition eller Komposisjon, og er heller ikke trygg på at alle UML-diagrammer er korrekte, så anser ikke at endringen løser denne mangelmeldingen.

…

-- Vennlig hilsen Petter Reinholdtsen