012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Internetový obchod s automobilovými náhradními díly D IPLOMOVÁ PRÁCE

ˇ Bc. Michal Cermák

Brno, podzim 2010

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D. ii

Podˇekování Rád bych podˇekoval RNDr. Radku Ošlejškovi, Ph.D. za vedení mé práce, vstˇrícný pˇrístup a cenné rady, které mi poskytl bˇehem konzultací. Podˇekování patˇrí také mým rodiˇcum, ˚ kteˇrí mˇe bˇehem studia podporovali.

iii

Shrnutí Obsahem práce je analýza, návrh a cˇ ásteˇcná implementace elektronického obchodu s automobilovými náhradními díly. Systém je namodelován v UML s durazem ˚ na použití softwarových vzoru˚ (analytických, návrhových a architektonických), jež jsou zárovenˇ popsány v jednotlivých kapitolách vˇenovaných ruzným ˚ fázím vývoje. Systém je napojen na webovou službu TecDoc, která slouží jako katalog náhradních dílu, ˚ a zárovenˇ na skladový systém Venet. Implementace je postavena na platformˇe Java Enterprise Edition a využívá aplikaˇcní rámce Hibernate, Spring a Spring Security.

iv

Klíˇcová slova Abstract Factory, analytické vzory, Data Access Object, Hibernate, návrhové vzory, Spring, TecDoc

v

Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Analýza . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Vize . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Diagram pˇrípadu˚ užití . . . . . . . . . . . . . 2.3 Doménový model . . . . . . . . . . . . . . . . 2.4 Analytické vzory . . . . . . . . . . . . . . . . 2.4.1 Historie vzniku vzoru˚ . . . . . . . . . 2.4.2 Vzory podle Fowlera . . . . . . . . . . 2.4.3 Pˇríklady vzoru˚ . . . . . . . . . . . . . 2.4.3.1 Organization Hierarchy . . . 2.4.3.2 Quantity . . . . . . . . . . . 2.5 Analytický model tˇríd . . . . . . . . . . . . . 3 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Návrhové vzory . . . . . . . . . . . . . . . . . 3.1.1 Puvod ˚ vzoru˚ . . . . . . . . . . . . . . 3.1.2 GoF vzory . . . . . . . . . . . . . . . . 3.1.3 Struktura vzoru˚ . . . . . . . . . . . . . 3.1.4 Pˇríklady vzoru˚ . . . . . . . . . . . . . 3.1.4.1 Factory Method . . . . . . . 3.1.4.2 Abstract Factory . . . . . . . 3.1.4.3 Data Access Object . . . . . . 3.1.4.4 DAO Factory . . . . . . . . . 3.2 Návrhový model tˇríd . . . . . . . . . . . . . . 4 Implementace . . . . . . . . . . . . . . . . . . . . . 4.1 Architektonické vzory . . . . . . . . . . . . . 4.1.1 Co jsou to architektonické vzory . . . 4.1.2 Model-View-Controller . . . . . . . . 4.1.3 Další vzory . . . . . . . . . . . . . . . 4.2 Technologie . . . . . . . . . . . . . . . . . . . 4.2.1 Hibernate . . . . . . . . . . . . . . . . 4.2.1.1 Úvod do problematiky . . . 4.2.1.2 Objektovˇe relaˇcní mapování 4.2.1.3 HQL . . . . . . . . . . . . . . 4.2.2 Spring Framework . . . . . . . . . . . 4.2.3 Spring Security . . . . . . . . . . . . . 4.2.4 TecDoc . . . . . . . . . . . . . . . . . . 4.2.4.1 Co je to TecDoc? . . . . . . . 4.2.4.2 TecDoc Web Service . . . . . 4.3 Diagram nasazení . . . . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 2 2 3 7 8 8 9 9 9 11 11 14 14 14 14 15 16 16 17 19 20 22 24 24 24 25 27 28 28 28 29 31 31 35 36 36 37 40 42 vi

Literatura . . . . . . . . . . . . . . . . . Rejstˇrík . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého CD . . . . . . B Textová specifikace pˇrípadu˚ užití C Analytický model tˇríd . . . . . . . D Ukázka uživatelského rozhraní .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

43 44 45 46 51 53

vii

Kapitola 1

Úvod S rozvojem internetu, a s ním souvisejících technologií, vzrustá ˚ jeho duležitost ˚ nejen jako ˇ zdroje informací a komunikaˇcního kanálu, ale také jako obchodní platformy. Cím dál tím více uživatelu˚ ho využívá k nákupum ˚ zboží. Vede je k tomu cˇ asto nižší cena oproti bˇežným kamenným obchodum, ˚ jednoduchost nákupu prostˇrednictvím poˇcítaˇce a také pohodlnost, nebot’ logistické spoleˇcnosti zboží doruˇcí v podstatˇe kamkoliv. Díky tomu je pro udržení konkurenceschopnosti firem prodávajících své zboží cˇ i služby nutné, aby tak cˇ inili i prostˇrednictvím elektronického obchodu. Cílem této práce je provést analýzu, návrh a cˇ ásteˇcnou implementaci elektronického obchodu s automobilovými náhradními díly, s durazem ˚ na použití softwarových vzoru˚ v jednotlivých etapách vývoje. Systém bude napojen na webovou službu TecDoc, která poslouží jako katalog náhradních dílu˚ a zárovenˇ na skladový systém Venet, ze kterého budou získávány informace o zákaznících. ˇ Práce je rozdˇelena na tˇri cˇ ásti. První z nich se zabývá analýzou. Ctenáˇ r se seznámí s vizí budoucího systému a oduvodnˇ ˚ ením vývoje nového rˇ ešení namísto využití již hotového open source systému. Následuje doménový model a diagram pˇrípadu˚ užití. Dále jsou pˇredstaveny analytické vzory, jež jsou využity pˇri modelování analytického diagramu tˇríd. Druhá cˇ ást se zabývá návrhem. Pˇredstavuje návrhové vzory a následnˇe návrhový model tˇríd, jenž tyto vzory využívá. Tˇretí cˇ ást se vˇenuje samotné implementaci. Nejprve je cˇ tenáˇr seznámen s architektonickými vzory a následnˇe s konkrétními technologiemi, jež byly použity pˇri vývoji systému, konkrétnˇe s aplikaˇcními rámci Hibernate, Spring a Spring Security a webovou službou TecDoc.

1

Kapitola 2

Analýza Tato kapitola se zabývá analýzou požadavku˚ na systém a základní analýzou systému - internetového obchodu s automobilovými náhradními díly. Kromˇe úvodní cˇ ásti, jež pˇredstavuje vizi systému, kapitola obsahuje UML1 modely využívané pˇri analýze, konkrétnˇe diagram pˇrípadu˚ užití, doménový model a analytický model tˇríd. Její souˇcástí je také podkapitola o analytických vzorech, které byly pˇri 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íkum. ˚ Hlavním cílem je vyvinout systém (internetový obchod), který umožní zákazníkum ˚ interaktivnˇe vyhledávat a objednávat zboží prostˇrednictvím elektronické komunikace, aniž by byli nˇejakým zpusobem ˚ cˇ asovˇe cˇ i místnˇe omezeni. Z hlediska zákazníka dojde ke znaˇcnému zlepšení dostupnosti služeb, nebot’ v souˇcasné dobˇe lze zboží objednávat pouze pˇrímo na prodejnˇe firmy nebo telefonicky, což muže ˚ být pro nˇekteré zákazníky jistým handicapem (omezená otevírací doba, dojezdová vzdálenost k nˇekteré z prodejen). Elektronický obchod budou moci využívat nepˇretržitˇe 24 hodin 7 dní v týdnu. Pro vedení firmy bude systém taktéž pˇrínosem. Pokud si zákazník zboží sám vyhledá a objedná pˇres internetový obchod, zmenší se vytížení zamˇestnancu˚ spojené s vyˇrizováním objednávek a ti budou moci ušetˇrený cˇ as vˇenovat jiným cˇ innostem spojeným s rozvojem firmy. Z obchodního hlediska systém umožní oslovit nové potencionální zákazníky a obecnˇe zvýšit povˇedomí o spoleˇcnosti. Vzhledem k tomu, že firmy se stejným nebo podobným obchodním zamˇerˇ ením již velmi cˇ asto elektronické obchody mají, stává se v souˇcasné dobˇe využití tohoto systému v podstatˇe nutností k zajištˇení konkurenceschopnosti. V souˇcasné dobˇe existuje celá rˇ ada open source systému˚ (internetových obchodu), ˚ jako

1.

UML je zkratka z anglického Unified Modeling Language.

2

ˇ ˚ UŽITÍ 2.2. DIAGRAM P RÍPAD U pˇríklad lze uvést OpenCart2 , tomatoCart3 , PrestaShop4 , ZenCart5 , osCommerce6 a mnoho dalších. Nabízí se tak otázka, proˇc nˇekteré z tˇechto volnˇe dostupných rˇ ešení nevyužít. Hlavním duvodem ˚ je pˇredevším skuteˇcnost, že obchodní doména automobilových náhradních dílu˚ je pomˇernˇe specifická, zatímco open source systémy pˇredstavují vesmˇes univerzální rˇ ešení. To znamená, že je lze velmi dobˇre použít jako rychlé a snadné rˇ ešení na eshop s obleˇcením, sportovními potˇrebami nebo hraˇckami pro dˇeti. Charakteristické pro nˇe je, že využívají vlastní databázi zboží, nabízené produkty si vystaˇcí s nˇekolika základními atributy (název, popis zboží, cena, . . . ) a spuštˇení eshopu je v podstatˇe otázka nˇekolika hodin. Za nevýhody lze považovat témˇerˇ nezmˇenitelný design (co se týˇce rozmístˇení jednotlivých prvku), ˚ ne vždy kompletní lokalizace cˇ 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ˇrípadˇe webovou službu TecDoc. Duvod ˚ je ten, že nabízených produktu˚ od mnoha ruzných ˚ výrobcu˚ budou rˇ ádovˇe desítky tisíc a v podstatˇe není možné je všechny ruˇcnˇe spravovat ve vlastní databázi. Pro vyhledání konkrétního náhradního dílu je potˇreba zadat údaje nejen o automobilu jako celku (výrobce, model, rok výroby), ale mnohdy také specifické údaje k jednotlivým cˇ á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ˇekteré další specifické produkty, které není možné získat z TecDocu. Pokud bychom tedy chtˇeli využít nˇejaké open source rˇ ešení, znamenalo by to rozsáhlé zásahy do jeho zdrojových kódu. ˚ Avšak ne každý kód je psán cˇ itelnˇe, srozumitelnˇe a s kvalitní dokumentací a proto jakékoliv jeho zmˇeny mohou být velkým problémem. Vzhledem k uvedeným skuteˇcnostem se tak jeví jako nejlepší rˇ ešení vyvinout vlastní systém se zamˇerˇ ením na zmínˇené specifické nároky. Pro úˇcely této prace jej nazývejme Ashop.

2.2

Diagram pˇrípadu˚ užití

Diagram pˇrípadu˚ užití slouží k zachycení funkˇcních požadavku˚ na systém. Je primárnˇe urcˇ en k modelování chování systému, aniž by zobrazoval jeho vnitˇrní strukturu. Základními komponentami diagramu jsou úˇcastníci, pˇrípady užití a vazby mezi nimi. Úˇcastníci jsou role pˇridˇelené osobám nebo pˇredmˇetum, ˚ které používají daný systém (lidé, externí systémy, cˇ ásti hardwaru, cˇ as). Pˇrípady užití jsou cˇ innosti, které muže ˚ systém vykonávat prostˇrednictvím interakce s externími úˇcastníky (ˇcinnosti požadované po systému). K zachycení vlastností konkrétního pˇrípadu užití se podle fáze analýzy používá dokumentace s ruznou ˚ úrovní detailu. ˚ K jejímu vyjádˇrení lze použít textovou specifikaci, diagram aktivit, stavový diagram, sekvenˇcní diagram nebo komunikaˇcní diagram [9]. 2. 3. 4. 5. 6.

3

ˇ ˚ UŽITÍ 2.2. DIAGRAM P RÍPAD U Textová specifikace vˇetšinou obsahuje název pˇrípadu užití, identifikaˇcní cˇ íslo, struˇcný popis, seznam úˇcastníku, ˚ vstupní podmínky, hlavní tok událostí, výstupní podmínky a alternativní toky.

Obrázek 2.1: Diagram pˇrípadu˚ užití Systém Ashop, jehož diagram pˇrípadu˚ 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ˇredstavuje zákazníky, kteˇrí nejsou zaregistrováni do systému (nemají vytvoˇrený úˇcet). Mohou vyhledávat zboží a následnˇe si ho objednat prostˇrednictvím nákupního košíku. Mohou se registrovat.

•

Neregistrovaný velkoobchodní zákazník - zahrnuje velkoobchodní zákazníky, kteˇrí u firmy pravidelnˇe nakupují prostˇrednictvím kamenné prodejny a mají pˇridˇeleno tzv. zákaznické cˇ íslo. Pomocí nˇeho se mohou do systému zaregistrovat a automaticky jim tak budou nastaveny slevy, které mají pˇridˇeleny. Jinak mohou systém používat stejnˇe jako neregistrovaní zákazníci. 4

ˇ ˚ UŽITÍ 2.2. DIAGRAM P RÍPAD U •

Zákazník - pˇredstavuje zákazníky, kteˇrí mají v systému vytvoˇrený uˇcet. Oproti neregistrovaným zákazníkum ˚ si navíc mohou prohlížet historii svých objednávek a mˇenit nastavení svého úˇctu.

•

Zamˇestanec - tato role zastupuje zamˇestnance firmy, kteˇrí mají na starosti vyˇrizování pˇrijatých objednávek a ovˇerˇ ování registrací velkoobchodních zákazníku. ˚

•

Administrátor - pˇredstavuje zamˇestnance s nejvyšším oprávnˇením. Umožnuje ˇ spravovat uživatelské úˇcty v systému, mˇenit nastavení eshopu, spravovat kategorie a jim pˇriˇrazené produkty.

Následuje textová specifikace jednotlivých pˇrípadu˚ užití identifikovaných v modelovaném systému. Vzhledem k tomu, že je pomˇernˇe rozsáhlá, uvádím zde pouze její cˇ ást. Kompletní dokumentaci lze nalézt v pˇríloze B. •

Registrace zákaznickým cˇ íslem - umožnuje ˇ uživateli provést registraci pomocí zákaznického cˇ ísla. Po vyplnˇení registraˇcního formuláˇre s povinnými údaji (zákaznické cˇ íslo, email, telefon) a jeho odesláním je registrace uložena do systému a cˇ eká na zpracování.

ˇíslo. Vstupní podmínky: uživatel zná své zákaznické c Aktéˇ ri: neregistrovaný velkoobchodní zákazník. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "registrace zákaznickým ˇ císlem". 2. Systém zobrazí editovatelný registraˇ cní formuláˇ r. 3. Uživatel vyplní formuláˇ r a klikne "registrovat". 4. Systém uloží registraci do databáze.

•

Registrace - umožnuje ˇ vytvoˇrit nový zákaznický úˇcet v systému. Po vyplnˇení povinných údaju˚ registraˇcního formuláˇre a jeho odeslání je zákazník zaregistrován a muže ˚ se pˇrihlásit do systému.

Aktéˇ ri: neregistrovaný zákazník. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "registrace". 2. Systém zobrazí editovatelný registraˇ cní formuláˇ r. 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ˇ rí nový uživatelský uˇ cet. 5.2 PU konˇ cí. 6. ELSE pokraˇ cuje krokem 2.

•

Vyhledání zboží - umožnuje ˇ vyhledat náhradní díly a doplnky ˇ k automobilum ˚ bud’ pˇrímo zadáním cˇ ísla výrobku nebo vybráním konkrétního automobilu (výrobce, model, typ motoru) a následnˇe prohledáním katalogu dostupných výrobku˚ pro tento automobil. 5

ˇ ˚ UŽITÍ 2.2. DIAGRAM P RÍPAD U Aktéˇ ri: neregistrovaný zákazník, webová služba TecDoc. Tok událostí: 1. PU zaˇ cíná tím, že uživatel klikne na "náhradní díly". 2. Systém zobrazí seznam výrobc˚ u automobil˚ u (audi, citroen, ...). 3. Uživatel klikne na konrétního výrobce. 4. Systém zobrazí seznam model˚ u pro vybraného výrobce automobilu. 5. Uživatel klikne na konkrétní model automobilu. 6. Systém zobrazí seznam typ˚ u 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í ˇ císlo a klikne na "vyhledat". 2. Systém zobrazí nalezené zboží.

•

Správa nákupního košíku - zahrnuje pˇridání vyhledaného zboží, odebrání nebo zmˇenu množství zboží v košíku. Nákupní košík zobrazuje informace o zboží (objednací cˇ íslo, název, cena, poˇcet kusu) ˚ a celkovou cenu nákupu. Zboží v nákupním košíku si muže ˚ zákazník objednat.

Aktéˇ ri: neregistrovaný zákazník.

•

Objednání zboží - umožnuje ˇ objednat zboží v nákupním košíku. Uživatel zvolí zpu˚ sob dopravy, zpusob ˚ platby, vyplní nebo pouze zkontroluje (pokud byly naˇcteny z uživatelského profilu) dodací a fakturaˇcní údaje a následnˇe potvrdí objednávku.

Aktéˇ ri: neregistrovaný zákazník. Vstupní podmínky: Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "objednat". 2. Systém zobrazí formuláˇ r pro volbu zp˚ usobu dopravy. 3. Uživatel vybere zp˚ usob dopravy a klikne "pokraˇ covat". 4. Systém zobrazí formuláˇ r pro volbu zp˚ usobu platby. 5. Uživatel vybere zp˚ usob platby a klikne na "pokraˇ covat". 6. Systém zobrazí formuláˇ r pro zadání fakturaˇ cní a dodací adresy. 7. Uživatel vyplní údaje a klikne na "pokraˇ covat". 8. Systém zobrazí souhrn všech údaj˚ u. 9. Uživatel klikne na "objednat". 10. Systém uloží objednávku do databáze a zašle uživateli informaˇ cní email. Alternativní tok: 1. Uživatel se m˚ uže vrátit na pˇ redchozí krok kliknutím na "zpˇ et". 2. Uživatel m˚ uže objednávku kdykoliv pˇ rerušit.

•

Prohlížení objednávek - umožnuje ˇ uživateli prohlížet detaily o všech svých realizovaných objednávkách. 6

2.3. DOMÉNOVÝ MODEL Aktéˇ ri: zákazník. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cí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 úˇctu - umožnuje ˇ uživateli editovat osobní cˇ i firemní údaje, fakturaˇcní a dodací adresu a kontaktní údaje.

Aktéˇ ri: zákazník. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "m˚ uj úˇ cet". 2. Systém zobrazí seznam možných nastavení. 3. Uživatel klikne na konkrétní položku nastavení. 4. Systém zobrazí formuláˇ r pro editaci požadovaného nastavení. 5. Uživatel zmˇ ení požadované údaje a klikne na "uložit". 6. Systém uloží zmˇ eny do databáze.

2.3

Doménový model

Doménový model je konceptuální model z oblasti zájmu, cˇ asto oznaˇcované jako problémové domény. Vytváˇrí se s cílem zachytit klíˇcové 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ˇekterých pˇrípadech také jejich atributy. Významným pˇrínosem tohoto modelu je skuteˇcnost, že popisuje a zárovenˇ omezuje rozˇ sah problémové domény. Casto se využívá pˇri schvalování a ovˇerˇ ování pochopení problémové domény mezi ruznými ˚ zainteresovanými stranami a stává se užiteˇcným komunikaˇcním nástrojem napˇrí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ˇestnanec - entita reprezentuje zamˇestnance firmy, kteˇrí budou se systémem pracovat. Mají na starosti vyˇrizování objednávek a spravování eshopu.

•

Objednávka - je vytváˇrena zákazníkem a vyˇrizována zamˇestnancem. Uchovává informace o objednaných produktech (množství, celková cena). Objednávka se nachází v ruzné ˚ fázi zpracování (pˇrijatá, zrušená , vyˇrízená, . . . ).

•

Doprava a platba - tyto entity reprezentují ruzné ˚ druhy dopravy a zpusoby ˚ platby, které muže ˚ zákazník využít pˇri objednávání zboží.

•

Zákazník - reprezentuje zákazníky, kteˇrí budou systém využívat za úˇcelem objednání zboží. Entita uchovává jejich osobní a kontaktní údaje, slevy. 7

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) muže ˚ být svázán s konkrétním automobilem, na který se montuje.

•

Kategorie - produkty jsou podle ruzných ˚ vlastností sdružovány do kategorií, které zákazníkovi usnadnují ˇ vyhledávání.

•

Automobil - entita uchovává informace o ruzných ˚ typech automobilu˚ a jejich vlastnostech (výrobce, model, objem motoru, rok výroby, typ paliva, . . . ).

2.4

Analytické vzory

2.4.1

Historie vzniku vzoru˚

Pojem vzor se poprvé objevil v práci Christophera Alexandera, profesora architektury na californské univerzitˇe v Berkeley, na konci 70. let minulého století. Alexander vymyslel rˇ adu teorií o vzorech v architektuˇre a zveˇrejnil je v nˇekolika 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ˇrí roli Ch. Alexandera, jako hlavní zdroj inspirace pro softwarové vzory, zpochybnují. ˇ Za publikaci, která mˇela daleko vˇetší vliv na softwarové vzory, považují knihu „Design Patterns: Elements of Reusable Object-Oriented Software“ [5] autoru˚ GoF7 . Zajímavostí je, že tˇri z tˇechto autoru˚ Alexanderovu knihu pˇred napsáním této neˇcetli. 7. GoF je zkratka z anglického Gang of Four. Používá se jako oznaˇcení pro cˇ tveˇrici autoru˚ - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides.

8

2.4. ANALYTICKÉ VZORY 2.4.2

Vzory podle Fowlera

Pod pojmem analytický vzor si lze pˇredstavit cˇ ást analytického modelu, kterou je možné opakovanˇe použít v podobných aplikaˇcních oblastech. Jde v podstatˇe o zobecnˇené rˇ ešení nˇejakého problému, jež vychází z dlouhodobé zkušenosti a jehož správnost byla mnohokrát ovˇerˇ ena praxí. Systém analytických vzoru˚ 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ˇelena na dvˇe cˇ ásti. První obsahuje analytické vzory, druhá vzory podpurné, ˚ které mohou být využity pˇri aplikaci analytických vzoru. ˚ Analytické vzory jsou rozdˇeleny do 9 kategorií, jež se týkají urˇcité doménové oblasti (koupˇe a prodej produktu, ˚ záznamy údaju˚ a mˇerˇ ení, . . . ). Každá z nich obsahuje soubor analytických vzoru, ˚ které jsou pˇredstavovány od tˇech nejjednodušších. Postupnˇe jsou tyto vzory rozšiˇrovány a kombinovány s ostatními, cˇ ímž nakonec vznikají pomˇernˇe rozsáhlé a komplexní vzory. Rozdˇelení vzoru˚ do kategorií s charakteristikou jejich doménové oblasti, jíž se zabývají, je následující: •

Accountability - rˇ ešení organizaˇcní struktury a odpovˇednosti osob.

•

Observations and Measurements - záznamy údaju˚ a mˇerˇ ení.

•

Observations for Corporate Finance - analýza složitých finanˇcních vztahu˚ a výsledku˚ ve firmách.

•

Referring to Objects - identifikace objektu. ˚

•

Inventory and Accounting - inventury a sledování penˇežních toku. ˚

•

Planning - plánování akcí a protokoly pro plánování.

•

Trading - koupˇe a prodej produktu. ˚

•

Derivative Contracts - ceny a jejich odvozování od ruzných ˚ subjektu. ˚

•

Trading Packages - cˇ lenˇení systému se složitou doménovou oblastí.

2.4.3

Pˇríklady vzoru˚

2.4.3.1 Organization Hierarchy Vzor Organization Hierarchy patˇrí do souboru vzoru˚ Accountability, jež se zabývají organizací struktur a jejich vzájemných vztahu. ˚ Mˇejme mezinárodní spoleˇcnost, která má operaˇcní jednotky na úrovni kontinentu, ˚ jež jsou rozdˇeleny na regiony. Ty jsou dále rozdˇeleny na divize na úrovni státu˚ a v každém z nich operuje nˇekolik prodejcu˚ jejího zboží. Uvedenou situaci mužeme ˚ jednoduše modelovat zpusobem ˚ uvedeným na obrázku 2.3. 9

2.4. ANALYTICKÉ VZORY

Obrázek 2.3: Struktura spoleˇcnosti modelovaná bežným zpusobem ˚ Tento model ovšem není ani flexibilní, ani znovupoužitelný. Pokud se struktura spoleˇcnosti zmˇení a napˇríklad divize budou zrušeny, znamená to zmˇenit výše uvedený model. Nelze jej použít pro spoleˇcnosti s jinou organizaˇcní strukturou nebo jinými názvy organizaˇcˇ ních jednotek. Rešením tohoto problému je použití velmi jednoduchého modelu s využitím rekurzivních vztahu, ˚ jak ukazuje obrázek 2.4.

Obrázek 2.4: Využití rekurze Nebezpeˇcím modelu s rekurzí je, že umožnuje ˇ regionu být napˇríklad cˇ ástí divize nebo prodejce. To lze vyˇrešit definováním podtypu˚ korespondujících s jednotlivými úrovnˇemi organizace, kterým dáme urˇcitá omezení. Výsledný model je na obrázku 2.5.

Obrázek 2.5: Typ Organization s podtypy a jejich omezeními

10

ˇ 2.5. ANALYTICKÝ MODEL T RÍD 2.4.3.2 Quantity Pˇri modelování informaˇcních systému˚ je velmi cˇ asto potˇreba o objektech reálného svˇeta uchovávat mnoho informací ruzných ˚ typu. ˚ Mˇejme lékaˇrskou ordinaci, která potˇrebuje ukládat údaje o pacientech. Typickým zpusobem, ˚ jak uchovat nˇejakou informaci, je uložit ji jako atribut objektu. Pokud u váhy pacienta zaznamenáme cˇ íslo 80, vˇetšinou už neuvádíme, že se jedná o váhu v kilogramech. Aˇckoliv je tento pˇrístup velmi cˇ asto používán, není pˇríliš univerzální. Mnohem výstižnˇejší by bylo uchovávat informaci ve formˇe hodnota - jednotka. Právˇe takový pˇrístup využívá analytický vzor Quantity, který patˇrí do souboru vzoru˚ Observation and Measurement.

Obrázek 2.6: Analytický vzor Quantity Pokud uvedený vzor aplikujeme na pˇríklad s váhou pacienta, má osoba atribut váha typu Quantity s množstvím 80 a jednotkou kilogram. Dalším pˇríkladem využití muže ˚ být uchovávání finanˇcní cˇ á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árovenˇ definuje povolené operace na hodnotách, které jsou uchovávány ve stejných jednotkách.

2.5

Analytický model tˇríd

Diagram tˇríd zobrazuje statický pohled na systém, zejména na tˇrídy a vzájemné vztahy mezi nimi, jejich atributy a operace. Analytický model je typem diagramu tˇríd, který se využívá pˇri analýze. Modeluje obchodní doménu systému - typy objektu˚ a vztahy mezi nimi. Jako výchozí dokumentace muže ˚ sloužit doménový model. Hlavním cílem pˇri vytváˇrení analytického modelu je zachování pˇrehlednosti a jednoduchosti bez zanášení jakýchkoliv implementaˇcních detailu. ˚ Vzhledem k tomu, že systém Ashop bude cˇ ásteˇcnˇe napojen na skladový systém Venet, který v souˇcasné dobˇe firma používá, a bude z nˇej získávat nˇekterá data o nabízených produktech, je potˇreba zahrnout tuto specifickou cˇ ást systému do analytického modelu. Zárovenˇ je nutné cˇ ásteˇcnˇe vycházet z již zmínˇeného skladového systému, duležitý ˚ je zejména zpusob ˚ stanovování ceny jednotlivých produktu. ˚ Problémová oblast je následující. V souˇcasném systému je každý produkt zaˇrazen do nˇejakého oddˇelení. Oddˇelení muže ˚ být dále rozdˇeleno na pododdˇelení a produkt tedy muže ˚ 11

ˇ 2.5. ANALYTICKÝ MODEL T RÍD zárovenˇ patˇrit do nˇejakého pododdˇelení. Jednotlivá oddˇelení mohou být sdružována do skupin. Zákazníci mohou mít ruzné ˚ slevy. Ty se však neváží na konkrétní produkt, ale na urˇcitou skupinu, oddˇelení nebo pododdˇelení. Pˇri výpoˇctu koneˇcné ceny produktu se uplatnuje ˇ nejvyšší sleva. Pro lepší pochopení uved’me názorný pˇríklad. Mˇejme produkt patˇrící do oddˇelení 25 a jeho pododdˇelení 3. Zákazník A má slevu 10 % na produkty z oddˇelení 25, žádnou jinou slevu nemá. Zákazník B má slevu 5 % na oddˇelení 25 a slevu 15 % na pododdˇelení 3 oddˇelení 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ˇe totožný s problémem modelovaným pomocí analytického vzoru Organization Hierarchy zminovaného ˇ v pˇredchozí kapitole. Jediným rozdílem je problémová oblast. Zde se jedná o produkty zaˇrazené do nˇejaké logické hierarchie, v pˇríkladu uvedeném pˇri popisu vzoru šlo o hierarchickou strukturu cˇ lenˇení mezinárodní spoleˇcnosti. Další oblastí vhodnou pro využití analytického vzoru, konkrétnˇe Quantity, je modelování produktu a jeho vlastností. Opˇet uved’me pˇríklad. Automobilový náhradní díl, napˇríklad olejový filtr, má jako základní parametry výšku, vnˇejší a vnitˇrní prumˇ ˚ er. Rozvodový rˇ emen má parametry poˇcet zubu˚ a tloušt’ku. Opˇet se liší pouze problémová oblast. Zde se jedná o uchovávání parametru˚ náhradních dílu˚ v ruzných ˚ jednotkách, v pˇríkladu z pˇredcházející kapitoly šlo o ukládání informací o zdravotním stavu pacienta. Vzor Quantity lze využít i pˇri modelování dostupnosti produktu. Chceme-li uchovávat informaci o množství zboží skladem, je vhodné využít kombinaci hodnota - jednotka. Napˇríklad - brzdový váleˇcek: 2 kusy, diamantová rˇ ezací struna: 20 metru, ˚ nemrznoucí smˇes do ostˇrikovaˇcu: ˚ 230 litru. ˚ Na obrázku 2.7 na následující stranˇe je cˇ ást analytického modelu, na nˇemž jsou barevnˇe zvýraznˇeny oblasti, které byly modelovány s použitím popisovaných vzoru. ˚ Kompletní analytický model je uveden v pˇríloze C.

12

ˇ 2.5. ANALYTICKÝ MODEL T RÍD

ˇ Obrázek 2.7: Cást analytického modelu tˇríd s využitím analytických vzoru˚

13

Kapitola 3

Návrh Tato kapitola navazuje na analýzu a zabývá se návrhem systému Ashop. První cˇ ást popisuje pozadí vzniku návrhových vzoru˚ a jejich základní cˇ lenˇení. Pˇredstavuje GoF vzory, konkrétnˇe Factory Method a Abstract Factory a dále J2EE1 vzor Data Access Object, který z nich vychází. Druhá cˇ ást obsahuje návrhový diagram tˇríd, který ukazuje pˇríklady použití vzoru˚ v kontextu modelovaného systému.

3.1

Návrhové vzory

3.1.1

Puvod ˚ vzoru˚

Pojem návrhový vzor se poprvé objevil na konferenci OOPSLA2 v roce 1987, kde Kent Beck a Ward Cunningham prezentovali sérii pˇrednášek na téma „Where do objects come from?“. Pˇredstavili na nich nˇekolik návrhových vzoru, ˚ které vytvoˇrili na základˇe svých problému˚ s návrhem aplikací pro programovací jazyk Smalltalk. Poˇcatkem devadesátých let minulého století se zaˇcala utváˇret již zminovaná ˇ skupina Gang of Four. V roce 1994 pˇredstavila na konferenci OOPSLA svoji knihu o návrhových vzorech „Design Patterns: Elements of Reusable Object-Oriented Software“ [5]. Kniha mˇela velký úspˇech a je dodnes považována za ústˇrední dílo z oblasti softwarových návrhových vzoru. ˚ 3.1.2

GoF vzory

Návrhové vzory, podobnˇe jako analytické, pˇredstavují obecné rˇ ešení nˇejakého cˇ 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ˇrímo vložit do vyvíjeného softwaru. Návrhový vzor je pouze šablona cˇ i popis rˇ ešení, které muže ˚ být použito v ruzných ˚ situacích. Aˇckoliv od vydání zminované ˇ knihy autoru˚ GoF uplynulo více než patnáct let, z hlediska rychlosti vývoje v oblasti informaˇcních technologií je to doba opravdu dlouhá, základní rozdˇelení vzoru˚ do skupin, které v ní bylo pˇredstaveno, se používá dodnes a v podstatˇe vˇetšina novˇejších knih o návrhových vzorech z tohoto cˇ lenˇení vychází. Rozdˇelení vzoru˚ 1. 2.

J2EE je zkratka z anglického Java 2 Enterprise Edition. Dnes se velmi cˇ asto používá pouze zkratka JEE. OOPSLA je zkratka z anglického Object-Oriented Programming, Systems, Languages & Applications.

14

3.1. NÁVRHOVÉ VZORY je následující: •

Creational Patterns (tvoˇrící vzory) Jak již napovídá název, vzory rˇ eší problémy s vytváˇrením objektu˚ v systému. Cílem tˇechto návrhových vzoru˚ je popsat postup výbˇeru tˇrídy nového objektu a zajištˇení správného poˇctu tˇechto objektu. ˚ Vˇetšinou se jedná o dynamická rozhodnutí uˇcinˇená za bˇehu programu. Mezi tyto vzory patˇrí: Abstract Factory, Builder, Factory Method, Prototype a Singleton.

•

Structural Patterns (strukturální vzory) Strukturální vzory reprezentují skupinu vzoru, ˚ které se zamˇerˇ ují na možnosti usporˇ ádání jednotlivých tˇríd nebo komponent v systému. Jejich cílem je zpˇrehlednit systém a využít možností strukturalizace zdrojového kódu. Mezi strukturální vzory patˇrí: 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ˇrídách nebo objektech. U tˇríd využívají pˇri návrhu rˇ ešení pˇredevším principu dˇediˇcnosti. V druhém pˇrípadˇe rˇ eší spolupráci mezi objekty a skupinami objektu, ˚ která zajišt’uje dosažení požadovaného výsledku (chování systému). Mezi vzory chování patˇrí: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method a Visitor.

S rozvojem nových technologií postupem cˇ asu vznikly další kategorie vzoru, ˚ napˇríklad Concurrency Patterns [2], které mají za úkol rˇ ešit multivláknové programování - vzory Scheduler, Thread Pool, Reactor a mnohé další. Existují také vzory pro konkrétní platformu, napˇríklad J2EE Patterns [6]. Vˇetšina novˇe vzniklých vzoru˚ má však jednu spoleˇcnou vlastnost - vycházejí, rozšiˇrují nebo v sobˇe integrují nˇekteré ze vzoru˚ GoF. 3.1.3

Struktura vzoru˚

Každý popis návrhového vzoru by mˇel obsahovat všechny podstatné a zárovenˇ dobˇre strukturované informace vedoucí k tomu, že vzor bude lehce pochopitelný a použitelný, bude snadné se ho nauˇcit 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 PLoP3 , které obsahuje následující základní prvky4 :

3. 4.

•

Jméno - vzor by mˇel mít smysluplný a snadno zapamatovatelný název vystihující jeho podstatu.

•

Problém - obsahuje popis problému, který daný vzor rˇ eší. PLoP je zkratka z anglického Pattern Languages of Programs. V závislosti na použité literatuˇre se mohou názvy mírnˇe lišit, avšak jejich význam by mˇel být stejný.

15

3.1. NÁVRHOVÉ VZORY •

Kontext/podmínky - popisuje veškeré okolnosti a podmínky, za kterých je možné vzor použít.

•

ˇ Rešení - obsahuje soubor pravidel ve formˇe textu, obrázku˚ cˇ i diagramu, ˚ které výsvˇetlují, jak dosáhnout požadovaných výsledku˚ a objasnují ˇ základní principy vzoru.

•

Výsledný kontext/podmínky - popisuje stav nebo konfiguraci systému po aplikování vzoru. Jeden vzor cˇ asto nepˇredstavuje kompletní rˇ ešení složitˇejšího problému, ale pouze jeho cˇ ást. Výsledný stav po použití jednoho vzoru muže ˚ být výchozím bodem pro použití dalšího vzoru.

•

Pˇríklady - každý popis by mˇel obsahovat jednu cˇ i více ukázek praktického použití vzoru, napˇríklad ve formˇe zdrojového kódu, která ilustruje výše uvedené cˇ ásti: problém, kontext a rˇ ešení.

•

Zduvodnˇ ˚ ení - obsahuje vysvˇetlení vzoru jako celku nebo jeho jednotlivých souˇcástí. Ukazuje, jak vzor skuteˇcnˇe funguje a jakým zpusobem ˚ zajišt’uje dosažení požadovaných cílu. ˚ Narozdíl od cˇ ásti rˇ ešení, která je jakýmsi pohledem z vnˇejšku, tato cˇ ást by mˇela naopak ukázat jeho vnitˇrní fungování.

•

Související vzory - cˇ asto se stává, že použití jednoho vzoru nepˇredstavuje ucelené rˇ 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ˇcné rˇ ešení tak muže ˚ být výsledkem aplikace nˇekolika souvisejících vzoru. ˚ Nˇekdy je možné rˇ ešit problém ruznými ˚ zpusoby ˚ (za pomoci odlišných vzoru) ˚ a pak je vhodné se o nich v této cˇ ásti zmínit.

•

Reference - popisuje známé použití vzoru v existujících systémech, které ovˇerˇ uje, že vzor skuteˇcnˇe pˇredstavuje osvˇedˇcené rˇ ešení pro daný opakující se problém (zvyšuje duvˇ ˚ eryhodnost). Muže ˚ sloužit také jako cˇ ást pˇríklady.

3.1.4

Pˇríklady vzoru˚

Následující cˇ ást pˇredstavuje konkrétní návrhové vzory, které byly využity bud’ pˇrímo a nebo jako souˇcást jiného vzoru použitého pˇri modelování systému. 3.1.4.1 Factory Method Factory Method [5] je jedním ze vzoru˚ GoF rˇ adící se do skupiny Creational Patterns (tvoˇrící ˇ vzory). Reší problém, jakým zpusobem ˚ za bˇehu programu rozhodnout o vytvoˇrení konkrétní instance tˇrídy. Pˇredpokladem pro použití tohoto vzoru je existence nˇekolika tˇríd, které mají vˇetšinou spoleˇcného pˇredka, ale poskytují ruzné ˚ služby nad ruznými ˚ daty. Factory Method pak umožnuje ˇ za bˇehu programu vybrat, kterou instanci nˇekteré z tˇechto tˇríd vytvoˇrit. Schéma vzoru na obrázku 3.1 obsahuje následující komponenty: 16

3.1. NÁVRHOVÉ VZORY

Obrázek 3.1: Vzor Factory Method •

Product - definuje rozhranní objektu˚ (obecnou tˇrídu), které jsou vytváˇreny pomocí FactoryMethod. Muže ˚ být implementována napˇríklad jako abstraktní tˇrída.

•

ConcreteProduct - implementuje rozhranní (rozšiˇruje tˇrídu) Product.

•

Creator - deklaruje metodu FactoryMethod, která je zodpovˇedná za vytváˇrení objektu˚ typu Product. Muže ˚ definovat výchozí implementaci této metody, která vrací defaultní objekt typu ConcreteProduct.

•

ConcreteCreator - pˇrekrývá FactoryMethod tak, aby vracela konkrétní instanci tˇrídy typu ConcreteProduct.

•

Client - pˇredstavuje klienta, který má referenci na objekt typu Creator, od nˇehož vyžaduje vytvoˇrení požadované instance tˇrídy typu Product.

Obecnˇe je využíván princip, kdy jedna instance tˇrídy ConcreteCreator vytváˇrí instance jedné z možných tˇríd typu ConcreteProduct. Klient si vytvoˇrí, 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 objektu. ˚ FactoryMethod muže ˚ rozhodnout, zda vytvoˇrí a vrátí novou instanci tˇrídy nebo použije již vytvoˇrený objekt, který není právˇe používán (tento princip se cˇ asto využívá pro pˇripojení k databázi). Výhodou vzoru je pˇredevším flexibilita, protože aplikaˇcní logika pro vytváˇrení objektu˚ je uzavˇrena do jedné tˇrídy a tím pádem lze jakoukoliv zmˇenu provést na jednom místˇe. Mezi související vzory patˇrí pˇredevším Abstract Factory, Template Method a Prototype. 3.1.4.2 Abstract Factory Abstract Factory [5] je dalším z tvoˇrících vzoru˚ podle GoF. Poskytuje rozhraní pro vytváˇrení rodin pˇríbuzných nebo závislých objektu˚ bez specifikace konkrétních tˇríd. Nahrazuje pˇrímé volání kostruktoru tˇrídy voláním tvoˇrící metody továrního objektu. Tento vzor poskytuje o nˇeco vyšší míru abstrakce (v podobˇe rozhranní) než Factory Method, cˇ ehož se využívá v pˇrípadech, kdy existuje nˇekolik tˇríd, které vytváˇrejí instance svých 17

3.1. NÁVRHOVÉ VZORY produktu. ˚ Každá z tˇechto tˇríd vytváˇrí jiný typ produktu, ale ty spolu nˇejakým zpusobem ˚ souvisí (mají spoleˇcené vlastnosti, odpovídají stejnému uživatelskému rozhraní). Abstract Factory umožnuje ˇ za bˇehu programu jednu z tˇechto tˇríd vybrat, aniž by tím zasahoval do dalších cˇ ástí systému.

Obrázek 3.2: Vzor Abstract Factory Zmínˇených vlastností je dosaženo díky vytvoˇrení abstraktní tˇrídy, pˇrípadnˇe rozhraní, jak pro konkrétní produkty, tak pro tˇrídy vytváˇrejí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áˇrejí objekty typu AbstractProduct.

•

ConcreteFactory - implementuje metody z rozhraní AbstractFactory. Tyto metody vytváˇrejí konkrétní produkty.

•

AbstractProduct - deklaruje rozhraní pro objekty typu Product.

•

Product - pˇredstavuje konkrétní produkt, který je vytváˇren s ním související továrnou. Implementuje rozhraní AbstractProduct.

Klient si vytváˇrí konkrétní instanci tovární tˇrídy typu ConcreteFactory, která implementuje rozhranní (v pˇrípadˇe abstraktní tˇrídy dˇedí z) AbstractFactory. Tato instance vytváˇrí objekty typu Product, které jsou pˇredávány klientovi. Napˇríklad ProductA2 a ProductB2 jsou vytváˇreny pomocí ConcreteFactory2. Hlavním pˇrínosem tohoto vzoru je použití rozhraní pro ruzné ˚ objekty typu ConcreteFactory. Kód klienta múže být psán nezávisle na použití konkrétní instance. Pokud je potˇreba 18

3.1. NÁVRHOVÉ VZORY do aplikace pˇridat novou továrnu typu ConcreteFactory, staˇcí jednoduše implementovat zminované ˇ rozhraní. Mezi související vzory patˇrí Factory Method. Tˇrídy ConcreteFactory pˇredstavují implementaci tohoto vzoru - metody CreateProduct jsou tovární metody, které vytváˇrí konkrétní produkty. Tˇrídy ConcreteFactory bývají cˇ asto implementovány pomocí vzoru Singleton [5]. Abstract Factory se v praxi uplatnil napˇríklad v grafické knihovnˇe Java AWT5 . 3.1.4.3 Data Access Object Data Access Object (DAO) je jedním ze základních vzoru˚ pro platformu J2EE. Jeho smyslem je zavést rozhraní mezi zdrojem dat a jeho konzumenty a izolovat aplikaˇcní logiku pro získávaní dat do jedné vrstvy. V souˇcasné dobˇe existuje mnoho ruznorodých ˚ zdroju˚ dat, které aplikace používají. Jsou jimi napˇríklad relaˇcní databáze, objektové databáze, webové služby a mnohé další. Každý zdroj ale poskytuje data ruzným ˚ zpusobem ˚ (pomocí ruzných ˚ rozhraní). Relaˇcní databáze 6 7 pomocí jazyka SQL , webové služby pomocí XML souboru. ˚ Nejen bussiness komponenty (session beany, objekty aplikaˇcní logiky), ale i presentaˇcní komponenty (servlety, pomocné objekty pro JSP stránky), které potˇrebují pˇristupovat k datovému zdroji, by mohly používat konrétní rozhraní datového zdroje k dosažení konektivity pˇrímo a manipulovat s daty. Ale vznikla by tím pˇrí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ˇenil datový zdroj, musela by se zmˇenit i implementace všech komponent, které zdroj používají. ˇ Rešením, jak se tomuto problému vyhnout, je použít vzor DAO, který abstrahuje a zapouzdˇruje veškerý pˇrístup k datovému zdroji. DAO zajišt’uje spojení se zdrojem a umožnuje ˇ manipulaci s daty prostˇrednictví Data Access objektu. Schéma vzoru je na obrázku 3.3.

Obrázek 3.3: Vzor Data Access Object 5. 6. 7.

AWT je zkratka z anglického Abstract Window Toolkit. SQL je zkratka z anglického Structured Query Language. XML je zkratka z anglického Extensible Markup Language.

19

3.1. NÁVRHOVÉ VZORY Význam jednotlivých komponent je následující: •

BussinesObject - reprezentuje data klienta (aplikaˇcní logiku). Jde o objekt, který potˇrebuje pˇrístup k datovému zdroji, aby mohl získávat a ukládat data.

•

DataAccessObject - je klíˇcovým objektem tohoto vzoru. Abstrahuje implementaci pˇrístupu k datum ˚ a BussinessObject má tím pádem zajištˇen transparentní pˇrístup k datovému zdroji. BussinessObject deleguje naˇcítání a ukládání dat na tento objekt.

•

DataSource - reprezentuje implementaci datového zdroje. Datovým zdrojem muže ˚ být databáze, webová služba, systém souboru˚ nebo tˇreba adresáˇrová služba.

•

TransferObject - je objekt, který slouží jako nosiˇc dat. DataAccessObject používá tento objekt k pˇrenášení dat ke klientovi a zárovenˇ ho muže ˚ od klienta získat, aby zajistil aktualizaci dat v DataSource.

Použití vzoru DAO má následující dusledky: ˚ •

bussiness objekty mohou pˇristupovat k datovému zdroji, aniž by cokoliv vˇedˇely o jeho implementaˇcních detailech. Pˇrístup je transparentní, protože implementaˇcní detaily jsou skryty uvnitˇr DAO objektu.

•

vrstva DAO umožnuje ˇ aplikaci snadnou migraci na jinou databázovou implementaci. Bussiness objekty o databázové implementaci nic nevˇedí. To znamená, že migrace zahrnuje pouze zmˇenu DAO vrstvy.

•

snižuje složitost kódu v bussiness objektu, protože veškerý kód spojený s pˇrístupem ke konkrétní databázové implemementaci (napˇríklad SQL dotazy) jsou ukryty v DAO objektu. Zvyšuje to cˇ itelnost kódu a produktivitu vývoje.

•

centralizuje veškerý pˇrístup k datum ˚ do jedné vrstvy, což vede ke snadnˇejší spravovatelnosti a udržovatelnosti aplikace.

•

DAO pˇridává další vrstvu mezi klienta a datový zdroj, která musí být navržena a následnˇe implementována tak, aby využila pˇredností tohoto vzoru. Avšak pˇrínosy v dusledku ˚ použití tohoto pˇrístupu ve vˇetšinˇe pˇrípadu˚ vynahradí úsilí, které je potˇreba vynaložit pˇri návrhu a implementaci této vrstvy.

Mezi související vzory patˇrí zejména vzor Transfer Object [6], který DAO využívá k pˇrenosu dat z/ke klientovi. 3.1.4.4 DAO Factory Vzor Data Access Object muže ˚ být rozšíˇren zaˇclenˇením vzoru˚ Factory Method a Abstract Factory, které byly zmínˇeny v kapitolách 3.1.4.1 a 3.1.4.2, cˇ ímž vznikne DAO Factory (továrna pro DAO). 20

3.1. NÁVRHOVÉ VZORY Pokud se datové úložištˇe nemˇení z jedné implementace na druhou, lze využít vzor Factory Method, který nám zajistí vytvoˇrení potˇrebného množství DAO objektu˚ 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ˇrípadˇe, že se datové úložištˇe muže ˚ mˇenit, je vhodné využít vzor Abstract Factory. Tato strategie poskytuje abstraktní tovární DAO objekt, ze kterého jsou vytváˇreny ruzné ˚ typy konkrétních DAO továren a každá z nich podporuje jiný typ datového úložištˇe. Po získání objektu konkrétní DAO továrny lze vytváˇret 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

ˇ 3.2. NÁVRHOVÝ MODEL T RÍD Dusledky, ˚ které pˇrináší 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ˇejší hierarchie tˇríd a tím pádem i celkové složitosti kódu. Proto je vhodné pˇri návrhu nejprve využít rˇ ešení s Factory Method vzorem a pak teprve, v pˇrípadˇe že je to nutné, použít rˇ ešení se vzorem Abstract Factory.

3.2

Návrhový model tˇríd

Návrhový model tˇríd rozšiˇruje analytický model o implementaˇcní tˇrídy. Zatímco analytický model by mˇel být co nejjednodušší, návrhový model by mˇel být již dostateˇcnˇe složitý a obsahovat všechny potˇrebné detaily, aby bylo možné jej snadno implementovat. Z obrázku 3.6 na následující stranˇe je vidˇet, že návrhový diagram tˇríd modelovaného systému využívá vzor DAO, který zabezpeˇcuje pˇrístup objektu˚ z aplikaˇcní vrstvy k perzistentní vrstvˇe aplikace. SpravceUzivatelu je aplikaˇcní objekt, který má za úkol správu všech uživatelu˚ systému. Pomocí DAO objektu˚ ZamestnanecDAO a ZakaznikDAO pˇristupuje k veškerým datum ˚ o zamˇestnancích a zákaznících, jež jsou reprezentovány objekty Zamestnanec, Adresa, Zakaznik a Role. Podobnˇe je tomu u modelované cˇ ásti s objednávkami. SpravceObjednavek je aplikaˇcní objekt, který prostˇrednictvím DAO objektu ObjednavkaDAO pˇristupuje a manipuluje s daty o objednávkách v podobˇe objektu˚ Objednavka, PolozkaObjednavky a Produkt. Stejný princip je použit u dalších cˇ ástí systému, které mají zajišt’ovat pˇrístup k datum. ˚ Vzhledem k tomu, že návrhový diagram tˇríd celého systému je znaˇcnˇe rozsáhlý a na formát A4 v podstatˇe není možné jej rozumnˇe zobrazit, je kompletní model systému uveden pouze na CD, které je pˇriloženo k této práci.

22

ˇ 3.2. NÁVRHOVÝ MODEL T RÍD

ˇ Obrázek 3.6: Cást návrhového modelu s využítím vzoru Data Access Object

23

Kapitola 4

Implementace Tato kapitola se zabývá implementací systému Ashop. Úvodní cˇ ást se vˇenuje architektonickým vzorum. ˚ Následuje pˇrehled použitých technologií s konkrétními ukázkami jejich využití pˇri implementaci. Podobnˇe jako v pˇredchozích kapitolách, i zde jsou popisované technologie dány do souvislosti se softwarovými vzory.

4.1

Architektonické vzory

4.1.1

Co jsou to architektonické vzory

Architektonické vzory stojí z dosud zmínˇených vzoru˚ (analytické a návrhové) na nejvyšší úrovni. Vyjadˇrují základní strukturální organizaˇcní schémata pro softwarové systémy. Poskytují nˇekolik pˇreddefinovanýh subsystému, ˚ specifikují jejich odpovˇednosti a obsahují pravidla a pokyny pro organizování vztahu˚ mezi nimi. Následující rozdˇelení vzoru˚ do cˇ tyˇr 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 POSA1 , 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 objektu. ˚ Podporují dekompozici hlavních úloh systému˚ na spolupracující dílˇcí podúlohy. Mezi tyto vzory patˇrí: Layers, Pipes and Filters a Blackboard.

•

Distributed Systems Do této kategorie patˇrí 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í rˇ ešení distribuce jako svuj ˚ druhotný úkol a jsou proto uvedeny v jiné kategorii.

•

Interactive Systems Tato kategorie zahrnuje dva vzory: Model-View-Controller a Presentation-AbstractionControl. Obecnˇe oba vzory podporují strukturování softwarových systému, ˚ jež se zabývají interakcí cˇ lovˇeka s poˇcítaˇci.

1.

POSA je zkratka z anglického Pattern-Oriented Software Architecture.

24

4.1. ARCHITEKTONICKÉ VZORY •

Adaptable Systems Do této kategorie patˇrí vzory Reflection a Microkernel. Jejich cílem je umožnit rozšiˇrování aplikací a jejich pˇrizpusobení ˚ se na nové technologie a mˇenící se funkˇcní požadavky.

Vzhledem k tomu, že na vzoru Model-View-Controller je založena jedna z technologií použitých pˇri implementaci systému, konkrétnˇe aplikaˇcní rámec Spring (viz kapitola 4.2.2), bude detailnˇeji popsán právˇe ten, ostatní vzory budou pˇredstaveny pouze na pˇríkladu jejich možného použití v praxi. 4.1.2

Model-View-Controller

Architektura MVC (Model-View-Controller) se stává cˇ ím dál více populární. Dukazem ˚ toho je množství MVC frameworku, ˚ které v posledních letech vznikly nebo se neustále objevují jejich nové verze. Pˇríkladem budiž APS.NET MVC, Zend Framework, Spring MVC a mnoho dalších. Cílem MVC je rozdˇelit interaktivní aplikace na 3 logické komponenty - Model, View a Controller tak, aby je šlo samostatnˇe upravovat a dopad zmˇen na ostatní byl co nejmenší. Model reprezentuje data a bussines logiku aplikace, View pˇredstavuje uživatelské rozhraní a Controller má na starosti tok událostí v aplikaci (ˇrídící logiku). Jednotlivé cˇ ásti si lze názornˇe pˇredstavit pomocí následujícího pˇríkladu tabulek a grafu˚ na obrázku 4.1.

Obrázek 4.1: Modelový pˇríklad MVC Model je datová struktura uchovávající cˇ ísla 35, 42, 58 a 37, která muže ˚ být v aplikaci realizována jako pole cˇ ísel nebo tˇrída. Pˇríklad obsahuje i údaj o prumˇ ˚ erném pˇríjmu, jehož výpoˇcet také patˇrí do modelu. View (pohled) je v pˇríkladu zastoupen hned nˇekolikrát. Je patrné, že jej reprezentuje koláˇcový a sloupcový graf. Ale také tabulka s daty je dalším pohledem, jemuž lze nastavit 25

4.1. ARCHITEKTONICKÉ VZORY napˇríklad ruzný ˚ formát zobrazování cˇ ísel (barva, velikost, mˇena, . . . ). View tedy pˇredstavuje zobrazení modelu a dalších prvku˚ uživatelského rozhraní. Controller (kontroler) není na uvedeném pˇríkladu vidˇet. Projeví se ve chvíli, kdy uživatel zmˇení obsah nˇekteré z bunˇek. V ten okamžik má kontroler za úkol aktualizovat model tak, aby došlo k výpoˇctu nového prumˇ ˚ eru a pˇrekreslily se všechny pohledy. Jakým zpuso˚ bem se zmˇeny v modelu projeví v pohledech však nemusí souviset s kontrolerem, ten pouze celý proces spouští. Obecné schéma MVC vzoru vyjadˇruje obrázek 4.2.

Obrázek 4.2: Schéma MVC Tok údálostí v MVC vypadá následnovˇe: 1 Uživatel provede nˇejakou akci v uživatelském rozhraní. 2 Akci zachytí Controller. 3 Controller rozhodne, jak na ni zareagovat a cˇ asto zmˇení data v Modelu nebo pˇrímo ovlivní View. 4 View zobrazí zmˇeny uživateli. Tento prubˇ ˚ eh se v podstatˇe neustále opakuje. Na schématu je navíc vidˇet 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ˇcastˇeji využíván ve webových technologiích. Z pohledu tˇrívrstvého modelu se lze setkat s dvˇema pˇrístupy k webovým aplikacím. První z nich bere webový prohlížeˇc pouze jako zobrazovací zaˇrízení a veškeré uživatelské rozhraní (HTML2 ) se generuje na serveru. Druhý pˇrístup využívající technologie AJAX3 naopak spoléhá na pˇrítomnost JavaScriptu ve webovém prohlížeˇci a podstatnou cˇ ást prezentaˇcní logiky tak pˇresouvá na stranu klienta. Zejména díky použitým technologiím je tedy patrný pomˇernˇe znaˇcný rozdíl. 2. 3.

HTML je zkratka z anglického HyperText Markup Language. AJAX je zkratka z anglického Asynchronous JavaScript and XML.

26

4.1. ARCHITEKTONICKÉ VZORY Serverové MVC musí využívat technologie, jako napˇríklad Spring MVC (viz. kapitola 4.2.2) cˇ i ASP.NET MVC, zatímco klientské MVC je realizováno pomocí JavaScriptu. V souˇcasné dobˇe se lze setkat s kombinací obou zmínˇených pˇrístupu˚ - AJAX doplnuje ˇ klasický model serverové aplikace. V tomto pˇrípadˇe je prezentaˇcní vrstva realizována jak na serveru, tak na klientovi. Avšak stále nejˇcastˇeji používaným rˇ ešením je využití MVC na serveru, protože kompletnˇe AJAXových aplikací je zatím velmi málo a ty jež ho využívají jen cˇ ásteˇcnˇe zase neobsahují tak komplikovanou logiku, aby mˇelo smysl MVC využít. Z hlediska serverové implementace jednotlivé komponenty vypadají následovnˇe. Model pˇredstavuje nejjednodušší cˇ á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átu, ˚ jako napˇríklad XML cˇ i JSON4 . Controller je v prostˇredí webu vˇetšinou tvoˇren dvˇema cˇ ástmi. První je tzv. Front Controller, který zachytává veškeré HTTP požadavky. Ty zpracuje a pˇrepošle konkrétním kontrolerum ˚ (tvoˇrí druhou cˇ ást), jež mají na starosti pouze urˇcité specifické úkoly. Konkrétní kontroler muže ˚ napˇríklad pˇrijmout formuláˇrová data puvodnˇ ˚ e 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ˇríklad v technologiích JavaFX nebo Silverlight. Model zustává ˚ stejný jako u MVC. View navíc zpracovává uživatelský vstup tím, že ho deleguje na Presenter (napˇríklad jako reakci na kliknutí myši vyvolá nˇejakou jeho metodu). Presenter obsahuje jak aplikaˇcní, tak prezentaˇcní logiku. Manipuluje s modelem a pˇrímo nebo nepˇrímo (pomocí notifikací) ovlivnuje ˇ View. 4.1.3

Další vzory

Layers - tento vzor pomáhá strukturovat aplikace, které mohou být rozdˇeleny do skupin podúloh a každá z tˇechto skupin je na urˇcité úrovni abstrakce. Typickým pˇríkladem jeho použití je referenˇcní komunikaˇcní ISO/OSI model, jenž rozdˇeluje komunikaci mezi poˇcítaˇci do sedmi souvisejících vrstev. Každá vrstva vykonává skupinu jasnˇe definovaných funkcí potˇrebných pro komunikaci. Pro svoji cˇ innost využívá služby své sousední nižší vrstvy a své služby naopak poskytuje sousední vyšší vrstvˇe. Pipes and Filtres - poskytuje strukturu pro systémy, které zpracovávají nˇejaké datové toky. Každý krok zpracování je zapouzdˇren v komponentˇe Filter (filtr). Data jsou pˇredávána prostˇrednictvím Pipes (potrubí) mezi sousedními filtry. Pomocí ruzných ˚ kombinací filtru˚ je možné vytváˇret rodiny souvisejících systému. ˚ Tento vzor lze v praxi ukázat napˇríklad na kompilátoru. Na jeho vstupu jsou data ve formˇe zdrojového kódu, která jsou postupnˇe zpracovávána pomocí filtru, ˚ které pˇredstavují - lexikální analyzátor, syntaktický analyzátor, sémantický analyzátor, pˇrekladaˇc do mezikódu, optimalizátor mezikódu a generátor kódu. Blackboard - vzor je užiteˇcný na rˇ ešení problému, ˚ pro nˇež neexistují deterministické strategie. Funguje na principu shromažd’ování znalostí z jednotlivých subsystému, ˚ na je4.

JSON je zkratka z anglického JavaScript Object Notation.

27

4.2. TECHNOLOGIE jichž základˇe je možné vytvoˇrít cˇ ásteˇcné nebo pˇribližné rˇ ešení. Použití vzoru lze ukázat napˇríklad na systému rozpoznávání reˇci. Jeho vstupem je rˇ eˇc zaznamenaná jako akustický signál. Systém pˇrijímá nejen jednotlivá slova, ale také celé vˇety, jež jsou omezeny syntaxí a slovní zásobou pro konrétní aplikace (napˇr. 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ˇríklad jedna cˇ ást (subsystém) provádí rozdˇelení vstupu na jednotlivá písmena, jiná cˇ ást provádí kontrolu syntaxe potencionálních frází. Obˇe tyto cˇ á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ˇrizpusobit ˚ se mˇenícím požadavkum ˚ systému. Oddˇeluje minimální funkˇcní jádro od rozširˇ ující funkcionality a specifických aplikací uživatelu. ˚ Slouží také jako soket pro zapojování ruzných ˚ rozšíˇrení a jejich spolupráci. Pˇríkladem implementace tohoto vzoru muže ˚ být napˇríklad architektura operaˇcního systému pro mobilní zaˇrízení Symbian OS.

4.2

Technologie

Cílem této kapitoly není podat vyˇcerpá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í cˇ ásti, vysvˇetlit duvody ˚ jejich použití a dát je do souvislosti se softwarovými vzory. 4.2.1

Hibernate

4.2.1.1 Úvod do problematiky Propojení objektovˇe orientované aplikace a relaˇcní databáze muže ˚ být pˇri vývoji informaˇcního systému pomˇernˇe obtížné a zabrat mnoho cˇ asu. Duvodem ˚ je odlišnost mezi zpusobem ˚ reprezentace dat v objektech a relaˇcních datázích. Rozdíl ilustruje následující pˇríklad. Mˇejme záznam v adresáˇri, který reprezentuje osobu s jedním nebo více telefonními cˇ ísly a jednou cˇ i více adresami. V objektovˇe orientované implementaci bude osoba reprezentována jako objekt Person, který v sobˇe bude uchovávat jméno, seznam telefonních cˇ ísel a seznam adres. Seznam telefonních cˇ ísel bude obsahovat cˇ í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ˇríklad muže ˚ být odkazován pomocí jednoduché promˇenné). Naproti tomu relaˇcní databáze mohou pracovat pouze se skalárními hodnotami (ˇcísla, rˇ etˇezce znaku, ˚ . . . ) organizovaných do relací (tabulek). Pokud tedy programátor chce ukládat objekty do relaˇcních databází, musí je nejprve pˇrevést na skupinu jednodušších hodnot (pˇri naˇcítání z databáze je pˇrevést zpˇet 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ˇredí Java (v souˇcasnosti i .Net), který tento problém rˇ eší pomocí tzv. objektovˇe-relaˇcního mapování (ORM). Jedná se o techniku mapování dat z objektového modelu na relaˇcní model a obrácenˇe. Hibernate se však nestará 28

4.2. TECHNOLOGIE pouze o mapování Java tˇríd na databázové tabulky a mapování datových typu˚ Javy na SQL datové typy, ale poskytuje také nástroje pro dotazování a vyhledávání dat. Hlavním pˇrínosem tohoto frameworku je, že zjednodušuje a ulehˇcuje práci vývojáˇrum, ˚ 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 3.66 . 4.2.1.2 Objektovˇe relaˇcní mapování Jak již bylo zmínˇeno, objektovˇe-relaˇcní mapování je programovací technika, která zajišt’uje konverzi dat (perzistentních tˇríd) mezi objektovým a relaˇcním modelem. Aplikace tak muže ˚ naˇcítat a ukládat data do relaˇcní databáze, ale na aplikaˇcní úrovni pracovat s objektovým modelem dat. Perzistentní tˇrída je obyˇcejná javová tˇrí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ˇrevádˇet data mezi objektovým a relaˇcním formátem, je nutné nakonfigurovat, jak se budou objekty transformovat (mapovat) na tabulky v databázi. To lze provést dvˇema zpusoby, ˚ bud’ pomocí mapovacích souboru, ˚ anebo anotací. Mapovací soubory - jedná se o soubory ve formátu XML, které mají pˇríponu „hbm.xml“. Pro jednu tˇrídu se vˇetšinou používá jeden mapovací soubor, ale není to podmínkou. Veškerá konfigurace se provádí pomocí tagu˚ a jejich atributu. ˚ Následující ukázka pˇredstavuje cˇ ást mapovacího souboru pro perzistentní tˇrídy z vyvíjeného systému, konkrétnˇe pro tˇríduUser a Customer. <property name="username" column="USERNAME" not-null="true" length="30"/> <property name="password" column="PASSWORD" not-null="true" length="30"/> <property name="email" column="EMAIL" not-null="true" lenght="50"/> <set name="authorities" table="USER_AUTHORITY" lazy="false"> <many-to-many column="AUTHORITY_ID" class="Authority"/> 5. 6.

JDBC je zkratka z anglického Java Database Connectivity. Dokumentaci lze nalézt na .

29

4.2. TECHNOLOGIE <joined-subclass name="Customer" table="CUSTOMERS"> <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"/>

Význam mapování je následující. Tˇrída User se bude ukládat do databázové tabulky USERS. Atribut id bude primárním klíˇcem a zpusob ˚ jeho generování je ponechán na konkrétní databázové implementaci. U atributu˚ username, password a email 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 objektu˚ typu Authority. Jelikož je vztah mezi objekty User a Authority M:N, tedy uživatel muže ˚ mít nˇekolik autorit a každá autorita muže ˚ být svázána s nˇekolika uživately, musí být tato vazba mapována do další tabulky, v tomto pˇrípadˇe USER_AUTHORITY. Dále je uvedeno mapování tˇrídy Customer, která rozšiˇruje tˇrídu User. Bude mapována na samostatnou tabulku CUSTOMERS s cizím klíˇcem ID. Následuje opˇet mapování atributu˚ na konkrétní sloupce tabulky, u IC a DIC je uvedeno omezení na délku sloupce. Anotace - pˇredstavují metadata, která lze pˇridávat k jednotlivým elementum ˚ kódu (tˇrída, metoda, promˇenná). Anotacemi je možné nahradit zminovaný ˇ mapovací soubor a mít tak konfiguraci dostupnou pˇrímo v kódu tˇrídy. V pˇrípadˇe mapování je lze použít dvˇema zpu˚ soby, bud’ u atributu, ˚ anebo jejich get method. Následující ukázka pˇredstavuje opˇet mapování tˇrídy User, tentokrát pomocí anotací. @Entity(name="USERS") @Inheritance(strategy=InheritanceType.JOINED) public class User implements Serializable { @Id @Column(name="ID") @GeneratedValue(strategy=GenerationType.AUTO) private long id; @Column(name="USERNAME", nullable=false, length=30) private String username; @Column(name="PASSWORD", nullable=false, length=30) private String password; @Column(name="EMAIL", nullable=false) private String email;

30

4.2. TECHNOLOGIE @ManyToMany @JoinTable(name="USER_AUTHORITY", joinColumns=@JoinColumn(name="USER_ID"), inverseJoinColumns=@JoinColumn(name="AUTHORITY_ID")) private Set authorities; public User() {} }

Obecnˇe lze rˇ íci, že výhodou použití ORM je pˇredevším pˇrenositelnost aplikace mezi ruz˚ nými databázovými systémy, typová kontrola již bˇehem pˇrekladu aplikace, zjednodušení implementace a také snadnˇejší testování. Za nevýhodu lze oznaˇcit potencionálnˇe menší výkon aplikace, nebot’ každý ORM nástroj má jistou režii, avšak konkrétnˇe Hibernate klade na tuto oblast velký duraz. ˚ 4.2.1.3 HQL Hibernate Query Language (HQL) je dotazovací jazyk, který je svoji syntaxí velmi podobný SQL. Narozdíl od nˇej je však plnˇe objektový a pracuje s vlastnostmi jako dˇediˇcnost cˇ i polymorfismus. S výjimkou názvu˚ tˇríd a jejich atributu˚ nejsou dotazy case-sensitivní. HQL podporuje klasické konstrukce, které jsou známé z jazyka SQL - vnitˇrní a vnˇejší spojení (join), agregaˇcní funkce, subdotazy, atd. Výsledek dotazu muže ˚ být vrácen jako atribut, objekt, kolekce nebo pole objektu. ˚ Pokud bychom chtˇeli získat napˇríklad objekty uživatelu, ˚ jejichž pˇrihlašovací jméno zaˇcí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živatelu˚ s požadovaným pˇrihlaš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ˇrejmˇe umožnuje ˇ zadávat dotazy i prostˇrednictvím jazyka SQL, avšak tento pˇrístup má podstatnou nevýhodu, jíž je ztráta pˇrenositelnosti mezi jednotlivými databázovými implementacemi, nebot’ každá vˇetšinou používá nˇejaký svuj ˚ SQL dialekt. 4.2.2

Spring Framework

Spring Framework7 je open source aplikaˇcní rámec pro vývoj aplikací na platformˇe Java. Muže ˚ být použit jako alternativa k Java EE8 . Sám pokrývá v podstatˇe všechny vrstvy bežné 7. 8.

Dokumentaci lze nalézt na . J2EE je zkratka z anglického Java Platform, Enterprise Edition.

31

4.2. TECHNOLOGIE enterprise aplikace (databázová, aplikaˇcní, prezentaˇcní), je však bˇežné, že je integrován spolu s dalšími frameworky usnadnujícími ˇ vývoj. Jádro Springu je založeno na návrhovém vzoru Inversion of Control (IoC), který umožnuje ˇ pˇrenést zodpovˇednost za vytváˇrení a provázání objektu˚ z aplikace na framework (jádro bývá oznaˇcováno jako IoC kontejner). Pˇri programování je bˇežné, že jednotlivé tˇrídy systému jsou vzájemnˇe propojené (jedna tˇrída využívá další tˇrídy, atd.). Tím pádem je mezi nimi velmi pevná vazba a pokud je potˇreba vymˇenit jednu tˇrídu za druhou, vyžaduje to zásah do zdrojového kódu. IoC umožnuje ˇ tuto vazbu uvolnit tím, že tˇrída nevytváˇrí instance dalších potˇrebných tˇríd sama, ale jsou jí dodány z vnˇejšku pomocí tzv. Dependency Injection (vkládání závislostí). Mezi nejpoužívanˇejší zpusoby ˚ patˇrí: •

Constructor Injection - injektování pomocí konstruktoru. Tˇrída, do níž je vkládána instance další tˇrídy musí mít konstruktor s parametrem typu vkládané tˇrídy.

•

Interface Injection - injektování prostˇrednictvím rozhraní. Rozhraní definuje metody, které slouží k nastavování ruzných ˚ instancí tˇríd. Aby tˇrída mohla tyto instance využívat, musí implementovat dané rozhraní.

•

Setter Injection - injektování pomocí setteru. ˚ Tˇrída, do níž jsou vkládány instance dalších tˇríd, musí mít implementovány potˇrebné set metody. Právˇe tento pˇrístup využívá Spring.

Objekty, které muže ˚ vytváˇret IoC kontejner na základˇe jejich definic v XML souborech cˇ 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ˇren zhruba 20 moduly, které jsou uspoˇrá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ˇreba využívat vždy celý rámec, ale pouze konkrétní modul, který se hodí na rˇ ešení daného problému. Následující cˇ ásti byly použity pˇri implementaci systému: •

Core a Beans - poskytují základní funkcionalitu frameworku, vˇcetnˇe IoC a Dependency Injection. Duležitou ˚ souˇcástí jsou BeanFactory, které slouží k vytváˇrení, konfiguraci a spravování zminovaných ˇ beans. Jejich implementace je založena na návrhovém vzoru Abstract Factory (viz kapitola 3.1.4.2).

•

Context - dˇedí vlastnosti od modulu Beans a pˇridává podporu pro internacionalizaci, propagaci událostí, nahrávání zdroju, ˚ vytváˇrení kontextu (napˇríklad servletovým kontejnerem) atd. Též podporuje nˇekteré Java EE technologie, jako EJB9 , JMX10 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

4.2. TECHNOLOGIE •

Expression Language - poskytuje jazyk pro dotazování a manipulaci s objekty. Jedná se o rozšíˇrení jazyka Unified Expression Language, jež se používá v prostˇredí technologií JSP a JSF. Podporuje práci s promˇennými, volání metod, práci s poli a kolekcemi, logické a aritmetické operátory, získávání objektu˚ podle jména z IoC kontejneru a mnohé další.

•

ORM - poskytuje integraˇcní vrstvu pro API zajišt’ující objektovˇe-relaˇcní mapování, napˇríklad Hibernate, JPA, iBatis a další.

•

Web - poskytuje základní webovˇe orientované funkce a vlastnosti, jako nahrávání souboru, ˚ inicializaci IoC kontejneru pomocí servlet listeneru, ˚ webovˇe orientovaný aplikaˇcní kontext, podporu pro vzdálené volání v prostˇredí webu.

•

Web Servlet (MVC) - obsahuje implementaci vzoru MVC (viz kapitola 4.1.2) pro webové aplikace, což umožnuje ˇ napˇríklad oddˇelit kód doménového modelu a webových formuláˇru˚ a zárovenˇ jednoduše spolupracovat s dalšími cˇ ástmi frameworku.

Obrázek 4.3: Struktura rámce Spring [8] Jako vhodná ukázka aplikaˇcní logiky pomocí rámce Spring poslouží kontroler pro zpracování údaju˚ z registraˇcního formuláˇre. 33

4.2. TECHNOLOGIE @Controller @RequestMapping("/customer/new") @SessionAttributes(types = Customer.class) public class RegistrForm { @Autowired private UserManager userManager; @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { dataBinder.setDisallowedFields("id"); } @RequestMapping(method = RequestMethod.GET) public String setupForm(Model model) { Customer customer = new Customer(); model.addAttribute(customer); return "/customer/form"; } @RequestMapping(method = RequestMethod.POST) public String processSubmit(@ModelAttribute Customer customer, BindingResult result, SessionStatus status) { new CustomerValidator().validate(customer, result); if (result.hasErrors()) { return "customer/form"; } else { userManager.saveNewRegistratedCustomer(customer); status.setComplete(); return "redirect:/customer/account"; } } }

Vˇetšina konfigurace je provádˇena pomocí anotací. Do kontroleru je injektován bussines objekt (viz vzor DAO 3.3) userManager, který slouží k manipulaci s daty uživatele. Metoda setupForm() má na starosti svázání objektu nového zákazníka s modelem a vybrání vhodného view, jenž zobrazí registraˇcní formuláˇr. Pomocí metody setAllowedFields() je zakázáno injektování hodnoty atributu id, nebot’ ten je generován automaticky databází. Pˇrestože se tento atribut ve formuláˇri nevyskytuje, mohl by být odeslán, pokud by uživatel provedl neoprávnˇené zmˇeny formuláˇrové stránky nebo webového požadavku. Jedná se tedy o bezpeˇcnostní ochranu. Metoda processSubmit() zajišt’uje zpracování dat odeslaných 34

4.2. TECHNOLOGIE z formuláˇre. Nejprve jsou zkontrolována pomocí validátoru. Pokud jsou v poˇrádku, prostˇrednictvím bussines objektu jsou uložena a uživatel je pˇresmˇerován na view zobrazující jeho uživatelský úˇcet. V opaˇcném pˇrípadˇe je uživateli zobrazeno opˇet view s formuláˇrem, v nˇemž jsou oznaˇcena chybnˇe zadaná data. 4.2.3

Spring Security

Spring Security11 je rámec, který poskytuje autentizaˇcní, autorizaˇcní a další bezpeˇcnostní prostˇredky pro enterprise aplikace. Projekt vznikl v roce 2003 puvodnˇ ˚ e pod názvem Acegi Security. O necelý rok pozdˇeji byl zaˇclenˇen mezi oficiální Spring projekty a v roce 2008 byla uvolnˇena jeho první verze pod názvem Spring Security. Aktuální dostupná verze je 3.0. Spring Security poskytuje své služby jak na úrovni webových požadavku, ˚ tak na úrovni volání jednotlivých metod. Lze jej použít nejen ve spojení s dalšími frameworky z rodiny Spring, ale také s mnoha dalšími aplikaˇcními rámci a technologiemi, napˇríklad AspectJ, OpenID, Jasypt, Jcaptcha cˇ i Grails. Stejnˇe jako Spring Framework využívá Dependency Injection. Zabezpeˇcení systému Ashop je z hlediska tohoto frameworku zajištˇena pomocí následujících prvku: ˚ autentizace (ovˇerˇ ení identity), autorizace pˇri volání metod a autorizace pˇri pˇrístupu k webové URL12 . Autentizace uživatelu˚ je provádˇena pomocí bˇežného formuláˇre pro zadání uživatelského jména a hesla. Pˇrihlašovací údaje jsou ovˇerˇ eny vuˇ ˚ ci záznamu v databázi a pokud se shodují, je uživatel autentizován. Následnˇe je tˇreba zajistit autorizaci, tzn. ovˇerˇ it, že autentizovaný uživatel má potˇrebná oprávnˇení pro provedení urˇcité cˇ innosti v systému. Prvním zpusobem ˚ je využití autorizace pˇri volání metod. Definuje se pomocí anotací pˇrímo ve zdrojovém kódu. @PreAuthorize("hasRole(’ROLE_SUPERVISOR’)") void changeSystemSettings(Setting setting) throws DataAccessException;

Pˇri volání metody je ovˇerˇ eno, zda má uživatel pˇridˇelenu pˇríslušnou roli. Pokud ano, metoda se normálnˇe vykoná, v opaˇcném pˇrípadˇe vyhodí výjimku DataAccessException. Druhý zpusob ˚ je autorizace pˇri pˇrístupu ke konkrétní webové adrese. Využívá se v pˇrípadˇe, že je systém rozdˇelen na více cˇ ásti z hlediska úrovní oprávnˇení (napˇríklad cˇ ást systému je veˇrejná, cˇ ást slouží pro jeho administraci). Pˇrístup k jednotlivým adresám se uvádí v konfiguraˇcním XML souboru. 11. Dokumentaci lze nalézt na adrese . 12. URL je zkratka z anglického Uniform Resource Locator.

35

4.2. TECHNOLOGIE V tomto pˇrípadˇe se uplatnují ˇ pravidla, která rˇ íkají, že k celému systému má pˇrístup pouze uživatel s rolí ROLE_USER. Zárovenˇ k cˇ ásti systému, která je mapována na adresu /security má pˇrístup pouze uživatel s rolí ROLE_SUPERVISOR. Existuje ještˇe další možnost - autorizace na úrovni cˇ ásti webové stránky s využitím knihovny Spring Security JPS Tag Library. Lze ji využít v pˇrípadˇe, že chceme na webové stránce zobrazit její urˇcitou cˇ ást pouze v pˇrípadˇe, že má uživatel jistá oprávnˇení. Omezení se zapisují pomocí tagu˚ pˇrímo do JSP stránky. <sec:authorize access="hasRole(’ROLE_LOGIN_USER’)"> <spring:url value="/customer/{userId}/account" var="accountUrl"> <spring:param name="userId" value="${user.id}"/> M˚ uj úˇ cet

Uvedený kód JSP stránky zajistí, že odkaz na nastavení uživatelského úˇctu se uživateli zobrazí jen v pˇrípadˇe, že má pˇridˇelenu roli ROLE_LOGIN_USER, která pˇredstavuje autentizovaného uživatele. 4.2.4

TecDoc

4.2.4.1 Co je to TecDoc? TecDoc13 je spoleˇcnost založená v roce 1994 nˇemeckou asociací pro náhradní díly (GVA) a obchodními spoleˇcnostmi na trhu s autopˇríslušenstvím. TecDoc poskytuje data pro identifikaci a objednávání náhradních dílu. ˚ Jejím hlavním úkolem je standardizace, sbˇer a distribuce dat a také rozvoj technologií pro jejich zpracování. TecDoc v podstatˇe funguje jako prostˇredník mezi výrobci automobilu˚ a náhradních dílu˚ a jejich prodejci, který spravuje a poskytuje data. Vzhledem k tomu, že se jedná o obchodní spoleˇcnost, jsou tyto služby placené. To znamená, že pokud výrobce chce, aby data o jeho produktech byla v databázi TecDoc, musí za to zaplatit. Stejnˇe tak je tomu i na stranˇe prodejce, pokud chce data využívat. V souˇcasné dobˇe databáze TecDoc obsahuje pˇres 41 tisíc dopravních prostˇredku, ˚ k nimž je navázáno 2.7 milionu˚ produktu˚ zhruba 400 znaˇcek a výrobcu. ˚ Její data jsou dostupná v 28 jazycích. Z hlediska rozsahu je to celosvˇetovˇe unikátní databáze. Aˇckoliv se na první pohled mohou zdát zminovaná ˇ cˇ ísla obrovská, tak TecDoc neobsahuje zdaleka všechny produkty dostupné na trhu s náhradními díly. To má dopad pˇredevším na jejich prodejce, kteˇrí jsou tím pádem nuceni využívat další zdroje dat (katalogy) v ruzných ˚ formátech. Data z TecDocu jsou dostupná dvˇema zpusoby. ˚ Prvním je online distribuce prostˇrednictvím webové služby TecDoc Web Service. Právˇe ta je využita pˇri implementaci systému 13. Celý název je spoleˇcnosti jeTecDoc Information System GmbH.

36

4.2. TECHNOLOGIE Ashop. Druhý zpusob ˚ je offline distribuce v tzv. TecDoc Export Format. Data jsou distribuována prostˇrednictvím datových médií (CD, DVD) cˇ tyˇrikrát roˇcnˇe. Nevýhodou je, že si uživatel musí data ruˇcnˇe aktualizovat, zatímco webová služba poskytuje data automaticky aktualizovaná. 4.2.4.2 TecDoc Web Service Webová služba je softwarový systém navržený k podpoˇre efektivní interakce (vzdálené volání procedur) dvou stroju˚ na síti pomocí pˇrenosu zpráv v jazyce XML. Je popsána (její rozhraní) ve strojovˇe zpracovatelném formátu pomocí jazyka WSDL14 . Komunikace mezi webovou službou a ostatními stroji probíhá pomocí zpráv protokolu SOAP15 , které jsou pˇrenášeny vˇetšinou prostˇrednictvím zavedených protokolu˚ (HTTP, SMTP, . . . ). Duvod ˚ jejich použití je ten, že vˇetšina firewallu˚ tˇemto protokolum ˚ duvˇ ˚ erˇ uje, zprávy nijak neblokuje a opravdu se dostanou ke svému pˇríjemci [10]. Jazyk WSDL slouží pro popis rozhraní webové služby. Popisuje názvy dostupných metod, typy jejich parametru˚ a návratových hodnot, na jaké adrese je služba dostupná a pomocí jakých protokolu. ˚ Existují cˇ tyˇri styly WSDL: RPC/encoded, RPC/literal, document/literal a wrapped document/literal. V souˇcasné dobˇe je nejˇcastˇeji používán poslednˇe jmenovaný styl wrapped document/literal, nebot’ umožnuje ˇ validovat XML pˇrímo z definice typu˚ ve WSDL. Následující kód pˇredstavuje cˇ ást WSDL dokumentu, který popisuje webovou službu TecDoc. Konkrétnˇe se jedná o popis funkce getVehicleModels3(), která slouží k vyhledání všech modelu˚ daného automobilu. První cˇ ást obsahuje definici typu, ˚ druhá komunikaˇcní zprávy a poslední definuje dostupné operace. <wsdl:definitions targetNamespace="http://webservicepilot.tecdoc.net/pegasus-2-0/ services/TecdocToCatWL" xmlns:tns5="http://carselection.datatype.tocinterface.cat.tecdoc.net" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> <schema elementFormDefault="qualified" targetNamespace="http://webservicepilot.tecdoc.net/pegasus-2-0/ services/TecdocToCatWL" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="getVehicleModels3"> <sequence> <element name="in0" type="tns5:VehicleModels3Request"/> 14. WSDL je zkratka z anglického Web Services Description Language. 15. SOAP je zkratka z anglického Simple Object Access Protocol.

37

4.2. TECHNOLOGIE <element name="getVehicleModels3Response"> <sequence> <element name="getVehicleModels3Return" type="tns5:VehicleModels3Response"/> <wsdl:message name="getVehicleModels3Request"> <wsdl:part element="impl:getVehicleModels3" name="parameters"/> <wsdl:message name="getVehicleModels3Response"> <wsdl:part element="impl:getVehicleModels3Response" name="parameters"/> <wsdl:portType name="TecdocToCat"> <wsdl:operation name="getVehicleModels3"> <wsdl:input message="impl:getVehicleModels3Request" name="getVehicleModels3Request"/> <wsdl:output message="impl:getVehicleModels3Response" name="getVehicleModels3Response"/>

Webová služba TecDoc poskytuje zhruba 100 metod (funkcí), které slouží pˇredevším k následujícím úˇcelum: ˚ •

konfigurace a pˇripojení k webové službˇe TecDoc,

•

vyhledání automobilu˚ podle ruzných ˚ kritérií (výrobce, model, typ karoserie, typ motoru, . . . ),

•

vyhledání informací o nápravách, typech motoru, ˚ karoserií a brzdových systému, ˚

•

vyhledání skupin produktu˚ pro konkrétní automobil,

•

vyhledání produktu˚ podle zadaných kritérií,

•

vyhledání informací a technických dokumentu˚ o jednotlivých produktech. 38

4.2. TECHNOLOGIE Z hlediska úˇcelu systému Ashop je klíˇcové umožnit uživateli vyhledat náhradní díl na jeho automobil. Pokud zná objednací cˇ íslo produktu, znamená to z hlediska implementace pro získání nejobecnˇejších informací volání funkce getArticleDirectSearchAllNumbers2() webové služby TecDoc. Funkce má následující povinné parametry: •

articleNumber - cˇ íslo produktu

•

country - kód zemˇe ve formátu ISO 3136

•

numberType - typ cˇ ísla produktu (EAN, náhradní cˇ íslo, objednací cˇ íslo, . . . )

•

providerId - pˇridˇelený identifikátor poskytovatele

•

searchExact - hledat pˇresnˇe stejné nebo i podobné cˇ íslo

•

sortType - tˇrídit podle výrobce, skupiny produktu, ...

Jako výsledek funkce vrací následující hodnoty: •

articleId - id produktu

•

articleName - název produktu

•

articleNo - cˇ íslo produktu

•

brandName - jméno výrobce

•

brandNo - cˇ íslo výrobce

•

genericArticleId - obecné cˇ íslo produktu

•

numberType - typ cˇ ísla produktu

Podrobnˇejší údaje o produktu lze získat pomocí volání dalších metod, napˇríklad getArticleDocuments() nebo getDirectArticlePartList2(). Tyto údaje jsou dále spojeny s informacemi z databáze systému (cena, množství skladem, sleva, . . . ) a následnˇe zobrazeny uživateli. Pokud však uživatel nezná objednací cˇ íslo, znamená to volat v nˇekolika krocích funkce urˇcené pro procházení vyhledávacího stromu a postupnˇe vybrat výrobce automobilu, model automobilu, motor, skupinu (podskupinu) produktu˚ a konkrétní produkt. K tomuto úˇcelu slouží napˇríklad funkce getVehicleManufacturers2(), getVehicleModels2(), getVehicleSimplifiedSelection2(), getVehicleIdsByCarTypeManuIdModelIdCriteria2() a mnohé další. Systém využívá celou rˇ adu dalších funkcí, zejména na vyhledání detailních informací o automobilech a produktech, jež mohou být pro uživatele zajímavé. Kompletní dokumentace webové služby je dostupná na adrese . Na obrázku 4.4 je uživatelské rozhraní systému s nalezenými produkty. Další ukázka rozhraní je uvedena v pˇríloze D. 39

4.3. DIAGRAM NASAZENÍ

Obrázek 4.4: Uživatelské rozhraní systému s výsledky hledání

4.3

Diagram nasazení

Diagram nasazení zobrazuje, jakým zpusobem ˚ bude rozmístˇena architektura softwaru na architekturu hardwaru. Diagram ukazuje hardwarové uzly, na kterých bude systém spouštˇen a softwarové komponenty, které na tˇechto uzlech pobˇeží. Diagram nasazení systému Ashop je na obrázku 4.5. Obsahuje následující uzly: •

Aplikaˇcní server - na tomto serveru bude nainstalován servletový kontejner TomCat, který bude sloužit jako bˇehové prostˇredí pro Eshop a s ním související kompomenty AktualizaceDat a AdministraceEshopu.

•

Databázový server - na tomto serveru pobˇeží relaˇcní databáze MySQL, která bude sloužit k uchovávání dat.

•

TecDoc - je server, na kterém bˇeží webová služba TecDoc, poskytující našemu systému katalog náhradních dílu. ˚ 40

4.3. DIAGRAM NASAZENÍ •

ZákazníkPC/ZamˇestanecPC - jedná se o klientské poˇcítaˇce, na kterých pobˇeží webový prohlížeˇc. Jeho prostˇrednictvím budou uživatelé (zákazníci a zamˇestnanci) pˇristupovat k systému.

•

Skladový systém Venet - pˇredstavuje server, na kterém bˇeží souˇcasný skladový systém firmy. Z uvedeného systému se budou naˇcítat data, která je nutné dennˇe aktualizovat (ceny produktu, ˚ slevy zákazníku, ˚ ...).

Obrázek 4.5: Diagram nasazení modelovaného systému

41

Kapitola 5

Závˇer Výsledkem práce je analýza a návrh elektronického obchodu s automobilovými náhradními díly s durazem ˚ na použití softwarových vzoru, ˚ cˇ ásteˇcná implementace veˇrejného rozhraní systému a popis použitých technologií. Systém je napojen na webovou službu TecDoc, která slouží jako katalog náhradních dílu˚ a zárovenˇ na skladový systém Venet, ze kterého jsou naˇcítány informace o zákaznících a nabízených produktech. V první kapitole jsou pˇredstaveny analytické vzory, jejichž prukopníkem ˚ se stal Martin Fowler, autor mnoha publikací o objektovˇe orientované analýze, UML a softwarových vzorech. Práce obsahuje popis a vysvˇetlení analityckých vzoru, ˚ které našly uplatnˇení pˇri modelování systému. Jejich použití tedy není ukázáno na umˇelých pˇríkladech, ale pˇrímo na cˇ ásti modelovaného systému. Dále je cˇ tenáˇr seznámen s modely systému, jež se používají ve fázi analýzy. Druhá kapitola se zabývá návrhovými vzory. Pˇredstavuje nˇekteré klasické „GoF“ vzory, jež se staly základem návrhových vzoru˚ pro enterprise aplikace na platformˇe Java a opˇet byly využity pˇri modelování systému. Konrétnˇe vzor Data Acces Object a jeho rozšíˇrení Factory for Data Access Object. Tˇretí kapitola se v úvodní cˇ ásti vˇenuje architektonickým vzorum. ˚ Podrobnˇe je vysvˇetlen vzor Model View Controller, na nˇemž je vystavˇen jeden z aplikaˇcních rámcu˚ použitých pˇri implementaci. Další cˇ ást se vˇenuje popisu již samotných technologií. Na implementaci vrstvy perzistence dat byl použit rámec Hibernate, aplikaˇcní logika a prezentaˇcní vrstva byla implementována pomocí rámce Spring Framework a na zabezpeˇcení byl využit rámec Spring Security. Tato cˇ ást se zamˇerˇ uje pˇredevším na konkrétní vlastnosti, principy a funkcionalitu zmínˇených rámcu, ˚ jež našly uplatnˇení pˇri implemetaci. Dále je v kapitole pˇredstavena webová služba TecDoc, na kterou je eshop napojen a jež slouží jako dababáze informací o automobilech a náhradních dílech. Vzhledem k množství poskytovaných dat se jedná celosvˇetovˇe o unikátní databázi. V poslední cˇ ásti je uveden diagram nasazení systému. Na závˇer je tˇreba zmínit, že po dokonˇcení implementace bude systém spuštˇen a využíván firmou Autodat s.r.o. Pˇrestože TecDoc poskytuje prostˇrednictvím webové služby systému obrovské množství produktu˚ (a informací o nich), v jeho databázi bohužel nejsou všechny, které firma v souˇcasné chvíli nabízí prostˇrednictvím kamenné prodejny. Do budoucna je proto plánováno napojení systému na další zdroj dat, at’ již ve formˇe nˇejaké externí databáze nebo další webové služby. Záležet bude na konkrétním poskytovateli dat. Avšak vzhledem k tomu, že byl systém vyvíjen s využitím softwarových vzoru, ˚ je na implementaci tohoto napojení dobˇre pˇripraven. 42

Literatura [1] Alexander, C. a Ishikawa, S. a Silverstein, M.: A Pattern Language, 1977, Oxford University Press. 2.4.1 [2] Schmidt, D. a Stal, M. a Rohnert, H. a Buschmann, F.: Pattern-Oriented Software Architecture, 2000, 0-471-60695-2, Wiley & Sons. 3.1.2 [3] Oldfield, P.: Domain Modelling, 2002, . 2.3 [4] Fowler, M.: Analysis Patterns, 1997, 0-201-89542-0, Addison-Wesley. 2.4.2 [5] Gamma, E. a Helm, R. a Johnson, R. a Vlissides, J.: Design Patterns, 0-201-63361-2, 1995, Addison-Wesley. 2.4.1, 3.1.1, 3.1.4.1, 3.1.4.2, 3.1.4.2 [6] Alur, D. a Crupi, J. a Malks, D.: Core J2EE Patterns, 2001, 0130648841, Prentice Hall / Sun Microsystems Press. 3.1.2, 3.1.4.3 [7] Buschmann, F. a Meunier, R. a Rohnert, H. a Sommerlad, P. a Stal, M.: Pattern-Oriented Software Architecture, John Wiley & Sons, 1996, 0471958897. 4.1.1 [8] Spring Framework, 2010, . 4.3 [9] Arlow, J. a Neustadt, I.: UML 2 a unifikovaný proces vývoje aplikací, 978-80-251-15039, 2007, Computer Press. 2.2 [10] Ferris, C. a Champion, M. a Hollander, D.: Web Service Architecture, 2004, . 4.2.4.2

43

Rejstˇrík Abstract Factory, 17 analitický model, 11 anotace, 30 Ashop, 3, 7, 35 Behavioral Patterns, 15 Blackboard, 27 Christopher Alexander, 8 Controller, 27, 33 Creational Patterns, 15

SQL, 31 Structural Patterns, 15 TecDoc, 3, 36 TecDoc Web Service, 37 textová specifikace, 4 View, 27 WSDL, 37 XML, 29

DAO, 19, 22 DAO Factory, 20 diagram pˇrípadu˚ užití, 3 entita, 7 Factory Method, 16 GoF, 8, 14 Hibernate, 28 HQL, 31 internet, 1 Inversion of Control, 32 Layers, 27 Martin Fowler, 9 Microkernel, 28 Model, 27 MVC, 25 návrhový model, 22 Organization Hierarchy, 9, 12 ORM, 28 Pipes and Filtres, 27 Quantity, 11, 12 Spring, 32 Spring Security, 35 44

Pˇríloha A

Obsah pˇriloženého CD Souˇcástí diplomové práce je CD, které obsahuje: •

diplomovou práce ve formátu PDF /thesis.pdf

•

text práce ve formátu DocBook /text

•

UML modely systému jako projekt pro Visual Paradigm /uml

•

zdrojové kódy systému /source

45

Pˇríloha B

Textová specifikace pˇrípadu˚ užití •

Registrace zákaznickým cˇ íslem - umožnuje ˇ uživateli provést registraci pomocí zákaznického cˇ ísla. Po vyplnˇení registraˇcního formuláˇre s povinnými údaji (zákaznické cˇ íslo, email, telefon) a jeho odesláním je registrace uložena do systému a cˇ eká na zpracování.

ˇíslo. Vstupní podmínky: uživatel zná své zákaznické c Aktéˇ ri: neregistrovaný velkoobchodní zákazník. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "registrace zákaznickým ˇ císlem". 2. Systém zobrazí editovatelný registraˇ cní formuláˇ r. 3. Uživatel vyplní formuláˇ r a klikne "registrovat". 4. Systém uloží registraci do databáze.

•

Registrace - umožnuje ˇ vytvoˇrit nový zákaznický úˇcet v systému. Po vyplnˇení povinných údaju˚ registraˇcního formuláˇre a jeho odeslání je zákazník zaregistrován a muže ˚ se pˇrihlásit do systému.

Aktéˇ ri: neregistrovaný zákazník. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "registrace". 2. Systém zobrazí editovatelný registraˇ cní formuláˇ r. 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ˇ rí nový uživatelský uˇ cet. 5.2 PU konˇ cí. 6. ELSE pokraˇ cuje krokem 2.

•

Vyhledání zboží - umožnuje ˇ vyhledat náhradní díly a doplnky ˇ k automobilum ˚ bud’ pˇrímo zadáním cˇ ísla výrobku nebo vybráním konkrétního automobilu (výrobce, model, typ motoru) a následnˇe prohledáním katalogu dostupných výrobku˚ pro tento automobil.

Aktéˇ ri: neregistrovaný zákazník, webová služba TecDoc. Tok událostí:

46

ˇ ˚ UŽITÍ B. T EXTOVÁ SPECIFIKACE P RÍPAD U

1. PU zaˇ cíná tím, že uživatel klikne na "náhradní díly". 2. Systém zobrazí seznam výrobc˚ u automobil˚ u (audi, citroen, ...). 3. Uživatel klikne na konrétního výrobce. 4. Systém zobrazí seznam model˚ u pro vybraného výrobce automobilu. 5. Uživatel klikne na konkrétní model automobilu. 6. Systém zobrazí seznam typ˚ u 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í ˇ císlo a klikne na "vyhledat". 2. Systém zobrazí nalezené zboží.

•

Správa nákupního košíku - zahrnuje pˇridání vyhledaného zboží, odebrání nebo zmˇenu množství zboží v košíku. Nákupní košík zobrazuje informace o zboží (objednací cˇ íslo, název, cena, poˇcet kusu) ˚ a celkovou cenu nákupu. Zboží v nákupním košíku si muže ˚ zákazník objednat.

Aktéˇ ri: neregistrovaný zákazník.

•

Objednání zboží - umožnuje ˇ objednat zboží v nákupním košíku. Uživatel zvolí zpu˚ sob dopravy, zpusob ˚ platby, vyplní nebo pouze zkontroluje (pokud byly naˇcteny z uživatelského profilu) dodací a fakturaˇcní údaje a následnˇe potvrdí objednávku.

Aktéˇ ri: neregistrovaný zákazník. Vstupní podmínky: Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "objednat". 2. Systém zobrazí formuláˇ r pro volbu zp˚ usobu dopravy. 3. Uživatel vybere zp˚ usob dopravy a klikne "pokraˇ covat". 4. Systém zobrazí formuláˇ r pro volbu zp˚ usobu platby. 5. Uživatel vybere zp˚ usob platby a klikne na "pokraˇ covat". 6. Systém zobrazí formuláˇ r pro zadání fakturaˇ cní a dodací adresy. 7. Uživatel vyplní údaje a klikne na "pokraˇ covat". 8. Systém zobrazí souhrn všech údaj˚ u. 9. Uživatel klikne na "objednat". 10. Systém uloží objednávku do databáze a zašle uživateli informaˇ cní email. Alternativní tok: 1. Uživatel se m˚ uže vrátit na pˇ redchozí krok kliknutím na "zpˇ et". 2. Uživatel m˚ uže objednávku kdykoliv pˇ rerušit.

•

Prohlížení objednávek - umožnuje ˇ uživateli prohlížet detaily o všech svých realizovaných objednávkách.

47


Aktéˇ ri: zákazník. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cí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 úˇctu - umožnuje ˇ uživateli editovat osobní cˇ i firemní údaje, fakturaˇcní a dodací adresu a kontaktní údaje.

Aktéˇ ri: zákazník. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "m˚ uj úˇ cet". 2. Systém zobrazí seznam možných nastavení. 3. Uživatel klikne na konkrétní položku nastavení. 4. Systém zobrazí formuláˇ r pro editaci požadovaného nastavení. 5. Uživatel zmˇ ení požadované údaje a klikne na "uložit". 6. Systém uloží zmˇ eny do databáze.

•

Správa objednávek - umožnuje ˇ zpracování objednávek zákazníku. ˚ Zahrnuje vytvorˇ ení a zrušení online objednávky, zpracování pˇrijaté objednávky.

Aktéˇ ri: zamˇ estnanec. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "objednávky". 2. Systém zobrazí seznam objednávek a možnosti jejich filtrování. 3. Uživatel zvolí konkrétní filtr. 4. Systém zobrazí vyfiltrované objednávky. 5. Uživatel zvolí konkrétní objednávku a klikne "upravit". 6. Systém zobrazí detaily vybrané objednávky. 7. Uživatel provede požadované zmˇ eny objednávky a klikne "potvrdit". 8. Systém uloží zmˇ eny do databáze.

•

Ovˇerˇení registrace - umožnuje ˇ ovˇerˇ it registraci zákazníka pomocí zákaznického cˇ ísla. Uživatel zkontroluje údaje zadané pˇri registraci a pokud jsou v poˇrádku, zašle zákazníkovi pˇrihlašovací údaje.

Aktéˇ ri: zamˇ estnanec. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel zvolí "ovˇ eˇ rit registraci". 2. Systém zobrazí seznam všech dosud neovˇ eˇ rených registrací. 3. Uživatel zvolí jednu konkrétní registraci a klikne na "detaily".

48


4. Systém zobrazí údaje vyplnˇ ené pˇ ri registraci. 5. Uživatel údaje ovˇ eˇ rí. 5.1 IF údaje jsou správné. 5.1.1 Uživatel klikne na "Ovˇ eˇ reno". 5.1.2. Systém vygeneruje pˇ rihlašovací údaje a zašle je emailem zákazníkovi, který se registroval pomocí zákaznického ˇ císla. 5.2 ELSE ovˇ eˇ rení je zamítnuto. 5.2.1 Systém zašle zákazníkovi emailem d˚ uvody pro zamítnutí registrace.

•

Správa objednávek - umožnuje ˇ zpracování objednávek zákazníku. ˚ Zahrnuje vytvorˇ ení a zrušení online objednávky, zpracování pˇrijaté objednávky.

Aktéˇ ri: zamˇ estnanec. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "objednávky". 2. Systém zobrazí seznam objednávek a možnosti jejich filtrování. 3. Uživatel zvolí konkrétní filtr. 4. Systém zobrazí vyfiltrované objednávky. 5. Uživatel zvolí konkrétní objednávku a klikne "upravit". 6. Systém zobrazí detaily vybrané objednávky. 7. Uživatel provede požadované zmˇ eny objednávky a klikne "potvrdit". 8. Systém uloží zmˇ eny do databáze.

•

Správa eshopu - umožnuje ˇ konfigurovat dostupná nastavení systému: automaticky generované emaily, zpusoby ˚ plateb, zpusoby ˚ dopravy, ...

Aktéˇ ri: administrátor. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "nastavení eshopu". 2. Systém zobrazí editovatelný formuláˇ r pro nastavení systému. 3. Uživatel zmˇ ení požadované vlastnosti a klikne "uložit nastavení". 4. Systém uloží nastavení do databáze.

•

Správa produktu˚ - umožnuje ˇ spravovat produkty, které nejsou naˇcítany z externího systému TecDoc.

Aktéˇ ri: administrátor. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "správa produkt˚ u". 2. Systém zobrazí pˇ rehled produkt˚ u ve vybrané kategorii katalogu. 3. Uživatel pˇ ridá, smaže nebo edituje vlastnosti produktu. 4. Systém uloží zmˇ eny do databáze.

49


•

Správa kategorií - umožnuje ˇ mˇenit strukturu katalogu produktu, ˚ tzn. pˇridat, smazat nebo editovat vybranou kategorii.

Aktéˇ ri: administrátor. Vstupní podmínky: uživatel je pˇ rihlášen do systému. Tok událostí: 1. PU zaˇ cíná, když uživatel klikne na "správa kategorií". 2. Systém zobrazí pˇ rehled kategorií produkt˚ u. 3. Uživatel pˇ ridá, smaže nebo edituje vybranou kategorii produkt˚ u. 4. Systém uloží zmˇ eny do databáze.

•

Import dat - každý den se ve stanovenou hodinu automaticky stahují soubory z externího skladového systému Venet. Tyto soubory obsahují data o produktech (cena, skladová dostupnost) a data o zákaznících.

Aktéˇ ri: ˇ cas, externí systém Venet. Vstupní podmínky: PU je spuštˇ en každý den ve stanovený ˇ cas. Tok událostí: 1. Systém si stáhne ze skladového systému Venet soubory obsahující data pro aktualizaci. 2. Systém stažená data zpracuje a uloží do databáze.

•

Správa uživatelu˚ - umožnuje ˇ vytváˇret, editovat a rušit uživatelské úˇcty a zárovenˇ konfigurovat pˇrístupové práva k jednotlivým cˇ ástem systému.

50

Pˇríloha C

Analytický model tˇríd Obrázek C.1 obsahuje kompletní analytický model tˇríd. Oproti modelu uvedenému v kapitole 2.5 byly nˇekteré entity z duvodu ˚ nedostatku místa pˇresunuty.

51

ˇ C. A NALYTICKÝ MODEL T RÍD

Obrázek C.1: Analytický model tˇríd

52

Pˇríloha D

Ukázka uživatelského rozhraní

Obrázek D.1: Registrace zákaznickým cˇ íslem

53

012345

Recommend Documents