eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Faktura£ní systém malé spole£nosti
Václav Kontár
Vedoucí práce:
Ing. Martin Molhanec, CSc.
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
11. £ervna 2009
iv
v
Pod¥kování D¥kuji vedoucímu mé bakalá°ské práce Ing. Martinu Molhancovi, CSc. za v¥cné p°ipomínky a ochotu. Také d¥kuji své rodin¥ i p°átel·m za trp¥livost a podporu.
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 11. 6. 2009
.............................................................
viii
Abstract The aim of this work is to analyze, de ne and implement information system for bills which is suitable for small companies. The system shall allow creation of pro-forma invoices and tax documents using web browser. It is implemented using PHP 5 scripting language with addition of MVC ZendFramework, JavaScript, AJAX and CSS. Whole application communicates with relational database MySQL. The work is documented according to the principles of software engineering and the administrator's manual is also included.
Abstrakt Cílem této práce je analyzovat, navrhnout a implementovat informa£ní systém pro správu faktur malých spole£ností. Systém umoº¬uje vytvá°et jak zálohové faktury, tak i da¬ové doklady a to pomocí webového prohlíºe£e. Implementace byla provedena skriptovacím jazykem PHP 5 s vyuºitím MVC ZendFrameworku. V aplikaci jsou dále vyuºity technologie JavaScript, AJAX a CSS. Aplikace komunikuje s rela£ní databází MySQL. V²e je zdokumentováno dle zásad softwarového inºenýrství a na záv¥r práce je p°iloºena uºivatelská p°íru£ka a p°íru£ka administrátora.
ix
x
Obsah 1 Úvod
1
2 Pouºité metodiky a technologie
3
2.1
Pouºitá metodika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
P°ehled pouºitých technologií
2.1.1
Feature Driven Development
. . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Skriptovací jazyk PHP . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Skriptovací jazyk JavaScript . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2.1
2.3
3
AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.3
Rela£ní databáze MySQL
. . . . . . . . . . . . . . . . . . . . . . .
5
2.2.4
Webový server Apache HTTP . . . . . . . . . . . . . . . . . . . . .
5
Návrhový vzor MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.2
View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.3
Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.4.1
Zend Framework
Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.4.2
Zend_View . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.4.3
Zend_Controller . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.4.4
Zend_Db . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.4.5
Zend_Controller_Router_Rewrite . . . . . . . . . . . . .
9
3 Úvodní studie
11
3.1
Odborný £lánek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Katalog poºadavk· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4
Rozbor alternativ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
Analýza rizik
3.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5.1
Ztráta dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5.2
Nedorozum¥ní p°i speci kaci poºadavk·
13
3.5.3
Nedostatky v analýze
3.5.4
Nedodrºení termín·
3.5.5
Nedostate£ná dokumentace
. . . . . . . . . . . . . . . . . . . . . .
14
3.5.6
Chyby v implementaci . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.5.7
Nedostate£ná kvali kace . . . . . . . . . . . . . . . . . . . . . . . .
14
Odhad ceny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . .
13
xi
OBSAH
xii
4 Analýza a návrh °e²ení
15
4.1
Konceptuální datový model
. . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
P°ípady pouºití (Use-Case)
. . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.1
Celkový pohled na aplikaci
. . . . . . . . . . . . . . . . . . . . . .
16
4.2.2
Celkový pohled na administraci aplikace . . . . . . . . . . . . . . .
17
4.2.3
Celkový pohled na uºivatelskou £ást aplikace
. . . . . . . . . . . .
18
4.3
Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.4
Uºivatelské rozhraní
19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Popis implementace 5.1
Popis vlastního °e²ení
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.1.1
Webový server Apache . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.1.2
.htaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.1.3
Adresá°ová struktura . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.1.3.1
/con g
22
5.1.3.2
/modules
5.1.4 5.2
5.3
21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autentizace uºivatel·
23
. . . . . . . . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Fyzický datový model 5.2.1
customer
5.2.2
con guration
5.2.3
invoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.2.4
item
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2.5
owner
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2.6
user
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2.7
state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
AJAX
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
6 Testování
27
7 Záv¥r
29
Literatura
31
8 P°ílohy 8.1
8.2
33
Uºivatelská p°íru£ka
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
8.1.1
P°ihlá²ení do systému
. . . . . . . . . . . . . . . . . . . . . . . . .
33
8.1.2
Vytvo°ení faktury . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
8.1.3
B¥ºná práce s fakturami . . . . . . . . . . . . . . . . . . . . . . . .
34
8.1.4
Vyhledávání faktury
. . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
P°íru£ka administrátora 8.2.1
P°ihlá²ení do systému
8.2.2
Správa uºivatel·
. . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3
Editace faktura£ních údaj·
. . . . . . . . . . . . . . . . . . . . . .
36 36
8.2.4
Obecné nastavení . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
8.2.5
Log
37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Seznam obrázk· 4.1
Konceptuální datový model
. . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
Celkový pohled na aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3
Celkový pohled na administraci aplikace . . . . . . . . . . . . . . . . . . .
17
4.4
Celkový pohled na uºivatelskou £ást aplikace
. . . . . . . . . . . . . . . .
18
4.5
Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.1
Fyzický datový model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
8.1
P°ihlá²ení uºivatele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
8.2
Nová faktura
8.3
Nová zálohová faktura
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
8.4
Kalendá° . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
8.5
Da¬ové doklady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
8.6
Vyhledávání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
8.7
Správa uºivatel·
36
8.8
Editace faktura£ních údaj·
. . . . . . . . . . . . . . . . . . . . . . . . . .
36
8.9
Obecné nastavení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
8.10 Zobrazení logu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiii
33
37
xiv
SEZNAM OBRÁZK
Seznam tabulek 3.1
Analýza rizik
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
13
xvi
SEZNAM TABULEK
Kapitola 1
Úvod Cílem této práce je implementovat informa£ní systém pro správu faktur malé spole£nosti, který bude fungovat ve webovém prohlíºe£i. Celá aplikace je implementována ve skriptovacím jazyce PHP 5 s vyuºitím Zend Frameworku, který jako architektonický návrhový vzor pouºivá Model-View-Controller. Dále se v aplikaci pouºívá zna£kovací jazyk XHTML, kaskádové styly CSS a JavaScript také AJAX k zrychlení uºivatelského rozhraní. Aplikace umoº¬uje uºivatel·m vytvá°ení, editaci a mazání zálohových faktur i da¬ových doklad·. Klí£ovou funk£ností je jejich export do XHTML £i PDF formátu. V evidenci faktur je umoºn¥no vyhledávání, ozna£ení jiº zaplacených faktur a nebo také zm¥na jejich stavu (nevy°ízeno, odeslána dobírka, ...).
1
2
KAPITOLA 1. ÚVOD
Kapitola 2
Pouºité metodiky a technologie 2.1
Pouºitá metodika
2.1.1 Feature Driven Development K vývoji aplikace jsem vyuºil zásady metodiky Feature Driven Development (FDD) [1], která byla poprvé uvedena v roce 1999 v knize Java Modeling in Color with UML. Jedná se o agilní metodiku vývoje softwaru, která je zaloºena na iterativním vývoji. Agilní metodiky [2] jsou známy tím, ºe vývoj je rychlý, nezdrºuje se zbyte£n¥ dlouho u jednotlivých fází a zam¥°uje se zejména na dodání funk£ní aplikace. Metodika Feature Driven Development je navíc význa£ná tím, ºe povaºuje vlastnosti (funk£nosti) aplikace za nejd·leºit¥j²í. D·raz je kladen na maximalizaci produkce, které je docíleno tak, ºe celý vývoj je °ízen t¥mito vlastnostmi aplikace. Je vhodná p°edev²ím k vývoji men²ích aplikací, kde lze aplikaci snadn¥ji speci kovat souhrnem vlastností. Po£ítá se zde jen s men²ím prostorem pro zm¥ny poºadavk· b¥hem vývoje. D·leºitou £ástí vývoje dle FDD je také modelování. Metodika doporu£uje na za£átku vývoje vytvo°it celkový model aplikace, aby do²lo k ujasn¥ní rys· aplikace. FDD doporu£uje krátké iterace a £asté konzultace se zákazníkem. Je-li zákazníkovi pr·b¥ºn¥ p°edstavován vývoj, tak nem·ºe na jeho konci prohlásit, ºe dostal jiný produkt, neº jaký o£ekával. Vzhledem k tomu, ºe základním rysem vývoje jsou vlastnosti, lze snadno kontrolovat pr·b¥h vývoje. FDD dodává £asté a hmatatelné výsledky. Zákazník vidí pokroky v pr·b¥hu vývoje, m·ºe jej snadn¥ji ovliv¬ovat a posuzovat aktuální stav. FDD je postaveno na osv¥d£ených postupech známých z agilních metodik vývoje softwaru. Doporu£uje kombinaci následujících praktik, které dosahují t¥ch nejlep²ích výsledk·, kdyº se pouºijí v²echny zárove¬:
Doménové objektové modelování Doménový objektový model spo£ívá v prozkoumání a vysv¥tlení hlavního problému. Zpravidla je tvo°en UML diagramem t°íd v kombinaci se sekven£ními diagramy. Doménový model p°edstavuje celkovou podobu, do které se zasazuje funkcionalita jednotlivých vlastností. Jedná se o stru£ný a p°edev²ím v¥cný pohled na zp·sob uloºení a komunikace informací. 3
KAPITOLA 2. POUITÉ METODIKY A TECHNOLOGIE
4
Vývoj dle vlastností aplikace Hlavní my²lenkou je, ºe funk£ní poºadavky obsahují jen ty poºadavky, které pro zákazníka mají uºitnou hodnotu. Vlastnosti by m¥ly být dostate£n¥ malé na to, aby jejich implementace netrvala p°íli² dlouho a byly tedy m¥°itelnou jednotkou. V¥t²í vlastnosti by se m¥ly rozd¥lit na díl£í celky.
Vlastnictví t°íd U vlastnictví t°íd jde o to, aby kaºdá t°ída £i skupina t°íd byla p°i°azena ke konkrétní osob¥, která má za n¥ zodpov¥dnost. FDD prosazuje individuální vlastnictví zdrojových kód·. (nap°. Extrémní programování prosazuje kolektivní vlastnictví)
Týmy pro vlastnosti Dle pravidla vý²e vlastnictví t°íd, p°id¥líme jednotlivým t°ídám vlastníky a zárove¬ má mít kaºdá vlastnost aplikace p°id¥leného £lena týmu, který za ni bude mít zodpov¥dnost.
Inspekce Pravidelné inspekce slouºí k zaji²t¥ní vysoké kvality a nízké chybovosti aplikace.
Pravidelné buildy Jednotlivé vlastnosti se pravideln¥ dávají do jednoho celku. Takto lze zjistit p°ípadné integra£ní problémy co nejd°íve.
ízení kon gurací Jedná se o udrºování verzí zdrojových kód·, ale i dokument· se speci kací poºadavk·, testovacích p°ípad·, dokumentace apod.
Viditelnost pokroku a výsledk· Vzhledem ke koncepci této metodiky je zde snadná viditelnost pokroku a výsledk· díl£í práce. P°edev²ím díky rozd¥lení aplikace na její funk£ní vlastnosti.
2.2
P°ehled pouºitých technologií
2.2.1 Skriptovací jazyk PHP PHP je skriptovací programovací jazyk, který se pouºívá za ú£elem tvorby dynamických webových aplikací [4]. Jedná se o intepretovaný programovací jazyk. PHP skripty jsou provád¥ny na stran¥ serveru, uºivatel tedy dostane data aº po jejich zpracování. Tento skriptovací jazyk není závislý na konkrétní platform¥. Av²ak nej£ast¥ji se pouºívá pro provoz webových aplikací v kombinaci s Apache serverem, MySQL databází a opera£ním systémem Linux. Pro implementaci aplikace jsem pouºil PHP Verze 5.2.0.
2.2.2 Skriptovací jazyk JavaScript JavaScript je intepretovaný skriptovací programovací jazyk. Lze jej pouºívat jak na stran¥ klienta, tak i serveru. Je multiplatformní a obvykle se vkládá p°ímo do zdrojových kód· webových stránek, kde se zpracovává na stran¥ klienta (webového prohlíºe£e).
2.3. NÁVRHOVÝ VZOR MVC
5
2.2.2.1 AJAX AJAX (Asynchronous JavaScript and XML) je ozna£ením pro technologie, které vyuºívají objektu XMLHttpRequest, a to p°edev²ím k vývoji interaktivních webových aplikací. Nej£ast¥ji je pouºit AJAX tak, ºe webové aplikace m¥ní sv·j obsah bez znovuna£ítání stránek.
2.2.3 Rela£ní databáze MySQL MySQL je databázový systém, který je distribuován zejména pod bezplatnou GPL licencí. Jedná se o multiplaformní databázový systém, který je velmi oblíben a vyuºívá jazyka SQL. Podobn¥ jako nap°. u databázového systému MSSQL se jedná o dialekt SQL jazyka, který obsahuje n¥která speci cká roz²í°ení.
2.2.4 Webový server Apache HTTP Apache HTTP Server je multiplatformní webový server s otev°eným kódem (opensource). Jedná se o nejroz²í°en¥j²í webový server v·bec [3], který je vysoce kon gurovatelný. Disponuje podporou pro PHP, Perl a dal²í skriptovací jazyky. Pro Apache existuje velká °ada modul·, které roz²i°ují jeho funk£nosti.
2.3
Návrhový vzor MVC
Model-View-Controller (MVC) je návrhový vzor, který rozd¥luje aplikaci na t°i vzájemn¥ co nejmén¥ závislé komponenty datový model aplikace, uºivatelské rozhraní a °ídicí logiku. Cílem je, aby modi kace n¥které z nich m¥la jen minimální vliv na ostatní. Tím se zna£n¥ usnadní modi kace nejen v pr·b¥hu vývoje aplikace, ale také jsou zdrojové kódy celkov¥ p°ehledn¥j²í.
2.3.1 Model Jedná se o doménovou speci kaci dat, s nimiº aplikace pracuje. Jsou zde uvedeny operace s daty. Nutno podotknout, ºe Model se nezabývá tím, kde jsou data uloºena m·ºe tedy jít o rela£ní databázi, ale t°eba i o XML soubor.
2.3.2 View View se zabývá gra ckou reprezentací získaných dat. Je d·leºité zde zd·raznit, ºe se samotnými daty nikterak nepracuje (to je úkolem Modelu).
2.3.3 Controller Úkolem Controlleru je zajistit logickou £ást celého systému, slouºí jako prost°edník mezi Modelem a View. Zaji²´uje tedy p°edávání dat View získaných z Modelu. Controller p°ijímá události systému a zpracovává je.
KAPITOLA 2. POUITÉ METODIKY A TECHNOLOGIE
6
2.3.4 Zend Framework Zend Framework (ZF) [5] je open source, objektov¥ orientovaný framework implementovaný v programovacím jazyce PHP 5. Slouºí k vývoji webových aplikací a vyuºívá implementaci návrhového vzoru MVC. Sou£ásti ZF jsou tém¥° nezávislé, kaºdá sou£ást je vytvo°ena tak, aby závisela na co nejmen²ím po£tu ostatních sou£ástí. Vývoj ZF je pod zá²titou spole£nosti Zend Technologies Ltd. Doporu£ená adresá°ová struktura vypadá takto: /application /controllers /models /views /scripts /helpers / lters /library /public /css /images /js Adresá°e v
application
p°edstavují architekturu MVC. V library jsou uloºeny ve²keré
knihovny ZF a mohou se zde ukládat dal²í pot°ebné knihovny. Public je ve°ejný adresá°, proto obsahuje soubory jako kaskádové styly (CSS) nebo t°eba JavaScripty. Dále obsahuje hlavní soubor aplikace
index.php
tzv. bootstrap soubor.
2.3.4.1 Bootstrap Jak uº bylo zmín¥no, v adresá°i kterému se °íká
public
se nachází hlavní soubor aplikace (index.php),
bootstrap soubor. Konkrétn¥ v ZF je v souboru index.php include souboru, bootstrap.php. ZF je navrºen tak, ºe ve²keré poºadavky jsou sm¥rovány
který se jmenuje
práv¥ na tento soubor a dále aplikace se rozhodne jak s nimi naloºí. P°esm¥rování poºadavk· se provádí zpravidla pomocí kon gura£ního souboru Apache serveru ostatní servery se toto nastavení provádí jinak. P°íklad obsahu souboru
.htaccess :
# public/.htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ /index.php [NC,L]}
.htaccess. Pro
2.3. NÁVRHOVÝ VZOR MVC
APPLICATION_PATH, která ukazuje application. Ukazatel vyuºívají knihovny ZF uloºené v library.
V bootstrapu se zpravidla de nuje podadresá°·m v
7
cestu k
define('APPLICATION_PATH', realpath(dirname(__FILE__)) . '/../application'); Dále se nastaví AUTOLOADER, ten umoºní ZF na£íst t°ídy automaticky a uº nemusíme do jednotlivých PHP skript· psát direktivy include nebo require.
require_once "Zend/Loader.php"; Zend_Loader::registerAutoload(); Nastavení kon gura£ního souboru pomocí Zend_Con g_Ini. Jako parametry zadáváme cestu ke kon gura£nímu souboru a jakou sekci souboru chceme na£íst. Pokud nezadáme ºádnou cestu, na£tou se v²echny sekce. Kon gura£ní soubor m·ºe obsahovat nap°. informace o databázi (host, dbname, ...).
$config = new Zend_Config_Ini(APPLICATION_PATH.'/config/config.ini', 'section'); FrontController zajistí, ºe bude URL správn¥ p°eloºena a p°edána správnému controlleru. Druhý °ádek kódu nastaví výchozí cestu ke controller·m.
$frontController = Zend_Controller_Front::getInstance(); $frontController->setControllerDirectory('default' => APPLICATION_PATH .'/controllers');
2.3.4.2 Zend_View Tato t°ída pracuje s £ástí View z MVC. P°edpokládejme pouºití výchozího ZF view enginu (lze pouºít i t°eba Smarty ²ablonovací systém [6]). Nejd°íve si ukáºeme jak m·ºe vypadat script:
| Author | Title |
books as $book): ?> | author ?> | title ?> |
Vidíme for-cyklus, který do tabulky vypisuje autora a název knihy. Je to klasický PHP skript, aº na to, ºe se provádí uvnit° jedné Zend_View instance, tzn. ºe odkazy na $this ukazují na danou instanci Zend_View a její vlastnosti a metody. P°i $this->books p°edá Controller instanci View v²echny knihy v databázi.
KAPITOLA 2. POUITÉ METODIKY A TECHNOLOGIE
8
2.3.4.3 Zend_Controller Je jádrem ZF MVC systému. Jeho d·leºitou sou£ástí je Zend_Controller_Front. Dal²í sou£ástí je Zend_Controler_Action. Nyní si ukáºeme ukázku controlleru pro skript z p°edchozí £ásti:
/** Zend_Controller_Action */ class BookController extends Zend_Controller_Action { public function booklistAction() { $bookTable = new DbTable_Book(); $this->view->books = $bookTable->getBooks(); } } Vidíme zde t°ídu BookController, která slouºí jako controller pro view/scripts/book. Metoda booklistAction obsluhuje soubor view/scripts/book/booklist.phtml. Metoda si vytvo°í instanci t°ídy DbTable_Book, která reprezentuje tabulku Book v databázi. Zavolá metodu getBooks(), která na£te knihy z databáze. Nakonec jsou knihy metodou booklistAction uloºeny do books v dané instanci view a obsluha controlleru je hotova.
2.3.4.4 Zend_Db Zend_Db a její podt°ídy vytvá°í jednoduché SQL databázové rozhraní pro ZF. D·leºitou sou£ástí je Zend_Db_Adapter, který slouºí k p°ipojení databáze. Obsahuje podt°ídy pro r·zné typy databází (pdo_ibm, pdo_mysql, pdo_oci, ...). P°íklad p°ipojení MySQL databáze:
$db = new Zend_Db_Adapter_Pdo_Mysql(array( 'host' => '127.0.0.1', 'username' => 'user', 'password' => 'pass', 'dbname' => 'tests' )); Host, username, password a dbname jsou parametry konstruktoru. Tato instance t°ídy se vytvá°í zpravidla v bootstrap souboru. Dále je moºnost tyto informace na£íst p°ímo ze souboru con g.ini. Dal²í sou£ástí je Zend_Db_Table, t°ída pracující s °ádky tabulky jako s objekty. P°íklad vytvo°ení takové abstraktní tabulky bude op¥t navazovat na p°edchozí p°íklady:
class DbTable_Book extends Zend_Db_Table_Abstract{ public function getBooks(){ $rows = array(); $rows = $this->fetchAll($this->select() ->from('book', array('author', 'title'))); return $rows; } }
2.3. NÁVRHOVÝ VZOR MVC
9
Vidíme t°ídu Book, která byla v p°edchozím p°íkladu vytvo°ena uvnit° controlleru. Metoda getBooks() vytvo°í prom¥nnou rows, do které p°idá v²echny °ádky z tabulky a nakonec rows vrátí v dané instanci. Select() je obdobou SQL p°íkazu SELECT a obsahuje metody jako from, where £i order. FetchAll() pak vrátí vybrané °ádky jako hodnotu typu Zend_Db_Table_Rowset_Abstract.
2.3.4.5 Zend_Controller_Router_Rewrite Zend_Controller_Router_Rewrite je standardní router ZF. Routování je proces, p°i kterém se zpracovává koncová URI a dekomponuje se do parametr· k rozpoznání toho, který modul, controller a akce daného controlleru p°ijme tento poºadavek. P°íklad routování v ZF:
$route = new Zend_Controller_Router_Route( 'author/:username', array( 'controller' => 'profile', 'action' => 'userinfo' ) ); $router->addRoute('user', $route); První parametr konstruktoru je de nice routeru, která je p°i°azena k URL. Statické £ásti URL jsou odd¥leny lomítkem "/", dynamické pak dvojte£kou ":". Tomu tedy bude vyhovovat adresa ve tvaru http://domain.com/author/cokoliv. Coº bude obslouºeno controllerem
username
pro le
a jeho metodou
userinfoAction.
Této metod¥ bude p°edán parametr
- tedy uºivatelské jméno, které bylo zadáno v URL.
10
KAPITOLA 2. POUITÉ METODIKY A TECHNOLOGIE
Kapitola 3
Úvodní studie 3.1
Odborný £lánek
Systém pro správu faktur bude spl¬ovat následující funk£ní poºadavky.
Uºivatel se musí do systému nejd°íve p°ihlásit. Po úsp¥²ném p°ihlá²ení vidí seznam jiº vytvo°ených faktur. Tento výpis je rozd¥len do dvou tabulek (zálohové faktury a da¬ové doklady), z nichº kaºdá má své vlastní stránkování. Uºivatel bude moci výpis faktur ltrovat zadáním
vyhledávacího výrazu.
Seznam faktur bude obsahovat tyto údaje (v tomto po°adí zleva): variabilní symbol, zobrazit (HTML £i PDF verzi), datum vystavení, spole£nost / jméno p°íjmení, cena, zaplaceno (checkbox ano/ne), stav (formulá°ový select), akce (jen u zálohových faktur pro moºnost vytvo°ení nového da¬ového dokladu), jméno (jméno uºivatele, který provedl poslední zm¥ny), poznámka, editace a mazání.
faktury vytvá°et a to tak, ºe nejd°íve vybere, jestli zálohovou fakturu £i da¬ový doklad. Poté m·ºe jiº vyplnit faktura£ní údaje, kde bude moºnost p°idat dal²í °ádky faktury. Zde bude uºivateli umoºn¥no
chce vytvo°it
Dále v seznamu faktur bude umoºn¥no
PDF
zobrazovat
jejich náhledovou
HTML
£i
verzi k tisku. PDF se bude vytvá°et za b¥hu tedy nebude ukládáno trvale
zaplaceno, stav, vytvo°it da¬ový doklad (jedná-li se o zálohovou fakturu), editovat fakturu a mazat fakturu (lze pouze pokud je uºivatel administrátor).
na server. M¥nit
Administrátorovi
bude umoºn¥no vyuºívat v²echny vý²e uvedené funkce, které
administra£ním menu bude moci editovat globální nastavení, spravovat uºivatelské ú£ty, editovat faktura£ní údaje spole£nosti a prohlíºet/smazat log.
má uºivatel a navíc dále uvedené. Ve svém
Globální nastavení bude obsahovat editaci po£tu faktur na stránce (stránkování), editovat výchozí m¥nu, editovat výchozí zp·sob doru£ení i zaplacení. Editace faktura£ních údaj· spole£nosti bude umoº¬ovat nahrání loga spole£nosti faktura£ních údaj·.
a vypln¥ní
Správa uºivatelských ú£tu bude umoº¬ovat vytvo°ení nového uºivatele, editaci uºivatele a smazat uºivatele. 11
KAPITOLA 3. ÚVODNÍ STUDIE
12
3.2
Katalog poºadavk·
•
Lze vytvo°it libovolný po£et faktur.
•
Seznam faktur má stránkování po x poloºkách (dle globálního nastavení).
•
Faktury lze editovat.
•
Faktury lze zobrazovat v HTML formátu £i PDF.
•
O kaºdé faktu°e je uchováváno, zda-li jiº byla zaplacena £i nikoliv.
•
Tento seznam faktur je p°ístupný po p°ihlá²ení.
•
Rozli²ují se dv¥ úrovn¥ uºivatelských práv:
administrátor
∗ ∗ ∗ ∗
m·ºe editovat faktura£ní údaje má p°ístup k logu
m·ºe pln¥ spravovat faktury (krom¥ jejich mazání) jeho akce jsou ukládány do logu
Seznam faktur má globální nastavení, které obsahuje:
•
má p°ístup ke globálnímu nastavení
uºivatel
∗ ∗ •
m·ºe pln¥ spravovat faktury
moºnost nastavení výchozí m¥ny, státu, zp·sobu doru£ení i zaplacení a DPH nastavení kolik °ádk· s fakturami se má zobrazovat na jedné stránce stránkování
Z proformy lze vytvo°it da¬ový doklad
tj. zkopírují se údaje, implicitn¥ se nastaví údaj uhrazeno zálohou na vý²i proformy, tedy v da¬ovém dokladu pak bude k úhrad¥ 0,- K£
3.3 •
z proformy lze vytvo°it pouze jeden da¬ový doklad (k ní spjatý)
Nefunk£ní poºadavky Ve²keré tabulky budou vyuºívat vzhledu tablecloth (http://cssglobe.com/lab/tablecloth/) JavaScript
•
PHP 5 (OOP)
•
ZendFramework
MySQL databáze
InnoDB engine
•
Webový prohlíºe£
•
Pro zm¥nu stav· a zaplaceno (ano/ne) bude pouºit AJAX
3.4. ROZBOR ALTERNATIV
3.4
13
Rozbor alternativ
V jedné malé spole£nosti se potýkali s problémem, kde necht¥li vyuºívat bu¤to drahý a nebo p°íli² obsáhlý ú£etní systém, av²ak p°esto pot°ebovali aplikaci na správu faktur. Vzhledem k tomu, ºe v²ichni z dané spole£nosti nesedí fyzicky v kancelá°i, tak bylo pot°eba k fakturám p°istupovat online a to pouze prost°ednictvím webového prohlíºe£e bez nutnosti instalace dal²ího softwaru. Napojení na sklad by zde nem¥lo smysl, protoºe se prodává p°edev²ím software a sluºby. Vzhledem k tomu, ºe je trh zahlcen velmi komplexním softwarem v tomto odv¥tví, tak mi p°i²la moºnost vytvo°it n¥co nového, jednoduchého a zárove¬ velmi snadno pouºitelného jako nejlep²í moºnost.
3.5
Analýza rizik
Riziko
Kategorie
Pravd¥p.
Dopad
Ztráta dat
Technický, obchodní
5 %
Katastro cký
Nedorozum¥ní p°i speci kaci
Analýza, obchodní
30 %
Kritický
Nedostatky v analýze
Analýza
15 %
Kritický
Nedodrºení termín·
Vývojový tým
25 %
Kritický
Nedostate£ná dokumentace
Vývojový tým
15 %
Kritický
Chyby v implementaci
Vývojový tým
30 %
Kritický
Nedostate£ná kvali kace
Vývojový tým
20 %
Marginální
Tabulka 3.1: Analýza rizik
3.5.1 Ztráta dat Absolutní ztráta dat by byla velikou katastrofou, av²ak vzhledem k tomu, ºe budu provád¥t pravidelné zálohy celého projektu, je riziko zna£n¥ minimalizováno.
3.5.2 Nedorozum¥ní p°i speci kaci poºadavk· P°i speci kaci poºadavk· je moºné, ºe se ²patn¥ pochopíme s vedoucím projektu. Formou £astých konzultací se budu snaºit této nep°íjemnosti vyhnout.
3.5.3 Nedostatky v analýze P°i provád¥ní dal²ích krok· m·ºu dojít ke zji²t¥ní, ºe analýza nebyla vypracována zcela správn¥ a je tedy pot°eba ji zp¥tn¥ p°epracovat. K omezení tohoto rizika budu provád¥t vývoj iterativn¥ po díl£ích £ástech a analýzu v£as p°epracovávat, kdyº bude t°eba.
3.5.4 Nedodrºení termín· Nedodrºení harmonogramu se budu snaºit vyhnout rozloºením práce na díl£í celky a jejich postupnému vypracovávání - nikoliv nárazovou nep°edvídatelnou zát¥ºí.
KAPITOLA 3. ÚVODNÍ STUDIE
14
3.5.5 Nedostate£ná dokumentace Dostate£ná dokumentace musí být základem kaºdého projektu a musí být zformulována tak, aby i laik porozum¥l dané problematice. Toho chci docílit tak, ºe budu dokumentaci ukazovat osobám v dané problematice nevzd¥laným.
3.5.6 Chyby v implementaci Aby se minimalizovaly chyby, které m·ºu jako programátor v implementaci p°ehlédnout, budu £asto provád¥t testování aplikace.
3.5.7 Nedostate£ná kvali kace Nemusím mít vºdy pot°ebné znalosti a zku²enosti p°i °e²ení problém·, které mohou p°i projektu nastat. Problém je to v²ak pouze marginálního rozsahu, protoºe pot°ebné znalosti lze nastudovat.
3.6
Odhad ceny
Vzhledem k tomu, ºe se jedná o software, tak cena by v tomto p°ípad¥ byla dána jeho prodejcem. Co se tý£e ceny provozní, tak aplikaci lze provozovat na b¥ºném webhostingu, který lze v dne²ní dob¥ po°ídit t°eba za 79 K£ / m¥síc (http://www.banan.cz).
Kapitola 4
Analýza a návrh °e²ení 4.1
Konceptuální datový model
Obrázek 4.1: Konceptuální datový model
15
KAPITOLA 4. ANALÝZA A NÁVRH EENÍ
16
Na tomto konceptuálním datovém modelu lze vid¥t objekty v databázi a vztahy mezi
invoice), item), uºivatel (user), který fakturu
nimi z hlediska jejich významu a chování. Základem celého systému je faktura ( na kterou se váºou jednotlivé fakturované poloºky (
state), údaje o zákazníkovi, kterému byla fakcustomer) a kone£n¥ faktura£ní údaje vystavovatele (owner). Navíc je zde (con guration) slouºící k nastavení systému.
naposledy zm¥nil, aktuální stav faktury ( tura vystavena (
4.2
P°ípady pouºití (Use-Case)
P°ípady uºití zachycují funk£nost, která bude aplikací pokryta. Jsou navrhovány z pohledu zákazníka a podávají prvotní p°edstavu o rozsahu projektu. Nezabývá se technologií implementace a pouºívá pro zákazníka pochopitelný jazyk, který m·ºe být pouºit pro prezentaci aplikace. Diagramy pouºití rozli²ují aktéry, kte°í v aplikaci gurují.
4.2.1 Celkový pohled na aplikaci Toto je p°ípad pouºití na nejvy²²í úrovni. Lze zde vid¥t rozdíl mezi akcemi, které m·ºe provád¥t uºivatel a administrátor.
Obrázek 4.2: Celkový pohled na aplikaci
4.2. PÍPADY POUITÍ (USE-CASE)
17
4.2.2 Celkový pohled na administraci aplikace V tomto p°ípad¥ pouºití je znázorn¥na administra£ní £ást aplikace. Vymezuje, jaké operace m·ºe administrátor narozdíl od uºivatele provád¥t.
Obrázek 4.3: Celkový pohled na administraci aplikace
18
KAPITOLA 4. ANALÝZA A NÁVRH EENÍ
4.2.3 Celkový pohled na uºivatelskou £ást aplikace V tomto p°ípad¥ pouºití je znázorn¥na uºivatelská £ást aplikace.
Obrázek 4.4: Celkový pohled na uºivatelskou £ást aplikace
4.3. DIAGRAM NASAZENÍ
4.3
19
Diagram nasazení
Obrázek 4.5: Diagram nasazení
4.4
Uºivatelské rozhraní
Uºivatelské rozhraní zprost°edkovává uºivateli p°ístup k celé aplikaci. Tedy k implementovaným funkcím dle vý²e uvedených p°ípad· uºití. P°i vytvá°ení uºivatelského rozhraní jsem se °ídil níºe uvedenými zásadami. Vzhledem k tomu, ºe uºivatelské rozhraní je jediný zprost°edkovatel mezi aplikací a
p°ehlednost a jednoduchost. Zejména pak bylo dodrºovat zvyklosti, které jsou b¥ºné u webových apli-
uºivatelem, kladl jsem tedy d·raz na t°eba myslet na to, ºe je nutné
kací a také na to, ºe ovládání aplikace musí být co nejvíce intuitivní. P°edpokládá se, ºe s aplikací budou pracovat osoby, které nejsou technicky vzd¥lané. Do návrhu uºivatelského rozhraní byly zapracovány p°ipomínky uºivatel·, kte°í aplikaci testovali. Proto je po p°ihlá²ení na kaºdé stránce moºnost odhlásit se a vrátit se na úvodní stránku. Vzhledem k tomu, ºe v¥t²inu stránek v aplikaci tvo°í stránky s tabulkami, tak jsou v²echny formátovány
jednotným vzhledem.
Ve²keré hypertextové odkazy jsou
formátovány stejnou barvou a písmem. Je tedy na první pohled patrné, co je text a co je hypertextový odkaz. Tabulky s fakturami mají také na
rychlosti aplikace,
stránkování dat.
Coº velmi p°idává na p°ehlednosti a
protoºe by se p°ená²elo více a více dat, jak by faktury
p°ibývaly. Kolik záznam· se má na jedné stránce zobrazit lze nastavit v administrátorské
20
KAPITOLA 4. ANALÝZA A NÁVRH EENÍ
sekci. Pokud po£et záznam· tento po£et p°esáhne, tak se uºivateli zobrazí jednoduchá navigace, která mu bude umoº¬ovat snadno mezi stránkami procházet.
Kapitola 5
Popis implementace 5.1
Popis vlastního °e²ení
Aplikace je napsaná v programovacím jazyce PHP 5 s vyuºitím Zend Frameworku verze 1.7.5.
5.1.1 Webový server Apache K implementaci byl pouºit webový server Apache ve verzi Apache/2.2.3 (Debian). V kon gura£ním souboru serveru byl vytvo°en
VirtualHost
následujícím zp·sobem:
ServerName vk.solicad.com DocumentRoot /home/vk/www/public AllowOverride All
DocumentRoot, tedy ve°ejn¥ p°ístupný adresá°, je jen /public. Tudíº neAllowOverride All je povoleno pouºití kon gura£ního souboru .htaccess, kterým se následn¥ sm¥rují ve²keré poºadavky na bootD·leºité je, ºe
jsou p°ístupné zdrojové kódy aplikace. Direktivou strap soubor aplikace.
5.1.2 .htaccess Pouºitý kon gura£ní soubor
.htaccess :
# public/.htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ /index.php [NC,L] 21
KAPITOLA 5. POPIS IMPLEMENTACE
22
5.1.3 Adresá°ová struktura K implementaci jsem zvolil takovouto adresá°ovou strukturu:
/application /con g /modules /admin /default /controllers /layouts /models /views /library /public
V adresá°i
application
je celá vlastní aplikace. Následující
library
obsahuje
Zend, kde
jsou ve²keré knihovny frameworku a dal²í pot°ebné knihovny (nap°. knihovna dompdf, která je pouºita pro generování PDF soubor·). Ve°ejný adresá°
public s javascripty, views je adresá°
kaskádovými styly, souborem .htaccess a bootstrap souborem. V adresá°i
scripts
a v n¥m adresá°e s jednotlivými view (nap°. index.phtml).
5.1.3.1 /con g Zde jsou uloºeny kon gura£ní soubory. Zvolil jsem XML formát Kon gura£ní soubor pro p°ipojení k databázi (
database.xml ):
pdo_mysql <params> localhost <username>faktury <password>4QmE77wP9RuMTzEs faktury
routes.xml ):
Kon gura£ní soubor pro routování (
Zend_Con g_Xml.
5.1. POPIS VLASTNÍHO EENÍ
23
logout <defaults> auth logout index/:page <defaults> index index <page>1 První routa funguje tak, ºe jakmile je adresa ve tvaru http://www.aplikace.com/logout, tak se °ízení poºadavku p°edá controlleru
goutAction.
AuthController
Druhá routa slouºí ke stránkování. S tím, ºe
:page
a provede se jeho metoda
lo-
znamená, ºe se jedná o parametr.
Jako výchozí se zobrazí první stránka. Pokud máme adresu nap°íklad ve tvaru http://www.aplikace.com/index/index/page/2/type/invoice, tak se °ízení poºadavku p°edá controlleru
IndexController
a provede se jeho metoda
IndexAction, které budou p°edány
dal²í parametry: page = 2, type = invoice.
5.1.3.2 /modules default )
Aplikace je logicky rozd¥lena na dv¥ £ásti uºivatelskou (
a administrátorskou
admin ). P°i£emº kaºdá z nich obsahuje vlastní MVC implementaci.
(
5.1.4 Autentizace uºivatel· V adresá°i
library
je plugin
CheckLogin.php,
který slouºí k tomu, ºe zjistí, jestli je uºi-
vatel p°ihlá²en a jestli má oprávn¥ní pro vstup do daného modulu. Pakliºe ne, tak je p°esm¥rován na p°ihla²ovací obrazovku. Tento plugin se volá vºdy v hlavním controlleru
frontControlleru.
$frontController->registerPlugin(new My_Controller_Plugin_CheckLogin()); K samotné autentizaci je pouºit
AuthController. Autentizace je d¥laná tak, ºe pokud
uºivateli vypr²elo p°ihlá²ení, tak po p°ihlá²ení bude p°esm¥rován na jím poºadovanou adresu.
KAPITOLA 5. POPIS IMPLEMENTACE
24
5.2
Fyzický datový model
Obrázek 5.1: Fyzický datový model
5.2.1 customer Tabulka obsahující údaje o zákazníkovi. Sloupce
id
a
second_id
p°edstavují v £eském
jazyce I a DI.
5.2.2 con guration Zde je administrátorské nastavení systému. P°íklad záznamu: Výchozí stát,
value
key
= country,
name
=
= eská republika.
5.2.3 invoice Nejd·leºit¥j²í tabulka, která obsahuje údaje o jednotlivých fakturách. Sloupec
id_created_invoice
obsahuje id da¬ového dokladu, který byl vytvo°en z této zálohové
5.3. AJAX faktury. Sloupec
id_state
25
id_user
je uºivatel, který provedl ve faktu°e poslední zm¥ny. Sloupec
p°edstavuje stav, ve kterém se faktura práv¥ nachází. Sloupec
zákazník, kterému je faktura vystavována. Sloupec
id_owner
id_customer
je
ur£uje, které faktura£ní
type ur£uje, jestli se jedná o zálohovou fakturu (0) £i proforma_paid je £ástka, která jiº byla uhrazena zálohou.
údaje se k faktu°e váºou. Sloupec da¬ový doklad (1). Sloupec
5.2.4 item Tabulka obsahující údaje o fakturované poloºce. Sloupec
id_invoice
je faktura, ke které
se poloºka váºe.
5.2.5 owner Tabulka obsahující faktura£ní údaje. Sloupce I a DI. Sloupec Sloupec
tax_payer
footer_info
id
a
second_id
p°edstavují v £eském jazyce
obsahuje textový údaj, který se zobrazí v pati£ce faktury.
ur£uje, jestli se jedná o plátce £i neplátce DPH.
5.2.6 user Tabulka obsahující údaje o uºivatelích systému. Sloupec
password
obsahuje heslo v za²i-
frované podob¥ ²ifruje se jednosm¥rnou hashovací funkcí.
5.2.7 state Tabulka obsahující stavy, ve kterých se m·ºe faktura nacházet. Sloupec
css_class
p°ed-
stavuje název t°ídy kaskádového stylu, kterým bude daný stav v p°ehledu faktur podbarven.
5.3
AJAX
Pro zm¥nu stav· faktur (vy°ízeno, nevy°ízeno, ...) a zm¥nu zaplaceno / nezaplaceno jsem pouºil technologii AJAX. Uºivatel tedy m·ºe tyto stavy m¥nit, aniº by se mu znovu na£ítala celá stránka, coº vede k výraznému zrychlení práce. Zm¥na zaplaceno / nezaplaceno:
var xmlHttp; function createXMLHttpRequest(){ if(window.ActiveXObject){ xmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); } else if(window.XMLHttpRequest){ xmlHttp = new XMLHttpRequest(); } }
KAPITOLA 5. POPIS IMPLEMENTACE
26
function doRequestChangePaid(id_invoice, paid, idCheckbox, idSpan){ createXMLHttpRequest(); xmlHttp.open("POST", "/invoice/changepaid", true); xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); xmlHttp.send("state="+paid+"&id="+id_invoice); xmlHttp.onreadystatechange = function() { if(xmlHttp.readyState == 4) { changeValue(idCheckbox); changeClass(idSpan); } }; } function changeValue(idCheckbox){ if(idCheckbox.value == 1) idCheckbox.value = 0; else idCheckbox.value = 1; } function changeClass(idSpan){ if(idSpan.className=="border_red") idSpan.className="border_green"; else idSpan.className="border_red"; } Po provedení funkce doRequestChangePaid se zm¥ní v databázi zaplacení / nezaplacení faktury, zm¥ní se stav formulá°ového checkboxu a jeho CSS t°ída.
Kapitola 6
Testování Testování aplikace je £asto klí£ovým bodem vývoje. Testování softwaru se d¥lí na black box a white box testování. P°i£emº black box testování je takové, kdy se testuje dle scéná°· (daných vstup·) a kontroluje se shoda s o£ekávaným výstupem. Testující osoba netu²í, jak software funguje uvnit°. Vzhledem k povaze aplikace zde bylo zapot°ebí provád¥t zejména funkcionální testování, to také odpovídá konceptu zvolené metodiky vývoje softwaru Feature Driven Development.
Black box
metoda testování byla k testování tohoto softwaru pouºita n¥kolikrát.
Postupovalo se dle scéná°·:
Administrátor nastaví systém (jako malá spole£nost, poté jako osoba OSV). Uºivatel vytvo°í zálohové faktury. Následn¥ uºivatel vytvá°í da¬ové doklady, ov¥°uje údaje £i tiskne.
White box
testování je takové testování, kdy má testující p°ístup do zdrojových
kód· a rozumí tomu, jak aplikace funguje uvnit°. Tento druh test· jsem p°i vývoji d¥lal pravideln¥. Jednalo se o testování nov¥ naprogramovaných díl²ích £ástí a ov¥°ení funk£nosti jiº hotových £ástí. Ob¥ma metodama testování byly chyby nalezeny a odstran¥ny.
Test pouºitelnosti Vybral jsem 5 osob, které aplikaci vid¥ly poprvé. Zadal jsem jim b¥ºné úkony jako vytvo°it zálohovou fakturu, da¬ový doklad, vyhledat fakturu £i vytisknout. Podle výsledk· jsem upravil uºivatelské rozhraní.
Zát¥ºové testování Zát¥ºový test probíhal tak, ºe jsem do databáze vloºil 10 000 záznam· faktur a ke kaºdé n¥kolik fakturovaných poloºek. Následn¥ jsem zkou²el v aplikaci vyhledávat, listovat stránkami v tabulce a nastavit stránkování po jednom záznamu. Odezva aplikace byla kv·li zát¥ºi na databázi pomalej²í, ale po°ád se dala bez potíºí pouºívat.
27
KAPITOLA 6. TESTOVÁNÍ
28
Testování prob¥hlo na:
Webový server Apache/2.2.3 (Debian) Skriptovací jazyk PHP 5.2.0-8+etch13 Databázový systém MySQL 5.0.32
Webové prohlíºe£e:
Opera 9.50 Mozzila Firefox 2.0.0.20, 3.0.10 Microsoft Internet Explorer 6, 7, 8
Kapitola 7
Záv¥r Cílem práce bylo navrhnout a implementovat faktura£ní systém pro malé spole£nosti. Tento zám¥r se poda°ilo realizovat a také vyzkou²et aplikaci v praxi. Implementace v Zend Frameworku byla jednozna£n¥ vhodnou volbou. Díky £emuº je aplikace snadno modi kovatelná a kaºdý, kdo jiº má se Zend Frameworkem zku²enosti, by se v ní m¥l rychle zorientovat. Pokud aplikace bude uvedena do b¥ºného provozu, jist¥ za£nou vznikat nové podn¥ty na její roz²í°ení. Pak uº je na subjektivním posouzení, jestli ta £i ona vlastnost bude p°ínosem a zda ji zapracovat. P°edpokladem bylo, ºe aplikace pob¥ºí pouze ve remní lokální síti. Pro pouºití v internetu by ur£it¥ bylo t°eba implementovat p°ihla²ování p°es HTTPS, nutit uºivatele zadávat bezpe£ná hesla, blokovat útoky hrubou silou a logovat IP adresy. Aplikaci by bylo moºno roz²í°it o evidenci skladových zásob. Také se nabízí moºnost nade novat spole£nosti, kterým je faktura £asto vystavována, a ty si pak moci snadno vybrat ze seznamu. Moºná by se v administraci ujala moºnost de novat si vlastní stavy faktur.
29
30
KAPITOLA 7. ZÁV
R
Literatura [1] A. Buchalcevová. Metodika Feature-driven development neopou²tí modelování a procesy, a p°esto p°iná²í výhody agilního vývoje.
Tvorba softwaru 2005,
pages 2530,
2005. [2] V. Kadlec.
Agilní programování.
Computer Press, a.s., Nám. 28. dubna 48, 635 00
Brno, 2004. [3] J. K. Mohammed.
Apache Server 2.
Computer Press, a.s., Nám. 28. dubna 48, 635
00 Brno, 2004. [4] L. Ullman.
PHP a MySQL.
Computer Press, a.s., Nám. 28. dubna 48, 635 00 Brno,
2004. [5] Manuálové stránky Zend Frameworku.
http://www.zendframework.com/manual/en/. [6] O ciální webové stránky ²ablonového systému Smarty.
http://www.smarty.net/.
31
32
LITERATURA
Kapitola 8
P°ílohy 8.1
Uºivatelská p°íru£ka
8.1.1 P°ihlá²ení do systému Po otev°ení aplikace ve webovém prohlíºe£i se uºivateli zobrazí formulá°, kde vyplní své p°ihla²ovací jméno a heslo. Jakmile se p°ihlá²ení zda°í, tak je uºivatel p°esm¥rován na hlavní stránku aplikace.
Obrázek 8.1: P°ihlá²ení uºivatele
8.1.2 Vytvo°ení faktury Nová zálohová faktura a Nový da¬ový doklad. Pro vytvo°ení poºadované faktury je t°eba kliknout na p°íslu²né tla£ítko. Na hlavní stránce aplikace jsou dv¥ formulá°ová tla£ítka:
Obrázek 8.2: Nová faktura Následn¥ vyplnit faktura£ní údaje. Tu£né údaje jsou pro daný typ faktury povinné. Poloºka
Poznámka
se zobrazuje po vytvo°ení faktury jen v aplikaci, nikoliv na samotné
faktu°e. Dále je pot°eba vyplnit poloºky faktury, tj. jednotlivé °ádky na faktu°e. Pro více °ádk· slouºí tla£ítko: "P°idat °ádek". Zadává se cena za jednu poloºku bez DPH. Bude-li po£et poloºek jiný neº jedna, tak bude výsledná fakturována cena vypo£ítána. Kaºdá poloºka faktury m·ºe mít jiné DPH. 33
KAPITOLA 8. PÍLOHY
34
Variabilní symboly se generují zcela automaticky. Zálohové faktury jsou £íslovány ve formátu 5XXXXXXXYY. P°i£emº X je £íselná °ada a YY rok, ke kterému se daná £íselná °ada vztahuje. Da¬ové doklady se li²í jen tím, ºe za£ínají £íslem 1 a samoz°ejm¥ mají vlastní £íselnou °adu.
Obrázek 8.3: Nová zálohová faktura Pro zadávání datum· lze vyuºít kalendá°, který se zobrazí po kliknutí na obrázek, který je vpravo od formulá°ového pole.
8.1.3 B¥ºná práce s fakturami Na hlavní stránce aplikace se nejnov¥j²í faktury (dle po°adí vytvo°ení) °adí do dvou
Zálohové faktury a Da¬ové doklady. Kaºdá tabulka má vlastní stránkování. Kaºdou fakturu lze zobrazit ve dvou formátech: pdf (k tisku) a html (rychlý náhled), £emuº odpovídají stejnojmenné odkazy. Kaºdou fakturu lze editovat odkaz editovat. tabulek:
Máte-li v aplikaci administrátorské právo, tak lze faktury i p°ímo z tabulky mazat odkaz
X.
Ve sloupci
Zaplaceno
lze vid¥t, jestli faktura byla jiº zaplacena £i nikoliv a klikem
do tohoto formulá°ového pole lze zaplaceno / nezaplaceno m¥nit. Stejným zp·sobem
8.2. PÍRUKA ADMINISTRÁTORA
35
Obrázek 8.4: Kalendá°
funguje sloupec
Stav reprezentující, v jakém je faktura stavu (nevy°ízeno, odeslána zál.
f., odeslána dobírka, vy°ízeno). Ve²kerá práce s fakturami je ukládana do souboru, ke kterému má p°ístup administrátor aplikace. U jednotlivých faktur se zobrazuje jen autor poslední zm¥ny.
Obrázek 8.5: Da¬ové doklady
8.1.4 Vyhledávání faktury Na hlavní stránce aplikace je formulá° s názvem zadat výraz k vyhledávání a stisknout tla£ítko
ok.
Vyhledávání.
Sta£í do tohoto pole
Vyhledává se v názvech spole£ností,
k°estním jménu, p°íjmení, I spole£nosti a také v poloºce variabilního symbolu. Pro zru²ení aktuálního vyhledávání jednodu²e pole vyhledávací pole prázdné a stiskn¥te tla£ítko
ok.
výraz
nechte
Obrázek 8.6: Vyhledávání
8.2
P°íru£ka administrátora
8.2.1 P°ihlá²ení do systému Administrátor se m·ºe do systému p°ihlásit i jako b¥ºný uºivatel (viz. P°íru£ka uºivatele). Po otev°ení aplikace ve webovém prohlíºe£i je nutno p°ipsat do webové adresy /admin. Coº m·ºe vypadat n¥jak takto: http://www.vase-faktury.cz/admin.
KAPITOLA 8. PÍLOHY
36
8.2.2 Správa uºivatel· Ve správ¥ uºivatel· lze vytvá°et nové uºivatele po kliknutí na odkaz
uºivatele
Vytvo°it nového
a vypln¥ní formulá°e. Krom¥ standardních údaj· je ve formulá°i moºnost
za²krtnout, jestli uºivatel bude administrátor £i nikoliv. Dále je zde moºnost u kaºdého uºivatele
editovat a smazat. Administrátor nem·ºe smazat sám sebe.
Obrázek 8.7: Správa uºivatel·
8.2.3 Editace faktura£ních údaj· Zde m·ºe administrátor m¥nit faktura£ní údaje. Tyto údaje se nezm¥ní ve stávajících fakturách, ale pouze v nov¥ vytvo°ených. Tu£né údaje jsou povinné. Je zde moºnost nahrát logo, které se bude zobrazovat v hlavi£ce faktury. Vhodné rozm¥ry jsou 145 x 37 pixel·. V¥t²í rozm¥ry se nemusí zobrazit v PDF formátu vhodn¥ k tisku. Jestliºe logo nechcete v·bec, tak sta£í za²krtnout polí£ko
Plátce DPH, kdyº Neplátce DPH.
Bez loga.
Také je zde moºnost za²krnout
tento údaj není za²krtnout, tak se ve faktu°e navíc objeví text
Obrázek 8.8: Editace faktura£ních údaj·
8.2.4 Obecné nastavení V obecném nastavení se m¥ní výchozí údaje ve fakturách (výchozí m¥na, výchozí stát, ...,) a po£et faktur, který se zobrazí najednou v tabulce po kolika záznamech stránkovat.
8.2. PÍRUKA ADMINISTRÁTORA
37
Obrázek 8.9: Obecné nastavení
8.2.5 Log Zde lze vid¥t jednotlivé uºivatelské akce (nejnov¥j²í dole). Také je zde moºnost aktuální p°ehled záznam· vymazat
Smazat log.
Obrázek 8.10: Zobrazení logu
