UML - úvod

UML = unified modeling language (tj. unifikovaný modelovací jazyk)

Unifikovaný : unifikuje Booch, OMT a Objectory modelovací jazyky

Modelovací : UML je jazyk pro specifikaci, visualizaci, konstrukci a dokumentaci artefaktů SW systémů.

UML je však využitelný i pro business modelování i pro modelování ne-SW systémů. V UML lze modelovat jakýkoliv typ aplikace běžící na jakémkoliv typu a kombinaci HW, OS, programovacím jazyku a sítě. Lze modelovat distribuované aplikace. Pro UML je nejpřirozenější modelování pro OO jazyky a prostředí (jako jsou např. C++, Java, C#), ale lze modelovat i pro neobjektové jazyky (např. Fortran, VB, COBOL). UML profiles nám pomůže v modelování transakčních, real-time a fault-tolerant systémů.

Language (jazyk) :UML není programovací jazyk, ale je to jazyk, neboť má : syntaxi (grafickou), tj. pravidla, dle kterých jsou elementy jazyka sestavovány do

výrazů sémantiku, tj. pravidla, dle kterých je syntaktickým výrazům přiřazen význam

UML samo v sobě obashuje mechanismy pro jeho rozšíření (dle potřeb konkrétního projektu nebo konkrétního vývojáře)Další vlastnosti UML :

otevřený standard podporuje celý vývojový cyklus podporuje různě aplikační oblasti založeno na zkušnostech potřebách komunity uživatelů podporováno celou řadou nástrojů přispěvatelé : Booch (Booch metoda), Rumbaugh (OMT), Jacobson (OOSE), Shlaer-

Mellor (object lifecyles), Odell (clasification), Wirfs-Brock (Responsibilities), Embley (Singleton classes and high level view), HP Fusion (operation descriptions and message numbering), Gamma a kolektiv (frameworks and patterns), Harel (statecharts), Meyer (before and after conditions)

Trocha historie :

1966 první objektově orientovaný jazyk Simula (O.-J. Dahl, K. Nygaard) 1967 Simula67 : třídy, dědičnost, polymorfizmus 70. léta první čistě objektový programovací jazyk Smalltalk : pojem objekt (Xerox) 80. léta éra smíšených jazyků Turbo Pascal, C++ : umožňovaly programovat objektově, ale tento přístup nevyžadovaly přelom 80. a 90. let řada metod pro OOA a OOD + CASE na nich založené :

CRC karty : class-responsibility-collaboration (z prostředí Smalltalk, Xerox) Booch, kniha : Object-Oriented Analysis and Design with Applications, 2nd edition,

Addison-Wesley, 1994 (Grady Booch, Rational) OMT, kniha : Object-Oriented Modeling and Design, Prentice Hall, 1991 (J. Rumbaugh

(General Electric) a další) případ užití (OOSE), kniha : Object-Oriented Softvare Enginering : A Use Case Driven

Approach, Addison-Wesley, 1992 (I. Jacobson a další)

1994 J. Rumbaugh se přidává k G. Boochovi a firmě Rational Software 1995 Unified Method verze 0.8 (G. Booch, J. Rumbaugh)

1995 I. Jacobson (Objectory) se přidává k G. Boochovi a J. Rumbaughovi (pokud se někde dočtete o The Three Amigos či Los Tres Buddies, tak vězte, že je to přezdívka tria Booch+Rumbaugh, Jacobson :-) 1996 UML 0.9, 0.91 do prací na UML se zapojují např.: Digital Equiment, HP, i-Logix, IBM, MCI, Microsoft, Oracle, TI, Unisys 1997 rational : 1.0, 1.1 OMG "adoptovalo" UML UML 1.0 (OMG) = UML 1.1 : standard, většinou nazývaný 1.1 1998 UML 1.2 : interní verze, nepodstatné úpravy 1999 UML 1.3 : změny v use cases (namísto <<uses>> a <<extends>> je zavedeno <<include>>, <<extend>> a generalizace) a activity diagramech

2001 Model tříd

Zpracoval Tomáš Pajonk pod vedením Doc. RNDr. Pavla Drbala, CSc.

Obsah

o Jednoduchý třídní diagram Třída Atribut

o Typ atributu o Viditelnost o Implicitní hodnota o Třídní atribut o Výčtový typ o Syntaxe atributu

Operace o Celotřídní operace o Signatury operací o Syntaxe operace o Základní hodnoty parametrů

Vztahy v   objektovém modelu Asociace

o Objektový diagram o Rekurzivní asociace o Role v asociaci o Kvalifikovaná asociace o Vylučovací asociace o Seřazená asociace o Asociační třída

o Trojná asociace

Agregace o Sdílená agregace o Kompoziční agregace

Generalizace (dědičnost) o Normální generalizace o Abstraktní třída o Polymorfismus o Jiné typy generalizací

Závislost Zjemnění Pravidla (constrains)

o Odvozená asociace o Omezená asociace o Omezený a odvozený atribut o Syntaxe pravidel

Interface Balíčky

o Generalizace o Importování o Viditelnost balíčků o Interface

Vzory

Kvalita modelu

Jednoduchý třídní diagram

Jednoduchý model pojišťovací společnosti. Jedna pojišťovací společnost má mnoho (0 až mnoho) pojišťovacích smluv. Pojištěnec má mnoho (0 až mnoho) pojišťovacích smluv.

Pojišťovací smlouva přiřazena k jedné poj. společnosti. Jedna smlouva je také přiřazena (má vztah) k mnoha (jednomu až mnoha) zákazníkům. Entity použité v modelu jsou třídy.

Příklady tříd v různých oborech lidské činnosti

Systémový Software Podnik Technický systém

Soubor Zákazník Senzor

Spustitelný soubor Smlouva Displej

Ikona Faktura Magnetická karta

Okno Dluh Stroj

Rolovací menu Aktivum Spínač

Databáze SBU Kontrolní stanoviště

Třída

Jméno třídy je tučně, jména atributů začínají malým písmenem

Atribut

Typ atributu

Typ atributu je od atributu oddělen dvojtečkou a začíná velkým písmenem.

Viditelnost

Viditelnost určuje zda je atribut viditelný i z jiné třídy než ve které je definován. Viditelnost je důležitá zejména z hlediska ochrany dat a integrity systému.

“public” atribut. Značíme jej “+”. Je viditelný a přístupný ze všech tříd.

“private” atribut . Značíme jej “-”. Je viditelný a přístupný pouze v rámci třídy.

V UML je povolen ještě jeden typ viditelnosti: “protected”, ten značíme “#”. Více v kapitole o generalizaci. Dále také viditelnost “implementation”. Ta nemá zvláštní symbol a více o ní u Balíčků.

Implicitní hodnota

Česky "implicitni hodnota, anglicky "default value". Proměnná nabývá této hodnoty automaticky při její inicializaci. Později může být samozřejmě měněna.

Třídní proměnná

Třídní proměnná nabývá stejné hodnoty pro všechny instance třídy. Třídní proměnná se značí podtržením (v C++ proměnná typu “static”).

Výčtový typ

Proměnná výčtového typu může nabývat pouze vypsaných hodnot. Hodnoty typu se uvádějí ve složených závorkách.

Syntaxe atributu

Operace

Viditelnost operací funguje stejně jako u atributů. Třída "Auto" má atributy a operace. Operace “jeď” má dva parametry: rychlost a směr. Operace "zjistiData" má výsledek typu AutoData.

Celotřídní operace

Třídní operace se vztahuje k třídě jako takové – lze ji volat bez existence jediné instance třídy. (V případě, že by k třídě postavička neexistovala žádná její instance nemohli bychom zavolat operaci "kresli" ale operace "zjistiPočet" by vrátila hodnotu 0.)

Třídní operace se značí podtržením stejně jako třídní proměnná (v C++ to je metoda typu “static”).

Signatury operací

Každá operace je uskutečňována voláním své signatury – z tohoto důvodu musí mít jedinečnou signaturu danou - návratovým typem, jménem a parametry. Je tedy možné, aby existovaly dvě různé operace se stejným jménem, ale rozdílným návratovým typem a stejnými parametry. (V C++ nepatří návratový typ do signatury.)

Ne všechny operace musí mít návratový typ nebo parametry.

Seznam parametrů je čárkami oddělený výčet parametrů zapsaných takto - Jméno : Typ Hodnoty = Základní hodnota

Syntaxe operace

Základní hodnoty parametrů

Poslední řádek na obrázku výše není dobře. Uvnitř závorek nemají být parametry. Na řádku má být:

postavička.změnVelikost () => procX=25, procY=25

Vztahy v objektovém modelu

Třídní diagramy jsou složeny z tříd a jejich vzájemných vztahů.

V UML jsou čtyři druhy vztahů:

asociace – popisuje to, že existuje spojení mezi jednotlivými objekty tříd generalizace – vztah mezi obecnějším a specifičtějším elementem.

Specifičtější element může obsahovat jenom přidané informace. (nesmí být oproti obecnějšímu jakkoli jinak upraven)

závislost – vztah mezi závislým a nezávislým elementem

zjemnění – vztah mezi dvěmi stejnými popisy věcí na různém úrovni abstrakce

Asociace

Asociace je spojení mezi třídami, oproti tomu sémantická konekce (link) je spojení mezi objekty (instancemi tříd) zúčastněných v asociaci. Asociace je většinou obousměrná. Objekty různých tříd se "znají", "vědí o sobě", "jsou propojeny", "pro každý objekt z třídy A existuje objekt z třídy B". Obousměrná asociace se značí čárou, jednosměrná se značí šipkou.Asociace má jméno (a zvláštní šipku, v jakém pořadí se má číst jméno asociace a jména asociací spojených tříd).Na každém konci asociace je "kvantifikace" – vyjádření, pro kolik objektů této třídy vztah "asociace" platí.

Slovní popis modelu:Pojišťovací společnost má pojišťovací kontrakty, které se vztahují k jednomu či více zákazníkům. Zákazník má pojišťovací kontrakty (žádný a více), každý se vztahuje k jedné pojišťovací společnosti. Pojišťovací kontrakt je mezi pojišťovací společností a jedním nebo více zákazníky. Pojišťovací kontrakt se vztahuje k společnosti i k zákazníkovi.Pojišťovací kontrakt je vyjádřen v (jedné nebo žádné) pojišťovací smlouvě (sepsaný kontrakt o pojištění).Pojišťovací smlouva se vztahuje k jednomu pojišťovacímu kontraktu. Může se zdát podivné, že existuje pojišťovací kontrakt a pojišťovací smlouva, ale toto odpovídá realitě, kterou má model zobrazovat. Může nastat situace že je uzavřen kontrakt (ústně) a samotná smlouva ještě nedošla poštou či nebyla doručena.Objektový diagram

Objekty jsou instance tříd. Proto je značíme podobně jako třídy, pouze s několika drobnými změnami.Za jménem objektu je dvojtečkou oddělena vlastní třída objektu. Celý výraz je podtržený. Objekt nemusí být pojmenován – v tomto případě podtrhneme pouze jméno třídy a před ní uděláme dvojtečku.Třídy jsou spojeny asociacemi, objekty jsou spojeny linky. Objekt je instance třídy, link je instance asociace. Kvantifikace u asociace vypovídají, kolik linků z této asociace může vzniknout.Rekurzivní asociace

Asociace třídy na samu sebe je také možná. V tomto případě to reprezentuje vzájemné vztahy mezi objekty dané třídy.Na obrázku je vyjádření stejné skutečnosti za použití třídních (vlevo) a objektových (vpravo) diagramů. Je nutno brát na zřetel že třídní diagram je daleko obecnější – tento objektový diagram zobrazuje jen jeden konkrétní případ.Role v asociaci

Ke každé třídě v asociaci může být přiřazena role. Jméno role podrobněji vysvětluje postavení třídy v asociaci. Role není povinná a vztahuje se k asociaci. Třída může reprezentovat různé role současně. Horní část obrázku:Člověk hraje roli řidiče a auto hraje roli služebního auta v asociaci "řídí" mezi Autem a Člověkem. Role souvisí s kontextem ve kterém hrají.Auto může v jiném kontextu hrát jinou roli (ambulance, požární auto, přepravní prostředek).Dolní část obrázku:Manžel je sezdán s manželkou. Oba dva jsou lidé. Pokud není člověk sezdán nemůže hrát roli manžela nebo manželky.Kvalifikovaná asociace

Kvalifikovaná asociace používá u asociací typu "jeden-na-mnoho" nebo "mnoho-na-mnoho". Kvalifikátor specifikuje, jak je určitý objekt na straně "mnoho" rozpoznán. Kvalifikované asociace snižují kvantifikace vztahu z "jeden-na-mnoho" na "jeden-na-jeden". Kvalifikátor – zakresluje se jako menší obdélník na straně asociace, která kvalifikuje.Vylučovací asociace

V některých modelech nejsou všechny kombinace přípustné. UML toto řeší pomocí vylučovacích asociací. Ty vyjadřují, že objekt třídy se může účastnit nanejvýš jednoho vztahu současně.Seřazená asociace

Linky mezi objekty mohou být seřazeny. (jako například okna na obrazovce). Základní hodnota je neseřazené. Seřazené asociace se značí {seřazené} nebo například {seřazené podle velikosti}.Asociační třída

Třída může být součástí asociace – v tomto případě se jí říká asociační třída (má stejné vlastnosti jako normální třída – např. může mít vztah s jinými třídami apod.). Používá s k dokonalejšímu popisu asociace. Každý link asociace (link a asociace má podobný vztah jako objekt a třída) je spojen s objektem asociační třídy.Obrázek:Plat je atributem (vlastností) asociace, ani ne Osoby, ani ne Podniku.

Obrázek:Ovládání výtahu manipuluje se čtyřmi výtahy. Na každé lince mezi výtahem a ovládáním výtahu je fronta. Každá fronta ukládá požadavky přijaté od ovládání výtahu a od výtahu samotného (tlačítka uvnitř výtahu). Když si ovládání výtahu vybere výtah aby splnil požadavek pasažéra mimo výtah (stojícího na podlaží), nejprve si přečte každou frontu a vybere si výtah, který ji má nejkratší.Trojná asociace

Značíme ji velkým kosodélníkem. Můžeme používat role a kvantifikace, ale kvalifikátory a agregace ne. Asociační třída může být připojena nakreslením přerušované čáry k jednomu z vrcholů kosodélníku.Kosodélník se používá i k zápisu vícesdružených asociací (čtverných apod.).Agregace

Je zvláštním případem asociace. Je to vztah typu "část-celek". Agregace často popisuje různé úrovně abstrakce. Klíčová slova použitá k identifikování agregátů jsou "skládá se z", "obsahuje", "je částí".Obrázek:Les se skládá z mnoha stromů. Pokácením několika stromů zůstává les lesem. Tato vlastnost je důležitá pro normální agregaci. Části (stromy) skládají celek (les). Agregaci označujeme dutým (nevyplněným) kosodélníkemSdílená agregace

Je to taková agregace, ve které jednotlivé části mohou být zároveň součástmi jiných agregací. Agregace je sdílená pokud je kvantifikace na straně celku jiná než 1. Tým se skládá z členů týmu. Jedna osoba může být členem mnoha týmů. Osoby jsou tedy sdílené části. Remix se skládá ze seřazených skladeb. Stejná skladba může být součástí mnoha remixů.Kompoziční agregace

Kompoziční agregace vlastní své části. Části "žijí" uvnitř celku. kvantifikace na straně celku může být 0 nebo1. Na straně částí není omezená. Možností zobrazení kompoziční agregace je víc.U tohoto zobrazení mohou mít všechny agregace jméno obou svých rolí (na obou koncích vztahu agregace).

Kompoziční agregace - jiný způsob kresbyDruhý způsob zakreslení. Agregát má pouze jedno jméno role a to na straně části.

Další způsob zobrazeníTřídy částí jsou zobrazeny uvnitř třídy celku. Kvantifikace je zobrazena v pravém horním rohu.

Kompoziční agregace – příklady zápisuGeneralizace (dědičnost)"Generalizace je taxonomický vztah (taxonomie je věda zabývající se tříděním) mezi obecnějším a specifičtějším elementem. Specifičtější element je plně konzistentní s obecnějším a obsahuje další informace. Instance specifičtějšího objektu může být použita všude, kde je povolen obecnější element."Místo specializace se také používá pojem dědičnost. Generalizace se dá použít pouze u typů (tříd) nikoli u instancí (tzn. třída může zdědit vlastnosti jiné třídy, ale objekt nemůže dědit z jiného objektu) Někdy se generalizaci také říká "je-nějaké", protože auto je nějaký dopravní prostředek, pes je nějaký živočich, prodavač je nějaký zaměstnanec, atd. Normální generalizace

Podtřída "zdědí" od své nadtřídy všechny atributy,operace a asociace, viditelnost zůstane zachována. "Private" atributy a operace budou zděděny, ale nebudou přístupné v podtřídě; "public" a "protected" atributy a operace budou také zděděny, avšak budou přístupné v podtřídě. ("protected" značíme takto: "#"). Zde vidíme,že třída může být současně podtřídou i nadtřídou.Abstraktní třída (genaralisace)

Slouží k vyjádření společných vlastností tříd. Tyto třídy z ní dědí své společné vlastnosti.

Existence objektů takové třídy není povolena.

Má abstraktní operace (tyto nemají žádné implementační metody pouze signatury).

Třída, která má alespoň jednu abstraktní operaci musí být sama abstraktní.

Třída, která dědí z abstraktní třídy musí její abstraktní metody implementovat nebo se stát abstraktní třídou.

Poznámka: opakem abstraktní třídy je třída konkrétní (může mít objekty, musí mít všechny operace implementované)

Na tomto obrázku jde vidět, že každá podtřída si abstraktní operace může definovat jinak.Polymorfismus

Vysvětlení (obrázek):Osoba má asociaci "řídí" k třídě Vozidlo. Třída Vozidlo je abstraktní – což znamená, objekty, které osoba řídí jsou z konkrétních tříd Auto nebo Loď. Jakmile třída Osoba zavolá operaci jeď() výsledek bude záviset na použitém objektu (buď se rozjedou kola nebo se roztočí lodní šroub).Této situaci, kdy se objekt z podtřídy chová jako objekt z nadtřídy a jedna nebo více operací v nadtřídě jsou předefinovány v podtřídě, se říká polymorfismus.

Polymorfismus (příklad)Plátno se skládá z mnoha figur. Figury mohou být kružnice, přímky, mnohoúhelníky či skupiny. Skupina je složena z mnoha figur. Jakmile klient požádá plátno, aby se nakreslilo, plátno zavolá své asociované figury, aby se nakreslily. Každá figura je zodpovědná za svoje správné nakreslení. Skupina se nakreslí tím, že zavolá operace kresli - jak jsou specifikovány v jednotlivých figurách. Jiné typy generalizací

V modelu můžou být u generalizace přidány další informace, které blíže vysvětlují její použití, í určují omezení či upravují pravidla. V UML jsou čtyři předdefinované typy generalizací. Přesahující generalizace. Umožňuje dědění z více tříd (nadtříd, předků) najednou. (pozn. ne všechny programovací jazyky toto umožňují). Jejím opakem je rozpojená generalizace, ve které můžou třídy dědit pouze z jedné třídy. Rozpojená generalizace je v UML brána jako základní a nemá v modelu grafické označení - označuje se slovem "přesahující" ve složených závorkách a přerušovanou čarou

Dalším typem generalizace definované v UML je hotová generalizace. Třídy pod přerušovanou čárou s popiskou {hotová}se nemohou dále rozvíjet (specifikovat). Opakem je nehotová generalizace – ta je brána jako základní a není třeba v UML modelech nějak označovat. Závislost

Závislost (vztah) je sémantické spojení mezi dvěma elementy modelu, jedním nezávislým a druhým na něj závislým. Změna v nezávislém elementu ovlivní závislý element. Příklad: jedna třída bere objekt druhé třídy jako parametr, jedna třída má přístup ke globálnímu objektu druhé třídy, jedna třída volá celotřídní operaci druhé třídy (v C++ metoda typu "static").Ve všech těchto příkladech existuje závislost jedné třídy na druhé i přesto, že neexistuje explicitně vyjádřená asociace. Opět platí, že změna v nezávislé třídě ovlivní třídu závislou. Zjemnění

Je to vztah mezi dvěma stejnými popisy věcí na různém úrovni abstrakce. Může existovat mezi typem a třídou, která jej realizuje, v tomto případě se mu říká realizace. Jiný typ zjemnění funguje mezi osnovou a celým textem. Zjemnění může být použito na modelování různých implementací stejné věci (jednoduchá implementace a jiná komplexnější, ale také efektivnější implementace).Zjemnění se používá při koordinaci v modelování. U velkých projektů všechny modely musí také být navzájem zkoordinované. Zjemnění zde funguje takto

Ukazuje, jak jsou modely na různých úrovních abstrakce provázány. Ukazuje, jaké jsou vztahy mezi modely na různých úrovních vývoje.

Ulehčuje sledování jednotlivých věcí v modelu.

Pravidla (constrains)K doplnění a zpřesnění modelů se v jazyce UML používají dva druhy pravidel – omezení a odvození. Příkladem omezení je vylučovací a seřazená asociace nebo rozpojená a hotová generalizace.

Odvození vysvětluje, jak mohou být věci odvozeny (např. věk osoby = dnešní datum – datum narození osoby). Pravidla mohou být připojena k jakémukoliv modelovému elementu, ale jsou zvlášť důležitá u atributů, asociací, dědičnosti, rolí a v ynamických modelech také u časového omezení.Všechna pravidla jsou zapsána ve složených závorkách, takto: {pravidlo} nebo se připojují k modelovým elementům jako poznámka. Generalizace má pouze omezení – žádná odvození. Omezení pro generalizaci jsou hotová, nehotová, rozpojená a přesahující.Role mohou mít omezeny kombinace, kterých se objekt může účastnit (např. osoba si nemůže sama schvalovat nákupy).Odvozená asociace

Asociace můžou být omezené nebo odvozené. Pokud má půjčovna kontrakty s mnoha zákazníky pak odvozená asociace může být, že někteří zákazníci jsou důležitější VIP zákazníci. Odvozenou (derivovanou) asociaci značíme lomítkem před jménem asociace.Omezená asociace

Může být použita v případě, že jedna asociace je podmnožinou druhé asociace.Omezený a odvozený atribut

Syntaxe pravidelV UML existuje jednoduchá syntaxe pro pravidla:

množina objektů '.' attribut výsledkem je množina hodnot atributů množina objektů'.' role výsledkem je množina objektů na které role

"ukazuje" - role je na cílové straně asociace

množina objektů'.' '~' role výsledkem je množina objektů které na množinu ukazují– role je na zdrojové straně asociace

množina objektů '[' booleovský výraz']' výsledkem je podmnožina objektů pro něž platí booleovský výraz

množina '.' '[' hodnota kvalifikátoru ']' výsledkem je podmnožina objektů vybraných kvalifikátorem

Pro zápis těchto pravidel existuje speciální jazyk OCL (Object Constrain Language).Interface

Interface se znázorňuje jako malý kruh se jménem. Je to vlastně asociace s kvantifikací 1 na 1. Používání interface je vztah závislosti (ale v tomto případě pouze na operacích specifického interface, nikoliv na hodnotách třídy, která interface implementuje).

Závislá třída může volat operace zveřejněné v interface, které nejsou přímo popsány v diagramu. Popíšou se tedy mimo diagram podobně jako třídy.Interface stejně jako třídy mohou využívat generalizace.Balíčky

"Packages" – balíčky – subsystémyDle definice UML je balíček : "Obecný mechanismus pro organizování elementů do sémanticky příbuzných skupin.".Balíčky samotné mají význam v průběhu modelování a nemusí být nutně přeloženy do spustitelných systémů.Balíček vlastní své elementy a jeden element nemůže být součástí více balíčků.Balíčky mohou importovat modelové elementy z jiných balíčků. V tomto případě balíček pouze ukazuje ze kterého balíčku ten element pochází.Mezi balíčky mohou existovat obvyklé vztahy kromě asociace tedy: generalizace, závislost a zjemnění.Balíček je podobný agregaci. Pokud vlastní své komponenty, je podobný kompoziční agregaci. Pokud jen ukazuje na komponenty, pak je podobný sdílené agregaci.

Příklad na obrázku:Subsystém E je závislý na subsystému B. C je závislé na B a D. B,C,E jsou uvnitř subsystému A. Všechny subsystémy jsou znázorněny jako balíčky.Generalizace

Subsystémy D a E jsou specializovány z zobecněného subsystémy C. B,C,D,E jsou v subsystému A. Subsystém C závisí na B (obvykle to znamená, že ze subsystému B importuje nějaké elementy).Importování

Balíček Z uvnitř balíčku W je importován do balíčku A. Balíček B je závislý na importovaném balíčku Z.Viditelnost balíčkůViditelnost u balíčků stejně jako u tříd ukazuje, jak ostatní balíčky můžou přistupovat k jeho obsahu. U balíčků rozlišujeme čtyři stupně viditelnosti:

"public" – je nastaven jako "default" a znamená, že ostatní elementy můžou vidět a používat obsah balíčku bez omezení

"private" – pouze balíček, který vlastní nebo importuje část tohoto balíčku může přistupovat k jeho obsahu

"protected" – stejně jako u "private" s tím, že balíčky specializované z tohoto balíčku mohou také přistupovat k jeho datům.

"implementation" – je podobná jako "private", ale modelové elementy, které jsou na balíčku závislé nemůžou používat elementy z balíčku označené "implementation".

Importování z balíčku se popisuje jako závislost (s označením <<importuje>>), což mj. znamená, že z balíčků, které mají celé označení "implementation" se už žádné jiné balíčky importovat nemůžou.

Interface

Interface se u balíčků značí stejně jako u tříd. Většinou jedna nebo více tříd z balíčku implementují toto interface. Vzory

Vzor je neúplně specifikovaná třída. Třída ze vzoru vznikne dosazením konkrétních dat do parametrů vzoru. Parametry mohou být třídy nebo primitivní typy (např. Integer, real, boolean). Příkladem parametrizované třídy je pole, kde konkrétní třídy mohou být pole aut, pole barev apod. Parametrizovaná třída má seznam parametrů (jméno a typ parametru oddělených čárkou). Kvalita modeluModelovací jazyk jako je UML nám dává syntaxi jak model nakreslit. Jaké jsou tedy charakteristiky dobrého modelu?

Zachytí to podstatné z daného problému. (jádro problému) Je snadný na prohlížení a pochopení.

Je jasné co je cílem modelu.

Snadno se udržuje a doplňuje.

Je konzistentní.

Zachovává souvislosti.

Jména modelových elementů musí být relevantní (obzvlášť to platí u tříd, asociací, rolí, atributů a operací). Neměla by obsahovat mnoho přípon a předpon.Je nutno si uvědomit, že dobrému modelu porozumí i vnější pozorovatel.

UML 1.4 2001-2005 ? práce na UML 2.0 (dosud neukončeno)

UML - skladba

Ne, zde není nic pro skladatele :-), jen něco o tom, z jakých kamenů se UML skládá. Tyto kameny jsou pouhopouhé tři :

předměty (things) , tj. elementy modelu definující : o strukturní abstrakce (structural things) : podstatná jména (modelu UML),

tj. elementy : třída (class), rozhraní (interface), spolupráce (collaboration), případ užití (use-case), aktivní třída (active class), komponenta (component), uzel (node)

o chování (behavioral things) : slovesa (modelu UML), tj.: interakce (vztahují se ke komunikaci mezi objekty - např. zprávy (messages), spoje (links)) a stavový stroj (specifikuje sekvenci stavů objektu pomocí stavů, přechodů, událostí a aktivit)

o seskupení (grouping things) : balíčky (packages) seskupující (dle potřeby) prvky modelu

o poznámky (anotational things) : poznámky s přidanými informacemi

relace (relationships) , tj. elementy modelu spojující spolu dva (či více) předmětů - strukturních abstrakcí (také mohou spojovat seskupení); jejich typy jsou :

o závislost (dependency) : znázornění vztahu, kdy změnou v jednom elementu je ovlivněn jiný (závislý) element

o asociace (association) : spojení definující vztah mezi elementy o zobecnění (generalization) : vztahy generalizace-specializace, tj. jeden

element je specializací jiného elementu o realizace (realization) : jeden element je realizací jiného elementu

diagramy : model je souhrn všech předmětů a relací, jejichž znázornění v jednom obrázku by bylo nepřehledné, mnohdy zcela nemožné; naproti tomu diagram je jeden průhled, okénko, kterým se díváme na model;diagramů je v UML několik typů, ale většinou máme v jednom projektu i vícero diagramů jenoho typu (ať už z důvodu velikosti modelu, nebo chceme v různých diagramech zobrazit pohled na systém z různých úhlů, či se v různých diagramech chceme zaměřit na různé aspekty modelovaného systému).Máme tedy devět diagramů ve dvou skupinách :

o statický model (zaměřený na systémovou strukturu) : diagram tříd diagram komponent diagram nasazení o dynamický model (zaměřený na chování systému) : diagram případu použití sekvenční diagram diagram spolupráce stavový diagram diagram aktivit objektový diagram

UML - mechanismy

UML má čtyři mechanismy, které se prolínají celým jazykem.Tyto mechanismy jsou :

specifikace : 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).

ozdoby (adornments) : 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.Proč je těchto ozdob u elementu zobrazeno někdy více a někdy méně :

o model vytváříme postupně : zpočátku máme málo informací, které postupně doplňujeme

o 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)

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

o 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.

o 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 rohraní

mechanismy rozšiřitelnosti : jakyk 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 :

o 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

o 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 : "<>". Stereotyp může mít rovněž přiřazen nový symbol - časté využití bývá např. v diagramu nasazení pro vytvořrní 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.

o 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}

Use case diagram - diagram případů užití

Zobrazuje chování systému (nebo jeho části) z hlediska uživatele.

Na obrázku je use case diagram jednoduchého systému půjčovny videokazet : ohraničení (boundary) udává hranice systému/susbsystému (zde videopůjčovna) účastník (aktor) reprezentuje kohokoliv (či cokoliv) mimo systém, kdo se systémem

komunikuje a interaguje (člověk, HW, čidlo, jiný systém, ...); jediné, co aktor může, je přijímat nebo předávat do systému informace

každý případ užití, typová činnost (use case) charakterizuje určité použití systému účastníkem; případ užití má jméno, může mít textovou specifikaci

vztahy, relace (relationships) : o asociace mezi prodavač a UC_01 půjčit vidokazetu : jde o komunikační

asociaci, vyjadřuje tok informace mezi vnějším prvkem a případem užití o mezi UC_01 půjčit vidokazetu a UC_05 najít zákazníka je závislost se

stereotypem <<include>> : UC_01 je zahrnuje do sebe UC_05 (zahrnovaný); toto nám umožňuje re-use : najít zákazníka v systému musíme jak tehdy, když si chce zákazník půjčit videokazetu, tak tehdy, když videokazetu vrací - <<include>> nám umožní nadefinovat hledání zákazníka (UC_05) jen jednou a opakovaně ho zahrnout do více případů užití (UC_01, UC_02 a UC_04)

o mezi UC_02 vrátit vidokazetu a UC_07 naúčtovat pokutu je závislost se stereotypem <<extend>> : bázový případ užití UC_02 je za určitých podmínek (byla překročena smluvní výpůjční doba) rozšířen o nové chování, tj. o rozšiřující případ uzžití UC_07 (systém pak zákazníkovi předepíše pokutu); UC_02 obsahuje zvláštní oddíl body rozšíření (extension points), které obsahují seznam všech bodů, kde může být chování UC_02 rozšířeno jiným případem užití - zde máme jediný bod rozšíření EP_1:pokuta, na který je odkazováno z extend relace : zápis (EP_1:pokuta) [vrátit < aktuální datum] znamená, že v bodu zošíření EP1:pokuta je spuštěno UC_07, ale jen tehdy, je-li splněna podmínka [vrátit

< aktuální datum] (tj. pokud je vracena kazeta, u které je datum kdy měla být vrácena starší než dnešní den - vrácení už mělo proběhnout v minulosti)

o mezi aktory manager a skladník je zavedena relace zobecnění účastníka (actor generalization) (viz vysvětlení vztahu generalizace - specializace výš v kapitolách pojednávajících o OO):

aktor skladník podědí od managera všechny relace k případům užití, tj. i když to není explicitně znázorněno, tak skladník může spouštět i use case UC_04

jinak řečeno : všude, kde je použit aktor manager, může být použit kterýkoliv z jeho potomků, tj. UC_04 může být spouštěno jak managerem, tak skladníkem i prodavačem

UC_03 může spouštět jen skladník, nemůže ho spouštět ani manager (manager není potomkem skladníka, ale jeho předkem) ani prodavač (není potomkem skladníka, ale je s ním ve stromu generalizací na stejné úrovni)

aktor manager je konkrétní aktor (je to tedy konkrétní role, která opravdu komunikuje se systémem - spouští use cases), ale mohl by být abstraktní (bylo by vyjádřeno kurzívou : manager) : pak by takováto role ve skutečnosti nikdy se systémem neinteragovala - sloužila by nám jen pro zavedení stromu dědičnosti

V diagramu je naznačeno, jak používají aktoři systém, ovšem jsou uvedeny jen názvy činností, my však potřebujeme specifikovat další podrobnosti - zde není opravdu jiná možnost, než naplnit do jednotlivých usecasů textové specifikace. V těchto specifikacích by mělo být zejména popsáno :

co systém dělá (ale ne jak to dělá) měly by být používány jen pojmy problémové domény jak a kdy činnost začíná a končí kdy má systém interakce s aktorem které údaje jsou měněny jaké kontroly vstupních údajů jsou prováděny základní, alternativní a chybové průběhy způsoby popisu nejsou v UML formalizovány: může to být strukturovaný/formátovaný

text (pre- a post-conditions), pseudokód, ...

Příklad popisu případu užití UC_02 vrátit kazetu :

vysvětlující komentáře budou psány takto

případ užití : vrátit kazetu

název případu užití

ID: UC_02

jednoznačný identifikátor

Účastníci : prodavač

seznam účastníků, kteří se podílejí na komunikaci

Vstupní podmínky 1. prodavač je zalogován do systému

zde jsou obsaženy všechny podmínky, které musí být splněny, aby mohl být use case spuštěn; neboli : všechny uvedené podmínky musí být vyhodnoceny jako pravdaPS.: takto jednoduché a obecné podmínky (zalogování do systému) se zde obvykle neuvádějí ....

Tok událostí 1. Systém spustí případ užití (UC_05 najít zákazníka)

zde je spuštěn zahrnutý případ užití pro nalezení konkrétního zákazníka (UC05) - ten vyzve uživatele k zadání čísla průkazky zákazníka, podle čísla průkazky ho vyhledá a vrátí jeho identifikaci zpět do klientského případu užití (tj. nic nezobrazí) : vlastní zobrazení zákazníka si zajišťuje každý klientský případ užití "po svém" (každý by mohl chtít zobrazit jinou sadu údajů zákazníka a jiným způsobem)

2. Systém zobrazí údaje vyhledaného zákazníka jako jméno, příjmení, adresu, telefon, vypůjčené kazety jako seznam záznamů : číslo kazety + název filmu + datum výpůjčky + vrátit (jako předpokládané datum vrácení)

3. Uživatel označí kazety, které zákazník vrací, a označení potvrdí (EP1:pokuta)

zde je spuštěn rozšiřující případ užití tehdy, když je splněna podmínka [vrátit < aktuální datum], tj. když kazeta měla být vrácena už v minulosti : pak se spustí EC_07 naúčtovat pokutu, které naúčtuje zákazníkovi pokutu - k danému zákazníkovi zapíše do systému datum vystavení pokuty a její výši a vytiskne doklad o zaplacení.

4. Systém od zákazníka odstraní všechny kazety, které předtím uživatel označil, a případ užití skončí

následné podmínky seznam vypůjčených kazet byl u zákazníka aktualizován

zde jsou uvedeny podmínky, které po úspěšném dokončení případu užití musí být pravdivé

alternativní tok 1. k bodu 2. hlavního toku : pokud v seznamu vypůjčených kazet není žádná kazeta,

systém tuto skutečnost oznámí a případ užití skončí

zde jsou uvedeny alternativy k hlavnímu toku, tj. průběhy nastávající jen zcela výjimečně a nestandardně

chybový tok 1. k bodu 1. hlavního toku : pokud zákazník není nalezen, systém tuto chybu vypíše,

upozorní obsluhu na to, že průkazka by měla být zničena a případ užití skončí

zde jsou uvedeny chybové větvě k hlavnímu toku, tj. průběhy, které by neměly vůbec nastat - pokud nastanou, je to považováno za chybu (např. nekonzistence dat v systému, nesoulad mezi reálným světem aevidovanými informacemi apod.) a tato situace musí být nějak vyřešena

Náměty na další samostudium

generalizace-specializace pro případy užití komunikační asociace mezi aktory k čemu všemu může být diagram případů užití vlastně použit ?