Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Metoda : Unified Modeling Language (UML)
Unified Modeling Language (UML)
Kód metody

Standarní kód metody v MBI

:
M529
Popis, obsahové vymezení

Obsahové vymezení metody - rekapitulace základních principů ve vztahu k řízení informatiky

1. Unified Modeling Language (dále UML) - celková charakteristika
  • Jazyk UML vznikl v polovině 90. let a je na něm postaveno mnoho objektově orientovaných metodik . O rozvoj jazyka se stará skupina Object Management Group (OMG) .
  • Podstatnou výhodou jazyka UML je jeho nezávislost na procesu vývoje, protože jazyk UML není svázán s žádnou konkrétní vývojovou metodikou.
  • Jazyk UML prošel během svého rozvoje několika změnami a rozšířeními. Příkladem je Object Contraint Language (OCL), který je využíván pro definici omezení.
  • Pro ukládání modelů UML existuje standardizovaný formát XML Metadata Interchange (XMI). Pomocí XMI je možné přenášet UML modely mezi různými CASE nástroji,.
  • Za pomoci diagramů umožňuje jazyk UML zachytit systém na různé úrovni abstrakce . UML obsahuje 14 typů diagramů , které jsou rozděleny na diagramy chování a diagramy struktury .
  • Mezi diagramy chování patří diagram aktivit, stavový diagram, diagram případů užití a všechny diagramy interakcí. Do diagramu interakcí patří diagram komunikace, diagram přehledu interakcí, sekvenční diagram a diagram časování.
  • Do diagramů struktury patří diagram tříd, diagram vnitřní struktury, diagram komponent, diagram nasazení, objektový diagram (někdy též nazýván diagram instancí), diagram profilů a diagram balíčků.
  • Diagramy chování jsou určeny k zachycení chování systému . Diagramy chování zachycují dynamické chování objektů v systému a to včetně jejich metod, spolupráce, aktivity a stavové historie . Dynamické chování systému může být popsáno jako série změn systému v určitém čase (Object Management Group, 2015).
  • Diagramy struktury jsou určeny k zachycení elementů nezávislých na čase . Diagramy struktury zachycují statickou strukturu objektů v systému a to znamená, že zachycují elementy ve specifikaci, která je nezávislá na čase. Elementy v diagramu struktury reprezentují koncept aplikace a mohou zahrnovat koncept z realného světa, abstraktní koncept a implementační koncept. Strukturální diagramy nezachycují detail dynamického chování, který je zachycen pomocí diagramů chování. (Object Management Group, 2015).
2. Typy diagramů UML
  • Diagram profilů: Metamodel k zachycení stereotypů jako tříd a profilů jako balíčků,
  • Diagram třid: Určen k zachycení tříd, atributů, metod a vztahů mezi objekty,
  • Diagram vnitřní struktury: K zachycení interní struktury prvku a spolupráce, kterou daná struktura umožňuje,
  • Diagram komponent: Pro zachycení vztahů jednotlivých komponent, které tvoří větší komponenty anebo celý informační systém. Určeno pro svévolné zachycení komplexních systému.,
  • Diagram nasazení: Určen k zachycení hardwarových zdrojů a softwarových komponent. Diagram umožňuje zachycení jejich spolupráce, lokality a další.,
  • Objektový diagram: Zachycuje kompletní nebo částečnou strukturu systému ve specifický čas.,
  • Diagram balíčků: K zobrazení obsahu a závislostí jednotlivýc balíčků.,
  • Diagram aktivit: Reprezentace posloupnosti aktivit s podporou rozhodování, iterace a souběžnosti.
  • Diagram případů užití: Zachycuje uživatelskou interakci se systémem a chování systému,
  • Stavový diagram: Určen k zobrazení jednotlivých stavů objektů a přechodů mezi nimi.,
  • Sekvenční diagram: Pro zachycení interakce mezi jednotlivými objekty a její posloupnosti,
  • Diagram komunikace: Zobrazením toku zpráv a vzájemných vztahů zachycuje komunikaci třídy, sekvence a případu užití,
  • Diagram přehledu interakcí: Stejný význam jako má diagram aktivit s tím, že jednotlivé aktivity představují diagramy interakcí,
  • Diagram časování: Pro zachycení chování objektu ve specifický časový úsek.

V dalších paragrafech jsou detailněji vymezeny pouze digramy případu užití a diagramy aktivit, jako zřejmě nejvyužívanější.

2.1. Use Case diagramy
  • Diagram případů užití zachycuje funkční požadavky na systém .
    • Diagram případů užití umožňuje zachytit, jaký typ uživatele používá systém a jaké činnosti vykonává . Nejvýznamnějšími prvky diagramu případů je případ užití, aktér a vztah .
  • Na modelu případů užití jsou zobrazeny zejména jednotlivé případy užití a jejich slovní popis . Případy užití představují funkční požadavky na systém.
  • Prvek diagramu s názvem AKTÉR zachycuje uživatele, který komunikuje se systémem. Aktérem může být buď živá osoba, jiný systém anebo hardware se kterým modelovaný systém komunikuje. Aktér je v jazyce UML zobrazen symbolem, který u sebe obsahuje název modelovaného aktéra. Živým aktérem může být například operátor anebo uživatel bankomatu. Neživým aktérem může být například core banking systém ,
  • Významným prvkem diagramu je případ užití, který je určen pro charakteristiku funkcionality systému plnící určitý cíl a je používán aktérem.
  • Každý případ užití dále obsahuje slovní popis. Samotná funkcionalita případu užití je specifikována jako posloupnost interakcí mezi aktérem a systémem. Posloupnost interakcí je pro případ užití označeno jako scénář případů užití (dále scénář). SCÉNÁŘ je určen jednomu průchodu případem užití od začátku do konce neboli jedné instanci případu užití. Jednotlivé případy užití začínají určitou spouštěcí událostí a pokračují, dokud není cíl případu užití splněn anebo dokud není případ užití přerušen. Obrázek obsahuje schématické znázornění případů užití ,
  • Na obrázku jsou znázorněny různé průchody případem užití neboli různé toky událostí , které jsou popsány různými scénáři. Prostřední přímá čára je zobrazením pro úspěšný scénář , který reprezentuje základní tok událostí. Úspěšný scénář vede k dosažení cíle případu užití.
  • Scénář z obrázku s označením „nesprávné zadání“ odpovídá chybně zadaným vstupním datům. V takovém případě je nutné se vrátit zpět a zadat údaje znovu. Pokud dojde k chybě či výjimce, tak skončí scénář dříve a v takovém případě není splněn cíl případu užití. Jednotlivé případy užití jsou množinou možných scénářů, které jsou popsány ve specifikaci daných případů užití. Tento popis by měl být sepsán bez používání detailní technické terminologie, jelikož je určen pro diskuzi nad požadavky na systém i s uživateli.
  • Doporučená struktura slovního popisu případu užití obsahuje:
    • Identifikace - jednoznačné označení případu užití,
    • Název případu užití,
    • Cíl – určení byznys cíle případu užití,
    • Primární aktér (aktéři) - pomocí případu užití plní cíl.
    • Pomocný aktér (aktéři) - poskytuje službu pro splnění úkolu primárního aktéra.
    • Vstupní podmínky - musí být splněny, pokud má případ užití začít.
    • Výstupní podmínky - definují stav systému po ukončení případu užití.
    • Scénáře případu užití - hlavní scénář - může být rozdělen na dílčí alternativní scénáře, které popisují výjimečné situace.
  • Dalším prvkem diagramu je VZTAH , který vyjadřuje tok informace mezi vnějším aktérem a případem užití. Vztah bývá označován také jako komunikační asociace a na diagramu je zobrazen čarou mezi případem užití a aktérem. Zobrazená čára může naznačovat, která strana iniciuje interakci, a to zakončením pomocí šipky. Uvádět šipku není povinné a v takovém případě může iniciovat interakci libovolná strana. Obrázek zobrazuje příklad aktéra, případů užití a zobrazenými vztahy mezi zmíněnými prvky ,
  • Vztahy mohou nabývat různých typů, které jsou známé pod názvy „include“, „extend“ a „generalizace“ či „specializace“.
  • Vztah „include“ je určen pro znázornění vloženého případu užití do jiného případu užití. Použití nalezne zejména u opakující se činnosti, která je vyjmuta a vytvořena jako nový případ užití navázaný na původní případ užití pomocí vazby „include“. Vložený případ se provede vždy. Obrázek zobrazuje použití vztahu „include“ ,
  • Vztah „extend“ je určen pro znázornění rozšíření chování základního případu užití. K rozšíření dochází pouze v případě, že je splněna podmínka rozšíření a pro vztah „extend“ dále platí, že základní případ může existovat sám o sobě (na rozdíl od vztahu „include“). Použití vztahu „extend“ nalezne uplatnění zejména v případech, ve kterých je zapotřebí vytknout podmíněné nebo výjimečné chování anebo je zapotřebí přidat chování, které rozšiřuje původní funkcionalitu, například v případech, kdy bude rozšiřující chování přidáno až v další verzi systému. Obrázek zobrazuje použití vztahu „extend“ ,
  • Vztah „generalizace“ či „specializace“ je určena pro zachycení obecného a speciálního chování. Tento vztah není určen jen pro případy užití, ale může být používán i pro aktéry. Vztah může způsobit nepřehlednost v modelu, a proto se jeho používání spíše nedoporučuje. Uplatnění vztahu nalezne zejména jako zjednodušení pro aktéry v případě, že množina aktérů vykonává jeden případ užití. V takovém případě je vhodné vytvořit společného předka pro jednotlivé aktéry a tohoto předka napojit na daný případ užití. Může se jednat například o přihlášení do aplikace. Obrázek obsahuje použití vztahu „generalizace“ u aktérů, kteří využívají společný případ užití ,
  • Modelování případů užití představuje techniku analýzy, která pomáhá identifikovat a vyjasňovat jednotlivé požadavky na systém. Modelování bývá poměrně pracné a v průběhu procesu vývoje dochází k upřesňování podoby modelu.
2.2. Diagramy aktivit
  • Diagram aktivit je určen pro zachycení aktivit se sekvenčním i paralelním průběhem . Modelování pomocí diagramu aktivit je možné využít pro zachycení logiky scénáře případu užití, zachycení byznys procesů a zachycení logiky byznys pravidel. Mezi prvky diagramu aktivit patří inicializace (zahájení), aktivita, tok, rozhodování, větvení, spojení, plavecké dráhy a ukončení .
  • Aktivita je modelována jako obdélník s uvedením názvu aktivity, který by měl být vyjádřen slovesnou vazbou, např. přihlásit se do aplikace. Aktivitu není možné dále dělit a nelze ji přerušit. Jednotlivé aktivity mohou mít pouze jeden vstupní bod a jeden výstupní tok . Pro zobrazení toku je určena čára se šipkou.
  • Prvek rozhodování je určen pro přerušení lineárního provádění aktivit. Vstupem je pro rozhodování jeden tok a výstupní počet toků není omezen, ovšem každý výstupní tok musí mít definovanou výstupní podmínku, které musí být definovány tak, aby bylo možné splnit pouze jednu.
  • Paralelní zpracování je možné zachytit pomocí prvku rozvětvení a spojení. Prvek rozvětvení má jeden vstupní tok a několik výstupních toků, které probíhají paralelně. Když dojde k rozvětvení, tak běží toky paralelně bez ohledu na pořadí, které není podstatné. Po dokončení paralelního zpracování dojde ke spojení běžících toků pomocí prvku pro spojení.
  • V diagramu aktivit je dále možné využít „plavecké dráhy“ k zachycení toho, kdo danou aktivitu provádí. Aktivity se pro tento úmysl seskupí do svislých pruhů dle nositele aktivity, který danou aktivitu provádí, např. dle osoby či oddělení.
  • Obrázek obsahuje příklad s prvkem inicializace, aktivity, rozhodování a zakončení .
3. Poznámky, reference