12. april 2006 - 18:26Der er
14 kommentarer og 1 løsning
UML - Association
Hej Eksperter.
Mit spørgsmål er kort og godt: Hvilken type association bruges mellem en alm. klasse, og en klasse der kun består af statiske metoder (der kan ikke skabes en instans af den)?
Det må enten være en Association eller en Dependency.
Min argumentation:
Jeg synes jeg kan argumentere for begge, da diverse beskrivelser af forskellen på de to typer er ekstremt ringe. Jeg har dog en beskrivelse fra bogen Applying UML and Patterns. Heri beskrives en Dependency som et kendskab til en klasse der ikke er baseret på en attribut-reference. Altså noget i retning af 'Class class = new Class()' må ikke forefindes. Men 'someFunction(new Classs())' må gerne findes. Dette synes jeg virker ganske logisk.
Men flg. to eksempler vil altså betyde forskellige reference typer:
Eks1: Class cls = new Class(); // Association - attribut-reference Eks1: someFunction(cls) ------------------------------------------------------------ Eks2: someFunction(new Class()); // Dependency - ingen attribut-ref.
Jeg finder det ret latterligt at man har to forskellige associeringer til nøjagtigt det samme. Det kan ikke passe at ovenstående to eksempler kan afgøre om det skal være Associering eller Dependency. Så jeg er så småt begyndt at hælde til, at man skal bruge Dependency hvis man ikke ARBEJDER på objektet, og dermed association hvis man arbejder (interagerer) med objektet.
Men hvad så med klasse-metoder? Her har man jo ikke en attribut-reference til en instans af klassen, eftersom du ikke kan skabe en instans. Men du bruger alligevel functioner på klassen. Skal jeg nu hælde til min ide om at associationstypen afhænger af om der arbejdes på objektet (eller klassen), eller om der er en attribut-reference?
Jeg er ret lost her. Jeg håber I kan hjælpe mig. Tak :)
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Jeg vil mene at en attribut på klassen i givet fald så en aggregering (enten Composite eller Shared). Associering bruges vist typisk for referencer i metoder med en ukendt levetid. Aggregeringer har kendt levetid, i og med at de "dør" sammen med klassen.
Du har ret - en aggregering (shared eller composite) er specielle tilfælde af en associering - nemlig at der er tale om associeringer på klasse-attribut niveau.
Jeg er dog ikke enig i dit sidste statement. Jeg er ret sikker på at man bruger associerings-notationen når der er tale om referencer med en begrænset/ukendt levetid i forhold til objektet der holder referencen.
associerings eksemplerne i "UML Destilled" bruger fields
"Applying UML and Patterns" 2nd ed side 293 siger:
"The usual interpretation of an association with a navigability arrow is attribute visibility from the source to target class. During implementation in an objectoriented programming language it is usually translated as the source class having an attribute that refers to an instance of the parget class."
Mja, du har naturligvis fat i noget mht. multiplicity/kardinalitet. Men man kan så passende spørge sig selv hvad formålat er med aggregerings-notationerne - for så er det ikke længere et spørgsmål om hvornår man skal bruge dependency frem for associering. Så er det et spørgsmål om hvornår man skal bruge en af aggregeringsformerne frem for associering.
jeg mener at det mest er en ren model ting som ikke har betydning for selve kode genereringen af attributten men kun for hvordan attributten kan anvendes
"UML Destilled 2nd Ed" side 85 snakker lidt om det:
"So the UML includes aggregation, but with hardly any semantics. As Jim Rumbaugh says, Think of it as a modeling placebo"
"With composition ...; further the parts are usually expected to live and die with the hwil. Usually, any deletion of the whole is considerde to cascade tothe parts."
Det er muligt du har ret i at det er afhængig af hvordan attributten kan anvendes - men dine uddrag fra UML Destilled nævner desværre ikke noget om dette - kun at Aggregeringer dør sammen med de objekter de er en "del af".
Så jeg står stadig tilbage med en undren, og er fortsat i tvivl om hvornår man skal bruge en "simple" associering frem for en aggregering. Eller er en aggregering blot en mere detaljeret associering der netop fortæller at associeringen KUN hører til ét andet objekt (Composite) eller at referencen kan være delt mellem flere objekter (Shared)? For så giver galskaben trodsalt mening.
Er UML Destiled i øvrigt en bog du kan anbefale som supplement til Applying UML and Patterns?
Jeg har snakket lidt med en anden ekspert på området. Hun mener at aggregerings-notationen er et værktøj til i højere grad at symbolisere, at en klasse er en del af en anden klasse i en domænemodel (!== klassediagram). Men jeg tror jeg har styr på hvordan jeg skal bruge det nu. Jeg har i øvrigt fået mulighed for at låne UML specifikationen, så der kan jeg passende dykke dybere ned i det ved lejlighed.
Tak for hjælpen og de gode råd - det er svartid :)
"jeg mener at det mest er en ren model ting som ikke har betydning for selve kode genereringen af attributten men kun for hvordan attributten kan anvendes"
og svar
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
