Simulačné diagramy. Základné schémy jazyka UML. Diagramy prehľadu interakcií

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

Samotné entity a vzťahy modelu sú inštanciami metatried metamodelu.

Vzhľadom na UML model z najvšeobecnejších pozícií môžeme povedať, že ide o graf (presnejšie 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 poskytuje rýchly (predbežný), ale úplný prehľad dostupných typov 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 znovu uvažované podrobnejšie a s príkladmi.

1.4.1. Esencie

Pre prehľadnosť možno entity v UML rozdeliť do štyroch skupín:

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

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

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

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

Rozhranie(rozhranie) 3 je 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žby.

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

herec(herec) 5 je entita, ktorá je mimo modelovaného systému a priamo s ním interaguje.

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

∇∇ V UML 1 došlo k nedobrovoľnej asociácii medzi diagramom spolupráce a entitou s rovnakým názvom, čo nebolo úplne pravdivé a niekedy 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 diagramu pre UML 2 (časť 1 a 2) diagram tried zobrazujúci vzťah diagramov v UML 2.

Ďalej 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 zostávajúcich kapitolách knihy.

Ale predtým, ako prejdeme k ďalšej časti, urobme malú odbočku o tom, ako štandard vyžaduje formátovanie grafov. Všeobecná šablóna prezentácie grafu je uvedená nižšie.

Existujú dva hlavné dizajnové prvky: vonkajší rám a štítok s názvom grafu. Ak je s rámom všetko jednoduché - je to obdĺžnik, ktorý ohraničuje 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. Grafický zápis.

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

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

Tab. Typy grafov a značky

Názov grafu	Značka (štandardná)	Značka (odporúčané)
Diagram použitia	prípad použitia alebo uč	prípad použitia
diagram tried	trieda	trieda
diagram automatu	štátny automat alebo stm	štátny automat
diagram činnosti	činnosť alebo konať	činnosť
sekvenčný diagram	interakcia alebo SD	SD
Komunikačný diagram	interakcia alebo SD	comm
Diagram komponentov	komponent alebo cmp	komponent
Schéma umiestnenia	neurčené	nasadenie
Diagram objektu	neurčené	objekt
Schéma vnútornej štruktúry	trieda	trieda alebo komponent
Diagram prehľadu interakcií	interakcia alebo SD	interakcia
Časový diagram	interakcia alebo SD	načasovanie
Schéma balíka	balík alebo bal	balík

11.1. Štruktúra jednotného modelovacieho jazyka

Jednotný modelovací jazyk (UML) je v súčasnosti de facto štandardom pre popis (dokumentáciu) výsledkov navrhovania a vývoja objektovo orientovaných systémov. Vývoj UML začali v roku 1994 Grady Booch a James Rumbaugh v Rational Software. Na jeseň 1995 sa k nim pridal Ivar Jakobson 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é distribuované spracovanie. Zjednotený modelovací jazyk (UML). Verzia 1.4.2");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Informačné technológie. Jednotný modelovací jazyk skupiny pre správu objektov (OMG UML). Časť 1. Infraštruktúra" (angl. "Informačné technológie -- Unified Modeling Language Management Group (OMG) UML) - Časť 1: Infraštruktúra") a "ISO / IEC 19505-2: 2012. Informačné technológie. Zjednotený modelovací jazyk pre správu objektov (OMG UML). Časť 2. Nadstavba" (anglicky "Information technology - Object Management Group Unified Modeling" Jazyk (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 - časť lingvistiky, ktorá študuje význam jednotiek jazyka, 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ájania viet do zložitých súvetí, spôsoby vytvárania výrokov ako súčasti textu.

Vo vzťahu k UML teda sémantika a syntax určujú štýl prezentácie (tvorba modelov), ktorá kombinuje prirodzené a formálne jazyky, aby reprezentovala 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é spojenie prvkov diagramu;

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

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

Tabuľka 11.1. Esencie

Typ	názov	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 imaginárnej entity s dobre definovanými pojmovými hranicami, individualitou (identitou), stavom a správaním. Z pohľadu UML sú objekty inštancie tried (inštancie entít)
	(herec)	Inžinier cestné služby	Entita mimo systému, ktorá interaguje so systémom a využíva jeho funkčnosť na dosiahnutie určitých cieľov alebo riešenie konkrétnych problémov. 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ýsledku, ktorý je pre aktéra významný
	(š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 riešenie problému
Zoskupovanie	(balík)		Všeobecný mechanizmus zoskupovania prvkov. Na rozdiel od komponentu je balík čisto konceptuálny (abstraktný) koncept. Špeciálnymi prípadmi balíka sú systém a model
	(fragment)		Oblasť špecifickej interakcie inštancií aktéra a objektu
	(oddiel činností)		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 nezvyčajnej situácie
vysvetľujúce	Poznámka (komentár)		Komentár prvku. Pripojené ku komentovanému prvku prerušovanou čiarou

Niektoré zdroje, najmä [ , ], rozlišujú aj entity správania interakcie A štátne stroje, ale z logického hľadiska by sa mali klasifikovať ako diagramy.

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

Nasledujúca tabuľka popisuje každý typ vzťahy UML používané v diagramoch na označenie vzťahov medzi entitami.

Tabuľka 11.3. Vzťahy

názov	Označenie	Definícia (sémantika)
asociácie		Vzťah, ktorý opisuje zmysluplný vzťah medzi dvoma alebo viacerými entitami. 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 naznačený z "celej" strany. Vzťah je určený iba medzi entitami rovnakého typu
Zloženie		Poddruh 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). Na strane šípky je označená nezávislá entita
Zovšeobecnenie		Vzťah medzi zovšeobecnenou entitou (predok, rodič) a špecializovanou entitou (dieťa, dcéra). Trojuholník je naznačený zo strany rodiča. Vzťah je určený iba medzi entitami rovnakého typu
Realizácia		Vzťah medzi entitami, kde jeden subjekt špecifikuje činnosť, ktorú sa iný subjekt 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 šípky označuje entitu, ktorá definuje akciu (rozhranie alebo prípad použitia)

Pre asociáciu, agregáciu a zloženie môžete zadať mnohosť (anglická multiplicity), ktorá charakterizuje celkový počet inštancií subjektov participujúcich na vzťahu. Spravidla sa uvádza na každej strane vzťahu v blízkosti zodpovedajúcej entity. Násobnosť je možné určiť 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 určené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..*);

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

Ak násobnosť nie je špecifikovaná, predpokladá sa, že jej hodnota je 1. Mnohonásobnosť inštancií entity zapojených do závislosti, zovšeobecnenia a implementácie sa vždy považuje za 1.

Nasledujúca tabuľka poskytuje popis expanzných mechanizmov používa sa na spresnenie sémantiky entít a vzťahov. Vo všeobecnosti je mechanizmus rozšírenia reťazec textu uzavretý v zátvorkách alebo úvodzovkách.

Tabuľka 11.4. Predlžovacie mechanizmy

názov	Označenie	Definícia (sémantika)
Stereotyp (stereotyp)	« »	Označenie, ktoré špecifikuje sémantiku prvku zápisu (napríklad: závislosť so stereotypom „include“ sa považuje za inkluzívny vzťah a trieda so stereotypom „hranica“ je hraničná trieda)
strážny stav (stav stráže)		Booleovská podmienka (napríklad: alebo [identifikácia dokončená])
Obmedzenie (obmedzenie)	{ }	Pravidlo, ktoré obmedzuje sémantiku prvku modelu (napríklad (čas vykonania kratší ako 10 ms))
Označená hodnota (označená hodnota)	{ }	Nová alebo kvalifikujúca vlastnosť prvku notácie (napríklad: (verzia = 3.2))

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

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 mapovania tried

Diagram je zoskupenie prvkov notácie na zobrazenie niektorého aspektu vyvíjaného informačného systému. Diagramy sú spravidla spojené grafy, v ktorých entity sú vrcholy a vzťahy sú oblúky. Nasledujúca tabuľka poskytuje stručný popis diagramov UML.

Tabuľka 11.5. Diagramy

Diagram			Účel
				podľa stupňa fyzickej realizácie	zobrazením dynamiky	podľa zobrazeného aspektu
(prípad použitia)			Zobrazuje systémové funkcie, interakciu medzi aktérmi a funkciami	logické	statické	funkčné
(trieda)			Zobrazuje množinu tried, rozhraní a vzťahov medzi nimi	Boolean alebo fyzické	statické	Funkčné informácie
(balík)			Zobrazuje množinu balíkov a ich vzťahy	Boolean alebo fyzické	statické	Komponent
správanie (správanie)	(štátny automat)		Zobrazuje stavy entity a prechody medzi nimi počas jej životného cyklu	logické	Dynamický	behaviorálna
	(aktivita)		Zobrazuje obchodné procesy v systéme (popis algoritmov správania)
	Interakcie (interakcia)	(sekvencia)	Zobrazuje postupnosť správ medzi objektmi a aktérmi
		(komunikácia)	Podobne ako sekvenčný diagram, ale hlavný dôraz sa kladie na štruktúru interakcie medzi objektmi
Implementácie (implementácia)	(komponent)		Zobrazuje súčasti systému (programy, knižnice, tabuľky atď.) a prepojenia medzi nimi	Fyzické	statické	Komponent
	(nasadenie)		Zobrazuje umiestnenie komponentov podľa sieťových uzlov, ako aj jej konfiguráciu

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

Objektový diagram (objektový diagram) - 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 na interakciu s inými triedami;

Profilový diagram (profilový diagram) - podobný popisu tried v nich zahrnutých;

Diagram prehľadu interakcií – podobný, ale so skrytými fragmentmi interakcie (fragmenty s referenčným štítkom). Ide o kontextový (konceptuálny), ktorého prvky budú špecifikované na samostatných dekompozičných diagramoch.

S cieľom zväčšiť koncepčné znázornenie vnútornej architektúry systému väčšina konštrukcie umožňuje využiť zabehnuté 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 zostavuje niekoľko diagramov rovnakého typu. Zároveň nemusíte vytvárať samostatné zobrazenia grafu, ak to nepotrebujete. Napríklad diagramy a sú vzájomne 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 (spresnenia) diagramov pre systémové modely.

Tabuľka 11.6. Prepojenie modelov a diagramov

Vyššie uvedená tabuľka nezobrazuje testovací model, pretože v rámci jeho konštrukcie sa nevyvíjajú diagramy, ale kontroluje sa (testuje) úplnosť a konzistencia.

Časť diagramov po ich zostrojení vyžaduje vývoj a dolaďovanie v rámci vývoja ďalšieho modelu (technologického postupu). Takže napríklad by sa to malo objasniť počas vývoja. v modeloch.

4. Definujte pojem "".

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 opísať systémy takmer z každého možného uhla pohľadu, pričom zohľadňuje 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 označuje vzťah medzi prvkami (objektmi).
5. sekvenčný diagram používa sa 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.

Všetky diagramy UML je možné podmienečne rozdeliť do dvoch skupín, z ktorých prvá sú všeobecné diagramy. Všeobecné diagramy sú prakticky nezávislé od predmetu modelovania a môžu byť použité v akomkoľvek softvérovom projekte bez ohľadu na predmet, oblasť rozhodovania atď.

1.5.1. Diagram použitia

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

Diagram použitia má odpovedať na hlavnú otázku modelovania: čo robí systém vo vonkajšom svete?

V diagrame použitia sa používajú dva typy hlavných entít: prípady použitia 1 a aktéri 2, medzi ktorými sú vytvorené tieto hlavné typy vzťahov:

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

Diagram použitia, ako každý iný, môže mať komentáre 7 . Okrem toho sa to dôrazne odporúča urobiť, aby sa zlepšila čitateľnosť máp.

Hlavné prvky zápisu použitého v diagrame použitia sú uvedené nižšie. Podrobný popis je uvedený v časti 2.2.

1.5.2. diagram tried

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

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

V diagrame tried sa používa jeden hlavný typ entít: triedy 1 (vrátane mnohých špeciálnych prípadov tried: rozhrania, primitívne typy, asociačné triedy a mnohé ďalšie), medzi ktorými sú vytvorené tieto hlavné typy vzťahov:

• spojenie medzi triedami 2 (s mnohými ďalšími podrobnosťami);
• zovšeobecňovanie medzi triedami 3;
• závislosti (rôzneho typu) medzi triedami 4 a medzi triedami a rozhraniami.

Niektoré prvky zápisu použitého v diagrame tried sú uvedené nižšie. Podrobný popis je uvedený v kapitole 3.

1.5.3. diagram automatu

diagram automatu(diagram stavového automatu) je jedným zo spôsobov, ako podrobne opísať správanie v UML na základe explicitného pridelenia stavov a popisu prechodov medzi stavmi.

Automatové diagramy, ako už názov napovedá, sú v podstate grafom prechodu stavu (pozri kapitolu 4), ktorý je nabitý mnohými ďalšími detailmi a detailmi.

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

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

1.5.4. diagram činnosti

diagram činnosti(diagram aktivít) - spôsob opisu správania na základe indikácie riadiacich tokov a dátových tokov.

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

V diagrame aktivít sa používa jeden hlavný typ entít - akcia 1 a jeden typ vzťahu - prechody 2 (prenosy kontroly a údajov). Používajú sa aj také konštrukcie ako rozvetvenia, splynutia, spojenia, vetvy 3 , ktoré sú podobné entitám, ale v skutočnosti nimi nie sú, ale sú grafickým spôsobom znázornenia niektorých špeciálnych prípadov mnohomiestnych vzťahov. Sémantika prvkov diagramu aktivít je podrobne popísaná v kapitole 4. Hlavné prvky zápisu použitého v diagrame aktivít sú uvedené nižšie.

1.5.5. sekvenčný diagram

sekvenčný diagram(sekvenčný diagram) je spôsob popisu správania systému na základe indikácie postupnosti prenášaných správ.

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

V sekvenčnom diagrame sa používa jeden hlavný typ entít – inštancie interagujúcich klasifikátorov 1 (hlavne triedy, komponenty a aktéri) a jeden typ vzťahu – spojenia 2, prostredníctvom ktorých sa vymieňajú správy 3 . Existuje niekoľko spôsobov odosielania správ, ktoré sa v grafickom zápise líšia vo forme šípky zodpovedajúcej vzťahu.

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

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

Nasledujúci obrázok zobrazuje hlavné prvky notácie použité v sekvenčnom diagrame. Na označenie samotných interagujúcich objektov sa používa štandardný zápis - obdĺžnik s názvom inštancie klasifikátora. Bodkovaná čiara, ktorá z nej vychádza, sa nazýva línia života (lifeline) 4 . Nejde o označenie vzťahu v modeli, ale o grafický komentár, ktorý má čitateľa diagramu nasmerovať správnym smerom. Postavy vo forme úzkych pásikov prekrytých na línii života tiež nie sú obrázkami simulovaných entít. Toto je grafický komentár zobrazujúci dĺžku času, počas ktorého objekt vlastní výskyt vykonávania 5 alebo inými slovami, ako prebieha aktivácia objektu. Kroky interakcie zlúčeniny (kombinovaný fragment) 6 umožňujú, aby sekvenčný diagram odrážal algoritmické aspekty protokolu interakcie. Viac podrobností o zápise sekvenčného diagramu nájdete v kapitole 4.

1.5.6. Komunikačný diagram

Komunikačný diagram(komunikačný diagram) – spôsob popisu správania, významovo ekvivalentný sekvenčnému diagramu.

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

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

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

1.5.7. Diagram komponentov

Diagram komponentov(diagram komponentov) – zobrazuje vzťah medzi modulmi (logickými alebo fyzickými), ktoré tvoria simulovaný systém.

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

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

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

1.5.8. Schéma umiestnenia

Schéma umiestnenia(diagram nasadenia) spolu so zobrazením zloženia a vzťahov prvkov systému ukazuje, ako sú fyzicky umiestnené na výpočtových zdrojoch počas vykonávania.

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

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

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 rozmiestnenia (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

Inklúzne 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.

Naliehavá správa 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 opisuje 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 sekvenčnom diagrame, ší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ú kladené na vzťahy 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 (interface) - abstraktná trieda, ktorá definuje množinu operácií, ktoré objekt ľubovoľnej triedy pridruženej k danému rozhraniu 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é triedne stereotypy:

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í v databáze tabuľka.

4.4.2.4.Kontrolné triedy

Kontrolné triedy sú zodpovedné za koordináciu činností 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 viaceré prípady 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ť iný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 uchovávajú 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útu.

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 či 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á operácia implementácie 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ý sa generuje na základe prípadu použitia, a ten na základe požiadaviek. Schopnosť sledovať celý tento reťazec vám umožňuje zabezpečiť, že každá požiadavka bude implementovaná v kóde a každý kúsok 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 súkromnej a chránenej triedy.

Ak chcete identifikovať transakcie, postupujte takto:

1. Preštudujte si 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 možnosť dozvedieť sa o atribútoch, operáciách a vzťahoch inej triedy. Inými slovami, aby jedna trieda poslala 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, spojenie 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í vykonaný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; napríklad, ak je potrebné odstrániť zákazníka, potom sa toto vymazanie musí rozšíriť na objednávky (a následne aj na riadky objednávok).