České vysoké učení technické v Praze. Fakulta Elektrotechnická. Bakalářská práce. Informační systém pro cestovní agenturu.

Transkript

1 Č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 2

3 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 4

5 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 6

7 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

8 8

9 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 10

11 Obsah Kapitola 1.Úvod...14 Kapitola 2.Analýza požadavků na IS Účel a cíl IS 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 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 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 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ů Potenciální zákazník 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 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í Správa zákazníků...25 a) Klienti...25 b) Smlouvy Management uživatelů IS...25 a) Uživatelé Statistiky a logy...26 a) Logování změn

12 b) Statistiky zájezdů...26 Kapitola 4.Návrh pro implementaci Relační datový model...27 a) Správa zájezdů...28 b) Správa klientů...30 c) CMS 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í Návrh programové části...35 a) Framework JWork...36 b) Databáze MySQL...36 c) SEO optimalizace...36 Kapitola 5.Implementace Použité technologie...38 a) Apache HTTP server...38 b) PHP...38 c) MySQL Použité aplikace...39 a) Vývojové prostředí Eclipse...39 b) phpmyadmin...39 c) Adobe Photoshop CS d) DB Designer e) Mozilla Firefox...39 f) Ostatní internetové prohlížeče 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í Testování z hlediska bezpečnosti systému...43 a) Testování na Cross Site Scripting...43 b) Testování na SQL injection 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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 23 Správa menu bude umožňovat vytvářet a konfigurovat navigační strukturu webu. Bude umět

24 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 ovou 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 ovou adresu, nebo měnit jejich stav z aktivní na neaktivní a opačně. Neaktivní odběratelé nedostávají newsletter na svůj 24

25 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

26 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 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

27 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

28 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

29 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. typu. Tabulka tour_type obsahuje seznam typu zájezdů. Každý zájezd může být pouze jednoho 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

30 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

31 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

32 c) CMS 32

33 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