\


 Sunday, 26 March 2006
UML - O agregaci, kompozici a asociaci a jako bonus společenská aktualitka :)

Na svých přednáškách při vysvětlování asociace a kompozice mám slide, na kterém jsou zmíněny základní rozdíly mezi oběma typy vztahů v UML. Ihned k tomu ale dodávám, že zmíněné rozdíly jsou akademické a že v praxi si vystačíme většinou s jedním typem vztahu (s agregací), u kterého při kódování intuitivně víme, zda složený (kompozitní) objekt rozhoduje, a pokud ano, tak v jaké míře, o životním cyklu svých konstituentů (objektů, z nichž je složen).

 

Kompozice
  • Kompozitní objekt nemůže existovat bez komponentních složek.
  • Každý komponentní objekt může být součástí jen jedné kompozice
  • Kompozice je většinou heterometrická
Agregace
  • Agregace může existovat bez svých konstitučních objektů
  • Jeden objekt může být potenciálně konstituentem více konstitučních objektů
  • Agregace inklinují k homeometrii

Informace o rozdílu mezi agregací a kompozicí vycházejí z UML specifikace, kde se říká:

"[Agregace je] speciální forma asociace, která specifikuje vztah mezi agregujícím(celkem) a jeho konstituentem (částí)."

"Kompozitní agregace je silnější forma agregace, která vyžaduje, že jakákoli instance konstituenta (části) bude součástí nejvýše jednoho kompozitního objektu. Jestliže je kompozitní objekt smazán, jsou většinou všechny jeho části vymazány s ním".

Čte někdo vůbec UML specifikaci namísto čtení takzvaně přístupných  a "lidsky psaných" knih, které dogmaticky vyžadují rozlišování mezi kompozici a agregací? Jak si můžete všimnout, v definicích agregace i kompozice je zřetelně vidět pozvolný přechod mezi asociací, agregací a kompozicí a ne žádné ostré hranice, jak se nám mnohdy snaží vsugerovat sekundární literatura k UML nebo žabomyší akademické války o přesný význam termínů. Převedu-li definice a jejich důsledky do normální řeči - agregace ani kompozice není z hlediska UML nic jiného než asociace. Protože se ale asociace s rysy kompozice a agregace vyskytují často,  zavedeme pro ně speciální jazykový konstrukty. Tyto jazykové konstrukty jsou implicitními nositeli omezení, jež jsou na agregaci a kompozici kladeny. Spory o to, co je v diagramu ještě agregace a co už musí být kompozice jsou směšné a nikam nevedoucí  - je to jen zvlášní druh moderního pseudovědeckého sektářství, kde se na hranici místo kacířů zástupně smaží nedogmatický duch UML.

Dále moje rozlišení agregace a kompozice vycházejí z praxe, kde indukcí dojdete k tomu, že kompozice bývá heterometrická  - konstituenti jsou objekty z různých tříd. Typicky například u faktury rozlišujete mezi řádky faktury, záhlavím faktury a zápatím faktury - faktura je tedy složena minimálně z objektů tří různých tříd. Když faktura nemá záhlaví, zápatí nebo alespoň jeden řádek, nemůže jít o fakturu. 

U agregace si častěji všimneme toho, že agregované objekty mohou být sdílené a že nezanikají se zánikem celku. Typicky o agregaci hovoříme třeba, když budeme modelovat kalendář pro obchodní zástupce a v kalendáři budou zadávány  jejich schůzky. Kalendář jako takový (seznam dní) může existovat i bez jakékoli evidované události. Některé události v kalendáři jsou privátní - typicky pravidelná návštěva přiděleného zákazníka. Jiné události jsou sdílené - společná schůzka všech obchodních zástupců je (přesněji řečeno - v tomto případě může být výhodně modelována jako) sdílená událost ve více kalendářích. I ty takzvaně privátní schůzky mohou "putovat" po kalendářích různých obchodních zástupců, když se dohodnou, že jeden po dobu dovolené zastoupí druhého a že převezme i jeho schůzky.

Důležité je si uvědomit, že v jazycích jako je C# nebo Java je rozdíl mezi kompozicí a agregaci opravdu zanedbatelný. Důvod je jednoduchý - nemáme v nich operátor delete([]) a odpovědnost za likvidaci objektů za nás převzal Garbage Collector. V C# a Javě si musíme pouze hlídat řízení životního cyklu objektů ukládaných do databáze - pokud něco (exkluzivně i sdíleně) vlastním (kompozice i agregace) , měl bych si uvědomit, že:

  1. Při zániku vazby musí dojít k odstranění objektu z databáze. Tedy odebere-li někdo řádek faktury z kolekce, je objekt faktura odpovědný za smazání vazby.
  2. Jestliže nemažu vazby fyzicky v databázi, ale pouze u objektů ze zrušených vazeb nastavuji stav 'neaktivní', musí moje business vrstva centrálně podporovat princip "co je neaktivní, je tabu a nikdo s tím nesmí pracovat  - a jak to v SW bývá, vždy máme výjimky. Jedinou výjimkou z tohoto pravidla jsou objekty, u nichž eviduji historii."

Poslední poznámka z praxe:

Na jedné přednášce (myslím před rokem na DNG) jsem se setkal s názorem, že typickým zástupcem agregace je "typování" objektů. Pod typováním objektu se můžeme představit objekt Uchazeč o práci, který má na sobě navázáno 0..n dalších objektů z třídy (z hlediska databáze z číselníku) Schopnost (řidičák, anglický jazyk, německý jazyk, práce s Excelem, lámání ženských srdcí atd.). Schopnost je zde termín, pod který jsou subsumovány všechny sledované typy evidovaných znalostí a dovedností. "Typování" není nic jiného, než klasifikace objektů dle různých kritérií, což nám umožňuje objekty rychle seskupovat do (z hlediska projektu) zajímavých množin - například budu-li obsazovat pozici lamačem srdcí se znalostí německého jazyka, snadno zjistím množinu uchazečů splňujících zadaná omezení.

Každý uchazeč může tedy "agregovat" o..n znalostí. Ale jde opravdu o agregaci? Já myslím, že je to prostá asociace - uchazeč nemá žádnou zvláštní vazbu na znalosti, ty jsou k němu jen "volně přidruženy".

A za jakých podmínek by bylo vhodné překvalifikovat vazbu mezi Uchazečem a Schopností opravdu na agregaci ? V momentě, kdy budete chtít evidovat nějakou dodatečnou a unikátní informaci k vazbě mezi uchazečem a jeho schopnostmi. Když tedy budeme chtít zjistit, od kdy uchazeč vlastní řidičský průkaz, nebo kolik dobytí ženských srdcí posloužilo jako předmostí k dobytí klínů;-) , zavedeme novou třídu DetailSchopnostíUchazeče - tato třída bude v asociaci s původní třídou Schopnost a bude agregována třídou Uchazeč (anebo dokonce v tomto případě bude jejím komponentním objektem) :-) .

Proč? Informace, které nesou objekty z třídy DetailSchopnostíUchazeče nemají význam "an sich", ale jen ve spojení s uchazečem. Jsou nedílnou částí právě jednoho obrazu, který nám dává objekt Uchazeč. Třída Schopnost nedílnou součástí obrazu právě jednoho Uchazeče nebyla - nenesla žádné specifické informace o uchazeči, jen s ním byla svázána náhodným poutem - asociací.

Na konec aktualitka na asociaci a kompozici ze života. :)

Asociace je pouhé registrované partnerství, ve kterém jsou dva konstituenti nahodilými objekty, kteří mají vůči sobě jeden kontingentní a zparchantělým parlamentem posvěcený link. Oba nijak závazně neřídí životní cyklus toho druhého.

Uzavřením manželství vzniká sakrální kompozitní objekt, jehož nedílnými součástmi jsou oba manželé s vzájemně protknutými životními cykly. A jak víme, při zániku kompozitního objektu, dříve či později nevratně odumírají i komponentní objekty.

I když nemusíme rozlišovat mezi asociací, agregací a kompozicí v UML, v životě může být dobře patrný rozdíl mezi asociací a kompozicí diferencujícím znakem mezi frivolní hrou a závazným svazkem. A pak že nelze do odborného blogu jednoduše a nenásilně propašovat názor na politická nebo společenská témata:-)



Sunday, 26 March 2006 15:50:53 (Central Europe Standard Time, UTC+01:00)       
Comments [5]  UML


Sunday, 26 March 2006 21:26:13 (Central Europe Standard Time, UTC+01:00)
Pragmatického pohledu na otázku agregace a kompozice není nikdy dost. Díky (i za příklad ze života :)
Monday, 27 March 2006 01:33:17 (Central Europe Standard Time, UTC+01:00)
Čau René, metafor a paralel není asi nikdy dost :) Asociace - souhlasím, často se na ženách volají metody, aniž se předpokládá následná agregace, či dokonce kompozice. Jenže, a to je už v povaze slečen, jejich deklarativní referenční integrita zakazuje vazbu, jež by se nepodílela na životnosti obou objektů. Tento model není přesný, co pak má vytoužená neexistuje i sama, nezávisle na mě? V mém srdci má ale zatím null. (Možná je to dnešní obvyklou kardinalitou vazeb danou až přiliž imperativními business pravidly ;)
Manželství, někdy je to high cohesion vazba trvalá a jedinečná (jedinečná v omezeném časovém intervalu životního cyklu objektu, ano, je to vážná věc, jenž se děje pouze několikrát za život;), a někdy je to jen loosely coupled asociace, nedej bože s chatty interface :-)
Add tvoje teze, že registrované partnerství je pouhá asociace, neškodilo by ubrat ze striktní typovosti a zkusit poopravit svůj analytický pohled. Ať už se jedná o asociaci, agregaci nebo kompozici, není podstatný typ komunikujících objektů (muž, žena, malé chlupaté stvoření z alfy centauri) ale povaha a síla vazby. A ta se projeví až po delším čase. Agregace nebo kompozice, obojí je lepší než dědičnost. Tam je odpovědnosti za child objekty nesrovnatelná :-)












Monday, 27 March 2006 09:39:56 (Central Europe Standard Time, UTC+01:00)
Pěkný a užitečný článek (díky za něj), ale dovolím si nesouhlasit s příkladem ze života. Manželství nemůže být kompozicí, protože manželství jako objekt neřídí životní cyklus podřízených objektů - lidí. Tyto objekty existovaly dávno předtím, než manželství vzniklo a také zánikem manželství lidské objekty nezaniknou. Navíc je to dokonce naopak - zánikem kteréhokoliv lidského objektu v manželství zaniká automaticky i objekt manželství. A v době rozvodů manželství není ani asociační třída na vazbě mezi dvěma osobami, protože lze (postupně, ne najednou) vytvořit několik různých instancí manželství se stejnými instancemi lidí. Že by tedy manželství byla jen prostá asociace - podobná, jako když se dva lidé náhodně posadí k jednomu stolu v hospodě?
pavel
Friday, 01 September 2006 16:05:02 (Central Europe Standard Time, UTC+01:00)
Názory vzešlé z mesaliance humanitní skepse a technologického optimismu

fuj to je hnusna veta...plna prazdnoty...

sorry
Friday, 01 September 2006 16:08:11 (Central Europe Standard Time, UTC+01:00)
Prazdnota muze byt docela prijemny stav, nemyslite :)

Navic ten podtitulek ani vetu netvori :)
Comments are closed.