2. diel - UML - Use Case Diagram

V minulej lekcii, Úvod do UML, sme si uviedli jazyk UML a pochopili, že uľahčuje ako analýzu, tak aj návrh informačných systémov.

V dnešnom UML tutoriále začneme s Use Case diagramami.

Use Case Diagram (slovensky diagram prípadov použitia) zobrazuje správanie systému tak, ako ho vidí užívateľ. Účelom diagramu je popísať funkcionalitu systému, teda čo od neho klient alebo my očakávame. Diagram vypovedá o tom, čo má systém vedieť, ale nehovorí, ako to bude robiť. Preto je to väčšinou prvý diagram, ktorý pri návrhu informačného systému vytvárame. Je dôležité sa najprv zhodnúť na tom, čo má náš systém (alebo aplikácia, hra, čokoľvek) vedieť. Až potom má zmysel sa pýtať, ako to vlastne urobíme.

Use Case diagram sa skladá z prípadov použitia (use case), ďalej aktérov (actors) a vzťahov medzi nimi.

Use Case (Prípad použitia)

Prípad použitia (alebo skrátene UC) je sada niekoľkých akcií, ktoré vedú k dosiahnutiu určitého cieľa. Use Case môže byť pridanie komentára k článku, registrovanie nového užívateľa alebo napr. vytlačenie dokumentu. Definuje teda jednu funkcionalitu, ktorú by mal navrhovaný systém vedieť. Tá v sebe obsahuje ďalšie akcie, napr. pridanie komentára bude obsahovať overenie užívateľa, validáciu zadaných dát, zápis do databázy a pod. To v diagrame zachytené už nebude. UML často hovorí o tzv. blackboxe (čiernej skrinke), kde skryjeme vnútornú logiku a pracujeme iba s komponentmi. Tento princíp presne využíva UC diagram.

Use Case je najčastejšie zakresľovaný ako elipsa s jeho názvom vo vnútri:

Prípady použitia vychádzajú zo zadania systému od nášho zákazníka (ak robíme systém pre seba, tak z našich poznámok, čo by mal vedieť). Hovoríme o tzv. mapovaní užívateľských požiadaviek na jednotlivé Use Case.

Actor (Aktér)

Aktér je rola, ktorá komunikuje s jednotlivými prípadmi použitia. V tejto úlohe môže byť obsadený používateľ alebo externý systém. Aktérom teda môže byť napr. Užívateľ, Administrátor, SMS server alebo dokonca Čas. Aktér inicializuje nejaký prípad použitia (napr. Užívateľ vloží príspevok do fóra). Tu by sme hovorili o tom, že aktér je aktívny. Aktér sám však môže byť prípadom použitia iniciovaný (napr. externý SMS server je iniciovaný prípadom použitia Poslať SMS). V tomto prípade hovoríme o pasívnom aktérovi a zakresľujeme ho v diagrame napravo.

Aktéry znázorňujeme ako postavu z čiar s názvom napísaným pod ňou:

Poďme si teraz skúsiť vytvoriť ukážkový UC diagram, nakoľko všetci poznáte ITnetwork, budeme navrhovať jemu podobný systém, len značne zjednodušený. Tento ukážkový systém nás bude sprevádzať celým UML kurzom, vlastne si celý ITnetwork navrhneme pomocou niekoľkých UML diagramov. Popis jeho funkčnosti by vyzeral pomocou Use Case diagramu takto:

Vidíme, že diagram nie je zložité nakresliť. Navrhnúť však prípady použitia tak, aby ich bol rozumný počet a rovnomerne pokrývali funkcionalitu systému už chce trochu praxe. Určite je však lepší nejaký ako žiadny, takže sa ho nebojte používať

• Neregistrovaný užívateľ môže písať komentáre alebo sa zaregistrovať. Komunikácia prebieha zľava doprava (pokiaľ nie je šípkou naznačený iný smer). Aktéri sú teda prepojení s tými prípadmi použitia, ktoré sa ich týkajú. Väzbe znázornenej jednoduchou čiarou hovoríme asociácia. Môže mať špecifikovanú násobnosť aj smer, ale tým sa tu nebudeme ešte zaoberať.
• Člen môže to isté, ako neregistrovaný užívateľ, pretože z neho dedí. Tento vzťah je znázornený prázdnou uzavretou šípkou smerom k predkovi. Túto väzbu nazývame generalizácia. Člen môže navyše ešte spravovať svoj profil a hodnotiť články.
• Redaktor tiež vie to isté ako člen, ale navyše môže články aj písať.
• Administrátor môže oproti redaktorom opäť spúšťať niekoľko funkčností navyše. Zaujímavá je väzba <<include>>. Tá sa používa v prípade, že je nejaká funkcionalita dôležitá natoľko, že ju chceme mať v diagrame namiesto toho, aby sme ju len vyhlásili súčasťou nejakého Use Case. Prípad použitia napojený pomocou väzby <<include>> sa spustí vždy, keď je spustený prípad, na ktorý je napojený. Tu je teda autor článku upomenutý pri schválení a zamietnutí článku. Samotné upomenutie v sebe bude mať ďalšiu logiku, napr. či emailom, SMS a pod. My ho máme zabalený v jednom prípade použitia. Okrem <<include>> existuje ešte väzba <<extend>>, ale tá je veľmi zavádzajúca a príliš sa nepoužíva, nebudeme sa ňou teda zaoberať.
• Posledným aktérom je Timer (čas), ten sa v určitú dobu spustí a vykoná odoslanie aktualizácií emailom. Aktéra čas zakresľujeme na pravú stranu, hoci je v podstate aktívna.

V nasledujúcom cvičení, Riešené úlohy k 1.-2. lekciu UML, si precvičíme nadobudnuté skúsenosti z predchádzajúcich lekcií.