E-learningové materiály pro výuku jazyka UML

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY BAKALÁŘSKÁ PRÁCE E-learningové materiály pro výuku jazyka UML Vít Urban Brno, 2013

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně dne Vít Urban Vedoucí práce: Mgr. Dalibor Toth

3 Poděkování Tímto bych rád poděkoval vedoucímu práce Mgr. Daliboru Tothovi za spolupráci při tvorbě této bakalářské práce. Také bych rád poděkoval své rodině a nejbližším za podporu během studia.

4 Shrnutí Tato bakalářská práce se zabývá tvorbou e-learningových materiálů popisujících jazyk UML, které můžou sloužit jako podklad pro výuku předmětů zabývajících se touto tématikou. V teoretické části této práce jsou popsány vybrané UML diagramy. Výsledkem praktické části jsou video návody na tvorbu jednotlivých modelů

5 Klíčová slova UML, objektově orientované programování, Visual Paradigm, e-learning, analýza a návrh informačních systémů, diagram tříd, diagram případů užití.

6 Obsah 1. Úvod Jazyk UML a CASE nástroje Historie UML Struktura UML CASE nástroje Specifikace vzorového informačního systému Specifikace systému MuShop UML Diagramy Diagram případů užití (Use Case Diagram) Diagram aktivit (Activity Diagram) Diagram tříd (Class Diagram) Stavový diagram (State Machine Diagram) Sekvenční diagram (Sequence Diagram) Komunikační diagram (Communication diagram) Diagram balíků (Package diagram) Diagram nasazení (Deployment diagram) Použití materiálů pro výuku Využití materiálu v předmětech Fakulty informatiky Závěr Literatura

7 1. Úvod Koncem 60. let minulého století se staly softwarové produkty natolik složitými, že nebylo možné je psát bez kvalitní dokumentace. Díky této skutečnosti se objevilo odvětví softwarového inženýrství, zabývající se analýzou, návrhem a udržováním velkých podnikových systémů. Během 70. a 80. let se začaly objevovat metodiky strukturované analýzy a návrhu softwaru jako například DeMarcova SASS nebo SSADM vyvinutá firmou LBMS. Na konci 80. let se objevuje poslední velká strukturovaná metodika YMSA od Edwarda Yourdona. Dále se objevovaly okrajové metodiky jako logické modelování či pohledová analýza [9]. Díky příchodu objektově orientovaného přístupu v 90. letech, který znamenal revoluci v programování, bylo nutné vyvinout i objektově orientované metody analýzy a návrhu. V roce 1994 začal vývoj UML 1. O tři roky později byl schválen standard UML ve verzi 1.1 a postupem času byly přidávány další prvky. Nyní je UML ve verzi [3] a oproti prvotní verzi se jeho rozsah takřka zdvojnásobil. Z UML také začínají vznikat různé odnože pro určité oblasti, které přebírají část UML, kterou modifikují a doplňují o prvky specifické pro konkrétní oblast.uml je momentálně nejdokonalejším jazykem pro vizualizaci analýzy, návrhu a dokumentace softwaru. Kombinuje prvky strukturované analýzy s novými komponentami. Samotný UML je složen ze 14 diagramů, které poskytují různé pohledy na strukturu a chování systému. Pro tvorbu UML modelů se používají tzv. CASE nástroje 2, které jsou přímo určeny k návrhu softwaru. Nápad pro vytvoření této práce vznikl při absolvování kurzu PV167. Tento předmět se zabývá návrhem objektově orientovaných systému pomocí jazyka UML. Tématikou vývoje systémů pomocí objektově orientovaných metod se zabývá několik dalších předmětů na Fakultě informatiky. Hlavní myšlenkou bylo vytvořit univerzální sadu výukových materiálů o jazyku UML, doplněných o video návody tvorby jednotlivých modelů a usnadnit tím práci lektorům při seminářích. Student jich může například využít při domácí přípravě projektů. Druhá kapitola se obsahuje stručný úvod do jazyku UML, jeho historii a strukturu. Najdeme zde také podkapitolu určenou CASE nástrojům. Ve třetí kapitole najdeme specifikaci vzorového informačního systému, podle kterého vznikaly příklady modelů. Vybrané UML diagramy jsou rozebrány ve čtvrté kapitole. Pro každý diagram byla vyhrazená samostatná podkapitola, ve které je uveden účel diagramu, sémantika a příklad tvorby modelu. Prvním rozebíraným je diagram případu použití, na který navazuje diagram aktivit. Následuje velká podkapitola věnující se obsáhlému diagramu tříd. Z tohoto diagramu poté čerpá stavový diagram a diagramy interakce. V závěru kapitoly jsou uvedeny diagram balíku a diagram nasazení. Pátou kapitolu věnuji využití práce jako studijního materiálu několika předmětů. 1 Unified Modelling Language 2 Computer Aided Software Engernering 2

8 2. Jazyk UML a CASE nástroje UML je univerzální jazyk pro vizuální modelování informačních systémů. Přestože je nejčastěji spojován s modelováním objektově orientovaných systémů, má mnohem širší využití, což vyplývá z jeho rozšiřovacích mechanismů. Jazyk UML byl navržen proto, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství devadesátých let [1]. Modelovací jazyk UML je souhrnem především grafických notací k vyjádření analytických a návrhových modelů. UML umožňuje modelovat jednoduché i složité systémy a aplikace pomocí stejné formální syntaxe a proto můžete výsledky své práce sdílet s ostatními návrháři. Vybrané modely jsou lehce pochopitelné i pro zákazníky aplikace a umožní kvalitní vyjasnění požadavků uživatelů na vytvářený systém [2]. Zároveň je možné jednotlivé modely navrhnout tak, aby programátor byl schopen vytvořit program bez velkého přemýšlení nad zadáním. Samotné UML však poskytuje pouze grafickou reprezentaci návrhu systému. Metody jak navrhnout systém specifikují objektově orientované metodiky jako například RUP (Rational Unified Process), které využívají právě UML jako nástroje. Právě metodika RUP pochází od stejných tvůrců jako UML a je nejvíce přizpůsobena pro spolupráci s tímto jazykem [4] Historie UML Do roku 1994 byl trh s objektově orientovanými metodami značně roztříštěn. Existovalo několik soupeřících metod a metodik pro vývoj systémů. Každá měla své specifické vlastnosti a ve většině případů i notaci. V této době měli největší podíl na trhu metody Booch (autor Grady Booch) a OMT 3 (Jim Rumbaugh) a metodika Objectory (Ivar Jacobson). Jedním z prvních pokusů o sjednocení byla metodika Fusion (Derek Coleman) v roce Tato metodika měla rozsáhlou reklamu a komerční podporu, ale nebyli k jejímu vývoji přizvání autoři výše zmíněných metod. Jako odpověď na tuto iniciativu se pánové Booch a Rumbaught připojili k firmě Rational Corporation, která pracovala na tvorbě jazyka UML. Toto spojení dvou velkých hráčů, ukázalo směr v budoucím vývoji a metodika Fusion byla postupně zapomenuta. Rok poté se přidal k firmě Rational i Ivar Jacobson a začali rozsáhlé práce na specifikaci standardu UML. Výsledkem jejich práce byl jazyk UML a metodika RUP. V roce 1997 sdružení OMG 4 přijalo UML 1.1 jako otevřený průmyslový standart pro modelování vývoje softwaru [1]. Postupem času se přidávali další diagramy a prvky. V roce 2005 nabyla platnosti verze UML 2.0, která přinesla největší změny v UML. Od této verze je specifikace 3 Object Modeling Technique 4 Object Modeling Group 3

9 UML rozdělena na dvě části: UML Infrastructure a UML Superstructure. Infrastructure stanovuje základní konstrukce jazyka, tato sekce je spíše než pro uživatele určena pro vývojáře modelovacích nástrojů. Superstructure definuje notaci a sémantiku jednotlivých diagramů a je určena pro uživatele. Dále byl přidán jazyk OCL 5, který je použit pro specifikaci omezení v jednotlivých diagramech. Od této inovace jsou nové verze spíše zaměřeny na drobné úpravy. Poslední oficiální verze byla vydána v srpnu 2011[3]. Z UML také začínají vznikat různé odnože pro různá odvětví, například jako SysML či WebML pro vývoj webových aplikací. Obr. č 1:Historie jazyka UML 5 Object Constraint Language 4

10 2.2. Struktura UML UML v současné podobě obsahuje celkem 14 různých typů diagramů a je možno rozdělit do dvou hlavních kategorii. Mezi behaviorální a strukturální diagramy. Jak název napovídá, behaviorální diagramy se zabývají hlavně dynamické chování systému v čase. Skupina behaviorálních diagramů obsahuje podskupinu diagramů interakce. Interakční diagramy znázorňují informační a datové toky mezi třídami a objekty modelovaného systému. Behaviorální diagramy Diagram případů užití (Use Case Diagram) popisuje funkcionality systému z hlediska aktérů, zobrazuje případy užití a jejich propojení Diagram aktivit (Activity Diagram) popisuje operační a business logiku systému pomocí procesních toků Stavový diagram (State Machine Diagram) popisuje stavy objektu a přechody mezi nimi Interakční diagramy Sekvenční diagram (Sequence Diagram) popisuje vzájemnou komunikaci mezi objekty a třídami. Posloupnost zpráv je zachycena osou Y. Komunikační diagram (Communication Diagram) podobný účel jako sekvenční diagram. Posloupnost komunikace je zachycena číslováním. Diagram časování (Timing Diagram) ukazuje změny stavu, podmínky objektu nebo role ve vztahu k času. Diagram přehledu interakcí (Interaction Overview Diagram) - přehled nad diagramy interakce 5

11 Strukturální diagramy popisují statickou architekturu systému. Zachycují jednotlivé elementy (třídy, objekty, komponenty, atd.) a jejich vzájemné asociace. Diagramy struktury Diagram tříd (Class Diagram) popisuje třídy, atributy, operace a vztahy mezi třídami Diagram balíků (Package Diagram) popisuje strukturu balíků a jejich závislosti Diagram komponent (Component Diagram) zobrazuje komponenty a jejich vztahy Diagram nasazení (Deployment Diagram) popisuje nasazení systému na hardwarové zdroje Objektový diagram (Object Diagram) zobrazuje stav objektů v daný časový okamžik Diagram vnitřní struktury (Composite Structure Diagram) zobrazuje interní strukturu prvků a jejich vzájemnou spolupráci Profilový diagram (Profile Diagram) popisuje rozšíření UML v daném systému např. vlastní stereotypy Obr. č 2: Rozdělení UML diagramů 6

12 Neexistuje žádné pevně stanovené pořadí, v němž by se měli diagramy UML vytvářet. Přesto se obvykle začíná diagramem případu použití, který stanovuje rozsah navrhovaného systému a požadavky uživatelů na systém. Ve skutečnosti se pracuje s několika diagramy zároveň. Každý z nich je postupně doplňován a detailizován[1]. Hlavními pilíři je diagram případu užití a diagram tříd od nich se ostatní diagramy odvíjí. Model systému nemusí obsahovat všechny diagramy. Například k modelování většiny systémů není potřeba diagram časování či diagram profilů. Na obrázku č. 2 jsou světle modrou barvou vyznačeny diagramy, kterými se budu zabývat v této práci CASE nástroje CASE nástroje patří mezi specializovaný software na podporu analýzy a návrhu systémů. V současné době všechny objektově orientované CASE nástroje vycházejí z jazyka UML. Nepodporují jen samotnou tvorbu modelů, ale poskytují také možnosti generovaní kódu, verzování artefaktů nebo cloudové služby. Většina dnešních CASE nástrojů podporuje i procesní modelování. CASE nástroje jsou ideálním pomocníkem pro analýzu a návrh informačních systémů, jelikož umožňují v rámci jediného prostředí zmapovat veškeré aspekty vývoje informačního systému [2]. Mezi nejpoužívanější komerční CASE nástroje v oblasti UML patří [10]: Enterprise Architect (Sparx Systems) Visual Paradigm for UML (Visual Paradigm International) Rational Rhapsody (IBM) Visio (Microsoft) Volně šiřitelné: Modelio (Modeliosoft) Umbrello UML Modeller (Umbrello Team) 7

13 3. Specifikace vzorového informačního systému Pomocí specifikace stanovuje zákazník prvotní požadavky na realizaci systému. Požadavek lze definovat jako zadání toho, co by mělo být implementováno. Rozlišujeme dva typy požadavků: Funkční požadavky (functional requirements), jež určují, jaké chování bude systém nabízet Nefunkční požadavky (non-functional requirements), které specifikují vlastnosti nebo omezující podmínky daného systému Požadavky by měly být vyjádřením, co by měl systém dělat a jaké chování by měl poskytovat, aniž bychom cokoli říkali o způsobu, jak bude dané funkce dosaženo [1]. Rozsah dokumentu není pevně stanoven. Správná textová specifikace by měla obsahovat účel a popis systému, dále může obsahovat výčet uživatelských rolí, popis formátu vstupů a výstupů či požadavky na technickou podporu aplikace. Taktéž může být těchto dokumentů více. Například stručné zadání projektu, které bude definovat rozsah systému a navazujícím dokumentem může být technická specifikace, kde je už systém detailně rozebrán. Dokument musí být napsán jednoznačně a srozumitelně, aby nedošlo k milné interpretaci požadavků. Často je na základě specifikace připravena finanční nabídka na realizaci, proto je důležité, aby dokument byl podepsán zástupcem zákazníka a dodavatele. Případné další požadavky na rozšíření systému se aplikují například pomocí změnového řízení. Jako doménu pro vzorový příklad jsem zvolil systém pro univerzitní prodejnu odborné literatury. Systém není příliš složitý, ale zároveň je vhodný pro demonstraci tvorby vybraných UML modelů. Navíc doména internetových obchodů je v dnešní době populární a je pro každého dobře srozumitelná Specifikace systému MuShop Popis systému: Jedná se o systém obsluhující síť prodejen na jednotlivých fakultách s centrálním skladem. Zákazníci mají možnost objednávat položky pomocí e-shop. Zákazníci (studenti, lektoři a zaměstnanci Masarykovy univerzity) mají automaticky vytvořenou registraci díky propojení s IS MUNI a přihlašují se pomocí UČO 6 a sekundárního hesla. Objednávky je možné posílat na určitou adresu nebo vyzvednout na pobočce. Zákazník může spravovat svůj účet (měnit osobní údaje, vypsat historii objednávek), spravovat košík (měnit počty zboží, mazat zboží z košíku), spravovat objednávku (zrušit, sledovat) či komentovat položky. Lektor má navíc možnost nahrávat skripta do databáze. 6 Univerzitní číslo osoby 8

14 Prodejce na pobočce potvrzuje vydání zboží a zaplacení objednávky. Obsah e-shopu má na starost správce obsahu. Přidává, odebírá a mění položky. Pokud jsou všechny objednané položky na skladě, objednávka je předána k expedici. Pokud není část objednaných položek na skladě, je zaslána skladníkovi objednávka, ten tyto chybějící položky objedná od dodavatele a ručně zpracuje objednávku. Každý den je automaticky vygenerován report, ve kterém jsou uvedeny položky s nízkou skladovou zásobou. Uživatelské role: Zákazník, lektor, prodejce, správce obsahu, skladník Další systémy: IS MUNI Informační systém Masarykovy univerzity. 9

15 4. UML Diagramy 4.1. Diagram případů užití (Use Case Diagram) Diagram případů užití je jeden z klíčových diagramů pro modelování dynamických vlastností systému. Use case diagramy, jsou klíčové k modelování vlastností systému, subsystému nebo tříd. Jednotlivé diagramy zobrazují množinu případů užití a aktérů a jejich vzájemné propojení. Jsou důležité pro vizualizaci, specifikaci a dokumentaci systému [7]. Díky jednoduché notaci je diagram případů užití velice nápomocen při sestavování požadavků s uživatelem. Taktéž je později možné vycházet z něho při přípravě testovacích scénářů v průběhu vývoje systému. Prvky diagramu [1] Hranice systému (System boundary): Ohraničení zobrazené kolem případů užití, jež je vyznačením hranic modelovaného systému. Aktéři se nacházejí mimo hranice systému. Aktéři (Actors): Jsou to role, přidělené vnějším entitám (osoby, jiné systémy), které přímo komunikují se systémem. Aktérem je velmi často i čas. Případy užití (Use Cases): Činnosti, které systém vykonává jménem jednotlivých aktérů nebo v jejich prospěch. Případy užití vždy iniciuje aktér a jsou vždy psány z jeho pohledu. Relace (Relationships): Vztahy mezi aktéry a případy užití. Relace může být obousměrná nebo jedno směrná Pokročilé typy relací: Generalizace aktéra: Umožňuje vyčlenit chování, které je společné dvěma a více aktérům, do jednoho rodičovského aktéra. Výrazně zlepšuje čitelnost diagramu. Generalizace případu užití: Zobecněný vztah mezi obecnějším a konkrétním případem užití. Tento ryp relace se požívá jen velice zřídka. Relace include: Vztah mezi případy užití, kdy jeden případ užití začleňuje chování jiného případu užití. Vyčleňuje kroky společné několika případům užití do samostatného případu užití. Tuto relaci je třeba používat jen v případě, zjednoduší-li to model. Relace extend: Vztah mezi případy užití, kdy jeden případ užití rozšiřuje své chování pomocí jiného případu užití. Bázový případ musí obsahovat místa rozšíření (extension points). Tato relace se používá velice zřídka. 10

16 Obr. č 3: Prvky diagramu případů užití Při modelování případů užití je dobré postupovat v následujících krocích Nalezení hranic systému. Stanovení aktérů. Nalezení případů užití. Stanovení relací mezi případy užití a aktéry. Uvedený postup je třeba opakovat, dokud nedojde k ustálení případů užití a aktérů Doporučení Případy užití je vhodné pojmenovávat podle určitých pravidel. Jelikož se jedná o událost, měl by případ užití obsahovat sloveso. Název by měl být krátký ale výstižný, aby čtenář měl představu o funkci případu užití. Název je identifikátor, a proto musí být jedinečný. Aktéři by měli být pojmenováni podstatným jménem v jednotném čísle. Každý aktér musí být spojen s alespoň jedním případem užití. Při vytváření Use Case Diagramu, je dobré pamatovat na princip KISS 7. Model má obsahovat jen tolik podrobností, aby popsal požadavky. Je dobré používat pokročilé typy relací jen tam kde je to nutné a jejich použití zjednoduší diagram. Diagram je dobré udržovat na úrovni, na které je srozumitelný i uživatelům. Use Case Diagram je behaviorální diagram na zachycení funkčních požadavků a při jeho vytváření bychom se měli ptát Co? a nikoli Jak? 7 Keep it Short and Simple 11

17 Obr. č 4: Nadměrné použití funkce include[1] Příklad Na obrázku č. 5 je uveden příklad diagramu případů užití systému MuShop pro správu univerzitních prodejen odborné literatury, s jehož specifikací jsme se seznámili v předchozí kapitole. Nyní si předvedeme jak při modelování tohoto diagramu postupovat. Nejprve je důležité stanovit hranice systému, jež jsou reprezentovány modrým obdélníkem s názvem modelovaného systému. V následujícím kroku identifikujeme aktéry ze specifikace systému. V našem případě se jedná o aktéry Zákazník, Lektor, Prodejce, Správce a Skladník. Tyto aktéry umístíme na diagram mimo hranice systému. Zákazník a lektor mají téměř stejná práva, lektor může navíc nahrávat skripta. Mezi těmito aktéry bude relace generalizace. Směr šipky u této relace ukazuje na obecnějšího aktéra. V systémové specifikaci bylo uvedeno, že registrace jsou vytvořeny automaticky pomocí spolupráce s univerzitním systémem. Externí systémy patří taktéž mezi aktéry. Pokud systém má obsahovat nějaké chování, které je vykonáváno pravidelně na základě časového údaje, je dobré uvést mezi aktéry i čas. V našem případě se jedná o pravidelně generovaný report nízkých skladových zásob. 12

18 Následně pokračujeme hledáním samotných případů užití a tvoříme relace s aktéry. Jak jsem již uvedl, případy užití se vyznačují činností jednotlivých aktérů. Při modelování diagramu si můžeme všimnout, že některé činnosti jsou opakovány v různých případech užití. V našem příkladu tato situace nastává v případě objednání položky a změny položky. V obou případech je nejprve nutné položku vyhledat v nabídce, v tuto chvíli je vhodné využít relaci include. Při využívání specializovaných relací ale bychom měli být opatrní, aby nevznikl podobný stav jako na obrázku č. 4. Většina základních relací bývá obousměrná, tzn., že v interakce probíhá oběma směry. V některých případech může interakce probíhat pouze jedním směrem, často se tak stává například při zasílání notifikací nebo zpráv. V našem příkladu je to relace mezi aktérem Skladnik a případem užití Reportovat stav zasob, kdy je výsledný report zaslán skladníkovy a on už na něho nijak zpětně nereaguje. Obr. č 5: Diagram případů užití systému MuShop 13

19 Textová specifikace případu užití Textová specifikace slouží k popisu a dokumentaci jednotlivých případu užití. Neexistuje standart v UML který by popsal, jak má vypadat a co by měla obsahovat textová specifikace. Díky tomu si můžeme vytvořit vlastní šablonu pro specifikaci anebo použit nějakou stávající. Správná šablona by měla obsahovat tyto části: Název případu užití Přesně jak je pojmenován v modelu. ID případu užití Číselný identifikátor případu užití. Popis případu užití Stručný popis podstaty případu užití. Primární aktéři Aktéři, kteří spouštějí případ užití. Sekundární aktéři Aktéři, kteří jsou zainteresováni do případu užití. Vstupní podmínky Podmínky, které musí být splněny před spuštěním případu užití. Výstupní podmínky Podmínky, které musí být splněny, pokud byl případ užití splněn úspěšně. Scénář Posloupnost jednotlivých kroků případu užití. Základní scénář zobrazuje ideální variantu průchodu případem užití. Je možné použít jednoduché větvení pomocí pseudokódu. Alternativní toky zde jsou uvedeny kroky, které jsou provedeny ve výjimečných situacích a za určitých podmínek, které mohou nastat při průchodu hlavním scénářem. Textová specifikace může dále obsahovat například návrhy GUI týkající se případu užití nebo znění chybových hlášení. Hlavní scénář by neměl být příliš rozsáhlí. Při psaní scénáře je dobré se vyhnout věcem ohledně návrhu a psát ho z pohledu aktéra. Je vhodné používat krátké a jednoduché deklarativní věty. Je taktéž možné použít programovací pseudo jazyk (jednoduché příkazy typu IF, THEN, ELSE, WHILE). Pokud bude hlavní scénář příliš dlouhý je dobré případ užití přezkoumat, zda není možné ho rozdělit na více případů užití. 14

20 Příklad Textové specifikace Název Objednat polozku ID UC 01 Popis Cílem je správně vypleněná objednávka připravená k expedici Primární Zákazník aktéři Sekundár Skladník ní aktéři Vstupní Zákazník je úspěšně přihlášen do systému podmínky Výstupní Objednávka připravená k expedici podmínky Scénář Číslo Aktér Akce 1. Zákazník Vyhledat požadované zboží 2. Zákazník Přidat zboží do košíku 3. Zákazník Uzavřít košík 4. Zákazník Vyplnit údaje do objednávky a odeslat ke zpracování 5. Systém Kontrola údajů 6. Systém IF zboží na skladě OR objednávka obsahuje méně jak 5 ks položek THEN krok č. 7. ELSE 6a 7. Systém Odečíst položky z DB skladu a vystavit fakturu 8. Skladník Potvrdit vyskladnění. Alt. toky 2a. Zákazník IF zákazník chce pokračovat v nákupu THEN krok č. 1 5a. Systém Kontrola údajů neproběhla úspěšně. Zobrazit chybové hlášení č. 1 6a. Systém Zaslat objednávku k ručnímu zpracování. Chybová Číslo Znění hlášení 1. Prosím zkontrolujte údaje uvedené v objednávce Tabulka 1: Příklad textové specifikace 15

21 4.2. Diagram aktivit (Activity Diagram) Diagramy aktivit jsou technikou k popsání procedurální logiky a business procesů. Velice se podobají vývojovým diagramům, ale hlavním rozdílem je možnost podpory paralelních toků. Activity diagram byl jednou z větších změn při přechodu na verzi UML 2.0 [5]. Ve verzi UML 1. x byly diagramy aktivit pouze zvláštním případem Stavových diagramů (o nich více v následující kapitole), v nichž měl každý stav přidruženou aktivitu. Ve specifikaci UML 2.0 mají diagramy aktivit úplně novou sémantiku založenou na Petriho sítích [1]. Diagramy aktivit velice pomáhají při modelování procedurální logiky případu užití. Diagram případu užití nám zobrazuje, co by měl systém dělat a diagram aktivit nám umožňuje specifikovat postup, kterým toho dosáhne[9]. Diagram aktivit je možné použit při modelování business procesů, ale v dnešní době je v této oblasti spíše nahrazen technikami BPMN (Business Process Model and Notation) nebo notací Eriksson Penker, která je rozšířením UML. Prvky diagramu [1] Token Imaginární prvek, který putuje po cestách v diagramu. Může reprezentovat například postup řízení, objekt, data. Aktivita (Activity) - Znázorňuje činnost, která může být dekomponována na jednotlivé uzly a toky Uzly (Nodes) Akce (Action Node) - Činnost, kterou není třeba dále dekomponovat. Řídící uzly (Control Nodes) - Řídí cestu vně aktivity. Počáteční uzel (Initial Node) - Ukazuje počátek toku, jenž je aktivován po spuštění aktivity Koncový uzel aktivity (Activity Final Node) - Ukončuje aktivitu Koncový uzel cesty (Flow final node) Značí konec specifického toku Uzel rozhodnutí (Decision Node) Token pokračuje výstupní hranou, která splnila podmínku. Uzel sloučení (Merge Node) Zkopíruje vstupní tokeny na výstupní hranu Uzel rozvětvení (Fork Node) - Rozdělí cestu na několik souběžných toků. 16

22 Uzel spojení (Join Node) Synchronizuje několik souběžných toků (tzn., čeká, až budou tokeny na všech vstupních hranách) Objektový uzel (Object Node): zastupuje objekt v rámci aktivity (např. Dokument smlouvy) Vstupní parametr aktivity Výstupní parametr aktivity Toky,hrany (Flows,Edges) Řídící tok (Control Flow): znázorňuje cestu mezi uzly Objektový tok (Object Flow): znázorňuje cestu objektu Oddíly, Plavecké dráhy (Swimlines): znázorňují odpovědnost za jednotlivé uzly. Odpovědnost může nést například případ užití, aktér, role, třída, komponenta, organizační jednotka. Doporučení Obr. č 6: Prvky diagramu Aktivit Je dobré se opět držet principu KISS. Model by neměl mít více jak 5 plaveckých drah. Plavecké dráhy je lépe zobrazovat vertikálně a počáteční uzel umístit do levého horního rohu. Akční uzly by měli mít vstupní a výstupní hrany. Pokud nebudou mít vstupní hrany je to stejné jako by byli spojeny s počátečním uzlem (formalismus Petriho sítí). Výstupní podmínky z rozhodovacího uzlu musí mít prázdný průnik. Token se může vydat pouze jednou cestou. 17

23 Příklad Na obrázku č. 7 je uveden příklad Diagramu aktivit případu užití Objednani polozky. V předchozí kapitole byl tento případ užití rozebrán v textové specifikaci. Obr. č 7: Objednání položky Při tvorbě diagramu aktivit je vhodné začít oddíly neboli plaveckými drahámi (Swimlines). V našem případě se jedná o rozdělení odpovědnosti mezi aktéry Zakaznik a Skladnik. Aktéra, který spouští případ užití umístíme do levého oddílu. Je to z důvodu, že dle nepsané konvence se čte tok diagramu zleva doprava. Následně můžeme vložit počáteční uzel do levého horního rohu. Nyní můžeme začít vytvářet logickou posloupnost akcí. V našem případě začneme s akcemi Vyhledanim polozky a Pridanim polozky do kosiku. Po této akci se zákazník může rozhodnout, zda chce pokračovat v nákupu nebo uzavřít košík. Pro znázornění využijeme rozhodovacího uzlu. Pokud chce zákazník pokračovat v nákupu, vrátí se před akci Vyhledani polozky. Řídící tok ale nemůžeme jednoduše navést na tuto akci, musí směřovat do slučovacího uzlu (Merge Node). Toto je z důvodů formalizmu a notace diagramu 18

24 aktivit. Pokud se rozhodne ukončit výběr položek, může pokračovat akcemi Uzavrit kosik a Vyplnit objednavku. Následně systém může zpracovat objednavku. Tuto činnost namodelujeme jako aktivitu, protože je možné jí dekomponovat. Nyní rozebereme vnitřek této aktivity. Jako vstupní parametr aktivity figuruje nová objednávka odeslaná zákazníkem. Následně proběhne kontrola objednávky, pokud není zboží na skladě nebo objednávka obsahuje 5 a více položek je zaslána skladníkovy k ručnímu zpracování. V opačném případě jsou paralelně spuštěny akce Vystavit fakturu a Odecist polozky z DB skladu. Výsledkem těchto činností jsou artefakty faktura a zpracovaná objednávka. Paralelní toky jsou uzavřeny mezi uzlem rozvětvení (Fork Node) a uzlem spojení (Join Node). Zpracovaná objednávka je zaslána skladníkovy pro vyskladnění zboží. Skladník potvrdí vyskladnění a změní stav objednávky na Expedovana. Nakonec ještě sloučíme s alternativním tokem ručního zpracování a přejdeme do koncového uzlu. 19

25 4.3. Diagram tříd (Class Diagram) Diagram tříd je nejčastěji používaným digramem při modelování objektověorientovaných systémů a představuje statický pohled na strukturu modelovaného systému. Znázorňuje množinu tříd, rozhraní a jejich vzájemnou spolupráci a vztahy [7]. Důležitou vlastností je popis atributů a metod jednotlivých tříd. Diagram tříd je nejmohutnější ze všech diagramů a toto je nutné vzít v úvahu při jeho tvorbě. Jeho tvorbu je vhodné rozdělit do několika úrovní. V první úrovni namodelujeme pouze základní logickou strukturu systému, která odpovídá požadavkům na systém. Tento model se nazývá doménový a obsahuje základní třídy, atributy a vztahy mezi třídami. Druhým v pořadí je návrhový model a rozšiřuje doménový model o datové typy atributů, operace a doplňující třídy (například výčtové třídy). Dále upřesňuje asociace mezi třídami. Poslední model je implementační a zaměřuje se na detailní popis struktury. Je primárně určen pro vývojáře systému. Rozšiřuje návrhový model o speciální operace, tzv. gettery a settery, které slouží k nastavení a získávání hodnot atributů. Dále přidává manažerské třídy a neposlední řadě shlukuje třídy do balíků. Rozdělení do jednotlivých úrovní modelů není pevně stanoveno, může se odrážet na mohutnosti systému a metodice implementace systému. Z diagramu tříd přímo vycházejí ostatní digramy struktury, jako například diagram komponent nebo diagram nasazení. Taktéž poskytuje důležitá data pro diagramy interakce. Prvky diagramu [6] Třída (Class) Deskriptor množiny objektů, které sdílejí stejné vlastnost a chování (atributy a chování). Dědičnost, generalizace (Generalization) Hierarchický vztah předek (Superclass) - potomek (Subclass). Potomek dědí atributy a operace od svého předka. Potomek může mít své specifické atributy a metody. Asociace (Associaciation) Základní vztah mezi instancemi daných tříd. Asosciace jsou obousměrné i jednosměrné. Agregace (Aggregation) Druh asociace vyjadřující vztah celek část. V tomto případě část může existovat bez celku. Kompozice (Composition) Silnější vztah celek část než agregace. Část nemůže existovat bez celku. 20

26 Násobnost, kardinalita (Multiplicity) Omezení v počtu instancí tříd ve vzájemné asociaci. Balík Sdružení několika vzájemně propojených tříd. Obr. č 8: Prvky diagramu tříd Doporučení Doménový model by měl být platformě nezávislý. Snažte se dobře vyvážit jednotlivé modely. Názvy tříd jsou podstatná jména čísla jednotného nejlépe v anglickém jazyce. Způsob zápisu takzvanou CamelCase notací. Pro názvy operací a atributů používejte stejnou notaci s malým písmenem na začátku. Vhodné vše pojmenovávat a popisovat anglicky. Asociace by měly mít vždy násobnosti. Při návrhu se držte pravidla KISS. Postupujte dle principů objektově orientovaného programování. 21

27 Příklad: Doménový model Při tvorbě diagramu tříd začneme nejprve s doménovým modelem, který znázorňuje základní náčrt struktury systému. Na obrázku číslo 9 je vyobrazen příklad doménového modelu systému MuShop. Při tvorbě je vhodné začít z jednoho konce a postupně přidávat další třídy. Osobně jsem nejdříve vytvořil třídu pro evidenci osob Person a uvědomil jsem si, že budu potřeba evidovat dva druhy osob zákazníka (Customer) a zaměstnance (Employee). Tyto dvě třídy mají podobné i rozdílné vlastnosti a tedy jsem využil vlastností generalizace. Další důležitou součástí systému je správa objednávek a jejich vztah vůči zákazníkovi. Ve třídě Customer jsem vytvořil atribut orderhistory, který zajistí evidenci objednávek. Pro uložení dat o jedné objednávce byla vytvořena třída Order, nesoucí informace o datu objednávky, způsobu dodání a obsahu nákupního košíku. Atribut shoppingcart obsahuje kolekci jednotlivých položek objednávky. Položka objednávky je formulována třídou CartItem, jenž nese data o produktu a počtu objednaných kusů. Třída Product obsahuje obecné vlastnosti produktů, které přebírají následující třídy v hierarchii produktů. Obr. č 9: : Doménový model systému MuShop 22

28 Návrhový model Dalším stupněm k úplnému modelu tříd je návrhový model. Tento model rozšiřuje předchozí doménový model o řadu vlastností. Obrázek číslo 10 je částí návrhového modelu našeho systému. Prvním krokem přiřazení datových typů k jednotlivým atributům. U základních atributů jako je příjmení osoby nebo datum objednávky není problém přiřadit základní datové typy. U komplexních atributů je možné vytvořit vlastní datový typ. V našem příkladu se například jedná o atribut address ve třídě Person. Pro tento atribut byla vytvořena vlastní třída datového typu Address, která obsahuje jednotlivé části adresy jako své vlastní atributy. Podobně jsem postupoval i u atributu branch (pobočka) ve třídě Employee. Obr. č 10: Část návrhového modelu systému MuShop V této třídě také došlo ke změně atributu position na výčtovou třídu (Enumeration class) EmployeePosition. Výčtové třídy se dají použít všude, kde se předpokládá výběr konstantní hodnoty atributu z určitého seznamu. Jednoduše řečeno obsahem výčtové třídy je seznam konstant (v UML používaný název Enumeration literal). V našem případě jsou to konstanty VENDOR, STOCKMAN, MANAGER reprezentující jednotlivé pracovní pozice zaměstnanců. Stejná technika byla použita i pro atributy actualstate a deliverytype u třídy Order. Tyto výčtové třídy jsou určené pro aktuální stav objednávky a způsob dodání. 23

29 Další důležitou funkcionalitou návrhového modelu je upřesnění asociací mezi třídami. Jedná se hlavně o nastavení násobností (Multiplicity), druhu asociace (Aggregation kind)a případně omezení směru (Navigability). Vezměme úvahu například vztah jednoduchý vztah mezi třídami Person a Address. Osoba má pouze jednu adresu, na adrese může být zapsáno více osob. Jiným příkladem je vztah zákazníka a objednávky. Zákazník může mít v daný okamžik žádnou nebo více objednávek ale obráceně objednávka patří jednomu zákazníkovi. Existuje však možnost objednávky na zboží zaměstnancem na pobočku, z tohoto důvodu je možné realizovat objednávku i bez přiřazeného zákazníka. Tento typ asociace se nazývá agregace. Podobným příkladem je vztah objednávky a položky v košíku. Objednávka může obsahovat více položek, ale Určitá položka může být přiřazena právě jedné objednávce. Položka nemůže existovat bez přiřazené objednávky, tento vztah je příkladem kompozice. Posledním příkladem speciální vazby jsou vztahy mezi výčtovými třídami a třídami, které je využívají. Výčtová třída se ze svého pohledu nijak nekomunikuje s touto třídou, a proto je možné využít jednosměrné asociace. Imlementační model Posledním naším modelem je implementační. Rozšiřuje návrhový model o manažerské třídy, které mají na starost CRUD operace s jednotlivými třídami, dále jsou přidány operace getter a setter, jenž nastavují a vracejí hodnoty atributů. V tomto modelu můžeme třídy sdružit do balíků. Na obrázku číslo 11 je uvedena část implementačního modelu. Obr. č 11: Část implementačního modelu diagramu tříd 24

30 4.4. Stavový diagram (State Machine Diagram) Stavový diagram poskytuje pohled na dynamické chování objektu v průběhu času pomocí modelování životního cyklu dané třídy, jinými slovy modelují chování objektu napříč případy užití. Jednotlivé objekty reagují na události v systému a podle toho mění své stavy. Stav je množina hodnot atributů pro danou třídu [6]. Stavové diagramy jsou velice podobné diagramům aktivit, liší se však sémantikou i účelem. Diagramy aktivit vycházejí z Petriho sítí a jsou určeny k modelování procesů. Stavové diagramy UML jsou založeny na Harelových diagramech (Harel Statecharts) a znázorňují životní cyklus objektu jako konečný stavový automat (Finite-state automaton) [1]. Prvky diagramu Stav (State) Reprezentace konkrétní situace, která nastala během životního cyklu objektu. Ke stavu mohou být přiřazeny události, které proběhnou během zpracovávání stavu. Přechod (Transition) Posun z jednoho stavu do jiného vyvolaného určitou událostí. Událost (Event) Specifikace něčeho významného, co nastane v určitém čase a prostoru. Lze jí znázornit externě na přechodech nebo interně uvnitř stavů. Dalšími prvky například jsou počáteční a koncové stavy či rozhodovací uzly. Doporučení Obr. č 12: Prvky stavového diagramu Všechny stavy s výjimkou počátečních a koncových stavů by měli mít jak vstupní tak výstupní přechod. Je dobré sestavit diagram tak aby byl čitelný zleva doprava. Počáteční bod v levém horním rohu a koncový v pravém dolním rohu. Událost pojmenovávat slovesem v trpném rodě. 25

31 Příklad V tomto příkladu si názorně ukážeme jak namodelovat Stavový diagram. Na obrázku č. 11 vidíme možné stavy objektu Order (Objednávka). Objekt mění své stavy dle vykonávaných činností, které mají vliv na jeho atributy. Nad stavy by se dalo uvažovat jako stadii životního cyklu objektu. Nyní si rozeberme náš příklad. Zákazník vloží položku do košíku, v tu chvíli se vytvoří nová objednávka, její stav bude Zalozena. Zákazník pokračuje v nákupu a následně uzavře košík a potvrdí objednávku. Systém příjme objednávku a stav se mění na Prijata. Pokud by zákazník objednávku nepotvrdil do 30 minut od jejího založení, automaticky se zruší a přejde do stavu Stornovana. Vraťme se ale ke stavu, kdy je přijata systémem. Systém vyhodnotí objednávku (zkontroluje údaje, vytvoří fakturu) a změní stav na Zpracovana. Skladník po připravení zásilky a předání k expedici změní stav na Expedovana. Po doručení zásilky zákazníkovy a spárování platby s objednávkou je stav změněn na Dokoncena. Samozřejmě může být z jakéhokoliv stavu za určitých podmínek stornovaná. Všimněme si také vykonávaní událostí uvnitř stavů. Obr. č 13: Stavy objednávky 26

32 4.5. Sekvenční diagram (Sequence Diagram) Digramy interakce popisují vzájemnou spolupráci skupiny objektů. UML definuje několik interakčních diagramů, avšak nejčastěji používaným je Sekvenční diagram. Typicky tento diagram zachycuje zasílání zpráv mezi klasifikátory (classifiers) v rámci případu užití [5]. Klasifikátorem v tomto případě může být aktér, třída nebo objekt. Sekvenční diagramy znázorňují klasifikátory na horní hraně diagramu. Na horní liště vlevo je umístěn aktér, který je zodpovědný za spuštění případu užití. Z klasifikátorů vede svislá čára reprezentující život objektu v průběhu daného případu užití. V terminologii UML je tako čára nazývávána jako čára života (LifeLine). Každá zpráva mezi objekty je znázorněna šipkou mezi čárami života. Zpráva jsou požadavky objektu o vyvolání operace druhého objektu. Objekty mohou zasílat zprávy i sami sobě (tzv. self-call) Pořadí (sekvence) zasílání zpráv je reprezentována osou Y, čas plyne od shora dolu [2]. Prvky diagramu [1] Čára života (LifeLine) Reprezentuje, jakým způsoben se instance určitého klasifikátoru účastní interakce. V hlavičce čáry života je uveden klasifikátor Zpráva (Message) Zastupuje druh komunikace mezi dvěma čárami života. Kombinované fragmenty (Combined Fragment) Oblast uvnitř sekvenčního diagramu s odlišným chováním. Doporučení Alt - Podmínka definuje, zda dojde k provedení operace Loop cyklus, smyčka Klasifikátory by měli být pojmenováni stejnými názvy jako v ostatních diagramech. Název zprávy odpovídá názvu volané operace. Není nutné modelovat návratové zprávy. Je vhodné, aby klasifikátory byly řazeny podle pořadí zasílání zpráv. 27

33 Obr. č 14: Prvky sekvenčního diagramu Příklad V následujícím příkladu si představíme tvorbu sekvenčního diagramu. Na obrázku číslo 15 je model vytvoření objednávky. Nejprve umístíme aktéra, který spouští případ užití. Objednáním prvního zboží spustí sekvenci tři operací. Nejprve je vytvořena objednávka voláním operace createorder() ze třídy OrderManager. Tato operace vytvoří instanci třídy Order a změní její stav na CREATED. Poté přidá položku zboží do košíku. Následně je zákazník dotázán, zda chce pokračovat v nákupu. Pokud ano pokračuje dalším přidáváním zboží do nákupního košíku. Po ukončení nákupu vybere možnost dodání, pomocí volání operace setdeliverytype(). Potvrzením odešle objednávku do systému a změní stav na ACCEPTED. Systém následně a vloží časové razítko a zapíše objednávku do uživatelova účtu voláním operace addorder() ze třídy Customer. Objednávka je tímto úspěšně předána k vyřízení. 28

34 Obr. č 15: Příklad sekvenčního diagramu 29

35 4.6. Komunikační diagram (Communication diagram) Komunikační diagram jsou dalším typem interakčních diagramů. Mají velice podobný cíl jako sekvenční diagramy. Komunikační diagramy zdůrazňují strukturální vztahy mezi klasifikátory a jsou užitečné ve fázi prvotní analýzy. Syntaxe komunikačních diagramů je velice podobné sekvenčním diagramům, avšak sémanticky jsou slabší. Na rozdíl od nich čáry života nemají svislou čáru a reprezentují třídy a objekty. Řazení zpráv je reprezentováno číslováním zpráv. Větvení je realizováno podmínkou v těle zprávy [1]. Prvky diagramu Čára života (LifeLine) Reprezentace třídy nebo objektu. Linka (Link) Spojnice mezi čarami života, po kterých putují zprávy. Po jedné lince může putovat více zpráv oběma směry. Zpráva (Message) viz Sekvenční diagram Aktér (Actor) viz Diagram případu užití Obr. č 16: Prvky komunikačního diagramu Doporučení Každá zpráva musí mít směr. Zprávy je nutné číslovat, aby bylo zřejmé jejich pořadí. Je vhodné používat předem domluvený formát. Ostatní doporučení jsou podobná jako u sekvenčních diagramů 30

36 Příklad Na obrázku číslo 17 je rozebrán stejný příklad jako v předchozí kapitole. Nyní ale namodelován pomocí komunikačního diagramu. Postup modelování byl velice podobný. Všimněme si však syntaxe zprávy číslo 4. Na obrázku číslo 15 byla tato zpráva namodelována pomocí kombinovaného fragmentu smyčky. Komunikační diagramy jsou sémanticky slabší a podobnou konstrukci nemají. Můžeme si však vypomoci jednoduchým pseudokódem. Specifikace UML konkrétní syntaxi nepředepisuje. Můžeme tedy použít, cokoliv co dává smysl[1]. Zbytek diagramu již byl modelován standartním způsobem. Na tomto příkladu je dobře vidět rozdíl mezi sekvenčními a komunikačními diagramy. Sekvenční jsou spíše vhodné na modelování komplexnějších případů užití, protože umožňují složitější konstrukce. Naopak komunikační diagramy jsou více čitelné u popisu jednodušších případů užití. Obr. č 17: Příklad komunikačního diagramu 31

37 4.7. Diagram balíků (Package diagram) Třídy představují základní formu struktury objektově orientovaných systémů. I přes jejich širokou použitelnost je potřeba nástroj pro jejich uspořádání ve větších systémech, které můžou obsahovat až stovky tříd. K tomuto účelu jsou právě stvořeny balíky. Pomocí Diagramu balíků je možné sdružovat i prvky ostatních diagramů do skupin a následně vyjádřit jejich závislosti. Programovací jazyk Java používá termín balík (package) ale například jazyky C++ nebo.net používají výraz jmenný prostor (namespace) [5]. Prvky diagramu Balík (Package) Mechanizmus jazyka UML pro sdružování prvků v jednotlivých modelech Závislost (Dependency) Relace mezi balíčky, kdy je klientský balíček nějakým způsobem závislý na zdrojovém balíčku. Typy relací rozlišujeme pomocí stereotypů «use» - Klientský balík využívá prvky zdrojového balíku. Základní typ závislosti. Pokud nemá relace stereotyp je považována za «use». «import» - Zdrojové prvky jsou importovány do klientského balíku. «access» - Klientský balík přistupuje k veřejným prvkům zdrojového balíku. «trace» - Používá se v případech kdy klientský balík je dalším vývojovým stupněm zdrojového balíku. Používá se spíše v relaci mezi modely. «merge» - Prvky zdrojového balíčku jsou sloučeny s klientským. Tato relace se běžně nevyužívá. Generalizace (Generalization) Relace významem podobná generalizaci tříd. Odvozené balíky dědí prvky svých předků. Obr. č 18: Prvky diagramu balíků 32

38 Doporučení Použití balíků musí být dobře vyváženo. Není dobré používat příliš balíků. Mezi balíky by nemělo docházet k cyklickým závislostem Závislost mezi balíčky nastává, pokud existuje závislost mezi dvěma prvky těchto balíků Pokud používáme balíky v diagramu případu užití, je dobré takto sdružovat případy užití podle aktérů. Příklad Obrázek číslo 19 představuje model balíků tříd. Jako ukázku jsem přidal návrh spolupráce s balíky programovacího jazyku Java, ve kterém by byl systém teoreticky vyvíjen. Jádro tvoří balíky tříd systému. Celý balík systému MuShop následně spolupracuje s vestavěnými balíky Java. Také je zde zohledněn balík informačního systému univerzity, který poskytuje databázi uživatelů. Obr. č 19:Příklad diagramu balíků 33

39 4.8. Diagram nasazení (Deployment diagram) Diagram nasazení popisuje hardware, na němž bude systém nasazena ale i způsob nasazení na jednotlivých uzlech. Diagram mapuje architekturu softwaru vytvořenou ve fázi návrhu na fyzickou architekturu systému, na němž bude systém spuštěn. U distribuovaných systémů se modeluje rozložení softwaru na fyzické uzly. Existují dva stupně diagramu nasazení. Obecný Diagram nasazení představují uzly obecné typy hardwaru (PC, Server) a softwaru (MS Windows 7, Oracle DB). V Diagramu konkrétního nasazení jsou uzly přesně specifikovány a zastupují konkrétní instance (server s IP adresou xy)[1]. Prvky diagramu Uzel (Node) Vyjádření typu výpočetního prostředku «device» - Zařízení Hardware «execution enviroment» - Softwarové prostředí Artefakt (Artefact) Fyzický výskyt softwaru (soubory, dokumenty, skripty atd.) Komponenta (Component) Část informačního systému umístěna na uzlu Asociace (Associaciation) Propojení jednotlivých uzlů Obr. č 20: Prvky diagramu nasazení Příklad Na obrázku číslo 21 je vyobrazen návrhový diagram systému MuShop. Při tvorbě modelu je si důležité uvědomit jaká architektura bude zvolena při vývoji systému. 34

40 V našem případě se jednalo o využití Java technologie, databázového sytému MySQL a přístupu pomocí webového prohlížeče. Při tvorbě modelu jsem nejprve začal umístěním aplikačního serveru. Náš systém využívá technologie Java a musí být přítomno prostředí Java Virtual Machine, jenž je nutné pro spouštění zdrojového kódu v jazyce Java. V rámci tohoto prostředí běží výpočetní komponenta našeho systému MuShop_Core, obsahující jádro systému. Další důležitou komponentou je databáze systému MuShop_DB, která běží v prostředí MySQL na databázovém serveru. Uživatelé jsou napojeni na systém pomocí webového služby MuShop_WebService, jež je obsluhována pomocí webového serveru Apache, umístěného na aplikačním serveru. Obr. č 21: Příklad diagramu nasazení 35

41 5. Použití materiálů pro výuku Materiály obsažené v této práci mohou najít uplatnění při výuce předmětů zabývající se tématikou objektově orientovaného vývoje informačních systémů. Tyto předměty je možné rozdělit do kategorii: Předměty zabývající výukou analýzy a návrhu informačních systémů Předměty zaměřené na objektově orientované programovací jazyky Pro předměty zabývající se analýzou a návrhem doporučuji použít plnou sadu UML diagramů obsažených v této práci. Také bych doporučoval využít následovné pořadí výuky diagramů. Diagram případů užití Pomocí tohoto diagramu v úvodu stanovýme požadavky na systém. Diagram aktivit Uvádí posloupnost událostí k vedoucí k naplnění cíle případu užití. Diagram tříd Obsahuje strukturu systému a ostatní diagramy z něho čerpají. Stavový diagram Doporučuji zařadit po diagramu tříd. Jsou již známy třídy a jejich instance. Sekvenční diagram Vhodné zařadit po diagramu tříd, z důvodu znalosti tříd a jejich operací. Komunikační diagram Alternativa k sekvenčnímu diagramu. Diagram balíků Diagram nižší priority vycházející z diagramu tříd Diagram nasazení Popisuje nasazení systému na výpočetní zdroje. 36

42 U předmětů vyučující objektové programovací jazyky není velký prostor pro analýzu a návrh. Často je však vhodné využít dvou nejdůležitějších diagramů diagramu případů užití a diagramu tříd k popsání požadavků a struktury aplikací Využití materiálu v předmětech Fakulty informatiky. PA103 Objektové metody návrhu informačních systémů Značná část tohoto předmětu je věnována jazyku UML a metodice RUP. V tomto předmětu je vhodné využít kompletní sadu se zaměřením na teorii, PV167 Projekt z objektového návrhu informačních systémů Seminář k předmětu PA103 zabývající se praktickou výukou tvorby UML modelů. V tomto semináři je možné použít kompletní sadu materiálů PB007 Softwarové inženýrství I Hlavní náplní tohoto předmětu je seznámit studenty s metodikou vývoje informačních systémů. V semináři tohoto předmětu je možné využít kompletní sady. PB162 Programování v jazyce Java Kurz zaměřený na základní znalosti objektového programovacího jazyka Java. V tomto předmětu je možné využít kapitoly o diagramu tříd. PV168 Seminář z programování v jazyce Java Seminář pokročilého programování v jazyce Java. V praktické části předmětu má student za úkol vypracovat samostatný projekt. Součástí tohoto projektu je diagram případů užití a diagram tříd. PB161 Programování v jazyce C++ Předmět zabývající se programováním v jazyce C++. Součástí kurzu jsou základní techniky objektově orientovaného návrhu. Je možné využit kapitol diagramu případu užití a diagramu tříd. 37

43 6. Závěr Cílem teoretické části této bakalářské práce bylo seznámit čtenáře s jazykem UML a vybranými diagramy tohoto jazyka. V úvodní kapitole jsem popsal vývoj a strukturu jazyka UML. Následující kapitola je určena specifikaci vzorového systémů, na základě kterého jsou zpracovány jednotlivé příklady. Hlavní část dokumentu je věnována účelu a sémantice UML diagramů. Také jsem se pokusil přidat několik doporučení a zpracovat vhodné příklady tvorby jednotlivých modelů. Při tvorbě vzorových modelů jsem se snažil nalézt příklad, který není příliš složitý a zároveň umožňuje použít širokou škálu konstrukčních prvků daného diagramu. Také jsem se snažil u několika příkladů poskytnout různé pohledy na určitou část modelovaného systému. Na konci teoretické části je výčet předmětů fakulty informatiky, u kterých je možné využít této práce. Praktická část obsahuje video návody tvorby jednotlivých modelů v nástroji Visual Paradigm for UML. Při realizaci těchto návodů bylo nejobtížnější vměstnat dostatek informací do požadované délky videa a zároveň se vyhnout opakování operací již jednou zaznamenaných. Nakonec díky sestříhání se podařilo tyto návody vyvážit. Celkem vzniklo jedenáct video návodů. Pro většinu diagramů stačilo vytvořit jeden samostatný záznam. Avšak v případě diagramu tříd vznikly tři záznamy, důvodem je rozdělení diagramu na tři modely. Navíc je jeden video návod věnován představení funkcí Visual Paradigm. Při hledání vhodného nástroje pro záznam návodů jsem vyzkoušel několik nástrojů, a však nejvhodnějším se nakonec ukázal Adobe Captivate. Věřím, že všech cílů bylo při realizaci této práce dosaženo a bude zařazena jako studijní materiál k výuce předmětů spojených s výukou UML či objektově orientovaných programovacích jazyků. 38