UML diagram. Typy diagramů UML

20. 3. 2019

Diagram UML je specializovaný grafický popisový jazyk určený pro modelování objektů při vývoji různých softwarů. Tento jazyk má široký profil a je otevřeným standardem, ve kterém se používají různé grafické symboly pro vytvoření modelu abstraktního systému. UML byla vytvořena za účelem definování, vizualizace, dokumentace a návrhu různých softwarových systémů. Je třeba poznamenat, že samotný diagram UML není programovacím jazykem, ale také umožňuje generovat samostatný kód založený na něm.

Proč je potřeba?

Použití UML nekončí simulací všech druhů softwaru. Také tento jazyk je dnes aktivně využíván pro modelování různých obchodních procesů, provádění návrhu systému a zobrazení organizačních struktur.

Pomocí softwaru UML mohou vývojáři softwaru poskytnout úplnou shodu v grafické notaci, která slouží k představě běžných pojmů, jako jsou: složka, generalizace, třída, chování a agregace. Díky tomu je dosaženo většího stupně soustředění na architekturu a design.

Je také třeba poznamenat, že existuje několik typů takových diagramů.

Schéma třídy

uml stavový diagram

Schéma třídy UML je statický strukturní diagram určený k popisu struktury systému a prokázání atributů, metod a závislostí mezi několika různými třídami.

Stojí za zmínku skutečnost, že existuje několik názorů na konstrukci takových diagramů, v závislosti na tom, jak budou použity:

  • Konceptuální. V tomto případě diagram třídy UML popisuje model konkrétní oblasti objektu a poskytuje pouze třídy aplikačních objektů.
  • Specifické. Diagram je používán při návrhu různých informačních systémů.
  • Realizace. Schéma třídy zahrnuje všechny druhy tříd, které jsou přímo použity v programovém kódu.

Schéma komponenty

uml diagramu

Diagram komponent UML je zcela statický strukturní diagram. Je určena k prokázání rozdělení určitého softwarového systému do různých konstrukčních prvků, jakož i spojení mezi nimi. Schéma komponenty UML jako takové může používat všechny druhy modelů, knihovny, soubory, balíčky, spustitelné soubory a mnoho dalších prvků.

Kompozitní / kompozitní struktura

Diagram UML kompozitní / kompozitní struktury je také statický strukturní diagram, ale slouží k zobrazení vnitřní struktury tříd. Pokud je to možné, tento diagram může také demonstrovat interakce prvků, které jsou ve vnitřní struktuře třídy.

Podtypem z nich je UML diagram spolupráce, který slouží k prokázání rolí, stejně jako interakce různých tříd v rámci spolupráce. Jsou docela vhodné, pokud chcete simulovat návrhové vzory.

Je třeba poznamenat, že typy grafů UML a strukturovaných struktur lze využít současně.

Graf nasazení

uml diagram aktivity

Tento diagram slouží k modelování pracovních uzlů, stejně jako všech nejrůznějších artefaktů, které byly na nich nasazeny. V UML 2 jsou artefakty nasazeny na různých uzlech, zatímco v první verzi byly nasazeny pouze komponenty. Schéma nasazení UML se tedy používá především pro druhou verzi.

Mezi artefaktem a komponentou, kterou implementuje, vzniká závislost projevu.

Objektový diagram

Tento pohled umožňuje zobrazit úplný nebo částečný snímek vytvořeného systému v určitém okamžiku. Plně zobrazuje všechny instance tříd určitého systému se současnými hodnotami jejich parametrů a také vztahy mezi nimi.

Schéma balíčků

uml použít schéma případů

Tento diagram je strukturální a jeho hlavním obsahem jsou nejrůznější balíky, stejně jako vztah mezi nimi. V tomto případě neexistuje žádné tvrdé dělení mezi několika strukturními diagramy, v důsledku čehož jejich použití je nejčastěji nalezeno výhradně pro pohodlí a samo o sobě nese žádný sémantický význam. Je třeba poznamenat, že různé diagramy UML mohou poskytovat různé prvky (příklady: samotné balíčky a balíčky).

Jejich využití je prováděno s cílem zajistit organizaci několika prvků do skupin na specifickém základě, zjednodušit strukturu a také organizovat práci s modelem tohoto systému.

Graf aktivity

uml diagramu komponent

Schéma aktivity UML zobrazuje rozložení určité aktivity na několik částí. V tomto případě termín "aktivita" označuje specifikaci konkrétního spustitelného chování v podobě paralelního, stejně jako koordinovaného sekvenčního provádění různých podřízených prvků - vnořené typy činností a různé akce kombinované toky z výstupů určitého uzlu na vstupy jiného.

Schéma aktivity UML se často používá k modelování různých obchodních procesů, paralelních a sekvenčních výpočtů. Kromě toho simulují různé technologické postupy.

Grafový stroj

Tento pohled je volán a poněkud jiný - schéma stavu UML. Má státní stroj s jednoduchými a složenými stavy, stejně jako přechody.

Stroj s konečným stavem je specifikací posloupnosti různých stavů, kterými prochází určitý objekt, nebo interakce v reakci na určité události v jeho životě, stejně jako reakce objektu na takové události. Stavový stroj, který používá diagram stavu UML, je přiřazen zdrojovému prvku a slouží k určení chování jeho instancí.

Takto nazvané dračí schémata mohou být použity jako analogy takových diagramů.

Použití schémat případů

uml sekvenčního diagramu

Schéma případů UML představuje všechny vztahy, které vznikají mezi herci, stejně jako různé případy použití. Jeho hlavním úkolem je implementovat kompletní prostředky, pomocí kterých může zákazník, koncový uživatel nebo nějaký vývojář společně diskutovat o chování a funkčnosti určitého systému.

Pokud je v procesu modelování systému použit schéma případů UML, analytik se chystá:

  • Jasně oddělit simulovaný systém od jeho prostředí.
  • Identifikujte herce, jejich interakce s tímto systémem a očekávanou funkcionalitu.
  • Nastavte v glosáři jako předmět různých konceptů, které se týkají podrobného popisu funkčnosti tohoto systému.

Pokud je v UML vytvořen schéma využití, postup začíná textovým popisem, který se získává z práce se zákazníkem. Současně stojí za zmínku skutečnost, že různé nefunkční požadavky při sestavování modelu precedentů jsou zcela vynechány a pro ně bude vytvořen samostatný dokument.

Komunikace

Schéma komunikace, stejně jako schéma sekvence UML, je tranzitivní, to znamená, že vyjadřuje vzájemnou interakci, ale současně ji demonstruje různými způsoby, a pokud je to nezbytné s potřebnou mírou přesnosti, můžete je převést do druhého.

Schéma komunikace odráží interakce mezi různými prvky kompozitní struktury a také role spolupráce. Jeho hlavní rozdíl od sekvenčního diagramu spočívá v tom, že vztahy mezi několika prvky jsou zcela jasné a čas se nepoužívá jako samostatné měření.

Tento typ se vyznačuje naprosto volným formátem pro uspořádání několika objektů a odkazů stejným způsobem jako v diagramu objektů. Pokud je potřeba zachovat pořadí zpráv v tomto volném formátu, provádí se jejich chronologické číslování. Čtení tohoto diagramu začíná počáteční zprávou 1.0 a pokračuje ve směru, ve kterém jsou zprávy přenášeny z jednoho objektu do druhého.

Většina těchto diagramů ukazuje přesně stejnou informaci, jakou poskytuje schéma sekvence, ale protože používá jiný způsob, jak prezentovat informace, je mnohem snazší určit některé věci na jednom diagramu než na jiném. Je také třeba poznamenat, že komunikační schéma jasně ukazuje, které prvky každý jednotlivý prvek interaguje, zatímco schéma sekvence jasně znázorňuje pořadí, ve kterém dochází k interakcím.

Schéma sekvence

uml diagramu třídy

Schéma sekvence UML demonstruje vzájemné působení mezi několika objekty, které jsou uspořádány podle doby, kdy se objevují. Na takovém grafu se zobrazí časově uspořádaná interakce mezi několika objekty. Zejména zobrazuje všechny objekty, které se podílejí na interakci, stejně jako kompletní posloupnost zpráv, které si vyměňují.

Hlavní prvky v tomto případě jsou označení různých objektů, stejně jako vertikální čáry představující průchod času a obdélníků, které poskytují činnost určitého objektu nebo výkon funkce.

Graf spolupráce

Tento typ diagramů umožňuje demonstrovat interakci mezi několika objekty, které odvozují sekvenci vysílání zpráv. Tento typ diagramů v kompaktní podobě sám o sobě odráží absolutně všechna přenášená a přijatá hlášení určitého objektu, stejně jako formáty těchto zpráv.

Vzhledem k tomu, že diagramy sekvence a komunikace jsou jednoduše odlišným pohledem na stejné postupy, Rational Rose poskytuje schopnost vytvářet sekvenci diagramů z komunikace nebo naopak a také provádí plně automatickou synchronizaci.

Přehledy interakcí

Jedná se o diagramy UML, které se vztahují k řadě schémat aktivit a zahrnují jak sekvenční prvky, tak konstrukce řídících toků.

Stojí za zmínku, že tento formát kombinuje schéma Spolupráce a Sekvenční schéma, které poskytují příležitost z různých hledisek, aby zvážily interakci mezi několika objekty v vytvořeném systému.

Schéma synchronizace

Je to alternativní verze sekvenčního diagramu, který explicitně demonstruje změnu stavu na životním řádku se specifickým časovým měřítkem. Může být velmi užitečné v různých aplikacích v reálném čase.

Jaké jsou výhody?

Za zmínku stojí několik výhod, které odlišují schéma použití UML a další:

  • Jazyk je objektově orientovaný, což vede k tomu, že technologie popisující výsledky analýzy a designu jsou sémanticky blízké programovacím metodám ve všech typech objektově orientovaných jazyků moderního typu.
  • Pomocí tohoto jazyka může být systém popsán téměř z jakéhokoli možného hlediska a různé aspekty jeho chování jsou popsány stejným způsobem.
  • Všechny diagramy jsou poměrně snadno čitelné i po poměrně rychlém seznámení se syntaxem.
  • UML vám umožňuje rozšířit i představit své vlastní grafické a textové stereotypy, které přispívají k jeho využití nejen v oblasti softwarového inženýrství.
  • Jazyk je poměrně rozšířený a také se velmi aktivně rozvíjí.

Nevýhody

Navzdory skutečnosti, že konstrukce diagramů UML se liší v množství svých výhod, často jsou kritizováni za následující nevýhody:

  • Redundance. V drtivé většině případů kritici říkají, že UML je příliš velká a složitá a často je to neoprávněné. Obsahuje spoustu nadbytečných nebo téměř zbytečných konstrukcí a diagramů a nejčastěji tato kritika přichází k druhé verzi, a nikoliv k první verzi, protože v novějších revizích existuje větší počet kompromisů "vyvíjených výborem".
  • Různé nepřesnosti sémantiky. Z důvodu toho, že UML je definována kombinací sebe sama, angličtiny a OCL, postrádá tuhost, která je neodmyslitelná v jazycích, které jsou přesně definovány technikou formálního popisu. V určitých situacích se abstraktní syntaxe OCL, UML a angličtiny začínají navzájem odporovat, zatímco v jiných případech jsou neúplné. Nepřesnost popisu samotného jazyka se odráží jak u uživatelů, tak u dodavatelů nástrojů, což nakonec vede k neslučitelnosti nástrojů díky jedinečnému způsobu interpretace různých specifikací.
  • Problémy v procesu implementace a studia. Všechny výše uvedené problémy vytvářejí určité potíže v procesu implementace a studium UML, a to je zvláště pravdivé, když vedení dělá inženýři násilně využívat, zatímco jim chybí předběžné dovednosti.
  • Kód odráží kód. Dalším názorem je, že důležitost není krásných a atraktivních modelů, ale samotných pracovních systémů, tedy kódu je projekt. Podle tohoto stanoviska je třeba vyvinout efektivnější způsob psaní softwaru. UML se obvykle oceňuje v přístupech, které kompilují modely pro regeneraci spustitelného nebo zdrojového kódu. Ale ve skutečnosti to nemusí stačit, protože v tomto jazyce nejsou žádné vlastnosti úplnosti Turingu a každý vygenerovaný kód bude nakonec omezen na to, co může UML tlumočnický nástroj převzít nebo definovat.
  • Nesoulad zatížení Tento termín je odvozen z teorie systémové analýzy, která určuje neschopnost vstupu určitého systému zachytit jiný výstup. Stejně jako u jakéhokoli standardního zápisu, UML může některé systémy představovat efektivněji a stručněji než jiné. Proto je vývojář více nakloněn těm řešením, která jsou pohodlnější pro propojení všech silných stránek UML a dalších programovacích jazyků. Tento problém je zjevnější, pokud jazyk vývoje nevyhovuje základním principům objektově orientované ortodoxní doktríny, to znamená, že se nesnaží pracovat v souladu se zásadami OOP.
  • Snaží se být univerzální. UML je obecný modelovací jazyk, který se snaží zajistit kompatibilitu se stávajícím jazykem zpracování. V kontextu konkrétního projektu, aby projektový tým dosáhl konečného cíle, musíte vybrat příslušné schopnosti tohoto jazyka. Kromě toho možné způsoby omezení rozsahu použití UML v určité oblasti procházejí formalizmem, který není plně artikulován, ale který sám je předmětem kritiky.

Použití tohoto jazyka tedy není relevantní ve všech situacích.