1. Úvod. Kapitola 1. Úvod

1

1. Úvod

„Internetový portál pro dospívající dívky - Holky sobě“ je experimentální projekt stojící na hranici tří vědních oborů - informatiky, sociologie a medicíny. Má práce se zaměřuje

z

převážné

části

na

stránku odborného

technického

provedení

informačního systému. Ten má dívkám nabídnout možnost řešit své problémy s dívkami stejného věku a také s lékaři. Neodmyslitelnou součástí je rozhodně možnost vést si osobní menstruační kalendář. Téma mé bakalářské práce může někomu přijít zábavné, ale realita bohužel často potvrzuje opak. Zdravotní i osobní problémy dívek nejen u nás v České republice jsou banalizovány a řešení zpočátku nepatrného problému se časem stává obtížné, ba někdy až nemožné. Implementace jako webová aplikace umožňuje již v současnosti přístup široké veřejnosti a jelikož zájmová skupina je ve věku od cca 11 do 26 let, mohou dívky navštívit stránky také ve školách, které svým žákům/studentům umožňují přístup k Internetu stále více. Jedním

ze

základních

předpokladů

a

také

důležitým

požadavkem

pro přístupnost a použitelnost internetové aplikace je využití doporučovaných postupů pro zabezpečení přehlednosti, jednoduchého a intuitivního ovládání na většině platforem a zařízeních umožňujících prohlížení internetových stránek.

Kapitola 1. Úvod

2

Internetový portál pro dospívající dívky

Bakalářská práce

3

2. Formulace cílů Kapitola vytyčuje hlavní cíl a definuje dílčí cíle a základní požadavky projektu 1) Vytvořit internetový portál pro dospívající dívky 2) Zajistit uchovávání dat jednotlivých uživatelů î Registrace uživatelů •

Registrace dívek

•

Registrace lékařů

î Přihlašování pro přístup k osobním datům a funkcím 3) Vytvořit rozhraní pro uchovávání informací o zdravotním stavu během menstruace – Menstruační kalendář 4) Zabezpečit možnost komunikace mezi uživateli î Vytvoření diskusního fóra î Vytvoření rozhraní pro zasílání zpráv mezi uživateli 5) Vytvořit rozhraní pro možnost poskytnutí služeb lékařů dívkám î Rezervační systém 6) Zabezpečit srozumitelnost a jednotnost zobrazovaných informací 7) Zabezpečit bezpečnost a přístupnost stránek

Kapitola 2. Formulace cílů

4



5

3. Rešerše

Mnou navrhovaný projekt se snaží zaujmout, co se oblasti zájmu týče, nezastupitelné místo na českém i slovenském Internetu, jak se ukazuje ze zkušeností získaných během testovacího provozu. Stávající portály pro dospívající dívky jsou většinou zaměřeny na módní trendy v oblékání či líčení, kterým se zde věnuje poměrně velké množství lidí, ale řešení důležitých problémů je záležitostí často jedné odpovědné osoby, což může vést k nesprávnému subjektivně zabarvenému úsudku. Na mém serveru však nabízím v otevřené diskusi možnost vstupu i více lékařů, díky čemuž je na problém pohlíženo z různých pohledů a nabízí se tak více alternativ k jeho řešení. Za průlomový bod ve své práci považuji vedení osobního menstruačního kalendáře. Důvodem je, že k nejčastějším problémům dívek patří právě jeho nevedení či ztráta, která je tímto vyloučena. Tuto službu zatím nenabízí žádný současný internetový portál. Co se týče možnosti rezervace termínu návštěvy lékaře, existuje v České republice jeden server, který ji nabízí a to Ordinace.cz. Stránky nabízejí velice podobnou službu jako je mnou navrhovaný rezervační systém. Lékaři je nabídnuta možnost poskytnout on-line rezervaci příchozím uživatelům. Chybí zde, ale bohužel možnost registrace pro pacienta. Projekt rozhodně nemá ambici stát se alternativou kontroverzní Elektronické zdravotní knížky, kterou nabídla VZP svým pojištěncům, jelikož ta byla orientována spíše na lékaře, narozdíl od portálu „holky sobě“, který je zaměřen na pacientku.

Kapitola 3. Rešerše

6

3.1. Zhodnocení situace na českém internetu Jak jsem již nastínil, je nabídka portálů pro mladé ženy, či dívky v Čechách velice omezená. Již při vyhledávání klíčových slov, jako např. “stranky pro divky”, pomocí vyhledávače Seznam.cz, narazí dívky na bariéru v podobě stovek odkazů na stránky s pornografickým materiálem. Abych byl ale objektivní, je třeba pochválit portály Centrum.cz a Atlas.cz, které nabízí tématickou část Žena (každý svou vlastní samozřejmě – zena.centrum.cz, zena.atlas.cz). Dle obsahu a struktury jde o velice kvalitně a profesionálně zpracované portály. Rubriky obou se velice podobají a nabízí uživatelkám přístup k informacím o kráse, zdraví, dětech, ale také možnost nechat si poradit v oblastech psychologie, těhotenství, či kosmetiky. A zde narážíme na problém. Věková skupina, pro kterou jsou portály zaměřeny je mnohem širší než bychom vzhledem k dívkám pod 15 let chtěli. Značné množství témat zahrnuje témata kolem aktivního pohlavního života a tudíž není nejvhodnější ani pro věkovou skupinu do 18 let. Nutno, ale uznat, že jde o stránky velice hodnotné. Ožehavými tématy pro dívky nad 18 let se zabývá také server Sexus.cz, zaměřený na lidskou sexualitu. Jde, ale také o poměrně hodnotný portál, jelikož nabízí různá řešení problémů, které ani se sexualitou nesouvisí. Zdá se, že stránky rozhodně nevznikly za špatným účelem, ale bohužel opět nejsou vhodné pro dívky ve věku, na který je zaměřena má práce. Další zajímavou stránkou pro ženy jsou stránky 28dni.cz, které jsou ale zaměřeny zejména na zdraví. Dívky ve věku od 15 let zde mohou najít všechny nejdůležitější informace, týkající se jejich života. Stránky jsou díky propracovanému a modernímu designu přehledné a informace jsou podávány velice pěknou formou. Posledním odstrašujícím případem bych rád ukončil tuto podkapitolu. Stránky časopisu Top Dívka, se snaží zaujmout dívky funkcemi jako chat, diskusní fórum (v době mé návštěvy nefunkční!) ale hlavně na agresivní styl publikace novinek a trendů. To vše by bylo pro dívky kolem 14-15 roku přijatelné, ale bohužel zpracování je nepřehledné až matoucí a dívky spíše odradí.



7

3.2. Zahraniční opensource technologie Vytvoření funkčního portálu znamená týdny intenzivní práce. Pro konkrétní aplikace však lze využít nabídky tzv. Content managementu. Jde o prostředí, které zabezpečuje normalizovaný přístup k obsahu a také jeho jednoduchou změnu. Mezi nejslavnější patří : î MediaWiki / Wiki Nejvíce je proslavené prostředí a to díky internetové encyklopedii WikiPedia. Vytvoření webu je snadné – klikací. Používá se zejména v opensource ke komunikaci

komunitách mezi

díky

uživateli.

širokým Právě

možnostem,

snadná

které

úprava

nabízí

existujících

dokumentů dala vzniknout projektu WikiPedia. î Plone Jde taktéž o opensource produkt, který nabízí komplexnost. Obsahuje webový server, správce obsahu a objektovou databázi. Je napsán v programovacím jazyce Python a je možné ho pomocí něho také dále rozšiřovat. Oblíbený je zejména u vysokoškolských zařízení v USA. Do trochu jiné kategorie patří komplexní diskusní fóra. Jedno z nejoblíbenějších je opensource projekt forum bb. Často se u různých počítačových komunit setkáváme s úkazem, kdy celý web je tvořen pouze tímto fórem. Pro můj projekt jsou však všechny tyto technologie zbytečně komplexní a je efektivnější naimplementovat si jednotlivé části sám.

3.3. Oblasti návrhu internetové aplikace V této podkapitole bych Vám rád nastínil proces a metodiku tvorby internetových aplikací podobného typu jako je má práce. Své znalosti jsem čerpal z vlastních

zkušeností,

ale

hlavně

ze

znalostí

získaných

díky

předmětu


8 Internet a WWW (X36WWW), přednášeném na Fakultě elektrotechnické Českého vysokého učení technického v Praze. Problematika tvorby internetových aplikací zahrnuje řadu oblastí a vystačila by na samostatnou publikaci (kterých je mimochodem celá řada). Nejdůležitějším předpokladem je alespoň minimální orientace v implementované problematice, bez které nemá smysl začít jakoukoliv analýzu požadavků na funkčnost systému. Důkladnější seznámení však většinou přichází během vývoje. Výhodou bývá možnost interakce se zákazníkem, nebo se vzorkem zájmové skupiny, pro kterou je systém navrhován. Rozdělme si tedy základní témata do skupin a pak si o nich povíme podrobněji: I.

Užitečnost a propagace

II. 3P - Přehlednost, přístupnost, použitelnost III. Zabezpečení IV. Modularita V. Volba technologií a publikace

I.

Užitečnost a propagace Úkolem internetového portálu bývá nejčastěji zaujmout určitou skupinu

obyvatelstva nabídkou služeb a zajistit, aby tyto služby byly uživateli co nejvíce prospěšné, což vede k tomu, ze se uživatel následně vrací a službu využívá znovu. Pro poskytovatele je takovéto chování užitečné, zejména pokud pro něj návrat uživatele znamená finanční zisk (prodej přes Internet, reklama). Pokud jde o službu novou, na trhu dosud neposkytovanou, je na tvůrci, jak dokáže své stránky zpracovat, aby se uživateli jevily co nejvíce užitečné. Vhodným způsobem může být statistický průzkum ohledně zájmu o službu a následná reklamní kampaň mířená na konkrétní věkovou (sociální, národnostní, náboženskou, ...)



9 skupinu, jenž projevila při dotazu největší zájem. Využití existujících statistik nepřímo souvisejících s tématem může být také vhodnou alternativou. V konkurenčním prostředí je třeba zviditelnit rozdíly a výhody vůči ostatním, které jsou inovativní. Zdůraznění banálních rozšíření vhodným způsobem může také získat řadu nových uživatelů. Ve zkratce řečeno užitečnost a propagace spolu tvoří důležitou dvojici. Jejich vyvážená kombinace přinese pravděpodobně dlouhodobý zájem o stránky. Malá propagace i dokonalého portálu může přivést tvůrce ke krachu vlivem nízkému zisku z reklamy. Naproti tomu silně proklamovaný web s nejasnou užitečností ztratí většinu zákazníků po několika prvních návštěvách.

II.

3P - Přehlednost, přístupnost, použitelnost Již zmiňovaná užitečnost přímo závisí na 3P - přehlednosti, přístupnosti

a použitelnosti. Jde o velice důležitou a často opomíjenou troj-vlastnost, kterou by měl každý úspěšný portál splňovat. Uživateli by mělo být na první pohled jasné, k čemu jednotlivé ovládací prvky slouží, a co může očekávat v jednotlivých částech obrazovky. Grafické přepracování původní implementace pomocí HTML by nemělo měnit základní význam jednotlivých ovládacích prvků. Odkaz by tedy měl zůstat vizuálně odkazem a tlačítko tlačítkem. Rozvržení prvků na stránce by mělo být přehledné a nejlépe stabilní. Nepůsobí dobře, pokud se menu přesouvá během navigace mezi stránkami na různá místa. Při využití aktivních prvků, které vyžadují stažení podpůrných knihoven (tzv. plug-in), by měla být zabezpečena plná funkcionalita stránek i bez těchto prvků. To platí také pro skriptovací jazyky (JavaScript (JScript) nebo VBScript), jejichž spouštění má uživatel možnost omezit. Příkladem je vizuálně zajímavé menu vytvořené v programu Macromedia Flash. Uživatel, který nevlastní potřebné rozšíření, je nucen ke stažení rozšíření pro svůj prohlížeč, což v některých případech není přípustné (nízká uživatelská práva, pomalé připojení k Internetu, nedostatek


10 času). Řešením může být vložení alternativního obsahu, nebo nabídka 2 verzí na hlavní stránce. Využití technologie CSS může při správném používání pomoct vytvořit portál přístupný všem kategoriím uživatelů, dokonce uživatelům s postižením zraku nebo s omezenou možností ovládání počítače. Důležité je držet se doporučení konsorcia W3C, které definuje standardy pro nejrůznější technologie týkající se Internetu. Nejvýraznějším z doporučení W3C je používání HTML pouze pro definici obsahu

stránek

a

tudíž

zamezení

formátování

vzhledu

pomocí

tabulek,

nebo v nejhorším případě pomocí rámců. Provedení vizualizace je ponecháno čistě na technologii CSS. Použitelnost webu lze razantně snížit častým „vyskakováním“ oken s reklamou nebo také příliš častými dotazy na uživatele. Ne každá akce vyžaduje potvrzení od uživatele. Nepřehlednost stránek, nepředvídatelné chování, ztrácení zadaných dat a další implementační nešvary způsobí nechuť u uživatele a je pravděpodobné, že se na stránky již nevrátí.

III.

Zabezpečení Otázka zabezpečení stránek proti útoku zvenčí je v současnosti stále vývojáři

opomíjena. Již žák 2. stupně základní školy je schopen nechtěně (ale často chtěně) provést nejtriviálnější, ale i složitější útok na internetovou stránku. Pouze za pomoci webového prohlížeče může způsobit škodu, která může omezit nebo zastavit funkčnost části nebo celého portálu i na desítky hodin, pokud není technická podpora dostupná okamžitě. K nejběžnějším pokusům patří pokus o vložení parazitního HTML kódu skrz formulář s neošetřenými vstupními hodnotami. Takto lze například do návštěvní knihy vložit libovolný obsah, ať už jde o logo delikventa v nejlepším případě, nebo o klientský skript generující v nekonečné smyčce nová okna prohlížeče, což



11 může vést k nestabilitě procesu webového prohlížeče, jeho zamrznutí nebo v nejhorším případě k pádu systému. O možnosti vložení vizuálně neviditelného ActiveX prvku nesoucího trojského koně ani nemluvně... Možnosti napadení portálu jsou rozličné a mezi nejnápaditější patří pak zejména pokus podobný předchozímu, který je ale o mnoho nebezpečnější. Jde o techniku zvanou SQL injection, která využívá stejné prostředky jako předchozí neošetření vstupů z formuláře. Bohužel však útočí opačným směrem a to přímo na databázi. Do SQL dotazu vloží příkazy jazyka, které mu zabezpečí získání dat z databáze nebo dokonce práva pro plný a neomezený přístup ke všem datům. Oba způsoby napadení jsou však snadno ošetřitelné a zanedbání zabezpečení je jen projevem neprofesionality nebo lenosti, což je neomluvitelné a bohužel často i osudné.

IV.

Modularita Tvůrce portálu se musí těsně před započetím prací postavit nejdůležitější

otázce - zda bude vytvářené komponenty ještě někdy potřebovat. Kladná odpověď je pro většinu projektů samozřejmostí a z praxe se zdá, že by měla taková být pro každý navrhovaný projekt. Modulární pojetí aplikace nám dovoluje vytvořit logické celky použitelné i v jiných aplikacích než je ta aktuálně navrhovaná. Strukturování komponent do modulů nám jednak zjednodušuje práci, jednak znamená lepší zorientovaní pro nezainteresovanou osobu, která má zájem prozkoumat strukturu naší aplikace, ať už je to kolega, nadřízený, nebo v negativním případě útočník, jemuž se podařilo vniknout do systému.

V.

Volba technologií Existují nejrůznější kritéria pro volbu technologií pro návrh, tvorbu , technické

zabezpečení, atd.


12

Pravděpodobně nejznámějším je kritérium počátečních a provozních nákladů na zakoupení potřebného software (webový server, databázový server, vývojové prostředí, ...), technických prostředků (servery pro jednotlivé komponenty, náhradní elektrické zdroje, ...), případně dalších prostředků. Jde-li o malý projekt, nebo je podmínkou minimalizace nákladů, je vhodné zvolit si některý z tzv. opensource produktů, jež jsou tvořeny komunitami vývojářů a nabízejí své produkty zdarma k použití po souhlasu s některou s licencí pro používání opensource (např. GNU, GPL, nebo osobní licence). Dalším kritériem bývá rychlost a efektivita nabízeného produktu v závislosti na očekávané zátěži a návštěvnosti portálu. Nevyplatí se rozhodnout se pro první nabízený produkt, pokud není vhodný pro aplikaci našeho typu. Nedostupnost služby, způsobená přetížením webového/databázového serveru, zákazníky doslova rozčiluje. Potřeba rychlé odpovědi se stala v současnosti téměř povinností, a proto je dobré volbu pečlivě zvážit. Mezi nejznámější volně dostupný software pro tvorbu a publikaci webu patří: î Databázový server : MySQL Server î Webový server : Apache î Serverový skriptovací jazyk : PHP î Vývojové prostředí : editor PSPad + webový prohlížeč

Pro publikaci portálu v síti Internet lze využít např. vlastní technické prostředky, což v případě menšího projektu může být neúnosně nákladné. V takovém případě je vhodné využít tzv. webhostingové služby, které nabízejí za měsíční paušál v řádu stovek korun českých možnost uložení Vaší aplikace na jejich serverech. Výhodou je dynamická technická podpora a přístup k širokému spektru technologií, často v aktuálních verzích. Nevýhodou bývá omezené množství přenesených dat mezi uživateli a serverem, na což je potřeba při návrhu aplikace pamatovat a omezit přenos dat na minimum. Největším problémem je bohužel možnost čtení Vašich zdrojových kódů a v konečném důsledku i krádež Vašeho originálního řešení.



13

4. Popis technologií

Implementace aplikace je provedena kombinací několika technologií, jejichž popis naleznete v této kapitole. Všechny technologie spojuje možnost bezplatného použití.

4.1.1. HTML 4.01 Transitional HTML - HyperText Markup Language je základní technologie pro tvorbu internetových aplikací. Původní myšlenkou tvůrců HTML bylo vytvořit jazyk pro popis formátování (tzv. markup) s možností propojování dokumentů pomocí odkazů (tzv. hypertext, hyperlinks). Tento model se vysoce osvědčil a přetrvává dosud, patrně přetrvá ještě řadu let. Během let se tvář HTML měnila a v současnosti prochází nejrazantnější změnou a to syntézou s jazykem XML. Výsledkem je jazyk XHTML, který již dodržuje přesná pravidla pro psaní značkovaných dokumentů. Ve své práci jsem se rozhodl pro použití HTML verze 4.01. Validace stránek je navržena vůči verzi Transitional.

4.1.2. CSS - Cascading Style Sheets Neshoda implementací formátovacích značek starších verzí HTML vyústila v nutnost definitivně odloučit styl dokumentu od jeho obsahu. Standardem pro tento účel se stalo CSS. Jde o jednoduchý jazyk pro definici vzhledu jednotlivých komponent HTML.

Kapitola 4. Popis technologií

14 Syntaxe zápisu se na první pohled velice podobá jazykům z rodiny C/Java. Je velice jednoduchá a intuitivní:

pravidlo_pro_vyber_prvku { jmeno-atributu1 : hodnota1; jmeno-atributu2 : hodnota2; ... } Pravidlu pro výběr prvku (prvků) říkáme selektor. Na jeho místě může stát název HTML značky, třídy prvků (specifikované pomocí atributu class u značky v HTML kódu) nebo pomocí jedinečného identifikátoru (atribut id).

selektor HTML značka

přiklad zápisu body { color : red; }

třída prvků

.nadpis { font-weight : bold; }

konkrétní prvek

#logo { width : 234px; }

Tabulka 4.1 – příklady zápisu CSS selektorů

4.1.3. JavaScript / JScript Jde o skriptovací (interpretovaný) jazyk, který se syntaxí podobná jazykům rodiny C/Java. Poskytuje přístup k objektovému modelu stránky (tzv. DOM) a k jeho částečným úpravám. Při načítání stránky umožňuje dynamický zápis podobně jako PHP, ale pouze z informací dostupných na straně klienta. Jeho nejdůležitějším využitím je zjišťování platnosti údajů zadaných během vyplňování položek ve formulářích. Dále nachází využití při tvorbě dynamicky se měnících stránek v kombinaci s technologií CSS, která je také součástí DOM.



15

4.1.4. PHP Původním výkladem této zvláštní zkratky bylo Personal Home Page, který byl časem přepracován na Hypertext Preprocessor. Nový výklad mnohem lépe nastiňuje, k čemu je PHP vhodné. PHP je netypový skriptovací jazyk navržený pro generování HTML stránek. Syntaxe je opět velice podobná jazykům rodiny C. Zásadním rozdílem je zápis proměnných, ve tvaru $promenna. PHP při interpretaci nahrazuje všechny výskyty

proměnných

jejich

hodnotami.

Zajímavostí

je

možnost

zápisu

$$promenna, kdy vznikne nová proměnná se jménem obsaženým v proměnné $promenna. Hodnoty přijaté od uživatele jsou k dispozici v dvou polích podle použité metody při posílání dat (get, post). Jsou to pole $_GET a $_POST. Pokud potřebujeme některé údaje uchovat po dobu delší než je délka jednoho http dotazu, nabízí nám PHP možnost tzv. sezení (sessions). Hodnoty jsou uchovávány v asociativním poli $_SESSION. Zrušení hodnot uložených pro jedno sezení (ukončení sezení) lze provést buď implicitně v programu, nebo stačí uzavřít okno prohlížeče na straně uživatele.

4.1.5. Apache web server Jde nejspíše o nejpoužívanější nekomerční webový server na světě. Díky jeho výborné integraci s PHP se jedná o pravděpodobně nejlepší volbu při volbě webového serveru. Nevýhodou pro nezkušeného uživatele je relativně složitá konfigurace pomocí přímé editace konfiguračních souborů jak PHP, tak Apache.

Kapitola 4. Popis technologií

16



17

5. Architektura aplikace

Má aplikace je postavena na tří-vrstvovém modelu webové aplikace KLIENTSERVER-DATABÁZE. Jednotlivé komponenty jsou navrženy tak, aby odpovídaly předpokladu co největšího zabezpečení systému proti útoku zvenčí.

SERVER KLIENT

DATABÁZE

PHP

JavaScript validace formulářových dat

Logika serverové aplikace

GUI

PHP validace dat

(HTML+CSS)

Obrázek 5.1 – třívrstvá architektura webové aplikace

î Klient Klientská strana aplikace zabezpečuje čtyři hlavní úlohy: î Prezentace dat formátovaných pomocí HTML a stylovaných pomocí CSS î Odeslání dat na server pomocí formulářů î Validace odesílaných formulářových dat pomocí JavaScriptu î Navigace mezi tématy pomocí hypertextových odkazů

î Validace odesílaných formulářových dat pomocí JavaScriptu Zřejmě nejzajímavější částí klientské strany aplikace je jednoznačně kontrola správnosti odesílaných dat pomocí formuláře. Kontrolu integritních omezení provádím pomocí porovnání s regulárním výrazem a to na každém formulářovém prvku. Před odesláním formuláře je provedena konečná kontrola a pokud jsou všechna data zadána správně,

Kapitola 5. Architektura aplikace

18 formulář se odešle. V opačném případě je uživateli naznačeno, která políčka jsou vyplněna nesprávně.

î Server Serverová aplikace zajišťuje vyřizování žádostí o zobrazení konkrétních dat požadovaných uživateli, validaci platnosti přijímaných/odesílaných dat, komunikaci s databází, rozumné sdělování chyb a akutních závad systému. K tomu bylo třeba vytvořit sadu funkcí zabezpečujících tyto služby.

î Validace přijímaných/odesílaných dat Validace dat na serverové straně pomocí regulárního výrazu probíhá stejně jako na straně klientské. Navíc jsou data, která nelze jednoduše validovat (např. textové vstupy), ošetřena proti pokusům o útok pomocí funkcí PHP: HTMLSpecialChars - převede speciální HTML znaky na znakové entity, čímž zamezíme vložení parazitního HTML kódu do stránek při zobrazování uložených dat uživateli addslashes - provede převod nebezpečných znaků jako jsou apostrofy a další, které by mohly být využity pro útok typu SQL injection, na escape sekvence přidáním zpětného lomítka před znak

î Volba tématu pro zobrazení uživateli Pro volbu obsahu stránky, která je

poskytnuta uživateli, je využito

vkládání rozhodované na základě hodnoty v položce asociativního pole $_GET[“topic”], do kterého je hodnota předána z dotazovací části URL (home.php?topic=tema). Viz uvedený příklad níže

switch($_GET[“topic”]){ case “tema” : require “nejake_tema.php”; }



19

î Komunikace s databází a výpis z databáze API jazyka PHP nabízí široké spektrum funkcí pro komunikaci s databází MySQL, ale každý dotaz do databáze znamená opakované vypisování stejného kódu. Tudíž jsem se rozhodl pro návrh vlastní třídy pro komunikaci s databází a standardizovaný výpis z ní. Má třída SQL nabízí rozhraní pro zjednodušené dotazování s využitím template souborů pro výpis dat. SQL dotaz se předává objektu pomocí konstruktoru třídy. Vyhodnocení dotazu proběhne pomocí metody enum() a následný výpis získaných dat pomocí metody put($template_file). Struktura template souboru je libovolná. Data z řádku databáze jsou přístupná v poli $zaznam indexovaném od nuly.

î Příklad: Fragment souboru pokus.php enum(); $sql->put(“pokus_temp.php”); ?>

Obsah souboru pokus_temp.php
”> email: ”>

Kapitola 5. Architektura aplikace

20

î Sdělování chyb a akutních závad Nastavení PHP do režimu, ve kterém se nezobrazují chybové hlášky (pomocí

error_reporting(0)),

nám

dává

možnost

sdělovat

chyby

dle vlastních potřeb. Implicitní nastavení PHP je sice výhodné z hlediska návrhu a ladění aplikace, ale z bezpečnostního hlediska může znamenat problém, protože potencionální útočník by se z hlášky mohl dozvědět jména důležitých součástí systému a při případném útoku by mohl získat důvěrné informace, například ohledně přístupových údajů k databázi. Pokud není k dispozici přístup k databázi, je uživatel upozorněn hláškou, že není dostupná komponenta systému a systém se tak nachází v režimu omezené funkčnosti. Pokud není k dispozici soubor potřebný pro některou z komponent, je v místě, kde by se měla nacházet požadovaná součást, zobrazena hláška o chybějící součásti. Uživateli je nabídnut kontakt na provozovatele.

î Architektura komponent systému Diskusní fórum Je realizováno jako stromová struktura ukládaná do databáze. Každé téma zná svého předchůdce, tudíž výběr témat na určité úrovni provedeme jako dotaz na všechna témata s předchůdcem odpovídajícím požadované úrovni. Hodnotu nula má virtuální téma, které tvoří kořen struktury. Seznam diskusí je organizován podobným způsobem. Příspěvky si pamatují číslo diskuse, do které patří.

Komunikační systém Realizován jednoduchou tabulkou s id odesílatele a příjemce jako cizími klíči. K dispozici je předmět zprávy pro rychlejší přehled.

Rezervační systém Realizován tabulkou Termin, kam lékaři zapisují volné termíny k rezervaci. Dále je vedena tabulka Rezervace, která obsahuje uid uživatele a id požadovaného termínu.



21

6. Analýza a návrh aplikace Kapitola má za úkol provést analýzu a návrh systému. V úvodní části se zaměřuji na rozbor součástí, které je třeba naimplementovat. Návrhu databáze se věnuji hned poté. Součástí analýzy je také funkční model a sada scénářů použití. Konec kapitoly je věnován návrhu grafického uživatelského rozhraní a popisu základních proměnných důležitých pro běh aplikace. Z hlediska programátora navrhujeme tyto části: î Aplikační logiku î GUI aplikace î Databázi Z pohledu uživatele je pak třeba naprogramovat tyto součásti: î Menstruační kalendář î Komunikační systém î Rezervační systém î Diskusní fórum

î Menstruační kalendář Kalendář nabídne možnost zaznamenávat si údaje o menstruaci, tj. datum, dobu trvání a doplňující informace. î Komunikační systém Použití pro psaní krátkých zpráv mezi uživateli. î Rezervační systém Pokud chce, může lékař nabídnout dívkám rezervaci v určité termíny.

Kapitola 6. Analýza a návrh aplikace

22

î Diskusní fórum Poskytuje možnost diskutovat na různá, dívkami vymyšlená témata. Z hlediska bezpečnosti je třeba zabezpečit aplikaci proti co největšímu počtu možných útoků.

6.1. Volba a návrh databáze Databáze informačního systému (IS) je jeho již téměř nezastupitelnou součástí. K realizaci ukládání dat je možné použít také přímo funkce filesystému, které nabízí každý, ať již klasický, či interpretovaný programovací jazyk. Vysoká režie přístupů k datům, neefektivita řešení, omezená možnost přesunout správu dat na samostatný server a navíc rozsáhlá bezpečnostní rizika vyžadují s vysokou pravděpodobností mnohem více času a prostředků než realizace samotného IS. Pro realizaci se jeví nejvhodnější relační databáze díky její jednoduchosti a na druhé straně eleganci řešení, kterou relační přístup nabízí. Z hlediska výběru databázového stroje máme k dispozici řadu komerčních i opensource produktů. Konkrétní výběr závisí na konkrétním případě. Pro účely bakalářské práce se nejvíce hodí bezplatné opensource řešení, které nabízí většinu funkcí komerčních produktů a často také bezproblémovou komunikaci s jinými potřebnými opensource komponentami. Na typu databázového stroje závisí také dialekt jazyka SQL, který budeme používat.



23

6.2. Struktura databáze (datový model) a význam jednotlivých atributů v tabulkách:

Obrázek 6.1 – datový model aplikace

Users: Atribut id login pass email status regmail showmail foto typ

Datový typ Integer String String String String

Význam Id uživatele Přihlašovací jméno Heslo šifrované md5 Email uživatele On-line/off-line Zda obdržel email o String registraci Zda zobrazovat email Small Integer uživatele String URL fotky uživatele Integer Typ uživatele (dívka, lékař) Tabulka 6.1 – přehled atributů tabulky Users


24

Kalendář: Atribut Id uid year month day day_count comment

Datový typ Význam Integer Id záznamu Integer Id uživatele Integer Rok Integer Měsíc Integer Den Integer Počet dní menstruace String Doplňující informace Tabulka 6.2 – přehled atributů tabulky Kalendář

Zprávy: Atribut id from to subject text date seen

Datový typ Význam Integer Id zprávy Integer Id odesilatele Integer Id příjemce String Předmět zprávy String Text zprávy Long Integer Timestamp času odeslání Small Integer Jde o novou zprávu? Tabulka 6.3 – přehled atributů tabulky Zprávy

Téma: Atribut id parent name icon

Datový typ Význam Integer Id tématu Integer Id nadřazeného tématu String Název tématu String Ikona tématu Tabulka 6.4 – přehled atributů tabulky Téma

Fórum: Atribut Id_f Id_t uid date name about

Datový typ Význam Integer Id fóra Integer Id nadřazeného tématu Integer Id zakladatele fóra Long Integer Timestamp založení String Název fóra String Popis fóra Tabulka 6.5 – přehled atributů tabulky Fórum



25

Příspěvek: Atribut Id_p Id_f uid date subject text

Datový typ Význam Integer Id příspěvku Integer Id fóra kam příspěvek patří Integer Id autora příspěvku Long Integer Timestamp příspěvku String Předmět příspěvku String Text příspěvku Tabulka 6.6 – přehled atributů tabulky Příspěvek

Termín: Atribut id_term uid year month day hour minute

Datový typ Význam Integer Id termínu Integer Id uživatele (lékaře) Integer Rok Integer Měsíc Integer Den Integer Hodina Integer Minuta Tabulka 6.7 – přehled atributů tabulkyTermín

Rezervace: Atribut id id_term uid_p comment

Datový typ Význam Integer Id rezervace Integer Id termínu Integer Id uživatele (pacienta) String Zpráva pacienta pro lékaře Tabulka 6.8 – přehled atributů tabulky Rezervace


26

6.3. Funkční model Navrhovaný systém se skládá z několika samostatných součásti a je tedy nutno navrhnout jej tak aby spolu jednotlivé komponenty logicky souvisely. Je proto nutné nadefinovat vztahy mezi komponentami a uživateli a podle nich sestavit funkční model, jež přehledně popíše tuto vzájemnou souvislost. Při návrhu komunikačního systému simulujeme potřebu sdělit druhé straně nějakou, pravděpodobně stručnou, jasnou a soukromou zprávu. Komponenta Zprávy tudíž musí nabídnout možnost: •

sestavit zprávu

•

odeslat zprávu

•

doručit zprávu příjemci

Operace, které tedy realizují komunikaci jsou: •

Psaní zprávy + její odeslání (tedy vztah Uživatel – píše – zprávy)

•

Doručení zprávy + její čtení (tedy vztah Uživatel – čte – zprávy)

Menstruační kalendář je funkcí navrhovanou pro konkrétní typ Uživatele a to konkrétně pro Dívku. Z principu očekáváme funkčnost založenou na opakované volbě jedné z operací: •

Vložení nového záznamu

•

Editace stávajícího záznamu

•

Smazání záznamu

•

Prohlížení záznamů (Vztah Dívka – si prohlíží - Kalendář)

Vztah Dívka – si vede - Kalendář

Jak je vidět, sloučením prvních tří možností vznikl pouze jeden vztah a to vztah zastřešující tyto pojmy jako Vedení kalendáře. Prohlížení kalendáře je pojem samovysvětlující . Rezervační systém si představíme zjednodušeně jako Termín. Uživatel kategorie Lékař je zodpovědný za operace: •

vypisování termínů (Vztah Lékař – vypisuje - Termín)

•

prohlížení zarezervovaných termínů (Vztah Lékař –zjišťuje obsazení – Termínu)



27 Uživatelka (tedy Dívka) provádí tyto operace: •

rezervuje se na/ruší si termín (Vztah Dívka – (Za/ode)pisuje si – Termín)

•

vyhledává volné termíny

Diskusní

fórum

se

chová

podobně

jako

systém

souborů.

Každé

téma (~adresář) může obsahovat další podtémata (~podadresáře) a nebo také samotné diskuse (~soubory). Obdobně jsou podobné také operace: •

prohlížení ~ výpis obsahu adresáře

•

čtení ~ otevírání souborů

•

vytváření ~ nový soubor / adresář

•

přispívání ~ zápis do souboru

Pak odpovídající vztahy jsou: •

Uživatel – čte – Fórum

•

Uživatel – přispívá do – Fóra

•

Uživatel – vytváří – Fórum

•

Uživatel – prohlíží – Fóra

UŽIVATEL vyhledává

píše Dívka

(Za/ode)pisuje si Termín

zjišťuje obsazení vypisuje

čte Zprávy Lékař

píše čte

Obrázek 6.2 – funkční model aplikace I.


28

UŽIVATEL Diskusní fórum

čte, prohlíží

vede si

Menstruační kalendář

Dívka prohlíží

vytváří, přispívá Lékař

Obrázek 6.3 – funkční model aplikace II.

6.4. Scénáře použití Zásady pro použití se řídí v celém projektu na základě těchto modelů: •

Model získávání informací

•

Model zápisu informací

•

Model modifikace informací

•

Model odstranění informací

Tyto čtyři obecné modely lze popsat názorně pomocí čtyř typických operací, které

lze

v informačním

systému

vykonat.

U

ostatních

již

jen

zmíním,

o který z modelů se jedná.

6.4.1.

Přihlašování

Proces přihlášení pozůstává z několika kroků. Prvním z nich je správné vyplnění formulářových položek k tomu určených. Uživatel zadá své identifikační údaje a odešle je na server. Před odesláním je na straně klienta zkontrolována platnost vložených dat vzhledem k integritním omezením (validace) a v případě jejich správnosti jsou data konečně odeslána. V opačném případě je uživatel upozorněn na neplatnost zadaných údajů. Na straně serveru proběhne opětovná validace dat a pokud je vše v pořádku vyžádají se z databáze údaje potřebné k identifikaci přihlašované osoby. Pokud je ověřena identita uživatele je mu navrácena informace o úspěšném přihlášení



29 a uživatel je přihlášen do systému. V opačném případě je vyzván k opětovnému zadání údajů.

6.4.2.

Registrace

Registrace do systému má také několik etap. Nejprve je nutné vyplnit všechny povinné údaje a zvolené nepovinné. Před odesláním dat na server je provedena validace dat. Pokud jsou nalezena nevalidní data, je uživatel upozorněn, aby údaje opravil. V opačném případě jsou data odeslána na server. Na straně serveru je provedena opětovná validace a pokud je vše v pořádku, uložíme do databáze záznam o novém uživateli. V opačném případě je uživatel srozuměn s chybou, které se dopustil a má možnost ji opravit a zkusit se zaregistrovat znovu.

î Scénáře vedení Menstruačního kalendáře 6.4.3.

Modifikace údaje

Nejprve jsou z databáze načtena původní nezměněná data a jsou vložena do formulářových prvků. Uživatel provede úpravu údajů a odešle formulář. Těsně před odesláním se provede validace odesílaných dat. Pokud jsou data validní formulář odešleme ke zpracování, jinak upozorníme uživatele na nesprávnost vstupních dat. Na serverové straně provedeme opět kontrolu validnosti dat. V případě validních dat provedeme modifikaci údajů. V opačném případě upozorníme uživatele na nesprávnost vstupních dat.

6.4.4.

Smazání údaje

Pokud si uživatel přeje smazání údaje z databáze,uskuteční tak volbou příslušného tlačítka/odkazu. Následně je vyzván na potvrzení žádosti o smazání. Tím předejdeme nechtěnému okamžitému smazání záznamu. Po potvrzení jsou data z databáze odstraněna.


30

6.4.5. Uživatelka

Zápis nového záznamu vyplní

informace

potřebné

pro

zapsání

nového

záznamu.

Při odeslání je provedena klientská kontrola odesílaných dat. Pokud proběhne v pořádku jsou data odeslána na server. V opačném případě je uživatel informován o chybně zadaných položkách. Na serverové straně je provedena další kontrola dat. Pokud jsou data validní, zapíšeme do databáze údaj o novém záznamu. V opačném případě upozorníme uživatele na nesprávnost vstupních dat.

6.4.6.

Výpis záznamů

Uživatelka zvolí rok pro výpis záznamů z kalendáře. Na straně serveru se zkontroluje validnost roku a v případě úspěchu se uživatelce zobrazí požadovaná data. V opačném případě dojde k zobrazení aktuálních záznamů.

î Scénáře Psaní Zpráv 6.4.7.

Nová Zpráva

Uživatel zadá uživatelské jméno příjemce zprávy a vyplní položky náležející zprávě samotné. Před odesláním se provede validace uživatelského jména příjemce. Pokud je v platném formátu je požadavek na odeslání zprávy poslán na server. Jinak je třeba zadat uživatelské jméno znovu. Na straně serveru je kontrolována validnost a existence uživatele. Pokud není uživatel nalezen nebo pokud není zadáno platné uživatelské jméno, není zpráva odeslána příjemci.

6.4.8.

Smazat Zprávu

Uživatel zvolí možnost smazání položky. Před samotným smazáním je dotázán jestli si je vědom důsledků svého konání. Pokud zvolí možnost „ano“ bude záznam definitivně smazán.



31

î Scénáře Diskusního fóra 6.4.9.

Vytvoření nového tématu

Uživatel vyplní potřebná data a odešle formulář. Příchozí data nejsou validována, ale

jsou

zabezpečena

proti případným nebezpečným znakům.

Nové téma je vytvořeno, pokud neexistuje jiné se stejným jménem.

6.4.10.

Vytvoření nové diskuse

Uživatel vyplní potřebná data a odešle formulář. Příchozí data nejsou validována, ale jsou zabezpečena proti případným nebezpečným znakům. Nová diskuse je vytvořena, pokud neexistuje jiná se stejným jménem a popisem.

6.4.11.

Zapsání nového příspěvku

Uživatel vyplní potřebná data a odešle formulář. Příchozí data nejsou validována, ale

jsou

zabezpečena

proti případným nebezpečným znakům.

Nový příspěvek je přidán, pokud neexistuje jiný se stejným textem a popisem.

6.4.12.

Prohlížení témat

Uživatel se pomocí odkazů pohybuje mezi tématy. Kliknutím na název tématu se zpřístupní obsah tématu.

6.4.13.

Čtení příspěvků

Vstup do diskuse je realizován také pomocí odkazu. Vstup se provede kliknutím na jméno diskuse.

î Scénáře Rezervace termínu 6.4.14.

Vytvoření nové rezervace

Uživatelka zvolí položku Rezervace. Zvolí si zaměření lékaře. Z vybraných si podle města vybere nejvhodnějšího. Zvolí si rok a měsíc návštěvy. Pokud jsou v databázi na tento měsíc nějaké termíny, vypíší se adekvátní dny. Zvolením dne se zobrazí možné hodiny příchodu.


32 Po výběru hodiny již stačí potvrdit rezervaci. Pokud zvolí uživatelka negativní odpověď, nic nebude rezervováno.

6.4.15.

Zrušení rezervace termínu

Rezervaci není možné zrušit pokud do návštěvy lékaře zbývají méně tři dny. Pokud je tato podmínka splněna, je možno rezervaci zrušit. Uživatelka zvolí možnost „zrušit“. Je dotázána, zda si je jista svou volbou. Pokud zvolí ano, je rezervace zrušena a termín uvolněn.

6.4.16.

Prohlížení vlastních rezervací

Uživatelka zvolí Prohlížení rezervací. Zobrazí se seznam rezervací seřazených vzestupně podle data termínu.

î Scénáře Vypsání termínu 6.4.17.

Vypsání nového termínu

Lékař sekvencí odkazů zvolí rok, měsíc a konkrétní dny, kdy chce vypsat termíny. Následně zvolí počet termínů na den, jejich délku a hodinu, od které mají být termíny vypsány.

6.4.18.

Prohlížení obsazení termínů

Lékař zvolí Prohlížení rezervací. Zobrazí se seznam rezervací seřazených vzestupně podle data termínu.

6.4.19.

Zrušení rezervace termínu

Lékař nemá právo zrušit termín pokud do dne termínu zbývá méně než 24. Lékař zvolí položku „zrušit“ u termínu. Je následně dotázán zda svou volbu myslí vážně. Pokud je jeho volba pozitivní, je rezervace zrušena.



33

6.5. Návrh GUI Jelikož je navrhovaný informační systém zamýšlen jako webová aplikace, bude její implementace provedena pomocí kombinace několika internetových technologií (HTML, CSS, PHP, MySQL). GUI takovéto aplikace je pak tvořeno sadou statických, nebo dynamicky generovaných dokumentů propojených hypertextovými odkazy. Styl grafického ztvárnění internetové aplikace požadovaného typu se během let postupně vyvíjel a v současnosti se nabízí několik běžně používaných variant, ze kterých si vývojář při návrhu vzhledu může zvolit. Mezi nejběžnější patří strukturované modulární formy.

I.

Klasický 3 - rámcový design (obr. X.X.X) Jedním z prvních způsobů, který se začal používat pro přehledný design,

je rozdělení vzhledu a funkcionality do 3 logických bloků: (a) Horní vodorovný pruh obsahující logo stránek (nebo firmy, instituce, atd.) a také další nejnutnější stručné informace důležité pro jasnou identifikaci a rychlý přehled o zaměření webu. (b) Navigační menu, umístěné v levé části obrazovky, obsahuje odkazy na nejdůležitější témata, která tvoří informační kostru stránek. (c) Hlavní

část,

ve

které

se

nachází

naprostá

většina

funkcionality

a informačního obsahu, je situována napravo od menu a zabírá převážnou část obrazovky Pojem “rámcový” pochází z původní implementace tohoto rozložení pomocí rámců,

který

byl

později

nahrazen

rozvržením

tabulkovým

a

nakonec

nejmodernějším, v současnosti používaným stylováním v CSS.


34

(a) LOGO + nejnutnější informace (b) MENU (c) HLAVNÍ ČÁST Nese převážnou část informačního obsahu stránek

Obrázek 6.4 –Klasický 3 rámcový web

II.

Rozšířený 4 - rámcový design (obr. Y.Y.Y) Potřeba sdělit uživateli další doplňující informace, případně mu nabídnout další

funkcionalitu vede k rozšíření 3-rámcového modelu o nový blok. Jeho umístění se jeví nejužitečnější v pravé časti obrazovky (d). Nejčastěji se s ním můžeme setkat u stránek menších organizací a školních zařízení.

(a) LOGO + nejnutnější informace (d) INFO

(b) MENU (c) HLAVNÍ ČÁST Nese převážnou část informačního obsahu stránek

Doplňující informace a funkce

Obrázek 6.5 – rozšířený 3 rámcový web



35

III.

Komplexní 4 - rámcový design (obr. Z.Z.Z) Vhodnou realizací předešlého designu lze dosáhnout komplexnost a modularitu

internetové aplikace. Bloky původně určené ryze pro nesení informačního obsahu využijeme jako kontejnery pro bloky nižší úrovně, jejichž případný přesun se tímto stane triviální otázkou. Implementace pomocí CSS a dodržení určitých pravidel (viz kapitola Implementace) dává tomuto rozložení velké možnosti rozšiřování funkcionality

i

optimalizace

pro

zpřístupnění

webu

co

nejširší

skupině

předpokládaných uživatelů.

Podblok8 (info?)

(a) BLOK1 Podblok9 (extra menu?)

(c) BLOK3

(b) BLOK2

(d) BLOK4

Podblok5 (banner?)

Podblok1 (menu?)

Podblok3 (zprávy?)

Podblok6 (novinky?)

Podblok2 (login?)

Podblok4 (reklama?)

Podblok7 (Anketa?)

Obrázek 6.6 –komplexní web

6.5.1. Volba designu Z hlediska požadavků na aplikaci se jako nejužitečnější jeví třetí jmenovaný Komplexní 4-rámcový design, jelikož vzhledem k zachování možnosti dynamického přidání, změny, či odebrání služby je modulární implementace výhodou.


36

6.5.2. Logické rozčlenění bloků a prvků GUI Dle zvoleného designu z předešlé části rozčleníme GUI celkově na 5 logických oblastí: (a) Horní část s horizontální navigační nabídkou. (b) Levá část pro vertikální navigační nabídku a přihlašovací formulář. (c) Centrální kontejner reprezentující hlavní informační část s konkrétním požadovaným obsahem. (d) Pravá část pro diskusní fórum. (e) Spodní proužek (patička) s informacemi o autorovi

(a) (b)

(d) (c)

(e)

Obrázek 6.7 – logické rozčlenění stránky

Bloky GUI : (a) Horní část s horizontální navigační nabídkou

LOGO

HORIZONTAL_MENU H_MENU_ITEM1

H_MENU_ITEM2 H_MENU_ITEM3

Obrázek 6.8 – vrchní část stránky Internetový portál pro dospívající dívky


37

Název

Funkce

Reakce na akci

LOGO

Vizuální Navigační

Kliknutím návrat na hlavní stránku

HORIZONTAL_MENU

Navigační

-

H_MENU_ITEM(1-3)

Navigační

Kliknutím přechod na požadovanou stránku

Tabulka 6.9 – popis komponent vrchní části stránky (b) Levá část pro vertikální navigační nabídku a přihlašovací formulář.

Název

Funce

Reakce na akci

VERTICAL_MENU

V_MENU_ITEM1 V_MENU_ITEM2

VERTICAL_MENU

Navigační

-

V_MENU_ITEM(1-3)

Navigační

Kliknutím přechod na požadovanou stránku

LOGIN_FORM

Navigační Bezpečnostní

-

LABEL(1-2)

Informační

TEXTFIELD1

Vstup dat

Po aktivaci lze zadat data

PASSWORD1

Vizuálně bezpečný vstup dat

Po aktivaci lze zadat data

BUTTON1

Navigační Odeslání dat

Kliknutím odeslání dat

V_MENU_ITEM3

LOGIN_FORM

LABEL1 TEXTFIELD1

LABEL2 PASSWORD1

BUTTON1

Obrázek 6.9 – menu

Tabulka 6.10 – popis komponent menu


38

(c) Centrální kontejner reprezentující hlavní informační část s konkrétním požadovaným obsahem Název

Funkce

Reakce na akci

HORIZ_SUB_MENU

Navigační

-

MENU_ITEM(1-3)

Navigační

Kliknutím přechod na požadovanou podstránku

CONTENT

Kontejner pro podstránky

-

Tabulka 6.11 – popis komponent informační části HORIZ_SUB_MENU MENU_ITEM1 MENU_ITEM2

MENU_ITEM3

CONTENT

Obrázek 6.10 – informační část (d) Pravá část pro diskusní fórum. BACK_LINK

Název

Funce

Reakce na akci

T_LIST

IMG1 TOPIC_LINK1 IMG2 TOPIC_LINK2

T_LIST

Navigační

-

TOPIC_LINK(1-3)

Navigační

Kliknutím přechod do požadovaného tématu

F_LIST

Navigační

-

IMG3 TOPIC_LINK3 F_LIST IMG4

FORUM_L1

FORUM_L(1-3)

Navigační

IMG5

FORUM_L2

BACK_LINK

Navigační

IMG6

FORUM_L3

IMG(1-6)

Vizuální

Obrázek 6.11 – komponenty diskuse Internetový portál pro dospívající dívky

Kliknutím přechod do požadované diskuse Přesun o úroveň výše Obrázek

Tabulka 6.12 – popis komponent diskuse


39

6.6. Seznam předpokládaných proměnných Pro implementaci jednotlivých částí bude třeba řada proměnných. Nejdůležitější jsou ty pro navigaci mezi stránkami a také k znalosti aktuálního stavu systému.

î Globálně důležité proměnné: Tyto proměnné mají pro fungování aplikace důležitou roli, jelikož zabezpečují navigaci, nebo poskytují uchování informace o aktuálním stavu aplikace. Jméno proměnné

Funkce proměnné

Datový typ

Možné hodnoty

topic

navigační

String

název služby

karta

navigační

Mixed

číslo záložky, nebo “info“

t

navigační

Integer

id tématu diskuse

f

navigační

Integer

id diskuse

Proměnné předávané metodou GET PHP aplikaci do asociativního pole $_GET Tabulka 6.13 – popis důležitých proměnných

Jméno proměnné

Funkce proměnné

Datový typ

Možné hodnoty

username

identifikační

String

uživatelské jméno přihlášeného uživatele

id

identifikační

Integer

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

typ

identifikační

Integer

Typ Přihlášeného uživatele

String

md5 obraz nápisu na kontrolním obrázku při registraci

regiment

kontrolní

Proměnné ukládané v PHP do asociativního $_SESSION Tabulka 6.14 – popis důležitých proměnných II.


40

î Lokální proměnné: Jsou

použity

pro

konkrétní

účely

jednotlivých

komponent.

Například

při registraci bude třeba tolik proměnných, kolik položek registrace nabízí.

î Důležité vnitřní proměnné: Důležitou funkci plní proměnné typu boolean pro uchování vyhodnocení platnosti vstupních dat zadaných uživatelem. Další proměnné jsou použity k uchování dílčího výpočtu, např. při vykonávání SQL dotazu do databáze.



41

7. Implementace a testování Pro implementaci internetového portálu lze použít řadu různých technologických postupů a produktů. Dle současného modelu tvorby webových aplikací se jedná o návrh 3 částí dle následujícího obrázku:

PHP ASP JSP HTML CSS JScript

Apache MS IIS JBoss

MySQL

KLIENT

SERVER

DATABÁZE

Obrázek 7.1 – třívrstvá architektura webové aplikace Produkt „Internetový portál pro dospívající dívky” je navržen pomocí následujících technologií, u kterých je uvedena také verze, jenž byla při vývoji použita. î Klientská část: Klientská část poskytuje zejména GUI umožňující uživateli přijímat informace ze serveru a využívat služby, které nabízí server nebo také aktivní část klientské aplikace. Technologie

Popis

HTML 4.01 transitional

GUI klientské části aplikace

CSS 2

Formátování GUI

JavaScript 1.5 Aktivní prvky GUI - logika klienta Tabulka 7.1 – seznam klientských technologií

Kapitola 7. Implementace a testování

42 î Serverová část Serverová část nabízí zpracování požadavků od klienta a je zodpovědná za generování HTML stránek s výsledkem požadavku. Při chybě má za úkol upozornit klienta, nebo mu nabídnout přijatelnou alternativu. Technologie

Popis

Apache/1.3.24

Webový server

PHP 4.3.1 Logika serverové části aplikace Tabulka 7.2 – seznam serverových technologií î Databáze Technologie MySQL Server 4.1

Popis Databázový server Tabulka 7.3 – databáze

Největší výhodou použitých technologií jsou nulové náklady na jejich pořízení. Všechny lze získat zdarma a používat je na základě souhlasu s GNU licencí. Kladem může být také využití vhodných opensource produktů pro vývoj pod J2EE (Java 2 Enterprise Edition). Příklady: î Návrhové prostředí : Netbeans IDE 5 î Technologie : Servlety, JSP î Server : JBoss Pro projekty většího rozsahu je pak rozumné využít placené produkty, u kterých po registraci získáváte také technickou podporu při potížích. Zajímavé ale je, že značná část světového webu běží právě na opensource produktech (Apache, PHP, MySQL/PostreSQL).



43

7.1. Členění kódu Zdrojový kód aplikace je rozčleněn do logických a funkčních částí podle jednotlivých bloků, které jsou umístěny každý ve svém vlastním adresáři. Tento postup dává možnost vždy bez dlouhého hledání najít, upravit nebo i případně odstranit některou ze součástí. Vstupním bodem aplikace je tradičně soubor index.html s úvodní animací. Hlavní strana je již generována pomocí PHP a jedná se o soubor home.php. Dotazovací část URL slouží k určení obsahu tohoto souboru vkládáním požadovaných komponent.

Vkládání a bezpečnost: Vkládání hlavních komponent (Kalendář, Zprávy, atd.) je realizováno pomocí rozhodování (jazykový konstrukt PHP switch($value)) o hodnotě proměnné $_GET[“topic”]. Pokud dojde k pokusu o přistup k neexistující součásti, použije se default hodnota, kterou je vložení úvodní stránky. Vkládání podstránek je ošetřeno stejným způsobem. Výjimku tvoří Diskusní fórum. Navigace mezi tématy diskuse a diskusemi samotnými se děje pomocí jejich identifikátorů v databázi. Tento postup by mohl vést ke dvěma typům útoku: 1) SQL injection Nebezpečný útok, kterým může útočník získat pomocí cíleného vložení SQL příkazů do konstruovaného dotazu důvěrné informace z databáze, nebo získat neomezená práva. 2) destrukce formátování HTML Pokud se útočník pokusí vložit některý z HTML tagů a zjistí úspěch, může předpokládat tento typ chování také na jiných místech stránek. Příkladem může být neošetřená kniha návštěv. Útočník pak


44 definitivně může na nějaký čas pozměnit chování, vzhled, ale také funkčnost webu. Každý adresář obsahující komponentu má následující obecnou strukturu:

file/dir název

popis

dir

KOMPONENTA

adresář se soubory komponenty

file

KOMPONENTA.php

hlavní strana komponenty

file

KOMPONENTA.css

stylopis komponenty

file

*.php

pomocné soubory komponenty

file

*_temp.php

šablony pro opakované generování výstupů z databáze

• místo KOMPONENTA je doplněno jméno komponenty

Tabulka 7.4 – obsah adresáře komponenty Konečné rozčlenění je následující:

file/dir název

popis

dir

forum

soubory diskusního fóra

dir

karta

soubory menstruačního kalendáře

dir

mess

soubory komunikační služby

dir

registrace

soubory registrace

dir

rezervace

soubory rezervačního systému

dir

users

soubory pro seznam uživatelů

Ostatní soubory jsou umístěny v kořenovém adresáři

Tabulka 7.5 – rozčlenění komponent



45

7.2. Harmonogram práce Etapa

Uskutečnění

Předběžná analýza požadavků

prosinec 2005 prosinec 2005 - leden 2006

Analýza možností realizace a užitečnosti Implementace stěžejních částí GUI

leden - duben 2006

Implementace jednotlivých funkčních komponent

leden - květen 2006

Ladění a alfa/beta testování

duben - červen 2006

Zdokonalení nalezených nedostatků a bezpečnostních děr

duben - červen 2006

Deployment a sledování funkčnosti Tabulka 7.6 – harmonogram práce


46

7.3. Implementace GUI Následující podkapitola zobrazuje sekvenci nasnímaných oken GUI s popisem jednotlivých jejich částí. U většiny výřezů jde o snímek centrálního kontejneru. Výjimku tvoří diskusní fórum, které se nachází v pravé části obrazovky. GUI bylo navrženo s ohledem na doporučení konsorcia W3C na tvorbu internetových aplikací a je tudíž zajištěna modularita, přehlednost a také přístupnost na většině zařízení, která podporují prohlížení HTML dokumentů. Pro uživatele s částečnou poruchou zraku je zabezpečeno možné zvětšení písma bez rozpadnutí designu stránek.

I. Úvodní strana: Vertikální navigační menu

Horizontální navigační menu

Centrální kontejner Přihlašovací formulář

Diskusní fórum

Obrázek 7.2 – úvodní strana



47

II. Kalendář î Výpis záznamů z kalendáře

Záložky pro volbu

Volba roku

Výpis položek kalendáře

Možnosti úprav

Obrázek 7.3 – výpis záznamů z kalendáře î Vložení nového záznamu

Volba data

Počet dní menstruace Doplňující informace

Obrázek 7.4 – vložení záznamu do kalendáře


48

III. Uživatelky î Seznam aktuálně přihlášených uživatelek

Status aktivity

Uživatelské jméno

Email uživatelky

Obrázek 7.5 – seznam přihlášených uživatelek

IV. Registrace î Ukázka registračního formuláře

Pokyny k registraci

Položky registrace

Obrázek 7.6 – registrace



49

V. Diskusní fórum

Návrat o úroveň výš

Témata diskusí

Seznam diskusí v tématu

Obrázek 7.7 – diskuse


50

7.4. Návrh testů a testování Podmínkou dobrého chodu aplikace je provedení souboru testů, které prověří schopnost systému čelit různým neočekávaným událostem, které mohou při reálném běhu aplikace nastat. Proces vývoje softwaru by měl zahrnovat postupné testování navrhovaných komponent a zpětné testování vznikajícího celku. Nejdůležitější testy vhodné pro tuto aplikaci jsou:

I. Testování modulů Jde o testy zaměřené na jednotlivé dílčí navrhované komponenty. Již při návrhu provádíme testování její funkčnosti. Pokud součást funguje bezproblémově,

odpadnou

problémy,

které

by

nastaly

při

jejím

zakomponování do systému a následném hledání chyby.

II. Integrační testování Přidáváním komponent k hlavnímu modulu, může dojít k nalezení chyby. Proto je důležité provést testování funkčnosti systému, po přidání každé další komponenty. Usnadní se nám hledání chyby, jelikož stav před sloučením považujeme za bezchybný a pokud přidání komponenty vyvolá nestabilitu, víme kde je třeba chybu předně hledat.

III. Validační testy Po zavedení všech modulů zkoumáme zda vůbec výsledek funkčně odpovídá našim předpokladům (případně požadavkům zákazníka).

IV. Bezpečnostní testy Jedná se o jeden z nejdůležitějších testů. Cílem je snaha za každou cenu nalézt všechny bezpečnostní mezery v návrhu. Provedení takovéto akce vychází ze známých technik průniku do systému. Jejich aplikací se snažíme přivést systém do nestabilního stavu, nebo do stavu kdy jsou



51 nám přístupná za jiných okolností nepřístupná data. Je podezřelé pokud se během testování žádný takovýto případ neobjeví. Může to svědčit o dvou věcech. Buď o dokonalém návrhu (méně pravděpodobné), nebo o špatně zvoleném způsobu testování.

V. Zátěžové testy Zátěžové testy otestují schopnost internetové aplikace vyrovnat se buď

s vysokou

režií

obsluhování

žádostí

nebo

s vysokým

odchozím/příchozím datovým tokem.

VI. Beta testování Testování systému za asistence uživatelů je velice užitečné. Zejména pokud uživatelé netuší, že se nacházejí v pozici beta testera a chovají se přirozeně. V případě dostatečného počtu uživatelů je pak možné využít beta testování pro testy 3., 4. a 5.

7.4.1. Návrh konkrétních testů Kapitola popisuje návrhy testů pro implementovanou internetovou aplikaci. Každý z testů má vlastní identifikační řetězec, který odpovídá identifikaci v protokolu o testování, jenž se nachází hned v další kapitole.

î Testy modulů (identifikace – MT##) Testy modulů prověří fungování jednotlivých součástí aplikace dříve než budou tyto součásti integrovány do systému.

1. Test MT01 – test korektního fungování komponenty Postup: I. Průchodem všech možných kombinací rozhodovacích bodů v programu otestujeme korektnost a funkčnost jednotlivých větví


52 II. Pro okrajové hodnoty vstupních dat otestujeme zda nedochází k zacyklení

2. Test MT02 – test sémantické správnosti návrhu komponenty Postup: I. Pro různé hodnoty korektních vstupů otestujeme zda program generuje relevantní výsledky II. Pro náhodná vstupní data otestujeme, zda jsou správně ošetřeny případné vznikající výjimky

î Bezpečnostní testy (identifikace – BT##_##) Testy zkoumající bezpečnost vytvářené aplikace testují u webových aplikací zejména schopnost odolat datům, která by mohla způsobit nestabilitu, otevřenost, nebo jiné chování, které ohrožuje běh systému.

1. Test BT01 – test odolnosti formulářů vůči nebezpečným znakům §

Subtest BT01_01 – test vkládáním HTML značek Postup: Postupně pro každý formulář provedeme následující postup: I. Do formulářového vstupního políčka vložíme vhodně zvolenou HTML značku. Vhodné jsou formátovací značky , , ale také hypertextový odkaz , jejichž vložení do stránky má okamžitě viditelný negativní dopad na vzhled webu. II. Formulář odešleme III. Pozorujeme vzniklou situaci a zaznamenáváme dopady IV. Postup opakujeme pro další políčko dle bodu I. dokud nevyčerpáme všechna políčka ve formuláři



53 Očekávané chování: Od systému očekáváme následující: •

Převedení HTML závorek < a > na HTML znakové entity < a > a tudíž výstupem v prohlížeči má být zobrazení samotné značky ().

•

Při kontrole povinných vstupních údajů, očekáváme navíc odmítnutí neplatných dat

§

Subtest BT01_02 – test vkládáním apostrofů, závorek, atd. Postupně pro každý formulář provedeme následující postup: I. Do formulářového vstupního políčka vložíme sekvenci apostrofů, závorek(nejlépe ukončujících) a uvozovek. II. Formulář odešleme III. Pozorujeme vzniklou situaci a zaznamenáváme dopady nejen na strukturu webu, ale také na podezřelé chování v souvislosti s databází (neprovedení dotazu, jiný než očekávaný výsledek) IV. Postup opakujeme pro další políčko dle bodu I. dokud nevyčerpáme všechna políčka ve formuláři Očekávané chování: Od systému očekáváme následující: •

Převedení znaků na escape sekvence (přidáním zpětného lomítka zrušíme jejich nebezpečný význam)

•

Při kontrole povinných vstupních údajů, očekáváme navíc odmítnutí neplatných dat

2. Test BT02 – test odolnosti dotazovací části URL vůči nebezpečným znakům §

Subtest BT02_01 – test vkládáním HTML značek a Subtest BT02_02 – test vkládáním apostrofů, závorek, atd.


54 Postup: Testy strukturou odpovídají testům BT01_01 a BT01_02, liší se pouze v zadávání údajů. Místo zapisování dat do formuláře, zapisujeme hodnoty do dotazovací části URL. Očekávané chování: Pro test BT02_01 je očekáváno chování jako u testu BT01_01. Podobně pak u BT02_02 jako u BT01_02.

î Validační Black-box testy (BX##) Validační testy metodou Black-box testing prověří zda jsou plněny požadavky na funkčnost systému z hlediska nároků uživatele.

1. Test BX01 – Validace procesu registrace Postup: I. Uživatel zvolí položku Registrace v hlavním menu II. Podle pokynů vyplní povinné údaje III. Odešle formulář IV. O dalším svém konání se rozhoduje dle hlášek systému Očekávané výstupy: •

V případě nesprávného zadání dat chybové hlášení

•

V případě korektních vstupních údajů úspěšná registrace

2. Test BX02 – Validace procesu vytvoření diskuse a vložení příspěvku Postup: I. Uživatel si zvolí téma, ve kterém si přeje novou diskusi II. Vyplní formulář pro vytvoření nové diskuse III. Odešle formulář IV. Vstoupí do nově vzniklé diskuse V. Vyplní formulář pro přidání příspěvku VI. Odešle formulář VII. Pozoruje výsledek svého konání



55

Očekávané výstupy: •

V případě správného postupu vytvoření nové diskuse

•

V opačném případě informace o duplicitě jména diskuse nebo o chybně zadaných parametrech

•

V diskusi se očekává vložení nového příspěvku

•

Nevložení pouze v případě duplicity příspěvku

7.4.2. Protokol o provedeném testování Protokol o provedení testování podává informaci o testech jež byli prováděny za účelem zjištění funkčnosti systému. Význam zkratek ve sloupci Id testu, je vysvětlen v předešlé kapitole. Z důvodu častého opakování testu modulů (MT01, MT02) ve všech verzích není toto testování zahrnuto do protokolu. Konkrétně tento typ testu přinesl největší úsporu času při zpětném ladění aplikace. Verze produktu: Pracovní Alfa : testovaná ve spolupráci s Táňou D. Beta 1 – 3 : různé verze pokusně zveřejněné verze Finální : konečná verze


56

Id testu

Verze

Datum

Testoval

BT02_02

Pracovní

29. 5. 2006

M. Prostredník

OK

þ Vše v pořádku

BX01

Alfa

1. 6. 2006

Táňa D. / M. Prostredník

OK

þ Vše v pořádku

BX02

Alfa

1. 6. 2006

Táňa D. / M. Prostredník

OK

þ Vše v pozadku

BT02_01

Beta

3. 6. 2006

M. Prostredník

OK

ý Závady

BT02_01

Beta 2

4. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BT01_01/02

Beta 3

14. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BT02_01/02

Beta 3

14. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BX01

Beta 3

14. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BX01

Finální

23. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BX02

Finální

23. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BT01_01/02

Finální

24. 6. 2006

M. Prostredník

OK

þ Vše v pořádku

BX = Black-box test

Průběh

Výsledky

BT = Bezpečnostní test

Tabulka 7.7 – protokol o provedeném testování



57

8. Závěr:

Hlavním cílem mého projektu bylo zanalyzovat, navrhnout a naimplementovat specifickou internetovou aplikaci zaměřenou na konkrétní věkovou skupinu a pohlaví. Internetový portál pro dospívající dívky je projekt, který si nárokuje získat stabilní klientelu dívek, jímž aspoň trochu záleží na jejich zdraví a mají tedy zájem vést si osobní menstruační kalendář. Jeho úspěšné naimplementování a zakomponování do systému je pravděpodobně jedním z největších přínosů projektu. Portál nabízí registraci dívkám a také lékařům, kteří jim mají zájem pomoci v nesnázích nejen přes internet, ale také osobně při návštěvě ordinace. Diskusní fórum zabezpečuje všem uživatelům možnost sdělit svůj osobní názor na nejrůznější témata, která si vymýšlejí podle vlastních představ. Grafické ztvárnění aplikace se podařilo plně uzpůsobit každodennímu použití, protože jeho vzhled je pojat neutrálně a nevybízí tak cizí bloudivé oči k tomu aby Vám „zíraly“ přes rameno. Aplikace je rozvržena přehledně a podává informace v co nejvíce srozumitelné formě. Pokusně zveřejněná verze si během několika málo měsíců získala bezmála 70 uživatelek a je třeba zdůraznit, že projekt se prezentuje pouze zařazením do katalogu u dočasného poskytovatele freewebových služeb. Tento zájem dívek potvrzuje užitečnost aplikace. Posílání zpráv bylo navrženo s ohledem na jednoduchost a rychlost a podle tohoto předpokladu také funguje. Rezervační systém je naimplementován, ale zatím není ještě zveřejněn. Jeho funkcionalita je však stoprocentní a ovládání jednoduché. Pokud tedy projeví lékaři zájem, není důvod proč by se služba neměla ujmout. Z hlediska

bezpečnosti

se

podařilo

dosáhnout

minimalizace

rizik

jak

pro uživatele tak pro provozovatele webu. Celkově se dá zkonstatovat, že se projekt povedlo zrealizovat na vysoce přijatelné úrovni.

Kapitola 8. Závěr

58



59

9. Seznam literatury [1] Pokyny pro psaní bakalářských a magisterských závěrečných prací na katedře počítačů .https://info336.felk.cvut.cz/. [2] PHP – PHP Manual – hlavní stránka .http://www.php.net/manual/en/. [3] MySQL – MySQL AB – the World’s most popular open source databáze – hlavní stránka .http://www.mysql.com/. [4] MediaWiki – MediaWiki .http://www.mediawiki.org/. [5] Plone – A user/friendly and powerful open source Content Manaegment System .http://www.plone.org/. [6] X36WWW – hlavní stránka .http://amun.felk.cvut.cz/x36www/.

Kapitola 9. Použitá literatura

60



61

A. UML diagramy î Scénář použití při přihlašování

Obrázek A.1 – Sekvenční diagram přihlašování

Příloha A. UML diagramy

62

î Scénář použití pro registraci

Obrázek A.2 – Sekvenční diagram registrace



63

B. Seznam zkratek CSS GUI HTML PHP SQL

Cascading Style Sheet Graphical User Interface Hypertext Markup Language Hypertext Preprocessor Simple Query Language

C. Katalog požadavků î Funkční požadavky: •

Diferencované přihlašování uživatelů = 2 uživatelské role

•

Menstruační kalendář pro zaznamenávání údajů o menstruaci

•

•

Intuitivní ovládání

•

Možnost tisku ročního přehledu

Komunikační centrum pro posílání zpráv mezi uživateli •

•

•

Dynamické rozhraní pro psaní a příjem zpráv

Diskusní fórum pro snadné výměny názorů •

Rychlé a téměř vždy okamžitě přístupné

•

Možnost vytvořit vlastní téma

•

Možnost zakládat diskuse a zúčastňovat se jich

Rezervační systém termínů u lékaře •

Vypisování a mazání termínů lékařem

•

Možnost rezervace termínu z hlediska uživatelek

Přílohy B. Seznam zkratek / Přílohy C. Katalog požadavků

64

î Požadavky na GUI: •

Implementace pomocí HTML

•

Optimalizace pro přístupnost na většině zařízení

•

Sympatické a intuitivní GUI

•

Design stránek provedený v studených barvách, ale ne nezajímavě

•

Zdůraznění důležitých oznámení, zneutrálnění zpráv nezajímavých

•

Chybové hlášky použitých technologií musí být potlačeny

î Požadavky na bezpečnost a zabezpečení: •

Odolnost vůči technikám SQL injection a vkládání HTML značek

•

Šifrování hesel v databázi pomocí jednosměrné šifry

•

Možnost okamžitého odhlášení ze systému

î Požadavky na použité technologie: •

Finanční – nejlépe nulové náklady na pořízený software

•

Výkonové – rychlé a nejlépe škálovatelné technologie

•

Využití standardů pro webové technologie dle konsorcia W3C •

HTML

•

CSS

•

JavaScript

î Požadavky na modularitu: •

Vytvoření komponent částečně závislých na aplikaci, ale s možností snadného použití v jiném projektu



65

D. Uživatelská příručka î Přihlášení Pro přihlášení využijte přihlašovací formulář na levé straně obrazovky pod hlavním menu. Zadejte Vaše uživatelské jméno a heslo a stiskněte tlačítko Přihlásit se! O případných chybách, či neplatných vstupech budete informováni.

î Odhlášení Odhlašovací odkaz naleznete přesně na tom samém místě jako přihlašovací formulář. Kliknutím na něj se ze systému odhlásíte.

î Psaní zpráv V hlavním menu zvolte položku Zprávy. Zobrazí se uvítací stránka se záložkami. Vyberte položku Napsat zprávu. Vyplňte požadovaná vstupní políčka a formulář odešlete. O případných chybách, či neplatných vstupech budete informováni.

î Čtení a mazání zpráv V hlavním menu zvolte položku Zprávy. Zobrazí se uvítací stránka se záložkami. Vyberte položku Číst zprávy. Zobrazí se seznam přijatých zpráv. Pokud chcete některou ze zpráv smazat klikněte na obrázek popelničky. Budete dotázáni zda si přejete zprávu doopravdy smazat. Klepnutím na Ano ji definitivně odstraníte.

î Vložení záznamu do menstruačního kalendáře V hlavním menu zvolte položku Kalendář. Zobrazí se uvítací stránka se záložkami. Vyberte položku Přidat záznam. Vyplňte požadovaná vstupní políčka a formulář odešlete. O případných chybách, či neplatných vstupech budete informováni. Pokud vše proběhlo v pořádku, měl by být ve výpisu k dispozici nový záznam.

î Prohlížení záznamů z menstruačního kalendáře V hlavním menu zvolte položku Kalendář. Zobrazí se uvítací stránka se záložkami. Vyberte položku Textová karta. Zobrazí se seznam záznamů

66 v aktuálním roce. Nad výpisem je k dispozici výběr z let kdy ste si vedla záznamy. Pokud chcete některý ze záznamů smazat klikněte na obrázek popelničky. Budete dotázáni zda si přejete záznam doopravdy smazat. Klepnutím na Ano ho definitivně odstraníte.

E. Obsah přiloženého CD help.doc

Uživatelská příručka

install.zip

Archiv s potřebnými soubory

Install.doc

Doporučený způsob instalace

BP.doc

Tento dokument

Index.html

Stránka s odkazy na ostatní soubory



1. Úvod. Kapitola 1. Úvod

Recommend Documents