České vysoké učení technické v Praze
Fakulta Elektrotechnická
Bakalářská práce Informační systém pro cestovní agenturu Radek Jedlička
Vedoucí práce: doc. Ing. Ivan Jelínek, CSc. Studijní program: Softwarové technologie a management Obor: Web a multimédia
květen 2010
2
Zadání Analýza požadavků na IS pro cestovní agenturu. Zjištění požadavků potenciálních zákazníků s respektováním konkurence na trhu. Návrh webového portálu s uživatelsky přívětivým rozhraním pro přístup k IS. Implementace IS a optimalizace pomocí SEO metod. Návrh uživatelských testů a test funkčnosti a přístupnosti k IS, kontrola splnění požadavků na IS.
3
4
Poděkování Poděkování patří všem, kteří mě podporovali při mém dlouhém studiu. Dík patří také mně za to odhodlání, vůli a trpělivost dotáhnout studium do konce.
5
6
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu.
V Praze dne...............................
7
...............................
8
Abstract This thesis deals with the analysis of requirements, the recognition of the needs of the users and a following implementation and testing of the information system for travel agencies. The first part of the work deals with the analysis of the requirements for the information system. The second part deals with the analysis of the requirements from potencial customers. The third part deals with the construction and the implementation of the system. The last part of the work deals with the testing of the system.
Abstrakt Tato práce se zabývá analýzou požadavků, zjištěním potřeb uživatelů a následnou implementací a testování informačního systému pro cestovní agenturu. První část práce se bude zabývat analýzou požadavků na informační systém. Druhá část bude vyhraněna pro zjištění požadavků potenciálních zákazníků. Třetí část se týká návrhu a implementace systému. Poslední část se zaměří na testování vytvořené aplikace.
9
10
Obsah Kapitola 1.Úvod.................................................................................................................................14 Kapitola 2.Analýza požadavků na IS.................................................................................................15 2.1.Účel a cíl IS..............................................................................................................................15 2.2.Rozdělení uživatelských rolí....................................................................................................15 a) Role webmaster.....................................................................................................................15 b) Role redaktor, správce obsahu..............................................................................................16 c) Role běžný uživatel internetu................................................................................................16 2.3.Funkční požadavky veřejné části IS........................................................................................16 a) Prohlížení nabídek zájezdů...................................................................................................16 b) Vyhledávání zájezdu.............................................................................................................17 c) On-line rezervace zájezdu.....................................................................................................17 2.4.Funkční požadavky neveřejné části systému...........................................................................17 a) Správa zájezdů......................................................................................................................17 b) Správa dalšího obsahu..........................................................................................................18 c) Správa klientů a smluv..........................................................................................................18 d) Statistiky...............................................................................................................................18 e) Správa přístupových práv.....................................................................................................19 2.5.Nefunkční požadavky..............................................................................................................19 a) Softwarové požadavky..........................................................................................................19 b) Hardwarové požadavky........................................................................................................20 c) Požadavky na přístupnost webu............................................................................................20 d) Ostatní požadavky................................................................................................................20 Kapitola 3.Zjištění požadavků potenciálních zákazníků....................................................................22 3.1.Potenciální zákazník................................................................................................................22 3.2.Redakční systém......................................................................................................................22 a) Správa obsahu.......................................................................................................................22 b) Správa stránek.......................................................................................................................22 c) Správa menu..........................................................................................................................22 d) Sidebox.................................................................................................................................23 e) Aktuality................................................................................................................................23 f) Newsletter..............................................................................................................................23 g) Odběratelé newsletteru.........................................................................................................23 3.3.Správa nabídky zájezdů...........................................................................................................24 a) Nastavení CK........................................................................................................................24 b) Import nabídek CK...............................................................................................................24 c) Vlastní nabídky.....................................................................................................................24 d) Správa zemí..........................................................................................................................24 e) Správa destinací....................................................................................................................25 f) Správa ubytování...................................................................................................................25 3.4.Správa zákazníků.....................................................................................................................25 a) Klienti...................................................................................................................................25 b) Smlouvy................................................................................................................................25 3.5.Management uživatelů IS........................................................................................................25 a) Uživatelé...............................................................................................................................26 3.6.Statistiky a logy.......................................................................................................................26 a) Logování změn......................................................................................................................26 11
b) Statistiky zájezdů..................................................................................................................26 Kapitola 4.Návrh pro implementaci...................................................................................................27 4.1.Relační datový model..............................................................................................................27 a) Správa zájezdů......................................................................................................................28 b) Správa klientů.......................................................................................................................30 c) CMS......................................................................................................................................31 4.2.Návrh uživatelského rozhraní..................................................................................................32 a) Návrh hlavní stránky.............................................................................................................33 b) Návrh podstránek..................................................................................................................34 c) Návrh administračního rozhraní............................................................................................35 4.3.Návrh programové části...........................................................................................................35 a) Framework JWork.................................................................................................................36 b) Databáze MySQL.................................................................................................................36 c) SEO optimalizace..................................................................................................................36 Kapitola 5.Implementace....................................................................................................................38 5.1.Použité technologie..................................................................................................................38 a) Apache HTTP server.............................................................................................................38 b) PHP.......................................................................................................................................38 c) MySQL.................................................................................................................................38 5.2.Použité aplikace.......................................................................................................................39 a) Vývojové prostředí Eclipse...................................................................................................39 b) phpmyadmin.........................................................................................................................39 c) Adobe Photoshop CS 4.........................................................................................................39 d) DB Designer 4......................................................................................................................39 e) Mozilla Firefox.....................................................................................................................39 f) Ostatní internetové prohlížeče...............................................................................................40 5.3.Postup implementace...............................................................................................................40 a) Vytvoření databázového modelu...........................................................................................40 b) Naplnění databáze daty.........................................................................................................40 c) Vytvoření grafické šablony...................................................................................................40 d) Kódování HTML šablony.....................................................................................................40 e) Instalace frameworku jWork.................................................................................................41 f) Programování modulů...........................................................................................................41 Kapitola 6.Testování...........................................................................................................................43 6.1.Testování z hlediska bezpečnosti systému...............................................................................43 a) Testování na Cross Site Scripting.........................................................................................43 b) Testování na SQL injection...................................................................................................43 6.2.Testování přístupnosti systému................................................................................................44 a) Testování IS zrakově postiženými uživateli..........................................................................44 b) Testování vypnutí kaskádových stylů a obrázků..................................................................44 c) Testování v různých prohlížečích..........................................................................................44 d) Testování vypnutého javascriptu a cookies...........................................................................45 Kapitola 7.Závěr.................................................................................................................................46 Kapitola 8.Použitá literatura...............................................................................................................47
12
Seznam použitých obrázků Obrázek 1: Datová struktura správy zájezdů......................................................................................28 Obrázek 2: Datová struktura správy klientů.......................................................................................30 Obrázek 3: Datová struktura CMS.....................................................................................................31 Obrázek 4: Návrh uživatelského rozhraní hlavní stránky..................................................................33 Obrázek 5: Návrh uživatelského rozhraní podstránky.......................................................................34 Obrázek 6: Návrh uživatelského rozhraní administrace.....................................................................35
13
Seznam zkratek a pojmů IS (informační systém), CA (cestovní agentura), CK (cestovní kancelář), CMS (content management system), API (application programming interface), SEO (search engine optimalization), HTML (hypertext markup language), CSS (cascading style sheets), PHP (hypertext preprocessor), URL (uniform resource locator), SQL (structured query language), W3C (world wide web consortium), MS (Microsoft), IE (Internet Explorer), XSS (cross site scripting).
14
Kapitola 1.Úvod Název mé bakalářské práce je informační systém pro cestovní agentury. Informační systémy se v posledních letech stávají stále více nepostradatelnější součástí každého podniku. Všechny cestovní agentury musí nějakým způsobem udržovat informace o nabídkách svých zájezdů, klientech, uzavřených smlouvách apod.. A tyto data v ucelené podobě poskytovat prostřednictvím internetu, nebo jiným informačním médiem svým potenciálním klientům. A to je hlavní účel, proč se informační systémy používají. Cílem této práce je navrhnout webovou aplikaci pro cestovní agentury, která jim umožní přímý prodej zájezdů, případně dalších služeb, prostřednictvím webového portálu. Cestovní agentura si sama bude schopna aktualizovat a přizpůsobovat svojí nabídku na internetu. A to prostřednictvím zabudovaného redakčního systému. Druhým cílem je realizace této aplikace. Naprogramování, vytvoření grafickému uživatelského rozhraní a optimalizace pro internetové vyhledávače. V úvodních nezbytných teoretických částech se chci věnovat analýze problému a ujasnit si základní požadavky na takový systém. Jasně definuji účel systému a také skupiny lidí, kteří s ním budou pracovat, nebo ho budou nějakým způsobem používat. V této analytické pasáži také specifikuji funkční požadavky, tedy funkce, které se od systému očekávají, že bude umět. Dále se zaměříme na to, kdo bude přímý potenciální zákazník systému a jsou jeho požadavky na systém. Druhá polovina práce se bude věnovat samotnému vývoji reálného systému. Vycházet přitom budeme z analytické části práce. Do systému bych měl implementovat všechny požadavky a to tak, aby výsledná aplikace splnila svůj předem jasně daný cíl. Po dokončení vývoje přijde na řadu testování systému a odstraňování nalezených nedostatků. Závěr bude obsahovat celkové zhodnocení, výsledky testování, možnosti nasazení vytvořeného IS do praxe a jeho dalšího rozšiřování a zdokonalování.
15
Kapitola 2.Analýza požadavků na IS Úvodní část, analýza požadavků. Ujasníme si nejdůležitější vstupní informace pro vývoj úspěšného a fungujícího IS. Nejprve stanovíme cíl a smysl celého systému. Dále pak se zaměříme na funkční požadavky uživatelů, kteří budou systém používat a nakonec zanalyzujeme technické, neboli nefunkční požadavky na systém.
2.1.Účel a cíl IS Účelem a cílem tohoto systému je jednoduchým způsobem umožnit CA prodej zájezdů po internetu. A to takovým způsobem, abychom celý proces prodeje pokud možno co nejvíce zautomatizovali. Jak ze strany provozovatele IS, tak ze strany internetového uživatele využívající služeb systému. Dalším cílem je uceleně spravovat veškerá data cestovní agentury. Ať jsou to informace o zájezdech, klientech, uzavřených smlouvách, statistikách či jiných vnitřních záležitostech. Cílem také je navrhnout pro klienty co nejefektivnější řešení v poměru cena / výkon. Rozhodně nechceme od systému, aby na trhu konkuroval svou rozsáhlou funkčností, kterou nabízí jiné firmy v podobě řešení na míru. Konkurovat bude především rychlou instalací, technickou dostupností a cenou.
2.2.Rozdělení uživatelských rolí Definujeme tři skupiny uživatelských rolí, které budou IS využívat. Každá role vykazuje určité obecné charakteristiky člověka a přesný účel, možnosti a omezení v užívání systému. Ujasnění si kdo se systémem bude pracovat je nezbytné provést ještě před samotnou analýzou požadavků. a) Role webmaster Role webmaster, neboli technický správce systému. Technicky vzdělaný člověk, nebo tým lidí. Kromě technického vzdělání tato funkce vyžaduje také zkušenosti a praxi v oboru webových technologií. Programování, práce s databází, HTML kódování a další. Podrobná znalost systému nutností. Má plný přístup ke zdrojovým kódům, databáze i do redakčního systému.
16
Jeho úkolem je zajišťovat bezchybný provoz, rozšiřovat a vylepšovat aplikaci dle požadavků ze strany provozovatele. Je odpovědný za správnou funkčnost celého IS. b) Role redaktor, správce obsahu Redaktor, správce obsahu, je člověk vyškolený pro uživatelské používání IS. Není nutná žádná technická znalost, ale tento člověk by měl být seznámen s prostředím CA, která systém využívá. Má přístup do redakčního systému a může plně využívat všech jeho funkcí. Vyžaduje přihlášení. Jeho úkolem je starat se o obsah na webovém portálu. Přidávat a aktualizovat zájezdy, psát novinky apod.. Zodpovídá za korektnost těchto informací. c) Role běžný uživatel internetu Běžný uživatel internetu, bez omezení věku, vzdělání, s různou technickou zdatností a znalostí internetu. Nemá zrakové ani jiné postižení, které by ho omezovalo v prohlížení internetového obsahu. Má možnost přístupu pouze k prohlížení webového portálu, kde listuje zájezdy, je upozorňován na různé akce atd.. Nejčastější důvod používání systému je hledání a nákup zájezdu. Případně jeho objednání.
2.3.Funkční požadavky veřejné části IS Funkční požadavky veřejné části IS obsahují přehled všech funkcí a možností systému, které může provádět běžný uživatel internetu, tedy návštěvník webového portálu. Požadavky soustředíme na to podstatné. Rychle a snadno vyhledat informace, které potřebuji. Prohlédnout, objednat. Soustředíme se na cíl uživatele a veškeré druhotné, byť třeba také užitečné, funkce ignorujeme. a) Prohlížení nabídek zájezdů Prohlížení nabídek zájezdů je tím nejčastějším důvodem, proč uživatel vstoupil na náš webový portál. Zajímá ho naše nabídka. V nabídce se zaměříme na informace, které jsou pro lidi nejzajímavější. Tím jsou hlavně velké obrazové informace jakými mohou být fotografie destinací. Zvýrazníme cenu, lákadla zájezdu a další nejdůležitější informace pro větší přehlednost. 17
Každý zájezd bude rozkliknutelný do jeho plného detailu s možností okamžité on-line nebo telefonické objednávky. b) Vyhledávání zájezdu Vyhledávání zájezdů, by uživatelům vždy mělo být dostupno několika různými způsoby. Vycházíme z toho, že každý uživatel je jinak zvyklý a má své oblíbené a jemu osvědčené způsoby. Nejběžnějším způsobem je vyhledávání zájezdů podle nabídky menu. Ta může být různě strukturována. Nejčastěji podle destinací, nebo typu zájezdu. Další možností je využít vyhledávajícího formuláře pro vyfiltrování všech zájezdů vyhovující našim požadavkům. Tento způsob více využívají uživatele, kteří mají představu co konkrétně hledají. c) On-line rezervace zájezdu On line rezervace zájezdu je dnes zcela standardním požadavkem uživatelů internetu, kteří přes internet nakupují zboží nebo služby. Po vybrání zájezdu se zobrazí formulář k vyplnění osobních a kontaktních údajů uživatele, který se odešle do rezervačního systému.
2.4.Funkční požadavky neveřejné části systému Funkční požadavky neveřejné části systému zahrnují přehled všech funkcí, které lze provádět po přihlášení se do systému. Možnost přihlášení bude mít pouze webmaster, nebo reaktor/správce IS. Většina funkcí bude přímo pracovat s databází systému. a) Správa zájezdů Správa zájezdů umožňuje měnit, přidávat a odebírat zájezdy do databáze IS. Přidávat zájezdy může manuálně, nebo automaticky pomocí importu zájezdů z jiného zdroje. Aktualizace a mazání bude probíhat manuálně. Zájezdům bude možnost přiřazovat různý stav. Určíme tak, které z nich se mají zobrazit na hlavní stránce, nebo na předních místech ve vyhledávání, nebo naopak které se nemají zobrazit vůbec. Zájezdům přiřazujeme termíny. Termín může být volný nebo obsazený. Termíny se mohou
18
odlišovat v délce, datu odjezdu a příjezdu a také v ceně. Zájezdům dále nastavujeme další atributy jako je typ dopravy, místa odjezdu, typ stravování, cestovní agenturu, typ a místo ubytování. b) Správa dalšího obsahu Správa dalšího obsahu zahrnuje správu všech obsahových sdělení včetně správy navigace webu. Můžeme měnit strukturu, podstránky, všechny obsahové části webu s vy jímkou informací o zájezdech. Vytváříme a měníme strukturu stránek a podstránek webu. Ke každé stránce můžeme přiřazovat libovolný počet podstránek s libovolným počtem zanoření. Měníme typ stránky. Vytváříme nové boxíky, které umíme přiřazovat k jednotlivým stránkám nebo podstránkám. Každý boxík můžeme přiřadit k jedné čí více stránek. Na jedné stránce může být více boxíků. Psaní a publikace aktualit. U každé aktuality nastavujeme zda se má nebo nemá zobrazit na webu čímž udržujeme aktuálnost. Vytváříme newsletter, který dále posíláme registrovaným nebo vybraným klientům. Registrujeme všechny provedené změny v IS a ukládáme je do databáze. U každé změny evidujeme uživatele, které je provedl. c) Správa klientů a smluv Správa klientů a smluv obsahuje přehled rezervací, uzavřených smluv a klientů, kteří tyto úkony provedly. Můžeme zde měnit stav rezervací a smluv podle toho zda je smlouva před uzavřením, nebo po uzavření. Ke klientům přiřazujeme libovolné poznámky a můžeme aktualizovat jejich osobní údaje. d) Statistiky Statistiky zahrnují přehledně řazené sledované údaje. zaměříme se především na ty obchodní údaje. Přehled o tom, kolik zájezdů je v nabídce, kolikrát byl zájezd prohlížen, kolik a které zájezdy byly rezervovány a kolik se nakonec uzavřelo smluv s klienty. Statistiky je možno pouze prohlížet, nebo vynulovat na počáteční stav.
19
e) Správa přístupových práv Správa přístupových práv umožňuje nastavovat autorizační práva pro přístup do redakčního systému. Můžeme přidávat, nebo odebírat správce systému. Správce systému můžeme nastavit zda jsou nebo nejsou aktivní. Neaktivní správci nemají přístup do systému.
2.5.Nefunkční požadavky Nefunkční požadavky zahrnují nutné technické prostředky pro fungování systému. Požadavky dělíme na softwarové, hardwarové, požadavky na přístupnost webu a na ostatní. a) Softwarové požadavky Softwarovými požadavky myslíme programové vybavení serveru a klienta. Server je počítač, na kterém systém běží. Klientem rozumíme běžný osobní počítač, na kterém chceme spouštět IS. Důraz je kladen na co nejnižší zřizovací a provozní náklady. Systém proto poběží na open source technologiích. Na serveru musí být nainstalován HTTP server apache s povoleným mod rewrite pro krásné URL. Webmaster musí mít možnost nastavit některé další důležité parametry serveru, které jsou specifické pro konkretní nasazené IS. IS bude naprogramován v PHP verze pět, která na rozdíl od starších verzí má dostatečnou podporu objektově orientovaného programování. Webmaster má opět přístup k nastavení proměnných prostředí. Pro uchování dat bude možno využít libovolnou databázi, kterou IS bude podporovat. Pro začátek počítáme s podporou MySQL, ale ponecháváme zde možnost bezproblémového rozšíření na kteroukoliv jinou databázi. Pro správu a přístup do databáze je nutné mít k dispozici dodatečný software. V našem případě to bude phpmyadmin. Všechny výše uvedené technologie jsou multiplatformní, je tedy možno je provozovat na operačních systémech Windows, libovolné distribuci Linuxu či serverech Solaris. Klient bude pouze potřebovat libovolný moderní webový prohlížeč a pro pohodlnější práci s podporou zapnutého JavaScriptu a cookies.
20
b) Hardwarové požadavky Hardwarové požadavky na chod IS nejsou nikterak náročné ani na straně serveru, ani na straně klienta. Systém počítá s nasazením na servery zavedených hostingových společností, kterých je dostatečný výběr. Přitom se neklade velký důraz na rychlou odezvu. Je proto možné využít i zahraničních hostingových serverů, které bývají cenově dostupnější a pro klienta tak výhodnější. Tyto servery mají více než dostatečnou výpočetní kapacitu pro běh serveru apache a jeho modulů. Bývají napojeny přímo na páteřní síť internetu, čímž se prakticky vyřeší rychlost načítání webu i při větším množství návštěvníků ve špičkách provozu. Při výběru hostingové společnosti doporučujeme klást důraz především na dostupnost, protože zde každý sebemenší výpadek může znamenat ztrátu zákazníka. Uživatelům opět postačí libovolné PC či notebook s nainstalovaným moderním internetovým prohlížečem. Podporu pro další zařízení jako jsou mobilní telefony či PDA neplánujeme. c) Požadavky na přístupnost webu Požadavky na přístupnost webu se odvíjí jak od grafického návrhu, tak od funkční implementace. Grafický návrh bude klást důraz na čitelnost, dostatečný kontrast fontu a pozadí, vhodný výběr typu a velikosti fontu. Barevně bude webové rozhraní sladěno tak, aby nedráždilo zrak a neodvádělo pozornost od obsahu. IS počítá s podporou JavaScriptu. Jeno cílem je uživatelům co nejvíce zpříjemňovat práci s webem, zejména interakci s formuláři. Validace formulářů, upozorňování na chyby a jejich zvýrazňování. Vypnutí JavaScriptu nesmí znemožňovat použití žádných funkcí IS. d) Ostatní požadavky Mezi ostatní požadavky patří optimalizace pro vyhledávače, SEO. Zahrnuje hezké URL, vkládání klíčových slov do URL a do titulků stránek. Dodržení sémantiky HTML a CSS kódu při kódování šablon stránek. Dalším požadavkem na chod systému je nutnost zřízení domény, na které bude systém
21
dostupný. Doporučujeme registrovat pečlivě zvolenou doménu druhého řádu. Dnes je problém najít zajímavou volnou doménu, často se tedy musíme spokojit s méně poutající alternativou, nebo zkusit štěstí a lukrativnější doménu odkoupit od jejího majitele. Posledním požadavkem je zkušený webmaster. Musí si umět poradit s nasazení a technickou správu IS, dokáže pracovat s databází, zálohovat systém, kontrolovat běh a řešit problémy v případě výpadků.
22
Kapitola 3.Zjištění požadavků potenciálních zákazníků Zjištění požadavků potenciálních zákazníků bude hrát důležitou roli pro samotný návrh implementace. Ujasníme si, kdo bude náš potenciální zákazník a následně dopodrobna specifikujeme zákazníkovi požadavky na systém.
3.1.Potenciální zákazník Potenciální zákazník je člověk, nebo společnost, která podniká v oboru cestovního ruchu. Provozuje, nebo chce provozovat cestovní agenturu. Může jím být nejčastěji začínající podnikatel, nebo někdo, kdo je nespokojený se svým stávajícím IS, či někdo, kdo hledá efektivnější řešení. Pro zjištění požadavků jsme vybrali modelový případ potenciálního zákazníka.
3.2.Redakční systém Redakční systém bude jednoduchým způsobem umožňovat nastavení vlastností, chování a vzhledu webových stránek. a) Správa obsahu Správa obsahu umožňuje konfiguraci některých modulů. Nastavení formulářů, zobrazování kurzů měn, informací o počasí. b) Správa stránek Správa stránek umožňuje přidávat nebo odebírat stránky webu. Editace obsahu stránek se provádí pomocí WISIWYG editoru. Umět bude základní práci s textem, jako je formátování odstavců, vytváření tabulek a seznamů, přidávání obrázků a vkládání odkazů. U stránky nastavuji zda je aktivní, nebo neaktivní. Neaktivní znamená, že se není dostupná a navenek se chová jakoby vůbec neexistovala. Můžeme nastavit libovolné URL stránky, přes které bude přístupná. Každá stránka musí mít unikátní URL. U stránky nastavujeme její typ, podle kterého se stránka chová. c) Správa menu Správa menu bude umožňovat vytvářet a konfigurovat navigační strukturu webu. Bude umět 23
libovolně řadit položky v menu. Každá položka menu může mít libovolný počet podpoložek. Počet zanoření není omezen. Ke každé položce menu náleží právě jedna stránka. d) Sidebox Sidebox, nebo boxíky, jsou místem pro vkládání textu nebo obrázků v postranních lištách webu. Systém do boxíku umožní vložit libovolný vlastní obsah nebo obsah nějakého modulu jako jsou např. kurzy měn, počasí, atd.. Boxík umíme přiřadit k jednotlivým stránkám. Každá stránka může mít i více boxíků. Jeden boxík může být přiřazen k více stránkám. U stránky s více boxíky nastavujeme jejich pořadí ve kterém se mají zobrazit. Boxík můžeme nastavit na to, zda je aktivní nebo neaktivní. Neaktivní boxík se na webu nebude zobrazovat. e) Aktuality Vkládání aktualit v podobě libovolného textu. Aktuality se budou zobrazovat na určeném místě na webových stránkách a v chronologickém pořadí. U aktualit zobrazujeme pouze datum publikace, titulek a obsah. Můžeme přepínat stav aktuality z aktivní na neaktivní a obráceně. f) Newsletter Newsletter bude umožňovat rozesílat novinky, on-line katalogy a další informace všem registrovaným zákazníkům na jejich emailovou adresu. Obsah a pravidelnost rozesílání nebude omezena. Pamatujeme si, které newslettery už byly odeslány. g) Odběratelé newsletteru Odběratele newsletteru můžeme pouze přidávat, měnit jejich emailovou adresu, nebo měnit jejich stav z aktivní na neaktivní a opačně. Neaktivní odběratelé nedostávají newsletter na svůj email
24
3.3.Správa nabídky zájezdů Správa nabídky zájezdů bude obsahovat veškeré funkce pro správu zájezdů CA. Bude umět importovat a aktualizovat zájezdy podle nabídky CK, tyto zájezdy bude možno doplnit o další vlastní informace. Můžeme měnit také informace o destinacích a cílových zemích zájezdů. a) Nastavení CK Nastavení CK přidává či odebírá nabídky cestovních kanceláří, které chceme prodávat. U jednotlivých CK si také určíme, zda požadujeme všechny jejich zájezdy nebo jen vybrané podle nastavitelného filtru. K cestovním kancelářím můžeme přiřadit vlastní popis, kód a adresu internetové stránky. b) Import nabídek CK Importem nabídek CK budeme moci automaticky aktualizovat vlastní nabídku zájezdů podle nejnovějších nabídek cestovních agentur. Po provedení aktualizace zobrazíme informace o jejím průběhu, počtu přidaných zájezdů a počtu odebraných zájezdů. Nabídku importujeme včetně možných termínů. c) Vlastní nabídky Vlastní nabídky nám umožní vytvářet vlastní nabídky zájezdů, včetně všech detailů i přidávání fotografií. K zájezdům přiřazujeme všechny atributy jako je typ zájezdu, typ ubytování, způsob dopravy, nástupní místa, CK, místo a typ ubytování. Popisek zájezdu může být libovolný a volitelný. K nabídce vytváříme termíny s cenou, počtem nocí, datem příjezdu a odjezdu. U termínu i nabídky zájezdu nastavíme zda je aktivní nebo neaktivní. Neaktivní položky se nezobrazují v nabídce na webu a není je mono rezervovat. d) Správa zemí Správa zemí umožňuje editovat informativní popisky, vkládat detaily o počasí, kultuře, měnách a dalších podrobnostech vztahujících se k cílovým zájezdů. Zemi nelze odstranit pokud se k ní vztahuje jedna či více destinací. 25
e) Správa destinací Správa destinací umožňuje vkládat vlastní informativní popisky a zajímavosti pro uživatele k jednotlivým destinacím. Destinace přiřazujeme k zemím. Destinaci nelze odstranit pokud se k ní vztahuje jedno či více ubytovacích zařízení. f) Správa ubytování Správa ubytování umožňuje editovat, přidávat a mazat ubytovací zařízení. U každé položky nastavujeme vlastní název a popisek. U ubytování nastavíme jeho typ, např.: hotel, pension, bungalov atd.. Každé ubytování přiřadíme právě k jedné destinaci.
3.4.Správa zákazníků Správa zákazníků zahrnuje správu klientů, kteří si rezervovali, nebo zakoupili zájezd u CA a nebo využili jiných služeb. Správa se také týká uzavřených smluv mezi klienty a CA. a) Klienti Modul klienti obsahuje seznam klientů s jejich údaji, které můžeme třídit, filtrovat, vyhledávat a měnit. Můžeme také přidávat nové a mazat staré klienty. Ke klientům můžeme vkládat libovolnou neveřejnou poznámku např. o jejich platební morálce nebo spolehlivosti. b) Smlouvy Modul smluv obsahuje správu seznam smluv mezi klienty a CA. Smlouva vzniká vždy při rezervaci zájezdu. V administraci můžeme smlouvu dále upravovat a na žádost klienta měnit náležitosti. Pro rychlejší orientaci můžeme smlouvy filtrovat a vyhledávat podle klienta. U smluv měníme jejich stav např. na stornováno, rezervováno, zaplaceno atd..
3.5.Management uživatelů IS Management uživatelů IS se bude starat o správu uživatelů, kteří mají přístup do informačního systému. Uživatelé mají přístup vždy do celého systému, neřešíme uživatelské skupiny. 26
a) Uživatelé Manipulace s uživateli, můžeme měnit osobní údaje, ručně odebírat, nebo přidávat nové uživatele. U uživatele můžeme nastavit stav na aktivní, nebo neaktivní. Neaktivní uživatelé nemají přístup do administračního systému, aktivní ano.
3.6.Statistiky a logy Modul pro prohlížení statistik a logů IS. Zaměřujeme se na statistiky k prodejnosti zájezdů a logujeme všechny změny v IS. a) Logování změn Logování změn umožňuje dohledat všechny úpravy provedené v IS. V logu je možnost filtrovat data podle uživatele, typu modulu nebo typu logu. b) Statistiky zájezdů Statistiky zájezdů zobrazují nejvíce / nejméně navštěvované a prodávané zájezdy. Ve statistice můžeme filtrovat a vyhledávat podle zájezdů.
27
Kapitola 4.Návrh pro implementaci Návrh pro implementaci obsahuje popis pro vývojáře, jakým způsobem se bude systém implementovat. Vstupem je analýza požadavků potenciálních zákazníků. Výstupem návrhu je návod a postup k technické realizaci. Návrh popisuje relační datový model, který obsahuje datovou strukturu IS. Uživatelské rozhraní na kterém je vidět jak celý systém bude vypadat. Nakonec také návrh programové části podle kterého se IS bude programovat.
4.1.Relační datový model Relační datový model zobrazuje způsob uložení dat do databázového systému. Není závislý na konkrétním databázovém systému. Pro vytvoření datového modelu je prvotní nalezení entit a vazeb mezi nimi. Použité pojmy: • Entita je určité seskupení dat, které k sobě logicky přináleží a které zkoumáme v rámci zadané analýzy. Každá entita má své atributy. • Atribut je položka entity. • Vazba určuje vztahy mezi entitami. • Primární klíč je atribut který jednoznačně identifikuje výskyt dané entity. Musí být jednoznačný. • Cizí klíč je atribut entity A, který se vyskytuje v entitě B jako primární klíč. Datový model IS je rozdělen na tři logicky oddělené části. Správa zájezdů, správa klientů a část pojmenovanou CMS. Primární klíče jsou označeny klíčkem. Entity zde reprezentují tabulky.
28
a) Správa zájezdů
Obrázek 1: Datová struktura správy zájezdů Datová struktura správa zájezdů udržuje informace o uložených zájezdech a všech k tomu logicky přímo navazujících objektech. Tabulka tour obsahuje informace o zájezdech. Tabulka term obsahuje informace o termínech, ceně a délce pobytu vytahující se ke konkrétním zájezdů. K jednomu zájezdu může být více možných termínů. Tabulka departure obsahuje seznam odletových, nebo odjezdových míst. Tabulka tour_departure obsahuje záznamy o odletových místech vzhledem k zájezdům. Každý zájezd může mít jedno nebo více odletových míst. Tabulka tour_type obsahuje seznam typu zájezdů. Každý zájezd může být pouze jednoho typu. Tabulka boarding obsahuje seznam typů stravování. Každý zájezd může mít pouze jeden typ stravování. Tabulka transport obsahuje seznam typů dopravy. Každý zájezd může mít pouze jeden typ dopravy. 29
Tabulka agency obsahuje cestovní kanceláře, které nabízejí zájezdy. Každá cestovní kancelář může nabízet více zájezdů. Tabulka accommodation obsahuje seznam ubytovacích zařízení. Tabulka accommodation_type obsahuje seznam typů ubytovacích zařízení. Každé ubytovací zařízení může být pouze jednoho typu. Tabulka destination obsahuje letoviska. Ke každému letovisku může být přiděleno více ubytovacích zařízení. Tabulka country obsahuje informace o zemích. Každá země může mít více letovisek.
30
b) Správa klientů
Obrázek 2: Datová struktura správy klientů Datová struktura správa klientů udržuje informace o klientech a jimi uzavřených smlouvách s cestovní agenturou. Tabulka contract obsahuje informace o smlouvách klientů. Tabulka contract_status obsahuje seznam stavů smlouvy. Každá smlouva má právě jeden stav. Tabulka customer obsahuje informace o klientech CA. Tabulka customer_contract obsahuje informace o tom, jaký klient uzavřel jakou smlouvu. Zároveň platí, že každý klient může uzavřít více smluv a zároveň ke každé smlouvě se může vázat jeden či více klientů.
31
c) CMS
32
Obrázek 3: Datová struktura CMS CMS obsahuje datovou strukturu samotného systému, který umožňuje správu obsahu webu. Tabulka user obsahuje uživatel, kteří mají přístup do systému. Tabulka changelog obsahuje informace o práci uživatelů s CMS. Při každé akci uživatele se do této tabulky uloží záznam s informacemi o tom, co se stalo. Tabulka changelog_type obsahuje seznam typů logu. Např. zda došlo k vytvoření záznamu, smazání, nebo úpravě. Tabulka page obsahuje informace o všech jednotlivých stránkách v systému veřejné části. Každá stránka může obsahovat libovolný počet podstránek s libovolným zanořením. Tabulka page_type obsahuje informace o typech stránky. Každá stránka může být pouze jednoho typu. Podle typu stránky se určuje její chování a způsob zobrazení. Tabulka sidebox obsahuje informace o boxíkách. Tabulka page_sidebox obsahuje informace o tom, jaký boxík se má zobrazit na jaké stránce. Platí, že na stránce se může zobrazit i více boxíků a jeden boxík se může zobrazit na více stránkách. V případě více boxíků na jedné stránce můžeme nastavit jejich pořadí. Můžeme také nastavit zobrazení boxíků na všechny podstránky té dané stránky.
33
Tabulka news obsahuje informace o novinkách. Tabulka newsletter obsahuje informace o newsletteru pro klienty.
4.2.Návrh uživatelského rozhraní Návrh uživatelského rozhraní vychází z analýzy potřeb uživatelů s ohledem na splnění účelu aplikace. Uživatelský návrh jsme vytvářeli pomocí programu Adobe Photoshop CS 4. Všechny použité obrázky a texty jsou pouze ilustrační. Vytvořeny jsou celkem tři návrhy. Jeden pro hlavní stránku, další pro podstránky a poslední pro administrační rozhraní IS.
34
35
a) Návrh hlavní stránky
Obrázek 4: Návrh uživatelského rozhraní hlavní stránky
Návrh hlavní stránky byl prováděn samostatně od ostatních podstránek. Úvodní stránka bývá nejčastěji také vstupní stránkou na webové stránky, proto ji byla potřeba věnovat zvláštní pozornost. Prvním zájmem bylo umístit na tuto stránku takové informace, které bude uživatel nejčastěji hledat. Nabídku vybraných zájezdů, rychlou vyhledávací nabídku, základní informace o stránce na které se nachází. Tím myslíme nějaké promo informace o CA. V neposlední řadě také rychlá navigace na vybrané zájezdy a vybrané destinace.
36
b) Návrh podstránek
Obrázek 5: Návrh uživatelského rozhraní podstránky
Návrh podstránek zachovává základní design hlavní stránky. Liší se v uspořádání obsahu. Každá podstránka bude mít svoje vlastní obsahové uspořádání pole svého typu. Každá podstránka musí zobrazovat drobečkovou navigaci pro snadnou orientaci uživatele v hierarchii navigace, která může mít několik úrovní zanoření.
37
c) Návrh administračního rozhraní
Obrázek 6: Návrh uživatelského rozhraní administrace
Návrh administračního rozhraní zachovává design a barevnost grafických návrhů webové stránky IS. Pro jednodušší orientaci a rychlé načítání stránek obsahuje jen minimální množství grafických prvků. Všechny editovatelné položky jsou součástí hlavního menu. Tím jsou přístupné na jedno kliknutí.
4.3.Návrh programové části Návrh programové části vychází z analýzy softwarových a hardwarových požadavků na systém. Pro vývoj složitějších systému nebo webových aplikací je výhodné nasadit framework. Framework je aplikační rozhraní, nad kterým se aplikace buduje. Pro naše účel jsme vybrali svůj vlastní framework nazvaný JWork. Hlavním důvodem je podrobná znalost, vlastní zkušenost s jeho nasazováním a možná rozšiřitelnost o novou funkčnost. 38
a) Framework JWork Základ frameworku JWork tvoří jeho jádro. To v sobě obsahuje třídy pro vlastní běh aplikace, třídy sloužící jako aplikační rozhraní k IS a konfiguraci. Třídy pro vlastní běh spouští aplikaci, načítají konfiguraci, načítají API, zpracovávají vstupní data, předávají řízení aplikaci a nakonec zobrazují výstup uživateli na obrazovku. API jádra aplikaci poskytuje funkce pro vyváření fungujícího systému. Ty pomocí návrhového vzoru model – view – controller od sebe oddělují datovou, řídící a výstupní část. Dále máme možnost přistupovat ke cookies, session, formulářovým polím, konfiguračním proměnným apod.. Konfigurace jádra obsahuje informace o umístění knihoven, datových zdrojů i samotné aplikace. Nastavuje také šablony, soubory, tovární hodnoty některých proměnných atd.. b) Databáze MySQL Databáze pro IS bude použita MySQL. Framework JWork umožňuje navrhnout rozhraní pro kteroukoliv databázi. Databázové tabulky budou typu MyISAM z důvodu obecného doporučení a kvůli častějšímu hledání v databázi, než vkládáním nebo změnou řádků. Data budou kódována v UTF-8 kvůli podpoře češtiny a jiných národních znacích, které se s velkou pravděpodobností v systému mohou vyskytovat. c) SEO optimalizace Optimalizace pro vyhledávače se týkají optimalizace výstupního zdrojového kódu a URL informačního systému. URL používané pro vnitřní navigaci v systému mají textový charakter a co nejvíce vystihují obsah stránky. Každá stránka má svoje unikátní URL. Pro oddělování logických celků v adresním řádku používáme značku "/" lomítka. Pro oddělení slov nepoužíváme mezeru, ale nahradíme ji značkou "-" pomlčky. V URL se dále vyskytují už jen pouze znaky anglické abecedy a čísla. Výstupní zdrojový kód musí být validní HTML a CSS kód podle standartu W3C. Použité HTL značky musí odpovídat sémantice dokumentu. To znamená správné použití nadpisů, odstavců, tabulek, seznamů a dalších elementů. Každá stránka musí obsahovat nadpis nejvyšší úrovně, tzv. nadpis H1, a titulek. Oba elementy musí obsahující text vystihující tématiku webové aplikace, nejlépe samotný název systému. 39
U tabulek, obrázků a odkazů používáme doplňkové atributy k upřesnění informací o objektu. Optimalizace obsahu podle klíčových slov je již individuální záležitost každého jednotlivého systému. Při vývoji samotného IS není možnost toto nijak rozumně optimalizovat.
40
Kapitola 5.Implementace Implementační část se zabývá způsobem a postupem vývoje celého systému. Vstupem je návrh implementace, výstupem je potom funkční aplikace k okamžitému použití. V první části definujeme použité technologie, dále aplikace se kterými jsme při vývoji pracovali a na konci postup samotné implementace.
5.1.Použité technologie Použité technologie obsahují základní popis použitých technologií při implementaci nebo provozu informačního systému. a) Apache HTTP server Apache HTTP server je softwarový program, fungující jako webový server. Jeho vývoj začal v roce 1993 v národním centru Superpočítačových aplikací na Illoinské univerzitě. O tři roky později se stal nejpopulárnějším serverem na internetu a to platí i doposud. Vývoj probíhá pod otevřeným kódem pro platformy Linuxu, Solaris, MS Windows i Mac OS X. Server se stále vyvíjí a v současné době je k dispozici ve verzi 2.3. b) PHP PHP je skriptovací programovací jazyk určený především k programování dynamických internetových stránek. PHP skripty jsou prováděny na straně serveru, který zpracovává požadavky uživatele a vrací pouze výsledek činnosti. V poslední verzi PHP 5.0 přibyly nové možnosti jazyka pro využití objektového přístupu programování. Několik posledních let je nejrozšířenějším programovacím jazykem určený pro webové technologie. Jazyk se stále vyvíjí a v současné době je k dispozici jeho nejnovější verze 5.3. c) MySQL MySQL je databázový systém, který vytvořila švédská firma MySQL AB. K dispozici je pod dvojí licencí. Bezplatnou GPL, nebo placenou komerční.
41
Komunikuje prostřednictvím jazyka SQL, což je standardizovaný dotazovací jazyk používaný pro práci s daty relační databáze. Databáze MySQL se stále vyvíjí a v současné době je k dispozici ve verzi 5.1.
5.2.Použité aplikace Použité aplikace obsahují základní popis aplikací použitých při vývoji informačního systému. Každá aplikace obsahuje popis, k čemu slouží a konkrétně k jakému účelu byla při implementaci použita. a) Vývojové prostředí Eclipse Vývojové prostředí Eclipse je open source vývojová platforma určená pro programování v jazyce Java. Obsahuje podporu pro přidání nových doplňků v podobě nových programovacích jazyků. Pro vývoj našeho systému jsme použili doplněk PHP development Tool od společnosti Zend. b) phpmyadmin Phpmyadmin je webová aplikace napsaná v jazyce PHP, která umožňuje správu databází MySQL na serveru. Umí pracovat s databázemi, tabulkami a daty v tabulkách. Nástroj jsme použili při vkládání testovacích dat do systému. c) Adobe Photoshop CS 4 Photoshop verze CS 4 od společnosti Adobe jsme použili pro vytvoření grafického návrhu systému. Tento nástroj je velice populární i mezi profesionálními grafiky v oblasti webových technologiích. Výsledný návrh je možno rozřezat na jednotlivé obrázky, použitelné do šablony HTML kódu. d) DB Designer 4 DB Designer verze 4 je aplikace společnosti fabFORCE a slouží k návrhu datových struktur pro relační databáze. Pracuje s jazykem SQL. Výsledný model dokáže propojit s databází na serveru a pomocí nástroje synchronizace provádět okamžité změny v databázových strukturách. e) Mozilla Firefox Mozilla Firefox je oblíbeným internetovým prohlížečem. Z pohledu webové vývojáře je možné obohatit jeho funkčnost o řadu užitečných funkcí usnadňující jak samotný vývoj, tak 42
následné testování. Použitými doplňky jsou Web Developer, Firebug a HTML validator. f) Ostatní internetové prohlížeče Ostatní internetové prohlížeče jsme použili k otestování informačního systému. Konkrétně pak ke kontrole správného zobrazování webových stránek na straně klienta a správné funkčnosti JavaScript kódu. Využili jsme prohlížeče MS Internet Explorer verze 5, 6, 7 a 8 a prohlížeč Opera.
5.3.Postup implementace Postup implementace obsahuje ucelený popis průběhu vývoje systému od vytvoření datového modelu až po naprogramování konkrétních modulů systému. a) Vytvoření databázového modelu Vytvoření databázového modelu bývá jedna z prvních věcí, kterou se začíná implementovat. Využili jsme modelu vytvořeného v návrhu implementace, který jsme vytvářeli v aplikaci DB Designer od společnosti fabFORCE. Program se umí automaticky spojit s databází serveru a nahrát celé schéma přímo na server. Této funkce jsme využili a jedním kliknutím jsme naimportovali celou datovou strukturu na server, kde máme nainstalovanou databázi MySQL. Veškeré dodatečné úpravy struktur jsme i nadále prováděli v aplikaci DB Designer a pomocí zabudované funkce synchronizace je aktualizovali na server. b) Naplnění databáze daty Pro naplnění databáze testovacími daty jsme využili možnosti aplikace phpmyadmin. Pomocí intuitivního ovládání jsme do tabulek postupně uložili několik testovacích řádků dat. Data jsme v průběhu vývoje a testování doplňovali dle potřeby. c) Vytvoření grafické šablony Grafický návrh systému jsme kompletně vyhotovili v programu Adobe Photoshop CS 4. Pomocí nástroje rozřezání jsme ho rozřezali na jednotlivé obrázky, které jsme dále využili při tvorbě HTML šablony. d) Kódování HTML šablony Grafický návrh bylo potřeba převést do HTML kódu a aplikovat na něj kaskádové styly tak, aby výsledná podoba odpovídala vytvořenému grafického návrhu. Šablonu jsme dělali tak, aby 43
vyhovovala standartu W3C a správně se zobrazovala ve všech prohlížečích. e) Instalace frameworku jWork Instalace frameworku jWork je velice prostá a zabere minimum času. Základ frameworku tvoří jedna složka obsahující celý systém, spouštěcí soubor typicky index.php a soubor .htaccess sloužící jako konfigurační soubor pro server Apache. Tyto tři součásti je potřeba pouze vzít a překopírovat do nově založeného projektu. V souboru .hraccess nastavíme správnou hodnotu pro RewriteBase, nejčastěji však na kořenový adresář serveru. Kořenový adresář se označuje pouze lomítkem "/". Konfigurační soubor frameworku config.php můžeme nechat beze změn, pokud nepoužijeme jiné než typické nastavení systému. To znamená, že zachováme typické pojmenování adresářů i pojmenování tříd a souborů. f) Programování modulů Programování modulů systému je nejnáročnější úkol celé implementace. Náš systém obsahuje dva moduly. Veřejný, který je nastaven jako výchozí a který funguje jako webový portál. Druhý modul je administrační a přístup je přístupný pouze pro přihlášené uživatele.. Každý modul vytváříme do vlastního adresáře, ve kterém dodržujeme adresářovou strukturu podle nastavení frameworku. Všechny názvy souborů a tříd musí dodržovat svou konvenci stanovenou opět konfigurací frameworku. Vytváření modulu se skládá ze čtyř úkolů, které se dají pojmenovat jako model – view – controller. Ale tím úplně prvním je nastavení konfigurace modulu. Každý modul obsahuje vlastní konfiguraci, která se nachází v kořenovém adresáři modulu a soubor se jmenuje config.php. V konfiguraci se nastavují základní vlastnosti modulu, včetně přístupových údajů k databázovému serveru. Modely jsou třídy reprezentující datové objekty projektu. To znamená, že každá tabulka uložená v databázi zde má svou třídu, která s danou tabulkou pracuje. Modelové třídy jsou potomky hlavní třídy JModel. Odvozené objekty z tříd těchto tříd modelů komunikují s databázovými zdroji, kde získávají, mažou a mění data. Data předávají ke zpracování řídícím objektům. Řídící objekty, neboli controllery, jsou spouštěny na základě požadavků uživatele. Třídy těchto kontrolérů jsou potomky hlavní třídy JController. Kontroler řídí chování celé aplikace a rozhodují o tom, které informace se dostanou na výstup uživateli. Využívají modely k získávání data, které dále posílají výstupním šablonám systému.
44
Výstupní šablony systému reprezentují podobu dat, která se dostane na obrazovku k uživateli. Šablony jsou volány a plněny daty řídícími objekty a mohou být statické, nebo dynamické. Pokud jsou dynamické, zobrazují ty data, která jim předávají řídící objekty. V šablonách se mixuje HTML kód, javascript a u těch dynamických také PHP kód. Programování modulů se vyžaduje znalost aplikačního rozhraní frameworku jWork. Proto se před zahájením úprav nebo vytváření nových modulů doporučuje s frameworkem seznámit.
45
Kapitola 6.Testování Testování při vývoji softwarových produktů patří k nejdůležitějším a často zároveň také k nejvíce podceňovaným úkonem vývojářů při vývoji internetových aplikací. Zaměřil jsem se na testování z hlediska bezpečnosti systému, přístupnosti a použitelnosti.
6.1.Testování z hlediska bezpečnosti systému Testování z hlediska bezpečnosti systému považuji za jedno z nejdůležitějších. Zvlášť u systémů, které uchovávají osobní údaje uživatelů, nebo údaje provozovatele cestovní agentury. Při testování jsem se zaměřil na nejčastější typy útoků na internetové informační systémy. Testoval jsem dva nějčastější typy útoků. Těmi jsou XSS neboli Cross Site scripting a SQL Injection. a) Testování na Cross Site Scripting Jeden z nejběžnějších a zároveň nejnebezpečnějších útoků. Jeho princip spočívá ve využití neošetřeného uživatelského vstupu a podstrčení klientovi nebezpečného kusu kódu nejčastěji v podobě javascriptu. Nejzranitelnějšími místy jsou formuláře, nebo samotné URL stránky. Obranou před tímto typem útoku z pohledu programátora je důsledně kontrolovat obsah všech HTTP hlaviček, cookies a formulářových polí. Framework jWork obsahuje knihovnu JLibValidator s řadou funkcí, které validují vstup na určitý typ dat. Je však na programátorovi, zda tuto třídu bude používat či nikoliv. Při testování jsem zjistil, že na několika místech IS nebyla validace vstupu provedena. A i když chyba by nezpůsobila možnost uložit škodlivý kód XSS do databáze, vyhození chyby rozhodně není lichotivá vizitka systému. Validace údajů v administrační části systému byla poměrně zanedbaná, což určitě není dobře a systém by touto cestou mohl být snadno napadnutelný. b) Testování na SQL injection SQL injection je útok, který se snaží o napadení, či získání dat z databáze. Útok se děje šikovným vložením kódu jako parametru do SQL dotazu. Proti tomuto typu útoku jsem informační systém shledal jako odolný. Framefork jWork nepoužívá přímé vkládání uživatelských parametrů do SQL dotazu, ale každý parametr před vložením ošetří nativní databázovou funkcí, v našem případě u databáze MySQL to je funkce mysql_escape_string. Tím je tento problém vyřešen na té systémové úrovni a programátor se již 46
nemusí o nic starat.
6.2.Testování přístupnosti systému Testováním přístupnosti systému ověřujeme použitelnost systému pro více či méně postižené uživatele, nebo pro uživatele technicky omezené. Například používají zastaralým prohlížečem, mají vypnutý javascript, nebo vypnuté cookies. a) Testování IS zrakově postiženými uživateli Protože jsem neměl takového uživatele k dispozici, zaměřil jsem se sám na některé detaily, které by těmto uživatelům mohli komplikovat používání stránek. Na první pohled velikost písma obsahového textu nemusí být dostatečná a mohla by způsobovat problémy. Důležité pro tyto uživatele však je, že moderní prohlížeče umožňují velikost fontu efektivně zvětšit. Při takto zvětšeném fontu se nerozpadá design webu a to považuji za velmi důležité. Téměř všechny odkazy jsou kromě barvy odlišeny od okolního textu také podtržením což uživatelům zvyšuje orientaci a na první pohled vědí na co mají klikat. Nadpisy pro tyto uživatele shledávám jako velmi výrazné a dostatečně odlišené. IS jsem shledal jako dostatečně přístupný pro uživatele s lehčí poruchou zraku. b) Testování vypnutí kaskádových stylů a obrázků Vypnutím zobrazování obrázků a kaskádových stylů ověříme zda, je systém správně strukturován a i nadále dobře použitelný. Největším nedostatkem jsem shledal to, že v tomto módu se nezobrazuje hlavní nadpis popisující stránku. Plusem zůstává, že obsah se chronologicky seřazuje tak jak má. To znamená, že v horní části vidíme navigaci a dál následuje obsahový text děleny nadpisy do jednotlivých sekcí tak jak by to mělo být. Ne všechny obrázky obsahují alternativní popisek a to považuji také za podstatnou chybu webu. Cekově však vypnutí obrázků ani stylů nijak neomezují sytém v jeho funkčnosti. c) Testování v různých prohlížečích Testovanými prohlížeči byla Mozilla Firefox, Opera, IE 5, IE 6, IE 7 a IE 8. Kromě velmi starého a dnes téměř nepoužívaného prohlížeče IE 5, tak ve všech těchto prohlížečů design správně držel. U různých prohlížečů byli pouze odchylky u některých detailů jako jsou formulářová pole, nebo vykreslení fontu či nepatrných posunutí některých prvků na stránce. Celkově je systém dobře použitelný ve všech moderních internetových prohlížečích.
47
d) Testování vypnutého javascriptu a cookies Po úplném vypnutí cookies se nebylo možné přihlásit do administračního sytému. Přihlašování funguje na principu ukládání si uživatele do session a nenabízí alternativní možnost. Nefunguje také možnost uživatele změnit aktuální měnu, ve které se zobrazují ceny zájezdů. Tento nedostatek by šel vyřešit přenášením informace o zvolené měně v parametru URL adresy. Vypnutím javascriptu jsme neztratili žádnou funkčnost systému, ale tato skutečnost uživatelům znepříjemnila používání některých formulářů. V administrační části to byla možnost využít WYSIWYG editoru na hlavním webu pak validace formuláře při objednávce zájezdu.
48
Kapitola 7.Závěr Cílem této práce bylo zanalyzovat, navrhnout a provést implementaci informačního systému pro cestovní agenturu a výslednou aplikaci otestovat. Systém měl umožnit prodej cestovních zájezdů prostřednictvím webového portálu. Hlavním požadavkem byla možnost správy dat pomocí administračního rozhraní přístupného pouze autorizovaným uživatelům. V první fázi jsme si udělali analýzu systému z nichž byl poté navržen informační systém. Jako vývojové prostředí byly vybrány open source technologie, server Apache, programovací jazyk PHP a databáze MySQL. V druhé fázi jsme se zaměřili na požadavky potenciálních klientů. Požadavky se týkali už konkrétní podoby a funkčnosti systému. Byly zmíněny veškeré součásti, které systém bude obsahovat a které se budou implementovat. Dalším úkolem bylo vyhotovit návrh implementace systému, který poskytuje kostru pro samotnou implementaci a naprogramování. Návrh zahrnuje datovou strukturu systému, návrh grafického rozhraní, návrh pro programovou implementaci a návrh pro SEO optimalizaci. Výsledkem realizace by měl být zcela funkční informační systém. Předposledním úkolem bylo systém implementovat. Vytvořili jsme databázové schéma a naplnili ho smysluplnými daty. Grafický návrh vytvořený v Adobe Photoshop CS 4 jsme nakódovali do HTML kódu s kaskádovými styly. K naprogramování aplikace jsme využili frameworku jWork a vývojového prostředí Eclipse. Poslední fáze, testováním, kterým se prověřovala bezpečnost a přístupnost systému. Testy odhalily několik závažnějších bezpečnostních nedostatků, zejména proti útokům XSS v administrační části systému. Testování přístupnosti dopadlo i přes několik nedokonalostí dobře. Aplikace by určitě šla ještě dále rozšiřovat o nové funkce a nebo vylepšovat stávající. Dovedu si představit propracovanější objednávkový systém, zahrnutí reklamních modulů, zvláštních cenových a slev u zájezdů nebo více poskytovaných informací návštěvníkům portálu spojené s cestovním ruchem. Zároveň navrhuji ošetřit systém proti XSS útokům a to na úrovni použitého frameworku. Systém je naštěstí stavěn tak, aby se mohl snadno přizpůsobovat a rozšiřovat na míru každému zákazníkovi. Shledávám ho jako dobře využitelný k praktickému využití.
49
Kapitola 8.Použitá literatura [1] Jiří Kosek – PHP, Tvorba interaktivních internetových aplikací, 1.vydání. Grada 1998 [2] George Schlossnagle – Pokročilé programování v PHP 5, 1.vydání. Zoner Press 2004 [3] Wikipedia – http://wikipedia.org [4] Dokumentace PHP – http://php.net/docs.php [5] Dokumentace MySQL – http://dev.mysql.com/doc/ [6] Dokumentace HTTP serveru Apache – http://httpd.apache.org/docs/ [7] Stránky World Wide Web consortium – http://w3c.org
50
Dodatek A: Příručka pro uživatele 1. Instalace Instalace celého IS vyžaduje určité znalosti prostředí webových aplikací a měla by být svěřena do rukou alespoň mírně zkušeného webmastera. Nutnou podmínkou pro běh systému je mít zajištěný hosting a zaplacenou doménu, pod kterou chceme systém provozovat. A to takový hosting. který splňuje požadavky na IS. Na hostingovém serveru se vytvoří prázdná databáze, do které se pomocí SQL dotazů vytvoří datová struktura a vloží všechna data v ní obsažená. SQL dotazy jsou součástí projektu a najdeme je v adresáři sql příslušného modulu. Pomocí libovolného FTP klienta se připojíme na naší doménu, kam nakopírujeme všechny soubory informačního systému. V případě nutnosti změníme nastavení souboru .htaccess k kořenovém adresáři systému. V konfiguračním souboru modulů zkontrolujeme nastavení připojení k databázi serveru.
2. Spuštění systému Po instalaci je systém připraven ke spuštění a používání. Test funkčnosti provedeme zadáním názvu domény do adresního řádku internetového prohlížeče. Pokud se nám zobrazí podoba našeho portálu i se všemi obrázky a daty z databáze, systém funguje. Přístup do administrace systému je typicky dostupný na internetové adrese http://názevdomény/admin/. Administrace je přístupná po úspěšném zadání uživatelského jména a hesla. Jméno i heslo pro první přihlášení je nutno nastavit ručním vložením nového uživatele do databáze, pokud již tak nebylo učiněno dříve. Systém je nyní připraven k používání.
3. Administrace systému Administrace systému je typicky přístupná na internetové adrese http://názevdomény/admin/ . Po přihlášení se nám zobrazí menu s nabídkou editovatelných modulů. Moduly jsou rozděleny do kategorií podle zaměření.
1
Modul správy obsahu Modul správy obsahu umožňuje aktualizovat obsah webu. Měníme obsah stránek, strukturu navigace, píšeme novinky nebo nastavujeme postranní sideboxíky. Modul správy zájezdů Modul správy zájezdů umožňuje přidávat a odebírat nabízené zájezdy. Můžeme také přidávat informace o destinacích, zemích a ubytovacích zařízení. Modul správy klientů Modul správy klientů se stará o práci s osobními údaji uživatelů a uzavřených smluv. Zde také můžeme nastavovat stav smluv. Modul správy uživatelů Modul správy uživatelů umožňuje přidávat a odebírat uživatele, kteří mají přístup do administračního systému. Uživatele můžeme také blokovat a nebo měnit jejich přístupové údaje. Modul statistik Modul statistik zobrazuje prodejnost jednotlivých zájezdů a také změny, které provedli uživatelé v administraci.
2
Dodatek B: Příručka pro vývojáře Příručka pro vývojáře slouží jako popis programového kódu a také jako návod pro další rozšiřování informačního systému, nebo i samotného frameworku. Na diagramech znázorňuje principy fungování systému.
1. Adresářová struktura Adresářová struktura systému obsahuje složku pro umístění frameworku jWork a složku pro umístění modulů samotného systému. Pro přehlednost jsou všechny systémové adresáře označeny prefixem "j". Složka jcore obsahuje hlavní spouštěcí třídu JCore, rodičovskou třídu pro všechny komponenty jádra JCoreComponent a konfigurační soubor config. Všechny funkční komponenty jádra jsou rozděleny dle svého účelu pro do dalších podadresářů. Rozdělení je kvůli přehlednosti systému. Složka jmodules obsahuje všechny funkční moduly projektu. Moduly jsou na sobě zcela nezávislé a lze je do systému libovolně přidávat nebo odebírat. Každý modul obsahuje svůj vlastní konfigurační soubor a podadresáře určené k umístění datových souborů a výkonných tříd modulu.
3
Obrázek 1: Adresářová struktura systému
4
2. Struktura systému Struktura systému graficky znázorňuje rozdělení aplikace na jednotlivé části. Rozdělení odpovídá adresářové struktuře. Šipky v diagramu ukazují závislost a zanoření jednotlivých komponent do sebe. Vstupní soubor index.php komunikuje s jádrem jCore, která načítá konfiguraci config a rodičovskou komponentu JCoreComponent. Ta vzájemně propojuje všechny všechny komponenty frameworku a ty díky tomu mohou mezi sebou spolupracovat. Komponenty vytvářejí aplikační rozhraní API pro moduly systému prostřednictvím veřejných metod. Rozhraní je poskytnuto tak, že všechny třídy v modulech jsou potomky tříd JController, JModel a JView z komponent systému.
5
Diagram 1: Komponenty systému
6
3. Sekvenční diagram systému Sekvenční diagram znázorňuje běh celého systému, od spuštění až po vrácení výstupu na obrazovku uživatele. Systém je spuštěn vždy přes vstupní soubor index.php což nám zajišťuje konfigurační soubor .htaccess, který směruje všehny HTTP požadavky právě na tento soubor. Všechny s výjimkou požadavků na obrázky, kaskádové styly a soubory javascriptu. Index vytvoří objekt jádra JCore, které převezme řízení aplikace. Načte svůj konfigurační soubor, podle kterého vyhledává všechny komponenty jádra. Nejprve načte hlavní komponentu JCoreComponent, vytvoří jeho instanci. Postupně načítá všechny ostatní komponeny v systému a vytváří si jejich instance. Jádro předává řídící funkci na svou řídící komponentu JFrontController. Jeho úkolem je řídít vnitřní logiku frameworku. FrontController nastaví všechny komponenty jádra do výchozího stavu. V druhé fázi FrontController vyšle požadavek směrem k objektu JModule, který zajišťuje správu, nastavení a také načítání modulů systému. JModule podle URL požadavků na server, které jsou dostupné přes komponentu JRequest, se pokusí o načtení konfiguračního souboru daného modulu. Výsledek vrací zpátky na FrontController, který předá řízení už na konkrétní Controller daného konkrétního modulu. Tím se dostáváme do fáze, kde modul, nebo také programátor systému, přebírá řídící zodpovědnost. JController už typicky komunikuje s datovými objekty, což jsou potomky třídy JModel. Získává z nich databázová data a předává je výstupním šablonám JView. Šablony JView předávají výstupní informaci na hlavní výstupní objekt JResponse. Ten tedy nyní obsahuje to, co chceme uživateli poslat na obrazovku monitoru. Po skončení činnosti JControlleru se řízení opět ujímá JFrontController, z objektu JResponse vytahuje výstupní data, předává je zpět do jádra JCore a ten je posílá jako HTML kód na výstup. Tím je cyklus jednoho požadavku u konce.
7
Diagram 2: Běh aplikace
8
