České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Správa zařízení pomocí informačního systému pro podporu call centra Bc. Lukáš Vlk
Vedoucí práce: Ing. Božena Mannová, Ph.D.
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 14. května 2010
iv
v
Poděkování Rád bych poděkoval všem, kteří mi poskytli cenné rady a připomínky při realizaci mé diplomové práce – především vedoucí práce Ing. Boženě Mannové, Ph.D. a operátorkám call centra společnosti KLIMAX TEPLICE s.r.o.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract This master thesis deals with analysis and design of an information system of call centre of company servicing air-conditioning and refrigerating systems. The analysis of company needs, design and implementation of the information system is described. The application is realised as open system so it may be easily upgrade. The company benefit is customized solution which helps to company control over all orders and make better use a company potential.
Abstrakt Diplomová práce se zabývá analýzou a návrhem informačního systému pro podporu provozu call centra společnosti starající se o servis klimatizačních, mrazících a chladících zařízení a vzduchotechniky. Výsledkem je zmapování potřeb společnosti, návrh a realizace informačního systému vhodného pro další rozšíření. Přínosem pro společnost je namíru šité řešení, které jí umožní získat přehled nad zakázkami a lépe využít svůj potenciál.
Úvod V kapitole Úvod představím cíl diplomové práce a její strukturu. Zmíním se o motivaci, která mne vedla k výběru tématu diplomové práce. Pro informační systém jsem zvolil název AirManager, protože se jedná o systém pomáhající spravovat zařízení z oblasti klimatizace a vzduchotechniky.
1.1
Cíl práce
Cílem diplomové práce je navrhnout informační systém, který zjednoduší a zefektivní práci ve firmě zabývající se montážemi a opravou klimatizačních, mrazících a chladících zařízení a vzduchotechniky. Návrh provést podle požadavků společnosti a následně ho zrealizovat a prakticky ověřit.
1.2
Struktura diplomové práce
Diplomovou práci jsem rozdělil do následujících kapitol. 1. Úvod – V úvodu je nastíněn cíl a motivace, která mne vedla k výběru tématu diplomové práce. 2. Úvod do problematiky – V této kapitole zmíním již existující implementace podobných systémů, o kterých jsem nalezl informace. 3. Analýza a návrh řešení – Kapitola Analýza a návrh řešení obsahuje analytickou a návrhovou část diplomové práce. Je zde definice základních pojmů použitých v této práci. Uvádím zde požadavky na IS, definuji uživatelské role a popisuji volbu nástrojů pro implementaci. 4. Realizace – V této kapitole popíši strukturu kódu informačního systému a zaměřím se na zajímavé části programu. 5. Testování – Testování prověří funkčnost programu. V této kapitole popíši, jak jsem testování prováděl.
1
2
KAPITOLA 1. ÚVOD
6. Závěr – Dosažení vytčeného cíle, přínosu tohoto informačního systému a jeho další rozšíření je zhodnoceno v této kapitole. 7. Seznam použitých zkratek – V příloze je uveden seznam použitých zkratek. Vybrané zkratky a pojmy jsem vysvětlil v kapitole 3 na straně 9. 8. UML diagramy – Do přílohy jsem umístil obrázky UML diagramů. 9. Datový model – Vzhledem k rozsahu datového modelu jsem jeho kompletní výpis umístil samostatně do přílohy. 10. Instalační a uživatelská příručka – Zde je uveden popis instalace a informace o spuštění programu. Před začátkem používání systému doporučuji každému nahlédnout do této příručky. 11. Obsah přiloženého DVD – Adresářová struktura s popisem a obsahem jednotlivých adresářů je uvedena v této části.
1.3
Motivace
Motivací k návrhu informačního systému pro správu zařízení je dlouhodobá spolupráce se společností KLIMAX TEPLICE s.r.o. A tak když mě požádala o pomoc s návrhem systému, který společnosti pomůže zvýšit efektivitu, neváhal jsem a nabídl své služby.
Kapitola 2
Úvod do problematiky Informační systém, který navrhuji, lze definovat několika vlastnostmi vyjadřující smysl použití. V prvé řadě se jedná o systém, který eviduje jakési zakázky, které jsou sjednány mezi společností a klientem. Dalo by se tedy říci, že se bude jednat o zakázkový systém. Také se jedná o systém, který usnadňuje komunikaci mezi společností a klientem. Společnost tak získává přehled o potřebách klienta. Například z dat uložených v systému je možné vyhodnotit, jaká zařízení jsou více problémová a doporučit klientovi jejich výměnu a tím snížit náklady na stálé opravy zastaralých zařízení. Pro systémy, které se starají o komunikaci mezi společností a zákazníkem, se používá označení CRM, což je zkratka spojení Customer Relationship Management. Dalo by se tedy říci, že navrhovaný informační systém je na míru šité řešení spojení zakázkového a CRM systému. V této kapitole uvádím několik informačních systémů, které již byly v této oblasti vytvořeny.
2.1
Diplomová práce – Informační systém pro podporu servisů kopírovací techniky
Nejprve jsem prováděl analýzu současných řešení v Elektronické archivaci diplomových a bakalářských prací na ČVUT. Nalezl jsem zde diplomovou práci Jana Skořepy na téma Informační systém pro podporu servisů kopírovací techniky. Autor svoji práci popisuje takto: „Tato diplomová práce je zaměřena na tvorbu informačního systému, který umožní jednoduchou správu kopírovacích strojů a archivaci činností na nich provedených. Informační systém bude tvořen ve spolupráci s firmou SKORI, s. r. o. Jedná se o malou firmu, která v oboru servisu a prodeje kopírovací techniky již několik let podniká a žádný specializovaný informační systém zatím nevyužívá. Tato diplomová práce je navrhována na míru této firmě, která specifikovala požadavky na informační systém, schvalovala návrhy, požadovala změny a na závěr zhodnotila úspěšnost a použitelnost navrženého systému.“
3
4
2.2
KAPITOLA 2. ÚVOD DO PROBLEMATIKY
Microsoft Dynamics CRM
Na stránkách společnosti Microsoft [10] popisují produkt následovně: „Microsoft Dynamics CRM je komplexní řešení pro řízení zákaznických vztahů, které poskytuje veškeré nástroje a funkce potřebné pro vytvoření a udržení dobrého přehledu o zákaznících, od prvního kontaktu, přes prodej až po následnou péči o klienta. S moduly Prodej, Marketing a Servis Microsoft Dynamics CRM nabízí funkce a možnosti k lepšímu zacílení nových zákazníků, správě marketingových kampaní, řízení obchodních aktivit a řešení a eskalaci servisních případů. Microsoft Dynamics CRM umožňuje udržovat zákaznické informace na jednom místě, podporuje týmovou práci a pomáhá v plnění úkolů v rámci nastavených firemních procesů.“
Obrázek 2.1: MS Dynamics CRM – Obchodní procesy. Osobně jsem se zúčastnil slavnostního uvedení Microsoft Dynamics CRM na český trh, které se konalo v březnu 2008 pod názvem: „CRM, které stačí jen zapnout!“ Proběhla zde ukázka funkcí systému a svoji prezentaci zde měli i klienti využívající tento systém. Vždy se jednalo o velké společnosti, jednou z nich byla např. Česká televize. Zástupce tohoto veřejnoprávního média nám nastínil jejich využití systému MS Dynamics CRM. Popsal, jak dříve neměli přehled o tom, jak jsou zodpovídány dotazy diváků. Nevěděli, zda se náměty a připomínky dostaly ke správným lidem a zda na ně reagovali, nebo si je alespoň přečetli. Naopak po nasazení CRM systému se vše zpřehlednilo, zefektivnilo a management dostal do ruky nástroje, pro vyhodnocování nabízených zkušeností.
2.2. MICROSOFT DYNAMICS CRM
Obrázek 2.2: MS Dynamics CRM – Dash.
Obrázek 2.3: MS Dynamics CRM – Obchodní vztahy.
5
6
KAPITOLA 2. ÚVOD DO PROBLEMATIKY
2.3
Informační systém BYZNYS Win
Společnost J.K.R. s. r. o. popisuje svůj produkt takto: „ERP systém BYZNYS Win je nástroj pro komplexní řízení podniku. Je určen pro společnosti, které chtějí sjednotit podnikové agendy nebo získat pomocníka pro komfortní zvládnutí základních potřeb společnosti v oblasti sledování kompletních ekonomických agend. BYZNYS Win nabízí řešení pro plánování a řízení všech klíčových podnikových procesů a to na všech úrovních podnikové architektury. Systém je navržen tak, aby v těchto klíčových procesech maximálně zvýšil efektivitu.“ „Svým rozsahem nabízených modulů a vysokou variabilitou při nasazování je schopen pokrýt potřeby společností různého oborového zaměření od obchodních společností, přes účetní společnosti až po výrobní podniky různého zaměření. BYZNYS Win tak dokáže najít řešení pro společnosti, které mají rozsáhlé požadavky, ale i společnosti, u kterých je dán důraz na zpracovávání velkých datových objemů.“ Informační systém BYZNYS Win obsahuje mimo jiné moduly CRM a Zakázky. Modul CRM poskytuje uživatelům možnost evidence a analýzy vztahů se zákazníky. Analýza vztahu s partnerem 1 přitom může čerpat z několika odlišných pohledů viz obrázek 2.4.
Obrázek 2.4: BYZNYS Win – Analýza vztahů s partnerem.
Modul Zakázky tvoří nadstavbu účetního okruhu v systému BYZNYS, ve kterém se zpracovávají tzv. výsledné kalkulace. Čerpal jsem z nápovědy k systému BYZNYS, kde je zákazník nazýván obchodním partnerem. V analýze je použit pro slovo partner jiný význam viz. 3.5. 1
7
2.4. ZHODNOCENÍ
Obrázek 2.5: BYZNYS Win – Modul Zakázky.
Zakázka je v pojetí systému BYZNYS obsahem a časem omezená činnost uvnitř účetní jednotky, kterou je třeba samostatně ekonomicky vyhodnocovat (resp. u které je potřeba sledovat alespoň jednu položku kalkulačního vzorce), tj. sledovat ziskovost zakázek. K vyhodnocení ziskovosti modul Zakázky nabízí: • evidenci karet zakázek s možností pozdější aktualizace kmenových i položkových údajů; • natažení nákladů a výnosů z modulů Finanční účetnictví, Fakturace, Pokladna, Mzdy a personalistika a Skladového hospodářství s automatickým členěním údajů do položek kalkulačního vzorce; • ruční doplnění a opravu dat nákladů a výnosů; • automatické propočítávání nepřímých režijních nákladů; • tvorba plánu zakázky (plánové kalkulace); • srovnání plánu zakázky se skutečností; • přehledy a tisky zakázek dle různých kritérií;
2.4
Zhodnocení
Diplomová práce kolegy Jana Skořepy z FEL ČVUT je zaměřena na jednoduchou správu kopírovacích strojů a archivaci činností na nich provedených a byla navrhována na míru firmě SKORI s. r. o. Z toho důvodu nesplňuje nároky společnosti KLIMAX TEPLICE s. r. o., která má zcela odlišné požadavky a zaměření. Naopak systém MS Dynamics CRM je velmi komplexní systém, který se však zaměřuje na komunikaci s klientem, delegování této komunikace odpovědným zaměstnancům a především na marketingové akce společnosti.
8
KAPITOLA 2. ÚVOD DO PROBLEMATIKY
Třetí zmíněný systém BYZNYS Win má moduly, jak pro CRM, tak i pro Zakázky. Soustředí se však především na ekonomické ukazatele zakázek. V době realizace diplomové práce se společnost KLIMAX TEPLICE s. r. o. rozhodla nasadit nový podnikový informační systém BYZNYS Win od společnosti J.K.R. s. r. o., jako náhradu za dřívější účetní program. Při analýzách bylo zjištěno, že BYZNYS Win umí plánovat a vyhodnocovat zakázky společnosti, ale zaměřuje se především na ekonomické ukazatele, jako jsou náklady, výnosy a zisk. Kdežto můj informační systém se zaměřuje především na plánování, sběr a vyhodnocování neekonomických informací, jako jsou např. výjezdy, splnění priorit, přehled typů spravovaných zařízení, umístění a dalších. Příkladem může být např. to, že systém BYZNYS Win nemá, kde shromažďovat informace, jako je přehled spravovaných zařízení se všemi požadovanými údaji. I když existují programy, které řeší danou problematiku obecně, management společnosti si vybral pro tuto oblast řešení tzv. šité na míru. Vztah programátor – zákazník přináší své výhody oproti univerzálním systémům. Úpravy programů na přání zákazníka jsou lépe řešena, často rychleji a přesněji na rozdíl od univerzálních řešení, kde tuto úpravu musí požadovat více uživatelů, neboť požadavky jednoho zákazníka jsou příliš drahé na realizaci doplňků v rozsáhlém systému.
Kapitola 3
Analýza a návrh řešení Při analýze a návrhu informačního systému jsem čerpal informace z knih [17], [1], [5] a také z poznámek z předmětu Architektura softwarových systémů vyučovaného na katedře počítačů FEL ČVUT. V této práci jsem použil následující terminologii. Úplný seznam zkratek je uveden v příloze. AJAX Asynchronous JavaScript and XML CRM Customer Relationship Management – řízení vztahů se zákazníky EJB Enterprise Java Bean – někdy se také používá název Session Bean. Používá se k psaní aplikační vrstvy (Business vrstvy). Facelets Framework představující šablonovací systém pro Java EE GUI Grafické uživatelské rozhraní Java EE Java Enterprise Edition Java ME Java Micro Edition Java SE Java Standard Edition JPA Java Persistence API – Java EE standard – Zabývá se objektově relačním mapováním; představuje databázovou vrstvu. JPA TopLink Essentials – Implementace JPA od společnosti Oracle JPQL Java Persistence Query Language – Objektové SQL definované v JPA. JSF Java Server Faces – Java EE standard – Technologie pomocí níž se realizuje prezentační vrstva. JTA Java Transaction API – Java EE standard – Zabývá se transakcemi. MBean Managed Bean – někdy se též používám označení Backing Bean. MVC Model – View – Controllec
9
10
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
ORM Objektově relační mapování Richfaces Knihovna obsahující GUI komponenty podporující AJAX VBA Visual Basic for Application VPN Virtual Private Network
3.1
Uživatelské role
Uživatele informačního systému je třeba rozdělit do uživatelských rolí podle jejich pravomocí a potřebných funkcí. Po seznámení se s prostředím společnosti jsem rozdělil uživatele do následujících rolí: • Administrátor – představuje správce systému a má přístup do celého systému. • Callcentrum – operátorky call centra mají přístup ke všem funkcím informačního systému. • Management – management společnosti má přístup ke všem datům, ale pouze pro čtení. Hlavními uživateli systému budou operátorky call centra, které budou nejvíce využívat systém. Ve firemních procesech ještě vystupují další osoby, které pracují s daty z informačního systému, nemají však vlastní přístup do systému. Jsou to především technici, kteří k datům ze systému přistupují zprostředkovaně přes call centrum, které jim předá potřebné zakázkové listy pro provedení úkolu. Po provedení úkolu odevzdávají technici montážní listy zpět operátorkám call centra, které výkon zaevidují do systému. Další, kdo k datům v systému přistupuje zprostředkovaně pomocí jiné uživatelské role, jsou klienti společností, kterým výstupní data předává management společnosti v tištěné podobě či prostřednictvím emailu.
3.2
Požadavky na systém
Společnost, pro kterou je aplikace navržena, má na systém tyto požadavky.
Požadavky managementu jsou následující: • Evidovat zařízení, které jsou ve správě společnosti, s detailními informacemi o jejich umístění, typu, výkonu, stáří, atd. • Evidovat provedené práce v rámci smluv, tj. výjezdy k závadám na zařízení. • Poskytnout přehledy o provedených pracích na zařízeních. • Poskytnout přehledy požadované zákazníkem. • Tisk formulářů se zadáním práce pro technika.
11
3.2. POŽADAVKY NA SYSTÉM
Funkční požadavky Seznam funkčních požadavků, ze kterých následně sestavím jednotlivá use case, je následující: Sjednání kontraktu s novou firmou Ukončení spolupráce s firmou Zobrazení, filtrování a řazení seznamu firem Zaevidování potřebné firemní struktury Skrytí provozovny Zobrazení, filtrování a řazení firemní struktury Zaevidování spravovaného zařízení Skrytí zařízení Montáž nového zařízení Demontáž zařízení Reaktivace skrytého zařízení Úprava definice typu zařízení Vyřazení typu zařízení z evidence Reaktivace skrytého typu zařízení Změna iniciálů dodavatele Vyřazení dodavatele z evidence Reaktivace skrytého dodavatele Změna iniciálů partnera Vyřazení partnera z evidence Reaktivace skrytého partnera Oprava iniciálů výrobce Vyřazení výrobce z evidence Reaktivace skrytého výrobce Změna údajů o kontaktu Vyřazení kontaktu z evidence Odebrání kontaktu z provozovny Reaktivace skrytého kontaktu Úprava priority Vyřazení priority z evidence Reaktivace skryté priority Úprava provedení
Změna iniciálů firmy Vyřazení firmy z evidence Reaktivace skryté firmy Změna firemní struktury Vyřazení provozovny z evidence Reaktivace skryté provozovny Úprava zařízení Vyřazení zařízení z evidence Přesun zařízení Zobrazení, filtrování a řazení seznamu zařízení Přidání nového typu zařízení do systému Skrytí typu zařízení Zobrazení, filtrování a řazení seznamu typů zařízení Zaevidování nového dodavatele Skrytí dodavatele Zobrazení, filtrování a řazení seznamu dodavatelů Sjednání spolupráce s novým partnerem Ukončení spolupráce s partnerem Zobrazení, filtrování a řazení seznamu partnerů Zadání nového výrobce Skrytí výrobce Zobrazení, filtrování a řazení seznamu výrobců Přidání nového kontaktu a přiřazení k firmě nebo provozovně Skrytí kontaktu Odebrání kontaktu z firmy Zobrazení, filtrování a řazení adresáře kontaktů Přidání nové priority Skrytí priority při nepoužívání Zobrazení, filtrování a řazení seznamu priorit Přidání nového provedení Skrytí provedení
12
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Vyřazení provedení z evidence Reaktivace skrytého provedení Úprava označení sortimentu Vyřazení označení sortimentu z evidence Reaktivace skrytého označení sortimentu Změna přiřazení venkovní jednotky Zobrazení, filtrování a řazení seznamu venkovních jednotek Naplánování pravidelných servisů Přiřazení technika k plánu pravidelného servisu Zobrazení, filtrování a řazení plánů pravidelných servisů Zaevidování provedení pravidelného servisu Přiřazení zařízení k provedenému pravidelnému servisu Skrytí pravidelného servisu Zobrazení, filtrování a řazení seznamu provedených pravidelných servisů Vystavení výjezdu Ukončení výjezdu
Zobrazení, filtrování a řazení seznamu provedení Přidání nového označení sortimentu Skrytí označení sortimentu Zobrazení, filtrování a řazení seznamu sortimentu Přiřazení zařízení (venkovní jednotky) k zařízení (vnitřní jednotky) Odstranění přiřazení Reaktivace skryté venkovní jednotky Změna plánu pravidelných servisů Sestavení měsíčního výpisu pravidelných servisů Reaktivace skrytého plánu pravidelného servisu Přiřazení technika k provedenému pravidelnému servisu Změna pravidelného servisu Vyřazení pravidelného servisu z evidence Reaktivace skrytého pravidelného servisu Doplnění údajů k výjezdu Zobrazení, filtrování a řazení seznamu výjezdů Reaktivace skrytého výjezdu Změna údajů o technikovi Vyřazení technika z evidence Reaktivace skrytého technika Oprava dokladu Vyřazení dokladu z evidence Reaktivace skrytého dokladu Upravení poznámky Smazání poznámky Reaktivace skryté poznámky
Zobrazení neukončených výjezdů Zaevidování nového technika Skrytí technika Zobrazení, filtrování a řazení sezn. techniků Zaevidování dokladu Skrytí dokladu Zobrazení, filtrování a řazení sezn. dokladů Přidání poznámky k libovolnému záznamu Skrytí poznámky Zobrazení, filtrování a řazení seznamu poznámek u libovolného záznamu Přidání odkazu k libovolnému záznamu Upravení odkazu Skrytí odkazu Smazání odkazu Zobrazení, filtrování a řazení seznamu od- Reaktivace skrytého odkazu kazů u libovolného záznamu Tisk sestav Tabulka 3.1: Seznam funkčních požadavků.
3.3. DOSTUPNOST SYSTÉMU
13
Nefunkční požadavky Na informační systém jsou kladeny tyto nefunkční požadavky: • náročnost na HW – Serverová část IS musí být spustitelná na dnes běžně dostupných serverech v cenové dostupnosti do 100 tis Kč. Klientská část IS musí být spustitelná na dnešních kancelářských počítačích, noteboocích a netboocích. • rychlost – Systém musí nabízet efektivní práci s ohledem na druh připojení. • dostupnost – Požadavek na dostupnost systému je podrobněji rozepsána v kapitole 3.3 na straně 13. • přenositelnost – Klientská část musí být dostupná na různých dnes používaných platformách. • bezpečnost – Oblast bezpečnosti je podrobněji rozepsána v kapitole 3.4 na straně 13. • rozšiřitelnost – Již nyní je zapotřebí předpokládat, že systém se bude dále rozšiřovat. • stálost a platnost dat – Po uložení dat se předpokládá, že data zůstanou konzistentní a budou pro ně platit zadaná integritní omezení.
3.3
Dostupnost systému
Režim provozu IS je 24x7 s možností omezení v nočních hodinách, případně o víkendu. Z dlouhodobého hlediska je lépe zásahy do systému plánovat na období přelomu podzim zima, kdy nejsou klimatizační zařízení tolik namáhána, jako v letních měsících, a také není potřeba zpracovávat roční výsledky, jako je tomu začátkem nového roku. V případě výpadku systému jsou připraveny vytištěné formuláře pro zadání nového servisního výjezdu. Ostatní agenda lze odložit až na zprovoznění systému. Výpadek by však neměl být delší než několik dní.
3.4
Bezpečnost
Důležitým požadavkem na informační systém je bezpečnost. Tu je zapotřebí zajistit z několika pohledů: • Neoprávněná osoba se nesmí dostat do systému. • Přihlášený uživatel smí pracovat jen s přidělenými funkcemi. • Pokud uživatel delší dobu nepracuje se systémem, je automaticky odhlášen. • Server 1
1
musí být správně nakonfigurován a pravidelně aktualizován.
tj. operační systém, aplikační server, databázový server
14
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
• Musí být veden záznam o přístupech k systému. • Zálohování dat je nutností. • Hesla musí být dostatečně silná. • Pokud bude informační systém přístupný i z Internetu, je bezpodmínečně nutné přenos dat šifrovat. • Server musí být chráněn firewallem. Pokud je to možné, musí se omezit přístup jen na vybrané IP adresy.
3.4.1
Logování přístupu
K bezpečnosti systému patří i vědět, kdo se k němu připojuje (resp. pokouší připojit). Nebezpečí útoku se zvýší, pokud je počítačová síť připojena k Internetu či informační systém přímo komunikuje s klientem přes Internet. Základními otázkami jsou především: • kdo (pokud je přihlášen), • kdy, • odkud (tj. z jaké IP adresy), • kam se snaží dostat (tj. na jaké URI), • session ID (pro sjednocování jednotlivých relací). K logování přístupu lze využít služeb aplikačního serveru, který dokáže zaznamenávat příchozí požadavky. Jeho nastavení je popsáno v kapitole D.3.2 na straně 75.
3.4.2
Zálohování dat
Databáze se bude zálohovat při výměně služby v call centru. Toto je nastaveno z důvodu ochrany dat, jednak proti poškození databáze vnějšími podmínkami a jednak proti ochraně před omyly uživatelů, aby se dalo vrátit k předchozí směně a minimalizovaly se náklady na opravu dat, které mohou vzniknout neopatrností či počáteční neznalostí nového systému. Zálohování bude provádět plánovač úloh (resp. cron) v nastavených časech a ukládat zálohu pomocí příkazu pg_dump do souboru, který se zkomprimuje a zašifruje. Následně se uloží do adresáře na jiném disku (resp. počítači). Z bezpečnostních důvodů se doporučuje zálohovat data i na jiná zařízení, jako je např. CD, DVD-RAM či speciální magnetická pásková zařízení určená k zálohování. Doba držení zálohy je ponechána na firemní politice. Kromě dat uložených v databázi je dobré zazálohovat i konfigurační soubory aplikačního serveru a databázového serveru. Tato data není zapotřebí zálohovat v pravidelných intervalech, ale stačí provést zálohu při změně konfigurace.
3.5. DATOVÝ SLOVNÍK
3.5
15
Datový slovník
Ve společnosti, která se zabývá servisem klimatizačních zařízení se vyskytují různé pojmy, které jsou více či méně jasné. Uvádím zde proto datový slovník, ve kterém se nacházejí výrazy běžně používané v této oblasti a jsou také použity v informačním systému. firma Společnost (klient), která si objednala služby. Adresa uvedená u firmy je ta, na které má společnost sídlo. provozovna Představuje pobočku, provozovnu klienta. Adresa uvedená u provozovny představuje skutečné umístění zařízení k ní přiřazené. zařízení Klimatizační zařízení, mrazící zařízení, lednice, ... typ zařízení Označení typu zařízení. výrobce Výrobce daného zařízení. dodavatel Společnost, která dané zařízení instalovala. partner Obchodní partner, se kterým společnost spolupracuje při opravách. provedení Provedení daného zařízení, např. podstropní klimatizace, kazetová klimatizace, ... výrobní číslo Výrobní číslo zařízení. evidováno od Datum, od kdy je zařízení evidováno na provozovně. Může se lišit od data montáže. záruka do Datum, do kdy je zařízení v záruce. technik Osoba, která provádí servis zařízení. sortiment Další roztřídění typů zařízení. venkovní jednotka Venkovní část klimatizačního zařízení. vnitřní jednotka Vnitřní část klimatizačního zařízení. výkon, příkon, napětí, proud Technické údaje o zařízení. umístění Popis umístění zařízení na provozovně. středisko Zařazení zařízení v rámci provozovny. kód firmy Číselné označení firmy. Má tvar fff, kde f představuje číslici 0 − 9. kód provozovny Číselné označení provozovny. Má tvar fff–pppp, kde fff představuje kód firmy a pppp představuje označení v rámci firmy, p je číslice 0 − 9. kód zařízení Číselné označení zařízení. Má tvar fff–pppp-zzz, kde fff představuje kód firmy, pppp představuje kód provozovny a zzz představuje kód zařízení, z je číslice 0 − 9.
16
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
kód výjezdu Číselné označení výjezdu. Má tvar rrrr–fff–pppp–vvvv, kde rrrr představuje rok, fff kód firmy, pppp provozovnu a vvvv představuje číslo výjezdu, které je jedinečné v rámci fff, v je číslice 0 − 9. výjezd Servisní výjezd na konkrétní provozovnu, může představovat opravu jednoho či více zařízení. pravidelný servis Pravidelný servis představuje předem nasmlouvanou kontrolu a údržbu zařízení. montáž Připojení zařízení na provozovně. demontáž Odpojení zařízení na provozovně a její odvoz. přesun Přesun zařízení z jedné provozovny (resp. firmy) na jinou. priorita Důležitost provedení výjezdu, priorita je určena časy příjezdu a dokončení. maximální čas příjezdu Limit pro příjezd a zahájení práce na zařízení. Je určen prioritou výjezdu. maximální čas dokončení opravy Limit pro dokončení práce na zařízení. Do této doby musí být zařízení opravené či limit označen za přerušený. přerušení Přerušení výjezdu je z důvodu neopravitelnosti zařízení na místě. Je potřeba objednat náhradní díl, či odvést zařízení do dílny. reklamace Výjezd, který je proveden na reklamaci předchozího výjezdu. Podmínky reklamace se řídí reklamačním řádem. storno Zrušení výjezdu. ukončeno Ukončení servisního výjezdu. vystavil Jméno operátorky call centra, která výjezd vystavila. profese Specializace technika. nahlášená závada Popis nahlášené závady. zjištěná závada Popis zjištěné závady technikem. čas nahlášení Čas, kdy byla nahlášena závada. čas výjezdu Čas výjezdu technika k opravě na provozovnu. čas příjezdu Čas příjezdu technika na provozovnu. čas začátku práce Čas, kdy se začalo zařízení opravovat. čas přerušení Čas přerušení práce technika, většinou je to z důvodu nutnosti objednání náhradního dílu. čas dokončení Čas dokončení opravy zařízení.
17
3.6. USE CASE
kontakt Kontaktní údaje na osoby, spojené s firmou či provozovnou. doklad Doklady vztahující se např. k výjezdu, zařízení, ... poznámka Poznámka sloužící pro vnitřní potřebu call centra. odkaz Odkaz na soubor v informačním systému. Např. nahrávka nahlášené závady, odkaz na webové stránky výrobce, ...
3.6
Use case
Z funkčních požadavků jsem sestavil několik use case. Při sestavování jsem použil šablonu uvedenou v [17]. Zde uvádím nejdůležitější případy užití: Název Případ užití číslo Aktéři Popis
Vstupní podmínky Výstupní podmínky Běžná cesta
Vystavení výjezdu UC1 Operátorka call centra Klient volá ohledně chyby na zařízení, představí se a sdělí potřebné údaje o tomto zařízení, jako je kód zařízení a popis závady. Může se stát, že kód zařízení klient nezná, v takovém případě se operátorka orientuje podle popisu zařízení, tj. výrobce a provedení zařízení a popis umístění zařízení. Operátorka zadá požadované údaje do IS a uloží ho. Následně vytiskne výjezd a kontaktuje technika. Operátorka je přihlášena do IS. Výjezd je validní a uložen v databázi. 1. Operátorka v menu zvolí odkaz výjezd. 2. IS zobrazí seznam výjezdu a tlačítka s funkcemi. 3. Operátorka stiskne tlačítko pro zadání nového výjezdu Nový záznam. 4. IS zobrazí formulář pro zadání nového výjezdu. 5. Operátorka vybere firmu, pro kterou zadává výjezd. 6. IS načte filtrovaný výběr provozoven pro vybranou firmu do příslušné komponenty. 7. Operátorka vybere provozovnu, pro kterou zadává výjezd. 8. IS načte filtrovaný výběr zařízení pro vybranou provozovnu do příslušné komponenty. 9. Operátorka zadá či ponechá přednastavený rok. 10. Operátorka stiskne tlačítko pro přiřazení čísla výjezdu. (alternativa 10a1) 11. IS doplní volný kód výjezdu ze sekvence. 12. Operátorka zadá telefonní číslo, ze kterého je výjezd nahlašován. 13. Operátorka stiskne tlačítko pro zadání aktuálního času do pole čas nahlášení. (alternativa 13a1) 14. IS doplní aktuální čas podle serveru.
18
Alternativní cesta
Výjimky
Vložené příp. užití Priorita Četnost užití
Název Případ užití číslo Aktéři Popis
Vstupní podmínky Výstupní podmínky Běžná cesta
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
15. Operátorka vybere číslo reklamovaného výjezdu, pokud je tento výjezd reklamací. 16. Operátorka vybere techniky, kteří provedou servisní výjezd. 17. Operátorka vybere zařízení, která dostala nahlášená od klienta. 18. IS zobrazí detailní informace o vybraných zařízeních. 19. Operátorka stiskne tlačítko Zařízení – Výjezdní informace. 20. IS zobrazí podformulář. 21. Operátorka zadá nahlášenou závadu. 22. Operátorka vybere prioritu, kterou určila podle pravidel stanovených ve smlouvě o poskytování služeb. 23. Operátorka stiskne tlačítko OK nebo pokud je zařízení více, operátorka stiskne tlačítko Další a postupuje v UC od bodu č. 21. 24. IS skryje podformulář. 25. Operátorka uloží servisní výjezd stisknutím tlačítka Uložit. 26. IS provede validaci zadaných dat, uloží záznam do databáze a zobrazí hlášení Záznam byl vytvořen. 10a1. Operátorka zadá kód výjezdu ručně. (zpět hl. UC od 12.) 13a1. Operátorka zadá čas nahlášení ručně. (zpět hl. UC od 15.) 1. – 26. Operátorka má možnost ukončení UC tlačítkem Zpět či použitím odkazu v menu. 10v1. Operátorka zadala již existující kód výjezdu. .1. IS provede validaci a zobrazí chybové hlášení. .2. Operátorka opraví kód výjezdu podle kroku 10 resp. 10a1. 26v1. IS nalezl při validaci chybu. .1. IS zobrazí chybové hlášení. .2a. Operátorka opraví zadaná data. (zpět hl. UC od 25.) .2b. Operátorka přeruší zadávání výjezdu. Nejsou Vysoká Jednotky v průběhu dne, zvýšená četnost v letním období.
Sjednání kontraktu s novou firmou UC2 Operátorka call centra Management společnosti uzavře nový kontrakt a předá potřebné informace operátorkám call centra, které informace zaevidují do systému. Operátorka je přihlášena do IS. Záznam firma je validní a uložen v databázi. 1. Operátorka v menu zvolí odkaz firma. 2. IS zobrazí seznam firem a tlačítka s funkcemi. 3. Operátorka stiskne tlačítko pro zadání nové firmy Nový záznam.
3.6. USE CASE
Alternativní cesta Výjimky
Vložené příp. užití Priorita Četnost užití
Název Případ užití číslo Aktéři Popis
Vstupní podmínky Výstupní podmínky Běžná cesta
Alternativní cesta Výjimky
Vložené příp. užití Priorita Četnost užití
19
4. IS zobrazí formulář pro zadání nové firmy. 5. Operátorka zadá kód firmy, název firmy, ič, dič. 6. Operátorka zadá sídlo společnosti, tj. ulici, obec, psč a zemi. 7. Operátorka uloží firmu stisknutím tlačítka Uložit. 8. IS provede validaci zadaných dat, uloží záznam do databáze a zobrazí hlášení Záznam byl vytvořen. 1. – 8. Operátorka má možnost ukončení UC tlačítkem Zpět či použitím odkazu v menu. 8v1. IS nalezl při validaci chybu. .1. IS zobrazí chybové hlášení. .2a. Operátorka opraví zadaná data. (zpět hl. UC od 7.) .2b. Operátorka přeruší zadávání firmy. Nejsou Vysoká Jednotky v průběhu roku.
Změna iniciálů firmy UC3 Operátorka call centra Je zapotřebí změnit iniciály firmy. Buď opravit chybu nebo klient změnit své iniciály. Např. změna adresy sídla firmy, klient se stane plátcem nebo změní svůj název. Operátorka call centra na tyto skutečnosti reaguje úpravu v systému. Operátorka je přihlášena do IS. Provedené změny jsou validní a uloženy v databázi. 1. Operátorka v menu zvolí odkaz firma. 2. IS zobrazí seznam firem a tlačítka s funkcemi. 3. Operátorka klikne na řádek s firmou, kterou chce upravovat. 4. Operátorka stiskne tlačítko pro úpravu firmy Úprava záznamu. 5. IS zobrazí formulář pro úpravu firmy. 6. Operátorka změní požadované údaje. 7. Operátorka uloží změny stisknutím tlačítka Uložit. 8. IS provede validaci dat, uloží záznam do databáze a zobrazí hlášení Záznam byl upraven. 1. – 8. Operátorka má možnost ukončení UC tlačítkem Zpět či použitím odkazu v menu. 8v1. IS nalezl při validaci chybu. .1. IS zobrazí chybové hlášení. .2a. Operátorka opraví chybná data. (zpět hl. UC od 7.) .2b. Operátorka přeruší změnu iniciálů firmy. Nejsou Vysoká Jednotky v průběhu roku.
20
Název Případ užití číslo Aktéři Popis
Vstupní podmínky Výstupní podmínky Běžná cesta
Alternativní cesta Výjimky Vložené příp. užití Priorita Četnost užití
Název Případ užití číslo Aktéři Popis Vstupní podmínky Výstupní podmínky Běžná cesta
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Ukončení spolupráce s firmou UC4 Operátorka call centra Při ukončení spolupráce je zapotřebí ještě nějakou dobu evidovat data. Je však výhodné data skrýt, aby se již nenabízela v nabídkách, přehledech a nezapočítávala se do statistik. Operátorky call centra záznam o firmě skryjí a tím se skryjí i všechny záznamy související s částí systému zabývající se evidencí zařízení. Operátorka je přihlášena do IS. Příznak skrytí je uložen do databáze. 1. Operátorka v menu zvolí odkaz firma. 2. IS zobrazí seznam firem a tlačítka s funkcemi. 3. Operátorka klikne na řádek s firmou, kterou chce skrýt. 4. Operátorka stiskne tlačítko pro skrytí firmy Skrýt. 5. IS provede skrytí firmy a k ní příslušných agend. 6. IS zobrazí hlášení Záznam byl skryt. 1. – 4. Operátorka má možnost ukončení UC použitím odkazu v menu. Nejsou Nejsou Vysoká Jednotky v průběhu roku.
Přidání poznámky k zařízení UC5 Operátorka call centra Operátorky mají možnost psát k libovolné entitě neomezené množství poznámek libovolného druhu. Operátorka je přihlášena do IS. Poznámka je validní a uložena v databázi. 1. Operátorka v menu zvolí odkaz zařízení. 2. IS zobrazí seznam zařízení a tlačítka s funkcemi. 3. Operátorka klikne na řádek se zařízením, ke kterému chce přidat poznámku. 4. Operátorka stiskne tlačítko pro zobrazení seznamu poznámek Seznam poznámek. 5. IS zobrazí seznam poznámek patřících k vybranému zařízení a tlačítka s funkcemi. 6. Operátorka stiskne tlačítko Nový záznam. 7. IS zobrazí formulář pro zadání nové poznámky. 8. Operátorka vyplní nadpis a tělo poznámky.
3.7. VOLBA NÁSTROJŮ PRO IMPLEMENTACI
Alternativní cesta Výjimky
Vložené příp. užití Priorita Četnost užití
3.7 3.7.1
21
9. Operátorka uloží poznámku stisknutím tlačítka Uložit. 10. IS provede validaci dat, uloží poznámku do databáze a zobrazí seznam zařízení. 1. – 10. Operátorka má možnost ukončení UC tlačítkem OK umístěném ve formuláři seznamu poznámek. 10v1. IS nalezl při validaci chybu. .1. IS zobrazí chybové hlášení. .2a. Operátorka opraví chybná data. (zpět hl. UC od 9.) .2b. Operátorka přeruší zadávání poznámky. Nejsou Vysoká Velmi časté použití.
Volba nástrojů pro implementaci Volba programovacího jazyka
Prvním rozhodnutím pro volbu realizace návrhu informačního systému je pro mě volba programovacího jazyka. Na výběr mám několik možností: • Použít databázi MS Access a k němu programovací jazyk VBA (Visual Basic for Application); • PHP; • Java; • C++; • C#; Programovací jazyky C++ a C# s použitím .Net technologií společnosti Microsoft by mohl být zajímavou volbou. I když programovací jazyk C++ ovládám, musím tyto jazyky zavrhnout z důvodu, že s technologií .Net jsem ještě nepracoval a nejsem s ní seznámen na takové úrovni, abych mohl vytvořit takto komplexní informační systém. Využít již známou databázi MS Access s programovacím jazykem VBA jsem zčásti zvažoval. Hlavní výhodou bylo to, že operátorky call centra již znaly tuto databázi. Bylo tu však několik omezení. Ve zkratce uvedu jen některé – nutnost mít balík MS Office ve vyšší verzi právě s databází MS Access, nemožnost přístupu přes Internet (kromě VPN připojení), automatické odesílání emailů, poškození otevřeného databázového souboru při výpadku napájení2 , transakce, komunikace s jinými podnikovými systémy. Z těchto důvodů tuto variantu zamítám. Databázový soubor byl umístěn na serveru a otevřen na pracovní stanici. Při výpadku napájení sice byly server a prac. stanice zajištěny UPS, nikoliv však všechny switche, které je propojovaly. 2
22
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Programovací jazyk PHP je velmi rozšířen pro vytváření dynamických webových stránek. Je nezávislý na platformě a umožňuje přístup k mnoha databázím. Existuje pro něj mnoho knihoven a frameworků. Mohu konstatovat, že tento programovací jazyk ovládám a mám znalosti k vytvoření informačního systému v tomto programovacím jazyce. PHP je jednou z mých reálných možností pro volbu programovacího jazyka. Programovací jazyk Java je rozšířen v mnoha variantách na různé platformy od mobilních telefonu (Java ME), desktopových počítačů (Java SE) až po enterprise řešení pro servery (Java EE). Je nezávislý na použitém operačním systému. Umožňuje přístup k mnoha databázím. Existuje pro něj mnoho knihoven a frameworků. S tímto jazykem jsem se setkal až na vysoké škole, kde jsem se nejprve naučil základy v průběhu bakalářského studia. Na magisterském studiu jsem se seznámil s Java EE v předmětu X33EJA Enterprise Java. Java EE je další z mých reálných možností pro volbu programovacího jazyka. Namísto Java EE spolu s EJB 3.0, existuje také možnost použít Javu spolu s některým z frameworků jako je např. Spring, Struct a další. Při rozhodování mezi PHP, Spring a Java EE, jsem se rozhodl pro Java EE. Přesvědčili mě především technologie, které Java EE nabízí: • JPA, které zabezpečí ORM pro mnoho databází. Informační systém půjde nasadit na mnoho databází a ve většině případů pouhou změnou několika konfiguračních souborů. • JPA zajistí mapování děděných entit do databáze • JTA zabezpečí transakce • používá se principu Configuration by Exception3 .
3.7.2
Volba vývojového prostředí
Vývojové prostředí pomáhá programátorovi s vývojem aplikace. Mělo by obsahovat funkce usnadňující vývoj, kompilaci, deploy, ladění aplikací a také podporu pro systém správy verzí. Mezi dnes nejznámější vývojová prostředí pro programovací jazyk Java patří: • NetBeans • Eclipse • IntelliJ IDEA Z licenčního hlediska je IntelliJ IDEA komerční vývojové prostředí, naopak NetBeans je šířen pod dualní licencí CDDL a GNU GPL v2. Eclipse je šířen pod licencí Eclipse Public License (EPL). Dobré vývojové prostředí by mělo obsahovat funkce jako je: kontrola syntaxe, Deploy on Save, Intelli Sence, Code Completion, Palette, Code Generation, Debugger a další. Tyto vyjmenované funkce lze považovat za standard a všechny výše vyjmenovaná vývojová prostředí je obsahují. 3 Tento princip znamená, že pokud se třída jmenuje Firma, předpokládá se, že tabulka se bude jmenovat firma. Pokud tomu tak skutečně je, není zapotřebí tuto skutečnost v kódu označovat. Pokud se však tabulka jmenuje jinak, je zapotřebí tuto skutečnost uvést.
3.7. VOLBA NÁSTROJŮ PRO IMPLEMENTACI
23
Kromě těchto obecných funkcí očekávám od vývojového prostředí i specifické funkce určené pro vývoj aplikací v Java EE. Těmito funkcemi jsou například: podpora EJB, JPA, JSF a dalších knihoven, jako je Richfaces, Facelets. Dalšími funkcemi, které bych rád nalezl ve vývojovém prostředí je podpora pro html, css, javascript. Všechny tyto funkce a mnoho dalších obsahují všechna tři vývojová prostředí. Dospěl jsem k názoru, že všechna zmiňovaná vývojová prostředí jsou si rovna. A že záleží na osobních sympatiích a preferencích, které kdo zvolí. Názor, že všechna zmiňovaná prostředí mají stejnou nebo podobnou funkční výbavu a že pokud jedno vývojové prostředí bude mít nějakou novinku, tak se dá očekávat v brzké době i u ostatních, zaznělo i na nahrávce na webové stránce [7]. Já jsem se rozhodl pro NetBeans, které má všechny potřebné funkce a již jsem ho využíval.
3.7.3
Volba aplikačního serveru a frameworků
Nejprve se zmíním, co je a k čemu slouží aplikační server. V článku [8] na serveru root.cz uvádějí: „Aplikační server tvoří vrstvu mezi operačním systémem a aplikacemi. Podobně, jako operační systém poskytuje základní funkce programům (například pro přístup k souborovému systému, nebo ke správě procesů), poskytuje aplikační server často používané funkce enterprise aplikacím. Vytváří další vrstvu abstrakce, aby bylo psaní aplikací jednodušší. Příkladem takových funkcí mohou být podpora transakčního zpracování požadavků, persistence objektů do databáze, výměna zpráv mezi aplikacemi a další. Nabízí se samozřejmě otázka, co to vlastně je enterprise aplikace a jak se liší od běžné aplikace. Není to nic složitého, de facto se jedná o běžnou aplikaci, na kterou jsou kladeny určité nároky co se týče spolehlivosti, dostupnosti, robustnosti, výkonnosti. Typická je také potřeba obsloužit současně velké množství požadavků (klientů). Klasickými zástupci enterprise aplikací jsou moderní webové aplikace a řešení postavená na servisně orientované architektuře (SOA).“ „Většina aplikačních serverů je vyvíjena v programovacím jazyce Java. Není to jenom tím, že Java je nezávislá na platformě, ale také tím, že existuje standard pro implementaci enterprise aplikací právě v jazyce Java. Tento standard se nazývá Java Enterprise Edition (JEE). Pokud bychom hledali paralelu se světem operačních systémů, mohli bychom zmínit standard POSIX.“ Pro běh aplikací napsaných v Java EE se používá aplikační server. Nabídek pro volbu je zde opět několik a stejně jako u vývojového prostředí se zde dají rozdělit na ty s komerční licencí a na ostatní, které se většinou nazývají komunitní. Jednou z možností je použít microcontainer Apache Tomcat a s ním některý z frameworků jako je Spring. Tuto variantu jsem však již vyloučil výše. Další z možností je namísto pouhého microcontaineru použít plnohodnotný aplikační server, kde microcontainer je jen jednou částí. Dále zabezpečují např. tyto funkčnosti: bezpečnost, transakční zpracování, sdílení zdrojů, synchronizovaný přístup ke komponentám, podporu persistence, distribuované aplikace, škálovatelnost. Podrobněji viz. [18]. Takovýmito aplikačními servery jsou například opensource:
24
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
• Glassfish • JBoss • Apache Geronimo • JonAS nebo komerční: • Sun Java AS • IBM WebSphere • BEA WebLogic Pro diplomovou práci si vybírám z freewarových resp. opensource variant. Glassfish a JBoss patří mezi nejznámější z opensource variant. Glassfish jsem se naučil používat v rámci předmětu X33EJA – Enterprise Java, kde probíhala výuka právě na kombinaci vývojového prostředí NetBeans a aplikačního serveru Glassfish. S aplikačním serverem JBoss jsem se seznámil pouze okrajově z několika článků na serveru root.cz a také jsem se stal členem skupiny JBoss User Group. Větší zkušenost mám právě s aplikačním serverem Glassfish, který obsahuje všechny potřebné komponenty pro tento informační systém. Jako jsou již dříve zmiňované funkce: bezpečnosti, transakční zpracování, sdílení zdrojů, synchronizovaný přístup ke komponentám, podporu persistence. A dále pak Java Mail a Web Services. Rád bych také dodal, že můj výběr programovacího jazyka, vývojového prostředí a aplikačního systému spolu s frameworky byl ovlivněn jejich provázaností. Většina z nich je totiž od stejné společnosti a tak se dá předpokládat dobrá spolupráce těchto nástrojů.
3.7.4
Volba databáze
Výběr databáze musím omezit na podporu vybrané specifikace JPA v implementaci zvoleného TopLink Essentials od společnosti Oracle. Toto omezení není až tak omezující, neboť TopLink JPA podporuje současné nejznámější databáze. Seznam podporovaných databází je uveden v [15], zde uvedu jen zkrácený výčet: • DB2 • DBase • Derby • HSQL • Informix • JavaDB • MySQL4
3.8. SOUHRN POUŽITÝCH PROSTŘEDÍ A TECHNOLOGIÍ
25
• Oracle • PostgreSQL • SQLServer • Sybase Vzhledem k tomu, že specifikace JPA umožňuje snadný přechod mezi databázemi. Výběr vývojové a testovací databáze tak důležitý. V případě nasazení informačního systému ve společnosti, bude hrát roli též cena licence. Zvažoval jsem použití MySQL, Oracle, PostgreSQL a SQLServer. Rozhodl jsem se pro PostgreSQL z následujících důvodu: • všechny 4 databáze mohu jako student použít, • MySQL a PostgreSQL zaberou méně místa po instalaci, • PostgreSQL má více možnosti než MySQL, • databázi PostgreSQL jsem dosud nepoužíval a rozhodl jsem se ji vyzkoušet.
3.8
Souhrn použitých prostředí a technologií
• NetBeans 6.8 (dříve 6.7.1) • Glassfish 2.1 (dříve 2.0) • EJB 3.0 (JPA, JTA) • JSF 1.2 • Richfaces 3.3.2.SR1 • PostgreSQL 8.4 (s pozdějšími aktualizacemi) • CVSNT 2.5.03.2382 • Mozilla Firefox 3.6.3 – Jako výchozí webový prohlížeč
3.9
Návrh databáze – vždy platné záznamy o výjezdu
V návrhu, který je zobrazen na obrázku 3.1 na straně 26, jsou informace o výjezdu asociovány s údaji v tabulce zařízení. V průběhu užívání tohoto systému však může dojít ke změně různých dat o tomto zařízení. Může jím být přesun zařízení, ať již pouhé přesunutí v rámci provozovny či přesun do jiné provozovny, či například změna parametrů zařízení. Pokud bych použil tento návrh a nastal by následující scénář, v informačním systému by tím byly nepravdivé údaje. 1. Zařízení je evidováno v IS
26
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.1: Class diagram – Prvotní návrh.
2. Na zařízení byl vystaven výjezd 3. Zařízení bylo přesunuto 4. Nyní je záznam o výjezdu nepravdivý, protože říká, že zařízení bylo opravováno jinde – na novém místě určení. Pro tento problém jsem vymyslel několik variant úprav datového modelu.
3.9.1
Zachování veškerých údajů s datem platnosti
První myšlenka směřovala na přidání údajů o platnosti záznamu do všech tabulek a vytvoření dalších asociačních tabulek s údaji o platnosti asociace. Přidání záznamu by pak znamenalo provést uložení informací do tabulek a přidat k nim datum pořízení záznamu, což je podobné původnímu návrhu.
3.9. NÁVRH DATABÁZE – VŽDY PLATNÉ ZÁZNAMY O VÝJEZDU
27
Změna záznamu by však neznamenala provedení příkazu update nad záznamem, nýbrž vytvoření nového záznamu s aktuální platností a u původního záznamu by se změnil pouze datum platnosti.
3.9.2
Export výjezdů z databáze
Dalším možným způsobem, jak mít možnost vytisknout výjezd zpětně, je mít ho uložen mimo tyto relace. Nabízí se možnost exportu vyplněného výjezdového formuláře do pdf souboru, kde na něj nebudou mít vliv jakékoliv změny v databázi. Tím se však ztratí možnost jednoduše nakládat s uloženými daty a dále je zpracovávat a analyzovat, vyjma tisku. Lepší možností je data uložit do dokumentu xml, ve kterém jsou data strukturovaná a dají se jednoduše znovu strojově přečíst bez ztráty významu informace. Potřebný tisk by se dal realizovat zpracováním xml souboru pomocí XSLT Transformace a kaskádových stylů.
3.9.3
Pohled na systém jako na dva hlavní požadavky
Po zamyšlení se nad požadavky na systém jsem došel k názoru, že se snažím spojit dva problémy do jednoho. Prvním požadavkem na systém je evidovat spravovaný majetek. Vědět o kolik zařízení se firma stará, kdy je potřeba provést pravidelné servisy a také hlavně kam mají technici přijet na opravu. Druhým požadavkem na systém je evidovat opravy zařízení. Že naplánovaný pravidelný servis byl skutečně proveden, že pokud bylo zařízení opravováno v rámci výjezdu splňuje požadovanou prioritu, atd. Jinými slovy musí uchovat veškeré potřebné informace o provedené práci. Pro splnění druhého požadavku je bezpodmínečně nutné mít informace svázány k době, kdy se událost stala a např. přestěhování zařízení nesmí mít na ně vliv – výjezdový protokol musí zůstat zachován. Pro první požadavek není nutné evidovat historii změn pro každý údaj.
3.9.4
Zhodnocení variant návrhu
Varianta Export je spíše únikem od problému a dá se jím řešit především již hotový systém, který není schopen tento požadavek snáze zapracovat. Varianta Zachování veškerých údajů řeší tento požadavek, ale zároveň se tímto způsobem bude zaznamenávat spousta dat, která nejsou potřeba a výrazně by se tím stal kód IS složitějším. Varianta Dvou hlavních požadavků rozdělila systém na dynamickou část, kde se sleduje aktuální stav spravovaných zařízení, a na druhou (statickou) část, kde se aktuální změna údaje nesmí promítnout zpětně. Tuto variantu jsem zvolil a také implementoval. Výsledný model je uveden v příloze B na straně 57. K této variantě, vyhodnocené jako nejlepší, přidám ještě vlastnost skrytí záznamu namísto jeho smazání. To slouží ke skrytí záznamů, které se již nemají zobrazovat ve statistikách a nabízet se uživatelům k používání. Přestože se skryté záznamy již nebudou používat, je zapotřebí jejich archivace.
28
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Kapitola 4
Realizace V této kapitole popíši strukturu kódu informačního systému a zaměřím se na zajímavé části programu. Volba nástrojů a jejich zdůvodnění je uvedena v předchozí kapitole 3.7 na straně 21.
4.1
Struktura aplikace
Aby byl kód přehledný, rozdělují se jednotlivé třídy do balíčků (package). V této kapitole uvedu, jak jsem rozdělil IS. Celý projekt informačního systému se nazývá AirManager s názvem package cz.vlk.airmanager. Projekt je rozdělen do dvou modulů. Prvním je EJB Module s název AirManager-ejb, který obsahuje aplikační a databázovou vrstvu. Druhým je Web Application Module s názvem AirManager-war, který obsahuje prezentační vrstvu.
4.1.1
EJB Module
Na obrázku 4.1 je vidět package diagram znázorňující uspořádání tříd. Obsah jednotlivých package jsem popsal v následujícím přehledu: cz.vlk.airmanager.bean obsahuje třídy EJB představující aplikační vrstvu IS. cz.vlk.airmanager.dto obsahuje třídy, které slouží k přenosu dat mezi aplikační a prezentační vrstvou a nejsou to objekty představující persistentní entity. cz.vlk.airmanager.entity obsahuje třídy představující entity s anotacemi pro objektově relační mapování technologie JPA. Kromě persistence jsem také třídy použil k předávání dat mezi aplikační a prezentační vrstvou. Jinými slovy jsou to objekty tzv. Domain vrstvy. cz.vlk.airmanager.exception obsahuje sadu výjimek používaných v kódu. Především jsou používány v komunikaci mezi aplikační a prezentační vrstvou. cz.vlk.airmanager.sql obsahuje třídy odpovědné za sestavení JPQL dotazů.
29
30
KAPITOLA 4. REALIZACE
cz.vlk.airmanager.util obsahuje pomocné třídy, např. pro práci s časem. cz.vlk.airmanager.valid obsahuje třídy starající se o validaci dat.
Obrázek 4.1: Package diagram představující obsah EJB Module.
4.1.2
Web Application Module
cz.vlk.airmanager.back obsahuje Backing Bean (neboli Managed Bean) představující Controller z MVC. cz.vlk.airmanager.messages obsahuje properties soubory s překladem. cz.vlk.airmanager.setting obsahuje properties soubory s nastavením vlastností komponent
Obrázek 4.2: Package diagram představující obsah Web Application Module.
4.2. DATOVÝ MODEL
31
cz.vlk.airmanager.url obsahuje properties soubory s url adresami používanými v IS. Struktura xhtml a css souborů, které představují View z modelu MVC, je následující: • web – obsahuje veřejné soubory, jako jsou např. úvodní a přihlašovací stránka • WEB-INF – obsahuje konfigurační xml soubory a některé knihovny • css – obsahuje kaskádové styly pro vzhled veřejné části • pri – privátní (neveřejná) část, obsahuje hlavní xhtml soubory, do kterých se vkládají šablony a další prvky • comp – obsahuje xhtml soubory s prezentačními prvky, které se doplňují do šablon a jsou používány ze souboru ve složce pri • css – obsahuje kaskádové styly pro vzhled neveřejné části • print – obsahuje xhtml soubory tiskových sestav • template – obsahuje šablony
4.2
Datový model
Z analýzy jsem sestavil datový model. Specifika návrhu jsem popsal v kapitole 3.9 na straně 25. Kde jsem popisoval návrh datového modelu, který dokáže zachovat platný záznam o výjezdu i při změně údajů o zařízení. Další specifika, která jsou vidět v datovém modelu je použití dědičnosti. Dědičnost jsem použil z důvodu generalizace všech entit pod společnou entitu PersistObj. Díky tomu lze ke každému záznamu libovolné entity přidat poznámky nebo odkazy. Dědičnost v datovém modelu jsem použil i pro generalizaci entit Firma, Partner, Dodavatel, Vyrobce. Společného předka jsem nazval Spolecnost. Dědičnost entit je znázorněna pomocí class diagramu B.1 na straně 57. Tento i další modely jsou umístěny v příloze B na straně 57. Další informace o datovém modelu jsem umístil do tabulek v příloze C na straně 61.
4.3
Použité datové typy
V rámci návrhu je zapotřebí si ujasnit jaké datové typy jsou zapotřebí. Také je zapotřebí určit provázanost datových typů použitých v prostředí Javy a v prostředí databáze. Při sestavení následující tabulky 4.1 jsem použil přehled datových typu uvedených v knize [3].
4.4
Požité principy a návrhové vzory
S návrhovými vzory jsem se detailněji seznámil v knize [5], kde se píše:
32
KAPITOLA 4. REALIZACE Java String Integer Boolean Date Float Double
PostgreSQL varchar(n), char(n), text numeric(8), integer boolean timestamp float4 float
Tabulka 4.1: Použité datové typy
„Příchod návrhových vzorů odstartoval ve světě programování opravdovou revoluci. Jejich koncepce totiž nabídla způsob, jak usnadnit řešení mnohých typických programátorských problémů. V současné době se znalost návrhových vzorů stává povinnou součástí kvalifikace programátora.“ Proto se domnívám, že bych se zde měl zmínit o návrhových vzorech a principech, které jsem při realizaci informačního systému použil.
4.4.1
Inversion of Control a Dependency Injection
Na internetových stránkách [6] jsou tyto technologie popsány takto: „Inversion of Control (IoC) je návrhový vzor, který přesouvá nutnost získání a inicializace závislostí (objektů) mimo rozsah objektu, který je využívá. Vlastní závislost je nastavena z vnějšku (Dependency Injection).“ „V případě IoC je vázající kód vytažen ven z objektu. Někdo třetí se stará o to, aby se do objektu A dostala v pravou chvíli zinicializovaná instance objektu B. Objekt B je do objektu A nastaven například settrem nebo přes konstruktor, této formě IoC se říká Dependency Injection (injekce závislosti).“ Jelikož Dependency Injection je jednou z klíčových vlastností implementovaných v JEE 5, i já tuto technologii v kódu hojně využívám. Používám především formu anotací, ale pokud bude zapotřebí při reálném nasazení upravit některé Dependency Injection je možné anotace v kódu přepsat pomocí xml souboru.
4.4.2
Model View Controller
V knize [5] je tento návrhový vzor definován takto: „MVC (Model/View/Controller) sestává ze tří druhů objektů. Model představuje objekt aplikace, View prezentaci na obrazovce a Controller definuje způsob, jak uživatelské rozhraní reaguje na vstup od uživatele. MVC odděluje tyto objekty a tím zvyšuje flexibilitu a znovupoužitelnost celého řešení.“
4.4. POŽITÉ PRINCIPY A NÁVRHOVÉ VZORY
33
Podle [5], návrhový vzor MVC je zmíněn v GoF, ale nepatří mezi vzory oficiálně uvedené v GoF. Celý informační systém tento vzor dodržuje. Model představuje podprojekt EJB Modul. View a Controller jsem použil v podprojektu WAR Modul. Detailněji jsem se o tomto zmínil v kapitole 4.1 na straně 29.
4.4.3
Šablonovací systém
Toto není návrhový vzor, ale doporučená technologie vývoje webových aplikací. Je založena na principu vytvoření šablony vzhledu a funkčních komponent, které jsou do šablony vkládány. Vzhled systému je tak oddělen od komponent, což přináší tyto výhody: • redukce redundantního kódu vzhledu, • změna vzhledu se provede pouze na jednom místě, • přispívá k zpřehlednění kódu. Jako šablonovací systém jsem použil framework Facelets. Na následujících řádcích uvádím ukázku použití tohoto šablonovacího systému. layout.xhtml ...
... použití šablony ... ...
34
KAPITOLA 4. REALIZACE
...
4.4.4
Multilanguage
Pod tímto názvem se skrývá vytažení textů z kódu do samostatných souborů. V každém souboru je pak jedna jazyková mutace. Do kódu programu se pak vkládá zástupný kódový řetězec. Tento kódový řetězec je za běhu nahrazen konkrétním slovním spojením podle zvoleného jazyka. Tento princip jsem také použil pro vložení textů, které může být zapotřebí změnit až při nasazování informačního systému. Jako je např. název společnosti, která IS používá, její adresa, nastavení vlastností některých komponent GUI.
4.4.5
Java Persistence API
Další zajímavou technologií, kterou jsem použil a stojí za zmínku, je technologie JPA. Použil jsem implementaci technologie JPA s názvem TopLink Essentials od společnosti Oracle. Ta zajišťuje objektově relační mapování (ORM) objektů z aplikační logiky do databáze. Z vlastností JPA jsem použil tyto nástroje: transakce (JTA), lazy loading, hierarchické dědění z hlavní entity PersistObj. Hierarchii dědění entit jsem znázornil pomocí class diagramu B.1 na straně 57. Pro splnění požadavku na přiřazení poznámky, odkazu a dokladu ke každé entitě, bylo zapotřebí vytvořit společného předka, který bude v relaci s poznámkou, resp. odkazem, resp. dokladem. Tento vztah je znázorněn class diagramem B.2 na straně 58. V rámci technologií JTA a EJB jsou všechny metody Session Bean automaticky v transakcích.
4.4.6
Návrhový vzor Template Metod
Charakteristika návrhový vzor Template Metod je v knize [5] popsána takto: „Definuje kostru algorimu v operaci delegujíc některé kroky na podtídy. Template Metod umožňuje podtřídám pozměnit některé kroky algoritmu, aniž by měnila jeho strukturu.“ Tento návrhový vzor jsem použil při implementaci JSF Managed Bean prezentační vrstvy. Rodič je v tomto případě třída ManagedBean a potomky jsou jednotlivé managed beany představující Controllery z MVC. Návrhový vzor Template Metod jsem použil i při realizaci sestavení JPQL dotazů z filtru. Kde základní algoritmus je definován jako final metody.
4.4. POŽITÉ PRINCIPY A NÁVRHOVÉ VZORY
35
Stejný postup jsem chtěl realizovat i u Session Bean, ale Session Beanám není dovoleno dědit. Když jsem se o to pokusil, kontrola syntaxe NetBeans to označila za chybu.
4.4.7
Návrhový vzor Command
Charakteristika návrhový vzor Command je v knize [5] popsána takto: „Zapouzdří požadavek jako objekt, čímž umožní parametrizovat klienty s různými požadavky, vytvářet fronty a záznamy požadavků a podporovat odvolatelné operace.“ Návrhový vzor Command jsem použil pro definování vlastností jednotlivých parametrů sestavení vnitřní reprezentace JPQL dotazu, jak je ukázáno na příkladu: ... ISql isql; isql = new ISql() { @Override public String getFiltrName() { return "kodFirmy"; } @Override public List<String> getFromClausule() { List<String> l = new ArrayList<String>(); l.add("Zarizeni zarizeni"); l.add("zarizeni.provozovnaId provozovna"); l.add("provozovna.firmaId firma"); return l; } @Override public String getWhereClausuleA() { return "firma.kodFirmy"; } @Override public String getWhereClausuleV() { return "kodFirmy"; } }; variantyFiltru.put(isql.getFiltrName(), isql); ... Ukázka představuje uložení jedné sady příkazů (Command) pro realizaci dotazu vyhledej všechna zařízení, která patří firmě s označením kodFirmy == ???
Data zadaná ve formuláři se validují hned po opuštění zadávacího pole. Pomocí technologie AJAX se zaslán požadavek na kontrolu validace. Tu přijme třída představující Controller z MVC a předá požadavek Modelu. Ten data zkontroluje a pokud data nejsou validní vyvolá výjimku. Výjimka je v Controlleru zachycena a zpracována do příslušné zprávy, která se zobrazí vedle zadávacího pole. Kontrolu povinnosti vyplnění provádí automaticky samotná komponenta. To zda musí být komponenta vyplněna či nikoliv se definuje přímo v tagu:
38
KAPITOLA 4. REALIZACE
Při odesílání formuláře se opět provede validace dat.
4.7
Návrh a implementace filtru
Nepostradatelnou funkcí každého informačního systému je možnost filtrovat a řadit data. Proto ani v mém systému nesmí chybět možnost filtrovat a řadit data podle požadovaných atributů. Jednou z možností, jak zrealizovat obě tyto funkce, je přenechat je na použité komponentě scrollableDataTable z knihovny Richfaces. K implementaci jsem použil příklad uvedený v [11] ukazující použití komponenty scrollableDataTable. Implementovaná komponenta představovala základní funkčnost řazení a filtrování. Problém tohoto řešení se ukázal až později, kdy jsem do databáze umístil více záznamů (cca. stovky). Řazení a filtrování se provádělo v této komponentě za přispění metod v ManagedBean JSF. To znamená, že komponenta požádala business vrstvu o všechny záznamy a teprve nad nimi začala provádět požadované operace. Toto vedlo ke značnému zpoždění. Z těchto důvodů a také z možnosti budoucího rozšíření filtru o více funkcí jsem navrhl jiný systém řazení a filtrování dat. Vytvořil jsem samostatný formulář, pomocí kterého se nastavuje řazení a filtrování. Tato data jsou předána business vrstvě, kde je vytvořen JPQL dotaz. Tento dotaz je předán EntityManageru, který se postará o sestavení sql dotazu pro danou databázi, v mém případě je vytvořen dotaz do PostgreSQL databáze. Výsledek dotazu je předán do aplikační vrstvy, která ho předá do prezentační vrstvy. Následně je aktualizováno zobrazení komponenty. Tento postup je zobrazen v sekvenčním diagramu na obrázku 4.3 na straně 39. Tím, že filtrování a řazení je přenecháno na databázi, která má pro tyto úkoly lepší předpoklady, načtení dat se stalo rychlejší. Zároveň se snížila i paměťová náročnost, protože aplikační server si nemusí alokovat tolik dat a pracovat nad nimi. Dalším přenosem dat, který musím brát v úvahu je přenos z aplikačního serveru na klienta. Tato komunikace je nejužším místem. Je to z toho důvodu, že databázový server a aplikační server jsou v jedné lokální síti, která má dnes většinou 100 Mbit/s, v některých případech se jedná i o gigabitové připojení, či jsou oba servery na jednom fyzickém serveru. Navíc, aby se nemuselo pro každý dotaz z aplikačního serveru do databázového serveru sestavovat nové spojení, je použit tzv. pool připojení. To znamená, že po ukončení dotazu není spojení z aplikačního do databázového serveru ukončeno, ale je ponecháno otevřené pro pozdější použití. Propustnost dat je mezi aplikačním a databázovým serverem vyšší než propustnost mezi aplikačním serverem a klientem. Komunikace může probíhat buď po lokální síti anebo přes Internet. V takovém případě je spojení výrazně pomalejší a to především pokud je například klient připojen bezdrátově, například pomocí notebooku připojeného pomocí mobilního operátora. Právě kvůli těmto omezením není dobré přenášet všechna data, ale zobrazovat je po částech. V tomto směru je také výhodné použít již výše zmiňovanou komponentu scrollableDataTable z knihovny Richfaces, protože nepřenáší veškerá data ze serveru na klienta, ale
4.8. IMPLEMENTACE POZNÁMEK A URI
39
Obrázek 4.3: Sekvenční diagram znázorňující spolupráci objektů při použití filtru záznamů.
pouze předem stanovený počet záznamů. Pokud je zapotřebí další „stránka“ záznamů jsou záznamy načteny pomocí technologie AJAX.
4.7.1
Konverze datových typů
Je zapotřebí ke správnému fungování JPA komponent. V opačném případě je vyvolána výjimka: java.lang.IllegalArgumentException: You have attempted to set a value of type class java.lang.String for parameter pobjId with expected type of class java.lang.Integer from query string SELECT poznamka FROM Poznamka poznamka JOIN poznamka.persistObjId pobj WHERE pobj.id = :pobjId.
4.8
Implementace poznámek a URI
1. Vytvoření filtru tj. třídy UriSql, PoznamkaSql 2. Vytvoření Session bean tj. třídy UriBean, UriLocal, PoznamkaBean, PoznamkaLocal
40
KAPITOLA 4. REALIZACE
3. Vytvoření Managed bean tj. třídy UriMBean, PoznamkaMBean 4. Zaregistrovat Managed bean do faces-config.xml 5. Vytvoření vzhledu tj. soubory uri.xhtml, poznamka.xhtml v adresáři template 6. Propojení funkčních komponent použitých v souborech uri.xhtml a poznamka.xhtml s Managed bean metodama. Takto jsem vytvořil modální okna, ve kterých se budou zobrazovat formuláře pracující s uri a poznámkami. Nyní musím tyto prvky napojit na všechny formuláře, kde se budou používat. To provedu následujícím poustupem: 1. Připojení souborů pomocí tagu do souborů XxxList.xhtml, kde Xxx představuje název Entity. 2. Přidání medoty actShowPoznamkaList() a actShowUriList() v každé Managed bean business objektu, v této metodě se určí vybraný záznam, ke kterému se bude vztahovat poznámka resp. uri. 3. Jako poslední je zapotřebí přidat tlačítka , která budou vyvolávat zobrazení modálního okna.
4.9
Potvrzení úspěšnosti akce
Při naplánované schůzce s operátorkami call centra jsem jim představil prototyp informačního systému. Na něm jsem jim ukázal, jaké jsou použity prvky, jejich ovládání a chování systému. Z této schůzky vyvstal požadavek na prezentační vrstvu informačního systému. Jde o to, že v prototypu se nezobrazila zpráva typu „Záznam byl úspěšně uložen“ . Pokud při vyplňování formuláře neprojdou zadané hodnoty validací, jsou opět zobrazeny a vedle hodnot se zobrazí vysvětlující informace, že je zapotřebí položku vyplnit (je povinná) či není správně zadaná. Pokud nastane výjimka, je zpracována a zareaguje se na ni. Pokud vše proběhne v pořádku a záznam se uloží do databáze, nezobrazí se žádná informační zpráva a automaticky se zobrazí seznam položek v tabulce, ze kterého se přecházelo do editačního formuláře. Je ovšem pravda, že zobrazení informačního okna s informací o úspěšnosti provedené akce je pro uživatele dobrá kontrola a především psychlogické ujištění, že je vše v pořádku. Proto jsem přidal modální okno s informací o úspěšnosti, či neúspěšnosti akce před zobrazení seznamu položek. Toto okno je zobrazeno na obrázku 4.4 na straně 41.
4.9.1
Realizace zobrazení
Zobrazení modální okna zajišťuje následující kód:
4.9. POTVRZENÍ ÚSPĚŠNOSTI AKCE
41
Obrázek 4.4: Ukázka aplikace, kde se zobrazuje modální okno oznamující úspěšné upravení záznamu.
V tomto případě se nedá efektivně využít tuto část jako šablonu a předefinovat pouze tagy, které jsou závislé na Managed bean. Je to z toho důvodu, že tvoří většinu kódu, to co by mělo zůstat neměnné v šabloně je pouze následující: ... ... ... ... A k tomuto by naopak do každého použití přibyl třikrát následující kód: ...
42
KAPITOLA 4. REALIZACE
Z toho důvodu považuji za efektivnější nepoužít šablonu a komponentu modalPanel použít v každém souboru v adresáři pri s názvem XxxList.xhtml, kde Xxx je název business objektu.
4.9.2
Realizace v Managed bean
V kódu starajícího se o funkčnost využiji již existující kód pro zobrazování lokalizovaných zpráv. Stačí mi tedy přidat atribut stavu provedené akce do abstraktní třídy ManagedBean, aby byla přístupná ve všech potomcích. Atribut může obsahovat následující stavy CREATE_OK, CREATE_F, EDIT_OK, EDIT_F, REMOVE_OK, REMOVE_F, HIDE_OK, HIDE_F. Následně je zapotřebí vytvořit tři metody, které se starají o: 1. nastavení požadovaného stavu 2. předání lokalizované zprávy 3. deaktivaci stavu při skrytí modálního okna Následně je ještě zapotřebí do jednotlivých metod starajících se o vytvoření, úpravu, smazání a skrytí záznamu v jednotlivých třídách Managed bean přidat nastavení stavu o úspěchu či neúspěchu uložení. Tímto je tento požadavek na zobrazování informačních zpráv stavu vyřešen.
4.10
Převod dat do MS Excel
Import dat z webové stránky, která obsahuje tabulku s daty je velice snadný. Stačí vytvořit soubor s příponou *.iqy a do souboru napsat náledující řádky: WEB 1 http://is.domena.cz/tabulka.xhtml Při otevření tohoto souboru se otevře program MS Excel, který se připojí na zadanou url adresu a importuje tabulku do svého sešitu. Tento princip bohužel nefunguje na tabulky scrollableDataTable z knihovny Richfaces. Pro převody dat do MS Excel je tedy zapotřebí vytvořit novou webovou stránku, která bude obsahovat pouze požadovanou tabulku vytvořenou pomocí tagů
4.11
Kontrola unikátnosti přes více tabulek
Kontrolu unikátnosti záznamu, který je rozprostřen přes více tabulek – rodič a potomek. Nešlo realizovat klasickým způsobem. Proto jsem si vytvořil vlastní funkci, kterou kontroluji data pomocí check který používá funkci definovanou níže. Bylo zapotřebí přidat sloupec dtypeSpolecnost do tabulky spolecnost a v konstruktorech potomků její nasetovat a nahradit unique za check a v něm kontrolovat záznamy přes persist_obj. To samé u unique pro kombinace
4.12. NÁVRH LOGOVÁNÍ ZPRÁV
43
• rok, firma_id, kod_vyjezdu • vyjezd.rok, vyjezd.kod_vyjezdu, servisni_udalost.kod_firmy CREATE OR REPLACE FUNCTION check_uq_kod_vyjezdu (KODVYJEZDU char(4), ID integer, ROK integer) RETURNS boolean AS $$ DECLARE r integer; BEGIN SELECT INTO r count(*) FROM servisni_udalost AS su, vyjezd AS v WHERE su.id = v.id AND v.rok = ROK AND v.kod_vyjezdu = KODVYJEZDU AND su.firma__kod_firmy = (SELECT firma__kod_firmy FROM servisni_udalost AS su WHERE su.id = ID); IF r = 0 THEN RETURN ’t’; ELSE RETURN ’f’; END IF; END; $$ LANGUAGE plpgsql STRICT IMMUTABLE; CREATE OR REPLACE FUNCTION check_uq_ic (IC numeric(10), ID integer) RETURNS boolean AS $$ DECLARE r integer; BEGIN SELECT INTO r count(*) FROM persist_obj AS po, spolecnost AS s WHERE po.id = s.id AND s.ic = IC AND po.dtype = (SELECT dtype FROM persist_obj AS po WHERE po.id = ID); IF r = 0 THEN RETURN ’t’; ELSE RETURN ’f’; END IF; END; $$ LANGUAGE plpgsql STRICT IMMUTABLE;
4.12
Návrh logování zpráv
Logovnání zpráv v prostředí AS GlassFish používá 7 úrovní. Jsou jimi FINEST, FINER, FINE, CONFIG, INFO, WARNING a SEVERE. Z toho SEVERE je nejvyšší úroveň. Pochází z třídy java.util.logging.Level. K zaznamenání zprávy slouží třída java.util.logging.Logger.
44
KAPITOLA 4. REALIZACE
V kódu využívám několik úrovní podle závažnosti od informování použití metody až po zaznamenání výjimky. V administrátorském nastavení aplikačního serveru GlassFish lze ovlivnit úroveň logování zpráv bez nutnosti měnit kód či zastavovat aplikační server. Postup nastavení jsem popsal v kapitole D.3.3 na straně 75. Z důvodu, že mnohdy jsem měl problém určit původ vyvolané výjimky, rozhodl jsem se v každé metodě zavolat Logger, který zaznamená vstup do metody. Tím získám backtrack mých metod než došlo k chybě. Využití automatických výpisů zobrazující výjimku jsem mnohdy nemohl využít z důvodu, že zde bylo zobrazeno mnoho vnitřních tříd aplikačního serveru a potřebná třída byla zastoupena symbolem tří teček. Nebo se potřebné informace k nalezení problému ztratily při zapouzdření jedné výjimky do druhé. Což se děje především mezi prezentační a aplikační vrstvou. Samozřejmě těmto zprávám jsem přiřadil nižší úroveň a při běžném provozu se nemusí vůbec zaznamenávat. Ovšem je zde vždy možnost je zapnout bez nového nahrání kódu či restartu aplikačního serveru. Pro méně významné metody jsem u zpráv použil úroveň FINE a nižší. Některé zajímavější metody z aplikační vrstvy, jako jsou metody create, edit, remove, hide, jsem označil vyšší úrovní INFO. Úrovně WARNING a SEVERE jsem nepoužil k zaznamenávání informací, ale pouze k zaznamenání nějaké výjimky či neočekávaného stavu.
Kapitola 5
Testování Při tvorbě jakéhokoliv programu je třeba ověřit, že je schopen plnit úkoly na něho svěřené. Při psaní této kapitoly vycházím především z informací, které jsem se dozvěděl na akci pořádané společností Microsoft nazvané „Testování aplikací – panelová diskuze“ [2]. Testovat aplikace, které ke svému běhu potřebují aplikační server je problematické. Je to z důvodu dependency injektion, které se provádí uvnitř aplikačního serveru a pokud je prováděno testování ve vývojovém prostředí nejsou do proměnných vloženy objekty určené anotacemi. Možnost, jak toto vyřešit, je použití embedded aplikační server, který například pro JBoss existuje a pro Glassfish se prozatím připravuje. Ovšem, jak jsem se dozvěděl na setkáních JBoss User Group, kterého jsem členem, ani použít JBoss jako embedded aplikační server není bezproblémové řešení. Z těchto důvodu jsem unit testy provedl jen pro ty části kódu, které bylo možné a přínosné testovat. Pro integrační testy jsem si vytvořil vlastní řešení.
5.1
Unit testy
Unit testy slouží především k testování aplikační vrstvy. Pomocí unit testů z vývojového prostředí jsem testoval především metody tříd sloužících k validaci vstupních dat a metody pro sestavování JPQL dotazů. Většina kódu uvnitř metod Session Bean není potřeba testovat, protože jsou povětšinou v následujícím duchu: public class ZarizeniBean implements ZarizeniLocal { @PersistenceContext private EntityManager em; private Logger log = Logger.getLogger(this.getClass().getCanonicalName()); @Override public void create(Zarizeni zarizeni) { log.info("create = " + zarizeni.getKodZarizeni()); em.persist(em.merge(zarizeni)); }
45
46
KAPITOLA 5. TESTOVÁNÍ
@Override public void edit(Zarizeni zarizeni) { log.info("edit = " + zarizeni.getKodZarizeni()); em.persist(em.merge(zarizeni)); } ... } Pokud bych EntityManager nahradil mock objektem a následně provedl volání metody, přínos v tomto případě by byl minimální. Na výše zmíněné konferenci [2] zaznělo od jednoho z přednášejících: „Unit testy by se měly vytvářet před psaním metody. Já píši unit testy pouze v případě, kdy zaváhám nad tím, jak metodu napsat.“ S tímto názorem se ztotožňuji a proto výše uvedený příklad otestuji až v rámci integračních testů, kde otestuji, že metoda skutečné uložila záznam do databáze.
5.2
Integrační testy
Tuto kapitolu bych zahájil citováním z článku [4]: „Integrační testy spočívají v testování konkrétní kódu spolu s okolními částmi, se kterými spolupracuje. Cílem je snaha otestovat kód ve stavu, který se blíží reálnému nasazení. Obvykle takto testujeme datovou vrstvu aplikace (jelikož tam klasické jednotkové testy ztrácejí smysl – chceme přeci otestovat správné dotazování databáze, tudíž databázi k testu potřebujeme) a v řadě případů se nám nevyplatí mockovat ani na úrovni business vrstvy.“ Integrační testy potřebuji spouštět v rámci aplikačního serveru, kde se správně použije dependency injection. Abych mohl jednotlivé metody otestovat, potřebuji k nim mít přístup. Vývojové prostředí NetBeans ani Eclipse mi k tomuto neposkytuje potřebnou podporu. Napadla mě myšlenka využít web services, které mi budou volat metody, které chci otestovat. Celé to poběží v rámci aplikačního serveru, který si sám vyřeší dependency injection. Myšlenka je následující: 1. Vytvořím nový projekt, do kterého vložím projekt AirManager-ejb, který představuje aplikační vrstvu informačního systému. 2. V tomto novém projektu vytvořím novou službu web services, do které napíši testovací metodu, která bude testovat část kódu z AirManager-ejb. 3. Jednotlivé metody sloučím pod společnou webovou službu a připíši k ní počitadlo úspěšných (resp. neúspěšných) testovacích metod a vrátím pomocí návratové hodnoty.
5.3. AKCEPTAČNÍ TESTY
47
Aplikační server Glassfish obsahuje jednoduchého klienta pro volání web services v něm uložených. Toho využiji ke spouštění testů. Pokud nastane chyba, což se dozvím z výsledku počitadla, zjistím ji z logu aplikačního serveru. Tento návrh pro testování se mi osvědčil, a proto jsem jej použil k testování informačního systému. Uvedu příklad jednoho integračního testu, který vyhledá všechny provozovny zadané firmy podle kódu firmy. @WebService() @Stateless() public class AirManagerTest_Provozovna { ... /** * Vyhledá firmu s kódem firmy 001 a vyhledá všechny provozovny této firmy. */ @WebMethod(operationName = "findProvozovnaByFirmaTest1") public String findProvozovnaByFirmaTest1() { String kodFirmy = "001"; try { Firma f = firmaBean.findFirmaByKodFirmy(kodFirmy); List provozovny = provozovnaBean.getAllProvozovnaByFirma(f); return provozovny.toString(); } catch (KodFirmyNenalezenException ex) { Logger.getLogger(AirManagerTest_Provozovna.class.getName()) .log(Level.SEVERE, null, ex); return "exception"; } } ... }
5.3
Akceptační testy
Akceptační testy provádí zadavatel, v mém případě zadavatele nahradily operátorky call centra. Na pravidelných schůzkách jsem jim představoval nejprve vytvářený návrh, následně první prototypy až po jednotlivé funkční bloky informačního systém. Jednotlivé připomínky jsem postupně zapracovával a o některých jsem se zmínil v předešlých kapitolách.
5.4
Testování GUI v různých prohlížečích
Návrh informačního systému je založen na principu serverové části a klientské části. Klientskou částí může být libovolný internetový prohlížeč s javascriptem. V dnešní době patří mezi nejpoužívanější prohlížeče:
48
KAPITOLA 5. TESTOVÁNÍ
• Internet Explorer, • Mozilla Firefox, • Opera browser, • Google Chrome, • Safari. Což je 5 prohlížečů, které byly vybrány Evropskou unií pro tzv. Balot screen viz. [9]. Z těchto prohlížečů jsem se rozhodl otestovat Internet Explorer, Mozilla Firefox, Opera browser, Google Chrome. Prohlížeč Safari jsem netestoval z důvodu, že ani já ani společnost, pro kterou tento program vyvíjím, nemáme nainstalován tento prohlížeč. A také z toho důvodu, že jak Google Chrome, tak Safari používá stejné vykreslovací jádro, tj. WebKit (viz. [16]). Test funkčnosti prohlížečů byl proveden bez automatizovaných nástrojů. To znamená, že jsem musel provést předem navržený testovací scénář v každém prohlížeči a všímat si odlišností. Testovací scénář byl následující: 1. Otevřít prohlížeč; 2. Otevřít vstupní stránku do informačního systému; 3. Přihlásit se; 4. Zobrazit seznam firem; 5. Použit filtr; 6. Přidat nový záznam; 7. Otevřít tiskovou sestavu; 8. Odhlásit se. Hodnotil jsem především: • Vzhled zobrazených stránek a jejich odlišnosti. • Funkčnosti použitých komponent. Internet Explorer 8 – je v současné době nejnovější verzí tohoto prohlížeče od společnosti Microsoft. Vzhled i funkčnost jsou v tomto prohlížeči dobré a nejeví se žádné známky problémů. Internet Explorer 7 – je starší verze prohlížeče uvedeného výše a zobrazuje stejný výstup jako Internet Explorer 8 v režimu zpětné kompatibility. Výsledný vzhled je oproti Internet Exploreru 8 (bez použití zpětné kompatibility) odlišný a to především v rozměrech mezi zobrazenými prvky. Použité komponenty však fungují správně.
5.4. TESTOVÁNÍ GUI V RŮZNÝCH PROHLÍŽEČÍCH
49
Mozilla Firefox 3.6 – je prohlížeč internetových stránek od Mozilla Foundation. Poslední verzí je 3.6.3. Tento prohlížeč používám jako výchozí a všechny komponenty se zde zobrazují správně. A to jak v nejnovější verzi, tak i ve verzi od 3.5. Verze předcházející 3.5 jsem netestoval. Opera browser 10.50 – je prohlížeč internetových stránek od Opera Software. Nejnovější verze, tj. verze 10.50 až 10.53) se nedají pro připojení k informačnímu systému použít. Sice vzhled vypadá správně, ale jen do té doby, než jsou zobrazeny prvky z knihovny Richfaces a to především prvek scrollableDataTable. Tato komponenta se špatně zobrazuje, viz. obrázek 5.1 na straně 49. Při použití horizontálního posuvníku se data zobrazují, ale pouze jako druhý sloupec. Funkce, jako je rozšíření sloupce, také nefunguje.
Obrázek 5.1: Zobrazení komponenty scrollableDataTable v Opera browser 10.53.
Opera browser 10.10 – je starší verze prohlížeče. Zde je vzhled stejný jako u novější verze. Na rozdíl od verze 10.50 komponenta scrollableDataTable z knihovny Richfaces funguje podle očekávání. Je zde však problém se zobrazením formuláře pro filtrování, který se po stisku tlačítka nezobrazí. Komponenta, která se stará o zobrazení tohoto formuláře, se nazývá Effect a je z knihovny Richfaces. Google Chrome 5.0.375.29 beta – je prohlížeč od společnosti Google. Kromě formuláře pro filtrování, který se po stisku tlačítka nezobrazí, funguje vše správně a vzhled je také
50
KAPITOLA 5. TESTOVÁNÍ
podle očekávání. Komponenta, která se stará o zobrazení filtrovacího formuláře, se nazývá Effect a je z knihovny Richfaces. Zhodnocení – Z provedených testů internetových prohlížečů mohu doporučit k připojení na informační systém především prohlížeč Mozilla Firefox a Internet Explorer v nejnovější verzi. U ostatních prohlížečů se vyskytly problémy. Jak je vidět především na prohlížeči Opera, došlo k úpravám v kódu prohlížeče starajícího se o vykreslování a funkce javascriptu. Na druhé straně knihovna Richfaces se také stále vyvíjí. Pro novou verzi knihovny bude zapotřebí opět provést kontrolu funkčnosti.
5.5
Test použitelnosti z hlediska rychlosti komunikační linky
V rámci testování GUI v jednotlivých prohlížečích jsem u testování internetového prohlížeče Mozilla Firefox použil doplněk Firebug, kterým jsem zároveň měřil dobu načtení stránky. Testování probíhalo na 100 záznamech. Průměrné načtení proběhlo okolo 2 sekund spolu se zpracováním všech skriptů z onload byl čas 6 sekund. V předmětu „Styk člověka s počítačem“ bylo zmíněno, že uživatel je schopen čekat bez zjevné reakce 4 až 5 sekund po této době se již snaží použít např. použít tlačítko „načíst znovu“ . Pokud je zapotřebí na zpracování informace delší čas měl by systém zobrazit nějakou formou informaci, že pracuje, např. komponentu progress bar. Vzhledem k tomu, že systém se načte do 2 sekund a do 6 se celý správně vykreslí, je vše v pořádku. Provedl jsem také test použitelnosti informačního systému komunikujícího s klientem přes Internet. Na obou stranách bylo připojení pomocí ADSL linky od společnosti Telefonica O2. K testu jsem použil šifrované https spojení a prohlížeč Mozilla Firefox 3.6.3. Rychlost načtení jsem měřil pomoci doplňku Firebug. Tento test byl ovlivněn další komunikací, která probíhala v průběhu testování, jde především o použití připojení přes vzdálenou plochu, přes kterou byl test proveden. Načtení html stránek, které nepoužívají mnoho AJAX component 1 , probíhalo v rozmezí 1 až 2 sekundy. Načtení html stránek s mnoha AJAX componentami načítající data probíhalo v rozmezí od 10 do 15 sekund. Z testu vyplývá, že i přes takto pomalou linku lze realizovat tento informační systém. Pro reálné využití bych doporučil jiný typ připojení, například některou z variant symetrického připojení, kde bude hodnota upstream na straně serveru vyšší než je 300 kb/s. Při větší zátěži je také možnost využít služeb hostingového centra.
1
Např. načtení formuláře, kde se AJAX používá jen pro validaci
Kapitola 6
Závěr 6.1
Přínos mé práce a dosažené cíle
Podle požadavků zadavatele jsem provedl analýzu a navrhl informační systém pro podporu servisů společnosti starající se o servis klimatizačních, mrazících a chladících zařízení a vzduchotechniky. Realizace navrženého informačního systému obsahuje původní požadavky zadavatele. Vytvořený informační systém jsem testoval v několika úrovních. Průběžně jsem prováděl unit testy a integrační testy, všechny zjištěné chyby jsem odstranil. Poté jsem provedl test GUI. V průběhu testování informačního systému jsem byl v neustálém kontaktu se zadavatelem a předkládal jsem mu jednotlivé části programu. Na závěr jsem zadavateli předložil vytvořený informační systém k akceptačnímu testu. Akceptační test proběhl v pořádku a dle jeho očekávání. Při provádění analýzy jsem zjistil, že existuje další využití navrženého informačního systému nad rámec požadavků zadavatele. Toto využití jsem průběžně konzultoval s managementem společnosti a výsledky jsem zahrnul do analýzy a návrhu řešení v kapitole 3. V další verzi informačního systému budou zanalyzované rozšiřující požadavky implementovány. Jako vhodné nástroje pro implementaci jsem zvolil platformu Java EE, aplikační server Glassfish, databázový systém PostgreSQL a vývojové prostředí NetBeans. Jako výchozí prohlížeč jsem zvolil program Mozilla Firefox. V aplikačním serveru Glassfish jsem použil technologie EJB 3.0, Java Persistence API, Java Transaction API, Java Server Faces 1.2 a knihovnu Richfaces. Při vývoji jsem použil systém pro správu verzi CVS NT. Výběr výše jmenovaných nástrojů jsem v diplomové práci zdůvodnil. V analýze a návrhu informačního systému jsem použil prostředky softwarového inženýrství ve vývojovém prostředí NetBeans – plugin UML. Při řešení diplomové práce jsem se seznámil s databází PostgreSQL a získal praxi s psaním Enterprise aplikací. Přínosem pro zadavatele je získání požadovaného informačního systému, který dle jejich očekávání zefektivnil práci a přinesl úspory v oblasti evidence a nákladovosti jednotlivých zakázek.
51
52
KAPITOLA 6. ZÁVĚR
6.2
Možnosti rozšíření
Při analýzách nového podnikového informačního systému BYZNYS Win, byla zjištěna možnost komunikace obou informačních systémů. Můj informační systém AirManager sbírá, eviduje a třídí neekonomické údaje. Informační systém BYZNYS Win naopak sbírá ekonomické údaje. Je zde možnost napojení systémů, kde systém BYZNYS Win ze systému AirManager získá zpřesňující údaje pro ekonomické vyhodnocení zakázek. Např. v BYZNYS Win se sleduje spotřeba pohonných hmot a cestovného zaměstnanců souhrnně. Ze systému AirManager lze získat zpřesňující údaje o cestovném a pohonných hmotách podle jednotlivých servisních výjezdů. Komunikací systémů lze získat např. roční náklady na konkrétní zařízení umístěné, na kterékoliv provozovně. Na základě tohoto vyhodnocení lze identifikovat neefektivnost servisních zásahů a doporučit pořízení nového zařízení nejen podle počtu servisních zásahů, ale i podle finančních nákladů. Další možnosti rozšíření informačního systému AirManager jsou: • načtení firemních údajů ze systému ARES, • vytvoření GUI pro přístup z mobilního telefonu, • automatické odesílání email pomocí Java Mail API, na které je to již připraveno, • vytvoření dalších tiskových sestav, • zpřístupnění části informací klientům přímým přístupem do informačního systému,
Literatura [1] M. Fowler. Destilované UML. Grada Publishing, a.s., Praha, Praha, 1. edition, 2009. [2] J. Jirava. Testování aplikací – panelová diskuze. http://akce.altairis.cz/Events/299.aspx, stav z 15. 10. 2009. [3] B. Momjian. PostgreSQL – Praktický průvodce. Computer Press, a.s., Brno, Brno, 1. edition, 2003. [4] J. Novotný. Jak na rychlé integrační testy ve springu. http://blog.novoj.net/2007/08/04/jak-na-rychle-integracni-testy-ve-springu, stav z 04. 08. 2007. [5] R. Pecinovský. Návrhové vzory. Computer Press, a.s., Brno, Brno, 1. edition, 2007. [6] R. Pichlík. Chudokrevné a plnokrevné ioc, ejb vs. spring. http://pichlik.sweb.cz/labels/enterprise-java.html, stav z 10. 01. 2007. [7] R. Pichlík. Cz podcast 29 – intellij idea 8, netbeans 6.5, virtualbox, opensolaris. http://www.java.cz/article/czpodcast-29, stav z 1. 4. 2010. [8] M. Večeřa. Jboss: Aplikační server. http://www.root.cz/clanky/jboss-aplikacni-server/, stav z 18. 2. 2008. [9] Informace týkající se webových prohlížečů. http://www.browserchoice.eu, stav z 1. 4. 2010. [10] Microsoft dynamics crm. http://www.microsoft.com/cze/dynamics/crm/default.mspx, stav z 20. 3. 2010. [11] Richfaces live demo. http://livedemo.exadel.com/richfaces-demo/, verze v.3.3.3.Final. [12] Instalace postgresql. http://www.postgres.cz/index.php/Instalace_PostgreSQL, stav z 9. 2. 2009. [13] Instalace a správa postgresql. http://gama.fsv.cvut.cz/wiki/index.php/Instalace_a_správa_PostgreSQL, stav z 9. 2. 2009. [14] Jemný úvod do pl/pgsql. http://www.root.cz/clanky/jemny-uvod-do-plpgsql/, stav z 10. 2. 2009.
53
54
LITERATURA
[15] Toplink essentials jpa extensions reference. http://www.oracle.com/technology/products/ias/toplink/jpa/essentials, stav z 26. 8. 2009. [16] Webový prohlážeč. http://cs.wikipedia.org/wiki/Webový_prohlížeč, stav z 1. 4. 2010. [17] K. E. Wiegers. Požadavky na software. Computer Press, a.s., Brno, Brno, 1. edition, 2008. [18] P. Šlechta and P. Aubrecht. X33eja – enterprise java. http://x33eja.wikidot.com, stav z 2. 2. 2009.
Příloha A
Seznam použitých zkratek AJAX Asynchronous JavaScript and XML AS Aplikační server CDDL Common Development and Distribution License CRM Customer Relationship Management DTO Data Transfer Object EJB Enterprise java bean EPL Eclipse Public License ERP Enterprise Resource Planning GNU GNU’s Not Unix GNU GPL GNU General Public License GoF Gang of Four GUI Grafické uživatelské rozhraní HW Hardware IoC Inversion of Control IP adresa Internet protocol IS Informační systém Java EE Java Enterprise Edition Java ME Java Micro Edition Java SE Java Standard Edition JPA Java Persistence API
55
56
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
JPQL Java Persistence Query Language JSF Java Server Faces JTA Java Transaction API JVM Java Virtual Machine MBean Managed Bean MS Microsoft SW Software VBA Visual Basic for Application VPN Virtual Private Network .. .
Příloha B
UML diagramy
Obrázek B.1: Class diagram – Znázorňuje dědičnost Entit.
57
58
PŘÍLOHA B. UML DIAGRAMY
Obrázek B.2: Class diagram.
Obrázek B.3: Class diagram.
59
Obrázek B.4: Class diagram.
60
PŘÍLOHA B. UML DIAGRAMY
Příloha C
Datový model V této příloze uvádím kompletní návrh datového modelu. Vysvětlivky: N/NN Null / Not Null PK Primary Key FK Foreign Key IX Index UQ Unique Atribut id dtype skryto
Typ integer char(3) varchar(100) varchar(50) varchar(50) varchar(50) real real real integer real varchar(50) varchar(50) varchar(10) varchar(100) integer integer
NN NN
Index, Constraint PK
NN N
FK FK, UQ
Default
Tabulka C.25: pravidelny_servis_zarizeni
Atribut id jmeno mobil profese telefon_domu ulice_domu obec_domu psc_domu partner_id
Typ integer varchar(50) char(13) varchar(50) char(13) varchar(50) varchar(50) char(6) integer
Typ integer varchar(200) varchar(100) text integer
NN NN NN
Index, Constraint PK
NN
FK
Tabulka C.32: uri
Default
72
PŘÍLOHA C. DATOVÝ MODEL
Příloha D
Instalační a uživatelská příručka D.1
Instalace
D.1.1
Instalace aplikačního serveru Glassfish
1. Stažení verze 2.1.1 aplikačního serveru Glassfish pro linux (nebo jiný OS) ze serveru glassfish.dev.java.net. 2. Spuštění: java -Xmx256m -jar glassfish-installer-*.jar 3. Vstup do vytvořeného adresáře cd glassfish 4. V případě linuxové verze je zapotřebí k souborů v adresáři lib/ant/bin přidat příznak spustitelnosti chmod -R +x lib/ant/bin 5. Dále pokračuje instalace spuštěním ANTu postupujícím podle nastavení v souboru setup.xml lib/ant/bin/ant -f setup.xml (v případě běhu AS v clusteru se spouští setup-cluster.xml) 6. Tímto je instalace ukončena a aplikační server Glassfish může být spuštěn. bin/asadmin start-domain (v případě více konfigurací nebo nestandardního umístění je nutno pomocí dalších přepínačů zadat název a umístění konfigurace)
D.1.2
Instalace PostgreSQL
Instalaci jsem provedl podle návodu uvedeném na [12] a [13]: su apt-get install postgresql postgresql-client /etc/init.d/postgresql start
73
74
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
su postgres createuser dbuzivatel sudo -i pg_createcluster 8.4 main -start Pro snadnější správu je také možné nainstalovat program pgAdmin sudo apt-get install pgadmin3
D.2
Spuštění a ukončení aplikačního serveru Glassfish a databáze PostgreSQL
Spuštění aplikačního serveru Glassfish se provádí následujícím příkazem: glassfish/bin/asadmin start-domain V případě více konfigurací nebo nestandardního umístění je nutno vybrat konkrétní konfiguraci: glassfish/bin/asadmin start-domain --domaindir adresář Ukončení aplikačního serveru Glassfish se provádí následujícím příkazem: glassfish/bin/asadmin stop-domain V případě více konfigurací nebo nestandardního umístění je opět nutno vybrat konkrétní kofiguraci: glassfish/bin/asadmin stop-domain --domaindir adresář PostgreSQL se spouští automaticky při startu operačního systému. Pokud je zapotřebí jej spustit či ukončit ručně, je možné použít příkaz: /etc/init.d/postgresql start /etc/init.d/postgresql stop
D.3
Konfigurace aplikačního serveru
Konfigurace se provádí v administrátorském rozhraní aplikačního serveru na adrese http://localhost:4848/index.jsf 1 .
D.3.1
Zvýšení paměti pro JVM
Se vzrůstající velikostí projektu a s počtem uživatelů je zapotřebí více paměti než je základní nastavení. I když v průběhu vývoje jsem zjistil, že ještě více paměti je zapotřebí při vývoji, protože s každým deployem aplikace se zaplnění paměti zvyšuje až je následně zaplněna celá přidělená paměť a aplikace se stane nestabilní. Nastavení se provádí v menu Application Server v kartě JMV Settings → JMV Options. V tabulce D.1 se nacházejí výchozí hodnoty a hodnoty, které jsem použil. 1
Administrační rozhraní může být nakonfigurováno na jiném portu. Tento port se vypíše při spuštění aplikačního serveru.
75
D.3. KONFIGURACE APLIKAČNÍHO SERVERU
Položka –XX:MaxPermmSize= –Xmx
Původní hodnota 192m 512m
Nová hodnota 384m 768m
Tabulka D.1: Zvýšení paměti pro JVM
D.3.2
Konfigurace logování přístupu
K bezpečnosti patří i vědět, kdo se k němu připojuje (resp. pokouší připojit). Nebezpečí útoku se především zvýší pokud je počítačová síť připojena k Internetu či informační systém přímo komunikuje s klientem přes Internet. Nastavení se provádí v Administraci AS Glassfish v menu Configuration → HTTP Service. 1. V kartě HTTP Service (a) zaškrtněte Access Logging Enable; (b) další položky jsou určeny pro buffer; 2. V kartě Access Log (a) v kolonce formát lze nastavit zaznamenávaná data. Výchozím nastavením je: %client.name% %auth-user-name% %datetime% %request% %status% %response.length% (b) dále se zde dá nastavit pojmenování a rotace souborů. V menu Configuration → HTTP Service → Virtual Servers → server nastavení.
2
lze dospecifikovat
1. Zapnutí či vypnutí logování přístupu pro tento virtuální server – Access Logging
3
2. Nastavení umístění logovacího souboru. To se provede v položce Directory.
D.3.3
Konfigurace logování zpráv
Logovnání zpráv v prostředí AS GlassFish používá 7 úrovní. Jsou jimi FINEST, FINER, FINE, CONFIG, INFO, WARNING a SEVERE. Z toho SEVERE je nejvyšší úroveň. V kódu využívám několik úrovní podle závažnosti od informování použití metody až po zaznamenání výjimky. V administrátorském nastavení aplikačního serveru GlassFish lze ovlivnit úroveň logování zpráv bez nutnosti měnit kód či zastavovat aplikační server. Logování se nachází v menu Application Server a následně v kartě Logging → Log Levels. V této části se dá detailně nastavit úroveň zpráv pro jednotlivé moduly. Do tabulky Additional Properties přidám jméno package, ve kterém je napsán IS, tj. cz.vlk.airmanager a k němu požadovanou úroveň. Úroveň lze také detailněji vyspecifikovat a to tak, že namísto hrubého cz.vlk.airmanager se zapíše konkrétní package či třída. 2 3
tj. název virtuálního serveru, na kterém běží IS Controlled by HTTP Service, Enbale, Disable
76
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
D.3.4
Konfigurace uživatelů
Dalším krokem v konfiguraci AS je vytvoření seznamu s uživatelskými jmény, hesly a přiřazení uživatelů do skupin podle práv. Tato nastavení se nachází pod názvem Realm. Realm může být buď 1. FileReal tj. soubor umístěný v konfiguraci AS Glassfish, 2. CertificateRealm, 3. LDAPRealm, 4. JDBCRealm, 5. SolarisRealm. Pro potřeby vytvořit maximálně 10 uživatelů není zapotřebí vytvářet systémy přihlašování pomocí certifikátů, LDAP či ověřovat uživatele pomocí Solaris. Ze zbývajících dvou možností, tedy mít uživatele v databázi nebo souboru, jsem si zvolil umístění v souboru, protože se velmi snadno obsluhuje a není zapotřebí vytvářet tabulky pro uživatele a skupiny v databázi a formuláře pro jejich obsluhu. Vše potřebné totiž administrační konzole obsahuje v sobě. Nejdříve tedy vytvořím novou Realm. 1. Vyberu v menu Configuration → Security → Realms 2. Stisknu tlačítko New ... 3. Dále vyplním jméno: AirManager 4. Class Name: com.sun.enterprise.security.auth.realm.file.FileRealm 5. Key File: ${com.sun.aas.instanceRoot}/config/airmanager-keyfile 6. Toto celé potvrdím tlačítkem OK Nyní mám vytvořenu novou Realm a tlačítkem Manage Users mohu nastavovat jednotlivé uživatele systému. 1. Stisknu tlačítko New ... 2. Nyní vyplním uživatelské jméno do položky User ID 3. Dále pak skupinu či skupiny (Group List) 4 , do které uživatel patří. 4. A naposledy také heslo do New Password a Confirm New Password. Tímto vytvořím všechny uživatele systému. 4
Jména skupin musí odpovídat těm, které jsou uvedené v konfiguračního xml souborech informačního systému.
D.4. KONFIGURACE POSTGRESQL
D.3.5
77
Vytvoření certifikátu
Ke komunikaci pomocí šifrovaného https spojení je zapotřebí vytvořit certifikát. O certifikát je možné požádat certifikační autoritu. Nebo je také možnost vytvořit si vlastní certifikát, který je podepsán sám sebou. Příkaz pro vytvoření certifikátu je následující: cd /glassfish/domains/domain1/config keytool -henkeypair -keyalg RSA -keysize 1024 -validity 1500 -alias s1as -keystore keystore.jks -dname "cn=server, o=dipl, l=Probostov, st=Czech Republic, c=CZ" -selfcert
D.4
Konfigurace PostgreSQL
Na vytváření procedur v databázovém prostředí PostgreSQL je zapotřebí zpřístupnit jazyk PL/pgSQL. To zda je již PL/pgSQL povoleno se zjistí příkazem: createlang -l air_manager Pokud příkaz vrátí tabulku s řádkem plpgsql | t, je jazyk PL/pgSQL aktivní a lze používat příkazy tohoto jazyka. V opačném případě je zapotřebí tento jazyk zpřístupnit a to následujícím příkazem pod právy Postgres super uživatele: createlang plpgsql air_manager K vytvoření tohoto návodu jsem použil informace z [14].
D.5
Uživatelská příručka
Uživatelská příručka slouží jako návod k obsluze. Zmíním se zde o základních úkonech a funkčnostech sytému. Informační systém je realizován jako webová aplikace, která je přístupná z internetového prohlížeče. Nutností je, aby měl internetový prohlížeč povoleny javascripty. Jak se zmiňuji v kapitole 5.4 na straně 47, doporučuji používat internetový prohlížeč Mozilla Firefox nebo Internet Explorer 8. Pro práci s informačním systémem je zapotřebí mít základní znalosti pro práci s počítačem a umět pracovat s Internetem.
D.5.1
Přihlášení se do systému
Pro vstup do informačního systému AirManager je zapotřebí nejprve spustit internetový prohlížeč. Následně zadat do adresního řádku: https://is.domena.cz/AirManager-war. Tím se načte přihlašovací formulář jako je na obrázku D.1 na straně 78. Systém podporuje více jazyků v současné verzi to je český a anglický jazyk. Přihlašovací formulář a následně celý systém bude automaticky komunikovat ve zvoleném jazyce.
78
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
Obrázek D.1: Přihlašovací obrazovka – česká.
Obrázek D.2: Přihlašovací obrazovka – anglická.
Obrázek D.3: Nastavení jazyka v prohlížeči Mozilla Firefox.
Na obrázku D.2 na straně 78 je zobrazen přihlašovací formulář v anglickém jazyce. Volba jazyka je provedena automaticky v závislosti na nastavení internetového prohlížeče. Změna nastavení jazyka v internetovém prohlížeči Mozilla Firefox je zobrazena na obrázku D.3 na straně 78. Toto menu je přístupné přes Nástroje → Moznosti → karta Obsah pod tlačítkem Vybrat jazyky.
D.5.2
Hlavní menu
Po přihlášení se v levé částí obrazovky zobrazí hlavní menu, pomocí kterého se uživatel dostane ke všem povoleným datům. Hlavní menu je zobrazeno na obrázku D.4 na straně 79.
D.5. UŽIVATELSKÁ PŘÍRUČKA
79
Obrázek D.4: Hlavní menu.
Vysvětlení pojmů jednotlivých položek menu je vysvětleno v datovém slovníku v kapitole 3.5 na straně 15.
D.5.3
Záznamy
Obrázek D.5: Seznam firem. Jednotlivé záznamy jsou zobrazovány v tabulkách, jak je vidět na obrázku D.5 na straně 79. Záznam se volí kliknutím na požadovaný řádek. Pokud je tabulka příliš velká a nevejde se na obrazovku, má tabulka vlastní posuvníky na pravém a dolním okraji tabulky. Pomocí
80
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
nich se lze posouvat po tabulce. Data jsou načítána po částech pomocí technologie AJAX, a proto může docházet u pomalejšího připojení k prodlevám v zobrazení.
D.5.4
Formulář pro zadávání a úpravu
Obrázek D.6: Formulář pro zadání nové firmy. Přes menu Firma → tlačítko Nový záznam se zobrazí formulář pro zadání nové firmy. Formulář je zobrazen na obrázku D.6 na straně 80. Při zadávání dat se na pozadí provádějí validace. Hlášení systému o validaci jsou zobrazovány vedle chybně vyplněného řádku. Ale také vedle nevyplněného povinného řádku. Po stisku tlačítka Uložit se provede opětovná kontrola zadaných dat a pokud je nalezena chyba je zobrazen formulář s vyplněnými daty a požadavkem o opravě zadaných dat. Pokud je vše v pořádku, zobrazí se oznámení o úspěšnosti akce, jako je vidět na obrázku 4.4 na straně 41. Na stejném principu fungují i ostatní formuláře. Svá specifika má formulář pro zadávání nového výjezdu. Obsahuje více interaktivních prvků a modálních oken. Část tohoto formuláře je zobrazena na obrázku D.7 na straně 81. Jsou zde vidět tlačítka „+“ , pomocí kterých systém zajišťuje automatické doplnění hodnot. Dále je na obrázku vidět komponenta kalendář pro snadné zadávání data a času.
D.5.5
Filtrování a Řazení
Filtrování a řazení dat se nachází pod tlačítkem Filtr, který je umístěn nad každou tabulkou. Po stisku tohoto tlačítka se vysune formulář, který je zobrazen na obrázku D.8 na straně 82. Formulář se skládá z několika částí:
D.5. UŽIVATELSKÁ PŘÍRUČKA
81
Obrázek D.7: Výjezdový formulář.
• V první části je zobrazen seznam atributů, podle kterých lze provést filtrování. • V druhé části se zadají podmínky pro filtrování. • Ve třetí části je zobrazen seznam atributů, podle kterých lze provést řazení dat. • Ve čtvrté části lze zvolit řazení vzestupné resp. sestupné. Filtrování se provede stisknutím tlačítka Filtr. Filtr se zruší stisknutím tlačítka Zrušit filtrování.
D.5.6
Odkazy a poznámky
Ke každému záznamu lze vložit neomezené množství odkazů či poznámek. Tlačítko, pod kterým se odkazy (resp. poznámky) nacházejí, se nazývá Seznam odkazů (resp. Seznam poznámek ) a nachází se nad tabulkou. Modální okno spravující odkazy je zobrazeno na obrázku D.9 na straně 83. Obsahuje formulář pro zadání a editování odkazů. Pod tímto formulářem se nachází tabulka s odkazy vztaženými k vybranému záznamu.
D.5.7
Nižší práva
Podle přiřazených práv jednotlivým uživatelům má management společnosti přístup pouze ke čtení dat. Proto mu jsou skryta tlačítka, která nepotřebuje, tak jak je to vidět na obrázku D.10 na straně 83.
82
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
Obrázek D.8: Formulář pro filtrování.
D.5. UŽIVATELSKÁ PŘÍRUČKA
Obrázek D.9: Modální okna se seznamem odkazů.
Obrázek D.10: Zobrazení pod účtem s nižšími právy.
83
84
PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
Příloha E
Obsah přiloženého DVD Na přiloženém DVD se nacházejí tyto adresáře • \bin – Obsahuje ear soubor pro deploy na server • \dokumentace – Elektronická verze dokumentační části diplomové práce • \sql – SQL skripty pro databázi PostgreSQL. • \src – Zdrojové kódy programu. Strukturu zdrojových kódů aplikace jsem uvedl v kapitole Realizace – Struktura aplikace na straně 29. • \sw – Softwarové vybavení.
