ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce Administra ní rozhraní pro správu webhostingu Vlastimil Jinoch Vedoucí práce: Ing. Bure² Miroslav Ph.D. Studijní program: Otev ená informatika, Bakalá ský Obor: Softwarové systémy 23. kv tna 2012
iv
v Pod kování Na tomto míst bych cht l pod kovat vedoucímu mé práce Ing. Miroslavu Bure²ovi, Ph.D., který mi ochotn pomohl mnoha radami s vývojem aplikace. Dále bych cht l pod kovat své rodin za podporu p i studiu.
vi
vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne 23. 5. 2012.............................................................
viii
Abstract Bachelor thesis deals with design and implementation of web interface for managing web hostings. System allows to manage domains and services linked with web hosting. It allows administrators to manage users. Implementation of system is done using Ruby on Rails platform and using agile development methodologies Behaviour Driven Development. Abstrakt Bakalá ská práce se zabývá návrhem a implementací webového rozhraní pro správu webových hosting. Systém umoº uje správu domén a sluºeb spjatých s webovým hostováním. Administrátor m pak umoº uje spravovat uºivatele. Implementace systému je provedena pomocí platformy Ruby on Rails s vyuºitím agilní metodiky vývoje Behaviour Driven Development. ix
x
Obsah 1 Úvod 1 2 Popis problému, specikace cíle 3 2.1 Popis problému................................... 3 2.2 Existující e²ení................................... 4 2.2.1 cpanel.................................... 5 2.2.2 Webmin................................... 5 2.2.3 Kloxo.................................... 5 2.2.4 Zhodnocení................................. 5 3 Analýza a návrh e²ení 7 3.1 Systémové poºadavky............................... 7 3.1.1 Funk ní poºadavky............................. 7 3.1.2 Nefunk ní poºadavky............................ 9 3.2 P ípady uºití.................................... 10 3.2.1 Akté i.................................... 10 3.2.2 Nep ihlá²ený uºivatel............................ 10 3.2.2.1 Scéná : P ihlásit se........................ 10 3.2.2.2 Scéná : Zaslat si heslo...................... 11 3.2.3 P ihlá²ený uºivatel............................. 12 3.2.3.1 Scéná : Odhlásit se........................ 12 3.2.3.2 Scéná : Upravit uºivatelské údaje................ 13 3.2.4 Uºivatel vlastnící zákazníka........................ 13 3.2.4.1 Scéná : Úprava zákaznických údaj.............. 13 3.2.5 Uºivatel ve vztahu s hostingem...................... 14 3.2.5.1 Scéná e.............................. 14 3.2.6 Administrátor................................ 14 3.2.6.1 Scéná e.............................. 14 3.3 Datový model.................................... 17 3.3.1 Cron..................................... 17 3.3.2 Domain................................... 18 3.3.3 Hosting................................... 19 xi
xii OBSAH 4 Realizace 21 4.1 Pouºité technologie................................. 21 4.1.1 Ruby on Rails................................ 21 4.1.2 MongoDb.................................. 21 4.1.3 Mongoid................................... 22 4.1.4 Twitter Boostrap.............................. 22 4.1.5 Devise.................................... 22 4.1.6 Cucumber.................................. 22 4.1.7 Rspec.................................... 23 4.1.8 Behavior Driven Development....................... 23 4.2 Struktura aplikace................................. 23 4.2.1 MVC..................................... 23 4.2.2 Souborová struktura aplikace....................... 24 4.3 Ukázka implementace vybrané funkcionality................... 24 4.3.1 Vytvo ení scéná e.............................. 25 4.3.2 Vytvo ení testu............................... 26 4.3.3 Samotná implementace........................... 26 4.3.4 Shrnutí................................... 27 4.4 Model nasazení................................... 28 5 Testování 29 5.1 Unit testy...................................... 29 5.1.1 Pokrytí kódu................................ 29 5.2 Regresní testy.................................... 29 5.2.1 Pokrytí scéná............................... 30 6 Záv r 31 6.1 Moºná roz²í ení................................... 32 A Seznam pouºitých zkratek 35 B Instala ní p íru ka 37 B.1 Poºadavky...................................... 37 B.2 Instalace....................................... 37 C Obsah p iloºeného CD 39
Seznam obrázk 3.1 UseCase Diagram - Akté i systému........................ 10 3.2 UseCase Diagram - nep ihlá²ený uºivatel..................... 11 3.3 UseCase Diagram - p ihlá²ený uºivatel...................... 12 3.4 UseCase Diagram - uºivatel vlastnící zákazníka................. 13 3.5 UseCase Diagram - uºivatel ve vztahu s hostingem............... 15 3.6 UseCase Diagram - administrátor......................... 16 3.7 Datový model.................................... 18 4.1 Behavior Driven Development cyklus [1]..................... 24 4.2 Diagram nasazení.................................. 28 xiii
xiv SEZNAM OBRÁZK
Seznam tabulek 3.1 Entita Cron..................................... 17 3.2 Entita Domain................................... 19 3.3 Entita Hosting................................... 20 4.1 Souborová struktura systému........................... 25 C.1 Obsah p iloºeného CD............................... 39 xv
xvi SEZNAM TABULEK
Kapitola 1 Úvod Téma bakalá ské práce vzniklo, na základ ºádosti spole nosti Blueberry.cz Apps s.r.o. o vytvo ení nové verze webového rozhraní pro správu webových hosting. D vodem ºádosti byla zastaralost p vodního systému a jeho né p ili² vhodná architektura, která neumoº ovala zakomponovat nové funkce. Dal²í ºádostí na systém byla její implementace v platform Ruby on Rails 4.1.1, s nerela ní databázi Mongodb za pomoci moderní metodiky Behaviour Driven Development 4.1.8, která si klade za cíl d kladné testování systému. Tím p edcházet zbyte ným chybám a zajistit moºnost dal²ích úprav. Nedílnou sou ástí zadání byla moºnost snadné a rychlé orientace v systému a moºnost bezproblémové správy sluºeb spjatých s webovým hostingem. Systém má být rozd len pro dv uºivatelské role a to role administrátora, který smí p idávat jednotlivé uºivatele, servery, tarify, hostingy a k nim p ipojené domény. Druhou rolí má být uºivatel, který smí spravovat hostingy, které jsou k n mu p ipojeny a p idávat k jednotlivým doménám mysql databáze, subdomény, ftp ú ty, cron události, emailové schránky a aliasy. Bakalá ská práce zahrnuje pouze webové rozhraní hostingu, ale systém ke kterému mu bude následn p ipojena se skládá z proxy serveru, který provádí akce vykonávané ve webhostingu na konkrétních serverech. Tento dokument se skládá z n kolika kapitol, které popisují témata, nutná pro správné vypracování systému. Druhá kapitola popisuje specikaci problému z pohledu zadavatele, který se snaºí popsat funkcionalitu systému. Dále pak obsahuje existujicí e²ení. T etí kapitola zabývající se analýzou a návrhem e²ení. Popisuje poºadavky na systém z hlediska analytického a dává jim strukturovanou formu. Popisuje p ípady uºití na základ kterého vzniká doménový model. Následující tvrtá kapitola popisuje implementaci e²ení a pouºité technologie. Zde je pak ukázán postup jedné iterace p i tvorb za pomoci agilní metodiky BDD. Záv rem kapitoli je pak diagram nasazení. Pátá kapitola v novaná testování, popisuje druhy test v systému, jejich mnoºství a pokrytí kódu t mito testy. Záv re ná kapitola shrnuje celý systém a utvá í záv r bakalá ské práce a popisuje dal²í moºná roz²í ení. 1
2 KAPITOLA 1. ÚVOD
Kapitola 2 Popis problému, specikace cíle 2.1 Popis problému Bakalá ská práce e²í návrh a správu webového rozhraní pro webové hostingy, který by m la uºivateli a administrátoru umoºnit co nejsnaz²í moºnost, jak ovládat webové domény, webové hostingy a sluºby s nimi spjaté. Co v²e se ale této problematiky týká? Hosting je pouze abstrakní skupina, která se na ºádnem serveru nevytvá í. Je nutno, aby administrátor mohl vytvo it webový hosting. Tento hosting je v²ak spjat s pravidly, která odpovídají tarifu. Taktéº je pro hosting nutno zvolit na kterém serveru budou jaké sluºby vykonávány. Podstatná je v²ak hlavn moºnost p ipojit k hostingu doménovou adresu. Dále by m l být denován vztah k hostingu a uºivateli. A to tak, ºe zákazník by m l být majitelem hostingu, nebo jeden ze zákazník, kte í mohou hosting editovat. M la by zde být moºnost k hostingu p ipojit konkrétního uºivatele, který jej bude moci spravovat. Figurovat by zde m la i moºnost zvolit zda je nutno hosting hradit. Pokud je nutno hosting hradit, tak ke kterému datu je nastavena splatnost. Tarif by m l specikovat, jaké mnoºství domén, jaký prostor a za jakou cenu je hosting nabízen. Server by m l uvád t jeho název a sluºby, které na n m jsou poskytovány (jedná se o sluºby: DNS, Emailove sluºby, Mysql Databáze, Web). Dále pak by m l nést informace o adrese serveru a bezpe nostním tokenu. Bezpe nostní token by m l zajistit bezpe nost p i p enosu poºadavk na server. Zákazník slouºí ke 2 ú el m. Jako majitel hostingu u kterého jsou uvedeny faktura ní údaje a také jako skupina uºivatel, která m ºe být p i azena k hostingu jako její správce. K zákazníku je moºno p i adit uºivatele, který se p ihlásí jako majitel zákazníka. Vyuºití zákazníka jako majitele hostingu a skupiny uºivatel je z d vodu snaº²ího p i- azování uºivatel k hostingu. Protoºe né vºdy je nutno, aby zákazník, který je vlastníkem, m l i vlastního uºivatele. Je tedy nutno k hostingu p i adit jiného zákazníka, který jej bude spravovat. 3
4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Uºivatel by m l být pouze poloºkou která nese informaci o p ihla²ovacích údajích a o tom, zda je uºivatel administrátorem, nebo ne. Doména je jednou z nejpodstatn j²ích ástí a to z d vodu, ºe se na n j váºou v²echny ostatní sluºby spojené s doménami (jedná se o emailové sluºby, ftp ú ty, mysql databáze, subdomény a CRON úlohy). Emailové schránky by m lo být moºno p ipojit ke kaºdé domén, dále by m ly evidovat uºivatelské jméno, maximálnní velikost schránky (pokud je to ºádoucí) a p ístupové heslo ke schránce. Emailový alias by m lo být moºno p ipojit ke kaºdé domén, m l by zaji² ovat správné p esm rování emial. U emailového aliasu by m lo být evidováno: lokální email a email p esm rování. Emailový ko² by m lo být moºné p ipojit ke kaºdé domén. M l by zaji² ovat p eposlání email, které nenajdou v domén adresáta, na jiný email, tak aby bylo moºné odchytit v²echny p íchozí emaily. Subdoména ponese informace o safe módu, názvu a o stránkách kam bude web p esm rován, dojde-li k n kterým z chyb (error: 401, 403, 404 a 500), m lo by být moºno ji p ipojit ke kaºdé domén. Mysql databáze by m la být moºna p ipojit k domén a m la by evidovat údaje o jménu databáze, kódování databáze, uºivatelském jménu a heslu. Ftp ú tet je poloºka, která má nést informace o subdomén, ke které je uºivatel p i azen, uºivatelském jménu, heslu, prostoru, ke kterému má uºivatel p ístup a dob platnosti ftp ú tu. M lo by být moºno ji p ipojit ke kaºdé domén. Cron úlohy by m ly nést informace o cest ke skriptu, který má být vykonáván a astosti výkonávání. M lo by být moºné je p ipojit k domén. Backend job je poloºka, která má nést informaci o provedených akcích systému, které se mají vykonat na reálných serverech. M la by zaznamenávat druh, parametry a stav akce, dále pak server, na kterém má být událost vykonána. Jedná se tedy o most mezi webovým rozhraním a skute ným vykonáním. 2.2 Existující e²ení Po vyslechnutí p edchozí specikace problému jsem se pokusil nalézt existující e²ení, které by odpovídalo poºadavk m. Poda ilo se mi nalézt následující e²ení:
2.2. EXISTUJÍCÍ E ENÍ 5 2.2.1 cpanel cpanel je systém postavený na unixové bázi slouºící ke správ webhostingového serveru. Byl vytvo et pro usnadn ní správy za pomoci grackého reºimu. Vyuºívá trojuºivatelský systém (adminsitrátor, prodejce a zákazník). P ístup k systému je provád n p es webový prohlíºe, krom n j umoº uje taktéº konzolové API, které umoº uje t etí stran, automatizovat standardní procesy pro správu systému. Základní inslace podporuje Apache, PHP, Mysql, Postgres, Perl a BIND (DNS) a emailovou podporu. cpanel je b ºn dostupný na portu 2082. V zabezpe eném portu pak na 2083. Nevýhodou tohoto systému je, ºe nejde po instalaci ze serveru odstranit a je nutno server naformátovat. [7] 2.2.2 Webmin Webmin je stejn jako cpanel zam en na servery unixového typu, ale je jej moºno nainstalovat i na windows server. Pomocí webminu je moºno kongurovat vnit ní stranu serveru, jako jsou nap íklad diskové kvóty, sluºby, nebo konguraci soubor, dále pak modikovat konguraci open source aplikací, jako jsou nap íklad Apatch, PHP, nebo MySQL. Systém v²ak není zam en pouze na správu webhostingu, ale na správu celého opera ního systému. Je naprogramován zejména v jazyce Perl a je moºno jej roz²í it o dal²í moduly. [16] 2.2.3 Kloxo Systém Kloxo je znám jako alternativa cpanelu, je postaven pro systémy unixového typu a nabízí správy webhostingového serveru. Kloxo je gracké uºivatelské rozhraní, které umoº uje p epínání se mezi sluºbami bez ztráty dat. Umoº uje v²ak práci nejen s apatchem, ale nap íklad i s lighttpd servery. Kloxo Enterprise umoº uje transformaci dat z Apatche do lighttpd. [11] 2.2.4 Zhodnocení Nalezené systémy jsou zam eny zejména na správu celého serveru, nebo pak pouze na správu webhostingu na jednom serveru. Poºadavkem na systém je, ale moºnost spravovat webhosting na více serverech a i s rozd lenými sluºbami. šádná z alternativ neni tedy dosta ující a je nutno vytvo it systém vlastní.
6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3 Analýza a návrh e²ení V této kapitole se zam íme na analýzu specikovaného systému z p edchozí kapitoly. Sestrojíme obecné a funk ní poºadavky, na základ kterých vytvo íme Use Case diagramy. Následn pak sestrojíme diagram t íd. V²chny diagramy v této práci byly vytvo eny za pomoci Enterprise architektu [17]. 3.1 Systémové poºadavky 3.1.1 Funk ní poºadavky Funk ní poºadavky, jak z názvu vyplývá, popisují funk ní poºadavky zákazníka, ale ne vºdy jsou v²echny. Je moºné, ºe v pr b hu návrhu systému se objeví nové funk ní poºadavky, které vyplývají z ostatních. [10] Aplikace umoºní uºivateli se p ihlásit na základ emailové adresy a hesla. Aplikace umoºní uºivateli se odhlásit. Aplikace umoºní uºivateli zaslat ztracené heslo. Aplikace bude vyºadovat p ihlá²ení pro p ístup do v²ech ástí systému. Aplikace bude rozli²ovat p ístup podle role uºivatele. Apliakce umoºní administrátoru sledovat backend joby. Aplikace umoºní administrátoru p idat, upravit, nebo odebrat server. Aplikace umoºní administrátoru p idat, upravit, nebo odebrat tarif. Apliakce umoºní administrátoru p idat, upravit, nebo odebrat uºivatele. Aplikace umoºní administrátoru p idat, upravit, nebo odebrat zákazníka. Aplikace umoºní administrátoru p idat, nebo odebrat zákazníkovi uºivatele, který je jeho vlastníkem. 7
8 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Aplikace umoºní administrátoru p idat, nebo odebrat zákazníkovi uºivatele, který je lenem této skupiny. Aplikace umoºní administrátoru p idat, upravit, nebo odebrat hosting. Aplikace bude vytvá et záznam o provedení: p ídání, odebrání, nebo úpravy hostingu do backend job. Aplikace umoºní administrátoru p idat, nebo odebrat hostingu zákazníka, který je jeho vlastníkem. Aplikace umoºní administrátoru p idat, nebo odebrat hostingu zákazníka, který jej m ºe spravovat. Aplikace umoºní administrátoru p idat, nebo odebrat hostingu uºivatele, který jej m ºe spravovat. Aplikace umoºní administrátoru p idat, upravit, nebo odebrat hostingu doménu. Aplikace bude vytvá et záznam o provedení: p idání, odebrání, nebo úpravy domény do backend job. Apliakce umoºní uºivateli p idat, nebo upravit uºivatelské údaje. Aplikace umoºní uºivateli, který je vlastníkem zákazníka, upravit údaje o zákazníku. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo odebrat mysql databázi. Aplikace bude vytvá et záznam o provedení: p idání, odebrání, nebo editace mysql databáze do backend job. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo odebrat subdoménu. Aplikace bude vytváºet záznam o provedení: p idání, odebrání, nebo editace subdomény do backend job. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo odebrat ftp ú et. Aplikace bude vytvá et záznam o provedení: p idání, odebrání, nebo editace ftp ú tu do backend job. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo odebrat emailovou schránku. Aplikace bude vytvá ez záznam o provedení: p idání, odebrání, nebo editace emailové schránky do backend job. Apliakce umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo odebrat emailový alias.
3.1. SYSTÉMOVÉ POšADAVKY 9 Aplikace bude vytvá et záznam o provedení: p idání, odebráni, nebo editace emailovýho aliasu do backend job. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, nebo odebrat emailový ko². Aplikace bude vytvá et záznam o provedení: p idání, nebo odebrání emailového ko²e do backend job. Aplikace umoºní uºivateli, který je ve vztahu s doménou, p idat, upravit, nebo editovat CRON událost. Aplikace bude vytvá et záznam o provedení: p idání, odebráni, nebo úpravy CRON události do backend job. 3.1.2 Nefunk ní poºadavky Nefunk ní poºadavky jsou podmínky kladené zákazníkem, tak aby spl ovaly jejich obchodní cíle. Dále je zde dal²í skupina nefunk ních poºadavk zvaná Service-level. Tato skupina se zam uje na poºadavky, které p ímo nesouvisí s obchodními cíly, ale jsou taktéº klí ové. [14] Seznam obecných poºadavk : Aplikace bude napsána ve framework Ruby on Rails. Aplikace bude vyuºívat dokumenta ní databázi Mongodb. Aplikace bude p ístupná z webového prohlíºe e. Aplikace bude psána za pouºití agilní technolohie Behaviour Driven Development. Aplikace bude dále roz²í ítelná.
10 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ 3.2 P ípady uºití P ípady uºití, známe také jeako Use case. Slouºí k dokumentaci poºadavk na systém. Kaºdý use case popisuje scéná jak by m l systém spolupracovat s koncovým uºivatelem k dosaºení cíle. P i vytvá ení p ípadu uºití se vyuºívá UML diagram. [18] Zde se zam íme v první ásti na aktéry a dále pak na konkrétní scéná e jednotlivých aktér. 3.2.1 Akté i Akté i jsou v²echny osoby které jsou n jákým zp sobem spjaté se systémem. A týkají se jich r zné akce a závislosti. V systému se objevuje 5 uºivatelských rolí. Jejich provázání je znázorn no v následujícím diagramu 3.1. Obrázek 3.1: UseCase Diagram - Akté i systému 3.2.2 Nep ihlá²ený uºivatel Nep ihlá²ený uºivatel je, jak název napovídá, uºivatel stojící p ed systémem, který má jen omezené moºnosti, které m ºe v systému provád t. Popis t chto akcí najdete v diagramu 3.2. 3.2.2.1 Scéná : P ihlásit se Vstupní podmínky Existující uºivatel v systému
3.2. P ÍPADY UšITÍ 11 Obrázek 3.2: UseCase Diagram - nep ihlá²ený uºivatel Scéná 1. Uºivatel vstoupí na p ihla²ovací stránku systému 2. Uºivatel zadá p ihla²ovací údaje 3. KDYš jsou údaje nesprávné: (a) Uºivatel je p esm rován zp t na p ihla²ovací stránku s chybovou hlá²kou 4. Uºivatel je p esm rován do systému 5. Uºivatel je p íhlá²en 3.2.2.2 Scéná : Zaslat si heslo Vstupní podmínky Existující uºivatel v systému Scéná 1. Uºivatel vstoupí na stránku pro zaslání hesla 2. Uºivatel zadá email 3. KDYš email není správný: (a) Uºivatel je p esm rován na stránku pro zaslání hesla s chybovou hlá²kou 4. Uºivateli je odeslán email s odkazem pro zm nu hesla 5. Uºivatel vstoupí na stránku pro zm nu hesla 6. Uºivatel zadá údaje
12 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ 7. KDYš jsou údaje nesprávné: (a) Uºivatel je p esm rován na stránku pro zm nu hesla s chybovou hlá²kou 8. Uºivatelské heslo je zm n no 9. Uºivatel je p esm rován do systému 10. Uºivatel je p íhlá²en 3.2.3 P ihlá²ený uºivatel P ihlá²ený uºivatel je první role, která vstupuje do systému a pro²la autorizací. Stejn jako u nep ihlá²eného uºivatele má jen minimální moºnosti práce se systémem. Popis p ípad uºití je moºné nalézt v diagramu 3.3. Obrázek 3.3: UseCase Diagram - p ihlá²ený uºivatel 3.2.3.1 Scéná : Odhlásit se Vstupní podmínky Existující uºivatel v systému Scéná 1. Uºivatel spustí odhlá²ení z jakéhokoliv místa v systému 2. Uºivatel je odhlá²en 3. Uºivatel je p esm rován na p ihla²ovací stránku
3.2. P ÍPADY UšITÍ 13 3.2.3.2 Scéná : Upravit uºivatelské údaje Vstupní podmínky Existující uºivatel v systému Scéná 1. Uºivatel vstoupí na stránku pro úpravu uºivatelských údaj 2. Uºivatel zadá údaje 3. KDYš jsou údaje nesprávné: (a) Uºivatel je p esm rován na stránku pro úpravu uºivatelských údaj s chybovou hlá²kou 4. Uºivatelské údaje jsou upraveny 5. Uºivatel je p esm rován na výchozí stránku p ihlá²eného uºivatele 3.2.4 Uºivatel vlastnící zákazníka Uºivatel vlastnící zákazníka, je p i azen v poloºce zákazník jako její majitel. Vztahuje se na n j tedy moºnost spravovat zákaznické údaje. A je spjat s hostingy zákazníka. P ípad uºití je moºné nalézt v diagramu 3.4. Obrázek 3.4: UseCase Diagram - uºivatel vlastnící zákazníka 3.2.4.1 Scéná : Úprava zákaznických údaj Vstupní podmínky Existující zákazník v systému Existující uºivatel v systému vlastnící zákazníka
14 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Scéná 1. Uºivatel vstoupí na stránku pro úpravu zákaznických údaj 2. Uºivatel zadá údaje 3. KDYš jsou údaje nesprávné: (a) Uºivatel je p esm rován na stránku pro správu uºivatelských údaj s chybovou hlá²kou 4. Uºivatelské údaje jsou upraveny 5. Uºivatel je p esm rován na stránku pro úpravu zákaznických údaj 3.2.5 Uºivatel ve vztahu s hostingem Uºivatel se stává spjat s hostingem v okamºiku kdyº je: vlastníkem, nebo lenem zákazníka, který je p i azen k hostingu jako vlastník. vlastníkem, nebo lenem zákazníka, který je p i azen k hostingu jako jeden ze správc. p i azen k hostingu jako jeden ze správc. Popis p ípad uºití uºivatele ve vztahu s hostingem je moºné nalézt v diagramu 3.5. 3.2.5.1 Scéná e Scéná e p ípadu uºití administrátora je moºno nalézt v p íloze D.1, která je umíst na na p iloºením CD. 3.2.6 Administrátor Administrátor d dí vlastnosti v²ech ostatních uºivatel a navíc mu umoº uje správu dal²ích vlastností systému. Akce je moºné nalézt v diagramu 3.6. 3.2.6.1 Scéná e Scéná e p ípadu uºití administrátora je moºno nalézt v p íloze D.2, která je umíst na na p iloºeném CD.
3.2. P ÍPADY UšITÍ 15 Obrázek 3.5: UseCase Diagram - uºivatel ve vztahu s hostingem
16 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.6: UseCase Diagram - administrátor
3.3. DATOVÝ MODEL 17 3.3 Datový model Datový model popisuje strukturu dat, tak jak budou uloºena v databázi a relace mezi nimi. To umoº uje snadnou p edstavu o tom, jak mezi sebou entity spolupracují a jak jsou na sob zavislé. [8] Datový model systému popisuje diagram 3.7. Tento diagram je vytvo et pro databázi mongodb 4.1.2. Proto je v následných specikacích jednotlivých entit popsáno, jaké validace jsou nad poloºkami vykonávány, nebo dokumenta ní databáze nekontroluje p esné datové typy. Z tohoto d vodu je nad nimi vykonávána validace pomocí Mongoid 4.1.3 adaptéru. V²echny entity datového modelu je moºno nalázt v p íloze E, která je umíst na na p iloºeném CD. 3.3.1 Cron Entita Cron popisuje soubor, který má být automaticky spou²t n a udává etnost jeho spou²t ní. Informace o datových typech a validacích je moºno nalézt v tabulce 3.1. Relace: Cron musí mít práv jednu Domain. Název Datový typ Popis path String Cesta k souboru z hlediska domény. Validace: prezence email String Email se kterým má být akce spjata. Validace: emailového formátu minute Integer Minuta spu²t ní. Validace: prezence, rozsah ísel hour Integer Hodina spu²t ní. Validace: prezence, rozsah ísel day Integer Den spu²t ní. Validace: prezence, rozsah ísel month Integer M síc spu²t ní. Validace: prezence, rozsah ísel weekday Integer Den v týdnu spu²t ní. Validace: prezence, rozsah ísel is actiove Boolean Aktivitu úlohy. Validace: ºádná script url String Celá cesta k souboru. Validace: ºádná Tabulka 3.1: Entita Cron
18 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.7: Datový model 3.3.2 Domain Entita Domain, jak je z názvu z ejmé, popisuje webovou doménu 2. ádu. Informace o datových typech a validacích je moºno nalézt v tabulce 3.2. Relace: Domain musí mít práv jeden Hosting.
3.3. DATOVÝ MODEL 19 Domain m ºe mít mnoho MysqlDatabase Domain m ºe mít mnoho Subdomain. Domain m ºe mít mnoho FtpAccount. Domain m ºe mít mnoho MailBox. Domain m ºe mít mnoho MailTrash. Domain m ºe mít mnoho MailAlias. Domain m ºe mít mnoho Cron. Název Datový typ Popis name String Jméno domény. Validace: prezence, formát domény expiration Date Datum platnosti domény. Validace: ºádná is billed Boolean Zda je doména ú tována. Validace: ºádná Tabulka 3.2: Entita Domain 3.3.3 Hosting Entita Hosting popisuje informace ukládané ke kaºdému hostingu. Informace o datových typech a validacích je moºno nalézt v tabulce C.1. Relace: Hosting m ºe mít práv jeden Server. Vztah je zde popsán jako web, protoºe hosting m ºe mít jeden web server. Hosting m ºe mít práv jeden Server. Vztah je zde popsán jako dns, protoºe hosting m ºe mít jeden dns server. Hosting m ºe mít práv jeden Server. Vztah je zde popsán jako mail, protoºe hosting m ºe mít jeden mail server. Hosting m ºe mít práv jeden Server. Vztah je zde popsán jako mysql, protoºe hosting m ºe mít jeden mysql server. Hosting m ºe mít mnoho User. Vztah je popsán jako member, protoºe hosting m ºe mít mnoho uºivatelských správc. Hosting m ºe mít mnoho Customer. Vztah je popsán jako member, protoºe hosting m ºe mít mnoho zákaznických správc.
20 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Hosting musí mít práv jednoho User. Vztah je popsán jako owner, protoºe hosting musí mít zákazníka vlastníka. Název Datový typ Popis name String Jméno hostingu. Validace: prezence is billed Boolean Je hosting ú tován? Validace: ºádná bill period Integer Doba ú tování v m sících. Validace: ºádná bill date Date Datum ú tování. Validace: ºádná note String Poznámky. Validace: ºádná last update DateTime Datum poslední zm ny v celém hostingu. Validace: ºádná Tabulka 3.3: Entita Hosting
Kapitola 4 Realizace Kapitola realizace popísuje technologie, které byly k tvorb pouºity a strukturu aplikace. Dále popisuje samotnou implementaci systému. 4.1 Pouºité technologie V systému bylo pouºito mnoho moderních a zajímavých technologií. Popí²u vám zde v²ak jen pár nejzajímav j²ích. 4.1.1 Ruby on Rails Ruby on Rails je framework pro vývoj webových aplikací napojených na databázi, pouºívající návrhový vzor Model View Controller. V²e v Rails je zaloºeno na jazyce Ruby 1. Na jazyce Ruby je zaloºen Ajax v ²ablonách (view), odpov di v controllerech i architektura aplikace v modelech obalujících databázi. Ke spu²t ní aplikace je t eba jen databáze a webový server. [15] 4.1.2 MongoDb MongoDb je open source dokumenta ní databáze, ne Sql typu, je lenem nové rodiny databázových systém. Namísto ukládání dat do klasických tabulek, ukládá struktorovaná data jako JSON, tedy s dynamickým schématem. To d lá integraci dat v n kterých aplikacích jednodu²²í a rychlej²í. Vývoj systému zapo al v roce 2007 a jiº dnes je p ipraven k plnému produk nímu pouºití. Je nasazen nap íklad v MTV Networks 2 a Foursquare 3. [12] 1 Ruby je pln objektový, interpretovaný, skryptovací jazyk. 2 MTV Networks je divize spole nosti MTV dohlíºející na b h mnoha televizních kanál. 3 Foursquare je mobilní geologická aplikace s prvky sociální sít. 21
22 KAPITOLA 4. REALIZACE 4.1.3 Mongoid Mongoid je objektov dokumenta ní mapper (ODM) pro MongoDb napsaný v jazyce Ruby. Vývoj zapo al v srpnu roku 2009 ameri anem Durran Jordan. Filozoi Mongoid je poskytnout p ív tivý API 4 pro vývojá e Ruby, kte í pouºívají Active- Record 5. Mongoid vyuºívá sílu Mongodb, která neobsahuje striktní schéma rela ní databáze. Vyuºíva dokumenta n -databázový design, dynamické dotazování a automatické upravování operací. [3] 4.1.4 Twitter Boostrap Twitter Boostrap je bezplatná kolekce nástroj pro vytvá ení webových stránek a webových aplikací. Obsahuje p edp ipravené ²ablony pro formulá e, tla ítka, navigace a mnoho dal²ích komponent za pouºití HTML 6 a CSS 7, p ípadn pak JavaScriptu. Jedná se o nejpopulárn j²í projekt na GitHubu v USA vyuºívaný zejména v NASA 8, MSNBC 9 a v mnoha dal²ích spole nostech. [6] 4.1.5 Devise Devise je exibilní e²ení pro autentizaci a autorizaci v systému. Je napsán pro Ruby on Rails. Umoº uje snadnou práci s uºivateli a jejich pravy. V sou asné dob se skládá z 12 modul : databázové autentizace, tokenu pro zabezpe- ení, omniauth slouºící prou autentizaci p es facebook, potvrzování p es email, obnovu p es email, registraci, zapamatování p ihlá²eného uºivatele, sledování po tu p ihlá²ení, vypr²ení platnosti p ihlá²ení, validace p ihla²ovacích údaj a zablokování ú tu po ur itém po tu neúsp ²ných p ihlá²ení. [5] 4.1.6 Cucumber Cucumber je nástroj provád jící automatické testy popsané textovou formou. V první fázi se m ºe zdát, ºe se jedná pouze o testovací nástroj, ale je zam en zejména na podporu BDD. Filozoí cucumber je, ºe by testy m ly být napsány po analýze jako první a jsou zkontrolovány obchodními analytiky, netechnicky z astn nou stranou. Cucumber je sepsán v jazyce Ruby, ale je moºné je nasadit nejen na kód psaný v Ruby, ale i v jiných jazycích nap íklad Java, C#, nebo Python. [4] 4 Application Programming Interface ozna uje rozhraní pro programování aplikací 5 ActiveRecord je adaptér pro práci s rela ními databázemi zakomponovaný v Ruby on Rails 6 HyperText Markup Language, zna kovací jazyk pro tvorbu webových stránke. 7 Kaskádové styly, nástroj pro designování stránek napsaných v HTML. 8 National Aeronautics and Space Administration 9 MSNBC je kabelový spravodajský kanál v USA
4.2. STRUKTURA APLIKACE 23 4.1.7 Rspec Rspec byl vytvo en Stevenem Bakerem v roce 2005. Vznikl na základ doslechu o BDD od Aslaka Hellesøy, který s Danem Northem pracoval na prvním projektu v BDD. Vznikl jako nový nástroj pro podporu vývoje TDD 10 se zam ením na scéná e v jazyce Ruby. Jedná se tedy o testovací BDD framework zam ený na TDD. [2] 4.1.8 Behavior Driven Development Behavior Driven Developmen zkrácen jen BDD, je agilní metodika vývoje softwaru. BDD se dívá na vývoj z pohledu uºivatele. To znamená, ºe programátor musí chápat sv t z pohledu uºivatele. Postup vývoje v BDD je zaloºen na dvou vrstvách testování. V první ásti je nutno napsat scéná (scéná e se v t²inou shodují s jednotlivými p ípady uºití) popisující akci, kterou vykonává uºivatel. Tato ást testu je provád na v mé práci pomocí Cucumber. P i spu²t ní t chto test dojde k neúsp chu. V dal²í fázi je nutno p ipravit Rspec testy, které testují software z hlediska programu. P i spu²t ní test jsou v²echny testy neúsp ²né. Po provedení p edchozích dvou krok teprve p ichází na adu implementace samotného kódu. Po správném napsání implementace by m lo dojít k sprovozn ní Rspec test. Po sprovozn ní Rspec test by m lo dojít k refactoringu 11 a vrácení se znovu k testování Rspec, do té doby neº bude v²e v po ádku. Po dokon ení cyklu refactoringu se p esuneme k sprovozn ní Cucumber scéná. To znamená zejména upravit kosmetickou strunu systému, tak aby odpovídala p edchozímu popisu. Po této ásti dochází znovu k refactoringu. Tímto dojde ke sprovozn ní daného scéná e s eliminováním mnoha chyb. [2] Gracké znázorn ní cyklu BDD je k nalezení v obrázku 4.1. 4.2 Struktura aplikace Systém vyuºívá klasickou MVC arcihtekturu a je tedy rozd lena do t í vrstev: Model, View a Controller. 4.2.1 MVC Model, View, Controller odd luje strukturu aplikace do 3 vrstev a to datového modelu, uºivatelského rozhraní a ídící logiky. [13] Model Model p edstavuje uloºi²t dat se kterými se v systému pracuje. Dotazuje se databáze a p edává je ídící struktu e. 10 Test Driven Development je agilní metorika vývoje. 11 Refactoring je isnost zabívající se p episem existujícího kódu do srozumiteln j²í a efektivn j²í formy.
24 KAPITOLA 4. REALIZACE Obrázek 4.1: Behavior Driven Development cyklus [1] View Provádí zobrazení dat, které jsou p edány ídící struktourou uºivateli. Controller ídící struktura zvolí data z modelu a p edá je ²ablon. 4.2.2 Souborová struktura aplikace Souborová struktura aplikace je popsána tabulkou 4.1. 4.3 Ukázka implementace vybrané funkcionality V této ásti je popsán konkrétní postup vývoje jedné iterace cyklu BDD. A to pro zobrazení prázdného seznamu tarif.
4.3. UKÁZKA IMPLEMENTACE VYBRANÉ FUNKCIONALITY 25 Adresa Popis app Obsahuje hlavní ást kódu. - assets Obsahuje: Css, javascript a dal²í soubory které mají být dostupné. - controllers Obsahuje ídící struktury aplikace. - helpers Obsahuje pomocné funkce k jednotlivým views. - models Obsahuje datové modely. - views Obsahuje ²ablony jednotlivých akcí. cong Obsahuje kongura ní soubory celého systému. features Obsahuje scéná e cucumber test. - step denition Obsahuje popisy jednotlivých krok scéná. lib Obsahuje knihovny vyuºívané systémem. log Obsahuje výpisy z b hu systému. public Obsahuje ve ejné statické ásti webu, nap íklad error stránky. script Obsahuje obsluºné scripty, neslouºí pro b h systému. spec Obsahuje Rspec testy. - factory.rb Generátor model pro testy. vendor Obsahuje externí pluginy a assety. Gemle.rb Seznam gem, které jsou systémem vyuºívány. Rakele.rb Seznam vykonávaných úloh. 4.3.1 Vytvo ení scéná e Tabulka 4.1: Souborová struktura systému Ve sloºce features vytvo íme scéná tarif.feature. V n m popí²eme scéná. @javascript Feature: Tarifs Scenario: Checking tarifs list without tarifs Given I am signed in as admin And I am on tarif pages Then I should see empty list of tarif pages V dal²í fázi vytvo íme popis jednotlivých krok scéná e ve sloºce features/step_deniton soubor tarif_step.rb. # encoding: utf-8 Given /^I am on tarif pages$/ do visit '/admin/tarifs' end Then /^I should see empty list of tarif pages$/ do
26 KAPITOLA 4. REALIZACE page.should have_selector 'table#tarifs tbody tr td.empty' end Pokud nyní spustíme test zjistíme ºe prob hl neúsp ²n. 4.3.2 Vytvo ení testu Pro vytvo ení testu a controlleru který nám má zajistit zobrazení prázdného seznamu tarif pouºijeme generátor. A to tak, ºe v konzoli v projektu vyvoláme: rails g controller admin::tarifs Nyní máme p edp ipravený soubor s testem a samotný controller. A vrhneme se na napsání testu. Ten sepí²eme do souboru spec/controllers/admin/tarifs_controller_spec.rb. require 'spec_helper' include Devise::TestHelpers describe Admin::TarifsController do context 'logged in as admin' do login_admin before do controller.stub :authenticate_user! end describe 'index' do it 'render index template' do get :index response.should render_template 'index' end end end end 4.3.3 Samotná implementace Pokud nyní spustíme Rspec test zjistíme, ºe neprochází z d vodu neexistující routy 12 pro controller: admin::tarifs akce: intex. Zaregistrujeme tedy routu do cong/routes.rb, aby bylo moºné vstoupit do námi vyºadované akce. P idáme pouze následující kód mezi ostatní. 12 Routa je cesta k zaregistrované akci v systému.
4.3. UKÁZKA IMPLEMENTACE VYBRANÉ FUNKCIONALITY 27 namespace(:admin) do resources :tarifs end Pokud nyní spustíme Rspec test tak nebude znovu úsp ²n, protoºe neexituje akce: intex pro controller: admin::tarifs. Vytvo íme tedy akci v controlleru app/controllers/admin/tarifs_controller.rb. class Admin::TarifsController < ApplicationController respond_to :html end before_filter :authenticate_user! def index end Po spu²t ní testu, ale není test stále úsp ²ný, protoºe neexistuje ²ablona. Tak tedy vytvo íme ²ablonu app/views/admin/tarifs/index.haml. Po vytvo ení ²ablony spustíme Rspec test a ten jiº prob hne úsp ²n. Spustíme tedy i Cucumber test, ale ten neprojde úsp ²n, protoºe po vstupu na stránku nebyla nalezena ºádná prázdná tabulka. Je tedy nutno do ²ablony vytvo it tabulku která bude prázdná: %table#tarifs.table-striped.table-bordered.table-condensed %thead %tr %th= t 'tarifs.name' %th= t 'tarifs.price' %th= t 'tarifs.year_price' %th= t 'tarifs.space' %th= t 'tarifs.domains' %th= t 'tarifs.actions' %tbody %tr %td.empty{colspan: 6}= t ('no_tarifs') Po spu²t ní cucumber testu zjistíme, ºe uº je v²e v po ádku. 4.3.4 Shrnutí Provedli jsme zde zprovozn ní scéná e, ve kterém uºivatel uvidí prázdný seznam tarif, za podmínek, ºe zádné tarify v systému nejsou. Pokud v²ak vytvo íme scéná, ve kterém chceme v seznamu vid t existující tarify, nebude scéná funk ní, protoºe zde zatím se ºádnými daty nepracujeme. Je tedy nutné provést úpravu sou asného kódu tak, aby spl oval nový scéná a zachovával ten p vodní.
28 KAPITOLA 4. REALIZACE 4.4 Model nasazení Diagram nasazení popisuje fyzické rozd lení systému do jednotlivých uzl a komunikace mezi nimi. [9] Jak je moºné vid t v diagramu 4.2. Do systému je p istupováno p es webový prohlí- ºe. Samotná aplikace v diagramu zakreslená jako Ruby on Rails, je spu²t na na Apatchy. Databáze m ºe být uloºena na externím serveru, komunikaci mezi ní zaji² uje Mongoid 4.1.3. Obrázek 4.2: Diagram nasazení
Kapitola 5 Testování Systém je vyvýjen pomocí agilní metodiky BDD 4.1.8 a tak je testování jeho p irozenou sou ástí. S kaºdou iterací p idání kódu vzniká sada nových test. V první ad integra ní testy a následn pak unit testy. 5.1 Unit testy Unit test se zabývá testováním jednotlivých fragment kódu. V objektov orientovaném programování se zam uje zejména na testování jednotlivých funkcí. To zaji² uje správnost jednotlivých komponent a tak by m l systém fungovat bez obtíºí. V systému je testování provedeno pomocí frameworku Rspec 4.1.7. Testování pomocí jednotkových test je velmi d leºité, protoºe zaji² uje omezení vzniku chyb, které se dostanou do systému a je obtíné je hledat. Dále je velmi uºite né mít sadu test, protoºe p i zm n ásti kódu se snadno odhalí p ípadná vzniklá chyba a je moºné ji snadno opravit. 5.1.1 Pokrytí kódu Pokrytí kódu se dá spo ítat jako mnoºství test na jednotku funkce. V systému je sepsáno 683 test a je zde 311 testovaných funkcí. Do výpo tu jsou zahrnuty st ºejní funkce, které ovliv ují b h systému, nikoliv pak funkce helper 1. Dále do výpo tu nejsou zahrnuty funkce t etí strany. V celkovém výpo tu je tedy koecient pokrytí roven 2,2. To znamení ºe kaºdá funkce v systému je testována p ibliºn 2,2 testy. Pokud zahrneme do výpo tu i netestované helpery dostaneme koecient roven pokrytí 1,65. 5.2 Regresní testy Regresní testy jsou zam eny na integraci nových komponent do sou asného systému. Sada takových test zaji² uje nepo²kození p edchozí funk nosti na úkor nové. V systému je pou- ºíváno pro tvorbu integra ních test knihovny cucumber 4.1.6. 1 Helper funkce která, pomáhá generovat obsah pro ²ablony, je vyvolávána ²ablonou. 29
30 KAPITOLA 5. TESTOVÁNÍ 5.2.1 Pokrytí scéná Pokrytí scéná je moºné spo ítat jako pom r sepsaných scéná k jednotlivým p ípad m uºití v analýze a po et reálných scéná regresních test. V p ípadech uºití je popsáno 47 scéná, které se tém ve v²ech p ípadech d lí na úsp ²ný a neúsp ²ný. Tím nar stá mnoºství na dvojnásobek tedy 94 scéná. V systému je sepsáno více neº 247 regresních test, které odpovídají z velké mirý scéná- m pouºití. Jsou v nich zahrnuty i scéná e výpis, ve kterých jsou plné i prázdné seznamy, nebo moºné alternativy selhání. Z výpo u vyplývá, ºe koecient pokrytí scéná je rovno 2,6. Z toho vyplývá, ºe je pokryto 100% p ípad uºití.
Kapitola 6 Záv r Cílem bakalá ské práce bylo navrhnout a implementovat webové rozhraní pro správu webového hostingu a sluºeb s ním spjatých, za pomocí agilní metodiky vývoje Behaviour Driven Development 4.1.8 v platform Ruby on Rails 4.1.1. Funk nost ov te sadou jednoduchých test. Zadání bylo dle mého názoru úsp ²n spl eno, protoºe rma Blueberry.cz Apps s.r.o. byla s programem spokojena a chysá se ho nasadit k uºití. V práci byly spln ny v²echny body zadání. Do²lo k d kladné analýze, která dbala na d kladný popis v²ech poºadavk. Následný návrh e²ení, který byl sestaven s ohledem na dal²í roz²í ítelnost. Implementace byla asov nejnáro n j²í ástí práce, protoºe systém je na implementaci pom rn rozsáhlý a p i kaºdé iteraci vývoje bylo psáno velké mnoºství test. Testování bylo st ºejní ást projektu, protoºe je zahrnuto v agilní metodice vývoje softwaru Behaviour Driven Development 4.1.8, která si klade za cíl, d kladné testování softwaru. Tuto metodiku jsem si p i práci na projektu poprvé po ádn vyzkou²el a byla pro m velice p ínosnou, nebo mi ukázala, ºe je váºn nutné, v²e d kladn testovat. Chyby, které jsou do softwaru zanesené p idáním nové funkcionality, je moºno velmi snadno nalézt a odstranit a tím zabránit po²kození jiº existující ásti softwaru. Dále jsem se d kladn seznámil s jazykem Ruby a frameworkem Ruby on Rails 4.1.1. V budoucnu plánuji dále roz²i ovat své zku²enosti v tomto jazece a frameworku. Práce pro m byla dále p ínosná zejména kv li moºnosti otestovat si vývoj softwaru od po áte ního získání informací poºadavk na systém, p es analýzu a návrh e²ení aº do samotné implementace. Tato praxe mi ukázala jiný pohled na vývoj softwaru, neº pouze ten z pohledu programátora, který pouze implementuje n kým zadaný návrh e²ení. K samotnému nasazení aplikace do produkce zatím nedo²lo a to z d vodu, ºe proxy server, který má provád t akce vykonané v systému na konkrétních serverech, není zatím upraven tak, aby splupracoval s novou verzí systému pro správu webových hosting. P vodní e²ení vyuºívalo totiº rela ní databázi a tak je proxy p ipravena pro ni. Je tedy nutno upravit proxy server, tak aby komunikoval s mongodb 4.1.2. 31
32 KAPITOLA 6. ZÁV R 6.1 Moºná roz²í ení Jako moºnost roz²í ení systému se nabízí p idání faktura ního systému, který by umoºnil snadnou (automatickou) fakturaci za hostingy a provád l jejich urgování, p ípadn nahlásil provozovateli ºe, zákazník dosud neuhradil poºadovanou ástku a je ºádoucí jej ze systému odstranit. Toto e²ení by mohl vyuºívat faktura ní systém spole nosti Blueberry.cz Apps s.r.o., který faktury umí vystavovat a vést jejich p ehlednou evidenci. Dal²í moºností roz²í ení by mohl být objednávkový systém, který by odstínil telefonickou, nebo emailovou komunikaci se zákazníkem zejména do úrovn systému. Zákazník by si zvolil pouze poºadovaný balí ek sluºeb o který by ºádal a po uhrazení by mu byl admimnistrátorem sprovozn n.
Literatura [1] DACID CHELIMSKY, Z. D. A. H. B. H. D. A. NORTH, D. The Rspec Book - Figure 1.1: The BDD cycle. Amazon.com, 1st edition, 2011. [2] DACID CHELIMSKY, Z. D. A. H. B. H. D. A. NORTH, D. The Rspec Book. Amazon.com, 1st edition, 2011. [3] Durran Jordan. Mongoid [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http: //mongoid.org/>. [4] P isp vatelé Wikipedie. Cucumber [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <https://github.com/cucumber/cucumber/wiki/>. [5] P isp vatelé Wikipedie. Devise [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <https: //github.com/plataformatec/devise>. [6] P isp vatelé Wikipedie. Twitter Boostrap [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://en.wikipedia.org/wiki/twitter_bootstrap>. [7] P isp vatelé Wikipedie. cpanel [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http: //en.wikipedia.org/wiki/cpanel>. [8] P isp vatelé Wikipedie. Data model [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://en.wikipedia.org/wiki/data_model>. [9] P isp vatelé Wikipedie. Deployment Diagram [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://en.wikipedia.org/wiki/deployment_diagram>. [10] P isp vatelé Wikipedie. Funk ní poºadavky [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://cs.wikipedia.org/wiki/analýza_poºadavk >. [11] P isp vatelé Wikipedie. Kloxo [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http: //en.wikipedia.org/wiki/kloxo>. [12] P isp vatelé wikipedie. MongoDB [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http: //en.wikipedia.org/wiki/mongodb>. [13] P isp vatelé Wikipedie. Model-view-controller [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://cs.wikipedia.org/wiki/model-view-controller>. 33
34 LITERATURA [14] P isp vatelé Wikipedie. Nefunk ní poºadavky [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://cs.wikipedia.org/wiki/nefunk nípoºadavky_softwarové_ architektury>. [15] P isp vatelé Wikipedie. Ruby on Rails [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://cs.wikipedia.org/wiki/ruby_on_rails>. [16] P isp vatelé Wikipedie. Webmin [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http: //en.wikipedia.org/wiki/webmin>. [17] Sparx Systems. UML tools for software development and modelling : Enterprise Architect UML modeling [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://www. sparxsystems.com.au>. [18] Zbyn k Ungermann. Jak psát UseCase - Systémová analýza a návrh [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: <http://www.cs.vsb.cz/stolfa/vyuka/2007-2008/ san/san-jakpsatusecase.pdf>.
P íloha A Seznam pouºitých zkratek BDD Behavior Driven Development TDD Test Driven Development HTML HyperText Markup Language CSS Cascading Style Sheets JSON JavaScript Object Notation API Application Programming Interface NASA National Aeronautics and Space Administration 35
36 P ÍLOHA A. SEZNAM POUšITÝCH ZKRATEK
P íloha B Instala ní p íru ka B.1 Poºadavky Pro instalaci je nutno spl ovat následující poºadavky: Ruby 1.9.3 Rubygems Mongodb B.2 Instalace Pro instalaci je nutno na server zkopírovat data z CD do poºadované sloºky. V kongura ním souboru: db/seeds.rb: admin_attributes = { :admin => true, :password => "heslo", :password_confirmation => "heslo" } users_attributes = [ admin_attributes.merge(:email => "admin@admin.cz", :name => 'Admin admin'), ] je nuntno upravit poloºky password a password conrmation, na heslo, které bude pro administrátory p ipraveno jako výchozí. Poté je nutno upravit administrátorský email a jeho jméno, tak aby odpovídal údaj m o administrátoru. V souboru cong/mongoid.yml je nutno nastavit databázi, kterou chceme pouºívat. Host ur uje adresu serveru a database název konkrétní databáze. T etím krokem je spu²t ní p íkazu: 37
38 P ÍLOHA B. INSTALAƒNÍ P ÍRUƒKA gem install bundler Po instalaci Budleru je t eba spustit p íkaz: bundler install Tento p íkaz nainstaluje v²echny poºadované závislosti. Po provedení instalace v²ech závyslostí sta í zavést do administrace nového administrátora. To provedeme p íkazem rake db:seed rake s Server je moºno spustit p íkazem: Po provedení p edchozích krok je moºno za ít pouºívat systém ve webovém prohlíºe í na adrese: http://localhost:3000
P íloha C Obsah p iloºeného CD Adresá /Soubor Popis data Zdrojové soubory tohoto dokumentu. prilohy Obsahuje p ílohy které nebyly ti²t ny. src Zdrojový kód aplikace. Struktura viz 4.2.2. text Obsahuje tento dokument ve formátu pdf. README.TXT Obsahuje popis instalace a poºadavky na systém. Tabulka C.1: Obsah p iloºeného CD 39