[UML/OO] Multiple Compositie

[riezebosch]

Kan LogActie van Actie en van LogScript afhankelijk zijn? Het lijkt me correct UML, maar ik weet dus niet zeker of je composities naar meerdere objecten mag maken.

Het idee is: Ik kan meerdere logs aanmaken bij een TestScript, en dus ook meerdere LogActies bij een Actie. Maar wanneer een Actie verwijderd wordt, moeten de LogActies die daarbij horen ook verwijderd worden. En als een LogScript verwijderd wordt, moeten óók alle daarbij behorende LogActies verwijderd worden...

Ik weet dus niet of dit correct UML is, omdat normaliter je bij een compisitie een (lijst van) instantie(s) van het ene object in het andere opneemt. En dat gaat in dit geval dus niet, aangezien LogActie dan in Actie én in LogScript opgenomen zou moeten worden. In een database kan ik dit wel plaatsen, want dan neem je gewoon het id van Actie en van LogScript op in LogActie. En waneer je een van beiden verwijderd, doe je ook een query op LogActie en verwijder diegene met het id van de verwijderde Actie of LogScript.

In OO kan je dit natuurlijk ook wel handmatig bereiken, door in allebei een reference op te nemen en dan handmatig de goede LogActies te verwijderen, maar het is juist zo mooi als dit automatisch door de destructor wordt gedaan.

Mijn vraag dus: is dit correct UML, of hoor je dit anders te modelleren?

[curry684]

Je kunt dit gewoon met de destructor doen als je reference counting implementeert... kijk eens naar smart pointers

Wat de UML betreft lijkt het me gewoon correct, als die dependency er is moet je 'm zo tekenen.

[riezebosch]

Dank u

edit:

Toch is het dan een stuk lastiger te implementeren dan met enkele compositie

[ Voor 85% gewijzigd door riezebosch op 19-10-2004 11:07 ]

[JaWi]

Strikt gezien is het niet toegestaan dat een 'part' (LogActie) tot twee 'composites' (Actie en LogScript) behoort. Als je de composite-relatie vervangt door een gewone aggregatie relatie (zo'n open diamantje), dan is het wel conform de UML-specificatie.

[riezebosch]

Maar drukt het dan nog steeds uit dat LogActie zowel afhankelijk is van Actie als van LogScript? Want wat ik wil uitbeelden is dus dat wanneer een Actie verwijderd wordt, ook alle daaraan gekoppelde LogActies. Maar dat wanneer een LogScript verwijderd wordt, ook alle dááraan gekoppelde LogActies verwijderd worden.

Want wat is dan precies het verschil tussen een compositie en een aggegratie? Beide zijn een deel/geheel of een "bevat een"-relaties... Toch?

[koli-man]

Bij een compositie kan het één niet bestaan zonder het ander en bij een aggregaat kan dat wel.
Een stuur kan niet bestaan zonder een fiets, maar een raam kan wel bestaan aaarrgrgrhhhh.....

[ Voor 73% gewijzigd door koli-man op 19-10-2004 12:10 . Reden: Ik ben zelf even helemaal in de war gebracht.....ik geef het op :) ]

[riezebosch]

Dat is dus wat ik wil, maar dan afhankelijk van twee andere dingen...

De vergelijking lijkt me nogal hetzelfde. Een fiets kan best bestaan zonder stuur, maar het stuurt vrij lastig. Meestal benoem je dat ook andersom: het stuur is onderdeel van de fiets, en het raam onderdeel van het huis. Verwar je nu niet aggregatie met associatie?

[ Voor 82% gewijzigd door riezebosch op 19-10-2004 12:08 ]

[JaWi]

riezebosch schreef op 19 oktober 2004 @ 12:04:
Dat is dus wat ik wil, maar dan afhankelijk van twee andere dingen...

De vergelijking lijkt me nogal hetzelfde. Een fiets kan best bestaan zonder stuur, maar het stuurt vrij lastig. Meestal benoem je dat ook andersom: het stuur is onderdeel van de fiets, en het raam onderdeel van het huis. Verwar je nu niet aggregatie met associatie?

Bij een compositie-relatie het volgende kunt denken: een fiets bestaat uit een tweetal wielen, een frame, een zadel, trappers, stuur, etc.. Twee wielen op zichzelf maken geen fiets, de combonatie (composition) van al die losse delen maakt het geheel tot een fiets.

Bij aggregatie kun je het volgende denken: een persoon heeft nul, een of meerdere fietsen. Zonder dat een persoon een fiets heeft, bestaat er wel zoiets als een fiets. Beide concepten kunnen dus ook los van elkaar bestaan. Daarnaast kan een fiets door meerdere personen gebruikt worden (dit terwijl een wiel -strikt genomen- nooit door twee fietsen gebruikt wordt).

[riezebosch]

Dat is omdat wielen concrete dingen zijn. Maar bij informatica is alles abstract, dus waarom zou een onderdeel niet tot twee dingen kunnen behoren, en van hun life-cycle afhankelijk zijn (concreet zoals curry684 opmerkt: door bijvoorbeeld smart-pointers)?

En zoals ik hier lees is bij aggregatie de life-cycle wel afhankelijk van het beherende object, alleen kan het object wel bestaan zonder beherend object. Maar dat is dus niet wat ik wil: LogActies mag niet bestaan zónder Actie of zónder LogScript. Compositie lijkt me dus wel degelijk op z'n plaats...

[JaWi]

riezebosch schreef op 19 oktober 2004 @ 13:04:
Dat is omdat wielen concrete dingen zijn. Maar bij informatica is alles abstract, dus waarom zou een onderdeel niet tot twee dingen kunnen behoren, en van hun life-cycle afhankelijk zijn (concreet zoals curry684 opmerkt: door bijvoorbeeld smart-pointers)?

En zoals ik hier lees is bij aggregatie de life-cycle wel afhankelijk van het beherende object, alleen kan het object wel bestaan zonder beherend object. Maar dat is dus niet wat ik wil: LogActies mag niet bestaan zónder Actie of zónder LogScript. Compositie lijkt me dus wel degelijk op z'n plaats...

Dat bij een aggregratie-relatie het "part-"object los kan bestaan van z'n beherende object is zwakke constraint, het hoeft niet zo te zijn. (Subtiel verschil met een compositie-relatie, waar het "part-"object niet los mag bestaan, maar waarbij het "part-"object ook slecht bij 1 beherend object mag hebben volgens de UML specificatie).

Als ik nu nog eens naar je ontwerp kijk, dan zou je het ook anders kunnen oplossen:

Je TestScript-class heeft een compositie-relatie met een aantal Akties. Een TestScript kan nul, een of meerdere LogScripts hebben. Nu is er een relatie tussen een Aktie en LogScripts, nl. dat acties gelogd worden. Dit is een eenrichtingsrelatie aangezien een Aktie gelogged worden door een LogScript en niet andersom. Tevens
heeft deze relatie een associatie-class, die aangeeft of de log-aktie gelukt is of niet.

(ik hoop dat m'n uitleg duidelijk is, heb helaas hier geen UML-tool voorhanden )

[riezebosch]

Ik heb het ook met Word gemaakt

De relatie tussen Actie en LogScripts loopt nu juist via LogActie, omdat ik op die manier per Actie kan loggen of die gelukt is of niet. LogScripts zit erbij omdat je dan ook op TestScript-niveau gegevens bij kan houden over het uitgevoerde script. De relatie tussen Actie en LogActie is ook eenzijdig. Ik denk zelf dat dit wel goed UML is, en zou ook niet weten waarom een aggregtie wel van meerdere objecten mag en een compositie niet... Het is verder ook niet belangrijk, omdat ik al een goede vertaling naar een database-ontwerp heb gemaakt. Maar ik vroeg me gewoon af of dit conform de UML-specificatie is.

Het afgebeelde stukje is overigens slechts een gedeelte van mijn complete UML.