telekomunikační firmy

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Fakturační a evidenční systém malé telekomunikační firmy Vojtěch Brom

Vedoucí práce: Ing. Martin Bloch, CSc.

Studijní program: Elektrotechnika a informatika, dobíhající magisterský Obor: Informatika a výpočetní technika Leden 2007 prosinec 2006

ii

Poděkování Na tomto místě bych rád vyjádřil své poděkování všem, bez kterých by tato práce nemohla vzniknout. V první řadě děkuji své rodině za poskytnuté zázemí a obrovskou podporu při studiu a psaní této práce, zejména pak své mamince, která celý text pečlivě přečetla a byla mi největší oporou. Dále děkuji Ing. Martinu Blochovi, CSc., vedoucímu této práce, za jeho optimistický přístup k věci a cenné rady. V neposlední řadě děkuji za podporu a podnětné připomínky svým přátelům.

iii

iv

Prohlášení Prohlašuji, že jsem svou diplomovou 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 použ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). V Praze dne 10.2. 2007

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

v

vi

Abstract This diploma thesis deals with the creation of Customer Relationship Management system for a small telecommunications company BCH TeleCommunications Inc. The goal is to design and to create user friendly application, which will simplify the client directory administration and invoicing for the customers. The whole thesis can be divided into several parts. First two parts deal with a general definition of the assignment itself with the summary of system requirements and a selection of suitable methodology for analysis and design. Following is the detailed requirements analysis and part of the system design. Next part is devoted to the description of system implementation and implementation supporting tools. At the end the thesis focuses on discussion about testing and the last part encompasses an evaluation of achieved results.

Abstrakt Tato diplomová práce se zabývá tvorbou evidenčního a fakturačního systému pro malou telekomunikační společnost BCH TeleCommunications s.r.o. Cílem je navržení a vytvoření přehledné aplikace, která společnosti usnadní především vedení zákaznické agendy a vystavování faktur pro zákazníky. Práci lze rozdělit do několika hlavních částí. První dvě části se zabývají obecnou definicí vlastního zadání s nástinem požadavků na systém a výběrem vhodné metodiky pro analýzu a návrh. Následuje podrobná analýza požadavků a část návrhu aplikace. Další část se věnuje popisu vlastní implementace a použitých implementačních nástrojů. Na konci se práce zaměřuje na diskusi o testování a v poslední části je obsaženo zhodnocení dosažených výsledků.

vii

viii

OBSAH 1

ÚVOD

1

2

POUŽITÉ TECHNOLOGIE A METODIKY

1

2.1 DOSTUPNÉ METODIKY (A TECHNOLOGIE) 2.1.1 CO JE METODIKA A CO TECHNOLOGIE 2.1.2 STRUČNÝ PŘEHLED 2.2 POUŽITÉ METODIKY (A TECHNOLOGIE) 2.2.1 UML 2.2.1.1 Použité a dostupné diagramy UML 2.2.2 ER MODELOVÁNÍ

1 1 2 3 3 4 4

3

5

ÚVODNÍ STUDIE

3.1 RÁMCOVÝ PLÁN PROJEKTU 3.2 DEKLARACE ZÁMĚRU 3.2.1 HLAVNÍ RYSY APLIKACE 3.3 ODBORNÝ ČLÁNEK 3.4 DIAGRAM KONTEXTU 3.4.1 BLIŽŠÍ SPECIFIKACE KONTEXTU 3.5 PŘÍPADY UŽITÍ 3.5.1 DIAGRAMY PŘÍPADŮ UŽITÍ 3.5.1.1 Výchozí Use Case diagram 3.5.1.2 Use Case diagramy většího detailu 3.5.2 TEXTOVÁ SPECIFIKACE NĚKTERÝCH PŘÍPADŮ UŽITÍ 3.6 STANOVENÍ DOSAŽITELNÝCH CÍLŮ VLASTNÍ DIPLOMOVÉ PRÁCE

5 6 6 6 9 9 10 10 10 11 13 15

4

17

ANALÝZA

4.1 SLOVNÍČEK POUŽÍVANÝCH POJMŮ A ZKRATEK 4.2 SOUČASNÉ FAKTURAČNÍ ŘEŠENÍ 4.2.1 STRUČNÁ CHARAKTERISTIKA 4.2.2 MIGRACE STÁVAJÍCÍCH DAT 4.3 PODROBNÝ KATALOG POŽADAVKŮ A BLIŽŠÍ SPECIFIKACE 4.3.1 POŽADAVKY NA HW A SW 4.3.2 POŽADAVKY NA VYTVÁŘENÝ SOFTWARE 4.3.2.1 Serverová část 4.3.2.1.1 Informace uchovávané o zákaznících 4.3.2.1.2 Informace evidované k fakturám 4.3.2.1.3 Informace sazebníků 4.3.2.1.4 Informace o klientských číslech a o všech provedených hovorech 4.3.2.1.5 Systémové informace 4.3.2.1.6 Informace o CDR projektech 4.3.2.2 Klientská část

ix

17 18 18 18 18 18 18 18 19 20 20 21 21 22 22

4.3.2.2.1 Správa klientské databáze 4.3.2.2.2 Import dat 4.3.2.2.3 Zakládání a rušení CDR projektů 4.3.2.2.4 Vytváření detailních výpisů hovorů (v rámci projektu) 4.3.2.2.5 Označování duplicitních a překrývajících se hovorů ve výpisu hovorů 4.3.2.2.6 Vytváření faktur a zpracování plateb (v rámci projektu) 4.3.2.2.7 Vytváření reportů (v rámci projektu) 4.3.2.2.8 Export do XLS 4.3.2.2.9 Tisk 4.3.2.2.10 Zasílání emailů 4.3.2.2.11 Zaznamenávání změn 4.3.2.2.12 Podpora více jazyků uživatelského rozhraní 4.4 DATOVÁ ANALÝZA 4.4.1 ER DIAGRAM 4.4.2 POPIS REPREZENTACE DAT 4.4.2.1 Entita zakaznik 4.4.2.2 Entita adresa 4.4.2.3 Entita CDR_projekt 4.4.2.4 Entita CLI 4.4.2.5 Entita CLI_skupina 4.4.2.6 Entita druh_platby 4.4.2.7 Entita email 4.4.2.8 Entita fakturace_poradnik 4.4.2.9 Entita faktura 4.4.2.10 Entita hovor 4.4.2.11 Entita kontaktni_osoba 4.4.2.12 Entita kreditni_karta 4.4.2.13 Entita problemova_hlaseni_CLI 4.4.2.14 Entita problemove_hlaseni 4.4.2.15 Entita sazba 4.4.2.16 Entita sazebnik 4.4.2.17 Entita servis_info 4.4.2.18 Entita system_log_uzivatel 4.4.2.19 Entita system_log_zmena 4.4.2.20 Entita system_uzivatel 4.4.2.21 Entita system_uzivatel_nastaveni 4.4.2.22 Entita technicky_partner 4.4.2.23 Entita telefon 4.4.2.24 Entita typ_karty 4.4.2.25 Entita typ_zakaznika 4.4.3 HODNOTY DAT A RELACE 4.4.3.1 Hodnoty dat 4.4.3.2 Relace 4.5 MODELOVÁNÍ DYNAMICKÉHO CHOVÁNÍ NĚKTERÝCH ČÁSTÍ SYSTÉMU 4.5.1 MODELOVÁNÍ PROCESU „VYTVOŘENÍ CDR PROJEKTU“ 4.5.2 MODELOVÁNÍ PROCESU „VYTVOŘENÍ CDR VÝPISŮ“ 4.5.2.1 Detekce duplicitních a překrývajících se hovorů 4.5.3 MODELOVÁNÍ PROCESU „VYTVOŘENÍ FAKTUR“ 4.6 DIAGRAMY AKTIVIT PRO PROVÁDĚNÍ NĚKTERÝCH OPERACÍ

x

22 22 23 23 23 23 24 24 24 25 25 25 26 26 27 27 27 28 28 28 28 28 28 29 29 29 29 30 30 30 30 30 31 31 31 31 31 32 32 32 32 32 33 33 33 35 35 36 37

4.6.1 OPERACE VYMAZÁNÍ (CDR PROJEKTU) 4.6.2 ZASLÁNÍ EMAILU 4.7 ZÁVĚREM K ANALÝZE

38 38 39

5

41

NÁVRH

5.1 NÁVRH ČLENĚNÍ SYSTÉMU A POPIS KOMPONENT 5.1.1 NÁVRH KOMPONENT (BALÍČKŮ) 5.1.2 POPIS ZÁKLADNÍHO NÁVRHU JEDNOTLIVÝCH KOMPONENT (BALÍČKŮ) 5.1.2.1 Komponenta dbaccess 5.1.2.1.1 Dílčí komponenta pro logování změn – datachanges 5.1.2.2 Komponenta entities 5.1.2.2.1 Reprezentace relací mezi entitními objekty 5.1.2.2.2 Ukládání, mazání a update dat entitních objektů 5.1.2.3 Komponenta emailing 5.1.2.4 Komponenta exceptions 5.1.2.5 Komponenta input 5.1.2.6 Komponenta printing 5.1.2.7 Komponenta xls 5.1.2.8 Komponenty tools, ApplicationStatus, Main a Login 5.2 NÁVRH GRAFICKÉHO UŽIVATELSKÉ ROZHRANÍ 5.2.1 STRUČNÝ POPIS DÍLČÍCH ČÁSTÍ KOMPONENTY GUI 5.2.1.1 Hlavní okno – třída MainFrame 5.2.1.1.1 Panely hlavního okna – balík panels 5.2.1.2 Datové modely – komponenta models 5.2.1.3 Dialogy a jednoduché zprávy – balíky dialogs a messages 5.2.1.4 Okno zákazníka – třída CustomerFrame 5.2.1.5 Programová správa grafického rozhraní – třída GUIStatus 5.2.1.6 Podpora vícejazyčného GUI 5.2.1.7 Měření průběhu dlouhých činností – balík progressmeasuring 5.2.2 NÁVRH INTERAKCE UŽIVATELE A GUI 5.3 AKCEPTAČNÍ TESTY A TESTY POUŽITELNOSTI 5.3.1 NÁVRH AKCEPTAČNÍCH TESTŮ PRO HLAVNÍ FUNKCE 5.3.2 TESTOVÁNÍ POUŽITELNOSTI

41 41 42 42 42 43 43 43 44 45 45 46 46 47 47 48 48 48 49 49 50 50 50 51 52 53 54 54

6

55

IMPLEMENTACE

6.1 POUŽITÉ TECHNOLOGIE A NÁSTROJE 6.1.1 VOLBA TECHNOLOGIÍ 6.1.2 VOLBA NÁSTROJŮ 6.1.3 STRUČNÝ PŘEHLED POUŽITÝCH NESTANDARDNÍCH KNIHOVEN A NÁSTROJŮ 6.1.3.1 Knihovny pro práci s XLS formátem 6.1.3.2 Knihovny pro podporu elektronické pošty 6.1.3.3 Knihovny a nástroje pro podporu tisku 6.2 POPIS VLASTNÍ IMPLEMENTACE 6.2.1 PRAVIDLA A KONVENCE PŘI PSANÍ KÓDU 6.2.2 STRUČNÝ POPIS IMPLEMENTACE ZAJÍMAVÝCH ČÁSTÍ SYSTÉMU 6.2.2.1 Podpora práce s formátem XLS

xi

55 55 55 55 56 56 56 57 57 58 58

6.2.2.1.1 Export dat užitím XLS šablony a knihovny jXLS 6.2.2.1.2 Načtení hodnoty buňky z XLS souboru pomocí knihovny Java Excel API 6.2.2.2 Podpora zasílání emailů 6.2.2.3 Podpora tisku a exportu do různých formátů 6.2.3 NALEZENÉ CHYBY V IMPLEMENTACI JAVY 6.2.3.1 Memory Leak v aplikacích založených na SWING v prostředí Windows 6.2.3.1.1 Stručný popis chyby 6.2.3.1.2 Postup vedoucí k odhalení chyby 6.2.3.1.3 Proprietální řešení chyby 6.2.3.2 Drobná chyba při používání komponenty SWINGu JDialog 6.2.4 PŘEHLED IMPLEMENTOVANÝCH ČÁSTÍ A ROZSAHU IMPLEMENTACE 6.3 INSTALAČNÍ PŘÍRUČKA 6.3.1 INSTALACE SERVEROVÉ ČÁSTI A VYTVOŘENÍ SCHÉMATU 6.3.1.1 Instalace a konfigurace MySQL 6.3.1.2 Vytvoření databázového schématu 6.3.2 INSTALACE KLIENTA

58 59 59 60 61 61 61 62 62 63 63 64 64 64 65 65

7

67

TESTOVÁNÍ

7.1 7.2 7.3 7.4 8

JEDNOTKOVÉ TESTY INTEGRAČNÍ TESTY TESTY GUI VALIDAČNÍ A SYSTÉMOVÉ TESTY, AKCEPTACE A TESTY POUŽITELNOSTI ZÁVĚR

8.1 8.2 8.3 9

67 67 68 69 71

ZHODNOCENÍ VÝBĚRU POUŽITÝCH TECHNOLOGIÍ A NÁSTROJŮ ZHODNOCENÍ DOSAŽENÝCH VÝSLEDKŮ DOPORUČENÍ PRO DALŠÍ POKRAČOVÁNI PROJEKTU POUŽITÉ ZDROJE

71 71 72 73

9.1 9.2

LITERATURA A SLIDY INTERNETOVÉ ODKAZY

73 74

10

SEZNAM ILUSTRACÍ, TABULEK A PŘÍLOH

75

10.1 10.2 10.3

SEZNAM ILUSTRACÍ SEZNAM TABULEK SEZNAM PŘÍLOH

75 76 76

xii

xiii

xiv

Kapitola 1. Úvod

1

1 Úvod Při studiu ČVUT jsem se od začátku snažil směrovat mé zaměření k informačním technologiím a oboru softwarového inženýrství. V průběhu času jsem začal pracovat na pozici intranetového vývojáře v malém týmu. S metodami a postupy návrhu a vývoje software, které jsou vyučovány na katedře počítačů, jsem se však v praxi neseznámil. Vývoj probíhal spíše stylem extrémního programování. V období výběru tématu diplomové práce se mi naskytla příležitost tvorby aplikace pro malou telekomunikační společnost. Software by měl sloužit zejména pro evidenci zákazníků, jejich hovorů a pro vytváření faktur a výpisů s hovory pro zákazníky. Napadlo mne, že by to byla ideální příležitost, jak si v praxi vyzkoušet vývojový cyklus softwarového inženýrství. Po konzultaci s mým vedoucím diplomové práce, který mi maximálně vyšel vstříc a neměl žádné námitky ani ke změně z původního tématu, ani k rozsahu a složitosti této aplikace a po odsouhlasení tématu vedoucím katedry, jsem se rozhodl pojmout tvorbu aplikace jako svou diplomovou práci. Aplikaci jsem nazval CRM & billing system (CRM z Customer Relationship Management).

2 Použité technologie a metodiky V této části textu se budu věnovat stručnému přehledu metodik a technologií, které jsou používány k podpoře analýzy a návrhu informačních systémů. Diskuze o zvolených implementačních technologiích a použitých nástrojích bude uvedena v další, implementační části práce.

2.1 Dostupné metodiky (a technologie) 2.1.1 Co je metodika a co technologie V současné době je k dispozici mnoho více čí méně používaných metodik a technologií, které slouží k podpoře tvorby specifikace, analýzy a návrhu informačních systémů (dále jen IS). Metodikou je míněna definice metod či technik včetně jejich vzájemných vztahů a návazností, které se k tvorbě IS používají. Můžeme také říci, že metodika je nauka o určitých postupech. Slovem technologie označujeme nějaký nástroj (v našich souvislostech většinou nějaký grafický jazyk), který daná metodika používá. Ve většině případů je však obojí skryto za termínem metodika. Typickým sloučením výše uvedených dvou termínů je metodika OMT (Object Modeling Technique) od J. Rumbaugha. Obsahuje jak definici vývojových etap (z nichž hlavní jsou analýza, návrh a implementace) a používaných modelů (objektový, dynamický a funkční) jakožto samotné metodiky, tak definici technologie, kterou zde tvoří bližší popis používaných modelů spolu se způsoby jejich modelování a syntaxí užívaných diagramů. Oproti této metodice dnes velmi známy jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systému UML (Unified Modeling Language) představuje pouze nástroj, čili technologii pro modelování. V další části této kapitoly již budu používat pouze termín

2

Kapitola 2. Použité technologie a metodiky

metodika, neboť i v odborné literatuře, která se věnuje tomuto tématu, se pojmy technologie a metodika v souvislostech analýzy a návrhu vzájemně překrývají.

2.1.2 Stručný přehled Metodiky používané pro analýzu (a následný návrh) můžeme obecně rozdělit na datové, strukturované, objektové, založené na UML a post-UML. Datová analýza označuje ve většině případů proces návrhu vhodného uložení dat. Pokud zůstaneme u ještě stále nejpoužívanějších relačních databází, je tím míněna definice tabulek a jejich položek včetně vztahů mezi nimi. V souvislosti s relačními databázemi je dnes velmi používáno ER modelování s jeho ER diagramy. V objektové metodice koresponduje s ER diagramem diagram tříd. Strukturované metodiky analýzy zahrnují více modelů (datový a více funkčních). Patří mezi ně známá metoda SSADM (The Structured System Analysis and Method), jejíž postup vývoje odpovídá standardnímu životnímu cyklu softwarového díla nebo velmi podobnému cyklu vodopád. Jako další s velmi podobnými vlastnostmi lze jmenovat metodiku Modern Structured Analysis od E. Yourdona. Nevýhodou strukturovaných metodik je fakt, že ukončení jedné fáze vývoje tvoří vstupní bod do fáze další. Pokud se toto dodržuje důsledně a v počátečních fázích nastane nějaká chyba, stojí její následná oprava hodně úsilí a prostředků. Nespornou výhodou je však dokumentace všech vývojových etap a s tím související možnost určení v jaké fázi se projekt nalézá. Postupy typu vodopád se dnes často kombinují s častým jednotkovým testováním a objektovým přístupem. Počátek analýzy pomocí objektové metodiky sahá na začátek 90tých let minulého století. S rozvojem objektového programování přichází metodiky jako OOA/OOD (Object-Oriented Analysis/Object-Oriented Design) od pánů Coada a Yourdona, které vyzdvihují modelování reálného světa na základě objektů (každé podstatné jméno je vlastně objekt) a jejich chování (metody objektu). Z dalších můžeme jmenovat OMT (Object-Oriented Modeling) od J. Rumbaugha, nebo metody pánů Boocha nebo Jacobsona. Objektově orientované metodologie kladou oproti strukturovaným důraz na souhru a komunikaci mezi jednotlivými úseky vývoje systému. Mezi metodiky založené čistě na jazyce UML patří UP (Unified Process) a URP (Unified Rational Process), který z něj vychází. Tyto metodiky jsou inkrementální a iterativní. To si můžeme představit jako několikanásobné opakování životního cyklu vodopád na jednotlivé části vývoje systému. Metodiky nazvané post-UML přicházejií s hodně odlišným přístupem k vývoji softwaru. Jejich stavební kameny tvoří prototypování a silné testování nejen výsledného systému nebo jeho částí, ale i všech malých jednotek. Vývoj pak probíhá tak, že se vytvoří nejprve hrubý prototyp, který je předložen zákazníkovi a dle jeho požadavků se upravuje, vylepšuje a opatřuje novými vlastnostmi.


3

2.2 Použité metodiky (a technologie) Při analýze a návrhu mé aplikace jsem se nedržel striktně žádné z výše uvedených metodik. Podle mého názoru nemá přesné dodržování jednotlivých kroků některé metodiky, v případě méně rozsáhlého systému (na kterém pracuje navíc jen jeden vývojář), přílišný smysl a podle některých autorů může být toto i u velkých projektů zhoubným faktorem. Metodika UP (URP) popisuje kompletní postup objektově orientované analýzy, návrhu a tvorby software, který je dle mého názoru správný (pominu-li post-UML metody, které můžeme těžko srovnávat s klasickými metodikami), nicméně tvorba veškeré definované dokumentace by byla časově velmi náročná a v mém případě zbytečná. Zvolil jsem tedy postup, který odpovídá klasickému vývojovému cyklu IS a byl přednášen v předmětech softwarového inženýrství (dále jen SI) v kombinaci s iterativní metodou, která je dnes víceméně běžná. Jedná se tedy o strukturovanou metodu (úvodní studie, analýza, návrh, implementace, testování a instalace), která je podpořena modelovacími technikami z jiných metodik a doplněna o iterativní způsob vlastní realizace cílového systému. Iterativním způsobem realizace rozumím to, že výsledný stabilní systém vznikne v rámci několika verzí. První, alfa verze systému bude výchozí pro další a její vytvoření jsem si stanovil za cíl této práce. Rozdíl tohoto postupu od klasické iterativní metody je v tom, že požadavky na systém jsou již předem známy (strukturovaná část), ale alfa verze je nemusí implementovat úplně všechny (měla by implementovat stěžejní části aplikace a být připravena na jednoduché napojení dalších částí). U klasického iterativního postupu vznikají nové požadavky v průběhu vývoje, což podle mého názoru u aplikace opírající se o strukturu databáze není šťastný způsob. Sled jednotlivých fází strukturované části vývoje IS je prakticky totožný s metodikou Modern Structured Analysis od E.Yourdona. Použité techniky jsou však jiné. Jako hlavní modelovací nástroj jsem použil jazyk UML. V úvodní studii jsem si pro kontextový diagram propůjčil DFD (Data Flow Diagram) z OOA/OOD od výše zmíněného E. Yourdona a pro databázové modelování metodu ERM (Entity Relationship Modeling) a její ER diagram.

2.2.1 UML UML je v softwarovém inženýrství univerzální grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. Nabízí standardní způsob zápisu, jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. Neobsahuje však způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy. Důvodem mého výběru UML jakožto hlavní technologie použité pro analýzu a návrh je právě výše uvedený fakt, že podporuje objektový přístup, nicméně je univerzální a nepředepisuje žádnou metodiku. Můžeme ho tedy používat dle vlastního uvážení pro modelování prakticky čehokoliv. Dalším důvodem mého výběru je předešlá praxe s tímto nástrojem z předmětů SI.

4


2.2.1.1 Použité a dostupné diagramy UML Při analýze a návrhu jsem samozřejmě nepoužil všechny dostupné prostředky tohoto jazyka. Pro mou potřebu bohatě stačily jen některé prvky, zejména pak stavové diagramy, diagramy aktivit a užití. Následuje přehled dostupných diagramů včetně jejich rozčlenění do skupin:

strukturní diagramy o diagram tříd (class diagram) o diagram komponent (component diagram) o diagramy vlastní struktury (composite structure diagram) o diagram nasazení (deployment diagram) o diagram balíčků (package diagram) o diagram objektů (object diagram), též se nazývá diagram instancí diagramy chování o diagram aktivit (activity diagram) o diagram užití (use case diagram) o stavový diagram (state machine diagram) diagramy interakce o sekvenční diagram (sequence diagram) o diagram komunikace (communication diagram, dříve collaboration diagram) o diagram časování (timing diagram)

2.2.2 ER modelování Pro datovou analýzu a s ní spjatý návrh struktury databáze jsem si vybral metodu ER. Podle mého názoru věrně vystihuje fyzickou situaci uvnitř relačního SŘBD (Systém Řízení Báze Dat) a mám s touto metodou poměrně dobré zkušenosti. Datovou analýzu jsem pak složil ze dvou hlavních částí. Ze samotného ER diagramu a z popisu reprezentace dat s bližší specifikací identifikátorů ukládaných dat a jejich typů.

Kapitola 3. Úvodní studie

5

3 Úvodní studie 3.1 Rámcový plán projektu Celý projekt můžeme rozdělit do pěti hlavních částí. Mezi nimi může vést velmi tenká hranice a zejména části úvodní studie a analýzy mnoho autorů nedělí stejně nebo je naopak slučují do části jedné – analytické. Mé rozdělení je následující:

Úvodní studie vytyčení cílů a hrubá definice požadavků na budoucí software stanovení hranic systému a případů užití

Analýza podrobné stanovení požadavků na systém datová analýza (návrh databázové struktury a reprezentace dat) modelování některých částí systému (stavové diagramy/diagramy aktivit)

Návrh návrh vlastních tříd systému (členění systému, komponenty) návrh uživatelského rozhraní definice akceptačních tesů a testů použitelnosti

Implementace alfa verze vlastní implementace včetně jednotkového testování integrace modulů včetně integračního testování (korektnost spolupráce modulů) tvorba instalační sady

Testování a instalace alfa verze tvorba instalační příručky instalace u zákazníka validační a systémové testování

Iterativní dokončení vývoje na základě alfa verze V této části projektu se začne vývoj ubírat směrem spíše extrémního programování, testování bude probíhat v prostředí provozu a hlášené chyby (se kterými se samozřejmě počítá) budou postupně odstraňovány. Dále budou doimplementovány dosud nerealizované funkčnosti (se kterými však bude od začátku počítáno). Tato část bude probíhat až po skončení práce na tomto textu.

6


3.2 Deklarace záměru Cílem práce je navrhnout a implementovat softwarový produkt, který bude programovým řešením fakturačního a evidenčního systému malé telekomunikační společnosti BCH. Aplikace by měla usnadnit celkový přehled a orientaci v zákaznické databázi společnosti a to zejména pomocí její snadné editace a filtrování výpisů podle různých kritérií. Dále bude podporovat vytváření detailních výpisů hovorů, tvorbu faktur, seznamů kreditních karet a dalších materiálů. Export informací do XLS formátu a jejich tisk by měly rovněž zefektivnit další zpracování informací. Tvorba reportů s výnosy a náklady za dané období (statistických přehledů) a evidování činnosti jednotlivých uživatelů systému by mohla být výhodná pro vedení společnosti.

3.2.1 Hlavní rysy aplikace

import vstupního, textového souboru s výpisy hovorů za dané období a jeho uložení do databáze (soubor poskytuje provider hovorů) import různých verzí sazebníku a jejich uložení v databázi (CSV formát) evidence zákazníků společnosti tvorba detailních výpisů hovorů k danému číslu tvorba faktur pro zákazníky na základě výpisů a sazebníků a jejich evidence podpora exportu do formátu XLS, tisku a zasílání emailů evidování činnosti uživatelů

Systém bude navržen s ohledem na maximální spolehlivost a další rozšiřitelnost. Přesto, že je primárně určen pro běh na platformě Windows, bude díky zvolené implementační technologii Java multiplatformní.

3.3 Odborný článek Hlavní motivací projektu CRM & billing system je požadavek malé telekomunikační společnosti na vytvoření aplikace pro evidenci zákaznické agendy a tvorbu fakturací s výpisy hovorů za dané fakturační období. Aplikace by měla usnadnit orientaci v zákaznické databázi a zautomatizovat proces vystavování faktur a tvorby zmiňovaných výpisů hovorů. Systém se bude skládat ze dvou částí. První část, která bude tvořit jakési datové základy celého systému, bude reprezentována relačním databázovým systémem. Systém řízení báze dat (dále jen SŘBD) se bude starat o korektní uložení všech informací, které má aplikace uchovávat a bude nainstalován na serveru, nebo nějaké permanentně běžící stanici, která se tímto stane databázovým serverem. Existuje mnoho SŘBD, ale naše aplikace bude vystavěna na software MySQL 5.0 Community Edition (dále jen MySQL). Je to spolehlivý, léty a uživateli prověřený databázový server a existuje k němu veškerá potřebná dokumentace a spousta nástrojů, které jsou jako samotné MySQL zdarma k dispozici. Druhá část systému bude tvořena klientskou stranou aplikace. Z pohledu uživatele bude tvořit vlastně celý program, neboť komunikace klientské a serverové části bude probíhat zcela transparentně.


7

Ponechme nyní stranou členění systému a role jeho jednotlivých částí a berme ho jako jednu kompaktní aplikaci. Tato aplikace bude zajišťovat několik funkcí. Jednak funkci CRM (Customer Relationship Management), neboli funkci zákaznického adresáře, který mimo kontaktních údajů udržuje i další informace spjaté se zákazníkem (například evidování plateb nebo vystavených faktur). Dalšími funkcemi aplikace budou: vystavování faktur za provedené hovory, vystavování detailních výpisů hovorů, tvorba reportů prezentujících shrnutí výnosů a nákladů společnosti k danému období, spravování ceníků hovorů, podpora tisku, exportu do a importu z XLS formátu a zasílání emailů. Dále bude systém podporovat evidenci plateb jednotlivých zákazníků (včetně přehledu neplatičů), přípravu obálkových štítků pro tisk a v neposlední řadě také logování činnosti uživatelů systému a částečnou integraci s klientským desktopem (používání výchozího poštovního klienta, aplikace dávkového tisku,…). K zákazníkům bude systém uchovávat jak základní kontaktní informace jako jsou jméno, příjmení, adresa a kontaktní telefon, tak adresy kontaktních osob (neboť zákazníkem nemusí být jen samotná fyzická osoba ale i společnost), informace o zákaznických číslech, platbách a tvořených fakturách. Dále se budou evidovat záznamy o zákaznickém servisu a problémových hlášeních a jiné podstatné informace. Co se týče ceníků hovorů. Systém jich bude moci evidovat libovolné množství. Zdrojem dat ceníků budou textové soubory pevného formátu. Soubor bude obsahovat vždy destinaci a sazbu. Aplikační rozhraní umožní jednoduchý import ceníku do systému včetně jeho pojmenování a záznamu data importu. Data o provedených hovorech jednotlivými zákazníky zasílá zprostředkovatel hovorů v textovém souboru pevně daného formátu. Tyto soubory jsou dvojího druhu, bez ohledu na význam jmen (v tomto kontextu není význam podstatný) – jeden je pro CS/CPS zákazníky a druhý pro 800 zákazníky. Informace obsažené v souborech jsou stejné, nicméně formát se liší. Aplikace bude podporovat oba vstupní formáty. Importem dat s výpisy hovorů vznikne nový projekt. Vytváření faktur, detailních výpisů hovorů a reportů s přehledem výnosů a nákladů bude vždy probíhat v rámci nějakého projektu. Dá se říci, že jeden vstupní soubor bude tvořit jeden projekt a jeden projekt bude tvořit jedno fakturační období pro danou skupinu zákazníků. K projektům se bude možno vracet, což zajistí jejich ukládání do databáze (ostatně jako kterékoliv jiné persistentní datové části s výjimkou některých nastavení). Vytvoření detailního výpisu hovorů se bude provádět automaticky po založení projektu. Zobrazí se přehled všech čísel, ze kterých bylo v rámci daného projektu voláno. Ke každému číslu systém přiřadí jméno zákazníka a název sazebníku, dle kterého jsou danému číslu účtovány ceny za provedené hovory. Tento přehled bude umožňovat detailní náhled na libovolné číslo, který zobrazí seznam všech realizovaných hovorů z daného čísla s informací o jejich délkách, tarifu, celkové ceně a dalších podstatných atributech. Pokud bude nalezeno číslo, které nevlastní žádný evidovaný klient, zobrazí se varovné hlášení. Stejně tak zobrazí program varování, pokud bude nalezena destinace volání, ke které neexistuje v používaném ceníku sazba (neboli destinace se v ceníku nevyskytuje). Výpis hovorů (k danému číslu) půjde exportovat do souboru formátu MS Excel (XLS). Vzhled listů v souboru bude určovat šablona.

8


Pro vystavení faktury budou používány informace ze zákaznického adresáře (zejména pak kontaktní informace a typ platby) a z projektu, v jehož rámci bude faktura vystavována. Aplikace bude muset nejprve vystavit výpisy hovorů ke každému zákaznickému číslu a exportovat je do formátu XLS. Každý výpis bude obsahovat celkovou účtovanou cenu za dané číslo. Tyto výpisy projdou manuální kontrolou zaměstnanci společnosti, která bude provedena v MS Excel. Po kontrole dojde k zpětnému importu výsledných cen (za jednotlivá čísla) ze souborů s výpisy ve formátu XLS do systému. Pomocí těchto cen program poté vystaví zákazníkům faktury. Částka na faktuře bude sumou za všechna klientská čísla. Primárním fyzickým cílem faktury bude soubor XLS, jehož vzhled se bude (stejně jako u výpisu hovorů) řídit šablonami. Vystavování faktur by šlo samozřejmě více zautomatizovat, nicméně uvedený postup je specielním přáním společnosti BCH. Další zajímavou vlastností vytvářeného software by měla být možnost zasílání emailu přímo z aplikačního rozhraní. Systém by měl podporovat zasílání hromadných zpráv skupinám zákazníků, které bude možné vybírat ručně nebo dle určitých kritérií (zejména dle typu zákazníka). Systém by měl rovněž podporovat užití výchozího poštovního programu pracovní stanice. Tisk obálkových štítků a složenek by měl rovněž ulehčovat práci. V systému se budou vyskytovat dva typy uživatelů. Privilegovaný a normální. Jediný rozdíl mezi nimi bude ten, že privilegovaný uživatel bude moci zakládat uživatelské účty. Každý, kdo bude se systémem pracovat, se bude muset nejprve přihlásit svým uživatelským jménem a heslem. Tento mechanismus poslouží primárně k evidování činnosti uživatelů (v tomto kontextu zaměstnanců). Vedlejším, ale neméně podstatným účelem bude zamezení škody, která by mohla vzniknout při přístupu nezasvěceným uživatelem. Ke každému uživateli bude systém evidovat jeho soukromé nastavení, zejména pak systémové cesty k adresářům zdrojů a cílu dat a nastavení jména a zpětné adresy elektronické pošty. Nastavení bude vztaženo vždy k uživateli a pracovní stanici. Poslední uložené nastavení bude rovněž zálohováno v databázi. V důsledku to znamená, že ke každému uživateli bude po přihlášení do systému načteno jeho nastavení pro klientskou stanici u které se právě nachází. Pokud na disku stanice nebude nalezeno jeho uložené nastavení, vytvoří se nové na základě dat načtených z databáze (nastavení, které uložil z nějaké stanice naposledy nebo prázdné nastavení). Každý uživatel bude mít možnost měnit si své vlastní heslo, privilegovaný pak měnit všechna hesla. Co se týče zabezpečení ukládaných dat ve smyslu zálohování databáze – to systém řešit nebude. Přenechá toto specifikum správci serveru, na kterém poběží používaný SŘBD. Vzhledem k charakteru výše zmíněného MySQL postačí pouze pravidelná a kompletní záloha adresáře, kde budou nainstalované datové soubory serveru. Implementace databáze, jakožto oddělené časti systému, přináší několik výhod. Jednou z nich je jednoduchá přenositelnost dat do libovolného jiného prostředí (například při změně SŘBD může zůstat stávající klientská aplikace nebo naopak při změně klientské aplikace budou všechna data nadále k použití). Uvažovali-li bychom do budoucna, bylo by možné vytvořit např. internetovou aplikaci, kde by si mohli uživatele prohlížet informace o svých provedených hovorech, jejich cenách, atp. a měnit kontaktní informace na sebe a kontaktní

9


osoby. Dále by bylo možné zařídit přístup k této databázi z libovolného místa s přístupem na www a tím umožnit práci i z jiných lokací než z kanceláře společnosti.

3.4 Diagram kontextu

Ilustrace 3.1 - Kontextový diagram

3.4.1 Bližší specifikace kontextu 1.a) plnění zákaznické databáze, zakládání a rušení projektů, tvorba faktur, výpisu a reportů, zasílání emailů, tisk, exportování do XLS,PDF, HTML,RTF, import z XLS, změna hesla, změna nastavení, ostatní nutné vstupy pro práci se systémem 1.b) zobrazování přehledů uživatelů a čísel, informace o fakturách, informace o výsledcích exportu do XLS, importu z XLS a zasílání emailu, přehledy neplatičů, zobrazování průběhu delších činností systému, ostatní reakce na práci uživatele 2.a) jako 1.a + správa uživatelských účtů systému 2.b) jako 1.b + zobrazování historie kteréhokoliv uživatele 3.a) potvrzení platnosti kreditních karet, potvrzení plateb (do systému zanese uživatel) 3.b) odeslání faxu s výpisem kreditních karet pro jejich validaci (fyzicky uživatelem)

10


3.5 Případy užití Níže uvedené případy užití (Use Cases) vznikaly postupně v rámci několika sezení se zákazníkem. Při jejich vytváření jsem postupoval metodou shora dolů, tedy nejprve jsem se snažil vyhledat nejobecnější případy, které jsem po diskusi vždy rozvinul do podrobnějších diagramů. Jak se později ukázalo, byl tento způsob výhodný, neboť sám zákazník si při komunikaci uvědomil spoustu aspektů, které by ho při pouhém vytváření výčtu požadavků na systém vůbec nenapadly.

3.5.1 Diagramy případů užití 3.5.1.1 Výchozí Use Case diagram

Ilustrace 3.2 - Use case diagram nejvyšší úrovně

Na obrázku 3.2 je zobrazen use case diagram nejvyšší úrovně, tedy nejnižšího detailu rozpracování. Diagram by měl být věrnou grafickou kopií odborného článku s vynechanými detaily. Levá část zobrazuje funkčnosti systému, které by měla obsahovat první alfa verze, určená k nasazení a testování u zákazníka. Pravá část diagramu (tedy funkčnosti přístupné pouze privilegovanému uživateli) není pro společnost BCH významná a bude v alfa verzi pouze připravena (kompletní podpora v databázi, ale jen částečná na klientské straně).


11

3.5.1.2 Use Case diagramy většího detailu Na následujících několika ilustracích jsou k vidění podrobněji rozpracované případy užití z ilustrace 3.2. Diagramy budou sloužit jako výchozí body pro pozdější implementaci jednotlivých funkčností cílové aplikace. Měly by graficky znázorňovat jednotlivé uživatelské požadavky na systém a dokumentovat tak hrubé chování aplikace. Use Case diagramy budou později zároveň oporou pro akceptační testování. Nebude totiž možnost pro napadení aplikace z hlediska chybějící klíčové funkčnosti, pokud tato nebude uvedena v nějakém z případů užití. Samozřejmě s ohledem na hrubý detail diagramů ve vztahu ke všem implementovaným podpůrným funkčnostem nutných pro korektní fungování klíčových funkčností, jež jsou vyjádřeny právě všemi případy užití.

Ilustrace 3.3 - Větší detail případů užití Spravovat CDR projekty, Spravovat sazebníky a Spravovat klienty

12


Ilustrace 3.4 - Větší detail případů užití Vytvářet výstupy, Tisknout a exportovat, Zasílat emaily a Spravovat uživatelské nastavení

13


Ilustrace 3.5 - Větší detail případů užití Spravovat uživatele

3.5.2 Textová specifikace některých případů užití Diagramy případů užití slouží primárně k určení aktérů a vymezení hranic systému. Přestože se jedná již o podrobnější analýzu, ponechávám i tuto část v úvodní studii, protože dle mého názoru diagramy případů užití dokreslují celkovou hrubou představu o fungování systému, což do úvodní studie nepochybně patří. Následuje textová specifikace některých případů užití. U všech se předpokládá, že je do systému přihlášen uživatel s příslušným oprávněním (tedy účastníkem případů je uživatel a vstupní podmínkou je přihlášení do systému). Alternativou k textové specifikaci mohou být diagramy aktivit, textová specifikace mi však přijde v tomto případě výhodnější. Založit projekt ID:

UC-ZalozitProjekt

Tok událostí: 1. Uživatel zvolí příkaz pro založení nového projektu. 2. Systém zobrazí formulářový dialog pro založení projektu. 3. Uživatel vyplní formulář. 3.1. zahrnout (UC-VybratVstupniSoubor) 4. Systém načte soubor a zkontroluje konzistenci dat (v klientské databázi jsou všechna čísla, která jsou ve vstupním souboru). 4.1. Systém dovolí uložit jen konzistentní data a v případě nutnosti zobrazí dialog. 5. IF(zobrazen dialog v 4.1) IF(uživatel zvolí uložit) 6 ELSE IF (uživatel zvolí vybrat nový zdroj) 4 ELSE IF (uživatel zvolí konec) BREAK 6. Systém uloží všechna konzistentní data a do logu uloží informaci o vytvoření nového projektu.

Smazat projekt ID:

UC-SmazatProjekt

Tok událostí: 1. Uživatel vyvolá volbu pro přehled projektů. 2. Systém zobrazí dostupné projekty a nabídku akcí. 3. Uživatel vybere projekt a zvolí akci smazat. 4. Systém si vyžádá potvrzení ke smazání. 5. IF(uživatel zvolí v 4 ANO) 5.1. Systém smaže projekt a všechna s ním související data (všechny hovory provedené v rámci projektu a vytvořené faktury za dané hovory) 5.2. Systém uloží do logu záznam o vymazání příslušného projektu

Textová specifikace případů užití 1 – Založit projekt a Smazat projekt

14

Kapitola 3. Úvodní studie Vybrat vstupní soubor

ID:

UC-VybratVstupniSoubor

Tok událostí: 1. Uživatel zadá volbu pro výběr vstupního souboru. 2. Systém zobrazí příslušný dialog. 3. Uživatel vybere soubor a potvrdí výběr. 4. Systém předá výběr nadřazené komponentě.

Založit sazebník ID:

UC-ZalozitSazebnik

Tok událostí: 1. Uživatel zadá příkaz pro založení nového sazebníku. 2. Systém zobrazí formulářový dialog. 3. Uživatel vyplní údaje. 3.1. zahrnout (UC-VybratVstupníSoubor) 4. Systém načte vstupní soubor a pokud bude bez chyb uloží ho do databáze a zobrazí sazebník v tabulce.

Textová specifikace případů užití 2 - Vybrat vstupní soubor a Založit sazebník Editovat klienta ID:

UC-EditovatKlienta

Tok událostí: 1. Uživatel zadá příkaz pro editování klienta (poklepání na stávajícího nebo vytvoření nového) 2. Systém zobrazí formulář pro editaci uživatelských atributů. 2.1. zahrnout (UC-SpravovatKontaktniOsoby) 3. Uživatel provede potřebné změny 4. IF(uživatel zvolí uložit) 4.1. Systém uloží všechny změny provedené ve všech atributech a zároveň uloží záznam o provedených změnách do logu (kdo a jakou změnu vytvořil). 5. IF(uživatel zavře dialog) 5.1. Systém z kontroluje, jestli byly provedeny nějaké změny, když ano zobrazí dialog pro uložení. 5.1.1. IF(uložit ANO) 3.1

Spravovat kontaktní osoby ID:

UC-SpravovatKontaktniOsoby

Tok událostí: 1. Uživatel zadá příkaz k editaci nebo vytvoření kontaktní osoby. 2. Systém zobrazí dialog s přehledem kontaktních osob daného zákazníka a jejich vlastnostmi. 3. Uživatel upraví nebo vyplní formulář. 4. IF(uživatel zavře dialog) informace budou zahozeny 4.1. ELSE IF(uživatel potvrdí OK) systém uloží všechny informace z formuláře a zaeviduje všechny změny do logu

Textová specifikace případů užití 3 - Editovat klienta a Spravovat kontaktní osoby Vytvářet faktury ID:

UC-VytvaretFaktury

Tok událostí: 1. Uživatel zadá příkaz pro vytvoření faktur. 2. Systém zobrazí dialog pro vytvoření faktur. 3. Uživatel vyplní všechny požadované údaje. Zejména pak cesty k souborům s výpisy hovorů v XLS, které budou obsahovat konečné ceny za číslo. 4. Systém importuje ze zadaných souborů klientské telefonní číslo a cenu za provedené hovory. 4.1. Systém přiřadí importované údaje k zákazníkům a vytvoří datový model faktur – ke každému zákazníkovi jedna faktura s výslednou cenou za všechna jeho telefonní čísla. 4.2. Systém exportuje datové modely faktur do formátu XLS do uživatelem zadané složky. 5. IF(uživatel zvolil uložení faktur do databáze) systém uloží data faktur do databáze (přiřadí fakturu ke zvolenému projektu a k danému klientovi).

Vytvářet seznam kreditních karet ID:

UC-SeznamKreditnichKaret

Tok událostí: 1. Uživatel zadá příkaz pro vytvoření seznamu kreditních karet pro ověření bankou. 2. Systém vyhledá v rámci aktivního projektu klienty,kteří mají nastavený typ platby kreditní kartou a mají vytvořenou fakturu. 3. Systém vytvoří a zobrazí náhled na seznam kreditních karet s částkami k úhradě. 4. Uživatel zvolí požadovanou akci (tisk nebo export) nebo dialog zavře. 4.1. IF(uživatel zvolí tisk) systém zobrazí standardní tiskový dialog a po potvrzení provede tisk. 4.2. ELSE IF (uživatel zvolí export) systém zobrazí dialog pro zvolení cíle exportu a po potvrzení provede export Vstupní podmínka: Otevřený nějaký projekt

Textová specifikace případů užití 4 - Vytvářet faktury a Vytvářet seznam kreditních karet

15

Kapitola 3. Úvodní studie Zasílat emaily ID:

UC-ZasilatEmaily

Vybrat příjemce ID:

UC-VybratPrijemce

Tok událostí: Tok událostí: 1. Uživatel zadá příkaz pro zaslání emailu. 1. Systém zobrazí dialog s přehledem klientů a 2. Systém zobrazí nové okno integrovaného SMTP kontaktních osob, kterým je možné zaslat email. klienta. 2. Uživatel provede výběr (ručně nebo pomocí filtrů). 3. Uživatel zvolí akci. 3. Po potvrzení systém předá seznam cílových adres 3.1. IF(uživatel zvolí výběr příjemců) zahrnout nadřazené komponentě (internímu klientovi nebo (UC-VybratPrijemce) výchozí poštovní aplikaci). 3.2. IF(uživatel zvolí výběr příloh) zahrnout (UC-VybratPrilohy) 3.3. IF(uživatel zvolí použití výchozí aplikace) zahrnout (UC-PouzitVychoziEAplikaci) 4. Po potvrzení systém odešle email. - Zahrnuté případy UC-VybratPrilohy a UC-PouzitVychoziAplikaci nemá význam rozepisovat. Textová specifikace případů užití 5 - Zasílat emaily a Vybrat příjemce

3.6 Stanovení dosažitelných cílů vlastní diplomové práce Každému projektu a jeho části, by se měly na počátku stanovit reálně dosažitelné cíle. Jinak by tomu nemělo být ani u diplomové práce. První z cílů této práce (analýza potřeb) je zhotovení úvodní studie a analytické dokumentace k celému projektu (úvodní studie je již hotová). Jedná se tedy o jasné vymezení hranic systému a podrobné zjištění všech požadavků na cílový systém. Druhým cílem je provedení návrhu struktury systému s ohledem na možnost co nejméně komplikovaného dalšího rozšíření na základě vytvořené analytické dokumentace. V realizační části práce bych rád implementoval první verzi systému, která by měla obsahovat kompletně odladěnou serverovou část, tedy databázi, podporující všechny definované požadavky na systém a alfa verzi klientské části aplikace, jež by měla implementovat stěžejní části cílové aplikace - tedy pro uživatele transparentní jádro komunikující s databází a připravenou podporu všech významných rysů projektu (Vlastní logika firemního procesu, tedy počítání výsledných fakturovaných cen, tvorba reportů, faktur a výpisů hovorů. Dále pak metody pro tisk, zasílání emailů, export a import z XLS formátu a logování uživatelských činností.). Do uživatelského rozhraní (dále GUI), které znamená pro uživatele „vlastní program“, bych rád napojil implementaci nejvíce žádaných požadavků na cílový systém (což by měla být pouhá kombinace prvků z transparentního jádra aplikace a prvků GUI). Dalším cílem práce je vytvoření instalačního balíčku z celé aplikace, který ještě před odevzdáním tohoto textu nainstaluji u zákazníka a tím odstartuji druhou polovinu celkového projektu – testování a opravování vzniklých chyb a dokončení implementace méně náročných prvků systému, což by podle mého odhadu mělo být pouze dodělání GUI ve smyslu implementace metod akčních prvků rozhraní za použití již implementovaných složitějších funkčností.

16


17

Kapitola 4. Analýza

4 Analýza V této části textu budou zformulovány analyzované potřeby společnosti BCH a to ve formě podrobného katalogu požadavků. Z katalogu požadavků dále vyplývá model databáze, který je velmi podstatný pro korektní funkčnost celého systému. Na tomto místě bych se rovněž rád zmínil o procesu získávání informací od zákazníka. V teorii SI je tradováno, že tato úloha patří k jedné z nejpodstatnějších a nejtěžších v celém průběhu analýzy. Tento fakt mohu jen potvrdit. Osobně jsem absolvoval několik jednání, jejichž hlavní náplní bylo získání odpovědí na mé dotazy. Přestože se některé mé otázky neměnily, odpovědi na ně byly pokaždé o něco jiné. Iterativním způsobem došlo nakonec k určité shodě, jejíž výsledky jsou uvedeny dále.

4.1 Slovníček používaných pojmů a zkratek BCH 800 vstup BDE CDR CDR projekt CLI CLI skupina CPS CRM CS CS/CPS vstup CVC DIČ DRM GPL IČ JRE MDB OpenSource Report SŘBD

klientská společnost jeden ze dvou typů vstupního souboru s informacemi o provedených hovorech od poskytovatele, sloupce v něm jsou odděleny tabulátorem Borland Database Engine (softwarový nástroj, který používají aplikace psané v Delphi pro práci s datovými zdroji) detailní výpis hovorů k jednomu CLI celek, obsahující všechny CDR výpisy a jiné informace za jedno fakturační období a danou skupinu zákazníků; skupina zákazníků je určena typem vstupního souboru (800 nebo CS/CPS) jedno zákaznické číslo klientská čísla se mohou sdružovat do skupin (například jeden klient může mít více poboček, každá pobočka je pak jedna CLI skupina) typ služby, kde předvolbu vytáčí operátor Customer Relationship Management (software pro správu zákaznické databáze) typ služby, kde předvolbu vytáčí zákazník jeden ze dvou typů vstupního souboru s informacemi o provedených hovorech od poskytovatele, sloupce v něm jsou odděleny středníkem verifikační kód platební karty identifikační číslo plátce daně dceřiná společnost společnosti BCH General Public Licence (typ licence) identifikační číslo Java Runtime Enviroment (software, který umožňuje běh aplikací napsaných v jazyce Java) typ databázových souborů MS Access software s volně dostupným zdrojovým kódem dokument s rozepsaný předběžnými výnosy a náklady za daný CDR projekt Systém Řízení Báze Dat (neboli databázový server ve smyslu software) Tabulka 4.1 – Slovníček pojmů a zkratek

18


4.2 Současné fakturační řešení 4.2.1 Stručná charakteristika Aplikace, kterou společnost BCH používá v současné době není zcela funkční, je napsána v Delphi a neexistují k ní zdrojové kódy. Databáze využívá datových souborů MDB, ke kterým přistupuje pomocí BDE a neumožňuje evidovat všechny požadované informace. Funkčnosti aplikace obsahují chyby, které náhodně způsobují neuložení zadaných údajů nebo pád celé aplikace. Korektně funguje export do XLS, pomocí něhož jsou vytvářeny faktury a výpisy hovorů, které jsou rovněž správné. Aplikace nepodporuje tisk ani zasílání emailů a ve vytvořených reportech se vyskytují chyby.

4.2.2 Migrace stávajících dat Jak jsem se již zmínil, data jsou ukládána do prostředí MS Access. Data projektů a informace o nich se ukládají do binárních souborů neznámého formátu a jejich migrace je prakticky nemožná, nicméně není vůbec nutná. To se nedá říci o zákaznických datech. Jejich migrace se bude řešit skrze různá proprietální řešení. V úvahu by zde přicházela dvě možná řešení. První z nich je připojení se ke stávající MDB databázi za pomocí ODBC rozhraní a vyřešit migraci přímo z aplikace nebo pomocí podpůrného modulu. Druhým způsobem by pak byl nejspíše export stávajících dat do CSV souboru a vytvoření skriptu, který soubor načte a uloží do nové databáze. Problematikou přenosu se v této práci zabývat nebudu, bude řešena až po nasazení aplikace, důkladném otestování a opravení chyb.

4.3 Podrobný katalog požadavků a bližší specifikace 4.3.1 Požadavky na HW a SW Co se týče potřebného HW, společnost BCH má vlastní, výkonnostně postačující stanice, na nichž je nainstalován operační systém platformy Windows NT 5.x. (XP). Jako minimální velikost operační paměti doporučuji 512 MB (vzhledem k nutnosti spouštění JRE a vytváření náhledů na tisk, které mohou zabírat poměrně velkou paměťovou kapacitu). Na serverové straně aplikace poběží systém řízení báze dat MySQL 5.0 Community Edition. Tento software je dostupný pod licencí GPL, tedy zcela zdarma. Je léty prověřený uživateli a vzhledem k tomu, že se jedná o OpenSource projekt, je stále vyvíjen a zlepšován. Poslední stabilní verze je 5.0. Nároky na HW jsou zde minimální, vzhledem k tomu, že na serveru nebude běžet jen tento SŘBD, doporučuji alespoň PIII-660MHz s 512 MB RAM .

4.3.2 Požadavky na vytvářený software 4.3.2.1 Serverová část Serverová část aplikace bude tvořit jádro celého systému. Bude se opírat o databázový systém MySQL, jež bude uchovávat veškerá data se kterými bude manipulováno. Evidované informace jsou uvedeny níže. V závorkách jsou poznámky upřesňující danou položku nebo významnější implementační detail.

Kapitola 4. Analýza 4.3.2.1.1 Informace uchovávané o zákaznících

obecné název společnosti (možnost uchování dvou názvů) jméno kontaktní osoby (společnost) (možnost více osob) příjmení, jméno a titul (osoba) IČ, DIČ adresy fakturační a korespondenční adresa - ulice, číslo popisné, PSČ, město, stát kontaktní osoby telefon mobilní telefon (možno i více) fax email (možno i více) - použít email k zasílání CDR ? www druh platby bankovním převodem kreditní kartou složenkou inkasem hotově a jinak typ zákazníka (možnost editovat typy) typ vyúčtování na BCH na DRM poznámky kreditní karta typ karty (možnost editovat typy) číslo karty CVC platnost do (upozorňování před vypršením) poznámky nastavení pro výpisy hovorů (CDR) zasílat CDR emailem ? (checkbox) seznam emailových adres pro zasílání (určeno z kontaktních osob) seznam telefonních čísel zákazníka (CLI) CLI skupiny vystavené faktury a jejich nastavení typ faktury, která se vystavuje inkaso kreditní karta převod složenka cash

19

20


seznam vystavených faktur (možnost nahlédnout na detaily) zasílat faktury emailem ? (checkbox) problémová hlášení datum nahlášení (resp. vytvoření záznamu) zaměstnanec BCH, který hlášení zaevidoval datum uzavření řešení problému zaměstnanec BCH, který hlášení uzavřel název klienta (z db) kontaktovat do kontaktovat na číslo problém problémová čísla (CLI) popis problému technický partner jméno technického partnera (název firmy) kontaktní informace číslo poznámky k výsledku řešení zákaznický servis datum kontaktování BCH zákazníkem důvod volání sdělení

4.3.2.1.2 Informace evidované k fakturám

datum vystavení datum splatnosti variabilní symbol číslo má tvar 00 CISLO_FAKTURY je pro první fakturu v každém novém roce 1 ROK se vztahuje k fakturačnímu období a ne k roku, kdy je faktura vystavena datum uhrazení uhrazeno ?(checkbox) částka částka v USD

4.3.2.1.3 Informace sazebníků

jméno sazebníku verze sazebníku datum jeho importu do systému samotné informace o sazbách destinace X sazba


21

4.3.2.1.4 Informace o klientských číslech a o všech provedených hovorech

Data z této části databáze budou sloužit k vytváření vlastních výpisů a fakturací. Prakticky se jedná o seznam všech poskytovaných telefonních čísel a o informace ze vstupních souborů s výpisy hovorů.

informace k číslu (CLI) číslo (CLI) typ služby CS (nutno vytáčet předvolbu) CPS (předvolbu vytáčí operátor) typ čísla pevná linka fax mobilní vlastník (klient) CLI skupina

informace o hovorech (v závorkách jsou uvedeny odpovídající názvy ze vstupního souboru s výpisem) klientské číslo CLI (ORIGINAL NUMBER) volané číslo (DESTINATION NUMBER) datum (DATE) čas (TIME) délka trvání hovoru (DURATION) cena jedné minuty hovoru (RATE) cena hovoru, naúčtovaná poskytovatelem (AMOUNT) účtovací měna (CURRENCY) pásmo (špička, mimo špičku) (Period) destinace volání (DESTINATION) mezinárodní destinace (INTERNATIONAL DESTINATION)

4.3.2.1.5 Systémové informace

uživatelé jméno příjmení email telefon uživatelské jméno uživatelské heslo oprávnění logování přístupů uživatelů datum a čas přihlášení do systému (2 měsíce zpět) datum a čas odhlášení ze systému (2 měsíce zpět)

22


logování změn v databázi klientů kdo změnu provedl kdy změnu provedl informace o provedené změně tabulka, ve které byla změna provedena změněný atribut stará a nová hodnota pokud se změna přímo týká nějakého klienta - kterého

4.3.2.1.6 Informace o CDR projektech

CDR projekt vzniká importem souboru s výpisem hovorů do aplikace. Existují dva druhy projektů – CS/CPS projekt a projekt 800. K projektu bude aplikace tedy evidovat:

typ projektu CS/CPS 800 datum založení pojmenování osobu, která ho založila

4.3.2.2 Klientská část Klientská část aplikace implementuje vnitřní logiku systému a grafické rozhraní. Zatímco serverová část komunikuje s uživatelem nepřímo prostřednictvím klientské části a tím je pro uživatele transparentní, klientská část se jeví uživateli jako výsledný softwarový produkt a z tohoto pohledu bude zajišťovat následující: 4.3.2.2.1 Správa klientské databáze

Aplikace bude dovolovat kompletní editaci všech evidovaných položek, které jsou uvedeny v odstavci 4.3.2.1.1 pomocí přívětivého uživatelského rozhraní. Rozhraní bude podporovat hromadné náhledy, zejména pak:

zobrazení seznamu klientů zobrazení seznamu všech čísel (CLI) zobrazení seznamu sazebníků

4.3.2.2.2 Import dat

import vstupních textových souborů s výpisem všech volání za dané období CS/CPS vstupních souborů 800 vstupních souborů import textového souboru se sazebníky včetně kontroly validní dvojice cena-destinace (program nahlásí chybu, pokud bude jedna z položek ve vstupním souboru chybět)


23

4.3.2.2.3 Zakládání a rušení CDR projektů

Importem vstupního souboru s výpisem hovorů od providera bude založen CDR projekt. Některé činnosti (uvedené v dalších bodech níže s poznámkou „v rámci projektu") budou probíhat pouze v rámci aktivního CDR projektu. 4.3.2.2.4 Vytváření detailních výpisů hovorů (v rámci projektu)

V rámci aktivního CDR projektu, tedy v rámci dat z jednoho vstupního souboru s výpisy hovorů bude ke každému číslu CLI vytvořen detailní výpis hovorů, který bude obsahovat tyto údaje:

jméno a příjmení zákazníka číslo, z něhož byly hovory uskutečněny (CLI) výpis hovorů, ke každému z nich: datum čas trvání hovoru volané číslo destinace (včetně rozlišní meziměstských a místních hovorů) sazba celková cena za hovor účtovaná BCH zákazníkovi (dopočítaná na základě sazebníků k danému číslu) celková provolaná částka za číslo CLI (suma cen za hovory z jednoho čísla) záhlaví (s čísly stránek výpisu) a zápatí (s kontaktními informacemi BCH) – bude řešit XLS šablona

Příklad vzhledu a formátu CDR výpisu viz příloha A.1. 4.3.2.2.5 Označování duplicitních a překrývajících se hovorů ve výpisu hovorů

Aplikace bude označovat odhalené duplicitní a překrývající se hovory. Toto označení je postačující až ve vytvořeném XLS souboru s výpisem. 4.3.2.2.6 Vytváření faktur a zpracování plateb (v rámci projektu)

Vytváření faktur bude dle požadavku BCH probíhat následujícím způsobem. Nejprve bude nutné vytvořit výpisy CDR a exportovat je do XLS. Tyto výpisy budou obsahovat automaticky počítanou cenu (pomocí vzorce v XLS souboru) za uskutečněné hovory z daného CLI. Poté co výpisy projdou manuální kontrolou bude možné vystavit faktury. Faktury se vystaví na základě informací z databáze klientů a cen uskutečněných hovorů z jejich čísel. Tyto ceny budou načteny zpětně z manuálně zkontrolovaných výpisů CDR (v XLS). Příklad vzhledu faktury viz příloha A.3.

faktury se rozliší dle databáze na: fakturované na společnost BCH ty z procesu vypadnou a jsou fakturovány ručně fakturované na společnost DRM

24


jejich zpracování pokračuje dle dalších, níže uvedených bodů

faktury se dále liší dle typu platby: platba bankovním převodem na spodní straně faktury je uvedeno bankovní spojení platba složenkou na spodní straně faktury je uvedeno bankovní spojení zákazník je přidán do seznamu k tisku složenek platba kreditní kartou na spodní straně faktury je uvedena část čísla kreditní karty a její platnost pro tyto zákazníky je také účtován poplatek, který tvoří 2% z účtované sumy suma na faktuře bude v dolarech, tedy je nutné přepočítat ji dle aktuálního kurzu platba inkasem platba v hotovosti na všech fakturách se bude částka zaokrouhlovat na 50 haléřů a bude napsáno o kolik bylo zaokrouhleno

Zpracování plateb spočívá v:

vytvoření seznamu kreditních karet k autorizaci pro banku vzhled seznamu viz příloha A.4 pro všechny zákazníky bude vytvořen seznam, aby bylo jasné, od koho se má očekávat platba (checkbox zaplatil/zaplatil) v aplikaci bude možno zobrazit seznam neplatičů (skrze všechny projekty) zákazník, který má nastavenu volbu používání fakturační adresy bude přidán do seznamu pro tisk štítků

4.3.2.2.7 Vytváření reportů (v rámci projektu)

aplikace bude vytvářet reporty, které budou sloužit jako přehled o nákladech a výnosech za dané období report bude XLS soubor (vzhled reportu viz příloha A.5)

4.3.2.2.8 Export do XLS

aplikace bude podporovat export do formátu XLS a pro detailní výpisy CDR faktury reporty seznam kreditních karet pro autorizaci bankou

4.3.2.2.9 Tisk

faktur složenek pro zákazníky platící složenkami seznamu kreditních karet pro ověření bankou


25

štítků s adresami dle výběru všechny zákazníky ti, jejichž fakturační a zasilatelská adresa je odlišná vybrané zákazníky (checkbox + ukládání výběrů pro další použití)

4.3.2.2.10 Zasílání emailů

detailní výpisy CDR a faktury v XLS formátu, hromadné emaily jednotlivcům výběru podle typu zákazníka skupině (checkbox) možnost použít výchozí poštovní aplikaci

4.3.2.2.11 Zaznamenávání změn

Aplikace bude zaznamenávat prováděné datové změny. Záznam bude obsahovat časovou známku provedené změny a její popis. Ke každé změně bude evidován uživatel, který ji provedl. 4.3.2.2.12 Podpora více jazyků uživatelského rozhraní

Aplikace bude podporovat nekomplikovanou možnost přeložení aplikačního rozhraní do více jazyků. Uživatel bude moci program spustit v požadovaném jazyce.

26


4.4 Datová analýza 4.4.1 ER diagram

Ilustrace 4.1- ER diagram databáze

27


4.4.2 Popis reprezentace dat Následuje podrobnější popis veškerých dat, ukládaných do databáze. Význam polí Atribut a Datový typ je zřejmý. Pole Null popisuje, jestli daný atribut může nabývat hodnoty null a pole Klíč určuje, zda se jedná o nějaký druh klíče (PK označuje primární klíč, FK cizí klíč). V poli Popis/Poznámka jsou uvedeny detaily, které blíže vysvětlují data, která daný atribut reprezentuje. U zřejmých atributů je toto pole prázdné. Význam některých atributů byl již uveden ve slovníčku pojmů v odstavci 4.1. Každá silná entita má jako primární klíč atribut id. U některých entit se primární klíč skládá ještě z klíčů cizích. V těchto případech se jedná o jasnou identifikační vazbu mezi dceřinou a rodičovskou entitou. Například entita hovor je jasně identifikována číslem, ze kterého se volalo (FK_CLI), projektem v rámci kterého je hovor evidován (FK_CDR_projekt) a jeho vlastním id. Oproti tomu faktura je slabou entitou bez vlastního primárního klíče.

4.4.2.1 Entita zakaznik Atribut id nazev_spol1 nazev_spol2 jmeno prijmeni titul IC DIC FK_typ FK_adresa_kor FK_adresa_fak FK_platba vyuctovani

Datový typ int char char char char char bigint char int int int int char

Klíč PK

poznamky FK_kreditni_karta zasilat_CDR

text int tinyint

zasilat_faktury

tinyint

Ano

uzivat_CLI_skupiny

tinyint

Ne

uzivat_koresp_adresu

tinyint

Ne

FK FK FK FK

FK

Null Ne Ano Ano Ano Ano Ano Ano Ano Ne Ano Ano Ne Ne Ano Ano Ano

Popis/Poznámka název společnosti eventuelní druhý název společnosti

IČO DIČO odkaz do tabulky typů odkaz na korespondenční adresu odkaz na fakturační adresu odkaz do tabulky typů plateb účtovat se může na BCH nebo DRM odkaz na kreditní kartu mají se zasílat CDR výpisy elektronickou poštou? mají se zasílat faktury elektronickou poštou? používá tento klient CLI skupiny pro vytváření výpisů? pro tisk štítků

4.4.2.2 Entita adresa Atribut id ulice PSC mesto stat

Datový typ int char int char char

Klíč PK

Null Ne Ano Ano Ano Ano

Popis/Poznámka

28


4.4.2.3 Entita CDR_projekt Atribut id typ datum_zalozeni jmeno FK_zalozil

Datový typ int char date char int

Klíč

Null

Ne Ano Ano Ne Ne

PK

FK

Popis/Poznámka CS/CPS nebo 800 datum importu vstupního souboru název projektu odkaz na uživatele systému

4.4.2.4 Entita CLI Atribut id CLI typ_sluzby typ_cisla FK_zakaznik FK_CLI_skupina

Datový typ int char char char int int

Klíč PK

FK FK

Null Ne Ne Ano Ano Ne Ano

FK_sazebnik

int

FK

Ano

Popis/Poznámka telefonní číslo klienta CS/CPS Mobil/Pevná linka/Fax číslo může patřit do nějaké skupiny odkaz do tabulky sazebníků na sazebník, dle kterého je číslo účtováno

4.4.2.5 Entita CLI_skupina Atribut id nazev FK_zakaznik

Datový typ int varchar int

Klíč PK FK

Null Ne Ne Ne

Popis/Poznámka název skupiny (např. pobočka) zákazník může vlastnit skupiny čísel

4.4.2.6 Entita druh_platby Atribut id nazev

Datový typ int char

Klíč PK

Null Ne Ne

Popis/Poznámka druhy plateb lze editovat

4.4.2.7 Entita email Atribut id email

Datový typ int varchar

FK_kontaktni_osoba

int

pro_CDR

tinyint

Klíč PK

Null Ne Ne

PK,FK

Ano Ano

Popis/Poznámka

kontaktní osoba může mít více emailů zasílat na tento email výpisy?

4.4.2.8 Entita fakturace_poradnik rok

Atribut

Datový typ int

posledni_faktura

int

Klíč PK

Null Ne Ne

Popis/Poznámka číslo naposledy vystavené faktury v daném roce

29


4.4.2.9 Entita faktura Atribut id datum_vystaveni datum_splatnosti variabilni_s uhrazeno castka castka_usd FK_zakaznik FK_CDR_projekt

4.4.2.10

id FK_CLI FK_CDR_projekt dest_number date time duration rate amount currency period destination internat_dest

Atribut id jmeno prijmeni fax www FK_zakaznik

4.4.2.12 Atribut id cislo CVC platnost poznamky FK_typ

Klíč

Null Ano Ne Ne Ne Ano Ne Ano Ne Ne

PK, FK PK, FK

Popis/Poznámka kdy byla faktura vystavena kdy má být splacena variabilní symbol byla faktura uhrazena? (0/1) částka v Kč pokud zákazník platí kartou komu byla faktura vystavena v rámci jakého projektu

Entita hovor

Atribut

4.4.2.11

Datový typ int date date bigint tinyint decimal decimal int int

Datový typ int int int char date time int decimal decimal char char char varchar

Klíč PK PK, FK PK, FK

Null Ne Ne Ne Ne Ne Ne Ne Ne Ne Ne Ne Ne Ne

Popis/Poznámka odkaz na číslo z kterého bylo voláno odkaz na projekt, v rámci něhož se volalo číslo, na které bylo voláno kdy bylo voláno v kolik hodin se volalo. délka hovoru v sekundách cena za minutu hovoru cena hovoru, účtovaná providerem měna špička/mimo špičku destinace mezinárodní destinace

Entita kontaktni_osoba Datový typ int char char char varchar int

Klíč PK

FK

Null Ne Ano Ano Ano Ano Ano

Popis/Poznámka

kterého zákazníka je toto kontakt

Entita kreditni_karta Datový typ int int int date text int

Klíč PK

FK

Null Ne Ne Ano Ano Ano Ne

Popis/Poznámka číslo kreditní karty kontrolní kód kreditní karty datum konce platnosti karty odkaz do tabulky typů karet

30


4.4.2.13

Entita problemova_hlaseni_CLI

Atribut FK_problemove_hlaseni

Datový typ int

Klíč PK, FK

Null Ne

FK_CLI

int

PK, FK

Ne

4.4.2.14

id datum_nahlaseni datum_uzavreni kontaktovat_do

Datový typ int date date date

kontaktovat_cislo

char

FK_zakaznik popis poznamky_reseni FK_technicky_partner FK_nahlasil FK_uzavrel

int text text int int int

Atribut id destinace sazba FK_sazebnik

4.4.2.16 Atribut id nazev verze datum_importu

4.4.2.17 Atribut id datum duvod_volani sdeleni FK_zakaznik

problémové hlášení se může týkat i více klientských čísel zároveň

Entita problemove_hlaseni

Atribut

4.4.2.15

Popis/Poznámka

Klíč PK

Null Ne Ano Ano Ano Ano

FK

FK FK FK

Ne Ano Ano Ano Ne Ne

Popis/Poznámka datum nahlášení problému datum uzavření/vyřešení problému telefonní číslo, na které se má zákazník kontaktovat (buď převzaté z kontaktních osob nebo zcela nové) popis problému doplňkové informace o vyřešení odkaz na technického partnera odkaz na uživatele systému odkaz na uživatele systému

Entita sazba Datový typ int varchar decimal int

Klíč PK

PK, FK

Null Ne Ne Ne Ne

Popis/Poznámka destinace hovoru cena v Kč za minutu hovoru odkaz na sazebník

Entita sazebnik Datový typ int char float date

Klíč PK

Null Ne Ne Ano Ano

Popis/Poznámka pojmenování sazebníků datum importu do systému

Entita servis_info Datový typ int date text text int

Klíč PK

FK

Null Ne Ano Ano Ano Ne

Popis/Poznámka datum zákazníkova volání sdělení od zákazníka odkaz na zákazníka

31


4.4.2.18 Atribut id log_in log_out FK_uzivatel

4.4.2.19 Atribut

Entita system_log_uzivatel Datový typ int datetime datetime int

Klíč PK

Null Ne Ne Ne Ne

FK

id datum_cas zaznam tabulka radek_id atribut hodnota_stara hodnota_nova FK_zakaznik

Klíč PK

FK

Null Ne Ne Ano Ano Ano Ano Ano Ano Ano

FK_provedl

int

FK

Ne

Atribut id user_name user_pass jmeno prijmeni email telefon opravneni

4.4.2.21 Atribut nastaveni_data FK_uzivatel

4.4.2.22 Atribut id nazev telefon poznamky

časová známka přihlášení časová známka odhlášení odkaz na uživatele

Entita system_log_zmena Datový typ bigint datetime varchar varchar int char varchar varchar int

4.4.2.20

Popis/Poznámka

Popis/Poznámka kdy byla změna provedena slovy „co se stalo“ v jaké tabulce došlo ke změně na jakém řádku došlo ke změně v jakém sloupci

pokud se změna týkala přímo nějakého zákazníka, jeho id kdo změnu provedl

Entita system_uzivatel Datový typ KLÍČ int PK char varchar char char char char int

Null Ne Ne Ne Ano Ano Ano Ano Ne

Popis/Poznámka uživatelské jméno uživatelské heslo jméno zaměstnance příjmení zaměstnance

0 = privilegovaný uživatel 1 = uživatel (možnost rozšíření o další práva)

Entita system_uzivatel_nastaveni Datový typ blob int

Klíč PK, FK

Null Ano Ne

Popis/Poznámka nastavení aplikace v binární podobě

Null Ne Ano Ano Ano

Popis/Poznámka

Entita technicky_partner Datový typ int char int text

Klíč PK

32


4.4.2.23

Entita telefon

Atribut id cislo FK_kontaktni_osoba

4.4.2.24 Atribut id nazev

4.4.2.25 Atribut id nazev

Datový typ int varchar int

Klíč PK

Null Ne Ne Ne

PK, FK

Popis/Poznámka telefonní číslo

Entita typ_karty Datový typ int varchar

Klíč PK

Null Ne Ne

Popis/Poznámka jméno typu

Entita typ_zakaznika Datový typ int varchar

Klíč PK

Null Ne Ne

Popis/Poznámka jméno typu

Některé atributy mají nastaveno omezení velikosti. To je znázorněno v závorkách u datových typů na diagramu Ilustrace 4.1.

4.4.3 Hodnoty dat a relace 4.4.3.1 Hodnoty dat Defaultní hodnotou všech atributů, jež mohou zůstat nevyplněné, je vždy hodnota null. U atributů, u kterých se očekávají hodnoty 0 nebo 1 (typ tinyint), bude brána hodnota null vždy jako 0. Primární klíče tabulek (id) budou generovány automaticky a jejich defaultní hodnota je 1. Slouží pro provázání a organizaci dat v databázi, pro uživatele budou zcela transparentní. S výjimkou entity druh_platby nemusí být inicializovány žádné výchozí hodnoty. Počáteční a neměnná data této tabulky následují. Id jednotlivých řádků je důležité, neboť se o něj při implementaci bude opírat výběr správné šablony pro fakturu. id 1 2 3 4 5 6

nazev Bank transfer Credit Card Postal order Collection order Cash Other

Tabulka 4.2 - Výchozí hodnoty atributů tabulky druh_platby

Atribut opravneni v tabulce system_uzivatel bude nabývat dvou hodnot. Hodnota 0 ponese význam identifikace privilegovaného uživatele, 1 pak neprivilegovaného. Tento atribut by mohl tedy být typu boolean (tinyint), nicméně s ohledem na případná další rozšíření jsem zvolil typ int.

33


U atributů, jež budou uchovávat telefonní čísla, jsem záměrně zvolil textový datový typ, neboť si zákazník nebyl jistý, jestli bude do telefonního čísla někdy v budoucnu zadávat i nenumerické znaky (jako např. + nebo -).

4.4.3.2 Relace Relační vtahy mezi jednotlivými entitami jsou patrné z diagramu na ilustraci Ilustrace 4.1 a nebudu je jednotlivě rozepisovat. Pro úplnost uvedu jen význam symbolů použité notace. Ukončovací symbol

Účast entity

povinná účast - přesně jednou povinná účast - jednou až n-krát nepovinná účast - maximálně nepovinná účast - až n-krát Tabulka 4.3- Význam symbolů použité ER notace

Relace kreslené čárkovanou čarou nesou význam neidentifikační vazby, plná čára znamená vazbu identifikační. Z důvodu přehlednosti jsem v ER diagramu na ilustraci Ilustrace 4.1 nezobrazil názvy relací. Nicméně relace pojmenované jsou a jejich jména se lze dozvědět například přímo v DDL skriptu, který databázi vytváří a je umístěn na přiloženém CD (viz příloha D).

4.5 Modelování dynamického chování některých částí systému Navrhovaná aplikace má mnoho částí, jejichž chování by bylo možné v rámci analytické části modelovat. Některé, méně složité či triviální problémy je však možné navrhnout přímo při implementaci. Zaměřím se tedy na důležitější celky, jejichž chování je složitější a mělo by být dobře zmapováno ještě před vlastním započetím návrhu a implementace.

4.5.1 Modelování procesu „Vytvoření CDR projektu“ Na ilustraci Ilustrace 4.2 je zobrazen stavový diagram znázorňující povolené sledy událostí při vytváření nového CDR projektu. Stěžejní částí je stav Kontrola konzistence dat a Tvorba stromu projektu. Po přečtení vstupního souboru budou data o načtených hovorech předána komponentě, která je zanalyzuje. Analýza bude spočívat v porovnání nalezených klientských čísel s dostupnými čísly v databázi. Pokud budou všechna čísla ze vstupu nalezena v databázi, mohou být data s hovory uložena. V opačném případě se logicky nabízí několik možností, jak pokračovat dál. První z nich je volba jiného souboru s daty konsistentními s databází (BCH může zažádat o nový zdroj dat, který bude správný a nebude obsahovat hovory z čísel, která BCH neprovozuje nebo se vstupní soubor může ručně upravit). Další možností je založení projektu pouze na bázi nalezených čísel a nakonec se nabízí volba ukončení vytváření projektu. Ve složeném stavu Vytvoření TreeTable modelu dochází k vlastnímu počítání cen. Výrazným požadavkem tohoto bodu je to, aby aplikace oznámila nenalezení destinace nebo sazby k destinaci v sazebníku, podle kterého je dané číslo účtované.

34


Stav Uložení dat reprezentuje komponentu, která celý projekt uloží do databáze. Důležité bude provést toto jako jedinou transakci, aby případná chyba nezpůsobila nekonzistentní data přímo v databázi. Ukládání dat nakonec přidá do systémového logu pro sledování činností informace o právě založeném projektu. Bližší popis komponenty pro evidování změn bude popsán v návrhové části práce. V příloze C.1 je k dispozici sekvenční diagram, který vykresluje blíže spolupráci jednotlivých komponent a tok událostí při zakládání nového projektu.

Ilustrace 4.2 – Stavový diagram procesu „Založení CDR projektu“


35

4.5.2 Modelování procesu „Vytvoření CDR výpisů“ Vytváření detailních výpisů hovorů je rovněž jedním ze stěžejních požadavků na cílový systém. Výpis hovorů bude vytvořen vždy pro každé číslo a bude obsahovat podrobné informace o všech hovorech, které byly v rámci daného projektu (možno říci také vstupního souboru nebo fakturačního období) z daného čísla uskutečněny. Výpis hovorů bude možné vytvářet v rámci aktivního (právě otevřeného) CDR projektu. K aktivnímu projektu bude vždy existovat jeho datový model, ze kterého bude komponenta tvorby CDR výpisu získávat data. V hlavičce výpisu bude uvedeno telefonní číslo, kterému výpis náleží a jméno klienta, který toto číslo používá. Pokud bude klient užívat CLI skupiny (např. jedna společnost má více poboček), bude jméno klienta rozšířeno o název příslušné CLI skupiny. Jména výsledných souborů XLS budou volena pomocí přednastavených vzorů. V první verzi systému bude postačující vzor CDR - <jméno_klienta> - <mm> .xls, kde budou všechny položky automaticky doplněny a položky mm (měsíc) a rr (rok) bude dovoleno ručně přenastavit.

Ilustrace 4.3 - Stavový diagram procesu „Vytvoření CDR výpisů“

4.5.2.1 Detekce duplicitních a překrývajících se hovorů Pro vlastní export do XLS bude užito šablony, která bude obsahovat vzorce pro detekování duplicitních a překrývajících se hovorů a pro výpočet výsledné účtované sumy za číslo. Po otevření souboru s výpisem v aplikaci MS Excel (nebo OpenOffice či jiné kompatibilní) se vzorce vypočítají a dojde k jasnému označení podezřelých řádků – příklad viz příloha A.2.

36


Výpisy budou před dalším zpracováním ručně kontrolovány zaměstnanci, kteří rozhodnou, zda se budou podezřelé hovory účtovat či ne. Algoritmus odhalení duplicitních (duplicit call) a překrývající se (overlap call) hovorů je vyjádřen pseudokódem na příkladu Příklad 4.1. Podle BCH nastává situace s těmito hovory poměrně často a je způsobena postupem při měření hovorů poskytovatelem. Např. pokud klient vytočí číslo a ještě před zvednutím hovoru volanou stranou hovor ukončí a v zápětí číslo vytočí znovu a hovor uskuteční, nastane situace duplicate call. FOR(všechny hovory){ ph = předchozí hovor; ah = aktuální hovor; IF(ah.datum==ph.datum AND ah.volané_číslo==ph.volané_číslo){ IF(ah.čas_volání částečně překrývá ph.čas_volání) OznačJakoOVERLAP(ah); IF(ah.čas_volání==ph.čas_volání OR (ah.čas_volání těsně navazuje na ph.čas_volání AND ah.čas_volání<=1 minuta)) OznačJakoDUPLICATE(ah); } } Příklad 4.1 - Pseudokód detekce overlap a duplicate hovorů

4.5.3 Modelování procesu „Vytvoření faktur“ Proces tvorby faktur je důležitou a netriviální součástí budoucího systému. Na ilustraci Ilustrace 4.4 je nakreslený model celé funkčnosti. Vytváření faktur společností BCH je poměrně nestandardní a stojí za to jej popsat blíže. K vytvoření faktur je potřeba mít vytvořené CDR výpisy. Z těch je totiž importována konečná částka za jednotlivá klientská čísla CLI. Specifickým požadavkem BCH je totiž možnost manuální kontroly CDR výpisů v MS Excel a s tím související možnost případné ruční opravy koncové ceny za číslo nebo jiných údajů výpisu. Ze zkontrolovaných výpisů musí tedy aplikace importovat ceny a přiřadit je ke konkrétním číslům. Ještě před importem obou hodnot (čísla a ceny) bude potřeba zkontrolovat správný formát souboru. V první fázi se soubory ve zvolené složce vyfiltrují dle jména a přípony, v druhé se bude muset zkontrolovat každý soubor „zevnitř“. Po úspěšném importu dvojic CLI a ceny za CLI dojde ke kontrole konzistence dat. K situaci, že importované číslo nebude existovat v databázi by sice nemělo dojít (vzhledem k tomu, že CDR výpisy budou z databáze generované), ale s přihlédnutím na možnost manuální úpravy celého souboru s výpisem, budou kontrola a následné vyřazení neexistujících čísel nutné. Ke každému klientovi bude následně dopočítána suma za všechna jeho čísla a ke klientům, kteří budou účtováni na společnost DRM, se vytvoří modely faktur. Klienti účtovaní na BCH z procesu vypadnou a BCH si je dofakturuje ručně. U klientů, kteří budou platit kreditní kartou, je navíc nutné vypočítat cenu v USD vzhledem k aktuálnímu kurzu dolaru (kurz bude zadán ve vstupním formuláři uživatelem). Na základě nastaveného typu platby bude rovněž vybrána šablona vzhledu faktury, která se použije při exportu do XLS.

37


Mezi důležité údaje na faktuře patří popis období a variabilní symbol. Popis období bude vybrán ve vstupním formuláři z dostupných projektů (jejich jména jsou popisem období). Na základě informací o vybraném projektu se přednastaví hodnoty roku a pořadového čísla faktury variabilního symbolu, který bude mít tvar 00<číslo_faktury_v_daném_roce>. Hodnotu roku (rrrr) a pořadového čísla bude umožněno měnit ručně, z důvodu možné změny fakturačních údajů a opětovnému vystavení stejné faktury. Z automatického číslování faktur plyne nutnost ukládat poslední číslo faktury v daném roce.

Ilustrace 4.4 - Stavový diagram procesu „Vytvoření faktur“

4.6 Diagramy aktivit pro provádění některých operací Stejně tak, jako v předešlém odstavci, není možné a ani nemá smysl modelovat aktivity pro všechny dostupné operace. Následující model vymazání projektu slouží pro ilustraci toho, že

38


mazání nejsou triviální operace a je třeba je předem dobře promyslet. Model pro zaslání emailu ukazuje možný (povolený) sled aktivit uživatele, který chce zprávu zaslat a reakce systému na ně.

4.6.1 Operace vymazání (CDR projektu) Vymazání CDR projektu obsahuje několik dílčích aktivit. Před vymazáním dat z tabulky CDR_projekt je z důvodu integrity dat nutné vymazat všechna související data z tabulky hovorů (hovor) a z tabulky faktur (faktura). To vše musí být provedeno jako jedna transakce, neboť při selhání dílčí aktivity musí být všechny ostatní změny stornovány, aby nedošlo k nekonzistenci dat. Podobným způsobem musí být při implementaci přistupováno i ke všem ostatním operacím mazání, které se dotknou více než jedné tabulky. Např. vymazání klienta, kontaktní osoby nebo čísla CLI. Z hlediska uživatele se operace jeví jako atomická a tak musí být i provedena. Příklad sledu aktivit při mazání CDR projektu je znázorněn diagramem na ilustraci 4.5.

Ilustrace 4.5 - Diagram aktivit vymazání CDR projektu

4.6.2 Zaslání emailu Zaslání emailu bude moci být provedeno dvěma způsoby. Prvním z nich bude použití výchozí poštovní aplikace klientské stanice. Před vlastním otevřením aplikace bude mít uživatel

39


možnost vybrat adresáty z klientské databáze. Jeho výběr bude následně delegován použité aplikaci. Druhým způsobem bude zaslání zprávy přímo z prostředí systému. Pro tento účel bude implementován jednoduchý emailový klient, který umožní výběr příloh a editaci předmětu a těla zprávy. Diagram na ilustraci 4.6 zobrazuje sled aktivit uživatele a systému při zasílání zprávy.

Ilustrace 4.6 – Diagram aktivit zasílání emailu

4.7 Závěrem k analýze Dle mého názoru je na tomto místě textu již cílová aplikace dostatečně analyzována a požadavky na jednotlivé funkčnosti jsou především z kapitol 4.3 a 4.5 známé. V kapitole 4.4 byla provedena podrobná datová analýza a celý návrh databáze. V kapitole 4.6 byla probrána významná operace mazání dat a jako ukázka modelování aktivit jiné operace popsáno zaslání emailu. Vzhledem k počtu všech možných procesů (který je zhruba stejný jako počet případů užití) a operací by jejich modelování bylo velmi rozsáhlé a u většiny i zbytečné. V rámci dalších kapitol budou uvedeny i další diagramy chování nebo spolupráce jiných částí cílového systému, které tyto části budou více či méně dokumentovat a tím dokreslovat celkovou představu o fungování systému. Následuje návrhová část textu, ve které budou poznatky získané z předešlých kapitol využity pro návrh struktury systému a kolaborace jeho částí.

40


Kapitola 5. Návrh

41

5 Návrh 5.1 Návrh členění systému a popis komponent 5.1.1 Návrh komponent (balíčků) Cílový systém bude implementován pomocí technologie Java. Při návrhu aplikace v tomto jazyce se nabízí používat balíčky. Balíčky slouží v podstatě jen k třídění zdrojových kódů do jmenných celků a pomáhají při řízení přístupů k elementům tříd. Při vhodném návrhu však mohou balíčky zastupovat jednotlivé části systému a tím vlastně reprezentovat systémové komponenty. Dále budu tedy na balíčky pohlížet jako na komponenty a i přes původně jiný význam jejich symbolů je tak budu používat i v diagramech. Při návrhu jednotlivých komponent jsem procházel požadavky z kapitoly 4 a postupně je rozřazoval do logických celků – balíčků. Každý balíček bude řešit podmnožinu požadavků s určitým společným rysem a bude se moci skládat z dalších vnořených balíčků – dílčích komponent. Při nejjemnějším pohledu na členění systému je komponentou vlastně každá třída. Návrh rozdělení systému na komponenty zobrazuje diagram na ilustraci 5.1.

Ilustrace 5.1- Diagram spolupráce balíčků a ostatních komponent nejvyšší úrovně

Na diagramu jsou znázorněny i komponenty Database a OS. Database zastupuje systémovou databázi, která byla navržena v kapitole 4.4. OS vyjadřuje operační systém. Pro korektnost

42

Kapitola 5. Návrh

stojí za zmínku, že ke všem externím komponentám (jako jsou právě Database a OS) se samozřejmě nepřistupuje přímo, ale přes JRE, tento aspekt však z diagramů vypouštím.

5.1.2 Popis základního návrhu jednotlivých komponent (balíčků) V této části bude rozebrán návrh a odpovědnosti všech předešle uvedených komponent s výjimkou komponenty gui, která je podstatně složitější a bude popsána v odstavci 5.2.

5.1.2.1 Komponenta dbaccess Bude zodpovídat za připojení k datovému zdroji a poskytovat služby pro práci s ním zbytku systému. Dále bude obsahovat mechanismy pro logování změn v databázi.

Ilustrace 5.2- Bližší pohled na komponentu dbaccess

Třída DatabaseSettings bude uchovávat nastavení připojení k databázi. Na základě nastavení aplikace pomocí třídy Database bude připojovat systém k databázi. Database by pak měla poskytovat objekt typu connection zbytku systému. Dále bude Database implementovat různé statické metody pro ulehčení práce s databází. Prakticky to bude aplikace návrhového vzoru fasáda na objekty poskytované JDBC ovladačem. 5.1.2.1.1 Dílčí komponenta pro logování změn – datachanges

Jeden z požadavků na cílovou aplikaci je zaznamenávání změn prováděných v databázi. Pro to jsem navrhnul komponentu datachanges. Hlavním stavebním kamenem logování změn jsou interface DataChangedIndicator (dále indikátor) a abstraktní třída DataChanges (dále změna).

Ilustrace 5.3 – Komponenty pro logování změn

Kapitola 5. Návrh

43

Libovolná komponenta, která bude moci vytvářet nějaké datové změny, bude implementovat indikátor. Ten bude sloužit pro detekci a zpracování provedených změn. Každá změna bude realizována vytvořením objektu typu změna. Tento objekt bude implementovat metody pro provedení změny a její logování. Objekty typu změna budou vytvářet posluchači změn – objekty typu PropertyChangeListener. Každá změna se zařadí do fronty změn a při potvrzení změn dojde k vykonání metod logChanges() a updateData() pro všechny prvky fronty. Změny budou moci být také stornovány.

5.1.2.2 Komponenta entities Entities bude shromažďovat třídy, které budou zastupovat jednotlivé databázové entity. Každá tabulka z databáze zde bude mít svou „javovskou“ alternativu. Všechny tyto třídy budou potomky třídy Entity (dále entitní třídy) a jejich jména budou s výjimkou velkého prvního písmene stejná jako jména databázových tabulek. Objekt typu Entity pak bude moci zastupovat libovolnou jinou entitní třídu, čehož půjde s výhodou využít například u výše diskutovaného zaznamenávání změn, ale samozřejmě i v dalších částech aplikace. Při vytváření objektu změny mu bude do konstruktoru předán objekt, v němž ke změně došlo. Pokud bude typ předávaného objektu Entity (což předpokládám bude 95% všech případů), bude stačit pro provedení změn (volání metody updateData() objektu změny) zavolat metodu save(), která však bude muset být každou entitní třídou přetížena, pro korektní fungování. 5.1.2.2.1 Reprezentace relací mezi entitními objekty

Stejně jako v databázovém modelu budou entitní objekty svázány relacemi. Relace budou reprezentované buď jednoduchou referencí na relací spojenou třídu nebo listem referencí (násobná relace). 5.1.2.2.2 Ukládání, mazání a update dat entitních objektů

Práce s daty z databáze bude pro entitní třídy nejčastější činností. Entitní třídy budou vlastně tvořit třetí stupeň rozhraní aplikace a databáze (první stupeň bude tvořit JDBC a druhý komponenta Database). 5.1.2.2.2.1 Ukládání a update – metoda save()

Metoda save() by měla kterýkoliv entitní objekt učinit persistentním. Musí tedy existovat mechanismus pro zjištění, zda se jedná o nový objekt či o update dat stávajícího objektu. To půjde jednoduše zařídit pomocí kontroly atributy id. Každý záznam v databázové tabulce má k dispozici atribut id. Ten je v rámci tabulky vždy jedinečný a tvoří s výjimkou několika případů primární klíč nebo jeho část. Při vytvoření nového entitního objektu bude jeho id nastaven na hodnotu 0 (neboť minimální hodnota id v databázi je 1). Po uložení dat objektu do databáze se načte generovaný klíč zpět do objektu a jeho další uložení již způsobí update. Id se samozřejmě načte s ostatními daty v případě vytváření nového objektu na základě existujících dat (načtení objektu z databáze). Rozhodnutí, zda uložit nebo provést update, tedy bude záviset na hodnotě atributu id (0 zn. update, jinak insert).

44

Kapitola 5. Návrh

Při volání metody save() dojde samozřejmě k jejímu volání i u entitních objektů spjatých relacemi s daným objektem relacemi. 5.1.2.2.2.2 Mazání – metoda delete()

Metoda delete() způsobí smazání dat entitního objektu z databáze. Opět se zde použije atribut id, pokud bude nulový, metoda neprovede nic. V jiném případě smaže data korespondující s daným id z tabulky. Problém může nastat z hlediska integritního omezení entit obsahujících reference. Při mazání dat některých entit je nutné nejprve vymazat data, která se na mazaná data odkazují. Zároveň bývá někdy nutné vymazat některá související data po smazání mazaných dat. K tomuto účelu jsem pro třídu Entity navrhnul další dvě metody – preDelete() a postDelete(). Potomek třídy Entity může tyto metody přetížit. Poté při volání metody delete() (pokud není přetížena, k čemuž by neměl být důvod) se nejprve vykoná preDelete(), poté se vymažou data mazané entity a nakonec se zavolá metoda postDelete(). Uvedené dvě metody by tedy měly obsahovat logiku pro správné mazání entit obsahujících reference.

Ilustrace 5.4 –Základní návrh abstraktní třídy Entity

5.1.2.3 Komponenta emailing

Ilustrace 5.5 – Základní návrh třídy pro zasílání emailů

45

Kapitola 5. Návrh

Komponenta emailing bude sloužit pro spolupráci se SMTP1 serverem a tak řešit požadavky, které se týkají zasílání emailů. Emailing bude tedy zajišťovat vytvoření jednoduché zprávy s přílohami, vlastním textem a předmětem. Rovněž bude umožněno použít k zaslání zprávy výchozí poštovní aplikaci systému. Pro integrované zasílání zpráv budu používat knihovnu JavaMail API. Základní návrh třídy obstarávající rozesílání emailů je vidět na ilustraci 5.5. Názvy metody sami vypovídají o své budoucí funkci a nebudu je dále rozebírat.

5.1.2.4 Komponenta exceptions O Javě se tvrdí, že velmi silným nástrojem tohoto jazyka jsou výjimky. U více rozsáhlého projektu je však výjimek více a je potřeba nějaký univerzální způsob pro jejich ošetření. Nejjednodušším způsobem reakce na výjimku je vytisknutí jejího stromu a případné ukončení metody, která ji odchytila. Tento způsob však není postačující pro software, který je určen ke komerčnímu nasazení (u školních nebo testovacích projektů to, dle mého názoru, vyřešit takto lze) a je třeba silnějšího mechanismu. Z tohoto důvodu jsem navrhl komponentu exceptions. Pokud bude třeba, budou do balíku exceptions přidávány vlastní třídy výjimek, nicméně hlavní část této komponenty bude tvořit třída ExceptionProcessor. Základní návrh této třídy (viz ilustrace 5.6) obsahuje tři statické metody. Všechny metody budou plnit stejnou funkci. Zobrazí na předané komponentě dialog s informací o vzniklé výjimce a zapíší výpis výjimky do souboru pro logování výjimek. Za pomoci tohoto logu by pak měla být detekce chyby podstatně jednodušší. Všechny výjimky, které bude nutné v aplikaci odchytit, budou zachytávány až ve vrstvě nejbližší uživateli – tedy ve vrstvě grafického rozhraní a každá reakce na každou výjimku bude její zpracování pomocí jedné z metod ExceptionProcessoru a případně další ošetření v závislosti na situaci.

Ilustrace 5.6 - Základní návrh třídy ExceptionProcessor

5.1.2.5 Komponenta input Komponenta input bude odpovědná za načítání dat z externích souborů. Aplikace bude muset načítat sazebníky a výpisy hovorů od poskytovatele z textových souborů. Input bude tedy obsahovat metody, které budou načtená data vracet a to nejlépe již jako list nově vytvořených 1

Simple Mail Transfer Protocol

46

Kapitola 5. Návrh

entitních objektů. Libovolné rozšíření pro načítání jiných dat by mělo být doplněno do této komponenty. Bližší detaily načítání budou navrženy až při implementaci.

5.1.2.6 Komponenta printing Při návrhu tiskové komponenty jsem nejprve musel vyřešit otázku, jak bude vlastní tisk realizován. Řešení pomocí balíku java.awt.print mi přišlo poněkud těžkopádné, a proto jsem hledal nějaký framework, který by podporoval vizuální návrh tiskové sestavy. Takových nástrojů je pro Javu k dispozici několik, ale již málokteré jsou zdarma. Nakonec jsem našel knihovnu JasperReports s vizuálním nástrojem iReport a po prostudování možností teprve zhotovil základní návrh komponenty printing. Principem tvorby sestav je návrh šablony pro tisk ve vizuálním nástroji a následné doplnění dat do šablony (již programově) v podobě listu Java Bean komponent nebo nastavení JDBC připojení. Z hlediska vizuálního návrháře musí být list Java Bean komponent vrácen nějakým datovým zdrojem (třídou a metodou). S ohledem na tyto požadavky jsem provedl základní návrh, který je vidět na ilustraci 5.7.

Ilustrace 5.7 - Základní návrh komponenty printing

Třída JasperPrinter bude obsahovat metody pro vytváření výsledných objektů, které již půjdou dalšími metodami knihovny JasperReports tisknout a exportovat. Metody budou vytvářet tisknutelné objekty tak, že doplní požadovaná data do připravených šablon. Data pro jednotlivé tiskové sestavy budou poskytovat metody třídy JasperPrinterDataSourceFactory, které budou vracet kolekce Java Bean komponent z balíku beans. Balík printing je vlastně aplikací návrhového vzoru fasáda nad knihovnou JasperReports, stejně tak tomu bylo u balíku dbaccess a JDBC ovladačů.

5.1.2.7 Komponenta xls Navrhovaná aplikace bude muset mít podle požadavků silnou podporu pro práci s formátem XLS. Soubory XLS budou cílem stěžejních operací jako je tvorba faktur nebo výpisů hovorů. Je potřeba zajistit možnost importu a exportu dat. Importovat data bude nutné z XLS souborů s CDR výpisy. Zejména pak dvojici CLI a suma za číslo CLI. K tomuto bude sloužit třída XlsImporter. Import telefonního čísla CLI bude provádět její metoda getCLIFromXLSCDR(File f). Import částky za telefonní číslo načte metoda getTotalPriceFromXLSCDR(File f). Obě tyto metody budou využívány metodou pro získání dvojice CLI a suma za číslo getAmountsMapForFiles(File[] cdrFiles).

47

Kapitola 5. Návrh

Export dat bude provádět třída XlsExporter. Stejně jako XlsImporter bude i XlsExporter obsahovat metody pro tvorbu jednotlivých materiálů. V základním návrhu jsou zatím dvě metody. Metoda exportBill(...) bude vytvářet faktury a exportCDR(...) bude exportovat výpisy hovorů. Třída se bude nejspíše dále rozrůstat podle dalších požadavků. Operace exportu budou používat připravené šablony. To bude mít velkou výhodu v tom, že vzhled šablon si bude moci klient měnit v MS Excel podle své vlastní vůle.

Ilustrace 5.8 - Základní návrh tříd XlsImporter a XlsExporter

5.1.2.8 Komponenty tools, ApplicationStatus, Main a Login Balíček tools jsem do návrhu zařadil z důvodu předešlých zkušeností s programováním. Téměř vždy jsem během implementace vytvářel různé pomocné třídy, které jsem ve zbytku aplikace často používal. Předpokládám, že v případě tohoto systému to nebude jiné a tak i přesto, že v tuto chvíli není jasné, co daná komponenta bude řešit, je podle mne nutné s ní počítat. Třída ApplicationStatus bude poměrně zásadní pro zbytek systému. Jak sám název napovídá, bude poskytovat informace o jeho aktuálním stavu. Tedy hlavně o aktuálně přihlášeném uživateli a jeho osobním nastavení a o otevřeném projektu (pokud nějaký bude). Nastavení uživatele bude uchovávat jím přednastavené cesty ke zdrojům importu a cílům exportu a jiné nastavitelné parametry aplikace. Třída Main spolu s třídou Login se budou starat o korektní spuštění celé aplikace a přihlášení uživatele.

5.2 Návrh grafického uživatelské rozhraní V teorii HCI2 je tradováno, že grafické uživatelské rozhraní (dále již pouze GUI3) tvoří v některých případech až 70% programového kódu a pro koncového uživatele znamená prakticky výsledný „program“. Jeho návrh by se tedy rozhodně neměl podceňovat.

2 3

Human Computer Interaction Graphical User Interface

48

Kapitola 5. Návrh

V této kapitole proberu můj návrh GUI, jak z programového hlediska, tak z hlediska možné interakce uživatele a GUI. Základní návrh struktury GUI (balíku gui) je znázorněn diagramem na ilustraci 5.9. Pro výslednou grafickou podobu rozhraní odkazuji čtenáře na přílohu B.

Ilustrace 5.9 - Základní návrh struktury komponenty gui

5.2.1 Stručný popis dílčích částí komponenty gui V aplikaci budou k dispozici 4 základní okna, která budou moci být otevřena současně. Hlavní okna budou implementovat třídy MainFrame, SettingsFrame, MailFrame a CustomerFrame. Zbytek GUI budou tvořit modální dialogy v rámci základních oken. Základní schéma kolaborujících prvků GUI znázorňuje ilustrace 5.10.

5.2.1.1 Hlavní okno – třída MainFrame Hlavní okno aplikace bude implementovat třída, kterou jsem nazval MainFrame. V tomto okně by mělo probíhat zhruba 80% veškerých uživatelských činností. Jednotlivé činnosti by měly být spouštěny pomocí akcí (objektů typu javax.swing.AbstractAction), které bude obsahovat dílčí balík tasks. Akce budou implementovat posloupnost kroků k vytvoření a zobrazení nějakého dialogu, okna nebo panelu. Většinu plochy hlavního okna bude zabírat místo pro umístění panelů. 5.2.1.1.1 Panely hlavního okna – balík panels

Panelem nazývám grafickou komponentu, která bude obsahovat rozhraní pro nějakou dílčí činnost uživatele, která bude probíhat v rámci hlavního okna. Například panel se sazebníky, panel s přehledem klientů, panel pro zobrazení stromu projektu atp. Jednotlivé panely budou muset odněkud získávat data a nějakým způsobem je zpracovávat. Pro tento účel jsem navrhl balík models.

49

Kapitola 5. Návrh

5.2.1.2 Datové modely – komponenta models Ve všech grafických komponentách je třeba manipulovat s daty. Vzhledem k charakteru navrhované aplikace budou data načítána z databáze (souboru) a zobrazována grafickými komponentami a naopak z grafických komponent ukládána do databáze (souboru). Při navrhování tohoto mechanismu jsem se inspiroval klasickou technikou MVC4. Hlavní grafické komponenty aplikace – okna, panely a dialogy budou reprezentovat zobrazení (view) a ovladače (controller). Výjimkou bude okno zákazníka, které bude mít ovladače z důvodu velkého množství ovladatelných položek separátně. Model bude implementován zcela odděleně a bude představovat jen kolekci dat, která má být zobrazena spolu s metodami pro manipulaci s daty. Všechny datové modely bude zastřešovat komponenta models.

Ilustrace 5.10 – Základní schéma prvků GUI nejvyšší úrovně

5.2.1.3 Dialogy a jednoduché zprávy – balíky dialogs a messages Důležitým prvkem při komunikaci s uživatelem je zpětná vazba. Uživatel by měl po libovolné akci vidět nějakou reakci systému. Pro jednoduché oznamovací reakce bude sloužit zasílání zprávy. Zpráva bude jednoduchý dialog, nevyžadující složitou reakci uživatele. Mechanismus pro zasílání zpráv bude obsahovat balík messages. Metody pro zasílání známých a častých zpráv budou mít tvar showXXXMessage(Component parent). Pro předem neznámé zprávy bude sloužit metoda showMessage(Component parent, String msg). Dialogy budou zastupovat funkci dílčích formulářů systému. Budou sloužit ke složitější interakci s uživatelem při provádění dílčích činností. Např. dialog pro vytvoření faktur, dialog pro import sazebníku atp. Rodičovskou třídou pro každý dialog bude třída AbstractDialog. Základní návrh této třídy je na ilustraci 5.11. Názvy metod vystihují jejich funkci. Metodou isCancled() bude moci rodičovská komponenta otestovat, zda byl dialog uzavřen křížkem nebo pomocí nějakého tlačítka.

4

Model View Controller

50

Kapitola 5. Návrh

Ilustrace 5.11 - Základní návrh třídy AbstractDialog

5.2.1.4 Okno zákazníka – třída CustomerFrame Okno pro zobrazení položek zákazníka bude od ostatních oken odlišné. Hlavní rozdíl bude v počtu zobrazovaných informací. Předběžný odhad počtu položek je 60. Z tohoto důvodu jsem se rozhodl předem úplně separovat nejen část modelu, jako u ostatních oken, ale i část ovladače a to hlavně z důvodu přehlednosti kódu a jeho lehčím dodatečným úpravám. Ovladače bude zastřešovat balík listeners.

5.2.1.5 Programová správa grafického rozhraní – třída GUIStatus Při implementaci GUI bude vhodné na nějakém místě centralizovat zobrazované grafické elementy. Například při vytvoření okna zákazníka a změně jeho vlastností by se tato změna měla zároveň promítnout na panel hlavního okna. Třída GUIStatus bude obsahovat reference na libovolné prvky GUI (v tuto chvíli však nejsem schopný přesně určit, které to budou), takže při zavolání vhodné metody může libovolný prvek GUI získat lehce libovolný jiný a pracovat s ním. To by mohlo být výhodné zejména při nutnosti spolupráce mezi hlavními okny aplikace, které jinak poběží paralelně bez společného rodiče. Toho jim bude moci částečně nahradit právě třída GUIStatus. Třída GUIStatus bude rovněž poskytovat zdroj pro popisné texty všech grafických elementů a jiné řetězce, používané pro komunikaci. Díky zdroji bude moci být GUI vícejazyčné (viz dále).

5.2.1.6 Podpora vícejazyčného GUI Další z požadavků na navrhovanou aplikaci je podpora více jazyků. Tento problém bývá řešen pomocí tzv. Resource Bundles5. Jedná se o jednoduchou techniku shromažďování veškerých popisů a hlášení na „jednom místě“ v několika verzích. Každá verze pak tvoří jeden jazyk pro GUI. Při implementaci se poté místo přímé textové podoby použije odkaz do zdroje. Z něj je poté podle nastaveného národního prostředí vybrána daná verze požadovaného textu, která se dosadí na dané místo v GUI. Prostředí Java podporuje vícejazyčná rozhraní pomocí zavedené techniky i18n6 podporované v balíku java.util. Překlad zdrojů a případnou úpravu hlášení a popisků GUI bude poté možno lehce upravovat editací textových souborů.

5 6

Svazky zdrojů číslo 18 vyjadřuje 18 písmen mezi i a n ve slově internationalization

Kapitola 5. Návrh

51

5.2.1.7 Měření průběhu dlouhých činností – balík progressmeasuring Špatné GUI se vyznačuje mnoha neduhy. Jedním z nich je i jeho zamrznutí při delší činnosti jádra aplikace. Uživatel by měl mít možnost průběh takové činnosti sledovat nebo o ní být alespoň nějakým způsobem uvědomen (změnou kursoru, hlášením). Vzhledem k tomu, že aplikace bude operovat s velkým množstvím dat (načítání tisíce řádků dat ze souborů, jejich zpracovávání, exporty do XLS atp.) rozhodl jsem se navrhnout komponentu, která by byla schopná jednoduše průběh zobrazovat (nejlépe zavoláním jedné metody). Zdánlivá banalita se však ukázala být poměrně složitým problémem a návrh této části jsem spojil s implementací, neboť jsem musel vyzkoušet, zda mnou navrhnuté řešení bude opravdu funkční. Protože jsem tomuto problému věnoval více času a shledávám ho poměrně zajímavým, rozeberu ho podrobněji v tomto odstavci a v části textu o implementaci jej již popisovat nebudu. Vzhledem k tomu, že GUI bude implementováno pomocí JFC7 a komponent SWING8 zde nastal problém s vlákny. GUI aplikace napsané ve SWING totiž běží v jediném speciálním vlákně, které je nazýváno Event Dispatch Thread (dále EDT). Toto vlákno obsluhuje frontu událostí a pokud v něm spustíme delší proces, GUI „jakoby zatuhne“, protože EDT čeká na jeho dokončení. Je tedy nutné úlohu spustit v jiném vlákně (dále BT9). Výsledky většiny úloh však budou potřeba pro další pokračování EDT vlákna a je tedy potřeba toto vlákno stejně pozastavit. V tomto místě je tedy vhodné zobrazovat průběh výpočtu vlákna BT. Pokud toto chceme provést jednoduchým voláním metody, která by pozastavila běh EDT, ale zároveň v rámci něj zobrazovala průběh úlohy v BT, je situace poměrně komplikovaná. Mé řešení využívá tří vláken. První z nich, BT, tvoří vlastní, časově náročnou úlohu. Druhé vlákno, nazvěme ho LT10, tuto úlohu „poslouchá“ a informuje o jejím průběhu třetí vlákno – vlastní vlákno SWINGu EDT, v rámci něhož je otevřen modální dialog, který zobrazuje průběh výpočtu pomocí komponenty JProgressBarr (dále JPB). Zobrazení modálního dialogu způsobí pozastavení předešlého toku vlákna EDT až do jeho zavření. Dialog však o stavu JPB nic neví a o úpravu hodnoty JPB a zavření dialogu se stará vlákno LT. Hodnota o průběhu úlohy je získávána metodou getCurrentProgress(), kterou poskytuje navržené rozhraní MeasurableTask. V důsledku celý tento mechanismus znamená, že pokud bude potřeba měřit průběh nějakého výpočtu, stačí aby třída, která výpočet provádí, implementovala rozhraní MeasurableTask. V zápětí po spuštění úlohy této třídy ve vlákně BT stačí zavolat statickou metodu třídy ProgressBarDialog - ShowListeningDiaog(Component owner, MeasurableTask task), která spustí vlákno LT a na předané komponentě zobrazí dialog s měřením průběhu úlohy task, čímž pozastaví aktuální tok EDT. Měřící vlákno LT, spuštěné metodou na pozadí, se samo ukončí a zavře zobrazený dialog poté, co metoda getCurrentProgress() vrátí hodnotu 100. 7

Java Foundation Classes Knihovna pro tvorbu GUI v Javě 9 Background Thread 10 Listening Thread 8

52

Kapitola 5. Návrh

Zavřením měřícího dialogu začne SWINGové vlákno EDT pokračovat v další činnosti, kterou bude zpracování výsledků výpočetně náročné úlohy. Popsaný mechanismus jsem odzkoušel a funguje spolehlivě, bližší představu o návrhu může přinést následující ilustrace. Zobrazí měřící dialog , čímž pozastaví původní tok vlákna EDT. Pustí vlákno LT.

Spustí vlastní vlákno LT, zaregistruje komponentu JPB a vlastní měřenou úlohu. Ilustrace 5.12 - Struktura komponenty pro měření průběhu

5.2.2 Návrh interakce uživatele a GUI Interakce uživatele a GUI bude probíhat standardním způsobem. Důležité je, aby systém na každou uživatelskou akci nějakým způsobem reagoval a poskytl tak uživateli zpětnou vazbu. Každá akce by tedy měla způsobit otevření dialogu, okna nebo jeho zavření či zobrazení nějakého hlášení. Při vzniku výjimky, kterou nelze ošetřit bez narušení běhu programu, bude zobrazen dialog s popisem vzniklé chyby. Jednotlivé akce, spouštějící procesy, které budou realizovat požadavky definované v kapitole 4.3, budou navázány na prvky menu oken. Položky menu hlavního okna budou rovněž dostupné skrz klávesové zkratky a některé z nich z panelu rychlé volby. Možnou struktury menu hlavního okna zobrazuje ilustrace 5.13. Zobrazené dialogy a okna budou obsahovat další akční prvky. Některé z nich budou vést k zobrazení dílčích dialogů nebo oken. Bylo by tedy vhodné, navrhnout podobné struktury i pro dílčí obrazovky. To však dle mého názoru nemá, vzhledem k rozsahu, v tuto chvíli význam a návrh provedu současně s implementací GUI.

53

Kapitola 5. Návrh

Ilustrace 5.13 – Diagram možné struktury hlavní menu

5.3 Akceptační testy a testy použitelnosti V tomto odstavci bych rád uvedl návrh testů pro akceptaci aplikace a zmínil se o testování použitelnosti11, o kterém si myslím, že má velký vliv na výslednou kvalitu celého software.

11

anglicky Usability Testing

54

Kapitola 5. Návrh

5.3.1 Návrh akceptačních testů pro hlavní funkce Pro úspěšné dokončení projektu musí být projekt akceptován. Akceptací zákazník potvrzuje splnění jeho požadavků. Obecně lze říci, že výsledný systém bude muset být akceptován, pokud bude korektně plnit všechny uvedené požadavky z odstavce 4.3 - Podrobný katalog požadavků a bližší specifikace. Pro akceptační testy jsem připravil sadu formulářů, které obsahují zadané požadavky spolu s místem pro popis nalezených chyb v jejich realizaci a zaznamenání případných poznámek pro jejich vylepšení. Požadavek musí být akceptován, pokud splní všechny body jeho znění nezávisle na možnostech vylepšení. Do formulářů jsem nepsal standardní popis akcí ve formě scénáře, neboť to považuji za zbytečné vzhledem k samotnému textu zadání požadavku. Je však možnost doplnit (při další spolupráci se zákazníkem) bližší specifikaci požadavku. Příklad akceptačních formulářů je uveden v příloze D.

5.3.2 Testování použitelnosti Při testování použitelnosti půjde prakticky o testování intuitivnosti GUI a pohodlnosti ovládání programu. Při testování funkčnosti aplikace bude mít BCH zároveň možnost navrhovat různé „proveditelné“ změny v GUI dle jejich požadavků. Předpokládám, že se bude jednat hlavně o úpravy struktury menu, vzhledu dialogů a rozmístění ovládacích prvků, či o změny v popisných textech prvků nebo textů hlášení. Pokud nebude změna znamenat velký zásah do struktury celého GUI, což by vzhledem k poměrně velké navržené modularitě neměla, bude GUI podle přání BCH upraveno.

Kapitola 6. Implementace

55

6 Implementace 6.1 Použité technologie a nástroje 6.1.1 Volba technologií K implementaci sytému jsem po dohodě s vedoucím práce zvolil technologii Java (konkrétně verzi 5) a databázový server MySQL (také verzi 5). Hlavní důvod volby těchto technologií byl ten, že jsou obě volně dostupné, jsou vyvíjeny na bázi OpenSource a existuje k nim celé řada utilit a podpůrných nástrojů, které jsou rovněž volně dostupné a zdarma. Druhým důvodem výběru byla moje předešlá zkušenost s programováním v Javě, které mě za celou dobu studia nejvíce oslovilo. Server MySQL rovněž používám již od dřívějších verzí, a protože od verze 5 má již plnou podporu integritních omezení (dříve pouze akceptoval syntaxi), neváhal jsem ho použít i pro tento projekt.

6.1.2 Volba nástrojů Při volbě vývojových nástrojů jsem již tak rozhodný nebyl. Rozhodoval jsem mezi třemi různými IDE12 : Eclipse, JBuilder a Netbeans. Nakonec jsem zvolil Netbeans IDE a to hlavně kvůli jeho GUI návrháři – projektu Matisse. Vzhledem k formulářové povaze aplikace byla toto velká priorita, neboť bez silného nástroje pro tvorbu GUI se, dle mého názoru, u rozsáhlejších, desktopově orientovaných aplikací nelze obejít. Pro návrh databázového schématu jsem si zvolil nástroj DB Visual Architect od společnosti Visual Paradigm, který je po dobu jednoho měsíce zdarma. Pro modelování částí systému a tvorbu diagramů jsem převážně používal nástroj Java Studio Enterprise 8, který společnost Sun poskytuje registrovaným uživatelům zdarma. Pro některé další diagramy jsem pak použil volně dostupný projekt Dia v kombinaci s MS Visio, který je pro studijní účely rovněž zdarma.

6.1.3 Stručný přehled použitých nestandardních knihoven a nástrojů Při implementaci jsem potřeboval řešit několik ne zcela standardních problémů. Jednalo se zejména o části tisku, práce s XLS formátem a posílání emailů. Je samozřejmě možné všechny tyto části naprogramovat pomocí standardních knihoven. To je ale nesmysl, protože programovat „něco“, co je již hotové, nemá význam, pokud by implementace trvala delší dobu než pochopení již hotového, existujícího řešení a nekladla si za cíl dosáhnout lepších nebo jiných funkčností. Při výběru dále jmenovaných knihoven a nástrojů byla hlavní prioritou jejich licence. Vybíral jsem pouze taková řešení, která jsou volně dostupná a mohou se dále šířit bez poplatků (tedy se jedná licence GPL13 a LGPL14)

12

Integrated Development Environment General Public License 14 Lesser General Public License 13

56


6.1.3.1 Knihovny pro práci s XLS formátem Pro práci s XLS formátem jsem zvolil dvě externí řešení. První z nich, knihovnu jXLS, jsem zvolil pro podporu exportu dat do XLS formátu. Tato knihovna používá pro export připravené XLS šablony, které obsahují speciální značky skriptovacího jazyka knihovny jXLS. Podle „miniskritpů“, umístěných uvnitř šablony XLS, je knihovna schopna doplnit data z kolekcí Java Bean komponent. Toto řešení je přesně to, které jsem potřeboval. Hlavní výhodu shledávám v tom, že grafický formát šablon může upravovat sám uživatel podle vlastní vůle přímo z prostředí MS Excel nebo jiné kompatibilní aplikace. Pro import dat ze souborů formátu XLS jsem použil knihovnu Java Excel API. Na rozdíl od předešlé knihovny, umí tato data ze XLS formátu i načítat. Načítání hodnot je pomocí této knihovny možné provést na základě jednoduché adresace buněk Toto řešení mi rovněž přišlo výhodné.

6.1.3.2 Knihovny pro podporu elektronické pošty V aplikace jsem musel řešit zasílání emailových zpráv. K tomuto účelu existuje framework od společnosti Sun – Java Mail API. Soubor těchto knihoven dovoluje poměrně jednoduchým způsobem nejen vytváření a zasílání zpráv, ale i jejich příjem. Samozřejmostí je podpora příloh, MIME typů a další.

6.1.3.3 Knihovny a nástroje pro podporu tisku Tisk z prostředí Javy je, i přes dlouholetou existenci této technologie, stále komplikovaný. Součástí standardního Java SDK15 je k dispozici balík java.awt.print. Po jeho prostudování jsem však usoudil, že toto příslušenství je pro mou potřebu absolutně nevhodné. Hledal jsem tedy nějaký vizuální návrhář reportů s podporou plnění dat z prostředí Java. Toto se ukázalo být poměrně problémem, neboť většina nástrojů, které jsem nacházel, byla zpoplatněna. Nakonec jsem objevil knihovnu JasperReports a vizuální návrhář reportů iReport. Po hrubém prostudování funkčností jsem byl zcela ohromen a rozhodl jsem se použít tyto prostředky i v mém projektu. Knihovna JasperReports pracuje na základě XML šablon, které popisují daný report (nebo také dokument). Syntaxe XML je poměrně bohatá a umožňuje definovat desítky vlastností, které jsou očekávány od profesionálního dokumentu. Od zadávání formátu papíru, velikosti okrajů, písma atp. až po definici datových zdrojů a vlastních logických výrazů, které podmiňují tisk a jejichž syntaxe je shodná se syntaxí jazyka Java. Problém tohoto jazyka je však, jako u kteréhokoliv bohatšího XML, že je obtížně čitelný a zapamatovatelný pro uživatele. A právě tento negativní aspekt výborně řeší návrhář iReport. Jedná se, podle mého názoru, o velmi přívětivý nástroj, ve kterém se výsledný vzhled reportu (jeho stránek) zhruba řečeno „nakreslí“. Práce v něm připomíná práci např. v MS Visio nebo s trochou nadsázky v MS Word. Uživatel nejprve definuje grafické objekty, rozložení a vzhled stránky a datové zdroje (jimiž mohou být opět objekty Java Bean). Poté pomocí speciální syntaxe umístí položky datových zdrojů na stránku a je téměř hotovo. Modelář report zkompiluje a nahlásí 15

Software Development Kit


57

případné chyby. Po úspěšné kompilaci je vytvořena XML šablona, reprezentující design daného reportu. Z prostředí jazyka Java se poté nataví datové zdroje, proměnné a položky reportu a o vše ostatní se již postarají prostředky knihovny JasperReports. Tisk nebo export reportu je poté otázkou několika řádek kódu. Velkou nevýhodou knihovny je naprostá absence popisu API a placené uživatelské příručky. Nicméně díky existenci různých internetových fór je tento nedostatek pro běžné použití přehlédnutelný.

6.2 Popis vlastní implementace 6.2.1 Pravidla a konvence při psaní kódu Pří psaní vlastního kódů aplikace jsem se řídil obecnými konvencemi pro psaní kódu a konvencemi pro psaní kódu v Javě. Pravidla shrnuje následujících několik bodů. Obecná pravidla pro pojmenovávání Názvy tříd začínají velkým písmenem. Názvy proměnných a parametrů metod začínají malým písmenem. Názvy konstant jsou psány pouze velkými písmeny. Názvy metod začínají malým písmenem. Názvy přístupových metod pro properties16 (soukromé proměnné třídy) začínají set nebo get a pokračují jménem property. Víceslovné pojmenování identifikátorů je bez mezer, vždy s velkým prvním písmenem slova (s výjimkou prvního). Pravidla pro psaní jazykových konstrukcí Řádek kódu by neměl být delší než 80 znaků. Odsazování bloků (cykly, podmínky) se provádí u všech druhů jednotně. Rozdělování dlouhých podmínek v konstrukci if – then – else na více řádků, uvádění then a else na samostatný řádek. Komunikace s uživatelem, hlášky, zprávy, upozornění Nepoužívají se slangové výrazy. Co nejvíce se vyhýbat výrazům v angličtině (výjimkou je ošetřování výjimek). Uživateli se netyká. Popisky na tlačítkách a v menu se zapisují pomocí infinitivů, krátce a výstižně. Další, mnou zavedené konvence Názvy atributů databázových tabulek jsou malými písmeny. Jména tříd s reprezentující databázové tabulky mají stejný název s výjimkou prvního velkého písmene. 16

soukromé proměnné třídy

58


Propeties tříd, které odpovídají atributům databáze mají stejný název jako atributy. Třídy, reprezentující okna aplikace končí slovem Frame. Třídy, reprezentující dialogy aplikace končí slovem Dialog. Třídy, reprezentující datové modely končí slovem Model.

6.2.2 Stručný popis implementace zajímavých částí systému V tomto odstavci se pokusím pomocí jednoduchých příkladů ukázat základní principy pro použití nestandardních knihoven, které byly diskutovány v odstavci 6.1.3. Komentáře v příkladech by měly jednotlivé postupy krok po kroku vysvětlovat. Pro podrobnější informace odkazuji čtenáře na zdrojové kódy aplikace nebo na stránky jednotlivých projektů, které budou uvedeny v kapitole 9.

6.2.2.1 Podpora práce s formátem XLS 6.2.2.1.1 Export dat užitím XLS šablony a knihovny jXLS

Předpokládejme, že máme k dispozici kolekci osob a chceme do XLS souboru exportovat jejich seznam, pro jednoduchost jen jméno a příjmení. Objekt osoba je objektem typu Java Bean a definice jeho třídy je následující. public class Osoba{ private String jmeno = null; private String prijmeni = null; public public public public public

Osoba(String jm, String prijmeni){...} void setJmeno(...){} void setPrijmeni(...){} String getJmeno(){...} String getPrijmeni(){...}

} Příklad 6.1 - Třída Osoba podle specifikace Java Benas

V prvním kroku je třeba vytvořit XLS šablonu a definovat v ní pomocí speciálních značek umístění dat. Následující značkový kód zapíšeme do XLS souboru. Znak „|” vyjadřuje oddělení buněk. <jx:forEach items="${osoba}" var="osoby"> ${osoba.jmeno} | ${osoba.prijmeni} Příklad 6.2 – Značkovací jazyk knihovny jXLS

Zvýrazněné prvky ukazují návaznost na následující kód v Javě. Osoby tvoří kolekci objektů typu Osoba a zvýrazněné jmeno a prijmeni zastupují properties třídy Osoba. Následující kód ilustruje vlastní export. // cesta souboru se šablonou a umístění vygenerovaného souboru String sablona = “D:\sablona.xls”; String cil = “D:\mujSoubor.xls”;


59

ArrayList mojeOsoby = new ArrayList(); //naplnění listu osob ... // příprava mapy objektu pro export Map beans = new HashMap(); beans.put("osoby",mojeOsoby); // vlastní export pomocí jXLS XLSTransformer transformer = new XLSTransformer(); transformer.transformXLS(sablona,beans,cil); Příklad 6.3 - Jednoduchý export do XLS pomocí knihovny jXLS

6.2.2.1.2 Načtení hodnoty buňky z XLS souboru pomocí knihovny Java Excel API

Následující příklad ukazuje použití knihovny JExcel API pro načtení hodnoty ceny z jedné buňky v souboru XLS. Poloha buňky není předem známa, nicméně víme, že se nalézá o jednu buňku vpravo od buňky, jejíž obsahem je řetězec „TOTAL CZK“. // otevření souboru a získání prvního sešitu jxl.Workbook workbook = jxl.Workbook.getWorkbook(new File(“s.xls”)); jxl.Sheet sheet = workbook.getSheet(0); // nalezení buňky požadované buňky jxl.Cell sumCell = sheet.findCell("TOTAL CZK"); int radek = sumCell.getRow(); int sloupec = sumCell.getColumn()+1; jxl.Cell total = sheet.getCell(sloupec,radek); // získání vlastní částky jxl.NumberFormulaCell nfc = (jxl.NumberFormulaCell)total; double totalDouble = nfc.getValue(); BigDecimal totalBD = new BigDecimal(totalExcelDouble); totalExcelBD = totalExcelBD.setScale(2,BigDecimal.ROUND_HALF_UP); // v proměnné totalBD je na tomto místě požadovaná hodnota ceny Příklad 6.4 - Načtení hodnoty buňky ze souboru XLS pomocí knihovny JExcel API

6.2.2.2 Podpora zasílání emailů V tomto odstavci uvedu příklad, ilustrující postup pro vytvoření jednoduché zprávy s jednou přílohou a její zaslání na jednu adresu. K tomu bude použita knihovna Java Mail API. // nastavení parametrů String mailServer = ”smtp.chello.cz”; String from = “[email protected]”; String to = “[email protected]”; String messageBody = “Text zpravy”; String subject = “Predmet zpravy”; String fileName = “D:\priloha.txt”; // nastavení mail serveru

60


Properties props = System.getProperties(); props.put("mail.smtp.host", mailServer); // získání sezení pro zasílání emailů Session session = Session.getDefaultInstance(props, null); // vytvoření zprávy k zaslání Message msg = new MimeMessage(session); msg.setFrom(new InternetAddress(from)); msg.addRecipient(Message.RecipientType.TO, new InternetAddress(to)); msg.setSubject(subject); // vytvoření části zprávy, reprezentující vlastní text BodyPart msgBodyPart = new MimeBodyPart(); msgBodyPart.setText(messageBody); /* vytvoření objektu Mutlipart pro složení zprávy z části textu a z části přílohy */ Multipart multipart = new MimeMultipart(); // přidáme část textu multipart.addBodyPart(messageBodyPart); /* přidáme přílohu */ MimeBodyPart attachmentBodyPart = new MimeBodyPart(); // určíme soubor DataSource source = new FileDataSource(filename); attachmentBodyPart.setDataHandler(new DataHandler(source)); // nastavíme jméno souboru (zde bude jméno včetně cesty k souboru) attachmentBodyPart.setFileName(filename); // přidáme přílohu do objektu Multipart multipart.addBodyPart(attachmentBodyPart); // všechny části spojíme dohromady do jedné zprávy msg.setContent(multipart); // pomocí statické metody send odešleme zprávu Transport.send(message); Příklad 6.5 - Zaslání jednoduché emailové zprávy pomocí knihovny Java Mail API

6.2.2.3 Podpora tisku a exportu do různých formátů Poslední příklad ukazuje možný postup při práci s knihovnou JasperReports. Předpokladem je zde existence XML šablony designu reportu – souboru sablona.jrxml. Soubor může být vytvořen např. pomocí nástroje iReport, o kterém jsem se zmiňoval v odstavci 6.1.3.3. Výsledkem by měl být dokument, který bude obsahovat jméno tvůrce a několik řádků textu, které budou určeny obsahem datové kolekce. Vzhled obrazovky náhledu na tisk je ukázán v příloze B. // načtení šablony XML – design reportu JasperDesign design = JRXmlLoader.load(“D:\sablona.jrxml”);

Kapitola 6. Implementace // kompilace JasperReport // vytvoření Collection c c.add(“první c.add(“druhý

61

designu – vytvoření vlastního reportu report = JasperCompileManager.compileReport(design); a naplnění kolekce dat = new ArrayList(); v reportu“); řádek v reportu“);

... // vytvoření datového zdroje z kolekce dat JRBeanCollectionDataSource ds = new JRBeanCollectionDataSource(c); // nastavení parametrů reportu Map params = new HashMap(); params.put(“vytvoril”,new String(”Vojtěch Brom“)); /* předání parametrů a datového zdroje do reportu – vytvoření objektu pro tisk */ JasperPrint print = JasperFillManager.fillReport(report,params,ds); /* zobrazení náhledu na vzniklou sestavu – okno náhledu umožňuje tisk i export do různých formátů */ JasperViewer.viewReport(print,false); // export reportu do PDF JasperExportManager.exportReportToPdfFile(print,"d:\mePDF.pdf"); // export reportu do HTML JasperExportManager.exportReportToHtmlFile(print,"d:\meHTML.html"); Příklad 6.6 - Ukázka práce s knihovnou JasperReports

6.2.3 Nalezené chyby v implementaci Javy Při vlastním kódování jsem se potýkal s mnoha různými implementačními problémy, které jsem musel řešit. Z mého pohledu obtížnější část implementace spočívala v tvorbě GUI, při níž jsem také objevil níže uvedené dvě chyby v implementaci knihovny SWING.

6.2.3.1 Memory Leak v aplikacích založených na SWING v prostředí Windows 6.2.3.1.1 Stručný popis chyby

Jedná se o nahlášenou chybu Javy s číslem 6462383. Vlastní chyba spočívá v tom, že JRE, které běží na systému Windows XP, nevrací alokovanou paměť systému v aplikacích používajících okna typu JFrame a v appletech17. Jinými slovy, nefunguje Garbage Collector a aplikace alokuje stále novou paměť až do chvíle, kdy již nejsou k dispozici žádné další prostředky a aplikace skončí s chybou OutOfMemoryError. Tato chyba se objevuje ve verzi Javy 1.5.

17

Aplikace jazyka Java, která je schopna běžet v rámci internetového prohlížeče.

62


V době psaní tohoto odstavce je již chyba označená jako vyřešená a odstraněná, nicméně jsem zatím nenašel žádný dostupný update, ve kterém by byla chyba zapsána jako opravená a to ani v seznamu oprav poslední verze Javy 6. 6.2.3.1.2 Postup vedoucí k odhalení chyby

Odhalení této chyby bylo opravdu strastiplné. Celá „cesta“ začala v momentě, kdy jsem prováděl zátěžový test aplikace a v rámci něj jsem zakládal několik projektů. Do vstupního souboru s výpisy hovorů jsem vygeneroval desítky tisíc řádků. Při zakládání pátého projektu se aplikace ukončila s výše zmiňovanou chybou OutOfMemoryError. Při následném sledování paměti jsem zjistil, že paměť procesu mé aplikace opravdu stále narůstá a během několika operací importu testovacích dat vzroste až nad hranici 300MB. Toto mne vedlo k myšlence, že v nějaké části kódu neuvolňuji reference na již nepoužívaná data a díky tomu GC18 nemůže paměť uvolňovat. Při kontrole kódu jsem však nemohl najít žádné místo, kde bych reference korektně nerušil. Specielně jsem se přitom soustředil na pomocné reference ve statických třídách, které bývají hlavním zdrojem chyb typu Memory Leak. Několikahodinové neúspěšné snažení najít chybu v kódu mne vedlo k vyhledání aplikace pro profilování paměti JRE. Pomocí nástroje Borland Optimizeit Enterprise Suite, který je pro vyzkoušení poskytován na 10 dní zdarma, jsem po několika dalších hodinách zjistil fakt, že po zrušení jakéhokoliv dialogu (metodou dispose() a následným nastavením jediné reference na něj na null) na něj i přesto zůstávají reference, a to ne ve třídách mé aplikace, ale v části paměti JRE. Až v tuto chvíli mne napadlo, že chyba nemusí být jen v mém kódu a pomocí internetových fór jsem zjistil, že se jedná o chybu JRE. Co mne však zarazilo byl fakt, že pro chybu bylo hlasováno pouze 12 krát (běžné jsou stovky hlasů) a tak jsem ještě pro jistotu pozoroval chování jiných aplikací, napsaných pomocí Javy a SWINGu – chování bylo stejné (příkladem takové aplikace je i již komentovaný iReport). 6.2.3.1.3 Proprietální řešení chyby

Na stránce s popisem chyby společnosti Sun, byla chyba klasifikována jakožto chyba ve focus19 subsystému SWINGu. Jako „nehezké“, ale funkční řešení, které způsobí uvolnění referencí a spuštění GC, byl uveden postup, při jehož aplikaci hlavní okno JFrame ztratí a opětovně získá focus. Toho lze docílit minimalizací a následnou maximalizací hlavního okna (což lze samozřejmě vyvolat programově). Další komplikaci mi způsobil fakt, že tento hack20 nefunguje na verzi JRE 1.5.08, kterou jsem používal. Po instalaci nové verze se paměť začala po provedení hacku skutečně uvolňovat a řešení již bylo jednoduché – průběžně kontrolovat stav paměti. Pokud překročí spotřeba paměti určitou hranici, je nutné programově zavřít a znovu otevřít hlavní okno. Toto lze implementovat například pomocí vlákna, které průběžně paměť sleduje.

18

Garbage Collector mechanismu zaměřování komponent GUI, zaměření komponenty GUI 20 programový postup pro nestandardní provedení požadované činnosti 19

63


6.2.3.2 Drobná chyba při používání komponenty SWINGu JDialog Druhý problém implementace Javy, na který jsem během programování narazil, souvisí se zobrazováním ikony rodičovského okna v dialogu založeném na komponentě JDialog. Pokud je dialog nastaven jako modální s neměnnou velikostí, nezobrazí se u něj ikona jeho rodiče, což je chování špatné. Jedná se opět o nahlášenou chybu s číslem 4295864, která je označená jako vyřešená, nicméně se stále projevuje (Nahlášená byla v roce 1999!). Vzhledem k tomu, že se jedná o „kosmetický“ detail a na funkci aplikace to nemá žádný vliv, uvádím zde tuto chybu pouze jako zajímavost.

6.2.4 Přehled implementovaných částí a rozsahu implementace V tomto odstavci shrnu stručně rozsah implementace. Aktuální počet implementovaných tříd je 125 a celkový počet řádků kódu je cca 9 000. Počet řádků jsem zjistil pomocí nástroje GeroneSoft's Code Counter Pro a nejsou v něm započteny komentáře, prázdná místa ani počet řádků generovaného kódu GUI, který představuje cca 4000 řádků. Stávající verze vznikla za 63 dní intenzivního programování. Předpokládám, že zhruba 60% kódu tvoří implementace GUI. Balíček

dbacces emailing entities exceptions gui input printing resources tools xls

Odpovědnost/Obsah

správa spojení s datovým zdrojem, logování změn zasílání emailů objekty typu Java Beans, reprezentace databázových tabulek, vrstva persistence ošetřování výjimek, vlastní výjimky implementace GUI načítání vstupních dat podpora tisku externí zdroje (ikony, obrázky,...) podpůrné nástroje podpora práce s formátem XLS

Počet tříd

12 3 22 7 91 1 4 1 6

Tabulka 6.1 – Přehled počtu implementovaných tříd podle balíčků

Následující tři tabulky obsahují přehled implementovaných tříd GUI, které definují vlastní vzhled oken, panelů a dialogů. Hodnoty LOC21 uvádějí počet řádků kódu včetně automaticky generovaného kódu visuálním návrhářem. Třída okna

MainFrame MailFrame CustomerFrame SettingsFrame

Popis

LOC

hlavní okno aplikace, obsahuje místo pro panely okno interního emailového klienta okno zákazníka okno nastavení

720 330 1162 72

Tabulka 6.2 - Přehled tříd hlavních oken

21

Lines Of Code

64

Kapitola 6. Implementace Třída dialogu

Popis

LOC

AbstractDialog BillFromXLSCDRsDialog CDRXlsExportDialog CmrContactsDialog EditTypeDialog EmailRecipientsSelectionDiaog ImportRateBookDialog NewCDRProjectDialog

rodič všech dalších dialogů dialog pro tvorbu faktur dialog pro tvorbu CDR výpisů dialog pro správu kontaktních osob dialog pro editaci typů (zákazníka, platby,...) dialog pro výběr adresátů emailu dialog pro import sazebníku dialog pro založení CDR projektu dialog pro zobrazení nekonzistentních dat při zakládání CDR projektu dialog pro oznámení nenalezených destinací dialog pro otevření a správu CDR projektů dialog pro tisk štítků dialog pro tvorbu reportu – statistického přehledu

83 685 200 264 200 180 205 285

NewCDRProjectBadDialog NotFoundDestinationsDialog OpenCDRProjectDialog PrintLablesDialog ReportXLSExportDialog

307 66 247 309 191

Tabulka 6.3 - Přehled tříd dialogových oken Třída panelu

Popis

CallListPanel CLIsPanel CustomersPanel DefaultEmptyPanel DodgerListPanel RateBookPanel

panel pro zobrazení stromu projektu panel pro přehled dostupných telefonních čísel panel pro přehled dostupných zákazníků základní, prázdný panel s logem panel pro zobrazení neplatičů panel pro přehled a editaci sazebníků

LOC

194 106 113 25 43 314

Tabulka 6.4 - Přehled tříd panelů hlavního okna

6.3 Instalační příručka Instalace aplikace se dělí na instalaci serverové a klientské části. Je vhodné nejprve nainstalovat databázový server a vytvořit v něm požadované schéma a teprve poté instalovat klientskou část. Pro úspěšnou instalaci postupujte dle níže uvedených bodů. Veškerý potřebný software najdete na CD v adresáři install. Struktura adresáře je popsána v příloze E. Uvedený postup je platný pro platformu MS Windows a otestovaný na verzi NT 5.1 (Windows XP SP2).

6.3.1 Instalace serverové části a vytvoření schématu 6.3.1.1 Instalace a konfigurace MySQL a) Pomocí Setup.exe spusťte instalačního průvodce a zvolte typickou instalaci. b) Registraci u MySQL můžete přeskočit, zvolte Skip Sign-Up a poté Configure the MySQL Server now. c) Na dalších obrazovkách zvolte postupně Detailed Configuration, Server Machine, Multifunctional Database.


65

d) Nastavte instalační cestu a při následné konfiguraci volte postupně DSS/OLAP, Enable TCP/IP Networking (port 3306) a Enable Strcit Mode, Best Support For Multilingualism (UTF8), Install As Windows Service (Lanuch MySQL Server automatically) a Include Bin Directory in Windows PATH. e) Při nastavování administrátorského hesla si údaje pečlivě zapamatujte, budou potřeba u dalších kroků instalace. Zadejte tedy heslo uživatele root (administrátor) a zvolte volbu Enable root Access from remote machine. f) Po instalaci serveru proveďte restart stanice.

6.3.1.2 Vytvoření databázového schématu Pro vytvoření databázového schématu spusťte soubor +create_on_win.bat. Budete vyzváni k zadání hesla. Použijte heslo uživatele root, které jste nastavili při instalaci serveru. Pokud by byl tento skript z nějakého důvodu nefunkční (nebo nekompatibilní s používaným OS), spusťte konzoli MySQL a v ní pomocí příkazu source skript createdb.ddl a poté initdb.sql.

6.3.2 Instalace klienta Pokud na stanici není nainstalován JRE verze minimálně 1.5, nainstalujte jej spuštěním souboru jre-1_5_0_09-windows-i586-p.exe. Instalace verze 1.5.09 je rovněž doporučená, takže pokud nemáte verzi vyšší, upgradem stávající verze nic nezkazíte. Pro instalaci vlastní aplikace je připraven průvodce a instalace je pomocí něj přímočará. Spusťte soubor setupcrm.exe a projděte průvodce, který jednoduše nainstaluje aplikace na stanici (pouze OS Windows). Při prvním spuštění budete dotázáni na přihlašovací údaje k databázi. Jméno databáze nastavte na hodnotu crm, ostatní údaje záleží na nastavení vašeho serveru. Jako uživatelské jméno můžete použít root s heslem nastaveným při instalaci nebo v konzoli MySQL vytvořit nového uživatele a nastavit mu příslušné oprávnění k databázi (z bezpečnostních důvodů je toto doporučené). Pro první přihlášení do systému CRM použijte uživatelské jméno admin bez hesla. Pokud používáte jiný OS nežli Windows, zkopírujte obsah adresáře dist na Vámi požadované místo. Pro spuštění pak použijte příkaz java –jar CRM.jar.

66


Kapitola 7. Testování

67

7 Testování 7.1 Jednotkové testy Testy jednotlivých dílčích části jsem prováděl zároveň s jejich implementací. Testování probíhalo metodou WhiteBox22 a v rámci něj jsem prověřoval zejména :

API implementovaných jednotek (tříd) okrajové podmínky (zda modul pracuje správně na hranicích, omezujících výpočet) nezávislé cesty (zda může být každý příkaz proveden alespoň jednou) cesty pro zpracování výjimek (zda je každá výjimka korektně ošetřena) zda volání příslušných metod přináší očekávané změny (v souborech, tabulkách atd.) funkčnost jednotek - každá metoda byla volána několikrát s různými parametry, aby mohla být dostatečně ověřena její správná činnost

Jednotkové testy odhalovaly řadu drobných chyb, které jsem v zápětí opravoval. Jednalo se jak o chyby syntaktické, tak o chyby sémantické.

7.2 Integrační testy Testování integrace částí mělo za úkol prověřit správné reakce jednotlivých celků na akce prováděné v jejich souvisejících částech. Toto testování jsem prováděl vždy po dokončení implementace jednotek nějakého většího celku (např. menšího balíčku, jako je xls nebo nějaké složitější třídy) a odhalené chyby jsem hned po dokončení testu odstraňoval. Tento postup bývá označován jako metoda inkrementální integrace. Tedy postupně se testují dílčí integrované části a nakonec (po vyřešení marginálních problémů) integrace celého systému. Integračním testováním jsem tedy prováděl verifikaci programových konstrukcí za pomocí metod BlackBox23 a částečně WhiteBox (pokrytí hlavních cest řízení). Chyby, odhalené v těchto testech, nebyly již tak jednoduché a odstraňování některých z nich bylo překvapivě komplikované. Komplikace nastávaly hlavně proto, že části systému se navzájem ovlivňují a odstranění chyby v jedné časti občas způsobilo vznik chyby v části související. Integračními testy jsem prověřoval zejména: 22

správnou funkčnost presentační vrstvy (GUI a jeho logika) součinnost prezentační vrstvy a logické vrstvy (jádro klientské části) spojení logické vrstvy aplikace s databázovým serverem

Způsob testování, při němž se pracuje přímo se zdrojovým kódem. Způsob testování, při němž nemusí být znám zdrojový kód – důraz se klade na správnou činnost celku v závislosti na vstupních datech. 23

68


7.3 Testy GUI V rámci testování grafického uživatelského rozhraní jsem pomocí znalostí z předmětů 36SI sestavil následující seznamy otázek, které sloužily jako pomyslné scénáře testů. GUI testy oken Bude okno správně otevřeno klávesovými příkazy či příkazy menu? Může být okno zmenšeno/zvětšeno, přesunuto, schováno? Jsou všechna data uvnitř okna dostupná myší, funkční klávesou, šipkami nebo klávesnicí? Je okno správně obnoveno, když se překryje a znovu zavolá? Jsou všechny funkce v okně dostupné, když je potřeba? Jsou všechny funkce v okně spustitelné? Jsou všechna roletová menu, nástrojové lišty, dialogová okénka, knoflíky, ikony a ostatní řídicí prvky správně zobrazeny? Je aktivní okno správně vysvícené? Pokud je spuštěno více vláken, jsou okna správně a ve správný čas aktualizovaná? Nezpůsobí vícenásobné kliknutí myši, nebo kliknutí mimo okno neočekávaný vedlejší efekt? Zavře se okno správně? GUI testy roletových menu a operací myši Je zobrazena správná příkazová lišta v odpovídajícím kontextu? Pracuje správně stahování menu? Jsou všechny funkce v menu a případné podfunkce správně zobrazeny? Jsou všechny funkce v menu správně ovladatelné myší? Dají se příslušné funkce spustit správně odpovídajícím klávesovým příkazem? Jsou funkce správně vysvíceny nebo neosvíceny podle daného kontextu? Dělá každá funkce to, co má? Jsou názvy funkcí názorné a srozumitelné? Jsou operace myši správně rozpoznány? Pokud je požadované vícenásobné kliknutí, je správně rozpoznáno? Je správně zobrazen a změněn kurzor v daném kontextu? Pro datové vstupy: Jsou alfanumerické datové vstupy správně zavedeny do systému? Jsou nesprávná data správně rozpoznána? Aktuální verze systému se z hlediska GUI testů ukázala jako nezpůsobilá, nicméně pro první verze aplikací je tento jev normální. Při dalších updatech by měly nedostatky postupně mizet.


69

7.4 Validační a systémové testy, akceptace a testy použitelnosti Validační testování bude probíhat spolu s testováním systémovým. Systémové testování prakticky ověřuje funkčnost systému v prostředí jeho reálného nasazení. Validace pak testuje, zda daný software splňuje „rozumná očekávání“ zákazníka, která jsou definovaná v katalogu požadavků na vytvářený software (odstavec 4.3). Výsledky těchto testů pak rozhodnou o akceptaci systému. O akceptačních testech a testech použitelnosti jsem se již zmiňoval v odstavci 5.3 - Akceptační testy a testy použitelnosti.

Ilustrace 7.1 – Model testování a jeho zařazení do struktury projektu

70


Kapitola 8. Závěr

71

8 Závěr 8.1 Zhodnocení výběru použitých technologií a nástrojů K volbě technologie a metodiky pro analýzu a návrh nemám žádné výhrady. Jazyk UML poskytuje k modelování dostatek elementů a díky tomu, že je univerzální a není omezen žádnou metodikou, také dostatek volnosti při jejich používání. Metodiku, založenou na klasickém vývojovém cyklu v kombinaci s iterativní fází dokončení rovněž hodnotím jako vhodnou. Co se týče vhodnosti zvolených technologií a nástrojů pro implementaci, musím konstatovat, že výběr technologie Java nebyl pro projekt tohoto typu nejšťastnější. Logická vrstva aplikace vznikala opravdu rychle, hlavně z důvodu nepřeberného množství funkcí tohoto jazyka, které velmi zjednodušují a urychlují vývoj. Jako nedostatek však shledávám nízkou podporu pro tvorbu GUI ve srovnání s konkurenčními technologiemi jako jsou .NET (C#) společnosti Microsoft nebo, ne tak mladé, Delphi či C++ Builder od společnosti Borland. Dle mého názoru je modularita některých komponent SWINGu přehnaná. Spolu s chybami, které obsahují vlastní komponenty i jádro SWINGu a s ne zcela „přívětivými“ správci rozvržení se tvorba složitějšího formuláře stává poměrně komplikovanou záležitostí. Na druhou stranu je zdarma k dispozici velké množství vývojových nástrojů a knihoven a výsledný produkt není omezen platformou Windows. Kdybych měl volit znovu technologii pro implementaci takto silně formulářově zaměřeného systému, který je primárně určen pro běh na platformě Windows, nejspíše by má volba směřovala k technologii .NET a jazyku C# a to z důvodu lepší podpory pro implementaci GUI a vyššímu výkonu výsledné aplikace. S databázovým serverem MySQL 5 jsem velmi spokojen. Výkon hodnotím jako slušný, na žádnou chybu jsem při práci nenarazil a dostupné nástroje pro práci s databází mi rovněž vyhovovaly (MySQL administrator a MySQL Query Browser). Výběr nástroje pro ER modelování shledávám rovněž vhodným. I přes drobné chyby v generovaném skriptu, které jsem musel ručně odstraňovat, mi práce s ním vyhovovala.

8.2 Zhodnocení dosažených výsledků Cílem práce bylo analyzovat potřeby společnosti BCH zahrnující postupy od přijetí dat o provedených hovorech až po jejich fakturace dle požadavků této firmy. Dále navrhnout a realizovat aplikaci na bázi technologií Java 5 a MySQL 5 a to s návazností na Excel, podporou tisku, rozesílání emailů a tvorbou statistických přehledů. Výsledná aplikace byla určena primárně k evidenci zákazníků a jejich hovorů, tvorbě faktur s automaticky vypočtenými konečnými cenami za jejich uskutečněné hovory podle smluvních sazebníků, výpisů hovorů a dalších potřebných materiálů. V rámci analýzy potřeb společnosti jsem absolvoval několik sezení se dvěma zástupci BCH a shromažďoval informace o jejich představách. Po každém sezení jsem vytvořil několik bodů s textovým popisem probíraných funkcionalit a na dalším jsem tento seznam znovu předložil ke kontrole. Přišlo mi až neuvěřitelné, jak se požadavky v průběhu těchto sezení neustále měnily. Nakonec jsme došli ke společné shodě, jejímž výsledkem je především odstavec 4.3 -

72

Kapitola 8. Závěr

Podrobný katalog požadavků a bližší specifikace. Jako součást analýzy jsem se soustředil rovněž na modelování stěžejních firemních procesů. Po provedení a zhotovení analytické části včetně návrhu databáze jsem přistoupil k návrhu vlastního řešení. Kladl jsem důraz na logickou modularitu systému a na modelování hlavních jeho částí. Při návrhu jsem se nezabýval příliš detaily, ale snažil jsem se vytvořit celkovou představu o součinnosti a odpovědnosti jednotlivých komponent. Zároveň jsem již přihlížel k zvolené implementační technologii Java. V této části jsem se rovněž zabýval uživatelským rozhraním, jakožto důležitou částí výsledné aplikace. Při implementaci jsem poté realizoval jednotlivé navržené části. Součástí implementace bylo také vyhledání vhodných podpůrných knihoven a jiných nástrojů spolu se studiem jejich možností a principu práce s nimi. Podařilo se mi implementovat všechny nestandardní aspekty zadání, tedy podporu emailů, tisku a práce s formátem XLS. Tvorba statistického přehledu spočívá ve statistickém odhadu výnosů a nákladů za dané období. Implementaci jsem provedl pomocí technologie Java 5 a databáze MySQL 5. Při implementaci GUI jsem objevil i několik chyb v knihovně SWING. Současná verze systému obsahuje plně odladěnou část databáze. Logická část klientské strany aplikace implementuje podporu všech požadavků definovaných v analytické části s výjimkou správy uživatelů vlastního systému. Prezentační vrstva (tedy GUI) v tuto chvíli neobsahuje všechna požadovaná rozhraní, troufám si však říci, že cca 80% GUI je již hotovo (stěžejní části pro práci s projekty, tvorbu faktur, tisk, správu zákazníků a sazebníků,...) nicméně není zcela odladěno. Stávající verze je v době psaní tohoto odstavce již instalována u firmy BCH. Práce s aplikací probíhá zatím v duchu plnění klientské databáze, která je nutná pro používání dalších funkčností celého systému. Instalací byly zároveň započaty poslední (nicméně ne jednodušší) fáze celého projektu, kterými jsou testování alfa verze a iterativní dokončení vývoje na základě alfa verze.

8.3 Doporučení pro další pokračováni projektu V další práci na tomto projektu dokončím implementaci GUI a správy uživatelů. Poté se budu společně s BCH soustředit na odstraňování nalezených chyb a přizpůsobování GUI podle „rozumných představ“ BCH. Po dokončení a akceptaci systému bych rád projednal možnosti dalšího rozšíření. Jako reálné se zatím jeví vytvoření internetové aplikace pro zákazníky. Aplikace by mohla umožňovat zákazníkům komplexní přehled nad všemi jejich hovory, fakturami a jinými vystavenými materiály za libovolné období. Zároveň by bylo možné vytvořit podporu pro internetové hlášení problémů, správu kontaktních údajů a jiné služby. Tato aplikace by rovněž mohla podporovat automatické nahrávání vstupních datových souborů (např. výběrem dedikované emailové schránky) a mnohé jiné funkce.

Kapitola 9. Použité zdroje

73

9 Použité zdroje 9.1 Literatura a slidy [1] P. Herout : Učebnice jazyka Java. České Budějovice: KOOP, 2005. ISBN 80-7232-115-3 [2] Spell, Brett : Java Programujeme Profesionálně. Praha : Computer Press, 2002. ISBN 80-7226-667-5 [3] Ian F. Darwin : Java kuchařka programátora. Brno : Computer Press, 2006. ISBN 80-251-0944-5 [4] Joshua Bloch : Java efektivně. Praha : Grada, 2002. ISBN 80-247-0416-1 [5] Jim Arlow, Ila Neustadt : UML a unifikovaný proces vývoje aplikací. Brno : CP Books, 2005. ISBN 80-7226-947-X [6] Božena Mannová, Karel Vosátka : Řízení softwarových projektů. Praha : Nakladatelství ČVUT, 2005. ISBN 80-01-03297-3

[7] K. Richta : Slidy pro podporu výuky předmětu SI1 na FEL ČVUT. Praha, 2005. [8] CGG : Slidy pro podporu výuky předmětu 36NUR na FEL ČVUT. Praha, 2005.

74

Kapitola 9. Použité zdroje

9.2 Internetové odkazy [1i] Typy diagramů OOA a návody na jejich použití. http://www.jiludwig.com/Diagram_Types.html [2i] Objektová analýza, návrh a programování. http://objekty.vse.cz/Main/HomePage [3i] Návrh aplikace v jazyce UML – seriál článků. http://interval.cz/serialy/navrh-aplikaci-v-jazyce-uml/ [4i] Stránky o Javě - dokumentace API, tutoriály, chyby atp. http://java.sun.com/ [5i] Stránky věnované IDE NetBeans – dokumentace, tutoriály atp. http://www.netbeans.org/ [6i] Stránky věnované tvorbě GUI v Javě - JDesktop. http://community.java.net/javadesktop/ [7i] Stránky věnované tvorbě GUI v Javě a integraci- JDIC. https://jdic.dev.java.net/ [8i] Stránky věnované tvorbě GUI v Javě integraci- SwingLabs. http://swinglabs.org/index.jsp [9i] Stránky projektu jXLS – knihovny pro export do XLS formátu z Javy. http://jxls.sourceforge.net/ [10i] Stránky projektu Java Excel API – knihovny pro práci s formátem XLS v Javě. http://jexcelapi.sourceforge.net/ [11i] Stránky projektu JasperReports – knihovny pro tvorbu reportů, jejich tisk a export v prostředí Javy. http://jasperforge.org/sf/projects/jasperreports [12i] Stránky projektu iReport – nástroje pro vizuální návrh designu pro knihovnu JasperReports. http://jasperforge.org/sf/projects/ireport [13i] Stránky věnované MySQL – dokumentace, návody atp. http://www.mysql.com/ [14i] Seriál o MySQL 5. http://www.linuxsoft.cz/article_list.php?id_kategory=232

Kapitola 10. Seznam ilustrací, tabulek a příloh

75

10 Seznam ilustrací, tabulek a příloh 10.1 Seznam ilustrací Ilustrace 3.1 - Kontextový diagram ............................................................................................9 Ilustrace 3.2 - Use case diagram nejvyšší úrovně.....................................................................10 Ilustrace 3.3 - Větší detail případů užití Spravovat CDR projekty, Spravovat sazebníky a Spravovat klienty....................................................................................................................11 Ilustrace 3.4 - Větší detail případů užití Vytvářet výstupy, Tisknout a exportovat, Zasílat emaily a Spravovat uživatelské nastavení .........................................................................12 Ilustrace 3.5 - Větší detail případů užití Spravovat uživatele ..............................................13 Ilustrace 4.1- ER diagram databáze..........................................................................................26 Ilustrace 4.2 – Stavový diagram procesu „Založení CDR projektu“........................................34 Ilustrace 4.3 - Stavový diagram procesu „Vytvoření CDR výpisů“........................................35 Ilustrace 4.4 - Stavový diagram procesu „Vytvoření faktur“ ...................................................37 Ilustrace 4.5 - Diagram aktivit vymazání CDR projektu..........................................................38 Ilustrace 4.6 – Diagram aktivit zasílání emailu ........................................................................39 Ilustrace 5.1- Diagram spolupráce balíčků a ostatních komponent nejvyšší úrovně...............41 Ilustrace 5.2- Bližší pohled na komponentu dbaccess..............................................................42 Ilustrace 5.3 – Komponenty pro logování změn ......................................................................42 Ilustrace 5.4 –Základní návrh abstraktní třídy Entity...............................................................44 Ilustrace 5.5 – Základní návrh třídy pro zasílání emailů ..........................................................44 Ilustrace 5.6 - Základní návrh třídy ExceptionProcessor .........................................................45 Ilustrace 5.7 - Základní návrh komponenty printing ................................................................46 Ilustrace 5.8 - Základní návrh tříd XlsImporter a XlsExporter ................................................47 Ilustrace 5.9 - Základní návrh struktury komponenty gui ........................................................48 Ilustrace 5.10 – Základní schéma prvků GUI nejvyšší úrovně................................................49 Ilustrace 5.11 - Základní návrh třídy AbstractDialog...............................................................50 Ilustrace 5.12 - Struktura komponenty pro měření průběhu.....................................................52 Ilustrace 5.13 – Diagram možné struktury hlavní menu ..........................................................53

76

Kapitola 10. Seznam ilustrací, tabulek a příloh

Ilustrace 7.1 – Model testování a jeho zařazení do struktury projektu .................................... 69

10.2 Seznam tabulek Tabulka 4.1 – Slovníček pojmů a zkratek................................................................................ 17 Tabulka 4.2 - Výchozí hodnoty atributů tabulky druh_platby ............................................... 32 Tabulka 4.3- Význam symbolů použité ER notace................................................................. 33 Tabulka 6.1 – Přehled počtu implementovaných tříd podle balíčků....................................... 63 Tabulka 6.2 - Přehled tříd hlavních oken ................................................................................. 63 Tabulka 6.3 - Přehled tříd dialogových oken ........................................................................... 64 Tabulka 6.4 - Přehled tříd panelů hlavního okna ..................................................................... 64

Textová specifikace případů užití 1 – Založit projekt a Smazat projekt............................. 13 Textová specifikace případů užití 2 - Vybrat vstupní soubor a Založit sazebník .............. 14 Textová specifikace případů užití 3 - Editovat klienta a Spravovat kontaktní osoby....... 14 Textová specifikace případů užití 4 - Vytvářet faktury a Vytvářet seznam kreditních karet .................................................................................................................................................. 14 Textová specifikace případů užití 5 - Zasílat emaily a Vybrat příjemce ............................ 15

10.3 Seznam příloh A - Příklady vytvářených materiálů B - Ukázky implementovaného grafického uživatelského rozhraní C - Dodatkové UML diagramy D - Ukázka formulářů pro akceptační testy E - Obsah přiloženého CD

Přílohy

A Příklady vytvářených materiálů A.1

Výpis CDR

-1-

-2-

A.2

Přílohy

Označení duplicitních a překrývajících se hovorů v MS Excel

Přílohy

A.3

Faktura

-3-

-4-

A.4

Přílohy

Seznam kreditních karet pro autorizaci

Přílohy

A.5

Report

-5-

-6-

Přílohy

B Ukázky implementovaného grafického uživatelského rozhraní

Ukázka 1 - Hlavní okno aplikace se stromem projektu

Ukázka 2 - Okno nastavení

-7-

Přílohy

Ukázka 3 – Okno klienta

Ukázka 4 - Různé dialogy

-8-

Přílohy

Ukázka 5 - Měření průběhu operace

Ukázka 6 - Složitější dialog pro fakturace

-9-

Přílohy

Ukázka 7 - Přihlašovací dialog

Ukázka 8 - Okno interního poštovního klienta s dialogem pro výběr adresátů

- 10 -

Přílohy

Ukázka 9 - Náhled na tisk a dialog nastavení tisku

- 11 -

User

MainForm : JFrame

InputLoade r

Database

Nov ý CDR proje kt <>

:A bstractDialog

show Zadání vstu pu (položky att_XXX) a potvrzení

C.1 Sekvenční diagram založení nového projektu

C Dodatkové UML diagramy

Přílohy

v alidate()

inva lid input

cdrp:= <>

:CDR_projekt

setXXX(att_XXX)

calls:=loadCallsFro mFile(att_file ) setCalls(calls) ok:=insertSafeToDatab ae() sp:=startRollBackTrans action() getPreparedStatement (query) [execute state ment faild] ro llBackToSav epoint(sp)

ok ==fals e ok ==tr ue

:Abstrac tDialog

<>

clp:= <>

:CallListPane l

zobrazení volba akce

setCallLis tPanel(clp) se tCurrentCDRProject(cdrp ) s etMasterViewAsCallListPanel()

zobrazení výpisu p rojektu

GUIStat us

A pplicationSta tus

- 12 -

Přílohy

D Ukázka formulářů pro akceptační testy Akceptace požadavku 4.3.2.2.1 Správa klientské databáze Požadavek: Aplikace bude dovolovat kompletní editaci všech evidovaných položek zákazníka, odsouhlasených v části analýzy, pomocí přívětivého uživatelského rozhraní. Rozhraní bude podporovat hromadné náhledy, zejména pak:

zobrazení seznamu klientů zobrazení seznamu všech čísel (CLI) zobrazení seznamu sazebníků

Akceptováno Neakceptováno Důvody Nesplněné části požadavku

Popis chyb splněných částí požadavku

Případné návrhy na zlepšení

- 13 -

Přílohy Akceptace požadavku 4.3.2.2.2 Import dat Požadavek:

import vstupních textových souborů s výpisem všech volání za dané období CS/CPS vstupních souborů 800 vstupních souborů import textového souboru se sazebníky včetně kontroly validní dvojice cena-destinace (program nahlásí chybu, pokud bude jedna z položek ve vstupním souboru chybět)

Upřesnění: Po importu sazebníku se daný sazebník zobrazí. Po importu vstupního souboru s výpisem hovorů se zobrazí strom projektu s vypočítanými cenami za jednotlivé hovory a s celkovými cenami za číslo. Ceny budou odpovídat příslušným sazebníkům. Všechna data půjdou uložit do databáze.

Akceptováno Neakceptováno Důvody Nesplněné části požadavku

Popis chyb splněných částí požadavku

Případné návrhy na zlepšení

- 14 -

Přílohy

E Obsah přiloženého CD adresář se zdrojovými kódy systému database/ SQL skripty pro vytvoření a inicializaci databáze java-build/ kompilované třídy klientské aplikace java-dist/ kompletní zkompilovaná klientská aplikace připravená ke spuštění (oproti java-build obsahuje všechny potřebné knihovny, šablony a adresáře) java-src/ kompletní zdrojové kódy klientské aplikace, potřebné knihovny, zdrojové kódy projektu v NetBeans IDE, skript pro vytvoření instalátoru nástrojem Inno Setup data/ adresář s testovacími vstupními daty, testovacími databázovými daty a příklady vytvářených výstupů docs/ adresář s dokumentačními reporty databáze a javadoc dokumentací klienta install/ instalační sada – vše potřebné pro nainstalování a spuštění systému 1. Server/ vše k instalaci serveru CRM & billing/ skripty pro tvorbu a inicializaci databáze +create_on_win.bat createdb.ddl initdb.sql MySQL Server 5.0.27 Community Edition/ MySQL server 2. Client/ vše k instalaci klienta CRM & billing/ soubory k instalaci klienta setupcrm.exe instalační soubor pro MS Windows dist/ funkční sada pro jiné OS (stačí zkopírovat) JRE/ Java Runtime Environment 3. Additional/ doplňkové programy, které se dají integrovat text/ vlastní diplomová práce install.html instalační příručka index.html úvodní informace o diplomové práci crm/

-

telekomunikační firmy

Recommend Documents