Webové a agentové technologie (Ukázka, strana 99)

Objektové metody se začaly tvořit již od poloviny sedmdesátých let, avšak až do poloviny let devadesátých neexistoval komplexní modelovací jazyk/metoda, která by pokryla celou problematiku.

Proto se v roce 1994 začalo ve firmě Rational přemýšlet o sjednocení a rozšíření stávajících metod.

Autoři metod Grandy Booch a Jim Rumbaugh, kteří byli zaměstnanci fy Rational, sloučily své metody Booch a OMT (Object Modeling Technique), a už za rok byla na světě verze 0.8 jazyka UML. Později se přidal i Ivar Jacobson, jehož firma Objectory se sloučila s Rational, se svojí metodou OOSE (Object-Oriented Software Engineering).

Sjednocování metod si dalo tyto cíle: ❚ Modelování systémů (nejen software) pomocí objektových pojmů. ❚ Spojení pojmových i výkonných částí. ❚ Vytvořit modelovací jazyk vhodný jak pro lidi, tak pro stroje.

Během roku 1996 se projevily snahy o standardizaci, vytvořilo se UML konsorcium, kde byly firmy jako: Digital Equipment Corp., HP, i-Logix, InteliCorp, IBM, ICON Computing, MCI Systemhouse, Oracle, Rational Software, TI a Unisys.

Jazyk UML je standardizován skupinou OMG (Object Management Group).

Jazyk UML je tedy neproprietální a otevřený všem – i v tom je jeho budoucnost. Spousta firem přijala UML jako svůj organizační standard.

UML v dnešní podobě je zamýšlen jako základ pro mnoho různých činností jak pro vizuální modelování, tak pro simulace či vývoj software.

Základní principy jazyka UML Principy UML lze nastínit několika body: ❚ Na každý složitý problém je vhodné se dívat z více úhlů pohledu. Jeden pohled nestačí. ❚ Každý model může býti vyjádřen s různou přesností. ❚ Nejlepší modely jsou pak spojeny s realitou.

Proto UML definuje následující typy diagramů, které umožňují různé úhly pohledu. ❚ Diagram případů použití (use case diagram). ❚ Diagram tříd (class diagram). ❚ Diagramy chování: ■ stavový diagram (statechart diagram); ■ diagram aktivit (activity diagram); – sekvenční diagram (sequence diagram); – diagram spolupráce (collaboration diagram) ❚ Implementační diagramy: ■ diagram komponent (component diagram); ■ diagram rozmístění (deployment diagram).

Stručný postup modelování – analytická fáze Postup modelování jde shrnout do několika sekvenčně prováděných bodů. Samozřejmě, modelování je postup iterativní, proto se v praxi dělají v tomto postupu různé cykly či skoky.

Nejčastější postup tedy je (vysvětlení následují níže): 1. Pohled případů použití – herci 2. Pohled případů použití – případy použití 3. Pohled případů použití – vztahy herci – případy použití 4. Pohled případů použití – sekvenční diagramy či diagramy spolupráce 5. Logický pohled – třídy 6. Logický pohled – vztahy mezi třídami a jejich typy a násobnosti 7. Logický pohled – atributy a operace tříd 8. Logický pohled – roztřídění do balíků 9. Logický pohled – stavové diagramy

98 Webové a agentové technologie

Ukázka elektronické knihy, UID: KOS182803

10. Pohled případů použití – přiřazení objektů v sekvenčních diagramech třídám 11. Pohled případů použití – přiřazení operací v sekvenčních diagramech 12. Přehled komponent – založení adresářů a souborů 13. Přehled komponent – přiřazení tříd do souborů 14. Pohled rozmístěnosti – rozvržení práce pro jednotlivé počítače/procesory Existují čtyři pohledy na model: ❚ pohled případů použití; ❚ logický pohled; ❚ přehled komponent; ❚ pohled rozmístění.

Pohled případů použití Tento pohled (Use case view) je zaměřen na pochopitelnost a použitelnost systému. Ukazuje herce – aktéry a případy použití spolu a jejich vzájemné působení. Jsou používány diagramy případů použití, diagramy posloupností s diagramy spolupráce.

Herci – Aktéři Herec je něco nebo někdo vně systému, kdo komunikuje s případem použití systému. Soubor herců reprezentuje všechny, kteří si vyměňují informace se systémem.

Případy použití Diagramy případů použití Diagramy případů použití ukazují vztahy mezi herci a případy použití. Automaticky je vytvořen hlavní diagram „Main“. Druhy vzájemných vztahů jsou: Komunikační vztah „rozšiřuje“ – od případu použití A k B znamená, případ použití B může používat (část – to je specifikované) chování případu použití A, vztah „používá“ – od případu A k B znamená, že případ použití A také zahrnuje chování případu použití B.

Diagramy posloupností Diagramy případů použití ukazují pohled na systém. Funkce případu použití je zachycena tokem událostí. Na popis, jak jsou realizovány případy použití se používají scénáře. Scénáře jsou zachyceny v diagramech posloupností. Ke každému případu použití může tedy patřit diagram posloupnosti.

Diagramy posloupnosti obsahují herce, objekty, zprávy.

Diagramy spolupráce Scénář může být také reprezentován diagramem spolupráce. Také jsou s případem použití, jako diagramy posloupností. Diagramy spolupráce obsahují herce, objekty, spojení, zprávy a volitelně i tok dat.

Balíky v pohledu případů použití Balík je všeobecný mechanismus, jak organizovat objekty do skupin. V pohledu případů použití může balík obsahovat: ❚ další balíky, herce, případy použití, diagramy posloupnosti, diagramy spolupráce.

Logický pohled Logický pohled se věnuje funkčním požadavkům na systém. Jsou zde třídy a jejich statické vztahy.

Také popisuje dynamickou povahu tříd. Jsou zde diagramy tříd a diagramy stavových přechodů.

Základní vlastnosti, komunikace, metodologie návrhu, Servisně orientovaná architektura – SOA Multiagentních systémů 99

Ukázka elektronické knihy, UID: KOS182803

Třídy Třída je soubor objektů s podobnou strukturou, chováním a vztahy. Je reprezentována obdélníkem rozděleným vodorovnými linkami: horní část – obsahuje jméno třídy a obecné vlastnosti, střední část – udržuje strukturu třídy, dolní část – udržuje chování třídy.

U každé třídy je vhodné psát popis do dokumentačního okna. Ten by měl popisovat, proč třída existuje a neměl by se zabývat strukturou třídy.

Stereotypy tříd Nové typy tříd mohou být vytvořeny pomocí stereotypů. Základní stereotypy pro třídy jsou: hranice (boundary), entita (entity), řízení (control), výjimka (exception), pomůcka (utility).

Balíky v logickém pohledu Balík je všeobecný mechanismus, jak organizovat objekty do skupin. Umístění tříd do balíků umožňuje zorganizovat model. Do balíku se zpočátku umisťují třídy, které logicky patří do jedné skupiny.

Jak pokračuje analýza a návrh, struktura balíku se může měnit, aby bylo možno zahrnout znovupoužití či jiné změny struktury.

V logickém pohledu může balík obsahovat: další balíky, třídy, diagramy tříd.

Diagramy tříd Diagramy tříd slouží k vytváření grafického pohledu na třídy, popř. i balíky. Do každého diagramu tříd lze umístit jakoukoli třídu z jakéhokoli balíku, pomocí přepínače.

Struktura tříd Struktura třídy je reprezentována sadou atributů – vlastností. Mohou být vytvořeny buď přes specifikaci či v diagramu tříd.

Chování tříd Chování třídy je prezentováno sadou operací – tedy služeb, které můžeme od objektu požadovat, aby vykazoval dané chování.

Operace a diagramy interakcí Zprávy v diagramech posloupností a diagramech spolupráce mohou být přiřazeny operacím. Objekt, který zprávu přijímá, musí být přiřazený třídě dříve, než může být vytvořena operace pro zprávu.

Spojení typu asociace Třídy v modelu mohou být spojeny typem asociace, což je vztah mezi dvěma třídami, který se určuje sadou spojení mezi objekty daných tříd. Asociace je kreslena jako jednoduchá linka spojující dvě třídy. Asociace může být pojmenována jménem nebo se může použít jmen rolí (role names) u každé třídy zvlášť. Asociace také obsahuje ukazatel násobnosti na obou stranách.

Spojení typu agregace Třídy v modelu mohou být spojeny typem agregace, což je silnější vztah, než asociace. Agregace se kreslí linkou s diamantem u třídy, která hraje roli celku. Agregace se většinou nijak nepojmenovává, protože už její význam je „má“ či „obsahuje“. I u agregace je ukazatel násobnosti.

Určení směru u asociace a agregace Asociace a agregace jsou obousměrné vztahy. Mohou být změněny na jednosměrné.

Spojení typu závislost Třídy také často závisí vztahem závislost, což bývá, když jedna třída (klient) závisí na některé službě druhé třídy (dodavatele). Tento vztah nastává tehdy, když:

100 Webové a agentové technologie

Ukázka elektronické knihy, UID: KOS182803