Mendelova univerzita v Brně Provozně ekonomická fakulta
Inovace a rozšíření inventarizačního systému Bakalářská práce
Vedoucí práce: Ing. Oldřich Faldík
Jan Král
Brno 2015
Poděkování Velmi rád bych poděkoval Ing. Oldřichu Faldíkovi za odborné vedení práce, podnětné rady a připomínky, za velkou ochotu a za čas, který mi věnoval. Dále Ing. Tomáši Koubkovi a Ing. Tomáši Kubínovi za pravidelnou zpětnou vazbu a cenné připomínky.
Čestné prohlášení Prohlašuji, že jsem tuto práci: Inovace a rozšíření inventarizačního systému vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 22. května 2015
_______________________________
Abstract Král, J. Innovation and extension of inventory control system. Bachelor thesis. Brno: Mendel University, 2015. The bachelor thesis deals with the innovation of the inventory control system used at the Department of Informatics, Mendel University, which is used for recording the flow of assets during the year. Thesis at the beginning discusses how the old system complies with the current needs of users. Based on this analysis is designed new inventory control system, which eliminates the problems of old system and adds new functionality. The new system is implemented as a web application in PHP using the Nette framework. Keywords Inventory control system, web application, PHP, Nette, PostgreSQL
Abstrakt Král, J. Inovace a rozšíření inventarizačního systému. Bakalářská práce. Brno: Mendelova univerzita v Brně, 2015. Bakalářská práce pojednává o inovaci inventarizačního systému na Ústavu Informatiky Mendelovy Univerzity v Brně, který slouží pro zaznamenávání toku majetku během roku. Práce na začátku rozebírá, nakolik starý systém vyhovuje aktuálním potřebám jeho uživatelů. Na základě této analýzy poté navrhuje systém nový, který eliminuje problémy starého systému a přidává novou funkcionalitu. Nový systém je implementován jako webová aplikace v jazyce PHP s využitím frameworku Nette. Klíčová slova Inventarizační systém, webová aplikace, PHP, Nette, PostgreSQL
Správa uživatelů ............................................................................................................... 34
5.8
Skripty spouštěné z CRONu .......................................................................................... 35
6
Závěr
37
7
Literatura
38
A
Návrh nové databáze
41
B
Ukázka responzivity
42
C
Ukázka vygenerovaného PDF
43
D
Diagramy tříd
44
Seznam obrázků
7
Seznam obrázků Obr. 1
Proces inventarizace
10
Obr. 2
Princip fungování CGI
13
Obr. 3
Testování zabezpečení proti XSS - vložení skriptu do formuláře
14
Testování zabezpečení proti XSS - načtení a interpretace skriptu
14
Obr. 5
Původní databáze - entitně-relační diagram
16
Obr. 6
Ukázka uživatelského rozhraní stávajícího systému
18
Obr. 7
Diagram případů užití pro nový inventarizační systém
20
Obr. 8
Architektura MVC
21
Obr. 9
Původní řešení uživatelských rolí
22
Obr. 10
Nové řešení uživatelských rolí
23
Obr. 11
Návrh uživatelského rozhraní
24
Obr. 12
Databázové struktury pro Centrum sporu
29
Obr. 13
Proces importu CSV souboru
30
Obr. 14
Formulář pro tisk Potvrzení o převzetí
32
Obr. 15
Proces autentizace
35
Obr. 16
Nová databáze – entitně-relační diagram
41
Obr. 17
Uživatelské rozhraní – verze pro velké obrazovky
42
Obr. 18
Uživatelské rozhraní – verze pro mobilní zařízení
42
Obr. 19
Vygenerovaný dokument Potvrzení o převzetí předmětů
43
Obr. 20
Diagram tříd modelů
44
Obr. 21
Diagram tříd presenterů
45
Obr. 4
Seznam tabulek
8
Seznam tabulek Tab. 1
Ukázka dat z logovací tabulky log
15
Tab. 2
Slowly changing dimension (type II.)
17
Úvod a cíl práce
9
1 Úvod a cíl práce 1.1
Úvod
Inventarizační systém Ústavu Informatiky je interní nástroj, který slouží k operativní evidenci majetku během roku. Jeho hlavním účelem je udržovat aktuální informace o majetku na Ústavu informatiky a poskytnout možnost zpětně dohledat historické informace o libovolném majetku. Současný systém byl navržen před více než deseti lety a člověk odpovědný za jeho vývoj už na univerzitě nepůsobí. V poslední době byly sice prováděny některé inovace, přesto však systém aktuálním potřebám uživatelů nevyhovuje. Je potřeba dodat nové funkce, které by minimalizovaly rutinní, opakující se činnosti uživatelů a poskytly určitou míru automatizace. Uživatelské rozhraní je nepřehledné a nemoderní. Kód aplikace je nestrukturovaný a nekomentovaný, takže jakékoliv zásahy jsou poměrně obtížné. Aplikace využívá zastaralé a dnes už nepříliš používané technologie. Z výše uvedených důvodů uživatelé vznesli požadavek na inovaci systému a rozšíření o další funkce. V této práci popisuji celý proces inovace – analýzu současného systému, návrh systému nového a následnou implementaci. Na závěr zhodnotím výsledný systém a uvedu možnosti dalšího vývoje.
1.2 Cíl práce Cílem práce je inovovat stávající Inventarizační systém na ÚI PEF MENDELU tak, aby vyhovoval aktuálním potřebám jeho uživatelů. Hlavním požadavkem je ponechání stávajících stěžejních funkcí, odstranění funkcí zbytečných a přidání funkcí nových. Nový systém by měl být přehlednější, intuitivnější na ovládání a optimalizovaný i pro prohlížení z mobilních zařízení. Měl by tedy uživatelům umožňovat efektivnější práci než doposud. Systém by měl být navrhnutý tak, aby byl do budoucna snadno upravitelný a rozšiřitelný.
1.3 Role inventarizačního systému Abychom měli ucelenou představu o roli inventarizačního systému na Ústavu informatiky, uvedu, jak funguje inventarizace v kontextu celé univerzity. Povinnost inventarizovat majetek účetní jednotce ukládá zákon (Shiffer, 2006): „Účetní jednotky jsou povinny inventarizovat majetek a závazky podle § 29 a 30.“ Tuto povinnost MENDELU splňuje inventarizací za pomoci celouniverzitního systému SAP. Jak je znázorněno na Obr. 1, jedenkrát za rok se na univerzitě provede inventura, získaná data se uloží do SAPu a následně importují do interního systému Ústavu informatiky (dále v textu uváděn jako Inventarizační systém). Ten je
Úvod a cíl práce
10
již flexibilnější a jeho správci jsou schopni změny v toku majetku zaznamenávat prakticky ihned. Těmito změnami je myšleno např. přestěhování majetku do jiné místnosti, změna správce majetku, vyřazení majetku apod. Další výhodou oproti SAPu je, že systém eviduje větší množství informací o majetku, je tedy podrobnější.
Obr. 1
Proces inventarizace
Jak je dále zřejmé z Obr. 1, tok dat je pouze jednosměrný. Změny v SAPu se jedenkrát za rok importují do inventarizačního systému, ovšem změny v tomto systému se zpětně do SAPu nepromítnou. Tím pádem slouží zejména jako podpůrný inventarizační systém Ústavu informatiky.
Metodika řešení
11
2 Metodika řešení V první části práce rozeberu funkční požadavky na nový systém. Poté analyzuji jednotlivé části současného systému. Zjistím, jakým požadavkům vyhovuje a v čem naopak nedostačuje. Na systém budu nahlížet z různých úhlů. Zaměřím se na logickou stavbu aplikace a na její zabezpečení. Dále na způsob uložení dat v databázi, která tvoří podstatnou část systému. V poslední řadě zhodnotím, jak je aplikace přívětivá z hlediska uživatelského rozhraní. Poznatky z analýzy využiju při návrhu nového systému. Bude potřeba se rozhodnout, podle jaké architektury bude systém vystavěn. Dále jaké změny budu muset provést v databázi nebo zda nebude potřeba navrhnout databázi novou. Nakonec se zaměřím na návrh nového uživatelského rozhraní, které by mělo být jednoduché, přehledné a umožňovat prohlížení i z mobilních zařízení. Ve stěžejní části „Implementace a výsledek“ předvedu nově vyvinutý systém, okomentuji nejdůležitější části aplikace, shrnu výhody oproti současnému systému a nastíním, s jakými problémy jsem se potýkal při implementaci. Také se zmíním o technologiích použitých při vývoji. Na závěr zhodnotím výhody a nevýhody zvoleného řešení a možnosti budoucího rozšíření.
Analýza současného systému
12
3 Analýza současného systému V této části se práce zabývá analýzou současného systému s ohledem na cíl práce a na požadavky, které stanovil zadavatel. Posuzuje, zda současný stav požadavkům vyhovuje a porovnává možné přístupy řešení. Z analýzy jsem dále vycházel při návrhu nového systému.
3.1 Funkční požadavky Z konzultací se zadavatelem vyplynuly funkční požadavky na systém. Nový systém musí umožnit: • Snadno získat informace o majetku o Možnost vyhledávat, řadit podle libovolných atributů • Spravování majetku o Přidat majetek, editovat již existující, hromadná úprava majetku • Získání historických údajů o Historie změn majetku (změna uživatele, zůstatkové hodnoty…) o Z výpisu historie má být na první pohled zřejmé, které atributy se v minulosti měnily • Správu databázových číselníků (místnosti, stavy majetku…) bez nutnosti využívat nástroje třetích stran pro správu databází (phpPGAdmin, phpMyAdmin…) o Přidávání nových záznamů do databázových tabulek, editace stávajících, mazání nevyužívaných záznamů • Centrum sporu – výpis všech nekonzistencí v databázi a možnost jejich nápravy • Správu uživatelů a přístupových práv, udržování aktuálních informací o uživatelích • Dostačující zabezpečení celé aplikace • Export současného stavu databáze využitelný pro zálohování • Import (z .csv souboru exportovaného ze SAPu nebo ze zálohy databáze) • Generování a tisk písemných potvrzení o převzetí majetku • Tisk sestav (např. všechny předměty svěřené jednomu uživateli) o Tisk do PDF o Export do Excelu
3.2 Logická stavba aplikace Současný systém je implementován jako webová aplikace propojená s externí aplikací napsanou v jazyce Perl. Toto propojení umožňuje protokol Common Gateway Interface. Princip fungování je nastíněn na Obr. 2. Klient zašle požadavek na webový server, požadavek je zpracován externí aplikací, ta poté vrátí webovému serve-
I když v současnosti Perl poskytuje možnost objektového programování (od verze 5) a systém tuto možnost částečně využívá, nevyužívá všechny výhody objektového návrhu (např. dědičnost). Často se opakují kusy kódu a tak se kód stává nepřehledným a redundantním. Pro systém není vytvořená žádná dokumentace a kód není komentovaný. Prakticky neexistuje oddělení aplikační logiky, obsluhy databáze a uživatelského rozhraní, jak je zřejmé z následující ukázky, kde na jednom místě spouštíme databázový dotaz (zjišťujeme počet majetku v evidenci), ukládáme ho do proměnné a ihned vykreslujeme výsledek: my $sumCounter = $i->{dbz}->select('select count(int_mnozstvi) from inv_inventar where int_bezny_stav < 4')->[0][0]; print $i->{utils}->submitT('Celkový počet majetku: '.$sumCounter.' ks.'); Nový systém by měl být navrhnut tak, aby umožňoval snadné úpravy a rozšíření. Současný stav tento požadavek nesplňuje. Při úpravách se musí do kódu zasahovat na více místech najednou, což může být zdlouhavé a vést k možným chybám. Z těchto důvodů bude od současného modelu upuštěno.
3.3 Zabezpečení Aplikace běží na fakultním serveru, lze se na ni dostat pouze z univerzitní sítě, případně lze pro připojení z venkovní sítě využít SSH tunel1 (tuto možnost však musí Mezi koncovými uzly se vytvoří zabezpečené SSH spojení, které je šifrované, na rozdíl od klasického spojení TCP/IP (Barrett, Silverman, 2001).
1
Analýza současného systému
14
povolit správce sítě). Přístup na server je chráněn heslem, dostanou se k němu pouze oprávnění uživatelé. Autentizace je řešena na úrovni webového serveru Apache, na úrovni samotné aplikace již ne. K aplikaci se tedy nedostanou neoprávnění uživatelé. Další zabezpečení již řešeno není. Provedl jsem test, jak je systém zabezpečený proti útoku metodou Cross-site skripting (XSS). Při tomto útoku útočník vloží na webové stránky potenciálně nebezpečný skript (skript na straně klienta, např. JavaScript). Skript je poté prohlížečem spuštěn a může způsobit škody, např. úplně změnit strukturu nebo obsah stránky2 (Liang, 2014). K útoku se využívá slabé místo systému. V našem případě to jsou neošetřené výpisy z databáze. Pak stačí do databáze škodlivý skript dostat – například přes formulář pro vkládání nového majetku. Vložený skript vidíme na Obr. 3.
Obr. 3
Testování zabezpečení proti XSS - vložení skriptu do formuláře
Při přidání majetku se skript uloží do databáze jako Název zařízení a při příštím zobrazení tohoto majetku se spustí. Výsledek podstrčeného skriptu je vidět na Obr. 4.
Obr. 4
Testování zabezpečení proti XSS - načtení a interpretace skriptu
Neošetřené výstupy a vstupy od uživatele mohou vést k dalším bezpečnostním rizikům (SQL Injection). Proto je vhodné s možností útoků či zneužitím počítat Javascript má přístup k celé webové stránce, tedy i k DOM (Document Object Model), a může tak měnit strukturu dokumentu
2
Analýza současného systému
15
a hodnoty odesílané formulářem, stejně jako všechny dynamicky generované výpisy, ošetřit (např. escapovat speciální znaky. Liang, 2014). Současný systém má tedy bezpečnostní trhliny, které musí být při inovaci odstraněny.
3.4 Databáze Pro uložení dat je v současném systému využitý objektově-relační databázový systém PostgreSQL. Původní návrh databáze, který vidíme na Obr. 5, má několik nedostatků, kterými se budeme zabývat dále. V databázi chybí některá integritní omezení (absence vazeb mezi tabulkami inv_inventar a inv_typ_majetku, inv_mistnosti a inv_mistnost_type, které by z logiky věci chybět neměly). V databázi je dále tabulka log, do které se na úrovni webového serveru Apache logují veškeré požadavky na server (GET i POST požadavky, ukázkový záznam z databáze vidíme v tabulce 1). Doslova při každém kliknutí tedy přibude v tabulce záznam a tabulka velmi rychle roste a tím databázi i celý systém zatěžuje (nyní zabírá cca 98 % velikosti celé databáze, s počtem záznamů nad 4 000 000). Tab. 1
Ukázka dat z logovací tabulky log
log_user log_date log_uri user1 30.11.2006 7:12 GET /invent/NN.gif HTTP/1.1
I přes výše zmíněné nedostatky je původní návrh databáze kvalitní, vyhovuje normálním formám a dobře je nastavena i většina integritních omezení (cizí klíče, unikátní klíče…). Pro nově navrhovaný systém je současná podoba databáze vyhovující, nebudou potřeba velké zásahy. Navrhované změny budou probrány v kapitole Návrh nového systému.
Analýza současného systému
17
3.5 Historizace dat Jedním ze základních funkčních požadavků je ukládání historických dat o majetku. Mělo by být dohledatelné, v jakém stavu se majetek nacházel v libovolném časovém okamžiku. Praktickým příkladem použití může být okamžik, kdy se porouchá zařízení. V tu chvíli bychom chtěli dohledat, kdo dané zařízení spravoval v minulosti, a tudíž by mohl mít zkušenosti se vzniklou závadou a vědět, jak v tomto případě postupovat (restartovat systém, reklamovat produkt…). Analyzoval jsem současný stav databáze a porovnal s dalšími možnými přístupy k historizaci dat. Jak vidíme na Obr. 5, ve stávajícím systému je historizace řešena pomocí historické tabulky inv_inventar_history. Zde jsou uloženy všechny změny, které byly u daného majetku kdy provedeny. Informace o aktuálním stavu majetku se pak nachází v tabulce inv_inventar, která má prakticky totožnou strukturu jako tabulka historická. Pokaždé, když jsou údaje o majetku změněny, současný stav majetku se zkopíruje do historické tabulky a teprve potom je upravena tabulka s aktuálními informacemi. Tím jsou předchozí i současný stav uchovány a data historizována. Dalším přístupem k historizaci dat jsou tabulky navržené jako tzv. Slowly changing dimensions (dále SCD). Využívají se hlavně u dat, která se často mění, a je požadováno uchovávání jejich historie. Tento přístup počítá s tím, že data v tabulce se budou měnit pomalu, v nepředvídatelných intervalech, spíše než na pravidelné bázi (Kimball, 2002). Uvedu příklad na SCD typu II, který by v našem případě vypadal následovně: Tab. 2
Slowly changing dimension (type II.)
id_inventar 1 1 2 2
nazev notebook notebook PC PC HP 110-300nc
uzivatel Petr Vávra Jan Lukáš Petr Vávra Petr Vávra
Jak je zřejmé z Tab. 2, tabulka uchovává historické informace o majetku na univerzitě. Každý majetek je označen svým identifikátorem (sloupec id_inventar) a dále evidujeme dva atributy – nazev a uzivatel. Ty se v průběhu času mohou měnit. Jak vidíme, notebook dne 1. 10. 2012 změnil majitele a PC byl 1. 9. 2010 přejmenován na specifičtější název PC HP 110-300nc. Díky sloupcům platnost_od a platnost_do zjistíme, jakých hodnot nabývaly jednotlivé položky v průběhu času. Pokud ve sloupci platnost_do není uvedena hodnota, znamená to, že se jedná o záznam s aktuální platností. Tyto dva přístupy jsem porovnal a rozhodl se pro uchování současného stavu – dvou oddělených tabulek, jedné historické a jedné aktuální. Důvodem pro toto rozhodnutí je hlavně efektivita a rychlost práce s daty. Zatímco v SCD jsou všechna
Analýza současného systému
18
data uložena v jedné tabulce a tabulka tak rychle narůstá na objemu, v případě dvou oddělených tabulek narůstá pouze tabulka historická. Protože ve většině případů našeho systému pracujeme s tabulkou aktuální (vyhledáváme, řadíme, filtrujeme, editujeme atd.), narůstající historická tabulka nezpomalí běžný chod aplikace. K historické tabulce se přistupuje méně často, například při zobrazení historických záznamů konkrétního majetku. Operace nad tabulkou navrženou jako SCD by byly značně pomalejší vzhledem k většímu množství dat.
3.6 Uživatelské rozhraní Uživatelské rozhraní současného systému je jednoduché a účelné, jak vidíme z Obr. 6.
Obr. 6
Ukázka uživatelského rozhraní stávajícího systému
Struktura stránky je vybudována jen pomocí tabulek (tzv. tabulkový layout. Gasston, 2013). Formátování je řešeno přímo u jednotlivých HTML prvků, jak je vidět v následující ukázce, kde HTML prvek určuje červenou barvu textu3. Evidence majetku Ústavu informatiky Stejně tak by mohl tag text podtrhnout, zvětšit velikost font či změnit rodinu písma. To vše se ale dnes řeší pomocí kaskádových stylů (CSS).
3
Analýza současného systému
19
V dnešní době je obvyklé vzhled definovat odděleně pomocí CSS, zatímco HTML prvky určují pouze obsah a strukturu. Také je dnes běžné rozvrhnout layout stránky pomocí CSS, nikoliv pomocí tabulek, jak se dělalo dříve (Gasston, 2013). Výše zmíněná stavba dokumentu může být dána dobou, ve které byl systém vyvíjen a nedostupností technologií. Uživatelské rozhraní má ovšem jiné nedostatky, kterým se budu věnovat v následujících odstavcích. V prvé řadě si je třeba uvědomit, že systém pracuje s obrovským množstvím dat. Zobrazuje však více informací, než uživatel většinou potřebuje a stává se tak nepřehledným. Možnost výběru zobrazovaných informací je zde velmi omezená. Na Obr. 6 vidíme prvních devět řádků z výpisu majetku, celá tabulka má přes dva tisíce řádků. Když uživatel roluje dolů, zaprvé mu z obrazovky zmizí navigační menu v levém panelu, zadruhé neuvidí záhlaví tabulky (tedy názvy sloupců). Všechny zmíněné nedostatky znesnadňují orientaci uživatele. Některé části systému jsou nevyužívané, některé naopak nevhodně umístěné. Např. editace majetku je rozdělena do dvou částí, každá z nich je dostupná odjinud. To uživatele může mást. Na mobilním zařízení se s aplikací pracuje obtížně. Navigační prvky a tlačítka jsou příliš malá pro displej s menším rozlišením. Shrnuto, uživatelské rozhraní odpovídá době, kdy aplikace vznikala, ale z dnešního pohledu je zastaralé, není responsivní a je místy nepřehledné. Pro nový systém navrhnu rozhraní nové, s použitím moderních technologií a vyhovující současným požadavkům.
Návrh nového systému
20
4 Návrh nového systému Z analýzy vyplynulo, že bude lepší vyvinout systém nový. Úprava současného systému by byla značně náročná a neefektivní. Na základě funkčních požadavků jsem sestavil Use case diagram (diagram případů užití, Obr. 7) znázorňující skupiny uživatelů, které budou se systémem pracovat a všechny akce, které dané skupiny mohou v rámci systému provádět.
Obr. 7
Diagram případů užití pro nový inventarizační systém
Návrh nového systému
21
První skupinou jsou Pozorovatelé. Mohou vykonávat pouze akce, kterými neprovedou žádné změny v databázi. Mohou tedy vyhledávat v evidenci, zobrazit si detail majetku včetně jeho historie, ale už ho nemůžou upravit. Dále můžou tisknout různé sestavy a potvrzení o převzetí majetku. Druhou skupinou jsou Administrátoři. Mají stejná práva jako Pozorovatelé, k tomu navíc mohou přidávat a editovat majetek, upravovat databázové číselníky, provádět import a export a mají přístup do centra sporu. Posledním aktorem, který k systému přistupuje, je softwarový démon CRON. Jednou denně vzdáleně spouští dva důležité skripty, které udržují databázi aktuální. Více v kapitole Skripty spouštěné z CRONu. Výhodou Use case diagramu je, že při implementaci výrazně ulehčí definování rolí a přístupových práv.
Model je datový a zejména funkční základ celé aplikace. Je v něm obsažena aplikační logika. View, tedy pohled, je vrstva aplikace, která má na starost zobrazení výsledku požadavku. Používá šablonovací systém a ví, jak se má zobrazit ta která komponenta nebo výsledek získaný z modelu. Controller (případně Presenter) je
Návrh nového systému
22
řadič, který zpracovává požadavky uživatele a na jejich základě pak volá patřičnou aplikační logiku (tj. model) a poté požádá view o vykreslení dat. Požadavky zmíněné výše splňuje framework Nette, který je napsaný v PHP, dodržuje principy MVC a plně využívá výhody objektového přístupu (členění do tříd, zapouzdření, dědičnost…). Nový systém tedy bude implementován právě v tomto frameworku. Objektový návrh vidíme na Obr. 20 a Obr. 21 (diagramy tříd).
4.2 Databáze Již dříve bylo řečeno, že strukturu současné databáze nebude potřeba od základu měnit. V novém návrhu byly provedeny tři výrazné změny, které budou popsány v této kapitole. Celý entitně-relační diagram upravené databáze naleznete v přílohách na Obr. 16.
Obr. 9
Původní řešení uživatelských rolí
Provedené změny: • Řešení uživatelských rolí. Původní přístup vidíme na Obr. 9. Tabulka inv_uzivatele obsahuje sloupce uziv_active_login a uziv_super, které nabývaly hodnoty true/false a sloužily pro definování rolí (administrátor, aktivní uživatel…). Když uvážíme, že by do budoucna role přibyly, znamenalo by to přidání dalších sloupců a tím pádem změnu struktury tabulky. Většinou je snazší přidávat řádky, než sloupce4, takže jsem systém rolí změnil a přidal tabulku role, která je na tabulku uzivatele navázaná cizím klíčem id_role. Každý uživatel tak spadá pod určitou roli (administrátor, pozorova-
V případě přidání řádku (záznamu) pouze vkládám nové hodnoty do již existující struktury. V případě přidání sloupce měním strukturu databázového objektu. To může být zdlouhavé, například když potřebuji definovat nový, povinný sloupec. Prvně vytvořím nepovinný sloupec. Poté ho naplním daty. A až v poslední řadě ho můžu nastavit jako povinný (do té doby obsahuje prázdné NULL hodnoty, nemůže tedy být povinný).
4
Návrh nového systému
23
tel…), která mu poskytuje příslušná práva. O definování uživatelských práv pomocí ACL5 bude psáno později. Nové řešení vidíme na Obr. 10.
Obr. 10
Nové řešení uživatelských rolí
• Přidání struktur pro nově vzniklé Centrum sporu • Přidání struktur pro uživatelsky definované šablony (tedy seznam sloupců, které se uživateli zobrazí při výpisu seznamu majetku)
4.3 Uživatelské rozhraní Základní požadavky na nové uživatelské rozhraní byly jednoduchost, přehlednost a responzivita6. Co se responzivity týče, primárně bude aplikace navržena pro desktop, sekundárně pak pro mobilní zařízení. Důvodem je fakt, že naprostá většina práce v inventarizačním systému je prováděna z kanceláře, kde je k dispozici monitor s větším rozlišením. Pro případy, kdy se uživatel potřebuje dostat k informacím ihned (např. zjistit, v jaké místnosti je nainstalovaný program, který potřebuje; kdo je správcem porouchaného dataprojektoru…), je systém optimalizován i pro mobilní zařízení. Vzhledem k výše zmíněným požadavkům jsem se rozhodl uživatelské rozhraní navrhnout v zásadách flat designu. Je to směr moderního digitálního designu, který se zaměřuje na minimalistický vzhled a odstraňuje všechny prvky a efekty, které dodávají iluzi třetí dimenze, jako jsou stíny, zkosení, světelné efekty, textury nebo hloubka ostrosti. Tímto vznikne jednoduše a čistě vypadající layout, který na obrazovce působí ploše. Mimo výše zmíněného klade flat design důraz na typografii, světlé a jasné barvy a jednolité barevné plochy. Svou jednoduchostí a účelností je tedy také vhodný pro responsivně laděné projekty (Pratas, 2014). Jako další prostředek k dosažení jednoduchého vzhledu jsem zvolil využívání piktogramů místo textu, například jako navigačních prvků. Piktogramy nabývají na 5 6
Access Control List, vrstva pro řízení práv a přístupu. Optimalizace zobrazení webových stránek pro zařízení různých velikostí a rozlišení.
Návrh nového systému
24
důležitosti zejména v případě mobilní verze, kdy prostoru na obrazovce není mnoho a velké množství textu ubírá na přehlednosti (např. v případě navigačního panelu). Další výhodou je, že piktogramy většinou uživateli evokují tlačítka, interaktivní prvky, čímž minimalizují častý problém flat designu – a to špatné rozlišení pasivních a interaktivních prvků (Pratas, 2014). Jak již bylo zmíněno, důležitou součástí návrhu je typografie. Pro tento účel jsem využil webové fonty, konkrétně Google Fonts. Důvodů je několik. Zaprvé, jsou dostupné pod licencí Open Source a tedy volně k užití, na rozdíl od komerčních licencí (The Google Fonts Team, 2015). Zadruhé, je to možnost, jak uživateli poskytnout font, který není základní, více se hodí k navrženému webu, a tedy přispívá k pozitivnímu dojmu. Zatřetí, použití je velmi snadné – stačí jedna řádka kódu obsahující odkaz na font. Důležitým aspektem responzivity je používání relativních jednotek namísto absolutních (Lagrone, 2013). Tedy např. velikost písma se udává v jednotkách rem, namísto absolutních mm (milimetry) nebo pt (typografický bod). Relativní jednotka rem znamená Root EM, velikost fontu je tedy relativní k velikosti kořenového fontu (typicky prvku ). V kombinaci s meta tagem viewport7 vytvoříme písmo, které bude dobře čitelné na velkém monitoru, tabletu i telefonu. Při návrhu uživatelského rozhraní jsem postupoval následovně. Nejdříve jsem navrhl layout stránky (viz Obr. 11).
Obr. 11
Návrh uživatelského rozhraní
Tento layout jsem dále rozpracoval ve vektorovém editoru Inkscape, a to jak pro desktopovou verzi, tak pro verzi mobilní. Poté jsem návrh implementoval pomocí Meta tag viewport říká prohlížeči, jak má rozmístit obsah na displej a informuje prohlížeč o tom, že stránka je optimalizovaná pro mobily (Malý, 2011). 7
Návrh nového systému
25
značkovacího jazyka HTML a kaskádových stylů CSS. Na závěr jsem přidal interaktivní prvky pomocí JQuery (javascriptová knihovna) a CSS3. Během vývoje aplikace jsem uživatelské rozhraní několikrát měnil, na základě zpětné vazby od zadavatele. Podoba návrhu a výsledného reálného vzhledu se tedy mírně lišila. Při tvorbě uživatelského rozhraní je dále třeba myslet na to, že jedna webová stránka se může v různých prohlížečích zobrazovat rozdílně. Proto jsem se aplikaci snažil optimalizovat pro různé prohlížeče – Google Chrome, Mozzila Firefox, Internet Explorer, Opera. Uvedu jeden příklad za všechny: prohlížeče vycházející z WebKitu8 mají jako výchozí barvu pozadí formulářových prvků, které byly automaticky vyplněny (autofill), žlutou – což pro výsledný navrhovaný vzhled není žádoucí. Tuto skutečnost vyřeší následující kus CSS, který formulářový prvek vyplní vnitřním stínem požadované barvy a překryje tak původní žlutou: input:-webkit-autofill { -webkit-box-shadow: 0 0 0px 1000px #ecf0ff inset; } Aby se uživatel v systému snadno orientoval, měl by vidět pouze ty části systému, ke kterým má přístup. Při návrhu vycházíme z rolí, které jsme definovali v Use case diagramu na začátku kapitoly. Uživatelské rozhraní pro Administrátora vypadá tedy jinak než pro Pozorovatele. Pozorovatel má méně práv, proto bude jeho uživatelské rozhraní mnohem jednodušší.
Pro uložení dat jsem se rozhodl využít stávající databázový systém PostreSQL. Důvody pro ponechání byly následující: • PostgreSQL je vhodné pro zpracování velkého objemu dat a pro složitější operace • Poskytuje i procedurální nástavbu jazyka SQL nazvanou PL/pgSQL, díky které lze vytvářet funkce. Přispívá tak tedy k znuvupoužitelnosti kódu • Je vydáno pod licencí typu MIT, je to tedy Open Source9 (WikiVS, 2015) • Pro původní databázi byl také využit databázový systém PostgreSQL, výkonnostně vyhovoval a uživatelé byli dlouhodobě spokojeni. 5.1.4
HTML a CSS
Pro popis struktury webové stránky jsem využil značkovací jazyk HTML, konkrétně jeho nejnovější verzi HTML5. HTML5 přichází s novými značkami, jako například sémantické prvky ,
