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

Č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

iv

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.

vi

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 25. 5. 2011

.............................................................

viii

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

x

Obsah Úvod

1

1 Význam a využití návrhových principů

3

2 Softwarová architektura 2.1 Úvod do softwarové architektury . . . . . 2.2 Architektonické vzory . . . . . . . . . . . 2.2.1 N-TIER / 3-TIER vzor . . . . . . 2.2.2 Praktické použití architektonického 2.3 Výčet požadavků na softwarový projekt . 2.4 Použité technologie a knihovny . . . . . . 2.4.1 Programovací jazyk . . . . . . . . . 2.4.2 Komunikační frameworky . . . . . 2.4.3 Perzistentní frameworky . . . . . . 2.4.4 Databáze . . . . . . . . . . . . . . 3 Návrhové vzory 3.1 Seznámení s návrhovými vzory . . . . . . 3.1.1 Struktura . . . . . . . . . . . . . . 3.1.2 Rozdělení návrhových vzorů . . . . 3.1.3 Unified Modeling Language - UML 3.2 Příklad použití návrhového vzoru . . . . . 4 Softwarový projekt 4.1 Analýza a návrh . . . . . . . . 4.2 Prezentační TIER . . . . . . . 4.2.1 Singleton . . . . . . . . 4.2.2 Builder . . . . . . . . . 4.2.3 Facade . . . . . . . . . . 4.2.4 Composite . . . . . . . . 4.2.5 State . . . . . . . . . . . 4.2.6 Command . . . . . . . . 4.2.7 Chain of Responsibility 4.3 Byznys TIER . . . . . . . . . . 4.3.1 Memento . . . . . . . . 4.3.2 Data Transfer Object .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

xi

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . vzoru . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . .

5 5 6 7 9 11 11 11 12 12 13

. . . . .

15 15 15 15 16 17

. . . . . . . . . . . .

19 19 19 19 20 21 21 22 23 23 24 24 24

xii

OBSAH

4.4

4.5

4.3.3 Proxy . . . . . . . . . 4.3.4 Table module . . . . . Data TIER . . . . . . . . . . 4.4.1 Abstract Factory . . . 4.4.2 Data Access Object . 4.4.3 Pooling . . . . . . . . 4.4.4 Active Record . . . . . 4.4.5 Foreign Key Mapping 4.4.6 Serialized LOB . . . . Testování . . . . . . . . . . . 4.5.1 Jednotkové testy . . . 4.5.2 Integrační testy . . . . 4.5.3 Validační testy . . . . 4.5.4 Systémové testy . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

25 25 26 26 26 27 28 29 29 29 30 31 32 33

Závěr

35

Literatura

37

A Seznam použitých zkratek

39

B Diagramy

41

C Obsah přiloženého CD

51

Seznam obrázků 1.1

Základní model tvorby software . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4

User, Business, System [6] . . . . . . . Běžný aplikační model [6] . . . . . . . N-TIER architektonický návrhový vzor Model New I/O [7] . . . . . . . . . . .

3.1 3.2 3.3 3.4

Příklad Příklad Příklad Příklad

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12

Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový Návrhový

B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10

4

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 5 . 8 . 10 . 12

vztahu asociace . . . . . . . . . vztahu agregace . . . . . . . . . vztahu kompozice . . . . . . . . návrhového vzoru - COMMAND

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

16 17 17 17

SINGLETON . . . . . . . . . . BUILDER . . . . . . . . . . . . FACADE . . . . . . . . . . . . . COMPOSITE . . . . . . . . . . STATE . . . . . . . . . . . . . . CHAIN OF RESPONSIBILITY DTO . . . . . . . . . . . . . . . PROXY . . . . . . . . . . . . . ABSTRACT FACTORY . . . . DATA ACCESS OBJECT . . . POOLING . . . . . . . . . . . . FOREIGN KEY MAPPING . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

20 20 21 22 22 23 24 25 26 27 28 29

Use Case Model . . . . . . . . . . . . . . . . . . . . . . Class Diagram - Prezentační TIER (bez ServiceLayer) Class Diagram - Prezentační TIER (ServiceLayer) . . . Class Diagram - Byznys TIER . . . . . . . . . . . . . . Class Diagram - Data TIER . . . . . . . . . . . . . . . Datový model . . . . . . . . . . . . . . . . . . . . . . . Přehled použitých vzorů - prezentační TIER . . . . . . Přehled použitých vzorů - byznys TIER . . . . . . . . Přehled použitých vzorů - data TIER . . . . . . . . . . Strukturální testování . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

41 42 43 44 45 46 47 48 49 50

vzor vzor vzor vzor vzor vzor vzor vzor vzor vzor vzor vzor

-

xiii

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1

Architektonické styly [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 4.2 4.3 4.4 4.5

Jednotkové testy . . . . . . . . . . . . Strukturální testy . . . . . . . . . . . . Inkrementální testy . . . . . . . . . . . Validační testy - Zobrazení všech View Systémové testy . . . . . . . . . . . . .

xv

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 30 31 32 33 33

xvi

SEZNAM TABULEK

Ú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

2

ÚVOD

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

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.

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

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 CLIENTSERVER 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í.

2.2. ARCHITEKTONICKÉ VZORY

Architektonický vzor Client/Server

Domain Driven Architecture Layered Architecture

Message Bus

N-TIER

Object-Oriented

7

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]

2.2.1

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:

8


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 4.4.2 či přístup mapování této vrstvy k databázi řeší ACTIVE RECORD 4.4.4 aj. Mezi vlastnosti této vrstvy patří:

2.2. ARCHITEKTONICKÉ VZORY

9

– Konektivita - řeší způsob připojení k databázi (viz POOLING 4.4.3 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.

2.2.2

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ě:

10


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 2.4.2 • Servisní vrstva data serveru – zprostředkovává instanci objektu (Driver) pro vzdálené volání – poskytuje LOG

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 2.4.3 • DB - MySQL viz kapitola 2.4.4 • 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 2.4.1

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

12

2.4.2


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

2.4.3

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.

2.4. POUŽITÉ TECHNOLOGIE A KNIHOVNY

2.4.4

Databáze

MySQL Perzistentním médiem v tomto systému je databázový server MySQL5.5 s engine InoDB.

13

14


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

3.1.2

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

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

3.1.3

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

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

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.

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 2.2.1. 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.9.

4.2 4.2.1

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

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

4.2.2

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

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.

4.2.3

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.

4.2.4

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()).

22


Obrázek 4.4: Návrhový vzor - COMPOSITE

4.2.5

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

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

4.2.6

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

4.2.7

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.

24

4.3 4.3.1


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

Obrázek 4.7: Návrhový vzor - DTO

4.3.2

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 DTOPerson č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.

4.3. BYZNYS TIER

4.3.3

25

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

4.3.4

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.

26


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 4.4.1

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.

4.4.2

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 4.4.4. Společnou

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ě FACTORY, 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.

4.4.3

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

28


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

4.4.4

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

4.5. TESTOVÁNÍ

4.4.5

29

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

4.4.6

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

4.5

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

30


• Validační testy • Systémové testy

4.5.1

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 6.9.1 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):

Č. 1 2 3 4 5 6

Test existLogin(login) existLogin(login) existLogin(login)

Vstup "milerjo1" "" "select login from person where login = ’milerjo1’" existPerson(login,password) "root","root" existPerson(login,password) "root","snizemic" existPerson(login,password) "", "" Tabulka 4.1: Jednotkové testy

Jednotkové testy byly provedeny na následujících třídách: • DAOActionJDBC • DAOAddressJDBC • DAOContractJDBC • DAOOrganizationJDBC • DAOPersonJDBC • DAORoleJDBC • ObjectHolder

P true false false

T true false false

V OK OK OK

true false false

true false false

OK OK OK

4.5. TESTOVÁNÍ

4.5.2

31

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 1, true, 4 2, 3, 3, 3,

false, 4 false, false, 4 true, true, 5 true, false, 5

Popis defaultní zobrazení MyView, načtou se data z DB o přihlášeném uživateli aktualizace zobrazení organizace v JComboBox updatePerson s nevyplněnými povinnými položkami updatePerson bez příslušné organizace updatePerson s příslušnou organizací 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

Výsledek OK OK OK OK OK

32


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 LoginView

Label "Login", "Password", "Note" RegisterView "Login", "Password", "Name", "Surname", "Email", "Note"

TextField "Login", "Password"

Button "LogIN", "Register"

ComboBox Výsledek OK

"Login", "Register" "Password", "Name", "Surname", "Email",

OK

Tabulka 4.3: Inkrementální testy

4.5.3

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.

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 LoginView ActionAddView OrganizationAddView PersonMyView

V OK OK OK OK

View RegisterView ActionView OrganizationView PersonAddView

V OK OK OK OK

View SearchPersonView Menu PersonDetailView

V OK OK OK OK

Tabulka 4.4: Validační testy - Zobrazení všech View

4.5.4

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) Tabulka 4.5: Systémové testy

V OK OK OK

34


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

36

KAPITOLA 4. LITERATURA

Literatura [1] Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, Boston, 2nd edition, 1995. [2] Christopher Alexander, Sara Ishikawa, MurraySilverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977. [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, 2005. [4] Ilja Kravál. Design Patterns v OOP. http://www.objects.cz, Praha, 1st edition, 2002. [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, 2002. [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, 2010.

37

38

LITERATURA

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

40

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

Příloha B

Diagramy

Obrázek B.1: Use Case Model

41

42

PŘÍLOHA B. DIAGRAMY

Obrázek B.2: Class Diagram - Prezentační TIER (bez ServiceLayer)

43

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

44


Obrázek B.4: Class Diagram - Byznys TIER

45

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

46


Obrázek B.6: Datový model

47

Obrázek B.7: Přehled použitých vzorů - prezentační TIER

48


Obrázek B.8: Přehled použitých vzorů - byznys TIER

49

Obrázek B.9: Přehled použitých vzorů - data TIER

50


Obrázek B.10: Strukturální testování

Příloha C

Obsah přiloženého CD Obsah přiloženého CD: • Analýza, Návrh - jednotlivé UseCase a Class diagramy. • Install - Kopie instalačních balíčků. • Softwarový projekt - Zdrojové kódy, včetně vytvořených JAR a potřebných knihoven.

51

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

Recommend Documents