VŠB - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky BAKALÁŘSKÁ PRÁCE

Transkript

1 VŠB - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky BAKALÁŘSKÁ PRÁCE Rok 2005 Jakub Černoch

2 VŠB - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky Studijní podpory pro OOM Rok 2005 Jakub Černoch

3 Poděkování Na tomto místě bych rád poděkoval svému vedoucímu bakalářské práce, panu Ing. Michalu Radeckému za pomoc při vedení správného zpracování bakalářské práce, za pomoc při odstraňování chyb, za náměty pro zdokonalení práce. Dále bych chtěl poděkovat Cecílii Kudělové za konzultaci grafické úpravy přiložené multimediální aplikace. Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně a uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. V Ostravě dne 6. ledna 2005 Jakub Černoch

4 Abstrakt Každý tvůrce softwaru, který se zabývá vytvářením složitějších softwarových aplikací, se alespoň jednou v životě setká s potřebou vyvíjet svůj software co nejefektivnějším způsobem. Efektivnost v jeho případě znamená nejen přehlednost jeho vlastního produktu, ale také dynamická schopnost jeho produktu reagovat na změny prostředí, ve kterém se produkt využívá. Během jeho vytváření se také může objevit v situaci, ve které se již někdy ocitl nebo v situaci, ve které by uvítal zjednodušení svého vlastního návrhu, aniž by byl nucen zavrhnout ten dosavadní a vytvořit úplně nový. Popsanou problematikou se zabývá právě tato bakalářská práce. Jejím cílem je na úvod seznámit s vytvořenou přiloženou multimediální aplikací pro studijní podporu a následně uvést tvůrce softwarových aplikací do problematiky základních a pokročilejších termínů objektově orientovaných metod související s fázemi vývoje softwarového díla podle standardu UML. Termíny jsou využity v poslední části práce, která se zabývá vlastními návrhovými vzory. Klíčová slova multimediální aplikace, objektově orientované metody, fáze vývoje softwarového díla, návrhový vzor

5 OBSAH OBSAH...1 ÚVOD...2 MULTIMEDIÁLNÍ APLIKACE...3 Logická struktura multimediální studijní podpory... 4 Implementace... 4 OBJEKTOVĚ ORIENTOVANÉ METODY Úvod do problematiky Základní pojmy Rational unified process (životní cyklus vývoje softwarového díla) Unifikovaný proces vývoje aplikací pro OOM Požadavky Analýza Návrh Implementace NÁVRHOVÉ VZORY Úvodem Co je návrhový vzor? Popis návrhových vzorů Jak návrhový vzor vybírat Katalog návrhových vzorů Návrhové vzory Tvořivé (creational patterns) Návrhové vzory Strukturální (structural patterns) Návrhové vzory Chování (behavioral patterns) ZÁVĚR PŘÍLOHY LITERATURA

6 ÚVOD V softwarovém světě se můžeme setkat s širokou škálou programovacích technik. Jednou z velmi rozšířených je objektově orientované programování. Pro perfektní ovládání umění objektově orientované programování je důležité osvojit si specifika zmíněného programování. Nejedná se pouze o vlastní psaní zdrojového kódu, ale také o možnost znovupoužitelnosti takto naprogramovaných aplikací. Než přikročíme k vlastnímu tématu zadání práce, budete na úvod seznámeni s přiloženou multimediální podporou. Následně budete seznámeni se základními i pokročilejšími pojmy z oblasti objektově orientovaných metod, které vám pomohou lépe porozumět poslední kapitole týkající se návrhových vzorů, které se v objektovém programování hojně využívají. 2

7 MULTIMEDIÁLNÍ APLIKACE Na výběr pro vytvoření multimediální studijní podpory jsem měl hned několik produktů. Pro zpracování vizuální podoby jsem po úvaze nakonec použil program Macromedia Flash MX Professional Flash jsem vybral hned z několika důvodů: - široké možnosti v oblasti grafických úprav - interaktivita v komunikaci s uživatelem - možnost vytvoření obsahu materiálu, který je pak možné dynamicky upravovat, pokud dojde k jeho změně - velký výběr exportovaných formátů (html, exe, swf...) - kvalitní přehledná struktura, co se týče knihovny, časové osy ve vlastním programu Prvním krokem bylo vytvoření grafického návrhu této aplikace tak, aby z ní bylo možné studovat. Usoudil jsem, že nejlepší bude, aby ovládání a přesun mezi kapitolami byl logický a inteligentně strukturovaný. Taky jsem ponechal velký prostor pro samotné texty s obrázky a ovládání. Po vykreslení grafických prvků jsem implementoval první animace tlačítek a přiřadil jim první action skripty. Jakmile všechna tlačítka reagovala správným způsobem, do souborů kapitol jsem vložil komponenty TextArea (viz. dále). Následně jsem jim přiřadil action skripty pro načítání externího obsahu a tento externí obsah jsem vytvořil. Obsahovalo to vytvoření textových souborů příslušných názvů, které obsahovaly teorii, kterou jsem chtěl zobrazit. Do textu jsem také vložil html tagy, které umožnily lepší přehlednost textu tím, že jej naformátovaly. Napomohl také externí soubor s kaskádovými styly, který jsem umístil do adresáře css. Po sepsání veškerého nutného obsahu, včetně úpravy obrázků, jsem do aplikace doplnil čas a datum, základní informace o mě jako autorovi, indikaci načítání Loaderů (viz. dále) a úvodní animaci pro spuštění aplikace. Výslednou multimediální studijní podporu jsem exportoval do html formátu, tedy webovských stránek a do formátu exe, což je spustitelný program pod windows obsahující vlastní flash přehrávač nutný pro spuštění. Multimediální studijní podpora je spustitelná na každém počítači, který má nainstalovaný Macromedia Flash Player 7 a vyšší řady, který lze spustit bez hardwarových problémů. Taky je nutné mít kompletní adresářovou strukturu celé multimediální studijní podpory. Multimediální studijní podpora se spouští následujícím způsobem: - html stránky: v adresáři s html soubory najděte index.html. Po odkliknutí se spustí váš webovský prohlížeč. Pokud nemáte nainstalován zmíněný Macromedia Flash Player 7 a výše, budete přesměrování na stránku, která vám umožní instalaci tohoto pluginu. Pokud Flash Player nainstalován máte, po chvíli budete přesměrování na samotné swf soubory, konkrétně na main.swf. Pokud i přesto, že máte určitě nainstalován Flash Player nelze aplikaci spustit, můžete ji spustit přes soubor s názvem index_content.html. - exe soubor: v adresáři s exe soubory najděte main.exe. Po odkliknutí se spustí Flash Player, který vám umožní další práci s materiálem Osobně bych doporučil také se zaměřit na výběr rozlišení obrazovky. Moje doporučení pro minimální rozlišení je 1024x768 pixelů, nejlépe v barvách. Pokud budete multimediální studijní podporu spouštět v tomto rozlišení v Internet Exploreru, doporučuju jej přepnout na celou obrazovku tlačítkem F11 (zpět opět F11). Tím se vyhnete možným posouváním posuvníku u zmíněného prohlížeče. 3

8 4 Logická struktura multimediální studijní podpory Teoretický text je rozdělen do dvou hlavních kapitol: Objektově orientované metody (OOM) a Katalog návrhových vzorů (KNV). Každá z těchto hlavních kapitol obsahuje teorii k danému tématu. Kapitola OOM je zpracováním pouze informativním, tedy připomíná pouze některé postupy či termíny související s objektově orientovaným programováním či s vývojem softwaru. Tyto termíny se mohou využit v rozsáhleji zpracované kapitole KNV. Základní struktura multimediální studijní podpory vypadá následovně: Každá z kapitol Úvod, Požadavky, Analýza, Návrh, Implementace obsahuje podkapitoly podle své teorie. Každá z kapitol návrhových vzorů obsahuje následující podkapitoly: Účel, Motivace, Použití, Struktura, Důsledky, Implementace, Příklad, Vzory v praxi. Implementace Všechny kapitoly jsou uspořádány v logicky uspořádané adresářové struktuře, které obsahují textové soubory obsahující teorii jednotlivých kapitol, obrázky k jednotlivým tématům a flashové spustitelné soubory vlastní grafiky. Obsah textových souborů, které využívají jednoduché html formátovací tagy a kaskádové styly, je možné dynamicky pozměňovat podle potřeby nebo z důvodů aktualizace informací v nich obsažených, včetně přiložených obrázků. Každý textový soubor má svůj jedinečný název podle své kapitoly či podkapitoly. Je to soubor se sice ukládá jako txt, ale sám obsahuje html kód. Každý textový soubor je načítán do tzv. TextArea, což je komponenta Flashe pro textový obsah. U této komponenty je možné nastavit vzhled, velikost, jestli se text v ní zobrazený bude formátova jako html, zalamování řádků apod. V následujícím textu je ukázka nastavení komponenty TextArea použitá v aplikaci. U TextArea se nastavuje barva a přiřazuje konkrétní styl z kaskádových stylů (viz. níže). tacolor = 0xCCCCCC; tasadaucel_txt.backgroundcolor = tacolor; tasadaucel_txt.stylesheet = styles_css; Následuje jedna ukázka načítání textového souboru do TextArea s názvem tasadaucet_txt strukturálního návrhového vzoru Adapter, kapitola Účel: //styl pro textarea tasadaucel_txt.backgroundcolor = tacolor; tasadaucel_txt.stylesheet = styles_css;

9 5 //text pro text area se nejprve nacte do promenne a pak priradi konkrétní komponente TextArea var tasadaucel_lv:loadvars = new LoadVars(); tasadaucel_lv.load("design_patterns/structural/adapter/sada_ucel.txt "); tasadaucel_lv.onload = function(success:boolean) { if(success) { tasadaucel_txt.text = this.content; else { trace("unable to load text file"); ; Při aktualizaci textových souborů je důležité dodržet následující podmínky: - začátek každého souboru musí začínat tímto řetězcem &content= Ukázka z textového souboru: &content=<p class='headline'>účel</p><br> <p>zapouzdří žádost do objektu a tím umožní... - je nutné dodržet adresářovou strukturu všech souborů - soubor nesmí pro správné zobrazení celého textu obsahovat znaky, které se využívají pro načítání souboru nebo jeho formátování; např. +, <, & apod. (využijte tyto náhradní symboly: v pořadí PLUS, OS, AA) - je velmi důležité a pro zobrazení českých znaků nutné dodržet kódování textového dokumentu, které nese označení UTF-8 - při ukládání nesmíme zapomenout na dodržení názvu souboru (každý název nese označení kapitoly a podkapitoly) Dalším důležitým souborem je soubor s kaskádovými styly styles.css, který je umístěn v adresáři css. Kaskádové styly jsou určeny pro textový html obsah výše zmíněné komponenty TextArea. Neexistence souboru s kaskádovými styly zapříčiní nenaformátovaný text ve všech komponentách TextArea všech kapitol multimediální studijní podpory. Následuje zdrojový kód flashových souborů, který načítá kaskádový styl, který je následně využit u všech TextArea u všech kapitol: //styl text area var styles_css = new TextField.StyleSheet(); styles_css.load("css/styles.css"); styles_css.onload = function(success:boolean) { if(!success) { trace("error loading css file..."); ;

10 6 Je vytvořena proměnná styles_css, do které se nahraje příslušný kaskádový styl. Pokud není načtení úspěšné, vypíše se programátorovi hlášení o neúspěchu. Posledními soubory, o kterých bych se chtěl jenom okrajově zmínit, jsou obrázky k některým podkapitolám. Všechny obrázky jsou uloženy do adresáře images v adresáři kapitoly, ke které mají vztah. V souvislosti s obrázky a jejich případnou aktualizací bych zmínil pouze následující tři doporučení: - v případě jejich úprav dbejte na to, aby byly hlediska místa na disku co nejmenší, ne na úkor kvality čím menší obrázky budou, tím rychleji se budou načítat - jejich horizontální rozlišení by nemělo přesáhnout 700px to je z důvodů velikosti komponenty TextArea u všech podkapitol - aby byly správně načteny všechny obrázky, měly by být ve formátu jpg Hlavní main.swf soubor obsahuje časovou osu, na které se mimo úvodní animace objevuje pouze jedna oblast s komponentou Loader, která pomocí action scriptu načítá externí swf soubory podkapitol podle zmáčknutého tlačítka. Je to jednodušší a úspornější řešení než mít na časové ose desítky komponent Loader. Tím by vzrostla velikost hlavního main.swf souboru a dosáhlo by se nepřehlednosti. Soubory kapitol (např. command.swf z kapitoly Návrhové vzory chování) mají na rozdíl od hlavního souboru více oblastí. Jejich počet závisí na počtu podkapitol. Každá tato oblast má svou komponentu TextArea, která má svůj jedinečný název a do které se mohou nerušeně načítat externí data. Tímto je možné zasáhnout do jednotlivých oblastí bez ovlivnění těch druhých.

11 7 Po úvodní krátké animaci (což jsou grafiky nebo MovieClipy rozpohybované pomocí změn souřadnic, kterým může být přidána animovaná vlastnost jas, alpha, barva ) se objeví úvodní obrazovka: Tento zdrojový kód načítá úvodní obrazovku: //autoload hlavniho loaderu this.mainloader_ldr.autoload = false;

12 8 //nacteni uvodni obrazovky _root.mainloader_ldr.contentpath = "main/hello.swf"; _root.mainloader_ldr.load(); Vpravo nahoře je dynamické textové pole, ve kterém se vám objeví nadpis hlavní kapitoly, ve které se zrovna pohybujete O aplikaci, Oom nebo Návrhové vzory. Text do tohoto textového pole se načítá následovně (v našem případě se na posledním řádku načte text NÁVRHOVÉ VZORY): mainname = new Array(); mainname[0] = "O APLIKACI"; mainname[1] = "OBJEKTOVĚ ORIENTOVANÉ METODY"; mainname[2] = "NÁVRHOVÉ VZORY"; main.text = mainname[2]; Nad tímto textovým polem je aktuální čas, který umožňuje mít přehled nad dobou strávenou při studiu. V prvním okénku animace se načte aktuální čas: cas = new Date(); this.dat_txt.text = cas.getdate() + ". " + (cas.getmonth() + 1) + ". " + cas.getfullyear() + ", " + cas.gethours() + ":" + cas.getminutes() + ":" + cas.getseconds(); A pomocí druhého okénka animace se znovu a znovu aktuální čas obnovuje: gotoandplay(1); Při načítání externích souborů, vyjma těch textových a obrázků, se vedle datumu pokud zrovna načítáte nějakou z hlavních kapitol, objeví LOADING.... Toto oznámení je zde uvedeno z důvodů pomalého načítání některých větších externích swf souborů. Indikuje, že komponenta Loader načítá obsah, i když se na obrazovce zrovna nic neobjevilo po stisku některého z tlačítek. Je to instance textové pole s názvem loading_txt, které má programově nastaveno naslouchání událostí, jež se dějí v komponentě Loader. Následující zdrojový text ukazuje příklad naslouchání: //informace o loadovani (text loading...) loadlistener = new Object(); loadlistener.progress = function() { _root.loading_txt._visible = true; ; loadlistener.complete = function(eventobj) { _root.loading_txt._visible = false; ; //nove naslouchani udalosti pri dokonceni loadovani _root.mainloader_ldr.addeventlistener("complete", loadlistener); Je vytvořen nový objekt, kterému jsou přiřazeny nové funkce pro naslouchání během načítání (progress) a pro naslouchání na konci načtení (complete). Tyto jsou pak přiřazeny konkrétnímu Leaderu, jenž tyto funkce použije. Světle šedé pole je zde umístěna flash komponenta Loader umožňuje načítat externí flashový obsah nebo obrázky. V našem případě načítá jednotlivé kapitoly. Výhodou je možnost dynamického načítání dat. Není nutné, aby se všechna data načetla do paměti, dokud si to uživatel nevyžádá (výhoda pro umístění na webovou síť).

13 9 Pro všechna načítání je použit podobný zdrojový kód, který je uveden níže. Liší se pouze názvem načítaného souboru a názvy instancí (zvýrazněno kurzívou), které načítání odstartují: this.fieldabout_mc.obsah_mc.obsah_btn.onrelease = function() { _root.mainloader_ldr.addeventlistener("progress", loadlistener); _root.mainloader_ldr.addeventlistener("complete", loadlistener); ; mainloader_ldr.contentpath = "info/obsah.swf"; mainloader_ldr.load(); Opět se zde využívá naslouchání událostí pro informaci o načítání (obě funkce pro naslouchání událostí Loaderu jsou uvedené výše). Vlevo nahoře jsou tři hlavní tlačítka O aplikaci, Oom, Návrhové vzory. Po jejich stisku se nic nenačítá. Pouze po najetí myši se rozbalí příslušné podnabídky. Tyto podnabídky jsou instance MovieClip s vlastní časovou osou. Pro lepší orientaci v pohybu jsou určité části časové osy pojmenovány (slidedown, slideup apod.). Částí řešení komunikace mezi jednotlivými podnabídkami jsou cykly, které kontrolují stavy jednotlivých instancí MovieClip. up = "slideup"; down = "slidedown"; //hlavni nabidka About this.about_btn.onrollover = function() { if (aboutmenu == 0) { fieldabout_mc.gotoandplay(down); aboutmenu = 1; if (oommenu == 1) { fieldoom_mc.gotoandplay(up); oommenu = 0; if (patmenu == 1) { fieldpattern_mc.gotoandplay(up); patmenu = 0; ;

14 10 Pro komunikaci instancí klipu MovieClip se navíc využívá neviditelné tlačítko. Pomocí neviditelného tlačítka je řešeno rozbalování a sbalování podmenu. Neviditelné proto, že obsahuje nějakou grafiku pouze ve stavu Hit (tlačítka ve flashi mají tyto stavy: Up počáteční, Down myš klikne, Over, myš přes něj přejede, Hit aktivní oblast tlačítka pro kliknutí), takže je mu dána pouze oblast aktivity. V actionscriptu se uvede, že po nájezdu myši na toto neviditelné tlačítko se dá vědět výsuvným menu a ta se uvedou do stavu vysunutého nebo zasunutého. Výpis funkčnosti neviditelného tlačítka z hlavního main.swf souboru je následující: //promenne pro ovladani tlacitek var aboutmenu:number = 0; var oommenu:number = 0; var patmenu:number = 0; var behfield:number = 0; var crefield:number = 0; var strfield:number = 0; //obsluha neviditelneho tlacitka invfield_btn this.invfield_btn.onrollover = function() { if (aboutmenu == 1) { fieldabout_mc.gotoandplay(up); aboutmenu = 0; if (oommenu == 1) { fieldoom_mc.gotoandplay(up); oommenu = 0;

15 11 ; if (patmenu == 1) { fieldpattern_mc.gotoandplay(up); patmenu = 0; if (behfield == 1) { chapterbehavioral_mc.gotoandplay(left); behfield = 0; if (crefield == 1) { chaptercreational_mc.gotoandplay(left); crefield = 0; if (strfield == 1) { chapterstructural_mc.gotoandplay(left); strfield = 0; Neviditelné tlačítko má jednu nevýhodu. Protože jsem TextArea podkapitol řešil tak, aby bylo možné označit text a kopírovat jej do schránky, může se stát, že některé výsuvné menu zůstane viset ve vzduchu. Tento stav setrvá dokud se myší nenajede nad neviditelné tlačítko. Je to ta modrozelená oblast přibližně po obvodu aplikace na následujícím obrázku. Návrhové vzory mají navíc ještě svoje podnabídky podle tří hlavních rozdělení návrhových vzorů. Jejich pohyb je řešen podobně jako u hlavní nabídky s tím rozdílem, že nyní se pohybují doleva nebo doprava a navíc jsou maskována jinou vrstvou, aby byla vidět až ve vhodnou chvíli:

16 12 left = "slideleft"; right = "slideright"; this.fieldpattern_mc.behavioral_mc.behavioral_btn.onrollover = function() { if (behfield == 0) { _root.chapterbehavioral_mc.gotoandplay(right); behfield = 1; if (crefield == 1) { _root.chaptercreational_mc.gotoandplay(left); crefield = 0; if (strfield == 1) { _root.chapterstructural_mc.gotoandplay(left); strfield = 0; ; Z úvodní obrazovky se můžete vzápětí přesunout do nabídky obsahu. Stejná možnost je přes tlačítka O aplikaci Obsah. Z obsahu se můžete dostat do jakékoliv kapitoly, do které se můžete dostat přes tlačítkovou nabídku. Tato aktivita je opět řešena neviditelnými tlačítky (v aplikaci nejdou vidět). Nyní však ale odkazují na externí soubory, které se načtou do hlavního Loaderu: //ovladani obsahu o aplikaci

17 13 this.obpouziti_btn.onrelease = function() { _root.mainloader_ldr.contentpath = "info/about.swf"; _root.mainloader_ldr.load(); ; a podobně Poslední zmínku ze souboru main.swf jsem si ponechal na údaje o mě jako autorovi. K nim se lze dostat po stisknutí tlačítka O AUTOROVI. Je to MovieClip, který obsahuje příslušné tlačítko s animací a textové pole s údaji o autorovi, které se vysune nebo zasune po stisknutí tlačítka. Text je maskován, aby nedošlo k jeho zviditelnění, kdy si to nepřejeme. Kontakt je aktivní text. Po kliknutí se otevře váš ový klient, který vám umožní napsat autorovi.

18 14 Pro ovládání tlačítka a textového pole, tedy celého MovieClipu slouží následující zdrojový kód: //tlacitko o autorovi this.oautorovi_mc.oautorovi_btn.onrelease = function() { if (_root.oautorovi_mc._currentframe == 1) { _root.oautorovi_mc.gotoandplay(up); else if (_root.oautorovi_mc._currentframe == 8) { _root.oautorovi_mc.gotoandplay(down); ; Po stisknutí tlačítka se kontroluje, na kterém snímku se instance MovieClipu nachází a podle toho jej tlačítko ovládá nahoru nebo dolů. Nevyužívá se neviditelné tlačítko. Proto je nutné pro zasunutí opětovné kliknutí. Funkčnost jednotlivých kapitol si ukážeme na kapitole Flyweight ze strukturálních návrhových vzorů.

19 15 První obrazovkou je hlavní nadpis. Vpravo nahoře jsou šipky pro postupný pohyb mezi jednotlivými podkapitolami. Obsahují jednouchý kód přičítající nebo odečítající aktuální snímek z časové osy: on (release) { gotoandplay(_currentframe - 10); Počet podkapitol lze snadno uhádnout podle počtu kulatých tlačítek, které jsou navíc pro jednoduchost orientace očíslovány. Jejich animace fungují na základě čtyř zmíněných stavů pro tlačítka. Po nájezdu na ně, se objeví další možnost přesunu mezi jednotlivými podkapitolami. Tyto vysouvající se tlačítka jsou maskována a lze je vidět pouze po rozbalení. Jejich funkčnost a komunikace mezi nimi je řešena podobně jako funkčnost hlavní nabídky, tedy pomocí neviditelného tlačítka, které je kolem tohoto menu. Nad oblastí kulatých tlačítek je místo pro název kapitoly a její podkapitoly. Je to dynamické textové pole, do kterého se načítá text z pole hodnot: //pole nazvu kapitol chapternumber = new Array(); chapternumber[0] = "1. "; chapternumber[1] = "2. "; chapternumber[2] = "3. "; chapternumber[3] = "4. "; chapternumber[4] = "5. "; chapternumber[5] = "6. "; chapternumber[6] = "7. ";

20 16 chapternumber[7] = "8. "; chaptername = new Array(); chaptername[0] = ": účel"; chaptername[1] = ": motivace"; chaptername[2] = ": použití vzoru"; chaptername[3] = ": popis struktury"; chaptername[4] = ": důsledky použití vzoru"; chaptername[5] = ": implementace"; chaptername[6] = ": příklad"; chaptername[7] = ": vzory v praxi"; patternname = "Flyweight"; Tyto hodnoty se pak v dynamickém textovém poli objevují podle skriptu: chapter.text = chapternumber[0] + patternname + chaptername[0]; Největší oblast je věnována komponentě TextArea, do které se dynamicky načítají textové html soubory. Každá tato komponenta má v dané podkapitole svůj jedinečný název, podle kterého se na ně odkazu v actionscriptu. Pro úpravu ve flashi je dobré vědět, že pro každý soubor existuje knihovna. Tato knihovna obsahuje všechny použité grafiky, movie klipy, buttony či komponenty, které jsou v daném souboru využity. Knihovnu jsem uspořádal podle druhu komponenty a pak podle toho, čemu náleží, jestli pozadí, tlačítkům :

21 17 OBJEKTOVĚ ORIENTOVANÉ METODY Úvod do problematiky Základní pojmy Co je to objektově orientovaná metoda Vlastní definici objektově orientované metody předřadíme zavedení následujících základních pojmů vztažených a definovaných v kontextu softwarového inženýrství: 1. metoda je promyšlený postup vývoje softwarového systému 2. architektura je organizovaná struktura a s ní spjaté chování systému 3. objekt je entita s jasně definovanou hranicí a identitou zahrnující její chování a stavy 4. objektově orientovaná architektura systému je tedy struktura propojených objektů, které prostřednictvím vzájemné komunikace (interakce) definují výsledné chování celého systému Z výše uvedeného tedy vyplývá, že objektově orientovaná metoda je promyšlený způsob vývoje softwarového systému postaveného na objektově orientované architektuře. Metoda reprezentuje ideální postup, který jednotlivé firmy přizpůsobují podle svých konkrétních podmínek do podoby svého tzv. softwarového procesu, tedy podnikového procesu používaného k realizaci jednotlivých softwarových projektů. Vztah metody a softwarového procesu tak lze nejlépe dokumentovat na analogii s laboratorním vývojem (metoda) a průmyslovou výrobou (softwarový proces) nějakého produktu. Co je účelem použití objektově orientované metody Účelem objektově orientovaných metod je dát softwarovým inženýrům k dispozici dobře definovaný popis cesty jak vyvíjet softwarové systémy objektově orientované architektury, a zajistit tak maximální kvalitu vytváření všech softwarových artefaktů spjatých s tímto vývojem. Softwarový produkt není dán pouze výsledným kódem, ale je tvořen celou řadou dokumentů popisujících specifikace požadavků, modely analýzy a návrhu, stejně jako popis fyzické architektury systému a způsob jeho rozmístění u zákazníka. Metody mohou být neformální, bez přesně definované syntaxe a sémantiky, nebo naopak formální, kdy je syntaxe a sémantika přesně daná. Náročnost zvládnutí metody stoupá s mírou formalizace dané metody. Čistě formální metoda nutně musí vycházet z matematicky definovaných formulí a bývá pro běžnou praxi díky své náročnosti hůře použitelná. Kompromisem jsou metody semiformální, které sice nejsou postaveny na jazyce matematiky, ale využívají přesně daného specifikačního jazyka (obvykle grafického), který je kompromisem přijatelným pro širokou obec softwarových inženýrů. Historie vývoje objektově orientovaných metod Historie vývoje objektově orientovaných je stejně stará jako vývoj jazyků používaných pro objektově orientované programování. Tyto metody vznikaly z důvodů zajištění metodiky efektivního použití těchto jazyků. Od druhé poloviny 80. let se tak objevila celá řada metod, které doznaly svého uplatnění v praxi. Ty nejvýznačnější, které se staly základem jazyka UML (Unified Modeling Language) jsou metoda OMT (Objekt Modeling Technique), Boochova metoda a OOSE (Object- Oriented Software Engineering). V dnešní době je standardem pro výše uvedené účely vývoje jazyk UML, který navazuje na historicky úspěšné metody z první poloviny devadesátých let a jehož řízená specifikace je garantována skupinou OMG (Object Management Group). Oficiální dokumentace specifikace jednotlivých verzí

22 18 jazyka UML jsou k dipozici na webových stránkách OMG na adrese Rational unified process (životní cyklus vývoje softwarového díla) Iterace, fáze a cykly vývoje softwarového díla Tento proces definuje při vývoji softwaru otázky kdo, co, kdy a jak. V současném období, kdy se předmětem vývoje staly softwarové systémy vysoké úrovně sofistikace, je nemožné nejprve specifikovat celé zadání, následně navrhnout jeho řešení, vytvořit softwarový produkt implementující toto zadání, vše otestovat a předat zadavateli k užívání. Jediným možným řešením takového problému je přístup postavený na postupném upřesňování cílového produktu cestou jeho inkrementálního rozšiřovaní z původní hrubé formy do výsledné podoby. Softwarový systém je tak vyvíjen ve verzích, které lze průběžně ověřovat se zadavatelem a případně je pozměnit pro následující cyklus. Samotný životní cyklus vývoje softwarového díla je rozložen do čtyř základních fází (zahájení, rozpracování, tvorba a předání), přičemž pro každou z nich je typická realizace několika iterací umožňujících postupné detailnější rozpracování produktu. Každý cyklus vede k vytvoření takové verze systému, kterou lze předat uživatelům, a která implementuje jimi specifikované požadavky. Iterace je pak úplná vývojová smyčka vedoucí k vytvoření spustitelné verze systému reprezentující podmnožinu vyvíjeného cílového produktu. Tento je postupně rozšiřován každou iterací až do výsledné podoby. V rámci každé iterace proběhnou činnosti vázané na byznys modelování, následují specifikace požadavků, analýza a návrh, implementace, testování a nasazení (instalace). K tomu probíhá celá řada podpůrných činností týkajících se správy konfigurací, řízení projektu a přípravy prostředí, ve kterém je systém vyvíjen a nasazen. Popis procesů a jimi vytvářených modelů Z výše uvedeného tedy vyplývá, že vývoj softwarového systému je dán celou řadou v iteracích prováděných činností uspořádaných do následujících procesů charakteristických dle účelu svého použití: 1. byznys modelování popisuje strukturu a dynamiku podniku či organizace 2. specifikace požadavků definuje funkcionalitu softwarového systému cestou specifikace tzv. případů použití 3. analýza a návrh se zaměřuje na specifikaci architektury softwarového produktu 4. implementace reprezentuje vlastní tvorbu softwaru, testování komponent a jejich integraci 5. testování se zaměřuje na činnosti spjaté s ověřením správnosti řešení softwaru v celé jeho složitosti

23 19 6. nasazení se zabývá problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře Unifikovaný proces vývoje aplikací pro OOM Požadavky Požadavky a jejich specifikace Většina prací spojená s definicí a specifikací požadavků je vykonána ve fázích začátku RUP. Následující metamodel ukazuje, že existují dva způsoby zachycení požadavků: - funkční a nefunkční požadavky - případy užití a účastníci Detail pracovního postupu tvorby požadavků v metodice RUP obsahuje následující aktivity, které nás jako objektově orientované analytiky budou zajímat: - vyhledání účastníků a případu užití - detaily případu užití - struktura modelu případů užití Standardní pracovní postup tvorby požadavků je rozšířeno tímto způsobem: - účastník: tvůrce požadavků - aktivita: vyhledání funkčních požadavků - aktivita: vyhledání nefunkčních požadavků - aktivita: stanovení priorit jednotlivých požadavků - aktivita: sledování požadavků až k případům užití Význam požadavků je dalekosáhlý. Přibližně 25% projektů končí nezdarem v důsledku problémů, které vznikly v procesu inženýrství požadavků. Existují dva typy požadavků: 1. funkční požadavky, které popisují požadovanou službu systému

24 20 2. nefunkční požadavky, které definují vlastnosti systému a omezení, za nichž musí systém pracovat Správně formulované požadavky by měly být vyjádřeny jednoduchým strukturovaným jazykem s použitím klíčového slova bude, aby je bylo možné v nástrojích pro podporu inženýrství požadavků snadno zpracovat. Např. <id><system>bude<funkce> (jedinečný identifikátor-název systému-klíčové slovo-funkce). Specifikace systémových požadavků obsahuje funkční i nefunkční požadavky na vznikající systém. Specifikace může mít podobu dokumentu nebo databáze v nástroji pro správu požadavků. To, že máme mapu systému neznamená ještě, že máme systém samotný. Naše volba v nepřeberném množství informací musí projít následujícími stavy: - odstraněním (odfiltrování informací) - deformací (což jsou pozměněné informace) - zobecněním (pravidla, víra, zásady, které byly vytvořeny o pravdě a nepravdě) Univerzální kvantifikátory (např. všichni, někteří, nikdo) mohou naznačovat hranice omezenosti vidění daného systému. Je třeba prověřit všechny možnosti. Modelování případů užití Modelování případů užití je součástí pracovního procesu Požadavky. Klíčovými aktivitami modelování případů užití jsou nalezení účastníků a případů užití a detail případů užití. Účastník specifikuje roli, kterou určitá externí entita přijímá v okamžiku, kdy začíná daný systém bezprostředně používat. Může vyjadřovat roli uživatele, roli dalšího systému, který se dotýká hranic našeho systému. Modelování případů užití je další formou inženýrství požadavků. Tuto aktivitu lze rozdělit na následující etapy: - nalezení hranic systému - nalezení účastníků - nalezení případů užití Účastníci jsou takové role přidělené vnějším entitám, které přímo komunikují se systémem. K označení účastníka napomůže, jestliže si uvědomíme, kdo nebo co používá systém, či s ním bezprostředně komunikuje. Účastníkem může být často i abstraktní pojem, např. čas. Případy užití jsou funkce, které systém vykonává jménem jednotlivých účastníků nebo v jejich prospěch. V nalezení případů užití nám může pomoci, když si uvědomíme, jak jednotliví účastníci komunikují se systémem. Diagramy případů užití znázorňují následující: - hranice systému - účastníky - případy užití