ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ
BAKALÁŘSKÁ PRÁCE Rozvoj informačního systému OpenPhone František Hradil
Vedoucí práce: Ing. Martin Komárek Studijní program: Softwarové technologie a management Obor: Softwarové inženýrství Červen 2009
Poděkování Rád bych na tomto místě poděkoval panu Ing. Martinu Komárkovi za vedení práce, přátelský přístup a přínosné konzultace k celé práci. Dále chci poděkovat svým rodičům, kteří mě podporovali v průběhu celého studia.
Prohlášení Prohlašuji, že jsem svou bakalářskou 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). Celé dílo je možné šířit pod licencí BSD (Berkeley Software Distribution - http://cs.wikipedia.org/wiki/BSD_licence).
V Praze dne 3.6.2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstract OpenPhoneIS is information system which facilitates private phone call`s legal obligation to small and middle organisations. System provides, on the strength of phone account and check some employee`s phone calls as private, automatic pricing to employee`s payment. On the strength of electronics bank statement, system parses income bank payments which are generated payment pair off.
Abstrakt OpenPhoneIS je informační systém usnadňující malým a středním organizacím zákonnou povinnost vyúčtování telefonických hovorů, které zaměstnanci uskutečnili soukromě. Systém, díky detailnímu výpisu z účtů a označení některých telefonických hovorů zaměstnanci za soukromé, umožnuje automatický výpočet částky, kterou má konkrétní zaměstnanec uhradit. Na základě elektronického výpisu dojde k načtení příchozích plateb, které jsou systémem spárovány s vygenerovanými platbami.
Obsah 1 Úvod................................................................................................................13 2 Popis problému................................................................................................15 2.1 Cíl práce...................................................................................................15 2.2 Průzkum existujících systémů..................................................................15 2.2.1 Tardat 4..............................................................................................15 2.2.2 WINTEL............................................................................................16 3 Analýza............................................................................................................17 3.1 Požadavky................................................................................................17 3.1.1 Funkční..............................................................................................17 3.1.2 Nefunkční..........................................................................................18 3.2 Uživatelské role........................................................................................18 3.2.1 Super administrátor...........................................................................19 3.2.2 Administrátor.....................................................................................19 3.2.3 Oprávněný uživatel............................................................................19 3.2.4 Seznam systémových operací............................................................19 3.3 Případy užití.............................................................................................20 3.4 Business object model a business procesy...............................................22 3.4.1 Business object model.......................................................................22 3.4.2 Business procesy...............................................................................22 4 Návrh a implementace.....................................................................................25 4.1 Rozdělení aplikace do subsystémů...........................................................25 4.2 Prezentační vrstva.....................................................................................27 4.2.1 Lokalizace textů................................................................................27 4.2.2 JSF Managed Beany..........................................................................27 4.2.3 Směrování stránek.............................................................................28 4.2.4 Konfigurace vrstvy............................................................................28 4.3 Aplikační vrstva.......................................................................................29 8
4.4 Datová vrstva............................................................................................30 4.5 Refaktorizace............................................................................................31 5 Použité technologie.........................................................................................33 5.1 Java Server Faces.....................................................................................33 5.2 Java Enterprise Edition.............................................................................33 5.3 GlassFish Application Server...................................................................33 6 Testování.........................................................................................................35 6.1 Unit testy..................................................................................................35 6.2 Výkonnostní testy.....................................................................................37 6.3 Zátěžové testy...........................................................................................39 7 Závěr................................................................................................................41 7.1 Splnění zadání..........................................................................................41 7.2 Doporučení pro další vývoj......................................................................41 7.3 Přínos pro autora......................................................................................41 8 Literatura.........................................................................................................43 9 Seznam příloh..................................................................................................45
9
Seznam obrázků Obrázek 1: Případy užití - obecný přehled................................................................................21 Obrázek 2: Business object model............................................................................................23 Obrázek 3: Diagram komponent...............................................................................................26 Obrázek 4: NetBeans Profiler - výsledek testu.........................................................................38 Obrázek 5: JMeter - výsledek testování - zobrazení stránky registrace.jsp (graf)....................40 Obrázek 6: JMeter - výsledek testování - zobrazení stránky registrace.jsp (tabulka)...............40
10
Seznam použitých zkratek 1. CASE: Computer-aided software engineering 2. VPN: Virtual Private Network 3. J2EE: Java 2 Enterprise Edition 4. J2SE: Java 2 Standart Edition 5. JSF: Java Server Faces 6. EJB: Enterprise JavaBean 7. JPA: Java Persistence API 8. API: Application Programming Interface 9. JVM: Java Virtual Machine 10. IDE: Integrated development environment 11. HTML: HyperText Markup Language 12. RMI: Remote Method Invocation 13. URL: Uniform Resource Locator 14. HTTP: Hypertext Transfer Protocol 15. UML: Unified Modeling language
11
12
1 Úvod Tématem mojí bakalářské práce je zpracování telefonních výpisů. Toto téma jsem si vybral proto, že se mi zdálo zajímavé a přínosné nejem pro firmy, ale také pro státní instituce. Rychle se šířící ekonomická recese nutí podniky poohlížet se po softwarových řešeních, která jsou volně dostupná. V současné době na trhu podobné řešení není. Rád bych tímto produktem pomohl ušetřit peníze firmám a usnadnil práci zaměstnancům, kteří evidencí a zpracováním vyúčtování ztrácejí čas, který by mohli ve svém zaměstnání věnovat něčemu přínosnějšímu. Jako CASE nástroj jsem zvolil Enterprise Architect [1], se kterým jsem se setkal v průběhu studia a mám s ním dobré zkušenosti. Jedná se o často používaný a cenově dostupný software, se kterým se mi velmi dobře pracuje. Volba vývojového prostředí pro mě byla jasná – vybral jsem si NetBeans IDE [2], které mě doprovázelo v průběhu celého studia. Práce navazuje na předmět Semestrální projekt (Y36PRO). V tomto předmětu se provedla analýza, vzniklo jádro aplikace a dále moduly pro parserování bankovních výpisů a podrobných výpisů od telefonních operátorů, modul pro odesílání a příjem emailů a také prezentační část. Zdá se mi v úvodu této práce nutné uvést seznam toho, za co nesu odpovědnost: •
prezentační vrstva: návrh, implementace, testování, grafické zpracování
•
jádro aplikace (aplikační + datová vrstva): návrh, implementace a testování
•
obecně: analýza, softwarová architektura (komunikace komponent)
13
14
2 Popis problému 2.1 Cíl práce Cílem této bakalářské práce je analyzovat, navrhnout, implementovat a otestovat systém, který usnadní organizacím s malým a středním počtem mobilních telefonů vyúčtování hovorů, které zaměstnanci uskutečnili soukromě. Úhrada a nebo zdanění těchto částek je povinna ze zákona. Systém díky detailnímu výpisu z účtů a označení některých telefonických hovorů zaměstnanci za soukromé bude umožňovat automatický výpočet částky, kterou má konkrétní zaměstnanec uhradit. Na základě elektronického bankovního výpisu, který systém získá z emailu nebo ze souboru, dojde k načtení plateb, které budou systémem spárovány s vygenerovanými platbami. Další funkce, kterou bude systém zajišťovat, je možnost přihlášení určitého počtu rodinných příslušníků či přátel zaměstnanců do VPN sítě zaměstnavatele. Zaměstnavatelům systém přinese úspory ve formě ušetřených nákladů spojených s voláním zaměstnanců svým blízkým a také možnost získat větší slevu z důvodu větší celkové sumy provolaných minut.
2.2 Průzkum existujících systémů Na trhu existuje několik komerčních produktů, které umožňují sledovat telefonní hovory. Jsou ovšem omezeny pouze na získávání dat z digitálních ústředen a neumožní nám tedy sledovat hovory, které zaměstnancí uskutečnili z mobilních telefonů. Další nevýhodou těchto aplikací je jejich cena, která se pohybuje v řádech desetittisíců korun, což může být pro malé organizace překážkou. OpenPhoneIS by měl zaplnit mezeru na našem trhu, a proto je jeho vývoj smysluplný. Výhodou produktu budou téměř nulové pořizovací náklady a minimální nároky na údržbu. Následující informace o produktech jsou citovány z webových stránek výrobců.
2.2.1 Tardat 4 Program TARDAT 4 slouží pro tarifikaci, evidenci a vyhodnocení informací o telefonních hovorech, které poskytuje pobočková telefonní ústředna. Tarifní data lze do programu přenášet jak prostřednictvím externí mezipaměti (např. našeho bufferu
15
TARFLEX), tak kabelem z ústředny. U některých typů ústředen, které jsou vybaveny síťovým rozhraním, je možné přenášet data z ústředny přímo po počítačové síti. Jedna instalace programu může udržovat databázi až 48 ústředen, které mají zcela nezávislou konfiguraci. Základní funkcí programu TARDAT je zobrazování údajů o hovorech v přehledech. Každý přehled obsahuje řadu nastavitelných parametrů, které umožňují zadat výběr zobrazovaných hovorů pomocí řady podmínek, zvolit zobrazované údaje a přizpůsobit vzhled výstupu požadavkům uživatele. Z programu lze přímo tisknout také účtenku a fakturu za telefonní provoz. K dispozici je také jednoduchý nástroj pro vyúčtování hovorného hostů v hotelu nebo pacientů v nemocnici. [3]
2.2.2 WINTEL Vyhodnocovací program telefonního provozu pobočkových ústředen – WINTEL umožňuje rychlé a podrobné sledování telefonního provozu pobočkových ústředen. Uživatel programu tak získává všechny potřebné údaje o telefonních hovorech: u odchozích dostává informaci o tom kdo, kdy, kam a za kolik telefonoval, u příchozích kdo, kdy a jak dlouho vedl telefonní hovor a v případě vysílané identifikace volajícího i z jakého telefonního čísla bylo voláno. [4]
16
3 Analýza 3.1 Požadavky Požadavky byly evidovány v CASE nástroji a jejich detailní zachycení se nachází v příloze F (/dokumentace/analyza/Requirements/requirements.pdf). Pro lepší přehlednost byly funkční požadavky rozděleny do několika kategorií.
3.1.1 Funkční 1. Administrace 1.1.
Systém bude umožňovat správu osob
1.2.
Systém bude umožňovat editaci firemních údajů
1.3.
Systém bude umožňovat správu oddělení
1.4.
Systém bude umožňovat správu uživatelských rolí
1.5.
Systém bude umožňovat správu telefonních čísel
1.6.
Systém bude umožňovat editaci firemního nastavení
2. Volby uživatele 2.1.
Systém bude umožňovat editaci osobního nastavení
2.2.
Systém bude umožňovat zobrazení platební historie
2.3.
Systém bude umožňovat zobrazení podrobného vyúčtování
2.4.
Systém bude umožňovat označování soukromých hovorů
2.5.
Systém bude umožňovat správu soukromých čísel
2.6.
Systém bude umožňovat zobrazení osobních údajů
2.7.
Systém bude umožňovat změnu hesla
3. Přehledy 3.1.
Systém bude umožňovat zobrazení provolané částky pro celou firmu
3.2.
Systém bude umožňovat zobrazení přehledů osob
3.3.
Systém bude umožňovat zobrazení přehledů plateb
3.4.
Systém bude umožňovat zobrazení přehledů telefonních čísel
3.5.
Systém bude umožňovat zobrazení přehledů vyúčtování
4. Registrace 4.1.
Systém bude umožňovat registraci nových firem
5. Super administrace 5.1.
Systém bude umožňovat správu bank
17
5.2.
Systém bude umožňovat správu jazyků
5.3.
Systém bude umožňovat smazání firmy
5.4.
Systém bude umožňovat změnu hesla
5.5.
Systém bude umožňovat zobrazení registrovaných firem
6. Volby účetní 6.1.
Systém bude umožňovat generování příkazů k úhradě
6.2.
Systém bude umožňovat vkládání telefonního vyúčtování
6.3.
Systém bude umožňovat ruční vytvoření platebního příkazu
6.4.
Systém bude umožňovat kontrolu e-mailů s bankovním výpisem
6.5.
Systém bude umožňovat vkládání bankovního výpisu v souboru
6.6.
Systém bude umožňovat ruční zadání příchozí platby
6.7.
Systém bude umožňovat automatické generování příkazů k úhradě
6.8.
Systém bude umožňovat automat. kontrolu e-mailů s bank. výpisem
3.1.2 Nefunkční 1. Systém bude webová aplikace. 2. Systém bude pro uložení dat používat relační databázi. 3. Systém bude volně šířitelný a bude tedy používat jen nekomerční volně dostupné komponenty. 4. Systém bude naprogramován v prostředí J2EE. 5. Systém bude nasazen na aplikačním serveru GlassFish. 6. Webová část systému bude používat framework JSF. 7. Systém bude k databázi přistupovat pomocí JPA (Toplink). 8. Systém bude optimalizován pro webový prohlížeč Firefox, který bude mít zapnutý javascript a css.
3.2 Uživatelské role V aplikaci nejsou pevně stanovené role. Existují pouze dvě základní role – super administrátor a administrátor. Další lze vytvářet a přiřazovat uživatelům podle uvážení. Každá role může opravňovat uživatele k vykonání určité systémové operace, a to té, která se dané roli přiřadí. Počet rolí, které uživatel může mít je libovolný, ovšem minimálně musí mít roli jednu.
18
3.2.1 Super administrátor Super administrátor je správce celé aplikace. Může si zobrazit přehled registrovaných firem a případně je smazat, může editovat seznam jazyků a bank. Nemá však možnost zobrazovat si telefonní vyúčtování či údaje o zaměstnancích registrovaných firem. Tato role je speciální a nemůže být přiřazena žádné osobě. Superadministrátor může být vytvořen pouze přidáním položek superAdminID a password do příslušné databázové tabulky (SuperAdmin).
3.2.2 Administrátor Tato role se vytvoří automaticky při zaregistrování firmy a je přiřazena uživateli, který byl uveden v registračním formuláři jako administrátor. Výchozí nastavení je takové, že uživatel s touto rolí může provádět všechny systémové operace. Toto nastavení je však možné libovolně upravovat.
3.2.3 Oprávněný uživatel Takto je v use-case modelech zobrazován uživatel, jehož role má přiřazenou potřebnou systémovou operaci.
3.2.4 Seznam systémových operací 1. Může administrovat firmu: Tato operace dovoluje provádět use-case “Editování firemních údajů”. 2. Může administrovat oddělení: Tato operace dovoluje provádět use-case “Editování oddělení”. 3.
Může administrovat role: Tato operace dovoluje provádět use-case “Editování rolí”.
4. Může administrovat osoby: Tato operace dovoluje provádět use-case “Editování osob”. 5. Může administrovat telefony: Tato operace dovoluje provádět use-case “Editování telefonních čísel”. 6. Může administrovat nastavení: Tato operace dovoluje provádět use-case “Editování firemního nastavení”. 7. Může vložit vyúčtování: Tato operace dovoluje provádět use-case “Vložení vyúčtování”. 8. Může vložit bankovní výpis: Tato operace dovoluje provádět use-case “Vložení
19
bankovního výpisu v souboru” a “Kontrola e-mailů s bankovním výpisem”. 9. Může generovat platby: Tato operace dovoluje provádět use-case “Generování platebních příkazů”. 10. Může zadat bankovní příkaz k úhradě: Tato operace dovoluje provádět use-case “Vytvoření příkazu k úhradě”. 11. Může zadat příchozí platbu: Tato operace dovoluje provádět use-case “Zadání příchozí bankovní platby”. 12. Může vidět vyúčtování: Tato operace dovoluje provádět use-case “Zobrazení přehledů telefonních vyúčtování”. 13. Může vidět osoby: Tato operace dovoluje provádět use-case “Zobrazení přehledů osob”. 14. Může vidět příchozí platby: Tato operace dovoluje provádět use-case “Zobrazení přehledů příchozích plateb”.
3.3 Případy užití Případy užití zachycují funkce modelovaného systému z pohledu aktérů. Je vhodné je modelovat u systémů, ve kterých převládají funkční požadavky a tam, kde je větší počet aktérů. Naopak není vhodné je modelovat pokud převládají požadavky nefunkční [18]. U systému OpenPhone byla volba zda modelovat či nemodelovat diagramy případů užití jasná. Funkčních požadavků je jednoznačně více než nefunkčních a aktérů může být mnoho v závislosti na tom, kolik jich vytvoří správce aplikace. Diagramy a zejména jejich scénáře vznikaly iterativně a často reagovaly na změnu požadavků na systém. Diagram na obrázku 1 zobrazuje nejdůležitější případy užití. Detailní zpracování a rozdělení do menších logických celků spolu se scénáři naleznete v příloze D (str. 25).
20
uc SimpleDocumentation
Editov ání firemních údaj ů
Editov ání firemního nastav ení Editov ání oddělení
(from A dministra ce)
(fro m Ad min istrace ) (fro m Ad mi nistrace )
Editov ání rolí Editov ání telefonních čísel
(from A dministra ce)
(fro m Ad min istrace ) Editov ání osob
(from A dmini strace)
Opráv něný uživ atel (from A ktéři)
Zobrazení přehledů osob
(from P řehl edy) Zobrazení přehledů telefonních v yúčtov ání
(fro m P ře hled y)
Zobrazení přehledů platebních příkazů
(fro m P řeh led y) Generov ání platebních příkazů
Zadání příchozí bankov ní platby
(from Vo lbyUcetn i)
Vložení bankov ního v ýpisu v souboru
(from V olb yUcetn i)
Vložení v yúčtov ání
(fro m V ol byUce tni)
Obrázek 1: Případy užití - obecný přehled
21
(fro m V o lbyUce tni)
Zobrazení přehledů příchozích plateb
(from P řeh ledy)
3.4 Business object model a business procesy 3.4.1 Business object model Business object model na obrázku 2 zachycuje statickou strukturu modelovaného systému. Cílem modelu je poskytnutí náhledu na systém na konceptuální úrovni. V modelu jsou zobrazeny všechny analytické třídy se všemi svými atributy. Vztahy mezi objekty jsou na konceptuální úrovni zachyceny pouze pomocí obyčejných asociací u kterých je navíc uvedena násobnost.
3.4.2 Business procesy Jedním z největších problémů v průběhu analýzy, bylo nalezení relací mezi business objekty Person, Payment a BankPayment. S tím souvisela i analýza procesu párování plateb. Celý proces může na první pohled vypadat poměrně jednoduše – systém vygeneruje příkaz k úhradě a poté ho dotyčná osoba zaplatí. Komplikace však nastává v okamžiku, kdy dotyčná osoba zaplatí příkaz k úhradě jen částečně nebo pokud zaplatí více peněz než má. Způsob, jakým systém páruje platby, je nejlépe vidět na diagramu activit (Párování plateb vložení výpisu v souboru), který naleznete v příloze E (str. 53). Variabilní symbol příkazů k úhradě má hodnotu, která odpovídá identifikačnímu číslu osoby v systému, pro níž se příkaz vytváří. Při přijetí platby se peníze připočtou k nejstaršímu vygenerovanému platebnímu příkazu. V případě, že přišlo více peněz než bylo požadováno, přičte se rozdíl na účet osoby, která peníze zaslala a při dalším vygenerování platebního příkazu se odtud odečtou. Dalším problematickým procesem bylo generování platebních příkazů. Tento proces znázorňuje diagram aktivit (Generování platebních příkazů), který se také nachází v příloze E (str. 52). Problém při generování nastává v okamžiku, kdy bylo jedno telefonní číslo používáno v zúčtovacím období více osobami. Proto systém při generování nejprve zjistí, kolik osob číslo používalo a poté pro každou osobu hledá hovory (položky), které byly uskutečněny v době, kdy číslo používala. Dalším krokem je výpočet ceny soukromých položek a případné přepsání peněz z účtu osoby do zaplacené částky příkazu k úhradě.
22
class Business Obj ect Model
Settings -
Operation
callCost: Dou ble com p anyID: Integ er constantS ym bo l: String defa ultLa ngu age: Strin g pass: Strin g pop 3: S tring pop 3P ort: int se ttingsID: Integ er sm sCost: Do uble sp ecSym b : String userna m e: S tring version: in t
-
SuperSettings
n am e : Strin g o pera tionID: Inte ger
-
1 0 ..*
Language
sm tp: S tring sm tpP ass: S tring sm tpP ort: in t sm tpUse rnam e: S tring supe rSettingsID: In tege r version: int
-
la ngu age ID: S tring
-
ba nkID: Inte ger na m e: S tring version: in t
RoleOperationMap Bank
SuperAdmin
1
-
0 ..*
pa sswo rd: S tring supe rAdm inID: String version: int
1 1 Company -
accou nt: S tring com panyID: Inte ger di c: S tring em ail: S tring ic: S tring na m e: String version: int
Role 1..* -
1 1
PersonRoleMap
na m e: S tring rol eID: Integ er 1 version: int
0 ..* 1 ..*
1
Department
1..* -
Employee
active: bo olea n co m pa nyID: Intege r dep artm e ntID: Integ er 1 description : Strin g nam e: S tring sho rtcut: S tring ve rsio n: int
1..* -
begin Em ploy: T im estam p depa rtm en tID: Intege r em pl oyeeID: Inte ger endE m p loy: T i m estam p ve rsio n: int
NewEv ent
0..1
-
0..* PhoneNumber -
active: b oole an descriptio n: S tring num ber: Strin g pho neNum berID: int version: in t
PersonPhoneNumberMap 0..* -
1
begin Use: T im e stam p endUse: T im estam p ve rsio n: int
0 ..* 0..*
1
1
1
1
Person 1 1 1
0..* Item
Bill -
e ve ntDate: T im e sta m p e ve ntT ext: String e xp iratio nDa te: T im estam p n ewEventID: in t p ersonID: Inte ger
0..* -
billID: Integ er date Since : T im estam p date T ill: T im e stam p sta te: int 1 total: Dou ble ve rsio n: int
date T im e: T im estam p item ID: In tege r pho neNR: Strin g price: Dou ble se rvi ce Leng ht: in t se rvi ce T ype : Strin g type: in t versi on: in t
accoun t: Do uble active: bo olea n date OfBirth : Da te em a il: String firstn am e : Strin g lastnam e: S tring login Ba d: T im estam p login Last: T im estam p password : Strin g personID: In teger responsible Em ployee : Integ er usernam e: S tring versio n: in t 1
+responsible Em ployee 0 ..1
+personID 0 ..*
1
respo nsib leE m plo ye e Payment -
1 0..*
a cco untNum b erReceiver: S tring a m m o unt: Dou ble co nsta ntS ym bol: S tring p aid: Dou ble p aym en tDa te: T im estam p p aym en tID: Intege r p ersonID: Inte ger p urge Date: T im estam p spe cificS ym bo l: Strin g state : int va riable Sym b ol: S tring ve rsion : int
BankPayment -
PersonSetting
a m m o unt: Dou ble b ankPa ym entID: In teger co nsta ntS ym bol: S tring p ersonID: Inte ger spe cificS ym bo l: Strin g state : int tim e: T im estam p tim eInsert: T im e sta m p tra nsactionID: S tring va riable Sym b ol: S tring ve rsion : int
0..*
Obrázek 2: Business object model
23
0..* Priv ateCall -
de scription: S tring nu m be r: String pe rso nID: Integ er priva teCallID: Integ er
-
daysEven t: int eventDelS ub Person : boo lean eventNewBa nkPaym ent: b oole an eventNewBil l: boo lean eventNewPa ym ent: boo lean eventNewSu bP erso n: bo olea n lang : Strin g num berL ineIn T ab le: int payA ll: boo lean personS ettin gID: Integ er versio n: int
24
4 Návrh a implementace 4.1 Rozdělení aplikace do subsystémů Vzhledem k rozsáhlosti aplikace, bylo nutné systém rozdělit na několik subsystémů. Další motivací byla znovupoužitelsnost modulů pro parserování telefonních výpisů, bankovních výpisů a snaha o vytvoření jádra aplikace, které bude naprosto nezávislé na uživatelském rozhraní. Vznikly tedy následující moduly: PhoneParser – zajišťuje zpracování podrobných telefonních vyúčtování BankParser – zajišťuje zpracování bankovních výpisů Mailer – zajišťuje odesílání a stahování e-mailů PhoneISCore – zajišťuje komunikaci s databází, stará se o veškerou aplikační logiku PhoneIS_WAR – obsahuje prezentační vrstvu, zpracovává požadavky od uživatele
Diagram komponent na obrázku 3 zachycuje komunikaci mezi jednotlivými moduly. Nezávislost modulů je zajištěna tím, že se komunikuje pouze přes jasně definované rozhraní. V případě potřeby tedy není problém, aby byly jednotlivé moduly nasazeny na jiných serverech a komunikace probíhala např. použitím webových služeb [5] či pomocí tzv. vdáleného volání (RMI) [6]. Hlavní komponentou je modul PhoneISCore, který je jádrem celé aplikace. Poskytuje rozhraní pro komunikaci s prezentační vrstvou a využívá další 3 moduly – PhoneParser, BankParser a Mailer.
25
cmp PhoneIS
Database
Oracle Toplink
PhoneIS Core log4j
Phone parser
Mailer
Bank parser
PhoneIS_WAR
JSF Framework
JSF 1.2
JSF Managed Bean JSP Pages
Obrázek 3: Diagram komponent
26
ApacheMyFaces Trinidad
4.2 Prezentační vrstva Prezentační vrstva zajišťuje komunikaci s uživatelem. Stará se tedy o zobrazení dat a o zpracování uživatelských akcí. Protože se jedná o poměrně rozsáhlou aplikaci, bylo nutné zvolit vhodný framework, který usnadní a urychlí programování. Zvolil jsem JSF 1.2 [7]. S tímto frameworkem mám bohaté zkušenosti, jak ve své školní, tak i mimoškolní praxi. JSF bohužel neřeší všechny požadavky, které musel systém splňovat. Proto jsem použil další framework Apache MyFaces Trinidad [8], který doplňuje JSF o nové komponenty. Tento framework v prezentační části zajišťuje: nahrávání souborů (upload), řazení a stránkování tabulek, validaci formulářů a výběr datumu pomocí vlastní komponenty (pop-up okénko).
4.2.1 Lokalizace textů Veškeré texty, které prezentační vrstva zobrazuje, jsou uloženy v externím souboru (tzv. resource bundle). Jsou pojmenovány podle toho, jaký text zobrazují (např. popisek tlačítka, varovná hláška, chybová hláška, popisek v menu, atd.). Díky této konvenci a použití základních komentářů se soubor stává přehledným, dobře se v něm vyhledává a edituje. Pokud je uživatel přihlášen do aplikace, pak se mu zobrazí taková jazyková verze, kterou má uloženou ve svém osobním nastavení. V opačném případě se načte takový jazyk, který má uživatel ve svém prohlížeči nastavený jako preferovaný. Pokud aplikace tento jazyk nepodporuje, zobrazí se defaultní jazyk aplikace, tedy čeština. O toto se stará framework JSF. Přidání další jazykové verze je snadné. Stačí zkopírovat messages.properties (package cz.cvut.phone.gui.messages) a vytvořit ve stejném balíčku soubor messages_xx.properties, kde “xx” zastupuje označení jazyka (např. “cs” je čeština). Nakonec je nutné upravit facesconfig.xml dle následujícího příkladu:
<default-locale>cs <supported-locale>en <supported-locale>xx
4.2.2 JSF Managed Beany Aplikace obsahuje několik desítek managed bean. Za zmínku stojí dvě základní:
27
a) ApplicationController Tato beana je společná pro celou aplikaci (scope = application). Pomocí ní se přistupuje ke konstantním hodnotám, které jsou pro aplikaci společné a jsou inicializovány pouze jednou, a to právě v této třídě. b) UserBean Tato beana je pro každou session jedinečná (scope = session). Pomocí ní přistupujeme v aplikaci k ApplicationControlleru, k modulu aplikační logiky, uchováváme v ní informace o nastavení uživatele a udržujeme seznam informačních hlášek, které se zobrazí uživateli při načtení další stránky. Všechny ostatní managed beany mají referenci na UserBean a mohou k ní tedy přistupovat. Nastavení referencí i veškeré další nastavení managed bean se udržuje v souboru faces-config.xml.
4.2.3 Směrování stránek Přesměrování ze stránky na stránku se provádí pomocí tzv. navigačních stringů. Systém směrování demonstruje následující příklad: Po stisku tlačítka “Uložit” se zavolá funkce save() s návratovým typem String. JSF prohledají konfigurační soubor faces-config.xml. Pokud v něm najdou vrácený String, dojde k přesměrování na určenou stránku. Pokud je návratová hodnota null nebo pokud nebylo nalezeno žádné pravidlo, zobrazí se stránka, která akci vyvolala. public String save(){ // kod funkce return “home”; } Ukázka konfiguračního souboru (faces-config.xml):
/* home /home.jsp
4.2.4 Konfigurace vrstvy Všechny konfigurační soubory jsou umístěny standardně v adresáři web/web-inf.
28
Adresář obsahuje následující soubory: a) web.xml Základní nastavení aplikace jako je např. doba platnosti session, mapování servletů, maximální velikost nahrávaného souboru, atd. b) faces-config.xml Konfiguruje JSF. Jsou zde uloženy cesty k managed beanám a pomocí dependency injection jsou jim nastavovány některé paramtery. Dále je zde uveden seznam jazyků, které aplikace podporuje. Nachází se zde i veškeré navigační stringy a cesty ke konvertorům. c) sun-web.xml Zde je nastaven název aplikace, který se zobrazuje v URL. d) trinidad-config.xml Nastavení frameworku trinidad – validace formulářů, použití css skinů. e) trinidad-skins.xml Nastavení css stylu, ve kterém je překrytý defaultní styl, který obsahuje framework trinidad.
4.3 Aplikační vrstva Aplikační vrstva je jakýmsi prostředníkem mezi vrstvou prezentační a vrstvou datovou. Obsahuje veškerou business logiku aplikace. Stará se tedy o implementaci všech procesů v systému a zajišťuje transformaci dat mezi vstupními / výstupními požadavky a datovou vrstvou. Vrstva je tvořena šesti bezestavovými EJB session beanami [9], o jejichž inicializaci se stará výhradně aplikační server. Nachází se v modulu PhoneISCore v package cz.cvut.phone.core.fasade.*. Obsah session bean byl volen tak, aby spolu logicky souvisel a aby se kód nikde neopakoval. Takovéto rozdělení spolu s výstižnou jmennou konvencí zajišťuje celkovou přehlednost a snadnou čitelnost programu. Prezentační vrstva přistupuje k těmto třídám pouze z tříd ApplicationController a UserBean. Zápis v kódu prezentační vrstvy při volání aplikační vrstvy může vypadat např. takto:
29
public class UserBean { ... @EJB ViewFasadeLocal viewFasade; ... } Nikde v kódu se tedy nevyskytuje klíčové slovo „new“. Za zmínku také stojí to, že k session beanám přistupujeme zásadně přes rozhraní.
4.4 Datová vrstva Datová vrstva je umístěna stejně jako vrstva aplikační v modulu PhoneISCore. Nachází se v package cz.cvut.phone.core.data.*. Její součástí jsou entitní třídy, které obsahují JPA anotace. Každá třída odpovídá tabulce v databázi. K datům přistupujeme pomocí bezestavových EJB session bean. Až na výjímky platí to, že pro každou tabulku existuje jedna beana, která zajišťuje načtení dat – tedy vytvoření dotazu a jeho provedení. Tyto beany vracejí data v podobě entitních tříd. Nutno poznamenat, že data v této podobě se předávají pouze do aplikační vrstvy, kde jsou transformována do zástupných DTO (data transfer object) objektů a v případě potřeby předána do vrstvy prezentační. Transformace je nutná proto, aby bylo jádro zcela nezávislé na svém okolí, tedy aby případná změna databázových tabulek nemusela nutně znamenat i úpravu prezentační vrstvy. Mezi mnou implementovanou datovou vrstvou a samotnou databází se nachází vrstva knihoven objektově relačního mapovacího frameworku Oracle TopLink [10]. Tento nástroj zcela řeší objektově relační mapování. Díky tomu byl vývoj datové vrstvy výrazně usnadněný. Pro uchování dat byla zvolena databáze Apache Derby [11]. Zvolil jsem ji proto, že byla součástí instalace vývojového prostředí NetBeans IDE 6.1. Výhodné bylo zejména to, že přes vývojové prostředí je možné tuto databázi spravovat a není zapotřebí instalovat žádný jiný program pro administraci. Díky tomu, že se k databázi přistupuje pomocí JPA, lze použít téměř libovolnou relační databázi. Stačí jen vygenerovat inicializační SQL příkazy pro danou databázi a na aplikačím serveru upravit cestu k nové databázi. Model datové vrstvy, zachycený ve formě UML class diagramu, se nachází v příloze F
30
(/dokumentace/navrh/datovyModel/datovyModel.pdf).
4.5 Refaktorizace Protože celý systém vznikal poměrně rychle, docházelo v průběhu vývoje k chybám, které bylo nutné před dokončením opravit. Refaktorizace spočívala především v hledání nepoužívaných funkcí a optimalizování kódu tak, aby se pokud možno nikde neopakoval. V prezentační vrstvě bylo nutné upravit ty jsp stránky, které obsahovaly podobný obsah. Tento obsah byl vyjmut do externího souboru (.jspf – jsp fragment). Výraznější změny byly provedeny především v jádru aplikace. V datové vrstvě byla téměř pro každou databázovou tabulku vytvořena EJB session beana, která zajišťuje načítání dat z databáze. Toto řešení přispívá k větší přehlednosti a usnadní případné budoucí úpravy. Třídy aplikační vrstvy byly zbaveny již nepoužívaného kódu a některé funkce přepsány tak, aby jejich vykonání bylo rychlejší. Další podstatný zásah, který jsem provedl, spočíval v úpravě přístupu z vrstvy prezentační na vrstvu aplikační. Na počátku tvorby se do aplikační vrstvy přistupovalo pouze přes třídu ApplicationController. Toto řešení však nebylo správné, protože tato třída je společná pro celou aplikaci. Při větším počtu uživatelů by docházelo k nepřiměřeně vysokému zpomalení, protože jednotliví uživatelé by museli čekat na ukončení akce, kterou vyvolal jiný uživatel. Nové řešení spočívá v přesunutí referencí na aplikační vrstvu do třídy UserBean, která je pro každou session jedinečná [12].
31
32
5 Použité technologie 5.1 Java Server Faces JSF [7] je framework, který usnadňuje tvorbu webových aplikací v prostředí J2EE a je přímo propagován firmou Sun Microsystems. Hlavním důvodem vzniku frameworku, byla snaha odstínit vývojáře od běžných problémů při komunikaci přes protokol HTTP a také snaha jasně oddělit prezentační část od části aplikační – tedy vytvářet aplikace za použití architektury MVC (Model – View – Controller). Protože framework je orientován komponentově, můžeme pracovat na úrovni jednotlivýh UI komponent a posluchačů událostí. Toto nám umožní přistupovat k tvorbě prezentační části aplikace efektivním, objektově orientovaným způsobem.
5.2 Java Enterprise Edition Java Enterprise Edition [9] je součástí platformy Java, která je určena především pro vývoj rozsáhlých podnikových a informačních systémů. Základem platformy J2EE je platforma J2SE. Pod pojmem J2EE se skrývá mnoho dalších technologií, které jsou vytvářeny spoluprací více firem v rámci tzv. Java Community Process [13]. Mezi tyto technologie patří např. specifikace pro vývoj webových aplikací (JSF), vývoj sdílené buseness logiky (EJB), podpora technologií webových služeb apod.
5.3 GlassFish Application Server GlassFish [14] je aplikační server vyvinutý firmou Sun Microsystems pro platformu J2EE. Jeho zdrojové kódy jsou otevřené a jeho použití je bezplatné. Od verze V2 je integrován do NetBeans IDE, což výrazně zpříjemňuje vývoj a urychluje deploy vyvíjené aplikace. Nabízí mnoho užitečných funkcí mezi které patří např. zajištění připojení k databázi, autentifikace uživatelů, odesílání a příjem e-mailů, provádění asynchroních operací či monitoring aplikací. Jeho správa je příjemná, neboť součástí distribuce je webová administrační konzole.
33
34
6 Testování Testování aplikace bylo poměrně náročné. Jedním z důvodů je rozsáhlost aplikace a také fakt, že se pracuje s často se měnícími daty. Výsledky mnohých akcí jsou závislé jednak na osobním nastavení uživate, dále na nastavení firmy a na tom, co konkrétního daný uživatel v systému provedl. Pro kontrolu správnosti jednotlivých funkcí byly použity unit testy. Ty však nepokryly všechny situace, které v systému mohou nastat a proto bylo nutné provést i „ruční test“. K tomuto účelu vznikla testovací data s testovacím scénářem, která můžete nalézt v příloze F (/DB/testovaciData/TestovaciScenar.pdf). Z časových důvodů bohužel nebylo důkladně testováno stahovaní bankovního výpisu z e-mailové schránky. V případě používání této funkce bude zapotřebí vypracovat testovací scénář a prověřit, že při komunikaci s e-mailovou schránkou nedochází k žádným problémům.
6.1 Unit testy Cílem unit testů [20] je izolované otestování částí programu (jednotek) a prokázaní, že jednotlivé individuální části kódu jsou správné. Jednotka je nejmenší testovatelná část programu. V objektově orientovaném programování se jednotkou programu myslí třída či metoda. Izolovanosti jednotky lze dosáhnout např. použitím pomocných objektů (tzv. Mock objektů [21]), které nahrazují třídy (případně i celé subsystémy), jenž daná jednotka potřebuje ke své funkčnosti. Průběh testu spočívá ve vytvoření testovacích vstupů a výstupů pro jednotku a její zavolání. Po provedení se výsledek jednotky porovná s očekávaným výsledkem. Pokud se výsledky liší, pak testovaná jednotka nepracuje správně. Pro provedení testů jsem si vzolil framework JUnit [17]. Hlavním důvodem byla jeho výborná podpora v IDE a dále to, že s tímto frameworkem jsem již nějaké zkušenosti měl. Testy byly psány pro oba moduly, které jsem programoval – tedy pro modul PhoneISWar a PhoneISCore. Některé z testů byly psány již v průběhu vývoje, většina však až po jeho ukončení. V testech jsem se snažil především odhalit chyby, které by mohly způsobit úplný pád programu – tzn. hledal jsem především neinicializované objekty a soustředil se na návratové hodnoty funkcí. Psaní unit testů pro platformu J2EE se od platformy J2SE značně liší. Následující
35
příklad obsahuje ukázku kódu psaného v prostředí J2EE: public class AccountFasade implements AccountFasadeLocal { … @EJB PersonFasadeLocal personFasade; … public String doSomething(){ return personFasade.doSomething(); } } V kódu vidíme, že proměná personFasade není nikde inicializovaná pomocí klíčového slova „new“, přesto je v kódu použita a program může pracovat zcela korektně. Vytvořímeli nyní následující testovací třídu: public class AccountFasadeTest { @Test public void doSomethingTest{ AccountFasade fasade = new AccountFasade(); String result = fasade.doSomething(); assertNotNull(result); } } Pokud bychom nyní test spustili, nastala by chyba NullPointerException, a to přesto, že stejná metoda zavolaná při standardním běhu aplikace by vracela správný výsledek. Důvod je prostý. Pokud aplikace běží na aplikačním serveru, postará se o inicializaci proměnné personFasade právě aplikační server. V testovacím režimu se pouze vytvoří instance třídy a proměná personFasade zůstává neinicializovaná. Tento problém jsem vyřešil použitím zástupných objektů. Při testování prezentační vrstvy bylo nutné vytvořit zástupné objekty pro všechny třídy aplikační vrstvy. Jejich vytvoření bylo poměrně jednoduché. Stačilo vytvořit třídu, která implementovala stejné rozhraní, jako třída aplikační vrstvy. Tato třída byla před spuštěním každého testu „nasetována“ do příslušné testované třídy. Díky unit testům jsem odhalil některé drobné chyby a na mnohých místech upravil metody tak, aby více testovaly vstupní parametry. Protože testování jednotek vyžaduje izolovanost dané jednotky, bylo psaní testů do značné míry i testem toho, zda je aplikace
36
správně členěna do logických celků. Pokud by aplikace nebyla navržena správně, bylo by težké vytvářet zástupné objekty. Díky tomu, že se komunikace mezi vrstvami provádí pomocí jasně definovaných rozhraní, nebyla tvorba zástupných objektů složitá a zásahy do kódu byly minimální.
6.2 Výkonnostní testy Výkon aplikace jsem testoval pomocí nástroje NetBeans Profiler [15]. Mezi hlavní funkce tohoto nástroje patří monitorování JVM a profilování výkonu a paměti. Profiler umožňuje testovat buď celou aplikaci nebo pouze její část (modul). Dokonce je možné testovat pouze určitý fragment kódu. Z velkého množství informací o výkonu aplikace pro mě byla nejpodstatnější tabulka, ve které byly zobrazeny všechny metody, které se volaly a doba jejich trvání. Při testování výkonu jsem se zaměřil především na vkládání telefonního vyúčtování. Již v průběhu analýzy a návrhu bylo zřejmé, že tato operace bude časově náročná a výkonnostní testy to potvrdily. Náročnost je dána tím, že pro každou položku vyúčtování se hledá osoba, která v daném okamžiku používala telefonní číslo jehož vyúčtování se zpracovává. Posloupnost akcí při sledování byla následující: 1. Přihlášení do aplikace 2. Vložení telefonních výpisů (.zip soubor - celkem 974 položek ve 4 vyúčtováních)
Obrázek 4 obsahuje výsledek, který poskytl NetBeans Profiler. Funkce jsou seřazeny podle celkového času od nejdéle trvající. Je zřejmé, že systému nejdéle trvá zjištění osoby, která používala telefon a také časté zjišťování, jestli byla daná osoba zaměstnána či nikoliv. Nelze zanedbat ani dotazy do databáze, které hledají cílové číslo v seznamu vždy soukromých čísel.
37
Obrázek 4: NetBeans Profiler - výsledek testu
Je nutné si uvědomit, že uvedené časy nejsou při opakování testu stejné. Test jsem prováděl celkem 5x. Největší naměřená odchylka u celkových časů odpovídá přibližně 5%. Na základě těchto výsledků, jsem se snažil zoptimalizovat některé funkce. Výsledek však byl zanedbatelný. Dalším nápadem, jak celou aplikaci zrychlit, bylo přidání indexů na databázové sloupečky, podle kterých se vyhledává. Přidal jsem tedy indexy do následujících tabulek (tabulka - sloupeček): 1. PersonPhoneNumberMap – beginuse, enduse 2. Employee – begin, end 3. PrivateCall - number Výsledek byl pro mě dost překvapující, protože doba trvání tří nejdéle trvajících metod byla přibližně o 4% vyšší než před nastavením indexů. Proto ani toto řešení nepomohlo. Podobným způsobem jsem analyzoval i akce generování plateb a vložení bankovního výpisu. Tyto akce jsou však v porovnáním s vložením telefonního vyúčtování z hlediska časové náročnosti zanedbatelné. Poslední test spočíval v procházení aplikace a prováděním náhodných editací v sekci administrace. Při tomto testu jsem nezjistil žádné neobvyklé chování.
38
6.3 Zátěžové testy Zátěžové testy jsem prováděl pomocí programu Apache JMeter [16]. Pomocí tohoto programu lze vytvářet specifické testy, které simulují reálnou zátěž během provozu. Tvorba samotného testu je jednoduchá. Stačí vytvořit tzv. ThreadGroup, ve kterém se nastaví počet spouštěných vláken a počet jejich opakování. Do ThreadGroup se přidá http request a dále prvky, které zaznamenávají průběh testu. Problém nastává v okamžiku, kdy chceme testovat web psaný v JSF. Tento framework do HTML stránky vkládá speciální pole, které zachycují stav aktuální stránky. Pokud tedy chceme testovat např. načtení formuláře a jeho následné odeslání, musíme tyto parametry znovu odeslat na server. Tento problém se mi nepodařilo vyřešit, což mi ovšem nebránilo v provádění testů pokračovat. Pouze jsem při testování data z aplikace pouze stahoval, ale už neposílal zpět ke zpracování. Testovány byly dva případy – zobrazení stránky registrace a dále načtení osob z databáze. Pro načtení osob z databáze jsem vytvořil testovací jsp stránku a JSF ManagedBeanu. Stránka po načtení automaticky vyhledala osoby v databázi. Bohužel se mi nepodařilo sehnat vhodný počítač, který bych použil jako server. Proto jsem musel spouštět test ze stejného počítače, na kterém byla aplikace nasazena. Tento způsob není příliš vhodný, protože může zkreslovat výsledek. Samotné spuštění testu je poměrně náročné na výkon. Parametry počítače: Intel(R) Core(TM)2 Duo CPU @ 2.20 GHz 2 GB RAM 32 bitový Windows Vista Home Premium V následujícím odstavci bude popsán test zobrazení stránky registrace. Při testu bylo spuštěno 50 vláken. Každé z nich celkem 30x zaslalo požadavek na zobrazení stránky registrace.jsp. Při testování jsem sledoval především průměrnou dobu odezvy a propustnost. Jak je vidět na následujících obrázcích, byla průměrná doba odezvy 2597 ms a propustnost 1120 requestů/minutu. Celý test trval přibližně 80 sekund.
39
Obrázek 5: JMeter - výsledek testování - zobrazení stránky registrace.jsp (graf)
Obrázek 6: JMeter - výsledek testování - zobrazení stránky registrace.jsp (tabulka)
Tyto výsledky nejsou příliš dobré. Požadavky na dnešní J2EE aplikace většinou říkají, že doba odezvy uživatelské transakce nesmí přesáhnout 3 sekundy nebo že 90% všech odezev by nemělo trvat déle než 1 sekundu [22]. Přesto je nutné si uvědomit, že zátěž byla poměrně veliká – za 80 sekund bylo obslouženo 1500 requestů. V reálném produkčním prostředí by byla aplikace nasazena na výkonnějším serveru a rychlost by se výrazně zvýšila. Z hlediska propustnosti nedopadl test nejhůře.
40
7 Závěr 7.1 Splnění zadání Jsem přesvědčen o tom, že zadání bylo splněno. Implementoval a otestoval jsem systém, který usnadní vyúčtování telefonních hovorů a bude své uživatele upozorňovat na nové události. Vznikla tak plně funkční aplikace, která může být okamžitě používána a tedy i nasazena do produkčního prostředí. I přes poměrně velké úsilí se mi nepodařilo implementovat časovač, který by zajišťoval automatické generování platebních příkazů a stahování bankovních výpisů z e-mailu. Posledním drobným nedostatkem je chybějící přehled vygenerovaných platebních příkazů a přehled telefonních čísel. Jejich vytvoření však zabere minimum času. O těchto nedostatcích jsem informoval vedoucího práce.
7.2 Doporučení pro další vývoj Byl bych velmi nerad, kdyby tento projekt skončil „v šuplíku“, a proto se na jeho vývoji budu podílet i nadále. Další rozvoj by měl zahrnout dopracování sekce přehledy a vytvoření nové sekce statistiky, ve které by bylo možné generovat základní reporty. Dále bude nutné jádro aplikace spojit s upraveným subsystémem BankParser, který v současné době vzniká jako osamocený modul. Komunikace s ním bude probíhat za pomoci webové služby. Další vývoj by neměl opomenout ani možnost automatického generování platebních příkazů a stahování bankovních výpisů z e-mailu. Je pravděpodobné, že výše uvedené akce budou kvůli časové náročnosti muset být prováděny asynchroně, tedy tak, aby aktér, který události vyvolá, nemusel čekat na jejich dokončení.
7.3 Přínos pro autora Práce na tomto systému pro mě byla velmi přínosná. Jednalo se o největší školní softwarový projekt, který jsem doposud vyvíjel. Naučil jsem se pracovat v týmu a mnoho technologií, které jsem použil, bylo pro mě nových. Díky tomu již nebudu mít strach z projektů, které mě v budoucnu čekají. Navíc se budu moci opírat o nabrané zkušenosti a to jak dobré, tak špatné.
41
42
8 Literatura Seznam použitých zdrojů 1: Enterprise Architect. Dostupný z WWW: http://www.sparxsystems.com.au/products/ea/index.html 2: Netbeans IDE. Dostupný z WWW: http://www.netbeans.org/ 3: Tardat 4.[cit. 12.1.2009]. Dostupný z WWW: http://www.tartek.cz/tardat4.html 4: WINTEL.[cit. 12.1.2009]. Dostupný z WWW: http://www.ateco.cz/wint_pop10.asp 5: Web Services Tutorial. Dostupný z WWW: http://w3schools.com/webservices/default.asp 6: RMI. Dostupný z WWW: http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp 7: Java Server Faces. Dostupný z WWW: http://java.sun.com/javaee/javaserverfaces/ 8: Apache MyFaces Trinidad. Dostupný z WWW: http://myfaces.apache.org/trinidad/ 9: EJB Tutorial. Dostupný z WWW: http://java.sun.com/developer/onlineTraining/Beans/EJBTutorial/ 10: Oracle TopLink. Dostupný z WWW: http://www.oracle.com/technology/products/ias/toplink/index.html 11: Apache Derby. Dostupný z WWW: http://db.apache.org/derby/ 12: Refactoring. Dostupný z WWW: http://www.refactoring.com/ 13: Java Community Process. Dostupný z WWW: http://jcp.org/en/home/index 14: GlassFish. Dostupný z WWW: https://glassfish.dev.java.net/ 15: NetBeans Profiler. Dostupný z WWW: http://profiler.netbeans.org/ 16: Apache JMeter. Dostupný z WWW: http://jakarta.apache.org/jmeter/ 17: JUnit. Dostupný z WWW: http://www.junit.org/ 18: ARLOW, Jim, NEUTSADT, Ila. UML 2 a unifikovaný proces vývoje aplikací. Computer Press, 2007. ISBN: 978-80-251-1503-9 19: GEARY David, HORSTMANN Cay. Core JavaServerFaces, Second edition. Prentice Hall, 2007. ISBN: 0-13-173886-0 20: Unit testing. Dostupný z WWW: http://en.wikipedia.org/wiki/Unit_testing 21: Mock Objects. Dostupný z WWW: http://www.mockobjects.com/ 22: Monitoring J2EE aplikací. Dostupné z WWW: http://www.komix.cz/csCZ/Produkty/Konzultace.aspx#Monitoring_J2EE
43
44
9 Seznam příloh A Instalační manuál.......................................................................................... 1 B Zprovoznění vývojového prostředí............................................................... 3 C Uživatelský manuál.......................................................................................15 D Use Case Document .....................................................................................25 E UML diagramy..............................................................................................51 F Přiložené CD.................................................................................................55
45
46
A Příloha – Instalační manuál 1) Úvod Tento dokument stručně popisuje postup instalace informačního systému OpenPhone na server. Odkazuje se na dokument „Zprovoznění vývojového prostředí“ a na webové instalační návody.
2) Postup instalace 1 . Instalace DB serveru Apache Derby (podrobný návod včetně aktuální verze: http://db.apache.org/derby/papers/DerbyTut/install_software.html) 1.1 Instalace JDK (Java Development Kit) 1.2 Instalace Apache Derby 1.3 Konfigurace Apache Derby 2 . Vytvoření databáze a vložení dat 2.1 Vytvoříme databázi, kterou pojmenujeme „PhoneIS“ 2.2 Vytvoříme databázové tabulky, tzn. spustíme obsah souboru init.sql (přiložené CD: /DB/init.sql) 2.3 Vložíme základní data, tzn. spustíme obsah souboru init_nutna_data.sql (přiložené CD: /DB/init_nutna_data .sql) 3 . Instalace
aplikačního
serveru
GlassFish
(aktuální
verze
zde:
https://glassfish.dev.java.net/public/downloadsindex.html) 4 . Vytvoření Connection poolu (viz. Zprovoznění vývojového prostředí systému OpenPhone, kapitola 4) 5 . Vytvoření JDBC resource (viz. Zprovoznění vývojového prostředí, kapitola 5) 6 . Deploy aplikace (viz. Zprovoznění vývojového prostředí, kapitola 6) 7 . Pokud jsme aplikaci úspěšně nahráli na aplikační server, bude možné ji spustit. URL bude mít tvar: http://server:port/PhoneIS_WAR.
1
2
B Příloha – Zprovoznění vývojového prostředí 1) Úvod Tento dokument by měl usnadnit práci vývojářům systému OpenPhone. Popisuje kroky, které jsou nutné provést při zprovoznění vývojového prostředí. Protože se jedná o J2EE aplikaci, je možné, že pro osobu, která se setkává s touto platformou Javy poprvé, může být problém ji zprovoznit. Tato příručka nemůže popisovat všechny neočekávané situace, které mohou nastat. Snaží se však odpovědět na známé problémy, se kterými jsem se nejen jako tvůrce produktu setkal. Manuál popisuje pouze deploy a build aplikace pomocí NetBeans IDE 6.1. Je však samozřejmě možné použít novější IDE.
2) Instalace a) Instalace NetBeans 6.1 + GlassFish V2 + Java DB (doporučeno) Ve složce /IDE na přiloženém CD se nachází inslační soubor pro NetBeans 6.1 pro prostředí windows. Postup instalace je zbytečné detailně popisovat. Pouze upozorňuji, že je nutné nainstalovat i aplikační server GlassFish a zapamatovat si heslo, které při instalaci zadáváme. Standardní login je admin/adminadmin. b) Instalace GlassFish V2 a jeho přidání do NetBeans 6.1 Pokud již máme nainstalován NetBeans, ovšem chybí nám aplikační server GlassFish, můžeme spustit jeho inslaci. Inslační soubor se nachází také na přiloženém CD ve složce /IDE. Po dokončení instalace spustíme NetBeans a přidáme server. Postup: Tools → Servers. Dole vlevo tlačítko „Add Server...“. Zvolíme GlassFishV2 → Next → vybereme cestu (např. C:\Program files\glassfish-v2ur2) → Next.
3) Vytvoření databáze a vložení dat Prostředí NetBeans nám umožňuje vytvořit a spravovat databázi Apache Derby. Postup vytváření je následující: Klikneme na záložku Services (standardně vlevo, pokud jí nevidíme, zobrazíme ji: Windows → Services). Rozbalíme položku Databases. Klikneme
3
pravým tlačítkem myši na JavaDB a vybereme položku „Create database“. Databázi pojmenujeme „PhoneIS“. Username a password necháme prázdné (pokud je chcete vyplnit, je nutné je zadat i při vytváření Connection poolu – viz. dále). Nyní v seznamu databází uvidíme i naši vytvořenou databázi. Klikneme na ní pravým tlačítkem a zvolíme položku „Connect“. Po připojení uvidíme po rozkliknutí naší datábáze 3 položky: Tables, View, Procedures. Klikneme pravým tlačítkem myši na naši databázi a zvolíme „Execute Command“. Zobrazí se nám záložka, do které vložíme obsah souboru init.sql z přiloženého CD (/DB/init.sql) a spustíme vložení kliknutím na tlačítko „Run SQL“ (viz. obrázek). Po prvním spuštění skončí tento skript s chybami, protože se snaží odstranit neexistující tabulky. Pokud ho spustíme znovu, bude vše v pořádku (u jednoho kolegy jsem dokonce viděl, že tato akce skončí úspěšne až napotřetí, poté již je vše vpořádku a pokud se skript spustí znovu, je akce úspěšná hned). Dále je nutné vložit základní data, bez kterých nemůže aplikace pracovat. Ta jsou uložena v souboru /DB/init_nutna_data.sql. Vložení probíhá obdobným způsobem. Databáze je nyní vytvořena a připravena k použití. Nyní např. můžeme vidět vytvořené tabulky – kliknutím na položku „Tables“ (pokud tabulky nejsou vidět, klikněte pravým tlačítkem na položku tables a zvolte možnost „refresh“). Následují obrázky, které názorně ukazují postup předchozí akce.
4
5
6
4) Vytvoření Connection poolu Spustíme GlassFish: Pravým tlačítkem klikneme v NetBeans na aplikační server a zvolíme položku start. Po spuštění klikneme opět pravým tlačítkem myši na aplikační server a vybereme položku „View Admin Console“. V internetovém prohlížeči se zobrazí stránka s přihlašovacím formulářem. Vyplníme do ní údaje, které jsme zadávali při instalaci (dafaultně admin/adminadmin). Po přihlášení v menu: Resources → JDBC → Connection Pools. Stiskneme tlačítko „New“. Vyplníme: Name: derby_netPool, Resource type: javax.sql.Datasource, Database vendor: Derby. Stiskneme „Next.“ Zkontrolujeme, že políčko resource type obsahuje hodnotu:
7
„org.apache.derby.jdbc.ClientDataSource“. Všechny hodnoty necháme defaultně, upravíme pouze spodní tabulku „Additional properties“. Nastavíme políčka: DatabaseName: PhoneIS User: app Pass: app Port: 1527 (Toto je defaultní port, na něm obvykle databáze běží. Vypisuje např. při prvním připojení k nějaké databázi v NetBeans – dole v logu – Output JAVA DB Database Process). ServerName: localhost Vytvoříme property „driverClass“ a přiřadíme ji hodnotu „org.apache.derby.jdbc.ClientDriver“. Vytvoříme property „URL“ a přiřadíme ji hodnotu „jdbc:derby://localhost:1527/PhoneIS“ (případně upravte port a název databáze). Ostatní políčka necháme prázdná a stiskneme tlačítko „Finish“. Po vytvoření bychom po kliknutí na nově vytvořený connection pool měli v záložce Additional properties vidět následující hodnoty:
Následující obrázky popisují průběh výše popsané akce:
8
5) Vytvoření JDBC resource V admin consoli v menu: Resources → JDBC → JDBC Resources. Stiskneme tlačítko „New“. Vyplníme: JNDI Name: PhoneISJNDI poolName: derby_netPool zaškrtneme status enable Stiskneme tlačítko ok a JDBC resource se vytvoří.
9
6) Deploy aplikace – ruční nahrání archivu na server Na přiloženém CD ve složce /src/dist nalezneme soubor, který se musí nahrát na server. V admin consoli zvolíme v menu: applications → enterprise applications a stiskneme tlačítko „Deploy...“. Zadáme cestu k archivu a stiskneme tlačítko ok. Pokud jsme správně vytvořili connection pool a jdbc resource, bude aplikace vystavena bez chyby a připravena k použití. Aplikaci je v tomto momentě možné otevřít na adrese: localhost:port/PhoneIS_WAR. Port zadejte takový, jako při instlaci (např. 8080 - http nebo 8181 - https). Nyní je ještě nutné nakopírovat konfigurační xml soubory modulu PhoneParser do složky config aplikačního serveru. Zkopírujte celou složku templates z přiloženého cd (/src/ PhoneIS/PhoneParser/) na aplikační server (... personalDomain1\personalDomain\config\).
7) Otevření a úprava cest v NetBeans V NetBeans si otevřete všechny moduly (File → Open project... → označtě moduly → Open Project) , tedy: BankParser, Mailer, PhoneIS, PhoneIS_WAR, PhoneISCore a PhoneParser. Nyní bude nutné ručně upravit cesty ke knihovnám a případně i cestu k aplikačnímu serveru. Pravděpodobně bude nutné provést některé z následujících akcí: Pravý klik na BankParser → Resolve Missing Server Problem... → Vybrat GlassFishV2 → ok Pravý klik na Mailer → Resolve Missing Server Problem... → Vybrat GlassFishV2 → ok Přidání knihoven - je možné, že NetBeans nenajde všechny potřebné knihovny, pak je nutné
10
kliknout pravým tlačítkem na modul, na jehož ikoně bude žlutý vykřičník a vybrat volbu resolve problems. NetBeans nabídne seznam knihoven, které nemůže najít. Knihovny se až na výjimky nalézají v kořenovém adresáři každého modulu v podadresáři “lib”. (Výjímkou je např. Knihovna log4j-1.2.15.jar, která je potřebná v modulu PhoneISCore, ale nachází se v adresáři modulu PhoneIS. Ovšem knihovnu log4j-settings.jar je nutné vybrat z adresáře lib modulu PhoneISCore). Pokud jste správně přidali všechny cesty, je možné provádět build a deploy aplikace přímo z prostředí NetBeans. Nastavíme modul PhoneIS jako hlavní projekt (pravý klik na PhoneIS → Set as Main Project). Nyní klikneme na zelenou šipku nahoře (Run Main Project), provede se build a deploy na aplikační server. Následující obrázky popisují výše popisovanou akci:
11
12
13
14
C Příloha – Uživatelský manuál 1) Úvod Tento dokument by měl usnadit práci uživatelům systému OpenPhone a měl by sloužit jako nápověda. Zobrazuje přehled a popis akcí, které lze se systémem vykonávat.
2) Administrace aplikace 1) Na úvodní stránce vyberte položku administrace. 2) Přihlašte se pomocí uživatelského jména a hesla (původní nastavení: admin/1234). Banky V této sekci se nastavují podporované banky. Tento seznam však nemá vliv na samotné parserování bankovních výpisů. Má význam pouze při registraci nové firmy. Při ní se v combo boxu zobrazí seznam kódů bank, které registrující vyplní. Jazyky V této sekci se nastavují podporované jazyky. Seznam jazyků se zobrazuje při registraci firmy, dále pak v nastavení firmy a v uživatelském nastavení. Pokud tedy přeložíme aplikace do nového jazyka, je nutné, kromě samotného přeložení a nastavení ve facesconfig.xml, přidat jazyk i sem, aby bylo možné ho nastavit. Změna hesla V této sekci si superadmin může změnit heslo. Heslo se do databáze ukládá zašifrované. Nastavení V této sekci se nastavují parametry připojení pro server odchozí pošty. Je potřeba vyplnit alespoň adresu smtp serveru a port smtp serveru. Pokud váš smtp server vyžaduje autentifikaci, je potřeba vyplnit i username a heslo. Aplikace prozatím odesílá e-maily jen při registraci firmy, takže toto nastavení pro vás nemusí být příliš důležité. Firmy V této sekci můžete vidět seznam registrovaných firem a můžete je také smazat.
15
3) Registrace 1) Na úvodní stránce vyberte položku registrace. 2) Vyplňte všechny položky formuláře. 3) Odešlete formulář. 4) Pokud je správně nastaven server odchozí pošty, měla by na e-mailovou adresu administrátora přijít zpráva s přihlašovacími údaji. Po registraci systém zobrazí ID pro vaši firmu. Toto číslo je nutné znát, protože pomocí něho bude probíhat přihlášení do aplikace. Poznámky k položkám formuláře: defaultní jazyk – jazyk, který bude nastavován vytvářeným uživatelům defaultní ceny – ceny, které budou účtovány v případě, že hovor bude soukromý a účtovaná cena od operátora bude 0
4) Přihlášení do aplikace 1) Vyplňte uživatelské jméno 2) Vyplňte číslo, které aplikace přiřadila vaší firmě 3) Vyplňte heslo 4) Odešlete formulář
5) Úvodní stránka Na této stránce vidíme datum posledního úspěšného a neúspěšného přihlášení. Dále je zde přehled nových udáslotí. Tato stránka se aktualizuje pouze po přihlášení do aplikace. Tzn., že pokud po našem přihlášení vznikne nějaká nová událost, systém ji zobrazí až po dalším přihlášení!
16
6) Sekce „Moje“ Označení hovorů Na této stránce se v tabulce zobrazí telefonní vyúčtování, které je možné zobrazit. Tzn., že zde budou do té doby, než někdo nezadá příkaz k vygenerování platebního příkazu. Postup je následující: 1) Vybrat si vyúčtování, které chceme označit a vybrat volbu „Detail“. 2) Označíme hovory, které byly soukromé. Pokud označíme sloupeček „vždy soukromý“, dojde k označení vybraného hovoru a navíc pokud v dalším období budeme volat na toto číslo, budou odchozí položky na toto číslo předoznačeny jako soukromé. 3) Stiskneme tlačítko uložit. Pozn.: Pokud má nějaká položka nastavenu cenu 0 a bude označena jako soukromá, neznamená to, že za ni nebudeme nic platit! Při generování platebních příkazů se systém pokusí nastavit takové položce defaultní cenu.
17
Telefonní vyúčtování V této sekci se můžeme podívat na naše vyúčtování. Pokud jsou v systému nějaké osoby, za které odpovídáme, je možné zobrazit i jejich vyúčtování. V takovém případě stačí zaškrtnout checkbox „Zobrazit účty příbuzných“. Příchozí platby V této sekci můžeme zobrazit naše příchozí platby. Jedním ze sloupečků u plateb je stav. Stav potvrzená znamená, že naše příchozí platba byla do systému zadána ručně nebo ze souboru, který byl vložen ručně. Pokud má naše platba stav nepotvrzená, znamená to, že byla vložena z bankovního výpisu, který systém stáhnul z e-mailu. Vyhledávací filtr: políčko od = datum připsání na účet Platební příkazy
18
V této sekci můžeme zobrazit naše platební příkazy. Pozn. k platbám: Pokud se vám stane, že zaplatíte za telefony víc, než jste ve skutečnosti protelefonovali, přebytek se připíše na vaše osobní konto. V okamžiku dalšího generování platebních příkazů se tato částka vezme a připíše se k zaplacené částce. Vyhledávací filtr: políčko od = datum vytvoření platebního příkazu Soukromá čísla V této sekci můžete editovat seznam čísel, která budou v telefonním vyúčtování předoznačena jako soukromá. Toto vám usnadní práci při označování hovorů. Telefonní čísla je do systému nutné zadávat i s předvolbou – tedy pro ČR 420. Osobní údaje V této sekci můžete vidět své soukromé informace. Nastavení V této sekci můžete editovat své osobní nastavení. Počet řádků v tabulkách – počet řádků, které chcete zobrazit v tabulkách (např. při označování hovorů, v příchozích platbách atd.) Platit účty příbuzným – pokud máte označeno ano, systém při generování platebního příkazu pro vašeho příbuzného nastaví platbu tak, aby jste ji platil vy. V praxi to znamená, že pokud máte v systému jednu příbuznou osobu, která má stejně jako vy jedno telefonní číslo, systém vám při generování platebních příkazů vygeneruje příkazy 2 (se stejným variabilním symbolem). Vy je můžete zaplatit jedním platebním příkazem. Platnost nové událost – počet dní, po které se bude v databázi udržovat nová událost. Po vypršení této doby bude nová událost ze systému smazána. Upozornění – nastavení, zda chcete upozornit na daný typ události Změna hesla V této sekci můžete své heslo. Heslo se do databáze ukládá zašifrované.
19
7) Sekce „Účty“ Vložit telefonní účet V této sekci můžete vložit soubor s telefonním vyúčtováním. Je možné vložit jeden soubor nebo archiv (.zip) s více soubory. Informace z dokumentace PhoneParseru: PhoneParser dokáže zpracovat podrobná vyúčtování ve formátech .xls a .csv. Ta mohou být dodána hromadně ve formě .zip archívu. V archívu mohou být vyúčtování od více operátorů
najednou,
je
dovolena
adresářová
struktura
i
další
.zip
archívy.
Podrobná vyúčtování ve zpracovatelné elektronickí podobě získáme obvykle z internetových stránek operátora, po přihlášení ke svému účtu. Vložení telefonního účtu může trvat déle (minuty) v závislosti na množství vkládaných dat. Po nahrání souboru na server se provede nejprve načtení jednotlivých položek, které jsou dále zpracovávány (systém se je snaží předoznačit, aby měl uživatel snažší práci).
Vložit bankovní výpis V této sekci můžete vložit bankovní výpis v textovém souboru. Informace z dokumentace BankParseru: Komerční banka: formát souboru .txt, výpis může být za určité období stáhnutelný z
20
internetového bankovnictví (Hlavní menu > Výpisy transakcí) mBank: formát souboru .txt, výpis může být stáhnutelný z internetového bankovnictví (lze si nechat posílat mšsíční výpisy e-mailem). Po vložení bankovního výpisu se provádí párování plateb. Tato operece je však mnohem rychlejší, než vložení telefonního výpisu.
Generování plateb V této sekci můžete spustit akci generování plateb. Systém začne zpracovávat telefonní vyúčtování a v případě, že osoba označila některé hovory jako soukromé, vygeneruje aplikace dané osobě příkaz k úhradě. Políčko „datum do“ určuje, které telefonní učty se mají zpracovat. Pokud do systému např. vložíme vyúčtování za leden a únor roku 2009 a chceme vygenerovat pouze lednové platby, zadáme do políčka datum 1.2.2009.
Zadat příkaz k úhradě V této sekci můžete ručně vytvořit příkaz k úhradě. 1) Zadejte příjmení (nebo jeho část) osoby, pro kterou chcete příkaz vytvořit. 2) Stiskněte tlačítko hledat. 3) Vyberte z nalezených osob správnou osobu a stiskněte tlačístko vybrat. 4) Upravte předvyplněné údaje a odešlete formulář.
Zadat příchozí platbu V této sekci můžete ručně zadat příchozí platbu. Postup je obdobný jako při vytváření příkazu k úhradě.
8) Sekce „Přehledy“ Přehledy vyúčtování V této sekci můžete zobrazit telefonní vyúčtování, které jsou uloženy v systému.
21
Zobrazená cena přesně odpovídá ceně, kterou vyúčtoval operátor. Je však možné, že se osobě která telefon používala, vygeneroval příkaz k úhradě na částku vyšší než vidíte. Pokud cena hovoru nebo sms byla 0, systém vypočetl cenu pomocí defaultních cen, které jsou uloženy v nastavení firmy. Přehled osob V této sekci můžete zobrazit osoby, které jsou uloženy v systému.
Přehled příchozích plateb V této sekci můžete zobrazit příchozí bankovní platby.
9) Sekce „Administrace“ Firma V této sekci můžete editovat základní údaje o vaší firmě. Oddělení V této sekci můžete editovat oddělení vaší firmy. Smazat lze pouze takové oddělení, ve kterém nejsou žádní zaměstnanci. Role V této sekci můžete editovat uživatelské role. Role nemusí mít přiřazenou žádnou operaci. V takovém případě bude uživatel s touto rolí vstupovat pouze do sekce „Moje“. Názvy operací jsou výstižné. Každá operace opravňuje uživatele s příslušnou rolí vstoupit na danou stránku. Vytvořenou roli je možné smazat pouze v případě, že jí nemá přiřazenou žádný z uživatelů. (pozn. každý uživatel musí mít přiřazenou alespoň jednu roli). Aktulalizace operací u role se projeví až po dalším přihlášení uživatele.
Osoby V této sekci můžete editovat osoby v systému. Následuje popis položek formuláře: e-mail: pouze informativní údaj, aplikace zatím uživatelům žádné e-maily (kromě e-
22
mailu administrátorovi při registraci firmy) nezasílá. Aktivní: aktivní zaměstnanec se může přihlásit do aplikace. Zneaktivnění znamená, že se zaměstnanci odeberou všechna telefonní čísla, která používá. Od okamžiku zneaktivnění se uživatel nebude moci přihlásit k systému. Stav: a) zaměstnanec: Zaměstnanec může nést odpovědnost za jiné osoby (nezaměstnance). Při vložení telefonního výpisu se zaměstnanci předoznačí hovory jako soukromé (pokud se cílové telefonní číslo nenalezne na seznamu vždy soukromých čísel). b) host: Hostovi jsou všechny telefonní hovory předoznačeny jako soukromé a host to nemůže změnit. Role: Zaměstnanec musí mít přiřazenou alespoň jednu roli. (připomenutí: role nemusí mít žádné operace, viz. návod k editování rolí). Tabulka s tel. čísly: V této tabulce je seznam telefonních čísel, které osoba používala/používá. Chcete-li osobě odebrat tel. číslo, stiskněte v daném řádku tabulky tlačítko „odebrat“. Chcete-li osobě přidat tel. číslo, stiskněte nahoře stránky tlačítko přidat. Dole na stránce se zobrazí tabulka, ve které jsou dostupná (ta, která nikdo nepoužívá) tel. čísla. Vyberte číslo a stiskněte tlačítko přidat. Změna hesla: Po stisknutí tlačítka vám systém umožní změnit uživateli heslo.
Telefonní čísla V této sekci můžete editovat telefonní čísla. Telefonní čísla je do systému nutné zadávat i s předvolbou – tedy pro ČR 420. Pokud by předvolba nebyla zadána, systém by nemohl ze souboru načíst telefonní výpisy. Příznak „aktivní“: pokud je telefon neaktivní, nebude jej možné přiřadit žádnému uživateli. Nastavení V této sekci můžete editovat nastavení vaší firmy. Položky: viz. registrace
23
24
D Příloha – Use Case Document
Use Case Document 3 Use Case 3.1 Administrace
25
3.1.1 Editování firemních údajů Flow of Events Basic Path Editace firemních údajů Případ užití začíná když chce uživatel editovat údaje o firmě. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí údaje společnosti (ID, název, IČ, DIČ, číslo účtu, email) 2) Uživatel zvolí volbu "Editovat" 3) Systém zobrazí údaje společnosti (název, IČ, DIČ, číslo účtu, email) v editovatelném formuláři. 4) Uživatel provede editaci údajů a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny.
3.1.2 Editování firemního nastavení Flow of Events Basic Path Editace firemního nastavení Případ užití začíná když chce uživatel editovat údaje o nastavení. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí firemní nastavení 2) Uživatel vybere volbu "Editovat" 3) Systém zobrazí data v editačním formuláři 4) Uživatel provede editaci a odešle formulář 5) Systém zvaliduje vstupní data a uloží změny
3.1.3 Editování oddělení Flow of Events Basic Path Editace oddělení Případ užití začíná když chce uživatel editovat údaje o oddělení Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo
26
1) Systém zobrazí tabulku s odděleními 2) Uživatel u zvoleného oddělení vybere volbu "Editovat" 3) Systém zobrazí formulář s informacemi o daném oddělení (název, zkratka, poznámka) 4) Uživatel provede editaci údajů a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny. Alternate Vymazání oddělení Případ užití začíná když chce uživatel vymazat oddělení ze systému Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí tabulku s odděleními 2. Uživatel u zvoleného oddělení vybere volbu "Editovat" 3. Uživatel vybere volbu "Odstranit" 4. Systém požádá uživatele o potvrzení vybrané volby 5. Systém zkontroluje, jestli se v oddělení nenachází nějaké osoby 6. Pokud se v oddělení nachází osoby 6.1 Systém zobrazí hlášku o tom, že oddělení nelze smazat 7. Jinak systém odstraní oddělení ze systému. Alternate Vytvoření nového oddě lení Případ užití začíná když chce uživatel založit nové oddělení Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí tabulku s odděleními 2) Uživatel vybere volbu "Přidat" 3) Systém zobrazí prázdný editovatelný formulář 4) Uživatel vyplní údaje (název, zkratka, poznámka) a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny.
3.1.4 Editování osob Flow of Events Basic Path Editace osob Případ užití začíná když chce uživatel editovat osobu Vstupní podmínky:
27
uživatel je přihlášen k systému uživatel má na operaci právo Include (Najít osobu) 1) Systém zobrazí údaje (ID, jméno, příjmení, username, e-mail, stav, oddělení, datum narození, role, používaná tel. čísla) o osobě v editovatelném formuláři. 2) Uživatel provede editaci údajů a odešle formulář. 3) Systém zvaliduje data na vstupu a uloží změny. Alternate Vytvoř ení nové osoby Případ užití začíná když chce uživatel přidat osobu do systému Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí stránku s přehledem osob 2) Uživatel vybere volbu "Přidat" 3) Systém zobrazí prázdný editovatelný formulář 4) Uživatel vyplní údaje a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny. Alternate Deaktivace osoby Případ užití začíná po 1. kroku případu užití Editace osob. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Uživatel vybere volbu "Zneaktivnit" 2. Systém požádá uživatele o potvrzení volby. 3. Pokud uživatel volbu potvrdí 3.1 Systém odebere osobě všechna tel. čísla, které má v daný okamžik přidělená
3.1.5 Editování rolí Flow of Events Basic Path Editace rolí Případ užití začíná když chce uživatel editovat role Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo
28
1) Systém zobrazí tabulku s rolemi 2) Uživatel u zvolené role vybere volbu "Editovat" 3) Systém zobrazí formulář s informacemi o dané roli (název, operace) 4) Uživatel provede editaci údajů a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny. Alternate Vymazání role Případ užití začíná když chce uživatel vymazat roli z databáze Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí tabulku s rolemi 2) Uživatel u zvolené role vybere volbu "Editovat" 3. Uživatel vybere volbu "Odstranit" 4. Systém požádá uživatele o potvrzení vybrané volby 5. Systém zkontroluje, jestli nemá roli přidělenou nějaká osba 6. Pokud má roli přidělenou nějaká osoba 6.1 Systém zobrazí hlášku o tom, že roli nelze smazat 7. Jinak systém odstraní roli ze systému. Alternate Vytvoření role Případ užití začíná když chce uživatel založit novou roli Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí tabulku s rolemi 2) Uživatel vybere volbu "Přidat" 3) Systém zobrazí prázdný editovatelný formulář 4) Uživatel vyplní údaje (název, povolené operace) a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny.
3.1.6 Editování telefonních čísel Flow of Events Basic Path Editace telefonních čísel Případ užití začíná když chce uživatel editovat údaje o telefonním čísle Vstupní podmínky: uživatel je přihlášen k systému
29
uživatel má na operaci právo Include (Najít telefonní číslo) 1) Systém zobrazí údaje (tel. číslo, stav, poznámka) o tel. čísle v editovatelném formuláři. 2) Uživatel provede editaci údajů a odešle formulář. 3) Systém zvaliduje data na vstupu a uloží změny. Alternate Přidání telefonního čísla do systému Případ užití začíná když chce uživatel přidat nové tel. číslo do systému Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí stránku s přehledem tel. čísel 2) Uživatel vybere volbu "Přidat" 3) Systém zobrazí prázdný editovatelný formulář 4) Uživatel vyplní údaje a odešle formulář. 5) Systém zvaliduje data na vstupu a uloží změny. Alternate Deaktivace telefonního čísla Případ užití začíná po 1. kroku případu užití Editace telefonních čísel Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Uživatel vybere volbu "Zneaktivnit" 2. Systém požádá uživatele o potvrzení volby. 3. Pokud uživatel volbu potvrdí 3.1 Pokud tel. číslo nějaká osoba používá, systém jí ho odebere.
3.1.7 Najít osobu Flow of Events Basic Path Najít osobu Případ užití začíná když chce uživatel najít osobu Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí vyhledávací filtr s údaji (příjmení, username, id, e-mail, role, id odpovědné osoby, stav) 2) Uživatel vyplní filtr a odešle formulář
30
3) Systém zobrazí nalezené osoby 4) Uživatel vybere jednu z nalezených osob
3.1.8 Najít telefonní číslo Flow of Events Basic Path Najít telefonní číslo Případ užití začíná když chce uživatel najít telefonní číslo Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí vyhledávací filtr s údaji (tel. číslo, stav) 2) Uživatel vyplní filtr a odešle formulář 3) Systém zobrazí nalezená tel. čísla 4) Uživatel vybere jedno z nalezených tel. čísel
3.2 Aktéř i Aktéři
31
3.2.1 Nepřihlášený uživatel Nepřihlášený uživatel je libovolný návštěvník internetové/instranetové aplikace.
3.2.2 Oprávně ný uživatel Oprávněný uživatel je ten uživatel, který má práva na příslušnou operaci (např. operace „Může editovat oddělení“). Tuto operaci získá tak, že alespoň jedna z jeho rolí má tuto operaci.
3.2.3 SuperAdmin Superadmin je aktér, který je „nad“ všemi firmami v aplikaci. Je to administrátor celé aplikace. Nemá však žádná práva ke konkrétní firmě. Firmu může pouze vymazat ze systému.
3.2.4 Čas Čas je aktér, který do akcí zasahuje při vypršení timeoutu časovače aplikačního serveru.
32
3.3 Přehledy Přehledy
3.3.1 Najít příchozí platbu Flow of Events Basic Path Najít příchozí platbu Případ užití začíná když chce uživatel najít příchozí platbu Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí vyhledávací filtr s údaji (od, do, var. symbol, spec.
33
symbol, konst. symbol, stav) 2) Uživatel vyplní filtr a odešle formulář 3) Systém zobrazí nalezené příchozí platby 4) Uživatel vybere jednu z nalezených příchozích plateb
3.3.2 Najít telefonní vyúč tování Flow of Events Basic Path Najít telefonní vyúč tování Případ užití začíná když chce uživatel najít telefonní vyúčtování Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1) Systém zobrazí vyhledávací filtr s údaji (od, do, tel. číslo, stav) 2) Uživatel vyplní filtr a odešle formulář 3) Systém zobrazí nalezené vyúčtování 4) Uživatel v ybere jedno z nalezených vyúčtování
3.3.3 Zobrazení provolané částky pro celou firmu 3.3.4 Zobrazení přehledů osob Flow of Events Basic Path Zobrazení př ehledů osoby Případ užití začíná když chce uživatel zobrazit informace o osobě Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo Include (Najít osobu) 1) Systém zobrazí údaje (ID, jméno, příjmení, username, e-mail, stav, oddělení, datum narození, stav účtu) o osobě v tabulce
3.3.5 Zobrazení přehledů platebních příkaz ů 3.3.6 Zobrazení přehledů příchozích plateb Flow of Events Basic Path Zobrazení př ehledů př íchozích plateb Případ užití začíná když chce uživatel zobrazit přehled příchozích plateb.
34
Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo Include (Najít příchozí platbu) 1. Systém zobrazí údaje o příchozí platbě.
3.3.7 Zobrazení přehledů telefonních vyúč tování Flow of Events Basic Path Zobrazení přehledů telefonních vyúč tování Případ užití začíná když chce uživatel zobrazit přehled telefonních vyúčtování. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo Include (Najít telefonní vyúčtování) 1. Systém zobrazí údaje (id, tel. číslo, cena, stav, od, do) o tel. vyúčtování a zobrazí také položky tohoto vyúčtování.
3.3.8 Zobrazení přehledů telefonních čísel
35
3.4 Registrace firmy Registrace firmy
3.4.1 Registrace nové firmy Flow of Events Basic Path Registrace firmy Případ užití začíná když chce uživatel zaregistrovat novou firmu do systému. 1. Systém zobrazí registrační formulář 2. Uživatel vyplní všechny povinné položky formuláře a odešle formulář 3. Systém zvaliduje vstupní data a založí firmu. 4. Systém odešle na administrátorův e-mail jeho přihlašovací údaje 5. Systém zobrazí ID, které bylo firmě přiřazeno
3.5 SimpleDocumentation SimpleDocumentation
36
37
3.6 SuperAdministrace SuperAdministrace
3.6.1 Editování bank Flow of Events Basic Path Editování banky Případ užití začíná když chce superadmin editovat banku. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Systém zobrazí tabulku s přehledem bank
38
2. Uživatel zvolí u vybrané banky volbu "Editovat" 3. Systém zobrazí formulář s informacemi (kód, název) o vybrané bance 4. Uživatel provede editaci a odešle formulář 5. Systém zvaliduje data a uloží změny Alternate Přidání banky Případ užití začíná když chce superadmin přidat banku. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Případ užití začíná bodem 1 případu užití Editování banky 2. Uživatel zvolí volbu Přidat 3. Systém zobrazí prázdný formulář s informacemi s položkami kód, název 4. Uživatel vyplní a odešle formulář 5. Systém zvaliduje data a uloží banku do databáze Alternate Smazání banky Případ užití začíná když chce superadmin smazat banku. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Případ užití začíná bodem 2 případu užití Editování banky 2. Uživatel zvolí volbu "Odstranit" 3. Systém požádá uživatel o potvrzení volby 4. Uživatel potvrdí volbu. 5. Systém odstraní banku z databáze
3.6.2 Editování jazyků Flow of Events Basic Path Přidání jazyku Případ užití začíná když chce superadmin přidat jazyk. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Systém zobrazí tabulku s přehledem jazyků 2. Uživatel zvolí volbu "Přidat" 3. Systém zobrazí formulář pro zadání nového jazyka (položka: název) 4. Uživatel vyplní název a odešle formulář 5. Systém zvaliduje data a uloží změny
39
Alternate Odstran ě ní jazyku Případ užití začíná když chce superadmin smazat jazyk. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Případ užití začíná bodem 1 případu užití přidání jazyku 2. Uživatel u vybraného jazyku zvolí volbu "Odstranit" 3. Systém požádá uživatel o potvrzení volby 4. Uživatel potvrdí volbu. 5. Systém odstraní jazyk z databáze
3.6.3 Editování nastavení aplikace Flow of Events Basic Path Editování nastavení aplikace Případ užití začíná když chce superadmin změnit nastavení aplikace. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Systém zobrazí nastavení aplikace 2. Uživatel vybere volbu "Editovat" 3. Systém zobrazí formulář s nastavením aplikace 4. Uživatel provede změny a odešle formulář 5. Systém zvaliduje data a uloží změny
3.6.4 Zobrazení firem Flow of Events Basic Path Zobrazení firem Případ užití začíná když chce superadmin zobrazit registrované firmy. Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor 1. Systém zobrazí tabulku s registrovanými firmami a jejich základními údaji (id, název, ič, dič, číslo účtu) Alternate Odstraně ní firmy Případ užití začíná když chce superadmin smazat některou z registrovaných firem Vstupní podmínky: uživatel je přihlášen k systému jako superadministrátor
40
1. Případ užití začíná bodem jedna případu užití Zobrazení firem. 2. Uživatel u zvolené firmy zvolí volbu "Odstranit" 3. Systém požádá uživatele o potvrzení volby 4. Uživatel potvrdí volbu 5. Systém odstraní firmu ze systému
3.7 VolbyUcetni VolbyUcetni
41
3.7.1 Generování platebních příkaz ů Flow of Events Basic Path Generování platebních příkaz ů Případ užití začíná když chce uživatel vytvořit platby za telekomunikační služby. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s datem do kdy se mají platby generovat 2. Uživatel zvolí datum a odešle formulář 3. Systém nalezne tel. vyúčtování, která ještě nebyla zpracována 4. Pro každé vyúčtování, na kterém je cena soukromých hovorů > 0 4.1 Najít počet osob, které v daném období číslo používalo 4.2 Pro každou osobu 4.2.1 Zjistit kolik mají zaplatit za soukromé hovory 4.2.2 Pokud zaplatit > 0 4.2.2.1 Include (Vygenerovat platbu)
3.7.2 Kontrola e-mailů s bankovním výpisem Flow of Events Basic Path Kontrola e-mailů s bankovním výpisem Případ užití začíná když chce uživatel stáhnout bankovní výpisy z emailu Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Uživatel spustí operaci. 2. Systém stáhne emaily, vyhledá v nich bankovní výpisy. 3. IF Bankovní výpis byl nalezen 3.1 Extend (Zpracování bankovního výpisu) 4. Systém zobrazí hlášení o průběhu zpracovávání.
3.7.3 Vložení bankovního výpisu v souboru Flow of Events Basic Path Vložení bankovního výpisu Případ užití začíná když chce uživatel vložit soubor s bankovním výpisem
42
Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí forlulář s políčkem pro určení cesty k souboru 2. Uživatel vybere soubor na disku a odešle formulář Include (Zpracování bankovního výpisu) 3. Systém zobrazí hlášení o průběhu zpracovávání.
3.7.4 Vložení vyúč tování Flow of Events Basic Path Vložení souboru s podrobným výpisem Případ užití začíná když chce uživatel vložit soubor s podrobným výpisem Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s políčkem pro určení cesty k souboru 2. Uživatel vybere soubor na disku a odešle formulář 3. Systém zpracuje data v souboru 4. Systém uloží vyúčtování do databáze. 5. Systém zobrazí hlášení o průběhu zpracovávání.
3.7.5 Vložit bankovní transakci Flow of Events Basic Path Vložit bankovní transakci Případ užití začíná když chce uživatel vložit bankovní transakci Vstupní podmínky: Jsou k dispozici data pro vytvoření bankovní transakce (specifický symbol, konstantní symbol, částka, id firmy, variabilní symbol, datum zaplacení) 1. Systém ověří, že daná transakce již není v databázi 2. Pokud v databázi není 2.1 Systém najde nezaplacené platby osoby a postupně k nim přičítá částku. Pokud z částky něco zbyde, přičte systém částku na účet osoby.
43
3.7.6 Vygenerovat platbu Flow of Events Basic Path Vytvoř it příkaz k úhradě Případ užití začíná když chce uživatel vytvořit příkaz k úhradě. Vstupní podmínky: Jsou k dispozici data pro vytvoření příkazu k úhradě (č. účtu příjemce, datum vystavení, datum splatnosti, specifický symbol, konstantní symbol, částka, id firmy) 1. Systém načte částku účtu osoby, pro kterou se příkaz vytváří 2. IF částka > 0 2.1 K hodnotě zaplaceno na příkazu se přičte částka z účtu 2.2 Částka se nastaví na nulu 2.3 IF zaplaceno > cena 2.3.1 K částce se přičte zaplaceno - cena 2.3.2 Zaplaceno nastaví tak aby platilo zaplaceno = cena 3. Systém uloží částku u osoby a příkaz k úhradě do databáze
3.7.7 Vytvoření příkazu k úhrad ě Flow of Events Basic Path Vytvoř ení příkazu k úhradě Případ užití začíná když chce uživatel vytvořit příkaz k úhradě Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí forlulář s políčkem pro příjmení osoby a combo boxem se seznamem nalezených osob. 2. Uživatel vyplní příjmení a odešle formulář 3. Systém zobrazí v combo boxu seznam nalezených osob 4. Uživatel vybere jednu z nalezených osob a odešle formulář 5. Systém zobrazí formulář pro zadání příkazu k úhradě s prvky č. účtu příjemce, datum vystavení, datum splatnosti, specifický symbol, konstantní symbol, částka) 6. Uživatel vyplní a odešle formulář. 7. Systém zvaliduje vstupní data Include(Vygenerovat platbu)
44
3.7.8 Zadání příchozí bankovní platby Flow of Events Basic Path Zadání příchozí bankovní platby Případ užití začíná když chce uživatel zadat příchozí platbu Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí forlulář s políčkem pro příjmení osoby a combo boxem se seznamem nalezených osob. 2. Uživatel vyplní příjmení a odešle formulář 3. Systém zobrazí v combo boxu seznam nalezených osob 4. Uživatel vybere jednu z nalezených osob a odešle formulář 5. Systém zobrazí formulář pro zadání příchozí platby s prvky specifický symbol, konstantní symbol, datum zaplacení, částka) 6. Uživatel vyplní a odešle formulář. 7. Systém zvaliduje vstupní data Include(Vložit bankovní transakci)
3.7.9 Zpracování bankovního výpisu Flow of Events Basic Path Zpracování bankovního výpisu Případ užití začíná když se systém získá soubor s bankovním výpisem 1. Systém zpracuje data z výpisu 2. Pokud výpis obsahuje příchozí transakce 2.1 Pro každou příchozí transakci 2.1.1 Systém zjistí, jestli je v dané firmě osoba, která má id stejné jako variabilní symbol transakce (bez firemní předpony). 2.1.2 Pokud existuje 2.1.2.1 Include(Vložit bankovní transakci)
3.8 VolbyUzivatele VolbyUzivatele
45
Figure 8: VolbyUzivatele
46
3.8.1 Editace osobního nastavení Flow of Events Basic Path Editace osobního nastavení Případ užití začíná když chce uživatel nastavit svůj účet v aplikaci. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí nastavení uživatele. 2. Uživatel vybere volbu "Editovat". 3. Systém zobrazí formulář s osobním nastavením. 4. Uživatel provede změny a odešle formulář. 5. Systém zvaliduje vstupní data a uloží změny.
3.8.2 Editace soukromých čísel Flow of Events Basic Path Editace soukromých čísel Případ užití začíná když chce uživatel editovat soukromá čísla Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí tabulku se soukromými čísly. 2. Uživatel u zvoleného čísla vybere volbu "Editovat" 3. Systém zobrazí formulář s informacemi o daném tel. číslei (číslo, poznámku) 4. Uživatel provede editaci údajů a odešle formulář. 5. Systém zvaliduje data na vstupu a uloží změny. Alternate Odebrání soukromého čísla Případ užití začíná když chce uživatel odebrat soukromé číslo. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí tabulku se soukromými čísly. 2. Uživatel u zvoleného čísla vybere volbu "Editovat" 3. Systém zobrazí formulář s informacemi o daném tel. číslei (číslo, poznámku) 4. Uživatel vybere volbu "Odstranit". 5. Systém požádá uživatele o potvrzení volby.
47
6. Uživatel potvrdí volbu. 7. Systém odstraní tel. číslo z databáze. Alternate Přidání soukromého čísla Případ užití začíná když chce uživatel přidat soukromé číslo. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí tabulku se soukromými čísly. 2. Uživatel u zvoleného čísla vybere volbu "Přidat" 3. Systém zobrazí formulář s informacemi o daném tel. číslei (číslo, poznámku) 4. Uživatel vyplní hodnoty a odešle formulář. 5. Systém zvaliduje údaje a uloží nové soukromé číslo.
3.8.3 Ozna č ení soukromých hovorů Flow of Events Basic Path Označ ení soukromých hovorů Případ užití začíná když chce uživatel označit soukromé hovory. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí přehled vyúčtování, které jsou ve stavu nový. 2. Uživatel vybere vyúčtování, které bude označovat. 3. Systém zobrazí formulář s položkami vybraného vyúčtování. 4. Uživatel označí soukromé hovory a odešle formulář. 5. Systém uloží změny do databáze.
3.8.4 Změ na hesla Flow of Events Basic Path Změna hesla Případ užití začíná když chce uživatel změnit heslo Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s políčky staré heslo, nové heslo, nové heslo 2 2. Vyplní a odešle formulář
48
3. Systém oveří, že je staré heslo vyplněno správně. 4. Systém ověří, že je nové heslo zadáno do dvou polí stejně. 5. Systém zašifruje hesla a uloží je do databáze. 6. Systém zobrazí informaci o výsledku změny.
3.8.5 Zobrazení platebních příkaz ů Flow of Events Basic Path Zobrazení platebních příkaz ů Případ užití začíná když chce uživatel zobrazit platební příkazy Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s vyhledávacím filtrem, který bude obsahovat políčka od a do. 2. Uživatel zadá datumy a odešle formulář. 3. Systém zobrazí tabulku s nalezenými platebními příkazy
3.8.6 Zobrazení podrobných vyúč tování Flow of Events Basic Path Zobrazení podrobných vyúč tování Případ užití začíná když chce uživatel zobrazit podrobné vyúčtování. Vstupní podmínky: uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s vyhledávacím filtrem, který bude obsahovat políčka od a do. 2. Uživatel zadá datumy a odešle formulář. 3. Systém zobrazí tabulku s nalezenými účty 4. Uživatel zvolí vyúčtování, které chce vidět. 5. Systém zobrazí tabulku, ve které budou položky vybraného vyúčtování.
3.8.7 Zobrazení příchozích plateb Flow of Events Basic Path Zobrazení příchozích plateb Případ užití začíná když chce uživatel zobrazit příchozí bankovní platby Vstupní podmínky:
49
uživatel je přihlášen k systému uživatel má na operaci právo 1. Systém zobrazí formulář s vyhledávacím filtrem, který bude obsahovat políčka od a do. 2. Uživatel zadá datumy a odešle formulář. 3. Systém zobrazí tabulku s nalezenými bankovními platbami
50
E Příloha – UML diagramy Tištěná příloha obsahuje pouze nejdůležitejší diagramy. Všechny diagramy se nacházejí na přiloženém cd (/dokumentace). 1) Generování platebních příkazů (diagram aktivit)
51
act Generov ání platebních příkazů Start
Aplikace v yhledá telefonní účty, které j sou v e stav u 100 (Nov ý)
Oprávněný uživatel spustí generování plateb
Pro každý telefonní účet se naj dou osoby, které v daném období telefonní číslo použív aly
Pro každou osobu se v yhledaj í soukromé položky a sečte se j ej ich celkov á cena
Aplikace v yhledá osobu, která bude položky platit
[soukr. cena > 0]
[j inak]
Aplikace v ygeneruj e příkaz k úhradě
[č ástka > úč et osoby]
[j inak]
[č ástka < úč et osoby]
zaplaceno = účet osoby účet osoby = 0
zaplaceno = částka účet osoby = (účet osoby - částka)
[č ástka - zapl aceno > 0]
[ji nak]
Příkaz k úhradě přechází do stav u 100 (Nezaplaceno)
Telefonní v yúčtov ání přechází do stav u 300 (Zpracov áno)
zaplaceno = účet osoby účet osoby = 0
Příkaz k úhradě přechází do stav u 300 (Zaplaceno potv rzeno)
Konec
52
2) Párování plateb – vložení výpisu v souboru (diagram aktivit) act Párov ání plateb - v ložení v ýpisu v souboru Start
BankParser vrátí seznam přícho zích plateb na ú č et
Pro každou platbu hledám osobu, j ej íž ID j e shodné s v ariabilním symbolem platby
[osoba nal ezena]
Vyhledání platby v databázi podle transactionID
Aplikace v yhledá platební příkazy které j sou v e stav u 100 (Nezaplaceno).
[přícho zí p latba nale ze na v databázi ]
Aplikace prochází nalezené platební příkazy od nej starší
[příchozí č ástka > zb ývá zapl ati t]
[j inak]
[příchozí č á stka = zbývá zap latit]
Příchozí platba přechází do stav u 20 (potv rzená) příchozí částka = příchozí částka - (částka zaplaceno)
zaplaceno = částka
zaplaceno = částka
zaplaceno = zaplaceno + příchozí částka
příchozí částka = 0
příchozí částka = 0
za place no ... č á stka, která b yl a zapla ce na č ástka ... č ástka, kte rá se m á za platit zb ývá zapl ati t = č ástka - za place no příchozí č ástka ... peníze, které b yl y p řij aty na úč et (č ástka na p řích ozí pla tbě)
[příchozí č ástka > 0] účet osoby = účet osoby + příchozí částka
Aplikace uloží příchozí platbu do databáze
K onec
53
54
F Příloha - Přiložené CD Adresářová struktura: • /dokumentace ◦ UML dokumentace, Javadoc • /src ◦ zdrojové kódy aplikace ◦ /dist ▪ build aplikace • /db ◦ inicializační sql scripty ◦ /testovaciData ▪ testovací scénář, testovací data (sql script) • /IDE ◦ instalační soubory pro NetBeans IDE 6.1 a aplikační server GlassFish V2 • /manual ◦ uživatelský a instalační manuál, zprovoznění vývojového prostředí • / ◦
zdrojový text této práce
55
