MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345 Webová aplikace pro ˇrízeníprojekt ˚u a správu úloh DIPLOMOVÁ PRÁCE Martin Pešout Brno, jaro 2009 Prohlášení Prohlašuji, že tato diplomová práce je mým p ˚uvodnímautorským dílem, které jsem vypra- coval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování použí- val nebo z nich ˇcerpal,v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušnýzdroj. Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D. ii Podˇekování Dˇekujipanu RNDr. Radku Ošlejškovi, Ph.D. za odbornou pomoc a rady pˇri finálních úpra- vách mé práce. Dále také všem, kteˇríjakoukoli mˇerou pˇrispˇelik jejímu dokonˇcení. iii Shrnutí Cílem diplomové práce je prostudování a porovnání souˇcasnýchnástroj ˚upro správu uži- vatelských požadavk ˚ua ˇrízeníúloh. Na základˇezjištˇenýchpoznatk ˚ubude namodelován vlastní systém bˇežícíjako webová aplikace. Práce se také zamˇeˇrujena popis jeho implemen- tace. Pro snazší pochopení je text ilustrován ˇradouUML diagram ˚u. iv Klíˇcováslova Ruby on Rails, MVC architektura, metoda HIT, projekt, projektové ˇrízení v Obsah 1 Úvod ...... 1 2 Rízeníˇ projekt ˚ua správa úloh ...... 2 2.1 Pojmy ...... 2 2.2 Co nabízejí souˇcasnáˇrešení? ...... 3 2.2.1 Poˇcítaˇcovéaplikace ...... 5 2.2.2 Open-source nástroje ...... 6 2.2.3 Webové nástroje ...... 6 2.3 Porovnání existujících nástroj ˚u ...... 6 2.3.1 Basecamp ...... 7 2.3.2 Tick ...... 8 2.3.3 The Trac Project ...... 8 2.3.4 Redmine ...... 9 2.4 Proˇcpsát vlastní systém? ...... 10 3 Jazyk a nástroje pro návrh systému ...... 12 3.1 Programovací jazyk Ruby ...... 12 3.1.1 Oblíbenost tohoto nástroje ...... 12 3.1.2 Vše, na co si vzpomenete, je objektem ...... 13 3.1.3 Flexibilita ...... 14 3.1.4 Zpestˇrenízdrojového kódu ...... 14 3.2 Architektura MVC ...... 15 3.3 Webový framework Ruby on Rails ...... 16 3.3.1 Základní vlastnosti ...... 17 3.3.2 Generátory ...... 18 3.3.3 Použití databáze ...... 18 3.3.4 Tvorba interaktivních aplikací ...... 20 3.3.5 Podpora více jazyk ˚u ...... 21 3.3.6 Vylepšení aplikace pomocí plugin ˚u ...... 22 3.3.7 Testování ...... 22 4 Modelování databázového schématu ...... 23 4.1 Entitnˇe-relaˇcnímodel ...... 23 4.2 Datové modelování metodou HIT ...... 24 4.2.1 Konceptuální model ...... 24 4.2.2 HIT jako rozšíˇreníentitnˇe-relaˇcníhomodelu ...... 27 4.3 Využití metody HIT pˇrinávrhu našeho systému ...... 27 5 Analýza a návrh systému ...... 29 5.1 Rozdˇeleníaplikace ...... 29 5.2 Seznam aktér ˚u ...... 30 5.2.1 Administrátor ...... 30 5.2.2 Uživatel ...... 30 5.3 Modely pˇrípad˚uužití ...... 30 vi 5.3.1 Modul systémových nastavení ...... 31 5.3.2 Modul CRM ...... 32 5.3.3 Modul projektového ˇrízení ...... 35 5.4 Diagram tˇríd ...... 38 5.4.1 Evidence zmˇen ...... 38 5.4.2 Modul CRM ...... 39 5.4.3 Modul projektového ˇrízení ...... 42 6 Rozhraní pro práci se systémem ...... 46 6.1 Navigace ...... 46 6.2 Dynamické stránky ...... 47 6.3 Nápovˇeda ...... 49 6.4 Optimalizace pro internetové prohlížeˇce ...... 50 7 Implementace ...... 51 7.1 Nasazení systému ...... 51 7.2 Webový server ...... 52 7.3 Databázový server ...... 53 7.4 Programovací jazyk ...... 53 8 Závˇer ...... 55 A Obsah pˇriloženéhoCD ...... 56 B HIT-model popisující strukturu modulu projektového ˇrízení ...... 57 Literatura a odkazy ...... 62 Rejstˇrík ...... 63 vii Kapitola 1 Úvod Plánování projekt ˚uuž dávno neobnáší veliké množství papírování. Informaˇcnítechnologie zde mají v tomto smˇeru své nezastupitelné místo. V souˇcasnédobˇem ˚užeuživatel vybírat z velikého množství sofistikovaných aplikací umožˇnujícíchˇrízeníprojekt ˚ua správu úloh. Dnešní firmy, které pracují na nˇekolika projektech, jsou ˇcastonuceny ˇrešitzásadní problém, a to, jak to udˇelat,aby svému zákazníkovi ve smlouvˇenepodepsaly nerealistické termíny, nepodcenily náklady nebo neslibovaly vyˇrešitpovˇestné„hodinky s vodotryskem“. Zp ˚u- soby ˇrešenítˇechtosituací ˇcastovytváˇrídobré jméno firmy. Vˇetšinouse používají nástroje, které se snaží proces plánování ulehˇcita zefektivnit. Otázkou však z ˚ustává,jak poznáme, že se jedná o kvalitní software, vyhovující našim požadavk ˚um?Nalezení odpovˇediby mˇelo být jedním z úkol ˚utéto práce. Hlavním cílem je pˇredevšímprostudování a porovnání souˇcasnýchnástroj ˚upro správu uživatelských požadavk ˚ua ˇrízeníúloh. Na základˇezjištˇenýchpoznatk ˚ubude následnˇespe- cifikován a namodelován vlastní systém bˇežícíjako webová aplikace a starající se o správu a ˇrízeníprojekt ˚u.Výsledná aplikace bude pak uplatnˇenave spoleˇcnostiIglooNET, s.r.o. V první ˇcástipráce bude ˇctenáˇrnejprve seznámen s danou problematikou a bude mu pˇriblí- žena zvolená metoda modelování struktury systému. Dále budou upˇresnˇenynástroje pou- žité v procesu vývoje. Druhá ˇcástpráce se zamˇeˇrípˇredevšímna analýzu jednotlivých mo- dul ˚ua blíže popíše zp ˚usob,jak se podaˇriloaplikaci nasadit do ostrého provozu. 1 Kapitola 2 Rízeníˇ projekt ˚ua správa úloh 2.1 Pojmy Než se zaˇcnehovoˇrito konkrétních pˇríkladechaplikací, je nutné si ujasnit, jaký je význam samotných pojm ˚uprojekt, projektové ˇrízenía k jakému úˇcelujsou nástroje pro projektové ˇrízeníurˇceny. Pod pojmem projekt se skrývá oznaˇcenídoˇcasnéhoúsilí vynakládaného k vytvoˇreníjedi- neˇcnéhoproduktu nebo služby. Má pevnˇedaný cíl, zaˇcáteka konec. Zdroje na jeho realizaci jsou omezené, a protože se vymyká bˇežnédenní praxi, není pˇredemjistý jeho výsledek. Pˇrí- kladem projektu r ˚uznéhorozsahu m ˚užebýt tvorba nové webové stránky, stavba rodinného domu nebo i uspoˇrádaníkulturního odpoledne pro dˇeti[11]. Pro srovnání následuje ještˇe definice projektu podle ISO 10006 [3]: Projekt je jedineˇcnýproces sestávající z ˇradykoordinovaných a ˇrízenýchˇcin- ností s daty zahájení a ukonˇcení,provádˇenýpro dosažení cíle, který vyhovuje specifickým požadavk ˚um,vˇcetnˇeomezení daných ˇcasem,náklady a zdroji. Co se týˇceprojekt ˚ua jejich plánování, pokaždé je nutné položit si základní otázku (tzv. trojimperativ), a to: „Co, kdy a za kolik?“. Odpovˇedˇetna ni se pokusil Harold Kerzner (Ph.D., MS, Engineering and MBA), který stanovil takzvaný magický trojúhelník, ve kterém dává do vztahu výkon/kvalitu, ˇcasa náklady [10]. Pokud bude zákazník chtít zkrátit ter- míny, musí poˇcítats tím, že dojde k navýšení náklad ˚ua nebo ke snížení kvality výsledného produktu. Pˇrisnaze o navýšení kvality se musí naopak poˇcítats prodloužením termín ˚ua nebo s nutným r ˚ustemnáklad ˚u.Z pohledu zákazníka je však zˇrejmé,že vždy bude pˇreva- žovat snaha o co nejkvalitnˇejšíprodukt dodaný v krátkém ˇcasea s využitím co nejnižších náklad ˚u. Tyto tˇrifaktory (ˇcas,náklady a výkon ˇcikvalita) a jejich vzájemná provázanost mají po- mˇernˇezásadní vliv na plánování a pr ˚ubˇehdokonˇcováníkaždého projektu. Nicménˇenení to jediný problém, který se m ˚užepˇriplánování projekt ˚uobjevit. Každá organizace, která se pak zabývá tvorbou urˇcitýchhodnot a realizující vlastní skupinu projekt ˚u,je dˇrívenebo pozdˇejipostavena do situace, kdy ˇreší,jak nejlépe dosáhnout nˇekolikacíl ˚u: • snížení potˇrebnýchnáklad ˚u • zvládnutí projektu v co nejkratším ˇcasea v pˇredemurˇcenýchtermínech realizace 2 2.2. CO NABÍZEJÍ SOUCASNÁˇ REŠENÍ?ˇ Obrázek 2.1: Magický trojúhelník podle Harloda Kerznera • snížení možných rizik projektu a vypracování plán ˚uco dˇelat,pokud nastanou • efektivní využití zdroj ˚u • generování co nejvˇetšíhozisku • zvýšení kvality produkt ˚u A právˇepro úspˇešnévedení projektu je nezbytné d ˚usledné,pˇrimˇeˇrenˇedetailní a zároveˇn realistické plánování. Tak se dá dosáhnout toho, že se nám pr ˚ubˇehprojektu nevymkne kon- trole a nedojde tak napˇríkladk navýšení náklad ˚uoproti p ˚uvodnímodhad ˚umnebo k ne- splnˇenítermín ˚uodevzdání. Celkovˇeˇreˇceno,jedná se o proces, ve kterém jednotlivci nebo organizace využívají své zdroje k realizaci projekt ˚u.Tento proces pak souhrnnˇeoznaˇcujeme pojmem projektové ˇrízení. Velké uplatnˇenív tomto procesu dostává metoda kritické cesty. Je to jeden z d ˚uležitých nástroj ˚uˇrízeníprojekt ˚u. Címˇ se vlastnˇetato metoda zabývá? Kritická cesta je posloupnost úkol ˚u(nebo i jediný úkol), kterou je urˇcenovypoˇcítanédatum dokonˇceníprojektu. To zna- mená, že po splnˇeníposledního úkolu na kritické cestˇeje projekt dokonˇcen.Pokud je známa kritická cesta projektu a zdroje pˇriˇrazenéke kritickým úkol ˚um,lze urˇcit,které úkoly mohou ovlivnit datum dokonˇceníprojektu a zda budou slíbené termíny vˇcassplnˇeny[1]. Pro lepší ˇrízeníprojekt ˚use ve firmách postupnˇezaˇcalypoužívat nástroje pro ˇrízenípro- jekt ˚u.Vˇetšinouse jedná o zvláštní software, který je urˇcenýpro tyto úˇcely. Zahrnuje roz- manité aplikace podporující snadné plánování, správu náklad ˚ua rozpoˇctu,spolupráci jed- notlivých úˇcastník˚u,alokaci zdroj ˚u,rychlou komunikaci ˇcitvorbu projektové dokumentace. Všechny tyto aplikace mají jedno spoleˇcné- usnadˇnujísdílení informací. 2.2 Co nabízejí souˇcasnáˇrešení? V této ˇcástibude rozebráno, co nám mohou souˇcasnáˇrešenínabídnout a ˇcímmohou pˇrispˇet k snazšímu vedení projektu do zdárného cíle [9]. Jádrem vˇetšinyaplikací bývají nástroje 3 2.2. CO NABÍZEJÍ SOUCASNÁˇ REŠENÍ?ˇ pro samotné projektové ˇrízení(Project management software). Ty nám poskytují možnosti založení projektu vˇcetnˇepˇriˇrazeníodpovídajících rolí, pˇriˇrazenídisponibilních zdroj ˚ua za- dávání úkol ˚uˇclen˚umtýmu. D ˚uležitáje možnost kontroly plnˇeníjednotlivých úkol ˚u. Castoˇ je možné se setkat i s funkcemi pro vyplnˇení,odeslání a následného schvalování pracovního výkazu. Ve výsledku dostává projektový manager širší pohled na celý projekt a je schopen sestavit jednotlivé úkoly tak, aby bylo snazší splnˇenídaných termín ˚u.Velice využívaným pomocníkem pˇritomto zp ˚usobuplánování je již zmínˇenámetoda kritické cesty. Ve spoustˇe aplikací je kritická cesta zobrazena pomocí Ganttova diagramu. Obrázek 2.2: Ukázka Ganttova diagramu Nástroje pro projektové ˇrízeníjdou ruku v ruce s nástroji pro zajištˇeníspolupráce úˇcast- ník ˚uprojekt ˚u(Collaborative software). Pro zajištˇenívˇcasnéinformovanosti uživatel ˚uje d ˚u- ležitá rozumná forma upozorˇnovánína zmˇeny. Rozumná je zde uvedena proto, že pokud nebude informovanost jednotlivých ˇclen˚udostateˇcná,málokdo se pˇrivˇetšímmnožství pro- jekt ˚ua úkol ˚udozví o d ˚uležitýchzmˇenách.Naopak, budou-li uživatelé systému informování o každé i nepodstatné úpravˇe,dojde k tomu, že se zaˇcnespousta oznámení pˇrehlížeta i tato varianta nesplní sv ˚ujúˇcel. Do stejné kategorie patˇrítaké aplikace umožˇnujícíemailovou ko- munikaci nebo r ˚uznéformy textových komunikaˇcníchnástroj ˚u(Instant Messengers). Pˇred- stavme si, že pracujeme na nˇejakémprojektu s kolegy z celého svˇeta.Potˇrebujemerychle vytvoˇritna webu prostor, kde bychom mohli jednoduše sdílet informace s ostatními (ná- pady, dokumentaci apod.). K takovému úˇceluse asi nejlépe hodí tzv. wiki. Jde o software, který dovoluje lidem spolupracovat na tvorbˇeobsahu tak, že umožní návštˇevník˚umpˇrímo a co nejrychleji vytváˇreta upravovat stránky. Aby byly stránky pˇeknˇeˇclenˇenéa pˇrehledné, podporuje wiki jednoduchý jazyk, se kterým dokáže uživatel sv ˚ujobsah vhodnˇestruktu- rovat. Lze proto ˇríci,že tvorba stránek a dokumentace podle vzoru wiki také patˇrído této kategorie. Další nemalou roli zde hrají i systémy pro správu verzí soubor ˚ua zdrojových kód ˚u,ˇcastoznámé jako CVS ˇrešení,mezi které patˇrínapˇríkladsvˇetovˇerozšíˇrenýSubver- sion1. Evidování informací o ukládaných souborech a jejich zmˇenáchv historii umožˇnuje snadnˇejšíspolupráci v týmovém prostˇredí.V pˇrípadˇenutnosti je možné se kdykoliv vrátit k p ˚uvodnímúpravám. Snadno se tak zjistí, kdo je odpovˇednýza zanesené chyby. Další podstatnou kategorií, do které spadá vˇetšinaaplikací projektového ˇrízení,je sku- pina nástroj ˚uumožˇnujícíchpodrobnou správu jednotlivých úkol ˚ua zákaznických poža- 1. http://subversion.tigris.org/ 4 2.2. CO NABÍZEJÍ SOUCASNÁˇ REŠENÍ?ˇ davk ˚u(Issues tracking system). Systém pro evidování požadavk ˚usi lze snadno pˇredstavit na modelu zákaznické podpory. Typickým pˇríklademm ˚užebýt ˇrešeníproblém ˚u,které do našeho systému nahlásil zákazník. Všechny požadavky jsou uloženy ve firemní databázi a následnˇejsou jim pˇridˇeloványzdroje a ˇrešitelé podle potˇreba možností organizace. Každý požadavek prochází také svým životním cyklem. Na poˇcátkuje oznaˇcenza nový a v pr ˚u- bˇehusvého plnˇeníse dostává do stav ˚u,kdy bývá zpravidla ˇrešitelioznaˇcenza vyˇrešený,po- zastavený nebo napˇríkladstornovaný zákazníkem. Konkrétní stavy pak už záleží na zamˇe- ˇreníjednotlivých aplikací. Castoˇ je možné jednotlivé úkoly oznaˇcitprioritou. Kritické úkoly jsou pˇredkládányˇrešitel˚umk neodkladnému dokonˇcení,naopak požadavky s nulovou pri- oritou nejsou tolik podstatné a jejich odklad nezp ˚usobíorganizaci výrazné komplikace. Aby byla podpoˇrenasnadná komunikace se zákazníkem, je d ˚uležitémít dostupné všechny jeho potˇrebnéinformace, napˇríklademailové adresy, kontaktní ˇcifakturaˇcníúdaje. I tímto smˇe- rem vycházejí uživatel ˚umaplikace tohoto typu vstˇríca nabízejí možnosti podrobné správy tˇechtoúdaj ˚u. Nastínˇenyzde byly tˇrihlavní ˇcásti,ze kterých se skládají bˇežnˇedostupné aplikace pro projektové ˇrízenía správu úloh. Výˇcetvšech tˇechtonástroj ˚unení zdaleka koneˇcný.Dále je možné se setkat napˇríklads integrovanými dokumentovými sklady, seznamy zboží na skladˇeapod. Cílem této kapitoly však není podrobný výpis všech možných vlastností. Úˇce- lem bylo poskytnout základní pˇrehled.Nyní budou pˇredstavenyv obecné rovinˇezp ˚usoby jednotlivých ˇrešení[1]. 2.2.1 Poˇcítaˇcovéaplikace Jedním ze zp ˚usob˚u,jakým jsou implementovány aplikace pro projektové ˇrízení,je formou program ˚ubˇežícíchna stolních poˇcítaˇcíchkaždého uživatele. Jedná se vˇetšinouo velice kva- litní nástroje a to se znaˇcnˇeodráží na jejich cenˇe.Oproti webovým nástroj ˚um,které bu- dou ještˇetaké zmínˇeny, mohou poskytnout vˇetšímožnosti ovládání. Avšak jistota a stabilita firmy stojící za vybraným ˇrešenímje ˇcastorozhodujícím mezníkem pro výbˇertohoto soft- ware u vˇetšíchspoleˇcností.Veliká výhoda je také v tom, že lze dosáhnout vˇetšíinterakce s uživatelem. Nasbíraná data jsou uložena v poˇcítaˇcíchkaždého ˇclenatýmu, a nebo je lze sdílet formou centrálních databází. Poˇcítaˇcovéaplikace se vyznaˇcujínásledujícími vlastnostmi: • k dostání máme vˇetšímnožství nástroj ˚upro podporu projektového ˇrízení,než jsou k dispozici u aplikací urˇcenýchpro web • širší spektrum ovládacích prvk ˚u • vyšší zˇrizovacínáklady • vhodnˇejšípro vˇetšíspoleˇcnostia rozsáhlejší projekty • pro používání je nutné instalovat specializovaný software na každé cílové stanici 5 2.3. POROVNÁNÍ EXISTUJÍCÍCH NÁSTROJU˚ 2.2.2 Open-source nástroje Zvláštním pˇríkladempoˇcítaˇcovýchaplikací pro podporu projektového ˇrízeníjsou takzvaná open-source ˇrešení.Pro spoleˇcnosti,které se nechtˇejívzdát výhod stolních aplikací, ale ne- mají dostateˇcnéfinance pro nákup potˇrebného programového vybavení, je využití otevˇre- ného software možná tou správnou volbou. Protože jsou zdrojové kódy dostupné všem, velikým plus ˇcastobývá, že se na ˇrešení chyb m ˚užepodílet širší skupina lidí. Pravdˇepo- dobnost, že budou potíže úspˇešnˇeodstranˇeny, je tak vˇetší.Na druhou stranu dostupnost zdrojových kód ˚unahrává i útoˇcník˚um,kteˇrímají tak další možnosti najít pˇrípadné„bez- peˇcnostnídíry“ a využít je pro sv ˚ujprospˇech. 2.2.3 Webové nástroje Nástroje pro projektové ˇrízeníjsou ve velké míˇreimplementovány také formou webových aplikací. Pro pˇrístupnám postaˇcípouze bˇežnýpoˇcítaˇcs novˇejšíminternetovým prohlížeˇcem a dostupným pˇripojenímk internetu. Díky nízkým poˇrizovacímnáklad ˚umjsou tato ˇrešení výhodná pro malé a stˇrednífirmy a pro práci na menších projektech. Webová ˇrešeníse vyznaˇcujínásledujícími vlastnostmi: • pˇristupovatlze z jakéhokoliv poˇcítaˇcebez nutné instalace nˇejakéhospecializovaného softwaru • nejsme závislí na použitém operaˇcnímsystému • snadnˇejise data sdílí mezi jednotlivými uživateli • ˇcastoje podporován pˇrístuppˇresmobilní pˇrístroje • základní verze aplikací bývají ˇcastozdarma • bez dostupného pˇripojeník internetu nelze s nástroji pracovat • pro využívání nám postaˇcíjedna verze softwaru a jedna instalace • webové aplikace nabízejí oproti stolním ˇrešenímmenší možnosti interakce s uživate- lem 2.3 Porovnání existujících nástroj ˚u V souˇcasnostije na trhu obrovské množství aplikací umožˇnujícíchsprávu uživatelských požadavk ˚ua ˇrízeníúloh. V této kapitole budou zmínˇenynˇekteréz nich. Protože i aplikace, která je navrhována v rámci této práce, bude implementována pro použití na webu, budou dále rozebírány jen ukázky existujících internetových aplikací pro ˇrízeníprojektu. 6 2.3. POROVNÁNÍ EXISTUJÍCÍCH NÁSTROJU˚ 2.3.1 Basecamp Basecamp2 je nástroj, který vsadil na jednoduchost a uživatelskou pˇrívˇetivost.Za jeho vzni- kem stojí spoleˇcnost37signals. Jedná se o hostovanou aplikaci dostupnou v nˇekolikavari- antách. Základní verze je zdarma, ale umožˇnujesprávu pouze jednoho projektu. Pro více projekt ˚uje nutné zvolit placenou variantu. Využití našel napˇríkladpˇrivývoji známého a dnes rychle se rozšiˇrujícíhoframeworku Ruby on Rails3. Ruby on Rails bude detailnˇejipo- psán v dalších ˇcástechtéto práce, protože tento framework byl nakonec zvolen jako vhodná platforma pro implementaci navrhovaného systému. Po pˇrihlášenído systému se zobrazí takzvaný dashboard, tedy uživatelská plocha. Infor- mace, které je zde možné vidˇet,závisí na konkrétním projektu a na pˇrístupovýchprávech pˇridˇelenýchadministrátorem. Je zde pˇrehledprojekt ˚u,poslední zmeškané úkoly a kalendáˇr s plány na pˇríštích14 dní. Základem všech aplikací pro ˇrízeníúloh je projekt. Jinak tomu není ani u Basecamp. Pro projekt zde lze definovat celou ˇraduinformací, napˇr.informace o zúˇcastnˇenýchstranách, urˇcenítýmu lidí, externí spolupracovníky apod. Pro vˇetšípˇrehlednosta lepší zvládnutel- nost projektu je možné nastavit i jeho fáze. Uživatel pak m ˚užepˇridávata plnit jednotlivé úkoly. Následnˇelze sledovat jejich aktuální stavy a zjišt’ovat tak napˇríklad,kde jsou rezervy v plnˇeníprojekt ˚ua kde došlo k pˇrekroˇcenípožadovaných ˇcas˚u. Komunikace mezi jednotlivými uživateli je vyˇrešenapomocí systému rozesílání zpráv. Ty jsou bud’ generovány automaticky, napˇríkladpˇriukonˇcenínˇekteréhoz úkol ˚u,a nebo je lze vytváˇretsamostatnˇea posílat konkrétním uživatel ˚um.Aby byla komunikace opravdu plnohodnotná, je dovoleno ke zprávám pˇrikládati soubory. Pro doplnˇeníslužeb zde exis- tují i RSS kanály informující pravidelnˇeo nových vzkazech. Další formou komunikace jsou komentáˇre,které je možné pˇrikládatna mnoha místech v systému. Integrována je i kvalitní správa soubor ˚u.Soubory je tak možné nahrávat, stahovat a sdí- let se svým týmem nebo s klientem. Veškeré úpravy soubor ˚umáme pod kontrolou, protože se uchovávají i jednotlivé verze a my se tak m ˚užemevracet i k starším úpravám našich soubor ˚u.Pokud jsme na cestách a hledáme zp ˚usob,jak si zobrazit d ˚uležitádata prostˇred- nictvím internetu ve svém mobilním pˇrístroji, existuje i v tomto smˇeru ˇradadostupných klient ˚u,kteˇrívzdálený pˇrístupumožní. Basecamp celkovˇep ˚usobívelmi dobrým dojmem. Vše je pˇrehlednéa dobˇregraficky sla- dˇené.Celý systém je doplnˇentechnologií AJAX4, díky které se nemusí pˇrikaždé provedené akci naˇcítatobsah celé stránky. To uvítají pˇrevážnˇeti jedinci, kteˇrínedisponují rychlým pˇri- pojením k internetu. Nˇekomuby ale mohlo vadit, že veškerá citlivá data o projektech nebˇeží na vlastních strojích, ale vše je hostováno u autora tohoto produktu. V souˇcasnostitaké není vyˇrešenalokalizace do ˇceštinya to m ˚užebýt pro nˇekteréuživatele pomˇernˇezásadní pˇre- kážkou. 2. http://www.basecamphq.com/ 3. http://www.rubyonrails.com/ 4. Asynchronous JavaScript and XML 7 2.3. POROVNÁNÍ EXISTUJÍCÍCH NÁSTROJU˚ 2.3.2 Tick Další systém, který bude v rámci této práce zmínˇen,je Tick5 od spoleˇcnostiMolehill. Tick je rozhodnˇevelmi povedeným nástrojem, který se m ˚užechlubit i pˇríjemnýmgrafickým pro- stˇredím.Uživatelské rozhraní je velmi jednoduché a pˇrímoˇcaré,což je obrovskou výhodou. Který uživatel by chtˇeltrávit zbyteˇcnˇeˇcaszdlouhavým „proklikáváním“ systému a vypiso- váním potˇrebnýchúdaj ˚u?Jedná o hostovanou aplikaci, která je dostupná v nˇekolikavarian- tách. Podobnˇejako Basecamp, umožˇnujei Tick vytváˇretprojekty, pˇriˇrazovatje jednotlivým klient ˚uma urˇcovatjim ˇcasovéodhady trvání. Poté, co je vše nastaveno, m ˚užeuživatel za- kládat vlastní úkoly, které budou souˇcástídaného projektu. I zde je možné definovat ˇcasové limity, díky kterým lze sledovat aktuální stav prací. Aby byli uživatelé o každé zmˇenˇevˇcas informováni, jsou systémové události doprovázeny upozornˇenímprostˇrednictvímzaslání emailu. Navíc pro ty, kteˇríjiž dˇríve využívali napˇríkladprodukt Basecamp, pˇricházítato aplikace s možností napojení na Váš existující úˇcet.Tak Vám dovolí pˇristupovatk vytvoˇre- ným projekt ˚umnebo sdílet databázi klient ˚u. Autoˇrisystému Tick vsadili hodnˇena propracovanost uživatelského rozhraní. Pˇritom nástroj i pˇresjeho jednoduchost neztrácí na kvalitˇe.Všechny d ˚uležitéúdaje jsou vhodnˇe graficky zpracované a uživatel nemusí zbyteˇcnˇehledat, kam kliknout, co zvolit nebo kam má potˇrebnéúdaje vyplnit. 2.3.3 The Trac Project Dalším zajímavým poˇcinemje The Trac Project6 od spoleˇcnostiEdgewall Software. Jedná se o velice rozšíˇrenýsystém. Jako ve vˇetšinˇeaplikací pro správu uživatelských požadavk ˚u, tak i zde je základem všeho projekt. Pro pˇrehlednosta lepší zvládnutí problémové oblasti je možné projekty rozdˇelit na jednotlivé fáze. Samotné požadavky jsou pak zadávány pro- stˇrednictvímtzv. ticket ˚u. Velkou výhodou je existující rozhraní, které slouží k napojení na CVS systém pro správu verzí soubor ˚ujako je Subversion nebo Git. Kontrolovat lze veškeré úpravy v rámci projektu. Je možné tak prohlížet zdrojové kódy a porovnávat jednotlivé revize projektu pˇrímov apli- kaci. K samotným úpravám se lze pak snadno odkazovat v komentáˇrích. The Trac Project myslí i na tvorbu projektové dokumentace. Ta je zde podpoˇrenainte- grovaným modulem wiki, který pˇrebíráoblíbené vlastnosti formátování textu z internetové encyklopedie Wikipedie7. Kromˇeklasického psaní textu disponuje tento modul možností tvorby hypertextových odkaz ˚umezi jednotlivými ˇcástmisystému. Snadno se tak propojí uložené požadavky, systémová hlášení, úpravy zdrojového kódu, vybrané soubory a nebo jen samotné stránky dokumentace mezi sebou. Zdaˇrileje zde implementována možnost použití vlastních plugin ˚u.Uživatel tak m ˚uže 5. http://www.tickspot.com/ 6. http://trac.edgewall.org/ 7. http://www.wikipedia.org/ 8 2.3. POROVNÁNÍ EXISTUJÍCÍCH NÁSTROJU˚ aplikaci pˇrizp˚usobitvíce vlastním pˇredstavám.Je však nutné si dát práci s instalací a správ- ným nastavením tˇechtodoplˇnk˚u. Bohužel existují i zápory tohoto ˇrešení. Tím nejvˇetšímje nutnost nové instalace pro každý projekt. To m ˚užebýt ponˇekudnepˇríjemnéa zdržující, zvláštˇepokud se pracuje s více projekty. Další obrovskou nevýhodou je absence možnosti evidovat ˇcasstrávený na jednotli- vých projektech. Tím pádem není ani možné vytváˇretr ˚uznéreporty a výkazy za odvedenou práci. 2.3.4 Redmine Na závˇervšech ukázek aplikací bude zmínˇenoˇrešenívystupující pod názvem Redmine8. Po prvním pˇrihlášeníse zobrazí ne moc pˇeknˇevypadající rozhraní. Design je kostrbatý a není zdaleka tak uhlazený a doplnˇenýgrafikou, jako tomu je u Basecamp nebo Tick. Ale i pˇres to se jedná o velmi propracovanou aplikaci. Po nˇekolikaminutách používání uživatel zjistí, že grafika není zdaleka vše a možnosti, které m ˚užetato aplikace nabídnout, jsou opravdu veliké. Samotné ovládání je velice chytré, intuitivní, a tak vˇetšinupotˇrebnýchodkaz ˚unení nutné zbyteˇcnˇehledat po obrazovce. Pro urychlení ovládání se na mnoha místech využívá technologie AJAX. Základ tvoˇríwebový framework Ruby on Rails, ve kterém je celé pro- stˇredíimplementováno. Protože se stále hovoˇrío systémech pro ˇrízeníprojekt ˚ua správu úloh, tak i zde jsou k dispozici následující vlastnosti: • podpora více projekt ˚u,možnost dˇeleníi na podprojekty • možnost podrobné správy jednotlivých úkol ˚ua zákaznických požadavk ˚u • evidence ˇcas˚ustrávených plnˇenímúkol ˚u • novinky, dokumenty a správa soubor ˚u • RSS kanály a upozornˇenína zmˇenyprostˇrednictvímzaslání emailové zprávy • flexibilní uživatelské role pro nastavení pˇrístupudo systému • kalendáˇra Gantt ˚uvdiagram pro pˇrehlednˇejšízobrazení úkol ˚u,který je automaticky vykreslován podle ˇcas˚uzaˇcátk˚ua konc ˚ujednotlivých úkol ˚u Zajímavým zpestˇrením,které m ˚užepotˇešitspoustu uživatel ˚ua usnadnit tak mnohým práci, je zakládání požadavk ˚uprostˇrednictvím zaslaných email ˚u.Systém rozpozná, o jaký projekt se jedná, a založí v nˇempˇríslušnýpožadavek. To je velice užiteˇcnév organizacích nabíze- jících r ˚uznédruhy zákaznické podpory. Snadno tak lze pˇrikládatkomentáˇrei k existujícím úkol ˚umpouze tím, že odpovíme na email, který byl zaslán skrze aplikaci Redmine. 8. http://www.redmine.org/ 9 2.4. PROCˇ PSÁT VLASTNÍ SYSTÉM? Každý používaný projekt lze dále napojit na systém pro správu verzí souboru. Je tak možné prohlížet obsahy jednotlivých repositáˇr˚unebo zobrazit nové zmˇenykonkrétních sou- bor ˚u.Redmine pak podporuje celou ˇraduverzovacích systém ˚ujako jsou Subversion, CVS, Git, Mercurial, Bazaar nebo Darcs. Jak tomu bývá u spousty podobných aplikací, tak i zde je zadávání delších text ˚udopl- nˇenoo možnost kombinace s wiki syntaxí. Lze tak odkazovat na jednotlivé projekty, úkoly ˇcidokonce na úpravy soubor ˚uv repositáˇrích.Vše se provádí pomocí jednoduchých texto- vých znaˇcek.Možností, jakým zp ˚usobemlze používat wiki syntax, existuje nˇekolik. Rešeníˇ zvolené v Redmine není vyloženˇešpatné, ale stále má jisté nedostatky. Napˇríkladimple- mentace wiki, která vystupuje pod názvem DokuWiki9, používá o nˇecobohatší jazyk a pˇri psaní text ˚unebo dokumentace je možné vyjádˇritmnohem víc než v Redmine. Pro naprostou vˇetšinuorganizací p ˚usobícíchv jiných než anglicky mluvících zemích je pro volbu vhodného software rozhodující, jakým zp ˚usobemje uživatelské prostˇredípˇrelo- ženo do místního jazyka. Redmine v souˇcasnédobˇepodporuje více než tˇricetjazykových mutací. Na seznamu je možné najít i takové exotické zemˇejako je Thajsko, Vietnam nebo Korea. Veliký podíl na podpoˇretolika jazyk ˚umá fakt, že celé prostˇredíje implementováno s využitím platformy Ruby on Rails, které jazykové mutace podporuje velice snadno. Redmine je na trhu pomˇernˇenovým nástrojem. Aplikace toho umí opravdu hodnˇea práce s ní je jednoduchá. Najdou se ale i nˇekterénevýhody. Napˇríkladvelikým omezením je, že projekty mají omezenou hloubku dˇelení.Vytvoˇritlze pouze jednu úroveˇnpodprojekt ˚u. Toto omezení se m ˚uženegativnˇeprojevit u vˇetšíchfirem nebo projekt ˚u,kde tato vlastnost bývá pˇrekážkou.Dále není možné sdílet úkoly mezi jednotlivými projekty. To bychom uví- tali napˇríkladv situaci, kdy je vytváˇrenspoleˇcnýprodukt, který se hodlá používat pro více r ˚uznýchzákazník ˚u.Uživatelské rozhraní p ˚usobína mnoha místech strohým dojmem. I pˇres to, že vzhled aplikace neznamená vše, je zˇrejmé,že lepší grafické zpracování by zde roz- hodnˇenebylo na škodu. Další problém nastal pˇripokusu o napojení Redmine na údajnˇe podporovaný verzovací systém Git. Na závˇerje nutné poznamenat, že nˇekteréchyby byly v pr ˚ubˇehupsaní diplomové práce pr ˚ubˇežnˇeodstranˇeny. Jeho autoˇrina systému neustálé pracují, pˇridávajínové vlastnosti a odstraˇnujístávající nedostatky, které jsou zde ze starších verzí. 2.4 Proˇcpsát vlastní systém? Proˇcje nutné vyvíjet vlastní systém a nevyužít napˇríkladjedno ze zmínˇenýchexistujících ˇre- šení? Jedním z hlavních d ˚uvod˚uje pˇredevšímintegrace se systémem spoleˇcnostiIglooNET, s.r.o.10 Címˇ se tedy spoleˇcnostzabývá? IglooNET, s.r.o. je dynamicky se rozvíjející spoleˇcnostp ˚usobícív oblasti IT od roku 2004, od ledna 2007 transformovaná na spoleˇcnosts ruˇcenímomezeným. Rozsah ˇcinnostije velmi široký, ale hlavním cílem je poskytování komplexních služeb v IT prostˇredí.Mezi stˇežejní 9. http://www.dokuwiki.org/ 10. http://www.igloonet.cz/ 10 2.4. PROCˇ PSÁT VLASTNÍ SYSTÉM? aktivity patˇríposkytování prostoru pro internetové prezentace - webhosting, serverhosting, správa sítí, server ˚ui osobních poˇcítaˇc˚ua služby s tím spojené. Cílem této práce by mˇelbýt návrh a implementace systému, který bude pro zákazníka více pochopitelný a spojí klasické CRM ˇrešeníse systémem na hlášení chyb a ˇrízenízakázek. D ˚urazvýsledné aplikace by pak mˇelbýt kladen také na uživatelskou pˇrívˇetivosta snadnost použití. Protože spoleˇcnostvznikala postupnˇe,je souˇcasnýstav takový, že ke svému chodu vy- užívá nˇekolikzcela oddˇelenýchsystém ˚u.Stávající ˇrešeníjsou již znaˇcnˇezastaralá a práce s nimi jsou dosti neefektivní. Bohužel také všechna data, která by se mohla evidovat dohro- mady, se nyní uchovávají na nˇekolikamístech. Zbyteˇcnépˇrecházenímezi více oddˇelenými aplikacemi je pak pro bˇežnoupráci pomˇernˇekontraproduktivní. I možné budoucí úpravy, které by firma chtˇelana tˇechtosystémech provádˇet,jsou obtížné. Hlavní webovou aplikací, která je ve firmˇepoužívána, je administraˇcnísystém. Rešeníˇ je navržené v programovacím jazyce Perl. Uživatel ˚umnabízí následující funkce: • správa internetových domén, evidence hosting ˚ua nabízených služeb • správa emailových schránek, možnost nastavení pˇresmˇerování • tvorba záloh emailového serveru • doménový koš • správa úˇctupro pˇripojeník serveru prostˇrednictvímFTP11 • webové rozhraní umožˇnujícíprovádˇetaktualizace zmˇenv repositáˇríchSubversion Další používanou aplikací, která je nezbytná pro správný chod firmy, je fakturaˇcnísystém. Je v nˇemevidována celá ˇradaúdaj ˚u,at’ už o zákazníkovi nebo o nabízených produktech, evi- dence objednávek a vydaných faktur. V této aplikaci je umožnˇenotaké hlídání internetových domén, které jsou v expiraci a rozesílání upomínek pro ty zákazníky, kteˇrívˇcasneprovedli platby. Jak již bylo uvedeno, jedná se o systém, který je zcela separovaný od administraˇcního rozhraní. Implementace byla provedena prostˇrednictvímRuby on Rails. Poslední aplikací, kterou firma využívá, je systém pro správu projekt ˚ua úkol ˚u.D ˚uležitý je hlavnˇepro vedení evidence zákaznických požadavk ˚u.Používána je již zmínˇenáaplikace Redmine, která je také navržena v prostˇredíRuby on Rails. Je zˇrejmé,že hlavním zámˇerem spoleˇcnostiIglooNET, s.r.o. je tvoˇrenítakové aplikace, která umožní efektivnˇejšípráci, lepší evidenci údaj ˚ua spojí všechny tyto oddˇelenéaplikace do jedné. Novˇeimplementované administraˇcnía fakturaˇcnírozhraní by se mˇelodo takovéto aplikace pˇridávatformou samostatných modul ˚u.Hlavním cílem této diplomové práce je specifikace a namodelování nového modulu, který umožní firmˇeˇrízeníprojekt ˚ua správu úkol ˚u.Nahradit by pak mˇelpoužívanou aplikaci Redmine a docílit tak snadného sdílení dat s celým systémem. SpoleˇcnostIglooNET, s.r.o. také plánuje tuto aplikaci nabízet dál svým zákazník ˚um.Díky tomu, že celé prostˇredíbude navržené modulárnˇe,by nemˇelbýt problém pˇrizp˚usobitfunkcionalitu jejich potˇrebám. 11. File Transfer Protocol 11 Kapitola 3 Jazyk a nástroje pro návrh systému Tato kapitola se zamˇeˇrína detailnˇejšípopis jazyka, který byl vybrán pro implementaci bu- doucího systému. Pˇrivýbˇeru se vycházelo z uvedených požadavk ˚uspoleˇcnostiIglooNET, s.r.o., pro kterou je navrhovaný modul urˇcen.Nové aplikace, které firma vytváˇrí,jsou imple- mentovány v prostˇredíRuby on Rails. Protože práce v nˇemje snadná a velice pˇríjemná,bylo nakonec Ruby on Rails vybráno jako vhodná platforma i pro náš vytváˇrenýsystém. V této ˇcástibude tedy pˇriblíženo,co nám tento nástroj pˇrinášía ˇcímm ˚užeulehˇcitprogramátorovi práci. 3.1 Programovací jazyk Ruby Pˇredsamotným popisem Ruby on Rails je nutné zmínit alespoˇnpár slov k programovacímu jazyku Ruby, na kterém je tento webový framework postaven. Tv ˚urcem je Yukihiro Mat- sumoto, v internetovém svˇetˇeznámý pod pˇrezdívkouMatz. Zámˇerem bylo spojit prvky z jeho oblíbených programovacích jazyk ˚u(Perl, Smalltalk, Eiffel, Ada a Lisp). Podaˇrilose mu zformovat nový jazyk, který vyvažuje funkcionální programování s imperativním. Matz pˇrímotvrdí v [13], že se snažil utvoˇritRuby pˇrirozený, ne jednoduchý. „Ruby je jednoduchý navenek, ale velmi komplexní uvnitˇr,pˇresnˇejako naše lidské tˇelo.“ —Yukihiro Matsumoto 3.1.1 Oblíbenost tohoto nástroje Programovací jazyk Ruby spatˇrilpoprvé svˇetlosvˇetav roce 1995. Vˇetšípozornosti se mu dostalo až v posledních letech, a to ve spojení s frameworkem Ruby on Rails. Index TIOBE1, který mˇeˇrínár ˚ustprogramovacích jazyk ˚u,uvádí Ruby v bˇreznu2009 na jedenáctém místˇe mezi všemi programovacími jazyky na svˇetˇe.Množství popularity je pˇrisuzovánopoˇctu softwaru napsaného v Ruby [14]. Ruby je k dispozici zcela zdarma. Volnˇeho lze užívat, kopírovat, upravovat a distribuovat. 1. http://www.tiobe.com/ 12 3.1. PROGRAMOVACÍ JAZYK RUBY Obrázek 3.1: Index TIOBE ukazující nár ˚ustpopularity jazyka Ruby v posledních letech 3.1.2 Vše, na co si vzpomenete, je objektem Ruby je plnˇeobjektový programovací jazyk. To má za následek, že vše, co vývojáˇrv kódu použije, je objektem. M ˚užesi pak dovolit využít i takových konstrukcí, které ukazuje násle- dující pˇríklad. 2.times {print "Hello world "} >> Hello world Hello world Každý kousek kódu má svoje vlastnosti a akce. V objektovˇe-orientovanémprogramování jsou vlastnosti nazývány instanˇcnípromˇennéa akce jsou známy jako metody. Mnoho pro- gramovacích jazyk ˚unemá ˇcíslaa další primitivní typy implementovány jako objekty. Zde tomu tak není a opravdu každý typ zde má svoje instanˇcnípromˇennéa akce. Pro ukázku, napˇríkladv jazyce Java je možné získat absolutní hodnotu nˇejakéhoˇcíslatak, že se zavolá oddˇelenáfunkce a následnˇese jí pˇredápotˇrebnáhodnota. Bude použito nejspíš nˇecotako- vého: number = Math.abs(-5) // Java kód Jak již bylo zmínˇeno,ˇcíslavystupují v roli objekt ˚u.Proto jazyk Ruby poskytuje mož- nost zjistit absolutní hodnotu pomocí vlastní metody daného ˇcísla.Pro zjištˇenívýsledku se jednoduše použije následující volání: number = -5.abs # Ruby kód Také tˇrídyobjekt ˚uvystupují v tomto jazyce jako objekty. Je možné proto s nimi dˇelat všechny bˇežnévˇecijako s ostatními objekty v Ruby. Vytváˇretlze úplnˇenové tˇrídyobjekt ˚u, editovat stávající pˇridánímnebo odebráním metod. Lze dokonce naklonovat tˇrídu,upravo- vat pak její kopii a originál tak zachovat. 13 3.1. PROGRAMOVACÍ JAZYK RUBY 3.1.3 Flexibilita Programovací jazyk Ruby pˇricházís vˇetšíflexibilitou, protože dovoluje vývojáˇr˚umvolnˇe mˇenitvlastní ˇcástijazyka. Základní metody tak mohou být zcela odebrány nebo znovu de- finovány. Programátor má v tomto smˇeru naprosto volnou ruku. Vše si lze pˇredstavitna ná- sledujícím jednoduchém pˇríkladu.Sˇcítáníje bˇežnˇereprezentováno pomocí operátoru plus (+). Ve vytváˇrenémprogramu bychom radˇejipoužili ˇcitelnˇejšíslovo plus. Jednoduše je tak možné pˇridatnovou metodu do tˇrídy Numeric. Dosáhne se toho, že pak u libovolného ˇcísla v našem systému bude dovoleno využívat tuto novou metodu. class Numeric def plus(x) self.+(x) end end y = 5.plus 6 # y je nyní rovno císluˇ 11 Další vˇecí,kterou se Ruby odlišuje od ostatních nástroj ˚u,je zp ˚usob,jakým lze psát kód. Syntaxe pak ve výsledku pˇripomínáspíše psanou vˇetunež kód programovacího jazyka. Au- toˇritohoto nástroje si této vlastnosti velmi cení a i zkušenosti mnoha programátor ˚uˇríkají,že jakmile si vývojáˇrna tento styl psaní kódu zvykne, nebude chtít používat nic jiného. Docílí se tím poté i pˇeknéˇcitelnostia úspory syntaxe. Jednoduchý pˇríkladje vidˇetna následující ukázce. body += additional_text unless additional_text.nil? Pro nové vývojáˇre,kteˇrípˇrešlik Ruby z nˇekteréhoimperativního programovacího ja- zyka jako je Visual Basic nebo PHP, je velice oblíbenou vlastností používání takzvaných blok ˚u.Programátor je schopný pomocí blok ˚upˇripojitna konec libovolné metody vlastní ˇcástzdrojového kódu, ve kterém popíše požadované chování. Psaní blok ˚uje inspirováno pˇredevšímfunkcionálními jazyky. Na následující ukázce je pˇredvedenopoužití bloku mezi konstrukcí do a end. Metoda map pak aplikuje náš blok na uvedený seznam slov. search_engines = %w[Google Yahoo MSN].map do |engine| "http://www." + engine.downcase + ".com" end 3.1.4 Zpestˇrenízdrojového kódu Pˇriprogramování lze pomˇernˇerychle zjistit, že Ruby rozumí spoustˇekonstrukcí. Závorky je možné používat ke zpˇrehlednˇenípsaného kódu, avšak dá se obejít i bez nich. Stejnˇese tento jazyk staví i k používání stˇredníkupro ukonˇcenípˇríkazuna ˇrádku.Obˇenásledující volání jsou proto ekvivalentní: 14 3.2. ARCHITEKTURA MVC number = (2 + 1); number = 2 + 1 Nové promˇenné,které bude potˇrebapoužívat, není nutné pˇredemdeklarovat. Pro jejich oznaˇceníje zde nˇekolikzákladních konvencí, kterými je vhodné se ˇrídit. • var je oznaˇcenípro lokální promˇennou • @var oznaˇcujeinstanˇcnípromˇennou • $var se používá pro globální promˇenné Dodržení tˇechtopravidel pak zvyšuje ˇcitelnostkódu a dovoluje programátor ˚umjednoduše oznaˇcitrole každé promˇenné. 3.2 Architektura MVC Ruby on Rails jsou postaveny na návrhovém vzoru Model-View-Controller. Jedná se o zá- klad kvalitního objektového návrhu. V principu MVC rozdˇelujenáš systém do tˇrílogicky nezávislých ˇcástí.Na datový model aplikace, uživatelské rozhraní a ˇrídícílogiku [6]. • Model (Model) - Model zajišt’uje zpracování dat. Ve skuteˇcnostipak pˇredstavujeja- kési rozhraní mezi databází a ˇradiˇcem. • Pohled (View) - Pohled zodpovídá za výsledné zobrazení dat pˇredanýchmodelem. Podstatné a d ˚uležitéz hlediska struktury aplikace je to, že samo grafické rozhraní neobsahuje ani vlastní data (to je úkolem modelu), ani logiku práce s nimi (o to se starají ˇradiˇce).Jednou z nejbˇežnˇejšícha nejˇcastˇejiopakovaných chyb pˇriobjektovém návrhu jsou právˇepohledy obsahující data ˇciˇrídícírutiny. • Radiˇc(Controller)ˇ - Radiˇcpˇrebírávstupyˇ od uživatele vyvolané vstupními objekty v rámci pohledu (napˇríkladnabídkami, tlaˇcítkya podobnˇe).Zpracuje je podle po- tˇrebya pak ˇrídícelé zobrazení dat na výstup. Zajišt’uje tak logiku chování celého systému. Pˇritomsamozˇrejmˇepodle potˇrebyspolupracuje s modelem. Pˇredávámu požadavky na zmˇeny, a kdykoli je to zapotˇrebí,vyžádá si od nˇejúdaje pro zobrazení. Použitím MVC lze docílit co nejvˇetšíflexibility a veliké znovupoužitelnosti kódu. Samotná data jsou oddˇelenaod grafického rozhraní a od ˇcástipˇrijímajícíuživatelské vstupy. Snadno pak je možné mˇenitvzhled aplikace podle konkrétních potˇrebzákazník ˚u,aniž by bylo nutné zasahovat do zdrojových kód ˚umodelu nebo ˇradiˇce. 15 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS Obrázek 3.2: Princip návrhového vzoru MVC 3.3 Webový framework Ruby on Rails Oficiální verze Ruby on Rails spatˇrilasvˇetlosvˇetav ˇcervenci2004. Za jeho vznikem stojí dán- ský programátor David Heinemeier Hansson. Pˇrisamotném vývoji byl použit nástroj pro- jektového ˇrízeníBasecamp. Jak už bylo nˇekolikrátzmínˇeno,jedná se o takzvaný webový fra- mework. Cílem frameworku je pˇrevzetítypických problém ˚udané oblasti, ˇcímžse usnadní vývoj tak, aby se návrháˇria vývojáˇrimohli soustˇreditpouze na zadání své práce. Mezi zá- kladní princip Rails patˇrí:„Konvence má pˇrednostpˇredkonfigurací“, tedy, že programátor konfiguruje pouze ty ˇcástiaplikace, které se liší od bˇežnéhonastavení. Vytvoˇrí-litedy napˇr. model Person, aplikace bude data automaticky hledat v tabulce people. Chce-li, aby apli- kace naˇcítaladata z jiné tabulky, napˇríklad users, musí tak uˇcinitvýslovnˇe[15]. „Ruby on Rails jsou pr ˚ulomovév snižování bariér pro vstup do programování. Mocné aplikace, jejichž vývoj v minulosti trval týdny ˇcimˇesíce,mohou být vytvoˇrenybˇehemnˇekolikadní.“ —Tim O’Reilly, zakladatel O’Reilly Media 16 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS 3.3.1 Základní vlastnosti Pˇrivývoji se zajisté spousta programátor ˚usetkala se situacemi, kdy jsou používány opa- kujících se ˇcástíkódu. Formátování data, správný výpis mˇeny, zobrazení varovných nebo informativních hlášení pro formuláˇrovépoložky. Lze jich vyjmenovat opravdu hodnˇe.Ni- koho tedy nepˇrekvapí,že Ruby on Rails pˇricházís ˇradourozšíˇrení,jak ulehˇcitnejˇcastˇejší pˇrípadytˇechtoúkon ˚u.Obsahují tyto dvˇezákladní rozšíˇrení: rozšíˇreníjazyka Ruby (Core Extensions) a pomocné metody (helpers). Rozšíˇreníjazyka Ruby doplˇnujízákladní tˇrídy Array, Date, Hash, Numeric a String o pohodlné metody (convenience methods), které zjednodušují ˇcastose opakující operace. Všechna tato rozšíˇrenívelice posilují vyjadˇrovacíschopnost jazyka Ruby. Typickým pˇríkla- dem m ˚užebýt zjištˇení,zda je ˇcíslosudé ˇciliché, které lze využít tˇrebapro stˇrídáníbarvy pozadí ˇrádk˚utabulky: 7.even? => false Další pˇeknouukázkou je práce s datem, kdy vývojáˇrm ˚užechtít zjistit, jaký ˇcasbyl pˇred pˇetiminutami. Staˇcípak použít následující volání, které vrátí požadovaný údaj. 5.minute.ago Pomocné tˇrídyRails se od rozšíˇrenítˇrídRuby liší. Svoje využití mají pouze v pohledech. Slouží opˇetke zjednodušení formátování a generování kódu. Typicky tak lze na stránce snadno vytváˇretpotˇrebnéprvky jazyka HTML. Pˇripotˇrebˇevypsat odkaz lze použít metoda link_to, která vše potˇrebnéobstará za nás. link_to ’Odstranit záznam’, {:controller => ’groups’, :action => ’delete’, :id => group}, :confirm => ’Jste si jistý?’ Je-li kladen pˇrivývoji patˇriˇcnýd ˚urazna to, aby aplikace byla uživatelsky pˇrívˇetivá,pak jsou vhodnými pomocníky metody, které zavádí do Ruby on Rails urˇcitýnávrhový vzor ve- doucí k vˇetšímupolidštˇenívýpis ˚udat. Na uživatele p ˚usobívýsledný systém ménˇestresují- cím dojmem a lidé mají pocit, že aplikace pak „mluví“ více jejich jazykem a nekomunikuje s nimi jen prostˇrednictvímˇcíselnýchúdaj ˚u. time_ago_in_words(5.minute.ago) => "5 minutami" number_to_currency(999) => "999,00 Kc"ˇ Tˇechtozabudovaných metod, které Ruby on Rails nabízí, je opravdu veliké množství. Všechny jsou ale dobˇrezdokumentované2. Nicménˇei pˇresjejich množství se ˇcastostává, že je nutné nadefinovat další pomocnou metodu, která se postará napˇríklado vykreslení hlav- ního menu na webové stránce. I s tímto autoˇripoˇcítalia je tak možné do pˇredempˇripravené adresáˇrovéstruktury ukládat nové soubory s vlastními metodami. 2. http://api.rubyonrails.org/ 17 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS 3.3.2 Generátory Velice zajímavými nástroji jsou takzvané generátory kódu. Generátory zaujmou pˇrevážnˇe vývojáˇreseznamující se prvnˇes tímto frameworkem. Ty nám pomohou pˇrivytváˇreníno- vých model ˚u,pohled ˚ua jiných souˇcástíaplikace. Aby vývojáˇrinemuseli psát všechno ruˇcnˇe, vygenerují pomocí nich základní strukturu automaticky a pak pouze upravují pˇrípadnéde- taily. Generátor ˚uje v systému nˇekolik.Naprostí zaˇcáteˇcníciuvítají zejména scaffold gene- rátory, které umí sestavit k vybrané databázové tabulce formuláˇrepro zakládání, editaci a mazání dat. Postará se i o vytvoˇrenípotˇrebnétabulky pro výpis dat. Scaffold automaticky vyrobí prvky formuláˇrepodle typ ˚usloupc ˚uv databázové tabulce. Takže z typu VARCHAR se stane ve formuláˇriobyˇcejnétextové pole, z typu BOOLEAN se stane naopak zaškrtávací formuláˇrovépole. 3.3.3 Použití databáze Pro samotný pˇrístupk databázi je zde použit princip ORM (Object-relational mapping). Ve skuteˇcnostito pak znamená, že všechny záznamy relaˇcnídatabáze jsou mapovány na ob- jekty. Rádkyˇ se pˇrevedouna instance objekt ˚ua sloupce na jejich atributy. Vytvoˇrenínového záznamu lze demonstrovat na jednoduché ukázce, která uloží do databáze novou osobu. p = Person.new :first_name => ’Martin’, :sure_name => ’Pešout’ p.comment = ’autor diplomové práce’ p.save Díky principu ORM se pracuje v aplikaci pouze s objekty a není nutné psát konkrétní SQL dotazy pro uložení potˇrebnýchdat. Programátor není v ˚ubecomezen použitou data- bází a když se rozhodne v budoucnu použít místo MySQL napˇríkladdatabázi PostgreSQL, zamˇenípouze pˇríslušnýadaptér v konfiguraˇcníchsouborech a nemusí kv ˚ulitakovéto zmˇenˇe pˇrepisovatzdrojové kódy. V souˇcasnédobˇejsou podporovány následující databáze: • MySQL • PostgreSQL • SQLite • SQL Server • IBM DB2 • Informix • Oracle • Firebird/Interbase • LDAP 18 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS • SybaseASA (Sybase Adaptive Server Anywhere aka SQL Anywhere Studio) Pˇrivyužívání databází narazil zˇrejmˇekaždý vývojáˇrna problém, jak udržet pˇrehledve všech úpravách, které nad databázovým schématem provádí. Za tímto úˇcelembyly vytvo- ˇrenyv Ruby on Rails takzvané migrace. Ty nám umožˇnujípopsat potˇrebnézmˇenyv da- tabázovém schématu a dokonce se vracet v tˇechtoúpravách zpˇet.Protože se jedná pouze o textové soubory, je již velice snadné tyto záznamy pˇrenéstnapˇríkladdo Subversion, tj. systému pro správu verzí zdrojových kód ˚u.Každá migrace se skládá ze dvou metod: up a down. Vývojáˇrtak dostane možnost v nich definovat akce, které se provedou pˇripro- cházení historie jednotlivých úprav databázového schématu. Dále je pro existenci migrací významná databázová tabulka schema_info s jedním sloupcem typu INTEGER. Zde se evidují identifikátory již provedených úprav (migrací). Tˇrídymigrací jsou uloženy ve spe- ciálních souborech, které jsou pojmenovány podle vzoru xxx_nazev_migrace.rb, kde xxx je ˇcíslovyjadˇrujícípˇresnýˇcasvzniku. Následující pˇríkladukazuje postup pˇrivytvoˇrení tabulky item: class CreateItems < ActiveRecord::Migration def self.up create_table :items do |t| end end def self.down drop_table :items end end Aplikace v Ruby on Rails m ˚užebýt spuštˇenav jednom z nˇekolikabˇehovýchprostˇredí, které pak ovlivˇnujíchování jednotlivých ˇcástíframeworku. Standardnˇejsou dostupná tˇri prostˇredí: • Vývojové - toto prostˇredíslouží pro vývoj aplikace • Testovací - slouží pro spuštˇeníautomatických jednotkových a integraˇcníchtest ˚u • Produkˇcní - v tomto prostˇredíje spouštˇenaaplikace do ostrého provozu Pˇripojeník databázi se nastavuje oddˇelenˇepro každé prostˇredízvlášt’. Pro vývojáˇreto zna- mená, že tak lze využít oddˇelenédatabáze. Je možné tak snadno mít testovací data zvlášt’ od dat sloužících k ostrému provozu na webu. Aplikace se pak v pˇrípadˇepotˇrebyspustí pouze v požadovaném režimu. I pˇrisamotném návrhu databázového schématu lze využít ˇraduužiteˇcnýchkonvencí. Pro názvy tabulek se bˇežnˇepoužívají anglické názvy objekt ˚u,které se reprezentují v množ- ném ˇcíslea malými písmeny. Pokud jsou názvy víceslovné, oddˇelujíse podtržítkem. Pˇríklad lze vidˇetna následující tabulce. Rails oˇcekávánázev sloupce primárního klíˇce id. Cizí klíˇcejsou ve tvaru {jednotné císloˇ cizí tabulky}_id. Samozˇrejmˇese jedná jen o ˇradudoporuˇcení,jak navrhovat 19 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS Název modelu Název tabulky Monkey monkeys Octopus octopi Customer customers Monkey Hunter monkey_hunters Tabulka 3.1: databázové schéma. Napˇríkladnázev sloupce primárního nebo cizího klíˇcem ˚užebýt i po- jmenován jinak. Rails pouze ˇríká,že pokud se využije tˇechtopravidel, usnadní se tím bu- doucí práce. Název tabulky Cizí klíˇc monkeys monkey_id octopi octopus_id Tabulka 3.2: Programátorská pˇrívˇetivostjde ještˇedál. Pˇripoužití speciálních názv ˚usloupc ˚utabulek je možné docílit také toho, že se budou automaticky vyplˇnovatnˇekteréˇcasovéúdaje. Sloupec s názvem created_on bude automaticky vyplnˇenaktuálním ˇcasempˇrivytvoˇrenínového záznamu v tabulce. Ve sloupci updated_on se zas automaticky vyplní ˇcasposlední editace pˇríslušnéhozáznamu. Naplnˇeníhodnotami tak za vývojáˇreobstará sama aplikace. 3.3.4 Tvorba interaktivních aplikací V prvních nˇekolikaletech internetu byly webové aplikace v porovnání se stolními aplika- cemi znaˇcnˇepomalé a neohrabané. Lidé mˇelirádi webové aplikace pˇrevážnˇeproto, že byly dostupné kdekoliv, kde bylo dostupné pˇripojeník internetu. Poté firma Microsoft vytvo- ˇrilatzv. XMLHttpRequest pro sv ˚ujinternetový prohlížeˇcInternet Explorer 5. Umožnila tím skript ˚umna zobrazené stránce komunikovat s webovým serverem v pozadí bez nutnosti naˇcítánínové webové stránky. Vývojáˇrtak m ˚uževytvoˇritvíce interaktivní aplikace. Brzo po zveˇrejnˇenítohoto ˇrešeníimplementovala i Mozilla a Opera XMLHttpRequest do svých pro- hlížeˇc˚u.Zprvu nebyla tato forma komunikace v ˚ubecrozšíˇrená.Do povˇedomívˇetšíhomnož- ství lidí ji dostala až spoleˇcnostGoogle, které se podaˇrilovyvinout sérii aplikací komunikují- cích právˇeprostˇrednictvímXMLHttpRequest. Nejznámˇejšíje asi Google Maps3, poskytující návštˇevník˚umpˇredstavu,že jsou schopni pˇretahovatnekoneˇcnˇerozsáhlou mapu v oknˇe svého prohlížeˇce.Využívání XHLHttpRequestu je nyní známo pod jednoduchým názvem AJAX (Asynchronous JavaScript and XML). Ruby on Rails má jednoduchý, konzistentní model, jak implementovat AJAX. Pokud se v prohlížeˇcizobrazí úvodní webová stránka, lze pomocí jiné uživatelské akce pˇrejítna no- 3. http://maps.google.com/ 20 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS vou internetovou stránku (klasické webové aplikace) a nebo spustit nˇekterou AJAX operaci: 1. Došlo ke spouštˇecíakci. Ta m ˚uženastat napˇríkladkliknutím na urˇcitýodkaz nebo tlaˇcítko,uživatel mohl zmˇenitdata ve formuláˇria nebo došlo ke spuštˇeníautomatické periodické akce. 2. Data asociovaná se spouštˇecíudálostí jsou zaslána asynchronnˇena server prostˇred- nictvím XMLHttpRequest, kde se o nˇepostará pˇríslušnáakce. 3. Obsluha dané akce na stranˇeserveru provede programátorem urˇcenéoperace v závis- losti na poskytnutých datech a jako výsledek vrátí pˇríslušnýfragment HTML kódu. 4. Skripty na stranˇeklienta obdrží fragment HTML kódu a použijí ho k aktualizaci spe- cifické ˇcástizobrazené HTML stránky. Aby bylo používání této technologie co nejsnazší, nabízí Ruby on Rails vývojáˇr˚umnˇekolik pomocných metod, které za nˇevygenerují ve zdrojovém kódu vše potˇrebné.Programátor zavolá pouze vhodnˇevybranou metodu. Pro ukázku zde bude zmínˇenaAJAX alternativa ke klasické pomocné metodˇepro zobrazení odkazu. link_to_remote(’Odstranit záznam’, :url => {:controller => ’groups’, :action => ’delete’, :id => group}, :confirm => ’Jste si jistý?’) 3.3.5 Podpora více jazyk ˚u Zejména u vˇetšíchprojekt ˚uje ˇcastonutné ˇrešitsituace, jak efektivnˇenaprogramovat apli- kaci s podporou více jazyk ˚u.Ruby on Rails od verze 2.2 poskytuje snadný zp ˚usob,jak toho docílit [2]. V rámci vícejazyˇcnépodpory se hovoˇrío dvou významných procesech. Proces in- ternacionalizace znamená, že se oddˇelujívšechny pˇrekládanétextové ˇretˇezcea další kousky kódu (jako mˇenua datum) mimo naši aplikaci. Proces lokalizace pak znamená samotné za- jištˇenípˇreklad˚ua místních formát ˚u(každý stát má jinou mˇenunebo jiný zp ˚usobzápisu pro datum) pro takovéto kousky textu. Oddˇelenépˇrekladyjsou poté umístˇenydo speciál- ních textových soubor ˚u.Každý text je v nˇemoznaˇcenunikátním klíˇcem,díky kterému lze poznat v pohledech, jaký popisek se má použít. Jednoduchý soubor s naším pˇreloženým textem pro anglický jazyk m ˚uževypadat tˇrebanásledovnˇe: en: hello: "Hello world" V jiném souboru bude uložen stejný pˇreklad,ale pro ˇceskýjazyk. cs: hello: "Ahoj svete"ˇ Pro vypsání našeho textu v pohledu, staˇcínapsat následující: 21 3.3. WEBOVÝ FRAMEWORK RUBY ON RAILS <%= t :hello -%> Aplikace pak pomocí jednoduchých pˇríkaz˚urozhodne, jaký jazyk se má aktuálnˇepou- žít. A podle toho se vypíše pˇríslušnýanglický nebo ˇceskýpopisek. Toto je samozˇrejmˇejen základní ukázka použití pˇreklad˚uv Ruby on Rails. Je možné využívat i složitˇejšíchmetod. Pˇrekládatlze jednotlivé modely, názvy atribut ˚u,rozlišovat jednotné a množné tvary slov apod. 3.3.6 Vylepšení aplikace pomocí plugin ˚u Další silnou stránkou Ruby on Rails je zp ˚usob,jakým lze snadno rozšiˇrovatposkytované funkce pomocí plugin ˚u. Jedná se o externí knihovny. Jejich použití šetˇríspoustu ˇcasu,pro- tože funkˇcnost,kterou potˇrebujete,napsal už nˇekdopˇredvámi a možná dokonce i lépe, než byste to udˇelalivy. U hojnˇepoužívaných plugin ˚uje navíc jistˇejší,že bude odstranˇenavˇetšina chyb. Existuje jich hned celá ˇrada,od tˇechˇrešícíchobecné problémy témˇeˇrkaždé aplikace po pluginy, které jsou urˇcenépro specifické pˇrípady. Snadno tak lze naše programy rozšíˇrit o možnost práce s obrázky nebo umožnit jednotlivým uživatel ˚umpˇrihlášenído systému a pˇriˇrazenípotˇrebnýchpráv. 3.3.7 Testování Poslední vlastnost, která bude v této kapitole zmínˇena,je testování. Vytváˇríme-liwebovou aplikaci, máme vždy urˇcitoupˇredstavu,jak by se mˇelachovat. Casˇ od ˇcasupotˇrebujeme nˇejakouˇcástupravit nebo pˇridatnové funkce. Jak se systém postupnˇerozr ˚ustá,je ˇcímdál víc obtížnˇejšísledovat, jestli se všechny ˇcástichovají poˇrádstejnˇe.Proces vývoje se proto ne- obejde bez testování. Na provedené úpravy napíše programátor vlastní sadu test ˚u,a pokud všechny kontroly projdou, dostává tak vˇetšízáruku, že do systému nˇekdonezanesl chyby. Samozˇrejmˇevše záleží na tom, s jakou d ˚uslednostíse testy píší. Testování v Ruby on Rails se dˇelído dvou ˇcástí: • Testy model ˚u(Unit tests) • Testy ˇradiˇc˚u(Functional tests) Proces testování pak probíhá pomocí tvrzení. Jedná se o speciální metody, které zkontrolují vybraný kód. Po spuštˇeníjsou vyhodnoceny bud’ jako pravda nebo nepravda, podle toho jestli se podaˇrilopotˇrebnýkód provˇeˇrit. 22 Kapitola 4 Modelování databázového schématu Pˇribudování systému se urˇcitˇekaždý vývojáˇrdostal do situace, kdy bylo nutné popsat strukturu databázového schématu. Nedostatky v takovémto návrhu však mohou odsou- dit budoucí aplikaci k záhubˇe.Pˇrinesprávném návrhu budou data, která bychom chtˇeli ukládat, bud’ obtížnˇezískatelná a nebo budou znemožnˇenysamotné budoucí úpravy. Pˇri budování modelu struktury systému se dnes nejˇcastˇejipoužívají sémantické nebo objektovˇe orientované datové modely. Nejznámˇejšímsémantickým modelem je entitnˇe-ralaˇcnímodel. V této kapitole bude nejprve pˇriblíženo,co vlastnˇepˇrinášízáklad entitnˇe-relaˇcníhomodelu a ˇcímse vyznaˇcuje.I pˇresto,že je toto ˇrešenínejvíce používané, byl pro návrh budoucího systému zvolen trochu jiný pˇrístup,a to datové modelování podle metody HIT. Dále bude ukázáno, že z praktického hlediska se jedná v podstatˇetaké o variantu entitnˇe-relaˇcního pˇrístupuk modelování datové základny. Zbytek kapitoly bude proto vˇenován popisu toho, co HIT znamená a jak se ho podaˇrilovyužít. 4.1 Entitnˇe-relaˇcnímodel Entitnˇe-relaˇcnímodel je cesta, jak graficky reprezentovat logické vazby mezi entitami za úˇcelemvytvoˇrenídatabáze. Byl navržen v roce 1970 Peterem Chenem, který p ˚usobilna Massachusetts Institute of Technology. Je založen na tˇrechzákladních modelovacích kon- struktech, a to entita, vztah a atribut [5]. Entita se dá definovat jako vˇecschopná samostatné existence a je jednoznaˇcnˇeidenti- fikovatelná. Entita je abstrakcí komplexity urˇcitéoblasti. Hovoˇríme-lio entitˇeobvyklým zp ˚usobem,hovoˇrímeo urˇcitémaspektu reálného svˇeta,který se dá od ostatních aspekt ˚u odlišit [2]. Logický význam entit je ekvivalentní s gramatickými podstatnými jmény, jako jsou zamˇestnanci,oddˇelení,produkty nebo uživatelé. Vztah zachycuje, jakým zp ˚usobemjsou dvˇenebo více entit vztažené mezi sebou. Sv ˚uj ekvivalent mají v slovesech nebo slovních spojeních, jako je napˇríkladproces nakupování, proces opravování, být ˇclennˇejakéskupiny a nebo být vedoucí urˇcitéhooddˇelení.Vztahy mohou být definovány podle poˇctuentit, se kterými jsou asociovány. Takovéto ˇcísloje pak nazváno stupeˇnnebo odbornˇeji pomˇerkardinality vazby. Kardinalita m ˚uženabývat hodnot 1:1, 1:N ˇciM:N. Jak entity, tak vztahy mohou mít své atributy. Atribut je funkce, která vyjadˇrujed ˚ule- žitou vlastnost nebo charakteristiku dané entity nebo vztahu [3]. Napˇríkladentita uživa- tel m ˚užeobsahovat atributy kˇrestníjméno, pˇríjmenínebo datum narození. Vztah uživatele 23 4.2. DATOVÉ MODELOVÁNÍ METODOU HIT patˇrícíhodo vybrané skupiny m ˚užemít atribut datum, který zas urˇcujeplatnost takovéto vazby. Každá entita musí obsahovat takové množství atribut ˚u,aby byla vždy v systému jed- noznaˇcnˇeidentifikovatelná. Takovéto atributy, které pˇresnˇevymezují naší entitu, jsou pak nazývány primárním klíˇcem. Tato základní varianta návrhu bývá ˇcastorozšíˇrenao další prvky zvyšující vyjadˇrovací sílu modelu. Velmi ˇcastoje tak možné se setkat napˇríklads ISA hierarchií, nˇekdypopisova- nou spíše jako vztah podtyp-nadtyp. V entitnˇe-relaˇcnímmodelování je struktura databáze zobrazena jako diagram, který je souhrnnˇenazýván entitnˇe-relaˇcnídiagram (ERD), podobající se grafickému zobrazení roz- boru gramatických ˇcástívˇety. Entity jsou vykresleny jako body, mnohoúhelníky, kruhy nebo oválné obrazce. Vazby jsou zobrazovány jako ˇcáryspojující právˇebody, mnohoúhelníky, kruhy nebo oválné obrazce. Každý entitnˇe-relaˇcnídiagram má ekvivalentní relaˇcnítabulku v databázi. Lze to ˇrícii naopak. Každá relaˇcnítabulka má sv ˚ujekvivalentní záznam v ta- kovémto diagramu. Jaké grafické znaˇckyjsou pˇresnˇepoužity, pak záleží na zvolené notaci. Známá Chenova notace ER modelování znázorˇnujeentity pomocí obdélník ˚ua vztahy po- mocí kosoˇctverc ˚u. 4.2 Datové modelování metodou HIT Zkratka HIT znamená Homogenní, Integrovaný, Typovˇeorientovaný. Jedná se o objektovˇe- funkˇcnímodel, jehož specifikaˇcníma manipulaˇcnímnástrojem je jazyk konstrukcí. Teore- tický základ pro datový model HIT je postaven na takzvané transparentní intenzionální logice (TIL) a na netradiˇcní teorii pojmu. TIL byla navržena Pavlem Tichým1 a pˇredstavuje výhodný nástroj pro analýzu význam ˚uvýraz ˚upˇrirozeného jazyka. Pro tuto práci však není podstatné detailnˇejšírozebírání logických základ ˚upro modelování podle metody HIT, tˇem je vˇenovánpodrobnˇejšívýklad napˇríkladv práci Marie Duží [3]. Je však nutné si alespoˇn ˇcásteˇcnˇepˇriblížit,co tato metoda nabízí. 4.2.1 Konceptuální model Modelování sytému je založeno na tom, že modeláˇranalyzuje výrazy pˇrirozeného jazyka, kterými business experti popisují svou oblast. Touto analýzou objevuje pojmy (konstrukce), které identifikují objekty zájmu. Pro usnadnˇeníkomunikace mezi uživatelem a analytikem existuje v metodˇeHIT grafická reprezentace, kde jsou jednotlivé atributy zaznamenávány v podobˇegrafických schémat. Konceptuální model vytvoˇrenýmetodou HIT je složený ze tˇrízákladních ˇcástí: • báze sort • množina HIT-atribut ˚unad bází sort • množina konstrukcí tvrzení konzistence 1. http://til.phil.muni.cz/text/biography_tichy.php 24 4.2. DATOVÉ MODELOVÁNÍ METODOU HIT Sorty hrají v datovém modelování roli elementárních typ ˚u.Bˇežnˇeje možné se setkat se dvˇemadruhy – entitní sorty a deskriptivní sorty. Entitní sorty odpovídají Chenovým en- titám popsaným v entitnˇe-relaˇcnímmodelu, který byl zmínˇenýv pˇredchozíkapitole 4.1. Je možné ˇríci,že každou entitní sortu si lze tedy pˇredstavitjako množinu všech objekt ˚u, které mˇely, mají a budou mít urˇcitouspoleˇcnouvlastnost. Navíc každá entitní sorta musí mít urˇcenysvé identifikaˇcníatributy [3]. Deskriptivní sorty odpovídají v podstatˇeprogramátorským datovým typ ˚uma slouží jako obory hodnot r ˚uznýchcharakteristik, pˇriˇrazenýchk jednotlivým výskyt ˚umentitních sort. Lze ˇríci,že pomocí prvk ˚udeskriptivních sort popisujeme prvky sort entitních. Pˇrivytváˇreníkonceptuálního schématu je nutné do samotného procesu modelování za- pojit i experta problémové oblasti. Tato jednoduchá zásada je ˇcastoopomíjena i pˇresto, že právˇebez dialogu analytika s pˇríslušnýmexpertem se nemusí podaˇritzachytit potˇrebné vlastnosti budovaného informaˇcníhosystému. Celý proces hledání jednotlivých entitních a deskriptivních sort je oznaˇcensouhrnnˇejako sortalizace. Jedná se o mapování reality. Pˇri hledání je zaostˇrovánapozornost na objekty zájmu, na to, co je pro danou business oblast podstatné. Nejd ˚uležitˇejšíje zapsat definice entitních a deskriptivních sort. Jakmile se podaˇrí nalézt novou sortu, je nutné doplnit její definici. Analytik se snaží v dialogu s expertem zachytit i jednotlivé pojmy (konstrukce) vyjádˇrenév pˇrirozeném jazyce, již tento expert po- užívá. Jestliže je pˇridávánanová entitní sorta, oznaˇcena #S, jejíž prvky jsou rozpoznány podle toho, že sdílejí právˇeurˇcitoukombinaci vlastností P1,P2,...,Pn, má její definice tvar: „Ob- jektem typu (#S) je každý takový element, který má vlastnost P1 a/nebo P2 a/nebo . . . a/nebo Pn“. Pˇritom vlastnost Pi m ˚užebýt i v negovaném tvaru [9]. Príkladˇ 4.2.1: Objektem typu (#Projekt) je každý existující nebo plánovaný projekt, tj. souhrn ˇcinností,které mají daný zaˇcáteka konec, smˇeˇrujíke splnˇenínˇejakéhoúkolu resp. cíle a které má smysl „projektovˇeˇrídit“. Pokud je pˇridávánanová deskriptivní sorta D, lze její definici zapsat ve tvaru, na základˇe kterého je možné rozpoznat, které ˇretˇezceznak ˚umohou být hodnotami této deskriptivní sorty: „Každý prvek deskriptivní sorty (D) je reprezentován ˇretˇezcem,který splˇnujepod- mínku C1 a/nebo C2 . . . a/nebo Ck“ [9]. Príkladˇ 4.2.2: Každý prvek deskriptivní sorty (Cas) je reprezentován ˇretˇezcemznak ˚u splˇnujícímpodmínky: ˇretˇezecmá právˇe6 znak ˚u,ˇretˇezecmá formu HHMMSS. Na zaˇcátkutéto kapitoly bylo uvedeno, že konceptuální model se skládá z nˇekolikaˇcástí. Jednou z nich je i množina HIT-atribut ˚u.Atribut v datovém modelu HIT je funkce, která vy- jadˇrujevztah mezi sortami. Ja tak možné vyjádˇritjak Chen ˚uvatribut, tak Chen ˚uvvztah mezi dvˇemaˇcivíce entitami z entitnˇe-relaˇcníhomodelu. Alespoˇnjedna sorta v tomto vztahu musí 25 4.2. DATOVÉ MODELOVÁNÍ METODOU HIT být entitní sortou. Atribut, který vyjadˇrovalvztah mezi deskriptivními sortami, by z prak- tického hlediska nemˇelvýznam [9]. Pˇribudování našeho seznamu HIT-atribut ˚use musí neustále provˇeˇrovat,zda novˇepˇridanéatributy jsou v nejjednodušším možném tvaru a zda se nezapisují nadbyteˇcnéatributy, které by bylo možné odvodit z již nalezených atribut ˚u. Obdobnˇejako entitní a deskriptivní sorty, také HIT-atributy jsou zapsány pomocí pevnˇe dané sémantiky ve formˇeurˇcitéhostandardizovaného výrazu pˇrirozeného jazyka. Formální definice, která byla uvedena v disertaˇcnípráci [9], ˇríkánásledující. Necht’ Wrd oznaˇcuje množinu všech svˇet˚ua Tim oznaˇcujemnožinu všech ˇcasovýchokamžik ˚u.Jestliže je pˇri- dáván HIT-atribut A typu (W rd → (T im → ((S1 × S2 × ... × Sn) → S))), který n-ticím (s1, . . . , sn) pˇriˇrazuje(v závislosti na stavu svˇeta)prvky z S, potom zápis sémantiky má formu A = text0(S)text1(S1)text2(S2) . . . textn(Sn)textn+1, kde pouze text0 a textn+1 m ˚uže být vynechán, a celý výraz, pˇreˇctenýjako výraz pˇrirozeného jazyka, nám sdˇelujefunkci, která vrací hodnotu z S na argumentech s1 ∈ S1, . . . , sn ∈ Sn. Príkladˇ 4.2.3: HIT-atribut A typu (W rd → (T im → (#Zamestnanec → P lat))), v zá- vislosti na stavu svˇeta,pˇriˇrazujezamˇestnanc˚umjednotlivé platy, a to právˇety, které jednoznaˇcnˇeurˇcujenásledující sémantika HIT-atributu A: A = (Plat) daného (#Zamestnanec). Dále staˇcívyjít z pˇredchozídefinice a modifikovat zápis. Necht’ BOOL je množina prav- divostních hodnot, množina m ˚užeobsahovat hodnoty {Pravda, Nepravda}. HIT-atribut A’ typu (W rd → (T im → ((S1 × S2 × ... × Sn) → (S → Bool)))), který n-ticím (s1, . . . , sn) pˇriˇrazujeprvky z (S → Bool), tj. podmnožiny S, potom náš zápis sémantiky má formu 0 A = text0(S)-s text1(S1)text2(S2) . . . textn(Sn)textn+1, kde pouze text0 a textn+1 m ˚užebýt vynechán, a celý výraz, pˇreˇctenýjako výraz pˇrirozeného jazyka, nám sdˇelujefuknci, která vrací nˇejakoupodmnožinu hodnot z S na argumentech s1 ∈ S1, . . . , sn ∈ Sn. Pˇrípona –s (anglický plurál) vyjadˇrujepˇriˇrazovánípodmnožiny hodnot z S [9]. Príkladˇ 4.2.4: HIT-atribut A’ typu (W rd → (T im → (#Material → (#Dodavatel → Bool)))), v závislosti na stavu svˇetapˇriˇrazujemateriál ˚umjejich dodavatelé, a to právˇe ty, které jednoznaˇcnˇeurˇcujenásledující sémantika HIT-atributu A’: A’ = (#Dodavatel)-s, kteˇrídodávají daný (#Materiál). Príkladˇ 4.2.5: HIT-atribut A” typu (W rd → (T im → ((#Student × #Semestr) → (#Kurz → Bool)))), v závislosti na stavu svˇetapˇriˇrazujedvojicím (student, semestr) jejich kurzy, a to právˇety, které jednoznaˇcnˇeurˇcujenásledující sémantika HIT-atributu A”: A” = (#Kurz)-s, které si zapsal (#Student) v daném (#Semestr). 26 4.3. VYUŽITÍ METODY HIT PRIˇ NÁVRHU NAŠEHO SYSTÉMU Aby byl náš model kompletní, je nutné postupnˇedoplnit i tvrzení konzistence. Ty nám v ter- mínech HIT-atribut ˚uvyjadˇrujínaši znalost o bližších souvislostech v modelované oblasti, které nelze zapsat pouze pomocí HIT-atribut ˚u.Lze tak vyjádˇrit,že ne všechny funkˇcníhod- noty datových funkcí jsou pˇrípustné.Každý HIT-atribut je opatˇrentzv. pomˇerem atributu. Jedná se o speciální pˇrípadtvrzení konzistence, které je zapisáno jako výraz p,m:q,n, kde platí: • p = 0 znamená, že atribut je „parciální funkcí“ • p = 1 znamená, že atribut je „totální funkcí“ • m = 1 znamená, že atribut je singulární • m = M znamená, že atribut je vícenásobný (M znamená „mnoho“) Obdobný význam mají ˇcísla q a n pro obrácený HIT-atribut [8]. Použitím pomˇeru HIT- atributu je umožnˇenpˇresnýzápis datového modelu a není tak dovolen dvojí výklad. Tento výraz je pak pˇripojenza definici pˇríslušnéhoHIT-atributu. 4.2.2 HIT jako rozšíˇreníentitnˇe-relaˇcníhomodelu Na HIT model je možné pohlížet i jako na urˇcitouvariantu entitnˇe-relaˇcníhopˇrístupu.Proˇc tomu tak je? Entitnˇe-relaˇcnídiagram (ERD) lze totiž z HIT-schématu získat pomocí jedno- duchého algoritmu. Podstatu tohoto algoritmu však není nutné rozebírat. Jeho detailnˇejší popis je uveden napˇríkladv práci Marie Duží [3]. Proˇcale transformujeme HIT-schéma? D ˚uvodje v podstatˇejednoduchý. Získáme tak schéma bližší poˇcítaˇcovémuvidˇenía tedy snáze implementovatelné. Výsledkem provedeného algoritmu je pak entitnˇe-relaˇcnímodel, který má všechny entity splˇnujícíˇctvrtoua pátou normální formu a BCNF (Boyce-Coddova normální forma) [8]. 4.3 Využití metody HIT pˇrinávrhu našeho systému Pˇribudování struktury budoucího systému bylo využito metody HIT. Celá aplikace je im- plementována v prostˇredíwebového frameworku Ruby on Rails, který však nedokáže spo- lupracovat s takovýmto popisem databázového schématu. V pˇredchozíkapitole 3.3.3 bylo uvedeno, že struktura databázového schématu se v Ruby on Rails popisuje pomocí takzva- ných migrací. Ty dokáží zachytit i jednotlivé zmˇenya umožní nám tak vracet se v historii zpˇetk pˇredešlýmúpravám. Abychom však dokázali vytvoˇritz HIT modelu jednotlivé sou- bory migrací, vyvinula spoleˇcnostIglooNET, s.r.o. pro naše potˇrebyknihovnu, která celý tento proces automatizuje. Programátor se pak jen stará o to, jak správnˇepopsat potˇrebné vlastnosti budovaného informaˇcníhosystému pomocí HIT-schématu. Budovaný seznam HIT-atribut ˚uje zaznamenáván v Ruby on Rails do speciálních tex- tových soubor ˚upomocí jednoduchých výraz ˚u.Protože se však poˇcítás nasazením této 27 4.3. VYUŽITÍ METODY HIT PRIˇ NÁVRHU NAŠEHO SYSTÉMU knihovny pouze v tomto programovacím jazyce, došlo k urˇcitýmzjednodušením. D ˚uvo- dem bylo hlavnˇeto, že Ruby on Rails je nástroj založený na konvencích. A tak dodrží-li se daná pravidla pro psaní kódu, bude vývoj aplikace znaˇcnˇejednodušší a rychlejší. Urˇcitýmzjednodušením prošla definice deskriptivních sort. V metodˇeHIT je definice deskriptivních sort navržena pomˇernˇeobecnˇea analytik je tak schopen popsat jakýkoliv požadovaný typ. Pˇríklad4.2.1 ukazuje definici deskriptivní sorty Casˇ pomocí metody HIT. Tento pˇrístuprozhodnˇenení na škodu, ale pro naše použití je to pomˇernˇezbyteˇcné.Samotná knihovna, která by tento obecný pˇrístupimplementovala, by byla znaˇcnˇesložitˇejší,protože by musela rozhodnout, jak námi popisovanou deskriptivní sortu zobrazí v prostˇredíRuby on Rails. Proto se vychází z toho, že Ruby on Rails má již sv ˚ujseznam základních datových typ ˚u,se kterými dokáže pracovat a definice jiných než uvedených typ ˚unení možná. Nemu- síme však mít obavu, nebot’ jsou pokryty všechny bˇežnˇepoužívané datové typy. Definice pak m ˚užouvypadat následovnˇe: d :date_of_birth, ’datum narození’, :date d :title, ’titul’, :string d :pre_title, ’tituly predˇ jménem’, :title Entitní sorty jsou definovány velice jednoduše. Zápis m ˚uževypadat následujícím zp ˚u- sobem: e :BankAccount, ’bankovní spojení’ e :Phone, ’Telefoní kontakt’ Pˇriurˇcováníklíˇc˚ukaždé entity výsledného ER-diagramu se vychází opˇetz konvencí Ruby on Rails, které mají dané jasné doporuˇcení,jak definovat primární a cizí klíˇce.Podrob- nˇejibyla definice klíˇc˚upopsána v kapitole 3.3.3. Díky tomu není nutné se zabývat jejich de- finicí a pˇripˇrevoduHIT-schématu se o jejich vytvoˇrenípostará automaticky naše knihovna. Zbývá nám jen ukázat, jak jsou znaˇcenyjednotlivé HIT-atributy. Oznaˇcenyjsou poˇcáteˇc- ním písmenem h. Zápis pak vypadá takto: e :Bank, ’banka’ h ’Jméno’, :name, ’daného banky’, :Bank, ’1101’ h ’Kód’, :bank_code, ’dané banky’, :Bank, ’1101’ d :name, ’jméno’, :string d :bank_code, ’kód’, :string Je možné zaznamenávat i vztahy mezi jednotlivými entitními sortami: h ’Osoba’, :Person, ’, které daný email patrí’,ˇ :Email, ’010M’ h ’Akce’, :Event, ’ke které daná prílohaˇ náleží’, :Attachment, ’010M’ Pˇripˇrevodupak knihovna vytvoˇrív aplikaci nejen nové migrace, ale pˇridái pˇríslušné modely. Textové popisky, které byly uvedeny pˇrizápisu HIT-atribut ˚u,jsou pak v modelech pro pˇrehlednosttaké pˇripojeny, a to formou komentáˇr˚u. 28 Kapitola 5 Analýza a návrh systému Pro analýzu systému byl použit modelovací jazyk UML (Unified Modeling Language). UML je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a doku- mentaci programových systém ˚u.To nám umožˇnujeefektivnˇemodelovat jednoduché i slo- žité aplikace pomocí stejné formální syntaxe a tím i zajistit vnitˇrníkonzistenci vytváˇrených diagram ˚u[4]. 5.1 Rozdˇeleníaplikace Pˇredzapoˇcetímsamotného modelování bylo nutné rozhodnout, jestli naším cílem je vy- tvoˇritjednu ucelenou aplikaci, a nebo poskytnout systém, jehož funkce budu možné roz- šiˇrovatpomocí nových modul ˚u.SpoleˇcnostIglooNET, s.r.o. plánuje aplikaci v budoucnu nadále rozšiˇrovata jednotlivé její ˇcástinabízet pak dál svým zákazník ˚um.Z toho d ˚uvodu je zˇrejmé,že je nutné celé prostˇredínavrhnout modulárnˇe.Jednotlivé komponenty systému bude možné poskládat podle pˇredstavzákazníka. Základní modul aplikace nese název CRM1. Aby bylo v ˚ubecmožné vytváˇretdalší mo- duly, je nutné nejprve zajistit správu uživatel ˚ua správu pˇrístup˚udo systému. Tato funk- cionalita je právˇeposkytována zde. Co dalšího nám ale m ˚užeCRM nabídnout? D ˚uležitou souˇcástíje správa subjekt ˚ua s tím spojená evidence informací o jednotlivých zákaznících (emailové adresy, telefonní ˇcísla,kontaktní údaje a další). Pro správný chod firmy hraje vý- znamnou roli i podpora mezifiremní komunikace. Pro tyto úˇcelyposkytuje modul CRM možnost vytváˇreta rozesílat emaily nebo krátké textové zprávy (SMS) na evidovaná tele- fonní ˇcísla. Cílem této práce je navrhnout a implementovat ˇrešení,které nabídne firmˇenástroje pro ˇrízeníprojekt ˚ua správu uživatelských požadavk ˚u.Toto je právˇeobsaženo v druhém mo- dulu pro projektové ˇrízení.Kromˇesamotné správy projekt ˚ua požadavk ˚uje zde poskytnuta uživateli možnost evidence ˇcasustráveného ˇrešenímjednotlivých úkol ˚unebo také zobrazo- vání r ˚uznýchsouhrnných informací. Nutnou souˇcástíwebové aplikace je modul pro systémová nastavení. Naše aplikace ob- sahuje ˇradud ˚uležitýchˇcíselník˚u. Casˇ od ˇcasuje však nutné pˇridatnebo upravit nˇekteréulo- žené hodnoty. Spravovat lze napˇríkladstáty, mˇesta,banky nebo firemní pozice. Tyto údaje se pak využívají na r ˚uznýchmístech po celém systému. 1. Customer Relationship Management 29 5.2. SEZNAM AKTÉRU˚ Tento výˇcetfunkcí, který je zde uveden, není zdaleka kompletní. V této kapitole bude ještˇevˇenovánapozornost detailnˇejšímupopisu. 5.2 Seznam aktér ˚u Náš systém se bude skládat pouze z neveˇrejnéˇcástia pˇrístupnýbude všem oprávnˇeným uživatel ˚um.Pro r ˚uznéskupiny lidí nabídneme r ˚uznépohledy na aplikaci. V systému máme dvˇezákladní skupiny aktér ˚u: • Administrátor • Uživatel 5.2.1 Administrátor Administrátor zastává v systému roli superuživatele. Vlastní neomezená práva ke všem ˇcástemaplikace. M ˚uževykonávat všechny stejné operace jako bˇežnýuživatel. Navíc má možnost spravovat pˇrístupovéuživatelské úˇctya pˇridˇelovatdalší administrátorská práva. Jako jediný m ˚užepˇristupovat k modulu pro systémová nastavení a tak spravovat systémové ˇcíselníkya promˇenné. 5.2.2 Uživatel Uživatel je základním aktérem v systému. Podle pˇridˇelenýchuživatelských rolí má opráv- nˇenívyužívat pˇríslušnéfunkce systému. Uživatelské role mohou být pˇridˇelenyjedinˇead- ministrátorem. Co se týˇcepˇridˇelováníuživatelských rolí, je nutné poznamenat, že administrátor má možnost všechny role dále seskupovat podle libosti a umožnit tak jednodušší pˇriˇrazování. Napˇríkladje možné vytvoˇritnovou skupinu uživatelských rolí nazvanou Manager pro- jekt ˚u, které budou pˇriˇrazenyvšechny role týkající se zakládání nových projekt ˚ua kompletní správy stávajících projekt ˚u.Pokud se pak bude pˇridávatdo systému nový manager pro- jekt ˚u,pˇriˇradíse mu jen patˇriˇcnáskupina a není nutné tak zbyteˇcnˇepˇriˇrazovatkaždou roli zvlášt’. 5.3 Modely pˇrípad˚uužití Vymezení hranic systému je v UML podpoˇrenodynamickým pohledem modelovaným pro- stˇrednictvímdiagram ˚upˇrípad˚uužití. Tento diagram, obecnˇemodel, zobrazuje základní vztah systému k jeho okolí (aktér ˚um).Každý pˇrípadužití pak pˇredstavujejeden z možných zp ˚usob˚upoužití systému, jednu z možných cest komunikace aktér-systém. V rámci tvorby tˇechtodiagram ˚uje modelován vztah systému a jeho okolí, nikoliv vzájemná interakce, tj. zp ˚usob,jakými jsou jednotlivé pˇrípadyužití zajištˇenyinterními funkcemi systému. 30 5.3. MODELY PRÍPADˇ UUŽITÍ˚ 5.3.1 Modul systémových nastavení Administrátor je jediným aktérem v aplikaci, který má možnost pˇristupovatk modulu sys- témových nastavení a provádˇetzde pˇríslušnéúpravy. Nastavení, které je zde možné pro- vést, m ˚uževýraznˇeovlivnit chování celého systému. Pˇrístupjiných než oprávnˇenýchosob je proto zbyteˇcný.Grafické znázornˇenípˇrípad˚uužití poskytuje obrázek 5.1. Obrázek 5.1: Model pˇrípad˚uužití pro modul systémových nastavení Zobrazit úvodní detail Tato funkcionalita umožˇnujeadministrátorovi zobrazit sou- hrnný pˇrehledo nových zmˇenáchv systémových nastaveních. Jedná se o první infor- mace, které jsou administrátorovi poskytnuty pˇrivstupu do tohoto modulu. Správa systémových nastavení Správa systémových nastavení dovoluje administrá- torovi editovat nˇekteréd ˚uležitépromˇennév systému. Je možné si tak nastavit napˇrí- klad jiný název celé aplikace, formát ukládaných ˇcasovýchúdaj ˚unebo zakázat nˇe- které moduly. Správa Instant Messengers Tato ˇcástumožní administrátorovi spravovat ˇcíselník In- stant Messengers, který se následnˇepoužívá v r ˚uznýchˇcástechnašeho systému. In- stant Messager je internetová služba umožˇnujícísvým uživatel ˚umsledovat, kteˇríje- jich pˇráteléjsou právˇepˇripojenia dle potˇrebyjim posílat zprávy, chatovat, pˇreposílat soubory mezi uživateli a jinak komunikovat. Mezi nejvíce svˇetovˇepoužívané patˇrí napˇríkladSkype, Jabber, MSN nebo ICQ. 31 5.3. MODELY PRÍPADˇ UUŽITÍ˚ Správa mestˇ Správa mˇestdovoluje administrátorovi spravovat ˇcíselníkmˇestv systému. Naplnit takovýto ˇcíselníkpˇredemje ponˇekudnároˇcnéa hlavnˇeby zde byla potˇreba neustálé aktualizace. Proto lze v aplikaci doplˇnovatnová mˇesta,která jsou nejprve oznaˇcenajako neschválená. V této ˇcástim ˚užepak administrátor vybraná mˇestaschva- lovat, opravit pˇreklepyv zadaných názvech ˇcipˇrípadnˇeslouˇcitjedno mˇestos dru- hým. Správa stát˚u Tato funkce systému dovolí administrátor ˚umspravovat ˇcíselníkstát ˚uv na- šem systému. Správa bank Protože je nutné v aplikaci evidovat k lidem jejich bankovní úˇcty, vznikl ˇcíselníkpro správu bank systému. Funkcionalita správy bank umožˇnujeadministrá- torovi dˇelatpatˇriˇcnézmˇenyv tomto ˇcíselníku. Správa firemních pozic K subjekt ˚umv systému je možné pˇriˇrazovati osoby p ˚uso- bící v rámci dané firmy. Pro tyto úˇcelyvznikl ˇcíselníkpro správu firemních pozic. Evidovat lze napˇríkladtakové pozice jako je jednatel, obchodní zástupce ˇciadminis- trativní pracovník. Funkcionalita správy firemních pozic umožˇnujeadministrátorovi spravovat tento ˇcíselník. 5.3.2 Modul CRM K modulu CRM mohou pˇristupovatvšichni aktéˇrinašeho systému, tedy administrátoˇria uživatelé. Administrátor má neomezený pˇrístupke všem ˇcástemtohoto modulu. Funkce, které mohou využívat jednotliví uživatelé, se liší individuálnˇev závislosti na pˇridˇelených rolích. Diagram si lze prohlédnout na obrázku 5.2. Správa uživatel˚u Tato funkcionalita poskytuje kompletní správu uživatel ˚uv systému. Uživatele je tak možné zakládat, editovat nebo mazat, pokud to však dovolí pˇríslušné oprávnˇení.Aby se uživatel v datech neztratil, je nutné mu nabídnout i r ˚uznémožnosti filtrování. Pˇrizobrazení detailu každého uživatele pak m ˚užedoplˇnovatˇradudalších údaj ˚u: • Správa adres - Správa adres dovoluje pˇridávata upravovat adresy u jednotli- vých uživatel ˚u.Pro naše úˇcelyje potˇrebaevidovat pouze tˇridruhy adres – fak- turaˇcní, kontaktní a jiné adresy. Pˇrizadávání nové adresy je možné dohledávat existující mˇestoa stát v ˇcíselnících,které jsou spoleˇcnépro celou aplikaci. Pokud není nalezeno požadované mˇesto,lze pˇridat mˇestozcela nové, které však bude oznaˇcenojako neschválené a bude ˇcekatna zkontrolování administrátorem. 32 5.3. MODELY PRÍPADˇ UUŽITÍ˚ Obrázek 5.2: Model pˇrípad˚uužití pro modul CRM • Správa telefonních ˇcísel - Správa telefonních ˇcíselumožˇnujepˇridávata upra- vovat telefonní ˇcíslau jednotlivých uživatel ˚u.Na tyto telefonní ˇcíslalze pak ze systému rozesílat krátké textové zprávy. Z toho d ˚uvodujsou všechny údaje pˇred samotným uložením zkontrolovány, zda vyhovují požadovanému formátu. • Správa webových kontakt ˚u - Tato funkcionalita dovoluje pˇridávata upravovat internetové adresy, které jsou pˇridružené k jednotlivým uživatel ˚um.Pˇredulože- ním je ovˇeˇreno,zda je skuteˇcnˇezadávána internetová adresa. • Správa emailových adres - Aby byla umožnˇenapozdˇejšíkomunikace mezi sa- motnými uživateli, je nutné evidovat emailové adresy. O to se starají funkce správy emailových adres. Všechny adresy jsou pˇreduložením zkontrolovány, zda mají správný tvar. • Správa úˇct˚uInstant Messenger - Tato funkce umožˇnujespravovat úˇctyInstant Messenger pro jednotlivé uživatele. Pˇrizakládání uživatel vybírá konkrétní typ úˇctuz ˇcíselníku,který je spoleˇcnýpro celou naši aplikaci. • Správa bankovních úˇct˚u - Správa bankovních úˇct˚udovoluje pˇridávata upra- vovat bankovní úˇctyv naší databázi. Ty jsou nutné proto, aby mohla aplikace v budoucnu pˇrijímatinformace o došlých platbách. V systému existuje ˇcíselník, ze kterého je nutné pˇripˇridávánínového úˇctuvybírat pˇríslušnoubanku. Pro plánované zahraniˇcníplatby lze místo klasického ˇcíslaúˇctuevidovat takzvaný IBAN2. 2. International Bank Account Number (IBAN) je mezinárodní ˇcíslobankovního úˇctuumožˇnujícíprovádˇet platby do a ze zahraniˇcí 33 5.3. MODELY PRÍPADˇ UUŽITÍ˚ Správa subjekt˚u Správa subjekt ˚udovoluje administrátorovi nebo uživatel ˚umevidovat vztah k r ˚uznýmtyp ˚umsubjekt ˚u.Jako subjekt však nemusí vystupovat pouze firmy a podnikatelé, ale i osoby nepodnikající. I u nepodnikajících osob však m ˚užebýt po- tˇreba,aby za ni vystupovalo více uživatel ˚u- napˇríkladwebmaster pro nˇeˇcíosobní stránky. Proto subjekt typu osoba má totožné vlastnosti jako subjekt typu firma, odli- šuje se pouze tím, že u nˇejnení evidovano ICˇ a DIC.ˇ Pˇriukládání nového subjektu je nutné, aby systém ovˇeˇril,zda takový záznam neexistuje v naší databázi. K subjekt ˚um lze pˇriˇrazovatstejné údaje jako u uživatel ˚u– adresy, telefonní ˇcísla,webové kontakty, emailové adresy, úˇctyInstant Messenger a bankovní úˇcty. Navíc je možné pˇripojit následující údaje: • Správa zákazník ˚u - Tato funkcionalita dovoluje k subjekt ˚umpˇriˇraditjejich zá- kazníky. V roli zákazníka zde vystupuje opˇetsubjekt dohledaný v databázi na- šeho systému. • Správa firemních osob - Úˇcelemtéto funkce je evidence osob, které spolupra- cují s konkrétním subjektem. Jako firemní osoba vystupuje uživatel dohledaný v databázi našeho systému. Aby bylo umožnˇenojemnˇejšídˇelení,lze navíc každé osobˇepˇriˇraditjejí pozici ve firmˇe.Hodnoty firemních pozic jsou uloženy ve spo- leˇcnémsystémovém ˇcíselníku. • Export a import z CSV - Tato funkcionalita poskytuje možnost exportovat vyfil- trované subjekty do textových CSV soubor ˚u3. Aby bylo dovoleno pˇrenášetdata i z jiných systém ˚udo našeho, je zde funkce pro zpˇetnýimport subjekt ˚udo apli- kace. • Dohledání subjekt ˚u - Funkcionalita dohledání subjekt ˚uulehˇcujezadávání no- vých firem do systému. Vychází se z toho, že témˇeˇrkaždá firma má pˇridˇelené svoje IC.ˇ Pomocí jednoduchého API je pak provádˇenakomunikace s ˇcíselníkem ARES4. Administrativní registr ekonomických subjekt ˚u(ARES) je státní infor- maˇcnísystém, který umožˇnujevyhledávání nad ekonomickými subjekty regis- trovanými v Ceskéˇ republice. Zprostˇredkovávázobrazení údaj ˚uvedených v jed- notlivých registrech státní správy, ze kterých ˇcerpádata. Na základˇedohleda- ných údaj ˚ujsou pˇredvyplnˇenyúdaje nutné pro založení nového subjektu. Správa prístupovýchˇ úct˚uˇ Správa pˇrístupovýchúˇct˚udovoluje administrátor ˚umsys- tému zakládat nebo upravovat stávající pˇrístupovéúˇcty. Je možné tak vytvoˇritbˇežný pˇrístupovýúˇcetnebo založit úˇcetadministrátorský. Jednotlivým uživatel ˚umpak lze individuálnˇepovolit vstup jen do nˇekterýchmodul ˚u. 3. CSV (Comma-separated values) je jednoduchý souborový formát urˇcenýpro výmˇenutabulkových dat 4. http://wwwinfo.mfcr.cz/ares/ares.html 34 5.3. MODELY PRÍPADˇ UUŽITÍ˚ Správa skupin S rostoucím poˇctemevidovaných subjekt ˚uje nutné zajistit vše potˇrebné pro to, aby uživatelé mˇelinástroj na jejich kategorizaci. Pˇrípadužití Správa skupin zahrnuje nástroje, které by mˇelytuto funkcionalitu zajišt’ovat. Vytváˇretlze skupiny, které mohou být ˇrazenydo libovolné stromové struktury a do kterých lze snadno pˇriˇraditvšechny vybrané subjekty. Správa zpráv Tato funkcionalita dovoluje administrátor ˚umnebo uživatel ˚umvytváˇret, upravovat a rozesílat zprávy. Ty mohou být dvojího druhu – krátké textové zprávy nebo emaily. Adresy pro nové emailové zprávy se zakládají pomocí funkcí uvede- ných v pˇrípaduužití Správa emailových adres. Adresáti pro krátké textové zprávy jsou uloženi naopak za použití funkcí popsaných v pˇrípaduužití Správa telefonních ˇcísel. Zde se pouze provede jejich dohledání. Protože tˇelozpráv se m ˚užemnohokrát opakovat, existuje zde z tohoto d ˚uvodufunkce tvorby šablon, které mají usnadnit pozdˇejšízakládání. Správa událostí Správa událostí poskytuje všechny potˇrebnéfunkce pro evidenci vý- znamných událostí v systému. Správa zahrnuje jejich vytváˇrení,editaci a mazání. Pˇri zakládání uživatel vybírá ze systému subjekt, který zastává roli poˇradatele.Každé události je možné následnˇepˇriˇraditlibovolný poˇcetúˇcastník˚u.Protože se události ˇcastoopakují, jsou zde obsaženy i funkce pro jejich snadné duplikování. Pro snadnou orientaci je nutné uživateli nabídnout i r ˚uznémožnosti filtrování. Správa soubor˚u Funkcionalita správy soubor ˚uumožˇnujejednoduchou práci se soubory v našem systému. Rozšiˇrujepˇrípadyužití Správa událostí a Správa zpráv. Soubory lze tak pˇrikládatk evidovaným událostem, ale také k vytváˇrenýmzprávám. U zpráv se soubory využívají jako pˇrílohyv emailové komunikaci, jedinˇetak je rozesílání opravdu plnohodnotné. 5.3.3 Modul projektového ˇrízení Také k modulu projektového ˇrízenímohou pˇristupovatvšichni aktéˇrinašeho systému – ad- ministrátoˇria uživatelé. Uživatelé mohou vykonávat jen ty funkce odpovídající pˇriˇrazeným rolím. Každý projekt má navíc svého správce a m ˚užemít pˇriˇrazensvé úˇcastníky. Správc ˚um projektu je povolena kompletní úprava vlastních projekt ˚ua úkol ˚u.Mohou je editovat, mazat ˇcilibovolnˇepˇresouvat.Úˇcastníciprojektu již taková práva nemají. Mají povoleno provádˇet pouze takové akce, které slouží k plnˇeníjednotlivých úkol ˚u,ke kterým byli pˇriˇrazeni. 35 5.3. MODELY PRÍPADˇ UUŽITÍ˚ Obrázek 5.3: Model pˇrípad˚uužití pro modul projektového ˇrízení Zobrazit hromadný prehledˇ Funkcionalita hromadného pˇrehleduzobrazuje aktuální zmˇenyv projektech a úkolech, týkající se aktuálnˇepˇrihlášenéhouživatele. Jedná se o první informace, které jsou poskytnuty pˇrivstupu do modulu a které mají zpˇre- hlednit celkovou orientaci v nejnovˇejšíchaktualizacích. Správa projekt˚u Pˇrípadužití Správa projekt ˚u zahrnuje funkce pro kompletní správu projekt ˚u.Nové projekty mohou zakládat pouze administrátoˇrisystému. Vytvoˇreným projekt ˚umje možné pak pˇriˇrazovatjejich správce a úˇcastníky. Pˇriukládání je nutné provést potˇrebnévalidace, aby byly d ˚uležitéinformace uchované ve správném tvaru a aby nebylo možné vytvoˇritnapˇríkladprojekt bez pˇriˇrazenéhosprávce. Každý pro- jekt má pˇriˇrazenzároveˇnidentifikátor, podle kterého se vygeneruje jeho internetová adresa, na které ho lze odkazovat. Pokud je provedena zmˇenatohoto identifikátoru, je nutné aktualizovat i danou adresu. Starší odkazy si systém nadále pamatuje a pˇri odkazování na nˇeje d ˚uležitépˇresmˇerovat na aktuální záznam. Historie všech úprav se v systému eviduje. Správa podprojekt˚u U vˇetšíchfirem zaˇcneˇcasemdocházet k nutnosti dˇelitspravované projekty na menší ˇcásti.Aby bylo umožnˇenosložitˇejšíˇclenˇeníprojekt ˚u,zavedla se možnost tvorby podprojekt ˚u.Tento pˇrípadužití pokrývá všechny funkce týkající se jejich správy. Ke každému projektu lze zakládat nové podprojekty a nebo dohledávat projekty už existující z databáze systému. Díky tˇemtofunkcím dokážeme jednotlivé projekty mezi sebou libovolnˇesdílet a je už pouze na uživateli, jak se rozhodne je 36 5.3. MODELY PRÍPADˇ UUŽITÍ˚ mezi sebou uspoˇrádat. Zobrazit prehledˇ projekt˚u Tato funkcionalita zajistí, že pˇrivstupu do projektu jsou uživateli zobrazeny nejd ˚uležitˇejšíinformace týkající se samotného projektu a další souhrnné údaje ohlednˇepˇriˇrazenýchúkol ˚u.Uživatel tak napˇríkladdostane pˇrehled stráveného ˇcasuna jednotlivých úkolech. Protože jsou v systému evidovány zmˇeny, které jsme na projektu provedli, obsahuje tato ˇcástfunkce pro zobrazení historie všech úprav. Správa úkol˚u Správa úkol ˚udovoluje pˇridávata upravovat jednotlivé úkoly, jsou evi- dovány v rámci daného projektu. Každá zmˇena,která byla provedena, se ukládá. Protože je dovoleno úkoly sdílet mezi projekty, je souˇcástítéto správy i funkce, která umožní dohledání již existujících úkol ˚u. Správa podúkol˚u Stejnˇejako tomu bylo u projekt ˚u,tak i u úkol ˚uje dovoleno jemnˇejší dˇelení.Z toho d ˚uvoduzde existuje funkcionalita poskytující potˇrebnénástroje pro správu podúkol ˚u.Uživatel si pak úkoly m ˚užeposkládat do libovolné struktury podle potˇreby. Pˇrikaždé zmˇenˇeje ale d ˚uležitéovˇeˇrit,zda úkol z ˚ustalzaˇrazenbud’ k pro- jektu nebo k nadˇrazenémuúkolu. Samostatné nezaˇrazenéúkoly systém není dovo- leno vytvoˇrit. Zobrazit prehledˇ úkol˚u Tato funkcionalita poskytne uživateli pˇrizobrazení detailu základní pˇrehledpodstatných údaj ˚u,které jsou evidovány k vybranému úkolu. Jed- notlivé funkce nám vypíšou ˇcasystrávené plnˇenímúkolu, dále pak je možné zobra- zovat napˇríkladhistorii provedených úprav. Správa aktivit Správa aktivit poskytuje uživatel ˚ummožnost evidovat strávený ˇcaspl- nˇenímjednotlivých úkol ˚u. Casˇ je vykazován v hodinách. Aby byla možnost pˇresnˇej- šího dˇelení,lze uvádˇeti desetinná ˇcísla. Správa rychlých poznámek Správa rychlých poznámek zahrnuje potˇrebnéfunkce pro správu krátkých textových poznámek k jednotlivým úkol ˚um.Každý uživatel, který má pˇrístupk danému úkolu, m ˚užepˇripojitvlastní textovou poznámku. Správa kategorií Tato funkcionalita dovoluje všem administrátor ˚umspravovat kate- gorie projekt ˚u,podle kterých se pak budou tˇríditvybrané úkoly. Jednotlivým kate- goriím je pak možné nadefinovat jejich hodnoty, které se vypíšou ve formuláˇripro 37 5.4. DIAGRAM TRÍDˇ editaci daného úkolu. Napˇríkladsi tak lze založit kategorii Priorita, která bude mít pˇriˇrazenyhodnoty: okamžitá, urgentní, vysoká, normální a nízká. Pokud se správce projektu rozhodne evidovat u svých úkol ˚uprioritu, bude pak možné v budoucnu pˇriˇraditk požadavku jednu ze zmínˇenýchhodnot. 5.4 Diagram tˇríd Základem vˇetšinyobjektovˇe-orientovanýchtechnik jazyka UML je diagram tˇríd.Pˇredsta- vuje grafický pohled na statickou strukturu systému. Avšak dokáže zachytit i vlastnosti týkající se chování. Samotný systém popisuje pomocí tˇrída zachycuje vztahy mezi nimi. Diagram tˇrídumožˇnuješiroké možnosti využití, pˇresmodelování specifické datové struk- tury pro doménovou oblast, až po detailní návrh cílového systému. V pˇredchozíchkapitolách bylo již nˇekolikrátuvedeno, že pro návrh struktury systému se použila metoda HIT. VytvoˇrenéHIT-schéma, které je popsáno v aplikaci, se pak automa- ticky pˇrevádípomocí vhodné knihovny na soubory migrací a pˇríslušnémodely. Pro snad- nˇejšíznázornˇenívýsledku je vždy vhodnˇejšínavrženou strukturu systému vizualizovat. Následující diagramy tˇrídzachycují strukturu model ˚uaplikace, pˇresnˇetak, jak byla vyge- nerována knihovnou pro pˇrevodHIT-schématu. Diagram tˇrídcelého systému je pˇrílišrozsáhlý a popisovat zde každou jeho ˇcástby ne- mˇelovýznam. Z toho d ˚uvodujsou vybrány pouze nejd ˚uležitˇejšíˇcástiaplikace a zbytek této kapitoly bude vˇenovánjejich detailnˇejšímurozboru. Pro jednoduchost jsou v našich diagra- mech skryty i jednotlivé atributy a operace specifické pro každou tˇrídu.Aby i pˇrestobylo možné si prohlédnout kompletní popis struktury systému, je uvedeno v pˇrílozetéto práce pˇríslušnéHIT-schéma, které všechny vlastnosti a vztahy zachycuje. 5.4.1 Evidence zmˇen Již pˇredzapoˇcetímtvorby podrobnˇejšíhomodelu systému bylo zˇrejmé,že bude nutné na ˇradˇemíst evidovat pr ˚ubˇehzmˇenobjekt ˚uv ˇcase.Dejme tomu, že v naší aplikaci máme da- tabázi firem. Pˇríklademjedné takové firmy m ˚užebýt spoleˇcnost Hraˇcky, s.r.o. Rok po zave- dení našeho systému zmˇenífirma sv ˚ujnázev na Království hraˇcek,s.r.o. Pro naše úˇcelyje nutné v systému evidovat jak souˇcasný,tak i p ˚uvodnínázev. Jak se ale k tomuto problému postavit? Vyjdeme ze zmínˇenéhopˇríkladus evidencí subjekt ˚u.U takovýchto záznam ˚uje nutné evidovat celou ˇraduúdaj ˚u.Na první pohled je zˇrejmé,že existují vlastnosti, u kterých m ˚užemei nemusíme zaznamenávat zmˇeny. Napˇríkladnázev je atribut, který se v pr ˚ubˇehu ˇcasum ˚užemˇenit.Stejnˇetak i textový popis daného subjektu nebo dokonce ˇcasprovedení zmˇeny. Na druhou stranu m ˚užememít údaje jako ˇcasvytvoˇrenízáznamu v databázi nebo autora, který subjekt založil. Toto jsou vlastnosti, které se v ˇcasemˇenitnebudou. Na diagramu 5.4 je možné vidˇetdvˇetˇrídy, které jsou spojeny pˇríslušnouvazbou. Ozna- ˇcenyjsou jako Hlava a Snímek. V aplikaci je ˇcastouvádˇenanglický ekvivalent Head a Snap. V systému samotném však díky vhodnˇenavržené knihovnˇevystupují jako jeden 38 5.4. DIAGRAM TRÍDˇ Obrázek 5.4: Diagram tˇrídpro evidenci historie celek. Na objekt tˇrídyoznaˇcenéjako Hlava m ˚užebýt navázáno až nˇekolikobjekt ˚utˇrídy Snímek. Je-li potˇrebase v systému odkazovat na objekt s evidovanou historii, odkazuje se po- každé na Hlavu. Jedná se o tˇríduzahrnující všechny vlastnosti, u kterých není nutné evido- vat zmˇeny. Zde jsou uloženy hodnoty jako je napˇríkladˇcaszaložení záznamu. Všechny informace, které se mohou mˇenitv ˇcase,jsou uloženy v rámci tˇrídy Snímek. Její objekty si evidují vazbu na objekt tˇrídy Hlava, který vše sdružuje do jednoho celku. Dále mají uložené údaje urˇcujícíobdobí platnosti daného snímku. Pokaždé, když bude pro- vedena zmˇenatˇechtoatribut ˚u,vytvoˇríse v systému nový snímek. Na diagramu je možné vidˇetvazbu snaps. Ta ukazuje na všechny snímky, které byly k danému objektu tˇrídy Hlava vytvoˇreny. Aktuálnˇeplatný snímek lze poznat podle toho, že atribut to je nedefinovaný. Pokud platný snímek neexistuje, znamená to, že byl daný objekt vymazán. Pokaždé se však nemusí evidovat pouze zmˇenyúdaj ˚u.Existují situace, kdy je d ˚uležité uložit informaci o tom, že nˇekterýobjekt byl ve vazbˇes jiným objektem. Rešeníˇ je založeno na tom, že se uloží údaje urˇcujícíobdobí platnosti a podle toho se pozná, kdy byla daná vazba v historii realizována. Detailnˇeje tato situace znázornˇenana obrázku 5.5. Zde je ulo- žena informace o tom, kdy byl daný uživatel ˇclenemdaného subjektu. 5.4.2 Modul CRM Struktura celého modulu CRM je znaˇcnˇerozsáhlá. Není však podstatné rozebírat detailnˇe každou jeho ˇcást.Zobrazení bylo redukováno dokonce o ˇraduˇcíselník˚u.Kompletní struk- tura je opˇetk nahlédnutí v pˇrílozetéto práce. Na následujícím diagramu je ukázáno, jak jsou v aplikaci vymodelovány jednotlivé tˇrídypro práci s uživateli a subjekty v systému. Dále model obsahuje i další navázané tˇrídypˇredstavujícípˇripojenéúdaje k jednotlivým uži- vatel ˚uma subjekt ˚um.Tˇrída Person a tˇrída Subject dovolují evidovat historii. V našem diagramu jsou pro jednoduchost znázornˇenyjako jedna tˇrída.Ve skuteˇcnostise historie evi- 39 5.4. DIAGRAM TRÍDˇ Obrázek 5.5: Diagram tˇrídpro evidenci historie vazeb duje podle postupu, který byl uveden v pˇredchozíkapitole. Trídaˇ Person Práci s bˇežnýmiuživateli v našem systému obstarává tˇrída Person. Ke každému záznamu dovoluje ukládat jméno, pˇríjmení,titul, pohlaví. Aby byly naše údaje evidovány korektnˇe,obsahuje všechny potˇrebnévalidace, které zajistí nutnou kontrolu pˇreduložením. Trídaˇ Account Tˇrída Account umožˇnujeuživatel ˚umpˇridˇelitpˇrístupdo naší aplikace. Každý uživatel m ˚užemít maximálnˇejeden pˇrístupovýúˇcet.D ˚uležitousouˇcástíje me- toda try_login, která slouží k autentizaci uživatel ˚u.Metoda vezme pˇredanépˇrihla- šovací údaje a pokusí se je ovˇeˇrit.V pˇrípadˇe,že jsou shodné s nˇekterýmzáznamem v databázi, vrátí pˇríslušnouinstanci tˇrídy Account. Další zajímavá souˇcást,kterou ta- hle tˇrídaobsahuje, je tˇrídnímetoda hash_password. Svoje využití má pˇrivytváˇrení nových instancí. Aby heslo nebylo ukládané v otevˇrenémtvaru, z pˇredanéhoúdaje vytváˇrípomocí hashovací funkce SHA-2565 otisk, který je pak uložen do databáze. Trídaˇ Subject Tˇrída Subject pˇredstavujerozhraní pro práci s jednotlivými subjekty v sytému. Jak lze podrobnˇejividˇetna diagramu 5.6, navázány jsou dvˇepodtˇrídy– Company a VirtualPerson. Jedním druhem subjekt ˚u,které jsou možné evidovat v našem systému, jsou firmy. Pro práci s tˇemito záznamy vznikla tˇrída Company. Protože každá firma musí mít sv ˚ujunikátní název a ICˇ se m ˚uževyskytovat také pouze jednou, nabízí tato tˇrída validace, které se postarají o konzistentní stav databáze tˇechtosubjekt ˚u. 5. SHA (Secure Hash Algorithm) je rozšíˇrenáhashovací funkce, která vytváˇríze vstupních dat výstup (otisk) fixní délky. SHA navrhla organizace NSA (Národní bezpeˇcnostníagentura v USA) a vydal NIST (Národní in- stitut pro standardy v USA) jako americký federální standard. SHA je rodina pˇetialgoritm ˚u:SHA-1, SHA-224, SHA-256, SHA-384 a SHA-512. Poslední ˇctyˇrivarianty se souhrnnˇeuvádˇejíjako SHA-2. 40 5.4. DIAGRAM TRÍDˇ Obrázek 5.6: Diagram tˇrídznázorˇnujícívztah mezi tˇrídouPerson a Subject Pokaždé ale není podmínkou, aby jako subjekt v naší aplikaci vystupovala firma. Sub- jekty mohou tvoˇriti osoby. Z toho d ˚uvoduvznikla tˇrída VirtualPerson, která dˇedí vlastnosti od tˇrídy Subjekt. Tento druh subjekt ˚uvzniká vždy k nˇejakémuexistují- címu uživateli (instance tˇrídy Person). Proto je na diagramu znázornˇenapˇríslušná vazba Subject-Person. Ostatní údaje subjekt˚ua osob Na našem diagramu lze vidˇeti ˇradutˇríd,které se nacházejí mezi tˇrídami Person a Subject. Ve spoustˇepˇrípad˚uje vhodné k uživate- l ˚umnebo subjekt ˚umevidovat další údaje. Umožnˇenoje navázat: • webové kontakty • emailové adresy • bankovní úˇcty • zákazníky subjekt ˚u • firemní osoby • kontakty Instant Messenger 41 5.4. DIAGRAM TRÍDˇ • telefonní ˇcísla • adresy Každý záznam m ˚užemít vazbu bud’ na uživatele nebo nˇekterýsubjekt. Nikdy však na oba zároveˇn.Tento stav je ovˇeˇrovánopˇetpomocí jednoduchých kontrolních me- tod. Tˇrída Address pˇredstavujeuložené kontaktní informace pro jednotlivé uživatele nebo subjekty. Pro naše úˇcelyje nutné vˇedˇet,jaké adresy byly pˇriˇrazenéi v minulosti. Proto je tˇrída Address rozšíˇrenai o možnost evidovat historii kontaktních údaj ˚u. 5.4.3 Modul projektového ˇrízení Protože hlavním cílem této práce je vytvoˇrenímodulu pro správu uživatelských požadavk ˚u a ˇrízeníúloh, bude v této ˇcástipodrobnˇejirozebráno, jaká struktura byla zvolena pro uklá- dání všech potˇrebnýchinformací. Výsledek je zobrazen na následujícím diagramu tˇríd.Je nutné však poznamenat, že také zde uvedený diagram je ˇcásteˇcnˇeredukovaný o tˇrídyslou- žící k evidenci historie. Kdybychom je použili v našem zobrazení, byl by diagram zbyteˇcnˇe složitˇejší.Pˇredsamotným popisem jednotlivých ˇcástíje nutné zmínit d ˚uvody, proˇcbyla struktura systému navržena zrovna tímto zp ˚usobem. Pˇritvorbˇestruktury tohoto modulu bylo nejtˇežšímúkolem navrhnout, jakým zp ˚usobem se postavit k ukládání jednotlivých projekt ˚u,požadavk ˚ua zbylých souvisejících dat. V prv- ním kroku bylo nutné provést identifikaci tˇríd.Ty se urˇcítak, že se naleznou všechna pod- statná jména nebo slovní spojení, která jsou významná v popisované oblasti projektového ˇrízení.Mezi nimi byli vybráni nasledující kandidáti: • projekty • úkoly • kategorie • rychlé poznámky • vykázaná práce Po zakreslení všech asociací, které jsou potˇrebnémezi nalezenými tˇrídami,bylo dosaženo pomˇernˇesložitého výsledku. V dalším kroku bylo nutné provést identifikaci atribut ˚u. Zpravidla se postupuje tak, že dojde k nalezení podstatných informací, které je d ˚uležitéukládat v našem systému pro jed- notlivé tˇrídy. Po provedení toho procesu nad navrhovaným modulem projekt ˚ubylo vidˇet,že vˇetšinasamostatných tˇrídmá hodnˇepodobné vlastnosti. Uvedeny jsou zde nˇekteréz nich: 42 5.4. DIAGRAM TRÍDˇ Obrázek 5.7: Diagram tˇrídpro modul projektového ˇrízení • Projekt – nutné je ukládát název projektu, textový popis, vlastníka projektu, datum urˇcujícízaˇcátek,datum uzavˇrení,správce projektu a úˇcastníkyprojektu, podprojekty. D ˚uležitéje vést evidenci zmˇen. • Úkol – nutné je ukládát název úkolu, textový popis, datum urˇcujícízaˇcátek,datum uzavˇrení,úˇcastníkyúkolu, ˇcasovounároˇcnost,komentáˇre,podúkoly a stav plnˇení. I zde je podstatná evidence provedených zmˇenv ˇcase. • Rychlé poznámky – nutné je ukládát název poznámky, textový popis a stav plnˇení. Budoucí úpravy poˇcítajís tím, že by mˇelojít snadno z rychlých poznámek vytvoˇrit úkoly. • Kategorie – nutné je ukládát název kategorie a pˇriˇrazenéúkoly. Podstatná je i evi- dence jednotlivých zmˇenv ˇcase. Z toho d ˚uvodubyla struktura hlavních ˇcástímodulu projektového ˇrízenínavržena obec- nˇeji.Využívá spoleˇcnýchvlastností nalezených tˇríd.Výsledek byl zaznamenán za použití generalizace, což je druh vazby pˇredstavujícívztah mezi obecnou a specifiˇctˇejšítˇrídou.Spo- leˇcnévlastnosti vybraných tˇrídeviduji v obecnˇejšítˇrídˇe AbstractTask. Taková struktura systému umožní v budoucnu napsat napˇríkladskripty pro kvalitnˇejšía univerzálnˇejšífil- trování. Všechny podstatné údaje jsou totiž uloženy v jedné hlavní tabulce. Vyhledávání 43 5.4. DIAGRAM TRÍDˇ pak v podstatˇeznamená jen procházení takto vytvoˇrenéstruktury objekt ˚u.Na následujících ˇrádcíchbude vˇenovánapozornost detailnˇejšímupopisu navržené struktury. Trídaˇ AbstractTask Pro práci s d ˚uležitýmiobjekty projektového ˇrízeníbyla vytvoˇrena tˇrída AbstractTask, urˇcujícímetody a atributy, které budou obsaženy v jednotli- vých podtˇrídách.Uloženy jsou zde právˇevšechny spoleˇcnévlastnosti jako napˇríklad název, popis, datum zaˇcátkuˇcidatum uzavˇrení.Jak lze vidˇetna diagramu, obsahuje tato tˇrídavazby sama na sebe. Tímto jsou zaznamenány situace, kdy má jeden úkol pˇriˇrazenyr ˚uznépodúkoly. D ˚uležitouvlastností je také evidence jednotlivých zmˇen v ˇcase.Toto je provádˇenopodle popsaného schématu uvedeného v jedné z pˇredcho- zích kapitol. Pro jednoduchost nejsou tˇrídypro zaznamenávání historie vyznaˇceny v našem diagramu. Trídaˇ AbstractCategory a príslušnéˇ podtrídyˇ Další ˇcástnaší hlavní abstraktní tˇrídypˇredstavujepodtˇrída AbstractCategory. Ta se pak dˇelína další podtˇrídy, a to na Project a SimpleCategory. A proˇcje zrovna pojmenovaná jako abstraktní kategorie? Pˇredmˇetemzájmu pro náš modul jsou zejména úkoly. Ty mohou být za- ˇrazenyaž v nˇekolikaprojektech. Projekt ˚umjsou dále pˇriˇrazoványhodnoty jednotli- vých kategorií (urˇcitápriorita, fáze, stav projektu). Z toho d ˚uvodujsou považovány jak projekty, tak hodnoty kategorií za jakési „kategorizaˇcníjednotky“ a jejich spoleˇcné vlastnosti sdružuje právˇetˇrída AbstractCategory. Jednu ˇcástpˇredstavujetˇrída Project. Ta poskytuje vývojáˇrivšechny potˇrebnéme- tody pro správné ukládání potˇrebnýchinformací. Pomocí vhodnˇedefinovaných vali- dací se pˇredejdepˇrípadnýmnekonzistencím v datech. Každý projekt navíc vlastní je- dineˇcnýtextový identifikátor, který slouží k budoucímu generování odkaz ˚u.Validace se opˇetpostarají o to, aby neexistovaly v systému dva projekty se stejným identifiká- torem. Díky tˇrídˇe ParentCategory a pˇríslušnýmvazbám je možné naše projekty seˇraditdo libovolné hierarchie. Druhou ˇcástpˇredstavujetˇrída SimpleCategory. Jak již bylo uvedeno, slouží tato tˇrídapro nadefinování hodnot vlastních kategorií, do kterých se pak v aplikaci bu- dou pˇriˇrazovatnaše projekty a úkoly. Stejnˇejako tomu bylo u projekt ˚u,tak i zde lze jednotlivé kategorie seˇraditdo libovolné hierarchie. K vytvoˇrenípˇríslušnýchvazeb se použije opˇettˇrída ParentCategory. Trídaˇ Task a príslušnéˇ podtrídyˇ Další podtˇrídouabstraktní tˇrídy AbstractTask je Task. Sdružuje další dvˇepodtˇrídy– SimpleTask a ToDoTask. Obˇepodtˇrídymají k sobˇepomˇernˇeblízko a do budoucna se plánuje z pˇrípadnýchrychlých poznámek (ToDoTask) vytváˇretúkoly. Historie se zde eviduje díky nadtˇrídˇe AbstractTask, kde je tato funkcionalita implementována. 44 5.4. DIAGRAM TRÍDˇ Podtˇrída SimpleTask pˇredstavujebˇežnýúkol v našem systému. Poskytuje všechny d ˚uležitémetody pro práci s pˇríslušnýmidaty. Pomocí validací se kontroluje, zda je úkol neustále navázán bud’ na jiný rodiˇcovskýúkol, a nebo zaˇrazendo nˇekterého projektu. Protože je dovoleno pˇriˇrazovatúkoly i projekty do libovolné struktury, ob- sahuje tˇrídapotˇrebnémetody zabraˇnujícívzniku pˇrípadnýchcykl ˚u.O pˇriˇrazenípod- projekt ˚use starají vazby tˇrídy AbstractClass. Protože je ˇcastopotˇrebaevidovat pouze krátké textové poznámky k jednotlivým úko- l ˚um,vznikla z tohoto d ˚uvodutˇrída ToDoTask, která nám dovoluje data tohoto typu ukládat. Díky tˇrídˇe ParentCategory je možné pˇriˇraditpoznámky k jednotlivým úkol ˚um. Trídaˇ ParentCategory ParentCategory dovoluje vývojáˇrievidovat vazby Projekt- Podprojekt, Kategorie-Podkategorie nebo Kategorie-Projekt. Tyto vazby nejsou v di- agramu vyznaˇcenypouze jednoduchým spojením, protože je ˇcastonutné evidovat i historii tˇechtovztah ˚u.Tˇrída ParentCategory má atributy, které nesou informaci o platnosti jednotlivých snímk ˚u,a poskytuje metody pro snadnou práci s tˇemitodaty. Pˇridávánítakovýchto vazeb m ˚užezp ˚usobitvznik nechtˇenýchcyklických graf ˚u.Aby se tomuto zamezilo, obsahuje tato tˇrídai všechny potˇrebnévalidace. Trídaˇ Work Work pˇredstavujetˇríduobstarávající vykazování odpracovaného ˇcasuna jed- notlivých úkolech. Casˇ je ukložen do databáze v minutách, avšak tˇrídaposkytuje me- tody pro pˇrevodˇcasovýchúdaj ˚una hodiny. Pomocí validací je možné zajistit, že ne- budou do systému uložena nesmyslná data. Trídaˇ AbstractCategoryClass a príslušnéˇ podtrídyˇ V systému je umožnˇeno evidovat r ˚uznédruhy kategorií. Naší kategorizaˇcníjednotkou tak m ˚užebýt projekt nebo jiné uživatelem definované kategorie. Tˇrída AbstractCategoryClass posky- tuje rozhraní pro práci s kategoriemi. Zde si lze nadefinovat, že instancí této tˇrídy bude napˇríkladpriorita projektu. Objekty tˇrídy SimpleCategory pak jen urˇcují,ja- kých hodnot nabývá priorita (normální, kritická, urgentní). Aby bylo možné zadefi- novat poˇradí,v jakém se budou jednotlivé kategorie vypisovat ve formuláˇriaplikace, eviduje se u každého záznamu i jeho poˇradové ˇcíslo.Tˇrídaposkytuje metody pro snadnou zmˇenutohoto poˇradí. 45 Kapitola 6 Rozhraní pro práci se systémem Pˇribudování každého nového systému je nutné vždy pamatovat na uživatelskou pˇrívˇeti- vost a snadnost použití. Naše aplikace m ˚užebýt dokonalá po stránce nabízených funkcí, ale pokud nebude uživatel schopný tyto funkce jednoduše využívat, ztratí rychle o používání tohoto systému zájem. Na následujících ˇrádcíchbude pˇredstaveno,jakým zp ˚usobemje ˇre- šena právˇezmiˇnovanáuživatelská pˇrívˇetivostv budovaném systému. Design, který uvidíte na zobrazených náhledech, není ještˇedokonˇcena jeho finální podoba také velikou mˇerou pˇrispˇejek lepší orientaci v aplikaci. 6.1 Navigace Protože náš systém bude v budoucnu obsahovat až nˇekolikmodul ˚ua každý modul se zvlášt’ dˇelína jednotlivé ˇcásti,hraje velikou roli v orientaci vhodnˇezvolené menu. Odkazy pro hlavní navigaci jsou rozdˇelenydo tˇechtotˇríˇcástí: • menu nabídka pro výbˇermodulu • menu nabídka pro výbˇersekce v zobrazeném modulu • postranní menu nabídka s výbˇerem specifických akcí Náhled aplikace 6.1 ukazuje všechny tˇridruhy menu, se kterými se lze setkat pˇripráci se systémem. Hlavní menu se nachází v horní ˇcástiobrazovky. Slouží pro vstup do jednotlivých mo- dul ˚u.Když se rozhodneme v budoucnu pˇridatdo systému nový modul, doplníme sem i pˇríslušnýodkaz. V souˇcasnédobˇetak m ˚užemevstoupit do modulu CRM, modulu projek- tového ˇrízenía modulu pro systémová nastavení. Každý modul poskytuje zpravidla veliké množství funkcí. Kv ˚ulipˇrehlednostise vˇetši- nou dˇelíi na další sekce. Vstupy do jednotlivých sekcí v zobrazeném modulu jsou vypsány pomocí dalšího systémového menu. Vˇedˇetco nejrychleji, kde se tyto odkazy nacházejí, je pro uživatele aplikace velice d ˚uležité.Z toho d ˚uvoduje menu umístˇenohned pod název naší aplikace. Na obrázku lze vidˇetmenu pro jednotlivé sekce v modulu CRM. Je tak možné zobrazit pˇrehledCRM, správu uživatel ˚u,správu subjekt ˚u,události v systému, skupiny nebo uložené zprávy. Obdobnˇetomu tak je i v ostatních modulech. 46 6.2. DYNAMICKÉ STRÁNKY Obrázek 6.1: Náhled na seznam projekt ˚u Poslední druh menu slouží pouze k zobrazení odkaz ˚upro specifické akce v našem sys- tému. Jeho pozice na obrazovce není pro uživatele až tak d ˚uležitá.Avšak vhodným umístˇe- ním dokáže práci ˇcastousnadnit. Umístˇeníbylo vybráno do pravého sloupce stránky. Ne- jedná se však o stálé menu. Na mnoha místech aplikace je jeho použití zbyteˇcné,proto z ˚u- stane skryté. 6.2 Dynamické stránky V kapitole popisující webový framework Ruby on Rails se hovoˇriloo tom, že v tomto pro- stˇredíje implementována ˇradaužiteˇcnýchfunkcí pro snadné využití technologie AJAX. Hlavní výhodou je odstranˇenínutnosti naˇcítatcelou stránku pokaždé, když uživatel pro- vede nˇejakouakci. Pokud se této vlastnosti vhodnˇevyužije, docílí se tím snížení zátˇeže webového serveru. Typickým pˇríklademm ˚užebýt situace, kdy chceme stisknutím jednoho tlaˇcítkaschválit mˇestov databázi systému. Pokud bychom nepoužívali AJAX, odešleme náš požadavek na server a zde se stránka musí znovu celá zpracovat, tˇrebažezbytek údaj ˚una ní z ˚ustávánezmˇenˇen.Bˇežnˇeby staˇcilozpracovat pouze zmˇenustavu vybraného mˇestaa nenaˇcítatzbyteˇcnˇevšechny údaje. Prostˇrednictvímtechnologie AJAX se zpracuje na pozadí zmˇenastavu mˇesta,server pošle zpˇetjen tu ˇcáststránky, která se zmˇenila,a jen tato ˇcást se na stránce aktualizuje a pˇrekreslí. Uživatel tak má pocit vˇetšíplynulosti práce. I náš sys- tém je doplnˇeno prvky využívající AJAX. Ukázáno zde bude nˇekolikpˇríklad˚u,které mají uživatel ˚umzpˇríjemnita zároveˇnzefektivnit samotnou práci s aplikaci. Zp ˚usobzpracování požadavk ˚upomocí technologie AJAX je sice výhodou, avšak m ˚uže pˇrinéstjednu velice nepˇríjemnouvlastnost. Protože komunikace probíhá na pozadí, je nutné 47 6.2. DYNAMICKÉ STRÁNKY uživateli nedokonˇcenéoperace nˇejakýmzp ˚usobemsignalizovat. Pokud by tomu tak nebylo, tak v pˇrípadˇepomalejšího internetové pˇripojení,kde jsou delší veškeré odezvy, uživatel ni- jak nezjistí, zda se jeho požadavek stále provádí nebo zda se dokonˇcil.Pro tyto potˇrebybyla pˇripravenametoda, která podobné pˇrípadydetekuje a zobrazí na popˇredístránky animaci signalizující pr ˚ubˇehkomunikace. Protože výpisy dat (napˇr.seznam uživatel ˚u,seznam subjekt ˚u)jsou použity na mnoha místech v systému, je jejich ovládání urychleno právˇeza pomoci AJAX. Na obrázku 6.1 lze vidˇettabulkový výpis evidovaných uživatel ˚u.Pˇrikaždé zmˇenˇenepˇrekreslujeme znova celou stránku, ale pouze naši tabulku se zobrazenými daty. Zde je technologie AJAX použita na: • filtrování • stránkování • ˇrazení • ˇrádekv tabulce po kliknutí zobrazí detailní informace • odstraˇnovánízáznam ˚u Pˇredstavmesi situaci, kdy máme v databázi dva tisíce subjekt ˚ua rozhodneme se pˇridat novou událost. Pro vytvoˇrení takového záznamu je nutné ve formuláˇrinejprve vybrat sub- jekt, který má roli poˇradatele.Vypisovat nabídku s tolika subjekty v systému není zrovna praktické. Dohledat mezi nimi jeden konkrétní záznam už nelze tak snadno, jako kdyby jich bylo pouze padesát. Pomocí nástroj ˚uframeworku Ruby on Rails a technologie AJAX do- cílíme efektivního dohledávání, které probˇehneaž v momentˇe,kdy potˇrebujemeskuteˇcnˇe najít požadovaný údaj. Ukázku lze vidˇetna obrázku 6.2. Obrázek 6.2: Dohledávání záznam ˚uza použití technologie AJAX 48 6.3. NÁPOVEDAˇ Zp ˚usob˚u,jakými je využito technologie AJAX ke zpˇríjemnˇeníovládání a zlepšení vlast- ností celého systému, je samozˇrejmˇevíce. Pro pˇrehledjsou zde uvedeny ještˇenˇekteréz nich: • zobrazení formuláˇrepro rychlé zadání nebo editaci záznamu • hromadné akce pro správu dat • dohledávání údaj ˚uv registru ekonomických subjekt ˚uARES • rychlá zmˇenastavu záznamu jedním kliknutím 6.3 Nápovˇeda Protože do systému budou pˇristupovati uživatelé, kteˇrínejsou pˇrílišobeznámeni s poskyto- vanými funkcemi a možnostmi aplikace, bylo nutné vymyslet zp ˚usob,jak pˇredejítmožným nejasnostem. Typickým pˇríklademje zadávání údaj ˚udo formuláˇr˚u. Castoˇ se nám stane, že nevíme, v jakém tvaru napsat hodnoty do položky formuláˇre.Pˇrivývoji byla snaha tomu zamezit, a proto jsou na ˇradˇemíst nabízeny možnosti zobrazení vyskakovací nápovˇedy. S použitím pluginu rails_widgets1 to jde velmi snadno. Pˇríkladlze vidˇetna obrázku 6.3. Obrázek 6.3: Nápovˇedapro položky formuláˇre 1. http://wiki.github.com/paolodona/rails-widgets 49 6.4. OPTIMALIZACE PRO INTERNETOVÉ PROHLÍŽECEˇ 6.4 Optimalizace pro internetové prohlížeˇce Pˇrestožeaplikace nemá plnˇedokonˇcenýdesign, nic nebránilo pˇripravitzdrojový kód opti- malizovaný pro vˇetšinubˇežnýchinternetových prohlížeˇc˚u.Nutnou podmínkou bylo, aby se systém zobrazil všude stejnˇe.Proto byly provedeny pˇríslušnéúpravy v generovaném HTML kódu a použitých kaskádových stylech. Zobrazení bylo otestováno pro tyto nejzná- mˇejšíprohlížeˇce: • Internet Explorer 6, Internet Explorer 7 • Firefox 3 • Opera 9 50 Kapitola 7 Implementace 7.1 Nasazení systému Diagram nasazení je typem diagramu urˇcenéhopro implementaˇcnífáze. Jeho úkolem je pˇredevšímzobrazit vztahy mezi ˇcástmisystému tak, jak vypadají v dobˇesamotného vyko- návání. Diagramy nasazení zobrazují napˇríkladrozložení jednotlivých softwarových kom- ponent na hardwarových zdrojích a jejich spolupráci, rozmístˇeníhardwarových a softwaro- vých prostˇredk˚uv lokalitách, topologie používaných sítí ˇcidruhy a využití komunikaˇcních prostˇredku. Obrázek 7.1: Diagram nasazení systému Obrázek 7.1 znázorˇnujezákladní hardwarové a softwarové komponenty a jejich pro- pojení. Náš systém, který obsahuje všechny navržené moduly, je oznaˇcenjako samostatná komponenta s názvem Administraˇcnísystém. Nasazen je na stejné stanici jako webový ser- ver. 51 7.2. WEBOVÝ SERVER Velkou roli v systému hraje i emailová komunikace. Ta je v diagramu vyznaˇcenajako komponenta SMTP. SMTP server slouží k odesílání veškeré elektronické pošty. Tuto službu však nebude využívat pouze náš administraˇcnísystém, ale potenciálnˇek ní mohou pˇri- stupovat všichni zákazníci spoleˇcnosti.Protože takové komunikace m ˚užeprobíhat velice mnoho, bˇežíkv ˚ulivˇetšíefektivitˇetato služba na jiném serveru. Další komponentou, se kterou systém komunikuje pˇrisvém provozu, je SMS brána. Spo- leˇcnostji používá k rozesílání krátkých textových zpráv. Umístˇenaje na jiné stanici než hlavní aplikace. Aby bylo možné z naší aplikace pˇristupovatk této bránˇe,je implemento- váno jednoduché rozhraní v prostˇredíRuby on Rails, které rozesílání zpráv snadno umožní. Diagram dále obsahuje vzdálenou komponentu ARES, se kterou aplikace komunikuje v pˇrípadech,kdy potˇrebujemedohledat informace o ekonomických subjektech registrova- ných v Ceskéˇ republice. Nasazena je na nˇekterémze server ˚uMinisterstva financí a my k ní pˇristupujemepomocí definovaného API. Nutným prvkem pro provoz našich modul ˚uje relaˇcnídatabáze. Zde však není pod- mínkou, aby byla umístˇenana stejné stanici. Z hlediska lepšího výkonu a možností vˇetších optimalizací je vhodnˇejšímít databázový server a webový server oddˇelený. 7.2 Webový server Svˇetovˇenejrozšíˇrenˇejšímˇrešením pro Ruby on Rails systémy je server WEBrick1. Jedná se o knihovnu, která je distribuována jako souˇcástsamotného Ruby. Pro vývoj byl však zvolen jiný webový server, a to produkt Mongrel verze 1.1.42. I zde se jedná o open-source HTTP knihovnu a webový server pro aplikace napsané v jazyce Ruby. Navíc se jedná o server, který je více stabilnˇejšía rychlejší než samotný WEBrick. Pˇriostrém provozu se od webového serveru Mongrel upustilo a místo toho se pˇristoupilo k jiné alternativˇe,se kterou se dosahuje lepších výsledk ˚u.Mezi jednu z oblíbených konfigu- rací patˇrípoužití Phusion Passenger3 ve spojení s Ruby Enterprise Edition4. Phusion Passen- ger je modul pro Apache HTTP Server, známý také pod názvy mod_rails nebo mod_rack. Umožˇnujesnadné nasazení webových aplikací napsaných v prostˇredíRuby on Rails. Rídíˇ se hlavnˇebˇežnýmikonvencemi tohoto frameworku, které ˇríkají:„Neopakujte zbyteˇcnˇesvoji ˇcinnost“.Ruby Enterprise Edition je serverovˇe-orientovanávˇetevjazyka Ruby, která je plnˇe kompatibilní s oficiálním Ruby interpretem verze 1.8.6. V této kombinaci lze docílit násle- dujících vlastností: • Nasazení je pouze otázkou nahrání aplikaˇcníchsoubor ˚u.Není nutná žádná další spe- ciální Ruby ˇciRuby on Rails konfigurace na serveru. • Aplikace napsané v prostˇredíframeworku Ruby on Rails, které jsou sestavené v ta- kovéto konfiguraci, využívají až o 33% ménˇepamˇeti. 1. http://www.webrick.org/ 2. http://mongrel.rubyforge.org/ 3. http://www.modrails.com/ 4. http://www.rubyenterpriseedition.com/ 52 7.3. DATABÁZOVÝ SERVER • Není potˇrebažádných prostˇredk˚upro údržbu. Žádná správa port ˚u,monitorování proces ˚una serveru nebo mazání starých soubor ˚u.Pokud je to možné, jsou chyby automaticky odstranˇeny. • Jedná se o nástroje, které jsou speciálnˇenavržené pro výkon, stabilitu a bezpeˇcnost. Phusion Passenger by nikdy nemˇelzp ˚usobitpád Apache v pˇrípadˇe,že dojde k pádu Rails aplikace. • Dobrá dokumentace, jak pro systémové administrátory, tak pro vývojáˇre. 7.3 Databázový server Pˇrivývoji systému byl použit databázový server MySQL (My Structured Query Language), který se stal v souˇcasnédobˇemezi bˇežnýmiuživateli jedním z nejpoužívanˇejších.Nedis- ponuje sice tolika funkcemi jako nˇekterékonkurenˇcnísystémy, ale zato se jedná o pomˇernˇe rychlou databázi bohatˇepostaˇcujícípro bˇežnéprojekty. Pro správný chod je však nutné, aby byl nainstalován i s podporou tabulek typu INNO DB, které umožˇnujíimplementovat data- bázi i s požadovaným integritním omezením. K vývoji a odladˇenísystému byl použít sever verze 5.0.67. Pro ostrý provoz aplikace byl zvolen databázový server firmy IglooNET, s.r.o., který bˇežíve verzi 5.0.51. Jednou z velikých výhod všech aplikací napsaných v prostˇredíRuby on Rails je prin- cip práce s daty. Není nutné psát SQL dotazy pro konkrétní použitou databázi. V Ruby on Rails pracujeme pouze s objekty. Princip Object-relational mapping nám zajistí, že když se v budoucnosti rozhodneme pro použití jiné databáze, bude nám staˇcitupravit jen pˇríslušné konfiguraˇcnísoubory. SpoleˇcnostIglooNET, s.r.o. používá pro své aplikace také databázi PostgreSQL. Pro náš systém však nebylo toto ˇrešenípoužito. Její budoucí využití by však nemˇelobýt problémem. Kompatibilita byla otestována na verzi PostgreSQL 8.1.13. 7.4 Programovací jazyk V kapitole 3 se hovoˇriloo tom, že systém je vyvíjen v prostˇredíprogramovacího jazyka Ruby a s využitím frameworku Ruby on Rails. Mezi vývojáˇriinternetových aplikací se tento ná- stroj tˇešíposlední dobou veliké oblibˇe.Nem ˚užemese tak divit, že dochází pomˇernˇeˇcasto k jeho úpravám. Vˇetšinouse jedná o opravy zjištˇenýchchyb, nˇekteréaktualizace však pˇri- nášejí i nové zajímavé funkce. Bˇehemtémˇeˇrsedmi mˇesíc˚uprací na tomto projektu došlo k nˇekolikavýznamným aktualizacím. Mezi jednu z nejvýznamnˇejšíchpatˇríimplementace nástroj ˚upro psaní vícejazyˇcnýchaplikací v Ruby on Rails od verze 2.2. Dˇrívebylo možné podobné aplikace také vyvíjet, ale pouze s pomocí speciálního pluginu. V pr ˚ubˇehuvývoje se postupnˇeupustilo od nutnosti používat pluginy pro podporu lokalizace, a celý kód byl upraven, aby byl kompatibilní s funkcemi verze 2.2. 53 7.4. PROGRAMOVACÍ JAZYK V souˇcasnédobˇeje aplikace vyvíjena v programovacím jazyku Ruby verze 1.8.7 a s po- užitým frameworkem Ruby on Rails verze 2.3.2. Pro usnadnˇenípráce je používáno nˇekolik zajímavých plugin ˚u.Mezi nˇekteréz nich patˇrí: • actions_sms_sender – Nástroj sloužící k rozesílání krátkých textových zpráv pˇresSMS bránu firmy IglooNET, s.r.o. • acts_as_list – Toto rozšíˇreníposkytuje možnosti ˇrazeníobjekt ˚udo seznamu. Tˇrída, na kterou je tento nástroj aplikovaný, musí mít definovaný atribut position. Každá instance této tˇrídymá pak svoje poˇradí.Pomocí vhodných metod jim lze upravovat pozici v seznamu. • attachment_fu – Aby nebylo nutné psát vlastní metody pro správu souboru v sys- tému, byl použit tento plugin. S jeho pomocí je možné ukládat soubory, pˇristupovat k nim a generovat odkazy pro jejich stažení. • auto_complete – Nástroj pro snadnˇejšívyhledávání. S jeho pomocí je možné vyhledá- vat v datech až v pˇrípadˇezadávání požadovaného výrazu. Jeho použití lze vidˇetna obrázku 6.2. • awesome_nested_set – Tento plugin dovoluje ˇraditvybrané záznamy v databázi do stromové struktury a poskytuje ˇraduužiteˇcnýchmetod pro jejich správu. • hit – Tento nástroj umožˇnujepˇrevádˇettextové soubory se zápisy HIT-atribut ˚una nové migrace a pˇríslušnémodely. • rails_widgets – Tento plugin pˇredstavujekolekci nástroj ˚u,které pomohou vylepšit grafické rozhraní naší aplikace. Snadno tak programátor vytvoˇrívyskakovací nápo- vˇedu,rámeˇckys kulatými rohy nebo indikátor pr ˚ubˇehu(progressbar). • searchlogic – Nástroj, který usnadˇnujehledání v uložených datech. Dokáže tak po- mocí nˇekolikajednoduchých pˇríkaz˚uvytvoˇritfiltrování, stránkování nebo zmˇenitˇra- zení zobrazených údaj ˚u.Implementována je i podpora technologie AJAX. 54 Kapitola 8 Závˇer Cílem této diplomové práce bylo pˇredevšímspecifikovat a namodelovat systém pro správu uživatelských požadavk ˚ua ˇrízeníúloh. V prvé ˇradˇebylo nutné prostudovat souˇcasnéná- stroje a zjistit, které funkce jsou vhodné i pro naše potˇreby. Dalo se tak pouˇcitz pˇredchozích chyb, které byly v tˇechtoaplikacích zaneseny. Výsledný modul musel navíc od zaˇcátkuspl- ˇnovatpožadavky firmy IglooNET, s.r.o. Tˇemise detailnˇejizabývala kapitola 2.4. Protože se jedná o aplikaci, která se plánuje v budoucnu nadále vyvíjet a rozr ˚ustat,bylo nutné klást veliký d ˚urazna návrh databázového schématu. K tomuto úˇceluse použilo ne- tradiˇcníhopˇrístupua databázové schéma bylo modelováno pomocí metody HIT. Pro sa- motnou realizaci byl pak zvolen webový framework Ruby on Rails, který poskytuje celou ˇraduužiteˇcnýchnástroj ˚u.Díky tomu odpadla nutnost zdlouhavˇeˇrešitbˇežnéprogramátor- ské úkony a pˇrivývoji se mohlo soustˇreditna samotné zadání práce. Ve výsledku se poda- ˇrilonavrhnout a implementovat aplikaci, která obsahuje dva základní moduly. Pro správu uživatel ˚u,kteˇríbudou pˇristupovatdo systému, byl vytvoˇrenmodul CRM. Tato ˇcástpˇred- stavuje základ celé aplikace. Hlavní cíle diplomové práce jsou pak shrnuty v druhé ˇcásti, a to v modulu pro projektové ˇrízení.V kapitole 5 je pˇrehlednýseznam poskytovaných funkcí a rozebrány jsou nˇekteréd ˚uležitéprvky struktury systému. Aplikaci se již podaˇrilonasadit do ostrého provozu. Teprve ten odhalil ˇraduskrytých problém ˚u,které se projevily až pˇrivˇetšímobjemu dat. Tyto chyby si vyžádaly ˇraduopti- malizací. Modulárnˇenavržené prostˇredíse ukázalo jako obrovská výhoda pˇriposkytování systému dalším zákazník ˚um.Pro nˇebyly úspˇešnˇenavrženy a implementovány další mo- duly. Vyzkoušelo se tak, že systém lze jednoduše rozšiˇrovatpodle potˇrebzákazník ˚u. Samotný modul projektového ˇrízeníse do budoucna plánuje rozšiˇrovato ˇraduužiteˇc- ných funkcí. S rostoucí nabídkou nových nástroj ˚ubude aplikace schopna více konkurovat souˇcasnýmsystém ˚umna trhu. Zatím jsou implementovány základní služby, které snadno umožní spravovat jednotlivé projekty a úkoly. Plánováno je rozšíˇrenínapˇríklado zakládání nových úkol ˚uprostˇrednictvímemailových zpráv, integraci se systémy pro správu verzí sou- bor ˚u,zobrazování Ganttova diagramu nebo umožnˇenízakládání wiki stránek k jednotlivým projekt ˚um. 55 PˇrílohaA Obsah pˇriloženéhoCD Souˇcástítéto práce je i pˇriloženéCD, na kterém lze nalézt: • zdrojový kód diplomové práce ve formátu xml • diplomová práce ve formátu pdf • zdrojové kódy vytvoˇrenýchmodul ˚u 56 PˇrílohaB HIT-model popisující strukturu modulu projektového ˇrízení d :from, ’od casu’,ˇ :datetime d :to, ’do casu’,ˇ :datetime d :created_at, ’vytvorenoˇ v’, :datetime d :name, ’jméno’, :string d :description, ’popis’, :text d :comment, ’komentár’,ˇ :description d :position, ’pozice v listu’, :integer d :start_date, ’zacátek’,ˇ :datetime d :due_date, ’datum uzavrení’,ˇ :datetime d :seo_url, ’SEO URL daného projektu’, :string d :hour_estimation, ’odhad hodin’, :float d :completed, ’dokoncenost’,ˇ :integer # 0..100% d :system, ’system flag, urcujeˇ systémovou kategorii’, :boolean d :uniq, ’jedna hodnota, povoluje TS jen jednu hodnotu’, :boolean d :inheritance, ’dediˇ cnost,ˇ dedíˇ potomci TS hodnoty CC’, :boolean d :minutes, ’minuty’, :integer d :worked_at, ’odpracováno’, :date, :child => true # ===== e :AbstractTask, ’abstractní úkol’ h ’Snímky úkolu’, :TaskSnap, ’daného abstraktního úkolu’, :AbstractTask, ’1M11’ h ’Abstractní úkol’, :AbstractTask, "byl vytvorenˇ v", :created_at, "0M01" h ’Autor’, :Person, ’daného abstraktního úkolu’, :AbstractTask, ’110M’, ’author’ e :Task, :AbstractTask, ’úkol’ e :SimpleTask, :Task, ’prostý úkol’ e :ToDoTask, :Task, ’todo’ h ’Rodicovskéˇ úkoly’, :Task, ’daného úkolu’, :Task, ’0M0M’, [’parent’, ’child’] e :AbstractCategory, :AbstractTask, ’Categorie’ h ’Pod kategorie’, :AbstractCategory, ’nekdyˇ patrícíˇ do dané kategorie’, 57 B. HIT-MODELPOPISUJÍCÍSTRUKTURUMODULUPROJEKTOVÉHO RÍZEN͡ :AbstractCategory, ’0M0M’, :ParentCategory, ’Nadrízenᡠkategorie’, [’child’, ’parent’] h ’Nadrízenᡠkategorie’, :ParentCategory, ’platí od’, :from, ’0M11’ h ’Nadrízenᡠkategorie’, :ParentCategory, ’platí do’, :to, ’0M01’ h ’V které trídˇ eˇ kategorií’, :AbstractCategoryClass, ’daná kategorie trídí’,ˇ :AbstractCategory, ’110M’ e :SimpleCategory, :AbstractCategory, ’prostá kategorie’ e :Project, :AbstractCategory, ’projekt’ h ’Používané trídyˇ kategorií’, :SimpleCategoryClass, ’deného projektu’, :Project, ’0M0M’ # ===== e :AbstractTaskSnap, ’snímek abstraktního úkolu’ h ’Autor’, :Person, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’110M’, ’author’ h ’Jméno’, :name, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’010M’ h ’Popis’, :description, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’010M’ h ’Odhad hodin’, :hour_estimation, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’010M’ # pokud null skládá se z potomk˚u h ’Zacátek’,ˇ :start_date, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’010M’ h ’Datum uzavrení’,ˇ :due_date, ’daného snímku abstraktního úkolu’, :AbstractTaskSnap, ’010M’ h ’Snímek abstraktního úkolu’, :AbstractTaskSnap, ’je platný od data’, :from, ’0M11’ h ’Snímek abstraktního úkolu’, :AbstractTaskSnap, ’je platný do data’, :to, ’0M01’ h ’Snimek abstractní úkol’, :AbstractTaskSnap, "byl vytvorenˇ v", :created_at, "0M01" e :TaskSnap, :AbstractTaskSnap, ’snímek úkolu’ h ’Je dokoncený’,ˇ :completed, ’daný snímek úkolu’, :TaskSnap, ’010M’ h ’Komentárˇ k verzi/zmenˇ e’,ˇ :comment, ’daného snímku úkolu’, :TaskSnap, ’010M’ e :SimpleTaskSnap, :TaskSnap, ’prostý úkol’ h ’Kategorie’, :AbstractCategory, ’, do kterých daný snímek prostého úkolu patrí’,ˇ :SimpleTaskSnap, ’0M0M’ 58 B. HIT-MODELPOPISUJÍCÍSTRUKTURUMODULUPROJEKTOVÉHO RÍZEN͡ e :ToDoSnap, :TaskSnap, ’todo’ e :CategorySnap, :AbstractTaskSnap, ’Snímek Kategorie’ e :ProjectSnap, :CategorySnap, ’snímek projektu’ h ’Subjekt’, :Subject, ’, který daný projekt vlastní’, :ProjectSnap, ’110M’ h ’Subjekt’, :Subject, ’, pro který je daný projekt vypracováván’, :ProjectSnap, ’110M’, ’customer_id’ h ’SEO URL’, :seo_url, ’daného projektu’, :ProjectSnap, ’010M’ e :SimpleCategorySnap, :CategorySnap, ’snímek prosté kategorie’ # ===== e :AbstractCategoryClass, ’trídaˇ categorií, napr:ˇ Prioryta, Modul, Tag, Typ(chyba, požadavek, zlepšení), apod.’ h ’Autor’, :Person, ’daného trídyˇ kategorií’, :AbstractCategoryClass, ’110M’, ’author’ h ’Snímky trídyˇ kategorií’, :AbstractCategoryClassSnap, ’dané trídyˇ kategorií’, :AbstractCategoryClass, ’1M11’ h ’Pozice’, :position, ’dané trídyˇ categorií’, :AbstractCategoryClass, ’1101’ # pozice fo formuláriˇ pro výberˇ h ’System flag’, :system, ’dané trídyˇ categorií’, :AbstractCategoryClass, ’110M’ h ’Jedna hodnota’, :uniq, ’dané trídyˇ categorií’, :AbstractCategoryClass, ’110M’ h ’Dediˇ cnost’,ˇ :inheritance, ’dané trídyˇ categorií’, :AbstractCategoryClass, ’110M’ h ’Trida kategorii’, :AbstractCategoryClass, "byla vytvorenaˇ v", :created_at, "0M01" e :SimpleCategoryClass, :AbstractCategoryClass, ’trídaˇ prostých categorií’ h ’výchozí hodnota’, :AbstractCategory, ’dané kategorie’, :SimpleCategoryClass, ’010M’, ’default_id’ e :ProjectCategoryClass, :AbstractCategoryClass, ’trídaˇ prostých categorií’ # ===== e :AbstractCategoryClassSnap, ’snímek trídyˇ kategorií’ h ’Autor’, :Person, ’daného snímku trídyˇ kategorií’, :AbstractCategoryClassSnap, ’110M’, ’author’ 59 B. HIT-MODELPOPISUJÍCÍSTRUKTURUMODULUPROJEKTOVÉHO RÍZEN͡ h ’jméno’, :name, ’daného snímku kategorie’, :AbstractCategoryClassSnap, ’110M’ h ’popis’, :description, ’daného snímku kategorie’, :AbstractCategoryClassSnap, ’010M’ h ’Snímek tridy kategorie’, :AbstractCategoryClassSnap, ’jsou platné od data’, :from, ’0M11’ h ’Snímek tridy kategorie’, :AbstractCategoryClassSnap, ’jsou platné do data’, :to, ’0M01’ h ’Snimek trida kategorie’, :AbstractCategoryClassSnap, "byl vytvorenˇ v", :created_at, ’0M01’ # ===== e :Work, ’práce’ h ’Úkol’, :Task, ’, na kterém se daná práce provedla’, :Work, ’110M’ h ’Osoba’, :Person, ’, která odpracovala danou práci’, :Work, ’110M’ h ’Autor’, :Person, ’dané provedené práce’, :Work, ’110M’, ’author’ h ’Editor’, :Person, ’dané provedené práce’, :Work, ’110M’, ’editor’ h ’Pocetˇ minut’, :minutes, ’dané práce’, :Work, ’110M’ h ’Daná práce’, :Work, ’odpracována dne’, :worked_at, ’0M11’ h ’Komentár’,ˇ :comment, ’dané práce’, :Work, ’010M’ h ’Prace’, :Work, ’byl vytvorenˇ v’, :created_at, ’0M01’ h ’Prace’, :Work, ’byl upraven v’, :updated_at, ’0M01’ 60 Literatura a odkazy Literatura [1] Kapsammer, E.: Comparison of Projectmanagement-Software, Johannes Kepler Uni- versität Linz, 2007, Linz. 2.2 [2] Beynon-Davies, P.: Database Systems, Houndmills, Basingstoke, 2004, UK: Palgrave. 4.1 [3] Duží, M.: Konceptuální modelování, datový model HIT, Slezská univerzita, 2000, Slezská univerzita. 4.1, 4.2, 4.2.1, 4.2.2 [4] Kanisová, H. a Müller, M.: UML srozumitelnˇe, Computer press, Brno, 2004, 80-251- 0231-9. [5] Pender, T.: UML Weekend Crash Course, Wiley publishing, New York, 2002, 0-7645- 4910-3. [6] Holzner, S.: Zaˇcínámeprogramovat v Ruby on Rails, Computer Press, kvˇeten2007, 978-80-251-1630-2. [7] Thomas, D. a Hansson, D.: Agile Web Development with Rails, The Pragmatic Progra- mmers LLC, prosinec 2005, 0-9766940-0-X. [8] Staníˇcek,Z.: Materiály k pˇrednáškámDatové modelování I, Masarykova univerzita, 2007, Brno. 4.2.1 [9] Staníˇcek,Z.: Universální modelování a konstrukce IS, Disertaˇcnípráce, 2003, Brno. 4.2.1 Odkazy [1] Microsoft: Kritická cesta, http://office.microsoft.com/cs-cz/project/ HP010404341029.aspx , 2009 [cit. 2009-01-26]. 2.1 [2] Ruby on Rails: Rails Internationalization (I18n) API, http://guides. rubyonrails.org/i18n.html , listopad 2008 [cit. 2009-02-22]. 3.3.5 [3] Pither, R. a Duncan, W.: Mezinárodní norma pro ˇrízeníjakosti projekt ˚uISO 10006, http://www.pmpartners.com/resources/iso10006.html , [cit. 2009-04-01]. 2.1 [4] Wikipedie: Definice UML, http://cs.wikipedia.org/wiki/UML , duben 2009 [cit. 2009-04-14]. 5 61 [5] Root.cz: Modelování databází, http://www.root.cz/clanky/ modelovani-databazi/ , duben 2002 [cit. 2009-03-19]. 4.1 [6] Wikipedie: Definice návrhového vzoru MVC, http://en.wikipedia.org/wiki/ Model-view-controller , kvˇeten2009 [cit. 2009-04-16]. 3.2 [7] Best Practice Software Engineering: Definice návrhového vzoru MVC, http://best-practice-software-engineering.ifs.tuwien.ac.at/ patterns/mvc.html , 2008 [cit. 2009-05-02]. [8] Database design resource: The Five Normal Forms - formal definitions, http://www. databasedesign-resource.com/normal-forms.html , 2008 [cit. 2009-04-21]. 4.2.2 [9] Wikipedie: List of project management software, http://en.wikipedia.org/ wiki/List_of_project_management_software , kvˇeten2009 [cit. 2009-04-18]. 2.2 [10] Project Management - Rízeníˇ projektu: Co je projekt a jaké má vlastnosti?, http:// rizeni-projektu.cz/view.php?cisloclanku=2005091201 , srpen 2005 [cit. 2009-03-28]. 2.1 [11] Na volné noze: Projektové ˇrízení, http://navolnenoze.cz/zpravy/ projektove-rizeni/ , leden 2007 [cit. 2009-03-11]. 2.1 [12] Ruby Programming Language: About Ruby, http://www.ruby-lang.org/ , 2009 [cit. 2009-02-23]. [13] Stewart, B.: An Interview with the Creator of Ruby, http://www. linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html , listopad 2001 [cit. 2009-02-28]. 3.1 [14] TIOBE Software BV: The Ruby Programming Language, http://www.tiobe.com/ index.php/paperinfo/tpci/Ruby.html , duben 2009 [cit. 2009-04-11]. 3.1.1 [15] Root.cz: Seriál Ruby on Rails, http://www.root.cz/serialy/ruby-on-rails/ , bˇrezen2006 [cit. 2009-03-01]. 3.3 [16] Ruby on Rails: Rails Wiki, http://wiki.rubyonrails.org/ , kvˇeten2009 [cit. 2009-02-15]. 62 Rejstˇrík AJAX, 7, 9, 20, 21, 47–49, 54 architektura MVC, 15 Basecamp, 7–9, 16 diagram nasazení, 51 diagram pˇrípad˚uužití, 30, 32 diagram tˇríd, 38–42, 44, 45 entitnˇe-ralaˇcnímodel, 23–25, 27 HIT model, 23–25, 27, 28, 38, 55 MySQL, 18, 53 PostgreSQL, 18, 53 projektové ˇrízení, 1–6, 9, 11, 29, 35, 42–44, 46, 55 Redmine, 9–11 Ruby on Rails, 7, 9–12, 15–17, 19–22, 27, 28, 47, 48, 52–55 The Track Project, 8 Tick, 8, 9 63
Webová Aplikace Pro Rízení Projekt ˚U a Správu Úloh
