1 Technická univerzita v Liberci Fakulta Mechatroniky SEMESTRÁLNÍ PROJEKT WEBOVÝ ELEKTRONICKÝ SYSTÉM DOTAZŮ WEB-BASED QUESTIONS SYSTEM Autor: Vedoucí ...
Technická univerzita v Liberci Fakulta Mechatroniky
SEMESTRÁLNÍ PROJEKT
WEBOVÝ ELEKTRONICKÝ SYSTÉM DOTAZŮ WEB-BASED QUESTIONS SYSTEM
Autor:
Bc. Martin Žaloudek
Vedoucí práce:
doc. RNDr. Pavel Satrapa, Ph.D
LIBEREC, 2008
Prohlášení Prohlašuji, že jsem tento projekt vypracoval zcela sám a celý projekt je mé vlastní autorské dílo. V Liberci, dne 19. května 2008 Martin Žaloudek
Abstrakt Tento projekt řeší návrh a realizaci webové aplikace sloužící občanům k podávání dotazů osobám a odborům městského úřadu. Konečná práce je rozdělena do dvou částí. Ta první je zaměřena na vysvětlení základních pojmů a principů návrhu informačních systémů, aplikací a databází. Teoretická část se současně zabývá tvorbou HTML kódu a jeho validitou. Druhá část pak popisuje návrh a praktickou implementaci celé aplikace. Klíčová slova: Informační systém, databáze, HTML, PHP, SQL
Obsah 1 Úvod.............................................................................................................................................5 2 Teorie...........................................................................................................................................6 2.1 Analýza problému a situace..................................................................................................6 2.2 Databáze................................................................................................................................6 2.3 XHTML kód........................................................................................................................10 3 Návrh aplikace..........................................................................................................................15 3.1 Analýza a počáteční informace...........................................................................................15 3.2 Model celé aplikace.............................................................................................................16 4 Implementace............................................................................................................................20 4.1 Databáze..............................................................................................................................20 4.2 Autentifikace.......................................................................................................................23 4.3 Paralelní přístup více uživateli............................................................................................24 4.4 Předávání dotazů.................................................................................................................25 5 Závěr..........................................................................................................................................27 6 Literatura..................................................................................................................................28 7 Slovník pojmů a zkratek..........................................................................................................29
-4-
Úvod
1 Úvod Tento projekt řeší návrh a realizaci webové aplikace sloužící k podávání dotazů osobám a odborům městského úřadu. Aplikace bude rozdělena na dvě části. První část bude umístěna veřejně na oficiálních webových stránkách města. Půjde o několik skriptů, které umožní občanům města rychle a jednoduše položit jakoukoliv otázku vybraným konkrétním pracovníkům úřadu nebo odborům městského úřadu. Druhá část bude sloužit pracovníkům úřadu, tedy osobám, které budou na podané dotazy odpovídat. Bude se jednat o zcela samostatný administrátorský nástroj. Do tohoto nástroje se budou jednotliví uživatelé (tj. odpovídající) přihlašovat a dotazy řešit. Vybraní uživatelé budou moci navíc spravovat uživatelské účty celého systému včetně jejich oprávnění. V rámci zkušeností z praxe budou moci jednotliví zaměstnanci městského úřadu nejen dotazy rovnou vyřešit, ale budou moci jen připojit vlastní komentář či poznámku (jak veřejnou, tak interní) a předat dotaz k řešení dále, někomu jiného.
-5-
Teorie
2 Teorie 2.1 Analýza problému a situace Jde o první a často nejdůležitější část vývoje celého informačního sytému. Bez důkladné analýzy a následného návrhu dochází často k situacím, kdy se narazí na závažný problém či chybu, a to až v části implementace projektu. Tyto stavy je třeba vyloučit nebo alespoň co nejvíce omezit. Velice totiž zvyšují časovou náročnost a tedy i výsledné náklady. Je podstatné věnovat dostatek času jednání se zadavateli. Pokud si předem nestanovíte přesné cíle a funkce celé aplikace, má zadavatel tendenci postupně zvyšovat své nároky a požadovat různá rozšíření a funkce, o kterých se dříve nejednalo. Je třeba věnovat pozornost zejména: ●
stanovení celkového cíle a náplně funkce IS
●
detailní popis jednotlivých funkcí
●
zjištění entit, které budou do systému přistupovat ○
systém na kterém výsledná aplikace poběží (server, typ OS, verze PHP,... )
●
konkrétní konfiguraci webového serveru (nastavení Apache a chování PHP)
●
definování termínu realizace a ceny
2.2 Databáze 2.2.1 Návrh databáze Většina současných webů ukládá svá data do databází. Jako sekundární úložný prostor lze samozřejmě použít například binárních či textových souborů, XML, apod. Primárně se však stále většinou používají databáze SQL. Na databázích většinou stojí celá výsledná webová aplikace. Je tedy velmi důležité správně analyzovat ukládaná data a podle nich dobře navrhnout strukturu databází a tabulek. Pokud bude -6-
Databáze databáze špatně navržena, může dojít i k situaci, že některé požadované informace nebudeme schopni získat přímo SQL dotazy, ale budeme si muset vypomoci dalším zpracováním SQL výsledků v jazyce PHP. Toto zpracování však bývá v porovnání s SQL dotazy mnohem časově náročnější, což se může při vyšším zatížení webového serveru velmi nepříjemně projevit na rychlosti odezev serveru klientům. Chcete-li dosáhnout optimálního návrhu DB, je vhodné držet se určitého postupu. Je vhodné rozdělit jej na tyto základní části:
●
shromažďování dat a požadavků od uživatelů a zadavatelů systému. Jedná se často o práci s lidmi, takže je vhodné se ozbrojit úsměvem a nekonečnou trpělivostí. Dobré je myslet na to, že většina lidí vám řekne jen to, na co se jich zeptáte, proto je nutné zeptat se na vše. Z vlastní zkušenosti mohu říct, že není chvíle, kdy by uživatel riskoval svůj život více, než když řekne tvůrci aplikace podstatnou informaci až ve chvíli, kdy je aplikace napsána a testována. Je vhodné provádět i určitou selekci informací. Většina lidí má pocit, že jim dáte program, který vyřeší všechny jejich problémy. Takové programy ale mají jen politické strany.
●
dalším krokem je definice nezávislých entit
●
definice vztahů a typů těchto vztahů
●
definice závislých entit a vyhledání kandidátů na klíčové atributy
Výše uvedené se v cyklu opakuje tak dlouho, až se podaří vyřešit všechny vztahy. Po této fázi návrhu DB by již měla existovat rámcová představa o tom, jak bude vypadat výsledná DB. [5, sekce Vlastní tvorba datového modelu]
2.2.2 Reprezentace a kroky návrhu Návrh samotný začíná většinou slovním popisem problému a následně popisem jednotlivých rolí a vlastností entit, které budou do systému vstupovat. Takto vytvořený text s popisem může dobře sloužit jako podklad pro další práci. Je však velmi nepřesný a hlavně nejednoznačný, je proto nutné ho přepracovat do přesné podoby výsledné databáze, která bude odrážet právě tento počáteční popis. Dalším krokem návrhu je vytvoření diagramu databázového modelu. Mezi programátory -7-
Databáze se nejčastěji používá ERD diagram, protože jeho reprezentace je prakticky totožná s výslednými tabulkami, atributy a relacemi následně vzniklé databáze se kterými se při své práci denně stýkají. Programátorům je tento způsob reprezentace databáze velmi blízky a dokáží o něm většinou intuitivně přemýšlet a rychle rozpoznávat různé možné nástrahy vnikajícího modelu. Posledním krokem návrhu bývá vytvoření (či automatické vygenerování) SQL dotazů, které vytvoří jednotlivé tabulky, nastaví integritní omezení, vazby cizích klíčů, případně další potřebné záležitosti. Databázový model lze tedy reprezentovat těmito hlavními způsoby: ●
textový popis
●
Diagramy
●
○
ER
○
UML
SQL dotazy
2.2.3 Ochrana databáze před útoky Tato část bývá v mnohých webových aplikacích velmi podceňována a opomíjena. V souvislosti s tím, že jazyk PHP nemá striktní určení datových typů proměnných, lze velice snadno serveru (např pomocí GET, POST, atd.) „podstrčit“ zcela jiné informace než očekává. Pokud není aplikace proti takovýmto podvrženým datům dostatečně odolná, lze takto celkem jednoduše donutit databázový server k vykonání zcela jiných úkonům, než autor systému původně zamýšlel. Zvláště v jazyce PHP, který striktně nerozlišuje datové typy je třeba kontrolovat všechny vstupy od uživatele a následně vypustit nepřístupné znaky a ošetřit znaky problémové (jako jsou například apostrofy, uvozovky a případně závorky, které reprezentují počátky a konce tagů v XML). Některé takového problémy lze místo složitého testování vyřešit celkem jednoduše. V případě očekávání celých čísel například mnohdy stačí všechny vstupní proměnné explicitně přetypovávat. I když pak útočník vloží řetězec, bude přetypován na číslo a nedojde tedy k možnému vykonání žádných SQL dotazů navíc. Slabina systému je tedy vyřešena (alespoň částečně). $q = 'SELECT * FROM tabulka where ID = ' . (int)$_GET['id'];
-8-
Databáze
2.2.4 Kompatibilita mezi jednotlivými databázovými servery I když standard SQL je dán, jeho implementace se v jednotlivých databázových serverech drobně liší. Na toto je třeba při psaní kódu brát ohled a snažit se SQL dotazy psát co „nejkompatibilněji“, tedy tak, aby se příkaz vykonal na různých serverech pokud možno bezchybně. Příkladem nevhodné implementace budiž například parametr LIMIT s oblibou používaný v MySQL, který lze ve většině běžných případech jednoduše nahradit konstrukcí TOP(číslo). Další vhodnou otázkou k zamyšlení před vlastním psaním aplikace je, zda jde o produkt, který bude běžet na zakázku pouze jednom konkrétním serveru, nebo zda půjde o nástroj obecnější, který by měl být snadno modifikovatelný pro různé SQL servery. V tom druhém případě bývá vhodné například nepsat příkazy typu mysql_* přímo do zdrojového kódu, ale vytvořit si vlastní funkce sql_*, které budou následně volat sql funkce příslušné konkrétní implementace SQL serveru (MySQL, MSSQL, atd.). Pak lze totiž velmi příjemně přepsat pouze několik málo těchto vlastních funkcí a celá aplikace je rázem skoro připravena pro nasazení na server s zcela odlišnou databází. Příkladem budiž implementace pro MySQL: function sql_query($q) { return mysql_query($q); }
Jednoduchou změnou pak přesměrujeme všechny dotazy například na Microsoft MSSQL databázový server. function sql_query($q) { return mssql_query($q); }
Tímto způsobem si ušetříme jinak nepříjemnou nutnost měnit příkazy pro SQL dotazy v každém skriptu zcela samostatně. Stejným způsobem je vhodné napsat si společnou funkci pro připojování k SQL serveru. Při případném přesunu nebo jiných změnách pak stačí změnit adresu serveru, jméno či heslo pouze na jenom místě a vše opět funguje, jak má.
-9-
XHTML kód
2.3 XHTML kód Výsledný kód, který se odesílá prohlížeči, tedy hlavně HTML, respektive dnes spíše XHTML (spolu s kaskádovými styly CSS) lze psát různě. Slušně nebo méně slušně. Jaký bude výsledek závisí většinou na snaze a hlavně zkušenostech programátora, případně HTML kodéra. Často také míra snažení závisí na účelu aplikace. Výsledkem snažení by však měl být pokud možno vždy validní kód. Tato validita jednak znamená, že výsledný XHTML dokument musí být parsovatelný XML soubor. Často se stává, že v dokumentu bývají špatně zapsané entitity a neošetřené speciální znaky. V PHP je tedy třeba vždy přemýšlet nad vypisovaným obsahem a případně před jeho samotným vypsáním ještě upravit například pomocí funkce htmlspecialchars(). Druhým krokem validace by mělo být ověření vůči standardu XHTML (standard definovaný skupinou W3C). V současné době se nejvíce používá verze XHTML 1.0 Transitional a XHTML 1.1. Novější veze 1.1 je však velmi striktní a v některých případech až příliš omezující. Například při použití WYSIWYG editoru se musíme většinou uchýlit ke starší verzi 1.0, protože zmíněné editory většinou omezující XHTML 1.1 příliš nedodrží. Validita dokumentu je velmi důležitá pro správné zobrazení v co největším množství prohlížečů. Nedodržováním standardů se vystavujeme velkému riziku, že aplikace bude funční jen na konkrétním prohlížeči, ve kterém stránky zkoušíme. Ještě důležitější než validita (X)HTML je často použití neproprietárních metod a funkčí v Javasriptu. Ten totiž různé prohlížeče podporují velmi různorodě. Standardy však né vždy splní svůj úkol. Prvním příkladem je bohužel právě Javascript, ve kterém je občas nutné vytvářet složité konstrukce podmínek, protože stejné vlastnosti a metody jsou v každém prohlížeči implementovány v různých objektech a pod různými názvy. Standardy je nutné také úmyslně porušit například v případě, kdy do webu potřebujeme vložit multimadiální obsah, konkrétně video. V tomto případě nám pro maximální kompatibilitu nezbude než se uchýlit k částečně proprietárnímu (nicméně funkčnímu) řešení.
- 10 -
XHTML kód
Jak je vidět z ukázky vložení AVI souboru, výsledký zdrojový kód není jednoduchý a už vůbec ne validní. Element embed je totiž proprietární a není schválen podle žádného standardu. V některých prohlížečích je to však jediný způsob, jak spolehlivě zobrazit přehrávač s videem.
2.3.1 Sémantika Snaha poslední doby je produkovat do internetu kód, který s sebou nese i jakousi částečnou sémantiku. Jde o to poskytnout informace tak, aby je pochopil nejen člověk sedící u počítače, ale aby i počítač sám byl schopen rozlišit jednotlivé části dokumentu a podle toho je případně dále zpracoval Tato snaha má řadu různých dopadů. Díky správně napsanému kódu je počítač schopen rozeznat jednotlivé nadpisy, odstavce, adresy, citace a další sekce. Takto získaný obsah je pak možno jednodušeji a efektivněji zobrazit například na speciálních zařízeních pro postižené, mobilních zařízení s malým displejem nebo v zařízeních TTS1. Naproti tomu přináší zavedení sémantiky i různá omezení. Samotný jazyk HTML a XHTML z důvodu sémantiky ve svých posledních verzích zrušil množství elementů (nebo nedoporučil jejich používání), které sloužili například pro pouhé grafické formátování dokumentu a neměli žádný z hlediska sémantiky žádný smysl. Bez použití sémantiky lze mnoho grafických návrhů webů navrhnout mnohem pohodlněji a jednodušeji. Teď mám na mysli hlavně dříve hojně používaný layout pomocí tabulek, který je již dnes zapovězen a jeho používání není považováno za profesionální. 1 Jde o různé nástroje syntetizující řeč z napsaného textu.
- 11 -
XHTML kód Hodlá-li autor psát zdrojové kódy webu správně sémanticky, bude muset být pravděpodobně dostatečně zdatný v používání kaskádových stylů, protože právě do nich byl z HTML přesunut úkol formátovat grafický výstup webových dokumentů. Problematika CSS je mimo rozsah této práce, podrobněji se ji však věnuje kniha Andyho Budda [6].
2.3.2 Přístupnost Přístupnost plynule navazuje na předchozí téma sémantiky. Společně s ní popisují pravidla přístupnosti webu několik důležitých bodů, které je velmi vhodné dodržovat. V principu jde o požadavek, aby byly stránky „použitelné“ i v případě, že klientské zařízení nepodporuje některou z technologií, které jsou webem používány. Totéž platí, pokud zařízení sice danou technologii podporuje, ale uživatel jí má například z bezpečnostních důvodů zakázanou. Jasným příkladem budiž Javascript a vyskakovací okénka. Na webu se s často objevuji konstrukce typu: zobrazit obrázekzobrazit obrázek
Druhá konstrukce je o malinko lepší, než ta první. Nicméně obě vykazují stejný problém. Pokud má totiž prohlížeč Javascript nebo vyskakování oken zakázáno, neobjeví se nic a uživatel přijde o informace, které se mu prostě nezobrazí. V tomto případě je řešení jednoduché: zobrazit obrázek
Na první pohled přibyl odkaz na obrázek v atributu href. Dále pak Javascript vracející informaci o tom, jestli bylo pop-up okno otevřeno nebo ne. Tato jednoduchá konstrukce vyřeší problém v případě vypnutého Javasriptu, protože pak se otevře klasický odkaz. A v případě, že otevření okna projde bez problémů, vrátí funkce window.open() true, celá událost onclick pak tedy false, čímž dojde k zablokování otevření obrázku klasickou cestou (parametrem href).
- 12 -
XHTML kód Tento příklad je triviální. Jasně však ukazuje nutnost „dvojitého programování“. Je třeba si uvědomit, že vždy je nutné vytvořit alternativu, co se stane v případě, kdy například technologie Javascriptu není dostupná. Tento problém se začíná velmi komplikovat u rozsáhlejších aplikací, které tyto technologie používají široce. Jde na například o weby založené na AJAXu2. Stejný přístup je nutný aplikovat i na kaskádové styly. Je důležité, aby při vypnutí CSS byl web čitelný a přehledný. Platí zásada, že CSS by mělo poskytovat pouze design, nikoliv obsah. Vypnutím stylů by měl návštěvník webu přijít maximálně o grafiku, hezké pozadí, formátování, apod. Ve stylech by tedy neměly být například uvedeny obrázky, které jakkoliv souvisejí s obsahem nebo jsou potřebné pro pochopení souvislostí na konkrétní stránce.
2.3.3 SEO SEO je zkratka, která poslední dobou hýbe světem internetu. Společnosti jsou ochotné zaplatit velmi vysoké částky za to, aby se více dostaly do povědomí uživatelů, tedy případných budoucích zákazníků. A programátoři a internetové agentury zabývající se SEO, tedy optimalizací pro vyhledávače jsou si této zkutečnosti velmi dobře vědomé. SEO zjednodušeně navazuje sémantiku webu. Díky snaze poskytnout obsah vyhledávacím robotům tak, aby ho co nejlépe pochopili lze dosáhnout lepších pozic ve vyhledávání určitých klíčových slov. V této „pseudovědě“ však nejde jen o to, jak obsah poskytnout, ale i (a to hlavně) o to, jaký obsah poskytnout. Samotná sémantika totiž mnohdy nestačí. Často se v praxi provádí úmyslná manipulace s obsahem, která má za cíl zlepšit pozice ve vyhledáváčích. Jde většinou o marketingový tah, který ma za účel přivést na svůj web více navštěvníků. Je to podobné, jako v reálném světě. Někdy není důležité, co říkáte, ale to, jak to říkáte. Vyjádřením téže informace různými způsoby lze totiž dosáhnout například u internetových vyhledávačů zcela rozdílných výsledků. Tyto se používají prakticky výhradně u komerčních webů. Seriózní portály tuto část SEO nevyužívají. Je velmi důležité, abychom si uvědomili, že zvýšení návštěvnosti ještě neznamená úspěch. Platí totiž, že návštěvník nerovná se zákazník. Né zcela čestnými praktikami SEO lze opravdu dosáhnout větší návštěvnosti optimalizovaných webových stránek. Velké množství takto získaných 2 „AJAX (Asynchronous JavaScript and XML) je obecné označení pro technologie vývoje interaktivních webových aplikací, které mění obsah svých stránek bez nutnosti jejich znovunačítání. Na rozdíl od klasických webových aplikací poskytují uživatelsky příjemnější prostředí, ale vyžadují použití moderních webových prohlížečů.“ [1, odstavec 1]
- 13 -
XHTML kód návštěvníků však otevře pouze úvodní stránku a pak okamžitě odchází. Takovouto aktivitu na webu pak samozřejmě nelze považovat za užitečnou. Více se této problematice věnuje ve svém článku [2] společnost Symbio. Problematika SEO je však mnohem hlubší a samotná by mnohonásobně přesáhla rozsah celého tohoto projektu, což dokazuje i kniha [3], která SEO rozebírá na celých 328 stránkách.
- 14 -
Návrh aplikace
3 Návrh aplikace 3.1 Analýza a počáteční informace Zadavatel neměl žádnou konkrétní počáteční představu o funkcích a vlastnostech celého informačního sytému pro komunikaci s občany. Po vlastní analýze situace a požadavcích jak ze strany městského úřadu, tak ze strany občanů byly definovány základní požadavky a vlastnosti: Občan bude moci zadat dotaz konkrétnímu odboru nebo konkrétní osobě (například starostovi). O aktuálním stavu řešení dotazu by měl být občan informován emailem. Jednotliví zaměstnanci úřadu budou dotazy řešit pomocí webové aplikace. Přihlášení a autentifikace bude řešena uživatelským jménem a heslem. Údaje o uživatelích (tedy zaměstnancích) budou uloženy v samostatné tabulce a budou zcela izolovány od centrálního autentizačního seznamu úřadu. Důvodem je změna celého informačního systému, který na úřadě právě probíhá. V případě zájmu ze strany zadavatele může být napojení na databázi tohoto nového informačního systému provedeno později. O nově příchozích dotazech budou kompetentní zaměstnanci notifikování emailem. Často se stává, že občan svůj dotaz směřuje na špatný odbor nebo je potřeba spolupráce více odborů. V důsledku toho musí být možné dotazy libovolně předávat mezi odbory. Správa uživatelů a odborů bude řešena přidělením oprávnění vybraným zaměstnancům, kteří pak budou moci přidávat, editovat a mazat všechny uživatele i odbory. Žádná další speciální oprávnění dále nejsou zatím požadována. Pokud občan povolí zveřejnění dotazu a zároveň odpovídající (tedy zaměstnanec městského úřadu) uzná za vhodné, že jde o dotaz vhodný pro zveřejnění, zobrazí se dotaz i s odpověďmi na portálu MÚ komukoliv k nahlédnutí.
- 15 -
Analýza a počáteční informace Průzkum na internetu ukázal, že neexistuje žádné řešení, které by se alespoň blížilo naším potřebám. Pro vytvoření zcela vlastní aplikace mluvilo i několik dalších aspektů. Hotový převzatý projekt má následující nevýhody:
●
ne zcela přesně odpovídá našim představám a požadavkům
●
obtížněji se edituje a přizpůsobuje
●
převzetí a pochopení cizího kódu je často velmi náročné
●
úprava do enginu a redakčního systému stávajícího webu nebývá bezproblémová
3.2 Model celé aplikace
Aplikace má několik hlavních funkcí: ●
●
práce s tazateli ○
přijímání dotazů
○
zasílat informace o stavu jejich dotazu
veřejnost ○
●
zobrazování zveřejněných dotazů
zaměstnanci MÚ ○
správa uživatelů
○
práce s dotazy ■
odpovídání
■
předávání
■
zveřejňování
Celý systém lze rozdělit
na dvě oddělené části. Jedna část je určena pro zadávání
a prohlížení dotazů občany a druhá pak k zadávání odpovědí, případně dalšímu zpracování otázek. - 16 -
Model celé aplikace Obě části aplikace jsou velmi rozdílné. Přesto však bude existovat společná knihovna, která implementuje některé obecně použitelné funkce. Pro administraci uživatelů byl zvolen mechanizmus, kdy někteří zvolení zaměstnanci (v praxi to budou vedoucí jednotlivých odborů) mohou kromě zodpovídání dotazů provádět i správu uživatelů. Jako alternativu bylo možné použít situaci, kdy administrátoři budou od zodpovídání dotazů zcela odděleni. V praxi však administrátoři budou pracovat i s dotazy. Pokud by tedy správa byla oddělena, museli by si tito zaměstnanci pamatovat například dvě různá přihlašovací jména nebo se přihlašovat do dvou různých sekcí. Proto bude vhodnější, když bude vše spojeno v jeden celek.
3.2.1 Část pro občany Na počátku je důležité říct, že tato část bude tvořena pouze souborem skriptů. Tyto skripty budou plně funkční, nicméně půjde pouze jakousi šablonou, která bude až následně implementována do existujícího webového portálu. V té souvislosti bude třeba do skriptů ještě různým způsobem zasahovat. Půjde zejména o přizpůsobení designu a enginu portálu městského úřadu. Hlavním úkolem bude vytvoření formuláře, který umožní občanům zadat dotaz a vybrat, komu bude adresován. Formulář bude doplněn drobným Javascriptem, který bude kontrolovat validitu zadaných údajů. Samozřejmostí je ještě následná kontrola vložených údajů v samotném PHP skriptu. Součástí poskytovaných informací bude i stránka se seznamem dotazů a odpovědí. Grafické ztvárnění bude řešeno až v poslední fázi ve spolupráci s webdesignerem celého portálu.
3.2.2 Administrační část pro zaměstnance Je největší část celého projektu. Účelem je poskytnout zaměstnancům městského úřadu prostředí pro vyřizování jednotlivých dotazů, které byly zadány pomocí formuláře na oficiálních webových stránkách města. Do systému budou přistupovat pouze zaměstnanci. Někteří z nich (vedoucí odborů) budou mít navíc přístup ke správě uživatelských účtů. Tento případ bude u jednotlivých uživatelů řešen pomocí příznaků. - 17 -
Model celé aplikace Celý informační systém lze sémanticky rozložit na dva moduly. První je samotný systém pracující s dotazy. Ten druhý pak řeší nutnou administraci celého systému uživatelů a odborů. Následující diagram detailněji rozvádí předchozí obecnější pohled na celý informační systém.
- 18 -
Model celé aplikace
Diagram postupného průchodu vloženého dotazu celým systémem. Začátek
Email tazateli o stavu dotazu
Email tazateli o vyřešení dotazu
odbor
Pro
Přisvojení dotazu konkrétní osobou
osoba
ano
Přidat odpověď ne
Vložení odpovědi
Předat dotaz
Změna stavu ponechat otevřený uzavřít dotaz
Změna řešitele dotazu
Uzavření dotazu
Konec
Email tazateli o vyřešení dotazu
- 19 -
Implementace
4 Implementace 4.1 Databáze 4.1.1 Databázový model
Pro implementaci byla použita databáze MySQL. Důvodem je hlavně výsledné umístění aplikace. Ta poběží na webovém serveru MÚ Klášterec n/O, kde již MySQL používají i pro ostatní webové nástroje a prezentace. Tento databázový server nám pro potřeby aplikace plně postačí, není tedy třeba požadovat instalaci jiného. Z bezpečnostních důvodů bude ale vhodné vytvořit do databáze nový účet, který bude mít přístup pouze do tabulek, které se týkají sytému dotazů.
- 20 -
Databáze Jako typ tabulek použijeme MyISAM, díky kterému sice přijdeme o možnost kontroly relací mezi tabulkami. Na druhou stranu však tento typ tabulek podporuje fulltextový index pro snadné a rychlé vyhledávání v datech.
4.1.2 Popis tabulek Tabulka „dotazy_osoby“ Obsahuje informace o všech uživatelích, který budou systém používat, tedy budou řešit dotazy. Záznamy kromě běžných hodnot, jako jsou přihlašovací jméno, heslo a email, obsahuje i další příznaky, které identifikují status daného uživatele. Sloupec opravneni může obsahovat příznak, který určuje, že daný uživatel může systém spravovat. Aplikace je připravena, aby bylo v případně rozšiřování možné kdykoliv přidat další potřebné příznaky, a tím nadefinovat další možné oprávnění. Sloupec verejny udavá, zda osobě mohou posílat dotazy přímo občané. Pokud ne, může dotaz přijít pouze až přeposláním od jiného zaměstnance úřadu. Hodnota sloupce aktivni udává, zda daná osoba aplikaci ještě využívá. Například při trvalém odchodu z úřadu nemůže být uživatel z databáze jednoduše smazán. Smazání je možné pouze v případě, že ještě daná osoba neodpověděla na žádný dotaz a není součástí žádného odboru (tj. v ostatních tabulkách na ní není žadný odkaz). V opačném případě je nutné osobu pouze zneplatnit (zakázat) – a to právě nastavením hodnoty sloupce aktivni na 0. Uživatele je takto možné samozřejmě zakázat i pouze dočasně. Jednotlivá hesla uživatelů systému nejsou samozřejmě uložena v plain textu, ale je v databázi zapsán pouze otisk SHA1.
Tabulka „dotazy_odbory“ Tento seznam obsahuje všechny odbory, které se do systému zapojí. Sloupce verejny a aktivni mají podobný význam jako u tabulky dotazy_osoby. Není-li odbor aktivní, již nemůže přijímat žádné nové dotazy. Osoby v tomto odboru však mohou již existující dotazy ještě dovyřešit.
- 21 -
Databáze
Tabulka „dotazy_osoby_odbory“ Jde o spojovací tabulku, která umožňuje propojit osoby s odbory v poměru M:N. Jeden zaměstnanec může být tedy součástí více odborů. To se sice v praxi nestává, je však dobré databázi navrhnout více volnou. Tato schopnost se také může hodit v případě, že je například potřeba, aby zaměstnanec kromě své vlastní práce dočasně zaskočil a zpracoval i práci jiného odboru. V tomto případě tak může zároveň pracovat se svým odborem i s tím, ve kterém zaskakuje. Tabulka „dotazy_zadani“Tabulka dotazy_zadani obsahuje jednotlivé dotazy. Důležité jsou sloupce pro_osoba_aktualni a pro_odbor_aktualni, které identifikují, kdo zrovna má za úkol dotaz zpracovat.
pro_osoba_aktualni pro_odbor_aktualni Popis NULL
NULL
Dotaz je již vyřešen a uzavřen
ID osoby
NULL
Zpracovat musí konkrétní osoba
NULL
ID odboru
Zpracovat dotaz může kdokoliv ze zvoleného odboru
ID osoby
ID odboru
Nedovolený stav
Naproti tomu sloupce pro_osoba a pro_odbor reference, komu byl daný dotaz poslán původně. Tato informace není pro zpracování dotazu potřeba, může se však hodit pro případné budoucí statistiky.
Tabulka „dotazy_odpovedi“ Každý záznam reprezentuje samostatnou odpověď ke každému dotazu. Vazba 1:N vůči tabulce dotazy_zadani umožňuje psát na každou otázku libovolný počet odpovědí. Otázku lze tak například vyřešit jen částečně, a pak nechat připsat další odpověď jiné osobě či odboru. Již zapsanou odpověď nepůjde opravit. Občan totiž je o každé zapsané odpovědi informován emailem. Docházelo by tak ke zmatkům a existovala by možnost s odpovědmi manipulovat. Pokud, pokud bude třeba odpověď poupravit nebo doplnit, musí být k dotazu zapsána odpověď další (původní bude ponechána beze změn). Sloupce id_osoba a id_odbor identifikují kdo danou odpověď napsal. Hodnota
- 22 -
Databáze id_osoba je vyplněna vždy a ukazuje na konkrétního zaměstnance (uživatele systému). Oproti
tomu hodnota id_odbor je vyplněna pouze v případě, že daný zaměstnanec je součástí nejakého odboru. Je-li součástí více odborů, bude muset vybrat, za který odpověď zadává.
4.1.3 Fulltextové vyhledávání Některé sloupce (dotaz, odpovědi, kontakty) jsou označeny indexem typu fulltext. Díky němu je pak možné jednoduše a efektivně provádět fulltextové vyhledávání v celé tabulce (či tabulkách). Následující příklad ukazuje fulltextové vyhledávání v otázkách i odpovědích. SELECT id, MAX(skore) FROM ( SELECT id, MATCH (dotaz, ip, kontakt_jmeno, kontakt_email, kontakt_dalsi) AGAINST ('vyhledávaná slova') AS skore FROM dotazy_zadani UNION ALL SELECT id_zadani as id, MATCH (odpoved, poznamka) AGAINST ('vyhledávaná slova') AS skore FROM dotazy_odpovedi ) as t1 WHERE skore > 0 GROUP BY id ORDER BY skore DESC LIMIT 100
4.2 Autentifikace Autentifikace uživatelů je řešena pomocí běžného webového formuláře, do kterého zaměstnanec městského úřadu zadá své přihlašovací jméno a heslo. Tyto identifikace jsou předány na server. V současné době není na webhostingovém serverech MÚ dostupné a nakonfigurované HTTPS. Použítí tohoto šifrovaného protokolu je však doporučeno, proto bude zahájeno jednání o jeho zřízení. Při každém otevření jakékoliv stránky z administračního prostředí se hned na počátku volá funkce loginAdmin(), která kontroluje, zda je uživatel správně přihlášen. Funkce se dívá do proměnné $_SESSION['logginedUser'], jestli existuje a je naplněna hodnotami. Pokud ano, je přihlášení považováno za úspěšné. V případě, že jsou zrovna předávány informace z přihlašovacího formuláře, jsou informace ze session vymazány, informace o přihlašujícím-se uživateli ověřeny - 23 -
Autentifikace v databázi a následně (v případě úspěšného ověření) informace uloženy zpět do session. Session proměnná $_SESSION['logginedUser'] obsahuje následující strukturu informací: [logginedUser] => Array ( [id] => 1 [user] => admin [pw] => 8cb2237d0679ca88db6464eac60da96345513964 [jmeno] => Administrator [email] => [email protected] [opravneni] => a [verejny] => 0 [aktivni] => 1 [odbory] => Array ( ) [opravneni2] => Array ( [administrace] => 1 ) )
4.3 Paralelní přístup více uživateli Vzhledem k tomu, že je očekáváno, že aplikaci bude ve stejné chvíli používat více uživatelů najednou, bylo nutné vyřešit problém, že někteří uživatelé by v jednou chvíli mohli pracovat nad společnými daty (otázku určenou pro celý odbor vidí více osob). Tuto možnou situaci bylo nutné zcela vyloučit. Řešením tohoto problému bylo zavedení postupu „přisvojení dotazu“. Princip je takový, že pokud není dotaz určen konkrétní osobě, ale celému odboru, nelze na něj přímo odpovědět. Kompetentní zaměstnanec nejdříve systém požádá o přesměrování dotazu na svou vlastní osobu. Po tomto přesměrování již nemá dotaz s původním odborem vůbec nic společného. Dotaz bude viděn a zpracováván pouze tou jednou konkrétní osobou, které požádala o „přisvojení dotazu“.
- 24 -
Paralelní přístup více uživateli
4.4 Předávání dotazů Jak již bylo řečeno dříve, předávání dotazů mezi odbory nebo jednotlivými osobami je velmi důležitá funkce systému. Z tohoto důvodu jsou v databázi v tabulce dotazy_zadani dva sloupce navíc. Jde o sloupce pro_osoba_aktualni a pro_odbor_aktualni, které obsahují aktuální oprávnění k zodpovězení dotazu. Při každé odpovědi je nutno navíc zvolit, co se bude s dotazem dít dále. Možnosti jsou následující: ●
dotaz zůstane otevřený – uživatel později přidá další odpověď
●
dotaz bude uzavřen – je již vyřešen
●
dotaz bude předán ke zpracování dále, někomu jinému
- 25 -
Předávání dotazů
Pro ilustraci přikládám závěrem ještě screenshot přehledu čekajících dotazů, který obsahuje nejdůležitější informace seřazené do tabulky.
Při větším množství dotazů bylo z důvodu přehlednosti nutno použít stránkování. Počet těchto dotazů na jednu stránku lze jednoduše změnit úpravou příslušné konstanty na počátku skriptu admindotazy/dotazy_prehled.php.
- 26 -
Závěr
5 Závěr Cílem práce bylo vytvořit aplikaci, která umožní občanům města vznášet dotazy a komunikovat s odbory nebo konkrétními zástupci města. Vývoj aplikace je hotov a celý projekt je nyní připraven k praktickému nasazení, realizace byla však odložena. Důvodem je příprava nového informačního portálu města. Vedení města zatím nerozhodlo, zda tuto službu občanům zařadí pod své stávající webové stránky a nebo projekt zahrne právě do nově připravovaného portálu. Zprovoznění systému dotazů tak bylo bohužel dočasně odsunuto do pozadí. V průběhu zkušebního provozu aplikace do reálného provozu se mohou, jako u každé aplikace, projevit drobné problémy, které budou odchytnuty a vyřešeny. Ladění je časově velmi náročná činnost. A i přes značnou snahu se nemusí podařit odchytit všechny neočekávané stavy a situace, které mohou v jednotlivých částech aplikace nastat. Některé tyto stavy se mohou objevit až po velmi dlouhé době běhu aplikace v reálných podmínkách. Další drobné problémy mohou nastat v případě přesunů aplikací na jiné servery s jiným nastavením a jinými verzemi PHP a SQL. Současně s přechodem aplikace do skutečného provozu lze očekávat, že budou ze strany zadavatelů vzneseny další požadavky na případné rozšíření funkcí, které se budou jevit jako přínosné pro celý systém. Po prvním rychlém prozkoumání aplikace požadoval zatím zadavatel přidání pouze jedné funkce, a to emailové notifikace jakékoliv události. Dokumentace bude dotvořena až po důkladnějším zhodnocení ze strany zadavatele a po vyřešení jeho dodatečných požadavků na změny. Návod k užívání bude pravděpodobně řešen pomocí nápovědných textů, popisků a bublinových nápověd přímo v aplikaci samotné. Celý systém dotazů obsahuje takřka 3000 řádků zdrojového kódu, což odpovídá velikosti 82 KiB. Další 10 KiB kódu zabírají různé javascripty a soubory kaskádových stylů. Vše je rozděleno do 34 skriptů.
Při tvorbě této práce byly použity open-source a freeware produkty PHP, MySQL, PhpMyAdmin, PSPad a OpenOffice.
- 27 -
Literatura
6 Literatura [1] Wikipedia, Asynchronous JavaScript and XML [online]. Verze 2.12.2007 [cit. 2008-03-31]. Dostupný z WWW: . [2] Robert Haas, Jak měřit úspěch webu [online]. Symbio digital s.r.o, 8.2.2005 [cit. 2008-05-13]. Dostupný z WWW: . [3] GRAPPONE, Jennifer , COUZIN, Gradiva. SEO - Search Engine Optimization. Roman Skřivánek, Dana Balaštíková. [s.l.] : Zoner press, 2007. 328 s. ISBN 978-80-86815-85. [4] LACKO, Luboslav, SQL: Hotová řešení. Tomáš Edér. Brno : Computer press, 2003. 298 s. ISBN 80-7226-975-5. [5] ŽÁK Karel, Modelování databází [online]. Internet Info s.r.o., 1998-2008 [cit. 2008-05-13]. Dostupný z WWW: . [6] BUDD Andy, CSS : filtry, hacky a pokročilé postupy. Jan Gregor. [s.l.] : Zoner press, 2007 270 s. ISBN 978-80-86815-54-1
- 28 -
Slovník pojmů a zkratek
7 Slovník pojmů a zkratek AJAX
(Asynchronous JavaScript and XML) je obecné označení pro technologie vývoje interaktivních webových aplikací, které mění obsah svých stránek bez nutnosti jejich znovunačítání. Na rozdíl od klasických webových aplikací poskytují uživatelsky příjemnější prostředí, ale vyžadují použití moderních webových prohlížečů.
CSS
Zkratka pro anglický název Cascading Style Sheets, česky tabulky kaskádových stylů. Je to jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML.
ERD
(Entitně relační diagram). Diagram používaný pro návrh databází a tabulek.
HTTPS
HTTPS je nadstavba počítačového protokolu HTTP, která poskytuje zvýšenou bezpečnost před odposloucháváním či podvržením dat. HTTPS není zcela jiný protokol, data jsou přenášena pomocí HTTP, ale jsou šifrována pomocí SSL nebo TLS, což zaručuje ochranu proti packet-sniffingu i man-in-the-middle útokům. HTTPS implicitně komunikuje prostřednictvím TCP portu 443 (u nechráněného HTTP je to port 80).
IS
(Informační systém) je systém pro sběr, udržování, zpracování a poskytování informací a dat.
LDAP
(Lightweight Directory Access Protocol) je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru. Podle tohoto protokolu jsou jednotlivé položky na serveru ukládány formou záznamů a uspořádány do stromové struktury (jako ve skutečné adresářové architektuře). Je vhodný pro udržování adresářů a práci s informacemi o uživatelích (např. pro vyhledávání adres konkrétních uživatelů v příslušných adresářích, resp. databázích).
MyISAM
je nejpoužívanější formát uložiště dat (storage engine) v databázovém systému MySQL. Je následovníkem formátu ISAM (Indexed Sequential Access Method).
MySQL
je databázový systém, vytvořený švédskou firmou MySQL AB.
PHP
(rekurzivní zkratka PHP: Hypertext Preprocessor, „PHP: Hypertextový preprocesor“, původně Personal Home Page) je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek.
SEO
(Search Engine Optimization, optimalizace pro vyhledávače) je metodologie
- 29 -
Slovník pojmů a zkratek vytváření a upravování webových stránek takovým způsobem, aby byly ve výsledcích hledání v internetových vyhledávačích zobrazeny na nejlepších místech (tj. tam, kde je hledající hledají). Cílem je nalákat na vlastní stránky co nejvíce zákazníků. SHA
(Secure Hash Algorithm) je rozšířená hashovací funkce, která vytváří ze vstupních dat výstup (otisk) fixní délky.
SQL
(Structured Query Language) je standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích. SQL je zkratka anglických slov.
TTS
(Text To Speech) je systém syntetizující řeč z psaného textu.
UML
(Unified Modeling Language) je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů.
W3C
(World Wide Web Consortium) je mezinárodní konsorcium, jehož členové společně s veřejností vyvíjejí webové standardy pro World Wide Web.
WYSIWYG je akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totožná s výslednou verzí dokumentu. XHTML
je značkovací jazyk pro tvorbu hypertextových dokumentů v prostředí WWW vyvinutý W3C. Původně se měl stát nástupcem jazyka HTML.
XML
(eXtensible Markup Language, česky rozšiřitelný značkovací jazyk) je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Umožňuje snadné vytváření konkrétních značkovacích jazyků pro různé účely a široké spektrum různých typů dat. Ve slovnících jsou použity texty a definice z projektu Wikipedia.
;“){kind=link}
