4. diel - UML - Doménový model

V predchádzajúcom cvičení, Riešené úlohy k 3. lekcii UML, sme si precvičili získané skúsenosti z predchádzajúcich lekcií.

Dostávame sa k tzv. doménovému modelu. Doménový model sa vytvára spolu s Use Case diagramom v počiatočnej fáze vývoja softvéru. Jedná sa o formu Class diagramu, teda diagramu tried. Asi nemusím spomínať, že systém bude programovaný objektovo a preto bude aj tak navrhovaný. Základnou entitou je trieda.

Triedy v doménovom modeli sú však značne zjednodušené, neobsahujú metódy a majú iba dôležité atribúty. Názvy tried, atribútov a ďalšie identifikátory môžeme písať s diakritikou. Doménový model je teda akýsi náčrt základných entít systému a vzťahov medzi nimi. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk) a atribúty nemajú dátové typy.

Pri tvorbe doménového modelu vychádzame zo zadania klienta. Z neho identifikujeme kľúčové entity a vzťahy medzi nimi. Tieto entity zakreslíme do modelu ako triedy.

Grafická notácia triedy je obdĺžnik rozdelený vodorovne na 3 časti:

V prvej je zapísané meno triedy, v druhej sú jej atribúty a v tretej časti nájdeme metódy. Pre doménový model budeme uvádzať iba zjednodušenú notáciu s názvom triedy a atribúty. Kompletnú triedu si predstavíme nabudúce, pri Class diagrame.

Triedy sú medzi sebou prepojené pomocou vzťahov.

Vzťahy

UML ponúka niekoľko druhov vzťahov, tie základné si vymenujeme.

Asociácia (Association)

Asociácia určuje základný vzťah medzi dvoma entitami. Tie môžu existovať nezávisle na sebe. Zakresľujeme ju ako jednoduchú plnú čiaru.

Príklad jednoduchej asociácie medzi 2 entitami môže byť Car a Driver. Vzťah by sa znázornil takto:

Ako východiskový je smer na obe strany, teda že prvá entita má odkaz na druhú, a naopak druhá na prvú. Toto správanie môžeme zmeniť pridaním jednoduchej šípky, ktorá smer špecifikuje a spôsobí, že odkaz si uchováva iba tá inštancia, z ktorej smeruje šípka.

Je možné vytvoriť asociáciu aj medzi 3 triedami, ale tým sa nebudeme zaoberať.

Agregácia (Aggregation)

Agregácia reprezentuje vzťah typu celok - časť. Zakresľujeme ju ako plnú čiaru, zakončenú na jednej strane prázdnym kosoštvorcom. Ten je umiestnený pri tej entite, ktorá reprezentuje celok (napr. sekcia s článkami). Z hľadiska implementácie je to taká entita, ktorá drží kolekciu prvkov. Entita reprezentujúca časť môže existovať sama o sebe a byť súčasťou aj iných kolekcií.

Príkladom agregácie môže byť už spomínaná sekcia, obsahujúca články. Čísla na konci väzby znamenajú tzv. multiplicitu, presnejšie, že sekcia obsahuje ľubovoľný počet článkov a článek patrí aspoň do 1 sekcie:

Multiplicite sa ešte budeme ďalej venovať.

Kompozícia (Composition)

Kompozícia je podobná agregácii, avšak reprezentuje silnejší vzťah. Entita časti nemá bez celku zmysel. Pokiaľ zanikne celok, zanikajú automaticky aj jeho časti.

Kompozíciu zakresľujeme rovnako ako agregáciu, kosoštvorec je však plný. U entity reprezentujúcej celok musí byť multiplicita vždy 1. Táto väzba býva mätúca a odporučil by som sa jej skôr vyhýbať a nahradiť ju agregáciou.

Príkladom môže byť Order a OrderItem. Zatiaľ čo článok z minulého príkladu dáva bez sekcie ešte nejaký zmysel, položka objednávky bez objednávky zmysel nedáva. Preto je tu použitá kompozícia:

Generalizácia (Generalization)

Posledným vzťahom, ktorý si tu uvedieme, je generalizácia. Z hľadiska implementácie sa jedná o dedičnosť. Jedna entita dedí vlastnosti a správanie iné. S touto väzbou sme sa už stretli pri Use Case diagrame.

Generalizáciu zakresľujeme ako plnú čiaru, zakončenú na jednej strane prázdnou uzavretou šípkou (alebo ak chcete trojuholníkom). Šípka je na strane entity, z ktorej sa dedí.

Príkladom môže byť trieda Shape, z ktorej dedia triedy Square a Circle:

Multiplicita

Vráťme sa ešte k multiplicite (čiže násobnosti). Multiplicitu môžeme uviesť pri väzbách asociácie, agregácie a kompozície (tu iba z jednej strany).

Vráťme sa k príkladu sekcia - článok.

Multiplicitu tu čítame takto: Sekcie môže mať ľubovoľný počet článkov (to spoznáme podľa hviezdičky v triede Article). Článek patrí do 1 až ľubovoľne sekcií (to spoznáme podľa 1..* pri Section). Poďme si teraz uviesť jednotlivé možné zápisy multiplicity:

• 1 (číslo) - Označuje konkrétnu hodnotu (tu práve 1).
• * (hviezdička) - Označuje ľubovoľný počet (teda aj 0). Namiesto hviezdičky môžeme v niektorých materiáloch nájsť symbol N.
• 1..* (interval) - Pomocou 2 bodiek môžeme označiť interval. Do neho vkladáme nám už známe symboly, napr.: 2..6 alebo 1..* alebo 0..1.

Zápisy môžeme dokonca aj zlučovať, napr. takto: 1, 2, 3, 7..*. Tento zápis označuje multiplicitu 1, 2, 3 alebo 7 a viac.

Pokiaľ nie je multiplicita uvedená, označuje to východiskovú hodnotu 1.

Príklad

Pokračujme v našom návrhu ITnetwork, zamyslime sa nad základnými entitami a prepojme ich vzťahy. Mohli by sme dospieť k podobnému výsledku (uviedol som aj atribúty, čo však nie je vôbec nutné):

Všimnite si, že v doménovom diagrame väzby ešte dodatočne popisujeme, v Class diagrame to už spravidla nerobíme. Vyplnená šípka označuje smer, v ktorom čítame popis väzby, napr. redaktor píše článok. Mohol by tu byť opačný smer šípky a popis článok bol napísaný, aj keď to neznie tak prirodzene.

V nasledujúcom kvíze, Kvíz - Use Case diagram a doménový model v UML, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.