X36ASS Dokumentace projektu. Firemní helpdesk se správou požadavků. Bc. Ondřej Brynda Bc. Petr Hůla

Transkript

1 X36ASS Dokumentace projektu Firemní helpdesk se správou požadavků Bc. Ondřej Brynda Bc. Petr Hůla

2 Obsah X36ASS Dokumentace projektu...1 Firemní helpdesk se správou požadavků Cíle projektu Uživatelé Funkční požadavky Nefunkční požadavky Use Case diagram Stavový diagram požadavku Datový model Použité technologie Diagramy nasazení Sekvenční diagramy načtení přehledu požadavků Náhled aplikace Srovnání architektur Vyhodnocení...11

3 1. Cíle projektu Cílem tohoto projektu je vytvoření webové aplikace Firemní helpdesk se správou požadavků a to hned ve dvou verzích ve dvou architekturách za účelem srovnání jejich výhod a nevýhod. Aplikace bude sloužit ke vkládání uživatelských dotazů a požadavků tedy stylem, který odpovídá aplikacím typu hepldesk. Navíc bude naše aplikace umožňovat správu těchto požadavků stylem issue tracking systémů. Uživatel/zákazník tedy zadá dotaz nad příslušným produktem. Pracovník firmy dále rozhodne o relevantnosti dotazu a buď ho uzavře nebo věc předá k dalšímu řešení příslušné osobě. Aplikaci jsme se rozhodli realizovat na platformách PHP a Enterprise Java. 2. Uživatelé Náš systém je cílen pro tři typy uživatelů. Jejich grafické znázornění najdete na obrázku 1. Nejobecnějším uživatelem je zákazník. Tento provádí v systému základní činnost, tedy odesílá svůj požadavek, zobrazuje již odeslané požadavky a komunikuje s ostatními uživateli diskuzí u jednotlivých požadavků. Řešitel je specifikací zákazníka s rozšířením pravomocí především o odesílání řešení jemu přidělených požadavků. I této osobě je umožněno přidávat do systému další požadavky, protože během řešení konkrétního požadavku může zjistit, že je třeba udělat ještě něco úplně jiného. Administrátor je rozšířením řešitele o klasické administrační prvky (správa uživatel), ale také o možnost přerozdělování požadavků konkrétním řešitelů. 3. Funkční požadavky V této kapitole popíšeme funkční požadavky na systém, rozdělené do kategorií dle uživatelských skupin. Zákazník zadává dotazy do systému, zobrazuje jím odeslané dotazy a jejich řešení, komunikuje s řešiteli kvůli upřesnění požadavků pomocí diskuse pod jednotlivými požadavky. Řešitel zobrazuje jemu přidělené požadavky a přidává k nim řešení. Administrátor spravuje uživatele a jejich účty, spravuje projekty a přiděluje jednotlivé požadavky konkrétním řešitelům. Má možnost nesmyslný nebo irelevantní požadavek rovnou uzavřít. 4. Nefunkční požadavky Obrázek 1: Uživatelé systému Nefunkční požadavky vychází z toho, že se jedná o webovou aplikaci. HTML i CSS by tedy měly být validní. Tím pádem musíme zajistit také správné zobrazení ve všech běžných webových prohlížečích. Aplikace by měla být dostupný 24 hodin denně, aby k ní mohli uživatelé pohodlně přistupovat kdykoliv nezávisle na časových pásmech. Důležitým požadavkem je také bezpečnost systému. Vyvarovat se musíme při nejmenším základním útokům jako SQL injection, XSS a další.

4 5. Use Case diagram Obrázek 2: Use case diagram Use Case diagram vidíte na přiloženém obrázku 2. Vychází ze zmíněných tří skupin uživatel. Zákazníkovi je tedy umožněno: zadat požadavek, přihlásit se nebo odhlásit ze systému, zobrazit své požadavky, přidat komentář a potvrdit vyřešení požadavku. Zobrazením svých požadavků je myšleno zobrazení požadavků, které zákazník odeslal. V případě řešitele, který tuto funkčnost dědí jde o zobrazení požadavků, které mu byly přiděleny k vyřešení. Řešitel tedy navíc může přidat řešení. Administrátor ještě navíc může spravovat uživatele a přiřazovat řešitele k jednotlivým požadavkům. 6. Stavový diagram požadavku Stavový diagram na obrázku 3 popisuje životní cyklus požadavku. Požadavek má celkem čtyři možné stavy: Nový, Přiřazený, Vyřešený a Uzavřený. Základním životním tokem požadavku je tedy posloupnost Nový, Přiřazený, Vyřešený a Uzavřený. To znamená, že je požadavek nejprve vytvořen a tedy ve stavu Nový, dále mu administrátor určí řešitele a požadavek přepne do stavu Přiřazený. Řešitel požadavek vyřeší a tudíž přepne do stavu Vyřešený. Následuje kontrola zákazníkem, který ověří vhodnost řešení. V případě, že je spokojen, potvrzením přepne požadavek do stavu Uzavřený. Není-li uživatel s řešením z nějakého důvodu spokojený, požadavek se znovu otevírá a tedy přepíná zpátky do stavu Přiřazený, je vrácen řešiteli. Životní cyklus dále umožňuje změnu řešitele požadavku. V případě, že už řešitel v řešení požadavku nemůže dále pokračovat, zruší se přiřazení a přepne znovu do stavu Nový. Pokud administrátor zjistil, že je požadavek nesmyslný, může ho ze stavu Nový přepnout rovnou do stavu Vyřešený.

5 Obrázek 3: Stavový diagram požadavku 7. Datový model Datový model aplikace je zobrazen na obrázku 4. Skládá se ze 4 entit a jedné ISA hierarchie. Ta odráží zmíněnou skupinu uživatel nad-entitu Osoba do níž patří Zákazník a Řešitel. Administrátor je odlišen příznakem isadmin, protože o něm neevidujeme žádné další informace, jen rozšiřujeme jeho pravomoce. Zákazník je v relaci N:N s entitou produkt, která eviduje informace o výrobcích firmy. Nad těmito produkty můžeme vznášet požadavky. Jsou tedy v relaci N:1. V entitě požadavek evidujeme informace sloužící k jeho popisu, příznak stavu a datum vložení a uzavření. Požadavky vznáší zákazník, takže je mezi nimi relace N:1. Řešitelům jsou tyto požadavky přidělovány k řešení od určitého data. Relace mezi nimi tedy nese tento atribut a je typu N:N, protože umožňujeme, aby jeden požadavek řešilo více řešitelů společně. Když řešitel požadavek vyřeší, přidá do databáze řešení. K tomu slouží entita Řešení. Relace řešitel řešení je logicky typu N:1. Relace požadavek řešení je typu N:1, což znamená, že k jednomu požadavku evidujeme více řešení, tedy například i původní špatné řešení, které zákazník zamítl (viz stavový diagram požadavku). Poslední entitou je Komentář, který slouží k diskutování nad jednotlivými požadavky. Konkrétní požadavek tedy může mít více komentářů. Komentáře vytváří osoby, tedy relace typu N:1. Každý komentář má svého jedinečného autora, který ovšem může vytvářet komentářů více.

6 Obrázek 4: Datový model

7 8. Použité technologie V případech obou architektur jsme zvolili open source řešení všech použitých technologií. V případě PHP, které bylo ve verzi 5.X byl jako webový server zvolen Apache a jako databázový server MySQL. V případě Java EE 6 jsme zvolili webový server GlassFish 3 a databázový server Java DB. 9. Diagramy nasazení Obrázek 5 ukazuje diagram nasazení aplikace v PHP verzi. Klient pomocí svého webového prohlížeče a http protokolu přistupuje k serveru, který obsluhuje mnoho klientů. Na serveru běží Apache s mod_php, který spouští naši aplikaci. Ta si pomocí mod_php načítá data z MySQL databáze. Java verze je zobrazena na obrázku 6. Situace klient-server je obdobná. Rozdíl je v tom, že na serveru běží JVM, které spouští server Glassfish, a ten zpřístupňuje aplikaci klientovi. Glassfish dále načítá data z databáze Java DB. Obrázek 5: Diagram nasazení - PHP

8 Obrázek 6: Diagram nasazení - Java 10. Sekvenční diagramy načtení přehledu požadavků Obrázek 7: Sekvenční diagram načtení požadavků - PHP Zřejmě nejnázornějším diagramem pro vyjádření rozdílu mezi jednotlivými architekturami jsou sekvenční diagramy. Na obrázku 7 je znázorněn sekvenční diagram načtení přehledu požadavků v architektuře s PHP. Zpracování probíhá následovně: webový prohlížeč pošle na server požadavek (ať již POST nebo GET) na konkrétní soubor (v tomto případě pozadavky.php), což už je přímo

9 konkrétní fyzická stránka, kde je umístěn náš vlastní kód. Naše stránka si vytvoří objekt Pozadavky, který je definován v souboru classpozadavky.php, a zavolá metodu tohoto objektu, která vrátí seznam požadavků. Zmíněná třída samozřejmě získá seznam požadavků tak, že pošle dotaz do databáze. Databáze vrací seznam řádků ve svém nativním formátu o tento formát se nestaráme, protože při zpracování výsledku používáme standartní funkce PHP, které nám umožní s výsledkem pracovat jako s asociativním polem (iterování přes řádky a indexem přes jednotlivé sloupce). Výsledek dotazu naše třída Pozadavky přepošle vlastní stránce pozadavky.php, která ho vypíše, přesněji řečeno pomocí PHP engine se vygeneruje konečná HTML podoba stránky a ta se odešle zpátky klientovi (v diagramu reprezentovaném čarou života: web. Prohlížeč). Obrázek 8: Sekvenční diagram načtení požadavků - Java Diagram pro stejnou situaci v architektuře Java je mírně složitější (zobrazeno na obrázku 8). Zpracování začíná stejně jako v předchozí architektuře: klient (webový prohlížeč) odešle požadavek na server. Tento požadavek namapuje server (v našem případě Glassfish) na konkrétní servlet (dáno v konfiguraci aplikace) a zavolá metodu servletu, která má zpracovat konkrétní typ požadavku (dopost nebo doget). Servlety obvykle spravuje nějaký framework (v našem případě JavaServer Faces), který po programátorovi požaduje pouze aby naplnil nějaké vlastnosti (zde konkrétně seznam požadavků, které se mají vypsat). To v Javě znamená volání metody get (zde konkrétně getpozadavky). Tato metoda se volá na tzv. backing bean, což jsou třídy, které mají za úkol obsluhovat prvky na jsf stránce. V sekvenčním diagramu je tento postup znázorněn jednoduše: čára života pozadavek.jsf volá metodu getpozadavky v balíku backing bean, která mu má vrátit seznam požadavků pro výpis. Backing bean by teoreticky mohl zpracovávat další vstupní parametry, ale v tomto jednoduchém případě to není zapotřebí. Backing bean předá volání metody na session bean v diagramu další čára života PozadavkyLocal.java, kde je uložena business logika naší aplikace.

10 Session bean by mohl provést další zpracování parametrů nebo další kontroly, ale nakonec stejně odešle dotaz na model, od kterého chce aby vybral seznam požadavků z databáze. Objekty v modelu, reprezentují entity jaké používáme v aplikaci a jejich mapování na tabulky v databázi (použita JavaDB). Je zde použit další framework Jave Persistence API, který mimojiné zajišťuje potřebné objektově-relační mapování. Model tedy odešle dotaz do databáze, databáze vrátí výsledek jako řádky tabulky, JPA provede OR mapování, tím dostaneme kolekci List objektů Pozadavek a ten opět vracíme přes jednotlivé vrstvy session bean a backing bean až do místa, kde servlet zavolal naší metodu getpozadavky. Zbytek obsluhy už se zařídí automaticky JSF vygeneruje servlet, ten zpracuje Glassfish a vygeneruje výhlednou odpověď v podobně HTML. 11. Náhled aplikace Na obrázku 9 si můžete prohlédnout screenshot výsledné aplikace, konkrétně stránky se seznamem zadaných požadavků. Pod hlavičkou "Helpdesk firmy XY" se nachází navigační menu a pod ním tabulka s výpisem zadaných požadavků. Ta obsahuje ID požadavku, jeho popis, aktuální stav, jméno řešitele, přiřazení ke konkrétní zakázce a odkaz na detail požadavku. Jelikož se v obou porovnávaných případech jedná o webovou aplikaci, její vzhled je totožný, a proto uvádíme pouze jeden obrázek. Obrázek 9: Náhled aplikace 12. Srovnání architektur V této kapitole uvedeme několik porovnání našich architektur. Jedná se spíše o předpokládané výhody a nevýhody, zatímco naše konkrétní zkušenosti jsou uvedeny v následujíc kapitole. Java Kompilované - rychlejší Méně hostingů Zpočátku složitější vývoj PHP Interpretované - pomalejší Rozšířený hosting Jednodušší pro začátečníka

11 Mnoho věcí zajišťuje samo o sobě Konfigurace v XML GC, debugování, škálování, knihovny... Vše si musíme udělat sami Konfigurace v PHP souborech Z technického hlediska je mezi oběma technologiemi zásadní rozdíl. PHP stránky se interpretují, tedy se zpracovávají při každém požadavku. Aplikace v Javě je kompilovaná, tedy se překládá do nativního kódu serveru. Oba přístupy mají své výhody i nevýhody intepretování je platformově nezávislé, ale není zde žádný prostor pro optimalizace, tedy stránka běží pořád stejně rychle. Naproti tomu kód Javy se může s výhodou optimalizovat a je potom rychlejší než PHP, ale nevýhodou je právě to, že musíme provést kompilaci, obvykle probíhá tzv. JIT (Just In Time), tedy například při prvním použití stránky - první načtení tedy bude mírně pomalejší. Druhým poměrně velkým rozdílem je dostupnost hostingu pro jednotlivé technologie. Zatímco PHP je jednoznačně nejrozšířenější, hostingy na Javu se shánění o mnoho hůře. To souvisí zřejmě i s dalším rozdílem: programování v PHP je na první pohled daleko jednodušší než v Javě. Tedy spíše se najdou uživatelé schopní psát v PHP než v Javě. Na druhou stranu výhodou Javy je, že mnoho rutinních činností zajišťuje sama o sobě, zatímco v PHP začínáme obvykle stavět na zelené louce. Je to dáno tím, že Java je poměrně rozsáhlá technologie (nejen pro webové projekty), tedy má velké množství knihoven, podporuje například automatickou správu paměti, škálování atd. 13. Vyhodnocení Při zpracování našeho projektu se nám jevil jako nejzásadnější rozdíl ve složitosti obou technologií. Trvalo nám mnohem delší dobu se zorientovat v Javě. Abych mohli vůbec začít psát museli jsme pochopit rozdělení do backing bean, session bean, modelu, jak vše spolu provázat a tak dále. Zatímco v PHP byl vývoj dost přímočarý, zhruba na úrovni: sem napište kód. Z toho plyne, že první verze byla hotová právě v PHP. Na druhou stranu, když jsme se seznámili s prostředím Javy, spoustu prací jsme měli ušetřenou díky možnostem Javy například ošetřování parametrů, jak už u dotazů do databáze, tak parametry požadavku, nebo OR mapování, řešení autorizace uživatelů... Dalším zásadním rozdílem je podle nás podpora ze strany IDE. Zatímco v Javě se zdá (například v sekvenčním diagramu), že musíme napsat mnohem více kódu, tak díky podpoře v IDE (v našem případě NetBeans) ho napíše vlastně méně než v PHP velké části se dají generovat například entity z databáze nebo i přehledy v JSF stránkách (podle entit). Takováto podpora IDE pro PHP neexistuje. Pravděpodobně je to dáno tím, že v PHP neexistují podobné standarty jako v Javě, takže se dá těžko předpokládat co chce programátor vlastně napsat. Velkým rozdílem je i to, jak jednotlivé technologie vynucují samotnou architekturu aplikace. Zatímco v PHP záleželo jen na nás, že jsme se snažili logiku aplikace a dotazy do databáze ukládat do zvláštních tříd a nemíchat do zobrazování, v Javě nás to daleko více nutilo rozdělit aplikaci do mnoha tříd. Vše je názorně vidět v sekvenčních diagramech. V PHP má naše aplikace stěží dvě vrstvy: prezentační a ve třídách business a databázovou. Naproti tomu v Javě: servlety a backing beany tvoří naší prezentační vrstvu, session beany business vrstvu a model je naše databázová vrstva. Zřejmě netřeba zmiňovat, že Java je přirozeně objektový jazyk, zatímco PHP zavádí objekty teprve v posledních pár letech. Během naší práce jsme nezaznamenali rozdíly co se týče rychlosti jednotlivých technologií. Ani problém s hostingy se nás nedotknul, protože jsme vyvíjeli na lokálně nainstalovaných serverech. Kdybychom vše shrnuli, dalo by se říct, že Java umožňujeme psaní lepších aplikacích, pomocí lepších nástrojů, ale vše je vykoupeno větší náročností jak na programátory, tak programové

12 vybavení. Naproti tomu v PHP může snadno vyvíjet téměř kdokoliv a v čemkoliv, ale zřejmě by bylo velmi obtížné s ním psát velký projekt. Na druhou stranu není potřeba používat Javu na malé osobní stránky. Nejdůležitějším kritériem pro volbu architektury (PHP nebo Java) je, podle našeho názoru, velikost zpracovávaného projektu. Podle našich zkušeností leží náš projekt na pomezí toho kdy se vyplatí použít Javu a přitom šel poměrně bez problémů realizovat i v PHP.