ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce Software pro skupinovou spolupráci v programátorském týmu Ji í Nápravník Vedoucí práce: Mgr. Jan Stoklasa Studijní program: Softwarové technologie a management, Bakalá ský Obor: Softwarové inºenýrství 23. kv tna 2010

iv

v Pod kování Tímto d kuji Mgr. Janu Stoklasovi za vední mé bakalá ské práce, ochotu, vst ícnost a as, který mi v noval. Také d kuji Ing. Tomá²i ƒernému za seznámení a rady týkající se systému Bugtrack, na který práce navazuje.

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/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Pelh imov dne 5. 5. 2010.............................................................

viii

Abstract This thesis is focused on the analysis and the implementation of the system, which should help with work in some software company. The output is a functional application for easy management of projects. This application extends current system with name Bugtrack, which is focused only on bug or requirment tracking. The output software helps with work at all stages of development - analysis, implementation, testing or support. Abstrakt Tato bakalá ská práce se zabývá analýzou a následnou implementací systému, který má usnadnit práci v softwarové rm. Výstupem je funk ní aplikace umoº ující snadné ízení projekt. Aplikace roz²i uje stávající systém Bugtrack, který se zam uje pouze na zaznamenání chyb, i poºadavk. Výstupní software pom ºe práci na projektu ve v²ech fázích vývoje - analýze, implementaci, testování a údrºb. ix

x

Obsah 1 Úvod 1 2 Popis problému, specikace cíle 3 2.1 Popis problému................................... 3 2.1.1 Bugtrack.................................. 3 2.2 Poºadavky na systém................................ 4 2.2.1 Funk ní poºadavky............................. 5 2.2.2 Nefunk ní poºadavky............................ 5 2.3 P ehled stávajících e²ení............................. 5 2.3.1 Trac..................................... 5 2.3.2 Redmine................................... 6 2.3.3 dotproject.................................. 7 2.3.4 Zhodnocení a záv r re²er²e......................... 7 3 Analýza a návrh e²ení 9 3.1 P ípady uºití.................................... 9 3.1.1 Akté i.................................... 9 3.1.1.1 Administrátor.......................... 9 3.1.1.2 ƒlen pracovní skupiny...................... 10 3.1.1.3 Vedoucí pracovní skupiny.................... 10 3.1.2 P ípady uºití systému........................... 10 3.1.3 Diagram aktivit............................... 12 3.2 Návrh softwaru................................... 12 3.2.1 Datový model................................ 13 3.2.1.1 Popis datového modelu..................... 13 3.2.2 Sekven ní diagramy............................ 15 3.2.3 Architektura................................ 15 3.2.4 Diagram nasazení.............................. 16 xi

xii OBSAH 4 Realizace 21 4.1 Framework SEAM................................. 21 4.1.1 Prezenta ní vrstva............................. 21 4.1.2 Obchodní vrstva.............................. 22 4.1.3 Databázová vrstva............................. 22 4.2 Implementa ní detaily............................... 22 4.2.1 Úpravy stávajícího e²ení......................... 22 4.2.2 CRUD operace se stránkováním a azením................ 23 4.2.3 Kalendá.................................. 24 4.3 GUI......................................... 25 5 Testování 27 5.1 Jednotkové testování................................ 27 5.2 Uºivatelské testování................................ 27 5.3 Automatizované testování............................. 28 5.3.1 Selenium IDE................................ 28 6 Záv r 31 Literatura 33 A Seznam pouºitých zkratek 35 B Instala ní a uºivatelská p íru ka 37 C Obsah p iloºeného CD 39

Seznam obrázk 2.1 Ukázka stávajícího systému Bugtrack - p ehled poºadavk........... 4 2.2 Funk ní poºadavky na systém........................... 5 2.3 Nefunk ní poºadavky na systém.......................... 6 3.1 Akté i systému................................... 10 3.2 P ípady uºití role uºivatel............................ 11 3.3 P ípady uºití administrátora............................ 12 3.4 P ípady uºití lena pracovní skupiny....................... 13 3.5 P ípady uºití vedoucího pracovní skupiny.................... 14 3.6 Diagram aktivity pro svolání pracovní sch ze.................. 15 3.7 Diagram aktivity pro vytvo ení pracovní skupiny................ 16 3.8 Datový model systému............................... 17 3.9 Sekven ní diagram pro vytvo ení projektové sch zky.............. 18 3.10 Datový model systému............................... 19 3.11 T ívrstvá architektura obecn (zdroj: [3]).................... 19 3.12 Diagram nasazení systému............................. 20 4.1 GUI - zobrazení detailu projektu......................... 25 4.2 GUI - zobrazení kalendá e............................. 26 C.1 Seznam p iloºeného CD p íklad........................ 39 xiii

xiv SEZNAM OBRÁZK

Seznam tabulek 5.1 Testovací p ípad: P idání nového projektu.................... 29 xv

xvi SEZNAM TABULEK

Kapitola 1 Úvod Softwarové inºenýrství je mezi námi jiº od ²edesátých let dvacátého století (samotný pojem softwarové inºenýrství byl denován na konferenci NATO v roce 1968 [2]). Za tu dobu samoz ejm pro²la tato oblast zna ným vývojem. N které postupy a procesy v ízení softwarových projekt byly upraveny i zru²eny. Na druhou stranu spousta nových proces vznikla a v sou asné dob se dostávájí do pop edí moderní metody nazývané také jako agilní metodiky. Nicmén hlavní postup práce na softwarovém projektu je stále stejný. Základem je zadání projektu, poté je zpracována analýza a návrh architektury. Z analýzy se p echází dále na implementaci, testování aplikace a p edání zákazníkovi. Samotným p edáním v²ak práce na softwarovém projektu nekon í. Je pot eba zajistit také jeho údrºbu a podporu pro zákazníka i po p edání. B hem práce na softwarovém projektu vznikají problémy a události, které je t eba e²it v rámci týmu pracujícího na projektu. Pro správu t chto poºadavk je vhodné mít systém, který tyto pot eby uspokojí. V programátorských týmech je n kolik druh lidí, a uº jde o vedoucího týmu, analytika, programátora i testera. Kaºdá osoba z týmu by m la mít p ístup do tohoto systému, kde bude moci p idávat nalezené chyby, nové poºadavky na systém a podobn. Po nasazení projektu není na ²kodu za ídit p ístup pro zákazníka, který bude moci tyto informace reportovat také. Cílem této práce je navrhnout a následn implementovat jednoduchý systém, který bude tyto v ci umoº ovat. 1

2 KAPITOLA 1. ÚVOD

Kapitola 2 Popis problému, specikace cíle V této kapitole se zam ím na problém, který budu e²it v bakalá ské práci. Stanovím si poºadavky pot ebné ke spln ní cíle. Záv rem kapitoly provedu srovnání nejznám j²ích stávajících e²ení a vyvodím záv r z této re²er²e. 2.1 Popis problému V této bakalá ské práci se budu zabývat problémem, který jsem nastínil v úvodu. I p es realtivn dlouho dobu existence oboru softwarové inºenýrství se základní postupy p íli² nem ní. Celkem astým problémem, nejen u za ínajících softwarových rem, je nejednotnost zadávání úkol a poºadavk na systém. Poºadavky jsou asto p edávány telefonicky, elektronickou po²tou i i na osobním jednání. M ºe potom docházet asto k nejasnostem a zmatk m, jelikoº není konkrétní poºadavek zanesen na jednom míst a má n kdy i t eba r zné konkrétní detaily. Proto je vhodné i u malých rem zaná²et v²echny poºadavky do jednoho systému, kam budou mít p ístup v²ichni lenové týmu a zadání tak bude jasn denované na jednom míst. Mým cílem v této bakalá ské práci je navrhnout práv takový systém, který umoºní lidem v týmu, respektive v malé i st edn velké softwarové rm jednoduché ízení projektu ve v²ech fázích softwarového vývoje. 2.1.1 Bugtrack Pro spln ní cíle jsem zvolil jako výchozí systém Bugtrack [3] a [4]. Jedná se o systém, který je naprogramovaný v technologii J2EE, konkrétn za pouºití frameworku SEAM. Bugtrack jako systém pro roz²í ení pouºiji i z toho d vodu, ºe jeho tv rcem je Ing. Tomá² ƒerný, který je oponentem mé práce a nabídl mi p ípadné konzultace ohledn tohoto systému. Nyní Bugtrack umoº uje detailn spravovat poºadavky. U poºadavk lze denovat spoustu atribut (komponenta, verze, apod.), p ípadn m ºeme k n jakému atributu p idat dal²í moºnost pro výb r. Díky detailnímu zanesení poºadavku do aplikace, umoºn no snadné a podrobné ltrování a procházení. U kaºdého poºadavku je zárove otev ena diskuze. Bugtrack 3

4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE má denované v podstat t i hlavní role administrátor, registrovaný uºivatel p edávající poºadavky a registrovaný uºivatel, který poºadavky zpracovává (vývojá, tester apod.). Stávající e²ení systému Bugtrack mimo zadání a zpracování poºadavku i chyby zahrnuje je²t správu uºivatel, kdy se udrºují p ihla²ovací a kontaktní informace na daného lov ka. Bugtrack také umoº uje jednoduché zobrazení (tzv. dashboard), kdy je vid t jasn, kolik je otev ených poºadavk, vytvo ených a hotových pro jednotlivé projekty. Obrázek 2.1: Ukázka stávajícího systému Bugtrack - p ehled poºadavk Já systém roz²í ím o ²ir²í podporu práce s projekty. Ve stávajícím systému jsou projekty denovány pouze jako textová poloºka, bude t eba je denovat jako samostatný objekt. Dal²í roz²í ení se bude týkat pracovních skupin. V softwarových rmách je asto denovaná n jaká skupina lidí, která na daném projektu i zakázce pracuje, proto bude vhodné podporu skupin implementovat. Ro²í ení budu sm rovat také na moºnost denovat sch zky v projektu. Nemén d leºité je také zobrazeni událostí projektu (sch zky, datum uzav ení poºadavku apod.) v kalendá i, který bude také sou ástí mého e²ení. 2.2 Poºadavky na systém Podle knihy [1] jsou poºadavky na systém denovány takto: Poºadavky jsou základem v²ech systému (nebo by alespo m ly být). Jsou v podstat vyjád ením toho, co by m l systém d lat. Poºadavky by m ly být jediným vyjád ením, co by m l systém d lat, nikoli toho jak by to m l d lat. Dále d lí poºadavky na: funk ní poºadavky nefunk ní poºadavky

2.3. P EHLED STÁVAJÍCÍCH E ENÍ 5 2.2.1 Funk ní poºadavky Funk ní poºadavky popisují o ekávané chování a funk nost systému. V mém systému tedy budou popisovat správu uºivatel, pracovních skupin, projekt a úkol k nim náleºícím. (Obrázek 2.2) Obrázek 2.2: Funk ní poºadavky na systém 2.2.2 Nefunk ní poºadavky Nefunk ní poºadavky se zam ují na omezení pro software i omezení týkající se vývoje. V mém p ípad jsem ur il jako nefunk ní poºadavky denoval poºadavek na multiplatformnost a konkretizoval programovací jazyk. (Obrázek 2.3) 2.3 P ehled stávajících e²ení Existuje jiº spousta systém, které je moºné pro ú ely ízení a vedení projekt pouºít. A uº jde o software nabízený na komer ní bázi i o voln ²i itelný (open source). Já se budu v této ásti zabývat pouze voln ²i itelným softwarem. Také do výb ru za adím pouze webová e²ení, jelikoº ty nejlépe umoºní spolupráci více lidí a odkudkoli. 2.3.1 Trac Trac [13] (v dob psaní práce ve verzi 0.11) je v softwarových rmách hojn vyuºívaným nástrojem. Jedná se o voln ²i itelný software napsaný v jazyce Python. Nabízí integraci v²ech pot ebných v cí pro správu projektu v jednom systému. Pro komunikaci mezi leny týmu a vedení dokumentace je v Tracu wiki systém TracWiki. D leºitou

6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Obrázek 2.3: Nefunk ní poºadavky na systém sou ástí je samoz ejm nástroj pro správu poºadavk, který je v Tracu nazýván TracTicket. Umoº uje nastavit v²echny podstatné informace k poºadavku prioritu, typ, etapu, verzi, komponentu, které se poºadavek týká, apod. Silnou stránkou Tracu je propojení s verzovacími systémy. Trac defaultn podporuje Subversion, nicmén pomocí plugin podporuje v²echny významn j²í verzovací systémy CVS, Mercurial, Git... Ov²em ani Trac není dokonalý a nemusí v n kterých v cech vyhovovat. Trac má hor²í podporu pro více projekt. Umoº uje sice pouze jednu instalaci a tu vyuºívat pro více projekt, není v²ak moºné, aby projekty mezi sebou sdílely informace. S tím souvisí i nemoºnost rozd lení na pracovní skupiny. Instalace Tracu je sloºit j²í a nesnadná pro laiky, obzvlá²t p i prvním zprovoz ování. Obdobn je to s uºivatelským prost edí, které není p íli² uºivatelsky p ív tivé. Trac je také pouze v anglickém jazyku, coº m ºe být pro ur itý typ lidí nevýhodou. Nicmén aktuáln vyvíjená verze 0.12 jiº podporu multijazy nosti zahrnuje, v etn e²tiny. 2.3.2 Redmine Redmine [9] je pom rn nový systémem (od roku 2006) pro management projekt. Na první pohled se zdá zna n inspirován Tracem, je v²ak napsán v Ruby on Rails a vypadá uºivatelsky p ív tiv ji. Nabízí samoz ejm také ve²keré pot ebné funkce pro ízení projekt. Krom Wiki systému a systému pro správu poºadavk nabízí i diskuzní fóra. U poºadavk lze specikovat v²echny d leºité informace, p ípadn m ºeme nadenovat vlastní atributy. Samoz ejmostí je i podpora hlavních verzovacích systém Subversion, CVS, Git, atd. Redmine je i lépe p ípraven pro ízení více projekt. Umoº uje exibilní denování uºivatelský rolí. P íjemnou vlastností je zobrazení kalendá e i Ganttova diagramu. Pro eskou ve ejnost je vhodná i eská lokalizace. Redmine obdobn jako Trac umoº uje roz²í ení pomocí pluginu o dal²í funkce.

2.3. P EHLED STÁVAJÍCÍCH E ENÍ 7 2.3.3 dotproject Pokud budeme brát ohled na erstv za ínající softwarovou rmu, která teprve za íná, pravd podobn ihned nebude pouºívat vlastní server, který je vhodn j²í pro instalace speci- t j²ího software, ale zvolí spí²e webhosting, pokud bude pro dané ú ely dosta ovat. Nejroz²í en j²ím jazykem na takových hostinzích je PHP a jako zástupce systému pro ízení projekt napsaného v PHP jsem zvolil dotproject [6]. dotproject neumoº uje takové moºnosti jako jiº zmi ované produkty. Nabízí jen základní moºnosti pro správu projekt. Umoº uje nadenování projekt a úkol i akcí s nimi spojenými. P íjemná je i správa klient a kontakt na n, které se potom m ºou p i azovat k jednotlivým projekt m. Negativem je slabá podpora správy poºadavk z atribut lze nastavit v podstat pouze prioritu, chybí moºnosti jako komponenta, verze software apod., tím bohuºel tém odpadá jakékoli pokro ilej²í ltrování. Dal²ím minusem je nemoºnost jednoduchého provázání s jakýmkoli systémem pro správu zdrojových kód. 2.3.4 Zhodnocení a záv r re²er²e V této krátké re²er²i jsem se pokusil p edstavit moºná, jiº hotová e²ení, která by mohla softwarová rma pouºít pro ízení projekt. Pokud srovnávané nástroje z funk ního hlediska, jistou volbou by byl Trac i Redmine. Oba software jsou funk n srovnatelné. Nevýhodou v²ak je hor²í zp sob instalace, jelikoº Python i Ruby on Rails není b ºn nabízen klasickými webhostingovými rmami. Pokud bychom cht li n který z t chto dvou provázat s verzovacím systémem, a tím pln vyuºít jejich moºnosti, pak by se nejideáln j²í jevilo pouºít vlastní server. dotproject pravd podobn zvolí spí²e rmy, které nedisponují moºností provozu vlastního serveru a cht jí opravdu jen základní informace o projektech a úkolech s nimi spojenými. Systém Bugtrack má v porovnání s t mito e²ení pravd podobn nejpokro ilej²í moºnosti ltrování a omezuje jej oproti t mto e²ením hlavn nemoºnost v t²í organizovanosti do projekt. Výhodou také m ºe být fakt, ºe je napsán v Jav a nem l by tedy být, díky ²ir²í znalosti tohoto jazyka, v t²í problém nalézt p ípadn n jakého programátora, který by mu porozum l a mohl ho roz²i ovat o dal²í funkcionalitu. Pokud stávající systém Bugtrack roz²í ím o podporu projekt, pracovní skupiny a moºnost svolávat sch zky, bude minimáln konkurenceschopný i v t²ím a stávajícím systém m.

8 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Kapitola 3 Analýza a návrh e²ení V této kapitole se budu zabývat analýzou a návrhem softwaru, který je cílem této bakalá ské práce. Vzhledem k tomu, ºe budu navazovat na software, který jiº funguje. Budu se v návrhu zabývat pouze v cmi, které se týkají mého roz²í ení. Pro bliº²í informace týkající se nejen návrhu jiº hotového softwaru Bugtrack, odkazují na práci Ing. Tomá²e ƒerného [3]. Kniha [1] popisuje rozdíl mezi analýzou a návrhem: Zám rem analýzy (z pohledu objektov orientovaného analytika) je tvorba analytického modelu. Tento model se zam uje na to, co systém musí ud lat, av²ak nezabývá se detaily týkajícími se zp sobu, jakým to ud lá. Tuto otázku p enechává aktivit (pracovnímu postupu) Návrh (Design). 3.1 P ípady uºití P ípady uºití zachycují chování systému a ukazují tak vn j²í pohled na modelovaný systém. P ípady uºití více rozebírají denované poºadavky a konkretizují je denováním jaké osoby daný p ípad vyuºívají. Samoz ejm se zabývají pouze funk ními poºadavky. Diagramy, které zachycují p ípady uºití pro jednotlivé aktory v systému pat í mezi standardní diagramy chování modelovacího jazyka UML. 3.1.1 Akté i Akté i neboli ú astnici jsou osoby (role), které budou v na²em systému pracovat. Já jsem ur il t i role, které budou pot eba: Administrator, Vedoucí pracovní skupiny a ƒlen pracovní skupiny. P i emº vedoucí pracovní skupiny bude specializací lena pracovní skupiny, jelikoº p ebírá jeho p ípady uºití. Kaºdá tato role bude mít spole ného p edch dce Uºivatel, který je ur en pro spole né akce uºivatel jako je p ihlá²ení do systému, odhlá²ení a podobn. 3.1.1.1 Administrátor Administrátor bude mít v systému plnou kontrolu nad osobami, jejich rolemi, nad projekty a úkoly k nim a také nad pracovními skupinami. Jako administrátora si m ºeme p edstavit majitele softwarové rmy. 9

10 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.1: Akté i systému 3.1.1.2 ƒlen pracovní skupiny V softwarové rm je n kolik lidí, kte í d lají na konkrétním projektu, i zakázce, takoví lidé pak tvo í pracovní skupinu. Její lenové pak zpracovávají zadané úkoly, p idávají nové chyby, upravují je apod. ƒlenem pracovní skupiny m ºe být i zákazník, pro kterého je zakázka tvo ena. Ten pak m ºe jednodu²e p idávat nalezené chyby. 3.1.1.3 Vedoucí pracovní skupiny Vedoucí pracovní skupiny má stejné moºnosti jako kaºdý len skupiny. Navíc má v²ak moºnost svolávat týmové porady a sch zky. 3.1.2 P ípady uºití systému V systému budou následující p ípady uºití vzhledem k jednotlivým aktér m: Uºivatel (obrázek 3.2)

3.1. P ÍPADY UšITÍ 11 Obrázek 3.2: P ípady uºití role uºivatel Zobrazit kalendá Administrátor (obrázek 3.3) P idat nový projekt Upravit zaloºený projekt Smazat zaloºený projekt Ukázat v²echny projekty P idat nový úkol k projektu Upravit úkol v projektu Smazat úkol v projektu Vytvo it pracovní skupinu Upravit pracovní skupinu Smazat pracovní skupinu ƒlen pracovní skupiny (obrázek 3.4) Ukázat projekty pracovní skupiny P idat úkol v projektu skupiny Upravit úkol v projektu skupiny Smazat úkol v projektu skupiny Zobrazit události u projektu skupiny Vedoucí pracovní skupiny (obrázek 3.5) Denovat projektovou sch zi Upravit projektovou sch zi Smazat projektovou sch zi

12 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.3: P ípady uºití administrátora 3.1.3 Diagram aktivit Diagram aktivit pat í mezi UML diagramy chování. Tyto diagramy popisují n jakou konkrétní aktivitu jako sled událostí následujících po sob. Diagramy aktivit jsou vhodné i p i modelování tzv. obchodních proces. Níºe uvádím diagramy aktivit pro svolání projektové sch zky (obrázek 3.6) a vytvo ení pracovní skupiny (obrázek 3.7). 3.2 Návrh softwaru V této ásti se budu zabývat samotným návrhem. Nejprve se zam ím na datový model, poté na sekven ní diagramy a zmíním také diagram nasazení. Na záv r této kapitoly se zam ím na samotnou architekturu aplikace.

3.2. NÁVRH SOFTWARU 13 Obrázek 3.4: P ípady uºití lena pracovní skupiny 3.2.1 Datový model Základem kaºdé aplikace je správn navrºený datový model. Datový model p edstavuje v²echny objekty, které v aplikaci vyuºijeme. U webových aplikací jsou tyto objekty zpravidla uloºeny v databázi, a jiº objektové i jsou reprezentovány tabulkami v rela ních databázích. Datový model m ºe mít formu E-R (entity-relationship) diagramu, který zobrazuje hlavní objekty (entity) a vztahy mezi nimi. Je zde brán ohled na fakt, ºe data budou uloºena v reala ní databázi, a proto se zde modelují i podp rné tabulky, které jsou t eba pro mapování vícenásobných vztah mezi entitami. Druhou moºností je návrh datového modelu pomocí UML a t ídního diagramu. Zde se denují objekty a vztahy mezi nimi. Já pouºívám pro analýzu a návrh program Enterprise Architect [7], který umoº uje UML diagram p etransformovat na E-R diagram a vygenerovat p ímo kód pro konkrétní databázový stroj. Proto zvolím jako zp sob tvorby datového modelu UML diagramy. 3.2.1.1 Popis datového modelu EntityObject Spole ný p edek v²ech objekt. Je zde pro zachování integrity se stávajícím systémem. Nyní je zde jen pro evidenci verze daného záznamu. Také bude vhodný p i psaní metod, kdy p jde vyuºít jako generika. Project Jde o jeden z hlavních objekt systému. Tento objekt v sob udrºuje informace o názvu, popisu a datumu, do kdy musí být ukon en. U projekt budou evidovány svolané

14 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.5: P ípady uºití vedoucího pracovní skupiny projektové sch zky a hlavn záznamy poºadavk. Kaºdý projekt bude mít p i azen zákazníka a pracovní skupinu, která na projektu d lá. Meeting Vedoucí pracovní skupiny bude moci svolat projektové sch zky, a tento objekt bude drºet informace o nich. Bude u ní mimo vztahu k projektu uvedeno datum konání, název a n jaký popis. Ke kaºdé sch zce se budou moci p i adit poºadavky, které se zde budou e²it. Workgroup Tento objekt zastupuje pracovní skupiny. Pracovní skupina je útvar, kterému m ºe být p i azen projekt ( i více projekt ), na kterých bude pracovat. Má název, popis, vedoucího a m ºe mít n kolik len. Record Pouºito jiº ze systému Bugtrack. Udrºuje v²echny d leºité informace o konkrétním poºadavku. History Objekt, který bude v sob drºet informace o n kterých úpravách týkajících se poºadavku. Bude v sob drºet informace o tom, kdy daná zm na nastala, u jakého poºadavku. Bude vyuºit hlavn v kalendá i. Stávající e²ení sice zm ny poºadavku zaznamenává, ale jsou zaznamenány pouze jako jeden textový výpis a zaznamenávají se ve²keré zm ny najednou, coº interpretaci do kalendá e siln znesnad uje. Bude proto lep²í pro kaºdou p edem vybranou událost ud lat nový záznam. User Také pouºit ze systému Bugtrack udrºuje informace o osobách v systému. Konkrétn jde o uºivatelské jméno, heslo, role, kontaktní informace a samoz ejm vztah k projekt m i poºadavk m.

3.2. NÁVRH SOFTWARU 15 Obrázek 3.6: Diagram aktivity pro svolání pracovní sch ze 3.2.2 Sekven ní diagramy Sekven ní diagramy pat í mezi diagramy chování nebo také diagramy interakcí jazyka UML. Tento typ popisuje interakce mezi jednotlivými objekty systému v závislosti na ase. Níºe ukazuji dva sekven ní diagramy. Jedná se o vytvo ení projektové sch ze 3.9 a zobrazení, respektive vygenerování, kalendá e 3.10, kde je vid t komunikace nejen s databází (PersistenceManager se stará o samotné fyzické spojení s databází), ale i s ostatními ídícími t ídami pro získání jednotlivých údaj pro kalendá. 3.2.3 Architektura Architektura systému je jiº ovlivn na tím, ºe navazuji na aplikaci Bugtrack. Tato aplikace je naprogramována nad technologií J2EE, neboli v jazyce Java v edici Enterprise, která je zam ena na programování sloºit j²ích systému. Nicmén i p esto, ºe jsem ovlivn n stávajícím e²ením, volil bych totoºné e²ení architektury, jelikoº je t ívrstvá architektura je pravd podobn nejideáln j²í zp sobem pro tento ú el.

16 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.7: Diagram aktivity pro vytvo ení pracovní skupiny Prezenta ní vrstva (presentation layer) je vrstva, která zprost edkovává komunikaci mezi uºivatelem a systémem samotným. Spadá sem hlavn gracké zobrazení (GUI) a výstup programu. Obchodní vrstva (business layer) provádí logiku systém. Je tedy v podstat nejd - leºit j²í sou ástí systému. P ebere data od uºivatele, zpracuje a posune do vrstvy starající se o uloºení, i naopak p ebere data z databázové vrstvy a po zpracování p edá do prezenta ní. Poslední vrstva je databázová vrstva (persistence layer), která se stará o samotný fyzický p ístup do datbáze. ƒasto je reprezentována jako objektov rela ní mapování (ORM), kdy entitní t ídy zastupují jednotlivé tabulky v rela ní databázi. 3.2.4 Diagram nasazení Diagram nasazení ukazuje, jak budou rozd leny zdroje na jakém hardware systém pob ºí a jaké komponenty budou vyuºity. V mém p ípad byl zp sob nasazení ovlivn n systémem Bugtrack. Jako databázový stroj je vyuºita MySQL databáze a jako aplika ní server Jboss, který je pravd podobn nejlep²í volbou pro Seam framework.

3.2. NÁVRH SOFTWARU 17 Obrázek 3.8: Datový model systému

18 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.9: Sekven ní diagram pro vytvo ení projektové sch zky

3.2. NÁVRH SOFTWARU 19 Obrázek 3.10: Datový model systému Obrázek 3.11: T ívrstvá architektura obecn (zdroj: [3])

20 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.12: Diagram nasazení systému

Kapitola 4 Realizace V této kapitole se na úvod zmíním o samotném frameworku SEAM, na kterém je aplikace postavena a o technologiích s ním spojených. Dále se zam ím na n které zajímavosti, p ípadn problémy, na které jsem p í implementaci narazil. 4.1 Framework SEAM Jak jiº bylo zmín no tato aplikace je postavena na frameworku SEAM, který nabádá k t ívrstvé architektu e. Kaºdá vrstva této architektury m ºe být zastoupena v SEAMu n kolika technologiemi i frameworky. SEAM [10] je webový framework, který je ²í en jako open source. Jeho vývoj spadá pod rmu JBoss, která vyvíjí i stejnojmenný aplika ní server JBoss, nicmén b h SEAMu není podmín n tohoto serveru, m ºe b ºet na libovolném serveru podporujícím Javovské technologie. Jedná se o integra ní framework, který spojuje n kolik Java technologií, nap íklad JSF (JavaServer Faces), JPA (Java Persistence API), Hibernate, AJAX (Asynchronous JavaScript and XML), EJB (Enterprise Java Beans) a dal²í. SEAM je primárn zam en na nové moderní webové aplikace. Nasv d uje tomu nejen velká podpora Ajaxu, ale i jednoduchá práce s elektronickou po²tou, podpora PDF apod. 4.1.1 Prezenta ní vrstva V SEAMu se o prezenta ní vrstvu stará JSF, resp. technologie na n m postavené. SEAM umoº uje snadno integrovat tzv. rich komponenty, jedná se o komponenty, které jsou postaveny na technologiích JavaScript a AJAX. O tyto rich komponenty se stará nadstavba JSF - RichFaces i IceFaces, JSF má více t chto nadstaveb, tyto jsou ov²em p ímo podporované SEAMem. V systému, na kterém pracuji v této bakalá ské práci jsou pouºity RichFaces. Dal²í technologií, která je pouºita a je celkem spjata s JSF jsou Facelets. Jedná se o ²ablonovací technologii, která umoº uje sloºit jednodu²e komponenty. Vhodný je nap íklad na denování rozloºení stránek, díky tomu pak nemusí docházet k astému opakování kódu. Výstupem prezenta ní vrstvy je vzhledem k tom, ºe se jedná o webovou aplikaci, klasický HTML (Hypertext Markup Language), CSS (Cascading Stylesheet) a JavaScript. 21

22 KAPITOLA 4. REALIZACE 4.1.2 Obchodní vrstva O obchodní logiku se v SEAMu nej ast ji starají Enterprise Java Beans (EJB), které jsou p ímo podporovány frameworkem. SEAM také obohacuje EJB o n kolik dal²ích vlastností a m ºeme tak vyuºívat práci s transakcemi, webové sluºby, konverzace a dal²í. 4.1.3 Databázová vrstva Databázová vrstva je postavena na technologii JPA. JPA má n kolik implementací, v Bugtracku je vyuºívána implementace Hibernate. JPA je typem ORM, kdy entitní t ídy zastupují fyzickou tabulku v rela ní databázi. Oproti starému p ístupu p es JDBC, kdy je pot eba psát ve²kerý SQL kód pro získání dat, v ORM lze pracovat p ímo s objekty a o samotné SQL dotazy se stará jiº JPA. JPA nabízí i n kolik dal²ích uºite ných vlastností jako je cachování jiº na tených dat, na ítání propojených objekt aº pokud jsou t eba (tzv. lazy fetching), validace na stran serveru, p ípadn pokud je t eba n jaký sloºit j²í dotaz, máme k dispozici HQL, který je podobný SQL. Velkou výhodou je také moºnost jednoduché vým ny databázového stroje v p ípad, ºe nedosta uje ten, na kterém systém b ºí. JPA a v podstat i v t²ina ORM je na databázových strojích nezávislá. Jako samotná databáze je v aplikace vyuºita databáze MySQL. 4.2 Implementa ní detaily V této ásti popí²u d leºité ásti, které bylo t eba upravit na stávajícím e²ení Bugtracku, dále se zam ím pouze na v ci, na kterých jsem strávil del²í as a které byly pro m komplikovan j²í i byly n ím zajímavé. 4.2.1 Úpravy stávajícího e²ení V Bugtracku je v t²ina atribut ukládána jako klasická textová poloºka, coº není vºdy nej² astn j²ím e²ením. Správn j²ím e²ením by bylo drºet si vºdy odkaz (referenci) na objekt, který tuto informaci ponese. Já tyto poloºky zm nil na referenci pouze u t ídy Record - konkrétn author, programmer a tester, kdy sm rovali na instanci t ídy User.Podobným zp sobem jsem upravil i poloºku project, která sm ruje na objekt Project. Samoz ejm bylo t eba upravit i zobrazování v jednotlivých výb rových li²tách u t chto atribut, aby se zobrazovali správné textové reprezentace a ne hashcode objekt. K poºadavk m jsem také p idal moºnost denovat datum, kdy by m l být vy e²en. Po té bylo také t eba upravit v ci ohledn uºivatelských rolí. Jak jiº jsme psal, systém má roli administrátora, nov registrovaného lena zadávajícího poºadavky a pracovníka, který s poºadavky pracuje a m ºe s nimi v²e d lat. Já jsem si ur il mimo administrátora jako role je²t lena pracovní skupiny a vedoucího pracovní skupiny. Nicmén tyto role není t eba zaná²et n jak do systému, jelikoº tyto role vznikají lenstvím / vedením pracovní skupiny. Pouze bylo t eba zajistit, aby mohli více manipulovat a být denováni jako programáto i a teste i pouze lidé z pracovní skupiny onoho projektu, pod který poºadavek spadá.

4.2. IMPLEMENTAƒNÍ DETAILY 23 4.2.2 CRUD operace se stránkováním a azením SEAM nabízí jednoduchou tvorbu webových aplikací, které se starají o tzv. CRUD operace (create-read-update-delete, neboli klasická manipulace s daty, kdy dochází pouze k na- ítání, p ídání, úprav a smazání dat). Jedná se o t ídy EntityHome a EntityList, které mimo t chto operací zaji² ují i stránkování a azení výsledk. e²il jsem problém zda vyuºít tyto t ídy a roz²i ovat od nich nové, které budu tvo it. Nakonec jsem v²ak zjistil, ºe bych metody týkající se t chto operací, hlavn p idávání, upravování a mazání musel asto p ekrývat a z velké ásti p episovat. Proto jsem vyuºil primárn abstraktní t ídy GeneralManager, která byla p ipravena jiº v systému Bugtrack a implementovala v²echny pot ebné metody, pouze metody pro samotné ukládání a vytvo ení nového záznamu z staly abstraktní a vyºadují napsání t la aº p i samotné implementaci. Jako hlavní t ídu pro dal²í implementaci ídících t íd jsem vyuºil tedy GeneralManager, nicmén bylo t eba vy e²it také problém azení a stránkování. Roz²í il jsem tedy General- Manager a vytvo il z ní PaginatedGeneralManager, který jsem zvolil jako nového p edka pro t ídy pro n º je stránkování a azení výsledk vhodné. U azení výsledk si bylo t eba také poradit se skute ností, ºe atribut podle kterého se bude adit je p edáván v adrese a n kdo nepovolaný tam m ºe umístit co chce. Proto bylo t eba vy e²it aby se adilo opravu jen podle atribut, které jsou pro to ur eny. Nejprve jsem tedy vºdy implementoval metodu, jenº vytvo ila mapu kdy k parametru z adresy byl p i azen atribut podle n hoº adit. Takto vypadá mapa, která adí výsledky u projektu: protected Map<String, String> createmap() { Map<String, String> result = new HashMap<String, String>(); result.put("id", "id"); result.put("name", "name"); result.put("customer", "customer.username"); result.put("workgroup", "workgroup.name"); return result; } Dále bylo t eba vytvo it metodu, která vytáhne z této mapy správný atribut pro azení. O to se postará metoda getreadyorder(), která vrátí výsledek, pokud parametr existuje v map a je správn nastaveno zda se má adit vzestupn i sestupn. protected String getreadyorder() { String ordersql = null; String[] order = getorder().tolowercase().split(" "); //získám parametr z adresy a zmen²ím na malá písmena if(ordermap.containskey(order[0]) && ("asc".equals(order[1]) "desc".equals(order[1])) ){ ordersql = ordermap.get(order[0]) + " " + order[1]; } else { throw new IllegalArgumentException("Bad order argument");

24 KAPITOLA 4. REALIZACE } } return ordersql; Pokud jsem cht l adit výsledky, nabízelo se vyuºít parametrizovaných dotaz a tedy sestavit dotaz a nastavit atribut, podle kterého budu adit. Takto by vypadalo azení projekt : Query q = getentitymanager().createquery("from Project allprojects order by :orderparameter"); q.setparameter("orderparameter", this.map.get(getreadyorder())); Bohuºel JPA ov²em neumoº uje pouºívat parametry jinde neº v podmínce WHERE. Bylo tedy t eba sloºit dotaz jiº jako parametr metody createquery() v EntityManager. Query q = createquery("from Project allprojects order by " + getreadyorder()); Co se tý e stránkování. Zde se o nastavení stránkování, respektive získání adekvátních dat stará metoda setfirstresult() EntityManagera. Op t tedy bylo t eba tento parametr p edat v URL adrese. O zobrazení stránkování se postaral tag v tablepagination jmenném prostoru util, který je jiº podobn vyuºit u stránkování záznam s poºadavky. 4.2.3 Kalendá V kalendá i jsem si v analýze denoval, ºe by bylo dobré v n m zobrazovat informace jako je as konání projektových sch zí, datum poºadovaného ukon ení a zm ny nastalé v jednotlivých poºadavcích pat ících k projekt m, v kterých je p ihlá²ený uºivatel lenem. Mezi tyto události jsem denoval: zm nu stavu poºadavku zm nu autora, programátora i testera otev ení i zav ení poºadavku (uzav eným je poºadavek povaºován, pokud nemá stav "NEW" i "ACTIVE" a zm na byla potvrzena stiskem tla ítka "Checked") Pokud bych ve²keré události projekt, v nichº je p ihlá²ený uºivatel lenem vypsal najednou, byl by kalendá p epln n, u inil jsem tedy rozhodnutí, ºe ve výchozím nastavení se budou zobrazovat pouze sch zky a datum do kdy má být poºadavek hotový, pokud je stanoven. Je zde v²ak umíst n ltr, v kterém lze nastavit i zobrazování dal²ích událostí, které jsem zde denoval. T ídu starající se o kalendá jsem denoval jako Stateful Session Beanu s uloºením do session. Je to z d vodu, aby se pamatoval stav ltru a také na jakém m síci a roku uºivatel zrovna je. Pokud se proklikne z kalendá e n kam jinam, a pak se bude chtít vrátit je vhodné aby byl p esn tam kde s kalendá em skon il. Nicmén bylo t eba zajistit, aby byl kalendá aktuální p i kaºdém zobrazení (coº by nemuselo být zaru eno, pokud by byl celý uloºen v session, uºivatel zm nil nap íklad stav poºadavku a vrátil se zp t do kalendá e), proto se vºdy generuje znovu p i na ítání stránky. To zajistí jeden ádek v XML souboru pro stránku zobrazující kalendá :

4.3. GUI 25 <action execute="#{calendarmanager.generatecalendar}"/> Co se tý e prezetna ní vrstvy u kalendá e. Cht l jsem vyuºít tagu calendar z RichFaces, který dle demoverze [5] umoº uje denovat takový kalendá jaký bych pot eboval. Bohuºel v²ak umoº uje denovat pouze jednu poloºku ke kaºdému datumu. To by ²lo e²it p edp ipravením jedné velké textové informace, ale nebylo by to p íli² exibilní a lep²ím e²ením proto bylo vytvo it takový kalendá od základu znovu. 4.3 GUI Gracké uºivatelské rozhraní jsem se sanºil zachovat ve stejném duchu a stylu jako m l systém Bugtrack. Obecn vzhled systému je zanechán podobný aº stejný, jako po vygenerováni kostry aplikace pomocí seam-gen s volbou RichFaces. Obrázek 4.1: GUI - zobrazení detailu projektu Uvádím obrázky detailu projektu, kde jsou obecné informace o projektu, projektové sch ze i poºadavky pat ící k danému projektu (obrázek 4.1) a pohledu na kalendá (obrázek 4.2).

26 KAPITOLA 4. REALIZACE Obrázek 4.2: GUI - zobrazení kalendá e

Kapitola 5 Testování V této ásti se zam ím na n které zp soby, jakými jsou testovány aplikace a jak jsem já konkrétn testoval systém. 5.1 Jednotkové testování Jednotkové testování (unit testing) je druhem testování software na tém nejniº²í úrovni, kdy se testují jednotky software. V Jav pat í mezi nejznám j²í zástupce JUnit [8] i nov j²í TestNG [12]. V objektov orientovaném kódu se jedná o jednotlivé t ídy, i pouze samotné metody t ídy. Základem je to, aby byly jednotky testovány bez jakéhokoli kontextu. To je u webových aplikací asto problém a obecn h e se testují. Jde tímto zp sobem testovat v podstat pouze obchodní logika. Problém ov²em nastává, pokud obchodní logika pracuje s databází. To uº totiº není bez kontextu a je t eba mít bu vºdy stejný p edp ipravený obsah v databázi nebo vyuºít tzv. fale²né (mock) objekty. Ty mají na starost simulovat p edpokládaný kontext. Komplikace v²ak nastávají u v t²ích systém, kdy je t chto mock objekt mnoho a dochází tak k sloºitému nastavování jen testovacího prost edí. TODO: Zde pokud bude dostatek asu ukáºu n jaký unit test. Zatím se mi neda í zprovoznit nástroj pro Unit testování. Pot ebuji v²ak je²t doladit n jaké v ci v samotné aplikaci a BP. ƒi-li pokud zbude dostatek asu a bude více ²t stí se zprovozn ním sna tu p ibude. 5.2 Uºivatelské testování Uºivatelské testování je v podstat nejjednodu²²í a asto i nejúsp ²n j²í. Jedná se o to, ºe se uºivatel posadí k aplikaci a prochází ji, pracuji s ní, plní daty apod. Snaºí se jednodu²e simulovat práci lov ka, který se systémem bude ve výsledku pracovat. Moje aplikace podléhala n kolikrát uºivatelskému testování. Samoz ejm vºdy kdyº p ibyla n jaká nová funkcionalita, otestoval jsem, zda pracuje tak jak má. Ke konci kdyº byl projekt jiº tém hotov jsem vyuºival tzv. systém dogfooding. Jedná se o princip, kdy samotní tv rci vyuºívají produkt, který vyuºívají. Nadenoval jsem si projekt s názvem Bakalá ská 27

28 KAPITOLA 5. TESTOVÁNÍ práce, ur il pracovní skupinu, zaná²el nalezené chyby a v ci, co mají být dod lány. Aplikaci jsem také ukázal n kolika osobám, které jsou v potencionální cílové skupin (konkrétn programáto i) a po stru ném seznámení systém bez problému ovládali. Toto testování odhalilo n kolik chyb, jako nap íklad ²patné p edávání parametr mezi jednotlivými stránkami, vypisování informací, které jiº se vypisovat nem li (kv li nekonzistentnímu stavu chache EntityManagera a dat m v databázi, apod. 5.3 Automatizované testování Uºivatelské testování je jist dobrým zp sobem jak otestovat aplikace bez jakýchkoli velkých investic. Na druhou stranu v n kterých p ípadech m ºe jít o nevhodný zp sob test. Mám na mysli nap íklad postupy, kdy se vyplní formulá, stiskne tla ítko pro uloºení, zkontroluje, zda k uloºení opravdu do²lo a podobn. V tomto p ípad je jist vhodn j²í toto testování zautomatizovat n jakým robotickým nástrojem, který je pro tento zp sob vytvo- ený. Jedná se o typ black-box ( erná sk í ka) testování. Nástroj neví nic o implementaci, pouze testuje to co vidí. 5.3.1 Selenium IDE Selenium IDE [11] je nástroj ur ený pro testování webových aplikací. Je implementován jako roz²í ení pro internetový prohlíºe Mozilla Firefox. Práce se tímto nástrojem je obdobná jako u dal²ích program zam ených na automatizované testování. Nejprve se zaznamenají akce (klikání, stisky kláves, apod.), které vznikají b hem nahrávání, p ípadn je m ºeme sami naskriptovat. Potom se test ( i testovací sada) spustí, prob hne a sd lí nám výsledek, zda byl test úsp ²ný i nikoli. Selenium IDE je postaveno na JavaScriptu a pracuje s DOMem HTML stránky, coº m ºe být problém, pokud se n kdy pozd ji zm ní rozvrºení stránky. To je ov²em u v t²iny (myslím i testovací nástroje pro desktopové aplikace) program pro automatizované testování. Údrºba testovacích skript je v podstat jedinou nevýhodou. TODO: Zde bude n kolik tabulek jako je tahle jedna níºe. Pravd podob n v²ak jen z jednoho testovacího scéná e - týkající se projektu a meetingu

5.3. AUTOMATIZOVANÉ TESTOVÁNÍ 29 P idání nového projektu Podmínky testu: p ihlá²ený uºivatel s administrátorskými právy Akce O ekávaný výsledek Výsledek V menu klikneme na odkaz Projects Zobrazí se p ehled projekt OK Klikneme na tla ítko Add Project Zobrazí formulá pro p idání projektu OK Klikneme na tla ítko Save Systém ohlásí, ºe nejsou vypln ny povinné OK údaje (název a pracovní skupina) Vyplníme pole Name (Test project) vybereme Formulá vypln n OK pracovní skupinu Klik na tla ítko Save Systém zobrazí p ehled projekt OK v etn nov zaloºeného (Test project) Tabulka 5.1: Testovací p ípad: P idání nového projektu

30 KAPITOLA 5. TESTOVÁNÍ

Kapitola 6 Záv r Cílem této bakalá ské práce bylo seznámení se zp soby ízení projekt a na základ t chto znalostí a vlastních zku²eností, které jsem nabyl mimojiné i v r zných projektových týmech, analyzovat a následn implementovat systém, jenº ízení a správu projekt umoºní, respektive usnadní. Myslím si, ºe tento cíl byl napln n. Po popsání obvyklého stylu práce jsem tená e této práce seznámil se systémem Bugtrack, který budu o funkcionalitu ízení projektu roz²i ovat. Následn jsem denoval poºadavky, které by m l systém ohledn projekt spl ovat, provedl jsem krátkou re²er²i nejznám j²ích stávajících e²ení, konkrétn Tracu, Redmine a dotprojectu. Dále byla provedena implementace s pomocí frameworku SEAM. Výsledná aplikace podporuje práci s projekty v etn denic událostí jako jsou týmové sch zky a porady, pracovní skupiny pracující na jednotlivých projektech a samoz ejm práci s jednotlivými poºadavky. Výsledky jsou mimojiné zobrazovány v p ehledním kalendá i pro jednotlivé p ihlá²ené uºivatele. Myslím, ºe nyní systém Bugtrack m ºe minimáln slu²n konkurovat e²ením, která jsem popsal v re²er²i. Nicmén dovedu si p edstavit r zná vylep²ení, která by jej do budoucna mohla zdokonalit. Zmíním nap íklad napojení na verzovací systémy a s tím spojené uzavírání chyb / poºadavk nahráním (commitem) nové verze. Dal²í zlep²ení by mohlo být ve sm ru r zných report, a uº k otev ení p ímo z webu, i zasílaných na elektronickou adresu. 31

32 KAPITOLA 6. ZÁV R

Literatura [1] J. ARLOW and I. NEUSTADT. UML 2 a unikovaný proces vývoje aplikací: Objektov orientovaná analýza a návrh prakticky. Computer Press a. s., 2nd edition, 2007. [2] N. Peter and B. Randell, editors. Software engineering: Report of a conference sponsored by the NATO Science Committee. NATO SCIENCE COMMITTEE, 1968. [3] T. ƒerný. Systém pro správu projektu Bug tracking system. Master's thesis, ƒeské vysoké u ení technické v Praze - Fakulta elektrotechnická, 2009. [4] Domovská stránka projektu Bugtrack. http://bug-track.sourceforge.net. [5] Ukázka vyuºití RichFaces kalendá e jako organizéru. http://livedemo.exadel.com/richfaces-demo/richfaces/calendar.jsf. [6] Domovská stránka projektu dotproject. http://www.dotproject.net/. [7] Domovská stránka programu Enterprise Architect. http://www.sparxsystems.com/products/ea/. [8] Domovská stránka projektu JUnit. http://www.junit.org. [9] Domovská stránka projektu Redmine. http://redmine.org. [10] Domovská stránka frameworku SEAM. http://seamframework.org/. [11] Domovská stránka projektu Selenium. http://seleniumhq.org//do. [12] Domovská stránka projektu TestNG. http://testng.org/. [13] Domovská stránka projektu Trac. http://trac.edgewall.org/. 33

34 LITERATURA

P íloha A Seznam pouºitých zkratek AJAX - Asynchronous JavaScript and XML CSS - Cascading StyleSheet EJB - Enterprise Java Beans GUI - Graphical User Interface HQL - Hibernate Query language HTML - HyperText Markup Language J2EE - Java 2 Enteprise Edition JDBC - Java Database Connector JSF - Java Server Faces JPA - Java Persistence API ORM - Object-relational mapping PDF - Portable Document File SQL - Structured query language URL - Uniform Resource Locator. 35

36 P ÍLOHA A. SEZNAM POUšITÝCH ZKRATEK

P íloha B Instala ní a uºivatelská p íru ka Tato p íloha velmi ºádoucí zejména u softwarových implementa ních prací. 37

38 P ÍLOHA B. INSTALAƒNÍ A UšIVATELSKÁ P ÍRUƒKA

P íloha C Obsah p iloºeného CD Tato p íloha je povinná pro kaºdou práci. Kaºdá práce musí totiº obsahovat p iloºené CD. Viz dále. M ºe vypadat nap íklad takto. Vá² seznam samoz ejm bude odpovídat typu va²í práce. (viz [?]): Obrázek C.1: Seznam p iloºeného CD p íklad Na GNU/Linuxu si strukturu p iloºeného CD m ºete snadno vyrobit p íkazem: $ tree. >tree.txt Ve vzniklém souboru pak sta í pouze doplnit komentá e. 39

40 P ÍLOHA C. OBSAH P ILOšENÉHO CD Z README.TXT (p ípadne index.html apod.) musí být rovn º z ejmé, jak programy instalovat, spou²t t a jaké poºadavky mají tyto programy na hardware. Adresá text musí obsahovat soubor s vlastním textem práce v PDF nebo PS formátu, který bude pozd ji pouºit pro prezentaci diplomové práce na WWW.