Typy čiar sa používajú v diagramoch uml. UML modelovanie

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnuté tak, aby podporovalo proces modelovania softvéru založeného na prístupe OO, organizovalo vzťah koncepčných a programových konceptov a odrážalo 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ž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. Navyše každá z týchto metód mala svoje vlastné silné stránky, ale neumožnili nám 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 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á priradenú špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jasne pochopený iným, ako aj softvérovým nástrojom, ktorý interpretuje 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 polotovar programový kód, zodpovedajúce 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.

Jednotný modelovací jazyk (UML) je v súčasnosti de facto štandardom pre popis (dokumentáciu) výsledkov návrhu a vývoja objektovo orientovaných systémov. Vývoj UML začali v roku 1994 Grady Booch a James Rumbaugh, ktorí pracovali v Rational Software. Na jeseň 1995 sa k nim pridal Ivar Jacobson a v októbri toho istého roku vyšla predbežná verzia 0.8 Unified Method. Odvtedy bolo vydaných niekoľko verzií špecifikácie UML, z ktorých dve majú štatút medzinárodného štandardu:

UML 1.4.2 – „ISO/IEC 19501:2005. informačné technológie. Otvorené spracovanie distribúcie. Unified Modeling Language (UML). Verzia 1.4.2" (anglicky "Information technology. Open distribution processing. Unified modeling language (UML). Verzia 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informačné technológie. Unified Modeling Language (OMG UML) pre správu objektov. Časť 1. Infraštruktúra" (angl. "Information technology -- Object Management Group Unified Modeling Language ( OMG UML) - Časť 1: Infraštruktúra") a "ISO/IEC 19505-2:2012 Informačné technológie pre skupinu na správu objektov (OMG UML) Časť 2. Nadstavba" (angl. "Information technology - Object"). Jednotný modelovací jazyk manažérskej skupiny (OMG UML) – Časť 2: Nadstavba“).

Najnovšiu špecifikáciu oficiálneho jazyka možno nájsť na www.omg.org.

Všeobecná štruktúra UML je znázornená na nasledujúcom obrázku.

Ryža. 11.1. Štruktúra UML

11.2. Sémantika a syntax UML

Sémantika - odbor jazykovedy, ktorý študuje význam jazykových jednotiek, predovšetkým jeho slov a slovných spojení.

Syntax – spôsoby spájania slov a ich tvarov do slovných spojení a viet, spájanie viet do zložitých viet, spôsoby vytvárania výpovedí ako súčasti textu.

Vo vzťahu k UML teda sémantika a syntax určujú štýl prezentácie (budovanie modelu), ktorý kombinuje prirodzené a formálne jazyky, aby reprezentoval základné pojmy (prvky modelu) a mechanizmy na ich rozšírenie.

11.3. Notácia UML

Notácia je grafická interpretácia sémantiky pre jej vizuálnu reprezentáciu.

UML definuje tri typ entity :

Štrukturálne - abstrakcia, ktorá je odrazom koncepčného alebo fyzického objektu;

Zoskupenie – prvok používaný na nejakú sémantickú kombináciu prvkov diagramu;

Vysvetľujúci (anotačný) – komentár k prvku diagramu.

Nasledujúca tabuľka ukazuje stručný popis hlavné entity používané v grafickom zápise a hlavné spôsoby ich zobrazenia.

Tabuľka 11.1. entity

Typ	Meno	Označenie	Definícia (sémantika)
Štrukturálne	(trieda)		Súbor objektov, ktoré majú spoločnú štruktúru a správanie
	(objekt)		Abstrakcia skutočnej alebo vymyslenej entity s jasne definovanými pojmovými hranicami, osobnosťou, stavom a správaním. Z pohľadu UML sú objekty inštanciami triedy (inštancie entity)
	(herec)	inžinier cestné služby	Entita mimo systému, ktorá interaguje so systémom a používa ho funkčnosť dosiahnuť určité ciele alebo vyriešiť konkrétne problémy. Aktér je teda externý zdroj alebo príjemca informácií
	(prípad použitia)		Popis akcií vykonaných systémom, ktoré vedú k významnému výsledku pre aktéra
	(štát)		Popis momentu v živote entity, keď spĺňa nejakú podmienku, vykonáva nejakú činnosť alebo čaká, kým nastane nejaká udalosť.
	Spolupráca (spolupráca)		Opis súboru inštancií aktérov, objektov a ich interakcie v procese riešenia určitého problému
	(komponent)		Fyzická časť systému (súbor) vrátane systémových modulov, ktoré zabezpečujú implementáciu konzistentnej sady rozhraní
	(rozhranie)	iVýpočet	Množina operácií, ktorá definuje službu (množinu služieb) poskytovanú triedou alebo komponentom
	(uzol)		Fyzická časť systému (počítač, tlačiareň atď.), ktorá poskytuje prostriedky na vyriešenie problému
Zoskupovanie	(balík)		Všeobecný mechanizmus zoskupovania prvkov. Na rozdiel od komponentu je balík čisto konceptuálny (abstraktný) koncept. Špeciálne prípady balíka sú systém a model
	(fragment)		Oblasť špecifickej interakcie medzi inštanciami aktérov a objektmi
	(oddiel aktivity)		Skupina operácií (oblasť zodpovednosti) vykonávaná jednou entitou (aktér, objekt, komponent, uzol atď.)
	(oblasť prerušiteľnej aktivity)		Skupina operácií, ktorých bežná postupnosť vykonávania môže byť prerušená v dôsledku výskytu nezvyčajnej situácie
Vysvetľujúce	Poznámka (komentár)		Komentár k prvku. Pripojí sa ku komentovanému prvku prerušovanou čiarou

Niektoré zdroje, najmä [,], tiež identifikujú entity správania interakcie A konečných automatov, ale z logického hľadiska by mali byť klasifikované ako diagramy.

Niektoré z vyššie uvedených entít podľa nich implikujú podrobný popis na diagramoch rozkladu. Na diagrame najvyššej úrovne sú označené špeciálnou ikonou alebo štítkom.

Nasledujúca tabuľka poskytuje popis všetkých typov vzťahy UML používané v diagramoch na označenie vzťahov medzi entitami.

Tabuľka 11.3. Vzťah

Meno	Označenie	Definícia (sémantika)
asociácie		Popis vzťahu zmysluplné spojenie medzi dvoma alebo viacerými subjektmi. Najvšeobecnejší typ vzťahu
Agregácia		Podtyp asociácie, ktorý opisuje vzťah „časť“ – „celok“, v ktorom môže „časť“ existovať oddelene od „celku“. Kosoštvorec je označený z „celej“ strany. Vzťah je špecifikovaný iba medzi entitami rovnakého typu
Zloženie		Podtyp agregácie, v ktorom „časti“ nemôžu existovať oddelene od „celku“. Spravidla sa „časti“ vytvárajú a ničia súčasne s „celkom“
Závislosť		Vzťah medzi dvoma entitami, v ktorom zmena v jednej entite (nezávislej) môže ovplyvniť stav alebo správanie druhej entity (závislej). Strana so šípkou označuje nezávislú entitu
Zovšeobecnenie		Vzťah medzi zovšeobecnenou entitou (predok, rodič) a špecializovanou entitou (potomok, dcéra). Trojuholník je naznačený zo strany rodiča. Vzťah je špecifikovaný iba medzi entitami rovnakého typu
Realizácia		Vzťah medzi entitami, kde jedna entita špecifikuje činnosť, ktorú sa iná entita zaväzuje vykonať. Vzťahy sa používajú v dvoch prípadoch: medzi rozhraniami a triedami (alebo komponentmi), medzi prípadmi použitia a spoluprácami. Strana so šípkou označuje entitu, ktorá definuje akciu (rozhranie alebo prípad použitia)

Pre asociáciu je možné špecifikovať agregáciu a zloženie mnohosť (angl. multiplicity), charakterizujúce celkový počet inštancií subjektov participujúcich na vzťahu. Zvyčajne sa uvádza na každej strane vzťahu v blízkosti zodpovedajúcej entity. Násobnosť môže byť označená nasledujúcimi spôsobmi:

- * – ľubovoľný počet kópií vrátane žiadneho;

Nezáporné celé číslo – násobnosť je striktne pevná a rovná sa zadanému číslu (napríklad: 1, 2 alebo 5);

Rozsah nezáporných celých čísel "prvé číslo.. druhé číslo" (napríklad: 1..5, 2..10 alebo 0..5);

Rozsah čísel od konkrétnej počiatočnej hodnoty po ľubovoľné konečné „prvé číslo.. *“ (napríklad: 1..*, 5..* alebo 0..*);

Výpis nezáporných celých čísel a rozsahov oddelených čiarkami (napríklad: 1, 3..5, 10, 15..*).

Ak násobnosť nie je špecifikovaná, potom sa predpokladá, že jej hodnota je 1. Vždy sa predpokladá, že násobnosť inštancií entity zúčastňujúcich sa na závislosti, zovšeobecnení a implementácii je 1.

Nasledujúca tabuľka poskytuje popis expanzných mechanizmov , slúži na objasnenie sémantiky entít a vzťahov. IN všeobecný prípad, mechanizmus rozšírenia je reťazec textu uzavretý v zátvorkách alebo úvodzovkách.

Tabuľka 11.4. Expanzné mechanizmy

Okrem stereotypov označených ako reťazec textu v úvodzovkách možno v diagramoch použiť aj grafické stereotypy. Nasledujúci obrázok ukazuje príklady štandardného a stereotypného zobrazenia.

a) štandardné označenie		b) štandardné označenie s textovým stereotypom		c) grafický stereotyp

Ryža. 11.2. Príklady štandardného a stereotypného triedneho zobrazenia

Diagram predstavuje zoskupenie prvkov notácie na zobrazenie niektorého aspektu rozvinutého informačný systém. Diagramy sú zvyčajne spojené grafy, v ktorých entity sú vrcholy a vzťahy sú oblúky. Nasledujúca tabuľka uvádza stručný popis UML diagramy.

Tabuľka 11.5. Diagramy

Štandard UML 2.x tiež definuje ďalšie, vysoko špecializované diagramy:

Diagram objektov - podobný, ale namiesto tried sa zobrazujú objekty;

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

Diagram zloženej štruktúry – popisuje porty (vrátane rozhraní) triedy pre interakciu s inými triedami;

Profilový diagram - podobný s popisom tried v nich zahrnutých;

Diagram prehľadu interakcií – podobný, ale so skrytými fragmentmi interakcie (fragmenty označené ref). Predstavuje kontextový (konceptuálny), ktorého prvky budú špecifikované na samostatných dekompozičných diagramoch.

Pre účely zväčšeného koncepčného znázornenia vnútornej architektúry systému väčšina konštrukcie umožňuje využiť ustálené grafické stereotypy pre tzv. Takýto diagram sa nazýva 1, ale nepatrí do zoznamu diagramov definovaných štandardom UML.

Pri vývoji samostatného modelu systému sa zostavuje niekoľko typov diagramov. Okrem toho sa pri vývoji modelu komplexného systému spravidla vytvorí niekoľko diagramov rovnakého typu. Zároveň nemusíte vytvárať samostatné typy grafov, ak to nie je potrebné. Napríklad diagramy a sú zameniteľné, sú vytvorené iba pre objekty s komplexným správaním. Nasledujúca tabuľka poskytuje odporúčania týkajúce sa potreby vytvorenia (objasnenia) diagramov pre modely systémov.

Tabuľka 11.6. Vzťah medzi modelmi a diagramami

Nasledujúca tabuľka neukazuje testovací model, keďže v rámci jeho konštrukcie sa diagramy nevyvíjajú, ale kontrolujú (testujú) na úplnosť a konzistenciu.

Niektoré z diagramov po ich zostavení vyžadujú vývoj a objasnenie v rámci vývoja ďalšieho modelu (technologického postupu). Mali by sa teda napríklad pri vývoji objasniť. V modeloch.

4. Definujte pojem " ".

UML model(UML model) je súborom konečnej množiny jazykových konštruktov, z ktorých hlavnými sú entity a vzťahy medzi nimi.

Samotné entity modelu a vzťahy sú inštanciami metamodelových metatried.

Ak vezmeme do úvahy model UML z najvšeobecnejších pozícií, môžeme povedať, že ide o graf (presnejšie o načítaný multi-pseudo-hyper-digraf), v ktorom sú vrcholy a hrany zaťažené dodatočnými informáciami a môžu mať zložitú vnútornú štruktúru. . Vrcholy tohto grafu sa nazývajú entity a hrany sa nazývajú vzťahy.. Zvyšok časti obsahuje rýchle (predbežné) ale úplná recenzia dostupné typy entít a vzťahov. Našťastie ich nie je príliš veľa. V ďalších kapitolách knihy sú všetky entity a vzťahy opäť preskúmané podrobnejšie a na príkladoch.

1.4.1. entity

Pre uľahčenie prehľadu možno entity v UML rozdeliť do štyroch skupín:

• štrukturálne;
• behaviorálne;
• zoskupovanie;
• anotačný.

Štrukturálne entity, ako môžete hádať, sú určené na opis štruktúry. Štrukturálne entity zvyčajne zahŕňajú nasledujúce.

Objekt(objekt) 1 – entita, ktorá je jedinečná a zahŕňa stav a správanie.

triedy(trieda) 2 – popis množiny objektov so spoločnými atribútmi, ktoré definujú stav a operáciami, ktoré definujú správanie.

Rozhranie(rozhranie) 3 – pomenovaná množina operácií, ktorá definuje množinu služieb, o ktoré môže spotrebiteľ požiadať a ktoré môže poskytnúť poskytovateľ služieb.

Spolupráca(spolupráca) 4 - zbierka predmetov, ktoré sa vzájomne ovplyvňujú, aby dosiahli nejaký cieľ.

Charakter(aktér) 5 – entita nachádzajúca sa mimo modelovaného systému a priamo s ním interagujúca.

∇ Takýto vzťah určite existuje, čo je vyjadrené na obr. Hierarchia typov diagramov pre UML 1 ako vzťah závislosti so stereotypom „spresniť“.

∇∇ V UML 1 vznikla mimovoľná asociácia medzi kooperačným diagramom a rovnomennou entitou, čo nebolo celkom pravdivé a niekedy aj zavádzajúce.

∇∇∇ V UML 2 sa syntaktické a sémantické zaťaženie stavového diagramu zmenilo natoľko, že názov už neodráža obsah.

Zoznam nových diagramov a ich názvov prijatých v tejto knihe je uvedený nižšie.

• Diagram kompozitnej štruktúry
• Schéma balíka
• Schéma štátneho stroja
• Komunikačný diagram
• Diagram prehľadu interakcií
• Časový diagram

Na obr. Hierarchia typov diagramov pre UML 2 (časť 1 a 2) Poskytuje sa diagram tried, ktorý ukazuje vzťah medzi diagramami v UML 2.

Neskôr v tejto kapitole veľmi stručne popíšeme všetkých trinásť kanonických diagramov, aby sme mali nejaký kontext a slovnú zásobu pre to, čo nasleduje. Podrobnosti sú uvedené v ostatných kapitolách knihy.

Ale predtým, ako prejdeme k ďalšej časti, urobme malú odbočku týkajúcu sa toho, ako štandard vyžaduje navrhovanie diagramov. Všeobecná šablóna prezentácie diagramu je uvedená nižšie.

Existujú dva hlavné dizajnové prvky: vonkajší rám a štítok s názvom schémy. Ak je s rámom všetko jednoduché - je to obdĺžnik, ktorý obmedzuje oblasť, v ktorej by sa mali nachádzať prvky diagramu, potom je názov diagramu napísaný v špeciálnom formáte znázornenom na obr. Zápis pre diagramy.

Tento zložitý tvar štítku nepodporujú všetky nástroje. Nie je to však potrebné, pretože sémantika je primárna a zápis je sekundárny. V nasledujúcom texte používame ako označenie grafu obdĺžnik, čo by nemalo spôsobiť zmätok.

Možné značky (typy) pre grafy sú uvedené v nasledujúcej tabuľke. Značky navrhované normou sú napísané v druhom stĺpci. Ako však prax ukázala, pravidlá navrhované normou nie sú vždy vhodné a logicky opodstatnené, preto tretí stĺpec tabuľky obsahuje alternatívu, ktorá je podľa nášho názoru rozumná.

Tabuľka Typy grafov a značky

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ý tímom Facility Management Team, vznikol ako výsledok niekoľkých doplnkové systémy UML notácie a teraz sa stal de facto štandardom pre vizuálne modelovanie. Základný princíp akéhokoľvek objektovo orientovaného programovania začína vytvorením modelu.

UML bol vytvorený ako výsledok chaosu okolo vývoja softvéru a dokumentácie. V deväťdesiatych rokoch ich bolo niekoľko rôznymi spôsobmi podania softvérové ​​systémy. 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 zostáva ním dodnes, len s niekoľkými aktualizáciami.

UML je v podstate modelovací jazyk všeobecný účel v oblasti rozvoja softvér. 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 diagramov 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ôzne technológie so všetkými procesmi počas celého cyklu vývoja softvéru.

UML má byť používateľsky vyvinutý jazyk vizuálneho modelovania. Podporuje koncepty rozvoja na vysokej úrovni, ako sú štruktúry, vzory a spolupráca. UML je súbor prvkov, ako napríklad:

1. Príkazy programovacieho jazyka.
2. Aktéri – popisujú rolu, ktorú hrá používateľ alebo akýkoľvek iný systém interagujúci s objektom.
3. Činnosti, ktoré je potrebné vykonať na splnenie zmluvy o dielo a sú uvedené v diagramoch.
4. Obchodný proces, ktorý zahŕňa súbor úloh, ktoré vytvárajú špecifickú službu pre klientov, 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, ktoré predstavujú všeobecné typy správania. Tieto diagramy sa používajú na dokumentáciu architektúry systémov a sú priamo zahrnuté v UML modelovaní systému.

UML diagramy sú prezentované ako statické a dynamické reprezentácie modelu systému. Statické zobrazenie obsahuje diagramy tried a zloženia, ktoré zvý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 typy tak v dokumentácii vývoja softvéru, ako 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 iba pohľad na systém na najvyššej úrovni a s najväčšou pravdepodobnosťou nebude obsahovať všetky potrebné detaily na dokončenie projektu až do úplného konca.
2. Forward Design – Návrh náčrtu sa robí pred kódovaním aplikácie. Toto sa robí pre lepšia recenzia systém alebo pracovný postup, ktorý sa používateľ pokúša 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 zobrazia ako forma dokumentácie pre rôzne aktivity, roly, účastníkov a pracovné postupy.
4. Modrotlač. V tomto prípade diagram slúži ako kompletný návrh, ktorý si vyžaduje len samotnú 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ň vedomostí, školenia používateľov, ako aj manažmentu a personálu.

UML nie je samostatný programovací jazyk ako Java, C++ alebo Python, ale so správnymi nástrojmi sa môže stať pseudoprogramovým jazykom UML. Na dosiahnutie tohto cieľa musí byť celý systém zdokumentovaný v rôznych diagramoch a pomocou správneho softvéru môžu byť diagramy priamo preložené do kódu. Táto metóda môže byť užitočná iba vtedy, ak čas strávený kreslením diagramov zaberie menej času ako písanie skutočného kódu. Hoci UML bol vytvorený pre modelovacie systémy, našiel niekoľko aplikácií v obchodných oblastiach.

Nižšie je uvedený 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 prijatia objednávky ako vstupu do momentu dokončenia objednávky a poskytnutia konkrétneho výstupu.

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, ktoré pokrývajú 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 zobraziť š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ôzne druhy UML diagramy sa pravidelne používajú pri dokumentovaní systémov a architektúr.
2. Paretov princíp platí aj pre použitie UML diagramov.
3. 20 % grafov 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 sú 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ťahy medzi rôznymi činnosťami.

Všetko vyššie uvedené je dôležité 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 tomu hovorí aj mapovanie obchodných procesov. Hlavnými postavami sú autor, redaktor a vydavateľ. Ako Príklad UML Je možné citovať nasledovné. Keď si recenzent pozrie koncept a rozhodne, že je potrebné vykonať nejaké zmeny. Autor potom upraví návrh a vráti ho späť, aby analyzoval recenziu.

Diagram použitia

Základný kameň systému – používa sa na analýzu požiadaviek na úrovni 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. Úlohou aktéra môžu byť používatelia, organizácie alebo externá aplikácia. Vzťahy medzi účastníkmi sú znázornené rovnými šípkami.

Napríklad pre tabuľku 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 vyplatenie akcií, kontrola kvality zásob, vrátenie zásob alebo ich distribúcia.

Tento typ diagramu je vhodný na zobrazenie dynamického správania medzi účastníkmi v systéme, čím zjednodušuje jeho prezentáciu bez toho, aby odrážal detaily implementácie.

Dočasné

Časové diagramy UML sa používajú na znázornenie vzťahov medzi objektmi, kde je zameranie závislé od času. 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ý pomocou záchranného lana, čo je v podstate línia, ktorá tvorí etapy, keď sa jednotlivý účastník pohybuje z jednej etapy do druhej. Pozornosť sa sústreďuje na trvanie udalostí a zmeny, ku ktorým dochádza v závislosti od toho.

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

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

Horizontálne diagramy, tiež nazývané stavové diagramy, sa používajú na opis rôznych stavov komponentu v rámci systému. Prijíma formát konečného 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 ako šachová partia. Typická šachová partia pozostáva z ťahov bieleho a ťahov čierneho. Prvý ťah má biely, ktorý tak 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, medzipristátím alebo remízou (rôzne stavy stroja). Stavové diagramy sa používajú hlavne v doprednom a spätnom dizajne UML. rôzne systémy.

Postupne

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 popise obchodných procesov vďaka svojej vizuálnej samozrejmosti. Ako už názov napovedá, diagramy popisujú postupnosť správ a interakcií, ktoré sa vyskytujú 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í.

Ak chcete získať viac úplné informácie, môžete zvážiť príklad sekvenčného diagramu UML nižšie.

Ako vyplýva z príkladu, štruktúrne diagramy sa používajú na zobrazenie štruktúry systému. Presnejšie povedané, jazyk sa používa pri vývoji softvéru na znázornenie architektúry systému a spôsobu, akým sú rôzne komponenty prepojené.

Diagram tried UML je najbežnejším typom diagramu pre softvérovú dokumentáciu. Keďže väčšina programov vytvorených v súčasnosti je stále založená na paradigme objektovo orientovaného programovania, používanie diagramov tried na dokumentovanie softvéru sa ukazuje ako zdravý rozum. Je to preto, že OOP je založený na triedach UML a vzťahoch medzi nimi. Stručne povedané, diagramy 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. Komunikácia medzi rôzne triedy(znázornený spojovacou čiarou) tvorí diagram tried. Vyššie uvedený príklad ukazuje základný diagram tried.

Objekty

Pri diskusii o štruktúrnych diagramoch UML je potrebné ponoriť sa do koncepcií informatiky. V softvérovom inžinierstve sa s triedami zaobchádza ako s abstraktnými dátovými typmi, zatiaľ čo objekty sú inštancie, ak napríklad existuje „Car“, čo je všeobecný abstraktný typ, potom inštancia triedy „Car“ bude „Audi“.

UML objektové diagramy pomáhajú vývojárom softvéru kontrolovať, či vygenerovaná abstraktná štruktúra predstavuje životaschopnú štruktúru, keď je implementovaná v praxi, to znamená, keď sú objekty konkretizované. Niektorí vývojári to považujú za sekundárnu úroveň kontroly presnosti. Zobrazuje inštancie tried. Presnejšie povedané, generická trieda „Client“ má teraz skutočného klienta, napríklad nazývaného „James“. James je inštanciou všeobecnejšej triedy a má rovnaké atribúty, avšak s danými hodnotami. To isté sa urobilo s účtu"Účty a úspory." 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 môžete vytvoriť fyzický model toho, ako sa softvérové ​​komponenty (artefakty) nasadzujú na hardvérové ​​komponenty známe 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. Artefaktová schéma klientskej aplikácie a databázy.

Diagram balíka je podobný kolekcii makier pre diagramy nasadenia UML, 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 postavený aj na niekoľkých ďalších balíkoch, ktoré reprezentujú zložitejšie systémy a správanie.

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

Ako každá iná vec v živote, aby ste urobili niečo správne, potrebujete správne nástroje. Nástroje, ktoré ponúkajú anotácie UML a šablóny diagramov, sa používajú na dokumentáciu softvéru, procesov alebo systémov. K dispozícii sú rôzne dokumentačné nástroje softvér, ktorý vám môže pomôcť nakresliť diagram.

Zvyčajne spadajú do nasledujúcich hlavných kategórií:

1. Papier a pero sú jednoduché. Vezmite papier a pero, otvorte UML syntaktický kód z internetu a nakreslite akýkoľvek typ diagramu, ktorý potrebujete.
2. Online nástroje – Existuje niekoľko online aplikácií, ktoré môžete použiť na vytvorenie grafu. Väčšina z nich ponúka platené predplatné alebo obmedzený počet diagramov na voľnej úrovni.
3. Bezplatné online nástroje sú takmer rovnaké ako platené. Hlavný rozdiel je v tom, že platené ponúkajú aj tutoriály a hotové šablóny pre konkrétne diagramy.
4. Desktopová aplikácia – typickou desktopovou aplikáciou, ktorá sa používa 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 celkom zrejmé, že UML je dôležitým aspektom spojeným s objektovo orientovaným vývojom softvéru. Na tvorbu používa grafický zápis vizuálne modely systémové programy.

UML je všeobecný grafický modelovací jazyk na špecifikovanie, vizualizáciu, navrhovanie a dokumentovanie všetkých artefaktov vytvorených počas vývoja softvérových systémov.

Existuje veľa dobrých kníh, ktoré podrobne popisujú UML (niekedy dokonca veľmi podrobne), rád by som na jednom mieste zhromaždil základné pojmy o diagramoch, entitách a prepojeniach medzi nimi pre rýchle pripomenutie, niečo ako cheat sheet.

Tento článok používa materiály z kníh: Ivanov D. Yu., Novikov F. A. Jednotný modelovací jazyk UML A Leonenkov. UML tutoriál.

Najprv sa rozhodneme pre editora. Pod Linuxom som skúšal rôzne UML editory, najviac sa mi páčil UMLet, hoci je napísaný v Jave, pohybuje sa veľmi rýchlo a obsahuje väčšinu šablón entít. Existuje aj ArgoUML, multiplatformový UML editor, tiež napísaný v Jave, ktorý je funkčne bohatý, no viac spomaľuje.

Zastavil som sa pri UMLet, nainštalujte ho pod Arch Linux A Ubuntu:

# v Arch Linuxe yaourt -S umlet # v Ubuntu sudo apt-get install umlet

V UML možno všetky entity rozdeliť do nasledujúcich typov:

• štrukturálne;
• behaviorálne;
• zoskupovanie;
• poznámka;

V UML sa používajú štyri hlavné typy vzťahov:

Závislosť- označuje, že zmena v nezávislom subjekte nejakým spôsobom ovplyvňuje závislý subjekt. Graficky je vzťah závislosti znázornený ako bodkovaná čiara so šípkou smerujúcou od závislej entity k nezávislej entite.

asociácie- nastáva, ak jedna entita priamo súvisí s inou (alebo s inými - asociácia môže byť nielen binárna). Graficky je asociácia znázornená ako plná čiara s rôznymi doplnkami spájajúcimi súvisiace entity.

Zovšeobecnenie je vzťah medzi dvoma entitami, z ktorých jedna je špeciálnym (špecializovaným) prípadom druhej. Graficky je zovšeobecnenie znázornené ako čiara s trojuholníkovou nevyplnenou šípkou na konci, ktorá smeruje od konkrétnej (podtriedy) k všeobecnej (nadtrieda).

Implementácie- Implementačný vzťah naznačuje, že jedna entita je implementáciou inej. Graficky je implementácia znázornená ako bodkovaná čiara s trojuholníkovou, nevyplnenou šípkou na konci, ktorá smeruje od implementujúcej entity k implementovanej entite.

IN UML 2 definované 13 typy diagramov. Podľa noriem musí mať každý diagram v ľavom hornom rohu rám s obdĺžnikom (pravý dolný roh skosený), ktorý označuje identifikátor diagramu (tag) a nadpis.

Diagramy na znázornenie štruktúry systému:

• Schéma komponentov (tag komponent);
• Schéma nasadenia, tag nasadenie);
• Diagram tried (diagram tried, tag trieda);
• Diagram objektu (tag objekt);
• Schéma zloženej štruktúry, tag trieda);

Diagramy na znázornenie správania systému:

• Synchronizačný diagram (interakčný diagram, tag načasovanie);
• Diagram aktivity (tag činnosť);
• Sekvenčný diagram, tag SD);
• Komunikačný diagram (tag comm);
• Schéma štátneho stroja, značka štátny automat);
• diagram prehľadu interakcií, tag interakcie);

Diagramy vynikajú:

• Diagram prípadu použitia (diagram prípadu použitia, značka prípadu použitia);
• Diagram balíka (diagram balíka, značka balík);

Diagram použitia

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

Keď považujete diagram prípadu použitia za model systému, môžete ho priradiť k modelu čiernej skrinky. Každý prípad použitia definuje postupnosť akcií, ktoré musí navrhnutý systém vykonať pri interakcii s príslušným aktérom.

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

Asociačný vzťah- Tento vzťah špecifikuje, akú konkrétnu úlohu hrá aktér pri interakcii s prípadom použitia. Asociačný vzťah je označený plnou čiarou medzi aktérom a prípadom použitia. Tento riadok môže mať ďalšie symboly, ako je názov a násobok.

Expanzný vzťah- definuje vzťah medzi inštanciami konkrétneho prípadu použitia a všeobecnejšieho prípadu použitia, ktorého vlastnosti sú určené na základe spôsobu, akým sa tieto prípady navzájom kombinujú. Ak teda existuje vzťah rozšírenia z prípadu použitia A na prípad použitia B, znamená to, že vlastnosti inštancie prípadu použitia B možno rozšíriť vďaka prítomnosti vlastností v rozšírenom prípade použitia A.

Vzťah rozšírenia medzi prípadmi použitia je označený bodkovaná čiara so šípkou (možnosť vzťahu závislosti) smerujúcou preč od prípadu použitia, ktorý je rozšírením pôvodného prípadu použitia.

Generalizačný vzťah slúži na označenie skutočnosti, že niektorý prípad použitia A možno zovšeobecniť na prípad použitia B. V tomto prípade bude možnosť A špecializáciou možnosti B. V tomto prípade sa B nazýva predok alebo rodič A a možnosť A je dieťa s možnosťou použitia V.

Graficky je tento vzťah znázornený plnou čiarou so šípkou v tvare otvoreného trojuholníka, ktorá označuje nadradený prípad použitia.

Všeobecný vzťah medzi prípadmi použitia sa používa vtedy, keď je potrebné poznamenať, že podradené prípady použitia majú všetky atribúty a správanie rodičovských prípadov použitia.

Inkluzívny vzťah medzi dvoma prípadmi použitia naznačuje, že niektoré špecifikované správanie pre jeden prípad použitia je zahrnuté ako základný komponent v sekvencii správania druhého prípadu použitia.

Vzťah zahrnutia nasmerovaný z prípadu použitia A na prípad použitia B naznačuje, že každý prípad použitia A obsahuje funkčné vlastnosti špecifikované pre prípad použitia B.

Graficky je tento vzťah označený bodkovanou čiarou so šípkou (variant vzťahu závislosti) smerujúcou od základného prípadu použitia k zahrnutému.

Diagram triedy

Diagram triedy(diagram tried) je hlavným spôsobom popisu statickej štruktúry systému.

Diagram tried používa jeden hlavný typ entity: triedy (vrátane mnohých špeciálnych prípadov tried: rozhrania, primitívne typy, asociačné triedy atď.), medzi ktorými sú vytvorené tieto hlavné typy vzťahov: závislosti, asociácie, zovšeobecnenia, implementácie.

Vzťah závislosti vo všeobecnosti označuje nejaký sémantický vzťah medzi dvoma prvkami modelu alebo dvoma súbormi takýchto prvkov, ktorý nie je vzťahom asociácie, zovšeobecnenia alebo implementácie. Vzťah závislosti sa používa v situácii, keď určitá zmena jedného prvku modelu môže vyžadovať zmenu iného prvku modelu, ktorý od neho závisí.

Vzťah závislosti je graficky znázornený bodkovanou čiarou medzi zodpovedajúcimi prvkami so šípkou na jednom konci, pričom šípka ukazuje z klientskej triedy závislosti na nezávislú alebo zdrojovú triedu.

Nad šípkou môžu byť špeciálne kľúčové slová (stereotypy):

• "access" - slúži na označenie dostupnosti verejných atribútov a operácií zdrojovej triedy pre triedy klientov;
• "bind" - trieda klienta môže použiť nejakú šablónu pre svoju následnú parametrizáciu;
• "derive" - ​​atribúty triedy klienta možno vypočítať z atribútov zdrojovej triedy;
• "import" - verejné atribúty a operácie zdrojovej triedy sa stávajú súčasťou klientskej triedy, ako keby boli deklarované priamo v nej;
• "spresniť" - označuje, že trieda klienta slúži ako spresnenie zdrojovej triedy z historických dôvodov, keď sa objaví dodatočné informácie pri práci na projekte.

Asociačný vzťah zodpovedá prítomnosti nejakého vzťahu medzi triedami. Tento vzťah je označený plnou čiarou s ďalšími špeciálnymi symbolmi, ktoré charakterizujú jednotlivé vlastnosti konkrétneho združenia. Ako doplnkové špeciálne znaky Je možné použiť názov asociácie, ako aj názvy a násobnosti tried rolí asociácie. Názov združenia je nepovinným prvkom jeho označenia.

Agregačný vzťah sa vyskytuje medzi niekoľkými triedami, ak jedna z tried predstavuje entitu, ktorá zahŕňa iné entity ako komponenty. Používa sa na reprezentáciu systémových vzťahov typu „časť-celok“.

Pomer zloženia je špeciálny prípad agregačného vzťahu. Tento vzťah slúži na zvýraznenie špeciálnej formy vzťahu „časť-celok“, v ktorom sú jednotlivé časti v určitom zmysle umiestnené v rámci celku. Špecifickosť vzťahu medzi nimi spočíva v tom, že časti nemôžu pôsobiť izolovane od celku, t. j. zničením celku sú zničené všetky jeho súčasti.

Generalizačný vzťah je vzťah medzi všeobecnejším prvkom (rodič alebo predok) a konkrétnejším resp špeciálny prvok(dieťa alebo potomok). Pri aplikácii na diagram tried tento vzťah popisuje hierarchickú štruktúru tried a dedičnosť ich vlastností a správania. To predpokladá, že trieda potomka má všetky vlastnosti a správanie triedy predkov a má tiež svoje vlastné vlastnosti a správanie, ktoré trieda predka nemá.

Schéma stroja

Schéma stroja(schéma stavového stroja) príp stavový diagram v UML 1 (stavový diagram) je jedným zo spôsobov, ako podrobne opísať správanie v UML. Ako už názov napovedá, diagramy strojov sú v podstate grafom stavov a prechodov konečného automatu nabitého mnohými ďalšími detailmi a detailmi.

Stavový diagram popisuje proces zmeny stavov iba jednej triedy, presnejšie jednej inštancie určitej triedy, t.j. modeluje všetky možné zmeny stavu konkrétneho objektu. V tomto prípade môže byť zmena stavu objektu spôsobená vonkajšími vplyvmi z iných objektov alebo zvonku. Má opísať reakciu objektu na také vonkajšie vplyvy, že sa používajú stavové diagramy.

V diagrame automatov sa používa jeden hlavný typ entity - stavy a jeden typ vzťahu - prechody, ale pre oba je definovaných veľa odrôd, špeciálnych prípadov a dodatočných zápisov. Automat predstavuje dynamické aspekty modelovaného systému vo forme orientovaného grafu, ktorého vrcholy zodpovedajú stavom a oblúky prechodom.

Počiatočný stav je špeciálny prípad stavu, ktorý neobsahuje žiadne vnútorné úkony (pseudostav). Objekt je v počiatočnom čase štandardne v tomto stave. Slúži na označenie grafickej oblasti na stavovom diagrame, od ktorej začína proces zmeny stavov.

finále (konečné) stav je špeciálny prípad stavu, ktorý taktiež neobsahuje žiadne vnútorné úkony (pseudostavy). Objekt bude v tomto stave štandardne potom, čo stroj dokončí svoju činnosť v konečnom bode v čase.

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.

Diagram aktivity(diagram aktivity) je ďalší spôsob popisu správania, ktorý vizuálne pripomína starý dobrý vývojový diagram algoritmu. Používa sa na modelovanie procesu vykonávania operácií.

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.

Diagram aktivity používa jeden hlavný typ entity – akciu a jeden typ vzťahu – prechody (prenosy kontroly). Používajú sa aj také konštrukcie, ako sú rozvetvenia, fúzie, spojenia a odbočky. Odporúčané ako názov jednoduchá akcia použiť sloveso s vysvetľujúcimi slovami.

Sekvenčný diagram

Sekvenčný diagram(sekvenčný diagram) je spôsob, ako opísať správanie systému „pomocou príkladov“.

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 základný typ entity – inštancie interagujúcich klasifikátorov (väčšinou triedy, komponenty a aktéri) – a jeden typ vzťahu – spojenia, v rámci ktorých sa vymieňajú správy.

Možné typy správ (obrázok prevzatý z larin.in):

Komunikačný diagram

Komunikačný diagram(komunikačný diagram) – 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.

V komunikačnom diagrame, ako aj v sekvenčnom diagrame sa teda používa jeden hlavný typ entít – inštancie interagujúcich klasifikátorov a jeden typ vzťahu – spojenia. Tu sa však nekladie dôraz na čas, ale na štruktúru spojení medzi konkrétnymi prípadmi.

Diagram komponentov

Diagram komponentov(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, ako aj rozhrania, prostredníctvom ktorých sú špecifikované vzťahy 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);

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 rozloženia sú v porovnaní s diagramom komponentu pridané dva typy entít: artefakt, ktorý je implementáciou komponentu a uzla (môže to byť buď klasifikátor popisujúci typ uzla alebo konkrétna inštancia), a asociačný vzťah medzi uzlami, čo naznačuje, že uzly sa počas vykonávania fyzicky prepojili.

Diagram objektu

Diagram objektu(objektový diagram) – je inštanciou diagramu tried.

Objektový diagram používa jeden hlavný typ entity: objekty (inštancie tried), medzi ktorými sú naznačené špecifické spojenia (najčastejšie inštancie asociácií). Diagramy objektov majú pomocný charakter – v skutočnosti ide o príklady (dalo by sa povedať, že výpisy pamäte), ktoré ukazujú, aké objekty sú k dispozícii a prepojenia medzi nimi v určitom konkrétnom momente prevádzky systému.

Schéma vnútornej štruktúry(composite structure diagram) slúži na podrobnejšiu reprezentáciu štruktúrnych klasifikátorov, predovšetkým tried a komponentov.

Štrukturálny klasifikátor je znázornený ako obdĺžnik s názvom klasifikátora v hornej časti. Vo vnútri sú diely. Môže existovať niekoľko častí. Časti môžu vzájomne pôsobiť. Toto je indikované pomocou konektorov rôznych typov. Miesto na vonkajšom okraji časti, ku ktorej sa pripája konektor, sa nazýva port. Porty sú tiež umiestnené na vonkajšej hranici štruktúrneho klasifikátora.

Diagram prehľadu interakcií Diagram prehľadu interakcie je typ diagramu aktivity s rozšírenou syntaxou: prvky diagramu prehľadu interakcie môžu byť prepojenia na použitie interakcie definované sekvenčnými diagramami.

Časový diagram

Časový diagramČasový diagram je špeciálna forma sekvenčného diagramu, ktorý sa zameriava na meniace sa stavy rôznych inštancií klasifikátorov a ich časovú synchronizáciu.

Schéma balíka

Schéma balíka(package diagram) je jediný nástroj, ktorý vám umožňuje riadiť zložitosť samotného modelu.

Hlavnými prvkami zápisu sú balíčky a závislosti s rôznymi stereotypmi.

Model vzťahu entít (model ER)

Analógové diagramy tried(UML) možno ER model, ktorý sa používa pri návrhu databáz (relačný model).

Model entít a vzťahov (ER-model) je dátový model, ktorý vám umožňuje opísať koncepčné diagramy predmetnej oblasti. Model ER sa používa vo vysokoúrovňovom (koncepčnom) návrhu databáz. S jeho pomocou môžete identifikovať kľúčové entity a identifikovať spojenia, ktoré je možné medzi týmito entitami vytvoriť. wikipedia

Akýkoľvek fragment predmetnej oblasti môže byť reprezentovaný ako súbor entít, medzi ktorými existuje množstvo spojení.

Základné pojmy:

Esencia(entita) je objekt, ktorý možno identifikovať nejakým spôsobom, ktorý ho odlišuje od iných objektov, napr. KLIENT 777. Entita je vlastne súbor atribútov.

Súprava entít(množina entít) - množina entít rovnakého typu (s rovnakými vlastnosťami).

Pripojenie(vzťah) je združenie založené medzi viacerými subjektmi.

doména(doména) - množina hodnôt (definičná doména) atribútu.

Existujú tri typy binárnych väzieb:

• jedna k jednej- jedna inštancia entity jednej triedy je spojená s jednou inštanciou entity inej triedy, napríklad HEAD - DEPARTMENT;
• 1 až N alebo jeden k mnohým- jedna inštancia entity jednej triedy je spojená s mnohými inštanciami entity inej triedy, napríklad ODDELENIE - ZAMESTNANEC;
• N až M alebo veľa mnohým- veľa inštancií entity jednej triedy je spojených s mnohými inštanciami entity inej triedy, napríklad ZAMESTNANEC - PROJEKT;
Slovník základných pojmov v UML

Objekt- entita, ktorá je jedinečná a zahŕňa stav a správanie.

triedy- popis množiny objektov so spoločnými atribútmi, ktoré definujú stav a operácie, ktoré definujú správanie.

Rozhranie- pomenovaná množina operácií, ktorá definuje množinu služieb, o ktoré môže spotrebiteľ požiadať a ktoré môže poskytnúť poskytovateľ služieb.

Spolupráca- súbor predmetov, ktoré sa vzájomne ovplyvňujú, aby dosiahli nejaký cieľ.

herec- entita nachádzajúca sa mimo modelovaného systému a priamo s ním interagujúca.

Komponent- modulárna časť systému s jasne definovanou sadou požadovaných a poskytovaných rozhraní.

Artefakt- prvok informácie, ktorý sa používa alebo generuje počas procesu vývoja softvéru. Inými slovami, artefakt je fyzická jednotka implementácie odvodená od prvku modelu (ako je trieda alebo komponent).

Uzol- výpočtový zdroj, na ktorom sú umiestnené a v prípade potreby spustené artefakty.

Behaviorálne entity sú určené na opis správania. Existujú len dve hlavné entity správania: stav a činnosť.

štátu- obdobie v životnom cykle predmetu, počas ktorého predmet spĺňa určitú podmienku a vykonáva vlastnú činnosť alebo čaká na výskyt nejakej udalosti.

Akcia- primitívny atómový výpočet.

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.

Klasifikátor je deskriptor množiny objektov rovnakého typu.

Dodatočné čítanie

• Fowler M. UML. Základy, 3. vydanie
• Buch G., Rambo D., Jacobson I. Jazyk UML. Používateľská príručka