Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Modelování e-Government procesů v UML Bakalářská práce
Autor:
OndřejKlásek Informační technologie, SIS
Vedoucí Práce:
Praha
Doc. Ing. Bohumil Miniberger, CSc.
Duben2011
Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne:
Ondřej Klásek
Poděkování: Rád bych ze srdce poděkoval především svým rodičům a to za nekonečnou podporu po všech stránkách, které můţe student a syn během studia, ale i ţivota, potřebovat. Dále bych rád poděkoval panu Doc.Ing. BohumiluMinibergerovi, CSc. a to zejména za jeho profesionální podporu a velmi vstřícný a ochotný přistup, díky kterým jsem neztratil odhodlání.
Anotace (Annotation) Práce zaměřená na UML a jeho vyuţití v E-governmentu. Cílem mé práce bylo zjistit, zda lze vyuţít přednosti tohoto modelovacího jazyka pro zjednodušení a lepší interpretaci této problematiky posledních let. Obsahem práce je pak dále základní charakteristika modelování, modelovacího jazyka UML, E-governmentu a dva základní diagramy jedné z běţných sluţeb CzechPOINT. Annotation The work focused on UML and its use in e-government. The aim of my work was to determine whether you can use the advantages of this modeling language to simplify and better interpretation of this issue in recent years. The thesis is then the basic characteristics of modeling, UML, E-government primary and two diagrams one of ordinary CzechPOINT services.
Klíčová slova: UML, e-government, modelování
Úvod Jiţ od prvopočátku zavádění e-governmentuse toto úsilí potýkala s řadou větších či menších problémů. Jako syn starosty jedné z těchto obcí jsem je vţdy vnímal, ať uţ jako občan, syn nebo jako zaměstnanec Obecního úřadu. Napadlo mě tedy, zda není nějaký způsob, jak zjednodušit a zlepšit vztahy mezi elektronickými sluţbami, které se v posledních letech čím dál tím více stávají nedílnou součástí běţného ţivota všech občanů, a právě občany, pro které jsou primárně určené. A stejně tak zda by mohlo UML ulehčit nějakým způsobem nelehkou práci, chtělo by se říci aţ „černou“ práci, která tak byla uloţena na bedra Obecních a Městských úřadů. Proto také je cílem mé práce: Nastínit procesy probíhající v eGovernmentu v ČR a moţnosti vyuţití UML v něm. V první kapitole jsem nastínil přínosy, klady modelování procesů jako takového. K tomuto jsem přistoupil zejména proto, ţe UML je jazykem, který byl stvořen právě pro tento účel a je nástrojem pro modelování. Proto jsem také jiţ do první kapitoly zařadil jeden ze dvou příkladů vyuţití, které chci ve své práci demonstrovat. Tímto prvním příkladem je namodelování jednoduché webová aplikace slouţící široké veřejnosti, která vznikla na základě poţadavků fiktivního klienta. Samotnému UML, jeho přínosům, základním částem a prvkům se věnuji v kapitole druhé. Zde se zmiňuji o historii a vývoji UML jako nástroje, který při správném pouţití, na správných místech můţe být skutečně mocným pomocníkem. Třetí kapitola je pak celá věnována e-Governmentu v ČR. Zmiňuji několik slov o tom, proč se začal zavádět, něco málo z historie a následuje výčet směrů, kterými se vydal od dob, kdy byly jednotlivé jeho části poprvé rozběhnuty. Tedy přes Komunikační infrastrukturu, Datové schránky, CzechPOINT aţ k Základním registrům. Čtvrtou kapitolu jsem pak pojal jakodemonstraci přímočarosti jednoho z řady produktů, které poskytuje právě CzechPOINT – Výpisu z katastru nemovitostí. Tuto skutečnost se snaţím demonstrovat pomocí UML a dvou základních diagramů – UseCase diagram a Activity diagram – které dokáţí poměrně výstiţně zachytit celý proces a dávají mi moţnost snadno vyhodnotit, zda byl navrţen tak, aby pomáhal a slouţil nebo je to jen rychlokvaška, které by měla být od základu přepracována.
5
Obsah Prohlášení: ...................................................................................................................................... 2 Poděkování: .................................................................................................................................... 3 Anotace (Annotation) ..................................................................................................................... 4 Úvod .................................................................................................................................................... 5 Obsah .............................................................................................................................................. 6 1. Obecný popis modelování procesů ............................................................................................ 7 1.1. Proces................................................................................................................................ 7 1.2. ARIS ................................................................................................................................ 11 1.2.1. Některé přínosy ARISu .............................................................................................. 12 1.2.2. RUP ............................................................................................................................ 14 1.2.3. Typy modelování........................................................................................................ 17 1.3. Příklad č. 1 ...................................................................................................................... 18 1.3.1. Diagram uţití (Use case diagram).............................................................................. 19 1.3.1.1. Základní scénář ................................................................................................. 20 1.3.2. Diagram tříd (Class diagram) ..................................................................................... 21 1.3.3. Uţivatelské rozhraní (interface) ................................................................................. 23 2. Stručný popis jazyka UML. ..................................................................................................... 24 2.1.1. Definice UML (Unified Modeling Language) ........................................................... 24 2.2. Notace UML – diagramy: ............................................................................................... 27 2.2.1. Typy UML diagramů: ............................................................................................... 27 2.2.2. Diagram tříd a objektů: .............................................................................................. 28 2.2.3. Diagram jednání ......................................................................................................... 29 2.2.4. Diagram spolupráce ................................................................................................... 31 2.2.5. Stavový diagram ........................................................................................................ 32 2.2.6. Diagram aktivit .......................................................................................................... 33 2.2.7. Diagram komponent................................................................................................... 36 2.2.8. Diagram nasazení ....................................................................................................... 37 3. E-government v ČR.................................................................................................................. 38 3.1. Charakteristika e- governmentu:..................................................................................... 38 3.2. eGON .............................................................................................................................. 39 3.3. Popis jednotlivých částí: ............................................................................................ 40 3.3.1. Základní registry veřejné správy ................................................................................ 40 3.3.2. KIVS – Komunikační infrastruktura veřejné správy.................................................. 40 3.3.3. Datové schránky a zákon o e-governmentu ............................................................... 41 3.3.3.1. Datové schránky ............................................................................................... 41 3.3.4. Czech POINT (Český Podací Ověřovací a Informační Národní Terminál.) ............. 43 3.3.4.1. Czech POINT. ................................................................................................... 44 3.3.4.2. Ve všech jeho pobočkách si lze zařídit: ............................................................ 45 4. Příklad vyuţití UML v e-governmentu .................................................................................... 46 4.1. Activity diagram: ............................................................................................................ 46 4.2. UseCase diagram, ........................................................................................................... 47 Závěr .................................................................................................................................................. 48 Seznam pouţitých obrázků: .......................................................................................................... 49 Zdroje informací ........................................................................................................................... 50 Přílohy: .............................................................................................................................................. 51 Seznam příloh .................................................................................................................................... 56
6
1. Obecný popis modelování procesů 1.1.
Proces
část organizovaného celku, která přijímá vstupy a transformuje je do uţitných výstupů, stejně tak lze říci, ţe proces je sled činností, který je vykonáván za účelem přidání hodnoty.
Obrázek 1 – Přejato od M. Miniberger, Informační Systémy ve zdravotnictví -2. [on/line][cit. 2011/02/04]Dostupné z: https://is.bivs.cz/auth/el/6110/leto2011/B108ISZ/Informacni_systemy_ve_zdravotnictvi2-cb2011.pdf?fakulta=6110;obdobi=57;kod=B108ISZ
Některé další pojmy související s Procesem: -
Iniciační proces – proces stojící na začátku, bez dalšího nadřazeného procesu.
-
Přezkoumání – činnost, jejímţ cílem je stanovit efektivnost procesu. Mělo by vést k eliminaci chyb v procesu a tím jejich zlepšování
-
Kontrola – činnost prováděná v určitých intervalech. Tato má za úkol ověřit, zda proces funguje dle přiloţené dokumentace a případně zda má proces pokračovat nebo být ukončen.
7
Modelování procesů je důleţité z mnoha důvodů. Umoţňuje lepší pochopení stávajícího stavu, přínos změn a celkový přínos daného procesu nebo funkce. Ne nadarmo se říká „Jeden obrázek dokáţe říci více, neţ tísic slov“ a právě tohoto faktu modelování vyuţívá. Jak Datové schrány, tak CzechPOINT (viz kapitola E-government v ČR) se od počátku potýkaly se skepsí a nedůvěrou především ze strany úřadů, úředníků, kterých se změny týkaly. Stejně tak ale na celou problematiku pohlíţela veřejnost, které z těchto změn měla těţit především, ale navzdory poměrně mohutné kampani přetrvává jistý ostych. Do dnešního dne se situace příliš nezlepšila. K poskytování této sluţby se úřady staví poněkud pasivně, především pak tam, kde je míra vyuţití, poptávky nízká, zaměstnanci úřadu mají jen malé zkušenosti s prací v systému a tak je jejich přístup spíše odmítavý. V řadě případů stále raději posílají občany do náleţitých měst, přímo na úřady, do jejichţ kompetence vydávání těchto informací spadalo dříve, zařídit si vše „po staru“. Právě správně zpracovaný model dokáţe pohled na celou situaci osvětlit. Občanům/ţadatelům ukáţe celý proces v jasných bodech, krok za krokem, od počátku aţ k výsledku, výstupu. Zaměstnanci, kteří nejsou zcela zběhlí v práci s tímto systémem, by zase měli jasný a polopatický návod, jak se dostat co nejsnadněji ke splnění poţadavku. Hlavní přínos modelování procesů tedy spočívá v: -
snazším pochopení stávajícího stavu a funkcí
-
lepším pochopení, zdůvodnění, přínosu změn
-
odkrytí dalších moţností, směrů rozvoje. Jak směrem ke zlepšení IS, tak změn organizačních, strukturálních na daném úřadě
-
Osvětlení dokumentace, která se k dané problematice vztahuje, popřípadě její aktualizace
Samozřejmě je nezbytné, modelovat jen tam, kde to můţe skutečně přinést nějaký uţitek a nepouštět se do příliš detailních modelů, aby spíše nemátly. Stejně tak je důleţité stále se soustředit na funkci daného procesu a nespojovat do jednoho modelu více funkcí. To by totiţ mohlo mít za následek naprosté znehodnocení.
8
1
V tomto směru je zajímavá práce Václava Řepy , ve které se, mimo jiné, věnuje modelování činností úřadu veřejné správy, přesněji samosprávy. Tento model vznikal díky spolupráci dvou městských úřadů, které dodaly data k analýze a také studentů Vysoké školy ekonomické v Praze. Cílem této spolupráce bylo vytvoření obecného, typového modelu fungování úřadu samosprávy. Uţitečnost tohoto přístupu lze snadno rozpoznat v příkladech, které mě v jiţ zmiňované práci zaujaly, zde nabídnu. Ty jsou vztaţeny k činnosti Stavebního úřadu, přesněji k jeho procesní oblasti, ta obsahuje procesy týkající se staveb, výstavby obecně, nebo plánování územního rozvoje. Stavební úřad je samozřejmě provázán v souladu i s dalšími procesními oblastmi, jako ţivotní prostředí nebo sociální oblast, které však pro přehlednost mnou popisovaných modelů, nebudu uvádět.
Jako první bych rád ukázal Model tříd
procesní oblasti stavebního úřadu, následně pak diagram stavů ţivotní cyklus „Stavby“ jako takové, jak je veden v análech stavebního úřadu. Následně pak ţivotní cyklus třídy objektů „Stavba“. I při modelováních takto komplexních diagramů musejí být samozřejmě zachována jistá, společná pravidla pro modelování, aby byl model zachycen přesně a výstiţně. Některá z nich jsem dále uvedl v části věnované UML, protoţe se shodují. Rád bych již zdezdůraznil tato pravidla: -
Pro kaţdou třídu, která je zachycena v diagramu tříd, by měl existovat stavový diagram, popisující jejich stavy a přechody mezi nimi. Výjimku lze udělat s takzvanými „primitivními třídami“, jeţ jsou natolik triviální, ţe jejich popis nemá smysl.
-
Ke kaţdému přechodu mezi dvěma stavy objektu odpovídá definovaná akce třídy
-
Kaţdá definovaná akce třídy musí být pouţita k uskutečnění přechodu mezi stavy této třídy. Nedílnou součástí kaţdé třídy jsou akce typu 'konstruktor'-to je akce, kterou samotný objekt vzniká – přechod do prvního stavu. A 'destruktor' – akce, kterou existenci daného objektu končí – přechod z posledního stavu. Tyto dvě akce jsou součástí kaţdé třídy objektů, i těch „primitivních“.
-
Všechny události, jeţ jsou společné více třídám objektů, musejí mít stanovený vztah mezi těmito objekty. Například událost „ţádost o stavební povolení“ je událostí společnou objektům „Občan“ - je jeho akcí a „Stavební povolení“ - u
1
Ing. Václav Řepa, CSc - Procesní řízení a modelování, 2., aktualizovanaé a rozšířené vydání
9
něhoţ vyvolá akci „Přijetí ţádosti o stavební povolení“, která je jeho konstruktorem. Toto musí fungovat i naopak, tedy, kaţdý vztah mezi třídami musí reflektovat příslušnou událost, společnou všem objektům, jichţ se týká. Podrobnější pohled do problematiky UML popisuji v další kapitole této práce. Příloha číslo 1 zachycuje nejpodstatnější části procesní oblasti stavebního úřadu. Skutečnosti zachycené v něm jsou platné pro všechny případy. Názvy daných oblastí jsou základními pojmy v této oblasti jako takové. Model zabývající se tímto se proto nazývá Konceptuální. Třídy: Stavba – ta je generickým, rodovým pojmem pro dvě moţnosti Stavba dočasná a Stavba trvalá. Subjekt – do této pak spadají Firma a Občan Územní řízení Stavební povolení Kolaudace Žádost o stavební povolení Záměrně jsem zde vypsal všechny třídy pouţité v daném module, abych zdůraznil, ţe pro všechny tyto je nezbytné vytvořit i náleţící stavové diagramy. Já zde pro demonstraci předvedu pouze jeden a to stavový diagram popisující ţivotní cyklus třídy „Stavba“ a „Stavební povolení“ (viz příloha 2 a 3). Jak je z těchto dvou diagramů patrné, slovní vysvětlení procesů probíhajících v rámci Stavebního úřadu by bylo dlouhé a poměrně sloţité. Naopak toto grafické vyjádření vše podstatně zjednodušuje. A myslím si, ţe právě tyto dva příklady, s problematikou, se kterou se všichni běţně setkáváme v průběhu celého ţivota, ukazují přínosy Modelování, jak jsem je vypsal dříve.
10
1.2.
ARIS
V této kapitole bych se také rád zmínil a programu ARIS, ten totiţ byl jedním z prvních velmi úspěšných nástrojů, slouţících pro modelováníi doplnit odkaz na zdroj Scheer,A-V.: Od podnikových procesů k aplikačním systémům. IDS- Scheer ČR, Brno 2002, (ISBN 80-238-4719-8. ARIS je velice komplexní nástroj a zde bych rád jen nastínil některé jeho funkce a přínosy. Zmiňuji ho zde také proto, ţe jeho sluţeb se vyuţívá i pro modelování UML diagramů o kterých se více dozvíme později. Modelovací grafický nástroj, umoţňuje popsat skutečnost pomocí přehledných schémat (modelů). Jeho vyuţití bylo míněno především pro podporu větších a velkých organizací. Dává totiţ k dispozici celou řadu modelů, určených pro různé oblasti lidské činnosti. ARIS lze pro představu pouţít k modelování -
popisu organizační a řídící struktury
-
mapy znalostí – kvalifikační předpoklady
-
seznamu nezávislých/závislých procesů
-
podrobný popis procesu
Databáze – kaţdý jednotlivý prvek vytvořených schémat je uloţen jako databázový objekt. To následně umoţňuje propojovat jednotlivá nezávisle vytvořená schémata jako schéma Organizační struktury organizace se schématem Prováděných činností a tak vytvořit vazbu mezi funkčním místem a náplní práce, kterou má vykonávat. Funkční místo lze propojit například i s modelem kvalifikačních předpokladů. Následně lze provádět různé dotazy do databáze a tak získávat nové pohledy na jiţ jednou popsanou skutečnost. Metrika – metodika - Pro pouţití existuje metodika, která zajišťuje jednotný popis kaţdého modelované části reality.
11
1.2.1. Některé přínosy ARISu -
Objekty modelu lze provázat i s jinými informačními systémy. Ke příkladu mohou
odkazovat na internetové zdroje. Touto cestou lze poměrně snadno propojit popis procesu s normou, která upravuje výkon jeho činností a uţivatel si můţe obsah normy zobrazit přímo v prostředí ARISu. -
Pokud máme popsaný proces a ten má slouţit jako vzorový, není problém jej vyuţít
pro vytvoření normy. Proces funguje i obráceně, tedy jiţ existující normu lze převést do popisu procesu a tím vytvořit podklad pro její optimalizaci. -
Vizualizací (namodelováním) se nabízí přehledný podklad pro zlepšování popisované
skutečnosti (organizační struktura, norma, proces,…). V modelech se zviditelní nelogičnosti, které často zůstanou ve slovním popisu skryty. -
Modely mohou poslouţit jako návod pro výkon činnosti.
-
Díky uloţení objektů v databázi a moţnosti definování vazeb lze získat nové podklady
pro řízení jak v grafické podobě tak i textové.
Modelování procesů se také hojně vyuţívá například při vývoji softwaru. Díky moţnosti shlédnout celý projekt dříve, neţ bude skutečně realizován je velmi silnou zbraní a má tedy samozřejmě i svá pravidla. V poslední části této kapitoly bych rád věnoval několik slov právě obecnému vyuţití modelovacích nástrojů při vývoji softwaru a malému příkladu vyuţití při tvorbě jednoduchých webových stránek. Zde je několik rad, které vycházejí z dlouhodobých zkušeností a pravidel lidí (uvést zdroj), kteří se touto problematikou zabývají a právě tyto rady vyzývají k pouţití modelovacích nástrojů z několika důvodů: -
jednoduché sdílení informací a prezentace myšlenek
-
zjednodušení popisu vytvářeného produktu
-
snazší komunikace
-
snazší nalezení chyb
-
simulace projektu (ţivotního cyklu, jednotlivých částí
12
Všechny tyto aspekty mají velký vliv na to, zda bude projekt realizován. Ať uţ co se týče vztahu finanční část – vývojový tým, tak i uvnitř vývojového týmu. Vţdyť není nic horšího, neţ špatně, nepochopitelně prezentovaný projekt, nebo špatné porozumění, pochopení problematiky uvnitř týmu. Model je samozřejmě moţné doplnit o různé komentáře, ale i bez nich by mělo být na první pohled jasné, o co jde a co je cílem. To vše samozřejmě platí i ve vztahu vývojový tým – vedení. I zde je potřeba řádně prezentovat progres a dodrţení vytýčeného směru. A v neposlední řadě toto pomáhá při předávání práce jiným kolegům, vţdyť není nic horšího, neţ přebírat povinnosti za kolegu, který onemocněl, pokud má naprosto jiný pracovní styl. Takové problémy při správně zvládnutém modelování, ale samozřejmě i pečlivě zpracované dokumentaci, odpadají. Další přínosy: -
řada pokročilých CASE nástrojů dokáţe přímo z diagramů potřebný kód vygenerovat, coţ je velmi uţitečné například u datových modelů, kde je tak moţné přímo generovat skripty pro vytvoření databázových tabulek. Generovaný kód totiţ často v takových případech není ani tolik o tvůrčí činnosti, jako o mechanickém opisování.
-
Jednotlivé modely lze poměrně snadno sestavit do jednoho komplexního celku a vidět tak celou vizi „pohromadě“
13
1.2.2. RUP Jednou z metodik vývoje softwaru, která pracuje s vizualizací je RationalUnifiedProcess (RUP). Ten má několik základních fází: Počátek (inception) – zahájení projektu, zde se projektant seznámí s problematikou, kterou je třeba zachytit a stanoví se první, elementární poţadavky. Elaborace (elaboration) – v této fázi vzniká dokumentace a právě zde se nejvíce vyuţije modelování. Konstrukce (construction) – tato fáze je fází implementace
Nasazení (transition) – uvedení softwaru do provozu
OBRÁZEK 2– POŘÍZEN Z WEBOVÝCH STRÁNEK SPOLEČNOSTI IBM, STEJNĚ JAKO NĚKTERÉ INFORMACE - HTTP://WWW.IBM.COM/DEVELOPERWORKS/WEBSERVICES/LIBRARY/WS-SOATERM2/
14
Tento graf, schéma vyuţití jednotlivých prvků v těchto čtyřech fázích jasně ukazuje, ţe modelování (design) je přítomno ve všech fázích vývoje, pouze s tím rozdílem, ţe kaţdá fáze vyţaduje jiný přístup – jiné formy modelování (různé modely a diagramy). To ostatně ukazuje zjednodušený model vyuţití diagramů, modelů (viz obrázek 2). Zde je samozřejmě vypsáno jen několik typů diagramů pro zachování přehlednosti. V tomto obrázku je vyobrazeno fází pět, kdy fáze dvě a tři jsou rozpracovanou fází číslo dvě z předchozího obrázku. V první části „Business modeling“ je zde vyznačen Business use case diagram – jedna se o klasický Use case diagram, tento se ale tvoří zejména k lepšímu pochopení ze strany zákazníka. Tento diagram je orientován na chod byznysu a ne všechny jeho části se pouţijí v implementační fázi.
15
Dále je pak vyobrazen Usecase model. Těch často vzniká celá řada – pro kaţdý samostatný modelu programu, této problematice rozdělování na jednotlivé části se také věnuje jiţ zmiňovaný RUP. Dále je use casediagramdoplněn o slovní popis, schémata uţivatelského prostředí. V této fázi také vzniká první Class diagram v němţ se definují alespoň základní poţadované atributy a metody. Finální ladění pak opět probíhá v implementační fázi. Toto vše je samozřejmě jen velmi obecné a kaţdý jednotlivý projekt je nutno brát jako unikátní a tak k němu i přistupovat.
OBRÁZEK 3– ZÍSKÁN SKRZE WEB – DOSTUPNÉ Zhttp://panrepa.org/CASE/CASE_v_SWhousu.pdf
Poslední fáze, fáze Testování, se pak jiţ bez řádné dokumentace neobejde. Zde se vyuţije vše, co během celého procesu vznikalo a pomocí toho se celý proces krok za krokem testuje.
16
1.2.3. Typy modelování
Konceptuální/formální modelování Oba přístupy se značně liší, proto je určitě vhodné zde zmínit jejich základní rozdíly, klady a případně zápory.
Konceptuální modelování: Zde je snaha zachytit danou problematiku co nejvýstiţněji a nejjednodušeji, tak, bez uţití nějakého předem stanoveného formátování, stanovených pravidel (daného metamodelu). Je samozřejmě
vhodné
všemu
srozumitelnosti.Výsledkem
dát
jednotnou
konceptuálního
formu,
modelování
aby je
bylo
dodrţeno
implementačně
pravidlo nezávislé
databázové schéma, tj. schéma obecně pouţitelné kdekoli v technicko-programovém prostředí.
Formální modelování: v tomto se pouţívá nějaký unifikovaný, formalizovaný jazyk, jakým je například UML, ve kterém jsou všechna pravidla stanovena – přesně definované typy diagramů a prvků, které se mohou vyskytnout
Nyní bych rád uvedl první příklad, ze dvou, které budu prezentovat v rámci této práce. Tento první příklad byl součástí zkoušky z předmětu Vývoj informačních systémů. Jedná se o celkový návrh vývoje jednoduché webové aplikace. Kde po vyhodnocení zadání proběhlo 2
jednání s klientem , při tomto jednání jsme si vyjasnili bliţší podrobnosti, já zde navrhl postup, který bych zvolil, samozřejmě ho prezentoval tak, aby byl přijatelný a srozumitelný především z pohledu klienta a jakmile jsem dostal zelenou, začal jsem samotnou aplikaci modelovat. Jednotlivé fáze tohoto procesu budou popsány dále.
2
Toho reprezentovala doc. Ing. Alena Buchalcevová, Ph.D – vyučující
17
1.3.
Příklad č. 1
Zadání: Aplikace umoţňuje evidenci a vyhledávání krátkodobých brigád. Brigády nabízejí firmy (zaměstnavatelé). Kaţdá firma můţe nabízet více míst. U kaţdé firmy je třeba evidovat kontaktní údaje (adresa, telefon, fax, e-mail). U nabízených míst je třeba evidovat typ brigády, poţadavky na uchazeče, plat a další údaje. Program bude podle zvolených kritérií vyhledávat moţná pracovní místa.
Po konzultaci s klientem: Aplikace bude konstruována jako webová, aby byla moţnost k ní přistupovat z WWW a tím pádem získat co největší moţný rozsah potenciálních klientů. Bude mít nenáročné intuitivní ovládání a bude fungovat v rámci běţného webového prohlíţeče. Z důvodu konkurenční výhody bylo schváleno rozšíření aplikace o další funkčnost, která zahrnuje zadávání poptávek po práci registrovanými uţivateli. Dále bude aplikace umoţňovat: -
vyhledávání nabídek/poptávek práce
-
reakci registrovaných uţivatelů/firem na uvedené inzeráty
-
zakládání nabídek/poptávek práce firem/reg. uţivatelů
-
zasílání vhodných uchazečů firmě automaticky systémem
Po stanovení těchto základních priorit jsem přistoupil k sestavení Use case diagramu (bliţší pohled na problematiku UML a význam jednotlivých diagramů viz následující kapitola). V něm jsem si definoval aktéry, kteří budou hrát v této aplikaci hlavní roli a definoval procesy, které budou moci vykonávat.
18
1.3.1. Diagram uţití (Use case diagram)
OBRÁZEK 4– USE CASE DIAGRAM PRO APLIKACI BRIGÁDA (OBRÁZEK – VLASTNÍ TVORBA MODELOVÁNO V VISUAL PARADIGM FOR UML)
Na první pohled je jasné, ţe aktéři jsou čtyři. Neregistrovaný, registrovaný uţivatel, Pracovník firmy a Časovač. Kaţdý z těchto aktérů má přiřazená určitá práva a můţe tak vyuţívat aplikaci pro více účelů a tedy efektivněji. Neregistrovaný uţivatel můţe pouze vyhledávat a prohlíţet nabídky na práci, registrovaný uţivatel pak můţe na dané nabídky reagovat přímo skrze náš systém, nebo 19
dokonce zaloţit vlastní poptávku po práci, která se následně zobrazí v části pro firmy. Firma, zde reprezentovaná Pracovníkem firmy, tedy například Pracovním oddělením, můţe tedy snadno nahlédnout do naší databáze a tam dle parametrů vyhledat zaměstnance, které potřebuji, nebo samozřejmě nastavit průběţné hledání takových lidí a následně jednu za předem stanovený čas obdrţet od systému jejich výpis. Právě tato vlastnost je zde nazvána Časovač, ta představuje samotný systém a jeho úkony v určitých časových intervalech. Jedná jako „hlídací psi“, zajišťující sběr statistických údajů a přidávání/odebírání nových či prošlých poptávek/nabídek práce.
1.3.1.1. Základní scénář Následně, pro bliţší specifikaci pro ty, jimţ se dostane má práce do rukou a budou mít za úkol toto vše stvořit a implementovat, jsem vytvořil takzvané Základní scénáře pro kaţdý jednotlivý případ uţití uvedených v Use case diagramu.
OBRÁZEK 5 – ZÁKLADNÍ SCÉNÁŘ PRO PŘÍPAD UŢITÍ „PROHLÍŢENÍ PRÁCE DLE PARAMETRŮ“ (VLASTNÍ TVORBA – POMOCÍ OFFICE EXCEL)
20
1.3.2. Diagram tříd (Class diagram) Dalším krokem pro vytvoření této aplikace bylo vytvoření Class diagramu (diagramu tříd), v něm se jako jednotlivé třídy zobrazí nejdůleţitější aspekty aplikace a zde také definuji atributy, které budou mít a metody, jeţ budou vyuţívat.
OBRÁZEK 6– CLASS DIAGRAM APLIKACE BRIGÁDA. VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML
21
Například Nabídka práce:
Zde je atributem id_nabídky – tedy identifikační číslo nabídky (přiřadí systém) id_firmy – přiřazeno při registraci datum_vystavení – přiřadí systém ve chvíli, kdy byla poptávka po práci/nabídka práce vystavena a následně atributy, které budou uvedeny u poptávky/nabídky práce typ_pracovního_poměru pozadované_vzdelani plat Metodami pak: createNabídka deleteNabídka viewNabídka
22
1.3.3. Uţivatelské rozhraní (interface) Samozřejmostí bylo i vytvoření alespoň základního interface. K tomuto účel jsem vyuţil jednoduchý program WPM – WebPageMaker – který je volně ke staţení. Ten mi dovoluje poměrně snadno vytvořit velice dobře vypadající a funkční prostředí, kde mohu otestovat a vyhodnotit propojení jednotlivých stránek, rozloţení základních orientačních kláves a další pouţité prvky. Stejně tak, díky tomuto nástroji, mohu svou práci mnohem snadněji předvést výsledky své práce klientovy a demonstrovat vše to, na čem jsem se s ním domluvil. (pro ilustraci vloţím jen úvodní okno interface)
OBRÁZEK 7 - VZHLED UŢIVATELSKÉHO PROSTŘEDÍ - VYTVOŘENO POMOCÍ WEBPAGEMAKER™ - software dostupný z webu http://www.webpage-maker.com/
Tímto bych rád uzavřel příklad a přistoupil k další kapitole.
23
2. Stručný popis jazyka UML. „UML umoţňuje vyjádření dokumentace analýzy, návrhu i implementace. UML byl vyvinut na základě zkušeností s mnoharůznými metodikami. UML umoţňuje i vyjádření strukturovaného přístupu,ale byl určen zejména pro objektově3
orientovanýpřístup“ .
2.1.1. Definice UML (Unified Modeling Language) UML je „Standard OMG (Object Management Group) pro zaznamenání, vizualizaci a dokumentaci artefaktů systémů s převáţně softwarovou charakteristikou“. Nebo „UML je unifikovaný vyjadřovací prostředek pro dokumentaci obsahové části informatických projektů (dokumentace projektu obsahuje ještě tzvprojektovou dokumentaci, která popisuje 4
projekt jako takový)" Obě tyto definice jsou správné a lze jich najít celou řadu.
Definice také zahrnuje: Notaci UML - pro zachycení artefaktů, na kterých se je potřeba domluvit. Lze jej vyuţít přímo – nakreslit obrázek, k upřesnění implementace --
ale i opačným způsobem,
obrázeknám poslouţí k pochopení existujícího kódu Metamodel UML - model, který vypovídá něco o modelech, které jsou specifikací zavedeny. Například – základy UML jsou dány metamodelem UML. Ten je tedy modelem samotného jazyka UML, přesněji modelem syntaktických pravidel. OCL (ObjectConstraintLanguage) – jazyk pro formálně přesný popis různých
3
Citace viz Doc. Ing. Karel Richta, CSc. - „X36SIN:Softwarové inţenýrství“ http://www.fosfor.cz/fel/sin/SIN_all_01-14.pdf 4
Citace viz Doc. Ing. Karel Richta, CSc. - „X36SIN:Softwarové inţenýrství“ http://www.fosfor.cz/fel/sin/SIN_all_01-14.pdf
24
omezení platných v modelu Specifikace převodu do výměnných formátů.
25
Zde je formulace několika důleţitých zásad pro úspěšnou tvorbu softwaru: -
Vyvíjet iterativně a přírůstkově - zajistit, ţe se vyzkouší více variant a tvorba „nezastydne“ na první myšlence. Následným přidáváním jednotlivých komponent se zajistí kompatibilita a „odladěnost“.
-
Důsledně projít, rozpoznat poţadavky a řádně je zpracovat
-
Modelovat visuálně =>UML
-
Průběţně kontrolovat, ověřovat kvalitu, testovat
-
Snaţit se pruţně reagovat na změny, být na ně připraven!
UML je dnes jiţ neodmyslitelnou součástí tohoto tvořícího procesu, protoţe sjednocuje kromě výhod dosavadních postupů a přístupů pro modelování, návrh a implementaci informačních systémů, tak i jejich názornou dokumentaci „Je ale třeba míti na paměti, ţe UML není všespasitelné, ono „U“ znamená unifikovaný, nikoli univerzální. UML není metodikou, nýbrţ slouţí k vyjádření typových artefaktů, které některé metodiky mohou vyţadovat“
5
Dnes se běţně pouţívá UML 2.0, oficiálně vzniklo v červnu 2003. První verze -- tedy 1.0 -pochází z roku 1996. Verze 2.0 byla navrţena tak, aby její nové moţnosti mohl pouţívat pouze ten, kdo si tak zvolí a ten kdo chce, mohl pracovat jako dříve. Nové vlastnostisamozřejmě mohou přinést výhody, inspirovat nové nástroje pro podporu. Především byl ale navrhován s důrazem na ještě přesnější vyjádření zápisů v UML, přesněji zkvalitnění sémantiky, metamodelu, zápisu. Podnětem k tomuto byl fakt, ţe nově vznikající systémy jsou velice sloţité a jiţ není moţné pouţívat při návrhu stejné postupy jako dříve. Verze 2.0 měla za cíl přesným nastavením, specifikací řídícího stylu docílit maximálního mnoţství kódu generovaného samostatně právě ze specifikace. Následně pak architekt a vývojář mohousoustředit své úsilí více na samotný model, neţ na detaily implementace. Samozřejmostí je, ţe UML se stále vyvíjí a přizpůsobuje novým potřebám.
5
- Citace viz Doc. Ing. Karel Richta, CSc – zapsáno během přednášek na BIVŠ 26
2.2.
Notace UML – diagramy:
UML 2.0 vyuţívá k vyjádření přibliţně 13 diagramů, já zde zmíním 8. Kaţdý je určen k zachycení určitých, specifických informací, které má vyjádřit. Stejně tak jsou přesně dána pravidla pro jejich zápis.
2.2.1. Typy UML diagramů:
Typy diagramů - jednotlivé názvy a moţné variace Anglicky
Česky
Class, Object
Tříd
Use case
Případů uţití; uţití; model jednání
Sequence
Sekvenční; posloupností
Collaboration
Spolupráce
Statechart
Stavový
Activity
Aktivit
Component
Komponent
Deployment
Nasazení, uţití
27
2.2.2. Diagram tříd a objektů: popisuje strukturu systému, zachycuje statický datový model systému od počátku, tedy konceptuální úrovně, aţ do konce, do fáze implementace. -
Jednotlivé třídy nesou svůj název (tučné písmo), jednotlivé atributy a metody, které vyuţívají (pod čarou)
OBRÁZEK 8 DIAGRAM TŘÍD A OBJEKTŮ (VLASTNÍ TVORBA MODELOVÁNO V VISUAL PARADIGM FOR UML)
28
2.2.3. Diagram jednání
Pro něj jsou specifické určité prvky, které se pouţívají vţdy, jsou to tyto: -
aktér
(actor)
-
uţivatelská
role,
spolupracující
systém
(zpravidla
představovaná osobou nebo softwarovou komponentou)
-
případ pouţití (use case) - dokumentace události, na kterou musí systém reagovat
-
komunikace - vazba mezi aktérem a případempouţití (aktér komunikuje se systémem na danémpřípadu)
OBRÁZEK 9 PŘIKLAD DIAGRAMU UŢITÍ (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
29
Diagram sekvenční
-
Zachycují průběţnou spoluprácičinnosti
-
Zachycují jak objekty, tak izprávyposílanév průběhu řešení scénáře
-
Lze je vyuţít pro popis scénáře při komunikaci s uţivateli
OBRÁZEK 10 PŘÍKLAD DIAGRAM SEKVENČNÍ(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
30
2.2.4. Diagram spolupráce
-
Velice podobné diagramu činností. Ovšem zde je mnohem více kladen důraz na komunikační část.
-
Čas je zde vyjádřen pomocí číslování( To lze ale pouţít i v předchozím případě) Jeho hlavním úkolem je zachytit, dokumentovat objekty a zprávy,posílané při řešení úkolu. Jsou tedy zvláště vhodné pro návrh komunikace
OBRÁZEK 11PŘÍKLAD DIAGRAM SPOLUPRÁCE(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
31
2.2.5. Stavový diagram -
Popisujepohyby, přechody v systému
-
Zachycuje stavy, které mohou nastat. Moţnépřechody mezinimi a události, podněty, které je iniciují. Stejně tak uvádějí podmínky, které s tímto souvisí.
-
Lze ho tedy uţít například pro popis metody (je potřeba znát přesný algoritmus algoritmus), nebo třeba pro zachycení protokolu o stykuuţivatele se systémem
OBRÁZEK 12 PŘÍKLAD STAVOVÝ DIAGRAM(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
32
2.2.6. Diagram aktivit -
Jiná varianta diagramu stavového.Zde se kromě stavů mohou pouţít i aktivity a přechody jsou vyvolány dokončením akce, jsou tedy synchronní.
-
Vyuţijí se zejména k dokumentaci tříd, metod a případů pouţití
-
Lze s nimi částečně nahradit diagramy datových toků, které jinak v UML neexistují.
-
Výhodou oproti stavovým diagramům je moţnost vyuţití symbolu „Rozhodnutí“.
OBRÁZEK 13 PŘÍKLAD DIAGRAM AKTIVIT(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
33
Některé elementy tvořící diagram aktivit: Počáteční bod - Initial Node
OBRÁZEK 14 POČÁTEČNÍ BOD(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
Značí se černým puntíkem. Koncový bod - Final Node Máme dva typy koncových bodů: - koncový bod aktivity
OBRÁZEK 15 KONCOVÝ BOD AKTIVITY(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
Koncový bod toku se označuje jako kruh s kříţkem.
OBRÁZEK 16 KONCOVÝ BOD TOKU(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
Rozdíl mezi koncovým bodem aktivity a toku je, ţe koncový bod toku ukazuje konec jediného kontrolního toku a koncový bod aktivity zobrazuje konec všech toků uvnitř aktivity. Aktivita - Aktivita je ukázána jako obdélník se zaoblenými rohy, uzavírající všechny akce, kontrolní toky a ostatní elementy, které tvoří aktivitu.
OBRÁZEK 17 AKTIVITA(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
34
Akce Akce reprezentuje krok uvedený vně aktivity. OBRÁZEK 18 AKCE(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
Kontrolní tok - ControlFlow
OBRÁZEK 19 KONTROLNÍ TOK(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
Kontrolní tok značí směr a přechod kontroly jedné akce do druhé. Rozdělovací/slučovací body – Decision/MergeNodes Značkou je kosočtverec.
OBRÁZEK 20 ROZDĚLOVACÍ/SLUČOVACÍ BODY
Rozdvojka a spojka - Fork and Joinnodes Nesou stejné označení – horizontální/vertikální „čáru“. Orientace čáry závisí na tom, zda se kontrolní tok pohybuje vertikálně, nebo horizontálně
OBRÁZEK 21 ROZDVOJKA A SPOJKA(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
-
Výstupní tok ze spojky nemůţe proběhnout, dokud nebyly přijaty všechny vstupní toky. 35
2.2.7. Diagram komponent -
Znázorňují strukturu(fyzickou) částí, komponent systému
-
Popisují typy částí, komponent.
-
Jednotlivé části mohou být vnořeny do jiných
-
Při vyjadřování vztahu mezi jednotlivými částmi lze
uţít „interface“
OBRÁZEK 22 PŘÍKLAD DIAGRAMU KOMPONENT(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
36
2.2.8. Diagram nasazení -
Popisují fyzické rozmístění elementů systému na uzly výpočetního systému
-
Popisují nutné vazby mezi uzly (případně téţ
-
pouţitý protokol - „interface“)
-
Obsahují pouze komponenty potřebné pro běh aplikace - komponenty potřebné pro překlad a sestavení jsou v diagramu komponent
OBRÁZEK 23 PŘÍKLAD DIAGRAM NASAZENÍ(VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML)
37
3. E-government v ČR. E-government vznikl v roce 1999 ve Velké Británii, která je dnes také v této oblasti nejdále. Postupně se začal realizovat v dalších evropských státech, jako významný prvek racionalizace státní a veřejné správy.
3.1. Pod
Charakteristika e- governmentu: pojmem e-government (téţ
označovaný
jak
E-government,
egovernment,
Egovernment) se označuje moţnost komunikace s institucemi státní a veřejné správy v elektronické podobě a veškeré procesy s tím související, zejména tvorba příslušné legislativy a přechod úřadů na elektronickou verzi vedení dokumentace. Pro správnou funkci e-governmentu je klíčová účelná elektronizace vnitřních agend ve veřejné správě, neboť jedině taková elektronizace v konečném důsledku umoţní veřejnosti volbu lokality a volbu způsobu komunikace s veřejnou správou. Právě elektronizace vnitřních agend veřejné správy je v současnosti nejsloţitějším úkolem egovernmentu.A stále tak zůstává předmětem hledání správného a efektivního řešení jak v České republice, tak v zahraničí. Jaké jsou jeho cíle a co vše nám přináší? Cílem e-governmentu je především usnadnit styk veřejnosti s úřady. Především se zde jedná o maximalizaci úspory času jak občanů, tak podnikatelů. Dále by měl e-government také zajišťovat větší efektivitu ve fungování úřadů a tím (teoreticky) ušetřit finance. Další peníze by se měli ušetřit právě uchováváním dokumentů v elektronické podobě, coţ ušetří náklady například za skladovací prostory, údrţbu klimatu vhodného pro delší skladování, ale i niţší spotřeba času při skladovacím času, respektive při hledání nějakého dokumentu.(Viz tabulka na další straně) To také byla hlavní „lákadla“ pro veřejnost. Celý koncept vychází z toho, ţe lidé jiţ dospěli do stádia, kdy jim nečiní ţádný problém pouţívat e-mail, nebo internetovské bankovnictví.. A skutečně jsou ohlasy spíše pozitivní. Na druhé straně ovšem práci brzdí některé úřady, které mají s elektronizací problémy.
38
3.2.
eGON
V ČR se stal symbolem e-governmentueGON. Jedná se o názorné vysvětlení jednotlivých pojmů e-governmentu ve veřejné správě. Tyto pojmy jsou čtyři. „Mozek“ – Základní registry veřejné správy V těchto registrech by měla být uloţena základní data o občanech. Důsledkem toho by měla klesnout nutnost navštěvovat jednotlivé úřady. Ty by si měly informace mezi sebou předávat nezávisle a třeba je jen jednou za čas potvrdit uloţené informace a dát souhlas s jejich uţíváním pro předem určené potřeby. Snad tedy konec podávání stále stejných informací dokola a dokola. „Oběhový systém“ – Komunikační infrastruktura VS (KIVS) KIVS zabezpečuje propojení sítí a systémů do společného prostředí. Vnáší jednotu a lepší koordinace a tím zvyšuje srozumitelnost sdílených informací, odpadají problémy s jiným softwarem atd., a sniţuje tím náklady. „Srdce“ – Zákon o e-governmentu (o
elektronických
úkonech
a
autorizované
konverzidokumentů) a Datové schránky. „Prsty“ – Czech POINT Pobočky
Czech
místěinformace
POINT o
údajích
zpřístupňují vedených
na v
jednom
centrálních
registrech. Czech POINT ale neslouţí pouze k získávání informací – můţete ho vyuţít takéjako podací místo (v OBRÁZEK 24 EGON – DOSTUPNÝ Z http://www.mvcr.cz/clanek/egon-jakosymbol-egovernmentu-modernihopratelskeho-a-efektivniho-uradu252052.aspx
současnosti např. k Registru ţivnostenského podnikání)
39
3.3. Popis jednotlivých částí: 3.3.1. Základní registry veřejné správy Hlavním důvodem jejich vzniku je především nejednotnost, stejně jako multiplicita dat a nedostatečné jednota v jejich formátu. Stejně tak jsou uloţené údaje nespolehlivé a jejich osobní vyplnění nebo potvrzení je nutné velmi často. Poţadavkem tedy je, aby data byla správná, úplná, aktuální a závazná. A to při zachování jejich transparentnosti pro osobu, nebo subjekt, jíţ se týkají a udrţení moţnosti sdílení dat mezi jednotlivými informačními systémy veřejné správy. Toto zajišťuje ISZR – Informační systém základních registrů, jehoţ správcem je úřad Správa základních registrů. Vytvořený právě za tímto účelem. S tím je také blízce spjat Zákon o základních registrech – zákony k jednotlivým registrům (Registr obyvatel – ROb, osob –ROs, a tak dále). Rozdělení a propojení jednotlivých registrů a úřadů je zobrazeno v modelu na další straně. Základní model Informačního systému základních registrů (řízení poskytování sluţeb egovernmentu
3.3.2. KIVS – Komunikační infrastruktura veřejné správy. Systém je koncipován tak, ţe skrze Centrální místo sluţeb se nastavuje celá jeho logika. Právě přes CMS různé subjekty veřejné správy propojují své linky a nezáleţí tedy na druhu jejich operátora. (Ve článku, ze kterého jsem čerpal, přirovnal tehdejší vrchní ředitel sekce rozvoje a projektového řízení ICT v oblasti veřejné správy Jindřich Kolář CMS k CML – centrálnímu mozku lidstva ze seriálu Návštěvníci, coţ mi přijde velice trefné) Toto řešení bylo zvoleno po předchozích zkušenostech s pouze jedním operátorem, kterým byla Telefónica O2. V soutěţi roku 2007 byly pak vybrány ještě společnosti GTS Novera a konsorcium T-Systems a ČD Telematika. Stalo se tak především ve jménu úspor, kterých bylo moţné, a také bylo, dosaţeno právě skrze nabourání monopolního postavení O2. Uţ v prvních dvou výběrových řízeních bylo totiţ dosaţeno úspor převyšujících 250 milionů korun. Tato částka byla následně investována do zkvalitnění nebo zrychlení spojení. Při zavádění CMS bylo samozřejmě pamatováno i na stávající sítě, kterých v našich zemích stále přibývá. Řešení je takové, ţe tam, kde není potřeba nové sítě, propojení budovat, tam kde uţ jsou, se CMS připojí rovnou k nim, poskytne své sluţby, například i připojení k internetu, a na oplátku vyuţije volný prostor v dané síti.
40
3.3.3. Datové schránky a zákon o e-governmentu „eGA čili zákon o e-governmentu - eGONovo srdce, které ho přivádí k ţivotu. Zákon o elektronických úkonech a autorizované konverzi dokumentů byl vyhlášen ve Sbírce zákonů 19.8.2008. Tento zákon, někdy téţ nazývaný zákon o e-governmentu nebo egovernmentAct, nabyl účinnosti od 1. července 2009.“ Jeho cílem je vytvořit, stanovit ideální prostředí, podmínky pro elektronickou komunikaci jak mezi úřadem a občanem, tak mezi jednotlivými úřady. Klíčové pro tuto komunikaci jsou právě datové schránky, které jsou prostředníkem při doručování úředních zpráv v elektronické podobě. Dalším klíčovým prvkem zákona je autorizovaná konverze dokumentů z/do elektronické podoby a potvrzení shody, pravosti.
3.3.3.1. Datové schránky Co říká zákon? „Datová schránka je elektronické úloţiště, které je určeno k doručování orgány veřejné moci a k provádění úkonů vůči orgánům veřejné moci. Datová schránka je elektronické úloţiště, které slouţí k dodávání dokumentů fyzických osob, podnikajících fyzických osob a právnických osob. Datové schránky zřizuje a spravuje Ministerstvo vnitra.“
6
Zavedení datových stránek se týká prakticky všech, kteří se pohybují ve veřejné správě. Stejně tak se týká právnických osob – firem. Stejně tak se týká i ţivnostníků a pokud mají zájem, mohou ho vyuţívat i osoby fyzické, to ale jen málokdo z nich, nás ví. V dnešní době uţ je moţná i komunikace mezi samotnými právnickými osobami a podnikajícími fyzickými osobami, tato moţnost je tu od 1.1.2010. Datové schránky fungují v rámci Informačního systému datových schránek (ISDS), ten spravuje Ministerstvo vnitra České republiky. Řízení tohoto systému spadá a je řízeno zákony a předpisy. Provozovatelem pak drţitel poštovní licence, u nás Česká pošta. V tomto systému jsou uchovávány veškeré informace o datových schránkách a jejích uţivatelích.
6
Citace z dokumentu INFORMAČNÍ SYSTÉM DATOVÝCH SCHRÁNEK - Základní informace Verze 3.0,
červenec 2009 http://www.datoveschranky.info/download/flyer.pdf
41
Díky tomuto propojení lze a v praxi ušetřit poměrně velkou sumu peněz. Zde přikládám výstupní dokument z roku 2008, který to jen potvrzuje – viz příloha P4.
42
3.3.4. Czech
POINT
(Český Podací Ověřovací a Informační Národní Terminál.)
Místo nazvaná „Czech point“ jsou rozeseta po celém území naší republiky a jedná se o asistované místo výkonu veřejné správy. Provoz byl zahájen koncem března 2007 v 37 pobočkách městských a obecních úřadů po celá České republice. Jako první z nich byla slavnostně otevřena pobočka 28.3.2007 tehdejším ministrem vnitra a premiérem vlády ČR.na Praze 13. Tehdy ale bylo moţné získat jen přibliţně 20% z nynějších nabízených sluţeb. Dalším milníkem pak bylo spuštění dalších osmi set poboček 1.1.2008. Na konci roku 2008 jiţ fungovalo více neţ 2000 poboček. Na začátku roku 2009 (24.ledna) byl počet pracovišť Czech POINTU 3261. Na obecních a městských úřadech, na pobočkách České pošty, u vybraných notářů, ale například i na českých zastupitelstvích v zahraničí. Ke 31.2011 uţ jich bylo 6516.
OBRÁZEK 25 POČET PRACOVIŠŤ CZECH http://www.czechpoint.cz/web/index.php?q=node/488
POINT
–
DOSTUPNÉ
Z
43
3.3.4.1. Czech POINT. Slouţí k získání přihlašovacích údajů k datové schránce, stejně jako místo, kde lze nahlásit jejich odcizení a blokaci. Tato místa jsou také prostředníkem pro připojení do datových schránek. Například můţe také pracovník dané pobočky klientovy z jeho datové schránky vytisknout dokument, za poplatek, v opačném případě, převede dokument v papírově podobě do podoby elektronické, umístí elektronický podpis a odešle dokument danému orgánu veřejné správy. Na konci roku byl vydán téměř jeden milion výpisů. K 31.1.2011 pak uţ počet vydaných výstupů přesáhl 4.500.000.
OBRÁZEK 26 POČETY VYDANÝCH VÝSTUPŮ http://www.czechpoint.cz/web/index.php?q=node/488
CZECH
POINT
-
DOSTUPNÉ
Z
Czech POINT ale samozřejmě nefunguje jen jako podpora Datových schránek, v prvním odstavci jsem se snaţil ukázat provázanost tohoto systému.
44
3.3.4.2. Ve všech jeho pobočkách si lze zařídit: a)Výpis z Katastru nemovitostí b)Výpis z Obchodního rejstříku c)Výpis z Ţivnostenského rejstříku d)Výpis z Rejstříku trestů e)Přijetí podání podle ţivnostenského zákona (§ 72) f)Ţádost o výpis nebo opis z Rejstříku trestů podle zákona č. 124/2008 Sb g)Výpis z bodového hodnocení řidiče h)Vydání ověřeného výstupu ze Seznamu kvalifikovaných dodavatelů i)Podání do registru účastníků provozu modulu autovraků ISOH j)Výpis z insolvenčního rejstříku k)Datové schránky l)Autorizovaná konverze dokumentů m)Centrální úloţiště ověřovacích doloţek n)Úschovna
systému
Czech
POINT -Úschovna
dokumentů
je
podpůrný
systém
proautorizovanou konverzi dokumentů. Vyuţívá se pro dočasné uloţení dokumentů v rámci konverze o)CzechPOINT@office - CzechPOINT@office je rozhraní, které bylo vytvořeno pro potřeby samotného úřadu. Jeho obsahem jsou agendy vykonávající úřady a orgány veřejné moci pro výkon své působnosti. CzechPOINT@office je součástí stávajícího systému. Je ale také moţnost k němu získat samostatný přístup. p)Czech POINT E-SHOP - výpisy poštou. Po vyplnění jednoduchého formuláře na internetu si lze objednat výpis ze ţivnostenského rejstříku, obchodního rejstříku a katastru nemovitostí. Ten pak bude do tří pracovních dnů doručen Českou poštou. V poslední době se pracuje i na dalších způsobech vyuţití a na dalších typech informací, které by mohla tato pracoviště zprostředkovávat. Podle mého tyto sluţby dokáţí člověku ušetřit poměrně velké mnoţství času. Vţdyť jen samotné úřady sídlí často nejen v naprosto jiných budovách, v jiných částech města ale i v úplně jiných městech. Coţ mohu sám, jako člověk, který vyrůstal a dosud ţije, v malé obci vzdálené od nejbliţšího většího města přibliţně 30 kilometrů, posoudit. Počty vydaných výstupů – jednotlivé poloţky za období 2007 – březen 2011 viz příloha P3.
45
4. Příklad vyuţití UML v e-governmentu Pro demonstraci vyuţití UML jsem se rozhodl vytvořit základní diagramy (activity diagram a class diagram) právě pro jiţ zmiňovaný CzechPOINT, konkrétně pak pro funkci Výpis z Katastru nemovitostí. Ta je nejvyuţívanější ze všech nabízených sluţeb a stejně tak patří i mezi první nabízené v rámci tohoto projektu. Jako modelovací nástroj jsem pouţil Visual Paradigmfor UML – community version, který je volně ke staţení na webu.(doplnit odkaz) Snahou mého konání bylo zobrazit posloupnosti tohoto úkonu a zjistit, zda je vyuţit dostatečně efektivně. Případně se pokusit odhalit nedostatky, kterými trpí a najít cestu, která je podle mě efektivnější. Prvním problémem, který jsem musel řešit byl přístup k samotnému CzechPOINTu, navštívil jsem několik úřadů státní správy v Praze, kde jsou jiţ několik let pobočky CzechPOINT zřízeny. Ovšem narazil jsem na neochotu, které mě velice překvapila. Zdrojem mých informací se tedy stal Obecní úřad Chanovice, kde mi vyšli velmi vstříc.
4.1.
Activity diagram:
Diagram jsem tvořil za pouţití poznámek, které jsem si vytvořil při pozorování administrativní pracovnice v praxi. Kladně hodnotím především přímočarost jednotlivých procesů. Stejně tak se mi líbí nenáročnost na znolost dané problematiky pro uţivatele. To znamená, ţe se v aplikaci po chvíli orientuje i laik. Pokud nastanou jakékoliv problémy, lze přímo z centrály stáhnout návod, který dokáţe vše poměrně kvalitně popsat. Co mi v něm ale chybělo, byl právě nějaký jednoduchý model, který by jednotlivé kroky dokázal seřadit za sebe a provést skrze úkony v co moţná nejsrozumitelnější podobě. Právě proto jsem zvolil diagram activit, který tuto funci skvěle plní. Viz příloha P5.
46
Dále jsem zvolil
4.2.
UseCase diagram,
pro jasné vymezení přímých aktérů, kteří v řešené problematice účinkují a procesů, které obstarávají. Zde jsem uvedl dva aktéry, jednak uţivatele, který disponuje certifikátem (Uţivatel – drţitel certifikátu) a systém jako takový, který má za úkol mapovat aktivity uţivatelů a sbírat potřebné informace, jsem uvedl jako Časovač. Jedná se především o počet přístupů, typ poţadovaného formuláře, místo odkud se přistupovalo. Neméně důleţité je také, aby systém kontroloval aktivitu uţivatele. Zde je limit nastaven na 20 minut, při dvaceti minutové neaktivitě systém uţivatele automaticky odhlásí. Tato dvaceti minutová prodleva je nastavena ale i z důvodu krátkodobého výpadku proudu, poruše zařízení a podobně. Viz příloha P6.
47
Závěr Účelem mé práce bylo zjistit, zda můţe pouţití UML v oblasti e-Governmentu nějak pomoci usnadnit jeho zavádění nejen do infrastruktury úřadů, ale především do ţivota občanů, kteří jsou cílovou skupinou. I kdyţ totiţ vyuţívání sluţeb poskytovaných na úřadech roste, většina populace je zatím zcela ignoruje. Toho jsem se snaţil docílit vyuţitím základních postupů a diagramů definovaných právě pro tento modelovací jazyk. Z příkladu, který jsem uvedl v poslední kapitole je dle mého názoru jasně viditelné, ţe CzechPOINT jako takový byl navrţen dobře. Přímočarý proces, který přes několik kroků vyústí v jasný výsledek. Bohuţel způsob jakým je tato sluţba prezentovánazaměstnanci některých úřadů, je spíše opačný. Osobně jsem byl svědkem situace, kdy zaměstnanec takové pobočky odešle občana pro výpis z Katastru nemovitostí na „nejbliţší“ Stavební úřad, který je dvacet i více kilometrů vzdálený a to jen proto, ţe sám přesně neví, jak CzechPOINT obsluhovat. Toto je podle mě ovšem velmi snadno řešitelné, vţdyť uţ jen letmý pohled na UseCase diagram má velkou výpovědní hodnotu. Jak pro občana, který něco potřebuje, tak pro úředníka, který právě díky grafickému znázornění posloupnosti jednotlivých kroků můţe s konkrétní sluţbou pracovat i bez větší míry zkušeností.
48
Seznam pouţitých obrázků: OBRÁZEK 1 – PŘEJATO OD M. MINIBERGER, INFORMAČNÍ SYSTÉMY VE ZDRAVOTNICTVÍ -2. [ON/LINE][CIT. 2011/02/04] DOSTUPNÉ Z: HTTPS://IS.BIVS.CZ/AUTH/EL/6110/LETO2011/B108ISZ/INFORMACNI_SYSTEMY_VE_ZDRAVOTNICTVI2-CB2011.PDF?FAKULTA=6110;OBDOBI=57;KOD=B108ISZ ................................................................................... 7 OBRÁZEK 2 POŘÍZEN Z WEBOVÝCH STRÁNEK SPOLEČNOSTI IBM, STEJNĚ JAKO NĚKTERÉ INFORMACE HTTP://WWW.IBM.COM/DEVELOPERWORKS/WEBSERVICES/LIBRARY/WS-SOA-TERM2/ .......................... 14 OBRÁZEK 3 ZÍSKÁN SKRZE WEB – DOSTUPNÉ Z HTTP://PANREPA.ORG/CASE/CASE_V_SWHOUSU.PDF .............. 16 OBRÁZEK 4USE CASE DIAGRAM PRO APLIKACI BRIGÁDA (OBRÁZEK – VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ...................................................................................................................... 19 OBRÁZEK 5 ZÁKLADNÍ SCÉNÁŘ PRO PŘÍPAD UŽITÍ „PROHLÍŽENÍ PRÁCE DLE PARAMETRŮ“ (VLASTNÍ TVORBA – POMOCÍ OFFICE EXCEL) ............................................................................................................................... 20 OBRÁZEK 6CLASS DIAGRAM APLIKACE BRIGÁDA. VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML.............................................................................................................................................................. 21 OBRÁZEK 7 VZHLED UŽIVATELSKÉHO PROSTŘEDÍ - VYTVOŘENO POMOCÍ WEBPAGEMAKER™ - SOFTWARE DOSTUPNÝ Z WEBU HTTP://WWW.WEBPAGE-MAKER.COM/ ..................................................................... 23 OBRÁZEK 8 - DIAGRAM TŘÍD A OBJEKTŮ (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) .. 28 OBRÁZEK 9 PŘIKLAD DIAGRAMU UŽITÍ (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) DIAGRAM SEKVENČNÍ .................................................................................................................................. 29 OBRÁZEK 10 PŘÍKLAD DIAGRAM SEKVENČNÍ (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ..................................................................................................................................................................... 30 OBRÁZEK 11PŘÍKLAD DIAGRAM SPOLUPRÁCE (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ............................................................................................................................................................ 31 OBRÁZEK 12 PŘÍKLAD STAVOVÝ DIAGRAM (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) 32 OBRÁZEK 13 PŘÍKLAD DIAGRAM AKTIVIT (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) . 33 OBRÁZEK 14 POČÁTEČNÍ BOD (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ................... 34 OBRÁZEK 15 KONCOVÝ BOD AKTIVITY (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ...... 34 OBRÁZEK 16 KONCOVÝ BOD TOKU (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ........... 34 OBRÁZEK 17 AKTIVITA (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ............................... 34 OBRÁZEK 18 AKCE (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ..................................... 35 OBRÁZEK 19 KONTROLNÍ TOK (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ................... 35 OBRÁZEK 20 ROZDĚLOVACÍ/SLUČOVACÍ BODY ...................................................................................................... 35 OBRÁZEK 21 ROZDVOJKA A SPOJKA (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) .......... 35 OBRÁZEK 22 PŘÍKLAD DIAGRAMU KOMPONENT (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ............................................................................................................................................................ 36 OBRÁZEK 23 PŘÍKLAD DIAGRAM NASAZENÍ (VLASTNÍ TVORBA - MODELOVÁNO V VISUAL PARADIGM FOR UML) ..................................................................................................................................................................... 37 OBRÁZEK 24 EGON – DOSTUPNÝ Z HTTP://WWW.MVCR.CZ/CLANEK/EGON-JAKO-SYMBOL-EGOVERNMENTUMODERNIHO-PRATELSKEHO-A-EFEKTIVNIHO-URADU-252052.ASPX .......................................................... 39 OBRÁZEK 25 POČET PRACOVIŠŤ CZECH POINT – DOSTUPNÉ Z HTTP://WWW.CZECHPOINT.CZ/WEB/INDEX.PHP?Q=NODE/488 ................................................................. 43 OBRÁZEK 26 POČETY VYDANÝCH VÝSTUPŮ CZECH POINT DOSTUPNÉ Z HTTP://WWW.CZECHPOINT.CZ/WEB/INDEX.PHP?Q=NODE/488 ................................................................. 44
49
Zdroje informací Tištění monografie: 1. ŘEPA, Václav:. Podnikové procesy : Procesní řízení a modelování. 2. aktualizované a rozšířené vydání. [s.l.] : [s.n.], 2008. 288 s. ISBN 978-80-247-2252 2. SCHEER,A-V.: Od podnikových procesů k aplikačním systémům. IDS- Scheer ČR, Brno 2002, (ISBN 80-238-4719-8. 3.
Příspěvky v elektronických monografiích 4. MINIBERGER Miloš: Informační Systémy ve zdravotnictví -2. [on/line][cit. 2011/02/04] Dostupné z: https://is.bivs.cz/auth/el/6110/leto2011/B108ISZ/Informacni_systemy_ve_zdravotnict vi2-cb-2011.pdf?fakulta=6110;obdobi=57;kod=B108ISZ 5. PELC, Jiří ; MEDŘICKÝ, Petr ; PEŠIČKA, Michal. Vyuţití modelovacích nástrojů ve vývojářské firmě : Prostředky CASE a jejich vyuţití při tvorbě IS. CASE [online]. 11. prosince 2005, 1, [cit. 2011-04-12]. Dostupný z WWW: http://panrepa.org/CASE/CASE_v_SWhousu.pdf 6. RICHTA, Karel. Softwarové inţenýrství : Modelovánípoţadávků. Softwarové inţenýrství [online].[cit. 2011-04-12]. Prezentace; Dostupný z WWW: http://www.fosfor.cz/fel/sin/SIN_all_01-14.pdf 7. ŠVEŘEPA, Jaromír. Modelování webových sluţeb v UML. Modelování [online]. 2006, 1, [cit. 2011-04-12]. Dostupný z WWW: http://www.lbms.cz/Nastroje/SelectArchitect/_pdf/Modelovani-webovych-sluzeb-v-UML-info.pdf
Firemní dokumentce: 8. Czech POINT [online].Ministerstvo vnitra České republiky, 2010, 2010 [cit. 2011-0412]. Czech POINT. Dostupné z WWW: http://www.czechpoint.cz/web/index.php 9. Datové schránky [online]. 2008, 07. 04. 2011 11:34:18 [cit. 2011-04-12]. Dostupné z WWW: http://www.datoveschranky.info/uvod/ 10. INFORMAČNÍ SYSTÉM DATOVÝCH SCHRÁNEK. Základní informace [online]. červenec 2009, 3, [cit. 2011-04-12]. Dostupný z WWW: http://www.datoveschranky.info/ke-stazeni/ 11. MINISTERSTVO VNITRA České republiky. EGON : NEWS. EGON [online]. únor 2009, 4, [cit. 2011-04-12]. Dostupný z WWW: www.mvcr.cz/soubor/egon-news-4pdf.aspx 12. ERationalUnifiedProcess : Best Practicesfor Software DevelopmentTeams. Rational Software WhitePaper[online]. 2001, 1, [cit. 2011-04-12]. Dostupný z WWW: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_ bestpractices_TP026B.pdf 50
Přílohy:
Příloha 1 – Model tříd procesní oblasti stavebního úřadu – převzato z ŘEPA, Václav:. Podnikové procesy : Procesní řízení a modelování. 2. aktualizované a rozšířené vydání. [s.l.] : [s.n.], 2008. 288 s. ISBN 978-80-247-2252
51
Příloha 2 - Ţivotní cyklus objektů "Stavba "– převzato z ŘEPA, Václav:. Podnikové procesy : Procesní řízení a modelování. 2. aktualizované a rozšířené vydání. [s.l.] : [s.n.], 2008. 288 s. ISBN 978-80-247-2252
52
53 Příloha 3 - Úspory po zavedení datových stránek Úřad plzeňského kraje 2008 – převzato z http://www.datoveschranky.info/dokumenty/
Příloha 4 - počet jednotlivých výstupů za období 2007 – 2011;DOSTUPNÉ Z http://www.czechpoint.cz/web/index.php?q=node/488
54
55 Příloha 5 - Activity diagram pro CzechPOINT - výpis z katastru nemovitostí (vlastní tvorba – vytvořeno ve VisualParadigmfor UML)
Příloha 6 – UseCase diagram CzechPOINT - Výpis z katastru nemovitostí (vlastní tvorba – vytvořeno ve VisualParadigmfor UML)
56
Seznam příloh PŘÍLOHA 1 – MODEL TŘÍD PROCESNÍ OBLASTI STAVEBNÍHO ÚŘADU – PŘEVZATO Z ŘEPA, VÁCLAV:. PODNIKOVÉ PROCESY : PROCESNÍ ŘÍZENÍ A MODELOVÁNÍ. 2. AKTUALIZOVANÉ A ROZŠÍŘENÉ VYDÁNÍ. *S.L.+ : [S.N.], 2008. 288 S. ISBN 978-80-247-2252............................................................................................................. 51 PŘÍLOHA 2 - ŽIVOTNÍ CYKLUS OBJEKTŮ "STAVBA " – PŘEVZATO Z ŘEPA, VÁCLAV:. PODNIKOVÉ PROCESY : PROCESNÍ ŘÍZENÍ A MODELOVÁNÍ. 2. AKTUALIZOVANÉ A ROZŠÍŘENÉ VYDÁNÍ. *S.L.+ : [S.N.], 2008. 288 S. ISBN 978-80-247-2252 ................................................................................................................................. 52 PŘÍLOHA 3 - ÚSPORY PO ZAVEDENÍ DATOVÝCH STRÁNEK ÚŘAD PLZEŇSKÉHO KRAJE 2008 – PŘEVZATO Z HTTP://WWW.DATOVESCHRANKY.INFO/DOKUMENTY/ .............................................................................. 53 PŘÍLOHA 4 - POČET JEDNOTLIVÝCH VÝSTUPŮ ZA OBDOBÍ 2007 – 2011; DOSTUPNÉ Z HTTP://WWW.CZECHPOINT.CZ/WEB/INDEX.PHP?Q=NODE/488 ................................................................. 54 PŘÍLOHA 5 - ACTIVITY DIAGRAM PRO CZECHPOINT - VÝPIS Z KATASTRU NEMOVITOSTÍ (VLASTNÍ TVORBA – VYTVOŘENO VE VISUAL PARADIGM FOR UML)............................................................................................ 55 PŘÍLOHA 6 – USECASE DIAGRAM CZECHPOINT - VÝPIS Z KATASTRU NEMOVITOSTÍ (VLASTNÍ TVORBA – VYTVOŘENO VE VISUAL PARADIGM FOR UML)............................................................................................ 56
57
