Využití návrhových vzorů v praxi. Josef Miléř

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Využití návrhových vzorů v praxi Josef Miléř Vedoucí práce: Ing. Jiří Daněček Studijní program: Softwarové technologie a management Obor: Softwarové inženýrství 25. května 2011

2 iv

3 v Poděkování Rád bych poděkoval panu Ing. Jiřímu Daněčkovi, že se ujal tématu této bakalářské práce, za jeho připomínky a spolupráci. Dále bych chtěl poděkovat mé rodině za podporu v průběhu celého studia a mým spolužákům Michalovi a Milanovi.

4 vi

5 vii Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract The bachelor project introduces design patterns as a programming tool. The software architecture and its styles, namely N-TIER pattern are also of the concern there. Later, some of the object-oriented design principles are implemented in a single example. Finally, the practical use of particular design patterns are presented in a simple software project. Abstrakt Bakalářská práce představuje návrhové vzory jako programovací nástroj, věnuje se softwarové architektuře a jejím stylům, zejména pak vzoru N-TIER a na konkrétním příkladě předvádí praktickou implementaci některých z objektových návrhových principů. Nakonec na jednoduchém softwarovém projektu demonstruje využití jednotlivých návrhových vzorů. ix

8 x

9 Obsah Úvod 1 1 Význam a využití návrhových principů 3 2 Softwarová architektura Úvod do softwarové architektury Architektonické vzory N-TIER / 3-TIER vzor Praktické použití architektonického vzoru Výčet požadavků na softwarový projekt Použité technologie a knihovny Programovací jazyk Komunikační frameworky Perzistentní frameworky Databáze Návrhové vzory Seznámení s návrhovými vzory Struktura Rozdělení návrhových vzorů Unified Modeling Language - UML Příklad použití návrhového vzoru Softwarový projekt Analýza a návrh Prezentační TIER Singleton Builder Facade Composite State Command Chain of Responsibility Byznys TIER Memento Data Transfer Object xi

10 xii OBSAH Proxy Table module Data TIER Abstract Factory Data Access Object Pooling Active Record Foreign Key Mapping Serialized LOB Testování Jednotkové testy Integrační testy Validační testy Systémové testy Závěr 35 Literatura 37 A Seznam použitých zkratek 39 B Diagramy 41 C Obsah přiloženého CD 51

11 Seznam obrázků 1.1 Základní model tvorby software User, Business, System [6] Běžný aplikační model [6] N-TIER architektonický návrhový vzor Model New I/O [7] Příklad vztahu asociace Příklad vztahu agregace Příklad vztahu kompozice Příklad návrhového vzoru - COMMAND Návrhový vzor - SINGLETON Návrhový vzor - BUILDER Návrhový vzor - FACADE Návrhový vzor - COMPOSITE Návrhový vzor - STATE Návrhový vzor - CHAIN OF RESPONSIBILITY Návrhový vzor - DTO Návrhový vzor - PROXY Návrhový vzor - ABSTRACT FACTORY Návrhový vzor - DATA ACCESS OBJECT Návrhový vzor - POOLING Návrhový vzor - FOREIGN KEY MAPPING B.1 Use Case Model B.2 Class Diagram - Prezentační TIER (bez ServiceLayer) B.3 Class Diagram - Prezentační TIER (ServiceLayer) B.4 Class Diagram - Byznys TIER B.5 Class Diagram - Data TIER B.6 Datový model B.7 Přehled použitých vzorů - prezentační TIER B.8 Přehled použitých vzorů - byznys TIER B.9 Přehled použitých vzorů - data TIER B.10 Strukturální testování xiii

12 xiv SEZNAM OBRÁZKŮ

13 Seznam tabulek 2.1 Architektonické styly [6] Jednotkové testy Strukturální testy Inkrementální testy Validační testy - Zobrazení všech View Systémové testy xv

14 xvi SEZNAM TABULEK

15 Úvod Životní cyklus tvorby softwarové aplikace se dá stručně shrnout do několika základních etap: analýza, návrh, implementace, testování, nasazení. V etapě tvorby návrhu může docházet k situaci, kdy jsou v různých projektech řešeny obdobné či stejné návrhové problémy. Pro řadu takových situací byly vytvořeny návrhové vzory, které danou problematiku řeší a dají se efektivně využít. Návrhový vzor je obecným znovu použitelným nástrojem pro řešení problému, který se určitým způsobem opakuje a je využitelný v různých situacích. Návrhový vzor pojmenovává, abstrahuje a identifikuje klíčové aspekty běžných návrhových struktur, které jsou vhodné pro tvorbu znovu použitelného objektově orientovaného návrhu. Návrhový vzor identifikuje použité třídy a instance, jejich role a vazby a přiřazení zodpovědností.[1] Návrhové vzory jsou aplikovatelné jak na úrovni návrhu celkové architektury informačních systémů, tak na úrovni řešení dílčích komponent. Motivem k sepsání této bakalářské práce byla potřeba blíže pochopit širší souvislosti zasazení návrhových vzorů do návrhu softwarových systémů, jejich role, vztahy v systému i mezi jednotlivými návrhovými vzory a jejich praktické využití. Cílem této bakalářské práce je představit návrhové vzory jako programovací nástroj a následně na jednoduchém příkladě předvést praktickou implementaci některých z objektových návrhových principů. Bakalářská práce se proto zabývá výběrem architektonického stylu, definicí rozhraní jednotlivých komponent, jsou zde zmíněny některé heuristiky, na jejichž základě jsou vytvářeny statické a dynamické části aplikace, a konečně i návrhové vzory. Tato bakalářská práce nemá představovat výčet veškerých návrhových vzorů s jejich popisem, ale byla sepsána s důrazem na aplikaci návrhových principů. Význam některých principů je proto názorně ilustrován v praktické části bakalářské práce. Bakalářské práce je strukturovaná do dvou hlavních částí, kde první část pokrývá nezbytný teoretický rámec a sestává z prvních tří kapitol. Druhá, praktická část je soustředěná ve čtvrté kapitole, tedy samotném softwarovém projektu. V první kapitole je stručně nastíněn význam a využití návrhových principů. Druhá kapitola se týká architektury návrhu softwarových systémů a jejich vzorů. Třetí kapitola popisuje strukturu publikace návrhových vzorů, jejich rozdělení, dále představuje nástroj pro modelování objektově orientovaných systémů a je zakončena příkladem využití návrhových vzorů. Softwarový projekt, který byl vytvořen v rámci této bakalářské práce a je popsán ve čtvrté kapitole, je jednoduchý registrační systém, kde si připojení uživatelé mohou listovat mezi akcemi, přihlásit se na ně a spravovat svůj profil. Tento jednoduchý model aplikace poskytuje dostatek prostoru pro objasnění funkcionalit návrhových principů. Jádro čtvrté kapitoly, a potažmo celé bakalářské práce, proto obsahuje přehled použitých návrhových vzorů včetně popisu jejich implementace. 1

16 2 ÚVOD

17 Kapitola 1 Význam a využití návrhových principů Návrhový vzor má svůj původ zcela mimo oblast softwarových technologií. V řadě publikací je citován architekt Christopher Alexander, který v šedesátých letech dvacátého století prohlásil: "Každý vzor popisuje jistý problém, který se může kolem nás znovu a znovu objevovat, a poté navrhuje jádro řešení k tomuto problému takovým způsobem, že toto řešení můžete využívat milionkrát znovu a znovu bez toho, aniž byste to tak kdy dělali dvakrát stejným způsobem".[2] Přestože Christopher Alexander v té chvíli mluvil o vzorech architektury návrhu budov, tato definice přesně popisuje problematiku návrhových vzorů. Počátky vzniku návrhových vzorů se datují do pozdních osmdesátých let, kdy se objektové programování stávalo více a více populární ve výzkumu a mezi experty, jako byli Gamma, Beck, Helm. Tito zkušení návrháři měli dokonalé podmínky pro to, aby začali zaznamenávat konstrukce spolupracujících objektů. Jejich práce se soustředila zejména kolem konferencí "Object-Oriented Programming, Systems, Languages and Applications"(OOPSLA) v Oregonu.[3] První publikací, která přináší strukturovaný přehled o základních návrhových vzorech a položila základy dalším snahám v tvorbě návrhových vzorů, je Design Patterns: Elements of Reusable Object-Oriented Software od Gamma, Helm, Johnson, Vlissides [1]. Tato čtveřice autorů, vystupující pod názvem Gang of Four, dala základy pro ostatní tvůrce, definovala strukturu publikace návrhového vzoru a představila prvních 23 vzorů. Dnes jich existují řádově stovky a uplatňují se ve specifických odvětvích. Návrhové vzory se v poslední době stávají jistým standardem pro návrhy softwarových systémů, jistotou dobré strukturovanosti, možnosti znovupoužitelnosti a přehledu. Opírají se o objektově orientované programovací jazyky a jejich nasazení získává v současnosti největší úspěch v Enterprise aplikacích. Tvorba software se dělí do několika etap: Analýza, návrh, implementace, testování, nasazení. Návrhové vzory jsou jistou paralelou těchto etap a doplňují právě analýzu, návrh a implementaci 1.1. Pokud mluvíme o návrhovém vzoru, vstupujeme tím do nitra návrhu a poté implementace daného projektu. Návrhové vzory přistupují k řešení problému z různé úrovně abstrakce. Řeší buď přímo specifický problém na úrovni části zdrojového kódu, či naopak odstupují do takové 3

18 4 KAPITOLA 1. VÝZNAM A VYUŽITÍ NÁVRHOVÝCH PRINCIPŮ Obrázek 1.1: Základní model tvorby software dálky, jako je vnější pohled na architekturu celého systému. Např. výběr strategie provedení nějaké úlohy na základě vstupních údajů (jdeme blíže k implementaci), nebo způsob návrhu celé byznys logiky vytvářeného systému (jdeme dále od konkrétní implementace). Návrhový vzor tedy pokrývá široké spektrum celého návrhu. Výrazným rysem návrhových vzorů je znovupoužitelnost daného řešení. Tato vlastnost má vliv na několik faktorů tvorby (ne jenom) informačních systémů [4]: rychlost vývoje softwarových systémů finance stabilita Použití návrhových vzorů má rovněž ekonomické implikace. To, jak rychle je firma schopná vyvíjet software, jí dává výraznou konkurenční výhodu na trhu. Využití již jednou navrženého řešení v dalších projektech generuje úsporu času, která se odrazí v nižší potřebě pracovní síly a tedy i úspoře nákladů. Díky tomu je firma schopná předložit zákazníkovi nižší cenovou nabídku za celý projekt a uspět v získání zakázky oproti konkurenci. Posledním zmíněným faktorem je stabilita. Již navržené funkční a otestované řešení jistého problému dává záruku k tomu, že bude stabilní. To se opět projeví v úspoře času, což se opět promítne do nižších nákladů a ceny, kterou lze zákazníkovi nabídnout. Velmi zjednodušeně se dá dojít k závěru, že návrhové vzory mají podíl na snižování nákladů na projekt.

19 Kapitola 2 Softwarová architektura Tato kapitola pojednává o softwarové architektuře a jejích stylech. Na tomto základě je vybrán a popsán vhodný architektonický styl pro softwarový projekt v rámci této bakalářské práce. Nakonec jsou zmíněny jednotlivé subsystémy toho vybraného architektonického stylu a popsány technologie, které byly použity pro projekt. 2.1 Úvod do softwarové architektury Martin Fowler ve své knize [5] definuje softwarovou architekturu, jako rozdělení systému na jednotlivé komponenty na nejvyšší možné úrovni a jako rozhodnutí, která bývají v následujících krocích těžko měnitelná. Softwarová architektura tedy neřeší nějakou specifickou implementaci. Použijeme-li slova Martina Fowlera, jsou to hlavně rozhodnutí o rozvržení, rozdělení systému na menší části. Špatně navržený systém je nestabilní, nepodporuje možná budoucí obchodní rozhodnutí, těžko se strukturuje. Obrázek 2.1: User, Business, System [6] Systém by měl být navržen tak, aby vytvořil jistý konsenzus mezi uživatelem, obchodní částí a systémem jako takovým (viz obrázek 2.1). Softwarová architektura je nedílnou součástí strategie návrhu celého systému. Pokládá základní kámen celé struktuře. Je to vlastně první dekompozice požadavků od zákazníka. 5

20 6 KAPITOLA 2. SOFTWAROVÁ ARCHITEKTURA Pokud se bude jednat o rozsáhlé systémy, je nadmíru důležité správně separovat jednotlivé komponenty a přiřadit jim právě tu správnou zodpovědnost za daný úkol. Několik následujících principů objasňuje předchozí tvrzení [6]: Správná separace - je důležité správně rozdělit systémové komponenty tak, aby jejich funkcionality co nejméně přesahovaly vzájemně vlastní hranice. V podstatě jde o to docílit: vysoké koheze - snaha o co nejvyšší míru účelovosti dané komponenty (třídy...), tzn. snaha o to, aby daná komponenta dělala pouze to, co má a nezajišťovala toho příliš. nízkého couplingu - snaha o snížení závislostí či propojení na ostatních komponentech (knihovnách, třídách...) Jednoduchá zodpovědnost - jde o to, aby každá komponenta měla co nejužší specializaci a byla zodpovědná právě za jednu danou vlastnost, samozřejmě na dané míře abstrakce. Minimální indirekce (Demeterův zákon) - jedna komponenta by neměla vědět o interní struktuře druhé komponenty. Pravidlo "Neopakuj se!"(dry - Do not repeat yourself) - jednoduché pravidlo o neopakování zdrojového kódu. Pokud existují duplikace, zřejmě to znamená, že by měla existovat komponenta spravující právě tuto duplicitu. Posledním bodem je pravidlo o tom "nepiš, co nemáš". Je potřeba vytvořit systém dle požadavků zákazníka, ne nic navíc. 2.2 Architektonické vzory Architektonické vzory (styly) jsou v podstatě podtřídou softwarové architektury. Je důležité si uvědomit, že architektura není to samé co vzor. Může existovat mnoho různých architektur, které implementují stejné architektonické vzory a naopak. Lze říci, že softwarová architektura je první dekompozicí návrhu systému, která implementuje výběr daného vzoru. Jelikož softwarový projekt v této bakalářské práci je jednoduchý registrační systém, jeho návrh začíná právě výběrem architektonického stylu. Rozhodnutí použít architektonický vzor přináší důležitou výhodu, která spočívá v užití jistého společného jazyka popisující systém na určité úrovni abstrakce. Bez nutnosti znalosti konkrétní implementace je možné diskutovat o daném systému. Například u vzoru CLIENT- SERVER je dopředu definována jeho konstrukce a možnosti použití technologie. Díky tomu, že není potřeba se zabývat detaily implementace, je možné na této úrovni zajišťovat služby vrstvy byznys procesu. Níže jsou představeny některé základní architektonické vzory (Tabulka 2.1). Kromě těchto uvedených stylů existuje řada dalších jako např. PIPE AND FILTERS, DATACENTRICké styly, VIRTUAL MACHINE a další. Tento výběr je pouze ukázkou toho, že nějaké existují, že mají jisté vlastnosti, podle kterých je pak možné volit vhodný styl pro dané řešení.

21 2.2. ARCHITEKTONICKÉ VZORY 7 Architektonický vzor Client/Server Domain Driven Architecture Layered Architecture Message Bus N-TIER Object-Oriented Popis Rozděluje systém na dvě aplikace, kde často bývá, že server je databází s aplikační logikou, reagující na požadavky klienta Vytváří doménový model na základě byznys konceptu. Jeden z nejpoužívanějších stylů. Základní princip je používaní služeb nižších vrstev vrstvami vyššími. Ne naopak. Rozděluje systém na komponenty na různé úrovni abstrakce. Komponenty jsou propojeny sběrnicí, do které přispívají svými zprávami, které jsou po této sběrnici doručovány na daný cíl. Každá TIER je spuštěná na jiném hardwaru. Komponenty reprezentující TIER mají různou funkcionalitu na stejné úrovni abstrakce. Rozložení zodpovědností třídám, které zapouzdřují data a chování. Tabulka 2.1: Architektonické styly [6] N-TIER / 3-TIER vzor N-TIER aplikace má podobné vlastnosti jako aplikace vícevrstvá. Dekomponuje systém na jednotlivé TIER, které jsou uspořádány do vrstev. Každá vrstva komunikuje pouze s vrstvou přilehlou a to skrze vytvořené rozhraní. Důležitou vlastností N-TIER modelu je, že jednotlivé TIER či komponenty poskytují různou funkcionalitu na stejné úrovni abstrakce a že každá TIER může být spuštěna samostatně na jiném zařízení, hardware. Druhá ze zmíněných vlastností nabízí následující benefity: Spravovatelnost - jelikož každá TIER je nezávislá, umožňuje jednoduchou správu aktualizací a změn uvnitř TIER. Škálovatelnost - obdobnost s vrstevnatým vzorem přináší jasnou dekompozici komponent celého systému. Flexibilita - na základě předchozích dvou vlastností je zřejmá flexibilita. Na obrázku 2.2 je běžný aplikační model, na kterém je popsán příklad, jakým způsobem může být N-TIER aplikace modelována. Systém se skládá ze čtyř vrstev plus jedné cross-cutting vrstvy. V N-TIER aplikaci by se tyto vrstvy rozdělily do tří samostatných aplikací. Komunikace probíhá od klienta skrze vrstvy do databáze a zpět ke klientovi. Následuje výčet jednotlivých vrstev a popis, jaké služby mají zajistit [6]: Presentation Layer - prezentační vrstva nám zprostředkovává základní komunikaci s uživatelem, většinou se v podstatě považuje za grafické rozhraní celého systému. V architektonickém stylu klient-server představuje klienta. Může nabízet následující služby:

22 8 KAPITOLA 2. SOFTWAROVÁ ARCHITEKTURA Obrázek 2.2: Běžný aplikační model [6] Kompozice - navržení nezávislých komponent zprostředkovávající komponování grafického rozhraní za běhu aplikace. Zjednodušuje správu těchto komponent. Navigace - zajištění správné navigace celého systému umožní uživateli jednoduchý průchod a pochopení nabízené služby. Klientské rozhraní - nabízí grafické rozhraní pro uživatele. Validace - kontrola správného zadání údajů. Business Layer - tato vrstva je jádrem logiky celého systému. Většinou mívá tyto základní komponenty: Facade - jedná se o základní rozhraní celé byznys vrstvy (TIER) a zjednodušuje přístup klienta k ostatním komponentám uvnitř vrstvy. Business Workflow - tato komponenta, nebo set komponent zajišťuje proces zpracování dat, které přijdou od klienta. Kontrolují tok dat, nastavují pořadí zpracování dat. Business Entities - vytvářejí doménový model struktury systému. Definují objekty jako např. Uživatel, Nákup, Nákupní položka atp. Data Layer - hlavním úkolem této vrstvy je zajištění přístupu k databázi a doručení dat byznys vrstvě. Na tomto místě lze poprvé zmínit návrhové vzory. Přístup k databázi a doručení dat byznys vrstvě řeší např. DATA ACCESS OBJECT či přístup mapování této vrstvy k databázi řeší ACTIVE RECORD aj. Mezi vlastnosti této vrstvy patří:

23 2.2. ARCHITEKTONICKÉ VZORY 9 Konektivita - řeší způsob připojení k databázi (viz POOLING atd.) BLOB (Binary Large Objects) - umožňuje uložit perzistentně instance tříd (objektů) Transakce - zajišťuje práci s daty nad databází jako s atomickou jednotkou. Service Layer - servisní vrstva nám poskytuje přenos zpráv mezi prezentační a byznys vrstvou, byznys vrstvou a data TIER. V případě použití Transmission Control Protocol (TCP) služby nám zprostředkuje vytvoření potřebných soketů, zapouzdření komunikace a definuje rozhraní pro samotnou komunikaci. Z toho i vyplývají služby, které má zajistit: Vytvoření zpráv - od přilehlé vrstvy získává data, vytvoří zprávu, do které vloží přenášené data. Vytvoření kanálu - zajistí vytvoření potřebného kanálu pro přenos zpráv v rámci servisní vrstvy. Transformace zprávy - transformuje zprávu do podoby přizpůsobené přenášenému médiu. Ukončení zprávy - definuje ukončení přenosu. Směrování zprávy - zajistí správné doručení zprávy danému cíli. Cross-Cutting - tato speciální vrstva může některé služby celého systému soustředit do jednoho místa. Přináší to samozřejmě lepší servis dané služby či možnost jednoduché změny. Mezi tyto služby patří: Autentizace - slouží k jednoznačnému určení uživatele, který přistupuje k systému. Autorizace - proces ověření přístupových oprávnění uživatele vstupující do informačního systému. Logování - systém ukládající informace o změnách v systému. Cache - v závislosti na tom, jak moc tenký klient je, je možnost zvýšit výkonnost právě pomocí cache. Opět to poskytuje příležitost k užití návrhových vzorů, jakými jsou např. IDENTITY MAP či LAZY-LOAD. V podstatě jde o chytrost klienta v době, kdy získává odpovědi ze serveru. Pokud má pocit, že dané informace by mohl později potřebovat, uloží je do cache a při příštím dotazu již nemusí žádat server resp. databázi, ale sáhne pouze do cache. Management výjimek - dobře navržená služba správy výjimek zajistí stabilitu klienta Praktické použití architektonického vzoru Pro tuto bakalářskou práci byl vybrán N-TIER architektonický návrhový vzor. Spolu s klientserver a vrstevnatým systémem jsou to nejpoužívanější vzory při požadavcích na GUI (grafické uživatelské rozhraní), DB (databázi) a připojení přes TCP. Projekt splňuje základní vlastnost N-TIER aplikace. Každá TIER může běžet na jiném virtuálním stroji. Praktické použití N-TIER architektonického návrhu je znázorněno na obrázku 2.3. Příklad použití N-TIER vzoru z obrázku 2.3 lze stručně popsat následovně:

24 10 KAPITOLA 2. SOFTWAROVÁ ARCHITEKTURA Obrázek 2.3: N-TIER architektonický návrhový vzor Prezentační TIER (klient) - je v našem případě tenkým klientem, který zasílá požadavky na server a ten mu vrací odpověď. Při každé odpovědi sestavuje GUI, případně plní daty zaslanými serverem. Ověřuje pouze vstupy na úrovni datových typů a povinných položek. Servisní vrstva klienta zajišťuje služby komunikace (startuje soket, sestavuje spojení se serverem) doručuje a provádí dekompozici přenášených dat (doručování zpráv - paketů) zprostředkovává odeslání zpráv (paketů) TCP - přenosový protokol zaručující doručení paketů. Servisní vrstva byznys serveru zajišťuje služby komunikace (startuje soket server, vyčkává na připojení klienta) doručuje a provádí dekompozici přenášených dat (doručování zpráv - paketů) zprostředkovává odeslání zpráv (paketů) přiřazuje číslo relace poskytuje LOG Byznys TIER - udržuje logiku celého systému. Vytváří požadavky na datový server. RMI - vzdálené volání metod viz kapitola Servisní vrstva data serveru zprostředkovává instanci objektu (Driver) pro vzdálené volání poskytuje LOG

25 2.3. VÝČET POŽADAVKŮ NA SOFTWAROVÝ PROJEKT 11 Data TIER udržuje spojení s databází nabízí metody pro získání dat z databáze JDBC - viz kapitola DB - MySQL viz kapitola NetInterface - rozhraní paketu přenášeného mezi klientem a serverem. Každý paket je sám sebou požadavkem či odpovědí. Dle druhu paketu se volají příslušné metody na fasádách. Každý paket nese úložiště dat ve formě DATA TRANSFER OBJECT (DTO) 4.7. Přenos mezi klientem a serverem je objektový. 2.3 Výčet požadavků na softwarový projekt Softwarový projekt v této bakalářské práci má splňovat následující požadavky: Přihlášení - základní možnost přihlásit se k existujícímu účtu na základě jména a hesla Registrace - možnost vytvoření vlastního účtu v systému Vyhledávání uživatele - vyhledání informací o ostatních uživatelích Vyhledávání akce - vyhledat akci a její detailní informace Vyhledávání organizace - možnost najít informace o organizaci a jejích členech Přihlášení se na akci - možnost přihlášení se na vypsanou akci Odhlášení se z akce - možnost odhlášení se z akce Editace vlastního profilu - možnost dodatečně upravit své údaje Těchto několik požadavků bývá jádrem veškerých registračních systémů. Jedná se o úroveň user. Tedy bez editace či přidávání dalších instancí. Díky jednoduchosti tohoto modelu lze názorně ukázat aplikaci návrhových vzorů dle druhu použití. Systém bude ukládat data na perzistentní medium. Nakonec bude vytvořeno grafické uživatelské rozhraní pro uživatele. 2.4 Použité technologie a knihovny Programovací jazyk Java Systém byl vytvořen s pomocí Java Development Kit (JDK) JDK 1.6 a spuštěn a otestován na Java Real-time Engine (JRE) jre6. Použita byla standardní knihovna. Grafické uživatelské rozhraní bylo vytvořeno pomocí knihovny Swing, bez použití frameworku. Nebyl použit žádný aplikační server, při tvorbě byly využity možnosti standardních knihoven Standard Development Kit (SDK).

26 12 KAPITOLA 2. SOFTWAROVÁ ARCHITEKTURA Komunikační frameworky New I/O NIO zkratka New I/O je od roku 2004 součástí kitu JDK 1.4. Jedná se o zcela nový přístup spravování TCP rozhraní. Na rozdíl od předchozí verze I/O, kde každému připojenému klientu bylo vytvořeno samostatné vlákno, NIO tuto problematiku řeší jinak. Vkládá mezi soket a klientskou část na serveru tzv. selector, který přepíná mezi jednotlivými kanály tak, jak přichází požadavky od vzdáleného klienta. Ty pak předává vytvořeným instancím spravující vzdálené dotazy. Viz obrázek 2.4. Obrázek 2.4: Model New I/O [7] Remote Method Invocation Základní vlastností této knihovny je možnost volání objektů vytvořených na jiném virtuálním stroji. Pro získání reference na tento vzdálený objekt se využívá Remote Method Invocation (RMI) registry. Vzdálený server pomocí třídy rmi.naming zavede tzv. stub pro daný objekt a umožní klientovi či přistupujícímu serveru, aby referenci na tuto instanci z RMI registry zprostředkoval. Poté lze plnohodnotně s instancí pracovat. Veškeré výpočty a správa se děje právě na vzdáleném virtuálním stroji. Další informace viz webové stránky firmy Oracle [8] Perzistentní frameworky Java Data Base Connectivity Java Data Base Connectivity (JDBC) je služba (knihovna) poskytující rozhraní pro unifikovaný přístup k databázím. Je napsána přesně pro rozhraní java.sql.*. Pro použití této knihovny je potřeba zaregistrovat Driver pomocí Class.forName(), čímž je spuštěna statická metoda, která právě com.mysql.jdbc.driver zaregistruje do java.sql.drivermanager. Voláním pak objektu DriverManager lze získat přístup ke všem třídám JDBC.

27 2.4. POUŽITÉ TECHNOLOGIE A KNIHOVNY Databáze MySQL Perzistentním médiem v tomto systému je databázový server MySQL5.5 s engine InoDB.

28 14 KAPITOLA 2. SOFTWAROVÁ ARCHITEKTURA

29 Kapitola 3 Návrhové vzory Následující kapitola představuje strukturu publikace návrhových vzorů a jejich rozdělení. Je zde nastíněn základní modelovací jazyk a jeho elementární vztahy mezi objekty. Na závěr je předvedena ukázka použití návrhového vzoru. 3.1 Seznámení s návrhovými vzory Struktura S vydáním knihy "Design Patterns: Elements of Reusable Object-Oriented Software"[1] byla definována struktura publikace návrhového vzoru. Každý vzor by měl pokrývat tyto požadavky: Název vzoru - každý návrhový vzor by měl svým názvem dopředu identifikovat problematiku, kterou řeší. Definování problému - měl by jasně definovat problematiku a popsat vhodnost použití. Řešení problému - nejdůležitější je představení daného řešení. Popis je na úrovni abstrakce, ne konkrétní implementace, protože vzor by měl být šablonou řešení, která může být použita v různých situacích. Souvislosti - informace o souvislostech ve vztahu k ostatním objektům či návrhovým vzorům Rozdělení návrhových vzorů Návrhové vzory byly původně rozděleny do tří skupin (názvy skupin se obecně nepřekládají) [1]: Creational - slouží ke kontrole tvorby objektů. Pomáhají systému, aby se stal více nezávislým na zodpovědnosti, jak budou objekty tvořeny, komponovány a reprezentovány. Behavioral - účastní se tvorby algoritmů a delegují zodpovědnosti mezi jednotlivé objekty. 15

30 16 KAPITOLA 3. NÁVRHOVÉ VZORY Structural - vytvářejí strukturu celého systému. V dnešní době se počet těchto kategorií rozrostl dle oblasti, kterou dané návrhové vzory řeší, např.: Concurrency - řeší problematiku souběhu dvou či více vláken, žádající stejnou službu (např. OPTIMISTIC OFFLINE LOCK, PESSIMISTIC OFFLINE LOCK). View - navrhuje možné strategie prezentační vrstvy (např. MVC). Distribution - zajišťuje distribuci objektů v systému (např. DTO4.3.2). Session state - spravuje stavové objekty (např. CLIENT SESSION STATE, SERVER SESSION STATE) Unified Modeling Language - UML Unified Modeling Language vznikl za účelem potřeby vizualizace objektového modelování. Stal se vyšší vrstvou návrhu softwarových systémů. Zpřehlednil samotný návrh a umožnil zjednodušenou komunikaci při řešení daných problematik. V dnešní době je to základní modelovací nástroj. Níže jsou stručně popsány tři nejzákladnější (a zároveň nejkontroverznější) vztahy uvnitř návrhů: Asociace Obrázek 3.1: Příklad vztahu asociace Asociace je primární vztah v UML a spočívá v tom, že jeden objekt nějakým způsobem používá druhý objekt. Na níže uvedeném příkladě je specifikováno šipkou, že objekt Klub používá objekt Osoba. Pokud by zde šipka nebyla, mohou oba dva sebe vzájemně používat. Agregace a kompozice Agregace i kompozice jsou podtřídou asociace a blíže specifikuje asociační vlastnost. V obou případech se bude jednat o modelování jistého celku. Agregace definuje model jako rozložitelný celek. Na obrázku objekt Auto používá objekty Motor a Kolo. V tomto případě se jedná o rozložitelný celek, což dokazuje i převedení objektů do skutečného světa. Kolo z jednoho auta lze použít i na jiné, pokud jsou typově identická. Naopak kompozice demonstruje na obrázku celek, který rozložitelný již není. Zde funguje pravidlo - s nikým se neděl. Není možné vzít pokoj z jednoho domu a dát ho do druhého. Instanci třídy Pokoj může používat pouze jedna instance třídy Dům, nemůže dojít ke sdílení instancí.

31 3.2. PŘÍKLAD POUŽITÍ NÁVRHOVÉHO VZORU 17 Obrázek 3.2: Příklad vztahu agregace Obrázek 3.3: Příklad vztahu kompozice 3.2 Příklad použití návrhového vzoru Jak již bylo řečeno výše, návrhový vzor řeší jistou problematiku, která již byla řešena, otestována, proběhl proces připomínkování a oprav až došlo k jeho publikaci. Níže je představen první návrhový vzor COMMAND. Obrázek 3.4: Příklad návrhového vzoru - COMMAND

32 18 KAPITOLA 3. NÁVRHOVÉ VZORY Návrhový vzor COMMAND lze použít tehdy, když je potřeba volat metodu objektu, o které není nezbytné vědět, co přesně dělá. Pouze je zřejmé, že daný objekt metodu implementuje a že jakmile je tento objekt předán, tak se metoda zavolá. V níže uvedeném projektu je vzor COMMAND využit v případě volání metod objektu FACADE, který je vstupním rozhraním prezentační TIER. Postup je následující: Server ve své byznys logice vytvoří objekt LoginViewPacket, který má funkci zobrazení přihlašovacího formuláře. Pošle ho prostřednictvím TCP směrem ke klientovi, kde na něj čeká objekt PacketReceiver. PacketReceiver jediné co ví, že mu určitě dorazí objekt Packet (či jeho potomek), který implementuje metodu doit(). Přijme, v tomto případě, LoginViewPacket a zavolá na něm implementovanou metodu. Metoda volá metodu objektu Facade. Zobrazí se GUI přihlašovacího formuláře. Základní výhodou této konstrukce je, že není třeba složitě vytvářet dlouhý přepínač s jednotlivými možnostmi, ale pouze na základě druhu objektu Packet je volána příslušná metoda na Facade.

33 Kapitola 4 Softwarový projekt V poslední kapitole je popsána základní analýza a návrh softwarového projektu včetně výsledků testů. Jednotlivé podkapitoly, které se věnují popisu využití konkrétních návrhových vzorů, je rovněž možné využít jako tutorial při studiu návrhových vzorů. 4.1 Analýza a návrh Do této bakalářské práce byl vybrán architektonický vzor N-TIER, podrobně popsán v podkapitole Analýza a návrh tohoto projektu je tvořena napříč celým dokumentem. Úvodní informace o systému jsou v kapitole 2, dále požadavky na systém v kapitole 2.3 a přehled použité technologie v kapitole 2.4. Use Case diagram je zobrazen v přílohách jako obrázek B.1. V následujících podkapitolách je v rámci jednotlivých TIER vysvětleno použití jednotlivých návrhových vzorů. Na úvod každého návrhového vzoru je popis problematiky, kterou řeší, a dále pak jeho konkrétní implementace. V přílohách jsou pak k nalezení diagramy použitých návrhových vzorů k daným TIER, prezentační TIER B.7, byznys TIER B.8, data TIER B Prezentační TIER Singleton SINGLETON lze použít v případě, kdy je třeba zajistit u daného objektu, aby existovala pouze jediná instance v celé době běhu programu. Řešení v softwarovém projektu Třída Singleton má privátní konstruktor, privátní atribut Singleton a Synchronized statickou metodu getinstance(). Metoda zajišťuje při prvním volání vytvoření vlastní instance, při dalších volání již vrací tu jedinou vytvořenou. Singleton byl použit u následujících tříd: ViewFactory - zajišťuje tvorbu GUI 19

34 20 KAPITOLA 4. SOFTWAROVÝ PROJEKT Obrázek 4.1: Návrhový vzor - SINGLETON SessionFactory - vrací session dané komunikace SocketFactory - navrací vytvořený soket pro komunikaci TCP Builder BUILDER odděluje konstrukci složeného objektu od jeho reprezentace. Stejný konstrukční proces může nabídnout různou reprezentaci. Jednoduše řečeno, pokud jsou různé objekty sestavovány stále stejným procesem, lze tento proces automatizovat právě vzorem BUILDER. Obrázek 4.2: Návrhový vzor - BUILDER Řešení v softwarovém projektu Vzor BUILDER je využíván pro sestavování jednotlivých pohledů grafického rozhraní. Vždy je volán objekt Director, je mu předán konkrétní objekt Builder (LoginViewBuilder) a zavolána metoda buildview(). Každý vytvářený pohled prochází procesem vytvoření komponent, vložením hodnot, nastavením posluchačů (vzor OBSERVER), rozmístění komponent a nakonec vložením do zobrazeného JFrame. V první fázi jsou komponenty vytvořeny a uloženy do datové struktury ArrayList(JComponent), dále je toto pole objektů předáno třídě (např.

35 4.2. PREZENTAČNÍ TIER 21 LoginViewSetter) zajišťující vložení hodnot. Ta postupně prochází polem jednotlivých komponent a předá hodnoty dle požadavku. Třetí částí vzniku View je zaregistrování posluchačů. Průchodem polem objektů je přiřazen daným komponentám posluchač. Zároveň je připravena metoda, která z View získá potřebné hodnoty a nakonec je přiřazena akce, kterou má po zavolání posluchače komponenta vykonat Facade Vzor FACADE poskytuje jednotné rozhraní složité hierarchii subsystémů. Pokud je v projektu několik subsystémů a všechny potřebují komunikovat s okolím, právě FACADE zjednoduší přístup k vnitřním rozhraním. Obrázek 4.3: Návrhový vzor - FACADE Řešení v softwarovém projektu V prezentační a byznys TIER slouží vzor FACADE jako hlavní rozhraní celé vrstvy. Odstiňuje přistupující objekty od vnitřní implementace. Pomáhá zjednodušit přístup k funkcionalitám jednotlivých TIER tím, že soustředí metody jednotlivých funkcí na jedno místo. FACADE v tomto projektu je součástí celého NetInterface, které je komunikačním protokolem přenášených dat po TCP mezi prezentační a byznys TIER Composite Vzor COMPOSITE komponuje objekty do stromové struktury. Vytváří složené objekty. Pomáhá zjednodušit manipulaci s objekty, které tvoří hierarchickou strukturu. Poté lze voláním jednoho objektu volat i všechny ostatní, které jsou v dané hierarchii. Řešení v softwarovém projektu Jsou využívány kompozitní struktury tvorby menu v knihovně javax.swing.*, které jsou postaveny na návrhovém vzoru COMPOSITE. Základním principem je, že všechny třídy tvořící samotné menu (JMenu, JMenuItem, JMenuBar...) dědí od tříd Container a JComponent. Dědění od těchto tříd předává svým potomkům kompozitní vlastnost, jak na úrovni třidy Container (mohu vkládat, či odstraňovat jednotlivé komponenty), tak zajišťuje vykreslení skrze třídu JComponent (její metodu paint(), resp. repaint()).

36 22 KAPITOLA 4. SOFTWAROVÝ PROJEKT Obrázek 4.4: Návrhový vzor - COMPOSITE State Vzor STATE umožňuje objektům měnit své chování na základě vnitřního stavu za běhu programu. Řeší nahrazení struktury case či if objektovým přístupem. Objekt se navenek chová dle aktuálního stavu, resp. dle právě použité třídy reprezentující stav. Obrázek 4.5: Návrhový vzor - STATE

37 4.2. PREZENTAČNÍ TIER 23 Řešení v softwarovém projektu Vzor STATE pomáhá specifikovat zobrazení grafických komponent na základě role uživatele. Tento návrhový vzor je využíván jako vnitřní stav celé TIER, na kterou se pak jednotlivé komponenty odkazují, a dle stavu se zobrazí či nikoliv. Např. u třídy RoleUser metoda isuser() vrací true, ale metody isaction() a ismanager() vrací false. Potom např. tlačítko AddAction při volání své metody isvisible(boolean) volá jako vstupní parametr metodu isaction() instance třídy, která implementuje rozhraní RoleUser. Pokud bude mít uživatel přiřazena práva pro správu akcí, potom bude implementovat třídu RoleAction a všechny funkcionality úrovně action bude mít zpřístupněné Command Návrhový vzor COMMAND a jeho využití byly již představeny v podkapitole 3.4. Obrázek 4.6: Návrhový vzor - CHAIN OF RESPONSIBILITY Chain of Responsibility V rámci do řetězu spojených objektů, je předáván požadavek na vyřízení tomu objektu, který daný požadavek vyřídí. V podstatě se jedná o předání zodpovědnosti objektu, kterému tato zodpovědnost byla přidělena. Řešení v softwarovém projektu Vzor CHAIN OF RESPONSIBILITY spolupracuje s návrhovým vzorem STRATEGY, kde rozhoduje strategii zpracování požadavku od uživatele. Pokud není schopen požadavek zpracovat, předává ho dál k vyřízení jiným třídám. Vzor je demonstrován na úrovni rozhraní jednotlivých tříd. Detailněji lze popsat na názorném příkladě. Např. ošetření vstupů je řešeno na úrovni prezentační TIER. Třída implementující rozhraní ActionInterface vykonává akce, které vyvolává uživatel systému. Každé akci je přidělena jistá zodpovědnost za to, co má sama zprostředkovat a co má předat dále na byznys TIER. K tomuto předávání zodpovědností slouží právě CHAIN OF RESPONSIBILITY.

38 24 KAPITOLA 4. SOFTWAROVÝ PROJEKT 4.3 Byznys TIER Memento Vzor MEMENTO slouží k uchování vnitřního stavu objektu, bez porušení jeho zapouzdření. Často se využívá při implementování služeb Undo či Checkpoint. Základním principem je uchování vnitřního stavu objektu buď na perzistentním úložišti, nebo v paměti, aniž by byla porušena struktura zapouzdření mechanizmu STATE. Řešení v softwarovém projektu Vzor MEMENTO je využit k uchování stavu prezentační TIER resp. jeho role. U jednotlivých uživatelů jsou uchovávány instance tříd implementující rozhraní Role např. RoleUser. K perzistenci slouží databáze s využitím vzoru SERIALIZED LOB Obrázek 4.7: Návrhový vzor - DTO Data Transfer Object Vzor DATA TRANSFER OBJECT (DTO) se zvolí, pokud je třeba přenést složitější konstrukci dat či např. v Java u metod navrátit více než jednu hodnotu. Tento princip je často využíván při přenosu dat v rámci systému či jeho modulů. Často totiž nestačí přenášet pouze jeden parametr resp. jeden datový typ. Konstrukce DATA TRANSFER OBJECT, která nám zapouzdřuje námi požadovaná data, usnadňuje jak komunikaci napříč systémem, tak mezi systémy. Nevýhodou může být vázanost na programovací technologii. Je potřeba zvážit při analýze a návrhu. Řešení v softwarovém projektu Vzor DTO zajišťuje přenos dat v rámci celého systému. Je doménově orientovaný, tzn. přenáší existující objekty. Mezi prezentační TIER a byznys TIER zapouzdřuje objekty jako DTO- Person či DTOOrganization. Např. DTOPerson má jako své atributy String login, String password, String name, String surname atp. Takto vytvořená struktura přenosu zjednodušuje a zpřehledňuje celý systém.

39 4.3. BYZNYS TIER Proxy Vzor PROXY zajišťuje kontrolu nad přístupem k jinému objektu. Mezi nejznámější vzory asi patří RemoteProxy, který poskytuje lokální reprezentaci objektů volaných ze vzdáleného cíle. Poskytuje sadu rozhraní, které tvoří přístup ke vzdáleným objektům. Obrázek 4.8: Návrhový vzor - PROXY Řešení v softwarovém projektu Vzor PROXY slouží jako zprostředkovatel rozhraní pro přístup do datové TIER. Skrze PROXY lze získat vzdálenou instanci DAOFactory, která dovoluje přistoupit do databáze. Jádrem PROXY je zde instance třídy Driver uložená v RMIregistry 2.4.2, kterou skrze rozhraní DriverInterface získá objekt DAOFactoryProxy. Tento mechanizmus je použit i při zavádění driveru v JDBC Po zavedení nezbytně nutného ovladače je získán kompletní přístup ke všem objektům v data TIER. Druh perzistentního media je vybrán parametrem uvnitř DAOFactory Table module Vzor TABLE MODULE je rozhodnutí o struktuře byznys logiky mezi třemi možnostmi - TRANSACTION SCRIPT, DOMAIN MODEL, TABLE MODULE [5]. Transaction Script - je nejjednodušším přístupem. Pokud na server přijde požadavek od klienta, vytvoří se transakce, provedou se potřebné změny v databázi, uzavře se transakce, pošle se odpověď na klienta. Každý dotaz má svou proceduru, která ho zpracovává. Domain Model - vyplatí se u složitějších systémů, kde se vytváří topologie objektů, které spolu v dané logice komunikují. Každý objekt zodpovídá za svou činnost. Bývá složitější mapovat rozhraní pro přístup do databáze. Table Module - každá tabulka v databázi má svou třídu v byznys logice, která ji reprezentuje. Tato třída pak obsahuje metody, které tvoří celou logiku systému.

40 26 KAPITOLA 4. SOFTWAROVÝ PROJEKT Rozhodnutí o výběru dané struktury je zásadní v dalších krocích. Těžko se refaktoruje z jedné možnosti na druhou. Je na zvážení, jakým způsobem se systém může změnit, rozrůst atd. Řešení v softwarovém projektu V tomto projektu byl zvolen TABLE MODULE. TRANSACTION SCRIPT by se jevil jako ideální volba, ale TABLE MODULE dává jistý přehled v tom, který objekt co dělá. V této konkrétní byznys logice existují právě třídy jako Person, Organization či Action. 4.4 Data TIER Abstract Factory Vzor ABSTRACT FACTORY poskytuje interface pro zastřešení konkrétních Factory, které řeší stejný problém různým způsobem. Abstrakce zde slouží jako rozhraní, které definuje strukturu a požadavky tříd Factory, které tuto abstrakci implementují. Obrázek 4.9: Návrhový vzor - ABSTRACT FACTORY Řešení v softwarovém projektu V tomto projektu je použit vzor ABSTRACT FACTORY pro zastřešení továrny DAOFactoryJDBC, která skrze JDBC nabízí přístup do databáze. Uvnitř třídy DAOFactory, abstraktní továrny, je naznačena možnost použití i jiné továrny DAOFactoryODBC, která by mohla zpřístupnit jiné typy databází např. Oracle. Stejně tak by mohla být vytvořena továrna pro uložení do souboru. Výhodou je, že změnou jednoho parametru je možné okamžitě připojit jiné médium a pracovat s ním bez potřeby upravit zbylý kód. Struktura abstrakce v tomto případě musí být navržena velmi pečlivě s ohledem na možné implementace Data Access Object Vzor DATA ACCESS OBJECT poskytuje data z databáze prostřednictvím svých metod. DATA ACCESS OBJECT může být různě mapován - viz podkapitola Společnou

41 4.4. DATA TIER 27 vlastností je specifičnost pro různá přístupová média a definované rozhraní pro stejný druh funkčnosti. Např. pokud bude potřeba uložit informace o uživateli jako např. jeho jméno a příjmení a bude požadována možnost uložení na pevný disk nebo do databáze, vytvoří se dvě třídy, které budou implementovat stejné rozhraní s metodami např. vložuživatele(), vraťuživatele(). Bude se tedy jednat o dvě třídy, které budou nabízet tyto služby, ale budou různě implementovány. Pak jednoduchým výběrem třídy resp. továrny lze přistoupit k vybranému médiu. Obrázek 4.10: Návrhový vzor - DATA ACCESS OBJECT Řešení v softwarovém projektu Na obrázku B.5 je znázorněna celá implementace DATA ACCESS OBJECT včetně FAC- TORY, který vytváří jednotlivé objekty. Hlavní výhodou tohoto přístupu je odstínění konkrétní implementace skrze ABSTRACT FACTORY a rozhraní jednotlivých DATA ACCESS OBJECT. Klient, v tomto případě byznys TIER, pouze vlastní rozhraní na celý tento přístup k databázi a implementaci ponechává na straně Data TIER Pooling Vzor POOLING nabízí řešení zajišťující sdílení vytvořených instancí v rámci systému či subsystému. Využije se v případě, že tvorba instance je příliš drahá. Pokud se vyplatí udržovat živé instance tříd oproti jednotlivým tvorbám instancí, které poskytují určitou službu, právě POOLING se stará o zprostředkování mezi přistupující uživatele resp. objekty. Zajišťuje perzistenci či držení v paměti nabízených instancí tříd, jejich distribuci a opětovné navrácení do úložiště pool. Řešení v softwarovém projektu Tato konstrukce byla využita v případě sdílení vytvořených připojení do databáze. Při inicializaci se systém automaticky spojí s databází pomocí deseti vytvořených spojení a tyto

42 28 KAPITOLA 4. SOFTWAROVÝ PROJEKT Obrázek 4.11: Návrhový vzor - POOLING instance pak udržuje v úložišti pool. Pokud přistupující klient potřebuje komunikovat s databází, volá továrnu ConnectionPool, která vrátí jednu z volných deseti připojení. Toto řešení zvyšuje rychlost vybavení klienta resp. jeho požadavků Active Record Vzor ACTIVE RECORD je způsob mapování DATA ACCESS OBJECT k databázi. Existuje několik přístupů, zde jsou uvedeny tři nejznámější: Row Data Gateway - objekt, který svými atributy odpovídá přesně jedné instanci v tabulce. Metody pak pokrývají základní databázové dotazy, jako např. insert, update, delete. Table Data Gateway - objekt odpovídá přesně celé tabulce. Nemá atributy, vstupní data se předávají, jako parametry metod. Metody vracejí celé record sety. Active Record - podobá se vzoru ROW DATA GATEWAY. Navíc má metody, které jsou spojeny s byznys logikou, např. getregisteredperson(name Action), metoda která vrací seznam všech instanci třídy Person, které jsou přihlášeni na danou akci. Pomocí základních dotazů vytvoří složitější dotaz. Pro více informací viz publikace [5] od Martina Fowlera. Řešení v softwarovém projektu Vzor ACTIVE RECORD svým provedením nabízí plné využití Standard Query Language(SQL) dotazů do databáze. Tím se přesouvá část výpočtů na datový server a rozkládá tak zátěž na jednotlivé TIER. DATA ACCESS OBJECT třídy jsou mapovány na instance jednotlivých tabulek s tím, že nabízejí komfortnější metody pro přenos dat s databází.

43 4.5. TESTOVÁNÍ Foreign Key Mapping FOREIGN KEY MAPPING (cizí klíč) je základním integritním omezením na úrovni databáze. Definují se tím jisté povinnosti, vlastnosti vzájemných asociací mezi tabulkami. Na obrázku 4.12 je tabulka person, která má jako jeden z atributů hodnotu ID. Toto číslo je jedinečné a existující uživatel má právě jedno. Ve druhé tabulce role jsou skrze ID přiřazovány uživatelům jejich role. Hodnota ID v tabulce role je definovaná jako FOREIGN KEY, čímž se říká, že pokud neexistuje instance v tabulce person s daným ID, nemůže existovat ani instance s tímto ID v tabulce role. Vzájemně se to vylučuje. Cizím klíčem jsou vlastně vysouvány atributy jedněch tabulek do druhých. Obrázek 4.12: Návrhový vzor - FOREIGN KEY MAPPING Řešení v softwarovém projektu Implementaci vzoru FOREIGN KEY MAPPING znázorňuje obrázek B Serialized LOB Vzor SERIALIZED LOB umožňuje uložení objektů na perzistentní úložiště. Pokud je např. potřeba uložit složitější strukturu objektů, vytvoří se jeden, který ostatní zapouzdří a jako bajtový proud pak uloží na perzistentní medium. Řešení v softwarovém projektu SERIALIZED LOB byl využit pro uchování instancí tříd, které implementují rozhraní Role jednotlivých uživatelů (tabulka role) B Testování Testy tohoto softwarového projektu byly provedeny za účelem snížení výskytu chyb na minimum. Testovalo se na těchto úrovních: Jednotkové testy Integrační testy

44 30 KAPITOLA 4. SOFTWAROVÝ PROJEKT Validační testy Systémové testy Jednotkové testy Jednotkové testy slouží ke zjištění správné funkčnosti a stability na úrovni nejmenších jednotek čili tříd. Otestovány byly třídy reprezentující objekty DATA ACCESS OBJECT metodou white-box, kde hlavním požadavkem je úplný přehled o struktuře jednotlivých tříd. Jako nástroj bylo použito vývojové prostředí NetBeans s nástrojem JUnitTest 4.5. Výstupy testů byly vypsány buď přímo do konzole, nebo byly ověřeny přímo v databázi. Následující tabulka přináší ukázku výsledku testů třídy DAOPersonJDBC (P - předpokládaný výstup, T - otestovaný výstup, V - výsledek): Č. Test Vstup P T V 1 existlogin(login) "milerjo1" true true OK 2 existlogin(login) "" false false OK 3 existlogin(login) "select login from person false false OK where login = milerjo1 " 4 existperson(login,password) "root","root" true true OK 5 existperson(login,password) "root","snizemic" false false OK 6 existperson(login,password) "", "" false false OK Tabulka 4.1: Jednotkové testy Jednotkové testy byly provedeny na následujících třídách: DAOActionJDBC DAOAddressJDBC DAOContractJDBC DAOOrganizationJDBC DAOPersonJDBC DAORoleJDBC ObjectHolder

45 4.5. TESTOVÁNÍ Integrační testy Integrační testy jsou založené na testování postupné konstrukce celého systému. Z pohledu jednotkového testování se jedná o slučování jednotek do subsystému a na něm pak aplikované testy. V této části testování byly použity dva přístupy [9]: Strukturální testování (White-box testing) - zaměřuje se na otestování cest, resp. všech rozhodovacích větví, zda-li jsou všechny použity, zda-li jsou korektně použity atp. Inkrementální testování - začíná testováním od prvních dvou modulů, odstraňuje chyby, poté přidává další modul a opět testuje a odstraňuje chyby až do úplného vytvoření systému. Strukturální testování Strukturální testování je zaměřeno především na zajištění správného průchodu rozhodovacích větví. Na obrázku B.10 je zobrazení otestování modulu vlastního profilu. Byly provedeny následující testy průchodu 4.2: Cesta Popis Výsledek 1, true, 4 defaultní zobrazení MyView, načtou se data z DB o OK přihlášeném uživateli 2, false, 4 aktualizace zobrazení organizace v JComboBox OK 3, false, false, 4 updateperson s nevyplněnými povinnými položkami OK 3, true, true, 5 updateperson bez příslušné organizace OK 3, true, false, 5 updateperson s příslušnou organizací OK Tabulka 4.2: Strukturální testy Strukturální testy byly provedeny na modulech byznys logiky: vyhledávací modul modul autentizace registrační modul modul správy akcí modul správy organizací modul vlastního profilu

46 32 KAPITOLA 4. SOFTWAROVÝ PROJEKT Inkrementální testování Principem inkrementálního testování je postupné testování, počínaje u dvou komponent. Tyto dvě komponenty se otestují, odstraní chyby a postupně se přidávají další části. Opět se testuje a odstraňují chyby. Takto se postupuje až do vytvoření celého systému. V softwarovém projektu vypracovaném do této bakalářské práce byly použity následující principy inkrementálního testování: Od shora dolů testování - tímto principem byly vyvíjeny a zároveň testovány jednotlivé TIER: Prezentační TIER - rozložení grafických komponent, komunikační engine, ošetření vstupů, objektový interface. Byznys TIER - komunikační engine, log modul, objektový interface. Datová TIER - komunikační rozhraní (RMI, JDBC), log modul. Sandwich integrační testování - tímto principem byla testována byznys logika byznys TIER. Kombinací těchto dvou principů byl vytvořen a otestován celý systém N-TIER aplikace na úrovni integračního testování. V tabulce 4.3 je příklad testů rozložení grafických komponent: Test Label TextField Button ComboBox Výsledek LoginView "Login", "Password", "Note" RegisterView "Login", "Password", "Name", "Surname", " ", "Note" "Login", "Password" "Login", "Password", "Name", "Surname", " ", "LogIN", "Register" "Register" Tabulka 4.3: Inkrementální testy OK OK Validační testy Validační testy se provádí po dokončené integraci a slouží k ověření, že požadavky, které byly od zákazníka vzneseny, jsou splněny. Testy byly provedeny metodou black-box. Tester je tedy odstíněn od dané implementace a zajímá ho pouze jaký bude výstup na základě jeho vstupu. V rámci této části byly provedeny následující testy: Ošetření vstupů - povinné položky, formát hodnoty datum.

47 4.5. TESTOVÁNÍ 33 Zobrazení všech View - průchod v menu, souvisí s následujícím bodem, tabulka 4.4 (V - výsledek). Postupný průchod všemi funkcionalitami - testovacími daty otestovány všechny nabízené funkce jako např. updatemyprofile, signin, signoff, detailaction. View V View V View V LoginView OK RegisterView OK SearchPersonView OK ActionAddView OK ActionView OK Menu OK OrganizationAddView OK OrganizationView OK PersonDetailView OK PersonMyView OK PersonAddView OK OK Tabulka 4.4: Validační testy - Zobrazení všech View Systémové testy Systémové testy byly provedeny hlavně se zaměřením na stabilitu byznys a data TIER. Výsledkem by měla být právě informace o tom, zda-li obě zmíněné TIER pracují dále bez jakékoliv kolize. Byly provedeny následující testy, viz tabulka 4.5 (V - výsledek): Test Přerušení komunikace na úrovni TCP mezi prezentační TIER a byznys TIER Ukončení aplikace (prezentační TIER) Více klientů (Concurrency) V OK OK OK Tabulka 4.5: Systémové testy

48 34 KAPITOLA 4. SOFTWAROVÝ PROJEKT

49 Závěr Tato bakalářská práce měla za cíl představit návrhové vzory jako programovací nástroj a následně na konkrétním příkladě předvést praktickou implementaci některých z objektových návrhových principů. První část se věnovala nezbytnému teoretickému základu, který se dotýkal softwarové architektury, architektonických stylů a úvodu do návrhových vzorů. Druhá, praktická část, spočívala v prezentaci vlastního softwarového projektu. Pro účely této bakalářské práce byl vytvořen jednoduchý model registračního systému, který využíval principů návrhových vzorů. Praktická implementace umožnila pochopit roli jednotlivých návrhových vzorů, zobrazila vazby mezi použitými vzory i jejich chování v rámci celého systému. Při zpracování této bakalářské práce bylo využito cca 20 návrhových vzorů a principů. Během práce na projektu se potvrdila kvalita konstrukce vybraných návrhových vzorů. Jejich implementace zpřehlednila celý softwarový návrh a položila dobré základy pro případné pozdější modifikace. Závěrem je třeba zdůraznit, že tento projekt představuje jen jednu z možných variant použití návrhových vzorů, která vznikla na základě určitého rámce naplánovaného na začátku práce. Po dokončení zpracování projektu se autorovi této bakalářské práce jeví další možnosti zlepšení funkcionalit a využití dalších návrhových vzorů. Následující úpravy a rozpracování by ale přesahovaly rozsah této bakalářské práce. 35

50 36 KAPITOLA 4. LITERATURA

51 Literatura [1] Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, Boston, 2nd edition, [2] Christopher Alexander, Sara Ishikawa, MurraySilverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, New York, [3] Mike O Docherty. Object-Oriented Analysis and Design: Understanding System Development with UML 2.0. John Wiley and Sons Ltd, West Sussex, England, 1st edition, [4] Ilja Kravál. Design Patterns v OOP. Praha, 1st edition, [5] Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford. Patterns of Enterprise Application Architecture. Addison Wesley, Boston, 1st edition, November 05, [6] S. Somasegar, Scott Guthrie, and David Hill. Microsoft Application Architecture Guide. Microsoft, 2nd edition. [7] Jakob Jenkov. Java nio. < [Online 15. duben 2011]. [Citace: 7. květen 2011.]. [8] Oracle. Rmi. < [Online 27. duben 2011]. [Citace: 7. květen 2011.]. [9] B.B.Agarwal, S.P. Tayal, and M. Gupta. Software Engeneering and Testing. Jones and Bartlett Publishers, Sudbury, Massachusetts, 1st edition,

52 38 LITERATURA

53 Příloha A Seznam použitých zkratek BLOB DAO DB DRY DTO GUI JDBC JDK JRE MVC NIO OOPSLA RMI SDK SQL SW TCP UML Binary Large Objects Database Access Object Databáze Dont repeat yourself Data Transfer Object Graphical User Interface Java Data Base Connectivity Java Development Kit Java Real-Time Engine Model View Controler New I/O (input/output) Object-Oriented Programming, Systems, Languages and Applications Remote Method Invocation Standard Development Kit Standard Query Language Software Transmission Control Protocol Unified Modeling Language 39

54 40 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

55 Příloha B Diagramy Obrázek B.1: Use Case Model 41

56 42 PŘÍLOHA B. DIAGRAMY Obrázek B.2: Class Diagram - Prezentační TIER (bez ServiceLayer)

57 Obrázek B.3: Class Diagram - Prezentační TIER (ServiceLayer) 43

58 44 PŘÍLOHA B. DIAGRAMY Obrázek B.4: Class Diagram - Byznys TIER

59 Obrázek B.5: Class Diagram - Data TIER 45

60 46 PŘÍLOHA B. DIAGRAMY Obrázek B.6: Datový model