Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky

Vyšší odborná škola informačních služeb v Praze

Pavel Přibyl

Návrh a implementace rezervačního systému vhodného pro transfuzní stanice

Bakalářská práce

2009

Poděkování

Děkuji vedoucímu práce Ing. Davidu Viochnovi za pomoc a podporu během

tvorby práce, za vstřícný a přátelský přístup při řešení nejrůznějších problémů. Zároveň

děkuji RNDr. Romanu Ondruškovi ze společnosti SUN Microsystems za přínosné

konzultace v otázkách uživatelského rozhraní. V neposlední řadě děkuji rodině

a přátelům za podporu a trpělivost.

Prohlášení

Prohlašuji, že jsem bakalářskou práci na téma „Návrh a implementace

rezervačního systému vhodného pro transfuzní stanice“ zpracoval samostatně a použil

pouze zdrojů, které cituji a uvádím v seznamu použité literatury.

V Praze dne 1.5.2009

Abstrakt Cílem práce je návrh a implementace on-line rezervačního systému vhodného

pro transfuzní stanice. Vzhledem ke specifickým požadavkům na systém je třeba

vytvořit vlastní řešení, nelze tedy použít stávající univerzální komerční aplikace.

Praktickou část tvoří samotná aplikace, resp. její zdrojový kód. Ten je vytvořen

s použitím technologií PHP, MySQL, XHTML, CSS a JavaScript.

Teoretická část popisuje způsob využití těchto technologií, specifikaci

požadavků a návrh systému. Pro modelování systému jsou využity UML diagramy.

Výsledkem práce je funkční webová aplikace s dokumentací. Tato aplikace je

využitelná pro praktické nasazení v transfuzních stanicích.

Abstract Objective of this work is to design and implement on-line reservation system

suitable for use in transfusion station. Due to the specific requirements for the system it

is necessary to create own solution, it is not possible to use universal commercial

applications.

Practical part of this work is the web application itself, respectively its source

code. It is created with the use of following technologies: PHP, MySQL, XHTML, CSS

and JavaScript.

The theoretical part describes how the technologies are used, the requirement

specification and system design. For modelling of the system are used UML diagrams.

Result of this work is functional web application with documentation. The

application is usable for practical use in transfusion station.

- 6 -

1. Obsah 1. Obsah ............................................................................................................................6

2. Úvod..............................................................................................................................8

2.1. Rezervační systém pro transfuzní stanici...............................................................9

3. Použité metody a technologie .....................................................................................10

3.1. PHP ......................................................................................................................10

3.1.1. Způsob využití...............................................................................................10

3.1.2. Přednosti jazyka ............................................................................................11

3.1.3. Objektově orientované programování v PHP ...............................................11

3.2. XHTML ...............................................................................................................12

3.3. CSS.......................................................................................................................12

3.4. JavaScript .............................................................................................................13

3.4.1. AJAX ............................................................................................................13

4. Návrh systému.............................................................................................................14

4.1. Specifikace požadavků.........................................................................................14

4.1.1. Funkcionalita.................................................................................................14

4.1.2. Uživatelé .......................................................................................................15

4.1.3. Základní postupy a pravidla používání .........................................................16

4.1.4. Data ...............................................................................................................17

4.2. Případy užití .........................................................................................................18

4.2.1. Doplňující charakteristiky.............................................................................19

4.3. Modely .................................................................................................................20

4.3.1. Přihlášení uživatele do systému (Diagram aktivit) .......................................20

4.3.2. Zápis rezervace (Diagram aktivit).................................................................21

4.3.3. Diagram tříd ..................................................................................................22

4.3.4. Sekvenční diagram........................................................................................24

4.3.5. Stavový diagram............................................................................................25

4.3.6. Diagram nasazení ..........................................................................................26

4.3.7. ERA diagram.................................................................................................27

- 7 -

5. Implementace ..............................................................................................................28

5.1. Serverová část aplikace........................................................................................28

5.1.1. Pomocné třídy ...............................................................................................29

5.1.2. Přihlášení uživatele .......................................................................................30

5.1.3. Vytvoření rozvrhů .........................................................................................30

5.1.4. Generování tabulek rozvrhů..........................................................................32

5.1.5. Časové razítko...............................................................................................33

5.1.6. Zaznamenávání rezervace .............................................................................34

5.1.7. Nastavení systému.........................................................................................35

5.1.8. Použité návrhové vzory.................................................................................36

5.1.9. Zabezpečení...................................................................................................37

5.2. Klientská část aplikace.........................................................................................39

5.2.1. Uživatelské rozhraní......................................................................................39

5.2.2. Ovládací prvky..............................................................................................41

5.2.3. Asynchronní dotazy ......................................................................................43

5.3. Testování aplikace................................................................................................45

6. Závěr ...........................................................................................................................46

6.1. Zhodnocení splnění požadavků............................................................................46

6.2. Budoucnost systému ............................................................................................47

7. Seznam použitých zdrojů ............................................................................................48

8. Seznam obrázků ..........................................................................................................50

9. Seznam příloh..............................................................................................................51

- 8 -

2. Úvod Cílem této práce je vytvořit „engine“, neboli funkční jádro on-line rezervačního

systému tak, aby vyhovoval specifickým požadavkům pro nasazení v transfuzní stanici.

Základem práce proto bude návrh databáze a aplikační části systému.

Následujícím krokem bude implementace, tj. vytvoření webové aplikace v jazyce PHP

s využitím MySQL databáze.

Přestože těžištěm bude serverová část aplikace, tedy samotná aplikační logika,

součástí práce bude i vytvoření vhodného uživatelského rozhraní. Pro tyto účely bude

využit jazyk XHTML, styly CSS a jazyk JavaScript.

Výsledná aplikace by měla být snadno modifikovatelná. Uživatel, resp. správce

systému bude schopen upravit její parametry tak, aby odpovídaly konkrétním potřebám

stanice. Díky tomu by pak aplikace měla být snadno rozšiřitelná do více transfuzních

stanic, bez nutnosti zasahovat do jejího zdrojového kódu.

Tato práce je vytvářena ve spolupráci se společností Baxter BioScience, působící

v oblasti zpracování krevní plazmy. V případě úspěšného dokončení bude rezervační

systém nabídnut k využívání v transfuzních stanicích, se kterými společnost

spolupracuje.

- 9 -

2.1. Rezervační systém pro transfuzní stanici Hlavní význam rezervačních systémů spočívá v možnosti zaznamenávat,

uchovávat a zpracovávat údaje o rezervacích jednotlivých uživatelů.

Nejčastější využití pak nacházejí v oblasti dopravy (rezervace jízdenek), sportu

(rezervace sportovišť, např. tenisových kurtů), kultury (vstupenky) apod. Systémy pak

mohou být navrhovány „na míru“, tj. účelně pro konkrétní nasazení, nebo univerzálně,

s možností využití na více místech.

I tato univerzální řešení se však vždy zaměřují na konkrétní oblast. Zatímco

např. pro sportovní zařízení existuje řada již hotových rezervačních systémů, jejich

nasazení v transfuzní stanici je poměrně nepraktické.

Systém pro transfuzní stanici musí mimo jiné počítat s řadou omezení, která jsou

spojena s darováním krve a krevní plazmy. Například se jedná o stanovení intervalu

mezi dvěma rezervacemi, během kterého nelze rezervace provádět. Zatímco systém pro

rezervaci tenisových kurtů zcela jistě umožňuje rezervovat si kurt na dvě hodiny ihned

po sobě, v případě transfuzní stanice musí být uživatelův výběr omezen.

Dostupné univerzální rezervační systémy pak často zahrnují i řešení finančních

otázek, tedy například výpočet ceny v závislosti na čase rezervace, možnosti platby on-

line apod. Pro nasazení v podmínkách transfuzní stanice je však tato funkcionalita

nadbytečná, resp. nežádoucí.

Z těchto důvodů se tedy jeví jako výhodnější vytvořit systém nový, který bude

již od začátku koncipován právě s přihlédnutím k těmto specifickým požadavkům.

- 10 -

3. Použité metody a technologie Serverová část aplikace bude vytvořena s využitím objektově orientovaného

programování v jazyce PHP. Samotnému vývoji bude předcházet návrh a modelování

systému s využitím UML jazyka.

Klientská část bude tvořena XHTML webovými stránkami, tvořenými v souladu

se standardy W3C [23]. Funkcionalita bude podpořena použitím skriptovacího jazyka

JavaScript a technologie AJAX. Grafická úprava a rozložení prvků stránky budou

zajištěny využitím kaskádových stylů CSS.

3.1. PHP PHP je open-source programovací jazyk, určený především pro tvorbu

webových stránek a aplikací. Za více než deset let své existence se PHP vyvinulo z

„okrajového“ jazyka, který byl využíván pro přidání dynamické funkcionality webovým

stránkám, na výkonný nástroj pro vývoj rozsáhlých aplikací.

Jeho popularita je způsobena zejména snadností použití, rychlým osvojením

základních funkcí, široké podpoře (jak ze strany významných vývojářů a poskytovatelů

webových hostinců, tak i ze strany početné komunity) a v neposlední řadě jeho cenou.

Je totiž zcela zdarma.

3.1.1. Způsob využití

PHP bylo navrženo (a dodnes je nejčastěji využíváno) pro spouštění a běh

skriptů generujících webový obsah, nejčastěji tedy HTML kódu. Výstupem těchto

skriptů však může být například i XML dokument, grafika, PDF soubor, flashová

animace apod. K uživateli, resp. na klientskou část aplikace, je pak přenesen již jen

výsledek činnosti skriptu. Uživatel tak nemá možnost prohlédnout si zdrojový kód

původního skriptu.

PHP skripty lze spouštět i bez běžícího serveru, z příkazové řádky. Tento přístup

bývá využíván spíše pro administrační účely, ladění skriptů a hledání chyb.

S pomocí PHP lze vytvořit rovněž i aplikace s grafickým uživatelským

rozhraním, které běží na straně klienta. Pro tyto účely je třeba nainstalovat grafické

rozšíření GTK+, například PHP-GTK

- 11 -

3.1.2. Přednosti jazyka

Jednou z důležitých vlastností je nezávislost na použité platformě. Všechny

zmíněné způsoby využití lze bez rozdílu provozovat na operačních systémech

Windows, MacOS, a různých UNIXových distribucích.

Předností PHP je pak široké spektrum podporovaných databází, se kterými může

spolupracovat. Umožňuje tak obsluhu všech významných databázových systémů:

MySQL, PostgreSQL, Oracle, Sybase, a ODBC, ale i řadu dalších (např. SQLite).

Díky zmiňované široké podpoře již existuje nepřeberné množství zdrojů,

kterých mohou uživatelé využívat. Jedná se jak o řadu teoretických zdrojů (návody,

doporučení, tipy a triky), tak o volně dostupná hotová řešení. Mezi tyto pak patří

nejrůznější knihovny s využitelnými funkcemi, připravené třídy nebo tzv. frameworky -

softwarové struktury obsahující nástroje pro usnadnění a urychlení vývoje aplikací.

3.1.3. Objektov ě orientované programování v PHP

Podpora OOP se v jazyce PHP objevila až s verzí 4. Jednalo se o zatím pouze

o základní principy. Programátor mohl mimo jiné definovat a využívat vlastní třídy,

jejich atributy a metody. Stále však chyběla podpora pro některé způsoby užití. Např.

zcela chyběla podpora modifikátorů přístupu, známých z jiných objektově

orientovaných či hybridních jazyků. Dále chyběla možnost použití abstraktních tříd.

Všechny tyto nedostatky však odstranila verze PHP 5.

Peter Lavin [10] popisuje původní nedůvěru ze strany programátorů a tvůrců

webových aplikací k využívání objektových principů v PHP. Zejména právě slabá

podpora ve verzi 4 jen utvrzovala názor některých, že PHP by mělo zůstat čistě

skriptovacím jazykem a využívat procedurální postupy.

V současné době je však využití OOP prakticky samozřejmostí. Jedním

z důvodů jsou jistě zmiňovaná vylepšení ve verzi 5, ale hlavně přijetí samotné podstaty

tohoto způsobu programování. To zajišťuje snadnou modifikovatelnost aplikací,

znuvupoužitelnost konkrétních řešení, snazší a intuitivnější návaznost na UML modely

atd.

Především však PHP jakožto hybridní jazyk umožňuje stále používat oba

způsoby programování. Programátor tak může využívat čistě procedurální přístup,

objektový přístup, nebo vhodnou kombinaci obojího.

- 12 -

3.2. XHTML XHTML je jazyk pro tvorbu hypertextových dokumentů. Oproti klasickému

HTML značkovacímu jazyku je patrné propojení určitých principů a pravidel pro zápis

kódu s jazykem XML. Vývoj a definici pravidel a standardů zajišťuje konsorcium W3C.

Validní dokument tak musí obsahovat odkaz na použitou definici DTD. Může

být použita standardní definice W3C, uživatel si však může vytvořit vlastní DTD

a používat tak při psaní dokumentu vlastní značky (tagy) a jejich strukturu.

Oproti HTML se liší i některá pravidla pro zápis kódu. Zatímco HTML

umožňuje použití neuzavřených nepárových tagů (např. <br>, <hr>, <img>) ,

v XHTML musí být i tyto tagy uzavírány. A to buď odpovídajícím uzavíracím tagem

(</br>, </hr>, </img>) , nebo pomocí zkráceného zápisu, např. <br />.

Další pravidla, mimo jiné zákaz křížení tagů nebo povinnost udávat hodnoty

atributů v uvozovkách, jsou obsaženy v dokumentaci W3C [23].

Dodržováním standardů pro zápis validních dokumentů by mělo být zajištěno

korektní zobrazení stránek ve všech moderních prohlížečích.

3.3. CSS Použití kaskádových stylů (CSS, cascading style sheet) umožňuje upravovat

vzhled stránek napsaných v (X)HTML. Je možné zapisovat kaskádové styly přímo do

zdrojového kódu stránky, případně do atributu style jednotlivých tagů. Nejčastěji se

však používá způsob zápisu CSS do odděleného souboru, čímž se výsledný kód značně

zpřehlední.

Pomocí kaskádových stylů lze měnit způsob zobrazení jednotlivých (X)HTML

elementů, případně lze definovat vlastní třídy a přiřazovat jim konkrétní vlastnosti.

Různé elementy se pak mohou přihlašovat k těmto třídám pomocí atributu class.

Zobrazení jednotlivých elementů lze rovněž upravovat přes jejich atribut id.

Styly umožňují definovat nejrůznější možnosti zobrazení. Kromě ovlivnění

barvy textu, použitého fontu, nebo obrázku pozadí bývají kaskádové styly často

využívány i pro určení rozložení jednotlivých prvků na stránce a definování celkové

struktury zobrazeného dokumentu.

Rovněž lze měnit použité styly v závislosti na konkrétním zobrazovacím médiu.

Lze tedy jinak formátovat dokument pro zobrazení na monitoru a jinak pro tisk.

- 13 -

3.4. JavaScript Hlavní předností skriptovacího jazyka JavaScript je to, že je interpretován až na

straně klienta, tedy v internetovém prohlížeči. Tím umožňuje přenést část zátěže ze

serveru a prohlížeč se stává tzv. „tlustým“ klientem. Ten neslouží již pouze k zobrazení

výstupů, ale sám se podílí na vykonávání částí kódu aplikace.

Skripty v jazyce JavaScript (zkráceně označovány jako „javascripty“) tak mohou

například kontrolovat údaje odeslané z webového formuláře nebo ovládat nejrůznější

interaktivní prvky (tlačítka, zaškrtávací políčka, textové vstupy).

Javascripty umí přistupovat k jednotlivým elementům HTML kódu, měnit

vlastnosti jejich atributů nebo kaskádových stylů. To přispívá ke značnému zvýšení

interakce stránek a přiblížení dojmu klasické „desktopové“ aplikace.

Nevýhodou využití tohoto jazyka je zejména fakt, že uživatel může podporu

JavaScriptu ve svém prohlížeči vypnout. Často je tak činěno z bezpečnostních důvodů.

Stránky pak mohou zcela přestat fungovat, nebo fungují s určitými omezeními. Dalším

problémem je odlišná podpora v internetových prohlížečích. Je proto třeba kód

optimalizovat pro různá prostředí a aplikaci testovat nejen na různých prohlížečích, ale

i na různých verzích jednoho typu prohlížeče (skripty se mohou chovat jinak v Internet

Exploreru 6 a jinak v Internet Exploreru 7).

Základní postupy při psaní javascriptů jsou popsány v odborných textech

a učebnicích [1][13][17][21]. Otázky spojené s kompatibilitou v různých prohlížečích

a řešením konkrétních problémů bývají probírány na odborných webových serverech

a v internetových diskusích [8].

3.4.1. AJAX

Jedním z nejčastějších způsobů využití javascriptů je v současné době

technologie AJAX a metody asynchronní komunikace se serverem.

Zatímco původní přístup pro tvorbu dynamických webových stránek a aplikací

vyžadoval po odeslání jakéhokoliv dotazu na server znovunačtení celé stránky,

s využitím AJAXu prohlížeč odesílá a přijímá pouze části stránky, které je potřeba

změnit.

- 14 -

4. Návrh systému

4.1. Specifikace požadavk ů Zadavatelem požadavků byl ing. David Viochna, MSc. ze společnosti Baxter

BioScience spol. s r.o.

Tato společnost se zabývá produkcí derivátů vyráběných z krevní plazmy.

Zároveň je i výrobcem technologií pro odběr a separaci krve.

Díky tomu, že společnost spolupracuje s řadou tuzemských transfuzních stanic,

bylo možné shromáždit a vyhodnotit požadavky z většího množství konkrétních

pracovišť.

4.1.1. Funkcionalita

Systém bude podporovat procesy spojené s rezervací termínů odběru plazmy

v transfuzní stanici. Kromě evidence uživatelových rezervací bude systém generovat

základní statistické přehledy (počet rezervací, využití jednotlivých separátorů apod.).

Systém bude umístěn na veřejně dostupném webovém serveru, uživatelé k němu

budou přistupovat přes internet prostřednictvím libovolného internetového prohlížeče.

Doba kdy je možné do systému přistupovat nebude nijak omezena.

Klient – dárce krevní plazmy – bude své rezervace zadávat sám, prostřednictvím

grafického uživatelského rozhraní. Pro tento účel bude muset mít zřízen uživatelský

účet s jedinečnými přihlašovacími údaji. Bude však podporována i možnost zapsání

dárcovy rezervace zaměstnancem transfuzní stanice (na základě osobní žádosti, nebo po

telefonické dohodě).

Aplikace bude navržena univerzálně, s nastavitelnými parametry, aby mohla být

snadno nasazena do různých stanic. Případné modifikace, opravy a rozšíření systému

bude možné aplikovat i během aktivního provozu, bez hrozby ztráty dat.

- 15 -

4.1.2. Uživatelé

Aplikace bude mít 3 kategorie uživatel:

• Klient (dárce) – bude mít možnost zapsat (případně i zrušit) vlastní rezervaci,

zobrazovat přehledy a statistiky svých rezervací a upravit vlastní nastavení

• Recepce – zaměstnanec transfuzní stanice. Bude mít přístup k pokročilejšímu

nastavení, možnost vytvářet uživatelské účty, zakládat a rušit rezervace jiných

uživatelů

• Správce – Mimo možností, které má „Recepce“, bude mít možnost nastavit

základní parametry systému, určovat otevírací dobu a rozvrhy jednotlivých

separátorů

Uživatelé mohou mít různě vysokou úroveň zkušenosti práce s informačními

technologiemi. Zatímco zaměstnanci stanice budou při instalaci systému proškoleni

v jeho využívání, klienti se s ním setkají poprvé až během užívání. Proto je nezbytné,

aby ovládání bylo intuitivní a přehledné, zároveň musí mít uživatel vždy k dispozici

nápovědu.

Přestože se u aplikace tohoto typu nepředpokládá úmyslné zneužití, je třeba

vytvořit bezpečnostní opatření, která by znemožnila byť i neúmyslné ohrožení

bezpečnosti, zneužití osobních údajů uživatelů, případně ztrátu dat. Za tímto účelem

bude aplikace obsahovat mimo jiné tato bezpečnostní opatření:

• Přihlášení pomocí e-mailu a hesla. Toto heslo nebude nikde zaznamenáno. Při

ztrátě nebo zapomenutí si bude klient muset vygenerovat heslo nové. Systém

bude odhlašovat neaktivní uživatele po uplynutí časového intervalu

• Kontrola odesílaných dat. Jelikož je aplikace založena na interakci s uživatelem,

je nutné kontrolovat všechny uživatelovy vstupy – např. data odeslaná pomocí

formulářů, ale i parametry předávané v URL adrese

• Evidence pouze nejnutnějších osobních údajů. Vzhledem k povaze systému

postačí zaznamenávat pouze základní osobní údaje – jméno, příjmení, e-mail,

případně i telefonní číslo

- 16 -

4.1.3. Základní postupy a pravidla používání V systému se budou uplatňovat následující pravidla a postupy:

A, Provádění rezervací

• Klient se může zapsat pouze na budoucí termíny

• Systém bude zobrazovat počet volných separátorů. Uživatel si může rezervovat

pouze termíny s alespoň jedním volným separátorem. Systém musí zabránit

konfliktu při zapisování dvou uživatelů na jeden separátor ve stejný čas

• Mezi dvěma rezervacemi jednoho klienta musí být (nastavitelný) interval,

během kterého nelze zapsat další rezervace

• Uživatel si bude moci rezervovat termín i na delší dobu dopředu. Délka této

doby bude limitovaná podle potřeb a požadavků transfuzní stanice

B, Vytváření a správa uživatelských účtů

• Klienti si sami nebudou moci vytvářet uživatelské účty. Ty jim budou vytvořeny

zaměstnancem transfuzní stanice

• Jako přihlašovací údaje bude sloužit e-mailová adresa a heslo. Uživatel si bude

moci sám změnit pouze heslo, adresu nikoliv. Tu to možnost bude mít pouze

správce systému

• Klient si sám nebude moci změnit osobní údaje (jméno a příjmení)

C, Nastavení parametrů systému

• Bude možné nastavit otevírací dobu celé stanice, stejně jako individuální rozvrh

pro jednotlivé separátory

• Kromě běžného rozvrhu bude možné nastavit mimořádný rozvrh, např. během

státních svátků, dovolených a mimořádných událostí

• Aplikace bude umožňovat nastavení jména a loga stanice, uvítací zprávy a

kontaktů

• Tato nastavení bude moci provádět pouze uživatel s administrátorskými právy

- 17 -

4.1.4. Data

Množství dat procházejících systémem do značné míry závisí na velikosti

stanice, ve které bude systém nasazen, resp. na počtu dárců kteří ji navštěvují.

Informace o rezervacích totiž představují největší část zpracovávaných dat. Další data

budou tvořit informace o rozvrzích jednotlivých separátorů, a to jak pravidelných, tak

mimořádných.

Předpokládané hodnoty:

Průměrný počet separátorů v jedné stanici ............... 8-10

Uživatelů v databázi ................................................. 1000

Průměrný počet rezervací 1 uživatele ...................... 1 za 3 týdny

Omezení počtu rezervací .......................................... maximálně 35 za rok

Pokud by každý dárce důsledně dodržoval počet 35 rezervací ročně, přibývalo

by do databáze rezervací 35 000 záznamů ročně. Tato situace je však pouze čistě

teoretická, takže hodnota je brána spíše jako horní limit.

Podobným způsobem lze určit limitní hodnotu pro počet uložených rozvrhů

separátorů.

Pokud by na každý den v roce připadal mimořádný rozvrh stanice a každý

separátor by měl unikátní rozvrh, tvořilo by data o rozvrzích 365 x 8 = 2920 záznamů.

Na druhou stranu pokud by platil po celý rok stejný rozvrh pro všechny

separátory, postačilo by pro zápis takové situace pouze 7 záznamů (na každý den

v týdnu by připadal jeden rozvrh).

- 18 -

4.2. Případy užití Následující diagram popisuje možnosti, které bude systém uživatelům poskytovat.

Obr. 4.1. - Use case diagram

- 19 -

4.2.1. Doplňující charakteristiky Upřesnění vybraných případů užití:

A, Přihlášení do systému

• Podmínky (preconditions): Uživatel musí mít zřízený vlastní účet

• Související případ užití: Vytvořit nový účet (aktér: Recepce, Správce)

• Postup (action steps): Uživatel vyplní přihlašovací údaje a odešle formulář

• Úspěšné zakončení: Uživatel je přihlášen do systému

Související diagram aktivit na straně 20

B, Zapsat vlastní rezervaci

• Podmínky (preconditions):

1, Uživatel musí být přihlášený

2, Rozvrh jednotlivých separátorů je nastaven a alespoň jeden termín je volný

• Související případ užití: Nastavit systém (aktér: Správce)

• Postup (action steps):

1, Uživatel vybere volný termín ze zobrazeného rozvrhu (tabulky)

2, Potvrdí ověřující dialog

• Úspěšné zakončení: Rezervace je zapsána do databáze a uživateli je poslán

e-mail

Související diagram aktivit na straně 21

C, Zapsat cizí rezervaci

• Podmínky (preconditions):

1, Uživatel musí být přihlášený jako Recepce nebo Správce

2, Rozvrh jednotlivých separátorů je nastaven a alespoň jeden termín je volný

3, V systému je založený alespoň jeden účet typu Klient

• Související případ užití: Nastavit systém (aktér: Správce)

• Postup (action steps):

1, Uživatel vybere volný termín ze zobrazeného rozvrhu (tabulky)

2, Ze zobrazeného seznamu vybere konkrétního uživatele

• Úspěšné zakončení: Rezervace je zapsána a uživateli je poslán e-mail

Související diagram aktivit na straně 21

- 20 -

4.3. Modely

4.3.1. Přihlášení uživatele do systému (Diagram aktivit)

Obr. 4.2. - diagram aktivity: přihlášení uživatele

- 21 -

4.3.2. Zápis rezervace (Diagram aktivit)

Obr. 4.3. - diagram aktivity: zapsání rezervace

- 22 -

4.3.3. Diagram t říd

Obr. 4.4. - diagram tříd

- 23 -

Popis jednotlivých tříd:

Rozvrh: Abstraktní třída, obsahující atributy a metody, které od ní přebírají její

potomci. Každý rozvrh tak obsahuje údaje o aktuálním dni a datu, stejně jako údaje

potřebné pro jeho zobrazení v tabulce.

DenniRozvrh: Představuje rozvrh stanice pro konkrétní den. Je vyhodnocován na

základě rozvrhů jednotlivých separátorů. Každému uživateli se může zobrazovat jinak

(správci se zobrazují jiné údaje než dárci. Ten vidí pouze své rezervace, nikoliv

rezervace jiných dárců apod.).

Nejdůležitější metody této třídy pro samotné zobrazení jsou pak zobrazJakoTabulku()

a zobrazVTabulce().

Umožňují vytvářet buď souhrnný přehled rozvrhů na více dnů, nebo detailní rozvrh pro

jeden konkrétní den s podrobným zobrazením rozvrhů separátorů.

RozvrhSeparatoru: Obsahuje údaje o otevírací době konkrétního separátoru.

Umožňuje zobrazení v detailním denním přehledu díky metodě zobrazVTabulce().

Uživatel: Kromě základních údajů o uživateli (jméno, příjmení, úroveň apod.) obsahuje

i údaje o jeho rezervacích. Všechny tyto údaje načítá z databáze, případně do databáze

zapisuje. K tomu slouží příslušné metody třídy.

Separator: Představuje údaje o jednotlivých separátorech. Díky statickým atributům

třídy pocetSeparatoru a vsechnySeparatory umožňuje systému přistupovat

k jednotlivým separátorům bez nutnosti přistupovat do databáze. K té se přistupuje

pouze při inicializaci rozvrhu, kdy třída Separator načte všechny údaje pomocí svých

statických metod.

Tento postup je zobrazen v sekvenčním diagramu na straně 24.

Rezervace: Instance této třídy představují jednotlivé uživatelovy rezervace. Ty jsou

primárně vytvářeny na základě uživatelovy aktivity (výběr termínu) a následně jejich

data uložena do databáze. Třída umožňuje komunikaci s DB i pomocí statické metody.

- 24 -

4.3.4. Sekven ční diagram

Obr. 4.5. - sekvenční diagram

Tento diagram popisuje spolupráci jednotlivých tříd. Na základě uživatelova požadavku

na zobrazení rozvrhu jsou načteny rozvrhy separátorů. Z nich je vytvořen rozvrh daného

dne a vygenerován XHTML kód. Díky němu pak může uživatel vybrat požadovaný

termín a zapsat tak svou rezervaci.

O úspěchu či neúspěchu zápisu je pak informován na základě hodnoty zapsano, která

může nabývat hodnot true/false.

- 25 -

4.3.5. Stavový diagram

Obr. 4.6. - stavový diagram

- 26 -

4.3.6. Diagram nasazení

Obr. 4.7. - diagram nasazení

Popis nasazení:

• Serverovou část aplikace budou tvořit PHP skripty. Na aplikačním serveru proto

musí být nainstalován PHP parser. Skripty budou ke svému chodu vyžadovat

PHP verze 5 a vyšší. Pro připojení k databázi bude sloužit standardní knihovna

php_mysql. Jednou z dalších možností by bylo použít vylepšené php_mysqli, ale

to během testovacího provozu vykazovalo nečekané chyby (pád aplikace,

odpojování od serveru).

• Bude použit MySQL databázový server. Data budou uložena s UTF-8

kódováním.

• Klientská část aplikace poběží ve webovém prohlížeči. Úlohu „tenkého“ klienta

budou plnit vygenerované XHTML stránky. Část aplikační logiky však budou

vykonávat přímo na straně uživatele skripty v Javascriptu, čímž budou plnit roli

„tlustého“ klienta.

- 27 -

4.3.7. ERA diagram Navrhovaná struktura databáze: Pozn.: tabulky se zaoblenými rohy představují slabé (popisné) entity

Obr. 4.8. - ERA diagram

- 28 -

5. Implementace

Tato část práce obsahuje způsoby řešení jednotlivých funkcí aplikace v již

hotovém programu. Cílem je poukázat na některá konkrétní řešení na úrovni zdrojového

kódu. Dále popsat a zdůvodnit strukturu a chování použitých objektů.

5.1. Serverová část aplikace

Základním souborem je index.php. Kód v tomto souboru je zpracován po zadání

URL adresy aplikace. Rozložení stránky je pak definováno v souboru dokument.php,

který se načítá po inicializaci tříd a proměnných, potřebných pro chod aplikace. Na

základě uživatelových akcí se k základnímu kódu obsaženému v tomto souboru

připojují konkrétní skripty pomocí PHP funkce include. Požadovaná akce se předává

v proměnné $akce jako součást URL adresy. Akce je poté vyhodnocena a pomocí řídící

struktury switch.

Příklad kódu:

if (isset($_GET['akce'])) $akce = $_GET['akce']; switch ( $akce) { case "iuzivatel": include '/zobrazeni/akce/iuzivatel.php'; break;

case … //další možné akce

default: include '/zobrazeni/akce/tyden.php'; break;

Pro práci s třídami je využita funkce _autoload, představená v PHP 5. Bez ní

vždy musela být požadovaná třída buď přímo součástí skriptu, který ji chtěl využít,

nebo k němu musela být alespoň připojena pomocí funkce include_once (případně

require_once).

Použití funkce autoload:

function __autoload($nazev_tridy) { require_once $nazev_tridy . '.php'; }

Např. pokud je třeba vytvořit novou instanci třídy ‘Tabulka’ pomocí příkazu

new Tabulka, připojí se kód souboru Tabulka.php. Kód třídy se tedy připojí až když

je skutečně vyžadován, čímž se zefektivňuje chod aplikace a zpřehledňuje kód.

- 29 -

5.1.1. Pomocné t řídy

Kromě základních tříd, zhotovených na základě návrhu systému (viz diagram

tříd na straně 22), obsahuje program řadu tzv. pomocných tříd, které slouží

k vykonávání specifických úkolů.

Tabulka usnadňuje tvorbu jednoduchých tabulek. Lze v ní nastavit jednotlivé

parametry požadované tabulky, jako např. počet sloupců, šířku (v pixelech nebo

procentech), styl vykreslování sudých a lichých řádků. Díky metodě addRow lze

přidávat jednotlivé řádky tabulky jako pole hodnot. Metoda displayTable() pak na

základě nastavených parametrů vygeneruje HTML kód tabulky.

Příklad použití – tabulka pro výpis jména a příjmení uživatel v databázi:

$vysledek = … //vysledek dotazu na DB uzivatel $tabulka = new Tabulka; $tabulka->numCols = 4; $tabulka->headings = array ("P říjmení","jméno"); while ($radek = mysql_fetch_array($vysledek)) { $tabulka->addRow($radek); } $tabulka->displayTable();

Formular na rozdíl od Tabulky neslouží přímo ke generování kódu, ale

k zaznamenávání hodnot a chyb, získané při vyhodnocování formulářů. Každý skript

pracující s formuláři využívá instanci této třídy. V případě nalezení jakékoliv chyby

(nevyplnění povinné položky, špatný formát e-mailu apod.) zaznamená údaje o této

chybě k příslušné položce formuláře.

Příklad použití – obsluha přihlašovacího formuláře:

Část kontrolního skriptu:

if(!$heslo){ $formular->nastavChybu("heslo", "* heslo nebylo zad áno");

}

Část skriptu se zobrazením formuláře:

echo $formular->error("heslo");

Pokud je helso správně zadáno, nezobrazí se nic. Jakmile však heslo není zadána,

zobrazí se příslušné oznámení chyby.

Další pomocné třídy jsou zmíněny přímo v následujících kapitolách.

- 30 -

5.1.2. Přihlášení uživatele Klíčovou roli při přihlašování hrají pomocné třídy Process, Session a Databaze.

Uživatel prostřednictvím formuláře odešle metodou POST své přihlašovací údaje. Třída

Process (resp. její instance) vyhodnocuje právě data odeslaná prostřednictvím formulářů

a předává je k dalšímu zpracováním. Ověření jejich správnosti pak probíhá s využitím

třídy Databaze, která v tomto případě zajišťuje přístup do tabulky s uživatelskými údaji

v databázi. Instance třídy Session pak umožňuje vytvářet session proměné, uchovávající

informace o přihlášeném uživateli.

Na rozdíl od běžných proměnných zůstávají hodnoty session uložené v globálním poli

$_SESSION. Jednotlivé skripty mohou k těmto hodnotám přistupovat nezávisle, tj.

nemusí si je explicitně předávat např. jako parametry v URL adrese.

Systém v tuto chvíli ověří, že jsou v pořádku nastavené sessions a obsahují informace

o uživateli. Již pak nezobrazuje přihlašovací formulář, ale úvodní stranu aplikace.

5.1.3. Vytvo ření rozvrh ů

Jednou z nejdůležitějších funkcí aplikace je vytvoření rozvrhů na základě nastavené

otevírací doby.

Spolupráce s databází

Záznamům v tabulce separator odpovídá záznam v tabulce rozvrh. Jsou propojeny přes

atribut id_separatoru. Takto lze nastavit pro každý separátor individuální rozvrh na

každý den v týdnu (hodnota vyjadřující číslo dne v týdnu je uložena v atributu den).

Pokud je v určitý den stejný rozvrh pro všechny separátory, použije se pouze jeden

záznam v tabulce rozvrh a do id_separatoru se vloží hodnota 0. Toto slouží pro snížení

nároků na databázi. Např. v případě 10 separátorů při stejné otevírací době od pondělí

do pátku postačí pouze 5 záznamů.

Pro případ mimořádných událostí (státní svátky, prázdniny apod.) je zavedena tabulka

udalosti. Tam se zaznamenává nejen popis události, ale zejména od kdy do kdy trvá.

Pokud je rozvrh spojen s konkrétní událostí, je id této události uloženo do atributu

id_udalosti. U těchto rozvrhů pak není nastavena hodnota den (resp. je nastavena na

NULL), neboť se nejedná o rozvrh pro konkrétní den v týdnu, ale pro celé období trvání

události.

- 31 -

Příklad:

Separator id_separatoru nazev 1 Jednička 2 Dvojka

Tabulka 5.1. až 5.3. – Příklady údajů v databázových tabulkách

Rozbor záznamů v tabulce Rozvrh:

• V pondělí (den=1) mají všechny separátory otevřeno od 8 do 18 hodin

• V úterý (den=2) má separátor „Jednička“ otevřeno od 8 do 18, „Dvojka“ od

10 do 14

• Na Vánoce je zavřeno (od 23.12 do 25.12.2009)

• Na Silvestra má separátor „Jednička“ rozvrh pouze od 8 do 12

SQL dotazy:

Třída DenniRozvrh ve své metodě nactiDenniRozvrh nejprve kontroluje, zda na

daný den připadá nějaký rozvrh, nebo jestli je ten den zavřeno. K tomu využívá atribut

třídy cisloDne a proměnnou datumDBformat, které vytvoří ze zadaného data:

$this->cisloDne = date("N", $datum); //napr. 1

$dateDBformat = date("Y-m-d", $datum); //napr. 2009-12-23

První SQL dotaz je pak formulován takto:

SELECT otevreno, id_separatoru, id_udalosti, popis FROM rozvrh LEFT JOIN udalosti USING(id_udalosti) WHERE den=".$this->cisloDne." OR (zacatek<='$dateDBformat' AND konec>='$dateDBfor mat ')

Výsledek tohoto dotazu pak určuje způsob načítání rozvrhů jednotlivých

separátorů. Pokud ani jeden ze řádků výsledku neobsahuje otevreno=1, není tento den

otevřeno a není třeba načítat další data.

Pokud hodnota id_udalosti není nulová, jedná se o mimořádný rozvrh. Rozvrhy

separátorů jsou pak načítány i s informacemi o mimořádné události.

Udalosti id_udalosti popis zacatek konec 10 Vánoce 2009-12-23 2009-12-25 11 Silvestr 2009-12-31 2009-12-31

Rozvrh id den otevreno od do id_separatoru id_udalosti 1 1 1 08:00 18:00 0 NULL 2 2 1 08:00 18:00 1 NULL 3 2 1 10:00 14:00 2 NULL 4 NULL 0 NULL NULL 0 10 5 NULL 1 08:00 12:00 1 11

- 32 -

5.1.4. Generování tabulek rozvrh ů

Systém generuje tyto tabulky na základě nastavení otevírací doby,

zaznamenaných rezervací, uživatelovy úrovně a dalších kritérií. Jednotlivé buňky

odpovídají časovým úsekům. Záleží pak na stavu konkrétní buňky, jaké akce s ní

mohou být spojeny.

Pro tento účel je vytvořena třída Bunka. Ta může nabývat dvou stavů –

aktivní/neaktivní. S neaktivními buňkami nemohou být spojeny žádné akce. Většinou

tyto buňky představují dobu kdy je zavřeno, jsou vyčerpány všechny volné separátory

apod. Pomocí aktivních buněk pak může uživatel provádět požadované akce, nejčastěji

tedy zapsat rezervaci. Buňky dále mohou být několika typů - ty pak odpovídají právě

důvodu jejich (ne)aktivity. Tyto typy mají význam zejména pro samotné zobrazení

buňky (např. buňka typu „obsazená“ bude zobrazena s červeným pozadím), rozhodují

o použitém popisku (tooltipu) a samotném textu, který bude buňka obsahovat. Podle

typu se pak také rozhoduje o použitém obslužném javascriptu.

Třída Rozvrh a její dva potomci – DenniRozvrh a RozvrhSeparatoru – slouží

jednak k uchovávání informací o otevírací době, ale mají i funkce pro generování

a zobrazování těchto interaktivních tabulek. Instance třídy DenniRozvrh umožňují

dvojí zobrazení – „v tabulce“ a nebo „jako tabulku“.

Zobrazení v tabulce slouží při zobrazení rozvrhů pro více dnů najednou, např.

v rámci jednoho týdne. Denní rozvrhy pak představují jednotlivé řádky.

Příklad: Dva denní rozvrhy. Čísla představují počet separátorů (volné/celkem).

10:00 11:00 12:00 Pondělí 1.1.2009 1/2 0/2 1/2 Úterý 2.1.2009 Zavřeno Zavřeno 6/6

tabulka 5.4. – rozvrhy v tabulce

Pokud je denní rozvrh zobrazen jako tabulka, představují řádky jednotlivé separátory.

Příklad: Zobrazení denního rozvrhu jako tabulky. X představuje obsazený separátor.

Pondělí 1.1.2009 10:00 11:00 12:00 Separátor 1 X X X Separátor 2 O X O

tabulka 5.5. – rozvrh jako tabulka

- 33 -

Pro zobrazení tabulky jsou pak důležité 3 metody:

• vytvorHlavicku() – vygeneruje záhlaví tabulky s nadpisem a časy, kterým

odpovídají jednotlivé buňky.

• vytvorRadek($nadpis) – vytvoří nový řádek, na jeho úvod napíše požadovaný

nadpis a řádek vyplní jednotlivými buňkami. O způsobu vyplnění rozhoduje

další funkce: naplnBunku ($zacatekBunky). Tuto metodu pak překrývají oba

potomci třídy Rozvrh. Na základě informace o čase, kterému buňka odpovídá,

vybere vhodný typ buňky.

• vytvorZapati() – slouží k vygenerování XHTML tagů pro uzavření tabulky

Samotné generování řádku v metodě vytvorRadek probíhá následujícím způsobem:

1. Na základě nastavení systému se určí počáteční a koncový čas.

2. Interval mezi těmito časy se vydělí dálkou jednoho odběru. Tím se zjistí,

kolik buněk je třeba na jeden řádek vložit.

3. Pomocí cyklu for vkládá jednotlivé buňky na řádek, funkce naplnBunku

rozhoduje o použitém typu buňky.

5.1.5. Časové razítko

Pro vyjádření času se v programu využívá tzv. časové razítko (timestamp, resp.

Unix timestamp). Čas je vyjádřen celým číslem, které představuje počet vteřin od

půlnoci 1.ledna 1970, tedy tzv. koordinovaného světového času (UTC).

PHP nabízí řadu funkcí pro převod data a času na časové razítko (např. strtotime,

mktime) a opačně (date).

Jelikož je čas vyjádřen jako celé číslo, je možné s ním provádět různé

matematické operace. Např. délku intervalu lze vyčíslit tak, že se odečte časové razítko,

představující začátek intervalu, od razítka konce. Výsledek pak lze např. vydělit číslem

3600 a získat tak délku intervalu v hodinách.

Jelikož žádné dvě razítka představující různé časy nemohou být shodná, je toto

číslo využito i jako jednoznačný identifikátor každé buňky v tabulce rozvrhu. Do

atributu id HTML tagu <td> je proto vložena hodnota „b_[hodnota časového razítka]”.

Dle standardů W3C nesmí identifikátor id začínat číslicí, proto obsahuje ještě předponu

b_ (buňka). Tento identifikátor je pak základem pro komunikaci s obslužnými

javascripty, které umožňují vybírat prvky na stránce právě na základě atributu id.

- 34 -

Problém s exponenciálním tvarem

Během testovacího provozu aplikace se na některých serverech vyskytovala

zvláštní chyba. V případě některých buněk rozvrhu nebyl javascript schopen z časového

razítka určit datum a zobrazoval nesmyslné hodnoty.

Ukázalo se, že příčinou byl automatický převod některých čísel na exponenciální

tvar. PHP totiž automaticky převádělo velká čísla končící na pět a více nul na jejich

vyjádření pomocí vhodné mocniny deseti.

Např. časové razítko představující 30.3.2009 10:00 je rovno 1238400000. PHP

však tento tvar převedlo na 1,2384E+9. Tuto hodnotu javascript vyhodnotil jako textový

řetězec a nebyl schopný z něj určit časový údaj.

Pro zabránění této nechtěné konverzi na exponenciální tvar byla použita funkce

intval. Ta vrací přesnou celočíselnou hodnotu zadané proměnné. Pokud je tedy potřeba

uložit časové razítko, použije se konstrukce:

$cas = intval($cas);

5.1.6. Zaznamenávání rezervace

Pokud uživatel potvrdí požadovaný termín v tabulce rozvrhu, vytvoří se nová

instance třídy Rezervace. Parametry konstruktoru této třídy jsou: časové razítko

představující vybraný termín, id separátoru a uživatel, pro kterého bude rezervace

zapsána (objekt typu Uzivatel).

Tato instance pak zavolá svojí metodu zapisDoDB, která spustí následující SQL

dotaz na databázi:

INSERT INTO rezervace (id_uzivatele, datum_cas, id_separatoru) VALUES (".$this->uzivatel->getId().", '$this->casDBformat', $this->separator)

Systém však ještě kontroluje, zda nebyla mezitím obsazena zbývající volná

místa. Uživatelské rozhraní totiž zobrazí aktuální počet volných separátorů pouze při

aktualizaci stránky s rozvrhem. Může se tedy stát, že mezitím poslední volné místo bylo

obsazeno a uživatel o tom neví, neboť si stránku neobnovil. Pro řešení těchto konfliktů

slouží metoda jeMozneZapsat, která před samotným zapsáním do databáze ověří, zda

ještě nějaké volné místo opravdu zbývá.

- 35 -

5.1.7. Nastavení systému

Jelikož základním požadavkem na aplikaci je její snadná modifikovatelnost, je

převážná většina jejích parametrů nastavitelná.

Parametry aplikace jsou umístěny v souborech konstanty.php a db_config.php

v adresáři /config. Mezi tyto parametry patří:

• nastavení přístupu k databázi – údaje jsou uloženy v konstantách

DB_SERVER, DB_LOGIN, DB_HESLO a DB_DATABAZE. Tyto konstanty

pak vstupují do všech skriptů, které se připojují k databázi a v případě změny

některého z údajů postačí pouze změnit hodnotu příslušné konstanty.

• názvy databázových tabulek - tyto nejsou v SQL dotazech pevně nastaveny,

ale rovněž využívají konstanty (např. TBL_REZERVACE=’rezervace’). V praxi

může nastat situace, kdy by docházelo ke konfliktu názvů tabulek v jedné

databázi. Aby při změně názvu tabulky nebylo nutné měnit všechny SQL dotazy

v programu, jsou tímto způsobem soustředěny na jedno místo.

• ostatní - nastavení doby platnosti cookies, doba neaktivity po které je uživatel

automaticky odhlášen apod.

Parametry tohoto typu je tedy možné upravit pouze editací souborů, ve kterých

jsou definovány. Není možné je měnit prostřednictvím uživatelského prostředí aplikace.

Naproti tomu parametry konkrétní transfuzní stanice jsou uloženy v databázi,

v tabulce nastaveni. Uživatelské prostředí umožňuje jejich nastavení pomocí formuláře

v administrátorské sekci systému. Uživatel musí být přihlášen jako správce, aby k nim

měl přístup.

Tyto parametry jsou: název stanice, nadpis stránky, obrázek s logem, kontaktní

informace, délka jednoho odběru, výhled (na kolik dní dopředu se má rozvrh

zobrazovat), interval mezi dvěma rezervacemi.

Pro uchovávání hodnot těchto parametrů slouží při běhu programu třída

NastaveniSystemu. Ta při spuštění aplikace načte hodnoty z databáze a pak je dává

k dispozici jako statické atributy. Například soubor pro zobrazení úvodní strany tak pro

zobrazení názvu stanice využívá následující kód:

<h1><?php echo NastaveniSystemu:: $NAZEV_STANICE ?></h1>

- 36 -

5.1.8. Použité návrhové vzory

A, Jedináček (Singleton)

Použití tohoto vzoru zajišťuje, že bude vytvořena pouze jedna instance určité

třídy. Tuto vlastnost využívá třída Databaze, u které by vytvoření více instancí bylo

nežádoucí. Vzniklo by tím více současných připojení k databázi, což PHP nepodporuje

a skript by skončil s chybou.

Základní myšlenkou tohoto návrhového vzoru je znepřístupnění konstruktoru

třídy nastavením modifikátoru jeho přístupu na private. V případě, že program

potřebuje instanci této třídy, nevytváří novou (new Databaze), ale volá její statickou

metodu getInstance (Databaze::getInstance() ). Tato metoda je definována takto:

public static function getInstance(){ if(self::$instance == NULL ){ self::$instance = new Databaze; } return self::$instance; }

Ve statickém atributu je tedy uchována jediná instance. Při prvním volání této metody je

vytvořena a uložena, při dalších volání metoda pouze vrací odkaz na již existující

instanci.

B, MVC

Vzor Model-View-Controller (Model-Pohled-Ovladač) byl použit pro obsluhu

administrátorské části aplikace. Spočívá v tom, že od sebe odděluje skripty na

zobrazovací (generují výstupní kód), datové modely (obsahují metody pro přístup

k databázi a uchovávají hodnoty ve svých atributech) a skripty s obslužnou logikou.

Jednotlivé skripty jsou rozděleny do příslušných adresářů a každý plní svoji

odpovídající funkci.

Příklad využití:

PravidelnyRozvrhOvladac vytvoří nový objekt (model) PravidelnyRozvrh. Ten

pomocí příslušných metod načte data z databáze a je předán příslušnému „pohledu“

PravidelnyRozvrhNastaveni. Ten zobrazí data z tohoto modelu jako tabulku a umožní

nastavit příslušné hodnoty. Ty jsou pak opět zpracovány ovladačem a uloženy do

databáze.

- 37 -

5.1.9. Zabezpečení

V této kapitole jsou popsány způsoby řešení bezpečnostních prvků. Jedná se

o nejčastěji řešené bezpečnostní otázky. Přesto, že je řešení poměrně snadné, bývají níže

popsané situace často podceňovány, což může vést k řadě problémů. Nejčastěji únik

informací o uživatelích, případně i ztráta dat.

Způsoby řešení jsou popsány v řadě publikací, ale i na nejrůznějších diskusních

fórech a návodech pro PHP programátory. Postupy použité v aplikaci jsou popsány

v [19].

A, Uložení hesla

Heslo je hlavním prvkem při ověřování totožnosti uživatele při jeho přihlašování

do systému. Zadané heslo je porovnáno s údajem v databázi. Tam se však neukládá

přesné znění hesla, nýbrž jen jeho zápis, zašifrovaný pomocí MD5 algoritmu. Díky

tomu ani správce systému s přístupem do databáze nezná hesla uložených uživatel.

Jelikož heslo není nikde přímo zaznamenáno, nemůže být v případě ztráty znovu

sděleno uživateli, ale musí mu být vygenerováno heslo nové.

V PHP existuje pro vytvoření zmiňovaného zápisu (označovaný jako otisk,

případně hash) funkce md5. Při přihlašování se tedy neporovnávají přímo hesla, ale

jejich otisky.

B, PHP injection

Situace, při které dojde k vložení cizího skriptu do běžící aplikace, bývá

označována jako PHP injection. Nejčastěji se tak stává v případech, kdy se k běžícímu

skriptu připojují jiné pomocí funkcí include a require. Jedná se i o situaci, která je

popsána v samém úvodu kapitoly „Implementace“. Na základě parametru $akce

přijatém v URL adrese aplikace připojuje související skript.

Kdyby byl skript napsán pouze formou include '/$akce', představoval by značné

riziko. Pokud by útočník zadal vlastní URL adresu, mohl by vložit vlastní škodlivý

skript. Např. tímto způsobem:

index.php?akce= http://domena.cz/skodlivyskript.php

- 38 -

C, SQL injection

V URL adrese jsou obsaženy hodnoty, které jsou následně použity v SQL

dotazech. Např. pro vyhledání uživatele v databázi může být předáno jeho id

v parametru $id. URL adresa pak vzpada např. takto:

index.php?akce= vyhledejuzivatele&id=13

Skript pro vyhledávání pak může obsahovat SQL dotaz:

$dotaz = “SELECT FROM uzivatele WHERE id_uzivatele = $id“

Útočník by však mohl změnit hodnotu parametru id v URL například na:

index.php?akce= vyhledejuzivatele&id=13;DROP TABLE uzivatele

Výsledný SQL dotaz by tedy byl:

SELECT FROM uzivatele WHERE id_uzivatele = 13; DROP TABLE uzivatele

Jako ochranu proti SQL injection je využita PHP funkce mysql_real_escape_string. Ta

vrací pouze takový textový řetězec, který je vhodný pro použití v SQL dotazu. Pokud

takový řetězec není možné vytvořit, vrací false.

- 39 -

5.2. Klientská část aplikace Tato kapitola popisuje část aplikace běžící na straně klienta, tj. v internetovém

prohlížeči. Kromě popisu uživatelského rozhraní vysvětluje princip fungování

asynchronních dotazů a vybraných javascriptů.

5.2.1. Uživatelské rozhraní

Obr. 5.1. – úvodní strana (pohled správce)

Hlavním prvkem aplikace jsou interaktivní tabulky s rozvrhy (na obrázku 5.1.

označeny číslem 5). Ty jsou proto zobrazeny na úvodní straně a uživatel k nim má

přístup ihned po přihlášení.

Rozmístění ovládacích prvků odpovídá rozložení v jiných internetových

aplikacích (např. Google Docs, e-mailové webové klienty apod.). Respektuje tak zásady

použitelnosti internetových aplikací [4] (s.171-191) . Uznávaný odborník Jakob Nielsen

na toto téma uvádí zásadu pro design webových stránek. „Uživatel stráví většinu času

na jiných stránkách. Své zkušenosti a očekávání si tak utváří tam a není žádoucí nutit ho

měnit jeho zaběhlé principy“ [14].

- 40 -

Přihlášený uživatel tak vidí své jméno v pravém horním rohu, kde se nacházejí

i volby pro úpravu účtu, případně odhlášení (číslo 1). Jednotlivé sekce systému jsou

přístupné přes menu s ikonkami (číslo 3). Položky v menu se liší podle úrovně

přihlášeného uživatele.

Nejčastěji využívané funkce, v tomto případě „Zobrazit denní rozvrh“ a „Přidat

uživatele“, jsou zobrazeny v levém horním rohu (číslo 4). Tedy v místě, odkud většina

uživatel začíná prohlížet stránku.

Název stanice, logo, úvodní zpráva a kontakty na stanici (číslo 2) mohou být

nastaveny v administrátorské sekci. Tyto údaje jsou zobrazeny po celou dobu, mění se

pouze obsah části stránky pod nimi.

Administrátor má možnost sledovat všechny uživatele, kteří jsou přihlášení

k systému. K tomu slouží spodní část stránky (číslo 6). Jména jsou zobrazena jako

odkazy, po kliknutí na jméno uživatele se otevře jeho profil.

Ukázky dalších částí uživatelského rozhraní jsou v příloze A, popis ovládání

a návod k obsluze je k dispozici na přiloženém CD.

- 41 -

5.2.2. Ovládací prvky

Ovládací prvky aplikace tvoří: odkazy, tlačítka spouštějící javascripty, skrytá okna.

A, Odkazy – standardní XHTML tag <a href=…> je použit pro předávání parametrů

v URL adrese. Serverová část aplikace pak k těmto parametrům přistupuje z pole

hodnot $_GET. Jelikož hlavním ovládacím skriptem je soubor index.php, všechny

odkazy odkazují na tento soubor. Je využita zkrácená forma zápisu, která v atributu href

udávají pouze parametry, které budou v URL adrese doplněny za index.php. Zápis tedy

vypadá například takto:

<a href="?akce=iuzivatel&uzivatel=$idUzivatele">$ce lejmeno</a>

B, Tlačítka – pro označení tlačítek rovněž slouží standardní XHTML tagy, konkrétně

<input type=“buton“>. Mimoto jako interaktivní tlačítka vystupují i jednotlivé buňky

tabulky s rozvrhem. Základem je atribut onclick, ve kterém je definovaná příslušná

funkce z obslužného javascriptu.

Ukázka použití:

Pokud je v určitý čas volný alespoň jeden separátor, je příslušná buňka v tabulce

s rozvrhem zobrazena zeleně a plní roli tlačítka. Po stisknutí se uživateli rezervuje

vybraný termín. Buňka tabulky, resp. XHTML tag <td> má definovány atributy id a

onlclick například takto:

<td id="b_1241429400_0_4" onClick = "rezervuj(this) ;"

Funkce rezervuj(prvek) je definována v obslužném javascriptu ‘rozvrh.js’. Při

zavolání této funkce je jí předán odkaz na vybranou buňku. Její id rozdělí pomocí

funkce split na jednotlivé části a použije je jako parametry pro další funkce. Jednou se

součástí id je i časové razítko, které odpovídá vybranému datu a času. Podle W3C

standardu [23] nesmí atribut id začínat číslicí, proto na začátku obsahuje předponu „b_“.

Krom toho, že funkce rezervuj předává parametry pro funkce, spojené se

samotným zápisem rezervace do databáze (více v kapitole „Asynchronní dotazy“),

předává odkaz na buňku funkci oznac(predmet). Ta zvýrazní vybranou buňku

oranžovou barvou, díky možnosti javascriptu měnit atributy CSS stylu.

predmet.style.backgroundColor = "#FFCC66";

Tímto způsobem je zajištěna zpětná vazba pro uživatele, který tak vidí, že

vybrána je opravdu požadovaná buňka.

- 42 -

C, Skrytá okna – jsou zobrazována pouze v případě, že se od uživatele čeká ještě

nějaká doplňující akce. Nejčastěji se jedná o potvrzující dialogy s možnostmi Ano/Ne.

Pomocí skrytého okna je řešen mimo jiné i seznam uživatel, který se zobrazí v případě

zápisu cizí rezervace správcem systému (resp. uživatelem s právy pro zápis cizích

rezervací).

Obr. 5.2. – okno se seznamem uživatelů

Tato okna jsou řešena pomocí HTML oddílů <div>, které mají standardně

nastavený CSS atribut display=none. Díky tomu jsou přítomné v HTML kódu (a může

tak k nim přistupovat javascript) , nejsou ale zobrazené na výstupní stránce.

Po zavolání spouštěcí funkce, resp. po provedení akce se kterou je spojeno

zviditelnění skrytého okna, nastaví javascript hodnotu atributu display na „block“ a

okno se zobrazí.

Pro zajištění pozice okna na středu stránky je nastaven CSS atribut position na

hodnotu „aboslute“. Pomocí hodnot atributů x a y je pak učena přesná poloha okna.

Jelikož okna musí být v popředí, tj. překrývat veškerý obsah pod nimi, je

nastavena hodnota z-index na 10. Standardní hodnota u ostatních prvků je 0. Hodnota 10

je tedy použita spíše pro jistotu. Teoreticky by stačila hodnota 1.

Jelikož tyto vlastnosti musí mít všechna skrytá okna, jsou v rámci CSS

definovány v třídě .neviditelny. Každý oddíl má tedy definovaný HTML atribut

class=“neviditelny“, čímž získává požadované hodnoty CSS atributů.

- 43 -

5.2.3. Asynchronní dotazy

Jak již bylo pospáno v úvodní kapitole „AJAX“, spočívá asynchronní dotazování

mimo jiné v komunikaci klienta se serverem bez nutnosti znovu načítat celý obsah

stránky. Těchto dotazů může být vykonáno i více najednou, což je podstatný rozdíl

oproti dřívějšímu přístupu v tvorbě webových aplikací.

Ve vytvořeném rezervačním systému je využito asynchronní dotazování pro tyto

aktivity:

a, zaznamenání/zrušení rezervace – javascript přejímá z vybrané buňky časové

razítko, které odpovídá datu a času rezervace. To je odesláno v asynchronním dotazu na

server, kde PHP skript vykoná SQL dotaz na tabulku s rezervacemi. Výsledek dotazu je

pak předán zpět javascriptu, který změní pouze určitou část stránky. Konkrétně text

v tzv. „informačním oddílu“. Ten je do této chvíle skrytý, v případě úspěchu je zobrazen

se zeleným pozadím a informuje o úspěšném vykonání dotazu.

b, zobrazení seznamu uživatelů – javascript opět pomocí dotazu na server

(potažmo na databázi) získá jména registrovaných uživatelů, zviditelní skryté okno a

vloží do něj tento seznam.

c, listování tabulkami s rozvrhy – uživatel má možnost zobrazovat rozvrhy na

další týdny pomocí příslušných tlačítek. I při této aktivitě se však mění pouze tabulky

s rozvrhy, zbytek stránky zůstává beze změny.

d, mazání záznamů – pokud je zobrazen tabulkový výpis hodnot (např. seznam

uživatel, výpis rezervací, přehled separátorů apod.), má uživatel možnost odstranit

záznam pomocí tlačítka na příslušném řádku. V tom případě je opět vykonán dotaz,

který pomocí id získaného javascriptem odstraní tento záznam z databáze. Po úspěšném

vykonání dotazu je odstraněn příslušný řádek z tabulky.

e, změna vybraného separátoru – uživateli je po potvrzení rezervace přidělen

první volný separátor. Správce mu však může přidělit separátor jiný. Tato akce s skládá

hned ze dvou asynch. dotazů. V prvním se správci zobrazí okno se separátory, které

jsou pro vybraný čas také dostupné. Po vybrání požadovaného separátoru se vykoná

dotaz na úpravu údaje v databázi rezervací a je překreslena tabulka s detailním

rozvrhem.

- 44 -

Ukázka kódu:

Funkce pro vykonávání asychronních dotazů jsou umístěny v souboru

javascript/asynchronni.js.

Pro zahájení přenosu je třeba vytvořit požadavek, tzv. request object. Jelikož

Internet Explorer využívá jiný druh požadavku než ostatní prohlížeče, je třeba v této fázi

rozlišit, o jaký prohlížeč se jedná. Použité řešení je popsáno v [18] (str. 20-22)

req = initRequest(); function initRequest() { if (window.XMLHttpRequest) { if (navigator.userAgent.indexOf('MSIE') != -1) { isIE = true; } return new XMLHttpRequest(); } else if (window.ActiveXObject) { isIE = true; return new ActiveXObject("Microsoft.XMLHTTP "); } else { return false; } }

Dále je definován cílový PHP skript, zadáním jeho URL adresy. Do URL lze

samozřejmě přidávat parametry dotazu. V tomto příkladu předáváme id vybrané buňky.

var url = "automatickeDoplneni.php?bunkaId=" + id_b unky; req.open("GET", url, true);

Je určena funkce, kterou má javascript vykonat, jakmile dostane odpověď na

odeslaný dotaz. Kód v příkladu nejprve najde na stránce prvek s id=”jmena” (jedná se

o jedno ze skrytých oken) a upraví jeho XHTML kód podle odpovědi serveru na

zaslaný požadavek.

req.onreadystatechange = callback1; function callback1() { jmena = document.getElementById("jmena"); jmena.innerHTML = req.responseText; }

Nakonec je požadavek odeslán.

req.send(null);

- 45 -

5.3. Testování aplikace Výsledná aplikace byla po dokončení spuštěna na veřejně přístupném serveru

a testována jak z hlediska funkcionality, tak z přehlednosti a použitelnosti uživatelského

rozhraní. Cílem bylo odhalit případné chyby v programu a otestovat, zda uživatelské

rozhraní bude pro uživatele intuitivní a přehledné.

Testu se zúčastnilo 9 osob. Jedním z nich byl zadavatel požadavků a vedoucí

práce, dále pak dvě zaměstnankyně transfuzní stanice, zbytek byli náhodně vybraní

dobrovolníci, kteří se systémem před samotným testováním nepřišli do styku.

Testování probíhalo na platformách: Windows XP; Windows Vista; Ubuntu

8.04; Solaris 10.

Internetové prohlížeče použité při testování: Internet Explorer 6, 7 a 8; Mozzila

Firefox 3, Opera 9, Konqueror (Ubuntu verze).

Během testování nebyly nalezeny žádné vážné nedostatky, které by zabraňovaly

používání aplikace. Menší chyby byly odstraněny ihned po odhalení a do konečné verze

programu se nedostaly.

Testování uživatelského rozhraní probíhalo formou tzv. „usability testu“.

Uživateli byly zadány různé úkoly (např. vytvořit nový uživatelský účet, nastavit

pokročilý rozvrh, zrušit rezervaci jiného uživatele apod.). Zatímco tyto akce vykonával,

musel nahlas komentovat veškeré své počínání, včetně svých názorů na to, jak s ním

aplikace komunikuje a jak reaguje na jeho podněty.

Na základě výsledků těchto testů bylo uživatelské rozhraní upraveno. Mělo by

tak splňovat podmínku snadného a intuitivního ovládání.

- 46 -

6. Závěr

6.1. Zhodnocení spln ění požadavk ů

Cíl práce, tj. vytvoření funkčního jádra rezervačního systému, se podařilo splnit.

Během práce se navíc podařilo aplikaci vylepšit natolik, že může být bez nutnosti

větších úprav používána jako plnohodnotný rezervační systém.

Tento systém tedy již ve stávající podobě splňuje všechny požadavky, které byly

definovány v úvodní specifikaci, případně které byly upřesněny během konzultací se

zadavatelem. Díky objektově orientovanému přístupu lze aplikaci dále snadno

rozšiřovat a modifikovat přidáním nových tříd, případně přidáním nových metod do tříd

stávajících.

Jedním z hlavních požadavků bylo snadné nastavení parametrů rezervačního

systému. I tento požadavek se podařilo úspěšně splnit. Správce systému má možnost

upravovat základní nastavení, definovat libovolnou otevírací dobu stanice (s možností

přiřadit specifický rozvrh jednotlivým separátorům) a ovlivňovat pravidelnou otevírací

dobu v případě mimořádných událostí.

Design uživatelského rozhraní vychází za současných standardů. Při vývoji byl

kladen důraz na intuitivnost a snadné osvojení ovládání. Systém tak nevyžaduje po

uživateli vysokou úroveň práce s informačními technologiemi. Součástí aplikace je

i podrobný návod.

Dostupnost a použitelnost ovládacích prvků není negativně ovlivněna použitým

internetovým prohlížečem.

Díky použití technologie AJAX je zajištěn rychlejší a plynulejší chod aplikace.

Uživatel není nucen čekat na znovunačtení celé stránky po každé své akci. Mění se

pouze části, které s touto akcí souvisejí.

Systém respektuje zásady bezpečnosti internetových aplikací. Předchází útokům

typu PHP injection a SQL injection. Hlavním zabezpečovacím prvkem pro identifikaci

uživatelů je heslo, jehož přesné znění není nikde zaznamenáváno. Pouze jako

zašifrovaný otisk.

- 47 -

V současné době je systém úspěšně implementován a testován na dvou veřejně

přístupných testovacích serverech. Rovněž byl spuštěn zkušební provoz v nově

otevírané transfuzní stanici v Praze.

6.2. Budoucnost systému O tento rezervační systém již projevily zájem dvě další transfuzní stanice

v České republice a velmi pravděpodobně zde opravdu bude provozován.

Pro budoucnost systému nyní bude nejdůležitější následující „ostrý“ provoz

a zpětná vazba od uživatelů.

V případě úspěšného provozu systému může být v budoucnosti systém

rozšiřován o další funkce. Díky snadné modifikovatelnosti není vyloučeno ani využití

v jiném prostředí. To ale rozhodně není prioritou. Tou i nadále zůstává zaměření na

transfuzní stanice.

- 48 -

7. Seznam použitých zdroj ů

1. ADAMS, Cameron, EDWARDS, James. The JavaScript Anthology. USA :

SitePoint, 2006. 592 s. ISBN 978-0-975-24026-7

2. ALLEN, Rob, LO, Nick, BROWN, Steven. ZEND Framework In action.

[ZEND Framework v akci] USA : Manning Publications, 2009. 623 s. ISBN

1933988320

3. ARLOW, Jim, NEUSTADT , Ila. UML a unifikovaný proces vývoje aplikací :

objektově orientovaná analýza a návrh prakticky. překl. Bogdan Kiszka. 2.

aktualiz. vyd. Brno : Computer Press, 2007. 567 s.

4. BUTOW, Eric. User Interface Design for Mere Mortals. [Návrh uživatelského

rozhraní pro běžné smrtelníky] : Addison-Wesley Professional, 2007. 312 s.

ISBN 978-0-321-44773-9

5. DRUSKA, Peter. CSS a XHTML : tvorba dokonalých webových stránek krok za

krokem. 1.vyd.. Praha : Grada, 2006. 200 s.

ISBN 80-247-1382-9 (brož.)

6. GRIFFITHS, Patrick. HTML Dog : The Best-Practice Guide to XHTML and

CSS. [Průvodce nejlepšími praktikami XHTML a CSS] New Riders, 2006. 368

s. ISBN 978-0-321-31139-9

7. HOFFMAN, Sharon L. Beyond RPG: To PHP or Not to PHP [PHP - ano či ne].

System iNEWS . 2008, is.344 [cit. 2008-11-14], s. 8-10. ISSN 1933-1738

8. Interval.cz : webdesign a e-komerce denně [online]. 2002 [cit. 2009-02-22].

Dostupný z WWW: <http://interval.cz/>. ISSN 1212-8651

9. KUČEROVÁ, Helena. Projektování informačních systémů : Sylaby ke kurzu.

Praha: Vyšší odborná škola informačních služeb, 2007. 114 s. Dostupný z

WWW: <http://info.sks.cz/users/ku/DOKUMENTY/pri_syl.pdf>

10. LAVIN, Peter. Object-Oriented PHP. [Objektově orientované PHP] 2006. 216

s. ISBN 978-1-593-27077-3

11. MCLAUGHLIN, Brett, POLLICE, Gary, WEST, David. Head First Object-

Oriented Analysis and Design. [Objektově orientovaná analýza a návrh] USA :

O'Reilly Media. Inc, 2006. 752 s. ISBN 978-0-596-00867-3

- 49 -

12. MILES, Russel, HAMILTON, Kim. Learning UML 2.0. USA : O'Reilly Media,

Inc., 2006. 288 s. ISBN 978-0-596-00982-3

13. MORRISON, Michael. Head First JavaScript. USA:O'Reilly Media, Inc, 2007.

656 s. ISBN 978-0-596-52774-7

14. NIELSEN, Jacob. Useit.com : Jakob Nielsen's Website [online]. 1995-2009 [cit.

2009-03-19]. Dostupný z WWW: <http://www.useit.com/>. ISSN 1548-555

15. PECINOVSKÝ, Rudolf. Myslíme objektově v jazyku Java : kompletní učebnice

pro začátečníky. 2., aktualiz. a rozš. vyd.. Praha : Grada, 2009. 570 s.

ISBN 978-80-247-2653-3

16. REIERSÖL, Dagfinn, BAKER, Marcus, SHIFLETT, Chris. PHP in Action :

Objects, Design, Agility. [PHP v akci: objekty, návrh, rychlost], 2007. 552 s.

ISBN 978-1-932394-75-7

17. RESIG, John. JavaScript a Ajax : moderní programování webových aplikací.

překl. Ondřej Baše, Ondřej Žižka. Vyd. 1. Brno : Computer Press, 2007. 360 s.

ISBN 978-80-251-1824-5 (brož.)

18. RIORDAN, Rebecca. Head First Ajax. USA : O\'Reilly Media, Inc., 2008. 528

s. ISBN 978-0-596-51578-2

19. SEIDEN, Alan. Configure a Safe Environment for PHP Web App [Nastavení

bezpečného prostředí pro PHP webové aplikace]. System iNEWS. 2007, is. 338

[cit. 2008-11-14], s. 36-40. ISSN 1933-1738

20. SCHWARTZ, Baron. High Performance MySQL [Vysoce výkonné MySQL].

2nd edition. USA:O'Reilly Media, Inc., 2008. 712 s. ISBN 978-0-596-10171-8

21. SUEHRING, Steve. JavaScript : krok za krokem. překl. Jakub Zemánek. Vyd. 1.

Brno: Computer Press, 2008. 335 s. ISBN 978-80-251-2241-9 (brož.)

22. VRÁNA, Jakub. PHP Triky : Weblog o elegantním programování v PHP pro

mírně pokročilé [online]. 2005 [cit. 2009-03-19]. Dostupný z WWW:

<http://php.vrana.cz/>

23. XHTML™ 1.0 : The Extensible HyperText Markup Language. 2002 [cit. 2009-

04-15]. Dostupný z WWW: <http://www.w3.org/TR/xhtml1/>

- 50 -

8. Seznam obrázk ů Obr. 4.1. - Use case diagram ................................................................................. 18

Obr. 4.2. - Diagram aktivity: přihlášení uživatele................................................. 20

Obr. 4.3. - Diagram aktivity: zapsání rezervace.................................................... 21

Obr. 4.4. - Diagram tříd......................................................................................... 22

Obr. 4.5. - Sekvenční diagram............................................................................... 24

Obr. 4.6. - Stavový diagram .................................................................................. 25

Obr. 4.7. - Diagram nasazení ................................................................................ 26

Obr. 4.8. - ERA diagram ....................................................................................... 27

Obr. 5.1. – Úvodní strana (pohled administrátora) ............................................... 39

Obr. 5.2. – Okno se seznamem uživatelů.............................................................. 42

- 51 -

9. Seznam p říloh A. Ukázky uživatelského rozhraní

B. Obsah přiloženého CD

C. Návod na instalaci aplikace

D. Příklady rezervačních systémů

A. Ukázky uživatelského rozhraní

Obr. A.1. – Profil uživatele

Obr. A.2. – Seznam uživatelů

Obr. A.3. – Statistiky stanice

Obr. A.4. – Administrátorská sekce: základní nastavení systému

Obr. A.5. – Administrátorská sekce: nastavení pravidelného rozvrhu

Obr. A.6. – Administrátorská sekce: nastavení specifického rozvrhu

Obr. A.7. – Denní rozvrh v tabulce (pohled uživatele)

Obr. A.8. – Detailní denní rozvrh s vyznačením rezervací

B. Obsah p řiloženého CD

Adresář (soubor) Obsah

/TXT Text bakalářské práce ve formátu .doc a .pdf

/OBR Obrázky, použité v bakalářské práci (v původním rozlišení)

/INSTALL Zdrojové soubory aplikace

/MANUAL Uživatelská příručky pro uživatele a pro správce systému

readme.txt Obsah CD

C. Návod na instalaci aplikace

Požadavky Server s podporou PHP verze 5 a vyšší

MySQL databáze verze 4.1 a vyšší

Libovolný internetový prohlížeč s podporou JavaScript: např. Internet Explorer (doporučená verze 7 a vyšší), Mozzila Firefox, Opera

Instalace 1. Nakopírujte adresář registrace z instalačního balíčku na Váš webový server.

2. Upravte nastavení databáze v souboru /config/db_config.php

3. Na Vaší databázi spusťte dotazy, uložené v souboru /config/databaze.sql

4. Nastavte přístupová práva pro zápis do adresáře /obr Toto nastavení je důležité kvůli možnosti uploadování vlastních obrázků na server

5. V případě instalace na lokální server (localhost) je nutné mít správně

nakonfigurovaný mailserver. V opačném případě systém hlásí chybu funkce mail() při pokusu odeslat e-mail. Pro testovací účely lze zabránit odesílání e-mailů nastavením konstant EMAIL_VITEJTE a EMAIL_ZMENA na „false“ (v souboru config/konstanty.php)

První spušt ění Pokud jste adresář registrace nakopírovali do kořenového adresáře Vašeho serveru, bude adresa např. http://registrace.vasedomena.cz

Přihlášení Po zadání této adresy budete vyzváni k zadání přihlašovacích údajů. Pro první přístup do systému použijte tyto hodnoty:

• e-mail: admin@admin.cx • heslo: admin

Tyto hodnoty si po prvním nastavení změňte v menu „Můj účet“.

Pozn. Nejprve doporučuji změnit heslo, potom teprve jméno a e-mail. Po změnění emailu budete ze systému odhlášeni a budete se muset přihlásit pomocí nového emailu.

Celou verzi návodu naleznete na přiloženém CD.

D. Příklady rezerva čních systém ů

TASW (typový aplikační software)

BIZZY (Smarcoms)

http://www.smarcoms.cz

Parametrizovatelný systém vhodný zejména pro

sportovní centra.

BOOKER (Nower systems s.r.o.)

http://www.nower.cz

Parametrizovatelný systém vhodný zejména pro

sportovní centra.

QBIS (Hired Help)

http://www.hiredhelp.biz

Parametrizovatelný systém. Navržený pro plánování

pomoci a služeb pro handicapované osoby.

IASW (individuální aplika ční software)

Hotelein

http://hotelein.cz

Rezervační systém pro rezervaci hotelových pokojů.

Palace Cinemas

http://www.palacecinemas.cz

Rezervační systém pro rezervaci vstupenek do kina.

Vytvořený pro společnost Palace Cinemas.