Nástroje pro kreslení UML diagramů. Modelování v UML. Obecné diagramy Příklad diagramů v jazyce uml

UML je jednotný grafický modelovací jazyk pro popis, vizualizaci, navrhování a dokumentaci OO systémů. UML je navrženo tak, aby podporovalo proces modelování softwaru založeného na přístupu OO, organizovalo vztah koncepčních a programových konceptů a odráželo problémy škálování složitých systémů. Modely UML se používají ve všech fázích životního cyklu softwaru, od obchodní analýzy až po údržbu systému. Různé organizace mohou používat UML, jak uznají za vhodné, v závislosti na jejich problémových oblastech a technologiích, které používají.

Stručná historie UML

Do poloviny 90. let navrhli různí autoři několik desítek metod OO modelování, z nichž každá používala svůj vlastní grafický zápis. Navíc každá z těchto metod měla své vlastní silné stránky, ale nedovolil postavit dostatečně úplný model PS, ukažte to „ze všech stran“, tedy všechny potřebné projekce (viz článek 1). Kromě toho, nedostatek OO modelovacího standardu ztěžoval vývojářům výběr nejvhodnější metody, což bránilo širokému přijetí OO přístupu k vývoji softwaru.

Na žádost Object Management Group (OMG), organizace odpovědné za přijímání standardů v oblasti objektových technologií a databází, vyřešili naléhavý problém sjednocení a standardizace autoři tří nejpopulárnějších metod OO - G Butch, D. Rambo a A. Jacobson, kteří společnými silami vytvořili verzi UML 1.1, schválenou OMG v roce 1997 jako standard.

UML je jazyk

Jakýkoli jazyk se skládá ze slovní zásoby a pravidel pro spojování slov za účelem vytvoření smysluplných konstrukcí. Takto jsou strukturovány zejména programovací jazyky, jako je UML. Jeho charakteristickým rysem je, že jazykový slovník je tvořen grafickými prvky. Každý grafický symbol má specifickou sémantiku, takže model vytvořený jedním vývojářem může být jasně srozumitelný pro druhého a také software, interpretující UML. Odtud zejména vyplývá, že softwarový model prezentovaný v UML lze automaticky přeložit do programovacího jazyka OO (jako je Java, C++, VisualBasic), tedy pokud existuje dobrý nástroj pro vizuální modelování, který podporuje UML, postavili model, obdržíme také ukázkový programový kód odpovídající tomuto modelu.

Je třeba zdůraznit, že UML je jazyk, nikoli metoda. Vysvětluje, z jakých prvků vytvářet modely a jak je číst, ale neříká nic o tom, které modely by měly být vyvinuty a v jakých případech. Pro vytvoření metody založené na UML je nutné ji doplnit o popis procesu vývoje softwaru. Příkladem takového procesu je Rational Unified Process, o kterém bude řeč v následujících článcích.

Slovník UML

Model je znázorněn ve formě entit a vztahů mezi nimi, které jsou znázorněny v diagramech.

Entity jsou abstrakce, které jsou hlavními prvky modelů. Existují čtyři typy entit – strukturální (třída, rozhraní, komponenta, případ užití, spolupráce, uzel), behaviorální (interakce, stav), seskupování (balíčky) a anotace (komentáře). Každý typ entity má své vlastní grafické znázornění. Entity budou podrobně probrány při studiu diagramů.

Vztah ukazují různé souvislosti mezi entitami. UML definuje následující typy vztahů:

Závislost ukazuje takové spojení mezi dvěma entitami, kdy změna jedné z nich - nezávislé - může ovlivnit sémantiku té druhé - závislé. Závislost je znázorněna tečkovanou šipkou směřující od závislé entity k nezávislé.
Sdružení je strukturální vztah ukazující, že objekty jedné entity souvisí s objekty druhé. Graficky je asociace zobrazena jako čára spojující asociované entity. Asociace slouží k navigaci mezi objekty. Například spojení mezi třídami „Objednávka“ a „Produkt“ lze použít k nalezení všech produktů specifikovaných v konkrétní objednávce – na jedné straně nebo k nalezení všech objednávek, které mají tento výrobek, - s jiným. Je jasné, že odpovídající programy musí implementovat mechanismus, který takovou navigaci zajistí. Pokud je vyžadována navigace pouze jedním směrem, je to označeno šipkou na konci přidružení. Zvláštním případem asociace je agregace - vztah tvaru „celek“ – „část“. Graficky je zvýrazněn diamantem na konci blízko esence-celu.
Zobecnění je vztah mezi nadřazenou entitou a podřízenou entitou. Tento vztah v podstatě odráží vlastnost dědičnosti pro třídy a objekty. Zobecnění je znázorněno jako čára končící trojúhelníkem směřujícím k mateřské entitě. Dítě zdědí strukturu (atributy) a chování (metody) rodiče, ale zároveň může mít nové prvky struktury a nové metody. UML umožňuje vícenásobnou dědičnost, kdy entita souvisí s více než jednou nadřazenou entitou.
Implementace– vztah mezi entitou, která definuje specifikaci chování (rozhraní) s entitou, která definuje implementaci tohoto chování (třída, komponenta). Tento vztah se běžně používá při modelování součástí a bude podrobněji popsán v následujících článcích.

Diagramy. UML poskytuje následující diagramy:

Diagramy popisující chování systému:

Stavové diagramy
diagramy aktivit,
Schémata objektů,
sekvenční diagramy,
Diagramy spolupráce;

Schémata popisující fyzickou implementaci systému:

Schémata součástí;
Schémata nasazení.

Pohled ovládání modelu. Balíčky.

Již jsme řekli, že aby byl model pro lidi dobře srozumitelný, je nutné jej hierarchicky uspořádat a na každé úrovni hierarchie ponechat malý počet entit. UML zahrnuje prostředky pro organizování hierarchické reprezentace modelu - balíčky. Každý model se skládá ze sady balíčků, které mohou obsahovat třídy, případy použití a další entity a diagramy. Balíček může obsahovat další balíčky, což umožňuje vytváření hierarchií. UML neposkytuje samostatné diagramy balíků, ale mohou se objevit v jiných diagramech. Balíček je vyobrazen jako obdélník se záložkou.

Co nabízí UML.

hierarchický popis komplexního systému identifikací balíčků;
formalizace funkčních požadavků na systém pomocí aparátu případů užití;
podrobný popis požadavků na systém vytvořením diagramů činností a scénářů;
identifikace datových tříd a sestavení koncepčního datového modelu ve formě diagramů tříd;
identifikace tříd, které popisují uživatelské rozhraní a vytvoření schématu navigace na obrazovce;
popis procesů interakce objektů při provádění systémových funkcí;
popis chování objektu formou diagramů aktivit a stavů;
popis softwarových komponent a jejich interakce prostřednictvím rozhraní;
popis fyzické architektury systému.

A poslední věc...

Přes veškerou atraktivitu UML by bylo obtížné jej použít v reálném softwarovém modelování bez nástrojů pro vizuální modelování. Tyto nástroje vám umožňují rychle prezentovat diagramy na obrazovce, dokumentovat je, generovat šablony programového kódu v různých programovacích jazycích OO a vytvářet databázová schémata. Většina z nich zahrnuje možnost reengineeringu programových kódů – obnovení určitých projekcí softwarového modelu automatickou analýzou zdrojových kódů programů, což je velmi důležité pro zajištění shody mezi modelem a kódy a při navrhování systémů, které zdědí funkčnost předchozích systémů.

10.4. DIAGRAMY UML

10.4.1. Typy vizuálních diagramů UML

UML umožňuje vytvářet několik typů vizuálních diagramů:

diagramy případů použití;

Sekvenční diagramy;

Kooperativní grafy;

Diagramy tříd;

Stavové diagramy;

Schémata součástí;

Schémata umístění.

Diagramy ilustrují různé aspekty systému. Například kooperativní diagram ukazuje, jak musí objekty interagovat, aby implementovaly některé funkce systému. Každý diagram má svůj vlastní účel.

10.4.2. Diagramy případů použití

Diagramy případů užití zobrazují interakce mezi případy užití, které představují funkce systému, a aktéry, kteří představují osoby nebo systémy přijímající nebo přenášející informace tento systém. Příklad diagramu případu použití pro bankomat (ATM) je znázorněn na Obr. 10.1.

Rýže. 10.1. Schéma případu použití

Diagram představuje interakce mezi případy užití a aktéry. Odráží systémové požadavky z pohledu uživatele. Případy užití jsou tedy funkce vykonávané systémem a aktéři jsou zainteresované strany ve vztahu k vytvářenému systému. Diagramy ukazují, kteří aktéři zahajují případy užití. Ukazují také, když aktér obdrží informace z případu užití. V podstatě může diagram případu použití ilustrovat systémové požadavky. V našem příkladu klient banky iniciuje různé případy použití: „Výběr peněz z účtu“, „Převod peněz“, „Vložení peněz na účet“, „Ukázat zůstatek“, „Změnit ID číslo“, „Provést platbu“. Zaměstnanec banky může zahájit případ použití Změna identifikačního čísla. Z případu použití „Provést platbu“ je šipka k systému Kredit. Herci mohou být externí systémy, v tomto případě je Kreditní systém zobrazen právě jako aktér - je externí vůči systému bankomatů. Šipka ukazující z případu užití na aktéra označuje, že případ užití poskytuje aktérovi určité informace. V tomto případě případ použití Provést platbu poskytuje Kreditnímu systému informace o platbě kreditní kartou.

Diagramy případů užití mohou poskytnout poměrně dost informací o systému. Tento typ diagramu popisuje celkovou funkčnost systému. Uživatelé, projektoví manažeři, analytici, vývojáři, specialisté na zajištění kvality a kdokoli, kdo se zajímá o systém jako celek, se může podívat na diagramy případů použití, aby pochopili, co má systém dělat.

10.4.3. Sekvenční diagramy

Sekvenční diagramy zobrazují tok událostí, ke kterým dochází v rámci případu užití. Například případ použití „Výběr peněz“ nabízí několik možných sekvencí: výběr peněz, pokus o výběr peněz, když na účtu není dostatek peněz, pokus o výběr peněz pomocí nesprávného identifikačního čísla a některé další. Normální scénář výběru 20 USD z účtu (při absenci problémů, jako je nesprávné identifikační číslo nebo nedostatek prostředků na účtu) je znázorněn na Obr. 10.2.

Obrázek 10.2. Sekvenční diagram pro Joeova klienta, který vybírá 20 $ ze svého účtu

V horní části diagramu jsou zobrazeni všichni aktéři a objekty požadované systémem k provedení případu použití Výběr peněz. Šipky odpovídají zprávám předávaným mezi aktérem a objektem nebo mezi objekty k provedení požadovaných funkcí. Je třeba také poznamenat, že sekvenční diagram zobrazuje objekty, nikoli třídy. Třídy jsou typy objektů. Objekty jsou betonové; místo třídy Klient Sekvenční diagram představuje konkrétního zákazníka, Joe.

Případ užití začíná, když zákazník vloží svou kartu do čtečky – tento objekt je znázorněn v obdélníku v horní části schématu. Přečte číslo karty, otevře objekt Joe Account a inicializuje obrazovku bankomatu. Obrazovka požádá Joea o jeho registrační číslo. Zákazník zadá číslo 1234. Obrazovka zkontroluje číslo proti objektu Joe Account a zjistí, že je správné. Na obrazovce se pak Joeovi zobrazí nabídka, ze které si může vybrat, a vybere „Vybrat peníze“. Obrazovka se zeptá, kolik chce vybrat, a Joe zadá 20 $. Obrazovka vybírá peníze z účtu. Přitom spouští řadu procesů prováděných objektem „Joeův účet“. Zároveň je ověřeno, že tento účet obsahuje dle alespoň, $ 20 a požadovaná částka je odečtena z účtu. Pokladna pak dostane pokyn „vystavit šek a 20 dolarů v hotovosti“. Nakonec stejný objekt „Joeův účet“ dává pokyn čtečce karet, aby kartu vrátila.

Tak, tento diagram sekvence ilustruje sekvenci akcí, které implementují případ použití „Výběr peněz z účtu“ na konkrétním příkladu Joeova klienta, který vybírá 20 USD. Při pohledu na tento diagram se uživatelé seznámí se specifiky své práce. Analytici vidí posloupnost (tok) akcí, vývojáři vidí objekty, které je třeba vytvořit, a jejich operace. Specialisté na kontrolu kvality porozumí detailům procesu a mohou vyvinout testy k jejich ověření. Sekvenční diagramy jsou tedy užitečné pro každého, kdo se podílí na projektu.

10.4.4. Kooperativní diagramy

Kooperativní diagramy odrážejí stejné informace jako sekvenční diagramy. Dělají to však jinak a s jinými cíli. Na Obr. 10.2 sekvenční diagram je uveden na Obr. 10.3 ve formě kooperativního diagramu.

Stejně jako dříve jsou předměty zobrazeny jako obdélníky a postavy jako postavy. Zatímco sekvenční diagram ukazuje interakci mezi herci a objekty v průběhu času, kooperativní diagram nevykazuje žádný vztah v čase. Můžete tedy vidět, že čtečka karet dává pokyn k otevření „Joe's account“ a „Joe's account“ způsobí, že zařízení vrátí kartu majiteli. Přímo interagující objekty jsou spojeny čarami. Pokud například čtečka karet komunikuje přímo s obrazovkou bankomatu, měla by mezi nimi být nakreslena čára. Absence čáry znamená, že mezi objekty neexistuje žádná přímá komunikace.

Rýže. 10.3. Kooperativní diagram popisující proces výběru peněz z účtu

Takže kooperativní diagram zobrazuje stejné informace jako sekvenční diagram, ale je potřeba pro jiný účel. Specialisté na zajištění kvality a systémoví architekti budou schopni porozumět rozložení procesů mezi objekty. Řekněme, že nějaký druh kooperativního diagramu připomíná hvězdu, kde je několik objektů spojeno s jedním centrálním objektem. Architekt systému může dojít k závěru, že systém je příliš závislý na centrální entitě a je třeba ho přepracovat, aby distribuoval procesy rovnoměrněji. V sekvenčním diagramu by tento typ interakce bylo těžké vidět.

10.4.5. Diagramy tříd

Diagramy tříd odrážejí interakce mezi třídami v systému. Například "Joeův účet" je objekt. Typ takového objektu lze obecně považovat za účet, tj. „Účet“ je třída. Třídy obsahují data a chování (akce), které tato data ovlivňují. Třída Účet tedy obsahuje identifikační číslo klienta a akce, které jej ověřují. V diagramu tříd je vytvořena třída pro každý typ objektu ze sekvenčních diagramů nebo kooperativních diagramů. Diagram tříd pro případ použití Výběr peněz je znázorněn na Obr. 10.4.

Diagram ukazuje vztahy mezi třídami, které implementují případ použití Výběr peněz. Tento proces zahrnuje čtyři třídy: čtečka karet, účet, obrazovka bankomatu a automat. Každá třída v diagramu tříd je znázorněna jako obdélník rozdělený na tři části. První část označuje název třídy, druhá - její atributy. Atribut je nějaká informace, která charakterizuje třídu. Například třída Účet má tři atributy: Číslo účtu, PIN a Zůstatek. Poslední část obsahuje operace třídy, odrážející její chování(akce prováděné třídou). Čáry spojující třídy ukazují interakce mezi třídami.

Rýže. 10.4. Diagram tříd

Vývojáři používají diagramy tříd ke skutečnému vytváření tříd. Nástroje jako Rose generují jádro kódu třídy, které programátoři vyplní podrobnostmi v jazyce podle svého výběru. Pomocí těchto diagramů mohou analytici ukázat detaily systému a architekti porozumět jeho návrhu. Pokud například třída nese příliš mnoho funkčního zatížení, bude to vidět v diagramu tříd a architekt to může přerozdělit mezi ostatní třídy. Diagram může také pomoci identifikovat případy, kdy mezi komunikujícími třídami nejsou definovány žádné vztahy. Měly by být vytvořeny diagramy tříd, které ukazují interagující třídy v každém případě použití. Můžete také vytvořit obecnější diagramy, které pokrývají všechny systémy nebo podsystémy.

10.4.6. Stavové diagramy

Stavové diagramy jsou navrženy tak, aby modelovaly různé stavy, ve kterých se objekt může nacházet. Zatímco diagram tříd zobrazuje statický obrázek tříd a jejich vztahů, stavové diagramy se používají k popisu dynamiky chování systému.

Stavové diagramy zobrazují chování objektu. Bankovní účet tedy může mít několik různých stavů. Může být otevřený, uzavřený nebo přečerpaný. Chování účtu se mění v závislosti na stavu, ve kterém se nachází. Stavový diagram ukazuje přesně tuto informaci. Na Obr. Obrázek 10.5 ukazuje příklad stavového diagramu pro bankovní účet.

Rýže. 10.5. Stavový diagram pro třídu Account

Tento diagram ukazuje možné stavy účtu a také proces přechodu účtu z jednoho stavu do druhého. Pokud například klient požádá o uzavření otevřeného účtu, tento přejde do stavu „Uzavřeno“. Požadavek klienta je tzv událost, jsou to události, které způsobují přechod z jednoho stavu do druhého.

Když si zákazník vybere peníze z otevřeného účtu, může se účet dostat do stavu přečerpání. K tomu dochází pouze v případě, že je zůstatek na účtu menší než nula, což se odráží v podmínce [záporný zůstatek] v našem grafu. Uzavřeno v hranatých závorkách stav určuje, kdy může nebo nemůže nastat přechod z jednoho stavu do druhého.

V diagramu jsou dva speciální stavy - počáteční A finále. Počáteční stav je zvýrazněn černou tečkou: odpovídá stavu objektu v době jeho vytvoření. Konečný stav je označen černou tečkou v bílém kruhu: odpovídá stavu objektu bezprostředně před jeho zničením. Ve stavovém diagramu může být jeden a pouze jeden počáteční stav. Přitom konečných stavů může být tolik, kolik potřebujete, nebo nemusí být vůbec žádný.

Když je objekt v určitém stavu, lze provést určité procesy. V našem příkladu je při překročení kreditu klientovi zaslána odpovídající zpráva. Jsou volány procesy, ke kterým dochází, když je objekt v určitém stavu akce.

Stavové diagramy není nutné vytvářet pro každou třídu, používají se pouze ve velmi složitých případech. Pokud objekt třídy může existovat ve více stavech a chová se v každém stavu jinak, bude pravděpodobně potřebovat takový diagram. Mnohé projekty je však vůbec nevyužívají. Pokud byly vytvořeny stavové diagramy, mohou je vývojáři použít při vytváření tříd.

Stavové diagramy jsou potřeba hlavně pro dokumentaci.

10.4.7. Schémata součástí

Schémata komponent ukazují, jak model vypadá fyzické úrovni. Ukazuje komponenty software váš systém a spojení mezi nimi. Existují dva typy komponent: spustitelné komponenty a knihovny kódů.

Na Obr. Obrázek 10.6 ukazuje jeden z diagramů komponent pro ATM systém. Tento diagram ukazuje součásti klienta systému ATM. V tomto případě se vývojový tým rozhodl postavit systém pomocí jazyka C++. Každá třída má svůj vlastní soubor záhlaví a soubor rozšíření. CPP, takže každá třída je v diagramu transformována na své vlastní komponenty. Volá se vybraná tmavá složka specifikace balíčku a odpovídá souboru těla třídy ATM v C++ (soubor s příponou .CPP). Nevybraná komponenta se také nazývá specifikace balíčku, ale odpovídá souboru záhlaví třídy jazyka C++ (soubor s příponou .H). součást bankomatu. EXE je specifikace úlohy a představuje tok zpracování informací. V tomto případě je podprocesem zpracování spustitelný program.

Komponenty jsou spojeny přerušovanou čarou, která představuje závislosti mezi nimi. Systém může mít více diagramů součástí v závislosti na počtu subsystémů resp spustitelné soubory. Každý subsystém je balíček komponent.

Schémata komponent používají ti účastníci projektu, kteří jsou zodpovědní za sestavení systému. Diagram komponent poskytuje představu o pořadí, ve kterém by měly být komponenty zkompilovány, a také o tom, které spustitelné komponenty budou systémem vytvořeny. Diagram ukazuje mapování tříd na implementované komponenty. Je tedy potřeba tam, kde začíná generování kódu.

Rýže. 10.6. Schéma součásti

10.4.8. Schémata umístění

Schémata rozložení ukazují fyzické umístění různých součástí systému v síti. V našem příkladu se systém ATM skládá z velkého počtu subsystémů běžících na samostatných fyzických zařízeních nebo uzlech. Schéma umístění pro ATM systém je na Obr. 10.7.

Z tohoto diagramu se můžete dozvědět o fyzickém uspořádání systému. Klientské programy ATM poběží na více místech na více místech. Klienti budou komunikovat s regionálním ATM serverem prostřednictvím uzavřených sítí. Bude spouštět software serveru ATM. Na druhou stranu, skrz lokální síť regionální server bude komunikovat s bankovním databázovým serverem, na kterém běží Oracle. Nakonec je tiskárna připojena k regionálnímu ATM serveru.

Tento diagram tedy ukazuje fyzické uspořádání systému. Náš ATM systém má například třívrstvou architekturu, přičemž databáze na první vrstvě, regionální server na druhé a klient na třetí.

10.7. Schéma umístění

Schéma uspořádání používá projektový manažer, uživatelé, systémový architekt a provozní personál k objasnění fyzického uspořádání systému a umístění jeho jednotlivých subsystémů. Projektový manažer vysvětlí uživatelům, jak bude hotový produkt vypadat. Provozní pracovníci budou moci plánovat instalační práce systému.

Z knihy Microsoft Office autor Leontyev Vitalij Petrovič

Grafy Čísla v tabulce vám vždy neumožňují získat úplný dojem, i když jsou setříděna pro vás nejpohodlněji. Pomocí těch dostupných od společnosti Microsoft Excel šablony diagramy, můžete získat jasný obrázek o datech ve vaší tabulce, a nikoli

Z knihy Počítač za 100. Začněme s Windows Vista autor Zozulya Yuri

Grafy Grafy se používají k prezentaci tabulkových dat grafické podobě, které mohou výrazně zlepšit viditelnost informací, ukázat vztah mezi různými parametry nebo dynamiku jejich změny. Chcete-li vložit diagramy do aplikace Word, použijte nástroje

Z knihy Efektivní kancelářská práce autor Ptašinskij Vladimír Sergejevič

Diagramy Nejvizuálnější Schopnost Excelu je prezentace výsledků výpočtů nebo nashromážděných dat ve formě grafů (diagramů): někdy nejpůsobivější čísla nejsou schopna přesvědčit tak, jak to lze provést ani pomocí jednoduché grafiky. Excel má

Z excelového sešitu. Multimediální kurz autor Medinov Oleg

Kapitola 8 Diagramy Často Excel program slouží k vytváření dokumentů představujících různé statistické a analytické zprávy. Mohou to být zprávy o prodeji, tabulky měření teploty vzduchu, údaje ze sociologických průzkumů atd. Čísla nejsou vždy

Z knihy Word 2007. Populární návod autor Krainsky I

Vytvoření grafu Pro první příklad budete muset vytvořit tabulku zobrazenou na Obr. 8.1. Rýže. 8.1. Tabulka měření teplotyNa základě údajů v této tabulce sestrojíme jednoduchý graf teplotních změn.1. Vyberte vyplněný rozsah v tabulce.2. Jít do

Z knihy Vlastní návod k práci na počítači autor Kolisničenko Denis Nikolajevič

6.6. Diagramy S výjimkou grafické soubory, V Word dokumenty můžete vkládat diagramy. Pomocí diagramů můžete vizuálně prezentovat číselná data, například sledovat, jak se data mění, vidět vývoj konkrétního projektu v čase. Diagramy jsou podobné

Z knihy Objektově orientovaná analýza a návrh s příklady aplikací v C++ od Butche Gradyho

14.9. Diagramy Možná je čas přeměnit suchá čísla na grafiku, díky níž bude náš stůl krásnější a informativnější? K tomu slouží diagramy. Ať už říkáte cokoli, diagram je vnímán lépe než tabulka. Chcete-li vytvořit diagram, musíte vybrat hodnoty, podle kterých

Z knihy Programovací technologie autor Kamaev V A

5.2. Základní diagramy tříd: Třídy a jejich vztahy Diagram tříd zobrazuje třídy a jejich vztahy, čímž představuje logický aspekt návrhu. Samostatný diagram tříd představuje konkrétní pohled na strukturu tříd. Ve fázi analýzy jsme

Z knihy Modelování obchodních procesů s BPwin 4.0 autor Maklakov Sergej Vladimirovič

5.4. Základní schémata objektů: Objekty a jejich vztahy Diagram objektů zobrazuje existující objekty a jejich vztahy v logickém návrhu systému. Jinými slovy, objektový diagram je snímek toku událostí v nějaké konfiguraci

Z knihy OrCAD PSpice. Analýza elektrické obvody od Keowna J.

5.7. Procesní diagramy. Základní: Procesory, zařízení a připojení Procesní diagramy se používají k zobrazení rozložení procesů mezi procesory ve fyzickém návrhu systému. Samostatný procesní diagram ukazuje jeden pohled na procesní strukturu

Z knihy VBA for Dummies od Steve Cummings

10.4. DIAGRAMY UML 10.4.1. Typy vizuálních diagramů UMLUML umožňuje vytvářet několik typů vizuálních diagramů: diagramy případů použití; sekvenční diagramy; kooperativní diagramy; diagramy tříd; stavové diagramy; diagramy

Z knihy Vlastní návod k práci na Macintoshi autor Sofia Skrylina

1.2.6. Rámeček diagramu Na Obr. Obrázek 1.2.26 ukazuje typický příklad dekompozičního diagramu s ohraničujícími rámečky nazývaný rámec diagramu. Rýže. 1.2.26. Příklad dekompozičního diagramu s drátěným modelem. Drátový model obsahuje nadpis ( nejlepší část rámy) a suterén (spodní část).

Z autorovy knihy

Časové diagramy Chcete-li získat časové diagramy vstupního a výstupního napětí, musíte mírně upravit vstupní soubor. Stejně jako v předchozím příkladu bude použito sinusové vstupní napětí: Vi 1 0 sin (0 0, 5 V 5 kHz) Spolu s analýzou přechodových jevů

Z autorovy knihy

Grafy a grafy Význam za nekonečnými řadami čísel může rozeznat pouze odborník, ale histogramu nebo koláčovému grafu může porozumět (nebo alespoň tvrdit, že rozumí) každý. VBA nemá vestavěné nástroje pro tvorbu diagramů, ale např

Z autorovy knihy

5.1.14. Grafy Grafy jsou grafickým znázorněním číselných dat v tabulce. Stránky nabízí několik typů grafů: sloupcový, skládaný sloupec, sloupcový graf, skládaný pruhový graf, čárový, plošný, skládaný

Z autorovy knihy

5.2.8. Grafy Graf je grafické znázornění dat z vybraného rozsahu. Chcete-li sestavit graf, postupujte podle následujícího algoritmu1. Vytvořte tabulku vypočtených hodnot.2. Vyberte požadovaný rozsah (může sestávat z nesousedícího obdélníku

Myslím, že každý v dětství slyšel takové rčení jako " Sedmkrát měř, jednou řež". V programování je to stejné. Vždy je lepší si implementaci promyslet, než strávíte čas jejím prováděním. Při implementaci musíte často vytvářet třídy a vymýšlet jejich interakci. A často vám může pomoci vizuální reprezentace vyřešit problém tím nejsprávnějším způsobem. Zde pomáháme UML.

Co je UML?

Pokud se podíváte na obrázky v vyhledávače, pak bude jasné, že UML– je to něco o diagramech, šipkách a čtvercích. Důležité je, že UML se překládá jako Unifikovaný Modelovací Jazyk. Důležité je zde slovo Unified. To znamená, že našim obrázkům porozumíme nejen my, ale i ostatní, kteří znají UML. Ukazuje se, že se jedná o mezinárodní jazyk pro kreslení diagramů.

Jak říká Wikipedie

UML je grafický popisný jazyk pro objektové modelování při vývoji softwaru, modelování obchodních procesů, návrhu systémů a zobrazování organizačních struktur.

Nejzajímavější věcí, o které ne každý přemýšlí nebo si ji neuvědomuje, je, že UML má specifikace. Navíc existuje dokonce specifikace UML2. Více podrobností o specifikaci lze nalézt na webu Object Management Group. Ve skutečnosti tato skupina vyvíjí specifikace UML. Zajímavé také je, že UML se neomezuje pouze na popis struktury tříd. Existuje mnoho typů UML diagramů. Stručný popis typů UML diagramů lze vidět ve stejné Wikipedii: UML - diagramy nebo ve videu Timura Batyršinova Přehled diagramů UML. UML se také široce používá k popisu různých procesů, například zde: Single sign-on using JWT. Pokud se vrátíme k použití diagramů tříd UML, stojí za zmínku kniha Head First: Design Patterns, ve které jsou vzory ilustrovány stejnými diagramy UML. Ukazuje se, že UML se skutečně používá. A ukazuje se, že znalost a pochopení její aplikace je docela užitečná dovednost.

aplikace

Podívejme se, jak můžete pracovat se stejným UML z IDE. Vezměme jako IDE IntelliJ nápad. Pokud použijete IntelliJ Idea Ultimate, poté budeme mít plugin nainstalován „z krabice“ Podpora UML". Umožňuje automaticky generovat krásné diagramy tříd. Například přes Ctrl+N nebo položku nabídky "Navigovat" -> "Třída" přejdeme do třídy ArrayList. Nyní v kontextové nabídce pro název třídy vyberte „Diagram“ -> „Zobrazit vyskakovací okno diagramu“. Výsledkem je krásný diagram:

Ale co když to chcete nakreslit sami, a i když ne Ultimate verze Idea? Pokud použijeme IntelliJ Idea Community Edition, pak nemáme jinou možnost. Chcete-li to provést, musíte pochopit, jak je takový diagram UML strukturován. Nejprve musíme nainstalovat Graphviz. Jedná se o sadu nástrojů pro vizualizaci grafů. Používá ho plugin, který budeme používat. Po instalaci je potřeba přidat adresář zásobník z nainstalovaného adresáře Graphviz na proměnnou prostředí CESTA. Poté v IntelliJ Idea vyberte z nabídky Soubor -> Nastavení. V okně „Nastavení“ vyberte kategorii „Pluginy“, klikněte na tlačítko „Procházet repozitáře“ a nainstalujte integrační plugin PlantUML. Proč je tenhle tak dobrý? PlantUML? Používá jazyk pro popis grafů nazvaný " tečka"a to mu umožňuje být univerzálnější, protože... daný jazyk Používá se nejen PlantUML. Navíc vše, co děláme níže, lze dělat nejen v IDE, ale také v služba online planttext.com. Po instalaci pluginu PlantUML budeme moci vytvářet diagramy UML pomocí „Soubor“ -> „Nový“. Vytvořme diagram typu „UML class“. Během tohoto procesu se automaticky vygeneruje šablona s příkladem. Smažte jeho obsah a vytvořte si vlastní, vyzbrojený článkem od Habra: Vztahy tříd – od UML po kód. A abychom pochopili, jak to v textu znázornit, vezmeme si příručku PlantUML: diagram tříd plantuml. Na samém začátku je tabulka ukazující, jak by měla být připojení popsána:

Můžeme se také podívat na samotná spojení zde: "Vztahy mezi třídami v UML. Příklady." Na základě těchto materiálů začněme vytvářet náš UML diagram. Přidejme následující obsah popisující obě třídy: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Chcete-li vidět výsledek v Idea, vyberte "Zobrazit" -> " Nástrojová okna" -> "PlantUML". Jednoduše dostaneme dva čtverce označující třídy. Jak víme, obě tyto třídy implementují rozhraní List. Tento vztah třídy se nazývá implementace. Chcete-li takový vztah znázornit, použijte šipku s tečkovaná čára. Pojďme si to znázornit: rozhraní Seznam Seznam< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о soukromý balíček pole prvků: ~ Object elementData Nyní chceme ukázat, že ArrayList obsahuje nějaké objekty. V tomto případě bude typ připojení - agregace(agregace). Agregát je v tomto případě ArrayList, protože obsahuje další předměty. Vybíráme agregaci, protože objekty v seznamu mohou žít bez seznamu: nejsou jeho nedílnou součástí. Jejich životnost není vázána na životnost seznamu. Agregát se z latiny překládá jako „shromážděný“, tedy něco složeného z něčeho. Například v životě existuje čerpací jednotka, která se skládá z čerpadla a motoru. Samotnou jednotku lze rozebrat a část z ní zůstane komponenty. Například prodat nebo vložit do jiné jednotky. Stejně tak seznam. A to je vyjádřeno ve formě prázdného kosočtverce poblíž jednotky a souvislé čáry. Znázorněme to následovně: třída Object ( ) ArrayList o- Object Nyní chceme ukázat, že na rozdíl od ArrayList třída LinkedList obsahuje Node - kontejnery, které odkazují na uložená data. V tomto případě jsou uzly součástí samotného LinkedList a nemohou žít odděleně. Node obsah přímo neukládá, ale obsahuje pouze odkaz na něj. Když například přidáme řádek do LinkedList, přidáme nový uzel, který obsahuje odkaz na tento řádek a také odkaz na předchozí a následující uzel. Tento typ připojení se nazývá složení(Složení). Pro zobrazení kompozitu (který se skládá z částí) se nakreslí barevný kosočtverec, k němuž vede souvislá čára. Pojďme si to nyní napsat ve formě textového zobrazení spojení: class Node ( ) LinkedList * -- Node A teď se musíme naučit, jak zobrazit další důležitý typ komunikace - závislost(vztah závislosti). Používá se, když jedna třída používá jinou a třída neobsahuje používanou třídu a není jejím potomkem. Například LinkedList a ArrayList mohou vytvořit ListIterator. Zobrazme to jako šipky s tečkovanou čarou: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Můžete jít do tolika detailů, kolik je potřeba. Všechna označení jsou uvedena zde: "PlantUML - Class Diagram". Navíc na kreslení takového diagramu není nic nadpřirozeného a při práci na svých úkolech ho můžete rychle nakreslit ručně. To rozvine vaše dovednosti v promýšlení aplikační architektury a pomůže vám identifikovat nedostatky ve struktuře tříd brzy, spíše než poté, co jste strávili den implementací špatného modelu. Myslím, že je to dobrý důvod to zkusit?)

Automatizace

Jíst různé cesty automatické generování PlantUML diagramů. Například v Idea Existuje plugin SketchIT, ale ten je nekreslí úplně správně. Například implementace rozhraní je nakreslena nesprávně (zobrazeno jako dědičnost). Na internetu jsou také příklady, jak to zabudovat životní cyklus budování vašeho projektu. Řekněme pro Maven existuje příklad použití uml-java-docklet. Abychom ukázali, jak se to dělá, použijeme Maven Archetype to rychlá tvorba Projekt Maven. Spusťte příkaz: mvn archetype:generate Na otázku výběru filtru ( Vyberte číslo nebo použijte filtr) opustíte výchozí nastavení pouhým stisknutím klávesy Enter. Vždy to bude" maven-archetype-quickstart". Vyberte nejnovější verzi. Dále odpovězte na otázky a dokončete vytvoření projektu:

Vzhledem k tomu, že Maven není středem zájmu tohoto článku, odpovědi na své otázky týkající se Maven naleznete v uživatelském centru Maven. Ve vygenerovaném projektu otevřete soubor s popisem projektu pro úpravy, pom.xml. Zkopírujeme do něj obsah z popisu instalace uml-java-docklet. Artefakt použitý v popisu nebylo možné najít v úložišti Maven Central. Ale fungovalo mi to s tímto: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. To znamená, že stačí nahradit v tomto popisu groupId s " info.leadinglight"zapnuto" com.chfourie"a nainstalovat verzi" 1.0.0 ". Poté můžeme spustit v adresáři, kde je umístěn soubor pom.xml tyto příkazy: mvn clean install a mvn javadoc:javadoc . Nyní, když otevřeme vygenerovanou dokumentaci (explorer target\site\apidocs\index.html), uvidíme diagramy UML. Mimochodem, implementace je zde již zobrazena správně)

Závěr

Jak můžete vidět, UML vám umožňuje vizualizovat strukturu vaší aplikace. Navíc UML není omezeno pouze na toto. Pomocí UML můžete popsat různé procesy ve vaší společnosti nebo popsat obchodní proces, ve kterém funguje funkce, kterou píšete. Jak užitečné je UML pro vás osobně, je na vás, abyste se rozhodli, ale v každém případě bude užitečné věnovat čas jeho podrobnějšímu přečtení. #Viacheslav Anglická verze tohoto příspěvku: UML diagram Java na CodeGym

Anotace: Předmětem tohoto kurzu je UML - jednotný modelovací jazyk. Předchozí přednáška hovořila o tom, co je UML, jeho historii, účelu, způsobech použití jazyka, struktuře jeho definice, terminologii a zápisu. Bylo poznamenáno, že model UML je sada diagramů. V této přednášce se budeme zabývat následujícími otázkami: proč je potřeba několik typů diagramů; typy diagramů; OOP a posloupnost diagramů

Než přejdeme k probírání hlavního materiálu této přednášky, promluvme si o tom, proč vůbec potřebujeme nějaké diagramy stavět. Vývoj modelu jakéhokoli systému (nejen softwarového) vždy předchází jeho vytvoření nebo aktualizaci. To je nutné alespoň pro jasnější představu o řešeném problému. Dobře promyšlené modely jsou velmi důležité jak pro interakci v rámci vývojového týmu, tak pro vzájemné porozumění se zákazníkem. V konečném důsledku to zajišťuje, že návrh je „architektonicky konzistentní“ před implementací do kódu.

Vytváříme modely složitých systémů, protože je nemůžeme úplně popsat, „podívat se na ně“. Zvýrazňujeme proto pouze vlastnosti systému, které jsou pro konkrétní úlohu zásadní, a sestavujeme jeho model, který tyto vlastnosti zobrazuje. Metoda objektově orientované analýzy nám umožňuje popsat skutečné komplexní systémy tím nejvhodnějším způsobem. Ale jak se zvyšuje složitost systémů, vyvstává potřeba dobré modelovací technologie. Jak jsme již řekli v předchozí přednášce, jednotný modelovací jazyk(Unified Modeling Language, UML), což je grafický jazyk pro specifikaci, vizualizaci, navrhování a dokumentaci systémů. Pomocí UML můžete vyvinout detailní model vytvářeného systému, odrážející nejen jeho koncepci, ale i specifické rysy jeho implementace. V rámci modelu UML jsou všechny představy o systému zaznamenávány ve formě speciálních grafických struktur nazývaných diagramy.

Poznámka. Budeme uvažovat ne všechny, ale pouze některé typy diagramů. Například schéma komponent není v této přednášce zahrnuto, což je pouze stručný přehled typy diagramů. Počet typů grafů pro konkrétní model aplikace nejsou nijak omezeny. Pro jednoduché aplikace není třeba vytvářet diagramy všech typů bez výjimky. Některé z nich mohou jednoduše chybět a tato skutečnost nebude považována za chybu. Je důležité pochopit, že dostupnost určitých typů diagramů závisí na specifikách konkrétního projektu. Informace o dalších typech diagramů (zde nediskutovaných) lze nalézt ve standardu UML.

Proč potřebujete několik typů diagramů

Nejprve si definujme terminologii. V úvodu této přednášky jsme opakovaně použili pojmy systém, model a diagram. Autor je přesvědčen, že každý z nás intuitivně chápe význam těchto pojmů, ale aby to bylo zcela jasné, podívejme se znovu do glosáře a přečtěte si následující:

Systém- soubor vzájemně propojených řízených subsystémů spojených společným účelem provozu.

Ano, málo informativní. Co je tedy subsystém? Abychom objasnili situaci, pojďme ke klasice:

Systém odkazuje na soubor subsystémů organizovaných k dosažení konkrétního cíle a popsaných pomocí sady modelů, případně z různých úhlů pohledu.

No nedá se nic dělat, budete muset hledat definici subsystému. Taky se tam píše subsystému je kolekce prvků, z nichž některé určují chování jiných prvků. Ian Sommerville vysvětluje tento koncept takto:

Subsystém je systém, jehož fungování není závislé na službách jiných subsystémů. Softwarový systém je strukturován jako soubor relativně nezávislých subsystémů. Jsou také definovány interakce mezi subsystémy.

Taky to není moc jasné, ale je to lepší. Řečeno „lidskou“ řečí, systém je reprezentován jako soubor jednodušších entit, které jsou relativně soběstačné. To lze přirovnat k tomu, jak v procesu vývoje programu vytváříme GUI ze standardních „kostek“ - vizuálních komponent, aneb jak je i samotný text programu rozdělen do modulů, které obsahují podprogramy, sjednocené funkčností a lze je znovu použít v dalších programech.

Rozumíme konceptu systému. Během procesu návrhu je systém zvažován z různých úhlů pohledu pomocí modelů, jejichž různé reprezentace se objevují ve formě diagramů. Čtenář může mít opět otázky ohledně významu pojmů modely A diagramy. Myslíme si, že je to krásná, ale nepříliš jasná definice modely jako sémanticky uzavřená abstrakce systému Je nepravděpodobné, že by to objasnilo situaci, takže se pokusíme vysvětlit „vlastními slovy“.

Modelka- jedná se o určitý (materiálový nebo nehmotný) objekt, který zobrazuje pouze nejvýznamnější charakteristiky systému pro danou úlohu. Modely jsou různé - materiální i nehmotné, umělé i přírodní, dekorativní i matematické...

Uveďme si pár příkladů. Nám všem známá plastová autíčka, se kterými jsme si v dětství s takovým nadšením hráli, nejsou nic jiného než materiál umělý dekor model skutečného auta. Takové „auto“ samozřejmě nemá motor, neplníme jeho nádrž benzínem a převodovka nefunguje (opravdu žádná převodovka není), ale jako model tato hračka zcela plní své funkce : dává dítěti představu o autě, protože jeho charakteristické rysy jsou přítomnost čtyř kol, karoserie, dveří, oken, schopnost řídit atd.

V lékařském výzkumu testování na zvířatech často předchází klinickým testům na lidech. V tomto případě se zvíře chová jako přírodní materiál lidské modely.

Výše uvedená rovnice je také model, ale je to matematický model a popisuje pohyb hmotného bodu vlivem gravitace.

Nezbývá než říci, co je to diagram. Diagram je grafické znázornění mnoha prvků. Typicky se zobrazuje jako graf s vrcholy (entity) a hranami (vztahy). Existuje mnoho příkladů diagramů. Jedná se o blokové schéma známé nám všem ze školních let a instalační schémata pro různá zařízení, která můžeme vidět v uživatelských příručkách, a strom souborů a adresářů na disku, který můžeme vidět spuštěním konzole Windows stromový příkaz a mnohem, mnohem více. V běžném životě nás diagramy obklopují ze všech stran, protože kresby vnímáme snadněji než text...

Ale vraťme se k návrhu softwaru (a dalším). V tomto odvětví s Diagramy lze použít k vizualizaci systému z různých perspektiv. Jeden z diagramů může například popisovat interakci uživatele se systémem, další může popisovat změnu stavů systému během jeho provozu, třetí může popisovat interakci prvků systému mezi sebou atd. Komplexní systém může a měl by být reprezentován jako soubor malých a téměř nezávislých modelů - diagramů a žádný z nich nestačí k popisu systému a získání jeho úplného obrazu, protože každý z nich se zaměřuje na určitý aspekt fungování systému a vyjadřuje rozdíl úroveň abstrakce. Jinými slovy, každý model odpovídá určitému konkrétnímu úhlu pohledu na navržený systém.

Navzdory skutečnosti, že v předchozím odstavci jsme s pojmem model zacházeli velmi volně, je třeba chápat, že v kontextu výše uvedených definic žádný jednotlivý diagram není model. Diagramy jsou pouze prostředkem k vizualizaci modelu a tyto dva pojmy je třeba rozlišovat. Pouze sada diagramů tvoří model systému a popisuje to nejúplněji, ale ne pouze jeden diagram vytržený z kontextu.

Typy grafů

Definováno UML 1.5 dvanáct typů grafů, rozdělené do tří skupin:

čtyři typy diagramů představují statickou strukturu aplikace;
pět představuje behaviorální aspekty systému;
tři představují fyzické aspekty fungování systému (implementační diagramy).

Aktuální verze UML 2.1 příliš změn neprovedla. Diagramy se mírně změnily ve vzhledu (objevily se rámečky a další vizuální vylepšení), mírně se zlepšil zápis a některé diagramy dostaly nová jména.

Nicméně přesné číslo kanonické diagramy pro nás je to naprosto nedůležité, protože nebudeme uvažovat všechny, ale jen některé - z toho důvodu, že počet typů diagramů pro konkrétní model konkrétní aplikace není striktně stanoven. Pro jednoduché aplikace není potřeba sestavovat každý jednotlivý diagram. Například pro lokální aplikaci není nutné sestavit diagram nasazení. Je důležité pochopit, že seznam diagramů závisí na specifikách vyvíjeného projektu a je určen samotným vývojářem. Pokud by zvídavý čtenář přesto chtěl vědět o všech UML diagramech, odkážeme ho na standard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Připomeňme, že účelem tohoto kurzu není popsat absolutně všechny možnosti UML, ale pouze tento jazyk představit a dát prvotní představu o této technologii.

Stručně se tedy podíváme na takové typy diagramů, jako jsou:

schéma případu použití;
diagram tříd;
objektový diagram;
sekvenční diagram;
diagram interakce;
stavový diagram;
diagram aktivit;
schéma nasazení.

O některých z těchto diagramů budeme hovořit podrobněji v příštích přednáškách. Prozatím se nezaměříme na detaily, ale dáme si za cíl naučit čtenáře alespoň vizuálně rozlišovat mezi typy diagramů a dát si prvotní představu o účelu hlavních typů diagramů. Takže, začněme.

Schéma případu použití

Jakékoli (včetně softwarových) systémů jsou navrženy s ohledem na skutečnost, že během svého provozu budou používány lidmi a/nebo interagovat s jinými systémy. Volají se entity, se kterými systém při své činnosti interaguje herci a každý aktér očekává, že se systém bude chovat přesně definovaným a předvídatelným způsobem. Zkusme podat přísnější definici ektoru. K tomu nám poslouží nádherný vizuální slovník pro UML Zicom Mentor:

Ector (herec)- jedná se o soubor logicky souvisejících rolí vykonávaných při interakci s precedenty nebo entitami (systém, subsystém nebo třída). Aktérem může být osoba nebo jiný systém, subsystém nebo třída, která představuje něco mimo entitu.

Graficky je ektor znázorněn buď " mužíček“, podobné těm, které jsme kreslili jako děti, zobrazující členy naší rodiny, popř symbol třídy s odpovídajícím stereotypem, jak je znázorněno na obrázku. Obě formy zobrazení mají stejný význam a lze je použít v diagramech. „Stereotypní“ forma se častěji používá k reprezentaci systémových aktérů nebo v případech, kdy má aktér vlastnosti a je třeba je zobrazit (obr. 2.1).

Pozorný čtenář se může okamžitě zeptat: proč herec a ne herec? Souhlasíme, slovo „ektor“ je pro uši Rusů trochu drsné. Důvod, proč to říkáme, je jednoduchý – ector je odvozeno od slova akce, což v překladu znamená akce. Doslovný překlad slova „ector“ je herec- příliš dlouhé a nepohodlné použití. Proto budeme i nadále mluvit tímto způsobem.

Rýže. 2.1.

Tentýž pozorný čtenář si mohl všimnout slova „precedent“, které probleskovalo ektorovou definicí. Co je to? Tato otázka nás bude zajímat ještě více, pokud si vzpomeneme, že o ní nyní mluvíme schéma případu použití. Tak,

Případ použití- popis samostatného aspektu chování systému z pohledu uživatele (Butch).

Definice je zcela jasná a obsáhlá, ale lze ji dále objasnit pomocí téhož Zicom Mentor"om:

Případ použití- popis souboru sekvenčních událostí (včetně možností) prováděných systémem, které vedou k výsledku pozorovanému aktérem. Případ užití představuje chování entity a popisuje interakci mezi aktéry a systémem. Případ užití neukazuje „jak“ je dosaženo určitého výsledku, pouze „co“ je dosaženo.

Precedenty jsou označeny velmi jednoduchým způsobem - ve formě elipsy, uvnitř které je naznačen její název. Případy užití a aktéři jsou propojeni pomocí čar. Často je na jednom konci čáry nakreslena postava. 2.3

tvorba obecných požadavků na chování navrženého systému;

vypracování koncepčního modelu systému pro jeho následné detailování;

příprava dokumentace pro interakci se zákazníky a uživateli systému.

11.1. Struktura jednotného modelovacího jazyka

Unifikovaný Modelovací Jazyk (UML) je v současnosti de facto standardem pro popis (dokumentaci) výsledků návrhu a vývoje objektově orientovaných systémů. Vývoj UML zahájili v roce 1994 Grady Booch a James Rumbaugh, kteří pracovali ve společnosti Rational Software. Na podzim 1995 se k nim přidal Ivar Jacobson a v říjnu téhož roku vyšla předběžná verze 0.8 Unified Method. Od té doby bylo vydáno několik verzí specifikace UML, z nichž dvě mají status mezinárodního standardu:

UML 1.4.2 – „ISO/IEC 19501:2005. Informační technologie. Otevřené distribuční zpracování. Unified Modeling Language (UML). Verze 1.4.2" (anglicky "Information technology. Open distribution processing. Unified modeling language (UML). Verze 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informační technologie. Sjednocený modelovací jazyk skupiny pro správu objektů (OMG UML). Část 1. Infrastruktura" (angl. "Informační technologie -- Jednotný modelovací jazyk skupiny pro správu objektů ( OMG UML) - Část 1: Infrastruktura") a "ISO/IEC 19505-2:2012. Informační technologie. Sjednocený modelovací jazyk skupiny pro správu objektů (OMG UML). Část 2. Nadstavba" (angl. "Informační technologie -- Skupina správy objektů Unified Modeling Language (OMG UML) – Část 2: Nadstavba“).

Nejnovější oficiální jazykové specifikace lze nalézt na www.omg.org.

Obecná struktura UML je znázorněna na následujícím obrázku.

Rýže. 11.1. Struktura UML

11.2. Sémantika a syntaxe UML

Sémantika - obor lingvistiky, který studuje význam jazykových jednotek, především jeho slov a frází.

Syntax – způsoby spojování slov a jejich tvarů do slovních spojení a vět, spojování vět do souvětí, způsoby vytváření výroků jako součásti textu.

Ve vztahu k UML tedy sémantika a syntaxe určují styl prezentace (budování modelu), který kombinuje přirozené a formální jazyky k reprezentaci základních pojmů (prvků modelu) a mechanismů pro jejich rozšíření.

11.3. Notace UML

Notace je grafická interpretace sémantiky pro její vizuální reprezentaci.

UML definuje tři typ entity :

Strukturální - abstrakce, která je odrazem konceptuálního nebo fyzického objektu;

Seskupování – prvek používaný pro nějakou sémantickou kombinaci prvků diagramu;

Vysvětlující (poznámkový) – komentář k prvku diagramu.

Následující tabulka ukazuje Stručný popis hlavní entity používané v grafickém zápisu a hlavní způsoby jejich zobrazení.

Tabulka 11.1. Entity

Typ	název	Označení	Definice (sémantika)
Strukturální	(třída)		Mnoho objektů, které mají obecná struktura a chování
	(objekt)		Abstrakce skutečné nebo imaginární entity s jasně definovanými pojmovými hranicemi, osobností, stavem a chováním. Z pohledu UML jsou objekty instancemi třídy (instance entity)
	(herec)	Inženýr služby cest	Entita mimo systém, která interaguje se systémem a používá jej funkčnost k dosažení určitých cílů nebo řešení konkrétních problémů. Tedy herec vnější zdroj nebo přijímač informací
	(případ užití)		Popis akcí prováděných systémem, které vedou k významnému výsledku pro aktéra
	(Stát)		Popis okamžiku v životě entity, kdy splňuje nějakou podmínku, vykonává nějakou činnost nebo čeká, až nastane nějaká událost.
	Spolupráce (spolupráce)		Popis souboru instancí aktérů, objektů a jejich interakce v procesu řešení určitého problému
	(komponent)		Fyzická část systému (soubor), včetně systémových modulů, které zajišťují implementaci konzistentní sady rozhraní
	(rozhraní)	iVýpočet	Sada operací, která definuje službu (množinu služeb) poskytovanou třídou nebo komponentou
	(uzel)		Fyzická část systému (počítač, tiskárna atd.), která poskytuje prostředky k řešení problému
Seskupování	(balík)		Obecný mechanismus pro seskupování prvků. Na rozdíl od komponenty je balíček čistě koncepční (abstraktní) koncept. Speciálními případy balíčku jsou systém a model
	(fragment)		Oblast specifické interakce mezi instancemi aktérů a objekty
	(oddíl aktivity)		Skupina operací (oblast odpovědnosti) prováděná jednou entitou (aktér, objekt, komponenta, uzel atd.)
	(oblast přerušitelné aktivity)		Skupina operací, jejichž běžný sled provádění může být přerušen v důsledku výskytu neobvyklé situace
Vysvětlující	Poznámka (komentář)		Komentář k prvku. Připojí se ke komentovanému prvku přerušovanou čarou

Některé zdroje, zejména [,], také identifikují entity chování interakce A konečných automatů, ale z logického hlediska by měly být klasifikovány jako diagramy.

Některé z výše uvedených entit podle nich implikují Detailní popis na diagramech rozkladu. Na diagramu nejvyšší úrovně jsou označeny speciální ikonou nebo štítkem.

Následující tabulka obsahuje popis všech typů vztahy UML používané v diagramech k označení vztahů mezi entitami.

Tabulka 11.3. Vztah

název	Označení	Definice (sémantika)
Sdružení		Popis vztahu smysluplné spojení mezi dvěma nebo více subjekty. Většina obecná forma vztah
Agregace		Podtyp asociace, který popisuje vztah „část“–„celek“, ve kterém „část“ může existovat odděleně od „celku“. Kosočtverec je naznačen z „celé“ strany. Vztah je určen pouze mezi entitami stejného typu
Složení		Podtyp agregace, ve kterém „části“ nemohou existovat odděleně od „celku“. Zpravidla se „části“ vytvářejí a ničí současně s „celkem“
Závislost		Vztah mezi dvěma entitami, ve kterém změna v jedné entitě (nezávislé) může ovlivnit stav nebo chování druhé entity (závislé). Strana se šipkou označuje nezávislou entitu
Zobecnění		Vztah mezi zobecněnou entitou (předek, rodič) a specializovanou entitou (potomek, dcera). Trojúhelník je naznačen ze strany rodiče. Vztah je určen pouze mezi entitami stejného typu
Realizace		Vztah mezi entitami, kde jedna entita specifikuje akci, kterou se jiná entita zavazuje provést. Vztahy se používají ve dvou případech: mezi rozhraními a třídami (nebo komponentami), mezi případy užití a spoluprácemi. Strana šipky označuje entitu, která definuje akci (rozhraní nebo případ použití)

Pro přidružení lze specifikovat agregaci a složení mnohost (angl. multiplicity), charakterizující celkový počet instancí entit účastnících se vztahu. Obvykle se uvádí na každé straně vztahu poblíž odpovídající entity. Násobnost lze indikovat následujícími způsoby:

- * – libovolný počet kopií, včetně žádné;

Nezáporné celé číslo – násobek je pevně daný a rovná se zadanému číslu (například: 1, 2 nebo 5);

Rozsah nezáporných celých čísel "první číslo.. druhé číslo" (například: 1..5, 2..10 nebo 0..5);

Rozsah čísel od konkrétní počáteční hodnoty po libovolné konečné "první číslo.. *" (například: 1..*, 5..* nebo 0..*);

Výpis nezáporných celých čísel a rozsahů oddělených čárkami (například: 1, 3..5, 10, 15..*).

Pokud násobnost není uvedena, předpokládá se její hodnota 1. Násobnost instancí entit účastnících se závislosti, zobecnění a implementace se vždy předpokládá 1.

Následující tabulka poskytuje popis expanzní mechanismy , sloužící k objasnění sémantiky entit a vztahů. Obecně je rozšiřovacím mechanismem řetězec textu uzavřený v závorkách nebo uvozovkách.

Tabulka 11.4. Expanzní mechanismy

název	Označení	Definice (sémantika)
Stereotyp (stereotyp)	« »	Označení, které specifikuje sémantiku prvku zápisu (například: závislost se stereotypem „zahrnout“ je považována za inkluzní vztah a třída se stereotypem „hranice“ je třída hranice)
Stav stráže (stav stráže)		Booleovská podmínka (například: nebo [identifikace dokončena])
Omezení (omezení)	{ }	Pravidlo, které omezuje sémantiku prvku modelu (například (doba provedení kratší než 10 ms))
Označená hodnota (označená hodnota)	{ }	Nová nebo objasňující vlastnost prvku zápisu (například: (verze = 3.2))

Kromě stereotypů označených jako řetězec textu v uvozovkách lze v diagramech použít grafické stereotypy. Následující obrázek ukazuje příklady standardního a stereotypního zobrazení.


a) standardní označení		b) standardní označení s textovým stereotypem		c) grafický stereotyp

Rýže. 11.2. Příklady standardního a stereotypního zobrazení třídy

Diagram představuje seskupení prvků zápisu pro zobrazení některého aspektu rozvinutého informační systém. Diagramy jsou obvykle spojený graf, ve kterém entity jsou vrcholy a vztahy jsou oblouky. Následující tabulka uvádí stručný popis UML diagramy.

Tabulka 11.5. Diagramy

Diagram			Účel
				podle stupně fyzické realizace	zobrazením dynamiky	podle zobrazeného aspektu
(případ užití)			Zobrazuje systémové funkce, interakce mezi aktéry a funkcemi	Logický	Statický	Funkční
(třída)			Zobrazuje sadu tříd, rozhraní a vztahů mezi nimi	Logické resp fyzický	Statický	Funkční a informační
(balík)			Zobrazuje sadu balíčků a vztahy mezi nimi	Logické resp fyzický	Statický	Komponent
Chování (chování)	(státní automat)		Zobrazuje stavy entity a přechody mezi nimi během jejího životního cyklu	Logický	Dynamický	Behaviorální
	(aktivita)		Zobrazuje obchodní procesy v systému (popis algoritmů chování)
	Interakce (interakce)	(sekvence)	Zobrazuje sekvenci předávání zpráv mezi objekty a aktéry
		(sdělení)	Podobně jako sekvenční diagram, ale důraz je kladen na strukturu interakcí mezi objekty
Implementace (implementace)	(komponent)		Zobrazuje systémové komponenty (programy, knihovny, tabulky atd.) a propojení mezi nimi	Fyzický	Statický	Komponent
	(rozvinutí)		Zobrazuje umístění komponent na uzlech sítě a také její konfiguraci

Standard UML 2.x také definuje další, vysoce specializované diagramy:

Diagram objektů - podobný, ale místo tříd se zobrazují objekty;

Časový diagram - popisuje stav objektu v čase;

Diagram složené struktury - popisuje porty (včetně rozhraní) třídy pro interakci s jinými třídami;

Diagram profilu - podobný s popisem tříd v nich zahrnutých;

Diagram přehledu interakcí – podobný, ale se skrytými fragmenty interakce (fragmenty označené ref). Představuje kontextový (konceptuální), jehož prvky budou specifikovány na samostatných dekompozičních diagramech.

Pro účely zvětšeného koncepčního znázornění vnitřní architektury systému umožňuje převážná část konstrukce využít zavedené grafické stereotypy pro tzv. Takový diagram se nazývá 1, ale nepatří do seznamu diagramů definovaných standardem UML.

Při vývoji samostatného modelu systému se vytváří několik typů diagramů. Navíc při vývoji modelu komplexního systému se zpravidla konstruuje několik diagramů stejného typu. Zároveň nemusíte vytvářet samostatné typy grafů, pokud to není nutné. Například diagramy a jsou vzájemně zaměnitelné; jsou vytvořeny pouze pro objekty s komplexním chováním. Následující tabulka poskytuje doporučení ohledně potřeby vyvinout (objasnit) diagramy pro modely systémů.

Tabulka 11.6. Vztah mezi modely a diagramy

Níže uvedená tabulka neukazuje testovací model, protože v rámci jeho konstrukce nejsou diagramy vytvářeny, ale kontrolovány (testovány) na úplnost a konzistenci.

Některé z diagramů po jejich konstrukci vyžadují vývoj a upřesnění v rámci vývoje dalšího modelu ( technologický postup). Měly by se tedy například během vývoje vyjasnit. V modelech.

4. Definujte pojem " ".