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, speci kace cíle
3
2.1 2.2
2.3
Popis problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Bugtrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Poºadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.2
Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
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í 3.1
3.2
9
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
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 4.1
4.2
4.3
21
Framework SEAM . . . . . . . . . . . 4.1.1 Prezenta£ní vrstva . . . . . . . 4.1.2 Obchodní vrstva . . . . . . . . 4.1.3 Databázová vrstva . . . . . . . Implementa£ní detaily . . . . . . . . . 4.2.1 Úpravy stávajícího °e²ení . . . 4.2.2 CRUD operace se stránkováním 4.2.3 Kalendá° . . . . . . . . . . . . GUI . . . . . . . . . . . . . . . . . . .
. . . . . . a . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . °azením . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
5 Testování 5.1 5.2 5.3
Jednotkové testování . . . Uºivatelské testování . . . Automatizované testování 5.3.1 Selenium IDE . . .
21 21 22 22 22 22 23 24 25
27 . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
27 27 28 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 2.2 2.3
Ukázka stávajícího systému Bugtrack - p°ehled poºadavk· . . . . . . . . . . . Funk£ní poºadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . . Nefunk£ní poºadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12
Akté°i systému . . . . . . . . . . . . . . . . . . . . . P°ípady uºití role uºivatel· . . . . . . . . . . . . . . P°ípady uºití administrátora . . . . . . . . . . . . . . P°ípady uºití £lena pracovní skupiny . . . . . . . . . P°ípady uºití vedoucího pracovní skupiny . . . . . . Diagram aktivity pro svolání pracovní sch·ze . . . . Diagram aktivity pro vytvo°ení pracovní skupiny . . Datový model systému . . . . . . . . . . . . . . . . . Sekven£ní diagram pro vytvo°ení projektové sch·zky Datový model systému . . . . . . . . . . . . . . . . . T°ívrstvá architektura obecn¥ (zdroj: [3]) . . . . . . Diagram nasazení systému . . . . . . . . . . . . . . .
4.1 4.2
GUI - zobrazení detailu projektu . . . . . . . . . . . . . . . . . . . . . . . . . 25 GUI - zobrazení kalendá°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
4 5 6 10 11 12 13 14 15 16 17 18 19 19 20
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 de nová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, speci kace 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¥ de nované 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 de novat 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á de nované 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 de novány pouze jako textová poloºka, bude t°eba je de novat jako samostatný objekt. Dal²í roz²í°ení se bude týkat pracovních skupin. V softwarových rmách je £asto de novaná 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 de novat 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 de nová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.
PEHLED STÁVAJÍCÍCH EENÍ
2.2.1
5
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 de noval 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 speci kovat v²echny d·leºité informace, p°ípadn¥ m·ºeme nade novat 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í de nová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.
PEHLED STÁVAJÍCÍCH EENÍ
2.3.3
7
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 nade nová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í de nované poºadavky a konkretizují je de nová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 EENÍ
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.
11
PÍPADY UITÍ
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) • De novat projektovou sch·zi • Upravit projektovou sch·zi • Smazat projektovou sch·zi
12
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
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 de nují 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áva-
jí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 EENÍ
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. Kon-
kré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 EENÍ
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¥ gra cké 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.
17
NÁVRH SOFTWARU
Obrázek 3.8: Datový model systému
18
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.9: Sekven£ní diagram pro vytvo°ení projektové sch·zky
3.2.
NÁVRH SOFTWARU
Obrázek 3.10: Datový model systému
Obrázek 3.11: T°ívrstvá architektura obecn¥ (zdroj: [3])
19
20
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
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 de nová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.
4.1.2
REALIZACE
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 de novat 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 de nováni jako programáto°i a teste°i pouze lidé z pracovní skupiny onoho projektu, pod který poºadavek spadá.
4.2.
IMPLEMENTANÍ DETAILY
4.2.2
23
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 GeneralManager 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() EntityManager a. 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 de noval, º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 de noval:
• 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 de noval. T°ídu starající se o kalendá° jsem de noval 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.
25
GUI
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 de novat takový kalendá° jaký bych pot°eboval. Bohuºel v²ak umoº¬uje de novat 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
Gra cké 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.
Obrázek 4.2: GUI - zobrazení kalendá°e
REALIZACE
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í. Nade noval 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 EntityManager a 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.
29
AUTOMATIZOVANÉ TESTOVÁNÍ
P°idání nového projektu Akce
Podmínky testu: p°ihlá²ený uºivatel s administrátorskými právy O£ekávaný výsledek
V menu klikneme na odkaz Projects Klikneme na tla£ítko Add Project Klikneme na tla£ítko Save
Vyplníme pole Name (Test project) vybereme pracovní skupinu Klik na tla£ítko Save
Zobrazí se p°ehled projekt· Zobrazí formulá° pro p°idání projektu Systém ohlásí, ºe nejsou vypln¥ny povinné údaje (název a pracovní skupina) Formulá° vypln¥n Systém zobrazí p°ehled projekt· v£etn¥ nov¥ zaloºeného (Test project)
Tabulka 5.1: Testovací p°ípad: P°idání nového projektu
Výsledek OK OK OK OK OK
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 de noval 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¥ de nic 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 uni kovaný 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 http://www.sparxsystems.com/products/ea/.
Enterprise
[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
Architect.
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 J2EE
- HyperText Markup Language
- 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 POUITÝ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.
INSTALANÍ A UIVATELSKÁ PÍRUKA
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 PILOENÉ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.
