UML (Unified modeling language) je grafický modelovací jazyk pro vytváření visuálních (grafických) modelů. UML je jednotný jazyk (grafický) pro specifikaci, vizualizaci, konstrukci a dokumentaci při OO analýze a návrhu (OOAaD) a pro modelování organizace (business modelling). UML není modelovací metodika – neříká nám nic o tom jak navrhovat SW systémy. Dává nám pouze grafickou syntaxi, pomocí které můžeme vyjadřovat modely. UML je otevřený, standardizovaný, průmyslově užívaný jazyk, snažící se vycházet z principů správného návrhu sw díla (best practices). Byl navržen tak aby byl snadno implementován CASE nástroji.

• do 1994 – nesjednocené metody objektového návrhu, existovalo několik soupeřících grafických modelovacích jazyků a metodik, mezi kterými vynikaly Boochova metoda (autor G. Booch) a Object modeling technique (OMT, autor J. Rumbaugh)
• 1994 – Booch a Rumbaugh přicházejí do Rational Software, aby zde pracovali ma sjednocení jejich metodik – UML, později se k nim připojuje Ivar Jacobson s metodologií OOSE
• 1996 – navržen konsorciem OMG (Object management group)
• 1997 – OMG schvaluje UML jako první otevřený OO modelovací jazyk
• 2005 – schválení vyraznějších změn v revizi UML 2.0

• Superstructure – definuje zápis a sématiku diagramů a jejich modelovacích elementů
• Infrastructure – definuje metamodel na němž je postavena část 1.
• Object constrain language (OCL) - jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech.
• Diagram interchange - popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji.

Každý element může (či měl by ?) být specifikován textem, který popisuje sémantiku tohoto elementu. Tato specifikace upřesňuje, blíže popisuje, udává smysl modelovaného elementu. Popisuje business pravidla elementů (tudíž má největší význam u elementů popisujících problémovou doménu).

Další informace známé o elementu modelu. Každý element může být vyjádřen jednoduchým tvarem, ale je možno k němu přidávat i další informace - ozdoby (např. seznam metod, seznam atributů, název objektu, stereotyp,..).

Proč je těchto ozdob u elementu zobrazeno někdy více a někdy méně:

• model vytváříme postupně : zpočátku máme málo informací, které postupně doplňujeme
• tvorbou určitého diagramu sledujeme určité cíle - nechceme v něm zobrazit ty podrobnosti, které jsou v tomto nepodstatné z hlediska toho, co právě chceme zdůraznit (jedno z prvořadých hledisek při tvorbě diagramu je totiž snadná čitelnost)

Udávají, jak je možno rozdělovat (skupinovat) jednotlivé elementy; první způsob dělení :

• klasifikátor a instance : pro dva elementy UML jsme si toto rozdělení již probrali - objekt je instance, kdežto třída je klasifikátor. Podobný vztah klasifikátor-instance lze nalézt pro další elementy UML. Každý elemement je buď klasifikátor nebo instance, a toto rozlišení je velmi důležité. Osvojením tohoto dělení si usnadníte komunikace mezi členy týmu (stačí říct : “…. klasifikátor elementu xxxx …., …. instance elementu yyyyy …..“ a bez dalšího vysvětlování je jasné, o co jde), můžeme se s tímto setkat i v CASE nástrojích a v literatuře.
• rozhraní a implementace : zalistujme výše v tomto kurzu do kapitoly popisující objekt - mluvili jsme o protokolu zpráv, což je rozhraní objektu. Implementace pak jsou metody, které řeší, implementují, toto rozhraní. (Obecně však může být definované rozhraní pro každý klasifikátor).

Toto důrazné oddělení má dvojí praktický význam :

• k tomu, abychom použili (již hotový) objekt, nemusíme znát jeho implementaci - stačí nám znát jeho rozhraní; programátoři (i neobjektoví) vlastně tohoto využívají při volání knihovních funkcí : programátor v jazyce C nemusí znát, jak je vnitřně vyřešena funkce printf, ale zná její rozhraní, tedy ji může používat
• a z druhé strany : vnitřek objektu může být (v budoucnu) libovolně změněn - ale jen tak, aby jeho klienty (tj. ty, které využívají jeho služby) nemuselo být nutno revidovat - jinak řečeno : i po úpravách musí objekt správně implementovat dohodnuté rozhraní; tedy ten, kdo vytváří/mění vnitřek objektu, nemusí nic vědět o tom, jak a kým bude objekt použit - stačí, když bude správně implementovat rozhraní

fetch.php

Jazyk UML sám v sobě obsahuje připravené mechanismy umožňující rozšířit jazkyk tak, aby vyhovoval momentálním potřebám. Máme k dispozici tři mechanismy rozšiřitelnosti :

• omezení (constraints) : jde o text ve složených závorkách {}. Podmínka či pravidlo v tomto textu musí být vždy splněna
• stereotypy (stereotypes) : s jejich pomocí lze z existujího elementu vytvořit nový. Vytvoříme ho tak, že název stereotypu vložíme do dvojitých ostrých závorek : “«novy_stereotyp»“. Stereotyp může mít rovněž přiřazen nový symbol - časté využití bývá např. v diagramu nasazení pro vytvoření symbolů tiskáren, serverů, notebooků apod. Některé stereotypy jsou již součástí jazyka UML a ještě se s nimi v tomto kurzu setkáme.
• označené hodnoty (taggedd values) : umožňuje přidávat nové vlastnosti k elementům modelu. Zavedeme ji přidáním názvu s připojenou vlastní hodnotou ve složených závorkách, např. {autor=pavus, verze=0.1}
• profily : Profil UML definuje množinu stereotypů, značek a omezení, díky nimž lze jazyk UML přizpůsobit konkrétnímu účelu. (např. můžeme mít nějaký profil modelování aplikací pro platformu J2EE, jiný profil pro .NET, apod.)

• Strukturální – class, interface, collaboration, active class, component, node, (lze si je představit jako podst. jména UML modelů)
• Behaviorální – interakce, stavové stroje, use case
• Skupiny – balíček (package)

fetch.php

Zobrazuje statickou strukturu systému, popisuje typy objektů a statické vztahy mezi nimi.

Tři pohledy na systém při použití diagramu tříd

• Konceptuální – koncepty aplikační domény, bez vztahu k implementaci, jazykově nezávislá.
• Specifikační – pohled na program, specifikace rozhraní bez specifikace implementace.
• Implementační – je vidět implementace - hranice nejsou ostré, UML podporuje všechny tři pohledy

Tipy:

• nesnažit se použít veškerou dostupnou notaci
• přizpůsobit pohled etapě projektu:
  • analýza: konceptuální pohled
  • návrh: specifikační + implementační
• koncentrovat se na klíčové oblasti, raději méně aktuálních diagramů
• nezabřednout brzy do implementačních detailů

fetch.php

Návrhové relace

• Agregace
  • Volná vazba mezi objekty
  • Typ celek/součást (celek řídí chod relace, součást poskytuje služby)
  • Agregované objekty
    • mohou být sdílené
    • nezanikají se zánikem celku
  • Celek někdy existuje nezávisle na součástech, někdy je na nich závislý
  • Součást může být sdílena více celky

fetch.php

• Kompozice
  • Silnější forma agregace
  • Součásti nemohou existovat mimo celek
  • Součást patří právě jednomu celku
  • Celek odpovídá za použití svých součástí
  • Za předpokladu, že odpovědnost za součásti přejde na jiný objekt, může celek součásti uvolnit.
  • Je-li zničen celek, musí zničit své součásti (nebo přenést odpovědnost na jiný objekt)

fetch.php

Generalizace

• Jako zobecnění (generalizace) se označuje relace mezi obecnějším a přesněji definovaným prvkem.
• Na následujícím obrázku je třída Zvíře obecnější než třída Pes.

fetch.php

Dědičnost tříd

• Potomci (podtřídy) přebírají charakteristiku svých předchůdců
• Potomci dědí
  • Atributy
  • Operace
  • Relace
  • Omezení
• Potomci mohou ke zděděnému fondu přidat novou charakteristiku

Realizace

• Fakt, že třída implementuje (realizuje) nějaké rozhraní znázorňujeme čárkovanou čárou, která směřuje od třídy k rozhraní.
• Na následujícím obrázku třída Timestamp implementuje rozhraní TimeComparable.
• Rozhraní se používá k určení společných protokolů pro třídy, mezi nimiž by za normálních okolností neměly být dědičné vazby.

fetch.php

Popisuje jak jsou jednotlivé komponenty (části) systému propojeny. Komponenta je fyzická nahraditelná část systému, která obaluje implementaci a poskytuje realizaci množiny specifikovaných rozhraní.

Diagram komponent znázorňuje komponenty použité v systému, tj. logické komponenty (např. business k., procesní k.) či fyzické komponenty (např. EJB k., CORBA k., .NET k. atd.). Diagram komponent nám může pomoci zejména tam, kde používáme vývoj založený na komponentách a kde struktura systému je založena na komponetách.

Komponenta je modulární část systému, která zapouzdřuje svůj obsah (tj. zapouzdřuje stav a chování i více klasifikátorů) a jejíž projev je nahraditelný (tj. komponenty, poskytující ekvivalentní funkcionalitu založenou na kompatibilitě jejich interfejsů, mohou být libovolně zaměňovány, a to buď už v čase tvorby designu, nebo až za běhu cílového systému). Komponenta je specializací strukturované třídy. Protože je komponenta specializací třídy, může mít své atributy a operace a může mít asociace a generalizace-specializace (více viz diagram tříd (class diagram)).

fetch.php

Na prvním obrázku je diagram komponent s jednou strukturovanou komponentou Obchod a jejími třemi vnitřními komponentami :Objednavka, :Produkt a :Zakaznik.

fetch.php

V druhém obrázku je další diagram komponent, kde vidíme komponentu Objednavka a její vnitřní klasifikátory HlavickaObjednavky a PolozkaObjednavky, které realizují chování této komponenty.

V diagramech můžeme vidět :

• komponenta je znázorněna jako symbol klasifikátoru (pravoúhelník), s klíčovým slovem «component». Volitelně má v pravém horním rohu zobrazenu speciální malou ikonu komponenty. ( PS.: ve verzi UML 1.x vypadal symbol komponenty právě tak, jako ona speciální ikona, přitom starý symbol komponenty je přípustný i ve verzi UML 2.0).

Druhy komponent:

• basic component : pro ni platí vše, co je v této kapitole o komponentě řečeno (pokud není výslovně uvedeno, že se informace týká jen komponenty typu packaging)
• packaging component : rozšiřuje komponentu typu basic o možnosti skupinování; takovéto komponenty se týkají aspekty spojené s problematikou namespaces (komponenta může dědit a importovat své členy, jako např. packages, use cases, komponenty, artefakty, třídy, ….)

Rozhraní:

• poskytovaný (provided) interface je implementován přímo danou komponentou (popř. klasifikátorem, který realizuje chování komponenty), nebo je to vlastně typ poskytovaného portu (zde poskytovaný interface ZadaniObjednavky je připojen na nepojmenovaný port).
• požadovaný (required) interface je typem požadovaného portu, nebo je určený závislostí usage přímo z dané komponenty (popř. klasifikátoru, který realizuje chování komponenty), (zde požadovný interface Ucet komponenty Obchod (1. diagram) je připojen na nepojmenovaný port, požadovaný interface ObjednatelnaPolozkaUcet komponenty Objednavka (2. diagram) je připojen pomocí závislosti na interní třídu PlozkaObjednavky).
• port nám umožňuje organizování interfejsů do skupin : můžeme vytvářet pojmenované sady interfejsů
• delegační konektor (delegation connector) propojuje externí rozhraní komponenty (tak, jak je specifikováno portem) s vnitřní částí komponenty (tj. s vnitřní komponentou či třídou anebo s portem vnitřní komponenty).
• montážní konektor (assembly connector) spojuje požadovaný a poskytovaný itrefejs; strana, která poskytuje interfejs, musí být schopna poskytnout minimálně všechny služby, které může požadovat strana s požadovaným interfejsem

příklady komponent:

• zdrojový soubor
• ActiveX prvek
• Enterprise JavaBean objekt
• Java servlet
• JSP stránka

Objektový diagram zobrazuje objekty a jejich spoje (links) v jednom okamžiku, tj. je to snapshot běžícího systému (či jeho části). Objekty jsou instancemi tříd. Objekty jsou propojeny linky. Objektový diagram vypadá podobně, jako diagram tříd. Název konkrétního objektu se zapisuje před název třídy a odděluje se dvojtečkou.

fetch.php

fetch.php Na obrázku je příklad objektového diagramu odvozeného z class diagramu naší půjčovny videokazet. :

• objekt je znázorněn podobně jako třída - obdélníkem, ale název objektu je vždy podtržený
• zápis c1:CKazeta značí objekt c1, který je instancí třídy CKazeta (obdobně je tomu s objekty c2 a c3)
• zápis :CRežisér značí tzv. anonymní objekt : nevíme, jak se objekt jmenuje, ale víme, ze které třídy byl objekt odvozen
• třetí možnost zápisu by byla c4, tj. objekt bez vyznačení třídy : nevíme, ze které třídy je objekt odvozen (nebo to autor věděl, ale chtěl znázornit, že objekt c4 mohl vzniknout z různých tříd)
• spojení (link) mezi objekty vzniklo jako instance asociace
• objekt :CRežisér je znázorněn v minimálním tvaru (jen jeho znázev), objekt c1:CKazeta je znázorněn s dalším * oddílem (kompartment) ukazujícím aktuální hodnoty atributů
• u objektu c1 je vyznačena role - tj. ve vztahu anonymního objektu :CRežisér versus c1:CKazeta hraje tato kazeta roli filmu (který byl režírován spojeným objektem - režisérem)

Use case diagram (UC diagram) zobrazuje chování systému (nebo jeho části) z hlediska uživatele. Vychází z funkčních požadavků na systém.

postup při modelování:

• najít hranice systému (za kterou funkčnost je systém zodpovědný a za kterou již není)
• najít aktéry
• najít případy užití – specifikace + scénáře

Aktér specifikuje roli, kterou si může vnější entita (osoba, HW zařízení, jiný informační systém) přisvojit. Akteři definují hranice systému Při identifikaci aktérů zjišťujeme:

• Kdo nebo co používá systém?
• V jakých rolích se přitom nachází?
• Kdo instaluje/nasazuje systém?
• Kdo systém udržuje?
• Které jiné systémy tento systém využívají?
• Spouští se nějaká událost v závislosti na čase? (např. zálohování apod.)

• Případ užití je nějaká činnost, kterou aktéři se systémem provádějí. Případy užití jsou vždy iniciovány aktérem.
• Při pojmenovávání UC používáme slovesnou vazbu (např. Zrušit objednávku, v AJ se pro pojmenovávání často užívá CamelCase - např. CancelOrder).

Identifikace případů užití:

• Které funkce budou jednotliví aktéři vyžadovat od systému?
• Ukládá nebo vrací systém nějaké informace? Pokud ano, který aktér tuto akci vyvolává.
• Co se stane pokud systém změní svůj stav (spušténý/vypnutý)?
• Existují nějaké vnější události, které působí na systém?
• Vytváří systém nějaké zprávy (reporty)?
• Komunikuje systém s nějakým vnějším systémem?

POZOR! Scénáře případů užití jsou nedílnou součástní modelu. Samotné diagramy (bez scénářů) nemají potřebnou vypovídací hodnotu.

Struktura scénáře:

• název (např. Půjčit knihu)
• identifikátor - jednoznačný (např. UC2.1)
• stručný popis (např. Označí vybranou knihu jako vypůjčenou a zadá příkaz k výdeji)
• seznam primárních aktérů (např. Zákazník)
• seznam sekundárních aktérů (např. Pokladní)
• Vstupní podmínky (např. Kniha je skladem)
• Hlavní scénář, popisuje jednotlivé interakce mezi systémem a aktérem
• Alternativní scénáře
• Výstupní podmínky (např. Kniha byla zapůjčena, byl odeslán příkaz k výdeji)

fetch.php

fetch.php

include

• vyčleňuje společné kroky několika případů užití do samostatného případu užití
• případu užití „Vrátit kazetu“ na prvním obrázku říkáme klientský
• případu užití „Najít zákazníka“ na prvním obrázku říkáme dodavatelský
• klientský případ užití je bez dodavatelského neúplný

extend

• umožňuje rozšířit případ užití o nové chování
• případu užití „Vrátit knihu“ na druhém obrázku říkáme bázový
• případu užití „Uložit pokutu“ na druhém obrázku říkáme rozšiřující
• bázový případ užití neví o rozšiřujícím; má pro něj jen tzv. místa rozšíření; je úplný i bez rozšiřujícícho
• rozšiřující bývá zpravidla bez neúplný (tzn. že nemůže být přímo inicializován aktérem, tzn. nemůže k němu vést asociace přímo od aktéra)

Diagram aktivit se používá pro popis dynamických aspektů systému.

Jde o jakýsi flowchart - znázorňuje tok řízení z aktivity do aktivity. Používá se také k modelování obchodních (business) procesů a workflow.

Diagram aktivit se soustřeďuje spíše na proces výpočtu než na objekty účastnící se výpočtu (i když i objekty mohou být znázorněny jako prvek aktivity).

Diagramy stavů a diagramy aktivit jsou si podobné (oba ukazují sekvenci stavů, které nastávají v čase, a ukazují podmínky způsobující přechody mezi stavy). Rozdíl mezi těmito diagramy je však v tom, že d. stavů se soustřeďuje na stavy objektu (tj. objektu provádějícího výpočet či objektu, se kterým je výpočet prováděn), kdežto d. aktivit se zaměřuje na stav samotného výpočtu (stav procesu, algoritmu, ….), kde může být účastno i více objektů, a kde jsou znázorněny řídící a informační toky mezi prvky diagramu.

fetch.php Na obrázku je příklad jednoduchého diagramu aktivit:

• aktivita (activity) vyřizování objednávek je ta, která je zde modelována (pro znázornění, jak vlastně toto vyřizování objednávek probíhá)
• oddíly (partitions, swimlanes): plavební dráhy - rozdělení diagramů na více částí pro znázornění odpovědností za různé části aktivity; zde jde o rozdělění aktivity na dvě různé firmy
• akce (action) : nejprimitivnější, nejnižší prvek výpočtu. Nemůže být dále dekomponován.
• hrana, tok (edge, flow) zobrazuje přechod z jedné aktivity do další (v příkladu je přechod vždy automatický, dojde k němu po ukončení předcházející akce)
• objekt (object) může vstupovat do aktivit, může být jejich výsledkem
• počáteční, finální uzel aktivity (initial, activity final) : zvláštní uzly pro označení počátku a konce aktivity

Aktivity mohou být spouštěny akcemi a nebo jako součásti jiných chování, např. přechody v diagramu stavového stroje, metodou, případem použití, jinou aktivitou… Aktivita je zobrazena v diagramu aktivit.

Aktivita je specifikace chování - popisuje sekvenční a souběžné kroky výpočetní procedury. Aktivita je modelována jako graf uzlů aktivity (activity nodes) propojených řídícími a datovými toky (control flow, data flow). PS.: Uzel aktivity je něco naprosto jiného než uzel v deployment modelu ! Paradoxně na tuto zmatečnost je poukazováno přímo v UML reference manuálu.

Uzly aktivity jsou :

• vložené aktivity
• akce: modelují účinky na systém
• lokace dat
• řídící konstrukce (control construct)

Diagram obsahuje stavový stroj (state machine). Stavový stroj vyjadřuje stavy určitého objektu a přechody mezi těmito stavy.

fetch.php

Na obrázku je příklad jednoduchého diagramu stavového stroje :

• stav (state) : situace, kdy modelovaný objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost - např. ve stavu narozený splňuje objekt podmínku, že mu není dosud 18 roků a čeká, až dosáhne plnoletosti
• přechod (transition)
• spojení mezi dvěma stavy; objekt přejde z prvního stavu do druhého stavu (za splnění určitých podmínek)
• rozloučení ukazuje přechod do téhož stavu (něco význačného se stane, ale stav se nezmění)
• počáteční, finální stav: zvláštní pseudostavy pro počátek a konec automatu

Stavový stroj je graf stavů a přechodů (mezi těmito stavy), který popisuje reakce objektu (přesněji : reakce instance klasifikátoru) na obdržení události. Stavový stroj může být připojený ke klasifikátoru (např. use case, class), nebo ke collaboration či k metodě.

Element, ke kterému je připojen stavový stroj, se nazývá vlastník (owner) stavového stroje.

Celý stavový stroj je vlastně složený stav (composite state), který je rekurzivně dekomponován na substavy. Nejspodnější (listové) stavy již nemají substavy.

Stavový stroj může mít reference na jiný stavový stroj použitím stavového substroje (submachine state). Ve stavovém stroji může být v jeden okamžik aktivních více stavů.

Pro vysvětlování podrobností o stavech musíme vědět, co je to přechod:

přechod (transition) je relace ve stavovém stroji mezi dvěma stavy, kde objekt v prvním stavu přejde do druhého stavu tehdy, když nastane specifikovaná událost (event) a jsou splněny specifikované podmínky (guards), přičemž se provede specifikovaný efekt (effect - action nebo activity). Přechod je nepřerušitelný.

Říká se, že přechod je odpálen (transition is fire). Přechod může mít jeden nebo více zdrojových stavů a jeden nebo více cílových stavů.

Co je to stav

stav (state) : situace, kdy modelovaný objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost. - např. ve stavu narozený splňuje objekt podmínku, že mu není dosud 18 roků a čeká, až dosáhne plnoletosti. Stavy jsou obsaženy ve stavovém stroji, který popisuje jak se vyvíjí objekt v čase dle svých reakcí na události.

Přitom sekvenční d. a d. komunikací jsou téměř izomorfní - tj. dají se převádět z jednoho tvaru na druhý (často i automatizovaně) (to však platí jen pro jednoduché sekvenční diagramy, které nepoužívají struktorované mechanismy jako interaction use a combined fragment - vysvětleny níže v sekci další podrobnosti).

Použití sekvenčního diagramu bývá vhodnější v těch případech, kde jsou důležité časové souvislosti interakcí, ovšem nevidíme v něm zobrazené vztahy mezi objekty.

Objekty si mohou posílat zprávy. Sekvenční diagram zobrazuje jejich časovou posloupnost. fetch.php

Jedná se o jednoduchý sekvenční diagram. Časová osa je svislá (čas běží shora dolů), na vodorovné ose jsou rozmístěny objekty:

• lifeline (čára života) reprezentuje participanta v interakci:
  • Participant je většinou konkrétní objekt.
  • Lifeline také ukazuje, kdy participant žije - v tomto diagramu všechny objekty existovaly už před posláním první zprávy, a dále existují po dokončení sekvenčního diagramu (resp. nevíme, kdy který objekt zanikne nebo nás to v tuto chvíli nezajímá)
  • execution specification, focus of control (aktivita objektu) vyjádřená zdvojeným úsekem (obdélníkem) na lifeline : ukazuje periodu, kdy je který objekt aktivní, neboli kdy provádí nějakou činnost, nějak se chová, včetně „podřízeného“ chování dalších objektů (tj. u aktivního objektu vyznačuje celý jeho život, u pasivního objektu časový interval, kdy je prováděna operace objektu, včetně čekání na návrat ze zavolané operace; v programátorském světě je to analogické době, po kterou je určitá hodnota ve „stack“ - v zásobníku) by )
• zpráva:
  • v našem příkladě máme jen jednoduché obyčejné zprávy : u nich se zpráva zobrazuje plnou čárou a plnou šipkou a v našem příkladu je znázorněno např. ohledně zprávy zpravaA(x) : objekt obj1 posílá (tedy je to sender) zprávu zpravaA s jedním argumentem, který je je naplněn hodnotou atributu x, objektu obj2 (to je tedy receiver)
  • zobrazení návratové zprávy není povinné (vždy si ji lze „domyslet“), ale může přidat na přehlednosti: zobrazuje se šipkou s čárkovnou čárou
  • návratová zpráva může, ale nemusí vracet hodnotu : po poslání zpravaA(x) a po té, co obj2 dokončí svou činnost, tak vrátí zpět návratovou hodnotu 123, kterou si obj1 převezme do svého atributu y

V diagramu je znázorněna tato sekvence :

1. objekt obj1 je hned na počátku aktivován (má focus) a poslal zprávu zpravaA s parametrem x objektu obj2 : obj1 přeruší zpracování (ztratí focus a předá řízení obj2) a čeká, až obj2 odpoví na zpravaA(x)
2. obj2 získává focus a spustí vlastní metodu
3. v jistém bodě zpracování posílá obj2 zprávu zpravaB do obj3 - obj2 započne čekat na odpověď od obj3
4. obj3 získává focus (a spouští vlastní metodu)
5. obj3 dokončí své zpracování, pak vrátí peška (předá řízení zpět) do obj2
6. obj2 pokračuje v práci, a posílá další zrávu do obj3
7. až obj3 dokončí zpracování, tak vrátí řízení zpět do obj2
8. obj2 pokračuje v práci a až skončí, tak vrátí řízení do obj1, přitom ale vrátí návratový návratovou hodnotu 123
9. obj1 si převezme návratovou hodnotu do atributu y

Popis šipek:

fetch.php

Diagram komunikací je i není nový v UML 2.0 : totiž v UML 1.x se jmenoval collaboration diagram, což bylo matoucí (collaboration byly statické struktury, kdežto diagram zahrnoval zprávy).

D. komunikací a sekvenční d. jsou téměř izomorfní - tj. dají se převádět z jednoho tvaru na druhý (často i automatizovaně) (to však platí jen pro jednoduché sekvenční diagramy, které nepoužívají struktorované mechanismy jako interaction use a combined fragment). D. komunikací i sekvenční d. ukazují interakce, ale každý svým vlastním způsobem.

Použití diagramu komunikací bývá vhodnější v těch případech, kde chceme zdůraznit strukturální aspekty spolupráce, tj. ukázat hlavně kdo s kým komunikuje - jsou méně vhodné pro zdůraznění časových souvislostí interakcí.

Objekty si mohou posílat zprávy. Diagram komunikací ukazuje objekty (přesněji : části kompozitní struktury nebo role ve spolupráci(collaboration)) a spojení a zprávy, které si objekty posílají. Čas zde nevystupuje jako zvláštní dimenze, proto musí být sekvence zpráv a spouběžnost threadů určena pomocí čísel sekvencí :

fetch.php

Jedná se o diagram komunikací odvozený z našeho jednoduchého sekvenčního diagramu

• uzly v tomto diagramu reprezentují části strukturované třídy nebo role collaborations (dále pro zjednodušení je budeme nazývat jako objekty) a korespondují s lifeline v sekvenčním diagramu.
• komunikační cesty (paths) jsou vyjádřeny čárami (spojkami, connectors) mezi uzly. Čáry můžou být nazvány svým jménem a/nebo jménem výchozí asociace (existuje-li). Můžou být vyjádřeny multiplicity.
• zpráva:
  • zpráva je zobrazena jako malá pojmenovaná šipka umístěná blízko spojnic; v našem příkladě máme jen jednoduché obyčejné zprávy : zde je šipka plná a v příkladu je znázorněno např. ohledně zprávy zpravaA(x) : objekt obj1 posílá (tedy je to sender) zprávu zpravaA s jedním argumentem, který je je naplněn hodnotou atributu x, objektu obj2 (to je tedy receiver), ten po svém zpracování vrací hodnotu 123, kterou si obj1 převezme do atributu y
  • sekvenční výraz (umístěný před názvem zprávy) určuje pořadí, v jakém jsou zprávy posílány : pozor, není to jen prosté pořadové číslo, ale je v něm vyjádřeno i zanoření
  • návratováHodnota není povinná

V diagramu je znázorněna tato sekvence :

1. objekt obj1 je hned na počátku aktivován (má focus) a poslal zprávu zpravaA s parametrem x objektu obj2 : obj1 přeruší zpracování (ztratí focus a předá řízení obj2) a čeká, až obj2 odpoví na zpravaA
2. obj2 získává focus a spustí vlastní metodu
3. v jistém bodě zpracování posílá obj2 zprávu zpravaB do obj3 - obj2 započne čekat na odpověď od obj3
4. obj3 získává focus (a spouští vlastní metodu)
5. obj3 dokončí své zpracování, pak vrátí peška (předá řízení zpět) do obj2
6. obj2 pokračuje v práci, a posílá další zrávu do obj3
7. až obj3 dokončí zpracování, tak vrátí řízení zpět do obj2
8. obj2 pokračuje v práci a až skončí, tak vrátí řízení do obj1, přitom ale vrátí návratovou hodnotu 123
9. obj1 si převezme návratovou hodnotu do atributu y

D. komunikací vlastně obsahuje jen čtyři typy elementů : základní frame, lifeline, komunikační cesty (paths) a zprávy

Diagram přehledu interakcí definuje interakce pomocí varianty diagramu aktivit : tato varianta zahrnuje fragmenty sekvenčních diagramů spolu s konstrukty pro řízení toku.

fetch.php

Diagram přehledu interakcí obsahuje jako své uzly interakce (online vložené interakční diagramy) a interaction use (ad interaction use viz sekvenční diagram)

• frame (rám): význam a jmenovka jsou stejné, jako v sekvenčním diagramu. Ovšem v refrenčním manuálu k UML se jeho autoři (trio amigos) odchylují od specifikace UML (sami to přiznávají), a používají jmenovku intover namísto sd
• alternative combined fragment zde má obdobu v uzlu decision (rozhodnutí) a odpovídajícím uzlu merge (splynutí)
• paralel combined fragment zde má obdobu v uzlu fork (rozdvojení) a odpovídajícím uzlu join (spojení)
• větvení a spojování zde musí být (na rozdíl od d. aktivit) explicitně uvedeno