ZADÁNÍ DIPLOMOVÉ PRÁCE

České vysoké učení technické v Praze Fakulta elektrotechnická katedra počítačů

ZADÁNÍ DIPLOMOVÉ PRÁCE Student: Bc. Valentin Kostělej Studijní program: Elektrotechnika a informatika (magisterský), strukturovaný Obor: Výpočetní technika Název tématu: Rezervační systém pro dárce krevní plazmy

Pokyny pro vypracování: Analyzujte stávající rezervační systém dárců krevní plazmy. Systém využívá 8 nemocnic a plasmaferetíckých center po celé ČR. Celkem je registrováno více než 50.000 aktivních uživatelů Aktuální systém je napsán v PHP nad MySQL databází, což aktuálné bráni rozšiřování uživatelské základny. Navrhněte a vytvořte zcela novou internetovou aplikaci zaměřenou na online rezervace. Systém bude umožňovat, kromě jiného, kompletní správu skrze webové rozhraní, selfprovisioning (zprovoznění a nastaveni systému zákazníkem), propojení s rozhraním pro SMS notifikace, rozsáhlé možnosti nastavení rezervačních prostředků a časových harmonogramů. Seznam všech nutných funkčních požadavků konzultujte se zadavatelem. Systém otestujte jak z hlediska správné funkcionality, tak z pohledu uživatelského rozhraní s reálnými uživateli. Seznam odborné literatury: Dodá vedoucí práce

Vedoucí: Ing. David Sedláček Platnost zadání: do konce letního semestru 2013/2014

L. S. doc. Ing. Miroslav Šnorek, CSc. vedoucí katedry

prof. Ing. Pavel Ripka, CSc. děkan V Praze dne 17. 9. 2012

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Rezervační systém pro dárce krevní plazmy Bc. Valentin Kostělej

Vedoucí práce: Ing. David Sedláček

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 30. dubna 2013

iv

v

Poděkování Chtěl bych poděkovat vedoucímu práce za rady při volbě tématu. Mému bratrovi Pavlovi hlavně za technické připomínky. Haně Ptáčkové, kamarádce a studentce 1. LF Karlové Univerzity, za gramatické opravy. A všem lidem, kteří mi ukázali, že stačí na sebe tlačit o něco víc a dostat se k cíli.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem 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 Bílině dne 15. 4. 2013

.............................................................

viii

Abstract Booking system for blood plasma donors is information system for booking and people administration. System is fully modular and safe. Also is fully portable and fully visually editable thanks to jQuery UI.

Abstrakt Rezervační systém pro dárce krevní plasmy je informační systém pro rezervace a správu lidí. Je plně rozšířitelný a bezpečný. Také plně přenositelný a plně vzhledově upravitelný díky jQuery UI.

ix

x

Obsah 1 Úvod 2 Analýza 2.1 Zadání a řešení úkolu . . . . . 2.2 Use Case a funkční požadavky 2.3 Architektura . . . . . . . . . 2.4 Závěr řešení . . . . . . . . . . 3 Návrh řešení 3.1 Databáze CENTRÁLY . . . . 3.2 Databáze LOKÁLU . . . . . 3.2.1 Osoba . . . . . . . . . 3.2.2 Objekt . . . . . . . . . 3.2.3 Otevírací doba . . . . 3.2.4 Jednotka a nedostupná 3.2.5 Ostatní tabulky . . . . 3.3 LOKÁL - PHP . . . . . . . . 3.3.1 Přihlášení . . . . . . . 3.3.2 Změna hesla . . . . . . 3.4 KLIENT . . . . . . . . . . . . 3.5 Závěr . . . . . . . . . . . . . .

1

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . doba . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

4 Implementace 4.1 Implementace LOKÁLU - PHP . . . . . . . . . . . . . 4.1.1 Jádro . . . . . . . . . . . . . . . . . . . . . . . 4.2 Moduly - PHP . . . . . . . . . . . . . . . . . . . . . . 4.2.1 private/aes.php . . . . . . . . . . . . . . . . . . 4.2.2 private/jed_local.php a private/otv_local.php 4.2.3 Ostatní moduly . . . . . . . . . . . . . . . . . . 4.2.4 API PHP modulů . . . . . . . . . . . . . . . . 4.3 Nový modul - PHP . . . . . . . . . . . . . . . . . . . . 4.4 Implementace KLIENTA – API a Hlavní okno . . . . . 4.5 Moduly - KLIENT . . . . . . . . . . . . . . . . . . . . 4.5.1 tabs/uvod.html a aktualita.html . . . . . . . . 4.5.2 tabs/lidi.html . . . . . . . . . . . . . . . . . . .

xi

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

3 3 6 8 11

. . . . . . . . . . . .

13 13 15 15 16 17 18 18 19 19 20 20 20

. . . . . . . . . . . .

21 21 21 24 25 25 25 26 31 31 34 35 35

xii

OBSAH

4.6

4.5.3 tabs/darovani.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.5.4 tabs/objekt.html, profile.html a system.html . . . . . . . . . . . . . . . 35 Nový modul - KLIENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Výhled do budoucnosti

37

6 Testování a použité nástroje 6.1 Úvod . . . . . . . . . . . . . . . . . . . 6.2 Použité nástroje . . . . . . . . . . . . 6.2.1 Vlastní testování . . . . . . . . 6.2.2 PHP a MySQL . . . . . . . . . 6.2.3 HTML a JavaScript aplikace . 6.2.4 NetBeans . . . . . . . . . . . . 6.2.5 http://www.javascriptlint.com/ 6.2.6 http://validator.w3.org/ . . . . 6.2.7 php . . . . . . . . . . . . . . . 6.3 Uživatelské testování . . . . . . . . . . 6.4 Závěr . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

39 39 40 40 40 40 41 41 41 41 42 42

7 Závěr

43

A Příručky – úvod

47

B Návod pro uživatele B.1 Úvod . . . . . . . . . . . . . B.2 Požadavky . . . . . . . . . . B.3 Úvodní stránka . . . . . . . B.3.1 Otevírací doba . . . B.4 Darování . . . . . . . . . . . B.4.1 Výběr data . . . . . B.4.2 Výběr času . . . . . B.4.3 Rekapitulace . . . . B.4.4 Změna a odstranění B.4.5 Moje rezervace . . . B.4.6 Události . . . . . . . B.5 Můj profil . . . . . . . . . . C Návod pro redaktora C.1 Úvod . . . . . . . . . . . . . C.2 Změna od běžného uživatele C.3 Správa lidí . . . . . . . . . . C.3.1 Nová registrace . . . C.3.2 Upravit osobu . . . . C.3.3 Výpis lidí . . . . . . C.3.4 Výpis rezervací . . . C.3.5 Události . . . . . . . C.3.6 Vzkazy . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

49 49 49 50 51 52 52 53 54 54 55 55 56

. . . . . . . . .

59 59 60 61 61 62 63 64 64 66

OBSAH

xiii

C.4 Často kladené otázky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 D Návod pro administrátora D.1 Úvod . . . . . . . . . . . D.2 Správa objektu . . . . . D.2.1 Rozvrh . . . . . D.2.2 Jednotky . . . . D.2.3 Nastavení . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

69 69 71 71 72 73

E Návod pro guru E.1 Správa systému E.1.1 Objekty E.1.2 Import . E.1.3 Logy . . E.2 Nový objekt . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

75 75 75 76 77 78

F Instalační příručka F.1 Požadavky . . . F.2 Instalace . . . . F.3 SLAVE server . F.4 Konfigurace . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

79 79 79 82 84

G Obsah přiloženého CD

85

xiv

OBSAH

Seznam obrázků 2.1 2.2 2.3 2.4 2.5

Starší systém . . . . . Use case . . . . . . . . Základní architektura . Rozšířená architektura Síť . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 3 . 6 . 9 . 9 . 10

3.1 3.2 3.3 3.4 3.5 3.6 3.7

CENTRÁLA . . . . . Osoba . . . . . . . . . Objekt . . . . . . . . . Otevírací doba . . . . Jednotka a nedostupná Zamluvení termínu . . Rezervace termínu . .

. . . . . . . . . . . . . . . . doba . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5.1

Výhled do budoucnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11

Úvodní stránka Otevírací doba Výběr data . . Výběr času . . Rekapitulace . Moje rezervace Moje rezervace Události . . . . Můj profil . . . Změna hesla . . Vzkazy . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

50 51 52 53 54 54 55 55 56 56 57

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8

Správa aktualit . Hledání uživatele Nová registrace . Upravit osobu . . Výpis lidí . . . . Výpis rezervací . Události . . . . . Nová událost . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

60 60 61 62 63 64 64 65

xv

13 15 16 17 18 19 19

xvi

SEZNAM OBRÁZKŮ

C.9 Upravit lidi . C.10 Vzkazy . . . . C.11 Nový vzkaz . C.12 Cizí rezervace D.1 D.2 D.3 D.4 D.5 D.6

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

65 66 66 67

Rozvrh . . . . . . Otevírací doba . Jednotky . . . . Nedostupní doba Nastavení . . . . Odběry . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

71 71 72 73 73 74

E.1 Objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 E.2 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 E.3 Logy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 F.1 F.2 F.3 F.4

phpMyAdmin . . index.php - úvod index.php - výpis Kate - soubory .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

80 80 81 82

Kapitola 1

Úvod Téma diplomové práce je „Rezervační systém pro dárce krevní plasmy“. S tím souvisí velká zodpovědnost, systém musí být bezpečný a také přehledný. Systém bude spravovat data uživatelů a termíny odběrů krevní plasmy, která denně zachraňuje životy mnoha lidí. Starší systém potřeboval rozšíření, a tak vznikla tato práce. Nový systém využívá technologie MySQL, PHP, HTML a JavaScript. Též prostředí jQuery a jQuery UI. Stejně jako tyto technologie, systém je plně rozšířitelný díky modulům. A jelikož jQuery UI je graficky měnitelné pomocí grafických témat, vzhled systému můžete kdykoliv upravit dle svých představ. Kromě běžných úkonů rezervačního systému, tento informační systém dokáže plně nahradit hlavní webové stránky menší odběrné stanice nebo může být využit k obecné správě prostředků a lidí. Systém spravuje převážně separátory, které odebírají krevní plasmu. Krevní plasma se dále zpracovává a pomáhá zachraňovat lidské životy. Také se z ní vyrábí různé druhy léčiv pro popálené pacienty, pacienty s rakovinou nebo se špatnou srážlivostí krve. Díky novému systému nyní můžete provádět rezervace nejen darování krevní plasmy, ale i například krve. Můžete přidávat nebo odebírat odběrné jednotky. Spravovat otevírací dobu nebo dobu, kdy je přistroj mimo provoz. A to i s týdenním opakováním. Můžete různě měnit časovou délku různých druhů darování, nastavit interval mezi odběry nebo nastavit limit dnů dopředu, kdy můžete provést rezervaci. A to s přesností na minuty. V následujících kapitolách si přiblížíme pohled na různé oblasti systému, instalace, uživatelské prostředí a budoucí vývoj.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Analýza 2.1

Zadání a řešení úkolu

Hlavní úkol je zachovat předešlou funkčnost starého systému a rozšířit ji o novou. Analýza starého systému ukázala, že oprava a rozšíření starého systému je náročná a musel bych skoro celý systém přepsat od základu. Proto začal vývoj na „zelené louce“, tedy od nuly. Měl jsem už částečně rozpracovaný systém na správu uživatelů, a po větší úpravě architektury jsem využil jeho základy. Starší systém využíval technologie PHP a MySQL server, nový systém obsahuje i tyto základy.

Obrázek 2.1: Starší systém

Obrázek 2.1 ukazuje vzhled starého systému. Starší systém měl jen základní grafické rozhraní pouze s hodinovými sloty, takže neumožňoval rezervaci přesně na minuty. V přílohách najdete soubor[11], který jsem dostal od zadavatelské společnosti. Ten probereme a doplním ho o další funkčnost.

3

4

KAPITOLA 2. ANALÝZA

„Funkcionalita“ • podporovat procesy spojené s rezervací termínů • systém bude generovat základní statistické přehledy • veřejně dostupný webový server • doba nebude nijak omezena • klient bude své rezervace zadávat sám, prostřednictvím grafického rozhraní • aplikace bude navržena univerzálně, s nastavitelnými parametry • případné modifikace bez hrozby ztráty dat

„Uživatelé“ • Klient • Recepce • Správce • ovládání má být intuitivní a přehledné • vytvořit bezpečnostní opatření • přihlášení pomocí e-mailu a hesla • kontrola odesílaných dat • evidence pouze nejnutnějších údajů

„Základní postupy a pravidla používání“ • konflikt při zapisování dvou uživatelů ve stejný čas • interval, během kterého nelze zapsat další rezervace • délka doby dopředu bude limitovaná • účty tvořeny zaměstnancem • vytvořit bezpečnostní opatření • přihlašovací údaje budou e-mailová adresa a heslo • nastavit otevírací dobu celé stanice

2.1. ZADÁNÍ A ŘEŠENÍ ÚKOLU

5

• individuální rozvrh pro jednotlivé separátory • nastavit mimořádný rozvrh • nastavení jména, loga stanice a kontaktů „Doplňující charakteristiky“ • nový účet - Recepce, Správce • zapsat cizí rezervaci - Recepce, Správce • nastavit systém - Správce • uživateli je poslán e-mail Požadavky na uživatele byly rozšířeny o jednoho uživatele – „Guru“, protože jeden server může mít několik objektů (odběrných míst), což pokrývá toto oprávnění. Přihlášení pomocí e-mailu bylo rozšířeno na přihlášení díky čemukoliv, včetně mezer, háčků a čárek. I evidence byla rozšířená na další nepovinné (však nesmí být nulové) údaje. „Základní postupy a pravidla používání“ byly zohledněny skoro ve všech případech, a také byly rozšířeny o zaslání zapomenutého hesla. Požadavky na rozvrh byly také přepracovány, takže na celé roky stačí jedno otevírací pravidlo (pokud nebudou svátky), o tom více v dalších kapitolách. Původní Use-case (Případy užití) diagram byl rozšířen také a můžete ho porovnat s novým v další kapitole. „Doplňující charakteristiky“ byly také rozšířeny. Z poskytnutého souboru tedy byly požadavky zahrnuty, a navíc i rozšířeny o další možnosti. Funkční požadavky zadavatele teď znáte, a můžete si o nich přečíst v přílohách, jdeme tedy na takzvané „Nefunkční požadavky“, neboli požadavky, které nemají funkci, ovlivňující chování systému, jeho základní vlastnosti. Systém by měl být jednoduchý a rychlý, o čemž se můžete přesvědčit dále. Měl by být přehledný a stabilní, proto byla použita určitá architektura a technologie, o kterých si také povíme dále. Má být samozřejmě i bezpečný, a to jak z pohledu Host-Uživatel (útočník z venku), tak i Uživatel-Zaměstnanec (získání vyššího oprávnění). „Nefunkční požadavky“ • jednoduchý • rychlý • přehledný • stabilní • bezpečný

Popsal jsem požadavky zadavatele, vlastnosti systému a vysvětlil jsem novou funkčnost. V další podkapitole popíšu oprávnění uživatelů, co mohou dělat a jaké jsou funkční požadavky tohoto systému.

6

2.2


Use Case a funkční požadavky

V této části diplomové práce si povíme, jakých rolí může nabývat uživatel (obrázek 2.2) a co může spravovat, což je vlastně i seznam funkčních požadavků.

Obrázek 2.2: Use case Systém rozpoznává 5 rolí – „Host“, „Uživatel“, „Redaktor“, „Admin na objektu“ a „Guru“. Host je nepřihlášený uživatel, který může prohlížet aktuality, otevírací dobu, kontaktní adresu nebo se přihlásit. Až se přihlásí, má alespoň základní oprávnění „Uživatel“, který v systému má číslo oprávnění „1“. Systém ho přesměruje na stránku „Darování“, kde uživatel může vybrat nový termín nebo upravit stávající rezervace. Zde se dají též vypsat minulé rezervace, nebo se zúčastnit událostí. Ve svém profilu uživatel může zobrazit svoje data, změnit heslo a kontaktní informace, popřípadě přečíst vzkazy od redaktora. „Redaktor“ s oprávněním „2“ může na rozdíl od běžného uživatele spravovat cizí rezervace. Též spravuje aktuality a události nebo může poslat jednotlivci, skupině nebo lidem na celém objektu vzkazy. Může vypsat všechny osoby v systému a rezervace na objektu. Také zaregistrovat nového uživatele nebo upravit současného. Uživatel nesmí však mít vyšší oprávnění než „3“ – „Admin na objektu“. Ten spravuje otevírací a nedostupní dobu na objektu, adresu a kontaktní údaje. Určuje též časy pro odběry a počet odběrných jednotek nebo separátorů. Vše toto i něco navíc může „Guru“, který přidává nové objekty nebo typy odběru, čistí staré rezervace, uživatele nebo systémové záznamy. Též může importovat data ze starého systému.

2.2. USE CASE A FUNKČNÍ POŽADAVKY

Funkční požadavky pro uživatele jsou (dědí se): Host: • Zjistit základní informace • Zapomenuté heslo • Přihlásit se

Uživatel: • Spravovat svoje termíny • Odhlásit se • Prohlížet / Přihlásit se na událost • Prohlížet / Změnit svoje udaje • Prohlížet svoje data

Redaktor: • Spravovat cizí termíny • Zakládat nové registrace / úprava a odstranění současných • Výpis lidí / rezervací • Spravovat vzkazy / aktuality / události

Admin na objektu: • Spravovat otevírací a nedostupní dobu / časy odběrů

Guru: • Správa objektů / odběrů / systému

7

8

2.3


Architektura

V této podkapitole si představíme použité komponenty (celky) a jejich spolupráci. Nový systém bude obsahovat následující: máte centrální SQL databázový server, kde jsou uložená jen základní data, jeden a více lokálních serverů, které jsou navzájem propojené, přitom jeden objekt může komunikovat s několika servery, nebo naopak jeden server může obstarávat několik objektů (odběrných míst), a na závěr máte klienta, který má za úkol zobrazit poskytnutá data nebo žádat server o provedení nějaké akce. Všechno tohle může provozovat jak několik počítačů, tak i jeden, a k tomu můžete systém nebo jeho část rozšířit i na jiné, než základní platformy, např. na mobily nebo tablety, bez zásahů do jádra. Centrální SQL databázový server (CENTRÁLA) obsahuje data, která se v systému vyskytují jen jednou. To jsou rezervační data, seznam objektů, seznam a hesla uživatelů a záznamy správy systému, jako jsou vypadlé lokální uzly a zda jsou data na nich konzistentní, nebo nepovolené SQL příkazy. Lokální server má vlastní SQL databázi a PHP část v roli vrátného. Lokálních serverů jsou dva druhy – MASTER a SLAVE. Každý z nich může libovolně zapisovat rezervace a odpovídat na dotazy. Rozdíl je v tom, že pokud máte dva a více lokálních serverů, musíte zajistit stejná data (konzistenci) ve všech databázích, proto je zápis vyhrazen MASTER serveru, a SLAVE se vzdáleně přihlásí na MASTER. Více o tom bude v příslušné kapitole. Server odpovídá v JSON[P] protokolu, což jsou standardizované odpovědi ve formě textu, proto je koncovému klientu jedno, zda se jedná o PHP, Ruby, JSP nebo ASP.NET. Kdykoliv můžete změnit část nebo i celou technologii a klientská část se nemusí měnit. Toto jsou dvě základní části, které může obsahovat jeden server, ba i jedna databáze. Komunikace přes příkazový řádek a textové odpovědi jsme však zažili v minulém století. Proto je tu třetí část – klient. Serveru je jedno, zdá komunikuje s počítačem a prohlížečem, mobilem nebo tabletem. Stačí, když klient reaguje na určité odpovědi a podporuje technologii cookies. Při vývoji klienta jsem se proto rozhodl pro tu nejzákladnější technologii – HTML a JavaScript, koncový uživatel nebo provozovatel tak nemusí mít PHP, ASP.NET nebo JSP server. Nemusí mít ani server, stačí mu novější internetový prohlížeč. Webová stránka je asynchronní (popis v příslušné kapitole) a využívá vývojové prostředí jQuery a jQuery UI.

2.3. ARCHITEKTURA

9

Obrázek 2.3: Základní architektura Obrázek 2.3 má 3 komponenty: HTML+JavaScript aplikace, PHP aplikace a MySQL databáze. Toto je nejzákladnější architektura, kterou jsem zvolil. Povšimněte si prosím, že komponenty nejsou izolované na servery. Tuto architekturu řeším provozem na jednom serveru, není však problém provoz na dvou nebo třech serverech. Popřípadě na serveru a klientu. Veškerá komunikace probíhá v TCP/IP protokolu, což je nejrozšířenější síťový protokol. HTML+JavaScript aplikace zprostředkovává vzhled systému, PHP aplikace obsahuje řídící logiku a MySQL databáze schraňuje data. Dotazy HTML+JavaScript aplikace probíhají přes AJAX, dozvíte se o tom v další kapitole. Zpětná odpověď od PHP aplikace je v JSON nebo JSONP formě, tedy v textově formě, jako je například: {" chyba " : 1 , " v r a t i t " : { " jmeno " " adresa " " email " " mobil " } }

: " Nemocnice New" , :[] , : null , : null

Důvody, proč jsem zvolil tuto architekturu, (rychlost, přenositelnost, mobilní aplikace. . . ) můžete najít v dalších podkapitolách. Teď se spíše podíváme, jak se dá tato architektura rozšířit.

Obrázek 2.4: Rozšířená architektura

Během vývoje jsem rozdělil databázi na dvě skupiny (obrázek 2.4). Na CENTRÁLE se nachází jen málo tabulek a záznamů, které budou obsahovat jen rezervační data, seznam uživatelů a objektů a společné logy. Naopak na LOKÁLU se ukládají záznamy, které se mění méně často – aktuality, otevírací a nedostupná doba, atd. Nejen z důvodu oddělení stabilních (skoro neměnných) záznamů a logiky od záznamů měněných často, ale i z důvodu dalšího rozšíření.

10


Obrázek 2.5: Síť

Systém mohu rozšířit na „Síť“ (obrázek 2.5). Teď můžete k MASTER PHP serveru přidat libovolný počet SLAVE PHP serverů, všechny mohou libovolně zapisovat rezervace a mají každý svoji lokální databázi (LOKÁL1 a LOKÁL2). Servery mají společnou databázi – CENTRÁLA. Tím můžeme zrychlit odezvu až o 100 procent! Jedinou nevýhodou tohoto řešení je nutnost režie zápisu do lokálních databází, kterou má vyhrazenou MASTER server. Na LOKÁLU je uložená například otevírací doba. Jeden klient se připojí k MASTER serveru, druhý ke SLAVE serveru. A oba se mohou ptát na otevírací dobu ve stejný okamžik, bez front a čekání. Tak se zrychlí odezva až o 100 procent. Distribuci zápisu řeší funkce sendToAllNodes($dotaz), kde $dotaz je několik SQL příkazů. Uživatel „master“ se přihlásí na MASTER serveru, bude mít seznam lokálních databází (LOKÁL1 a LOKÁL2) a $dotaz. Nejdříve zkontroluje, zda jsou všechny databáze živé a obsah je konzistentní. Potom všem pošle dávku příkazů k zápisu ve formě transakce. Jestli data nejsou konzistentní nebo uzel vypadl, zápis se neprovede a uloží se záznam do Master logů. Rezervace a přihlášení budou fungovat, jsou na CENTÁLE. Jestli nějaký uzel vypadl dlouhodobě, musí být vyškrtnutý ze seznamu, aby zápis nových uživatelů, aktualit nebo otevíracích dob byl možný. Po návratu uzlu na něj musí být nahrána nová databáze, jako kdyby to byl nový SLAVE server. Když dojde k výpadku MASTER serveru, musíte zvolit nový a upravit záznamy. Starší systém uměl jen rezervace, nebyl rozšířitelný na jiné platformy a umožňoval jen pevné hodinové rezervace na začátku hodiny. Nový systém bude umět víc než rezervace, bude rozšířitelný na jiné platformy a také bude umožňovat nastavit jak časovou délku odběru, tak i rezervace přesně na minuty. A také jiné vlastností. Tím se dostáváme i ke způsobu rozšíření aplikací. Obě aplikace jsou rozšiřitelné díky modulům – souborům, které zvýší funkčnost systému. U každé máte vzorové soubory rozšíření, o jejich využití se něco dozvíte v dalších kapitolách, které na Vás teď čekají.

2.4. ZÁVĚR ŘEŠENÍ

11

Nový systém: • Používá nejrozšířenější technologie • Každá komponenta (celek) je nahraditelná • Každá komponenta má svoje rozhraní • Minimální komunikace přes textové odpovědí • Rozšířitelný díky modulům • Rozšířitelný na jiné platformy • Distribuovaný přistup k informacím • MySQL, PHP, HTML, JavaScript, jQuery a JSON[P]

Seznámili jste se základní a rozšířenou architekturou, kterou můžete dále rozšířit na celou síť serverů. Víte teď, jaké jsou komponenty v systému a jak spolu komunikují. Také víte něco o komunikaci přes JSON (textové odpovědi) a dozvěděli jste se proč byla zvolena taková architektura, a co každá komponenta obsahuje. Příručky a popis jednotlivých funkcí najdete v přílohách.

2.4

Závěr řešení

Máte za sebou úvod, nastínění problémů, co by měl systém umět, jakou má architekturu, funkční a nefunkční požadavky. Toto je tedy konec analýzy a dále můžete se podívat na návrh řešení a implementaci. Předtím, než se podíváte, jak se systém ovládá, pár slov k vývoji. Tato dokumentace vznikla až po vytvoření systému, a jediný nástroj, který jsem používal k vývoji, byl „Kate“, což je poznámkový blok. Až později byly použity nástroje na kontrolu PHP, JavaScript a HTML kódu. Většinu času mi zabralo vytvořit stabilní jádro, pak lokální funkce modulů, a až potom PHP moduly. Nezapomínejte však na vývoj HTML+JavaScript aplikace a její rozhraní. Hodně funkcí prošlo několikrát optimalizací. Nyní má systém 3 hlavní části, jako i 3 typy komponent – HTML+JavaScript aplikace, PHP aplikace a MySQL databáze. Toto jsou tři technologie (a jejich nadstavby), které musíte znát, abyste mohli systém rozšířit a vyvíjet dál. Nyní Vás čeká část, kde se nejen seznámíte s ovládáním nejen grafického rozhraní HTML+JavaScript aplikace, ale též se podíváte na PHP aplikaci a databázi MySQL.

12


Kapitola 3

Návrh řešení 3.1

Databáze CENTRÁLY

V této části se podíváte na část systému nesoucí jméno CENTRÁLA. Jedná se o SQL databázi, která obsahuje hesla uživatelů, seznam objektů, zamluvené a rezervované časy a záznamy systému.

Obrázek 3.1: CENTRÁLA

13

14

KAPITOLA 3. NÁVRH ŘEŠENÍ

Ke správě a vývoji databáze slouží nástroj „DB Designer Fork“[1]. CENTRÁLA má jen základní jednoduchou strukturu. Obsahuje jen minimum věcí společných s LOKÁLEM, a to jsou ID osob a objektů. Vždy platí, že když na LOKÁLU vytvoříte nový objekt nebo nového uživatele, tak se nejdříve vytvoří na CENTRÁLE a pak získáte jeho ID a použijete ho na lokální databázi. Je vidět (obrázek 3.1), že věci, jako ID jednotky nebo ID druhu, nejsou na CENTRÁLE, a spravuje je LOKÁL. Tabulka „Zaznamy_masteru“, kde jsou uloženy logy informačního systému, jako jsou nedostupnost uzlů nebo neprovedené SQL příkazy, které způsobily nekonzistentnost sítě lokálních databází. Pokud máte jen MASTER server, najdete tam pokusy možných útoků. Pokud máte dva a více serveru (Síť), a máte záznam o nekonzistentnosti jednoho z nich, zkontrolujte a opravte, prosím, nekonzistentnost databáze ručně. Úkol této části systému je jednoduchý – rychle poskytnout a zapsat data od CENTRÁLY.

3.2. DATABÁZE LOKÁLU

3.2

15

Databáze LOKÁLU

Zde rozdělím lokální server na dvě části – SQL databázi a PHP část. Tato podkapitola popisuje SQL databázi. Na rozdíl od CENTRÁLY, databáze je rozsáhlá a dávat sem celý obrázek by bylo nepřehledné, proto jej proberu po částech.

3.2.1

Osoba

Obrázek 3.2: Osoba

Největší celek je „Osoba“ (obrázek 3.2). Má identifikaci „id“, svoje data, jako username, jeho MD5 hash, e-mail, telefon, současný klíč pro komunikaci „klic“ a pro přihlášení „loginklic“, o kterých se dozvíte v PHP logice, a další data. Má jak vazbu sama na sebe, v případě registrátora, tak i vazby na tabulky výčtů hodnot, jako jsou „Opravneni“, „Stav_v_systemu“ nebo „Operator“, abych se co nejvíce přiblížil k 3. normální formě databáze. Také vztahy 1:N, jako jsou „Logy“ nebo kdo je autorem „Vzkazy“, kde se ID osoby vyskytuje přímo. Vztahy M:N se řeší díky vztahu 1:N a tabulkám „_has_“ („Osoba_has_Vzkazy“, „Osoba_has_Objekt“ a „Osoba_has_Udalost“), kde se mohou vyskytovat nejen dvojice aktérů, ale i stupeň oprávnění.

16

3.2.2


Objekt

Obrázek 3.3: Objekt

„Objekt“ (obrázek 3.3) sám o sobě neobsahuje hodně informací, jen jméno, e-mail, telefon, mobil a ID adresy. Avšak má hodně vazeb a vztahů, a to včetně identifikační závislosti v případě „Nastaveni_objektu“, kde máte uložená data o způsobu odběru. Máte tu vztahy na otevírací dobu („Mimoradny_den“, „Mimoradny_rozvrh“ a „Tydenni_rozvrh“), kde se objekt vyskytuje jako identifikační klíč. Máte zase klasické vztahy M:N, řešené přes 1:N vztah a tabulky „_has_“ („Osoby_has_Objekt“ a „Vzkazy_has_Objekt“, kde jsou uloženy aktuality). U tabulky „Adresat“ jsem zamítl identifikační závislost, i když by tady klidně mohla být. A pak tu jsou tabulky („Udalost“, „Jednotka“ nebo „Logy“), kde se ID objektu vyskytuje jako atribut přiřazování.

3.2. DATABÁZE LOKÁLU

3.2.3

17

Otevírací doba

Obrázek 3.4: Otevírací doba

Každá otevírací doba (obrázek 3.4) má vazbu na objekt. Jsou tři typy – „Mimoradny_den“ (jeden den, jedno datum), „Mimoradny_rozvrh“ (jak dlouho platí a pro který den nebo dny) a „Tydenní_rozvrh“ (standardní doba, pro ten den nebo dny). V případě dnů, je zde tabulka „Den“, kde jsou uložené jednotlivé dny (1-7) nebo skupina Po-Pá (8). Na každý typ se váže ID otevírací doby v tabulce „Otevreno“, která je jedinečná na rozdíl od pauz. Jelikož oba objekty mohou mít otevřeno 08:00-18:00, nemusí mít stejné pauzy, proto každý má svoje „idOtevreno“. A naopak - dva objekty mohou mít pauzu 14:00-14:30, systém to pozná a vyhnete se duplicitě.

18

3.2.4


Jednotka a nedostupná doba

Obrázek 3.5: Jednotka a nedostupná doba

Poslední část databáze, na kterou se podíváte zblízka, bude „Jednotka“ (obrázek 3.5) a nedostupná doba. Pro nedostupnou dobu platí podobná pravidla, jako pro otevírací dobu, až na názvy tabulek („Mimoradny_cas“, „Mimoradne_nedostupne_casy“ a „Tydenni_nedostupne_casy“) a neplatí zde jedinečnost pro „Nedostupnost“, kde v otevírací době to bylo „Otevreno“. Další rozdíl je, že nedostupná doba se váže na jednotku, ne na objekt. „Jednotka“ reprezentuje spíše pseudo-přístroj, jako například separátor s jedinečným ID, aby se od sebe odlišily.

3.2.5

Ostatní tabulky

Databáze LOKÁLU obsahuje i jiné tabulky. Některé jsou entity, jako je „Udalost“, některé jsou jen výčet („Opravneni“) a některé jsou vztahové („Osoba_has_Udalost“) i nesoucí informace („Osoba_has_Objekt“). Vyjmenovat a popisovat každou z nich tu nebudu, i když každá z nich je důležitá, a nechám to na samostatném procházení zdrojů. Jsou tu i pozůstatky, jako je stav jednotky, který je vždy aktivní, což nemůžete měnit v systému a jsou v základu na „1“, protože změny v PHP části se nemusely promítnout na změny databázové části. Pro plné pochopení databáze doporučuji otevřít zdrojové soubory už ve zmiňovaném programu „DB Designer Fork“, nebo v phpMyAdmin. Další sekcí je řízení obou těchto skupin (CENTRÁLA a LOKÁL).

3.3. LOKÁL - PHP

3.3

19

LOKÁL - PHP

V této části bych rád poukázal na perličky, které provázely vývoj. Nejsou zde diagramy průběhů funkcí, protože všechny jsou lineární. Buď máte všechno v pořádku, nebo Vás systém upozorní, popř. odhlásí (obrázek 3.6 a 3.7).

Obrázek 3.6: Zamluvení termínu

Obrázek 3.7: Rezervace termínu

3.3.1

Přihlášení

Vaše heslo během celé relace se nepošle. Ano, je to popsáno níže. Dostanete řetězec, který je platný jen 2 minuty, spojíte ho dohromady se zašifrovaným heslem a Vaším jménem, a z toho celého vypočtete kontrolní součet, který následně pošlete. Pokud někdo bude mezi Vámi a serverem odposlouchávat heslo, neuspěje.

20


Postup: • Požádám server o „loginklic“ • Server vygeneruje náhodný řetězec a připojí podpis, který je také vázán na IP adresu žadatele • Server pošle mi „loginklic“ a max. do 2 minut očekává odpověď • MD5(MD5(Heslo)), „loginklic“ a UPPERCASE(Username) -> Do jednoho ŘETĚZCE • Pošlu serveru MD5(UPPERCASE(Username)), MD5(ŘETĚZCE), „loginklic“ a číslo objektu • Server pošle mi komunikační „klic“ • „klic“ je vázán na ID uživatele, jeho IP adresu a je podepsaný serverem

3.3.2

Změna hesla

Změna hesla se provádí jinak. Klient vezme současné ID uživatele, středník a kontrolní součet kontrolního součtu nového hesla. Spojí to dohromady a díky funkci OpenSSL a algoritmu AES-256[8] zašifruje tento řetězec - GibberishAES.enc(text, md5_stareheslo)[6], kde text je tento řetězec a md5_stareheslo je kontrolní součet Vašeho starého hesla, který je uložen na serveru. Klient tím získal řetězec, který může dešifrovat jen dvojitý kontrolní součet Vašeho starého hesla a který pošle serveru. Ten to dešifruje, a jestli ID souhlasí, heslo změní.

3.4

KLIENT

Veškerá logika je na stráně PHP serveru, přesto klient zachytí špatné parametry a odmítne poslat příkaz na hlavní server. Nejedná se však o dvojitou ochranu, protože každý může poslat PHP serveru dotaz přes adresovou řádku, a server tento dotaz v případě chyby odmítne. Klient tedy pomáhá nejen grafickým prostředím, ale snižuje i počet dotazů na hlavní server. KLIENT je jen „ochranka“, co vezme kartotéku uživatele, zběžně zkontroluje žádost a pošle jí dál. Je na PHP serveru zda tu žádost schválí.

3.5

Závěr

Toto není závěr návrhu řešení, je to závěr počátečních předpokladů, které Vás čekají v kapitole Implementace. Na další stránce si povíme něco o vývoji, řešení a implementaci systému, se kterým jste se teď setkali. Proto toto není konec ani analýzy, ani návrhu řešení, je to konec počáteční vize, a realizace Vás teprve čeká.

Kapitola 4

Implementace 4.1

Implementace LOKÁLU - PHP

V této kapitole se podíváte na jádro systému. Veškerá logika na MASTER a SLAVE serverech je psána v jazyce PHP, její popis najdete v minulých kapitolách. K vývoji systému jsem zvolil nejrozšířenější webový programovací jazyk PHP, ale jak jsem už psal v úvodu, není problém nahradit tento jazyk platformou ASP.NET, JSP nebo Ruby. Server odpovídá v JSON[P] protokolu, což jak už jsem zmínil, jsou textové odpovědi. Server sám o sobě nemá grafické rozhraní, proto není problém přidat podporu třeba Qt aplikace ve Windows či Linux nebo aplikace pro mobilní platformy Android či iOS. PHP část je napsána v takzvané procedurální formě, aby byla zachována co největší kompatibilita se staršími verzemi jazyka PHP, i když je doporučená verze 5.3. Procedurální forma rovněž zajistí, aby přechod na jinou technologii byl co možná nejjednodušší. PHP část má svoje malé základní jádro a moduly, díky kterým můžete systém rozšířit. Všechny operace, až na jednu, která používá metodu POST, berou parametry z adresového řádku a povíme si o tom něco dále v této kapitole. Všechny moduly vrací zpět JSON[P] odpověď.

4.1.1

Jádro

Ve složce MASTER serveru jsou PHP soubory - jsou to moduly. Ve složce „objekty“ jsou uloženy JavaScriptové soubory, kde jsou uvedeny nastavení objektů pro klienta. Složka „private“ obsahuje soubory jádra. private/.ht-konfigurace.php Kromě hesel, zápisu do LOKÁLU, nastavení zabezpečení a seznamu MASTER a SLAVE serverů, má za úkol nastavit a nastartovat session. Pak jsou tu hesla a nastavení pro spojení s CENTRÁLOU a LOKÁLEM. ’VERYSECURE’ pro paranoidní zabezpečení a ’LOGOUT_CAS’ pro nastavení automatického odhlášení. Jsou tu dva jedinečné klíče ’ID_WEBU’ a ’ID_WEBU2’, které slouží pro ověření a šifrování dotazů. Pak je tu inicializace 3 globálních proměnných pro spojení s databází a seznam serverů v systému. Konfigurace do sebe též začleňuje soubor „pripojeni.php“.

21

22

KAPITOLA 4. IMPLEMENTACE

private/pripojeni.php Tento soubor zajistí spojení se dvěma databázemi CENTRÁLY a LOKÁLU, nebo vypíše chybu a skončí. Dále tento soubor zajišťuje zápis do LOKÁLNÍCH databází, aby obsah byl konzistentní (stejný na všech serverech). Např. když dva lidé zapisují naráz, může vzniknout nekonzistentnost. Příklad – já zapíšu do databáze otevírací dobu, kterou chci použít dále. Mezitím kolega spustí čištění, a jelikož moje otevírací doba není přiřazena, systém ji odstraní. Já pak budu chtít tuto dobu použít a budu mít smůlu. A máme tu chaotické chování systému, protože nevíme, čí příkaz bude rychlejší. Proto se to řeší transakcí. A teď si představte, že chcete zapsat do několika databází na různých serverech, hrůza. Budou zapisovat dva lidé, v první databázi záznam bude mít ID 3 a na druhé ID 4, a teď někdo pošle odstranění ID 3, a to je problém. Proto byl vytvořen uživatel „master“ a funkce sendToAllNodes($dotaz), viz Architektura 2.5. Když jsem člověk, tak se pokusím přihlásit jako „master“ na MASTER serveru. Když tam někdo je přihlášen, tak počkám náhodnou dobu a zkusím se znovu přihlásit, a to 4 krát. Když se přihlásím a server není v údržbě, pošlu zašifrovaný dotaz, a systém ho provede ve všech databázích v seznamu. Toto je zjednodušený popis, systém hlídá i čas dotazu, konzistentnost a dostupnost databází.

private/getset.php Kromě správy hodnot v session, tento soubor nám generuje náhodný řetězec dané délky („loginklic“, „klic“ a nové heslo), nebo také vypíše v JSON[P] chybějící parametr. Dále, má za úkol posílat e-mail na určitou adresu a také zde máme funkci getKlic(). Tato funkce nejen vrátí obsah z adresové řádky, ale také ověří, zda tento klíč platí pro IP adresu klienta a jeho ID, to vše podepsáno systémem díky proměnné ID_WEBU. Je tu i funkce getKontrolniKlic(), která zvyšuje bezpečnost. Postup: • Server dostal požadavek • Pokud jádro není načteno, načte ho • Zkontroluje, co obsahuje adresový řádek • Podle požadavku zkontroluje přihlášení, pravost „klic“, oprávnění a čas přihlášení • U plné kontroly také zkontroluje záznamy přes databázi, ne přes session • Kde také provede getKontrolniKlic() kontrolu SessionID a „klic“ z databázi • Provede se požadavek

4.1. IMPLEMENTACE LOKÁLU - PHP

23

private/promenne.php Vám při startu session nastaví potřebné hodnoty a také přemaže proměnné a klíč v databázi při odhlášení.

private/vstup.php Tento soubor sloučí celé jádro dohromady. Též má funkci zkontroluj(), která dle potřeby provede kompletní nebo běžnou kontrolu uživatele, a případně ho odhlásí. Jádro: • Načtu jednou (require_once) .ht-konfigurace.php • Načtu jednou pripojeni.php • Načtu jednou getset.php • Načtu jednou promenne.php • Také jejích funkce Jsou tu i jiné funkce, všechny z nich jsou zdokumentované a jsou také uvedeny vstupy a výstupy, proto není důvod je tady rozebírat. Teď se podíváte na chvíli pryč ze složky „private“ do hlavního adresáře.

index.php Slouží pro počáteční instalaci systému, kde uživatel zadá potřebné údaje a systém vytvoří databázové tabulky uživatele a vygeneruje výpis, se kterým jste se setkali v příručce o instalaci systému. Využívá tyto soubory – „centrala.sql“ a „node.sql“, kde jsou uloženy vzorové tabulky, „konfigurace_vzor.php“ a „objekt_vzor.js“, kde jsou uloženy vzorové soubory, a soubor „sql.php“ z dílny phpBB[10], který zapíše vzorové databázové tabulky místo phpMyAdmina.

login.php a logout.php Přestože se jedná o moduly, jsou nedílnou součástí systému. Při startu „login.php“ se uživateli vygeneruje takzvaný „loginklic“, ten má celkem 26 písmen (13 náhodných, zbylých 13 obsahuje jeho podpis). Je platný jen 2 minuty, je uložen do session, je vázán na IP adresu žadatele a vše je podepsáno proměnnou ’ID_WEBU2’. První ochrana před nepovolaným uživatelem. Klient vezme uživatelské dvakrát šifrované heslo pomocí MD5, tento „loginklic“ a uživatelské přihlašovací jméno (vše velkými písmeny), spojí to dohromady a to celé dá do MD5 – získá „loginheslo“. Druhá ochrana před nepovolaným uživatelem, který chce odhalit cizí heslo. Klient toto přihlašovací jméno napíše (vše velkými písmeny) a dá MD5 – získá „loginjmeno“. A teď společně s číslem objektu („loginobjekt“) odešle „loginklic“, „loginheslo“ a „loginjmeno“. Získá takzvaný „klic“, který má 26 písmen (13-20 písmen náhodných, zbylé obsahuje podpis,

24


IP adresu žadatele, jeho ID a vše je podepsáno ’ID_WEBU’ ) a se kterým komunikuje se systémem během session a který je uložen v databázi společně s „loginklic“. Třetí ochrana před nepovolaným uživatelem, protože i opakované posílání získaných dat útočníkovi nepomůže, a to tu ještě nemluvím o další kontrole (getKontrolniKlic(), intval(), date()...) - jednoduše každý vstup je kontrolován a transformován. Odhlášení „logout.php“ zničí session a její proměnné, plus zapíše „klic“ do databáze, že jste odhlášen.

4.2

Moduly - PHP

Systém je rozšířitelný díky souborům neboli modulům. Jsou dva různé typy modulů. První má jednu funkci („cron.php“, už zmíněné „login.php“ a „logout.php“, „zamluv.php“, „rezervuj.php“ nebo „odstran.php“), provádí jednu určitou akci bez potřeby doplňujících parametrů. Druhý typ („aktualita.php“, „ jednotky.php“, „objekt.php“, „otev_doba.php“,. . . ) musí mít parametr „akce=X“, kde X je číslo funkce. Oba typy se však volají stejně:

v e r e j n e . php? c a l l b a c k=jQuery1910&akce=7&o b j e k t=1&p o c a t e c n i=0&p o c e t=5 „verejne.php“ – je název modulu callback – je proměnná, která značí, že chceme odpověď v JSONP akce – číslo akce, 7 = vypiš aktuality objekt – parametr akce, číslo objektu pocatecni – parametr akce, počáteční číslo aktuality pocet – parametr akce, počet aktualit

Některé parametry musíte uvést, některé nemusíte. Každá akce chce svoje parametry a musíte se podívat do API rozhraní modulu, co daná akce chce. Proto metodu POST najdete jen u importu uživatelů, kde posíláte soubor. Pro získání dat proto používáte metody REQUEST a GET, a samozřejmě ošetření vstupů (intval(), date() nebo mysqli_real_escape_string()). Nepsané pravidlo je, že modul má dva soubory – jeden v hlavním adresáři serveru, kde je jen kontrola vstupů, volání funkcí a výpis, a jeden ve složce „private“, kde jsou lokální funkce. Také proto používám v jednom modulu lokální funkce z jiných modulů, což snižuje redundanci (zdvojení) kódu. V každém modulu je popsáno, co dělá, a jsou zdokumentované všechny lokální funkce. Proto tady nebudu vypisovat API každého modulu - viz 4.2.4 API PHP modulů, spíše se zaměřím na zajímavé věci. Až na výjimky platí pravidlo UNIXu: psát menší funkce, ale kvalitně, pak to spojit dohromady.

4.2. MODULY - PHP

4.2.1

25

private/aes.php

Je to knihovna, která dokáže dešifrovat řetězec poslaný z JavaScriptu. Slouží ke změně hesla. Když budete chtít změnit heslo, posílat nové a nešifrované není bezpečné. Proto vezmete nové heslo, dvakrát zašifrované v MD5, které bude v této podobě uloženo na serveru. Připojíte k tomu ID uživatele, a zašifrujete to řetězcem starého hesla, které je momentálně na serveru. „aes.php“[8] tento řetězec dešifruje, zkontroluje ID a zapíše nové heslo (viz Návrh řešení 3.3.2 Změna hesla).

4.2.2

private/jed_local.php a private/otv_local.php

Kromě vytváření sítě MASTER a SLAVE uzlů, jsou to jediné knihovny, u které byly velmi náročné na vývoj. Jak bylo uvedeno v 3.2.3 Návrhu řešení, jsou 3 typy otevírací a nedostupné doby, a zkontrolovat při změně pravidel pro co, kdy a jaká pravidla platí, bylo velice obtížně. A jsou tu právě porušení pravidla UNIXu, že funkce má být malá.

4.2.3

Ostatní moduly

• aktualita.php - spravuje aktuality • cron.php - posílá e-maily a SMS • jednotky.php - spravuje jednotky • objekt.php - spravuje objekt • odstran.php - odstraní rezervaci • rez_data.php - vrátí rezervační data • rezervuj.php - provede rezervaci • zamluv.php - zamluví termín • otev_doba.php - spravuje otevírací dobu • profile.php - spravuje můj profil • registrace.php - spravuje uživatele • system.php - spravuje systém • ucet.php - spravuje účet • udalost.php - spravuje události • verejne.php - základní informace

Každý modul používá různé soubory ze složky „private“.

26


4.2.4

API PHP modulů

aktualita.php • akce=1 - Nová aktualita, Potřeba: barva, titulek, datum, text • akce=2 - Vrátí aktualitu, Potřeba: menim • akce=3 - Upraví aktualitu, Potřeba: menim, barva, titulek, datum, text • akce=4 - Odstraní aktualitu, Potřeba: menim cron.php • nic - Pošle SMS a e-maily jednotky.php • akce=1 - Vrátí mimořádný den, Potřeba: datum, idnedostupno, idjednotky • akce=2 - Nastaví mimořádný den, Potřeba: old_datum, datum, idnedostupno, idjednotky, prepis, nedostupno • akce=3 - Odstraní mimořádný den, Potřeba: datum, prepis, idnedostupno, idjednotky • akce=4 - Vrátí mimořádnou dobu, Potřeba: plati_od, den, idnedostupno, idjednotky • akce=5 - Nastaví mimořádnou dobu, Potřeba: old_plati_od, old_den, plati_od, plati_do, den, idnedostupno, prepis, idjednotky, nedostupno • akce=6 - Odstraní mimořádnou dobu, Potřeba: idnedostupno, plati_od, den, prepis, idjednotky • akce=7 - Vrátí týdenní dobu, Potřeba: den, idnedostupno, idjednotky • akce=8 - Nastaví týdenní dobu, Potřeba: old_den, den, idnedostupno, prepis, idjednotky, nedostupno • akce=9 - Odstraní týdenní dobu, Potřeba: idnedostupno, den, prepis, idjednotky • akce=10 - Nové pravidlo, Potřeba: typ, prepis, idjednotky, nedostupno, ostatní dle typu • akce=11 - Vrátí seznam jednotek, Potřeba: • akce=12 - Nastaví počet jednotek, Potřeba: typ, pocet • akce=13 - Odstraní jednotku, Potřeba: idjednotky login.php • nic - Vrátí loginklic • loginklic, loginjmeno, loginheslo, loginobjekt - Přihlášení

4.2. MODULY - PHP

27

logout.php • nic - Odhlásí uživatele

objekt.php • akce=1 - Nastaví jméno, Potřeba: jmeno • akce=2 - Nastaví adresu, Potřeba: ulice, mesto, smer_cislo, stat • akce=3 - Nastaví e-mail, Potřeba: email • akce=4 - Nastaví telefon, Potřeba: telefon • akce=5 - Nastaví mobil, Potřeba: mobil • akce=6 - Nový odběr, Potřeba: druh, priprava, odber, odpojeni, cisteni, interval, max_dnu, zamestnancu • akce=7 - Upraví odběr, Potřeba: druh, priprava, odber, odpojeni, cisteni, interval, zamestnancu, max_dnu, prepis • akce=8 - Odstraní odběr, Potřeba: druh

odstran.php • rezervace - Odstraní rezervaci, Volitelné: user, objekt

otev_doba.php • akce=1 - Vrátí mimořádný den, Potřeba: datum, idotevreno • akce=2 - Nastaví mimořádný den, Potřeba: old_datum, datum, prepis, otevreno, pauzy • akce=3 - Odstraní mimořádný den, Potřeba: datum, prepis • akce=4 - Vrátí mimořádnou dobu, Potřeba: plati_od, den, idotevreno • akce=5 - Nastaví mimořádnou dobu, Potřeba: old_plati_od, old_den, plati_od, plati_do, den, prepis, otevreno, pauzy • akce=6 - Odstraní mimořádnou dobu, Potřeba: plati_od, den, prepis • akce=7 - Vrátí týdenní dobu, Potřeba: den, idotevreno • akce=8 - Nastaví týdenní dobu, Potřeba: old_den, den, prepis, otevreno, pauzy • akce=9 - Odstraní týdenní dobu, Potřeba: den, prepis

28


• akce=10 - Nové pravidlo, Potřeba: typ, prepis, otevreno, pauzy, ostatní dle typu

profile.php • akce=1 - Vrátí uživatelské data, Potřeba: • akce=2 - Změní heslo uživatele, Potřeba: magicstring • akce=3 - Statistika událostí, Potřeba: • akce=4 - Změní kontakty, Potřeba: telefon, operator, email • akce=5 - Statistika rezervací, Potřeba: -

registrace.php • akce=1 - Nová registrace, Potřeba: username, jmeno, prijmeni, telefon, operator, email, narozen, rc, Volitelné: objekt, opravneni, poznamka • akce=2 - Otestuje Username, Potřeba: username • akce=3 - Vrátí uživatele, Potřeba: id • akce=4 - Resetuje heslo, Potřeba: id • akce=5 - Odstraní uživatele, Potřeba: id • akce=6 - Upraví uživatele, Potřeba: id, username, jmeno, prijmeni, telefon, operator, email, narozen, rc, Volitelné: neomluveno, objekt, opravneni, poznamka • akce=7 - Vrátí seznam uživatelů, Potřeba: idfrom, idto • akce=8 - Vrátí seznam uživatelů, Potřeba: idlist • akce=9 - Vrátí seznam rezervací, Potřeba: datefrom, dateto, jedid, uziid

rez_data.php • datum, davam - Vrátí rezervační data, Volitelné: user

rezervuj.php • zadost, odber - Rezervuje žádost, Volitelné: user, upozorneni

4.2. MODULY - PHP

system.php • akce=1 - Nový objekt, Potřeba: jmeno • akce=2 - Odstraní objekt, Potřeba: objekt • akce=3 - Nový odběr, Potřeba: jmeno • akce=4 - Vrátí odběr, Potřeba: iddruh • akce=5 - Upraví odběr, Potřeba: iddruh, jmeno • akce=6 - Odstraní odběr, Potřeba: iddruh • akce=7 - Vrátí logy, Potřeba: • akce=8 - Odstraní logy, Potřeba: • akce=9 - Vrátí MASTER logy, Potřeba: • akce=10 - Odstraní MASTER logy, Potřeba: • akce=11 - Import uživatelů, Potřeba: POST:import_objekt, import_opravneni, FILES:sys_import_file • akce=12 - Odstraní staré rezervace, Potřeba: mesicu • akce=13 - Odstraní sirotky, Potřeba: -

ucet.php • akce=1 - Vrátí nebo obnoví čas přihlášení, Potřeba: • akce=2 - Vrátí nastavený čas odhlášení, Potřeba: • akce=3 - Vrátí jméno uživatele, Potřeba: • akce=4 - Vrátí seznam uživatelů, Potřeba: like • akce=5 - Provede kontrolu prav, Potřeba: stupen • akce=6 - Vrátí uživatele, Potřeba: id • akce=7 - Vrátí nadcházející rezervace, Potřeba: • akce=8 - Vrátí předchozí rezervace, Potřeba: • akce=9 - Pošle vzkaz, Potřeba: barva, titulek, datum, text, komu • akce=10 - Odstraní vzkaz, Potřeba: vzkaz • akce=11 - Vrátí vzkazy, Potřeba: -

29

30


udalost.php • akce=1 - Vrátí událostí, Potřeba: • akce=2 - Přihlásit se na událost, Potřeba: udalost • akce=3 - Odhlásit se z události, Potřeba: udalost • akce=4 - Nová událost, Potřeba: nazev, popis, datum_od, datum_do, misto, barva • akce=5 - Odstraní událost, Potřeba: udalost • akce=6 - Vrátí událost, Potřeba: udalost • akce=7 - Upraví událost, Potřeba: udalost, nazev, popis, datum_od, datum_do, misto, barva • akce=8 - Upraví účastníky, Potřeba: udalost, prihlaseny, jedou • akce=9 - Vrátí účastníky, Potřeba: udalost • akce=10 - Pošle vzkazy potvrzeným, Potřeba: udalost

verejne.php • akce=1 - Výpis objektů, Potřeba: • akce=2 - Darování na objektu, Potřeba: objekt • akce=3 - Standardní otev. doba, Potřeba: objekt • akce=4 - Všechny mim. otev. doby, Potřeba: objekt • akce=5 - Určitá mim. otev. doba, Potřeba: doba, objekt • akce=6 - Svátky, Potřeba: objekt • akce=7 - Vrátí aktuality, Potřeba: objekt, Volitelné: pocatecni, pocet • akce=8 - Všechny mim. otev. doby hromadně, Potřeba: objekt • akce=9 - Standardní nedost. doba, Potřeba: objekt • akce=10 - Všechny mim. nedost. doby, Potřeba: objekt • akce=11 - Sváteční nedost. doby, Potřeba: objekt • akce=12 - Informace o objektu, Potřeba: objekt • akce=13 - Darování na objektu podrobně, Potřeba: objekt • akce=14 - Zapomenuté heslo, Potřeba: md5jmeno, md5email, md5telefon

4.3. NOVÝ MODUL - PHP

31

• akce=15 - Určitý odběr podrobně, Potřeba: objekt, druh • akce=16 - Všechny odběry v systému, Potřeba: -

zamluv.php • datum, davam, jednotka, zacatek - Rezervuje žádost, Volitelné: user, edit

4.3

Nový modul - PHP

Pro nový modul byly vytvořeny soubory „empty.php“ a „emp_local.php“. Jsou okomentované a kdykoliv po zkopírování obou souborů můžete systém rozšířit o danou funkci. Pro vývoj dalších modulů však doporučuji nejdříve prostudovat současný kód, podívat se na hotové systémové metody a funkce. Dále, platí druhé nepsané pravidlo – odpověď má mít vždy příznak „chyba“, kde „1“ znamená OK a minus číslo – kód chyby. V této podkapitole jste se dozvěděli, jaké soubory jsou na serveru a co soubory dělají. Dozvěděli jste se něco o struktuře kódu, posílání dotazů a získávání odpovědí. Doufám, že svůj účel sekce splnila a v další podkapitole se dozvíte, jak to spojíte s JavaScriptem a konečně se podíváte na grafické rozhraní, než na textové odpovědi.

4.4

Implementace KLIENTA – API a Hlavní okno

Dostáváte k uživatelskému rozhraní (GUI). Ne, že by práce v konzoli nebyla zábavná, ale musíte moderní technologie využít naplno. A také, zvyšující se výkon počítačů a mobilů nám pokládá otázku – proč nevyužít tento výkon. Server je moc vytížený na to, aby nám vykresloval tabulku a pak to posílal po síti. Navíc by server musel vědět, jaké zařízení je na druhé straně. To všechno mě vedlo k vývoji systému na bázi JSON serveru (a jeho variantě s „callback“ JSONP). JSON odpověď vypadá následovně: {" chyba " : 1 , " v r a t i t " : { " jmeno " : " Nemocnice New" , " a d r e s a " : [ ] , " e m a i l " : n u l l , " t e l e f o n " : n u l l , " mobil " : n u l l }} Je to unifikována textová odpověď, které rozumí PHP a JavaScript. Tím se dostáváme k architektuře klienta. Klient je napsaný v HTML + JavaScript kódu. JavaScript je ale sám o sobě jen programovací jazyk, jako C nebo Java, pro zkvalitnění práce potřebujeme už hotové knihovny, takzvané „frameworky“. Jejich výhody (šetří kódem a fungují) a nevýhody (kompatibilita prohlížečů) nechám stranou. Jako základní framework jsem si zvolil jQuery 1.9[3] a jeho grafickou nadstavbu jQuery UI 1.10[5]. Pro jejich správné fungování Vám stačí starší Firefox 3, v případě Internet Exploreru, verze 8.0. Osmá verze je dostupná pro zatím nejstarší podporovaný operační systém Windows XP, jehož podpora končí v roce 2014.

32


Funkce v PHP a JavaScriptu spolu nemohou komunikovat napřímo, jako například PHP a MySQL. Pro jejich spolupráci existuje technologie zvaná AJAX (Asynchronní JavaScript a XML). A to slovíčko „asynchronní“ hraje v tomto webu důležitou roli. Ne, že by AJAX neuměl být synchronní (zavolám funkci, čekám na provedení a až potom pokračuji), kombinace jQuery a JSONP nás nutí dodržovat tuto asynchronnost (zavolám funkci a pokračuji dále, a za nějakou dobu dostanu odpověď, kterou zpracuji). Výhodou toho je možnost rychlejšího webu, nevýhodou jsou nároky na programátora. Výhodou použité architektury je nejen nezávislost na koncovém zařízení (dostanu text a je na mně, jak to zpracuji), ale tato struktura také nezatěžuje server, koncový zákazník nepotřebuje mít vlastní PHP server, dokonce mu stačí prohlížeč s podporou posílání AJAX (přesně XMLHttpRequest) dotazů, kde např. Firefox to má v základu. Výhodou je samozřejmě i objem datového přenosu, který je minimální. Teď se podíváte na propojení PHP a jQuery. Až na jednu výjimku, veškeré rozhraní je ve složce „lib“ v klientské části (instalační složka „view“).

/∗∗ ∗ Provede k o n t r o l u p r i h . prav ∗ @param { i n t } s t u p e n − p r i h . prava ∗ @param { s t r i n g } k l i c − k l i c u z i v a t e l e ∗ @returns { none } − v o l a ajax_kontrola_done ( data ) ∗/ f u n c t i o n a j a x _ k o n t r o l a ( stupen , k l i c ) { var adr = ’ u c e t . php? k l i c =’ + k l i c ; adr = a j a x _ s e r v e r + adr ; var v r a t i t = new Array ( ) ; v r a t i t . chyba = −1; $ . ajax ({ u r l : adr , data : { akce : 5 , stupen : stupen }, dataType : ’ jsonp ’ , s u c c e s s : f u n c t i o n ( data , s t a t u s ) { ajax_kontrola_done ( data ) ; }, e r r o r : f u n c t i o n ( data , s t a t u s , e ) { ajax_kontrola_done ( v r a t i t ) ; } }); }

4.4. IMPLEMENTACE KLIENTA – API A HLAVNÍ OKNO

33

Toto je ukázka, na které vysvětlím, jak to funguje. Někde v kódu zavoláte funkci ajax_kontrola(stupen, klic), které poskytnete parametr „stupen“ a „klic“, které následně poskytnete PHP serveru, tedy LOKÁLU. Do proměnné „adr“ zapíšete celou adresu lokálního serveru se jménem modulu a přístupovým klíčem. Vytvoříte proměnnou „vratit“, která se vrátí při selhání dotazu. Přes AJAXový příkaz „$.ajax“, kterému poskytnete „url“ (adresu LOKÁLU), „data“ (co posíláte serveru), „dataType“ (typ serveru a formát odpovědi), „success“ (když je vše v pořádku) a „error“ (když je chyba), se zeptáte serveru, ale nečekáte na odpověď. Aplikace provádí další úkony, a za 10ms nebo i 100ms, i za 333ms přijde odpověď. Pokud vše bylo OK, provede se „success“, tedy zavolá se funkce ajax_kontrola_done(data), kde jsou „data“ odpovědi ze serveru. Když dojde k chybě, tak se provede „error“, a zase se zavolá funkce ajax_kontrola_done(vratit), kde ale „vratit.chyba“ je -1, a funkce si to musí pohlídat. Funguje to na stejném principu, jako telefonování. Někomu zavoláte telefonem, nevíte, kdy to vezme. Až to vezme, my řeknete „zkontroluj záznam ’Josef ’“, on zkontroluje záznam a odpoví „12“, tak Vy otevřete balíček č. 12. Nebo až to vezme, a Vy řeknete „zkontroluj záznam ’Pepa’“, a on odpoví „chyba -1“ nebo když to nikdo nevezme, máte smůlu a žádný balíček neotevřete a upozorníte na chybu vedoucího. A tak funguje ve zkratce asynchronní web – něco zavoláte a nevíte, kdy přijde odpověď. Zase platí nepsané pravidlo, že funkce volání má název „ajax_něco()“ a závěrečná má jméno „ajax_něco_done(data)“. A „ajax_něco_done(data)“ musí mít „data.chyba“, kde 1 znamená OK a něco jiného neOK. Kromě API (rozhraní) k PHP serveru ve složce „lib“ najdete soubor „gibberish-aes.js“[6] od Marka Percivala, tento soubor slouží k zašifrování hesla, aby se zabránilo případným odposlechům. Složka „obr“ obsahuje obrázky použité ve webu. O složce „tab“ se dozvíte v další podkapitole. Ve složce „ui“ jsou uloženy kaskádové styly (CSS) jak systému, tak i jQuery UI a doplňku „wysiwyg“, který vytvoří grafický textový editor. Také zde máte zmíněné frameworky a moduly (doplňky) pro něj ve složce „ js“. Modulů pro frameworky je dostatek[4]. Už jsem se zmínil o „wysiwyg“ (grafický textový editor), moduly s názvem „cookie“ nebo „md5“ programátorovi nemusím vysvětlovat. Modul „migrate“ slouží pro zpětnou kompatibilitu starších modulů, a právě tam se může vyskytnout problém u internetového prohlížeče Internet Explorer. Doplněk „overscroll“, který slouží pro posouvání časové osy v rezervaci díky táhnutí myší, je ve starší verzi 1.6.4, protože novější verze v IE8 hlásí chybu. Musím tak použít starší verzi modulu a modul „migrate“. Proto chci upozornit další vývojáře, že ne vždycky novější verze znamená něco lepšího, ale také i nefunkčnost na starších systémech. Doplněk „dataTables“ jsou tabulky a „form“ je nástroj pro AJAXový POST bez nutnosti přesměrování, použitý u importu osob. V hlavním adresáři klienta najdete též CSS styly, které určují vzhled hlavní stránky a modulů. Rovněž tam najdete ikonku webu nebo soubor „lang.xml“. Což nás vede k další vlastnosti webu – multijazyčnost[2]. Internetová stránka je za běžného provozu v češtině, přitom v požadavcích je vícejazyčnost webu. Právě v „lang.xml“ je prozatím jen český a anglický jazyk, rozšíření na další jazyky nechám na jazykových odbornících, kterým stačí poskytnout tento jeden soubor. Pozor když budete měnit češtinu, musíte ji změnit jak v souboru „lang.xml“, tak i v kódu aplikace. „lang2.xml“ má jazyková data pro zaměstnance.

34


Pomalu se dostáváte k závěru této kapitoly, a to k souborům „index.html“ a „index.js“. Tento HTML soubor je napsán v XHTML Strict normě, což zaručuje ten nejpřesnější standard ve všech prohlížečích. Jinak tu není nic závratného, máme zde metadata, odkazy na kaskádové styly a skriptové soubory, pak už je to čistý HTML kód, který vytvoří základ vzhledu stránky. Soubor „index.js“ už z názvu značí, že se jedna o JavaScriptový dokument. Máte zde nějaké globální proměnné, nějaké funkce, které jsou samozřejmě okomentované, a jQuery funkci $(function()), která se provede po načtení stránky. Zase, nebudu tu rozebírat, co dělají jednotlivé funkce, toto není příručka, ale návod, který nám má pomoct pochopit strukturu a vlastnosti systému. Pokud chcete vědět, jaké funkce jsou v systému, otevřete kód v textovém editoru, a máte tam vše zdokumentováno – vstupy, výstupy a co daná funkce dělá. V další podkapitole se dozvíte něco o modulech do systému a jak vytvořit vlastní. Doufám, že tato kapitola Vám pomohla pochopit, co všechno obsahuje instalační složka „view“ a k čemu slouží jednotlivé soubory. Omlouvám se za větší používání technických termínů a zkratek, které nezasvěcenému čtenáři budou připadat jako španělská vesnice. Děkuji, že jste dočetli až sem, trochu porozuměli klientské části a jdeme na další sekci.

4.5

Moduly - KLIENT

Stejně tak, jak byla rozšířitelná PHP aplikace, musí být rozšiřitelná i klientská aplikace. Přesto platí logické pravidlo – musíte nejdříve rozšířit PHP část a k tomu dělat grafické rozhraní v HTML+Javascript kódu. Neplatí však, což jste mohli vidět u souborů ve složce „lib“, že modul v PHP musí přesně odpovídat modulu v klientském API (rozhraní). Klient může volat libovolně jakékoliv moduly na LOKÁLU a provádět jakékoliv akce. Jak jste se už dozvěděli z minulé podkapitoly, můstek mezi PHP a JavaScriptem zaručuje AJAX, díky souborům ve složce „lib“. Už víte, co je na straně PHP aplikace, je na čase se podívat podrobněji, co je na stráně klientské aplikace. Nastínil jsem, jak probíhá komunikace po tom můstku, a trochu jsem řekl o souborech „index.html“ a „index.js“, o něž se opřu. Je na čase otevřít složku „tabs“, kde jsou uloženy HTML stránky, které se načítají do hlavního okna. Na rozdíl od souborů zmíněných dříve („index.html“ a „index.js“), tyto soubory nejsou rozdělené do dvou částí – tj. JavaScript a HTML jsou v jednom souboru. Také musíte zachovat určitou HTML strukturu, protože po načtení zvolené stránky se na ní aplikují transformace od jQuery UI. Jak jQuery, tak i jeho grafická nadstavba jQuery UI, jsou dynamické, neboli dokážou určitou část HTML kódu změnit v objekt, který reaguje na určité podněty. Vysvětlím to na příkladu. Máte díly od auta, řeknete mechanikovi (tedy jQuery UI), že je to auto, a on Vám to auto postaví, a Vy můžete to auto řídit. Toto v podstatě udělá jQuery UI se stránkou, kterou načte. Ale nemohou to být díly z lodi, když chcete auto. Proto musíte dodržovat určitou strukturu HTML kódu, aby to fungovalo správně.

4.6. NOVÝ MODUL - KLIENT

4.5.1

35

tabs/uvod.html a aktualita.html

Jsou to stránky, které se Vám zobrazí při startu, kde se dozvíte o novinkách a otevírací době.

4.5.2

tabs/lidi.html

Tady můžete spravovat lidi a vidíte tuto stránku, když klepnete na tlačítko „Správa lidí“

4.5.3

tabs/darovani.html

Největší a též nejdůležitější stránka rezervačního systému. Obsahuje různé grafické a logické části, kterým se raději vyhneme a necháme je na samostatné prostudování kódu, který samozřejmě je vždy zdokumentován.

4.5.4

tabs/objekt.html, profile.html a system.html

Jsou to další moduly, které odpovídají za správu objektu, systému a uživatele.

4.6

Nový modul - KLIENT

Podobně jako i v PHP aplikaci, máte zde dva soubory („/lib/empty.js“ a „/tabs/empty.html“), které Vám pomohou vytvořit novou sekci v systému nebo pomohou porozumět struktuře současných. Soubor „/lib/empty.js“ má ukázkové funkce volání lokálního PHP serveru, které jsem už vysvětlil, a snad jste pochopili, v minulé podkapitole. Ba „/tabs/empty.html“ má popsanou a zdokumentovanou strukturu sekce, kterou by měl pochopit běžný programátor webových aplikací.

Pokud jste přečetli všechny návody této diplomové práce, měli byste něco vědět o souborech, technologiích a způsobu jejích využití. Dozvěděli jste se, kam se podívat při vývoji nebo změně systému. Běžným uživatelům však stačí se jen přesvědčit, že systém funguje. Toto nebyla příručka, která by obsahovala výčet souborů a jejich funkcí. Toto byl návod, průvodní dopis, textový popis systému, který měl pomoct pochopit, kde a co všechno máme. Pokrok ale nezastavíš a dále se dozvíte, kam může směřovat další vývoj – vzhůru k oblakům.

36


Kapitola 5

Výhled do budoucnosti Prošli jste hodně. Z obyčejného zadání rezervačního systému, přes úvod, analýzu, seznámení se s architekturou a funkčními a nefunkčními požadavky, až na konec návody a popisem částí. Teď se podíváte do budoucnosti, a na to, co všechno může čekat tento projekt. Nejhorší vyhlídky, které mohou nastat, jsou ty, že tato práce bude k ničemu. Nedostane oblibu a podporu uživatelů nebo se nahradí komerčním konkurenčním softwarem. Skončí jako zaprášená diplomová práce v univerzitní knihovně. To by ale bylo smutné, a přidáme trochu naděje. První směr rozvoje, který vidím, je rozšíření na mobilní aplikaci (obrázek 5.1):

Obrázek 5.1: Výhled do budoucnosti Právě zvolená architektura nám dovoluje téměř cokoliv. Potřebujete jen klientskou část, která umí pracovat s JSON nebo JSONP protokolem a práce se session. Popřípadě se dá naprogramovat JSON parser, neboli program, který převede textovou odpověď na data, což pro zvolenou architekturu nebude problém. A nejen odpověď je textová, PHP aplikaci můžeme kompletně řídit textovým rozhraním, takže vůbec nejste závislí na AJAX technologii. Vnější vývoj tedy spočívá v rozšíření platforem, nejen webové aplikace.

37

38

KAPITOLA 5. VÝHLED DO BUDOUCNOSTI

Vnitřní vývoj vidím ve tvorbě modulů, též známých jako soubory rozšiřující funkčnost systému. Tato práce se vlastně točí kolem skupiny modulů, které mají na starost rezervace. Dokonce i přihlášení do systému je řešeno modulem. Což nás přivádí na další směr vývoje – bezpečnost. Přestože zde jsou jedinečné mechanismy zabezpečení, které samy o sobě zabrání téměř jakémukoliv útoku, spojení s dalšími technologiemi (HTTPS nebo databázové certifikáty) udělá ze systému pevnost. Avšak i všechny zmíněné technologie jsou napadnutelné, zvlášť, když jsou teď ve vývoji různé algoritmy, které dnešní zabezpečovací technologie obejdou. Proto například i do našich počítačů musíme instalovat záplaty pro operační systémy a aplikace. Toto je tedy náhled na možný vývoj. Rozšíření platforem, tvorba nových a vylepšení současných modulů a neustálé sledování dění ve světové bezpečnosti informačních technologií. Na další stránce Vás čeká testování a závěr, kde shrnu přínos aplikace a i této práce.

Kapitola 6

Testování a použité nástroje 6.1

Úvod

Pověděl jsem něco o vývoji aplikací jak v minulých kapitolách, tak i v úvodu. Otázka zůstává ale nezodpovězená – Je systém funkční? O tomto i dalších postřezích si povíme v této kapitole. Zajisté Vám nemohly uniknout problémy s registrem vozidel. Systém byl pomalý, firma vývojářů nezkušená a napojení na centrální registry také nebylo moc úspěšné. Člověka napadne otázka: „Proč?“. Nedostatečné testování byl možný důvod. Proto i já, jak už jsem psal na začátku práce, se rozhodl pro malé funkce, u každé jsem kontroloval funkčnost a postupně jsem přidával další výpočet do celku po vzoru spirály. Problém nastal, když už jsem měl už hotový celek, který fungoval, ale potřeboval jsem sjednotit rozhraní, a tak jsem změnil API PHP aplikace. Došlo právě k tomu, co u registru vozidel, systém zkolaboval. Musel jsem pak každou funkci testovat znovu. Novější vývojové prostředí, jako jsou NetBeans nebo Eclipse, mají automatické testy, a tak programátoři zlenivěli. Enterprise Architektor zas pro ně vygeneruje kód z takzvaného „Modelu“. Ani jedno jsem z toho nepožil v době vývoje. Ne, že by to nebylo dobré nebo bych to neuměl, ale já jsem byl jediný vývojář a nepotřeboval jsem to s někým sdílet nebo někomu vysvětlovat. Jediné, co jsem potřeboval, byl pokročilý poznámkový blok – Kate. Až všechno bylo sepsáno, otestováno a rozhraní bylo stabilizováno, poté jsem použil různé nezávislé kontrolory (validátory) kódu, které odstranily drobné chyby. Důvodů tohoto řešení je hned několik. První – věděl jsem, kde a jak část programu dělá svou práci. Druhý – mohl jsem definovat přesně, co každá funkce dělá. U „Modelu“ s proměnnými, a zvlášť globálními, vůbec nepracujete, proto to může být velice pomalé. Došlo sice k poskvrnění programátorského pravidla o globálních proměnných, ale pokaždé žádat server o stejná data, a pak data upravovat podle nového pravidla (např. u otevírací doby), by bylo zbytečně pomalé, jak je to popsáno v „Modelu“. Zkušenější vývojář zálohuje data, i kdyby měl použít globální proměnné, a nemusí se ptát znovu serveru. Třetí důvod – mohl jsem krok po kroku sledovat chování aplikace a opravit chod, než kdybych navrhl celý proces, který bych pak těžko optimalizoval. Popsal jsem vývoj a testování, proč jsem se rozhodl pro tento způsob vývoje a v další sekci se podíváte na použité nástroje a způsoby testování.

39

40

KAPITOLA 6. TESTOVÁNÍ A POUŽITÉ NÁSTROJE

6.2 6.2.1

Použité nástroje Vlastní testování

Žádné analyzátory, unit testy či generátory jsem nepoužil. Otevřel jsem poznámkový blok a psal. Až jsem měl hotové funkce a podmínky, kód jsem už přeložil nebo spustil. A ne jen tak spustil, ale nastavil jsem kompilátor nebo interpreta, aby hlásil i tu nejmenší chybu a varování. A tak jsem pokračoval, dokud jsem neměl celek – testoval jsem každou funkci, kontroloval jsem nebo upravoval vstupy, a optimalizoval jsem je.

6.2.2

PHP a MySQL

Nastavil jsem v php.ini, aby mi vypsal všechno, co se mu nelíbí, a to včetně neinicializovaných proměnných, i když implicitně je to nula. Kontroloval jsem přístup k databázím, aby nedošlo při paralelnímu přístupu k nekonzistentnosti nebo náhodným výsledkům. Proto chci upozornit na použití takzvaného „multiquery“, což je několik MySQL dotazů v jednom řetězci. Když toto budete provádět, a pak i číst například vložené ID, tak nemusíte dostat výsledek, protože ještě není zapsaný. Budete proto muset buď dotaz rozdělit na jednotlivé, nebo zapisovat tuto dávku společně s použitím posledního vloženého záznamu. V PHP modulech také najdete řádek: error_reporting(0); Tento řádek vypne výpis chyb, na které narazí. A také se můžete přesvědčit, že je okomentovaný, takže PHP server vypíše všechny chyby. Celé testování jsem prováděl v tom to režimu, a na žádnou chybu jsem nenarazil. S tím souvisí i JSON a JSONP výstup. Tento výstup by při výpisu chyby byl neplatný, i přestože se může provést, tak pozor na hlášky. Tvrdit, že PHP aplikace je bezchybná nemohu, i přestože se tak tváří. Potřebuje projít zátěžovými testy a testy s větším počtem uživatelů. Což jsem také popisoval v úvodu ohledně registru vozidel. Testem se musí ale projít i klientská aplikace, o čem se dozvíte v další sekci.

6.2.3

HTML a JavaScript aplikace

Výhodou této platformy je dostatek volně šiřitelných nástrojů na hledání chyb. Další výhodou je, že tato část jen zobrazuje data, provede menší kontrolu a posílá dotaz PHP aplikaci. Proto je skoro jedno, zdá tato aplikace bude obsahovat chyby, protože všechno má odchytit PHP aplikace. Musím upozornit zaměstnance a administrátory, že tato aplikace je přenositelná a upravitelná dle požadavků zákazníka. Proto musíte vědět, že pracujete s „pravou“ aplikací. Je to jako když do svého domácího adresáře umístíte soubor „dir.exe“ a poprosíte administrátora, aby ve Vaší složce spustil výpis souborů příkazem „dir“. Provede se „škodlivý“ program, namísto neškodného výpisu. (Proto v Linuxu musíte zadat „./dir“). PHP aplikaci je jedno, zdá jedná s mobilem, touto aplikací nebo „škodlivou“ aplikací, která může odposlouchávat hesla. Proto používejte jen zdroje, kterým důvěřujte. Není to moje chyba, ale obdobně jako u podvodných e-mailů, kde Vám přijde upozornění jakoby z Vaší banky, že musíte změnit údaje, a uvede odkaz na cizí stránky, i tady člověk musí vědět, s kým jedná.

6.2. POUŽITÉ NÁSTROJE

6.2.4

41

NetBeans

I přestože je to výkonné prostředí pro vývoj, které má podporu PHP, HTML a JavaScript, nepoužil jsem ho při vývoji. NetBeans byl původně navržen pro jazyk Java, a také je v tom dobrý. Naopak doplňky, které zapnou podporu C/C++, PHP nebo HTML obsahují jen základní funkce. Nedokážou upozornit na nedeklarovanou nebo nepoužitou proměnnou. Nedokážou správně pracovat s XHTML a také jQuery logikou, kde pracujete s „id“ nebo „class“, a hlásí je jako nevyužité. To co umí, je formátování kódu. Takže kódy ve zdrojových souborech jsou zarovnaně. Také mě upozornil na některé podmínky („===“ místo „==“) v JavaScriptu, které nedokázal odhalit další nástroj.

6.2.5

http://www.javascriptlint.com/

Výborný nástroj na kontrolu JavaScript kódu. Odhalí už zmíněné podmínky, středníky, tečky a závorky v kódu. Mohu poznamenat, že jak tady, tak i v NetBeans, prošel kód této práce na zelenou.

6.2.6

http://validator.w3.org/

Asi nejrozšířenější nástroj na kontrolu standardu HTML. Zase mohu hlásit, že statický kód je v tom nejpřísnějším standardu „XHTML 1.0 Strict“. Tady však musím upozornit, že prohlížeče tento standard předělají na svůj, aby vzhled byl co nejvíce jednotný v každém prohlížeči. Také jak jQuery, tak jQuery UI upravují HTML a JavaScript dynamicky, takže konečný kód má jiný standard. Dokonce když dáte v prohlížeči uložit stránku do souboru, tak například místo „
“, což je standard XHTML, bude uloženo „
“, což už je standart HTML.

6.2.7

php

Jako nejlepší nástroj pro kontrolu a testování jsem využil přímo interpreta tohoto programovacího jazyka – program php. V php.ini jsem nastavil hlásit a vypsat všechny chyby (E_ALL), pro znalce C/C++ je to něco jako režim Wall a pedantic. Do toho jsem ještě doinstaloval pluginy, které také prověřily kód.

42

KAPITOLA 6. TESTOVÁNÍ A POUŽITÉ NÁSTROJE

6.3

Uživatelské testování

Úkol: • Přihlásit se • Provést rezervaci na příští týden ve středu v 15:15 • Odhlásit se Toto testování jsem prováděl jak já, tak i kamarádí a kolegové různých věkových skupin a vzdělání. Dostál jsem několik připomínek, které jsem opravil, ale jednalo se o zvýraznění dat. Všechno je přesně definováno a ovládaní je intuitivní, a každý byl schopen provést daný úkol bez toho, aby se díval do příručky. Byly i připomínky, jako aby uživatel neviděl jednotlivé separátory, ale na otázku, jak by to chtěli jinak zobrazit, jsem nedostal odpověď. Grafické rozhraní má za úkol zobrazit přehledně data a PHP aplikace zas hlídá oprávnění. Proto uživatelské testy se týkají jen klienta a vzhledu, protože každý modul PHP aplikace na začátku provede kontrolu práv uživatele. A i běžný nezkušený uživatel dokázal provést rezervaci bez příruček, které najdete na konci této práce. Tím bych tuto sekci ukončil a nechal uživatele udělat názor na vzhled a chování aplikace.

6.4

Závěr

Důležité je, aby kód obsahoval co nejméně chyb, proto jsem zvolil tento vývoj a testování. O funkčnosti webu se můžete přesvědčit na veřejném serveru:

Adresa: http://rs-diplomka.php5.cz/view Username: admin, valentin, user4 Heslo: Heslo123

Též v příručkách najdete ukázky funkčnosti jednotlivých modulů, a každý z nich byl testován, jak jsem popsal výše.

Požadovaná funkčnost byla splněná dle poskytnutého souboru a starého systému. Ba i doplněná o další. Systém je připraven k ostrému provozu. Je modulární a dokáže pracovat jak s jinými klienty, včetně mobilních platforem, tak i s rozhraním proprietárních a otevřených modulů. Tedy vytvořil jsem stabilní základ a funkčnost, bezpečný web a čeká nás závěr této písemné práce.

Kapitola 7

Závěr Závěr? Zní to, jako kdyby něco mělo skončit. Ano, blížíme se ke konci této diplomové práce, tedy písemné části. Konce jsem nikdy neměl rád, i přestože všechno jednou skončí a my musíme jít dále. Dále zkoumat nové možnosti a příležitosti. Konce starých dobrých časů na střední, bezstarostných časů dětství nebo krásných časů v práci asi zažil každý. Občas se tam chceme vrátit a změnit to, co bylo. Pak si ale uvědomíme, že díky těm časům a koncům jsme lepší než předtím a díky nim jsme teď tam, kde jsme. Někdo v horší situaci, někdo v lepší. Toto je i tento případ. Tato diplomová práce vznikla na základě něčí potřeby, jehož potřeba teď končí nebo změnila jeho pohled. Tato diplomová práce uzavřela jednu z kapitol života studenta ČVUT. Tato diplomová práce zůstane v paměti čtenářů a, jak jsem už psal, v universitní knihovně. Nezbývá jen doufat, že bude dobře sloužit. Když otevřete stránky ať už Vašeho oblíbeného vyhledávače, nebo sociální sítě, denně vidíte práci stovek až tisíců programátorů. Některých nezkušených, některých průměrných a některých nadprůměrných. Nějakého studenta, zaměstnance nebo vzor ze šablony, který ale předtím někdo vytvořil. Stránky informativní, poučné, zábavné nebo jako tato práce – rezervační. Jsou placené nebo open-source platformy. Stránek jsou na světě milióny, tisíce z nich jsou kvalitní a máme zde stovky technologií. Výkon prohlížečů se zvyšuje, zvyšuje se i náročnost na kvalitu stránek. Byl to jeden z důvodů, proč starý systém dosloužil. Přestože ve své době mohl patřit ke špičce. Každý projekt má svou životnost. Vždy přijde čas se poohlédnout po nových možnostech. Zda se tento projekt usadí a kolik vydrží, nemůžeme s jistotou říct. Proto byla tato diplomová práce rozdělená na několik částí a různé technologie. Každá část je nahraditelná a můžeme ji libovolně změnit nebo optimalizovat. Toto jsem už řešil v předchozí kapitole. Nové technologie nás tlačí dopředu a ten, kdo se zastaví, se těžko vrátí zpět na výsluní. Odešli jsme ale od tématu, a je na čase se k němu vrátit. Právě jste dočetli dokumentaci k diplomové práci, která řeší problematiku rezervačního systému pro dárce krevní plasmy, věci, která jak už jsem naznačil, je dost důležitá pro každého z nás. Výsledek můžete vidět jak před sebou, tak i ve svém internetovém prohlížeči. Výsledek, který funguje a který můžete používat. Výsledek, co uvádí práci studenta elektrotechnické fakulty. A výsledek, jenž je bezpečný a spolehlivý. A toto je jeho poslání a účel.

43

44

KAPITOLA 7. ZÁVĚR

Literatura [1] DB Designer Fork. http://sourceforge.net/projects/dbdesigner-fork/, stav z 1. 3. 2013. [2] Google. http://google.com/, stav z 1. 3. 2013. [3] jQuery, . http://jquery.com/, stav z 1. 3. 2013. [4] jQuery plugins, . http://plugins.jquery.com/, stav z 1. 3. 2013. [5] jQuery UI, . http://jqueryui.com/, stav z 1. 3. 2013. [6] Gibberish AES. https://github.com/mdp/gibberish-aes/, stav z 1. 3. 2013. [7] jsdoc-toolkit. http://code.google.com/p/jsdoc-toolkit/, stav z 1. 3. 2013. [8] PHP manual, . http://php.net/, stav z 1. 3. 2013. [9] phpDocumentor 2, . http://www.phpdoc.org/, stav z 1. 3. 2013. [10] Stack Overflow. http://stackoverflow.com/, stav z 1. 3. 2013. [11] PAVEL KANTOR, D. V. Specifikace požadavků, 2012.

45

46

LITERATURA

Příloha A

Příručky – úvod Tato část má za úkol seznámit jak běžného uživatele, tak i redaktora, administrátora na objektu, guru, ba dokonce vývojáře, s tím, co systém umí a co byste měli zvládnout vy. Počáteční kapitoly jsou nejjednodušší, ale každá další chce hlubší znalosti problémů nebo technologie. Můžete narazit na pojem nebo termín, kterému nebudete rozumět, protože jste nějakou kapitolu nebo kapitoly přeskočili, přestože se budu snažit psát co nejméně odborně, i když to Vám může připadat dětinské a samozřejmé. Také se budu pokoušet uvést jednoduché příklady ze života, abyste pochopili, jak systém funguje. Jak jsem upozorňoval předtím a budu upozorňovat dále, toto jsou návody, ne příručky. Nehledejte zde manuál k funkcím a souborům, co soubory dělají a vysvětlení seznamu akcí. Proto existují přílohy na CD, kde najdete až 100 stránkovou automaticky vygenerovanou dokumentaci PHP aplikace[9][7]. Po přečtení příslušných kapitol budete znát základní vlastnosti systému pro určitého uživatele. Některé vlastnosti jsou však vynechané nebo jen nastíněné. Určité způsoby, jako rozbalovací seznam, jsou intuitivní. Intuitivním jsem se pokoušel udělat i celé ovládání. Pokud jste běžný uživatel, můžete tuto část přeskočit. Pro redaktora mám tip, aby vyplňoval všechny položky ve formuláři, i kdyby tam musel napsat „nemá“. Admin na objektu by měl přečíst, jak fungují otevírací a nedostupní pravidla, aby se předešlo nedorozumění, že to pravidlo tam je, ale „není“ v systému. A guru ať zkontroluje MASTER logy, když systém nechce zakládat nové rezervace nebo měnit aktuality. A všichni, koho jsem zmínil v minulém odstavci, mohou tento návod jen prolistovat a hledat zde odpovědi, pokud narazili na problém, který nemohou vyřešit, což doufám nenastane. Na další stránce se dozvíme, jak vypadá úvodní stránka a co všechno tam najdeme. Výlet do grafické části začíná.

47

48

PŘÍLOHA A. PŘÍRUČKY – ÚVOD

Příloha B

Návod pro uživatele B.1

Úvod

Žádný návod či příručku nepotřebujete. Web je intuitivní a vše, co se v této kapitole dozvíte, jsou spíše výpisy funkcionality a místa, kde máte tuto funkčnost hledat. Rozhraní bylo inspirováno ze známých a často používaných webů, jako jsou sociální sítě, on-line TV programy nebo e-shopy. Samozřejmě stejné ovládaní mají i jiné internetové stránky. Takže pokud nemáte problém, který nemůžete vyřešit, klidně tuto kapitolu přeskočte a jděte rovnou na internetové stránky. Jestli se chcete dozvědět více o tom, co web umí, směle čtete dál.

B.2

Požadavky

Webové rozhraní využívá vývojové prostředí, neboli framework, jQuery, jQuery UI a jeho zásuvné moduly (pluginy). Proto se požadavky na internetové prohlížeče odvíjí od požadavků těchto vývojových prostředí. Pro správné fungování stránek potřebujete jeden z těchto prohlížečů: Internet Explorer 8 nebo vyšší, Firefox 3+, Opera 10+ nebo současnou verzi Google Chrome nebo Chromium. Pokud jako internetový prohlížeč používáte Konqueror a jeho jádro KHTML, nainstalujte prosím do něj jádro Webkit. Také pozor na identifikaci Konqueroru, nesmíte použít cizí identifikaci prohlížeče nižší, než je uvedeno výše. To platí, i jestli používáte Rekonq.

49

50

B.3

PŘÍLOHA B. NÁVOD PRO UŽIVATELE

Úvodní stránka

Obrázek B.1: Úvodní stránka

První, co spatříte po načtení stránky, jsou úvodní stránky s aktualitami (obrázek B.1), názvem objektu (1) a přihlašovacím formulářem (2). Pokud chcete změnit aktuální jazyk nebo jste zapomněli svoje heslo, použijte, prosím, panel v pravo (3). U zapomenutého hesla musíte znát svoje přihlašovací jméno (Username), e-mail a telefonní číslo. Jestli jste neměli uvedený telefon, zkuste zadat základní telefonní číslo: +420123456789 (bez mezer). Pro přihlášení použijte, prosím, přihlašovací formulář (2) a zadejte buď původní jméno (e-mail) a heslo ze starého systému, nebo údaje, které jste dostali elektronickou poštou. Pozor na malá a velká písmena a Caps Lock. Když heslo zadáte špatně, systém to zaznamená, aby odhalil případného útočníka, a když heslo zadáte 3 krát špatně, budete muset počkat 10 sekund na další pokus.

B.3. ÚVODNÍ STRÁNKA

B.3.1

51

Otevírací doba

Obrázek B.2: Otevírací doba

Na úvodní stránce (obrázek B.2) se též dozvíte běžnou otevírací dobu (1), svátky a mimořádné dny (2) nebo dlouhodobé změny v otevírací době a od kdy do kdy platí (3). Také se dozvíte kontaktní informace a adresu příslušného objektu (4). Návody a nápověda budou přibývat v dalších dvou podsekcích.

52

B.4 B.4.1


Darování Výběr data

Obrázek B.3: Výběr data

Po úspěšném přihlášení budete přesměrováni na stránku „Darování“ do podsekce „Stabilní odběr“ (obrázek B.3). Též zmizí přihlašovací formulář a objeví se tlačítko s Vaším jménem (1), díky kterému se dostanete na svůj profil, a panel s tlačítkem „Odhlásit“ a automatickým odhlášením (2). Čas se obnovuje po projevení aktivity, ale jen po uběhnutí 1/4 celkové doby, tedy po 5 minutách, proto nemějte obavy. Pro provedení rezervace, prosím, zvolte datum v kalendáři (3), které se také zobrazuje níže společně s výběrem, co chci darovat (4). Po zvolení data a odběru, prosím, pokračujte dál tlačítkem „Další krok“ (5).

B.4. DAROVÁNÍ

B.4.2

53

Výběr času

Obrázek B.4: Výběr času

V další sekci (obrázek B.4) se objeví tabulka s časem (1) a seznamem odběrných jednotek (2), v případě darování plasmy - seznam separátorů. Pro pohyb v čase stačí táhnout myší vnitřní pole tabulky. Novou rezervaci můžete provést 3 způsoby. První způsob je, že chytnete myší červený čtvereček „JÁ“ (3) a přitáhnete ho do zeleného pole, kde se ukotví (4). Druhý způsob je kliknutí kamkoliv na zelenou plochu a program ukotví Vaší rezervaci na nejbližší možné místo. Doladit čas a jednotku můžete díky formuláři níže (7), kde nastavíte jednotku a čas přesně na minuty, což je také třetí způsob. Obnovit data můžete díky tlačítku „Obnovit“ (8), dále vidíte žlutě (5) přestávky a výluky nebo červeně (6) rezervace jiných lidí a zamluvené časy. Tlačítkem „Další krok“ (9) zamluvíte určený termín a máte 20 minut na jeho potvrzení.

54

B.4.3


Rekapitulace

Obrázek B.5: Rekapitulace

Třetí a závěrečná sekce je rekapitulace (obrázek B.5). Máte lístek, zamluvený čas, který musíte potvrdit do 20 minut. Na něm jsou uvedeny Vaše údaje, co a kde darujete, začátek, konec a stav (1). Zvolte, prosím, jakým způsobem chcete být upozorněni (2) – ráno emailem nebo/a hodinu předem díky SMS (jen pokud máte operátora O2, Vodafone nebo T-Mobile a máte povolené SMS z internetu). Pro potvrzení rezervace dejte, prosím, tlačítko „Pokračuj“ (3) a počkejte na potvrzovací dialog.

B.4.4

Změna a odstranění

Chcete-li už potvrzenou rezervaci změnit nebo odstranit, máte dva způsoby. První najdete příslušný den a svoji rezervaci (obrázek B.6).

Obrázek B.6: Moje rezervace

Klepnutím na ikonku koše danou rezervaci odstraníte, nebo klepnutím na červenou zónu můžete rezervaci přesouvat, jako by byla nová.

B.4. DAROVÁNÍ

B.4.5

55

Moje rezervace

Obrázek B.7: Moje rezervace Druhým způsobem je výpis všech rezervací v druhé podsekci (obrázek B.7) „Moje rezervace“ (1) stránky „Darování“. Kde nadcházející rezervace můžete upravit (2) nebo odstranit (3).

B.4.6

Události

Další podsekcí stránky „Darování“ jsou „Události“ (obrázek B.8).

Obrázek B.8: Události Díky tlačítku „Načti“ (2) načtete možné události. Vždy tam máte datum, kdy událost probíhá, místo, popis a Váš stav (3). Pokud nejste potvrzen, můžete se na událost přihlásit nebo se z ní odhlásit (4).

56

B.5


Můj profil

Obrázek B.9: Můj profil

Do sekce „Můj profil“ (obrázek B.9) se dostanete kliknutím na tlačítko s Vaším jménem (1) vpravo nahoře. První, co uvidíte, jsou Vaše údaje (jméno, příjmení, oprávnění, kontakty,. . . ) v systému (2), pak si můžete všimnout statistiky rezervací (3) a statistiky událostí (4). Pokud budete chtít změnit přihlašovací jméno (Username), jméno nebo datum narození, obraťte se, prosím, na zaměstnance objektu. Avšak telefon, operátora, email nebo heslo můžete změnit sami.

Obrázek B.10: Změna hesla

Proto slouží druhá podsekce „Změna údajů“ (obrázek B.10). Kde pro změnu hesla zadáte staré heslo a dvakrát nové heslo, které bude mít nejméně 6 písmen. Svůj telefon, operátora a e-mail změníte díky druhému formuláři (3). Změní se tak i údaje pro zapomenuté heslo, proto si změněné údaje pamatujte, jinak se pak budete muset obrátit na zaměstnance objektu.

B.5. MŮJ PROFIL

57

Obrázek B.11: Vzkazy

Třetí a poslední podsekcí jsou „Vzkazy“ (obrázek B.11). Zde se dozvíte důležité sdělení (2), na které Vás upozorní systém e-mailem. Toto jsou základní funkce systému. Doufám, že budete spokojeni, a neváhejte se obrátit na zaměstnance v případě nejasností. Děkujeme.

58


Příloha C

Návod pro redaktora C.1

Úvod

V této kapitole se dozví běžný zaměstnanec, co všechno smí a může dělat a jak na to. Platí zde stejné pravidlo, jako u návodu pro uživatele pro práci, můžete toto přeskočit a podívat se sem jen v případě problému. Také platí pravidlo intuitivního chování a uvádění všech důležitých políček, typu rodného čísla, i když tam dáte nesmysl. Program počítá, že na druhé straně sedí zkušenější uživatel, ale když program objeví zásadní chybu, operaci neprovede a vypíše chybu.

59

60

C.2

PŘÍLOHA C. NÁVOD PRO REDAKTORA

Změna od běžného uživatele

Obrázek C.1: Správa aktualit

První změnou od běžného uživatele je správa aktualit (obrázek C.1). Můžete aktualitu odstranit, upravit nebo přidat novou (1). Po kliknutí se objeví dialog, kde zadáte titulek (2), datum (3), obsah a barvu (5) aktuality. Obsah můžete formátovat jako ve Wordu díky tlačítkům (4) nad ním. Úpravu nebo novou aktualitu potvrdíte tlačítkem „OK“ (6).

Obrázek C.2: Hledání uživatele Další změnou od obyčejného uživatele je formulář „Jméno“ (obrázek C.2) v sekci „Darování“. Díky tomuto formuláři můžete zarezervovat termín cizím jménem nebo vypsat rezervace v podsekci „Moje rezervace“ a upravovat je. Rozdíl je i ve výběru termínů, kde můžete odstranit nebo přesunout rezervaci kohokoliv i s kolizí bloků. Musíte však každou změnu potvrdit, jako byste byli běžný uživatel. Také po klepnutí na rezervaci se Vám vypíše jméno, budoucí a předchozí rezervace v podsekci „Moje rezervace“.

C.3. SPRÁVA LIDÍ

C.3 C.3.1

61

Správa lidí Nová registrace

Obrázek C.3: Nová registrace Další viditelnou změnou je tlačítko nahoře se jménem „Správa lidí“ (1), jehož první podsekcí je „Nová registrace“ (obrázek C.3). V tomto formuláři musíte vyplnit všechny položky, až na poznámku, když tyto údaje nemáte, tak buď nechte, co tam je (telefon, operátor a datum narození), nebo zadejte správný tvar (jméno, příjmení a e-mail (4)), nebo napište třeba „nemá“ u rodného čísla (5). Přihlašovací údaje budou uživateli poslány na e-mail (4). Uživatel musí mít jedinečné přihlašovací jméno (Username (2)), systém Vás upozorní animací buňky v případě, že už takové jméno existuje. Jinak můžete zadat cokoliv od e-mailové adresy po celé jméno s háčky a čárkami – „Tomáš Novák“. Položka „Práva“ určuje oprávnění uživatele. Práva jsou následující: 1 = obyčejný uživatel, 2 = redaktor, 3 = administrátor na objektu, 4 = guru. Nemůžete dávat větší číslo, než je Vaše. Do položky „Objekt“ se píšou ID čísla objektů. Když nejste guru, měňte jenom číslo „Práva“. Když jste guru, můžete do práv napsat: „1,3“ a objektu: „2,5“ – to znamená, že uživatel bude mít práva běžného uživatele na objektu s ID 2 a práva administrátora na objektu s ID 5. Registraci potvrdíte tlačítkem „Nový“ (6). Úspěšný zápis se vypíše v konzoli (7).

62

C.3.2


Upravit osobu

Obrázek C.4: Upravit osobu

Upravit nebo odstranit uživatele a resetovat heslo můžete v další, tedy druhé, podsekci „Upravit osobu“ (obrázek C.4). Formulář se jménem (2) funguje jako v „Darování“. Můžete resetovat heslo uživatele, které se mu odešle na e-mail. Pozor, systém zaznamenává tuto aktivitu, abyste neresetovali heslo administrátorů každou minutu. Upravit osobu můžete jen se stejným nebo s nižším oprávněním v celém systému. Můžete zapsat uživatele do svého objektu díky položkám „Práva“ a „Objekt“ (4). Připsáním do práv „. . . , 1“ (čárka a číslo) pro obyčejného uživatele a „. . . , 3“ do objektu, kde „3“ je Váš objekt. Změnu potvrdíte tlačítkem „Upravit“ (5), kde úspěšné provedení uvidíte v konzoli (7). Zablokovat uživatele můžete odstraněním hodnot z „Práva“ a „Objekt“ (4) a potvrzením „Upravit“ (5). Odstranění buď z Vašeho objektu, nebo z celého systému dosáhnete díky tlačítku „Odstranit“ (6).

C.3. SPRÁVA LIDÍ

C.3.3

63

Výpis lidí

Obrázek C.5: Výpis lidí

„Výpis lidí“ (obrázek C.5) je třetí podsekce „Správy lidí“. Zde můžete vypsat lidi z celého systému a to buď od určitých ID do určitých ID (2), nebo podle seznamu ID (3) ve tvaru: „2,4,5,7“ pro 4 uživatele s daným ID, nebo pole nechat prázdným pro zobrazení všech lidí. Vyhledávat obsah můžete díky „Search“ (4) a listovat v seznamu pomocí tlačítek dole (5).

64

C.3.4


Výpis rezervací

Obrázek C.6: Výpis rezervací

Dostáváte se do druhé poloviny podsekcí. Čtvrtou položkou v seznamu je „Výpis rezervací“ (obrázek C.6). Zde se můžete dozvědět průběh předchozích a nadcházejících darování. Stačí zadat, od kterého do kterého data, a vypsat odběry a zmáčknout tlačítko „Načti“ (2). Můžete zas listovat (3) a vyhledávat v tabulce. Též můžete omezit seznam na určité jednotky nebo lidi, kde zadáte jejich ID v už známém tvaru „3,5,6,9“.

C.3.5

Události

Obrázek C.7: Události

C.3. SPRÁVA LIDÍ

65

Pátou a předposlední podsekcí jsou „Události“ (obrázek C.7). Zde je správa něčeho jiného, než událostí. Aktivní události načtete pomocí tlačítka „Načti“ (2), kde se vypíšou už do známé tabulky. Tlačítkem „Nová událost“ (3) vytvoříte překvapivě novou událost. Tenhle dialog (obrázek C.8) uvidíte při zakládání nové nebo úpravě (6) staré události.

Obrázek C.8: Nová událost Máte tu jméno události (1), počáteční a koncové datum (2), místo (3), popis (4) a barvu (5). Změnu nebo novou událost zrušíte tlačítkem „Storno“, potvrdíte to tlačítkem „OK“ (6). Událost odstraníte tlačítkem koše (7) z obrázku C.7, a lidi, které se událostí zúčastní nebo jsou přihlášeni, zobrazíte díky tlačítku „Upravit lidi“ (4).

Obrázek C.9: Upravit lidi Tento dialog (obrázek C.9) se zobrazí, když chcete upravit lidi, kteří se zúčastní události. Pokud si nejste jistý v ID, zkopírujte obsah a dejte „Výpis lidí“, kde se zobrazí podrobnosti. Přihlášení lidé (1) jsou lidé, kteří mají zájem se události zúčastnit a potvrzení (2) jsou lidé, kteří jste už potvrdili. Je však jedno, jak se kdo přihlašoval nebo byl potvrzen, zapíšete ID už ve známém tvaru: „1,3,13,16“ do dvou položek ve formuláři a dáme „OK“ (3). E-mail zúčastněným (potvrzeným) lidem pošlete díky tlačítku „Poslat e-maily“ (5) z obrázku C.7.

66

C.3.6


Vzkazy

Poslední a šestou podsekcí jsou „Vzkazy“ (1).

Obrázek C.10: Vzkazy

Vzkazy (obrázek C.10), na rozdíl do ostatních položek, nejdou upravit, jen odstranit (5), protože poslané e-maily také nemůžete upravit. Vzkazy můžete načíst pomocí tlačítka „Načti“ (2) a obsah uvidíte dole (4). Nový vzkaz (obrázek C.11) vytvoříte tlačítkem „Nový vzkaz“ (3).

Obrázek C.11: Nový vzkaz

Zadáte ID (1) už ve známém tvaru „3,5,7,13“ nebo „-1“ pro všechny lidi na objektu. Též zadáte předmět (2), datum (3), obsah (4) a barvu (5), jako ve všech ostatních dialozích. Vzkazy odešlete tlačítkem „OK“ (6) a systém upozorní zadané uživatele e-mailem, že mají vzkaz.

C.4. ČASTO KLADENÉ OTÁZKY

67

Tohle je ve stručnosti vše, co můžete jako redaktor provádět, a jestli jste to dočetli až do konce, tak děkuji, protože jak jsem psal na začátku, vše by mělo být srozumitelné a uvítal bych připomínky, proč a čemu jste nerozuměli.

C.4

Často kladené otázky

• Jak zobrazím nebo zapíšu rezervaci jiné osobě, než sobě?

Obrázek C.12: Cizí rezervace Jako redaktorovi se Vám zobrazí v „Darování“ formulář (obrázek C.12), kde můžete po napsání jména, příjmení nebo username vyhledávat určitou osobu. Po zvolení osoby můžete zobrazit její rezervace nebo se přihlásit na termín, jako byste byli dotyčná osoba. • Mohu zapisovat rezervace, nemohu však měnit aktuality a osoby. Platí i pro administrátora na objektu. Požádejte hlavního správce (guru) o kontrolu MASTER logu. • Nemohu změnit osobu, která má na jiném objektu vyšší oprávnění než já. Samozřejmě, je to z důvodu bezpečnosti, kde se dva redaktoři na různých objektech se domluví a změní e-mail u administrátora a pak resetuji heslo. Proto můžete upravovat jen data lidí se stejným nebo nižším oprávněním. • Proč nemohu být současně přihlášen na dvou různých počítačích zároveň? Systém hlídá aktivitu uživatele. Z důvodu bezpečnosti můžete být přihlášen jen na jednom počítači a skoro jakýkoliv pokus o porušení tohoto pravidla odhlásí oba počítače.

68


Příloha D

Návod pro administrátora D.1

Úvod

Dostali jste se k návodu pro administrátory na objektu, druhého nejvýše postaveného oprávnění v systému. Má všechna práva redaktora, plus spravuje otevírací a výlukovou dobu, jednotky, kontakty a odběry na objektu. Je to jediný případ, u kterého se musíte dívat do návodu, protože jsou tu dvě následující pravidla. Pravidlo otevírací doby – máte svátky a mimořádné dny, mimořádné doby a standardní otevírací dobu. Svátky a mimořádné dny jsou jasné – jedno datum, jedna určitá otevírací doba. Zábava začíná u mimořádných dob, musíte nejprve zvolit, od kdy platí, což je zatím v pohodě. Pak musíte zvolit, do kdy platí nebo do neznáma, a zábava začíná. Teď už všechny mimořádné doby, které se kryjí s právě vytvořenou, musí mít stejný počátek a konec, proto musíte zvolit období moudře. Platí to z důvodu jednoznačnosti otevírací doby. Pak musíte zvolit, pro který den nebo dny (Po-Pá) platí, a vždy nejdříve platí jednotlivý den. Pro ostatní dny, které nesplňují podmínku mimořádné doby, platí standardní otevírací doba nebo je zavřeno. V krátkosti: Chci otevírací dobu na 04. 04. 2013 (čtvrtek). Podívám se, jestli je to v seznamu mimořádných dnů – je=dám otevírací pravidlo. Není – podívám se, zda je v seznamu období, co kryje zvolené datum – je=podívám se, zda existuje pravidlo pro čtvrtek, v druhém kole po pravidlu Po-Pá. Není – podívám se po pravidlu ve standardní době pro čtvrtek, a zase v druhém kole po pravidlu Po-Pá. Další vysvětlení – objekt má jediné pravidlo standardní doby, že Po-Pá má otevřeno 08:00-18:00 a nějaké pauzy. Tak je od pondělí do pátku otevřen od 8 hodin do 18 hodin. V pátek je ale málo lidí, tak chcete upravit, aby bylo otevřeno do 16 hodin – tak jen přidáte pravidlo do standardní doby, že pátek má otevřeno 08:00-16:00. Tak od pondělí do čtvrtka máte od 8 do 18, a pátek od 8 do 16 hodin. Zatím rozumíte – pátek má vyšší váhu, tak vítězí. Celý příští měsíc má půlka zaměstnanců dovolenou, tak potřebujete mít zavřeno v pondělí a pátek, a sobotu (jen příští měsíc) mít otevřeno od 10 do 14 hodin. Tak přidáte pravidlo mimořádné doby od 01. 05. 2013 do 31. 05. 2013 pro pondělí, že má zavřeno (prázdný řetězec v „Otevřeno“). Pak přidáte pravidlo od 01. 05. 2013 do 31. 05. 2013 pro pátek, že má zavřeno. Pak přidáte pravidlo mimořádné doby od 01. 05. 2013 do 31. 05. 2013 pro sobotu, že má otevřeno 10:00-14:00. Tak se Vám objeví tabulka mimořádné otevírací doby, která

69

70

PŘÍLOHA D. NÁVOD PRO ADMINISTRÁTORA

platí od 01. 05. 2013 – 31. 05. 2013, kde bude: Pondělí – zavřeno, od Úterý po Čtvrtek – 08:00 – 18:00, Pátek – zavřeno, Sobota – 10:00 – 14:00 a Neděle – zavřeno. Zatím srozumitelné – vždy platí pravidlo nejvyšší váhy. Sobota se Vám osvědčila, ale nechcete to ještě zavádět napevno, protože nevíte, do kdy se Vám to vyplatí. Tak políčko „Platí DO“ necháte prázdné. Nebo v půlce května Vám vypadla hlavní lékařka, která ordinovala ve středu, tak potřebujete mít od 15. 05. 2013 zavřeno ve středu do neznáma. Pokud se pokusíte přidat mimořádnou dobu od 15. 05. 2013 do neznáma (prázdný řádek), tak neuspějete, protože se doby kryjí. Budete muset přidat pravidlo od 01. 05. 2013 do 31. 05. 2013 pro středu, že má zavřeno, pak pravidlo od 01. 06. 2013 do neznáma pro středu a zavřeno. Srozumitelné – protože pravidla na pondělí a pátek platí jen do 31. 05. 2013 a pak už ne. Základní logiku otevírací doby snad chápete, teď pravidla nedostupné doby. Obdobně jako u otevírací doby, máte 3 druhy – mimořádné dny, mimořádné doby a standardní dobu. Platí stejná pravidla data a opakování. Na rozdíl od otevírací doby, nedostupná doba zakáže rezervaci v daný čas. Také platí, že nedostupný čas platí pro skupinu odběru a nedědí se. Např. máte standardní pravidlo, že v pátek jednotka 4, která odebírá plasmu, je nedostupná po celý den. Tak jestli přidáte pravidlo mimořádné doby nebo dne na pátek na jednotku 2, která také odebírá plasmu, v ten den nebo dobu pravidlo na jednotku 4 neplatí, a budete ho muset znovu zapsat. Důvod je jednoduchý, normálně je jednotka 4 v pátek mimo provoz, ale zrovna v ten den máte „Světový den odběru“, a potřebujete mít všechny jednotky aktivní. Proto Vám stačí přidat pravidlo, kde nedefinujete nedostupní dobu, a stačí pro jednu jednotku ve skupině, a funguje to. Jiný rozumnější způsob negování nedostupných časů jsem nenašel. Proto musíte všechny potřebné nedostupné časy pro mimořádný den nebo dobu zapsat znovu. Pořád nesrozumitelné? Tak jinak, pravidla jsou v následujícím pořadí: Mimořádný den – Mimořádná doba pro 1 den – Mimořádná doba pro pracovní dny – Standardní doba pro 1 den – Standardní doba pro pracovní den – Žádné pravidlo. Vždy se vybere to nejvyšší pravidlo pro dané datum nebo den a víc ne – nedívá se také pod sebe. Otevírací pravidla platí pro celý objekt a jednotky a dědí se. Nedostupná pravidla platí pro odběrovou skupinu a nedědí se. Konec popisu a ukážeme si, jak to vytvoříte.

D.2. SPRÁVA OBJEKTU

D.2 D.2.1

71

Správa objektu Rozvrh

Obrázek D.1: Rozvrh

Po přihlášení administrátora na objektu se objeví tlačítko „Správa objektu“ (1). První podsekcí je „Rozvrh“ (obrázek D.1), kde můžete upravit otevírací dobu. Máme tlačítko „Přidat pravidlo“ (2), seznam mimořádných dnů (3), seznam mimořádných dob (4), seznam standardních dob (5) a tlačítka na správu – úprava (6) a odstranit (7).

Obrázek D.2: Otevírací doba

72


Pro nové pravidlo nebo úpravu slouží dialog, který vidíte na obrázku D.2. Zvolíte, nebo máte předvolen, Typ (1) – „Mimořádný den“, „Mimořádná doba“ nebo „Standardní doba“, jejichž popis a účel je popsán v úvodu. Podle Typu zvolíte datum nebo platnost (2) a pro který den (3). Zadáte otevírací dobu ve tvaru „HH:MM-HH:MM“ nebo necháte prázdnou pro zavřeno. Je důležité psát i počáteční nuly (08:00). Zvolíte pauzy (5) ve tvaru „HH:MM-HH:MM,HH:MM-HH:MM,. . . “ – jako otevírací doba oddělaná čárkami, nebo můžete nechat prázdnou pro žádné pauzy. Jestli chcete, aby se už zapsané budoucí rezervace podřídily tomuto pravidlu, zaškrtnete „Aplikovat na současné“ (6), kde se rezervace mimo pracovní dobu odstraní a systém pošle e-mail, že daná rezervace byla zrušena. Pravidlo potvrdíte tlačítkem „OK“ (7).

D.2.2

Jednotky

Obrázek D.3: Jednotky

Druhou podsekcí „Správy objektu“ jsou „Jednotky“ (obrázek D.3). Zase je tu tlačítko na přidání nového pravidla (2), editaci pravidla (11) nebo jeho odstranění (12). Oproti předchozí podsekci, kde jste měli mimořádné dny (8), mimořádné doby (9) a standardní doby (10), máte navíc černý formulář „Seznam jednotek“ (3). Jeho chování je poněkud odlišné, máte seznam ID jednotek (4) a počet jednotek (5) určitého odběru. Dále je odlišné chování tlačítek. Tlačítko pro editaci (6) nastaví počet (5) jednotek, vybranou jednotku needituje. Naopak tlačítko odstranění (7) odstraní jen jednu vybranou jednotku (4). Systém se pokusí najít pro kolizní rezervaci volnou sousední jednotku namísto odstraněné nebo odstraněných, v případě hromadného snížení počtu (6). Případné odstranění bude oznámeno vlastníkovi rezervace e-mailem.

D.2. SPRÁVA OBJEKTU

73

Obrázek D.4: Nedostupní doba

Zde máte obdobný dialog (obrázek D.4) pro nedostupnou dobu, jako pro otevírací dobu. Typ (1), platnost (2) a den (3) jsou stejné jako předtím. Rozdíl je, že platnost doby musí být identická pro skupinu, když v otevíracích pravidlech musela být pro celý objekt. Skupinu a jednotku zvolíte díky selektorům (4). Napíšete už ve známém tvaru „HH:MM-HH:MM“ nedostupný čas (5) a opět zvolíte, zda systém má upravit existující rezervace dle nového pravidla. I zde se systém pokusí najít sousední jednotku, jestli nedojde ke kolizi. Tlačítko „OK“ (7) Vám dané pravidlo vytvoří.

D.2.3

Nastavení

Obrázek D.5: Nastavení

74


Třetí a poslední podsekcí jsou „Nastavení“ (obrázek D.5). Tlačítko „Přidat pravidlo“ (2) přidá nové pravidlo pro odběry, které definuje guru systému. Co definujete Vy, jsou nastavení, která platí pro odběr. Toto pravidlo můžete odstranit (4) nebo editovat (3). Pak můžete nastavit jméno objektu (5), adresu (6), e-mail, telefon nebo mobil (7), které se zobrazí na úvodní stránce.

Obrázek D.6: Odběry

Tento dialog (obrázek D.6) dostanete, když přidáváte nové pravidlo odběru nebo existující pravidlo upravujete. Máte na výběr (1), pro který odběr pravidlo platí. Logicky, pro jeden typ darování můžete mít jen jedno pravidlo. Jsou tu také časy (2), kde každý znamená něco jiného. „Čas přípravy“ – je čas, kdy k Vám přijde sestřička, napojí Vás na přístroj a odejde – je potřeba 1 zaměstnanec. Pak sedíte a přístroj něco dělá (separuje plasmu nebo odebírá krev), což je „Čas odběru“ – není potřeba zaměstnance. Pak je „Čas odpojení“, kdy znovu přijde sestřička a musí Vás odpojit od přístroje, vzít získaný balíček plasmy nebo krve a Vám dát například jablko – je potřeba 1 zaměstnanec. Pak má přístroj automatické čištění, což je v systému zohledněno jako „Čas čištění“ – není potřeba zaměstnance. Potřeba zaměstnance souvisí s položkou „Počet zaměstnanců“ (4), kde určujete počet lidí na objektu. Jestli na objektu jsou jen dvě sestřičky, naráz přijde 10 lidí a 15 minut trvá napojení pacienta, tak poslední dvojice bude čekat celou hodinu, a to nepočítáme lidi, kteří dorazí během té hodiny, a vznikl by problém „nekonečné“ fronty, kde by docházelo k časovému zpoždění i několika hodin. Tomuto problému se můžete vyhnout, když počet zaměstnanců bude stejný, jako počet jednotek. „Interval ve dnech“ (3) je položka, která určí, kolik dnů musí pacient počkat, aby mohl mít další odběr. Jinak musí požádat zaměstnance o zápis na kratším rozestupu. Také jen zaměstnanec smí překročit limit dnů dopředu – „Max dnů dopředu“ (5). Jestli se jedná o editaci pravidla, je zaškrtnuté „Aplikovat na současné“ (6) a nový interval je vyšší než předchozí, tak se odstraní oba termíny a bude to oznámeno majiteli e-mailem. Také když se zvýší doba celkového odběru a vznikne kolize, systém se pokusí najít volnou sousední jednotku nebo u zavírací doby odstraní rezervaci. Tlačítkem „OK“ (7) potvrdíte změnu v nastavení. Toto jsou ve stručnosti základní možnosti systému, kterým byste měli rozumět pro úspěšnou administraci. Bude to chtít navyknout na pravidla hlavně nedostupných dob. V případě nejasností se neváhejte zeptat hlavního administrátora (guru).

Příloha E

Návod pro guru E.1

Správa systému

Zadáte do internetového prohlížeče adresu klienta a přihlásíte se jako „admin“ nebo jako uživatel s oprávněním 4.

E.1.1

Objekty

Obrázek E.1: Objekty

V hlavní liště zvolíte „Správa systému“ (obrázek E.1) a uvidíte první podsekci „Objekty“. Můžete přidat odběr (2) nebo objekt (3) díky příslušným tlačítkům. Popřípadě odběry (4) spravovat tlačítky na editaci (5), pro změnu názvu, nebo na odstranění (6). Seznam objektů a jejich ID v závorkách můžete zobrazit selektorem (7). Objekt můžete odstranit (8), a pro změnu jména či adresy se musíte na tom objektu přihlásit. Pak můžete odstranit staré rezervace podle staří a zmáčknout tlačítko „Vyčistit“ (9). Poslední položkou v podsekci je

75

76

PŘÍLOHA E. NÁVOD PRO GURU

údržba, „Vyčistit sirotky“ (10) odstraní lidi, kteří nejsou na žádném objektu, vyčistí stará pravidla otevírací nebo nedostupné doby.

E.1.2

Import

Obrázek E.2: Import

Druhou podsekcí ve správě systému je „Import“ (obrázek E.2). Slouží k nahrání uživatelů ze starého rezervačního systému do nového. Aby to fungovalo, potřebujete nejdříve data ze starého systému uložit do souboru. K tomu slouží nástroj, jehož obrázek F.1 je v dalším návodu, phpMyAdmin. V původní databázi najděte tabulku „uzivatele“ a exportujte to do XML souboru – „uzivatele.xml“. Systém umí pracovat i s JSON souborem, avšak phpMyAdmin nikoliv, i když tvrdí, že ano. Například telefonní číslo „+420123456789“ exportuje jako integer místo string, a JSON soubor je neplatný. Až budete mít XML soubor, vyberte ho prosím tlačítkem „Procházet“ (2), zadejte, k jakému objektu patří a jaké budou mít uživatelé oprávnění (3), pak dejte „Import“ (4). Nepovedení uživatelé se Vám vypíšou v konzoli (5).

E.1. SPRÁVA SYSTÉMU

E.1.3

77

Logy

Obrázek E.3: Logy

Občas, jako správný správce, se musíte podívat, co systém dělá. K tomu slouží „Logy“ (obrázek E.3), což je poslední podsekce správy. Máte dva druhy záznamů – „Master“ a „Logy“, které načtete příslušnými tlačítky (2 a 3), popřípadě vyčistíte (4 a 5). Načtou se nám do vyhrazených tabulek (6 a 7). Master jsou logy sítě uzlů a nepovedené SQL příkazy. Pokud někdo provede neplatný SQL příkaz nebo uzel vypadne, server zablokuje hromadný zápis do všech lokálních databází (rezervace se budou zapisovat normálně) tj. žádná změna nebo vytváření aktualit, uživatelů, událostí nebo otevíracích pravidel, dokud nevyčistíte Master logy. V „Logy“ jsou běžné záznamy – špatně zadaná nebo resetovaná hesla, také odstranění uživatelů, atd. V další části práce se dozvíte, jak vytvořit další objekt, připojit další server do systému nebo co všechno můžete upravit v souboru „.ht-konfigurace.php“.

78

E.2

PŘÍLOHA E. NÁVOD PRO GURU

Nový objekt

Systém umožňuje běh několika objektů na jednom serveru, stejně tak i běh jednoho nebo více objektů na více serverech. Jsou dva kroky, které musíte udělat, abyste přidal nový objekt. Krok první – ve správě systému vytvoříte nový objekt a opíšete jeho ID v závorce, např. „Nový objekt (5)“, tak ID je 5. Krok druhý – zkopírujete jeden z JavaScript souborů ve složce „objekty“ na MASTER serveru, třeba „new.js“ do „novyObjekt.js“, a upravíte hned první řádek – var objekt = X;, kde X je ID objektu, tedy na var objekt = 5;. Teď už stačí zkopírovat „view“ část a upravit e-mail a odkaz v „index.html“, kde místo „new.js“ zapíšete „novyObjekt.js“. Koncový klient nepotřebuje PHP server, stačí mu složka s obsahem „view“ a zbytek už je na něm.

Příloha F

Instalační příručka F.1

Požadavky

• Apache server • PHP server v5.3 • cURL a OpenSSL rozšíření • Řízeni .htaccess • Funkce mail() • MySQL v5.5

F.2

Instalace

V této kapitole se podíváme krok za krokem na instalaci a údržbu systému. Pro úspěšnou instalaci potřebujete mít SQL server a PHP+Apache server. Byla zvolena zatím nejrozšířenější varianta SQL serveru – MySQL, skript na vytvoření databázových tabulek je kompatibilní i s MariaDB serverem, který v současné době nabírá na popularitě. Pokud používáte PostgeSQL nebo jiný SQL server, nezoufejte a požádejte o export databázových tabulek výrobce systému. Doporučená verze MySQL je 5.5 a vyšší, u PHP 5.3 a vyšší. Systém Vám poběží i na starších verzích. PHP server musí umožňovat posílat emaily přes funkci mail(), také mít rozšíření cURL. Také přístup k souborům je řízen „.htaccess“. Základní softwarové požadavky máte. Teď potřebujete jednu databázi nebo nejlépe dvě. K vytvoření tabulek slouží například nástroj phpMyAdmin (obrázek F.1), kde vlevo vidíte seznam databází. Ale můžete použít i příkazový řádek SQL serveru. Systém má dvě základní skupiny tabulek – CENTRÁLA a LOKÁLNÍ. Pokud nebudete systém dále rozšiřovat o servery, stačí Vám jedna databáze, i pokud budete, systému to nevadí, obě skupiny jsou skoro nezávislé. Každopádně potřebujete dvě nebo jednu databázi a přístupové údaje k nim, které budete potřebovat v dalším kroku. Teď potřebujete dvě veřejné internetové adresy. Stačí zase i jedna, kde MASTER server bude v podsložce hlavní složky. A dostáváte se do architektury, která je popsaná v jiné

79

80

PŘÍLOHA F. INSTALAČNÍ PŘÍRUČKA

Obrázek F.1: phpMyAdmin

kapitole. Stručně řečeno, máte MASTER a možné SLAVE servery, které zpracovávají data v PHP a odpovídají v JSON[P] protokolu. Pak máte klienta napsaného v HTML, což je grafické zobrazení dat. V návodu jsou to dvě různé instalační složky „server“ a „view“ na adrese http://carth.sh.cvut.cz/rs/. Obě složky mohou být jak v jedné složce, tak i MASTER server může být v podsložce klienta, ale oba mohou být třeba na různých serverech. Systému je to jedno. Důležité je, abyste zkopírovali obsah složky „server“ na místo, kde bude MASTER server, adresa byla veřejně přístupná, a samozřejmě byl zapnutý interpret – PHP server.

Obrázek F.2: index.php - úvod

F.2. INSTALACE

81

Po zkopírování souborů a zadání internetové adresy MASTER serveru do prohlížeče, se Vám objeví následující formulář (obrázek F.2). V prvním políčku (1) bude současná adresa (POZOR CELÁ VČETNĚ http:// s LOMÍTKEM NA KONCI). Do „Centrální databáze“ (2) zadejte přihlašovací údaje a jméno tabulky, které máte z první části návodu, pro CENTRÁLU. Do „Lokální databáze“ (3) údaje pro LOKÁL. Jak už je uvedené výš, údaje mohou být identické, ale zadat je musíte do obou. Stejně tak i dvakrát heslo pro uživatele „admin“. Pak klikněte na tlačítko „Hotovo“ (5). Chvíli se budou vytvářet databázové tabulky a dva uživatele – „admin“ a „master“. Uživatel „master“ je virtuální a jeho úkol je popsán v jiné kapitole.

Obrázek F.3: index.php - výpis

Po úspěšné instalaci se Vám objeví následující výpis (obrázek F.3). Musíte vytvořit dva soubory a jeden upravit.

82


Obrázek F.4: Kate - soubory

3 soubory (obrázek F.4) – jeden ve složce „private“, druhý ve složce „objekty“ a třetí soubor musíte upravit. Vytvořte nový soubor v adresáři MASTER serveru ve složce „private“. Soubor pojmenujte „.ht-konfigurace.php“, vložte do něj daný obsah a uložte. Další soubor v adresáři MASTER ve složce „objekty“. Soubor pojmenujte „new.js“ (nebo jak chcete, ale upravte podle toho další krok) vložte obsah a uložte. V instalační složce „view“ najděte soubor „index.html“ a vložte na chybějící místo odkaz na skript „new.js“ (2), změňte kontaktní e-mail a uložte to. Přidejte do CRONu, nebo třeba na stránkách http://www.mywebcron.com/, záznam pro spuštění souboru „cron.php“ na MASTER serveru pro SMS a emailové upozornění každou hodinu. A je to! Teď můžete nahrát kamkoliv obsah instalační složky „view“ nebo otevřít lokálně soubor „index.html“ ve Firefoxu a spravovat systém.

F.3

SLAVE server

Důvodů, proč klonovat server může být hodně. Potřebujete zálohu, rychlejší odezvu nebo snížit zátěž „vratného“, neboli PHP serveru. Také s dnešní popularitou útoků hackerů na Váš server, jako jsou DoS útoky, díky fragmentaci systému dokážete tímto útokům lépe čelit. Podmínkou přidaní dalšího serveru, aby to mělo smysl, jsou dvě databáze, když jste zakládali MASTER server, a nejlépe na dvou různých serverech, aby účinek byl co největší – až o 100 procent rychlejší. Samozřejmě můžete rozšířit systém, i když máte jen jednu databázi. Nesmyslem je rozšiřovat systém, když vše bude na jednom serveru. Krok 1 – zakázat zápis do LOKÁLU. Všechny lokální databáze mají stejný hlavní obsah, jak to zařizuje systém je popsáno v jiné kapitole, proto musíte dočasně vypnout zápis na MASTER serveru. V souboru „.ht-konfigurace.php“ upravíme řádek: define(’MASTERUDRZBA’, ’0’); na define(’MASTERUDRZBA’, ’1’);.

F.3. SLAVE SERVER

83

Krok 2 – otevřete phpMyAdmin a exportujete celou databázi LOKÁLU, kterou následně nahrajete do nové. Krok 3 – zkopírujete obsah MASTER serveru na místo, kde bude SLAVE server. A upravíte soubor „.ht-konfigurace.php“ na SLAVE serveru následovně: - Pokud ’DBHOSTCENTRAL’ má lokální adresu (localhost nebo 127.0.0.1), změníte ji na vzdálenou adresu. - Do ’DBNODE’ zapíšete jméno uzlu ’slave1’, nebo jinou číslici - Do ’DBHOST’, ’DBLOGIN’, ’DBHESLO’, a ’DBBASE’ zapíšete přístupové údaje nové databáze - Odkomentujete nebo zkopírujete poslední záznam: $NODE = Array ( ’DBNODE’ ’DBHOST’ => ’ 1 2 7 . 0 . 0 . 1 ’ ’DBLOGIN’ => ’ u z i v a t e l ’ ’DBHESLO’ => ’ h e s l o ’ , ’DBBASE’ => ’ r s −node2 ’ array_push ($NODE_ARRAY,

=> ’ s l a v e 1 ’ , , , ); $NODE) ;

Kde uvedete potřebné údaje. Také nezapomeňte u prvního ’DBNODE’ => ’master’ změnit lokální adresu na vzdálenou a změňte ID_WEBU a ID_WEBU2 na náhodné MD5. Do ’MASTERUDRZBA’ zapíšete ’0’, a „.ht-konfigurace.php“ na SLAVE serveru uložíte. Krok 4 – otevřeme soubor „.ht-konfigurace.php“ na MASTER serveru. Odkomentujete nebo zkopírujete poslední záznam: $NODE = Array ( ’DBNODE’ ’DBHOST’ => ’ 1 2 7 . 0 . 0 . 1 ’ ’DBLOGIN’ => ’ u z i v a t e l ’ ’DBHESLO’ => ’ h e s l o ’ , ’DBBASE’ => ’ r s −node2 ’ array_push ($NODE_ARRAY,

=> ’ s l a v e 1 ’ , , , ); $NODE) ;

Kde uvedete potřebné údaje nové tabulky. Do ’MASTERUDRZBA’ na MASTER serveru uložíte.

zapíšete

’0’,

a

soubor

„.ht-konfigurace.php“

Krok 5 – do všech souborů ve složce „objekty“ na všech serverech připíšete nový SLAVE server: s e r v e r y [ 1 ] = ’ h t t p : / / c a r t h . sh . cvut . c z / r s / s e r v e r 2 / ’ ; A necháte výběr serveru na náhodě: var a j a x _ s e r v e r _ i n d e x = Math . f l o o r ( ( Math . random ( ) ∗ s e r v e r y . l e n g t h ) ) ; var a j a x _ s e r v e r = s e r v e r y [ a j a x _ s e r v e r _ i n d e x ] ; Popř. zakomentujte poslední řádek, kde jsme ajax_server určili napevno. Soubory uložíte a je hotovo.

84

F.4


Konfigurace

Popsal jsem, k čemu slouží ’MASTERUDRZBA’ (zápis do lokální databáze, můžete provádět rezervace), co jsou to záznamy ’$NODE’ a ’ajax_server’. Teď se podíváte, co dalšího můžete upravit v souboru „.ht-konfigurace.php“. Upozorňuji, že hodnoty musíte měnit na všech serverech, pokud máte tuto architekturu. Tady jsou popsány jen věci, které potřebuje vědět instalátor a guru, ostatní jsou popsány v jiné kapitole. ’VERYSECURE’ – Za normálních podmínek ’0’. Určuje, zda server provádí paranoidní kontrolu uživatele s databází při každém dotazu. ’LOGOUT_CAS’ – čas automatického odhlášení v sekundách.

V této kapitole jste se dozvěděli, co všechno je potřeba vědět pro instalaci a správu už hotového systému. Pro běžné správce stačí, když ho vidí, jako „Black box“, který má vstupy a výstupy. Pokud se chcete dozvědět víc, doporučuji přečíst další kapitoly, které vyžadují znalost databází a jejich příkazů, PHP, JSON[P], jQuery, JavaScript a HTML. Je třeba také vědět něco o asynchronním webu, i když jsem se to pokoušel napsat co možná nejjednodušeji. Děkuji, že jste to dočetli až sem, a doufám, že budete spokojeni.

Příloha G

Obsah přiloženého CD

85

ZADÁNÍ DIPLOMOVÉ PRÁCE

Recommend Documents