Problém identity instancí asociačních tříd Autor RNDr. Ilja Kraval Ve školeních a také následně po jejich ukončení se stále častěji objevují dotazy, které se týkají tzv. identity instancí asociační třídy. Jako příklad uvedu citaci z jednoho mailu: Dobrý den. Absolvoval jsem u Vás školení o objektovém modelování a bylo pro mě velmi poučné. Nedávno jsem narazil na jeden článek na internetu, který mi ale trochu naboural můj pohled na použití asociativní třídy. Příklad se týkal následující asociativní třídy:
Zaujal mě závěr diskuse, kde se mimo jiné hovoří:... - jediné co je podstatné je to, že v každém okamžiku běhu systému existuje maximálně jedna instance asociační třídy, jejíž identita je dána třídami v asociaci. Jinými slovy - třída Jízda v systému nemůže být modelována jako asociační třída, protože byste po čase měl n tříd se stejnou identitou - tuto vazbu je nutné rozpadnout na běžnou agregaci.... U asociační třídy je opravdu zakázáno mít instance, jejichž identita není jednoznačná. Příklad: Když řeknu, že každý řidič je na jedno použití a uskuteční jednu jízdu - pak je asociační třída v pořádku. Za běhu aplikace, při implementaci mohu toto pravidlo zjemnit tak, že řeknu, že vždy existuje jen jedna aktivní jízda (ostatní jsou neaktivní a nejsou součástí business vrtvy). Když řeknu, že v nějakém okamžiku může jeden řidič řídit jen jeden autobus, jsem nucen: 1) Nepoužít asociační třídu, ale zavést běžnou třídu Jízda, která agreguje jednu instanci řidiče a jednu instanci 2) Zavést omezení (Constraint), že při plánování/evidenci jízd nesmí dojít k časovému překryvu uskutečněných jízd různými autobusy ve stejné době u jednoho řidiče.... A dále: Je to na různých místech, ale snad postačí citace z UML reference guide: "An association class connecting classes A and B is not the same as a class D with binary associations to A and B. Like all links, a link of an association class such as C takes its identity from the object references in it. The attribute values are not involved in providing identity. Therefore, two links of C must not have the same pair (a,b) objects, even if their attribute values differ, because they would have the same identity. That is, given attribute E, it is not permitted that (a,b,e1) and (a,b,e2) both be instances of C, because they share the same identity (a,b)" Pokud platí výše uvedená citace, potom příklady, které uvádíte ve svých skriptech "Objektové modelování pomocí UML v praxi 2005" např. pro vztah Auto - Osoba prostřednictvím Asociativní třídy Vlastnictví (str. 155) mají stejný charakter jako výše uvedený příklad a neměly by být zapsány pomocí asociativní třídy. Problém ale je, že intuitivně je mi bližší vaše vysvětlení. Navíc se mi nepodařilo na internetu najít originál UML reference guide s touto definici. Specifikace UML 2.0 na www.uml.org také jednoznačně nedefinuje vlastnost Asociativní třídy, jak je uvedena ve výše uvedené citaci. strana 2
Můžete mi pomoci? Moje odpověď na tento mail byla následující: Přeji pěkný den, nevím, kde uvedený názor vzniká, ale myslím, že je chybný a myslím, že UML jej ve své specifikaci z uvedených stránek přímo vyvrací. Viz kapitola 7.3.3 Association: When one or more ends of the association have isunique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values. a logicky to může nastat jedině v tom případě, kdy link má svou vlastní strukturu (tehdy totiž links carry an additional identifier apart from their end values), tedy své atributy anebo další asociace, a tedy nutně pochází z asociační třídy. Uvedená věta vysloveně popírá nutnost "identity" linku ve smyslu věty: jediné co je podstatné je to, že v každém okamžiku běhu systému existuje maximálně jedna instance asociační třídy, jejíž identita je dána třídami (dodatečná poznámka Ilji Kravala: přesněji instancemi) v asociaci, Pravda je jiná: Na základě uvedené "černé" věty z UML může existovat několik různých linků (instancí asociace) mezi dvěma stejnými instancemi. V našem případě je totiž sama jízda jednoznačně identifikována vším, co obsahuje: instancí ze třídy Autobus, instancí ze třídy Osoba, cílem, datumem a časem odjezdu. Pro dvě stejné instance Autobus a Osoba tedy může existovat vícero linků (tj. instancí jízd) s různými svými dalšími hodnotami atributů a to měla na mysli věta napsaná černě. Co musí být unikátní, je jasné a není to jenom a pouze dvojkombinace instancí na koncích asociace. Další kapitola 7.3.4. AssociationClass, která definuje asociační třídu jako prvek, který má vlastnosti jak asociace, tak třídy, nemůže popřít předešlou černou větu a takové omezení se tedy nemůže vyskytnout. Důležitá je poznámka Note v této kapitole: Note It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e., from the instance point of view, the multiplicity of the associations ends are 1. To prozrazuje tu skutečnost, jak to vše funguje instančně: Každá instance asociační třídy si ukazuje (má na konci asociace přiřazenu) po jedné instanci z každé třídy, strana 3
které propojuje - a to je celý mechanismus asociační třídy: Přes tato propojení "se chodí" do jedněch k druhým. Konec mailu K této odpovědi mailem dodám ještě jeden názorný příklad, kde se právě vyskytuje otázka co je vlastně identita instance asociační třídy. Zaveďme vzor Povolené kombinace mezi prvky tříd A a B tak, že existuje multiinstanční třída A (z ní bude seznam instancí) a existuje multiinstanční třída B (z ní bude druhý seznam instancí). Zaveďme povolené kombinace mezi A a B tak, že se jedná o asociační třídu mezi A a B, nazvěme ji například Povolené A versus B. Takovýto vzor se v podnikových systémech vyskytuje velmi často. K tomu zaveďme ještě dva atributy typu datum ve třídě povolených kombinací a nazvěme je od a do (doba platnosti). Je zřejmé, že nyní netvoří analytickou identitu pouze dvojice konců asociace, ale navíc i tyto dva atributy. (poznámka: navíc musí být zaveden constraint ohledně možných překryvů datumů ). V každém případě nemá smysl zavádět dva prvky se stejnou dvojkombnací konců aosicační třídy a dvojící datumů, takový prvek už tam je. Například velmi dobře to vystihuje tato situace: Někdo se splete a zapomene, že tam tento konkrétní prvek již jednou zadal a pokusí se jej zadat znovu. Všimněme si detailně slovního spojení tento konkrétní prvek, tím jsme velmi nápadně dali najevo, že každý prvek je přesně takto identifikován, tj. je identifikován tímto: Kdo z A a ke komu z B a odkdy a dokdy. Jinak řečeno, do hry na identitu může vstoupit libovolný další prvek vnitřní struktury v instanci asociační třídy, pokud jej má. Pokud instance asociační třídy nemá takovou další vnitřní strukturu (obsahuje pouze konce asociace), potom povinně musí být tyto konce v kombinaci unikátní a nemůže nastat situace, že by existovaly dva linky propojující stejnou množinu instancí na koncích asociace. Znamená to jednoduše to, že pokud vypustíme v našem příkladu atributy od - do, tak potom nemá smysl (a je to zakázáno) zavádět dva linky pro dvě stejné dvojkombinace instancí z A a B, protože taková dvojkombinace instancí z A a z B už tam jednou je a nedaly by se od sebe rozlišit. Tedy jinak řečeno, pokud si instance očíslujeme, tak nemá smysl něco takového (pokud jsme zrušili další vnitřní strukturu, jako byla např. od - do): Povolené kombinace bez od - do (pozor : chybná konstrukce!): (1,1) (1,2) (2,1) (1,1) prvek (1,1) už tam jednou je! Jakmile zavedeme datumy od do, situace se změní, ale princip nikoliv. Kombinace (1,1) se může opakovat, identitu nyní tvoří dvojkombinace instancí z A a z B plus nějaká další vnitřní struktura, například od do (anglicky řečeno, v tomto případě nastává ono zmiňované: in such a case, links carry an additional identifier apart from their end values Myslím, že tím je jasné, co se skutečně myslí onou identitou strana 4
instance asociační třídy a co ji vlastně tvoří. V žádném případě to není povinně pouze kombinace konců asociace --- * * * --- strana 5