11. Co to je uml, k čemu V kontextu softwarového inženýrství slouží?

UML – Unified Modeling Language

• UML je grafický jazyk pro vizualizaci, specifikaci, konstruování a dokumentaci softwarových systémů.

• soubor nejrůznějších typizovaných grafů, které mají zachycovat vztahy, případně postupy, které lze nalézt v komplexních reálných systémech. Od složitých organizačních jednotek až po jednoduché problémy.

• UML nabízí standardní postup pro psaní návrhů systémů, včetně konceptuálních součástí, jako jsou obchodní procesy a systémové funkce, stejně jako konkrétních součástí, jako jsou příkazy programovacího jazyka, schémata databází a znovupoužitelné součásti softwaru

• UML je navrženo natolik rozsáhle, že jím lze modelovat či dokumentovat prakticky jakýkoliv systém.

Slouží k popisu libovolného systému – je vizuální

Má 8 typů diagramů – 8 různých pohledů na model systému:

• diagramy tříd a objektů (class diagrams, object diagrams) popisují statickou strukturu

systému, znázorňují datový model systému od konceptuální úrovně až po implementaci

Diagramy tříd patří bezesporu k nejčastěji používaným nástrojům UML a tvoří vůbec jakýsi základ všech prostředků objektové analýzy a designu . Tyto diagramy jsou většinou vytvářeny již ve fázi analýzy často jako pojmové modely, jejichž úkolem je formálněji definovat jednotlivé termíny používané ve studované problémové oblasti. Takové modely jsou maximálně přínosné a užitečné v okamžiku, kdy je nutno zpětně vstřebat terminologii oboru. S postupným přibližováním k fázi implementace jsou diagramy tříd poměrně zásadně přehodnocovány a v ideálním případě zpracovávány až do podoby grafického modelu ekvivalentního zdrojovému kódu.

Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. UML explicitně rozlišuje několik druhů tříd (parametrizovatelné třídy, …), stejně jako rozličné množství vztahů, které jednotlivé třídy navzájem pojí (asociace, agregace, kompozice, specializace/generalizace, ...).

Tvorba diagramů tříd patří mezi klíčové problémy a zcela vážně lze prohlásit, že zvládnout objektový přístup často znamená správně využívat právě tento typ diagramů používaný průběžně napříč celým životním cyklem tvorby IS. Zvláště při tvorbě těchto diagramů se doporučuje dodržovat nepsané pravidlo 7 + 2, které říká, že v jednom diagramu je vhodné zobrazit 7, maximálně až 9 tříd.

• modely jednání (diagramy případů užití - use case diagrams) dokumentují možné případy

použití systému - události, na které musí systém reagovat

První úkol, tj. vymezení hranic systému, je v UML podpořeno dynamickým pohledem modelovaným prostřednictvím diagramů případů užití, který je znám pod celou řadou dalších názvů jako například diagram typových čiností, jednání atp. Tento diagram, obecně model, zobrazuje základní vztah systému k jeho okolí, tzv. aktorům. Aktory jsou nejčastěji samotní uživatelé systému, nicméně mohou jimi býti obecně libovolní externí činitelé stojící mimo modelovaný systém.

• scénáře činností (diagramy posloupností - sequence diagrams) popisují scénář průběhu určité

činnosti v systému

Sekvenční diagramy se vytvářejí většinou přímo z diagramů případů užití. K jednomu případu užití může existovat několik sekvenčních diagramů, které modelují interakci objektů v rámci komunikace aktora se systémem.

Jak je docela zřejmé, sekvenční diagramy jsou zaměřeny výhradně na dynamickou stránku systému. Jsou vhodné pro nalezení jednotlivých objektů a zobrazení komunikace mezi nimi.

• diagramy spolupráce (collaboration diagrams) zachycují komunikaci spolupracujících objektů,

Chceme-li v jednom diagramu znázornit jak strukturu objektů (například skládání objektů) tak i jejich dynamické chování, použijeme s výhodou diagramů spolupráce, které jsou vedle sekvenčních diagramů dalším prostředkem, jehož těžiště tkví v modelování dynamiky. Na rozdíl od sekvenčních diagramů je však znatelně obtížnější vysledovat návaznost jednotlivých posílaných zpráv zajišťujících samotnou funkcionalitu systému. Zatímco v sekvenčních diagramech je tato návaznost zřejmá z vertikálního uspořádání celého diagramu, v diagramech spolupráce je následnost zobrazena pořadovým číslem, kterým jsou zprávy uvozeny.

Tvorba diagramu spolupráce by měla být v souladu s diagramem tříd. Pro zachování vzájemné konzistence modelů je nezbytné dodržovat základní pravidla, která mezi těmito modely platí. Komunikace mezi objekty musí být například podmíněna existencí odpovídající vazby mezi jejich třídami, o existenci patřičných tříd nemluvě. Nemusíme asi ani zdůrazňovat, jak nevděčnou prací je "ruční" kontrolování obdobných pravidel. Je jasné, že zde mohou opět pomoci CASE nástroje.

• stavové diagramy (statechart diagrams) popisují dynamické chování objektu nebo systému,

možné stavy a přechody mezi nimi

Diagram stavů a přechodů, jak je někdy tento prostředek nazýván, slouží pro modelování životního cyklu části systému svým rozsahem odpovídající jednomu objektu. Přechod mezi jednotlivými stavy bývá vyvolán podnětem z vnějšího okolí, nejčastěji ve formě zprávy zaslané příslušnému objektu nebo jinou externí událostí.

• diagramy aktivit (activity diagrams) popisují průběh aktivit procesu či činnosti,

Jako jistou obdobu stavových diagramů můžeme chápat i diagramy aktivit, kde jednotlivými stavy rozumíme aktivity a přechod mezi aktivitami je vyvolán dokončením aktivity stávající. Diagram aktivit se zpravidla vztahuje k jednomu případu užití, případně k jedné metodě objektu. Pomocí diagramu aktivit modelujeme tentokrát dynamický tok řízený nikoliv vnějšími událostmi ale interními podněty.

• diagramy komponent (component diagrams) popisují rozdělení výsledného systému na

funkční celky (komponenty) a definují náplň jednotlivých komponent

Jeho pomocí se visualizují vztahy mezi jednotlivými SW komponentami, které mohou být ve formě zdrojových souborů, hotových spustitelných částí nebo pouze hlavičkových souborů. Mezi jednotlivými komponetami může existovat pouze jeden druh vazby a tou je závislost. Je možné zobrazovat například návaznost zdrojových a hlavičkových souborů nebo zdrojových souborů tvořící knihovnu tříd.

diagramy nasazení (deployment diagrams) popisují umístění funkčních celků (komponent)

na výpočetní uzly informačního systému.

Diagram nasazení je druhým typem diagramů určených pro implementační fáze. Jeho úkolem je především zobrazit vztahy mezi částmi systému tak, jak vypadají v době samotného vykonávání. Diagramy nasazení zobrazují rozložení jednotlivých SW komponent na HW zdrojích a jejich spolupráci, rozmístění HW a SW prostředků v lokalitách, topologie používaných sítí, druhy a využití komunikačních prostředků atp.

Statickou strukturu systému vyjadřují diagramy tříd, diagramy spolupráce, diagramy komponent a diagram nasazení.

Funkční stránku popisují model jednání, scénáře událostí, diagramy spolupráce a diagramy aktivit. Dynamickou stránku dokumentují scénáře událostí, diagramy spolupráce, stavové diagramy a diagramy aktivit.

Použití diagramů v jednotlivých fázích vývoje je dáno konkrétní metodikou, ale orientačně můžeme říci, že:

V rámci analýzy se využívají diagramy tříd, model jednání, diagramy aktivit, scénáře činností a stavové diagramy.

Pro fázi návrhu jsou typické diagramy tříd, diagramy spolupráce, diagramy aktivit, diagramy komponent a diagramy nasazení.

Ve fázi implementace se používají diagramy tříd, diagramy komponent a diagramy nasazení.