}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Internetový obchod s automobilovými náhradními díly DIPLOMOVÁ PRÁCE Bc. Michal Čermák Brno, podzim 2010

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D. ii

3 Poděkování Rád bych poděkoval RNDr. Radku Ošlejškovi, Ph.D. za vedení mé práce, vstřícný přístup a cenné rady, které mi poskytl během konzultací. Poděkování patří také mým rodičům, kteří mě během studia podporovali. iii

4 Shrnutí Obsahem práce je analýza, návrh a částečná implementace elektronického obchodu s automobilovými náhradními díly. Systém je namodelován v UML s důrazem na použití softwarových vzorů (analytických, návrhových a architektonických), jež jsou zároveň popsány v jednotlivých kapitolách věnovaných různým fázím vývoje. Systém je napojen na webovou službu TecDoc, která slouží jako katalog náhradních dílů, a zároveň na skladový systém Venet. Implementace je postavena na platformě Java Enterprise Edition a využívá aplikační rámce Hibernate, Spring a Spring Security. iv

5 Klíčová slova Abstract Factory, analytické vzory, Data Access Object, Hibernate, návrhové vzory, Spring, TecDoc v

6 Obsah 1 Úvod Analýza Vize Diagram případů užití Doménový model Analytické vzory Historie vzniku vzorů Vzory podle Fowlera Příklady vzorů Organization Hierarchy Quantity Analytický model tříd Návrh Návrhové vzory Původ vzorů GoF vzory Struktura vzorů Příklady vzorů Factory Method Abstract Factory Data Access Object DAO Factory Návrhový model tříd Implementace Architektonické vzory Co jsou to architektonické vzory Model-View-Controller Další vzory Technologie Hibernate Úvod do problematiky Objektově relační mapování HQL Spring Framework Spring Security TecDoc Co je to TecDoc? TecDoc Web Service Diagram nasazení Závěr vi

7 Literatura Rejstřík A Obsah přiloženého CD B Textová specifikace případů užití C Analytický model tříd D Ukázka uživatelského rozhraní vii

8 Kapitola 1 Úvod S rozvojem internetu, a s ním souvisejících technologií, vzrůstá jeho důležitost nejen jako zdroje informací a komunikačního kanálu, ale také jako obchodní platformy. Čím dál tím více uživatelů ho využívá k nákupům zboží. Vede je k tomu často nižší cena oproti běžným kamenným obchodům, jednoduchost nákupu prostřednictvím počítače a také pohodlnost, nebot logistické společnosti zboží doručí v podstatě kamkoliv. Díky tomu je pro udržení konkurenceschopnosti firem prodávajících své zboží či služby nutné, aby tak činili i prostřednictvím elektronického obchodu. Cílem této práce je provést analýzu, návrh a částečnou implementaci elektronického obchodu s automobilovými náhradními díly, s důrazem na použití softwarových vzorů v jednotlivých etapách vývoje. Systém bude napojen na webovou službu TecDoc, která poslouží jako katalog náhradních dílů a zároveň na skladový systém Venet, ze kterého budou získávány informace o zákaznících. Práce je rozdělena na tři části. První z nich se zabývá analýzou. Čtenář se seznámí s vizí budoucího systému a odůvodněním vývoje nového řešení namísto využití již hotového open source systému. Následuje doménový model a diagram případů užití. Dále jsou představeny analytické vzory, jež jsou využity při modelování analytického diagramu tříd. Druhá část se zabývá návrhem. Představuje návrhové vzory a následně návrhový model tříd, jenž tyto vzory využívá. Třetí část se věnuje samotné implementaci. Nejprve je čtenář seznámen s architektonickými vzory a následně s konkrétními technologiemi, jež byly použity při vývoji systému, konkrétně s aplikačními rámci Hibernate, Spring a Spring Security a webovou službou Tec- Doc. 1

9 Kapitola 2 Analýza Tato kapitola se zabývá analýzou požadavků na systém a základní analýzou systému - internetového obchodu s automobilovými náhradními díly. Kromě úvodní části, jež představuje vizi systému, kapitola obsahuje UML 1 modely využívané při analýze, konkrétně diagram případů užití, doménový model a analytický model tříd. Její součástí je také podkapitola o analytických vzorech, které byly při modelování využity. 2.1 Vize Základní vizí projektu internetového obchodu s automobilovými náhradními díly je zlepšení kvality a dostupnosti služeb poskytovaných firmou Autodat s.r.o. svým zákazníkům. Hlavním cílem je vyvinout systém (internetový obchod), který umožní zákazníkům interaktivně vyhledávat a objednávat zboží prostřednictvím elektronické komunikace, aniž by byli nějakým způsobem časově či místně omezeni. Z hlediska zákazníka dojde ke značnému zlepšení dostupnosti služeb, nebot v současné době lze zboží objednávat pouze přímo na prodejně firmy nebo telefonicky, což může být pro některé zákazníky jistým handicapem (omezená otevírací doba, dojezdová vzdálenost k některé z prodejen). Elektronický obchod budou moci využívat nepřetržitě 24 hodin 7 dní v týdnu. Pro vedení firmy bude systém taktéž přínosem. Pokud si zákazník zboží sám vyhledá a objedná přes internetový obchod, zmenší se vytížení zaměstnanců spojené s vyřizováním objednávek a ti budou moci ušetřený čas věnovat jiným činnostem spojeným s rozvojem firmy. Z obchodního hlediska systém umožní oslovit nové potencionální zákazníky a obecně zvýšit povědomí o společnosti. Vzhledem k tomu, že firmy se stejným nebo podobným obchodním zaměřením již velmi často elektronické obchody mají, stává se v současné době využití tohoto systému v podstatě nutností k zajištění konkurenceschopnosti. V současné době existuje celá řada open source systémů (internetových obchodů), jako 1. UML je zkratka z anglického Unified Modeling Language. 2

10 2.2. DIAGRAM PŘÍPADŮ UŽITÍ příklad lze uvést OpenCart 2, tomatocart 3, PrestaShop 4, ZenCart 5, oscommerce 6 a mnoho dalších. Nabízí se tak otázka, proč některé z těchto volně dostupných řešení nevyužít. Hlavním důvodem je především skutečnost, že obchodní doména automobilových náhradních dílů je poměrně specifická, zatímco open source systémy představují vesměs univerzální řešení. To znamená, že je lze velmi dobře použít jako rychlé a snadné řešení na eshop s oblečením, sportovními potřebami nebo hračkami pro děti. Charakteristické pro ně je, že využívají vlastní databázi zboží, nabízené produkty si vystačí s několika základními atributy (název, popis zboží, cena,... ) a spuštění eshopu je v podstatě otázka několika hodin. Za nevýhody lze považovat téměř nezměnitelný design (co se týče rozmístění jednotlivých prvků), ne vždy kompletní lokalizace či závislost podpory na velikosti komunity. Naproti tomu zamýšlený eshop s náhradními díly musí využívat externí vyhledávací katalog zboží, v našem případě webovou službu TecDoc. Důvod je ten, že nabízených produktů od mnoha různých výrobců budou řádově desítky tisíc a v podstatě není možné je všechny ručně spravovat ve vlastní databázi. Pro vyhledání konkrétního náhradního dílu je potřeba zadat údaje nejen o automobilu jako celku (výrobce, model, rok výroby), ale mnohdy také specifické údaje k jednotlivým částem automobilu v závislosti na hledaném dílu (kód motoru, výkon, typ brzdového systému,... ). Navíc eshop musí být napojen na stávající skladový systém, ze kterého se budou získávat data o zákaznících, produktech (cena, skladová dostupnost,... ) a některé další specifické produkty, které není možné získat z Tec- Docu. Pokud bychom tedy chtěli využít nějaké open source řešení, znamenalo by to rozsáhlé zásahy do jeho zdrojových kódů. Avšak ne každý kód je psán čitelně, srozumitelně a s kvalitní dokumentací a proto jakékoliv jeho změny mohou být velkým problémem. Vzhledem k uvedeným skutečnostem se tak jeví jako nejlepší řešení vyvinout vlastní systém se zaměřením na zmíněné specifické nároky. Pro účely této prace jej nazývejme Ashop. 2.2 Diagram případů užití Diagram případů užití slouží k zachycení funkčních požadavků na systém. Je primárně určen k modelování chování systému, aniž by zobrazoval jeho vnitřní strukturu. Základními komponentami diagramu jsou účastníci, případy užití a vazby mezi nimi. Účastníci jsou role přidělené osobám nebo předmětům, které používají daný systém (lidé, externí systémy, části hardwaru, čas). Případy užití jsou činnosti, které může systém vykonávat prostřednictvím interakce s externími účastníky (činnosti požadované po systému). K zachycení vlastností konkrétního případu užití se podle fáze analýzy používá dokumentace s různou úrovní detailů. K jejímu vyjádření lze použít textovou specifikaci, diagram aktivit, stavový diagram, sekvenční diagram nebo komunikační diagram [9]. 2. < 3. < 4. < 5. < 6. < 3

11 2.2. DIAGRAM PŘÍPADŮ UŽITÍ Textová specifikace většinou obsahuje název případu užití, identifikační číslo, stručný popis, seznam účastníků, vstupní podmínky, hlavní tok událostí, výstupní podmínky a alternativní toky. Obrázek 2.1: Diagram případů užití Systém Ashop, jehož diagram případů užití je zachycen na obrázku 2.1, bude používán z hlediska následujících uživatelských rolí. Neregistrovaný zákazník - představuje zákazníky, kteří nejsou zaregistrováni do systému (nemají vytvořený účet). Mohou vyhledávat zboží a následně si ho objednat prostřednictvím nákupního košíku. Mohou se registrovat. Neregistrovaný velkoobchodní zákazník - zahrnuje velkoobchodní zákazníky, kteří u firmy pravidelně nakupují prostřednictvím kamenné prodejny a mají přiděleno tzv. zákaznické číslo. Pomocí něho se mohou do systému zaregistrovat a automaticky jim tak budou nastaveny slevy, které mají přiděleny. Jinak mohou systém používat stejně jako neregistrovaní zákazníci. 4

12 2.2. DIAGRAM PŘÍPADŮ UŽITÍ Zákazník - představuje zákazníky, kteří mají v systému vytvořený učet. Oproti neregistrovaným zákazníkům si navíc mohou prohlížet historii svých objednávek a měnit nastavení svého účtu. Zaměstanec - tato role zastupuje zaměstnance firmy, kteří mají na starosti vyřizování přijatých objednávek a ověřování registrací velkoobchodních zákazníků. Administrátor - představuje zaměstnance s nejvyšším oprávněním. Umožňuje spravovat uživatelské účty v systému, měnit nastavení eshopu, spravovat kategorie a jim přiřazené produkty. Následuje textová specifikace jednotlivých případů užití identifikovaných v modelovaném systému. Vzhledem k tomu, že je poměrně rozsáhlá, uvádím zde pouze její část. Kompletní dokumentaci lze nalézt v příloze B. Registrace zákaznickým číslem - umožňuje uživateli provést registraci pomocí zákaznického čísla. Po vyplnění registračního formuláře s povinnými údaji (zákaznické číslo, , telefon) a jeho odesláním je registrace uložena do systému a čeká na zpracování. Vstupní podmínky: uživatel zná své zákaznické číslo. Aktéři: neregistrovaný velkoobchodní zákazník. Tok událostí: 1. PU začíná, když uživatel klikne na "registrace zákaznickým číslem". 2. Systém zobrazí editovatelný registrační formulář. 3. Uživatel vyplní formulář a klikne "registrovat". 4. Systém uloží registraci do databáze. Registrace - umožňuje vytvořit nový zákaznický účet v systému. Po vyplnění povinných údajů registračního formuláře a jeho odeslání je zákazník zaregistrován a může se přihlásit do systému. Aktéři: neregistrovaný zákazník. Tok událostí: 1. PU začíná, když uživatel klikne na "registrace". 2. Systém zobrazí editovatelný registrační formulář. 3. Uživatel vyplní požadované informace a klikne na "registrovat". 4. Systém zkontroluje zadané informace. 5. IF Údaje jsou správné. 5.1 Systém uloží data do databáze a vytvoří nový uživatelský učet. 5.2 PU končí. 6. ELSE pokračuje krokem 2. Vyhledání zboží - umožňuje vyhledat náhradní díly a doplňky k automobilům bud přímo zadáním čísla výrobku nebo vybráním konkrétního automobilu (výrobce, model, typ motoru) a následně prohledáním katalogu dostupných výrobků pro tento automobil. 5

13 2.2. DIAGRAM PŘÍPADŮ UŽITÍ Aktéři: neregistrovaný zákazník, webová služba TecDoc. Tok událostí: 1. PU začíná tím, že uživatel klikne na "náhradní díly". 2. Systém zobrazí seznam výrobců automobilů (audi, citroen,...). 3. Uživatel klikne na konrétního výrobce. 4. Systém zobrazí seznam modelů pro vybraného výrobce automobilu. 5. Uživatel klikne na konkrétní model automobilu. 6. Systém zobrazí seznam typů motoru pro konkrétní model automobilu. 7. Uživatel klikne na konkrétní typ motoru. 8. Systém zobrazí seznam kategorií zboží pro vybraný automobil. 9. Uživatel klikne na konkrétní kategorii (podkategorii) zboží. 10. Systém zobrazí seznam zboží ve vybrané kategorii (podkategorii). Alternativní tok: 1. Uživatel zadá objednací číslo a klikne na "vyhledat". 2. Systém zobrazí nalezené zboží. Správa nákupního košíku - zahrnuje přidání vyhledaného zboží, odebrání nebo změnu množství zboží v košíku. Nákupní košík zobrazuje informace o zboží (objednací číslo, název, cena, počet kusů) a celkovou cenu nákupu. Zboží v nákupním košíku si může zákazník objednat. Aktéři: neregistrovaný zákazník. Objednání zboží - umožňuje objednat zboží v nákupním košíku. Uživatel zvolí způsob dopravy, způsob platby, vyplní nebo pouze zkontroluje (pokud byly načteny z uživatelského profilu) dodací a fakturační údaje a následně potvrdí objednávku. Aktéři: neregistrovaný zákazník. Vstupní podmínky: Tok událostí: 1. PU začíná, když uživatel klikne na "objednat". 2. Systém zobrazí formulář pro volbu způsobu dopravy. 3. Uživatel vybere způsob dopravy a klikne "pokračovat". 4. Systém zobrazí formulář pro volbu způsobu platby. 5. Uživatel vybere způsob platby a klikne na "pokračovat". 6. Systém zobrazí formulář pro zadání fakturační a dodací adresy. 7. Uživatel vyplní údaje a klikne na "pokračovat". 8. Systém zobrazí souhrn všech údajů. 9. Uživatel klikne na "objednat". 10. Systém uloží objednávku do databáze a zašle uživateli informační . Alternativní tok: 1. Uživatel se může vrátit na předchozí krok kliknutím na "zpět". 2. Uživatel může objednávku kdykoliv přerušit. Prohlížení objednávek - umožňuje uživateli prohlížet detaily o všech svých realizovaných objednávkách. 6

14 2.3. DOMÉNOVÝ MODEL Aktéři: zákazník. Vstupní podmínky: uživatel je přihlášen do systému. Tok událostí: 1. PU začíná, když uživatel klikne na "moje objednávky". 2. Systém zobrazí seznam všech objednávek uživatele. 3. Uživatel klikne na konkrétní objednávku. 4. Systém zobrazí detailní informace spojené se zvolenou objednávkou. Nastavení uživatelského účtu - umožňuje uživateli editovat osobní či firemní údaje, fakturační a dodací adresu a kontaktní údaje. Aktéři: zákazník. Vstupní podmínky: uživatel je přihlášen do systému. Tok událostí: 1. PU začíná, když uživatel klikne na "můj účet". 2. Systém zobrazí seznam možných nastavení. 3. Uživatel klikne na konkrétní položku nastavení. 4. Systém zobrazí formulář pro editaci požadovaného nastavení. 5. Uživatel změní požadované údaje a klikne na "uložit". 6. Systém uloží změny do databáze. 2.3 Doménový model Doménový model je konceptuální model z oblasti zájmu, často označované jako problémové domény. Vytváří se s cílem zachytit klíčové pojmy problémové domény. Doménový model identifikuje vztahy mezi jednotlivými objekty (fyzickými i abstraktními) problémové domény a v některých případech také jejich atributy. Významným přínosem tohoto modelu je skutečnost, že popisuje a zároveň omezuje rozsah problémové domény. Často se využívá při schvalování a ověřování pochopení problémové domény mezi různými zainteresovanými stranami a stává se užitečným komunikačním nástrojem například mezi obchodním a vývojovým týmem [3]. Doménový model systému Ashop na obrázku 2.2 obsahuje následující entity: Zaměstnanec - entita reprezentuje zaměstnance firmy, kteří budou se systémem pracovat. Mají na starosti vyřizování objednávek a spravování eshopu. Objednávka - je vytvářena zákazníkem a vyřizována zaměstnancem. Uchovává informace o objednaných produktech (množství, celková cena). Objednávka se nachází v různé fázi zpracování (přijatá, zrušená, vyřízená,... ). Doprava a platba - tyto entity reprezentují různé druhy dopravy a způsoby platby, které může zákazník využít při objednávání zboží. Zákazník - reprezentuje zákazníky, kteří budou systém využívat za účelem objednání zboží. Entita uchovává jejich osobní a kontaktní údaje, slevy. 7

15 2.4. ANALYTICKÉ VZORY Obrázek 2.2: Doménový model systému Ashop Produkt - entita reprezentuje zboží, které si zákazníci mohou koupit. Sdružuje informace jako název, popis zboží, cenu, výrobce a další. Produkt (náhradní díl) může být svázán s konkrétním automobilem, na který se montuje. Kategorie - produkty jsou podle různých vlastností sdružovány do kategorií, které zákazníkovi usnadňují vyhledávání. Automobil - entita uchovává informace o různých typech automobilů a jejich vlastnostech (výrobce, model, objem motoru, rok výroby, typ paliva,... ). 2.4 Analytické vzory Historie vzniku vzorů Pojem vzor se poprvé objevil v práci Christophera Alexandera, profesora architektury na californské univerzitě v Berkeley, na konci 70. let minulého století. Alexander vymyslel řadu teorií o vzorech v architektuře a zveřejnil je v několika publikacích. Jednou z nich je i kniha A Pattern Language [1], která je mnohými považována za jakýsi prototyp pro knihy o vzorech v softwaru. Najdou se však i lidé, kteří roli Ch. Alexandera, jako hlavní zdroj inspirace pro softwarové vzory, zpochybňují. Za publikaci, která měla daleko větší vliv na softwarové vzory, považují knihu Design Patterns: Elements of Reusable Object-Oriented Software [5] autorů GoF 7. Zajímavostí je, že tři z těchto autorů Alexanderovu knihu před napsáním této nečetli. 7. GoF je zkratka z anglického Gang of Four. Používá se jako označení pro čtveřici autorů - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides. 8

16 2.4. ANALYTICKÉ VZORY Vzory podle Fowlera Pod pojmem analytický vzor si lze představit část analytického modelu, kterou je možné opakovaně použít v podobných aplikačních oblastech. Jde v podstatě o zobecněné řešení nějakého problému, jež vychází z dlouhodobé zkušenosti a jehož správnost byla mnohokrát ověřena praxí. Systém analytických vzorů uvedených v této kapitole vychází z knihy Analysis Patterns - Reusable Object Models [4], jejímž autorem je Martin Fowler. Kniha je rozdělena na dvě části. První obsahuje analytické vzory, druhá vzory podpůrné, které mohou být využity při aplikaci analytických vzorů. Analytické vzory jsou rozděleny do 9 kategorií, jež se týkají určité doménové oblasti (koupě a prodej produktů, záznamy údajů a měření,... ). Každá z nich obsahuje soubor analytických vzorů, které jsou představovány od těch nejjednodušších. Postupně jsou tyto vzory rozšiřovány a kombinovány s ostatními, čímž nakonec vznikají poměrně rozsáhlé a komplexní vzory. Rozdělení vzorů do kategorií s charakteristikou jejich doménové oblasti, jíž se zabývají, je následující: Accountability - řešení organizační struktury a odpovědnosti osob. Observations and Measurements - záznamy údajů a měření. Observations for Corporate Finance - analýza složitých finančních vztahů a výsledků ve firmách. Referring to Objects - identifikace objektů. Inventory and Accounting - inventury a sledování peněžních toků. Planning - plánování akcí a protokoly pro plánování. Trading - koupě a prodej produktů. Derivative Contracts - ceny a jejich odvozování od různých subjektů. Trading Packages - členění systému se složitou doménovou oblastí Příklady vzorů Organization Hierarchy Vzor Organization Hierarchy patří do souboru vzorů Accountability, jež se zabývají organizací struktur a jejich vzájemných vztahů. Mějme mezinárodní společnost, která má operační jednotky na úrovni kontinentů, jež jsou rozděleny na regiony. Ty jsou dále rozděleny na divize na úrovni států a v každém z nich operuje několik prodejců jejího zboží. Uvedenou situaci můžeme jednoduše modelovat způsobem uvedeným na obrázku

17 2.4. ANALYTICKÉ VZORY Obrázek 2.3: Struktura společnosti modelovaná bežným způsobem Tento model ovšem není ani flexibilní, ani znovupoužitelný. Pokud se struktura společnosti změní a například divize budou zrušeny, znamená to změnit výše uvedený model. Nelze jej použít pro společnosti s jinou organizační strukturou nebo jinými názvy organizačních jednotek. Řešením tohoto problému je použití velmi jednoduchého modelu s využitím rekurzivních vztahů, jak ukazuje obrázek 2.4. Obrázek 2.4: Využití rekurze Nebezpečím modelu s rekurzí je, že umožňuje regionu být například částí divize nebo prodejce. To lze vyřešit definováním podtypů korespondujících s jednotlivými úrovněmi organizace, kterým dáme určitá omezení. Výsledný model je na obrázku 2.5. Obrázek 2.5: Typ Organization s podtypy a jejich omezeními 10

18 2.5. ANALYTICKÝ MODEL TŘÍD Quantity Při modelování informačních systémů je velmi často potřeba o objektech reálného světa uchovávat mnoho informací různých typů. Mějme lékařskou ordinaci, která potřebuje ukládat údaje o pacientech. Typickým způsobem, jak uchovat nějakou informaci, je uložit ji jako atribut objektu. Pokud u váhy pacienta zaznamenáme číslo 80, většinou už neuvádíme, že se jedná o váhu v kilogramech. Ačkoliv je tento přístup velmi často používán, není příliš univerzální. Mnohem výstižnější by bylo uchovávat informaci ve formě hodnota - jednotka. Právě takový přístup využívá analytický vzor Quantity, který patří do souboru vzorů Observation and Measurement. Obrázek 2.6: Analytický vzor Quantity Pokud uvedený vzor aplikujeme na příklad s váhou pacienta, má osoba atribut váha typu Quantity s množstvím 80 a jednotkou kilogram. Dalším příkladem využití může být uchovávání finanční částky. 150 korun bude reprezentováno jako Quantity s množstvím 150 a jednotkou koruna. Výhodou použití tohoto vzoru je, že zároveň definuje povolené operace na hodnotách, které jsou uchovávány ve stejných jednotkách. 2.5 Analytický model tříd Diagram tříd zobrazuje statický pohled na systém, zejména na třídy a vzájemné vztahy mezi nimi, jejich atributy a operace. Analytický model je typem diagramu tříd, který se využívá při analýze. Modeluje obchodní doménu systému - typy objektů a vztahy mezi nimi. Jako výchozí dokumentace může sloužit doménový model. Hlavním cílem při vytváření analytického modelu je zachování přehlednosti a jednoduchosti bez zanášení jakýchkoliv implementačních detailů. Vzhledem k tomu, že systém Ashop bude částečně napojen na skladový systém Venet, který v současné době firma používá, a bude z něj získávat některá data o nabízených produktech, je potřeba zahrnout tuto specifickou část systému do analytického modelu. Zároveň je nutné částečně vycházet z již zmíněného skladového systému, důležitý je zejména způsob stanovování ceny jednotlivých produktů. Problémová oblast je následující. V současném systému je každý produkt zařazen do nějakého oddělení. Oddělení může být dále rozděleno na pododdělení a produkt tedy může 11

19 2.5. ANALYTICKÝ MODEL TŘÍD zároveň patřit do nějakého pododdělení. Jednotlivá oddělení mohou být sdružována do skupin. Zákazníci mohou mít různé slevy. Ty se však neváží na konkrétní produkt, ale na určitou skupinu, oddělení nebo pododdělení. Při výpočtu konečné ceny produktu se uplatňuje nejvyšší sleva. Pro lepší pochopení uved me názorný příklad. Mějme produkt patřící do oddělení 25 a jeho pododdělení 3. Zákazník A má slevu 10 % na produkty z oddělení 25, žádnou jinou slevu nemá. Zákazník B má slevu 5 % na oddělení 25 a slevu 15 % na pododdělení 3 oddělení 25. Výsledná sleva pro zákazníka A tedy bude 10 %, pro zákazníka B 15 %, nebot se uplatní vyšší sleva. Uvedený problém je v podstatě totožný s problémem modelovaným pomocí analytického vzoru Organization Hierarchy zmiňovaného v předchozí kapitole. Jediným rozdílem je problémová oblast. Zde se jedná o produkty zařazené do nějaké logické hierarchie, v příkladu uvedeném při popisu vzoru šlo o hierarchickou strukturu členění mezinárodní společnosti. Další oblastí vhodnou pro využití analytického vzoru, konkrétně Quantity, je modelování produktu a jeho vlastností. Opět uved me příklad. Automobilový náhradní díl, například olejový filtr, má jako základní parametry výšku, vnější a vnitřní průměr. Rozvodový řemen má parametry počet zubů a tloušt ku. Opět se liší pouze problémová oblast. Zde se jedná o uchovávání parametrů náhradních dílů v různých jednotkách, v příkladu z předcházející kapitoly šlo o ukládání informací o zdravotním stavu pacienta. Vzor Quantity lze využít i při modelování dostupnosti produktu. Chceme-li uchovávat informaci o množství zboží skladem, je vhodné využít kombinaci hodnota - jednotka. Například - brzdový váleček: 2 kusy, diamantová řezací struna: 20 metrů, nemrznoucí směs do ostřikovačů: 230 litrů. Na obrázku 2.7 na následující straně je část analytického modelu, na němž jsou barevně zvýrazněny oblasti, které byly modelovány s použitím popisovaných vzorů. Kompletní analytický model je uveden v příloze C. 12

20 2.5. ANALYTICKÝ MODEL TŘÍD Obrázek 2.7: Část analytického modelu tříd s využitím analytických vzorů 13

21 Kapitola 3 Návrh Tato kapitola navazuje na analýzu a zabývá se návrhem systému Ashop. První část popisuje pozadí vzniku návrhových vzorů a jejich základní členění. Představuje GoF vzory, konkrétně Factory Method a Abstract Factory a dále J2EE 1 vzor Data Access Object, který z nich vychází. Druhá část obsahuje návrhový diagram tříd, který ukazuje příklady použití vzorů v kontextu modelovaného systému. 3.1 Návrhové vzory Původ vzorů Pojem návrhový vzor se poprvé objevil na konferenci OOPSLA 2 v roce 1987, kde Kent Beck a Ward Cunningham prezentovali sérii přednášek na téma Where do objects come from?. Představili na nich několik návrhových vzorů, které vytvořili na základě svých problémů s návrhem aplikací pro programovací jazyk Smalltalk. Počatkem devadesátých let minulého století se začala utvářet již zmiňovaná skupina Gang of Four. V roce 1994 představila na konferenci OOPSLA svoji knihu o návrhových vzorech Design Patterns: Elements of Reusable Object-Oriented Software [5]. Kniha měla velký úspěch a je dodnes považována za ústřední dílo z oblasti softwarových návrhových vzorů GoF vzory Návrhové vzory, podobně jako analytické, představují obecné řešení nějakého často se opakujícího problému a používají se ve fázi návrhu softwaru. Nejedná se ale o žádné knihovny nebo konkrétní zdrojové kódy, které by bylo možné přímo vložit do vyvíjeného softwaru. Návrhový vzor je pouze šablona či popis řešení, které může být použito v různých situacích. Ačkoliv od vydání zmiňované knihy autorů GoF uplynulo více než patnáct let, z hlediska rychlosti vývoje v oblasti informačních technologií je to doba opravdu dlouhá, základní rozdělení vzorů do skupin, které v ní bylo představeno, se používá dodnes a v podstatě většina novějších knih o návrhových vzorech z tohoto členění vychází. Rozdělení vzorů 1. J2EE je zkratka z anglického Java 2 Enterprise Edition. Dnes se velmi často používá pouze zkratka JEE. 2. OOPSLA je zkratka z anglického Object-Oriented Programming, Systems, Languages & Applications. 14

22 3.1. NÁVRHOVÉ VZORY je následující: Creational Patterns (tvořící vzory) Jak již napovídá název, vzory řeší problémy s vytvářením objektů v systému. Cílem těchto návrhových vzorů je popsat postup výběru třídy nového objektu a zajištění správného počtu těchto objektů. Většinou se jedná o dynamická rozhodnutí učiněná za běhu programu. Mezi tyto vzory patří: Abstract Factory, Builder, Factory Method, Prototype a Singleton. Structural Patterns (strukturální vzory) Strukturální vzory reprezentují skupinu vzorů, které se zaměřují na možnosti uspořádání jednotlivých tříd nebo komponent v systému. Jejich cílem je zpřehlednit systém a využít možností strukturalizace zdrojového kódu. Mezi strukturální vzory patří: Adapter, Bridge, Composite, Decorator, Facade, Flyweight a Proxy. Behavioral Patterns (vzory chování) Jedná se o vzory, které se zabývají chováním systému. Jsou založeny bud na třídách nebo objektech. U tříd využívají při návrhu řešení především principu dědičnosti. V druhém případě řeší spolupráci mezi objekty a skupinami objektů, která zajišt uje dosažení požadovaného výsledku (chování systému). Mezi vzory chování patří: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method a Visitor. S rozvojem nových technologií postupem času vznikly další kategorie vzorů, například Concurrency Patterns [2], které mají za úkol řešit multivláknové programování - vzory Scheduler, Thread Pool, Reactor a mnohé další. Existují také vzory pro konkrétní platformu, například J2EE Patterns [6]. Většina nově vzniklých vzorů má však jednu společnou vlastnost - vycházejí, rozšiřují nebo v sobě integrují některé ze vzorů GoF Struktura vzorů Každý popis návrhového vzoru by měl obsahovat všechny podstatné a zároveň dobře strukturované informace vedoucí k tomu, že vzor bude lehce pochopitelný a použitelný, bude snadné se ho naučit a bude možné ho porovnávat s ostatními vzory. Proto se pro jejich popis používá již ustálené schéma zavedené v roce 1995 na konferenci PLoP 3, které obsahuje následující základní prvky 4 : Jméno - vzor by měl mít smysluplný a snadno zapamatovatelný název vystihující jeho podstatu. Problém - obsahuje popis problému, který daný vzor řeší. 3. PLoP je zkratka z anglického Pattern Languages of Programs. 4. V závislosti na použité literatuře se mohou názvy mírně lišit, avšak jejich význam by měl být stejný. 15

23 3.1. NÁVRHOVÉ VZORY Kontext/podmínky - popisuje veškeré okolnosti a podmínky, za kterých je možné vzor použít. Řešení - obsahuje soubor pravidel ve formě textu, obrázků či diagramů, které výsvětlují, jak dosáhnout požadovaných výsledků a objasňují základní principy vzoru. Výsledný kontext/podmínky - popisuje stav nebo konfiguraci systému po aplikování vzoru. Jeden vzor často nepředstavuje kompletní řešení složitějšího problému, ale pouze jeho část. Výsledný stav po použití jednoho vzoru může být výchozím bodem pro použití dalšího vzoru. Příklady - každý popis by měl obsahovat jednu či více ukázek praktického použití vzoru, například ve formě zdrojového kódu, která ilustruje výše uvedené části: problém, kontext a řešení. Zdůvodnění - obsahuje vysvětlení vzoru jako celku nebo jeho jednotlivých součástí. Ukazuje, jak vzor skutečně funguje a jakým způsobem zajišt uje dosažení požadovaných cílů. Narozdíl od části řešení, která je jakýmsi pohledem z vnějšku, tato část by měla naopak ukázat jeho vnitřní fungování. Související vzory - často se stává, že použití jednoho vzoru nepředstavuje ucelené řešení. Vstupní podmínky pro použití popisovaného vzoru mohou být výsledkem aplikace jiného vzoru a naopak výstupní podmínky mohou být vstupním bodem pro jiný vzor. Konečné řešení tak může být výsledkem aplikace několika souvisejících vzorů. Někdy je možné řešit problém různými způsoby (za pomoci odlišných vzorů) a pak je vhodné se o nich v této části zmínit. Reference - popisuje známé použití vzoru v existujících systémech, které ověřuje, že vzor skutečně představuje osvědčené řešení pro daný opakující se problém (zvyšuje důvěryhodnost). Může sloužit také jako část příklady Příklady vzorů Následující část představuje konkrétní návrhové vzory, které byly využity bud přímo a nebo jako součást jiného vzoru použitého při modelování systému Factory Method Factory Method [5] je jedním ze vzorů GoF řadící se do skupiny Creational Patterns (tvořící vzory). Řeší problém, jakým způsobem za běhu programu rozhodnout o vytvoření konkrétní instance třídy. Předpokladem pro použití tohoto vzoru je existence několika tříd, které mají většinou společného předka, ale poskytují různé služby nad různými daty. Factory Method pak umožňuje za běhu programu vybrat, kterou instanci některé z těchto tříd vytvořit. Schéma vzoru na obrázku 3.1 obsahuje následující komponenty: 16

24 3.1. NÁVRHOVÉ VZORY Obrázek 3.1: Vzor Factory Method Product - definuje rozhranní objektů (obecnou třídu), které jsou vytvářeny pomocí FactoryMethod. Může být implementována například jako abstraktní třída. ConcreteProduct - implementuje rozhranní (rozšiřuje třídu) Product. Creator - deklaruje metodu FactoryMethod, která je zodpovědná za vytváření objektů typu Product. Může definovat výchozí implementaci této metody, která vrací defaultní objekt typu ConcreteProduct. ConcreteCreator - překrývá FactoryMethod tak, aby vracela konkrétní instanci třídy typu ConcreteProduct. Client - představuje klienta, který má referenci na objekt typu Creator, od něhož vyžaduje vytvoření požadované instance třídy typu Product. Obecně je využíván princip, kdy jedna instance třídy ConcreteCreator vytváří instance jedné z možných tříd typu ConcreteProduct. Klient si vytvoří, nebo získá odkaz na ConcreteCreator a volá jeho metodu FactoryMethod. Ta mu jako výsledek vrátí instanci konkrétního produktu. Tento vzor lze použít pro práci s pooly objektů. FactoryMethod může rozhodnout, zda vytvoří a vrátí novou instanci třídy nebo použije již vytvořený objekt, který není právě používán (tento princip se často využívá pro připojení k databázi). Výhodou vzoru je především flexibilita, protože aplikační logika pro vytváření objektů je uzavřena do jedné třídy a tím pádem lze jakoukoliv změnu provést na jednom místě. Mezi související vzory patří především Abstract Factory, Template Method a Prototype Abstract Factory Abstract Factory [5] je dalším z tvořících vzorů podle GoF. Poskytuje rozhraní pro vytváření rodin příbuzných nebo závislých objektů bez specifikace konkrétních tříd. Nahrazuje přímé volání kostruktoru třídy voláním tvořící metody továrního objektu. Tento vzor poskytuje o něco vyšší míru abstrakce (v podobě rozhranní) než Factory Method, čehož se využívá v případech, kdy existuje několik tříd, které vytvářejí instance svých 17

25 3.1. NÁVRHOVÉ VZORY produktů. Každá z těchto tříd vytváří jiný typ produktu, ale ty spolu nějakým způsobem souvisí (mají společené vlastnosti, odpovídají stejnému uživatelskému rozhraní). Abstract Factory umožňuje za běhu programu jednu z těchto tříd vybrat, aniž by tím zasahoval do dalších částí systému. Obrázek 3.2: Vzor Abstract Factory Zmíněných vlastností je dosaženo díky vytvoření abstraktní třídy, případně rozhraní, jak pro konkrétní produkty, tak pro třídy vytvářející samotné produkty. Schéma vzoru ukazuje obrázek 3.2. Jednotlivé elementy mají následující význam: AbstractFactory - deklaruje rozhraní pro metody, které vytvářejí objekty typu AbstractProduct. ConcreteFactory - implementuje metody z rozhraní AbstractFactory. Tyto metody vytvářejí konkrétní produkty. AbstractProduct - deklaruje rozhraní pro objekty typu Product. Product - představuje konkrétní produkt, který je vytvářen s ním související továrnou. Implementuje rozhraní AbstractProduct. Klient si vytváří konkrétní instanci tovární třídy typu ConcreteFactory, která implementuje rozhranní (v případě abstraktní třídy dědí z) AbstractFactory. Tato instance vytváří objekty typu Product, které jsou předávány klientovi. Například ProductA2 a ProductB2 jsou vytvářeny pomocí ConcreteFactory2. Hlavním přínosem tohoto vzoru je použití rozhraní pro různé objekty typu ConcreteFactory. Kód klienta múže být psán nezávisle na použití konkrétní instance. Pokud je potřeba 18

26 3.1. NÁVRHOVÉ VZORY do aplikace přidat novou továrnu typu ConcreteFactory, stačí jednoduše implementovat zmiňované rozhraní. Mezi související vzory patří Factory Method. Třídy ConcreteFactory představují implementaci tohoto vzoru - metody CreateProduct jsou tovární metody, které vytváří konkrétní produkty. Třídy ConcreteFactory bývají často implementovány pomocí vzoru Singleton [5]. Abstract Factory se v praxi uplatnil například v grafické knihovně Java AWT Data Access Object Data Access Object (DAO) je jedním ze základních vzorů pro platformu J2EE. Jeho smyslem je zavést rozhraní mezi zdrojem dat a jeho konzumenty a izolovat aplikační logiku pro získávaní dat do jedné vrstvy. V současné době existuje mnoho různorodých zdrojů dat, které aplikace používají. Jsou jimi například relační databáze, objektové databáze, webové služby a mnohé další. Každý zdroj ale poskytuje data různým způsobem (pomocí různých rozhraní). Relační databáze pomocí jazyka SQL 6, webové služby pomocí XML 7 souborů. Nejen bussiness komponenty (session beany, objekty aplikační logiky), ale i presentační komponenty (servlety, pomocné objekty pro JSP stránky), které potřebují přistupovat k datovému zdroji, by mohly používat konrétní rozhraní datového zdroje k dosažení konektivity přímo a manipulovat s daty. Ale vznikla by tím přímá závislost mezi komponentami a konkrétní implementací datového zdroje. Taková závislost je však nežádoucí, protože pokud by se změnil datový zdroj, musela by se změnit i implementace všech komponent, které zdroj používají. Řešením, jak se tomuto problému vyhnout, je použít vzor DAO, který abstrahuje a zapouzdřuje veškerý přístup k datovému zdroji. DAO zajišt uje spojení se zdrojem a umožňuje manipulaci s daty prostřednictví Data Access objektu. Schéma vzoru je na obrázku 3.3. Obrázek 3.3: Vzor Data Access Object 5. AWT je zkratka z anglického Abstract Window Toolkit. 6. SQL je zkratka z anglického Structured Query Language. 7. XML je zkratka z anglického Extensible Markup Language. 19

27 3.1. NÁVRHOVÉ VZORY Význam jednotlivých komponent je následující: BussinesObject - reprezentuje data klienta (aplikační logiku). Jde o objekt, který potřebuje přístup k datovému zdroji, aby mohl získávat a ukládat data. DataAccessObject - je klíčovým objektem tohoto vzoru. Abstrahuje implementaci přístupu k datům a BussinessObject má tím pádem zajištěn transparentní přístup k datovému zdroji. BussinessObject deleguje načítání a ukládání dat na tento objekt. DataSource - reprezentuje implementaci datového zdroje. Datovým zdrojem může být databáze, webová služba, systém souborů nebo třeba adresářová služba. TransferObject - je objekt, který slouží jako nosič dat. DataAccessObject používá tento objekt k přenášení dat ke klientovi a zároveň ho může od klienta získat, aby zajistil aktualizaci dat v DataSource. Použití vzoru DAO má následující důsledky: bussiness objekty mohou přistupovat k datovému zdroji, aniž by cokoliv věděly o jeho implementačních detailech. Přístup je transparentní, protože implementační detaily jsou skryty uvnitř DAO objektu. vrstva DAO umožňuje aplikaci snadnou migraci na jinou databázovou implementaci. Bussiness objekty o databázové implementaci nic nevědí. To znamená, že migrace zahrnuje pouze změnu DAO vrstvy. snižuje složitost kódu v bussiness objektu, protože veškerý kód spojený s přístupem ke konkrétní databázové implemementaci (například SQL dotazy) jsou ukryty v DAO objektu. Zvyšuje to čitelnost kódu a produktivitu vývoje. centralizuje veškerý přístup k datům do jedné vrstvy, což vede ke snadnější spravovatelnosti a udržovatelnosti aplikace. DAO přidává další vrstvu mezi klienta a datový zdroj, která musí být navržena a následně implementována tak, aby využila předností tohoto vzoru. Avšak přínosy v důsledku použití tohoto přístupu ve většině případů vynahradí úsilí, které je potřeba vynaložit při návrhu a implementaci této vrstvy. Mezi související vzory patří zejména vzor Transfer Object [6], který DAO využívá k přenosu dat z/ke klientovi DAO Factory Vzor Data Access Object může být rozšířen začleněním vzorů Factory Method a Abstract Factory, které byly zmíněny v kapitolách a , čímž vznikne DAO Factory (továrna pro DAO). 20

28 3.1. NÁVRHOVÉ VZORY Pokud se datové úložiště nemění z jedné implementace na druhou, lze využít vzor Factory Method, který nám zajistí vytvoření potřebného množství DAO objektů vyžadovaných aplikací. Schéma je na obrázku 3.4. Obrázek 3.4: Továrna pro DAO strategii používající vzor Factory Method V případě, že se datové úložiště může měnit, je vhodné využít vzor Abstract Factory. Tato strategie poskytuje abstraktní tovární DAO objekt, ze kterého jsou vytvářeny různé typy konkrétních DAO továren a každá z nich podporuje jiný typ datového úložiště. Po získání objektu konkrétní DAO továrny lze vytvářet DAO objekty, které tato továrna podporuje. Schéma ukazuje obrázek 3.5. Obrázek 3.5: Továrny pro DAO objekty využívající vzor Abstract Factory 21

29 3.2. NÁVRHOVÝ MODEL TŘÍD Důsledky, které přináší využití DAO továren jsou podobné jako u samotného vzoru DAO. Jejich použití navíc zvyšuje flexibilitu, avšak za cenu složitější hierarchie tříd a tím pádem i celkové složitosti kódu. Proto je vhodné při návrhu nejprve využít řešení s Factory Method vzorem a pak teprve, v případě že je to nutné, použít řešení se vzorem Abstract Factory. 3.2 Návrhový model tříd Návrhový model tříd rozšiřuje analytický model o implementační třídy. Zatímco analytický model by měl být co nejjednodušší, návrhový model by měl být již dostatečně složitý a obsahovat všechny potřebné detaily, aby bylo možné jej snadno implementovat. Z obrázku 3.6 na následující straně je vidět, že návrhový diagram tříd modelovaného systému využívá vzor DAO, který zabezpečuje přístup objektů z aplikační vrstvy k perzistentní vrstvě aplikace. SpravceUzivatelu je aplikační objekt, který má za úkol správu všech uživatelů systému. Pomocí DAO objektů ZamestnanecDAO a ZakaznikDAO přistupuje k veškerým datům o zaměstnancích a zákaznících, jež jsou reprezentovány objekty Zamestnanec, Adresa, Zakaznik a Role. Podobně je tomu u modelované části s objednávkami. SpravceObjednavek je aplikační objekt, který prostřednictvím DAO objektu ObjednavkaDAO přistupuje a manipuluje s daty o objednávkách v podobě objektů Objednavka, PolozkaObjednavky a Produkt. Stejný princip je použit u dalších částí systému, které mají zajišt ovat přístup k datům. Vzhledem k tomu, že návrhový diagram tříd celého systému je značně rozsáhlý a na formát A4 v podstatě není možné jej rozumně zobrazit, je kompletní model systému uveden pouze na CD, které je přiloženo k této práci. 22

30 3.2. NÁVRHOVÝ MODEL TŘÍD Obrázek 3.6: Část návrhového modelu s využítím vzoru Data Access Object 23

31 Kapitola 4 Implementace Tato kapitola se zabývá implementací systému Ashop. Úvodní část se věnuje architektonickým vzorům. Následuje přehled použitých technologií s konkrétními ukázkami jejich využití při implementaci. Podobně jako v předchozích kapitolách, i zde jsou popisované technologie dány do souvislosti se softwarovými vzory. 4.1 Architektonické vzory Co jsou to architektonické vzory Architektonické vzory stojí z dosud zmíněných vzorů (analytické a návrhové) na nejvyšší úrovni. Vyjadřují základní strukturální organizační schémata pro softwarové systémy. Poskytují několik předdefinovanýh subsystémů, specifikují jejich odpovědnosti a obsahují pravidla a pokyny pro organizování vztahů mezi nimi. Následující rozdělení vzorů do čtyř kategorií vychází z knihy Pattern-Oriented Software Architecture: A System of Patterns [7], která vyšla jako první díl ze série knih POSA 1, jež se zabývají softwarovou architekturou. From Mud to Structure Vzory v této kategorii pomáhají vyhnout se velkému množství komponent nebo objektů. Podporují dekompozici hlavních úloh systémů na spolupracující dílčí podúlohy. Mezi tyto vzory patří: Layers, Pipes and Filters a Blackboard. Distributed Systems Do této kategorie patří pouze jediný vzor - Broker, který poskytuje kompletní infrastrukturu pro distribuované aplikace. Navíc odkazuje na další dva vzory - Microkernel a Pipes and Filters, jež mají řešení distribuce jako svůj druhotný úkol a jsou proto uvedeny v jiné kategorii. Interactive Systems Tato kategorie zahrnuje dva vzory: Model-View-Controller a Presentation-Abstraction- Control. Obecně oba vzory podporují strukturování softwarových systémů, jež se zabývají interakcí člověka s počítači. 1. POSA je zkratka z anglického Pattern-Oriented Software Architecture. 24

32 Adaptable Systems 4.1. ARCHITEKTONICKÉ VZORY Do této kategorie patří vzory Reflection a Microkernel. Jejich cílem je umožnit rozšiřování aplikací a jejich přizpůsobení se na nové technologie a měnící se funkční požadavky. Vzhledem k tomu, že na vzoru Model-View-Controller je založena jedna z technologií použitých při implementaci systému, konkrétně aplikační rámec Spring (viz kapitola 4.2.2), bude detailněji popsán právě ten, ostatní vzory budou představeny pouze na příkladu jejich možného použití v praxi Model-View-Controller Architektura MVC (Model-View-Controller) se stává čím dál více populární. Důkazem toho je množství MVC frameworků, které v posledních letech vznikly nebo se neustále objevují jejich nové verze. Příkladem budiž APS.NET MVC, Zend Framework, Spring MVC a mnoho dalších. Cílem MVC je rozdělit interaktivní aplikace na 3 logické komponenty - Model, View a Controller tak, aby je šlo samostatně upravovat a dopad změn na ostatní byl co nejmenší. Model reprezentuje data a bussines logiku aplikace, View představuje uživatelské rozhraní a Controller má na starosti tok událostí v aplikaci (řídící logiku). Jednotlivé části si lze názorně představit pomocí následujícího příkladu tabulek a grafů na obrázku 4.1. Obrázek 4.1: Modelový příklad MVC Model je datová struktura uchovávající čísla 35, 42, 58 a 37, která může být v aplikaci realizována jako pole čísel nebo třída. Příklad obsahuje i údaj o průměrném příjmu, jehož výpočet také patří do modelu. View (pohled) je v příkladu zastoupen hned několikrát. Je patrné, že jej reprezentuje koláčový a sloupcový graf. Ale také tabulka s daty je dalším pohledem, jemuž lze nastavit 25

33 4.1. ARCHITEKTONICKÉ VZORY například různý formát zobrazování čísel (barva, velikost, měna,... ). View tedy představuje zobrazení modelu a dalších prvků uživatelského rozhraní. Controller (kontroler) není na uvedeném příkladu vidět. Projeví se ve chvíli, kdy uživatel změní obsah některé z buněk. V ten okamžik má kontroler za úkol aktualizovat model tak, aby došlo k výpočtu nového průměru a překreslily se všechny pohledy. Jakým způsobem se změny v modelu projeví v pohledech však nemusí souviset s kontrolerem, ten pouze celý proces spouští. Obecné schéma MVC vzoru vyjadřuje obrázek 4.2. Tok údálostí v MVC vypadá následnově: Obrázek 4.2: Schéma MVC 1 Uživatel provede nějakou akci v uživatelském rozhraní. 2 Akci zachytí Controller. 3 Controller rozhodne, jak na ni zareagovat a často změní data v Modelu nebo přímo ovlivní View. 4 View zobrazí změny uživateli. Tento průběh se v podstatě neustále opakuje. Na schématu je navíc vidět vazba mezi kontrolerem a pohledem, což je pro mnohé MVC frameworky typické. Jejich vztah je obvykle takový, že kontroler rozhoduje o tom, který pohled zobrazit. Vzor MVC je nejčastěji využíván ve webových technologiích. Z pohledu třívrstvého modelu se lze setkat s dvěma přístupy k webovým aplikacím. První z nich bere webový prohlížeč pouze jako zobrazovací zařízení a veškeré uživatelské rozhraní (HTML 2 ) se generuje na serveru. Druhý přístup využívající technologie AJAX 3 naopak spoléhá na přítomnost JavaScriptu ve webovém prohlížeči a podstatnou část prezentační logiky tak přesouvá na stranu klienta. Zejména díky použitým technologiím je tedy patrný poměrně značný rozdíl. 2. HTML je zkratka z anglického HyperText Markup Language. 3. AJAX je zkratka z anglického Asynchronous JavaScript and XML. 26

34 4.1. ARCHITEKTONICKÉ VZORY Serverové MVC musí využívat technologie, jako například Spring MVC (viz. kapitola 4.2.2) či ASP.NET MVC, zatímco klientské MVC je realizováno pomocí JavaScriptu. V současné době se lze setkat s kombinací obou zmíněných přístupů - AJAX doplňuje klasický model serverové aplikace. V tomto případě je prezentační vrstva realizována jak na serveru, tak na klientovi. Avšak stále nejčastěji používaným řešením je využití MVC na serveru, protože kompletně AJAXových aplikací je zatím velmi málo a ty jež ho využívají jen částečně zase neobsahují tak komplikovanou logiku, aby mělo smysl MVC využít. Z hlediska serverové implementace jednotlivé komponenty vypadají následovně. Model představuje nejjednodušší část, nebot koresponduje s modelem v klasických desktopových aplikacích. Obsahuje data a bussines logiku. View je serverový kód (Java, Ruby, PHP,... ), který se stará o generování HTML nebo jiných formátů, jako například XML či JSON 4. Controller je v prostředí webu většinou tvořen dvěma částmi. První je tzv. Front Controller, který zachytává veškeré HTTP požadavky. Ty zpracuje a přepošle konkrétním kontrolerům (tvoří druhou část), jež mají na starosti pouze určité specifické úkoly. Konkrétní kontroler může například přijmout formulářová data původně pocházející z HTTP požadavku, uložit je do modelu a spojit ho s konkrétním pohledem. Velmi podobným vzorem k MVC je MVP (Model-View-Presenter), který se používá například v technologiích JavaFX nebo Silverlight. Model zůstává stejný jako u MVC. View navíc zpracovává uživatelský vstup tím, že ho deleguje na Presenter (například jako reakci na kliknutí myši vyvolá nějakou jeho metodu). Presenter obsahuje jak aplikační, tak prezentační logiku. Manipuluje s modelem a přímo nebo nepřímo (pomocí notifikací) ovlivňuje View Další vzory Layers - tento vzor pomáhá strukturovat aplikace, které mohou být rozděleny do skupin podúloh a každá z těchto skupin je na určité úrovni abstrakce. Typickým příkladem jeho použití je referenční komunikační ISO/OSI model, jenž rozděluje komunikaci mezi počítači do sedmi souvisejících vrstev. Každá vrstva vykonává skupinu jasně definovaných funkcí potřebných pro komunikaci. Pro svoji činnost využívá služby své sousední nižší vrstvy a své služby naopak poskytuje sousední vyšší vrstvě. Pipes and Filtres - poskytuje strukturu pro systémy, které zpracovávají nějaké datové toky. Každý krok zpracování je zapouzdřen v komponentě Filter (filtr). Data jsou předávána prostřednictvím Pipes (potrubí) mezi sousedními filtry. Pomocí různých kombinací filtrů je možné vytvářet rodiny souvisejících systémů. Tento vzor lze v praxi ukázat například na kompilátoru. Na jeho vstupu jsou data ve formě zdrojového kódu, která jsou postupně zpracovávána pomocí filtrů, které představují - lexikální analyzátor, syntaktický analyzátor, sémantický analyzátor, překladač do mezikódu, optimalizátor mezikódu a generátor kódu. Blackboard - vzor je užitečný na řešení problémů, pro něž neexistují deterministické strategie. Funguje na principu shromažd ování znalostí z jednotlivých subsystémů, na je- 4. JSON je zkratka z anglického JavaScript Object Notation. 27

35 4.2. TECHNOLOGIE jichž základě je možné vytvořít částečné nebo přibližné řešení. Použití vzoru lze ukázat například na systému rozpoznávání reči. Jeho vstupem je řeč zaznamenaná jako akustický signál. Systém přijímá nejen jednotlivá slova, ale také celé věty, jež jsou omezeny syntaxí a slovní zásobou pro konrétní aplikace (např. databázový dotaz). Požadovaný výstup je strojová reprezentace odpovídajících frázi daného jazyka. Transformace vyžaduje akustickofonetické, jazykové a statistické rozbory. Například jedna část (subsystém) provádí rozdělení vstupu na jednotlivá písmena, jiná část provádí kontrolu syntaxe potencionálních frází. Obě tyto části ale pracují v jiných oblastech zpracovaní. Microkernel - tento vzor se využívá v softwarových systémech, které musí být schopny přizpůsobit se měnícím požadavkům systému. Odděluje minimální funkční jádro od rozšiřující funkcionality a specifických aplikací uživatelů. Slouží také jako soket pro zapojování různých rozšíření a jejich spolupráci. Příkladem implementace tohoto vzoru může být například architektura operačního systému pro mobilní zařízení Symbian OS. 4.2 Technologie Cílem této kapitoly není podat vyčerpávající informace o všech použitých technologiích, nebot k tomu slouží jejich mnohasetstránkové dokumentace, ale naopak uvést pouze jejich konkrétní části, vysvětlit důvody jejich použití a dát je do souvislosti se softwarovými vzory Hibernate Úvod do problematiky Propojení objektově orientované aplikace a relační databáze může být při vývoji informačního systému poměrně obtížné a zabrat mnoho času. Důvodem je odlišnost mezi způsobem reprezentace dat v objektech a relačních datázích. Rozdíl ilustruje následující příklad. Mějme záznam v adresáři, který reprezentuje osobu s jedním nebo více telefonními čísly a jednou či více adresami. V objektově orientované implementaci bude osoba reprezentována jako objekt Person, který v sobě bude uchovávat jméno, seznam telefonních čísel a seznam adres. Seznam telefonních čísel bude obsahovat čísla reprezentovaná jako objekty PhoneNumber, seznam adres objekty Address, atd. Tento záznam je objektovým programovacím jazykem reprezentován jako jedna hodnota (například může být odkazován pomocí jednoduché proměnné). Naproti tomu relační databáze mohou pracovat pouze se skalárními hodnotami (čísla, řetězce znaků,... ) organizovaných do relací (tabulek). Pokud tedy programátor chce ukládat objekty do relačních databází, musí je nejprve převést na skupinu jednodušších hodnot (při načítání z databáze je převést zpět na objekt) nebo používat pouze skalární hodnoty, což je z hlediska objektového programování nevhodné. Hibernate vznikl jako nástroj (framework) pro prostředí Java (v současnosti i.net), který tento problém řeší pomocí tzv. objektově-relačního mapování (ORM). Jedná se o techniku mapování dat z objektového modelu na relační model a obráceně. Hibernate se však nestará 28

36 4.2. TECHNOLOGIE pouze o mapování Java tříd na databázové tabulky a mapování datových typů Javy na SQL datové typy, ale poskytuje také nástroje pro dotazování a vyhledávání dat. Hlavním přínosem tohoto frameworku je, že zjednodušuje a ulehčuje práci vývojářům, protože eliminuje nutnost psaní kódu spojeného se zpracováním dat pomocí SQL a JDBC 5. Aktuální verze frameworku je Hibernate Objektově relační mapování Jak již bylo zmíněno, objektově-relační mapování je programovací technika, která zajišt uje konverzi dat (perzistentních tříd) mezi objektovým a relačním modelem. Aplikace tak může načítat a ukládat data do relační databáze, ale na aplikační úrovni pracovat s objektovým modelem dat. Perzistentní třída je obyčejná javová třída, která reprezentuje entity z modelovaného systému. Musí obsahovat bezparametrický konstruktor a get/set metody pro svoje atributy. Aby mohl Hibernate automaticky převádět data mezi objektovým a relačním formátem, je nutné nakonfigurovat, jak se budou objekty transformovat (mapovat) na tabulky v databázi. To lze provést dvěma způsoby, bud pomocí mapovacích souborů, anebo anotací. Mapovací soubory - jedná se o soubory ve formátu XML, které mají příponu hbm.xml. Pro jednu třídu se většinou používá jeden mapovací soubor, ale není to podmínkou. Veškerá konfigurace se provádí pomocí tagů a jejich atributů. Následující ukázka představuje část mapovacího souboru pro perzistentní třídy z vyvíjeného systému, konkrétně pro tříduuser a Customer. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" " <hibernate-mapping package="cz.autodat.eshop.entities"> <class name="user" table="users" lazy="false"> <id name="id" column="id" type="long"> <generator class="native"/> </id> <property name="username" column="username" not-null="true" length="30"/> <property name="password" column="password" not-null="true" length="30"/> <property name=" " column=" " not-null="true" lenght="50"/> <set name="authorities" table="user_authority" lazy="false"> <key column="user_id"/> <many-to-many column="authority_id" class="authority"/> </set> 5. JDBC je zkratka z anglického Java Database Connectivity. 6. Dokumentaci lze nalézt na < 29

37 4.2. TECHNOLOGIE <joined-subclass name="customer" table="customers"> <key column="id"/> <property name="customernumber" column="cn" type="int"/> <property name="customertype" column="type"/> <property name="phone" column="phone" type="string"/> <property name="ic" column="ic" type="string" length="8"/> <property name="dic" column="dic" type="string" length="10"/> </joined-subclass> </class> </hibernate-mapping> Význam mapování je následující. Třída User se bude ukládat do databázové tabulky USERS. Atribut id bude primárním klíčem a způsob jeho generování je ponechán na konkrétní databázové implementaci. U atributů username, password a je uvedeno mapování na konkrétní sloupce tabulky i s jejich délkou a nastaveno integritní omezení na nenulovost. Atribut authorities reprezentuje množinu objektů typu Authority. Jelikož je vztah mezi objekty User a Authority M:N, tedy uživatel může mít několik autorit a každá autorita může být svázána s několika uživately, musí být tato vazba mapována do další tabulky, v tomto případě USER_AUTHORITY. Dále je uvedeno mapování třídy Customer, která rozšiřuje třídu User. Bude mapována na samostatnou tabulku CUSTOMERS s cizím klíčem ID. Následuje opět mapování atributů na konkrétní sloupce tabulky, u IC a DIC je uvedeno omezení na délku sloupce. Anotace - představují metadata, která lze přidávat k jednotlivým elementům kódu (třída, metoda, proměnná). Anotacemi je možné nahradit zmiňovaný mapovací soubor a mít tak konfiguraci dostupnou přímo v kódu třídy. V případě mapování je lze použít dvěma způsoby, bud u atributů, anebo jejich get method. Následující ukázka představuje opět mapování třídy User, tentokrát public class User implements @GeneratedValue(strategy=GenerationType.AUTO) private long nullable=false, length=30) private String nullable=false, length=30) private String nullable=false) private String ; 30

38 } private Set<Authority> authorities; public User() {} 4.2. TECHNOLOGIE Obecně lze říci, že výhodou použití ORM je především přenositelnost aplikace mezi různými databázovými systémy, typová kontrola již během překladu aplikace, zjednodušení implementace a také snadnější testování. Za nevýhodu lze označit potencionálně menší výkon aplikace, nebot každý ORM nástroj má jistou režii, avšak konkrétně Hibernate klade na tuto oblast velký důraz HQL Hibernate Query Language (HQL) je dotazovací jazyk, který je svoji syntaxí velmi podobný SQL. Narozdíl od něj je však plně objektový a pracuje s vlastnostmi jako dědičnost či polymorfismus. S výjimkou názvů tříd a jejich atributů nejsou dotazy case-sensitivní. HQL podporuje klasické konstrukce, které jsou známé z jazyka SQL - vnitřní a vnější spojení (join), agregační funkce, subdotazy, atd. Výsledek dotazu může být vrácen jako atribut, objekt, kolekce nebo pole objektů. Pokud bychom chtěli získat například objekty uživatelů, jejichž přihlašovací jméno začíná na tom, mohli bychom to provést pomocí následujícího HQL dotazu. from User as user where lower(user.username) like tom% ; S využitím Hibernate API by zdrojový kód metody, která bude vracet kolekci uživatelů s požadovaným přihlašovacím jménem, mohl vypadat takto: public Collection<User> getusersbyusername(string name) { } return session.createquery( "from User as user where lower(user.username) like :n").setparameter("n", name + "%" ).list(); Hibernate samozřejmě umožňuje zadávat dotazy i prostřednictvím jazyka SQL, avšak tento přístup má podstatnou nevýhodu, jíž je ztráta přenositelnosti mezi jednotlivými databázovými implementacemi, nebot každá většinou používá nějaký svůj SQL dialekt Spring Framework Spring Framework 7 je open source aplikační rámec pro vývoj aplikací na platformě Java. Může být použit jako alternativa k Java EE 8. Sám pokrývá v podstatě všechny vrstvy bežné 7. Dokumentaci lze nalézt na < 8. J2EE je zkratka z anglického Java Platform, Enterprise Edition. 31

39 4.2. TECHNOLOGIE enterprise aplikace (databázová, aplikační, prezentační), je však běžné, že je integrován spolu s dalšími frameworky usnadňujícími vývoj. Jádro Springu je založeno na návrhovém vzoru Inversion of Control (IoC), který umožňuje přenést zodpovědnost za vytváření a provázání objektů z aplikace na framework (jádro bývá označováno jako IoC kontejner). Při programování je běžné, že jednotlivé třídy systému jsou vzájemně propojené (jedna třída využívá další třídy, atd.). Tím pádem je mezi nimi velmi pevná vazba a pokud je potřeba vyměnit jednu třídu za druhou, vyžaduje to zásah do zdrojového kódu. IoC umožňuje tuto vazbu uvolnit tím, že třída nevytváří instance dalších potřebných tříd sama, ale jsou jí dodány z vnějšku pomocí tzv. Dependency Injection (vkládání závislostí). Mezi nejpoužívanější způsoby patří: Constructor Injection - injektování pomocí konstruktoru. Třída, do níž je vkládána instance další třídy musí mít konstruktor s parametrem typu vkládané třídy. Interface Injection - injektování prostřednictvím rozhraní. Rozhraní definuje metody, které slouží k nastavování různých instancí tříd. Aby třída mohla tyto instance využívat, musí implementovat dané rozhraní. Setter Injection - injektování pomocí setterů. Třída, do níž jsou vkládány instance dalších tříd, musí mít implementovány potřebné set metody. Právě tento přístup využívá Spring. Objekty, které může vytvářet IoC kontejner na základě jejich definic v XML souborech či anotací, se nazývají beans. Do nich mohou být dále vkládány odkazy na další objekty nebo mohou být samy injektovány. Spring Framework je tvořen zhruba 20 moduly, které jsou uspořádány do následujících skupin: Core Container, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation, and Test podle oblasti jejich využití. Není tedy potřeba využívat vždy celý rámec, ale pouze konkrétní modul, který se hodí na řešení daného problému. Následující části byly použity při implementaci systému: Core a Beans - poskytují základní funkcionalitu frameworku, včetně IoC a Dependency Injection. Důležitou součástí jsou BeanFactory, které slouží k vytváření, konfiguraci a spravování zmiňovaných beans. Jejich implementace je založena na návrhovém vzoru Abstract Factory (viz kapitola ). Context - dědí vlastnosti od modulu Beans a přidává podporu pro internacionalizaci, propagaci událostí, nahrávání zdrojů, vytváření kontextu (například servletovým kontejnerem) atd. Též podporuje některé Java EE technologie, jako EJB 9, JMX 10 a vzdálené volání. 9. EJB je zkratka z anglického Enterprise JavaBeans. 10. JMX je zkratka z anglického Java Management Extensions. 32

40 4.2. TECHNOLOGIE Expression Language - poskytuje jazyk pro dotazování a manipulaci s objekty. Jedná se o rozšíření jazyka Unified Expression Language, jež se používá v prostředí technologií JSP a JSF. Podporuje práci s proměnnými, volání metod, práci s poli a kolekcemi, logické a aritmetické operátory, získávání objektů podle jména z IoC kontejneru a mnohé další. ORM - poskytuje integrační vrstvu pro API zajišt ující objektově-relační mapování, například Hibernate, JPA, ibatis a další. Web - poskytuje základní webově orientované funkce a vlastnosti, jako nahrávání souborů, inicializaci IoC kontejneru pomocí servlet listenerů, webově orientovaný aplikační kontext, podporu pro vzdálené volání v prostředí webu. Web Servlet (MVC) - obsahuje implementaci vzoru MVC (viz kapitola 4.1.2) pro webové aplikace, což umožňuje například oddělit kód doménového modelu a webových formulářů a zároveň jednoduše spolupracovat s dalšími částmi frameworku. Obrázek 4.3: Struktura rámce Spring [8] Jako vhodná ukázka aplikační logiky pomocí rámce Spring poslouží kontroler pro zpracování údajů z registračního formuláře. 33