České vysoké učení technické v Praze Fakulta elektrotechnická
ˇ VUT FEL katedra pocˇı´tacˇu˚ C
Diplomová práce
Informační systém pro dětský tábor Jan Galajda
Vedoucí práce: Ing. Martin Molhanec, CSc.
Studijní program: Elektrotechnika a informatika, dobíhající Obor: Výpočetní technika leden 2008
ii
Poděkování Na tomto místě chci poděkovat všem, kteří mě podpořili v mé práci ve fázi návrhu, analýzy nebo implementace. Děkuji lidem z vedení dětského tábora za jejich připomínky a návrhy. Největší dík pak patří mému vedoucímu diplomové práce Ing. Martinu Molhancovi, CSc., který vždy rychle a ochotně odpovídal na moje dotazy. iii
iv
Prohlášení Prohlašuji, že jsem svou diplomovou 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 Praze dne 17.1. 2008
.............................................................
v
vi
Abstract This text is a documentation of the Information system for the summer children camp. The system provides an Internet presentation of the camp, it supports communication among camp participants and it affords event planning during the year. My diploma thesis is divided into several basic parts. The summary of the present state is mentioned in the first part. Used technologies are discussed in the second part, which is followed with the study and analysis of the system. Last chapters contain information on the system implementation and testing. The information system including documentation is available on the enclosed DVD.
Abstrakt Tento text je dokumentací k projektu Informačního systému pro dětský tábor, který umožňuje táboru prezentaci na internetu, komunikaci mezi účastníky tábora a plánování akcí během celého roku. Diplomová práce je rozdělena do několika základních částí. V první části je provedeno shrnutí současného stavu problematiky, v druhé části popisuji použité technologie. Následuje studie a analýza. Závěrečné kapitoly jsou věnovány samotné implementaci a testování. Instalaci informačního systému včetně dokumentace najdete na přiloženém DVD.
vii
viii
Obsah Seznam obrázků
xvi
Seznam tabulek
xviii
1 Úvod
1
1.1
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Cíl diplomové práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Současný stav problematiky . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3.1
Táborové servery . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3.2
On-line řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3.2.1
eStránky - aneb aktuální řešení . . . . . . . . . . . . . .
3
1.3.2.2
Webgarden|zone . . . . . . . . . . . . . . . . . . . . . .
5
Redakční systémy . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.3.1
Vlastnosti . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.3.2
Možné využití . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3.3.3
Praktické nasazení systému . . . . . . . . . . . . . . . .
7
1.3.3.4
Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . .
8
Shrnutí
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.3.3
1.3.4
2 Použité technologie a metodiky
10
2.1
HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.6
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.7
AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.7.1
Princip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.7.2
Používané techniky . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.7.3
Výhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.7.4
Nevýhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Texy! a Texyla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.8.1
16
2.8
Texy! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
2.8.2 2.9
Texyla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
webhosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3 Úvodní studie
19
3.1
Deklarace záměru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Odborný článek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3
Katalog požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.1
Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.2
Funkce systému . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.2.1
Neregistrovaný uživatel . . . . . . . . . . . . . . . . . .
21
3.3.2.2
Dítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3.2.3
Instruktor . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3.2.4
Rodič / bývalý účastník tábora . . . . . . . . . . . . . .
22
3.3.2.5
Vedoucí . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3.2.6
Správce stránek . . . . . . . . . . . . . . . . . . . . . . .
23
3.3.2.7
Administrátor . . . . . . . . . . . . . . . . . . . . . . . .
23
Nefunkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . .
24
Návrh architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4.1
Požadavky na softwarové vybavení klientů . . . . . . . . . . . . .
25
3.4.2
Požadavky na hardwarové vybavení klientů . . . . . . . . . . . . .
25
3.4.3
Požadavky na webový server . . . . . . . . . . . . . . . . . . . . .
25
3.5
Harmonogram projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.6
Use Case nejvyšší úrovně . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.7
Analýza rizik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.7.1
Rizika procesní a implementační . . . . . . . . . . . . . . . . . . .
28
3.7.2
Rizika personální . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.7.3
Rizika obchodní . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.7.4
Rizika technologická . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.7.5
Rizika bezpečnostní . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.7.6
Analýza rizik vyvíjeného informačního systému . . . . . . . . . .
30
3.3.3 3.4
4 Analýza a návrh řešení 4.1
34
Popis případů užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.1.1
35
Spuštění systému . . . . . . . . . . . . . . . . . . . . . . . . . . . x
4.1.2
Zobrazení stránek o táboře . . . . . . . . . . . . . . . . . . . . . .
35
4.1.3
Prohlížení novinek . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.1.4
Zobrazení kalendáře akcí . . . . . . . . . . . . . . . . . . . . . . .
37
4.1.5
Prohlížení fotografií . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.1.6
Registrace do systému . . . . . . . . . . . . . . . . . . . . . . . .
40
4.1.7
Přihlášení do systému . . . . . . . . . . . . . . . . . . . . . . . .
41
4.1.8
Odhlášení ze systému . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1.9
Změna hesla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.10 Editace a prohlížení osobních údajů . . . . . . . . . . . . . . . . .
44
4.1.11 Zobrazení kontaktů ostatních registrovaných uživatelů . . . . . . .
44
4.1.12 Diskusní fórum - prohlížení
. . . . . . . . . . . . . . . . . . . . .
46
4.1.13 Diskusní fórum - vkládání příspěvků . . . . . . . . . . . . . . . .
47
4.1.14 Registrace dítěte do systému . . . . . . . . . . . . . . . . . . . . .
48
4.1.15 Změna údajů dítěte . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.1.16 Přihlášení dítěte na tábor a další akce
. . . . . . . . . . . . . . .
51
4.1.17 Přihlášení na akci . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.1.18 Zobrazení a změna přihlášených akcí . . . . . . . . . . . . . . . .
53
4.1.19 Vložení nové akce do kalendáře . . . . . . . . . . . . . . . . . . .
54
4.1.20 Vytvoření fotogalerie . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.1.21 Vložení fotografií . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.1.22 Zobrazení informací o osobách přihlášených na akci . . . . . . . .
59
4.1.23 Schválení registrace uživatelů . . . . . . . . . . . . . . . . . . . .
60
4.1.24 Správa off-line přihlášek . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.25 Zobrazení seznamů přihlášených dětí na jednotlivé akce . . . . . .
63
4.1.26 Správa stránek . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.1.27 Nová stránka . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.1.28 Úprava menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.1.29 Editace kalendáře akcí . . . . . . . . . . . . . . . . . . . . . . . .
69
4.1.30 Editace diskusních příspěvků
. . . . . . . . . . . . . . . . . . . .
70
4.1.31 Mazání fotografií . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.1.32 Mazání a editace fotogalerií . . . . . . . . . . . . . . . . . . . . .
71
4.1.33 Vytvoření diskusního tématu . . . . . . . . . . . . . . . . . . . . .
72
4.1.34 Mazání a editace diskusního tématu . . . . . . . . . . . . . . . . .
73
xi
4.2
4.1.35 Vložení novinek . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.1.36 Editace novinek . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.1.37 Přidělení role správce . . . . . . . . . . . . . . . . . . . . . . . . .
76
Konceptuální datový model . . . . . . . . . . . . . . . . . . . . . . . . .
77
5 Implementace
80
5.1
Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2
Struktura programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
6 Testování 6.1
87
Testování kódu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.1.1
white-box testy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.1.2
black-box testy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.2
Testy databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.3
Testy projektu jako celku . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.4
Usability testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
7 Závěr
89
7.1
Zhodnocení a závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
7.2
Budoucnost systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
8 Literatura
91
A Seznam použitých zkratek
93
B Instalační příručka
95
B.1 Instalace FTP klienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
B.2 Získání webového prostoru . . . . . . . . . . . . . . . . . . . . . . . . . .
95
B.3 Zavedení databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
B.4 Nahrání skriptů na server . . . . . . . . . . . . . . . . . . . . . . . . . .
96
B.5 Spuštění systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
C Uživatelská příručka
98
C.1 Základní navigace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
C.2 Registrace do systému a změna osobních údajů
. . . . . . . . . . . . . .
98
C.3 Přhlášení na akci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
xii
C.4 Správa dalších prvků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 C.5 Administrační prvky pro správce stránek . . . . . . . . . . . . . . . . . . 100 D Obsah přiloženého DVD
102
xiii
xiv
Seznam obrázků 1.1
Zobrazení informací o táboře na stránkách Dětské-tábory.info . . . . . . .
2
1.2
Aktuální stav táborových www stránek vytvořených s pomocí služby eStránky.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Ukázka použití redakčního systému Drupal na stránkách věnovaných nástroji phpMyAdmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1
Princip volání Ajaxu. [21] . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
Vlevo editační okno Textyly s Texy! kódem. Vpravo pak náhled editovaného textu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1
Diagram nasazení.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
Harmonogram projektu. . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3
Use nejvyšší úrovně. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1
Zobrazení stránek o táboře. . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2
Kalendář akcí - tlačítka pro přihlášení. . . . . . . . . . . . . . . . . . . .
38
4.3
Prohlížení fotografií - základní informace o galerii s tlačítkem pro zobrazení náhledů fotek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.4
Registrační formulář. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.5
Přihlášení do systému. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.6
Odhlášení ze systému. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.7
Editace a prohlížení osobních údajů. . . . . . . . . . . . . . . . . . . . .
45
4.8
Zobrazení kontaktů ostatních registrovaných uživatelů. . . . . . . . . . .
46
4.9
Diskusní fórum - prohlížení a vkládání příspěvku. . . . . . . . . . . . . .
48
4.10 Přihlášení dítěte na tábor a další akce. . . . . . . . . . . . . . . . . . . .
52
4.11 Zobrazení a změna přihlášených akcí. . . . . . . . . . . . . . . . . . . . .
53
4.12 Diagram aktivit: Zobrazení a změna přihlášených akcí. . . . . . . . . . .
58
4.13 Vložení nové akce do kalendáře. . . . . . . . . . . . . . . . . . . . . . . .
58
4.14 Vložení fotografií. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.15 Zobrazení akce - editační tlačítka. . . . . . . . . . . . . . . . . . . . . . .
60
4.16 Schválení registrace uživatelů. . . . . . . . . . . . . . . . . . . . . . . . .
61
4.17 Část menu určená správcům stránek. . . . . . . . . . . . . . . . . . . . .
61
4.18 Správa off-line přihlášek. . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.19 Seznam dětí přihlášených na akce - formulář pro jeho generování. . . . .
64
4.20 Správa stránek - přehled stránek uložených v systému. . . . . . . . . . .
65
1.3
xv
4.21 Správa stránek - varování před smazáním stránky. . . . . . . . . . . . . .
65
4.22 Správa stránek - editace vlastností stránky. . . . . . . . . . . . . . . . . .
66
4.23 Správa stránek - editace stránky s článkem.
. . . . . . . . . . . . . . . .
66
4.24 Úprava menu - přehled položek menu. . . . . . . . . . . . . . . . . . . . .
69
4.25 Vložení novinek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.26 Formulář pro vložení novinky. . . . . . . . . . . . . . . . . . . . . . . . .
77
4.27 Vazba 1:N mezi entitami. . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.28 Vazba 1:1 mezi entitami. . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.29 Vazba N:N mezi entitami. . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.30 Konceptuální datový model. . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.1
Datový model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.2
Struktura částí programu. . . . . . . . . . . . . . . . . . . . . . . . . . .
85
C.1 Zobrazení stránek o táboře. . . . . . . . . . . . . . . . . . . . . . . . . .
99
C.2 Odhlášení ze systému. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
C.3 Správa stránek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.4 Úprava menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
xvi
Seznam tabulek 3.1
Tabulka rizik vyvíjeného projektu . . . . . . . . . . . . . . . . . . . . . .
31
4.1
Use Case Spuštění systému . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.2
Use Case Zobrazení stránek o táboře . . . . . . . . . . . . . . . . . . . .
35
4.3
Use Case Prohlížení novinek . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.4
Use Case Zobrazení kalendáře akcí . . . . . . . . . . . . . . . . . . . . .
38
4.5
Use Case Prohlížení fotografií . . . . . . . . . . . . . . . . . . . . . . . .
39
4.6
Use Case Registrace do systému . . . . . . . . . . . . . . . . . . . . . . .
40
4.7
Use Case Přihlášení do systému . . . . . . . . . . . . . . . . . . . . . . .
41
4.8
Use Case Odhlášení ze systému . . . . . . . . . . . . . . . . . . . . . . .
42
4.9
Use Case Změna hesla . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.10 Use Case Editace a prohlížení osobních údajů . . . . . . . . . . . . . . .
44
4.11 Use Case Zobrazení kontaktů ostatních registrovaných uživatelů . . . . .
45
4.12 Use Case Diskusní fórum - prohlížení . . . . . . . . . . . . . . . . . . . .
46
4.13 Use Case Diskusní fórum - vkládání příspěvků . . . . . . . . . . . . . . .
47
4.14 Use Case Registrace dítěte do systému . . . . . . . . . . . . . . . . . . .
49
4.15 Use Case Změna údajů dítěte . . . . . . . . . . . . . . . . . . . . . . . .
50
4.16 Use Case Přihlášení dítěte na tábor a další akce . . . . . . . . . . . . . .
51
4.17 Use Case Přihlášení na akci . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.18 Use Case Zobrazení a změna přihlášených akcí . . . . . . . . . . . . . . .
54
4.19 Use Case Vložení nové akce do kalendáře . . . . . . . . . . . . . . . . . .
55
4.20 Use Case Vytvoření fotogalerie . . . . . . . . . . . . . . . . . . . . . . . .
56
4.21 Use Case Vložení fotografií . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.22 Use Case Zobrazení informací o osobách přihlášených na akci . . . . . . .
59
4.23 Use Case Schválení registrace uživatelů . . . . . . . . . . . . . . . . . . .
60
4.24 Use Case Správa off-line přihlášek . . . . . . . . . . . . . . . . . . . . . .
62
4.25 Use Case Zobrazení seznamů přihlášených dětí na jednotlivé akce . . . .
63
4.26 Use Case Správa stránek . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.27 Use Case Nová stránka . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.28 Use Case Úprava menu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.29 Use Case Editace kalendáře akcí . . . . . . . . . . . . . . . . . . . . . . .
69
4.30 Use Case Editace diskusních příspěvků . . . . . . . . . . . . . . . . . . .
70
xvii
4.31 Use Case Mazání fotografií . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.32 Use Case Mazání a editace fotogalerií . . . . . . . . . . . . . . . . . . . .
71
4.33 Use Case Vytvoření diskusního tématu . . . . . . . . . . . . . . . . . . .
73
4.34 Use Case Mazání a editace diskusního tématu . . . . . . . . . . . . . . .
73
4.35 Use Case Vložení novinek . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.36 Use Case Editace novinek . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.37 Use Case Přidělení role správce . . . . . . . . . . . . . . . . . . . . . . .
76
5.1
Databázová tabulka stranka . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2
Databázová tabulka menu . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.3
Databázová tabulka prvek stranky . . . . . . . . . . . . . . . . . . . . . .
82
5.4
Databázová tabulka clanek . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.5
Databázová tabulka novinka . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.6
Databázová tabulka fotografie . . . . . . . . . . . . . . . . . . . . . . . .
83
5.7
Databázová tabulka diskusni prispevek . . . . . . . . . . . . . . . . . . .
83
5.8
Databázová tabulka akce . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.9
Databázová tabulka uzivatel . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.10 Databázová tabulka role . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.11 Databázová tabulka prihlaska . . . . . . . . . . . . . . . . . . . . . . . .
85
xviii
KAPITOLA 1. ÚVOD
1
1 Úvod 1.1
Úvod
Již od mých prvních setkání s internetem na střední škole mě zajímalo, jak se vytvářejí internetové stránky, jak je možné zpřístupňovat nejrůznější informace širokému okruhu uživatelů prostřednictvím celosvětové sítě. Během posledních let jsem zhotovil pro sebe či přátele několik internetových stránek, které splnily účel, pro nějž byly vytvořeny. Při jejich tvorbě jsem použil jen základních technologií využívaných pro tvorbu statických stránek - HTML a CSS. Když jsem začal přemýšlet o tématu mé diplomové práce, rozhodl jsem se, že bych se chtěl více ponořit do problematiky návrhu a tvorby internetových aplikací. Ve škole jsme se tímto tématem téměř nezabývali, a tak jsem práci na diplomové práci v oblasti webových projektů bral jako výbornou příležitost naučit se něčemu novému. Ještě více mě v tomto nápadu povzbudilo možné praktické využití výsledku mé práce. Se svými přáteli totiž již mnoho let spoluorganizuji dětský letní tábor. Pro vzájemnou komunikaci mezi vedoucími, rodiči i dětmi se využívá internetové prezentace. Současná aplikace má některé menší a několik větších nedostatků. Po konzultaci s kamarádem, který má táborové stránky na starosti, jsem učinil rozhodnutí, že vytvořím zcela novou táborovou webovou aplikaci, která vyřeší současné chyby a realizuje i nové funkčnosti.
1.2
Cíl diplomové práce
Cílem mé diplomové práce je navrhnout a implementovat malý informační systém pro dětský tábor, který bude využíván organizátory letního tábora pořádaného každoročně v Heralticích na Třebíčsku. Využití vyvíjeného systému pro dětský tábor se bude odehrávat v několika oblastech. Poslouží jako prezentace dětského tábora navenek, tj. představí tábor rodičům a dětem, potenciálním účastníkům. Dále umožní jednoduchou komunikaci mezi vedoucími, resp. komunikaci vedoucích s dětmi, které se již některé táborové akce zúčastnili. To bude probíhat formou diskusích fór, publikováním fotografií z akcí, zveřejňováním kontaktů. Kalendář poslouží k informování o mimotáborových akcích, vedoucí i děti se budou moci přes systém přihlásit na tábor i jiné akce. Nový informační systém ulehčí též organizaci tábora samotným pořadatelům. Budou moci spravovat přihlášené účastníky, vytvářet automatizované seznamy účastníků tábora, které jsou potřebné k zajištění bezproblémového chodu tábora. Z výše uvedeného vyplývá jasný požadavek, že vyvíjený informační systém musí být přístupný z jakéhokoli počítače připojeného k internetu, a tudíž se bude jednat o internetovou aplikaci. Zdůrazním i přání organizátorů tábora na cenu. Protože peněz není nikdy dost, musí být výsledný systém finančně co nejméně náročný.
2
KAPITOLA 1. ÚVOD
1.3
Současný stav problematiky
Organizace, které pořádají dětské tábory, mají mnoho možností, jak se prezentovat veřejnosti na internetu. Rád bych zde tyto možnosti trochu rozvedl, uvedl jejich charakteristiku, výhody, nevýhody a možnost aplikování na dětský tábor zmiňovaný v úvodu. Zaměřím se na tyto možnosti řešení problému: • specializované táborové servery • hotová on-line řešení • redakční systémy • statické www stránky 1.3.1
Táborové servery
Servery specializované na informování zájemců o dětské tábory jsou nejjednodušší možností, jak dát o táboru vědět prostřednictvím internetu. Server Dětské-tábory.info [3] umožňuje po jednoduché registraci vložení informací o plánovaném dětském táboře. Vedle základních údajů (jako např. datum a místo pořádání, kapacita atd.) je možné vložit popis programu tábora, prostředí a ubytování, způsobu dopravy, kontaktní informace a několik fotografií. Diskusní forum je řešeno formou externí aplikace, která není zakomponována do vzhledu stránek.
Obrázek 1.1: Zobrazení informací o táboře na stránkách Dětské-tábory.info Použití služby je bezplatné, umožňuje rychlé informování. Tento typ serveru má podle mě zejména inzertní charakter. Při vkládání informací o táboře uvedeme odkaz na táborové internetové stránky, na nichž jsou uvedeny podrobnější údaje. Závěr: Po vložení inzerátu splňují stránky informační funkci. Další požadované funkčnosti (rozsáhlejší fotogalerie, kalendář akcí, přihlášky atd.), nejsou přítomny nebo jsou výrazně omezené. 1.3.2
On-line řešení
V poslední době se na internetu objevuje stále více aplikací, které umožňují běžným uživatelům publikovat on-line informace na internetu. Běžnými uživateli mám na mysli
KAPITOLA 1. ÚVOD
3
osoby, které používají e-mail či si umí vyhledávat potřebné informace, nemají ale žádné znalosti programování ani značkovacího jazyka HTML. Mezi nejoblíbenější patří blogy a fotogalerie, které jednoduše zpřístupňují čtenářovy názory na libovolná témata, resp. dovolují sdílet fotografie mezi přáteli nebo širokou veřejností. Blog1 je webová aplikace obsahující periodické příspěvky na jedné webové stránce. Může se jednat jak o osobní deníky, tak i oficiální zpravodajství firem, sdělovacích prostředků atp. Do blogu může přispívat jediný autor, malá skupina přátel nebo i široké společenství. Řada weblogů umožňuje přidávání komentářů k jednotlivým příspěvkům, takže kolem nich vzniká čtenářská komunita. Pro vytvoření weblogů existuje na internetu řada systémů, s jejichž pomocí mohou zájemci po jednoduché registraci začít ihned zveřejňovat své články. Mezi nejznámější světové stránky pro tvorbu blogů patří server myspace.com, blog.com nebo blogger.com od společnosti Google. Z českých serverů je vhodné zmínit blog.cz, bloguje.cz či lide.cz největšího portálu Seznam.cz. Vytváření blogů dnes nabízí téměř každý větší server zabývající se zábavou a poskytováním informací v síti internet. I když některé weblogy umožňují i vkládání fotografií, přesto tyto systémy neobsahují všechny požadované funkce, které potřebuje využívat zmiňovaný dětský tábor. Rozhodneme-li se zveřejnit fotografie z dovolené, oslavy apod. svým přátelům přes internet, je nejjednodušší využít některého veřejného internetového fotoalba. Mají tu výhodu, že se nemusíme prakticky o nic starat. Musíme jen nahrát své fotky, odpadají nám starosti, kam fotoalbum umístit, nemusíme instalovat žádný software. Již delší dobu může český uživatel využít fotoalba firmy Volný.cz. Nejoblíbenější je Rajče.net portálu iDnes.cz. Z celosvětových projektů zmiňme alespoň Flickr.com a webové album Picasa internetového giganta Google. Fotoalba se pochopitelně liší jak vzhledem, tak i počtem doplňkových funkcí (např. komentáře, hodnocení fotek). Velikost alb může být od desítek MB až po řádově jednotky GB u nejpopulárnějších služeb. Můžeme se setkat i s velikostí zcela neomezenými systémy. Vytváření a zveřejňování alb fotografií je mezi internetovými uživateli velmi populární, a proto se systémy pro jejich publikování neustále rozvíjejí, přidávají stále více možností, jak je využívat. Bohužel pro náš dětský tábor přinášejí opět jen řešení části problematiky, a tak jsou pro nás nevhodné. Určitou kombinací fotogalerie, weblogů a podobných systémů, jsou on-line produkty zaměřené na jednoduchou tvorbu internetových stránek. Uživatelé s jejich pomocí mohou jednoduše vytvářet stránky a články, nahrávat obrázky do fotogalerií, diskutovat prostřednictvím fór. Zdá se, že bychom zde mohli nalézt něco, co by nám pomohlo vytvořit odpovídající informační systém pro dětský tabor. Podívejme se tedy na ně blíže. 1.3.2.1
eStránky - aneb aktuální řešení
Koncem roku 2005 se na českém internetu objevila služba eStránky [4]. Aplikace umožňuje i laikovi během několika minut vytvořit vlastní web, blog či fotoalbum. I když služba vznikla vlastně náhodou [24], získala si za dobu dvou let rychle velkou oblibu. V 1
Nebo též weblog.
4
KAPITOLA 1. ÚVOD
systému je již zaregistrováno více než 350 tisíc uživatelů. eStránky umožňují registrovaným uživatelům vytvářet statické www stránky bez použití HTML kódu. Využívají k tomu integrovaný WYSIWYG editor, ve kterém se tvorba obsahu podobá vytváření běžného textového dokumentu v MS Word či OpenOffice. Výsledná stránka vzniká psaním textu a jeho formátováním pomocí různých funkčních tlačítek. Jednotlivé stránky lze sdružovat do rubrik, které lze koncovému uživateli zveřejnit v menu. Další důležitou funkcí je vytváření fotogalerií obrázků a fotografií. Fotky lze na server nahrávat pomocí formuláře z administračního rozhraní nebo pomocí FTP přístupu2 . Náhledy jsou vytvářeny automaticky. Galerie lze opět členit do rubrik. K článkům i fotogaleriím lze připojit diskusní příspěvky, které nejsou hierarchicky členěny, zobrazují se od nejnovějších reakcí. Jednotlivé stránky i alba obrázků lze zamknout heslem3 , které je však pro všechny uživatele stejné. V administračním rozhraní je možné nastavit grafický návrh, který bude použit a jeho barevné variace. Šablonu vzhledu lze upravovat. Stejně jako rozmístění jednotlivých prvků na stránce včetně jich zapnutí či vypnutí. Stránky mají adresu ve formátu jméno.estranky.cz. Zmiňme v krátkosti jednotlivé verze poskytované služby. Pro vyzkoušení je ideální verze zdarma, která obsahuje 30 MB prostoru, možnost zveřejnění max. 60 fotografií, přenos 1 GB dat za měsíc, není určena firmám a je nutné zobrazovat vloženou reklamu. Nekomerční verze není určená firmám, platí se za ní poplatek 420 Kč za rok. Uživatel dostane 1 GB prostoru, může zveřejnit až 2000 fotografií a přenést až 5 GB za měsíc. Fotografie můžeme nahrávat i přes FTP, jednotlivé stránky lze zamknout heslem. Nekomerční placená verze neobsahuje reklamu provozovatele a nelze do ní umístit cizí reklamu. Komerční verze stojí 1500 Kč za rok, má obdobné parametry jako nekomerční verze s tím, že lze vyžít 5 GB prostoru, mít dvojnásobný přenos dat a do stránek umisťovat cizí reklamu. Táborový vedoucí zodpovědný za internetové stránky vytvořil před více než rokem prezentaci právě pomocí zde popsaného systému eStránky. Kvůli možnosti zveřejnění většiny fotografií z tábora se rozhodl pro využití nekomerční prezentace, která poskytuje poměrně dost prostoru na jejich uložení za rozumnou cenu. Vedle tvorby obsahu a publikace obrázků jsou stránky využívány i pro komunikaci mezi vedoucími prostřednictvím diskuse. Během používání se časem začaly objevovat i nedostatky tohoto řešení. Základní funkce, které od stránek tábor požaduje, jsou sice splněny, bohužel ale není možné implementovat některé další funkčnosti, které by organizátorům akce pomohly. Zejména chybí vytváření interaktivního kalendáře akcí (i mimotáborových), možnosti přihlášení na ně a správa přihlášených účastníků. Přihlašování všech vedoucích do zamčených stránek pod jedním heslem je nevyhovující z hlediska bezpečnosti. Administrátor při tvorbě stránek často bojuje s WYSIWYG editorem, aby dosáhl ve výsledku opravdu toho, co 2 3
Neplatí pro verzi zdarma - viz. dále. Neplatí pro verzi zdarma - viz. dále.
KAPITOLA 1. ÚVOD
5
Obrázek 1.2: Aktuální stav táborových www stránek vytvořených s pomocí služby eStránky.cz měl v úmyslu. Stává se, že v editoru se něco zobrazí jedním způsobem a na výsledné stránce jiným způsobem. Editor pak kolikrát místo ulehčení práci ztěžuje. Přepínání do HTML módu a zpět také není bez chyb a někdy dochází zcela k rozhození kódu. Závěr: eStránky pro začátek splňovaly funkce, které tábor od systému na tvorbu a publikaci stránek očekával. S postupným vývojem se ukázalo, že je třeba implementovat nové funkčnosti, hlavně kalendář akcí, možnost přihlašování na akce a autorizaci uživatelů stránek. Toto není v současném systému eStránek možné, a proto bylo rozhodnuto o hledání jiného řešení. 1.3.2.2
Webgarden|zone
Webgarden|zone [16] dává uživateli podobné možnosti jako eStránky. On-line publikační systém umožňuje vytvoření a správu dynamických internetových stránek bez znalosti HTML a jiných webových technologií. Stránky se opět vytvářejí snadno a rychle, vše je zdarma. Do stránek lze vkládat články, galerie a odkazy, zakládat diskuze, vytvářet ankety a uploadovat soubory. K dispozici je více než sto předvolených vzhledů, které můžeme upravovat pomocí editoru či přímým zápisem do souboru CSS. Obsah stránek se dělí do rubrik. Stránky mají adresu „ jmenostranek.domena-od-webgardenu.cz”, přičemž je k dispozici několik domén druhého řádu. Stránky se spravují pomocí rychlé a přehledné administrace. Chci zmínit několik výhod oproti eStránkám. Nenároční uživatelé jistě ocení pěkné průvodce na vytvoření blogu, galerií, fór, magazínu či běžných www stránek. Přednasta-
6
KAPITOLA 1. ÚVOD
vené vzhledy se mi osobně zdají být atraktivnější, stránky působí moderněji. Užitečným nástrojem jsou ankety, všechny druhy příspěvku mohou být řazeny abecedně, chronologicky i manuálně. Panel novinky zveřejňuje aktuální změny na stránkách. Jako nejzajímavější výhodu považuji zavedení systému práv a uživatelských skupin. Pomocí nich lze omezit přístup do jednotlivých sekcí stránek s tím, že každý uživatel má své uživatelské jméno a heslo. Díky čemuž jsou zabezpečené sekce výrazně bezpečnější než zamykání na eStránkách. Závěr: Kdybychom se chtěli při tvorbě stránek pro tábor rozhodnout pro využití on-line systémů, bylo v současné době nejvhodnějším řešením použití právě Webgardenu kvůli lepší bezpečnosti nebo novým zajímavým funkcím v porovnání s eStránkami. Problematika přihlašování dětí na tábor a jiné akce a jejich následná administrace není ani zde řešena, a tak se podíváme na další možnosti, které se nám nabízejí. 1.3.3
Redakční systémy
Systém pro správu obsahu, často označovaný zkratkou CMS, je software spravující informace různého charakteru, který se zároveň stará i o jejich efektivní využití a zobrazení na některém z předpřipravených výstupů. V zásadě je jedno, jakým způsobem jsou data ve finále publikována, velmi často jsou tímto výstupem dynamicky generované HTML stránky. Uživatelé k nim přistupují prostřednictvím internetových prohlížečů. Můžeme zde pak hovořit o tzv. systému pro správu webového obsahu (WCM). Pro CMS se často používají i termíny publikační či redakční systém4 . 1.3.3.1
Vlastnosti
Redakční systém umožňuje lehce a rychle vkládat nový obsah a upravovat stávající. Stejně jako u dříve popsaných on-line řešení nemusíme mít technické znalosti potřebné pro tvorbu stránek. Veškerý obsah je většinou ukládán do databáze, ze které se informace při příchodu návštěvníka následně čtou. Vedle tvorby obsahu se systém zabývá i provázání jednotlivých článků, poskytuje různé kontroly a optimalizace. Pro potřeby neustálé aktuálnosti stránek můžeme využít krátkých textových zpráv ve formě novinek. Součástí bývá i možnost vytvoření fotografických alb. Velmi silnou stránkou některých RS je přístupový management, pomocí kterého je možno autorizovat uživatele. V některých případech jde uživateli přidělit i specifická přístupová práva k jednotlivým částem systému. Umožňuje to vytváření webu více lidmi najednou. Každý může spravovat svou sekci a administrátor vše korigovat. Redakční systém stránkám dodává i množství dynamických prvků. Obsahuje tvorbu a správu diskuzí, komentářů, anket, umožňuje tak získat zpětnou vazbu uživatele. Články se v redakčních systémech dají nastavit tak, aby se zobrazili jen v určitém časovém intervalu. Můžeme si připravit článek, který vyjde např. až další den ráno. Po uložení článku do systému je článek pomocí šablon vzhledů, kterých bývá na výběr velké množství, zobrazován uživatelům společně s automaticky doplněnými anketami, možností vkládání komentářů či s dalšími funkcemi. Komentáře a ankety se administrují v jiné části systému. 4
Zkráceně RS.
KAPITOLA 1. ÚVOD
7
Některé CMS obsahují i pokročilé nástroje jako jsou statistiky, editor obrázků, správa verzí dokumentů, úkolování a interní komunikace mezi autory, centrální správu všech souborů určených ke stažení. 1.3.3.2
Možné využití
Současné redakční systémy jsou natolik vyspělé a do značné míry i univerzální, že je lze využít při řešení téměř všech typů informačních webů kromě vysoce specializovaných zadání typu elektronický obchod. Tato univerzálnost nemění nic na skutečnosti, že existují zadání, pro jejichž řešení se publikační systémy hodí více, a zadání, ve kterých je použití minimálně sporné či zcela nevhodné. Nejklasičtější příklad vhodného využití redakčního systému je nasazení v rámci zpravodajského serveru. V případě využití aktualit, ankety a dalších součástí RS může vzniknout velmi zajímavý a dynamický firemní web malé či středně velké firmy. Prezentace státních, obecních a neziskových organizací funkčně a vzhledově většinou kombinuje vlastnosti zpravodajských a firemních serverů. Jako nevhodné nasazení publikačních systémů je použití v rámci elektronického obchodu. Je vždy lepší využít aplikaci, která je pro tento typ činnost navrhována již od samého počátku. Implementace v rámci RS může vést až k nepřekonatelným problémům s funkčností nebo vlastnostmi e-shopu. Velké firemní prezentace mají většinou složitou strukturu, kombinují statický a dynamický přístup k tvorbě stránek. Přistupuje se k nim na různých uživatelských úrovních, často je třeba je napojit na interní informační systémy. 1.3.3.3
Praktické nasazení systému
Samostatnou kapitolou při zavádění redakčních systémů je jejich finanční stránka. Ve většině případů vychází jako levnější řešení nasazení CMS v porovnání s vývojem vlastního webu, kdy za méně peněz dostaneme stejnou nebo i lepší funkčnost. Vedle komerčních řešení je na internetu k dostání obrovské množství open source produktů. Je si z čeho vybírat, nalezneme i řadu velmi kvalitních programů. CMS se člení dle řady kritérií, například rozsahu řešení, použitého vývojového prostředí nebo cílové skupiny. Nejoblíbenější systémy, které jsou zdarma k dostání, bývají naprogramovány v PHP v kombinaci s databázovým systémem, často s MySQL (technologické podrobnosti jsou popsány v samostatné kapitole této práce). Webové publikační systémy obvykle vyžadují zkušeného programátora, který nastaví jednotlivé funkčnosti. Běžnou správu zvládají administrátoři bez velkých technických zkušeností. Rozhodneme-li se využít redakční systém, musíme si krom samotného systému zajistit i místo, kam jej na internetu umístíme. Obecně lze říci, že potřebujeme server, který umožňuje spouštění programů, v nichž je redakční systém implementován. Stejně tak musí zpřístupnit databázový stroj, se kterým se v systému počítá. Existuje velké množství poskytovatelů webového prostoru, kteří nabízejí služby PHP a MySQL svým zákazníkům. Rozsah služeb se samozřejmě liší, ať už jde o množství povoleného uložení dat, množství přenášených dat za měsíc atd. Tyto firmy provozují tzv. webhosting, v pří-
8
KAPITOLA 1. ÚVOD
padě poskytnutí služeb zdarma se jedná o freehosting. Služby zdarma obvykle požadují jako protislužbu zobrazení reklamy či mohou být méně spolehlivé. Bezplatné redakční systémy lze provozovat i na řadě freehostingových serverech, kdy jsou náklady na zavedení a používání systému nulové (nepočítáme-li čas strávený seznámením s produktem, jeho instalací a nastavováním). Vždy je třeba zkontorolovat, zda daný hostingový server je nastaven tak, aby vyhovoval i zaváděnému systému. Požadavky jsou různé pro jednotlivé systémy. Na českém internetu lze zadarmo získat prostor o velikosti až jeden GB. Hlavně v případě, že máme např. velký objem uložených fotografií (a dat obecně), budeme muset pro získání prostoru o velikosti několika GB sáhnout po placeném hostingu. Jeho cena se v České republice pohybuje od cca 75 Kč za měsíc [20]. 1.3.3.4
Zhodnocení
Jak již bylo řečeno, je na trhu dostupné velké množství redakčních systémů. S ohledem na co nejmenší finanční náročnost by bylo možné pro plánovaný táborový systém využít některý z bezplatných CMS. Mezi nejoblíbenější patří Joomla! [7], Drupal [2], Wordpress [18] nebo PhpRS [13].
Obrázek 1.3: Ukázka použití redakčního systému Drupal na stránkách věnovaných nástroji phpMyAdmin. Závěr: Při seznamování s možnostmi redakčních systémů je vhodné vyzkoušet online demo, které je v řadě případů přítomno na stránkách jednotlivých systémů. Lze si prohlédnout i reálné aplikace, které jsou na zkoumaných produktech postaveny. Prošel jsem si možnosti některých redakčních systémů. Jsou opravdu bohaté, pochopitelně se liší systém od systému. S jejich využitím by se dala implementovat většina
KAPITOLA 1. ÚVOD
9
funkčnosti, které požadujeme od táborových stránek. Bohužel jsem nenašel produkt, který by realizoval požadovaný způsob přihlašování na akce a jejich následné zpracování včetně různých reportů. Nelze ale vyloučit, že nějaký takový systém existuje. Obecným problém bezplatných systémů je, že často nejsou dostatečně zdokumentovány. Případné doprogramování neexistujících funkčností se tím stává poměrně obtížné. Výsledný systém pro dětský letní tábor nemá být nějak extrémně rozsáhlý. Použití RS by paradoxně mohlo vést k situaci, že budou zavedeny služby, které nebudou využívány, resp. svou rozsáhlostí bude výsledek na uživatele působit nepřehledně. Spolu s nutností dodělávání funkcí týkajících se přihlašování na akce a s tím spojenou potřebou proniknout alespoň částečně do složitých kódů redakčních systémů nepovažuji využití redakčního systému v našem případě za přínosné. 1.3.4
Shrnutí
V úvodní kapitole jsme si představili možnosti, které vedou více či méně úspěšně k vytvoření informačního systému pro dětský tábor. Podle mého názoru bude nejjednodušší variantou vytvoření stránek zcela nových, bez využití nějakého existujícího produktu. Pochopitelně je při implementaci přínosné aplikovat již některé hotové komponenty, které jsou volně dostupné na internetu. Tyto budou zmíněny v následující kapitole týkající se použitých technologií. Chtěli-li bychom využít některého z popisovaných produktů, pak bych doporučil Webgarden|zone. Museli bychom se smířit s tím, že neumožňuje vše, co je od systému očekáváno. Na druhou stranu toho poskytuje více než současný systém. V případě, že bychom od táborových stránek očekávali nějaké masivní rozšiřování záběru poskytovaných služeb, navrhuji využít pěkného českého redakčního systému Drupal, který má na svých stránkách i bohatou uživatelskou podporu.
10
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
2 Použité technologie a metodiky 2.1
HTML
HTML patří do skupiny tzv. značkovacích jazyků, je používáno pro tvorbu internetových stránek. Poskytuje prostředky, kterými můžeme popsat strukturu textového dokumentu, jenž má být publikován na internetu. Jazyk je charakterizován definovanou množinou značek1 a jejich atributů. Mezi značky se uzavírají části textu dokumentu a tím se určuje význam obsaženého textu. Názvy jednotlivých značek se uzavírají mezi úhlové závorky („<” a „>”). Část dokumentu uzavřená mezi značkami tvoří element dokumentu. Součástí obsahu elementu mohou být další vnořené elementy. Atributy jsou doplňující informace, které upřesňují vlastnosti elementu. Normy a doporučení pro jazyk HTML schvaluje nezávislé mezinárodní standardizační konsorcium W3C. HTML prošlo rozsáhlým rozvojem, a tak se setkáváme s řadou verzí jazyka. Vývoj byl původně ukončen verzí 4.01, která je v současnosti při použití HTML standardem. Dle W3C mělo další publikování dokumentů v prostředí internetu patřit XHTML. Některým lidem se však vývoj okolo XHTML nezamlouval. W3C během roku 2007 založilo novou pracovní skupinu HTML, jejíž cílem je v roce 2010 uvolnit specifikaci nové HTML verze 5.
2.2
CSS
CSS je jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML navržený organizací W3C. Byly vydány zatím dvě verze specifikace CSS 1 a CSS 2 (a opravná verze CSS 2.1), již delší dobu je vyvíjena CSS 3. Zkratka CSS znamená cascading style sheets, česky překládané jako kaskádové styly. Kaskádové, protože se na sebe mohou vrstvit definice stylu, ale platí jenom ta poslední. Hlavním smyslem použití je umožnit návrhářům oddělit vzhled dokumentu od jeho struktury a obsahu. Původně to měl umožnit už jazyk HTML, ale v důsledku nedostatečných standardů a konkurenčního boje výrobců prohlížečů se vyvinul jinak. Starší verze HTML obsahují celou řadu elementů, které nepopisují obsah a strukturu dokumentu, ale i způsob jeho zobrazení. Z hlediska zpracování dokumentů a vyhledávání informací není takový vývoj žádoucí. V současné době všechny moderní prohlížeče internetových stránek CSS podporují. Nelze jej užít ve velmi starých prohlížečích (Explorer 2 a Navigator 3), které se však již nevyskytují. Textové prohlížeče a některá mobilní zařízení také nepodporují definice CSS k zobrazení, text se v nich nezformátuje, ale zůstává čitelný.
1
Často se jako synonyma používá termínu tag, který pochází z angličtiny.
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
2.3
11
JavaScript
JavaScript je multiplatformní programovací jazyk, jenž vyvinula společnost Netscape. Zpravidla se používá jako interpretovaný programovací jazyk pro www stránky, který je vkládan přímo do HTML kódu stránky. Slovo Java je součástí jeho názvu pouze s marketingových důvodů, s programovacím jazykem Java jej však spojuje jen podobná syntaxe. Program v JavaScriptu se obvykle spouští až po stažení www stránky z internetu, tj. na straně klienta2 (klientský skript). To je rozdíl od jiných interpretovaných programovacích jazyků (např. PHP), které se spouštějí na straně serveru (serverové skripty) ještě před stažením z internetu a které klientovi posílají už jen výsledky. Z toho plynou jistá bezpečností omezení, JavaScript např. nemůže pracovat se soubory, aby tím neohrozil soukromí uživatele. JavaScript se používá například při vstupní kontrole dat vkládaných do formulářů ještě před tím, než jsou vyplněné údaje odeslány na server. Kontrolu údajů nemusí provádět server a výsledkem je rychlejší odezva pro uživatele3 . JavaScript pracuje s jednotlivými komponentami prohlížeče a stránky pomocí objektového modelu dokumentu (DOM). JavaScript funguje ve všech moderních prohlížečích, často není podporován v mobilních zařízeních. Uživatel navíc může JavaScript ve svém prohlížeči zakázat. Proto je nutné při vývoji internetových aplikací s JavaScriptem buď zajistit podporu JavaScriptu v prohlížeči (což lze např. ve firmě) nebo je nutné umožnit uživateli použití stránek i s vypnutým JavaScriptem, byť by měl být snížen jeho uživatelský komfort při práci se stránkami.
2.4
Apache
Webovým serverem rozumíme počítač připojený k počítačové síti s nainstalovaným softwarovým webovým serverem, který od klientů (internetových prohlížečů) přijímá požadavky ve tvaru HTTP a je zodpovědný za jejich vyřizování. Vyřízením požadavku se rozumí odeslání webové stránky počítači, který požadavek vznesl. Odpověď obvykle představuje nějaký HTML dokument. Může to být ale i dokument v jiném formátu (text, obrázek apod.). Server má v zásadě dvě možnosti, jak získávat informace, které vrací klientům. Jsou to buď předem připravené datové soubory (HTML stránky), které webový server bez změny poskytne klientovi. Hovoříme pak o tzv. statických www stránkách. Nebo může teprve na základě požadavku klienta shromáždit potřebná data (přečíst ze souboru, z databáze atp.), zformátovat je a připravit k prezentaci většinou formou HTML (či XHTML). takto připravený dokument je poskytnut internetovému prohlížeči, který zaslal požadavek. V tomto případě jde o tzv. dynamické stránky. K dynamickému vytváření obsahu se používá celá řada různých technologií (např. JavaScript je možné použít i na straně serveru. První implementací JavaScriptu na straně serveru byl LiveWire firmy Netscape vypuštěný roku 1996. 3 Toto využití nemá s nástupem rychlého internetu v posledních letech již tak velký přínos jako dříve. 2
12
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
Perl, PHP, ASP), v této práci bude použito PHP. Statický obsah je schopen server poskytnout významně rychleji než dynamický. Na druhé straně pomocí dynamického obsahu lze poskytovat mnohem větší obsah informací a lze reagovat i na různé dotazy klientů. Proto se v praxi v mnoha případech oba způsoby poskytování obsahu kombinují. Apache Server [1] je softwarový webový server s otevřeným kódem pro Linux, MS Windows a další platformy. V současné době dodává prohlížečům na celém světě většinu internetových stránek. Apache je dostupný zdarma, poměrně jednoduše se instaluje i na domácí počítač, čímž lze zdarma spolu se skriptovacím jazykem PHP a databází MySQL vytvořit velmi kvalitní vývojové prostředí internetových aplikací. Název Apache vznikl z anglického „a patchy server”, tedy záplatovaný server. Odvozuje z historie programu, kdy byl Apache mezi správci serverů používán s mnoha různými záplatami a úpravami. Jako indiánský symbol je ve znaku ptačí pero.
2.5
PHP
PHP je skriptovací programovací jazyk určený především pro programování dynamických internetových stránek. Nejčastěji se začleňuje přímo do struktury jazyka HTML či XHTML, což je velmi výhodné pro tvorbu webových aplikací. PHP lze ovšem také použít i k tvorbě konzolových a desktopových aplikací. Skripty PHP jsou prováděny na straně serveru, k uživateli je přenášen až výsledek jejich činnosti a to stejným způsobem, jakým se odesílají běžné statické stránky. Syntaxe jazyka kombinuje hned několik programovacích jazyků (Perl, C, Pascal a Java). PHP je nezávislé na platformě, skripty fungují bez úprav na mnoha různých operačních systémech. Obsahuje rozsáhlé knihovny funkcí pro zpracování textu, grafiky, práci se soubory, přístup k většině databázových serverů, podporu celé řady internetových protokolů. S verzí PHP 5 se výrazně zlepšil přístup k objektově orientovanému programování. Jazyk PHP se stal velmi oblíbeným především díky jednoduchosti použití a tomu, že kombinuje vlastnosti více programovacích jazyků. Nechává tak vývojáři částečnou svobodu v syntaxi. V kombinaci s databázovým serverem (nejčastěji s MySQL nebo PostgreSQL) a webovým serverem Apache je často využíváno k tvorbě webových aplikací. PHP je open source technologie, kterou můžeme volně stáhnout na oficiálním serveru projektu www.php.net, kde najdeme i výbornou on-line dokumentaci [25] s velkým množstvím příkladů použití.
2.6
MySQL
MySQL [9] je databázový systém dostupný jak pod bezplatnou licencí GPL, tak pod komerční placenou licencí. MySQL je multiplatformní databáze. Komunikace s ní probíhá pomocí jazyka SQL. Podobně jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s některými rozšířeními. Pro svou snadnou implementovatelnost v různých operačních systémech (MS Windows a Linux nevyjímaje), výkon a především díky tomu, že se jedná o volně šiřitelný
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
13
software, má vysoký podíl trhu používaných databází v oblasti internetových aplikací. Jak již bylo dříve zmíněno, jako základní software webového serveru je velmi oblíbená a často nasazovaná kombinace MySQL, PHP a server Apache. Od počátku bylo MySQL optimalizováno především na rychlost, a to i za cenu některých zjednodušení: má jen jednoduché způsoby zálohování, a až donedávna nepodporovalo pohledy, triggery, a uložené procedury4 MySQL nenabízí v základní instalaci pro práci s daty žádné grafické rozhraní, SQL dotazy lze provádět přes příkazový řádek. Pro jednoduché vytváření, spouštění a optimalizaci SQL dotazů je možné doinstalovat vizuální nástroj MySQL Query Browser, který je též dostupný na stránkách projektu. Velmi oblíbenou alternativou k tomuto nástroji je PHPMyAdmin [11]. Jedná se aplikaci napsanou v PHP, kterou lze provozovat na vývojové stanici a která dovoluje vytvářet a spravovat databáze na místním počítači.
2.7
AJAX
2.7.1
Princip
Ajax je nová technologie používaná při vývoji internetových aplikací. Název je zkratkou pro Asynchronous JavaScript and XML a byl poprvé použit v únoru 2005. Samotné komponenty, jež Ajax využívá, existují již od roku 1998. Ajax umožňuje vytváření interaktivnějších webových stránek, které mohou okamžitě reagovat na uživatelovo chování. Děje se tak pomocí malých ”kousků” dat, které jsou vyměňovány se serverem na pozadí. Pokyn k výměně dat je před zrakem uživatele ukryt, a tak stránka nemusí být při změně vždy znovu celá načítána. Popsaný princip ukazuje obrázek 2.1.
Obrázek 2.1: Princip volání Ajaxu. [21] Důvodem pro použití Ajaxu je zvýšení interaktivnosti stránky, rychlosti zobrazení nových informací, vytvoření nové funkcionality a uživatelské přívětivosti. 4
Objevily se až od verze 5.
14
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
2.7.2
Používané techniky
Ajax je metoda nezávislá na použité platformě, nezávisí na operačním systému ani použitém hardware. Je podporována všemi moderními prohlížeči ať už jde o Internet Explorer či Mozilla Firefox, tak i Operu. V krátkosti si uveďme, jakých technologií Ajax využívá: • Pro zobrazování informací je použito standardního XHTML (popř. HTML) a CSS. • Nezbytnou složkou pak je JavaScript, který umožňuje vytvářet funkcionalitu na straně klienta, k manipulaci s částmi HTML stránky používá DOM. • Základní elementem je objekt XMLHttpRequest, který umožňuje JavaScriptu asynchronní výměnu dat s webovým serverem. Komunikace mezi klientem a serverem probíhá na pozadí, uživatel tak může nerušeně pokračovat v práci. Tato komunikace znamená vytvoření HTTP požadavku na soubor či skript, který je umístěný na serveru. • Většinou je pro přenos dat mezi serverem a klientem využit XML formát, avšak lze použít i prostý text, HTML či JSON. Klasické webové stránky zobrazují data, která jsou uložena v databázových strojích na serveru, nejsou s nimi však pevně svázány. Před tím, než jsou informace z databáze dodány do uživatelova prohlížeče, je nutné je všechny „zabalit” do jednoho HTML kódu a odeslat, klient celý kód přijme a zobrazí. Proto vždy, když se chce uživatel podívat na byť jen trochu jinou množinu dat, musí být znovu načtena celá internetová stránka. Žádost o nová data a jejich příjem pomocí objektu XMLHttpRequest odstraňuje nutnost požadavku na server pro zaslání celé stránky. Pro zobrazení nových dat tedy nemusí být přenesena kompletní webová stránka. Pro porozumění si ještě vysvětleme, v jaké formě si během asynchronního přenosu klientská a serverová strana předávají svá data. Klientský skript, který přistupuje k serveru pomocí XMLHttpRequest může prostřednictvím metod GET a POST poslat dvojice „ jméno-hodnota”. Tyto dvojice lze na straně serveru přečíst libovolným skriptem. Serverový skript zasílá odpověď zpět pomocí HTTP, ale na rozdíl od klasické internetové stránky je odpověď ve formátu, který je parsován JavaScriptem v klientovi. Jak již bylo poznamenáno, nejčastěji je tímto formátem XML a to kvůli velkému rozšíření a množství dostupných knihoven, pomocí nichž lze s daty v XML manipulovat. Využitím Ajaxové technologie posouvá běžnou internetovou stránku více na úroveň aplikace, protože stránka může být, obdobně jako běžná desktopová aplikace, velmi úzce svázána s daty uloženými v databázovém stroji na serveru. 2.7.3
Výhody
Zmiňme si nyní výhody, které použití Ajaxu ve webových aplikacích přináší. Jak bylo zmíněno, patří mezi ně odstranění nutnosti znovunačtení a opětovného zobrazení celé stránky při každé operaci. Velmi vhodné využití je např. při bodovém hodnocení kvality
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
15
fotografií, článků či při hlasování v anketách. Stránka zůstává většinou celá nezměněná a aktualizuje se jen výsledek hlasování. Jelikož není potřeba při každém požadavku sestavit celý HTML dokument, ale pouze provedené změny, je množství přenášených dat výrazně menší a nasazení Ajaxu může výrazně snížit vytížení sítě, popř. i zátěž webových serverů. Zároveň ale dochází ke zvýšení počtu vyměňovaných HTTP požadavků, které mohou způsobit, že při nevhodné implementaci zátěž neklesne. Ajax umožňuje vytvářet lepší a přístupnější webové aplikace, stránky, které jsou pro uživatele větším „zážitkem” než klasické internetové stránky. Protože používá stávající technologie, je možné Ajaxu využívat ihned v plném rozsahu, po vývojářích nevyžaduje velké množství zcela nových znalostí. Díky své popularitě podporuje tzv. vzory, které vývojářům pomáhají, aby se při běžných úkolech vyhnuli vynalézání již dávno známých věcí. 2.7.4
Nevýhody
Mezi nevýhody patří hlavně změna náhledu na internetovou aplikaci jako takovou. Webové stránky již nejsou jen posloupností stránek, mezi kterými lze přepínat pomocí tlačítka „zpět”. Jedna stránka může procházet mnoha stavy, mění se na ní zobrazené informace, a tak použití tlačítka „zpět” může uživateli přinést zcela jiný výsledek než očekával. Ajaxové internetové aplikace se totiž svým chováním blíží plnohodnotným desktopovým aplikacím se složitou vnitřní logikou. Vývojáři se samozřejmě snaží problém s historií stránek řešit, a tak nejnovější aplikace jsou už schopny funkce tlačítek „zpět” a „následující” alespoň částečně obnovit. Využívají k tomu např. neviditelných „iframe”5 . S tímto úzce souvisí i obtížnost bookmarkování konkrétního stavu webové aplikace. Ukládání stavu aplikace lze řešit s využitím textu za znakem „#” v URL stránky. Mnoho prohlížečů umožňuje JavaScriptu dynamicky upravovat část URL za „#”, a tak Ajaxové aplikace mohou tuto část měnit zároveň s tím, jak uživatel mění stav aplikace. Toto řešení též vylepšuje podporu tlačítka „zpět”. Typickou ukázkou popsaného je implementace mapového serveru Mapy.cz. Dalším problémem může být též doba síťové odezvy serveru na asynchronní požadavek klienta. Potřeba komunikace přes internet může mít negativní dopad na rychlost odezvy a interaktivitu uživatelského rozhraní. Pokud uživateli není jasně naznačeno, že aplikace zpracovává jeho požadavek, jediné, čeho si všimne, je zpožděná reakce aplikace. To může vést i k tomu, že se pokusí provést operaci znovu, protože se domnívá, že systém jeho příkaz ignoroval. Pro vyhledávací roboty není jednoduché indexovat internetové stránky, které využívají Ajax. Vývojář proto nesmí spoléhat jen na to, že si vyhledávač jeho stránku najde a správně zaindexuje, ale musí mu speciálními technikami pomoci. Uživatelům, jež mají vypnutý JavaScript a tudíž nemohou využívat Ajaxových vymožeností, by se měly internetové stránky zobrazovat plnohodnotně co do informační hodnoty, byť třeba s menším uživatelským komfortem. Rozhodně by se vývojáři měli 5
Iframe je tag v HTML a XHTML
16
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
vyvarovat situace, kdy s vypnutým JavaScriptem bude uživatel zcela „odříznut” od aplikace. Proto se doporučuje vytvořit aplikaci celou bez využítí technik Ajaxu a následně provést Ajaxová vylepšení. Ajax spoléhá na JavaScript, který bývá implementován rozdílně jak různými druhy prohlížečů, tak i různými verzemi jednoho prohlížeče. Kvůli tomu je potřeba aplikaci otestovat v několika různých internetových prohlížečích, abychom zajistili bezchybný chod internetové aplikace. Často se stávalo, že některé části JavaScriptového kódu musí být psány dvakrát, jednou pro Internet Explorer a podruhé pro Mozillu. S nejnovějšími verzemi prohlížečů se naštěstí tento problém stále zmenšuje, čemuž napomáhá i vznik abstraktních JavaScriptových knihoven.
2.8 2.8.1
Texy! a Texyla Texy!
Texy! [14] je program, díky kterému můžeme snadno, bez odborných znalostí, psát texty do webových stránek. Umožňuje jednoduše zvýraznit písmo, vytvořit nadpis či odrážky, přidat obrázek nebo tabulku. Generuje vždy validní HTML nebo XHTML kód, podporuje CSS, rozumí všem obvyklým kódováním včetně Unicode, je dokonale konfigurovatelné a přizpůsobitelné. Původně vzniklo Texy! jako nástroj, který umožnil i uživatelům neznalým HTML snadno editovat obsah webových stránek. Záměrem bylo vytvořit silnou alternativu k WYSIWYG editorům, které se v praxi ukazují jako neefektivní. Běžný uživatel se může plně věnovat psaní čistého textu, který si formátuje velmi přirozeným způsobem. A nemusí se učit téměř nic nového. Zkušení tvůrci internetového obsahu, jakými jsou například bloggeři, často jazyk HTML znají. Ale psát články přímo v něm je nepříjemné a proto si zjednodušují práci používáním chytrých editorů. Jedním z nich je i Texy!. Je navíc dostupný i přes webové rozhraní a nabízí neobvykle vysoký komfort. Díky Texy! se autor může plně věnovat obsahu dokumentu a nemusí uvažovat nad HTML nebo typografickou úpravou. Texy! dokáže psaní výrazně zjednodušit, přitom pokročilého uživatele nijak neomezuje - lze vkládat i HTML značky a CSS formátování. Texy! počítá i s nasazením jako formátovač příspěvků v diskuzních fórech a komentářích. Přispěvatelé mohou používat jednotnou a intuitivní syntaxi a programátorům odpadne náročná práce na vlastním formátovači. Tato oblast použití je charakteristická tím, že vyžaduje mnohem přísnější kontrolu vstupů. Texy! proto obsahuje mechanismy, které zakáží nebo omezí použití určitých HTML značek (a jejich atributů), kaskádových stylů atd. Pisatel komentáře totiž může odeslat prakticky jakýkoliv shluk písmen a je jen na aplikaci, aby se s nimi vypořádala a vrátila validní a očekávatelný HTML kód. Komentář může být napsán se záměrem podvrhnout záškodnický kód např. ve formě JavaScriptu.
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
17
Ukažme si několik příkladů syntaxe Texy!: Hlavní titulek **************
Podtitulek ==========
//kurzíva//
**tučné**
Závěrem si ještě řekněme, proč jsem se rozhodl v této práci místo oblíbených WYSIWYG editorů použít Texy!. WYSIWYG editor zobrazuje zpracovávaný obsah během editace v takové podobě, v jaké bude ve výsledku zobrazen na internetu. Výsledná stránka (či její část) je vytvářena psaním textu a jeho formátováním pomocí různých funkčních tlačítek. Tvorba obsahu stránky či příspěvku do diskusního fóra je tak podobná s vytvářením běžného textového dokumentu v pokročilých textových editorech jako MS Word či OpenOffice. Tento druh editorů zažil v oblasti správy internetového obsahu skutečný boom, dnes jsou součástí většiny redakčních systémů. V praxi se však ukazuje, že přednosti zmiňovaných editorů nejsou tak jednoznačné, jak se na první pohled zdají. Řada vizuálních editorů negeneruje použitelný kód, výsledné zobrazení vkládaného či upravovaného obsahu bývá často odlišné od zobrazení ve WYSIWYG editoru. Po špatných zkušenostech z eStránek, kdy editor velmi obtížně umožňoval pracovat s tabulkami nebo do výsledného HTML kódu vkládal spoustu nesmyslných značek, jsem se rozhodl, že bych chtěl pro můj projekt využít jiného modelu, bude-li to možné. Proto jsem ocenil možnosti, které jsem nalezl u Texy! a jeho Ajaxové implementaci Texyly, které se budu věnovat níže. Texy! je implementována v PHP a je dostupná pod GPL licencí. Tzn. že aplikaci lze zdarma použít pro vlastní potřebu. Je možné ji dále i distribuovat, ale pouze včetně zdrojových kódů, nedotčených zmínek o vlastnictví autorských práv a se svolením, že kdokoliv další může aplikaci opět šířit dál. 2.8.2
Texyla
Editor Texyla [15] je Ajaxová nadstavba pro výše zmiňovaný formátovač Texy!, pochopitelně je naprogramovaná v PHP s využitím JavaScriptu. Nevýhodou použití samotné Texy! je, že vždy, když se chceme podívat na výslednou podobu upravované stránky, je nutné ji nejprve uložit, a pak případně opět načíst k další editaci. Texyla tuto nevýhodu smazává. Umožňuje totiž zobrazit text zpracovaný pomocí Texy! již při samotném psaní. Stačí jen v případě potřeby zmáčknout tlačítko „formátovat” a obsah formulářového prvku „textarea”, v němž je vložen zpracovávaný text, je odeslán pomocí JavaScriptu ke zpracování formátovači Texy!. Výsledek je pak zobrazen v náhledovém prvku. Díky využití Ajaxu zůstává při zobrazení náhledu v tagu „textarea” zbytek stránky nezměněný. V Texyle používáme standardní formátovací řetězce z Texy!. Můžeme si však pomoci i využitím klikacích ikonek (viz. obrázek 2.2), které editovaný text zformátují za nás. Programátor stránek může při zavádění Texyly do svých stránek nastavit jednotlivé konkrétní ikony, které se budou uživateli zobrazovat. Např. v administračním rozhraní pro psaní článků jich asi bude uvedeno více, naopak v diskusním fóru budeme chtít možnosti formátování omezit, a tak nabídneme jen některé ikonky. Náhled zpracovávaného textu lze zobrazit stiskem jediného tlačítka.
18
KAPITOLA 2. POUŽITÉ TECHNOLOGIE A METODIKY
Obrázek 2.2: Vlevo editační okno Textyly s Texy! kódem. Vpravo pak náhled editovaného textu.
2.9
webhosting
Jak jsem psal už v části věnované webovému serveru Apache, je pro vývoj internetové aplikace možné použít lokální počítač. Nejpozději když máme hotovou finální aplikaci, budeme se muset porozhlédnout po místě, kam hotový produkt na internetu umístit a následně jej tam zprovoznit. Ve skutečnosti je lepší už dříve testovat jednotlivé části systému v ostrém provozu, abychom nebyli překvapeni nefunkčností některých částí naší aplikace. Většinou to bývá způsobeno jiným nastavením konfigurace serveru než máme u sebe na lokálním pc. Pro zpřístupnění našich stránek uživatelům si tedy musíme najít vhodný webhosting, tj. pronájem prostoru pro webové stránky na cizím serveru. Díky tomu můžeme umístit své webové stránky na internet, aniž bychom museli mít vlastní server. Poskytovatelé webhostingu většinou v rámci služby nabízí skriptovací technologie jako PHP nebo ASP, z databází jsou nabízeny především MySQL, PostgreSQL a MS SQL. Stránky se na server kopírují protokolem FTP. Webhosting je pouze samotné umístění stránek na serveru poskytovatele. Aby se uživatelé internetu ke stránkám dostali, je potřeba mít zaregistrovánu doménu, což je jednoznačné jméno (adresa) identifikující místo, kde jsou uloženy dané internetové stránky. Pro zavedení táborového informačního systému je v první fázi možné použít služeb některého z poskytovatele freehostingových služeb. Zajímavou nabídku přináší firma ProFiTux.cz, která nám nabízí zdarma v rámci freehostingu [12] 300 MB prostoru pro stránky, podporu PHP verze 5 a MySQL 4.1, emailovou schránku a další. V rámci freehostingu bývá vždy možnost registrace adresy stránek, která v případě ProFiTuxu může být např. taborheraltice.profitux.cz. Po zprovoznění a úspěšném zaběhnutí táborového systému navrhuji u ProFiTuxu zřízení placeného hostingu, kdy nejsme omezování velikostí datového prostoru a jsou nám k dispozici i další služby jako cron, což je automatické spouštění skriptů v určený čas. Cena webhostingu je 75 Kč za měsíc. Je nutné ještě registrovat internetovou adresu. Tu v doméně .cz (např. tedy taborheraltice.cz) pořídíme okolo 300 Kč za rok.
KAPITOLA 3. ÚVODNÍ STUDIE
19
3 Úvodní studie 3.1
Deklarace záměru
Vyvíjený informační systém pro organizátory dětského tábora v Heralticích na Třebíčsku se bude využívat v několika oblastech. Poslouží jako prezentace dětského tábora na internetu pro rodiče a jejich děti. Umožní jednoduchou komunikaci mezi vedoucími a mezi vedoucími a dětmi, které se už některé táborové akce zúčastnili. Tato komunikace bude řešena formou diskusích fór, publikováním fotografií z akcí, zveřejňováním kontaktů. Bude implementován i kalendář mimotáborových akcích, na které se půjde přihlásit on-line. Informační systém ulehčí také organizaci tábora. Pořadatelé budou moct vytvářet automatizované seznamy účastníků tábora, které jsou nutné k zajištění jeho bezproblémového chodu. Vyvíjený informační systém musí být přístupný z jakéhokoli počítače připojeného k internetu, budeme tedy vyvíjet internetovou aplikaci. Jelikož tábor je pořádán jako nekomerční, je cílem, aby byl výsledný systém co nejlevnější.
3.2
Odborný článek
Se svými přáteli již mnoho let spoluorganizuji dětský letní tábor v Heralticích, v malé vísce na Vysočině nedaleko Třebíče. Tábor je organizován zejména pro členy judistického oddílu z Kladna a z Prahy - Kobylis. Kromě judistů se tábora mohou v omezené míře zúčastnit i nejudisté, zejména příbuzní vedoucích a instruktorů. Přihlášení na tábor probíhá formou vyplnění krátké nezávazné přihlášky, kterou děti obdrží začátkem kalendářního roku během tréninků. Nejudistům jsou tyto přihlášky distribuovány pomocí příbuzných z řad vedoucích tábora, popř. po kamarádech, kteří se judistických tréninků účastní. Poté, co je vytvořen seznam zájemců, jsou jim během jara rozdány výše uvedeným způsobem i detailní závazné přihlášky spolu s podrobnými informacemi o táboře a formuláři k potvrzení bezinfekčnosti dítěte, resp. zdravotní způsobilosti dítěte k účasti na táboře. Vyplněná přihláška se odevzdává během dubna, opět většinou na trénincích. „Bezinfekčnost” a „způsobilost” odevzdávají rodiče vyplněné až při samotném odjezdu na tábor. Tábora se účastní přibližně 40 dětí ve věku 7-15 let. Některé děti, které přesáhnout tuto věkovou hranici, mohou jezdit i nadále na tábor ve funkci instruktora, obvykle jich bývá kolem čtyř pěti. Je jim 15-18 roků. Ostatní účastnící tábora starší 18 let jsou vedoucí, kterých je v současné době kolem 16. Patří mezi ně jak hlavní vedoucí, tak zdravotník, kuchařky, technik, oddíloví vedoucí. Doba pobytu na táboře je 14 dnů, během dopoledne probíhají tréninky a kratší dopolední programy, odpoledne jsou věnována náročnějším hrám zejména v lese, které jsou obvykle součástí celotáborové hry. V průběhu celého tábora vzniká fotografická dokumentace, která je po táboře dis-
20
KAPITOLA 3. ÚVODNÍ STUDIE
tribuována mezi děti na CD či DVD nosičích. Asi před rokem se jeden z vedoucích rozhodl, že vytvoří a zprovozní internetové stránky tábora. Využil k tomu v té době poměrně nový systém eStránky.cz1 . Tato služba umožňuje vytvářet www stránky i běžným uživatelům internetu, kteří nemají zkušenosti s programováním. Služba eStránky.cz nám umožnila publikování informací o táboře na internetu. Jde jak o obecné informace o táboře a jeho okolí, o historii tábora, kontakty na vedoucí, popis celotáborové hry, tak lze vytvořit i jednoduchá diskusní fóra a zveřejnit fotografie ve fotogalerii. Vkládání fotografií do galerií je hojně využíváno zejména v období po táboře. Správci stránek je zprostředkováno buď pomocí webového formuláře nebo díky FTP přístupu. Rodiče si ze stránek mohou též stáhnout elektronickou přihlášku, kterou si vytisknou a vyplní. Její odevzdání probíhá standardní cestou, tj. výše popsaným způsobem. Jednotlivé stránky, diskuse i fotogalerie lze zaheslovat, tzn. že jsou přístupné jen s použitím jednotného hesla. To je využíváno pro přístup do sekce pro vedoucí, kteří mají všichni stejné heslo. Kromě samotného letního tábora je pro děti organizováno i několik akcí během školního roku, pro instruktory a vedoucí probíhají akce přibližně jednou měsíčně. Současný systém neumožňuje efektivní zveřejňování chystaných akcí pro děti či vedoucí. Informace o akcích jsou publikovány v rámci jedné stránky, kterou administrátor ručně upravuje. S rostoucí komunikací přes internet v rámci našeho táborového společenství vznikají také nové požadavky na funkčnost táborových internetových stránek. Jak již bylo dříve řečeno, nejsou eStránky tyto nové funkčnosti schopny realizovat. Je potřeba zavést možnost přihlašování uživatelů do systému tak, aby se zobrazoval obsah jim „šitý na míru” - např. aby se diskuse pro vedoucí nezobrazovala dětem. Pro zvýšení bezpečnosti by každý registrovaný měl mít své přihlašovací jméno a heslo, stejně tak mu má být zpřístupněna editace osobních údajů zanesených do systému. Každému registrovanému uživateli z řad vedoucích bude umožněno vytvářet fotogalerie a vkládat do nich fotografie. Musí být možné omezit zpřístupnění vytvořené galerie jen určité skupině uživatelů, např. vedoucím. Vedle zavedení on-line přihlašování dětí na tábor je třeba podporovat i vkládání dat do systému za děti přihlášené klasickou „papírovou” cestou. Z údajů o přihlášených dětech na tábor musí být možné generovat reporty jako např. kontaktní údaje na rodiče, ještě nezaplacené poplatky atd. Vedení tábora by pomohlo i sledování historie účastníků tábora, tj. zda už byli na některém z předchozích táborů. Při organizaci mimotáborových akcí během roku usnadní život kalendář akcí, kde budou všechny informace o dané akci včetně možnosti přihlášení na ni.
1
Systém je podrobně popsán v úvodní kapitole mé diplomové práce.
KAPITOLA 3. ÚVODNÍ STUDIE
3.3
21
Katalog požadavků
3.3.1
Uživatelské role
V novém systému bude podporováno několik druhů uživatelských rolí. Silnější uživatelská role přejímá všechna práva role slabší (pokud není výslovně uvedeno, že mu některá funkce slabší role není zpřístupněna) a zároveň má i práva vyjmenovaná níže u každé role. Hierarchie uživatelů je následující (od nejslabšího po nejsilnějšího): • neregistrovaný (určeno návštěvníkům stránek, kteří se nezaregistrují, resp. se neautorizují do systému) • dítě • instruktor • rodič / bývalý účastník tábora • vedoucí • správce stránek • administrátor 3.3.2 3.3.2.1
Funkce systému Neregistrovaný uživatel
Obecně má přístup ke všemu, co je určeno široké veřejnosti. Může přistupovat k obsahu, ke kterému není nutné přihlášení do systému. Obsah, pro který je přihlášení potřeba, je mu automaticky odfiltrován (obsah je obecně odfiltrováván na základě aktuální role - vedoucí tedy vidí obsah určený jak roli vedoucí, tak i rolím podřízeným). Jsou mu přístupné následující funkce: • prohlížení stránek s informacemi o táboře • prohlížení fotografií ve fotogaleriích • prohlížení novinek • prohlížení kalendáře akcí pro děti (akce pro vedoucí jsou odfiltrovány) • registrace do systému pro uživatele, kteří chtějí mít jednu z rolí: rodič, instruktor, vedoucí.
22
KAPITOLA 3. ÚVODNÍ STUDIE
3.3.2.2
Dítě
Obecně má přístup ke všemu, co je určeno široké veřejnosti a dětem. Po přihlášení může přistupovat k obsahu, ke kterému není nutná autorizace do systému, resp. který je určen dětem. Obsah, který mu není určen je automaticky odfiltrován. Vedle výše uvedených funkcí je mu přístupné: • přihlášení do systému (lze, pokud bylo zaregistrováno rodičem - viz. 3.3.2.4. Každé dítě tak musí mít přiřazeného rodiče, který je v systému též zaregistrován.) • odhlášení ze systému • změna hesla • prohlížení a editace vybraných osobních údajů • prohlížení diskusního fóra a vkládání nových příspěvků • vkládání příspěvků do diskusního fóra • zobrazování základních kontaktů na ostatní děti (icq, skype, e-mail) 3.3.2.3
Instruktor
Obecně má přístup ke všemu, co je určeno široké veřejnosti a dětem. Po přihlášení může přistupovat k obsahu, ke kterému není nutná autorizace do systému, resp. který je určen dětem. Obsah, pro který mu není určen je automaticky odfiltrován. Od role dítěte a rodiče se role liší v následujících funkcích: • nejsou mu přístupné funkce, které souvisí s registrací, přihlašováním na akce a editací údajů svých potomků, jež jsou uvedeny v popisu role rodiče - viz. 3.3.2.4. • přihlašování sebe na jednotlivé akce a na tábor • v kalendáři akcí mu jsou zobrazeny i akce určené pro vedoucí • zobrazování kontaktů na ostatní instruktory a vedoucí 3.3.2.4
Rodič / bývalý účastník tábora
Obecně má přístup ke všemu, co je určeno široké veřejnosti a dětem. Po přihlášení může přistupovat k obsahu, ke kterému není nutná autorizace do systému, resp. který je určen dětem. Obsah, který mu není určen je automaticky odfiltrován. Od role dítěte se role rodiče líší v následujících funkcích: • registrace svého potomka do systému v roli dítěte (zajistí se tím, že rodiče budou mít přehled, kam se potomek registruje.) • přihlašování svého dítěte na jednotlivé akce a na tábor
KAPITOLA 3. ÚVODNÍ STUDIE
23
• změna údajů včetně hesla u svého potomka • není mu přístupná funkce zobrazování základních kontaktů na ostatní děti (icq, skype, e-mail) 3.3.2.5
Vedoucí
Obecně má po přihlášení přístup ke všemu, co je v systému implementováno. Nepřístupné mu zůstávají jen funkce určené k administraci pro správce a administrátora systému. Krom výše uvedených mu jsou přístupné funkce: • vyváření fotogalerie a vkládání fotografií • vkládání nových akcí do kalendáře akcí • zobrazování reportů o přihlášených dětech na jednotlivé akce - nejsou zobrazeny citlivé údaje jako je např. telefonní číslo 3.3.2.6
Správce stránek
Obecně má po přihlášení přístup ke všemu, co je v systému implementováno. Nepřístupná mu je jen funkce vytváření nového správce stránek. Správce stránek má všechny nástroje, které jsou potřeba k vytvoření obsahu internetových stránek tábora - od tvorby článku, jeho zařazení do správné kategorie až po tvorbu menu. Vedle funkcí zděděných po „slabších” rolích je mu přístupné: • editace diskusních příspěvků • mazání fotografií i celých galerií • editace plánovaných akcí v kalendáři • vytváření, editace a mazání stránek s obsahem • vytváření a rušení diskusních fór • vyváření, editace a mazání rubrik, do nichž se zařazují jednotlivé stránky • vyváření, editace a mazání položek menu, které se zobrazuje uživatelům • zobrazování reportů o přihlášených dětech na jednotlivé akce - jsou zobrazeny i citlivé údaje jako je např. telefonní číslo 3.3.2.7
Administrátor
Má stejná práva jako správce stránek. Navíc může: • přiřadit již registrovanému uživateli roli správce stránek • odebrat uživateli roli správce stránek
24 3.3.3
KAPITOLA 3. ÚVODNÍ STUDIE Nefunkční požadavky
Systém bude implementován jako webová aplikace a bude umístěn na webhostingovém serveru. Přístupný tedy bude ze všech počítačů připojených k internetu vybavených internetovým prohlížečem.
3.4
Návrh architektury
Komunikace uživatele s informačním systémem pro dětský tábor bude probíhat přes www rozhraní libovolného internetového prohlížeče, který vyhovuje požadavkům uvedených v 3.4.1. Celý systém bude koncipován jako webová aplikace umístěná na webhostingovém serveru. Aplikační část bude zajištěna skriptovacím jazykem PHP, data budou ukládány v SQL databázi. Server musí splňovat podmínky z podkapitoly 3.4.3.
Obrázek 3.1: Diagram nasazení.
KAPITOLA 3. ÚVODNÍ STUDIE 3.4.1
25
Požadavky na softwarové vybavení klientů
Prohlížeč www stránek, který podporuje: • kaskádovací styly - v současné době se s prohlížeči bez podpory CSS prakticky nesetkáváme • skriptovací jazyk JavaScript - ten není podmínkou, ale jeho zapnutí je doporučeno 3.4.2
Požadavky na hardwarové vybavení klientů
• jakýkoli počítač schopný provozovat internetový prohlížeč • přístup k internetu 3.4.3
Požadavky na webový server
• softwarový webový server Apache • podpora PHP 5 • podpora MySQL alespoň verze 4.1 • dostatečná kapacita diskového prostoru; zpočátku alespoň několik set MB, později až několika GB • nepřetržitý provoz
3.5
Harmonogram projektu Harmonogram projektu si můžeme prohlédnout na obrázku 3.2.
3.6
Use Case nejvyšší úrovně
Případy užití2 zachycují funkčnost, která bude budoucím informačním systémem pokryta, a vymezují tak jednoznačně rozsah prací. Jsou psány z pohledu zákazníka a podávají první představu o rozsahu projektu. V této fázi analýzy se ještě nezabýváme technologickými aspekty řešení. Používáme pouze pojmy přirozeného jazyka, abychom co nejvěrněji a pro zákazníka co nejsrozumitelněji představili kostru systému. Use Case diagram rozlišuje aktéry, kteří komunikují se systémem. Use Case nejvyšší úrovně je na obrázku 3.3, kde jsou role seřazeny od shora dolů se vzrůstajícími právy. Vysvětlení k diagramu užití 3.3. 2
Často používaný je též anglický termín Use Case.
26
KAPITOLA 3. ÚVODNÍ STUDIE
Obrázek 3.2: Harmonogram projektu.
KAPITOLA 3. ÚVODNÍ STUDIE
Obrázek 3.3: Use nejvyšší úrovně.
27
28
KAPITOLA 3. ÚVODNÍ STUDIE • Zobrazení požadovaného obsahu je automaticky přizpůsobeno tomu, ve které roli je uživatel přihlášen do systému. Např. akce v kalendáři akcí zobrazené dětem jsou zobrazeny i vedoucím, těm jsou navíc zobrazeny i akce určené pro vedoucí (ty dětem zůstanou skryty, protože k jejich zobrazení nemají práva). • Silnější role dědí zobrazení od slabší + zobrazuje obsah určený pro svou roli. Jen v případě, kdy tomu tak není, je to explicitně v diagramu zachyceno.
3.7 3.7.1
Analýza rizik Rizika procesní a implementační
• Chyby v analýze – Analýza nebyla správně provedena, objevily se v ní závažné nedostatky. • Odklon od požadavků - Výsledný produkt se rozchází s požadavky zákazníka. • Chyby v řízení projektu – Projekt není správně řízen, řízení je komplikované nebo zcela chybí. • Nízký odhad rozsahu projektu – Kvůli nedostatečným zkušenostem v plánování projektů. • Nedostatky v dokumentaci produktu - Produkt není během vývoje dostatečně dokumentován. • Nedostatečné testování - Nedostatky dílčích testů se projevují při testování rozsáhlejších celků.
3.7.2
Rizika personální
• Nedostatečná kvalifikace pracovníků - Pracovníci nemají pokročilé znalosti potřebných technologií • Nedostatek zkušeností - Chybí zkušenosti s prací na podobných projektech, s danou technologií, s projektem dané velikosti atp. • Nedorozumění, špatná komunikace mezi členy týmu - Nedochází ke komunikaci mezi jednotlivým částmi týmu, pracovníci neinformují ostatní členy, na čem pracují, s jakými problémy se setkávají atd. • Fluktuace pracovníků - Nedostatečné odměňování, špatné pracovní prostředí, lepší pracovní nabídky vedou k odchodu od rozdělaného projektu.
KAPITOLA 3. ÚVODNÍ STUDIE 3.7.3
29
Rizika obchodní
• Změna rozsahu požadavků na projekt - Dojde k organizačním změnám u zákazníka, potřebuje produkt využít jiným způsobem (např. potřebuje přidat některé funkčnosti). • Změna požadavků ze strany zákazníka - Např. v důsledku změny legislativy je nutné změnit chování některých funkčností. • Nedostatečné zaškolení koncových uživatelů - Dodavatel neprovede zaškolení personálu, resp. jej podcení, což vede k malé efektivnosti využití systému a k jeho špatnému přijetí zaměstnanci objednavatele. • Špatná orientace uživatelů v systému - Způsobená nevhodným uživatelským rozhraním, přílišnou složitostí dialogů apod. • Pozdní dodání - Špatné plánování termínů, malá motivace, pomalí pracovníci. • Systém se nebude používat - Zásadní změny v organizaci zadavatele mohou vést k tomu, že se výsledný systém ukáže jako nepotřebný. • Nedostatek financí v průběhu projektu – Nedostatek vlastního kapitálu či půjček od bank nebo jiných investorů. • Finanční podhodnocení - Stanovení nízké výsledné ceny s následkem (vysokého) prodělku a možného předčasného ukončení. 3.7.4
Rizika technologická
• Nedostatečné nástroje pro vývoj - Nejsou zajištěny potřebné nástroje pro vývoj aplikace v nadefinovaném prostředí. • Nedostupná nápověda pro používané nástroje - Jsou k dispozici nástroje bez dostatečné dokumentace, což vede ke zpomalení vývoje při jejich používání. • Problémy s konfigurací HW a SW - Nedaří se nakonfigurovat používaný software dle potřeb. Možná kolize konfigurace SW (ale i hardware) na vývojových počítačích a na stanicích, kde má být výsledný produkt umístěn. • Nekompatibilita verzí – Verze použitého SW nebo HW nejsou kompatibilní. • Nedostupnost internetu - Aplikace je umístěna na server, který má problémy s připojením do internetu. 3.7.5
Rizika bezpečnostní
• Chyby v softwaru - Chyby způsobené programátory kvůli nedůslednosti či neznalostí.
30
KAPITOLA 3. ÚVODNÍ STUDIE • Proniknutí nepovolané osoby do výsledného systému - Špatná autentizace, neověřování vstupů zadaných od uživatele může vést k zpřístupnění částí systému uživateli, který k tomu nemá oprávnění. Toto dokonce může vést k úplnému ovládnutí systému útočníkem. Dále může být způsobeno použitím nevhodného systému k zabezpečení, neaplikováním kritických updatů. • Vada nebo chyba HW/SW při vývoji - Může vést ke ztrátě vytvořených částí produktu. • Zcizení vyvíjeného systému - Kvůli nedostatečné kontrole přístupu k hardwaru nebo softwaru, který se podílí na vývoji.
3.7.6
Analýza rizik vyvíjeného informačního systému
Přehled rizik, která vidím v projektu vyvíjeného informačního systému pro dětský tábor je v tabulce 3.1. Sloupec P znamená pravděpodobnost výskytu daného problému. Hodnocení závažnosti rizika se provádí pomocí kategorií dopadu - sloupec D. Dopad může být: • 1 – zanedbatelný • 2 – marginální • 3 – kritický • 4 – katastrofický Riziko
Kategorie
P D Návrh řešení [%]
Nedostatečná kvalifikace pracovníků Nedostatek zkušeností Problémy s konfigurací HW a SW Nedostatečné zaškolení koncových uživatelů Chyby v softwaru
Personální
65
4
Personální
60
3
Technologická 50
3
Obchodní
50
2
Bezpečnostní
50
3
40
3
Nedostatečné tes- Procesní tování
Řešitel problému Poctivé studium dané pro- řešitel blematiky, konzultace. Poradit se s kolegy, kteří tyto zkušenosti mají. Studium manuálů, odborných fór na internetu. Jednoduchost a přehlednost ovládání. Dostupnost nápovědy. Provádět testování, dát budoucím uživatelům zkušební verzi produktu k otestování. Navrhnout vhodné testy, průběžné testování.
řešitel řešitel řešitel
řešitel
řešitel
31
KAPITOLA 3. ÚVODNÍ STUDIE Riziko
Kategorie
Nízký odhad roz- Procesní sahu projektu
P D Návrh řešení [%] 40
3
Řešitel problému
Zintenzivnění práce. Pod- řešitel, niknout kroky pro odklad zadavatel, diplomové práce.
vedoucí práce
Nedostatečné ná- Technologická 40 stroje pro vývoj
2
Chyby v analýze
40
3
Změna požadavků Obchodní ze strany zákazníka Nedostatky v Procesní dokumentaci produktu Pozdní dodání Obchodní
35
3
30
2
30
2
Vada nebo chyba Bezpečnostní HW/SW při vývoji Systém se nebude Obchodní používat
20
4
20
3
Změna rozsahu Obchodní požadavků na projekt Odklon od poža- Procesní davků
15
3
10
4
Nedostupnost in- Technologická 10 ternetu
4
Procesní
Tabulka 3.1: Tabulka rizik
Včas nainstalovat a řešitel vyzkoušet potřebné produkty, hledat případné alternativy. Konzultace analýzy se zá- řešitel, kazníkem. zadavatel Průběžné konzultace se zá- řešitel, kazníkem, dobrá komuni- zadakace. vatel Povinná dokumentace jed- řešitel notlivých částí systému. Dostatečná motivace, kon- řešitel trola milníků projektu, rezervy v plánu. Časté zálohování na něko- řešitel lik různých medií. Ukázat výhody oproti současnému stavu. Zaškolit uživatele. Konzultovat se zadavatelem situaci v jeho organizaci. Průběžná konzultace nad hotovými částmi, odsouhlasení zákazníkem. Umístit výsledný produkt na server kvalitního provozovatele, zjistit si reference na něj. vyvíjeného projektu
řešitel, zadavatel řešitel, zadavatel řešitel, zadavatel řešitel, zadavatel
Jako riziko, které se může vyskytnout s největší pravděpodobností, jsem ohodnotil riziko mé malé znalosti programovacích jazyků používaných ve vývoji aplikací pro internet. Dosud jsem vytvářel jen několik statických webových stránek, znalosti PHP mám jen na nejzákladnější úrovni. Ze školy znám databázový systém Oracle, proto předpokládám,
32
KAPITOLA 3. ÚVODNÍ STUDIE
že s databází MySQL bych neměl mít nějaké zásadní potíže. O to více se budu muset věnovat studiu jazyka PHP, k čemuž využiji vedle učebnic i bohatých internetových serverů věnujících se této problematice. Nedostatečná znalost PHP a případně dalších technologií může mít na projekt fatální dopad v podobě jeho neúspěšného dokončení. Vedle znalostí samotných technologií jsou při práci na projektu důležité i zkušenosti s podobnou prací. Jak vyplývá z výše uvedeného, ty zatím bohužel nemám. Očekávám, že to může mít velký vliv na výsledek mé práce, zejména pak při volbě jednotlivých postupů řešení dílčích úkolů - nebudu využívat optimální techniky, které vedou rychleji k lepšímu cíli atp. Nezkušenost hodlám nahradit zvýšeným úsilím při studiu, chci se inspirovat na stránkách, které radí, jak postupovat při tvorbě webových aplikací. Nastavení serveru Apache, PHP a MySQL na domácím PC není dle reakcí na internetových diskuzních fórech zcela triviální záležitost, a tak očekávám, že i já s tím mohu mít jisté problémy. Další problémy nastávají při exportu aplikace z vývojové stanice na cílový server kvůli rozdílnému nastavení serverů. Abych riziko, že taková situace nastane, minimalizoval, věnuji dostatečný čas studiu konfigurace a jejímu sesynchronizování s cílovým serverem. Aby mohli uživatelé efektivně systém využívat, pokusím se o zvolení samovysvětlujících názvů pro použité navigační prvky. Vytvořím i uživatelskou příručku, která bude jednotlivé funkčnosti popisovat. Podle mé osobní znalosti budoucích uživatelů mám ale obavy, že jí nebudou věnovat moc pozornosti. Chybám se nevyhne žádný softwarový produkt, a proto je nutné jej dostatečně otestovat. Dopady na projekt nemusí být zásadní, každá chyba se dá odstranit. Cenou za časté odstraňování chyb může být ale časové zdržení. Nedostatkem času na testování se pravděpodobnost výskytu chyb zvětšuje. Časová zdržení lze omezit dostatečnými rezervami v plánu. Již zmíněná nezkušenost s obdobnými projekty může v mém případě vést k podcenění rozsahu projektu. S tím souvisí i podcenění časové náročnosti prací. Abych toto riziko zmírnil, prostuduji, resp. budu konzultovat časový harmonogram prací s programátory, kteří již pracovali na projektu s obdobnou funkčností. Server Apache, PHP i MySQL jsou vytvářeny na bázi open-source technologií, takže s jejich dostupností není problém. Problémem může zpočátku být zvolení si vhodného editoru, který bude při psaní kódu použit. PHP skripty lze samozřejmě psát i v obyčejném Poznámkovém bloku, ale bylo by to víc než nepohodlné. Nebylo by ani možné využít různých ulehčení, která specializované editory poskytují. Volba editoru má vliv na efektivnost samotného programování. To že se s prací na projektu doberu k cíli, ale jen ulehčuje. Analýza je základem úspěchu k tomu, aby byl zákazník s dodaným systémem spokojený. Při nedostatečné analýze může dojít k tomu, že systém sice bude dodán, ale s jinou funkčností než požadoval zákazník. Jelikož osobně znám prostředí dětského tábora, pro který je systém vyvíjen, myslím si, že je málo pravděpodobné, že bych mohl požadavky zákazníka pochopit zcela odlišným způsobem než jsou míněny. Mou nevýhodou je, že větší analýzu pro skutečný projekt jsem osobně ještě neprováděl, a tak nelze vyloučit případné chyby ani nějaká opomenutí.
KAPITOLA 3. ÚVODNÍ STUDIE
33
Aby nedošlo ke ztrátě kódu3 rozpracovaného systému vlivem havárie vývojové stanice, budu data poctivě zálohovat - nejlépe několika způsoby jakými jsou uložení na DVD či FTP server. Ztráta dat by měla fatální důsledky, které by se projevily zejména pozdním dodáním systému. Ten by se musel vyvíjet od začátku. Pravděpodobnost ztráty dat hodnotím s ohledem na plánovaná provedená opatření jako velmi nízkou. Požadavky na systém budou zaneseny do jednotlivých Use Casů. Při programování jednotlivých funkčností se budu popisem případů užití řídit, aby nedošlo k dodání jiných funkčností, než byly se zákazníkem domluveny. To by ho jistě nepotěšilo a mělo by to tak zásadní vliv na možnost dodání vyvíjeného systému. Dostupnost systému bude zajištěna umístěním na server provozovatele webhostingu, s nimž mají moji kamarádi věnující se webové tvorbě dobré zkušenosti. Pokud je sebelepší systém umístěn na často nedostupných serverech, je jeho použití omezené, někdy až zcela nepoužitelné.
3
Pochopitelně je třeba zálohovat i provedenou analýzu a dokumentaci.
34
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
4 Analýza a návrh řešení 4.1
Popis případů užití
V této části podrobně rozeberu průběh jednotlivých případů užití včetně uvedení omezujících podmínek a dalších důležitých informací. Nejprve vysvětlím některé termíny, které budu dále používat: • stránka - má dvojí význam. Obecný, kdy se hovoří o internetové stránce jako celku - obsahuje menu a samotný obsah. Konkrétní význam slova stránka v mé analýze je následovný: stránka se skládá z nadpisu, může obsahovat i krátký popis. Stránka dále obsahuje jednotlivé prvky stránky jako jsou články, diskusní fóra, fotogalerie, novinky a plánované akce. • menu a položka menu - menu slouží k navigaci ve výsledných internetových stránkách. Pod jednotlivými položkami menu se ukrývají odkazy na jednotlivé stránky. Po vybrání položky menu je uživateli zobrazena odkazovaná stránka. • uživatel systému - je jakýkoli uživatel táborového informačního systému, bez ohledu na jemu přiřazenou roli (tedy i neregistrovaný nebo nepřihlášený uživatel). Může být v systému přihlášen pod svou uživatelskou rolí. • uživatel přihlášený „pod rolí” - každý uživatel, který se nezaregistruje do táborového informačního systému, v něm vystupuje s přidělenou rolí „neregistrovaný”. Pod stejnou rolí v systému vystupují i zaregistrovaní uživatelé, kteří se při používání systému do něj zatím nepřihlásili (nezalogovali se). Systém může přizpůsobovat zobrazení stránek uživateli dle jeho role, pod kterou je přihlášen. • Přihlásí-li se uživatel do systému svým uživatelským jménem a heslem, vystupuje v roli, kterou má registrovánu. Silnější uživatelská role má zpřístupněny všechny případy užití, které jsou přístupny slabší roli, pokud není výslovně uvedeno jinak. Hierarchie rolí je uvedena v kapitole 3.3.1. • uživatel vybere položku - uživatel si zvolí položku, najede na ni myší a provede dvojklik myší, čímž dá příkaz k přesunu na jinou webovou stránku. • přihlášená akce - je každá akce, na kterou se uživatel v systému přihlásil. Následně však mohl stav této přihlášené akce změnit. Každá uživatelem přihlášená akce tedy má jeden ze stavů „Přihlášen” či „Nepřihlášen”, pro některé aktéry je přístupný i stav „Nerozhodnut”. • diskusní téma a příspěvek - diskusní téma obsahuje soubor diskusních příspěvků.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.1.1
35
Spuštění systému
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel zná internetovou adresu, na níž je systém „umístěn”. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.1. Krok 1 2 3
Role
Akce Uživatel Zadá internetovou adresu do prohlížeče webových stránek. Systém Zobrazí úvodní stránku webové prezentace tábora. Systém Zároveň zobrazí i menu s odkazy na dostupné stránky určené pro všechny uživatele. Tabulka 4.1: Use Case Spuštění systému
Alternativní scénář případu užití: krok 2 - Pokud není v systému uložena úvodní stránka, je zobrazena stránka s prázdným obsahem (grafické prvky stránky jsou také zobrazeny). krok 3 - Pokud není v systému uložen obsah menu, není menu zobrazeno. 4.1.2
Zobrazení stránek o táboře
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel se nachází na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.2. Krok Role 1 Uživatel 2 Systém 3
Akce Z menu vybere stránku, kterou chce zobrazit. Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Na základě vybrané položky v menu zobrazí stránku s odpovídajícím obsahem, přičemž odfiltruje obsah, který není určen pro danou roli. Tabulka 4.2: Use Case Zobrazení stránek o táboře
36
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 1 - Pokud není v systému uložen obsah menu, nemůže uživatel kliknout na jeho položky. V tom případě uživatel nemůže změnit zobrazenou stránku, systém tak nic neprovádí a scénář je předčasně ukončen. krok 3 - Pokud byl odfiltrován veškerý obsah, je zobrazena stránka s prázdným obsahem (grafické prvky stránky jsou také zobrazeny). Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.1.
Obrázek 4.1: Zobrazení stránek o táboře.
4.1.3
Prohlížení novinek
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel se nachází na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.3. Krok Role 1 Uživatel
Akce Vybere v menu položku, pod kterou se nachází odkaz na stránku s novinkami. Typicky je taková položka menu pojmenovaná „Novinky”, avšak správce stránek jí může dát libovolné jméno.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
37
Krok Role 2 Systém
Akce Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Zobrazí stránku s obsahem všech novinek, přičemž odfiltruje obsah, který není určen pro danou roli. Tabulka 4.3: Use Case Prohlížení novinek
3
Alternativní scénář případu užití: krok 1 - Nenachází-li se v menu odkaz na stránku s novinkami, uživatel nemůže novinky zobrazit, systém nic neprovádí a scénář je předčasně ukončen. krok 3 - Pokud byly odfiltrovány všechny novinky, resp. nejsou-li v systému pro vybrané menu žádné uloženy, je zobrazena prázdná stránka, přičemž navigační prvky, jako je menu, jsou zachovány - v podstatě platí krok 3 alternativního scénáře z případu užití 4.1.2. 4.1.4
Zobrazení kalendáře akcí
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel se nachází na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.4. Krok Role 1 Uživatel
2
Systém
3
Systém
4
Systém
Akce Vybere v menu položku, pod kterou se nachází odkaz na stránku s plánovanými akcemi. Taková položka menu bývá pojmenovaná např. „Plánované akce” či „Kalendář akcí”, avšak správce stránek jí může dát libovolné jméno. Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Zobrazí stránku se přehledem plánovaných akcí, přičemž odfiltruje obsah, který není určen pro danou roli. Součástí zobrazení je i přehled akcí, na něž je uživatel, popř. jeho dítě, přihlášen - viz. případ užití 4.1.18. POKUD je uživatel přihlášen v roli „instruktora”, tak mu jsou zobrazeny i akce určené pro vedoucí. JINAK pokračuje v dalším kroku.
38
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role 5 Systém
Akce POKUD je uživatel přihlášen v roli „vedoucí”, „správce stránek”, „instruktor” nebo „administrátor” je zobrazen i ovládací prvek pro přihlášení uživatele1 na akci - to je využito v Use Case 4.1.17. POKUD má uživatel k sobě zaregistrované své „dítě”2 , je zobrazen i ovládací prvek pro přihlášení svého potomka na akci - to je využito v Use Case 4.1.16. JINAK
uživatel nemá možnost přihlášení, zobrazení má informativní charakter a systém už nic neprovádí. Tabulka 4.4: Use Case Zobrazení kalendáře akcí
Alternativní scénář případu užití: krok 1 - Nenachází-li se v menu odkaz na stránku s kalendářem akcí, uživatel nemůže akce zobrazit, systém nic neprovádí a scénář je předčasně ukončen. krok 3 - Pokud byly odfiltrovány všechny akce, resp. nejsou-li v systému pro vybrané menu žádné uloženy, je zobrazen prázdný obsah, platí krok 3 alternativního scénáře z případu užití 4.1.2. Následně je scénář předčasně ukončen. Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.2.
Obrázek 4.2: Kalendář akcí - tlačítka pro přihlášení.
1 2
myšleno přihlášení sebe sama na akci to je možné jen pro některé role - viz. Use Case 4.1.14
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.1.5
39
Prohlížení fotografií
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel se nachází na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.5. Krok Role 1 Uživatel 2 3 4 5 6
7
Akce Vybere v menu položku, pod kterou se nachází odkaz na stránku s fotogaleriemi. Taková položka může mít libovolné jméno určené správcem stránek. Systém Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Zobrazí seznam fotogalerií, přičemž odfiltruje obsah, který není určen pro danou roli. Uživatel Vybere fotogalerii, ze které si chce prohlédnout fotografie. Systém Zobrazí náhledy fotografií z vybrané galerie. Uživatel POKUD chce uživatel zobrazit fotografii ve větší velikosti, klikne na náhled požadované fotky. JINAK uživatel si prohlíží náhledy a již další akci nepožaduje. Systém POKUD uživatel chtěl zobrazit fotku ve větší velikosti, systém zobrazí velkou fotografii. JINAK od systému není očekávána žádná reakce. Tabulka 4.5: Use Case Prohlížení fotografií
Alternativní scénář případu užití: krok 3 - Jsou-li všechny fotogalerie odfiltrovány, resp. není-li v systému pro vybrané menu uložena žádná fotogalerie, je zobrazen prázdný obsah, platí krok 3 alternativního scénáře případu užití 4.1.2 a scénář je ukončen. krok 5 - Pokud vybraná fotogalerie neobsahuje žádné obrázky, je zobrazen prázdný obsah, platí alternativní scénář z případu užití 4.1.2 a scénář je ukončen. krok 7 - Chybí-li k některé fotografii náhled, je v náhledovém okénku zobrazen prázdný obrázek. Pokud není fotografie ve velkém formátu dostupná, je při požadavku na její zobrazení zobrazen prázdný obsah, platí alternativní scénář z případu užití 4.1.2.
40
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.3.
Obrázek 4.3: Prohlížení fotografií - základní informace o galerii s tlačítkem pro zobrazení náhledů fotek.
4.1.6
Registrace do systému
Aktéři: uživatel systému Omezení na stav systému před spuštěním případu užití: Uživatel se nachází na stránkách tábora a chce zaregistrovat jednu z následujících rolí: „rodič / bývalý účastník”, „instruktor”, „vedoucí”. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.6. Krok 1 2 3 4
Role
Akce Uživatel Klikne na ikonku Registrace. Systém Zobrazí stránku s registračním formulářem. Uživatel Vyplní všechna povinná pole formuláře. Součástí je i zvolení role, kterou chce uživatel registrovat. Nakonec stiskne tlačítko „Registrace do systému”. Systém Uloží všechny zadané informace do databáze. Zároveň vygeneruje požadavek na správce stránek, ve kterém má správce schválit zaregistrování nového uživatele - viz. případ užití 4.1.23. Tabulka 4.6: Use Case Registrace do systému
Omezení na stav systému po ukončení případu užití: Uživatel je ve stavu schvalování registrace. Výstupem je v systému zaregistrovaný požadavek na schválení registrace. (Teprve až po schválení registrace (viz. případ užití 4.1.23) je jeho uživatelský účet plně aktivován, tedy je registrován do systému a může jej využívat v rozsahu definovaném pro jeho roli).
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
41
Alternativní scénář případu užití: krok 4 - Uživatel nevyplní všechny povinné položky, systém ho na to upozorní a vrátí ho do stavu zobrazení registračního formuláře - tj. pokračuje znovu od kroku 2. Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.4.
Obrázek 4.4: Registrační formulář.
4.1.7
Přihlášení do systému
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.7. Krok Role 1 Uživatel 2
Akce Vyplní pole určené pro zadání uživatelského jména svým uživatelským jménem. Pole určené pro heslo vyplní platným heslem ke svému účtu. Systém Ověří platnost uživatelského jména a hesla a přihlásí uživatele do systému. Tabulka 4.7: Use Case Přihlášení do systému
42
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Omezení na stav systému po ukončení případu užití: Uživatel se nachází na stránkách tábora, je v systému zaregistrován a zná své uživatelské jméno a heslo. Zároveň zatím není ze stejného terminálu v systému přihlášen on ani žádný jiný uživatel3 . Alternativní scénář případu užití: Pokud uživatel zadal špatnou kombinaci jména a hesla, systém mu zobrazí stránku s informací o špatně zadaném uživatelském jménu nebo heslu. Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.5.
Obrázek 4.5: Přihlášení do systému.
4.1.8
Odhlášení ze systému
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.8. Krok Role Akce 1 Uživatel Klikne na tlačítko „Odhlásit”. 2 Systém Odhlásí uživatele ze systému. Tabulka 4.8: Use Case Odhlášení ze systému
Omezení na stav systému po ukončení případu užití: Uživatel je odhlášen ze systému, který s ním dále pracuje jako s „neregistrovaným” uživatelem. Pokud je přihlášen jiný uživatel, je nutné jej napřed odhlásit (viz. Use Case 4.1.8) a pak teprve pokračovat v přihlašování. 3
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
43
Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.6.
Obrázek 4.6: Odhlášení ze systému.
4.1.9
Změna hesla
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.9. Krok Role 1 Uživatel 2 Systém
3 4
Uživatel Systém
5
Uživatel
6
Systém
Akce Zvolí položku „Změnit osobní údaje”. Zobrazí stránku se souhrnem informací o uživateli, kde je zároveň uveden i odkaz na změnu osobních údajů a odkaz na změnu hesla. Je zde i odkaz pro registraci svého dítěte do systému, resp. pro editaci jeho údajů. Zvolí odkaz na změnu hesla. Zobrazí stránku s třemi políčky formuláře. První určený pro stávající heslo. Druhé a třetí políčko je určené pro zadání nového hesla a pro jeho ověření. Zadá stávající heslo a nové heslo, které zadá ještě jednou do ověřovacího pole. Stiskne tlačítko „Změnit heslo”. Ověří správnost původního hesla a shodnost nového hesla. Uloží nové heslo v databázi. Tabulka 4.9: Use Case Změna hesla
Alternativní scénář případu užití: krok 6 - Pokud je původní heslo zadáno špatně nebo není nově zadané heslo shodné s políčkem určeným pro ověření hesla (tj. není-li nové heslo vyplněno vůbec), zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 4.
44
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
4.1.10
Editace a prohlížení osobních údajů
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.10. Krok Role 1 Uživatel 2 Systém
Akce Zvolí položku „Změnit osobní údaje”. Zobrazí stránku se souhrnem informací o uživateli, kde je zároveň uveden i odkaz na změnu osobních údajů a odkaz na změnu hesla. Je zde i odkaz pro registraci svého dítěte do systému, resp. pro editaci jeho údajů. Uživatel Zvolí odkaz na změnu osobních údajů. Systém Zobrazí stránku s formulářem, ve kterém jsou uvedeny údaje o uživateli uložené v systému. Všechny údaje mohou být uživatelem editovány. Uživatel Uživatel upraví údaje, které chce změnit. Pro potvrzení změn stiskne tlačítko „Uložit změny”. Systém Ověří správnost vyplnění údajů a uloží je v databázi. Tabulka 4.10: Use Case Editace a prohlížení osobních údajů
3 4 5 6
Alternativní scénář případu užití: krok 6 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 4. Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.7. 4.1.11
Zobrazení kontaktů ostatních registrovaných uživatelů
Aktéři: dítě, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.11.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
45
Obrázek 4.7: Editace a prohlížení osobních údajů. Krok Role 1 Uživatel
2 3
4
Akce Vybere v menu položku, pod kterou se nachází odkaz na stránku s kontakty na ostatní registrované uživatele. Taková položka může mít libovolné jméno určené správcem stránek, typycky to bývají „kontakty” apod. Systém Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Zobrazí kontakty na ostatní registrované uživatele stejné a slabší role kromě kontaktů na rodiče. Kontakty jsou uvedeny ve skupinách dle jednotlivých druhů rolí. V kontaktech na slabší role je zobrazeno méně údajů než v kontaktech na silnější role4 . Uživatel POKUD je uživatelská role správce stránek nebo administrátor, systém zobrazí i kontakty na uživatele registrované v roli rodiče. POKUD je uživatelská role instruktor, systém zobrazí i kontakty na vedoucí. JINAK nezobrazuje nic dalšího. Tabulka 4.11: Use Case Zobrazení kontaktů ostatních registrovaných uživatelů
Alternativní scénář případu užití: Pokud v systému nejsou zaregistrováni žádní uživatelé, zobrazí se stránka bez kontaktů jen se seznamem všech rolí, jejichž kontakty si daný uživatel může prohlédnout. Návrh uživatelského rozhraní: Je zobrazen na obrázku 4.8. Např. výpis kontaktů dětí obsahuje jen jméno, příjmení, e-mail, icq a skype. U vedoucích jsou uvedeny i další údaje jako je telefonní číslo. 4
46
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 4.8: Zobrazení kontaktů ostatních registrovaných uživatelů. 4.1.12
Diskusní fórum - prohlížení
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.12. Krok Role 1 Uživatel 2 3
4 5 6
Akce Vybere v menu položku, pod kterou se nachází odkaz na stránku s diskusemi. Taková položka může mít libovolné jméno určené správcem stránek. Systém Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Zobrazí seznam diskusních témat, přičemž odfiltruje obsah, který není určen pro danou roli. Uživatelům přihlášeným v roli „vedoucí”, „správce stránek” či „administrátor” jsou zobrazeny i diskuse určené pro role „instruktor”. Uživatel Vybere téma, které si chce prohlédnout. Systém Zobrazí obsah diskusních příspěvků v pořadí od nejnovějších. Systém Zároveň zobrazí i formulář pro vložení nového příspěvku jeho použití viz. Use Case 4.1.13. Tabulka 4.12: Use Case Diskusní fórum - prohlížení
Alternativní scénář případu užití: krok 3 - Pokud byla všechna diskusní fóra odfiltrována, resp. nejsou-li v systému pro vybrané menu žádná uložena, je zobrazen prázdný obsah, platí alternativní scénář z případu užití 4.1.2 a scénář je ukončen. krok 5 - Pokud vybraná diskuse neobsahuje žádné příspěvky, je zobrazen pouze formulář pro vložení nového příspěvku - viz. krok 6.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
47
Návrh uživatelského rozhraní: Přehled diskusních témat strukturou odpovídá obrázku 4.3. Prohlížení diskusních příspěvků je zobrazeno na obrázku 4.9. 4.1.13
Diskusní fórum - vkládání příspěvků
Aktéři: dítě, rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Prohlíží si příspěvky v některé z diskusí - viz. případ užití 4.1.12. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.13. Krok Role 1 Uživatel
2 3
4
5
Akce Na stránce najede do části se zobrazeným formulářem pro vložení nového příspěvku. Vyplní nadpis příspěvku a vloží jeho text. Při vkládání může využít některá formátovací tlačítka, která vkládaný text upraví speciálními znaky, které jsou využity pro formátování vstupních polí v programu Texy! (více v kapitole 2.8). Po dokončení vkládání stiskne tlačítko „Náhled”. Systém Zobrazí náhled vkládané zprávy s tlačítky „Upravit” a „Odeslat”. Uživatel POKUD je uživatel s obsahem i vzhledem svého příspěvku spokojen, stiskne pro uložení do systému tlačítko „Odeslat”. JINAK uživatel zvolí tlačítko „Upravit”. Systém POKUD uživatel zvolil tlačítko „Odeslat”, systém uloží nový příspěvek do databáze. JINAK uživatel je vrácen k editaci příspěvku a případ užití pokračuje znovu od kroku 1 s tím, že dříve vyplněné údaje a texty jsou zachovány pro opětovnou editaci. Systém Diskuse, do které byl vkládán příspěvek, je zobrazena dle případu užití 4.1.12. Tabulka 4.13: Use Case Diskusní fórum - vkládání příspěvků
48
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 2 - Když není vyplněno textové pole s příspěvkem, je zobrazena hláška „Textové pole je prázdné” a uživatel je vrácen do kroku 1. krok 3 - Nechce-li uživatel pokračovat ve vkládání příspěvku, nepoužije žádného z tlačítek „Upravit”, „Odeslat” a pokračuje v prohlížení diskuse a stránek běžným způsobem. Scénář je ukončen. Návrh uživatelského rozhraní: Vkládání příspěvku je zobrazeno na obrázku 4.9.
Obrázek 4.9: Diskusní fórum - prohlížení a vkládání příspěvku.
4.1.14
Registrace dítěte do systému
Aktéři: rodič, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Chce v systému zřídit svému dítěti uživatelský účet pro roli „dítě”. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.14.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
49
Krok Role 1 Uživatel 2 Systém
3 4 5
6 7 8 9 10
Akce Zvolí položku „Změnit osobní údaje”. Zobrazí stránku se souhrnem informací o uživateli, kde je zároveň uveden i odkaz na změnu osobních údajů a odkaz na změnu hesla. Je zde i odkaz pro registraci svého dítěte do systému, resp. pro editaci jeho údajů. Uživatel Zvolí odkaz pro registraci (editaci) svého dítěte do systému. Systém Zobrazí stránku, na které je tlačítko pro registraci dítěte do systému. Systém POKUD je k uživateli přiřazeno nějaké dítě, jsou zobrazeny i zaregistrované údaje tohoto dítěte (kromě hesla). Zároveň jsou zobrazena tlačítka „Změnit údaje dítěte” a „Registrace dítěte”. JINAK se pokračuje v dalším kroku. Uživatel Stiskne tlačítko „Registrace dítěte”. Systém Zobrazí stránku s formulářem. Formulář umožňuje vyplnění osobních údajů dítěte včetně jeho uživatelského jména a hesla. Uživatel Vyplní formulář a stiskne tlačítko „Zaregistrovat dítě”. Systém Ověří správnost vyplněných údajů a uloží je v databázi. Systém Vrátí se na stránku zobrazenou systémem v kroku 4 a 5. Zde je možné scénář ukončit nebo opětovně pokračovat v registraci dalšího dítěte, popř. lze změnit registrované údaje svého dítěte - viz. 4.1.15. Tabulka 4.14: Use Case Registrace dítěte do systému
Omezení na stav systému po ukončení případu užití: Do systému je zaregistrován nový uživatel s rolí „dítě”. Zde již neprobíhá schvalování registrace, a tak je uživatelský účet ihned aktivní a lze jej plně využívat v rámci přidělených práv. Alternativní scénář případu užití: krok 9 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 7. Návrh uživatelského rozhraní: Uživatelské rozhraní bude obdobné jako v Use Case 4.1.10 Editace a prohlížení osobních údajů - obrázek 4.7. Jen budou zobrazeny údaje o dítěti a budou zobrazena tlačítka „Změnit údaje dítěte” a „Registrace dítěte”.
50
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
4.1.15
Změna údajů dítěte
Aktéři: rodič, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Chce změnit uživatelské údaje nebo heslo svého potomka, který byl dříve rodičem do systému zaregistrován pod rolí „dítě”. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.15. Krok Role 1 Uživatel 2 Systém
3 4
5 6 7 8 9
Akce Zvolí položku „Změnit osobní údaje”. Zobrazí stránku se souhrnem informací o uživateli, kde je zároveň uveden i odkaz na změnu osobních údajů a odkaz na změnu hesla. Je zde i odkaz pro registraci svého dítěte do systému, resp. pro editaci jeho údajů. Uživatel Zvolí odkaz pro registraci (editaci) svého dítěte do systému. Systém Zobrazí stránku se zaregistrovanými údaji (kromě hesla) dítěte, které bylo daným uživatelem do systému registrováno. Zároveň jsou zobrazena i tlačítka „Změnit údaje dítěte” a „Registrace dítěte”. Uživatel Stiskne tlačítko „Změnit údaje dítěte”. Systém Zobrazí stránku s formulářem s předvyplněnými daty, jež jsou v systému uloženy. Formulář umožňuje úpravu osobních údajů dítěte včetně jeho uživatelského jména a hesla. Uživatel Po úpravě údajů stiskne tlačítko „Uložit změny”. Systém Ověří správnost vyplnění údajů a uloží je v databázi. Systém Vrátí se na stránku zobrazenou systémem v kroku 4. Zde je možné scénář ukončit nebo opětovně editovat údaje dítěte, popř. lze do systému registrovat nové dítě - viz. případ užití 4.1.14. Tabulka 4.15: Use Case Změna údajů dítěte
Alternativní scénář případu užití: krok 4 - Pokud si uživatel k sobě zatím nezaregistroval žádné dítě, nejsou logicky data dítěte zobrazeny. Není ani zobrazeno tlačítko „Změnit údaje dítěte”. Zůstává jen tlačítko „Zaregistrovat dítě”. Zde scénář končí. Pro registraci dítěte do systému odsud může uživatel pokračovat krokem 6 v Use Case 4.1.14. krok 8 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 6.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
51
Návrh uživatelského rozhraní: Uživatelské rozhraní bude obdobné jako při registraci do systému v Use Case 4.1.6 - viz. obrázek 4.4. Ve formuláři budou předvyplněny uložené hodnoty. 4.1.16
Přihlášení dítěte na tábor a další akce
Aktéři: rodič, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Prohlíží si kalendář akcí - viz. případ užití 4.1.4. Chce své dítě přihlásit na některou z dostupných akcí. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.16. Krok Role 1 Uživatel 2 Uživatel 3 4
5 6
Akce Rozhodne se, na jakou akci chce své dítě přihlásit. Klikne na tlačítko „Přihlásit dítě na akci” zobrazené u vybrané akce. Systém Zjistí obsazenost akce. V případě, že již není volná kapacita, je o tom uživatel informován a scénář se zde předčasně ukončí. Systém Zobrazí formulář pro vyplnění osobních údajů rodiče a dítěte, které potřebují organizátoři akce. V polích formuláře jsou předvyplněny údaje, které jsou v systému o uživateli uloženy5 . Pro přihlášení na vícedenní akci (typicky tábor) je požadováno vyplnění více údajů než na jednodenní akci. Uživatel Vyplní do formuláře všechny povinné údaje a dá pokyn k uložení informací do systému. Systém Ověří správnost vyplněných údajů a uloží je do databáze. Tabulka 4.16: Use Case Přihlášení dítěte na tábor a další akce
Omezení na stav systému po ukončení případu užití: Dítě patřící k danému uživateli je přihlášeno na akci. Alternativní scénář případu užití: krok 6 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, nejsou informace uloženy. Uživateli je zobrazena chybová hláška a je vrácen do kroku 4. Jedná se jednak o údaje uložené v osobním profilu rodiče a dítěte, a jednak o údaje z přihlášek z minulých akcí. 5
52
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Návrh uživatelského rozhraní: Přihlašovací formulář je zobrazen na obrázku 4.10.
Obrázek 4.10: Přihlášení dítěte na tábor a další akce. 4.1.17
Přihlášení na akci
Aktéři: instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Prohlíží si kalendář akcí - viz. případ užití 4.1.4. Chce se přihlásit na některou z dostupných akcí. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.17. Krok Role 1 Uživatel 2 Uživatel 3
Systém
4
Systém
Akce Rozhodne se, na jakou akci se chce přihlásit. Klikne na tlačítko „Přihlásit se na akci” zobrazené u vybrané akce. Zjistí obsazenost akce. V případě, že již není volná kapacita, je o tom uživatel informován a scénář se zde předčasně ukončí. Zobrazí formulář pro vyplnění osobních údajů. V polích formuláře jsou předvyplněny údaje, které jsou v systému o uživateli uloženy. Součástí je volba, zda se uživatel hlásí na akce určitě zúčastní, zda ještě neví nebo zda se jí určitě nezúčastní.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
53
Krok Role 5 Uživatel
Akce Vyplní do formuláře všechny povinné údaje a dá pokyn k uložení informací do systému stiskem tlačítka „Přihlásit na akci”. Systém Ověří správnost vyplněných údajů a uloží je do databáze. Tabulka 4.17: Use Case Přihlášení na akci
6
Omezení na stav systému po ukončení případu užití: Uživateli jsou přiřazeny preference (tj. účast, možná účast, neúčast) k dané akci. Alternativní scénář případu užití: krok 6 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 4. Návrh uživatelského rozhraní: Přihlašovací formulář je obdobný formuláři 4.10 z případu užití 4.1.16. 4.1.18
Zobrazení a změna přihlášených akcí
Aktéři: rodič, instruktor, vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Je na stránce s kalendářem akcí - viz. případ užití 4.1.4. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.18. Scénář je zachycen i v diagramu aktivit na obrázku 4.12.
Obrázek 4.11: Zobrazení a změna přihlášených akcí.
54
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role 1 Systém
Akce Na začátku stránky s kalendářem akcí zobrazí přehled akcí, na které je přihlášen uživatel nebo jím registrované dítě. Vedle názvu každé přihlášené akce je zobrazen formulářový prvek s aktuálním stavem přihlášení daného uživatele (resp. jeho dítěte) na konkrétní akci. Uživatel POKUD chce uživatel změnit stav přihlášení sebe nebo dítěte na akci, učiní tak změnou hodnoty formulářového prvku a stiskem tlačítka „Uložit změnu”, které jsou oboje zobrazeny u příslušné přihlášené akce. K dispozici jsou stavy „Přihlášen” a „Nepřihlášen”. Pro aktéry v roli jiné než rodič je přístupný i stav „Nerozhodnut”, který slouží k projevení zájmu o akci, kdy zároveň uživatel není ještě rozhodnut, zda se akce skutečně zúčastní. JINAK se pokračuje dalším bodem scénáře. Systém POKUD uživatel potvrdil změnu stavu přihlášení některé akce, je tato změna uložena do databáze. Zároveň se pokračuje ve scénáři od kroku 1. JINAK od systému není očekávána žádná reakce. Uživatel pokračuje v prohlížení kalendáře dle Use Case 4.1.4. Tabulka 4.18: Use Case Zobrazení a změna přihlášených akcí
2
3
4
Návrh uživatelského rozhraní: Přehled přihlášených akcí a stav přihlášení je na obrázku 4.11. 4.1.19
Vložení nové akce do kalendáře
Aktéři: vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Je na stránce s kalendářem akcí - viz. krok 3 případu užití 4.1.4. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.19. Krok Role 1 Systém
Akce Zobrazí na začátku stránky s kalendářem akcí odkaz na přidání akce.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
55
Krok Role 2 Uživatel 3 Systém
Akce Klikne na tlačítko „Přidat akci”. Zobrazí formulář pro vyplnění údajů o akci. Vedle názvu je třeba zadat termín akce, kapacitu a přidat případný další popis. Součástí formuláře je i volba, pro koho je akce určena. Uživatel Vyplní do formuláře všechny povinné údaje a dá pokyn k uložení informací do systému stiskem tlačítka „Vložit akci”. Systém Ověří správnost vyplnění údajů a uloží je v databázi. Tabulka 4.19: Use Case Vložení nové akce do kalendáře
4 5
Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce přidání akce do kalendáře určena, není odkaz na přidání akce zobrazen. Scénář je zde předčasně ukončen. krok 5 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 3. Návrh uživatelského rozhraní: Formulář pro přidání nové akce je na obrázku 4.13. 4.1.20
Vytvoření fotogalerie
Aktéři: vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce se seznamem fotogalerií - viz. krok 3 případu užití 4.1.5. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.20. Krok Role 1 Systém 2 3
Uživatel Systém
4
Uživatel
Akce Jako součást stránky se seznamem fotogalerií zobrazí tlačítko „Přidat novou fotogalerii”. Klikne na tlačítko „Přidat novou fotogalerii”. Zobrazí formulář pro vytvoření nové fotogalerie. Jedním z údajů k vyplnění je i informace, komu je fotogalerie určena. Na výběr je: „vedoucím” nebo „neregistrovaným” uživatelům6 . Do formuláře vyplní nadpis fotogalerie a určí, komu je určena. Stiskne tlačítko ”Vytvořit fotogalerii”.
Jak již bylo uvedeno dříve, fotogalerie určené neregistrovaným jsou samozřejmě přístupné i všem ostatním rolím. 6
56
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role 5 Systém
Akce Systém ověří správnost vyplnění údajů a uloží vložené informace do databáze. Systém Zároveň s provedením kroku 5 automaticky vytvoří složku, do které budou fotografie dané galerie ukládány - jméno složky vychází z názvu fotogalerie při založení, přičemž jsou použity jen znaky používané při tvorbě internetových aplikací (nejsou tedy povoleny např. mezery či české znaky). Název složky se se změnou názvu fotogalerie v systému již dále nemění. Tabulka 4.20: Use Case Vytvoření fotogalerie
6
Alternativní scénář případu užití: krok 5 - Když uživatel nevyplní formulář nebo vloží nevalidní data, systém ho na to upozorní a vrátí do kroku 4. krok 6 - Pokud se systému nepodaří pro novou galerii vytvořit odpovídající složku, nejsou v systému žádná data o nové složce uložena a Use Case je ukončen s nesplněným zadáním. Návrh uživatelského rozhraní: Formulář pro přidání nové fotogalerie je obdobný formuláři pro přidání akce na obrázku 4.13. 4.1.21
Vložení fotografií
Aktéři: vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce s obsahem fotogalerie - viz. krok 5 případu užití 4.1.5 -, do které chce vložit nové obrázky. Jako obrázky lze vkládat jen soubory typu JPG. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.21. Krok Role 1 Systém 2 3
Uživatel Systém
Akce Zobrazí obsah fotografie dle Use Case 4.1.5 a nad částí s náhledy fotek zobrazí odkaz „Vložit nové fotografie do galerie”. Klikne na odkaz „Vložit nové fotografie”. Zobrazí formulář pro vložení pěti fotografií. Cestu k fotografii lze určit pomocí tlačítka „Procházet” a zobrazeného okna pro procházení složek, které je standardní pro používaný operační systém.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
57
Krok Role 4 Uživatel 5 6
Akce Pomocí příkazů „Procházet” najde cestu až k pěti fotografiím. Pro potvrzení vložení všech vybraných fotek do systému stiskne tlačítko „Vložit fotografie”. Systém Ověří správnost zadaných údajů a stáhne fotografie na server, přičemž je uloží do složky, která je přiřazena galerii, do které se vkládá. Systém Zároveň s provedením kroku 5 jsou automaticky vkládané fotografie přejmenovány a jsou vytvořeny jejich náhledy. Jméno náhledu je stejné jako jméno originálního obrázku s tím, že se před název dá předpona „th ”. Jméno souborů vychází z původního názvu souboru, přičemž jsou použity jen znaky používané při tvorbě internetových aplikací (tedy např. mezery či české znaky nejsou povoleny). Tabulka 4.21: Use Case Vložení fotografií
Alternativní scénář případu užití: krok 5 - Jestliže nebyly zadány správné cesty k souborům, formát souboru neodpovídal uvedenému omezení nebo obrázky byly moc velké, je o tom uživatel informován chybovou hláškou a je vrácen do kroku 4. krok 6 - Pokud se systému nepodaří vytvořit náhledy, nejsou obrázky ani další informace o nich do systému uloženy. Use Case je ukončen.
58
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 4.12: Diagram aktivit: Zobrazení a změna přihlášených akcí.
Obrázek 4.13: Vložení nové akce do kalendáře.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
59
Návrh uživatelského rozhraní: Formulář pro přidání nových fotografií je zobrazen na obrázku 4.14.
Obrázek 4.14: Vložení fotografií.
4.1.22
Zobrazení informací o osobách přihlášených na akci
Aktéři: vedoucí, správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce s podrobnými informacemi o zvolené akci - tj. po kroku 5 případu užití 4.1.4. Chce zobrazit informace o přihlášených osobách na danou akci. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.22. Krok Role 1 Systém 2 3
Akce Zobrazí ovládací prvek pro zobrazení seznamu přihlášených účastníků na danou akci. Uživatel Stiskne tlačítko „Přihlášení účastníci”. Systém Zobrazí seznam osob, které jsou přihlášeny na danou akci. Součástí seznamu jsou i některé osobní údaje o přihlášeném. Uživatelům v roli „vedoucí” je zobrazeno méně údajů o přihlášené osobě, uživatelům v silnějších rolích je zobrazeno více údajů o přihlášené osobě. Tabulka 4.22: Use Case Zobrazení informací o osobách přihlášených na akci
60
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 3 - Pokud není nikdo na akci přihlášen, je zobrazen prázdný seznam. Návrh uživatelského rozhraní: Informace o akci včetně tlačítka pro zobrazení přihlášených účastníků jsou na obrázku 4.15.
Obrázek 4.15: Zobrazení akce - editační tlačítka.
4.1.23
Schválení registrace uživatelů
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.23. Krok Role 1 Uživatel 2 Systém 3
4
Akce Klikne na položku menu „Nové registrace”. Zobrazí stránku se seznamem žádostí o registraci - ty vznikly jako výsledek případu užití 4.1.6. Uživatel V seznamu nově registrovaných uživatelů čekajících na schválení registrace zaškrtne všechny, jejichž registraci chce povolit. Změnu stavu registrace vybraných uživatelů provede stiskem tlačítka „Schválit vybrané registrace”. Systém Plně aktivuje uživatelské účty výše vybraným uživatelům. 4.1.6. Tabulka 4.23: Use Case Schválení registrace uživatelů
Omezení na stav systému po ukončení případu užití: Uživatelské účty, které byly ve stavu schvalování registrace a které byly správcem aktivovány, mohou systém využívat v rozsahu definovaném pro registrovanou roli.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
61
Alternativní scénář případu užití: krok 3 a 4 - Žádost o registraci může správce nebo administrátor zamítnout stiskem tlačítka „Zamítnout registraci”, které je uvedené vedle každé žádosti. Systém po příkazu k zamítnutí smaže žádost o registraci ze systému. Návrh uživatelského rozhraní: Návrh rozhraní pro schvalování a zamítání registrací je na obrázku 4.16. Položka menu s odkazem na „Nové registrace” a další položky určené správci stránek jsou zobrazeny v návrhu menu na obrázku 4.17.
Obrázek 4.16: Schválení registrace uživatelů.
Obrázek 4.17: Část menu určená správcům stránek.
4.1.24
Správa off-line přihlášek
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Chce přihlásit účastníky na některou z vypsaných akcí. Typicky to jsou děti přihlášené např. na tábor formou vyplněné papírové přihlášky. Uživatel má přihlášku, kterou chce zanést do systému, v papírové formě, ve formě sms, e-mailu atp. Všechny tyto přihlášky jsou tzv. „off-line přihlášky”. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.24.
62
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role 1 Uživatel 2 Systém 3 4 5 6
7
8
Akce Klikne na položku menu „Off-line přihlášky”. Zobrazí stránku s příkazy pro vložení a editaci off-line přihlášky. Uživatel Zvolí jednu z možností: „Přihlásit na akci” nebo „Změnit přihlášení”. Systém Zobrazí seznam s akcemi uloženými v systému. Uživatel Ze seznamu vybere akci, které se prováděná operace týká. Stiskne tlačítko „Pokračovat”. Systém POKUD uživatel zvolil přihlášení na akci, pokračuje scénář obdobně jako od kroku 3 v Use Case 4.1.17. JINAK uživatel zvolil změnu přihlášky a je zobrazen seznam přihlášených účastníků na zvolenou akci. Vedle jména přihlášeného účastníka je zobrazen formulářový prvek s aktuálním stavem přihlášení. Uživatel Změní stav přihlášení tak, že vybere požadovanou hodnotu formulářového prvku a stiskne tlačítko „Uložit změnu” oboje je zobrazeno u jména editovaného účastníka. K dispozici jsou stavy „Přihlášen”, „Nepřihlášen” a „Nerozhodnut”, který slouží k projevení zájmu o akci, kdy zároveň potenciální účastník není ještě rozhodnut, zda se akce skutečně zúčastní. Systém POKUD uživatel potvrdil změnu stavu přihlášení některé akce, je tato změna uložena do databáze. Zároveň se pokračuje ve scénáři od kroku 6. JINAK od systému není očekávána žádná reakce. Tabulka 4.24: Use Case Správa off-line přihlášek
Návrh uživatelského rozhraní: Návrh rozhraní pro změnu off-line přihlášek je na obrázku 4.18.
Obrázek 4.18: Správa off-line přihlášek.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.1.25
63
Zobrazení seznamů přihlášených dětí na jednotlivé akce
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Chce zobrazit a případně i vytisknout seznamy dětí přihlášených na některou z vypsaných akcí. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.25. Krok Role 1 Uživatel 2 Systém
Akce Klikne na položku menu „Seznamy dětí”. Zobrazí stránku, kde je možné zvolit akci, z níž chceme generovat seznam přihlášených dětí. Zároveň je na výběr možnost generování několika druhů seznamů - detailní, zkrácený, seznamy pro získání slev atp. Uživatel Zvolí akci, z níž chce seznam dětí generovat, a zvolí typ seznamu, jenž chce zobrazit. Stiskne tlačítko „Vytvořit seznam”. Systém V novém okně prohlížeče zobrazí seznam s údaji o přihlášených dětech. Množství údajů závisí na typu zvoleného seznamu. Pro zobrazení seznamu je zvolena jen jednoduchá grafika, která umožňuje pohodlné vytištění seznamu přímo z prohlížeče internetových stránek. Tabulka 4.25: Use Case Zobrazení seznamů přihlášených dětí na jednotlivé akce
3 4
Alternativní scénář případu užití: krok 2 - Pokud není v systému uložena žádná akce, není možné ve scénáři dále pokračovat. Uživatel je o tom informován. Scénář je zde ukončen. krok 4 - Pokud není na akci přihlášeno žádné dítě, je zobrazen prázdný seznam. Návrh uživatelského rozhraní: Formulář pro generování seznamů dětí je na obrázku 4.19.
4.1.26
Správa stránek
Aktéři: správce stránek, administrátor
64
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 4.19: Seznam dětí přihlášených na akce - formulář pro jeho generování. Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Chce do systému vložit nové stránky, resp. chce již existující změnit. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.26. Krok Role 1 Uživatel 2 Systém
3
7
Uživatel
Akce Klikne na položku menu „Správa stránek”. Zobrazí seznam stránek, které jsou v systému uloženy. U každé stránky jsou zobrazena tlačítka „Smazat stránku” a „Editace stránky”. Pro vytvoření nové stránky je zobrazeno „okno” s formulářem - tímto je proveden krok 1 případu užití 4.1.27. Zvolí akci, kterou chce provést. POKUD chce uživatel vytvořit novou stránku, pokračuje se případem použití 4.1.27 od kroku 2. POKUD uživatel zvolil smazání stránky, zobrazí systém dotaz, zda se má stránka skutečně smazat. Pokud uživatel smazání potvrdí, jsou nejprve smazány všechny prvky stránky (včetně obsahu) - když se toto smazání povede, systém smaže i požadovanou stránku. Nepovede-li se to, stránka není smazána. Pokračuje se znovu od kroku 2. POKUD uživatel zvolil editaci stránky, systém zobrazí formulář, ve kterém je možné editovat uložené parametry stránky. Typ stránky nelze změnit7 . Uživatel zedituje formulář a změny potvrdí stiskem potvrzovacího tlačítka. Systém následně uloží data do systému.
Typ lze zvolit jen při vytváření stránky - viz. Use Case 4.1.27.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role
65
Akce JINAK uživatel neprovedl žádnou akci, je scénář ukončen. Tabulka 4.26: Use Case Správa stránek
Návrh uživatelského rozhraní: Přehled stránek uložených v systému spolu s editačními funkcemi je uveden na obrázku 4.20. Varování před smazáním stánky je na obrázku 4.21. Editační okno vlastností stránky vidíme na obrázku 4.22. Pokud stránka obsahuje článek, můžeme jej při editaci změnit, jak je vidět z obrázku 4.23.
Obrázek 4.20: Správa stránek - přehled stránek uložených v systému.
Obrázek 4.21: Správa stránek - varování před smazáním stránky.
66
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 4.22: Správa stránek - editace vlastností stránky.
Obrázek 4.23: Správa stránek - editace stránky s článkem.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.1.27
67
Nová stránka
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází na stránce se správou stránek - viz. Use Case 4.1.26. V kroku 3 případu užití 4.1.26 se rozhodl pro vytvoření nové stránky. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.27. Krok Role 1 Systém
2
Uživatel
3
Systém
Akce Zobrazí formulář pro vytvoření nové stránky. Součástí je volba typu stránky, jež má být vytvořena. Na výběr je stránka s článkem, akcemi, novinkami, fotografiemi, diskusemi a s kontakty. Vyplní formulář a zvolí, jaký typ stránky vytváří. Stiskne tlačítko „Vytvořit novou stránku”. Uloží data do systému. Tabulka 4.27: Use Case Nová stránka
Omezení na stav systému po ukončení případu užití: Do systému je uložena stránka bez obsahu, jen se základními údaji. Obsah se pro stránky s články vloží dle scénáře 4.1.26 (přes volbu „Editace stránky” kroku 3). Obsah stránky s kontakty je generován automaticky. Obsah stránky s novinkami se vloží dle scénáře 4.1.35. Obsah stránky s diskusemi se vloží dle scénáře 4.1.33, kde jsou vytvořena samotná diskusní témata. Obsah stránky s fotogaleriemi se vloží dle scénáře 4.1.20, kde jsou vytvořeny jednotlivé prázdné fotogalerie. Obsah stránky s akcemi se vloží dle scénáře 4.1.19. Alternativní scénář případu užití: krok 3 - Vloží-li uživatel nevalidní data, systém ho na to upozorní a vrátí jej do kroku 2. 4.1.28
Úprava menu
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Chce upravit menu aplikace, tj. chce přidat, odebrat nebo pozměnit položky zobrazovaného menu.
68
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.28. Krok Role 1 Uživatel 2 Systém
3
4
Uživatel
5
Systém
Akce Klikne na položku menu „Úprava menu”. Zobrazí editovatelný seznam (formulář) aktuálních položek menu. U každé položky je uveden název, pořadí v menu, stránka, na kterou položka menu odkazuje, tlačítko pro změnu dané položky menu a tlačítko pro smazání. Zároveň je zobrazeno i tlačítko pro přidání položky do menu. POKUD chce uživatel smazat položku menu, stiskne u vybrané položky tlačítko „Smazat”. Systém se zeptá, zda se má položka menu skutečně smazat. Pokud to uživatel potvrdí, vymaže ji ze systému. Dále se pokračuje od kroku 2. POKUD chce uživatel přidat do menu novou položku, stiskne tlačítko „Vytvořit novou položku menu”. Do systému je uloženo nové menu s prázdným obsahem. Obsah (název, odkazovaná stránka atd.) se naplní stejným způsobem jako při editaci položky menu. Pokračuje od kroku 2 tohoto scénáře. POKUD chce uživatel editovat položku menu, pokračuje se krokem 4 tohoto scénáře. JINAK se nic neděje a scénář je ukončen. Může editovat jednotlivé položky menu. Editovat lze název položky, pořadí v menu, na jakou stránku položka odkazuje (to je voleno výběrem z rozevíracího menu, kde jsou uvedeny všechny stránky uložené v systému). Pro provedení změn položky se stiskne tlačítko „Uložení změn”, zobrazené vedle editované položky. Ověří vstupní data a uloží je do databáze. Pokračuje se krokem 2 tohoto scénáře. Tabulka 4.28: Use Case Úprava menu
Alternativní scénář případu užití: krok 5 - Pokud uživatel vložil nevalidní data, je na to upozorněn a záznamy o položce v menu nejsou změněna. Pokračuje se krokem 2. Návrh uživatelského rozhraní: Přehled položek menu spolu s editačními funkcemi je uveden na obrázku 4.24. Varování před smazáním položky menu je obdobné jako v případě užití „Správa
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
69
stránky” - obrázek 4.21.
Obrázek 4.24: Úprava menu - přehled položek menu.
4.1.29
Editace kalendáře akcí
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Je na stránce s kalendářem akcí - viz. případ užití 4.1.4. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.29. Krok Role 1 Systém 2 3
Akce Zobrazí u každé akce editační tlačítko a tlačítko pro smazání akce. Uživatel Stiskne u akce, kterou chce změnit, tlačítko „Edituj akci”. Systém Pokračuje od kroku 3 (včetně alternativního scénáře) ze scénáře Use Case 4.1.19 s tím, že ve formuláři jsou předvyplněny údaje o akci, které jsou uloženy v databázi. Tabulka 4.29: Use Case Editace kalendáře akcí
70
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce editace kalendáře akcí určena, nejsou editační tlačítka zobrazena. Scénář je zde předčasně ukončen. krok 2 - Pro smazání vybrané akce z kalendáře stiskne uživatel tlačítko „Smaž akci”. Systém vymaže údaje o akci ze systému a scénář je zde ukončen. Návrh uživatelského rozhraní: Přehled funkčních tlačítek dostupných pro konkrétní akci je na obrázku 4.15.
4.1.30
Editace diskusních příspěvků
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Prohlíží si příspěvky v některé z diskusí - viz. případ užití 4.1.12. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.30. Krok 1 2 3
Role
Akce Zobrazí u každého příspěvku akce editační tlačítko. Stiskne editační tlačítko u příspěvku, který chce změnit. Pokračuje od kroku 1 (včetně alternativního scénáře) ze scénáře Use Case 4.1.13 s tím, že ve formuláři jsou předvyplněny uložené hodnoty k danému příspěvku. Tabulka 4.30: Use Case Editace diskusních příspěvků
Systém Uživatel Systém
Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce editace diskusních příspěvků určena, není editační tlačítko zobrazeno. Scénář je zde předčasně ukončen.
4.1.31
Mazání fotografií
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Prohlíží si fotografie v některé z fotogalerií - viz. případ užití 4.1.5.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
71
Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.31. Krok Role 1 Systém 2 Uživatel
Akce Zobrazí u každé fotografie tlačítko pro smazání fotografie. Stiskne tlačítko pro smazání u fotografie, kterou chce z dané galerie odstranit. Systém Odstraní záznam o fotografii z databáze. Zároveň ji smaže z disku včetně jejího náhledu. Tabulka 4.31: Use Case Mazání fotografií
3
Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce mazání fotografií určena, není editační tlačítko zobrazeno. Scénář je zde předčasně ukončen. krok 3 - Pokud se nepodaří odstranit fotografii z databáze, nedojde ani k jejímu smazání z disku (platí i pro náhled). 4.1.32
Mazání a editace fotogalerií
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce se seznamem fotogalerií - viz. krok 3 případu užití 4.1.5. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.32. Krok Role 1 Systém 2 3 4 5
Akce Zobrazí u každé fotogalerie tlačítko pro smazání a pro editaci fotogalerie. Uživatel Stiskne tlačítko pro smazání u fotogalerie, kterou chce ze systému odstranit. Systém Zobrazí dotaz, zda se má daná galerie včetně všech obsažených fotografií skutečně smazat. Na výběr jsou možnosti „ano” a „ne”. Uživatel Zvolí tlačítko „ano” pro smazání dané galerie včetně obsažených fotografií. Systém Odstraní záznam o fotogalerii z databáze, zároveň vymaže záznam v databázi o všech fotografiích v dané galerii obsažených a fyzicky je smaže z disku včetně náhledů. Tabulka 4.32: Use Case Mazání a editace fotogalerií
72
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce mazání fotografií určena, není tlačítko pro mazání zobrazeno. Scénář je zde předčasně ukončen. krok 4 - Uživatel stiskne „ne” pro nesmazání dané galerie. Nedojde ke smazání fotogalerie, scénář je zde ukončen a uživatel je uveden do stavu po kroku 1 tohoto scénáře. Zde je scénář buď ukončen nebo lze mazat další galerie. krok 5 - Pokud se nepodaří odstranit fotografie ze systému, nedojde ani ke smazání záznamu o dané fotogalerii. krok 2 - Uživatel stiskne editační tlačítko u fotogalerie, kterou chce změnit. Systém zobrazí formulář z kroku 3 případu užití 4.1.20 s předvyplněnými informacemi, které jsou o galerii uloženy v systému. Dále se pokračuje ve zmíněném scénáři s tím, že krok 6 scénáře 4.1.20 se neprovádí - složka, kam se ukládají fotografie dané galerie si nechává své původní jméno. Platí i alternativní krok 5 výše odkazovaného scénáře. Návrh uživatelského rozhraní: Editační a mazací tlačítko je zobrazeno stejný způsobem jako jsou tlačítka zobrazena u „akce” - viz. obrázek 4.15. Varovné hlášení před smazáním galerie je obdobné jako na obrázku 4.21.
4.1.33
Vytvoření diskusního tématu
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce se seznamem diskusních témat - viz. krok 3 případu užití 4.1.12. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.33. Krok Role 1 Systém 2 3
Uživatel Systém
4
Uživatel
Akce Jako součást stránky se seznamem diskusních témat zobrazí tlačítko „Vytvořit nové diskusní téma”. Klikne na tlačítko „Vytvořit nové diskusní téma”. Zobrazí formulář pro vytvoření nového diskusního tématu. Jedním z údajů k vyplnění je i informace, komu je daná diskuse určena. Na výběr jsou všechny uživatelské role krom neregistrovaných uživatelů a administrátora. Do formuláře vyplní nadpis diskusního tématu a určí, komu je určena. Stiskne tlačítko ”Vytvořit novou diskusi”.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
73
Krok Role 5 Systém
Akce Systém ověří správnost vyplnění údajů a uloží vložené informace do databáze. Tabulka 4.33: Use Case Vytvoření diskusního tématu
Alternativní scénář případu užití: krok 5 - Když uživatel nevyplní formulář nebo vloží nevalidní data, systém ho na to upozorní a vrátí do kroku 4. Návrh uživatelského rozhraní: Tlačítko „Vytvořit nové diskusní téma” je zobrazeno na úrovni nadpisu stránky s diskusními tématy. Zobrazení je obdobné jako u vkládání „novinek” na obrázku 4.25. Formulář pro vložení diskusního tématu je podobný s formulářem pro vložení „novinky” na obrázku 4.26. 4.1.34
Mazání a editace diskusního tématu
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Nachází se na stránce se seznamem diskusních témat - viz. krok 3 případu užití 4.1.12. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.34. Krok Role 1 Systém 2 3 4 5 6
Akce Zjistí, pod jakou rolí je uživatel aktuálně přihlášen na stránkách. Systém Zobrazí u každého diskusního tématu tlačítka pro jeho smazání a pro jeho editaci. Uživatel Stiskne tlačítko pro smazání tématu, jež chce ze systému odstranit. Systém Zobrazí dotaz, zda se má dané téma včetně všech obsažených příspěvků skutečně smazat. Na výběr jsou možnosti „ano” a „ne”. Uživatel Zvolí tlačítko „ano” pro smazání daného tématu včetně obsažených příspěvků. Systém Odstraní záznam o diskusním tématu z databáze, zároveň vymaže záznam v databázi o všech diskusních příspěvcích, které do daného tématu patří. Tabulka 4.34: Use Case Mazání a editace diskusního tématu
74
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Alternativní scénář případu užití: krok 2 - Pro uživatelské role, pro které není funkce mazání fotografií určena, není tlačítko pro mazání zobrazeno. Scénář je zde předčasně ukončen. krok 5 - Uživatel stiskne „ne” pro nesmazání daného tématu. Téma nebude smazáno, scénář je zde ukončen a uživatel je uveden do stavu po kroku 2 tohoto scénáře. Zde je scénář buď ukončen nebo lze mazat další témata. krok 6 - Pokud se nepodaří odstranit diskusní příspěvky ze systému, nedojde ani ke smazání záznamu o daném diskusním tématu. krok 3 - Uživatel stiskne editační tlačítko u diskusního tématu, které chce změnit. Systém zobrazí formulář z kroku 3 případu užití 4.1.33 s předvyplněnými informacemi, které jsou o tématu uloženy v systému. Dále se pokračuje v odkazovaném scénáři včetně jeho alternativní části. Návrh uživatelského rozhraní: Editační a mazací tlačítko je zobrazeno stejný způsobem jako jsou tlačítka zobrazena u „akce” - viz. obrázek 4.15. Varovné hlášení před smazáním diskusního tématu je obdobné jako na obrázku 4.21.
4.1.35
Vložení novinek
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Je na stránce s novinkami - viz. případ užití 4.1.3. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.35. Krok Role 1 Systém 2 3
4 5
Akce Zobrazí na začátku stránky s novinkami odkaz na přidání novinky. Uživatel Klikne na tlačítko „Přidat novinku”. Systém Zobrazí formulář pro vyplnění informací o novince. Jedním z údajů k vyplnění je i informace, komu je novinka určena. Na výběr je: „vedoucím” nebo „neregistrovaným” uživatelům. Uživatel Vyplní do formuláře všechny povinné údaje a dá pokyn k uložení informací do systému stiskem tlačítka „Vložit novinku”. Systém Ověří správnost vyplnění údajů a uloží je v databázi. Tabulka 4.35: Use Case Vložení novinek
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
75
Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce přidání novinky určena, není odkaz pro přidání zobrazen. Scénář je zde předčasně ukončen. krok 5 - Pokud chybí vyplnění některého povinného údaje, popř. jsou-li zadána nevalidní data, zobrazí systém uživateli chybovou hlášku a vrátí jej do kroku 3. Návrh uživatelského rozhraní: Tlačítko „Přidat novinku” je zobrazeno na úrovni nadpisu stránky s novinkami nad krátkým textem, který zobrazuje stručné informace o stránce s novinkami. Pod tímto textem jsou zobrazeny již samotné novinky. Tlačítko je zobrazeno na obrázku 4.25. Formulář pro vložení novinky je na obrázku 4.26.
Obrázek 4.25: Vložení novinek. 4.1.36
Editace novinek
Aktéři: správce stránek, administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Je na stránce s novinkami - viz. případ užití 4.1.3. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.36. Krok Role 1 Systém 2
Uživatel
Akce Zobrazí u každé novinky editační tlačítko a tlačítko pro smazání novinky. Stiskne editační tlačítko u novinky, kterou chce změnit.
76
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Krok Role 3 Systém
Akce Pokračuje od kroku 2 (včetně alternativního scénáře) ze scénáře Use Case 4.1.35 s tím, že ve formuláři jsou předvyplněny informace o novince, které jsou uloženy v databázi. Tabulka 4.36: Use Case Editace novinek
Alternativní scénář případu užití: krok 1 - Pro uživatelské role, pro které není funkce editace kalendáře akcí určena, nejsou editační tlačítka zobrazena. Scénář je zde předčasně ukončen. krok 2 - Pro smazání vybrané novinky uživatel stiskne tlačítko pro smazání. Systém vymaže údaje o novince ze systému a scénář je zde ukončen. Návrh uživatelského rozhraní: Tlačítko pro editaci a mazání je zobrazeno stejným způsobem jako u „akce” viz. obrázek 4.15. 4.1.37
Přidělení role správce
Aktéři: administrátor Omezení na stav systému před spuštěním případu užití: Uživatel je přihlášen do systému v roli, která je uvedená v kolonce aktéři. Uživatel se nachází kdekoli na stránkách tábora. Kroky případu užití: Jsou popsány ve scénáři případu užití v tabulce 4.37. Krok Role 1 Uživatel 2 Systém 3
4
Akce Klikne na položku menu „Přidělení role správce”. Zobrazí stránku se seznamem uživatelů, kteří mají přidělenu roli „Vedoucí”. Uživatel V zobrazeném seznamu zaškrtne všechny vedoucí, jimž chce dát práva na správu stránek, tj. jimž chce přidělit roli „Správce stránek”. Změnu role vybraných uživatelů provede stiskem tlačítka „Potvrdit změny”. Systém Vybraným uživatelům přidělí roli „Správce stránek”. Tabulka 4.37: Use Case Přidělení role správce
Alternativní scénář případu užití: krok 3 a 4 - Odebrání role „správce” a přiřazení role „vedoucí” se provede zrušením zaškrtnutí zaškrtávacího políčka u vybraného uživatele, který měl dosud roli „správce stránek”. Systém po stisku tlačítka „Potvrdit změny” změní
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
77
Obrázek 4.26: Formulář pro vložení novinky. uživatelům, jimž bylo zrušeno zaškrtnutí, roli na vedoucího, který již nemá právo spravovat obsah stránek.
4.2
Konceptuální datový model
Konceptuální modely se snaží popisovat data nezávisle na jejich finálním uložení ve zvolené databázi. Konceptuální model představuje formální popis modelované reality, jeho hlavním úkolem je nalezení entit, vtahů, popř. i atributů. Slouží obvykle k vytvoření schémat s následnou transformací na databázové schéma. Při tvorbě konceptuálního modelu postupujeme následovně. Identifikujeme typy entit jako množiny objektů stejného typu (např. exemplář knihy, čtenář). Následně hledáme typy vztahů, do kterých entity identifikovaných typů mohou vstupovat (např. čtenář (entita) má půjčen (vztah) exemplář knihy (entita)). Dále ještě můžeme na základě přiměřené úrovně abstrakce přiřadit jednotlivým typům entit a vztahů popisné atributy (např. příjmení (popisný atribut) čtenáře (entita)). Nakonec lze formulovat i integritní omezení vyjadřující s větší či menší přesností soulad schématu s modelovanou realitou. Někdy se popisné atributy přiřazují entitám až v samotném datovém modelu. Tak to budu dělat i já. V této části najdu jen entity a vztahy mezi nimi. V další části mé práce se pak dostanu i k definovaní atributů entit a k jejich popisu. Pro znázornění konceptuálního datového modelu využiji tzv. Martinovi notace. Vysvětleme si nejprve význam použitých symbolů: • entita - objekt reálného světa, který je schopen nezávislé existence a je jednoznačně odlišitelný od ostatních objektů. Můžeme říct, že je to určité uskupení dat, jež k sobě logicky patří a jež zkoumáme v rámci v rámci dané analýzy. Entity popisujeme podstatným jménem.
78
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ • vztah - vazba mezi dvěma či více více entitami. Vztahy se obvykle označují slovesy. • atribut - položka dané entity (např. entita pacient má atribut jméno, rodné číslo atd.) Máme tři základní typy vazeb: 1:1, 1:N a N:N.
Na obrázku 4.27 je Entita1 ve vztahu k Entitě2. Kolečko u symbolu „vidlička”, který přiléhá k Entitě2, značí, že Entita1 může k sobě mít žádný nebo několik výskytů Entity2. Pokud by byl požadován alespoň jeden výskyt, bylo by místo kolečka zakresleno „přeškrtnutí”. To, že Entita2 musí být ve vztahu právě s jednou Entitou1, je vyjádřeno jednoduchou „čárou” u Entity1 a symbolem „přeškrtnutí”. „Kolečko” na stejném místě by znamenalo, že Entita2 může být ve vztahu s maximálně jednou Entitou1.
Obrázek 4.27: Vazba 1:N mezi entitami. Obdobná pravidla platí pro vztah 1:1 uvedený na obrázku 4.28, kde Entita3 může být ve vztahu s žádnou nebo jednou Entitou4. Entita4 musí být ve vztahu právě s jednou Entitou3.
Obrázek 4.28: Vazba 1:1 mezi entitami. Vazba N:N se používá jen v počátcích analýzy, pro výsledné databázové schéma je nevhodná a musí být dekomponována. Značení se řídí stejnými předpisy jako u předchozích typů vazeb. Na obrázku 4.29 může být Entita5 ve vztahu s žádným až mnoha Entitami6, což platí i opačně.
Obrázek 4.29: Vazba N:N mezi entitami. Na základě analýzy popsaných Use Casů a požadovaných funkčností jsem nalezl entity, které je třeba zakomponovat do vyvíjeného informačního systému. Konceptuální datový model je uveden na obrázku 4.30.
KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 4.30: Konceptuální datový model.
79
80
KAPITOLA 5. IMPLEMENTACE
5 Implementace 5.1
Datový model
Fyzický model je diagram, který znázorňuje způsob uložení dat informačního systému do databázového stroje. Na modelu jsou zobrazeny entity, které představují jednotlivé tabulky ukládané do databáze. Ke každé entitě jsou připojeny atributy, každý atribut odpovídá jednomu sloupečku v databázové tabulce. Atribut se skládá ze jména, datového typu, může být povinný nebo nepovinný, může být primárním či cizím klíčem. Databázové schéma informačního systému pro dětský tábor je zobrazeno na obrázku 5.1. Primární klíče jsou psány červeně s textem „(PK)”, cizí klíče jsou zobrazeny zeleně s textem „(FK)”. Povinné atributy jsou znázorněny symbolem „(NN)”. V následujících tabulkách jsou popsány atributy jednotlivých databázových tabulek vyvíjeného informačního systému. Tabulka stranka (viz. tabulka 5.1) obsahuje základní informace o stránkách, které je prostřednictvím systému možné zobrazit uživatelům. Vedle nadpisu je povinným atributem i typ stránky, který určuje, jaký obsah bude daná stránka zobrazovat: „A” je pro stránku s akcemi, „C” pro stránku s články, „D” je stránka s diskusními fóry, „F” slouží pro zobrazování fotogalerií, „K” k zobrazení stránky s kontakty a „N” pro stránky uveřejňující novinky. Úvodní text slouží k uložení textu, který popisuje základní informace o stránce. Název ID stranka Nadpis Typ stranky Uvodni text
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null varchar(50) Not Null char(1) Not Null varchar(255) Null Tabulka 5.1: Databázová tabulka stranka
Tabulka menu (viz. tabulka 5.2) slouží k vytvoření položek menu. Název je text zobrazený ve výsledném menu, „ID stranka” obsahuje identifikaci stránky (z tabulky stranka), na níž položka menu odkazuje. Parametr pořadí slouží k určení posloupnosti zobrazování položek menu na výsledné stránce zobrazované uživatelům systému. Název ID menu ID stranka Nazev Poradi
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null smallint(5) FK, Not Null varchar(50) Null smallint(5) Null Tabulka 5.2: Databázová tabulka menu
Tabulka prvek stranky (viz. tabulka 5.3) obsahuje jednotlivé prvky, které se mohou na stránce objevit. Těmito prvky jsou články, novinky, diskusní fóra, fotogalerie a tábo-
KAPITOLA 5. IMPLEMENTACE
Obrázek 5.1: Datový model.
81
82
KAPITOLA 5. IMPLEMENTACE
rové akce. V této tabulce se určí základní vlastnosti prvku, detaily (jako text článku či diskusního příspěvku k danému tématu atp.) jsou uloženy v jednotlivých specializovaných tabulkách. Cizí klíč odkazuje na tabulku stranka. Vedle nadpisu a krátkého popisu prvků stránky je důležitým atributem je tzv. „oprávnění”, kam se zapisuje číselná hodnota. Čím vyšší hodnota, tím větší práva uživatel potřebuje, aby mu byl daný prvek stránky zpřístupněn. Hodnoty obecně odpovídají atributu „práva” z tabulky role. Nejsou s touto tabulkou ve vztahu proto, aby se hodnota práv nemusela měnit v případě, že by došlo k odebrání některé role ze systému. Položka „složka” slouží k uložení názvu adresáře, kam mají být nahrávány obrázky dané fotogalerie. Název Datový typ ID prvek stranky smallint(5) ID stranka smallint(5) Nadpis varchar(50) Kratky popis varchar(255) Opravneni smallint(5) Slozka varchar(255) Tabulka 5.3: Databázová
Vlastnosti PK, auto increment, Not Null FK, Not Null Not Null Null Not Null Null tabulka prvek stranky
Tabulka clanek (viz. tabulka 5.4) obsahuje data o článku. Cizí klíč odkazuje na tabulku prvek stranky. Název ID clanek ID prvek stranky Text clanku
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null smallint(5) FK, Not Null text Null Tabulka 5.4: Databázová tabulka clanek
Tabulka novinka (viz. tabulka 5.5) je strukturou shodná s tabulkou článek, přesto jsem ji pro přehlednost oddělil do samostatné entity. Cizí klíč odkazuje na tabulku prvek stranky. Název Datový typ Vlastnosti ID clanek smallint(5) PK, auto increment, Not Null ID prvek stranky smallint(5) FK, Not Null Text novinky text Null Tabulka 5.5: Databázová tabulka novinka
Tabulka fotografie (viz. tabulka 5.6) obsahuje informace o jednotlivých fotografiích, které patří do fotogalerie uložené v tabulce prvek stranky, kam odkazuje i cizí klíč „ID prvek stranky”. O vložené fotografii ukládáme informace o názvu souboru a názvu souboru s náhledem.
KAPITOLA 5. IMPLEMENTACE
83
Název Datový typ Vlastnosti ID fotografie smallint(5) PK, auto increment, Not Null ID prvek stranky smallint(5) FK, Not Null Jmeno nove varchar(100) Not Null Jmeno nahledu varchar(103) Not Null Tabulka 5.6: Databázová tabulka fotografie
Tabulka diskusni prispevek (viz. tabulka 5.7) obsahuje informace o jednotlivých příspěvcích do diskuse, jejíž téma a krátký popis je uložen v tabulce prvek stranky, kam odkazuje i cizí klíč „ID prvek stranky”. Druhý cizí klíč určuje, který uživatel příspěvek do diskuse vložil. Název Datový typ Vlastnosti ID diskusni prispevek smallint(5) PK, auto increment, Not Null ID uzivatel smallint(5) FK, Not Null ID prvek stranky smallint(5) FK, Not Null Titulek varchar(50) Not Null Text prispevku text Not Null Datum vlozeni timestamp Not Null Tabulka 5.7: Databázová tabulka diskusni prispevek
Tabulka akce (viz. tabulka 5.8) obsahuje informace o plánovaných akcích uveřejňovaných v kalendáři. Cizí klíč „ID prvek stranky” je navázán na tabulku prvek stranky, druhý cizí klíč určuje, jakým rolím je daná akce určena. Mezi povinné atributy patří datum a čas začátku a konce akce, je možné uložit i kapacitu konkrétní akce. Název ID akce ID prvek stranky Akce urcena roli Text akce Datum zacatku Datum konce Kapacita
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null smallint(5) FK, Not Null smallint(5) FK, Not Null text Null datetime Not Null datetime Not Null smallint(6) Null Tabulka 5.8: Databázová tabulka akce
Tabulka uzivatel (viz. tabulka 5.9) obsahuje všechny informace, které se o uživatelích ukládají do systému. Každý uživatel má přiřazené vedle automaticky generovaného ID i „login” do systému. V zašifrované podobě se ukládá i heslo pro přihlášení. Každý uživatel má nějakou roli, na níž odkazuje cizí klíč „ID role”. Cizí klíč „ID rodice” slouží k uložení informací o rodiči daného uživatele. Nemusí-li mít uživatel rodiče, je do tohoto atributu ukládáno jeho vlastní ID, takže je sám sobě rodičem. „Stav registrace” slouží k uložení informace o tom, zda bylo uživateli schváleno zaregistrování do systému. Ostatní atributy
84
KAPITOLA 5. IMPLEMENTACE
mají samovysvětlující názvy, takže myslím, že je není třeba podrobněji rozebírat. Název ID uzivatel ID role ID rodice Login Heslo Stav registrace Jmeno Prijmeni Datum narozeni Email Icq Skype Telefon Ulice Mesto Psc
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null smallint(5) FK, Not Null smallint(5) FK, Not Null varchar(20) Not Null varchar(40) Not Null char(1) Not Null varchar(20) Not Null varchar(40) Not Null datetime Null varchar(60) Null char(11) Null varchar(30) Null char(15) Null varchar(60) Null varchar(30) Null char(5) Null Tabulka 5.9: Databázová tabulka uzivatel
Tabulka role (viz. tabulka 5.10) obsahuje definici jednotlivých rolí používaných v systému. Atrbut „prava” obsahuje číselnou hodnotu. Čím vyšší tato hodnota je, tím větší práva uživatel v systému má. Textový popis role se ukládá do „popis role”. Název ID role Prava Popis role
Datový typ Vlastnosti smallint(5) PK, auto increment, Not Null smallint(5) Not Null varchar(30) Null Tabulka 5.10: Databázová tabulka role
Tabulka prihlaska (viz. tabulka 5.11) obsahuje informace ukládané v případě, že se účastník přihlásí na některou z akcí. Cizí klíč „ID akce” slouží k uložení informací o přihlašované akci a je navázán na odpovídající tabulku. Druhý cizí klíč odkazuje na tabulku uzivatel, ukládá se do něj informace, kdo se přihlásil na danou akci. „Stav prihlaseni” obsahuje informace o tom, v jakém stavu se přihláška nachází, zda je uživatel skutečně přihlášen, zda se odhlásil nebo se ještě nerozmyslel. Ostatní atributy mají samovysvětlující názvy. Název ID prihlaska ID uzivatel ID akce Datum prihlaseni Stav prihlaseni
Datový typ smallint(5) smallint(5) smallint(5) datetime char(1)
Vlastnosti PK, auto increment, Not Null FK, Not Null FK, Not Null Not Null Not Null
KAPITOLA 5. IMPLEMENTACE Název Jmeno Prijmeni Ulice Mesto Psc Zdravotni pojistovna Judista Plavec Jmeno rodice1 Prijmeni rodice1 Telefon rodice1 Email rodice1 Zamestnavatel rodice1 Povolani rodice1 Tabulka
85
Datový typ Vlastnosti varchar(20) Not Null varchar(40) Not Null varchar(60) Not Null varchar(30) Not Null char(5) Not Null varchar(50) Null tinyint(1) Null tinyint(1) Null varchar(20) Null varchar(40) Null char(15) Null varchar(60) Null varchar(50) Null varchar(30) Null 5.11: Databázová tabulka prihlaska
V porovnání s konceptuálním modelem ubyla entita kontakty - všechny stránky, které mají zobrazovat kontakty jsou generovány automaticky, a tak již nebylo nutné vytvářet pro ně speciální tabulku, která by byla závislá na tabulce prvek stranky.
5.2
Struktura programu
Program je složen ze souborů, které jsou uloženy v několika adresářích. Jeho struktura je zobrazena na obrázku 5.2.
Obrázek 5.2: Struktura částí programu. Po zadání internetové adresy, pod níž je táborový informační systém dostupný přes internet, do prohlížeče se zobrazí úvodní stránka systému. Uživatel po celou dobu práce se systém komunikuje jen s PHP skriptem index.php. V tomto souboru je nastaven jednotný vzhled stránek - část zobrazující hlavičku, navigační menu i část určenou pro obsah. V těchto jednotlivých částech jsou volány funkce, které stránkám dodávají samotný obsah. Grafická podoba systému je plně závislá na souboru styl.css. Pozadí menu i obsahu je tvořeno opakujícím se úzkým obrázkem new.gif.
86
KAPITOLA 5. IMPLEMENTACE
Do souboru index.php jsou includovány další PHP skripty, které vykonávají jednotlivé funkčnosti programu. Nejprve popíšu inicializační soubory. V connect.php je kód, který při požadavku na libovolnou stránku systému provede automatické připojení k databázovému stroji MySQL. Data z databáze je potřeba získávat při zobrazování libovolné stránky. To, k jaké databázi se systém připojuje, záleží na nastavení konfiguračního souboru conf.php, do kterého se vyplní jméno databáze, uživatelské jméno a heslo získané od poskytovatele webového serveru. V souboru inc.php jsou definovány konstanty používané v jednotlivých programech a některé pomocné funkce. Pro zobrazení menu a samotného obsahu volá soubor index.php funkce obsažené ve skriptu zobrazeni.php. Tyto funkce zobrazují menu a stránky různých typů (kalendář, diskuse atd.). Zobrazení jednotlivých prvků stránek (diskusní příspěvek, konkrétní novinku apod.) má na starosti skript prvek.php. Funkčnosti určené správcům stránek, resp. administrátorovi jsou implementovány v souboru sprava.php. Jedná se např. o vkládání stránek do systému, vytváření položek menu, schvalování nových uživatelů. Registrace uživatele do systému, změny jeho osobních údajů, správa přihlášených akcí, funkce umožňující přihlášení a odhlášení do systému a další funkčnosti související s jednotlivými uživateli jsou realizovány skriptem uzivatele.php. Adresář images slouží k ukládání obrázků. V této složce se vytvářejí adresáře pro jednotlivé fotogalerie, do nichž se následně nahrávají vlastní fotografie včetně náhledů. Přímo do složky images jsou zároveň správcem systému vkládány obrázky, které se mají zobrazit na stránkách v rámci jednotlivých článků. Skripty značkovacího systému Texy! a jeho nadstavby Texyla jsou všechny uloženy v adresáři texyla.
KAPITOLA 6. TESTOVÁNÍ
87
6 Testování Testování je součástí vývoje každého programu a pro odevzdání kvalitního produktu ho nelze vynechat. Lze jej rozdělit do několika částí.
6.1
Testování kódu
Při testování se snažíme nalézt slabá místa programu, přivést ho do nestandardního stavu apod. Výsledkem bývá odhalení co největšího počtu chyb, které jsou pak následně opraveny. Zadáním vstupních dat do programu získáme výstupní data, která porovnáme s očekávanými výstupními hodnotami. Pokud se neshodují, vyskytla se chyba. Pro tvorbu dat pro testovací případy existují dvě základní techniky - white-box a black-box testování.
6.1.1
white-box testy
Při white-box testování stanovujeme data pro testovací případy na základě znalosti vnitřní logiky programu. Otestujeme tak funkčnosti jednotlivých částí programu. Testují se vnitřní datové struktury, všechny cykly, okrajové podmínky. Cílem je projít všechny cesty programu aspoň jednou. Toto testování jsem prováděl v průběhu samotného programování. Vstupní data jsem si rozdělil do tříd, data z každé třídy mají za následek jiný průchod programu. Zástupce každé třídy jsem pak otestoval a zjistil, zda funkce dává správný výsledek nebo ne.
6.1.2
black-box testy
Při black-box testování se na testovaný program díváme jako na černou skříňku a snažíme se zjistit za jakých okolností se chová jinak, než jak je uvedeno ve specifikaci. Provedení těchto testů jsem realizoval jednak já osobně, zároveň jsem o něj požádal i své kamarády z dětského tábora. Na internet jsem umístil funkční části aplikace a mailem je požádal o otestování jednotlivých funkčností. Zároveň jsem po nich žádal, aby jako vstupní data zadávali i neobvyklé hodnoty. Chyby mi byly oznamovány e-mailem.
6.2
Testy databáze
Po vložení databázových tabulek do databázového systému jsem je naplnil testovacími daty. Již vkládání dat bylo testem, jenž ověřoval zejména správné nastavení primárních a cizích klíčů a povinné a nepovinné atributy. Dále byly provedeny testovací SQL dotazy.
88
6.3
KAPITOLA 6. TESTOVÁNÍ
Testy projektu jako celku
Celý projekt byl opět otestován formou black-box testů. Zároveň jsem provedl validační testy, které slouží k ověření, že systém splňuje zákazníkovy požadavky. Provádět lze dva typy validačních testů. Testování provádí zákazník za účasti programátora a testy, kdy zákazník ověřuje funkčnost už bez přítomnosti programátora. Toto testování jsem prováděl tak, že jsem procházel případy užití a porovnával požadované funkčnosti s výslednou částí systému, jenž měla konkrétní případ implementovat. Když došlo k nesrovnalostem mezi případem užití a programem, upravil jsem kód tak, aby výsledek odpovídal zadání.
6.4
Usability testy
Tuto formu testování uživatelského rozhraní jsem již nestačil provést kvůli časovému zaneprázdnění mému a mých přátel z táborového prostředí. Na jaro plánuji vytvoření několika úkolů, které zadám dvěma či třem vedoucím a instruktorům. Provádění těchto úkolů budu sledovat a v případě, že se narazí na nějakou zásadní chybu v navrženém uživatelském rozhraní, tak ji následně opravím. Nevím, zda se mi k tomuto testování podaří přivést i některé z dětí, které bude systém využívat.
KAPITOLA 7. ZÁVĚR
89
7 Závěr 7.1
Zhodnocení a závěr
Cílem mojí diplomové práce bylo navrhnout a implementovat internetový informační systém pro dětský tábor. Tábor již pro prezentaci na internetu využívá systém eStránky, který ale není dostatečně flexibilní, aby dovedl uspokojit všechny požadavky, které organizátoři na systém mají. Provedl jsem studii dané problematiky, požadavky na systém jsem konzultoval s několika členy organizačního týmu dětského tábora. Po jejich zpracování a prozkoumání dostupných řešení jsem se rozhodl pro implementaci systému vlastními silami. Pro získání přesné specifikace potřeb bylo nutné problematiku hlouběji analyzovat, jednotlivé požadavky bylo třeba domyslet do podrobností. Výsledkem toho je i rozsáhlá analýza uvedená v jedné z předchozích kapitol mojí práce. Při jejím zpracovávání jsem se průběžně radil se členy táborového vedení a snažil se diskutoval o mém řešení. Výhodou pro mě bylo, že se na organizování tábora spolupodílím, a tak mám poměrně dobrou představu o přáních jednotlivých osob na nový systém. Po provedení analýzy jsem se pustil do samotné implementace systému. Dlouhou dobu jsem strávil studiem různých knih a internetových serverů věnujících se programování v PHP. Výsledkem je informační systém pro dětský tábor, který umožní organizátorům na internetu představit tábor široké veřejnosti. Zároveň poslouží i jako komunikační nástroj mezi vedoucími, dětmi a jejich rodiči a to formou diskusních fór a publikací fotografií ze společných akcí. Celoročně bude možné do systému zadávat plánované mimotáborové akce a bude možné se na ně přihlásit.
7.2
Budoucnost systému
Nasazení systému do provozu se předpokládá během léta. Očekávám, že jeho zavedení bude uvítáno, protože řeší nedostatky, jež má původní systém. Fotografie z letošního letního tábora by měly být zveřejňovány již za pomoci nového systému. Do té doby proběhne ještě uživatelské testování, které nebylo možné dosud provést z důvodů časové zaneprázdněnosti vedoucích. Na základě reakcí uživatelů je lze provést ještě některé drobné změny uživatelského rozhraní. Zároveň budou do léta stanoveny i přesné požadavky na automatizované seznamy, které by měl systém vytvářet. Ty pak budou do systému doprogramovány. Nabízí se i některá vylepšení, která by mohla být v budoucnu systémem realizována. Nahrávání fotografií do galerií je v současné době možné jen pomocí formuláře na stránkách systému, což je v případě nutnosti publikovat větší množství fotek dosti zdlouhavé a nepohodlné. Bylo by dobré zpřístupnit funkci nahrání fotek na server pomocí FTP klienta a jejich následné automatické zavedení do databáze. Zajímavou možností rozšíření může např. být i možnost ohodnocování kvality fotografií.
90
KAPITOLA 7. ZÁVĚR
KAPITOLA 8. LITERATURA
8 Literatura [1] Apache - webový server. http://www.apache.org . [2] Drupal. http://www.drupal.cz/ . [3] Dětské-tábory.info. http://www.detske-tabory.info . [4] estránky.cz. http://www.estranky.cz . [5] Živě. http://www.zive.cz . [6] Jak psát web - o tvorbě internetových stránek. http://www.jakpsatweb.cz . [7] Joomla! http://www.joomla.org/ . [8] Lupa. http://www.lupa.cz . [9] Mysql. http://dev.mysql.com/downloads/ . [10] owebu.cz. http://www.owebu.cz . [11] phpmyadmin. http://phpmyadmin.cz/ . [12] Profitux.cz - webhosting. http://www.profitux.cz/freehosting/ . [13] Super svět - phprs. http://www.supersvet.cz . [14] Texy! http://texy.info/cs/ . [15] Texyla. http://texyla.jaknato.com . [16] Webgarden|zone. http://zone.webgarden.cz . [17] Wikipedia. http://wikipedia.org .
91
92
KAPITOLA 8. LITERATURA
[18] Wordpress. http://wordpress.org/ . [19] Lee Babin. Beginning Ajax with PHP: From Novice to Professional. Apress, 2007. [20] Banan.cz. webhosting. http://www.banan.cz/ . [21] Filip Chereches-Tosa Mihail Bucica Christina Darie, Bogdan Brinzarea. AJAX a PHP - tvoříme interaktivní webové aplikace profesionálně. Zoner Press, 1. edition, 2006. [22] Miroslav Müller Hana Kanisová. UML srozumitelně. Computer Press, 2. edition, 2006. [23] Ivan Halaška Jaroslav Pokorný. Databázové systémy. Vydavatelství ČVUT, 2nd edition, 2003. in Czech. [24] Lupa. estránky.cz: z osobních stránek milionová služba, 2007. http://www.lupa.cz/clanky/projekt-estranky-cz-z-osobnich-stranekmilionova-sluzba/ . [25] PHP. On-line dokumentace php. http://cz.php.net/manual/cs/ .
DODATEK A. SEZNAM POUŽITÝCH ZKRATEK
A Seznam použitých zkratek Ajax asynchronous JavaScript and XML Apache a patchy server; webový server ASP active server pages Blog též weblog, vzniklo stažením anglického web log, tedy webový záznam CMS content management system (systém pro správu obsahu) CSS cascading style sheets DOM document object model FK foreign key (česky cizí klíč) FTP file transfer protocol GB gigabyte GPL general public license HTML hypertext markup language HTTP hyper text transfer protocol HW hardware JSON JavaScript object notation MB megabyte MS Microsoft NN Not Null PC personal computer PHP rekurzivní zkratka PHP: Hypertext Preprocessor PK primary key (česky primární klíč) RS redakční systém SQL structured query language SW software UC UseCase (případ užití) URL uniform resource locator W3C world wide web consortium
93
94
DODATEK A. SEZNAM POUŽITÝCH ZKRATEK
WCM web content management system (systém pro správu webovéhoobsahu) WYSIWYG what you see is what you get (neboli ”co vidíš, to dostaneš”) WWW world wide web XHTML extensible hypertext markup language (rozšiřitelné HTML) XML extensible markup language (rozšiřitelný značkovací jazyk)
DODATEK B. INSTALAČNÍ PŘÍRUČKA
95
B Instalační příručka Pro zprovoznění systému podnikněte kroky, které jsou popsány níže. Instalace předpokládá použití operačního systému Windows. V případě využití operačního systému na bázi Linux je instalace obdobná.
B.1
Instalace FTP klienta
1. v internetovém prohlížeči zadejte adresu http://download.totalcommander.cz/. 2. klikněte na „32 bit verze”. 3. vyberte stránku, ze které chcete program stáhnout. 4. uložte program na libovolné místo na disku. 5. po stažení spusťte instalaci programu Total Commander. 6. nechte vše ve standardním nastavení až se doklikáte ke spuštění instalace. 7. potvrďte spuštění instalace.
B.2
Získání webového prostoru
1. v internetovém prohlížeči zadejte adresu www.profitux.cz. 2. klikněte na tlačítko „webhosting” a zvolte položku „freehosting”. 3. vyplňte registrační formulář - zvolte adresu, kterou chcete používat pro stránky tábora; v kolonce „ukázka tvorby” zadejte současnou adresu táborových stránek. Potvrďte registraci. 4. registrace bude nyní provozovatelem zpracována. Nejpozději během jednoho dne obdržíte na uvedenou adresu e-mail se všemi důležitými registračními údaji.
B.3
Zavedení databáze
1. vložte DVD do vaší DVD mechaniky. 2. v internetovém prohlížeči zadejte adresu http://freeadmin.profitux.cz. 3. do formuláře zadejte uživatelské jméno a heslo, které vám přišlo e-mailem. Jedná se o informace z e-mailu označené „FREEadmin”. 4. po přihlášení klikněte na phpMyAdmin. 5. zadejte uživatelské jméno a heslo pro přístup do databáze. Jedná se o informace z e-mailu označené „MySQL Databaze”.
96
DODATEK B. INSTALAČNÍ PŘÍRUČKA 6. po přihlášení klikněte na záložku „import”. 7. stiskněte tlačítko „procházet” a najděte na DVD s informačním systémem soubor db.sql, který je umístěný ve složce instalace. 8. znakovou sadu zadejte „utf8”. 9. stiskněte tlačíko „proveď”.
10. zavřete okno prohlížeče, se kterým jste dosud pracovali.
B.4
Nahrání skriptů na server
1. na DVD se přesuňte do složky is. 2. zmáčkněte klávesu „shift” a pravým tlačítkem myši klikněte na soubor conf.php. Najeďte na položku „otevřít v programu” a zde vyberte „zvolit program”. 3. vyberte „poznámkový blok” a stiskněte „ok”. 4. dostali jste se do editace konfiguračního souboru pro databázi. 5. v šestém řádku místo „dp” napište název databáze, který vám přišel e-mailem. Jedná se o informace z e-mailu označené „MySQL Databaze”. 6. obdobně v sedmém řádku nahraďte „root” uživateským jménem z e-mailu, v osmém řádku zadejte místo „heslo” heslo z e-mailu. 7. klikněte na menu soubor a dejte uložit jako. V kolonce „uložit jako typ” zvolte všechny soubory. Název souboru nechte na conf.php. Neměňte ani kódování. 8. klikněte na tlačítko „tento počítač” a dál dvojklik na disk „C:” - tím jste určili, že upravený soubor chcete uložit přímo na disk „C:”. Stiskněte tlačítko „uložit”. 9. z nabídky „start” - „programy” spusťte nainstalovaný program Total Commander. 10. klikněte myší do pravého okna, následně zvolte menu „síť” a „FTP - připojit se” 11. zvolte tlačítko „nové připojení”. 12. vyplňte kolonky dle následovných pokynů. Do názvu relace zadejte „tábor”. Jako hostitel uveďte údaj, který vám přišel e-mailem. Jedná se o informace z e-mailu označené „FTP”. 13. ze stejné části e-mailu vyplňte kolonky „ jméno uživatele” a „heslo”. 14. klikněte na „ok”. 15. v levé části okna „připojení k FTP serveru” označte položku „tábor” a stiskněte tlačítko připojit. 16. klikněte myší do levého okna. Ve výběrovém tlačítku vlevo pod menu zvolte disk „C:” výběrem položky „-c-”.
DODATEK B. INSTALAČNÍ PŘÍRUČKA
97
17. najeďte na soubor „conf.php”, stiskněte klávesu „F5” a dejte „enter”. 18. ve výběrovém tlačítku vlevo pod menu zvolte písmeno disku, pod kterým máte DVD mechaniku. 19. po načtení najeďte do složky is. Stiskněte hvězdičku na numerické klávesnici. Tím označíte všechny soubory ke zkopírování na server. 20. stiskněte klávesu „F5” a dejte enter. Vyčkejte, než se všechna data nahrají na server. 21. zavřete Total Commander. Můžete jej nyní i odinstalovat.
B.5
Spuštění systému
1. v internetovém prohlížeči zadejte adresu, která odpovídá vašemu uživatelskému jménu z e-mailu. Jedná se o informace označené „FTP”. 2. zobrazí se vám táborový informační systém. 3. přihlaste se do něj uživatelským jménem „admin” a heslem „tabor123”. 4. do systému jste přihlášen v roli administrátora. 5. změňte si osobní údaje a zejména heslo.
98
DODATEK C. UŽIVATELSKÁ PŘÍRUČKA
C Uživatelská příručka C.1
Základní navigace
Všechny popisované funkčnosti jsou závislé na roli, která je přiřazena vašemu uživatelskému účtu. Proto vám nemusí být některé popisované části zpřístupněny! • Pro zobrazení stránek zadejte do internetového prohlížeče adresu, kde jsou táborové stránky umístěny. • Stránky jsou rozděleny do tří částí, jak je viděl z obrázku C.1. • Největší místo zabírá pravá část, kde zobrazován obsah zvolené stránky. • V levé části je zobrazené menu. Pod každou položkou menu se ukrývá odkaz na některou ze stránek. Správce by měl dbát na to, aby se podle názvu položky dalo odhadnout, na jakou stránku odkazuje. Přesun na jinou stránku provedeme kliknutím na libovolnou položku menu. Následně nám je zobrazen obsah zvolené stránky. Na stránce může být zobrazen článek, což je delší text. Dále jsou zobrazovány novinky, kalendář akcí, kontakty na ostatní uživatele, seznam fotogalerií a diskusních fór. • Pro zobrazení fotografií si musíte nejprve na stránce s fotogaleriemi vybrat fotogalerii, kterou si chcete prohlížet. To provedete kliknutím na název galerie. Budou zobrazeny náhledy fotografií. Kliknete-li na náhled, je zobrazena fotografie v plné velikosti. Máte-li zobrazené náhledy fotografií a dostatečná práva, je vám přístupná funkce pro nahrání dalších fotek do galerie. Klikněte na odkaz „Vložit nové fotografie do galerie”. Zde vyberte až pět obrázků, které chcete vložit. Následně stiskněte tlačítko „Vložit fotografie” a vyčkejte, až se nahrají na server. • Pro zobrazení příspěvků v diskusním fóru si musíte nejprve na stránce s diskusemi vybrat diskusní téma, u kterého chcete zobrazit jednotlivé příspěvky. To provedete kliknutím na název diskusního tématu. Bude vám zobrazen text všech diskusních příspěvků daného tématu. Na začátku stránky je zobrazen i formulář pro vkládání nových příspěvků do diskuse. • V horní části, ještě nad samotným obsahem je přihlašovací menu. S jeho pomocí se můžeme přihlásit do systému (vyplňte vaše uživatelské jméno a heslo a klikněte na tlačítko přihlásit). Tamtéž se můžete následně i odhlásit stiskem tlačítka odhlásit - viz. obrázek C.2.
C.2
Registrace do systému a změna osobních údajů
• v přihlašovacím menu klikněte na položku „Registrace do systému”. • vyplňte všechna povinná pole, zvolte roli, kterou chcete používat, a stiskněte tlačítko „Registruj”.
DODATEK C. UŽIVATELSKÁ PŘÍRUČKA
99
Obrázek C.1: Zobrazení stránek o táboře. • během jednoho až dvou dnů očekávejte schválení registrace správcem stránek. Následně se můžete do systému přihlásit a využívat jej. • pro změnu osobních údajů stiskněte „Změnit osobní údaje”. Zobrazí se vám stránka se souhrnem vašich osobních údajů a odkazem na změnu hesla či dalších vašich údajů. Klikněte na požadovaný odkaz a proveďte změny. Nezapomeňte je potvrdit stiskem potvrzovacího tlačítka. • Ze stejné stránky můžete zaregistrovat do systému u vaše dítě. Stiskněte „Registrace dítěte” a vyplňte registrační formulář. Uživatelský účet vašeho dítěte je aktivní ihned po dokončení registrace. Údaje o dítěti můžete i změnit po zvolení volby „Změnit údaje dítěte”.
Obrázek C.2: Odhlášení ze systému.
C.3
Přhlášení na akci
• Zobrazte stránku s kalendářem akcí a klikněte na tlačítko přihlásit se na akci. Vyplňte formulář a potvrďte jej. Tímto jste přihlášeni na akci. • Obdobným způsobem můžete na akci přihlásit i svoje dítě.
100
DODATEK C. UŽIVATELSKÁ PŘÍRUČKA
• Přehled vašich přihlášených akcí je zobrazen na začátku stránky s kalendářem. Zde můžete vaše přihlášení též zrušit.
C.4
Správa dalších prvků
• Pro vložení novinek jděte na stránku s novinkami a klikněte na „Přidat novinku”. Vyplňte formulář a potvrďte. Novinka je vložena do systému. Příkazy pro editaci či smazání novinek jsou přístupné opět ze stránek s novinkami. • Chcete-li vložit novou akci do kalendáře klikněte na stránce s jeho zobrazením na tlačítko „Přidat akci” a vyplňte zobrazený formulář. Akce je po potvrzení vložena do systému a zobrazována uživatelům. Příkazy pro editaci či mazání akcí jsou přístupné opět ze stránek s kalendářem akcí.
C.5
Administrační prvky pro správce stránek
• Správcům stránek jsou přes menu zpřístupněny následující funkčnosti: „správa stránek”, „správa menu”, „nové registrace”, „seznamy dětí” a „off-line přihlášky”. • „správa stránek” umožňuje vkládání nových stránek do systému, stejně jako editaci vlastností již uložených stránek. Stránku zde můžeme i vymazat. Rozhraní pro správu stránek vidíme na obrázku C.3. • „správa menu” slouží ke zpřístupnění stránek uživatelům. Odkaz na stránky je vložen pod jednotlivé položky menu. Ty můžeme opět vkládat, mazat či editovat, jak je vidět z obrázku C.4. • „nové registrace” slouží ke schválení žádostí o registraci do systému. Jednotlivé žádosti můžeme buď smazat, anebo je označit a pak hromadně potvrdit jejich schválení stiskem potvrzovacího tlačítka. • „seznamy dětí” nám umožňují vygenerovat seznam přihlášených dětí na jednotlivé akce. Je třeba zvolit akcí, pro kterou chceme seznam vytvořit, a druh tohoto seznamu. Následně stiskneme tlačítko „vytvořit seznam”. • „off-line přihlášky” nám zpřístupňují možnost vložit do systému přihlášky dětí, které jsem obdrželi klasickou papírovou formou. • Uživatelům v roli „administrátor” je zpřístupněna ještě volba „Přidělení role správce”. Zde zaškrtne všechny vedoucí, jimž chce dát práva na správu stránek, tj. jimž chce přidělit roli „Správce stránek”. Výběr je ještě nutné potvrdit stiskem tlačítka „Potvrdit změny”.
DODATEK C. UŽIVATELSKÁ PŘÍRUČKA
Obrázek C.3: Správa stránek.
Obrázek C.4: Úprava menu.
101
102
DODATEK D. OBSAH PŘILOŽENÉHO DVD
D Obsah přiloženého DVD Na přiloženém DVD je následující adresářová struktura: • /instalace/db.sql - soubor s dávkou SQL příkazů pro vytvoření databáze • /is - v této složce jsou uloženy všechny zdrojové kódy informačního systému pro dětský tábor • /help – v této složce je uložena uživatelská a instalační příručka v PDF formátu • /text – v této složce je zdrojový text mé diplomové práce ve formátu TEX podobě • /diplomova prace.pdf – tento text v PDF formátu
