Analýza, návrh a implementace informačního systému pro CRM

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Analýza, návrh a implementace informačního systému pro CRM Komárek David Vedoucí práce: Ing. Semrád Josef Studijní program: Elektrotechnika a informatika, strukturovaný, navazující magisterský Obor: Výpočetní technika leden 2011

2

3 iv

4 Poděkování Děkuji panu Ing. Josefu Semrádovi za poskytnutou pomoc při tvorbě diplomové práce, za jeho čas, který mi věnoval při konzultacích. Velký dík také patří panu Ing. Pavlovi Krbálkovi, vedoucímu Kompetenčního centra Generali Development s.r.o., za to, že mi umožnil pracovat na tak zajímavém a komplexním projektu. v

5 vi

6 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze poklady uvedené příloze seznamu. Nemám závažný důvod proti použití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Hradci Králové dne 29. prosince vii

7 viii

8 Abstract The main goal of this thesis is analysis, proposal and implementation of the information system facilitating communication of the insurance company. Realized system will be intended for company staff as compensation of correspondence. This thesis includes the part describing existing solutions of this area. Abstrakt Předmětem této práce je analýza, návrh a implementace informačního systému usnadňujícího komunikaci poboček pojišťovací společnosti. Implementovaný systém plně poslouží zaměstnancům společnosti jako náhrada ové korespondence. Součástí práce je i porovnání stávajících řešení z této oblasti na trhu. ix

9 x

10 Obsah Obsah...xi Seznam obrázků...xiii Seznam tabulek...xv 1. Úvod Popis problému Hlavní cíle Struktura práce Existující řešení Rozšířitelný software Open-Source řešení Firemní řešení Komerční software Vývoj vlastní aplikace Závěr Analýza Úvodní studie Deklarace záměru Odborný článek Pracovní název Analýza a záznam požadavků Business Process Model Funkční požadavky Nefunkční požadavky Uživatelské role Případy užití a scénáře Harmonogram práce (Ganttův diagram) Odhad pracnosti a rozpočtu projektu Analýza rizik Návrh Technologie a prostředky Typ aplikace Datové úložiště (databáze) Volba vývojového prostředku programovací jazyk Aplikační server Volba vývojového prostředí Volba nástroje pro správu zdrojových kódů Ostatní použité prostředky Architektura Databázová vrstva (Database layer) Datová vrstva (Data Access layer) Servisní vrstva (Service layer) Prezentační vrstva (Presentation layer) Doménový model tříd Návrh uživatelského rozhraní Plán testování xi

11 4.6 Plán nasazení Rozdělování požadavků dle zatížení (Load Balancing) Sdílení dat produkčními servery Implementace Aplikační framework Struktura zdrojového kódu Konfigurace Lokalizace Připojení externích knihoven Uživatelské rozhraní Struktura obrazovek Šablony Ukázky uživatelského rozhraní Datová vrstva Mapování datového zdroje DAO Aplikační logika Servisní vrstva Implementační problémy a jejich řešení Nezobrazení lokalizovaných textů při Ajax validaci Klauzule GROUP BY v Criteria API Identifikace znovupoužitelného kódu Klasifikační jádro Strom klasifikací Testování Konfigurace testovacího prostředí Testovací subjekty Výsledky testování Závěr Srovnání s existujícími řešeními Možnost vývoje další verze Shrnutí práce Literatura Seznam použitých zkratek Příloha A. Obsah přiloženého CD Příloha B. User manual Příloha C. Administration manual xii

12 Seznam obrázků Obrázek 1: Hierarchie mandantu Obrázek 2: BPMN - životní cyklus tématu Obrázek 3: Hlavní funkční požadavky Obrázek 4: Podrobný popis požadavků Obrázek 5: Vedlejší funkční požadavky Obrázek 6: "Nice to have" požadavky Obrázek 7: Hierarchie uživatelských rolí Obrázek 8: UC - Přihlášení uživatele do systému Obrázek 9: Diagram aktivit - Kontrola přístupu uživatele do mandantu Obrázek 10: UC - Vyhledávání témat Obrázek 11: UC - Vytvoření hierarchie mandantu Obrázek 12: Sekvenční diagram - Automatický dávkový import Obrázek 13: Ukázka Ganttova diagramu Obrázek 14: Metoda UCP v Enterprise Architect Obrázek 15: Délka trvání implementační fáze dle GD Obrázek 16: Vícevrstvá architektura aplikace Obrázek 17: Ukázka návrhu služeb servisní vrstvy Obrázek 18: Analytický model tříd - Vztahy třídy Téma Obrázek 19: Analytický model tříd - Hierarchie klasifikací Obrázek 20: Analytický model tříd - Uživatelé a uživatelské role Obrázek 21: Analytický model tříd - Logování událostí Obrázek 22: Návrh UI (EA) - Přehled témat a menu Obrázek 23: Návrh UI (Pencil) - Přehled témat a menu Obrázek 24: Návrh UI (EA) - Vytvoření nového tématu Obrázek 25: Návrh UI (Pencil) - Vytvoření nového tématu Obrázek 26: Diagram nasazení systému Obrázek 27: Aplikační framework Obrázek 28: Návrh obrazovky - Uživatelský profil Obrázek 29: Konečná obrazovka - Uživatelský profil Obrázek 30: Návrh obrazovky - Vyhledávání témat Obrázek 31: Konečná obrazovka - Vyhledávání témat Obrázek 32: Rozhraní a implementace DAO Obrázek 33: Znovupoužitelný kód - klasifikační jádro xiii

13 xiv

14 Seznam tabulek Tabulka 1: Scénář přihlášení uživatele do systému Tabulka 2: Scénář vytvoření mandantu Tabulka 3: Scénář připojení uživatele do mandantu Tabulka 4: Odhad trvání projektu na základě harmonogramu práce Tabulka 5: Odhad složitosti realizace aktérů v systému Tabulka 6: Odhad složitosti případů užití Tabulka 7: Výpočet technického faktoru Tabulka 8: Výpočet faktoru prostředí Tabulka 9: Výsledný odhad délky práce a ceny projektu Tabulka 10: Srovnání verzovacích systémů SVN a CVS xv

15 xvi

16 1. Úvod Elektronická pošta je bezesporu jedním z nejpoužívanějších komunikačních prostředků ve firmách, společnostech či u běžných uživatelů počítače a internetu. Přesto není pro určité druhy komunikací vhodným nástrojem a je potřeba využít jiné řešení či vyvinout vlastní systém. Mezi takové druhy komunikace patří například zasílání privátních dokumentů, citlivých dat, soukromých zpráv či obsahově velkých souborů. Tato práce popisuje případ, pro který je právě nutné vyměnit ovou komunikaci za lepší řešení. 1.1 Popis problému Zaměstnanci rozsáhlé pojišťovací společnosti pracující na pobočkách po celé střední a východní Evropě si musí zasílat mnoho zpráv týkajících se jejich činnosti. Je to jejich každodenní rutina. Jedná se o výkazy práce, statistiky poboček za určitá období, privátní dokumenty, dotazy, upozornění na blížící se termíny, připomínky či jiné informace. Právě zasílání privátních dokumentů em není nejvhodnější variantou, neboť nelze plně zaručit jejich zabezpečení při přenosu. Obecně pak nelze zaručit doručení jakéhokoliv u, kontrolovat, zda jsou uvedeni správně všichni příjemci (při rozposílání kopie několika uživatelům či skupinám zároveň) či zda není uveden příjemce, který zprávu obdržet nemá. Těchto problémů samozřejmě existuje mnoho a platí, že čím složitější je struktura uživatelů a přenášených dat, tím více se vyskytne chyb způsobených lidským faktorem. Tyto chyby tedy musí být eliminovány prostředkem, který zaručí dostatečnou bezpečnost komunikace, přístup k němu nebude složitý pro uživatele a poskytne uživateli minimálně všechny funkce, které stávající elektronická komunikace podporovala. Konkrétní příkladem takového prostředku a jeho vývojem se zabývá tato práce. 1.2 Hlavní cíle Mezi hlavní cíle projektu patří: - vývoj či výběr kvalitního informačního systému, který umožní uživatelům snadnou a rychlou komunikaci, - zajištění bezpečnosti uživatelského přístupu, komunikace a přenosu dat mezi uživateli - umožnit uživateli přístup k systému z jakéhokoliv místa na světě (uživatelská autentizace a autorizace), - možnost připojení velkého počtu uživatelů k systému bez ztráty rychlosti odezvy, - zajistit rychlou časovou odezvu systému, - uživatelsky příjemné prostředí a snadná práce se systémem, - informovanost uživatelů o provedených akcích a událostech v systému (notifikace), 1

17 - nezávislost chodu vyvíjeného systému na operačním systému, - zajistit úložný prostor a správu pro velké množství dokumentů, - validace vstupních dat dle zadaných podmínek, - využití objektově orientovaného přístupu v případě návrhu a následné implementace systému, - možnost snadného zdokonalování a vývoje nových prvků systému použitím moderních technologií, frameworků, známých implementačních vzorů a jiných použitelných prostředků, - snadné zavedení a nasazení nových funkcionalit a oprav v co nejkratším čase. 1.3 Struktura práce Práci lze rozdělit do několika oblastí, které směřují k úspěšnému získání řešení na základě vytyčených cílů: 1. Rozbor existujících řešení Popis existujících řešení, jejichž vlastnosti a možnosti odpovídají minimálně základním požadavkům na cílový systém. 2. Analýza požadavků na cílový systém Úvodní studie, definice hlavních, vedlejších a nice to have požadavků a tvorba business procesů vycházejících z jednání se zadavatelem projektu. Dále tvorba případů užití s popisnými scénáři, analýzy rizik a odhadu pracnosti a rozpočtu. Popis pomocí metod moderní analýzy software s využitím diagramů, dokumentů a jiných výstupů standardu UML 2.1 a BPMN notace. 3. Návrh konkrétního řešení vycházejícího z analýzy Návrh možného řešení vývoje informačního systému splňujícího všechny kladené požadavky, které byly zmíněny v kompletní analýze. Do návrhu patří tvorba prvotních náhledů obrazovek aplikace, tvorba detailního prototypu uživatelského rozhraní, sestavení doménového modelu, plán testování a nasazování systému a návrh realizace řešení (architektura, dokumentace, návrhové vzory apod.). Návrh realizován pomocí standardu UML 2.1 a nástroje pro tvorbu prototypu uživatelského rozhraní. Součástí je i diskuze alternativ z oblasti implementačních, analytických a správních prostředků zjednodušujících vývoj systému a výběr nejvhodnějších z těchto prostředků. 2

18 4. Implementace vyvíjeného systému Popis implementace informačně-komunikačního systému na základě vytvořeného návrhu projektu pomocí vybraných implementačních prostředků. Dále rozbory a řešení stěžejních úloh a problémů při implementaci. Ukázky zdrojových kódů včetně jejich popisu a management znovupoužitelného kódu. 5. Testování implementovaného systému Rozbor průběhů testování stanovených dle plánu (kapitola 4.5). Popis výsledků testování a vyslovení závěrů na základě hodnocení těchto testů. 6. Shrnutí a zhodnocení celé práce Zhodnocení úspěšnosti vývoje projektu a splnění hlavních cílů. Popis získaných zkušeností autora při práci a možností rozvoje (vývoj nových verzí) vytvořeného díla. Popis možností dalšího rozvoje projektu. 3

19 4

20 2. Existující řešení 2.1 Rozšířitelný software Jedná se o software, pluginy, části aplikací a různé vývojové frameworky, ke kterým je poskytován zdrojový kód a je možné jej doplnit o vlastní funkcionalitu. V případě neznalosti zdrojových kódů či dokonce programovacího jazyku, ve kterém je software napsán, je ale těžké rozšířit stávající řešení vlastní implementací a to trvá někdy déle než vývoj vlastní aplikace od počátku. Rozšířit vlastní logikou lze otevřené zdrojové kódy, které lze najít na internetu nebo je možné odkoupit zdrojové kódy již existujících aplikací disponující podobnou funkcionalitou od jiných vývojových týmů. Pokud má společnost, ve které je aplikace vyvíjena, vlastní informační středisko (IT sektor), je možné využít používaných frameworků či hotových řešení z jiných firemních projektů (tímto se ušetří nejen čas, který je spotřebován na tvorbu, ale i finance, které by byly vynaloženy na koupi cizích software). Pro vývoj aplikace by bylo vhodné nalézt řešení, které optimálně disponuje: - správou uživatelů a jejich rolemi v aplikaci (oprávnění definovaná na co nejnižší úroveň prvků v aplikaci), - možností spravovat a ukládat dokumenty, texty a jiné podklady, - správou témat a příspěvků v uživatelsky definovaných strukturách (kategorie, podkategorie apod.), - podporou ové komunikace (odesílání ů a notifikací), - přenositelností (aplikace nezávislá na operačním systému). Řešení, které by ovšem vyhovovalo všem těmto podmínkám lze těžko nalézt. Požadovaná aplikace má navíc dost specifické požadavky na její vývoj, proto je nutné se s nároky značně uskromnit. Mezi hledaná řešení se řadí diskuzní internetová fóra, systémy pro správu obsahu (DMS, CMS) či různé redakční systémy Open-Source řešení Řešení s open-source kódem existuje na internetu určitě mnoho, a proto je důležité vybírat z těch nejlepších a pokud možno logikou nejbližších k cílové aplikaci. Problémem open-source řešení je to, že není zaručen bezchybný běh systému. I když jsou velmi dobře testované komunitou, obsahují mnoho registrovaných (i neregistrovaných) chyb. 5

21 phpbb Projekt šířený přes GNU/GPL open-source licenci poskytuje snadno a detailně nastavitelné internetové fórum. Skrze příjemné administrační rozhraní lze nastavit vzhled, strukturu, práva přes uživatelské role, uživatelské skupiny a jiná nastavení. Systém podporuje odesílání ových upozornění, upload souborových příloh k tématům či rozšířené vyhledávání témat. Tento software je naprogramován v jazyku PHP s možností připojení k různým databázovým systémům (MySQL, MS SQL, PostgreSQL, Firebird, SQLite, Access DB atd.) Výhodou je i snadná instalace, které netrvá déle než pět minut. [1] Bohužel phpbb umožňuje vkládat témata pouze do jedné kategorie či podkategorie (do jedné struktury). Toto téma tedy nemůže být sdílené více kategoriemi. Z požadavků kladených na cílovou aplikace plyne, že je potřeba sdílet témata ve více kategorizacích (musí existovat dva typy struktur - kategorie/podkategorie a země/společnost). Téma je pak uloženo jak v kategorii (podkategorii), tak v zemi a společnosti. Vanilla [2] Další z velmi používaných diskuzních fór šířených pod licencí GPL2. Systém je naprogramován také v PHP a jako úložiště využívá MySQL databázi. Systém je kompatibilní s většinou nových internetových prohlížečů a díky popularitě vytvořila komunita pro tento systém mnoho přídavných doplňků. Vanilla je nastavitelná přes user-friendly administrační rozhraní, ale nastavitelnost není tak detailní jako v případě phpbb. Drupal [3] Volně šířitelný systém pro správu obsahu pod licencí GNU/GPL naprogramovaný v jazyku PHP s připojením k databázi MySQL či PostgreSQL. Velkou výhodou je modularita tohoto systému, lze vybírat z modulů pro tvorbu: - článků, - statických stránek, - diskuzních fór, - blogů, - přidávání příspěvků k obsahu. Další moduly lze stáhnout z internetu. 6

22 XMB (extreme Message Board) [4] Kvalitní open-source fórum naprogramované taktéž v jazyku PHP. Podporuje organizaci témat do diskuzí, subdiskuzí a kategorií. Výhodou je snadná správa uživatelů a nastavení pravidel pro používání fóra. Uživatelé mezi sebou mohou komunikovat prostřednictvím zpráv. Fóra či kategorie je možné moderovat. Pro každé fórum lze nastavit vlastní vzhled, což je také výhoda Firemní řešení Ve společnosti lze využít server/klient nástroje Lotus Notes/Domino od firmy IBM. Vzhledem k tomu, že je instalován jako firemní software pro každého uživatele, není problém s placením speciální licence. Lotus Notes je využíván jako klientská část pro přístup k serverové části Lotus Domino (robustní aplikační server). Produkt Lotus disponuje dokumentovou databází (základní jednotka je dokument). Pro vývoj aplikací je využitelný nástroj Lotus Designer. Lotus Notes spadá do oblasti RAD - Rapid Application Development, což znamená, že v Lotusech lze rychlým způsobem naimplementovat aplikaci. K vytvořené aplikaci lze přistupovat právě přes Lotus Notes nebo přes řadu podporovaných služeb (IMAP, HTTP, LDAP apod.) a standardů (HTML, XHTML, XML, Java). [5] Mezi hlavní výhody produktu Lotus patří vysoká úroveň zabezpečení dat, replikace, snadná rozšířitelnost, rychlý vývoj a aplikace business procesů ve workflow (automatizace procesů, tok dat od uživatele k uživateli, přiřazování úkolů a odpovědnosti). 2.2 Komerční software Microsoft SharePoint SharePoint je rodina softwarových produktů vyvíjených známou společností Microsoft. Jedná se o balík několika produktů, které slouží k usnadnění spolupráce, ke sdílení souborů či k webovým publikacím. Hlavními produkty jsou SharePoint Server, SharePoint Foundation, Search Server a SharePoint Designer. ViewPoint Document Manager [6] Document manager je jedním z řešení softwarového balíku podporujícího obchodní služby ViewPoint. Tento nástroj poskytuje do detailu nastavitelné úložiště pro soubory, správu uživatelů, úkolů či generování dokumentů a ových notifikací. ová komunikace v aplikaci Document Manager velmi kvalitně podporuje ové klienty Microsoft Outlook a Lotus Notes. 7

23 Document Manager je úložištěm pro soubory jakéhokoliv formátu s podporou plánování akcí s těmito soubory či úkoly. Nechybí ani základní práce s obrázky (náhledy, rotace apod.) či indexování dokumentů a jejich linkování. Aplikace integruje podporu základních aplikací sady MS Office jako Word, Excel či Outlook. Dále pak aplikace Lotus Notes a Groupwise. Aplikace je obecně velmi přizpůsobitelná, proto lze spoustu aplikačních dat upravovat (vytvářet nové typy úkolů, tvorba vlastních sestav, workflow procesů apod.). Velmi vhodným doplňkem je pak dávkový import dokumentů či souborů a nastavení automatických akcí nad dokumenty či úkoly. Základním rozhraním je desktopová aplikace, ale existuje také možnost webové verze, která je přístupná odkudkoliv. 2.3 Vývoj vlastní aplikace K tomuto řešení lze přistoupit, pokud má firma kapacitu na vývoj složitější aplikace, která zabere nemálo času věnovaného analýze, návrhu, implementaci, testování a potřebné podpoře. Firma se zkušenými programátory má zaběhnuté principy v programování a jiných činnostech s vývojem souvisejících. Programátoři staví na technologiích osvědčených v jiných projektech a vývoj tedy není tak těžkopádný (učení se nového jazyka, komunikace apod.). Toto řešení ovšem může zabrat mnoho času a peněz do vývoje vynaložených. 2.4 Závěr Začít s vývojem nové aplikace od počátku se zdá být úkolem, který zabere nejvíce času. Ovšem, vzhledem k detailním požadavkům vedoucím k naprosto unikátní aplikaci s mnoha specifikami, které jen těžce odvodit od již existujících vzorů, je takový vývoj nutný. Tímto ovšem není neopomíjena možnost využít již existující frameworky, vzory či pomocné utilitky, které vývoj nejen urychlí, ale také zjednoduší. Vzhledem k tomu, že analýza požadavků tohoto projektu a jejich zpracování do chápatelné podoby zabere ve všech zmiňovaných případech stejný čas, je důležité zaměřit se na odhad délky trvání samotné implementace. Vůči stávajícím řešením, která je potřeba rozšířit či jinak upravit, můžeme dojít k závěru, že vývoj nové aplikace zabere více času stráveného nad implementací. Tento čas ovšem nebude dle odhadu o tolik delší oproti implementaci rozšíření stávajících řešení. Z tohoto důvodu a z důvodu nenalezení ideálně rozšířitelného řešení z internetu či trhu bylo rozhodnuto o vývoji vlastní nové aplikace. 8

24 3. Analýza Analýzou, v případě této práce, se myslí sběr co nejvíce podstatných i nepodstatných informací a požadavků na systém zadaných zadavatelem a jejich následné zpracování do podoby, ze které vzejde kvalitní návrh software. Další důsledek získání zadání uvádí následující tvrzení 1 : Proces získávání zadání je vhodným okamžikem k navázání vztahů s uživatelskou základnou, kdy bychom měli začít zkoumat očekávání uživatelů a jejich naděje spojené s vytvářeným systémem. Základem kvalitního vývoje software je samozřejmě kvalitní analýza, proto byl v této práci kladen důraz na její kvalitu a zpracování. Z toho důvodu se doba zpracování analýzy přiblížila ke třem měsícům práce. K uvedeným analytickým metodám jsou zobrazeny pouze ukázky vytvořených diagramů, popisů a jiných výstupů, všechny výstupy jsou obsaženy na přiloženém CD. 3.1 Úvodní studie Obsah úvodní studie vychází z jednání se zadavatelem. Na základě těchto schůzek bylo možné deklarovat záměr projektu a sepsat odborný článek Deklarace záměru Cílem projektu je výběr či vývoj řešení softwarového produktu sloužícího pro komunikaci uživatelů předáváním zpráv a dokumentů. Cílovou skupinou jsou pracovníci různých oddělení pojišťovací společnosti. Většina z těchto uživatelů pracuje na počítači a s internetem se základní úrovní dovednosti. Vzhledem k tomu, že uživatelé pochází z různých zemí střední a východní Evropy, je nutné, aby byla aplikace přeložitelná do více jazyků (primárně jazyk anglický) Odborný článek Zaměstnanci oddělení pojišťovací společnosti vykazují velké množství dat týkajících se jejich práce, jejichž sběrem lze ohodnotit a analyzovat úspěšnost či neúspěšnost tohoto oddělení jako celku. Takovému oddělení se říká mandant. Většina mandantů má své zastoupení v každé zemi. V rámci každého mandantu je pak možné sbírat různé statistiky za jednotlivá období roku (čtvrtletí, pololetí, celoroční), plánovat úkoly do příštího období z důvodu synchronizace poboček či zasílat průběžné informativní reporty. 1 HUNT, Andrew; THOMAS, David. Programátor pragmatik : Jak se stát lepším programátorem a vytvářet kvalitní software. Brno : Computer Press a.s., s. ISBN

25 Cílem projektu je tedy realizace informačního systému umožňujícího správu mandantů a komunikaci v nich. Komunikace probíhá pomocí témat, která svým typem a názvem upřesňují, co je po zaměstnancích vyžadováno (požadavek na zaslání čtvrtletní statistiky, dotaz ohledně korektnosti zaslaných dokumentů, dokumentace, informativní témata apod.). Do každého tématu lze vkládat příspěvky s textem a přílohami (soubory se statistikami, dokumenty, manuály). Téma s příspěvky a přílohami lze vložit pomocí stránky s formulářem či pomocí importní XML dávky s patřičnými informacemi a odkazy na souborové přílohy. Struktura témat je definována pomocí různých typů tzv. klasifikací. Každé téma musí patřit do jedné klasifikace od typu Kategorie, Podkategorie a Země a také do jedné či více klasifikací typu Společnost. Existují tedy dva pohledy na klasifikace, jeden z pohledu kategorií (Kategorie, Podkategorie) a druhý z pohledu společností (Země, Společnost). 10

26 Hierarchii celého mandantu si pak lze představit takto: Obrázek 1: Hierarchie mandantu Uživatelské přístupy musí být omezovány uživatelskými rolemi, protože někteří zaměstnanci budou mít přístup pouze do určitých klasifikací. Každá role tedy přiřazuje různá oprávnění pro různé kombinace klasifikací z obou pohledů struktury témat (např. kombinace Kategorie - Společnost). Oprávnění mohou být na čtení tématu, vytváření tématu, vytváření příspěvku, mazání tématu, mazání příloh u příspěvků nebo na zobrazení smazaných témat. 11

27 V aplikaci budou existovat 3 globální uživatelské role: - Uživatel, - Administrátor mandantu, - Systémový administrátor. Je nutné, aby byli uživatelé informováni o aktivitách nastalých v aplikaci. Opět je nutné řešit zasílání notifikačních zpráv (nejlépe em) na základě přiřazení různých kombinací klasifikací, na které má uživatel právo. Není tedy možné, aby si uživatel nastavil kombinaci pro notifikaci, pro niž nemá právo a dostával tak jemu nepřístupné dokumenty a informace Pracovní název Pro práci na projektu je nutné stanovit název (pokud není již pevně stanoven zadavatelem) používaný místo oslovení Informačně-komunikační systém apod. Název projektu je totiž používán v dokumentech, ve vývojových či analytických prostředích a jiných odkazech na vyvíjený systém. Pro tento systém byl zvolen název International Communication Portal, zkráceně ICP. 3.2 Analýza a záznam požadavků Sběr požadavků vychází z mnoha jednání se zadavatelem projektu, ze zápisů z těchto jednání, z telefonických jednání a také z ových diskuzí. Na tento proces sběru požadavků byla kladena preciznost, neboť se jedná o komplexní softwarový projekt a není možné na určité funkce zapomenout. Pro záznam požadavků bylo použito tří metod: 1. Business Process Model. 2. UML diagramy požadavků s textovými popisy. 3. Případy užití se scénáři Business Process Model Business procesy se stávají v dnešní době složitějšími a složitějšími. Proto se analýza business logiky stala samostatným odvětvím. Tato analýza funguje nejen jako prostředek pochopení logiky businessu v realitě stranou zhotovitele, ale také jako základ pro implementaci těchto procesů v aplikaci. Na základě této analýzy vyvstala spousta požadavků, které nemusely být klasickou analýzou požadavků v textové podobě zachyceny. [7] 12

28 Pro popis business procesů v této práci byla využita notace BPMN, která nahrazuje diagramy aktivit v UML a má za cíl být zahrnuta ve standardu UML. Modelování BPMN diagramů je zahrnuto v modelovacím nástroji Enterprise Architect, který byl při práci použit. Existuje mnoho dalších nástrojů, které se specializují na modelování business aktivit, jejich rozbor ovšem není cílem této práce. Příkladem vhodným pro ukázku v této analýze je business proces diagram životního cyklu tématu. Téma, jako základní a stěžejní entita aplikace, je různých typů a může se během svého životního cyklu dostat do několika odlišných stavů. Z hlediska pochopení, v čem spočívá výhoda komunikace uživatelů použitím témat a příspěvků, je vhodné sestrojit tento popisný diagram. Na základě tohoto diagramu bylo možné určit několik dalších entit, vlastností a funkcionalit, které bylo nutné implementovat. Ze zakreslených událostí typu IntermediateEvent s trigerem Message 2 je například patrné, že bude nutné využít SMTP server pro odesílání upozorňujících ových notifikací. Dále lze určit, že entita Téma se může dostat do stavů Vytvořeno, Zavřeno, Viditelné a Neviditelné. Z procesu plyne několik dalších poznatků, které je nutné zahrnout do analýzy, aby popis pro návrh a následnou implementaci byl co možná nejlépe připravený a pochopitelný. Těmito poznatky se zabývají další části analýzy. Ostatní BPMN diagramy a jejich popisy jsou uvedeny na přiloženém CD. 2 Proces pokračuje po vykonání události tohoto typu (v tomto případě odeslání či přijetí zprávy) 13

29 Obrázek 2: BPMN - životní cyklus tématu 14

30 3.2.2 Funkční požadavky Analýza a zpracování funkčních požadavků ve formě UML diagramů rozděluje vstupní požadavky dle rozsahu a priority do tří sekcí: 1. Hlavní požadavky Jedná se o hlavní cíle, které musí aplikace splňovat, funkční požadavky s nejvyšší prioritou. Tyto požadavky jsou náročné na pracnost i cenu. Bez vypracování těchto požadavků by aplikace nesplňovala základní očekávání zadavatele. Ukázka seznamu hlavních funkčních požadavků je na obrázku. Obrázek 3: Hlavní funkční požadavky Každý hlavní požadavek musí obsahovat podrobný popis funkce, kterou má splňovat. 15

31 Obrázek 4: Podrobný popis požadavků 2. Vedlejší požadavky Skupina požadavků označených jako subfunkce zobrazuje vedlejší požadavky, které nejsou primární pro dosažení hlavních uživatelských cílů, ale očekává se jejich implementace. Obrázek 5: Vedlejší funkční požadavky 16

32 3. Nice to have požadavky A konečně požadavky, které není nutné v první verzi implementovat, ale v případě vhodnosti či jednoduchosti lze splnit. U těchto požadavků lze specifikovat, od jaké verze je možné nad jejich implementací přemýšlet. Obrázek 6: "Nice to have" požadavky Nefunkční požadavky Seznam nefunkčních požadavků: - webová internetová aplikace, - klientské i serverové zabezpečení, - rychlá odezva systému na požadavek (max. do 3 vteřin), - pravidelná záloha aplikačních dat (uložené souborové přílohy, databáze), - optimalizace pro známé internetové prohlížeče (primárně platformní prohlížeč společnosti - Internet Explorer 8), - user-friendly přístup pro široké spektrum uživatelů, - velká kapacita pevného disku pro uložení souborových příloh (odhad průměrného využití prostoru pro nové přílohy je 50 MB/den = cca 20 GB/rok). 17

33 3.2.4 Uživatelské role Dle odborného článku (viz kapitola 3.1.2) plyne, že existují 3 uživatelské role: Uživatel mandantu, administrátor mandantu a systémový administrátor. - Uživatel mandantu: o běžný uživatel aplikace, o může vstupovat do jemu přiřazených mandantů, o dle přiřazených práv zobrazuje přehledy témat, příspěvky v tématech, vytváří nová témata či příspěvky, uzavírá témata apod. - Administrátor mandantu: o stejná práva jako role Uživatel mandantu, o navíc nastavuje parametry daného mandantu (vytváří klasifikace, uživatele a uživatelské role v daném mandantu, uživatelské skupiny či typy témat), o exportuje seznamy uživatelů do Excelu a jiných formátů. - Systémový administrátor: o stejná práva jako role Administrátor mandantu, o navíc vytváří, edituje či maže mandanty, o má právo pro vstup do jakéhokoliv mandantu (pro práci v něm už ovšem musí mít přidělena dostatečná oprávnění), o exportuje uživatelské logy do souboru. Obrázek 7: Hierarchie uživatelských rolí 18

34 3.2.5 Případy užití a scénáře Případy užití dokumentují reakce systému na uživatelské požadavky. Spolupráce systému s uživatelem je popsána scénáři. Vzhledem k tomu, že se scénáře mohou měnit, bylo použito verzí scénářů (lze najít scénář před změnou). Každý scénář může mít několik alternativ (alternativa označena písmenem za číslem verze) v případě různých způsobů použití a reakce (rozvětvení aktivit dle rozhodnutí systému či uživatele). Protože počet zachycených případů užití je velký, bude zde ukázáno jen několik z nich. Všechny případy užití jsou pak přiloženy na CD. Přihlášení uživatele do systému Scénář: Obrázek 8: UC - Přihlášení uživatele do systému UC: Přihlášení uživatele do systému verze obsah scénáře Uživatel zadá přihlašovací údaje. 2. Přihlásí se do systému pomocí tlačítka přihlásit. 1.1a 1. Uživatel zadá přihlašovací údaje. 2. Uživatel se pokusí přihlásit do systému pomocí tlačítka přihlásit. 3. Systém ověří přihlašovací údaje. 4. Pokud jsou údaje platné a uživatel patří do nějakého mandantu, je přihlášen do systému. 5. Uživatelovi se otevře defaultní mandant s přehledem témat před expirací (pokud nemá přiřazen defaultní mandant, vybere se jeden z možných). 19

35 1.1b Alternativní scénář ke kroku Pokud jsou údaje neplatné či uživatel není přiřazen do žádného mandantu, je zobrazena chybová hláška upozorňující na tuto skutečnost. 1.1c Alternativní scénář ke kroku (po něm) 5. Pokud vypršela platnost uživatelova hesla, systém otevře obrazovku s možností změny hesla. 6. Uživatel zadá staré a nové heslo a potvrdí zadání. 7. Systém ověří, že uživatel zadal správné staré heslo a nové heslo v požadovaném formátu a uloží změny. Tabulka 1: Scénář přihlášení uživatele do systému Uživateli se dle jeho globální uživatelské role zobrazí jiná obrazovka. Pro systémového administrátora je to administrační rozhraní systému, pro administrátora mandantu a běžného uživatele mandantu je to pak přehled témat jednoho z přidělených mandantů. Vzhledem k tomu, že uživateli se může přidělení mandantů měnit a jeho defaultně nastavený mandant (do kterého je uživatel po přihlášení přesměrován) již nemusí být platný nebo dokonce je uživatel zablokován administrátorem, pak je zapotřebí řešit kontrolu přístupu a popř. nastavit nový defaultní mandant. Obrázek 9: Diagram aktivit - Kontrola přístupu uživatele do mandantu 20

36 Přehled a vyhledávání témat Témata lze zobrazovat třemi různými způsoby: 1. Přehled aktuálních témat. Přehled se zobrazí uživateli po přihlášení do systému. Jedná se o hlavní obrazovku aplikace, neboť na ní lze najít nejaktuálnější řešená témata (aktuálnost závisí na stavech a datech úprav těchto témat). 2. Stromová hierarchie témat. Po výběru elementu z hierarchického stromu klasifikací se uživateli zobrazí seznam témat do této klasifikace přiřazených. 3. Vyhledávání témat. Uživatel si zvolí z velkého množství kritérií, dle kterých chce hledat témata (prakticky všechny atributy témat lze nastavit jako kritéria). Obrázek 10: UC - Vyhledávání témat Scénáře k tomuto diagramu - viz soubor(dokument) na přiloženém CD. 21

37 Administrace mandantu (vytvoření hierarchie klasifikací) Ukázka složitějšího případu užití je tvorba klasifikační hierarchie. Témata musí být správně a snadno kategorizována pro snadné vyhledávání, zařazování nových témat či přidělování uživatelských oprávnění ke kombinacím dvou pohledů klasifikací. Pro ukázku vypsány opět jen některé scénáře. Obrázek 11: UC - Vytvoření hierarchie mandantu 22

38 UC: Vytvoření mandantu verze scénář Systémový administrátor musí být pro vytvoření mandantu přihlášen. 2. Administrátor zadá název mandantu (popř. vybere jeho implicitní styl). 3. Administrátor vybere se seznamu všech uživatelů administrátora mandantu. 4. Administrátor stiskne tlačítko pro vytvoření mandantu. 5. Systém založí nový mandant a jeho administrátora. Tabulka 2: Scénář vytvoření mandantu UC: Připojení uživatele do mandantu verze scénář Administrátor vybere mandant, do kterého patří nový uživatel. 2. Zaškrtne, zda-li má být tento uživatel administrátorem tohoto mandantu. 3. Potvrdí vytvoření Administrátor mandantu vybere uživatele ze seznamu, který ještě nepatří do stávajícího (UC: Výběr existujícího uživatele). 2. Přiřadí uživatele do svého mandantu stiskem příslušného tlačítka. 3. Systém přiřadí uživatele do mandantu. Tabulka 3: Scénář připojení uživatele do mandantu Automatický dávkový import Dávkový import probíhá v nastavených časech (konfigurace aplikace). Import je spuštěn nad nastaveným adresářem obsahujícím patřičné soubory a dokumenty, které se mají do systému vložit. Každá složka je dle svého názvu (identifikátor tématu) spojena s tématem v systému. Do tohoto tématu jsou pak vytvářeny příspěvky na základě obsažených příloh. 23

39 Obrázek 12: Sekvenční diagram - Automatický dávkový import Sekvenční diagram zobrazuje aktivity při hromadném importu z pohledu doménových tříd. Každý automatický import probíhá ve třech cyklických krocích po načtení adresářů s připravenými dokumenty. 1. Pokud je v adresáři pro dané téma nějaký soubor, vytvoř importovací dávku (jinak přechod na další složku). 2. Do této dávky načti soubory z adresáře a připoj je k novému příspěvku. 3. Připoj nový příspěvek k danému tématu. 3.3 Harmonogram práce (Ganttův diagram) Proces vývoje toho projektu byl inspirován modelem OOSP (Object-Oriented Software Process), který rozděluje vývoj software do čtyř fází [8]: 1. Inicializace 2. Konstrukce 3. Odbavení 4. Údržba a podpora 24

40 V této práci je OOSP model pozměněn takto: - fáze Odbavení je součástí fáze Testovací běh a Pilotní provoz, - fáze Údržba a podpora je zahrnuta pouze pod fázi Pilotní provoz (další podpora po ukončení projektu je zde samozřejmostí). Obrázek 13: Ukázka Ganttova diagramu Harmonogram práce byl vytvořen prostřednictvím Ganttova diagramu rozložení práce a zdrojů. Tento diagram byl vytvořen v nástroji Microsoft Project Dopodrobna popisuje postupnou činnost na jednotlivých úkolech v hlavních fázích vývoje. Na základě tohoto diagramu byl stanoven prvotní odhad na délku trvání vývoje cílového produktu. fáze trvání (dny) Inicializace 109 Konstrukce 105 Testovací běh 23 Pilotní provoz 50 Ukončení projektu 5 Celkem 292 Tabulka 4: Odhad trvání projektu na základě harmonogramu práce S rozložením práce mezi tři vývojové pracovníky by tedy vývoj trval necelý rok. 3.4 Odhad pracnosti a rozpočtu projektu Pro odhad pracnosti a rozpočtu potřebného na realizaci projektu byla použita metoda Use Case Points (UCP). Narozdíl od velmi často používaných metod typu COCOMO či Functional Point Analysis (FPA) je výpočet pomocí UCP jednoduchý (zmíněné nepoužité metody vyžadují pro kvalitní výpočet funkčních bodů experty). [9] 25

41 Obrázek 14: Metoda UCP v Enterprise Architect Metodu UCP podporuje také nástroj Enterprise Architect. Zpracování této metody není ovšem dostatečně kvalitní (zejména pro těžce nastavitelné konstanty faktorů) a proto byl tímto nástrojem proveden pouze součet Use Case bodů a export tabulky s ohodnocením případů užití a aktérů z hlediska jejich složitosti. a) složitost aktérů Mezi aktéry patří všechny uživatelské role (uživatel mandantu, systémový a mandatní administrátor) a také systém jako reagující prostředek na požadavky uživatelských rolí. Aktér Váha Počet Jednoduchý Středně složitý Složitý Unadjusted actor weight 8 Tabulka 5: Odhad složitosti realizace aktérů v systému 26

42 b) složitost Use Cases Složitost se odvíjí dle počtu transakcí v Use Case provedených. Počet transakcí se dá spočítat v tomto případě jako počet kroků scénáře. Use Case Počet transakcí Váha Počet UC jednoduchý < průměrný 4 až komplexní > c) technické faktory Unadjusted Use Case weight 430 Unadjusted Use Case Points 438 Tabulka 6: Odhad složitosti případů užití Hodnota faktoru je určena dle vlivu daného technického požadavku. Platí, že čím vyšší hodnota faktoru, tím větší vliv. Hodnoty se pohybují od 0 do 5. Celková hodnota technického faktoru (TCF) 3 = 0,6 + (0,01 * součet_hodnot_faktorů) Technické faktory Váha Faktor Součin Distribuovaný systém Nároky na odezvy aplikace Uživatelská efektivita Komplexní zpracování Znovupoužitelný kód Snadná instalace 0,5 2 1 Snadné použití 0,5 4 2 Přenositelnost Snadná údržba Konkurenční přístup Bezpečnostní aspekty Spolupráce se systémy 3.stran Speciální výcvik Technical complexity factor (TCF) 0,92 Tabulka 7: Výpočet technického faktoru 32 3 Konstanty uvedené v součinu jsou tzv. magické konstanty. 27

43 d) faktory prostředí Určení hodnot faktorů je stejné jako v případě faktorů technických. Celková hodnota faktoru prostředí (EF) = 1,4 + (-0,03 * součet_hodnot_faktorů) Faktory prostředí Váha Faktor Součin Slučitelný s RUP Zkušenosti z tvorby aplikací 0,5 3 1,5 Zkušenosti s OOP Schopnosti ved.analytika 0,5 3 1,5 Motivace Stabilní požadavky Pracovníci na částečný úvazek Obtížné vývojové prostředí e) výpočet složitosti a ocenění projektu Environmental factor (EF) 1,19 Tabulka 8: Výpočet faktoru prostředí Celkový počet přidělených Use Case bodů (UCP) k projektu se spočítá ze součinu: Unadjusted UCP * TCF * EF Dále je potřeba určit pracnost jednoho UCP. Jedná se o dobu, kterou stráví jeden vývojář nad jedním UCP. V tomto případě je možné pracnost měnit na základě odhadu: Rozmezí pracnosti na 1 UCP = optimistická varianta (vývojář pracuje na jednom UCP 1 hodinu) 3 pesimistická varianta 7 28

44 Další hodnota, která určuje dobu vývoje je počet pracovníků, kteří mohou na projektu pracovat, celková cena se pak odvíjí také od nákladů na práci vývojáře za jeden měsíc. Udjasted Use Case Points (UCP) 479,52 Pracnost na 1 Use Case Point 1,6 Počet pracovníků v týmu 2 Měsíční nákladová cena/pracovníka Kč Celková pracnost 768 člověkohodin 5 člověkoměsíců Odhad ceny projektu Kč Odhad délky trvání projektu 3 měsíců Tabulka 9: Výsledný odhad délky práce a ceny projektu Výsledný odhad doby vývoje by se měl shodovat s odhadem délky práce na části konstrukční fáze (příprava vývoje, tvorba GUI a implementace logiky) dle stanoveného harmonogramu v předchozí kapitole. Je tedy možné provést kontrolu vypočtených hodnot z výsledků obou metod odhadu. Odhad práce na implementaci: Obrázek 15: Délka trvání implementační fáze dle Ganttova diagramu - dle Ganttova diagramu: 90 dnů (člověkodnů) - dle metody UCP 4 : 768 hodin / 4 hodiny / 2 pracovníci = 96 člověkodnů Výsledné hodnoty jsou přibližné stejné (chyba způsobena odhadem). Odhad práce tedy lze považovat za uspokojivý. 4 Pracovní doba vývojáře na poloviční úvazek = 4 hodiny. Na projektu pracuje tým o dvou zaměstnancích. 29

45 3.5 Analýza rizik Krok, který vede ke snižování rizik při vývoji softwarového projektu jejich analýza. Analýza rizik je dle [10] proces definování hrozeb, pravděpodobnosti jejich uskutečnění a dopadu na aktiva, tedy stanovení rizik a jejich závažnosti. Analyzovaná rizika: - propuštění, dlouhodobá nepřítomnost či ukončení pracovního poměru vývojáře, který je seznámen s projektem o důsledek: prodloužení analýzy, projektování a celkového vývoje, zvýšení nákladů o řešení: dostatečná kvalita analytických materiálů pro rychlé zaučení nového pracovníka - odmítnutí vývoje projektu zadavatelem na základě velké ceny o důsledek: finanční i časová ztráta strany řešitele v důsledku práce na analýze o řešení: zadavatelem je blízký a známý partner řešitelské strany, proto bude cena nastavena na základě vzájemné dohody (základní náklady na vývoj ovšem nebudou snižovány) - ukončení spolupráce obou stran na základě okolnosti, která zapříčinila pád společnosti zadavatele o důsledek: finanční a časová ztráta strany řešitele o řešení: není - nedostatek času či financí na vývoj projektu řešitelem o důsledek: nedodání produktu v dohodnutých termínech, ztráta společnosti zadavatele o řešení: eliminace implementace funkcionalit, které není nutné zahrnout do první verze systému a jejich vývoj bude možný v dalších verzích 30

46 4. Návrh 4.1 Technologie a prostředky Typ aplikace V současné době je možné při vývoji software vybírat mezi několika typy interakce uživatele s aplikačními daty. Trendem je vytvářet aplikace přístupné přes webové rozhraní, ale je třeba zmínit výhody a nevýhody ostatních řešení pro vývoj informačních systémů. Desktopová aplikace Nespornou výhodou desktopové aplikace je rychlost přechodu mezi jednotlivými obrazovkami. Není totiž nutné stahovat potřebné prostředky k běhu aplikace z internetu. Veškeré přídavné knihovny, grafické prvky (obrázky) a popř. ozvučení je uloženo na disku uživatelského počítače. Aplikační požadavky jsou tak zpožděny hlavně přístupem aplikace ke vzdálenému zdroji dat, který je pro informační systémy potřebný. Další výhodou je vzhled aplikace, který se přizpůsobuje operačnímu systému, na kterém aplikace běží. Uživatel pak může intuitivně ovládat aplikaci vzhledem k tomu, že komponenty této aplikace vypadají stejně jako v jiných aplikacích, které standardně používá (pokud aplikace nevyužívá speciálních stylů pro ovládací prvky). Problémem jsou pak aktualizace takových aplikací, které probíhá nejčastěji přes různé update či patche. Tyto doplňky si pak musí uživatel stejně stáhnout z internetu a většinou i ručně nainstalovat. Pokud je pak nutné přejít na vyšší majoritní verzi programu, velikost takové aktualizace může dosahovat velikosti celé aplikace, což není pro uživatele zrovna příjemné. Webová aplikace Zmíněnou výhodu pro desktopové aplikace, a to vzhled přizpůsobující se operačnímu systému, již dnes nelze považovat za nevýhodu u webových aplikací, neboť moderní technologie pro vývoj webových aplikací již dosahují podobných kvalit jako aplikace desktopové. Díky asynchronímu přístupu k datovému zdroji (dnes realizováno např. pomocí technologie Ajax) není nutné při každém požadavku obnovovat celou webovou stránku, ale jen prvky (komponenty), kterých se změny dotknou. Webové aplikace se pak ovládají (popř. vypadají) jako aplikace desktopové a říkáme jim RIA aplikace (Rich Internet Application), čili bohaté internetové aplikace. 31

47 Webová aplikace umožňuje to, aby do ní vstoupil uživatel v jakémkoliv bodu pomocí URL. To znamená, že uživatel může do adresního řádku zadat adresu stránky webové aplikace, na kterou chce vstoupit, aniž by se k této fázi musel složitě doklikávat. Stejně tak je možné opakování požadavku či vracení se o krok zpět (tlačítka obnovit a zpět v internetovém prohlížeči). Bez jakéhokoliv programování si tak může uživatel ukládat své oblíbené stránky do svých záložek, což je zejména pro informační systém velká výhoda (záložky na důležitá témata apod.). Velkou výhodou webových aplikací je pak možnost je aktualizovat bez nutnosti toho, aby si uživatel musel stahovat či dokonce instalovat aktualizace. Též lze zmínit i rychlost přístupu k datům, protože datový zdroj je možné umístit na stejný server, na kterém je aplikace spuštěna. Rychlost přístupu je pak mnohonásobně rychlejší než při vzdáleném přístupu ke zdroji dat. Nespornou výhodou je také možný přístup k aplikaci z jakéhokoliv počítače či zařízení, které umožňuje přístup k internetu přes webový prohlížeč (v případě internetové aplikace). Toto lze označit také jako nevýhodu pro případy útoků hackerů či jiného zneužití dat v aplikaci obsažených. Nevýhodou je také to, že aplikace běží jedině při připojení k internetu a pokud není implementován speciální klient (desktopová aplikace), lze se k aplikaci připojit jen přes webové rozhraní, které není bez připojení k internetu dostupné. Ovšem je nutné zdůraznit, že pro aplikace, které využívají sdílený (a vzdálený) datový zdroj, je připojení k internetu nezbytné a tudíž lze tento problém opominout. Mobilní aplikace Mobilní aplikace nepatří mezi řešení, která by nějakým způsobem konkurovala výše zmíněným rozhraním (alespoň v současnosti), neboť pro informační systémy je potřeba velké plochy pro zobrazení co největšího množství dat v co nejlepším podání. Tento požadavek proto není vzhledem k velikosti mobilních zařízení splnitelný. Přesto může být mobilní aplikace ve spojení s informačními systémy vhodným doplňkem pro případy, kdy je uživatel na cestách a nemá při ruce notebook či jiný druh počítače. Takový doplněk může sloužit pro nahlížení zkráceného přehledu dat či pro zobrazení zpráv aplikace. Nutno zmínit, že v dnešní době již spousta mobilních zařízení podporuje operační systémy a proto není problém se připojit k aplikaci stejným způsobem jako z jakéhokoliv počítače pomocí internetového připojení a prohlížeče či přímo přes desktopovou aplikaci. 32

48 Závěr Z požadavků zadaných zadavatelem plyne, že aplikace musí být přístupná ze všech koutů světa a zároveň musí být aplikační data co nejrychleji přístupná uživateli. Uživatel musí provádět co nejméně akcí, aby se do aplikace dostal a mohl s ní lehce pracovat. Samozřejmostí také je, aby bylo co nejrychleji možné provést opravu aplikace v případě chyby. Proto, hlavně díky poslední zmíněné myšlence, je nejvhodnější typem webová aplikace Datové úložiště (databáze) U datově složitých struktur je nevhodnějším prostředkem databáze. V širším smyslu jsou součástí databáze i softwarové prostředky, které umožňují manipulaci s uloženými daty a přístup k nim. Funkcionality těchto prostředků, výkon a možnosti databáze jsou základními kritérii při výběru správné databáze. Existují tři základní typy databází: relační, objektové a objektově-relační. Díky vyspělosti a široké podpoře softwarových prostředků je práce zaměřena pouze na relační databázové systémy. Další typy databází si může čtenář prostudovat samostatně. MySQL MySQL je multiplatformní databáze. Pro webové vývojáře je MySQL vnímáno jako rychlé úložiště dat. Je k dispozici jak pod bezplatnou licencí, tak pod komerční placenou licencí. Jednou z největších výhod MySQL je její dostupnost, dokumentace a její podpora na většině hostingů. Dnes se jedná o jeden z nejpoužívanějších databázových systémů v komunitě vůbec. Na databázi tohoto typu lze postavit i složitější informační systém. K tomuto typu RDBMS existuje několik kvalitních a zdarma dostupných správců a klientů v grafickém prostředí, které umožňuje snadno a rychle vyhledávat a měnit data. Jedním z nejvýznamnějších v současné době je nástroj HeidiSQL. Oracle Moderní multiplatformní databázový systém s velice pokročilými možnostmi zpracování dat, vysokým výkonem. Velmi rozšířený je tento systém i ve školství (podpora studia). Distribuce v několika edicích dle použití ve firmách a domácnostech (Enterprise, Standard, Standard One, 33

49 Express). Úspěch tohoto RDBMS systému je publikován na oficiálních webových stránkách společnosti Oracle. Dle článku na tomto webu je Oracle 5 : Na prvním místě co do podílu na trhu RDBMS mezi pěti nejvýznamnějšími obchodníky. Na prvním místě v celkovém softwarovém přínosu na systémech Linux/Unix. Oracle má větší podíl na trhu než jeho čtyři největší konkurenti dohromady. Microsoft SQL (MSSQL) Databázový systém od Microsoftu, nyní v nejnovější verzi 2008, je vhodným prostředkem pro velmi rozsáhlé aplikace s požadavkem na velké množství dat. MS SQL Server je placený, ale za to velmi spolehlivý nástroj, určený spíše pro velké projekty a společnosti. Existuje pro něj spousta nástrojů, které zjednodušují práci při tvorbě (nástroje pro synchronizaci dat a struktury). Pro správu dat lze využít Enterprise Manager, jehož tvůrcem je sám Microsoft. Poskytuje mnoho funkcí pro zobrazování vazeb mezi tabulkami či pro přenos dat mezi databázemi jejich zálohou apod. MS-SQL Server poskytuje také možnosti naprogramovat tzv. DTS balíčky, které obsahují kód programovacího jazyku Visual Basic. Díky těmto balíčkům lze spouštět pravidelné importy či exporty dat, kontrolovat data či vstupní dávky pro import. DB2 První prototyp tohoto RDBMS systému od firmy IBM je již znám ze sedmdesátých let minulého století, DB2 provází tedy dlouhá historie. Jedná se o komerční systém distribuovaný v několika verzích (Express, Workgroup Server, Enterprise Server). Zdarma je pak verze DB2 Express-C, která je podobná open source RDBMS MySQL či PostgreSQL, ovšem DB2 Express-C není open source. Ovšem oproti volným verzím databáze od Oracle či Microsoftu neomezuje počet naráz připojených uživatelů či velikost databáze. [11] DB2 lze provozovat na většině operačních systémů. V současnosti nejnovější verze 9.7 dosáhla mnohem větší výkonnosti a menší spotřeby oproti databázi Oracle (2,7krát rychlejší). DB2 lze využít jako distribuovanou databázi pro rozdělení zátěže požadavků a datových operací. [11] Pro DB2 existuje několik klientů sloužících ke správě dat a schémat. Velmi kvalitním je IBM Data Tools, naprogramovaný klient na platformě Eclipse. Tento nástroj poskytuje veškerou správu dat, 5 GRAHAM, Colleen, et al. Gartner [online] [cit ]. Dostupné z WWW: < html?ssSourceSiteId=ocomcz> 34

50 kterou běžný uživatel potřebuje, a to v prostředí, které je mu známé z programování aplikací (Eclipse jako nástroj pro vývoj v programovacích jazycích Java, C++, PHP a jiných). Závěr Vzhledem k tomu, že je ve vývoji zaběhlý systém objektově-relačního mapování pomocí nástroje Hibernate, je možné využít jakoukoliv relační databázi z vybraných (Hibernate podporuje většinu známých databázových systémů). Osvědčeným, velmi výkonným a lehce spravovatelným se stal RDBMS systém DB Volba vývojového prostředku programovací jazyk PHP Skriptovací jazyk PHP je zřejmě nejpoužívanějším jazykem pro tvorbu dynamických webových stránek. Mezi nejnovější koncepty patří objektově orientovaný přístup, díky kterému je možné v PHP vytvářet i složitě strukturované systémy. V současnosti se PHP prosazuje především pro tvorbu webových redakčních systémů či elektronických obchodů. Výhody: a) skripty prováděny na serveru (k uživateli se dostane až výsledek), b) podpora většiny internetových protokolů (HTTP, SMTP, FTP, IMAP, POP3,...), c) objektově orientované programování (od verze 5), d) jednoduchost (což je i nevýhodou), e) rozsáhlé knihovny funkcí (grafika, práce se soubory a s databázemi), f) ideální pro malé weby či menší redakční systémy. Nevýhody: a) základní knihovny procedurální, b) bez možnosti vyhazování výjimek, c) absence kvalitních vývojových prostředků pro debuging či kontrolu kódu, d) názvosloví knihovních funkcí, e) nepřehledný tvar kódu, f) netypový (proměnným je typ přiřazován automaticky). Od roku 1994 je PHP jedním z nejpoužívanějších jazyků pro tvorbu dynamicky generovaných stránek. [12] 35

51 Java Java je moderní objektově orientovaný programovací jazyk, který vyvinula společnost Sun Microsystems v roce Od 8.května 2007 je Java vyvíjena jako open-source. Hlavními výhodami jsou: [13] a) jednoduchost jeho syntaxe je zjednodušenou (a drobně upravenou) verzí syntaxe jazyka C a C++. Odpadla většina konstrukcí, které způsobovaly programátorům problémy, a na druhou stranu přibyla řada užitečných rozšíření, b) objektová orientovanost s výjimkou osmi primitivních datových typů jsou všechny ostatní datové typy objektové, c) distribuce je navržen pro podporu aplikací v síti (podporuje různé úrovně síťového spojení, práce se vzdálenými soubory, umožňuje vytvářet distribuované klientské aplikace a servery), d) interpretace místo skutečného strojového kódu se vytváří pouze tzv. mezikód (bajtkód). Tento formát je nezávislý na architektuře počítače nebo zařízení. Program pak může pracovat na libovolném počítači nebo zařízení, který má k dispozici interpret Javy, tzv. virtuální stroj Javy - Java Virtual Machine (JVM), e) nezávislý na architektuře vytvořená aplikace běží na libovolném operačním systému nebo libovolné architektuře. Ke spuštění programu je potřeba pouze to, aby byl na dané platformě instalován správný virtuální stroj. Podle konkrétní platformy se může přizpůsobit vzhled a chování aplikace, f) dynamický Java byla navržena pro nasazení ve vyvíjejícím se prostředí. Knihovna může být dynamicky za chodu rozšiřována o nové třídy a funkce, a to jak z externích zdrojů, tak vlastním programem, g) elegantní velice pěkně se v něm pracuje, je snadno čitelný (např. i pro publikaci algoritmů), přímo vyžaduje ošetření výjimek a typovou kontrolu. Nevýhody: a) paměťová náročnost (i u malých programů) pro chod aplikací je nutné mít v pamětí celé prostředí pro běh (JVM), b) start programů - je pomalejší neboť prostředí musí při každém spouštění program nejprve zkompilovat. 36

52 Programovací jazyk Java je vydáván ve třech různých platformách. Každá se zaměřuje na vývoj specifických aplikací: 1. Java ME (Micro Edition) tato edice se skládá z virtuálního stroje a API, pomocí kterého je možné vyvíjet a spouštět předkompilované skripty pro zařízení s nízkým výkonem (mobilní telefony, PDA). 2. Java SE (Standard Edition) tato edice je vlastně původní Javou, která byla určena pro tvorbu desktopových aplikací. Obsahuje virtuální stroj, knihovny se základními funkcemi a knihovny pro tvorbu GUI (AWT, Swing). 3. Java EE (Enterprise Edition) označovaná jako J2EE je určena pro tvorbu a provoz velkých podnikových aplikací, informačních systémů a vůbec všech velkých a náročných projektů. Základem této edice je Java SE, do které byly přidány prvky, které tuto edici vylepšují na Enterprise Edition. Těmito prvky jsou například: Java Servlety, JSP - pro vývoj webových aplikací, JMS (Java Messaging Services) přístup ke zprávovému middleware, EJB (Enterprise JavaBeans) pro vývoj sdílené business logiky..net.net je sada technologií pro tvorbu desktopových a internetových aplikací. Pro spouštění a běh takových aplikací slouží.net Framework. Tento framework je implementován pod MS Windows, tudíž je na této platformě závislý, ale protože je pouhým rozšířením operačního systému (dynamicky linkované knihovny, konfigurace, služby), jeho odstranění nezmění funkci systému. V této technologii je možné psát zdrojový kód programovacími jazyky, pro které dodává Microsoft kompilátory (C++, C#, Visual Basic) a také jazyky, které jsou určeny pro.net, ale od jiných firem. Pro vývoj webových aplikací je jasnou volbou C#, která je navíc kvalitnějším jazykem než Java. C++ je pro tyto účely příliš složitý a zdaleka neposkytuje vhodné prostředí pro tvorbu webu. Visual Basic je již zastaralý a jeho existence je odůvodněná tím, že ho stále používají někteří programátoři, kteří nechtějí měnit platformu. [14] Výhody.NET: a) oproti Javě je C# o něco kvalitnější, b) CLR (Common Language Runtime) zajišťuje spouštění a ukončování programů, spravuje paměť, vlákna, zajišťuje bezpečnost aplikací atd. (pro všechny jazyky.net), c) pokročilejší programování oproti Javě na straně serveru. 37

53 Nevýhody: a) oproti Javě se sezení udržuje pouze pomocí cookies (u Javy i v URL), b) závislý na platformě. Adobe Flash (ActionScript) Adobe Flash představuje velký nástroj pro vývoj webových reklam, jednoduchých her, prezentací či online editorů. Aplikace v tomto nástroji lze vyvíjet buď grafickou formou (možnost naklikat aplikaci do uživatelského rozhraní a doplnit kód výběrem příkazů z navigačního menu) nebo formou programování v ActionScriptu přímo. Programovat v tomto jazyku lze přímo v prostředí Flash či v externím nástroji (např. Flash Developer). Kód je ovšem vždy potřeba kompilovat právě v prostředí Flash. Kvůli bezpečnosti nepodporuje Flash žádné přímé ukládání či načítání dat, komunikace probíhá buď prostřednictvím XML (XML servery) či skriptů. Přímé připojení k databázi tedy není podporováno. Závěr Vybraným vývojovým prostředkem pro vývoj webového informačního systému se stala Java ve verzi Enterprise. Jako většina programovacích jazyků v dnešní době je i Java objektový programovací jazyk. Pro verzi EE dnes existuje spousta frameworků, které usnadňují vývoj složitých webových aplikací, a to jak z pohledu uživatelského rozhraní (JSP, JSF apod.), tak z pohledu business logiky (návrhové vzory pro Java EE) či datové vrstvy (ORM nástroje apod.). Java je navíc multiplatformním prostředkem, což je nespornou výhodou pro přesun aplikace (a potažmo aplikačního serveru) na jakýkoliv operační systém Aplikační server Aplikační server je prostředek, na kterém je spuštěna webová aplikace. Z hlediska programátora řeší následující problémy [3]: a) zpracovává sezení uživatelů, b) přístup k datům, c) problémy s nízkoúrovňovými protokoly, d) bezpečnost, e) výkonnost, f) integrace datových zdrojů. 38

54 Dnes existuje již mnoho aplikačních serverů, které splňují základní potřeby vývojáře na kvalitu. Vybírat ten nejlepší je tedy možné dle několika parametrů: - osvědčená kvalita, dlouhodobý vývoj (stable release), - úroveň dokumentace a konfigurace serveru, - kvalita administračního rozhraní, - stabilita běhu (i při víceuživatelském přístupu), - podpora nových technologií (verze servletů, JSP apod.). Apache Tomcat Aplikační server Tomcat je Open-source servletový kontajner od Sun Microsystems, který umožňuje snadný vývoj a nasazování webových aplikací a služeb. V současnosti je nejnovější beta verze 7.0. Stabilní je pak verze 6.0, která podporuje servlety verze 2.5 a specifikaci JSP verze 2.1. [15] Pro jednoduchou správu a nasazování aplikací na server je k dispozici HTML manager s kvalitní dokumentací. Tento aplikační server je nabízen ke stažení v několika formách (instalační balík s integrací do operačního systému, archiv ZIP, jako embedded server (také ZIP archiv) rozbalitelný při nasazování aplikace). Je důležité říci, že Apache Tomcat je referenční implementací J2EE servletů, což znamená, že pokud fungují servlety na tomto serveru, budou fungovat i na ostatních J2EE aplikačních serverech nezávisle na platformě. Sun GlassFish Enterprise Server Open-source aplikační server pro nasazování a doručování webových aplikací a služeb. Je určen pro platformu J2EE. Součástí serveru je i velmi kvalitní dokumentace. Na serveru lze spustit i Enterprise JavaBeans. GlassFish poskytuje velmi kvalitní administrační rozhraní, přes které lze snadno server i aplikace konfigurovat. Jetty Jetty je aplikační server a http server pro Javu, který je šířen zadarmo pod licencí open-source. Výhodami tohoto serveru jsou [16]: a) malá velikost (stovky kb), b) rychlost zpracování požadavků, c) lze integrovat s aplikačními servery JBoss, Geronimo. 39

55 Tento aplikační server je většinou také integrován do některých kompilačních a deployment nástrojů jako embedded server pro snadné spuštění aplikace bez nutnosti instalace samostatného aplikačního serveru. Oracle Application Server, IBM WebSphere AS, Bea Webblogic Tyto aplikační servery zmiňuji jako zástupce komerčních produktů, které nelze s open-source servery srovnávat. Komerční aplikační servery jsou určené pro robustní aplikace s důraznými požadavky na výkon, spolehlivost a stabilitu. Volba aplikačního serveru Pro tvorbu informačního systému postačí zdarma dostupný aplikační server Apache Tomcat 6.0 (stabilní verze), který splňuje požadavky na jednoduchost uživatelského rozhraní a instalace, dostupnost a podporu aplikací vyvíjených v Javě. Apache Tomcat používají s úspěchem také některé anglické banky, proto lze považovat tento server za kvalitní Volba vývojového prostředí Eclipse IDE Vývojové open-source prostředí pro programování v jazyce Java, C++ či PHP v několika možných verzích určených pro vývoj stand-alone aplikací, mobilních aplikací až po vývoj webových aplikací pod platformou J2EE. Eclipse je vyvíjen v Javě, proto ho lze spustit pod většinou známých operačních systémů. Eclipse lze nainstalovat jednoduchým rozbalením archivu. Projekty jsou pak umístěné ve workspace určeném složkou dosažitelnou z počítače, kde je Eclipse spuštěn. Těchto pracovních prostorů může být zaregistrováno více a lze se mezi nimi přepínat, což vytváří dokonalou variabilitu při vývoji v několika programovacích jazycích v jednom vývojovém nástroji. Díky velké škále pluginů pro toto prostředí je možné např. vytvářet UML diagramy, spravovat databázi, používat systém pro správu verzí, či vytvářet a spouštět JUnit testy. Eclipse je též vývojovou platformou pro další prostředí. Na této platformě lze tedy programovat nová vývojová prostředí či prostředky pro správu informací apod. Vývojář pak pracuje ve stejných podmínkách a prostředí na více různých projektech. 40

56 Netbeans IDE Vývojové prostředí NetBeans je výbornou variantou pro tvorbu GUI aplikací. V základní instalaci nechybí podpora ani pro enterprise aplikace. Snadnou cestou pomocí průvodců lze vytvořit základní strukturu webové aplikace. Práce na tomto nástroji dosáhla za poslední léta velkého pokroku, co se týče rychlosti práce s aplikací. Nechybí ani podpora nejznámějších verzovacích systému (SVN, CVS, Mercurial). NetBeans lze rozšířit pomocí doplňku a pluginů. Existují distribuce pro vývoj PHP či C++ aplikací. IntelliJ IDEA [17] Druhým z komerčních prostředí je inteligentní IntelliJ IDEA. Inteligentní proto, že programátorovi dokáže v jakoukoliv chvíli vývoje napovídat co nejpravděpodobnější postup jeho další práce. Tento nástroj je dostupný ve dvou varianteách: a) Community Edition open source edice z podporou vývoje základní Javy, b) Ultimate Edition plně podproované prostředí (Java EE, Spring, Hibernate a další), trial verze na 30 dní. Závěr Při srovnání ceny, výkonu a možností představených prostředí se jeví jako nejlepší vývojové prostředí Eclipse IDE. Vzhledem k tomu, že byla vybrána databáze DB2, která může být spravována v prostředí IBM Data Tools (stavěném na platformě Eclipse), bude se hodit Eclipse IDE také pro vývoj Java EE webovou aplikaci. Podpora nejdůležitějších extenzí a frameworků je v tomto prostředí vzhledem k oblíbenosti zajištěna. Stejně tak i velmi kvalitní asistence při programování (např. inteligence při doplňování kódu) Volba nástroje pro správu zdrojových kódů V oblasti vývoje software je správa zdrojového kódu důležitým krokem pro úspěch. Dvojnásob to pak platí u složitých projektů (PC her, informačních systémů apod.). Na těch totiž musí pracovat větší počet vývojářů a udržet kód stabilní a bez konfliktů je pak nadlidský úkol. Aby k těmto chybám nedocházelo a vývoj mohl proběhnout v pořádku a s čistotou kódu, je nutné využít jeden ze systémů, které umožňují spravovat zdrojové kódy a jejich verze. Správa verzí je dnes běžně používána ve word procesorech (MS Word, Excel apod.), pro wiki systémy či pro verzování obyčejných textových dokumentů. 41

57 CVS (Concurrent Version System) CVS je tzv. systém souběžných verzí fungující na bázi klient-server. Je k dispozici zdarma jako open-source projekt. Základní správní jednotkou je modul (adresářová struktura), do kterého jsou ukládány verzované zdrojové soubory. Lokálnímu úložišti se pak říká sandbox ( pískoviště ). K CVS lze přistupovat jak přes příkazovou řádku, tak přes dostupné GUI klienty (WinCVS či TortoiseCVS). CVS systém je integrován do spousty vývojových prostředí a nástrojů (NetBeans, Eclipse, EnterpriseArchitect). Podporuje možnosti značkování (tagging) a větvení (branching) a tím pádem možnost vývoje více verzí paralelně při účasti i několika vývojových týmů. Samozřejmostí je i zamykání souborů či hledání kolizí v kódu. U všech souborů je ukládána historie, lze se tedy kdykoliv k jakékoliv verzi souboru vrátit. Nevýhodou CVS je jeho zastaralost (vytvořeno spousty oprav) a také to, že byl původně určen pouze pro práci s textovými soubory (ostatní soubory nejsou tak triviální pro správu binární, unicode apod.). SVN (Subversion) V roce 2000 odstartoval projekt, který měl nahradit zastaralý a pomalý systém CVS. Hlavně pak odstranit nedostatky typu: nemožnost přesunu nebo kopírování adresářů, časovou a prostorovou náročnost větvení a značkování apod. Jedná se tedy opět o klient-server open-source projekt, který je k dispozici zdarma a je přístupný na většině platforem. Pro práci jsou k dispozici nástroje jako svn-client (příkazová řádka) či výborný GUI nástroj TortoiseSVN. Samozřejmá je pak i integrace do většiny aplikací, které správu verzí podporují. Systém SVN pokrývá veškeré výhody CVS a přidává nové možnosti a výhody: - adresáře, přejmenování a souborová metadata jsou verzována, - atomický commit, - větvení a značkování podstatně rychlejší oproti CVS (konstantní čas), - možnost výběru implementace pomocí databáze nebo obyčejných textových souborů, - verzování symbolických odkazů, - zrcadlení repozitáře. 42

58 Srovnání CVS vs. SVN SVN Revize je stav filesystému Umí verzovat i adresáře Obecně méně komunikuje se serverem Vyřešení konfliktu je nutné potvrdit CVS Revize se vztahuje ke konkrétnímu souboru Verzuje pouze soubory Neuchovává poslední verze souborů lokálně Tabulka 10: Srovnání verzovacích systémů SVN a CVS Je možné omylem odeslat na server soubor i s nedořešeným konfliktem Z tabulky plyne, že lepším nástrojem je jednoznačně Subversion, což je zřejmé také z toho, že se vyvíjel jako následník CVS. Mercurial [18] Je nutné zmínit také jednoho zástupce Peer-To-Peer přístupu, a to nástroj Mercurial. Tento systém od vyvinutý Mattem Mackallem je šířen pod licencí GPL (General Public License) a klade si tyto hlavní cíle: - jednoduchost, - škálovatelnost, - efektivitu, - podporu clone/branch a pull/sync. Mercurial je multiplatformní (i pro Mac) a jeho první release vyšel v roce Od té doby prošel celou řadou vylepšení a je dnes rozšířen do prostředí typu Eclipse, NetBeans, VisualHG apod. jako plugin. Pro přístup k systému Mercurial slouží klienti: TortioseHg, Hgk či MacHg. Volba verzovacího systému Pro informační systém byl použit verzovací systém Subversion. V současnosti je to zřejmě nejlepší klient-server systém, který existuje. Díky dlouholetému vylepšování se nejedná o experimentální nástroj, což je pro tak důležitou oblast jako je správa kódu podstatné Ostatní použité prostředky Spring Framework Tento framework má za cíl eliminovat spoustu základních problémů při vývoji enterprise aplikací. Vytvořen pro programovací jazyk Java. Podporuje IoC (Inversion of Control), aspektové programování, poskytuje celou řadu modulů (transakce, podpora vývoje webových aplikací Spring WebFlow, Spring MVC), utilit či pluginů do vývojových IDE. [19] 43

59 Spring framework podporuje tvorbu vícevrstvých aplikací. Zasahuje tedy do všech základních vrstev (prezentační, servisní, datová). Každou z těchto vrstev je pak možné snadno konfigurovat a soustředit se pouze na vývoj vlastní logiky aplikace bez nutnosti zabírat se myšlenkami ohledně struktury aplikace a propojení vrstev. Maven Maven je určen pro snadné buildování aplikací. Hlavním cílem tohoto nástroje je dovolit vývojáři zkrátit veškeré jeho úsilí na tvorbě projektu do co nejkratšího času. Za základě tohoto cíle Maven pokrývá tyto oblasti: - usnadnění procesu buildování není třeba vědět nic o tom, jak Maven zajišťuje building, vše je skryto za oponou, - poskytování jednotného systému pro buildování projekt v Mavenu je postaven na tzv. POMu (Project Object Model), který popisuje veškeré okolnosti s projektem spojené (externí knihovny, informace o projektu, způsoby nasazování aplikace apod.) a sadě pluginů, které jsou sdílené všemi projekty vytvořenými v Mavenu a právě to nám vytváři jednotný systém využitelný v jakémkoliv projektu za stejných podmínek, - poskytnutí kvalitních informací o projektu mnoho informací lze obsáhnout do POM, další informace Maven získává přímo ze zdrojového kódu (např. reporty Unit testů, změnové logy ze správy verzí apod.), - poskytnutí návodů pro vývoj dle nejlepších praktit, - transparentní přidávání nových funkcí snadnou cestou mohou vývojáři doplnit své instalace Mavenu o nové prvky včetně možnosti instalace nových pluginů (a jejich vývoje). Aplikace postavená na Mavenu má jednoduchou strukturu: /src/main... zdrojové soubory hlavní aplikace /src/test... zdrojové soubory pro testovací účely (Unit testy apod.) /target... výstupní složka pro kompilace a buildy /pom.xml... konfigurační soubor Mavenu se všemi informacemi o projektu Maven podporuje plně modularitu aplikací, lze tedy jednoduše sestavit aplikaci složenou z několika modulů a lehce ji spravovat a buildovat, a to třeba jen jako samostatné moduly. 44

60 Hudson Hudson je webová aplikace sloužící pro monitorování a spouštění opakovaných úkolů týkajících se nasazování nových verzí projektů a úloh typu CRON. Poskytuje online příkazovou řádku, ve které lze sledovat průběh nasazování aplikace, statistiku využití paměti či jiných prostředků aplikací, statistiku úspěšnosti nasazení aplikace apod. Aplikaci lze snadno nasadit na vybraný server pomocí jednoho kliku myší (Hudsonu si pomocí konfigurace projektu nalezne umístění aplikace v určité lokaci, provede např. pomocí Mavenu build aplikace a nahraje ji do cílového prostředí). K Hudsonu lze připojit další pluginy, které usnadní práci s projekty. Trac Nástroj napsaný v jazyce Python (pro jeho spuštění je nutný). Slouží ke správě úkolů projektu, prohlížení jeho zdrojového kódu či pro vytváření wiki stránek o projektu. Trac poskytuje vlastní dotazovací jazyk, pomocí kterého lze upravovat či vytvářen nové sestavy úkolů dle různého filtrování. Pomocí Tracu lze snadno spravovat úkoly, milníky či verze projektu v týmu. Úkoly mají různé stavy, příznaky a popisy, pomocí kterých lze určit, v jaké fázi úkol je. Trac lze rozšířit spoustou pluginů, např. pro správu uživatelů, přidávání nových položek k uživatelským profilům apod. Lze vytvářet sestavy do souborů CSV či jiných formátů (dle pluginů). Uživatelé spjatí s úkoly jsou informování em o změnách obsahu. Obrovskou výhodou je možnosti modifikace veškerého obsahu a vzhledu Tracu. Enterprise Architect Pro analýzu a návrh aplikace pomocí UML diagramů a jiných notací slouží komerční software Enterprise Architect od společnosti Sparx Systems. Tento nástroj je velmi komplexní a poskytuje celou řadu pomůcek pro tvorbu cílové analytické dokumentace i k těm nejsložitějším projektům. Pomocí EA lze snadno vytvářet výstupy dokumentace do formátu HTML či RTF (dle vytvořených šablon), exportovat modely do XML pro přenos či sdílet projekt uložením na databázový server. Microsoft Project Tato aplikace posloužila v případě této práce pro návrh rozdělení prostředků, úkolů a zdrojů. Díky tomuto nástroj byl vytvořen Ganttův diagram (harmonogram práce se stanovenou pracností) a byla vypočtena časová náročnost projektu. 45

61 Pencil Velmi intuitivní, jednoduchý, ale vynikající nástroj pro návrh obrazovek aplikace. Dříve vyvíjen pouze jako doplněk do internetového prohlížeče Mozilla Firefox (Pencil Sketch), nyní i jako samostatná aplikace. Snadným způsobem lze rychle pomocí drag n drop metody vytvořit návrh obrazovek aplikace a exportovat je do formátu obrazu, HTML stránky (např. tlačítka se vygenerují jako odkazy na jiné stránky) či do jiných formátů (další výstupní generátory lze stáhnout z internetu). Aplikaci obsahuje základní knihovny s komponentami, lze ovšem stáhnout z internetu nové knihovny či vytvořit vlastní sady komponent. 4.2 Architektura U projektů, jejichž vývoj zabere mnoho práce a času, není možné začít psát kód bez vytvoření implementační koncepce. Implementační koncepcí je myšleno oddělení specifických implementovaných funkcionalit systému do samostatných nezávislých bloků či vrstev, které spolu navzájem komunikují (přes rozhraní, remoting či jiným způsobem). Vývojové architektuře, která je stavěna na základě takové koncepce, se pak říká vícevrstvá neboli multi-tier. Obrázek 16: Vícevrstvá architektura aplikace 46

62 4.2.1 Databázová vrstva (Database layer) Na databázové vrstvě budou implementovány metody spouštěné databázovým strojem (rutiny, triggery) a pohledy, které usnadní a urychlí vyhledávání dat. Mapování těchto metod, pohledů ale i relačních tabulek do aplikačního kontextu zajišťuje vrstva datová Datová vrstva (Data Access layer) Na datové vrstvě pracuje především ORM nástroj Hibernate. Vrstva zahrnuje: - objektově-relační mapování datových zdrojů (databázové tabulky a pohledy) na objekty programovacího jazyka (doménové třídy), - spouštění databázových rutin, - rozhraní přístupu k datovému zdroji (pro každý typ datového zdroje se může implementace tohoto rozhraní lišit) pomocí DAO objektů (Data Access Object objekt přístupu k datům), metody a funkce DAO objektů pracují s daty v úložišti (pomocí databázových dotazů tvořených z objektověorientovaných dotazů jazyka HQL Hibernate Query Language) Servisní vrstva (Service layer) Business logiku aplikace, přístup k datům přes rozhraní datové vrstvy a zprostředkování dat vrstvě prezentační zajišťuje servisní vrstva architektury. Implementace této vrstvy je rozdělena mezi: a) specifické služby realizované rozhraními a implementačními třídami (např. služba pro zpracování logiky tématu obsahuje metody pro vytvoření tématu, smazání tématu, přidání příspěvku do tématu apod.) Návrh služeb: - AbstractService abstraktní služba s implementacemi metod použitelných ve všech ostatních službách (předek pro implementace ostatních služeb), obsahuje například metody vracející DAO (Data Access Object) objekty z datové vrstvy či aplikační konfiguraci převedenou na objekt s návratovými funkcemi konfiguračních hodnot, - ClassificationService tvorba, úprava či jiná modifikace klasifikací, - ExportService export dat do výstupních formátů, - ImportService import dat pomocí XML či ZIP dávek, - MailService podpora pro odesílání ů, - SearchService vyhledávací služba ICP (hledání témat, filtrování uživatelů apod.), - SystemService systémové informace a nastavení, - TopicService správa témat, příspěvků a příloh v tématu, - UserService správa uživatelských účtů, uživatelských rolí či skupin. 47

63 Obrázek 17: Ukázka návrhu služeb servisní vrstvy b) metody business logiky doménových tříd (třídy entit aplikace např. třída Téma obsahuje metodu, která do kolekce typu Příspěvek přidá nový objekt tohoto typu) Prezentační vrstva (Presentation layer) Vrstva, zodpovídající za zobrazení dat uživateli v čitelné podobě. Tato vrstva realizována pomocí: - JSF implementace MyFaces 1.2.9, - JSF faceletů - JSF Facelets (tvorba šablon stránek), - knihovny JSF komponent RichFaces 3.3.2, - komponent knihovny Tomahawk 1.1.8, - frameworku Spring WebFlow (zajišťuje datový tok, rozhraní přístupu prezentační vrstvy k datům přes metody servisní vrstvy či asociované beany aplikačním kontextem Spring Frameworku). 48

64 4.3 Doménový model tříd Analytický doménový model zachycuje klíčové třídy z domény řešení, jejich vlastnosti, chování a vztahy. Klíčovou třídou je téma (Topic), které zakládá uživatel (třída User). Téma - obecné vztahy Obrázek 18: Analytický model tříd - Vztahy třídy Téma Téma obsahuje příspěvky (Reply) zakládané uživatelem nebo příspěvky založené při hromadném importu (Import, TopicImport). Příspěvky mohou obsahovat přílohy (Attachments). Každý hromadný import provádí třída - manažer importu (ImportManager). Ta podle konfigurace načte z 49

65 adresářů data a pro každé téma založí jeden objekt třídy Import. Téma má definovaný typ (TopicType) a stav (TopicState). Pro každou kombinaci typu a stavu tématu je možné nadefinovat barvu (TopicTypeColor) a expirační dobu (TopicTypeExpiration). Každé téma je při vytvoření zařazené do jedné podkategorie a do jedné či více společností (jedná se o druhy klasifikací - Classification). Hierarchie klasifikací Obrázek 19: Analytický model tříd - Hierarchie klasifikací V systému je možné klasifikační třídy (Classification) seřadit do hierarchie. Systém obsahuje konečnou množinu kombinací klasifikací. Každá kombinace je dána třídou Combination. Na nejvyšší úrovni hierarchie klasifikací je mandant (Mandant), který obsahuje klasifikace druhé úrovně = země (Country) a kategorie (Category). Dále do země patří společnosti (Company) a do kategorie podkategorie (Subcategory). Možné typy klasifikací jsou dané výčtem druhu ClassificationType. Pro každý mandant (Mandant) je definována vlastní struktura hierarchie Category - Subcategory a Country - Company. Stejně tak jsou i pro mandant definovány typy témat (TopicType). 50

66 Přiřazení tématu do hierarchie klasifikací Při vytvoření tématu je přiřazen seznam klasifikací k tomuto tématu. Jedná se o všechny klasifikace, do kterých nové téma patří, tedy i do těch, se kterými má téma přímou vazbu ve stromu klasifikací (společnosti a podkategorie). Do tohoto seznamu pak budou zařazeny i předchůdci podkategorie a společností. Uživatelé a uživatelské role Obrázek 20: Analytický model tříd - Uživatelé a uživatelské role 51

67 Strukturu mandantu definuje administrátor mandantu tj. uživatel, který má všechna práva pro celý mandant. Zakládat nová témata (a popř. další speciální akce) může uživatel vlastnící potřebná práva (Permission) na zakládání témat, příspěvky k existujícím tématům může přidávat uživatel s právy pro přidání příspěvku apod. Systém spravuje administrátor systému (má veškerá práva pro všechny mandanty). Uživatelé mohou mít různá práva pro každou klasifikaci. Tyto práva se definují pro určité kombinace klasifikací obou struktur (Country, Category) v rámci rolí (LocalRole). Ke každé roli je pak možné přiřadit více uživatelů. To znamená, že role a notifikace uživatelů se definují pro kombinaci Klasifikace - Klasifikace (např.: Mandant - Company nebo Subcategory - Country). Práva rolí vůči kombinacím v daném mandantu (lokální práva) jsou určena pomocí objektů třídy RoleSetting, které obsahují seznam práv (Permission) pro dané kombinace klasifikací vůči rolím. Uživatel má v rámci mandantu jednoznačně přiřazenou globální roli (uživatel, administrátor apod.). Notifikace (Notification) uživatelů k jednotlivým kombinacím jsou přiřazovány pomocí instance třídy UserSetting, která říká, jaké notifikace budou posílány konkrétnímu uživateli pro dané kombinace klasifikací. Uživatelé mohou být seskupováni v rámci mandantu do definovaných skupin (UserGroup). Logování událostí Obrázek 21: Analytický model tříd - Logování událostí Uživatelské akce (EventType - např. sledování tématu uživatelem pro kontrolu průchodu, vytvoření nového tématu, editace práv uživatele apod.) jsou sledovány a zaznamenány (EventLog). 52

68 4.4 Návrh uživatelského rozhraní Návrh uživatelského rozhraní se skládá ze dvou fází: 1. Prvotní nástřel rozvržení obrazovek a diagramy navigací mezi těmito obrazovkami. Model první verze návrhu uživatelského rozhraní. Realizováno pomocí diagramů nástroje Enterprise Architekt. 2. Detailní popis obrazovek s logickým uspořádáním komponent. Návrh vzorových obrazovek pro implementaci vytvořen v nástroji Pencil (dříve Pencil Sketch). Přehled témat a hlavní aplikační menu (úvodní obrazovka po přihlášení uživatele) Model zobrazuje přehled témat vybraného mandantu pro přihlášeného uživatele a menu, které je zobrazeno i na všech ostatních uživatelských stránkách. Tento úvodní přehled obsahuje jen viditelná témata (viditelnost témat viz kapitola 3.2.2). Zobrazená témata je možné řadit dle vybraného sloupce (vyhledávání ve všech tématech je možné ve formuláři Topic search). Pokud má uživatel roli ve více mandantech, je možné se mezi mandanty přepínat (pokud jsou práva) pomocí rozbalovacího menu s výběrem mandantů. Témata jsou v přehledu barevně odlišená. V horní části obrazovky jsou zobrazeny důležité zprávy zadávané systémovým (system message) či madantním administrátorem (mandant message). 53

69 Obrázek 22: Návrh UI (EA) - Přehled témat a menu Obrázek 23: Návrh UI (Pencil) - Přehled témat a menu 54

70 Druhá fáze návrhu této obrazovky přesunula hlavní menu do vertikální podoby do záhlaví stránky. Tento přesun byl proveden kvůli většímu prostoru pro zobrazení dat (horizontální menu zabírá více prostoru ve stránce). Vytvoření či editace tématu Model zobrazuje uživatelský formulář pro založení nového či editaci existujícího tématu. Základní požadavky na validaci a funkcionalitu této obrazovky: - nutné přiřadit minimálně jednu společnost a právě jednu podkategorii k tématu, - při zakládání tématu se zobrazuje seznam společností založených v mandantu, - je možné nastavit příznak automatického smazání starých příspěvků či jen příloh při nové odpovědi, - po vytvoření tématu je uživatel odkázán na jeho detail, kde může vytvořit nové příspěvky, - uložení změn v případě editace existujícího tématu se provádí tlačítkem Save, - téma lze smazat pomocí tlačítka Delete, pokud na to má uživatel dostatečná práva. Tlačítko Create joined topic Pokud je vybráno více společností, je založeno jedno téma, kam mají přístup uživatelé z vybraných společností. Téma existuje v systému jen jednou. Tlacítko Create individual topic Pokud je vybráno více společností, je pro každou společnost založeno nové téma. 55

71 Obrázek 24: Návrh UI (EA) - Vytvoření nového tématu Obrázek 25: Návrh UI (Pencil) - Vytvoření nového tématu 56

72 Ve druhé fázi byl návrh doplněn o možnost přidání prvního příspěvku k tématu při jeho vytváření. Uživatel tak v rámci jednoho formuláře vytvoří téma i příspěvek. Návrh a popis všech obrazovek je uveden na příloženém CD. 4.5 Plán testování Testování složitějšího projektu by mělo být vždy rozděleno na více částí. Není například vhodné, aby zadavatel či skupiny cílových uživatelů testovala první alfa verze aplikace. Programátor nepíše kód bezchybně a navíc, některé chyby vzejdou až při běhu aplikace (runtime errors). Nejdříve by tedy měli sami programátoři či jiní pracovníci vývojového centra nalézt co nejvíce chyb a až po kvalitním odladění zpřístupnit aplikaci zadavateli či cílovým subjektům. Fáze 1: Lokální testování. Lokální testování alfa a beta verzí aplikace probíhá na vývojové platformě programátorů (na jednotlivých počítačích) či na vývojovém serveru přístupném pro programátory. Tohoto testování se tedy účastní pouze vývojáři. Fáze 2: Testování v malém. Testování aplikace zpřístupněné na testovacím serveru jen několika uživateli. Toto testování slouží pro představení prvních výsledků práce zadavateli. Ve stanovených časových intervalech je aplikace nasazována na tento server pro přehled postupu vývoje. Toto testování slouží pro odhalení základních chyb, které identifikuje zadavatel z hlediska businessu (chyby v procesech, špatné výstupy apod.) či vzhledu (úprava uživatelského rozhraní). Fáze 3: Testování ve velkém. Testování cílovými uživateli na veřejné testovací platformě. Odhalení chyb díky hromadnému přístupu velkého počtu uživatelů (zátěžové testy). Předpoklad pokrytí většiny funkcionalit vede k testům rychlosti odezvy při naplnění datového úložiště velkým množstvím dat. 4.6 Plán nasazení Již z plánu testování vyplývá, že bude potřeba zavést několik prostředí pro spuštění aplikace s různými omezeními přístupu uživatelů: a) vývojové prostředí přístup možný pouze pro vývojáře, b) testovací prostředí přístup pro vývojáře a úzkou skupinu uživatelů zadavatelské strany (či pro vedení řešitelské strany), 57

73 c) produkční prostředí veřejný přístup k aplikaci na základě certifikačního ověření (nutné vytvořit certifikát podepsaný certifikační autoritou), aplikace musí být dostatečně zabezpečena proti úniku citlivých dat. Obrázek 26: Diagram nasazení systému Každý z dostupných serverů musí mít umožněn přístup k databázovému serveru svého typu (každý typ prostředí má svůj server s databázovým strojem) Rozdělování požadavků dle zatížení (Load Balancing) Vzhledem k očekávanému přístupu velkého množství uživatelů k aplikaci budou požadavky na produkčním prostředí rozdělovány pomocí aplikačního serveru (Apache Tomcat 6.0) specializovaného na tuto funkci. Tento server se nazývá Load Balancer a vstupní aplikační požadavky rozděluje na základě zatížení mezi podřadné aplikační servery (taktéž Apache Tomcat 6.0), na nichž je v kopii spuštěna aplikace. 58

74 4.6.2 Sdílení dat produkčními servery Aplikace umožňuje uživateli ukládat souborové přílohy. Ty budou uloženy na disku přístupném oběma produkčními servery pomocí mapování datového zdroje. Přílohy tedy budou přístupné z obou instancí produkční verze aplikace bez nutnosti přenášet nějaká data. 59

75 60

76 5. Implementace 5.1 Aplikační framework Použité technologie jsou určitým způsobem rozděleny do navržených vrstev sestavené architektury. Toto rozdělení a použití stanovených technologií určuje aplikační framework, dle kterého se řídí implementace aplikace Struktura zdrojového kódu Obrázek 27: Aplikační framework Struktura zdrojového kódu vychází ze standardní projektové struktury J2EE webové aplikace dle nástroje Apache Maven. Ta dělí zdrojový kód na složky provozní (main) a testovací (test). Pro aplikaci ICP je v těchto složkách kód rozdělen na: a) aplikační logiku napsanou v Javě (složka java), b) konfigurační XML či properties soubory (složka resources), Jedná se např. o nastavení Spring frameworku (inicializace bean), konfigurace motivů RichFaces či konfigurace mapování Hibernate, c) konfigurační složky závislé na použitém serveru (složka config) Konfigurace připojení k databázi, nastavení logování, nastavení cest k serverům (pro ukládání příloh), d) zdroj webové aplikace JSP stránky, JSF komponenty, JavaScript, CSS styly, definice použitých UI komponent, konfigurace webové aplikace apod. 61

77 Zkompilovaný kód se standardně ukládá do složky target. Struktura zdrojového kódu aplikace ICP: icp -- pom.xml -- src -- main -- java -- cz/icp/**/*.java -- resources -- /**/*.properties -- /**/*.xml -- config -- local/*.properties -- development/*.properties -- test/*.properties -- production/*.properties -- app-config.properties -- webapp -- index.jsp -- css/*.css -- scripts/*.js -- images/* -- /**/*.jspx -- WEB-INF -- web.xml -- faces-config.xml -- test Konfigurace Konfigurace aplikace /config/app-config.properties Určité hodnoty by v kódu neměly být definovány přímo. Proto je vhodné je oddělit do externího konfiguračního souboru. Tento soubor lze měnit i po kompilaci aplikace, není ovšem nutné kompilovat znovu celý kód. Ukázka souboru s aplikační konfigurací:... exporttitle = export passwordexpirednotification = 14 passwordvalidity = 90 passwordlength = 6 companylistsize =

78 Konfigurace připojení k databázi /config/server_profile/database.properties Protože se aplikace připojuje k databázi určené dle serveru, je nutné pro každý server definovat vlastní konfiguraci připojení. Apache Maven pak při kompilaci kódu vybere dle zadaného profilu správnou konfiguraci automaticky. Ukázka připojení k databázi: jdbc.url=jdbc:mysql://localhost/icp jdbc.user=root jdbc.password= jdbc.driverclass=com.mysql.jdbc.driver... Nastavené hodnoty jsou využity při vytváření databázového připojení pomocí třídy ComboPooledDataSource. Tvorba instance této třídy je definována v jednom z konfiguračních souborů Spring Frameworku (/resources/spring-data-access.xml): <bean id="datasource" class="com.mchange.v2.c3p0.combopooleddatasource"> <property name="jdbcurl" value="${jdbc.url}" /> <property name="driverclass" value="${jdbc.driverclass}" /> <property name="user" value="${jdbc.user}" /> <property name="password" value="${jdbc.password}" /> <property name="initialpoolsize" value="10" /> <property name="minpoolsize" value="5" /> <property name="maxpoolsize" value="20" /> <property name="acquireincrement" value="5" /> <property name="maxidletime" value="28800" /> </bean> Lokalizace Dle požadavku možnosti překladu aplikace do více jazyků byla zavedena odkazová forma vkládání textů do uživatelského rozhraní. V JSP stránce to tedy znamená náhradu přímého vložení textu zástupnou konstantou. Tyto konstanty jsou v době generování JSP stránky nastaveny na hodnoty dle překladových souborů messages_xx.properties. Např. konstanta #{msg.login_username} má v souboru messages_cs.properties překlad login_username = Uživatelské jméno a v souboru anglické lokalizace messages_en.properties login_username = Username 63

79 Lokalizační soubor je určen dle nastavení jazyku v subsystému (mandantu). Administrátor mandantu tedy volí jazyk, kterým bude mandant přeložen pro všechny uživatele připojené do tohoto mandantu Připojení externích knihoven Správa a připojování nových externích knihoven je jednoduchým způsobem prováděna pomocí nástroje Apache Maven. Pro přidání nové knihovny k projektu stačí do konfiguračního souboru Mavenu (soubor /pom.xml) zadat závislost definovanou dle nastavení dané knihovny v centrálním repozitáři (pro Maven existuje spousta těchto repozitářů s knihovnami). Příklad definice repozitáře v pom.xml: <repository> <id>org.jboss.maven2.repository</id> <name>jboss Maven 2 Repository</name> <url> </repository> Příklad definice závislosti externí knihovny: <dependency> <groupid>org.hibernate</groupid> <artifactid>hibernate-core</artifactid> <version>3.3.2.ga</version> </dependency> 5.2 Uživatelské rozhraní Vzhledem k oddělení uživatelského rozhraní a business logiky do samostatných nezávislých vrstev (prezentační a servisní) lze nejdříve zkompletovat všechny obrazovky aplikace bez nutnosti řešit chování těchto obrazovek. Zadavatel pak ještě může okomentovat vzhled těchto obrazovek a případně se mohou tyto implementace upravit bez nutnosti měnit kód logiky či mezivrstvy s přístupem k datům business logiky. Samotné obrazovky lze totiž nasadit na server jako běžící aplikaci. Výsledné uživatelské rozhraní se následně oživí dodáním kódu logiky aplikace. Implementace uživatelského rozhraní pomocí zvolených technologií probíhala na základě detailně navržených obrazovek (viz kapitola 4.4). Díky knihovně s moderní sadou webových komponent (RichFaces) bylo možné docílit minimálně stejné kvality rozložení a vzhledu obrazovek jako v navrženém konceptu. 64

80 5.2.1 Struktura obrazovek Aplikační obrazovky a jejich doplňky jsou strukturovány do složek dle jejich využití a globálních uživatelských rolí. Struktura definic stránek uživatelského rozhraní: /src/main/webapp -- index.jsp...úvodní stránka aplikace -- admin...administrační rozhraní -- error...chybové stránky -- includes...vkládané podstránky (menu, clona apod.) -- modals...modální panely (okna) vkládané do stránek -- private...stránky přístupné po přihlášení -- public...veřejné stránky (přihlášení, odhlášení) -- templates...stránky se šablonami Šablony Velkou roli zjednodušující kód stránek hrají šablony definované pomocí faceletů (JSF Facelets ). Zabrání se tak zbytečnému opakování kódu hlaviček a zápatí. Definice šablony JSP stránky mandantu vypadá například takto: <?xml version="1.0" encoding="utf-8"?> <jsp:root xmlns:jsp=" xmlns:ui=" <ui:composition template="layout.jspx"> <ui:define name="title"> <ui:insert name="title"> Atribut title pro stránku není definován! </ui:insert> </ui:define> </jsp:root> </ui:composition> <ui:define name="menu"> <ui:include src="../includes/menu_mandant.jspx" /> </ui:define> <ui:define name="pane-content"> <ui:insert name="pane-content" /> </ui:define> 65

81 Tato šablona navíc využívá obecnou aplikační šablonu layout.jspx obsahující např. copyright, číslo verze či název serveru, na kterém aplikace aktuálně běží. Obsah stránky využívající tuto šablonu je pak doplněn do tagu ui:define s názvem pane-content. Ukázka využití šablony stránky mandantu u přehledu témat. <jsp:root xmlns:jsp=" xmlns:ui=" <ui:composition template="../templates/default_mandant.jspx"> <ui:define name="title">#{msg.overview_title}</ui:define> <ui:define name="pane-content">...obsah stránky... </ui:define> </ui:composition>... </jsp:root> 66

82 5.2.3 Ukázky uživatelského rozhraní Uživatelský profil Obrázek 28: Návrh obrazovky - Uživatelský profil Obrázek 29: Konečná obrazovka - Uživatelský profil 67

83 Vyhledávání témat (s menu) Obrázek 30: Návrh obrazovky - Vyhledávání témat Obrázek 31: Konečná obrazovka - Vyhledávání témat 68

84 5.3 Datová vrstva Aby mohly být doménové objekty ukládány či modifikovány v rámci datového zdroje (databáze), je nutné převést je na perzistentní. Transientní doménový objekt se stane perzistentním, pokud je asociován s Hibernate sezením. Implementace je jednoduchá: DomainClass foo = new DomainClass(); foo.setname("some domain object with name"); hibernatesession.save(foo); O spolupráci doménových objektů s databází, jejich perzistenci a přístupem k nim z vyšších vrstev se stará právě datová vrstva Mapování datového zdroje Pro úspěšnou asociaci doménových objektů s databázovými tabulkami je třeba specifikovat, které atributy jsou přiřazeny jakým sloupcům tabulek. O to se stará objektově-relační mapování a v projektu je řešeno pomocí XML souborů. Tyto soubory je možné snadno vygenerovat pomocí utility či pluginu do nástroje Eclipse IDE, ovšem za cenu menší kontroly nad vygenerovaným kódem. Proto byly XML mapovací soubory vytvořeny manuálně. Ukázka mapování POJO objektu na relační tabulku databáze DB2 pro třídu Topic (téma): public class Topic extends VersionedEntity {... } private String title; private TopicState state; private Date creationdate; Mapovací soubor XML: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="cz.generali.mercury.domain"> <typedef class="cz.generali.mercury.converters.genericenumusertype" name="topicstate"> <param name="enumclassname">cz.generali.mercury.domain.enums.topicstate</param> </typedef> <class name="topic" table="topic"> <id name="id" type="long"> 69

85 <column name="id_topic" /> <generator class="native" /> </id> <version name="version" column="version" type="long"/> <property name="title" column="title" type="string" /> <property name="state" column="topic_state" type="topicstate" /> <property name="creationdate" column="creation_date" type="timestamp" />... </class> </hibernate-mapping> Mapování výčtových typů (Enumerace) Pro výčtové typy není vhodné vytvářet speciální databázové tabulky a jejich mapování. Hodnoty těchto enumerací se takřka nemění, proto je nejjednodušší zapsat jejich definice přímo do kódu. Toto řešení má navíc jednu velkou výhodu. Vzhledem k tomu, že je aplikace lokalizovaná do několika světových jazyků, muselo by v případě databázového uložení enumerací existovat tolik sloupců s překladem dané hodnoty, kolik má aplikace překladů. S každým novým jazykem by pak pro všechny tabulky s enumeracemi musel být přidán nový sloupec s překladem daného výrazu. Ovšem v případě implementace výčtového typu pomocí Java Enumeration objektu je možné hodnoty získat odkazem s překladového souboru messages (viz kapitola 5.1.3). Překlad je pak také efektivně umístěn vždy v jednom zdroji pro celou aplikaci. Mapování enumeračního typu je provedeno pomocí nové definice typu (typedef). Pro správné vytvoření definice je použita generická třída GenericEnumUserType. Tato třída je parametrizovaná právě výčtovým typem. V dalším mapování je definice enumerace použita jako u standardních datových typů. Definice výčtového typu TopicState (stav tématu) v mapovacím souboru pro objekt Topic vypadá následovně: <typedef class="cz.generali.mercury.converters.genericenumusertype" name="topicstate"> <param name="enumclassname">cz.generali.mercury.domain.enums.topicstate</param> </typedef> 70

86 Mapování databázových pohledů (DTO objekty) Stejně jako databázové tabulky jsou mapovány i databázové pohledy. Pro tyto pohledy existují v Java kódu tzv. DTO (Data Transfer Object) objekty 6, které slouží pro asociaci pohledových dat a jejich následné zobrazení. Stejně tak je možné pomocí Hibernate tyto DTO objekty filtrovat dle kritérií či řadit pomocí Hibernate Order objektu DAO Každá doménová třída disponuje vlastním DAO objektem, který obsluhuje přístup její instance do databáze. DAO objektem se rozumí rozhraní přístupné pro vyšší aplikační vrstvy s patřičnou implementací závislou na vybraném typu datového zdroje. Obsahuje veškeré metody pro modifikaci, ukládání, načítání, filtrování či mazání doménového objektu v datovém zdroji. Právě implementace těchto DAO objektů zajišťuje perzistenci doménových objektů. Obrázek 32: Rozhraní a implementace DAO 6 DTO objekty jsou instance klasických Java tříd podobných třídám doménovým. Očekává se, že DTO objekty fungují jako přenoska dat, proto by neměly obsahovat žádnou logiku, ale pouze definici členských atributů a metody get a set pro tyto atributy. 71

87 Generické DAO Protože je každá doménová třída asociovaná s vlastním DAO objektem, bylo by nevhodné psát duplicitní kód metod, které bude zaručeně většina doménových objektů v rámci datové vrstvy potřebovat (persist, load, get, delete, update apod.). Pro zobecnění a zefektivnění práce je implementováno tzv. generické DAO, které tyto metody zajistí pro každou DAO třídu. Tato generická třída pak využívá metod utility HibernateDaoSupport, která přímo podporuje základní operace nad datovým zdrojem. public class HibernateGenericDao<T, ID extends Serializable> extends HibernateDaoSupport implements GenericDao<T, ID>, Serializable{ private Class<T> persistentclass; public void delete(t entity) { gethibernatetemplate().delete(entity); } public void refresh(t entity) { if(entity!= null) gethibernatetemplate().refresh(entity); } public List<T> findall() { return findbycriteria(); } public ID persist(t entity) { ID id = (ID) gethibernatetemplate().save(entity); return id; } public void saveorupdate(t entity) { gethibernatetemplate().saveorupdate(entity); } public void update(t entity) { gethibernatetemplate().update(entity); } } Filtrování navrácených dat (Criteria API) V informačním systému je vždy kladen požadavek na velké množství filtrací, řazení či jiných operací nad velkým množstvím dat. Pro usnadnění realizace těchto filtrů je vhodné vždy použít existující (či vlastní) framework. V tomto případě bylo ve spojení s Hibernate použito rozhraní Criteria API. 72

88 Toto rozhraní kvalitně pokrývá většinu operací a příkazů databázového dotazovacího jazyka. Programátor již píše pouze kontrolovaný Java kód bez nutnosti zajímat se konkrétní zápis v dotazovacím jazyku SQL. Ukázka metody z DAO objektu HibernateUserDao vracející objekt uživatele dle jeho uživatelského jména: public User finduserbyusername(string username) { DetachedCriteria criteria = DetachedCriteria.forClass(User.class); criteria.add(restrictions.eq("username", username).ignorecase()); List<User> users = gethibernatetemplate().findbycriteria(criteria); if(users!= null &&!users.isempty()) return users.get(0); return null; } Konfigurace DAO objektů (spring-data-access.xml) Díky použití frameworku Spring je jednoduché nastavit přístup DAO objektů ostatním vrstvám. Toto je provedeno pomocí XML konfigurace, která zajistí vytvoření potřebných bean (instancí DAO tříd) v případě jejich potřeby využití. Spring také zajišťuje vytvoření připojení k datovému zdroji na základě zvolených parametrů připojení (dle konfigurace database.properties viz kapitola 5.1.2). Při volání metod přistupujících k databázi již není nutné vytvářet spojení, Spring jej vytvoří v pozadí. <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:context=" <bean id="datasource" class="com.mchange.v2.c3p0.combopooleddatasource"> <property name="jdbcurl" value="${jdbc.url}" /> <property name="driverclass" value="${jdbc.driverclass}" /> <property name="user" value="${jdbc.user}" /> <property name="password" value="${jdbc.password}" />... </bean> <bean id="sessionfactory" class="org.springframework.orm.hibernate3.localsessionfactorybean"> <property name="datasource" ref="datasource"/> <property name="hibernateproperties"> <value> hibernate.current_session_context_class=thread hibernate.bytecode.use_reflection_optimizer=true... </value> </property>... 73

89 </bean> <bean id="abstractdao" abstract="true"> <property name="sessionfactory" ref="sessionfactory" /> </bean> <bean id="daofactory" class="cz.generali.mercury.dao.daofactory" factory-method="gethibernatedaofactory" /> <bean id="attachmentdao" factory-bean="daofactory" factorymethod="getattachmentdao" parent="abstractdao" /> <bean id="classificationdao" factory-bean="daofactory" factorymethod="getclassificationdao" parent="abstractdao" />... other beans configuration... <tx:annotation-driven /> </beans> 5.4 Aplikační logika Aplikační logiku lze rozdělit do několika oblastí s různým pohledem a zájmem: a) business logika (servisní vrstva, doménové třídy) Logika funkce systému jako business služby. Sestavená na základě funkčních požadavků a business procesů, b) doménová logika (doménové třídy) Implementace logiky doménových tříd z pohledu aplikace a realizace v daném programovacím jazyku. Jedná se např. o spojování atributů v doménové třídě do logických řetězců, či návrat hodnot atributů na základě vstupních podmínek, c) systémová backend logika (balíček utilit, importní a exportní továrny) Doplňkové třídy specializující se na určitou oblast systémové práce. Příkladem je specializovaná třída pro práci se soubory (FileUtils) poskytující metody pro návrat přípony z názvu souboru či nového názvu souboru v případě duplicity v cílové složce. Každá z těchto oblastí však nemá přesné určení a umístění. Nelze například říci, že business logika striktně patří pouze do metod servisní vrstvy, i když je k tomu servisní vrstva primárně určena. Zájmy těchto oblastí se tedy mohou vzájemně překrývat. 74

90 5.4.1 Servisní vrstva Podstatným rozdílem mezi umístěními zmíněných logických celků je přístup k datové vrstvě. Jedině služby servisní vrstvy totiž mohou přistupovat k metodám vrstvy datové přes rozhraní DAO objektů. To je pak realizováno díky injektivní poskytovanou Spring frameworkem. Stejně jako měly DAO objekty svého předka s implementací společných metod zastřešující zápis dotazovacího jazyka, mají i služby servisní vrstvy předka (abstraktního), který injektuje DAO, konfigurační a jiné objekty společné pro všechny servisní objekty. public abstract class AbstractService implements IAbstractService {... protected Configuration protected AttachmentDao protected ClassificationDao protected CombinationDao protected EventLogDao protected ImportDao protected TopicDao protected UserDao protected UserGroupDao protected UserSettingDao usersettingdao; V implementacích servisních metod se pak k těmto Spring objektům (beany) přistupuje snadno pomocí určení názvu těchto bean. Každá služba je také asociována s aplikačním kontextem Springu, neboť tyto služby využívá prezentační vrstva skrze Spring WebFlow. Tato asociace je public class TopicServiceImpl extends AbstractService implements TopicService public void deletereply(reply reply) { logger.info("mazu prispevek s ID: " + reply.getid()); Topic topic = reply.gettopic(); reply.delete(configuration.getattachmentsdir()); topicdao.update(topic); } }... 75

91 V ukázce je uvedena metoda deletereply, která nastaví příspěvku příznak smazáno. Třída Reply obsahuje metodu delete, která nastaví atributu deleted hodnotu true a smaže všechny soubory asociované s daným příspěvkem z disku. Adresář s přílohami je určen parametrem dle konfiguračního souboru (obsah souboru je v datovém zdroji - objekt typu Configuration). Nakonec je potřeba uložit provedené změny nejen v příspěvku, ale i v celém tématu, neboť příspěvek lze smazat pouze ze zobrazeného detailu tématu a je nutné, aby příspěvek po smazání na základě Ajax požadavku zmizel i z detailu tématu (data pro téma jsou znovu načtena z databáze). 5.5 Implementační problémy a jejich řešení Nezobrazení lokalizovaných textů při Ajax validaci Popis: Při ajaxové validaci JSF formulářů se nezobrazí v komponentě h:messages (či rich:messages) texty které jsou lokalizované. Příklad: <a4j:form> <rich:messages /> <h:inputtext label="#{msg.username_field}" value="#{username}" required="true" requiredmessage="#{msg.username_required}" /> <a4j:commandbutton value="send data" /> </a4j:form> Po odeslání tohoto formuláře (a nevyplněném vstupním poli username) se zobrazí chybový symbol, ale bez textu chyby (nenačte se). Chyba je v tom, že při ajaxové validaci se znovu nenačítají lokalizované texty z properties souboru (to by se dělo při klasickém odeslání odpovědi s kompletním obnovením stránky) a tudíž se v poli s chybami nezobrazí vázaná zpráva ze souboru messages.properties. Řešení: Pokud jsou ve stránce načítány externí lokalizované texty (messages) pomocí JSF tagu <f:loadbundle>, stane se přesně to, co je popsáno v příkladu. Místo tohoto tagu je nutné použít tag <a4j:loadbundle>, který je obsažen i v knihovně JSF tagů RichFaces. Ten zařídí to, že se lokalizované texty načtou při každém (i ajaxovém) requestu. 76

92 5.5.2 Klauzule GROUP BY v Criteria API V současné verzi Hibernate Criteria API bohužel chybí podpora SQL konstrukce Group By. Tento příkaz se dá ovšem sestavit manuálně vložením řetězce do SQL restrikce (Hibernate Restrictions součást Criteria API). criteria.add(restrictions.sqlrestriction( 1=1 GROUP BY this_.id_topic )); Metoda sqlrestriction napojí na vygenerovaný SQL dotaz za klauzuli WHERE zadaný řetězec v nativním jazyku SQL dle vybraného databázového dialektu. Očekává se tedy, že přijde podmínka, proto začíná řetězec podmínkou 1=1, která platí vždy. Tato konstrukce ještě není složitým případem. Problém přijde tehdy, pokud je před seskupením pomocí GROUP BY vytvořeno jedno nebo více spojení typu JOIN či jiná operace, kvůli které Hibernate vytváří aliasy tabulek. Potom není zřejmé, jaký název bude jaké tabulce přiřazen (obyvkle počáteční písmena tabulky spojená s generovaným indexem). Ke zjištění názvu aliasu byla použita funkce utility HibernateCriteriaUtil: public static String getcriteriasqlalias(criteria criteria, String asociationtablepath, String basetablealiasname, String sqlcolumn); Tato funkce vrací název aliasu cílové tabulky (zkrácený název lze zjistit - basetablealiasname) zahrnuté ve spojeních v přejatých kritériích (criteria). Sloupec, dle kterého má být seskupení provedeno je určen jak celou asociativní cestou 7 (asociationtablepath), tak SQL názvem v cílové tabulce (sqlcolumn). Použití v kódu pro seskupení pomocí identifikátoru přílohy v příspěvku vypadá následovně: String groupstatement = HibernateCriteriaUtil.getCriteriaSqlAlias (criteria, "replies.attachments.id", "attach", "ID_ATTACHMENT"); criteria.add(restrictions.sqlrestriction(groupstatement)); 5.6 Identifikace znovupoužitelného kódu Při implementaci složitějšího projektu se vždy najdou oblasti, ve kterých je možné využít již existující řešení. Stejně tak je možné identifikovat ve vlastním řešení kód, který je možné použít i v jiných aplikacích. Tato práce není pro programátory příliš lákavou, ovšem pro další vývoj je to způsob, jak ušetřit mnoho času při přemýšlení a vývoji nad něčím, co již existuje. 7 Cesta k cílovému sloupci získaná tečkovou notací přes závislé tabulky. 77

93 5.6.1 Klasifikační jádro Základ klasifikační hierarchie je možné použít pro další projekty, které využijí kategorizaci či jiný způsob klasifikace. Všechny typy klasifikací mají společného předka abstraktní třídu AbstractNode implementující základní operace nad uzlem hierarchického stromu (přidání potomka, vrácení objektu předka stromu apod.). Pomocí této třídy lze vytvářet kategorizační hierarchie s neomezeným množstvím úrovní, řadit je (obsahují řadící klíč) či porovnávat. Obrázek 33: Znovupoužitelný kód - klasifikační jádro Rozhraní Node reprezentuje uzel hierarchického stromu. public interface Node extends Comparable<Node> { public String gettitle(); public Node getparent(); public Serializable getid(); public List<Node> getchildren(); public Long getorderkey(); public void sortchildrenbyorderkey(); 78

94 } public void addchild(node node); public void removechild(node node); public void removeallchildren(); public int compareto(node o); Strom klasifikací Komponenta RichTree (tag rich:tree) z knihovny RichFaces umožňuje zobrazit stromovou strukturu elementů v hierarchickém uspořádání. Aby bylo možné využít obecné vlastnosti třídy reprezentující kořenový uzel tohoto stromu, byla navrhnuta a realizována vlastní implementace elementu stromu RichTree abstraktní generická třída RichTreeBean. Tato třída implementuje základní operace pro práci s RichTree stromem (načítání dat při obnovení nebo vytvoření stromu, předimplementace akce pro výběr prvku stromu apod.). Datové položky použité ve stromu jsou předány pomocí generického parametru T. Proto je tato implementace datově invazivní. public interface RichTree<T> { public TreeNode<T> gettreenode(); public void processselection(nodeselectedevent event); public void processnodeselection(nodeselectedevent event); public abstract void init(); public abstract void loadtree(); } V projektu ICP byla tato implementace využita pro sestrojení klasifikačního stromu. Třída ClassificationTreeBean využívá vlastností abstraktní třídy RichTreeBean a předává jí jako parametr datový typ Node (předek public class ClassificationTreeBean extends RichTreeBean<Node> implements Serializable {...} Použití v JSP stránce s RichFaces komponentou: <rich:tree var="item" id="treeview" advisenodeselected="#{classificationtreebean.advisenodeselected} advisenodeopened="#{classificationtreebean.advisenodeopened}" value="#{classificationtreebean.treenode}" > 79

95 80

96 6. Testování 6.1 Konfigurace testovacího prostředí Testovací prostředí bylo nakonfigurováno pro různé typy testů jiným způsobem. Přehled typu testů je uveden v kapitole 4.5. Vzhledem k používané firemní platformě na straně zadavatele a cílových uživatelů je nutné testovat aplikaci především v internetovém prohlížeči Internet Explorer Pro každý typ testování byl nastaven podrobný výstup do logovacích souborů na straně serveru. U každého logu je navíc evidován uživatel, který akci provedl, proto je snadné ihned najít příčinu a zdroj chyby, která mohla v systému nastat. Testovací subjekty obdrželi scénáře, dle kterých měli splnit zadané úkoly a otestovat tak většinu funkcí systému. Opakováním těchto scénářů lze zcela eliminovat nahodilé chyby i chyby, které se při jednorázovém otestování neprojeví. Testovací scénáře jsou uvedeny v příloze této práce. Lokální testování: - vývojová platforma s operačním systémem Windows Server 2003 a nainstalovanými prohlížeči internetu Internet Explorer verze 6.0, 7.0 a 8.0, Mozilla Firefox 3, Google Chrome 8, Opera 10 a Safari 5, - vzdálená databáze IBM DB2 v9.7. Testování v malém : - operační systém Windows Server 2003 (v rámci firemní platformy vývojové i zadavatelovi), - internetový prohlížeč Internet Explorer 7.0, Mozilla Firefox 3, - databáze IBM DB2 v9.1. Testování ve velkém : - operační systém Windows Server 2003, - internetový prohlížeč Internet Explorer 6.0, 7.0, 8.0, Mozilla Firefox 3, - databáze IBM DB2 v

97 6.2 Testovací subjekty Skupina cílových subjektů, tedy osob, které aplikaci testují, závisí opět na zvolené konfiguraci a typu testování. Pro účely lokálního testování se jedná pouze o skupinu programátorů, kteří spolu mohou přímo komunikovat a sdělovat si zkušenosti s testovaným systémem. V případě testování v malém a testování ve velkém jsou pak cílovou skupinou nejen vývojáři, ale také koncoví uživatelé, kteří budou aplikaci v případě úspěšného vývoje v budoucnu používat. Nejedná se tedy o běžné uživatele internetu, ale pouze o zaměstnance ze strany zadavatele, kteří budou mít přístup k aplikaci v produkčním prostředí. Tyto subjekty mohou objektivně ohodnotit vzhled a chování systému, programátor bere nakódované a jednou otestované funkcionality jako samozřejmé a po úpravě závislého kódu se již k opětovném testování většinou nevrací. Spojení subjektů z vývojového týmu a z koncových produkčních subjektů pak tvoří testovací skupinu nutnou pro zátěžový test paralelního přístupu více uživatelů ve stejném čase. Toto testování probíhá v rámci testů ve velkém. 6.3 Výsledky testování Nalezené chyby, nedostatky či přání na funkci systému byly v průběhu testování zaznamenávány do trackovacího systému Trac. Díky tomu bylo možné snadno spravovat výsledky testování a nové požadavky na systém. V rámci lokálního testování byla odhalena většina funkčních i vzhledových chyb či vad. Toto testování se opakovalo několikrát, dokud nebylo dosaženo naprosté eliminace chyb či chybových logů. Po úspěšném lokálním testování mohl být systém zpřístupněn k testování v malém. Během tohoto testování bylo nalezeno několik nedostatků a chyb: - vzhled komponent uživatelského rozhraní byl označen za složitý došlo ke zjednodušení (odstranění barevných přechodů), - ve vyhledávání se nezobrazovali témata se stavem uzavřeno tyto témata nemají být vidět pouze v úvodním přehledu, v ostatních přehledech jsou viditelná, - úvodní přihlašovací stránka se příliš dlouho načítala důvodem byla její velikost (3MB), toto vzniklo díky linkování a znovunačítání nepotřebných knihoven (nedocházelo k cachování), - malý limit počtu znaků pro název tématu uživatel potřebuje zadat delší název, než pole povoluje. S tímto byl navíc problém při vytváření tématu s automatickým připojením 82

98 názvu společnosti před jeho název. Pokud se délka názvu tématu blížila omezujícímu limitu počtu znaků a uživatel navíc zvolil, aby se po vytvoření k názvu přidal navíc název společnosti, došlo k překročení tohoto limitu. Při vstupu do editace tohoto téma pak uživatel nemohl provést úpravy, neboť ho validace upozorňovala na příliš dlouhý název tématu. V poslední fázi byl proveden zátěžový test a testování velkým množstvím subjektů v rámci testování ve velkém : - upozornění na konkurenční přístup k tématu se zobrazovalo i ve chvíli, kdy ke konkurenci nedocházelo, - chyba v přenosu sezení mezi produkčními servery bylo nutné serializovat objekty, které toto způsobily (tato chyba zjištěna pouze z logu, pro uživatele by se projevila při odpojení serveru, na kterém by aktuálně pracoval), - pomalá odezva aplikace při velkém množství dat v databázi. Toto zpomalení se projevila při vyhledávání pomocí všech kritérií (tvoří se nejsložitější databázový dotaz) mezi tématy. 83

99 84

100 7. Závěr 7.1 Srovnání s existujícími řešeními Při srovnání vyvinutého software s existujícími řešeními z úvodu práce lze říci, že největšími výhodami systému ICP oproti nejkvalitnějším systémům z diskuze existujících řešení jsou: - implementace všech kladených požadavků na systém, - striktní styl vývoje pro rozvoj aplikace do dalších verzí, - možnost výběru vlastních technologií a prostředků (není nutné nakupovat licence komerčních produktů, které by byly nutné při použití stávajících řešení), - naprostá kontrola nad kódem, snadná oprava chyb. Na druhou stranu existují i nevýhody. Od existujících řešení se očekává jejich bezchybná funkcionalita, což nelze tvrdit o systému ICP od nasazení první verze na produkční prostředí. Tento negativní faktor byl ovšem kvalitně redukován dlouhodobým testováním a opravami. 7.2 Možnost vývoje další verze Při práci s první produkční verzí napadne uživatele mnoho nových požadavků a vylepšení na systém. Jedním z klíčových požadavků zadavatele, ale i vývojového týmu byla proto možnost rozvoje projektu do nových verzí. Již během vývoje první verze se vyskytlo mnoho požadavků na druhou verzi. Některé z nich (lehce splnitelné) byly zahrnuty do první verze, ostatní byly pak zaznamenány do systému Trac. Na základě těchto požadavků může být provedena následná analýza a odhad pracnosti a ceny. Vzhledem k přehlednému a striktnímu vývoji informačního systému ICP co do stylu, kultury a obecnosti kódu není problém začít vývoj dalších verzí. 7.3 Shrnutí práce Hlavní cíle kladené na projekt informačně-komunikačního systému byly zcela splněny. Velká část vývoje byla zaměřena především na kvalitní analýzu a návrh cílové aplikace. Díky těmto fázím bylo možné implementovat kvalitní software bez nutnosti přepracování. Fázím analýzy a návrhu jsou věnovány dvě kapitoly v práci. Cíle kladené na rychlost, dostupnost a jinou důležitou vlastnost projektu mohly být realizovány také díky kvalitním firemním hardwarovým prostředkům (clustering serverů, velikost úložného prostoru, kvalitní databázový systém, ový SMTP server apod.). Díky kvalitnímu testování pak mohla být odstraněna většina funkčních chyb a nedostatků. 85

101 Vývoj informačního systému ICP přinesl nové zkušenosti nejen autorovi, ale i celému vývojovému týmu, neboť byly nalezeny nové nedostatky a bugy použitých technologií a prostředků. Tyto chyby byly zaznamenány pro informaci ostatním vývojářům. Složitá struktura témat byla vzorem pro management znovupoužitelného kódu, který je možné využít pro vývoj jiných komunikačních či informačních aplikací. Díky této práci byla obohacena autorova znalost moderních prostředků vývoje enterprise webových aplikací. Autor byl navíc seznámen s praktickými komunikačními i firemními procesy z oblasti pojišťovacího a finančního businessu. 86

102 8. Literatura [1] Oficiální stránky phpbb, [2] Vanilla forums, The best way to make your community grow, [3] Drupal, Come for the software, stay for the community, [4] extreme Message Board, [5] IBM Lotus Notes/Domino - Wiki, [6] ViewPoint solutions oficiální web, [7] BPMN Specification, [8] Přednášky o OOSP předmětu X36SSP. (Martin Molhanec 2007), [9] Elektronický dokument Gautama Banerjee: Use Case Points. Srpen 2001, [10] Smejkal Vladimír, Rais Karel: Řízení rizik ve firmách a jiných organizacích. Grada Publishing ISBN [11] IBM DB2 Software, [12] Seriál o PHP, [13] Bruce Eckel: Thinking in Java, 3rd Edition (volně dostupná elektronická kniha) 87

103 [14] Elektronický dokument Tomáše Matouška: Microsoft.NET & Java 2, [15] Matthew Moodie: Pro Apache Tomcat. APress ISBN-13 (pbk): [16] Oficiální stránky Jetty, [17] IntelliJ IDEA, The Most Intelligent Java IDE, [18] Mercurial SCM, Work easy, Work faster, [19] Dave Minter: Beginning Spring 2, From Novice to Professional. APress ISBN-13 (pbk):

104 9. Seznam použitých zkratek.net Dot NET (Network) API Application Programming Interface CMS Content Management System COCOMO The Constructive Cost Model CRM Customer Relationship Management DAO Data Access Object DB DataBase DMS Document Management System DTO Data Tranfer Object EA Enterprise Architect EJB Enterprise Java Beans FPA Functional Point Analysis GUI Graphical User Interface IDE - Integrated Development Environment J2EE Java 2 Enterprise Edition J2ME Java 2 Mobile Edition J2SE Java 2 Standard Edition JAR Java ARchive JDBC Java DataBase Conectivity JSP Java Server Pages JSF Java Server Faces MS - Microsoft MVC Model View Controller ORM Object Relational Mapping PHP Hypertext Preprocessor RDBMS Relational DataBase Management System SMTP Simple Mail Transfer Protocol SQL Structured Query Language UML Unified Modeling Language WAR Web Application Archive XML Extensible Markup Language 89

105 90

106 Příloha A. Obsah přiloženého CD /Diplomová práce.pdf /README.txt /appendix /icp /target /src text této práce nápověda ke spuštění projektu další přílohy práce ve formátu PDF složka s projektem vytvořeném v Eclipse IDE složka se zkompilovanými.class soubory a archivem WAR zdrojové kódy ukázkové implementace 91

107 92

108 Příloha B. User manual B.1 What is ICP application? ICP application is for shared communication between local companies and holding. Its basic item is so called topic. Topic is a web page similar to standard web discussion and it consists of following parts: Title of the topic which is simple description of whole topic. Header that contains several parameters according which you could easily find it (like company to which it relates, type, etc.). These properties are assigned at the beginning (i.e. when topic is created) hence no ex-post sorting should be performed. One or more replies written by users (i.e. text and possibly also attached files). They are for asking questions and provide answers, delivering files with data, providing guidelines, etc. They are order from newest one at the beginning to the oldest one at the end. This basic idea is supported by following two main features: Any change in the application (new topic, new reply, etc.) is send via to users that have access to this information (i.e. user rights to see it). Hence users are immediately informed about new requests, available guidelines, etc. These notification s could be 93

109 in fact deleted since all information is anyway stored in the application. Users could also customize in which cases would like to receive these notifications. It is easy to find topics either by browsing through tree structure of categories or doing search across all topics according any parameter (company, type, full text search, etc.). In general there are not so many documents (topics) as in standard communication since whole discussion about one topic is on one page. ICP is structured into independent subsystems. Each subsystem is for different purpose (for example subsystem controlling for communication between local and holding controlling, etc.). Subsystems are completely independent they could have, depending on purpose and organizational structure, different structure of companies, different types of topics, etc. Each user has via one username and one password access to ICP. Depending on its user rights he or she has access to one or more subsystems (for example controlling, consolidation, actuary, etc.), one or more companies inside given subsystem (i.e. to topics related to these companies), different functionalities inside given subsystem. This manual covers basic functionalities of ICP application that are available to standard users. Exact functionalities that are finally available to the user depend on each subsystem. B.2 Installing certificate If you connect to this address you will see that access is denied. In order to access the ICP application you should install your personal certificate that you received via from holding (file icp_user.p12 ). To install certificate follow instructions described in the next section according your internet browser (in most cases it is Internet Explorer). B.2.1 Internet Explorer Do following steps: In the main menu of Internet Explorer click on Tools and select Properties. Select folder Content and click on button Certificates. Select folder Personal and click in button Import. Click on button Next. Click on button Browse. Select a file with certificate and click on button Open. Do not forget to switch type of file to *.p12. 94

110 You should return on previous dialog. Click on button Next. Type a password that you received with certificate and click on button Next. Click on button Next. Click on button Finish. Certificate should be successfully installed. You should see it in the list of personal certificates. B.2.2 Mozilla Firefox Do following steps: In the main menu of Mozilla Firefox click on Tools and select Properties. Select folder Advances, subfolder Encryption and click on button Certificates. Choose folder Personal and click on button Import. Select a file, type password that you received with certificate and click on button OK. Certificate should be successfully installed. You should see it in the list of personal certificates. B.3 Logging into application When your user account in ICP application is created you should receive with your username and initial password. This you should type into following login page and click on Login. If you tick Remember me computer will remember your login information and next time you enter ICP and you do not have to type username and password again. In order to use this functionality you should NOT logout on main screen but just close web browser when you finish working with application (if you logout you would be asked for password again. We recommend doing this only on computers to which do not have access other users. After you first time login into the application it will asks you to change your password to new one. You should retype old password on type the new one two times. System checks strength of each new password and accepts only password with strength medium or higher (i.e. password should not be simple it should be at least 6 characters long and contain mixture of small and capital letters, numbers and special characters). B.4 Initial screen (overview) 95

111 After logging into ICP application you get to the initial screen called overview. It consists of main menu, administrator messages and overview list of topics. B.4.1 Main menu Main menu is present on each screen and consist of three parts. Left part: here you could select among main views which are overview, tree view and search (see sections below). Some users (depending on customization of the subsystem) have also access to do new topic. Middle part: contains you username and possibility of switching between subsystems. If you have access into more subsystems (for example controlling, consolidation and actuary) you could switch between them by clicking on icon of green arrows. Right part: contains logout from application, user settings (see section Settings below) and help. B.4.2 Messages from administrators Messages from administrators contain most important information from administrator of your subsystem and global administrator of whole ICP application. Please read it carefully since it contains information like when will be system shut down, important technical information and other things. 96

112 B.4.3 Overview list of topics Overview is a table with open questions, recent guidelines and other topics. Exact specification of items that are displayed (e.g. for how long for example guidelines stay in overview) depends on customization of each subsystem. Each row represents one topic. Note that only limited number of items (for example 20) is displayed on the page. You could navigate through pages using buttons in the bottom left part of the table. In the bottom right part you could select how many rows should be on each page. Total number of topics in the list is indicated in the bottom left part. Rows are marked with colors to distinguish between different types of topics, their status and deadline (for example open question before deadline is yellow, after deadline red and closed, i.e. solved, is green). Exact colors depend on customization of each subsystem. Columns of the table contain information about each topic: Topic title: title of the topic Type: type of topic (question, guideline, etc) Category / Subcategory: assignment of topic to tree of categories (for example Monthly statistics / 2010 January ) Country / Company: assignment of topic to companies. If topic is assigned to one company you see it directly. If it is assigned to more companies see just number of companies (whole list of companies could be displayed by clicking on the drop-down box). More companies are assigned for example in following cases: o question on inter-unit matching difference: assigned to two companies between which is difference o information/question about market: assigned to all companies in one country (for example 3 companies) o guidelines: assigned to all companies (for example 25 companies) Deadline: deadline till when given request should be solved. Not all topics have defined deadlines (for example guidelines, of course, do not have deadline). Changed: when was done the last change in the topic. Changed by user: who made the last change in the topic. You could click on the name of user to display additional information ( , phone, address, position, etc.). You could select topics related to one specific company by selecting it in drop-down box above the table. 97

113 Topics are in the table ordered according last change, i.e. on the top are topics that were changed recently. Tip: if you wrote answer to some question your name is displayed as user who made last change. Until the name is unchanged nobody else wrote reaction to your answer. You display any topic by clicking on its topic title. B.5 Topic B.5.1 Looking at topic On the top there is colored box with topic title. Color is according the same rule as in the list of topics in overview. In the top right corner of title there is topic ID (for example # 250). Topic ID is a unique number in given subsystem (topics are numbered 1, 2. 3, etc.). I.e. there are no two topics with the same number. Hence you can use it also as reference (for example to write for details see topic #250 ) and you could also search topic according its ID (see section Search below). Below topic title there is header that contains: Type (status): type and status of topic (for example open question, close question, etc.). Deadline: deadline till when given topic (for example question) should be solved. If topic do not have specified deadline this row is not displayed. 98

114 Category: assignment of topic to tree of categories (for example Monthly statistics / 2010 January ) Companies: assignment of topic to companies. Topic could be assigned to more companies. Created: when and who create the topic. Last change: when and who changed the topic last time. Closed: when and who closed the topic. Note that if a topic is reopened this information is again set to empty. Below header there are following buttons: New reply: for writing of a new reply in this topic (see section Replying to topic). Print: to display this topic in a layout suitable for printing. Send a review on my to send whole topic to your . Review is send immediately (i.e. it should come fast up to a minute depending on speed of delivery). Below buttons there are individual replies ordered from the newest to the oldest (i.e. newest is on the top). Each reply consist of two parts Left box: when and who wrote the last reply. Right box: text of a reply with attachments. Attachments could be downloaded by clicking on them. Note that you could click on the name of user in the header (right part of the table) or in any reply to get more information about this person. B.5.2 Replying to topic If you would like to write a reply into selected topic you should click on the button New reply and following dialog should appear (note that it is not possible to reply in a topic that is closed). 99

115 Here you could write your reply in the field Text of a reply. You could use also formatting it by additional buttons in the field (for example B for bold text, I for Italic, etc.). If you would like to add attachments to the topic click on button Browse in the section Attachments, select file from you local computer and then wait until it is uploaded (it should appear in the box Uploaded files ). To remove already uploaded file click on its name in the box Uploaded files and file should disappear. When reply is prepared click on the button Save. System will then display the whole topic and your reply should be the first one (the newest one). Note: due to technical reasons only not-formatted text could be pasted into reply. Hence in case you pasting some text special window appear. Then you paste your text into this window and click on insert. Text will be inserted without formatting. B.5.3 Notification s Immediately when new reply appears in any topic notification is send to all users that have right to see given topic (i.e. to users that have access to this topic). Each user have possibility to customize when would like to receive notifications (see section Settings below). Notification is not send to user that reply created (see additional notifications in the next paragraphs). Each notification contains main information about topic (namely its full header) and new reply. Attachments that are assigned to reply are sent also unless they are too large (attachments 100

116 larger than 1 MB are not send). contains also direct link to topics and by clicking on it web page with given topic is directly opened. Here you could see full topic with all replies, attachments and other information. Note: do not reply to notification since it is generated automatically by ICP application! Tip: if you use Remember me in login screen you do not have to log in when you click on link in notification and topic is directly displayed. Tip: you could delete notification s that you received since all information is stored in the application and you could easily find it there (see section How to find existing topic). This could significantly reduce size of your mailbox. When you writing reply you have two options how to send additional notifications: By ticking on Send me notification too you will also receive notification . This could be useful if you would like to forward your reply to somebody else. You could also send additional notification to some other persons (that for example do not have access into ICP application) by writing their addresses into field Send additional notification on following addresses. B.6 How to find existing topic You have basically four ways how to find existing topic as follows. B.6.1 Using overview If you are looking for open question or some recent guideline most probably you could find it directly in the overview (i.e. initial page of application). Overview could also display it by clicking in the main menu on item Overview. B.6.2 Using tree view All topics (open or closer, recent or older) are available through tree view that you could access by clicking in the main menu on item Tree view. Here you have opportunity to browse whole tree of categories and find any topic to which you have access (i.e. user rights). Here are the main things that should be outlined. Note that list is displayed only if you select some subcategory, i.e. nothing is displayed if you select category or main root of the tree (list would be too long). 101

117 Additionally you could also filter topics related to one company by selecting it in drop-down box. You display any topic by clicking on its topic title. B.6.3 Using search If you are not able to find a topic in overview or using tree view you could enter search by clicking in the main menu on item Search. Here you could search through all topics to which you have access according almost any parameter of topic. Here are the main things that should be outlined. To display result of search you have to click on button Search. Initially only main fields are displayed. By clicking on Display detailed search you display full range of fields for search. Button Delete filter reset all fields, i.e. they will be empty. You could display additional information of topics (i.e. additional columns) by selecting them in section The resulting columns. 102

118 Topics are displayed are not only a simple list but you have possibility to click on the icon + that is at the beginning of each row and expand each topic into individual replies. You could also expand all topics at once clicking on button Unpack all (and vice versa by button "Pack all"). If you filter according text of a reply, reply date or attachment then there are displayed only replies that match given filter (i.e. you see only some replies). For example if you filter text of reply expenses and given topic has 10 replies of which 3 contain word expenses then only these 3 that fit to the condition are displayed. To see all replies you have to click on topic title and enter into the topic. If you search according attachment filename you have to specify name exactly or use * (for example *.xls to search for all Excel files). If you search attachment file by size (min and/or max), type only numbers please. Search is in Bytes (B) (i.e in search is 1000 B = 1kB files). If you search by Keywords, you can filter by more keywords separated by ";". You display any topic by clicking on its topic title. Examples of search: all new things (i.e. all changes) done through last week: o set date in the field Last change from equal to day one week ago all new things (i.e. all changes) done through last week related to one company: o set date in the field Last change from equal to day one week ago o select a country and company in the fields Country and Company items closed during last month o set date in the field Closed from to day one month ago full text search for word expenses (in all replies) o set the field Text of a reply to expenses searching topic number 123 o set filed Topic ID to 123 B.6.4 Using notification If you have a notification you could simply click on the link and it directly displays the whole topic. 103

119 B.7 New topic In some subsystems standard users do not have right to create a new topic or change of properties of existing topic. I.e. they could write replies into existing topics but they cannot create new topic. B.7.1 Creating a topic For creating a new topic click on New topic in the main menu. In the upper part you fill in properties of topic: Topic title: title of the topic. Topic type: type, i.e. question, guideline, etc. Status: whether topic should be initially opened or closed. System will automatically setup this property based on selected type. Keywords: one or more keywords assigned to topic. To write more keywords separate them by ; (for example expenses; production ). Deadline: till when given request should be solved. For some topic types you have to specify deadline, for some types deadline could be specified (but no necessary) and for some types deadline is not allowed. Category and Subcategory: assignment of topic to tree of categories and subcategories. Available and Assigned companies: assignment of topic to companies. You could select one or more companies by clicking on their names or by clicking on buttons Copy all or Remove all. Important is what remains in the right box (i.e. to these companies will be assigned this topic). Text of a reply: the first reply in topic. 104

120 Attachments: files attached to the first reply (for details see section Replying to topic). Send me notification too: see section Replying to topic. Send additional notification on following addresses: see section Replying to topic. When you fill in all parameters you will create a topic by clicking on button Crate shared topic. By this action you will create one topic into which have shared access people from companies you selected in the box Assigned companies. System will afterwards display you the topic that you just created. Notification s are immediately send to all users that have user rights to see this topic (depends also on the way they customized their notifications see section Notification s). B.7.2 Creating more topics at once In some cases you would like to create for example 10 individual topics for 10 companies, i.e. each company should have one individual topic to which have access only people from this company. Here you could use select these companies in the box Assigned companies and click on Crete individual topics. If you selected 10 companies system will create 10 topics (to each topic will be assigned exactly one company). All topics will have same title, type, deadline, etc. If option Add companies names to the topic titles is checked system will add also the name of the company to the title of each individual topic. If you for example write into title of topic Quarterly presentation and this option is checked one topic assigned to company Czech R. / Generali will have title Quarterly presentation (Czech R. / Generali). Like this you could easily distinguish between topics (they do not have the same title). B.7.3 Closing and changing of topic When certain topic is solved (for example question is fully answered) you could close the topic. This could be done by clicking on the button Close topic in the header of topic. If you would like to reopen topic you could click on the button Edit topic in the header of topic and change its status to Open. This way you could also change other properties of the topic like title, type, assigned companies, etc. Change of properties also generates notification s. 105

121 B.8 Settings B.8.1 Information about user You could display your personal information by clicking in the main menu on item Settings and selecting folder Information about a user. Here are main things that should be outlined. Please keep information up to date. Keep your address up to date. If the address is incorrect you will not receive any notification ! Use following format for your phone number (+country code) local phone number (for example (+420) ). If you have access into more subsystems (for example controlling, consolidation and actuary) you could select which of them should be displayed initially by selecting it in the field Initial subsystem. After any changes you should click on Save otherwise the changes are lost! You could change your password clicking on button Change password. B.8.2 Notification s You could customize your notification s by clicking in the main menu on item Settings and selecting folder Notification s. At the beginning (at least for few weeks) we suggest to keep initial customization. Notifications work as follows. You create one or more combinations of category or subcategory plus country or company and for each combination you assign which notifications you would like to receive. Example: you have one combination TMR Czech R. / Generali to which is assigned notification New topic. If there is created new topic assigned to subcategory TMR / and company Czech R. / Generali you will receive notification (in case you have according your user rights access to Czech R. / Generali ). When you user account is created you have setup one combination controlling controlling which means all categories and subcategories all countries and companies. For this combination all kinds of notifications are assigned. Like this you receive information about all changes in 106

122 application (of course only to those topics to which you have access). You could change ot as follows. You could create new combination by selections category or subcategory and country or company in the two drop-down boxes at the top and then clicking on Create a combination. Given combination then appears in the list of available combinations. If you select one available combination you would see a list of available notifications (left bottom box) and notifications that are assigned to this combination (right bottom box). You could move notifications between left and right box by clicking on them (for example clicking on text New topic ) or by clicking on buttons Copy all or Remove all. Important is what remains in the right box (i.e. for this list of actions you will receive notification s). You have to press "Save changes" immediately after you change assigned notifications (i.e. you have to press it individually for each of combinations). Otherwise assigned notifications will not be saved! Any available combination could be deleted by selecting it from the list and clicking on Delete combination. If you delete all combinations you will not receive any notification . Exact meaning of each notification is as follows: New topic: new topic is created. New reply: new reply in existing topic is created. Close topic: existing topic was closed. Topic properties changed: change of title of topic, type, status, deadline, etc. (also when already closed topic is reopened). Topic moved: topic was moved from one subcategory to another or from one company to another. Also in case when topic was assigned to you company (i.e. from the point of view of you company it is like a new topic but it already existed before but was not assigned to you company). Example: you are responsible for all companies in Czech R. that are Ceska Pojistovna, Generali and Pension Fund. You create following combinations: 1. controlling Czech R. / Ceska Pojistovna and assign all notifications, 2. TMR Czech R. / Generali and assign all notifications, 107

123 3. Plans Czech R. and assign only notification New topic. In this case you would get notification to: 1. any change related to Ceska Pojistovna (i.e. new topic, new reply, etc.), 2. any change related to TMR of Generali (i.e. new topic, new reply, etc.), 3. any new topic related to plan of all companies in Czech R. (i.e. Ceska Pojistovna, Generali and Pension Fund). B.9 Flash player installation Some components in application require Flash Player (for example component for adding attachments from your local folder to replies). In most cases Flash Player is installed automatically by your web browser. If not and this component does not work properly you should install it manually. To install it do following steps. Go to page. Uncheck all other items in section Also install in order to install only Flash Player Click the Agree and install now button and follow the instructions. B.10 Bug reporting Since no system perfect following section describes what to do in case of error. 108

124 B.10.1 Please wait dialog In case following Please wait dialog remains for longer time on the screen (more than 1 minute) please refresh the web page either by pressing F5 or clicking on the refresh button in your web browser. B.10.2 Error If error occurs (see picture below) send to holding containing following information: Describe in detail in which situation it happened. For example: I was in topic number #123, I clicked on new reply, wrote a text and when I pressed Save error occurred. Copy-paste the error text from web page into . Error text could be long but please copypaste it whole (i.e. whole web page). This would help us to identify the error and fix it in application. 109

125 110

126 Příloha C. Administration manual C.1 System administration System administration page is automatically showed after login for system administrators (user with this application role). Other way to go to this window is clicking the button Administration from the main menu. If the button is not visible, this means, you are not a system administrator. In system administration user can do some common application actions as: Publish system message which is showed in overview window (in all subsystems). This message serves to publish an important application messages. Manage subsystems. Administrator can create subsystem with initial settings as name of subsystem, language in which subsystem will be translated or address of this subsystem. Through links in this subsystem overview administrator can go to subsystem administration (described in chapter 2). Filter and search users existing in whole application. Is possible to export this user lists to XLS or TXT file. System administrator can edit common user information in his profile as name, nickname or address (in subsystem is possible to change data which are dependent on the subsystem as roles or notification settings). Only system administrator can unblock blocked user (by user profile window). Export system log (events done by all users from all subsystems including records about login) C.2 Subsystem (mandant) administration C.2.1 Basic settings Administrator can change basic settings of this subsystem, export log events to the text file or import data to application in this section. Basic Subsystem s message is an information which is visible in topic overview. This warns users to some important changes or news in this subsystem. Administrator can change skin of a subsystem too (it means that every page will be styled by selected skin colors). 111

127 Export log This form makes it possible to export information about user s events done in the subsystem. Administrator can export only events limited by date (from or to). Data import The most important part of this page provide interface for importing topic data from prepared file batches to an application subsystem. Administrator can prepare import batch by this instructions: First, administrator must create XML file with import configuration (topic identification, replies texts, attachment file paths etc.). If batch content some attachments, it s recommended to add all import files with XML configuration to ZIP archive, which is easy to import. Third, to start import, administrator must browse the archived import file, upload it and click on the Start import button. Finally an import is proceeded successfully (replies with attachments are saved and notifications are sended) or finished with some error. The common exceptions (errors) that can occur during import file process are: o Bad file structure, it s not possible to upload file. Common technical causes: Unsupported encoding: windows-8 this exception signals that XML file has encoding which is not supported by ICP 112

128 org.springframework.oxm.unmarshallingfailureexception: JiBX unmarshalling exception; nested exception is org.jibx.runtime.jibxexception: Expected "Topic" end tag, found "Reply" start tag (line 4, col 3) this exception signals, that XML file is not valid (it contain some strange tag, or some invalid value). In this case, XML contains Reply tag, which is not allowed. o It is not possible to find xml file for topic import, it should be named import.xml this exception can occur when zip file doesn t contain import.xml file. o It is not possible to find entries with a title [path of the file] in the imported zip file this exception can occur when import.xml file contain some attachment, which is not contained in zip file. o You have no permission to add replies to topic [topic number] this exception can occur, when unauthorized user try to upload reply to topic. C.2.2 Users There is page for managing users in subsystem. Administrator can search all users from the application and filter them by some criterions. Filtered user lists can be exported to XLS or TXT file format. For one user is possible to do several actions: Add to subsystem / Remove from subsystem - administrator can find existing users in the application and add them into his subsystem by clicking Add to subsytem link or remove user from subsystem by clicking Remove from subsystem link. After adding user to subsystem, system automatically create subsystem account for this user (default settings of notifications etc.). By removing user from subsystem, this settings are deleted. Edit user profile can be also edited by administrator (in subsystem, administrator can assign subsystem roles which is not possible for logged user to edit ourself roles). Block user can be blocked by subsystem administrator (for blocked users is not possible to login into application), but unblocking can do only system administrator. History overview about user activity in subsystem New user By this form can be created a new user profile in the application (assigned to current subsystem). First, administrator must fill basic information about the user. Next, administrator assign subsystem roles (permissions) to the user. After saving, it s possible to set notifications settings. 113

129 C.2.3 User roles For user access to topics there are user roles. The user role is defined for one concrete subsystem and is described by permission settings for combination of category and company structure (for more information about application structures see chapter 2.e). After creating user role and assigning users to it, this users have set of permissions, which say what them to do in selected structure elements (category, subcategory, country or company with topics) for defined user role. There are also several actions to do with user roles: Edit administrator can chnage name or description of user role. Delete deleting user role from application. Assign users by this window users can be added/removed to/from user role. Assign permissions administrator must define combinations of structure elements (from category view and company view) and assign some permissions for it (what users can to do in this classifications). User list list of assigned users to user role (can by exported to XLS or TXT, s of these users can be copied to clipboard) C.2.4 User groups User groups serve to making user overviews. This screen is very similar to previous user roles. But for a user group is not possible to define permissions. 114

130 C.2.5 Topic hierarchy In ICP, topics are assigned into two type of structure elements (classifications) category and company elements. These classifications are associated with each other by parent/children relationship. This means that it looks like tree structure (categories as roots contents subcategories as leafs and countries as roots contents companies as leafs). Whole classification structure is created by this screen topic hierarchy. Classifications at same level are ordered by order key (if order keys are equals, ordered by title) it is a number in brackets after classification title and administrator can choose it. Classification cannot be deleted if contains some topics. C.2.6 Topic types Every topic have a type that describe his behaviour. After deleting a topic type, it is possible to restore it. There are some attributes of topic type that are important to describe for understanding: Type title describe a topic type. Default status designates which status can by set for topic by default. Deadline whether deadline must be required. Open status expiration (in days) after this time from topic last change will be topic invisibled in topic overview (declared for status OPEN) Closed status expiration (in days) after this time from topic last change will be topic invisibled in topic overview (declared for status CLOSED) Colors colors defined for topic in different states (it depends on topic status and deadline) 115