VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA STROJNÍHO INŽENÝRSTVÍ ÚSTAV AUTOMATIZACE A INFORMATIKY FACULTY OF MECHANICAL ENGINEERING INSTITUTE OF AUTOMATION AND COMPUTER SCIENCE
REALIZACE INFORMAČNÍHO SYSTÉMU V PROSTŘEDÍ INTERNETU INTERNET IMPLEMENTATION OF INFORMATION SYSTEM
DIPLOMOVÁ PRÁCE DIPLOMA THESIS
AUTOR PRÁCE
VÍT SYNEK
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR
BRNO 2007
ING. VLADIMÍR DUMEK, PH.D.
Strana 3
Zadání závěrečné práce (na místo tohoto listu vložte originál a nebo kopii zadání Vaš práce)
Strana 4
Licenční smlouva (na místo tohoto listu vložte vyplněný a podepsaný list formuláře licenčního ujednání)
Strana 5
Abstrakt Diplomová práce se zabývá realizací informačního systému neziskové organizace, problémem tvorby webového rozhraní v PHP a k tomu příslušné databáze v systému MySQL.
ABSTRACT Diploma work has dealt with problem of implementation of information systém of non-profit organization also with problem of creation web interface in enviroment of PHP and with creation of propriet database in the MySQL system.
Strana 6
KLÍČOVÁ SLOVA Informační systém, PHP, MySQL, HTML, HTTPS, SSL, dynamické webové stránky, uživatelská práva, UML, bezpečná komunikace sítí WWW.
KEYWORDS Information systém, PHP, MySQL, HTML, HTTPS, SSL, dynamick web pages, user rights, UML, secure comunication on WWW.
Strana 7
PODĚKOVÁNÍ Rád bych poděkoval za odborné vedení a podporu během tvorby diplomové práce Ing. Vladimíru Dumkovi, Ph.D. Dále pak vedení a zaměstnancům neziskové organizace REZEKVÍTEK za všechny užitečné rady, připomínky a veškerou spolupráci.
Strana 8
Strana 9
OBSAH: 1 1.1 1.2 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.3.1 2.3.2 2.3.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.5 2.6 3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 4 4.1 4.1.1 4.1.2 4.1.3 4.2
ÚVOD ...........................................................................................................................11 POŽADAVKY NA REALIZACI INFORMAČNÍHO SYSTÉMU ........................ 13 Rezekvítek.................................................................................................................... 13 Požadavky na systém ................................................................................................... 13 ZÁKLADNÍ TECHNOLOGIE PRO TVORBU INTERNETOVÝCH APLIKACÍ.................................................................................................................. 15 Statické webové stránky............................................................................................... 15 Dynamické webové stránky ......................................................................................... 15 Kaskádové styly ....................................................................................................... 16 DHTML.................................................................................................................... 16 CGI ........................................................................................................................... 17 SAPI modul .............................................................................................................. 18 Skriptovací jazyky na straně serveru............................................................................ 18 Kompilované jazyky ................................................................................................ 19 Perl ........................................................................................................................... 19 PHP........................................................................................................................... 19 Databázové systémy..................................................................................................... 20 Hierarchický model .................................................................................................. 20 Síťový model............................................................................................................ 21 Relační model........................................................................................................... 21 Objektový model ...................................................................................................... 22 PostgreSQL .................................................................................................................. 22 MySQL......................................................................................................................... 22 MODELOVACÍ A OPTIMALIZAČNÍ NÁSTROJE.............................................. 23 Normalizace databází ................................................................................................... 23 0. normalizovaná forma............................................................................................ 23 1. normalizovaná forma............................................................................................ 24 2. normalizovaná forma............................................................................................ 24 3. normalizovaná forma............................................................................................ 24 Boyce-Coddova normalizovaná forma..................................................................... 24 4. normalizovaná forma............................................................................................ 25 5. normalizovaná forma a další ................................................................................ 25 Denormalizace.............................................................................................................. 25 Modelovací jazyk UML ............................................................................................... 25 Vývoj a historie UML .............................................................................................. 26 Diagramy UML ........................................................................................................ 26 Diagram užití............................................................................................................ 27 Diagram tříd (Class Diagram) .................................................................................. 28 Stavový diagram (Statechart Diagram) .................................................................... 30 Sekvenční diagram (Sequence Diagram) ................................................................. 31 Diagram spolupráce (Collaboration Diagram) ......................................................... 32 Diagram komponent (Component Diagram)............................................................ 32 Diagram nasazení (Deployment Diagram)............................................................... 32 ZABEZPEČENÍ ......................................................................................................... 33 Bezpečné uložení dat.................................................................................................... 33 Trvale ukládaná data aplikace .................................................................................. 33 Dočasná aplikační data............................................................................................. 33 Data uložená v databázi............................................................................................ 34 Komunikace ................................................................................................................. 34
Strana 10 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 5 5.1 5.2 5.3 5.4 5.5 6 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.2 6.3 6.3.1 6.4 6.5 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 6.5.7 6.5.8 7 8
HTTP........................................................................................................................ 34 HTTPS...................................................................................................................... 34 Šifrování ....................................................................................................................... 35 Šifrovací algoritmy................................................................................................... 35 Kontrolní součty....................................................................................................... 36 Digitální podpis ........................................................................................................ 36 Distribuce veřejných klíčů a certifikační autority .................................................... 36 SSL ........................................................................................................................... 38 Zamezení zneužití ........................................................................................................ 39 ANALÝZA POŽADAVKŮ NA SYSTÉM ................................................................ 41 Požadavky zadavatele .................................................................................................. 41 Zjištění potřeb uživatelů............................................................................................... 41 Analýza potřeb uživatelů pomocí technik jazyka UML............................................... 42 Databáze ....................................................................................................................... 48 Rozbor zjištěných požadavků....................................................................................... 48 APLIKACE VYTVOŘENÉHO ŘEŠENÍ ................................................................ 49 Použité prostředky........................................................................................................ 49 WWW server............................................................................................................ 49 MySQL..................................................................................................................... 49 PHP........................................................................................................................... 49 Prostředí vývoje........................................................................................................ 50 Celkové schéma informačního systému (Data Flow Diagram) ................................... 50 Návrh databáze............................................................................................................. 51 Popis jednotlivých tabulek informačního systému................................................... 52 Uživatelské rozhraní..................................................................................................... 57 Realizace aplikace ........................................................................................................ 58 Generování stránek................................................................................................... 58 Přístupová práva....................................................................................................... 58 Přihlášení.................................................................................................................. 59 Modul Adresář.......................................................................................................... 60 Modul Členské příspěvky......................................................................................... 60 Modul Archiv Dokumentů ....................................................................................... 61 Modul Administrace Systému .................................................................................. 62 Další pomocné soubory............................................................................................ 63 ZÁVĚR........................................................................................................................ 65 SEZNAM POUŽITÉ LITERATURY....................................................................... 67
Strana 11
ÚVOD Počítače a obecně Informační technologie ovlivňují lidskou činnost mnohem více, než tomu bylo kdykoliv dříve v lidských dějinách. Toto klade velký důraz na ukládání, vyhledávání a prezentaci informací ve velkém objemu. Velké množství informací není možné zpracovávat bez užití počítačů, nebo obecněji informačních technologií a jsou to softwarová řešení – informační systémy, která jsou schopny toto zabezpečit. Tato diplomová práce nejprve obecně hodnotí vlastnosti a požadavky, které jsou kladeny na informační systémy a následně ukazuje některé prostředky, které je možné využít pro implementaci informačního systému. Z těchto prostředků jsou následně vybrány ty, kterých bude využito pro implementaci této diplomové práce. Cílem diplomové práce je vytvoření informačního systému neziskové organizace REZEKVÍTEK a jeho příslušného webového rozhraní. Dalším důležitým krokem je vytvoření přehledné databáze poskytovaných údajů informačním systémem a jejich zabezpečení proti zneužití. V této části je velice důležitá správná implementace a bezchybná realizace bezpečnosti. Vytvořené webové rozhraní by mělo sloužit k práci s touto databází přes internet, pomocí některého internetového prohlížeče (např. Mozzila, Opera, Internet Explorer...). Celé webové rozhraní je kombinací několika jazyků (programovacích, dotazovacích atd.). a výsledkem by měli být webové stránky pro internetový prohlížeč.
Strana 12
Strana 13
1
POŽADAVKY NA REALIZACI INFORMAČNÍHO SYSTÉMU
1.1
Rezekvítek
Rezekvítek je občanské sdružení, jehož posláním je sdružovat občany, kteří se dobrovolně věnují ekologické výchově a ochraně přírody. Rezekvítek se snaží přispívat ke zvyšování pedagogické i odborné úrovně této práce a všestranně své členy v této činnosti podporovat. Hlavní náplní organizace, vyplývající z jejího poslání, je právě práce se členskou základnou i širokou veřejností. Dokud byla činnost organizace omezena na jen na hrstku příznivců bylo možné vyřizovat vše tzv. „papírově“. Díky růstu objemu činnosti organizace se ale začaly objevovat problémy s aktualizací a předáváním dat.
1.2
Požadavky na systém
Informační systém bude provozován na vnitřní síti organizace a jejím serveru s dostupností z vnější sítě – prostředí internetu. Systém by měl jednoduše, přehledně a zároveň bezpečně zpřístupnit data a dokumenty organizace jak zaměstnancům, tak statutárním a správním orgánům organizace. Vzhledem k existenci Zákona č. 101/2000 Sb., o ochraně osobních údajů a faktu, že by systém měl obsahovat i citlivá osobní data členů organizace a interní dokumenty, musí být systém zabezpečen proti neoprávněnému přístupu. Do systému budou implementována uživatelská práva. Systém by měl být pomocníkem při předávání informací členům a evidenci jejich příspěvků. Díky této aplikaci by mělo být možné oprávněným uživatelům poskytnout interní dokumenty organizace. Na základě seznámení se základními požadavky je možno určit prostředky, které by byly vhodné pro návrh modelu a implementaci informačního systému.
Strana 14
Strana 15
2
ZÁKLADNÍ TECHNOLOGIE PRO TVORBU INTERNETOVÝCH APLIKACÍ
Obvykle užívaný název pro dokument na WWW ( World Wide Web ) je webová stránka. Nejčastěji užitý jazyk pro tvorbu webových stránek je jazyk HTML ( HyperText Markup Language ), ten umožňuje propojovat jednotlivé stránky mezi sebou pomocí odkazů, tedy je možné se pohybovat mezi jednotlivými dokumenty. Z technického hlediska je prohlížení webových stránek typická klient-server aplikace, kde server je program, který zpracovává požadavky (definované protokolem HTTP (Hyper Text Transfer Protocol)) a na základě těchto požadavků posílá zpátky klientovi dokument, který danému požadavku odpovídá. Z terminologického hlediska se programu na straně serveru říká webový server (nejběžnějšími zástupci takovýchto programů (uváděné nezávisle na podporovaných operačních systémech) jsou servery Apache, Microsoft IIS, OmniHTTPd, Xitami, …) a programům na straně klienta prohlížeč (Microsoft Internet Explorer, Mozilla, Netscape Communicator (Navigator), Opera, Lynx, Amaya, …). V následujících kapitolách budou popsány různé technologie, které se pro tvorbu dynamických webových stránek nejvíce využívají. Zejména jde o různé skriptovací jazyky a databázové systémy použité při tvorbě webových aplikací a využívajících konceptu dynamických stránek. Budou uvedeny jen nástroje volně šířitelné (open-source), a proto i volně použitelné. Placená řešení nebudou zmíněna z důvodu množství uvolněných prostředků zadavatele. Cílem této kapitoly je zvolit z možných variant optimální prostředky pro vývoj informačního systému neziskové organizace.
2.1
Statické webové stránky
Statické webové stránky jsou dokumenty psané povětšinou v jazyce HTML a jsou uloženy na disku serveru. Jejich změna není možná během prohlížení přes webový prohlížeč, pouze při změně souboru přímo na disku. Brzy po masivním rozšíření internetu se ukázalo, že udržování všech informací na statických webových stránkách je velice neefektivní. A při požadavku na aktuálnost dokumentů, jde o nadlidský úkol. Vznikla tedy potřeba automatizovat postup vytváření dokumentu a jeho obsahu.
2.2
Dynamické webové stránky
Dynamické webové stránky jsou HTML stránky, které v rámci své definice obsahují nějaký kód, který umožňuje reagovat na akce uživatele. Především je třeba říci, že dynamické HTML do jazyka HTML nepřidává žádné nové atributy nebo elementy. Dynamické HTML pouze definuje různé možnosti, jakými mohou skripty zařazené do stránek měnit jejich obsah. Všechny změny obsahu prohlížeč okamžitě zjistí a zobrazení stránky přizpůsobí aktuálnímu stavu. Toho lze docílit dvěma různými způsoby prvním, kdy je skript vykonáván na straně klienta nebo druhým, kdy je kód vykonáván na straně serveru. První způsob, kdy je v rámci dokumentu HTML psán určitý kód, který je schopen nějakým způsobem reagovat na akce uživatele. Obvykle se jedná o funkce napsané v jazyce Javascript (popř. VBScript), kde pomocí DOM (Document Object Model) můžeme manipulovat s obsahem dokumentu (dokumenty HTML s vloženým Javascript kódem se nazývají DHTML, neboli Dynamic HTML). Dalším možným způsobem, kterým je chápán pojem dynamické webové stránky, jsou takové dokumenty, jejichž obsah je na základě požadavku z klientské strany dynamicky vytvářen nějakým programem na straně serveru. Obsah takovéto stránky tedy v okamžiku vzniku požadavku není přítomen na serveru jako statický soubor, ale je vytvářen jako odpověď až na základě obdržení požadavku. Takovýto přístup umožňuje zapojit do procesu vytváření stránek další prostředky typu
Strana 16 databázových systémů, s jejichž pomocí lze ukládat a spravovat značné množství informací, které pak můžeme využít k tvorbě stránek, nabízet informace k prohlížení, apod. 2.2.1
Kaskádové styly
Kaskádové styly – CSS (Cascading Style Sheets), jsou nadstavbou vyznačovacích jazyků HTML, XHTML či XML. V jazyku HTML existuje několik atributů a elementů, které ovlivňují pouze grafickou stránku vzhledu dokumentu. S jejich využitím můžeme sice získat graficky atraktivní stránku, to však s sebou nese řadu nevýhod. Samotný text stránky bývá obvykle špatně strukturován. Jednotlivé elementy bývají využívány jen k dosažení určitých grafických efektů. A velkou nevýhodou je přílišná složitost vytváření dokumentu a jeho inovace, kdy se vizuální atributy nastavují zbytečně opakovaně u všech elementů. Všechny předem uvedené nevýhody odstraňují právě kaskádové styly (Cascading Style Sheets) a dodávají tvorbě webu tentýž komfort, jaký je k dispozici ve většině textových procesorů. Na jednom centrálním místě je možné nastavit styly CSS tak, aby ovlivnily vzhled značek HTML jedné jediné webové stránky nebo celého webu. Styly umožňují předdefinovat způsob zobrazení (druh a velikost písma, barvu, apod.) každého elementu na stránce. Styly však nejsou součástí textu stránky a tedy může být kód stránky přehlednější a dobře strukturovaný. Navíc je možné definovat jednotný vzhled určitého elementu v celém dokumentu jedním zápisem. Styly jsou zapisovány takzvanými pravidly, které je možné sdružovat, vytvářet v kontextu, a dle použitého prohlížeče zde funguje i do jisté míry dědičnost. Každé pravidlo má vždy dvě části: •
Selektor ( H1 )
•
Deklaraci ( text-align: left )
Každá deklarace je složena ze dvou částí: •
Vlastnost ( text-align: )
•
Hodnota ( left )
Vlastností u každého selektoru může být více a mohou být tedy sdružovány. Jednotlivé selektory stejného typu jsou odlišeny tzv. třídami nebo identifikátory ID. Styly je možné zapisovat přímo k selektoru, do hlavičky dokumentu, nebo do externího souboru. CSS se stále vyvíjí a momentálně je ve verzi 3 CSS3, který je sice navržen, ale není implementován do žádného prohlížeče. Verze CSS2 je sice částečně podporována aktuálními prohlížeči, ale výsledek bývá rozdílný. Důvodem je neimplementace některé vlastnosti či její hodnoty. Případně je problém ve vlastním výkladu toho co by která vlastnost měla dělat a jak. 2.2.2
DHTML
Spojení HTML kódu se skriptem bývá označováno jako DHTML. Je možné užít jakýkoliv skriptovací jazyk, který je schopen prohlížeč zpracovat například VBScript, JavaScript nebo konkurenční JScript. Druhý jmenovaný bývá použit nejčastěji a proto bude požit jako modelový příklad. JavaScript je jednoduchý programovací jazyk, který se používá v internetových stránkách. Zapisuje se přímo do HTML kódu, což je velká výhoda, protože je to jednoduché. Každý program se skládá z příkazů, které jsou prováděny sekvenčně v pořadí, v jakém byly zapsány. JavaScript je klientský skript. To znamená, že se program odesílá se stránkou na klienta (do prohlížeče) a teprve tam je vykonáván.
Strana 17
Obrázek 1: Schéma klientského skriptu
Příčinou vzniku JavaScriptu byl požadavek na zvýšení uživatelského komfortu pro uživatele stránek. JavaScript můžeme použít například při vstupní kontrole dat vkládaných do formulářů a to ještě předtí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živatele. V zásadě jsou dvě možnosti, jak je možné vložit skript do HTML stránky. Jsou rozděleny podle toho, jakým způsobem je má prohlížeč interpretovat: •
Skripty, které mají být vykonány při nahrání HTML kódu do prohlížeče jsou vkládány pomocí elementu SCRIPT.
•
Skripty, které mají být vykonány vždy, když se vyskytne určitá událost. Událostí existuje několik a vždy se musí být vztaženy k určitému elementu. Událostí může být například pohyb kurzoru myši nad příslušným elementem.
Skript se vkládá do HTML dokumentu pomocí párového tagu SCRIPT. Skript je možné vložit do stránky přímo nebo uvést pouze odkaz na URL, které obsahuje program v příslušném skriptovacím jazyce. Příkazy zavřené v elementu SCRIPT se provedou pouze jednou při načtení stránky. Aby mohly být dokumenty vytvářené s pomocí JavaScriptů opravdu interaktivní, je potřeba, aby provedení určité části skriptu bylo vyvoláno událostí, kterou způsobil svou činností uživatel. U každého elementu je možno použít několik atributů, které odpovídají jednotlivým událostem. Jako jejich hodnota se uvádí příkazy, které se po vyvolání dané události mají provést. Nazývají se souhrnně obsluha události. Z principu práce s dynamickým HTML je zřejmé, že stránka bude bez problémů zobrazena i v prohlížeči, které dynamické HTML nepodporují. Pouze se nezobrazí části textu vygenerované scriptem a po kliknutí myší na příslušný odkaz se nestane nic, protože tyto prohlížeče neumějí dynamicky měnit obsah stránky po jejím zobrazení. To by měl mít na zřeteli tvůrce stránek při volbě těchto skriptů, tak aby zásadně nepoškodí základní informační hodnotu stránky. 2.2.3
CGI
Nejstarším, ale stále ve velké míře díky své jednoduchosti používaným přístupem vytváření obsahu stránky na straně serveru je CGI (Common gateway interface). Jeho princip je velice jednoduchý. Webový server obdrží požadavek od klienta a tento požadavek je přeposlán dalšímu programu, který požadavek zpracuje, zpět serveru pošle již vytvořenou stránku a server ji odešle zpět klientovi jako odpověď na jeho požadavek. Na webovém serveru podporujícím CGI to bývá obvykle zařízeno tak, že v jeho konfiguračním souboru je definováno, ve kterém konkrétním adresáři leží CGI programy, případně jakou příponu mají soubory, které mají být považovány za CGI programy. Když webový server dostane požadavek,
Strana 18 který má zpracovat CGI program, nastaví proměnné prostředí, spustí CGI program a na standardní vstup mu zašle data z požadavku. Odpověď na požadavek očekává na standardním výstupu CGI programu. Z předchozího odstavce vyplývá, že CGI programem může být program napsaný v jakémkoliv programovacím jazyce, který podporuje čtení ze standardního vstupu, čtení/nastavování proměnných prostředí a zápis na standardní výstup. To je jeden ze základních požadavků na každý „rozumný” programovací jazyk, takže výběr je opravdu bohatý. Vytváření CGI programů skrývá jedno z mnoha nebezpečí. Pokud budeme psát CGI program v jazyce, jehož kompilátor umožňuje zkompilování programu do spustitelné podoby, musíme dát velmi pozor na všechna bezpečnostní rizika vyplývající ze způsobu užití programu jako CGI. Takovýto program musí vždy na jakýkoliv vstup odpovědět nějakým výstupem. Tedy nesmí existovat vstup, který by zapříčinil zhroucení nebo chybné chování programu. Výhodou takovéhoto programu je rychlost a nízká náročnost systémové prostředky na rozdíl od programů napsaných v nějakém interpretovaném jazyce. Ovšem z programátorského hlediska je výhodnější a příjemnější použít k napsání CGI programu některého interpretovaného jazyka. Skriptovací jazyky poskytují daleko širší možnosti při práci s textem. Proto jsou pro CGI programování, kde se zpracovává především textový vstup, nejvhodnější. Mezi jejich zástupce patří například PHP, Python, Perl, ASP, Tcl, atd. 2.2.4
SAPI modul
SAPI (Server Application Interface) modul je novější způsob implementace téhož přístupu jako CGI. Ekvivalentem CGI programu je modul (knihovna), který je spouštěn v rámci procesu web serveru (a tudíž se spouští rychleji než jako samostatný proces), jsou však na něj kladeny větší nároky týkající se implementace rozhraní, kterým komunikuje s webovým serverem. Jelikož už nejde o samostatně spustitelný program, takřka zde odpadá možnost pro běžného aplikačního (webového) programátora programovat v kompilovaných jazycích (každý takovýto program by v sobě musel obsahovat implementaci rozhraní pro web server). Zbývá zde tedy možnost použít některého interpretovaného jazyka, jehož interpret existuje jako SAPI modul pro příslušný web server.
2.3
Skriptovací jazyky na straně serveru
Na straně serveru je možné použít pro vývoj CGI aplikací téměř jakýkoliv programovací jazyk. Je zde tedy velká volnost při výběru jazyka, kterým může být nějaká aplikace napsána. Který z nich vybrat záleží na mnoha hlediscích, mohou to být rychlost výsledné aplikace, bezpečnost jejího použití, rychlost vývoje, snadnost aktualizace apod.
Obrázek 2: Schéma skriptu běžícímu na serveru
Strana 19 V následujících podkapitolách budou zmíněny jazyků, které je možno použít pro tvorbu webových komerční, volně nešířitelná řešení, neboť nejsou oblastí úplný, ale dobře ukazuje možnosti výběru a na pro implementaci to nemá vliv. 2.3.1
jen významnější zástupci programovacích aplikací. Zároveň nebudou uvedena žádná zájmu diplomové práce. Výčet není zdaleka posouzení kvality prostředku vybraného
Kompilované jazyky
Naprogramování serverové aplikace v některém kompilovaném jazyce (C, C++, Java…) má obrovskou výhodu v maximální výkonnosti a rychlosti zpracování požadavku při porovnání s ekvivalentními programy napsanými v nějakém interpretovaném jazyce. Nevýhodou takto vytvořeného programu je obvykle daleko delší doba vývoje aplikace, kvůli nutnosti dodržovat přísná kritéria pro bezpečnost a stabilitu aplikace. 2.3.2
Perl
Jazyk Perl je vysoce vyspělý open-source programovací jazyk s podporou objektově orientovaného přístupu, který je vynikající zvláště ve schopnosti zpracování textu. Jeho hlavní předností při zpracování textu je přímá podpora regulárních výrazů, která je dovedena takřka k dokonalosti množstvím svých schopností i rychlostí. Pro Perl existuje celá řada knihoven funkcí, mezi nimi nechybí knihovny pro podporu práce s HTML stránkami a HTTP komunikací nebo rozhraní pro komunikaci s různými databázemi. Perl existuje pro širokou škálu operačních systémů (Windows, UNIX, Apple), je tedy nezávislý na platformě a je velice vhodným kandidátem pro vývoj webových aplikací. 2.3.3
PHP
PHP je serverový skriptový jazyk navržený pro potřeby tvorby webových stránek. Je k dispozici pro většinu operačních systémů a pro celou řadu různých webových serverů jako CGI aplikace i jako SAPI modul pro servery, které tuto možnost nabízejí. Do stránky HTML je možné umístit kód PHP, který se vykoná pokaždé, když má být stránka zobrazena. PHP kód se interpretován na webovém serveru a generuje HTML nebo jiný výstup. PHP má také implementováno plno rozšiřujících knihoven pro práci se širokou škálou databází, textových a grafických formátů souborů apod. Od verze 4 je zavedena částečná podpora objektově orientovaného programování. Oproti Perlu PHP ve své verzi jako skriptovací jazyk pro web neobsahuje funkce potenciálně nebezpečné pro samotný server, může běžet v tzv. bezpečném módu, kde má administrátor systému možnost podstatným způsobem omezit možnost prolomení bezpečnostních ochran serveru. Další užitečnou vlastností je např. možnost nastavit maximální dobu běhu PHP skriptu, maximální množství paměti, které může skript během svého provádění využít atd. PHP byl vytvořen v roce 1994 původně jako práce jednoho člověka – Rasmuse Lerdorfa. Jeho výtvor byl dalšími nadšenci dále vyvíjen a prodělal do dnešního dne čtyři velké předělávky a dnes je to již plnohodnotný nástroj pro tvorbu dynamického webu. V květnu 2007 byl používán na více jak dvaceti miliónech domén. (zdroj. Http://www.php.net/usage.php ) PHP je produktem Open Source a kdokoliv má přístup k jeho zdrojovému kódu. Je možné jej tedy používat, upravovat a dále distribuovat, to vše bez jakéhokoliv poplatku. PHP původně znamenalo Personal Home Page, ale název byl později změněn tak, aby získal podobně rekurzivní význam jako GNU (GNU Gnu's Not Unix) a tedy PHP dnes znamená Hypertext Preprocesor. Současná hlavní verze PHP nese číslo 5.x. A je založena na jádře Zend společnosti Zend Technologies (http://www.zend.com), která se podílí na vývoji jádra a pak jej sama využívá pro tvorbu svého vlastního komerčního řešení. Domovská stránka projektu PHP je k dispozici na http://www.php.net.
Strana 20 PHP bylo zvoleno pro implementaci této diplomové práce. Důvodem je všeobecná podpora na serverech poskytovatelů hostingu.
2.4
Databázové systémy
Databázové systémy jsou velmi vhodným prostředkem pro ukládání, správu a práci s velkým objemem dat. Pokud se programátor aplikace rozhodne ukládat data v databázovém sytému, odpadá pro něj nutnost implementovat svůj vlastní (i když obvykle jednodušší) systém, pomocí něhož by spravoval data aplikace. Pro práci s daty v databázovém systému se používá standardizovaného jazyka (SQL). Existují v zásadě čtyři hlavní databázové modely a jejich kombinace. Jsou to hierarchický, síťový, relační a objektový databázový model. V současné době se užívají dva hlavní modely práce s těmito daty relační a objektový model. Dnes již naštěstí existují volně dostupné kvalitní relační databázové systémy, které je možno použít i pro náročné aplikace. 2.4.1
Hierarchický model
Jedná se o nejstarší databázový model.Vztahy mezi soubory jsou ve stylu rodič-potomek. Každý rodič může mít vztah k více potomkům, ale jednotlivý potomci mohou mít vztah jen k jednomu rodiči.
Obrázek 3: Hierarchický databázový model
Tento model je vhodný pro zachycení vztahu jednoho s mnohými (one-to-many), kdy má jeden rodič mnoho potomků (např. jedna škola mnoho žáků). Má však problém se vztahy mnoha s mnohými (many-to-many). Další slabinou je malá flexibilnost, protože přidání nových vztahů do modelu, může mít za následek, rozsáhlou změnu struktury a následně všech již existujících aplikací. Navíc při vývoji aplikací je potřeba dobře znát strukturu dat, aby bylo možné strukturou procházet a tak se dostat k požadovaným datům.
Strana 21 2.4.2
Síťový model
Je o jeden stupínek výše než hierarchický model a řeší některé z potíží předchozího modelu, především nedostatek flexibility. Potomek již nemusí mít jen jednoho rodiče, ale může jich mít více – potomci jsou nazváni členy a rodiče vlastníky. Lépe se modelují vztahy many-to-many.
Obrázek 4: Síťový databázový model
I tento model má své problémy a velká omezení a proto není často využíván. Jeho implementace je obtížná i správa je složitá i když je tento model pružnější než model hierarchický. Stále je potřeba dobře rozumět struktuře dat. 2.4.3
Relační model
Nejrozšířenějším je relační model a představuje skok vpřed vzhledem k síťovému modelu. Byl vyvinut E. F. Coddem v roce 1970. V tomto modelu jsou data ukládána ve formě tabulek. Relační model je postaven na matematickém základu relačních algeber. Tento model namísto využívání vztahů rodič-potomek nebo vlastník-člen umožňuje vytvoření vztahu mezi jakýmikoli dvěma soubory prostřednictvím nějakého společného pole. Vztahy mezi daty neexistují přímo, ale jsou vytvářeny a vyhledávány na základě dotazu. Dotaz je příkaz pro databázový systém, který v bázi dat vyhledává data odpovídající podmínkám uvedeným v dotazu. Možné vztahy při modelování relací jsou:
Obrázek 5: Vztah jednoho s jedním
Obrázek 6: Vztah jednoho s mnoha
Strana 22 Obrázek 7: Vztah mnoho s mnoha
Při použití relačního modelu dochází k výraznému snížení složitosti návrhu, protože lze uskutečňovat změny v databázovém schématu, aniž by byla ovlivněna schopnost systému přistupovat k datům. Navíc protože se k datům přistupuje přímo pomocí vztahu mezi soubory a ne pomocí cest, lze snadno přidávat nové vztahy mezi soubory dat. 2.4.4
Objektový model
Novějším ale ne tak rozšířeným přístupem, je objektový model. V tomto modelu jsou data reprezentována objekty, které mají své atributy, operace a je mezi nimi uplatňován vztah dědičnosti. Lze přímo vytvářet vztahy mezi objekty a tvořit tak sofistikovanou strukturu, kde jsou jednotlivé objekty na sobě funkčně závislé. Objektový model databáze kombinuje prvky objektově orientovaného programování s databázovými schopnostmi. Přímo rozšiřují funkčnost objektových programovacích jazyků (Java, C++, Smalltalk,) a poskytují plnou schopnost programování databáze. Datový model aplikace a datový model databáze jsou ve finále hodně podobné a výsledný kód se tak dá mnohem efektivněji udržovat.
2.5
PostgreSQL
PostgreSQL je na schopnosti velice bohatý databázový systém. Podporuje většinu vlastností definovaných ve standardu SQL-92 a SQL-99, obsahuje navíc některá rozšíření těchto standardů. Předností systému PostgreSQL je rozšiřitelnost. Systém může být bezproblémově rozšiřován o nové datové typy, funkce operátory, agregační funkce, procedurální jazyky. Jedinou nevýhodou tohoto systému v porovnání s dalším open-source databázovým systémem MySQL je nižší rychlost provádění požadavků vzhledem ke složitějším implementovaným možnostem SQL dotazů a transakčnímu přístupu k provádění dotazů (ani jeden z těchto důvodů neubírá nic na kvalitě PostgreSQL, pouze konstatuje, že vzhledem k menší komplikovanosti bývá ve valné většině případů MySQL rychlejší). Další nevýhodou tohoto systému je nutnost časté „údržby” (příkaz VACUUM) tabulek a indexů, která při větším zatížení serveru vede ke znatelnému zpomalení jeho funkce.
2.6
MySQL
Tento velice rozšířený a populární databázový systém podporuje na rozdíl od PostgreSQL pouze omezenou část požadavků na databázový server definovaných ve standardu SQL-92. Nepodporuje například vnořené dotazy, cizí klíče, transakce (obojí od verze 3.23 podporováno pro InnoDB typ databáze), pohledy, uložené procedury, triggery, kurzory, a některé další. Přes tato omezení se tento systém stal suverénně nejpopulárnějším volně šiřitelným databázovým systémem možná proto, že díky své jednoduchosti zůstává jedním z nejrychlejších a nejstabilnějších databázových systémů i ve srovnání s komerčními systémy. Nutno podotknout, že od verze 4.1 implementuje MySQL velice zajímavou možnost definice různých kódových tabulek textů a řazení textových položek nejenom v rámci nastavení celého databázového serveru, jak jej implementuje ve starších verzích, ale až na úrovni jednotlivých sloupců, tabulek, či databází. Otevírá se tak možnost ukládat vícejazyčná data v rámci jedné databáze.
Strana 23
3
MODELOVACÍ A OPTIMALIZAČNÍ NÁSTROJE
3.1
Normalizace databází
Normalizace představuje mocný nástroj při optimalizaci návrhu databází. Byl vyvinut v 70. letech minulého století E. F. Coddem a v současné době se jedná o standardní požadavek většiny databázových návrhů. Pomocí tohoto nástroje je možné redukovat tzv. anomálie dat a zjednodušit jejich správu. Existuje několik forem normalizace označených po sobě jdoucími čísly: •
0. normalizovaná forma
•
1. normalizovaná forma
•
2. normalizovaná forma
•
3. normalizovaná forma
•
Boyce-Coddova normalizovaná forma
•
4. normalizovaná forma
•
5. normalizovaná forma
•
Denormalizace
Jednoduché projekty obsahující jen dvojice propojených tabulek lze jednoduše zvládnout bez optimalizací, protože dotazy bývají jednoduché. Ovšem při vytváření větších projektů se dotazy stávají složitějšími. Začínají se objevovat výkonnostní problémy a anomálie dat. Bez zvládnutí znalostí návrhu databází a normalizace se mohou tyto potíže stát nezvládnutelnými. Normalizování databází je technika, která je schopná pomoci vyhnout se datovým anomáliím a dalším problémům se správou dat. Skládá se z transformování tabulky různými fázemi: 1. normalizovanou formou, 2. normalizovanou formou, 3. normalizovanou formou a tak dále. Zaměřuje se na:
3.1.1
•
Eliminaci nadbytečnosti dat (a tedy spotřebování menšího prostoru)
•
Usnadnění změny dat a zabránění vzniku anomálií při této činnosti
•
Ulehčení zavádění omezení referenční integrity
•
Vytváření snadno pochopitelné struktury, která se úzce podobá situaci reprezentované daty a umožňuje další růst
0. normalizovaná forma Jde o zcela nenormalizovanou strukturu, která splňuje některé z těchto kritérií: •
Struktura obsahuje opakující se skupiny – mnoho výskytu daného pole.
•
Nejsou definovány všechny klíčové atributy.
•
Atributy nezávisí jen na primárním klíči.
Tato forma je základní ze které se většinou začíná s normalizací.
Strana 24 3.1.2
1. normalizovaná forma Tabulky v první normalizované formě naplňují tato pravidla: •
Nejsou tu žádné opakující se skupiny.
•
Jsou definovány všechny klíčové atributy.
•
Všechny atributy závisejí na primárním klíči.
To znamená, že data musejí být schopna převedení do tabulkového formátu, kde každé pole obsahuje jednu hodnotu. Jedná se rovněž o fázi, kde se definuje primární klíč. V této fázi se obvykle aplikuje princip atomičnosti. Znamená to, že všechny sloupce musejí obsahovat své nejmenší součásti a jsou dále nedělitelné. Příkladem tohoto principu je situace, kdy je vytvořeno pole jmeno. Je však lepší užitím tohoto principu rozdělit jej na krestni_jmeno a prijmeni. 3.1.3
2. normalizovaná forma Tabulka je ve druhé normalizované formě, pokud naplňuje tato pravidla: •
Nachází se v 1. normalizované formě
•
Nezahrnuje žádné částečné závislosti (kdy nějaký atribut závisí jen na části primárního klíče)
Aby mohl nějaký atribut záviset jen na části primárního klíče, musí se daný primární klíč skládat z více než jednoho pole. Pokud primární klíč zahrnuje jen jedno pole, tabulka je automaticky ve 2. normalizované formě, pokud ovšem splňuje podmínky 1. normalizované formy. 3.1.4
3. normalizovaná forma Tabulka se nachází ve 3. normalizované formě, pokud naplňuje následující pravidla: •
Je ve druhé normalizované formě
•
Neobsahuje žádné tranzitivní neboli přechodné závislosti (když nějaký neklidový atribut závisí na primárním klíči prostřednictvím jiného neklíčového atributu).
Pokud nějaká tabulka obsahuje jen jeden neklíčový atribut, je samozřejmě nemožné, aby byl tento neklíčový atribut závislý na nějakém jiném neklíčovém atributu. Všechny podobné tabulky splňující podmínky 2. normalizované formy se zároveň automaticky nacházejí ve 3. normalizované formě. Třetí normalizovaná forma bývá obvykle dostačující pro většinu tabulek, protože vylučují nejčastější typy datových anomálií. Další normalizované formy jsou pro obvyklé aplikace užitečné jen zřídka. Ve většině případů se tabulky 3. normalizované formy stejně nachází i v těchto normalizovaných formách. Ovšem mohou být užitečné při řešení vyjímek u kterých je potřeba normalizovat do vyšších úrovní, pokud je to zapotřebí. 3.1.5
Boyce-Coddova normalizovaná forma
Tato normalizovaná forma nese jména pánů E. F Codda a R. F. Boyceho, dvou významných pracovníků v oblasti databázového modelu. E. F. Codd vyvinul a rozšířil relační model a v roce 1970 vyvinul rovněž normalizaci pro relační modely, zatímco R. F. Boyce byl jedním z tvůrců jazyka Structured Query Language (tenkrát označovaného za SEQUEL). Tabulka je v Boyce-Coddově normalizované formě, když naplňuje tyto podmínky: •
Nachází se ve 3. normalizované formě
•
Každý determinant je kandidátním klíčem.
Strana 25 Determinant je atribut, který určuje (determinuje) hodnotu jiného atributu. Kandidátní klíč je buď klíč nebo alternativní klíč (jinými slovy, daný atribut může být klíčem pro danou tabulku). 3.1.6
4. normalizovaná forma Tabulka je ve 4. normalizované formě, když naplňuje tato kritéria:
3.1.7
•
Je v Boyce-Coddově normalizované formě.
•
Neobsahuje více něž jednu vícehodnotovou závislost.
5. normalizovaná forma a další
Existují i další vyšší normalizované formy, které jsou však spíše akademické povahy, protože jimi řešené problémy se v praxi projevují málokdy. [1]
3.2
Denormalizace
Denormalizace je proces vrácení transformací uskutečněných během normalizace z výkonnostních důvodů. Je to metoda značně rozporumlná, jeden názor uvádí, že cena za denormalizaci je příliš vysoká a doporučuje nikdy nedenormalizovat, druhý názor vyzdvihuje výhody a denormalizaci doporučuje. Podpůrci denormalizace podpírají svá tvrzení takto: Normalizace vytváří více tabulek, jak postupuje k vyšším normalizovaným formám, více tabulek však znamená uskutečnění více spojení přebírání dat, což zase na druhou stranu zpomaluje dotazy. Z toho důvodu je v zájmu zlepšení rychlosti určitých dotazů vhodné zapomenout na výhody integrity dat a vrátit datovou strukturu na nižší normalizovanou formu. Nejrozumnějším řešením bude asi kompromis a praktický přístup, který zvažuje omezení SQL, ale brání se zbytečné denormalizaci. Stačí se držet následujících doporučení:
3.3
•
Je-li výkonnost normalizované struktury přijatelná, nemělo by se nenormalizovat.
•
Je-li výkonnost nepřijatelná, je potřeba se přesvědčit, že ji denormalizace dostane na přijatelnou úroveň. Je také dobré zvážit alternativy, jako je např. lepší hardware, který může výkonnostní problém vyřešit bez denormalizace. Po denormalizaci je obtížnější měnit strukturu.
•
Je potřeba zhodnotit cenu zvýšení výkonnosti na úkor snížení integrity dat.
•
Je dobré zvážit možné budoucí scénáře, kdy mohou začít aplikace klást na data jiné požadavky. Není vhodné denormalizovat kvůli zvýšení výkonu konkrétní aplikace, protože pak se struktura dat stává závislou na dané aplikaci. Pokud bereme jako ideální stav aplikační nezávislost.[1]
Modelovací jazyk UML
UML (Unified Modeling Language) je jazyk pro modelování, specifikaci, vizualizaci, vytváření a dokumentování částí softwarových systémů, obchodních modelů, nebo jiných nesoftwarových systémů. UML je jazyk se širokým záběrem pokrývajícím velké množství aplikačních oblastí. UML představuje soubor nejlepších inženýrských postupů úspěšně používaných při modelování velkých a komplexních systémů. Jazyk UML je modulární a není potřeba vždy využívat všech možností a schopností, které nabízí, ale jen ty, které nás přímo zajímají (překlad ze specifikace UML 2.0 [7]).
Strana 26 UML je dobrým pomocníkem při modelování komplexních systémů, umožňuje různé pohledy na problém a zároveň umožňuje vytvářet různé úrovně abstrakce systému. Tím pádem je možné nahlížet na systém jako celek a postupně se nořit čím dál hlouběji do přesnější specifikace konkrétních vlastností dané části systému. 3.3.1
Vývoj a historie UML
Jazyky pro objektově orientované modelování se začaly objevovat od poloviny sedmdesátých let dvacátého století a koncem let osmdesátých začala řada metodologů experimentovat s různými přístupy k objektově orientované analýze a návrhu. Modelovací jazyk UML byl výsledkem snažení analytiků a designerů, kteří v přůběhu 80. a 90. let vytvářeli metody umožňující popsat objektově orientovanou analýzu a návrh. V polovině 90. let byly velmi rozšířené metody OMT (Object Modeling Technique), jejich autory byli Booch a Rumbaugh, a dále metodika Ivara Jacobsona – Objectory. V roce 1995 byly zahájeny práce na sjednocení různých metod a syntaxí pro modelování pod záštitou firmy Rational. Výsledkem snažení bylo v roce 1997 vytvoření první verze modelovacího jazyka UML 0.91. Během stejného roku vznikla při organizaci OMG [7] (Object Management Group) snaha zapojit do vývoje jazyka UML velké softwarové firmy, které by mohly přispět svými zkušenostmi a podněty při vývoji jazyka. Tento souhrn metod se stal průmyslovým standardem a postupně se vyvíjel až do aktuálně používané verze 2.1.1, u které byla vydána specifikace v únoru 2007. Verze UML 2.x představuje největší změnu, k jaké v UML vůbec kdy došlo. V rámci samotného UML došlo totiž ke změnám v samotném jeho metamodelu a vzniklo i několik dalších doplňujících diagramů. 3.3.2
Diagramy UML
Diagramy jsou základním konstruktem jazyka. UML diagramy přestavují vlastně grafy – vlastnosti nebo stavy modelovaného systému tvoří uzly a vztahy mezi nimi tvoří hrany. Digramy můžeme rozdělit do tří základních tříd, kde první se týká struktury projektu, dále chování, pod nímž lze najít související celek diagramů interakce. UML 2.0 definuje celkem 13 typů diagramů. •
•
•
Strukturní diagramy o
Diagram tříd (Class diagram)
o
Diagram komponent (Component diagram)
o
Composite structure diagram
o
Diagram nasazení (Deployment diagram)
o
Objektový diagram (Object diagram)
o
Package diagram
Diagramy chování o
Diagram aktivit (Activity diagram)
o
Stavový diagram (State Machine diagram)
o
Případy užití (Use case diagram)
Diagramy interakce, podmnožina digramů chování o
Diagram kolaborace (Communication diagram)
o
Interaction overview diagram (UML 2.0)
o
Scénáře událostí (Sequence diagram)
o
UML Timing Diagram (UML 2.0)
Strana 27
Obrázek 8: Zařazení diagramů v UML
Všechny prvky diagramů mohou mít své jméno, které je identifikuje. Prvek může mít také popisek (label), který přibližuje jeho význam nebo funkci. Prvky mohou mít přiřazeny poznámky (note), které představují informaci vztaženou k určité vlastnosti prvku (komentáře, omezující podmínky, atd.). Prvky mohou být na základě souvislosti, jak významem nebo funkčností, spojovány do skupin, či balíčků (package). Pomocí balíčků lze reprezentovat různé úrovně modelu. Balíček představuje funkční celek, který může mít k ostatním částem systému tzv. rozhraní. Popis funkcí uvnitř balíčku není pro rozhraní podstatný. Není tedy podstatný ani pro ostatní části systému používajících toto rozhraní a jedná se pouze o bližší specifikaci nebo model tohoto funkčního celku. Prvky mohou obsahovat omezující podmínky (constraints) nebo komentáře (comments) popisující význam modelu. Rozdíl mezi nimi je pouze v jazyku jakým je psán. Omezující podmínky jsou psány v jazyku, který je nástrojem, v něm je model vytvářen, určitým způsobem interpretován a zpracováván. Komentáře jsou psány „lidským” jazykem a jsou určeny pro čtenáře. Omezující podmínky jsou uváděny ve složených závorkách {omezující podmínka}. Prvek může mít řadu vlastností (atribut) a ty jsou definovány páry název = hodnota. Podrobněji mohou být prvky určeny stereotypem. Stereotyp je hodnota uvozená dvojitými lomenými uvozovkami «stereotyp». Stereotyp je důležitý pro definování role prvku. Existuje celá řada standardně definovaných stereotypů s přesně definovaným významem. Stereotyp může být definován sám svým modelem. V takovém případě má prvek diagramu reprezentující třídu stereotypu stereotyp «stereotyp». 3.3.3
Diagram užití
Diagram užití ukazuje funkčnost systému nebo třídy z hlediska vnějších uživatelů systému (ať už se jedná o uživatele lidské, nebo další části systému (objekty)). Uživatelé jsou reprezentováni obvykle ikonou postavy, v podstatě se však jedná o libovolné objekty se stereotypem «actor». Uživatelé se v diagramu nacházejí vně hranic systému naznačených obdélníkem uvnitř něhož se nacházejí prvky systému.
Strana 28 •
Případ užití (use case) Případ užití je celistvou funkční jednotkou poskytovanou systémem nebo třídou reprezentovatelnou posloupností zpráv mezi systémem a jedním či více uživateli systému spolu se změnami, které v důsledku této interakce v systému nastávají. Případ užití může zapouzdřovat podrobnější popis akcí a změn v systému, které mohou být podrobněji popsány v dalších diagramech. V diagramu je případ užití reprezentován elipsou s názvem případu užití.
Obrázek 9: Příklad USE CASE
•
Uživatel (actor) Uživatel je jeden nebo více objektů, které v roli uživatele (stereotyp «actor») přímo komunikují se systémem. Jeden objekt může plnit v komunikaci se systémem řadu různých rolí, a tudíž může být reprezentován řadou různých uživatelů. V diagramu jsou uživatelé obvykle reprezentováni jako ikony postav, nebo jako obdélníky (představující třídy) se stereotypem.
•
Vztahy v diagramu Mezi uživatelem a případem užití může existovat pouze jeden vztah postižitelný stereotypem «communicates». Tedy uživatel se systémem komunikuje. Vztahy však mohou existovat i mezi jednotlivými případy užití v rámci diagramu. Mohou existovat dva druhy vztahů:
3.3.4
-
Rozšíření («extend») – vztah z A do B znamená, že případ užití B v sobě může zahrnovat chování (na základě definovaných podmínek), které je popsáno v A.
-
Použití («include») – vztah z A do B znamená, že v A bude zahrnuto chování definované v B
Diagram tříd (Class Diagram)
Diagramy tříd se používají pro popis tříd a jejich vzájemných vztahů. Jedná se o diagram statických závislostí a nelze v něm postihnout dynamiku chování tříd. Diagram tříd je jedním ze základních modelů UML, třídy definované v diagramech tříd se objevují v řadě jiných druhů diagramů postihujících jiné pohledy na systém.
Strana 29 •
Třída (class) Třída sdružuje skupinu objektů se stejnou strukturou, chováním a vztahy, ale líší se jen hodnotami atributů. Instancí třídy je objekt. Třídě můžeme definovat atributy, metody a pomocí asociací i vztahy s dalšími třídami. V diagramu je třída značena obdélníkem, který může být rozdělen až na tři části. V první části je uvedeno jméno třídy, to je v rámci balíčku unikátní, a její eventuální stereotyp. Ve druhé části bývají uvedeny atributy a ve třetí operace této třídy.
Třída atributy operace Obrázek 10: Nákres třídy
•
Atributy třídy Třída může mít definovánu celou řadu atributů, každý z nich se v diagramu znázorňuje na samostatný řádek v následujícím formátu: viditelnost jméno : typ [násobnost] = počáteční hodnota {popis} -
Viditelnost atributu znamená jeho přístupnost z jiných tříd (podobně jako v C++). Může být veřejná (public), značí se +, chráněná (protected), značí se #, soukromá (private), značí se -, v rámci balíčku (package), značí se ~.
-
Násobnost označuje počet hodnot pole daného typu. Pokud není vyjádřena (včetně hranatých závorek), je implicitní hodnotou násobnost 1..1 značící právě jeden prvek.
-
Počáteční hodnota nemusí být definována (včetně znaku =) a značí počáteční hodnotu atributu.
Pomocí atributů lze popsat jakýkoliv vztah včetně těch, které jsou definovány asociacemi. •
Operace třídy Operacemi třídy znamenají operace definované nad touto třídou nebo metody, které třída poskytuje. Definice operace se zapisují v následujícím formátu: viditelnost jméno(parametry) : návratový typ {popis} -
Viditelnost viz. atribut
-
Parametry operace značí parametry, se kterými operace pracuje. Je to čárkami oddělený seznam definic parametru s následujícím formátem: druh jméno : typ = výchozí hodnota
-
Druh značí jde-li o vstupní (in) parametr, vstupně výstupní (inout), nebo výstupní (out) parametr. Pokud není druh specifikován, je výchozím druhem vstupní.
-
Výchozí hodnota (včetně =) může být vynechána.
Strana 30 •
Typy vztahů mezi třídami -
Asociace (association) Asociace je vztah mezi dvěma třídami. Tyto dvě třídy nemusejí být různé, tzn. může existovat vztah třídy sama se sebou. Asociace může být pojmenována. Asociace může být rozšířena o další atributy i operace, může se jednat o asociační třídu, která sama může být svázána dalšími asociacemi s dalšími třídami.
Obrázek 11: Příklad zobrazení asociace
-
Agregace (aggregation) Agregace je zvláštní druh asociace, která je určitým druhem kompozice objektů. Pokud je Komponenta agregována v Celku, pak Komponenta je částí Celku, ale jsou navzájem nezávislé z hlediska jejich „životního cyklu”.
-
Kompozice (composition) Kompozice je silnějším druhem agregace. Pokud je Celek kompozicí Komponenty, pak Komponenta je částí Celku a Celek má Komponentu plně pod kontrolou. Tedy Komponenta je nedílnou součástí Celku a nelze jej vnímat bez kontextu v němž existuje.
Obrázek 12: Příklad zobrazení kompozice
-
Generalizace (generalization) Generalizace je vztah mezi „rodičovským” elementem a jeho potomkem, který zcela dědí vlastnosti svých rodičů (jednoho nebo více) a definuje nové.
-
Realizace rozhraní (interface) Rozhraním se nazývají z vnějšku viditelné operace třídy, komponenty nebo jiných elementů (balíčky, …), u kterého není uvedena specifikace jeho vnitřní struktury. Rozhraní často specifikuje pouze část chování třídy. Rozhraní postrádá atributy, stavy, asociace, obsahuje pouze operace.
-
Závislost (dependency) Závislost značí situaci, kdy změna cílového elementu závislosti vyžaduje změnu počátečního elementu závislosti.
3.3.5
Stavový diagram (Statechart Diagram)
Stavový diagram se užívá k popisu chování instancí elementů modelu jako například objektů (instancí tříd), případů užití (use case), uživatelů (actor), podsystémů, operací, apod. Popisuje možné posloupnosti stavů a akcí, jimiž instance elementu může projít, jako reakci na různé události v modelovaném systému.
Strana 31 •
Stav (state) Objekt se nachází v určitém stavu, pokud jsou splněny v rámci jeho atributů určité podmínky, nebo se nachází v určité interakci splňující určité podmínky, či pokud vykonává nějakou akci, nebo čeká na nějakou událost.
•
Událost (event) Událostí nazýváme vznik určitého případu. V rámci stavových diagramů je to případ, který může vyvolat změnu stavu nějakého modelovaného objektu. Události jsou „viditelné”, tedy přijimatelné různými objekty vždy v rámci celého balíčku (package), ve kterém jsou definovány. Nelze vytvořit událost, která by byla viditelná pouze nějakou určenou třídou.
•
Přechod (transition) Přechod je vztah mezi dvěma stavy. Znázorňuje přechod instance z prvního stavu do druhého a provedení odpovídající akce, závisející na určité události a splnění daných podmínek.
Obrázek 13: Příklad stavového diagramu
3.3.6
Sekvenční diagram (Sequence Diagram)
Sekvenční diagram reprezentuje časovou posloupnost interakcí mezi třídami, jejich instancemi nebo případy užití. Nikdy nemodeluje všechny možné interakce nějakého objektu. Užívá se pro popis funkcí nutných ke splnění určitého úkolu. Na základě analýzy tohoto úkolu je pak vytvořen diagram, který zobrazuje všechny objekty a jejich interakce nutné ke splnění daného úkolu.
Strana 32 Sekvenční diagram je dvoudimenzionální. Svislá osa znázorňuje časový průběh a následnost jednotlivých operací, na vodorovné ose jsou vyneseny účastnící se objekty.
Obrázek 14: Příklad sekvenčního diagramu
3.3.7
Diagram spolupráce (Collaboration Diagram)
Diagram spolupráce vyjadřuje podobné aspekty modelu jako sekvenční diagram, neprezentuje však časovou posloupnost provádění jednotlivých akcí, spíše znázorňuje, dle svého názvu, způsoby spolupráce jednotlivých elementů modelu při řešení daného problému. Diagram spolupráce vyjadřuje buďto množinu rolí, které mohou „hrát” jednotlivé instance spolu s nutnými vztahy v kontextu daného problému, nebo znázorňuje přímo instance s jejich vztahy a zprávami, které mezi sebou zasílají tak, aby řešily daný problém. 3.3.8
Diagram komponent (Component Diagram)
Diagram komponent zobrazuje vztahy mezi softwarovými komponentami (třídy, …), jejich závislosti, způsoby komunikace, umístění a další. Ačkoliv komponenta nemá své vlastní vlastnosti, funguje jako seskupení tříd, které jsou již definovány se svými vlastnostmi. Tudíž komponenty mohou definovat svoje rozhraní, které definuje „služby” poskytované jednotlivými částmi komponenty. Diagram může obsahovat tato rozhraní a závislosti mezi komponentami (respektive jejich částmi). 3.3.9
Diagram nasazení (Deployment Diagram)
Diagramy nasazení zobrazují konfiguraci modelovaného systému za běhu a softwarové komponenty, procesy a objekty, které spouští procesy modelovaného systému.
Strana 33
4
ZABEZPEČENÍ
Prioritou každého informačního systému, který obsahuje citlivá data by mělo být zabezpečení proti zneužití těchto dat. To můžeme chápat jednak jako bezpečnost uložení dat aplikace, jednak jako bezpečnost komunikace klienta s aplikací a v neposlední řadě také jako ochranu před zneužitím nebo chybným použitím aplikace. V dalších kapitolách budou popsána možná bezpečnostní rizika a řešení jejich omezení v oblasti webových aplikací s přihlédnutím k tématu této diplomové práce, kterým je vytvoření informačního systému.
4.1
Bezpečné uložení dat Data využívaná systémem lze rozdělit do tří skupin: •
trvale ukládaná data, která jsou pod přímou správou aplikace, která je ukládá na nějaké médium (pevný disk počítače, apod.),
•
dočasná data používaná pro přechovávání přechodných nastavení aplikace,
•
trvale ukládaná data, pro jejichž správu je využito služeb databázového systému.
V každé z těchto skupin jsou určitá bezpečnostní rizika, která je nutno co nejvíce omezit. 4.1.1
Trvale ukládaná data aplikace
Pokud aplikace ukládá data přímo do souborového systému serveru, je nutno v co největší míře zajistit, aby k těmto datům nebylo umožněno přistupovat neoprávněným uživatelům. Pokud pokládáme samotný server za bezpečný, tedy nepředpokládáme, že není nutné chránit data před uživateli majícími přístup k serveru, musíme zajistit, aby tato data nebyla přístupná neoprávněným uživatelům. Protože interpret skriptů PHP je spouštěn přímo procesem webového serveru, je důležité zajistit správné nastavení oprávnění u adresáře ve kterém budou data ukládána. Je potřeba nastavit oprávnění tak, aby do něj tento proces mohl zapisovat a číst z něj. Zároveň však musíme zajistit, aby nebylo možné přistoupit k datům přímo pomocí URL i neautorizovaným uživatelům systému. Toto je možné zařídit zpřístupněním pomocí PHP skriptu, který zkontroluje oprávněnost přístupu. Samotná data by měla být uložena mimo webový prostor. Pokud je potřeba data ukládat do webového prostoru (kvůli externímu hostingu webu), musí být webový server nakonfigurován tak, aby data nevracel, i když je zadána URL, která odpovídá umístění těchto dat ve webovém prostoru (u serveru Apache jde o konfigurační soubor .htaccess). Tak mohou být data plně pod správou aplikace a nemůže dojít k jejich neoprávněnému získání. 4.1.2
Dočasná aplikační data
Pod pojmem dočasných dat se ve webových aplikacích obvykle myslí taková data, jež jsou potřeba k uchovávání aplikačních nastavení pro jednu návštěvu uživatele (typicky se jedná například o uchovávání obsahu košíku, aktuálně nastavenou jazykovou verzi a podobné informace). Návštěva uživatele proto musí být nějakým způsobem jednoznačně identifikována. V PHP je poskytována podpora pro uchovávání tohoto druhu informací pod názvem „session management“ (volně přeloženo správa návštěvy). Identifikaci návštěvy lze předávat v rámci každého HTTP požadavku, nebo může být uložena ve formě souboru cookie v rámci webového prohlížeče uživatele pracujícího s aplikací. Pokud můžeme identifikovat konkrétní návštěvu, můžeme pro ukládat pro ni specifická data. PHP poskytuje prostředky pro ukládání dočasných dat jednak do paměti (do paměťového prostoru web serveru, který PHP spouští), nebo do souborového systému serveru.
Strana 34 Způsob práce s dočasnými daty lze považovat za bezpečný, pokud je zajištěno, že třetí strana nemůže zjistit identifikaci návštěvy. To je možné pouze za použití zabezpečeného spojení mezi klientem a webovým serverem (viz kapitola HTTPS). 4.1.3
Data uložená v databázi
Bezpečnost uložení takovýchto dat je otázkou nastavení databázového systému. Pro zabezpečení dat je důležité, aby k nim v databázi měla přístup pouze aplikace, která tato data používá. Je nutné v databázovém systému vytvořit uživatelský účet se jménem a heslem, který dovoluje aplikaci přistupovat k datům. Práva na databázi by měla být nastavena tak, aby k ní mohl přistupovat jen „uživatel“ daného jména a hesla. Dále se doporučuje uživateli omezit práva na jednotlivých tabulkách na nezbytné minimum tak, aby byla zajištěna správná funkčnost aplikace. Mimo zabezpečení samotných dat, je potřeba zajistit také bezpečnost komunikace mezi aplikací a databázovým serverem. MySQL umožňuje používat šifrovanou komunikaci pomocí SSL. Tato volba by byla ideální, pokud by se databázový server a aplikace nacházeli na různých počítačích a byli nuceni používat komunikaci přes síť. V současné době však tuto možnost nepodporuje interpret PHP, a proto je potřeba použít nezabezpečenou komunikaci a spolehnout se pouze na ochranu dat databázovým systémem. Pokud se databázový server a webový server nacházejí na jednom počítači, stačí ke stejné úrovni zabezpečení dat nastavit práva na databázi tak, aby se k datům mohla dostat aplikace pouze z tohoto serveru a byl zamezen přístup k datům z jiných serverů.
4.2
Komunikace
Zabezpečení komunikace přes síť Internet mezi serverem a klientem by mělo být důležitou vlastností systému, který pracuje s citlivými daty. V následujících kapitolách bude rozebrána podstata bezpečného spojení mezi klientem a webovým serverem. 4.2.1
HTTP
HTTP (Hypertext Transfer Protocol) je jednoduchý aplikační protokol vystavený nad protokolem TCP. Tento bezstavový protokol vystavený na modelu požadavek - odpověď je užíván zejména pro přenos dat v rámci sítě WWW. Existuje několik verzí tohoto protokolu, kdy nejnovější verze 1.1 je podporována většinou prohlížečů. Data přenášená pomocí tohoto protokolu nejsou žádným způsobem šifrována a jsou přenášena v čisté textové formě. V rámci HTTP existuje koncept autentifikace pro přístup k určitým zdrojům, problémem však je již zmíněná absence jakéhokoliv šifrování obsahu (včetně například přístupových hesel), který je zpřístupněn na základě úspěšné autentifikace. Tento protokol je tedy úplně nepoužitelný v situaci, kdy potřebujeme data, či postup autentifikace nějakým způsobem zabezpečit před zneužitím. 4.2.2
HTTPS
HTTPS není dalším typem komunikačního protokolu, ale jde o nástavbu protokolu HTTP, která poskytuje zvýšenou bezpečnost před odposloucháváním či podvržením dat. Zkratka HTTPS znamená „HTTP over SSL“, tedy komunikace pomocí HTTP protokolu pomocí spojení šifrovaného protokolem SSL nebo novějším TSL. Scénář spojení je takový, že nejdříve se ustaví šifrované spojení pomocí protokolu SSL(TSL). Po jeho navázání probíhá komunikace naprosto stejně jako při použití čistého HTTP protokolu. Tento postup má obrovskou výhodu, jelikož zachovává zpětnou kompatibilitu se staršími aplikacemi využívajícími protokol HTTP a zároveň poskytuje účinné zabezpečení takovéto komunikace proti většině typů zneužití, odposlechu, atd.
Strana 35 4.3
Šifrování
V této kapitole se budeme zabývat základními pojmy a obecnými principy šifrování dat. Rozebraných principů a pojmů potom použijeme k vysvětlení principů SSL. Šifrování neboli kryptografie je nauka o metodách utajování smyslu zpráv převodem do podoby, která je čitelná jen se speciální znalostí. Slovo kryptografie má původ v řečtině – kryptós znamená skrytý a gráphein znamená psát. Někdy je pojem obecněji používán pro vědu o čemkoli spojeném se šiframi jako alternativa k pojmu kryptologie. Kryptografie se po staletí vyvíjela k větší složitosti zároveň s lidskou civilizací a mnohokrát ovlivnila běh dějin. Zejména utajení či vyzrazení strategických vojenských informací mělo a má obrovský význam, ale i vyzrazení jinak citlivých dat (čísla bankovních karet, hesel atd.) a podobně, to vše úzce závisí s bezpečným přenosem informací a se schopnostmi protivníka šifru rozbít. Na začátku je potřeba definovat několik pojmů z oblasti šifrování.
4.3.1
•
Šifrovací algoritmus – je algoritmus užívající nějakou šifrovací metodu, která většinou vychází z přesné matematické definice a provádí samotné šifrování nebo dešifrování dat.
•
Šifrovací klíč – je informace, která určuje průběh šifrovacího algoritmu. Při šifrování, klíč specifikuje transformaci zprávy do šifrovaného textu, při dešifrování je tomu naopak.
•
Délka klíče – je velikost šifrovacího klíče pro šifrování nebo dešifrování zprávy. Klasická kryptografie používá klíče, které můžou být omnoho kratší než zpráva, nicméně dostatečně dlouhé na to, aby nebylo možné vyzkoušet všechny možnosti. 80 bitů je považováno za minimální délku klíče pro symetrickou kryptografii. Běžně se užívají 128-bitové klíče.
•
Síla šifry – údaj vyjadřující minimální množství úsilí nutného k prolomení daného šifrovacího algoritmu.
•
Obousměrná šifra – šifrovací algoritmus u kterého je možné se znalostí správného klíče zašifrovat i dešifrovat danou zprávu.
•
Jednosměrná šifra – na rozdíl od obousměrné šifry není možno zašifrovanou zprávu jednoznačně dešifrovat. Tato na první pohled nevyužitelná šifra má své uplatnění například při vytváření kontrolních součtů zpráv nebo digitálních podpisů.
•
Prolomení – prolomení šifrovacího algoritmu znamená správně rozšifrovat zašifrovaný text bez znalosti šifrovacího klíče. Každý šifrovací algoritmus je vymýšlen se snahou minimalizovat riziko prolomení.
Šifrovací algoritmy Šifrovací algoritmy se dělí na dvě základní skupiny: •
Symetrické algoritmy – pro zašifrování i rozšifrování zprávy je použito jediného klíče. Velkou výhodou těchto algoritmů je nízká výpočtová náročnost, naopak nevýhodou je sdílení tajného klíče mezi odesílatelem i příjemcem.
•
Asymetrické algoritmy – pro zašifrování a dešifrování je použito dvou různých klíčů (soukromý a veřejný klíč). Zprávu zašifrovanou pomocí jednoho klíče lze rozšifrovat pouze pomocí druhého a naopak. Existuje vždy jeden unikátní pár soukromý-veřejný klíč. Soukromý klíč je dle svého názvu určen jedné osobě a měl by být znám pouze jí. Veřejný klíč je naopak určen pro zveřejnění a může být znám komukoliv.
Strana 36 4.3.2
Kontrolní součty
Tento termín více odpovídá funkci, kterou tento mechanismus vykonává, než doslovný překlad anglického termínu Message Digest – výtah zprávy. Někdy se kontrolní součet označuje termínem „hash kód“. Kontrolní součty vznikají použitím jednocestných šifrovacích algoritmů. Důležitou vlastností výsledků šifrování vzniklých při použití hashovacích algoritmů je jejich jednotná délka. Zašifrováním libovolně dlouhé vstupní zprávy vznikne tedy vždy výsledek jedné délky. Díky této vlastnosti může pro daný kontrolní součet existovat více původních zpráv, pro které je kontrolní součet shodný. Je dokázáno, že vzhledem k délce součtu (obvykle 128 bitů) a použitým algoritmům, je velice nepravděpodobné, že by vznikly dva různé dokumenty se stejným kontrolním součtem. Kontrolní součty jsou zmíněny díky jejich důležitosti při tvorbě digitálních podpisů a také kvůli použití jako prostředku ke kontrole integrity dat. 4.3.3
Digitální podpis
Digitální podpisy slouží ke kontrole autenticity a integrity dat. Ke kontrole integrity lze použít i kontrolních součtů, ty ale není možné použít k zaručení autenticity zprávy (tedy k zaručení „původu“ zprávy). Digitální podpis má všechny vlastnosti psaného podpisu a svou odolností vůči padělání jej v určitém úhlu pohledu dokonce předčí. K realizaci podpisu je využit asymetrický šifrovací algoritmus RSA. Digitální podpis nešifruje zprávu, je k ní pouze připojen pro ověření autenticity zprávy příjemcem a zpráva i bez něj čitelná.
Obrázek 15: Schéma použití elektronického podpisu pro autorizaci i autentizaci zprávy
Při tvorbě digitálního podpisu se nejdříve vytvoří kontrolní součet zprávy, který se následně zakóduje pomocí privátního klíče. Příjemce je pak schopen s odpovídajícím veřejným klíčem ověřit autenticitu zprávy – tedy se podařilo rozšifrovat i integritu – tedy odpovídá kontrolní součet přijaté zprávy. Při užívání digitálních podpisů je potřeba vyřešit jeden podstatný problém, který s jejich použitím souvisí a to je právě distribuce veřejných klíčů.
4.3.4
Distribuce veřejných klíčů a certifikační autority
Znalost odpovídajících veřejných klíčů je rozhodující pro mnoho oblastí zabezpečené komunikace pomocí asymetrických šifrovacích algoritmů jako jsou například výše uvedené digitální podpisy, obecně šifrování zpráv, či šifrovaná komunikace (SSL).
Strana 37 Základní schéma navázání komunikace mezi dvěma subjekty, které by spolu chtěli komunikovat by mohl vypadat například takto:
A → B : A zašle B svůj veřejný klíč B → A : B zašle A svůj veřejný klíč A ↔ B : posílají si navzájem zprávy šifrované veřejným klíčem svého protějšku. Tento typ komunikace však není odolný vůči útokům typu „Man-in-the-middle“. Jde o situaci, kdy útočník je prostředníkem komunikace mezi A a B. Proto je důležité zaručit nějakým způsobem pravost komunikujících subjektů, jinak si komunikující strany nemohou být jisty bezpečností jejich šifrované komunikace. Autenticita takovéhoto klíče bývá zaručena pomocí digitálního podpisu. Princip a problémy spojené s podepisováním klíčů budou zmíněny. Pokud obdržíme od protějšku podepsaný veřejný klíč, nedává nám podpis ještě žádnou záruku pravosti, pokud není zaručena pravost subjektu (tedy přesněji její veřejný klíč), který klíč podepsal. Tady se dostáváme k obdobnému problému jako je nepodepsaný klíč. Musíme proto znát další veřejný klíč, pomocí něhož bychom mohli ověřit pravost námi požadovaného klíče. I přes tento nedostatek je tento postup používán. Existují veřejné subjekty, takzvané certifikační autority, které podepisují a tímto zaručují pravost veřejného klíče jiných společností. Samotné certifikační autority jsou povinny uveřejnit otisk (výtah zprávy) svého veřejného klíče v neelektronickém médiu (např. kniha, apod.). Takto vznikne elektronicky nenapadnutelný zdroj, z něhož jsme pak schopni ověřit pravost klíče certifikační autority.
Obrázek 16: Schéma stromu certifikačních autorit
Každá certifikační autorita na vyžádání subjektu ověří jeho pravost, tedy si ověří, že daný subjekt je opravdu ten, za který se vydává a vystaví mu tzv. certifikát. To je již podepsaný veřejný klíč daného subjektu spolu s dalšími informativními údaji. Každý certifikát má jen určitou časovou platnost, po jejím uplynutí je potřeba o něj opět požádat. Certifikát můžeme, pokud máme důvěru k certifikační autoritě, která jej vydala, považovat za důkaz pravosti subjektu, se kterým komunikaci vedeme.
Strana 38 4.3.5
SSL
SSL (Secure Sockets Layer) je protokol, respektive vrstva vložená mezi vrstvu transportní (např. TCP/IP) a aplikační (např. HTTP), která definuje postupy nutné k zabezpečení komunikace šifrováním a autentizaci komunikujících stran.
Obrázek 17: Pozice protokolu SSL v TPC/IP modelu
V předcházející kapitole byly vysvětleny základní principy zabezpečené šifrované komunikace z kterých vychází způsob práce protokolu SSL. Při navázání komunikace protokol SSL používá ověřování pomocí certifikátů. Základní schéma navazování spojení pomocí SSL vypadá dle specifikace takto:
Obrázek 18: Diagram navázání SSL komunikace mezi klientem a serverem
Z levé strany vycházejí činnosti iniciované od klientské strany a na pravé pak činnosti serveru. Části komunikace označené hvězdičkou nemusejí proběhnout. Na počátku každé komunikace je pozdrav klienta se serverem. Během něho si obě strany dohodnou základní nastavení komunikace. V této části může být obnovena dřívější relace (session) – pokud existuje. Jako součást pozdravu jsou odeslány údaje o vlastnostech klienta tak serveru
Strana 39 (podporovaná verze protokolu, použitelné šifrovací algoritmy, apod.). Další zprávy vždy obsahují kontrolní součty vytvořené z náhodných číslic obsažených v pozdravech klienta i serveru a určitých dalších parametrů, aby byla zaručena autenticita komunikace. Po úspěšném vykonání pozdravu zasílá server klientovi svůj certifikát (byl-li vyzván), případně jinou formu klíče, pokud certifikát nevlastní, a nebo je použita šifrovací metoda vyžadující nějaký klíč. Při další komunikaci je ustaven klíč sezení (master secret) pomocí dočasného klíče sezení a dalších údajů vyplynuvších ze vzájemné komunikace (ta je již asymetricky šifrována pomocí veřejných klíčů). Klíč sezení je pak poprvé použit k zašifrování zprávy „Konec úvodního nastavení“, tímto se spojení považuje za ustavené a může začít vzájemná výměna dat. Protokol SSL je navržen tak, že je zcela nezávislý použitých algoritmech. Tím pádem probíhající komunikace může být šifrována celou řadou různých šifrovacích algoritmů. Mezi nimi je možné uvést například:
4.4
•
Asymetrické algoritmy pro ustavení komunikace: FORTEZZA, RSA, ElGamal, KEA …
•
Symetrické pro vlastní výměnu dat: DES (a jeho variace), RC2, RC4, IDEA, …
•
Pro vytváření kontrolních součtů: MD5, SHA.
Zamezení zneužití
Jak bylo zmíněno v kapitole CGI, je důležitou vlastností webové aplikace její ochrana před zneužitím např. podvržením chybných parametrů či jejich vynecháním v URL pro nějaký skript. Žádná zabezpečená aplikace by neměla proto v žádném případě spoléhat na korektnost a úplnost očekávaných vstupů. Data bývají v rámci HTTP protokolu předávána textovou formou a tím pádem nelze zaručit, že obdržená data budou mít očekávaný datový typ. Mělo by být zcela v režii aplikace zkontrolovat správnost vstupů a případně je převést na očekávaný datový typ. Tato konverze získává na důležitosti zejména pokud se takto obdržená data mají stát součástí SQL dotazu, pomocí něhož je nějaká informace z databáze získávána nebo naopak ukládána. Možný útočník může jako vstup pro skript nastavit data taková, že mohou vést k vytvoření „nebezpečného“ SQL dotazu. Takto sestavený dotaz může zapříčinit buď „pouhé“ selhání SQL dotazu, nebo mnohem horší variantu, kdy dojde k sestavení dotazu ze zadaných dat, že dotaz provede úplně jiný SQL dotaz než měl aplikační programátor na mysli. Tímto způsobem může dojít až k destruktivním akcím typu vymazání dat z databáze, apod. Takovýto typ útoku bývá nazýván anglickým termínem „SQL injection“ a obranou před ním je právě důsledná konverze dat na očekávané datové typy. To samo o sobě ovšem nestačí. Protože velké množství dat zadávaných do databázového systému je v podobě znakových řetězců, je důležité, aby z těchto řetězců byly vyloučeny znaky, kterými by bylo možno ovlivnit SQL příkaz. Textová data musí být proto ošetřena tak, aby se zamezilo tomuto zneužití. Ošetření se nazývá „quoting“ a PHP funkce pro komunikaci s databázovým serverem MySQL obsahují funkci provádějící quoting řetězce.
Strana 40
Strana 41
5
ANALÝZA POŽADAVKŮ NA SYSTÉM
5.1
Požadavky zadavatele Požadavky vyplývající ze zadání a úvodního jednání se zadavatelem:
5.2
•
realizace informačního systému a jeho funkčnost
•
přehlednost uživatelského rozhraní,
•
příjemné uživatelské rozhraní,
•
výkonnost,
•
bezpečnost,
•
přenositelnost,
•
nízké pořizovací náklady,
•
přístup uživatelů do jednotlivých sekcí dle nastavených práv,
•
souběžný přístup více uživatelů,
•
využití stávajícího hardwarového řešení.
Zjištění potřeb uživatelů
Aby bylo možné provést funkční analýzu potřeb uživatelů systému, je potřeba zvolit vhodnou formu komunikace mezi zainteresovanými osobami. Zjistit typické role v jakých tito uživatelé vystupují a zvolit metodiku podle které bude následná analýza probíhat. Tato důležitá část návrhu systému byla ze začátku podceněna. Poté co komunikace se zadavatelem a ostatními osobami byla spíše sporadická a vedla ke vzniku velkého množství nesprávných řešení, tedy řešení jiných, než byla požadována ,bylo potřeba stanovit jasná pravidla, hierarchii zodpovědnostosti atd. Způsob výměny informací uvnitř i vně organizace, který do této chvíle probíhal podle zvyklostí zadavatelské organizace, se musel změnit. Neboť i důležitá sdělení se předávala způsobem – „Až ho uvidíš tak mu to řekni…“. Bylo proto nutné domluvit si jasná pravidla, aby nadále nedocházelo k nedorozuměním vedoucím k významným časovým ztrátám. Dohodnout funkční komunikační model bylo složitější díky množství dotčených osob. Občas to byly osoby, kterých se projekt dotýkal jen minimálně a jejich odhodlání spolupracovat bylo, i díky jejich ochotě zaběhnuté věci změnit, velice nízké. Nakonec nejdůležitějšími osobami se z mého pohledu stali: ředitel organizace a předseda správní rady – tedy zadavatel a jeho zástupce. V tomto složení jsme absolvovali několik jednání a domluvili se na použití komplexního modelovacího jazyka UML. Protože se nikdo ze zúčastněných osob, vzhledem ke svému humanitně orientovanému vzdělání, s modelovacím jazykem UML nesetkal, bylo potřeba ze začátku velké množství věcí vysvětlovat, popisovat a kreslit. Po zvládnutí této úvodní fáze jsme, ale rychle zjišťovali, že je možné tohoto jazyka využít pro přenos informací a myšlenek. Bylo ovšem důležité mít na zřeteli kontext vývoje, pokud někdo vstoupil do procesu návrhu později a neúčastnil se fáze „osvěty“, tak nebyl schopen se účinně zapojit. Což u starších metod návrhu – např. EAR + DFD není takovým problémem. Tedy, podle mého názoru, UML jako jazyk modelování klade vysoké požadavky na znalosti a analytické schopnosti všech zúčastněných. V další kapitole bude popsána samotná analýza potřeb a požadavků kladených na systém jak ze strany zadavatele, tak i dalších zúčastněných potencionálních uživatelů. K analýze budou použity vhodné prostředky modelovacího jazyka UML
Strana 42 5.3
Analýza potřeb uživatelů pomocí technik jazyka UML
Prvním úkolem bylo potřeba najít a označit všechny zúčastněné osoby a přidělit jim příslušné role. Jedné osobě může být přiděleno více rolí. Tímto vznikne seznam potencionálních uživatelů systémů – aktérů, se kterými je třeba spojit možné případy užití. Z nich je možné vytvořit model definující základní případy užití modelového systému. Mezi zúčastněnými osobami byly identifikovány následující role: •
Zaměstnanec – zaměstnanec organizace, který získal oprávnění se systémem pracovat
•
Účetní – zaměstnanec pověřený správou příspěvků členů organizace
•
Ředitel – ředitel organizace kontrolující vše
•
Člen správní rady – volený člen správní rady
•
Administrátor – zaměstnanec pověřený správou systému
Obrázek 19: Vysokoúrovňový diagram případů užití vyjadřující hlavní požadavky IS
Strana 43 Zaměstnanec – uživatel systému který má možnost využívat kontakty členů. Mají možnost adresy vkládat, upravovat i mazat. Každý kontakt mohou zařadit do některé ze skupin.
Obrázek 20: Diagram případů užití zaměstnanec
Účetní – jediná část systému, ke které by jej měla zajímat je agenda týkající se členských příspěvků. Mohou příspěvky vkládat, mazat a opravovat.
Obrázek 21: Diagram případů užití účetní
Strana 44 Člen rady – uživatel mající přístup pouze k interním dokumentům organizace.
Obrázek 22: Diagram případů užití člena rady
Administrátor – těchto uživatelů může být i více, jejich hlavním úkolem je správa systému. Administrátoři mohou vytvářet, mazat a upravovat uživatelské účty. U existujících účtů mohou přidávat a odebírat jednotlivým uživatelům oprávnění. Mají možnost také účet dočasně zablokovat.
Obrázek 23: Diagram případů užití administrátor
Strana 45 Ředitel – speciální typ účtu, který umožňuje přístup a úpravu všech částí systému s výjimkou administrace systému a správy uživatelských účtů.
Obrázek 24: Diagram případů užití ředitele
Dále jsem na základě rozhovorů a připravené série dotazů všechny případy užití rozebral až na úroveň scénářů. Z této doplňující analýzy jsem získal větší množství nových informací, na základě kterých jsem model rozšířil o další případy užití. Takto vytvořený model systému bylo následně potřeba komplexně zpracovat. Zde jsem využil některé další techniky modelovacího jazyka UML, jako jsou vkládání, rozšíření a zobecnění, které umožňují významným způsobem zjednodušit a zefektivnit celkový model systému. Na základě popsané analýzy funkčních požadavků vznikl následující komplexní model systému modelovaný technikou diagramů případů užití jazyka UML.
Strana 46
Obrázek 25: Model případů užití znázorňující pohled na celý informační systém
Na obrázku je zobrazen celkový model informačního systému, jehož celková koncepce vznikla za pravidelných konzultací řešitelů. Jak vyplývá z požadavků cílových skupin navrhovaný systém musí poskytovat tyto základní akce: •
přihlášení do systému – každý uživatel chtějící použít informační systém se musí nejprve do systému přihlásit. To provede zadáním přihlašovacího jména a hesla, které mu bylo přiděleno administrátorem,
•
Adresář – uživatel zvolí modul systému Adresář se kterým bude pracovat o
vyhledání adresy – uživatel může vyhledat jednotlivou adresu
o
úprava kontaktu - uživatel s příslušným oprávněním může vkládat nové adresy nebo upravovat stávající
Strana 47 •
•
•
•
Poplatky – uživatel zvolí modul systému Poplatky se kterým bude pracovat o
vyhledání neplatičů – systém pro zadaný rok vyhledá členy organizace, kteří nezaplatili členský příspěvek
o
vložení platby – uživatel s příslušným oprávněním má možnost vložit do systému přijatou platbu
Dokumenty – uživatel zvolí modul systému Dokumenty se kterým bude pracovat o
vyhledání dokumentu – uživatel může vyhledání dokument podle krytérií
o
vložení dokumentu – uživatel s příslušným oprávněním může vkládat do systému nové dokumenty a organizovat je
Administrace – uživatel zvolí modul systému Administrace se kterým bude pracovat o
nový uživatel - uživatel(administrátor) může vložit nového uživatele
o
úprava uživatele – uživatel může měnit přihlašovací údaje a oprávnění
Odhlášení od systému – práce se systémem končí odhlášením.
Kvůli větší ochraně a bezpečnosti celého navrhovaného systému je zaveden tzv. time-out neboli vypršení sezení. To znamená, že sezení je po jisté době nečinnosti zrušeno a uživatel, pokud chce dále se systémem pracovat, se musí znovu přihlásit. Tato událost je v diagramu případů užití znázorněna externím participantem, který po uplynutí time-outu generuje požadavek na zrušení sezení. Další analýzou vypsaných případů užití systému jsem získal podrobnější případy pro jednotlivé základní systémové požadavky. Pro příklad pohledu z nižší úrovně bude popsán model administrace systému. Výsledek modelující tuto úroveň pohledu na část systému reprezentuje obrázek Případ užití “úprava uživatele”.
Obrázek 26: Diagram případ užití „úprava uživatele“
Strana 48 5.4
Databáze
Návrh databáze spočívá ve vytvoření hlavních tabulek a související infrastruktury okolo nich, k zajištění normálných forem. Z předešlé analýzy můžeme získat základní tabulky: clenove, skupiny, typ_clena, poplatky, uzivatele, opravneni, logfile a dokumenty. V tabulce clenove budou záznamy o všech kontaktech clenu, kteří mohou, ale nemusí být členy nějaké skupiny. Vztahy jsou znázorněny na následujícím obrázku. Přes spojovací tabulku prop_skup je zajištěn vztah clenove:skupiny – M:N. Na clenove je navázán typ_clena. Vztahem typ_clena:clenové 1:N je zajištěno, že člen musí mít přiřazenu jeden typ členství.
Obrázek 27: Relace clenove – skupina
Další vztah zajišťuje přiřazení příspěvku clenovi. Vztah je řešen relací clenove:poplatky 1:N. Tedy jeden člen může mít více příspěvků, ale jeden příspěvek může mít jen jednoho platícího.
Obrázek 28: Relace clenove – poplatky
Tento vztah popisuje relaci mezi uživatelem a skupinou oprávnění. Vztah uzivatel:opravneni je zde řešen vztahem 1:1. Na tabulku opravneni je vazan vztahem 1:N popis_opravneni.
Obrázek 29: Relace uzivatel - opravneni
5.5
Rozbor zjištěných požadavků
Důraz u uživatelského rozhraní bude kladen na přehlednost, podporu více WWW prohlížečů a výkonnost. Výkonnosti je dosaženo výběrem výkonného databázového serveru, operačního systému a efektivního skriptovacího jazyka. Přitom velice důležitou roli bude hrát vyváženost uvedených kritérií. Bezpečnost závisí na výběru bezpečného databázového serveru a zabezpečeného operačního systému. Pro veškerou komunikaci s klientem bude nutné používat šifrovaný typ přenosu dat. Autorizovaný uživatel bude mít pro přístup do systému přiděleno jedinečné přihlašovací jméno a heslo. Uživateli přidělené číslo session (popisované dále) mu bude po definovaném čase nečinnosti z bezpečnostních důvodů odebráno, aby se zabránilo neautorizovanému přístupu k účtu přihlášeného uživatele. Pokud se tak stane, bude uživatel nucen znovu zadat své přihlašovací jméno a heslo. Souběžný přístup více uživatelů bude řešen přidělením jedinečného čísla session, které bude přihlášeného uživatele provázet až do doby jeho odhlášení.
Strana 49
6
APLIKACE VYTVOŘENÉHO ŘEŠENÍ
Na základě provedené analýzy požadavků a po konzultaci se zadavatelem byl následně navržen a implementován systém. K jeho vytvoření a provozování byly zvoleny následující prostředky, které splňují dohodnutá kritéria.
6.1
Použité prostředky
Následující podkapitoly by měly ukázat důvody volby prostředků pro implementaci informačního systému v rámci této diplomové práce. Zejména z finančních důvodů kladených zadavatelem byla vyloučena všechna komerční řešení. Důležitým rozhodnutím je volba jazyka pro implementaci systému a volba databázového systému pro ukládání dat. Jsou jim proto věnovány samostatné podkapitoly. 6.1.1
WWW server
Z důvodů přenositelnosti a finanční náročnosti bude nejvhodnější použít volně dostupný server Apache, který navíc dobře spolupracuje s PHP skripty a splňuje výkonnostní nároky projektu. 6.1.2
MySQL
Hlavní nevýhody tohoto databázového systému byly uvedeny již v kapitole zabývající se jeho popisem. Databázový systém MySQL postrádá velké množství pokročilých funkcí běžných u komerčních řešení. Ovšem schopnosti, které MySQL přesto poskytuje, zdaleka přesahují základní požadavky na databázový systém, zejména úroveň podpory jazyka SQL. Systém MySQL poskytuje propracovaný systém uživatelských práv, pomocí kterého můžeme přiřazovat práva na čtení, úpravu, vkládání, atd. až na úrovni jednotlivých sloupců tabulek databáze. Hlavní předností tohoto systému je opět volná dostupnost, přenositelnost, rychlost provádění dotazů při vysoké zátěži serveru a výborná stabilita systému ověřená použitím v mnoha komerčních společnostech i nekomerčních organizacích. 6.1.3
PHP
Ve srovnání s jazykem Perl nabízí skoro stejné schopnosti a vlastnosti. Mezi objektivní důvody pro volbu jazyka PHP patří velká rozšířenost mezi poskytovateli webového prostoru, díky svým vlastnostem a možnostem konfigurace speciálně navrženým pro použití PHP jako webového skriptovacího jazyka, a opět jeho přenositelnost mezi platformami. Jak bylo napsáno v popisu, umožňuje jazyk PHP podporu pro objektově orientovaný vývoj aplikací. Syntaxe jazyka umožňuje velice jednoduše a efektivně vytvářet složité datové struktury a nekomplikovaným způsobem s nimi pracovat. Velkou předností jazyka PHP je možnost načítání definičních skriptů až na základě situace vyžadující použití funkcí či objektů definovaných v těchto skriptech, a to velice jednoduše. V případě dobrého návrhu je tak možno naprogramovat i velice komplexní aplikaci a zároveň nesnížit rychlost zpracování a provedení zdrojového textu. Toto je možné jen díky tomuto přístupu, kdy není nutné načítat všechny zdrojové texty, ale jen ty, které jsou nutné k provedení právě zpracovávaného požadavku. PHP tedy poskytuje řadu syntaktických konstrukcí, které umožňují vytvářet velice složité a přesto efektivní aplikace zbytečně nezatěžující server výpočetními a paměťovými nároky na jejich zpracování.
Strana 51 6.3
Návrh databáze
Po provedení analýzy funkčních požadavků a jejího následného zpracování byla navržena celková koncepce informačního systému. Komplexně navrženou datovou strukturu informačního systému znázorňuje následující obrázek.
Obrázek 31: Zobrazení celkové struktury a relací v databázi
V dalších podkapitolách je uveden navržený systém databáze, který je popsán formou jednotlivých tabulek. U každé tabulky jsou uvedeny definice primárních a cizích klíčů a jednoduchý popis obsahu, k jehož uložení tabulka slouží. Jednotlivé atributy tabulky jsou popsány čtyřmi vlastnostmi: jméno atributu, datový typ (znak, řetězec znaků, číslo, datum … ), následuje rozměr tohoto údaje případně „maska“ údaje a poslední položkou v tabulce je stručný slovní popis jednotlivých atributů s vysvětlením vzájemných relací.
Strana 52 6.3.1
Popis jednotlivých tabulek informačního systému
Poznámka: V tabulkách je primární klíč vyznačen podtrženým a tučným písmem, cizí klíč je vyznačen pouze tučným písmem.
Atribut
Typ
Velikost
Popis
id_clena
int
10
Identifikace kontaktu
foto_clena
varchar
255
Fotografie kontaktu
jmeno_clena
varchar
20
Jméno kontaktu
prijmeni_clena
varchar
50
Příjmení kontaktu
dat_naroz_clena
date
0000-00-00
Datum narození kontaktu
email_clena
varchar
100
Email kontaktu
prezdivka_clena
varchar
50
Přezdívka kontaktu
tel_clena
varchar
100
Číslo telefonu
mobil_clena
varchar
100
Číslo mobilu
ulice_clena
varchar
255
Ulice adresy
mesto_clena
varchar
50
Město adresy
psc_clena
int
5
PSČ adresy
k_det_clena
varchar
255
Detail adresáta
k_ulice_clena
varchar
255
Ulice korespond. adresy
k_mesto_clena
varchar
50
Město korespond. adresy
k_psc_clena
int
5
PSČ korespond. adresy
posta_clena
enum
ano/ne
Zasílat korespondenci
id_typ_clena
tinyint
2
Vazba na tab. clenství_typ
vede_deti
enum
ano/ne
Údaj jestli vede dětský kolektiv
jak_vede
varchar
255
Detail (kde, jak vede)
aktual_clena
datetime
0000-00-00 00:00:00
Datum poslední aktualizace
Tabulka 1: Tabulka clenove
Název tabulky: clenove Popis tabulky: Tabulka slouží k uložení informací o veškerých kontaktech a je společná jak pro sekci adresář tak poplatky … Primární klíč: id_clena Cizí klíče:
id_typ_clena odkazuje na tabulku clenstvi_typ
Strana 53
Atribut
Typ
Velikost
Popis
id_typ_clena
tinyint
2
Identifikace typu člena
stat_clena
varchar
50
Název typu člena
Tabulka 2: Tabulka clenstvi_typ
Název tabulky: clenstvi_typ Popis tabulky: Pomocná tabulka slouží k uložení informací o možných typech členství. Primární klíč: id_typ_clena Cizí klíče:
-
Atribut
Typ
Velikost
Popis
id_ekoklub
tinyint
2
Identifikace ekoklubu
ekoklub
varchar
50
Název ekoklubu
Tabulka 3: Tabulka ekoklub_typ
Název tabulky: ekoklub_typ Popis tabulky: Pomocná tabulka slouží k uložení informací o možných ekoklubech. Primární klíč: id_ekoklub Cizí klíče:
-
Atribut
Typ
Velikost
Popis
id_eko_spoj
int
6
Identifikace spojení
id_clena
int
6
Vazba na tabulku clenove
id_ekoklub
tinyint
2
Vazba na tabulku ekoklub_typ
Tabulka 4: Tabulka eko_spoj
Název tabulky: eko_spoj Popis tabulky: Spojovací tabulka slouží k propojení tabulky clenove a ekoklub_typ. Obsahuje informace o členství v ekoklubu. Primární klíč: id_eko_spoj Cizí klíče:
id_clena odkazuje na tabulku clenove, id_ekoklub odkazuje na tabulku ekoklub_typ
Strana 54
Atribut
Typ
Velikost
Popis
id_skupiny
int
5
Identifikace skupiny
skupina
varchar
255
Název skupiny
Tabulka 5: Tabulka skup_clenu
Název tabulky: skup_clenu Popis tabulky: Pomocná tabulka slouží k uložení informací o možných skupinách, kterých může být kontakt členem. Primární klíč: id_skupiny Cizí klíče:
-
Atribut
Typ
Velikost
Popis
id_prop_sk
int
10
Identifikace propojení skupiny
id_clena
int
10
Vazba na tabulku clenove
id_skupiny
int
5
Vazba na tabulku skup_clenu
Tabulka 6: Tabulka prop_skupin
Název tabulky: prop_skupin Popis tabulky: Spojovací tabulka slouží k propojení tabulky clenove a skup_clenu. Obsahuje informace o členství ve skupinách. Primární klíč: id_prop_sk Cizí klíče:
id_clena odkazuje na tabulku clenove, id_skupiny odkazuje na tabulku skup_clenu
Atribut
Typ
Velikost
Popis
id_prisp
int
10
Identifikace příspěvku
id_clena
int
10
Vazba na tabulku clenove
prispevek_rok
year
4
Rok příspěvku
datum_zaplac
date
0000-00-00
Datum zaplacení příspěvku
doklad
varchar
50
Doklad
cena_zaplac
int
5
Velikost příspěvku
Tabulka 7: Tabulka prispevky
Název tabulky: prispevky Popis tabulky: Tabulka slouží k uložení informací o veškerých příspěvcích členů. Primární klíč: id_prisp Cizí klíče:
id_clena odkazuje na tabulku clenove
Strana 55
Atribut
Typ
Velikost
Popis
id_dokum
int
10
Identifikace dokumentu
path_dokum
varchar
255
Jméno souboru
popis_dokum
varchar
255
Popis dokumentu
id_kat_dokum
int
3
Vazba na tabulku kategorie_dokum
date_vloz_dokum
datetime
0000-00-00 00:00:00
Datum vložení dokumentu
Tabulka 8: Tabulka dokumenty
Název tabulky: dokumenty Popis tabulky: Tabulka slouží k uložení informací o vložených dokumentech do systému. Primární klíč: id_dokum Cizí klíče:
id_kat_dokum odkazuje na tabulku kategorie_dokum
Atribut
Typ
Velikost
Popis
id_kat_dokum
int
3
Identifikace kategorie dokumentu
kat_dokum
varchar
255
Název kategorie dokumentu
Tabulka 9: Tabulka kategorie_dokum
Název tabulky: kategorie_dokum Popis tabulky: Pomocná tabulka slouží k uložení informací o možných skupinách dokumentů. Primární klíč: id_kat_dokum Cizí klíče:
-
Atribut
Typ
Velikost
Popis
id_uzivatele
int
8
Identifikace uživatele
login
varchar
20
Login
heslo
varchar
100
Heslo
pristup
enum
ano/ne
Povolení přístupu do systému
jmeno
varchar
20
Jméno uživatele
prijmeni
varchar
50
Přijmení uživatele
Tabulka 10: Tabulka uzivatele
Název tabulky: uzivatele Popis tabulky: Tabulka slouží k uložení informací o uživatelských účtech pro přístup do systému. Primární klíč: id_uzivatele Cizí klíče:
-
Strana 56
Atribut
Typ
Velikost
Popis
id_uzivatele
int
8
Propojení s tabulkou uzivatele
administrace
tinyint
1
Číslo oprávnění sekce administrace
adresar
tinyint
1
Číslo oprávnění sekce adresar
poplatky
tinyint
1
Číslo oprávnění sekce poplatky
dokumenty
tinyint
1
Číslo oprávnění sekce dokumenty
Tabulka 11: Tabulka opravneni
Název tabulky: opravneni Popis tabulky: Tabulka slouží k uložení informací o právech jednotlivých uživatelů k přístupu do jednotlivým sekcí systému. Primární klíč: id_uzivatele Cizí klíče:
administrace, adresar, popis_opravneni
poplatky,
dokumenty
Atribut
Typ
Velikost
id_opravneni
tinyint
1
Identifikace oprávnění
kod_opravneni
varchar
20
Kód oprávnění
text_opravneni
varchar
255
Popis oprávnění
odkazují
na
tabulku
Popis
Tabulka 12: Tabulka popis_opravneni
Název tabulky: popis_opravneni Popis tabulky: Pomocná tabulka slouží k uložení informací o možných druzích oprávnění. Primární klíč: id_opravneni Cizí klíče:
-
Atribut
Typ
Velikost
Popis
id_log
int
10
Identifikace záznamu
id_uzivatele
int
8
Vazba na tabulku uzivatele
login
varchar
20
Login uživatele záznamu
time_log
datetime
0000-00-00 00:00:00
Čas záznamu
akce_log
varchar
255
Činnost
Tabulka 13: Tabulka log_file
Název tabulky: kategorie_dokum Popis tabulky: Tabulka slouží k uložení informací o týkajících se práce se systémem. Primární klíč: id_log Cizí klíče:
id_uzivatele odkazuje na tabulku uzivatele
Strana 57 6.4
Uživatelské rozhraní Velmi důležitým bodem řešení každého projektu je přehledné uživatelské rozhraní.
Snahou bylo vytvořit velmi intuitivní prostředí, ve kterém uživatel stále bude vědět v které části informačního systému je a jaké možnosti se mu nabízí. Veškerý design hlavních prvků je tvořen pomocí stylů. Zobrazovací plocha prohlížeče je rozdělena do pěti základních částí, z nichž dvě zabezpečují ovládací funkce, ostatní slouží primárně k zobrazení požadovaných dat, nebo mají informativní charakter. charakter. Následující obrázek pořízený přímo ze systému ukazuje jednotlivé funkční části obrazovky.
Obrázek 32: Základní rozdělení obrazovky
Na obrázku jsou velkými čísly označeny jednotlivé funkční části obrazovky, které plní následující úlohy: •
Část označená číslem 1 slouží jako primární ovládací menu k výběru kategorie se kterou uživatel bude pracovat.
•
Části označené číslem 2 slouží k informativním účelům a ukazuje momentálně prováděnou akci uživatele.
•
Třetí část obrazovky slouží jako sekundární ovládací menu umožňující výběr podkategorie činnosti nebo akce.
•
Čtvrtá část obrazovky je využívána jako hlavní univerzální zobrazovací plocha pro výstupy jednotlivých skriptů, které něco zobrazují.
•
Pátá část je stavovým řádkem pro zobrazování vedlejších informací uživateli (například datumu apod.).
Záměrem práce nebylo implementovat všechny možné části navržené zadavatelem, ale podrobně zanalyzovat potřeby a na těchto podkladech připravit systém a databázi tak, aby bylo možné další funkční moduly následně realizovat.
Strana 58 6.5
Realizace aplikace
Implementaci jsem na základě principů modulárního způsobu programování rozdělil do několika skriptů, z nichž každý programově řeší část požadavků kladených na systém. Programové provedení se tímto krokem stává přehlednějším a navíc poskytuje možnost reprezentovat každý případ užití samostatným skriptem. 6.5.1
Generování stránek
Hlavním skriptem celé aplikace je soubor index.php, který vytváří nový objekt třídy htmpage do kterého jsou dalšími funkcemi nality všechny části stránky. Sestavení a zobrazení stránek zajišťuje svými funkcemi a atributy objekt htmpage. Prototyp tohoto objektu je v souboru page.php, obsahuje funkce pro nastavení atributu, a zobrazení. Zde je příklad funkce pro zobrazení - Display( ): function Display() { if($this->presmer<>'') { // Don't use cache (required for Opera) header('Expires: 0'); // rfc2616 - Section 14.21 header('Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0'); // HTTP/1.1 header('Pragma: no-cache'); // HTTP/1.0'; } echo "\n\n\n"; $this -> DisplayTitle(); $this -> DisplayKeywords(); $this -> DisplayStyles(); $this -> DisplayCodePage(); $this -> DisplayErrorPage(); echo "\n\n"; $this -> DisplayHeader(); $this -> DisplayTopMenu(); $this -> DisplayMenu(); $this -> DisplayPage(); $this -> DisplayClear(); $this -> DisplayFooter(); echo "\n\n"; }
Zobrazení obsahu hlavní informační části zajišťuje funkce DisplayPage() zobrazující atribut objektu $page. Tento atribut je nastavován funkcí SetPage() využívající funkce RetPageName() vracející jméno vkládané stránky. Ostatní funkce zobrazují další části HTML stránky obdobným způsobem. 6.5.2
Přístupová práva
Přístupová práva jsou realizována komplexně pro celý systém. Každý uživatelský účet má v první řadě určeno je-li možné se tímto účtem do systému přihlásit. Zde jsou dvě možnosti Ano/Ne, toto přístupové právo je zde implementována z důvodu možnosti dočasně zablokovat nevyužívané účty (dlouhodobé stáže zaměstnanců v zahraničí) nebo možnost vypnout testovací účty. Systém může také účet dočasně zablokovat v případě, že je s ním nepatřičně nakládáno (opakované nesprávné přihlášení – pokus prolomení hesla hrubou silou atd.). Dále jsou pro každý účet definována práva pro práci s každým modulem systému. Pomocí zadaných oprávnění je možné určit jakým způsobem může daný uživatelem s kterým modulem pracovat. Zatím jsou v tomto systému zavedeny tři typy oprávnění: •
Uživatel nemá právo s tímto modulem pracovat.
•
Uživatel má právo do tohoto modulu nahlížet.
•
Uživatel má právo v tomto modulu aktualizovat data.
Díky své koncepci tento systém umožňuje jednoduše implementovat další druhy oprávnění.
Strana 59 Jemnější rozdělení oprávnění by mohlo vypadat například takto: •
Uživatel nemá právo s tímto modulem pracovat.
•
Uživatel má právo nahlížet jen do veřejných položek modulu.
•
Uživatel má právo nahlížet do všech položek modulu.
•
Uživatel má právo v tomto modulu vkládat i aktualizovat data.
•
Uživatel má právo v modulu data vkládat, aktualizovat i mazat.
Pro účely systému je jednodušší seznam oprávnění v současné době plně dostačující. 6.5.3
Přihlášení
První stránkou při otevření aplikace která bude načtena je soubor login.php. Na ní se může uživatel přihlásit do prostředí informačního systému.
Obrázek 33: Přihlašovací obrazovka
Účelem je autorizovat přihlašujícího se uživatele a vytvořit session a její proměnné. Údaje vložené uživatelem jsou porovnány se záznamy v databázi pomocí skriptu prihlaseni.php. Pouze korektně autorizovaný uživatel může být přihlášen do systému. Nepřihlášený uživatel nemůže jakkoliv se systémem pracovat. Autorizace vytvořené session je prováděna opakovaně na každé stránce ke které uživatel přistupuje. Toto je automaticky realizováno funkcí overeni_seance(), která kontroluje existující session a její proměnné jestli odpovídají uživateli a kontroluje se i time-out dané session. Dále je ověřováno oprávnění jestli daný uživatel má oprávnění do dané sekce vstupovat a to funkcí overeni_opravneni(). V případě úspěchu všech ověřovacích funkcí se daná stránka zobrazí, pokud ovšem některá z ověřovacích funkcí neuspěje je uživateli sdělen důvod a je přesměrován zpět na přihlašovací stránku, kde se musí znovu přihlásit. V případě opakovaného špatného zadání přihlašovacích údajů je účet dočasně zablokován, odblokován může být jen administrátorem.
Strana 60 6.5.4
Modul Adresář
Tento modul využívá ulozkontakt.php, smazkontakt.php.
stránek
adresar.php,
zobrazkontakt.php,
novykontakt.php,
Obrázek 34: Modul Adresář soubor adresar.php
Soubor adresar.php umožňuje prohlížet seznam všech kontaktů v databázi. Údaje je možné řadit podle různých sloupců, lze vybírat různé skupiny do kterých jsou jednotlivé kontakty zařazeny, lze ovlivnit i zobrazení tabulky (např. po kolika se bude listovat). Je implementováno i vyhledávání kontaktů dle zadaného údaje. Pokud má uživatel dostatečná oprávnění jsou aktivní i ikony pro úpravu údajů nacházející se v levé části řádku tabulky. Pro vkládání je využit soubor novykontakt.php, který zobrazí volný vstupní formulář. Po zadání údajů je údaj pomocí souboru ulozkontakt.php zkontrolován a uložen. V případě úpravy existujícího kontaktu je využit pro zobrazení formuláře, tentokrát již naplněného údaji soubor upravkontakt.php. Při mazání existujícího kontaktu je využit soubor smazkontakt.php. Na něm je uživatel upozorněn, že budou smazány i všechny související údaje tedy i údaje o členských poplatcích a je požadováno potvrzení operace. Pokud je operace potvrzena, tak je kontakt z databáze smazán. Jsou zrušeny i všechny navázané údaje. 6.5.5
Modul Členské příspěvky
Tento modul využívá soubory poplatky.php, smaz_poplat.php, uprav_poplat.php a neplatici.php.
vloz_poplat.php,
uloz_poplat.php,
Soubor poplatky.php slouží pro prohlížení zaplacených příspěvků. Platby je možné řadit podle roků, za které byly zaplaceny. Pokud má uživatel dostatečná oprávnění jsou aktivní také ikony pro administraci příspěvků v levé části řádku tabulky příslušného údaje.
Strana 61 Soubor vloz_poplat.php slouží pro vložení nového příspěvku. V rámci tohoto modulu je možné vyhledat i neplatiče aktuálního roku k čemuž slouží soubor neplatici.php.
Obrázek 35: Modul Poplatky soubor poplatky.php
6.5.6
Modul Archiv Dokumentů
Tento modul využívá stránek dokumenty.php, file.php, novy_dokum.php, uloz_dokum.php, smaz_dokum.php, uprav_dokum.php.
Obrázek 36: Modul Archiv Dokumentů - základní pohled
Strana 62 Soubor dokumenty.php slouží k zobrazení dokumentů vložených do systému. Je možné jejich třídění podle kategorií ve kterých jsou zařazeny. Důležitou funkcí je možností stažení určitého vybraného dokumentu do počítače uživatele. Vložené dokumenty nejsou přístupné přímo, tedy není možné je stáhnout jinak než pomocí skriptů informačního systému uložených v souboru file.php. Tohoto stavu je docíleno vhodným nastavením webového serveru a přístupových práv adresářů. Z této stránky je možné, pokud to uživatelova práva umožňují, se dostat k administraci vložených dokumentů. V této sekci je využívána stránka admin_dokum.php, kde je možné do systému nové dokumenty vkládat, nebo je naopak ze systému mazat, popřípadě provádět jejich aktualizaci. K těmto dílčím úkolům slouží soubory smaz_dokum.php, novy_dokum.php, uprav_dokum.php. 6.5.7
Modul Administrace Systému
Tento modul umožňuje administraci systému a využívá stránek admin.php, novyuziv.php, upravuziv.php, vlozuziv.php, smazuziv.php, upravopravuziv.php. Do tohoto modulu mají přístup pouze administrátoři. Stránka admin.php slouží k zobrazení existujících uživatelských účtů a jejich základních údajů, zároveň je jasně zobrazeno, zda-li je účet aktivní nebo byl zablokován. V levé části řádku zobrazujícího údaje o uživatelském účtu jsou čtyři ikony zobrazující možnosti práce s daným záznamem. U záznamu je možné zobrazit nebo změnit detaily účtu, nastavit oprávnění pro moduly daného účtu či účet zablokovat a nebo celý účet smazat.
Obrázek 37: Modul Administrace systému - základní přehled
Soubor novyuziv.php slouží k vytvoření přístupového účtu uživatele. Administrátor zde zadává login heslo, potvrzení hesla, skutečné jméno a příjmení uživatele a jestli je účet aktivní. Login je ověřen v databázi a systém nepovolí duplicitní názvy účtů. Heslo i potvrzení hesla musejí být shodné. Heslo je zašifrováno pomocí algoritmu MD5 a jeho obraz je uložen v databázi. Osmimístné identifikační číslo je automaticky generováno funkcí a je ověřeno v databázi, že již neexistuje. Při vytvoření účtu jsou všechna oprávnění toho účtu nastavena tak, že uživatel nemá přístup do žádného z modulů a je tedy potřeba tato oprávnění nastavit.
Strana 63
Obrázek 38: Modul Administrace systému – soubor upravopravuziv.php
Pro nastavení oprávnění slouží soubor upravopravuziv.php. Zde má administrátor možnost přehledně nastavit oprávnění zvlášť pro každý modul a zablokovat nebo povolit přístup uživatele do systému. Je možné také měnit údaje účtu. K tomuto slouží soubor upravuziv.php, ve kterém je možné změnit heslo nebo údaje účtu jako například jméno. U účtu nelze měnit login nebo ID účtu. Poslední možností, která je zajišťována souborem smazuziv.php je zrušení existujícího uživatelského účtu. Mazání je dvoustupňové, kdy je administrátor vyzván k potvrzení této operace a následně se ověřují dvě možnosti, které mohou toto mazání odmítnout. První možnost je, když je mazán účet administrátora zadávajícího tento příkaz a v druhém případě, když je mazán účet administrátora a v systému již jiný účet s tímto oprávněním neexistuje. 6.5.8
Další pomocné soubory Tyto soubory jsou nezbytné pro korektní chod celé aplikace a jsou to:
Veškerá globální nastavení pro celou aplikaci (kódové stránky, time-outy, databázové servery… ) jsou v souboru global.php. Soubor forms.php obsahuje funkce pro generování veškerých formulářů. Soubor files.php obsahuje funkce pro práci se soubory. Soubor connect.php obsahuje veškeré funkce pro práci s databází – nastavení spojení, položení dotazu, ověření oprávnění atd. Soubor rezek_fce.php obsahuje veškeré funkce pro zpracování dat získaných z databáze. Soubor input.php obsahuje veškeré funkce pro ošetření vstupu a výstupu z-do databáze. Soubor chyba.php zabezpečuje kultivovaný výstup při snaze zobrazit nedostupnou stránku.
Strana 64
Strana 65
7
ZÁVĚR
Cílem této diplomové práce bylo realizovat informační systém neziskové organizace. Pro tvorbu tohoto systému bylo důležité po zvolení programovacích jazyků také jejich dobré pochopení. Analýza systému byla provedena také pomocí použití jazyka UML. Pro optimalizaci databázových struktur bylo požito metod normalizace. Návrh struktury databáze na začátku projektu byl dobrý, i když během realizace se ukázalo, že je nutné počítat i se změnami. Bezpečnost a stabilita systému byla testována. Ukázalo se, že systém má ještě stále nedostatky. Některé chyby systému byly skryté a až v momentě kdy byla aplikace testována uživateli se tyto nedostatky projevily, některé se mi více či méně podařilo odstranit. Doufám, že tento informační systém pomůže organizaci při zlepšení komunikace a bude užitečným nástrojem pří sdílení informací a dokumentů.
Strana 66
Strana 67
8
SEZNAM POUŽITÉ LITERATURY [1] GILFILLAN, Ian; Myslíme v MySQL 4 : 1. vyd. Praha : GRADA 2003. ISBN 80-247-0661-X. [2] KRÁL, Jan; Informační systémy: 1. vyd. : SCIENCE 1998. ISBN 80-86083-00-4. [3] STANÍČEK, Petr; CSS Kaskádové styly – Kompletní průvodce : 2. vyd. Brno : Computer Press 2003. ISBN 80-7226-872-4. [4] MySQL [online]. Dokument dostupný na URL http://www.mysql.com/ (duben 2007). [5] PostgreSQL [online]. Dokument dostupný na URL http://www.postgresql.org/ (leden 2007). [6] KANISOVÁ, Hana; Müller, Miroslav; UML srozumitelně: 2. vyd. Brno : Computer Press 2006. ISBN 80-251-1083-4. [7] OMG, OMG Unfied Modeling Language Version 2.0 Specification. Dokument dostupný na URL http://www.omg.org/ docs/formal/07-02-03.pdf (duben 2007). [8] CASTAGNETTO, Jesus; Rawat, Haris; Schumann, Sascha; Scollo, Chris; Veliath, Deepak; Programujeme PHP profesionálně: 2. vyd. Brno : Computer Press 2002. ISBN 80-7226-310-2. [9] PHP Hypertext Preprocesor [online]. Dokument dostupný na URL http://www.php.net/ (únor 2007). [10] WELLING, Luke; Thomson, Laura; PHP a MySQL rozvoj webových aplikací : 2. vyd. Praha : Softpress 2004. ISBN 80-86497-60-7. [11] W3C, W3C Document Object Model. [online] Dokument dostupný na URL http://www.w3c.org/DOM/ (únor 2007).
