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, speci kace 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í
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Analýza a návrh °e²ení 3.1
3.2
Systémové poºadavky
7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
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
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.3
3.2.4
Uºivatel vlastnící zákazníka 3.2.4.1
3.2.5
. . . . . . . . . . . . . . . . . . . . . . . .
Scéná°: Úprava zákaznických údaj·
Uºivatel ve vztahu s hostingem
13
. . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . .
14
Scéná°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Administrátor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.6.1
Scéná°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.5.1 3.2.6
3.3
5
3.3.1
Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.2
Domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3.3
Hosting
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
xi
xii
OBSAH
4 Realizace 4.1
4.2
4.3
4.4
21
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
Struktura aplikace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.1
MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.2
Souborová struktura aplikace
24
. . . . . . . . . . . . . . . . . . . . . . .
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
Model nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5 Testování
29
5.1
Unit testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1.1
29
5.2
Regresní testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.2.1
30
Pokrytí kódu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pokrytí scéná°· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Záv¥r
31
6.1
32
Moºná roz²í°ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
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
. . . . . . . . . . . . . . . . .
13
xiv
SEZNAM OBRÁZK
Seznam tabulek 3.1
Entita Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
17
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 speci kaci 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, speci kace 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 de nová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 speci kovat, 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.
Uºivatel
POPIS PROBLÉMU, SPECIFIKACE CÍLE
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í speci kace 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Í EENÍ
2.2.1
5
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 gra cké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 kon gurovat vnit°ní stranu serveru, jako jsou nap°íklad diskové kvóty, sluºby, nebo kon guraci soubor·, dále pak modi kovat kon guraci 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 gra cké 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 speci kované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 EENÍ
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É POADAVKY
•
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.
3.2
ANALÝZA A NÁVRH EENÍ
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 UITÍ
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
11
12
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
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 UITÍ
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 EENÍ
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 UITÍ
Obrázek 3.5: UseCase Diagram - uºivatel ve vztahu s hostingem
15
16
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.6: UseCase Diagram - administrátor
3.3.
17
DATOVÝ MODEL
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 speci kací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
hour
Integer
day
Integer
month
Integer
weekday
Integer
Minuta spu²t¥ní. Validace: prezence, rozsah £ísel Hodina spu²t¥ní. Validace: prezence, rozsah £ísel Den spu²t¥ní. Validace: prezence, rozsah £ísel M¥síc spu²t¥ní. Validace: prezence, rozsah £ísel 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 EENÍ
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.
19
DATOVÝ MODEL
•
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.
expiration
Date
Validace: prezence, formát domény 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 EENÍ
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
bill period
Integer
bill date
Date
note
String
last update
DateTime
Je hosting ú£tován? Validace: ºádná Doba ú£tování v m¥sících. Validace: ºádná Datum ú£tování. Validace: ºádná Poznámky. Validace: ºádná 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.
1
V²e v Rails je zaloºeno na jazyce Ruby . 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í.
2 a Foursquare3 . [12]
Je nasazen nap°íklad v MTV Networks 1 2 3
Ruby je pln¥ objektový, interpretovaný, skryptovací jazyk. MTV Networks je divize spole£nosti MTV dohlíºející na b¥h mnoha televizních kanál·. Foursquare je mobilní geologická aplikace s prvky sociální sít¥.
21
22
KAPITOLA 4.
4.1.3
REALIZACE
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.
4
Filozo i Mongoid je poskytnout p°ív¥tivý API pro vývojá°e Ruby, kte°í pouºívají Active-
5 Record . 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
6 a CSS7 , p°ípadn¥ pak JavaScriptu.
komponent za pouºití HTML
8
Jedná se o nejpopulárn¥j²í projekt na GitHubu v USA vyuºívaný zejména v NASA , 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 5 6 7 8 9
Application Programming Interface ozna£uje rozhraní pro programování aplikací ActiveRecord je adaptér pro práci s rela£ními databázemi zakomponovaný v Ruby on Rails HyperText Markup Language, zna£kovací jazyk pro tvorbu webových stránke. Kaskádové styly, nástroj pro designování stránek napsaných v HTML. National Aeronautics and Space Administration MSNBC je kabelový spravodajský kanál v USA
4.2.
23
STRUKTURA APLIKACE
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
10 se zam¥°ením na scéná°e v jazyce Ruby.
nový nástroj pro podporu vývoje TDD
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·.
11 a vrácení se znovu k testování
Po sprovozn¥ní Rspec test· by m¥lo dojít k refactoringu 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] Gra cké 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 data-
báze a p°edává je °ídící struktu°e. 10 11
Test Driven Development je agilní metorika vývoje. 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 4.2.2
ídící struktura zvolí data z modelu a p°edá je ²ablon¥.
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
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í.
con g
Obsahuje kon gura£ní soubory celého systému.
features
Obsahuje scéná°e cucumber test·.
- step de nition
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.
Gem le.rb
Seznam gem·, které jsou systémem vyuºívány.
Rake le.rb
Seznam vykonávaných úloh.
25
Tabulka 4.1: Souborová struktura systému
4.3.1
Vytvo°ení scéná°e
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_de niton 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 con g/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 before_filter :authenticate_user! def index end 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.
4.4
REALIZACE
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é
1
ovliv¬ují b¥h systému, nikoliv pak funkce helper· . Dále do výpo£tu nejsou zahrnuty funkce t°etí strany. V celkovém výpo£tu je tedy koe cient 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 koe cient 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.
5.2.1
TESTOVÁNÍ
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 koe cient 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.
6.1
ZÁV
R
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].
//mongoid.org/>. [4] P°isp¥vatelé Wikipedie.
Dostupné z:
Cucumber [online]. 2012. [cit. 02. 05. 2012].
Dostupné z:
. [5] P°isp¥vatelé Wikipedie. Devise [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
//github.com/plataformatec/devise>.
[6] P°isp¥vatelé Wikipedie. Twitter Boostrap [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
. [7] P°isp¥vatelé Wikipedie. cPanel [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
//en.wikipedia.org/wiki/cPanel>.
[8] P°isp¥vatelé Wikipedie.
Data model [online]. 2012. [cit. 02. 05. 2012].
Dostupné z:
. [9] P°isp¥vatelé Wikipedie. Deployment Diagram [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: . [10] P°isp¥vatelé Wikipedie. Funk£ní poºadavky [online]. 2012. [cit. 02. 05. 2012]. Dostupné z: . [11] P°isp¥vatelé Wikipedie.
Kloxo [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
//en.wikipedia.org/wiki/Kloxo>.
[12] P°isp¥vatelé wikipedie. MongoDB [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
//en.wikipedia.org/wiki/MongoDB>.
[13] P°isp¥vatelé Wikipedie.
Model-view-controller [online]. 2012. [cit. 02. 05. 2012].
stupné z: .
33
Do-
34
LITERATURA
[14] P°isp¥vatelé Dostupné
z:
Wikipedie.
Nefunk£ní
poºadavky
[online].
2012.
[cit.
02. 05. 2012].
architektury>.
[15] P°isp¥vatelé Wikipedie.
Ruby on Rails [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
. [16] P°isp¥vatelé Wikipedie. Webmin [online]. 2012. [cit. 02. 05. 2012]. Dostupné z:
//en.wikipedia.org/wiki/Webmin>.
[17] Sparx Systems.
UML tools for software development and modelling : Enterprise Ar-
chitect UML modeling [online]. 2012. [cit. 02. 05. 2012].
sparxsystems.com.au>. [18] Zbyn¥k Ungermann. [cit. 02. 05. 2012].
Dostupné z:
Jak psát UseCase - Systémová analýza a návrh [online]. 2012.
Dostupné z:
san/SAN-jakpsatusecase.pdf>.
P°íloha A
Seznam pouºitých zkratek BDD
Behavior Driven Development
TDD
Test Driven Development
HTML CSS
Cascading Style Sheets
JSON API
HyperText Markup Language
JavaScript Object Notation
Application Programming Interface
NASA
National Aeronautics and Space Administration
35
36
PÍLOHA A.
SEZNAM POUITÝ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 kon gura£ním souboru: db/seeds.rb:
admin_attributes = { :admin => true, :password => "heslo", :password_confirmation => "heslo" } users_attributes = [ admin_attributes.merge(:email => "[email protected]", :name => 'Admin admin'), ] je nuntno upravit poloºky password a password con rmation, 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 con g/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.
INSTALANÍ PÍRUKA
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 Server je moºno spustit p°íkazem:
rake s 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
