Bc. Tomáš Hladík. Vytvoření prezentační vrstvy a rozhraní systému pro integraci a vyhledávání informací

DIPLOMOVÁ PRÁCE

Bc. Tomáš Hladík Vytvoření prezentační vrstvy a rozhraní systému pro integraci a vyhledávání informací

Katedra softwarového inženýrství

Vedoucí diplomové práce: Studijní program: Studijní obor:

Doc. Mgr. Martin Nečaský, Ph.D. Informatika Softwarové inženýrství

Praha 2016

Prohlašuji, že jsem tuto diplomovou práci vypracoval(a) samostatně a výhradně s použitím citovaných pramenů, literatury a dalších odborných zdrojů. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona v platném znění, zejména skutečnost, že Univerzita Karlova má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle S60 odst. 1 autorského zákona.

V Praze

dne 28.7.2016

Podpis autora

i

Název práce: Vytvoření prezentační vrstvy a rozhraní systému pro integraci a vyhledávání informací Autor: Bc. Tomáš Hladík Katedra: Katedra softwarového inženýrství Vedoucí diplomové práce: Doc. Mgr. Martin Nečaský, Ph.D., Katedra softwarového inženýrství Abstrakt: Cílem této práce je analyzovat, navrhnout a implementovat systém pro prezentaci business objektů, které jsou dostupné skrze již existující RESTful API. Data pocházejí z integračního systému, který je spojuje z různých zdrojů a publikuje společně s informacemi o způsobu jejich uložení. Tato práce si klade za cíl vytvořit pohledy na data, jež splňují následující požadavky – reakce na změnu metadat, více výstupních formátů a uživatelsky nastavitelné pohledy. Aplikace má být snadno modifikovatelná a napojitelná i na již existující webové systémy. Klíčová slova: webové stránky, prezentační systém, šablony, vícevrstvý systém, transformace dat

Title: Presentation layer and interface for a system for information integration and search Author: Bc. Tomáš Hladík Department: The Department of Software Engineering Supervisor: Doc. Mgr. Martin Nečaský, Ph.D., The Department of Software Engineering Abstract: The aim of this thesis is to analyse, design and implement a system to present business objects. These objects are accessible through an existing RESTful API of an integration system. The system combines various sources and publishes them together with information how these data are stored. The task of the thesis is to create data views that meet the following requirements - they can react to metadata changes, they support multiple output formats and these views can be customized. The application should be easily modifiable and connectable to already existing web systems. Keywords: web pages, presentation system, templates, multilayered system, data transformation

ii

Tímto bych chtěl poděkovat Doc. Mgr. Martinu Nečaskému, Ph.D. za jeho čas při osobních schůzkách, inspirativní a věcnou diskusi. Současně také společnosti C42 s.r.o. za poradenství v oblasti business inteligence a jejich návrhy, především však Ing. Ondřeji Pánkovi za jeho přínos při vývoji systému, jehož je tato práce součástí. V neposlední řadě si vážím i podpory rodiny, která mi nejen že umožnila vysokoškolské vzdělání, ale také mě podpořila při mém semestrálním studiu na University of Portsmouth v rámci programu Erasmus+.

iii

Obsah Úvod

4

1 Předpoklady práce 1.1 Cíl práce . . . . . . . . . . . . . . 1.2 Integrační část . . . . . . . . . . 1.2.1 Podporované datové zdroje 1.2.2 Popis dat . . . . . . . . . 1.2.3 Katalog dat . . . . . . . . 1.3 Výstupy integračního systému . .

. . . . . .

. . . . . .

. . . . . .

2 Podobné projekty 2.1 Microsoft SharePoint . . . . . . . . . . 2.2 Prohlížeče dat . . . . . . . . . . . . . . 2.2.1 Zobrazení dat ve formátu JSON 2.2.2 Sémantický web . . . . . . . . . 2.2.3 Šablonovací systémy . . . . . . 2.2.4 Jednoduchá vizualizace dat . . 2.3 Shrnutí . . . . . . . . . . . . . . . . . . 3 Analýza 3.1 Záměr projektu . . . . . . . . . . 3.2 Hlavní požadavky na systém . . . 3.3 Problémy prezentační části . . . . 3.3.1 Různé formáty výstupů . . 3.3.2 Změna dat . . . . . . . . . 3.3.3 Uživatelský vstup . . . . . 3.3.4 Načítání atributů a externí 3.4 Slovník pojmů . . . . . . . . . . . 3.5 Seznam požadavků . . . . . . . . 3.5.1 Funkční požadavky . . . . 3.5.2 Kvalitativní požadavky . . 3.6 Případy užití . . . . . . . . . . . 3.6.1 Uživatel . . . . . . . . . . 3.6.2 Administrátor . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 5 6 7 9 10 13

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

14 14 15 15 17 18 19 21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . stránky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

22 22 23 23 23 23 24 24 24 25 25 27 29 29 31

. . . . . . . . .

32 32 33 34 34 35 35 36 36 38

. . . . . . .

4 Návrh a architektura systému 4.1 Princip fungování . . . . . . . . . . . . . . . 4.2 Volba použitých technologií . . . . . . . . . 4.3 Struktura pohledů . . . . . . . . . . . . . . 4.3.1 Vytváření pohledů . . . . . . . . . . 4.3.2 Vytváření pohledů - na straně klienta 4.3.3 Ukládání pohledů . . . . . . . . . . . 4.3.4 HTML šablony . . . . . . . . . . . . 4.3.5 HTML šablony - druhá verze . . . . 4.3.6 XML šablony . . . . . . . . . . . . .

1

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

4.4

4.3.7 Shrnutí . . . . . . . . . . . . . . . . . Architektura aplikace . . . . . . . . . . . . . . 4.4.1 Pohled na moduly a jejich komponenty 4.4.1.1 Klient modul . . . . . . . . . 4.4.1.2 Komunikační modul . . . . . 4.4.1.3 Modul šablon . . . . . . . . . 4.4.1.4 Integrační obal (wrapper) . . 4.4.1.5 Databázový obal (wrapper) . 4.4.1.6 Návrh databáze . . . . . . . . 4.4.2 Pohledy na důležité procesy . . . . . . 4.4.2.1 Vykreslení šablony . . . . . . 4.4.2.2 Vytvoření šablony . . . . . . 4.4.2.3 Změna parametrů . . . . . .

5 Uživatelská dokumentace 5.1 Instalace prezentační vrstvy . 5.1.1 PDF exporty . . . . . 5.1.2 Konfigurace parametrů 5.2 Funkcionalita systému . . . . 5.2.1 Vyhledávání dat . . . . 5.2.2 Detail entity . . . . . . 5.2.3 Editace pohledu . . . . 5.2.4 Správa pohledů . . . . 5.3 Struktura pohledů . . . . . .

. . . . . . . . .

6 Pohled programátora 6.1 Napojení externí stránky . . . . 6.2 Rozšířitelnost pohledů . . . . . 6.2.1 Formát výstupu . . . . . 6.2.2 Bloky dat a jejich funkce 6.3 Komunikační modul . . . . . . 6.3.1 Data Resource . . . . . . 6.3.2 Search Resource . . . . . 6.3.3 Template Resource . . . 6.4 Přehled balíčků a složek . . . . 6.4.1 Java část . . . . . . . . . 6.4.2 Javascript část . . . . . 6.5 Programátorská dokumentace .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

7 Akceptační testy 7.1 Hlavní funkcionalita systému . . . . . 7.2 Procházení mezi detaily entit . . . . 7.3 Změna pohledů na data . . . . . . . 7.4 Zobrazení detailu . . . . . . . . . . . 7.5 Změny metadat . . . . . . . . . . . . 7.6 Administrace šablon a jejich bloků . . 7.7 Administrace zobrazení entit a šablon Závěr

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . .

38 40 40 41 44 44 45 47 47 48 49 50 51

. . . . . . . . .

52 52 53 53 54 54 55 57 59 60

. . . . . . . . . . . .

61 61 62 62 63 63 63 64 64 65 66 67 67

. . . . . . .

68 69 70 71 72 73 74 75 76

2

Seznam použité literatury

77

Seznam obrázků

79

Seznam tabulek

81

Seznam použitých zkratek

82

Přílohy

84

3

Úvod Tato diplomová práce si klade za cíl navrhnout a implementovat prezentační vrstvu již existujícího integračního systému, který slouží jako databáze budoucího většího celku vyvíjené aplikace. Integrační vrstva vznikla jako diplomová práce Ing. Ondřeje Pánka na Českém vysokém učení technickém v Praze pod vedením Doc. Mgr. Martina Nečaského, Ph.D. (Pánek, 2015). Tato část měla za cíl publikovat data z více datových zdrojů skrze webové služby pro další zpracování. Výsledná aplikace vzniká jako produkt společnosti C42 s.r.o., která svými nápady, požadavky a cennými radami stojí za vznikem této práce. Hlavní náplní společnosti je zpracování a prezentace dat, to znamená tvorba přehledných grafických výstupů, reportů a dalších zdrojů dat. Touto aplikací je potenciálně možné rozšířit produktové služby společnosti v oblasti business inteligence. Záměrem práce je vyvinout systém, který by intuitivně zobrazil získaná data na základě informací o způsobu jejich uložení. S tím souvisí rozumná reakce na změny struktury dat, které často ovlivní jejich samotné pohledy. Dalšími požadavky jsou správa pohledů, vyhledávání a zobrazení dat v různých formátech. Samotná práce nejdříve představí cíle práce a datovou část, která tvoří vstupní část vyvíjeného systému. Následně se zaměříme na podobné projekty, které byly důležité jako inspirace pro tuto práci. Poté budou definovány požadavky na funkce a kvalitu aplikace, po nichž následuje detailní rozbor návrhu a architektury systému. Poslední větší část tvoří uživatelská a programátorská dokumentace. Závěrem si projdeme akceptační testy společnosti, ze kterých mohou vyplynout další požadavky pro rozšíření aplikace.

4

1. Předpoklady práce V dnešní době se setkáváme s velkým množstvím dat, která společnosti vlastní, produkují nebo také zpracovávají. Velké množství informací bývá uloženo v různých datových zdrojích a jejich společné provázání a procházení není až tak triviálním problémem. Přesto ale může být přínosné data propojit a získat jedním kliknutím během několika málo okamžiků větší množství informací. Z předchozího odstavce tak plynou dva základní problémy: jak data spojit a jak je následně zobrazit na jedné stránce. První část řešil ve své diplomové práci Ing. Ondřej Pánek (2015) na Fakultě elektrotechniky na Českém vysokém učení technickém v Praze. Druhý problém, tedy samotné zobrazení dat, je náplní této práce. Záměrem společnosti C42 s.r.o. 1 je vytvořit systém, který zvládne prezentovat data z různých datových zdrojů na jednom místě. Vzniká tedy systém založený na vícevrstvé architektuře, kdy tato práce popisuje prezentační vrstvu. Datová vrstva aplikace již byla vytvořena v rámci dříve zmíněné práce. Cílem této vrstvy bylo vytvořit systém, který z různých datových zdrojů dokáže publikovat objekty, jejichž provázané informace se nacházejí na různých místech, případně i v různě uložených formátech.

1.1

Cíl práce

Prezentační vrstva systému pro integraci a zobrazení dat řeší samotný problém zobrazení informací uživateli. Od této vrstvy je vyžadována především intuitivní prezentace dat ve formátu HTML, procházení jednotlivých provázaných entit, jejich vyhledávání a filtrování. Problémovou částí systému je změna dat, na kterou musí datové pohledy spolehlivě reagovat. Současně musí být aplikace připravena na rozšíření o zobrazení dat v jiných formátech. Vrstva dále umožní zobrazit data 1

http://www.c42.cz

5

integračního systému na externích stránkách, tedy může být napojena na další projekty společnosti C42 s.r.o.. Cílem této práce je systém implementovat a popsat jednotlivé fáze vývoje tohoto softwaru. Prvotně se jedná o seznámení se s integračním vrstvou a její pochopení. Následuje sběr a analýza jednotlivých funkčních i kvalitativních požadavků a na jejich základě bude nutné navrhnout architekturu aplikace. Nedílnou součástí musí být také dokumentace systému pro uživatele i programátora. Práce bude zakončena akceptačními testy systému s důrazem na zmínění další možné rozšiřitelnosti a použitelnosti systému.

1.2

Integrační část

V první kapitole si postupně představíme již existující integrační systém a jeho navázání na prezentační vrstvu výsledné aplikace. Integrační vrstva spojuje informace z různých datových zdrojů na základě jejich identifikátorů, na výstup se poté dostanou data ve formátu JSON. Společně s daty lze získat i jejich metadata, tedy dodatečné informace popisující konkrétní typ dat. Na základě těchto výstupních dat integračního systému a katalogu bude nutné vytvořit aplikaci, která zvládne data rozumně vykreslit a současně také reagovat na potenciální změny, které mohou nastat. Těmito změnami lze chápat nové nebo smazané atributy u datových entit, případně změnu metadat atributů nebo samotných entit. Celkový systém bude následně použit pro interní účely společnosti, případně může být poskytnut i zákazníkům, kteří by podobný problém také mohli řešit. Na obrázku 1.1 je znázorněná základní struktura celé vyvíjené aplikace a její rozdělení na dva základní moduly - integrační a prezentační vrstvu.

6

Obrázek 1.1: Základní struktura cílové aplikace

1.2.1

Podporované datové zdroje

V tuto chvíli integrační část podporuje pět různých formátů uložení dat ze šesti různých zdrojů, viz obrázek 1.2.

Obrázek 1.2: Podporované datové zdroje a formáty

7

Do integračního systému je momentálně připojeno šest datových zdrojů, které je možné v případě nového požadavku rozšířit. Podobně je myšleno také na rozšiřitelnost týkající se formátů uložených dat, která také není striktně vázána jenom na uvedenou pětici formátů. Následuje detailní popis používaných dat:

1. SQL - dotazovací jazyk relačních databází (a) ARES RDB - Administrativní registr ekonomických subjektů 2 - jedná se o hlavní zdroj dat, který obsahuje informace o všech akciových společnostech v České republice. ARES je spravován Ministerstvem financí České republiky a databáze vznikla jako dočasný datový zdroj z veřejně dostupných informací jako simulace funkčnosti nad relačními databázemi 2. XLS - formát tabulkového procesoru aplikace Microsoft Office Excel (a) Strukturální fondy EU

3

- Ministerstvo pro místní rozvoj publikuje seznam úspěšných žadatelů o dotace v rámci programu strukturálních fondů EU (b) Zdravotní pojišťovna Ministerstva vnitra České republiky

4

- publikuje seznam dlužníků, jejichž penále a celkové dluhy na pojistném jsou vyšší než 100.000 Kč 3. REST - architektonický styl práce s daty (a) ARES REST - jedná se o stejná data jako výše popsaná, která jsou veřejně dostupná online. Duplicita těchto dat vznikla pouze z důvodu otestování dalšího datového zdroje. Aplikace zdroj využívá pro informace o akcionářích společností, statutátních orgánech, představenstvech společností, dozorčích radách apod.

2

http://wwwinfo.mfcr.cz/ares/ares.html http://www.strukturalni-fondy.cz/en/Informace-o-cerpani/Seznamy-prijemcu 4 http://www.zpmvcr.cz/platci/dluznici/ 3

8

4. SOAP - webová služba využívající protokol SOAP (a) Daňový portál

5

- je spravován Elektronickými službami Finanční správy České republiky. Webové služby SOAP umožňují zjistit spolehlivost plátců DPH a také jejich bankovní účty 5. CSV - souborový formát tabulkových dat (a) ČOI Česká obchodní inspekce

6

- tato státní organizace publikuje data o inspekcích a sankcích udělených v rámci kontrol podnikatelů a firem

1.2.2

Popis dat

Z výše uvedených údajů je zřejmé, že poskytovaná data se týkají akciových společností a údajů s nimi spojenými. Nicméně tento systém je vyvíjen zcela obecně, proto není problém data (zdroje) jakkoli upravit, což by mohlo vést k lehce jiným požadavkům na systém. Jako příklad lze uvést spíše informační charakter současných dat, které neumožňují vytvoření rozsáhlých reportů, analýz nebo grafů. Na druhou stranu je rozsáhlá funkčnost již očekávána od této práce, proto veškeré další úpravy (ať už integrační nebo prezentační vrstvy) by neměly být neřešitelné. Pro úplnost si ještě popíšeme poskytovaná data a především katalog popisující jejich způsob uložení. Následující obrázek 1.3 popisuje zpracovávaná data, především však z pohledu hlavní entity Společnost, o které se v systému nachází nejvíce informací. 5 6

http://adisspr.mfcr.cz/adistc/adis/idpr_pub/dpr_info/ws_spdph.faces http://www.coi.cz/cz/spotrebitel/otevrena-data/

9

Obrázek 1.3: Náčrt struktury dat

1.2.3

Katalog dat

Obrázek 1.3 popisuje, jaká data jsou dostupná pro další použití. Druhý vstup informací pro tuto práci je katalog dat popisující metadata jednotlivých typů entit a jejich atributů. V aplikaci se tedy vyskytují dva druhy objektů - entity a jejich atributy. Jako základní typy entity můžeme chápat výše uvedené prvky, např. Společnost, Adresy, Osoby a další. Atributy jsou jednoduché vlastnosti entit - IČ Společností, anebo i přímo entity - Inspekce u Společností. Veškerou sémantiku uložení a vztahů popisuje právě tento katalog následovně:

10

Popis sémantiky entit

Vlastnost

Možné hodnoty

Popis

uri

URI

URI entity v katalogu

resource

Řetězec

Identifikátor entity

name

Řetězec

Název entity

owned

true | false

Značí, jestli se jedná o silnou, nebo slabou entitu Pokud se jedná o slabou entitu,

owner

URI

toto políčko obsahuje URI nadřazené entity

description

Řetězec

attributeTypes

Seznam atributů

Popis entity Seznam

atributů

přiřazených

k entitě Tabulka 1.1: Popis sémantiky entit

K jednoznačné identifikaci entity v rámci dat se poté použije klíčový atribut (viz tabulka 1.2), pokud se jedná o silnou entitu. Jedná-li se o slabou entitu, k její identifikaci se musí použít nadřazená entita (pokud je owned nastaveno na kladnou hodnotu), jejíž URI je uloženo v políčku owner.

11

Popis sémantiky atributů

Vlastnost

Možné hodnoty

Popis

uri

URI

URI atributu v katalogu

name

Řetězec

Název atributu

key

true | false

Označení klíčového atributu Kardinalita atributu - jedná se

cardinality

single | multiple

o hodnotu, anebo seznam (hodnot, URI anebo entit)

collection | entity | at- Značí, kdy k datům entity zísfetchLevel fetchedAsUri

tribute

káme přístup (viz dále)

true | false

Označuje načtení entity jako URI

URI

URI odkazující silné entity

Řetězec

Popis atributu

referenced MasterEntity TypeURI description

Tabulka 1.2: Popis sémantiky atributů

Každá entita se tedy skládá z množiny atributů (kde atribut může být také současně entitou, což značí referencedMasterEntityType). Atributy se mohou načítat ihned při přístupu na entitu, případně až v době, kdy jsou opravdu potřeba, aby se minimalizovala zátěž na server. Toto chování popisuje vlastnost fetchLevel následovně:

collection - Atribut se načte vždy (ať se jedná o dotaz na kolekci, nebo konkrétní entitu) entity - Atribut se načte jen v době přístupu na detail entity attribute - K hodnotě atributu se uživatel dostane jenom při přímém dotazu na jeho hodnotu

12

1.3

Výstupy integračního systému

Pro komunikaci s integračním systémem byl zvolen architektonický styl REST, který umožňuje jednoduchou síťovou komunikaci klient-server. To znamená, že integrační systém nemusí vůbec vědět o tom, jací klienti se k integračnímu systému připojí. Pro další využití je podstatné si popsat následující webové služby dostupné HTTP metodou GET a jejich odezvu ve formátu JSON. Následující seznam popisuje URL přístup a výstup takto:

∙ /data - seznam všech silných entit jako seznam URI na jejich kolekci ∙ /data/{entityResource} - seznam všech silných entit daného typu, současně lze i filtrovat pomocí HTTP hlavičky X-filter: {jméno atributu}{<, =, >}{hodnota} ∙ /data/{entityResource}/{entityKey} - detail konkrétní entity ∙ /data/{entityResource}/{entityKey}/{attributeName} - detail atributu vázaný na danou entitu ∙ /data/{owningEntityResource}/{owningEntityKey}/ {entityResource}/{entityKey} - detail slabé entity vázané ke konkrétní entitě ∙ /data/{owningEntityResource}/{owningEntityKey}/ {entityResource}/{entityKey}/{attributeName} - detail atributu slabé entity ∙ /catalog - seznam všech typů entit (slabých i silných) jako seznam URI na jejich detail ∙ /catalog/{entityResource} - popis metadat konkrétního typu entity ∙ /data/{entityResource}/{attributeName} - popis metadat konkrétního typu atributu pod danou entitou

13

2. Podobné projekty Tato kapitola kapitola se zaměřuje na vyhledání podobných projektů, jenž řeší problémy vizualizace dat. Požadavky kladené jak na výsledný systém, tak i na tuto práci, jsou nyní jasné. Cílem je vytvořit nebo upravit existující aplikaci, která zvládne zobrazit data získaná z integračního systému v různých výstupních formátech. V ideálním případě by bylo nejlepším řešením najít aplikaci splňující požadavky kladené jak na prezentační vrstvu, tak i na samotný integrační systém. Tento případ ale zřejmě nenastane, proto se pokusíme zaměřit na systémy a způsoby řešení, které by mohly být využitelné a které mohou být inspirací pro samotný projekt pro vyřešení částečných problémů.

2.1

Microsoft SharePoint

Již během interní analýzy celého projektu se ukázalo, že najít podobný projekt bude velmi náročný úkol. Jednou z možností, jak pokrýt celý projekt, byla aplikace SharePoint od společnosti Microsoft. Tento kancelářský program by pro běžné uživatele mohl být dostačující, protože zvládá spojit data z databáze, RESTful API nebo XML souborů. Zobrazení je také možné skrze webové stránky pomocí datových pohledů 1 , příklad použití je vidět na obrázku 2.1. Celkově se pro náš účel ale jedná o příliš rozsáhlou aplikaci, která už má problémy s rozšiřitelností, jak tomu u podobných kancelářských programů bývá.

Obrázek 2.1: Microsoft SharePoint - DataView (Microsoft Corporation, 2016) 1

https://www.youtube.com/watch?v=5pW5ReqbUhA - video návod popisující vytvoření da-

tových pohledů

14

Nevýhody

Mezi nevýhody SharePointu patří to, že je aplikace placená. Jedná se také o kancelářskou aplikaci, proto je její rozšiřitelnost omezená. Kvůli těmto důvodům nebyla aplikace dále brána do úvahy pro účel této práce.

2.2

Prohlížeče dat

V následující části se zaměříme na projekty, které řeší určitou dílčí část, jež je spojena s vizualizací dat. V tuto chvíli by bylo ideální najít takový systém, který by zvládal alespoň menší část požadované funkcionality a rozšířit ho pro potřeby aplikace. Na podobné přístupy se zaměříme dále.

2.2.1

Zobrazení dat ve formátu JSON

Takovým možným řešením se jeví jednoduché použití RESTful API, případně JSON prohlížečů. Často jsou tyto prohlížeče řešené formou doplňků do běžných prohlížečů. Tento přístup se hodí, pokud chceme rychle získat a přečíst data reprezentované pomocí JSON formátu. Jako příklad lze uvést JSONView 2

3

dostupný pro Google Chrome i Mozilla Firefox prohlížeče. Z pohledu REST klientů lze uvést Advanced REST Client 4 a DHC REST Client 5 , které dokáží velmi dobře pracovat s RESTful API, zobrazovat data a procházet mezi nimi. Bohužel jakákoli rozšiřitelnost není možná, nicméně se hodí pro rychlé zobrazení dat přijatých skrze HTTP požadavky. 2

https://chrome.google.com/webstore/detail/jsonview/... https://addons.mozilla.org/en-us/firefox/addon/jsonview/ 4 https://chrome.google.com/webstore/detail/advanced-rest-client/... 5 https://chrome.google.com/webstore/detail/dhc-rest-client/... 3

15

Obrázek 2.2: RESTful API browser - DHC REST Client Nevýhody

Zmíněné prohlížeče nemají žádnou možnost rozšiřitelnosti pro další využití. Vzhledem k projektu by bylo nutné nějakým způsobem zakomponovat grafické (CSS) styly a další logiku, což ale tyto prohlížeče neumožňují.

16

Inspirace

Jako výhodu a reálné použití při vývoji projektu lze uvést jejich jednoduchost. JSON formát není uživatelsky přívětivý, tedy rozeznat konkrétní data výstupu RESTful API (ve formátu JSON) není jednoduchá záležitost. Toto je při testování, kdy chceme ověřit, jestli jsou vracena správná data, zásadní problém. V tuto chvíli je podobný přístup velmi dobrou volbou. Grafická vizualizace jednoho z prohlížečů je vidět na obrázku 2.2.

2.2.2

Sémantický web

Jelikož se projekt zabývá spojením dat z různých datových zdrojů na základě jejich metadat, určitě je také zajímavá myšlenka sémantického webu (Berners-Lee a kol., 2001), resp. publikování dat pomocí metody Linked Data (Bizer a kol., 2009). Nicméně projekt není zaměřen na další datové zpracování, sémantický web tak nebude tím správným krokem, zvláště když integrační vrstva sama o sobě zajistí propojení dat. Nicméně existující prohlížeče Linked Data nabízejí zajímavé přístupy ke zpracování dat, jak popisuje publikace Berners-Lee a kol. (2006). Jde především o zobrazení dat z různých pohledů - textově, tabulkově, Google mapa zobrazující zachycená města, kalendář a podobně. Dále lze tvořit i analýzy nad daty, což od této práce není vyžadováno.

Obrázek 2.3: Tabulator - pohled na data (Berners-Lee a kol., 2006)

17

Vztah k projektu

Sémantický web vznikl z důvodu počítačového zpracování dat a jejich další znovupoužitelnosti. Tento prezentační systém je však zaměřen na prezentaci dat z RESTful API. Původním možných řešením bylo data z různých datových zdrojů publikovat pomocí standardu Linked Data a následně zajistit jejich zobrazení pomocí některého z prohlížečů. Tento přístup však nebyl zvolen, viz diplomová práce (Pánek, 2015) popisující vytvoření integračního systému. Pro samotnou prezentaci dat se již jedná o velmi neefektivní a příliš komplikovaný přístup, jelikož v tuto chvíli neexistuje požadavek na znovupoužitelnost dat dalšími subjekty.

Inspirace

Sémantický web a jeho prohlížeče také popisují několik přístupů, které můžeme u tohoto projektu využít - identifikátory a pohledy na data. Identifikátor (IRI) je důležitý v době, kdy chceme přistoupit na detail entity, mít připravená data a získat tak konkrétní náhled. Různé pohledy jsou zajímavé, protože stejná data si můžeme různě zobrazit a získat tak další přidanou hodnotu. Více popisuje obrázek 2.3.

2.2.3

Šablonovací systémy

Další možností je vybrat vhodný programovací jazyk a spojit ho s podporovaným šablonovacím systémem, který typicky danou šablonu dokáže naplnit určenými daty. Většinou jde o zjednodušení logiky aplikace a rozdělení pohledů na data od samotné logiky aplikace. Problémem ale je, že od aplikace vyžadujeme zobrazení v různých formátech. Data nejsou načítána vždy okamžitě a také logika samotných pohledů bude složitější než to, co jednoduchá šablona zvládne vykreslit.

18

Spoustu příkladů popisuje článek Wikipedia (2016b), kde lze najít ke každému programovacímu jazyku až několik desítek dostupných šablonovacích systémů.

Nevýhody

Bohužel není možné rychle vytvořit šablony tak, aby splňovaly podmínky kladené na tuto práci, především zobrazení v různých formátech současně. Stále bude nutné připravit značnou část logiky aplikace, aby se tento přístup dal reálně využít.

Inspirace

Šablonovací systémy jsou určitě dobrou volbou při správně zvoleném programovacím jazyku a ulehčí a zpřehlední vývoj celé aplikace oddělením logické a prezentační vrstvy.

2.2.4

Jednoduchá vizualizace dat

Poslední možností je najít nástroj pro jednoduchou vizualizaci dat a ten napojit na vstupní zdroj dat aplikace. Takovým nástrojem může být tabulkový procesor, nástroj pro vytváření grafů v jazyce JavaScript, Google Maps a podobně. Podobných nástrojů dokážeme najít dostatečné množství, jsou ale vždy zaměřené jenom na částečný problém zpracování jednoduchých dat.

Nevýhody

Vstupní data programu ale určitě nelze označit za jednoduchá. Z toho důvodu je nemožné použít jeden nástroj, který by zvládl veškerá data správně a intuitivně zobrazit.

19

Inspirace

Nicméně na zpracování dílčích problémů bude vhodné využít již existujících řešení. Data by šla rozdělit do různých bloků, které by se následně vykreslovaly samostatně, viz obrázek 2.4.

Obrázek 2.4: Pohled na bloky dat

20

2.3

Shrnutí

V této kapitole jsme nahlédli na několik možných způsobů jak prezentovat data se zaměřením na JSON formát, resp. práci s RESTful API. V těchto ohledech žádná z možností není plně vyhovující pro tento projekt. Pokud bychom chtěli nejrychleji prezentovat data, určitě by stál za úvahu Microsoft SharePoint, který je ale placený, určený pro kancelářské využití a jeho rozšiřitelnost je limitována. Na druhé straně jsou menší vizualizační prostředky, které zvládnou zobrazit specificky určená data. Jejich využití a zakomponování do systému je více časově náročné, nicméně umožňuje větší škálovatelnost systému. Současně jsou zajímavé myšlenky sémantického webu a jeho prohlížečů jako různé pohledy na data a jednoznačné identifikátory jednotlivých entit.

21

3. Analýza Následující kapitolou se zaměříme na prvotní náhled fungování systému. Nejdříve si představíme základní vizi a motivaci, proč projekt vzniká a jaké hlavní požadavky jsou na projekt kladeny. Další zaměření bude na problémové a obtížnější části projektu, které bude nutné vyřešit. Následuje část s pojmy spojenými s aplikací. Nedílnou součástí analýzy jsou také funkční a kvalitativní požadavky na systém společně s případy užití a představení jednotlivých aktérů systému.

3.1

Záměr projektu

V dnešní době každá společnost vlastní velké množství dat, která typicky používá k dalšímu zpracování. Na druhé straně je důležité si data rychle zobrazit. Často totiž pocházejí z tabulkových procesorů, případně dalších formátů, kde přehlednost a uživatelské zobrazení nepatří mezi nejlépe podporované vlastnosti. Současně je důležité si data procházet bez nutnosti složitě vyhledávat, kde se další důležitá data nacházejí. Zároveň však mohou být data přímo použita pro další zpracování, tedy samotné prohlížení nemusí být jedinou funkcí, kterou od systému očekáváme. Může jít o rychlé exporty do tisknutelného PDF formátu, případně do tabulkového procesoru Microsoft Excel. V neposlední řadě je cílem projektu vyvinout prezentační vrstvu nezávisle na použitých datech s určitou interakcí uživatele, který si může definovat, jak budou data zobrazena. To znamená při každém stejném požadavku (pokud se nezmění data) se pohledy budou zobrazovat stejně. Pokud ke změně dat dojde, systém na změnu musí umět zareagovat úpravou pohledů.

22

3.2

Hlavní požadavky na systém

Podstatné funkční požadavky pro používání systému jsou následující: ∙ Zobrazit informace o jednotlivých entitách ∙ Procházet provázané entity ∙ Vyhledávat data ∙ Export do PDF ∙ Podpora pro rozšíření na zobrazení v dalších formátech ∙ K externí stránce připojit nápovědu získanou z prezentační vrstvy systému

3.3

Problémy prezentační části

Další částí se zaměříme na podstatné problémy, které touto prací budeme muset vyřešit.

3.3.1

Různé formáty výstupů

Hlavním požadavkem je zobrazení dat ve formátu HTML, což by znamenalo vytvoření jednoduché webové stránky, která toto zvládne. Dalšími požadavky jsou ale exporty do dalších formátů - cílem práce je exportovat pohledy do PDF formátu a podpora pro rozšíření systému do dalších formátů. Příkladem může být dokumentový procesor Microsoft Word, případně tabulkový Microsoft Excel.

3.3.2

Změna dat

Následujícím výrazným požadavkem je zobrazení obecných dat na základě jejich metadat. To znamená, že systém bude muset pohledy nějakým způsobem ukládat a reagovat na změny v datech, které se často očekávají. 23

3.3.3

Uživatelský vstup

Od aplikace je také vyžadována uživatelská interakce. Uživatel bude moci pohledy na data měnit a upravovat, aby se data zobrazila na základě uživatelem definovaném pohledu.

3.3.4

Načítání atributů a externí stránky

Posledním, spíše menším, problémem zůstává to, jak řešit zobrazení atributů, protože některé jsou z integrační vrstvy načtené okamžitě. Některé jsou dodány až v době, kdy se na ně speciálně dotážeme. Podobně bychom mohli definovat problém, kdy bychom na externí stránce chtěli nápovědu k danému elementu (například o firmě s daným IČ). Obě akce jsou podobné, jelikož půjde o to, jak zobrazit data (jasně identifikovatelná) v konkrétním HTML elementu.

3.4

Slovník pojmů

Pro ujasnění následuje výčet pojmů používaných v této práci a dokumentaci:

Datový zdroj - vstupní data produkovaná integrační vrstvou systému Integrační systém - sjednocuje jednodušší datové zdroje v různých formátech a publikuje pomocí RESTful API Katalog - vstupní metadata zachycující způsob uložení a provázaní jednotlivých entit a atributů datového zdroje Pohled - jedná se o obecné zobrazení dat, není podstatné, jakým způsobem se budou pohledy zobrazovat a jakým způsobem budou programátorsky řešeny Šablona - uložení pohledu do interního formátu, na jehož základě se dokáže pohled obnovit a znovu vykreslit

24

3.5

Seznam požadavků

Následující kapitolou si ujasníme požadavky, které od systému požadujeme - tedy funkční i kvalitativní. Funkční požadavky kladou důraz na funkcionalitu systému, kvalitativní naopak na způsob řešení. Splnění jednotlivých požadavků bude naznačeno u souhrnného popisu jednotlivých modulů softwarové architektury v kapitole 4.4.

3.5.1

Funkční požadavky

Funkční požadavky popisují veškeré požadavky zákazníka kladené na systémové funkce, aktivity a akce, které musí aplikace zvládat. Požadavky projektu jsou rozdělené na dvě části, z pohledu uživatele (procházení dat) a administrátora (administrace prezentační vrstvy). Požadavky ze strany klienta Systém na základě znalostí z datového zdroje a katalogu umožní:

1. zobrazit seznam všech používaných typů entit a jejich atributů, mezi kterými lze vyhledávat 2. zobrazit seznam všech entit konkrétního typu 3. zobrazit vyfiltrovaný seznam entit daného typu podle použitého filtru atributu a porovnávacích kritérií (rovná se, větší, menší, část řetězce) 4. zobrazit pohled na konkrétní entitu (tzv. detail entity), pohled může být automaticky vygenerovaný, případně definovaný uživatelem (detail musí obsahovat napojení atributů na zobrazení minimálně v řádcích a tabulkách) 5. změnit pohled na danou entitu na jiný, který byl pro danou entitu (přesně identifikovanou, případně pro všechny entity konkrétního typu) vytvořen 6. načíst atributy entity v konkrétním pohledu (uživatel si pro každý pohled může vybrat, které atributy se budou načítat) 25

7. procházení mezi entitami zobrazenými v daném pohledu 8. zobrazit krátký detail entity před zobrazením plného detailu (z důvodu rychlejší orientace v systému), tento krátký detail půjde zobrazit i z externí stránku mimo systém 9. exportovat pohled do formátu PDF

Požadavky systému na administraci Systém umožní:

10. vytvořit, editovat a smazat pohled na data 11. přiřadit šablonu všem entitám zvoleného typu 12. přiřadit šablonu konkrétní entitě 13. určit výchozí pohled na data 14. měnit pořadí pohledů, tedy jejich prioritu zobrazení 15. zobrazit, přidat a smazat nastavení entity používající konkrétní pohled 16. zobrazit, změnit a přidat používané grafické styly pohledů (a jednotlivých bloků dat) 17. automaticky vytvořit pohled na entitu 18. automaticky přiřadit šablonu entitě, pokud nemá již přiřazen existující pohled

26

3.5.2

Kvalitativní požadavky

Tyto požadavky popisují způsob řešení, které je důležité pro zákazníka. Jde především o vlastnosti specifikující kvalitu řešení, různá kritéria a omezení kladená na systém, jeho vývoj a dokumentaci. Požadavky na návrh aplikace Systém bude mít následující vlastnosti:

19. URL integrační vrstvy bude možné jednoduše nastavit v konfiguračním souboru projektu 20. odhalí změny v datech (nové, smazané atributy) a jejich metadatech (změny atributů) 21. automaticky vytvoří pohled pro nově vzniklý typ entity 22. upraví pohled pro typ entity, kde dojde ke změně v datech (doplní, nebo smaže potřebné atributy) 23. upraví pohled pro typ entity, kde dojde ke změně v metadatech (upraví potřebné údaje) 24. zobrazí krátký detail entity na externí stránce s možností zobrazení plného detailu ve vyvíjeném systému

Dostupnost systému Systém bude mít následující vlastnosti:

25. oznámí přístup na neexistující entitu, případně neplatný uživatelský vstup 26. při neexistujícím pohledu aplikace zajistí její vytvoření 27. při špatně uloženém pohledu (uživatel zadá špatný vstup, případně u validního pohledu se změní metadata a pohled přestane být aktuální) zajistí systém opravu 27

Zabezpečení systému Jelikož je aplikace vyvíjena jako interní, není požadavek na její zabezpečení pomocí autentizace uživatelů. Škálovatelnost systému Systém bude mít následující vlastnosti:

28. je možné rozšířit o zobrazení dat v dalším formátu 29. lze napojit na další vizualizační zdroje jednoduchých dat 30. při případném požadavku je možné rozlišit role administrátora a běžného uživatele, tedy zabezpečit samotnou administraci systému 31. lze rozšířit o napojení na více integračních datových systémů, pro něž je práce vyvíjena

Dokumentace systému Systém bude mít následující vlastnosti:

32. programátorská dokumentace systému bude vedena v angličtině (stejně jako zdrojové kódy) 33. uživatelská dokumentace systému bude dostupná v češtině 34. základní architektonické pohledy budou dostupné v češtině 35. dokumentace systému bude obsahovat instalační příručku 36. dokumentace systému bude obsahovat základní použití aplikace, vč. popisu úpravy pohledů a vzorových obrázků 37. zdrojové kódy budou rovněž zdokumentovány

28

3.6

Případy užití

V poslední části kapitoly se zaměříme na případy užití systému. Požadavky systému musí zůstat zachovány, ale současně musí reagovat na různé aktéry systému. V tomto případě jde o dvojici:

Klient - jde o UI klienta, jiný software (např. pro testování) nebo běžného uživatele Administrátor - jedná se o administrátora systému spravujícího pohledy na data

3.6.1

Uživatel

Z pohledu běžného uživatele jde především o naplnění funkcionality týkající se zobrazení dat, viz diagramy 3.1 a 3.2.

Obrázek 3.1: Případ užití - uživatel

29

Obrázek 3.2: Případ užití - pohledy na data

30

3.6.2

Administrátor

Druhým aktérem systému je administrátor, který má na starost správu pohledů, jejich vytváření, editaci a funkce s tím spojené. Vzhledem k požadavkům na bezpečnost není tato role v danou chvíli podstatná, nicméně pro vyšší přehlednost je uvedena samostatně. Diagram 3.3 znázorňuje administrátora a jeho pravomoci v rámci systému.

Obrázek 3.3: Případ užití - administrátor

31

4. Návrh a architektura systému V následující kapitole se již zaměříme na návrh celé aplikace, představíme si architekturu aplikace a prvky s ní spojené. Nejdříve si popíšeme obecný návrh fungování systému, poté se zaměříme na volbu programovacích jazyků, ve kterých bude aplikace vytvořena. Také si popíšeme vytváření pohledů (stěžejní části aplikace) v kontextu problémových částí popsaných v sekci 3.3. Nakonec si projdeme strukturu aplikace včetně komunikace mezi hlavními moduly a integrační vrstvou.

4.1

Princip fungování

Systém je navržen pro komunikaci s integrační vrstvou, ze které systém vždy získá dvojici údajů, tedy samotná data a jejich metadata. V případě, kdy uživatel zažádá o vykreslení stránky, systém musí buď vytvořit, případně získat pohled na konkrétní data na základě jejich metadat. Pokud by systém pohled již evidoval, metadata v tomto kroku nemusí hrát úplně podstatnou roli, protože by se jenom dodaný pohled (šablona) naplnil daty. V opačném případě je nutné obrátit se na integrační systém a vygenerovat pohled, který se následně zobrazí uživateli, viz obrázek 4.1. Ať se pohledy ukládat budou, nebo ne, tato situace rozhodně nastane v případě nové (dosud nezaevidované) entity, pro kterou pohled zatím nebyl použit, resp. vytvořen.

32

Obrázek 4.1: Proces vykreslení dat

4.2

Volba použitých technologií

Společnost C42 s.r.o. se zabývá business inteligencí, tedy prezentací dat a reportů, proto by bylo užitečné nezvolit kompletně odlišné prostředky pro vývoj této aplikace. Jejich výstupy jsou většinou založené na webových stránkách využívající JavaScript 1 , skriptovací jazyk front-endu. I pro účely této práce se jedná o rozumnou myšlenku. Především napojení externí stránky a zobrazení náhledu před zobrazením plného detailu entity bude nutné řešit na straně klienta. Poté už není velkým problémem celé vykreslování pohledů řešit na straně JavaScriptu. Další výhodou je rychlost komunikace - při použití JavaScriptu není nutné přenášet kompletní HTML stránku ze serveru na klienta (při správném použití), tedy velikost přenesených dat je výrazně nižší. Zároveň také nemusí prohlížeč vykreslit celou stránku, případně opakovaně vykreslovat stejné části webové stránky. Nevýhodou je výrazně nižší testovatelnost, netypované parametry a proměnné a nižší podpora ze strany klientů. Nicméně aplikace je vyvíjena především pro desktopové využití, mobilní využití se prozatím nepředpokládá, proto poslední jmenovaná nevýhoda není tak podstatná. První dvě nevýhody na samotnou kvalitu aplikace také nemají velký vliv, jsou podstatné pouze pro její vývoj. 1

http://www.w3schools.com/Js/

33

Programovacím jazykem serveru byla zvolena Java 2 , a to především z důvodu používání v dalších firemních projektech. Jedná se o typovaný jazyk s podporou RESTful API a spoustou existujících knihoven 3 . Mezi dalšími použitými knihovnami a frameworky byly z pohledu Javy použity Spring

4

a ORM Hibernate 5 . JavaScript využívá jQuery 6 , Backbone

7

a Under-

score 8 . Jejich použití (stejně jako představení další použitých menších doplňků) bude následovat v dalších částech této kapitoly.

4.3

Struktura pohledů

Následuje popis návrhu základní části celé aplikace (pohledů na data) a řešení podstatných problémů, které s pohledy souvisí. Těmito problémy jsou různé výstupní formáty, změna dat a metadat integrační vrstvy, uživatelský vstup (definování vlastních pohledů) a zobrazení různě načítaných atributů, včetně zobrazení na externích stránkách (viz kap. 3.3). Představíme si několik možných variant řešení, jejich klady a zápory se vzájemným porovnáním a následnou volbou použitého řešení.

4.3.1

Vytváření pohledů

Pro všechna možná řešení platí, že výsledný pohled vznikne na základě dat a jejich metadat přístupných skrze RESTful API integrační vrstvy celého systému. Prvním možným řešením je generování veškerých pohledů přímo na serveru. Na základě dat a metadat vytvoříme pohled, který bude zobrazen uživateli. 2 3

https://java.com/ Společně s Javascriptem se jedná o dvojici velmi často používaných programovacích jazyků,

s nimiž nemá autor tolik praktických zkušeností při vývoji kompletních webových řešení. Také i z tohoto důvodu byla tato dvojice programovacích jazyků vybrána. 4 http://projects.spring.io/spring-framework/ 5 http://hibernate.org/orm/ 6 https://jquery.com/ 7 http://backbonejs.org/ 8 http://underscorejs.org/

34

Nevýhody

Tento přístup má značnou výhodu v přístupu vzhledem ke změně dat a jejich atributů, protože při každém požadavku bude šablona znovu vygenerovaná. Problémů nastává více, především však v sekci 4.2 definovaný požadavek na zpracování dat na straně klienta, tedy nepřenášení celých pohledů jedním HTTP požadavkem.

4.3.2

Vytváření pohledů - na straně klienta

Nabízí se tedy možnost přesunout veškerou hlavní logiku na stranu klienta a komunikaci vést pouze mezi klientem a integrační vrstvou. To by usnadnilo nejen komunikaci, ale také samotná architektura systému by byla jednodušší a přehlednější.

Nevýhody

Tento přístup se již přizpůsobil požadavkům společnosti pro alespoň částečnou implementaci (a možné napojení na další existující projekty) na straně klienta. Stále však zůstává nevyřešena interakce uživatele. Uživatel nemá žádnou možnost pro vlastní vstup do systému, definici vlastních pohledů, přidávání pohledů. Uživatel také nemůže rozhodnout, kdy a jak se budou načítat atributy k entitám.

4.3.3

Ukládání pohledů

Předchozí problém by mohl být vyřešen jednoduchým ukládáním pohledů do šablon, které by byly obnovitelné. Tedy uživateli by byl vygenerován pohled na data s možností jeho uložení. Při ukládání by měl uživatel možnost měnit grafické styly zobrazení a další požadované vlastnosti.

35

Nevýhody

Tento přístup již řeší možnost uživatelské interakce, zůstává však zbytečně složitým. Dokud si uživatel pohled neuloží, bude se mu generovat opakovaně. Na druhé straně musí současně logika aplikace zvládat jak pohledy generovat, tak je obnovovat. Při generování pohledů také hraje roli, v jakém pořadí uživatel data (atributy) dostane, tedy pohledy se mohou pokaždé generovat s lehkými změnami, což není optimálním řešením. Navíc není jasné, jak by se pohledy vůbec měly ukládat.

4.3.4

HTML šablony

Dalším možným řešením je vedení šablon v HTML formátu. Při každém novém požadavku se vygeneruje a uloží šablona (na serveru), klient dostane vždy již existující pohled, který jen vykreslí. Tímto krokem se zjednoduší logika, klient bude řešit pouze vykreslení, server poté správu pohledů.

Nevýhody

Podstatným, zatím nezmíněným, a nevyřešeným problémem zůstává požadavek na zobrazení pohledů ve formátech HTML, PDF. V úvahu je nutné vzít také další potenciální rozšiřitelnost pro další formáty, např. pro tabulkové a dokumentové procesory aplikací Microsoft Word, Excel a další. Při současném návrhu by se musel problém řešit šablonou pro každý formát samostatně, což by bylo komplikované nejen z hlediska vývoje. Výrazně horší situace nastane i při editaci pohledů, protože uživatel by byl nucen editovat všechny formáty současně.

4.3.5

HTML šablony - druhá verze

Místo šablon pro jeden formát by bylo ideální vytvořit jednu obecnou šablonu a pro ni převodní pravidla (funkce) do požadovaných formátů. Aby byla situace

36

ještě jednodušší, využijeme myšlenku obrázku 2.4 - tedy blokové zobrazení dat. Jediným problémem tak zůstává převodní funkce jednotlivých bloků do konkrétního formátu. Po analýze již dříve představených dat v sekci 1.2.1 budou prozatím použity 4 základní bloky dat:

∙ Řádek ∙ Seznam ∙ Tabulka ∙ Mapa

V této části tedy bude jednoduché jednotlivé objekty převádět do konkrétního formátu (primárně HTML) a libovolně je rozšiřovat. Například by bylo možné přidat bloky kalendáře a grafů, současné datové zdroje pro vizualizaci těchto typů dat ale nejsou zajímavé. Jako bonus dostáváme možnost využívat vizualizační nástroje pro jednotlivé bloky dat. Pro definici šablony a jejich bloků může být inspirací návrhový vzor Composite (Gamma a kol., 1994), viz obrázek 4.2. Tedy šablona se může skládat z jednoduchých bloků, případně z jiné šablony (je nutná kontrola případného zacyklení). Blok pro tabulku by mohl vypadat následovně:



37

Obrázek 4.2: Návrh šablony a jednotlivých bloků

4.3.6

XML šablony

Menší optimalizací bude ukládání šablon v XML formátu, jelikož HTML šablony by nebyly validně uložené - např. element table musí mít definované potřebné potomky.

4.3.7

Shrnutí

Posledním ne zcela popsaným problémem zůstává změna struktury poskytovaných dat pohledu - tento problém již ale lze vyřešit na základě popsaného systému. Při vykreslení klient ví, jaká data mu budou poskytnuta. Pokud se data změní (změní se metadata vykreslovaných atributů, anebo potřebný atribut zmizí), poté správce šablon (tedy server) dostane požadavek pro zkontrolování a opravení šablony. Pokud naopak entita bude mít nový atribut, poté šablona sama může mít seznam použitých a nepoužitých atributů (takto se pozná nový). Případně je možné pravidelně spouštět nástroj, který kontroluje nastalé změny (vč. změny a mazání atributů).

38

Tabulka 4.1 popisuje porovnání struktury pohledů: Vytváření

Ukládání

HTML

XML

pohledů

pohledů

šablony

šablony

(4.3.1)

(4.3.3)

(4.3.4)

(4.3.6)

3

7

7

7

3

3

3

3

7

3

3

3

7

7

3

3

7

7

7

3

Změna metadat Atributy Ext. str. Uživatelský vstup Jednotné pohledy Různé formáty

Tabulka 4.1: Porovnání možných přístupů pohledů

Porovnávané vlastnosti v tabulce 4.1 jsou následující:

Změna metadat - schopnost pohledu reagovat na změnu metadat Atributy, externí stránka - možnost načtení atributů, resp. zobrazení na externí stránce

9

Uživatelský vstup - možnost uživatele změnit pohled Jednotné pohledy - zobrazení identického pohledu pro stejný požadavek

10

Různé formáty - reakce systému na nový požadavek rozšiřitelnosti aplikace o další formáty 9

Tento problém není až tak výrazným v žádném případě, pokaždé stačí atribut zobrazit

v daném HTML elementu bez ohledu na používanou strukturu pohledů. 10 Tento požadavek má nízkou prioritu

39

4.4

Architektura aplikace

V následující části se zaměříme na samotnou architekturu aplikace (Clements a kol., 2002). Budou nás zajímat pohledy na moduly a komponenty (logické části systému), vztahy a vzájemnou komunikaci mezi nimi a také s dříve vytvořenou integrační vrstvou. V kapitole si představíme logické celky aplikace s detailním popisem a klíčové procesy pro důležité případy použití aplikace. S krátkým popisem se současně zaměříme na splnění požadavků kladených na systém v kapitole 3.5.

4.4.1

Pohled na moduly a jejich komponenty

Prvním pohledem na architekturu je rozdělení celé aplikace na jednotlivé celky, moduly. Obrázek 4.3 popisuje jednotlivé prvky systému následovně: Klient, externí stránka - jedná se o vstupní body celého systému Klient modul - veškerá logika klienta je obsažena v tomto modulu - načítání dat, vizualizace a editace šablon Komunikační modul - zajišťuje komunikaci na serveru mezi klientem a dalšími moduly Modul šablon - správa šablon, jejich vytváření, validace a reakce na změny v datech Integrační obal (wrapper) - komunikace mezi jinými moduly a integrační vrstvou Databázový obal (wrapper) - mapování řádků relační databáze do objektů Šablony - datový zdroj uložených šablon Databáze - vede záznamy o šablonách, používaných atributech a jejich metadatech 40

Obrázek 4.3: Architektura aplikace Integrační vrstva - původně vytvořená vrstva celého systému, jež se chová jako černá skříňka k tomuto systému - veškerá komunikace probíhá skrze vstupní body Data a Katalog

4.4.1.1

Klient modul

Nejdůležitější částí systému je klient modul. Stará se o veškerou logiku vizualizace pohledů, posílá požadavky na šablonovací a integrační systém, získává data a metadata pro pohledy. Současně zajišťuje grafické prostředí pro úpravu šablon, jejich administraci a zobrazení stránek s jednodušší logikou.

41

Modul zpracovává požadovanou funkcionalitu kladenou na samotné zobrazení. Vzhledem k cílům projektu definovaným v kapitole 3.5 se jedná o funkční požadavky číslo 1 - 9 a kvalitativní 20, 22 - 25 a 29 - 30, které zajišťuje především komponenta Továrnička šablon. Zároveň je vstupním bodem pro další požadavky, především však administrační 10 - 18. Diagram modulu je znázorněn na obrázku 4.4. Pro vývoj modulu jsou použity následující frameworky a knihovny:

∙ Backbone.js - zajištění páteřní logiky aplikace ve smyslu MVC (Krasner a kol., 1988) ∙ Underscore.js - další užitečné funkce, především rychlé vykreslení HTML šablon na základě jejich parametrů ∙ jQuery - základní knihovna pro JavaScript a manipulaci s DOM objekty

Obrázek 4.4: Klient modul - jádro aplikace

Komponenty modulu klienta:

Router stojí na vrcholu modulu, jehož cílem je rozdělit URL na požadavky a přeposlat je dalším komponentám na zpracování.

42

Továrnička šablon nese hlavní logiku vykreslování pohledů. Na základě získaných dat, metadat a šablony vykreslí pohled (resp. předá požadavek na jednotlivé bloky). Současně přidá další logiku, aby bylo možné portál procházet bez kompletního znovunačtení celé stránky. Také zajistí zobrazení atributů v potřebnou chvíli (např. při načtení stránky nebo dvojkliku) a jejich zobrazení. Editační komponenta zajišťuje editaci jednotlivých šablon, jejich grafické zobrazení a základní kontrolu vůči metadatům. Je založeno především na doplňku jQuery drag & drop

11

.

Základní pohledy jsou již jednoduchou komponentou, jejímž cílem je zobrazit a zajistit jednoduchou logiku různých stránek. Tento princip bývá povětšinou podobný - načíst a zobrazit data, umožnit jejich editaci nebo smazání a následně odeslat požadavek na komunikační vrstvu. Základní bloky zajišťují vykreslení jednoduchých bloků šablony zobrazených na obrázku 4.2. Pro vykreslení byl využit návrhový vzor Chain of Responsibility (Gamma a kol., 1994), podle něhož stačí znát jenom jeden objekt bloku a na něm poté volat vykreslení. Tedy veškeré požadavky zpracovává objekt řádek - pokud na vstupu dostane řádek, vykreslí ho. Pokud ne, povinnost přesune na následující prvek. A pokud má být vykreslena šablona (tedy seznam prvků), šablona vznikne spojením jednotlivých základních bloků a jejich transformací do konkrétního formátu. Pro přívětivější vizualizaci bloků se použijí následující doplňky: ∙ Tabulky - DataTables

12

zvládají jednoduše řadit data v tabulkách,

vyhledávat v nich a řešit stránkování ∙ Mapy - API Mapy.cz

13

pro zobrazení mapy dané adresy

Integrační mapování slouží ke správnému generování IRI entit a atributů, správné práci URI metadat vzhledem k integrační vrstvě a ke zpracování některých požadavků směrem ke komunikační vrstvě (integrační části). 11

https://jqueryui.com/draggable/ https://datatables.net/ 13 https://api.mapy.cz/ 12

43

4.4.1.2

Komunikační modul

Komunikační modul funguje jako jednoduché rozhraní RESTful API mezi samotným jádrem serverové a klientské části. Veškerá komunikace prochází skrze tuto vrstvu a její třídy. Pro její implementaci je použit open-source framework Jersey 14 . Veškeré chování je popsané v programátorské dokumentaci v kapitole 6.

4.4.1.3

Modul šablon

Nejrozsáhlejší modul serverové části řeší práci se šablonami, jejich vytváření, validaci a změny týkající se metadat atributů. Mezi konkrétní funkcionalitu z kapitoly 3.5 patří administrační požadavky 10 - 18 a kvalitativní 20 - 23 a 26 30. Požadavky se týkají především automatické úpravy a vytváření pohledů, jenž jsou hlavním úkolem pro komponenty spravující Validaci a Generování šablon. Diagram 4.5 znázorňuje veškeré komponenty použité v rámci tohoto modulu:

Obrázek 4.5: Modul šablon 14

https://jersey.java.net/

44

Popis komponent modulu:

Komponenta služeb zpracovává veškerou komunikaci od klienta, resp. komunikační vrstvy. Má na starost předávání požadavků, jejich zpracování a vrácení výsledku zpět komunikační vrstvě. Správa šablon řeší administrační požadavky šablon - vyhledání vhodné šablony, přiřazení, uložení a podobně. Generování šablon je podstatnou komponentou při nově vzniklém typu entity anebo atributu, kde zajistí vytvoření šablony. Zajistí také opravu při nastalé změně v datech nebo metadatech. Validace řeší problém kontroly správně uložené šablony. Část klienta při editaci pouze napovídá vstup uživateli, nicméně nekontroluje, jestli je šablona odeslaná správně. Tento krok řeší zmíněná komponenta. Současně se také může stát, že šablona byla validně uložena, nicméně se změnila metadata integrační části systému. Poté tato komponenta určí, co je potřeba opravit, aby byla šablona opět použitelnou a zobrazitelnou. Obal šablon zajišťuje funkce mezi aplikací a XML šablonami.

4.4.1.4

Integrační obal (wrapper)

Integrační obal funguje jako mezivrstva mezi prezentační a integrační částí systému. Veškerá komunikace prezentační části směrem k integrační prochází skrze tento modul. Má také na starost uložení a identifikaci změn v rámci katalogu. Z požadavků systému v kapitole 3.5 zajišťuje splnění bodů 19 - 20, 25 a 31. Struktura modulu je znázorněna na diagramu 4.6.

45

Obrázek 4.6: Integrační modul Popis komponent modulu:

Komponenta katalogu má na starost ukládání dat katalogu do databáze pro pozdější účely zjištění změn oproti dřívější verzi. Ukládají se pouze důležité informace pro vykreslení dat, různé popisky jsou pro tuto komponentu irelevantní. REST obal zajišťuje veškerou komunikaci s integrační částí systému. Část klienta by teoreticky mohla komunikovat přímo s integrační vrstvou, nicméně integrační a prezentační části se mohou nacházet na různých doménách (serverech). Problém nastává při komunikaci mezi dvěma různými zdroji (CORS), v tomto případě se jedná o techniku AJAX dotazující se na externí (integrační) RESTful API, která nedovoluje přímou komunikaci. Tento problém lze vyřešit změnou HTTP hlavičky Access-Control-Allow-Origin na straně integrační vrstvy (Wikipedia, 2016a), kterou momentálně ale neposkytuje. Nicméně zvolený přístup umožňuje implementaci návrhového vzoru Proxy (Gamma a kol., 1994), který dokáže reagovat na případné změny v inte46

grační vrstvě. Zároveň může monitorovat veškerou komunikaci směrem od klienta a přeposílat ji dál. Tato vrstva by tedy mohla zajistit komunikaci i s více integračními zdroji.

4.4.1.5

Databázový obal (wrapper)

K databázovým objektům je přistupováno skrze rozhraní databázového obalu. Pro implementaci obalu je využit framework objektově-relačního mapování Hibernate. Tento modul v sobě obsahuje mapující třídy jednotlivých tabulek (viz následující kapitola) a také DAO třídy pro přístup k jednotlivým datům (objektům, tedy řádkům).

4.4.1.6

Návrh databáze

Následuje představení návrhu databáze na diagramu 4.7, který je z důvodu dokumentačních požadavků v angličtině. Databáze vede záznamy o uložených šablonách, o typech entit a atributů z katalogu a o jejich použití v rámci šablon. V návrhu databáze je použito 6 entit následovně:

Entity Type - jedná se o typ entity z katalogu, vazba owner značí, jestli se jedná o silnou, nebo slabou entitu závislou na jiném typu entity Attribute Type - značí typ atributu vázaného přes entityType k entitě, atribut může být současně i entitou, což popisuje vazba referencedMasterType Template File - šablona pro daný typ entity, nebo atributu Template Attribute - popisuje použití typu atributu v rámci šablony, rank znázorňuje pořadí atributu v šabloně Template Mapping - umožňuje konkrétní (případně každé) entitě (resp. atributu) přiřadit konkrétní šablonu vztahující se k danému typu entity (atributu) 47

Obrázek 4.7: Návrh databáze Template Table Attribute - popisuje použití typu atributu v rámci tabulky v šabloně

4.4.2

Pohledy na důležité procesy

V poslední části kapitoly se zaměříme na architektonické pohledy návrhu komunikace pro nejdůležitější procesy aplikace. Pro přehlednost není v pohledech uveden komunikační modul, přes nějž jde veškerá komunikace a přidal by pouze dělení šipky směrem od klienta na server. V diagramech je použita následující

48

symbolika - plná šipka znázorňuje požadavek směrem k dalšímu modulu, prázdná šipka asynchronní požadavek a přerušovaná odpověď požadavku (nese-li důležitou informaci).

4.4.2.1

Vykreslení šablony

Nejčastějším požadavkem systému je určitě vykreslení pohledu, jenž popisuje diagram 4.8. Při tomto požadavku je postupně odeslána čtveřice asynchronních požadavků (tedy není přesně dané, v jakém pořadí obdržíme jejich odpovědi) dotaz na data a metadata z integračního systému, dostupné šablony na pohled a konkrétní šablonu. Jakmile klient má všechny odpovědi, začíná zpracovávat šablonu - nejdříve ověří, jestli šablona neobsahuje další šablony - pokud ano, načte je. Následně provede transformaci jednotlivých bloků do požadovaného formátu. Poslední částí je opět případné zobrazení pohledů místo dodatečně načítaných atributů, je-li to požadováno.

Obrázek 4.8: Proces vykreslení pohledu

49

4.4.2.2

Vytvoření šablony

Základním problémem je vytvoření samotné šablony, které probíhá podobně jako vykreslení - pouze v jednom kroku dojde k mírné změně. Dle 4.8 se klient při vykreslení šablony nejdříve zeptá na možné pohledy pro data. Pokud neexistuje žádný, je nutné načíst metadata a na jejich základě pohled vytvořit. Jako menší vylepšení je použitá krátká analýza, která určí pozici atributu v rámci šablony. Klíčové atributy se zobrazí dříve než atributy, které se načítají dodatečně, řádky dříve než tabulky a podobně. Jelikož se často vyskytují stejně pojmenované atributy (např. name, surname, dateFrom, dateTo, street, city), vezme se v úvahu i jejich pozice v rámci již existujících šablon. Jakmile atributy jednou ručně seřadíme, máme jistotu, že počáteční datum se bude vždy zobrazovat před konečným datem, jméno před příjmením atd.. Samotný proces vytvoření šablony je zobrazen na diagramu 4.9.

Obrázek 4.9: Proces vytvoření šablony

50

4.4.2.3

Změna parametrů

Poslední pohled na funkci systému popisuje diagram 4.10 - jedná se o opravu pohledů. Zaznamená-li klient chybu při vykreslování pohledu, šablonovací modul porovná metadata uložená v databázi s aktuálními a na základě případných změn opraví všechny pohledy, kde se změněný atribut vyskytuje.

Obrázek 4.10: Proces opravy šablony při změně metadat

51

5. Uživatelská dokumentace V následující části se tato práce zaměřuje na reálné využití z pohledu uživatele a jeho interakci se systémem. Kapitola popisuje veškerou nutnou instalaci prezentační vrstvy, její konfiguraci, základní poskytované funkce (včetně obrázkového znázornění) a popisu jednotlivých bloků šablon.

5.1

Instalace prezentační vrstvy

Podstatným krokem k tomu, abychom mohli prezentační vrstvu používat, je její publikování na veřejně dostupném místě. Tento proces se skládá ze dvou kroků, jelikož celý systém obsahuje dva logické celky - serverovou a klientskou část. První, tedy serverovou část, je nutné vystavit na JAVA webovém serveru. Pro vývoj systému byl použit open-source projekt Apache Tomcat 8.0.27.0 1 jako rozšíření pro IDE NetBeans 2 . Server Apache Tomcat není ale vázaný na zvolené IDE a je volně dostupným produktem společnosti Apache Software Foundation. Na server je nutné nahrát a rozmístit (z angl. deploy) zdrojový WAR soubor (The Apache Software Foundation, 2016). Druhou částí je modul klienta. Ten bude jako součást WAR souboru umístěn na stejný server. Pokud by to byl problém, anebo byl vyžadován jiný přístup, je možné tento modul jednoduše oddělit a umístit na jiné veřejně dostupné místo (v rámci intranetu, internetu apod.). Jelikož je modul realizován jako jednoduchá webová stránka ve formátu HTML, není kromě veřejné dostupnosti (je-li vyžadována) žádný jiný požadavek na jeho zprovoznění.

1 2

http://tomcat.apache.org/ https://netbeans.org/

52

Poslední částí je vytvoření databáze. Pro vývoj je použita databáze MySQL 3 , kterou po instalaci může zpřístupnit HeidiSQL

4

skrze své GUI. Nicméně použití

zvolené databáze není silně vázáno s aplikací. Po připojení jiného konektoru skrze Java Maven projekt je možné používat i jiné databáze. Tabulky databáze jsou přístupné na přiloženém CD.

5.1.1

PDF exporty

Část serveru používá open-source knihovnu wkhtmltopdf 5 , která velmi jednoduše vytvoří PDF soubor na základě poskytnutého zdrojového kódu webové stránky a grafických stylů CSS. Popis instalace (včetně instalačních souborů) je dostupný na webových stránkách projektu (Truelsen a Kulkarni, 2016).

5.1.2

Konfigurace parametrů

Před samotným používáním aplikace je ještě nutné nastavit parametry přístupu - z klientské části na serverovou a mezi prezentační a integrační vrstvou. Klientskou část je nutné editovat v samotné webové aplikaci resources/js v souborech main.js a parameters.js ve složce resources/js/config, kde je třeba ověřit dvojice parametrů: API URL definuje URL serverové části pro komunikaci RESTful API. Integration URL značí URL integrační části. S touto vrstvou se nekomunikuje přímo, nicméně data používají k identifikaci URL integrační části, se kterou je potřebné pracovat. Další parametry jsou nutné pro popis dat pocházejících ze serverové části. Parametry jsou použité hlavně z důvodu možných změn v sémantice dat, proto jejich změna je nutná pouze a jenom v případě změny v navazujících zdrojích. 3

http://dev.mysql.com/downloads/mysql/ http://www.heidisql.com/ 5 http://wkhtmltopdf.org 4

53

Serverovou část je možné parametrizovat v souboru config.properties ve složce serveru profiles. Parametry jsou použity následovně:

Database nastaví JDBC konektor databáze, další řádky nastavují uživatelské jméno a heslo přístupu k databázi. Templates folder definuje složku, ve které se nachází uložené šablony. Integration URL zná URL pro přístup k integrační části.

5.2

Funkcionalita systému

V následující kapitole se podíváme na podstatné funkce požadované od systému, které byly již dříve definovány v sekci 3.5.1. Mezi hlavní klíčové požadavky patří filtrování dat a zobrazení detailu entit, poté je důležitá možnost mezi entitami procházet a zobrazovat jejich krátké náhledy. Podstatné jsou i požadavky na změnu pohledů, jejich vytváření, editaci a přiřazení pohledů konkrétním entitám.

5.2.1

Vyhledávání dat

Vstupním bodem do systému je možnost vyhledávání dat. Uživatel si vybere entitu, kterou chce vyhledat, její atribut, porovnávací kritérium a hodnotu atributu. Integrační systém dovoluje filtrovat pouze entity silného typu, což znamená, že není možné vyhledávat mezi vázanými entitami. Jako důvod lze uvést příklad externích webových služeb, kde jako parametr poskytujeme identifikační číslo (IČ) společnosti a díky jeho znalosti získáme data. V obecném případě není možné získat veškeré entity a mezi nimi hledat, a to především ze dvou hlavních důvodů. Velmi často existuje omezení na počet dotazů na webové služby, případně by se jednalo o velké množství požadavků, jejichž splnění by potřebovalo příliš mnoho času. Problém by bylo možné vyřešit cachováním dat, což ale není požadavek na integrační vrstvu, viz. 1.

54

Obrázek 5.1 znázorňuje stránku filtru s výsledky, kde se po najetí myší zobrazí dodatečné informace s možností prokliknutí na detail entity.

Obrázek 5.1: Zobrazení vyhledávacího formuláře

5.2.2

Detail entity

Uživatel si může data zobrazit třemi způsoby, první byl popsán v předcházející kapitole - vyhledávání všech entit. Uživateli je poté nabídnuta možnost si data zobrazit (viz obrázek 5.2) a před samotným zobrazením detailu si zobrazit krátký detail (obrázek 5.3). Tato možnost je podobná případu užití, kdy chce uživatel mít možnost zobrazit tento detail na externí stránce.

55

Obrázek 5.2: Detail entity

Samotný detail poté nabízí následující doplňkové funkce:

∙ změna pohledu na data (vlevo nahoře) ∙ export pohledu do PDF formátu (tato funkce může být přímo definována pro šablonu) ∙ vytvoření a editace šablony ∙ zobrazení dodatečně načítaných atributů (na obrázku 5.2 se jedná o šedě vykreslené bloky dat), samotné načtení je možné definovat přímo v šabloně, případně načíst dvojím kliknutím na konkrétní blok ∙ filtrování dat v tabulce ∙ zobrazení skrytých sloupců v tabulce ∙ zobrazit krátký detail následující entity po najetí myší (řádek tabulky, anebo dodatečně načítaný atribut), viz obr. 5.3

56

Obrázek 5.3: Náhled před prokliknutím na další entitu

5.2.3

Editace pohledu

Samotná editace šablon je možná následujícím způsobem. Uživatel vybere dvojklikem šablonu, kterou chce editovat. Následně může přesouvat šablony stejného typu (a základní bloky), tím se vytvoří nový blok dat (viz obrázek 5.4). Jednotlivé bloky je možné editovat opět dvojklikem na konkrétní blok, viz 5.5. V této fázi uživatel uvidí metadata typu entity, k níž je šablona připojená, společně s dalšími informacemi, které jsou pro šablonu zajímavé. Veškerá interakce je založena na přetahování myší (z angl. drag & drop).

57

Obrázek 5.4: Souhrn všech šablon

Obrázek 5.5: Editace bloku šablony

58

5.2.4

Správa pohledů

Následující administrační tabulka na obrázku 5.6 znázorňuje hlavní funkcionalitu z pohledu administrace pohledů. Tato část umožňuje uživatelům mazat šablonu (její vytvoření je možné z detailu entity). Současně umožňuje přidávat a odebírat napojení mezi šablonou a entitou (případně všemi entitami konkrétního typu). Napojení se zapisuje následovně:

Prázdný řetězec značí veškeré entity daného typu. ID (řetězec/číslo) označuje entitu identifikovanou zvoleným klíčovým parametrem. Klíčové slovo quick naváže šablonu na krátký detail entity daného typu, krátký detail konkrétní entity proto není možný.

Obrázek 5.6: Správa přiřazení pohledů

59

5.3

Struktura pohledů

Sekce 5.2.3 popisuje editaci pohledů a jednotlivých bloků, které se mohou skládat z několika parametrů, jejichž význam je následující:

class - odpovídá HTML atributu class, podle nějž se prvek vykreslí [ŘMTS 6 ] data-label - popisek k bloku dat [ŘMTS] data-var - navázání bloku na atributy integračního systému a další funkce prezentační vrstvy, atribut se zapisuje do dvojitých složených závorek, př. Number of inspections: 𝑐𝑜𝑢𝑛𝑡({{𝑖𝑛𝑠𝑝𝑒𝑐𝑡𝑖𝑜𝑛𝑠}}) [ŘMTS] data-preview - navázání konkrétního atributu, pro který má být zobrazen krátký detail; data-var nelze použít z důvodu používání funkcí, např. i sjednocení více parametrů a krátký detail by tak nebyl unikátně definován [ŘTS] data-load - značí, zda se bude atribut načítat okamžitě (hodnota true), nebo až po dvojkliku uživatele [Ř] data-template - možnost zvolit šablonu, v níž se konkrétní entita zobrazí na své detailní stránce [ŘTS] data-thead - popisky sloupců tabulky (oddělené středníkem) [T] data-items - proměnné jednotlivých sloupců podobně jako data-var (případně oddělené středníkem) [TS]

6

značí použití v jednotlivých blocích dat: Ř - řádek, M - mapa, T - tabulka, S - seznam

60

6. Pohled programátora V následující kapitole si popíšeme klíčové části systému z pohledu rozšiřitelnosti aplikace (především nových formátů a nových bloků dat). Představíme si služby systému, které je možné napojit na jiné systémy (vč. popisu, jak napojit krátký náhled na HTML element externího systému). Krátce se zaměříme na popis jednotlivých balíčků a složek aplikace. Veškerá další programátorská dokumentace je dostupná na přiloženém CD (anglicky).

6.1

Napojení externí stránky

Jedním z důležitých požadavků společnosti C42 s.r.o. byla možnost napojení detailu entity na již existující systémy. Pro tento požadavek bude třeba sdílet určité JS soubory a případně i kaskádové styly. < link href = " { path }/ resources / css / main . css " rel = " stylesheet " type = " text / css " / > < link href = " { path }/ resources / css / templates . css " rel = " stylesheet " type = " text / css " / > < link href = " { lib }/ jquery - qtip . css " rel = " stylesheet " type = " text / css " / >

< script src = " { path }/ resources / js / main - ext . js " > < script src = " { lib }/ require . js " > < script src = " { lib }/ jquery - min . js " > < script > window . onload = function () { $ ( " # tem " ). bi ( " 26726548 " ); }; Zdrojový kód 6.1: Napojení na externí stránku 61

Jak znázorňuje kód 6.1, je třeba načíst dvojici volně dostupných knihoven jQuery (vč. qtip doplňku) a requireJS. Z této práce se načítá main-ext.js, což je minimalizovaná verze klientského modulu prezentační vrstvy. Nepovinně lze použít i vytvořené kaskádové styly. Krátká nápověda se poté zobrazí po najetí myší nad elementem propojeným s jQuery objektem a funkcí bi() s parametry IČ akciové společnosti nebo plným identifikátorem entity v rámci integračního systému.

6.2

Rozšířitelnost pohledů

Rozšiřitelnost aplikace se rozhodně předpokládá u formátu výstupu a zobrazení jednotlivých bloků dat. Zatímco formát dat je třeba zpracovávat jenom u klienta, bloky dat a jejich validitu je nutné validovat i na serverové části. Se zobrazením bloků dat souvisí velmi úzce používání definovaných funkcí, pro které platí podobný princip.

6.2.1

Formát výstupu

Případný požadavek na nový formát výstupu bude nutné řešit v rámci tříd jednotlivých bloků a jejich abstrakce js/templates/basic/AbstractTemplate.js. Každému bloku bude nutné nadefinovat novou převodní funkci z obecného formátu do konkrétního. Zmíněná abstraktní šablona a třída js/models/TemplateFactory.js poté na základě formátu zajistí zavolání správné převodní funkce. Pokud by neexistovala JavaScript knihovna pro práci s požadovaným formátem, bude nutné konverzní komponentu přesunout na server a zde konkrétní formát zpracovat. Nicméně podle současných požadavků, cílových formátů a podporujících JavaScript knihoven by toto nemělo být problémem.

62

6.2.2

Bloky dat a jejich funkce

U bloků dat a jejich funkcí je situace z pohledu klienta naprosto totožná s předchozím případem, protože stejné třídy mají na starost i vykreslení bloků. Problém nastává při ukládání, obnově a především validaci pohledů, kde je nutné reagovat i na případné změny v metadatech. Poté je nutné vědět, jestli blok dat zpracovává tabulky nebo jednoduché řádky, jaké proměnné jsou k bloku vázané a podobně. Pro tento účel monitoruje jednotlivé bloky a funkce balíček cz.c42.bi.template.xml.params a JAVA enum BasicEnum a FunctionEnum. Pro každý blok a funkci je potřeba definovat název a vstupní kardinalitu dat, resp. i výstupní a počet parametrů v případně funkcí bloků.

6.3

Komunikační modul

V kapitole 5 byla detailně představena klientská část, nyní se zaměříme na funkcionalitu serverové části s popsáním dostupných vstupních bodů. Veškerá komunikace směrem od klienta probíhá skrze RESTful API komunikačního modulu, proto se jedná o vrstvu, která by měla být důkladně popsána. Následující tabulky popisují hlavní funkcionalitu, bližší implementační podrobnosti (včetně potřebných vstupů a výstupů) jsou popsány v přiložené programátorské dokumentaci. Pokud není uvedeno jinak, metody v tabulkách jsou určeny ke čtení dat (HTTP požadavek GET).

6.3.1

Data Resource

Datový zdroj zajišťuje komunikaci s integračním rozhraním, je dostupný skrze /rest/data a zajišťuje dvě základní funkce. Bližší popis je dostupný v tabulce 6.1.

63

URL přístupu

Popis funkce Vrací detail entity ke zvolenému identifikátoru. Pokud není identifikátor uveden, vrací odkazy na se-

/

znamy všech nezávislých entit. Vrací metadata ke konkrétnímu typu entity nebo /metadata atributu. Tabulka 6.1: Služby komunikačního modulu - data

6.3.2

Search Resource

Vyhledávání dat je zpřístupněné skrze /rest/search a použití popisuje tabulka 6.2. URL přístupu

Popis funkce Vyhledá entity z integračního systému pomocí filtrovacích kritérií. Jedinou výjimkou je kritérium LIKE, jež v integračním systému není v současné

/

době implementováno a je řešeno až na straně prezentační vrstvy. Vyhledá vhodné šablony pro data. Pokud není /template žádná dostupná, poté ji vytvoří. /css

Vrátí dostupné třídy kaskádových stylů. Tabulka 6.2: Služby komunikačního modulu - vyhledávání

6.3.3

Template Resource

Poslední dostupný zdroj zajišťuje práci se šablonami a je dostupný skrze /rest/template. Tabulka 6.3 popisuje dostupné funkce.

64

URL přístupu

Popis funkce

/

Vrací seznam všech šablon.

/create

Vytváří novou šablonu pro požadovaný typ entity. Přepočítá pozice jednotlivých parametrů v šab-

/update loně. Vrací XML šablonu, podle níž budou vykreslena /xml data. Poskytuje seznam všech šablon společně s typy entit a konkrétními entitami, jež jsou k šabloně vá-

/entities

zané. /validate

Validuje šablonu, případně zajistí její opravu.

/remove-mapping Odstraní přiřazení šablony a entity. [DELETE] /remove

Kompletně odstraní požadovanou šablonu (včetně

[DELETE]

propojených informací).

/add-mapping Přidá provázání mezi šablonou a entitou. [POST] /save Uloží šablonu. [POST] /toPDF

Zajistí konverzi pohledu do PDF formátu a na-

[POST]

bídne soubor ke stažení uživateli. Tabulka 6.3: Služby komunikačního modulu - šablony

6.4

Přehled balíčků a složek

Pro snazší orientaci ve zdrojových kódech aplikace a v její dokumentaci slouží následující část popisující existující balíčky (v případě Java kódů) a hlavní složky (u Javascript kódů). Veškeré kódy vycházejí z návrhu systému popsaném v kapitole 4.

65

6.4.1

Java část

Následuje krátký seznam jednotlivých balíčků serverové části a jejich použití:

cz.c42.bi.core je základním balíčkem pro různé abstraktní a další obecné třídy. cz.c42.bi.integration.catalog obsahuje hlavní třídy pro data (metadata) poskytovaná skrze integrační vrstvu systému. Tyto informace jsou důležité pro navázání na šablony a pozdější identifikaci změn. cz.c42.bi.integration.catalog.enumerator zná různé seznamy hodnot z integračního systému (kardinalitu atributů a kdy bude atribut načten). cz.c42.bi.integration.rest komunikuje s integračním systémem. cz.c42.bi.rest je komunikačním modulem, skrze něj probíhá veškerá komunikace od klienta na server. cz.c42.bi.template.db obsahuje třídy a služby pracující s databázovými objekty a šablonami. cz.c42.bi.template.db.objects zná třídy reprezentující jednotlivé tabulky a relace databáze. cz.c42.bi.template.validator je hlavní službou zajišťující ověření validity šablon a jejich opravu. cz.c42.bi.template.validator.creator má na starost vytváření a správu jednotlivých bloků šablon. cz.c42.bi.template.validator.exceptions obsahuje možné výjimky vzniklé při validaci. cz.c42.bi.template.xml je balíčkem určeným pro práci s XML dokumenty, tedy šablonami. Zajišťuje jejich čtení, ukládání, transformaci do dalších Java objektů a podobné funkce. cz.c42.bi.template.xml.params zná jednotlivé parametry použité u jednotlivých bloků dat a jejich funkcí. 66

6.4.2

Javascript část

hlavní složka obsahuje hlavní soubory nutné pro správu požadavků uživatele, základní nastavení a konfiguraci aplikace a používaných knihoven. config monitoruje veškeré používané parametry používané při komunikaci s integrační vrstvou a komunikačním modulem prezentační vrstvy. Zná také parametry používané jednotlivými bloky šablon. controllers předává požadavky na další pohledy, nenese příliš velkou logiku aplikace. models zajišťuje funkcionalitu základních částí systémů - ať už grafických, nebo logických. templates/basic zpracovává základní bloky šablon, zajišťuje konverzi do cílového formátu a následné zobrazení. templates/html jedná se o základní HTML šablony jednotlivých stránek systému. views zajišťuje správu jednotlivých pohledů, většinou nese hlavní logiku požadavku. Logika je tedy více na straně pohledů (view) místo kontrolerů z důvodu použití knihovny Backbone.js (Backbone.js, 2016).

6.5

Programátorská dokumentace

Veškerá dokumentace (včetně zdrojových kódů aplikace) je dostupná anglicky na přiloženém CD.

67

7. Akceptační testy Poslední větší kapitolu tvoří akceptační testy systému společností C42 s.r.o., pro niž byla aplikace vyvíjena. Během předvedení aplikace byly testovány scénáře, které byly připravené již při samotné analýze projektu, společně s běžně používanými prohlížeči - Mozilla Firefox, Google Chrome, Safari, Internet Explorer 10 a Microsoft Edge. Testy nám současně ukázaly možná vylepšení, především lepší interakci uživatele. Na následujících stránkách si představíme jednotlivé testovací scénáře. Další testy serverové části (testy jednotek a integrační testy) jsou popsány v přiložené programátorské dokumentaci.

68

7.1

Hlavní funkcionalita systému

Název testu

Obecný přístup 1. Otevřít systém 2. Zobrazit stránku filtru 3. Zobrazí se seznam možných typů entit, mezi kterými lze vyhledávat

Postup testu 4. Uživatel vybere filtrovací kritéria 5. Uživatel potvrdí výběr a zobrazí se výsledky 6. Uživatel přejde na detail zvolené entity

Vyhodnocení

Přijato bez výhrad

Odůvodnění zadavatele Během testovací fáze vznikly menší problémy v prohlížečích IE10 a Safari, které nepodporují jisté Javascript funkce. Poznámky Jinak se systém chová stabilně ve všech testovaných prohlížečích.

69

7.2

Procházení mezi detaily entit

Název testu

Zobrazení navázaných entit 1. Zobrazit detail entity 2. Myší najet na entitu

Postup testu

3. Zobrazí se krátký souhrn zvolené entity 4. Uživatel buď přejde na detail entity, anebo pokračuje v procházení současné stránky

Vyhodnocení

Přijato bez výhrad

Odůvodnění

Test proběhl bez problémů, pouze v Microsoft Edge pro-

zadavatele

hlížeči vyskakuje krátká nápověda mimo prohlížeč. V dalším vývoji systému se zaměříme na podporu používaných prohlížečů a vyladění menších grafických problémů.

Poznámky Jelikož se jedná o interní systém, nebude problém zjistit potřebné prohlížeče a věnovat jim větší pozornost.

70

7.3

Změna pohledů na data

Název testu

Různé pohledy 1. Zobrazit detail entity 2. Uživatel má možnost změnit dostupné pohledy

Postup testu 3. Uživatel má možnost exportovat pohled do PDF formátu

Vyhodnocení

Přijato V prohlížeči Safari nefunguje vygenerování PDF doku-

Odůvodnění mentu, současně mají PDF dokumenty mírně odlišné zobzadavatele razení v porovnání s obrazovkou. V dalším vývoji bude jistě sjednoceno grafické zobrazení, které v době vývoje nemělo hlavní prioritu. Problém u SaPoznámky

fari je z důvodu blokování vyskakovacích oken, což bude možné opravit přesměrováním na vygenerovaný PDF dokument.

71

7.4

Zobrazení detailu

Název testu

Zobrazení atributů 1. Uživatel zadá požadavek na vykreslení zvolené entity 2. Systém automaticky načte data a jejich šablonu 3. Systém vykreslí jednotlivé bloky dat

Postup testu

4. Systém načte požadované dodatečně načítané atributy 5. Uživatel má nyní možnost zobrazit krátký detail atributu, přejít na jeho detail nebo atribut vykreslit v současném pohledu

Vyhodnocení

Přijato bez výhrad

Odůvodnění zadavatele Poznámky

72

7.5

Změny metadat

Název testu

Validita šablony vzhledem k metadatům 1. Uživatel smaže veškeré šablony v systému 2. Uživatel zadá požadavek na zobrazení konkrétní entity 3. Systém zajistí vytvoření nové šablony 4. Uživateli se zobrazí detail entity

Postup testu 5. Uživatel v administraci šablon přepíše atribut na neexistující 6. Uživatel zadá požadavek na vykreslení konkrétní entity k dané šabloně 7. Uživateli se zobrazí opravená šablona

Vyhodnocení

Přijato bez výhrad

Odůvodnění zadavatele Poznámky

73

7.6

Administrace šablon a jejich bloků

Název testu

Zobrazení atributů 1. Uživatel si vyžádá seznam uložených šablon 2. Uživatel vybere šablonu, kterou chce editovat 3. Uživatel může do šablony přidat nové bloky (šablony stejného typu)

Postup testu 4. Uživatel může měnit různé parametry jednotlivých bloků - navázanou proměnnou, popisek, dobu načtení parametru (okamžitě / při vyžádání) a šablonu, ve které se následující atribut, resp. entita zobrazí

Vyhodnocení

Přijato Tento systém je určitě dostačující, nicméně z hlediska uživatele, který chce pouze změnit pohled, možná až zbytečně komplikovaný. Častými změnami bude určitě přeskupení pořadí bloků, případně jejich úplné skrytí. Bylo by ideální

Odůvodnění přímo na detailu entit přepnout do editačního módu a tam zadavatele tyto změny provést pouhým přetažením. Jednoduchý blok by poté šlo editovat v okénku, které je již implementováno. Zároveň Internet Explorer 10 a Microsoft Edge překrývají některé elementy. Jedná se o požadavek na uživatelskou interakci, který nebude těžké zapracovat. Skrývání a zobrazení je již implementováno u sloupců tabulek, tento princip se přidá i na Poznámky jednotlivé bloky. Dalším krokem bude přetahování jednotlivých bloků myší a jejich napojení na existující editační okno.

74

7.7

Administrace zobrazení entit a šablon

Název testu

Zobrazení atributů 1. Uživatel si vyžádá seznam uložených šablon 2. Uživatel zvolí šablonu, ke které chce přiřadit určitou entitu 3. Uživatel zvolí konkrétní entitu, veškeré entity stej-

Postup testu

ného typu (pro které byla šablona vytvořena) anebo zobrazení v rámci krátkých náhledů 4. Uživateli se zobrazí potvrzení a aktualizovaný seznam šablon

Vyhodnocení

Přijato bez výhrad

Odůvodnění

Jediný problém je u prohlížečů Microsoft Edge a Internet

zadavatele

Explorer 10, u kterých se neaktualizuje tabulka šablon. Veškeré požadavky byly správně zpracovány, jen prohlížeče

Poznámky zřejmě zobrazují cachované HTML šablony.

75

Závěr Tato práce se zabývala vytvořením prezentační vrstvy k již existujícímu systému pro sjednocení a publikování dat z různých datových zdrojů. Integrační systém již dříve vznikl jako diplomová práce (Pánek, 2015), na kterou tato práce volně navazuje. Celý systém byl vyvíjen a podporován společností C42 s.r.o.. Samotnou prací jsme popsali jednotlivé fáze vývoje softwaru - od sběru požadavků, jejich analýzu až po návrh a implementaci celého systému. Během celého procesu jsme se seznámili s některými nově využívanými přístupy vývoje software - s dokumentačním UML, programovacími jazyky Java a Javascript a s jejich známými a často používanými knihovnami a doplňky. U vzniklé aplikace je předpokládáno reálné využití a napojení na již existující systémy společnosti, což znamená i další vývoj aplikace. Některé změnové požadavky popisují i akceptační testy. Předpokládá se změna uživatelského prostředí, aby veškerá interakce s aplikací nepotřebovala více kroků, než kolik jich je nezbytně nutných. Co se týká funkcionality, zde je možné aplikaci rozšířit o nové formáty, bloky dat a jejich doplňky. Cílová aplikace splňuje prvotní požadavky společnosti i této práce a je zároveň určena k dalšímu rozvoji a používání.

76

Seznam použité literatury Backbone.js (2016). Backbone.js documentation [online]. [cit. 19.7.2016]. URL http://backbonejs.org/#View. Berners-Lee, T., Hendler, J., Lassila, O. a kol. (2001). The semantic web. Scientific american, 284(5), 28–37. Berners-Lee, T., Chen, Y., Chilton, L., Connolly, D., Dhanaraj, R., Hollenbach, J., Lerer, A. a Sheets, D. (2006). Tabulator: Exploring and analyzing linked data on the semantic web. In Proceedings of the 3rd international semantic web user interaction workshop, volume 2006, page 159. Athens, Georgia. Bizer, C., Heath, T. a Berners-Lee, T. (2009). Linked data-the story so far. Semantic Services, Interoperability and Web Applications: Emerging Concepts, pages 205–227. Clements, P., Garlan, D., Bass, L., Stafford, J., Nord, R., Ivers, J. a Little, R. (2002). Documenting software architectures: views and beyond. Pearson Education. Gamma, E., Helm, R., Johnson, R. a Vlissides, J. (1994). Design patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Reading. Krasner, G. E., Pope, S. T. a kol. (1988). A description of the model-viewcontroller user interface paradigm in the smalltalk-80 system. Journal of object oriented programming, 1(3), 26–49. Microsoft Corporation (2016). Display data from multiple sources in a single data view [online]. [cit. 7.7.2016]. URL https://support.office.com/enus/article/Display-data-from-multiple-sources-in-a-single-DataView-f9898d20-a5ab-4973-9d16-9f4e4c088ae1. Pánek, O. (2015). Integration of heterogeneous data sources based on a catalog of master entities. Diplomová práce, Fakulta elektotechnická, České vysoké učení technické v Praze. 77

The Apache Software Foundation (2016). Tomcat web application deployment [online]. [cit. 18.7.2016]. URL https://tomcat.apache.org/tomcat8.0-doc/deployer-howto.html. Truelsen, J. a Kulkarni, A. (2016). wkhtmltopdf documentation [online]. [cit. 18.7.2016]. URL http://wkhtmltopdf.org/downloads.html. Wikipedia (2016a). Cross-origin resource sharing — wikipedia, the free encyclopedia [online]. [cit. 11.7.2016]. URL https://en.wikipedia.org/w/index. php?title=Cross-origin_resource_sharing&oldid=729143466. Wikipedia (2016b).

Comparison of web template engines — wiki-

pedia, the free encyclopedia [online].

[cit. 7.7.2016].

URL https:

//en.wikipedia.org/w/index.php?title=Comparison_of_web_template_ engines&oldid=727449498.

78

Seznam obrázků 1.1

Základní struktura cílové aplikace

. . . . . . . . . . . . . . . . .

1.2

Podporované datové zdroje a formáty

1.3

Náčrt struktury dat

7

. . . . . . . . . . . . . . .

7

. . . . . . . . . . . . . . . . . . . . . . . . .

10

2.1

Microsoft SharePoint - DataView . . . . . . . . . . . . . . . . . .

14

2.2

RESTful API browser - DHC REST Client

. . . . . . . . . . . .

16

2.3

Tabulator - pohled na data . . . . . . . . . . . . . . . . . . . . . .

17

2.4

Pohled na bloky dat . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.1

Případ užití - uživatel

29

3.2

Případ užití - pohledy na data

. . . . . . . . . . . . . . . . . . .

30

3.3

Případ užití - administrátor . . . . . . . . . . . . . . . . . . . . .

31

4.1

Proces vykreslení dat

. . . . . . . . . . . . . . . . . . . . . . . .

33

4.2

Návrh šablony a jednotlivých bloků . . . . . . . . . . . . . . . . .

38

4.3

Architektura aplikace

. . . . . . . . . . . . . . . . . . . . . . . .

41

4.4

Klient modul - jádro aplikace . . . . . . . . . . . . . . . . . . . .

42

4.5

Modul šablon . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.6

Integrační modul . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.7

Návrh databáze

. . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.8

Proces vykreslení pohledu . . . . . . . . . . . . . . . . . . . . . .

49

. . . . . . . . . . . . . . . . . . . . . . . .

79

4.9

Proces vytvoření šablony

. . . . . . . . . . . . . . . . . . . . . .

50

4.10 Proces opravy šablony při změně metadat . . . . . . . . . . . . .

51

5.1

Zobrazení vyhledávacího formuláře . . . . . . . . . . . . . . . . .

55

5.2

Detail entity

56

5.3

Náhled před prokliknutím na další entitu

. . . . . . . . . . . . .

57

5.4

Souhrn všech šablon . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.5

Editace bloku šablony . . . . . . . . . . . . . . . . . . . . . . . .

58

5.6

Správa přiřazení pohledů

59

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

80

Seznam tabulek 1.1

Popis sémantiky entit

. . . . . . . . . . . . . . . . . . . . . . . .

1.2

Popis sémantiky atributů

4.1

Porovnání možných přístupů pohledů

. . . . . . . . . . . . . . .

39

6.1

Služby komunikačního modulu - data . . . . . . . . . . . . . . . .

64

6.2

Služby komunikačního modulu - vyhledávání

. . . . . . . . . . .

64

6.3

Služby komunikačního modulu - šablony . . . . . . . . . . . . . .

65

. . . . . . . . . . . . . . . . . . . . . .

81

11 12

Seznam použitých zkratek AJAX - Asynchronous JavaScript and XML, asynchronní požadavky webových stránek API - Application Programming Interface, rozhraní aplikace ARES - Administrativní Registr Ekonomických Subjektů CORS - Cross-Origin Resource Sharing, sdílení zdrojů různého původu CSS - Cascading Style Sheets, grafické styly HTML elementů CSV - Comma-separated values, souborový formát tabulkových dat ČOI - Česká Obchodní Inspekce DAO - Data Access Object, abstrakce přístupu k datům DOM - Document Object Model, objektová reprezentace HTML a XML dokumentů DPH - Daň z Přidané Hodnoty HTML - HyperText Markup Language, značkovací jazyk pro tvorbu webových stránek HTTP - Hypertext Transfer Protocol, aplikační protokol pro hypertextové dokumenty IČO - Identifikační Číslo Organizace, unikátní osmimístné identifikační číslo organizací IDE - Integrated Development Environment, vývojové prostředí softwaru IRI - Internationalized Resource Identifier, mezinárodní identifikátor entit JS - JavaScript, skriptovací jazyk webových stránek JSON - JavaScript Object Notation, datový formát pro přenos dat

82

MVS - Model View Controller, typ softwarové architektury ORM - Object-Relational Mapping, automatická konverze dat z relační databáze PDF - Portable Document Format, souborový formát pro ukládání dokumentů nezávisle na softwaru i hardwaru RDB - Relační DataBáze REST - Representational State Rransfer, architektonický styl přístupu k datům SOAP - Simple Object Access Protocol, protokol pro výměnu zpráv SQL - Structured Query Language, standardizovaný dotazovací jazyk databází UI - User Interface, uživatelské rozhraní systému UML - Unified Modeling Language, modelovací jazyk softwarového inženýrství URI - Uniform Resource Identifier, identifikátor entit URL - Uniform Resource Locator, umístění zdroje informací XML - Extensible Markup Language, značkovací jazyk vytvořený konsorciem W3C XLS - Microsoft Excel Spreadsheet, tabulkový procesor společnosti Microsoft Corporation WAR - Web application ARchive, distribuovatelný soubor webových stránek

83

Přílohy Na přiloženém CD se nacházejí následující soubory:

∙ Zdrojové kódy aplikace (Java Maven projekt) ∙ Distribuovatelný WAR souboru ∙ Databáze projektu ∙ Vzorové šablony ∙ Samotný text práce ∙ Programátorská dokumentace serverové (Java) i klientské části (JavaScript)

84