}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Webový informační systém pro odpadové hospodářství Bakalářská práce Matěj Karolyi Brno, 2015

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Matěj Karolyi Vedoucí práce: prof. RNDr. Jiří Hřebíček, CSc. ii

Poděkování Chtěl bych poděkovat panu prof. RNDr. Jiřímu Hřebíčkovi, CSc. za cenné rady, připomínky a předané zkušennosti. Velký dík patří i mé rodině, přítelkyni a přátelům, kteří mě podporovali v předchozím studiu. iii

Shrnutí V bakalářské práci je analyzován stav legislativy týkající se odpadového hospodářství v České republice. Dále se práce zabývá návrhem a implementací prototypu webového informačního systému pro odpadové hospodářství podniku s více provozovnami, k němuž uživatelé přistupují prostřednictvím webového prohlížeče. Prototyp systému byl konzultován v organizaci s více provozovnami a implementován tak, aby byl použitelný v běžné praxi. iv

Klíčová slova informační systém, model-view-controller, ASP.NET MVC, databáze, UML, environmentalistika, odpadové hospodářství v

Obsah 1 Úvod............................... 3 2 Teoretická východiska..................... 5 2.1 Informační systémy..................... 5 2.1.1 Jakost informačního systému............ 5 2.2 Environmentalistika..................... 6 2.3 Environmentální informační systémy v ČR........ 7 2.3.1 CENIA....................... 7 2.3.2 ISPOP........................ 8 2.3.3 ENVIS........................ 9 3 Analýza............................. 10 3.1 Legislativa.......................... 10 3.1.1 Zákon 185/2001 Sb.................. 10 3.1.2 Vyhláška 383/2001 Sb................ 11 3.1.3 Vyhláška 381/2001 Sb................ 11 3.2 Hlášení o odpadech pro ČSÚ................ 11 3.3 Specifikace požadavků................... 12 3.3.1 Nefunkční požadavky................ 12 3.3.2 Funkční požadavky................. 13 3.4 Případy užití........................ 14 3.4.1 Přihlášení...................... 16 3.4.2 Odhlášení...................... 16 3.4.3 Změna osobních údajů............... 16 3.4.4 Resetování hesla uživatelů............. 16 3.4.5 Evidence odpadů.................. 16 3.4.6 Práce s nápovědou................. 17 3.4.7 Vytváření výstupů a výběr typu výstupu..... 17 3.4.8 Správa číselníků................... 17 3.4.9 Správa účtů..................... 17 3.5 Nejčastější aktivity uživatelů v systému.......... 18 3.5.1 Správa záznamů................... 18 3.5.2 Vytváření výstupů................. 19 4 Návrh............................... 20 4.1 Vybrané číselníky...................... 20 4.1.1 Orp......................... 20 4.1.2 Zuj.......................... 20 1

4.1.3 Waste........................ 21 4.1.4 Process....................... 21 4.1.5 Adr.......................... 22 4.1.6 Ycode........................ 22 4.2 Datový model........................ 22 4.3 Návrh obrazovky výstupů hlášení............. 25 5 Implementace.......................... 26 5.1 Použité technologie..................... 26 5.1.1 ASP.NET a MS SQL................ 26 5.1.2 CSS & LESS.................... 27 5.1.3 Ostatní....................... 29 5.2 Architektura MVC v kontextu ASP.NET......... 29 5.2.1 Model číselníku Ycode............... 29 5.2.2 Pohled uživatelských rolí.............. 30 5.2.3 Řadič pro obsluhu přihlašování.......... 32 5.3 Nasazení a testování.................... 33 6 Ukázky Envis 2......................... 35 7 Závěr............................... 37 Seznam literatury....................... 39 A Výstup hlášení pro ORP................... 41 B Výstup hlášení pro ČSÚ................... 42 C Doplňující materiály...................... 45 C.1 Seznam elektronických příloh............... 45 C.2 Obsah přiloženého CD................... 45 2

1 Úvod Využívání informačních technologií (IT) k usnadnění a zkvalitnění práce je v mnoha oblastech lidské činnosti stále častějším jevem. Jedním z odvětví IT jsou i informační systémy (IS), které dovolují shromažďovat a ukládat data. Dále je datům přidělen význam, vzniká informace, a ta může být systémem prezentována pro potřeby uživatelů. Jedno ze základních dělení IS je na systémy pro zpracování dat a na komunikační systémy [1]. Systém, který je výsledkem této práce, můžeme zařadit do první kategorie. Informační systémy jsou hojně využívány v podnikové sféře. V té jsou pro uživatele vhodným nástrojem k organizaci a archivaci informací souvisejících s celým životním cyklem firmy. Oborem, který nás bude blíže zajímat, je environmentalistika. Environmentální informační systém (EIS) má zabezpečovat komunikaci, vedení záznamů a dokumentace a podávání zpráv o chování firmy k životnímu prostředí všem zainteresovaným stranám [2]. Zainteresovanými stranami se myslí zejména státní orgány. Těm jsou firmy povinny podle zákona podávat především roční přehled evidence nakládání s odpady. Cílem této práce je návrh a implementace informačního systému pro vedení odpadové evidence. Samotnému vývoji systému předchází analýza současné legislativy, zejména zákona 185/2001 Sb, který upravuje pravidla pro nakládání s odpady, práva a povinnosti osob v odpadovém hospodářství a působnost orgánů veřejné správy [3]. Z uvedeného zákona vychází mnoho úprav, které mají vliv i na vývoj informačního systému, a je nutné tyto úpravy při vývoji respektovat a neporušovat. Během fáze analýzy je zapotřebí si určit funkční i nefunkční požadavky a definovat případy užití pomocí diagramu. V další fázi vývoje probíhá návrh systému. Je vytvořen model databáze a jsou vybrány technologie, které se použijí k implementaci. Při implementaci je kladen důraz na to, aby byl zdrojový kód přehledný a dodržoval konvence daného programovacího jazyka. Systém nese jméno Envis 2 (Environmentální informační systém 2) a vychází z nyní používaného systému Envis. Motivace pro modernizaci systému plyne především z toho, že je stávající IS už zastaralý. Od vytvoření prvního Envisu se změnily nejen technologické možnosti, ale také zákon. Ze zmíněného systému je částečně zachováno schéma databáze a rozvr- 3

1. Úvod žení uživatelského rozhraní. Nový systém je ovšem kompletně přeprogramován. Předpokládá se, že systém bude konzultován ve vybrané organizaci s více provozovnami. Pokud bude uznán vhodným pro potřeby vedení odpadového hospodářství, nabízí se možnost nasadit systém ve zmiňované organizaci a rozšířit ho i do dalších firem. Těm Envis 2 umožní automatizovaně vytvářet hlášení pro ISPOP (Integrovaný systém pro plnění ohlašovací povinnosti) starající se o sběr informací ohledně nakládání s odpady. Práce je dělena do kapitol, přičemž každá z nich se věnuje jiné etapě vývoje systému. Následující kapitola vysvětluje základní pojmy v oblasti informačních systémů a environmentalistiky. Účel této kapitoly je především v uvedení čtenáře do problematiky, která je v následujících částech práce blíže specifikována. Třetí kapitola zachycuje analýzu současného stavu a představuje právní předpisy stanovující normy, které by měl náš systém splňovat. Jsou zde vypsány stěžejní zákony upravující nakládání s odpady na území České republiky. Nachází se zde již dříve zmiňovaný diagram případů užití, ale také diagramy aktivit. Kapitola nesoucí název Návrh ukazuje datový model systému pomocí ERD diagramu a obsahuje informace o nasazení a následném testování systému. V páté kapitole jsou blíže popsány technologie, jež jsou použity pro implementaci. V předposlední kapitole věnované ukázkám vytvořeného systému se nacházejí náhledy obrazovek a výstupních hlášení. Práce obsahuje i závěr, který shrnuje dosažené výsledky. 4

2 Teoretická východiska Cílem této kapitoly je stručně a výstižně popsat pojmy informační systém a environmentalistika. Jelikož výstupem práce je právě environmentální informační systém pro odpadové hospodářství, je zapotřebí těmto oborům dobře porozumět. Jedná se ovšem o velmi obsáhlé oblasti lidské činnosti, proto v této práci shrnuji pouze základní poznatky. V textu jsou nicméně obsaženy odkazy na knižní i elektronické zdroje, ve kterých lze nalézt více informací. Po teoretických pojmech jsou představeny konkrétní příklady environmentálních systémů v České republice. Jedná se jak o systémy státních organizací pro sběr či poskytování informací týkajících se životního prostředí, tak i o systém Envis, jenž je pomyslným předkem systému vytvořeného v rámci této práce. 2.1 Informační systémy Informační systém může být chápán mnoha způsoby. Systém se dá považovat za množinu objektů, které mají své atributy a vztahy. Přívlastek informační potom upřesňuje definici systému tak, že vazby mezi jednotlivými objekty jsou určeny informacemi a samotné prvky se dají představit jako procesy měnící vstupní informace na výstupní za pomoci předem určeného algoritmu [2]. Na některé systémy jsou při provozu kladeny velké nároky ohledně spolehlivosti a bezpečnosti a jejich selhání může zapříčinit velkou škodu na majetku či životě. Proto vyvstala potřeba mít možnost určit jakost dodávaného systému. 2.1.1 Jakost informačního systému Mnoho firem vyvíjecích software se snaží řídit a ověřovat své procesy podle norem ISO (Mezinárodní organizace pro standardizaci) a IEC (Mezinárodní elektronická komise). V důsledku by dodržování těchto norem mělo zaručit vytvoření kvalitního softwaru. Tyto normy se ovšem stále dotvářejí a stabilizují. Vymezují šest základních charakteristik jakosti (dle ISO), které by měl splňovat nejlépe každý informační systém, tedy i Envis 2: 5

2. Teoretická východiska 1. Funkčnost systému jedná se o schopnost produktu za stanovených podmínek zabezpečit požadované funkce. 2. Bezporuchovost jinak řečeno spolehlivost produktu; je chápána jako způsobilost zajistit požadovanou úroveň výkonu v případě používání produktu stanoveným způsobem. 3. Použitelnost vlastnost vymezující míru úsilí, kterou musí uživatel vynaložit při standardním používání produktu. 4. Efektivnost neboli účinnost; schopnost produktu vyprodukovat určitý výkon s přiměřeným využitím dostupných zdrojů (procesorový čas, operační paměť). 5. Udržovatelnost vlastnost dovolující produkt opravovat či měnit na základě dodatečných požadavků. 6. Přenositelnost schopnost produktu být za stanovených podmínek umístěn do jiného prostředí a tam fungovat (jiný hardware, aplikační prostředí) [4]. 2.2 Environmentalistika Environmentalistika je vědní obor zabývající se životním prostředím. Zkoumá zejména vliv člověka na své okolí, přičemž používá poznatky z biologie, chemie, fyziky a mnoha dalších oborů. Zároveň je ale používána i jinými oblastmi lidské činnosti, a to nejen technickými a přírodovědeckými obory, ale i těmi humanitními. Životní prostředí můžeme chápat jako souhrn ekologických činitelů, které mají bezprostřední význam pro život a vývoj určitého druhu nebo pro jeho populaci. Činitelé prostředí na sebe vzájemně působí a společně vytvářejí podmínky daného prostředí, ve kterém žije určitý organismus nebo populace [5]. Existují dvě hlavní složky životního prostředí přírodní a umělé složky vytvořené člověkem. Do první kategorie spadá živá a neživá příroda, ovzduší, půda, voda, flora a fauna, zatímco do druhé obytné, pracovní a rekreační prostředí člověka. Na tyto složky působí tzv. environmentální činitelé (vnitřní nebo vnější). Tito činitelé mohou být buď přírodní jevy, nebo lidé. A právě lidské zásahy do životního prostředí 6

2. Teoretická východiska s negativním dopadem je zapotřebí kontrolovat a snažit se vytvořit takové podmínky, které budou pro okolí co nejpříznivější [5]. 2.3 Environmentální informační systémy v ČR Předchozí dvě sekce definovaly pojmy informační systém a environmentalistika. Sekce 2.3 tyto dva pojmy spojuje do jednoho a popisuje, jak jsou informační systémy užitečné v oblasti životního prostředí. Systémy tohoto rázu slouží pro sběr, uchování a následnou reprezentaci dat týkajících se životního prostředí. Může se jednat o systémy produkující reporty (například ze zákona povinná hlášení) nebo právě o systémy, které tato data shromažďují a následně vytvářejí ucelený pohled na stav životního prostředí v dané lokalitě. V ČR existuje několik environmentálních informačních systémů. Přehled těch stěžejních pro tuto práci je předmětem zbytku kapitoly teoretických základů. 2.3.1 CENIA Celým názvem Česká informační agentura životního prostředí. Její webový portál se nachází na adrese http://www.cenia.cz/. Je příspěvkovou organizací Ministerstva životního prostředí starající se o shromažďování, hodnocení, interpretaci a distribuci informací o životním prostředí na území České republiky. Agentura byla založena 1. 4. 2005 na základě rozhodnutí Ministerstva životního prostředí. Za jejího předchůdce je ale považována už Výpočetní a experimentální laboratoř (VEL) a následně začátkem 90. let založené Centrum ekologických informací (CEI), které mělo za úkol vytvořit Jednotný informační systém o životním prostředí v České republice. V současné době CENIA spravuje několik informačních serverů. Jedním z nich je Informační systém statistiky a reportingu životního prostředí, 1 dále spravuje mapové služby Portálu veřejné správy 2 a v neposlední řadě se stará o ISPOP [6]. 1. Více informací na http://issar.cenia.cz/ 2. Více informací na http://geoportal.gov.cz/ 7

2. Teoretická východiska 2.3.2 ISPOP Tento systém byl zřízen Českou informační agenturou životního prostředí pro zpracování a příjem vybraných hlášení, neboli ohlašovacích povinností, z oblasti životního prostředí v elektronické podobě a jejich další předávání institucím veřejné správy. Integrovaný systém plnění ohlašovacích povinností byl založen dle zákona č. 25/2008 Sb. v únoru roku 2008. ISPOP má sloužit jako sběrný bod pro každoroční hlášení o nakládání s odpady, které jsou původci odpadů povinni dle zákona číslo 185/2001 Sb. (viz podsekce 3.1.1) odevzdávat. Tento systém: dovoluje jeho uživatelům vytvářet hlášení pomocí specializovaných nástrojů přijímá a eviduje vytvořená hlášení poskytuje hlášení institucím státní a veřejné správy umožňuje automatizovanou strojovou výměnu informací, atd. [7] Hlášení pro systém ISPOP se posílá v elektronické podobě ve formátu XML. Je důležité, aby soubor splňoval datové standardy 3 stanovené Integrovaným systémem plnění ohlašovacích povinností. Každá položka v seznamu standardů obsahuje jeho název, přiřazení k ohlašovací povinnosti, samotný datový standard popsaný XML schématem (formát XSD) a popis datového standardu dokumentem PDF. V kontextu této práce nás nejvíce zajímá standard nesoucí název F_ODP_PROD, který je vystavěn na příloze číslo 20 nacházející se ve vyhlášce 383/2001 Sb. (viz. podsekce 3.1.2). XML schéma, které určuje strukturu souboru přijímaného systémem ISPOP, je obsáhlé, proto se v textu práce nenachází, ale je umístěno na přiloženém CD a je také ke stažení na stránkách samotného ISPOPu. Schéma říká, že výsledný XML soubor sestává ze čtyř hlavních sekcí a seznamu partnerů, přičemž povinné jsou pouze první dvě a seznam partnerů. První sekce obsahuje identifikační údaje o původci odpadů a provozovně, kde odpad vznikl. Ve druhé sekci se nachází seznam 3. Seznam datových standardů: https://www.ispop.cz/magnoliapublic/ cenia-project/uvod/datove_standardy_aktualne.html 8

2. Teoretická východiska odpadů, se kterými bylo nakládáno ve vykazovaném období. U odpadu se uvádí jeho název, kód, kategorie, množství a kód nakládání. Pokud má kód nakládání s odpady přiděleného partnera, je u odpadu uveden jeho index, který odkazuje na konkrétní identifikační údaje v seznamu partnerů. 2.3.3 ENVIS Envis 4 je systém jiné povahy než oba předchozí. Na rozdíl od nich není spravován žádnou státní organizací a neslouží pro předávání environmentálních informací veřejnosti. Slouží pro vedení odpadové evidence v organizaci s více provozovnami. Tato organizace je původcem odpadu, a je tedy dle zákona povinna podávat roční hlášení o nakládání s odpady. Systém se považuje za předchůdce Envis 2, který je předmětem této práce. Envis byl vytvořen v roce 2004 společností ECO Management s.r.o. 5 a do nynějška je jí spravován. Základní funkce systému (vytváření evidence nakládání a přepravy odpadů, správa provozoven a zpracovatelů) se do nového systému s menšími úpravami přenesly. Envis má ovšem zastaralé ohlašovací nástroje. Generované výstupy neumožňují podávání hlášení skrze systém ISPOP. Především odtud vyvstala motivace k vytvoření systému nového, který bude tuto formu podávání hlášení podporovat. Po zavedení Envis 2 v klientské organizaci, bude pravděpodobně provoz původního Envisu ukončen. 4. Nachází se na adrese http://envis.cz/rsd/ 5. Více informací na http://www.ecomanag.cz/ 9

3 Analýza Analýza je jednou ze základních praktik při vývoji informačního systému. Během ní se vytvářejí jednotlivé požadavky na systém. Díky informacím, které nám jsou prostřednictvím analýzy poskytnuty, je možné vytvořit kvalitní návrh informačního systému. V této práci požadavky vycházejí hned z několika zdrojů. Prvním jsou zákony týkající se odpadového hospodářství České republiky, kterým je věnována následující sekce. Dalším zdrojem je systém pro evidenci nakládání s odpady Envis. A posledním zdrojem požadavků jsou návrhy na vylepšení funkcionality a přívětivosti systému od uživatelů nynějšího Envisu. 3.1 Legislativa V České republice bylo přijato několik právních úprav týkajících se odpadového hospodářství. Jedná se zejména o zákon 185/2001 Sb., o odpadech a o změně některých dalších zákonů. Následují také vyhlášky 383/2001 Sb., o podrobnostech nakládání s odpady, a 381/2001 Sb., kterou se stanoví Katalog odpadů. 3.1.1 Zákon 185/2001 Sb. Tento zákon definuje základní pojmy o odpadovém hospodářství a také určuje osoby, které jsou za nakládání s odpady zodpovědné. Zákon říká, že odpad je každá movitá věc, které se osoba zbavuje nebo má úmysl nebo povinnost se jí zbavit [3]. Speciální kategorií odpadů jsou takzvané nebezpečné odpady. Jde o odpady, které mají jednu či více nebezpečných vlastností uvedených zákonem a je nutné s nimi nakládat podle stanovených pravidel. Zákon říká, že osoba zodpovědná za nakládání s odpady se nazývá odpadový hospodář. Ten odpovídá původci nebo oprávněné osobě, která jej svým odpadovým hospodářem určila, za zajištění odborného nakládání s odpady. Dále zákon upravuje práva a povinnosti původců odpadů. Například jsou povinni vést průběžnou evidenci o odpadech a způsobech nakládání s odpady, z níž jednou ročně vytvářejí hlášení. 10

3. Analýza 3.1.2 Vyhláška 383/2001 Sb. Tato vyhláška upravuje zejména způsob evidence a podávání roční zprávy o plnění povinnosti zpětného odběru. Ta může být zasílána v elektronické podobě v přenosovém standardu dat o odpadech na elektronickou adresu. Ohlašování se provádí zvlášť za každou samostatnou provozovnu, činnost, mobilní zařízení a za každý druh odpadu obecnímu úřadu obce s rozšířenou působností místně příslušnému podle místa nakládání s odpadem [8]. Důležitou součástí vyhlášky je příloha číslo 20. Jedná se o dokument zobrazující strukturu hlášení o produkci a nakládání s odpady pro obce s rozšířenou působností. Druhá polovina dokumentu definuje kódy nakládání s odpady. Envis 2 umožňuje vyprodukovat dokument právě s takovou strukturou. Jeho vzhled vytvořený nad testovacími daty je možné nalézt v příloze A této práce. 3.1.3 Vyhláška 381/2001 Sb. Vyhláška Ministerstva životního prostředí, jejímž hlavním cílem je určit druhy odpadů, které jsou původci odpadů povinni evidovat a patřičně s nimi nakládat. Definuje Katalog odpadů, který je stěžejním číselníkem v navrhovaném systému. 3.2 Hlášení o odpadech pro ČSÚ Vedle povinností vyplývajících z legislativy popsané výše musí původci zasílat každoročně hlášení o odpadech také na Český statistický úřad. Jedná se o dokument ve formátu PDF, který obsahuje stejné informace jako hlášení pro obce s rozšířenou působností vycházející z vyhlášky 383/2001 Sb. Přesto má dokument jinou strukturu a je požadováno, aby ho systém vytvářel také. V příloze B se nachází ukázka tohoto souboru, který byl vygenerován systémem Envis 2 na testovacích datech. Samotný vzor je možné stáhnout na webových stránkách Českého statistického úřadu. 11

3.3 Specifikace požadavků 3. Analýza Specifikace požadavků je reprezentace vlastností, kterými by měl navrhovaný systém disponovat, služeb, jež má poskytovat a také omezení, za kterých musí systém pracovat [9]. Požadavky můžeme rozdělit do dvou kategorií. První jsou funkční požadavky. Jedná se o určitou funkcionalitu, kterou systém nabízí (úlohy, výstupy,... ). Druhou kategorií jsou potom nefunkční požadavky. To jsou naopak omezení kladená buď během vývoje systému (cena), nebo při jeho provozu (bezpečnost). Většinu níže zmíněných požadavků (funkčních i nefunkčních) vytyčila klientská organizace, které jsem během vývoje prezentoval prvotní prototyp. Na základě konzultace s jejím představitelem byly tyto požadavky upraveny tak, aby maximálně splňovaly potřeby potenciálních uživatelů i provozovatelů systému. 3.3.1 Nefunkční požadavky Webová služba to znamená, že je aplikace nasazena na serveru a přístup k ní je zprostředkován pomocí tenkého klienta (webového prohlížeče). Tento přístup přináší mnoho výhod oproti klasickým desktopovým aplikacím. Především to, že na straně klienta není potřeba provádět žádné instalace a poté i aktualizace systému. Tyto procesy se provádí pouze na serveru. Nízké náklady na provoz provoz systému není doprovázen žádnými paušálními poplatky za licenci. Jelikož se jedná o webovou aplikaci, jakákoliv změna či aktualizace není potřeba provádět ve všech provozovnách, ale pouze na serveru. Jediným výdajem by tedy měly být poplatek hostingovému serveru. Přizpůsobený design protože jde o produkt tvořený na míru, byl prostor i k přizpůsobení designu tak, aby zapadal do tématu organizace. Tento požadavek zahrnuje volbu barevné palety, výběr ozdobných prvků a přidání korporátního loga. Nasazení na serveru organizace klientská organizace disponuje vlastními servery. Jednou z možností je nasadit systém právě na nich. Jedná se o nejlepší alternativu jak z hlediska ceny, tak z hlediska pozdější evoluce systému. 12

3. Analýza 3.3.2 Funkční požadavky Autentizace uživatelů vytvořený informační systém bude volně přístupný na Internetu. Je tedy nutné, aby neoprávněné osoby neměly se systémem umožněno pracovat. Při prvotním přístupu je každý uživatel automaticky přesměrován na přihlašovací stránku a požádán o zadání jména a hesla. Pokud jsou oba údaje validní, uživatel může vstoupit do systému. Pokud nejsou, je mu přístup odepřen a je vyzván k opětovnému zadání přihlašovacích údajů. Autorizace uživatelů podle autentizačního procesu je uživateli přiřazena role, pod kterou se v systému pohybuje. Na základě přiřazené role může uživatel pracovat v určených sekcích systému a využívat určenou sadu nástrojů. Podle role je omezena i viditelnost dat. Správa záznamů v databázi na základě tohoto požadavku je v systému umožněno přidávat, mazat a editovat záznamy. S těmito operacemi přichází i nutnost kontrolovat, zda jsou zadávány správné údaje. Pokud operace vede k vytvoření nevalidního záznamu nebo k nekonzistenci databáze, je uživatel upozorněn a vyzván k opravě vstupu, nebo je operace zakázána. Evidence nakládání a pohybu odpadů požadavek vytvořit soubor ovládacích prvků, který umožní pohodlně a efektivně vytvořit záznamy o nakládání s odpady nebo o přepravě nebezpečných odpadů. Tyto záznamy bude poté možné jednoduše kontrolovat, seřazovat, vyhledávat a filtrovat. Vytváření výstupu průběžné evidence odpadů záznamy vytvořené pomocí evidenčního systému je možné vyexportovat ve formátu PDF. Je možné položky do výsledného výstupu na základě několika parametrů filtrovat. Vytváření výstupů pro zainteresované strany jedná se o generování ročních zpráv, které jsou provozovny povinny zasílat dle zákona o odpadech (viz. podsekce 3.1.1). Existují tři formy výstupů, které je systém schopný generovat: 13

3. Analýza PDF dokument pro Český statistický úřad PDF dokument pro obce s rozšířenou působností XML dokument pro systém ISPOP Vytváření ostatních výstupů mimo povinné výstupy, kterými budou provozovny plnit svoji ohlašovací povinnost, má systém dovolovat vytvořit i následující dokumenty: Identifikační list nebezpečného odpadu poskytuje výpis vlastností opadu a všech potřebných informací pro manipulaci s odpadem. Přepravní list nebezpečného odpadu obsahuje informace o přepravě nebezpečného odpadu, jeho množství a osobách figurujících v tomto procesu. Manuál k systému a odkaz na platnou legislativu pro pohodlí uživatelů je v systému obsažen manuál. V případě nesrozumitelností je možné se z většiny obrazovek pomocí symbolu otazníku přesměrovat na relevantní nápovědu. Systém nabízí i odkazy na externí server, který poskytuje aktuální znění zákonů spjatých s odpadovým hospodářstvím v České republice. 3.4 Případy užití V této sekci je popsáno jak bude systém používán. K tomu je využito diagramu případů užití. Diagram případů užití (Use Case Diagram) se používá k popisu chování systému z hlediska uživatele a zachycuje, které typy uživatelů se systémem pracují a jaké činnosti v rámci systému vykonávají [10]. Jednotlivé případy užití (use cases) reprezentují funkční požadavky na systém, aktéři (actors) představují vnější prvky komunikující se systémem, přičemž aktér nemusí být živá osoba, ale může se jednat i o externí systém či jiný program [11]. Při vytváření nového systému se jedná o jeden z prvních výstupů. Na základě tohoto diagramu je možné hrubě určit mohutnost systému a tím i jeho náročnost na vytvoření a potažmo i náklady na vývoj. 14

3. Analýza Obrázek 3.1: Diagram případů užití Aktéři Administrátor uživatel, který bude k systému přistupovat nejméně. Jeho práva jsou neomezená, může se systémem pracovat v celém rozsahu. Předpokládá se, že administrátor bude k systému přistupovat pouze v případech nouze, nebo za ojedinělých podmínek. Vedoucí má stejné pravomoce jako administrátor. Tento uživatel by měl být v systému pouze jeden. Může kontrolovat práci svých podřízených, vytvářet za ně výstupy i evidenci o nakládání s odpady. Má přehled o všech provozovnách a může vytvářet průběžný přehled evidence za celou organizaci. Odpadový hospodář zaměstnanec provozovny, který se stará o vedení evidence nakládání s odpady. Má omezená práva k přístupu do určitých sekcí systému (může pracovat jen s daty své 15

3. Analýza provozovny a nemůže manipulovat s účty jiných uživatelů). Jde o nejpočetnější skupinu uživatelů v systému. 3.4.1 Přihlášení Interagující aktéři: Administrátor, Odpadový hospodář, Vedoucí Aktér je vyzván k zadání přihlašovacích údajů. Systém po zadání jména a hesla schválí jejich validitu, nebo je aktér vyzván k jejich opětovnému zadání. Po autentizaci následuje přiřazení role, na základě které je aktérovi umožněno pracovat s určitými úseky systému. 3.4.2 Odhlášení Interagující aktéři: Administrátor, Odpadový hospodář, Vedoucí Z jakékoliv obrazovky je aktérovi umožněno se odhlásit vzdát se práv k práci se systémem. Pokud tak učiní, je přesměrován na přihlašovací stránku. 3.4.3 Změna osobních údajů Interagující aktéři: Administrátor, Odpadový hospodář, Vedoucí Aktér má možnost upravit údaje o své osobě v databázi (příjmení, telefon,... ). Upravit může pouze údaje, které náleží identitě, pod kterou je právě přihlášen. Změna osobních údajů zahrnuje i změnu hesla. Pro změnu hesla je zapotřebí znát to stávající. 3.4.4 Resetování hesla uživatelů Interagující aktéři: Administrátor, Vedoucí Aktér může ostatním uživatelům i sobě změnit heslo. Není zapotřebí znát stávající heslo uživatele, kterému se heslo resetuje. Tento úkon by se měl provádět pouze v krajních případech. 3.4.5 Evidence odpadů Interagující aktéři: Odpadový hospodář, Vedoucí Stěžejní funkcionalita systému. Nejčastějšími aktéry jsou odpadoví hospodáři z jednotlivých provozoven. Ti celoročně vytváří záznamy 16

3. Analýza evidence nakládání s odpady. Tento případ užití je v další sekci blíže popsán pomocí diagramu aktivit. 3.4.6 Práce s nápovědou Interagující aktéři: Administrátor, Odpadový hospodář, Vedoucí V případě nepochopení funkce nebo neporozumění některým pojmům, je v systému přítomna nápověda. Informace obsažené v nápovědě jsou pro přehlednost sdruženy podle jednotlivých obrazovek uživatelského rozhraní. Z většiny obrazovek je možné pohodlně přistoupit k relevantní části nápovědy pomocí symbolu otazníku. 3.4.7 Vytváření výstupů a výběr typu výstupu Interagující aktéři: Odpadový hospodář, Vedoucí Tento případ užití umožňuje aktérům vytvářet výstupy určitých záznamů v databázi. Jedná se o výstupy popsané v podsekci 3.3.2. Odpadovým hospodářům je dovoleno vytvářet hlášení o nakládání s odpady pouze pro provozovnu, do níž spadají. Vedoucí může udělat hlášení či přehled evidence pro libovolnou provozovnu nebo pro všechny provozovny dohromady. 3.4.8 Správa číselníků Interagující aktéři: Administrátor, Vedoucí Vytváření, editace nebo mazání číselníků v systému. Jsou jimi například katalog odpadů, číselník způsobů nakládání s odpady nebo seznam základních územních jednotek České republiky. Jelikož se jedná o číselníky dané státem, neočekává se jejich editace uživateli. Aktérům v roli s plnými právy je to i přesto umožněno. 3.4.9 Správa účtů Interagující aktéři: Administrátor, Vedoucí Systém je určen pouze pro omezený počet uživatelů, kteří jsou vybráni pro práci s ním. Proto zde není žádná volná registrace, ale uživatelské účty jsou skrze tento případ užití spravovány vedoucím nebo administrátorem. Tento případ užití dovoluje aktérům vytvářet, editovat i mazat ostatní uživatele systému. 17

3.5 Nejčastější aktivity uživatelů v systému 3. Analýza Systém může být popsán pomocí procesů, jež budou uživatelé vykonávat a na jejich popis nám poslouží diagramy aktivit. Diagram aktivit je jeden z UML diagramů. Každý proces je reprezentován sekvencí kroků, které jsou v modelu zakresleny jako akce nebo vnořené aktivity. Sekvenci jednotlivých kroků v diagramu určuje řídící tok. 3.5.1 Správa záznamů Obrázek 3.2: Diagram aktivit správy záznamů Výše zobrazený diagram ukazuje aktivity provedené při správě záznamů. Seskupení akcí a aktivit můžeme rozdělit do čtyř hlavních sekcí. Vyhledávání, vytváření nových, editace stávajících a mazání již nepotřebných záznamů. Výchozí akcí je vypsání položek z databáze. Následně se uživatel rozhoduje, kterou činnost chce provést. Každá činnost obsahuje několik jednotlivých kroků a jejich validita je kontrolována systémem. Uživatel by se měl vždy na konci každého cyklu dostat zpět k výpisu záznamů. 18

3. Analýza 3.5.2 Vytváření výstupů Obrázek 3.3: Diagram aktivit vytváření výstupů Vytváření výstupů je významnou aktivitou vykonávanou v rámci systému. Není důležité, zda se jedná o průběžný přehled evidence, výstupy pro plnění ohlašovací povinnosti nebo o ostatní výstupy. Postup je vždy totožný. Nejdříve si uživatel zvolí záložku výstupu, který chce vytvořit. Následně vyplní typ, formát a ostatní údaje výstupu, například období či název provozovny. Po potvrzení údajů je automaticky vygenerován výstup. Tento cyklus se může opakovat několikrát. Aktivita je ukončena opuštěním ovládací obrazovky vytváření výstupů. 19

4 Návrh Návrh informačního systému následuje bezprostředně po analýze. Často se tyto dvě fáze překrývají. Během tohoto kroku jsou zpracovány výstupy z analýzy a na jejich základě je vybudována struktura systému. Kapitola představuje datový model, informace o vybraných číselnících a návrh uživatelského rozhraní jedné z ovládacích obrazovek. 4.1 Vybrané číselníky V této sekci blíže popisuji tabulky databáze, které jsou v systému připraveny jako výchozí. Jedná se o číselníky definované zákonem, státními organizacemi nebo ostatními externími autoritami. Jsou to právě ty číselníky, které rozvádí případ užití v podsekci 3.4.8. 4.1.1 Orp Tabulka obsahuje kódy a názvy všech obcí s rozšířenou působností (ORP) v České republice. Tento číselník byl zaveden Českým statistickým úřadem (ČSÚ) 1 a je jím aktuálně spravován. Code čtyřmístné číslo obce s rozšířenou působností s rozsahem 1000 9999. Name název ORP (Např.: Brno, Hlavní město Praha,... ). 4.1.2 Zuj V této tabulce se nachází seznam základních územních jednotek (ZÚJ). Základní územní jednotkou se rozumí taková jednotka, která se pro výkon veřejné správy již dále nečlení [12]. Jedná se o největší číselník v systému, čítající přes šest tisíc záznamů. Garantem a správcem tohoto číselníku je opět ČSÚ. ZujCode šestimístné číslo určující základní územní jednotku s rozsahem 100000 999999. 1. Více informací na http://www.czso.cz/ 20

4. Návrh Municipality název jednotky. Cznuts pětimístný řetězec znaků určující kraj jednotky dle klasifikace územních statistických jednotek. Každý kód začíná prefixem CZ následovaný třemi číslicemi. 4.1.3 Waste Číselník vymezený vyhláškou Ministerstva životního prostředí České republiky číslo 381/2001 Sb. (viz. Sekce 3.1.3). Code číslo o délce 5 až 6 číslic jednoznačně určující odpad. Description popis odpadu jehož maximální délka je 300 znaků. CategoryID jedná se o cizí klíč kategorie odpadu. Dle vyhlášky existují dvě kategorie odpadů nebezpečné a ostatní. 4.1.4 Process Tabulka databáze se způsoby nakládání s odpady. Jejich seznam je k nalezení v příloze číslo 20 vyhlášky Ministerstva životního prostředí číslo 383/2001 Sb. (viz. Sekce 3.1.2). Code tento řetězec ze tří až čtyř znaků se používá pro jednoznačné určení způsobu nakládání. První písmeno určuje původ odpadu a zbylá část kódu (písmeno a jedna až dvě číslice) označuje způsob nakládání s odpadem. Name název způsobu nakládání. Origin určuje, zda se jedná o kód používaný při definování původu odpadu nebo jeho zpracování. Bilance jednobitová hodnota. Určuje zda je množství odpadu, se kterým je nakládáno, považováno za kladné nebo záporné vůči původci. HasPartner opět jednobitová hodnota. Říká nám, jestli musí být u daného nakládání s odpady definován zpracovatel odpadu. 21

4. Návrh 4.1.5 Adr Tento číselník vymezila Evropská dohoda o mezinárodní silniční přepravě nebezpečných věcí (ADR). Byla sjednána v Ženevě dne 30. září 1957 pod patronací EHK OSN a vstoupila v platnost dne 29. ledna 1968. Tato dohoda prošla mnoha novelami a aktuální je ze dne 1. 1. 2013 [13]. Code celý kód se skládá ze tří částí oddělených mezerou: Třída je první částí a jedná se o číslo ve tvaru x nebo x.x, kde x je libovolná číslice. Další částí je obalová skupina. Jedná se o řetězec skládající se z jednoho až dvouciferného čísla a jednoho písmena. Poslední je čtyřciferné UN číslo. 4.1.6 Ycode V této tabulce jsou uvedeny kódy používané při mezinárodní přepravě odpadů. Jejich kompletní seznam je uveden v Předpisu č. 100/1994 Sb., Sdělení Ministerstva zahraničních věcí o sjednání Basilejské úmluvy o kontrole pohybu nebezpečných odpadů přes hranice států a jejich zneškodňování. Code řetězec složený z písmena Y a dvouciferného čísla označuje kategorie odpadů, které musejí být kontrolovány. Description slovní popis kategorie maximální délky 100 znaků. 4.2 Datový model Datové modelování se používá pro vytvoření datové struktury databázového serveru. Tento server je následně používán aplikací k uchovávání dat potřebných pro její práci. Samotný datový model může mít několik podob. Odlišnosti mezi nimi jsou zejména v konkrétnosti uváděných informací. Za nejabstraktnější se považuje konceptuální model, jenž obsahuje pouze základní informace o entitách a jejich vztazích. Konkrétnější je technologický model obohacující entity o jejich atributy, jako jsou například primární klíče. Implementační model se dá pokládat za 22

4. Návrh konkrétní realizaci databáze a obsahuje informace potřebné pro její vygenerování [11]. Na obrázku 4.1 se nachází technologický model databáze systému Envis 2. Jsou zobrazeny jména tabulek a jejich atributy i s datovými typy a velikostí. U atributů je vyznačené, zda se jedná o primární či cizí klíče a také zda jim musí/nemusí být přidělena hodnota (zda jsou Nullable). Vztahy mezi entitami jsou vyznačeny pomocí tzv. notace vraní nohy (Crow s foot notation) představenou Georgem Everestem v roce 1987 [11]. Tabulky databáze by se daly rozdělit do čtyř sekcí: 1. Ekonomické subjekty Tyto entity se starají o udržování záznamů, týkajících se subjektů manipulujících s opady. Řeč je o provozovnách, dopravcích a zpracovatelích odpadů. Zařazené tabulky Role, User, Company, Plant, EliminationPlant, Transporter OrganizationType, TransportType, Zuj, Orp 2. Odpady Tabulky související s katalogem odpadů a nakládáním s odpady. Spadá sem i vytváření identifikačních listů nebezpečných odpadů. Zařazené tabulky Category, Waste, Process, Ilno, Adr, FavoriteWaste, FavoriteProcess 3. Evidence Za pomoci předchozích dvou částí je systém schopný produkovat evidenci nakládání s odpady. Jednoduše řečeno se vždy přiřadí několik subjektů k odpadu a určí se, co s nimi bylo provedeno a jak. Zařazené tabulky WasteRecord, TransportRecord, TransportItem 23

4. Návrh 4. Podpůrné entity Do této kategorie se řadí ostatní entity, které mají za úkol dotvářet prostředí systému (především manuál k systému). Zařazené tabulky HelpSubject, HelpItem, Year Obrázek 4.1: Datový model databáze Envis 2 24

4.3 Návrh obrazovky výstupů hlášení 4. Návrh Modelování vzhledu uživatelského rozhraní je důležitou součástí tvorby informačního systému. Vše, s čím bude uživatel komunikovat, se vytváří během tohoto procesu. Je důležité navrhnout takové uživatelské rozhraní, které nebude složité pro použití i v případě, že uživatel systém vidí poprvé. Také je nutné, aby bylo rozložení ovládací obrazovky dostatečně intuitivní a uživatele nemátlo či nezpomalovalo. Jednou z oblíbených technik návrhu rozhraní je pomocí tzv. drátěných modelů (Wireframes). Jedná se o jednoduchý nákres, který popisuje funkcionalitu stránky a také to, jak by měla s uživatelem komunikovat. Je mnohem jednodušší prezentovat rozvržení stránky pomocí wireframe, než popisovat ho slovně [14]. Obrázek 4.2 se dá považovat za drátěný model. Vizuálně popisuje návrh obrazovky odstíněný od všech grafických prvků. Snaží se pouze sdělit, jaké ovládací prvky bude mít uživatel na stránce dostupné. Jelikož Envis 2 je prací jednoho člověka, není nutné si předávat návrh všech obrazovek tímto způsobem, ale stačí si je pouze představit. Obrázek 4.2: Wireframe obrazovky pro vytváření výstupů hlášení 25

5 Implementace Zde se zabývám samotnou implementací informačního systému Envis 2. Jsou představeny technologie použité při vývoji systému s odůvodněním, proč byly vybrány právě ony. Kapitola pojednává i o softwarové architektuře Model-view-controller (MVC) 1 a také o nasazení ukázkové verze programu na hostingový server a o jejím testování. 5.1 Použité technologie Při vývoji systému byly použity zejména technologie a nástroje společnosti Microsoft. Jedná se sice o platformě závislé řešení, jde ovšem o produkt na míru a očekává se, že pro něj bude vytvořeno optimální prostředí. Faktory mezi nimi kvalitní dokumentace, uživatelsky přívětivé programovací prostředí a velká komunita programátorů vedly k volbě technologií popsaných níže. 5.1.1 ASP.NET a MS SQL ASP.NET je webová platforma, která poskytuje všechny služby potřebné pro vytváření serverových webových aplikací na úrovni velkých podniků. Technologie ASP.NET je postavena na rozhraní.net Framework. 2 Při vývoji systému Envis 2 bylo použito jazyku C# a.net Frameworku verze 4.5. Jako optimální vývojové prostředí pro výše zmíněnou platformu je zvoleno Visual Studio. To je vytvářeno v několika verzích, jež se liší poskytovanou sadou funkcí. Od toho se samozřejmě odvíjí cena za licenci. Visual Studio je ale také vydáváno bezplatně. Jedná se o produkt nesoucí název Visual Studio Express for Web 2013, který je zcela zdarma a poskytuje základní funkce pro práci v.net. V této práci je využívána bezplatná varianta Visual Studia. 1. Více informací na https://msdn.microsoft.com/en-us/library/ff649643. aspx/ 2..NET Framework je vývojová platforma společnosti Microstoft pro sestavování aplikací pro systémy Windows. Více na https://msdn.microsoft.com/en-us/ library/ 26

5. Implementace Microsoft SQL Server 3 je dalším z produktů této americké společnosti, jehož hlavním úkolem je vytvářet a udržovat databázi. Jedná se o alternativu volně šiřitelného databázového systému MySQL od Oracle. V současné době (květen 2015) se MS SQL nachází ve verzi 12.0 (SQL Server 2014). 5.1.2 CSS & LESS CSS je zkratkou Cascading Style Sheets, česky kaskádové styly. Byl vyvinut později než HTML s cílem vymýtit z jazyka HTML jakékoli prezentační (tzn. vzhledové) prvky. CSS samotný poskytuje vše podstatné pro určení vzhledu kterékoli části WWW stránky [15]. CSS má několik nedostatků. Pokud se kód stylů stane mohutným, jeho správa je složitá. Řešením je použití preprocesoru LESS, 4 jehož autorem je Alexis Sellier. LESS se dá představit jako nástavba kaskádových stylů přinášející možnost vytvářet proměnné, jmenné prostory, pohodlně pracovat s barevnou paletou a matematickými funkcemi. Také je možné importovat jednotlivé LESS soubory do sebe a tím docílit ještě větší dekompozice kódu. Ukázka 5.1: Část.less souboru se styly pro Envis 2: @primarycolor: #09457A; @secondarycolor: #0096DC; @primarylight: hsl(hue(@primarycolor), 100%, 60%); @primarydark: hsl(hue(@primarycolor), 55%, 40%); @borderpd: 1px solid @primarydark;....btnstyle(@border, @radius, @mixincolor, @textcolor, @textcolorhover) { margin: 4px 2px 4px 2px; border: @border; border-radius: @radius;.gradient(@mixincolor); 3. Více informací na http://www.microsoft.com/cs-cz/server-cloud/ products/sql-server/ 4. Více informací na http://www.lesscss.cz/ 27

5. Implementace a{ color: @textcolor; font-weight: bold; } &:hover{ a~{ color: @textcolorhover;.hovereffect(@mixincolor); border-radius: @radius; } } }....navbar-nav { li{.btnstyle(@borderpd, 0, @primarydark, white, white); a~{ padding: 10px 5px 10px 5px; } } V ukázce je vidět ukládání hexadecimálního kódu barev do proměnných, které jsou použity v dalších částech souboru. Následující úsek (.btnstyle) se nazývá mixin. Ten sdružuje definice stylů a může být později zavolán v rámci konkrétního určování stylu s různými parametry. Tím se opět zamezuje častému opakování kódu. Volání mixinu je zachyceno v poslední části ukázky 5.1. V tomto případě jde o určení vzhledu tlačítka hlavního menu. Nicméně, ani moderní webové prohlížeče neumí pracovat se soubory.less, proto je nutné je převést opět do jazyka CSS. Existuje široká nabídka nástrojů pro splnění tohoto účelu. Při vývoji systému Envis 2 je použit kompilátor WinLess, 5 optimalizovaný pro prostředí operačního systému Windows. 5. Více informací na http://winless.org/ 28

5. Implementace 5.1.3 Ostatní Veškerý obsah viděný uživatelem systému Envis 2 je vytvořen pomocí jazyka HTML. Zdrojové soubory ovšem neobsahují čisté HTML. Jsou rozšířeny šablonovým jazykem Razor (viz. Podsekce 5.2.2). Dalším jazykem použitým při vývoji je JavaScript. V rámci této práce je JavaScript využíván spíše okrajově prostřednictvím knihoven třetích stran. Zejména potom front-end knihovnou Twitter Bootstrap. 6 5.2 Architektura MVC v kontextu ASP.NET Celým názvem Model-view-controller je architektura snažící se oddělit datový model Model, uživatelské rozhraní View (Pohled) a řídící logiku aplikace Controller (Řadič) do tří nezávislých částí. Tím by se mělo zaručit, že kód bude přehlednější a změna jedné komponenty bude mít co nejmenší vliv na zbývající dvě. Tato architektura je podporována platformou ASP.NET MVC, jež se v současné době (květen 2015) nachází v ustálené verzi 5.2.3 a v beta verzi 6. V kontextu.net frameworku se jedná o alternativní přístup oproti dříve vyvinutým WebForms. 7 U Envis 2 je zvoleno MVC spíše kvůli osobním preferencím, jelikož v obou případech se dá najít několik kladů i záporů. 5.2.1 Model číselníku Ycode První částí celku je model. Jedná se o komponentu, jež zajišťuje reprezentaci informací v systému a poskytování byznys logiky. Jeho hlavní úlohou je komunikace s databází, vydávání dat a ukládání nových. Je v něm specifikována struktura dat a zároveň i validační mechanismy. Ukázka 5.2: Model Y-kódu: public class Ycode { public int YcodeID { get; set; } [Required(ErrorMessage = "Tato položka je povinná.")] 6. Více informací na http://getbootstrap.com/ 7. Více informací na http://www.asp.net/web-forms/ 29

[Display(Name = "Kód")] [RegularExpression(@"Y([0-9]{2})", ErrorMessage = "Zadejte platný kód Y-kód.")] public string Code { get; set; } 5. Implementace } [Required(ErrorMessage = "Tato položka je povinná.")] [Display(Name = "Popis")] [MaxLength(100, ErrorMessage = "Limit 100 znaků.")] public string Description { get; set; } Důležitou částí kódu jsou jednotlivé datové anotace (DataAnnotations) v hranatých závorkách. Pomocí takto definovaných výrazů se dají určit omezení pro záznamy v databázi. Tato omezení jsou za běhu aplikace automaticky vyhodnocována a systém tak ošetřuje vstupy uživatelů. Při vytváření systému bylo použito Entity Framework verze 6.1.1. 8 Díky tomu je možné skrze model vytvořit schéma databáze. Tento přístup se nazývá code first. 9 Například z modelu Y-kódu (viz. Ukázka 5.2) se v databázi vytvoří tabulka se třemi sloupečky YcodeID, Code a Description. Ta může být následně naplněna záznamy. 5.2.2 Pohled uživatelských rolí Pohled se stará o vykreslení celého obsahu uživatelského rozhraní. Prostřednictvím řadiče přebírá data vyprodukovaná modelem a vytváří obsah stránky/obrazovky. Také předává informace o chování a požadavcích uživatele zpět do řadiče, který na základě předem definovaného scénáře opět provede aktualizaci pohledu. 8. Více informací na https://msdn.microsoft.com/en-us/data/ef.aspx 9. Přehled možných přístupů vytváření databáze a jejich výhody shrnul Ladislav Mrnka na serveru stackoverflow.com: http://stackoverflow.com/a/5446587 30

5. Implementace Ukázka 5.3: Kód pohledu detailů rolí: @model EvidenceSystem.Models.Role @{ ViewBag.Title = "Detaily"; } <h2>detaily</h2> <div class="body-section"> <div> <h4>role <a href="@url.action("manual", "Manual", new { subjectid = 20})">? </a></h4> <hr /> <dl class="dl-horizontal"> <dt>@html.displaynamefor(model => model.name)</dt> <dd> @Html.DisplayFor(model => model.name)</dd> </dl> </div> <p>@html.actionlink("zpět na výpis", "Index")</p> </div> <div class="body-section"> <h4>uživatelé</h4> <table class="table"> <tr> <th>jméno</th> <th>provozovna</th> </tr> @foreach (var item in Model.Users) { <tr> <td> @Html.DisplayFor(modelItem => item.wholename) </td> <td> @Html.DisplayFor(modelItem => item.plant.entirename) </td> </tr> } </table> </div> 31

5. Implementace Na ukázce je vidět HTML kód pohledu, který je obohacen o prvky šablonového jazyka Razor (řádky začínající symbolem @). 10 Díky tomuto rozšíření značkovacího jazyka HTML je umožněno vytvářet dynamický obsah stránky. 5.2.3 Řadič pro obsluhu přihlašování Poslední komponentou je controller neboli řadič. Zde se nachází zejména funkční část kódu. Právě řadič reaguje na příkazy uživatele a podle nich aktualizuje model i pohled. Mezi dvěma předchozími částmi funguje jako prostředník. Ukázka 5.4: Část kódu Account řadiče: public class AccountController : BaseController { EvidenceSystemContext Context = new EvidenceSystemContext(); // // GET: /Account/ [AllowAnonymous] public ActionResult Login() { return View(); } [HttpPost] [AllowAnonymous] public ActionResult Login(LoginViewModel model, string returnurl = "") { if (ModelState.IsValid) { var user = Context.Users.Where(u => u.username == model.username && u.password == model.password).firstordefault(); 10. Více informací na http://www.w3schools.com/aspnet/razor_intro.asp 32

... 5. Implementace if (user!= null && user.plantid!= null &&!user.plant.active) { ModelState.AddModelError("", "Vaše provozovna je neaktivní! Nebudete se moci přihlásit."); } if (user!= null) { var role = user.role.name; CustomPrincipalSerializeModel serializemodel = new CustomPrincipalSerializeModel(); serializemodel.userid = user.userid; serializemodel.firstname = user.firstname; V kódu řadiče se nachází dvě metody. Obě obsluhují obrazovku přihlášení. První se stará o iniciální vykreslení pohledu, druhá již obsluhuje akce uživatele. Druhý řadič obsahuje sekvenci příkazů, jenž na základě vstupních hodnot (jméno a heslo) vyhodnotí, zda se jedná o zaregistrovanou osobu. Pokud ano, umožní jí vstup do systému. V opačném případě je přístup odepřen a řadič si vyžádá opakované zadání údajů. 5.3 Nasazení a testování V současné době (květen 2015) je funkční prototyp systému naprogramován a nachází se ve fázi testovacího provozu. Envis 2 je volně přístupný na adrese http://envis2.aspone.cz. Systém je napojený na databázi, která obsahuje testovací data. Je možné si vyzkoušet veškerou funkcionalitu od přihlášení až po vytvoření hlášení. Do systému je možné se přihlásit pomocí jména admin a hesla 123456789. Tento uživatel má přidělena veškerá práva k práci se systémem. Pro přihlášení do role, která má omezená práva a může pracovat pouze se záznamy své provozovny, lze použít uživatelské jméno worker s heslem 123456789. 33

5. Implementace Během implementace byl systém průběžně testován. V několika fázích vývoje se na testování podíleli i fiktivní uživatelé. Jednalo se jak o zástupce klientské organizace, tak o studenty Masarykovy univerzity. Díky jejich procházení si jednotlivými kroky tvorby evidence a následného generování výstupů vzešlo mnoho užitečných poznámek, které vedly k úpravám na několika místech uživatelského rozhraní. Poté, co bude systém otestován na této dočasné doméně a uznán vedením klientské organizace vhodným nástrojem pro tvorbu odpadové evidence, lze počítat s jeho nasazením na jejích serverech. V takovém případě by bylo nutno zaškolit personál, který by systém obsluhoval. 34

6 Ukázky Envis 2 Cílem této kapitoly je prezentovat vzhled vytvořeného informačního systému. Funkční demoverze programu je přístupná na adrese uvedené v sekci 5.3. Zdrojový kód systému je umístěn na přiloženém CD. Ukázky výstupních dokumentů, které Envis 2 produkuje a jejichž prostřednictvím se plní ohlašovací povinnost původce odpadů, se nacházejí v přílohách práce. Všechny obrazovky (kromě přihlašovací) disponují navigačním menu v záhlaví. Pomocí něj se dá směřovat do kterékoli sekce v systému. Obrazovky mají obdobný vzhled a jsou laděny do barev klientské společnosti. Na obrázku 6.1 je možné vidět zobrazení položek z databáze. Jedná se o výpis dat z tabulky Ilno (viz. sekce 4.2). Náhled je rozdělen do dvou částí. První část umožňuje filtrovat výpis dle parametrů. Druhá obsahuje záznamy s možností je upravovat, mazat a vytvářet nové. Obrázek 6.1: Obrazovka výpisu záznamů identifikačních listů n.o. Obrázek 6.2 ukazuje, jak je možné záznamy vytvořit nebo editovat už existující. V tomto případě jde o vytváření položky evidence odpadů. Pomocí textových oken a rolovacích nabídek se nastaví veškeré potřebné informace o nakládání s odpadem, aby mohl být záznam později zpracován a zahrnut do ročního hlášení pro ISPOP nebo ČSÚ. 35