Príklady Uml diagramov. UML diagram

UML alebo Unified Modeling Language je grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvér. Použitie UML sa však neobmedzuje len na IT, ďalšou veľkou oblasťou praktickej aplikácie UML je modelovanie obchodných procesov, návrh systému a mapovanie organizačných štruktúr.

UML umožňuje vývojárom softvéru dohodnúť sa na grafických zápisoch reprezentujúcich spoločné koncepty a zamerať sa na dizajn a vývoj.

• Výhody UML
• UML používa grafické označenia prvkov modelovaného systému a diagramy UML sú pomerne ľahko pochopiteľné;
• UML umožňuje popisovať systémy takmer zo všetkých možných uhlov pohľadu, berúc do úvahy rôzne aspekty;
• UML je objektovo orientovaný: jeho metódy analýzy a konštrukcie sú sémanticky blízke programovacím metódam používaným v moderných jazykoch OOP;
• UML je otvorený štandard. Norma sa vyvíja a vyvíja od verzie k verzii, pričom spĺňa najmodernejšie požiadavky na popis systémov;

obsahuje rozširujúci mechanizmus, ktorý umožňuje zadávať ďalšie textové a grafické typy, čo umožňuje využívať UML nielen v IT oblasti.

Typy diagramov UML

• V UML existuje 14 typov diagramov. Možno ich rozdeliť do 2 kategórií:štrukturálne
• , predstavujúci informačnú štruktúru; behaviorálna , predstavujúce správanie systému a rôzne aspekty interakcií. Zvažuje sa samostatný podtyp diagramov správania.

interakčné diagramy Hierarchia typov,
UML diagramy

reprezentovaný diagramom tried

1. Štruktúrne diagramy Diagram triedy je kľúčovým prvkom v objektovo orientovanom modelovaní. Pomocou tohto diagramu (v skutočnosti cez triedy , ich, atribúty metódy
2. a závislosti medzi triedami) popisuje doménový model a štruktúru modelovaného systému. Diagram komponentov zobrazí rozdelenie programový kód do veľkých blokov (štrukturálnych komponentov) a show závislosti
3. medzi nimi. Komponenty môžu byť balíky, moduly, knižnice, súbory atď. Schéma objektu
4. zobrazuje úplný alebo čiastočný výsek simulovaného systému v danom časovom bode. Predstavuje inštancie tried (objekty), ich stav (aktuálne hodnoty atribútov) a vzťahy medzi nimi. demonštruje vnútornú štruktúru tried a tam, kde je to možné, interakcie medzi prvkami tejto štruktúry.
5. Schéma balíka zobrazuje balíčky a vzťahy medzi nimi. Tento typ diagramu slúži na zjednodušenie štruktúry modelu (a teda aj práce s ním) kombinovaním prvkov modelu do skupín podľa určitých kritérií.
6. Schéma nasadenia modeluje nasadenie softvérových komponentov ( artefakty) o výpočtových zdrojoch/hardvérových komponentoch ( uzly).
7. Profilový diagram opisuje mechanizmus rozšírenia, ktorý umožňuje prispôsobiť UML rôznym témam a odvetviam.

Príklad diagramu tried UML

Diagramy správania

1. Diagram aktivity zobrazuje akcie ( akcie), z ktorých určitá činnosť pozostáva ( činnosť). Diagramy činností sa používajú na modelovanie obchodných procesov, technologických procesov, sekvenčných a paralelných výpočtov.
2. Diagram prípadu použitia(alebo diagram prípadu použitia) popisuje vzťah medzi aktérmi (aktérmi) a prípadmi použitia modelovaného systému (jeho schopnosti).
3. Hlavným účelom diagramu je byť univerzálnym nástrojom pre zákazníkov, vývojárov a koncových používateľov na spoločnú diskusiu o systéme – jeho schopnostiach a správaní. Stavový diagram
4. zobrazuje dynamické správanie entity, ukazuje, ako táto entita v závislosti od jej aktuálneho stavu reaguje na rôzne udalosti. Toto je v podstate stavový diagram z teórie atómov. Komunikačný diagram(v starších verziách
5. diagram spolupráce) ukazuje interakcie medzi časťami zloženej štruktúry a rolami spolupráce. Diagram explicitne naznačuje vzťahy medzi prvkami (objektmi).
6. Sekvenčný diagram slúži na vizualizáciu postupnosti interakcií objektov. Zobrazuje životný cyklus daného objektu a interakciu aktérov (hercov) v rámci určitého prípadu použitia, postupnosť správ, ktoré si vymieňajú.
7. Diagram prehľadu interakcií zahŕňa časť sekvenčného diagramu a návrh riadiaceho toku. Pomáha zvážiť interakciu objektov z rôznych uhlov pohľadu.

Všetky UML diagramy možno rozdeliť do dvoch skupín, z ktorých prvá je všeobecný diagram. Všeobecné diagramy sú prakticky nezávislé od predmetu modelovania a možno ich použiť v akomkoľvek softvérovom projekte bez ohľadu na predmet, oblasť riešenia a pod.

1.5.1. Diagram použitia

Diagram použitia(diagram prípadov použitia) je najvšeobecnejším znázornením funkčného účelu systému.

Diagram použitia je navrhnutý tak, aby odpovedal na hlavnú otázku modelovania: čo robí systém vo vonkajšom svete?

Diagram použitia používa dva typy základných entít: prípady použitia 1 a aktérov 2, medzi ktorými sú vytvorené tieto základné typy vzťahov:

• asociácia medzi aktérom a prípadom použitia 3 ;
• zovšeobecňovanie medzi aktérmi 4 ;
• zovšeobecňovanie medzi prípadmi použitia 5 ;
• závislosti (rôzneho typu) medzi prípadmi použitia 6.

Diagram použitia, ako každý iný diagram, môže obsahovať komentáre 7 . Okrem toho sa to dôrazne odporúča na zlepšenie čitateľnosti diagramov.

Hlavné prvky notácie použité v diagrame použitia sú uvedené nižšie. Podrobný popis uvedené v časti 2.2.

1.5.2. Diagram triedy

Štruktúrne diagramy(diagram tried) je hlavným spôsobom popisu štruktúry systému.

To nie je prekvapujúce, pretože UML je primárne objektovo orientovaný jazyk a triedy sú hlavným (ak nie jediným) stavebným kameňom.

Diagram tried používa jeden základný typ entity: triedy 1 (vrátane mnohých špeciálnych prípadov tried: rozhrania, primitívne typy, asociačné triedy a mnohé ďalšie), medzi ktorými sú vytvorené nasledujúce základné typy vzťahov:

• spojenie medzi 2 triedami (s množstvom ďalších podrobností);
• zovšeobecňovanie medzi triedami 3;
• závislosti (rôzneho typu) medzi triedami 4 a medzi triedami a rozhraniami.

Niektoré zo zápisov použitých v diagrame tried sú uvedené nižšie. Podrobný popis je uvedený v kapitole 3.

1.5.3. Schéma stroja

Schéma stroja(diagram stavového automatu) je jedným zo spôsobov, ako podrobne opísať správanie v UML na základe explicitnej identifikácie stavov a opisu prechodov medzi stavmi.

V podstate, automatové diagramy, ako už názov napovedá, sú grafom prechodov stavov (pozri kapitolu 4) s množstvom ďalších detailov a detailov.

V diagrame automatov sa používa jeden hlavný typ entity - stavy 1 a jeden typ vzťahu - prechody 2, ale pre oba je definovaných veľa odrôd, špeciálnych prípadov a dodatočných zápisov. Vypisovať ich všetky v úvodnej recenzii nemá zmysel.

Podrobný popis všetkých variácií diagramov automatov je uvedený v časti 4.2 a nasledujúci obrázok zobrazuje iba hlavné prvky zápisu použitého v diagrame automatu.

1.5.4. Diagram aktivity

Diagram aktivity(diagram aktivít) – spôsob opisu správania založený na špecifikácii riadiacich tokov a dátových tokov.

Diagram aktivity je ďalším spôsobom, ako opísať správanie, ktoré vizuálne pripomína starý dobrý vývojový diagram algoritmu. Vďaka modernizovanému zápisu konzistentnému s objektovo orientovaným prístupom a čo je najdôležitejšie, vďaka novej sémantickej zložke (voľná interpretácia Petriho sietí) je však diagram aktivity UML silným nástrojom na popis správania systému.

Diagram aktivity používa jeden hlavný typ entity – akcia 1 a jeden typ vzťahu – prechody 2 (prenosy kontroly a údajov). Používajú sa aj také konštrukcie ako forks, mergers, connection, branch 3, ktoré sú podobné entitám, ale v skutočnosti nimi nie sú, ale sú grafickým spôsobom znázornenia niektorých špeciálnych prípadov viacmiestových vzťahov. Sémantika prvkov diagramu aktivít je podrobne popísaná v kapitole 4. Hlavné prvky notácie použité v diagrame aktivít sú uvedené nižšie.

1.5.5. Sekvenčný diagram

diagram spolupráce(sekvenčný diagram) je spôsob popisu správania systému založený na udávaní postupnosti prenášaných správ.

V skutočnosti je sekvenčný diagram záznamom protokolu konkrétnej relácie systému (alebo fragmentu takéhoto protokolu). V objektovo orientovanom programovaní je najdôležitejšou vecou za behu odovzdávanie správ medzi komunikujúcimi objektmi. V tomto diagrame je zobrazená postupnosť odosielania správ, odtiaľ názov.

Sekvenčný diagram používa jeden hlavný typ entity – inštancie interagujúcich klasifikátorov 1 (hlavne triedy, komponenty a aktéri) a jeden typ vzťahu – spojenia 2, cez ktoré sa vymieňajú správy 3. Existuje niekoľko spôsobov odosielania správ, ktoré sa v grafickom zápise líšia typom šípky zodpovedajúcej vzťahu.

Dôležitým aspektom sekvenčného diagramu je jasné zobrazenie plynutia času. Na rozdiel od iných typov diagramov, snáď okrem synchronizačných diagramov, v sekvenčnom diagrame je dôležitá nielen prítomnosť grafických spojení medzi prvkami, ale aj relatívna poloha prvkov na diagrame. Konkrétne sa predpokladá, že existuje (neviditeľná) časová os, štandardne smerovaná zhora nadol a správa, ktorá sa odošle neskôr, je nakreslená nižšie.

Časová os môže byť nasmerovaná horizontálne, v tomto prípade sa čas považuje za plynúci zľava doprava.

Nasledujúci obrázok ukazuje základnú notáciu použitú v sekvenčnom diagrame. Na označenie samotných interagujúcich objektov sa používa štandardný zápis - obdĺžnik s názvom inštancie klasifikátora. Bodkovaná čiara, ktorá z nej vychádza, sa nazýva záchranná čiara 4. Toto nie je znázornenie vzťahu v modeli, ale grafický komentár navrhnutý tak, aby naviedol čitateľa diagramu správnym smerom. Postavy vo forme úzkych pruhov prekrývajúcich sa na línii života tiež nie sú obrazmi modelovaných entít. Toto je grafický komentár zobrazujúci časové úseky, počas ktorých objekt vlastní riadiaci tok (výskyt vykonávania) 5 alebo inými slovami, prebieha aktivácia objektu. Kroky 6 kombinovaného fragmentu umožňujú, aby sekvenčný diagram odrážal algoritmické aspekty interakčného protokolu. Ďalšie podrobnosti o zápise sekvenčného diagramu nájdete v kapitole 4.

1.5.6. Komunikačný diagram

zobrazuje dynamické správanie entity, ukazuje, ako táto entita v závislosti od jej aktuálneho stavu reaguje na rôzne udalosti.(komunikačný diagram) je spôsob popisu správania, ktorý je sémanticky ekvivalentný sekvenčnému diagramu.

V skutočnosti ide o rovnaký opis postupnosti výmeny správ interagujúcich inštancií klasifikátorov, len vyjadrený inými grafickými prostriedkami. Navyše väčšina nástrojov dokáže automaticky previesť sekvenčné diagramy na komunikačné diagramy a naopak.

V komunikačnom diagrame, ako aj v sekvenčnom diagrame sa teda používa jeden hlavný typ entity - inštancie interagujúcich klasifikátorov 1 a jeden typ vzťahu - spojenia 2.

Obrázok ukazuje hlavné prvky notácie použité v komunikačnom diagrame. Na označenie samotných interagujúcich objektov sa používa štandardný zápis - obdĺžnik s názvom inštancie klasifikátora. Relatívna poloha prvkov v diagrame spolupráce nezáleží - dôležité sú len spojenia (najčastejšie prípady asociácií), po ktorých sa správy prenášajú 3 . Hierarchické desiatkové číslovanie sa používa na zobrazenie poradia správ v čase.

1.5.7. Diagram komponentov

a závislosti medzi triedami) popisuje doménový model a štruktúru modelovaného systému.(diagram komponentov) – zobrazuje vzťahy medzi modulmi (logickými alebo fyzickými), ktoré tvoria modelovaný systém.

Hlavným typom entít v diagrame komponentov sú samotné komponenty 1, ako aj rozhrania 2, cez ktoré je naznačený vzťah medzi komponentmi. V diagrame komponentov platia nasledujúce vzťahy:

• implementácie medzi komponentmi a rozhraniami (komponent implementuje rozhranie);
• závislosti medzi komponentmi a rozhraniami (komponent používa rozhranie) 3.

Obrázok ukazuje hlavné prvky zápisu použitého v diagrame komponentov. Podrobný popis je uvedený v kapitole 3.

1.5.8. Schéma umiestnenia

Schéma umiestnenia(diagram nasadenia) spolu so zobrazením zloženia a prepojení prvkov systému ukazuje, ako sú fyzicky umiestnené na výpočtových zdrojoch za behu.

V diagrame umiestnenia sú teda v porovnaní s diagramom komponentov pridané dva typy entít: artefakt 1, ktorý je implementáciou komponentu 2 a uzla 3 (môže to byť buď klasifikátor popisujúci typ uzla alebo konkrétna inštancia), ako aj asociačný vzťah medzi uzlami 4, čo ukazuje, že uzly sú fyzicky spojené za behu.

Obrázok ukazuje hlavné prvky notácie použitej v diagrame rozloženia. Aby sa ukázalo, že jedna entita je súčasťou inej entity, použije sa buď vzťah závislosti „nasadenia“ 5 , alebo sa postava jednej entity umiestni do postavy inej entity 6 . Podrobný popis schémy je uvedený v kapitole 3.

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnutý tak, aby podporoval proces modelovania softvéru založeného na prístupe OO, organizoval vzťah koncepčných a programových konceptov a odrážal problémy so škálovaním. komplexné systémy. Modely UML sa používajú vo všetkých fázach životného cyklu softvéru, od obchodnej analýzy až po údržbu systému. Rôzne organizácie môžu použiť UML podľa vlastného uváženia v závislosti od svojich problémových oblastí a použitých technológií.

Stručná história UML

Do polovice 90. rokov navrhli rôzni autori niekoľko desiatok metód OO modelovania, z ktorých každá používala svoj vlastný grafický zápis. Každá z týchto metód mala zároveň svoje silné stránky, ale neumožňovala vybudovať dostatočne úplný model PS, ktorý by ho ukazoval „zo všetkých strán“, teda všetky potrebné projekcie (pozri článok 1). Okrem toho nedostatok štandardu modelovania OO sťažoval vývojárom výber najvhodnejšej metódy, čo bránilo širokému prijatiu prístupu OO k vývoju softvéru.

Na žiadosť Object Management Group (OMG), organizácie zodpovednej za prijímanie štandardov v oblasti objektových technológií a databáz, naliehavý problém zjednotenia a štandardizácie vyriešili autori troch najpopulárnejších metód OO - G Butch, D. Rambo a A. Jacobson, ktorí spoločnými silami vytvorili verziu UML 1.1, schválenú OMG v roku 1997 ako štandard.

UML je jazyk

Akýkoľvek jazyk pozostáva zo slovnej zásoby a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takto sú štruktúrované najmä programovacie jazyky, ako napríklad UML. Jeho charakteristickým znakom je, že jazykový slovník tvoria grafické prvky. Každý grafický symbol má špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jasne pochopený iným, a tiež softvér, interpretácia UML. Z tohto konkrétne vyplýva, že softvérový model prezentovaný v UML možno automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda ak existuje dobrý nástroj na vizuálne modelovanie, ktorý podporuje UML, postavili model, dostaneme aj vzorový programový kód zodpovedajúci tomuto modelu.

Treba zdôrazniť, že UML je jazyk, nie metóda. Vysvetľuje, z akých prvkov vytvárať modely a ako ich čítať, ale nehovorí nič o tom, ktoré modely by sa mali vyvíjať a v akých prípadoch. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja softvéru. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v nasledujúcich článkoch.

Slovník UML

Model je znázornený vo forme entít a vzťahov medzi nimi, ktoré sú znázornené v diagramoch.

entity sú abstrakcie, ktoré sú hlavnými prvkami modelov. Existujú štyri typy entít – štrukturálne (trieda, rozhranie, komponent, prípad použitia, spolupráca, uzol), behaviorálne (interakcia, stav), zoskupovanie (balíky) a anotácia (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne prediskutované pri štúdiu diagramov.

Vzťah ukazujú rôzne prepojenia medzi entitami. UML definuje nasledujúce typy vzťahov:

• Závislosť ukazuje také prepojenie dvoch entít, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou od závislej entity k nezávislej.
• asociácie je štrukturálny vzťah ukazujúci, že objekty jednej entity súvisia s objektmi inej entity. Graficky je asociácia znázornená ako čiara spájajúca pridružené entity. Asociácie slúžia na navigáciu medzi objektmi. Napríklad spojenie medzi triedami „Objednávka“ a „Produkt“ môže byť použité na nájdenie všetkých produktov špecifikovaných v konkrétnej objednávke na jednej strane alebo na nájdenie všetkých objednávok, ktoré obsahujú tento produkt, na strane druhej. Je jasné, že príslušné programy musia implementovať mechanizmus, ktorý takúto navigáciu zabezpečí. Ak je potrebná navigácia iba jedným smerom, je to označené šípkou na konci priradenia. Špeciálnym prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený diamantom na konci blízko esencie-celku.
• Zovšeobecnenie je vzťah medzi nadradenou entitou a podriadenou entitou. Tento vzťah v podstate odráža vlastnosť dedičnosti pre triedy a objekty. Zovšeobecnenie je znázornené ako čiara končiaca trojuholníkom smerujúcim k nadradenej entite. Dieťa zdedí štruktúru (atribúty) a správanie (metódy) rodiča, no zároveň môže mať nové prvky štruktúry a nové metódy. UML umožňuje viacnásobné dedičstvo, keď entita súvisí s viac ako jednou nadradenou entitou.
• Implementácia– vzťah medzi entitou, ktorá definuje špecifikáciu správania (interface) s entitou, ktorá definuje implementáciu tohto správania (trieda, komponent). Tento vzťah sa bežne používa pri modelovaní komponentov a bude podrobnejšie popísaný v nasledujúcich článkoch.

Diagramy. UML poskytuje nasledujúce diagramy:

• Diagramy popisujúce správanie systému:
• Stavové diagramy
• diagramy aktivít,
• Diagramy objektov,
• sekvenčné diagramy,
• Diagramy spolupráce;
• Diagramy popisujúce fyzickú implementáciu systému:
• Schémy komponentov;
• Schémy nasadenia.

Zobrazenie ovládania modelu. Balíčky.

Už sme si povedali, že na to, aby bol model pre ľudí dobre pochopený, je potrebné ho usporiadať hierarchicky, pričom na každej úrovni hierarchie zostane malý počet entít. UML obsahuje prostriedky na organizáciu hierarchickej reprezentácie modelu – balíkov. Každý model pozostáva zo sady balíkov, ktoré môžu obsahovať triedy, prípady použitia a iné entity a diagramy. Balík môže obsahovať ďalšie balíky, čo umožňuje vytváranie hierarchií. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balíček je vyobrazený ako obdĺžnik so záložkou.

Čo poskytuje UML.

• hierarchický popis komplexného systému identifikáciou balíkov;
• formalizácia funkčných požiadaviek na systém pomocou aparátu prípadov použitia;
• spresnenie systémových požiadaviek vytvorením diagramov činností a scenárov;
• identifikácia dátových tried a zostavenie koncepčného dátového modelu vo forme diagramov tried;
• identifikácia tried, ktoré popisujú užívateľské rozhranie a vytvorenie schémy navigácie na obrazovke;
• opis procesov interakcie objektov pri vykonávaní systémových funkcií;
• popis správania sa objektu vo forme diagramov aktivít a stavov;
• popis softvérových komponentov a ich interakcia prostredníctvom rozhraní;
• popis fyzickej architektúry systému.

A posledná vec...

Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom softvérovom modelovaní bez nástrojov na vizuálne modelovanie. Takéto nástroje vám umožňujú rýchlo prezentovať diagramy na obrazovke, dokumentovať ich, vytvárať šablóny programového kódu v rôznych programovacích jazykoch OO a vytvárať databázové schémy. Väčšina z nich obsahuje možnosť reengineeringu programových kódov - obnovenie určitých projekcií modelu PS automatická analýza zdrojové kódy programov, čo je veľmi dôležité na zabezpečenie súladu medzi modelom a kódmi a pri navrhovaní systémov, ktoré dedia funkčnosť predchádzajúcich systémov.

        Unified Modeling Language (UML) je jazyk na špecifikovanie, vizualizáciu, konštrukciu a dokumentáciu softvérových systémov, ako aj obchodných modelov a iných nesoftvérových systémov. UML je kombináciou inžinierskych techník, ktoré boli predtým úspešne použité na modelovanie veľkých a zložitých systémov

        Tvorcovia UML ho prezentujú ako jazyk na definovanie, reprezentáciu, navrhovanie a dokumentovanie softvérových systémov, podnikových systémov a iných systémov rôzneho charakteru. UML definuje notáciu a metamodel. Notácia je zbierka grafických objektov, ktoré sa používajú v modeloch; je to syntax modelovacieho jazyka.

        UML poskytuje expresívne nástroje na vytváranie vizuálne modely, ktorý:

• sú jednotne chápané všetkými vývojármi zapojenými do projektu;
• sú prostriedkom komunikácie v rámci projektu.

        Unified Modeling Language (UML):

• nezávisí od objektovo orientovaných (OO) programovacích jazykov;
• nezávisí od použitej metodiky vývoja projektu;
• môže podporovať akýkoľvek programovací jazyk OO.

        UML je otvorený a má nástroje na rozšírenie základného jadra. UML možno použiť na zmysluplný opis tried, objektov a komponentov v rôznych tematických oblastiach, ktoré sa od seba často veľmi líšia.

UML diagramy

        Rational Rose poskytuje dizajnérovi systému k dispozícii nasledujúce typy diagramov, ktorých postupné vytváranie umožňuje získať úplný obraz o celom navrhnutom systéme a jeho jednotlivých komponentoch:

• Diagram prípadu použitia;
• Diagram rozmiestnenia (topologické diagramy);
• stavový diagram;
• Interakčný diagram; Diagram aktivity;
• Sekvenčný diagram;
• Diagram spolupráce;
• diagram tried;
• Diagram komponentov (diagramy komponentov);
• Schémy správania;
• Diagram aktivity;
• Implementačné schémy;

        Každý z týchto diagramov špecifikuje rôzne predstavy o modeli systému. Diagram prípadov použitia zároveň predstavuje konceptuálny model systému, ktorý je východiskom pre konštrukciu všetkých ostatných diagramov. Diagram tried je logický model, ktorý odráža statické aspekty štrukturálneho návrhu systému a diagramy správania, ktoré sú tiež variáciami logického modelu, odrážajú dynamické aspekty jeho fungovania. Implementačné diagramy slúžia na znázornenie komponentov systému a odkazujú na jeho fyzický model.

        Niektoré z vyššie uvedených diagramov slúžia na označenie dvoch alebo viacerých poddruhov. Nasledujúce diagramy sa používajú ako nezávislé reprezentácie: prípady použitia, triedy, stavy, aktivity, sekvencie, spolupráca, komponenty a nasadenie.

        Pre UML diagramy existujú tri typy vizuálnych symbolov, ktoré sú dôležité z hľadiska informácií, ktoré obsahujú:

• komunikácie, ktoré sú v rovine znázornené rôznymi čiarami;
• text, obsiahnuté v hraniciach jednotlivých geometrických útvarov;
• grafické symboly, zobrazené v blízkosti vizuálnych prvkov diagramov.

        Pri grafickom znázornení diagramov sa odporúča dodržiavať nasledujúce pravidlá:

• každý diagram musí byť úplnou reprezentáciou nejakého fragmentu modelovanej predmetnej oblasti;
• modelové entity prezentované na diagrame musia mať rovnakú koncepčnú úroveň;
• všetky informácie o subjektoch musia byť jasne uvedené na diagrame;
• diagramy by nemali obsahovať protichodné informácie;
• diagramy by nemali byť preťažené textovými informáciami;
• každý diagram musí byť sebestačný na správnu interpretáciu všetkých jeho prvkov;
• počet typov diagramov potrebných na popis konkrétneho systému nie je presne stanovený a určuje ho vývojár;
• systémové modely by mali obsahovať len tie prvky, ktoré sú definované v notácii UML.

Entity v UML

        V UML sú definované štyri typy entít: štrukturálne, behaviorálne, zoskupovanie a anotácia. Entity sú hlavnými objektovo orientovanými prvkami jazyka, pomocou ktorého sa vytvárajú modely.

        Štrukturálne entity sú podstatné mená v modeloch UML. Typicky predstavujú statické časti modelu zodpovedajúce koncepčným alebo fyzickým prvkom systému. Príkladmi štrukturálnych entít sú „trieda“, „rozhranie“, „spolupráca“, „prípad použitia“, „komponent“, „uzol“, „aktér“.

        Entity správania sú dynamické komponenty modelu UML. Sú to slovesá, ktoré opisujú správanie modelu v čase a priestore. Existujú dva hlavné typy subjektov správania:

• interakcia je správanie, ktorého podstatou je výmena správ medzi objektmi v rámci špecifického kontextu na dosiahnutie konkrétneho cieľa;
• automat - behaviorálny algoritmus, ktorý definuje postupnosť stavov, ktorými objekt alebo interakcia prechádza v reakcii na rôzne udalosti.

        Zoskupovanie entít sú organizačné časti modelu UML. Sú to bloky, na ktoré je možné model rozložiť. Takáto primárna entita existuje v jedinej kópii – toto je balík.

        Balíky sú univerzálnym mechanizmom na organizovanie prvkov do skupín. Štrukturálne, behaviorálne a iné zoskupovacie entity môžu byť umiestnené v balíku. Na rozdiel od komponentov, ktoré skutočne existujú počas spustenia programu, balíky majú čisto koncepčný charakter, to znamená, že existujú iba počas procesu vývoja.

        Entity anotácie- toto sú vysvetľujúce časti modelu UML: komentáre pre dodatočný popis, vysvetlenie alebo komentár k akémukoľvek prvku modelu. Existuje len jeden základný typ prvku anotácie – poznámka. Poznámky sa používajú na poskytnutie diagramov s komentármi alebo obmedzeniami, vyjadrené v neformálnom alebo formálnom texte.

Vzťahy v UML

        V jazyku UML sú definované nasledujúce typy vzťahov: závislosť, asociácia, zovšeobecnenie a implementácia. Tieto vzťahy sú hlavnými spojovacími konštrukciami UML a používajú sa aj ako entity na vytváranie modelov.

        Závislosť- ide o sémantický vzťah medzi dvoma entitami, v ktorom zmena jednej z nich, nezávislej, môže ovplyvniť sémantiku druhej, závislej.

        asociácie- štruktúrny vzťah, ktorý opisuje súbor sémantických alebo logických súvislostí medzi objektmi.

        Zovšeobecnenie je vzťah, v ktorom môže byť objekt špecializovaného prvku (potomok) nahradený objektom všeobecného prvku (predok). Zároveň v súlade s princípmi objektovo orientovaného programovania potomok (dieťa) zdedí štruktúru a správanie svojho predka (rodiča).

        Realizácia je sémantický vzťah medzi klasifikátormi, v ktorom jeden klasifikátor definuje povinnosť a druhý zaručuje jej splnenie. Implementačné vzťahy sa vyskytujú v dvoch prípadoch:

• medzi rozhraniami a triedami alebo komponentmi, ktoré ich implementujú;
• medzi precedensmi a spoluprácami, ktoré ich realizujú.

Spoločné mechanizmy UML

        Na presný popis systému v UML sa používajú takzvané všeobecné mechanizmy:

• špecifikácie;
• doplnky (ozdoby);
• spoločné delenia;
• rozšírenia (mechanizmy rozšíriteľnosti).

        UML nie je len grafický jazyk. Za každým grafickým prvkom je jeho zápis špecifikácia, obsahujúci textovú reprezentáciu zodpovedajúceho jazykového konštruktu. Napríklad ikona triedy má špecifikáciu, ktorá popisuje jej atribúty, operácie a správanie, hoci vizuálne, v diagrame, ikona často odráža len malú časť týchto informácií. Model môže navyše obsahovať inú reprezentáciu tejto triedy, odrážajúc jej úplne iné aspekty, no napriek tomu v súlade so špecifikáciou. Grafická notácia UML sa teda používa na vizualizáciu systému a pomocou špecifikácií na popis jeho detailov.

        Takmer každý prvok UML má jedinečné grafické znázornenie, ktoré poskytuje vizuálnu reprezentáciu jeho najdôležitejších charakteristík. Zápis entity „trieda“ obsahuje jej názov, atribúty a operácie. Špecifikácia triedy môže obsahovať ďalšie podrobnosti, ako napríklad viditeľnosť atribútov a operácií, komentáre alebo označenie, že trieda je abstraktná. Mnohé z týchto detailov je možné zobraziť ako grafiku alebo text. dodatky na štandardný obdĺžnik, ktorý predstavuje triedu.

        Pri modelovaní objektovo orientovaných systémov existuje určitá divízie zastúpené subjekty.

        Po prvé, je tu rozdelenie na triedy a objekty. Trieda je abstrakcia a objekt je konkrétnym stelesnením tejto abstrakcie. V tomto smere sa takmer všetky jazykové konštrukty vyznačujú dualitou triedy/objektu. Existujú teda precedensy a inštancie precedensov, komponenty a inštancie komponentov, uzly a inštancie uzlov. V grafickom znázornení je zvykom používať rovnaký symbol pre objekt ako pre triedu a podčiarknuť názov.

        Po druhé, je tu rozdelenie na rozhranie a jeho implementáciu. Rozhranie deklaruje záväzky a implementácia predstavuje konkrétnu implementáciu týchto záväzkov a zabezpečuje presné dodržiavanie deklarovanej sémantiky. Z tohto dôvodu sa takmer všetky konštrukty UML vyznačujú dualitou rozhrania/implementácie. Napríklad precedensy sa realizujú spoluprácou a operácie sa realizujú metódami.

        UML je otvorený jazyk, to znamená, že umožňuje kontrolovaným rozšíreniam odrážať vlastnosti doménových modelov.

        Mechanizmy rozšírenia UML zahŕňajú:

• stereotypy (stereotypy) - rozširujú slovnú zásobu UML, umožňujúcu vytvárať nové na základe existujúcich jazykových prvkov, zamerané na riešenie konkrétneho problému;
• označené hodnoty - rozširujú vlastnosti základných konštruktov UML, čo umožňuje zahrnúť ďalšie informácie do špecifikácie prvku;
• obmedzenia (obmedzenia) - rozširujú sémantiku konštruktov UML, umožňujú vytvárať nové a rušiť existujúce pravidlá.

        Tieto tri mechanizmy rozšírenia jazyka spolu umožňujú upravovať ho v súlade s potrebami projektu alebo vlastnosťami vývojovej technológie.

Schéma prípadu použitia

        Tento typ diagramu vám umožňuje vytvoriť zoznam operácií, ktoré systém vykonáva. Často sa tento typ diagramu nazýva funkčný diagram, pretože na základe súboru takýchto diagramov sa vytvorí zoznam požiadaviek na systém a určí sa súbor funkcií, ktoré systém vykonáva.

        Diagramy prípadov použitia opisujú funkčnosť systému alebo to, čo má systém robiť. Vývoj diagramu má nasledujúce ciele:

• určiť všeobecné hranice a kontext modelovaného predmetu;
• formulovať všeobecné požiadavky na funkčné správanie navrhnutého systému;
• vypracovať prvotný koncepčný model systému pre jeho následné spresnenie vo forme logických a fyzických modelov;
• pripraviť počiatočnú dokumentáciu pre interakciu vývojárov systému s jeho zákazníkmi a používateľmi.

        Podstata diagramu prípadov použitia je nasledovná. Navrhovaný systém je reprezentovaný ako súbor entít alebo aktérov, ktorí interagujú so systémom prostredníctvom prípadov použitia. V tomto prípade je aktérom alebo aktérom akákoľvek entita, ktorá interaguje so systémom zvonku. Môže to byť osoba technické zariadenie, program alebo akýkoľvek iný systém, ktorý môže slúžiť ako zdroj vplyvu na simulovaný systém určený samotným vývojárom. Prípad použitia slúži na popis služieb, ktoré systém poskytuje aktérovi.

        Účelom prípadu použitia je definovať úplný aspekt alebo fragment správania nejakej entity bez odhalenia jej vnútornej štruktúry. Takouto entitou môže byť systém alebo akýkoľvek prvok modelu, ktorý má svoje vlastné správanie.

        Každý prípad použitia zodpovedá samostatnej službe, ktorú modelovaná entita poskytuje na žiadosť aktéra, to znamená, že určuje, ako bude táto entita použitá. Služba, ktorá sa inicializuje na žiadosť aktéra, je úplný, nedeliteľný sled akcií. To znamená, že keď systém dokončí spracovanie požiadavky, musí sa vrátiť do počiatočný stav aby ste boli pripravení na nasledujúce požiadavky

        Prípady použitia je možné použiť na špecifikáciu externých požiadaviek na navrhovaný systém, ako aj na špecifikáciu funkčného správania existujúceho systému. Súbor prípadov použitia ako celok by mal definovať všetky možné aspekty očakávaného správania systému. Prípady použitia navyše implicitne stanovujú požiadavky, ktoré definujú, ako musia aktéri interagovať so systémom, aby boli schopní správne prevádzkovať poskytované služby. Pre pohodlie možno mnohé prípady použitia považovať za samostatný balík.

        Príkladmi prípadov použitia môžu byť nasledovné úkony: kontrola stavu bežného účtu klienta, zadanie objednávky na nákup tovaru, získanie dodatočných informácií o bonite klienta, zobrazenie grafického formulára na obrazovke monitora a iné akcie.

diagram tried

        Centrálnym miestom v objektovo orientovanom programovaní je vývoj logického modelu systému vo forme diagramu tried. Diagram tried sa používa na reprezentáciu statickej štruktúry modelu systému v terminológii tried objektovo orientovaného programovania. Diagram tried môže odrážať najmä rôzne vzťahy medzi jednotlivými doménovými entitami, ako sú objekty a subsystémy, ako aj popisovať ich vnútornú štruktúru a typy vzťahov.

        Ikony diagramu vám umožňujú zobraziť komplexnú hierarchiu systémov, vzťahy medzi triedami (triedy) a rozhraniami (rozhrania). Tento typ diagram je obsahovo opačný ako diagram spolupráce, ktorý zobrazuje systémové objekty. Rational Rose vám umožňuje vytvárať triedy pomocou tohto typu diagramu v rôznych zápisoch. podobne ako oblak. Trieda je teda len šablóna, podľa ktorej sa v budúcnosti vytvorí konkrétny objekt.

        Diagram tried je graf, ktorého vrcholy sú prvky typu „klasifikátor“, spojené rôzne druhyštrukturálne vzťahy. Diagram tried môže obsahovať aj rozhrania, balíky, vzťahy a dokonca aj jednotlivé inštancie, ako sú objekty a vzťahy.

        triedy v UML sa používa na označenie množiny objektov, ktoré majú rovnakú štruktúru, správanie a vzťahy s objektmi iných tried. Graficky je trieda znázornená ako obdĺžnik, ktorý je možné dodatočne rozdeliť vodorovné čiary do sekcií alebo sekcií. Tieto sekcie môžu obsahovať názov triedy, atribúty (premenné) a operácie (metódy).

stavový diagram

        Každý stavový diagram v UML popisuje všetky možné stavy jednej inštancie určitej triedy a možné sekvencie jej prechodov z jedného stavu do druhého, to znamená, že modeluje všetky zmeny stavov objektu ako jeho odpoveď na externé vplyvov.

        Stavové diagramy sa najčastejšie používajú na popis správania jednotlivých objektov, ale môžu sa použiť aj na špecifikáciu funkčnosti iných komponentov modelu, ako sú prípady použitia, aktéri, subsystémy, operácie a metódy.

        Stavový diagram je špeciálny typ grafu, ktorý predstavuje určitý automat. Vrcholy grafu sú možné stavy stroja, znázornené príslušnými grafickými symbolmi, a oblúky označujú jeho prechody zo stavu do stavu. Stavové diagramy môžu byť vnorené, aby poskytli podrobnejšiu reprezentáciu jednotlivých prvkov modelu.

        V metamodeli UML stroj je balík, ktorý definuje veľa pojmov potrebných na reprezentáciu správania modelovanej entity vo forme diskrétneho priestoru s konečným počtom stavov a prechodov.

        Trvanie systému v ktoromkoľvek z možných stavov výrazne presahuje čas strávený prechodom z jedného stavu do druhého. Predpokladá sa, že v limite môže byť čas prechodu rovný nule (pokiaľ nie je uvedené inak), to znamená, že zmena stavu objektu môže nastať okamžite.

        Správanie automatu je modelované ako sekvenčný pohyb po grafe od vrcholu k vrcholu, pričom sa berie do úvahy orientácia oblúkov, ktoré ich spájajú.

        Stroj musí spĺňať nasledujúce povinné podmienky:

• stav, do ktorého sa objekt môže dostať, je určený iba jeho súčasným stavom a nezávisí od jeho predchádzajúcej histórie;
• V každom okamihu môže byť automat iba v jednom zo svojich stavov. Súčasne môže automat zostať v samostatnom stave tak dlho, ako si želáte, ak nenastanú žiadne udalosti;
• čas, počas ktorého je stroj v jednom alebo druhom stave, ako aj čas potrebný na dosiahnutie jedného alebo druhého stavu, nie sú žiadnym spôsobom špecifikované;
• počet stavov automatu musí byť konečný a všetky musia byť explicitne špecifikované. Jednotlivé pseudostavy nemusia mať špecifikácie (počiatočný a konečný stav). V tomto prípade sú ich účel a sémantika úplne určené z kontextu modelu a uvažovaného stavového diagramu;
• Graf automatu by nemal obsahovať izolované stavy a prechody. Pre každý stav, okrem počiatočného, ​​musí byť určený predchádzajúci stav a každý prechod musí spájať dva stavy stroja;
• automat by nemal obsahovať konfliktné prechody, kedy môže objekt súčasne prechádzať do dvoch alebo viacerých po sebe nasledujúcich stavov (okrem prípadu paralelných podautomatov). V UML je eliminácia konfliktov možná zavedením strážnych podmienok.

štátu je základom nielen v metamodeli jazyka UML, ale aj v aplikovanej systémovej analýze. Celý koncept dynamického systému je založený na koncepte štátu. Sémantika stavu v jazyku UML má množstvo špecifických čŕt.

        V UML je stav abstraktná metatrieda používaná na modelovanie špecifickej situácie, počas ktorej sú splnené určité podmienky. Stav môže byť špecifikovaný ako množina špecifických hodnôt atribútov triedy alebo objektu. Zmeniť individuálnych hodnôt atribúty budú odrážať zmenu stavu modelovanej triedy alebo objektu.

Diagram aktivity

        Pri modelovaní správania navrhovaného alebo analyzovaného systému je potrebné nielen prezentovať proces zmeny jeho stavov, ale aj podrobne opísať vlastnosti algoritmickej a logickej implementácie operácií vykonávaných systémom.

        Tento typ diagramu možno v skutočnosti použiť aj na vyjadrenie stavov modelovaného objektu, avšak hlavným účelom diagramu aktivity je odrážať obchodné procesy objektu. Tento typ diagramu umožňuje zobraziť nielen postupnosť procesov, ale aj vetvenie a dokonca synchronizáciu procesov.

        Tento typ diagramu vám umožňuje navrhnúť algoritmy pre správanie objektov akejkoľvek zložitosti, vrátane toho, že sa dajú použiť na zostavenie blokových diagramov.

        Na modelovanie procesu vykonávania operácií v jazyku UML sa používajú diagramy aktivít. V nich použitý grafický zápis je v mnohom podobný zápisu stavového diagramu, keďže tieto diagramy obsahujú aj stavové a prechodové symboly. Každý stav v diagrame aktivít zodpovedá dokončeniu nejakej základnej operácie a prechod do nasledujúceho stavu nastáva až po dokončení tejto operácie.

        Diagramy aktivít teda možno považovať za špeciálny prípad stavových diagramov. Umožňujú implementovať do jazyka UML vlastnosti procedurálneho a synchrónneho riadenia vďaka dokončeniu interných činností a akcií. Hlavným využitím diagramov aktivít je vizualizácia implementačných vlastností operácií tried, keď je potrebné prezentovať algoritmy na ich implementáciu.

        V kontexte jazyka UML činnosť je súbor jednotlivých výpočtov vykonávaných automatom, vedúcich k nejakému výsledku alebo akcii. Diagram aktivity zobrazuje logiku a postupnosť prechodov z jednej aktivity na druhú a zameriava pozornosť analytika na výsledky. Výsledkom činnosti môže byť zmena stavu systému alebo návrat určitej hodnoty.

        Akčný stav je špeciálny prípad stavu s nejakou vstupnou akciou a aspoň jedným prechodom opúšťajúcim stav. Tento prechod implicitne predpokladá, že vstupná akcia už bola dokončená. Akčný stav nemôže mať vnútorné prechody, pretože je elementárny. Bežným použitím akčného stavu je modelovanie jedného kroku pri vykonávaní algoritmu (postupu) alebo riadiaceho toku.

Sekvenčný diagram

        Pri zvažovaní diagramov stavov a aktivít sa zistilo, že hoci sa tieto diagramy používajú na špecifikáciu dynamiky správania systému, čas v nich nie je explicitne prítomný. Časový aspekt správania môže byť významný pri modelovaní synchrónnych procesov, ktoré opisujú interakcie objektov. Na modelovanie interakcie objektov v čase používa UML sekvenčné diagramy.

        Iba tí predmety, ktoré sa priamo podieľajú na interakcii. Kľúčom k sekvenčným diagramom je dynamika interakcie objektov v priebehu času.

        V UML má sekvenčný diagram dva rozmery. Prvý je zľava doprava vo forme zvislých čiar, z ktorých každá zobrazuje líniu života samostatného objektu zúčastňujúceho sa interakcie. Objekt úplne vľavo na diagrame je ten, ktorý iniciuje interakciu. Napravo je ďalší objekt, ktorý priamo interaguje s prvým. Všetky objekty v sekvenčnom diagrame teda tvoria nejaké poradie, určené poradím alebo stupňom aktivity objektov pri vzájomnej interakcii.

        Graficky je každý objekt znázornený ako obdĺžnik a nachádza sa v hornej časti svojej životnej línie. Do obdĺžnika napíšte názov objektu a názov triedy oddelené dvojbodkou. V tomto prípade je zdôraznený celý záznam, ktorý je znakom objektu.

        Druhým rozmerom sekvenčného diagramu je vertikálna časová os smerujúca zhora nadol. Počiatočný časový okamih zodpovedá najviac vrchná časť diagramy. Interakcie objektov sú implementované prostredníctvom správ, ktoré posiela jeden objekt druhému. Správy sa zobrazujú ako vodorovné šípky s názvom správy a ich poradie je určené časom výskytu. To znamená, že správy umiestnené vyššie v sekvenčnom diagrame sú iniciované pred tými, ktoré sú umiestnené nižšie. Mierka na časovej osi nie je uvedená, pretože sekvenčný diagram modeluje iba časové usporiadanie interakcií „skôr-neskôr“.

Diagram spolupráce

        Hlavná vlastnosť kooperačných diagramov je schopnosť graficky znázorniť nielen postupnosť interakcie, ale aj všetky štrukturálne vzťahy medzi objektmi zúčastňujúcimi sa tejto interakcie.

        Tento typ diagramu vám umožňuje opísať interakcie objektov abstrahovať od postupnosti prenosu správ. Tento typ diagramu zobrazuje v kompaktnej forme všetky prijaté a odoslané správy konkrétneho objektu a typy týchto správ.

        V prvom rade kooperačný diagram zobrazuje objekty zúčastňujúce sa interakcie vo forme obdĺžnikov obsahujúcich názov objektu, jeho triedu a prípadne hodnoty atribútov. Ďalej, ako v diagrame tried, asociácie medzi objektmi sú označené vo forme rôznych spojovacích čiar. V tomto prípade môžete explicitne špecifikovať názvy asociácie a roly, ktoré objekty v tejto asociácii zohrávajú. Okrem toho môžu byť zobrazené dynamické spojenia - toky správ. Sú tiež prezentované vo forme spojovacích čiar medzi objektmi, nad ktorými je šípka označujúca smer, názov správy a sériové číslo v všeobecná postupnosť inicializácia správ.

        Na rozdiel od sekvenčného diagramu, diagram spolupráce zobrazuje iba vzťahy medzi objektmi, ktoré zohrávajú špecifické úlohy v interakcii. Tento graf nezobrazuje čas ako samostatnú dimenziu. Preto môže byť sekvencia interakcií a paralelných tokov určená pomocou sekvenčných čísel. Preto, ak potrebujete explicitne špecifikovať vzťahy medzi objektmi v reálnom čase, je lepšie to urobiť v sekvenčnom diagrame.

        Koncept spolupráce je jedným zo základných pojmov v jazyku UML. Slúži na označenie množiny objektov interagujúcich s konkrétnym účelom vo všeobecnom kontexte modelovaného systému. Účelom samotnej spolupráce je špecifikovať implementačné vlastnosti jednotlivých najvýznamnejších operácií v systéme. Kooperácia definuje štruktúru správania systému z hľadiska interakcie účastníkov tejto spolupráce.

        Spoluprácu možno reprezentovať na dvoch úrovniach:

• úroveň špecifikácie - zobrazuje úlohy klasifikátorov a úlohy asociácií v posudzovanej interakcii;
• úroveň príkladov - označuje inštancie a súvislosti, ktoré tvoria jednotlivé roly v spolupráci.

        Diagram spolupráce na úrovni špecifikácie zobrazuje úlohy, ktoré zohrávajú prvky zapojené do interakcie. Prvkami spolupráce na tejto úrovni sú triedy a asociácie, ktoré označujú jednotlivé roly klasifikátorov a asociácie medzi účastníkmi spolupráce.

        Diagram spolupráce na úrovni príkladu je reprezentovaný množinou objektov (inštancie tried) a spojení (inštancie asociácií). V tomto prípade sú spojenia doplnené šípkami správ. Na tejto úrovni sú zobrazené iba objekty, ktoré priamo súvisia s implementáciou operácie alebo klasifikátora. V tomto prípade nie je vôbec potrebné znázorňovať všetky vlastnosti alebo všetky asociácie, keďže kooperačný diagram obsahuje iba roly klasifikátorov, ale nie samotné klasifikátory. Kým teda klasifikátor vyžaduje úplný popis všetkých svojich inštancií, rola klasifikátora vyžaduje popis len tých vlastností a asociácií, ktoré sú nevyhnutné na účasť na konkrétnej spolupráci.

        Z toho vyplýva dôležitý dôsledok. Rovnaký súbor objektov sa môže zúčastniť rôznych kooperácií. V závislosti od uvažovanej spolupráce sa môžu meniť ako vlastnosti jednotlivých objektov, tak aj väzby medzi nimi. To je to, čo odlišuje diagram spolupráce od diagramu tried, ktorý musí označovať všetky vlastnosti a asociácie medzi prvkami diagramu.

Schéma komponentov

        Tento typ diagramu je určený na distribúciu tried a objektov medzi komponenty počas fyzického návrhu systému. Tento typ diagramu sa často nazýva modulové diagramy.

        Celý projekt softvérový systém je súbor modelov logických a fyzických úrovní, ktoré musia byť navzájom konzistentné. Jazyk UML používa implementačné diagramy na fyzickú reprezentáciu modelov systému, ktoré zahŕňajú diagram komponentov A diagram nasadenia.

        Diagram komponentov, na rozdiel od predtým diskutovaných diagramov, popisuje vlastnosti fyzickej reprezentácie systému. Umožňuje vám určiť architektúru vyvíjaného systému vytvorením závislostí medzi softvérovými komponentmi, ktorými môže byť zdrojový a spustiteľný kód. Hlavnými grafickými prvkami diagramu komponentov sú komponenty, rozhrania a závislosti medzi nimi.

        Diagram komponentov je vytvorený na nasledujúce účely:

• vizualizácia všeobecnej štruktúry zdrojového kódu softvérového systému;
• špecifikácie spustiteľnej verzie softvérového systému;
• zabezpečenie opätovného použitia jednotlivých fragmentov programového kódu;
• reprezentácie konceptuálnych a fyzických databázových schém.

        Na vývoji diagramov komponentov sa podieľajú systémoví analytici a architekti, ako aj programátori. Diagram komponentov poskytuje konzistentný prechod od logickej reprezentácie ku konkrétnej implementácii projektu vo forme softvérového kódu. Niektoré komponenty môžu existovať iba v štádiu kompilácie programového kódu, iné v štádiu jeho vykonávania. Diagram komponentov odráža všeobecné závislosti medzi komponentmi, pričom tieto komponenty považuje za klasifikátory.

        Na znázornenie fyzických entít v jazyku UML sa používa špeciálny výraz - komponent. Komponent implementuje určitú množinu rozhraní a slúži na všeobecné označenie prvkov fyzickej reprezentácie modelu. Používa sa na grafické znázornenie súčiastky zvláštny charakter- obdĺžnik s dvomi menšími obdĺžnikmi vloženými vľavo. Vo vnútri veľkého obdĺžnika je napísaný názov súčiastky a v prípade potreby aj nejaké dodatočné informácie. Vzhľad tohto symbolu sa môže mierne líšiť v závislosti od povahy informácií spojených s komponentom.

Schéma nasadenia

        Tento typ diagramu je určený na analýzu hardvéru systému, teda hardvéru, nie programov. Priamo preložené z angličtiny znamená Deployment „rozmiestnenie“, ale výraz „topológia“ presnejšie odráža podstatu tohto typu diagramu.

        Fyzická reprezentácia softvérového systému nemôže byť úplná, ak neexistujú informácie o tom, na akej platforme a na akých výpočtových prostriedkoch je implementovaný. Ak sa vyvíja program, ktorý beží lokálne na počítači používateľa a nepoužíva periférne zariadenia a zdroje, potom nie je potrebné vyvíjať ďalšie diagramy. Pri vývoji podnikových aplikácií môže byť prítomnosť takýchto diagramov mimoriadne užitočná pri riešení problémov s racionálnym umiestnením komponentov s cieľom efektívne využívať distribuované výpočtové a komunikačné zdroje siete, zaistiť bezpečnosť a iné.

        Diagramy nasadenia sa používajú na reprezentáciu všeobecnej konfigurácie a topológie distribuovaného softvérového systému v UML.

        Diagram nasadenia je navrhnutý tak, aby vizualizoval prvky a komponenty programu, ktoré existujú iba vo fáze spustenia. V tomto prípade sa použijú iba súčasti inštancie programu, ktoré sú spustiteľnými súbormi resp dynamických knižníc. Tie komponenty, ktoré sa nepoužívajú za behu, nie sú zobrazené v diagrame nasadenia. Komponenty so zdrojovými kódmi programu sa teda môžu nachádzať iba v diagrame komponentov. Nie sú uvedené na schéme nasadenia.

        Diagram nasadenia obsahuje grafické obrázky procesory, zariadenia, procesy a prepojenia medzi nimi. Na rozdiel od diagramov logickej reprezentácie je diagram nasadenia jednotný pre systém ako celok, pretože musí plne odrážať vlastnosti jeho implementácie. Vytvorenie diagramu nasadenia je zvyčajne posledným krokom pri špecifikovaní modelu softvérového systému.

        Pri vývoji diagramu nasadenia sa sledujú tieto ciele:

• určiť distribúciu komponentov systému v jeho fyzických uzloch;
• ukázať fyzické spojenia medzi všetkými uzlami implementácie systému vo fáze jeho vykonávania;
• identifikovať úzke miesta systému a prekonfigurovať jeho topológiu na dosiahnutie požadovaného výkonu.

        Diagramy nasadenia spoločne vyvíjajú systémoví analytici, sieťoví inžinieri a systémoví technici.

Funkcie pracovného rozhrania Rational Rose

        Nástroj Rational Rose CASE implementuje všeobecne akceptované štandardy pre operačné rozhranie programu, podobne ako známe vizuálne programovacie prostredia. Po nainštalovaní Rational Rose na počítač užívateľa, ktorá nespôsobuje prakticky žiadne ťažkosti ani začiatočníkom, vedie spustenie tohto programu v MS Windows 95/98 k vzhľadu pracovného rozhrania na obrazovke (obr. 6).

Obrázok - 6. Celkový pohľad na pracovné rozhranie programu Rational Rose

        Operačné rozhranie Rational Rose pozostáva z rôznych prvkov, z ktorých hlavné sú:

• Hlavné menu programu
• Okno diagramu
• Okno dokumentácie
• Okno prehliadača
• Okno denníka

Stručne zvážime účel a hlavné funkcie každého z týchto prvkov.

Hlavné menu programu

Hlavné menu programu je vyhotovené vo všeobecne uznávanom štandarde a má nasledovný vzhľad (obr. 7).

Jednotlivé položky menu, ktorých účel je jasný už z ich názvov, kombinujú podobné operácie súvisiace s celým projektom ako celkom. Niektoré položky ponuky obsahujú známe funkcie (otvorenie projektu, tlač diagramov, kopírovanie a vkladanie rôznych prvkov diagramu zo schránky). Iné sú také špecifické, že si môžu vyžadovať ďalšie úsilie na štúdium (možnosti generovania kódu, kontrola konzistencie modelu, pripojenie ďalších modulov).

Obrázok - 7. Vzhľad hlavné menu programu

Štandardný panel nástrojov

Štandardný panel nástrojov sa nachádza pod hlavným menu programu a vyzerá takto (obr. 8). Niektoré nástroje nie sú dostupné (nový projekt nemá žiadne prvky). Štandardný panel nástrojov poskytuje rýchly prístup k príkazom ponuky, ktoré vývojári používajú najčastejšie.

Obrázok - 8. Vzhľad štandardného panela nástrojov

Používateľ si môže prispôsobiť vzhľad tohto panelu podľa vlastného uváženia. Ak to chcete urobiť, vyberte položku ponuky Nástroje -> Možnosti a otvorte kartu Panely nástrojov. Týmto spôsobom môžete zobraziť alebo skryť rôzne tlačidlá nástrojov a zmeniť ich veľkosť.

Okno prehliadača

Predvolené okno prehliadača sa nachádza na ľavej strane pracovného rozhrania pod štandardným panelom nástrojov (obr. 9).

Prehliadač organizuje zobrazenia modelu v hierarchickej štruktúre, ktorá zjednodušuje navigáciu a umožňuje vám nájsť akýkoľvek prvok modelu v projekte. V tomto prípade sa akýkoľvek prvok, ktorý vývojár pridá do modelu, okamžite zobrazí v okne prehliadača. Podľa toho výberom prvku v okne prehliadača ho môžeme vizualizovať v okne diagramu alebo zmeniť jeho špecifikáciu. Prehliadač vám tiež umožňuje organizovať prvky modelu do balíkov a presúvať prvky medzi rôznymi zobrazeniami modelu. V prípade potreby je možné okno prehliadača umiestniť na iné miesto v pracovnom rozhraní alebo úplne skryť pomocou položky ponuky Zobraziť. Veľkosť prehliadača môžete zmeniť aj potiahnutím jeho vonkajšieho rámu myšou.

Obrázok - 9. Vzhľad prehliadača

Špeciálny panel nástrojov

Špeciálny panel nástrojov sa nachádza medzi oknom prehliadača a oknom grafu v strednej časti pracovného rozhrania. Štandardne sa ponúka panel nástrojov na zostavenie modelového diagramu tried (obr. 10).

Obrázok - 10. Vzhľad špeciálneho panela nástrojov pre diagram tried

Umiestnenie špeciálneho panela nástrojov je možné zmeniť presunutím rámu panelu na požadované miesto. Zloženie panela si môžete prispôsobiť aj pridaním alebo odstránením jednotlivých tlačidiel zodpovedajúcich určitým nástrojom. Priradenia tlačidiel sa dajú naučiť z popisov, ktoré sa zobrazia po umiestnení kurzora myši na príslušné tlačidlo.

Okno diagramu

Okno diagramu je hlavnou pracovnou oblasťou jeho rozhrania, v ktorej sú vizualizované rôzne pohľady na model projektu. Štandardne je okno diagramu umiestnené na pravej strane pracovného rozhrania, ale jeho umiestnenie a veľkosť je možné tiež zmeniť. Pri vývoji nového projektu, ak nebol použitý Sprievodca projektom, je okno diagramu prázdnou oblasťou, ktorá neobsahuje žiadne prvky modelu (obr. 11).

Názov diagramu, ktorý sa nachádza v tomto okne, je uvedený v záhlaví programu (najvrchnejší riadok programu) alebo, ak okno nie je maximalizované na celú obrazovku, v záhlaví okna grafu. V okne grafu môže byť súčasne niekoľko grafov, ale aktívny môže byť iba jeden z nich. Napríklad na obr. 11 je aktívny diagram diagram nasadenia, aj keď existujú aj iné diagramy. Prepínanie medzi diagramami je možné vykonať výberom požadovaného zobrazenia na štandardnom paneli nástrojov alebo cez položku ponuky Okno. Keď aktivujete samostatné zobrazenie grafu, zmení sa vzhľad špeciálneho panela s nástrojmi, ktorý je prispôsobený pre konkrétne zobrazenie grafu.

Obrázok - 11. Vzhľad okna diagramu s rôznymi typmi zobrazenia modelu

Okno dokumentácie

V predvolenom nastavení sa na obrazovke nemusí nachádzať okno s dokumentáciou. V tomto prípade sa dá aktivovať cez položku ponuky Zobraziť -> Dokumentácia, po ktorej sa zobrazí pod prehliadačom (obr. 12).

Okno dokumentácie, ako už názov napovedá, je určené na dokumentáciu prvkov zobrazenia modelu. Môžete v ňom zaznamenať širokú škálu informácií a čo je dôležité - v ruštine. Tieto informácie sú následne prevedené na komentáre a žiadnym spôsobom neovplyvňujú logiku vykonávania programového kódu.

V okne dokumentácie sa aktivujú informácie, ktoré sa týkajú jednotlivého vybraného prvku diagramu. V tomto prípade môžete vybrať prvok buď v okne prehliadača alebo v okne diagramu. Keď do diagramu pridáte nový prvok (napríklad triedu), automaticky sa vygeneruje dokumentácia k nemu, ktorá je prázdna (Žiadna dokumentácia). Následne vývojár samostatne zadá potrebné vysvetľujúce informácie, ktoré sa zapamätajú a môžu sa počas práce na projekte meniť.

Rovnako ako v iných oknách pracovného rozhrania môžete zmeniť veľkosť a polohu okna dokumentácie.

Obrázok - 12. Vzhľad okna dokumentácie

Okno denníka

Okno Protokol je navrhnuté tak, aby automaticky zaznamenávalo rôzne servisné informácie generované počas práce s programom. Protokol zaznamenáva čas a povahu akcií vykonaných vývojárom, ako je aktualizácia modelu, prispôsobenie ponúk a panelov nástrojov, ako aj chybové hlásenia, ktoré sa vyskytujú počas generovania kódu.

Okno protokolu je vždy prítomné na pracovnom rozhraní v oblasti okna diagramu (obr. 13). Môže však byť skrytý inými oknami grafu alebo minimalizovaný. Okno denníka môžete aktivovať cez ponuku Okno->Protokol. V tomto prípade sa zobrazuje nad ostatnými oknami v pravej časti pracovného rozhrania. Toto okno sa nedá úplne odstrániť, dá sa iba minimalizovať.

Obrázok - 13. Vzhľad okna denníka

Záver

        Časom sa z jazyka UML stane „esperanto“, v ktorom budú môcť komunikovať matematici, systémoví analytici, fyzici, programátori, manažéri, ekonómovia a špecialisti iných profesií a prezentovať svoje odborné znalosti v jednotnej forme. Veď v podstate každý zo špecialistov pracuje s modelovými reprezentáciami vo svojom odbore. A práve tento aspekt modelu je možné špecifikovať pomocou jazyka UML.

        V tomto ohľade význam jazyka UML výrazne narastá, pretože čoraz viac nadobúda vlastnosti jazyka reprezentujúceho znalosti. Prítomnosť vizuálnych prostriedkov na reprezentáciu štruktúry a správania modelu v jazyku UML zároveň umožňuje dosiahnuť adekvátnu reprezentáciu deklaratívnych a procedurálnych znalostí a nemenej dôležité vytvoriť sémantickú korešpondenciu medzi týmito formami vedomosti. Všetky tieto vlastnosti jazyka UML nám umožňujú dospieť k záveru, že má najvážnejšie vyhliadky v blízkej budúcnosti.

Tento článok popisuje novú éru vývoja softvéru, jej vplyv na nové požiadavky UML a osvedčené postupy na ich splnenie.
  7. „Dátové modelovanie v Rational Rose“ Sergey Trofimov Opisuje modelovanie fyzickej reprezentácie údajov pomocou Rational Rose
  8. Jazyk UML. Všeobecné pochopenie jazyka UML: štruktúry, grafické prvky a diagramy jazyka.
  9. Praktické UML. Tento dokument je prekladom dokumentu "Praktické UML. Praktický úvod pre vývojárov". Praktický úvod pre vývojárov
  10. „Štandardný objektovo orientovaný modelovací jazyk UML“ Vendrov Alexander Michajlovič. História UML
  11. UML – jednotný modelovací jazyk. Tento materiál obsahuje počiatočné informácie o metódach popisu softvérových systémov a notácií používaných v UML
  12. Jazyk UML. Používateľská príručka. Autori: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. "UML diagramy v Rational Rose" Sergej Trofimov
  14. "Analýza a návrh. Vizuálne modelovanie (UML) Rational Rose" Konstantin Domolego
  15. Knižnica Gennadija Vernikova. Úplné popisyštandardy dizajnu a modelovania.
  16. „Príklad opisu predmetnej oblasti pomocou UML pri vývoji softvérových systémov“ E.B. Zolotukhina, R.V. Alfimov. V článku o konkrétny príklad demonštruje možný prístup k modelovaniu domén založený na použití Unified Modeling Language (UML)

Diagram UML je špecializovaný grafický popisný jazyk určený na objektové modelovanie pri vývoji rôznych softvérov. Jazyk má široký profil a je otvoreným štandardom, ktorý používa rôzne grafické zápisy na vytvorenie abstraktného modelu systému. UML bol vytvorený s cieľom umožniť definíciu, vizualizáciu, dokumentáciu a návrh všetkých druhov softvérových systémov. Stojí za zmienku, že samotný diagram UML nie je programovací jazyk, ale poskytuje možnosť generovania samostatného kódu na jeho základe.

Prečo je to potrebné?

Použitie UML nekončí modelovaním všetkých druhov softvéru. Tento jazyk sa dnes aktívne používa aj na modelovanie rôznych obchodných procesov, návrh systému a tiež zobrazovanie organizačných štruktúr.

Pomocou UML môžu vývojári softvéru zabezpečiť úplnú zhodu v grafickom zápise používanom na reprezentáciu bežných pojmov, ako sú: komponent, generický, trieda, správanie a agregácia. Vďaka tomu je dosiahnutá väčšia miera koncentrácie na architektúru a dizajn.

Za zmienku tiež stojí, že existuje niekoľko typov takýchto grafov.

Diagram triedy

Diagram tried UML je statický štrukturálny diagram určený na opis štruktúry systému, ako aj na zobrazenie atribútov, metód a závislostí medzi niekoľkými rôznymi triedami.

Za zmienku stojí skutočnosť, že existuje niekoľko pohľadov na konštrukciu takýchto diagramov v závislosti od toho, ako sa budú používať:

• Koncepčný. IN v tomto prípade Diagram tried UML popisuje model špecifickej oblasti a poskytuje iba triedy objektov aplikácie.
• Špecifické. Diagram sa používa v procese návrhu rôznych informačných systémov.
• Implementácia. Diagram tried zahŕňa všetky druhy tried, ktoré sa priamo používajú v programovom kóde.

Diagram komponentov

Diagram komponentov UML je úplne statický diagram štruktúry. Má demonštrovať členenie konkrétneho softvérového systému na rôzne štrukturálne komponenty, ako aj prepojenia medzi nimi. Diagram komponentov UML môže používať všetky druhy modelov, knižníc, súborov, balíkov, spustiteľných súborov a mnoho ďalších prvkov ako takých.

Diagram kompozitnej/zloženej štruktúry

Diagram kompozitnej/zloženej štruktúry UML je tiež diagramom statickej štruktúry, ale používa sa na zobrazenie vnútornej štruktúry tried. Ak je to možné, tento diagram môže demonštrovať aj interakciu prvkov nachádzajúcich sa vo vnútornej štruktúre triedy.

Ich podtypom je diagram spolupráce UML, ktorý sa používa na demonštráciu rolí, ako aj interakcie rôznych tried v rámci hraníc spolupráce. Sú celkom pohodlné, ak potrebujete modelovať dizajnové vzory.

Stojí za zmienku, že zobrazenie UML triedy a diagramu kompozitnej štruktúry je možné použiť súčasne.

Schéma nasadenia

Tento diagram sa používa na modelovanie bežiacich uzlov, ako aj všetkých druhov artefaktov, ktoré na nich boli nasadené. V UML 2 sú artefakty nasadené do rôznych uzlov, zatiaľ čo v prvej verzii boli nasadené iba komponenty. Diagram nasadenia UML sa teda používa predovšetkým pre druhú verziu.

Medzi artefaktom a komponentom, ktorý implementuje, sa vytvorí prejavová závislosť.

Diagram objektu

Toto zobrazenie vám umožňuje vidieť úplnú alebo čiastočnú snímku systému, ktorý sa vytvára v určitom časovom bode. Plne zobrazuje všetky inštancie tried konkrétneho systému s uvedením aktuálnych hodnôt ich parametrov, ako aj spojení medzi nimi.

Schéma balíka

Tento diagram má štrukturálny charakter a jeho hlavným obsahom sú všetky druhy balíkov, ako aj vzťahy medzi nimi. V tomto prípade neexistuje prísne rozdelenie medzi niekoľkými štruktúrne diagramy, v dôsledku čoho sa ich použitie najčastejšie používa iba na uľahčenie a nenesie žiadny sémantický význam. Stojí za zmienku, že rôzne prvky môžu poskytovať ďalšie diagramy UML (príklady: balíčky a samotné diagramy balíkov).

Ich použitie sa vykonáva s cieľom zabezpečiť organizáciu niekoľkých prvkov do skupín podľa určitého kritéria s cieľom zjednodušiť štruktúru, ako aj organizovať prácu s modelom daného systému.

Diagram aktivity

Diagram aktivity UML zobrazuje rozklad špecifickej aktivity na niekoľko častí. V tomto prípade je pojem „činnosť“ špecifikácia určitého vykonateľného správania vo forme paralelného, ​​ako aj koordinovaného postupného vykonávania rôznych podriadených prvkov - vnorených typov činností a rôznych akcií, spojených tokmi vychádzajúcimi z výstupov. určitého uzla na vstupy iného uzla.

Diagramy aktivít UML sa často používajú na modelovanie rôznych obchodných procesov, paralelných a sekvenčných výpočtov. Okrem iného simulujú všemožné technologické postupy.

Schéma stroja

Tento typ sa nazýva aj trochu inak – stavový diagram UML. Má prezentovaný konečný automat s jednoduchými a zloženými stavmi, ako aj prechodmi.

Stavový automat je špecifikácia postupnosti rôznych stavov, ktorými určitý objekt alebo interakcia prechádza v reakcii na určité udalosti vo svojom živote, ako aj reakciu objektu na takéto udalosti. Stavový stroj, ktorý používa stavový diagram UML, je pripojený k zdrojovému prvku a používa sa na definovanie správania jeho inštancií.

Takzvané dračie diagramy môžu byť použité ako analógy takýchto diagramov.

Diagramy prípadov použitia

Diagram prípadov použitia UML zobrazuje všetky vzťahy, ktoré vznikajú medzi aktérmi, ako aj rôzne možnosti použitie. Jeho hlavnou úlohou je poskytnúť plnohodnotný prostriedok, prostredníctvom ktorého môže zákazník, koncový používateľ alebo ktorýkoľvek vývojár spoločne diskutovať o správaní a funkčnosti určitého systému.

Ak sa v procese modelovania systému použije diagram prípadov použitia UML, analytik:

• Jasne oddeľte modelovaný systém od jeho prostredia.
• Identifikujte aktérov, spôsoby ich interakcie s týmto systémom, ako aj jeho očakávanú funkčnosť.
• Nastavte v slovníku ako oblasť predmetov rôzne pojmy, ktorých sa to týka podrobný popis funkčnosť tohto systému.

Ak je diagram použitia vypracovaný v UML, postup začína textovým popisom, ktorý sa získa pri práci so zákazníkom. Za zmienku stojí fakt, že v procese zostavovania modelu prípadu použitia sa úplne vynechajú rôzne nefunkčné požiadavky a vygeneruje sa pre ne samostatný dokument.

komunikácie

Komunikačný diagram, rovnako ako sekvenčný diagram UML, je tranzitívny, to znamená, že vyjadruje interakciu, ale zároveň ju demonštruje. rôznymi spôsobmi a ak je to potrebné, s požadovaným stupňom presnosti môžete jeden previesť na iný.

Komunikačný diagram odráža interakcie, ktoré sa vyskytujú medzi rôznymi prvkami zloženej štruktúry, ako aj úlohy spolupráce. Hlavný rozdiel medzi ním a sekvenčným diagramom je v tom, že robí vzťahy medzi niekoľkými prvkami celkom explicitnými a nepoužíva čas ako samostatnú dimenziu.

Tento typ sa vyznačuje úplne voľným formátom na usporiadanie niekoľkých objektov a spojení rovnakým spôsobom, ako sa to robí v diagrame objektov. Ak je potrebné zachovať poradie správ v tomto voľnom formáte, sú očíslované chronologicky. Čítanie tohto diagramu začína počiatočnou správou 1.0 a následne pokračuje v smere, v ktorom sa správy prenášajú z jedného objektu do druhého.

Z veľkej časti tieto diagramy zobrazujú presne tie isté informácie, ktoré nám poskytuje sekvenčný diagram, ale keďže používa iný spôsob prezentácie informácií, určité veci v jednom diagrame sa dajú identifikovať oveľa ľahšie ako v inom. Za zmienku tiež stojí, že komunikačný diagram jasnejšie ukazuje, s ktorými prvkami každý interaguje. samostatný prvok, zatiaľ čo sekvenčný diagram jasnejšie ukazuje, v akom poradí sa interakcie vyskytujú.

Sekvenčný diagram

Sekvenčný diagram UML zobrazuje interakcie medzi viacerými objektmi, ktoré sú usporiadané podľa času, kedy sa vyskytujú. Tento diagram zobrazuje časovo usporiadanú interakciu medzi niekoľkými objektmi. Zobrazuje najmä všetky objekty, ktoré sa zúčastňujú interakcie, ako aj kompletnú sekvenciu správ, ktoré si medzi sebou vymieňajú.

Hlavnými prvkami sú v tomto prípade označenia rôznych predmetov, ako aj zvislé čiary znázorňujúce plynutie času a obdĺžniky predstavujúce činnosť určitého predmetu alebo výkon nejakej funkcie.

Schéma spolupráce

Tento typ diagramu vám umožňuje demonštrovať interakcie medzi niekoľkými objektmi abstrahovať od postupnosti prenosu správ. Tento typ diagramu zobrazuje v kompaktnej forme absolútne všetky odoslané a prijaté správy určitého objektu, ako aj formáty týchto správ.

Pretože sekvenčné a komunikačné diagramy sú jednoducho rozdielne pohľady na tie isté postupy, Rational Rose poskytuje možnosť vytvárať sekvenčný diagram z komunikačného diagramu alebo naopak a tiež ich úplne automaticky synchronizuje.

Diagramy prehľadu interakcií

Sú to diagramy UML, ktoré sú typom diagramu aktivít a zahŕňajú prvky sekvencie aj konštrukty toku riadenia.

Za zmienku stojí skutočnosť, že tento formát kombinuje Collaboration a Sequence diagram, ktoré poskytujú príležitosť zvážiť interakciu medzi niekoľkými objektmi v systéme, ktorý sa vytvára, z rôznych uhlov pohľadu.

Časový diagram

predstavuje alternatívna možnosť sekvenčný diagram, ktorý jasne demonštruje zmenu stavu pozdĺž životnej línie s určitým časovým rozsahom. Môže byť celkom užitočný v rôznych aplikáciách v reálnom čase.

Aké sú výhody?

Za zmienku stojí niekoľko výhod, ktoré odlišujú diagram použitia UML a ďalšie:

• Jazyk je objektovo orientovaný, v dôsledku čoho sú technológie na popis výsledkov analýzy a návrhu sémanticky blízke programovacím metódam vo všetkých druhoch moderných objektovo orientovaných jazykov.
• S pomocou tohto jazyka systém možno opísať takmer z akéhokoľvek možného uhla pohľadu a rôzne aspekty jeho správania sú opísané rovnakým spôsobom.
• Všetky diagramy sú pomerne ľahko čitateľné aj po pomerne rýchlom úvode do jeho syntaxe.
• UML umožňuje rozširovať a tiež zavádzať vlastné grafické a textové stereotypy, čo podporuje jeho využitie nielen v softvérovom inžinierstve.
• Jazyk sa stal pomerne rozšíreným a tiež sa pomerne aktívne rozvíja.

Nedostatky

Napriek tomu, že konštrukcia UML diagramov má veľa výhod, často sú kritizované za nasledujúce nevýhody:

• Redundancia. Vo veľkej väčšine prípadov kritici tvrdia, že UML je príliš veľké a zložité, čo je často neopodstatnené. Obsahuje pomerne veľa nadbytočných alebo prakticky zbytočných návrhov a schém a takáto kritika je najčastejšie namierená na druhú verziu, nie na prvú, pretože novšie revízie obsahujú viac kompromisov „navrhnutých výborom“.
• Rôzne nepresnosti v sémantike. Pretože UML je definovaný kombináciou seba, angličtiny a OCL, nemá tuhosť, ktorá je vlastná jazykom presne definovaným formálnymi popisnými technikami. V určitých situáciách si abstraktná syntax OCL, UML a angličtiny začne protirečiť, zatiaľ čo v iných prípadoch sú neúplné. Nepresné popisy samotného jazyka ovplyvňujú používateľov aj poskytovateľov nástrojov, čo v konečnom dôsledku vedie k nekompatibilite nástrojov v dôsledku jedinečného spôsobu, akým sa zaobchádza s rôznymi špecifikáciami.
• Problémy v procese implementácie a štúdia. Všetky vyššie uvedené problémy spôsobujú určité ťažkosti v procese implementácie a učenia sa UML, a to platí najmä vtedy, keď manažment núti inžinierov používať ho, keď im chýbajú predchádzajúce zručnosti.
• Kód odráža kód. Iný názor je, že nie sú dôležité krásne a atraktívne modely, ale samotné fungujúce systémy, teda kód je projekt. Podľa tohto názoru je potrebné viac sa rozvíjať efektívnym spôsobom softvér na písanie. UML sa bežne oceňuje v prístupoch, ktoré kompilujú modely na regeneráciu spustiteľného alebo zdrojového kódu. Ale v skutočnosti to nemusí stačiť, pretože jazyku chýbajú Turingove vlastnosti úplnosti a každý vygenerovaný kód bude v konečnom dôsledku obmedzený na to, čo dokáže uhádnuť alebo určiť nástroj na interpretáciu UML.
• Nesúlad zaťaženia. Tento termín pochádza z teórie systémovej analýzy na určenie neschopnosti vstupu určitého systému vnímať iný výstup. Ako v každom štandardné systémy notácie, UML môže reprezentovať niektoré systémy efektívnejšie a stručnejšie ako iné. Vývojár sa teda viac prikláňa k tým riešeniam, ktoré sú pohodlnejšie na prepojenie všetkých silné stránky UML, ako aj iné programovacie jazyky. Tento problém je zrejmejší, ak vývojový jazyk nezodpovedá základným princípom objektovo orientovanej ortodoxie, to znamená, že sa nesnaží pracovať v súlade s princípmi OOP.
• Snaží sa byť univerzálny. UML je modelovací jazyk všeobecný účel, ktorý sa snaží zabezpečiť kompatibilitu s akýmkoľvek aktuálne existujúcim jazykom spracovania. V kontexte daného projektu, aby tím dizajnérov dosiahol konečný cieľ, je potrebné vybrať použiteľné vlastnosti daného jazyka. Okrem tohto možné spôsoby obmedzenia rozsahu UML v konkrétnej oblasti podliehajú formalizmu, ktorý nie je úplne formulovaný a ktorý je sám osebe predmetom kritiky.

Použitie tohto jazyka teda nie je relevantné vo všetkých situáciách.