**Prípad použitia** (anglicky *Use case*) opisuje správanie systému v rôznych situáciách vo forme reakcií systému na požiadavky jedného z používateľov systému.

Tento článok opisuje prípady užitia vo všeobecnosti a nevenuje sa priamo diagramom prípadov použitia.

Prípady použitia sa používajú v systémovom inžinierstve na zachytenie funkčných požiadaviek a opisujú vzťahy medzi systémom a používateľom systému vo forme postupnosti jednoduchých krokov. Používateľ systému sa nazýva primárny aktér a vyvoláva interakciu so systémom s cieľom dosiahnuť určitý účel. Každý prípad užitia predstavuje sériu činnosti a udalosti z pohľadu aktéra.

Jednotlivé prípady užitia opisujú ako aktér komunikuje so systémom, aby dosiahol požadovaný cieľ. Podľa úrovne detailu, do ktorej je prípad užitia opísaný, môže každý prípad použitia predstavovať jeden alebo viac scenárov komunikácie. Tieto scenáre zobrazujú odlišné správanie systému v závislosti od zvláštnych požiadaviek a podmienok sprevádzajúcich pôvodnú požiadavku.

Keďže prípady použitia vznikajú v spolupráci systémových analytikov a koncových používateľov systému, pri ich písaní sa nepoužíva technický žargón a preferuje sa jazyk zrozumiteľný pre koncových používateľov. Prípady použitia majú v zásade textovú formu, ale možno ich vyjadriť aj prostredníctvom UML use case diagramov.

Kvalitne napísaný prípad použitia je ľahko čitateľný a skladá sa z viet napísaných v jednej rečníckej forme zobrazujúcich kroky, v ktorých aktér dosahuje svoje ciele alebo odovzdáva informácie iným aktérom. Prípady použitia sú vždy písané z pohľadu zákazníka a podávajú prvú predstavu o rozsahu projektu.

Dejiny
------

Už koncom šesťdesiatych rokov vymyslel Ivar Jacobson pri práci na telefónnom systéme vo firme Sony Ericsson vec, ktorá sa neskôr stala známa ako prípady použitia. Až v osemdesiatych rokoch ich však uviedol do objektovo orientovanej programátorskej komunity, kde začali byť hneď uznávané ako vynikajúci prostriedok na vyplnenie medzery medzi používateľmi a vývojármi pri vývoji informačných systémov.

Pôvodne mali prípady použitia textovú podobu, až neskôr sa začali interpretovať aj graficky a boli zaradené do jazyka UML (Unified Modeling Language).

Prehľad
-------

Prípady užitia popisujú spôsob a postup ako dosiahnuť požadovaný cieľ. Pri vývoji 
informačného systému má zákazník určité 
požiadavky na funkcionalitu systému. Správne definovať tieto požiadavky a porozumieť im, sú kľúčové časti celého projektu vývoja informačného systému. Ak nebude požiadavka správne formulovaná, výsledkom nebude to, čo zadávateľ skutočne chcel, ale to, čo formuloval.

Požiadavka je jednoznačne vyjadriteľná potreba toho, čo ma daný systém alebo služba vykonávať. Formuluje budúcu vlastnosť, schopnosť a charakteristiku či kvalitu systému. Prípady užitia však nemusia vždy zaznamenávať iba požiadavky na správanie software či jeho časti. Môže ísť aj o zdokumentovanie firemných procesov vo firme. Preto rozlišujeme dva druhy prípadov užitia – firemné prípady užitia a systémové prípady užitia.

Firemné prípady užitia opisujú firemné procesy v organizácií. Diskutovaným systémom je v tomto prípade sama organizácia a prípady užitia ukazujú ako jednotlivé procesy fungujú a akú prinášajú svojim vlastníkom či účastníkom hodnotu.

Systémové prípady použitia opisujú jednotlivé funkcie, ktoré systém ponúka svojim používateľom, aby uspokojil ich potreby a pomohol im dosiahnuť požadovaný cieľ. V tomto prípade prípady užitia zobrazujú čo aktér dosiahne tým, že bude so systémom komunikovať.

Komponenty prípadov použitia
----------------------------

Hlavnou zásadou pri písaní prípadov použitia je nepoužívať zložitý technický jazyk pri opisovaní jednotlivých prípadov a používať zrozumiteľnú ľudskú reč a aj pri jej používaní uprednostňovať jednoduché vety pred zložitými súvetiami, používať rovnaké výrazy – nepoužívať synonymá – aby nedošlo k zmäteniu čitateľov prípadov použitia.

Preto neexistuje štandardná šablóna, schéma či jazyk na opis prípadov použitia. Štandardizácia je však dôležitá v rámci jedného projektu či jednej organizácie. Aj napriek tomu existuje niekoľko prvkov, ktoré každý prípad použitia musí obsahovať, aby mal relevantnú vypovedaciu hodnotu.

### Názov

Prípady použitia opisujú, akým spôsobom môže aktér dosiahnuť svoj cieľ. Keďže je to opis činnosti, mal by názov prípadu použitia obsahovať sloveso a opisovať cieľ, ktorý možno dosiahnuť, napr. Objednať výrobok je lepšie ako Objednávka výrobku.
Názov prípadu použitia má byť krátky a výstižný, pomenovaný podľa cieľa aktéra a zložený z dvoch či maximálne troch slov. Ak je názov dlhý, dá sa predpokladať, že existuje výstižnejšie pomenovanie.

### Cieľ

Podnetom pre vznik prípadu použitia je zámer aktéra dosiahnuť určitý cieľ, preto je prípad použitia, ktorý nemá definovaný cieľ, nepoužiteľný. Cieľ by mal opisovať, čo chce aktér dosiahnuť tým, že sa bude správať tak, ako opisuje prípad použitia.

### Aktér

Aktér je niekto alebo niečo nachádzajúce sa mi mimo systému. Nemusí to byť len človeka, môže to byť aj mechanický či počítačový systém alebo celá organizácia. Aktér môže na systém priamo pôsobiť alebo môže systém pôsobiť na neho. Podľa toho rozoznávame primárneho a sekundárneho aktéra. Aktér predstavuje rolu, nie konkrétneho používateľa, ktorá je vo vzťahu so systémom, ktorého funkcionalitu opisujeme. Každý používateľ môže vystupovať v rozličných rolách, byť vždy iným aktérom, v závislosti od toho, akú funkciu systému práve využíva.

**Primárny aktér** – účastník požadujúci, aby systém zaistil dosiahnutie jeho cieľa. Obvykle iniciuje interakciu so systémom.

**Sekundárny aktér** – systém, voči ktorému ma diskutovaný systém cieľ alebo pre ktorý má tento systém nejakú úlohu.

### Vstupné podmienky

Vstupná podmienka definuje, čo musí byť splnené (čo musí systém garantovať, že je pravda), aby mohol byť prípad použitia splnený. Vstupné podmienky však samé o sebe nespúšťajú prípad použitia, no v prípade ich nesplnenia k spusteniu prípadu nedôjde. Obvykle je vstupná podmienka zárukou toho, že už prebehol iný prípad užitia, ktorý túto podmienku nastavil. Je dôležité neprehliadnuť žiadnu vstupnú podmienku, pretože ak nastane situácia nepopísaná vo vstupných podmienkach prípadu použitia a tým pádom systém nie je na túto situáciu pripravený, môže sa buď zrútiť alebo začať správať nepredvídane. Vzhľadom na to, že vstupnú podmienku nastavuje systém a je jasné, že je platná, nie je nutné ju opätovne v priebehu prípadu užitia overovať.

### Spúšťače

Spúšťač špecifikuje udalosť, ktorá iniciuje začatie prípadu použitia. Táto udalosť môže byť interná, časová alebo externá. Niekedy spúšťač predchádza prvému kroku prípadu užitia, niekedy je sám prvým krokom.

### Hlavný úspešný scenár

Je to typický scenár, opis jednotlivých jednoduchých činností, na konci ktorých je dosiahnutý požadovaný cieľ. Všetky ostatné spôsoby vedúce k úspechu či ošetrenie chybových stavov sú rozšírené scenáre.

Príklad hlavného scenára:

1. Používateľ si vyberie požadovanú kategóriu výrobkov
2. Systém zobrazí výrobky patriace do tejto kategórie
3. Používateľ si vyberie konkrétny produkt a klikne pre zobrazenie detailných informácií
4. Systém zobrazí detailné informácie k danému výrobku

Každý krok scenáru môže popisovať:

* interakciu medzi dvoma aktérmi (aby sme dosiahli cieľ)
* validáciu (aby sme ochránili účastníka)
* internú zmenu stavu (v záujme účastníka)

### Rozšírenia (alternatívne scenáre)

Prípad použitia by mal obsahovať všetky scenáre, ako hlavný úspešný scenár, tak ostatné úspešné či neúspešné scenáre. Rozšírenia sa dajú písať troma spôsobmi:

* písať všetky jednotlivé scenáre samostatne
* používať v prípadoch podmienené výrazy s využitím slova „ak"
* opísať hlavný úspešný scenár ako jednoduchú postupnosť krokov a písať rozšírenie pre každý bod rozvetvenia

Rozšírenie je v skutočnosti rozpracovaný prípad použitia. Začína podmienkou, obsahuje sekvenciu krokov opisujúcich, čo sa v prípade splnenia podmienky stane a končí dosiahnutím cieľa rozšírenia alebo predčasným ukončením.

Podmienky rozšírenia sú podmienky, na základe ktorých sa systém chová odlišným spôsobom. Rozšírenia zahrňujú alternatívy ako pre úspešné, tak aj pre neúspešné vyhodnotenie podmienok. V prípadoch použitia sa môžu vyskytovať aj podmienky v už existujúcich podmienkach, ktoré vyžadujú ďalšie rozšírenia. Tento jav sa nazýva vnorovanie. Je však nutné rozlíšiť, kedy je ešte vnorovanie prehľadné a kedy je vhodnejšie vytvoriť nový prípad užitia.

Prípady použitia a UML
----------------------

Hoci sú prípady použitia pôvodne písané výlučne v textovej podobe, existuje aj ich grafické vyjadrenie. Diagramy prípadov užitia poskytujú rýchlu predstavu o jednotlivých funkciách systému, ale presné postupy, rozširujúce či alternatívne scenáre musia byť zachytené v textovej forme. Modelovací jazyk UML v sebe zahrňuje i diagramy pre prípady použitia.

V UML diagramoch zachytávame len prípady použitia, aktérov a ich vzťahy. Prípad použitia je vyjadrený oválom

Najdôležitejšou časťou je správne priradenie prípadu použitia k aktérovi, ktoré zobrazujeme plnou neprerušovanou čiarou. Diagramy prípadov užitia sú však iba pomôckou pre rýchlu orientáciu vo funkčných požiadavkách na systém, ktoré musia byť podložené významovými textovými popismi jednotlivých prípadov použitia.

Výhody používania prípadov použitia
-----------------------------------

* načrtnú prvú tvár navrhovaného systému
* pomáhajú odhadovať a plánovať prácu na projekte
* sú ľahko pochopiteľné pre klienta a poskytujú jednoduchú a zrozumiteľnú komunikáciu medzi klientom a vývojármi
* majú "poloformálnu" štruktúru. Prípady použitia netrvajú striktne na tom, ako musia byť jednotlivé požiadavky zachytené, ale zároveň vyžadujú určitú formálnu štruktúru toho, ako majú byť zapísané. Tvorivosť samotného opisu jednotlivých prípadoch použitia je na ich autorovi.
* prípady použitia zachytávajú väčšinu neobvyklých a chybových situácií, ktoré môžu nastať. Veľká časť práce pri tvorbe systému spočíva v zvládaní chybových a neočakávaných situácií, a preto sa prípady užitia snažia tieto situácie opísať hneď na začiatku procesu tvorby systému.
* poskytujú dôležité informácie pre veľa ľudí podieľajúcich sa na vývoji systému. Projektový manažér môže pomocou nich zostaviť plán projektu a odhady prácnosti, grafici a návrhári dizajnu používateľského rozhrania navrhujú grafiku a následne ju prepájajú s jednotlivými prípadmi použitia, testéri zostavujú scenáre pre testovanie na základe úspešných a neúspešných scenárov a podmienok z prípadov užitia a podobne.
* prípady použitia sa zameriavajú na užívateľov systému viac než na systém samotný a preto obsahujú skutočné potreby, ktoré ma systém pokrývať.

Nevýhody a obmedzenia prípadov použitia
---------------------------------------

* zachytávajú iba funkčné požiadavky na systém. Nepracujú s požiadavkami, ktoré nie sú založené na interaktivite s používateľom, ako napr. algoritmy, ani s nie funkčnými požiadavkami, ako napr. platforma, výkon a podobne.
* vyžadujú osvojenie nových znalostí pre vývojárov aj pre klienta
* pri extrémnom programovaní môžu vďaka podrobnému opisu požiadaviek spôsobovať stratu času

Zdroje
------

1. 1 2 3 4 5 6  Alistair Cockburn. *Use Cases - Jak efektivně modelovat aplikace*. [s.l.] : [s.n.], 2005. ISBN 80-251-0721-3.
2. ↑  Hana Kanisová a Miroslav Muller. *UML srozumitelně*. [s.l.] : [s.n.], 2004. ISBN 80-251-0231-9.

*Tento článok je čiastočný alebo úplný preklad článku Use case na anglickej Wikipédii (číslo revízie nebolo určené).*

Pozri aj
--------

* Diagram prípadov použitia