Masarykova univerzita Fakulta informatiky
Informační portál pro eGovernment (Diplomová práce)
Brno 2010
Bc. Tereza Dvořáková
Prohlášení: Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, ze kterých jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Tereza Dvořáková
Shrnutí Práce se věnuje problematice eGovernmentu a nedostatku portálů s veškerými informacemi o této oblasti pro občany. Pro potřeby práce byl vytvořen portál, na kterém mohou být uloženy články uživatelů obsahující informace o procesu elektronizace veřejné správy. Analýza a návrh portálu jsou součástí práce. Stejně tak jsou v práci popsány jednotlivé komponenty portálu a funkcionality a vzhled stránek.
Klíčová slova eGovernment, wikipedia, eGON, CZECH Point, XHTML, Java třídy, informační portál, entitněrelační diagram, diagram případů užití, XML soubory
Poděkování Na tomto místě bych ráda poděkovala svému vedoucímu práce, prof. RNDr. Jiřímu Hřebíčkovi, CSc., a PHDr. Irině Zálišové za jejich pomoc a cenné rady.
1. ÚVOD ...................................................................................................................... 1 2. EGOVERNMENT ...................................................................................................... 2 2.1. Definice eGovernmentu podle OECD ........................................................................................................ 2 2.2. Definice eGovernmentu podle Ministerstva vnitra ČR: ........................................................................ 2 2.3 EGON – symbol eGovernmentu .................................................................................................................. 2 2.4. Czech POINT .................................................................................................................................................. 3 2.5 eGA čili zákon o eGovernmentu ................................................................................................................. 4 2.6 KIVS – Komunikační infrastruktura veřejné správy .............................................................................. 4 2.7 Základní registry veřejné správy............................................................................................................... 5 2.8 Informační systém datových schránek - ISDS ......................................................................................... 5 2.9 Strategie rozvoje služeb informační společnosti na období 2008 - 2012 .......................................... 6 2.10 Informační portál ....................................................................................................................................... 9 2.10.1 Typy portálů .......................................................................................................................................... 9
3. POUŽITÉ TECHNOLOGIE ...................................................................................... 11 3.1 Java ................................................................................................................................................................ 11 3.1.1 Historie ................................................................................................................................................... 11 3.1.2 Základní vlastnosti jazyka Java ............................................................................................................. 12 3.1.3 Platforma Java ........................................................................................................................................ 12 3.1.4 Implementace ........................................................................................................................................ 13 3.1.5 Automatická správa paměti .................................................................................................................. 13 3.2 eXtensible Markup Language - XML ........................................................................................................ 14 3.2.1 Historie XML .......................................................................................................................................... 14 3.2.2 Vlastnosti XML ....................................................................................................................................... 15 3.3 eXtensible HyperText Markup Language – XHTML.............................................................................. 16
4. ANALÝZA A NÁVRH INFORMAČNÍ PORTÁLU ....................................................... 18 4.1. Popis systému ............................................................................................................................................. 18 4.2 Diagram případů užití................................................................................................................................ 19 4.2.1 Toky událostí ......................................................................................................................................... 19 4.3 Diagram tříd ................................................................................................................................................ 22 4.4 Entitně-relační diagram ............................................................................................................................ 22 4.4.1 Definice entit .......................................................................................................................................... 23 4.4.2 Definice vazeb ........................................................................................................................................ 24
5. ŘEŠENÍ APLIKACE ................................................................................................ 25 5.1 Třídy a soubory BackEndu .......................................................................................................................... 26 5.2 Třídy a soubory FrontEndu ......................................................................................................................... 34
6. INFORMAČNÍ PORTÁL – VZHLED STRÁNEK A PRÁCE S PORTÁLEM ................... 42 7. ZÁVĚR ................................................................................................................... 46 8. POUŽITÁ LITERATURA ........................................................................................ 47
1. Úvod Žijeme v době, která je plně modernizovaná, plná počítačů a jiných elektronických zařízení, které slouží ke zjednodušení života. Nikoho již nepřekvapí, že v komerční sféře jsou využity veškeré dostupné komunikační a informační technologie. Naštěstí, i veřejná správa se snaží nezaostávat. V České republice se jednotlivé části veřejné správy postupně modernizují, aby poskytly občanům pohodlnější každodenní interakci s úřady. Tomuto procesu modernizace veřejné správy se říká proces eGovernmentu. Pokud se občan chce dozvědět cokoliv o rozvoji elektronizace a modernizace veřejné správy, musí si jednotlivé informace vyhledat různě na internetu. Proto, aby nemusel vyhledávat jednotlivé články z různých koutů světa, je vytvořena tato práce. Práce se zabývá otázkami vývoje eGovernmentu v České republice a snaží se poskytnout uživateli jednotné informace o tomto procesu a o věcech s ním spojených. Práce je především zaměřena na programovou část. Pro účely mé práce byl vytvořen informační portál, který pracuje na principech wikipedie. Každý uživatel se může do systému přihlásit a může publikovat články obsahující informace o eGovernmentu. Kdokoliv může v článcích vyhledávat – a to pomocí zadané ontologie. Vyhledávač nabídne nejen fulltextové výsledky, ale také najde výsledky pro slova nějakým způsobem příbuzná se zadaným slovem. Prohledávány jsou nejen články, ale také přiložené soubory – zejména pdf soubory. Práce je rozdělena do několika kapitol. V první části jsou definovány základní pojmy, je zde nastíněna problematika modernizace veřejné správy a popsány informační portály. Druhá část je věnována použitým technologiím. Další část je věnována analýze a návrhu samotných stránek, které jsou součástí práce. V předposlední kapitole se věnuji jednotlivým částem programu a jejich popisu a poslední kapitola je věnována samotným stránkám informační portálu.
1
2. eGovernment
2.1. Definice eGovernmentu podle OECD1 „Výraz e-government se zaměřuje na využití nových informačních a komunikačních technologií (ICT) vládou, jako je používání v celé řadě vládních funkcí. Zejména propojení potenciálu internetu a příbuzných technologií má potenciál k transformaci struktury a k fungování vlády.“
2.2. Definice eGovernmentu podle Ministerstva vnitra ČR2: eGovernment je využívání informačních technologií veřejnými institucemi pro zajištění výměny informací s občany, soukromými organizacemi a jinými veřejnými institucemi za účelem zvyšování efektivity vnitřního fungování a poskytování rychlých, dostupných a kvalitních informačních služeb. V České republice s pojmem eGovernment souvisí hned několik dalších pojmů, jako například eGon, informační systém datových schránek, Czech POINT, základní registry a jiné. Veškeré základní pojmy jsou vysvětleny níže.
2.3 EGON – symbol eGovernmentu3 eGon je symbolem eGovernmentu v České republice. Je v přeneseném významu živý organismus, kde se fungování jednotlivých částí navzájem podmiňuje. Existenci a životní funkce eGONa zajišťují: Prsty – Czech POINT – soustava snadno dostupných míst Oběhová soustava – KIVS – Komunikační infrastruktura veřejné správy zajišťuje bezpečný přenos dat Srdce – Zákon o Egovernmentu – zákon o elektronických úkonech a autorizované konverzi č.300/2008 Sb. http://stats.oecd.org/glossary/detail.asp?ID=4752 http://www.mvcr.cz 3 http://www.mvcr.cz/clanek/egon-jako-symbol-egovernmentu-moderniho-pratelskeho-a-efektivnihouradu-252052.aspx 1 2
2
Mozek – Základní registry veřejné správy – bezpečné a aktuální databáze dat o občanech a státních i nestátních subjektech
Obrázek 2.1 Logo eGONa1
2.4. Czech POINT2 Czech POINT znamená Český Podací Ověřovací a Informační Národní Terminál. Jedná se o kontaktní místo veřejné správy, poskytující občanům zejména ověřené údaje z centrálních registrů, jako například výpis z rejstříku trestů. Jedním z důvodů vzniku těchto terminálů je zrychlení a zpřístupnění služeb občanům. Proto je postupně vytvářena rozsáhlá síť poboček těchto terminálů. Czech pointy nabízejí: Výpis z katastru nemovitostí Výpis z Obchodního rejstříku Výpis ze Živnostenského rejstříku Výpis z Rejstříku trestů Výpis bodového hodnocení řidiče Výpis ze seznamu kvalifikovaných dodavatelů Přijetí podání podle živnostenského zákona, Zdroj obrázku – http://mvcr.cz http://www.mvcr.cz/clanek/egon-symbol-egovernmentu-czech-point-kontaktni-mista-verejnespravy.aspx 1 2
3
Přijetí podání do registru účastníků provozu modulu autovraků ISOH konverzi dokumentů z listinné do elektronické formy a naopak Přijetí podání žádosti o zřízení datové schránky. Czech Pointy jsou dostupné na obecních úřadech a městských úřadech, pobočkách České pošty, pobočkách Hospodářské komory ČR, českých zastupitelstvích v zahraničí, u vybraných notářů nebo prostřednictvím e-shopu na www.czechpoint.cz. Všechny výpisy z CzechPointů jsou zpoplatněny, poplatek pak závisí na typu výpisu, délce aj.
Obrázek 2.2 Logo Czech Pointu1
2.5 eGA čili zákon o eGovernmentu2 Cílem zákona je vytvoření optimálních podmínek pro elektronickou komunikaci mezi úřady a občany i mezi úřady samotnými. Tímto se také umožní vedení elektronických spisů ve správních řízeních. Hlavní nástroj pro provádění elektronických úkonů jsou datové schránky. Druhým klíčovým nástrojem zákona o elektronických úkonech je autorizovaná konverze dokumentů. Což znamená převedení dokumentu z listinné podoby do dokumentu obsaženého v datové zprávě nebo převedení dokumentu obsaženého v datové zprávě do listinné podoby a zároveň ověření shody jejich obsahu a připojení ověřovací doložky.
2.6 KIVS – Komunikační infrastruktura veřejné správy3 Komunikační infrastruktura veřejné správy představuje sjednocení různých datových linek subjektů veřejné správy do jedné datové sítě. Hlavním cílem je vytvoření jednotné datové sítě, která bude poskytovat bezpečné datové připojení a vysoký standard nabízených služeb. Prostřednictvím KIVSu jsou propojeny orgány veřejné správy s registry nebo terminály Czech POINT. Zdroj obrázku – http://www.mvcr.cz http://www.mvcr.cz/clanek/ega-cili-zakon-o-egovernmentu.aspx 3 http://www.mvcr.cz/clanek/egon-symbol-egovernmentu-komunikacni-infrastruktura-verejnespravy.aspx 1 2
4
2.7 Základní registry veřejné správy1 Jeden z hlavních pilířů elektronizace veřejné správy je vytvoření centrálních registrů veřejné správy, které by řešily dosavadní nejednotnost, multiplicitu a neaktuálnost klíčových databází. Základním prvkem v registru je tzv. referenční údaj. Je to vlastně údaj, který bude přebírán ze systému základních registrů. V principu tak bude stačit jen jedna změna v registru. Ta se promítne i v ostatních registrech. Základní registry budou čtyři: Registr obyvatel (ROB) – obsahující základní informace o občanech a cizincích s povolením k pobytu Registr práv a povinností (RPP) – obsahující referenční údaje o působnosti orgánů veřejné moci Registr osob (ROS) – obsahující údaje o právnických osobách, podnikajících fyzických osobách, orgánech veřejné moci i o nekomerčních subjektech jako např. církve aj. Registr územní identifikace, adres a nemovitostí (RUIAN) – spravující údaje o základních územních a správních prvcích Všechny čtyři registry budou fungovat v rámci Informačního systému základních registrů, tzv. ISZR, který bude spravovat Správa základních registrů. Tento informační systém bude zajišťovat sdílení dat mezi jednotlivými registry, správu oprávnění přístupu k datům aj.
2.8 Informační systém datových schránek - ISDS2 ISDS je informační systém veřejné správy, obsahující údaje o datových schránkách, jejich uživatelích, přístupech do schránky a dalších záležitostech spojených s jejich provozem. Ministerstvo vnitra je správcem tohoto systému a provozovatelem je držitel poštovní licence, tedy Česká pošta s. p. Údaje ze systému jsou neveřejné. Datová schránka je definována jako elektronické úložiště speciálního typu. Je určena k doručování elektronických dokumentů od veřejných orgánů. Ze zákona musí mít každý orgán veřejné moci, každá podnikající osoba jak už právnická tak i fyzická zřízenou datovou schránku pro komunikaci s veřejnými orgány. Například pro zasílání obsílek k soudům a jiné. 1 2
http://www.mvcr.cz/clanek/zakladni-registry-verejne-spravy.aspx http://cs.wikipedia.org/wiki/Datov%C3%A1_schr%C3%A1nka
5
2.9 Strategie rozvoje služeb informační společnosti na období 2008 20121 Tato strategie byla publikována Radou vlády pro informační společnost v březnu roku 2008. Tento dokument stanovuje vizi České republiky jako jedné z pěti nejlepších zemí Evropské unie v oblasti rozvoje eGovernmentu. Toto je strategie pro rozvoj služeb v otevřené, demokratické společnosti, nikoliv strategie pro rozvoj informační společnosti jako takové, která může pouze vycházet ze svobodné iniciativy občanů a podnikatelů. Nicméně, vláda si stanovila úkol reformovat veřejnou správu a služby poskytované státem a veřejnými orgány, s cílem zefektivnit služby pro informační společnost. Budování eGovernmentu a rozvoj služeb informační společnosti není izolovaný úkol, ale úzce souvisí s racionalizací procesů a zavádění moderních nástrojů řízení ve veřejné správě, jakož i zlepšení právního prostředí a politické tvorby. Proto by tato strategie měla být vnímána v širším kontextu všech aktivit zaměřených na posílení efektivnosti veřejné správy a poskytování uživatelsky příjemných služeb. Hlavním cílem strategie je transformovat a zjednodušit procesy veřejných služeb tak, aby využívaly moderní informační a komunikační technologie takovým způsobem, kterým jsou využívány v komerční sféře. Moderní informační a komunikační technologie umožňují vytvořit zcela nové portfolio služeb a mohou výrazně zjednodušit komunikaci občanů a firem s veřejnou správou. Současně je dalším cílem výrazně zvýšit efektivitu veřejné správy. Pokud jde o znepokojené občany, cílem nové strategie je poskytovat pohodlnou, bezpečnou a spolehlivou elektronickou komunikaci se všemi úrovněmi vlády pro tolik životních událostí jak jen je to možné.
Z hlediska infrastruktury, mezi strategické cíle patří: Konsolidovaná databáze, použitá pro stavbu obsahu a aplikací Ucelený soubor právních předpisů s cílem poskytnout právní základ a podporu pro eGovernment
1
http://www.epractice.eu/en/factsheets/
6
Robustní, bezpečné a efektivní infrastruktury umožňující přístup ke zdrojům dat, které mají potenciál pro další rozvoj Soubor klíčových aplikací pro práci s „životními událostmi a komunikace společnosti“ se státní správou 20% snížení administrativních nákladů do roku 2013 v důsledku vývoje eGovernmentu
Strategické mezníky by se daly shrnout takto: Do roku 2009, dostupnost Datových schránek (osobních registrů pro komunikaci s orgány veřejné moci), rozvinutá síť míst veřejných kontaktů správy (Czech POINT Network), kde bude možné získat ověřené výpisy z vybraných registrů. Síť bodů Czech POINT byla úspěšně spuštěna v pilotní fázi v dubnu 2007 a v lednu 2008 byla rozšířena na celou Českou republiku. V srpnu 2009 sestávala celá síť z více než 3700 fyzických kontaktních míst, kde mají občané přístup ke všem veřejným záznamům a mohou požadovat výpisy z různých rejstříků pomocí one-stop bodu. Pokud jde o systém datových schránek, prvního listopadu 2009 má začít jeho plný provoz. Sestavení centrálního registru do roku 2010 Právní základ pro dosažení cílů strategie bude plně zaveden v roce 2010 Do roku 2012, provedení funkčních aplikací nezbytných pro zdravotnictví, sociální péči, správní, soudní a daňové řízení, jakož i pro provozní infrastrukturu pro dlouhodobé ukládání a archivaci elektronických dokumentů Do roku 2015 bude proces digitalizace databází plně dokončen – včetně geoinformačního systému
Existují tři zásady pro provádění strategie: Zaostřeno více na občana než na úřady Řízené provedení s jasnými přínosy pro občany Účinně a efektivně – vygenerovaná hodnota převyšuje náklady
Tato strategie se bude provádět prostřednictvím řady vzájemně propojených projektů, které jsou rozděleny do pěti programových oblastí:
7
Základní registry a identifikace, včetně organizačních struktur a technické podpory, aby se zabránilo duplicitě dat a udržení požadované bezpečnostní normy Univerzální kontaktní místo pro komunikaci s veřejnou správou pomocí systému datových schránek Bezpečná komunikace mezi orgány veřejné moci, také mezi nimi a občany a nezávislý dohled nad dodržováním bezpečnostních a provozních pravidel Digitalizace datových archivů Individuální služby informační společnosti, v prioritách: o
Zdravotní péče, odchod do důchodu, vzdělání
o
Služby veřejné správy v užším slova smyslu (soudní, správní, daňové řízení a správa elektronických souborů), které umožňují snadný přenos informací mezi jednotlivými orgány
o
Správa majetku státu (registrace a správa majetku, rozpočtování, státní pokladna, veřejné zakázky a dotace)
Úspěch bude měřen z pohledu občanů, kteří zodpoví následující otázky: Zlepšila se a zjednodušila komunikace s veřejnou správou v každodenním životě? Může občan poskytnout požadované informace pouze jednou, nebo je musí sdělit několikrát? Jsou elektronické formuláře více spolehlivé než tradiční papírové formuláře pro komunikaci s veřejnou správou? Má zavedení eGovernmentu výrazný podíl na snížení administrativních nákladů? Jsou vize „aby obíhala data a ne občan“ splněny?
Pokud jde o rozměr infrastruktury, jsou kritéria hodnocení na základě těchto kontrolních bodů: Platný, komplexní rámec pro podporu rozvoje eGovernmentu Dostupnost datových schránek pro elektronickou komunikaci Konsolidované a interoperabilní základní registry Funkční infrastruktura pro dlouhodobé ukládání a archivaci elektronických dokumentů Univerzální kontaktní místa veřejné správy k dispozici fyzicky i virtuálně Bezpečný přístup k základním údajům o základních aplikacích a možnost odpovědi na otázky prostřednictvím elektronické správy
8
Konečným ukazatelem úspěchu bude i nadále občanská spokojenost. Tato strategie se bude považovat za úspěšnou, pokud budou občané vnímat řešení elektronické veřejné správy jako přirozený prvek každodenního života a jako skutečnou pomoc při řešení každodenních životních událostí.
2.10 Informační portál1 Informační portál prezentuje informace z různých zdrojů jednotným způsobem. Kromě standardních funkcí vyhledávače, portály nabízejí další služby, jako jsou databáze, emailové služby, informace aj. Tento typ portálu lze považovat za umístění mnoho typů informací z různých zdrojů na jednom místě v internetu. Lidé, kteří používají informační portály, jsou často pouze spotřebiteli, nepublikují sami na portálech. Hlavním konceptem je prezentovat uživateli jedinou stránku, která seskupuje obsahy z celé řady dalších systémů nebo serverů. Portály, které představují funkčnost aplikace pro uživatele, jsou ve skutečnosti pouze předním kusem nastavení serveru. Servisně orientovaná architektura je jedním z příkladů, jak může být portál využíván k doručování aplikačnímu serveru obsah a funkcionalitu. Aplikační server nebo architektura pak vykonává skutečnou funkci aplikace. Tento aplikační server je zase připojen k databázovým serverům.
2.10.1 Typy portálů Osobní portál Osobní portál je určen k použití distribuovaných aplikací. Osobní portály mohou být spojeny s nějakým konkrétním tématem, jako například poskytování odkazů na externí obsah. Portály nejsou omezeny na pouhé poskytování odkazů. Zpravodajské portály Tradiční média se rychle přizpůsobila novému věku technologií. Tyto nové mediální kanály dávají divákovi příležitost k dosažení informací v kratším čase než z tištěných médií.
1
http://en.wikipedia.org/wiki/Web_portal
9
Vládní webové portál Koncem 90. let se mnoho vlád zavazuje k vytvoření webových portálů pro své občany. V České republice je to informační portál portal.gov.cz. Firemní webové portály Firemní portály nabízí svým zaměstnancům a zákazníkům možnost samoobslužného přístupu. Skladové portály Tyto portály jsou také známy jako portály kapitálového trhu nebo burzovní portály. Tyto portály usnadňují proces informování akcionářů s obsáhlými online daty, jako jsou aktuální ceny, poslední novinky, zprávy a oznámení. Vyhledávácí portály Vyhledávací portály poskytují souhrnné výsledky z několika různých vyhledávačů na jedné stránce. Nabídkové portály Nabídkové portály představují bránu do vyhledávání / podávání / podání / archivování údajů o nabídkách. S nabídkovým portálem budou všechny postupy výběrového procesu vykonány na webu. Hostované webové portály Hostované webové portály získaly popularitu řadou firem a řada z nich je začala nabízet jako hostovanou službu. V mnoha ohledech slouží jako nástroj pro zveřejňování informací. Doménově specifické portály Řada portálů, které jsou specifické pro danou doménu, nabízejí přístup ke spřízněným společnostem a službám. Ve stejném duchu se objevily informační portály.
10
3. Použité technologie 3.1 Java1 3.1.1 Historie James Gosling, Mike Sheridan a Patrick Naughton zahájili vývoj jazyka Java v červnu roku 1991. Java byla původně navržena pro účely interaktivní televize, ale to bylo příliš pokročilé. Jazyk byl původně nazván „Oak“ podle dubu, který stál u Goslingovy kanceláře. Později byl přejmenován na „Green“ a nakonec se ustálil název „Java“. Goslingovým cílem byla realizace virtuálního stroje a jazyka, který by se svoji strukturou podobal C/C++. Společnost Sun Microsystems vydala první veřejnou implementaci jako Java 1.0 v roce 1995, která slibovala heslo „napsat jednou, běžet kdekoliv“, což znamená poskytování služeb bez poplatku
a
možnost
spustit
program
na
jakékoliv
platformě.
Poměrně
bezpečná
konfigurovatelná bezpečnost dovoluje síťové a souborové omezení přístupu. Hlavní webové prohlížeče brzy začlenily schopnost spouštět Java applety na webových stránkách a Java se stala velmi rychle populární. S příchodem Java 2.0 (vypuštěné původně jako J2SEE 1.2 v prosinci 1998) měly nové verze více konfigurací postavených pro různé typy platforem. Například platforma J2EE pro rozsáhlé distribuované systémy a pro podnikové aplikace nebo J2ME pro mobilní aplikace. J2SE byla označena jako Standard Edition. V roce 2006 Sun přejmenoval nové verze na Java EE, Java ME, Java SE kvůli marketingovým účelům. Java zůstala de facto standard, který lze ovládat pomocí Java Community Process. Najednou v roce 1997 Sun zveřejnila téměř celou Java implementaci bez jakéhokoliv poplatku. Sun dosáhla příjmu z Javy prostřednictvím prodeje licencí na specializovaných produktech jako je Java Enterprise system. Společnost rozlišuje své produkty na Software Development Kit (SDK) a Runtime Environment (JRE, podmnožina SDK). Hlavní rozdíl spočívá v tom, že JRE má nedostatek kompilátorů, obslužných programů a hlavičkových souborů. 13. listopadu 2006 vydala Sun většinu Javy jako open source software za podmínek GNU General Public License. 8. května 2007 byl tento proces ukončen, takže všechny základní kódy v jazyce Java jsou k dispozici jako free/open source software, kromě malé části kódu, ke kterému nemá Sun autorská práva.
1
http://en.wikipedia.org/wiki/Java_%28programming_language%29
11
3.1.2 Základní vlastnosti jazyka Java Jednoduchost – syntaxe je upravenou a zjednodušenou verzí syntaxe jazyka C a C++ Objektová orientovanost – s několika výjimkami, jsou všechny typy objektové Distribuovanost – je navržen pro podporu aplikací v sítích Interpretovanost – místo kódu se vytváří mezikód, který je nezávislý na architektuře počítače. Program pak může pracovat na jakémkoliv počítači, který má virtuální stroj javy (JVM). Robustnost – je určen pro psaní spolehlivé softwaru. Používá silnou typovou kontrolu. Generační správa paměti – správa paměti je uskutečněna pomocí Garbage Collectoru, který automaticky vyhledává ty části paměti, které již nejsou používány, a uvolňuje je pro další použití. V posledních verzích je paměť rozdělena na více částí a každý používá jiný algoritmus pro garbage collector. Bezpečnost – počítač, na kterém je program zpracováván, je chráněn v síťovém prostředí před napadením nepřátelským kódem Nezávislost na architektuře – díky JVM běží vytvořená aplikace na jakémkoliv operačním systému Přenositelnost – přenositelnost je myšlena v rámci jedné platformy. Platforma určená pro jednodušší zařízení nemusí podporovat všechny funkce platformy pro složitější zařízení. Jazyk je nezávislý i v případě datových typů. Výkonnost – do strojového se kódu se překládá jen potřebný kód, proto není ztráta výkonu tolik významná. Víceúlohovost – podporuje zpracování vícevláknových aplikací Dynamičnost – jazyk byl vyvinut pro dynamicky se rozvíjející prostředí, knihovna může být za chodu rozšiřována. Elegantnost – snadno čitelný kód
3.1.3 Platforma Java Jedním z charakteristických rysů Javy je přenositelnost, to znamená, že programy napsané v jazyce Java musí běžet podobně na všech podporovaných hardwarových platformách nebo operačních systémech. Toho je dosaženo tím, že Java jazyk je překládán do mezikódu, nazvaném Java bytecode. Java bytecode je analogický strojovému kódu, ale je určen pro virtuální stroje psané specificky pro daný hardware. Koncoví uživatelé pak používají Java Runtime Environment (JRE) na vlastním stroji pro samostatné Javové aplikace nebo ve webovém prohlížeči pro Java applety. Standardizované knihovny poskytují v obecném smyslu přístup k hostitelským specifickým funkcím jako je grafika nebo síťování.
12
Hlavní výhodou použití bytekódu je portování. Nicméně, interpretovatelný program téměř vždy poběží pomaleji než programy přeložené do nativního kódu. Just-in-time kompilátory, které překládají bytekód do strojového kódu za běhu, byly zavedeny již téměř od počátku. Za ta léta byla tato funkce virtuálního stroje optimalizována tak, že výkon je srovnatelný se zkompilovaným C kódem.
3.1.4 Implementace Sun Microsystems oficiálně vlastní licenci Java Standard Edition na platformy pro Linux, Mac OS X a Solaris. Ačkoliv v minulosti měla také licenci pro platformy Microsoft, licence vypršela a nebyla obnovena. Pro tuto a další platformy jsou k dispozici alternativní Java prostředí prostřednictvím sítě třetí strany. Nezávislost na platformě má zásadní význam pro strategii Java EE. Toto prostředí umožňuje přenosné server-side aplikace, jako jsou webové služby, Java servlety a Enterprise Java Beans, stejně tak jako vestavěné systémy založené na OSGi. Prostřednictvím nového projektu Glassfish, Sun pracuje na vytvoření plně funkční a jednotné open-source implementace Java EE technologie.
3.1.5 Automatická správa paměti Java používá automatický garbage collector ke spravování pamětí v životním cyklu objektů. Programátor určuje, kdy jsou objekty vytvořeny, a runtime Java je zodpovědná za vymáhání paměti, když objekty nejsou používány. Jakmile nezůstanou žádné odkazy na objekt, nedosažitelná paměť je automaticky uvolněna pomocí garbage collectoru. K úniku paměti může dojít, pokud programátorský kód drží odkaz na objekt, který již není potřeba. Jednou z myšlenek, které stojí za automatickým modelem správy paměti, je, že programátoři mohou být ušetřeni nutnosti provádět manuální správu paměti. V některých jazycích je paměť pro tvorbu objektů implicitně přidělena ve frontě nebo explicitně přidělena a navrácena z haldy. Pokud program neuvolní daný objekt, dochází k blokování nepotřebné paměti. Pokud se program pokusí o přístup nebo navrácení paměti, která již byla navrácena, výsledek je nedefinovatelný a je těžké předpovědět, zda se program stane nestabilní nebo se zhroutí. Tento problém může být částečně napraven pomocí inteligentních ukazatelů, ty se musí přidat do režie a složitosti. Garbage collector může pracovat kdykoliv. V ideálním případě je spuštěn, když je program nečinný. Je zaručeno, že bude spuštěn, pokud není dostatek volné paměti pro alokování nového objektu. Explicitní správa paměti není v jazyce Java možná.
13
Stejně jako v C++ a některých jiných objektově orientovaných jazycích, proměnné primitivních datových typů nejsou objekty. Hodnoty primitivních typů jsou buď uloženy v oblastech (pro objekty) nebo na zásobníku (pro metody) spíše než na haldě, jak běžně platí pro objekty. Toto bylo vědomé rozhodnutí návrhářů Javy z výkonnostních důvodů. Z tohoto důvodu nebyla Java považována za čistě objektově-orientovaný programovací jazyk. Nicméně autoboxing umožňuje programátorům postupovat jako by primitivní typy byly instance tříd.
3.2 eXtensible Markup Language - XML1 eXtensible Markup Language (zkráceně XML, česky rozšiřitelný značkovací jazyk) je značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Tento jazyk je zjednodušenou podobou jazyk SGML. XML umožňuje snadné vytváření konkrétních značkovacích aplikací pro různé účely a typy dat. Zpracování XML je podporováno řadou programovacích jazyků a nástrojů. Tento jazyk je určen zejména pro výměnu dat mezi aplikacemi a pro publikování dokumentů, kde popisuje strukturu z hlediska věcného obsahu, nezabývá se vzhledem. Prezentací se pak zabývají kaskádové styly.
3.2.1 Historie XML Všestrannost SGML pro dynamické zobrazování informací byla dohodnuta vydavateli časných digitálních medií v 80. letech minulého století, ještě před vzestupem internetu. V polovině 90. let získali někteří vývojáři SGML zkušenosti s World Wide Webem a věřili, že SGML nabídne řešení některých problémů, kterým musel web čelit, jako například mohutnost. V roce 1995 byl SGML přidán na seznam aktivit W3C, když se Dan Connoly stal zaměstnancem. Samotné práce byly zahájeny v roce 1996, když ing. Jiří Bosák vyvinul chartu a rekrutoval spolupracovníky. Bosák působil v malé komunitě lidí, kteří měli dobré zkušenosti jak s SGML tak i na webu. XML byl sestaven pracovní skupinou 11 členů a podporován členskou základnou o 150 členech. Technická debata probíhala díky mailingové zájmové skupině a problémy byly řešeny na základě konsesu nebo díky hlasování většiny pracovníků skupiny. Záznamy o designových rozhodnutích a jejich zdůvodněních byly sestaveny Michaelem Sperberg-McQueenem 4. prosince 1997. James Clark působil jako technický vedoucí pracovní skupiny, přispěl především prázdným elementem „<empty/>“ a názvem „XML“. Další návrhy názvu jazyka byly například „MGML“ (Minimal 1
http://cs.wikipedia.org/wiki/Xml
14
Generalized Markup Language), „SLIM“ (Structured Language for Internet Markup) nebo „MAGMA“ (Minimal Architekture for Generalized Markup Applications). Editoři pro specifikaci jazyka byli původně Tim Bray a Michael Sperberg-McQueen. Během vývoje projektu, Bray přijímal poradenské zakázky od Netscape, čímž vznikly protesty ze strany Microsoftu. Bray byl požádán, aby dočasně odstoupil od redigování. To vedlo ke sporu ve skupině, nakonec byl problém vyřešen jmenováním Jeana Paoliho z Microsoftu jako třetím editorem. Skupina vyvíjecí XML se nikdy osobně nesetkala. Design byl vyvíjen pomocí emailů a telekonferencí. Hlavní návrh designu byl dosažen už po dvaceti týdnech intenzivního vývoje v době od července do listopadu roku 1996. Tehdy byl zveřejněn první pracovní návrh specifikace XML. Další projektové práce pokračovaly roku 1997. XML 1.0 se stal 10. února součástí W3C.
3.2.2 Vlastnosti XML XML je standardní formát pro výměnu informací. Je to jednoduchý otevřený formát, který není úzce propojen s nějakou konkrétní platformou nebo technologií. Je založen na jednoduchém textu a je zpracovatelný jakýmkoliv textovým editorem. Specifikace XML je zdarma přístupná všem, tudíž každý může do svých aplikací implementovat podporu XML. XML od svých počátků myslel na potřeby odlišných jazyků než je angličtina. Implicitně se používá znaková sada Unicode, ale je přípustné i jiné kódování. V XML mohou být vytvořeny dokumenty, které obsahují texty v několika jazycích najednou. V jednom dokumentu j možno přepínat mezi různými jazyky. Pomocí XML tagů se v dokumentu vyznačuje význam jednotlivých částí textu. Dokumenty pak obsahují mnohem více informací, než když je kladen důraz na prezentaci. XML samo o sobě nenabízí žádné prostředky pro definici vzhledu. Pro tyto účely existují stylové jazyky, které definují, jak se které elementy mají zobrazit. Mezi nejznámější stylové jazyky patří kaskádové styly (CSS). Ty lze použít pro jednoduché formátování. XML neobsahuje předdefinované tagy. Je třeba si nadefinovat svoje vlastní. Tagy je možno nadefinovat v souboru DTD. Program, který pak kontroluje, zda dokument odpovídá své definici, se nazývá parser. Ten pak můžeme při vývoji aplikace použít k detekci většiny chyb v datech. DTD není jediný definiční jazyk XML. Příkladem dalšího definičního jazyka je například DocBook, který je určen pro vytváření knih, článků, publikací a podobně. Další vlastností XML patří, že v jednom dokumentu se dá nezávisle na sobě použít několik druhů značkování. Aktuální verze XML je verze 1.1. První verze 1.0 existuje již v páté revizi. První verze dovolovala užívání znaků platných v Unicode 2.0.
15
3.3 eXtensible HyperText Markup Language – XHTML1 XHTML patří do rodiny značkovacích jazyků XML. XHTML rozšiřuje jazyk HTML, ve kterém jsou psány webové stránky. Zatímco HTML byl definován jako aplikace SGML, XHTML je aplikací XML, přísnější podmnožinou SGML. XHTML je „přeformulování tří typů dokumentů html jako aplikací XML 1.0“. W3C i nadále udržuje HTML 4.01 standard a specifikaci pro HTML5 a ten se aktivně rozvíjí. V současné době je aktuální XHTML 1.0 standard a W3C poznamenalo, že „rodina XHTML je dalším krokem ve vývoji internetu. Přechodem na XHTML mohou vývojáři vstoupit do světa XML a získat tak všechny jeho související výhody“. V roce 2004 se nezávisle na W3C vytvořila pracovní skupina WHATWG, která začala pracovat na obyčejném HTML, který není založen na XHTML. Většina hlavních dodavatelů prohlížečů nebyla ochotná k provádění funkcí v nových návrzích W3C v XHTML 2.0. WHATWG začal nakonec pracovat na standardu, který podporuje jak XML, HTML5 tak i W3C standardy jako je XHTML2. V roce 2009 povolilo W3C charterovou dohodu, že HTML5 bude jediným budoucím standardem HTML a to včetně XML a non-XML serializací. Z této úmluvy W3C naznačuje, že většina autorů aplikací raději využívá syntax HTML než XHTML. XHTML byl vytvořen, aby HTML více rozšiřoval a zvyšoval interoperabilitu s dalšími formáty dat. HTML4 byl zdánlivě aplikace SGML, nicméně SGML specifikace byla složitá a ani webové prohlížeče ani HTML4 standard nebyly s ní v souladu. Standard XML, který byl schválen v roce 1998, poskytl jednodušší formát dat blíže k jednoduchosti HTML4. Přepnutím do formátu XML se očekávalo, že HTML se stane kompatibilní s běžnými XML nástroji; servery budou schopny transformovat obsah, podle potřeby pro koncová zařízení jako jsou telefony. Díky využití jmenný prostorů XHTML poskytují rozšiřitelnost, včetně fragmentů z jiných jazyků založených na XML jako je například Scalable Vector Graphics a MathML. V neposlední řadě, obnovená práce by mohla poskytnout příležitost rozdělit HTML do opakovaně použitelných komponent (Modularizace XHTML) a vyčistit neúhledné části jazyka. Existují různé rozdíly mezi HTML a XHTML. Document Object Model je stromová struktura, která představuje stránky interně v aplikacích, HTML a XHTML mají dva různé způsoby značkování. Oba jazyky jsou méně výrazné než DOM, a obecně syntaxe XHTML je trochu výraznější než syntaxe HTML. První z rozdílů je, že XHTML využívá syntaxe XML, zatímco HTML využívá pseudosyntaxe SGML.
1
http://en.wikipedia.org/wiki/Xhtml
16
Podobnosti mezi HTML4 a XHTML1.0 vedly mnoho webových stránek a redakčních systémů k tomu, aby přijaly původní W3C XHTML1.0 doporučení. Pro podporu autorů v přechodu, W3C poskytlo pokyny k tomu, jak publikovat XHTML 1.0 dokumenty HTML kompatibilním způsobem, aby mohly být použity v prohlížečích, které nebyly původně navrhnuty pro XHTML. Takový HTML kompatibilní obsah je odeslán pomocí HTML typu média spíše než internetovým typem média XHTML. Většina webových prohlížečů má podporu pro všechny možné druhy médií XHTML. Pozoruhodnou výjimkou je Internet Explorer od společnosti Microsoft, který spíše než zobrazení xml / xhtml obsahu nabídne možnost uložení místa na disku. Poslední dvě verze tohoto prohlížeče vykazují tuto vlastnost. Vzhledem k tomu, že podpora není tolik rozšířená, většina vývojářů se radši použití XHTML, které není HTML kompatibilní, vyhýbá. Tudíž výhody, jako například jmenné prostory, nemají pro uživatele prospěch. Na začátku dvacátého-prvního století si někteří vývojáři kladli otázku, proč autoři webů odskočili k XHTML. Jiní namítali, že problémy používání XHTML mohou být způsobeny tím, že někteří autoři vytvářejí neplatné doklady XHTML a také tím, že v aplikaci IE nebyla dostatečná podpora. Také popisovali výhody dokumentů založených na XML jako například vyhledávání, indexování. Simon Peters zkoumal soulad XML s mobilními prohlížeči a dospěl k závěru, že tvrzení, že XHTML bude potřeba pro potřeby mobilních zařízení, je prostě jen mýtus.
17
4. Analýza a návrh Informační portálu
4.1. Popis systému
Informační portál je určen k publikování jednotlivých článků zaměřených na oblast elektronizace a modernizace veřejné správy. Samozřejmě by mohl být určen k publikování jakýkoliv článků. Také slouží k ukládání různých souborů, které s danou problematikou souvisí. Na portál mohou uživatelé přistupovat buď jako hosté, přihlášení uživatelé nebo super uživatelé. Každý uživatel má možnost se na portál zaregistrovat a mít tak mnohem více práv než nepřihlášený uživatel - host. Práva super uživatele může nastavit pouze administrátor. Administrátor a super uživatel mají zpřístupněnou sekci administrace, která je určena k vytváření, editaci a mazání kategorií článků a ontologií. Ontologie jsou nastavením skupiny slov, které se vyhledávají, když je jakékoliv slovo z této skupiny zadáno do vyhledávací funkce. V této části systému je možno také spravovat kategorie, ke kterým se pak přidávají již konkrétní články. Administrátor spravuje v administraci uživatele. Může jim měnit práva, emailové adresy a také může uživatele smazat. Pokud se tak stane, tak uživateli přijde informační email, že byl ze systému vymazán. Každý přihlášený uživatel má právo publikovat článek, vytvářet nové verze již vytvořených článků. Tato nová verze se automaticky nastaví jako aktuální a je zobrazována ostatním uživatelům. Smazat může uživatel pouze ten článek nebo verzi článku, kterou sám vytvořil. Super uživatel a administrátor mohou mazat vše. Každý uživatel, kterému byl smazán článek nebo jeho verze článku, je o této události upozorněn informativním emailem. Na portále se dá využit funkce hledání. Tuto funkci může využít jakýkoliv uživatel. Přihlášeným uživatelům se pak zobrazuje i historie článků, ve kterých bylo dané slovo nalezeno. Funkce hledání vezme zadané slovo a to nejdříve vyhledává ve všech skupinách ontologií, pokud zde slovo najde, pak ve všech článcích a přílohách hledá celou skupinu slov. Pokud se zadané slovo v ontologii nevyskytuje, je vyhledáváno pouze toto slovo.
18
4.2 Diagram případů užití
Obrázek 4.1 Use case diagram
4.2.1 Toky událostí Případ užití: File viewing 1. pu začíná volbou „zobrazit přílohu“ 2. systém nabídne formulář pro uložení nebo zobrazení daného souboru 3. uživatel potvrdí jednu z možností Případ užití: Article reading 1. pu začíná volbou „zobrazit článek“ 2. If uživatel je přihlášen 1. zobraz všechny historie daného článku 3. If uživatel není přihlášen 1. zobraz pouze aktuální verzi článku 4. uživatel potvrdí výběr článku a systém článek zobrazí
Případ užití: Word searching 1. pu začíná volbou „najdi slovo“ 2. hledej slovo v ontologiích 3. if najdeš slovo v nějaké skupině
19
1. hledej všechny slova dané skupiny v přiložených souborech 2. if uživatel je přihlášen 1. hledej skupinu slov ve všech verzích článků 3. if uživatel není přihlášen 1. hledej skupinu slov pouze v aktuálních verzích článků 4. if nenajdeš slovo v nějaké ontologii 1. hledej slovo v přiložených souborech 2. if uživatel je přihlášen 1. hledej slovo i v historiích článků 3. if uživatel není přihlášen 1. hledej slovo v aktuálních verzích článků Případ užití: File uploading 1. pu začíná volbou „nahraj soubor“ 2. systém nabídne formulář pro uložení souboru z adresáře počítače a potvrdí uložení souboru 3. systém uloží soubor do databáze Případ užití: Article creation 1. 2. 3. 4.
pu začíná volbou „vytvoř článek“ systém nabídne formulář pro vytvoření článku uživatel vyplní příslušné hodnoty článku a potvrdí uložení systém uloží článek do databáze
Případ užití: Article editation 1. 2. 3. 4.
pu začíná volbou „edituj článek“ systém nabídne formulář pro editaci článku uživatel vyplní příslušné hodnoty a potvrdí uložení nové verze článku systém uloží novou verzi článku do databáze
Případ užití: Article deleting 1. pu začíná volbou „smaž článek“ 2. if uživatel je přihlášen 1. if verze kterou chce smazat je v jeho vlastnictví 1. smaž článek z databáze 2. pu končí 2. if uživatel je superuživatel nebo administrátor 1. smaž článek z databáze 2. pošli email uživateli, který daný článek vytvořil Případ užití: Ontology creation Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. 2. 3. 4.
pu začíná volbou „vytvoř ontologii“ systém zobrazí formulář pro vytvoření ontologie uživatel doplní jednotlivá slova ontologie a potvrdí uložení hodnot ontologie je uložena do databáze
20
Případ užití: Ontology editation Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. 2. 3. 4.
pu začíná volbou „edituj ontologii“ uživatel doplní další slova ontologie a potvrdí uložení hodnot uživatel smaže některá slova z ontologie ontologie je uložena do databáze
Případ užití: Ontology deleting Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. pu začíná volbou „smaž ontologii“ 2. systém smaže danou ontologii i se všemi slovy z databáze Případ užití: Category creation Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. pu začíná volbou „vytvoř kategorii“ 2. systém zobrazí formulář pro vytvoření kategorie 3. uživatel uloží novou kategorii Případ užití: Category editation Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. pu začíná volbou „edituj kategorii“ 2. systém zobrazí formulář pro editování kategorie 3. uživatel uloží novou verzi kategorie Případ užití: Category deleting Preconditions: uživatel je přihlášen jako super uživatel nebo administrátor 1. pu začíná volbou „smaž kategorii“ 2. systém smaže danou kategorii Případ užití: User editation Preconditions: uživatel je přihlášen jako administrátor 1. pu začíná volbou „edituj uživatele“ 2. administrátor změní požadované hodnoty uživatele a potvrdí uložení nových hodnot 3. systém uloží nové hodnoty do databáze Případ užití: User deleting Preconditions: uživatel je přihlášen jako administrátor 1. pu začíná volbou „smaž uživatele“
21
2. uživateli je zaslán email, že byl jeho účet smazán 3. uživatel je smazán z databáze
4.3 Diagram tříd
Obrázek 4.2 Class diagram
4.4 Entitně-relační diagram
Obrázek 4.3 Entitně-relační diagram
22
4.4.1 Definice entit Název: Article Popis: Objektem typu (#Article) je každé zpracování jakéhokoliv textu obsahující: anotaci, text článku v podobě XML dat, autora a datum vytvoření článku. V tomto portále je vždy obsahem článku problematika věnovaná eGovernmentu. Jakýkoliv nesmyslný text nebo text obsahující jiné informace bude z databáze vymazán. Název: User Popis: Objektem typu (#User) je každý zaregistrovaný člověk, který využívá služeb informačního portálu a má určitá práva, které nepřihlášený uživatel nemůže mít. Každý zaregistrovaný uživatel má v databázi evidovány tyto atributy: jméno, login, email a heslo. Kde login musí být v rámci portálu unikátní. Název: Ontology Popis: Objektem typu (#Ontology) je každá vzájemně disjunktní skupina slov, které jsou významově podobné v oblasti eGovernmentu. Tyto slova si mohou být podobná i v základě slova. Tyto skupiny slov mohou být určeny pouze administrátorem. Dají se kdykoliv změnit nebo odstranit. Název: File Popis: Objektem typu (#File) je každý elektronický soubor (např. Textový soubor, Pdf soubor, obrázek), který je připojen k jakémukoliv článku na portálu. Jeden článek může obsahovat několik takových souborů. Název: Category Popis: Objektem typu (#Category) je každý název skupiny článků, který určuje právě umístění těchto článků. Každý článek může být právě v jedné kategorii. Kategorie mohou být vytvářeny nebo editovány administrátorem. Název: ContentVersion
23
Popis: Objektem typu (#ContentVersion) je každý obsah reprezentovatelný XML daty a je součástí článku nebo ontologie. Takový obsah může vytvořit jakýkoliv registrovaný uživatel a to tím, že vytvoří článek nebo edituje již vytvořený článek.
4.4.2 Definice vazeb
Název: Is in category Články (#Article)-s, které jsou v dané kategorii (#Category). / 0,N:0,M Název: Owns Uživatel (#User), který vlastní daný článek (#Article). / 1,1:0,M Název: Creates Uživatel (#User), který vytvořil danou verzi obsahu (#ContentVersion). / 1,1:0,N Název: Includes Článek (#Article), který obsahuje dané přílohy (#File)-s. / 1,1:1,M Název: Includes Článek (#Article), který obsahuje danou verzi obsahu (#ContentVersion). / 0,1:1,M Název: Includes Ontologie (#Ontology), která obsahuje danou verzi obsahu (#ContentVersion). / / 0,1:1,M Název: Is a subcategory of Kategorie (#Category)-s, které jsou podkategoriemi dané kategorie (#Category). / 0,N:1,1
24
5. Řešení aplikace Aplikaci jsem tvořila ve vývojovém prostředí NetBeans. Samotná aplikace se skládá ze dvou částí: BackEndu a FrontEndu. BackEnd zajišťuje provádění všech činností systému. Jsou zde naimplementovány všechny třídy a objekty. FrontEnd slouží jako rozhraní mezi uživatelem a BackEndem. FrontEnd je zodpovědný za vybírání vstupů a jejich zpracování do podoby, jak jsou naimplementovány v BackEndu. Je zde také naimplementován vzhled stránek pomocí xhtml souborů. V BackEndu se nachází zdrojový adresář, kde jsou veškeré implementace objektů systému. Základní objekty systému jsou: File, Article, Category, User, Ontology, ContentVersion. Zdrojový adresář je rozdělen do několika podadresářů, které obsahují samotné třídy. Ve zkratce tyto třídy představím. V adresáři domainmodel jsou základní třídy objektů, která nesou data. Základní třídou je třída Identifiable, kterou všechny ostatní třídy rozšiřují. Třída Identifiable nese unikátní identifikátory objektů. V adresáři dao jsou nadefinována rozhraní objektů, které pouze určují, jaké metody musí třídy implementující toto rozhraní mít. Třídy v adresáři dao.impl jsou třídy, které částečně implementují rozhraní dao. Je zde naimplementována abstraktní třída JackrabbitAbstractDAO. Tato třída implementuje pouze ty metody, které jsou pro všechny třídy stejné. Všechny ostatní třídy tuto abstraktní třídu rozšiřují o metody, které převádějí danou třídu objektu na uzel repositáře Jackrabbit a zpět. Třída persistance.Jackrabbit pak obsahuje metody pro přístup do repositáře, které jsou používány ve třídách v adresáři dao.impl. Používá JcrTemplate, který je nakonfigurovaný pomocí souboru ve WEB-INF adresáři. Třída mailservice obsahuje naimplementovány metody pro zasílání automatických emailů. Adresář webservices.impl obsahuje dva druhy tříd: třídy, které zajišťují transakční přístup k datům a rozhraní, které popisují metody těchto tříd.
25
Adresář webservices.holders obsahuje třídu Holder, která je používána k přenosu základních dat přes webové služby. Další třídy z tohoto adresáře tuto třídu rozšiřují o list objektů typu jednotlivých objektů domény. Třída Holder nese informace o chybách, jejich typech a příčinách. Adresář webservices obsahuje vlastní třídy webových služeb, které jsou volány z FrontEndu. Tyto třídy zajišťují naplnění Holderu daty a nastavení případných chybových zpráv. Obsahem některých tříd se budu dále zabývat v dalších podkapitolách. Ve FrontEndu se nacházejí zdrojové kódy samotných stránek. Tyto soubory jsou v adresáři webpages. Jsou zde také konfigurační soubory v adresáři WEB-INF. Obě dvě části obsahují testovací balíčky, adresáře s použitými knihovnami, adresáře s testovacími knihovnami a adresáře s konfiguračními soubory. V adresáři se zdrojovými balíčky FrontEndu je třída Controller, která obsahuje všechny metody pro práci se systémem. Všechny
zdrojové
kódy
jsou
zveřejněny
na
stránkách
http://www.fi.muni.cz/~xdvora20/eGovernment a jsou také na přiloženém CD.
5.1 Třídy a soubory BackEndu Třídy adresáře domainmodel Základní třída Identifiable je abstraktní třídou. Jsou zde implementovány pouze základní parametry a metody, které jsou pro všechny objekty stejné. Potom každá další třída obsahuje již svoje vlastní atributy a metody – především gettery a settery – pro jejich nastavení. Například, třída File obsahuje tyto atributy: private String fileName = ""; private byte[] data = new byte[0]; private String type = ""; private boolean visible = false; private long dateOfCreation = new Date().getTime(); private String description = ""; private String creatorId = ""; private String articleId = "";
26
Třídy adresáře dao.impl Abstraktní třída JackrabbitAbstractDAO částečně implementuje rozhraní DAO a to tak, že implementuje pouze metody stejné pro všechny třídy objektů. Mezi společné metody objektů patří tyto metody: find(String), findAll(), merge(T), persist(T), remove(String) a search(String). Příklad implementace jedné z metod:
@Transactional(readOnly = true) public T find(String id) { T obj = null; Node node = jackrabbit.getElement("//" + getElementPath() + "/" + getElementName() + "[id='" + id + "']"); if (node != null) { obj = nodeToObject(node); } return obj; }
Další třídy adresáře DAO.impl implementují následující čtyři metody, pro každou třídu objektu jsou tyto metody naimplementovány jednotlivě vzhledem k jejich atributům. Metody: nodeToObject(Node), setNodeProperties(Node,T), getElementPath(), getElementName(). Třída File.DAO obsahuje navíc metody inputStreamToData(inputstream) a extractText(inputstream). Třída mailservice Pro potřeby zasílání automatických emailů při smazání článku nebo uživatele byla vytvořena emailová schránka na portálu gmail.com s přihlašovacími údaji: email: "noreply.egovernment", heslo: "egomaildaemon". V třídě mailservice jsou pak implementovány metody pro zasílání těchto automatických emailů. public MailService() { email = new SimpleEmail();
27
email.setHostName("smtp.gmail.com"); email.setSmtpPort(587); email.setAuthenticator(new DefaultAuthenticator("
[email protected]", "egomaildaemon")); email.setTLS(true); } public void sendMail(String to, String subject, String message) { try { email.setFrom("
[email protected]"); email.addTo(to); email.setSubject(subject); email.setMsg(message); email.send(); } catch (EmailException ex) { Logger.getLogger(MailService.class.getName()).log(Level. SEVERE, null, ex); } }
Třídy adresáře webservices.impl V tomto adresáři jsou umístěny rozhraní a třídy. V rozhraních jsou popsány metody, které jsou pak implementovány v příslušných třídách. Tyto metody jsou určeny pro transakční přístup k datům. Pro ukázku jsou zde znázorněny metody ve třídě ArticleServiceImpl: Metoda createArticle @Transactional @Override public Article createArticle(Article article) { article = articleDAO.persist(article); return article; }
28
Metoda updateArticle @Transactional @Override public void updateArticle(Article article) { articleDAO.merge(article); }
Metoda deleteArticle @Transactional @Override public void deleteArticle(String articleId, String userId) { Article article = articleDAO.find(articleId); User creator = userDAO.find(article.getCreatorId()); User user = userDAO.find(userId); for (String contentVersionId : article.getContentVersionIdList()) { contentVersionDAO.remove(contentVersionId); } for (String fileId : article.getFileIdList()) { fileDAO.remove(fileId); } articleDAO.remove(articleId); MailService mailService = new MailService(); mailService.sendMail(creator.getEmail(), "Článek odstraněn", "Vas clanek " + article.getName() + " byl odstranen uzivatelem " + user.getName() + ". Anotace clanku: " + article.getAnnotation()); }
Metoda deleteArticle obsahuje část, kde je vytvořen a odeslán informační email autorovi článku, že jeho článek byl smazán.
29
@Override public List
getAllArticles() { return articleDAO.findAll(); }
Metoda getAllArticles vrací všechny články bez jakéhokoliv rozřazení do kategorií. Metoda getArticle @Override public Article getArticle(String id) { return articleDAO.find(id); }
Metoda searchArticle @Override public List searchArticles(String query) { return articleDAO.search(query); }
Metoda getArticlesInCategory – zobrazení článků v jednotlivých kategoriích @Override public List getArticlesInCategory(String categoryId) { List articles = articleDAO.findAll(); List selected = new ArrayList(); for (Article article : articles) { if (article.getCategoryId().equals(categoryId)) { selected.add(article); } } return selected; } }
30
Složitější metodou těchto tříd je metoda deleteUser v třídě UserServiceImpl, která když je uživatel smazán, tak ho smaže jako autora u jednotlivých článků nebo verzí článků a při odstranění účtu mu je zaslán automatický informační email, že byl jeho účet smazán. @Transactional @Override public void deleteUser(String userId, String adminId) { User user = userDAO.find(userId); User admin = userDAO.find(adminId); List articles = articleDAO.findAll(); for (Article article : articles) { if (article.getCreatorId().equals(userId)) { article.setCreatorId(""); articleDAO.merge(article); } } List files = fileDAO.findAll(); for (File file : files) { if (file.getCreatorId().equals(userId)) { file.setCreatorId(""); fileDAO.merge(file); } } List contentVersions = contentVersionDAO.findAll(); for (ContentVersion contentVersion : contentVersions) { if (contentVersion.getCreatorId().equals(userId)) { contentVersion.setCreatorId(""); contentVersionDAO.merge(contentVersion); }
31
} userDAO.remove(userId); MailService mailService = new MailService(); mailService.sendMail(user.getEmail(), "Ucet odstranen", "Vas ucet " + user.getLogin() + " byl odstranen administratorem " + admin.getName()); }
Třída Holder v adresáři webservices.Holders obsahuje tyto základní metody s informacemi o chybách:
public boolean isFailed() { return failed; } public void setFailed(boolean failed) { this.failed = failed; } public ErrorType getErrorType() { return errorType; } public void setErrorType(ErrorType errorType) { this.errorType = errorType; } public String getExceptionMessage() { return exceptionMessage; } public void setExceptionMessage(String exceptionMessage) { this.exceptionMessage = exceptionMessage; } }
32
Třídy v adresáři webservices Třídy v tomto adresáři slouží k naplnění Holderu jednotlivých typů objektů daty a nastavení chybových zpráv. Pro ukázku je zde popsána třída FileService, metody v ostatních třídách jsou na stejném principu, vždy pro každý objekt domény. public class FileService extends SpringBeanAutowiringSupport { @Autowired private IFileService fileService;
Metoda, která naplňuje holder při nahrávání souboru do systému a nastavuje chybové zprávy, které se zobrazují při jednotlivých konkrétních chybách. @WebMethod public FileHolder createFile(File file) { FileHolder holder = new FileHolder(); try { holder.setFile(fileService.createFile(file)); } catch (DataIntegrityViolationException ex) { holder.setFailed(true); holder.setErrorType(ErrorType.NO_ID_AVAILABLE_ERROR); holder.setExceptionMessage(ex.getMessage()); } catch (Exception ex) { holder.setFailed(true); holder.setErrorType(ErrorType.GENERAL_ERROR); holder.setExceptionMessage(ex.getMessage()); } return holder; }
Metoda naplňující holder při updatování souboru a nastavuje chybové hlášky k jednotlivým chybám.
33
@WebMethod public Holder updateFile(File file) { Holder holder = new Holder(); try { fileService.updateFile(file); } catch(DataRetrievalFailureException ex) { holder.setFailed(true); holder.setErrorType(ErrorType.NOT_FOUND_ERROR); holder.setExceptionMessage(ex.getMessage()); } catch (Exception ex) { holder.setFailed(true); holder.setErrorType(ErrorType.GENERAL_ERROR); holder.setExceptionMessage(ex.getMessage()); } return holder; }
5.2 Třídy a soubory FrontEndu Ve FrontEndu v adresáři WEB-INF jsou xml soubory, které nastavují propojení BackEndu a FrontEndu. XML soubor applicationContext obsahuje informace, které slouží k nastavení přístupu do BackEndu. <property name="wsdlDocumentUrl" value="http://kore.fi.muni.cz:14180/BackEnd/CategoryService?wsdl"/> <property name="namespaceUri" value="http://webservices/"/> <property name="serviceName" value="CategoryService"/> <property name="serviceInterface" value="webservices.CategoryService"/> <property name="portName" value="CategoryServicePort"/>
34
XML soubor face-config obsahuje informace, jak se má systém zachovat při přechodech mezi jednotlivými komponentami systému. Vlastně jakou stránku má zobrazit, když uživatel přechází z jednoho formuláře na druhý. Musí zde být ošetřeny i neočekávané vstupy uživatele, aby nedocházelo ke zbytečným chybám systému. Například tato ukázka slouží k navigaci ze stránky article.xhtml na ostatní formuláře a stránky. /article.xhtml register /registerform.xhtml article /article.xhtml admin /admin.xhtml list /articlelist.xhtml mainpage /mainpage.xhtml
35
search /searchList.xhtml
Základní rozvržení stránky je nastaveno v souboru template.xhtml. Je zde určeno, kde jsou jaká tlačítka, textová pole a jiné. Ostatní xhtml soubory v adresáři WEB-INF určují, co se bude uživateli zobrazovat na jednotlivých formulářích, například soubory mainpage, articlelist, registerform. Všechny funkční hodnoty jsou nastaveny pomocí funkcí v controlleru. Některé části budou pro ukázku popsány níže. Například rozvržení tlačítek a textových polí v levém horním rohu, když není uživatel přihlášen.
Soubor articlelist.xhtml, který nastavuje zobrazení článků v kategoriích nebo bez rozlišení kategorií, tlačítka vytvořit článek. ${controller.category.name}
36
37
Z funkcí ze souboru controller jsou nejzajímavější funkce pro hledání slov v článcích a zobrazení vyhledaných článků. Pro vyhledávání nelze použít množinu, ta přehazuje pořadí prvků, proto jsou použity seznamy identifikátorů. Funkce, která vrací ontologie, ve kterých našla slovo, které bylo uživatelem zadáno do pole hledat. private Set<String> getSearchSet() { Set<String> searchSet = new HashSet<String>(); searchSet.add(searchText); OntologyHolder ontologyHolder = ontologyService.searchOntologies(searchText); for (Ontology foundOntology : ontologyHolder.getOntologies()) { searchSet.addAll(foundOntology.getKeywordList()); } return searchSet; }
Funkce, která vrací seznam článků, kde byly daná slova nebo jen slovo nalezeno. public DataModel getFoundArticles() { List foundArticles = new ArrayList(); List<String> foundArticlesId = new ArrayList<String>(); for (String searchSetItem : getSearchSet()) { ArticleHolder articleHolder = articleService.searchArticles(searchSetItem); for (Article foundArticle : articleHolder.getArticles()) { if (!foundArticlesId.contains(foundArticle.getId())) { foundArticles.add(foundArticle); foundArticlesId.add(foundArticle.getId()); }
38
} ContentVersionHolder contentVersionHolder = contentVersionService.searchContentVersions(searchSetItem); for (ContentVersion foundVersion : contentVersionHolder.getContentVersions()) { ArticleHolder holder = articleService.getArticle(foundVersion.getArticleId()); Article foundArticle = holder.getArticle(); if ((foundArticle != null) && (foundArticle.getCurrentContentVersionId().equals(foundVersion.getId())) && (!foundArticlesId.contains(foundArticle.getId()))) { foundArticles.add(foundArticle); foundArticlesId.add(foundArticle.getId()); } } } articleDataModel.setWrappedData(foundArticles); return articleDataModel; }
Podobné je i zobrazení nalezených článků, kde bylo slovo nalezeno v přiložených souborech. public DataModel getFoundArticlesInFiles() { List foundArticles = new ArrayList(); List<String> foundArticlesId = new ArrayList<String>(); for (String searchSetItem : getSearchSet()) { FileHolder fileHolder = fileService.searchFiles(searchSetItem); for (File foundFile : fileHolder.getFiles()) { ArticleHolder holder = articleService.getArticle(foundFile.getArticleId()); Article foundArticle = holder.getArticle(); if ((foundArticle != null) && (!foundArticlesId.contains(foundArticle.getId()))) { foundArticles.add(foundArticle); foundArticlesId.add(foundArticle.getId());
39
} } } articleDataModel.setWrappedData(foundArticles); return articleDataModel; }
Nastavení uploadování souboru jako přílohy článku. public String uploadFile() { try { file.setType(uploadedFile.getContentType()); file.setArticleId(article.getId()); file.setCreatorId(user.getId()); file.setDateOfCreation(new Date().getTime()); file.setData(uploadedFile.getBytes()); FileHolder holder = fileService.createFile(file); if (holder.isFailed()) { System.err.println("uploadFile error = " + holder.getErrorType().toString() + " " + holder.getExceptionMessage()); message = holder.getExceptionMessage(); } file = new File(); ArticleHolder articleHolder = articleService.getArticle(article.getId()); if (articleHolder.isFailed()) { System.err.println("articleLoad error = " + articleHolder.getErrorType().toString() + " " + articleHolder.getExceptionMessage()); message = articleHolder.getExceptionMessage(); } article = articleHolder.getArticle();
40
} catch (IOException ex) { Logger.getLogger(Controller.class.getName()).log(Level.SEVERE, null, ex); message = "Zadaný soubor nelze načíst"; } return "article"; }
41
6. Informační portál – vzhled stránek a práce s portálem Informační portál je přístupný na stránkách http://kore.fi.muni.cz:14180/FrontEnd. Pro přístup na stránky bylo vytvořeno několik účtů, ale samozřejmě mohou být vytvořeny i účty nové: administrátor o login: admin o heslo: heslo super uživatel o login: super o heslo: heslo uživatel o login: uzivatel1 o heslo: heslo1 Po vstupu na stránky je zobrazena úvodní stránka, která je rozvržena do několika oblastí. Oblast nahoře vlevo slouží k vyhledávání výrazů. Výraz může vyhledávat jak přihlášený, tak i nepřihlášený uživatel. Vpravo nahoře jsou pole pro přihlášení a tlačítko pro registraci nového uživatele. Levá část stránky slouží k zobrazení všech kategorií, kde jsou uloženy články. Samotný střed stránky je pak určen pro aktuální výběr formuláře.
Obrázek 6.1 Úvodní stránka
Po přihlášení se vzhled a funkcionality různí podle úrovně přístupu jakou daný uživatel má. Administrátor a super uživatel mají přístupný formulář administrace, kde jsou vytvářeny, editovány a mazány kategorie a ontologie. Oba dva typy uživatelů mohou také mazat jakékoliv
42
články, bez ohledu na to, zda je vytvořili či nikoliv. Administrátor má navíc formulář pro editování a mazání uživatelů. Zde může jakémukoliv uživateli nastavit práva super uživatele nebo mu je odebrat, měnit emailovou adresu a jméno uživatele. Login je pevně daný již od registrace.
Obrázek 6.2 Editace uživatelů
Formulář pro editaci ontologií je velmi jednoduchý. Stačí v seznamu ontologií kliknout na tlačítko editovat u příslušné ontologie. Ontologie jsou brány jako skupiny slov, kde název ontologie je již jedním ze slov dané skupiny. Dále se dají další slova do skupin přidávat nebo odebírat. Jakákoliv ontologie může být i smazána najednou, pomocí tlačítka smazat ontologii u příslušného řádku. Jak je již napsáno výše, na tento formulář má přístup pouze administrátor a super uživatel, tudíž by se nemělo stát, že skupiny budou obsahovat nesmyslná slova, nebo že budou bezdůvodně smazána.
Obrázek 6.3 Editace ontologií
43
Psaní a publikování článku je povoleno pouze přihlášeným uživatelům. A to hned z několika důvodů. Aby nedocházelo k publikacím nesmyslných článků. Ne každý uživatel se bude chtít zaregistrovat jen proto, aby mohl na stránkách spamovat. A také, aby se dal autor článku dohledat. Článek může být vytvořen v rámci nějaké kategorie. Formulář pro publikaci článku je opět velmi jednoduchý. Je rozdělen do dvou částí. Hlavní část je věnována publikaci samotného článku, jeho názvu a anotace. Další, nepovinnou součástí publikace článku, je publikování jakéhokoliv souboru a to tak, že uživatel může nastavit, zda bude soubor viditelný pro ostatní uživatele či ne.
Obrázek 6.4 Vytvoření článku
Záložka Historie u článku je přístupná všem přihlášeným uživatelům. Pouze administrátor a super uživatel mohou jednotlivé verze článků mazat, jak chtějí. Ostatní uživatelé mohou mazat pouze své verze článků. A pokud je u článku již jen jedna poslední verze, tak tu může smazat pouze administrátor nebo super uživatel. A to ne přes smazání historií článků, ale přes úpravu článku. V systému je to nastaveno tak, že pokud je již poslední verze článku, tak ta se nedá smazat pomocí smazat verzi, aby nedocházelo k nedopatřením smazání důležitých článků.
44
Obrázek 6.5 Historie článků
Vyhledávání je zpřístupněno jak přihlášeným, tak i nepřihlášeným uživatelům. Jediným rozdílem je, že pokud vyhledává slovo přihlášený uživatel, slovo je vyhledáváno i ve starších verzích článků. Pro nepřihlášeného uživatele se slovo vyhledává pouze v aktuální verzi článku, tedy ve verzi, kterou jako nepřihlášený uživatel vidí. Pokud jsou v systému vytvořeny nějaké ontologie, slovo je nejdříve vyhledáno v nich a poté je vyhledáno jak v článcích, tak i v souborech, a to v souborech typu pdf.
Obrázek 6.6 Vyhledávání – nepřihlášený uživatel
45
7. Závěr Cílem této práce bylo zrealizovat myšlenku vytvoření portálu podobného svým funkcionalitám stránkám typu www.wikipedia.org. Systém je plně schopen základní funkcionality zvládnout. Je navržen tak, aby se daly případně doimplementovat další funkcionality. Jeho využití nemusí být limitováno pouze oblastí elektronizace veřejné správy. Je schopný fungovat v jakékoliv jiné oblasti. Na úvod je čtenář uveden do problematiky elektronizace veřejné správy a je obeznámen se základními definicemi a strategiemi tohoto rozvoje. V další části je čtenář seznámen s použitými technologiemi při vytváření portálu a také s historií jejich vzniku a základními vlastnostmi. Další, již praktická část, uvede čtenáře k přípravě portálu, pomocí analytických diagramů a jejich popisu. Další část je věnována konkrétním částem zdrojového kódu s jejich vysvětlením. Poté jsou uvedeny ukázky z praktického fungování systému. Myslím, že by se dalo mnohé ještě přidělat či udělat trochu jinak. Určitě by se dalo vytknout, že systém ukládá data do svého repositáře, nikoliv do databáze. Ochrana dat by se dala vylepšit. Avšak pro potřeby práce je portál plně funkční.
46
8. Použitá literatura 1. Řepa, Václav. Analýza a návrh informačních systémů. Praha: Vyd. 1, 1999. ISBN 8086119130 2. An Overview of eGovernment and eInclusion situation in Europe – Czech Factsheet [Online] 2010 http://www.epractice.eu/en/factsheets/ 3. eGON jako symbol eGovernmentu – moderního, přátelského a efektivního úřadu [Online] 2010 http://www.mvcr.cz/clanek/egon-jako-symbol-egovernmentu-moderniho-pratelskeho-aefektivniho-uradu-252052.aspx 4. Horton, Ivor. Java 5.0. Praha: 2005. ISBN 8086330125 5. Czech POINT – kontaktní místa veřejné správy [Online] 2010 http://www.mvcr.cz/clanek/egon-symbol-egovernmentu-czech-point-kontaktni-mista-verejnespravy.aspx 6. Komunikační infrastruktura veřejné správy [Online] 2010 http://www.mvcr.cz/clanek/egonsymbol-egovernmentu-komunikacni-infrastruktura-verejne-spravy.aspx 7. Základní registry veřejné správy [Online] 2010 http://www.mvcr.cz/clanek/zakladniregistry-verejne-spravy.aspx 8. O datových schránkách [Online] 2010 http://www.datoveschranky.info/o-datovychschrankach-text/ 9. eXtensible Markup Language [Online] 2010 http://en.wikipedia.org/wiki/Xml 10. eXtensible HyperText Markup Language [Online] 2010 http://en.wikipedia.org/wiki/Xhtml 11. Java (programming language) [Online] 2010 http://en.wikipedia.org/wiki/Java_language 12. Lidinský, Vít. eGovernment bezpečně. Praha: Vyd. 1, 2008. ISBN 9788024724621
47
