2. diel - UML - Use Case Diagram

V minulej lekcii, Úvod do UML , sme si uviedli jazyk UML a pochopili, že uľahčuje tak analýzu, tak i návrh informačných systémov. V dnešnom UML tutoriálu začneme s Use Case diagramy.

Use Case Diagram (slovensky diagram prípadov použitia) zobrazuje správanie systému tak, ako ho vidia 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ácie, 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 použí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 podobne. To v diagrame zachytené už nebude. UML často hovorí o tzv. Blackbox (čiernej skrinke), kde skryjeme vnútornú logiku a pracujeme len s komponentmi. Tento princíp presne využíva UC diagram.

Use Case je najčastejšie zakresľovanie ako elipsa s jeho názvom vnútri.

Prípady použitia vychádza 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. Mapovanie užívateľských požiadaviek na jednotlivé Use Case.

Actor (Aktér)

Aktér je úloha, 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 je aktér aktívna. 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ľuje ho v diagrame napravo.

Aktérmi 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, keďže 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. Opis 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šie 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ípady použitia, ktoré sa ich týkajú. Väzbe znázornenej jednoduchou čiarou hovoríme asociácie. 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 dedia. Tento vzťah je znázornený prázdnu uzavretou šípkou smerom k predkovi. Túto väzbu nazývame generalizácie. Č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čnosťou 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 povolení a zamietnutí článku. Samotné upomenutý v sebe bude mať ďalšie logiku, napr. Či emailom, SMS a podobne. 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úce 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ľujú na pravú stranu, hoci je v podstate aktívny.

Nabudúce, v lekcii UML - Use Case Špecifikácie , si povieme niečo o UC špecifikáciu a ukážeme si ešte jeden Use Case diagram, tentoraz komplexnejšieho systému.