UML, analýza požadavků

BI-WI.21-11
  • Modelování obchodních procesů (UML diagram aktivit),
  • analytický doménový model (UML diagram tříd, UML stavový diagram),
  • analýza a správa požadavků (cíle, kategorizace, UML diagram případů užití, scénáře případů užití).

Modelování obchodních procesů

  • Cílem je popsat jak proces probíhá.

  • Pro zachycení procesů je nejdůležitější textový popis, diagram slouží pro snadnější pochopení a ověření.

  • Prakticky "pokročilejší vývojový diagram"

  • Typicky dvě fáze:

    • modelování současného stavu (AS IS)
    • a budoucího stavu (TO BE).

  • Využívá se pro

    • popsání činností zákazníka
    • pochopení potřeba a problémů
    • přesnější specifikaci požadavků
    • identifikaci problémových míst

UML diagram aktivit

UML = Unified Modeling Language

  • Znázorňuje tok řízení a tok dat mezi akcemi v procesu, algoritmu nebo případu užití.

  • Zaměřuje se na dynamické aspekty systému, ukazující sekvenci kroků a rozhodnutí.

  • Využíván pro:

    • Modelování workflow a obchodních procesů
    • Detailnímu popisu logiky operací nebo případů užití
    • Vizualizace interakcí mezi částmi systému nebo mezi systémem a externími entitami

../../Attachments/Pasted image 20260618165256.png

Notace uzlů

Prvek Notace (dle ) Popis Ukázka
Počáteční uzel Vyplněný černý kruh Začátek toku aktivity. ../../Attachments/Pasted image 20260618165758.png
Koncový uzel aktivity Černý kruh s bílým okrajem (terč) Konec celého toku aktivity. ../../Attachments/Pasted image 20260618165813.png
Koncový uzel toku Kruh s křížkem uvnitř Konec specifického toku, nikoliv celé aktivity. ../../Attachments/Pasted image 20260618165820.png
Akce Obdélník se zaoblenými rohy Základní krok práce (může být i odeslání/přijetí události, časová událost, volání jiné aktivity). ../../Attachments/Pasted image 20260618170127.png
Odeslání události Vlajka se šipkou vpravo "teleport/návěstí" ../../Attachments/Pasted image 20260618170143.png
Přijetí události Vlajka s vybráním šipky vlevo "teleport/návěstí" ../../Attachments/Pasted image 20260618170150.png
Časová událost Přesýpací hodiny Začátek toku závislý na čase (např. 14dní před xxx) ../../Attachments/Pasted image 20260618170158.png
Tok řízení (Přechod) Plná šipka Směr postupu mezi akcemi/uzly. ../../Attachments/Pasted image 20260618170253.png
Objektový uzel / Tok Obdélník (objekt), přerušovaná šipka (tok) Reprezentuje data/objekty a jejich tok mezi akcemi. ../../Attachments/Pasted image 20260618170905.png
Rozhodovací uzel Kosočtverec (1 vstup, více výstupů) Větvení toku na základě podmínek. ../../Attachments/Pasted image 20260618170923.png
Slučovací uzel Kosočtverec (s více vstupy, 1 výstupem) Sloučení alternativních toků,
nevyžaduje synchronizaci.		 ../../Attachments/Pasted image 20260618170923.png
Uzel větvení (Fork) Silná čára (1 vstup, více výstupů) Rozdělení toku na paralelní větve. ../../Attachments/Pasted image 20260618170942.png
Uzel spojení (Join) Silná čára (více vstupů, 1 výstup) Synchronizace a sloučení paralelních větví,
tok pokračuje až poté, co jsou dokončeny všechny vstupující paralelní toky.		 ../../Attachments/Pasted image 20260618170942.png
Zóna zodpovědnosti (Swimlane) Obdélníková oblast (sloupec/řádek) Znázornění odpovědnosti za akce (aktér, oddělení). ../../Attachments/Pasted image 20260618171243.png
Strážní podmínka Text v [ ] na přechodu z uzlu rozhodnutí Podmínka, která musí být splněna pro aktivaci přechodu. ../../Attachments/Pasted image 20260618171210.png

Analytický doménový model

  • Konceptuální model zachycující klíčové entity, jejich atributy a vztah k problému.

  • Zaměřuje se na CO (jaké koncepty existují), nikoli JAK (implementaci).

  • Třídy vyplývají z podstatných jmen business proces modelu, use case modelu a slovníčku pojmů.

  • Cílem je popsat

    • data,
    • význam termínů,
    • vazby mezi entitami,
    • a identifikovat stavy entit a jejich atributy.

UML diagram tříd

  • Statická struktura domény zobrazením tříd, jejich atributů a vztahů

  • V analytickém modelu se operace (metody) často vynechávají, důraz je kladen na koncepty a jejich vztahy.

  • V kontextu analytického modelu:

    • Třídy reprezentují koncepty z domény problematiky
    • Atributy reprezentují relevantní vlastnosti konceptů (bez datových typů)
    • Vztahy modelují propojení konceptů

../../Attachments/Pasted image 20260618172011.png

Třída, atribut, operace

  • Třída - Obdélník s názvem a atributy, sekce pro metody může být prázdná
  • Atribut - Vlastnost třídy, typicky jen název, viditelnost ani typ se nemusí specifikovat (- private, # protected, + public)
  • Operace - Metoda, chování třídy, často vynechány v doménovém modelu

../../Attachments/Pasted image 20260618172336.png

Vztahy

  • Asociace - Obecný vztah s názvem a násobností
  • Kompozice - Silnější forma agregace, část nemůže existovat bez celku (vyplněný kosočtverec)
  • Agregace - Vyjadřuje "má část", může existovat nezávisle (kosočtverec)
  • Generalizace/Dědičnost - Vyjadřuje "je typu", podtřída dědí od nadtřídy

../../Attachments/Pasted image 20260618173739.png

  • Asociační třída - Čistě na konceptuální úrovni, umožňuje přidat atributy k vazbě

../../Attachments/Pasted image 20260618174046.png

UML stavový diagram

  • Chování konkrétního objektu v průběhu životního cyklu.

  • Popisuje všechny možné stavy, kterých může nabýt a přechody mezi nimi.

  • Pro vyjádření chování objektů, které je složité a závislé na aktuálním stavu a externích událostech (tzv. reaktivní systémy).

  • Cílem je:

    • porozumění životnímu cyklu entit,
    • vyjasnění stavů
    • zachycení událostí
    • popis podmínek změn

  • Lze realizovat pomocí návrhového vzoru Stav

../../Attachments/Pasted image 20260618174352.png

Komponenty

  • Stav - Zaoblený obdélník
    • Počáteční stav - Vyplněný černý kruh, označuje začátek životního cyklu
    • Koncový stav - Černý kruh s bílým okrajem (terč)
  • Přechod - Směrová šipka, obvykle formátu událost [strážní podmínka] / akce

Analýza a správa požadavků

  • Zjišťování, shromažďování, dokumentování, analyzování a validování potřeb a podmínek, které má software splňovat

  • Zajišťuje, aby produkt co nejvíce splňoval reálné potřeby koncových uživatelů a stakeholderů.

  • Vývoj v rámci stanového rozpočtu a časového plánu

    • Vymezuje hranice systému
    • Přesnější odhad pracnosti
    • Vyjasnění zadání se zákazníkem
    • Zachycení omezení kladených na IS

Cíle

  • Vysokoúrovňové záměry, potřeby nebo očekávání stakeholderů, které popisují, čeho chtějí dosáhnout pomocí systému.

  • Odpovídají na otázku “proč” je systém vyvíjen.

  • Oproti tomu požadavky jsou konkrétnější specifikace “co” se musí vyvíjet, aby byly cíle naplněné.

  • Poskytují kontext a zdůvodnění požadavků.

  • Umožňují evaluaci a prioritizaci požadavků (požadavek je oprávněný, pokud přispívá k cíli).

  • Pomáhají při řešení konfliktů mezi požadavky.

  • Podporují sledovatelnost a validaci.

  • Jsou zdrojem nefunkčních požadavků (kvalitativní cíle, např. použitelnost, bezpečnost).

Kategorizace požadavků

Funkční požadavky

  • Co musí systém dělat, jaké konkrétní funkce a služby má poskytovat
  • Popisují chování systému
  • Modelovány pomocí případu užití (use case diagram)

../../Attachments/Pasted image 20260618175245.png

Nefunkční požadavky

  • Jaké vlastnosti má systém mít, jak dobře má systém fungovat

  • Omezení kladená na systém a mají zásadní dopad na návrh architektury

  • Měly by být co nejvíce kvantifikovatelné a ověřitelné

  • Lze je kategorizovat pomocí FURPS:

    • Functionality - specifické aspekty funkčnosti
    • Usability - Snadnost s jakou může uživatel systém obsluhovat. např. responzivita
    • Reliability - schopnost fungovat bezchybně. např. dostupnost 99.9%.
    • Performance - rychlost odezvy, propustnost. např. obsloužení 100 paralelních dotazů uživatelů
    • Supportability - snadnost modifikací a oprav

UML diagram případů užití (Use case)

  • Funkcionalita systému z pohledu externích uživatelů nazývaných aktéři

  • Popisuje CO systém dělá, ne JAK to interně realizuje.

  • Je součástí činnosti analytika při definování požadavků a rozsahu projektu.

  • Hlavní účel

    • Identifikovat, organizovat a komunikovat funkční požadavky
    • Definovat hranice systému a jeho interakce s vnějším světem (aktéry)
    • Vysokoúrovňový přehled o schopnostech
    • Slouží jako základ pro detailnější specifikaci chování pomocí scénářů případů užití

../../Attachments/Pasted image 20260618175836.png

Komponenty

  • Aktér - Postavička - Role entity (uživatel, systém, čas, ...) interagující se systémem
  • Případ užití - Elipsa - Sekvence akcí systému poskytující výsledek pro aktéra
  • Hranice systému - Vnější obdélník - Odděluje případy užití od aktérů
  • Vztahy
    • Asociace - Plná čára spojující aktéra s případem užití
    • Generalizace mezi aktéry - Plná čára s plnou (trojúhelníkovou) šipkou, prakticky dědičnost, např. Čtenář ../../Attachments/Pasted image 20260618180607.png Uživatel
    • Stereotyp <<include>> - Přerušovaná šipka - vyčlenění společné funkcionality
    • Stereotyp <<extend>> - Přerušovaná šipka - přidává volitelnou funkcionalitu za určitých podmínek, základní případ užití je kompletní i bez rozšíření

../../Attachments/Pasted image 20260618180836.png

Scénáře případů užití

  • Textový popis sekvence interakcí mezi aktérem a systémem při provádění konkrétního případu užití. Diagramy PU jsou pouze doplňkem pro rychlejší orientaci.

  • Každý PU má hlavní scénář (basic flow) a může mít alternativní scénáře (alternative flows) a výjmečné scénáře (exception flows).

  • Popisuje komplikované a důležité PU

  • Pro velmi složité PU používáno v kombinaci s UML diagramem aktivit

  • V kombinaci s grafickým návrhem obrazovky (wireframe) usnadňuje pochopení a komunikaci

  • Význam

    • Detailní pochopení funkčnosti
    • Základ pro tvorbu uživatelské příručky, akceptačních testů a zpřesnění odhadů
    • Zadání programátora
    • Vyjasňuje nejasnosti v požadavcích
    • Usnadňuje komunikaci a validaci

  • Typická struktura

    • Název případu užití
    • Identifikátor
    • Cíl/stručný popis
    • Aktéři (primární a sekundární)
    • Vstupní podmínky - stav systému před zahájením
    • Hlavní úspěšný scénář - číslovaná sekvence kroků interakce aktér-systém
    • Alternativní toky
    • Výstupní podmínky - stav systému po dokončení

Vytvořeno: 18. 6. 2026, 16:19
Poslední aktualizace: 18. 6. 2026, 19:28