Návrh architektury systému na správu projekt· · Návrh architektury systému na správu projektů Vojtěch Král Vedoucí práce:Ing. Jiří Mlejnek Studijní program: Softwarové

České vysoké učení technické v PrazeFakulta elektrotechnická

Katedra počítačů

Bakalářská práce

Návrh architektury systému na správu projektů

Vojtěch Král

Vedoucí práce: Ing. Jiří Mlejnek

Studijní program: Softwarové technologie a management, Bakalářský

Obor: Softwarové inženýrství

20. května 2010

iv

v

PoděkováníChtěl bych poděkovat svému vedoucímu bakalářské práce panu Ing. Jiřímu Mlejnkovi za jehonemalý čas, který mi věnoval při konzultacích. Dále bych chtěl poděkovat panu RNDr. IvanuKorošovi za jazykovou korekci.

vi

vii

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

V Meziměstí dne 20. 5. 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

Abstract

This thesis deals with the selection of proper technologies and with a software design ofproject management system. The selection of the technologies includes choosing properprogramming language, server and database. The analysis of the technologies covers theselection of frameworks for data and presentation layer as well as the application frameworkused for uniting the whole system. Specification of interfaces for modules communicatingwith external systems such as SVN and TRAC is one of the important parts of the softwaredesign.

Abstrakt

Tato práce se zabývá výběrem adekvátních technologií a samotným návrhem systému nasprávu projektů. Výběr technologii se týká zvolení programovacího jazyka, serveru a databáze.Mezi analýzu technologii je zahrnut i výběr frameworků pro datovou a prezentační vrstvu adále aplikační framework, který pomůže propojit celou aplikaci. Důležitou součástí návrhu jemimo jiné specifikace rozhraní pro moduly sloužící ke komunikaci s externími systémy SVNa TRAC, se kterými navrhovaný systém spolupracuje.

ix

x

Obsah

1 Úvod 11.1 Kontext řešeného problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Cíle bakalářské práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Analýza 32.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Programovací Jazyk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Frameworky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Návrh řešení 153.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Datová vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Balíček entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Balíček dao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Business vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1 Balíček server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.2 Balíček project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Prezentační vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.1 Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5 Komunikace s okolím . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.6 Použité návrhové vzory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Zhodnocení provedených rozhodnutí 414.1 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Možná budoucí zlepšení 455.1 Nabízející se rozšíření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Nabízející se vylepšení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Instalační příručka 496.1 Předpříprava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Nasazení Swinpro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

xi

xii OBSAH

7 Závěr 51

Literatura 53

A Slovníček pojmů 59

B Obsah přiloženého CD 61

Seznam obrázků

3.1 Rozdělení doménové vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Rozdělení balíčku entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Rozdělení balíčku dao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Rozdělení balíčku dao.hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 Výtah tříd z balíčku dao.hibernate.project . . . . . . . . . . . . . . . . . . . . 213.6 Rozdělení balíčku business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.7 Rozdělení balíčku business.manager . . . . . . . . . . . . . . . . . . . . . . . . 233.8 První část balíčku business.manager.server . . . . . . . . . . . . . . . . . . . . 243.9 Druhá část balíčku business.server . . . . . . . . . . . . . . . . . . . . . . . . 253.10 První část balíčku business.manager.project . . . . . . . . . . . . . . . . . . . 293.11 Druhá část balíčku business.manager.project . . . . . . . . . . . . . . . . . . . 333.12 Schéma zpracování požadavku od uživatele . . . . . . . . . . . . . . . . . . . . 353.13 Schéma průchodu požadavku od uživatele skrze filtry . . . . . . . . . . . . . . 363.14 Schéma nasazení systému pro řízení projektů na fakulte . . . . . . . . . . . . 40

xiii

xiv SEZNAM OBRÁZKŮ

Seznam tabulek

xv

xvi SEZNAM TABULEK

Kapitola 1

Úvod

V úvodní kapitole bych nastínil důvody a okolnosti, které vedly ke vzniku této bakalářsképráce.

V 5. semestru mého studia v předmětech Y36SI2 a Y36SI3 jsem se dostal k zajímavémuprojektu. Úkolem projektu bylo analyzovat požadavky, navrhnout a implementovat systémna správu projektů SWINPRO1. Podrobnější kontext řešeného problému uvedu později. Mojiúlohou v projektu bylo provést samotný návrh a výběr technologií (podrobněji v kapitole „Cílebakalářské práce“) na základě analýzy požadavků v práci [65] kolegy Zdeňka Ryboly. Dalšíkolega z týmu Jan Ustohal se zabýval verzovacími systémy a jejich propojením se systémemSWINPRO v práci [68]. Kolega Jiří Špaček v práci [60] analyzoval autentizační metody ajejich využití pro systém SWINPRO. Michal Strnad se bude zabývat ve své bakalářské práci[67] testováním systému SWINPRO.

Implementace systému SWINPRO nebyla náplní mé bakalářské práce. Krom implementa-ce částí, které náleží do prací kolegů Ustahala, Špačka a Strnada a kolegové je implemetovalisami v rámci práce, zbyla ještě část, která nebyla zahrnuta do žádné výše zmíněné práce.Na této zbylé části se implementačně podílel celý tým v rámci semestrálního projektu vpředmětech Y36SI2 a Y36SI3.

1.1 Kontext řešeného problému

Na začátek této kapitoly bych chtěl zmínit, že podrobný rozbor problému a požadavků nasystém je v [65] a já zde uvádím pouze stručný popis, abych uvedl čtenáře do problematiky.Úkolem tohoto projektu bylo realizovat systém na zjednodušení postupu při vytváření pro-jektů v softwarově-inženýrských předmětech. Dále budu označovat tento systém na správuprojektu jménem „SWINPRO“. Tento postup se původně skládal z vytvoření studentskýchtýmů, vybrání tématu týmem, informování cvičícího a následně cvičící musel založit každémutýmu repozitář na správu zdrojového kódu a taky umožnit přístup do systému TRAC2.Největší práce spočívala na bedrech cvičícího, který (v případě zakládání TRACu a SVNrepozitáře) musel dělat tuto práci v příkazové řádce pomocí linuxových scriptů. Jelikož měl

1Jméno jsem převzal z [65]2TRAC je jeden ze systémů na správu požadavků.

1

2 KAPITOLA 1. ÚVOD

cvičící více cvičení a na každém cvičení okolo 3 až 5 týmů, tak mu zpřístupňování dílčíchsystému (TRAC, SVN) zabralo notnou dávku času.

Tento systém má za úkol automatizovat a ulehčit práci cvičícímu. Hlavní požadavky jsou,aby si studenti zakládali týmy a volili téma aniž by cvičící musel tomuto býti nápomocen.Až se studenti rozhodnou, že projekt je „zralý“, aby práce na něm mohla být započata, takprostřednictvím tohoto systému požádají svého cvičícího, alias supervisora (jak uvádí [65]),aby projekt schválil. Tento cvičící resp. supervisor pouze zkontroluje, že projekt je adekvátníjeho podmínkám, a potvrdí schválení (samozřejmě v opačném případě odmítne a uvedepřipomínky). Ovšem největším přínosem systému je automatické zakládání repozitáře SVNa nastavení přístupu pro TRAC pro daný projekt a všechny jeho participující členy. Totozaložení proběhne automaticky po schválení projektu a od cvičícího není vyžadováno žádnépsaní linuxových scriptů ani nic podobného. Toto byl stručný popis postupu, jak probíhalozakládání projektu dosud a jak by tento postup měl systém na správu projektů zjednodušit.Pro obsáhlejší rozbor požadavků odkazuji na [65], pro osvitu čtenáře jsem zde uvedl pouzestručný popis.

1.2 Cíle bakalářské práce

Cílem této bakalářské práce je analýza a rozbor technologií vhodných pro systém na správuprojektů. Cílem této analýzy je diskuse technologií možných pro použití a zmínění jejichvýhod a nevýhod a závěrem zdůvodnění proč ona technologie byla pro systém SWINPROpoužita. Rovněž je cílem této práce analýza architektury a rozbor užitých návrhových vzorůa zdůvodnění, jaké klady a zápory zvolená řešení přináší. V neposlední řadě je v této prácizahrnuto i několik návrhů na budoucí vylepšení systému, zejména jeho architektury. Rovněžje v této práci rozbor architektury podpořen UML3 diagramy, které pomáhají k lepšímupochopení rozborů architektury. V této práci neuvedu úplně všechny UML diagramy, kteréjsem při návrhu architektury vytvořil. V případech kdy by se diagramy lišily jen nepatrně,zvolím jeden etalon a u ostatních se zmíní pouze jejich významné odlišnosti od etalonu.Všechny vytvořené diagramy jsou na přiloženém CD.

Kromě analýzy architektonické je součástí práce i popis postupu při nasazení tohotosystému do „ostrého“ provozu. Rovněž při tomto popisu budou uvedeny podmínky, kterémusí prostředí splňovat před instalací systému SWINPRO.

Tato práce navazuje na analýzu požadavku provedené v [65]. Proto se budu poměrně častona tuto literaturu odvolávat při zdůvodňování zvolené technologie, stylu architektury atd.Je tomu z toho důvodu, že požadavky uživatele samozřejmě ovlivňují funkčnost systémua různé styly architektury resp. použité technologie umožňují naplnění funkce snadněji anaopak některé s notnými problémy.

3Unified Modeling Language

Kapitola 2

Analýza

2.1 Architektura

Prvotním cílem bylo zvolit jakou vlastně bude mít systém na řízení projektů architekturu. Ipřes skutečnost, že se mi nabízelo více možností, byla konečná volba poměrně jednoduchá.

Základním kritériem, které muselo být vzato v úvahu, je to, že systém nabízí služby víceuživatelům z různých míst zároveň a tudíž možnost, že by byl navržen jako čistě desktopováaplikace, byla vyloučena. Samozřejmě, že by tento návrh byl proveditelný, ale vyžadovalby navíc speciální synchronizaci mezi jednotlivými instalacemi systému a nebo by studentimuseli používat pouze jeden počítač, což odporuje předpokladu. Další možností bylo postavitsystém jako klient-server aplikaci. Tato možnost samozřejmě je intuitivní, protože podporujepřístup více uživatelů na jedno centralizované úložiště dat resp. funkcí, které systém spravuje,resp. poskytuje. Tímto poskytovatelem je samozřejmě server, který je ideálně spuštěn napočítači mající veřejnou IP adresu a nebo dostupnou privátní adresu, pokud by systém bylprovozován na intranetu.

Po vybrání architektury typu klient-server jsou zde další dvě majoritní možnosti. Za prvéklient může být implementován jako „tlustý“ a nebo za druhé jako „tenký“. Definici „tlustého“a „tenkého“ klienta jsem převzal z [9], respektive [31], a příslušné české ekvivalenty z [5]. Vpřípadě implementace „tlustého“ klienta by bylo nutné implementovat jak server, tak ještěklienta, který by na své straně měl část, či celou logiku aplikace a pouze by komunikoval seserverem, který by mu poskytoval data nebo i některou funkčnost. Tento styl implementaceby měl tu výhodu, že by nemuselo být požadováno trvalé spojení se serverem a pro operaceneměnící data by bylo možno poskytnout i režim pouze prohlížení bez připojení na server.Tato výhoda nemá tak velkou váhu, protože když už chceme něco prohlížet, tak je zcela jistělepší mít aktuální data. Zároveň by se taky musela řešit otázka, která všechna data majíbýt v režimu offline přístupná a tato data by se pak musela zkopírovat ze serveru, což bymohlo vyústit i v kopii celé databáze. Při velkém množství dat v databázi by to mohl býtproblém. Nehledě na to, kdyby se povolily i úpravy v offline režimu, to by pak vyvstávalyproblémy se synchronizací upravených dat a kam nová upravená data ukládat na straněklienta. Další poměrně svízelnou otázkou je, jak distribuovat nové verze „tlustého“ klientamezi všechny uživatele, když každý z nich může mít jiný operační systém. Dala by se za tímtoúčelem použít třeba JavaWeb Start (viz [34]). Nevýhodou JavaWeb Start je, že podle [34] a

3

4 KAPITOLA 2. ANALÝZA

[18] se implicitně pouští aplikace v zabezpečeném módu, který nedovoluje například přístupna disk nebo k síťové komunikaci. Tento problém by se dal vyřešit digitálním podpisem.Větší problém jsem ale viděl v nutnosti mít JRE1 nainstalován na uživatelově počítači. Proinstalaci JRE by mohlo být na veřejných počítačích (v knihovně, škole, internetové kavárněatd.) zapotřebí vlastnit administrátorská práva a s tímto faktem ani technologie JavaWebStart „nehne“. Samozřejmě by tento klient musel být přenositelný (což by Java Web Startzaručila), protože se očekává přístup studentů z nejrůznějších operačních systémů. Jak jsemvýše nastínil, muselo by se vyřešit několik problémů při použití „tlustého“ klienta, a protojsem „tlustého“ klienta nezvolil.

Jako mnohem lepší řešení se mně jevilo použití „tenkého“ klienta, který bude mít nasvé straně minimum logiky („minimum“ jsem použil záměrně, neboť webový prohlížeč můžeobsahovat logiku, třeba na kontrolu formulářů v podobě JavaScriptu) a bude hlavně sloužitpro zobrazení dat a interakci s uživatelem. Webový prohlížeč je podle mě velice dobrávolba, protože rozšíření prohlížečů napříč hlavními operačními systémy je veliké (jak můžetezjistit v [6]), takže je až na minoritní výjimky v podstatě zaručeno, že uživatel bude mocivyužít přístupu přes webový prohlížeč na běžném školním, kancelářském nebo domácímpočítači. Zároveň i později vybraný framework RichFaces podporuje nejvíce rozšířené webovéprohlížeče, viz [38], takže ani v tomto ohledu nenastal následkem zvolení webového prohlížečežádný problém. S výběrem webového prohlížeče jsem následně zvolil komunikační protokola to HTTP2, respektive HTTPS3. Jak se uvádí v [58], protokol HTTPS je šifrovaná variantaprotokolu HTTP a je vhodnější pro přenášení dat, která je potřeba zabezpečit, aby jenemohl přečíst nežádoucí subjekt. Zároveň také HTTPS zaručuje, že totožnost odesílatele datnení podvržená. Pro komunikaci přes HTTP/HTTPS je potřeba mít i server, který tomutoprotokolu rozumí a je schopen pomocí něho komunikovat s klientem. Možnostmi serverů ajejich výhod a nevýhod se budu podrobněji zabývat později.

2.2 Technologie

V této části práce budu diskutovat a rozebírat použité technologie a technologie, které mohlybýt použity, ale nebyly. Zároveň také budu analyzovat výhody a nevýhody jednotlivýchalternativ.

2.2.1 Programovací Jazyk

Otázka typu architektury již byla vyřešena a nyní zbývalo se rozhodnout jaký jazyk použítpro systém na řízení projektů. Nabízely se mi v podstatě tyto jazyky/platformy: C++,PHP4, .Net, J2EE5. Některé jazyky jako třeba Ruby, Smalltalk, Objective-C nebo Coboljsem do výběru nezahrnul, protože jsou málo používané (viz jejich popularita na [57])a protože s těmito jazyky nemám žádnou praktickou zkušenost. Výhody, které zmiňuje[61], jako například snazší udržovatelnost a znovupoužitelnost, pro mě hrály hlavní roli při

1Java Runtime Enviroment2HyperText Transfer Protocol3HTTP Secure4Rekursivní zkratka z „PHP: Hypertext Preprocesor“5Zkratka pro Javu Enterprise Edition

2.2. TECHNOLOGIE 5

výběru objektové (abych byl korektní tak objektově orientované) kategorie a tudíž ve výběruneobjektové jazyky nejsou.

C++

Výhodou toho jazyka je určitě rychlost, jak zmiňuje např. [47]. Tento jazyk by se určitěhodil pro systémy mající vysoké nároky na rychlost. Jak je uvedeno v [65], tento systémje určen hlavně pro školní účely s přihlédnutím na možnost nasazení i v komerční sféře.Jelikož ale nemá za úkol pracovat s enormním množstvím uživatelů nebo dat v extrémněkrátkých časech, tak rychlostní výhoda C++ nehraje tak velikou roli při rozhodování. Naopaknevýhodou jazyka C++ je malý výběr frameworků hodících se pro vyvíjený systém, kterýmiby například mohly být Wt (pro podrobnější údaje odkazuji na [35]) nebo CppCMS (propodrobnější údaje odkazuji na [33]). Ovšem na rozdíl od Javy, která má podle seznamu na[25] velké množství webových frameworků, je toto pouze kapka v moři. Zároveň také dalšínevýhodou je podle [47] nedostatek standardních nástrojů a knihoven. A navíc v případěpoužití tohoto jazyka by bylo nutno vyvinou různé verze pro různé operační systémy.

PHP

V tomto jazyku začíná „programovat“ většina lidí, kteří se chtějí začlenit mezi vývojářewebových interaktivních aplikací. Určitě je toto pro začátek vhodný jazyk a pokud progra-mátor postoupí dále v jeho znalostech, tak může programovat i objektově. Zároveň je k němudostupná řada frameworků, např. jak uvádí [66] ZendFramework, CakePHP, Codelgniter,PRADO. Co se mně jeví jako nevýhoda php je skutečnost (podle [55] kap. 4.), že php jeinterpretovaný jazyk, a tudíž se syntaktické chyby v kódu projeví až za běhu, protože neníprovedena kontrola překladačem při překladu. Zároveň předem zmíněná kniha hovoří i o tom,že místo chyby podle výpisu se může s opravdovým místem chyby značně lišit. Dále podle[48] php neobsahuje ani typovou kontrolu a i tento fakt se projeví chybou až za běhu. TakžePHP jsem také nezvolil jako jazyk pro implementaci.

.NET

Platforma pro .NET je proprietárním produktem firmy Microsoft, a je tudíž určena prooperační systém Windows. Jak uvádí [56] tak existuje alternativa pro Linux a sice projekts názvem „Mono“. .NET platforma, jelikož je podporována Microsoftem, tak má i značnouzákladnu co se týče knihovních funkcí. Důvodem proč nebyla tato platforma vybrána jakoimplementační je její portovatelnost. Sice existuje výše zmíněný projekt Mono, nicméně Javaa její JVM6 jsou pod jednou střechou firmy SUN Microsystems, a tudíž o všechny JVM sestará jedna firma, a tak je zde, podle mého názoru určitý větší kredit, že bude přenositelnostlepší (ostatně je to v zájmu samotné firmy Sun, když proklamuje přenositelnost Javy viznapříklad [21]). Dalším neméně vážným aspektem je, že moje dosud nabyté zkušenosti jsouhlavně z prostředí Javy a tudíž by osvojování .NETu zabralo čas, kterým bych pak mohlzpozdit práce navazující na tuto bakalářskou práci.

6Java Virtual Machine


Java

Zbývá zmínit poslední jazyk z nabídky a tím je jazyk Java. Požadavky na přenositelnostjsou u tohoto jazyka splněny (portovatelnost zmiňuje [21]). Podle [52] a [17] je napsanýprogram překládán do bytecodu a po spuštění je za běhu interpretován virtuálním strojemJavy, který už je specifický pro ten který operační systém. Tímto se tedy odstíní programátorod budoucího operačního systému. Další značnou výhodou Javy respektive Javy EnterpriseEdition (edice Javy určena pro enterprise systémy) je její značná rozšířenost ve světě webovýchaplikací a systémů (zmiňuje [16]) a s tím spojená bohatá podpora. Tato podpora se týká jakdůsledně definovaných principů v J2EE7 (J2EE je vlastně soubor metod, standardů, principůa postupů, jak je uvedeno v [14] nebo [13]) tak i dostupných frameworků (viz seznam [25]),které implementují nebo vlastním stylem rozšiřují tyto standardy. Dále je s touto rozšířenostíJavy spojeno i velké zázemí komunity a rovněž veliká pravděpodobnost, že problémy, kterése v průběhu vývoje objeví, již někdo dříve vyřešil, a tudíž půjdou dohledat na Internetu.Nakonec jsem jako platformu pro implementaci z výše zmíněných důvodů zvolil J2EE.

2.2.2 Server

Základní styl architektury a vývojová platforma už byly vybrány. Jelikož jako klienta jsemse rozhodl přepoužít webový prohlížeč, tak nyní zbývá vybrat aplikaci, která bude běžetna serverové straně. V zásadě se nabízely dvě možnosti: zvolit aplikační server nebo pouzeservletový kontejner a přidat do něj framework pro nahrazení EJB8 a pro podporu JPA9.Podle zdroje [8] se EJB používá pro business logiku a podle [16] je součástí standardu JavaEnterprise Edition (stejně jako JPA), takže je obsaženo v J2EE kompatibilních aplikačníchserverech - viz seznam [15]. O frameworcích nahrazujících EJB a podporujících JPA budupodrobněji diskutovat později. Nyní bych analyzoval možnosti, které se byly k dispozici zhlediska výběrů serverů.

Ještě bych chtěl zmínit, že systém na správu projektů je možno přenášet mezi nížediskutovánými servery. Je samozřejmě nutné přizpůsobit konfigurační soubory danému ser-veru, ale aplikace „vevnitř“ jako taková se nemusí přizpůsobovat. Maximálně by mohl nastatproblém mezi knihovnami připojenými k aplikaci a knihovnami přímo na serveru. Nicméněpo drobných úpravách konfiguračního souboru a náležitém otestování aplikace na novémserveru není problém provozovat systém SWINPRO na různých aplikačních serverech.

Aplikační servery

Jak uvádí [70], aplikační server již obsahuje potřebné knihovny pro podporu vývoje aplikace.Těmito nejdůležitějšími věcmi je podpora pro prezentační vrstvu, business vrstvu a dále pakpro objektově-relační mapování a ostatní (vycházím z [16], [70] a [3]).

Na trhu existují jak placené tak open source aplikační servery. Placené aplikační serveryvůbec nepřipadaly do úvahy pro tento systém. Důvody byly následující: cena a skutečnost,že open source varianty jsou stejně tak v seznamu oficiálních implementací JEE10 5 na [15]

7Zkratka pro Javu Enterprise Edition8Enterprise Java Bean9Java Persistence API

10Jiná možná zktratka pro Javu Enterprise Edition

2.2. TECHNOLOGIE 7

jako placené verze. Jelikož tento systém je primárně určen pro školní účely, tak role cenováhrála podstatnou roli. Když si uvědomíme, že například takový aplikační server WebLogicod Oraclu stoji ve standardní verzi circa 10 000 amerických dolarů (tento údaj je získán z[27]), tak vynaložení uvedené částky pro takovýto školní projekt je zcela zbytečné.

Placenou variantu aplikačního serveru jsem tedy zcela vyloučil a zbývá zde open sourceřešení. Prakticky se nabízí dva produkty GlassFish (ten je teď již také majetkem Oraclu) aJBoss.

První zmíněný vznikl pod křídly firmy Sun Microsystems a nyní je pod taktovkou Oraclu,ostatně jako celý Sun. Pro naše účely by v podstatě vyhovoval. Je zdarma a obsahujeframeworky pro prezentační, business a mapovací vrstvu a zároveň je integrovaný s vývojovýmprostředím NetBeans, ve kterém se bude tento systém vyvíjet. I přesto má jednu vadu na„kráse“ a tou je jeho budoucnost. Pokud si přečtete [37], tak zde nabudete dojmu, že Oraclese chystá podporovat i nadále projekt GlassFish. Ovšem článek [49] zmiňuje, že budoucnostGlassFishe nemusí být až tak zřejmá. Naznačuje, že sice Oracle veřejně přislíbil pokračovati nadále s GlassFishem, ale taky poukazuje na fakt, že společnost Oracle již jeden aplikačníserver spravuje, a to WebLogic (zdroj se už nezmiňuje o 3. aplikačním serveru „OracleInternet Application Server“ viz [26]). Mít dva aplikační servery pod jednou firmou, k tomujeden placený a druhý open source, může podle autora článku vyústit v různé konce. Buďbudou oba servery kooperovat a vzájemně sdílet technologie, nebo se může stát, že zákaznícinebudou chtít platit za drahý WebLogic a místo toho si pořídí GlassFish. A také zároveňnení jasné do jaké míry hodlá Oracle podporovat GlassFish a kolik prostředků má v úmysludo tohoto projektu ještě investovat.

Kvůli nejasné budoucnosti aplikačního serveru GlassFish jsem se radši rozhodl se k výběrutohoto serveru nepřiklonit.

Další možností byl server JBoss od firmy Red Hat. Tento server je rovněž z kategorieaplikačních serverů, a tak jako GlassFish poskytuje již vestavěný základ pro podporu vývojeaplikací. Jelikož je JBoss náročný na systémové prostředky (viz [12]) a tento systém je určenprvotně pro školní účely, tak jsem tento server nevybral.

Na závěr bych chtěl zmínit, že i když nebyl vybrán žádný aplikační server, tak toneznamená, že v budoucnu se na něj nebude dát přejít. Jelikož systém má frameworkydodané a nevyužívá žádných speciálních vlastností poskytovaných serverem, tak se tentoinstalační balíček dá nasadit i na aplikační servery, protože potřebnou aplikační podporu si„ponese“ s sebou a po řádném otestování může být provozován i na tomto jiném serveru.

Servletové kontejnery

Jako významný hráč na tomto poli přichází v úvahu servletový kontejner Apache Tomcat.Jak říká [1] hned v prvním odstavci, tak Tomcat sám o sobě je uzpůsoben pro správu JSP11

stránek, respektive servletů (každá JSP stránka se vždy přeloží do jí funkčně ekvivalentníhoservletu, jak uvádí slide č. 9 z [44]). Jelikož JSP stránky, potažmo servlety, jsou určenyhlavně pro prezentační vrstvu, jsou poměrně nevyhovující vyvíjenému systému. Přeci jennechci navazovat spojení do databáze z prezentační vrstvy a už vůbec mít aplikaci v podstatějednovrstvou.

11Java Server Pages


Tento problém lze ovšem lehce řešit s použitím vhodných frameworků (viz napříkladrozsáhlý seznam [25]), které jsou volně dostupné a vytvoří podmínky pro pohodlné odděleníprezentační, business a datové vrstvy. Jelikož framework je v podstatě již hotový balík Javatříd, který poskytuje určitou funkčnost, tak ho lze lehce připojit k vyvíjenému projektu apoužívat jeho funkčnost. O tom, jaké možné frameworky se nabízejí, poreferuji později vpodkapitole „frameworky“. Důležité ale je, že Tomcat umožňuje vložení frameworků, kteréjsou pro vývoj potřeba (viz kapitola „frameworky“) , a tak umožní po stránce implementačnípokrýt problematiku podobně jako by to umožňoval aplikační server. Tomcat je také méněnáročný na systémové prostředky, a jelikož se pro systém pro správu projektu předpokládajípouze desítky (max. stovky) uživatelů celkově (nepřipojených současně), tak není vyžadovánopoužití robustního serveru. Zároveň nepředpokládám, že systém bude ve škole nasazen naextra výkonném počítači, čili menší spotřeba systémových zdrojů je velice žádoucí. V nepo-slední řadě je Tomcat neplacený, což je pro použití ve školním prostředí výhodou. Závěrembych pouze zmínil, že z výše zmíněných důvodů jsem vybral jako server Tomcat a to ve verzi6.

Další alternativou k serveru Tomcat by mohl být například server Jetty. Podle [71] jsouoba velice podobné servletové kontejnery, s tím, že Jetty je více modularitivnější. Nevýhodouovšem je, že NetBeans (vývojové prostředí ve kterém bude systém implementován) neníintegrováno s tímto serverem, takže hlavně proto jsem zvolil server Tomcat.

Výše zmíněné servery, jak jsem již řekl, jsou si poměrně blízké a jelikož aplikační balíček,který obsahuje systém SWINPRO si nese celou aplikační podporu s sebou, tak není problémmezi těmito dvěma servery systém SWINPRO přenést a po řádném otestování může býtprovozován i na jiném serveru.

2.2.3 Databáze

Další věcí co je pro systém na správu projektu potřeba, je databáze, kam se budou ukládatvšechna data. Databází se samozřejmě nabízí velké množství. Jako typ databáze jsem zvolilrelační databázi z hlediska jejího rozšíření (viz [28]) a taky počtu frameworků pro objektově-relační mapování (výčet těchto frameworků je např. zde [22]), které odstíňují aplikaci pracujícís objekty od databáze pracující s tabulkami. Čistě objektovou databázi jsem nevybral zdůvodu, že jsem s tímto typem databáze neměl zkušenosti. XML12 databázi jsem zároveňnezvolil, protože data, respektive objekty se kterými bude aplikace pracovat, nemají strukturu,která by speciálně vyžadovala ukládání nativně v XML. Rovněž XML databáze nejsou takrozšířené jako relační.

Mezi relačními databáze patří placené databáze jako například: Oracle, DB2 od IBM,Microsoft SQL server a ostatní. Tyto databáze jsou zpravidla velmi drahé. Jak uvedu vdalší podkapitole o použitých frameworcích, tak je „de-facto“ jedno, která databáze se zvolípro ukládání dat systému SWINPRO, protože použitý framework podporuje ukládání dat dovětšiny rozšířených databází. Čili pokud by tento systém byl nasazen v produkčním prostředía ukládala by se do něj kriticky důležitá data, tak by jistě bylo vhodné zvolit některý zprodukčních databázových strojů. Pro školní účely je toto ovšem ale zbytečné.

Výhodnější je použít některou z open source databází, jako jsou: MySQL, PostrgeSQL,Oracle XE.

12eXtended Markup Language

2.2. TECHNOLOGIE 9

Oracle XE

Jak píše [50] tak Oracle XE je neplacená verze postavena na produkční databázi Oracle 10.Jak uvádí [50] i [53], systémová náročnost této databáze je poměrně vysoká. Takový 1 GBdiskového místa při prázdné databázi je skutečně podle mě mnoho. Jak také uvádí [50], taktato neplacená varianta od Oraclu podporuje jen operační systémy Linux a Windows, cožv případě velkého rozšíření operačního systému Solaris ve škole by mohl být v budoucnuproblém. Jak jsem napsal hned v úvodu, tak Oracle XE je velký konzument systémovýchprostředků, a to byl hlavní fakt, proč jsem tuto databázi nezvolil jako podporu pro vyvíjenýsystém.

MySQL

Databáze nenáročná na systémové prostředky (v měřítku databázových strojů podle [53]).Jejím neduhem je, že ve výchozím nastavení nepodporuje transakce ani referenční integritu,jak stojí v [69]. Toto je samozřejmě značná nevýhoda, která se ale dá vyřešit použitím jinéhoukládacího enginu.

PostgreSQL

Ze zdroje [40] a [53] je tato databáze podobně nenáročná na systémové prostředky, jeobjektově orientovanou relační databází, a v základu implementuje referenční integritu atransakce.

Závěr

Jak jste si mohli přečíst výše, tak Oracle XE byl z výběru vyloučen, ale při porovnání MySQLa PostgreSQL už není tak jasné, který je lepší pro použití v daném školním prostředí. I cose týče výkonu, tak (podle [46]) jsou tyto databáze v podstatě vyrovnané.

Jelikož MySQL a PostgreSQL jsou opravdu vyrovnaní, tak v závěru u mě rozhodla obavao budoucnost MySQL po zakoupení firmy Sun firmou Oracle (podobné obavy jako v případěGlassFishe i když v [37] stojí, že MySQL bude podporováno) a taky moje osobní sympatie azkušenosti. Zvolil jsem tedy databázový stroj PostgreSQL. Chci ale znovu upozornit na fakt,že systém používá framework, který umožňuje vyměnit databázi a pouze drobnou úpravoukonfiguračního souboru provozovat celý systém nad jinou databází.

2.2.4 Frameworky

V této kapitole chci analyzovat frameworky, které bylo možné použít a které jsem vybralk použití. Nejprve bych chtěl zodpovědět otázku proč vlastně je dobré použít frameworky.Frameworky jsou v podstatě naprogramované knihovny, specifikované postupy, či oboje do-hromady, které řeší nějaký specifický problém, se kterým se v dané oblasti potýká hodně lidí.Úkolem frameworku je samozřejmě práci co nejvíce zjednodušit. Podle [65] nejsou na systémkladeny žádné speciální požadavky, které by byly ojedinělé ve sféře podobných systémů. Díkytomu návrh a realizace systému SWINPRO nevyžadovaly postupy a programová řešení, kteráby ještě nebyla nikdy vyzkoušena, a tudíž jako rozumný postup pro naplnění požadavků na


systém se pro mě jevilo použít již vyzkoušené principy a knihovny, čili vybrat a nasaditvhodné frameworky.

„Problémů“, které jsem musel brát v potaz při výběru frameworků, bylo několik:

• Je používán objektově orientovaný jazyk, ale relační databáze.

• Nutnost při každé aktualizaci, vytvoření nebo smazání objektu aktualizovat, vytvořitnebo smazat i příslušná data v databázi.

• Jakým způsobem ukládat data do databáze.

• Kdy otvírat a kdy zavírat připojení do databáze.

• Jak udělat propracovaný webový interface, tak aby umožňoval pohodlnou práci uživatelea tak aby byl snadno implementovatelný.

• Jak udělat testy, aby po každém běhu testu se nehromadily další a další data v databázi.

• Jak co nejpohodlněji přistupovat k business objektům z prezentační vrstvy, aby zvolenéřešení zároveň podporovalo rozšiřitelnost a modifikovatelnost.

Toto byl výčet jen základních problému, které byly známy před započetím implementace ak jejichž řešení se zasloužily velkým dílem vybrané frameworky.

Práce s databází

Na začátek bych uvedl, že v této podkapitole jsem čerpal z [39] a tudíž se dále nebudu vkaždé větě odvolávat na tuto literaturu. Ve výčtu problémů, kterým bylo nutno čelit, vícejak polovina uvedených položek souvisí s prací s databází. Problém jako třeba „ jak ukládatobjekty do databáze“ se dal vyřešit objektově relačním mapováním. Byl tedy zapotřebíframework, který umožní elegantním způsobem ukládat objekty do relační databáze. Jakotento framework jsem vybral Hibernate, protože je velice rozšířeným frameworkem protuto problematiku, jak říká [22], a také jsem s ním měl již pozitivní zkušenost. Z dalšíchmožností frameworků vyjmenovaných v seznamu [22] se jako alternativy nabízely TopLinka iBatis, protože Spring (tento framework budu rozebírat později) poskytuje pro tyto dvadalší frameworky také podporu, stejně jako pro Hibernate (viz [42]).

Poněvadž systém byl implementován v Javě verze 1.6 a Hibernate je založen na JPA apodporuje všechny jeho rysy (viz [11] kap. Preface), tak bylo možno použít anotace (anotacese nacházejí v Javě od verze 1.5 viz [52]) definované JPA a tím při implementaci velice ulehčitpráci s psaním konfiguračních souborů. Podle [11] je princip takový, že se vytvoří třídy, kterése mají ukládat do databáze a pak se u těchto tříd pomocí anotací specifikuje, které atributyse mají ukládat a jake vztahy jsou mezi třídou a ukazateli v ní (myšleno vztahy 1:N, M:N)a kdo je vlastníkem teto relace. Na aspektu kdo je vlastníkem relace záleží při konstruovánírelace, aby nedošlo k duplicitám a nebo naopak neuložení relace do databáze.

Po „oanotování“ všech tříd, které se mají ukládat do databáze, už jen stačí pomocíHibernatu a jeho ukládacích mechanismů předat objekt jako parametr příslušné ukládacímetodě a Hibernate se o vše postará sám a naplní příslušné tabulky v databázi. Tak tomu jei u aktualizování a mazání objektů z databáze. Samozřejmě o věci jako je spravování spojení

2.2. TECHNOLOGIE 11

do databáze se programátor nemusí vůbec starat. To všechno zařídí Hibernate a pokud bychtěl programátor podrobnější nastavení Hibernatu, stačí pouze upravit konfigurační soubor.Pro podrobnější nastavení a popis Hibernatu je možné nahlédnout do [39], dále se již nebudupopisem Hibernatu zabývat, pokud to nebude ovlivňovat navržení systému.

Prezentační vrstva

V této podkapitole se budu zabývat výběrem frameworku pro prezentační vrstvu. Jak jižjsem zmínil v seznamu problémů, viz výše, jedním z bodů byl ten, aby webový interfacebyl pro uživatele přívětivý a také „líbivý“. Tomuto řešení se můžu vydat v ústrety již jávýběrem vhodného frameworku pro prezentační vrstvu, který následně umožní využívat jižframeworkem připravené komponenty a nemuset je programovat znovu.

Vybral jsem JSF13 také z důvodů, které uvádí [23]. Jsou jimi: JSF jsou „v podstatě“standardem, integrace s Java vývojovými prostředími a integrovatelnost s Hibernatem aSpringem. Zároveň podle [19] JSF verze 1.2 vyžadují server, který implementuje technologieServlet verze 2.5. Zároveň zmiňuje, že je potřeba servletový kontejner Tomcat ve verzinejméně 6.0. Verzi Tomcatu 6.0 jsem zvolil, a tudíž výběru JSF verze 1.2 nestálo z tohotopohledu nic v cestě. Tento framework pro prezentační vrstvu jsem zvolil ještě před započetímimplementace.

V průběhu implementace se ale ukázalo, že počet hotových komponent, které JSF obsahuje,je nedostačující a prakticky využívaná byla hlavně DataTable a pak políčka pro vstup oduživatele a výstup uživateli. Zároveň se ukázalo, že by přišlo vhod o něco více komponentaby prezentace systému SWINPRO pro uživatele mohla být pestřejší. Z komponent, kterédoposavad scházely byla třeba komponenta, která by podporovala třídění, dále pak komonenta,ve které by se dal realizovat strom (myslím tim datovou strukturu) kategorií, či panelovákomponenta, aby se uživatel nemusel přesouvat mezi celými stránkami, ale mohl pouze„překlikávat“ záložky. Těmito okolnostmi jsem byl donucen zvolit nový framework, kterýby pokud možno byl kompatibilní s JSF, aby se nemusely již hotové stránky předělávat, azároveň poskytoval co nejvíce chybějících komponent.

Jelikož systém SWINPRO už byl ve fázi vývoje, bylo nutné se co nejrychleji rozhodnout avybrat nový framework. Při vybírání jsem využil přednášek předmětu X33EJA o EnterpriseJavě a to konkrétně [43], kde se uvádí, že velice dobrý framework, který tvoří nadstavbu nadJSF, je framework RichFaces. Jak jsem si ověřil v [38] v kapitole „Technical Requirements“,požadavky na server, verzi Javy a verzi JSF byly splněny. Zároveň po shlédnutí možnostítohoto frameworku v [29] jsem byl přesvědčen tento framework nasadit. Menší nevýhodoubylo, že tento framework nebyl integrován do vývojového prostředí NetBeans, ve kterémtým vyvíjel, čili zde nebyla forma nápovědy ze strany NetBeans. Tato nevýhoda ale nemělatakovou váhu, protože na [38] se nachází velice důkladný průvodce pro všechny komponentyz RichFaces frameworku.

Další možný framework pro prezentační vrstvu byl framework GWT14. Jak popisuje [63],tak GWT pracuje na principu, že se prezentační vrstva naprogramuje a odladí v Javě, pak sespustí vestavěný kompilátor v GWT a tento javský kód přeloží do JavaScriptu a zároveň ho

13Java Server Faces14Google Web Toolkit


optimalizuje. Jelikož výsledkem je JavaScript, tak se dá napojit třeba do statické HTML15

stránky nebo do JSP. Zároveň JavaScript, který běží na straně klienta, umožňuje volat javskémetody na straně serveru (samozřejmě po splnění určitých podmínek). Nevýhoda frameworkuGWT je, že nemusí mít všichni uživatelé povolen JavaScript ve svých prohlížečích. Dalšínevýhodou pro mě osobně je fakt, že GWT je pod správou jedné firmy Google a zatím nemátakovou základnu jako JSF. JSF je, jak už jsem zmínil, v podstatě standardem ukrývajícímse pod střechou velké technologie JEE. Rovněž se na JEE specifikaci, vedenou firmou Sun,nabalily softwary třetích stran, které specifikaci implementují jako třeba Hibernate, aplikačníservery a ostatní. Několik nevýhod GWT uvádí [51]. Zmiňuje třeba nestandardní postupintegrace JavaScriptu a také učící křivku, která na začátku jen pozvolně stoupá. Zároveň takynení podle [65] žádný speciální požadavek na vzhled systému SWINPRO, aby uživatelskérozhraní vypadalo jako v případě desktopové aplikace, takže není třeba nuceně volit čistěJavaScriptové webové stránky. Jelikož jsem neměl žádnou osobní zkušenost s GWT a také zvýše zmíněných důvodů jsem GWT nezvolil.

Poslední možností je zajímavý webový framework Vaadin ([32], [59]). Podle mě jehozajímavost tkví v tom, že implementace prezentační vrstvy se velice podobá implementaciprezentační vrstvy při vývoji desktopové aplikace ve Swingu16 Další pro mě příjemnouskutečností je, že hlavní logika se nepřenáší na stranu klienta, ale zůstává na straně serveru.Prezentační vrstva se stejně jako v GWT programuje v Javě a pak se překládá do JavaScriptu(překlad není vždy nutný, protože Vaadin obsahuje již množství předpřipravených komponent),který putuje ke klientovi. Zároveň je příjemné, že tento framework je Java Archive a tak sedá připojit k jakémukoliv projektu. Současně poskytuje možnost integrace se Springem17

(přímo návod lze najít zde [30]). Tento framework jsem nevybral jen proto, že jsem se o němdočetl až po započatí vývoje a to už na něj nebylo vhodné přecházet. Musím přiznat, žepodle zdrojů, které jsem uvedl, se tento framework jeví jako velice zajímavý. Vědět o němdříve, tak bych určitě zvažoval jeho využití.

Integrační framework

Poslední úkol byl vybrat framework, který „zastřeší“ a pomůže propojit celou aplikaci. Nyníje už vybrán framework pro nejnižší datovou vrstvu a pak pro nejvyšší prezentační vrstvua je tedy potřeba framework pro propojení těchto vrstev. Hledal jsem framework, který bynabízel určitou správu objektů a třeba naplňování atributů objektů, aby se programátornemusel starat, kde a jak získat potřebné instance, se kterými by chtěl komunikovat.

Naskytly se mi dva takovéto aplikační frameworky: Spring a Seam. Jak jsem si přečetl v[41] „Seam Vs Spring“, tak se nedá říci, že by jeden z těchto dvou frameworků byl výrazněhorší. Na Springu se mi zamlouvalo, že (podle [41]) spíše propaguje klasické rozdělení navrstvu datovou, business a prezentační. A jelikož jsem měl takovouto představu o systému,že bude striktně rozdělen do těchto tří vrstev a osobně jsem již v minulosti se Springem přišeldo styku, tak jsem se jal získat hlubší informace o Springu.

Jak uvádí [42], tak Spring obsahuje podporu pro Hibernate a JSF. Jak jsem psal o párodstavců výše, tak právě Hibernate bude použit jako objektově-relačně mapující framework

15HyperText Markup Language16Swing je javský framework pro prezentační vrstvu pro desktopové aplikace.17Framework, který systém SWINPRO bude používat, více o něm v nadcházející kapitole.

2.2. TECHNOLOGIE 13

a JSF budou zase použity pro prezentační vrstvu. Jak jsem zmínil v minulé kapitole oprezentační vrstvě, v průběhu vývoje jsem byl nucen vybrat rozsáhlejší framework. Díkytomu, že RichFaces stojí na JSF a Spring spolupracuje s JSF, tak tato změna prezentačníhoframeworku nepřinesla žádné škody.

Jak také uvádí [42], Spring poskytuje technologii zvanou „Inversion of Control“, kterávelice zpříjemnila následnou implementaci. Její kouzlo je v tom, že v konfiguračních souborechnadefinuje programátor, kam se mají které objekty vložit a Spring se o vše postará, aprogramátor se tudíž nemusí starat o způsob, kterým naváže vazby mezi objekty tak, abymohly komunikovat mezi sebou. Dále tuto technologii připomenu, až budu rozebírat jednotlivévrstvy a třídy. Jelikož Spring spolupracuje s JSF, tak v mapování backing bean na konkrétnítřídy ve „faces-config.xml“ stačí přidat atributy těchto tříd, o které se má postarat Spring.On už stejným principem, jako jsem popisoval výše, dodá backing beaně potřebné instancetříd (toto uvádí [42] kap. 15.). Zároveň také stejnojmenný zdroj uvádí, že Spring obsahujepodporu pro JUnit18, který, jelikož je systém programován v Javě, je logickou volbou. Tatopodpora tkví v podpoře transakcí a např. implicitním volání příkazu rollback po každétestovací metodě. Pokud by někoho zajímala problematika testování více, tak odkazuji nabakalářskou práci mého kolegy Michala Strnada [67], která se bude zabývat testovánímsystému SWINPRO.

Další poskytovaná funkčnost Springu, která byla využita, je např. podpora pro aspektověorientované programování (zkratka AOP19). Tato technologie se využila např. pro logovánípři volání metod business vrstvy. Bohužel jsem na tuto technologii Springu narazil až poté, cojsem navrhl systém SWINPRO. Možný přínos této technologie pro návrh diskutuji v kapitole„Zhodnocení provedených rozhodnutí“. Pro základní informace o aspektově orientovanémprogramování odkazuji na [4].

18JUnit je testovací framework pro Javu určen pro testování jednotek.19Anglicky: Aspect-Oriented Programming


Kapitola 3

Návrh řešení

3.1 Úvod

V této kapitole detailněji rozebírám architekturu vlastního systému. Budu se zaměřovat naarchitekturu serveru, protože, jak už jsem se zmínil dříve, jako klient slouží webový prohlížeča ten jako takový nebude implementován. Zároveň chci zmínit, že popis architektury jedoprovázen UML diagramy. Tyto diagramy jsem konstruoval podle informací z [54].

Jako styl architektury jsem zvolil třívrstvou architekturu. Tato architektura předepisujerozdělení na vrstvu datovou (alias databázovou), business vrstvu a prezentační vrstvu.Jmenovaná architektura byla zvolena záměrně, aby se oddělil způsob ukládání dat do databázeod operací, které se budou s těmito daty provádět, a od vlastní prezentace dat uživateli. Totooddělení je dobré, protože v případě změny business (v našem případě školních) podmínekstačí pouze modifikovat danou třídu nebo metodu v business vrstvě (v této vrstvě by mělabýt kontrola těchto podmínek) a třeba datová nemusí být vůbec modifikovaná. Tento návrharchitektury také podporuje soustředění kontrol omezení kladených na data na jedno místoa ne jejich „rozsévání“ po různých místech v aplikaci, které jsou při změně aplikace těžkodohledatelné. Další nespornou výhodou je možnost vyměnit rozhraní pro uživatele nebopopřípadě implementovat další rozhraní. Jelikož tyto rozhraní budou komunikovat se stejnoubusiness vrstvou, tak neporušení omezení na ukládaná data je zaručeno a nemusí každéuživatelské rozhraní mít svoje metody kontroly tohoto dodržení. Samozřejmě že omezenístylu, které znamená, že do celočíselné proměnné nepůjde zadat uživatelem reálné číslo,bude mít každé rozhraní vlastní, ale komplexnější omezení, které vychází z uživatelskýchpožadavků, budou implementovány na jednom místě a to v business vrstvě.

V minulém odstavci zmíněné výhody business vrstvy se samozřejmě v obdobné verzivztahují i na prezentační a datovou vrstvu. Jako se business vrstva stará jen o kontroluomezení kladených na data, tak se prezentační vrstva stará jen o prezentaci. Tudíž aspektyspojené s prezentováním dat by se měly začlenit hlavně do této vrstvy a ne do ostatních.Datová vrstva se zase stará výhradně o komunikaci s databází a žádná jiná vrstva by nemělapřistupovat do databáze přímo, pokud k tomu není vážný důvod.

Postupně v této kapitole zdokumentuji datovou, business a prezentační vrstvu. Jelikož sebudou některé třídy sobě hodně podobat, tak v tomto případě uvedu pro tuto množinu třídtypický vzor, který popíšu podrobně a u ostatních tříd ze shluku uvedu pouze zajímavosti

15

16 KAPITOLA 3. NÁVRH ŘEŠENÍ

nebo odchylky. Zároveň v této bakalářské práci neuvedu všechny diagramy, ale vyberu apodrobně popíši pouze ty, které jsou z mého hlediska stěžejní pro modelování architekturysystému SWINPRO. Všechny diagramy si pak můžete prohlédnout na přiloženém CD.

V podkapitole „Komunikace s okolím“ zanalyzuji komunikaci se systémy Trac a SVN.Nástroje Trac a SVN slouží jako podpora pro výuku softwarových kurzů ve škole a zakládáníasociovaných projektů na těchto nástrojích byl jeden ze základních požadavků, viz [65].

Při popisování zmíním i tu a tam použitý návrhový vzor. O stručných popisech vzorů avýhody, které s sebou přinesly, se rozepíši až na úplný závěr kapitoly.

Znovu připomínám, že v podstatě celá tato kapitola, stejně jako celý návrh, vychází zanalýzy požadavků v [65].

3.2 Datová vrstva

V této kapitole popíši vrstvu, která je nejblíže k databázi z hlediska celé architektury systému.Na obrázku 3.1 můžete vidět rozdělení této vrstvy. Rozdělení odpovídá přesně balíčkům vJavě. V datové vrstvě se nachází 3 balíčky a to balíček pro entity1, „DAO“2 třídy a propomocné komparátory. Označení „DAO“ jsem použil záměrně, protože existuje stejnojmennývzor, který popisuje problém, jak přistupovat k datům na permanentním úložišti. Jelikožmnou označené „DAO“ třídy jsem konstruoval podle tohoto vzoru, tak jsem jim a celémubalíčku přiřadil tento název. Více o tomto vzoru se můžete dočíst třeba na [7].

Obrázek 3.1: Rozdělení doménové vrstvy

Balíček „entity“ obsahuje pouze třídy, které se budou ukládat do databáze. Tyto třídyjsou navrženy co nejjednodušeji a v podstatě by se dalo říci, že slouží jako kontejnery na data,

1Toto je název pro třídu jejíž obsah se bude ukládat do databáze.2Z anglického spojení „Data Access Object“.

3.2. DATOVÁ VRSTVA 17

která potřebuje systém uchovávat pro uživatele, projekty, milníky a ostatní. Tyto entity vsobě neobsahují žádnou výpočetní logiku a zpravidla mají pouze metody „set“ a „get“. Tytoentity záměrně nemají žádné metody, které by prováděly složitější operace s jejich daty.Důvody jsou popsány v úvodu této kapitoly.

Balíček „dao“ obsahuje pouze třídy pro přístup k datům, zde entitám. Čili tyto třídyobsahují metody stylu ulož, načti, vymaž. Zároveň jsou jediným přístupovým bodem kperzistentnímu úložišti, čili se všemi dotazy na načtení objektu či jeho uložení se businessvrstva obrací na tyto objekty a ony požadovaný objekt načtou, aniž by zbytek aplikacemusel vědět odkud. Tento návrh umožní abstrakci většiny části aplikace od konkrétníhoperzistentního média. Nesmírnou výhodou je fakt, že můžete celý „dao.hibernate“ balíčekvyměnit a pokud realizujete příslušné rozhraní, které je v balíčku „dao“ v podbalíčku „facade“,tak si toho žádný objekt používající tyto objekty pro ukládání ani „nevšimne“.

Balíček komparátorů je pouze určen pro třídy nápomocné při řazení kolekcí. Tento balíčekje umístěn do datové vrstvy, protože v podstatě třídění podle ID nebo podle jména, příjmenía uživatelského jména v případě uživatelů je velice spjato se strukturou entitních tříd.

3.2.1 Balíček entity

V této podkapitole rozeberu balíček entity. Na obrázku 3.2 vidíte rozdělení na podbalíčky av každém podbalíčku již konkrétní entitní třídy.

Konkrétní entitní třídy v podbalíčcích jsou celkem nezajímavé a, jak již uvedl výše, sloužív podstatě pouze jako kontejner pro data. Speciální zřetel bych spíše věnoval abstraktní třídě„AbstractEntity“. Tato třída slouží jako předek všech konkrétních entitních tříd. Je tomu tak,že všechny entitní třídy musí mít atribut ID, toto je vynuceno používáním relační databáze aframeworku Hibernate. Jelikož tento atribut bude u všech entit, tak se jeví jako zcela logickéjej umístit do rodiče. Zároveň jsou zde umístěny metody, které rovněž každá entita musívlastnit, a to metody nastavení a získaní ID (tyto metody jsou požadovány Hibernatem)a metoda „equals“. Metoda „equals“ je určena pro rozhodnutí zda jsou dvě instance stejné.Možná se Vám jeví jako podivné, proč je třída abstraktní, když nemá žádné abstraktnímetody. Důvod je prostý. Vytvoření instance od této třídy je nežádoucí, protože logicky nicnepředstavuje (nepředstavuje uživatele, projekt ani nic podobného).

3.2.2 Balíček dao

V této podkapitole rozeberu balíček „dao“. Na obrázku 3.3 vidíte rozdělení na podbalíčky„facade“ a „hibernate“, které obsahují další podbalíčky. Tyto podbalíčky jsou voleny tak, abysdružovaly třídy podobného významu. Zároveň zde vidíte i „IDAOFactory“ a „DAOFactory“,která daný interface implementuje (metody u „DAOFactory“ jsem nezobrazil kvůli přehle-dnosti obrázku). Tato třída je zde proto, aby sem přistupovaly business objekty a získávalyzde konkrétní reference na „DAO“ objekty.

Podbalíček „facade“ obsahuje pouze rozhraní pro třídy, které mají za úkol přistupovat kdatům na persistentním médiu. Tato rozhraní realizují třídy z balíčku „hibernate“. Rozdělenína tyto dva hlavní podbalíčky je uděláno záměrně. Třídy z business vrstvy se odvolávajína tato rozhraní a tudíž nejsou svázány těsně s konkrétní třídou, která toto rozhraní imple-mentuje. To přináší výhodu v podobě toho, že je zde možnost implementovat jiný balíček


Obrázek 3.2: Rozdělení balíčku entity

„DAO“ tříd, které budou ukládat třeba do souborů na disk a v případě, že tyto nové třídyimplementují rozhraní z balíčku „facade“, nemusí v business vrstvě nastat žádná změna,protože rozhraní se nezměnilo, pouze se vyměnila implementace.

Třídy v balíčku „hibernate“ (viz obrázek 3.4) realizují rozhraní z balíčku „facade“. Tytotřídy využívají podpory Springu pro Hibernate a třída „AbstractHibernateDAO“ dědí odtřídy ve Springu jménem „HibernateDAOSupport“. Jelikož všechny „DAO“ třídy musí mítmetody pro vrácení objektu podle identifikátoru a pro vrácení všech objektů, o jejichžukládání, mazání a upravování se daná třída stará, tak tyto dvě metody jsou umístěny doabstraktní třídy „AbstractHibernateDAO“. Tyto dvě metody jsou označeny jako chráněné,takže je využívají pouze potomci. Metody jsou chráněné, protože obsahují dva argumenty,a tím je třída a identifikátor, natož veřejné rozhraní by mělo obsahovat (viz super-rozhraní„IAbstractDAO“) tyto metody bez argumentu třídy. Třída jako argument je zde kvůli Hiber-natu, který potřebuje při načítání všech objektů nebo jen objektu podle identifikátorů znáttřídu objektu. Všechny konkrétní třídy v balíčku „hibernate“ jsou potomky „AbstractHiber-

3.2. DATOVÁ VRSTVA 19

Obrázek 3.3: Rozdělení balíčku dao

nateDAO“. Celý systém balíčku „hibernate“ a „facade“ jsem navrhl tak, že je zde použitagenerika, jak je ostatně vidět z 3.4.

Jelikož třídy z balíčku „dao“ jsou velice podobné, tak bych zde uvedl jeden příklad abychvysvětlil o odstavec dříve rozebírané dědění. Pro demonstraci jsem si vybral část balíčku„project“ z balíčku „hibernate“. Na 3.5 (na diagramu nejsou všechny třídy z balíčku, jelikožpak by diagram byl moc malý a nečitelný) vidíte v horní části rozhraní, ty jsou ze dřívezmiňovaného balíčku „dao.facade“, a v dolní části konkrétní třídy, které realizují tyto rozhraní.

Nejprve bych se vrátil k tématu z předminulého odstavce a to sice k metodám „getById-(long)“ a „getAll()“. Tyto dvě metody využívají chráněné metody svého rodiče, o kterých jsem


Obrázek 3.4: Rozdělení balíčku dao.hibernate

se zmiňoval dříve. Zároveň díky speficikaci generiky rozhraní není návratový typ „T“ resp.„list<T>“, jak je tomu v super-rozhraní „IAbstractDAO“ (viz 3.4), ale jsou zde konkrétnínávratové typy čili „Category“,„Project“ a podobně v případě druhé metody vracející seznam.

Dále samozřejmě rozhraní z balíčků „dao.facade.milestone“, „dao.facade.user“, „dao.facade.request“, „dao.facade.system“ přidávají k metodám zděděným od super-rozhraní „IAbstract-DAO“ další své metody. V případě obr. 3.5 jsou jimi například metody vyhledání projektůpodle zkratky, jména, stavu nebo vyhledání kategorií podle jména. Tyto zmíněné metodypouze slouží k tomu, že z perzistentního média načtou objekty, které splňují dané kritérium,a vrátí je v podobě seznamu nebo jako jednotlivce. Dále nebudu třídy a jejich metody zbalíčku „dao“ rozebírat, protože jejich funkce je, podle mě, intuitivně pochopitelná z jménametody. Co jsem považoval za hlavní, byl systém rozhraní a konkrétních implementací včetněpoužití generiky. Pokud máte zájem o přesnou specifikaci všech metod, tak Vás odkazuji naJavaDoc3 systému SWINPRO. Pro ostatní diagramy z datové vrstvy se můžete podívat na

3Dokumentovací nástroj Javy, který slouží k dokumentování zdrojového kódu komentáři.

3.3. BUSINESS VRSTVA 21

Obrázek 3.5: Výtah tříd z balíčku dao.hibernate.project

přiložené CD.

3.3 Business vrstva

V této kapitole se budu podrobněji zabývat business vrstvou. Do business vrstvy soustředímbusiness procesy, tak jak odpovídají reálnému světu. Za tyto business procesy považujinapříklad založení projektu, schválení projektu, agendu nezbytnou při přijímání členů aostatní. U těchto procesů je nutné postupovat v pevně daném pořadí a i toto pořadí musíbýt v business vrstvě respektováno. Zároveň do této vrstvy soustředím také aplikační logiku.Touto aplikační logikou myslím všechna omezení a testy na data, tak jak je vyžaduje reálnýsvět. Uvedu příklad. Tak třeba uživatel musí mít vždy vyplněný email správnou emailovouadresou. Nebo pouze cvičící (alias supervisor) může schválit projekt a nemůže to udělat nikdoze studentů. Při definování a implementování těchto pravidel, kontrol a procesů vycházímsamozřejmě z [65], protože, jak jsem již uvedl, tyto kontroly omezení a procesy pramení zreality, tudíž z požadavků, které posledně zmíněný zdroj analyzuje.

Základní rozdělení businessové vrstvy jsem navrhl obdobně jako u datové vrstvy. Naobrázku 3.6 můžete vidět rozdělení do dvou hlavních balíčků, „facade“ a „manager“. Stejnějako u datové vrstvy tak balíček „facade“ obsahuje pouze rozhraní. Tato rozhraní specifikujíveřejné metody pro fasády jednotlivých podbalíčků business vrstvy. Balíček „facade“ obsahujepodbalíčky „account“, „projekt“, „server“ a „system“. Úplně totožnou hierarchii balíčku ob-sahuje balíček „manager“ (jak ostatně můžete vidět na 3.7). Tato fasádní rozhraní jsourealizována některými třídami právě z balíčku „manager“. Při návrhu této fasády jsem použil


návrhový vzor Facade4 (podrobněji o tomto vzoru později). Ve všech případech konkrétníchtříd vyšlo, že rozhraní z balíčku „facade“ realizoval přímo konkrétní manažer (můžete sivšimnou na obr. 3.8) a čili zde není žádná speciálně vyčleněná fasádní třída, která bydelegovala volání do vnitřku balíčku, jak říká vzor Facade. Tohoto jsem nedociloval záměrně,ale samotné manažerské třídy mají veřejné rozhraní natolik komplexní, že není důvod vsunovatještě další třídu do cesty komunikace. Jelikož je fasáda vůči okolí specifikována rozhraním,nic nebrání tomu, aby se při dalším rozvoji systému SWINPRO vyčlenila speciální třída proúlohu fasády. Pokud tato nová fasádní třída realizuje předepsané rozhraní, tak okolí nemusíbýt vůbec ovlivněno touto záměnou.

Obrázek 3.6: Rozdělení balíčku business

Na obrázku 3.7 můžete vidět rozdělení business vrstvy balíčku „manager“. Jak si můžetevšimnout, rozdělení do balíčků je podobné jako ve vrstvě datové (obr. 3.3). Toto rozčleněnínení samozřejmě úplně shodné, protože třídy entitní sdružují data, kdežto třídy businessovésdružují hlavně metody a funkčnost. Například není samostatná třída pro kontakt člena,ale tato funkčnost je poskytována třídou „AccountManager“, protože kontakt vždy musípatřit nějakému členovi. Nicméně jsem se snažil udělat rozčlenění tak, aby odpovídalo logickéstruktuře poskytovaných funkc, a tím aby přispívalo k orientaci v programu jak při imple-mentaci, tak i pro případné další týmy, které by tento systém do budoucna rozvíjely neboupravovaly.

Takže balíček „account“ je určen pro business třídy (nebo chcete-li manažery), kteréposkytují funkčnost spojenou s uživatelským účtem. Mezi touto funkčností by mohlo být:přidání uživatele, přidání kontaktu, změna práv uživatele, změna pouze profilu uživatele aostatní.

Do balíčku „project“ jsem sdružil třídy, které poskytují funkčnost vázanou na projekt. Čilimanažery pro tikety a milníky jsou v tomto balíčku, protože souvisí s některým projektem.

Balíček „system“ obsahuje manažery pro funkce, které souvisí s celým systémem. Podle[65] jsou kategorie jedny napříč celým systémem a privátní štítky jsou pro každého supervisorazvlášť, a proto jsem tyto dva manažery vyčlenil do tohoto balíčku.

Na konec v balíčku „server“ jsou manažery, které zprostředkovávají funkcionalitu serverůse kterými systém SWINPRO spolupracuje. Těmito servery jsou Trac, SVN a emailový server(ten je potřeba pro upozornění uživatelů na některé události, viz [65]). Z požadavků v [65]

4Česky Fasáda.


Obrázek 3.7: Rozdělení balíčku business.manager

tyto manažery poskytují funkce, jako třeba vytvoření repozitáře na SVN, založení projektuna Trac s přístupovými právy členů týmu a ostatní.

3.3.1 Balíček server

V této kapitole blíže popíšu balíček „server“. Tento balíček jsem musel rozdělit do vícediagramů z důvodu přehlednosti.

Na obrázku 3.8 vidíte třídu „ToolServerManager“ (veřejné metody jsou skryty z důvodupřehlednosti) pro spravování nástrojů (Trac, SVN atd.) se kterými systém SWINPRO musíspolupracovat. Tato třída slouží pro přidávání, odebírání, upravování a získávání dostupnýchnástrojů v systému SWINPRO. Jelikož je toto business třída, tak při těchto operacíchkontroluje, jestli nově přidávaný, potažmo změněný už existující, server splňuje všechnakritéria a pokud ano, tak vykoná požadovanou operaci.

Třída „ToolServerFunctionManager“ (veřejné metody jsou skryty z důvodu přehlednosti)na obr. 3.8 zprostředkovává funkce externích nástrojů (Trac, SVN atd). Těmito funkcemi,jsou například přidávání milníků, tiketů do nástroje na správu požadavků (např. dřívezmíněný Trac). Další funkce jsou otevření nebo uzavření projektu na externím nástroji.Přičemž těmto metodám se musí předat výčtový typ nástroje, kde se má uzavřít, respektiveotevřít, asociovaný projekt.

Další třídou je zde „ToolServerFactory“. Tato třída je konstruovaná s využitím návrhovéhovzoru Factory method. Slouží pouze k tomu, aby se na ní obracela třída „ToolServerFunction-Manager“ pokud chce získat objekt, který přímo bude komunikovat s externím nástrojem(tyto třídy jsou na obr. 3.9). Tato továrna dále podle svého uvážení vytvoří a připraví


Obrázek 3.8: První část balíčku business.manager.server

adekvátní objekt a vrátí ho jako typ rozhraní „IBTSServerBo“ potažmo „ISCMSystemServer-Bo“. Tímto je dosaženo, že „ToolServerFunctionManager“ se nemusí starat o to, jestli komuni-kuje s SVN repozitářem, či jakýmkoliv jiným nástrojem sloužícím pro verzování kódu (stejnětomu je v případě TRACu a jakýmkoli jiným systémem pro správu požadavků).

Styl návrhu „ToolServerFactory“ zároveň umožňuje, že se dají lehce vyměnit továrnítřídy. Poskytuje také prostor se až později rozhodnout, zda se bude pokaždé vytvářet nováinstance modulu komunikujícího s externím nástrojem, či se zde použije návrhový vzor Pool5

5Tvořivý návrhový vzor. Česky „Bazén“.


a jednotlivé instance se budou recyklovat. Návrhový vzor Pool jsem nechal pro pozdějšíuvážení, protože podle mého názoru se jedná spíše o vzor, který je dobré použít až ve fázioptimalizace nebo pokud bych už předem věděl, že vytváření instancí bude drahá záležitost.Jelikož předčasná optimalizace není dobrá, tak je zde pouze připraveno prostředí pro možnépozdější začlenění tohoto vzoru.

Dále jsou na obr. 3.8 uvedená dvě rozhraní „IToolServerFunctionFacade“ a „IToolServer-Facade“ z balíčku „business.facade“. Jak jsem již dříve zmínil, tato dvě fasádní rozhraní jsourealizována přímo třídami „ToolServerFunctionManager“ respektive „ToolServerManager“.Nic ale nebrání tomu, aby při růstu tohoto balíčku byla tato rozhraní realizovány speciálněvyčleněnými třídami.

Obrázek 3.9: Druhá část balíčku business.server

Obrázek 3.9 znázorňuje hierarchii rozhraní, které budou realizovat třídy komunikujícís externím nástrojem (např. Trac, SVN atd.). Tato rozhraní předepisují funkce, které byměly zmíněné třídy implementovat. Do rozhraní „IToolServerBo“ jsem vyčlenil funkce, kteréjsou společné jak pro rozhraní pro správu kódu, tak i pro rozhraní pro systém správypožadavků. Rozhraní „ISCMServerBo“, dědící od rozhraní „IToolServerBo“, dále přidávámetody specifické jen pro systémy pro správu zdrojového kódu. Rozhraní „IBTSServerBo“,


dědící od rozhraní „IToolServerBo“, dále přidává metody specifické jen pro systémy prosprávu požadavků.

Dříve než popíšu jednotlivé metody rozhraní „ISCMServerBo“ a „IBTSServerBo“, takdefinuji obecné kategorie přístupových práv, poněvadž při popisu metod se na ně buduodkazovat.

omezená práva pouze pro čtení Tato práva budou pro uživatele v BT6 systému znamenatpouze možnost prohlížení již vytvořených dokumentů, stránek, tiketů a milníků. V SCMsystému bude toto znamenat pouze možnost stahování souborů z repozitáře.

plná práva Tato práva budou znamenat pro BT systém možnost zakládání/mazání/měněnístránek, tiketů a milníků. Pro SCM systém toto bude znamenat, že uživatel bude mocistahovat, vytvářet, měnit a mazat obsah repozitáře.

Rozhraní „ISCMServerBo“ má tyto metody:

• createProject(): void - Metoda založí repozitář a nastaví přístup pro členy týmu.Přístupová práva pro členy týmu budou nastavena na plná práva. Pokud se metoděnepodaří založit repozitář nebo přidělit práva, tak vyvolá výjimku.

• deleteAllFiles(): void - Metoda smaže všechny soubory v repozitáři. Po skončení tétometody by neměl v repozitáři zůstat žádný soubor. Pokud nastane chyba, tak metodavyvolává výjimku.

• download(): String - Metoda stáhne a zabalí aktuální obsah repozitáře na server, kdeběží systém SWINPRO. Vrátí textovou hodnotu cesty k archivu, kam byl uložen azabalen obsah repozitáře. V případě neúspěchu metoda vymaže nekompletní archiva vyvolá výjimku. Návratová hodnota NULL neznačí neúspěch stahování, čili tatohodnota by se neměla nikdy vrátit.

• moveTo(ToolServer): void - Metoda zkopíruje obsah aktuálního repozitáře do novéhorepozitáře, který je předán metodě jako parametr. Tento přesun bude realizován naúrovni souborového systému, nikoliv speciálními prostředky systému pro správu zdro-jového kódu. Po skončení metody bude jak na starém tak na novém serveru stejnýobsah včetně přístupových práv pro členy týmu. Pokud nastane v průběhu chyba,metoda se pokusí vymazat nekompletní nový repozitář, a dočasné soubory potřebnépro přenos a následně vyvolá výjimku.

• replicate(ToolServer): void - Metoda zkopíruje obsah aktuálního repozitáře do novéhorepozitáře, který je předán metodě jako parametr. Tato kopie bude realizována prostře-dnictvím specifických nástrojů pro daný SCM7. Metoda nemusí být implementována,protože každý SCM nemusí tuto možnost umožňovat, pak ale musí vyhazovat výjimku.Po skončení metody bude jak na starém tak na novém serveru stejný obsah. Pokudnastane v průběhu chyba, metoda se pokusí vymazat nekompletní nový repozitář, adočasné soubory potřebné pro přenos a vyvolá výjimku.

6Zkratka k „Bug Tracking“7Source Code Management. Anglická zkratka pro systému pro správu zdrojového kódu


• uploadDirectoryTree(String): void - Metoda nahraje obsah archivu do repozitáře. Tex-tový parametr udává cestu k archivu, se kterým se má pracovat. Rozbalení souborumůže proběhnout lokálně nebo až na vzdáleném počítači. Po skončení této metody budemít repozitář strukturu a zároveň bude obsahovat soubory ekvivalentně k původnímuarchivu. Zároveň musí být vymazány všechny soubory, které byly vytvořeny toutometodou jako pomocné. Původní archiv tato metoda nemaže. Pokud nastane v průběhunahrávání obsahu chyba, metoda se pokusí vymazat již nahranou část archivu a všechnydočasně vytvořené soubory, a pak vyvolá výjimku.

Rozhraní „IBTSServerBo“ má tyto metody:

• addMilestone(Milestone): void - Metoda přidá milník, který má jako parametr, aso-ciovanému projektu na systému pro správu požadavků. Po skončení metody bude naexterním projektu přidán danému projektu milestone nebo metoda skončí vyvolánímvýjimky.

• addTicket(Ticket): void - Metoda přidá tiket, který má jako parametr, asociovanémuprojektu na systému pro správu požadavků. Po skončení metody bude na externímnástroji přidán danému asociovanému projektu tiket nebo metoda skončí vyvolánímvýjimky.

• closeProject(): void - Metoda nastaví na systému pro správu požadavků pro konkrétníasociovaný projekt omezená práva pouze pro čtení pro všechny jeho členy. Pokud semetodě nepovede nastavit tato práva pro všechny členy, vyvolá výjimku. Pokud senepovede odebrat práva z důvodu neexistence uživatelského účtu, metoda výjimkunevyvolává.

• createProject(): void - Metoda vytvoří asociovaný projekt na externím nástroji anastaví práva pro přístup všem členům projektového týmu na externím nástroji. Právapro přístup budou nastavena na hodnotu plná práva. Pokud se metodě nepovedevytvořit asociovaný projekt na externím nástroji nebo se nepodaří nastavit práva provšechny členy týmu, tak metoda vyvolá výjimku.

• deleteMilestone(Milestone): void - Metoda vymaže milník, který dostala jako parametr,z asociovaného projektu ze systému pro správu požadavků. Pokud jsou tomuto milníkupřiděleny tikety na externím nástroji, tak metoda vyvolá výjimku. Pokud milník nee-xistuje na externím nástroji, tak metoda regulérně skončí a výjimku nevyvolává.

• deleteProject(): void - Metoda smaže asociovaný projekt ze systému pro správu po-žadavků. Po skončení této metody musí být asociovaný projekt na externím nástrojizcela vymazán. V opačném případě metoda vyvolá výjimku.

• deleteTicket(): void - Metoda smaže tiket, který dostala jako parametr, z asociovanéhoprojektu ze systému pro správu požadavků. V případě, že tiket na externím nástrojinení, tak metoda regulérně skončí a výjimku nevyvolává. V ostatních nečekanýchpřípadech metoda vyvolá výjimku.

• grantPrivilages(User): void - Metoda přidělí práva uživateli, kterého dostala jako para-metr, v asociovaného projektu v systému pro správu požadavků. Tato práva odpovídají


nastavení plná práva. Tato práva se samozřejmě mohou v závislosti na externím systémumírně lišit. V případě, že se nepovede práva přidělit, tak metoda vyvolá výjimku.

• moveTo(ToolServer): void - Metoda zkopíruje obsah náležící danému asociovanémuprojektu z aktuálního systému pro správu požadavků na jiný nový systém pro správupožadavků. Po skončení metody se musí na obou systémech, jak novém, tak starém,nacházet stejná data včetně přístupových práv. Metoda smaže po svém skončení (i vpřípadě výjimky) všechny dočasné soubory, které vytvořila pro potřebu kopie. Metodanesmaže obsah na původním externím nástroji. Pokud při vykonávání metody nastanenečekaná událost, metoda po sobě smaže dočasné soubory a nekompletní obsah nanovém externím úložišti a vyvolá výjimku.

• openProject(): void - Metoda nastaví na systému pro správu požadavků pro konkrétníasociovaný projekt plná práva pro všechny jeho členy. Pokud se nepovede nastavenípráv pro všechny členy, metoda vyvolá výjimku.

• revokePrivilages(User): void - Metoda odstraní práva uživatele pro přístup do asociova-ného projektu v systému pro správu požadavků. Po skončení metody uživatel musí mítpráva v rozsahu omezená práva pouze pro čtení. Pokud uživatel nebude na externímnástroji existovat a tudíž mu nebudou moci být ani práva odebrána, tak metoda skončíregulérně.

V balíčku „business.manager.server“ jsou ještě třídy pro odesílání emailů a pomocnýbalíček „util“, který rozebírá podrobněji práce kolegy [68]. Rovněž pokud by Vás zajímalakonkrétní implementace „ISCMServerBo“ a hlubší rozbor problematiky systému pro správuzdrojového kódu, tak rovněž odkazuji na [68]. Uvádění tříd pro emaily na tomto místě měpřipadá zbytečné. Pokud si je chcete prohlédnout, diagramy jsou v příloze. Pro podrobnýpopis metod odkazuji na JavaDoc systému SWINPRO. Jediný aspekt, který je podle měv této souvislosti zajímavý, je zmínění, že odesílání emailů je uděláno pomocí spuštěníspeciálního vlákna, které email odešle. Původně tento proces nebyl realizován vláknem, ale připilotním provozu vyšlo najevo, že komunikace s poštovním serverem zpomaluje celý systém.Proto jsem pozměnil architekturu a pro odeslání emailu je použito samostatné vlákno.

3.3.2 Balíček project

Balíček „project“ jsem rozdělil do dvou diagramů z důvodu přehlednosti.Na obr. 3.10 vidíte třídy „TicketManager“, „MilestoneManager“ a „ProjectManager“8.

„TicketManager“ se stará o tikety v systému SWINPRO a o propojení na daný systémpro správu požadavků. Tato třída volá metody třídy „ToolServerFunctionManager“. Třída„MilestoneManager“ se stará o milníky, jak v systému SWINPRO, tak i o propojení na danýsystém pro správu požadavků. I tato třída využívá služeb třídy „ToolServerFunctionManager“.U tříd „TicketManager“ a „MilestoneManager“ jsem nezobrazil soukromé atributy v diagramu,poněvadž by přispěly k jeho znepřehlednění. Jelikož obsahují podobné atributy jako „Project-Manager“, tak podrobně popíšu pouze třídu „ProjectManager“, která mi připadá i z hlediskametod nejzajímavější k popisu.

Třída „ProjecManager“ obsahuje atributy:8U této třídy jsem skryl veřejné metody definované rozhraním


Obrázek 3.10: První část balíčku business.manager.project

• projectDAO: IProjectDAO - Tento atribut je typu „IProjectDAO“ a ukazuje na kon-krétní instanci třídy, která daný interface implementuje. Tento atribut je využíván prozískávání objektu typu „Project“ z perzistentního média.

• privateTagDAO: IPrivateTagDAO - Tento atribut je využíván pro získávání objektůtypu „PrivateTag“ z perzistentního média.

• distributedPointDAO: IDistributedPointDAO - Tento atribut je využíván pro získáváníobjektů typu „DistributedPoint“ z perzistentního média.

• requestManager: RequestManager - Tento atribut je využíván při požádání o schválenía i při samotném potvrzení/odmítnutí schválení projektu supervisorem. V této fázi jenutno pracovat i se samotnou žádosti a to se děje prostřednictvím tohoto atributu. Zdejsem nepoužil jako typ rozhraní, protože se jedna o vazbu v rámci balíčku.


• toolServerFunctionManager: IToolServerFunctionFacade - Tento atribut je využívánpro volání metod daného objektu, když je potřeba komunikovat s externími nástroji.Tato nutnost je například ve chvíli schválení projektu, či jeho mazání. Typ tohotoatributu je rozhraní, protože se jedná o komunikaci napříč balíčky. Rozhraní „ITool-ServerFunctionFacade“ obsahuje poskytované funkce externích nástrojů a poněvadžpočítám s budoucím přibýváním dalších externích nástrojů, tak typ rozhraní se mi zdejeví jako lepší varianta.

• sendEmailManager: SendEmailBo - Tento atribut je použit pro rozesílání upozorňova-cích emailů.

Jak jste si mohli všimnout, všechny „DAO“ ukazatele jsou typu rozhraní. Je tomu takzáměrně, protože toto řešení umožňuje změnit implementaci a uchovávat data ne pouzev databázi, ale třeba v souborech nebo kdekoliv, kde se zákazníkovi zlíbí. Pokud nováimplementace realizuje dané rozhraní z balíčku „dao.facade“, tak nic nebrání tomu přepsatkonfigurační soubory Springu a vložit do těchto ukazatelů jiné instance konkrétních tříd.

V této fázi se využije Spring, konkrétně jeho technologie „Inversion of Control“, a pomocíkonfiguračních souborů se specifikuje jaký ukazatel se má naplnit kterou konkrétní instancítřídy. Následkem toho odpadne starost programátora, kde, čím a jak naplňovat ukazatele na„DAO“ objekty. Toho postupu je využito ve všech manžerech pro „DAO“ objekty a ve všechbacking beanách pro business objekty (čili manažery).

Jako další uvedu veřejné metody třídy „ProjectManager“. Až na poslední tři jsou to imetody definované rozhraním „IProjectFacade“:

• getProjects(): List<Project> - Metoda vrátí seznam všech projektů, které se nacházív systému SWINPRO.

• refreshProject(Project): Project - Metoda obnoví project, který ji je předán jako atribut.Používá se když je potřeba obnovit stav projektu z databáze.

• getMemberProjectsByStates(ProjectStateEnum[],User): List<Project> - Metoda vrátíseznam členských projektů uživatele, který ji je předán jako druhý parametr. Zároveňtyto členské projekty jsou v jednom ze stavů, které jsou předány jako první parametrmetody. Možná se Vám zdá zbytečné kvůli třídění projektů uživatele volat metodubusiness třídy. Proč data rovnou neprotřídit třeba v prezentační vrstvě? Je to z tohodůvodu, že v této metodě si mohu vybrat jestli budu třídění provádět v paměti a nebojestli zavolám nižší vrstvu. Pokud budu volat nižší vrstvu, tak třídění připadne v tomtopřípadě na databázi. K této úvaze mě vedla skutečnost, že databáze jsou optimalizovanétaké pro vyhledávání.

• getAllProjectsByStates(ProjectStateEnum[]): List<Project> - Metoda vrátí list všechprojektů v sytému SWINPRO, které zároveň jsou v jednom z určených stavů.

• getSupervisorProjectsByStates(User, ProjectStateEnum[]): List<Project> - Metodavrátí seznam vedených projektů uživatelem, který je předán jako první parametr.Zároveň tyto vedené projekty jsou v jednom ze stavů, které jsou předány jako druhýparametr metody.


• setToolServersToProject(List<ToolServer>, Project): void - Metoda přiřadí externínástroje, předané jako první parametr, projektu, který je předán jako druhý parametr.Přiřazování se děje prostřednictvím této metody, protože zde lze zkontrolovat napříkladkolik serverů se přiřazuje.

• closeProject(User, Project): void - Metoda uzavře projekt a postará se o zavolánídalších metod pro uzavření asociovaných projektů na externích nástrojích, které projektvyužívá. Uživatel, který je předá jako první parametr, je iniciátor akce. Předává se dometody proto, aby se zjistilo, zda může danou akci iniciovat.

• createProject(User, Project): void - Metoda zkontroluje atributy projektu a pokudvyhovují, tak založí projekt.

• updateProject(Project): void - Metoda aktualizuje stav projektu do databáze.

• deleteProject(User, Project): void - Metoda vymaže projekt a rovněž se postará ozavolání potřebných metod pro vymazání asociovaných projektů na externích nástrojích.Uživatel jako parametr je předán znovu z důvodu ověření, jestli uživatel smí tuto akciprovést.

• approveProject(Project, User, ProjectApprovalRequest, String): void - Metoda zařídíschválení projektu a založení asociovaných projektů na externích nástrojích, které chceprojekt využívat. Textový parametr předávaný metodě slouží jako odpověď na žádosto schválení. Uživatel jako parametr je z důvodu ověření, že on smí tuto akci provést.Žádost předávaná jako parametr „ProjectApprovalRequest“ je předávaná proto, abyse změnil její stav a uložila se odpověď na tuto žádost. Nejpodstatnější požadavek natuto metodu je, že musí být atomická. Tento požadavek na metodu znamená, že buďmusí projít všechny změny, která tato metoda udělá, nebo musí být všechny změnyprovedeny touto metodou vráceny do původního stavu.

• rejectApproval(User, ProjectApprovalRequest, String): void - Metoda zařídí odmítnutížádosti o schválení a nastaví projekt do stavu před podáním žádosti. Uživatel jakoparametr je z důvodu ověření, kdo tuto metodu volá a jestli jí smí zavolat. Textováhodnota předávaná jako třetí parametr je text odpovědi uživatele, který žádost zamítá.„ProjectApprovalRequest“ je proto, aby se uložila odpověď na tuto žádost a zároveňse zaznamenalo datum, kdy byla žádost vyřízena.

• requestApproval(User, Project, String): void - Metoda se stará o podání žádosti oschválení projektu. Uživatel (jako první parametr) slouží k ověření iniciátora metody.Projekt (jako druhý parametr) je projektem, pro který má tato žádost být vytvořena,a třetím parametrem je text žádosti. Metoda zároveň zaznamená datum vytvořenížádosti.

• assignTag(PrivateTag, List<Project>): void - Metoda přiřadí soukromý štítek (prvníparametr) všem projektům ze seznamu (druhý parametr).

• unassign Tag(PrivateTag, List<Project>): void - Metoda odebere soukromý štítek(první parametr) všem projektům ze seznamu (druhý parametr).


• distributePoints(User, Map<User,DistributedPoint>, Milestone, Project): void - Meto-da se stará o rozdělování bodů mezi členy projektového týmu. Informace o tom kdo mádostat kolik bodů je uložena v mapě, předané jako druhý parametr. Zároveň tyto bodymusí být rozděleny za určitý milník, ten je jako třetí parametr. Projekt, jako posledníparametr, je předán, aby bylo možné zkontrolovat, že si členové nepřerozdělují vícebodů než dostali a zároveň, že v mapě jsou pouze členové projektu. Uživatel jako prvníparametr je znovu pouze pro ověření, jestli smí nebo nemůže o tuto akci žádat.

• isProjectActive(Project): boolean - Metoda vrací pravdivostní hodnotu, jestli projektje nebo není v aktivním stavu, čili stavu po schválení. Tuto metodu jsem udělal proto,aby se v budoucnu mohla změnit definice termínu, kdy je projekt aktivní a nemusel seměnit kontrolní kód na více místech programu.

• canProjectBeChangedByTeamMember(Project): boolean - Metoda vrací pravdivostníhodnotu, zda může vedoucí projektu měnit projekt předaný jako parametr.

• canProjectBeChangedBySupervisor(Project): boolean - Metoda vrací pravdivostní ho-dnotu, zda může supervisor projektu měnit projekt předaný jako parametr.

• canExecutingUserChangeProject(User, Project): boolean - Metoda vrací pravdivostníhodnotu, zda může uživatel předaný jako první parametr měnit projekt předaný jakodruhý parametr.

Nejspíše Vás zaujme, proč v některých metodách „ProjectManager“ je jako parametrpředáván uživatel (ten který danou metodu volá) a v některých tomu tak není. Je tomu takz důvodu, že v první fázi jsem navrhl metody business tříd bez parametru uživatele. Nicméněpo započatí implementace se ukázalo, že toto nebylo dobré řešení, protože totožnost a právauživatele by musela ověřovat prezentační vrstva. Z tohoto důvodu jsem pozměnil návrh apřidal parametr uživatele. Jelikož již některé části business tříd byly implementovány, takzměna zasáhla ještě neimplementované metody a již implementované metody, které bylypodle mého uvážení kritické z hlediska nutnosti ověřit iniciátora operace.

Na obrázku 3.11 se nachází zbytek tříd z balíčku „business.manager.project“. Třída „Mem-bershipManager“ obstarává záležitosti týkající se členství (opuštění, vyhození člena) a předá-vání funkcí vedoucího týmu a supervisora. Přijímání členů není v této třídě zahrnuto, jelikožpodle [65] je nutné, aby před přidáním člena do týmu proběhla určitá agenda. Touto agendoumám na mysli podání a schválení pozvánky či žádosti o členství.

O pozvánky a žádosti o členství se stará třída „RequestManager“ (skryl jsem u ní atributya veřejné metody). K této funkčnosti ještě přidává správu žádostí o schválení projektu. Provšechny typy žádostí (včetně pozvánek) poskytuje funkce pro podání, schválení a odmítnutí.Pro žádosti ovlivňující složení týmu poskytuje i přímé vymazání žádosti, čili v reálném světěje toto ekvivalentní stažení žádosti odesílatelem.

„RequestManager“ má ještě metody na filtrování těchto typů žádostí podle stavu. Důvod,proč jsou tyto metody zde a ne v prezentační vrstvě, je stejný jako ten, který jsem popisoval utřídy „ProjecManager“ a její metody „getMemberProjectsByStates(ProjectStateEnum[],User)“.

3.4. PREZENTAČNÍ VRSTVA 33

Obrázek 3.11: Druhá část balíčku business.manager.project

3.4 Prezentační vrstva

Tuto vrstvu nebudu již rozebírat tak, jako vrstvy předchozí. Pouze zde nastíním z jakýchčástí se skládá a taky uvedu ukázku příkladu komunikace skrze všechny vrstvy. Tuto ukázku


jsem si záměrně nechal nakonec do kapitoly o prezentační vrstvě, protože tato komunikaceje v naprosté většině případů zahájena uživatelem právě prostřednictvím prezentační vrstvy.

Prezentační vrstva se skládá ze samotných stránek a java tříd (budu je označovat jako„backing beany“), které obsahují atributy, které má stránka zobrazit. Následně backing beanapřistupuje do business vrstvy, kde volá metody manažerů popsaných v kapitole předchozí atěmto metodám předává informace získané od uživatele.

Jelikož samotné stránky a backing beany nejsou z mého pohledu až tak zajímavé, radějizde popíši komunikaci, jak probíhá od uživatele až po databázi.

3.4.1 Komunikace

Na obrázku 3.12 je schéma komunikace od uživatele až po datovou vrstvu, která pak přistupujedo databáze (samozřejmě v tomto případě skrze Hibernate). Komunikaci jsem zobrazil úmy-slně takto symbolicky bez konkrétních objektů, protože schéma platí vždy pouze se měnístránky, objekty a ostatní. Tuto komunikaci započíná uživatel svým požadavkem, kterýodešle prostřednictvím webového prohlížeče například stiskem tlačítka. Než se požadavekdostane k samotné stránce neboli servletu (každá stránka se překládá do servletu jak uvádíslide č. 9 z [44]), tak musí projít filtry. Jak uvádí [45], filtry se zřetězí v tom pořadí, v jakém sezapíší do konfiguračního souboru „web.xml“. Zároveň zmiňovaná literatura uvádí, že pomocífiltrů se dá měnit obsah nebo zabezpečovat přístup ke stránce. V obr. 3.12 jsem úmyslněneuvedl všechny filtry, protože by se obrázek stal moc dlouhým a nebyl by čitelný. Takžepo přefiltrování dotazu se konečně požadavek dostává ke stránce. Stránka naplní atributybacking beany (podle schéma životního cyklu JSF z [43] slide č. 25), jejíž data zobrazuje apokud se jedná o případ „stisknutého tlačítka“, tak následně vyvolá některou metodu backingbeany (v tomto hypotetickém příkladě metodu přidruženou k tlačítku). Z volané metody vbeaně se zavolá metoda některého z manažerů se sesbíranými informacemi od uživatele. Tytoinformace můžou být ku příkladu texty, které uživatel vyplnil do textových polí. Metodamanažeru bude zpravidla některé objekty aktualizovat, vytvářet nebo mazat a tak se musíobrátít na příslušný „DAO“ objekt pro uložení, získání, smazání nebo modifikování objektuna persistentním úložišti.

Tento postup, který jsem popsal platí pro případ, že uživatel vyvolá akci (např. stiskemtlačítka, odešle na server formulář). V případě, že si pouze chce stránku zobrazit, tak backingbeana bude získávat data od manažeru k zobrazení při svém konstruování a manažer budevolat od „DAO“ objektu pouze metody k získání objektů, nikoliv k jejich změně.

Výše popsaný případ probíhá, když jde všechno ideálně, tudíž uživatel je oprávněný kúkonu, který chce provést. Pokud není oprávněný, tak může nastat několik možností. Zaprvé jeho požadavek při průchodu filtry vyustí v přesměrování na úvodní stránku, kde sebude míti přihlásit. Další možností je, že volání dojde až do manažeru a tam se zjistí, ževykonávající uživatel, který byl předán jako parametr, nemá oprávnění akci provést a tudížmetoda vyvolá výjimku. Výjimka bude v backing beaně zachycena, přeložena a následnězobrazena uživateli.

Na obrázku 3.13 jsem rozvedl jednotlivé filtry, které se na obrázku 3.12 skrývaly podpojmem „filtry“. Abych byl korektní, tak první a třetí filtr nejsou přímo javské objekty, aletento schématický název mi připadl lépe pochopitelnější, než kdybych tam uvedl přímo jménotřídy, které není zcela vypovídající.

3.4. PREZENTAČNÍ VRSTVA 35

Obrázek 3.12: Schéma zpracování požadavku od uživatele

Filtr jménem „RichFacesFilter“ je filtr nutný pro funkci frameworku RichFaces a konkrétnítřída je obsažena uvnitř frameworku. Filtr „OpenSessionInViewFilter“ je objekt sloužící prootevření session do databáze. Jelikož je to filter a podle [45] vstupuje mezi klienta a servlet,tak je v tomto případě zaručeno, že spojení do databáze se otevře ještě před vlastnímvykonáváním stránky a zavře po dokončení vykonávání. Čili tento filtr odboural starosto to kdy otvírat a zavírat spojení do databáze. Filtr „MyFacesExtensionFilter“ zase nenípřímo jméno třídy, ale pouze zástupný název pro funkci, kterou tento filtr vykonává. Je tofilter od frameworku MyFaces. Tento prezentační framework bylo nutno dodat do systémuv průběhu vývoje. Je použita pouze jediná jeho komponenta a to komponenta pro nahránísouboru na server. Tento framework jsem nerozebíral v kapitole frameworky, protože jakjsem již uvedl, nebyl stěžejní a byl použit pouze pro nahrání souboru na serveru, jelikož sevyskytly problémy s nahrávací komponentou od RichFaces. Posledním členem, který filtrujekomunikaci je „LoginListener“. V jeho názvu je slovo „listener“, protože je definovaný jako„phase listener“ v konfiguračním souboru pro JSF. Ale jak stojí v [20], „phase listener“je funkčně ekvivalentní filtru a proto jsem ho zahrnul do filtrů, protože jeho hlavní úkolje filtrovat uživatele, kteří jsou přihlášeni a mohou přistupovat na stránky a kteří nejsoupřihlášeni a nebude jim stránka zobrazena. Pro podrobnější popis třídy „LoginListener“odkazuji na práci mého kolegy [60], který se zabývá podrobně metodami přihlašování ksystému SWINPRO.


Obrázek 3.13: Schéma průchodu požadavku od uživatele skrze filtry

3.5 Komunikace s okolím

V této kapitole nastíním externí systémy, se kterými musí systém na řízení projektů spolu-pracovat.

Podle mě nejvíce vypovídajícím diagramem je diagram nasazení. Na diagramu 3.14 vidíteschéma nasazení systému SWINPRO (v diagramu označený jako „SWINPRO.war9“) ve škole.Jak je patrné z obrázku, systém běží na serveru Tomcat a je připojen k databázi PostgreSQL.Na diagramu je databáze PostgreSQL na tomtéž stroji jako Tomcat, ale toto není podmínkou.Uživatel se připojuje k Tomcatu pomocí protokolu HTTP/HTTPS. Použití nešifrované resp.šifrované varianty protokolu HTTP záleží na nastavení Tomcatu. Systém SWINPRO sepřipojuje pomocí zabezpečeného připojení SSH10 na server, kde se zakládají SVN repozitářea projekty v TRACu. Více se tu o komunikaci mezi systémem pro správu projektů a SVN,potažmo TRACem, rozepisovat nebudu, protože toto není primárně náplní této bakalářsképráce.

Na diagramu 3.14 je zobrazeno propojení systému SWINPRO s konkrétními externímisystémy TRAC a SVN. Obecně může být systém SWINPRO propojen s jakýmikoli externímisystémy pro správu zdrojového kódu a správu požadavků, pokud budou do systému SWIN-PRO začleněny ovládací moduly komunikující s těmito externími systémy. Rozmístění atyp komunikace mezi externími systémy závisí na jednotlivých typech externích systémů. V

9„.war“ je označení pro „Web ARchive“10Secure SHell

3.6. POUŽITÉ NÁVRHOVÉ VZORY 37

případě nasazení SVN a TRACu ve škole jsou tyto systémy umístěny na jednom počítači(viz 3.14) .

3.6 Použité návrhové vzory

Jelikož jsem v textu několikrát zmínil některý návrhový vzor, ale podrobněji jsem ho nevy-světlil, činím tak nyní. Návrhové vzory jsem čerpal hlavně z [62] a [10].

Singleton

Návrhový vzor Singleton (česky Jedináček) je zde zahrnut, i když není přesně podle specifikace[62]. Díky Springu a jeho technologii Inversion of Control v podstavě spravované třídy ( vnávrhu se jedná se o všechny „DAO“ a business třídy) jsou jedináčci, ale nutno podotknout,že mají pouze jedinou instanci v rámci aplikačního kontejneru, který je součástí Springu.Pokud by tyto třídy měly důsledně splňovat vzor Jedináček, tak by musely mít i privátníkontruktor, který by jasně zaručil, že v celé aplikaci nebude moci být více jak jedna instance.Čili v systému SWINPRO se stará o „ jedináčkovství“ Spring, ale kdybychom chtěli volatkontruktor pro vytvoření nové instance, tak nám v tom nic nebrání.

Facade

Návrhový vzor Facade (český Fasáda) jsem zmínil v balíčcích business vrstvy. Tento návrhovývzor jsem použil, abych snížil počet vazeb mezi třídami prezentační vrstvy a třídami businessvrstvy. Zároveň Fasáda umožňuje, aby objekt prezentační vrstvy zavolal jednu metoduobjektu fasády a pokud se žádaná akce skládá ze sekvence metod, tak volání této sekvenceuž může provést „fasádní“ objekt a vrátit volajícímu chtěný výsledek. Vzor Fasáda jsemneaplikoval zcela důsledně podle [62], protože ona fasáda není konkrétní jedna třída, kteráby delegovala volání na více jiných tříd. Pro důsledné nedodržení jsem měl svůj důvod.Kdyby byla jedna „fasádní“ třída pro celý balíček, tak bude nadúměrně veliká a to jsemnechtěl. Z tohoto důvodu jsem udělal menší fasády předepsané rozhraními. Fakt, že rozhraníjsou realizována přímo konkrétním manažerem a v podstatě zde není přítomna speciálněvyčleněná „fasádní“ třída, je způsoben tím, že samotní manažeři jsou navrženi poměrněkomplexně a již mají metody, které zastřešují onu sekvenci volání jiných metod. Do budoucnaale nevylučuji, že v případě rozšiřování systému SWINPRO není možné vyčlenit speciálníobjekt na tuto „fasádní“ funkci. Stačí pouze, aby tento zvolený objekt implementoval mnoupředepsané rozhraní.

Factory method

Návrhový vzor Factory method (česky Tovární metoda) se objevuje např. v balíčku „business.-manager.server“. Podle tohoto vzoru je navržena třída „ToolServerFactory“ a rozhraní „ITool-ServerFactory“, které obsahuje dvě metody. V těchto metodách se řeší problém od jaké třídyvytvořit instanci, aby mohla komunikovat s externím nástrojem, který je přiřazen projektu(tento projekt je jako parametr metody). Návratovým typem je rozhraní. Tento návrhovývzor umožnil, aby metody třídy „ToolServerFunctionManager“ byly napsány zcela obecně a


obracely se na objekt typu „ISCMServerBo“ a „IBTSServerBo“. O to, se kterou konkrétníinstancí budou tyto metody pracovat, se třída „ToolServerFunctionManager“ nezajímá. Kvyřešení tohoto problému se obrací na rozhraní „IToolServerFactory“. K naplnění ukazatelev „ToolServerFunctionManager“ je využíván Spring a jeho technologie Inversion of Control.Pokud tedy je zapotřebí začlenit jinou továrnu do systému, tak stačí realizovat rozhraní„IToolServerFactory“ a pak už jen změnit konfigurační soubor Springu.

Low coupling

Tento vzor je součástí GRASP11 vzorů (jejich přehled můžete nalézt zde [10]). Low coupling(česky Nízká provázanost) hovoří o stylu návrhu, který by se měl snažit minimalizovat početvazeb mezi třídami a podporovat jejich znovupoužitelnost. Tímto principem jsem se řídilpři návrhu a proto celá „DAO“ vrstva vystupuje proti vyšší business vrstvě tím stylem, žekonkrétní „DAO“ třídy jsou schovány za rozhraním. Tohoto samého postupu je použito vpřípadě business vrstvy a vyšší prezentační vrstvy, kdy prezentační vrstva je odstíněna odkonkrétní implementace soustavou fasád na které se obrací.

Creator

Tento vzor taky patří mezi GRASP vzory. Creator (česky Tvůrce) řeší problém kdo budezodpovědný za vytváření určitého objektu. Tento princip je použit třeba u „ToolServerFactory“,kdy jsem odpovědnost za vytváření objektů typu „ISCMServerBo“ respektive „IBTSServerBo“přenesl pouze na tuto třídu. Tento případ není úplně ukázkový pro vzor Creator, protože sezde neřeší provázanost z obou stran (jako je tomu v příkladu v [64]), ale nicméně základnímyšlenku obsahuje.

Controller

Tento vzor je opět součástí GRASP vzorů. Controller (česky Kontroler) se zabývá otázkoukdo bude zodpovědný za přijímání požadavků od uživatele. Při návrhu samotného systémujsem tolik tuto otázku řešit nemusel přímo já, protože použitý framework JSF v podstatěurčoval, že třídy přijímající požadavky od uživatele budou backing beany, které se vážou nakonkrétní JSF stránku. Nicméně jsem tento vzor chtěl zde zmínit, protože byl v systémuSWINPRO použit.

High cohesion

Tento vzor je také součástí GRASP vzorů. High cohesion (česky Vysoká soudržnost) říká, žesoudržnost tříd a balíčků by měla být co nejvyšší, aneb daný úkol by se měl celý vyřešit vrámci třídy/balíčku. Tento postup je vidět například při rozdělení business vrstvy do balíčků.Třídy v balíčku jsou si funkčně velice příbuzné. Tento vzor souvisí i se vzorem Low coupling,protože pokud si při řešení problému třída vystačí sama bez velkého počtu externích tříd,tak se zároveň snižuje provázanost mezi třídami. Zároveň pokud třídy/balíčky splňují tentovzor, tak systém je dobře modulovatelný a jednotlivé třídy/balíčky se dají snáze upravovataniž by to ovlivňovalo zbytek programu.

11General Responsibility Assignment Software Patterns

3.6. POUŽITÉ NÁVRHOVÉ VZORY 39

Three-tier architecture

Neboli třívrstvá architektura je architektonický vzor (viz např. [24]), který vlastně říká,jak navrhnout software z velice obecného hlediska. Tento vzor předepisuje, aby byl systémrozvržen do tří vrstev, a to na: datovou, business a prezentační vrstvu. Jak jste si mohlivšimnout v kapitole o návrhu, systém SWINPRO jsem takto rozdělil. Přináší to s sebouvýhody, že datová či prezentační vrstva se dá vyměnit a tím docílit komunikaci s jinýmúložným prostorem nebo úplně jiný vzhled systému. Zároveň všechna pravidla a podmínky,mající odraz v reálném světě, se promítají majoritně do business vrstvy a tak jejich kontrolaje centralizovaná. Datová vrstva se stará pouze o připojení do databáze a prezentační vrstvazase pouze o prezentaci dat uživateli.


Obrázek 3.14: Schéma nasazení systému pro řízení projektů na fakulte

Kapitola 4

Zhodnocení provedených rozhodnutí

V této kapitole zhodnotím svoje rozhodnutí, které jsem provedl, jestli byla správná či špatná aco případně v průběhu implementace přinesla. Toto zhodnocení je psáno až po implementaciv době pilotního provozu.

4.1 Technologie

Co se týče technologií, tak tam si myslím, že vývojářský tým nenarazil na neřešitelnýproblém. Architektura klient-server se jevila jako dobrý základ. Rovněž s vybraným pro-gramovacím jazykem ani s databází nebyly problémy.

Drobné problémy se vyskytly ohledně vybraného serveru Tomcat. V průběhu vývojedocházelo k častým zablokováním serveru a to po docela málo nahráních SWINPRO naserver. Tento problém se nepodařilo vyřešit, poněvadž je problém přímo v serveru. Vhodnýmnastavením se podařilo zablokování několikanásobně oddálit. Tohoto oddálení bylo docílenodíky nastavení většího prostoru pro uživatelské třídy, tedy ty které nejsou součástí JRE (popistohoto prostoru je zmíněn v [36]). Zvětšení tohoto prostoru se provede přidáním parametru„-XX:MaxPermSize=512m“ při spouštění Tomcatu. Tento parametr se zanese do proměnné„JAVA_OPTS“ v konfiguračním souboru „catalina.bat“ nebo „catalina.sh“ (v závislosti naoperačním systému).

Vybraný framework Hibernate se rovněž osvědčil. Hlavním přínosem byla technologieobjektově-relačního mapování, kterou Hibernate nabídl. Tato technologie velmi ulehčila prácipři implementaci a programátoři si nemuseli zatěžovat hlavu s konstrukcí SQL dotazů. Tovše udělal Hibernate za ně. Hibernate také podporuje mapování v případech dědičnostimezi objekty, takže ani v datové vrstvě, kde se používalo dědění v kontextu entitních tříd,nenastaly žádné problémy. Zároveň specifikování mapování entitních tříd anotacemi přímove zdrojovém kódu, se ukázalo býti velmi přehledné a rychlé.

S Hibernatem nastal jen problém ve chvíli, kdy bylo potřeba dostat se po změně objektuv paměti k původnímu objektu, který je v databázi. Patrně z důvodu caschování Hibernateodmítal vrátit původní objekt z databáze. Tento problém se ale nakonec vyřešil pomocízavolání metody „evict(Object)“, která náleží objektu „Session“ a způsobí vymazání objektuz cache Hibernatu, takže Hibernate je následně nucen si načíst objekt přímo z databáze.

41

42 KAPITOLA 4. ZHODNOCENÍ PROVEDENÝCH ROZHODNUTÍ

Vybraný framework JSF, jak už jsme zmínil, nebyl tak bohatý na komponenty, a tak jsemmusel vybrat v průběhu vývoje nadstavbu. Nadstavba se vybrala poměrně rychle, protožeměla jako základ framework JSF.

Nadstavba frameworku JSF framework RichFaces se osvědčila a velkým množstvím nabí-zených hotových komponent urychlila vývoj webového uživatelského rozhraní. Pouze zůstalynevyřešené určité problémy a i v době psaní této bakalářské práce se nepodařilo ještěprojektovému týmu opravit problém s pomalým Ajaxem. Další nepříjemná vlastnost, která seobjevila v průběhu, byla taková, že programátoři museli poměrně značné množství hodnotpředávat jako parametr webové adresy, aby se mohly tyto údaje přenést mezi stránkamia jejich backing beanami. Tento problém se taky nepodařilo vyřešit, a tak se údaje muselypředávat pomocí parametrů adresy. Zároveň se nedala použít působnost (angl. scope) backingbean na celé sezení (angl. session), protože by uživateli nebylo umožněno otevřít si vícezáložek ve svém webovém prohlížeči a na každé záložce být v jiném stavu téže stránky (stavby se totiž sdílel napříč stejnými stránkami).

Framework Spring se osvědčil. Pouze ze začátku měl tým problém osvojit si jeho funkce,např. pro Inversion of Control (princip této technologie jsem popisoval v analýze), ale totose v průběhu vývoje vyřešilo a tato technologie velice usnadnila vývoj. Také při testováníse hojně využívala podpora Springu pro testovací framework JUnit. Z ní bylo použito např.implicitní volání příkazu rollback po každé testovací metodě, nebo běh každého testu vsamostatné transakci, aby test nemohl ohrozit data, která byla zanesena do databáze ještěpřed jeho spuštěním. Ještě bych zmínil technologii AOP, která byla použita pro systémlogování při zavolání business metody. Bohužel jsem na tuto technologii přišel pozdě, a takjsem už nemohl návrh přizpůsobit tak, aby se AOP využilo více. Možný přínos AOP pronávrh systému SWINPRO uvedu v následující podkapitole.

Hlavní přínos frameworku Spring bude jistě také doceněn i do budoucna. Spring nabízímnoho technologií a i když pro systém SWINPRO jich bylo použito jen několik, tak věřím,že při dalším rozšiřování systému SWINPRO dojdou nasazení i ostatní technologie, kteréSpring nabízí.

Určitě jako zajímavý framework pro prezentační vrstvu by mohl být Vaadin, ale jelikožjsem ho objevil pozdě, tak jsem ho nenasadil.

4.2 Návrh

Nejdříve zhodnotím návrh obecně a pak postoupím ke zhodnocení jednotlivých vrstev.

Zvolená třívrstvá architektura se osvědčila a přispěla k jasnému oddělení způsobu ukládánídat od business procesů a logiky a od prezentace dat uživateli.

Mnou aplikované návrhové vzory se také osvědčily a celkově přispěly k modularitě systémua jeho přehlednosti (ve zdrojovém kódu). Nenastal případ, že by následkem aplikace návr-hového vzoru vzniklo více potíží, než kdyby nebyl aplikován. Toto je pochopitelné, protoženávrhové vzory jsou nejlepší zatím vyzkoušené praktiky, jak řešit určitý problém. Jelikožjsem návrhové vzory aplikoval správně, tak se projevily jejich výhody, které jsem popsal vkapitole „Použité návrhové vzory“.

4.2. NÁVRH 43

Datová vrstva

Návrh datové vrstvy se ukázal být jako velice povedený. Rozdělení vrstvy do balíčků prorozhraní a konkrétní třídy přispělo k orientaci ve zdrojovém kódu. Úplná jednoduchost„DAO“ tříd byla k užitku. Jediná věc, která se projevila jako zbytečná, byla „DaoFactory“,jejíž funkce byla nahrazena funkcí Springu. Rovněž také tato továrna by neumožňovala protestovací účely asociovat různé business objekty s různými „DAO“ objekty. Z těchto důvodů„DaoFactory“ ani nebyla implementována.

Business vrstva

Hlavním zmatečným prvkem v této vrstvě byla kontrola a autentizace uživatele, zda smíprovést danou akci či ne. Jak již jsem uvedl v předchozím textu, tak ze začátku uživatelnebyl jako parametr vůbec předáván, ale po započetí vývoje jsem byl nucen toto pozměnit auživatele jako parametr předávat. Nepodařilo se mi ovšem do tohoto vnést úplnou jednotnost,a tak občas uživatel je jako parametr předán a občas se pouze věří, že prezentační vrstvanezobrazí uživateli co nemá vidět. U nejstěžejnějších funkcí je autentizace uživatele provedenav business vrstvě. Nicméně toto by bylo dobré sjednotit.

V kontextu autentizace uživatele by zde bylo na místě mechanismus ověřování trochupoupravit. Velice vhodná technologie je AOP1, kterou Spring také disponuje. Při začátkunávrhu jsem AOP neznal, a tudíž ho ani nevyužil. V případě aplikování AOP by se dalospecifikovat anotacemi v kódu, nebo přímo v konfiguračních souborech Springu, že předurčitou množinou metod se má nejdříve zavolat metoda, která provede ověření uživatele av případě neúspěchu vyvolá výjimku. Spring zařídí, aby tato specifikovaná metoda byla vdaných případech zavolána jako první ještě před metodou, která provádí jakékoli změny.Zároveň by se nemusel předávat parametr uživatele, ale ověřovací metoda by si ho mohlazískat ze třídy „LoginBean“ (tuto třídu podrobně rozebírá ve své práci [60] kolega Špaček).

Další věc, která nebyla z návrhu splněna, je soustava fasád v jednotlivých podbalíčcíchbusiness vrstvy. Nenaplnění nedošlo z důvodu zbytečnosti fasád, ale spíše z důvodu pochybeníprogramátorů v implementačním procesu.

1Aspektově orientované programování

44 KAPITOLA 4. ZHODNOCENÍ PROVEDENÝCH ROZHODNUTÍ

Kapitola 5

Možná budoucí zlepšení

V této kapitole zmíním vylepšení (rozšíření), která nemohla být realizována z hlediska ča-sového, a dále vylepšení, na která se přišlo v průběhu vývoje, ale už nezbyl čas na jejichzapracování.

Nebudu zde provádět žádnou detailní analýzu, pouze podotknu, které věci by mohly býtzajímavé z mého hlediska. Do budoucna by bylo určitě v případě zájmu nutné je podrobitdůkladné analýze, zda jsou proveditelné čí vůbec žádoucí.

5.1 Nabízející se rozšíření

Na první pohled se zde nabízí rozšíření a implementace co se týče externích nástrojů, sekterými systém pracuje. Je zde možno doimplementovat spolupraci s dalšími verzovacímisystémy, jako je třeba Git, Mercurial nebo CVS. Rovněž se nabízí toto rozšíření i v oblastisystému pro správu požadavků. V souvislosti s implementací dalších externích nástrojů byurčitě mohly být doimplementovány všechny funkce externích nástrojů tak, jak jsem jenavrhnul v této práci. Většina z nich již je realizována, ale v době psaní této bakalářsképráce se v systému SWINPRO nacházejí ještě některé metody pouze se signaturou. Vpřípadě systému pro správu zdrojového kódu se souběžně s touto prací provádí implementaceněkterých dalších modulů jako součást jiné bakalářské práce [68] mého kolegy Ustahala.

Když už je řeč o externích nástrojích, zajímavým rozšířením by byla možnost nahrávatovladače (moduly) pro jednotlivé verzovací nástroje či systémy pro správu požadavků zaběhu systému. S pomocí reflexe v Javě si myslím, že po důkladném analyzování požadavkůa samotného procesu nahrávání by toto nemusel být problém.

Jako zajímavé by se určitě jevilo rozšíření co se týče webových služeb. Kdyby se metodybusiness vrstvy vystavily navenek jako webové služby a umožnilo se jejich volání, samozřejměpo adekvátní autentifikaci uživatele, pak by toto umožnilo realizovat více nezávislých pří-stupových rozhraní k systému a zárověň umožnilo jejich implementaci v různých jazycích.Nebo by se nemusely všechny business metody zveřejňovat jako webové služby, ale třeba jenněkteré. Další možností by bylo vytvořit modul, jehož metody budou jako webové službya který bude pouze delegovat volání na business metody. Toto řešení by umožnilo třebalogovat kdo a kam přistupuje pres webové služby, nebo přes webové služby pustit jen některéuživatele. Třeba pouze externí systémy by mohly volat webové služby.

45

46 KAPITOLA 5. MOŽNÁ BUDOUCÍ ZLEPŠENÍ

5.2 Nabízející se vylepšení

Jedna z hlavních věcí, která by se určitě dala ještě vylepšit, je řízení přístupu uživatelů kfunkčnostem systému. Nyní se má věc tak, že v podstatě co nemá uživatel vidět, je skrytona prezentační úrovni, čili se uživateli nezobrazí, pokud nemá příslušná práva. Z hlediskauživatele přistupujícího přes webový prohlížeč, až takový problém není, protože nezobrazenéfunkčnosti se nedají dohledat ani v zdrojovém kódu stránky, takže si je „normální“1 uživatelnení schopný vyvolat. Je zde ale ovšem jiné nebezpečí, a to, že je kontrola roztroušena jakčástečně do business vrstvy tak i do prezentační. Správně by měla být všechna omezenípřístupu kontrolována hlavně v business vrstvě, protože prezentační vrstva se může lehcevyměnit a nebo při jejím upravování může programátor snadno na nějaké omezení zapo-menout. V průběhu vývoje se na toto přišlo, a tak se u nejdůležitějších funkcí přesunulakontrola i na úroveň business tříd. Není tomu tak ale v případě všech funkcí.

Dále je zde otázka důvěryhodnosti prezentační vrstvy. Jelikož může být více pohledůnavázaných na tutéž business vrstvu, tak z pohledu business vrstvy jsou tyto pohledynedůvěryhodné, a tudíž by jim neměly být předávány objekty v té samé podobě, jako jsou vdatabázi. Hlavní problém je v tom, že v prezentační vrstvě se může třeba změnit uživatelskéjméno, které podle požadavků (viz [65]) by se nikdy po nastavení měnit nemělo. Pokud pakbude zavolána např. metoda pro aktualizaci profilu uživatele, tak provádějící manažer nemášanci zjistit, jestli se změnily jen atributy objektu, které se podle požadavků měnit mohou,protože nemá k dispozici původní verzi objektu.

V době, kdy jsem konstruoval návrh systému mě napadly tyto varianty, jak znemožnitprezentační vrstvě nastavovat všechny atributy:

• Návratová hodnota business metody by nebyl přímo objekt User, Project, Categoryatd., ale interface, který by nedefinoval „settovací“ metody u atributů, kde by jejichzměna byla nežádoucí. Tento přístup má jednu nevýhodu. Pomocí reflexe se dá objekt vprezentační vrstvě přetypovat na konkrétní třídu a pak již lze nastavit všechny zakázanéatributy.

• „Settovací“ metody pro neměnné atributy by mohly v případě svého zavolání nastavitproměnnou typu boolean, že byly zavolány. V tomto případě, kdyby to business metodazjistila, tak by vyvolala výjimku. Tento přístup má nevýhodu. Musel by se vyřešitzpůsob jak resetovat praporky, aniž by je nemohla resetovat prezentační vrstva. A tojsme zase na začátku problému.

• V business metodě by se objekt získaný z databáze kompletně přeložil do novéhoobjektu, který by neumožňoval nastavovat neměnné atributy. Toto řešení by zplodiloveliké množství dalších tříd.

Žádnou z těchto variant jsem neuplatnil, protože se mi žádná nezdála elegantní z pohledunávrhu a pracnosti řešení. Jelikož prezentační vrstva je součástí systému, spokojil jsem se sfaktem, že budu prezentační vrstvu považovat za důvěryhodnou. Pokud by se ale do budoucnauvažovalo o například webových službách, popř. o posílání objektů někam vzdáleně, a tam

1Normální myslím z pohledu, že není žádným profesionálním hackerem.

5.2. NABÍZEJÍCÍ SE VYLEPŠENÍ 47

pak by byly prezentovány uživateli, tak tento problém by určitě bylo vhodné důkladněanalyzovat a vyřešit.

Návrh na řešení, který mě napadl až v průběhu implementačních prací, a tudíž nenízakomponován, byl tento. Uvedu jej na konkrétním příkladu, abych dosáhl lepší srozumi-telnosti. Řekněme, že tento problém se bude týkat uživatele. V balíčku s manažerem proúčty vytvoříme obalovou třídu pro uživatele, která bude mít soukromý ukazatel na uživatele,jenž bude finální. Zároveň bude mít všechny metody, které má uživatel, s tím rozdílem, že„settry“ u neměnných atributů budou mít prázdné tělo. Dále pak tato obalová třída budemít „get“ metodu na onoho uživatele, ale s viditelností pouze v rámci balíčku, takže se tímdocílí, že v prezentační vrstvě nebude možnost dostat se přímo k objektu uživatele, kterýjsme načetli z databáze. Určitě by nešla použít v tomto případě dědičnost, protože pakbychom mohli použít přetypování na předka, abychom se dostali k uživateli. Tento nápad semi jeví elegantní z toho důvodu, že už z principu návrhu zaručuje business metodě jistotu, žeprezentační vrstva nemůže změnit některé atributy, aniž by to business vrstva musela extrakontrolovat. V případě, že by někdy nastal požadavek na změnu neměnného atributu, takby jeho nové hodnoty musely být předány jako parametr business metodě a až zde by mohlodojít k nastavení. Z principu rozsahu bakalářské práce je toto jenom námět na zlepšení ajeho schůdnost by musela být nejprve hlouběji analyzována.

Dalším zlepšením, či spíše opravou, jak již byla zmíněna v hodnocení rozhodnutí, jeimplementace fasád v business balíčcích. V případě, že by se balíčky v budoucnu rozrůstalyo další třídy, tak by fasády přispěly k menší provázanosti prezentační a business vrstvy.

48 KAPITOLA 5. MOŽNÁ BUDOUCÍ ZLEPŠENÍ

Kapitola 6

Instalační příručka

V této kapitole sepíši kroky, které je nutné podniknout, aby mohl být systém SWINPROnainstalován na počítači. Instalaci systému popíši pro server Tomcat verze 6, protože natomto serveru byl systém vyvíjen a i testován. Samozřejmě je možné systém nasadit najakýkoli servletový kontejner či aplikační server, protože projekt Swinpro si „nese“ celouaplikační podporu s sebou. Pro případ nasazení na jiný server než Tomcat je nutné systémSWINPRO nejdříve řádně otestovat a také přípravy samotného počítače se budou lišit vzávislosti na použitém serveru.

6.1 Předpříprava

Nejdříve musíte mít na počítači nainstalován JRE1 verze 5.0 a vyšší. Tuto podmínku si kladeserver Tomcat. S instalaci JRE na Vámi vybraný operační systém by neměl být problém,protože Java poskytuje JRE na většinu rozšířených operačních systémů. Dále je nutné mítdostatečný hardwarový výkon počítače pro server Tomcat a databázi PostgreSQL. Databázisi rovněž můžete vybrat různou. Použitý framework Hibernate poskytuje podporu pro většinudatabázových strojů.

Další krok je instalace Tomcatu (detailní popis naleznete zde [2]) a PostgreSQL (detailnípopis naleznete zde [40]). Po splnění těchto kroků jsou připraveny podmínk pro vlastnínasazení systému SWINPRO.

6.2 Nasazení Swinpro

Před samotným nasazením je nutné nastavit připojení k databázi. Soubor „swinpro.war“ jeobyčejný archiv, takže ho můžete otevřít v archivačním nástroji. Přímo v archivu „swinpro.war“je podsložka „WEB-INF“ a v této složce je soubor „domain-context.xml“. Po otevření tohotosouboru hned druhý odstavec nadepsaný komentářem „<!– Hibernate Configuration –>“ setýká konfigurace připojení k databázi. První property je název třídy ovladače, který budepoužit pro připojení do databáze. Druhá property je adresa a port, kam má být spojeníiniciováno. V případě použití PostgreSQL je ve tvaru

1Java Runtime Enviroment

49

50 KAPITOLA 6. INSTALAČNÍ PŘÍRUČKA

„ jdbc:postgresql://ADRESA:PORT/JMÉNO_DATABÁZE“. Další řádek obsahuje uživatel-ské jméno, pod kterým se má Hibernate přihlásit do dané databáze a další řádek je hesloasociované s tímto jménem. Ukázku ze souboru „domain-context.xml“ týkajícího se nastavenípřipojení do databáze si můžete prohlédnou níže.

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName" value="org.postgresql.Driver"/><property name="url"value="jdbc:postgresql://rabbit.felk.cvut.cz:5432/swinpro"/><property name="username" value="UzivateslkeJmeno"/><property name="password" value="UzivatelskeHeslo"/>

</bean>

V dalším kroku je nutné nastavit prostředí pro ověřování uživatelů. Touto problematikouse zabývá podrobně práce mého kolegy [60].

Po nastavení ověřování je na čase provést samotný deploy pomocí například webovéhorozhraní, které poskytuje server Tomcat. V tomto administrátorském rozhraní pouze vyberetesoubor „swinpro.war“ a potvrdíte „deploy“. Po nahrání na server se vám objeví u seznamůaplikací i aplikace SWIPRO.

Kapitola 7

Závěr

Jelikož jsem diskusi o správnosti mých rozhodnutí a o možných rozšířeních již obsáhl vdřívějších kapitolách, tak bych zde pouze zmínil moje osobní pocity a pár slov na závěr.

Úkolem této bakalářské práce bylo na základě detailní analýzy požadavků v [65] provéstnávrh tohoto systému a analýzu technologií vhodných pro tento systém. Cíle bakalářsképráce jsem naplnil a všechna svá rozhodnutí náležitě zdůvodnil a uvedl i alternativy, mezikterými jsem si mohl vybrat.

Bakalářská práce pro mě byla značným přínosem. V průběhu jejího zpracování jsemmusel pročíst množství dokumentací a srovnávacích článku různých webových technologií ato zcela jistě přispělo k rozšíření mých obzorů, co se týče webových technologií a problémů,které se těmito technologiemi dají řešit. Další přínosem byla zkušenost v návrhu větší webovéaplikace, kde jsem musel pamatovat na budoucí možnost rozšiřitelnosti a růstu aplikace.

Dalším velkým přínosem byla zpětná vazba ze strany vedoucího práce. Tímto mám hlavněna mysli případy, kdy jsem navrhnul část systému podle svého nejlepšího vědomí a svědomía vedoucí práce mi návrh schválil, že je dobrý, nebo mě naopak upozornil na některé aspekty,které mě přinutily k zamyšlení a úpravě návrhu.

Co pro mě bylo dobrou motivací bylo vědomí, že systém který navrhuji bude i reálněpoužit a že to není pouze projekt „do šuplíku“.

Zároveň si troufám říci, že provedená rozhodnutí v této bakalářské práci se nedají označitza věcně špatná. Naopak se domnívám, že důkladná analýza technologií a pečlivě provedenýnávrh přispěly ke zdárnému průběhu implementace, a i ke konečné kvalitě systému SWIN-PRO, i když toto prověří hlavně čas a používání systému SWINPRO.

51

52 KAPITOLA 7. ZÁVĚR

Literatura

[1] Apache tomcat. http://tomcat.apache.org/, stav ze 20. 3. 2010.

[2] Apache tomcat 6.0. http://tomcat.apache.org/tomcat-6.0-doc/index.html, stavze 18. 4. 2010.

[3] Application server. http://en.wikipedia.org/wiki/Application_server, stav ze23. 3. 2010.

[4] Aspect-oriented programming. http://en.wikipedia.org/wiki/Aspect-oriented_programming, stav ze 5. 4. 2010.

[5] Bezdisková stanice. http://cs.wikipedia.org/wiki/Bezdisková_stanice, stav ze9. 5. 2010.

[6] Comparison of web browsers. http://en.wikipedia.org/wiki/Comparison_of_web_browsers, stav ze 26. 3. 2010.

[7] Core j2ee patterns - data access object. http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html,stav ze 12. 5. 2010.

[8] Enterprise javabean. http://en.wikipedia.org/wiki/Enterprise_JavaBean, stav ze23. 3. 2010.

[9] Fat client. http://en.wikipedia.org/wiki/Fat_client, stav ze 9. 5. 2010.

[10] Grasp (object-oriented design). http://en.wikipedia.org/wiki/GRASP_(object-oriented_design), stav ze 10. 4. 2010.

[11] Hibernate annotations. http://docs.jboss.org/hibernate/stable/annotations/reference/en/html/, stav ze 20. 3. 2010.

[12] Installation guide. http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5.0.0/html/Installation_Guide/index.html, stav ze1. 4. 2010.

[13] J2ee - java 2 enterprise edition. http://artax.karlin.mff.cuni.cz/~ebik/nju/linuxem/J2EE/J2EE.html, stav ze 19. 3. 2010.

[14] Java 2 platform, enterprise edition (j2ee) overview.http://java.sun.com/j2ee/overview.html, stav ze 19. 3. 2010.

53

54 LITERATURA

[15] Java ee 5 compatible implementations. http://java.sun.com/javaee/overview/compatibility-javaee5.jsp, stav ze 23. 3. 2010.

[16] Java platform, enterprise edition. http://en.wikipedia.org/wiki/J2EE, stav ze23. 3. 2010.

[17] Java (programming language). http://en.wikipedia.org/wiki/Java_(programming_language), stav ze 25. 3. 2010.

[18] Javatm web start version 1.5.0 - frequently asked questions(faq). http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#301, stav ze 25. 3. 2010.

[19] Jsf 1.2 features. http://www.roseindia.net/jsf/jsf1.2/jsf1.2features.shtml,stav ze 20. 3. 2010.

[20] Jsf phase listener. http://wiki.foochal.org/index.php/JSF_Phase_Listener, stavze 23. 3. 2010.

[21] Learn about java technology. http://www.java.com/en/about/, stav ze 19. 3. 2010.

[22] List of object-relational mapping software. http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software, stav ze 20. 3. 2010.

[23] Mojarra javaserver faces jsf 2.0 from sun. https://javaserverfaces.dev.java.net/presentations20090520-jsf2-datasheet.pdf, stav ze 20. 3. 2010.

[24] Multitier architecture. http://en.wikipedia.org/wiki/Multitier_architecture,stav ze 10. 4. 2010.

[25] Open source web frameworks in java. http://java-source.net/open-source/web-frameworks, stav ze 18. 3. 2010.

[26] Oracle internet application server. http://www.oracle.com/technology/products/ias/index.html, stav ze 18. 5. 2010.

[27] Oracle weblogic server standard edition. https://shop.oracle.com/pls/ostore/product?p1=OracleWebLogicServerStandardEdition&sc=ocom_oracleweblogicserverstandardedition, stav ze 1. 4. 2010.

[28] Relational database management system. http://en.wikipedia.org/wiki/Relational_database_management_systems, stav ze 18. 4. 2010.

[29] Richfaces live demo. http://livedemo.exadel.com/richfaces-demo/index.jsp, stavze 20. 3. 2010.

[30] Spring integration. http://vaadin.com/wiki/-/wiki/Main/Spring Integration,stav ze 2. 4. 2010.

[31] Thin client. http://en.wikipedia.org/wiki/Thin_client, stav ze 9. 5. 2010.

[32] Vaadin. http://en.wikipedia.org/wiki/Vaadin, stav ze 2. 4. 2010.

LITERATURA 55

[33] Welcome to cppcms. http://cppcms.sourceforge.net/wikipp/en/page/main, stavze 18. 3. 2010.

[34] What is java web start and how is it launched?http://java.com/en/download/faq/java_webstart.xml, stav ze 25. 3. 2010.

[35] Wt: an introduction. http://www.webtoolkit.eu/wt, stav ze 18. 3. 2010.

[36] Explaining java.lang.outofmemoryerror: Permgen space, 2005.http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space, stav ze 9. 4. 2010.

[37] Overview and frequently asked questions, 2009. http://regmedia.co.uk/2009/10/30/oracle_statement_sun_software.pdf, stav ze 12. 3. 2010.

[38] Richfaces developer guide, 2009. http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/, stav ze 20. 3. 2010.

[39] Hibernate documentation overview, 2010. http://docs.jboss.org/hibernate/stable/core/reference/en/pdf/hibernate_reference.pdf, stav ze 20. 3. 2010.

[40] Postgresql 8.4.3 documentation, 2010. http://www.postgresql.org/docs/8.4/static/index.html, stav ze 25. 3. 2010.

[41] A. Ansari. Seam vs spring, 2008. http://linkedinspin.ning.com/profiles/blogs/1601474:BlogPost:28386, stav ze 20. 3. 2010.

[42] A. Ansari. The spring framework - reference documentation, 2008.http://static.springsource.org/spring/docs/2.5.x/spring-reference.pdf,stav ze 20. 3. 2010.

[43] P. Aubrecht. Jsf. http://krizik.felk.cvut.cz/moodle/file.php/25/09zprednaska8-JSF.pdf, stav ze 22. 3. 2010.

[44] P. Aubrecht. Jsp. http://krizik.felk.cvut.cz/moodle/file.php/25/09zprednaska3-JSP.pdf, stav ze 20. 3. 2010.

[45] P. Aubrecht. Servlety. http://krizik.felk.cvut.cz/moodle/file.php/25/09zprednaska2-Servlet.pdf, stav ze 22. 3. 2010.

[46] F. Avila. Performance comparison between mysql and postgresql,2007. http://www.authorstream.com/presentation/Tatlises-15835-LinuxWorld-MySQL-Postgres-performance-en-Comparison-PostgreSQL-Agenda-Objective-TPC-Team-Benchmarks-angusallyouneed-tcm4-123635-Entertainment-ppt-powerpoint, stav ze 12. 3. 2010.

[47] A. Baryudin. C++ web development framework.http://www.baryudin.com/articles/software/c-plus-plus-web-development-framework.html, stav ze 18. 3. 2010.

[48] M. Burda. Php v objeti objektu (6), 2001.http://www.root.cz/clanky/php-v-objeti-objektu-6/, stav ze 19. 3. 2010.

56 LITERATURA

[49] G. Clarke. Oracle sees future in sun’s glassfish, 2009.http://www.theregister.co.uk/2009/10/30/oracle_sun_middleware_promise,stav ze 12. 3. 2010.

[50] M. Devaine. Srovnání databázových serverů, 2007.http://www.linuxexpres.cz/software/srovnani-databazovych-serveru, stavze 25. 3. 2010.

[51] M. Hall. Pros and cons of gwt, 2007. http://www.myeclipseide.com/PNphpBB2-viewtopic-t-18969.html, stav ze 1. 4. 2010.

[52] P. Herout. Učebnice jazyka Java. Kopp, 2007.

[53] O. Jakubčík. Oracle - 1 (úvod, distribuce, oraclexe), 2009.http://www.abclinuxu.cz/clanky/navody/ oracle-1-uvod-distribuce-oraclexe,stav ze 25. 3. 2010.

[54] I. N. Jim Arlow. UML2. CPress, 2008.

[55] J. Kosek. PHP. Grada, 1999.

[56] P. Krajča. Microsoft .net a linux, 2005. http://www.linuxexpres.cz/software/microsoft-net-a-linux, stav ze 12. 3. 2010.

[57] D. Lukeš. Programming language popularity. http://langpop.com/, stav ze 4. 5. 2010.

[58] D. Lukeš. Relational database management system, 2001.http://www.lupa.cz/clanky/https-bezpecnost-jen-pro-vyvolene/, stav ze4. 5. 2010.

[59] P. Mička. Vaadin. http://rtime.felk.cvut.cz/osp/student/mickapa1/vaadin.pdf,stav ze 2. 4. 2010.

[60] J. Špaček. Autentizační metody webových aplikací. 2010. Bakalářská práce.

[61] R. Pecinovský. Soucasne trendy v metodice vyuky programovani, 2006.http://gynome.nmnm.cz/konference/files/2006/sbornik/pecinovsky.pdf, stav ze19. 3. 2010.

[62] R. Pecinovský. Návrhové vzory. CPress, 2007.

[63] R. Pichlík. Google web toolkit, 2006. http://interval.cz/clanky/google-web-toolkit/, stav ze 20. 3. 2010.

[64] G. Pollice. Creator. http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/Creator.html, stav ze 18. 4. 2010.

[65] Z. Rybola. Analýza požadavků pro systém na správu projektů. 2010. Diplomová práce.

[66] J. Skrášek. Php frameworky, 2008. http://programujte.com/?akce=clanek&cl=2008022000-php-frameworky, stav ze 12. 3. 2010.

LITERATURA 57

[67] M. Strnad. Testovani a optimalizace informacniho systemu SWINPRO. 2011.Bakalářská práce.

[68] J. Ustohal. Podpora pro nástroje na správu zdrojového kódu pro aplikaci SWINPRO.2010. Bakalářská práce.

[69] M. Valenta. Dba - mysql, 2008. http://service.felk.cvut.cz/courses/Y36DBA/slides/dba_04_mysql.pdf, stav ze 25. 3. 2010.

[70] M. Večeřa. Jboss: Aplikační server. http://www.root.cz/clanky/jboss-aplikacni-server/, stav ze 23. 3. 2010.

[71] G. Wilkins. Apache tomcat, 2008. http://www.webtide.com/choose/jetty.jsp, stavze 3. 5. 2010.

58 LITERATURA

Příloha A

Slovníček pojmů

SWINPRO Jméno konkrétní systému na správu projektů, jehož architektura je v tétobakalářské práci analyzována. Název jsem převzal z [65].

datová vrstva Vrstva sloužící pro komunikaci s databází.

DAO Data Access Object

DAO třída Třída, která pouze slouží pro získávání a ukládání dat z respektive na perzistentnímédium.

DAO objekt Objekt „DAO“ třídy.

business vrtva Vrstva sloužící pro kontrolu komplexnějších omezení kladených na data.Tyto omezení vycházejí z požadavků.

business objekt Objekt business vrstvy.

manažer Označuje business třídu nebo objekt.

prezentační vrstva Vrstva, která se zabývá prezentací dat uživateli.

JSP Java Server Pages

JSF Java Server Faces. Toto je framework pro prezentační vrstvu.

JSF stránka Toto označení používám pro webovou stránku používající framework JSFnebo jeho nadstavbu RichFaces.

RichFaces Framework pro prezentační vrstvu. Tvoří nadstavbu nad JSF frameworkem.

backing beana Třída která obsahuje data určité JSF stránky a můžou být volány jejímetody skrze tuto JSF stránku.

externí nástroj Souhrné označení pro TRAc, SVN a ostatní systému, se kterými komunikujesystém SWINPRO.

projekt Projekt v systému SWINPRO.

59

60 PŘÍLOHA A. SLOVNÍČEK POJMŮ

asociovaný projekt Projekt v systému TRAC, SVN atd., který je asociovaný (provázaný)s projektem v systému SWINPRO.

SCM system Source Code Management system. Český ekvivalent je systém pro správuzdrojového kódu.

BT system Bug Tracking system. Český ekvivalent je systém pro správu požadavků.

Příloha B

Obsah přiloženého CD

• README.TXT - soubor s popisem struktury CD.

• text/ - adresář s bakalářskou prací ve formátu PDF.

– kral-thesis-2010.pdf - soubor s vlastním textem bakalářské práce.

• zdrojoveSouboryBP/ - adresář se soubory bakalářské práce v Latexu.

– kral-thesis-2010.zip - soubor ve formátu ZIP, který obsahuje projekt z programuWinEdt, který byl použit pro psaní bakalářské práce.

• prilohaBP/ - Adresář pro soubory přiložené k práci, na které se z bakalářské práceodkazuji.

– swinpro.ea - soubor z programu Enterprise Architect, který obsahuje všechnymnout vytvořené diagramy.

61

Documents

Návrh architektury systému na správu projekt· · Návrh architektury systému na správu projektů Vojtěch Král Vedoucí práce:Ing. Jiří Mlejnek Studijní program: Softwarové