Informační systém cestovní agentury

Transkript

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

2 ii

3 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

4 iv

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

6 vi

7 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

8 viii

9 Obsah Seznam obrázků Seznam tabulek xiii xv 1. Úvod 1 2. Použité technologie a metodiky X(HTML) CSS PHP Smarty JavaScript Ajax MySQL Apache http Server Úvodní studie Deklarace záměru Odborný článek Ubytovací zařízení Doplňkové služby Uživatelé, klienti Rezervace CMS Systém Statistiky Katalog požadavků Uživatelské role Klient Prodejce Správce CMS Manažer Administrátor Funkce systému Služby systému pro klienta Služby pro prodejce Služby pro správce CMS Služby pro manažera Služby pro administrátora Nefunkční požadavky Návrh architektury Požadavky na softwarové vybavení uživatelů systému Požadavky na hardwarové, softwarové vybavení a obecné požadavky na webový server Softwarové vybavení Hardwarové vybavení Obecné požadavky Požadavky na HW vybavení počítačů uživatelů informačního systému Harmonogram projektu Use Case nejvyšší úrovně Analýza rizik.. 17 ix

10 3.8. Datový slovník Analýza a návrh řešení Analýza případů užití UC001 Přihlášení do systému UC002 Odhlášení ze systému UC003 Správa uživatelů UC004 - Vytvoření nového uživatele UC005 Editace uživatele UC006 Odstranění uživatele UC007 Prohlížení údajů o uživateli UC008 Vyhledávání uživatelů UC009 Prohlížení seznamu uživatelů UC010 - Správa ubytování UC011 Vytvoření nového ubytovacího zařízení UC012 Editace ubytovacího zařízení UC013 Odstranění ubytování UC014 Prohlížení údajů o ubytování UC015 Vyhledávání ubytování UC016 Prohlížení seznamu ubytování UC017 Správa produktů a ceníků UC018 Přidání produktu k ubytování UC019 Editace produktů ubytování UC020 Odstranění produktu UC021 Přidání sekce ceníku UC022 Editace sekce ceníku UC023 Odstranění sekce UC024 Přidání období k sekci ceníku UC025 Editace období k sekci ceníku UC026 Odstranění období sekce ceníku UC027 Editace ceníku UC028 Prohlížení ceníku UC029 Správa rezervace UC030 Vytvoření rezervace UC031 Přidání a změna klienta k rezervaci UC032 Editace kontaktních údajů o klientovi v rezervaci UC033 Odebrání klienta z rezervace UC034 Přidání objednávky ubytování k rezervaci UC035 Přidání produktu ubytování k objednávce ubytování UC036 Editace produktů ubytování u objednávky ubytování UC037 Odstranění produktu ubytování z objednávky ubytování UC038 Změna stavu objednávky UC039 Odstranění objednávky ubytování UC040 Přidání objednávky služby UC041 Editace objednávky služby UC042 Odstranění objednávky služby UC043 Přidání objednávky přepravy UC044 Editace objednávky přepravy UC045 Odstranění objednávky přepravy UC046 Správa komentářů k rezervaci UC047 Přidání platby k rezervaci UC048 Editace platby UC049 Odstranění platby UC050 Prohlížení rezervace x

11 UC051 Prohlížení seznamu rezervací UC052 Vyhledávání rezervací UC053 Vytvoření nového partnera pro služby a přepravu UC054 Prohlížení seznamu partnerů UC055 Prohlížení partnera UC056 Editace partnera pro služby a přepravu UC057 Vytvoření nové služby UC058 Prohlížení seznamu služeb UC059 Vyhledávání služeb UC060 Prohlížení služby UC061 Editace služby UC062 Odstranění služby Datový model Konceptuální schéma databáze Teorie Návrh Návrh uživatelského rozhraní Pravidla návrhu UI Návrh UI rezervačního systému CA Specifikace prototypu uživatele a minimálních technických požadavků na sytém Pravidla přístupnosti zásadní pro návrh aplikace Pravidla použitelnosti zásadní pro návrh aplikace Struktura uživatelského rozhraní vzhledem k funkčnosti aplikace Návrh uživatelského rozhraní pomocí grafického programu Implementace Datový model, implementace datového modelu Implementace případů užití Vlastní implementace Postup implementace Struktura aplikace, programové skripty Základní soubory a objekty Objekty Pluginy Šablony Soubory s javascriptem Nové Smarty funkce Testování Testování uživatelského rozhraní Testování aplikace jako celku Testování přístupnosti Testování přístupnosti Testování přístupnosti vzhledem k typu používaného prohlížeče Testování použitelnosti Pravidla a cíl testování Výběr testerů Předpoklady a požadavky na uživatele Předtestový dotazník Nastavení testu Úkoly a vlastní testování Výsledky testování Nalezené problémy a jejich možná řešení Vyhodnocení testování xi

12 7. Závěr Literatura 133 A Seznam použitých zkratek 135 B Testování použitelnosti dotazníky 137 B.1 Předtestový dotazník B.2 Potestový dotazník C Uživatelská příručka 140 C.1 Doporučené systémové požadavky C.2 Základní struktura aplikace, navigace C.3 Přihlášení uživatele do systému C.4 Odhlášení uživatele ze systému C.5 Správa uživatelů C.5.1 Vytvoření nového uživatele C.5.2 Prohlížení seznamu uživatelů C.5.3 Prohlížení údajů o uživateli C.5.4 Změna uživatelských údajů C.5.5 Odstranění uživatele C.6 Správa ubytování C.6.1 Přidání nového ubytování C.6.2 Seznam & Vyhledávání ubytování C.6.3 Upravení údajů o ubytování & odstranění ubytování C.6.4 Prohlížení údajů o ubytování C.7 Správa ceníku C.7.1 Přidání a správa typů pokojů C.7.2 Přidání sekce ceníku C.7.3 Správa cen C.7.4 Přidání a úprava období sekce ceníku C.7.5 Odstranění sekce ceníku C.8 Správa rezervace / rezervací C.8.1 Vytvoření nové rezervace C.8.2 Správa rezervace C.8.3 Vyhledávání rezervací D Obsah přiloženého CD 157 xii

13 Seznam obrázků 2.1 Komunikace serveru a klientského počítače po spuštění javascriptu Ajax Architektura Objednávka stavový diagram Diagram nasazení Use Case diagram nejvyšší úrovně, část Use Case diagram nejvyšší úrovně, část Harmonogram Projektu Návrh uživatelského rozhraní Přihlášení do systému Návrh uživatelského rozhraní Odhlášení ze systému Návrh uživatelského rozhraní Formulář pro vytvoření nového uživatele Diagram Aktivit 1 Vytvoření nového uživatele, Diagram Aktivit 2 Editace uživatele Návrh uživatelského rozhraní Prohlížení údajů o uživateli systému Návrh uživatelského rozhraní Seznam uživatelů Diagram Aktivit 3 Odstranění uživatele, Diagram Aktivit 4 Vyhledávání uživatelů Diagram Aktivit 5 Správa ubytování Diagram Aktivit 6 Vytvoření nového ubytování Návrh uživatelského rozhraní Odstranění ubytování Návrh uživatelského rozhraní Prohlížení údajů o ubytování Diagram Aktivit 7 Správa produktů a ceníků Návrh uživatelského rozhraní Přidání a editace produktů (typů pokoje) ubytování Návrh uživatelského rozhraní Formulář pro přidání sekce ceníku Diagram Aktivit 8 Editace ceníku, Diagram Aktivit 9 Odstranění produktu Návrh uživatelského rozhraní Formulář pro editaci a prohlížení ceníku ubytování Návrh uživatelského rozhraní Prohlížení rezervace Diagram Aktivit 9 Správa rezervací Diagram Aktivit 10 Přidání a změna klienta k rezervaci Návrh uživatelského rozhraní Formulář pro přidání produktu k objednávce 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í Návrh uživatelského rozhraní Editace produktů objednávky Návrh uživatelského rozhraní Změna stavu objednávky Návrh uživatelského rozhraní Vyhledávání rezervací & seznam rezervací Konceptuální návrh databáze Návrh základního uživatelského rozhraní v grafickém editoru Návrh dalších elementů aplikace zobrazených v obsahové části Fyzický datový model xiii

14 5.2 Základní adresářová struktura aplikace C.1 Základní navigace systému C.2 Přihlašovací formulář C.3 Odhlášení ze systému C.4 Formulář pro přidání nového uživatele C.5 Stránka se seznamem uživatelů C.6 Informace o uživateli C.7 Formulář pro přidání nového ubytování C.8 Formulář pro vyhledávání ubytování & seznam ubytování C.9 Spodní část formuláře pro úpravu a odstranění ubytování C.10 Ceník Správa pokojů ubytovacího zařízení C.11 Ceník Formulář pro přidání nové sekce ceníku C.12 Ceník Formulář pro správu cen C.13 Stránka s novou rezervací C.14 Rezervace Formulář přidání klienta k rezervaci C.15 Rezervace Formulář pro editaci kontaktních údajů C.16 Rezervace Objednávka ubytování C.17 Rezervace Formulář pro editaci objednávky ubytování. 151 C.18 Rezervace Formulář pro editaci produktů objednávky ubytování. 153 C.19 Rezervace Formulář přidání platby k rezervaci C.20 Vyhledávání rezervací & Seznam rezervací xiv

15 Seznam tabulek 3.1 Analýza rizik Datový slovník 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 Databázová tabulka kurz Databázová tabulka typ_logu Databázová tabulka log Seznam objektů aplikace Seznam pluginů Seznam šablon Sumář testování případů užití Testování přístupnosti kontrast barev Vybraní testující pro testování použitelnosti xv

16 xvi

17 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 u. 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 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

18 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 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 <img />). 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í 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

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

20 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 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: <?php // Vytvoření nového objektu Smarty $smarty = new Smarty(); // Přiřazení hodnoty Smarty proměnné jmeno $smarty->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

21 KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY Zdrojový kód šablony uvodni_stranka.tpl: <html> <head> <title>úvodní stránka</title> </head> <body> <h1>ahoj {$jmeno }</h1> // zobrazení dnešního data v českém formátu 2 způsoby <div>dnes je: {$smarty.now date_format:"%d-%m-%y"} </div> <div>dnes je: {$ aktualni_datum date_format:"%d.%m.%y"} </div> <p>{$uvodni_text upper truncate:53}</p> // 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 </body> </html> <p>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}</span>, {else} {$stastne_cislo}, {/if} {/foreach} </p> Zobrazení šablony v prohlížeči: Ahoj Jirka Snizek Dnes je: Dnes je: 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

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

23 KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY 2.7. MySQL Obrázek 2-2 : Ajax architektura. MySQL je multiplatformní databázový server (aktuální verze ). 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 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

24 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í 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 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í 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 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

25 KAPITOLA 3. ÚVODNÍ STUDIE 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: ovou/telefonickou a internetovou objednávku. Pokud přijde ová 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. Vytvořená (vznik objednávky) 2. Předběžná (partner CA potvrdil objednávku a stanovil opci) 3. Fixní (klient zaplatil požadovanou částku) 4. Využívaná (klient využívá ubytování, službu) 5. Ukončená (klient ukončil pobyt, službu) konečný stav 6. 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 ové objednávky. 9

26 KAPITOLA 3. ÚVODNÍ STUDIE 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, ová 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

27 KAPITOLA 3. ÚVODNÍ STUDIE 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 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) Katalog požadavků Uživatelské role Systém bude obsahovat 5 uživatelských rolí s různými pravidly přístupu 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 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 . Poté systém automaticky vygeneruje nové heslo a odešle nové údaje na , který je uveden v systému u daného uživatele. 11

28 KAPITOLA 3. ÚVODNÍ STUDIE 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 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ů 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 Funkce systému Služby systému pro klienta V současné době se neplánují žádné služby pro klienta 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í Služby pro správce CMS systému prohlížení textů v CMS systému 12

29 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) 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) 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 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

30 KAPITOLA 3. ÚVODNÍ STUDIE 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 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 Požadavky na terminálové stanice uživatelů systému jsou uvedeny v kapitole Obrázek 3-2: Diagram nasazení 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šší Požadavky na hardwarové, softwarové vybavení a obecné požadavky na webový server Softwarové vybavení 14

31 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šší Hardwarové vybavení Velká kapacita diskového prostoru (minimálně několik GB). Velká operační paměť 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 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 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

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

33 KAPITOLA 3. ÚVODNÍ STUDIE Obrázek 3-4: Use Case diagram nejvyšší úrovně, část 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

34 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ňů: zanedbatelný marginální kritický katastrofický Rizi ko Odhad ppsti. výskytu Dopad Vysvětlení odhadu pravděpodobnosti (+ označuje důvody pro snížení rizika, - pro zvýšení rizika) 1. a 10 % Kritický - 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. 1. b 10% Marginální Odpovídá odhadu rizika 1.a. + Budu sám implementovat aplikaci 1. c 20% Marginální - 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. 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. 18

35 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. 2. b 1% Kritický + Vzhledem ke zkušenostem a doporučením od lidí z oboru mohu toto riziko vyloučit. + Malý výběr mezi technologiemi. 2. c 20% Marginální - 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. d 15% Zanedbatel -ný - Rozdíl v reprezentaci CSS 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. 3. a 50% 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. 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. 19

36 KAPITOLA 3. ÚVODNÍ STUDIE 3. b 15% Kritický +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. 3. c 5%, 50% 3. d 5% Marginální/ Zanedbatel ný Katastrofic ký + 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. 4. a 10% Kritický - Možná chyba při implementaci vzhledem k rozsahu systému. 4. b 15% Kritický - Katastrofic ký - Nejsem hacker a neznám všechny typy možných útoků. + Mám určitě znalosti ohledně bezpečnosti aplikace. 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í. 20

37 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 CMS Evidence Role správce informačního systému. Má přístup ke všem funkcím systému. Systém pro správu webového obsahu. Tzv. redakční systém. 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 Ftp přístup Hosting Htaccess Check-in Check-out Kaskádové styly Klient Manažer Nákupní cena Objednávka Platba Objednávka, která již byla klientem potvrzena a alespoň částečně uhrazena. 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 u či webového formuláře. Zaznamenaná platba klienta za služby či ubytování. 21

38 KAPITOLA 3. ÚVODNÍ STUDIE 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

39 KAPITOLA 3. ÚVODNÍ STUDIE Obrázek 3-5 : Harmonogram Projekt 23

40 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 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: Hlavní aktéři minimálně méně často opakovaně 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

41 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ů 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

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

43 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-2: Návrh uživatelského rozhraní Odhlášení ze systému 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ý 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

44 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í, ová 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

45 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-3: Návrh uživatelského rozhraní Formulář pro vytvoření nového uživatele (klienta) 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

46 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 UC 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

47 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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

48 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 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í, ová 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

49 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í, ová 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ý 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

50 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

51 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-7 : Diagram Aktivit 3 Odstranění uživatele, Diagram Aktivit 4 Vyhledávání uživatelů 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

52 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 UC 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í 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

53 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, ová 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í 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

54 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 UC 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 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

55 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í 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

56 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í) 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

57 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ý 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

58 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Uživateli se zobrazil seznam ubytování. Požadavek na logování Žádný 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 UC 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

59 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-12 : Diagram Aktivit 7 Správa produktů a ceníku 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

60 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í 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

61 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í 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

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

63 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

64 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-15 : Diagram Aktivit 8 Editace ceníku, Diagram Aktivit 9 Odstranění produktu 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

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

66 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í 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

67 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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í 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

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

69 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-16: Návrh uživatelského rozhraní Formulář pro editaci a prohlížení ceníku ubytování 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

70 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ý 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

71 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 UC 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

72 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-17: Návrh uživatelského rozhraní Prohlížení rezervace. 56

73 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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í) 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

74 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í 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

75 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. 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. 6. Uživatel stiskne tlačítko vybrat u konkrétního klienta. 7. Systém přidá vybraného klienta k rezervaci. 8. 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í 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

76 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 6. 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í, ová 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 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

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

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

79 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

80 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní Obrázek 4-20: Návrh uživatelského rozhraní Formulář pro přidání produktu k objednávce. 64

81 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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í 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

82 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

83 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní Obrázek 4-22: Návrh uživatelského rozhraní Editace produktů objednávky 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

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

85 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní Obrázek 4-23: Návrh uživatelského rozhraní Změna stavu objednávky 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

86 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ UC040 Přidání objednávky služby Analogické k případu užití UC034 Přidání objednávky ubytování k rezervaci 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í UC 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 UC042 Odstranění objednávky služby Stručný popis 70

87 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í UC043 Přidání objednávky přepravy Analogické k případu užití UC034 Přidání objednávky ubytování k rezervaci UC044 Editace objednávky přepravy Analogické k případu užití UC041 Editace objednávky služby UC045 Odstranění objednávky přepravy Analogické k případu užití UC042 Odstranění objednávky služby UC046 Správa komentářů k rezervaci 71

88 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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ý 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

89 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í UC048 Editace platby Analogické k případu užití UC041 Editace objednávky služby UC049 Odstranění platby Analogické k případu užití UC042 Odstranění objednávky služby 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

90 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

91 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ o 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ý 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, ová 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ý 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, ová 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

92 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

93 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-24: Návrh uživatelského rozhraní Vyhledávání rezervací & seznam rezervací 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

94 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. Systém ověří, zda jsou všechny povinné údaje vyplněné a zkontroluje korektnost všech zadaných údajů. 6. Systém uloží informace do databáze. 7. 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, ová 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í UC054 Prohlížení seznamu partnerů Analogické k případu užití UC009 Prohlížení seznamu uživatelů UC055 Prohlížení partnera Analogické k případu užití UC014 - Prohlížení údajů o ubytování 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

95 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 6. Systém upraví informace o partnerovi. 7. 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 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

96 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í UC058 Prohlížení seznamu služeb Analogické k případu užití UC009 Prohlížení seznamu uživatelů UC059 Vyhledávání služeb Analogické k případu užití UC008 Vyhledávání uživatelů UC060 Prohlížení služby Analogické k případu užití UC014 - Prohlížení údajů o ubytování 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

97 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. Systém ověří, zda jsou všechny povinné údaje vyplněné, a zkontroluje korektnost všech zadaných údajů. 6. Systém upraví údaje o službě a obdobích služby. 7. 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 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

98 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í 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 Konceptuální schéma databáze 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) 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

99 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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ů. 5. 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ží. 6. 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. 7. Čá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. 8. Uživatel Entita Uživatel slouží pro evidenci uživatelů systému a uživatelů webových stránek. 9. 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. 10. Zaměstnanec Také Zaměstnanec je potomkem entity Uživatel. U zaměstnance evidujeme navíc několik dalších atributů oproti Klientovi. 11. 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. 12. 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. 13. 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í. 14. 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. 15. 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. 16. 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. 17. 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. 18. Objednávka Ubytování 83

100 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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í. 19. 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. 20. 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í. 21. 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. 22. 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ů. 23. Poskytovatel služby Poskytovatel služby je konkrétním typem partnera poskytující doplňkové služby pro CA. 24. Poskytovatel přepravy Poskytovatel přepravy je konkrétním typem partnera poskytující přepravu pro CA. 25. 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. 26. 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. 27. 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. 28. 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. 29. Slovník Tato entita slouží pro evidenci slov, frází a vět v jednotlivých překladech. 84

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

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

103 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 Entita slouží pro ukládání odeslaných ů 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 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) 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

104 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

105 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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.) 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

106 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ o Webový prohlížeč IE7 a IE8, Mozilla Firefox 2 a 3, Opera, Google Chrome. o 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 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

107 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ o Každý prvek ve formuláři musí mít vystihující popisek. o 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 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

108 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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

109 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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

110 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4-27 : Návrh dalších elementů aplikace zobrazených v obsahové části, které budou stejné pro všechny stránky. 94

111 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 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 , PHP 5.3 a databázový server MySQL 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 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 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

112 KAPITOLA 5. IMPLEMENTACE Obrázek 5-1: Fyzický model dat 96

113 KAPITOLA 5. IMPLEMENTACE slovnik Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null fraze_id Int(11) Not Null jazyk Varchar(2) Not Null text Text Not Null stav Int(1) Not Null, hodnoty 0-2 typ Varchar(20) 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 Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null role Enum( prodejce, spravce_cms, Not Null manazer, administrator, klient ) prava Varchar(100) Not Null popis Varchar(255) 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). uzivatel Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null uzivatelske_jmeno Varchar(50) Not Null, Unikátní heslo Varchar(40) Null, VP(NULL) jmeno Varchar(50) Not Null prijmeni Varchar(50) Not Null Varchar(100) Not Null telefon Varchar(100) Null, VP(NULL) firma Varchar(50) Null, VP(NULL) Fax Varchar(50) Null, VP(NULL) zeme_id Int(10) Null, VP(NULL), REF(zeme.id) timestamp_registrace Timestamp Not Null, VP(aktuální čas) timestamp_posledni_prihlaseni Timestamp Null, VP(NULL) role_id Int(10) Not Null, REF(uzivatelska_role.id) jazyk_id Varchar(2) Not Null, VP(cz), REF(jazyk.id) adresa Varchar(255) Null, VP(NULL) 97

114 KAPITOLA 5. IMPLEMENTACE komentar Text Null, VP(NULL) narozeniny Varchar(20) Null, VP(NULL) status Enum( visible, invisible, junk ) 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 Datový typ Omezení, upřesnění Id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) Not Null, REF(slovnik.fraze_id) Tabulka 6-4: Databázová tabulka zeme oblast Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null zeme_id Int(11) REF(zeme.id), Not Null Tabulka 6-5: Databázová tabulka oblast mesto Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null oblast_id Int(11) REF(oblast.id), Not Null 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ě. cast_mesta Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null mesto_id Int(11) REF(mesto.id), Not Null Tabulka 6-7: Databázová tabulka cast_mesta 98

115 KAPITOLA 5. IMPLEMENTACE kategorie Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null 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). ubytovani Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null popis_fraze_id Int(11) REF(slovnik.fraze_id),Not Null kategorie_id Int(11) Not Null, REF(kategorie.id) zeme_id Int(11) Not Null, REF(zeme.id) oblast_id Int(11) Not Null, REF(oblast.id) mesto_id Int(11) Not Null, REF(mesto.id) cast_mesta_id Int(11) Not Null, VP(0), REF(cast_mesta.id) Varchar(100) Not Null telefon Varchar(50) Null adresa Text Not Null web Text Null fax Varchar(50) Null gps_souradnice Varchar(50) Null stav Enum( visible, invisible, junk ) Not Null, VP(invisible) koupelna Int(1) Not Null, VP(0) sprcha Int(1) Not Null, VP(0) mycka Int(1) Not Null, VP(0) kuchynka Int(1) Not Null, VP(0) lednicka Int(1) Not Null, VP(0) klimatizace Int(1) Not Null, VP(0) trezor Int(1) Not Null, VP(0) detska_postylka Int(1) Not Null, VP(0) televize Int(1) Not Null, VP(0) radio Int(1) Not Null, VP(0) dvd Int(1) Not Null, VP(0) satelit Int(1) Not Null, VP(0) 99

116 KAPITOLA 5. IMPLEMENTACE telefon_na_pokoji Int(1) Not Null, VP(0) fen Int(1) Not Null, VP(0) minibar Int(1) Not Null, VP(0) konvice Int(1) Not Null, VP(0) zehlicka Int(1) Not Null, VP(0) recepce Int(1) Not Null, VP(0) restaurace Int(1) Not Null, VP(0) pokoj_s_balkonem Int(1) Not Null, VP(0) vytah Int(1) Not Null, VP(0) male_zvire Int(1) Not Null, VP(0) bazen Int(1) Not Null, VP(0) fitnes Int(1) Not Null, VP(0) kongresove_centrum Int(1) Not Null, VP(0) pocet_pokoju Int(3) Null pocet_luzek Int(4) Null pocet_bezbarierovych_pokoju Int(3) Null pocet_kurackych_pokoju Int(3) Null Tabulka 6-9: Databázová tabulka ubytovani typ_pokoje Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null nazev_fraze_id Int(10) REF(slovnik.fraze_id), Not Null 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. produkt Název atributu Datový typ Omezení, upřesnění Id Int(10) PK, AI, Not Null ubytovani_id Int(10) Not Null, REF(ubytovani.id) pocet_lidi Int(2) Not Null typ_pokoje_id Int(10) Not Null, REF(typ_pokoje.id) komentar_fraze_id Int(10) 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

117 KAPITOLA 5. IMPLEMENTACE sekce_ceniku Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null ubytovani_id Int(10) Not Null, REF(ubytovani.id) typ Enum( normal, special, top ) Not Null, VP(normal) popis Text Null Tabulka 6-12: Databázová tabulka sekce_ceniku obdobi_sekce Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null sekce_ceniku_id Int(10) Not Null, REF(sekce_ceniku.id) datum_od Date Not Null datum_do Date Not 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 Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null sekce_ceniku_id Int(10) Not Null, REF(sekce_ceniku.id) produkt_id Int(10) Not Null, REF(produkt.id) cena_brutto Float Not Null mena_brutto Enum( CZK, EUR, USD ) Not Null, VP(CZK) cena_netto Float Not Null mena_brutto Enum( CZK, EUR, USD ) Not Null, VP(CZK) cena_pult Float Not Null mena_pult Enum( CZK, EUR, USD ) 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 Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null nazev_fraze_id Int(11) REF(slovnik.fraze_id), Not Null Tabulka 6-15: Databázová tabulka typ_platby 101

118 KAPITOLA 5. IMPLEMENTACE 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é. rezervace Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null uzivatel_id Int(10) Null, REF(uzivatel.id) kontaktni_jmeno Varchar(50) Null kontaktni_prijmeni Varchar(50) Null kontaktni_ Varchar(50) Null kontaktni_telefon Varchar(50) Null kontaktni_firma Varchar(50) Null jmeno_na_voucher Varchar(50) Null zamestnanci Varchar(100) Null typ_platby Int(10) Null, REF(typ_platby.id) timestamp_vytvoreni Timestamp Not Null, VP(CURRENT_TIMESTAMP) mena_platby Varchar(3) Null, VP(CZK) komentar Text Null komentar_klienta Text Null typ Enum( normal, online ) Not Null, VP(normal) stav Enum( new, request, final, Not Null, VP(new) junk ) aktuální_kurz_czk Double Not Null, VP(0) aktuální_kurz_usd Double Not Null, VP(0) aktualni_kurz_huf Double 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 Rezervace stavy objednávky (REQ = odpovídá bodu 1, PRE = 2, FIX = 3, CH-IN = 4, CH-OUT = 5, CLX = 6, CLX-FIX = 7). objednavka_ubytovani Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null rezervace_id Int(10) Not Null, REF(rezervace.id) ubytovani_id Int(10) Not Null, REF(ubytovani_id) datum_od Date Null datum_do Date Null pocet_dospelych Int(3) Not Null pocet_studentu Int(3) Not Null pocet_deti Int(3) Not Null opce Datetime Null vek_deti Varchar(20) Null typ Varchar(20) Null 102

119 KAPITOLA 5. IMPLEMENTACE stav Enum( REQ, PRE, FIX, Not Null, VP(REQ) CH-IN, CH-OUT, CLX, CLX-FIX ) komentar Text Null Tabulka 6-17: Databázová tabulka objednavka_ubytovani produkt_objednavky Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null objednavka_id Int(10) Not Null, REF(objednavka_ubytovani.iud) produkt_id Int(10) Not Null, VP(0), REF(produkt.id) pocet_noci Int(3) Not Null pocet_produktu Int(3) Not Null, VP(1) cena_netto Double Not Null, VP(0.0) mena_netto Varchar(3) Not Null cena_brutto Double Not Null, VP(0.0) mena_brutto Varchar(3) Not Null datum_od Date Not Null datum_do Date Not Null popis_typu_pokoje Text Not Null komentar Text 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. platba Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null rezervace_id Int(10) Not Null, REF(rezervace.id) objednavka_id Int(10) Not Null, VP(0) kategorie Enum( ubytovani, preprava, Not Null sluzba,ostatni) charakter Enum( predplatba,finalni ) Not Null typ Int(10) Not Null castka Double Not Null poplatky Double Not Null, VP(0) mena Varchar(3) Not Null cas_platby Timestamp Not Null, VP(CURRENT_TIMESTAMP) cislo_karty Varchar(30) Null cislo_autorizace Varchar(30) Null datum_autorizace Timestamp Null datum_kurzu Timestamp Null komentar Text Null 103

120 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í ové 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. partner Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null spolecnost Varchar(100) Not Null adresa Varchar(100) Null fax Varchar(50) Null Varchar(100) Not Null web Varchar(100) Null komentar Text Null informace_o_preprave Text Null Tabulka 6-20: Databázová tabulka partner objednavka_prepravy Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null ridic Varchar(100) Not Null typ Varchar(100) Not Null rezervace_id Int(10) Not Null partner_id Int(10) Not Null datum Date Not Null cas Time Not Null místo_odjezdu Varchar(100) Null konecne_misto Varchar(100) Null jmeno Varchar(50) Null pocet_osob Int(3) Not Null pocet_detskych_sedacek Int(3) Not Null cena_netto Double Not Null mena_netto Varchar(3) Not Null cena_brutto Double Not Null mena_brutto Varchar(3) Not Null cislo_letu Varchar(50) Null komentar Text 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 Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null partner_id Int(10) Not Null, REF(partner.id) nazev_fraze_id Int(10) Not Null 104

121 KAPITOLA 5. IMPLEMENTACE jazyky Varchar(100) Null misto_zacatku Varchar(100) Null misto_konce Varchar(100) Null delka Double Null popis_fraze_id Int(10) Not Null komentar Text Null stav Enum( REQ, PRE, FIX, CH-OUT, CLX ) Not Null, VP(REQ) Tabulka 6-22: Databázová tabulka sluzba sezona_sluzby Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null sluzba_id Int(10) Not Null, REF(sluzba.id) nazev Varchar(50) Not Null datum_od Date Not Null datum_do Date Not Null casy Varchar(100) Null dny_v_tydnu Varchar(30) Null cena_netto_dospely Double Not Null cena_brutto_dospely Double Not Null cena_netto_student Double Null cena_brutto_student Double Null cena_netto_dite Double Null cena_brutto_dite Double Null mena Varchar(3) Not Null max_pocet_osob Int(3) Null Tabulka 6-23: Databázová tabulka sezona_sluzby objednavka_sluzby Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI, Not Null rezervace_id Int(10) Not Null, REF(rezervace.id) sluzba_id Int(10) Not Null, REF(sluzba.id) typ Varchar(50) Not Null datum Date Not Null cas Time Not Null jazyk Varchar(2) Not Null nazev Varchar(100) Not Null pocet_dospelych Int(3) Not Null pocet_studentu Int(3) Not Null pocet_deti Int(3) Not Null cena_netto_dospely Double Not Null cena_brutto_dospely Double Not Null cena_netto_student Double Null cena_brutto_student Double Null cena_netto_dite Double Null cena_brutto_dite Double Null mena_netto_cen Varchar(3) Not Null 105

122 KAPITOLA 5. IMPLEMENTACE mena_brutto_cen Varchar(3) Not Null zaplaceno Enum( yes, no ) Not Null, VP(0) misto_odjezdu Varchar(100) Null misto_navratu Varchar(100) Null komentar Text 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 Datový typ Omezení, upřesnění id Varchar(2) PK, Not Null poradi Int(2) 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 Datový typ Omezení, upřesnění id Varchar(100) PK, Not Null nadpis_fraze_id Int(10) Not Null, REF(slovnik.fraze_id) text_fraze_id Int(10) Not Null, REF(slovnik.fraze_id) typ Enum( system, normal ) Not Null, VP(normal) Tabulka 6-26: Databázová tabulka cms Tabulka eviduje všechny odeslané y 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í u. Název atributu Datový typ Omezení, upřesnění id Int(10) PK, AI,Not Null _odesilatele Varchar(100) Not Null _prijemce Varchar(100) Not Null predmet Text Not Null zprava Text Not Null typ Varchar(50) Null timestamp Timestamp Not Null, VP(CURRENT_TIMESTAMP) rezervace_id Int(10) Null, REF(rezervace.id) objednavka_id Int(10) Null typ_objednavky Enum( ubytovani, sluzba, Null preprava ) Tabulka 6-27: Databázová tabulka 106

123 KAPITOLA 5. IMPLEMENTACE kurz Název atributu Datový typ Omezení, upřesnění mena Varchar(3) PK, Not Null koeficient Double Not Null datum_platnosti Date PK, Not Null Tabulka 6-28: Databázová tabulka kurz typ_logu Název atributu Datový typ Omezení, upřesnění id Int(11) PK, Not Null popis Text Not Null Tabulka 6-29: Databázová tabulka typ_logu log Název atributu Datový typ Omezení, upřesnění id Int(11) PK, AI, Not Null popis Text Not Null cas Timestamp Not Null, VP(CURRENT_TIMESTAMP) uzivatel_id Int(10) Not Null, REF(uzivatel.id) rezervace_id Int(10) Null, REF(rezervace.id) objednavka_id Int(10) Null typ_objednavky Enum( ubytovani, sluzba, preprava ) 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í) Vlastní implementace Implementaci lze rozdělit podle různých kriterií. Základní dělení bych popsal takto: Tvorba vzhledu 107

124 KAPITOLA 5. IMPLEMENTACE o 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í. Vypsané části se při programování většinou překrývají a doplňují, ale lze je i implementovat jako samostatné části 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

125 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í Struktura aplikace, programové skripty 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

126 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. control address( ) Kontrola správného tvaru ové adresy. safetystring(hodnota) Vrací upravenou hodnotu vstupní proměnné (odstraňuje prázdné znaky a převádí HMTL znaky). 110

127 KAPITOLA 5. IMPLEMENTACE 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í , 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

128 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í, , 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 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

129 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 V šabloně Význam a funkce accommodation_form accommodation_form.tpl Správa ubytování accommodation_pricelist accommodation_pricelist.tpl Správa ceníku pro ubytování accommodation_search accommodation_search.tpl Vyhledávání ubytování ajax_res_order_change ajax_res_order_change.tpl Změna stavu objednávky rezervace Categories settings_category.tpl Správa kategorií ubytování cms_add cms_add.tpl Vložení článku do cms a slovníku cms_list cms.tpl Zobrazení seznamu článků z cms Countries settings_countries.tpl Správa zemí if_rights - Informace o přihlášeném uživateli pro smarty funkci if_rights index_settings index.tpl Hlavní plugin, základní nastavení Login index.tpl Přihlášení, odhlášení, testování přihlášení uživatele Oblasti settings_oblast.tpl Správa oblastí zemí partner_form partners.tpl Správa partnerů res_add_accommodation res_add_accommodation.tpl Správa ubytování k rezervaci res_add_order_product res_add_order_product.tpl Správa produktů objednávky ubytování res_edit_user res_edit_user.tpl Správa kontaktních údajů uživatele v rezervaci res_choose_user res_choose_user.tpl Nalezení a přidání uživatele k rezervaci res_payment_form res_payment_form.tpl Správa plateb k rezervaci res_service_form Správa služeb k rezervaci Reservation reservation.tpl Nalezení všech informací o rezervaci, výpočet finálních plateb za objednávky reservation_accommodation reservation_accommodation. tpl Získání informací o ubytování k rezervaci reservation_client reservation_client.tpl Získání informací o klientovi k rezervaci reservation_payment reservation_payment.tpl Získání informací o platbách k rezervaci reservation_service reservation_service.tpl Získání informací o službách k rezervaci reservation_sum reservation_sum.tpl Výpočet platebního sumáře kolik je třeba zaplatit, kolik je zaplaceno, 113

130 KAPITOLA 5. IMPLEMENTACE reservations reservations.tpl Získání seznamu rezervací dle parametrů reservations_search reservations_search.tpl Vyhledávání v rezervacích service_form service_form.tpl Správa služby services services.tpl Seznam služeb towns settings_towns.tpl Správa měst towns_part settings_towns_part.tpl Správa částí města user user.tpl Správa uživatele user_add user_add.tpl Přidání uživatele users users.tpl Seznam a vyhledávání uživatelů Šablony (smarty šablony) Tabulka 5-32: Seznam pluginů 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 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 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 114

131 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 user.tpl user_add.tpl users.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ů Tabulka 5-33: Seznam šablon 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ší 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

132 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

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

134 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 T F T T T T T T 0 0 T T UC002 T T T T T UC004 T T T F T T T T 0 T T 0 UC005 T T T F T T T T 0 T T F UC006 T T F F 0 T T T F T T F UC007 T T T 0 T F T T F UC008 T T T 0 T T T 0 0 T T T UC009 T T T 0 T T T T F 0 0 F UC011 T T T T T T T T 0 T T T UC012 T T T F T T T 0 0 T T T UC013 T T T T 0 T T 0 T 0 0 F UC014 T T T 0 T T T T T UC015 T F T T T T T T 0 T 0 F UC016 T T T T T T T T T UC018 T T T T T F T 0 0 T F T UC019 T F F T T F T 0 0 T T T UC020 T T T F T F T 0 T T T T UC021 T T F F T F T 0 0 T T F 118

135 KAPITOLA 6. TESTOVÁNÍ UC022 T T T T T T T T 0 T T T UC023 T T T F T F T 0 T T T T UC027 T T T F T F T 0 0 T T T UC028 T T T 0 T F T F UC030 T T T 0 T T T T T UC031 T T T T T T T 0 0 T T F UC032 T F T T T T T 0 0 T T T UC033 T T T T T T T 0 T 0 0 T UC034 T T T T T T T 0 0 F F F UC035 T T T T T T T 0 0 T T F UC036 T T T F T T T 0 0 F T F UC037 T T T F T T T 0 F T T F UC038 T T T T 0 0 T T T UC040 v době testování nebyl tento případ užití naimplementován UC041 v době testování nebyl tento případ užití naimplementován UC042 v době testování nebyl tento případ užití naimplementován UC046 T T T T T 0 T T T T T T UC047 T T F F T 0 T 0 0 F F T UC048 T F F F T 0 T 0 0 F F T UC049 T T T T T 0 T 0 T 0 T T UC050 T T T 0 T T T T 0 T 0 T UC051 T T T 0 T F T T T UC052 T T T T T T T T 0 T 0 F UC053 T T T T T F T 0 0 T T T UC054 T T T 0 T T T T T UC055 T T T 0 T T T T T UC056 T T T F T T T 0 0 T T T UC057 T T T T T T T 0 0 F T T UC058 T T T 0 T T T T T UC059 v době testování nebyl tento případ užití naimplementován UC060 T T T 0 T T T T T UC061 T T T T T F T T 0 T T T UC062 T T T T T T T 0 T 0 0 T Vyhodnocení Tabulka 6-1: Testování aplikace jako celku. UC001 o 2-3x špatně zadané heslo nezablokovalo účet. UC004 o 4 Systém neinformoval uživatele o přidání. UC005 o 4 Systém neinformoval uživatele o editaci údajů. o 12 Chybí odkaz na návrat na předchozí stránku na stránce editace údajů. 119

136 KAPITOLA 6. TESTOVÁNÍ UC006 o o UC007 3,9 Po stisknutí tlačítka Delete se systém nezeptal uživatele, ale rovnou ho odstranil. 4 Po smazání nebyl uživatel informován o úspěšném provedení požadavku. o o UC009 o o UC012 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. 9 Po stisknutí odkazu se systém nezeptá, zda opravdu odstranit uživatele, ale přímo ho odstraní. 12 Zobrazují se i odstranění uživatelé (označení junk ). 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

137 KAPITOLA 6. TESTOVÁNÍ 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. o 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 UC037 o 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. 4 Systém neinformuje uživatele o odstranění produktu (mohl by být problém při větším počtu produktů) 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

138 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 Testování přístupnosti Testování přístupnosti systému bylo testováno podle popsaných pravidel v kapitole (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á Testování přístupnosti Pro testování přístupnosti jsem si zvolil webový prohlížeč Mozilla Firefox 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 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

139 KAPITOLA 6. TESTOVÁNÍ Co Barva Barva písma Rozdíl Rozdíl jasu pozadí barev Levé hlavní menu, text #414C8C #FFFFFF Tabulky, formuláře #FFFFFF # Levé menu a označené žluté #414C8C #FFCC odkazy Hlavička tabulek, rezervace #CCCCFF # hlavičky tabulek, rezervace nová okna Obsahové menu základní barva a černé písmo #78AFE # 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

140 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 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 Testování použitelnosti Pravidla a cíl testování Co je to použitelnost již bylo popsáno v kapitole 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

141 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í Výběr testerů 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) 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í Otázka č. 1 Otázka č. 2 Otázka č. 3 Otázka č. 4 Otázka č. 5 Otázka č. 6 - Věk Zkušenosti Používání Zdravotní Zkušenosti Používání s webovým rezerv. problémy, s PC PC prohlížečem systému jiné Č Expert Expertní > 3h denně Ano Ne Č Průměrné Vysoké > 3h denně Ne Ne Č 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 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

142 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 Ú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 len 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 em 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 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 do 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 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 č

143 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 , odjezd nejdéle 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ě ovou 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 č

144 KAPITOLA 6. TESTOVÁNÍ 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í 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

145 KAPITOLA 6. TESTOVÁNÍ 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

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

147 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

148 KAPITOLA 7. ZÁVĚR 132

149 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 h [2] Pravidla tvorby přístupného webu, [Online], Poslední revize < > [3] Smarty template engine, [Online]. < [4] Oficiální dokumentace PHP, [Online], Poslední revize < [5] Usability (official U.S. Government Web site managed by the U.S. Department of Health & Human Services), [Online], Poslední revize < [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 < [8] Wikipedia EN - Unified Modeling Language, [Online], Poslední revize < [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 < [11] w3.org : Web Content Accessibility Guidelines (WCAG) 2.0, W3C Recommendation. [Online], Poslední revize < [12] Wikipedia.org: Software Testing. [Online], Poslední revize

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

151 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

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

153 PŘÍLOHA B. TESTOVÁNÍ POUŽITELNOSTI - DOTAZNÍKY B Testování použitelnosti dotazníky B.1 Předtestový dotazník 1. Jaký je Váš věk? a více 2. Jaké máte zkušenosti s prací na PC? Žádné Základní Průměrné Vysoké (např. živím se prací s PC) Expertní (např. programuji) 3. Jaké máte zkušenosti s prací s webovým prohlížečem? Žádné (nepoužívám internetový prohlížeč) Základní (používám webový prohlížeč pro čtení ů ů a zpráv na internetu aj.) Vysoké (používám více funkcí na internetu, využívám vyhledávače, nakupuji přes e-shopy,...) Expertní (programátor webových aplikací aj.) 4. Jak často používáte počítač? Vůbec 1x týdně 1x denně 1-3 hodiny denně více jak 3 hodiny denně 5. Používal (a) jste někdy nějaký rezervační systém? Ne Ano, mám malé zkušenosti Ano, mám pokročilé zkušenosti 6. Máte nějaké zdravotní problémy 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

154 PŘÍLOHA B. TESTOVÁNÍ POUŽITELNOSTI - DOTAZNÍKY B.2 Potestový dotazník (známkujte stejným způ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á? Jak hodnotíte vzhled aplikace? Bylo pro Vás barevné provedení příjemné? Změnil (a) byste něco na vzhledu aplikace či uspořádání jednotlivých částí? Co by to bylo? 4. Jak hodnotíte systém nápověd? Byla pro vás nápověda přínosem? Byly pro Vás formuláře v aplikaci přehledné? Pokud ne, popište, co byste změnil (a) Jaká část aplikace pro Vás byla nejméně přehledná a s kterou jste měl (a) nejvíce problémů při práci. 7. Měl (a) jste při práci se systémem problém při přečtení nějakého testu? Případně jak jste to řešil (a)? 8. Přišla Vám stránka s detailem rezervace přehledná? Uspořá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á funkce, která by např. mohla zlepšit či urychlit práci se systémem? 10. Jiné připomínky k systému (zde prosím popište ostatní připomínky k systému, které neobsáhly předchozí otázky). 138

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

156 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

157 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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, , 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

158 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA C.5.2 Prohlížení seznamu uživatelů Obrázek C-4: Formulář pro přidání nového uživatele. 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

159 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. C.5.4 Změna uživatelských údajů Obrázek C-6: Informace o uživateli 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

160 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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

161 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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

162 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. C.7.2 Přidání sekce ceníku Obrázek C-10: Ceník Správa pokojů ubytovacího zařízení. 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

163 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

164 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. C.8.2 Správa rezervace Obrázek C-13: Stránka s novou rezervací 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

165 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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

166 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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í, ová 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

167 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Obrázek C-16: Rezervace Objednávka ubytování. Obrázek C-17: Rezervace Formulář pro editaci objednávky ubytování. 151

168 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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

169 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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

170 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 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 ová adresa Firma Název ubytování Stav rezervace Datum příjezdu Datum odjezdu Některé parametry lze mezi sebou kombinovat. 154

171 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Pro vyhledávání podle rezervačního čísla, jména, u, 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