Obecná charakteristika jazyka UML. UML diagram. Typy diagramů UML Diagram vrstvy 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 neumožňovala dostatečně vybudovat ú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. S každým grafickým symbolem je spojena specifická sémantika, takže model vytvořený jedním vývojářem může být jasně srozumitelný druhému, stejně jako softwarovému nástroji, který interpretuje 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ůj 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“ může být použito k nalezení všech produktů specifikovaných v konkrétní objednávce na jedné straně nebo k nalezení všech objednávek, které tento produkt obsahují, na straně druhé. 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 bez něj bylo obtížné jej použít v reálném modelování PS nástroje 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ů.

Diagram UML je specializovaný grafický popisný jazyk určený pro objektové modelování při vývoji různého softwaru. Tento jazyk má široký profil a je otevřeným standardem, který používá různé grafické symboly vytvořit abstraktní model systému. UML byl vytvořen, aby umožnil definici, vizualizaci, dokumentaci a návrh všech druhů softwarových systémů. Stojí za zmínku, že UML diagram sám o sobě není programovací jazyk, ale poskytuje možnost generování samostatného kódu na jeho základě.

Proč je to potřeba?

Použití UML nekončí modelováním všech druhů softwaru. Tento jazyk se dnes také aktivně používá pro modelování různých obchodních procesů, provádění návrhu systému a také zobrazování organizačních struktur.

S UML mohou vývojáři softwaru poskytnout úplnou shodu v grafickém zápisu používaném k reprezentaci běžných pojmů, jako jsou: komponenta, generika, třída, chování a agregace. Díky tomu je dosaženo větší míry koncentrace na architekturu a design.

Za zmínku také stojí, že existuje několik typů takových grafů.

Diagram tříd

Diagram tříd UML je statický strukturní diagram určený k popisu struktury systému a také k zobrazení atributů, metod a závislostí mezi několika různé třídy.

Za zmínku stojí skutečnost, že existuje několik úhlů pohledu na konstrukci takových diagramů v závislosti na tom, jak budou použity:

  • Pojmový. V tomto případě diagram tříd UML popisuje model konkrétní předmětové oblasti a poskytuje pouze třídy objektů aplikace.
  • Charakteristický. Diagram se používá v procesu návrhu různých informačních systémů.
  • Implementace. Diagram tříd zahrnuje všechny druhy tříd, které se přímo používají v kódu programu.

Schéma součásti

Diagram komponent UML je zcela statický strukturní diagram. Má demonstrovat členění konkrétního softwarového systému na různé strukturální komponenty a také vazby mezi nimi. Diagram komponent UML může používat všechny druhy modelů, knihoven, souborů, balíčků, spustitelných souborů a mnoho dalších prvků jako takových.

Složený/složený strukturní diagram

Diagram kompozitní/složené struktury UML je také diagram statické struktury, ale používá se k zobrazení vnitřní struktury tříd. Pokud možno tento diagram může také demonstrovat interakci prvků umístěných ve vnitřní struktuře třídy.

Jejich podtypem je diagram spolupráce UML, který se používá k demonstraci rolí a také interakce různých tříd v rámci hranic spolupráce. Jsou docela pohodlné, pokud potřebujete modelovat návrhové vzory.

Stojí za zmínku, že zobrazení třídy UML a diagramu kompozitní struktury lze používat současně.

Schéma nasazení

Tento diagram se používá k modelování běžících uzlů a také všech druhů artefaktů, které na nich byly nasazeny. V UML 2 jsou artefakty nasazeny do různých uzlů, zatímco v první verzi byly nasazeny pouze komponenty. Diagram nasazení UML se tedy používá především pro druhou verzi.

Mezi artefaktem a komponentou, kterou implementuje, se vytvoří závislost manifestace.

Diagram objektu

Toto zobrazení vám umožňuje vidět úplný nebo částečný snímek systému vytvářeného v určitém okamžiku. Plně zobrazuje všechny instance tříd konkrétního systému s uvedením aktuálních hodnot jejich parametrů a také spojení mezi nimi.

Schéma balíčku

Tento diagram je strukturální povahy a jeho hlavním obsahem jsou všechny druhy balíčků a také vztahy mezi nimi. V tomto případě neexistuje žádné striktní rozdělení mezi několika strukturálními diagramy, v důsledku čehož se jejich použití nejčastěji nachází pouze pro pohodlí a nemá žádný sémantický význam. Stojí za zmínku, že různé prvky mohou poskytovat další diagramy UML (příklady: balíčky a samotné diagramy balíčků).

Jejich použití se provádí za účelem zajištění organizace několika prvků do skupin podle určitého kritéria za účelem zjednodušení struktury a také organizace práce s modelem daného systému.

Diagram aktivity

Diagram aktivity UML zobrazuje rozklad konkrétní aktivity do několika částí. V tomto případě je pojem „činnost“ specifikací určitého spustitelného chování ve formě paralelního, ale i koordinovaného sekvenčního provádění různých podřízených prvků - vnořených typů činností a různých akcí, spojených toky vycházejícími z výstupů. určitého uzlu na vstupy jiného.

Diagramy aktivit UML se často používají k modelování různých obchodních procesů, paralelních a sekvenčních výpočtů. Mimo jiné simulují všemožné technologické postupy.

Schéma stroje

Tento typ se také nazývá trochu jinak - UML stavový diagram. Má prezentovaný konečný automat s jednoduchými a složenými stavy, stejně jako přechody.

Stavový automat je specifikace posloupnosti různých stavů, kterými určitý objekt nebo interakce prochází v reakci na určité události ve svém životě, stejně jako reakce objektu na takové události. Stavový stroj, který používá stavový diagram UML, je připojen ke zdrojovému prvku a používá se k definování chování jeho instancí.

Takzvané dračí diagramy mohou být použity jako analogy takových diagramů.

Schémata případů použití

Diagram případů použití UML zobrazuje všechny vztahy, které se vyskytují mezi aktéry, stejně jako různé případy použití. Jeho hlavním úkolem je poskytnout plnohodnotný prostředek, jehož prostřednictvím může zákazník, koncový uživatel nebo jakýkoli 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 diagram případu použití UML, pak analytik:

  • Jasně oddělte modelovaný systém od jeho prostředí.
  • Identifikujte aktéry, způsoby jejich interakce s tímto systémem a také jeho očekávanou funkčnost.
  • Nastavte ve slovníku jako předmět různé pojmy, které se týkají podrobného popisu funkčnosti daného systému.

Pokud je diagram použití vypracován v UML, postup začíná textovým popisem, který se získá při práci se zákazníkem. Za zmínku stojí skutečnost, že různé nefunkční požadavky jsou v procesu sestavování modelu případu užití zcela vynechány a bude pro ně vygenerován samostatný dokument.

komunikace

Komunikační diagram, stejně jako sekvenční diagram UML, je tranzitivní, to znamená, že vyjadřuje interakci, ale zároveň ji demonstruje různé způsoby a v případě potřeby lze jeden převést na druhý s požadovaným stupněm přesnosti.

Komunikační diagram odráží interakce, ke kterým dochází mezi různými prvky kompozitní struktury, a také role spolupráce. Hlavní rozdíl mezi ním a sekvenčním diagramem je v tom, že vztahy mezi několika prvky jsou zcela explicitní a nepoužívá čas jako samostatnou dimenzi.

Tenhle typ Vyznačuje se zcela volným formátem pro uspořádání více objektů a spojení stejným způsobem jako v objektovém diagramu. Pokud je potřeba zachovat pořadí zpráv v tomto volném formátu, jsou číslovány chronologicky. Čtení tohoto diagramu začíná počáteční zprávou 1.0 a následně pokračuje ve směru, ve kterém jsou zprávy přenášeny z jednoho objektu do druhého.

Z velké části tyto diagramy ukazují přesně tytéž informace, které nám poskytuje sekvenční diagram, ale protože používá jiný způsob prezentace informací, určité věci v jednom diagramu se dají identifikovat mnohem snadněji než v jiném. Za zmínku také stojí, že komunikační diagram jasněji ukazuje, se kterými prvky každý interaguje. samostatný prvek, zatímco sekvenční diagram jasněji ukazuje, v jakém pořadí k interakcím dochází.

Sekvenční diagram

Sekvenční diagram UML ukazuje interakce mezi více objekty, které jsou seřazeny podle času, kdy se vyskytují. Tento diagram ukazuje časově uspořádanou interakci mezi několika objekty. Zejména zobrazuje všechny objekty, které se účastní interakce, a také kompletní sekvenci zpráv vyměňovaných mezi nimi.

Hlavními prvky jsou v tomto případě označení různých předmětů, dále svislé čáry znázorňující běh času a obdélníky představující činnost určitého předmětu nebo výkon nějaké funkce.

Schéma spolupráce

Tento typ diagramu vám umožňuje demonstrovat interakce mezi několika objekty abstrahováním od sekvence překladu zpráv. Tento typ diagramu zobrazuje v kompaktní formě absolutně všechny odeslané a přijaté zprávy určitého objektu a také formáty těchto zpráv.

Protože sekvenční a komunikační diagramy jsou jednoduše různé pohledy na stejné procedury, Rational Rose poskytuje možnost vytvořit komunikační diagram ze sekvenčního diagramu nebo naopak a také je zcela automaticky synchronizuje.

Diagramy přehledu interakcí

Toto jsou diagramy jazyk UML, které jsou typem diagramu aktivit a zahrnují jak prvky sekvence, tak konstrukty toku řízení.

Za zmínku stojí skutečnost, že tento formát kombinuje Collaboration a Sekvenční diagram, které poskytují možnost uvažovat o interakci mezi několika objekty ve vznikajícím systému z různých úhlů pohledu.

Časový diagram

Představuje alternativní verzi sekvenčního diagramu, který explicitně demonstruje změnu stavu podél záchranné čáry v určitém časovém měřítku. Může být docela užitečné v různé aplikace reálný čas.

Jaké jsou výhody?

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

  • Jazyk je objektově orientovaný, v důsledku čehož jsou technologie pro popis výsledků analýzy a návrhu sémanticky blízké programovacím metodám ve všech druzích moderních objektově orientovaných jazyků.
  • S pomocí tohoto jazyka systém lze popsat téměř ze všech možných úhlů pohledu a stejným způsobem jsou popsány různé aspekty jeho chování.
  • Všechny diagramy jsou poměrně dobře čitelné i po poměrně rychlém seznámení s jeho syntaxí.
  • UML umožňuje rozšířit a také zavést vlastní grafické a textové stereotypy, což podporuje jeho využití nejen v softwarovém inženýrství.
  • Jazyk se stal poměrně rozšířeným a také se poměrně aktivně rozvíjí.

Nedostatky

Navzdory skutečnosti, že konstrukce UML diagramů má mnoho výhod, jsou často kritizovány za následující nevýhody:

  • Nadbytek. V naprosté většině případů kritici říkají, že UML je příliš velké a složité, a to je často neopodstatněné. Obsahuje poměrně hodně nadbytečných nebo prakticky nepoužitelných návrhů a schémat a taková kritika je nejčastěji směřována na druhou verzi, nikoli na první, protože novější revize obsahují více kompromisů „navrženo výborem“.
  • Různé nepřesnosti v sémantice. Protože UML je definováno kombinací sebe sama, angličtiny a OCL, nemá tuhost, která je vlastní jazykům přesně definovaným technikami formálního popisu. V určitých situacích si abstraktní syntaxe OCL, UML a angličtiny začnou odporovat, zatímco v jiných případech jsou neúplné. Nepřesnost ve specifikaci samotného jazyka má dopad jak na uživatele, tak na dodavatele nástrojů, což v konečném důsledku vede k nekompatibilitě nástrojů kvůli jedinečnému způsobu zacházení s různými specifikacemi.
  • Problémy v procesu implementace a studia. Všechny výše uvedené problémy vytvářejí problémy při implementaci a učení UML, zvláště když management nutí inženýry používat jej bez předchozích znalostí.
  • Kód odráží kód. Jiný názor je, že důležité nejsou krásné a atraktivní modely, ale samotné fungující systémy, tedy kód je projekt. Podle tohoto názoru je potřeba se více rozvíjet účinná metoda software pro psaní. UML je běžně ceněno 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 jazyk postrádá Turingovy vlastnosti úplnosti a každý vygenerovaný kód bude nakonec omezen na to, co dokáže uhodnout nebo určit nástroj pro interpretaci UML.
  • Nesoulad zatížení. Tento termín pochází z teorie systémové analýzy k určení neschopnosti vstupu určitého systému vnímat jiný výstup. Jako každý standardní zápis může UML reprezentovat některé systémy efektivněji a stručněji než jiné. Vývojář je tedy více nakloněn těm řešením, která jsou pohodlnější v prolínání všech silných stránek UML, ale i jiných programovacích jazyků. Tento problém je zjevnější, pokud vývojový jazyk neodpovídá základním principům objektově orientované ortodoxie, to znamená, že se nesnaží pracovat v souladu s principy OOP.
  • Snaží se být univerzální. UML je univerzální modelovací jazyk, který se snaží být kompatibilní s jakýmkoliv dnes dostupným jazykem zpracování. V kontextu daného projektu, aby tým designérů dosáhl konečného cíle, je nutné vybrat použitelné vlastnosti daného jazyka. Kromě toho možné způsoby, jak omezit rozsah UML v určité oblasti, jsou prostřednictvím formalismu, který není plně artikulován a který sám je předmětem kritiky.

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

V současné době je UML standardní notací pro vizuální modelování softwarových systémů, přijatou konsorciem Object Management Group (OMG) na podzim roku 1997, která je podporována mnoha objektově orientovanými produkty CASE.

Standard UML nabízí pro modelování následující sadu diagramů:

· diagram případu užití – pro modelování obchodních procesů organizace nebo podniku a stanovení požadavků na vytvářený informační systém;

· diagram tříd – pro modelování statické struktury systémových tříd a vazeb mezi nimi;

· diagramy chování systému;

· diagramy interakce;

· sekvenční diagramy – pro modelování procesu zasílání zpráv mezi objekty v rámci jednoho případu užití;

· diagram spolupráce – pro modelování procesu zasílání zpráv mezi objekty v rámci jednoho případu užití;

· stavový diagram – pro modelování chování systémových objektů při přechodu z jednoho stavu do druhého;

· diagram aktivit – pro modelování chování systému v rámci různých případů užití, případně modelování aktivit;

implementační schémata:

· diagramy komponent – ​​pro modelování hierarchie komponent (subsystémů) informačního systému;

· diagram nasazení – pro modelování fyzické architektury navrženého informačního systému.

Na Obr. 1.1 představuje integrovaný model informačního systému, včetně hlavních diagramů, které by měly být vyvinuty v tomto projektu kurzu.

Rýže. 1. Integrovaný model informačního systému v notaci UML

4.2. Schéma případu použití

Případ užití je posloupnost akcí prováděných systémem v reakci na událost iniciovanou nějakým externím objektem (aktérem). Případ užití popisuje typickou interakci mezi uživatelem a systémem. V nejjednodušším případě je případ užití určen v procesu projednávání funkcí, které by chtěl v tomto informačním systému implementovat. V UML je případ použití znázorněn následovně:

Obr.2. Případ použití

Aktér je role, kterou uživatel hraje ve vztahu k systému. Herci představují role, nikoli konkrétní osoby nebo pracovní pozice. Přestože jsou v diagramech případů užití zobrazeni jako stylizované lidské postavy, herec může být také externí informační systém, který potřebuje nějaké informace z tohoto systému. Aktéři by měli být na diagramu uvedeni pouze v případě, že skutečně potřebují nějaké případy použití. V UML jsou aktéři reprezentováni jako tvary:



Obr.3. postava (herec)

Herci jsou rozděleni do tří hlavních typů:

· uživatelé;

· systémy;

· další systémy spolupracující s tímto systémem;

Čas se stává aktérem, pokud na něm závisí spuštění jakýchkoliv událostí v systému.

4.2.1. Vztahy mezi případy užití a aktéry

V UML podporují diagramy případů použití několik typů vztahů mezi prvky diagramu:

· komunikace

zahrnutí (zahrnout),

· prodloužení (prodloužit),

· zobecnění.

komunikační spojení je vztah mezi případem užití a aktérem. V UML jsou komunikační vztahy znázorněny pomocí jednosměrné asociace (plná čára).

Obr.4. Příklad komunikačního spojení

Povolit připojení používá se v situacích, kdy existuje určitá část chování systému, která se opakuje ve více než jednom případě použití. Tato připojení se obvykle používají k modelování opakovaně použitelné funkce.

Expanzní komunikace používá se k popisu změn v normálním chování systému. V případě potřeby umožňuje použití jednoho případu použití funkčnost jiný případ použití.

Obr.5. Příklad vztahu zahrnutí a rozšíření

Generalizační spojení ukazuje, že několik herců nebo tříd má společné vlastnosti.

Obr.6. Příklad spojení zobecnění

4.3.



Interakční diagramy popsat chování interagujících skupin objektů. Interakční diagram obvykle pokrývá chování objektů pouze v jednom případě použití. Takový diagram zobrazuje řadu objektů a zpráv, které si mezi sebou vyměňují.

Zpráva je prostředek, kterým odesílající objekt žádá objekt příjemce o provedení jedné z jeho operací.

Informační zpráva je zpráva, která poskytuje objektu příjemce nějaké informace k aktualizaci jeho stavu.

Žádost o zprávu (dotazovací) je zpráva požadující vydání některých informací o objektu příjemce.

Naléhavá zpráva je zpráva, která požaduje, aby objekt příjemce provedl nějakou akci.

Existují dva typy interakčních diagramů: sekvenční diagramy a diagramy spolupráce.

4.3.1. Sekvenční diagramy

Sekvenční diagram odráží tok událostí vyskytujících se v rámci jednoho případu použití.

Všichni aktéři (herci, třídy nebo objekty) zapojení do daného scénáře (případ užití) jsou uvedeni v horní části diagramu. Šipky odpovídají zprávám předávaným mezi aktérem a objektem nebo mezi objekty k provedení požadovaných funkcí.

V sekvenčním diagramu je objekt znázorněn jako obdélník s tečkovanou svislou čarou nakreslenou z něj dolů. Tato linka se nazývá záchranné lano objektu . Představuje fragment životního cyklu objektu v procesu interakce.

Každá zpráva je znázorněna jako šipka mezi liniemi života dvou objektů. Zprávy se zobrazují v pořadí, v jakém se objevují na stránce shora dolů. Každá zpráva je označena alespoň názvem zprávy. V případě potřeby můžete také přidat argumenty a některé řídicí informace. Můžete zobrazit sebedelegování – zprávu, kterou si objekt posílá, přičemž šipka zprávy ukazuje na stejnou čáru života.

Rýže. 7. Příklad sekvenčního diagramu

4.3.2. Diagram spolupráce

Schémata spolupráce zobrazit tok událostí v rámci konkrétního scénáře (případ užití). Zprávy jsou seřazeny podle času, i když diagramy spolupráce se více zaměřují na spojení mezi objekty. Diagram spolupráce představuje všechny informace, které jsou přítomné v sekvenčním diagramu, ale diagram spolupráce popisuje tok událostí odlišně. Usnadňuje pochopení souvislostí, které mezi objekty existují.

V diagramu spolupráce, stejně jako v sekvenčním diagramu, představují šipky zprávy vyměňované v rámci daného případu použití. Jejich časová posloupnost je označena číslováním zpráv.

Rýže. 8. Příklad kooperačního diagramu

4.4. Diagram tříd

4.4.1. Obecná informace

Diagram tříd definuje typy tříd systému a různé druhy statických spojení, které mezi nimi existují. Diagramy tříd také zobrazují atributy tříd, operace tříd a omezení, která jsou uvalena na vztahy mezi třídami.

Diagram tříd v jazyce UML je graf, jehož uzly jsou prvky statické struktury projektu (třídy, rozhraní) a oblouky jsou vztahy mezi uzly (asociace, dědičnost, závislosti).

Diagram tříd zobrazuje následující prvky:

· Balíček - sada prvků modelu, které spolu logicky souvisí;

· Třída (třída) - popis společných vlastností skupiny podobných objektů;

· Rozhraní – abstraktní třída, která specifikuje sadu operací, které objekt libovolné třídy přidružené k danému rozhraní poskytuje jiným objektům.

4.4.2. Třída

Třída je skupina entit (objektů), které mají podobné vlastnosti, konkrétně data a chování. Jednotlivý zástupce třídy se nazývá objekt třídy nebo jednoduše objekt.

Chování objektu v UML odkazuje na jakákoli pravidla pro interakci objektu s vnějším světem a s daty samotného objektu.

Na obrázcích je třída znázorněna jako obdélník s plným okrajem, rozdělený vodorovnými čarami na 3 části:

Horní část (část jména) obsahuje název třídy a další obecné vlastnosti (zejména stereotyp).

Střední část obsahuje seznam atributů

V dolní části je seznam operací třídy, které odrážejí její chování (akce prováděné třídou).

Jakákoli sekce atributů a operací nemusí být zobrazena (nebo obě najednou). Pro chybějící část nemusíte kreslit dělicí čáru ani žádným způsobem naznačovat přítomnost nebo nepřítomnost prvků v ní.

Podle uvážení konkrétní implementace může být zavedena další sekce například výjimky.

Rýže. 9. Příklad diagramu tříd

4.4.2.1.Třídní stereotypy

Třídní stereotypy jsou mechanismem pro rozdělování tříd do kategorií.

UML definuje tři hlavní třídní stereotypy:

Hranice (hranice);

Entita (entita);

Řízení.

4.4.2.2.Hraniční třídy

Hraniční třídy jsou ty třídy, které se nacházejí na hranici systému a celého prostředí. Patří mezi ně displeje, sestavy, rozhraní s hardwarem (jako jsou tiskárny nebo skenery) a rozhraní s jinými systémy.

Chcete-li najít hraniční třídy, musíte prozkoumat diagramy případů použití. Každá interakce mezi aktérem a případem užití musí být spojena s alespoň jednou hraniční třídou. Je to tato třída, která umožňuje herci interakci se systémem.

4.4.2.3.Třídy entit

Třídy entit obsahují uložené informace. Pro uživatele mají největší význam, a proto jejich názvy často používají výrazy z předmětné oblasti. Obvykle se v databázi vytvoří tabulka pro každou třídu entity.

4.4.2.4.Kontrolní třídy

Kontrolní třídy jsou zodpovědné za koordinaci akcí ostatních tříd. Každý případ použití má obvykle jednu ovládací třídu, která řídí sekvenci událostí pro daný případ použití. Řídicí třída je zodpovědná za koordinaci, ale sama o sobě nenese žádnou funkcionalitu, protože ostatní třídy ji neposílají velké množství zprávy. Místo toho sám posílá mnoho zpráv. Třída manažera jednoduše deleguje odpovědnost na jiné třídy, a proto se často nazývá třída manažerů.

V systému mohou být další třídy řízení, které jsou společné pro více případů použití. Například může existovat třída SecurityManager, která je zodpovědná za monitorování událostí souvisejících se zabezpečením. Třída TransactionManager je zodpovědná za koordinaci zpráv souvisejících s databázovými transakcemi. Mohou existovat jiní správci, kteří se starají o další prvky provozu systému, jako je sdílení zdrojů, distribuované zpracování dat nebo zpracování chyb.

Kromě výše zmíněných stereotypů si můžete vytvořit vlastní.

4.4.2.5.Atributy

Atribut je prvek informace spojený s třídou. Atributy ukládají zapouzdřená data třídy.

Protože atributy jsou obsaženy v rámci třídy, jsou skryté před ostatními třídami. Z tohoto důvodu možná budete muset určit, které třídy mají právo číst a měnit atributy. Tato vlastnost se nazývá viditelnost atributu.

Atribut může mít čtyři možné hodnoty tohoto parametru:

Veřejné (obecné, otevřené). Tato hodnota viditelnosti předpokládá, že atribut bude viditelný pro všechny ostatní třídy. Jakákoli třída může zobrazit nebo změnit hodnotu atributu. Podle notace UML předchází běžnému atributu znaménko „+“.

Soukromé (uzavřené, tajné). Odpovídající atribut není viditelný pro žádnou jinou třídu. Soukromý atribut je označen znakem „–“ podle notace UML.

Chráněno (chráněno). Tento atribut je dostupný pouze pro samotnou třídu a její potomky. Notace UML pro chráněný atribut je znak "#".

Balíček nebo Implementace (balíček). Předpokládá, že atribut je sdílený, ale pouze v rámci jeho balíčku. Tento typ viditelnosti není označen žádnou speciální ikonou.

Pomocí uzavřenosti či bezpečnosti se lze vyhnout situaci, kdy hodnotu atributu mění všechny třídy systému. Místo toho bude logika pro změnu atributu obsažena ve stejné třídě jako samotný atribut. Nastavení viditelnosti, které nastavíte, ovlivní vygenerovaný kód.

4.4.2.6.Operace

Operace implementují chování spojené s třídou. Operace má tři části: název, parametry a návratový typ.

Parametry jsou argumenty přijaté operací jako vstup. Návratový typ odkazuje na výsledek operace.

Diagram tříd může zobrazovat názvy operací i názvy operací spolu s jejich parametry a návratovým typem. Chcete-li snížit zatížení diagramu, je užitečné u některých z nich zobrazovat pouze názvy operací a u jiných jejich úplný podpis.

V UML mají operace následující zápis:

Název operace (argument: datový typ argumentu, argument2: datový typ argumentu2,...): návratový typ

Je třeba zvážit čtyři různé typy operací:

Prováděcí operace;

Manažerské operace;

Přístupové operace;

Pomocné operace.

Implementační operace

Operace implementátoru implementují některé obchodní funkce. Takové operace lze nalézt zkoumáním interakčních diagramů. Tento typ diagramu se zaměřuje na obchodní funkce a každou zprávu v diagramu lze pravděpodobně namapovat na implementační aktivitu.

Každá implementační operace musí být snadno dohledatelná k odpovídajícímu požadavku. Toho je dosaženo v různých fázích simulace. Operace je odvozena od zprávy v interakčním diagramu, zprávy pocházejí Detailní popis tok událostí, který je vytvořen na základě případu užití a ten je vytvořen na základě požadavků. Schopnost sledovat celý tento řetězec vám umožňuje zajistit, aby byl každý požadavek implementován v kódu a každý kus kódu implementoval nějaký požadavek.

Kontrolní operace

Manažerské operace řídí vytváření a ničení objektů. Do této kategorie spadají konstruktory a destruktory tříd.

Přístupové operace

Atributy jsou obvykle soukromé nebo chráněné. Jiné třídy však někdy potřebují zobrazit nebo změnit své hodnoty. Pro tento účel existují přístupové operace. Tento přístup umožňuje bezpečně zapouzdřit atributy v rámci třídy, chránit je před ostatními třídami, ale stále k nim umožňuje kontrolovaný přístup. Je standardní vytvořit operace Get a Set pro každý atribut třídy.

Pomocné operace

Pomocné operace jsou operace třídy, které jsou nezbytné k tomu, aby mohla plnit své povinnosti, ale o kterých by ostatní třídy neměly nic vědět. Jedná se o operace soukromé a chráněné třídy.

Chcete-li identifikovat transakce, postupujte takto:

1. Naučte se sekvenční diagramy a kooperativní diagramy. Většina zpráv v těchto diagramech jsou implementační operace. Reflexní zprávy budou pomocnými operacemi.

2. Zvažte kontrolní operace. Možná budete muset přidat konstruktory a destruktory.

3. Zvažte operace přístupu. Pro každý atribut třídy, se kterým budou muset ostatní třídy pracovat, musíte vytvořit operace Get a Set.

4.4.2.7.Spojení

Vztah představuje sémantický vztah mezi třídami. Poskytuje třídě schopnost učit se o atributech, operacích a vztazích jiné třídy. Jinými slovy, aby jedna třída mohla poslat zprávu druhé v sekvenčním nebo kooperativním diagramu, musí mezi nimi existovat vztah.

Mezi třídami lze vytvořit čtyři typy vztahů: asociace, závislosti, agregace a zobecnění.

Komunikační asociace

Asociace je sémantické spojení mezi třídami. Jsou nakresleny na diagramu tříd jako obyčejná čára.

Rýže. 10. Komunikační asociace

Přidružení mohou být obousměrná, jako v příkladu, nebo jednosměrná. V UML jsou obousměrné asociace nakresleny jako jednoduchá čára bez šipek nebo se šipkami na obou stranách. Jednosměrné přidružení má pouze jednu šipku ukazující jeho směr.

Směr asociace lze určit zkoumáním sekvenčních diagramů a kooperativních diagramů. Pokud jsou všechny zprávy na nich odesílány pouze jednou třídou a přijímány pouze jinou třídou, ale nikoli naopak, dochází mezi těmito třídami k jednosměrné komunikaci. Pokud je alespoň jedna zpráva odeslána opačným směrem, musí být přidružení obousměrné.

Asociace mohou být reflexivní. Reflexivní přidružení zahrnuje jednu instanci třídy, která interaguje s jinými instancemi stejné třídy.

Komunikační závislost

Vztahy závislostí také odrážejí vztahy mezi třídami, ale jsou vždy jednosměrné a ukazují, že jedna třída závisí na definicích vytvořených v jiné. Například třída A používá metody třídy B. Když se pak třída B změní, je nutné provést odpovídající změny ve třídě A.

Je znázorněna závislost tečkovaná čára nakreslený mezi dvěma prvky diagramu a prvek připojený ke konci šipky se považuje za závislý na prvku připojeném k začátku této šipky.

Rýže. 11. Komunikační závislost

Při generování kódu pro tyto třídy do nich nebudou přidány žádné nové atributy. Pro podporu komunikace však budou vytvořeni operátoři pro konkrétní jazyky.

Agregace komunikace

Agregace jsou užší formou asociace. Agregace je spojením celku a jeho části. Můžete mít například třídu nazvanou Car, stejně jako třídy jako Motor, Pneumatiky a třídy pro další části vozu. Výsledkem je, že objekt třídy Car se bude skládat z objektu třídy Engine, čtyř objektů Tire atd. Agregace jsou vizualizovány jako čára s kosočtvercem poblíž třídy, což je celé číslo:

Rýže. 11. Agregace komunikace

Kromě jednoduché agregace zavádí UML silnější typ agregace zvaný kompozice. Podle kompozice může předmět-část patřit pouze k jedinému celku a navíc se životní cyklus částí zpravidla shoduje s cyklem celku: žijí a umírají s ním. Jakékoli smazání celku se vztahuje na jeho části.

Toto kaskádové mazání je často považováno za součást definice agregace, ale je vždy implikováno, když je multiplicita rolí 1..1; pokud je například nutné odstranit Zákazníka, pak se toto odstranění musí týkat také Objednávek (a následně Řádků Objednávek).

UML je zkratka, která znamená Unified Modeling Language. Ve skutečnosti je to jedna z nejpopulárnějších technik modelování obchodních procesů a je mezinárodní standardní notací pro specifikaci, vizualizaci a dokumentaci vývoje softwaru. Definovaný Object Management Group se objevil jako následek několika dalších notačních systémů UML a nyní se stal de facto standardem pro vizuální modelování. Základní princip jakéhokoli objektově orientovaného programování začíná vytvořením modelu.

UML byl vytvořen jako výsledek chaosu kolem vývoje softwaru a dokumentace. V 90. letech 20. století existovalo několik různých způsobů uvažování o softwarových systémech. Bylo potřeba vytvořit jednotnější vizuální způsob UML, jak tyto systémy reprezentovat, a v důsledku toho byl v letech 1994 až 1996 vyvinut třemi softwarovými inženýry pracujícími ve společnosti Rational Software. Později byl přijat jako standard v roce 1997 a zůstává jím dodnes, pouze s několika aktualizacemi.

UML je v podstatě univerzální modelovací jazyk v oblasti vývoje softwaru. Nyní si však našel cestu do dokumentace několika obchodních procesů nebo pracovních postupů, jako jsou diagramy aktivit. Typ UML diagramů lze použít jako náhradu za vývojové diagramy. Poskytují jak standardizovanější způsob modelování pracovních postupů, tak širokou škálu funkcí pro zlepšení čitelnosti a efektivity.

Architektura je založena na metaobjektu, který definuje základ pro tvorbu jazyka UML. Je dostatečně přesný na vytvoření celé aplikace. Plně spustitelné UML lze nasadit na více platformách pomocí různé technologie se všemi procesy během celého cyklu vývoje softwaru.

UML má být uživatelsky vyvinutý jazyk vizuálního modelování. Podporuje koncepty vývoje na vysoké úrovni, jako jsou struktury, vzory a spolupráce. UML je sada prvků, jako jsou:

  1. Příkazy programovacího jazyka.
  2. Aktéři – popisují roli, kterou hraje uživatel nebo jakýkoli jiný systém interagující s objektem.
  3. Činnosti, které je nutné provést pro splnění smlouvy o dílo a jsou uvedeny v diagramech.
  4. Obchodní proces, který zahrnuje sadu úkolů, které vytvářejí konkrétní službu pro klienty, vizualizované pomocí vývojového diagramu sekvenčních akcí.
  5. Logické a opakovaně použitelné softwarové komponenty.

Diagramy UML spadají do dvou kategorií. První typ zahrnuje sedm typů diagramů představujících strukturální informace, druhý - zbývajících sedm, představujících obecné typy chování. Tyto diagramy se používají k dokumentaci architektury systémů a přímo se podílejí na modelování systému v UML.

UML diagramy jsou prezentovány jako statické a dynamické reprezentace modelu systému. Statické zobrazení obsahuje diagramy tříd a složení, které zvýrazňují statickou strukturu. Dynamický pohled představuje interakci mezi objekty a změny vnitřních stavů objektů pomocí sekvenčních, aktivitních a stavových diagramů.

Pro zjednodušení modelování je k dispozici široká škála modelovacích nástrojů UML, včetně IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner a Dia.

Použití UML má různé typy jak v dokumentaci vývoje softwaru, tak v obchodních procesech:

  1. Skica. V tomto případě se diagramy UML používají k vyjádření různých aspektů a charakteristik systému. Toto je však pouze reprezentace nejvyšší úroveň systému a s největší pravděpodobností nebude obsahovat všechny potřebné detaily k dokončení projektu až do úplného konce.
  2. Forward Design - Návrh náčrtu se provádí před kódováním aplikace. Toto se dělá pro lepší recenze systém nebo pracovní postup, který se uživatel pokouší vytvořit. Lze identifikovat mnoho konstrukčních problémů nebo nedostatků, které zlepší celkové zdraví a pohodu projektu.
  3. Reverzní provedení. Jakmile je kód napsán, diagramy UML se zobrazí jako forma dokumentace pro různé aktivity, role, účastníky a pracovní postupy.
  4. Modrotisk. V tomto případě schéma slouží jako kompletní návrh, který vyžaduje pouze samotnou implementaci systému nebo softwaru. To se často provádí pomocí nástrojů CASE (Computer Aided Software Engineering Tools). Hlavní nevýhodou používání nástrojů CASE je, že vyžadují určitou úroveň znalostí, školení uživatelů, ale i managementu a personálu.

UML není samostatný programovací jazyk jako Java, C++ nebo Python, ale se správnými nástroji se může stát pseudoprogramovým jazykem UML. K dosažení tohoto cíle musí být celý systém dokumentován v různých diagramech a pomocí správného softwaru mohou být diagramy přímo převedeny do kódu. Tato metoda může být užitečná pouze v případě, že čas strávený kreslením diagramů zabere méně času než psaní skutečného kódu. Přestože byl UML vytvořen pro modelování systémů, našel několik aplikací v obchodních oblastech.

Níže je uveden příklad UML diagramu pro obchodní modelování.

Jedním z praktických řešení by bylo vizuálně znázornit tok procesu pro prodej na dálku prostřednictvím diagramu aktivit. Od okamžiku přijetí objednávky jako vstupu do okamžiku dokončení objednávky a zadání konkrétního výstupu.

Existuje několik typů diagramů UML a každý z nich plní jiný úkol, ať už je vyvinut před implementací nebo po ní, jako součást dokumentace. Dvě nejširší kategorie, které pokrývají všechny ostatní typy, jsou diagram chování a diagram struktury. Jak název napovídá, některé UML diagramy se pokoušejí analyzovat a znázornit strukturu systému nebo procesu, zatímco jiné popisují chování systému, jeho účastníků a komponent.

Jednotlivé typy jsou rozděleny následovně:

  1. Ne všechny ze 14 různé typy Diagramy UML se pravidelně používají při dokumentaci systémů a architektur.
  2. Paretův princip platí i pro použití UML diagramů.
  3. 20 % grafů používají vývojáři 80 % času.

Nejčastěji používané prvky při vývoji softwaru jsou:

  • diagramy použití;
  • diagramy tříd;
  • sekvence.

Diagramy aktivit jsou nejdůležitější diagramy UML pro vytváření modelů obchodních procesů. Při vývoji softwaru se používají k popisu toku různých činností. Mohou být sériové nebo paralelní. Popisují předměty používané, spotřebované nebo produkované činností a vztahy mezi nimi různé typyčinnosti.

Vše výše uvedené je důležité pro modelování obchodních procesů, které vedou od jednoho k druhému, protože jsou vzájemně propojeny s jasným začátkem a koncem. V obchodním prostředí se tomu také říká mapování obchodních procesů. Hlavními postavami jsou autor, redaktor a vydavatel. Příklad UML je následující. Když se recenzent podívá na pracovní verzi a rozhodne se, že je třeba provést nějaké změny. Autor poté návrh reviduje a vrátí jej zpět k analýze recenze.

Diagram použití

Základní kámen systému – používá se k analýze požadavků na systémové úrovni. Tyto požadavky jsou vyjádřeny v různých případech použití. Tři hlavní součásti diagramu UML jsou:

  1. Funkční – prezentovány jako případy použití.
  2. Sloveso, které popisuje akci.
  3. Aktéři – pro interakci se systémem. Role aktéra mohou být uživatelé, organizace nebo externí aplikace. Vztahy mezi účastníky jsou znázorněny přímými šipkami.

Například pro tabulku řízení zásob. V tomto případě jde o vlastníka, dodavatele, manažera, specialistu na inventarizaci a inspektora inventury. Kulaté kontejnery představují akce prováděné herci. Možné akce: nákup a platba akcií, kontrola kvality zásob, vrácení zásob nebo jejich distribuce.

Tento typ diagramu je vhodný pro zobrazení dynamického chování mezi účastníky v systému, zjednodušuje jeho prezentaci, aniž by odrážel detaily implementace.

Dočasný

Časové diagramy UML se používají k reprezentaci vztahů objektů, kde je fokus závislý na čase. Není zajímavé, jak objekty interagují nebo se navzájem mění, ale uživatel si chce představit, jak objekty a subjekty jednají podél lineární časové osy.

Každý jednotlivý účastník je reprezentován pomocí záchranného lana, což je v podstatě čára, která tvoří fáze, jak se jednotlivý účastník pohybuje z jedné fáze do druhé. Důraz je kladen na dobu trvání událostí a změny, ke kterým v závislosti na ní dochází.

Hlavní součásti časového diagramu jsou:

  1. Lifeline je individuální člen.
  2. Časová osa stavu – Jediná životní cesta může v rámci procesu procházet různými stavy.
  3. Omezení trvání je omezení časového intervalu, které představuje dobu trvání potřebnou ke splnění omezení.
  4. Časový limit - omezení časového intervalu, během kterého musí účastník něco splnit.
  5. Destruction Emergence – Vznik zprávy, která zničí jednotlivého účastníka a představuje konec životního cyklu tohoto účastníka.

Horizontální diagramy, nazývané také stavové diagramy, se používají k popisu různých stavů komponenty v systému. Přijímá konečný formát názvu, protože diagram je v podstatě stroj, který popisuje více stavů objektu a jak se mění na základě vnitřních a vnějších událostí.

Velmi jednoduchý stavový diagram stroje by byl jako šachová partie. Typická šachová hra se skládá z tahů bílého a tahů černého. Bílý má první tah, který tak zahajuje hru. Konec hry může nastat bez ohledu na to, zda vyhraje bílý nebo černý. Hra může skončit zápasem, mezipřistáním nebo remízou (různé stavy stroje). Stavové diagramy se používají především v dopředném a zpětném UML návrhu různých systémů.

Po sobě

Tento typ diagramů jsou nejdůležitější UML diagramy nejen mezi komunitou počítačová věda, ale také jako modely na úrovni návrhu pro vývoj obchodních aplikací. Jsou oblíbené při popisu obchodních procesů díky své vizuálně samozřejmosti. Jak název napovídá, diagramy popisují posloupnost zpráv a interakcí, ke kterým dochází mezi subjekty a objekty. Aktéři nebo objekty mohou být aktivní pouze v případě potřeby nebo když s nimi chce komunikovat jiný objekt. Všechny zprávy jsou uvedeny v chronologickém pořadí.

Chcete-li získat více úplné informace, můžete zvážit příklad sekvenčního diagramu UML níže.

Jak ukazuje příklad, strukturní diagramy se používají k zobrazení struktury systému. Přesněji řečeno, jazyk se používá při vývoji softwaru k reprezentaci architektury systému a toho, jak jsou různé komponenty propojeny.

Diagram tříd UML je nejběžnějším typem diagramu pro dokumentaci softwaru. Protože většina programů vytvořených dnes je stále založena na objektově orientovaném programovacím paradigmatu, používání diagramů tříd k dokumentaci softwaru se ukazuje jako zdravý rozum. Je to proto, že OOP je založen na třídách UML a vztazích mezi nimi. Stručně řečeno, diagramy obsahují třídy spolu s jejich atributy, nazývanými také datová pole, a jejich chování, nazývané členské funkce.

Přesněji řečeno, každá třída má 3 pole: název nahoře, atributy těsně pod názvem, operace/chování dole. Vztah mezi různými třídami (reprezentovaný spojovací čarou) tvoří diagram tříd. Výše uvedený příklad ukazuje základní diagram tříd.

Objekty

Když diskutujeme o strukturních diagramech UML, je třeba se ponořit do konceptů počítačové vědy. V softwarovém inženýrství se s třídami zachází jako s abstraktními datovými typy, zatímco objekty jsou instancemi. Například, pokud existuje „Car“, což je obecný abstraktní typ, pak instance třídy „Car“ bude „Audi“.

Diagramy objektů UML pomáhají vývojářům softwaru zkontrolovat, zda vygenerovaná abstraktní struktura představuje životaschopnou strukturu, když je implementována v praxi, to znamená, když jsou objekty konkretizovány. Někteří vývojáři to považují za sekundární úroveň kontroly přesnosti. Zobrazuje instance tříd. Přesněji řečeno, generická třída "Client" má nyní skutečného klienta, například s názvem "James". James je instancí obecnější třídy a má stejné atributy, nicméně s danými hodnotami. Totéž bylo provedeno s Účty a spořicím účtem. Oba jsou objekty svých příslušných tříd.

Nasazení

Diagramy nasazení se používají k vizualizaci vztahu mezi softwarem a hardwarem. Přesněji řečeno, pomocí diagramů nasazení, které můžete sestavit fyzikální model jak jsou softwarové komponenty (artefakty) nasazeny na hardwarové komponenty známé jako uzly.

Typické schéma zjednodušeného nasazení pro webovou aplikaci by zahrnovalo:

  1. Uzly (aplikační server a databázový server).
  2. Artefakty schéma klientské aplikace a databáze.

Diagram balíčku je podobný kolekci maker pro diagramy nasazení UML, které jsme vysvětlili výše. Různé balíčky obsahují uzly a artefakty. Seskupují diagramy a komponenty modelu do skupin, podobně jako jmenný prostor zapouzdřuje různá jména, která spolu souvisí. Nakonec může být balíček postaven na několika dalších balících, které reprezentují složitější systémy a chování.

Hlavním účelem diagramu balíčku je ukázat vztahy mezi různými velkými komponentami, které tvoří složitý systém. Programátoři tuto funkci abstrakce najdou dobrá výhoda pro použití diagramů balíků, zvláště když některé detaily mohou být vyloučeny z celkového obrazu.

Jako každá jiná věc v životě, abyste něco udělali správně, potřebujete správné nástroje. Nástroje, které nabízejí UML anotace a šablony diagramů, se používají k dokumentaci softwaru, procesů nebo systémů. K dispozici jsou různé dokumentační nástroje software, který vám může pomoci nakreslit diagram.

Obvykle spadají do následujících hlavních kategorií:

  1. Papír a pero jsou snadné. Vezměte papír a pero, otevřete UML syntaktický kód z internetu a nakreslete libovolný typ diagramu, který potřebujete.
  2. Online nástroje – Existuje několik online aplikací, které můžete použít k vytvoření grafu. Většina z nich nabízí placené předplatné nebo omezený počet diagramů na bezplatné úrovni.
  3. Bezplatné online nástroje jsou téměř stejné jako ty placené. Hlavní rozdíl je v tom, že nabízejí i placené učební pomůcky A hotové šablony pro konkrétní diagramy.
  4. Desktopová aplikace – Typickou desktopovou aplikací pro diagramy a téměř všechny další diagramy je Microsoft Visio. Nabízí pokročilé funkce a funkce. Jedinou nevýhodou je, že za to musíte zaplatit.

Je tedy zcela zřejmé, že UML je důležitým aspektem spojeným s objektově orientovaným vývojem softwaru. K vytváření vizuálních modelů systémových programů využívá grafickou notaci.

UML neboli Unified Modeling Language je grafický popisný jazyk pro objektové modelování v oblasti vývoje softwaru. Využití UML se ale neomezuje pouze na IT, další velkou oblastí praktické aplikace UML je modelování obchodních procesů, návrh systému a mapování organizačních struktur. UML umožňuje vývojářům softwaru dohodnout se na grafické notaci pro reprezentaci obecné pojmy a zaměřit se na design a vývoj.

Výhody UML

  • UML používá grafické zápisy pro prvky modelovaného systému a diagramy UML jsou poměrně snadno pochopitelné;
  • UML umožňuje popisovat systémy téměř ze všech možných úhlů pohledu s přihlédnutím k různým aspektům;
  • UML je objektově orientovaný: jeho metody analýzy a konstrukce jsou sémanticky blízké metodám programování používaným v moderní jazyky OOP;
  • UML je otevřený standard. Norma se vyvíjí a vyvíjí od verze k verzi, splňující nejmodernější požadavky na popis systémů;
  • obsahuje rozšiřující mechanismus, který umožňuje zadávat další textové a grafické typy, což umožňuje používat UML nejen v oblasti IT.

Typy diagramů UML

V UML existuje 14 typů diagramů. Lze je rozdělit do 2 kategorií:

  • strukturální, zastupující informační struktura;
  • behaviorální, představující chování systému a různé aspekty interakcí. Zvažuje se samostatný podtyp diagramů chování interakční diagramy.

Hierarchie typů UML diagramů, reprezentovaný diagramem tříd

Strukturní diagramy

  1. Diagram tříd je klíčovým prvkem v objektově orientovaném modelování. Pomocí tohoto diagramu (ve skutečnosti přes třídy, jejich atributy, metody a závislosti mezi třídami) popisuje doménový model a strukturu modelovaného systému.
  2. Schéma součásti zobrazuje členění programového kódu na velké bloky (strukturální komponenty) a ukazuje závislosti mezi nimi. Komponenty mohou být balíčky, moduly, knihovny, soubory atd.
  3. Schéma objektu zobrazuje úplný nebo částečný řez simulovaného systému v daném časovém okamžiku. Představuje instance tříd (objekty), jejich stav (aktuální hodnoty atributů) a vztahy mezi nimi.
  4. Schéma složené struktury demonstruje vnitřní strukturu tříd a tam, kde je to možné, interakce mezi prvky této struktury.
  5. Schéma balíčku zobrazuje balíčky a vztahy mezi nimi. Tento typ diagramu slouží ke zjednodušení struktury modelu (a tedy i práce s ním) slučováním prvků modelu do skupin podle určitých kritérií.
  6. Schéma nasazení modeluje nasazení softwarových komponent ( artefakty) na výpočetní prostředky/hardwarové komponenty ( uzly).
  7. Profilový diagram popisuje mechanismus rozšíření, který umožňuje přizpůsobit UML různým oborům a odvětvím.

Příklad diagramu tříd UML

Diagramy chování

  1. Diagram aktivity ukazuje akce ( akce), ze kterých se skládá nějaká činnost ( aktivita). Diagramy aktivit se používají k modelování obchodních procesů, technologické procesy, sekvenční a paralelní výpočty.
  2. Schéma případu použití(nebo schéma případu použití) popisuje vztah mezi aktéry (aktéry) a případy použití modelovaného systému (jeho schopnosti). Hlavním účelem diagramu je být univerzálním nástrojem pro zákazníky, vývojáře a koncové uživatele ke společné diskusi o systému - jeho schopnostech a chování.
  3. Stavový diagram zobrazuje dynamické chování entity a ukazuje, jak na ní tato entita závisí aktuální stav reaguje na různé události. Toto je v podstatě stavový diagram z atomové teorie.
  4. Komunikační schéma(v dřívějších verzích diagram spolupráce) ukazuje interakce mezi částmi kompozitní struktury a rolemi spolupráce. Diagram explicitně ukazuje vztahy mezi prvky (objekty).
  5. Sekvenční diagram slouží k vizualizaci sledu interakcí objektů. Ukazuje životní cyklus daného objektu a interakci aktérů (herců) v rámci určitého případu užití, sekvenci zpráv, které si vyměňují.
  6. Diagram přehledu interakce zahrnuje část sekvenčního diagramu a návrh řídicího toku. Pomáhá uvažovat o interakci objektů z různých úhlů pohledu.
  7. Časový diagram- samostatný podtyp interakčních diagramů se specializací na časování. Diagramy tohoto typu se používají ke studiu chování objektů za určité časové období.