3
Obrázek 3.3.8 Závislost a realizace
ačních“ pseudoobjektů (viz níže), které fakticky vyjadřují vztahy mezi objekty, a tak jsou na nich přirozeně závislé, nebo jako přirozený důsledek vztahu kompozice (fatální závislost na celku). • Realizace je vztah třídy a tzv. rozhraní, souhrnu všech „veřejně přístupných“ metod dané třídy. Používá se u objektů, jež představují programové komponenty počítačové aplikace, pro potřebu využití jejich operací jinými komponentami; využití by se jinak muselo specifikovat zavedením vztahu dědičnosti mezi třídami. V konceptuální modelu je tento „vztah“ irelevantní proto, že buď je odrazem skutečné (konceptuální) generalizace a ta by pak měla být v modelu vidět, a to jako generalizace, nebo odráží specifickou potřebu designu aplikace, jež se obsahu business modelu netýká. Konceptuální modelování vyžaduje v jazyku UML dále použití speciálních konstrukcí k modelování faktů, pro něž jazyk UML nemá vlastní prostředky: Asociační objekt (viz obrázek 3.3.9) Je pseudoobjekt, jenž ve skutečnosti není objektem, ale představuje vztah mezi objekty. Jako vztah je plně „identifikačně“ závislý na objektech, mezi nimiž je vztahem (jeho existence bez oněch objektů nemá smysl). Tím mu schází základní definiční vlastnost objektu – vlastní identita, a proto by také neměl být považován za skutečný objekt. Obrázek 3.3.9 ukazuje příklad asociační třídy Půjčka. Identita půjčky je dána identitou Člověka v roli dlužníka a Banky v roli věřitele. Jakmile schází jeden z těchto objektů, ani Půjčka nemůže existovat, je na nich svou existencí plně závislá. Takový pojem tedy nelze považovat za samostatnou (nezávislou) třídu objektů, ale jen za to, čím vpravdě je: za vztah objektů, a to navzdory tomu, že může mít vlastní atributy i operace a dokonce i asociace k jiným třídám (jako je zde například vztah k Člověku v roli ručitele)64. Asociační třída je v notaci modelu tříd spojena s asociací, již představuje, přerušovanou čarou.
64
98
V tomto příkladu by nyní měla přijít na přetřes otázka, zda si může člověk sám ručit na vlastní půjčku či je zde nutné další pravidlo, že se musí jednat o různé osoby, což by se v modelu dalo ošetřit různými způsoby, nicméně to již je jiná píseň, nesouvisející s účelem tohoto příkladu, jenž zde chce především ukázat, co je asociační objekt.
Procesně řízená organizace Ukázka elektronické knihy, UID: KOS182842
3
Obrázek 3.3.9 Asociační třída
Obrázek 3.3.10 ukazuje příklad reálného konceptuálního modelu (z oblasti provozu poskytovatele lékařských služeb). Na tomto modelu je dobře vidět několik typických rysů konceptuálního modelování v prostředí jazyka UML: • V modelu není nikde použit konstrukt agregace. Přitom v některých částech modelu lze pozorovat čistě hierarchické vztahy mezi třídami objektů, jež obsahově agregaci odpovídají. Například Klienta bychom mohli považovat za kontejner Lékařských zpráv, nebo Zahraničního obchodníka a současně i Dodavatele služeb za zásobárnu Přijatých faktur. Je ale zřejmé, že takové pojetí je v lepším případě zbytečné, v horším dokonce matoucí (například výše zmíněné dvě, současně existující zásobárny téže věci si lze jen těžko reálně představit, zde analogie kulhá jak John Silver). Každopádně, použití agregace v konceptuálním modelu nepředstavuje nic jiného než vztah 1:*, na vyjádření čehož vždy bohatě postačí prostá asociace. • V modelu je často použit konstrukt generalizace. Generalizace, a potažmo specializace, je přirozenou hierarchií pojmů a v konceptuálním modelu je tedy zcela namístě.65 Potřeba generalizace se v konceptuálním modelu zpravidla pozná z potřeby rozlišit u objektů různé vlastnosti, operace či vztahy k jiným objektům, a současně přiznat jejich společné (vlastnosti, operace, či vztahy k jiným objektům). Dobrým příkladem je zde Dodavatel služeb, jako generická třída, pod níž se skrývají čtyři různé druhy dodavatelů. Každý druh dodavatele je něčím specifický, což vyžaduje u každého vnímat specifické vlastnosti (atributy), ale i operace a patrně i průběh života (životní cyklus). Přitom ale všichni mají mnoho atributů, ale i operací (a patrně i celé úseky života) společné. Ty jsou uvedeny přímo u generické třídy. Kromě výše zmíněných rozdílů ve vlastnostech a chování, též jednotlivé druhy dodavatelů vstupují typicky jiným způsobem do vztahů s ostatními objekty. Dodavatelé typu Ubytovací kapacita, Dopravce a Poskytovatel doplňkové služby mají typové asociace k Zakázce, zatímco Poskytovatel operačního prostoru není sjednáván na celou zakázku, ale zvlášť na jednotlivé operace. Kromě toho i asociace různých typů dodavatelů ke společné třídě Zakázka mají typově různou kardinalitu a parcialitu: doplňkové služby, ani doprava sjednány být vůbec nemusí, na rozdíl od ubytování, které je sjednáváno vždy. 65
K tomu viz téma hierarchických abstrakcí, bohatě komentované v kapitole „Informační modelování organizací“.
Informační modelování organizací
99 Ukázka elektronické knihy, UID: KOS182842
Obrázek 3.3.10 Příklad konceptuálního modelu tříd
3
100
Procesně řízená organizace Ukázka elektronické knihy, UID: KOS182842