EVROPSKÁ UNIE Evropské strukturální a investiční fondy Operační program Výzkum, vývoj a vzdělávání M I N I S T E R S T V O Š K O L S T V Í , M L A D E 2 E A TĚLOVÝCHOVY Název projektu Rozvoj vzdělávání na Slezské univerzitě v Opavě Registrační číslo projektu CZ.02.2.69/0.0./0.0/16_015/0002400 Objektové metody modelování v příkladech Distanční studijní text Zdeněk Franěk Karviná 2018 SLEZSKÁ U N I V E R Z I T A OBCHODNĚ PODNIKATELSKÁ FAKULTA V KARVINÉ Zdeněk Franěk - Objektové metody modelování v příkladech Obor: Informační a komunikační technologie (ICT), Vývoj a analýzy softwaru a aplikací Klíčová slova: Analýza, software, diagramy UML, metodika RUP, objekty, třídy, polymorfismus, dědičnost. Anotace: Tento učební text se zabývá analýzou návrhu software s využitím U M L diagramů a metodiky RUP. Je určen pro studenty 1. ročníku studijního programu Manažerská informatika v navazujícím stupni studia, zejména v kombinované formě výuky. Z tohoto důvodu je forma učebního textu koncipována tak, aby studenti měli k dispozici text postačující k ovládnutí dané problematiky a zároveň si mohli své znalosti po každé kapitole ověřit pomocí testových otázek nebo úkolů. Hlavním tématem studijní opory je popis analytických postupů při návrhu informačních systémů - software s využitím jazyka Unified Modeling Language (UML) a metodiky RUP. Modelovací jazyk U M L je základní nástroj pro objektovou analýzu při návrhu software a informačních systémů. Tato studijní opora navazuje na předchozí studijní oporu z roku 2014 s názvem „Objektové metody modelování - Výklad jazyka UML". Tato studijní opora je určena zejména pro studenty v distanční formě studia a tomu odpovídá jiná struktura studijní opory dle předepsané wordovské šablony. V nové studijní distanční opoře je kladen důraz na praktické předvedení možností objektových technik modelování, a proto je výklad provázen řadou praktických příkladů. Po každé kapitole jsou zařazeny testové otázky tak, aby si student osvojené poznatky mohl sám otestovat. Obě studijní opory se vzájemně doplňují a jsou dostupné v e-learningovém kurzu pro výuku povinně volitelného předmětu „Objektové metody modelování" magisterského studijního programu „Manažerská informa­ tika" Objektově orientované modelovací techniky a jazyk U M L jsou ústředním tématem této opory. Autor: R N D r . Z d e n ě k F r a n ě k , P h . D . Recenzenti: doc. Mgr. Petr Suchánek, Ph.D. Ing. Václav Król, Ph.D. ISBN 978-80-7510-295-9 Toto dílo podléhá licenci: Creative Commons Uved Znění licence dostupné na http://creativecommons.Org/licenses/by-sa/4.0 (oci 0 © Creative Commons Uveďte původ-Zachovejte licenci 4.0 c a B B B Znění licence dostupné na: 2 Zdeněk Franěk - Objektové metody modelování v příkladech Obsah ÚVODEM 5 RYCHLÝ NÁHLED STUDIJNÍ OPORY 7 1 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ 8 1.1 Od strukturálního poj etí k obj ektovému 9 1.2 Objekt 11 1.2.1 Třída 13 1.2.2 Struktura tříd 15 1.2.3 Zobecnění (generalizace-specializace), dědění (inheritance) 15 1.2.4 Abstraktní metody a třídy 17 1.2.5 Polymorfismus 18 1.2.6 Zapouzdření 18 2 ZÁKLADNÍ ELEMENTY JAZYKA U M L 21 2.1 Princip jazyka U M L 21 2.2 Historie vzniku jazyka U M L 22 2.3 UML-skladba 23 2.4 U M L - mechanismy 24 3 POPIS JAZYKA U M L - USE CASE 28 3.1 Úvod do problematiky USE CASE 28 3.2 Případová studie USE CASE 29 3.3 Scénáře v případech užití 33 3.4 Popis případu užití 34 3.5 Vstupní a výstupní podmínky 35 3.6 Postup tvorby popisu případu užití 35 4 POPIS JAZYKA U M L - MODELOVÁNÍ TŘÍD A OBJEKTŮ 38 4.1 Základní popis diagramu tříd 39 4.2 Prvky diagramu tříd a doporučení k vytváření modelu tříd 40 4.3 Příklad modelu tříd objednávka na e-shopu 41 4.4 Model objektové spolupráce 41 4.5 Základní charakteristika a prvky objektového diagramu 42 4.6 Příklad objektového diagram 43 5 POPIS JAZYKA U M L - STAVOVÉ DIAGRAMY 46 5.1 Základní charakterištika 46 3 Zdeněk Franěk - Objektové metody modelování v příkladech 5.2 Prvky stavového diagramu 46 5.3 Doporučení k vytváření stavového diagramu 47 5.4 Příkladový stavový diagram 48 6 POPIS JAZYKA U M L - DIAGRAMY AKTIVIT 50 6.1 Základní charakteristika diagramu aktivit 50 6.2 Prvky diagramu aktivit 51 6.3 Doporučení k vytváření diagramu aktivit 52 6.4 Příklady diagramů aktivit 52 7 SEKVENČNÍ DIAGRAM 58 7.1 Základní charakteristika a prvky sekvenčního diagramu 58 7.2 Doporučení k vytváření sekvenčního diagramu 59 7.3 Příkladový sekvenční diagram 60 8 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI 64 8.1 IBM Rational Software Development Platform 64 8.2 ENTERPRISE ARCHITECT firmy SPARX 67 8.3 U M L A VISIO firmy MICROSOFT 74 9 RUP - RATIONAL UNIFIED PROCESS 77 10 PRAKTICKÉ PŘÍKLADY VYUŽITÍ U M L 82 10.1 Užití skladového informačního systému 82 10.2 Analytická úloha pro společnost DERS 89 10.3 Podnikový prodej - vytvoření nové objednávky zákazníkem 97 10.4 Rezervační systém kulturních akcí 106 10.5 Modelování IS knihovny 113 10.6 Kniha jízd 118 SHRNUTÍ STUDIJNÍ OPORY 123 LITERATURA 124 PŘÍLOHA Č. 1: SEZNAM OBRÁZKŮ 126 PŘÍLOHA Č. 2: SEZNAM TABULEK 127 PŘEHLED DOSTUPNÝCH IKON 128 4 Zdeněk Franěk - Objektové metody modelování v příkladech ÚVODEM Návrh informačních systémů (dálejen IS), metodikajejich vytváření, programování systémů a aplikací, vytváření software, objektové metody modelování s využitím jazyka Unified Modeling Language (dálejen UML) jsou na vrcholu témat tvůrčí práce v oblasti informačních technologií (dálejen IT) technologií. Učební text, který je zvýše uvedených oblastí návrhu informačních systému zaměřen především na objektové metody modelování s využitím jazyka U M L a metodiku vytváření software, je určen studentům 1. ročníků studijního programu Manažerská informatika na Obchodně podnikatelské fakultě v Karviné, Slezské univerzity v Opavě (dálejen SU OPF). Je zaměřen na kombinovanou formu studia a tomu je určena forma textu. Text je provázen ikonami, zdůrazňujícími hlavní rysy IT technik z výše uvedenou tématikou. Na začátku každé kapitoly je shrnutí čemu se studenti naučí, následuje výklad a příklad pokud to umožňuje charakter tématu. Vždyjsou graficky zdůrazněny hlavní myšlenky, resp. poznatky. Na konci každé kapitoly jsou uvedeny testové otázky k procvičení probrané látky. Správné odpovědi pro samokontrolu j sou přiloženy hned za otázkami. Pochopení textu této distanční studijní opory předpokládá u studentů základní znalosti z oblasti informačních technologií. Je určen studentům navazujícímu stupni studia, především v kombinované formě studia. Tyto předpokládané znalosti odpovídají znalostem získaných absolvováním bakalářského stupně studia studijního programu Manažerská informatika na OPF. Jedná se zejména o zvládnutí základních poznatků z předmětu databázové systémy, algoritmy a datové a procesní modelování. Všechna tato témata jsou součástí studia v bakalářském stupni, studijního programu Manažerská informatika. Přesto lze k textu přistoupit bez předchozího studia a v případě neporozumění textu si znalosti doplnit z příslušných částí příslušných studijních opor. Text je doprovázen případovou studií a látka je ilustrovaná příklady, na kterých lze porozumět předchozí teorii. Doporučený postup při práci s textem je následující: Přečíst si důkladně teorii a hned šiji ověřit na příkladu. Poté se znovu vrátit k teorii a pomocí příkladu objasnit sporná nebo těžká místa. Zpětným pročítáním textu lze tzv. iterační metodou přírůstků znalostí dospět k pochopení probíraných témat. Zvláštní pozornost doporučujeme věnovat rovněž metodice návrhu informačních systémů. Je nutno zdůraznit, že bez dobré metodiky nelze dosáhnout úspěchu při návrhu IS. Metodika Unified Process (dálejen UP), objektové metody modelování a U M L diagramy spolu úzce souvisí. Je třeba zdůraznit, že tento učební text se věnuje výhradně fázi analýzy před zahájením programování informačního systému, resp. software obecně. Cílem autora bylo popsat všechny techniky tak, aby po jejich aplikaci bylo možno zahájit programátorské práce a aby 5 Zdeněk Franěk - Objektové metody modelování v příkladech si zúčastněné strany (zadavatel, uživatel, analytik a programátor) plně rozuměli. Samozřejmě to nevylučuje to, že se U M L diagramy často používají i pro nasazení a dokumentaci programových systémů. Tato studijní opora je součástí e-learningového kurzu na http://elearning.opf.slu.cz, který je dostupný pro studenty předmětu „Objektové metody modelování". Text byl sestaven na základě využití literatury, zkušeností autora a na základě přednášek a seminářů během výuky předmětu. V práci jsou využity poznatky při zpracování seminárních prací studenty ve spolupráci s lektorem předmětu. V předmětu je využíván software, při jednoduchých úlohách je to MS VISIO a šablony pro UML. Pro složitější úlohy byly v předmětu využívány CASE nástroje. Nejdříve to byl CASE firmy IBM Rational IBM Architect. Později velmi kvalitní a nejvíce rozšířený CASE nástroj firmy SPARX Enterprise Architect. Tento software se při rozvoji předmětu plánuje využívat jako číslo 1. Poděkování za spolupráci na této učební opoře patří samozřejmě autorům literatury, studentům-účastníkům přednášek a seminářů, dále pak spolupracovníkům z katedry matematiky a informatiky SU OPF a za podporu mým blízkým. 6 Zdeněk Franěk - Objektové metody modelování v příkladech RYCHLÝ NÁHLED STUDIJNÍ OPORY Cílem studijní opory je srozumitelnou formou s využitím ikon a struktury používané pro kombinovanou formu výuky seznámit studenty s teorií objektového modelování systémů ajejím významem pro projektování informačních systémů. Předmět seznámí studenty s historickým vývojem objektového přístupu a používanými standardy v dané oblasti. V textu jsou studenti seznámeni s metodikou RUP (Rational Unified Process). Hlavní náplň opory je věnována jazyku U M L (Unified Modeling Language). Jazyk U M L byl koncipován pro návrh, analýzu, tvorbu a dokumentaci informačních systémů s objektově orientovaným přístupem. V rámci studia učební opory studenti získají znalosti standardního způsobu zápisu - koncepce návrhu systému, jako jsou business procesy a systémové funkce. Dále se naučí tvořit konkrétní prvky, jako jsou například znovupoužitelné programové komponenty a databázová schémata. Na příkladech je demonstrována praktická práce s jazykem UML. V textu jsou procvičeny základní postupy při vývoji software s využitím Enterprise Architect (označuje se zkratkou EA) firmy SPARX, který patří do rodiny Computer Aided Software Engineering (ve zkratce CASE) a šablony pro U M L diagramy produktu VISIO firmy Microsoft. Studenti j sou seznámeni se softwarem IBM Rational Enterprise Architect, průkopníkem mezi CASE softwarovými nástroji na poli vývoje informačních systémů. Učební text se dělí do těchto témat: 1. Úvod do objektového modelování 2. Shrnutí základních pojmů objektově orientované analýzy a návrhu software. Pojem objekt. Základní koncepty: abstrakce, zapouzdření, skrývání informací, třídy, dědičnost, interface. 3. Popis jazyka U M L 4. Co je UML, objekty a jazyk UML, struktura jazyka, stavební bloky, vyjádření tříd, atributů a operací. Obecný přehled diagramů UML. Diagramy UML: případy užití, stavové diagramy, diagramy sekvencí, diagramy spolupráce, diagramy tříd, diagramy činností, diagramy architektury. 5. Software produkty pro práci v U M L 6. Přehled softwarových nástrojů pro objektové modelování. Představení a zpřístupnění software E A SPARX a MS VISIO - část pro kreslení U M L diagramů. Případy užití. 7. Metodika Unified Process (UP) a Rational Unified Process (RUP) 8. Hlavní principy moderního iterativního vývoje softwaru metodikou RUP. 9. Jednotlivé fáze životního cyklu projektu, který vyvíjí software - účel, možnosti, rizika vývoje. 10. Případové studie návrhu informačního systému s využitím U M L a metodiky RUP. 7 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ 1 UVOD DO OBJEKTOVÉ ORIENTOVANÉHO MODELO­ VÁNÍ RYCHLÝ NÁHLED KAPITOLY Úvodní kapitola učebního textu seznamuje studenty s principy objektově orientovaného návrhu software. Objektově orientované modelování ve zkratce OOM pochází z anglického Object-Oriented Modeling. V první kapitole je popsána historie vzniku objektově orientovaného přístupu vývoje software a srovnání s předchozím procedurálním přístupem. V kapitole jsou popsány základní pojmy jako je třída, objekt, zapouzdření, dědičnost a polymorfismus a některé další vlastnosti OOM. Objektově orientované modelování pokrývá analýzu, programování a nasazení software. CÍLE KAPITOLY Cílem úvodní kapitolyje seznámit čtenáře se základními pojmy objektově orientovaného modelování při vytváření software, obecněji informačních systémů. Základní pojmy popsat a vysvětlit, a také doložit na příkladech. ČAS POTŘEBNÝ KE STUDIU 100 minut. KLÍČOVÁ SLOVA KAPITOLY Objekt, třída, polymorfismus, dědičnost, zapouzdření, překrývání metod. 8 Zdeněk Franěk - Objektové metody modelování v příkladech 1.1 Od strukturálního pojetí k objektovému Strukturální pojetí programování je charakteristické tím, že naprogramovaný kód pracuje přímo s daty. Vývoj programového kódu aplikace byl sestaven strukturovaně. Hlavním rysem analýzy při vývoji aplikace bylo to, že se aplikace dělila na dynamickou funkční část a statickou datovou část. Data byla ukládána v jednotlivých souborech nebo později v relačních databázích. Programový kód byl psán shora dolů s využitím volání funkcí. To na jedné straně zpřehledňovalo programování a na straně druhé zavádělo prvky opakované použitelnosti, tzv. re-use. Při tomto přístupu k programování narůstala složitost programů a používané analytické postupy při návrhu softwaru narážely na velké problémy propojení vrstvy datové a funkční. Výpočty a zacházení se stejnými daty se prováděla na mnoha místech programového kódu a bylo hodně komplikované provádět změny a další přidávání funkcionalit systému. Po zavedení architektury klient - server nastaly další potíže jak správně vyvíjet informační systémy. Strukturální pojetí programo­ vání Z výše uvedených důvodů se v programátorské komunitě ve světě začal používat objektově orientovaný přístup. Jedním z hlavních cílů objektově orientované analýzy, návrhu a programování je další zvýšení produktivity vývojářských prací. [Kan2004] Objektově orientovaný přístup vývoje software je mladší technika navazující na strukturovaný přístup. Tento přístup je založen na objektech. Objekty jsou struktury, které mají definované vlastnosti (atributy) a své chování (operace), které daný projekt může provádět. Informační systém (IS), resp. software takto vyvinutý je chápán jako množina spolupracujících objektů. Tento přístup umožňují programovací jazyky jako je Java, C#, Smaltalk, atd. Návrh - analýza při tvorbě informačních systémů je reprezentována CASE nástroji (Computer Aided Software Engineering) a Unified Modeling Language. Modelovací jazyk U M L je naprosto v souladu s objektovým přístupem. V systémech napsaných pomocí OOM se daleko více uplatňuje znovu-použitelnost. Zavádí se pojmy třída, dědičnost, zapouzdření, komponenty, distribuované objekty a jiné, které oproti strukturálnímu přístupu výrazně zvyšují produktivitu analýzy a programování systémů. [Kan2004] Objektově orientovaný přístup vývoje soft­ ware Definujme si kód: tyto prvky čtou a mění data; jsou to výkonné části informačního systému, provádějí nějakou činnost; mohou to být např. binární programy (či jejich části - moduly, funkce, procedury,...), skripty, triggery. 9 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ CHARAKTERISTIKA DAT Definujme si data: jak proměnné (lokální či globální) držené jen v paměti (po vypnutí počítače se jejich obsah, ale vlastně i jejich samotná existence "ztratí"), tak perzistentní data (soubory, řádky databázových tabulek, apod.) Kód pracuje s daty Charakteristický obrázek 1 - část systému, kde kód pracuje s daty ve strukturovaném přístupu návrhu a naprogramování software: Obrázek 1: Strukturální pojetí - kód a data, zdroj: http://mpavus.wz.cz Tato modelová situace, kdy kód pracuje s daty, přináší různé problémy. Ukážeme si některé z těchto problémů, s jejichž řešením nám může pomoci objektový přístup. Při vývoji IS musíme provádět transformaci požadavků do software, resp. do zdrojového kódu, který pracuje s daty. Nestačí nám prostě namodelovat realitu, ale navíc ji musíme rozdělit na oblast dat a na oblast kódu. Tato transformace nás stojí jisté úsilí, a důsledky této transformace se "nesou" celým dalším vývojem a údržbou IS. 10 Zdeněk Franěk - Objektové metody modelování v příkladech Tento přístup a postup nám ve fázi údržby a následného rozvoje může způsobit daleko větší obtíže, než které jsme si prožili při prvotním vytvoření IS. Vznikají problémy při údržbě a dalším rozvoji IS, pokud chceme přidat/změnit funkcionalitu. Nelze často prakticky zjistit, která data jsou aktualizována kterou funkcí. Navíc daná funkce může vyvolávat další funkce a ty mohou spouštět další funkce, a až v těchto volaných funkcích může být pracováno s určitou oblastí dat. Toto čtení/měnění se může provádět jen za určitých podmínek, jejichž vyhodnocení může být velmi komplikované. Vzniká tak problém při údržbě a dalším rozvoji IS, jak jednoduše zajistit, aby obsah dat byl validní. A další problémy vznikají při ladění a testování programového kódu s lokálními daty (předávanými jako parametr) a globálními daty (měnitelná i bez jejich předávání). V souvislosti s tím vzniká další otázka, jak dokonale ladit a testovat jednotlivé funkce systému, resp. jednotlivé situace v systému, které mohou nastat? Další problémy přináší znovu-použitelnost (re-use). Problémy ve struktu­ rovaném přístupu programo­ vání Na základě výše uvedených problémů při strukturálním přístupu byla vyvinuta IT technologie „Objektově orientovaná analýza a design" pro tvorbu software/informačních sys­ témů. 1.2 Objekt Objekt jako se­ skupení dat a funk­ cionality Objekt je základní abstraktní jednotkou používanou v objektovém modelování. Objekt je seskupením dat a funkcionality, které jsou spolu spojeny za účelem plnění soudržné množiny zodpovědností. Objekt má svou identitu, vlastnosti, chování a zodpovědnost. [Kan2004] Objekt je uzavřený, lokální data jsou obalena metodami, ale ani metody nejsou zvenčí přístupné - jediný způsob, jak použít objekt či jak s ním komunikovat, je poslat objektu 11 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ zprávu. Po zaslání zprávy objekt spustí svou metodu, která může použít atributy objektu a další metody objektu, může také poslat zprávu jinému objektu. Základní pojmy charakterizující objekt byly podrobně popsány v elektronickém učebním textu, viz literatura [Fra2014], proto zde uvádíme jen jejich přehled s odkazem na elearningový kurz k předmětu Objektově orientované modelování: Základní pojmy cha­ rakterizující objekt • Zapouzdření • Metody (chování) • Atributy (lokální data) • Odkaz na jiný objekt: pokud objekt zná odkaz na jiný objekt, může mu poslat zprávu. • Zasílání zpráv SAMOSTATNÝ UKOL J Prostudujte důkladně definici objektu a jeho základní vlastnosti a porovnejte, jakým způsobem popisují různí autoři, viz literatura tohoto učebního textu. ÚKOL K ZAMYŠLENÍ Dva příklady k objektovému myšlení: Objekt je černá skříňka a objekt jako HW, Komponenty, upraveno a inspirováno podle: http://mpavus.wz.cz/oo/ OBJEKT JE BLACK-BOX: Mějme „black-box" s několika tlačítky a kontrolkami. Může to být mobil, televize, automobil, počítač, mikrovlnka. Pro použití některého z objektů potřebujeme vědět, jaké má tento objekt chování a jaké tlačítko mám zmáčknout, aby se objekt zachoval tak, jak právě potřebujeme. V případě mobilu: abych ho uměl zapnout, abych dovedl vytočit číslo, přijmout hovor, uložit své kontakty, abych dovedl zesílit či ztlumit hlasitost. Naprosto mě nezajímá, co je uvnitř. To znamená, že pokud požádám například zmáčknutím příslušného tlačítka o zobrazení kontaktů, mobil to provede. Mobil použije po obdržení zprávy (zmáčknutím tlačítka) 12 Zdeněk Franěk - Objektové metody modelování v příkladech jednu nebo více metod, případně požádá o služby další objekty, které jsou připraveny, tak zvaně „zabaleny", uvnitř v mobilu. OBJEKT JAKO H W : Komponenty personálních počítačů mají výše uvedené objektové vlastnosti. Jednotlivé komponenty (např. paměť, grafická karta, pevný disk, procesor ...) mají chování jako ob­ jekty: Po správném složení a zapojení personálního počítače tyto objekty spolu spolupracují: Jeden objekt požaduje po jiném objektu, resp. jedna komponenta žádá jinou komponentu, o provedení služeb, které tento objekt poskytuje. Výsledkem spolupráce všech objektů je zajištění správné fungování systému. Pokud komponenty počítače správně spolupracují, je to funkční PC. KOMPONENTY Komponenty mají vnitřní paměť, vnitřní metody a lze je skládat. Komponenty jsou podrobně popsány v předchozím elektronickém skriptu [FRA2014], které je nedílnou součástí e-learningového kurzu předmětu „Objektové metody modelování". 1.2.1 TŘÍDA 0DEFINICE Třída reprezentuje šablonu pro objekty a popisuje interní strukturu těchto objektů. Třída obPro návrh objektových systémů se předpokládá, že je třeba navrhnout model tříd objektů jektů je de(Class model), který v podstatě nezobrazuje jednotlivé objekty, ale šablonu (předpis) pro f s w °m an g a trj vytvoření objektů - to je třída objektů. Třída objektů je definována svými atributy a meto- butyamedami. Při návrhu třídy neuvažujeme o konkrétním naplnění atributů, pouze definujeme jejich název a typ. Při vzniku instance objektu (skutečný objekt) se atributům přiřadí skutečné hodnoty. todami 13 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ Diagramy tříd zobrazují static­ kou stránku systému Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. Vztahy, které jednotlivé třídy navzájem pojí, jsou asociace, agregace, kompozice, specializace/generalizace. Podřízenost jednoho objektu vůči druhému je v analýze chápána dvojím způsobem, buď jako agregace, nebo jako kompozice. V obou případech se však jedná o vztah dvou objektů, z nichž podřízený objekt má svou objektovou referenci vloženu do prvního objektu. K detailnímu vysvětlení jednotlivých typů vazeb se dostaneme v následujícím textu. [Kan2004] RESENA ÚLOHA Příklad: V informačním systému evidujícím lékaře máme třídu Lékař s atributy uchovávajícími informace o lékaři (jméno, adresa, atd.) a se dvěma metodami - ty umí ověřit členství lékaře v lékařské komoře a odeslat lékaři e-mail. Na následujícím obrázku 2 je znázorněna třída lékař se dvěma vytvořenými objekty nový lékař (právě zaváděný do systému) a hlavní lékař ČR. > L é k a ř -jméno: string -tituliint -adnesaQ rdinaceiint -datu m Na rozen i: Date -i- OvěrVKomoře()void + OdsĚI" Email () void Nový:Lékař j m éno = "Ja n Vel Íčka" titul = "MVDr." Bdre5aOrdmace = "Haškova 55, Ostrava, 700 3 D" datumNarození = 12.3.1965 Lékař jméno - "Radovan Malý" titul - "MVDr." adresa Ord i nace = "" d atu m N arozen í = 27.3.1965 Obrázek 2 Třída s dvěma vytvořenými objekty (instancemi třídy), zdroj vlastní 14 Zdeněk Franěk - Objektové metody modelování v příkladech 1.2.2 STRUKTURA TŘÍD Struktura tříd je založena na dvou principech, na zodpovědnosti třídy a na zapouzdření třídy. Zopakujme si, co si pod těmito pojmy představujeme. Zodpovědnost třídy je jedním z klíčových faktorů objektově orientované analýzy a návrhu a znamená, že námi definovaný objekt nese zodpovědnost za danou problematiku (tj. „to o čem uchovává informace a chování") a žádný jiný objekt se nesmí „plést do této zodpovědnosti". Dva principy, na kterých je třída zalo­ žena 1.2.3 ZOBECNĚNÍ (GENERALIZACE-SPECIALIZACE), DĚDĚNÍ (INHERITANCE) Zobecnění nám umožňuje další stupeň re-use, resp. znovu-použitelnost nikoliv ve vztahu třída a několik jejích instancí, ale třída a od ní několik odvozených tříd. Pokud namodelujeme několik tříd, které jsou si velmi podobné, mohlo by se jednat o situaci, kde je vhodné použít zobecnění. RESENA ÚLOHA Klasický příklad pro znázornění zobecnění: obecnější třída (předek, nadtřída, bázová třída, předchůdce) se jmenuje tvar a zastupuje nějaký, blíže neurčený dvourozměrný tvar. Tvar má svou barvu čáry, barvu výplně, pozici (pozice těžiště), šířku a výšku, dále má metody nakresli (nakreslí tvar), spočítej Obsah (spočítá plošný obsah) a spočítejPlochuOhraničení (spočítá plochu pravoúhelníku ohraničujícího tvar), viz obrázek 3. Vysvětlení pojmu zobecnění na příkladu 15 ÚVOD DO OBJEKTOVĚ ORIENTOVANÉHO MODELOVÁNÍ Twir -barva Cáry:int -barva Výpl ně: int -pozice: int -šířka:int -výška: int +naknesliO:voicl +srjočítej Ob sabQ: void +spočítej PI odiu Obráni čeníQ: voicl A knih +nal Prodejce «business» Prodejce jméno If n ort pnj mení uži xate Isté Jméno Zakaintk id_zakaz nik : string jmeno : string prijmeni: string adresa : int telefon : decirral e mail: int prihlasen : bool s leva : float +vytvorit_objedravku[|: int +napsat_dotaz[| : bng o bjed rs uka id_zalaznik : string id_objedravky: string datum_prijeti: int spusob_dopravy : string zpusob_platby :string stav : bool 4-potvrd rt_objednavku[| : string •i-zmenit_objedravku():string fuzavrit_objed nav ku(J : strire fzas Et_rrailO : brg Katabjz bozi id_z bozi: string nazev_zboz i: string popE_zbozi: string cena_zbozi: float dostupnost_zbozi : bool Nákupní kosík id_zboz i: string id_objednavky : string mnozstvi:decimal +pridat_zbozi[| : bool +zmenit_mnozstvi[|: dec imal +odebrat_zbce iQ : bool Obrázek 8: Doménový model tříd pro objednávku na e-shopu, zdroj: vlastní 4.4 Model objektové spolupráce Cílem této podkapitoly je naučit se porozumět a vytvořit model objektové spolupráce. Výše j sme ukázali, j ak pomocí analytických tříd můžeme modelovat statickou strukturu systému. Pro identifikaci tříd v systému posloužily vytvořené případy užití. Pro vytváření modelu objektové spolupráce využijeme opět případy užití k tomu, abychom pro ně hledali jejich realizace, tedy takové množiny tříd, které provádějí chování případu užití pomocí vzájemné spolupráce. Jinak řečeno se jedná o převod slovního popisu scénáře případu užití na model interakce identifikovaných tříd. Proces hledání realizace případů užití je soustavným (iteračním) upřesňováním. Přitom procházíme specifikace jednotlivých případů užití a modelujeme způsob, jak požadované chování zajistit pomocí nalezené množiny analytických tříd a jimi poskytovaných operací. Volání těchto operací je zajišťováno systémem předávání zpráv mezi objekty. 41 POPIS IAZYKA UML MODELOVÁNÍ TŘÍD A OBJEKTŮ Pro modelování spolupráce objektů používáme zvláštní typy diagramů, které mají vyjadřovací schopnosti k tomu, aby znázornily, jak mezi sebou objekty spolupracují. Právě interakční diagramy jsou tím nástrojem, který nám pomůže odhalit většinu operací spolupracujících tříd. [Kan004] 4.5 Základní charakteristika a prvky objektového diagramu Objektový diagram (Object Diagram) je snímkem objektů a jejich vztahů v systému v určitém časovém okamžiku. [Buch2007] Je také nazýván diagramem instancí z důvodu, že zobrazuje instance tříd. Používá se především pro znázornění určité konfigurace objektů či zobrazení vzájemně propojených objektů ve speciálních situacích, kdy je diagram tříd či sekvenční diagram nepostačující. [Buch2007]; [Fow2003] Objektový diagram může být chápán jako speciální případ diagramu tříd vytvářený za účelem zdůraznit vazby mezi in­ stancemi. Objektový diagram je užitečný také v počátečních fázích projektu pro modelování ukázek problémové domény, které odhalují objekty a jejich vztahy (viz. Obrázek 9). Často se také používá pro modelování testovacích případů (test cases) pro ověření správnosti diagramu tříd. [Pen2003] Objektový diagram se svou notací velmi podobá diagramu tříd či komunikace a obvykle obsahuje pouze objekty (objects) a spojení (connections) mezi nimi. Atributy se u objektů vyznačují pouze v případě, že je to nutné pro jejich jednoznačnou identifikaci, metody se neuvádějí vůbec, viz [Obj2006]. SAMOSTATNÝ UKOL Vyzkoušejte si tvorbu objektového diagramu na tématu v rámci své seminární práce, využijte k tomu sadu podrobných návodů a doporučení zpracovaných v publikacích [Fra2013], [Arl2008] a [Pen2003]. 42 Zdeněk Franěk - Objektové metody modelování v příkladech 4.6 Příklad objektového diagram object Objektový ioi odejceBoluinil: Piodejce sjednává klientHoiacek: Klient Obrázek 9: Objektový diagram, zdroj: http://uml.czweb.org/diagram_trid.htm SHRNUTI KAPITOLY Tato kapitola vysvětluje pojmy objekty a třídy. Jsou v ní obsaženy doporučení pro jejich vytváření. V této souvislosti byla probrána metodika vytváření objektového diagramu. 43 POPIS JAZYKA UML MODELOVÁNÍ TŘÍD A OBJEKTŮ OTÁZKY Na kterých dvou principech je založena struktura tříd? Vyberte jednu z nabízených možností: a. Zodpovědnost a zapouzdření b. Struktura a metodika c. Název atributu a viditelnost Který z pojmů nevyjadřuje vztah mezi třídami Vyberte jednu z nabízených možností: a. Agregace b. Rekurze c. Asociace Třída je standardní konstrukce UML používaná pro Vyberte jednu z nabízených možností: a. Definování vzorů, z nichž během běhu systému (software) vzniká programový kód b. Definování vzorů, z nichž během běhu systému (software) vznikají objekty c. Definování vzorů, z nichž během běhu systému (software) vznikají události v systému Diagram objektové spolupráce klade důraz především na: Vyberte jednu z nabízených možností: a. Zjednodušený přehled jednotlivých funkcí systému b. Na pořadí jednotlivých událostí c. Kontext a uspořádání spolupracujících objektů 44 Zdeněk Franěk - Objektové metody modelování v příkladech Objektový diagram úzce souvisí s: Vyberte jednu z nabízených možností: a. S diagramem nasazení b. Se stavovým diagramem c. S diagramem tříd ODPOVĚDI a. b. b. c. c. 45 POPIS JAZYKA UML - STA VOVÉ DIAGRAMY 5 POPIS JAZYKA UML - STAVOVÉ DIAGRAMY 5.1 Základní charakteristika Stavový diagram (State Machine Diagram) „zachycuje jednotlivé stavy objektu a přechody mezi nimi." [Buch2007] Stavové diagramy se používají především pro popis chovaní určitého objektu napříč více případy užití a jejich vznik je spojen už s prvními objektově orientovanými technikami. [Fow2003] Stavové diagramy jsou jednou ze známých technik pro zná­ zornění chovaní systému Stavové diagramy jsou jednou ze známých technik pro znázornění chovaní systému. Popisují všechny možné stavy, které může nabývat konkrétní objekt systému, jinými slovy modelují chování objektu napříč všemi případy užití. Zároveň znázorňují, jak se stavy objektu mění v závislosti na událostech, které se ho dotýkají. [Kan2004] V mnoha objektově orientovaných technikách se stavové diagramy kreslí pro konkrétní třídu s cílem zachytit životní cyklus konkrétního objektu. 5.2 Prvky stavového diagramu Základními prvky stavového diagramu jsou stavy, přechody a události, viz obrázek 10. Pokud to CASE nástroj umožňuje, může být diagram ohraničen rámem s názvem objektu. V případě, že se stavy nepohybují v cyklu, měl by diagram obsahovat počáteční (initial state) a koncový stav (finál state). [Arl2008] Stav (state) je dle [Rum2004] „situace v životě objektu, během níž objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost." stm Stavovýdag'am J Ä C Staví událost [podmínka] fclce f S • -I J Ä % J ^ Počáteční Koncový stav äav Obrázek 10: Prvky stavového diagramu, zdroj: http://uml.czweb.org/dia- gram_trid.htm Přechody (transitions) představují podmínky pro přechod objektu z jednoho stavu do druhého. V diagramu jsou značeny linií vedoucí od jednoho stavu k druhému. Jejich popis se skládá ze tří základních částí: událost [podmínka]/ akce. K vykonání uvedené akce a přechodu do dalšího stavu může dojít pouze v případě, pokud je při vzniku události uvedená podmínka (guard) pravdivá. Událost (trigger signatuře) je „specifikací určitého výskytu něčeho v čase a prostoru." [Arl2008] Pokud není v diagramu uvedena, znamená to, že přechod 46 Zdeněk Franěk - Objektové metody modelování v příkladech do dalšího stavu probíhá automaticky. Na obrázku 11 jsou přechody označeny pouze událostmi (např. posuzování zahájeno). [Arl2008]; [Fow2003] 5.3 Doporučení k vytváření stavového diagramu Podrobnější popis doporučení k vytváření stavového diagramu je zpracován v předchozím elektronickém skriptu [Fra2014], které je k dispozici studentům předmětu „Objektové metody modelování" na e-learning portále SU v rámci připraveného kurzu. SAMOS TA TNÝ ÚKOL Podle literatury [Fra2014], [Sta2006] a [Arl2008] vypracujte návod a doporučení pro vytváření stavových diagramů. Získané poznatky aplikujte na svůj příklad stavového diagramu v rámci seminární práce. 47 POPIS IAZYKA UML - STA VOVE DIAGRAMY 5.4 Příkladový stavový diagram i Stav ou ý d ag"am smlo uvy ^Rozprat CC eh ^ j i •: i na "*[ záh áj posouzení J o pravé ný C POSUZOJariý-/ návrh len schválen s po dmi nkou \ S c r w álený s ť Z a m ŕ t r i i _ i ý " \ nír+í <="_i 4Neuzavře Smlou.1 a ^ Kortrolovará ~ ^ n a ] ^ * e , C zá pi s<_i d)o E RP Obrázek 11: Stavový diagram, zdroj: http://uml.czweb.org/ SHRNUTI KAPITOLY V této kapitole byl popsán stavový diagram. Na příkladově je vysvětlen princip a smysl stavového diagramu. 48 Zdeněk Franěk - Objektové metody modelování v příkladech OTÁZKY K čemu slouží stavový diagram Vyberte jednu z nabízených možností: a. Modeluje chování objektu pro některé případy užití b. Popisují některé stavy, které může nabývat konkrétní objekt systému c. Znázorňují, jak se mění stavy objektů v závislosti na událostech Stavový diagram obsahuje prvky Vyberte jednu z nabízených možností: a. Start, stop, stav b. Start, stop, příkaz c. Start, stav, rozhodnutí Kolik může být symbolů Start ve stavovém diagramu Vyberte jednu z nabízených možností: a. Více b. Právě jeden c. Dva ODPOVĚDI c. a. b. 49 POPIS JAZYKA UML DIAGRAMY AKTIVIT 6 POPIS JAZYKA UML - DIAGRAMY AKTIVIT RYCHLÝ NÁHLED KAPITOLY Tato kapitola objasňuje princip diagramu aktivit. CÍLE KAPITOLY Cílem je porozumět a naučit vytvářet diagram aktivit CAS POTREBNÝ KE STUDIU 90 minut KLÍČOVÁ SLOVA KAPITOLY UML, diagram aktivit, 6.1 Základní charakteristika diagramu aktivit Diagram aktivit (Activity Diagram) je typem diagramu interakcí, který se používá pro popis procedurální logiky, byznys procesů či pracovních postupů. Umožňuje také graficky modelovat jednotlivé případy užití jako posloupnost akcí. [Fow2003] [Arl2008] Diagramy aktivit představují pravděpodobně nej obtížnější část jazyka UML. Jsou užitečné zejména tím, že dovolují popisovat chování, které má charakter paralelního zpraco­ vání. 50 Zdeněk Franěk - Objektové metody modelování v příkladech Diagram aktivit (Activity diagram) zobrazuje sekvenci činností, které podporují jak sek- ^ctivity di­ agram venční, tak paralelní chování. Diagram aktivit je v podstatě variantou stavového diagramu, zobrazuje Diagramy aktivit modelují procesy jako kolekce aktivit a přechodů mezi nimi. Vzhledem k tomu, že diagramy aktivit j sou určeny zejména pro komunikaci s lidmi se znalostí struktury obchodních a podnikových procesů, měla by být dostatečně přehledné. [Kan2004] sekvenci činností 6.2 Prvky diagramu aktivit DEFINICE Df Diagram aktivit modeluje procesy jako aktivity, které se skládají z uzlů (nodes) vzájemně propojených hranami (edges), viz obrázek 12. [ARL2007] m typy Existují tři typy uzlů - akční uzly, které reprezentují samostatné a v rámci aktivity neděuziudia- Htelné jednotky, řídící uzly, jejichž úkolem je řídit cestu uvnitř aktivity a uzly objektové, gramu aktivit které zastupují objekty. Nej používanějším akčním uzlem je tzv. call action node, který inicializuje aktivitu, chování či operaci. Příkladem řídících uzlů jsou počáteční (initial nodes), konečné uzly (finál nodes) nebo uzly rozhodnutí (decision nodes). [Arl2008] Uzel rozhodnutí má jednu vstupní hranu a několik konkurujících si hran výstupních. Daný výstup bude zvolen podle toho, která ze vzájemně se vylučujících kontrolních podmínek bude splněna. K označení hrany, která bude použita, pokud nebude splněna žádná kontrolní podmínka, se používá klíčové slovo jinak (else) [Fow2003], [Arl2008]. Uzel sloučení (merge) může mít několik vstupních, ale pouze jednu výstupní hranu. Používá se především pro sjednocení větví diagramu aktivit, které byly předtím rozděleny uzlem rozhodnutí [Arl2008]. 51 POPIS JAZYKA UML DIAGRAMY AKTIVIT act Oagram aktvit y hrana Počáteční uzel Akčríuzel Lbe Irozhodn uťi/d ou cení U:e I rozvětvení/spoj ení Kone čný u ze I 0 Objektwý ucel Obrázek 12: Prvky diagramu aktivit, zdroj [ARL2007] Procesy, které diagram popisuje, mohou probíhat paralelně, což je umožněno řídícími uzly rozvětvení (fork) a spojení (join) [Fow2003]. Pro zpřehlednění se může diagram rozdělit například dle rolí či organizačních jednotek do tzv. zón odpovědnosti či plaveckých drah (swimlanes) [Arl2008]. 6.3 Doporučení k vytváření diagramu aktivit Podrobnější popis doporučení k vytváření stavového diagramu je zpracován v předchozím elektronickém skriptu [Fra2014], které je k dispozici studentům předmětu „Objektové metody modelování" na e-learning portále SU v rámci připraveného kurzu. SAMOSTATNÝ ÚKOL Podle literatury [Fra2014], [Act2006] a případně i další literatury si sestavte pravidla pro vytváření diagramů aktivit. Tento návod aplikujte při kreslení diagramu aktivit ve své seminární práci. 6.4 Příklady diagramů aktivit Příkladový diagram v rámci případové studie znázorňuje chování systému e-shopu při tvorbě objednávky zákazníkem. Diagram prezentuje činnost zákazníka e-shopu od vstupu na stránky při tvorbě objednávky. Proces objednávání obsahuje vyhledání zboží, prohlížení popisu zboží a postupy při jeho zakoupení. Zákazník - uživatel e-shopu si zboží prohlíží, a pokud si ho vybere, přidá ho do nákupního košíku. Tento proces přidávání zboží opakuje uživatel tak dlouho, dokud nemá v košíku všechno zboží. Samozřejmě při procesu vkládání do košíku může volit množství, přednastavená hodnota počtu kusů je 1. Systém si před přechodem k dokončení objednávky zkontroluje, zda zákazník je přihlášen a má aktivovaný 52 Zdeněk Franěk - Objektové metody modelování v příkladech slevový VIP program. Pokud ano, tak systém upraví cenu. Následně je vyzván k vyplnění (v případě neregistrovaného zákazníka) nebo potvrzení (přihlášený zákazník) platebních, dopravních a doručovacích údajů. Následně je objednávka odeslána a systém zašle potvrzovací e-mail a na základě zvolené metody platby odešle zboží zákazníkovi. 53 POPIS JAZYKA UML DIAGRAMY AKTIVIT 9 _ Vstup na stránky E-shopu^ ^Hledat zboží^j ^Prohlížet zboží^ Přidat? Ano ^Zadat množstvy ^Přidat clo košíku^ Vše? Ano VIP program 1 I Nákupní košík - ^ ^ U p r a v e n í ceny^ Způsob platby a dopravy D ^Odeslání objednávky^ Obrázek 13: Diagram aktivit - zákazník nakupuje na e-shopu, zdroj vlastní zpraco­ vání 54 Zdeněk Franěk - Objektové metody modelování v příkladech Druhým příkladem složitějšího diagramu aktivit je případ ocenění vozidla, viz obr. 14. C I f H M r i J VjftH-il lan M - i r í -> " v add* - j n í l 3 l - i . C TTIr J rh- i m I-c"_L .' y - -••ja op™ hip n i v + i c |fl'IM iTl I i1 .1 J c X . n J n.4 TJ L i . • •J •• r-l.l •TJTLF vm kí-n-o-ůl*-1 2 ÍN + hl IfTrO'.1 i t I m J - s w u IF Pjj M iruŕ -Ú Obrázek 14: Diagram aktivit ocenění vozidla, zdroj: vlastní 55 POPIS JAZYKA UML DIAGRAMY AKTIVIT SHRNUTÍ KAPITOL Y V této kapitole byla probrána metodika vytváření diagramu aktivit. Na příkladech byly vysvětleny základní pojmy a způsob využití diagramu aktivit. OTÁZKY Diagramy činností se používají pro Vyberte jednu z nabízených možností: a. Vyjádření dynamického chování modelu b. Vyjádření statické struktury modelu c. Vyjádření vztahu mezi uživateli a systémem Které tvrzení o diagramech činností je pravdivé? Vyberte jednu z nabízených možností: a. Diagram činností je není vybaven pro větvení dle podmínek a zachycuje jen paralelní zpracování b. Diagram činností je vybaven pro větvení dle podmínek a zachycuje paralelní zpraco­ vání c. Diagram činností je vybaven pro větvení dle podmínek, ale nezachycuje paralelní zpra­ cování 56 Zdeněk Franěk - Objektové metody modelování v příkladech Diagramy činností patří mezi diagramy Vyberte jednu z nabízených možností: a. Statické struktury systému b. Dynamického chování systému c. Žádná z uvedených dvou možností Diagramy činností podporují Vyberte jednu z nabízených možností: a. Jen paralelní chování b. Jen sekvenční chování c. Jak sekvenční, tak i paralelní chování ODPOVĚDI a. b. b. c. 57 SEKVENČNÍ DIAGRAM 7 SEKVENČNÍ DIAGRAM «3> RYCHL Ý NÁHLED KAPITOL Y Tato kapitola objasňuje princip sekvenčního diagramu. CILE KAPITOLY Cílem je porozumět a naučit vytvářet sekvenční diagram. [0 ČAS POTŘEBNÝ KE STUDIU | 90 minut H KLICOVA SLOVA KAPITOLY Sekvenční diagram, UML, 7.1 Základní charakteristika a prvky sekvenčního diagramu sekvenční Stavové diagramy pracují se stavy objektů. Popis stavů ovšem neřeší všechno. Proto v ja- diagram popisuje, zyku U M L existuje další prostředek - diagram sekvencí, který popisuje, jak spolu objekty jak spolu v č a s e komunikuj í. [Sch2001 ] objekty komunikují v čase Sekvenční diagram nejčastěji zobrazuje chování a spolupráci jednotlivých objektů v rámci jednoho případu užití. Pro popis chování jednoho objektu napříč více případy užití se používá stavový diagram. [Fow2003] Sekvenční diagram (Sequence Diagram) je nejvíce používaným diagramem interakcí. „Zachycuje grafický průběh zpracování v systému v podobě zasílání zpráv." [Buch2007] 58 Zdeněk Franěk - Objektové metody modelování v příkladech PRVKY DIAGRAMU Diagram sekvencí (sekvenční diagram) se skládá z objektů zakreslených běžným způso- D i a a r a m bem (jako obdélníčky s podtrženým jménem), ze zpráv zakreslených jako plné šipky seskiádá a z času, který je znázorněn vertikálním postupem v diagramu. [Kan004] Zprávy mohou být z o b J e k t ů , zpráv a v sekvenčním diagramu posílány jak mezi jednotlivými objekty, tak i třídami či dokonce znázornění aktéry. Proto se prvky, které mezi sebou v diagramu komunikují, nazývají souhrnně klasifikátory (classifiers). [Buch2007] Z každého klasifikátoru vede tzv. čára života (lifeline), která reprezentuje, jakým způsoben se instance určitého klasifikátoru účastní interakce. [Arl2008] casu 7.2 Doporučení k vytváření sekvenčního diagramu Dle literatury [Seq2006], [Arl2008], [Buch2007] platí pro sekvenční diagram celá doporučení a návodů, například že aktéři by měli být pojmenování stejnými názvy jako v usecase diagramu. Podrobně byla pravidla vytváření sekvenčních diagramů zpracována v učebním textu [Fra2013], který je k dispozici na e-learning portálu v rámci kurzu „Objektové metody modelování". SAMOS TA TNÝ ÚKOL Podle literatury [Seq2006], [Arl2008], [Buch2007] a [Fra2014] si sestavte pravidla pro vytváření sekvenčního diagramu. Tato pravidla aplikujte při kreslení diagramu aktivit ve své seminární práci. 59 SEKVENČNÍ DIAGRAM 7.3 Příkladový sekvenční diagram Pro hl cťt zboží Ha kúpni košik Uda p o za ka z n ikovi Q biedna vka Qdesbt zboz i I hledatzboži I X, — fJU na lezeno í i i prohlížet zboži I i. ^ přidá t do košiku pridá no do pra va/pb t ba j i i i i i i i zaslat e-mail o objednávce . J L . I I I I I I I I I _ L F'otvrd ŕt o bjed nav ku * za pbtŕt za pb ceno odeslat z bozi Obrázek 15: Sekvenční diagram popisující nákup zboží na e-shopu neregistrovaným uživatelem, zdroj: vlastní 60 Zdeněk Franěk - Objektové metody modelování v příkladech Registrovaný uživatel Přihlášení Autorizace Hledat zboží Nalezeno Prohlížet zboží Zobrazeno Přidat do košíku Přidáno Uplatnit slevu uplatněno způsob platby a dopravy Potvrdit objednávku zaslat e-mail o objednávce Zaplatit za zboží Odeslat zboží E-shop Obrázek 16: Sekvenční diagram popisující nákup zboží na e-shopu registrovaným uživatelem s uplatněním slevy, zdroj: vlastní SHRNUTÍ KAPITOL Y V této kapitole byla probrána metodika vytváření sekvenčního diagramu. Na příkladech byly ukázány základní prvky diagramu tak, aby studenti byli schopni za využití literatury sestavit sekvenční diagram. 61 SEKVENČNÍ DIAGRAM OTÁZKY Sekvenční diagram a diagram objektové spolupráce znázorňují Vyberte jednu z nabízených možností: a. USE CASE - případ užití b. Statickou strukturu systému c. Jak spolu objekty spolupracují Jak se v sekvenčním diagramu vyznačuje zpráva? Vyberte jednu z nabízených možností: a. Šipkou s vyplněným hrotem b. Šipkou s polovinou hrotu c. Jednoduchou šipkou Jak se v sekvenčním diagramu zobrazuje čas? Vyberte jednu z nabízených možností: a. Vertikálně b. Nezobrazuje se c. Horizontálně zleva doprava 62 Zdeněk Franěk - Objektové metody modelování v příkladech Sekvenční diagram vystihuje tvrzení. Vyberte jednu z nabízených možností: a. Zobrazení funkcionality systému b. Zobrazení objektů v čase c. Zobrazení vzájemných vztahů objektů ODPOVĚDI c. a. a. b. 63 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI 8 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI RYCHLÝ NÁHLED KAPITOLY Kapitola dává přehled software, který se používá, resp. je dostupný na trhu. Jistě existuje celá řada software produktů, které umožňuji konstrukci U M L diagramů. Zde jsou vytipovány tři základní produkty s jejich popisem funkčnosti. CÍLE KAPITOLY Cíl kapitoly dát přehled o nejčastěji používaných sw produktech a v případě SW Enterprise Architect dát podrobnější návod k jeho ovládání. ČAS POTŘEBNÝ KE STUDIU 180 minut KLÍČOVÁ SLOVA KAPITOLY Software, U M L diagramy, objektový orientovaný návrh SW. 8.1 IBM Rational Software Development Platform Case nástroj firmy IBM pro podporu vývoje aplikací zahrnuje všechny možné nástroje od popisu firemních procesů až po kreslení diagramů UML. Je určen pro týmovou práci při řešení rozsáhlých projektů vyvíjejících informační systém. 64 Zdeněk Franěk - Objektové metody modelování v příkladech Obrázek 17: IBM Rational Development Platform Týmová práce při vývoji software, zdroj: vlastní (printscreen) Tento software od firmy IBM byl nainstalován na serveru počítačové sítě SU OPF. Vzhledem k jeho vysoké ceně fakulta vlastní pouze jednu licenci pro demonštratívni účely ve výuce. 65 */ R e q u i r e m e n t - U s e L o s e " l o d e L l n s t r u c t i o n s 1 I B M R a t i o n a l S o f t w a r e D e v e l o p m e n t P l a t f o r m Fi t Edit Navigace bťdn.li Project Diagram Modeling Run Window Help ] r v ca j á J Í L \ % • J 4> J • <^ - - Jffjx) I H B - H - I "3 5§ I [5^Requirement [^.Modeling älExplo... p j j D i a g r a m Na.. H i' \ Architectural Discovery H ^ My Diagrams É-IČ3 Miscellaneous Model? 3 Use Case Model,ems . Use Case Modell.ernx "i Use Case Model Pokusí.emx H - - ^ Use Case Model Pokusil.emx • My Topic Diagrams t3 Miscellaneous Models ".S Use Case Model.em* °0S Use Case Model 1. emx ^ Use Case Model Pokusí.emx [+]...-[£]• use Case Model Pokusil.emx Í3- *Use Case Model Pokusil.emx Evidence záručního listu >S-H > CO o O D- O — •OJ > >N o >N ' ô 1 O S » S t a r t | J j g I \§i Seznam Slovník - templat... | [ ( t ) R e q u i r e m e n t - U s e C a . . . Zdeněk Franěk - Objektové metody modelování v příkladech 8.2 ENTERPRISE ARCHITECT firmy SPARX Velmi používaný program pro kreslení U M L diagramů je Enterprise Architect firmy Sparx. Program je běžně využíván pro výuku pro transparentnost, přehlednost a poměrně jednoduché ovládání. Obrázek 19: Vývojové prostředí Enterprise Architect firmy Sparx - CLASS DIAGRAM, zdroj: vlastní s využitím software Enterprise Architect NÁVOD K OVLÁDÁNÍ PROGRAMU Firma Sparx umožňuje klientům a tedy i studentů stáhnout 100 denní Trial verzi. EA firmy Sparx je ideálním CASE nástrojem, ve srovnání s Rational IBM Architect je nepoměrně levnější a ve srovnání s šablonami na podporu U M L v MS VISIO je to komplexní CASE nástroj. 67 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI VYTVOŘENÍ PROJEKTU Projekt je tvořen jedním souborem nebo slouží jako úložiště pro jeden nebo více modelů. Prvním krokem je buď otevřít existující projekt, nebo vytvořit nový projekt. V tomto příkladu vytvoříme projekt založený na jednom souboru a přidáme některé modely založené na šablonách. Vytvoříme jednoduchý Use Case diagram, který budeme dále přizpůsobovat našim požadavkům. Kdykoliv můžeme znovu otevřít proj ekt, když na něj poklepneme v prohlížeči souborů. Objeví se také v našem seznamu Současné projekty (Recent Projects) na úvodní stránce (Start Page). VYTVOŘENÍ NOVÉHO PROJEKTU: 1. Nastartujeme Enterprise Architect Zobrazí se pracovní prostředí E A a dialog „Manage Projects" správy projektů se seznamem dříve použitých projektů, viz obrázek 20. Můžeme tak pokračovat v práci na již vytvořených projektech nebo si otevřít ukázkový projekt EAExample. Okno zavřeme. 2. Klikneme na tlačítko nový project (New File) a vybereme vhodné jméno a umístění nového projektu. ® ' 1 1 D e s i g n ut Publish Cc nfigure Construct Code Extend Q Find Command,,. r3 I © Window Browser Navigato Show Model Views My Kanban Active Diagrams Notes Document 1 B Manage r n • n . v i u . i s w . Perspectives Views Preferences ' Workspace i p i Home Page r3 I © Window Browser Navigato Show • Element Browser Resources • MyGantt < \ Active Elements n Summary • Relationships • My Work Sets. Qy Active Tasks O Properties • Tagged Value Today Windows 1 B Manage r n • n . v i u . i s w . Perspectives Views Preferences ' Workspace Help Project Browser = Open Project,.. ^ * x T o o l b o x Notes • * E I U £ - I IE iE I x* * , & | B > Artifacts Obrázek 20 Vytvoření nového projektu v Enterprise Architect, zdroj vlastní 68 Zdeněk Franěk - Objektové metody modelování v příkladech Otevře se standardní dialogové okno prohlížeče souborů Windows, soubory mají příponu .eap Projekt pojmenuje například newproject a soubor uložíme. Enterprise Architect vytvoří nový soubor projektu a uloží ho na určeném místě. Od této chvíle se celý projekt bude ukládat do souboru newproject.eap. Po uložení se nám otevře průvodce Model Wizard a zašktrtneme políčko Use Case, viz obrázek 21. 1 ü d e l P a t t e m s I Add to Package Model • I Customize Pattern on import Technology Name Core M o d e l i n g B P M N A : U M L 2 Business Database Use Case Business Database "E • Domain M o d e l Software i • Class Services f ] • C o m p o n e n t Frameworks El • Deployment NIEM Á : Extensions Others • • Dashboard: Issues and Defects Business Process D Z • Requirements • Testing • M a i n t e n a n c e • • Project M a n a g e m e n t • • User Interface Á : Views D Z • Requirements D Z • Analysis V i e w System behavior described with Use Cases and Actors Obrázek 21 Model Wizard EA s volbou Use Case, zdroj vlastní 69 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI Průvodce (Model Wizard) automaticky vytvoří pro nás nový „Use Case Model", který vidíme v Proj ect Browser na levé straně vývojového prostředí, viz obrázek 22. Rozbalíme pomocí šipek model a dostáváme Use Case Model, Actors a Primary Use Cases. Window Browser Navigator Search Show Explore Project Browser = Use Casel A H Model A @ Use Case Model ft Use Case Model A & Actors l | Actors A & Primary Use Cases 1% Primary Use Cases f> O UseCasel O UseCas.e2 Notes B / U ü • - t v My Kanban Active Diagrams er • My Gantt Q± Active Elements n MyWorkSet! Active Tasks Toolbox Document Relationíhipí Tagged Values Windows B I C Visual Style Full Screen Preference? F- Common p- Artifacts •ige Obrázek 22 Vytvoření Use Case Modelu, zdroj vlastní zpracování NAKRESLENÍ U S E C A S E Doubleclick na Use Case Model - otevře se nám ukázkový diagram Use Case, viz obrázek 23. Na obrázku je připraven důkladný návod a popis Use Case diagramu, balíčky Actors a Primary Use Case, viz též Project Browser. 70 Zdeněk Franěk - Objektové metody modelování v příkladech I B A i i l i j H t l i h B U Model View 1 Report Sp.cifiatmn |=| Matrix Specifkation H| Executable StatsMachire H| SysMLSim Ccnfiguration 1 ln,a D e Attrt |=| Reading Li st Obrázek 23 Ukázkový Use Case Model, vlastní zpracování PŘIDÁNÍ PRVKŮ DIAGRAMU POMOCÍ PANELU NÁSTROJŮ V podokně Toolbox máme připravené kreslící nástroje pro kreslení diagramu. Pokud Toolbox není vidět, aktivujeme ho kombinací kláves Alt+5. Metodou drag and drop přetáhneme ikonu Actor a dvakrát Use Case. Po přetažení se nám na pracovní ploše EA objeví příslušné obrázky Actorl a Use Casel a Use Case2. Při každém přetažení objektu se nám vysvítí příslušné okno s vlastnostmi. Ty mohu dle potřeby vyplnit, tedy pojmenovat Actory a Use a zejména u Use Case ve vlastnostech je textové pole pro zadání scénáře. Podobně přetažením myši vytvoříme asociaci mezi Actorl a Use Casel a Use Case2,viz obrázek 24. Pro vytvoření asociace můžeme využít i jiný postup. Po kliknutí na Actorl se nám objeví pomocné navigační symboly, viz obrázek 25. Zatím jsme ponechali vzorové návody a balíčky na obrazovce. Ty můžeme j ednoduše odstranit. ODSTRANĚNÍ PRVKU Odstranění prvku s pracovní plochy E A provedeme jednoduše tak, že prvek označíme myší a zmáčkneme klávesu DEL. Prvek v Prohlížeči projektu můžeme mít ve více diagramech v rámci celého projektu. Pokud prvek odstraníme z diagramu pomocí klávesy Delete, nebude automaticky odstraněn odpovídající prvek v celém Prohlížeči projektu. Toho dosáhneme kombinací kláves CTRL + DEL. 71 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI Poznámka: Po stisknutí Ctrl + Delete budeme vyzváni k potvrzení odstranění a budeme varováni, že operaci nelze vrátit zpět. Toolbox x « Še Use Case Diagram: "Use Case Model" More tools.. £ g *Use Case Model X J Use Case £ Actor O Use Case Q£ Test Case •••Ofr Collaboration \# Collaboration Use Q Boundary F*i Package ^ Use Case Relationships / / / 7 7 J Use Case Patterns <*j\ Basic Use Case J Common I 1 A E 1 % 1 B 6 Artifacts H_ Artifact |5] Document Encrypted Document H_ Checklist H_ Audited Checklist § Review |5] User Story H_ Working Set H Standard Chart 8 Time Series Chart H Model View =| Report Specification [=| Matrix Specification TxThe Use Case model's a cata oaxecf system funcrionarrty described using LML Use Cases. Bach Use Case represents a single, repeatable interaction that a user or 'actor1 experiences when using the system. A UseCasetypicalry includes one or more •scenarios' whcti describe the intenactiorks that go on between the Actorand the System, a nd documents the results a nd exceptions that occur tr : "• f = = =' i £•= '= c = it •/ =. Use Cases may Include other Use Cases as part of a larger patten of Interaction and may a to be extended by other use cases to handleexceptionalconditions RB3S abOLt US? Ľ3SB MOE? rg -•= = : = c- Lt Actes View Further Exa mples Primary Use Cases + US? 231-91 Obrázek 24 Kontextový Toolbox a přidávání prvků Use Case diagramu, zdroj vlastní POUŽITÍ QUICKLINKERU Použitím Quicklinkeru můžeme rychle vytvářet vztahy mezi stávajícími prvky bez použití Toolboxu. Po kliknutí na Actérl se nám objeví příslušné konektory, viz obrázek 25. Jednoduše přetáhneme šipku Quicklinkeru na požadované místo a pomocí menu vytvoříme prvek nebo konektor. Kontextové menu obsahuje nejběžnější prvky a konektory pro daný dia­ gram. 72 Zdeněk Franěk - Objektové metody modelování v příkladech A A I í? Aclorl ^ Obrázek 25 Quicklinker - šipka, zdroj vlastní zpracování EA, zdroj vlastní V našem případě přidáme „Use Case 3" a smažeme všechny návody a pomocné balíčky, viz obrázek 26. Browser Navigat Element Brcwsei Project Browser ] Model H Use Case Model J | Use Case Model A & Actors SS Actors Use PrimaryUse Cases S§ Primary Use Cases > OUseCasel O UseCaseZ £ Actorl $ Actorl $ ActorS • Use Casel • UseCase2 O Use Case3 • :Actor1 Notes n Mytonban I A • My Gantt <\ A • MyWorkSets <\ A Toolbox Relatio Tagged on UssCaw O Use Case G ' Test Case •:Ž5 Collaboration Q:- Collaboration Use • Boundary Q Package Use Case Relationships / ŕ / / ä LseCase Patterns - J Basic Use Casi 1 I A iE B ^ IS 1 E ft & §1 Artifact Document Encrypted Document Pj Checklist Pj Audited Checklist [^1 Review |S| User Story §1 Working Set H Standard Chart B Time Series Chart g Model View =| Report Specification |B) Matrix Specification Pi Executable StateMachin J] SysMLSim Configurator =] Image Asset =| Reading List Use Case Diagram: "Use Ca; Register Help Obrázek 26 Vytvoření asociace pomocí Quicklinkeru, zdroj vlastní 73 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI 8.3 UML A VISIO firmy MICROSOFT Šablona diagramu modelu U M L aplikace Microsoft Office Visio nabízí podporu vytváření objektově orientovaných modelů. Diagram případu použití Diagram statické struktury - diagram tříd Diagram činnosti Stavový diagram Sekvenční diagram Diagram komponent Diagram zavedení Šablony MS VISIO pro U M L vyhledáme zadání hesla U M L diagramy do vyhledávání šablon a poté vybereme příslušný diagram, viz obrázek 27. a x PPhlásitse Nový ô Domů UML diagramy Diagram sekvence UML LU Diagram případu použití UML Diagram činnosti UML Statická struktura UML Kategorie Software Diagram stavového stroje UML Obrázek 27 Vyhledání šablon na podporu U M L diagramů, zdroj vlastní v MS VI­ SIO Program VISIO je dostupný studentům Obchodně podnikatelské fakulty na počítačových učebnách, s šablonou diagramů U M L na PC učebně, kde probíhá výuka předmětu „Objektové metody modelování. 74 Zdeněk Franěk - Objektové metody modelování v příkladech Pro řešení seminární práce, kterou studenti dle sylabu předmětu „Objektové metody modelování" musí vytvořit je podpora U M L v MS VISIO postačující. Ideální prostředek pro řešení pokročilejších projektů jsou však výše uvedené CASE nástroje. Návody na použití těchto šablon je nad možnosti rozsahu tohoto textu, ovládání je intuitivní, s využitím znalostí ovládacích postupů v MS OFFICE. Prostředí a vzhled obrazovky šablony pro USE Case je na následujícím obrázku 28: H *}- | |J7Q| |2M |2M |300| |j10 |S201 |Tj Stránka-1 Vše * © 5tránka 1 z 1 Čeština 1JJJJJ 1 + 101% H ES | SS P o M u -) " i • »1 ŕ - 1 4 5 0 % " 27.05.2013 TS) Obrázek 28 Printscreen prostředí kreslení USE CASE v MS Visio, zdoj vlastní zpracování v MS VISIO SHRNUTÍ KAPITOL Y V této kapitole je uveden přehled software pro vytváření diagramů U M L a využití metodiky RUP. Zvláštní pozornost je věnována software ENTERPRISE ARCHITECT firmy Sparx. S tímto software počítáme do budoucna jako nej důležitější a počítá se pořízením minimálně dvaceti plovoucích licencí. Software IBM Rational Architect je dostupný ve verzi z roku 2008 přes „tenký klient" CITRIX. Tento software bude pouze demonštratívni s využitím postupů RUP. Software VISIO obsahuje několik základních šablon pro kreslení U M L diagramů. Je postačující pro psaní seminárních prací, pro psaní bakalářských a diplomových prací bude nutno použít EA. 75 PŘEHLED SOFTWARE PRODUKTŮ PRO PRÁCI SAMOSTATNÝ ÚKOL 1) Nainstalujte si software Enterprise Architect firmy Sparx, trial verzi na 10 dnů a vyzkoušejte si nakreslit diagramy uvedené v tomto skriptu. 2) Vyzkoušejte vzdálený přístup přes V M Ware software k programu Visio a vyzkoušejte si nakreslit diagramy v tomto skriptu KONTROLNÍ OTÁZKA Který ze software Visio a Enterprise Architect firmy Sparx umožňuje z diagramů generovat programový kód? 76 Zdeněk Franěk - Objektové metody modelování v příkladech 9 RUP - RATIONAL UNIFIED PROCESS RYCHLÝ NÁHLED KAPITOL Y Tato kapitola seznamuje s metodikou vytváření informačních systémů s názvem Rational Unified Process (dále RUP). CILE KAPITOLY Cílem kapitoly je vysvětlit metodiku RUP. CAS POTREBNÝ KE STUDIU 120 minut KLICOVA SLOVA KAPITOLY RUP, metodika, informační systém, vývoj sw, iterace, správa požadavků, komponenta, zahájeni, inception, příprava, elaboration, konstrukce, construction, předávání, transition E LUMetodika RUP (ko­ merční produkt) a UP (obecná metodika) PRŮVODCE STUDIEM Metodiku Rational Unified Process Rup (RUP) vytvořila společnost „Rational Software Corporation". Tato metodika byla distribuována formou softwarového produktu, který převzala i se společností v roce 2003 firma IBM. Nynější podobu metodiky a její realizaci pomocí software najdete na stránkách http//www.ibm.com - do vyhledání na stránkách nutno zadat slovo „rational". Nutno poznamenat, že RUP je komerční produkt na rozdíl od obecné metodiky Unified Process. 77 RUP - RATIONAL UNIFIED PROCESS Metodiku RUP názorne ilustruje grafické znázornění disciplín a fází projektu na obrázku 29: Fáze projektu Zahájení Příprava • Konstrukce * Předávání Tvorba podnik, modelu Správa požadavků Analýza a návrh i Implementace 1 1 1 1 •i i Testování Nasazení Konfigurace a změny i i 1 i i i : : : • i i • L ^ ' ~ 1 . Řízení projektu i i i Správa prostředí 1 P 1 1 1— 1 Správa prostředí Z1 PZ1 PZ2 T1 T2 T3 TN P1 P2 Iterace Obrázek 29: Schéma projektu dle metodiky RUP, zdroj: [Arl2008] Pro modelování procesů v ži­ votním cyklu projektu se využívá UML Pro modelování procesů v životním cyklu projektu - vývoje informačního systému se využívá diagramů jazyka Unified Modeling Language (UML). Metodika RUP byla popsána v předchozím učebním textu [FRA2014]. Tento učební text obsahuje komplexní popis metodiky RUP, resp. UP a bude nedílnou součástí e-learningového kurzu k výuce předmětu „Objektové metody modelování". SHRNUTI KAPITOLY Tato kapitolaje věnována popisu metodiky tvorby informačních systémů. Samotné UML se svými diagramy nejsou metodikou. Ty metodice pomáhají při tvorbě software. Veškeré studijní materiály o metodice RUP a srovnání s UP jsou obsaženy v [FRA2014]. 78 Zdeněk Franěk - Objektové metody modelování v příkladech OTÁZKY Zkratka UP znamená Vyberte jednu z nabízených možností: a. Unified process b. Unified program c. Universal process Co je UP? Vyberte jednu z nabízených možností: a. Soubor typových řešení iterativní metodologie vývoje SW resp. IS b. Objektově orientovaná iterativní metodologie vývoje SW resp. IS c. Jiný název pro U M L diagramy Axiomem metodiky UP není Vyberte jednu z nabízených možností: a. Zásada řízení případem užití a rizikem b. Zásada soustředění na programování c. Zásada iterace a přírůstku Pět základních pracovních postupů (workflow) Vyberte jednu z nabízených možností: a. Plánování, Analýza, Návrh, Implementace, Testování b. Analýza, Návrh, Programování, Implementace a Testování c. Požadavky, Analýza, Návrh, Implementace a Testování 79 RUP - RATIONAL UNIFIED PROCESS Fáze metodiky UP jsou Vyberte jednu z nabízených možností: a. Milník, Fáze, Iterace a Zavedení b. Zahájení, Konstrukce, Zavedení a Testování c. Zahájení, Rozpracování, Konstrukce a Zavedení Software jev metodice UP vytvářen v iteracích Vyberte jednu z nabízených možností: a. Každá iterace je mini projekt b. Iterace jsou skládány jedna za druhou, ale nemají vliv na konečnou podobu systému c. Iterace jsou aplikovány jen na celý projekt Každá iterace generuje Vyberte jednu z nabízených možností: a. Baseline b. Přírůstek programového kódu c. Helpline Tvrzení "Pro každý nový projekt tvorby SW je třeba vytvořit novou instanci metodiky UP" je pravdivé Vyberte jednu z nabízených možností: a. ANO b. Někdy ANO někdy N E - záleží na použití metodiky UP c. NE 80 Zdeněk Franěk - Objektové metody modelování v příkladech Metodika UP a RUP se liší Vyberte jednu z nabízených možností: a. Sémantikou elementů jednotlivých metod b. Jsou to úplně odlišné metodiky o RUP vykazuje určité terminologické a syntaktické odlišnosti Metodika UP a RUP jsou rigorózní nebo agilní? Vyberte jednu z nabízených možností: a. agilní i rigorózní b. agilní o rigorózní ODPOVĚDI a. b. b. c. c. a. a. a. c. c. PRAKTICKÉ PŘÍKLADY VYUŽITÍ UML 10 PRAKTICKÉ PRÍKLADY VYUŽITI UML PŘÍPADOVÉ STUDIE Tato kapitola přináší prípadové studie - čerpající příklady ze seminárních prací, které vznikly při výuce předmětu „Úvod do objektového modelování" v letech 2012 - 2017. Kapitola je zařazena proto, aby studenti inovovaného předmětu „Metody objektového modelování" měli inspiraci při tvorbě seminárních prací. Vznikla tak sbírka řešených příkladů. Zde uvedené řešené příklady - případové studie poslouží pro praktické procvičení uplatnění U M L diagramů při návrhu IS. Jsou zde obsažena různá témata vesměs ze zkušenosti studentů, ať již z tvorby IS nebo jejich provozování. Každý student si vyzkoušel modelovat část IS s využitím U M L diagramů. Nejčastěji studenti využívají MS VISIO, méně často pak Enterprise Architect firmy Sparx. 10.1 Užití skladového informačního systému ÚVOD Tématem práce je navrhnout modul informačního systému pro sklad. Základní požadavky jsou, aby mohl jakýkoliv libovolný pracovník pomocí IS zažádat o vyskladnení, naskladnění výrobku a skladník, pracující ve skladu mohl zboží připravit a oznámit, že je zboží připraveno. Modul by měl být zaveden především z důvodu, že sklad a ostatní pracovitě se nachází v odlišných lokalitách. Tím společnost X Y ušetří náklady a čas nutný ke zbytečným výjezdům. Cílem práce není za napsání kódu modulu, nýbrž vytvoření jeho stručného konceptu za pomocí diagramu tříd, use case diagramu, diagramu aktivit a pro doplnění sekvenčním diagramem. Diagramy byly vytvářeny za pomocí software Microsoft Office 2013, Visio 2013. 82 Zdeněk Franěk - Objektové metody modelování v příkladech DIAGRAM TŘÍD První část práce je věnována diagramu tříd. Diagram č. 1: Diagram tříd modulu skladu pracovník -pracovnikID : int -jmeno : string -prijmeni: string -email: string -typID : int +ZobrazPracovníka () +PridejPracovnika () +UpravPracovnika () +SmazPracovnika () +Uloz() 1.." požadavek -pozadavekID : int -datum_pozadavku : date -pracovnikID : int -vyrobekID: int -mnozstvi: int -duvod : string +ZobrazPozadavek() +VytvorPozadavek () +SmazPozadavek () +UpravPozadavek () +Uloz() -vyrobekID: int -cena_produktu : float -druh : string -pocet: int +SkladUprav () +Uloz () 0.." Zdroj: vlastní zpracování výrobek -vyrobeklD: int -cena_produktu : float -druh : string -pocet: int -zůstatek : double = 0.0 +PridejVyrobek () +SmazVyrobek () +UpravVyrobek () +VyberVyrobek () +Uloz () Diagram pro modul skladu obsahuje základní čtyři třídy. Každá třída má vlastní název, který je napsán v modré hlavičce. Ve střední části jsou uvedeny atributy třídy a spodní část obsahuje metody. 83 PRAKTICKÉ PŘÍKLADY VYUŽITÍ UML TŘÍDY Třída pracovník představuje jak pracovníka, který zadává požadavky, tak i skladníka, který požadavky vyřizuje. Pro jejich odlišení se využívají odlišná práva, která zajišťuje atribut typ ID. Třída umožňuje pracovníka za pomocí metod zobrazit, upravit smazat a ukládat změny. Třída požadavek představuje katalog požadavků, kam pracovníci ukládají své žádosti ohledně skladu. Tyto požadavky je možno díky metodám zobrazovat, vytvářet, mazat, upravovat a ukládat. Třída výrobek představuj e výrobky, které j sou uloženy ve skladu a j sou požadovaný pracovníky za pomocí katalogu požadavků. Výrobky lze opět zobrazovat, upravovat, přidávat a mazat, jednotlivé kroky lze ukládat. Třída sklad představuje reálný sklad, v němž jsou uloženy výrobky. Ten lze za pomocí metod upravovat a změny ukládat. Vztahy V diagramu tříd jsem využil 3 základní vztahy mezi třídami. Jsou to kompozice, agregace asociace. Asociace je vztah mezi třídami, který specifikuje spojení mezi jejich instancemi. Tento vztah jsem využil mezi třídami pracovník a požadavek. Kompozice je určitá forma asociace, kde je vyjádřen vztah celek část. Tento vztah je využit mezi výrobkem a požadavkem. Agregace je silnější vztah než asociace, „při zániku kontejneru automaticky rušíme i daný element. " V diagramu jej nalezneme mezi výrobkem a skladem. PŘÍPADY UŽITÍ - USE CASE DIAGRAM „Use case diagram" zobrazuje informační systém jako celek a ukazuje, v jakých případech jej lze použít. Nej důležitějšími prvky diagramu jsou hranice systému, aktéři, činnosti a vazby mezi nimi. 84 Zdeněk Franěk - Objektové metody modelování v příkladech Diagram č. 2: Use case diagram modulu skladu ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ « z a h r n u t í » « z a h r n u ť » \ 1 « z a h r n u t í » ^ t Zaměstnanec Cas Zdroj: vlastní zpracování Aktéři - v modulu sklad se vyskytují tři aktéři. Prvním je zaměstnanec, ten může zadávat požadavky do katalogu požadavků, dále je mazat a upravovat. Do katalogu požadavků má dále přístup i druhý aktér, skladník. Ten dále může výrobky naskladňovat, vyskladňovat, objednávat a má přístup do katalogu výrobků, kde může výrobky měnit, mazat, přidávat. Posledním aktérem je čas, který vykonává činnosti v určitém časovém bodě, např. poskytuje, že je výrobek připraven k vyzvednutí nebo podává chybová hlášení. V „Use case diagramu" byly použity relace zahrnutí (include) a rozšíření (extend). „Relace «include» vyčleňuje kroky společníka několika případům užití do samostatného případu užití, který je následně do příslušných užití zahrnut". „Relace «extend» je způsobem, jímž lze do existujícího případu užití vložit nové chování" 85 PRAKTICKÉ PŘÍKLADY VYUŽITÍ UML DIAGRAM AKTIVÍT Diagram aktivit popisuje chovaní systému. Diagram popisuje vyskladnení výrobku. Zdroj: vlastní zpracování Diagram se skládá z akcí, označených zelenými políčky, počátečního a koncového uzlu. Tok akcí je zobrazen za pomocí čar se šipkami. Symbol modrého kosočtverce označuje rozhodnutí nebo sloučení. 86 Zdeněk Franěk - Objektové metody modelování v příkladech SEKVENČNÍ DIAGRAM Sekvenční diagram ukazuje posloupnost daných akcí, jak následují postupně v čase. Diagram je navržen tak, aby byl dodržen základní logický koncept. Vynechání jedná části má ve většině případů zhroucení celého systému. Diagram č. 4. ukazuje, jak vypadá úspěšné vyskladnení výrobku ze skladu. zaměstnanec IT systém skladník sklad Zdroj: vlastní zpracování Modré pole s panáčkem vyjadřují životnost aktéra, modré políčka bez panáčka vyjadřují životnost objektů. Zelená svislá pole ukazují, kdy je objekt aktivní. Dané aktivity (sekvence) jsou pak značeny čárami se šipkami, které udávají směr. Plná čára označuje klasickou zprávu, přerušovaná čára pak zprávu návratovou a šipka zalomená zpět označuje zpětnou zprávu (např. IT systém sám zjistí, jestli je výrobek dostupný a sám upraví data v databázi). 87 ZÁVĚR V této práci byl navržen modul skladu pro informační systém za pomoci programovacího jazyka UML. Zdárně byly vytvořeny všechny diagramy, které byly zpracovány v softwaru Microsoft Office 2013, Visio 2013. Cíle práce tedy byly splněny. Práce přinesla mnoho nových zkušeností a poznatků. Projevila se zde také silná stránka UML, jakou jsou například standardizace a veliká šíře záběru. Síří záběru je myšleno to, že v sobě ukrývá celý softwarový cyklus od návrhu až po fyzické nasazení. Velkou výhodou je také snadná úprava a rozšiřitelnost. Výhodou jazyka U M L je, že podporuje i průmyslovou oblast přes nástroje CASE. Jako slabou stránku lze považovat slabší důraz na grafické rozlišení. Některé prvky mají stejné grafické zobrazení, ale rozdílné vysvětlení. Mnoho uživatelů si taktéž stěžuje, že nelze na první pohled někdy z diagramu vyčíst, co přesně vyjadřuje, či jestli představuje třídy či objekty, jestli jsou vztahy dynamické nebo statické apod. Celkově převládají dobré vlastnosti a lze jej využívat i v reálném prostředí pro dobře odvedenou práci. U M L má stále co nabídnout a stojí za zvážení, zda se tento jazyk naučit podrobně a komplexně. Odměna v podobě dosažených výsledků bude jistě stát za to. 88 Zdeněk Franěk - Objektové metody modelování v příkladech 10.2 Analytická úloha pro společnost DERS ÚVOD Cílem této práce je opravit chyby, které způsobil bývalý analytik společnosti DERS při sestavování analýzy a návrhu informačního systému (dále jen IS) pro jednu nejmenovanou leteckou společnost. Úkol opravit tuto analýzu se skládá ze dvou dílčích úloh: • opravit diagram tříd, který udává nepřesné informace, a • pokud možno opravit a rozšířit Use Case diagram o scénář a upravit diagram případů užití. Vzhledem k náročnosti tohoto úkolu se tato práce nebude zabývat částí teoretickou, teorie bude vysvětlena v rámci praktické části. V této práci byly použity dva druhy vývojových prostředí. DERS používá vývojové prostředí Enterprise Architect 2012, tato práce využívá MS Visio 2016. PŘEDSTAVENÍ SPOLEČNOSTI DERS Firma DERS je společností zabývající se tvorbou aplikací pro různá odvětví, od aplikací sloužících v sociálních službách, až po aplikace, které jsou „šité" na míru zadavatelům. Vznikla v roce 1991 a její sídlo je v Hradci Králové. V rámci podpory vedení akademických pracovníků se společnost zabývá např. správou kapacit výzkumné infrastruktury, správou zakázek a evidencí a vykazování publikační čin­ nosti. V rámci oblasti koloběhů je to například správa procesu nákupu, procesu pořízení majetku, ale i například procesu pracovních cest a jiných personálních činností. V oblasti sociálních služeb se DERS zabývá hlavně podporou a řízení sítě sociálních slu­ žeb. A konečně v zakázkové činnosti se firma zabývá specifickými problémy a žádostmi kli­ entů. DERS k úspěšnému vyřešení problémů a k dosažení cílů využívá hlavně těchto tří prvků: • U X 1 - silná orientace na zákazníka; 1 UX - dojem, který zůstane v naší paměti po interakci s lidmi, produkty a událostmi (pozn. autora). 89 • SimplifyWorks - framework na tvorbu aplikací; • a konečně, jak sami v DERSu říkají, zdravý selský rozum a otevřený přístup. Ve zkratce se dá napsat, že firma DERS se „zabývá jednoduchým softwarem, který odstraňuje papírové koloběhy a umožňuje se soustředit na odbornou práci" (DERS 2016). UVEDENÍ DO PROBLEMATIKY ÚKOLU Obrázky skrývající se za odkazem u jednotlivých otázek zjednodušeně popisují systém fungování letiště z pohledu prvků (Class model) a jejich chování (Use case model): Základní prvky systému: • Osoby (pilot, cestující) • Let • Rezervace • Letiště • Stát Do každého letu se vždy musí přihlásit dva piloti, jinak se neletí. Systém jim následně odešle potvrzení o přihlášení. Cestující jsou povinni si zarezervovat místa v letadle - mohou mít na své jméno i více rezervací. Systém jim následně odešle potvrzení rezervace. U každého letu musí být kromě základních informací vždy uvedeno také odletové a cílové letiště + datum odletu. Letušky potřebují palubní seznam cestujících pro daný let, který obsluhují. Management letiště potřebuje lx měsíčně získat přehled všech pilotů a jejich letů. 90 Zdeněk Franěk - Objektové metody modelování v příkladech DIAGRAM TŘÍD Firma DERS zaslala analytikům tento nepovedený diagram tříd: Obrázek 1: Diagram tříd před úpravami Osoba jméno, int adresa char Pilot cisloLicence int 0 1 Let cisloLetu char letadlo char datumOdletu datetime datumPriletu int cilovaStanice Stat odletovaStanice char 0..* Rezervace cisioSedadia: Int cisloRezervace: int cisloLetu int 0 1 Letiště 0 1 - název char - mesto char stat Stat 0.1 - název char - mesto char stat Stat Jak j e již z obrázku patrné, jsou zde chyby jak v atributech, tak v asociacích, Stát dokonce nemá žádnou relaci. Po důkladném rozboru tohoto diagramu tříd jsem vytvořil diagram tříd svůj, který vypadá takto: 91 Obrázek 2: Diagram tříd Osoba «jrn*no Sinnj +Adre:a: String í-CIsi&LkeriCí: im +Jmerio: String -F idejCes 3E;U|: Let í-CljioLeiu: inj tDatumOdletu: Date vDatumPřilétli: Date -PtidejStatOdletuO -PridejStat PriletuO -PTldtJPoíe(C«ti|ilclcri(| 1 - ľeítující •Jmtno: String, •CisloPasu: Int -PřidejPoiadavtyfl i • Rezervace •CliluReií*w?c*: int *CisloLetu: Int •CiiloSedadli Out --Přidej PocetCe:tujicicriľ) -Pndej Rezervaci Q •OdeberfteztrvacKl Stůl ndlclJ -PridejCaiOdletuil Stul p ř í l e t u -PridejCasPriletuO Jak již je vidět z diagramu po úpravách, změnily se jak relace, tak i některé atributy a metody volání. První věcí, která se změnila, je dědičnost, která je dána mezi osobou, pilotem a cestujícím. Samozřejmě že je zde jasná dědičnost ve vztahu pilota a cestujícího vzhledem k osobě, která předává pilotovi a cestujícímu údaje o adrese a jméně. Vzhledem k tomu, že 92 Zdeněk Franěk - Objektové metody modelování v příkladech může dojít k omylům, nechává se u cestujícího i pilota jméno i v atributech těchto tříd. Dále se rozšířil, co se týká dědičnosti stát, který se dále rozdělil na stát odletu a příletu. Vazby mezi třídami se vyřešili složenou agregací, vzalo se v potaz, že let je omezen nejen počtem cestujících, ale i kapacitou letu a je ovlivněn právě počtem pilotů, který musí být roven či větší než dva, což se týká i násobnosti v relaci pilot - let. DIAGRAM PŘÍPADŮ UŽITÍ A SCÉNÁŘ PŘÍPADU UŽITÍ Analytik nechal v DERSu tento diagram případu užití: Obrázek 3: Diagram případu užití před úpravami Jak je již z diagramu vidět, analytik vůbec nedbal zadání a nevložil do diagramu hlášení systému o počtu pilotů a počtu letů minimálně lx za měsíc. Po úpravách tohoto diagramu vzešel diagram tento: 93 Obrázek 4: Diagram případu užití po úpravách Systém Rezervační systém pro cestující Tento diagram případů užití se kompletně přeměnil, jelikož předešlý diagram byl neúplný, špatně zkonstruovaný a chyběly mu klíčové prvky, j ako j sou např. subsystémy. Proto se rozhodlo o tom, že se vytvoří úplně nový, který je rozdělen na dva subsystémy, které na 94 Zdeněk Franěk - Objektové metody modelování v příkladech sobě pracují nezávisle. Jen hlavní systém dokáže tyto dva subsystémy řídit. Z tohoto diagramu se také mohou vytvořit právě dva nezávisle na sobě pracující scénáře, jeden pro subsystém vytvářející rezervace pro cestující, druhý pro zaměstnance aerolinek, respektive v tomto případě pro piloty společnosti. Scénáře by mohly vypadat takto: /. Scénář pro rezervaci letenek: Tabulka 1: Scénář rezervace letenek 1 Uživatel se přihlásí do systému 2 Systém potvrdí přihlášení 3 Uživatel vybere datum a číslo letu a zašle požadavek 4 Systém potvrdí požadavek na číslo letu a datum letu 5 Uživatel určí počet cestujících a zašle požadavek 6 Systém potvrdí počet cestujících 7 Uživatel potvrdí objednávku a uzavře rezervaci 8 Systém potvrdí rezervaci 9 Systém zašle potvrzující mail s platebními údaji Mohla by nastat i situace, kdy je tento let již plně obsazen. Poté by mohl nastat alternativní scénář v bodě 4, kdy systém nahlásí již plnou obsazenost. V tomto případě by se scénář musel vrátit k bodu číslo 3 a uživatel by si musel najít jiné číslo a datum letu. Tento scénář je jen rychlý nástin do problematiky scénářů, samozřejmě kdyby se mělo jít do detailu, některé body tohoto scénáře by se daly rozklíčovat na více pod bodů (např. bod 3, bod 5, dále rozšíření bodu 7 apod.) 2. Scénář pro přihlášení pilota na let Tabulka 2: Scénář pro přihlášení pilota k letu 1 Pilot se přihlásí do systému 2 Systém potvrdí přihlášení 3 Pilot vybere datum a číslo letu a zašle požadavek 4 Systém potvrdí požadavek na číslo letu a datum letu 5 Pilot potvrdí datum a číslo letu 6 Systém vloží pilota do databáze letů 7 Systém zašle zprávu pilotovi o přiděleném letu 8 Pilot potvrdí systému přidělený let 9 Systém znovu zašle potvrzující zprávu pilotovi o přiděleném letu I zde je patrné, že systém bude generovat přidělování letu podle časové a pracovní náročnosti pilota. V reálu by to měl být ovšem systém, který bude přidělovat lety pilotům právě 95 podle časového a pracovního vytížení pilotů. Tato problematika ovšem vyžaduje více informací, které pro tuto práci ovšem nejsou dostupné, či nejsou v kompetenci píšícího tuto práci je použít. Mohlo by se nyní podle scénářů postupovat ve tvorbě sekvenčních diagramů a diagramů aktivit, znovu ovšem tato práce naráží na své limity, které jsou ovlivněny firmou DERs. ZÁVĚR Problematika analýzy a návrhu IS je velmi široká a zahrnuje nejen znalosti z prostředí U M L 2.0, popřípadě U M L 2.5, je nutno znát také metodiky a metody, znát prostředí společnosti či firmy zadavatele, umět aplikovat nástroje Business procesů jako například BPMN 2.0 aj. Je třeba také spolupracovat s týmem kodérů, testerů, s lidmi, kteří tento systém budou do společnosti zavádět a hlavně je třeba komunikovat se zadavatelem, s lidmi, kteří tento systém budou používat, protože tyto informace j sou pro analytika klíčové. Když analytik tyto informace nemá neboje dokonce nezná, dopadne to takovým způsobem, jako bylo vidět na diagramech, které byly použity v této práci., 96 Zdeněk Franěk - Objektové metody modelování v příkladech 10.3Podnikový prodej - vytvoření nové objednávky zákazníkem SLOVNÍ POPIS PODNIKOVÉHO PROCESU Jedním z nej důležitějších podnikových procesuje Prodej. V našem případě se firma zabývá nákupem a následným prodejem zboží skrze E-commerce systém. Celý tento podnikový proces začíná tím, že vedení firmy zadá do informačního systému pokyn k zahájení marketingové kampaně. Informační systém informuje manažera prodeje o pokynu vedení firmy (např. současně skrz notifikační lištu v systému, sms, emailem, atd.). Manažer následně zadává do informačního systému pokyn, který je určený pro oddělení prodeje. Systém informuje oddělení prodeje o pověření k zahájení marketingové kampaně. Oddělení tedy zahájí marketingovou kampaň a kontaktuje potencionální zákazníky s nabídkou produktů (může se jednat o emailový kontakt, telefonický kontakt či jinou formu). Pokud má zákazník o zboží zájem, oddělení prodeje vloží do systému žádost o odeslání odkazu na katalog produktů, resp. webové rozhraní E-commerce systému. Systém následně odešle zákazníkovi zprávu obsahující odkaz na E-commerce systém. Později se zákazník naviguje na webové rozhraní E-commerce. V tom momentě E-commerce navyšuje počítadla návštěvnosti a informuje systém. Systém si to poznamená a v požadovaných intervalech (měsíčně, týdně, atd.) generuje sestavy návštěvnosti, které jsou určené vedení firmy. E-commerce po připojení zákazníka předkládá zákazníkovi žádost o registraci. Zákazník se registruje a E-commerce registraci potvrzuje. Poté je zákazníkovi předložen katalog zboží. Při výběru zboží zákazníka kontroluje E-commerce skrz dotaz na sklad, zdaje zboží dostupné. E-commerce poté odesílá systému výběr zákazníka, který je určen k analýze potenciálně chtěného zboží, na které se později mohou vztahovat slevy. Systém opět generuje sestavy přehledu potencionálně chtěných výrobků a ty předkládá vedení firmy. Současně informuje manažera prodeje o potencionálně velké objednávce. Manažer prodeje konzultuje s vedením firmy případné slevy. Vedení firmy dává pokyn manažerovi k zadání hromadné slevy pro objednávku zákazníka. Manažer vkládá hromadnou slevu do E-commerce systému ke konkrétní objednávce. E-commerce generuje konečnou cenu, způsob dopravy a platby. Zákazník vybírá údaje. E-Commerce přesměrovává zákazníka na platební bránu. Zákazník provádí platbu. Platební brána informuje jak prodejce, tak zákazníka o provedené platbě. E-commerce generuje fakturu zákazníkovi a informuje systém o nové objednávce. Systém informuje oddělení prodeje o nové objednávce ke zpracování. Pro přehlednost je uvedený proces přepsán do tabulky: 97 Pořadí činnosti Kdo (počáteční aktér) Akce Cíl (cílový aktér) 1. Vedení firmy Zadá do informačního systému pokyn k zahájení marketingové kampaně Systém 2. Systém Informuje manažera prodeje o pokynu vedení firmy Manažer prodeje 3. Manažer prodeje Zadává do informačního systému pokyn určený pro oddělení pro­ deje Systém 4. Systém Informuje oddělení prodeje o pověření k zahájení marketingové kampaně Oddělení prodeje 5. Oddělení prodeje Kontaktuje potenciálního zákazníka ohledně katalogu produktů Zákazník 6. Zákazník Projevuje zájem o zboží Oddělení prodeje 7. Oddělení prodeje Vkládá do systému žádost o odeslání odkazu na katalog pro­ duktů Systém 8. Systém Odesílá odkaz na katalog pro­ duktů Zákazník 9. Zákazník Navigace na webové rozhraní E-commerce 10. E-commerce Navyšuje počítadla návštěvnosti Systém 11. Systém Generuje sestavu návštěvnosti webu Vedení firmy 12. E-commerce Předkládá zákazníkovi žádost o registraci Zákazník 13. Zákazník Provádí registraci E-commerce 14. E-commerce Potvrzuje registraci Zákazník 15. E-commerce Předkládá nabídku zboží Zákazník 16. Zákazník Vybírá zboží E-commerce 17. E-commerce Kontroluje dostupnost zboží na skladě Sklad 18. Sklad Potvrzuje dostupnost zboží E-commerce 19. E-commerce Odesílá výběr zákazníka k ana­ lýze Systém 20. Systém Generuje sestavu potencionálně chtěného zboží Vedení firmy 21. Systém Informuje manažera o potencionálně velké objednávce Manažer prodeje 22. Manažer prodeje Konzultuje s vedením potencionální slevy objednávky Vedení firmy 23. Vedení firmy Zadává pokyn k úpravě smluvních cen v objednávce Manažer prodeje 24. Manažer prodeje Zadává hromadnou slevu pro objednávku E-commerce 25. E-commerce Generuje konečné ceny, způsob dopravy a platby Zákazník 26. Zákazník Vybírá možnosti E-commerce 27. E-commerce Přesměrovává zákazníka na platební bránu Zákazník 28. Zákazník Uskutečňuje platbu Platební brána 29. Platební brána Informuje zákazníka o uskutečněné platbě Zákazník 30. Platební brána Informuje E-Commerce o platbě E-Commerce 31. E-commerce Generuje Fakturu Zákazník 32. E-commerce Informuje systém o nové objed­ návce Systém 33. Systém Informuje oddělení prodeje o objednávce ke zpracování Oddělení prodeje 98 Zdeněk Franěk - Objektové metody modelování v příkladech USE CASE DIAGRAMY Celkově tedy máme v modulu vytvoření objednávky tyto aktéry, kteří vykonávají následující operace: Aktér Akce Vedení firmy Zadat kampaň Prohlížet sestavy Konzultace s manažerem prodeje Manažer prodeje Zahájit kampaň Interakce s E-commerce Konzultace s vedením firmy Oddělení prodeje Spustit kampaň Zadatpožadavek na odeslání produktu Řešit nové objednávky Systém Informovat o kampani Analyzovat výběr zákazníka Generovat sestavy E-commerce Interakce se zákazníkem Interakce se systémem Interakce s platební bránou Interakce s manažerem prodeje Interakce se skladem Zákazník Interakce s oddělením prodeje Interakce s E-commerce Interakce s platební bránou Platební brána Interakce se zákazníkem Interakce s E-commerce Sklad Interakce s E-commerce 99 PŘEHLED USE CASE DIAGRAMŮ: Vedení firmy: J Manažer prodeje: 100 Zdeněk Franěk - Objektové metody modelování v příkladech Oddělení prodeje: 101 E-commerce uc UseCase E-commerce o E-Commerce (from Akteni 102 Zdeněk Franěk - Objektové metody modelování v příkladech Zákazník: Platební brána: 103 DIAGRAM TŘÍD Faktura objednávka - ID :int Castka :dnuble DZekaznika int E ICstjednávťa :int objednávka - ID :int Castka :dnuble DZekaznika int E ICstjednávťa :int Castita ľdcuble - ID :int ~ se-zna mzbc-zi :int - IDzaiaznila :ini - ID :int Castka :dnuble DZekaznika int E ICstjednávťa :int Castita ľdcuble - ID :int ~ se-zna mzbc-zi :int - IDzaiaznila :ini Systém Date :da.te - Veraion :int Sa-znam c-bj-adnávak k v^iíze n i string ĚfaznamUzivatalu string Se-stavy ;sliing SeznamKampani D - CssiliC o-:=zE + GanarujSastavyQ iioid FOfcJ 3 Co se týče diagramu tříd, Výše zachycené vztahy mezi třídami, zahrnující asociaci, agregaci a kompozici, jedná se o jakýsi předběžný model, neboť ve finální verzi musí být mnohem propracovanější. SEKVENČNÍ DIAGRAM Sekvenční diagram pokrývá za sebou jdoucí činnosti v podniku. V tomto diagramu mají jednotliví aktéři přiděleny plovoucí dráhy tzv. swimlines. Mezi těmito aktéry probíhají činnosti formou zpráv. Na rozdíl od předchozích diagramů, jedná se o diagram dynamický. 104 Zdeněk Franěk - Objektové metody modelování v příkladech 105 ZÁVĚR Cíl práce byl splněn, všechny předem vytyčené diagramy byly zkonstruovány. Je nutno podotknout, že v případě budoucí modifikace těchto diagramů, bude třeba snížit míru abstrakce a zaměřit se na danou doménu podrobněji. 1 0 . 4 Rezervační systém kulturních akcí ÚVOD V seminární práci popisuji, jak funguje systém pro objednávání vstupenek na kulturní akce pomocí internetového portálu. Proces zahrnuje dvě zákaznické role. Jednu jako neregistrovaný uživatel a druhou jako uživatel registrovaný. Od závislosti na registraci či ne registraci zákazníka se pak odvíjí možnosti činností, které daný zákazník může v systému vykonávat. Dále zde máme roli administrátora, který potvrzuje, mění a ruší objednávky, spravuje nabídku akcí a odpovídá na dotazy. Tyto procesy vizuálně modeluji pomocí U M L diagramů, které jsem vytvořila pomoci programu Microsoft Visio 2010. Volba tématu z prostředí kultury byla pro mne nasnadě, jelikož ráda navštěvuji všelijaké kulturní akce. Často proto využívám rezervaci a objednávání vstupenek na různá divadelní představení, koncerty a plesy přes internet. Jedná se o velmi mobilní, přehlednou a pohodlnou variantu, která se těší stále větší oblibě. DIAGRAM TŘÍD Diagram tříd zachycuje proces evidence dat o zákaznících a objednávkách. U zákazníků, kteří se chtějí registrovat, se evidují údaje o registraci a přihlášení. U objednávek se evidují bližší informace o dané kulturní akci, ke které se vztahují informace o sálu, ve kterém se akce pořádá. 106 Zdeněk Franěk - Objektové metody modelování v příkladech Zákazník -10 : int -Jméno : string rPřfjmeni: string -Adresa: stři ng rEmsil: stí In* -Telefon: string 3 L Registrace Uživatelské Jméno; string •Heslo : int Jméno: scring •Příjmení: stři rtg Adresa string •Email: st ring Telefon : string Objerln ávha •ID : Int •Cena : bool •Datum platby: Date •Storno objednávky : bool Způsob platby: int •Poznámky, slevy atd. : string 4 ľritilďrhCTii -Uživatelské j m é n o : string -Heslo : Int -Uživatelské j m é n o : string -Heslo : Int Kultu rn akce -Typ: int •Místo : nt •Datum int -Čas :int Sál •Rada: string -Číslo sedadla: int Počet míst: lni DIAGRAM PŘÍPADU UŽITÍ Digram případu užití zobrazuje proces vytváření, rušení a potvrzení objednávek vstupenek na kulturní akce v rámci portálu. V diagramu jsou zobrazeny tři role lidí a systém. Jsou zde dvě uživatelské role, přičemž dané role mají různé možnosti činností v systému a to v závislosti na přihlášení nebo nepřihlášení uživatele. Běžný uživatel Běžný uživatel má možnost prohlížení akcí, jejich objednání a také registraci. Registrovaný uživatel Registrovaný uživatel má kromě možnosti prohlížení akcí a jejich objednání, také k dispozici přehled svých objednávek, s možností měnit je a stornovat. Dále může ze svého rozhraní položit dotaz administrátorovi. Administrátor Administrátor vytváří přehled kulturních akcí, provádí jejich změny, rušení a aktualizace. Dále registruje uživatele, potvrzuje a ruší objednávky, generuje pro uživatele rozhraní přehledu vlastních objednávek a zodpovídá dotazy. Je třeba říci, že role administrátora se prolíná s rolí systému. Typy činností jako potvrzení a rušení objednávek, správa uživatelova rozhraní, jeho registrace a podobnejšou řešeny automaticky pomocí systému. Člověka je 107 pak potřeba na správu celého systému, zadávání a změnu programu akcí, odpovídání na dotazy atd. Systém DIAGRAM AKTIVIT Prostřednictvím diagramu aktivit zobrazuji dva typy činností: registraci nového zákazníka a dotaz registrovaného zákazníka na administrátora. 1) Diagram registrace nového zákazníka 108 Zdeněk Franěk - Objektové metody modelování v příkladech Registrace Odeslání údajů do systému a jejich kontrola T C h y b n ě z a d a n é ú d a j e Potvrzení registrace v 109 2) Diagram dotazu registrovaného zákazníka na administrátora 110 Zdeněk Franěk - Objektové metody modelování v příkladech SCÉNÁŘ PŘÍPADU UŽITÍ Scénář případu užití popisuje proces událostí, které popisují průběh rezervace přes rezervační systém. Komunikace probíhá na základě událostí vykonaných registrovaným uživatelem, které následně rezervační systém vyhodnocuje a najejich základě provádí nezbytné operace pro úspěšné dokončení rezervace. 1 Uživatel Vstoupí do portálu. 2 Systém Zobrazí dialogové okno pro přihlášení. 3 Uživatel Zadá své přihlašovací údaje nebo se nově zaregistruje. 4 Systém Provede kontrolu přihlašovacích údajů a potvrdí přihlášení uživatele nebo potvrdí registraci a nově registrovaného uživatele přihlásí. 5 Uživatel Vybere kulturní akci, termín a místa v sále. 6 Systém Provede předběžnou rezervaci pro daná místa v sále. 7 Systém Vygeneruje formulář pro způsob platby. 8 Uživatel Vybere způsob platby z možností osobně nebo přes internet banking. 9 Systém Vygeneruje potvrzení objednávky a údaje uloží. 10 Systém V případě platby přes internet banking systém generuje formulář pro zaplacení. 11 Uživatel Vybere banku, přes kterou platí, zadá potřebné informace a objednávku zaplatí. 12 Systém Provede transakci. 13 Systém Potvrdí transakci, uloží údaje a zašle uživateli fakturu. 111 SEKVENČNÍ DIAGRAM Diagram popisující sekvenci činností při objednávce registrovaného zákazníka. Jedná se o logický koncept toho, jak mají jít jednotlivé činnosti za sebou, aby nedošlo k selhání pro­ cesu. Registrovaný uživatel Vytvoření objednávkového formuláře Vytvoření objednávky Kontrola Vytvoř Ověření Administrativní pracovník/ systěm V pořádku Vytvoř objednávku Proveď objednávku Potvrzení objednávky ZÁVĚR V rámci předmětu Objektové modelování byly poskytnuty podmínky k seznámení se s metodami vizuálního modelování pomocí softwarových nástrojů. Tvorba U M L diagramů pomocí specializovaného software je zajímavá a bylo zajímavé nahlédnout do této problematiky. Seminární práce pomohla nahlédnout na procesy, které běžně pomocí internetu vykonáváme, trochu z jiného pohledu, více si uvědomit, co se za danými procesy skrývá a dle jakých kroků se postupuje. 112 Zdeněk Franěk - Objektové metody modelování v příkladech 10.5 Modelování IS knihovny ÚVOD Práce je zaměřena na problematiku informačního systému knihovny. Jedná se o jednoduchý informační systém, který by měl nabízet základní funkce, jak pro registrované a neregistrované uživatele a administrátora. Problém nastává při půjčování knih, kdy se některé tituly nevracejí, a po delší době je složité dohledat, kdo si daný titul vypůjčil. Funkce IS: Prohlížení titulů, Registrace uživatele, Přihlašování uživatelů, Rezervace titulů, Správa registrovaných uživatelů, Správa titulů, Správa vypůjčených titulů DIAGRAM TŘÍD Diagram znázorňuje datový model IS jeho třídy a vztahy mezi nimi. U jednotlivých tříd jsou poté popsány jejich atributy a operace. Penále lD_penaie : Integer iDctenare: Integer iD_vypujcky: Integer Částka: integer •Vytvořeni penáleQ •Zruieni penále!) 0..* Čtenář -ID_ctenare: integer -Jméno -Příjmení: String -Mésto: Stnng -Ulice: Stnng -ČP: Integer -•Registrace uilvatele() ••Zrušení registracef) o..* Výpůjčky ID_vypujcky i integer -ID_ctenare : Integer ID_knihy: Integer Datum výpůjčky : Date Datum vráceni výpůjčky: Date Prodlouženi výpůjčky : Byte •Vytvořeni výpůjčky!) •Prodlouženi výpůjčky! J ••Zrušeni vypújčkyl) 0..1 Rezervace -IDrezervace : Integer ID_ctenare: Integer -ID_knihy: Integer Datum rezervace: Date •Vytvorení' rezervace! | •Zrušení rezervace!) 0..1 Knihy -ID_knihy : Integer -ISBN : Integer -Název: String -Autor: String -Zánr: Stnng -Nakladatelství: Stnng -Rok vydáni: Integer •Přidáni knihyd •Odebráni knihy! | 113 USE CASE DIAGRAM Diagram případu užití zobrazuje procesy spojené se správou knih, rezervací, výpůjček a čtenářů. V diagramu jsou zobrazeny tři základní role host, čtenář a administrátor. Host Jedná se o běžného uživatele, který není přihlášen. Tudíž má omezené možnosti, co se týče využívání systému. Jedinými funkcemi, které jsou mu k dispozici je vyhledávání knih v databázi a možnost se zaregistrovat do systému. Čtenář Tato role náleží již přihlášenému uživateli. Tento již může, kromě vyhledávání knih, také provádět rezervace titulů, rušit rezervace, spravovat své výpůjčky (vrácení knih, placení za upomínky) a spravovat informace na svém čtenářském profilu. Administrátor Administrativní pracovník, může v systému využívat služeb přidávat a vyřazovat tituly či čtenáře, potvrzovat rezervace, výpůjčky a registrace uživatelů. 114 Zdeněk Franěk - Objektové metody modelování v příkladech DIAGRAM AKTIVITY Diagram zobrazuje užití informačního systému, kdy do něj vstoupí nepřihlášený uživatel a chce si vypůjčit knihu. Systém ho následně vyzve k přihlášení, příp. registraci, zjistí, zda je titul k dispozici a zda již čtenář nemá nějakou upomínku. C Vstup do IS^j ^Vyhledávání t i t u l u j Registrovaný / \ _ _ >| Zadaní reg. údajů uživatel? \ f ANO \1/ \1/ ^Rezerace titulĹľj^ ^Potvrzeni registrace^ e titul k / \ dispozici? \ / NI ANO I Titul l2e rezervovat I Má upom 3 uživatel y \ omínku ? \ / A N C 115 Scénář případu užití Tato část již slovně popisuje události, při nichž dochází od vstupu nepřihlášeného uživatele po uložení veškerých dat do databáze systému. Krok Role Scénář Uživatel Vstoupí do IS 2 Systém Zobrazí možnost vyhledávání, přihlášení, nebo registrace Uživatel Zvolí registraci 4 Systém Zobrazí formulář pro registraci Uživatel Zadá své údaje a provede registraci 6 Systém Potvrdí registrací a zobrazí potvrzení Systém Zobrazí formulář pro přihlášení 8 Uživatel Zadá své údaje a přihlásí se Systém Zobrazí uživateli možnost vyhledávání 10 Uživatel Vybere titul k rezervaci Systém Provede kontrolu, zdaje titul k dispozici a zda nemá uživatel upomínku 12 Systém Nahlásí uživateli, že titul je možné si rezervovat Uživatel Potvrdí rezervaci 14 Systém Uloží údaje o rezervaci do databáze a pošle zprávu administrátorovi SEKVENČNÍ DIAGRAM Na následujícím diagramu je znázorněno, jak bude probíhat komunikace mezi aktérem a komponenty systému v čase. ' i - ii I ' l l -i-i y l u i - . M V l FormuHf rezervace knih Login-formulár I Výběr knihy Vytvoř Prihlasovací údaje I ..- •.••f'.urn-M, I Ok I Rezervace knihy I— I Potvrzeni rezervace Kc;erv.KC v syslému Adnm systém I x Zpráva o rezervaci 116 Zdeněk Franěk - Objektové metody modelování v příkladech ZÁVĚR Práce byla zaměřena na problematiku modelování informačního systému. Pro vypracování byl zvolen zjednodušený informační model knihovny, který řeší funkce a vztahy mezi registrovanými uživateli, knihami a jejich rezervacemi a výpůjčkami. Důležitou roli při návrhu informačních systému je přijat na veškeré komponenty a části, které budou následně uživatelé a administrátoři využívat a přijít na způsob, které z těchto složek a jakým způsobem provázat, aby spolu bezchybně komunikovaly a také nezatěžovaly zbytečně systém. Při pracování seminární práce bylo využito produkt Microsoft Visio 2010. Produkt jsem stáhl prostřednictvím služby MSDN. AA. 117 10.6 Kniha jízd UVOD Tato aplikace má za úkol evidovat seznam vozidel a informace o ujetých kilometrech, lokalit odjezdu a příjezdu vozidel a časové údaje o jízdě. Umožňuje zadávat a prohlížet tyto údaje a zobrazovat patřičné statistiky vozidel a vytvářet tiskové sestavy. DIAGRAM TŘÍD V diagramu jsou znázorněny třídy, které jsem vytvořil na základě interakce uživatelů s aplikací. Třídy mají mezi s sebou vazby v podobě agregace a asociace. SPZ IDRidic stavTachometru nazevAutomobilu typAutomobil u zadejSPZ dejSPZ zadejStavTachometru dejStavTachometru zadejNazevAutomobilu dejNazevAutomobilu zadejTypAutomobilu dejTypAutomobilu IDRidic j m é n o SPZ za dej ID dejlD zadejJmeno dejJmeno IDRidic SPZ vytvorAutomobil vytvorRidice zobrazZaznamyAutomobilu zobrazZaznamyRidice Záznam SPZ datumZaznamu adresaOdjezdu adresaPrijezdu N pocetKm za dejDatumZa známu dejDatum Záznamu zadejAdresaOdjezdu dejAdresaOdjezdu zadejAdresaPrijezdu dejAdresaPrijezdu zadejPocetKm dejPocetKm 118 Zdeněk Franěk - Objektové metody modelování v příkladech USE CASE DIAGRAM Zobrazuje role, které se při používání aplikace vyskytují (řidič, správce) ajejich možnosti interakce s tímto programem. Kniha j í z d 119 SCÉNÁŘE PŘÍPADU UŽITÍ Ukazují příklad možného využití aplikace v roli správce, který chce zobrazit statistiky o jízdách vozidel a řidiče, který vkládá nový záznam o jízdě. Přihlášení správce Krok Role Akce 1 Uživatel Otevře aplikaci 2 Uživatel Přihlásí se do systému jako správce 3 Systém Ověří zadané údaje a autorizuje přihlášení Uživatel Z nabídky zvolí sledování statistik jízd 5 Systém Zobrazí menu statistik 6 Uživatel Zadá údaje pro zobrazení požadovaných dat Systém Na základě zadaných údajů zobrazí příslušná data 8 Uživatel Prohlédne si zobrazené statistiky 9 Uživatel Odhlásí se a uzavře aplikaci Přihlášení řidiče Krok Role Akce 1 Uživatel Otevře aplikaci 2 Uživatel Přihlásí se do systému jako řidič 3 Systém Ověří zadané údaje a autorizuje přihlášení Uživatel Z nabídky zvolí vložení nového záznamu 5 Systém Zobrazí formulář pro zadání záznamu 6 Uživatel Zadá údaje požadované systémem Systém Uloží údaje do databáze 8 Uživatel Odhlásí se a uzavře aplikaci 120 Zdeněk Franěk - Objektové metody modelování v příkladech DIAGRAM AKTIVIT 121 SEKVENČNÍ DIAGRAM Zobrazuje časové posloupnosti aktivity uložení záznamu o jízdě, kterou provádí uživatel a systém na jeho kroky reaguje. ir Řidič Úvodní strana Formulář vložení záznamu Ulož záznam -Zvol í či nn o st • <^ Zobraz formulář-Zadej údaje- I H Pošli údaje • y Údaje v pořádku, zázanam uložen- ZÁVĚR V této práci je pomocí U M L diagramů zachycena struktura aplikace „Kniha jízd". Je v ní popsáno několik možných scénářů, které charakterizují tento systém. Všechny diagramy jsou zpracovány pomocí programu Visio. 122 Zdeněk Franěk - Objektové metody modelování v příkladech SHRNUTÍ STUDIJNÍ OPORY Studijní opora „Objektové metody modelování v příkladech" je určena studentům studijního programu manažerská informatika na Obchodně podnikatelské fakultě v Karviné, Slezské univerzity v Opavě. Vznikla na základě zkušeností autora s vedením seminářů a přednášek v předmětu Objektové metody modelování. Studijní opora ve spojení s předchozí studijní oporou „Objektové metody modelování s využitím jazyka U M L " poskytuje ucelený náhled do problematiky analytického procesu návrhu informačního systému, tvorby software nebo dokumentace software. Postihuje fázi návrh systému, analýzy systému předcházející zahájení programátorských prací. Velký důraz je kladen při výkladu látky na příklady z praxe, které provázejí celý text a je jim věnována samostatná závěrečná kapitola. Problematika objektových metod modelování, návrh informačních systémů a tvorba software je velmi rozsáhlá. Pokrývá celý vývojový proces od návrhu informačního systému, přes jeho programování až po jeho nasazení, údržbu a inovování. Tato studijní opora je věnována zejména části analýzy, která předchází programování. Popsané poznatky a přístupy při návrhu informačních systémů jsou nezbytným vědomostním vybavení studenta studijního programu „Manažerská informatika" Slezské univerzity v Opavě, Obchodně podnikatelské fakultě v Karviné. 123 Zdeněk Franěk - Objektové metody modelování v příkladech LITERATURA [I] [Arl2008] ARLOW, J. NEUSTADT, I. U M L 2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. Přel. Bogdan Kiszka. Dotisk 1.vydání, Brno: Computer Press, 2008. 567 s. ISBN 978-80-251- 1503-9. [2] [AW2005] ALDORF, F. Metodika RUP - diplomová práce, 2005, VŠE Praha [3] [Bool998] BOOCH, G. JACOBSON, I. RUMBAUGH, J. The Unified Modeling Language User Guide, l.vyd. Addison Wesley, 1998. ISBN 0- 201-57168-4. [4] [Buch2007] BUCHALCEVOVÁ, A. PAVLÍČKOVÁ, J. PAVLÍČEK, L. Základy softwarového inženýrství - materiály ke cvičení, l.vyd. Praha: Vysoká škola ekonomická, 2007. 222 s. ISBN 987-80-245-1270-9. [5] [Fow2003] FOWLER, M . U M L Distilled: A Brief Guide to the Standard Object Modeling Language. 3. edition. Addison Wesley, 2003. 208 s. ISBN 0- 321-19368-7. [6] [Kan2004] KANISOVÁ, H. Miller, M . U M L srozumitelně, l.vyd, Brno: Computer Press, 2004. 158 s. ISBN 80-251-0231-9. [7] [Pen2003] PENDER, Tom. U M L Bible, l.vyd. Indianapolis: Wiley Publishing, Inc., 2003. ISBN 0-7645-2604-9. [8] [Rum2004] RUMBAUGH, J. JACOBSON, I. BOOCH, G. The Unified Modeling Language Reference Manual. 2.vyd. Addison-Wesley, 2004. ISBN 032124562853 [9] [Schm2001] SCHMULLER, J. Myslíme v jazyku U M L : knihovna programátora, přel. Jiří Hynek, l.vyd. Praha: Grada, 2001. 360 s. ISBN 80-247-0029-8. [10] [Str2007] STŘÍŽOVÁ, V. HORNÝ, S. SVATÁ, V , VÁCLAVÍKOVÁ, M . Systémové pojetí (hospodářské) organizace, l.vyd. Praha: Oeconomica, 2007. 239 s. ISBN 978-80-245-1265-5. [II] [Lef2010] LEFFINGWELL, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010, 560 s., ISBN 0-321-63584-1 [12] [Fow2009] FOWLER, M . Destilované U M L . Grada Publishing a.s. 2009. 176 s. ISBN 978-80-247-2062-3 [13] [Fra2014] FRANĚK Z. Objektové metody modelování, učební text, SU OPF 2014, 115 s., elektronická verze „online", ISBN 978-80-7510-081-8 124 Zdeněk Franěk - Objektové metody modelování v příkladech Internetové zdroje: [1] http://mpavus.wz.cz [2] http://uml.czweb.org/index.html [3] http://www.rational.com [4] http://www.ibm.com [5] http://www.sparx.com [6] http://ecom.ef.icu.cz/web2/download/podkladv/zakladni-poimy-ea.pdf [7] http://dspace.upce.cz/bitstream/handle/10195/64679/E1 .pdf?sequence= 1 &isAll- owed=y [8] https://www.root.cz/clanky/nastroie-pro-tvorbu-uml-diagramu/ 125 Zdeněk Franěk - Objektové metody modelování v příkladech PŘÍLOHA Č. 1: SEZNAM OBRÁZKŮ Obrázek 1: Strukturální pojetí - kód a data, zdroj: http://mpavus.wz.cz 10 Obrázek 2 Třída s dvěma vytvořenými objekty (instancemi třídy), zdroj vlastní 14 Obrázek 3 Třída a podtřídy, zdroj http://mpavus.wz.cz/oo/ 16 Obrázek 4 Abstraktní třídy a metody, zdroj http://mpavus.wz.cz/oo/ 17 Obrázek 5: Historie vzniku UML, zdroj: [Arl2008)] 22 Obrázek 6: Objednávka na e-shopu, příklad případu užití, zdroj vlastní 32 Obrázek 7 Porovnání třídy analytického a návrhového modelu tříd, zdroj: http://uml.czweb.org/diagram_trid.htm 39 Obrázek 8: Doménový model tříd pro objednávku na e-shopu, zdroj: vlastní 41 Obrázek 9: Objektový diagram, zdroj: http://uml.czweb.org/diagram_trid.htm 43 Obrázek 10: Prvky stavového diagramu, zdroj: http://uml.czweb.org/diagram_trid.htm .46 Obrázek 11: Stavový diagram, zdroj: http://uml.czweb.org/ 48 Obrázek 12: Prvky diagramu aktivit, zdroj [ARL2007] 52 Obrázek 13: Diagram aktivit - zákazník nakupuje na e-shopu, zdroj vlastní zpracování..54 Obrázek 14: Diagram aktivit ocenění vozidla, zdroj: vlastní 55 Obrázek 15: Sekvenční diagram popisující nákup zboží na e-shopu neregistrovaným uživatelem, zdroj: vlastní 60 Obrázek 16: Sekvenční diagram popisující nákup zboží na e-shopu registrovaným uživatelem s uplatněním slevy, zdroj: vlastní 61 Obrázek 17: IBM Rational Development Platform Týmová práce při vývoji software, zdroj: vlastní (printscreen) 65 Obrázek 18: Příklad vývojového prostředí IBM Developer Platform - USE CASE Model, zdroj: Vlastní s využitím software IBM Rational Development Platform 66 Obrázek 19: Vývojové prostředí Enterprise Architect firmy Sparx - CLASS DIAGRAM, zdroj: vlastní s využitím software Enterprise Architect 67 Obrázek 20 Vytvoření nového projektu v Enterprise Architect, zdroj vlastní 68 Obrázek 21 Model Wizard E A s volbou Use Case, zdroj vlastní 69 Obrázek 22 Vytvoření Use Case Modelu, zdroj vlastní zpracování 70 Obrázek 23 Ukázkový Use Case Model, vlastní zpracování 71 Obrázek 24 Kontextový Toolbox a přidávání prvků Use Case diagramu, zdroj vlastní ...72 Obrázek 25 Quicklinker - šipka, zdroj vlastní zpracování EA, zdroj vlastní 73 Obrázek 26 Vytvoření asociace pomocí Quicklinkeru, zdroj vlastní 73 Obrázek 27 Vyhledání šablon na podporu U M L diagramů, zdroj vlastní v MS VISIO ...74 Obrázek 28 Printscreen prostředí kreslení USE CASE v MS Visio, zdoj vlastní zpracování v MS VISIO 75 Obrázek 29: Schéma projektu dle metodiky RUP, zdroj: [Arl2008] 78 126 Zdeněk Franěk - Objektové metody modelování v příkladech PŘÍLOHA Č. 2: SEZNAM TABULEK Tabulka 1: Scénáře případu užití registrovaný uživatel, který uplatňuje slevu a platí kreditní kartou, zdroj: vlastní 33 Tabulka 2 Scénář případu užití „neregistrovaný uživatel", který platí přes bankovní účet, zdroj: vlastní 34 Tabulka 3 Případ užití: Výběr zboží v e-shopu s uplatněním podmínky, zdroj: vlastní....35 127 PŘEHLED DOSTUPNÝCH IKON Čas potřebný ke studiu E m Klíčová slova Průvodce studiem <£> I Rychlý náhled Tutoriály K zapamatování Řešená úloha Kontrolní otázka |-/] J Odpovědi Samostatný úkol Pro zájemce -^-1 Cíle kapitoly Nezapomeňte na odpočinek -=^r-1 Průvodce textem 2 I Shrnutí Definice Případová studie Věta Korespondenční úkol Otázky Další zdroje Úkol k zamyšlení 128 Název: Autor: Vydavatel: Určeno: Počet stran Recenzenti Tiskárna: Náklad: ISBN Objektové metody modelování v příkladech RNDr. Zdeněk Franěk, Ph.D. Slezská univerzita v Opavě Obchodně podnikatelská fakulta v Karviné studentům SU OPF Karviná 129 doc. Dr. Ing. Ivo Formánek doc. Mgr. Petr Suchánek, Ph.D. X-MEDIA servis s.r.o. 50 ks 978-80-7510-295-9 Tato publikace neprošla jazykovou úpravou.