2. diel - UML - Use Case Diagram

V predchádzajúcej 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 tutoriáli UML 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ť funkčnosť 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 pýtať sa, 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 súbor 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. Presne tento princíp 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). 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 na fórum). Tu by sme hovorili o tom, že je aktér 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érov 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 ešte nebudeme 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 na rozdiel od redaktorov opäť spúšťať niekoľko funkcií 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 autor článku dostane upomienku pri schválení a zamietnutí článku. Samotné upomenutie v sebe bude mať ďalšiu logiku, napr 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, takže sa ňou nebudeme 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ívny.

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