Všeobecná charakteristika jazyka UML. UML diagram. Typy UML diagramov Uml diagram vrstvy

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnutý tak, aby podporoval proces modelovania PS založený na prístupe OO, organizoval vzťah medzi konceptuálnymi a programovými konceptmi a reflektoval problémy škálovania zložitých systémov. 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žívať UML vlastným spôsobom, v závislosti od ich problémových oblastí a použitých technológií.

Stručná história UML

Do polovice 90. rokov 20. storočia bolo navrhnutých niekoľko desiatok metód OO modelovania rôznymi autormi, z ktorých každý používal svoj vlastný grafický zápis. Každá z týchto metód mala zároveň svoje silné stránky, ale neumožňovala postaviť dostatočne ucelený model PS, ukázať ho „zo všetkých strán“, teda všetky potrebné projekcie (pozri článok 1). Okrem toho absencia štandardu OO modelovania sťažovala vývojárom výber najvhodnejšej metódy, čo bránilo širokému používaniu 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 vyriešili naliehavý problém unifikácie a štandardizácie autori troch najpopulárnejších metód OO - G. Booch , D. Rambo a A. Jacobson, ktorí spojili svoje úsilie a vytvorili UML verziu 1.1, schválenú OMG v roku 1997 ako štandard.

UML je jazyk

Každý jazyk pozostáva zo slovníka a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takže sú usporiadané najmä programovacie jazyky, ako je UML. Jeho charakteristickým znakom je, že slovnú zásobu jazyka tvoria grafické prvky. Každý grafický symbol má špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jednoznačne pochopený iným, ako aj nástrojom, ktorý interpretuje UML. Z toho predovšetkým vyplýva, že model PS prezentovaný v UML je možné automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda pomocou dobrého nástroja na vizuálne modelovanie, ktorý podporuje UML. zostavením modelu dostaneme aj prázdny kód programu 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 a v akých prípadoch by sa mali rozvíjať. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja PS. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v ďalších článkoch.

UML slovník

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

Esencie 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 anotačné (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne diskutované pri štúdiu diagramov.

Vzťahy ukazujú rôzne vzťahy medzi entitami. V UML sú definované nasledujúce typy vzťahov:

  • Závislosť ukazuje taký vzťah medzi dvoma entitami, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou zo závislej entity na nezávislú entitu.
  • 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 súvisiace entity. Asociácie sa používajú 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 druhej strane. 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. Osobitným prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený kosoštvorcom na konci blízko entity-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 (State diagrams),
    • 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.

Pohľad na ovládanie modelu. Balíčky.

Už sme si povedali, že na to, aby človek dobre porozumel modelu, je potrebné ho hierarchicky usporiadať, 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 vám umožňuje vytvárať hierarchie. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balík sa zobrazí ako obdĺžnik s uškom.

Čo poskytuje UML.

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

A posledný…

Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom modelovaní PS 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ť prázdne miesta programových kódov v rôznych OO programovacích jazykoch a vytvárať databázové schémy. Väčšina z nich zahŕňa možnosť reengineeringu programových kódov - obnovenie určitých projekcií modelu PS automatickou analýzou zdrojových kódov programov, čo je veľmi dôležité pre zabezpečenie zhody modelu a kódov a pri navrhovaní systémov, ktoré zdedia funkčnosť predchádzajúcich systémov. .

UML diagram je špecializovaný grafický popisný jazyk určený na objektové modelovanie pri vývoji rôznych softvérov. Tento 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ť na jeho základe vygenerovať samostatný kód.

Prečo je potrebná?

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

S 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, zovšeobecnenie, trieda, správanie a agregácia. Tým sa dosiahne väčšia miera koncentrácie na architektúru a dizajn.

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

diagram tried

Diagram tried UML je diagram statickej štruktúry 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ý. V tomto prípade diagram tried UML popisuje model konkrétnej oblasti a poskytuje iba triedy objektov aplikácie.
  • Špecifické. Diagram sa používa v procese navrhovania 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 vzťahy 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.

Schéma kompozitnej/kompozitnej š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, ktoré sú vo vnútornej štruktúre triedy.

Ich poddruhom je diagram spolupráce UML, ktorý sa používa na demonštráciu rolí a interakcií rôznych tried v rámci spolupráce. Sú celkom praktické, ak potrebujete modelovať dizajnové vzory.

Stojí za zmienku, že diagramy tried UML a diagramy zloženej štruktúry môžu byť použité súčasne.

Diagram nasadenia

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

Závislosť prejavu sa vytvára medzi artefaktom a komponentom, ktorý implementuje.

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 vzťahov 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 striktné oddelenie medzi niekoľkými štrukturálnymi diagramami, v dôsledku čoho sa ich použitie najčastejšie používa iba pre pohodlie a nemá ž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 atribútu, aby sa zjednodušila štruktúra, ako aj zorganizovať prácu s modelom tohto systému.

diagram činnosti

Diagram aktivity UML zobrazuje rozklad konkrétnej aktivity na niekoľko častí. V tomto prípade pojem „činnosť“ označuje špecifikáciu 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 idúcimi z výstupy určitého uzla na vstupy iného.

Diagram aktivity UML sa často používa na modelovanie rôznych obchodných procesov, paralelných a sekvenčných výpočtov. Okrem iného modelujú všelijaké technologické postupy.

diagram automatu

Tento pohľad sa nazýva a trochu inak - stavový diagram UML. Má prezentovaný stavový automat s jednoduchými a zloženými stavmi, ako aj prechodmi.

Stavový automat je špecifikácia postupnosti rôznych stavov, ktorými prechádza určitý objekt, alebo interakcia v reakcii na niektoré udalosti v jeho živote, ako aj odozva objektu na takéto udalosti. Stavový stroj, ktorý používa stavový diagram UML, je pripojený k pôvodné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é sa vyskytujú medzi aktérmi, ako aj rôzne prípady použitia. Jeho hlavnou úlohou je poskytnúť plnohodnotný prostriedok, pomocou ktorého môže zákazník, koncový používateľ, prípadne nejaký vývojár spoločne diskutovať o správaní a funkčnosti konkrétneho systému.

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

  • Jasne oddeľte modelovaný systém od jeho prostredia.
  • Identifikovať aktérov, spôsoby ich interakcie s týmto systémom, ako aj jeho očakávanú funkčnosť.
  • Nastavte si v slovníku ako predmet rôzne pojmy, ktoré súvisia s podrobným popisom funkčnosti tohto systému.

Ak sa v UML vyvíja diagram použitia, postup začína textovým popisom, ktorý sa získa pri práci so zákazníkom. Zároveň stojí za zmienku skutočnosť, že v procese zostavovania modelu prípadu použitia sú úplne vynechané rôzne nefunkčné požiadavky a už pre ne bude vytvorený samostatný dokument.

komunikácie

Komunikačný diagram je rovnako ako UML sekvenčný diagram tranzitívny, teda vyjadruje interakciu, no zároveň ju rôznymi spôsobmi demonštruje a v prípade potreby možno s požadovanou mierou presnosti transformovať na ďalší.

Komunikačný diagram odráža interakcie, ktoré sa vyskytujú medzi rôznymi prvkami zloženej štruktúry, ako aj úlohy spolupráce. Jeho hlavný rozdiel od sekvenčného diagramu je v tom, že jasne naznačuje vzťah medzi niekoľkými prvkami a čas sa nepoužíva ako samostatná dimenzia.

Tento typ sa vyznačuje úplne voľným formátom usporiadania niekoľkých objektov a vzťahov 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 takéto 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ú určiť oveľa ľahšie ako v inom. Za zmienku tiež stojí, že komunikačný diagram jasnejšie ukazuje, s ktorými prvkami každý jednotlivý prvok interaguje, zatiaľ čo sekvenčný diagram jasnejšie ukazuje, v akom poradí sa interakcie vykonávajú.

sekvenčný diagram

Sekvenčný diagram UML zobrazuje interakcie medzi viacerými objektmi, ktoré sú zoradené podľa času ich výskytu. Takýto 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 vymieňajú.

Hlavnými prvkami sú v tomto prípade označenia rôznych objektov, ako aj zvislé čiary, ktoré zobrazujú plynutie času a obdĺžniky, ktoré predstavujú činnosť konkrétneho objektu alebo vykonávanie nejakej funkcie ním.

Schéma spolupráce

Tento typ diagramu vám umožňuje zobraziť interakcie medzi niekoľkými objektmi abstrahovať od postupnosti prekladu správ. Tento typ diagramov v kompaktnej forme zobrazuje 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é diagramy a komunikačné diagramy sú jednoducho rozdielne pohľady na tie isté postupy, Rational Rose poskytuje možnosť vytvoriť komunikačný sekvenčný diagram zo sekvenčného diagramu alebo naopak a tiež ich úplne automaticky synchronizuje.

Diagramy prehľadu interakcií

Sú to UML diagramy, ktoré patria k typu diagramov aktivít a zahŕňajú sekvenčné prvky 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 tvoria, z rôznych uhlov pohľadu.

Časový diagram

Predstavuje alternatívnu verziu sekvenčného diagramu, ktorá explicitne demonštruje zmenu stavu na záchrannej línii s určitým časovým rozsahom. Môže to 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 vykonanej analýzy a návrhu sémanticky blízke programovacím metódam vo všetkých druhoch objektovo orientovaných jazykov moderného typu.
  • Pomocou tohto jazyka možno systém popísať takmer z akéhokoľvek možného uhla pohľadu a rovnako sú popísané rôzne aspekty jeho správania.
  • Všetky diagramy sú pomerne dobre čitateľné aj po pomerne rýchlom oboznámení sa s jeho syntaxou.
  • UML umožňuje rozširovať, ale aj zavádzať vlastné grafické a textové stereotypy, čo prispieva k jeho využitiu 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 tieto nedostatky:

  • nadbytok. Vo veľkej väčšine prípadov kritici tvrdia, že UML je príliš veľký a zložitý a často je to neopodstatnené. Zahŕňa pomerne veľa nadbytočných alebo takmer zbytočných konštrukcií a diagramov a najčastejšie takáto kritika smeruje k druhej verzii a nie k prvej, pretože v novších revíziách je viac kompromisov „navrhnutých výborom“.
  • Rôzne nepresnosti v sémantike. Pretože UML je definovaný kombináciou seba, angličtiny a OCL, chýba mu tuhosť, ktorá je vlastná jazykom, ktoré sú presne definované technikami formálneho popisu. V určitých situáciách si abstraktná syntax OCL, UML a angličtiny začnú navzájom protirečiť, zatiaľ čo v iných prípadoch sú neúplné. Nepresnosť samotného popisu jazyka ovplyvňuje 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 zaobchádzania 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 priamo fungujúce systémy, teda kód je projekt. Podľa tohto názoru je potrebné vyvinúť efektívnejší spôsob písania softvéru. UML sa 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 nakoniec obmedzený tým, čo môže interpretačný nástroj UML predpokladať alebo určiť.
  • 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ť výstup iného systému. Ako každá štandardná notácia, UML môže reprezentovať určité systémy efektívnejším a stručnejším spôsobom ako iné. Vývojár je teda viac naklonený tým riešeniam, ktoré sú pohodlnejšie na tkanie všetkých silných stránok UML, ako aj iných programovacích jazykov. Tento problém je zrejmejší, ak vývojový jazyk nezodpovedá hlavným princípom objektovo orientovanej ortodoxnej doktríny, to znamená, že sa nesnaží pracovať v súlade s princípmi OOP.
  • Snaží sa byť všestranný. UML je univerzálny modelovací jazyk, ktorý sa snaží byť kompatibilný s akýmkoľvek jazykom spracovania, ktorý v súčasnosti existuje. V kontexte konkrétneho projektu, aby tím dizajnérov dosiahol konečný cieľ, je potrebné zvoliť použiteľné vlastnosti tohto jazyka. Okrem toho možné spôsoby, ako obmedziť rozsah použitia UML v určitej oblasti, prechádzajú formalizmom, ktorý nie je úplne formulovaný, ale ktorý je sám osebe predmetom kritiky.

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

UML je teraz štandardná notácia pre vizuálne modelovanie softvérových systémov, ktorú prijala Object Management Group (OMG) na jeseň roku 1997 a podporuje ju mnoho objektovo orientovaných produktov CASE.

Štandard UML ponúka nasledujúcu sadu diagramov na modelovanie:

Use case diagram (use case diagram) - na modelovanie obchodných procesov organizácie alebo podniku a určenie požiadaviek na vytváraný informačný systém;

diagram tried (class diagram) - na modelovanie statickej štruktúry tried systému a vzťahov medzi nimi;

diagram správania systému (diagramy správania);

interakčné diagramy;

Sekvenčné diagramy - na modelovanie procesu zasielania správ medzi objektmi v rámci jedného prípadu použitia;

diagram spolupráce (diagram spolupráce) - na modelovanie procesu zasielania správ medzi objektmi v rámci rovnakého prípadu použitia;

stavový diagram - na modelovanie správania sa objektov systému pri prechode z jedného stavu do druhého;

diagram aktivít - na modelovanie správania systému v rámci rôznych prípadov použitia, prípadne modelovania aktivít;

implementačný diagram (implementačné diagramy):

Komponentové diagramy (komponentové diagramy) - na modelovanie hierarchie komponentov (subsystémov) informačného systému;

diagram nasadenia (deployment diagram) - pre modelovanie fyzickej architektúry navrhovaného informačného systému.

Na obr. 1.1 predstavuje integrovaný model informačného systému vrátane hlavných diagramov, ktoré sa majú vypracovať v rámci tohto projektu kurzu.

Ryža. 1. Integrovaný model informačného systému v zápise jazyka UML

4.2. Schéma prípadu použitia

Prípad použitia je postupnosť akcií vykonaných systémom v reakcii na udalosť vyvolanú nejakým externým objektom (aktérom). Prípad použitia opisuje typickú interakciu medzi používateľom a systémom. V najjednoduchšom prípade sa prípad použitia určí v procese diskusie s používateľom o funkciách, ktoré by chcel v tomto informačnom systéme implementovať. V UML je prípad použitia znázornený takto:

Obr.2. Prípad použitia

Aktér je rola, ktorú používateľ hrá vo vzťahu k systému. Herci predstavujú roly, nie konkrétne osoby alebo pracovné pozície. Hoci sú v diagramoch prípadov použitia zobrazené ako štylizované ľudské postavy, aktérom môže byť aj externý informačný systém, ktorý potrebuje nejaké informácie zo systému. Hercov by ste mali v diagrame zobraziť iba vtedy, keď skutočne potrebujú nejaké prípady použitia. V UML sú herci reprezentovaní ako tvary:



Obr.3. postava (herec)

Herci sú rozdelení do troch hlavných typov:

Používatelia

systémy;

Iné systémy interagujúce s týmto systémom;

Čas sa stáva aktérom, ak na ňom závisí spustenie akýchkoľvek udalostí v systéme.

4.2.1. Vzťahy medzi prípadmi použitia a aktérmi

V UML diagramy prípadov použitia podporujú niekoľko typov vzťahov medzi prvkami diagramu:

Komunikácia (komunikácia),

Zahrnutie (zahrnúť),

rozšírenie (predĺženie),

zovšeobecňovanie.

komunikačná komunikácia je vzťah medzi prípadom použitia a aktérom. V UML sú komunikačné spojenia zobrazené pomocou jednosmernej asociácie (plná čiara).

Obr.4. Príklad komunikačného prepojenia

Inkluzívne spojenie používa sa v situáciách, keď existuje určitá časť správania systému, ktorá sa opakuje vo viac ako jednom prípade použitia. Pomocou takýchto odkazov sa zvyčajne modeluje opakovane použiteľná funkcia.

Predlžovacie pripojenie používa sa na opis zmien v normálnom správaní systému. V prípade potreby umožňuje jednému prípadu použitia použiť funkcie iného prípadu použitia.

Obr.5. Príklad vzťahu inklúzie a rozšírenia

Zovšeobecňovanie komunikácie naznačuje, že niekoľko aktérov alebo tried má spoločné vlastnosti.

Obr.6. Príklad zovšeobecňujúceho vzťahu

4.3.



Interakčné diagramy opísať správanie interagujúcich skupín objektov. Interakčný diagram zvyčajne pokrýva iba správanie objektov v rámci jedného prípadu použitia. Takýto diagram zobrazuje množstvo objektov a správ, ktoré si navzájom vymieňajú.

správu je prostriedok, ktorým odosielajúci objekt žiada objekt príjemcu, aby vykonal jednu z jeho operácií.

Informačná (informatívna) správa je správa, ktorá poskytuje prijímajúcemu objektu nejaké informácie na aktualizáciu jeho stavu.

Žiadosť o správu (otázka) je správa požadujúca výstup niektorých informácií o objekte príjemcu.

Imperatívne posolstvo je správa, ktorá žiada príjemcu, aby vykonal nejakú akciu.

Existujú dva typy interakčných diagramov: sekvenčné diagramy a diagramy spolupráce.

4.3.1. Sekvenčné diagramy

sekvenčný diagram odráža tok udalostí vyskytujúcich sa v rámci jedného prípadu použitia.

Všetci aktéri (herci, triedy alebo objekty) zapojení do daného scenára (prípad použitia) sú znázornení v hornej časti diagramu. Šípky zodpovedajú správam odovzdávaným medzi aktérom a objektom alebo medzi objektmi na vykonávanie požadovaných funkcií.

V sekvenčnom diagrame je objekt znázornený ako obdĺžnik, z ktorého je nadol nakreslená bodkovaná zvislá čiara. Táto linka je tzv záchranné lano objektu . Je to fragment životného cyklu objektu v procese interakcie.

Každá správa je znázornená ako šípka medzi životnými čiarami dvoch objektov. Správy sa zobrazujú v poradí, v akom sa zobrazujú na stránke zhora nadol. Každá správa je označená aspoň názvom správy. Voliteľne môžete pridať aj argumenty a niektoré riadiace informácie. Môžete zobraziť sebadelegovanie, správu, ktorú si objekt posiela sám, pričom šípka správy ukazuje na rovnakú záchrannú linku.

Ryža. 7. Príklad sekvenčného diagramu

4.3.2. Diagram spolupráce

Diagramy spolupráce zobraziť tok udalostí v rámci konkrétneho scenára (prípad použitia). Správy sú zoradené podľa času, hoci diagramy spolupráce sa viac zameriavajú na vzťahy medzi objektmi. Diagram spolupráce zobrazuje všetky informácie, ktoré má sekvenčný diagram, ale diagram spolupráce popisuje tok udalostí iným spôsobom. Z toho je ľahšie pochopiť súvislosti, ktoré existujú medzi objektmi.

V diagrame spolupráce, rovnako ako v diagrame sekvencií, šípky predstavujú správy, ktoré sa vymieňajú v rámci daného prípadu použitia. Ich časová postupnosť je označená číslovaním správ.

Ryža. 8. Príklad kooperačného diagramu

4.4. diagram tried

4.4.1. Všeobecné informácie

diagram tried definuje typy systémových tried a rôzne druhy statických väzieb, ktoré medzi nimi existujú. Diagramy tried tiež zobrazujú atribúty tried, operácie tried a obmedzenia, ktoré sú umiestnené na vzťahoch medzi triedami.

Diagram tried v UML je graf, ktorého uzly sú prvkami statickej štruktúry projektu (triedy, rozhrania) a oblúky sú vzťahy medzi uzlami (asociácie, dedičnosť, závislosti).

Diagram tried zobrazuje nasledujúce prvky:

· Balík (balík) - súbor prvkov modelu, ktoré spolu logicky súvisia;

· Trieda (trieda) - popis spoločných vlastností skupiny podobných objektov;

· Rozhranie (rozhranie) - abstraktná trieda, ktorá špecifikuje množinu operácií, ktoré objekt ľubovoľnej triedy spojenej s daným rozhraním poskytuje iným objektom.

4.4.2. Trieda

Trieda je skupina entít (objektov), ​​ktoré majú podobné vlastnosti, a to dáta a správanie. Jednotlivý člen triedy sa nazýva objekt triedy alebo jednoducho objekt.

Správanie objektu v UML sa vzťahuje na akékoľvek pravidlá pre interakciu objektu s vonkajším svetom a s údajmi samotného objektu.

V diagramoch je trieda znázornená ako obdĺžnik s pevným okrajom, rozdelený vodorovnými čiarami na 3 časti:

Horná časť (časť názvu) obsahuje názov triedy a ďalšie všeobecné vlastnosti (najmä stereotyp).

Stredná časť obsahuje zoznam atribútov

V spodnej časti je zoznam operácií triedy, ktoré odrážajú jej správanie (akcie vykonávané triedou).

Žiadna zo sekcií atribútov a operácií sa nemusí zobraziť (alebo oboje). Pre chýbajúcu časť nemusíte kresliť deliacu čiaru a nejako naznačovať prítomnosť alebo neprítomnosť prvkov v nej.

Dodatočné oddiely, ako napríklad výnimky, môžu byť zavedené podľa uváženia konkrétnej implementácie.

Ryža. 9. Príklad diagramu tried

4.4.2.1.Triedne stereotypy

Stereotypovanie tried je mechanizmus na klasifikáciu tried do kategórií.

UML definuje tri hlavné stereotypy triedy:

Hranica (hranica);

Entita (entita);

Kontrola (manažment).

4.4.2.2.Hraničné triedy

Hraničné triedy sú tie triedy, ktoré sa nachádzajú na hranici systému a celého prostredia. Sú to displeje, zostavy, rozhrania s hardvérom (ako sú tlačiarne alebo skenery) a rozhrania s inými systémami.

Ak chcete nájsť hraničné triedy, musíte preskúmať diagramy prípadov použitia. Každá interakcia medzi aktérom a prípadom použitia musí mať aspoň jednu hraničnú triedu. Práve táto trieda umožňuje hercovi interakciu so systémom.

4.4.2.3.triedy entít

Triedy entít obsahujú uložené informácie. Pre používateľa majú najväčší význam, a preto ich názvy často používajú výrazy z predmetnej oblasti. Zvyčajne sa pre každú triedu entity vytvorí tabuľka v databáze.

4.4.2.4.Kontrolné triedy

Kontrolné triedy sú zodpovedné za koordináciu akcií ostatných tried. Každý prípad použitia má zvyčajne jednu riadiacu triedu, ktorá riadi postupnosť udalostí pre daný prípad použitia. Riadiaca trieda je zodpovedná za koordináciu, ale sama o sebe nenesie žiadnu funkčnosť, pretože ostatné triedy jej neposielajú veľké množstvo správ. Namiesto toho sám posiela množstvo správ. Trieda manažérov jednoducho deleguje zodpovednosť na iné triedy, a preto sa často označuje ako trieda manažérov.

V systéme môžu byť ďalšie triedy riadenia, ktoré sú spoločné pre niekoľko prípadov použitia. Napríklad môže existovať trieda SecurityManager zodpovedná za monitorovanie udalostí súvisiacich s bezpečnosťou. Trieda TransactionManager sa stará o koordináciu správ súvisiacich s databázovými transakciami. Môžu existovať iní manažéri, ktorí sa budú zaoberať ďalšími prvkami fungovania systému, ako je zdieľanie zdrojov, distribuované spracovanie údajov alebo spracovanie chýb.

Okrem vyššie uvedených stereotypov si môžete vytvoriť svoj vlastný.

4.4.2.5.Atribúty

Atribút je informácia spojená s triedou. Atribúty ukladajú zapuzdrené údaje triedy.

Pretože atribúty sú obsiahnuté v triede, sú skryté pred ostatnými triedami. Z tohto dôvodu môže byť potrebné špecifikovať, ktoré triedy majú právo čítať a upravovať atribúty. Táto vlastnosť sa nazýva viditeľnosť atribútov.

Atribút môže mať štyri možné hodnoty tohto parametra:

Verejné (všeobecné, otvorené). Táto hodnota viditeľnosti predpokladá, že atribút bude viditeľný pre všetky ostatné triedy. Akákoľvek trieda môže zobraziť alebo zmeniť hodnotu atribútu. V súlade s notáciou UML je pred spoločným atribútom znak „+“.

Súkromné ​​(uzavreté, tajné). Zodpovedajúci atribút nie je viditeľný pre žiadnu inú triedu. Súkromný atribút je označený znakom "-" v súlade s notáciou UML.

Chránené (chránené). Takýto atribút je dostupný iba pre samotnú triedu a jej potomkov. Notácia UML pre chránený atribút je znak "#".

Balenie alebo Implementácia (šarža). Predpokladajme, že daný atribút je zdieľaný, ale iba v rámci jeho balíka. Tento typ viditeľnosti nie je označený žiadnou špeciálnou ikonou.

Pomocou uzavretosti alebo bezpečnosti je možné predísť situácii, keď hodnotu atribútu menia všetky triedy systému. Namiesto toho bude logika modifikácie atribútu zabalená do rovnakej triedy ako samotný atribút. Možnosti viditeľnosti, ktoré nastavíte, ovplyvnia vygenerovaný kód.

4.4.2.6.Operácie

Operácie implementujú správanie súvisiace s triedou. Operácia má tri časti – názov, parametre a návratový typ.

Parametre sú argumenty, ktoré operácia dostane ako vstup. Návratový typ sa vzťahuje na výsledok akcie operácie.

Diagram tried môže zobrazovať názvy operácií aj názvy operácií spolu s ich parametrami a typom návratu. Ak chcete znížiť zaťaženie diagramu, je užitočné zobraziť iba názvy operácií na niektorých z nich a ich úplný podpis na iných.

V UML majú operácie nasledujúci zápis:

Názov operácie (argument: typ údajov argument, argument2: typ údajov argument2,...): návratový typ

Je potrebné zvážiť štyri rôzne typy operácií:

Implementačné operácie;

Manažérske operácie;

Prístupové operácie;

Pomocné operácie.

Implementačné operácie

Operácie implementátora implementujú niektoré obchodné funkcie. Takéto operácie možno nájsť skúmaním interakčných diagramov. Diagramy tohto typu sa zameriavajú na obchodné funkcie a každá správa v diagrame môže byť s najväčšou pravdepodobnosťou spojená s implementačnou operáciou.

Každá implementačná operácia musí byť ľahko sledovateľná podľa príslušnej požiadavky. To sa dosiahne v rôznych fázach simulácie. Operácia je odvodená od správy v interakčnom diagrame, správy sú odvodené od podrobného popisu toku udalostí, ktorý je generovaný na základe prípadu použitia, a ten na základe požiadaviek. Schopnosť sledovať celý tento reťazec pomáha zaistiť, že každá požiadavka je implementovaná v kóde a každý kus kódu implementuje nejakú požiadavku.

Manažérske operácie

Manažérske operácie riadia vytváranie a ničenie objektov. Konštruktory a deštruktory tried patria do tejto kategórie.

Prístupové operácie

Atribúty sú zvyčajne súkromné ​​alebo chránené. Iné triedy však niekedy potrebujú zobraziť alebo zmeniť svoje hodnoty. Na to existujú prístupové operácie. Tento prístup umožňuje bezpečné zapuzdrenie atribútov v rámci triedy, čím ich chráni pred inými triedami, no stále k nim umožňuje kontrolovaný prístup. Štandardom je vytváranie operácií Get a Set (získanie a zmena hodnoty) pre každý atribút triedy.

Pomocné operácie

Pomocné (pomocné operácie) sú tie operácie triedy, ktoré sú potrebné na to, aby plnila svoje povinnosti, ale o ktorých by ostatné triedy nemali nič vedieť. Ide o operácie privátnej a chránenej triedy.

Ak chcete identifikovať transakcie, postupujte takto:

1. Študujte sekvenčné diagramy a kooperatívne diagramy. Väčšina správ v týchto diagramoch sú implementačné operácie. Reflexné správy budú pomocnými operáciami.

2. Zvážte kontrolné operácie. Možno budete musieť pridať konštruktory a deštruktory.

3. Zvážte operácie prístupu. Pre každý atribút triedy, s ktorým budú musieť pracovať iné triedy, musíte vytvoriť operácie Get a Set.

4.4.2.7.Spojenia

Vzťah je sémantický vzťah medzi triedami. Dáva triede schopnosť učiť sa o atribútoch, operáciách a vzťahoch inej triedy. Inými slovami, aby jedna trieda mohla poslať správu druhej v sekvenčnom alebo kooperatívnom diagrame, musí medzi nimi existovať spojenie.

Existujú štyri typy vzťahov, ktoré možno vytvoriť medzi triedami: asociácie, závislosti, agregácie a zovšeobecnenia.

Komunikačná asociácia

Asociácia je sémantický vzťah medzi triedami. Sú nakreslené na diagrame tried ako obyčajná čiara.

Ryža. 10. Komunikačná asociácia

Asociácie môžu byť obojsmerné, ako v príklade, alebo jednosmerné. V UML sú obojsmerné asociácie nakreslené ako jednoduchá čiara bez šípok alebo so šípkami na oboch stranách čiary. Jednosmerné priradenie má iba jednu šípku ukazujúcu jeho smer.

Smer asociácie možno určiť skúmaním sekvenčných diagramov a kooperatívnych diagramov. Ak všetky správy na nich odosiela len jedna trieda a prijíma ich len iná trieda, ale nie naopak, medzi týmito triedami prebieha jednosmerná komunikácia. Ak sa aspoň jedna správa odošle opačným smerom, priradenie musí byť obojsmerné.

Asociácie môžu byť reflexívne. Reflexná asociácia znamená, že jedna inštancia triedy interaguje s inými inštanciami tej istej triedy.

Komunikačná závislosť

Vzťahy závislosti tiež odrážajú vzťah medzi triedami, ale sú vždy jednosmerné a ukazujú, že jedna trieda závisí od definícií vytvorených v inej. Napríklad trieda A používa metódy triedy B. Potom, keď sa trieda B zmení, je potrebné vykonať zodpovedajúce zmeny v triede A.

Závislosť je znázornená prerušovanou čiarou nakreslenou medzi dvoma prvkami diagramu a prvok ukotvený na konci šípky sa považuje za závislý od prvku ukotveného na začiatku tejto šípky.

Ryža. 11. Komunikačná závislosť

Pri generovaní kódu pre tieto triedy sa do nich nepridajú žiadne nové atribúty. Vytvoria sa však operátori špecifickí pre daný jazyk, ktorí sú potrební na podporu komunikácie.

Agregácia komunikácie

Agregácie sú užšou formou asociácie. Agregácia je spojenie medzi celkom a jeho časťou. Môžete mať napríklad triedu Car, ako aj triedy Motor, Pneumatiky a triedy pre iné automobilové diely. Výsledkom je, že objekt triedy Car bude pozostávať z objektu triedy Motor, štyroch objektov Pneumatiky atď. Agregácie sú vizualizované ako čiara s kosoštvorcom pre triedu, ktorá je celým číslom:

Ryža. 11. Agregácia komunikácie

Okrem jednoduchej agregácie, UML zavádza silnejšiu formu agregácie nazývanú kompozícia. Podľa zloženia môže časť predmetu patriť iba do jedného celku a navyše sa spravidla životný cyklus častí zhoduje s cyklom celku: žijú a umierajú s ním. Akékoľvek odstránenie celku sa vzťahuje aj na jeho časti.

Toto kaskádové vymazanie sa často považuje za súčasť definície agregácie, ale vždy sa predpokladá, keď je multiplicita rolí 1..1; ak je napríklad potrebné odstrániť Zákazníka, potom sa toto vymazanie musí rozšíriť na Objednávky (a následne na Riadky objednávok).

UML je skratka pre Unified Modeling Language. V skutočnosti je to jedna z najpopulárnejších techník modelovania obchodných procesov a je to medzinárodná štandardná notácia pre špecifikáciu, vizualizáciu a dokumentáciu vývoja softvéru. Definovaný skupinou pre správu objektov sa objavil ako výsledok niekoľkých dodatočných notačných systémov UML a teraz sa stal de facto štandardom pre vizuálne modelovanie. Základný princíp akéhokoľvek objektovo orientovaného programovania začína tvorbou modelu.

UML bol vytvorený z chaosu okolo vývoja softvéru a dokumentácie. V 90. rokoch 20. storočia existovalo niekoľko rôznych spôsobov reprezentácie softvérových systémov. Bolo potrebné vytvoriť jednotnejší vizuálny spôsob UML na reprezentáciu týchto systémov, a preto ho v rokoch 1994 až 1996 vyvinuli traja softvéroví inžinieri pracujúci v Rational Software. Neskôr bol prijatý ako štandard v roku 1997 a zostal tak až do dnešného dňa len s niekoľkými aktualizáciami.

UML je v podstate všeobecný modelovací jazyk v oblasti vývoja softvéru. Teraz si však našiel cestu do dokumentácie niekoľkých obchodných procesov alebo pracovných tokov, ako sú diagramy aktivít. Typ UML diagram možno použiť ako náhradu za vývojové diagramy. Poskytujú štandardizovanejší spôsob modelovania pracovných postupov a širokú škálu funkcií na zlepšenie čitateľnosti a efektívnosti.

Architektúra je založená na meta-objekte, ktorý definuje základ pre tvorbu jazyka UML. Je dostatočne presný na vytvorenie celej aplikácie. Plne spustiteľný UML môže byť nasadený na viacerých platformách pomocou rôznych technológií so všetkými procesmi počas celého cyklu vývoja softvéru.

UML je určený pre používateľov na vývoj jazyka vizuálneho modelovania. Podporuje koncepty rozvoja na vysokej úrovni, ako sú štruktúry, vzory a spolupráce. UML je zbierka prvkov, ako napríklad:

  1. Príkazy programovacieho jazyka.
  2. Aktéri opisujú úlohu, ktorú hrá používateľ alebo akýkoľvek iný systém, ktorý interaguje s objektom.
  3. Činnosti, ktoré sa majú vykonať pri plnení zmluvy o dielo a ktoré sa majú prezentovať v diagramoch.
  4. Obchodný proces, ktorý zahŕňa súbor úloh, ktoré vytvárajú špecifickú službu pre zákazníkov, vizualizovaný vývojovým diagramom sekvenčných akcií.
  5. Logické a opakovane použiteľné softvérové ​​komponenty.

UML diagramy spadajú do dvoch kategórií. Prvý typ zahŕňa sedem typov diagramov reprezentujúcich štrukturálne informácie, druhý - zvyšných sedem predstavuje všeobecné typy správania. Tieto diagramy sa používajú na dokumentáciu architektúry systémov a priamo sa podieľajú na modelovaní systému UML.

UML diagramy sú prezentované ako statické a dynamické reprezentácie modelu systému. Statické zobrazenie zahŕňa diagramy tried a zloženej štruktúry, ktoré zdôrazňujú statickú štruktúru. Dynamický pohľad predstavuje interakciu medzi objektmi a zmeny vnútorných stavov objektov pomocou sekvenčných, aktivít a stavových diagramov.

Na zjednodušenie modelovania je k dispozícii široká škála nástrojov na modelovanie UML, vrátane IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner a Dia.

Použitie UML má rôzne podoby ako v dokumentácii vývoja softvéru, tak aj v obchodných procesoch:

  1. Skica. V tomto prípade sa diagramy UML používajú na vyjadrenie rôznych aspektov a charakteristík systému. Toto je však len pohľad na systém na najvyššej úrovni a s najväčšou pravdepodobnosťou nebude obsahovať všetky potrebné detaily na dotiahnutie projektu do úplného konca.
  2. Forward Design – Návrh náčrtu sa robí pred kódovaním aplikácie. Deje sa tak pre lepší prehľad o systéme alebo pracovnom postupe, ktorý sa používateľ snaží vytvoriť. Je možné identifikovať veľa konštrukčných problémov alebo nedostatkov, ktoré zlepšia celkové zdravie a pohodu projektu.
  3. Obrátený dizajn. Po napísaní kódu sa diagramy UML objavia ako forma dokumentácie pre rôzne aktivity, roly, prispievateľov a pracovné postupy.
  4. Modrotlač. V tomto prípade diagram slúži ako kompletná konštrukcia, ktorá si vyžaduje iba skutočnú implementáciu systému alebo softvéru. Často sa to robí pomocou nástrojov CASE (Computer Aided Software Engineering Tools). Hlavnou nevýhodou používania nástrojov CASE je, že vyžadujú určitú úroveň znalostí, školenia používateľov a manažmentu a personálu.

UML nie je samostatný programovací jazyk ako Java, C++ alebo Python, avšak so správnymi nástrojmi sa môže zmeniť na pseudoprogramovací jazyk UML. Na dosiahnutie tohto cieľa musí byť celý systém zdokumentovaný v rôznych diagramoch a pomocou správneho softvéru je možné diagramy priamo preložiť do kódu. Táto metóda môže byť užitočná iba vtedy, ak čas strávený kreslením diagramov trvá menej času ako písanie skutočného kódu. Aj keď bol UML vytvorený pre modelovanie systémov, našiel si niekoľko využití v obchodných oblastiach.

Nasleduje príklad UML diagramu pre obchodné modelovanie.

Jedným z praktických riešení by bolo vizuálne znázorniť tok procesu pre telesales prostredníctvom diagramu aktivít. Od momentu, kedy je objednávka prijatá ako vstup, až po moment, kedy je objednávka dokončená a daný konkrétny výstup.

Existuje niekoľko typov UML diagramov a každý z nich plní inú úlohu, či už je vyvinutý pred implementáciou alebo po nej, ako súčasť dokumentácie. Dve najširšie kategórie pokrývajúce všetky ostatné typy sú diagram správania a diagram štruktúry. Ako už názov napovedá, niektoré UML diagramy sa pokúšajú analyzovať a znázorniť štruktúru systému alebo procesu, zatiaľ čo iné popisujú správanie systému, jeho účastníkov a komponentov.

Jednotlivé typy sú rozdelené takto:

  1. Nie všetky zo 14 rôznych typov UML diagramov sa pravidelne používajú pri dokumentovaní systémov a architektúr.
  2. Paretov princíp platí aj pre použitie UML diagramov.
  3. 20 % diagramov používajú vývojári 80 % času.

Najčastejšie používané prvky pri vývoji softvéru sú:

  • diagramy použitia;
  • diagramy tried;
  • sekvencie.

Diagramy aktivít - Najdôležitejšie diagramy UML pre vytváranie modelov obchodných procesov. Pri vývoji softvéru sa používajú na opis toku rôznych činností. Môžu byť sériové alebo paralelné. Popisujú predmety používané, spotrebované alebo produkované činnosťou a vzťah medzi rôznymi činnosťami.

Všetko vyššie uvedené je nevyhnutné pre modelovanie obchodných procesov, ktoré vedú od jedného k druhému, keďže sú vzájomne prepojené s jasným začiatkom a koncom. V podnikateľskom prostredí sa to označuje aj ako mapovanie obchodných procesov. Hlavnými aktérmi sú autor, redaktor a vydavateľ. Príklad UML je nasledujúci. Keď recenzent posúdi projekt a rozhodne, že je potrebné vykonať nejaké zmeny. Autor potom skontroluje koncept a vráti ho znova na analýzu recenzie.

Diagram použitia

Základný kameň systému – slúži na analýzu požiadaviek na úroveň systému. Tieto požiadavky sú vyjadrené v rôznych prípadoch použitia. Tri hlavné zložky diagramu UML sú:

  1. Funkčné – prezentované ako prípady použitia.
  2. Sloveso, ktoré opisuje činnosť.
  3. Herci - na interakciu so systémom. Aktérmi môžu byť používatelia, organizácie alebo externý nárok. Vzťahy medzi účastníkmi sú znázornené rovnými šípkami.

Napríklad pre diagram riadenia zásob. V tomto prípade ide o vlastníka, dodávateľa, manažéra, špecialistu na inventarizáciu a inšpektora zásob. Okrúhle nádoby predstavujú akcie, ktoré herci vykonávajú. Možné akcie: nákup a platba za akcie, kontrola kvality akcií, vrátenie akcií alebo distribúcia akcií.

Tento typ diagramu je vhodný na zobrazenie dynamického správania medzi účastníkmi v systéme, čo zjednodušuje jeho prezentáciu bez odhalenia detailov implementácie.

Dočasné

Časové diagramy UML sa používajú na znázornenie vzťahov medzi objektmi, keď je zameranie časovo závislé. V tomto prípade nie je zaujímavé, ako objekty interagujú alebo sa navzájom menia, ale používateľ si chce predstaviť, ako objekty a subjekty pôsobia pozdĺž lineárnej časovej osi.

Každý jednotlivý účastník je reprezentovaný prostredníctvom záchranného lana, čo je v podstate línia, ktorá tvorí etapy, keď sa individuálny účastník pohybuje z jednej etapy do druhej. Hlavná pozornosť sa venuje trvaniu času udalostí a zmenám, ktoré nastávajú v závislosti od toho.

Hlavné zložky časového diagramu sú:

  1. Lifeline je individuálny člen.
  2. Stavová časová os – jediná životná cesta môže prechádzať rôznymi stavmi v rámci procesu.
  3. Obmedzenie trvania – obmedzenie časového intervalu, ktoré predstavuje trvanie obmedzenia potrebného na splnenie.
  4. Časový limit – Obmedzenie časového intervalu, počas ktorého musí člen niečo vykonať.
  5. Destruction Emergence – objavenie sa správy, ktorá zničí jednotlivého člena a zobrazuje koniec životného cyklu tohto člena.

Horizontálne diagramy, tiež nazývané stavové diagramy, sa používajú na opis rôznych stavov komponentu v rámci systému. Má konečný formát názvu, pretože diagram je v podstate stroj, ktorý popisuje viaceré stavy objektu a ako sa mení na základe vnútorných a vonkajších udalostí.

Veľmi jednoduchý stavový diagram stroja by bol v šachovej hre. Typická šachová partia pozostáva z ťahov bieleho a ťahov čierneho. Biely má prvý ťah, čím začína hru. Koniec hry môže nastať bez ohľadu na to, či vyhrá biely alebo čierny. Hra môže skončiť zápasom, rezignáciou alebo remízou (rôzne stavy auta). Stavové diagramy sa používajú hlavne v doprednom a spätnom UML návrhu rôznych systémov.

Sekvenčné

Tento typ diagramu je najdôležitejším UML diagramom nielen medzi počítačovou komunitou, ale aj ako model na úrovni návrhu pre vývoj obchodných aplikácií. Sú obľúbené pri popisovaní obchodných procesov vďaka svojej vizuálnej samovysvetľujúcej povahe. Ako už názov napovedá, diagramy popisujú postupnosť správ a interakcií, ktoré prebiehajú medzi subjektmi a objektmi. Aktéri alebo objekty môžu byť aktívne len vtedy, keď je to potrebné alebo keď s nimi chce komunikovať iný objekt. Všetky správy sú prezentované v chronologickom poradí.

Ďalšie informácie nájdete v príklade sekvenčného diagramu UML nižšie.

Ako vyplýva z príkladu, na znázornenie štruktúry systému sa používajú štrukturálne diagramy. Presnejšie povedané, jazyk sa používa pri vývoji softvéru na reprezentáciu architektúry systému a toho, ako spolu rôzne komponenty súvisia.

Diagram tried UML je najbežnejším typom diagramu pre softvérovú dokumentáciu. Pretože väčšina softvéru, ktorý sa v súčasnosti píše, je stále založená na paradigme objektovo orientovaného programovania, používanie diagramov tried na dokumentovanie softvéru je zdravý rozum. Je to preto, že OOP je založený na triedach UML a vzťahoch medzi nimi. Stručne povedané, grafy obsahujú triedy spolu s ich atribútmi, ktoré sa tiež nazývajú dátové polia, a ich správanie, nazývané členské funkcie.

Konkrétnejšie, každá trieda má 3 polia: meno hore, atribúty hneď pod názvom, operácie/správanie dole. Vzťah medzi rôznymi triedami (reprezentovaný spojnicou) tvorí diagram tried. Vyššie uvedený príklad ukazuje základný diagram tried.

Objekty

Pri diskusii o štruktúrnych diagramoch UML sa musíte ponoriť do konceptov súvisiacich s počítačovou vedou. V softvérovom inžinierstve sú triedy považované za abstraktné dátové typy, zatiaľ čo objekty sú inštancie. Napríklad, ak existuje „Car“, čo je všeobecný abstraktný typ, potom inštancia triedy „Car“ by bola „Audi“.

UML objektové diagramy pomáhajú vývojárom softvéru skontrolovať, či je vygenerovaná abstraktná štruktúra životaschopnou štruktúrou, keď sa implementuje v praxi, to znamená pri vytváraní objektov. Niektorí vývojári to považujú za sekundárnu úroveň kontroly presnosti. Zobrazuje inštancie triedy. Presnejšie, generická trieda "Client" má teraz skutočného klienta, napríklad s názvom "James". James je inštanciou všeobecnejšej triedy a má rovnaké atribúty, avšak s danými hodnotami. To isté bolo urobené s Účtom a sporiacim účtom. Obaja sú objektmi svojich príslušných tried.

Nasadenia

Diagramy nasadenia sa používajú na vizualizáciu vzťahu medzi softvérom a hardvérom. Aby sme boli konkrétnejší, pomocou diagramov nasadenia je možné vytvoriť fyzický model toho, ako sú softvérové ​​​​komponenty (artefakty) nasadené do hardvérových komponentov známych ako uzly.

Typická schéma zjednodušeného nasadenia webovej aplikácie by zahŕňala:

  1. Uzly (aplikačný server a databázový server).
  2. Diagram artefaktov klientskej aplikácie a databázy.

Diagram balíka je podobný makrám pre diagramy UML nasadenia, ktoré sme vysvetlili vyššie. Rôzne balíčky obsahujú uzly a artefakty. Zoskupujú diagramy a komponenty modelu do skupín, podobne ako menný priestor zapuzdruje rôzne názvy, ktoré spolu súvisia. V konečnom dôsledku môže byť balík vytvorený aj niekoľkými ďalšími balíkmi, ktoré reprezentujú zložitejšie systémy a správanie.

Hlavným účelom diagramu balíkov je ukázať vzťahy medzi rôznymi veľkými komponentmi, ktoré tvoria komplexný systém. Programátori považujú túto abstrakciu za dobrú výhodu pri používaní diagramov balíkov, najmä ak niektoré detaily môžu byť vynechané z obrázka.

Ako každá iná vec v živote, aby ste urobili niečo správne, potrebujete správne nástroje. Na dokumentovanie softvéru, procesov alebo systémov používajte nástroje, ktoré ponúkajú anotácie UML a šablóny diagramov. Existujú rôzne nástroje softvérovej dokumentácie, ktoré môžu pomôcť nakresliť diagram.

Vo všeobecnosti spadajú do nasledujúcich hlavných kategórií:

  1. Papier a pero sú jednoduché. Vezmite papier a pero, otvorte kód syntaxe UML z webu a nakreslite ľubovoľný typ diagramu, ktorý chcete.
  2. Online nástroje – Existuje niekoľko online aplikácií, ktoré je možné použiť na vytvorenie grafu. Väčšina z nich ponúka platené predplatné alebo obmedzený počet diagramov na bezplatnej úrovni.
  3. Bezplatné online nástroje sú takmer rovnaké ako platené. Hlavným rozdielom je, že platené ponúkajú aj návody a hotové šablóny pre konkrétne diagramy.
  4. Desktopová aplikácia – typickou desktopovou aplikáciou na použitie pre diagramy a takmer všetky iné diagramy je Microsoft Visio. Ponúka pokročilé funkcie a funkcie. Jedinou nevýhodou je, že za to musíte zaplatiť.

Je teda jasné, že UML je dôležitým aspektom spojeným s vývojom objektovo orientovaného softvéru. Na vytváranie vizuálnych modelov systémových programov využíva grafickú notáciu.

UML alebo Unified Modeling Language je grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru. Využ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 konvenciách reprezentujúcich spoločné koncepty a sústrediť sa na dizajn a vývoj.

Výhody UML

  • UML používa grafické symboly pre prvky modelovaného systému a diagramy UML sú pomerne ľahko pochopiteľné;
  • UML umožňuje popísať systémy takmer z každého možného uhla pohľadu, pričom berie 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 zaviesť ďalšie textové a grafické typy, čo umožňuje využitie UML nielen v oblasti IT.

Typy UML diagramov

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í. Samostatným poddruhom diagramov správania sú interakčné diagramy.

Hierarchia typov UML diagramov, reprezentovaný diagramom tried

Štrukturálne diagramy

  1. diagram tried je kľúčovým prvkom v objektovo orientovanom modelovaní. S pomocou tohto diagramu (v skutočnosti cez triedy, ich atribúty, metódy a závislosti medzi triedami) popisuje doménový model a štruktúru modelovaného systému.
  2. Diagram komponentov zobrazuje rozdelenie kódu programu na veľké bloky (štrukturálne komponenty) a zobrazuje závislosti medzi nimi. Komponenty môžu byť balíky, moduly, knižnice, súbory atď.
  3. objektový diagram zobrazuje úplný alebo čiastočný rez simulovaného systému v danom časovom bode. Predstavuje inštancie tried (objektov), ​​ich stav (aktuálne hodnoty atribútov) a vzťahy medzi nimi.
  4. Schéma zloženej štruktúry demonštruje vnútornú štruktúru tried a ak 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. Diagram 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šíriteľnosti, ktorý umožňuje prispôsobiť UML rôznym témam a oblastiam činnosti.

Príklad diagramu tried UML

Diagramy správania

  1. diagram činnosti zobrazuje akcie ( akcie), z toho určitá činnosť ( činnosť). Diagramy činností sa používajú na modelovanie obchodných procesov, technologických procesov, sériových a paralelných výpočtov.
  2. Schéma prípadu použitia(alebo diagram prípadu použitia) popisuje vzťah medzi aktérmi (aktérmi) a prípadmi použitia simulovaného systému (jeho schopnosti). Hlavným účelom diagramu je byť univerzálnym nástrojom pre zákazníkov, vývojárov a koncových používateľov, pomocou ktorého by bolo možné spoločne diskutovať o systéme - jeho schopnostiach a správaní.
  3. Stavový diagram zobrazuje dynamické správanie entity, ukazuje, ako táto entita v závislosti od jej aktuálneho stavu reaguje na rôzne udalosti. V skutočnosti ide o stavový diagram z teórie atómov.
  4. Komunikačný diagram(v starších verziách diagram spolupráce) ukazuje interakcie medzi časťami zloženej štruktúry a rolami spolupráce. Diagram explicitne naznačuje vzťah medzi prvkami (objektmi).
  5. 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 nejakého prípadu použitia, postupnosť správ, ktoré si vymieňajú.
  6. Diagram prehľadu interakcií zahŕňa časť sekvenčného diagramu a konštrukt riadiaceho toku. Pomáha zvážiť interakciu objektov z rôznych uhlov pohľadu.
  7. Časový diagram- samostatný poddruh interakčných diagramov, špecializujúci sa na časovanie. Diagramy tohto typu sa používajú na štúdium správania objektov počas určitého časového obdobia.