Informační systém cestovní agentury

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Informační systém cestovní agentury Bc. Jiří Snížek

Vedoucí práce: Ing. Martin Molhanec, Csc.

Studijní program: Elektrotechnika a informatika (magisterský), strukturovaný Obor: Výpočetní technika Leden 2010

ii

Poděkování Chtěl bych poděkovat panu Ing. Martinu Molhancovi, CSc., vedoucímu diplomové práce za jeho čas, ochotu pomoci a poradit při zdolávání překážek položených touto prací a zejména za věcné připomínky a rady, které sloužily ke zdárnému dokončení této práce. Také bych chtěl poděkovat svým příbuzným, kteří mi pomohli s testováním implementace systému.

iii

iv

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 30. 12. 2009

………………………………………………………….

v

vi

Abstract This graduation theses is focused on motion for an implementation of an informating traveler’s agency system, used mainly for accommodation registration, client registration and reservation. Furthermore, this system should substitute contemporary out-of-date system while providing easier and faster order communication for the company. The text of this these is devided into several parts. First, it describes difficulties connected with contemporary system used by the company, then it moves to description of the technology the new system is based on. The third part is an opening study, followed by motion for the resolution analysis. The last chapters are devoted to implementation of the application and its testing ceremony. Last but not least, the enclosed supplement contains user guide and handy vocabulary list.

Abstrakt Tato diplomová práce se zabývá návrhem a implementací informačního systému cestovní agentury sloužící zejména pro evidenci ubytování, klientů a rezervací. Tento systém by měl nahradit současný zastaralý systém a měl by přinést společnosti jednoduší a rychlejší vyřizování objednávek. Text této práce je rozdělen do několika částí. První část popisuje současnou situaci problému, druhá část popisuje technologie, na nichž bude systém postavem. Třetí částí je úvodní studie, následuje analýza návrhu řešení. Závěrečné kapitoly jsou věnovány implementaci aplikace a jejímu testování. V příloze je mj. uvedena uživatelská příručka a slovník pojmů.

vii

viii

Obsah Seznam obrázků

xiii

Seznam tabulek

xv

1. Úvod

1

2. Použité technologie a metodiky 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

2

X(HTML) ……………………………………………………………….… CSS …………………………………………………………………….…. PHP …………………………………………………………………….…. Smarty ………………………………………………………………….…. JavaScript ……………………………………………………………….… Ajax …………………………………………………………………….…. MySQL ………………………………………………………………….… Apache http Server …………………………………………………….…..

3. Úvodní studie

2 2 3 4 5 6 7 7

8

3.1. Deklarace záměru ……………………………………………………….…. 3.2. Odborný článek ………………………………………………………….… 3.2.1. Ubytovací zařízení ……………………………………………….….. 3.2.2. Doplňkové služby …………………………………………………… 3.2.3. Uživatelé, klienti ………………………………………………….…. 3.2.4. Rezervace ………………………………………………………….… 3.2.5. CMS Systém …………………………………………………….…… 3.2.6. Statistiky ……………………………………………………….…….. 3.3. Katalog požadavků …………………………………………………………. 3.3.1. Uživatelské role ………………………………………………………. 3.3.1.1. Klient ……………………………………………………….. 3.3.1.2. Prodejce …………………………………………………….. 3.3.1.3. Správce CMS ……………………………………………….. 3.3.1.4. Manažer …………………………………………………….. 3.3.1.5. Administrátor ……………………………………………….. 3.3.2. Funkce systému ………………………………………………………. 3.3.2.1. Služby systému pro klienta ………………………………….. 3.3.2.2. Služby pro prodejce ………………………………………… 3.3.2.3. Služby pro správce CMS …………………………………… 3.3.2.4. Služby pro manažera ………………………………………… 3.3.2.5. Služby pro administrátora …………………………………… 3.3.3. Nefunkční požadavky ………………………………………………… 3.4. Návrh architektury ………………………………………………………….. 3.4.1. Požadavky na softwarové vybavení uživatelů systému ……………….. 3.4.2. Požadavky na hardwarové, softwarové vybavení a obecné požadavky na webový server ……………………………………………………… 3.4.2.1. Softwarové vybavení ………………………………………… 3.4.2.2. Hardwarové vybavení ……………………………………….. 3.4.2.3. Obecné požadavky …………………………………………... 3.4.3. Požadavky na HW vybavení počítačů uživatelů informačního systému.. 3.5. Harmonogram projektu …………………………………………………….. 3.6. Use Case nejvyšší úrovně …………………………………………………... 3.7. Analýza rizik ……………………………………………………………….. ix

8 8 8 8 8 9 11 11 11 11 11 11 12 12 12 12 12 12 12 13 13 13 14 14 14 14 15 15 15 15 16 17

3.8. Datový slovník ……………………………………………………………...............

4. Analýza a návrh řešení

21

24

4.1. Analýza případů užití ……………………………………………………………….. 4.1.1. UC001 – Přihlášení do systému …………………………………….…….…… 4.1.2. UC002 – Odhlášení ze systému ………………………………………….……. 4.1.3. UC003 – Správa uživatelů ……………………………………………….……. 4.1.4. UC004 - Vytvoření nového uživatele …………………………………….…… 4.1.5. UC005 – Editace uživatele ………………………………………….…….…… 4.1.6. UC006 – Odstranění uživatele ………………………………………..……….. 4.1.7. UC007 – Prohlížení údajů o uživateli ……………………………….………… 4.1.8. UC008 – Vyhledávání uživatelů ………………………………….…………… 4.1.9. UC009 – Prohlížení seznamu uživatelů …………………………….…………. 4.1.10. UC010 - Správa ubytování …………………………………….……………. 4.1.11. UC011 – Vytvoření nového ubytovacího zařízení …………….……………. 4.1.12. UC012 – Editace ubytovacího zařízení ………………………….………….. 4.1.13. UC013 – Odstranění ubytování ………………………………….…………. 4.1.14. UC014 – Prohlížení údajů o ubytování …………………………….……….. 4.1.15. UC015 – Vyhledávání ubytování ………………………………….……….. 4.1.16. UC016 – Prohlížení seznamu ubytování ………………………….………… 4.1.17. UC017 – Správa produktů a ceníků ………………………………………… 4.1.18. UC018 – Přidání produktu k ubytování ……………………………….……. 4.1.19. UC019 – Editace produktů ubytování ………………………………….…… 4.1.20. UC020 – Odstranění produktu ……………………………………….….…. 4.1.21. UC021 – Přidání sekce ceníku ……………………………………………… 4.1.22. UC022 – Editace sekce ceníku ……………………………………….….….. 4.1.23. UC023 – Odstranění sekce ………………………………………….............. 4.1.24. UC024 – Přidání období k sekci ceníku …….. ……………………………… 4.1.25. UC025 – Editace období k sekci ceníku ……….……….……….……..……. 4.1.26. UC026 – Odstranění období sekce ceníku ……….……….……….….….….. 4.1.27. UC027 – Editace ceníku ……….……….……….……….……….…….…… 4.1.28. UC028 – Prohlížení ceníku ………….……….……….……….……….…… 4.1.29. UC029 – Správa rezervace … ……….……….……….……….……….…… 4.1.30. UC030 – Vytvoření rezervace ……… ……….……….……….……….…… 4.1.31. UC031 – Přidání a změna klienta k rezervaci ……….……….……….…… 4.1.32. UC032 – Editace kontaktních údajů o klientovi v rezervaci ….……….….… 4.1.33. UC033 – Odebrání klienta z rezervace ……… ……….……….……….…… 4.1.34. UC034 – Přidání objednávky ubytování k rezervaci ………….……….….… 4.1.35. UC035 – Přidání produktu ubytování k objednávce ubytování ……….……. 4.1.36. UC036 – Editace produktů ubytování u objednávky ubytování ……… …….. 4.1.37. UC037 – Odstranění produktu ubytování z objednávky ubytování ….. …….. 4.1.38. UC038 – Změna stavu objednávky … ……….……….……….……….……. 4.1.39. UC039 – Odstranění objednávky ubytování ... ……….……….……….……. 4.1.40. UC040 – Přidání objednávky služby . ……….……….……….……….……. 4.1.41. UC041 – Editace objednávky služby . ……….……….……….……….……. 4.1.42. UC042 – Odstranění objednávky služby ..……….……….……….……….… 4.1.43. UC043 – Přidání objednávky přepravy …….....……….……….……….…… 4.1.44. UC044 – Editace objednávky přepravy …………….……….……….………. 4.1.45. UC045 – Odstranění objednávky přepravy ...….……….……….……….…… 4.1.46. UC046 – Správa komentářů k rezervaci ……….……….……….…………… 4.1.47. UC047 – Přidání platby k rezervaci ………….……….……….……….…….. 4.1.48. UC048 – Editace platby …… ……….……….……….……….…………….. 4.1.49. UC049 – Odstranění platby… ……….……….……….……….…………….. 4.1.50. UC050 – Prohlížení rezervace ……… ……….……….……….……….……. x

24 25 26 27 27 29 31 31 32 33 35 36 37 38 39 40 41 42 43 44 45 46 48 49 49 50 51 51 53 54 57 58 59 60 61 62 65 67 68 69 70 70 70 71 71 71 71 72 73 73 73

4.1.51. UC051 – Prohlížení seznamu rezervací ……….……….……………. 4.1.52. UC052 – Vyhledávání rezervací …….……….……….……….…….. 4.1.53. UC053 – Vytvoření nového partnera pro služby a přepravu ………… 4.1.54. UC054 – Prohlížení seznamu partnerů ……… ……….……….…….. 4.1.55. UC055 – Prohlížení partnera ……….……….……….……….…….. 4.1.56. UC056 – Editace partnera pro služby a přepravu …… ……….……… 4.1.57. UC057 – Vytvoření nové služby …… ……….……….……….…….. 4.1.58. UC058 – Prohlížení seznamu služeb ……….……….……….…….. 4.1.59. UC059 – Vyhledávání služeb ……….……….……….……….…….. 4.1.60. UC060 – Prohlížení služby … ……….……….……….……….……... 4.1.61. UC061 – Editace služby …… ……….……….……….……….…….. 4.1.62. UC062 – Odstranění služby ... ……….……….……….……….…….. 4.2. Datový model ……….……….……….……….……….……….…………….. 4.2.1. Konceptuální schéma databáze ……….……….……….……….………. 4.2.1.1. Teorie ……….……….……….……….……….……….……… 4.2.1.2. Návrh ……….……….……….……….……….……….……… 4.3. Návrh uživatelského rozhraní ……….……….……….……….……….……... 4.3.1. Pravidla návrhu UI ……….……….……….……….……….……….….. 4.3.2. Návrh UI rezervačního systému CA ……….……….……….……….…. 4.3.2.1. Specifikace prototypu uživatele a minimálních technických požadavků na sytém……….……….………….……….…………… 4.3.2.2. Pravidla přístupnosti zásadní pro návrh aplikace …………………. 4.3.2.3. Pravidla použitelnosti zásadní pro návrh aplikace ………………... 4.3.2.4. Struktura uživatelského rozhraní vzhledem k funkčnosti aplikace ... 4.3.2.5. Návrh uživatelského rozhraní pomocí grafického programu ………

5. Implementace

75 75 77 78 78 78 79 80 80 80 80 81 82 82 82 82 87 87 89 89 90 91 92 93

95

5.1. Datový model, implementace datového modelu ………..………..………..…. 5.2. Implementace případů užití ………..………..………..………..………..…… 5.3. Vlastní implementace ………..………..………..………..………..………..… 5.3.1. Postup implementace ………..………..………..………..………..……. 5.4. Struktura aplikace, programové skripty ………..………..………..………..… 5.4.1. Základní soubory a objekty ………..………..………..………..………. 5.4.2. Objekty ………..………..………..………..………..………..………… 5.4.3. Pluginy ………..………..………..………..………..………..…………. 5.4.4. Šablony ………..………..………..………..………..………..………… 5.4.5. Soubory s javascriptem ………..………..………..………..………..…. 5.4.6. Nové Smarty funkce ………..………..………..………..………..……..

6. Testování

95 107 107 108 109 109 110 112 114 115 116

117

6.1. Testování uživatelského rozhraní ………..………..………..………..………. 6.2. Testování aplikace jako celku ………..………..………..………..………..… 6.3. Testování přístupnosti ………..………..………..………..………..………… 6.3.1. Testování přístupnosti …………………………………………………. 6.3.2. Testování přístupnosti vzhledem k typu používaného prohlížeče ……. 6.4. Testování použitelnosti ………..………..………..………..………..……….. 6.4.1. Pravidla a cíl testování ………..………..………..………..………..….. 6.4.2. Výběr testerů ………..………..………..………..………..………..…… 6.4.2.1. Předpoklady a požadavky na uživatele ………..………..……. 6.4.2.2. Předtestový dotazník ………..………..………..………..……. 6.4.3. Nastavení testu ………..………..………..………..………..………..… 6.4.4. Úkoly a vlastní testování ………..………..………..………..…………. 6.4.5. Výsledky testování ………..………..………..………..………..……… 6.4.6. Nalezené problémy a jejich možná řešení ………..………..………..…. 6.5. Vyhodnocení testování ………..………..………..………..………..………… xi

117 117 122 122 124 124 124 125 125 125 125 126 127 128 130

7. Závěr

131

8. Literatura

133

A Seznam použitých zkratek

135

B Testování použitelnosti – dotazníky B.1 B.2

137

Předtestový dotazník ………..………..………..………..………..……….. Potestový dotazník ………..………..………..………..………..………….

C Uživatelská příručka

137 138

140

C.1 Doporučené systémové požadavky ………..………..………..………..……. 140 C.2 Základní struktura aplikace, navigace ………..………..………..…………... 140 C.3 Přihlášení uživatele do systému ………..………..………..………….. 141 C.4 Odhlášení uživatele ze systému ………..………..………..………..………… 141 C.5 Správa uživatelů ………..………..………..………..………..………..……….. 141 C.5.1 Vytvoření nového uživatele ………..………..………..………..……… 141 C.5.2 Prohlížení seznamu uživatelů ………..………..………..………..…… 142 C.5.3 Prohlížení údajů o uživateli ………..………..………..………..……… 142 C.5.4 Změna uživatelských údajů ………..………..………..………..………. 143 C.5.5 Odstranění uživatele ………..………..………..………..…………… 143 C.6 Správa ubytování ………..………..………..………..………..………..…….. 143 C.6.1 Přidání nového ubytování ………..………..………..………..……….. 143 C.6.2 Seznam & Vyhledávání ubytování ………..………..………..…….. 144 C.6.3 Upravení údajů o ubytování & odstranění ubytování ………..……. 145 C.6.4 Prohlížení údajů o ubytování ………..………..………..………..…….. 145 C.7 Správa ceníku ………..………..………..………..………..………..………… 145 C.7.1 Přidání a správa typů pokojů ………..………..………..………..…. 145 C.7.2 Přidání sekce ceníku ………..………..………..………..………..…. 146 C.7.3 Správa cen ………..………..………..………..………..………..….. 147 C.7.4 Přidání a úprava období sekce ceníku ………..………..………..…. 147 C.7.5 Odstranění sekce ceníku ………..………..………..………..………. 147 C.8 Správa rezervace / rezervací ………..………..………..………..………..…... 148 C.8.1 Vytvoření nové rezervace ………..………..………..………..…….. 148 C.8.2 Správa rezervace ………..………..………..………..………..…….. 148 C.8.3 Vyhledávání rezervací ………..………..………..………..………… 154

D Obsah přiloženého CD

157

xii

Seznam obrázků 2.1 2.2

Komunikace serveru a klientského počítače po spuštění javascriptu .............. Ajax Architektura ..........................................................................................

6 7

3.1 3.2 3.3 3.4 3.5

Objednávka – stavový diagram ..................................................................... Diagram nasazení ......................................................................................... Use Case diagram nejvyšší úrovně, část 1 ……….……….……….………..... Use Case diagram nejvyšší úrovně, část 2 ……….……….……….………..... Harmonogram Projektu ……….……….……….……….……….………….....

10 14 16 17 23

4.1 4.2 4.3 4.4

4.25 4.26 4.27

Návrh uživatelského rozhraní – Přihlášení do systému ……….…………….. 26 Návrh uživatelského rozhraní – Odhlášení ze systému ……….…………….. 27 Návrh uživatelského rozhraní – Formulář pro vytvoření nového uživatele .. 29 Diagram Aktivit 1 – Vytvoření nového uživatele, Diagram Aktivit 2 – Editace uživatele ……….……….……….……….……….……….……….. 30 Návrh uživatelského rozhraní – Prohlížení údajů o uživateli systému …….. 32 Návrh uživatelského rozhraní – Seznam uživatelů ……….……….………… 34 Diagram Aktivit 3 – Odstranění uživatele, Diagram Aktivit 4 – Vyhledávání uživatelů ……….……….……….……….……….……….…… 35 Diagram Aktivit 5 – Správa ubytování ……….……….……….……….…… 36 Diagram Aktivit 6 – Vytvoření nového ubytování ……….……….………… 37 Návrh uživatelského rozhraní – Odstranění ubytování ……….……….……. 39 Návrh uživatelského rozhraní – Prohlížení údajů o ubytování ……….……. 40 Diagram Aktivit 7 – Správa produktů a ceníků ……….……….……….…… 43 Návrh uživatelského rozhraní – Přidání a editace produktů (typů pokoje) ubytování ……….……….……….……….………… 45 Návrh uživatelského rozhraní – Formulář pro přidání sekce ceníku ………. 47 Diagram Aktivit 8 – Editace ceníku, Diagram Aktivit 9 – Odstranění produktu ……….……….……….……….……….……….……… 48 Návrh uživatelského rozhraní – Formulář pro editaci a prohlížení ceníku ubytování ……….……….……….……….……….……… 53 Návrh uživatelského rozhraní – Prohlížení rezervace ……….……….…….. 56 Diagram Aktivit 9 – Správa rezervací ……….……….……….……….……. 57 Diagram Aktivit 10 – Přidání a změna klienta k rezervaci ……….………… 61 Návrh uživatelského rozhraní – Formulář pro přidání produktu k objednávce ……….……….……….……….……….……….…… 64 Diagram Aktivit 11 – Přidání objednávky ubytování k rezervaci, Diagram Aktivit 12 – Přidání produktu ubytování k objednávce ubytování. 65 Návrh uživatelského rozhraní – Editace produktů objednávky……….……. 67 Návrh uživatelského rozhraní – Změna stavu objednávky ……….………… 69 Návrh uživatelského rozhraní – Vyhledávání rezervací & seznam rezervací ……….……….……….……….……….……. 77 Konceptuální návrh databáze ……….……….……….……….……….…….. 85 Návrh základního uživatelského rozhraní v grafickém editoru ……….……. 93 Návrh dalších elementů aplikace zobrazených v obsahové části …………… 94

5.1

Fyzický datový model ……….……….……….……….…………………….

4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24

xiii

96

5.2

Základní adresářová struktura aplikace ……….……….……….……….…… 108

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11 C.12 C.13 C.14 C.15 C.16 C.17 C.18 C.19 C.20

Základní navigace systému ……….……….……….……….……….……… Přihlašovací formulář ……….……….……….……….……….……….…… Odhlášení ze systému ……….……….……….……….……….……….…… Formulář pro přidání nového uživatele ……….……….……….……….….. Stránka se seznamem uživatelů ……….……….……….……….……….…. Informace o uživateli ……….……….……….……….……….……….…… Formulář pro přidání nového ubytování ……….……….……….……….… Formulář pro vyhledávání ubytování & seznam ubytování ……….………. Spodní část formuláře pro úpravu a odstranění ubytování ……….……….. Ceník – Správa pokojů ubytovacího zařízení ……….……….……….……. Ceník – Formulář pro přidání nové sekce ceníku ……….……….………… Ceník – Formulář pro správu cen ……….……….……….……….………… Stránka s novou rezervací ……….……….……….……….……….……….. Rezervace – Formulář přidání klienta k rezervaci ……….……….………… Rezervace – Formulář pro editaci kontaktních údajů ……….……….…….. Rezervace – Objednávka ubytování ……….……….……….……….…….. Rezervace – Formulář pro editaci objednávky ubytování ……….………… Rezervace – Formulář pro editaci produktů objednávky ubytování ………. Rezervace – Formulář přidání platby k rezervaci ……….……….…………. Vyhledávání rezervací & Seznam rezervací ……….……….……….………

xiv

140 141 141 142 142 143 144 144 145 146 146 147 148 149 150 151 151 153 154 155

Seznam tabulek 3.1 3.2

Analýza rizik ……….……….……….……….……….……….……….…… Datový slovník ……….……….……….……….……….……….………….

18 21

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 5.29 5.30 5.31 5.32 5.33

Databázová tabulka slovnik ……….……….……….……….……….…….. Databázová tabulka uzivatelska_role ……….……….……….……….…… Databázová tabulka uzivatel ……….……….……….……….……….……. Databázová tabulka země ……….……….……….……….……….……….. Databázová tabulka oblast ……….……….……….……….……….………. Databázová tabulka mesto……….……….……….……….……….……….. Databázová tabulka cast_mesta ……….……….……….……….…………. Databázová tabulka kategorie ……….……….……….……….……….….. Databázová tabulka ubytovani ……….……….……….……….……….…. Databázová tabulka typ_pokoje ……….……….……….……….…………. Databázová tabulka produkt ……….……….……….……….……….……. Databázová tabulka sekce_ceniku ……….……….……….……….………. Databázová tabulka obdobi_sekce ……….……….……….……….………. Databázová tabulka cenik ……….……….……….……….……….……….. Databázová tabulka typ_platby ……….……….……….……….………….. Databázová tabulka cenik ……….……….……….……….……….……….. Databázová tabulka objednavka_ubytovani ……….……….……….…….. Databázová tabulka produkt_objednavky ……….……….……….……….. Databázová tabulka platba ……….……….……….……….……….……… Databázová tabulka partner ……….……….……….……….……….…….. Databázová tabulka objednavka_prepravy ……….……….……….……… Databázová tabulka sluzba ……….……….……….……….……….……… Databázová tabulka sezona_sluzby ……….……….……….……….……… Databázová tabulka objednavka_sluzby ……….……….……….…………. Databázová tabulka poradi ……….……….……….……….……….……… Databázová tabulka cms ……….……….……….……….……….……….… Databázová tabulka email ……….……….……….……….……….……….. Databázová tabulka kurz ……….……….……….……….……….………… Databázová tabulka typ_logu ……….……….……….……….……….…… Databázová tabulka log ……….……….……….……….……….…………. Seznam objektů aplikace ……….……….……….……….……….………… Seznam pluginů ……….……….……….……….……….……….…………. Seznam šablon ……….……….……….……….……….……….……….….

97 97 97 98 98 98 98 99 99 100 100 101 101 101 101 102 102 103 103 104 104 104 105 105 106 106 107 108 108 108 111 113 115

6.1 6.2 6.3

Sumář testování případů užití ……….……….……….……….……….…… Testování přístupnosti – kontrast barev ……….……….……….……….…. Vybraní testující pro testování použitelnosti ……….……….……….……..

118 123 125

xv

xvi

KAPITOLA 1. ÚVOD

1 Úvod V době konce prvního desetiletí nového milénia hrají počítače a různé systémy prim při automatizaci jednotlivých lidských činností. Je tomu tak i v případě cestovních agentur, které v současné době nabízejí své služby pomocí internetových prezentací. Ale nebylo tomu tak vždy. Podívejme se zpátky do 90. let 20. století, kdy se v České republice teprve začal internet vyvíjet. V této době cestovní agentury získávaly klienty úplně jinými způsoby, než je tomu dnes, např. i pomocí osobních kontaktů a známostí s dalšími lidmi nabízejícími podobné služby. Veškerá agenda byla závislá na dopisech, telefoznu, tužce či propisce a papíru. S masivním rozvojem internetu koncem 90. let a zejména začátkem 21. století se začaly rozvíjet technologie přístupné široké veřejnosti pro vývoj webových prezentací a posléze také automatizovaných informačních systémů využívající ke své práci databázové systémy. V této době začaly tyto společnosti využívat k prodeji svých služeb (zejména ubytování) možností internetu. V internetových prezentacích se objevovaly informace o nabízených ubytovacích zařízení, ale stále se musela objednávka řešit buď pomocí telefonu, nebo emailu. S rozvojem skriptovacích jazyků jako např. PHP a databázových systémů začaly vznikat první informační (rezervační) systémy, které dokázaly ukládat veškeré informace do databází, což bylo velmi flexibilní a urychlovalo to práci. Cestovní agentura Mery’s podniká v oboru nabízení ubytovacích zařízení již od roku 1991. Klientům nabízí jak své vlastní apartmány, tak i zprostředkovává ubytování v hotelích po celé České republice, Slovensku a Maďarsku. Agentura se převážně zaměřuje na zahraniční klientelu a od rezervačního systému si slibuje zjednodušení agendy společnosti a více zákazníků. Cílem aplikace je zejména zjednodušit správu cestovní agentury Mery’s, kdy veškeré informace budou uloženy v databázích a které budou kdykoliv jednoduše přístupné. Další cílem je zrychlit, zjednodušit a zefektivnit práci při vyřizování objednávek klientů. Takovýto systém umožní částečnou automatizaci úkonů, které by jinak musel dělat zaměstnanec společnosti. Z toho také vyplývá důležitý efekt, méně práce = méně zaměstnanců, rychlejší práce = možnost vyřídit více objednávek a předběhnutí konkurence = větší zisk pro firmu. Aplikace bude sloužit jak pro správu rezervací, tak i pro správu klientů a ubytovacích zařízení. Některé části budou v budoucnu propojené s webovou prezentací, objednávky z internetových stránek se budou automaticky ukládat do rezervačního sytému. Diplomová práce bude popisovat vývoj celého systému. Po této první kapitole následuje druhá kapitola popisující technologie využité pří implementaci systému. Následuje třetí kapitola obsahující úvodní studii, ve které je podrobně popsáno, co vše by měla aplikace umět. Čtvrtá kapitola se věnuje vlastní analýze návrhu. Zde jsou popsány případy užití, konceptuální schéma a návrh uživatelského rozhraní. Vše je popsáno podle pravidel jazyka UML. Pátá kapitola popisuje implementaci vlastního systému dle návrhu ze čtvrté kapitoly. Implementace je rozdělena do několika pod částí, jejichž vývoj může částečně probíhat samostatně a celek aplikace vznikne až po spojení všech těchto částí. Šestá kapitola pojednává o důležité fázi vývoje informačních systémů, testování implementace systému. V této části se dovídáme o několika metodách testování, které byly použity v této práci, jako např. testování použitelnosti a přístupnosti. Nedílnou součástí práce je také uživatelská příručka sloužící jak pro administrátory systému, tak i pro běžné uživatele.

1

KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY

2 Použité technologie a metodiky Vzhledem k jednomu z hlavních požadavků, možnosti propojit informační systém s webovou prezentací, která již existuje a je naprogramovaná pomocí HTML a PHP, jsem zvolil pro implementaci níže uvedené technologie. Hlavním úkolem systému bude shromaždovat a udržovat klientská data. Tato data budou ukládána do vhodné databáze, ze které bude systém tato data jednoduše získávat. Tato kritéria splňuje databázový systém MySQL, který je navíc Open Source, tudíž zdarma. Databázový systém poběží na taktéž volně dostupném serveru Apache. Spolu se skriptovacím programovacím jazykem PHP tvoří silnou trojici pro vytvoření libovolné webové aplikace.

2.1. X(HTML) XHTML (extensible hypertext markup language) je značkovací jazyk pro tvorbu hypertextových dokumentů v prostředí WWW. Původně měl být nástupcem jazyka HTML (poslední verze 4.01), ale v současné době je ve vývoji nová verze HTML 5. Přesto při programování budu využívat pravidel XHMTL. Pro XHTML existují 3 verze: • XHTML 1.0 Strict – Využívá se pro tvorbu strukturovaných stránek osvobozených od formátovacích značek. Pro tvorbu struktury se využívá kaskádových stylů CSS. Z této verze budu vycházet. • XHTML 1.0 Transitional – Vhodné pro tvorbu stránek určených i pro staré prohlížeče bez použití kaskádových stylů CSS. • XHTML 1.0 Frameset – Stejné jako „Transitional“, navíc podporuje tvorbu rámců. Rozdíly mezi XHTML a HTML: • V XHTML oproti HTML musí být každý tag včetně nepárových ukončen. Ukončení lze u nepárového tagu provést např. pomocí lomítka uvnitř tagu (např. obrázek ). • V XHTML musí být všechny tagy a jejich atributy napsány malými písmeny. • V XHTML musí být všechny atributy tagů uzavřeny do uvozovek. • Dokument musí začínat XML deklarací.

2.2. CSS CSS (Cascading Style Sheets) je jazyk pro popis způsobů zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML vytvořený standardizační organizací W3C (mezinárodní konsorcium pro vývoj webových standardů). Hlavním cílem jazyka je umožnit vývojářům oddělit vzhled dokumentu od struktury a obsahu. V současné době byly vydány 2 specifikace jazyka CSS1 a CSS2, třetí specifikace CSS3 je stále ve vývoji. CSS nahrazuje nedokonalé formátování textů pomocí HTML tagů, které se v současné době již nevyužívá. Hlavní výhody CSS stylů: • Více možností formátování dokumentu oproti HTML (např. jednoduché odsazení bloku od okraje stránky pomocí atributů margin a padding).

2

KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY •

• •

•

Konzistentní styl – Na všech stránkách dokumentu mohou být stejně formátovány nadpisy, odstavce, seznamy či obrázky díky vytvoření souboru se stylem, který se připojuje ke všem stránkám HTML dokumentu. Oddělení obsahu a struktury od vzhledu. Dynamická práce se styly o Např. při změně barvy odkazů bychom museli u HTML formátování změnit barvu u všech odkazů v dokumentu zvlášť. U CSS nám stačí upravit soubor se stylem. Kratší doba načítání stránky.

Jako každý programovací jazyk má i CSS několik nevýhod. Největší a zároveň nejproblémovější nevýhodou pro programátory je různá interpretace CSS nejrozšířenějších prohlížečů. V současné době využívá prohlížeč Internet Explorer přibližně 2/3 populace, Mozillu Firefox cca. 15% lidí. Interpretace některých stylů se liší nejen mezi těmito 2 nejrozšířenějšími prohlížeči, ale také mezi různými verzemi stejných typů. Rozdíl mezi IE6 (tuto verzi dosud využívá cca. 40% lidí používající prohlížeče IE) a IE7 je markantní. Programátor proto musí ladit vzhled minimálně pro 4 prohlížeče najednou.

2.3. PHP PHP (Hypertext Preprocesor) je skriptovací programovací jazyk určený pro programování dynamických webových stránek [1]. PHP se většinou začleňuje přímo do struktury jazyka (X)HTML. PHP skripty jsou prováděny na straně serveru, uživateli se pouze zobrazí výsledek těchto skriptů. Je nezávislý na typu operačního systému. Syntaxe jazyka vychází z několika programovacích jazyků jako je např. Pascal, C, Java aj. Obsahuje v sobě knihovny funkcí pro práci s textem, grafikou, soubory a také pro přístup k mnoha typům databázových serverů (např. MySQL, MSSQL, PostgreSQL, Oracle aj.). Poskytuje také možnost práce s mnoha internetovými protokoly (HTTP, FTP, POP3, IMAP aj.). PHP je šířen jako Open Source a v kombinaci s webovým a databázovým serverem se stal silným nástrojem pro tvorbu webových stránek a aplikací. Počátek vývoje je datován k roku 1995, kdy vzniklo PHP 1.0. Stále aktuální a používanou verzí je PHP 4. Nejnovější verze PHP 5 se dočkala významného rozšíření podpory objektově orientovaného programování (OOP). Byly přidány tyto OOP funkce: • Konstruktory, destruktory • Public, priváte, protected proměnné a metody • Interface • Abstraktní třídy • Statické proměnné a metody • Objekty jsou vždy volané odkazem PHP 5 také vylepšuje práci s MySQL databází a přidává více možnosti pro práci s XML. Podporuje ošetření chyb pomocí vyjímek try a catch. Výhody PHP: • Specializované přímo pro tvorbu webových stránek. • Obrovské množství základních funkcí v knihovnách PHP. • Nezávislost na operačním systému. 3

KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY • • • •

Podpora mnoha databázových systémů. Většina hostingových serverů podporuje PHP. Velké množství příkladů + dostupná dokumentace. OpenSource.

Nevýhody: • Jazyk PHP není nikde definován, je jen popsán implementací. • Ve standardních instalacích chybí ladící nástroje .

2.4. Smarty Smarty [3] je šablonovací systém vytvořený za použití skriptovacího jazyka PHP. Hlavním smyslem je snaha oddělit aplikační logiku od té prezentační použitím speciálních znaků a příkazů. Výhodou je rozdělení práce na jednom projektu více lidem s různými znalostmi (člověk ovládající HTML může vytvářet šablony stránek bez znalosti složité implementace aplikační logiky v PHP – pouze může obdržet od programátora sadu názvů proměnných s informací o jejich obsahu). Tvorba šablon není omezena pouze využitím HTML značek, ale Smarty také umožňuje použití řídících struktur, cyklů, různých vestavěných funkcí pro práci s textem či časem. Základ syntaxe tohoto systému tvoří dvojce oddělovačů { a }, mezi které se vkládají všechny tagy (proměnné, komentáře, příkazy,…). Všechny proměnné začínají symbolem $. Pomocí rezervované proměnné $smarty lze přímo ze šablony přistupovat ke globálním PHP proměnným jako např. $_POST, $_SERVER, $_SESSION aj. Příklady syntaxe lze vidět níže v ohraničeném boxu. Velkým přínosem Smarty je možnost kompilace šablon. Při prvním volání (spuštění) šablony se šablona zkompiluje do běžného PHP skriptu, který se uloží na příslušném místě na serveru. Při dalším použití šablony se již využívá existující zkompilované verze, což zvyšuje rychlost načtení webové stránky. Další výhodou je jednoduchá rozšiřitelnost o vlastní funkce (existuje mnoho předpřipravených funkcí) a rozsáhlá projektová dokumentace. Výběr z nejdůležitějších Smarty funkcí uložených v hlavní třídě smarty.class.php a zároveň příklad PHP kódu, který předá šabloně několik proměnných a zároveň šablonu zobrazí, uvádím zde: assign(“jmeno”, “Jirka Snizek”); // Vytvoření pole čísel a přiřazení tohoto pole Smarty proměnné “cisla” $cisla[0]=3; $cisla[1]=7; $cisla[2]=13; $smarty->assign(“cisla”, $cisla); // Přířazení aktuálního dne Smarty proměnné „aktualni_datum“ $dnes=date( “Y-m-d” , time() ); // dnešní datum v klasickém PHP formátu $smarty->assign(“aktualni_datum”, $dnes); $smarty->assign(“uvodni_text”, “Toto je uvodni text, ktery bude preveden na velka pismena”); Zobrazení šablony $smarty->display(„uvodni_stranka.tpl“); ?>

4


Zdrojový kód šablony uvodni_stranka.tpl: Úvodní stránka
Ahoj {$jmeno }
// zobrazení dnešního data v českém formátu – 2 způsoby
Dnes je: {$smarty.now|date_format:"%d-%m-%Y"}

Dnes je: {$ aktualni_datum|date_format:"%d.%m.%Y"}

{$uvodni_text|upper|truncate:53}
// zobrazení textu z proměnné $uvodni_text a ten se vypíše velkými písmeny // pokud je text delší než 20 znaků, zobrazí se jen 20 znaků a 3 tečky
Vaše štastná čísla pro dnešní den jsou: {foreach from=$cisla key=”klic” item=”stastne_cislo”} // pokud je šťastné číslo 13, vypíše se tučným červeným písmem {if $stastne_cislo==13} <span style=”color:red;font-weight:bold”>{$stastne_cislo} , {else} {$stastne_cislo} , {/if} {/foreach}

Zobrazení šablony v prohlížeči:

Ahoj Jirka Snizek Dnes je: 16-10-2009 Dnes je: 16-10-2009 TOTO JE UVODNI TEXT, KTERY BUDE PREVEDEN NA VELKA PIS… Vaše štastná čísla pro dnešní den jsou: 3 , 7 , 13 ,

2.5. JavaScript JavaScript je multiplatformní, objektově orientovaný skriptovací jazyk, využívaný při programování internetových stránek. Jedná se o klientský skript. To znamená, že se program (skript) odesílá spolu se stránkou ke klientovi (do prohlížeče) a tam se teprve provede. Viz obrázek 2-1. Skripty se píšou přímo do HTML, nebo jsou uloženy v externím souboru a logicky připojovány k HTML stránce pomocí odkazu. Podporuje ho většina prohlížečů, avšak ne každý

5

KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY prohlížeč podporuje všechny dostupné funkce (nutnost ladit pro více typů internetových prohlížečů). JavaScript je často využíván pro ovládání interaktivních prvků GUI (tlačítka, textová pole) nebo pro vytváření animací a obrazových efektů. Často je také využíván pro kontrolu různých formulářových dat před odeslání na server (v případě chybně vyplněných údajů se stránka znovu nenačítá a na chybu je uživatel upozorněn přímo prohlížečem). Výhodou je rychlejší odezva pro uživatele. Omezením tohoto jazyka jsou možnost uživatelem zakázat používání javascriptu v prohlížeči (je nutné zabezpečit funkčnost stránky i při vypnutém javascriptu), neumí přistupovat k souborům (kromě cookies) a neumí uložit žádná data (řeší PHP aj.).

Obrázek 2-1 : Komunikace serveru a klientského počítače (prohlížeče) pro spuštění skriptů v jazyce JavaScript.

2.6. AJAX AJAX (Asynchronous JavaScript and XML) je technologie postavená na skriptovacím jazyku JavaScript, jenž umožňuje zasílat HTTP požadavky serveru bez nutnosti načíst nově stránku. Umožňuje změnit obsah webové stránky, aniž by došlo k jejímu znovunačtení. K tomu využívá jazyka XML pro komunikaci s PHP skripty. Pro zasílání požadavků přes HTTP protokol je v javascriptu objekt XMLHttpRequest. Získání nového obsahu pomocí AJAXU probíhá v několika krocích: a. Vytvoření objektu XMLHttpRequest. b. Vytvoření spojení s požadovaným skriptem uloženým na serveru. c. Zaslání požadavku na server včetně proměnných pro skript. d. Přijmutí dat (nebo chybových hlášení) a zpracování dat. Nejčastěji se AJAX využívá např. pro tzv. našeptávače, kde se při psaní textu do textového pole při každé změně odesílá hodnota textového pole na server a od něj dostáváme nápovědu se slovy, která bychom mohli chtít napsat. Vše probíhá tak, že uživatel nepozná komunikaci se serverem. Dalším příkladem je hlasování v anketách, kde se po hlasování zobrazí nový stav ankety, aniž by se znovu načetla stránka. Výhodou je, že při využití Ajaxu se nenačítá celá stránka (nemusí se skládat celý HTML dokument), ale pouze provedené změny a tím se zrychlí zobrazení změn na stránce. Jelikož lze v prohlížeči zakázat používání javascriptu, tak je třeba implementovat použitelnou verzi i bez použití ajaxu.

6


Obrázek 2-2 : Ajax architektura.

2.7. MySQL MySQL je multiplatformní databázový server (aktuální verze 5.1.33). Komunikace s ním probíhá pomocí jazyka SQL (Structured query language). SQL je standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích. Díky snadné implementovatelnosti, multiplatformnosti, výkonu a open source licenci je MySQL jednou z nejpoužívanějších databází. Obvykle se využívá spolu s PHP a serverem Apache. Nabízí několik typů databázových tabulek, které se liší svými vlastnostmi a možnostmi použití. Nejpoužívanějšími jsou MyIsam (bez podpory transakci) a InnoDB (podporuje transakce). Pro snazší správu databáze byl vytvořen nástroj phpMyAdmin, jenž umožňuje jednoduchou správu obsahu databáze prostřednictvím webového prostředí. Silnějším nástrojem vývojářů je však správa databáze pomocí příkazové řádky.

2.8. Apache Http Server Apache je multiplatformní webový (Http) server s otevřeným kódem, který se v současnosti používá na většině serverů. Webový server je odpovědný za vyřizování http požadavků (odeslání webové stránky klientovy) od klientů (webových prohlížečů).

7

KAPITOLA 3. ÚVODNÍ STUDIE

3 Úvodní studie 3.1. Deklarace záměru Informační systém cestovní agentury je určen pro agentury nabízející ubytování a další služby spojené s cestováním. Projekt si klade za cíl vytvořit evidenci ubytovacích kapacit, přepravních a doplňkových služeb agentury, evidenci klientů. V návaznosti na tyto evidence vytvořit rezervační systém, jenž bude sloužit pro evidenci objednávek ubytování od klientů. Systém by měl být navržen tak, aby ho bylo možné jednoduše propojit s webovou prezentací, kde agentura nabízí ubytování. Součástí systému také budou požadované statistiky související s rezervacemi ubytování.

3.2. Odborný článek Informační systém cestovní agentury (dále IS) slouží k zaznamenávání objednávek ubytování či dalších přidružených služeb. IS je určen společnostem (cestovní agentury, hotely aj.), které nabízejí ubytování třetím stranám (klienti, firmy) a potřebují vést evidenci o objednávkách na jednotlivá ubytovací zařízení. Evidence je myšlena nejen jako tabulka (databáze), ale možnost záznamy vkládat, editovat a mazat. 3.2.1. Ubytovací zařízení V konkrétním případě má cestovní agentura smluveno několik stovek hotelů a penzionů, které nabízí prostřednictvím webové prezentace a potřebuje o nich uchovávat důležité informace, mezi které patří popis ubytování, poskytované služby, kategorie ubytování, interní údaje pro agenturu aj. Každé ubytovací zařízení může obsahovat několik typů pokojů s různými cenami pro každý z typů pokoje. V různých časových obdobích se mohou lišit ceny jednotlivých pokojů. Budou zadávány 3 typy cen: pultová cena hotelu, nákupní cena agentury a prodejní cena. Ceny budou udávány v českých korunách, nebo v eurech a mohou být zadány jako standardní (katalogové), speciální nabídky nebo top termíny. Systém bude umožňovat vyhledávat v databázi ubytovacích zařízení podle různých parametrů ubytování i dle počátečního písmena názvu zařízení. 3.2.2. Doplňkové služby S ubytováním souvisí další doplňkové služby. Agentura může nabízet různé transportní služby jako např. odvoz klienta z letiště do hotelu a zpět. Předpokládá se externí spolupráce s několika dopravními společnostmi, které je potřeba evidovat. Další doplňkové služby agentura zařizuje až na žádost zákazníka. U těchto služeb je přepokládán častých zásah do jejich evidence, a proto je důležitá jednoduchost jejich správy. 3.2.3. Uživatelé, klienti Systém také bude uchovávat informace o uživatelích, kteří poptávají ubytování. V této evidenci budou zahrnuti i zaměstnanci společnosti.

8

KAPITOLA 3. ÚVODNÍ STUDIE 3.2.4. Rezervace Stěžejní část systému tvoří správa rezervací. Vlastní rezervace se skládá z několika částí: • vlastní informace o rezervaci – datum vzniku, typ rezervace • informace o měnových kurzech • zaměstnanci, kteří spravují danou rezervaci • detaily o klientovi • objednané služby o ubytování o transfer o ostatní doplňkové služby • informace o platbách • komentáře Cestovní agentura přijímá 2 typy objednávek: emailovou/telefonickou a internetovou objednávku. Pokud přijde emailová poptávka, zaměstnanec (dále jako uživatel) vytvoří prázdnou rezervaci. Této rezervaci buď přiřadí již existujícího klienta, nebo přímo v rezervaci vytvoří nového. Uživatel se automaticky stává vlastníkem (správcem) rezervace. Následně již půjdou přidávat ubytovací zařízení a služby, které si klient objednává. Kliknutím na tlačítko „Přidej ubytování“ půjde přidat objednávka ubytovacího zařízení včetně požadovaného typu pokoje (pokojů) a dat, kdy se má pobyt uskutečnit. Tato objednávka bude mít několik stavů: 1. 2. 3. 4. 5. 6.

Vytvořená (vznik objednávky) Předběžná (partner CA potvrdil objednávku a stanovil opci) Fixní (klient zaplatil požadovanou částku) Využívaná (klient využívá ubytování, službu) Ukončená (klient ukončil pobyt, službu) – konečný stav Zrušená (klient zrušil objednávku, nebo nezaplatil do propadnutí opce) – konečný stav 7. Fixně zrušená (klient zrušil objednávku a zaplatil storno poplatky) – konečný stav Stavový diagram objednávky je zobrazen na obrázku 3-1. Ze stavu 1 a 2 se při zrušení objednávky dostane do stavu 6, ze stavu 3 do stavu 7 (fixní objednávka zrušena). Do rezervace půjde přidat neomezené množství objednávek ubytování a ty půjdou měnit v 1. až 3. stavu. Stejně jako pro ubytování bude fungovat správa dalších nabízených služby (transfery aj.). Pokud přijde internetová objednávka, systém automaticky vytvoří novou rezervaci včetně nového uživatele a do rezervace přidá zvolený typ ubytování. Dále vše funguje stejně jako u emailové objednávky.

9


Obrázek 3-1 : Objednávka – stavový diagram. Další důležitou částí je evidence plateb za objednané služby. Platba je navázána na konkrétní rezervaci. Za každý typ služby (ubytování, transfery aj.) se eviduje platba zvlášť. Může existovat několik plateb za jednu službu. Klient platí bud zálohu, nebo celé ubytování (službu). Může platit několika možnými způsoby (hotově, kartou aj.). Systém by měl zajišťovat propojení evidence plateb s firemním účetním programem. Poslední částí rezervačního formuláře bude statistika příjmů za danou rezervaci společně s informací o platbách klienta, případně kolik je ještě potřeba zaplatit. V systému by měla existovat stránka, která bude zobrazovat nezaplacené objednávky. Rezervace bude možné vyhledávat podle různých parametrů (číslo rezervace, jméno klienta, emailová adresa, ubytování, data uskutečnění pobytu aj.). Dále bude existovat výpis všech rezervací řazených podle data vzniku, kliknutí na konkrétní rezervaci se otevře okno s detailem o rezervaci. Další částí systému budou přehledy rezervací: • Právě probíhající objednávky (klienti, kteří aktuálně využívají našich služeb) • Příjezdy klientů v aktuální den • Odjezdy klientů v aktuální den • Transfery v aktuální den • Přehled všech transferů • Evidence všech plateb Kliknutím na konkrétní údaj ve všech přehledech se otevře detail dané rezervace.

10

KAPITOLA 3. ÚVODNÍ STUDIE 3.2.5. CMS Systém Nástavbou rezervačního systému by měl být Systém pro správu obsahu (CMS), který bude určen pro vytváření obsahu pro webovou prezentaci. Předpokládá se prezentace v několika světových jazycích. Omezená část pracovníků bude moci vytvářet obsah, všichni uživatelé budou moci překládat texty do ostatních jazyků. Tyto překlady nebudou automaticky veřejné, ale bude existovat uživatel s právem tyto texty publikovat, nebo je vrátit k překladu. 3.2.6. Statistiky Statistiky ne přímo související s rezervacemi. Tyto statistiky budou určeny pouze pro uživatele „manažer“. • Statistika měsíčních a ročních příjmů, nákladů, zisků, počtu ubytovaných osob pro kategorie ubytovacích zařízení a také pro jednotlivé hotely. • Měsíční a roční statistika počtu ubytovaných osob podle národnosti a kategorie ubytování. • Měsíční a roční statistika příjmů a nákladů za ostatní služby. • Měsíční a roční statistika rezervací dle prodejců (seznam rezervací včetně příjmů, nákladů, názvu ubytování či služby, data, počtu osob a prodejců, kteří se na dané rezervaci podíleli).

3.3. Katalog požadavků 3.3.1. Uživatelské role Systém bude obsahovat 5 uživatelských rolí s různými pravidly přístupu. 3.3.1.1. Klient V systému nebude mít žádná práva, pouze se budou uchovávat data o klientovi v databázi pro případ vzniku klientského rozhraní v prezentačním webu. 3.3.1.2. Prodejce Tento uživatel se stará o správu objednávek klientů. Vyřizuje veškeré náležitosti rezervace včetně plateb, může přidávat nové klienty do databáze. Dále má přístupnou omezenou část CMS systému, kde může překládat texty a posílat je k publikaci. Pokud při přihlášení do systému dojde k opakovanému špatnému zadání uživatelského jména a hesla, dojde k zablokování přístupu a odeslání varování administrátorovi. Pokud uživatel zapomene heslo, otevře si formulář pro zaslání nového hesla na email. Poté systém automaticky vygeneruje nové heslo a odešle nové údaje na email, který je uveden v systému u daného uživatele.

11

KAPITOLA 3. ÚVODNÍ STUDIE 3.3.1.3. Správce CMS Uživatel, který má všechny pravomoci v CMS systému, může přidávat nový obsah, překládat a také publikovat veškeré texty. 3.3.1.4. Manažer Hierarchicky nad prodejcem a správcem CMS – přebírá všechny jejich pravomoci. Dále může spravovat ceníky, evidence ubytování, doplňkových služeb a evidenci uživatelů. 3.3.1.5. Administrátor Nejvyšší pravomoci. Může vše, co ostatní uživatelé, navíc může měnit veškeré údaje o uživatelích včetně jejich hesel. Spravuje IS a řeší vzniklé problémy se systémem. 3.3.2. Funkce systému 3.3.2.1. Služby systému pro klienta •

V současné době se neplánují žádné služby pro klienta

3.3.2.2. Služby pro prodejce • • • • •

• • • • • •

přihlášení do systému odhlášení ze systému změna osobních kontaktních údajů vytvoření prázdné rezervace správa rezervace o odstranění rezervace o vytvoření nového uživatele – klienta o editace osobních údajů klienta o přidání ubytování k rezervaci o přidání, editace a odstranění typu ubytování k rezervaci a ubytovacímu zařízení o přidání, editace a odstranění doplňkové služby o přidání, editace a odstranění platby za ubytování či službu o vložení a editace komentáře k rezervaci prohlížení rezervací vyhledávání v evidenci rezervací prohlížení rezervačních reportů překlad existujících frází v CMS systému editace osobních údajů v systému prohlížení evidence ubytování

3.3.2.3. Služby pro správce CMS systému •

prohlížení textů v CMS systému 12

KAPITOLA 3. ÚVODNÍ STUDIE • • • • •

vložení nového textu do slovníku editace originálních textů a překladů ve slovníku odstranění textu včetně jeho překladů ze slovníku překlad textu do dalšího jazyka schválení překladu textu z „hlavního“ jazyka – zveřejnění překladu na webu (pokud je daný text umístěn na stránkách)

3.3.2.4. Služby pro manažera Manažer obecně přebírá veškerá práva prodejce. K tomu mu náleží další práva: • • •

• • • • •

přidání nového ubytovacího zařízení (hotelu, penzionu, apartmánu aj.) editace a odstranění ubytovacího zařízení z evidence ubytování včetně všech příslušných produktů a ceníků správa produktů a ceníků k danému ubytovacímu zařízení (produktem je v tomto případě myšleno typ ubytování – typ pokoje) o přidání, editace a odstranění produktu o přidání období pro ceníky – období, pro které budou platit vložené ceny za dané produkty po vložení časového období dojde k přidání ceníkové tabulky o editace a odstranění časového období, při odstranění časového období dojde k odstranění ceníku pro dané období o editace ceníku editace uživatelských-klientských údajů odstranění uživatele-klienta přidání, editace a odstranění služby transferu přidání, editace a odstranění ostatní doplňkové služby prohlížení „manažerských“ statistik (viz. 1.7)

3.3.2.5. Služby pro administrátora Administrátor je správce informačního systému s neomezenými právy užívání. Kromě již jmenovaných služeb ostatních typů uživatelů může administrátor: • •

přidávat, editovat a mazat údaje o všech uživatelích měnit přístupová hesla do systému

Administrátor bude také řešit problémy vzniklé v systému a měl by radit uživatelům, jak se systémem pracovat. 3.3.3. Nefunkční požadavky IS bude implementován jako webová aplikace a bude umístěna na některém z hostingových serverů. Bude přístupný z jakéhokoliv počítače připojeného k internetu. IS bude implementován tak, aby fungoval nezávisle na operačním systému a webovém prohlížeči. Důležitá je možnost navázat informační systém na již existující webovou prezentaci, která je implementována pomocí PHP a MySQL databáze. 13


3.4. Návrh architektury Komunikace uživatelů s informačním systémem cestovní agentury bude probíhat přes webové rozhraní pomocí libovolného internetového prohlížeče splňujícího požadavky uvedené v 3.4.1. Tuto komunikaci zachycuje diagram nasazení na obrázku 3-2. Informační systém bude koncipován jako webová aplikace, která bude celá uložena na vhodném webhostingovém serveru. Požadavky na server jsou uvedeny v kapitole 3.4.2. Požadavky na terminálové stanice uživatelů systému jsou uvedeny v kapitole 3.4.3.

Obrázek 3-2: Diagram nasazení.

3.4.1. Požadavky na softwarové vybavení uživatelů systému • •

•

Libovolný operační systém. Internetový prohlížeč podporující: o Kaskádové styly – specifikace CSS1. o Podpora skriptovacího jazyka JavaScript. Doporučené www prohlížeče: Internet Explorer verze 7 a vyšší, Mozilla Firefox verze 2 a vyšší, Opera verze 8 a vyšší.

3.4.2. Požadavky na hardwarové, softwarové vybavení a obecné požadavky na webový server 3.4.2.1. Softwarové vybavení 14

KAPITOLA 3. ÚVODNÍ STUDIE • • •

Libovolný operační systému. Webový server Apache s podporou PHP 5. Databázový server MySQL verze 4.1 a vyšší.

3.4.2.2. Hardwarové vybavení • •

Velká kapacita diskového prostoru (minimálně několik GB). Velká operační paměť.

3.4.2.3. Obecné požadavky • • • •

•

Neomezený FTP přístup. Správa htaccess včetně mod-rewrites. Pravidelné zálohy databáze (alespoň denní zálohy). Cron – tzv. plánovač úloh, který umožňuje spouštět v pravidelných časových intervalech požadované příkazy (např. php skripty). U rezervačního systému půjde například o automatickou změnu stavu rezervace, nebo aktualizace kurzovního lístku. Non-stop technická podpora.

3.4.3. Požadavky na HW vybavení počítačů uživatelů informačního systému • •

Libovolný počítač umožňující rychlou práci s www prohlížečem. Připojení k internetu.

3.5. Harmonogram projektu Harmonogram projektu je koncipován s faktem, že je projekt tvořen také v rámci diplomové práce. Vzhledem k ostatním školním a pracovním povinnostem jsem vyhradil čas na projekt okolo 25 hodin týdně. Prvním úkolem bylo zjistit současný stav softwarového vybavení, které využívá CA, a definovat záměr projektu. Po několika schůzkách se zadavatelem začala práce na Úvodní studii. Úvodní studie byla konzultována se zadavatelem a výstupem bylo několik úprav a nových požadavků. V druhé fázi projektu přijde na řadu podrobná analýza návrhu. Bude vytvořen databázový model pro uložení dat a blíže popsány případy užití vznikajícího systému. Navíc bude vytvořen základní grafický návrh aplikace. Následná implementace bude vycházet z předchozí analýzy a v jejím průběhu bude také konzultována se zadavatelem. Po implementaci přijde na řadu testování vzniklé aplikace. Testovat se bude tzv. „průchodem“ bez využití potencionálních uživatelů systému. Naopak k testování použitelnosti a přístupnosti systému již využiji potencionální uživatele systému. Podle závěrů z testování dojde k úpravě (opravě) aplikace. V poslední fázi bude vytvořena uživatelská a administrátorská dokumentace a dojde k nasazení systému k zadavateli.

15

KAPITOLA 3. ÚVODNÍ STUDIE Pro tvorbu harmonogramu projektu jsem využil program GantProject, se kterým jsem se již setkal v předmětu „Návrh a řízení projektu, technická komunikace“. Harmonogram projektu je zobrazen na obrázku 3-5.

3.6. Use Case nejvyšší úrovně UseCase neboli případy použití slouží pro zobrazení funkčnosti budoucího informačního systému a tím také vymezuje jednoznačně rozsah systému. Use Case zachycuje zadavatelovy požadavky na systém, ukazuje hranice mezi systémem a jeho okolím (okolím se myslí uživatelé, procesy a vztahy, které sice systém ovlivňují, ale nejsou jeho přímou součástí) a také typy uživatelů, kteří budou využívat. Případy užití jsou zachyceny ve vizuální a textové podobě. Diagramy případů užití poskytují rychlou představu o jednotlivých funkcích systémů, přesné postupy a rozšiřující scénáře zachycuje textová podoba. Na obrázcích 3-3 a 3-4 je zobrazen Use Case nevyšší úrovně.

Obrázek 3-3: Use Case diagram nejvyšší úrovně, část 1.

16


Obrázek 3-4: Use Case diagram nejvyšší úrovně, část 2.

3.7. Analýza rizik Vývoj každého softwarového projektu s sebou přináší určitá rizika, která jsou potřeba u konkrétního projektu specifikovat, odhadnout pravděpodobnost výskytu a nalézt možnosti zmírnění dopadu daných rizik. U softwarových projektů jsou jedna z nejběžnějších rizik tato: nekorektní chování aplikace, pozdní dodání a odmítnutí aplikace uživatelem. Vývoj Informačního systému cestovní agentury s sebou přináší tato rizika: 1. Funkční rizika a. Chyby v analýze – Analýza byla špatně provedena. b. Chyby ve funkci systému – aplikace funguje odlišně od požadavků zadavatele. Špatný výstup pro programátora či nepochopení problému programátorem. c. Složitost aplikace a nedostatečná dokumentace – Aplikace je složitá na ovládání, uživatel nemůže nalézt pomoc v dokumentaci, která je buď nedostatečná, nebo nepochopitelná. 2. Implementační a technologická rizika a. Chyba v kódu aplikace – Aplikace byla nekorektně naprogramovaná. b. Špatná volba technologie, na které bude aplikace postavena. c. Špatná volba technologií vzhledem k rychlosti aplikace – Aplikace poběží na některých systémech a prohlížečích velmi pomalu. d. Chyba vzhledu v určitých webových prohlížečích – Každý webový prohlížeč může různě interpretovat CSS tagy, zejména se jedná o starší verze prohlížečů. 3. Rizika personální a obchodní a. Nedodržení termínu na dokončení a odevzdání aplikace. b. Nedostatečná kvalifikace uživatelů – aplikace bude příliš obtížná k užívání pro běžného uživatele. c. Změna rozsahu projektu – Zákazník chce výrazně změnit fungování systému. 17

KAPITOLA 3. ÚVODNÍ STUDIE d. Zrušení projektu zákazníkem – Zákazník se dostane do finančních problémů a ukončí činnost v oboru. 4. Bezpečnostní rizika a. Proniknutí nepovolaných osob k chráněným částem systému – Uživatel s určitou systémovou rolí může pracovat s částmi systému, ke kterým by neměl mít přístup. b. Úspěšné napadení systému hackerem. c. Ztráta dat. Následující tabulka popisuje odhad pravděpodobnosti výskytu výše popsaných rizik, návrh řešení, jak předejít daným rizikům a ohodnocení dopadu při vyplnění se daného rizika. Dopad jsem rozdělil do 4 stupňů: • • • •

Rizi ko

Odhad ppsti. výskytu

zanedbatelný marginální kritický katastrofický

Dopad

1. a

10 %

Kritický

1. b

10%

Marginální

1. c

20%

Marginální

Vysvětlení odhadu pravděpodobnosti (+ označuje důvody pro snížení rizika, - pro zvýšení rizika) - Nemám dostatek zkušeností s analýzami. + Mohu se opřít o rady vedoucího práce. + Aplikace vyvíjím pro konkrétní společnost, proto mohu využít konzultace se zadavatelem. Odpovídá odhadu rizika 1.a. + Budu sám implementovat aplikaci - Nemám velké zkušenosti s vývojem takto rozsáhlé aplikace. - Pro psaní dokumentace nejsem příliš dobře jazykově vybaven. +Mám zkušenosti s vytvářením menších dokumentací a pracoval jsem již s jiným rezervačním systémem.

18

Návrh řešení Časté konzultace se zákazníkem, v případě nejasnosti žádat o opakované vysvětlení požadavku. Využívat a striktně dodržovat pravidla UML.

Podrobný a přesný výstup pro programátora. Konzultace s programátorem během implementace. Konzultace se zákazníkem. Testováním odhalíme složitost aplikace – následná úprava implementace. Testování dokumentace s běžným uživatelem.

KAPITOLA 3. ÚVODNÍ STUDIE 2. a

10%

Marginální

- Budoucí systém bude velmi rozsáhlý, bude mnoho souborů se zdrojovými kódy, které budou různě propleteny. +Mám zkušenosti z testováním systémů, a proto bych měl být schopen chyby odhalit . + Vzhledem ke zkušenostem a doporučením od lidí z oboru mohu toto riziko vyloučit. + Malý výběr mezi technologiemi. - Systém bude složitý + Zkušenosti získané ve škole při vývoji školních prací. + Existují rozsáhlé dokumentace a diskusní fóra pro jednotlivé technologie.

2. b

1%

Kritický

2. c

20%

Marginální

2. d

15%

3. a

50%

Zanedbatel - Rozdíl v reprezentaci CSS -ný stylů již mezi IE6 a IE7, natož s ostatními typy prohlížečů + Všechny důležité prohlížeče jsou volně přístupné (zdarma). + Zadavatel nepožaduje funkčnost systému pro prohlížeč IE6, kde by mohl nastat největší problém. Marginální - Systém bude velmi rozsáhlý & čas na celkový projekt je pouze v rozsahu času diplomové práce. - Pouze implementace takovéhoto systému spolu s testováním je otázka několika měsíců a nejsem si jistý, zda pouze pro jednoho programátora. 19

Testování aplikace – Nasazení beta verze přímo k uživateli.

Vzhledem k výběru již vyzkoušených a ve velké míře využívaných technologií (apache, php, xhtml) lze tento typ rizika zanedbat. Podrobné prostudování dokumentací k jednotlivým technologiím před zahájením implementace. Prostudování diskusních fór a hledání možných vad těchto technologií. Testování aplikace na různých systémech s různou konfigurací + testování aplikace pro všechny využívané webové prohlížeče. Správný návrh uživatelského rozhraní. Testování vzhledu během implementace v různých typech a verzích prohlížečích. Po implementaci testování vzhledu uživatelem. Styl CSS načítat z externího souboru, který půjde případně jednodušeji upravit.

Plán práce musí obsahovat určitou rezervu. Kontrola termínů hlavních bodů harmonogramu projektu.

KAPITOLA 3. ÚVODNÍ STUDIE 3. b

15%

Kritický

3. c

5%, 50%

Marginální/ Zanedbatel ný

3. d

5% Katastrofic ký

4. a

10%

Kritický

4. b

15%

Kritický Katastrofic ký

+Uživatelé by měli mít základní počítačové vzdělání a základy práce s internetem. - Já jsem velmi pokročilý uživatel, a proto mohu mít sklony dělat aplikaci podle svého nejlepšího mínění, což nemusí vyhovovat běžným uživatelům systému. + Zadavatel přesně ví, co požaduje od aplikace (změna oboru u cestovní agentury není pravděpodobná) - V druhém případě je velmi pravděpodobné, že bude mít zadavatel další funkční požadavky na systém (může rozšířit působnost svého podnikání) + Cestovní agentura působí na trhu více jak 15 let, za tu dobu si udělala renomé. - Současná globální ekonomická krize způsobuje krach mnoha firem, nevyjímaje cestovní agentury. - V posledním roce dochází ke snižování počtu cizinců navštěvujících Českou repubiku. - Možná chyba při implementaci vzhledem k rozsahu systému.

- Nejsem hacker a neznám všechny typy možných útoků. + Mám určitě znalosti ohledně bezpečnosti aplikace.

20

Před implementací: Konzultace se zadavatelem ohledně předpokládaných uživatelů systému. Návrh systému podle pravidel použitelnosti. Návrh uživatelského systému dle standardů. Po implementaci: testování běžnými uživateli. V prvním případě je myšlena zásadní změna v dosavadním projektu – předejít tomu lze pouze částečně správnou a častou komunikací se zadavatelem. V druhém případě by mohlo dojít k rozšíření stávajícího projektu, což nepředstavuje pro projekt velké riziko. Existuje mnoho faktorů, které nelze ovlivnit na straně projektu.

Před implementací: kvalitní popis případů užití. Po implementaci: podrobná kontrola implementace testováním možností práce se systémem jednotlivých uživatelských rolí. Navrhnout a implementovat ochranu před známými bezpečnostními riziky. Provedení testů ochrany proti vnějšímu napadení.

KAPITOLA 3. ÚVODNÍ STUDIE 4. c

2%

Kritický Katastrofic ký

- Technika není nikdy 100% dokonalá. + Znám možnosti zálohování takovýchto systémů (minimálně každodenní zálohování databáze a týden zálohování celého serveru)

Vytváření záloh databáze – denní zálohování, týdenní dvojí zálohování (uložení záloh na přenosné medium a uskladnění v trezoru).

Tabulka 3-1: Analýza rizik

3.8. Datový slovník Tabulka 3-2 zobrazuje slovník pojmů používaných v úvodní studii a analýze. Slovník pojmů je důležitý vzhledem ke komunikaci se zákazníkem, slouží k přesnému vymezení slov použitých v projektové dokumentaci a eliminuje možnost špatného pochopení dokumentu ze strany zákazníka.

Termín

Význam

Administrátor

Role správce informačního systému. Má přístup ke všem funkcím systému.

CMS

Systém pro správu webového obsahu. Tzv. redakční systém.

Evidence

Tabulka či provázané tabulky, do kterých se ukládají požadované informace. Evidencí je také myšleno možnost vkládat, upravovat a mazat údaje.

Fixní rezervace

Objednávka, která již byla klientem potvrzena a alespoň částečně uhrazena.

Ftp přístup Hosting Htaccess Check-in Check-out Kaskádové styly Klient Manažer Nákupní cena Objednávka Platba

Přístup k prostoru na disku u hostingu pomocí Správců souborů. Umožňuje jednodušší správu souborů. Pronájem prostoru pro webové stránky na cizím serveru. Konfigurační soubor webového serveru. Umožňuje přesměrování stránek, nastavení chybových stránek, omezení přístupu aj. Datum začátku pobytu klienta. Datum konce pobytu klienta. Programovací jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. Role v IS systému připravená pro budoucí implementaci. Klient je zákazník cestovní agentury. Role v IS systému. Tuto roli mají vedoucí zaměstnanci společnosti. Kromě svých práv do systému přebírá všechny od prodejce. Cena ubytování, kterou platí cestovní agentura. Poptávka klienta po ubytování či jiné službě prostřednictvím emailu či webového formuláře. Zaznamenaná platba klienta za služby či ubytování.

21


Prodejce Prodejní cena Produkt Prohlížení Předběžná rezervace Pultová cena Report Správce CMS Terminálová stanice Transfer Vlastník rezervace Vyhledávání

Role v IS systému. Tuto roli mají zaměstnanci, kteří se starají pouze o prodej služeb. Cena, za kterou cestovní agentura prodává ubytování klientům Typ ubytování (apartmán, dvoulůžkový pokoj, studio,...). Tabulka s výpisem dat z evidence, kterou je množné řadit dle různých parametrů tabulky. Stav objednávky mezi vytvořením rezervace a uhrazením objednané služby. Cena, za kterou vlastník ubytovacího zařízení nabízí ubytování běžným klientům. Výpis tabulky z nějaké evidence podle vybraných parametrů. Role v IS systému. Tuto roli mají zaměstnanci spravující Content Management Systém. Této roli systém neumožňuje přístup k jiným modulům. Počítač. Doprava klienta z jednoho místa na druhé. Zaměstnanec-prodejce, který rezervaci zpracovává. Formulář umožňující vyhledávat v evidenci dle různých parametrů. Tabulka 3-2 : Datový slovník

22


Obrázek 3-5 : Harmonogram Projekt 23

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

4 Analýza a návrh řešení 4.1. Analýza případů užití Popsané případy užití v této části vycházejí z kapitoly 3.3 – Katalog požadavků, konkrétně z definovaných funkčních požadavků v podkapitole 3.3.2. Tyto případy užití popisují všechny základní funkce, které bude systém poskytovat. Následující případy užití jsou popsány pomocí jazyka UML [7][8] – Use Case texty a UML diagramy aktivit. Use Case texty budou využity vždy, diagram aktivit bude využit pouze ve složitějších případech užití. Při vytváření formátu Use Case textů jsem se nechal inspirovat již existujícími šablonami, zejména tedy doporučením z článku [10]. Nejprve popíši a vysvětlím moji šablonu pro Use Case texty, která se bude skládat z těchto částí: •

Stručný popis Stručný popis slouží k rychlému pochopení konkrétní funkce systému.

•

Frekvence užití Informace, jak často bude případ užití v systému využíván. Zejména slouží jako informace, jak moc se věnovat precizní implementaci dané funkci systému vzhledem k ostatním funkcím. Jednotlivé případy užití budou hodnoceny takto: • • •

•

minimálně méně často opakovaně

Hlavní aktéři Seznam aktérů, kteří mohou vystupovat v konkrétním případu užití.

•

Vstupní podmínky Údaje udávající, v jakém stavu se musí systém či uživatel nacházet, aby mohlo dojít k využití dané funkce systému.

•

Hlavní scénář Hlavní tok událostí, neboli postup, jak dosáhnout hlavního funkčního záměru daného případu užití.

•

Alternativní scénář V této části jsou popsány všechny odchylky od hlavního toku událostí (větvení, cykly,…)

•

Rozšiřující tok událostí Doplňkové informace rozšiřující jednotlivé body hlavního toku. 24

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ •

Stav po ukončení Případ užití je dokončen, pokud došlo k provedení všech událostí popsaných v seznamu „stav po dokončení“.

•

Požadavek na logování Důležité události vzniklé v systému by měly být logovány. Požadavky na logování jsou uvedeny v tomto bodě.

•

Návrh uživatelského rozhraní U některých případů užití je dobré uvést i návrh uživatelského rozhraní. Návrh bude uveden pouze u vybraných případů.

4.1.1. UC001 – Přihlášení do systému Stručný popis Přihlašovací procedura do rezervačního systému. Klient zadá do prohlížeče URL adresu, na které se nachází rezervační systém. Systém zobrazí přihlašovací formulář. Klient uvede své uživatelské jméno a heslo a systém zkontroluje zadané údaje oproti databázi. Pokud jsou údaje platné, systém uloží uživatele do sessions prohlížeče a zobrazí úvodní stránku spolu s menu pro konkrétní roli uživatele v systému. V případě neplatnosti přihlašovacích údajů zobrazí systém informace o chybě a vyzve uživatele k zadání nových údajů. Frekvence užití Méně často Hlavní aktéři Prodejce, Správce CMS, Manažer, Administrátor Vstupní podmínky Uživatel zná URL adresu, kde se nachází rezervační systém. Hlavní scénář 1. Systém vyzve uživatele k zadání přihlašovacích údajů. 2. Uživatel zadá přihlašovací jméno a heslo. 3. Systém ověří uživatelem zadané přihlašovací údaje. 4. Systém přihlásí uživatele do systému a zobrazí úvodní stránku spolu s příslušným menu podle jeho role v systému. Alternativní scénář 4. b V případě, že uživatel nezadal správné přihlašovací údaje: • Systém zobrazí uživateli informaci o špatném zadání údajů a vyzve uživatele k opětovnému zadání uživatelského jména a hesla. • V případě, že uživatel nezadal správné přihlašovací údaje 3x za sebou: • Systém zablokuje účet uživateli se zadaným uživatelským účtem a informuje uživatele o zablokování spolu s radami, jakým způsobem účet odblokovat. Rozšiřující tok událostí Žádný Stav po ukončení

25

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Systém uložil uživatele do sessions, uživatel se nachází na úvodní stránce a zobrazilo se mu správné menu dle jeho role v systému. Požadavek na logování Systém zaeviduje do logu identifikátor, pod kterým se uživatel přihlašuje, čas přihlášení a úspěšnost (přihlášen / zadány chybné údaje). Návrh uživatelského rozhraní

Obrázek 4-1: Návrh uživatelského rozhraní – Přihlášení do systému. 4.1.2. UC002 – Odhlášení ze systému Stručný popis Odhlašovací procedura z rezervačního systému. Případ užití začíná tehdy, když uživatel klikne na odkaz „Odhlásit“. Systém pro odhlášení uživatele ze systému odstraní sessions. Frekvence užití Méně často Hlavní aktéři Prodejce, Správce CMS, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Hlavní scénář 1. Uživatel klikne na odkaz „Odhlásit“. 2. Systém odstraní všechny http sessions. 3. Systém zobrazí přihlašovací stránku. Alternativní scénář Žádný Rozšiřující tok událostí Žádný Stav po ukončení Všechny http sessions jsou odstraněny. Uživateli je zobrazena přihlašovací stránka. Požadavek na logování Systém zaeviduje do logu identifikátor, pod kterým se uživatel přihlašuje, a čas odhlášení. Návrh uživatelského rozhraní

26


Obrázek 4-2: Návrh uživatelského rozhraní – Odhlášení ze systému.

4.1.3. UC003 – Správa uživatelů Stručný popis Správa uživatelů v systému v sobě zahrnuje tyto úkony: Vytvoření nového uživatele, editace uživatele, odstranění uživatele, prohlížení údajů o uživateli, prohlížení seznamu uživatelů a vyhledávání uživatelů. Ne všechny tyto funkce systému mohou využívat všichni aktéři (možnost využití závisí na uživatelské roli v systému). Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Hlavní scénář 1. Uživatel odešle požadavek na správu uživatelů 2. Systém ověří uživatelovu roli v systému 3. Systém provede příslušný požadavek Alternativní scénář 3 – Systém zjistí nedostatečná oprávnění pro provedení požadavku a zobrazí předchozí stránku spolu s informací o neoprávněnosti požadavku vzhledem k uživatelským právům (tento scénář by správně neměl nastat, systém by neměl umožnit dostat se k jakémukoliv odkazu, na který nemá uživatelská oprávnění). Rozšiřující tok událostí 3. a – Systém provede scénář konkrétního požadavku na správu systému – Případy užití UC004 – UC009 Požadavek na logování Žádný 4.1.4. UC004 – Vytvoření nového uživatele = Vytvoření nového klienta Stručný popis Uživatel systému vloží do systému bud nového klienta s jeho kontaktními údaji, nebo vytvoří nového uživatele systému (pouze role Administrátor). Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky 27

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Dědí od případu užití UC003 Hlavní scénář 1. Systém obdrží požadavek na vytvoření nového uživatele. 2. Systém zobrazí formulář pro vložení nového uživatele. 3. Uživatel vyplní údaje do formuláře, vybere roli v systému a stiskne tlačítko „Ulož“ 4. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 5. Systém uloží informace do databáze a zobrazí údaje o nově zadaném uživateli. Alternativní scénář 1. a – Uživatel klikne v hlavním menu na odkaz „Nový uživatel“ a systém se dostane do 2. kroku hlavního scénáře. 1. b – Uživatel klikne na odkaz „Nový uživatel“ při vkládání nové rezervace a systém se dostane do 2. kroku hlavního scénáře. 5. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění (upravení) údajů (hlavní scénář – krok 2). Navíc systém konkretizuje špatně zadané údaje (textově i graficky). Rozšiřující tok událostí 2. Uživatel s rolí PRODEJCE A MANAŽER může vložit pouze uživatele typu „klient“, ADMINISTRÁTOR může přiřadit uživateli libovolnou roli. 3. a - Povinné údaje v případě KLIENTA: Uživatelské údaje, jméno, příjmení, emailová adresa a jazyk. Povinné údaje v případě PŘÍMÉHO UŽIVATELE SYSTÉMU: stejně jako u klienta, navíc je požadováno heslo do systému. 3. b – Heslo musí splňovat základní bezpečností zásady: délka minimálně 8 znaků, musí obsahovat minimálně jedno číslo, jedno velké písmeno a jeden speciální znak (např. +,!,?). 4. Uživatelské jméno musí být v systému unikátní. Stav po ukončení Informace o novém uživateli/klientovi jsou uloženy v databázi. Uživateli se zobrazila stránka s údaji o novém uživateli/klientovi. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového uživatele, identifikátor nového uživatele a čas přidání. Návrh uživatelského rozhraní

28


Obrázek 4-3: Návrh uživatelského rozhraní – Formulář pro vytvoření nového uživatele (klienta). 4.1.5. UC005 – Editace uživatele Stručný popis Procedura pro úpravu údajů o uživateli systému či klientovi. PRODEJCE a MANAŽER může upravovat údaje o KLIENTOVI a své údaje (kromě uživatelského jména). ADMINISTRÁTOR může upravovat údaje o všech uživatelích včetně uživatelského jména. Frekvence užití Minimálně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC003 Hlavní scénář 1. Systém obdrží požadavek na editaci uživatele. 2. Systém zobrazí předem vyplněný formulář s aktuálními údaji pro editaci údajů o uživateli. 3. Uživatel provede požadované změny ve formuláři a stiskne tlačítko „Ulož“. 4. Systém ověří, zda jsou vyplněny všechny povinné údaje, a zkontroluje korektnost všech zadaných údajů. 5. Systém uloží změněné informace do databáze a zobrazí údaje o editovaném uživateli. Alternativní scénář 1. a – Uživatel klikne v seznamu uživatelů na odkaz „editovat“ u konkrétního uživatele a systém se dostane do 2. kroku hlavního scénáře. 29

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 1. b – Uživatel klikne v detailu rezervace na odkaz „editovat uživatele“ a systém se dostane do 2. kroku hlavního scénáře. 3. a1 – Uživatel klikne na odkaz „zpět“. 3. a2 – Systém zobrazí naposledy zobrazenou stránku (seznam uživatelů nebo detail rezervace). 5. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění (upravení) údajů (hlavní scénář – krok 2). Navíc systém konkretizuje špatně zadané údaje (textově i graficky). Rozšiřující tok událostí 2. Uživatel s rolí PRODEJCE A MANAŽER nemohou měnit uživatelovu roli v systému, ADMINISTRÁTOR může roli měnit libovolně. 3. a - Povinné údaje platí stejně jako u UC004. 5. a – Pokud uživatel vstoupil do editace uživatele z detailu rezervace, systém zobrazí také odkaz na návrat k této rezervaci. 5. b – V případě že uživatel nevyplnil pole s heslem, systém nekontroluje toto pole a hodnota hesla se nezmění. Stav po ukončení Nové informace o uživateli/klientovi jsou uloženy v databázi. Uživateli se zobrazila stránka s údaji o novém uživateli/klientovi spolu s informací o dokončení provedené změny. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci uživatele, identifikátor uživatele a čas editace.

Obrázek 4-4 : Diagram Aktivit 1 – Vytvoření nového uživatele, Diagram Aktivit 2 – Editace uživatele. 30


4.1.6. UC006 – Odstranění uživatele Stručný popis Procedura pro odstranění uživatele ze systému. Uživatel vyhledá uživatele, kterého chce ze systému odstranit a stiskne tlačítko „odstranit“. Po stisknutí tlačítka však nedojde k fyzickému odstranění z databáze, pouze se změní stav uživatele na „odstraněn“. Uživatel se systémovou rolí PRODEJCE či MANAŽER může odstranit pouze uživatele s rolí KLIENT, administrátor může odstranit jakéhokoliv uživatele kromě defaultního administrátorského účtu. Frekvence užití Minimálně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC003 Hlavní scénář 1. Systém obdrží požadavek na „odstranění“ uživatele ze systému. 2. Systém zobrazí okno s upozornění, zda opravdu chceme uživatele odstranit. 3. Uživatel stiskne tlačítko „ANO“. 4. Systém nastaví danému uživateli atribut „stav“ na „odstraněn“. 5. Systém zobrazí stránku „vyhledávání uživatelů“ spolu s informací o provedení odstranění daného uživatele ze systému. Alternativní scénář 1. a1 – Uživatel klikne v seznamu uživatelů nebo v prohlížení údajů o uživateli na odkaz „odstranit“ u konkrétního uživatele. Dále se pokračuje krokem 2 v hlavním scénáři. 3. a1 – Uživatel stiskne tlačítko „NE“ a systém se vrátí na posledně zobrazenou stránku. Rozšiřující tok událostí 2 – Upozornění by mělo být řešeno na klientské stránce pouze pomocí JavaSriptu. Stav po ukončení Odstraňovanému uživateli byl změněn atribut „stav“ na „odstraněn“. Uživateli se zobrazila informace o úspěšném odstranění uživatele. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění uživatele + identifikátor odstraněného uživatele a čas editace. 4.1.7. UC007 – Prohlížení údajů o uživateli Stručný popis Tento případ užití umožňuje prohlížet informaci o konkrétním uživateli a přímo navazuje na jeden z těchto případů užití: UC008 – Vyhledávání uživatelů, UC009 – Prohlížení seznamu uživatelů. Uživatel s rolí PRODEJCE může prohlížet pouze údaje o KLIENTECH. MANAŽER může ještě navíc prohlížet údaje o PRODEJCÍCH. ADMINISTRÁTOR může prohlížet údaje o libovolném uživateli. Frekvence užití Méně často Hlavní aktéři 31

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC003 Uživatel je na stránce prohlížení uživatelů, nebo na stránce prohlížení rezervace. Hlavní scénář 1. Uživatel odešle požadavek na prohlížení údajů o konkrétním uživateli. 2. Systém zobrazí stránku se všemi informacemi o uživateli. Alternativní scénář Žádný Rozšiřující tok událostí 2. a - Nezobrazuje se hodnota hesla 2. b – Pokud uživatelova role umožňuje editovat daného uživatele, nebo uživatel prohlíží své vlastní údaje, zobrazí se odkaz na editaci uživatelských údajů. 2. c – Pokud uživatelova role a role prohlíženého uživatele umožňuje odstranění prohlíženého uživatele, zobrazí systém tlačítko pro odstranění uživatele. Stav po ukončení Uživateli se zobrazila stránka s údaji o konkrétním uživateli. Požadavek na logování Žádný Návrh uživatelského rozhraní

Obrázek 4-5: Návrh uživatelského rozhraní – Prohlížení údajů o uživateli systému. 4.1.8. UC008 – Vyhledávání uživatelů Stručný popis Případ užití vyhledávání uživatelů umožňuje vyhledat uživatele dle těchto atributů: uživatelské jméno, jméno, příjmení, emailová adresa a role v systému. V případě hledání klienta lze vyhledávat i podle názvu firmy a adresy. Vyhledávat lze i podle kombinací z těchto atributů. Uživateli s rolí PRODEJCE se zobrazí pouze KLIENTI. MANAŽEROVI se zobrazí KLIENTI i PRODEJCI. Administrátorovi se zobrazují všechny záznamy. Frekvence užití 32

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC003 Hlavní scénář 1. Uživatel klikne v hlavním menu v sekci Uživatelé na odkaz „Vyhledávání“. 2. Systém zobrazí formulář pro vyhledávání uživatelů dle určených atributů. 3. Uživatel vyplní formulář a stiskne tlačítko „Vyhledat“. 4. Systém uloží do SESSIONS parametry vyhledávání. 5. Systém prohledá databázi uživatelů dle požadovaných hodnot jednotlivých atributů. 6. Systém zobrazí seznam uživatelů odpovídajících požadovaným parametrům pod formulář vyhledávání (Případ užití UC009). Alternativní scénář 5. a – Systém nenalezl žádný odpovídající údaj v databázi uživatelů, zobrazí upozornění o neúspěchu hledání a přejde do kroku 2. hlavního scénáře – zobrazí vyplněný formulář. Rozšiřující tok událostí 2. a - Vyhledávací parametry: uživatelské jméno, jméno, příjmení, emailová adresa, jméno firmy, adresa a uživatelská role. 2. b – Seznam uživatelských rolí se mění dle role uživatele (viz. Stručný popis tohoto případu užití). Stav po ukončení Uživateli se zobrazil seznam uživatelů spolu s formulářem vyhledávání vyplněným podle posledního vyhledávání. Požadavek na logování Žádný. 4.1.9. UC009 – Prohlížení seznamu uživatelů Stručný popis Tento případ užití zobrazí seznam uživatelů dle nastavených parametrů. PRODEJCE může zobrazit a procházet seznam KLIENTŮ, MANAŽER může navíc zobrazit také PRODEJCE a ADMINISTRÁTOR může zobrazit uživatele se všemi systémovými rolemi. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC003 Hlavní scénář 1. Systém obdrží požadavek na zobrazení seznamu uživatelů. 2. Systém vyhledá uživatele podle vstupních parametrů. 3. Systém zobrazí seznam uživatelů Alternativní scénář

33

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 3. a – Systém nenalezl žádného uživatele odpovídajícího požadovaným parametrům a informuje o tom uživatele. Rozšiřující tok událostí 3 – Systém zobrazí důležité informace o uživateli, odkaz na zobrazení všech informací o uživateli, odkaz na editace údajů a odkaz pro odstranění uživatele. Stav po ukončení Uživateli se zobrazil seznam uživatelů. Požadavek na logování Žádný Návrh uživatelského rozhraní

Obrázek 4-6: Návrh uživatelského rozhraní – Seznam uživatelů.

34


Obrázek 4-7 : Diagram Aktivit 3 – Odstranění uživatele, Diagram Aktivit 4 – Vyhledávání uživatelů 4.1.10. UC010 – Správa ubytování Stručný popis Správa ubytování v systému v sobě zahrnuje tyto úkony: Vytvoření nového ubytování, editace ubytování, odstranění ubytování, prohlížení údajů o ubytování, prohlížení seznamu ubytování a vyhledávání ubytování. Ne všechny tyto funkce systému mohou využívat všichni aktéři (možnost využití závisí na uživatelské roli v systému). Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Hlavní scénář 1. Uživatel odešle požadavek na správu ubytování. 2. Systém ověří uživatelovu roli v systému. 3. Systém provede příslušný požadavek. Alternativní scénář Žádný Rozšiřující tok událostí 35

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 3. a – Systém provede scénář konkrétního požadavku na správu ubytování – Případy užití UC011 – UC016 3. b – Systém zjistí nedostatečná oprávnění pro provedení požadavku a zobrazí předchozí stránku spolu s informací o neoprávněnosti požadavku vzhledem k uživatelským právům (tento scénář by správně neměl nastat, systém by neměl umožnit dostat se k jakémukoliv odkazu, na který nemá uživatelská oprávnění). Požadavek na logování Žádný

Obrázek 4-8: Diagram Aktivit 5 – Správa ubytování. 4.1.11. UC011 – Vytvoření nového ubytovacího zařízení Stručný popis Procedura pro přidání nového ubytovacího zařízení do systému. Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Uživatelská role přihlášeného uživatele v systému je MANAŽER, nebo ADMINISTRÁTOR Hlavní scénář 1. Uživatel klikne v levém menu v sekci „Ubytování“ na odkaz „Nové ubytování“. 2. Systém zobrazí formulář pro přidání nového ubytovacího zařízení. 3. Uživatel vyplní údaje do formuláře a stiskne tlačítko „Ulož“ 4. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 5. Systém uloží informace do databáze 6. Systém zobrazí údaje o nově zadaném ubytování (případ užití UC014)

36

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář 5. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění (upravení) údajů (hlavní scénář – krok 2). Navíc systém konkretizuje špatně zadané údaje. Rozšiřující tok událostí 3. a - Povinné údaje: název ubytování, popis, emailová adresa, kategorie, země, oblast a město. 3. b – Název ubytování musí obsahovat minimálně 5 znaků. Stav po ukončení Informace o novém ubytování jsou uloženy v databázi. Uživateli se zobrazila stránka s údaji o novém ubytování s informací o úspěšném přidání nového zařízení. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového ubytování, identifikátor nového ubytování a čas přidání.

Obrázek 4-9 : Diagram Aktivit 6 – Vytvoření nového ubytování. 4.1.12. UC012 – Editace ubytovacího zařízení Stručný popis Procedura pro úpravu údajů o ubytovacím zařízení. Tento případ užití je analogický k případu užití UC006 – Editace uživatele. Případné odchylky budou popsány níže. 37

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Uživatelská role přihlášeného uživatele v systému je MANAŽER, nebo ADMINISTRÁTOR Hlavní scénář Analogické k UC005 – Editace uživatele Alternativní scénář 1. a – Uživatel klikne v seznamu ubytování na odkaz „editovat“ u konkrétního ubytování a systém se dostane do 2. kroku hlavního scénáře. Rozšiřující tok událostí 3. a - Povinné údaje platí stejně jako u UC011. 5. a - Systém zobrazí také odkaz na návrat k seznamu ubytování. Stav po ukončení Nové informace o ubytování jsou uloženy v databázi. Uživateli se zobrazila stránka s údaji o ubytovacím zařízení spolu s informací o dokončení provedené změny. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci ubytovacího zařízení, identifikátor ubytování, konkrétní změny a čas editace. 4.1.13. UC013 – Odstranění ubytování Stručný popis Procedura pro odstranění ubytování ze systému. Uživatel vyhledá konkrétní ubytovací zařízení a vznese požadavek na jeho odstranění. Systém neodstraní ubytování z databáze, ale pouze nastaví stav ubytování na „odstraněno“. Tento případ užití je analogický k případu užití UC006 – Odstranění uživatele. Případné odchylky budou popsány níže. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Uživatelská role přihlášeného uživatele v systému je MANAŽER, nebo ADMINISTRÁTOR. Hlavní scénář Analogické k UC006 – Odstranění uživatele Alternativní scénář 1. a1 – Uživatel klikne v seznamu ubytování nebo v prohlížení údajů o ubytování na odkaz „odstranit“ u konkrétního ubytovacího zařízení. Dále se pokračuje krokem 2. v hlavním scénáři. Rozšiřující tok událostí Analogické k UC006 – Odstranění uživatele Stav po ukončení

38

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Odstraňovanému ubytovacímu zařízení byl změněn atribut „stav“ na „odstraněn“. Uživateli se zobrazila informace o úspěšném odstranění ubytovacího zařízení. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění ubytování + identifikátor odstraněného ubytování a čas odstranění. Návrh uživatelského rozhraní

Obrázek 4-10: Návrh uživatelského rozhraní – Odstranění ubytování. 4.1.14. UC014 – Prohlížení údajů o ubytování Stručný popis Tento případ užití umožňuje prohlížet informace o konkrétním ubytování a přímo navazuje na jeden z těchto případů užití: UC015 – Vyhledávání ubytování, UC016 – Prohlížení seznamu ubytování. Uživatelům s rolí MANAŽER a ADMINISTRÁTOR se navíc zobrazí odkazy pro editaci údajů a odstranění ubytování. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Uživatel je na stránce prohlížení seznamu ubytování. Hlavní scénář 1. Uživatel odešle požadavek na prohlížení údajů o konkrétním ubytování. 2. Systém zobrazí stránku se všemi informacemi o ubytování. Alternativní scénář Žádný Rozšiřující tok událostí 2. a – Pokud má přihlášený uživatel systémovou roli MANAŽER, nebo ADMINISTRÁTOR, zobrazí se na stránce také odkazy na editaci a odstranění ubytování.

39

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 2. b – Pokud má přihlášený uživatel systémovou roli MANAŽER, nebo ADMINISTRÁTOR, zobrazí se na stránce také odkaz na správu ceníků. 2. c – Nevyplněné nepovinné položky se nezobrazují, pouze se zobrazí seznam nevyplněných atributů. Stav po ukončení Uživateli se zobrazila stránka s údaji o konkrétním ubytování. Požadavek na logování Žádný Návrh uživatelského rozhraní

Obrázek 4-11: Návrh uživatelského rozhraní – Prohlížení údajů o ubytování (tento formulář je totožný i pro přidání a editaci ubytování).

4.1.15. UC015 – Vyhledávání ubytování Stručný popis Případ užití vyhledávání ubytování umožňuje vyhledat ubytovací zařízení podle všech možných atributů, které jde navíc navzájem kombinovat. Tento případ užití je analogický k případu užití UC008 – Vyhledávání uživatelů. Případné odchylky budou popsány níže. Frekvence užití Opakovaně 40

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Hlavní scénář Analogické k UC008 – Vyhledávání uživatelů Alternativní scénář Analogické k UC008 – Vyhledávání uživatelů 3. a1 – Uživatel kliknul na odkaz počátečního písmene ubytování ve formuláři vyhledávání. 3. a2 – Systém prohledá databázi ubytovacích zařízení a vyhledá všechny, jejichž název začíná na požadované počáteční písmeno. 3. a3 – Systém zobrazí ubytování, jejichž název začíná na dané písmeno (UC016). Rozšiřující tok událostí 2. a - Vyhledávací parametry jsou všechny atributy entity Ubytování. 2. b – Vyhledávací formulář navíc obsahuje možnost vyhledávání dle počátečního písmene názvu ubytovacího zařízení. Stav po ukončení Uživateli se zobrazil seznam ubytování spolu s formulářem vyhledávání vyplněným dle posledního vyhledávání. Požadavek na logování Žádný. 4.1.16. UC016 – Prohlížení seznamu ubytování Stručný popis Tento případ užití zobrazí seznam ubytovacích zařízení dle nastavených atributů. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Hlavní scénář 1. Systém obdrží požadavek na zobrazení seznamu ubytovacích zařízení. 2. Systém vyhledá uživatele podle vstupních parametrů. 3. Systém zobrazí seznam ubytovacích zařízení. Alternativní scénář 3. a – Systém nenalezl žádné ubytování odpovídající požadovaným parametrům a informuje o tom uživatele. Rozšiřující tok událostí 3. a – Systém zobrazí důležité informace o ubytování (název, kategorie, umístění), odkaz na zobrazení všech informací o ubytování. 3. b - Pokud je uživatel role MANAŽER, nebo ADMINISTRÁTOR, systém zobrazí ke každému ubytování odkaz na editaci ubytování, odkaz na správu ceníků a odkaz na zobrazení ubytování na mapě. Stav po ukončení 41

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Uživateli se zobrazil seznam ubytování. Požadavek na logování Žádný 4.1.17. UC017 – Správa produktů a ceníků Stručný popis Správa produktů a ceníků zahrnuje tyto úkony: Přidání nového produktu, editace produktu, odstranění produktu, prohlížení produktů, přidání sekce, odstranění sekce, přidání období do sekce, úprava období v sekci, odstranění období ze sekce, editace ceníku a prohlížení ceníku. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Uživatel prohlíží detail ubytování, nebo se nachází na stránce se seznamem ubytování. Hlavní scénář 1. Uživatel odešle požadavek na správu produktů a ceníků. 2. Systém ověří uživatelovu roli v systému. 3. Systém provede příslušný požadavek. Alternativní scénář Žádný Rozšiřující tok událostí 3. a – Systém provede scénář konkrétního požadavku na správu systému – Případy užití UC018 – UC028. 3. b – Systém zjistí nedostatečná oprávnění pro provedení požadavku a zobrazí předchozí stránku spolu s informací o neoprávněnosti požadavku vzhledem k uživatelským právům. Požadavek na logování Žádný

42


Obrázek 4-12 : Diagram Aktivit 7 – Správa produktů a ceníku. 4.1.18. UC018 – Přidání produktu k ubytování Stručný popis Uživatel chce vytvořit ceník ubytovacího zařízení, ale nejdříve musí přidat nějaký typ pokoje (produkt), pro který budou ceny platit. Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem Hlavní scénář 1. Systém obdrží požadavek na vytvoření nového produktu. 2. Systém zobrazí formulář pro vytvoření nového produktu. 3. Uživatel vybere typ pokoje, vyplní hodnotu maximálního počtu lidí a případně doplní komentář. 4. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 5. Systém uloží informace do databáze a zobrazí stránku s ceníkem.

43

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář 5. a – Systém odhalil vyplnění nekorektních údajů a vyzve uživatele k upravení údajů (hlavní scénář – krok 2). Navíc systém konkretizuje špatně zadané údaje (textově i graficky). Rozšiřující tok událostí 1. – Uživatel klikne na tlačítko přidat produkt v ceníku pro konkrétní ubytování. Stav po ukončení Produkt byl uložen v databázi. Uživateli se zobrazila stránka s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového produktu, identifikátor nového produktu a čas přidání. 4.1.19. UC019 – Editace produktů ubytování Stručný popis Na stránce s ceníkem bude seznam produktů k danému ubytovacímu zařízení. Tato tabulka bude zároveň formulářem a všechny její hodnoty půjdou okamžitě přepisovat. Po stisknutí tlačítka „ulož“ se uloží změny provedené v produktech. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017. Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Případ užitá začíná, když uživatel začne upravovat hodnoty ve formuláři s produkty. 2. Uživatel stiskne tlačítko „Ulož“. 3. Systém ověří, zda jsou všechny povinné údaje vyplněné a zkontroluje korektnost všech zadaných údajů. 4. Systém uloží upravené informace do databáze a zobrazí stránku s ceníkem. Systém navíc informuje uživatele o úspěšném provedení požadavku. Alternativní scénář 4. a – Systém odhalil vyplnění nekorektních údajů a vyzve uživatele k upravení – systém zobrazí stránku s ceníkem spolu s vyplněným formulářem s produkty. Rozšiřující tok událostí 1. – Uživatel se nachází na stránce s ceníkem pro dané ubytování. Stav po ukončení Změny v produktech byly uloženy v databázi. Uživateli se zobrazila stránka s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci produktů, identifikátor ubytování a čas editace.

44

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní

Obrázek 4-13: Návrh uživatelského rozhraní – Přidání a editace produktů (typů pokoje) ubytování.

4.1.20. UC020 – Odstranění produktu Stručný popis Případ užití odstranění produktu odebere produkt z ubytování. Uživatel klikne na tlačítko „odstranit“ v seznamu produktů a systém odstraní produkt z databáze. Navíc pokud jsou již vyplněny nějaké ceny k danému produktu, dojde k odstranění těchto cen. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Uživatel klikne na tlačítko „odstranit“ v seznamu produktů u vybraného produktu. 2. Systém zobrazí okno s upozornění, zda opravdu chceme produkt odstranit. 3. Uživatel stiskne tlačítko „ANO“. 4. Systém zkontroluje uživatelovu roli v systému a ověří jeho práva pro tuto systémovou akci. 5. Systém odstraní z databáze všechny ceny pro daný produkt, pokud nějaké existují. 6. Systém odstraní z databáze daný produkt. 45

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 7.

Systém zobrazí stránku s ceníkem spolu s informací o provedení odstranění daného produktu ze systému.

Alternativní scénář 3. a – Uživatel stiskne tlačítko „NE“ a systém se vrátí na posledně zobrazenou stránku. 5. a – Systém zjistil nedostatečná systémová práva pro daný úkon a zobrazí stránku s ceníkem spolu s informací o nedostačujících právech (k tomuto scénáři by nemělo při správné implementaci dojít, ale je zde uveden pro vyšší ochranu systému). Rozšiřující tok událostí 2 – Upozornění by mělo být řešeno na klientské stránce pouze pomocí JavaScriptu. Stav po ukončení Produkt a všechny ceny k produktu byly odstraněny z databáze. Systém zobrazil stránku s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění produktu a čas.

4.1.21. UC021 – Přidání sekce ceníku Stručný popis Uživatel chce vytvořit ceník ubytovacího zařízení, ale nejdříve musí přidat alespoň jeden produkt a jednu sekci. Uživatel vyplní období ve formuláři pro přidání nové sekce ceníku, pro které bude platit a stisknutím tlačítka „přidej“ přidá sekci k ceníku. Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Případ užití začíná, když uživatel začne vyplňovat formulář pro přidání sekce do ceníku. 2. Uživatel stiskne tlačítko „přidej“. 3. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných hodnot – správný formát dat. 4. Systém uloží novou sekci do databáze. 5. Systém vytvoří období sekce pro právě vytvořenou sekci. 6. Systém zobrazí ceník pro dané ubytování a informuje uživatele o vytvoření nové sekce. Alternativní scénář 4. a – Systém odhalil vyplnění nekorektních údajů a vyzve uživatele k upravení údajů. Navíc systém konkretizuje špatně zadané údaje (textově i graficky). Rozšiřující tok událostí 3. – Systém ověřuje, zda jsou správně zadaná data „od“ a „do“, zda je datum „od“ nižší než datum „do“.

46

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Stav po ukončení Sekce a období sekce byly uloženy do databáze. Uživateli se zobrazila stránka s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nové sekce a nového období sekce, identifikátor nové sekce a období a čas přidání. Návrh uživatelského rozhraní

Obrázek 4-14: Návrh uživatelského rozhraní – Formulář pro přidání sekce ceníku.

47


Obrázek 4-15 : Diagram Aktivit 8 – Editace ceníku, Diagram Aktivit 9 – Odstranění produktu.

4.1.22. UC022 – Editace sekce ceníku Stručný popis Sekce ceníku se zobrazuje, pokud existuje alespoň 1 produkt daného ubytování. V sekci lze editovat její typ a popis. Uživatel u dané sekce v ceníku může tyto informace přímo editovat a po stisknutí tlačítka „ulož“ se těmito údaji přepíše záznam v databázi. Tento případ užití je analogií k případu užití UC019 – Editace produktů ubytování Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. 48

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Hlavní scénář Analogické k UC019 – Editace produktů ubytování Alternativní scénář Analogické k UC019 – Editace produktů ubytování Rozšiřující tok událostí Analogické k UC019 – Editace produktů ubytování Stav po ukončení Sekce byla upravena. Uživateli se zobrazila stránka s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci úpravy sekce, identifikátor upravené sekce a čas editace. 4.1.23. UC023 – Odstranění sekce Stručný popis Případ užití odstranění produktu odebere sekci z ubytování. Uživatel klikne na tlačítko „odstranit sekci“ v ceníku u konkrétní sekce a systém odstraní sekci z databáze. Navíc pokud jsou již vyplněny nějaké ceny k dané sekci, dojde k odstranění těchto cen. Tento případu užití je analogický k UC020 – Odstranění produktu.

4.1.24. UC024 – Přidání období k sekci ceníku Stručný popis Tento scénář nastává ve 2 případech. Bud uživatel klikne v ceníku u vybrané sekce na tlačítko „přidat období“, nebo při vytváření nové sekce ceníku. Systém zkontroluje zadané údaje a uloží nové období do databáze. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Systém obdrží požadavek na přidání období k sekci. 2. Systém zkontroluje hodnoty „datum od“ a „datum do“. 3. Systém přidá do databáze nové období k dané sekci. 4. Systém zobrazí stránku s ceníkem pro ubytování a informuje uživatele o provedení požadavku. Alternativní scénář 3. a – Systém zjistí špatně zadané hodnoty, informuje o tom uživatele a také mu doporučí, jak správně vyplnit položky. 4. a – Pokud se vytváří období sekce spolu s novou sekcí, pokračuje se v případu užití UC021, krok 6. Rozšiřující tok událostí

49

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 3. – Systém ověřuje, zda jsou správně zadaná data „od“ a „do“, zda je datum „od“ nižší než datum „do“. Stav po ukončení Systém uloží nové období a zobrazí upravenou stránku s ceníkem. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového období sekce, identifikátor nového období sekce, identifikátor sekce a čas přidání.

4.1.25. UC025 – Editace období k sekci ceníku Stručný popis Uživatel klikne na stránce ceníků u dané sekce na tlačítko „editace období“. Poté dojde k zobrazení všech období dané sekce ve formuláři. Pro uložení změn stiskne uživatel tlačítko „ulož“. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Případ užití začíná, když uživatel stiskne tlačítko „editace období“ na stránce ceníku u konkrétní sekce, pro které daná období platí. 2. Systém zobrazí formulář s jednotlivými obdobími, která lze měnit. 3. Uživatel provede libovolné změny v datech a stiskne tlačítko „ulož“ 4. Systém zkontroluje korektnost zadaných údajů. 5. Systém změní data v databázi. 6. Systém zobrazí stránku s ceníkem spolu s informací o úspěšném provedení změn v obdobích. Alternativní scénář 3. a – Uživatel stiskne tlačítko zpět. 3. b – Systém neprovede žádné změny a zobrazí stránku s ceníkem. 5. a – Systém zjistil nekorektnost zadaných údajů, zobrazí naposledy vyplněný formulář a označí položky, které byly špatně vyplněny (druhý krok hlavního scénáře). Rozšiřující tok událostí 3. – Systém ověřuje, zda jsou správně zadaná data „od“ a „do“, zda je datum „od“ nižší než datum „do“. Stav po ukončení Systém změnil údaje o obdobích. Systém zobrazil stránku s ceníkem spolu s informací o provedení změn. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editace období, identifikátor měněného období sekce a čas změny.

50

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.1.26. UC026 – Odstranění období sekce ceníku Stručný popis Případ užití odstranění období sekce ceníku odebere sekci ceníku z ubytování. Uživatel klikne na tlačítko „odstranit období“ u konkrétní sekce. Systém zobrazí seznam období, kde je u každého období umístěno tlačítko „odstranit“. Po kliknutí na tlačítko dojde k odebrání období ze sekce. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Případ užití začíná, když uživatel stiskne tlačítko „odstranit období“ na stránce ceníku u konkrétní sekce, pro které daná období platí. 2. Systém zobrazí všechny období pro danou sekci. Vedle každého období je umístěno tlačítko „odstraň“. 3. Uživatel klikne na tlačítko „odstraň“. 4. Systém zobrazí okno s upozornění, zda opravdu chceme období odstranit. 5. Uživatel stiskne tlačítko „ANO“. 6. Systém odstraní období z databáze. 7. Systém zobrazí stránku s ceníkem spolu s informací o provedení odstranění daného období ze sekce ceníku. Alternativní scénář 5. a – Uživatel stiskne tlačítko „NE“ a systém se vrátí na posledně zobrazenou stránku. Rozšiřující tok událostí Žádný Stav po ukončení Období sekce bylo odstraněno z databáze. Systém zobrazil stránku s ceníkem a informoval uživatele o úspěšném odstranění období. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění období, jaké období bylo odstraněno a čas smazání.

4.1.27. UC027 – Editace ceníku Stručný popis Procedura pro editaci cen v ceníku. Uživatel zobrazí stránku s ceníkem. Pokud již vytvořil alespoň jeden produkt a jednu sekci, zobrazí se mu formuláře pro vyplnění cen dělených podle sekcí ceníku. V každé sekci je možné vyplnit ceny pro všechny produkty. Po vyplnění formulářů bud uživatel klikne na tlačítko „ulož“, které se nachází u každé sekce, nebo na tlačítko „ulož vše“, které je umístěno pod všemi formuláři. Systém ulož ceny buď jen pro konkrétní sekci, nebo vyplněné ceny ve všech sekcích. Tento případ užití je nadstavbou případu užití „Prohlížení ceníku“. 51

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Frekvence užití Opakovaně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Uživatel se nachází na stránce s ceníkem. Hlavní scénář 1. Případ užití začíná, pokud uživatel při prohlížení ceníku začne upravovat formulář s cenami 2. Uživatel stiskne tlačítko „ulož vše“. 3. Systém zkontroluje, zda uživatel vyplnil správné hodnoty. 4. Systém uloží všechny změněné hodnoty do databáze. 5. Systém zobrazí stránku s ceníkem s informací o úspěšné změně cen. Alternativní scénář 2. a1 – Uživatel stiskne tlačítko „ulož“ u konkrétní sekce. 2. a2 – Případ užití pokračuje krokem 3. hlavního scénáře, pouze s tím rozdílem, že kontroluje a ukládá změněné hodnoty jen pro konkrétní jednu sekci. 4. a1 – Systém zjistil nekorektnost některých vyplněných hodnot a uloží pouze správně zadané hodnoty. 4. a2 – Systém zobrazí stránku s ceníkem spolu s informací o částečné změně hodnot v ceníku a zobrazí políčka, která byla špatně vyplněna a u nichž nedošlo ke změně hodnoty. Rozšiřující tok událostí 3. – Hodnoty mohou být reálná kladná čísla, nebo 0. 4. – Systém uloží všechny správně zadané hodnoty, i pokud není některá položka správně zadaná. O neuložení špatně vyplněných položek bude systém uživatele informovat. Stav po ukončení Požadované změny cen byly provedeny. Systém zobrazil ceník s informací o provedených změnách. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci ceníků a identifikátor ubytování a čas editace. Návrh uživatelského rozhraní

52


Obrázek 4-16: Návrh uživatelského rozhraní – Formulář pro editaci a prohlížení ceníku ubytování. 4.1.28. UC028 – Prohlížení ceníku Stručný popis Tento případ užití zobrazí ceník pro konkrétní ubytovací zařízení. Zároveň je to vstupní případ užití pro další případy související s ceníkem. Pokud je uživatel role PRODEJCE, zobrazí se mu pouze tabulky s ceníkem bez možnosti jakýchkoliv úprav. Roli MANAŽER a ADMINISTRÁTOR se zobrazí všechna tlačítka a odkazy pro správu ceníku. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC017 Hlavní scénář 1. Případ užití začíná, pokud uživatel klikne na odkaz „ceník“ buď při prohlížení konkrétního ubytovacího zařízení, nebo v seznamu ubytování. 2. Systém vyhledá všechny údaje související s ceníkem pro konkrétní ubytování. 3. Systém zobrazí stránku s ceníkem (dále může uživatel pokračovat případy užití UC018-UC027).

53

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář Žádný Rozšiřující tok událostí 3 – Stránka s ceníkem bude obsahovat tyto části: • Formulář pro přidání produktu (UC018) • Formulář pro přidání sekce (UC021) • Seznam produktů (UC019 a UC023) • Ceník – tabulka/formulář s ceníkem se zobrazí, až pokud bude existovat alespoň 1 produkt a sekce. Ceník bude rozčleněn do sekcí. Každá sekce bude obsahovat všechny produkty s jejich cenami pro daná období v sekci. Sekce bude obsahovat tato tlačítka: o Přidej období (UC024) o Editace období (UC025) o Odstraň období (UC026) o Odstraň sekci (UC023) o Ulož ceník (UC027) V sekci bude také výpis období, pro která je ceník platný. V případě, že jde uživatele s Rolí MANAŽER či ADMINISTRÁTOR, zobrazí se ceny v textových přepisovatelných polích. Na konci ceníku bude navíc tlačítko „Ulož vše“ (UC027). Stav po ukončení Uživateli se zobrazila stránka s ceníkem. Požadavek na logování Žádný

4.1.29. UC029 – Správa rezervace Stručný popis Správa rezervace zahrnuje tyto úkony: Vytvoření nové rezervace, odstranění rezervace, prohlížení rezervace, přidání a úprava klienta v rezervaci, přidání | editace | odstranění objednávky ubytovaní k rezervaci, přidání | editace | odstranění produktu ubytování, změna stavu objednávky, přidání | editace | odstranění objednávky doplňkové služby a přepravy, přidání | editace | odstranění platby za objednávku(y), vytvoření a editace komentáře k rezervaci. Spravovat rezervací můžou všechny role v systému mimo KLIENTA. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Hlavní scénář 1. Uživatel odešle požadavek na správu rezervace 2. Systém ověří uživatelovu roli v systému 3. Systém provede příslušný požadavek (UC030 – UC050) 4. Systém označí uživatele jako „vlastníka“ rezervace. 54

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář Žádný Rozšiřující tok událostí 3. a – Systém provede scénář konkrétního požadavku na správu rezervace – Případy užití UC030 – UC050 3. b – Systém zjistí nedostatečná oprávnění pro provedení požadavku a zobrazí předchozí stránku spolu s informací o neoprávněnosti požadavku vzhledem k uživatelským právům. 4. a – Rezervace může mít více vlastníků. Požadavek na logování Žádný Návrh uživatelského rozhraní

55


Obrázek 4-17: Návrh uživatelského rozhraní – Prohlížení rezervace. 56


Obrázek 4-18 : Diagram Aktivit 9 – Správa rezervací (v diagramu nejsou uvedeny případy užití týkající se objednávek služeb a přepravy, které odpovídají případům užití týkajících se objednávky ubytování) 4.1.30. UC030 – Vytvoření rezervace Stručný popis Scénář užití vytvoření nové rezervace začíná kliknutím uživatele na odkaz „nová rezervace“ v menu „Rezervace“ a v sekci „Rezervace“. Systém zobrazí jednoduchý formulář pro přidání rezervace s tlačítkem „vytvoř rezervaci“. Po potvrzení je uživatel přesměrován na stránku s novou rezervací, kterou posléze může spravovat. Frekvence užití Opakovaně Hlavní aktéři 57

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Hlavní scénář 1. Uživatel klikne na odkaz „nová rezervace“ v menu „Rezervace“ a v sekci „Rezervace“ 2. Systém zobrazí formulář pro přidání rezervace 3. Uživatel klikne na tlačítko „vytvořit rezervaci“. 4. Systém vygeneruje unikátní identifikátor rezervace. 5. Systém vytvoří novou rezervaci s unikátním identifikátorem. 6. Systém nastaví nové rezervaci parametr „stav“ na hodnotu „nová“ 7. Systém zobrazí stránku s rezervací s informací o úspěšném vytvoření nové rezervace. Alternativní scénář Žádný Rozšiřující tok událostí 4. – Identifikátorem rezervace je číslo poslední rezervace inkrementované o 1. Stav po ukončení Systém uloží do databáze údaje o nové rezervaci a zobrazí stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového rezervace, identifikátor rezervace a čas přidání. 4.1.31. UC031 – Přidání a změna klienta k rezervaci Stručný popis Případ užití „Přidání a změna klienta k rezervaci“ začíná stisknutím tlačítka „vybrat klienta“ v sekci „informace o klientovi“ na stránce rezervace. Uživateli se zobrazí nové okno s formulářem pro vyhledání klienta v databázi klientů a tlačítkem pro vytvoření nového klienta. Uživatel buď vyhledá existujícího klienta dle všech možných parametrů uživatele KLIENT, nebo vytvoří nového kliknutím na odkaz „nový klient“. Po uzavření nového okna dojde k obnovení údajů o klientovi na stránce rezervace. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Případ užití začíná kliknutím na tlačítko „vybrat klienta“. 2. Systém zobrazí nové okno s formulářem pro vyhledání klienta a s tlačítkem pro přidání nového klienta. 3. Uživatel zadá údaje o hledaném klientovi do formuláře a stiskne tlačítko hledat. 4. Systém vyhledá v databázi uživatelů klienty, kteří odpovídají zadaným parametrům.

58


6. 7. 8.

Systém zobrazí pod vyplněný formulář seznam klientů s nejdůležitějšími informacemi, které odpovídají zadaným parametrům. U každého klienta zobrazí tlačítko „vybrat“. Uživatel stiskne tlačítko vybrat u konkrétního klienta. Systém přidá vybraného klienta k rezervaci. Systém zavře okno s přidáním klienta do rezervace a aktualizuje stránku rezervace.

Alternativní scénář 3. a1 – Uživatel klikne na tlačítko „vytvoř klienta“ (Případ užití UC004). 3. a2 – Po ukončení případu užití UC004 systém zobrazí pod formulář pro vyhledávání klientů informace o právě přidaném klientovi s tlačítkem „vybrat“. Dále se pokračuje 6. krokem hlavního scénáře. 3. b1 – Uživatel zavře nové okno. 5. a1 – Systém nenalezl žádného klienta, který by odpovídal zadaným parametrům a zobrazí vyplněný formulář pro vyhledávání klientů a informací, že žádný klient neodpovídá zadaným parametrům. Systém doporučí uživateli upravit údaje ve formuláři. Dále se pokračuje 3. krokem hlavního scénáře. 5. b1 – Systém nalezl více než 100 klientů. Systém nezobrazí seznam uživatelů, ale upozorní uživatele na tuto skutečnost a doporučí mu upřesnění údajů o hledaném klientovi. Dále se pokračuje 3. krokem hlavního scénáře. Rozšiřující tok událostí 2. – Formulář obsahuje všechny parametry, které náleží uživateli s rolí KLIENT. Stav po ukončení Systém přidal vybraného uživatele k rezervaci. Systém aktualizoval stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání klienta k rezervaci, identifikátor rezervace a přidaného klienta a čas přidání. 4.1.32. UC032 – Editace kontaktních údajů o klientovi v rezervaci Stručný popis Tento případ užití slouží pro změnu údajů o klientovi pouze pro konkrétní rezervaci. Frekvence užití Minimálně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Případ užití začíná kliknutím na tlačítko „editace údajů“ na stránce s rezervací v sekci „informace o klientovi“. 2. Systém zobrazí nové okno s formulářem pro editace údajů o klientovi, který je vyplněný podle aktuálních hodnot z databáze. 3. Uživatel změní některé údaje ve formuláři a stiskne tlačítko „ulož“. 4. Systém zkontroluje platnost a korektnost zadaných údajů. 5. Systém upraví údaje o klientovi v rezervaci dle zadaných údajů. 59


Systém zavře nové okno a aktualizuje stránku rezervace.

Alternativní scénář 3. a1 – Uživatel stiskne tlačítko „zpět“. 3. a2 – Systém zavře nové okno, stránku s rezervací neaktualizuje. 4. a1 – Systém nalezl chybu v některých zadaných hodnotách. Dále se pokračuje 2. krokem hlavního scénáře. Systém navíc zobrazí informaci o chybně vyplněných údajích. Rozšiřující tok událostí 2. – Formulář obsahuje položky: jméno, příjmení, emailová adresa, telefon a firma. Také obsahuje tlačítka „ulož“ a „zpět“. Stav po ukončení Systém upravil kontaktní údaje o klientovi. Systém aktualizoval stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci kontaktních údajů, identifikátor rezervace, změny v kontaktních údajích a čas editace. 4.1.33. UC033 – Odebrání klienta z rezervace Stručný popis Tento případ užití slouží pro odebrání klienta z rezervace. Po stisknutí tlačítka „odebrat klienta“ systém odebere klienta z rezervace. Frekvence užití Minimálně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Případ užití začíná kliknutím na tlačítko „odebrat klienta“ na stránce s rezervací v sekci „informace o klientovi“. 2. Systém zobrazí javascriptovou hlášku, zda chce uživatel opravdu odebrat klienta z rezervace. 3. Uživatel stiskne tlačítko „ano“. 4. Systém odebere klienta z rezervace. 5. Systém zobrazí aktualizovanou stránku s rezervací. Alternativní scénář 3. a1 – Uživatel stiskne tlačítko „ne“. 3. a2 – Systém zobrazí původní stránku s rezervací. Rozšiřující tok událostí 4. – Systém odstraní všechny kontaktní údaje a identifikátor uživatele z tabulky rezervace u konkrétní rezervace. Stav po ukončení Systém odstranil kontaktní údaje a identifikátor uživatele z rezervace. Systém zobrazil aktualizovanou stránku s rezervací.

60

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odebrání kontaktních údajů, identifikátor rezervace a čas odebrání.

Obrázek 4-19 : Diagram Aktivit 10 – Přidání a změna klienta k rezervaci. 4.1.34. UC034 – Přidání objednávky ubytování k rezervaci Stručný popis Případ užití začíná stisknutím tlačítka „přidat ubytování“ v sekci „objednávky ubytování“ na stránce rezervace. Uživatel vybere ubytování a vyplní základní informace o objednávce. Stisknutím tlačítka „přidej“ systém uloží a přidá objednávku k rezervaci. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 61

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Uživatel klikne na tlačítko „přidat ubytování“ na stránce s rezervací v sekci „objednávky ubytování“. 2. Systém zobrazí nové okno s formulářem pro přidání nové objednávky ubytování. 3. Uživatel vyplní formulář (vybere ubytování ze seznamu ubytování a vyplní všechny povinné údaje) a stiskne tlačítko „ulož“. 4. Systém zkontroluje platnost zadaných údajů. 5. Systém uloží novou objednávku do databáze a přiřadí ji k dané rezervaci. 6. Systém nastaví parametr „stav“ objednávky na „vytvořená“. 7. Systém zavře okno a aktualizuje stránku rezervace. Alternativní scénář 3. a1 – Uživatel stiskne tlačítko „zavřít“. 3. a2 – Systém zavře nové okno a stránku s rezervací neaktualizuje. 5. a1 – Systém zjistil chyby v zadaných údajích. Dále se pokračuje 2. krokem hlavního scénáře – formulář je vyplněný dle naposledy zadaných údajů a uživatel je informován o chybně zadaných hodnotách. Rozšiřující tok událostí 2. – Formulář obsahuje tyto položky: výběr ubytování, datum objednávky od a do, počet dospělých osob, počet studentů, počet dětí, opci, věk dětí, komentář. 4. – Povinné položky: ubytování, počet dospělých osob nebo počet studentů je větší než 0, datum od a datum do. Stav po ukončení Systém uložil objednávku do databáze a přiřadil ji k dané rezervaci. Systém aktualizoval stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání objednávky ubytování k rezervaci, identifikátor rezervace, identifikátor objednávky a čas přidání. Systém zaeviduje do logu změnu stavu objednávky na stav „vytvořená“ spolu s identifikátorem uživatele, který tuto změnu provedl. 4.1.35. UC035 – Přidání produktu ubytování k objednávce ubytování Stručný popis Po přidání objednávky ubytování k rezervaci je také potřeba přidat k dané objednávce alespoň jeden produkt. K tomu slouží tento případ užití, který vytvoří „produkt k objednávce ubytování“ a přiřadí jej k požadované objednávce. Na stránce rezervace v sekci „objednávky ubytování bude u každé objednávky tlačítko „přidat produkt“. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací.

62

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Hlavní scénář 1. Systém obdrží požadavek na přidání produktu k objednávce (uživatel klikne na tlačítko „přidat produkt“ u konkrétní objednávky ubytování). 2. Systém otevře nové okno a v něm zobrazí formulář pro přidání nového produktu k objednávce. 3. Uživatel vybere ze seznamu všech možných produktů jeden produkt, vyplní políčko „počet produktů“, případně přidá komentář a stiskne tlačítko „přidej“. 4. Systém zkontroluje, zda je hodnota „počet produktů“ větší než 0 5. Systém zjistí, do kolika sekcí ceníku spadají data příjezdu a odjezdu u objednávky. 6. Systém nalezne pro všechny sekce ceníku ceny pro daný produkt. 7. Systém pro každou sekci ceníku vytvoří nový produkt objednávky se zjištěnými cenami. Data „od“ a „do“ u produktu objednávky nastaví dle období dané sekce a dle data příjezdu a odjezdu klienta. 8. Systém uzavře okno a aktualizuje stránku s rezervací. Alternativní scénář 5. a1 – Systém zjistil, že uživatel nevyplnil správně hodnotu „počet produktů“. Pokračuje se 2. krokem hlavního scénáře. Systém navíc upozorní klienta o chybně zadané položce. 7. a1 – Systém nenalezl žádnou sekci ceníku (neexistuje ceník pro data příjezd - odjezd). 7. a2 a – Jestliže neexistuje ceník ani pro část období objednávky, tak systém vytvoří jeden „produkt objednávky a přiřadí mu nulové hodnoty všech cen“, data od-do nastaví dle dat příjezdu a odjezdu. 7. a2 b – Existuje ceník pouze pro část období objednávky. Systém přidá produkty pro tuto část stejně jako v hlavním scénáři, navíc přidá jeden produkt objednávky s nulovými cenami (stejně jako u 7. a2 a). 7.a3 – Systém zobrazí ve stejném okně formulář pro editaci produktů objednávky (UC036) Rozšiřující tok událostí 2. – Formulář se skládá z políček: Výběr z produktů, které nabízí dané ubytování, počet produktů a komentář k produktu. Stav po ukončení Systém uložil produkty objednávky do databáze a přiřadil je k dané objednávce. Systém aktualizoval stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání produktu, identifikátory všech přidaných produktů a čas přidání.

63


Obrázek 4-20: Návrh uživatelského rozhraní – Formulář pro přidání produktu k objednávce.

64


Obrázek 4-21 : Diagram Aktivit 11 – Přidání objednávky ubytování k rezervaci, Diagram Aktivit 12 – Přidání produktu ubytování k objednávce ubytování. 4.1.36. UC036 – Editace produktů ubytování u objednávky ubytování Stručný popis Tento případ užití slouží pro změnu hodnot u již přidaných produktů objednávky. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 65

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Případ užití začíná stisknutím tlačítka „editace produktů“ uživatelem na stránce s rezervací v sekci „objednávky ubytování“ u konkrétní objednávky. 2. Systém zobrazí nové okno se seznamem produktů objednávky. Seznam je zároveň formulářem, všechny hodnoty lze měnit. 3. Uživatel upraví libovolné položky a stiskne tlačítko „ulož“. 4. Systém zjistí korektnost zadaných údajů. 5. Systém upraví změněné hodnoty u jednotlivých produktů. 6. Uživatel uzavře nové okno. 7. Systém aktualizuje stránku s rezervací. Alternativní scénář 1. a – Systém obdržel požadavek na editaci produktů objednávky následující po případu užití UC035 (alternativní scénář 7. a3) 3. a – Systém stiskne tlačítko „odstraň“ u konkrétního produktu objednávky. Proběhne případ užití UC037. Po ukončení případu užití se může pokračovat kroky 3 a 6 hlavního scénáře. 5. a – Systém zjistil chybně vyplněné hodnoty, případ užití pokračuje 2. krokem hlavního scénáře. Uživatel je navíc informován o chybně zadaných hodnotách a o neuložení změn. Rozšiřující tok událostí 2. – Každý řádek seznamu produktů objednávky obsahuje přepisovatelná políčka: popis typu pokoje, počet produktů (pokojů), počet nocí, ceny za pokoj a noc (brutto a netto), měny brutto a netto ceny, datum od a do, komentář k produktu. V editaci nelze změnit typ produktu, pouze popis pokoje. U každého produktu je ještě tlačítko “ulož“, které uloží hodnoty pouze pro daný produkt a tlačítko „odstraň“, který odstraní konkrétní produkt objednávky. Stav po ukončení Systém uložil nové hodnoty u produktů objednávky. Uživatel zavřel okno s editací produktů objednávky a systém aktualizoval stránku s rezervací. Požadavek na logování Pro každý upravený produkt objednávky systém zaeviduje do logu identifikátor uživatele, akci editaci produktu objednávky, identifikátory produktu objednávky, změny hodnot a čas editace.

66


Obrázek 4-22: Návrh uživatelského rozhraní – Editace produktů objednávky. 4.1.37. UC037 – Odstranění produktu ubytování z objednávky ubytování Stručný popis Tento případ užití slouží pro odstranění produktu objednávky z konkrétní objednávky ubytování. Frekvence užití Méně často Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce (v okně) pro editaci produktů objednávky. Hlavní scénář 1. Systém obdržel požadavek na odstranění produktu objednávky z konkrétní objednávky. 2. Systém zobrazí hlášku, zda uživatel opravdu chce odstranit produkt z objednávky. 3. Uživatel stiskne tlačítko „ano“. 4. Systém odstraní produkt objednávky z databáze. 5. Systém zobrazí naposledy otevřené okno (stránka pro editaci produktů objednávky). Alternativní scénář 3. a1 – Uživatel stiskne tlačítko ne. 67

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 3. a2 – Systém neprovede nic, zobrazí naposledy načtenou stránku (okno). Rozšiřující tok událostí 1. – Uživatel stiskne tlačítko „odstranit“ u konkrétního produktu objednávky na stránce „editace produktů objednávky“. Stav po ukončení Systém odstranil produkt objednávky z databáze. Systém zobrazil stránku s editací produktů objednávky. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění produktu objednávky, hodnoty odstraněného produktu a čas editace. 4.1.38. UC038 – Změna stavu objednávky Stručný popis Tento případ užití slouží pro změnu stavu objednávky. U konkrétní objednávky bude několik „radio buttonů“, kde každý bude symbolizovat jeden možný stav. Označením konkrétního stavu a kliknutím na tlačítko „nastav stav“ dojde k nastavení stavu objednávky. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Případu užití začíná, když uživatel označí některý z možných stavů objednávky u konkrétní objednávky. 2. Uživatel klikne na tlačítko „nastav stav“. 3. Systém změní stav u konkrétní objednávky na označený stav a informuje o tom uživatele Alternativní scénář Žádný Rozšiřující tok událostí Žádný Stav po ukončení Systém změnil stav konkrétní objednávky. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, identifikátor objednávky, původní a aktuální stav, čas změny.

68


Obrázek 4-23: Návrh uživatelského rozhraní – Změna stavu objednávky.

4.1.39. UC039 – Odstranění objednávky ubytování Stručný popis Tento případ užití slouží pro odebrání objednávky ubytování z rezervace. Po stisknutí tlačítka „smazat objednávku“ systém odstraní objednávku z databáze. Frekvence užití Méně často Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Objednávka je ve stavu REQ, nebo PRE Hlavní scénář 1. Případ užití začíná kliknutím na tlačítko „odstraň objednávku“ na stránce s rezervací u konkrétní objednávky. 2. Systém zobrazí javascriptovou hlášku, zda chce uživatel opravdu odstranit objednávku z rezervace. 3. Uživatel stiskne tlačítko „ano“. 4. Systém vyhledá všechny produkty objednávky patřící k dané objednávce. 5. Systém odstraní z databáze všechny produkty objednávky, pokud nějaké existují. 6. Systém odstraní z databáze vlastní objednávku. 7. Systém zobrazí stránku s rezervací a informuje uživatele o odstranění objednávky. Alternativní scénář 3. a1 – Uživatel stiskne tlačítko „ne“. 3. a2 – Systém zobrazí původní stránku s rezervací. Rozšiřující tok událostí Žádný Stav po ukončení Systém odstranil všechny produkty objednávky i objednávku. Systém zobrazil stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, identifikátor rezervace, akci odstranění objednávky, informace o odebírané objednávce a čas odstranění. 69


4.1.40. UC040 – Přidání objednávky služby Analogické k případu užití UC034 – Přidání objednávky ubytování k rezervaci. 4.1.41. UC041 – Editace objednávky služby Stručný popis Procedura pro úpravu údajů u objednané služby. Službu lze upravovat, dokud není její stav „ukončen“. Součástí editace služby může být úkon „odstranění služby“. Kromě formuláře bude stránka obsahovat také tlačítko „ulož“ a „vymaž“. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Objednávka není ve stavu „ukončena“ Hlavní scénář 1. Případ užití začíná stisknutím tlačítka „editace“ uživatelem na stránce s rezervací v sekci „objednávky služeb“ u konkrétní objednávky. 2. Systém zobrazí nové okno s předem vyplněným formulářem pro úpravu objednávky služby dle aktuálních dat získaných z databáze. 3. Uživatel upraví libovolné položky a stiskne tlačítko „ulož“. 4. Systém prověří korektnost zadaných údajů. 5. Systém upraví změněné hodnoty. 6. Systém uzavře nové okno. 7. Systém aktualizuje stránku s rezervací a informuje uživatele o úspěšném provedení změn. Alternativní scénář 3. a – Uživatel uzavře nové okno. Systém neprovede nic. 3. b – Uživatel stiskne tlačítko „vymaž“. Dále se pokračuje případem užití UC042. 5. a – Systém zjistil chyby ve změněných hodnotách objednávky. Dále se pokračuje 2. krokem hlavního scénáře. Systém navíc zobrazí informaci o chybně vyplněných položkách a tyto položky označí. Rozšiřující tok událostí Žádný Stav po ukončení Systém uložil nové hodnoty u objednávky služby. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci objednávky služby, identifikátory objednávky služby, změny hodnot a čas editace. 4.1.42. UC042 – Odstranění objednávky služby Stručný popis 70

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Procedura pro odstranění služby z rezervace. Uživatel stiskne tlačítko „vymaž“ při editaci objednávky služby a systém tuto objednávku odstraní z databáze. Frekvence užití Méně často Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce editace objednávky služby Stav objednávky služby není „ukončena“ ani „fixní“. Hlavní scénář 1. Systém obdrží požadavek na odstranění objednávky služby z rezervace. 2. Systém zobrazí javascriptovou hlášku, zda chce uživatel opravdu odstranit objednávku z rezervace. 3. Uživatel stiskne tlačítko „ano“. 4. Systém ověří, zda parametr „stav“ objednávky služby není „ukončena“, nebo „fixní“. 5. Systém odstraní z databáze objednávku služby. 6. Systém zobrazí aktualizovanou stránku s rezervací a informuje uživatele o odstranění objednávky služby. Alternativní scénář 3. a1 – Uživatel stiskne tlačítko „ne“. 3. a2 – Systém zobrazí původní stránku s editací služby. 5. a1 – Stav objednávky je „fixní“ nebo „ukončena“, systém neodstraní službu, zobrazí naposledy zobrazenou stránku a informuje uživatele, že nelze odstranit službu v tomto stavu. Rozšiřující tok událostí 1. – Uživatel klikne ze stránky „editace objednávky služby“ na tlačítko „vymaž“. Stav po ukončení Systém odstranil objednávku služby z databáze. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, identifikátor rezervace, informace o odebírané službě a čas odstranění. 4.1.43. UC043 – Přidání objednávky přepravy Analogické k případu užití UC034 – Přidání objednávky ubytování k rezervaci. 4.1.44. UC044 – Editace objednávky přepravy Analogické k případu užití UC041 – Editace objednávky služby. 4.1.45. UC045 – Odstranění objednávky přepravy Analogické k případu užití UC042 – Odstranění objednávky služby. 4.1.46. UC046 – Správa komentářů k rezervaci 71


Stručný popis Případ užití „správa komentářů k rezervaci“ slučuje tyto případy užití: přidání, editace a odstranění komentáře. Na stránce rezervace bude existovat sekce „komentáře“. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Systém obdrží požadavek na správu komentáře. • Uživatel stiskne tlačítko „přidej komentář“ • Systém zobrazí textové pole pro přidání komentáře spolu s tlačítkem „ulož“. • Uživatel napíše komentář do textového pole a stiskne tlačítko „ulož“. • Systém uloží komentář k rezervaci • Systém aktualizuje stránku s rezervací • Uživatel stiskne tlačítko „uprav“ u konkrétního komentáře • Systém zobrazí vyplněné textové pole spolu s tlačítkem „ulož“. • Uživatel upraví komentář a stiskne tlačítko „ulož“. • Systém změní komentář u rezervace. • Systém aktualizuje stránku s rezervací. • Uživatel stiskne tlačítko „odstraň“ u konkrétního komentáře • Systém odstraní komentář z rezervace. • Systém aktualizuje stránku s rezervací. Alternativní scénář Žádný Rozšiřující tok událostí Žádný Požadavek na logování Žádný 4.1.47. UC047 – Přidání platby k rezervaci Stručný popis Případ užití začíná stisknutím „přidat platbu“ na stránce rezervace v sekci platby. Systém zobrazí formulář pro přidání platby. Uživatel vybere účel platby a vyplní další vyžadované položky. Po stisknutí tlačítka „ulož“ systém přidá platbu k rezervaci. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 72

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Uživatel se nachází na stránce s rezervací. Hlavní scénář 1. Uživatel klikne na tlačítko „přidat platbu“ na stránce s rezervací v sekci „platby“. 2. Systém otevře nové okno s formulářem pro přidání platby obsahující všechny potřebné parametry a tlačítka „ulož“ a „zavři“. 3. Uživatel vybere typ platby, za jakou objednávku daná platba je a vyplní ostatní údaje ve formuláři. 4. Uživatel stiskne tlačítko „ulož“. 5. Systém zkontroluje správnost zadaných údajů do formuláře. 6. Systém uloží platbu do databáze a přiřadí jí k dané rezervaci. 7. Systém zavře okno s přidáním platby a aktualizuje stránku rezervace. Alternativní scénář 4. a1 – Uživatel stiskne tlačítko „zavřít“. 4. a2 – Systém zavře nové okno a stránku s rezervací neaktualizuje. 6. a1 – Systém zjistil špatně zadané hodnoty, dále se pokračuje krokem 3 hlavního scénáře, přičemž je uživatel o chybně zadaných hodnotách informován textově i graficky. Rozšiřující tok událostí 2 – Kategorie platby může být: ubytování, služba, přeprava nebo „ostatní“. Charakter platby je bud autorizace, předplatba, nebo finální platba. Součástí formuláře bude i převodník měn využívající tabulku „kurz“ . 5 – Kontrola zadání všech povinných údajů, parametr částka musí být číslo větší než 0, parametr poplatky musí být číslo, kontrola správnost data kurzu a autorizace. Stav po ukončení Systém uložil platbu do databáze a aktualizoval stránku s rezervací. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání platby k rezervaci, identifikátor rezervace, identifikátor platby a čas přidání. 4.1.48. UC048 – Editace platby Analogické k případu užití UC041 – Editace objednávky služby. 4.1.49. UC049 – Odstranění platby Analogické k případu užití UC042 – Odstranění objednávky služby. 4.1.50. UC050 – Prohlížení rezervace Stručný popis Případ užití „Prohlížení rezervace“ zobrazí stránku s informacemi o konkrétní rezervaci spolu s ovládacími prvky umožňující rezervaci upravovat. Také je vstupním případem užití pro další případy užití související s editací rezervace. Upravovat rezervaci mohou uživatelé typu PRODEJCE, MANAŽER a ADMINISTRÁTOR. Frekvence užití Opakovaně Hlavní aktéři 73

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Prodejce, Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC029 Uživatel je na stránce se seznamem rezervací. Hlavní scénář 1. Případ užití začíná, když uživatel klikne na odkaz „prohlížení rezervace“ při prohlížení seznamu rezervací. 2. Systém vyhledá všechny údaje související s danou rezervací. 3. Systém zobrazí stránku s rezervací (dále může uživatel pokračovat případy užití UC031-UC049). Alternativní scénář Žádný Rozšiřující tok událostí 3 – Stránka s rezervací se bude skládat z těchto částí: • Hlavička rezervace o Hlavička rezervace bude obsahovat číslo rezervace, stav rezervace, vlastníky rezervace, datum vzniku rezervace a typ rezervace. • Informace i klientovi o Výpis základních informací o klientovi. o Tlačítka „vybrat klienta“ a „editace údajů“. • Objednávky o Objednávky ubytování Výpis všech objednávek ubytování. Každá objednávka bude obsahovat informace o objednávce: • Stav, datum příjezdu a odjezdu, počty osob, věk dětí, případně opci. • Výpis všech produktů k dané objednávce. • U každého produktu objednávky bude vypsáno: počet produktů, počet nocí, celková brutto cena, celková netto cena, měny cen, datum od a datum do. • Tlačítko „přidat produkt“. • Tlačítko „editace produktů“. Tlačítko „přidat objednávku“. Tlačítko „editovat objednávku“ o Objednávky služeb a přepravy Výpis všech objednávek služeb. Každá objednávka bude obsahovat informace o objednávce: • Stav, název služby, datum uskutečnění služby, počty osob, cenu služby. Tlačítka „přidat objednávku“ a „editovat objednávku“ • Platby o Tlačítko „přidat platbu“ o Seznam plateb U každé platby bude tlačítko „editovat platbu“ • Statistika rezervace

74

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Celková brutto cena, celková netto cena, zisk, kolik bylo zaplaceno z celkové částky. Stav po ukončení Uživateli se zobrazila stránka s rezervací. Požadavek na logování Žádný o

4.1.51. UC051 – Prohlížení seznamu rezervací Stručný popis Tento případ užití zobrazí seznam rezervací dle obdržených parametrů. Případ užití také následuje po případu užití Vyhledávání rezervací UC052. Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Hlavní scénář 1. Systém obdrží požadavek na zobrazení seznamu rezervací spolu s parametry, podle kterých má rezervace vyhledat. 2. Systém vyhledá rezervace odpovídající vstupním parametrům. 3. Systém zobrazí seznam rezervací. Alternativní scénář 3. a – Systém nenalezl žádné rezervace odpovídající požadovaným parametrům. Systém o nenalezení rezervací informuje uživatele. Rozšiřující tok událostí 3 – Systém zobrazí tyto informace o rezervaci: Číslo rezervace, jméno a příjmení klienta, emailová adresa klienta, všechny objednávky na ubytování, případně objednávky služeb a přepravy, data objednávek. Navíc se u každé rezervace zobrazí odkaz „prohlížení rezervace“. Stav po ukončení Uživateli se zobrazil seznam rezervací. Požadavek na logování Žádný 4.1.52. UC052 – Vyhledávání rezervací Stručný popis Procedura vyhledávání rezervací nabízí uživateli možnost vyhledávat v databázi rezervací podle těchto parametrů: rezervační číslo, klient, emailová adresa klienta, název ubytování (služby), stavu objednávky, data platnosti objednávky (v případě ubytování je to dle data příjezdu a odjezdu, u služby a přepravy je to konkrétní jedno datum). Uživatel s rolí MANAŽER, nebo ADMINISTRÁTOR může také vyhledávat podle vlastníka rezervace. 75

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Frekvence užití Opakovaně Hlavní aktéři Prodejce, Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“.

Hlavní scénář 1. Uživatel klikne v hlavním menu v sekci Rezervace na odkaz „Vyhledávání“. 2. Systém zobrazí formulář pro vyhledávání rezervací. 3. Uživatel vyplní formulář a stiskne tlačítko „Vyhledat“. 4. Systém uloží do SESSIONS parametry vyhledávání. 5. Systém prohledá databázi rezervace podle zadaných hodnot. 6. Systém zobrazí seznam rezervací odpovídajících požadovaným parametrům pod formulář vyhledávání rezervací (Případ užití UC051 – Prohlížení seznamu rezervací). Alternativní scénář 5. a – Systém nenalezl žádný odpovídající údaj v databázi uživatelů. Systém zobrazí informaci o neexistenci rezervace se zadanými parametry a dále se pokračuje 2.krokem hlavního scénáře (formulář je vyplněn podle naposledy zadaných hodnot). Rozšiřující tok událostí Žádný Stav po ukončení Uživateli se zobrazil seznam rezervací spolu s formulářem vyhledávání vyplněným dle posledního vyhledávání. Požadavek na logování Žádný. Návrh uživatelského rozhraní

76


Obrázek 4-24: Návrh uživatelského rozhraní – Vyhledávání rezervací & seznam rezervací.

4.1.53. UC053 – Vytvoření nového partnera pro služby a přepravu Stručný popis Tento případ užití slouží pro přidání nového partnera poskytující přepravu, nebo doplňkovou službu. Proto budou existovat 2 typy partnerů, které budou mít některé rozdílné atributy. Případ užití začíná kliknutím na odkaz „Přidat partnera“ v levém menu v sekci „Služby a přeprava“ Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Uživatel je role MANAŽER, nebo ADMINITRÁTOR. Hlavní scénář 1. Uživatel klikne v levém menu v sekci „Služby a přeprava“ na odkaz „Přidat partnera“. 2. Systém zkontroluje uživatelovu roli v systému. 3. Systém zobrazí formulář pro přidání nového partnera. 4. Uživatel vyplní údaje do formuláře a také vybere, jestli partner poskytuje služby či přepravu, a stiskne tlačítko „Ulož“. 77

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. 6. 7.

Systém ověří, zda jsou všechny povinné údaje vyplněné a zkontroluje korektnost všech zadaných údajů. Systém uloží informace do databáze. Systém zobrazí údaje o nově zadaném partnerovi.

Alternativní scénář 5. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění (upravení) údajů (hlavní scénář – krok 2). Systém také špatně zadané údaje označí graficky. Rozšiřující tok událostí 4. a - Povinné údaje: Společnost, adresa, emailová adresa. V případě, že uživatel přidává partnera poskytujícího přepravu, musí ještě vyplnit informace o přepravě. Stav po ukončení Partner byl vložen do databáze. Systém informoval uživatele o úspěšném přidání partnera. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nového partnera, identifikátor nového partnera a čas přidání. 4.1.54. UC054 – Prohlížení seznamu partnerů Analogické k případu užití UC009 – Prohlížení seznamu uživatelů. 4.1.55. UC055 – Prohlížení partnera Analogické k případu užití UC014 - Prohlížení údajů o ubytování. 4.1.56. UC056 – Editace partnera pro služby a přepravu Stručný popis Úprava informací o partnerovi poskytující přepravu či doplňkovou službu. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Uživatel je role MANAŽER, nebo ADMINITRÁTOR. Uživatel prohlíží seznam partnerů. Hlavní scénář 1. Případ užití začíná kliknutím na odkaz „edituj“ na stránce se seznamem partnerů. 2. Systém vyhledá v databázi všechny informace o daném partnerovi. 3. Systém zobrazí stránku s formulářem pro editaci partnera. Formulář je vyplněn podle aktuálních údajů o partnerovi. 4. Uživatel upraví požadované údaje a stiskne tlačítko “ulož“. 5. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 78

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 6. 7.

Systém upraví informace o partnerovi. Systém zobrazí stránku s informacemi o partnerovi a zobrazí uživateli informaci o úspěšné úpravě údajů.

Alternativní scénář 5. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění (upravení) údajů (hlavní scénář – krok 2). Systém také špatně zadané údaje označí graficky. Rozšiřující tok událostí 5. – Povinné údaje stejné jako u UC053. Stav po ukončení Systém uložil změny u partnera a zobrazil informaci o úspěšném provedení změn. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci partnera, identifikátor partnera, provedené změny a čas úpravy. 4.1.57. UC057 – Vytvoření nové služby Stručný popis Procedura pro přidání nové služby. Před přidáním služby je nutné nejdříve přidat partnera poskytující konkrétní službu (UC053). Případ užití začíná klepnutím na odkaz „nová služba“ v levém menu v sekci „Služby a přeprava“. Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je v menu „Rezervace“. Uživatel je role MANAŽER, nebo ADMINITRÁTOR. Hlavní scénář 1. Uživatel klikne v levém menu v sekci „Služby a přeprava“ na odkaz „Nová služba“. 2. Systém zkontroluje uživatelovu roli v systému. 3. Systém zobrazí formulář pro přidání nové služby. 4. Uživatel vyplní údaje ve formuláři a vybere partnera poskytující tuto službu. 5. Uživatel vyplní údaje o sezónách poskytované služby. 6. Uživatel stiskne tlačítko „ulož“. 7. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 8. Systém uloží do databáze údaje o službě s jednoznačným identifikátorem 9. Systém uloží do databáze informace o sezónách s identifikátorem služby. 10. Systém zobrazí údaje o nově zadané službě spolu s informací o úspěšném přidání služby. Alternativní scénář

79

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 7. a – Systém zjistil nekorektnost některých vyplněných údajů a vyzve uživatele k doplnění údajů (hlavní scénář – krok 3). Formulář je zobrazen s naposledy zadanými údaji. Špatné údaje jsou také označeny graficky. Rozšiřující tok událostí 3. a – Formulář obsahuje část pro přidání jednoho období ke službě, které se musí povinně vyplnit. V této části také bude tlačítko „přidej další období“, které přidá do formuláře položky pro přidání dalšího období. 7. a – Povinné položky: název, jazyky, místo začátku, délka, popis. Povinné údaje pro období: název, datum od, datum do, časy, dny v týdnu, cena pro dospělého netto a brutto a měna. Stav po ukončení Služba byla vložena do databáze. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci přidání nové služby, identifikátor služby a čas přidání. 4.1.58. UC058 – Prohlížení seznamu služeb Analogické k případu užití UC009 – Prohlížení seznamu uživatelů. 4.1.59. UC059 – Vyhledávání služeb Analogické k případu užití UC008 – Vyhledávání uživatelů. 4.1.60. UC060 – Prohlížení služby Analogické k případu užití UC014 - Prohlížení údajů o ubytování. 4.1.61. UC061 – Editace služby Stručný popis Případ užití sloužící pro úpravu údajů u nabízené služby, který začíná stisknutím odkazu „edituj“ na stránce seznamu služeb u konkrétní služby. Frekvence užití Méně často Hlavní aktéři Manažer, Administrátor Vstupní podmínky Uživatel je přihlášen v systému. Uživatel je role MANAŽER, nebo ADMINITRÁTOR. Uživatel prohlíží seznam služeb. Hlavní scénář 1. Případ užití začíná kliknutím na odkaz „edituj“ na stránce se seznamem služeb. 2. Systém vyhledá v databázi všechny informace o konkrétní službě. 3. Systém zobrazí stránku s formulářem pro editaci služby. Formulář je vyplněn podle aktuálních údajů o službě. 4. Uživatel upraví požadované údaje a stiskne tlačítko “ulož“.

80

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. 6. 7.

Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. Systém upraví údaje o službě a obdobích služby. Systém zobrazí stránku s informacemi o službě (UC060) a zobrazí uživateli informaci o úspěšné úpravě údajů.

Alternativní scénář 4. a1 - Uživatel stiskne tlačítko „přidej období“. 4. a2 - Systém přidá do formuláře položky pro přidání další sezóny k službě. Dále se pokračuje krokem 4 hlavního scénáře. 5. a1 – Systém zjistil chybu v zadaných údajích, nebo zjistil nevyplněnou povinnou položku. 5. a2 – Dále se pokračuje krokem 3 hlavního scénáře, přičemž je formulář vyplněn dle naposledy zadaných hodnot a uživatel informován o špatně zadaných položkách. Rozšiřující tok událostí Žádný Stav po ukončení Systém uložil změny u služby a zobrazil informaci o úspěšném provedení změn. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci editaci služby, identifikátor služby, provedené změny a čas úpravy.

4.1.62. UC062 – Odstranění služby Stručný popis Procedura pro odstranění služby ze systému. Uživatel vyhledá konkrétní službu a vznese požadavek na jeho odstranění. Systém neodstraní službu z databáze, ale pouze nastaví stav služby na „Odstraněno“. Tento případ užití je analogický k případu užití UC006 – Odstranění uživatele. Případné odchylky budou popsány níže. Frekvence užití Minimálně Hlavní aktéři Manažer, Administrátor Vstupní podmínky Dědí od případu užití UC010 Uživatelská role přihlášeného uživatele v systému je MANAŽER, nebo ADMINISTRÁTOR. Hlavní scénář Analogické k UC006 – Odstranění uživatele Alternativní scénář 1. a1 – Uživatel klikne v seznamu služeb nebo v prohlížení údajů o službě na odkaz „odstranit“ u konkrétní sužby. Dále se pokračuje krokem 2 v hlavním scénáři. Rozšiřující tok událostí Analogické k UC006 – Odstranění uživatele Stav po ukončení

81

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Odstraňované službě byl změněn atribut „stav“ na „odstraněn“. Uživateli se zobrazila informace o úspěšném odstranění služby. Požadavek na logování Systém zaeviduje do logu identifikátor uživatele, akci odstranění služby + identifikátor odstraněné služby a čas odstranění.

4.2. Datový model Datové modelování patří k jedné ze základních součástí analýzy softwarového projektu. Úkolem datového modelování je navrhnout kvalitní datovou strukturu pro určitou aplikaci a databázový systém, jenž bude tato aplikace využívat pro ukládání dat. 4.2.1. Konceptuální schéma databáze 4.2.1.1. Teorie Konceptuální model je obecný model pro vytvoření popisu dat v databázi nezávisle na uložení dat. Konceptuální model se zabývá modelováním reality, vychází ze standardů ER diagramů. ER diagram je grafický model, který se skládá z entitních množin (objektů – rezervace, uživatel, ubytování,…), vztahových typů (vztahy, do kterých mohou entity vstupovat – např. daný uživatel[entita] MÁ_VYTVOŘENU[vztah] danou rezervaci ubytování [entita]), atributů (popisuje vlastnosti entit a vztahů – např. atributy entity „UŽIVATEL“ jsou jméno, příjmení, adresa, telefon, země,věk, role uživatele aj.) a integritních omezení (vyjadřuje soulad schématu s modelovanou realitou – např. atribut věk může být pouze celé číslo z rozsahu 1-199). 4.2.1.2. Návrh Navržený konceptuální model (obrázek 4-25) vychází ze standardů ER modelování, přestože již známe konkrétní databázový systém, který bude aplikace využívat. Všechny entity mají svůj jednoznačný identifikátor, který je jediným primárním klíčem konkrétní entity V konceptuálním modelu se vyskytují tyto entity: 1. Rezervace Entita Rezervace slouží pro uložení základních údajů o rezervaci ubytování / dopravy / služby. Každá rezervace obsahuje odkaz na uživatele. Rezervace patří právě jednomu uživateli. 2. Ubytování Entita Ubytování uchovává konkrétní informace o ubytovacích zařízeních. U každého ubytování se odkazuje na entity určující jeho umístění – Země, Oblast, Město a Část města. Dále se také udržuje odkaz na kategorii ubytování. Každé ubytování je umístěno právě v jedné zemi, oblasti, městě, části města a kategorii. 3. Kategorie Tato entita slouží jako tzv. číselník, který uchovává pouze klíč a hodnotu. Entita je určena k uchování všech možných kvalitativních kategorií ubytování, které cestovní agentura nabízí. 4. Země 82


5.

6.

7.

8. 9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

Tato entita slouží jako tzv. číselník. Entita Země slouží pro evidenci zemí, ve kterých jsou umístěna ubytovací zařízení, a také pro uložení názvů států. Oblast Tato entita slouží jako tzv. číselník. Entita Oblast slouží pro evidenci oblastí, do kterých se jednotlivé země v entitě Země dělí. Každá oblast uchovává odkaz na zemi, ve které daná oblast leží. Město Tato entita slouží jako tzv. číselník. Entita Město slouží pro evidenci měst. Každé město je umístěno v právě jedné oblasti. Část města Tato entita slouží jako tzv. číselník. Entita Část města eviduje podrobnější dělení měst z entity Město a je jednoznačně určena názvem a městem. Uživatel Entita Uživatel slouží pro evidenci uživatelů systému a uživatelů webových stránek. Klient Klient je potomkem entity Uživatel, od které přebírá veškeré atributy a navíc definuje atribut datum narození. Jedná se o hierarchický model mezi těmito 2 entitami. Zaměstnanec Také Zaměstnanec je potomkem entity Uživatel. U zaměstnance evidujeme navíc několik dalších atributů oproti Klientovi. Uživatelská role Entita Uživatelská role obsahuje názvy „rolí“ v systému a je ve vztahu s entitou Uživatel. Každému uživateli je přidružena právě jedna role v systému. Produkt Každé ubytovací zařízení může nabízet několik typů pokojů lišících se kvalitou a max. obsazeností. Tyto údaje uchovává entita Produkt. Každý produkt uchovává odkaz na typ pokoje, který je právě jeden. Sekce ceníku Entita Sekce ceníku slouží pro rozdělení ceníků na jednotlivé produkty dle časových období. V sekci může být libovolný počet časových období. Období sekce Každá sekce může obsahovat libovolný počet období, pro která platí ceník. Pro evidenci těchto období slouží entita Období sekce, která také uchovává odkaz na příslušnou Sekci ceníku. Ceník Entita ceník udržuje informace o cenách za konkrétní produkt pro určitou sekci ceníku (pro období v sekci). Každý řádek v tabulce ceník si udržuje odkaz na konkrétní řádek tabulky Produkt a konkrétní řádek tabulky Sekce ceníku. Typ pokoje Tato entita slouží jako tzv. číselník. Entita Typ pokoje eviduje seznam všech možných typů pokojů, které nabízejí ubytovací zařízení pro CA. Objednávka Každá rezervace obsahuje minimálně jednu objednávku ubytování, služby, nebo přepravy. Entita objednávka uchovává informace o těchto objednávkách. Tato entita má 3 potomky: Objednávku ubytování, Objednávku služby a Objednávku přepravy. Vlastní entita Objednávka eviduje pouze informace o stavu objednávky spolu s komentářem a uchovává odkaz na příslušnou rezervaci. Objednávka Ubytování 83


19.

20.

21.

22.

23.

24. 25.

26.

27.

28.

29.

Entita Objednávka Ubytování je potomkem entity Objednávka. Tato entita uchovává základní informace o objednávce, jako jsou počet osob, datum od, datum do či opce. Navíc je ve vztahu k entitě Produkt k objednávce ubytování, kde lze ke každé objednávce přidružit libovolný počet produktů. Každá objednávka ubytování je přiřazena ke konkrétnímu ubytování z entity Ubytování. Produkt k objednávce ubytování. Tato entita vznikla díky vztahu M:N mezi entitami Objednávka a Produkt, kdy jeden produkt může být ve více objednávkách a objednávka může obsahovat více produktů. Tudíž tato entita uchovává odkazy na entitu Objednávka a Produkt. Entita blíže specifikuje informace o objednávce. Typ platby Tato entita slouží jako tzv. číselník. Entita Typ platby eviduje všechny možné možnosti plateb za ubytování a služby, které CA nabízí. Platba Všechny objednávky se mohou dostat do fixního stavu až po splnění určitých podmínek. CA vyžaduje u všech nabízených služeb platbu či garanci předem. Pro evidenci těchto plateb slouží entita Platba, která také uchovává odkaz na entitu Rezervace a Typ platby. Platba je přidružena právě k jedné rezervaci a je jednoho typu. Partner Tato entita slouží pro evidenci partnerů cestovní agentury, jejichž služby (doplňkové služby a přeprava) CA bude nabízet. Tato entita obsahuje atributy společné pro všechny typy partnerů. Poskytovatel služby Poskytovatel služby je konkrétním typem partnera poskytující doplňkové služby pro CA. Poskytovatel přepravy Poskytovatel přepravy je konkrétním typem partnera poskytující přepravu pro CA. Služba Entita služba slouží pro evidenci služeb, které nabízejí jednotliví partneři pro CA. Tato entita je ve vztahu s entitami Poskytovatel služby (Partner) a Sezóna služby. Každou službu poskytuje právě jeden partner, služba musí mít minimálně jednu sezónu. Sezóna Služby Každá služba může být v různých časových obdobích poskytována v různé dny a také se mohou lišit ceny. Tyto informace uchovává tato entita, která je ve vztahu právě s entitou „služba“. Jedna sezóna může být u právě jedné služby, služba může mít více sezón. Objednávka Služby Entita Objednávka služby je potomkem entity „Objednávka“. Udržuje informace o konkrétní objednávce patřící k jedné rezervaci. Tato entita je ve vztahu s entitou „služba“, objednávka služby je právě na jednu službu. Objednávka Přepravy Entita Objednávka přepravy je potomkem entity „Objednávka“ a eviduje údaje o jednotlivých objednávkách přepravy. Objednávka náleží právě k jedné rezervaci a poskytuje ji právě jeden „poskytovatel přepravy“. Slovník Tato entita slouží pro evidenci slov, frází a vět v jednotlivých překladech.

84


85


86


30. CMS Tato entita je určena pro vytváření „článků“ pro webovou aplikaci, které je nutné mít přeložené ve více jazycích. Článek má vždy jednoznačný identifikátor. Entita CMS je ve vztahu s entitou Slovník. 31. Jazyk Entita Jazyk slouží pro evidenci jazyků, které jsou využity v rezervačním systému. 32. Email Entita email slouží pro ukládání odeslaných emailů pomocí rezervačního systému. Každý záznam náleží k jedné rezervaci, popřípadě k jedné konkrétní objednávce. 33. Kurzy (k CZK měně) Entita sloužící pro ukládání informací o denních kurzech, které je potřeba evidovat kvůli platbám v jiných měnách, než je základní měna systému.

4.3. Návrh uživatelského rozhraní Termín uživatelské rozhraní (déle ve zkratce UI – User Interface) lze obecně popsat jako množinu způsobů, kterými uživatelé ovlivňují chování strojů, zařízení či počítačových programů. Uživatelským rozhraním je většinou soubor zobrazovacích a ovládacích prvků, se kterými uživatel pracuje. V případě webových aplikací se rozumí uživatelským rozhraním grafika webové aplikace spolu s klávesnicí a myší. Uživatelské rozhraní je jedním z klíčových faktorů ovlivňující úspěšnost a použitelnost daného systému. Rezervační systém CA jakožto webová aplikace bude využívat grafické uživatelské rozhraní GUI (Graphical User Interface). 4.3.1. Pravidla návrhu UI a. Návrh zaměřený na uživatele Při tvorbě GUI je třeba se zaměřit na uživatele a jeho vztah k systému. Tímto vztahem se také zabývá disciplína HCI (Human Computer Interaction), která zavádí pojem návrhu zaměřeného na uživatele. Základními principy jsou: • Intuitivní ovládání a předvídatelné chování systému. • Přehlednost systému. • Přizpůsobivost systému vzhledem k chování a potřebám uživatele. • Produktivita založená na přehlednosti a zpětných vazbách systému. • Integrita – ochrana před nebezpečnými operacemi, online nápověda. Výše popsané principy jsou základem pro správný návrh uživatelského rozhraní. b. Mezinárodní normy týkající se návrhu uživatelského rozhraní Existují 2 zásadní evropské normy týkající se návrhu UI: norma ISO 9241 a směrnice Evropské Rady 90/270/EWG týkající se Ergonomie software, stanovují kritéria pro tvorbu UI a definují pojem použitelnost. Jedná se však pouze o obecná doporučení a nepříliš podrobný popis, jak tyto pravidla při návrhu využít. Specifikace

87

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ některých částí těchto norem lze nalézt na internetových stránkách zabývajících se návrhem UI. c. Použitelnost (Usability) Použitelnost je obecně termín označující, jak snadno lze dosáhnout kýženého cíle pomocí dostupných ovládacích nástrojů, neboli jak snadno se lidem pracuje s konkrétním systémem a jak rychle jsou schopni dosáhnout svého cíle. Použitelnost webových aplikací je jeden z podoborů v tvorbě www stránek a aplikací [5]. Zabývá se tím, jak snadno a intuitivně se webová aplikace uživateli používá, jak je přehledná a srozumitelná. Použitelnost se zabývá těmito otázkami: • Jak snadno se uživatel naučí web ovládat. • Jak efektivně s aplikací pracuje. • Kolik udělá uživatel chyb při ovládání aplikace a jestli dosáhne svého cíle. • Jak dobře si zvykne na styl ovládání aplikace. Na základě provádění různých testů vznikla tzv. pravidla použitelnosti. Pro různé druhy aplikací a platforem se tato pravidla mohou částečně lišit. Pro webové aplikace tato pravidla popisují, na co jsou uživatelé internetu (webových aplikací) zvyklí a co jim při používání aplikace pomáhá a ulehčuje či urychluje práci se systémem. V další podkapitole uvedu, jaká pravidla použitelnosti využiji při návrhu a implementaci navrhovaného rezervačního systému CA. d. Přístupnost (Accessibility) Pojem přístupnost vyjadřuje míru, s jakou dokážou s webovou aplikací pracovat různě omezení uživatelé. Přístupnost znamená bezbariérovost! Přístupná webová aplikace umožňuje uživateli bez ohledu na jeho hendikep, technické či znalostní vybavení plnohodnotně pracovat s aplikací a umožňuje mu veškerý přístup ke všem důležitým funkcím aplikace. Aby byla aplikace použitelná, musí se zajistit, aby mohl každý tuto aplikaci bez problému využívat vzhledem ke svým potřebám. Hendikepovaní uživatelé jsou např. tito: • uživatelé se zrakovým postižením o slabozrací o nevidomí o barvoslepí • pohybově postižení uživatelé • sluchově postižení uživatelé • uživatelé s poruchami vnímaní textu a poruchou soustředění • uživatelé využívající alternativní hardware a software Přístupná webová aplikace je také taková, která počítá s různým technickým vybavením uživatele. Ne každý uživatel má nejnovější typ počítače či rychlé připojení k internetu. Každý uživatel může využívat jiný typ prohlížeče. Aplikace se musí dokázat přizpůsobit všem těmto nárokům.

88

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.3.2. Návrh UI rezervační systému CA Návrh UI jsem rozdělil do několika částí. Nejdříve je nutné specifikovat prototyp uživatele a technické vybavení tohoto uživatele. Důležité je určit nejmenší možné technické parametry zařízení a software, které bude uživatel využívat. Z hlediska přístupnosti je nutné zjistit od zadavatele, zda se předpokládá, že bude aplikaci využívat hendikepovaná osoba a pokud ano, tak s jakými možnými omezeními. Dalším důležitým krokem je prostudování základních pravidel přístupnosti a použitelnosti, dle kterých by mělo být uživatelské rozhraní navrženo. Třetím krokem je specifikace části uživatelského rozhraní vzhledem k funkcím systému. Po specifikaci bude následovat hrubý návrh rozložení jednotlivých specifikovaných částí. V této fázi návrhu se pracuje pouze s psacími potřebami a papírem. Po hrubém nástinu UI následuje návrh základního grafického rozhraní pomocí některé z grafických aplikací. K tomuto využiji grafického programu Adobe Photoshop. K této části také patří návrh základních elementů rozhraní, které budou globálně využívány (např. jednotné nadpisy, symboly reprezentující nápovědu či chybu v systému, jednotný vzhled formulářů aj.). 4.3.2.1. Specifikace prototypu uživatele a minimálních technických požadavků na sytém Navrhovaný rezervační systém bude pouze interní systém, ke kterému bude mít přístup pouze omezené kvantum uživatelů (zaměstnanci CA). Proto lze specifikovat minimální požadavky na uživatele a technické zázemí: Zaměstnanec společnosti bude mít tyto vlastnosti a dovednosti: • Zkušenosti s prací na PC, zkušenosti s webovými stránkami, práce s MS Word a MS Excel. • Požadavkem zadavatele na zaměstnance je minimálně středoškolské vzdělání. • Musí dokázat ovládat myš a klávesnici pomocí rukou. Zaměstnanec nesmí být: • Nevidomý (částečné problémy se zrakem nejsou překážkou – slabozrakost, barvoslepost). • Nesmí mít velké pohybové omezení horních končetin (vzhledem k povaze celého pracovního úvazku). Zaměstnanec může mít tyto hendikepy: • Menší zrakové postižení. • Sluchové postižení. • Pohybové postižení (mimo horní končetiny). Dále je nutné počítat s různým technickým vybavením uživatelů. Na základě konzultace se zadavatelem jsem vytvořil seznam minimálního hardwarového a softwarového vybavení. Na základě tohoto seznamu by měla být aplikace provozu schopná i při této minimální konfiguraci: • Hardware o Počítač s procesorem 500 MHz, paměť 256 MB. o Monitor a grafická karta podporující rozlišení min. 1024x 768. • Software

89

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ o o

Webový prohlížeč IE7 a IE8, Mozilla Firefox 2 a 3, Opera, Google Chrome. Aplikace by neměla doznat změn při použití libovolného z výše popsaných prohlížečů.

Při návrhu a vlastní implementaci je proto nutné počítat s těmito omezeními. 4.3.2.2. Pravidla přístupnosti zásadní pro návrh aplikace Návrh UI a vlastní implementace nemůže postihnout všechna pravidla, ale určitě musí být použita všechna pravidla vhodná pro tento typ systému. V této části vycházím z pravidel „pravidla přístupného webu“ pro účely novely Zákona č. 365/2000 Sb. o informačních systémech veřejné správy, provedenou zákonem č. 81/2006 Sb. [2]. Tato pravidla přístupnosti slouží pro návrh informačních webových stránek orgánů veřejné správy. Návrh rezervačního systému CA bude vycházet z těchto základních pravidel, uvedu pouze nejdůležitější z nich: • Obsah webových stránek je dostupný a čitelný o Informace sdělované prostřednictvím skriptů, objektů, appletů, kaskádových stylů, cookies a jiných doplňků na straně uživatele, musí být dostupné i bez kteréhokoliv z těchto doplňků a stránky musí být standardně ovladatelné. o Informace sdělované barvou musí být dostupné i bez barevného rozlišení. o Barvy popředí a pozadí musí být vůči sobě dostatečně kontrastní, jestliže text nese významové sdělení. o Velikost písma lze měnit na 2-násobek standardní velikosti pomocí standardních funkcí prohlížeče, aniž by došlo ke ztrátě informací a funkcionality. • Práci s webovou stránkou řídí uživatel o Načtení nové stránky či přesměrování na jinou stránku může proběhnou pouze poté, co uživatel klikl na odkaz, nebo odeslal formulář. o Načtení nové webové stránky jen v odůvodněných případech a uživatel by měl na toto být předem upozorněn. o Na stránkách nesmí docházet více jak 3x za sekundu k výrazným změnám barevnosti, kontrastu či jasu, či změnám polohy prvku (např. animace). • Přehlednost a srozumitelnost informací o Stránka musí sdělovat informace jednoduchým jazykem a srozumitelnou formou. Možné problémy s nepochopením by měla řešit nápověda. o Rozsáhlé obsahové bloky by se měly dělit do menších, výstižně nadepsaných částí. • Pochopitelné ovládání webové aplikace o Navigace musí být srozumitelná a konzistentní, na všech stránkách systému musí být obdobná. Jednotlivé odkazy v navigaci musí být krátké a výstižné, uživatel musí pochopit, kam se po jejich aktivaci dostane. o Každá stránka musí obsahovat odkaz vyšší úroveň v hierarchii stránek a odkaz na hlavní stránku (tzv. drobečková navigace). o Každá stránka aplikace musí mít unikátní a výstižný název. 90

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Každý prvek ve formuláři musí mít vystihující popisek. V případě, že uživatel učinil chybu při vyplňování formuláře, musí dostat informaci o tom, která položka byla špatně vyplněna, a případně i informaci, jak tuto chybu odstranit. Některá další pravidla z dokumentu [2] nepatří již k návrhu UI, ale k vlastní implementaci a ta v této části nebudu zmiňovat. o o

4.3.2.3. Pravidla použitelnosti zásadní pro návrh aplikace Existuje mnoho pravidel použitelnosti. Některá jsou daná standardem, jiná jsou pouze uživatelským doporučením zjištěná pomocí testování. Každý uživatel může pod pojmem „použitelné“ vidět něco jiného. Např. člověk, který se živí jako programátor, může vidět stránku s e-obchodem jako jednoduchou na použití, dokáže v ní nakoupit zboží do 2 minut. Další uživatel se základním počítačovým vzděláním není schopen nakoupit ani za 10 minut, protože nemůže přijít na to, jak vlastně daný systém funguje. V zásadě je lepší předpokládat uživatele jako neznalého, toho, který nemá příliš zkušeností s rozmanitostí webů a je zvyklý na nějaký standard vzhledu webových stránek. Rezervační systém CA musí určitě vycházet z těchto pravidel: • • • •

• • • • • •

Vytvoření jasné vizuální hierarchie na stránkách. Rozdělení aplikace do jasně definovaných oblastí – souvisí s vizuálními hranicemi. Neměnit zvyklosti, vše musí být pochopitelné (např. menu se vždy nachází nahoře či vlevo, vyhledávání je vždy vpravo nahoře). Vyznačení odkazů – vše, co je odkaz, by mělo být podtrženo, odkazy v menu nemusí být vždy podtrženy, ale je třeba se držet zvoleného stylu u všech odkazů v menu. Do stránek nevkládat zbytečnosti. Vyvarovat se chyb v aplikaci. Když už chyba nastane, musí na ni systém upozornit. Pro hlášení chyb by měl být jednotný formát. Uživatel by měl být intuitivně schopen systém ovládat bez použití obsáhlé nápovědy. Nápověda by měla být krátká a výstižná, pokud je to možné. Kvalitní nápověda a dokumentace. Systém by měl mluvit mluvou uživatelů, spíše než využívat nějaké odborné fráze. Pokud je to nezbytné, je třeba tuto frázi uživateli vysvětlit. Systém by měl vždy mít stejný vzhled, pokud se jedná o položky stejného významu. Např. nadpisy by měly vypadat na všech stránkách stejně, stejný vzhled formulářů a tabulek, konzistentní barvy odkazů a textů.

Zde jsem popsal několik ze základních pravidel použitelnosti spolu s pravidly, o kterých si myslím, že by měla být v návrhu použita. Konkrétní pravidla uvedu přímo u vlastního návrhu vzhledu aplikace.

91

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.3.2.4. Struktura uživatelského rozhraní vzhledem k funkčnosti aplikace Struktura návrhu webové aplikace navrhovaného systému se bude skládat ze 3 částí: hlavičky, levého menu a obsahové části. Při návrhu se budu snažit využít znalostí z mnou využívaných webových aplikací spolu s pravidly použitelnosti. Hlavička Hlavička je umístěna na stránce úplně nahoře, pokrývá celou část šířky vymezeného okna pro aplikaci, její výška bude kolem 100 obrazových bodů (pixelů). Hlavička bude obsahovat logo systému (název), horní navigační lištu a údaje o přihlášeném uživateli. Logo (název systému) Logo bude dle konvencí umístěno vlevo nahoře. Logo bude zároveň odkazem na hlavní stránku. Horní navigační lišta Horní navigace bude obsahovat základní navigaci pro systém. Bude se dělit na 2 části. První část bude umístěna na levém menu a bude ovládat levé menu (systém se bude dělit na 2 části – rezervační a webová část). Druhá část horní navigace bude obsahovat odkazy na obecné systémové stránky včetně hlavní stránky (odkazy Domů, CMS, Nastavení a Nápověda). Jednotlivé odkazy navrhuji ve formě záložek – v současné době velmi používané a jasně rozpoznatelné jako navigace. Záložky budou mít 2 barvy. Jedna barva pro označení právě vybrané stránky, druhá pro ostatní. Informace o uživateli Informace o uživateli a tlačítko „odhlásit“ bude umístěno vpravo nahoře. Pokud není přihlášen žádný uživatel, toto místo zůstane prázdné. Po přihlášení se v tzv. ohraničeném boxu zobrazí jméno uživatele, jeho role v systému a také tlačítko odkaz „odhlásit“. Tento odkaz bude jasně viditelný, bude mít odlišnou barvu oproti ostatním odkazům, ale bude ladit s celkovým dizajnem stránky. Levé menu Levé menu je umístěno na levé straně ihned pod hlavičkou a ve svislém směru bude zabírat zbytek stránky (vždy vyplní celou svislou část stránky). Šířka levého menu bude kolem 150-250 pixelů. Levé menu bude obsahovat pouze navigaci rezervačního systému a bude se měnit podle zvolené záložky v horní navigační liště (rezervace|web). Navigace bude rozčleněna do několika logických částí (rezervace, ubytování, uživatelé, služby a přeprava, statistiky). Každá část bude mít výrazný nadpis a bude graficky oddělena od ostatních částí. Obsahová část Obsah bude umístěn ve zbylé oblasti vyhrazené stránky, tedy napravo od levého menu. Úplně nahoře v obsahové části bude umístěn nadpis stránky spolu s „drobečkovou navigací“. Drobečková navigace ukazuje na umístění aktuální stránky v hierarchii stránek aplikace (např. Domů > Uživatel > Přidání uživatele).

92

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.3.2.5. Návrh uživatelského rozhraní pomocí grafického programu V této části jsem se poprvé začal zabývat otázkou barevného provedení vzhledu aplikace. Barevné provedení Vzhledem ke svým dosavadním zkušenostem a oblíbenosti jednotlivých barev jsem zvolil jako základní barevný odstín modrou barvu. Systému budou vévodit 4 barevné odstíny (obrázek 4-26): světle modrá pro podklad obsahové části, tmavě modrá pro obě navigační lišty, bílá pro podklad hlavičky a text odkazů pod tmavě modrým pozadím a nakonec černá pro ostatní text. Tyto odstíny barev jsem volil tak, aby byly dostatečně vzájemně kontrastní, k tomu jsem využil programu pro porovnávání kontrastů dvou barev. Navíc jsem využil tmavě žlutou barvu pro zvýraznění odkazu pro „odhlášení“. Tato barva také vyšla jako vhodná pro obarvení právě označených odkazů. Vzhled dalších elementů webové aplikace se bude řídit tímto základním barevným schématem. Návrh standardních prvků aplikace Standardními prvky je myšleno to, že každý z těchto prvků bude vypadat ve všech částích aplikace stejně. Z obrázku 4-27 jsou vidět návrhy: • nadpis stránky s drobečkovou navigací • formuláře • ikony označující nápovědu • ikony označující chybu K vytvoření základního návrhu uživatelského rozhraní jsem použil grafického editoru Adobe Photoshop CS3.

Obrázek 4-26 : Návrh základního uživatelského rozhraní v grafickém editoru. 93


Obrázek 4-27 : Návrh dalších elementů aplikace zobrazených v obsahové části, které budou stejné pro všechny stránky.

94

KAPITOLA 5. IMPLEMENTACE

5 Implementace Tato kapitola se zabývá vlastní implementací systému navrženého zejména podle analýzy návrhu popsané v kapitole 4. Implementace probíhala v několika fázích, které se vzájemně prolínaly a budou níže podrobněji popsány. Při implementaci jsem využil tyto programy: • PsPad 4.5.3 – Volně šiřitelný (freeware) textový editor, který jsem si oblíbil vzhledem k jeho jednoduchosti a možnosti zvýrazňování syntaxe pro mnoho druhů zdrojových kódů včetně Smarty. • WampServer 2.0 – Instalační balík obsahující server Apache 2.2.11, PHP 5.3 a databázový server MySQL 5.1.36. Jeho výhodou je jednoduchá instalace, která dokáže sama nastavit základní vlastnosti serveru. • Internet Explorer 7, Mozzila Firefox 3.5, Opera 10, Google Chrome, IETester(prohlížeč umožňující simulovat několik verzí prohlížeče Internet Explorer) – Tyto webové prohlížeče jsem využil pro testování aplikace. • Adobe Photoshop CS3 – Grafický bitmapový editor, který jsem využil pro návrh uživatelského rozhraní a posléze layoutu celé aplikace.

5.1. Datový model (fyzická reprezentace dat), implementace datového modelu Fyzická reprezentace dat je popsána datovým modelem, který vychází z konceptuálního návrhu, jenž je uveden v kapitole 4.2. Pro ukládání dat využívá systém databáze MySQL. Následující tabulky popisují atributy jednotlivých databázových tabulek. Každý řádek tabulky bude obsahovat následující informace: • Název atributu. • Datový typ – Datový typ určuje typ a rozsah velikosti záznamu a je uveden podle standardu SQL. • Vlastnosti, omezení – V tomto sloupci budou uvedena integritní omezení pro konkrétní atribut, případně slovní upřesnění významu atributu. Některé parametry v tomto sloupci budou uvedeny zkratkou: o PK – Primární klíč o FK – Cizí klíč o AI – Automatické zvyšování hodnoty o REF (id) – Reference o VP() – Výchozí parametr – v závorce je uvedena hodnota Význam jednotlivých tabulek byl již popsán v části 4.2.1.2. Upřesnění některých tabulek uvedu přímo k jednotlivým tabulkám. Navržený systém je koncipován s možností vícejazyčnosti. Proto je potřeba některé texty ukládat mimo konkrétní tabulku, která by umožňovala uložit text pouze v jedné jazykové verzi. Z tohoto důvodu vznikla tabulka slovník, kde atribut „fraze_id“ bude logicky spojovat všechny jazykové verze jednoho textu (bude mít stejné číslo). Jazyk bude uložen ve zkrácené podobě v atributu „jazyk“. Atribut stav může nabývat hodnot od 0 do 2 (0 = nepřeložená fráze, 1 = přeložená fráze neaktivní, 2 = přeložená fráze aktivní). Atribut „typ“ bude sloužit pro zařazení textu do skupin pro snazší určení stavu fráze.

95


Obrázek 5-1: Fyzický model dat 96

KAPITOLA 5. IMPLEMENTACE slovnik Datový typ Int(11) Int(11) Varchar(2) Text Int(1) Varchar(20)

Název atributu id fraze_id jazyk text stav typ

Omezení, upřesnění PK, AI, Not Null Not Null Not Null Not Null Not Null, hodnoty 0-2 Null, VP(NULL)

Tabulka 6-1: Databázová tabulka slovnik

Tabulka uzivatelska_role slouží pro evidenci uživatelských rolí v systému spolu s jejich popisem a právy v systému. Atribut „prava“ bude obsahovat hodnoty ze struktury atributu „role“, a to právě ty, jejichž práva také pod něj hierarchicky spadají. uzivatelska_role Datový typ Int(10) Enum(‘prodejce’,’spravce_cms’, ‘manazer’,’administrator’, ‘klient’) Varchar(100) Varchar(255)

Název atributu id role

prava popis

Omezení, upřesnění PK, AI, Not Null Not Null

Not Null Not Null

Tabulka 6-2: Databázová tabulka uzivatelska_role

Tabulka uzivatel slouží pro uložení informací o uživatelích systému a klientech. Kvůli zjednodušení jsem sloučil entity Zaměstnanec a Klient a jejich atributy přidal k entitě Uživatel. Tyto parametry budou defaultně nulové. Atribut „heslo“ bude obsahovat uživatelem zadané heslo v šifrované podobě. Datový typ „timestamp“ má tento tvar: „YYYY-MM-DD HH:MM:SS“ (rok-měsíc-den hodina:minuta:sekunda).

Název atributu id uzivatelske_jmeno heslo jmeno prijmeni email telefon firma Fax zeme_id

uzivatel Datový typ Int(10) Varchar(50) Varchar(40) Varchar(50) Varchar(50) Varchar(100) Varchar(100) Varchar(50) Varchar(50) Int(10)

timestamp_registrace timestamp_posledni_prihlaseni role_id

Timestamp Timestamp Int(10)

jazyk_id

Varchar(2)

adresa

Varchar(255) 97

Omezení, upřesnění PK, AI, Not Null Not Null, Unikátní Null, VP(NULL) Not Null Not Null Not Null Null, VP(NULL) Null, VP(NULL) Null, VP(NULL) Null, VP(NULL), REF(zeme.id) Not Null, VP(aktuální čas) Null, VP(NULL) Not Null, REF(uzivatelska_role.id) Not Null, VP(cz), REF(jazyk.id) Null, VP(NULL)

KAPITOLA 5. IMPLEMENTACE komentar narozeniny status

Text Varchar(20) Enum(‘visible’,’invisible’, ’junk’)

Null, VP(NULL) Null, VP(NULL) Not Null, VP(visible)

Tabulka 6-3: Databázová tabulka uzivatel Tabulka zeme slouží pro evidenci zemí (států). Atribut „nazev_fraze_id“ odkazuje na tabulku slovnik, ve které je uložen vlastní název země. Tento atribut je takto uložen proto, že se předpokládá vícejazyčné využití systému, a proto může existovat více záznamů v tabulce slovník (pro každý překládaný jazyk jeden záznam). Pro všechny atributy v ostatních tabulkách, v jejichž názvu se objeví na konci „fraze_id“, platí tento popis, jenž už dále nebude uváděn. zeme Název atributu Id nazev_fraze_id

Datový typ Int(11) Int(11)

Omezení, upřesnění PK, AI, Not Null Not REF(slovnik.fraze_id)

Null,

Tabulka 6-4: Databázová tabulka zeme

oblast Název atributu id nazev_fraze_id


zeme_id

Int(11)

Omezení, upřesnění PK, AI, Not Null REF(slovnik.fraze_id), Null REF(zeme.id), Not Null

Not

Tabulka 6-5: Databázová tabulka oblast

mesto Název atributu id nazev_fraze_id


oblast_id

Int(11)

Omezení, upřesnění PK, AI, Not Null REF(slovnik.fraze_id), Null REF(oblast.id), Not Null

Not

Tabulka 6-6: Databázová tabulka mesto Tabulka cast_mesta slouží pro evidenci částí měst pro města uvedená v tabulce mesto. Atribut „mesto_id“ obsahuje identifikátor konkrétního města (tzv. referenci), který je poté využit při získání informací o daném městě.

Název atributu id nazev_fraze_id

cast_mesta Datový typ Int(11) Int(11)

mesto_id

Int(11)

Omezení, upřesnění PK, AI, Not Null REF(slovnik.fraze_id), Null REF(mesto.id), Not Null

Tabulka 6-7: Databázová tabulka cast_mesta 98

Not



kategorie Datový typ Int(11) Int(11)

Omezení, upřesnění PK, AI, Not Null REF(slovnik.fraze_id), Null

Not

Tabulka 6-8: Databázová tabulka kategorie

Tabulka ubytování slouží pro evidenci hotelů, apartmánů, chatek a jiných ubytovacích zařízení. Název a popis ubytování se ukládají do slovníku, jelikož se předpokládá využití této tabulky i u webové prezentace, pomocí níž cestovní agentura nabízí ubytování. Pokud je datový typ atributu Int(1), hodnoty budou nabývat pouze hodnot 0 nebo 1 (0 = ubytování neposkytuje, 1 = ubytování poskytuje). Ubytování nemusí být zařazeno v žádné „části města“ (atribut cast_mesta_id = 0). Hodnota atributu „gps_souradnice“ bude ve tvaru „lat.gps“+“;“+“len.gps“. Atribut „stav“ může nabývat 3 hodnot: „visible“ = hotel je aktuálně nabízen cestovní agenturou, „invisible“ = hotel není aktuálně nabízen CA, kdykoli ho lze vrátit do stavu „visible“, „junk“ = hotel je smazaný, ale zůstává v databázi kvůli statistikám (nelze již změnit stav).

Název atributu id nazev_fraze_id popis_fraze_id kategorie_id zeme_id oblast_id mesto_id cast_mesta_id email telefon adresa web fax gps_souradnice stav koupelna sprcha mycka kuchynka lednicka klimatizace trezor detska_postylka televize radio dvd satelit

ubytovani Datový typ Int(11) Int(11)

Omezení, upřesnění PK, AI, Not Null REF(slovnik.fraze_id), Not Null Int(11) REF(slovnik.fraze_id),Not Null Int(11) Not Null, REF(kategorie.id) Int(11) Not Null, REF(zeme.id) Int(11) Not Null, REF(oblast.id) Int(11) Not Null, REF(mesto.id) Int(11) Not Null, VP(0), REF(cast_mesta.id) Varchar(100) Not Null Varchar(50) Null Text Not Null Text Null Varchar(50) Null Varchar(50) Null Enum(‘visible’,’invisible’,’junk’) Not Null, VP(invisible) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) Int(1) Not Null, VP(0) 99

KAPITOLA 5. IMPLEMENTACE telefon_na_pokoji fen minibar konvice zehlicka recepce restaurace pokoj_s_balkonem vytah male_zvire bazen fitnes kongresove_centrum pocet_pokoju pocet_luzek pocet_bezbarierovych_pokoju pocet_kurackych_pokoju

Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(1) Int(3) Int(4) Int(3) Int(3)

Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0) Null Null Null Null

Tabulka 6-9: Databázová tabulka ubytovani


typ_pokoje Datový typ Int(10) Int(10)


Not

Tabulka 6-10: Databázová tabulka typ_pokoje

Následující 4 tabulky slouží pro evidenci ceníků ubytovacích zařízení. Jsou to tabulky produkt, sekce_ceniku, obdobi sekce a cenik. V tabulce produkt atribut „pocet_lidi“ může být omezen max. číslem 99, jelikož není doposud znám pokoj, apartmán či chata pro více než 99 osob. Atributy „ubytovani_id“, „typ_pokoje_id“ a „komentar_fraze_id“ jsou referencemi na další tabulky.

Název atributu Id ubytovani_id pocet_lidi typ_pokoje_id komentar_fraze_id

produkt Datový typ Int(10) Int(10) Int(2) Int(10) Int(10)

Omezení, upřesnění PK, AI, Not Null Not Null, REF(ubytovani.id) Not Null Not Null, REF(typ_pokoje.id) Null, REF(slovnik.fraze_id)

Tabulka 6-11: Databázová tabulka produkt Tabulka sekce_ceniku slouží pro členění cen do sekcí, ve kterých se mohou ceny lišit. Atribut „typ“ specifikuje sekci ceníku takto: „normal“ = běžné ceny, „special“ = speciální nabídka, „top“ = ceny v top termínech. Stejné typy sekce se nemohou prolínat v obdobích, různé typy ano. Nejvyšší váhu má „top“ sekce, poté „special“ a posledním je „normal“. Popis sekce není povinný.

100


Název atributu id ubytovani_id typ popis

sekce_ceniku Datový typ Int(10) Int(10) Enum(‘normal’,’special’,’top’) Text

Omezení, upřesnění PK, AI, Not Null Not Null, REF(ubytovani.id) Not Null, VP(normal) Null

Tabulka 6-12: Databázová tabulka sekce_ceniku

Název atributu id sekce_ceniku_id

obdobi_sekce Datový typ Int(10) Int(10)

datum_od datum_do

Date Date

Omezení, upřesnění PK, AI, Not Null Not REF(sekce_ceniku.id) Not Null Not Null

Null,

Tabulka 6-13: Databázová tabulka obdobi_sekce

Tabulka cenik slouží pro uložení cen pro každý produkt v každé sekci. Proto obsahuje 2 parametry s referencemi na příslušné tabulky. V této tabulce je použit datový typ „enum“ pro uložení typu měny pro jednotlivé ceny. Jelikož máme konkrétní množství měn, ve kterých půjde ukládat ceny, je tento typ vhodnější z hlediska rychlosti databázového serveru než např. datový typ varchar. Ceny jsou datového typu „float“. cenik Název atributu id sekce_ceniku_id


produkt_id cena_brutto mena_brutto cena_netto mena_brutto cena_pult mena_pult

Int(10) Float Enum(‘CZK’,’EUR’,’USD’) Float Enum(‘CZK’,’EUR’,’USD’) Float Enum(‘CZK’,’EUR’,’USD’)

Omezení, upřesnění PK, AI, Not Null Not Null, REF(sekce_ceniku.id) Not Null, REF(produkt.id) Not Null Not Null, VP(CZK) Not Null Not Null, VP(CZK) Not Null Not Null, VP(CZK)

Tabulka 6-14: Databázová tabulka cenik

Tabulka typ_platby slouží pro evidenci možností plateb, které nabízí CA. Tuto tabulku budou využívat tabulky rezervace a platba.


typ_platby Datový typ Int(11) Int(11)


Tabulka 6-15: Databázová tabulka typ_platby 101

Not


V tabulce rezervace jsou ukládány základní informace o rezervaci. Tato tabulka je základní při vytváření rezervací a několik dalších tabulek obsahuje referenci na ni. Jelikož se bude převážná část atributů vyplňovat až při zpracovávání rezervace (ne při vytvoření), mohou být tyto atributy nulové.

Název atributu id uzivatel_id kontaktni_jmeno kontaktni_prijmeni kontaktni_email kontaktni_telefon kontaktni_firma jmeno_na_voucher zamestnanci typ_platby timestamp_vytvoreni mena_platby komentar komentar_klienta typ stav aktuální_kurz_CZK aktuální_kurz_USD aktualni_kurz_HUF

rezervace Datový typ Int(10) Int(10) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(100) Int(10) Timestamp Varchar(3) Text Text Enum(‚normal’,’online’) Enum(‚new’,’request’,’final’, ‘junk’) Double Double Double

Omezení, upřesnění PK, AI, Not Null Null, REF(uzivatel.id) Null Null Null Null Null Null Null Null, REF(typ_platby.id) Not Null, VP(CURRENT_TIMESTAMP) Null, VP(CZK) Null Null Not Null, VP(normal) Not Null, VP(new) Not Null, VP(0) Not Null, VP(0) Not Null, VP(0)

Tabulka 6-16: Databázová tabulka rezervace

Tabulka objednavka_ubytovani slouží pro evidenci objednávek ubytování. Každý záznam v tabulce je propojen s tabulkou ubytovani a rezervace. Atribut stav může nabývat hodnot uvedených v kapitole 3. Úvodní studie, podsekce 3.2.4 – Rezervace – stavy objednávky (REQ = odpovídá bodu 1, PRE = 2, FIX = 3, CH-IN = 4, CH-OUT = 5, CLX = 6, CLX-FIX = 7).

Název atributu id rezervace_id ubytovani_id datum_od datum_do pocet_dospelych pocet_studentu pocet_deti opce vek_deti typ

objednavka_ubytovani Datový typ Int(10) Int(10) Int(10) Date Date Int(3) Int(3) Int(3) Datetime Varchar(20) Varchar(20) 102

Omezení, upřesnění PK, AI, Not Null Not Null, REF(rezervace.id) Not Null, REF(ubytovani_id) Null Null Not Null Not Null Not Null Null Null Null

KAPITOLA 5. IMPLEMENTACE stav

Enum(‘REQ’, ‘PRE’, ‘FIX’, Not Null, VP(REQ) ‘CH-IN’, ‘CH-OUT’, ‘CLX’, ‘CLX-FIX’) Text Null

komentar

Tabulka 6-17: Databázová tabulka objednavka_ubytovani

Název atributu id objednavka_id

produkt_objednavky Datový typ Int(10) Int(10)

produkt_id

Int(10)

pocet_noci pocet_produktu cena_netto mena_netto cena_brutto mena_brutto datum_od datum_do popis_typu_pokoje komentar

Int(3) Int(3) Double Varchar(3) Double Varchar(3) Date Date Text Text

Omezení, upřesnění PK, AI, Not Null Not Null, REF(objednavka_ubytovani.iud) Not Null, VP(0), REF(produkt.id) Not Null Not Null, VP(1) Not Null, VP(0.0) Not Null Not Null, VP(0.0) Not Null Not Null Not Null Not Null Null

Tabulka 6-18: Databázová tabulka produkt_objednavky Tabulka platba slouží pro evidenci plateb za objednávky. Atribut „objednavka_id“ je referencí na jednu z těchto 3 tabulek: objednavka_ubytovani, objednavka_sluzby a objednavka_prepravy. Na jakou z těchto 3 tabulek je odkazováno určuje atribut „kategorie“, který může navíc nabývat hodnoty „ostatní“. V tomto případě je atribut „objednavka_id“ 0.

charakter typ castka poplatky mena cas_platby

platba Datový typ Int(10) Int(10) Int(10) Enum(‘ubytovani’, ’preprava’, ’sluzba’,ostatni) Enum(‘predplatba‘,finalni‘‘) Int(10) Double Double Varchar(3) Timestamp

cislo_karty cislo_autorizace datum_autorizace datum_kurzu komentar

Varchar(30) Varchar(30) Timestamp Timestamp Text

Název atributu id rezervace_id objednavka_id kategorie

103

Omezení, upřesnění PK, AI, Not Null Not Null, REF(rezervace.id) Not Null, VP(0) Not Null Not Null Not Null Not Null Not Null, VP(0) Not Null Not Null, VP(CURRENT_TIMESTAMP) Null Null Null Null Null

KAPITOLA 5. IMPLEMENTACE Tabulka 6-19: Databázová tabulka platba Tabulka partner obsahuje informace o partnerech CA, jejich služby CA nabízí. Pro uložení partnera je minimálně požadováno zadání emailové adresy partnera a název společnosti (jejich hodnoty nemohou být NULL). Kvůli jednoduchosti spojuje tato tabulka atributy z entit Poskytovatel přepravy a Poskytovatel služby.

Název atributu id spolecnost adresa fax email web komentar informace_o_preprave

partner Datový typ Int(10) Varchar(100) Varchar(100) Varchar(50) Varchar(100) Varchar(100) Text Text

Omezení, upřesnění PK, AI, Not Null Not Null Null Null Not Null Null Null Null

Tabulka 6-20: Databázová tabulka partner

Název atributu id ridic typ rezervace_id partner_id datum cas místo_odjezdu konecne_misto jmeno pocet_osob pocet_detskych_sedacek cena_netto mena_netto cena_brutto mena_brutto cislo_letu komentar

objednavka_prepravy Datový typ Int(10) Varchar(100) Varchar(100) Int(10) Int(10) Date Time Varchar(100) Varchar(100) Varchar(50) Int(3) Int(3) Double Varchar(3) Double Varchar(3) Varchar(50) Text

Omezení, upřesnění PK, AI, Not Null Not Null Not Null Not Null Not Null Not Null Not Null Null Null Null Not Null Not Null Not Null Not Null Not Null Not Null Null Null

Tabulka 6-21: Databázová tabulka objednavka_prepravy Tabulky služba a období sluzby slouží pro evidenci služeb, které nabízejí partneři cestovní agentury. Z databáze služeb si poté klienti vybírají konkrétní služby, které jsou následně evidovány v tabulce objednavka_sluzby. sluzba Název atributu id partner_id nazev_fraze_id

Datový typ Int(10) Int(10) Int(10) 104

Omezení, upřesnění PK, AI, Not Null Not Null, REF(partner.id) Not Null

KAPITOLA 5. IMPLEMENTACE jazyky misto_zacatku misto_konce delka popis_fraze_id komentar stav

Varchar(100) Varchar(100) Varchar(100) Double Int(10) Text Enum(‘REQ’, ’PRE’, ’FIX’, ‘CH-OUT’,’CLX’)

Null Null Null Null Not Null Null Not Null, VP(REQ)

Tabulka 6-22: Databázová tabulka sluzba

Název atributu id sluzba_id nazev datum_od datum_do casy dny_v_tydnu cena_netto_dospely cena_brutto_dospely cena_netto_student cena_brutto_student cena_netto_dite cena_brutto_dite mena max_pocet_osob

sezona_sluzby Datový typ Int(10) Int(10) Varchar(50) Date Date Varchar(100) Varchar(30) Double Double Double Double Double Double Varchar(3) Int(3)

Omezení, upřesnění PK, AI, Not Null Not Null, REF(sluzba.id) Not Null Not Null Not Null Null Null Not Null Not Null Null Null Null Null Not Null Null

Tabulka 6-23: Databázová tabulka sezona_sluzby

Název atributu id rezervace_id sluzba_id typ datum cas jazyk nazev pocet_dospelych pocet_studentu pocet_deti cena_netto_dospely cena_brutto_dospely cena_netto_student cena_brutto_student cena_netto_dite cena_brutto_dite mena_netto_cen

objednavka_sluzby Datový typ Int(10) Int(10) Int(10) Varchar(50) Date Time Varchar(2) Varchar(100) Int(3) Int(3) Int(3) Double Double Double Double Double Double Varchar(3) 105

Omezení, upřesnění PK, AI, Not Null Not Null, REF(rezervace.id) Not Null, REF(sluzba.id) Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null Null Null Null Null Not Null

KAPITOLA 5. IMPLEMENTACE mena_brutto_cen zaplaceno misto_odjezdu misto_navratu komentar

Varchar(3) Enum(‘yes’,’no’) Varchar(100) Varchar(100) Text

Not Null Not Null, VP(0) Null Null Null

Tabulka 6-24: Databázová tabulka objednavka_sluzby Tabulka jazyk eviduje typy jazyků, které lze v objednávkovém procesu využít. To znamená, kterými se klient může dorozumět s CA. Tuto tabulku využívá několik dalších tabulek. jazyk Název atributu id poradi

Datový typ Varchar(2) Int(2)

Omezení, upřesnění PK, Not Null Not Null

Tabulka 6-25: Databázová tabulka poradi Tabulka cms slouží pro ukládání tzv. článků, respektive textů, které by měly být přeloženy a budou se využívat v systému či na plánovaných webových stránkách. Datový typ primárního klíče je oproti ostatním typ Varchar s maximálním počtem 100 znaků, protože požadujeme, aby každý článek měl vlastní jednoznačný textový identifikátor. cms Název atributu id nadpis_fraze_id

Datový typ Varchar(100) Int(10)

text_fraze_id

Int(10)

typ

Enum(‚system‘,‘normal‘)

Omezení, upřesnění PK, Not Null Not REF(slovnik.fraze_id) Not REF(slovnik.fraze_id) Not Null, VP(normal)

Null, Null,

Tabulka 6-26: Databázová tabulka cms Tabulka email eviduje všechny odeslané emaily pomocí rezervačního systému. Opět se zde objevuje atribut „objednavka_id“, jehož reference závisí na atributu „typ_objednavky“. Atribut „timestamp“ je čas odeslání emailu. email Název atributu id email_odesilatele email_prijemce predmet zprava typ timestamp rezervace_id objednavka_id typ_objednavky

Datový typ Int(10) Varchar(100) Varchar(100) Text Text Varchar(50) Timestamp

Omezení, upřesnění PK, AI,Not Null Not Null Not Null Not Null Not Null Null Not Null, VP(CURRENT_TIMESTAMP) Null, REF(rezervace.id) Null Null

Int(10) Int(10) Enum(‘ubytovani’, ’sluzba’, ’preprava’) Tabulka 6-27: Databázová tabulka email 106


kurz Název atributu mena koeficient datum_platnosti

Datový typ Varchar(3) Double Date

Omezení, upřesnění PK, Not Null Not Null PK, Not Null

Tabulka 6-28: Databázová tabulka kurz

typ_logu Datový typ Int(11) Text

Název atributu id popis

Omezení, upřesnění PK, Not Null Not Null

Tabulka 6-29: Databázová tabulka typ_logu

log Název atributu id popis cas

Datový typ Int(11) Text Timestamp

uzivatel_id rezervace_id objednavka_id typ_objednavky

Int(10) Int(10) Int(10) Enum(‘ubytovani’, sluzba’, ’preprava’)

Omezení, upřesnění PK, AI, Not Null Not Null Not Null, VP(CURRENT_TIMESTAMP) Not Null, REF(uzivatel.id) Null, REF(rezervace.id) Null Null

Tabulka 6-30: Databázová tabulka log

5.2. Implementace případů užití Podle kapitoly 4.1 – Případy užití byla implementována většina případů užití. Vzhledem k časové náročnosti programování jsem musel v této práci vynechat funkce systému související s přepravou (případy užití UC043, UC044, UC045). U některých případů užití byly vynechány části týkající se přepravy. Tyto funkce budou dodatečně naprogramovány v nejbližším možném termínu, proto jsem popsal a vytvořil všechny související tabulky v databázovém systému. Navíc jsem naprogramoval několik pomocných funkcí, které nebyly v analýze popsány. Mezi ně lze počítat např. nastavení systému, do nějž patří správa kategorií ubytování, zemí, oblastí, měst a částí měst (správa obsahuje funkce pro přidání, editaci a mazání). 5.3. Vlastní implementace Implementaci lze rozdělit podle různých kriterií. Základní dělení bych popsal takto: • Tvorba vzhledu

107

KAPITOLA 5. IMPLEMENTACE Grafický návrh pomocí grafického editoru, jenž je poté využit při implementaci vzhledu aplikace. o Tvorba šablon. o Torba CSS stylů. Funkčnost sytému o Vytvoření základní kostry systému. o Tvorba šablon. o Tvorba funkčních skriptů ovládající jednotlivé části systému. o Tvorba objektů (tříd). o Tvorba tabulek v databázi. o Tvorba javascriptových funkcí. o

•

Vypsané části se při programování většinou překrývají a doplňují, ale lze je i implementovat jako samostatné části. 5.3.1. Postup implementace Z druhé kapitoly vyplývá, že pro implementaci využiji šablonovacího systému Smarty pro PHP. Jedná se vlastně o balík PHP skriptů, kterému vévodí skript Smarty.class.php, jenž implementuje třídu Smarty. Mimo tento soubor dále obsahuje soubory reprezentující defaultní funkce poskytované tímto systémem. V prvním kroku bylo důležité vytvořit základní kostru systému. Nejdříve jsem vytvořil kořenovou složku nazvanou „Mars“. Do této složky jsem zkopíroval Smarty PHP skripty, a to do podadresáře „libs“. Smarty ke své práci využívá tzv. pracovní adresáře – povinné jsou „templates“ (adresář obsahující šablony) a „templates_c“ (adresář obsahující zkompilované šablony). Pro přehlednost jsem také vytvořil adresáře pro kaskádové styly (adresář css), javascriptové funkce (adresář js), pro obrázky a grafiku (adresář img) a tzv. pluginy, což jsou PHP skripty, jejichž výstupy budou využívat šablony (adresář plugins).

Obrázek 5-2 : Základní adresářová struktura aplikace. Pomocí nástroje PhpMyAdmin, který slouží pro správu MySQL databází pomocí webového rozhraní, jsem vytvořil novou databázi nazvanou „mars“. Základním souborem je soubor „zpracuj.php“, který obsluhuje veškerý provoz systému a je jejím základním kamenem. Aby se nejdříve spouštěl tento skript, zaručuje upravený soubor

108

KAPITOLA 5. IMPLEMENTACE .htacces (speciální textový soubor sloužící pro úpravu chování serveru Apache). Tento soubor vypadá takto: RewriteEngine on DirectoryIndex start.html zpracuj.php // definuje soubory, které se mají zobrazit, pokud odkazujeme pouze na adresář, a ne na soubor RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /Mars/zpracuj.php [L] // vše je přesměrováno na soubor zpracuj.php Dalšími základními soubory jsou index.php (inicializuje používání smarty a zobrazuje požadovanou stránku) a ajax.php (slouží pro provedení ajaxových skriptů), které budou podrobněji popsány níže. Do základní struktury aplikace se také počítá návrh základní šablony (šablona index.tpl), která je spouštěna pokaždé při načítání aplikace (souborem index.php). Takto jsem vytvořil tzv. muster vzhledu vycházející z návrhu z kapitoly 4.3. V této fázi jsem používal grafického editoru a styl aplikace definoval v souboru default.css. Jakmile jsem dokončil tvorbu základního vzhledu a funkčnosti systému, pustil jsem se do implementace navržených případů užití. Postupoval jsem takto: 1. Analyzoval jsem případ užití a hledal příbuzné případy užití (např. případy užití týkající se správy uživatelů). 2. Pomocí programu PhpMyAdmin jsem vytvořil databázové tabulky související s případy užití (v mém příkladu tabulky uzivatel, uzivatelská_role, zeme, jazyk, slovnik). 3. Vytvořil jsem objekty (třídy) reprezentující jednotlivé tabulky. Tyto třídy jsou uloženy v adresáři „libs“. Každá třída obsahuje funkce spojené s daným objektem, které byly potřeba implementovat vzhledem k případům užití. 4. Vytvořil jsem základ šablony. 5. K téměř každé šabloně jsem implementoval tzv. plugin, tedy php skript, který provede nějaké příkazy, případně nalezne a zpracuje data z databáze. Tento skript se provede vždy na začátku šablony a jeho výstupem jsou určitá data, která se poté využijí uvnitř šablony. 6. Dokončil jsem šablonu s využitím výstupních hodnot pluginu. 7. U některých šablon jsem přidal javascriptové funkce.Nejvíce tam, kde se pracuje s formuláři. 8. Upravil jsem vzhled šablony pomocí kaskádových stylů. V průběhu práce jsem také navrhoval vzhled jednotlivých částí systému, které by se mohly opakovat (např. formuláře, nadpis stránky aj). Tyto návrhy jsem poté využíval u všech stránek, aby byla aplikace lépe pochopitelná a jednoduchá na používání.

5.4. Struktura aplikace, programové skripty 5.4.1. Základní soubory a objekty V této části uvedu základní soubory potřebné pro běh celé aplikace. U každého souboru naznačím jeho funkci, popřípadě popíši v něm obsažené funkce.

109

KAPITOLA 5. IMPLEMENTACE Soubor zpracuj.php je tzv. „spouštěcí soubor“ sytému (proběhne vždy jako první) a má tyto funkce: • Povoluje použití SESSIONS. • Obsahuje Funkci na zobrazení požadované stránky – viewPage($stranka,$parametry). • Funkce nejdříve spustí funkci na uložení parametrů z proměnné $parametry a $stranka do PHP globální proměnné $_REQUEST a poté vkládá do stránky soubor index.php . • Rozdělí URL adresu na části podle znaku „/“ (a uloží do pole) a takto rozdělenou adresu prochází cyklem, při němž testuje jednotlivé části adresy a rozhoduje se, jaká stránka by se měla zobrazit. Po nalezení spustí funkci na zobrazení požadované stránky. Soubor index.php obsahuje třídu Index, která je potomkem třídy Page (adresář „libs“, soubor Page.class.php). Třída Page obsahuje dvě proměnné - $params a $smarty a dvě funkce: • initPage() – inicializace Smarty třídy, uložení všech hodnot z proměnné $_REQUEST do proměnné $params. • display(nazev šablony) – zobrazení požadované šablony V souboru index.php je dále vytvoření instance třídy Index, spuštění funkce initPage() a display(„index.tpl“). Soubor index.tpl obsahuje základní HTML strukturu aplikace. Jednotlivé části jsou do této šablony vkládány pomocí smarty funkce „include“. Nejzajímavější je vkládání obsahové části. Pokud není uživatel přihlášen, vždy se v této části zobrazí šablona login.tpl určená pro přihlášení, jinak se zde zobrazí šablona s totožným názvem, který byl uveden ve skriptu zpracuj.php ve funkci viewPage jako první parametr $stranka. Na počátku šablony se nejdříve spustí tyto 2 pluginy a to pomocí smarty funkce „load_page_plugin“. Tato funkce má 3 parametry: • name – jméno pluginu, který se má spustit (pluginy jsou uloženy v adresáři „plugins“ ve tvaru „name.plugin.php“) • assign – název proměnné, pomocí níž lze přistoupit k výstupním proměnným pluginu. • input – vstupní proměnné V šabloně index.tpl se spouští tyto pluginy: • index_settings – základní skripty pro všechny stránky • login – zajišťuje přihlašování do systému a testování přihlášení Soubor Plugin.class.php obsahuje třídu Plugin, ze které poté dědí všechny pluginy. Tato třída slouží pro definice a deklaraci společných proměnných. A obsahuje funkce vhodné pro použití ve více pluginech: • InitPlugin(parametry) – Uloží do třídní proměnné $params hodnoty z lokální proměnné “parametry”. • &getClass(název třídy) – Vytvoří novou instanci požadované třídy z adresáře „libs“ a vrátí její odkaz. • controlEmailAddress(email) – Kontrola správného tvaru emailové adresy. • safetyString(hodnota) – Vrací upravenou hodnotu vstupní proměnné (odstraňuje prázdné znaky a převádí HMTL znaky).

110

KAPITOLA 5. IMPLEMENTACE 5.4.2. Objekty (třídy) Soubory s objekty obsahují třídy s objekty vytvořené podle konceptuálního modelu z kapitoly 4.2 a navíc další pomocné třídy pro běžný chod aplikace. Tyto soubory jsou uloženy v adresáři libs a mají vždy název ve tvaru „název objektu“.class.php. Funkce jednotlivých objektů nejsou implementovány podle přesných pravidel Objektově orientovaného programování, ale jsou přizpůsobené pro jednoduché použití se šablonovacím systémem Smarty. Většina funkcí přímo pracuje s databází, proto jsou všechny hodnoty vstupních parametrů ve všech funkcích všech objektů kontrolovány na výskyt nebezpečných znaků a nebezpečných řetězců (ochrana před napadením hackerem) pomocí funkce safety(hodnota) třídy Sql. Název objektu CastMesta Cenik Cms Jazyk Kategorie Kurz Log MainClass Město ObdobiSekce ObjednavkaSluzby ObjednavkaUbytovani Oblast Page Partner Platba Plugin Produkt ProduktObjednavky Rezervace SekceCeniku SezonaSluzby SimpleSql Slovnik Sluzba Sql TypPlatby TypPokoje Ubytovani Uzivatel Země

Význam a funkce objektu Část města, funkce pro správu částí měst Ceník, funkce pro správu ceníku ubytování CMS, funkce pro tvorbu článků Jazyk, funkce pro správu jazyků používaných v systému Kategorie ubytování, funkce pro správu kategorií Kurz měn, funkce pro zjištění kurzů a vrácení kurzů Log, funkce pro správu logů systému Základní třída pro Pluginy Město, funkce pro správu měst v oblastech Období Sekce Objednávky služeb pro rezervaci Objednávky ubytování pro rezervaci Oblast, funkce pro správu oblastí Page, inicializace Smarty Partner, funkce pro správu partnera Platba, funkce pro správu plateb Potomek objektu MainClass, základní inicializace všech pluginů Produkt, funkce pro správu typů pokojů k ubytování Produkt Objednávky, správa produktů k objednávce ubytování Rezervace, funkce pro správu rezervací Sekce ceníku, funkce pro správu sekcí ceníku Sezóna služby, funkce pro správu jednotlivých sezón služeb Třída je uložena v podadresáři SimpleSql, slouží pro práci s databází Slovník, funkce pro správu a manipulaci se slovníkem Služba, funkce pro správu služeb nabízených partnery Třída pro práci s databází, je potomkem třídy SimpleSql Typ platby, funkce pro správu druhů plateb Typ pokoje, funkce pro správu typů pokojů Ubytování, funkce pro správu ubytovacích zařízení Uživatel, funkce pro správu uživatelů Země, funkce pro správu zemí Tabulka 5-31: Seznam objektů aplikace

Jako příklad jednoho objektu uvedu objekt Rezervace. Třída Rezervace obsahuje proměnné a funkce. Proměnné této třídy jsou: identifikátor, uživatel, kontaktní jméno, kontaktní příjmení, kontaktní email, kontaktní firma, jméno na voucher, zaměstnanci, typ platby, čas vytvoření, měna platby, komentár, komentář klienta, typ, stav, aktuální kurzy CZK, USD a HUF. Mezi funkce této třídy patří: 111

KAPITOLA 5. IMPLEMENTACE • •

•

•

•

•

•

Rezervace() – konstruktor vytvorRezervaci(ukazatel na třídu Sql pro práci s databází (dále uvedu pouze $Sql), další parametry…) o Funkce pro přidání nové rezervace do databáze. o Vrací hodnotu identifikátoru nově přidané rezervace v případě úspěšného přidání, jinak vrací hodnotu false. o Veřejná funkce (k funkci lze přistupovat i mimo třídu). vratKontaktniUdaje($Sql, identifikátor rezervace) o Funkce vrátí všechny kontaktní údaje z tabulky rezervace pro rezervaci s uvedeným identifikátorem – hodnoty jsou vráceny v poli. o Veřejná funkce. upravKontaktniUdaje(&$Sql,identifikátor rezervace, jméno, příjmení, email, telefon, firma, jméno na voucher,jazyk) o Funkce upraví kontaktní údaje pro danou rezervaci. o Veřejná funkce. upravJedenParametrRezervace($Sql, identifikátor rezervace, parametr , hodnota parametru) o Funkce upraví hodnotu jednoho atributu pro danou rezervaci. o Veřejná funkce. vratRezervaci($Sql, identifikátor rezervace, jazyk) o Funkce vrátí všechny hodnoty z tabulky rezervace pro danou rezervaci + navíc do sebe inkluduje objekty ObjednavakaUbytovani, ObjednavkaSluzby a Platba. Tyto třídy využívá k nalezení objednávek ubytování, objednávek služeb a plateb pro danou rezervaci. Pokud tyto funkce vrátí nějaké hodnoty, přičlení je k již existujícímu poli s rezervací. o Veřejná funkce. vratSeznamRezervacíDleParametru($Sql, parametry v poli, jazyk, podmínka řazení, limit) o Funkce vrací seznam rezervací odpovídající zadaným parametrům. o Parametr limit je použit z důvodu stránkování. o Funkce na začátku využívá ještě třídní privátní funkci (funkce může být volaná pouze z vnitřku vlastní třídy) vytvorDozatProVyhledavani($Sql, parametry,jazyk), která vytvoří část SQL dotazu podle vstupních parametrů (konkrétně vytvoří podmínky WHERE a spojení tabulek JOIN). o Veřejná funkce.

5.4.3. Pluginy (řídící skripty) Pluginy jsou PHP skripty využívané šablonami. Tyto skripty jsou uloženy v adresáři plugins. Název souboru je složen takto: „jmeno_sablony“.plugin.php. Každý soubor obsahuje třídu nazvanou podle názvu jména šablony, která je potomkem objektu Plugin. Všechny tyto pluginy obsahují dvě základní funkce: • init() – Funkce pro vytvoření instancí objektů, které bude konkrétní plugin využívat. • run() – Vlastní skript, který je spuštěn ihned po funkci init(). Obsahuje prováděcí skripty. Příkladem uvedu plugin pro správu zemí countries.plugin.php. 112

KAPITOLA 5. IMPLEMENTACE Při spuštění tohoto pluginu se nejdříve vytvoří instance objektů Sql a Zeme. V závislosti na vstupu (např. odeslání nějaké formuláře) se provede zpracování vstupních hodnot a posléze se spustí některá z funkcí třídy Kategorie. Dále dochází ke zpracování vrácených výsledků u funkcí. Pokud není odeslán žádný formulář, pouze se spustí funkce objetu Kategorie pro vrácení seznamu všech kategorií ubytování. Nakonec se tento výsledek vloží do výstupní proměnné daného pluginu, aby se mohl využít i uvnitř šablony. Některé pluginy nemusí patřit k žádné šabloně, jsou to většinou globálně využívané pluginy např. novými smarty funkcemi. Objekt accommodation_form accommodation_pricelist accommodation_search ajax_res_order_change

V šabloně accommodation_form.tpl accommodation_pricelist.tpl accommodation_search.tpl ajax_res_order_change.tpl

Categories cms_add

settings_category.tpl cms_add.tpl

cms_list

cms.tpl

Countries if_rights

settings_countries.tpl -

index_settings

index.tpl

Login

index.tpl

Oblasti partner_form res_add_accommodation res_add_order_product

settings_oblast.tpl partners.tpl res_add_accommodation.tpl res_add_order_product.tpl

res_edit_user

res_edit_user.tpl

res_choose_user

res_choose_user.tpl

res_payment_form res_service_form Reservation

res_payment_form.tpl

reservation_accommodation reservation_client

reservation_accommodation. tpl reservation_client.tpl

reservation_payment

reservation_payment.tpl

reservation_service

reservation_service.tpl

reservation_sum

reservation_sum.tpl

reservation.tpl

113

Význam a funkce Správa ubytování Správa ceníku pro ubytování Vyhledávání ubytování Změna stavu objednávky rezervace Správa kategorií ubytování Vložení článku do cms a slovníku Zobrazení seznamu článků z cms Správa zemí Informace o přihlášeném uživateli pro smarty funkci „if_rights“ Hlavní plugin, základní nastavení Přihlášení, odhlášení, testování přihlášení uživatele Správa oblastí zemí Správa partnerů Správa ubytování k rezervaci Správa produktů objednávky ubytování Správa kontaktních údajů uživatele v rezervaci Nalezení a přidání uživatele k rezervaci Správa plateb k rezervaci Správa služeb k rezervaci Nalezení všech informací o rezervaci, výpočet finálních plateb za objednávky Získání informací o ubytování k rezervaci Získání informací o klientovi k rezervaci Získání informací o platbách k rezervaci Získání informací o službách k rezervaci Výpočet platebního sumáře – kolik je třeba zaplatit, kolik je zaplaceno,…

KAPITOLA 5. IMPLEMENTACE reservations

reservations.tpl

reservations_search service_form services towns towns_part user user_add users

reservations_search.tpl service_form.tpl services.tpl settings_towns.tpl settings_towns_part.tpl user.tpl user_add.tpl users.tpl

Získání seznamu rezervací dle parametrů Vyhledávání v rezervacích Správa služby Seznam služeb Správa měst Správa částí města Správa uživatele Přidání uživatele Seznam a vyhledávání uživatelů

Tabulka 5-32: Seznam pluginů 5.4.4. Šablony (smarty šablony) Smarty šablony umožňují vládat do HTML kódu speciální znaky a příkazy a tímto je dosaženo oddělení prezentace dat od aplikační logiky. Šablony tedy slouží právě pro prezentaci dat, která jsou získána z nějakého pluginu. Zobrazená stránka se většinou skládá z více šablon. V mém případě je každá stránka složena minimálně z těchto šablon: html_head.tpl (šablona pro definici hlavičky dokumentu), main_top.tpl (horní část stránky – shodná pro všechny stránky), main_menu_left.tpl (levé menu), html_bottom.tpl (ukončení dokumentu – tzv. patička) a jako poslední se vkládá šablona s proměnným obsahem. Šablona accommodation_form.tpl accommodation_pricelist.tpl

Význam Přidání ubytování, informace o ubytování Správa produktů, sekcí, sezon a ceníků pro ubytování Vyhledávání ubytování Zobrazení ajax funkcí Změna stavu objednávky u rezervace Seznam cms frází Přidání a editace cms článku Zobrazení nápovědy – pomocí jQuery a Ajax Patička HTML dokumentu Hlavička HTML dokumentu Zobrazení požadované šablony v novém okně Základní šablona – tvoří strukturu aplikace Přihlášení do systému Úvodní stránka Patička stránky Horní část stránky Levé menu Správa partnerů Přidání a editace ubytování k rezervaci Přidání a editace produktů k objednávce ubytování Úprava kontaktních údajů k rezervaci Vyhledání a vybrání uživatele k rezervaci Přidání a editace platby k rezervaci Základní šablona pro zobrazení informací o rezervaci Informace o ubytování v rezervaci Vytvoření nové rezervace

accommodation_search.tpl ajax_page.tpl ajax_res_order_change.tpl cms.tpl cms_add.tpl help.tpl html_bottom.tpl html_head.tpl inc_show_page.tpl index.tpl login.tpl main.tpl main_bottom.tpl main_top.tpl menu_left.tpl partners.tpl res_add_accommodation.tpl res_add_order_product.tpl res_edit_user.tpl res_choose_user.tpl res_payment_form.tpl reservation.tpl reservation_accommodation.tpl reservation_add.tpl 114

KAPITOLA 5. IMPLEMENTACE reservation_client.tpl reservation_payment.tpl reservation_service.tpl reservation_sum.tpl reservations.tpl reservations_search.tpl service_form.tpl services.tpl settings.tpl settings_category.tpl settings_countries.tpl settings_oblast.tpl settings_towns.tpl settings_towns_part.tpl show_page.tpl

Informace o klientovi v rezervaci Informace o platbách v rezervaci Informace o službách v rezervaci Sumář informací rezervace Seznam rezervací Vyhledávání rezervací Správa služby Seznam a vyhledáván í služeb Hlavní stránka nastavení systému Správa kategorií Správa zemí Správa oblastí Správa měst Správa částí měst Hlavička a patička pro zobrazení šablony v novém okně Informace o uživateli Přidání a editace uživatele Seznam a vyhledávání uživatelů

user.tpl user_add.tpl users.tpl

Tabulka 5-33: Seznam šablon 5.4.5. Soubory s Javascript Soubory s javascriptovými funkcemi jsou uloženy v adresáři js. Pro snazší využití možností javascriptu jsem se rozhodl využít Javascriptového Frameworku jQuery [9], který umožňuje snadnější přístup k DOM elementům a je velmi dobře zdokumentován. Některé jednoduché javascriptové funkce jsem umístil přímo do kódu šablony. V adresáři se nacházejí tyto soubory: • •

jquery.js – Soubor pro práci s jQuery Frameworkem. mars.js – Běžné funkce pro využití v různých částech aplikace o Obsahuje funkce pro skrývání a zobrazování HTML elementů, skrývání více elementů najednou podle názvu třídy, otevření nějaké šablony v novém okně.

•

users.js – Funkce pro změnu formuláře při změně uživatelské role.

Uvnitř šablon se nachází funkce pro kontrolu stisknutí tlačítka DELETE a další. 5.4.6. Nové Smarty funkce V průběhu implementace jsem v některých částech zjistil, že mi nevyhovuje sada vestavěných Smarty funkcí. Výhoda Smarty je i v tom, že je velmi snadné vytvořit si funkce vlastní. Proto jsem přidal k již existujícím funkcím umístěných ve složce libs/Smarty/plugins/ tyto: block.if_rights (soubor block.if_rights.php ) Jedná se o tzv. blokovou funkci. Využije se v případě, že je některý obsah aplikace určený pouze pro určité konkrétní uživatelské role. Cokoliv, co je umístěno ve zdrojovém kódu mezi tagy {if_rights rights="admin|manazer" } a {/if_rights}, je viděno v tomto případě pouze uživateli s rolemi Administrátor a Manažer. 115

KAPITOLA 5. IMPLEMENTACE function.load_page_plugin (soubor function.load_page_plugin.php ) Funkce sloužící pro spuštění určitého pluginu v šabloně. function.bad_value (soubor function.bad_value.php ) Funkce zobrazí na místě jejím spuštění ikonu s vykřičníkem. function.help. (soubor function.help.php ) Funkce zobrazí na místě jejím spuštění ikonu s otazníkem.

116

KAPITOLA 6. TESTOVÁNÍ

6 Testování 6.1. Testování uživatelského rozhraní Testování uživatelského rozhraní probíhalo již od počátku analýzy návrhu. Nejdříve jsem se zadavatelem konzultoval jeho přibližnou představu o vzhledu vyvíjené aplikace, zejména co se týká umístění základních prvků a barev. Z tohoto sezení vznikl papírový prototyp, jenž spojoval jeho představu s mojí spolu se zachováním pravidel použitelnosti. Tento prototyp byl předveden zadavateli, který v této fázi s návrhem souhlasil. V další fázi vývoje jsem připravil grafický návrh vzhledu systému pomocí grafického editoru. Tento návrh se už velmi blížil výsledné podobě systému ve webovém prohlížeči. Zadavateli jsem donesl 2 návrhy s různým barevným provedením. Zadavatel si vybral ten, který je uváděn v této práci, s tím, že došlo k určitým korekcím barev odkazů a vzhledu nadpisů všech stránek. Při implementaci vzhledu aplikace jsem postupoval přesně dle grafického návrhu. Jakmile jsem naprogramoval základní grafiku aplikace, opět jsem se sešel se zadavatelem, aby posoudil podobu systému v pohybu, kdy dochází ke změnám barev při najetí na odkazy atd. Jemu se konečný návrh líbil, ale požádal o změnu typu písma menu odrážek a na základě jeho dalších připomínek došlo k úpravě vzhledu formulářů a částečné změně vzhledu stránky s rezervací (odsazení jednotlivých sekcí, velikost písma, umístění jednotlivých informací na stránce). Další testování uživatelského rozhraní proběhlo v rámci testování použitelnosti viz kapitola 6.4.

6.2. Testování aplikace jako celku Testování systému jako celku započalo ihned po dokončení vývoje jednotlivých částí systému (případů užití a dalších potřebných funkcí) [12]. Vzhledem k časové tísni byl proveden tento test pouze vývojářem (tedy mnou) a ne přímo zadavatelem z důvodu brzkého termínu odevzdání této práce. Tento test je však naplánován na začátek února 2010. Testování vývojářem Testování pobíhalo na mém osobním počítači s touto konfigurací: • Notebook s úhlopříčkou 12“ • Procesor IntelCentrino2, 2.26 GHz • Paměť 4GB • Rozlišení obrazovky 1280 x 800 px • Webový prohlížeč Internet Explorer 7 Testování probíhalo na základě procházení jednotlivých naimplementovaných případů užití. U každého případu se testovalo několik parametrů chování systému. V této fázi jsem vynechal testování funkčnosti a návrhu rozhraní vzhledem k různým typům webových prohlížečů, protože budu testovat pouze určité části aplikace. Úkolem tohoto testování bylo zjistit závažné chyby v chování aplikace, nalézt chybně nebo vůbec nenaprogramované části případů užití, nalézt jednoznačné chyby oproti pravidlům použitelnosti. Při testování jsem sledoval zejména tyto parametry: 117

KAPITOLA 6. TESTOVÁNÍ 1. Zda jsem dokázal začít s případem užití a jestli bylo jednoduché dostat se v systému k tomuto případu užití. 2. Povedlo se splnit cíl. Alternativní scénář proběhl dle popisu. 3. Během jednotlivých částí případu užití nedošlo k neočekávané události, která nebyla ošetřena. Správné pořadí kroků dle popisu případu užití. Vždy bylo pochopitelné, co se stalo po vzniku nějaké události (stisknutí odkazu či tlačítka). 4. Po zpracování nějakého formuláře jsem byl informován systémem o proběhnutí či chybě. 5. Stránka měla správně nadpis a navigaci. 6. Odkaz příslušné stránky v menu byl příslušně označen. 7. Informace na stránce byly čitelné. 8. Odkazy na jednotlivých stránkách vedou na správnou stránku či vykonávají správnou funkci. 9. Po stisknutí tlačítka DELETE se systém vždy zeptá, zda opravdu chceme odstranit záznam. 10. Formuláře jsou správně popsány a jsou označeny povinné položky. 11. Po vyplnění a odeslání formuláře: a. Při neúplném vyplnění formuláře zůstanou všechny položky vyplněné tak, jak je vyplnil uživatel. Uživatel je informován o chybách. b. Položky byly správně uloženy v databázi. 12. Nedošlo k jiným problémům či k žádnému jinému zjištění nějaké anomálie systému. Následující tabulka popisuje výsledky testování pro jednotlivé případy užití. V tabulce je uveden případ užití, výsledek pro každý bod testu (T = správně, F = chyba, 0 = v tomto případě nemá smysl testovat). Pokud se vyskytl nějaký problém v případu užití, je popsán pod tabulkou. Případ užití UC001 UC002 UC004 UC005 UC006 UC007 UC008 UC009 UC011 UC012 UC013 UC014 UC015 UC016 UC018 UC019 UC020 UC021

1 T T T T T T T T T T T T T T T T T T

2 F T T T T T T T T T T T F T T F T T

3 T T T T F T T T T T T T T T T F T F

4 T 0 F F F 0 0 0 T F T 0 T T T T F F

118

5 T 0 T T 0 T T T T T 0 T T T T T T T

6 T 0 T T T F T T T T T T T T F F F F

7 T T T T T T T T T T T T T T T T T T

8 T 0 T T T T 0 T T 0 0 T T T 0 0 0 0

9 0 0 0 0 F 0 0 F 0 0 T 0 0 0 0 0 T 0

10 0 0 T T T 0 T 0 T T 0 0 T 0 T T T T

11 T 0 T T T 0 T 0 T T 0 0 0 0 F T T T

12 T T 0 F F F T F T T F T F T T T T F


UC022 UC023 UC027 UC028 UC030 UC031 UC032 UC033 UC034 UC035 UC036 UC037 UC038 UC040 UC041 UC042 UC046 UC047 UC048 UC049 UC050 UC051 UC052 UC053 UC054 UC055 UC056 UC057 UC058 UC059 UC060 UC061 UC062

1 T T T T T T T T T T T T T

T T T T T T T T T T T T T T T T

2 3 4 5 6 7 8 9 10 11 T T T T T T T 0 T T T T F T F T 0 T T T T T F T F T 0 0 T T T T 0 T F T 0 0 0 0 T T 0 T T T 0 0 0 T T T T T T T 0 0 T T F T T T T T 0 0 T T T T T T T T 0 T 0 0 T T T T T T 0 0 F F T T T T T T 0 0 T T T T F T T T 0 0 F T T T F T T T 0 F T T T T 0 0 0 T 0 0 T T v době testování nebyl tento případ užití naimplementován v době testování nebyl tento případ užití naimplementován v době testování nebyl tento případ užití naimplementován T T T T 0 T T T T T T F F T 0 T 0 0 F F F F F T 0 T 0 0 F F T T T T 0 T 0 T 0 T T T 0 T T T T 0 T 0 T T 0 T F T T 0 0 0 T T T T T T T 0 T 0 T T T T F T 0 0 T T T T 0 T T T T 0 0 0 T T 0 T T T T 0 0 0 T T F T T T 0 0 T T T T T T T T 0 0 F T T T 0 T T T T 0 0 0 v době testování nebyl tento případ užití naimplementován T T 0 T T T T 0 0 0 T T T T F T T 0 T T T T T T T T 0 T 0 0 Tabulka 6-1: Testování aplikace jako celku.

Vyhodnocení • • •

UC001 o UC004 o UC005 o o

2 - 3x špatně zadané heslo nezablokovalo účet. 4 – Systém neinformoval uživatele o přidání. 4 – Systém neinformoval uživatele o editaci údajů. 12 – Chybí odkaz na návrat na předchozí stránku na stránce editace údajů. 119

12 T T T F T F T T F F F F T

T T T T T T F T T T T T T T T T

KAPITOLA 6. TESTOVÁNÍ •

•

UC006 o 3,9 – Po stisknutí tlačítka Delete se systém nezeptal uživatele, ale rovnou ho odstranil. o 4 – Po smazání nebyl uživatel informován o úspěšném provedení požadavku. UC007 o o

•

•

• •

•

•

• •

• •

• •

6 - V menu nebyl označen žádný odkaz. 12 – Na stránce s údaji o klientovi se u všech typu rolí zobrazovaly kontaktní údaje, ale u všech rolí kromě klienta jsou tyto údaje vždy prázdné, proto je nemá cenu zobrazovat.

UC009 o 9 – Po stisknutí odkazu se systém nezeptá, zda opravdu odstranit uživatele, ale přímo ho odstraní. o 12 – Zobrazují se i odstranění uživatelé (označení „junk“). UC012 o 4 – Po stisknutí tlačítka „ulož“ nebyl uživatel informován o provedení příkazu (formulář byl již ale vyplněn dle správných hodnot). UC013 o 12 – Odstraněné ubytování se i po smazání zobrazuje v seznamu ubytování. UC015 o 2 – Nefungovalo vyhledávání podle parametru „kategorie ubytování“. o 12 – Málo parametrů, podle kterých lze vyhledávat. UC018 o 6 – Není označen žádný odkaz v levém menu (zřejmě nikde, kde se pracuje na stránce s ceníkem). o 11 – Při neúplném vyplnění formuláře systém nedrží vyplněné hodnoty. UC019 o 2,3 - Buď se nezobrazuje komentář k produktu, nebo se neukládá do databáze. Jinak zbytek proběhne v pořádku. UC020 o 4 -Box s informací o odstranění produktu vyskočil, ale chyběl text. UC021 o 4 - Box s informací o přidání sekce vyskočil, ale chyběl text. o 3 – Nekontrolují se data, i když jsem nevyplnil žádné datum, přesto došlo k přidání sekce. o 12 – Typ sekce ceníku a komentář se nezobrazuje u výpisu jednotlivých sekcí. UC022 o 4 -Box s informací o odstranění sekce vyskočil, ale chyběl text. UC027 o 4 – Systém vůbec neinformoval o změně údajů, či o případné chybě, když jsem zadal špatný údaj, a nedošlo k uložení části ceníku. UC028 o 12 -U sekcí ceníku nejsou informace o typu a chybí komentář k sekci. UC031 o 12 - Na stránce vložení klienta k rezervaci, hned jak se otevře nové okno, je dole informace „Počet nalezených klientů:“, která tam má být až po vyhledání uživatelů.

120

KAPITOLA 6. TESTOVÁNÍ o o

• •

•

•

•

•

•

• • • • •

12 – Pokud systém nenalezl žádného klienta odpovídajícího zadaným údajům, tak je tam opět vypsaná špatná hláška. Alternativní scénář předpokládal přidání nového klienta přímo v otevřeném okně, což jsem nakonec neimplementoval, jelikož má uživatel jinou možnost přidat nového klienta.

UC032 o Neukládá se položka „jazyk“. UC034 o 10 – Nejsou označeny povinné položky o 11,12 – Systém uloží objednávku, i pokud nejsou vyplněné žádné údaje! Není kontrola zadávaných údajů. UC035 o 12 – Po stisku tlačítka neinformuje systém uživatele o stavu provedení akce. Pokud je zadaná hodnota počtu pokojů < 1, správně se produkt neuloží, ale ani systém nehlásí chybu. o 12 – Na stránce s rezervací se nevypisuje komentář k produktu a počet produktů. UC036 o 12 – Systém umožní uložit hodnotu počet produktů menší než 1, dále systém umožní uložit záporné hodnoty u cen. UC037 o 4 – Systém neinformuje uživatele o odstranění produktu (mohl by být problém při větším počtu produktů) o 9 – Systém se nezeptá uživatele, zda chce opravdu smazat záznam, po stisknutí tlačítka „Odstraň“, ale rovnou produkt odstraní. UC047 o 12 – V novém okně chybí tlačítko zavřít. o 3, 11 – Pokud nejsou vyplněny všechny povinné údaje, tak se nic nestane, ale ani se nezobrazí hláška o chybě. o 10 – Nejsou označeny povinné položky. UC048 o Editace služby není funkční, po stisknutí tlačítka „ulož“ se nic neděje, systém nehlásí žádné chyby, ale k uložení změn nedojde. o Nejsou označené povinné položky. UC051 o 6 – V levém menu není označena ani jedna položka. UC052 o Chybí vyskakovací kalendáře u položek s daty. UC053 o 6 – V levém menu není označena ani jedna položka. UC056 o 4 – Po uložení informací se nezobrazilo okno informující o provedení akce. UC057 o 10 – U jedné povinné položky chybělo označení hvězdičkou.

121

KAPITOLA 6. TESTOVÁNÍ V tabulce s přehledem nejsou uvedeny případy užití, které buď nebyly v době testování naimplementovány, nebo takové, pro které nemělo testování smysl. Poté, co budou ty případy užití implementovány, budou stejným způsobem otestovány. Kromě případů užití jsem testoval i další funkce systému, které nebyly popsány v případech užití. U těchto funkcí jsem nalezl několik podobných chyb, které jsem zjistil u testování případů užití. Vyhodnocení testování vývojářem Při testu bylo nalezeno větší množství drobných chyb, které však nebude těžké opravit. Několikrát se objevil závažnější problém, jenž bude potřebovat k vyřešení více času (např. některé části případů užití nebyly správně naimplementovány, v několika formulářích nedochází ke kontrole zadávaných údajů aj.). Nalezení chyb jsem předpokládal zejména vzhledem k časové tísni při implementaci. Rozsah takového projektu by si zasloužil více času na implementaci, než je dáno dobou pro práci na diplomové práci. Tyto chyby jsem již buď opravil, nebo budou v nejbližší době opraveny, tak aby nevadily při testování použitelnosti systému.

6.3. Testování přístupnosti Testování přístupnosti systému bylo testováno podle popsaných pravidel v kapitole 4.3.2.2 (zásadní pravidla přístupnosti pro systém CA). Po dohodě se zadavatel jsme vyloučili používání webového prohlížeče IE6, který by při použití nových CSS funkcí mohl zásadně ovlivňovat vzhled oproti ostatním prohlížečům a také pomalu spolupracuje s javascriptovým frameworkem jQuery, který aplikace využívá. 6.3.1. Testování přístupnosti Pro testování přístupnosti jsem si zvolil webový prohlížeč Mozilla Firefox 3.5.5. Pro tento typ prohlížeče existuje přídavná aplikace Web Developer (verze 1.1.8), která je určena pro vývojáře webových aplikací a obsahuje mnoho užitečných funkcí jako např. možnost vypnout javascript, možnost vypnout obrázky, zakázat používání css stylů aj. Testování probíhalo tak, že jsem si nejdříve sumarizoval všechna pravidla, která by měl systém splňovat, a poté jsem začal pro každé pravidlo procházet stránky systému, kde by se mohl vyskytnout nějaký problém. Ve vyhodnocení uvedu pouze nalezené problémy s přístupností, případně u některých pravidel popíšu postup kontroly. Vyhodnocení Pravidlo: Barvy pozadí a popředí by měly být vůči sobě dostatečně kontrastní. Testování: Pomocí programu na stránce http://www.sovavsiti.cz/kontrast/. Doporučená hodnota pro rozdíl barvy = minimálně 500 (rozdíl barev je uveden hodnotou od 0 do 756, rozdíl jasu 0 až 255), doporučená hodnota pro rozdíl jasu = minimálně 150. Výsledek:

122

KAPITOLA 6. TESTOVÁNÍ Co

Barva pozadí Levé hlavní menu, text #414C8C Tabulky, formuláře #FFFFFF Levé menu a označené žluté #414C8C odkazy Hlavička tabulek, rezervace – #CCCCFF hlavičky tabulek, rezervace – nová okna Obsahové menu – základní #78AFE barva a černé písmo

Barva písma #FFFFFF #000000 #FFCC20

Rozdíl barev 484 765 426

Rozdíl jasu 175 255 120

#000000

663

210

#000000

511

145

Tabulka 6-2: Kontrola kontrastu pozadí a popředí aplikace. Rozdíl barev nesplňují podklad levého menu s textem a podklad levého menu s označenými odkazy. V prvním případě se jedná o těsné nesplnění doporučené hodnoty, což může navíc vyvážit vysoký rozdíl jasu. Až uživatelské testování ukáže, zda by to mohlo dělat větší problémy. V druhém případě byly zaznamenány větší odchylky od doporučených hodnot rozdílu barev i jasu. Na druhou stranu se jedná pouze o odlišení označených odkazů od ostatních. V tomto případě také nebudu měnit barevné schéma. Oba dva případy budou otestovány při testování použitelnosti. Pravidlo: Stránka musí sdělovat informace jednoduchým jazykem a srozumitelnou formou. Možné problémy s nepochopením by měla řešit nápověda. Vyhodnocení: U problematických stránek se objevuje nápověda. Navíc je text většinou jednoduchý, skládající se pouze z několika slov, používaných při práci v cestovním ruchu. Pravidlo: Rozsáhlé obsahové bloky by se měly dělit do menších, výstižně nadepsaných částí. Testování: Procházel jsem stránky, které sdělují více informací (např. přidání nového ubytování, stránka s rezervací, stránka s ceníkem ubytování) a kontroloval rozdělení do logických bloků. Vyhodnocení: Všechny kontrolované stránky jsou vhodně rozdělené do logických bloků. Pravidlo: Každá stránka musí obsahovat odkaz vyšší úroveň v hierarchii stránek a odkaz na hlavní stránku. Vyhodnocení: Všechny stránky obsahují drobečkovou navigaci, ale neexistují odkazy na vyšší úroveň v hierarchii stránek. Z každé stránky existuje odkaz na hlavní stránku. Pravidlo: V případě, že uživatel učinil chybu při vyplňování formuláře, musí dostat informaci o tom, která položka byla špatně vyplněna a případně i informaci, jak tuto chybu odstranit. Vyhodnocení: 123

KAPITOLA 6. TESTOVÁNÍ Z testování aplikace jako celku vyplývá, že pouze v některých částech aplikace není toto pravidlo splněno. K nápravě dojde při opravování aplikace dle vyhodnocení testování aplikace jako celku. 6.3.2. Testování přístupnosti vzhledem k typu používaného prohlížeče V této části testování jsem se zejména zaměřil na kontrolu korektního zobrazování jednotlivých částí aplikace v různých typech webových prohlížečů. Pro každý prohlížeč jsem dále testoval, zda se neztrácí obsah při zvětšení o 100% a zdali zůstala zachovaná struktura obsahu webu při různých rozlišeních obrazovky. Systém jsem testoval v těchto prohlížečích: Mozilla Firefox 3.5.5, Internet Explorer 7, Opera 10, Google Chrome. Testování zvětšování písma pomocí standardních funkcí prohlížeče Při změnách velikosti stránky a velikosti písma byl u všech prohlížečů zachován korektní vzhled aplikace. Jediný problém by mohl nastat se staršími prohlížeči Internetu Explorer, který jsme však se zadavatelem předem vyloučili jako nepoužívaný. Testování různých rozlišení obrazovky Aplikace si při různých nastaveních rozlišení obrazovky či velikosti okna zachovala původní vzhled ve všech typech prohlížečů, a to díky fixně nastavené šířce hlavního obsahového elementu (nastaven na 1000px). Testování anomálií vzhledu aplikace Při implementaci jsem využíval pouze prohlížeč IE7 a částečně také Mozzillu Firefox 3.5.5, proto z testování vynechám prohlížeč IE7. U všech 3 typů se objevil problém se zarovnáním obsahu úvodní přihlašovací stránky a stránky pro přidání nové rezervace. U Opery se objevil problém s velikostí textu, kdy byla velikost oproti ostatním prohlížečům menší a případně by některým uživatelů mohla činit problémy. U přidání platby k rezervaci došlo při změně hodnoty „Kategorie“ k nesprávnému odsazení položky, která se zobrazuje až po zvolení konkrétní kategorie. Testování přístupnosti dopadlo velmi dobře, nebyla nalezena žádná kritická či velmi závažná chyba. Nalezené problémy půjdou lehce opravit.

6.4. Testování použitelnosti 6.4.1. Pravidla a cíl testování Co je to použitelnost již bylo popsáno v kapitole 4.3.1. Z tohoto popisu vyplývají důvody, proč testovat aplikaci na použitelnost. Jedním z důležitých aspektů je, aby uživatel mohl se systémem pracovat co nejrychleji a nejjednodušeji pro dosažení kýženého cíle. Dále lze také tímto testováním odhalit další chyby, na které se nepřišlo během testování programátorem. Základem testování použitelnosti je dobře navržený scénář vzhledem ke konkrétní aplikaci a jejím budoucím uživatelů. Minimální počet osob pro vyhodnocení testu je přibližně 5, ale čím větší číslo, tím více se lze o problémech systému dozvědět. Scénář obsahuje několik 124

KAPITOLA 6. TESTOVÁNÍ úkolů, které by měli testovaní jedinci splnit. Při provádění jednotlivých úkolů jsou pečlivě zaznamenávány uživatelovy reakce, úspěchy a klopýtnutí. V prvním kroku je důležité nalézt cílovou skupinu testerů, kteří budou přibližně odpovídat budoucím opravdovým uživatelům. V druhé fázi se musí vytvořit vlastní scénář testování. Při testování našeho systému se zaměřím na nejvíce využívané funkce systému a to funkce pro uživatele s rolí „prodejce“. U manažerů se předpokládá, že mají vyšší odbornou znalost práce s počítačem s déle trvajícím pracovním úvazkem, nežli prodejci. Proto z testu vynechám funkce pro správu uživatelů, cms a nastavení systému a naopak se více zaměřím na správu rezervací a ubytování. 6.4.2. Výběr testerů 6.4.2.1 Předpoklady a požadavky na uživatele Jak již bylo zmíněno v předchozí části, testování se zaměří na funkce pro běžného zaměstnance společnosti, který má na starosti prodej ubytování. Pro testování bude předpokládat uživatelovu základní znalost práce s počítačem a internetem (nebudeme předpokládat dokonalého uživatele, ale ani žádného počítačového analfabeta). 6.4.2.2 Předtestový dotazník a výběr vhodných kandidátů Vzhledem k tomu, že tento projekt vzniká jako diplomová práce a má velmi omezený rozpočet a čas na zpracování, nelze splnit ani základní aspekt testování – min. počet testerů. Proto jsem oslovil pouze členy rodiny a blízké známé o pomoc při testování systému, k čemuž svolili 3 z nich. Tento počet zřejmě povede k tomu, že nebudou odstraněny všechny chyby a problémy s použitelností. Po dohodě se zadavatelem proběhne kvalitnější a tím také průkaznější testování během dalšího vývoje. I přesto, že jsem si nemohl vybrat ze skupiny lidí potřebný vzorek testerů, jsem vytvořil předtestový dotazník, který poté využiji při zhodnocení testování. Viz. příloha B.1. Testující

Č. 1 Č. 2 Č. 3

Otázka č. Otázka č. Otázka č. 3 Otázka č. Otázka č. Otázka č. 1 2 4 5 6 Používání Zdravotní Zkušenosti Používání Zkušenosti rezerv. problémy, Věk s webovým PC s PC systému jiné prohlížečem 19-25 Expert Expertní > 3h denně Ano Ne 19-25 Průměrné Vysoké > 3h denně Ne Ne 46-55 Základní Základní 1x Denně Ne Brýle

Tabulka 6-3: Vybraní testující pro testování použitelnosti a odpovědi na otázky v předtestovém dotazníku.

6.4.3. Nastavení testu Ani tato část nebude odpovídat profesionálním podmínkám. Testování bude probíhat v místě bydliště testujícího. Testovací počítač bude můj vlastní notebook s úhlopříčkou 12,1 a 125

KAPITOLA 6. TESTOVÁNÍ systémem Windows Vista. Uživatelé budou moci při práci využívat svůj oblíbeny webový prohlížeč. Práce uživatele s aplikací bude zaznamenávána pomocí diktafonu a snímaní plochy obrazovky. 6.4.4. Úkoly a vlastní testování Testovaný uživatel se usadil k počítači, kde měl otevřen oblíbený prohlížeč již se spuštěnou aplikací. Uživatel dostal papír s úkoly, které by měl splnit, a s přihlašovacími údaji do systému. Tyto úkoly byly poskládány v logickém sledu, tak jak by se mělo se systémem pracovat. Úkol č. 1 Přihlaste se do systému. Přidejte do systému nový 4* hotel s názvem Hiltonos, který se nachází v Praze, na Novém Městě. Tento hotel nabízí 55 pokojů, na pokojích je koupelna, klimatizace a trezor. K hotelu také zadejte GPS souřadnice lat. 45°22’33‘‘ len. 45°22’33‘‘. Ostatní povinné údaje vyplňte dle libosti. Po přidání hotelu chcete ještě vyhledat všechny 4* hotely, které jsou uloženy v systému. Vyhledejte je. Doplňkové otázky během plnění úkolu • Víte, k čemu jsou na stránce otazníčky? • V jako formátu zadáte GPS souřadnice? • Dělalo Vám problémy nalézt nějakou stránku, která byla po vás požadovaná ke splnění úkolu? • Pokud jste vyplnil (a) nějakou položku špatně, pomohl Vám systém s vyplněním hodnoty? Úkol č. 2 Emailem Vám přišel dotaz od klienta, který by se chtěl ubytovat v hotelu Aparthotel Lužická, ale nejdříve by potřeboval znát cenu za 2 lůžkový pokoj v období od 15. 12. 2009 – 18. 12. 2009. Zjistěte tuto cenu. Úkol č. 3 Do společnosti přišel nový zákazník a chtěl by si objednat ubytování v Aparthotelu Lužická v termínu od 18.12.2009 do 23.12.2009. Přidejte nového klienta do systému. Poté pro tohoto klienta vytvořte novou rezervaci s objednávkou na dané ubytování a 2 lůžkový pokoj. Od hotelu jste obdrželi informaci, že mají prázdný pokoj, a dostali jste opci do 17.12.2009. Nastavte opci u objednávky. Nastavte objednávku na předrezervaci. Nevyhovuje Vám ale brutto cena za noc, zvyšte ji o 10 EUR. Klient se rozhodl zaplatit ihned, proto přidejte platbu za toto ubytování k rezervaci a nastavte stav objednávky na FIX. Klient objednává ubytování pro paní Martu Novou, proto toto jméno uveďte jako jméno na voucher. Doplňkové otázky během plnění úkolu • Jaký je zisk společnosti z této objednávky? • Kde všude se uvádí zisky? Úkol č. 4

126

KAPITOLA 6. TESTOVÁNÍ Vyhledejte rezervace pro pana Jiřího Nováka. Pan Novák si přeje prodloužit pobyt o další dva dny v prosinci 2009 u Aparthotelu Lužická a přeje si navýšit počet pokojů na 2. Změňte proto data tak, jak si přeje pan Novák. Zjistěte, kolik ho bude stát tento pobyt. Úkol č. 5 Vyhledejte všechny rezervace, jejichž objednávky ubytování jsou na tato data: příjezd nejdříve 1. 12. 2009, odjezd nejdéle 20. 12. 2009. 6.4.5. Výsledky testování Úkol č. 1 1.a) 1.b)

1.c)

1.d)

1.e)

Všichni testující se dokázali úspěšně přihlásit do systému. Testující č. 2 měl problém s nalezením odkazu pro přidání nového ubytování, což bylo zřejmě způsobeno nedostatečným prvotním prozkoumáním systému. Po nápovědě však odkaz nakonec nalezl. Všem testujícím se zdál být formulář přehledný a jednotlivá pole výstižná. Všichni také věděli, k čemu slouží ikony s otazníkem. Žádný testující nevěděl ihned, jak zadat souřadnice GPS. Oba by ale využili nápovědy. Uživatel č. 1 by navrhoval rozdělit zadávání do dvou polí. Všichni testující úkol nakonec splnili. Testující č. 3 nevěděl, jestli po stisknutí tlačítka „ulož“ hotel opravdu přidal, jelikož se neukázal žádný informační box, ale pouze se změnil hlavní nadpis stránky. Při hledání hotelů nenastal žádný problém, všichni testující se bez problému dostali na stránku s vyhledáváním a dokázali vyhledat požadované hotely. Každý uživatele byl požádán, aby vyplnil špatně emailovou adresu a nezadal název ubytování. Všichni ocenili systém nápovědy a upozornění a dokázali si nalézt, jak správně špatně vyplněné položky vyplnit.

Úkol č. 2 2.a) Všichni testující se dostali intuitivně na stránku s ceníkem. Testující č. 1 hledal nějaký kalkulátor, který by mu vypočítal cenu pro zadané období. Úkol č. 3 3.a) Při snaze dostat se na stránku s přidáním nového klienta se testující č. 2 snažil klikat na odkaz nová rezervace. Po mém navedení, aby si testující přečetl správně zadání, už našel odkaz pro přidání nového uživatele. Testující č. 1 nevěděl, jak přidat klienta, nenašel žádný odkaz pro přidání klienta. Po upozornění, že klient je jeden typ uživatele, se všichni správně dostali na stránku pro přidání uživatele. 3.b) Testující č. 1 přecházel mezi položkami ve formuláři pomocí klávesy TAB, a ta ho vedla jinak, než očekával. 3.c) Ani jeden z testujících neměl problém vytvořit novou rezervaci. Testující věděli, jak vybrat klienta k rezervaci. Testující č. 1 by uvítal při vyplňování formuláře pro vyhledání klienta tzv. našeptávač. Po uzavření nového okna si nevšiml, že se nějaké údaje na stránce s rezervací změnily. 3.d) Všichni testující uměli přidat novou objednávku ubytování, testující č. 2 nevěděl, v jakém formátu zadat data od a do. Po přidání nastal problém, jelikož si uživatelé neuvědomovali, že ještě musí přidat produkt. Po mé nápovědě se testující č. 1 a č. 3 127


3.e) 3.f) 3.g)

3.h)

snažili rovnou upravovat produkty, i když ještě žádné nebyly zadány. Testující č. 2 chtěl zadat 2 lůžková pokoj tak, že chtěl upravit přímo objednávku a zadat počet lidí na 2. Po vysvětlení souvislostí všichni testující přidali produkt správně. Testující č. 2, 3 nechápali tlačítko s názvem „přidej produkt“. Všichni testující věděli, kde změnit stav objednávky, ale nevěděli, jak změnu uložit (stav se ukládá ihned při změně automaticky). Poté, co jsem všem testujícím vysvětlil, co znamená opce, všichni ji dokázali správně nastavit. S přidáním platby za ubytování měl problém pouze testující č. 2, jenž nevěděl, kde vůbec na stránce s rezervací platbu zadat. Po doporučení podívat se na navigaci dané stránky testující danou sekci nalezl. U formuláře pro přidání chyběly hvězdičky pro označení povinných údajů, a tak testující č. 2, 3 nevěděli, co všechno musí vyplnit. Testující č. 2 úplně zapomněl na to, že by měl přidávat platbu k nějakému ubytování, a zadal pouze částku. Všem testujícím se podařilo správně změnit jméno na voucheru, tlačítko pro změnu hledali ihned v sekci klient.

Úkol č. 4 4.a) Testující č. 2 místo odkazu „Vyhledej“ stiskl „Seznam rezervací“, který ho však navedl na stejnou stránku. Všichni testující nalezli správnou rezervaci. 4.b) Všichni testující chvíli přemýšleli, kde mohou upravit objednávku. Po menší nápovědě všichni tlačítko pro editaci nalezli a objednávku správně prodloužili o 2 dny. V tomto případě jsem odhalil problém s automatickým přidáváním a úpravou produktů ubytování, pokud dojde ke změně dat pobytu. Testující č. 3 nemohl nalézt, kde může upravit počet produktů. Všichni testující by uvítali nápovědu pro přidávání a úpravu produktů k objednávce potažmo nápovědu k celé správě objednávek. 4.c) Testující č. 3 hledal cenu za pobyt v ceníku (ne přímo na stránce s rezervací), jinak všichni nakonec konečnou cenu nalezli. Úkol č. 5 5.a) Všem testujícím se bez problému podařilo vyhledat rezervace podle zadání.

6.4.6. Nalezené problémy a jejich možná řešení Na závěr testu ještě testované osoby vyplnily potestový dotazník, který mi přinesl další důležité podněty pro úpravu a vylepšení systému. Během testu byly také testující dotazování, jak na ně působí vzhled jednotlivých částí systému, jestli se jim s ním dobře pracovalo, jestli bylo ovládání intuitivní a jiné podobné otázky. Pomocí testu použitelnosti, předtestového a potestového dotazníku lze udělat závěry a navrhnou vylepšení systému. Nyní zde uvedu problémy vyplývající z testu a navrhnu jejich řešení. Nutno dodat, že několik problémů vzniklo z důvodů nepozornosti při čtení zadání, nesoustředěnosti a také krátkému času na seznámení se s aplikací. Ad 1.c) Problém se zadáváním GPS souřadnic Souřadnice se zadávají pouze do jednoho textového pole, což znesnadňuje jejich zadávání. Řešením by mohlo být rozdělení na 2 textová pole, která budou předem vyplněna znaky °,“,‘. Pomohla by také srozumitelnější nápověda. 128


Ad 1.c) Nezobrazovala se informace o přidání nového ubytování Systém při přidání nového ubytování pouze změnil hlavní nadpis. Jistým řešením bude přidat informační box, který se po přidání zobrazí. Ad 2.a) Složitý výpočet ceny pro nějaký pobyt Testující musel zjišťovat cenu pro nějaké období složitějšími výpočty. Řešením by byla implementace tzv. kalkulátoru, kde by si mohl uživatel zadat datum od a datum do spolu s typem pokoje a systém by automaticky vypočítal cenu. Ad 3.a) Problém s přidáním klienta Uživatelé nemohli nalézt odkaz, jak se dostat na stránku pro přidání klienta (odkaz přidat uživatele v sekci Uživatel). Řešením by bylo: • Přidat odkaz „nový klient“ (do menu sekce „Uživatelé“). • Přidat odkaz do menu sekce „Rezervace“. Ad 3.b) Chybějící tab-index u formulářových polí Testující přemisťující se formulářem pomocí klávesy TAB se ne vždy dostali do pole, kam chtěli. Řešením by bylo přidat k jednotlivým polím formuláře tzv. tab-indexi, které slouží pro určení pořadí pole při procházení formuláře. Ad 3.c) Nevýraznost změny informací na stránce s rezervací Systém při změně údajů o rezervaci neobnovuje celou stránku, ale pouze část se změněnou informací. Testování uživatelé poukazovali na tuto nevýraznost. Řešením by mohlo být: • Výrazné bliknutí změněné části. • Označení změněné části až do nového obnovení stránky. • Vyskakovací javascriptové okno s upozorněním na změnu. Ad 3.d) Přidání typu pokoje (produktu) k objednávce Uživatelé nevěděli, že ještě musí přidat k objednávce produkt. Tento problém musí řešit uživatelská příručka. Dalším řešením bude přidat podrobnější nápovědu či seznam kroků, jak správně vytvořit objednávku ubytování. Testující dále nechápali tlačítko „přidat produkt“. Řešením bude nazvat tlačítko „přidat typ pokoje“. Ad 3.e) Změna stavu objednávky Změna stavu se projevila ihned po překliknutí radio buttonu, což uživatelé nevěděli. Řešením může být: • Upozornění o změně vyskakovacím oknem. • Přidat tlačítko „ulož stav“. Ad 3.g) Přidání platby za objednávku Tady šlo zřejmě o problém s nedostatečným seznámením se systémem spolu s chybějícím označením povinných položek. Měla by pomoci kvalitnější nápověda. Ad 4.b) Špatný název sekce na stránce s rezervací

129

KAPITOLA 6. TESTOVÁNÍ V tomto případě šlo o problém s názvem sekce a úkolem. Sekce rezervace se jmenuje „Ubytování“ a test mluví o objednávce. Proto by bylo vhodné upravit název sekce na „Objednávky ubytování“, případně se na tuto část více zaměřit v nápovědě a při předvádění aplikace uživateli. Ad 4.c) Nalezení ceny za pobyt na stránce s rezervací Problém byl zřejmě v nepozornosti testujícího, ostatní testující uvedli, že jim tato část problémy nedělala. Výsledky potestového dotazníku Z potestového dotazníku vyplynuly tyto informace: • Práce se systémem byl pro uživatele víceméně intuitivní vzhledem k zaměření. Všechny testované osoby se shodly, že by jim více času na seznámení se systémem ulehčilo práci. • Vzhled aplikace se vesměs líbil, nikdo neměl žádné velké připomínky. Ovládání systému bylo pro všechny přehledné. • Systém nápovědy chválili všichni uživatelé, kterým se jevil jako velmi přínosný. • Práce s formulářem byla jednoduchá a přehledná, nedostatkem byla absence tzv. tabindexů u formulářových polí. Jeden z testujících by zvětšil písmo u popisů jednotlivých polí. • Největší problémem byla část s přidáváním a editací produktů. • Jeden z testujících si stěžoval na velikost textů u formulářů. Ostatním velikost vyhovovala. • Na stránce s rezervací nastal problém s názvem sekce „Ubytování“. Jeden z testujících upozorňoval na jiný systém tlačítek u sekce „Klient“, který se liší od ostatních (tlačítka pro ovládání jsou v sekci nahoře, u ostatních sekcí dole). • Testujícím chyběl kalkulátor pro výpočet ceny za pobyt.

6.5. Vyhodnocená testování Testování proběhlo v několika fázích. Nejdříve jsem provedl test celé aplikace procházením všech navržených případů užití a test uživatelského rozhraní. Poté jsem provedl test přístupnosti aplikace, jenž kontroloval body sepsané v kapitole 4.3. Nakonec jsem provedl test použitelnosti na 3 testovaných uživatelích. Každý test odhalil určité problémy a nedostatky systému a je těžké určit, který byl pro mne nejvíce přínosným. Bohužel jsem mohl využít pro testování použitelnosti pouze 3 osob, a proto není test tak moc průkazný. Se zadavatelem je však domluven test, kde budu mít k dispozici minimálně 10 osob. Veškeré nalezené problémy a nedostatky aplikace byly nebo budou v nejbližší době odstraněny. Po odstraněná těchto problémů dojde ke spuštění první beta verze aplikace přímo v provozu cestovní agentury.

130

KAPITOLA 7. ZÁVĚR

7 Závěr Tato práce měla za cíl navrhnout a implementovat informační systém cestovní agentury. Na začátku práce jsem provedl počáteční studii daného problému, ze které poté vycházela analýza. Poté jsem vybral technologie, na kterých by měla být aplikace postavena. V této části jsem se blíže seznámil s technologií Ajax. V dalším kroku následovala analýza návrhu, ve které jsem vycházel z dosavadních školních zkušeností. Proto jsem také využil jazyka UML pro popis případů užití a návrhu databázového modelu a navíc jsem se více zdokonalil v práci s grafickými programy při návrhu vzhledu uživatelského rozhraní. Po skočení analýzy jsem provedl implementaci a následně celou aplikaci podrobil několika testům, které pomohly odhalit několik závažných chyb v systému a mnoho drobných nedostatků. Při testování jsem prohloubil své znalosti z oblasti přístupnosti a použitelnosti webových aplikací, které bych rád využil při dalších projektech. Již při vzniku nápadu vytvořit rezervační systém pro cestovní agenturu bylo jasné, že za dobu 3 měsíců, které bych měl věnovat práci na diplomové práci, nebude možné projekt odevzdat zadavateli jako hotový. V současné době je informační systém cestovní agentury nasazen pro první beta testování aplikace přímo na pracovišti, kde dochází ke sběru důležitých informací o vadách a problémech se systémem. Po přibližně měsíci dojde poté k vyhodnocení testování a následné úpravě systému. Informační systém nyní obsahuje tyto funkce: správa uživatelů, správa ubytování, správa rezervací, správa služeb a partnerů a systém pro správu obsahu. V nejbližší době budou doimplementovány další požadované části: správa služeb přepravy, manažerské statistiky. Systém je navržen a implementován tak, aby nebyl problém přidat libovolnou novou funkci, aniž by došlo k nějakým velkým zásahům do ostatních funkcí systému. V následujících měsících bude docházet k postupnému vylepšování a přidávání nových funkcí na základě testovacího provozu systému. Dále je také naplánován nový test použitelnosti, který by měl být průkaznější oproti prvnímu provedenému testu. Jako hlavní přínos vidím fakt, že jsem mohl projít všemi fázemi vývoje softwarového projektu a zejména že se jednalo o reálný projekt, který bude využíván v praxi. Velkým přínosem je pro mne i komunikace se zadavatelem, kde jsem si také mohl procvičit přednes či prosazování svých myšlenek, což bych velmi rád využil pro své budoucí uplatnění. Nemohu opomenout, že pro mne bude diplomová práce sloužit jako reference při získávání nového zaměstnání po ukončení studia.

131

KAPITOLA 7. ZÁVĚR

132

KAPITOLA 8. SEZNAM LITERATURY A POUŽITÝCH ZDROJŮ

8 Literatura [1]

Gutmans, A.; Bakken, S. S.; Rathans, D. : Mistroství v PHP 5. Brno: Computer Press, a.s., druhé vydání, 2008, ISBN 978-80-251-1519-0.h

[2]

Pravidla tvorby přístupného webu, [Online], Poslední revize 12. 12. 2009.

[3]

Smarty template engine, [Online].

[4]

Oficiální dokumentace PHP, [Online], Poslední revize 1. 12. 2009.

[5]

Usability (official U.S. Government Web site managed by the U.S. Department of Health & Human Services), [Online], Poslední revize 12. 12. 2009.

[6] H1 – Prezentace firmy poskytující internetové poradenství a výkonový marketing, [Online]. [7]

Stránka Moodlu na ČVUT (X36ASS - Architektura softwarových systémů), [Online], Poslední revize 14.12.2009. < http://ocw.cvut.cz/moodle/>

[8]

Wikipedia EN - Unified Modeling Language, [Online], Poslední revize 14.12.2009

[9]

JQuery – Officiální dokumentace javascriptové knihovny pro snazší začlenění javascriptu do HTML kódu.

[10]

Interval – Internetový časopis zabývající se zejména vývojem webových aplikací (všechny články týkající se UML a tvorby případů užití), [Online], Poslední revize 7.11.2009.

[11]

w3.org : Web Content Accessibility Guidelines (WCAG) 2.0, W3C Recommendation. [Online], Poslední revize 12.12.2009

[12]

Wikipedia.org: Software Testing. [Online], Poslední revize 12.12.2009. http://en.wikipedia.org/wiki/Software_testing

133

KAPITOLA 8. SEZNAM LITERATURY A POUŽITÝCH ZDROJŮ

134

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

A

Seznam použitých zkratek

AJAX Asynchronous JavaScript and XML AI Auto increment CA Cestovní Agentura CMS Content Management System CSS Cascading Style Sheets CZK Czech Koruna DOM Document Object Model ER diagram – Entity-Relationship model EUR Euro FK Foreign Key FTP File Transfer Protocol HCI Human-Computer Interaction HTML HyperText Markup Language HTTP HyperText Transfer Protocol HUF Hungarian Forint GB GigaByte GHz Gigahertz GPS Global Positioning System GUI Graphical User Interface IE6, IE7 Internet Explorer IMAP Internet Message Access Protocol IS Information System ISO International Organization for Standardization MS Microsoft MySQL My Structured Query Language MSSQL Microsoft Structured Query Language OOP Object-Oriented Programming PC Personal Computer PostgreSQL Postgre Structured Query Language PHP Hypertext Preprocessor PK Primary Key POP3 Post Office Protocol 3 PX Pixel REF Reference SQL Structured Query Language UI User Interface UML Unified Modeling Language URL Uniform Resource Locator USD United States Dollar WWW World Wide Web XHTML eXtensible HyperText Markup Language XML eXtensible Markup Languag

135

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

136

PŘÍLOHA B. TESTOVÁNÍ POUŽITELNOSTI - DOTAZNÍKY

B

Testování použitelnosti – dotazníky

B.1

Předtestový edtestový dotazník

1.

Jaký je Váš věk? 0-18 19-25 26-35 36-45 46-55 55 a více

2.

Jaké máte zkušenosti s prací na PC? Žádné Základní Průměrné Vysoké (např. (nap živím se prací s PC) Expertní (např. (nap programuji)

3.

Jaké máte zkušenosti s prací s webovým prohlížečem? Žádné (nepoužívám internetový prohlížeč) prohlíže Základní (používám webový prohlížeč prohlíže pro čtení emailůů a zpráv na internetu aj.) Vysoké (používám více funkcí na internetu, využívám vyhledávače, vyhledáva nakupuji přes e-shopy,...) Expertní (programátor webových aplikací aj.)

4. Jak často asto používáte poč počítač? Vůbec 1x týdně 1x denně 1-33 hodiny denně denn více jak 3 hodiny denně denn 5.

Používal (a) jste někdy ěkdy nnějaký rezervační systém? Ne Ano, mám malé zkušenosti Ano, mám pokročilé zkušenosti

6.

Máte nějaké jaké zdravotní problémy ovliv ovlivňující práci na PC? Ne Nosím brýle Větší zrakové problémy Fyzický hendikep (problém s normálním ovládáním PC) Jiné ……………………………………………………………………..

137


B.2

Potestový dotazník

(známkujte stejným způsobem sobem jako ve škole - 1 nejlepší, 5 nejhorší) 1. Jak hodnotíte práci se systémem, byla pro Vás práce se systémem jednoduchá?

1

2

3

4

5

2. Jak hodnotíte vzhled aplikace? Bylo pro Vás barevné provedení příjemné? p

1

2

3

4

5

3. Změnil (a) byste něco co na vzhledu aplikace či uspořádání jednotlivých částí? ástí? Co by to bylo?

4. Jak hodnotíte systém nápověd? ěd? Byla pro vás nápov nápověda přínosem?

1

2

3

4

5

5. Byly pro Vás formulářee v aplikaci ppřehledné? Pokud ne, popište, co byste změnil ěnil (a).

1

2

3

4

5

6. Jaká část ást aplikace pro Vás byla nejméně nejmén přehledná a s kterou jste měll (a) nejvíce problémů při práci.

7. Měl (a) jste přii práci se systémem problém ppři přečtení nějakého testu? Případně ípadně jak jste to řešil (a)?

8. Přišla išla Vám stránka s detailem rezervace přehledná? p Uspořádání ádání jednotlivých částí bylo pochopitelné? Pokud ne, co byste udělal (a) jinak?

9. Chyběla Vám v systému nějaká ějaká funkce, která by např. nap mohla zlepšit či urychlit práci se systémem?

10. Jiné připomínky ipomínky k systému (zde prosím popište ostatní ppřipomínky mínky k systému, které neobsáhly předchozí otázky).

138


139

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA

C

Uživatelská příručka

Tato část textu je sepsána jako základní uživatelská příručka pro práci s navrženým a implementovaným rezervačním systémem pro první beta testování přímo u uživatele. Příručka popisuje prozatím 100% implementované funkce. Po vydání nových verzí systému bude uživatelský manuál vždy aktualizován.

C.1

Doporučené systémové požadavky

Pro běh systému můžete využít libovolného internetového prohlížeče, spíše však využijte některý z těchto: • Internet Explorer 7 a vyšší • Mozilla Firefox 3.0 a vyšší • Google Chrome • Opera 8 a vyšší Pro správnou funkčnost musíte mít v prohlížeči povolenu technologii Javascript.

C.2

Základní struktura aplikace, navigace

Základní struktura systému je rozdělena do 4 částí. V horní části se nachází základní navigace ovládání systému, která obsahuje tyto záložky (odkazy): • Domů – Odkaz na hlavní stránku • CMS – Odkaz na správu CMS systému • Nastavení – Odkaz na stránku s nastavením systému (pouze pro role manažer a administrátor) • Nápověda – Odkaz vedoucím na stránku s nápovědou • Rezervace – Zpřístupnění levého menu pro ovládání rezervačního systému • Web – Zpřístupnění levého menu pro ovládání CMS systému a jiných funkcí určených pro přidružený web Nahoře vpravo je umístěn malý panel s informacemi o přihlášeném uživateli spolu s odkazem „Odhlásit“ ze systému. Levé menu obsahuje strukturované odkazy pro ovládání všech související s rezervacemi a ovládáním přidruženého webu.

Obrázek C-1: Základní navigace systému.

140


C.3

Přihlášení uživatele do systému

Pro přihlášení do systému rezervační agentury jste obdrželi od správce systému ve vaší společnosti webovou adresu, kterou zadejte do Vašeho prohlížeče. Tím se zobrazí stránka pro přihlášení do systému (obrázek C.2), kde je nutné vyplnit správcem přidělené uživatelské jméno a heslo.

Obrázek C-2: Přihlašovací formulář.

C.4

Odhlášení uživatele ze systému Z aplikace se odhlásíte kliknutím na odkaz „Odhlásit“ umístěný na stránce vpravo

nahoře.

Obrázek C-3: Odhlášení ze systému

C.5

Správa uživatelů

C.5.1 Vytvoření nového uživatele Pro vytvoření nového uživatele klikněte v levém menu v sekci UŽIVATELÉ na odkaz Nový uživatel. Následně se zobrazí stránka s formulářem pro přidání nového uživatele. Uživatel s rolí PRODEJCE může přidávat pouze uživatele klienty a MANAŽER klienty a prodejce. Pro úspěšné přidání uživatel je nutné vyplnit hodnoty „uživatelské jméno“, „jméno“, „příjmení“, „2 x zopakovat stejně heslo“, „email“, „roli“ a „jazyk“. Po stisknutí tlačítka ULOŽ dojde k uložení údajů o novém uživateli a zobrazí se stránka s informací o něm. V případě, že nedojde z nějakého důvodu k uložení uživatele, zobrazí se opět formulář pro přidání uživatele s již vyplněnými údaji a informací, proč nedošlo k uložení spolu s nápovědou.

141


Obrázek C-4: Formulář pro přidání nového uživatele. C.5.2 Prohlížení seznamu uživatelů Pro prohlížení seznamu uživatelů klikněte na odkaz Seznam uživatelův v levém menu v sekci UŽIVATELÉ. Na této stránce naleznete seznam uživatelů spolu se základními informacemi o každém uživateli a odkazy pro: • zobrazení informací o uživateli (zobraz) • změnu údajů (uprav). • odstranění uživatele (vymaž) Uživateli s rolí PRODEJCE se zobrazí seznam pouze s KLIENTY.

Obrázek C-5: Stránka se seznamem uživatelů.

142

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA C.5.3 Prohlížení údajů o uživateli Prohlížet údaje o konkrétním uživateli můžete klepnutím na odkaz zobraz na stránce se seznamem uživatelů. Na stránce se zobrazí všechny vyplněné údaje o uživateli a navíc spolu s tlačítky pro upravení údajů o uživateli a odstranění uživatele.

Obrázek C-6: Informace o uživateli C.5.4 Změna uživatelských údajů Uživatel s rolí PRODEJCE může změnit pouze své a klientské údaje, MANAŽER může navíc změnit údaje o PRODEJCÍCH a ADMISNITRÁTOR může upravovat libovolné informace. Na stránku s formulářem pro změnu uživatelských údajů se dostanete bud při prohlížení údajů o konkrétním uživateli stisknutím tlačítka Uprav uživatele, nebo v seznamu uživatelů na odkaz uprav. Poté se zobrazí stránka s vyplněným formulářem (stejný jako na obrázku C.4). Pro změnu informací opravte požadované položky ve formuláři a stiskněte tlačítko ULOŽ. C.5.5 Odstranění uživatele Pro odstranění uživatele stiskněte tlačítko Odstraň uživatele na stránce s prohlížením údajů o konkrétním uživateli, nebo na stránce se seznamem uživatelů odkaz vymaž. Po kliknutí se Vám zobrazí okénko, zda opravdu chcete daného uživatel ze systému odstranit s dvěma možnostmi: ANO a NE. ANO znamená odstranění uživatele, stisknutím tlačítka NE se vrátíte zpět na naposledy načtenou stránku.

C.6

Správa ubytování

C.6.1 Přidání nového ubytování Zobrazit formulář pro přidání nového ubytování můžete kliknutím na odkaz Nové ubytování umístěný v levém menu v sekci UBYTOVÁNÍ. Pro úspěšné přidání je potřeba vyplnit všechny povinné údaje označené červenou hvězdičkou. Jak vyplnit jednotlivé údaje, zjistíte kliknutím na ikonu otazníku u některých z položek formuláře. Poté stiskněte tlačítko ULOŽ. V případě vyplnění špatných hodnot se Vám zobrazí box s údaji o špatném vyplnění a každá špatně vyplněná položka je červeně označena, jinak dojde k uložení nového ubytování.

143


Obrázek C-7: Formulář pro přidání nového ubytování. C.6.2 Seznam & Vyhledávání ubytování Nalézt vlastní ubytování můžete dvěma způsoby: • Stisknutím odkazu Vyhledávání v levém menu v sekci UBYTOVÁNÍ • Stisknutím odkazu Seznam ubytování v levém menu v sekci UBYTOVÁNÍ V obou případech se Vám zobrazí jak formulář pro vyhledání konkrétního ubytování, tak také seznam s nalezeným ubytováním. Při prvním zobrazení stránky se zobrazí seznam se všemi ubytovacími zařízeními. Vyplnění formuláře a stisknutím tlačítka HLEDEJ získáte seznam ubytování odpovídající zadaným parametrům hledání. Každé ubytovací zařízení v seznamu je popsáno jménem a kategorií + obsahuje odkazy na zobrazení údajů o ubytování (odkaz zobraz), změnu údajů a odstranění ubytování (uprav) a správu ceníku (ceník). Odkaz pro úpravu údajů se nezobrazuje uživateli s rolí PRODEJCE.

Obrázek C-8: Formulář pro vyhledávání ubytování & seznam ubytování 144


C.6.3 Upravení údajů o ubytování & odstranění ubytování Na stránku s úpravami údajů o ubytovacím zařízení se dostanete kliknutím na odkaz uprav v seznamu ubytování u konkrétního záznamu, kde se zobrazí stejný formulář, jako je pro vytvoření nového ubytování. Tento formulář je vyplněn dle aktuálních údajů. Pro změnu přepište požadované položky a stiskněte tlačítko ULOŽ. Pro odstranění ubytovacího zařízení stiskněte tlačítko ODSTRAŇ. Před vlastním odstraněním ze systému se Vás ještě systém dotáže, zda opravdu chcete odstranit ubytování. Stisknutím tlačítka ANO odstraníte ubytování ze systému.

Obrázek C-9: Spodní část formuláře pro úpravu a odstranění ubytování C.6.4 Prohlížení údajů o ubytování Pro informace o ubytovacím zařízení klikněte na odkaz zobraz na stránce se seznamem ubytování. Poté se zobrazí stejná stránka jako při editaci údajů, kromě tlačítek ULOŽ a ODSTRAŇ.

C.7

Správa ceníku

Spravovat ceník ubytování můžete kliknutím na odkaz „ceník“ na stránce se seznamem ubytování, nebo na stránce s prohlížením údajů o ubytování. Uživatel s rolí PRODEJCE může pouze ceník prohlížet, proto je tato část příručky určena pro role MANAŽER a ADMINISTRÁTOR. C.7.1 Přidání a správa typů pokojů Nový pokoj Přidat nový typ pokoje můžete vyplněním formuláře nový typ pokoje a stisknutím tlačítka PŘIDEJ. Povinné údaje jsou počet lidí (max. počet osob na pokoji) a typ pokoje. Max. počet lidí musíme mít minimální hodnotu 1. Úprava údajů o pokojích Druhý formulář ceníku slouží pro editaci pokojů. Stisknutí tlačítka ULOŽ dojde k uložení změn u všech produktů. Odstranění pokoje 145

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Ve formuláři nazvaném pokoje je u každého typu pokoje tlačítko ODSTRAŇ. Kliknutím na něj odstraníte ze systému daný typ pokoje. Pozor! Pokud již existuje ceník pro tento typ pokoje, dojde k odstranění všech příslušných cen.

Obrázek C-10: Ceník – Správa pokojů ubytovacího zařízení. C.7.2 Přidání sekce ceníku Abyste mohli vyplňovat ceník, musíte vytvořit kromě nějakého typu pokoje také sekci ceníku, pro kterou budou platit ceny. Každá sekce ceníku bude obsahovat minimálně 1 období, pro které budou ceny platit. Dále je potřeba vyplnit typ sekce, který může nabývat jedné z těchto hodnot: • Normální (normální ceny) • Speciální (speciál ceny) • Top (top termín ceny) Žádná období se pro stejný typ sekce nemohou překrývat, pro různé sekce se ale mohou překrývat. Pokud se budou některá období překrývat, budou se brát ceny pro objednávky ubytování v tomto pořadí: Top ceny, Speciální a nakonec případně Normální.

Obrázek C-11: Ceník – Formulář pro přidání nové sekce ceníku.

146

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA C.7.3 Správa cen (zadávaní a editace) V případě, že jste vytvořili alespoň jeden typ pokoje a jednu sekci ceníku, můžete zadávat ceny za ubytování pro zadané období a pokoje. Tento formulář naleznete na stránce s ceníkem pod formulářem pro přidání sekce ceníku. Pro každý produkt a sekci můžete zadat: • Brutto cenu • Měnu brutto ceny • Netto cenu • Měnu netto ceny • Pultovou cenu • Měnu pultové ceny Stisknutím tlačítka ULOŽ umístěném dole ve formuláři uložíte všechny zadané ceny. Ceny můžete zadávat v číselném formátu, minimální hodnotou je 0.

Obrázek C-12: Ceník – Formulář pro správu cen C.7.4 Přidání a úprava období sekce ceníku Na konci každé sekce ceníku ve formuláři ceník (obr. C.12) je umístěno tlačítko UPRAV OBDOBÍ. Kliknutím na toto tlačítko zobrazíte formulář, ve kterém můžete přidat nové období, nebo editovat stávající. Stisknutím tlačítka ulož v novém formuláři se uloží všechny změny (změny v období či nová období). C.7.5 Odstranění sekce ceníku Na konci každé sekce ceníku ve formuláři ceník (obr. C.12) je také umístěno tlačítko ODSTRAŇ OBDOBÍ. Kliknutím na toto tlačítko odstraníte danou sekci ceníku spolu se všemi 147

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA zadanými cenami pro danou sekci. Navíc dojde k odstranění také všech období spojených s danou sekcí. Předtím, než dojde k provedení všech těchto příkazů, zeptá se systém, zda opravdu chcete odstranit danou sekci se všemi příslušnými cenami. Kliknutím na tlačítko ANO systém odstraní konkrétní sekci ceníku.

C.8

Správa rezervace / rezervací

C.8.1 Vytvoření nové rezervace Novou rezervaci přidáte kliknutím na odkaz nová rezervace v levém menu v sekci REZERVACE. Zobrazí se jednoduchý formulář, kde musíte kliknout na tlačítko VYTVOŘ REZERVACI. Poté systém vytvoří novou prázdnou rezervaci a zobrazí novou stránku s touto rezervací, kterou půjde posléze editovat.

Obrázek C-13: Stránka s novou rezervací C.8.2 Správa rezervace Stránka s rezervací je rozčleněna na několik sekcí. Nahoře je umístěna navigace, pomocí které se můžete pohybovat po celé stránce. Vlastní rezervace je rozčleněna do těchto částí: • •

Informace o rezervaci Informace o klientovi spolu s těmito možnostmi o Vybrání klienta o Editace kontaktních údajů 148


•

• •

•

Objednávky ubytování o Přidání ubytování o U každé objednávky lze Editovat objednávku Přidat a editovat produkty k objednávce Objednávky služeb Platby o Přidání platby o Každou platbu lze Upravit Odstranit Sumář o Obsahuje shrnutí cen a plateb za všechny objednávky

Přidání klienta k rezervaci Klienta k rezervaci přidáte stisknutím tlačítka „Vyber klienta“. Po stisknutí se otevře nové okno s formulářem pro vyhledávání klientů. Vyplňte požadované hodnoty a stiskněte tlačítko „Vyhledej“. Hledání probíhá i dle částečné shody se zadanými hodnotami. Nyní mohou nastat 3 případy: • Zadání neodpovídá ani jeden klient o Změňte hodnoty ve formuláři. • Nalezen 1 až 10 klientů o Systém zobrazí tabulku s výpisem nalezených klientů. o Stisknutím tlačítka „Vyber“ u konkrétního klienta jej přidáte k rezervaci. o Po stisknutí tlačítka dojde k zavření nového okna a k aktualizaci stránky s rezervací. • Nalezeno více jak 10 klientů o Upřesněte hodnoty ve formuláři (napište celé jméno, hledejte dle více položek, aj.)

Obrázek C-14: Rezervace – Formulář přidání klienta k rezervaci. 149


Editace kontaktních údajů klienta Kontaktní údaje rezervace se mohou lišit od údajů uvedených při zakládání klienta v systému. Kontaktní údaje jsou: jméno, příjmení, emailová adresa, telefon, firma, jméno na voucher a jazyk. Pro změnu klikněte na tlačítko „Uprav kontaktní údaje“ v sekci Klient. Zobrazí se Vám formulář v novém okně zobrazený na obrázku C-15. Změňte libovolné údaje a stiskněte tlačítko „ULOŽ“. Poté dojde k uložení nových hodnot a uzavřená nového okna spolu s obnovením stránky s rezervací.

Obrázek C-15: Rezervace – Formulář pro editaci kontaktních údajů. Vytvoření objednávky ubytování Pro přidání objednávky ubytování k rezervaci slouží tlačítko „Přidej ubytování“ v sekci rezervace Ubytování. Po stisknutí se otevře v novém okně formulář pro přidání objednávky. Povinné položky jsou: • ubytování • počet dospělých (číslo > 0) Pro vyplnění položek „datum příjezdu“, „datum odjezdu“ a „opce“ využijte systém kalendáře (po kliknutí do příslušného textového pole se Vám tyto kalendáře automaticky zobrazí). Stisknutím tlačítka „ULOŽ“ přidáte objednávku k rezervaci. Po přidání objednávky ubytování je ještě potřeba přidat alespoň jeden produkt (pokoj).

150


Obrázek C-16: Rezervace – Objednávka ubytování.

Obrázek C-17: Rezervace – Formulář pro editaci objednávky ubytování. 151


Editace objednávky ubytování U každé objednávky ubytování je v dolní části umístěno několik ovládacích tlačítek. Jedno z nich slouží pro zobrazení formuláře pro editaci objednávky (tlačítko „Uprav objednávku“). Po stisknutí tohoto tlačítka se zobrazí stejný formulář, jako pro přidání objednávky. Zde máte 2 možnosti: • Upravit údaje. o Po úpravě požadovaných hodnot stiskněte tlačítko „ULOŽ“. Systém tyto změny uloží, uzavře nové okno a aktualizuje stránku s rezervací. • Odstranit objednávku ubytování. o Stisknutím tlačítka „Odstraň“. o Odstranit lze objednávku pouze ve stavu REQ a PRE. o Systém se ještě zeptá, zda opravdu chcete smazat objednávku. Pro odstranění stiskněte „ANO“. Jinak „NE“. Přidání produktu k objednávce ubytování Každá objednávka by měla obsahovat alespoň 1 produkt (pokoj). Pokoje se přidávají po vytvoření objednávky, protože klient při kontaktování CA nemusí na začátku vědět, jaký pokoj by chtěl či jaký pokoj dané ubytovací zařízení nabízí. Produkt = Pokoj. Pro přidání konkrétního pokoje stiskněte tlačítko „Přidej produkt“. Poté dojde k zobrazení formuláře v novém okně. Zde vyplňte tyto položky: • typ pokoje (povinný údaj) • počet pokojů – počet objednávaných pokojů tohoto typu (povinný údaj) • upřesnění popisu – upřesněn popisu pokoje • komentář – váš komentář k pokoji Pokoj přidáte stisknutím tlačítka „ULOŽ“. Systém v tuto chvíli přidá pokoj k objednávce a nalezne ceny z ceníku ubytování pro tento typ pokoje a období. Tyto ceny budeme poté moci jednoduše editovat. Vzhledem k tomu, že se pro určité období můžou ceny lišit, systém vytvoří pro každé ceny nový produkt. Jednotlivé produkty se poté objevují na stránce s rezervací u každé objednávky v části „Produkty“ (obrázek C-16). Editace produktů objednávky ubytování Pro editaci produktů (pokojů) stiskněte tlačítko „Uprav Produkty“. V novém okně se zobrazí formulář z obrázku C-18. Tlačítkem „Ulož“ uložíte všechny provedené změny u všech produktů. Stisknutím tlačítka „Odstraň“ odeberete z objednávky ubytování konkrétní produkt. Pokud okno zavřete bez uložení, systém žádné změny neuloží.

152


Obrázek C-18: Rezervace – Formulář pro editaci produktů objednávky ubytování.

Přidání a editace platby za rezervaci (objednávku) Sekci Platby naleznete na stránce s rezervací po sekci Služby. Platby mohou být jak za konkrétní objednávku, tak i za blíže nespecifikovanou věc. U plateb zadáváte tyto parametry: • Kategorie platby – zde máte na výběr z: (povinná položka) o Ubytování o Služba o Ostatní • Objednávka – pouze pokud zadáte kategorii platby o Zde můžete vybrat konkrétní objednávku ubytování, služby za kterou je platba. • Charakter (povinná položka) o Předplatba o Finální platba • Typ platby – zde zadáváte způsob platby – platba kartou, bankovním převodem aj. (povinná položka) • Částka (povinná položka) • Číslo karty, číslo autorizace, datum autorizace, datum kurzů, komentář Pro otevření formuláře stiskněte tlačítko „Přidej platbu“. Po vyplnění formuláře z obrázku C-19, stisknutím tlačítka „Ulož“ přidáte novou platbu k rezervaci. U každé platby dole je umístěno tlačítko „Uprav platbu“. Po stisknutí se otevře stejný formulář, jako pro přidání platby, který bude vyplněn dle aktuálních hodnot. Navíc je pod formulářem umístěno tlačítko „Odstranit“, po jehož stisknutí a potvrzení odstraníte platbu z rezervace. Pro uložení změn stiskněte tlačítko „Ulož“.

153


Obrázek C-19: Rezervace – Formulář přidání platby k rezervaci.

C.8.3 Vyhledávání rezervací Vyhledávat rezervace můžete pomocí formuláře, který naleznete pod odkazem „Vyhledávání“ v levém menu v sekci Rezervace. Systém nyní umožňuje hledat rezervace dle těchto atributů: • Rezervační číslo • Jméno klienta • Emailová adresa • Firma • Název ubytování • Stav rezervace • Datum příjezdu • Datum odjezdu Některé parametry lze mezi sebou kombinovat.

154

PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Pro vyhledávání podle rezervačního čísla, jména, emailu, firmy nebo ubytování napište do textového pole hledaný řetězec a označte hledanou položku ve formuláři vedle hledaného textu. Pokud nezaškrtnete ani jeden z nabízejících se stavů, vyhledává rezervace s libovolným stavem. Po stisknutí tlačítka „Hledej“ systém vyhledá a zobrazí všechny odpovídající rezervace. Tlačítko „Vynuluj“ slouží k vymazání všech parametrů hledání. V případě, že jste nevyplnili žádný parametr, systém zobrazí všechny rezervace.

Obrázek C-20: Vyhledávání rezervací & Seznam rezervací.

Zobrazená rezervace Pro zobrazení rezervace klikněte na daný v tabulce s výpisem rezervací.

155


156

PŘÍLOHA D. OBSAH PŘILOŽENÉHO CD

D

Obsah přiloženého CD / text / help / html / install / software index.htm

- diplomová práce ve formátu PDF a DOC - uživatelská příručka spolu s příručkou pro instalaci - kompletní adresářová struktura včetně souborů - soubory potřebné pro zprovoznění systému na serveru (příkazy sql pro vytvoření databáze) - freeware program WAMP – webový server Apache s PHP a MySQL - průvodce CD

157

Informační systém cestovní agentury

Recommend Documents

Ahoj {$jmeno }