Systém domácího účetnictví pro OS Linux

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Systém domácího účetnictví pro OS Linux Analýza, návrh a kompletní zpracování

Autor:

Bc. Kamil Pošvic Informační technologie

Vedoucí práce:

Praha

Ing. Michal Valenta, PhD.

duben 2009

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury. V Praze dne Kamil Pošvic

2

Anotace Tato diplomová práce se zabývá analýzou poţadavků na systém domácího účetnictví, návrhem a jeho vlastní implementací. Důraz je kladen především na vyuţití open-source nebo freeware nástrojů, multiplatformitu a rozšiřitelnost. Výsledný informační systém by měl slouţit jako základní stavební prvek domácnosti zajišťující plánování investic, pravidelnou kontrolu účtů i zpětnou analýzu výsledku hospodaření. Annotation This diploma thesis deals with the analysis of requirements for a home accounting system, its design and own implementation. In the first place it focuses on utilization of open-source or freeware tools, multiplatformity and extendibility. The resulting information system should become a household headstone for investment planning, checking and output analyzing.

3

Obsah 1. ÚVOD ...................................................................................................................................................... 8 2. POUŢITÉ TECHNOLOGIE ................................................................................................................. 9 2.1 PYTHON .............................................................................................................................................. 9 2.2 MYSQL .............................................................................................................................................. 9 2.3 KNIHOVNA QT4 ................................................................................................................................ 10 2.4 QT DESIGNER ................................................................................................................................... 11 2.5 ERIC4................................................................................................................................................ 12 2.6 PYGOOGLECHART ............................................................................................................................ 12 2.7 PHPMYADMIN .................................................................................................................................. 13 2.8 OPEN-SOURCE A GNU GPL .............................................................................................................. 13 3. ÚVODNÍ STUDIE ................................................................................................................................ 15 3.1 SOUČASNÝ STAV............................................................................................................................... 15 3.1.1 KMyMoney ............................................................................................................................... 15 3.1.2 Opale........................................................................................................................................ 15 3.1.3 Proč vlastní řešení? ................................................................................................................. 16 3.2 DEKLARACE ZÁMĚRU ....................................................................................................................... 16 3.3 ODBORNÝ ČLÁNEK ........................................................................................................................... 17 3.4 NEFUNKČNÍ POŢADAVKY .................................................................................................................. 17 3.5 NÁVRH ARCHITEKTURY .................................................................................................................... 18 3.6 ANALÝZA RIZIK ................................................................................................................................ 18 3.6.1 Rizika procesní ......................................................................................................................... 19 3.6.1.1 Chyby v analýze ............................................................................................................................... 19 3.6.1.2 Odklon od poţadavků ....................................................................................................................... 19 3.6.1.3 Špatný odhad časové náročnosti ....................................................................................................... 20

3.6.2 Rizika technologická ................................................................................................................ 20 3.6.2.1 Nekompatibilita HW a SW ............................................................................................................... 20 3.6.2.2 Nedostatečné nástroje ....................................................................................................................... 20

3.6.3 Rizika implementační ............................................................................................................... 21 3.6.3.1 Nedostatečné testování ..................................................................................................................... 21 3.6.3.2 Chybné ovládání ............................................................................................................................... 21 3.6.3.3 Znalosti............................................................................................................................................. 21

3.6.4 Rizika bezpečnostní .................................................................................................................. 22 3.6.4.1 Nefunkčnost HW .............................................................................................................................. 22 3.6.4.2 Nefunkčnost SW .............................................................................................................................. 22

4.1 SEZNAM AKTÉRŮ .............................................................................................................................. 23 4.2 ANALÝZA PŘÍPADŮ POUŢITÍ .............................................................................................................. 23 4.2.1 Přihlášení uživatele .................................................................................................................. 23 4.2.2 Odhlášení uživatele .................................................................................................................. 24

4

4.2.3 Změna hesla přihlášeného uživatele ........................................................................................ 25 4.2.4 Správa uživatelů ....................................................................................................................... 26 4.2.4.1 Přidání uţivatele ............................................................................................................................... 27 4.2.4.2 Editace uţivatele............................................................................................................................... 28 4.2.4.3 Změna hesla...................................................................................................................................... 29 4.2.4.4 Změna oprávnění .............................................................................................................................. 29 4.2.4.5 Smazání uţivatele ............................................................................................................................. 30 4.2.4.6 Zobrazení seznamu ........................................................................................................................... 31

4.2.5 Příchozí transakce ................................................................................................................... 32 4.2.5.1 Uloţení transakce ............................................................................................................................. 33 4.2.5.2 Smazání transakce ............................................................................................................................ 33

4.2.6 Převod ...................................................................................................................................... 35 4.2.7 Odchozí transakce.................................................................................................................... 35 4.2.7.1 Přidání kategorie .............................................................................................................................. 36 4.2.7.2 Smazání kategorie ............................................................................................................................ 38

4.2.8 Budget ...................................................................................................................................... 38 4.2.9 Výpis ........................................................................................................................................ 39 4.2.9.1 Výpis dle kategorie ........................................................................................................................... 40 4.2.9.2 Výpis dle účtu................................................................................................................................... 41

4.2.10 Graf ........................................................................................................................................ 42 4.2.11 Inventura ................................................................................................................................ 43 4.3 KONCEPTUÁLNÍ MODEL .................................................................................................................... 44 5. NÁVRH A IMPLEMENTACE ........................................................................................................... 47 5.1 FYZICKÝ DATOVÝ MODEL ................................................................................................................. 47 5.2 DATABÁZOVÉ TABULKY ................................................................................................................... 47 5.2 POPIS KOMPONENT ........................................................................................................................... 54 5.2.1 PyGoogleChart ........................................................................................................................ 55 5.2.2 Tvorba vlastního modulu ......................................................................................................... 55 5.3 GUI .................................................................................................................................................. 56 6. TESTOVÁNÍ ........................................................................................................................................ 57 6.1 TESTOVÁNÍ KÓDU ............................................................................................................................. 57 6.1.1 White-box testy ......................................................................................................................... 57 6.1.2 Black-box testy ......................................................................................................................... 57 6.2 TESTOVÁNÍ DATABÁZE ..................................................................................................................... 58 6.3 TESTOVÁNÍ GUI ............................................................................................................................... 58 6.4 TEST POUŢITELNOSTI ........................................................................................................................ 58 7. ZÁVĚR .................................................................................................................................................. 59 7.1 ZHODNOCENÍ .................................................................................................................................... 59 7.2 BUDOUCNOST PROJEKTU .................................................................................................................. 60

5

Seznam tabulek Tabulka 1 - Souhrn rizik a dopadů vyvíjeného projektu ................................................ 18 Tabulka 2 - Use Case: Přihlášení uţivatele .................................................................... 24 Tabulka 3 - Use Case: Odhlášení uţivatele .................................................................... 25 Tabulka 4 - Use Case: Změna hesla ............................................................................... 26 Tabulka 5 - Use Case: Správa uţivatelů ......................................................................... 27 Tabulka 6 - Use Case: Přidání uţivatele......................................................................... 27 Tabulka 7 - Use Case: Editace uţivatele ........................................................................ 28 Tabulka 8 - Use Case: Změna hesla ............................................................................... 29 Tabulka 9 - Use Case: Změna oprávnění........................................................................ 29 Tabulka 10 - Use Case: Smazání uţivatele .................................................................... 30 Tabulka 11 - Use Case: Zobrazení seznamu .................................................................. 31 Tabulka 12 - Use Case: Příchozí transakce .................................................................... 32 Tabulka 13 - Use Case: Uloţení transakce ..................................................................... 33 Tabulka 14 - Use Case: Smazání transakce .................................................................... 34 Tabulka 15 - Use Case: Přidání kategorie ...................................................................... 37 Tabulka 16 - Use Case: Smazání kategorie .................................................................... 38 Tabulka 17 - Use Case: Budget ...................................................................................... 38 Tabulka 18 - Use Case: Výpis ........................................................................................ 40 Tabulka 19 - Use Case: Výběr dle kategorie .................................................................. 40 Tabulka 20 - Use Case: Výpis dle účtu .......................................................................... 41 Tabulka 21 - Databázové tabulky: Uzivatele ................................................................. 47 Tabulka 22 - Databázové tabulky: Ucty ......................................................................... 48 Tabulka 23 - Databázové tabulky: Kategorie ................................................................. 48 Tabulka 24 - Databázové tabulky: Skupiny ................................................................... 48 Tabulka 25 - Databázové tabulky: Mesice ..................................................................... 49 Tabulka 26 - Databázové tabulky: Budget ..................................................................... 49 Tabulka 27 - Databázové tabulky: Inventura ................................................................. 50 Tabulka 28 - Databázové tabulky: Prichozi ................................................................... 51 Tabulka 29 - Databázové tabulky: Odchozi ................................................................... 51 Tabulka 30 - Databázové tabulky: Prevody ................................................................... 52 Tabulka 31 - Databázové tabulky: Menu ....................................................................... 53 Tabulka 32 - Databázové tabulky: Toolbar .................................................................... 54

6

Seznam obrázků Obrázek 1 - Architektura systému .................................................................................. 18 Obrázek 2 - Use Case: Přihlášení uţivatele .................................................................... 24 Obrázek 3 - Activity Diagram - Přihlášení uţovatele..................................................... 24 Obrázek 4 - Use Case: Odhlášení uţivatele.................................................................... 25 Obrázek 5 - Dialog Přihlášení do systému ..................................................................... 25 Obrázek 6 - Use Case: Správa uţivatelů ........................................................................ 26 Obrázek 7 - Activity Diagram: Přidání uţivatele ........................................................... 28 Obrázek 8 - Activity Diagram: Editace uţivatele........................................................... 28 Obrázek 9 - Activity Diagram: Změna hesla .................................................................. 29 Obrázek 10 - Activity Diagram: Změna oprávnění ........................................................ 30 Obrázek 11 - Activity Diagram: Smazání uţivatele ....................................................... 31 Obrázek 12 - Návrh GUI - Seznam uţivatelů................................................................. 31 Obrázek 13 - Use Case: Příchozí transakce .................................................................... 32 Obrázek 14 - Activity Diagram: Uloţení transakce ....................................................... 33 Obrázek 15 - Návrh GUI: Příchozí transakce ................................................................. 34 Obrázek 16 - Návrh GUI: Převod ................................................................................... 35 Obrázek 17 - Návrh GUI: Odchozí transakce ................................................................ 36 Obrázek 18 - Use Case: Přidání kategorie ...................................................................... 36 Obrázek 19 - Activity Diagram: Přidání kategorie ......................................................... 37 Obrázek 20 - Návrh GUI: Přidání kategorie................................................................... 37 Obrázek 21 - Use Case: Budget...................................................................................... 38 Obrázek 22 - Activity Diagram: Budget......................................................................... 39 Obrázek 23 - Návrh GUI: Budget................................................................................... 39 Obrázek 24 - Use Case: Výpis........................................................................................ 40 Obrázek 25 - Návrh GUI: Výpisy................................................................................... 42 Obrázek 26 - Use Case: Graf .......................................................................................... 42 Obrázek 27 - Návrh GUI: Graf ....................................................................................... 43 Obrázek 28 - Use Case: Inventura .................................................................................. 43 Obrázek 29 - Návrh GUI: Inventura ............................................................................... 44 Obrázek 30 - Konceptuální model .................................................................................. 45 Obrázek 31 - Návrh GUI: Hlavní okno .......................................................................... 56

7

Kapitola 1 1. Úvod Cílem této diplomové práce je návrh a implementace systému domácího účetnictví. Systém musí umoţňovat přehledné výpisy a statistiky pro vedení domácího účetnictví. Důleţitou roli v návrhu je poţadavek na multiplatformitu systému. Dalším neméně důleţitým poţadavkem je vyuţití vhodných freeware nebo open-source technologií. Celý projekt bude dále vyvíjen i spravován pod licencí GPL. Všechny části projektu jsou pečlivě dokumentovány v souladu se zvyklostmi softwarového inţenýrství. V následující kapitole se nachází stručné seznámení s technologiemi jako např. Python, MySQL, Qt 4 a nástroji jako např. Qt Designer, Eric4, PyGoogleChart a phpMyAdmin, které byly v rámci implementace pouţity. Ve třetí kapitole nalezneme úvodní studii obsahující seznámení se současným stavem, deklaraci záměru, odborný článek, dále pak katalog poţadavků, návrh architektury a analýzu rizik. Ve čtvrté kapitole je provedena analýza projektu. Tato část obsahuje přehled aktérů systému, ale především konceptuální datový model a analýzu případů pouţití. Jednotlivé případy jsou modelovány pomocí Use Case tabulek, Aktivity diagramů a jsou zde načrtnuty návrhy grafického uţivatelského rozhraní. Implementaci je věnována pátá kapitola, zaměřena je především na seznámení s datovým modelem, jednotlivými tabulkami a uloţenými procedurami, které tvoří páteř systému. V neposlední řadě se zde blíţe seznámíme s architekturou a jsou zde rozebrány nejzajímavější partie systému. Šestá kapitola je věnována testování a sedmou kapitolou, závěrem, je tato práce výhledem do budoucnosti systému ukončena. Nedílnou součástí práce je instalační, která tvoří přílohu A.

8

Kapitola 2 2. Pouţité technologie Tato kapitola má za úkol seznámení s nejdůleţitějšími technologiemi, které jsou pro řešený úkol pouţity.

2.1 Python Python je univerzální strojově nezávislý jazyk1. Je navrţen tak aby klad důraz na čitelnost kódu. Základní syntaxe python a sémantika je minimalistická, zatímco základní knihovna je rozsáhlá a zevrubná. Jeho vyuţití mezer jako bloků vyznačující jednotlivé úrovně běhu programu je poměrně neobvyklé vzhledem k ostatním populárním programovacím jazykům. Python podporuje různé programovací formy (primárně objektově orientované, kategorické a funkční) a představuje plně dynamický systém a plně automatický management paměti, podobně jako Perl, Ruby, Schneme a Tcl. Stejně jako ostatní dynamické jazyky je i Python často pouţíván jako skriptovací jazyk. Jazyk má otevřený, na komunitě zaloţený model vývoje, řízený neziskovou nadací Python Software Foundation, která udrţuje definici standardu jazyka v CPython, referenční implementaci.

2.2 MySQL MySQL je multiplatformní databáze. Komunikace s ní probíhá pomocí jazyka SQL s mírnými úpravami (jako u ostatních SQL databází) Pro svou snadnou implementovatelnost (lze jej instalovat na Linux, MS Windows, ale i další operační systémy), výkon a především díky tomu, ţe se jedná o open-source software, má vysoký podíl na v současné době pouţívaných databázích. Velmi oblíbená a často nasazovaná je kombinace MySQL, PHP a Apache jako základní software webového serveru, ale její vyuţití je i na lokálních stanicích pro správu dat.

1

"What is Python Good For?". General Python FAQ. Python Foundation. http://www.python.org/doc/faq/general/#what-is-

python-good-for. Vytvořeno 5.9.20082

9

MySQL bylo od počátku optimalizováno především na rychlost, a to i za cenu některých zjednodušení: má jen jednoduché způsoby zálohování, a aţ donedávna nepodporovalo pohledy, triggery, a uloţené procedury. Tyto vlastnosti jsou doplňovány teprve v posledních letech, kdy začaly nejčastějším uţivatelům produktu jiţ poněkud scházet. Přehled podporovaných vlastností: cizí klíče (od verze 3.23 podporovány v tabulkách typu InnoDB) transakce (od verze 3.23 podporovány v tabulkách typu InnoDB) podpora různých znakových sad a časových pásem v datech (od verze 4.1) poddotazy (od verze 4.1) uloţené procedury (od verze 5.0) triggery (od verze 5.0) pohledy (od verze 5.0) práce s metadaty (od verze 5.0)

2.3 Knihovna Qt4 Qt (vyslovuje se jako anglické slovo „cute“) je multiplatformní grafické uţivatelské rozhraní široce vyuţívané pro tvorbu grafických rozhraní GUI2 (v tomto případě je často označován jako „widget toolkit“). Často se také vyuţívá pro negrafické programy jako konzolové nástroje a servery. Qt je nejčastěji spojováno se správcem oken KDE, webovým prohlíţečem Opera, elektronickým globusem Gogole Earth, IM3 nástrojem Skype, Adobe Photoshop Album, VirtualBox a OPIE. Knihovna je vyvíjena norskou firmou QT Software, dříve známou jako Trolltech, jejímţ 100% vlastníkem je Nokia od 17. června 2008. Qt vyuţívá C++ s několika nestandardními úpravami vloţenými dodatečným preprocesorem, který generuje standardní C++ kód těsně před kompilací. Qt můţe být také vyuţito mnoha jinými programovacími jazyky díky propojení (v našem případě pomocí knihovny PyQt, která náš kód upravuje pro komunikaci s kódem C++). 2 3

GUI = Graphical User Interface = Grafické uţivatelské prostředí IM = Instant Messaging = programy umoţňující rychlou komunikaci přes z sít

10

Knihovna běţí na všech hlavních platformách a pomáhá nám tak v našem záměru, aby systém domácího účetnictví byl multiplatformní. Její procedury a funkce které nejsou grafického rázu nám umoţňují komunikaci s SQL servery, čtení XML, práci s vlákny, síťovou komunikaci a unifikovanou multiplatformní API4 pro práci se soubory. Distribuována je pod licencí GNU Leader General Public Licence5 (podobně jako ostatní). Qt je šířena jako open-source.

2.4 Qt Designer Qt Designer je nástroj určený k návrhům a implementaci uţivatelských rozhraní zaloţené na multiplatformní knihovně Qt. Qt Designer je postaven tak, aby byl co nejvíce jednoduchý a co nejvíce usnadňoval práci s knihovnou. Kdykoliv můţete vytvořit design, který vám bude aktuálně vyhovovat a nebo ho i kdykoliv změnit bez toho, aby jste museli měnit jedinou řádku vašeho programu. Qt Designer fungoval jiţ od dřívějších verzí a jeho nespornou výhodou je, ţe se jeho ovládání a prostředí mění minimálně, takţe přechod mezi jednotlivými verzemi knihovny je bezproblémový a snadný. Pomocí programu vytvoříme jednotlivá dialogová okna, která můţeme samozřejmě vytvářet i v programu samotném. Tvorba pomocí externího programu má však řadu výhod. Jednou z hlavních je snadný překlad vašich programů. Samotný program se nezmění, ale program bude bez problémů komunikovat ve francouzštině, angličtině či jiných jazykových mutacích. Stačí jen přeloţit jednotlivé popisky v externích souborech. Další takovou výhodou je i zpětná rekurze. Jestliţe si vytvořím okno pomocí Qt Designeru a náš hlavní program si jej otevře, můţe se všemi prvky libovolně nakládat (dokonce je i smazat) a upravit okno aktuální potřebě. Výsledné rozhraní je jak funkční tak atraktivní, pohodlné pro uţivatele. Pomocí Qt Designeru si můţete dokonce zadat obsluhy jednotlivých signálů jiţ přímo do kódu.

4 5

API = Application Programming Interface = rozhraní počítačů určené pro programování aplikací LGPL = upravená, permisivnější verze GPL, speciálně připravena pro knihovny

11

2.5 Eric4 Eric je bezplatné integrované vývojové prostředí pro programovací jazyky Python a Ruby. Je navrţen jako vývojové prostředí obsahující několika programů jako například editor ovládacích prvků QScintilla, interpreter jazyka Python, Python Profiler pro nastavení profilu jazyka a mnoho dalších drobných programů usnadňující nám tvorbu. Samozřejmostí je snadná moţnost vypnutí dané funkcionality, kterou nepouţíváme nebo v dané chvíli nepotřebujeme. Celý editor sám je napsán pomocí jazyka Python a knihovny Qt. Hlavní vymoţeností tohoto editoru je projektový manaţer, editor se syntaxí jazyka, debugování kódu, profilování, spouštění programu s podporou parametrů a moţnost kdykoliv zobrazit nebo zapisovat do konsole.

2.6 PyGoogleChart PyGoogleChart je kompletní implementací Google Chart API pro Python. Tato funkcionalita nám umoţňuje dynamicky generovat grafy. Tato funkcionalita je k dispozici on-line, coţ nám zajišťuje neustálou aktualizaci, údrţbu a bezproblémový přístup. Knihovna PyGoogleChart nám umoţňuje zpracovat vstupní informace v rámci pythonu a pak je odeslat na server a získat jako výstup obrázek v námi zvolených rozměrech a formátu. Není ţádné omezení v počtu generování grafů na den nicméně si Google rezervuje moţnost omezit přístup dané IP v případě překročení více neţ 250 000 přístupů na den. Toto omezení můţe být zrušeno v případě předchozího oznámení. Pro naše potřeby bude knihovna plně vyhovovat a v případě nové verze programu se mohou i naše grafy příjemně vyvíjet. Dostupné jsou jak jednoduché grafy, tak i sloţitější 3D grafy, mapy oblastí a kontinentů či čárové kódy, speciální značky pro mobilní telefony a další. Pro naše potřeby budou plně vyhovovat základní funkce grafů, ale pro případná rozšíření je moţné vyuţít i další typy grafů.

12

2.7 phpMyAdmin phpMyAdmin je svobodný software napsaný v jazyce PHP6 a je navrţený k obsluze databáze MySQL přes internet. phpMyAdmin podporuje širokou škálu operací s databází

MySQL.

Nejčastěji

vyuţívané

operace

jsou

přímo

navrţeny

a

zakomponovány do jeho prostředí (údrţba databází, tabulky, relace, indexy, uţivatelé, přístupy a další), ale přesto máte stále moţnost si psát příkazy přímo a nespoléhat se na přednastavené šablony. Mezi hlavní výhody patří: intuitivní webové rozhraní podpora pro většinu funkcí MySQL: o procházet a vytvářet databáze, tabulky, zobrazení, pole a indexy o vytvářet, kopírovat, mazat, přejmenovávat a upravovat databáze, tabulky, pole a indexy o udrţovat server, databáze a tabulky v souladu s nastavením serveru o spouštět, editovat a ukládat si vlastní příkazy SQL o spravovat MySQL uţivatele a jejich oprávnění spravovat uloţené procedury a triggery importovat data z CSV a SQL exportovat data do mnoha formátů: CSV, SQL, XML, PDF, ISO/IEC 26300 OpenDocument Writer a Calc, Word, Excel, LATEX a další spravovat více serverů zároveň vytvářet PDF vzhled rozloţení vaší databáze vytváření komplexních dotazů pomocí QBE7 vyhledávat globálně v celé nebo v části databáze přetvářet uloţená data do libovolného formátu díky sadě předdefinovaných funkcí

2.8 Open-source a GNU GPL 8

GNU General Public License, GNU GPL (česky „všeobecná veřejná licence GNU“) je

licence pro svobodný software, původně napsaná Richardem Stallmanem pro projekt 6 7 8

PHP = rekurzivní zkratka, PHP: Hypertextový preprocesor, je skriptovací programovací jazyk na straně serveru QBE = Query by Example, databázový jazyk pro relační databáze zdroj Wikipedia, otevřená encyklopedie - http://cs.wikipedia.org/wiki/GPL - 1.04.2009

13

GNU. GPL je nejpopulárnějším a dobře známým příkladem silně copyleftové licence, která vyţaduje, aby byla odvozená díla dostupná pod toutéţ licencí. V rámci této filosofie je řečeno, ţe poskytuje uţivatelům počítačového programu práva svobodného softwaru a pouţívá copyleft k zajištění, aby byly tyto svobody ochráněny, i kdyţ je dílo změněno nebo k něčemu přidáno. Toto je rozdíl oproti permisivním licencím svobodného softwaru, jejímţ typickým případem jsou BSD licence. GNU Lesser General Public License (LGPL) je upravená, permisivnější verze GPL, původně zamýšlená pro některé knihovny. Existuje také GNU Free Documentation License, která byla původně určena pro dokumentaci k softwaru GNU, která ale byla později pouţita i jinde, například v projektu Wikipedia.

14

Kapitola 3 3. Úvodní studie Zhodnotíme současný stav, podíváme se na záměr, návrh architektury a uděláme si analýzu rizik

3.1 Současný stav V současnosti je mnoho programů a systémů poskytující účetní sluţby. Kdyţ se podíváme na celkový výběr a nastavíme si parametr open-source, tak se nám výběr jiţ razantně zúţí. Podrobným rozborem zjistíme, ţe většina těchto systémů se specializuje na firmy. Funkcionality jako podvojné účetnictví, peněţní deník nebo práce s DPH jsou pro rodinný rozpočet bezpředmětné. Takţe díky dvěma kritériím získáváme seznam čítající všeho všudy dva programy: KMyMoney9 a Opale10.

3.1.1 KMyMoney Je výchozím program v prostředí KDE zaloţeném na bázi Qt. Coţ z něj činí největšího favorita na splnění našich poţadavků. Systém je prezentován jako nejlepší osobní finanční manager pro Linux. Výhodou tohoto systému je propracovanost do detailů, distribuce jako základ systému a kompletní zpracování. Nevýhodou však je v tomto případě jeho nadnárodnost a zaměření na vyuţití pro osobní finance a menší firmy. Díky nadnárodnosti zde máme mnoho funkcionalit, které pro naše podmínky jsou nepotřebné a běţného uţivatele mohou spíše zmást a přesvědčit o sloţitosti daného programu. Další nevýhodou je zaměření i na malé firmy Takţe i zde nalezneme v tabulkách DPH, peněţení deníky a výkazy. Coţ jsou detaily které běţná rodina pro plánování výdajů na jídlo nebo na benzín asi těţko vyuţije.

3.1.2 Opale Opale je naopak prezentován jako nejjednodušší manaţer osobních financí všech dob. Shrnuje základní funkcionality bankovního účtu a zásobuje nás velkou mírou grafů a výstupů. I tento program je vytvořen pomocí open-source knihovny Qt. Bohuţel po 9

http://kmymoney2.sourceforge.net/index-home.html

10

http://www.freehackers.org/Opale

15

otevření zjistíme, ţe hlavní funkcí programu je analýza dat z měsíčních výpisů z banky a jejich grafické zpracování a moţnost statistického model pro vývoj do následujících měsíců a roků. Je zde absence zpracování jednotlivých výdajů pro celou rodinu a moţnost práce s více účty pro danou kategorii je také velmi omezena (ne-li dokonce nemoţná). Po bliţším dohledání v dokumentaci programu zjistíte, ţe primární jednoduchost udávaná ve specifikaci jde na úkor funkcionality, i kdyţ analytický modul jsem bezesporu na velmi kvalitní úrovni.

3.1.3 Proč vlastní řešení? Vlastní řešení je tedy zřejmé. Chceme mít jednoduchý systém, který budeme moci dále rozvíjet a který postihne základní potřeby běţné české rodiny. Systém bude plně otevřený a bude moţné na něj napojit i další aplikace včetně moţnosti vzdáleného přístupu přes internet a správu pro jednotlivé uţivatele. Základem je navrţení kvalitního jádra systému, který by mohl být dále rozvíjen pomocí jednotlivých modulů v jazyce Python. Na systém bude plně navazovat přístup přes internet a wap11. Tento systém je paralelně vyvíjen za pouţití technologie PHP a Apache12. Tento systém není součástí této práce.

3.2 Deklarace záměru Úkolem této diplomové práce je návrh a implementace jádra systému domácího účetnictví (pracovní název HASy 1.0). Program bude zaveden v běţné české rodině, kde jiţ v současné době funguje jakýsi základní systém plánování, ale vzhledem k současným poţadavkům a parametrům jiţ zcela nedostatečný. Cílem je tedy vytvoření nového návrhu za vyuţití moderních technologií s co největším důrazem na rozšiřitelnost a modularitu systému. Systém musí umoţňovat spravovat více účtů, moţnost výdaje třídit do kategorií a sub kategorií, moţnost plánování výdajů na jednotlivé měsíce, variabilitu začátků a konců účetního měsíce (většina rodin plánuje finance od výplaty k výplatě a výplatní datum nikdy není prvním dnem měsíce) a samozřejmě moţnost sledování výdajů po jednotlivých kategoriích v průběhu měsíce. 11 12

wap = wireless application protocol, systém pro zajištění provozu elektronických sluţeb na mobilních telefonech Apache = softwarový webový server s otevřeným kódem, http://httpd.apache.org/

16

3.3 Odborný článek Základním úkolem systému „HASy“ je zajištění zadávání účtenek a transakcí do systému, vyhodnocení zadaných dat, vytvoření výstupů a zobrazení vývoje po jednotlivých obdobích. Před začátkem práce se kaţdý uţivatel musí přihlásit. Uţivatel se přihlašuje uţivatelským jménem a heslem. Kaţdý uţivatel mám označenou výši přístupu a podle svého oprávnění má přístup k jednotlivým funkcím. Základní rozdělení je Administrátor a Uţivatel. Jednotlivé účty jsou zařazovány do databáze, kde je jim přiřazen klíč a uţivatel si vloţí svůj popis daného účtu pro lepší zpracování. Systém po instalaci obsahuje 9 základních kategorií postihující základní potřeby běţné české rodiny. Všechny jsou moţné uţivatelem editovat a změnit si je přesně pro svoje osobní potřeby. Horní hranice počtu kategorií není omezena, kategorie jsou ukládány do databáze. Dolní hranice je stanovena na 1. Systém umoţňuje plánovat po jednotlivých měsících. Datum počátku daného měsíce systém odvodí dle měsíční uzávěrky kterou provádíme 1x měsíčně a díky ní zjišťujeme diference systému a reality. Tato funkce je dobrá pro udrţení konsistence dat v případě plného nebo částečného nezadávání účtů do systému. Systém umoţňuje tři základní operace s účty. Příchozí transakce, odchozí transakce a převod. Postihuje tím jak příjem výplaty, výdaje i převod mezi jednotlivými účty (výběr z bankovního účtu je převodem peněz z účtu bankovního na účet peněţenka). Pro potřeby statistické je v systému implementována jednoduchá knihovna umoţňující zobrazení výdajů v porovnání s plán na daný měsíc. Systém umoţňuje také provést kompletní nebo částečnou zálohu dat a jejich zpětné načtení v případě havárie.

3.4 Nefunkční poţadavky Do nefunkčního poţadavků zahrnuji poţadavky, které přímo nesouvisejí s funkčností systému, ale mají na návrh systému nezanedbatelný vliv Systém bude multiplatformní (provozovatelný na více OS) 17

o V současné době pouze pod systémem Linux, dle zadání DP Systém bude umoţňovat snadnou zálohu a obnovu ze zálohy o V současné době je záloha a obnova řešena přes nástroj phpMyAdmin Instalace bude uţivatelsky příjemná o V současné době instalace probíhá pomocí konsole, v budoucnu bude také řešena knihovnou Qt

3.5 Návrh architektury Systém je řešen jednoduchou třívrstvou architekturou Obrázek 1 - Architektura systému

Zdroj: autor

Databázová vrstva je tvořena databázovým serverem MySQL Aplikační vrstva tvoří Python a jeho interpreter Prezenční vrstvu zajišťuje knihovna Qt

3.6 Analýza rizik Kaţdý projekt má svá rizika. Jestliţe se zamyslíme u softwarových projektů mohou nastat tyto případy: nedodrţení termínu, nefunkčnost systému a odmítnutí finálního produktu zadavatelem. Tyto případy se ještě mohou dále dělit na menší rizika, jejich shrnutí spolu s plánovaným odhadem dopadu na projekt jsem dal do následující tabulky. Tabulka 1 - Souhrn rizik a dopadů vyvíjeného projektu

Riziko

Kategorie rizika

Úroveň dopadu na projekt

Chyby v analýze

Procesní

18

Kritický

Odklon od poţadavků

Procesní

Významný

Špatný odhad časové náročnosti

Procesní

Významný

Nekompatibilita HW a SW

Technologická

Zanedbatelná

Nedostatečné nástroje

Technologická

Minimální

Nedostatečné testování

Implementační

Kritická

Chybné ovládání

Implementační

Kritická

Znalosti

Implementační

Kritická

Nefunkčnost HW

Bezpečnostní

Kritická

Nefunkčnost SW

Bezpečnostní

Kritická

Zdroj: autor

3.6.1 Rizika procesní Zde se nacházejí chyby, kterých jsme se dopustili během analýzy a přípravy projektu, chyby mohou být i kritické, protoţe můţe nastat odklon od původního zadání a celý projekt můţe tím být odmítnut. 3.6.1.1 Chyby v analýze Jedná se o kritické riziko, neboť při chybné analýze můţe dojít k odklonu projektu od zadání. Náprava této chyby můţe být velice pracná a v některých případech i nemoţná v rámci daného časového horizontu. Důsledek: Aplikace nefunguje správně. Prevence: Častá komunikace se zákazníkem, schvalování jednotlivých komponent Řešitel: Programátor 3.6.1.2 Odklon od poţadavků Aplikace funguje jiným způsobem neţ zákazník poţadoval nebo má funkce které zákazník nepoţadoval či naopak některé poţadované neobsahuje. Riziko vzniká z přílišné kreativity programátora a díky chybnému pochopení, Důsledek: Aplikace nefunguje správně Prevence: Častá komunikace se zákazníkem, sepsání podrobných poţadavků na začátku projektu a odsouhlasení klientem Řešitel: Programátor, klient

19

3.6.1.3 Špatný odhad časové náročnosti Špatný odhad časové náročnosti zde můţe být velice významný, protoţe se jedná o diplomovou práci, tak není moţné řešit zvýšeným počtem programátorů a v obecných případech můţe vést ke zvýšeným nákladům. Důsledek: Nedodrţení termínu, zvýšené náklady Prevence: Precizní časový odhad na jednotlivou fázi projektu, počítání s časovou rezervou na případné nepředpokládané problémy a překáţky Řešitel: Programátor

3.6.2 Rizika technologická Zde jsou rizika, která mohou vzniknout chybným pouţitím technologií nebo nástrojů. 3.6.2.1 Nekompatibilita HW a SW Vzhledem k tomu, ţe jsme vybrali většinu nástrojů multiplatformních a jejich rozšíření na všech platformách je značné, je toto riziko minimální, nicméně ve vývoji projektu můţe nastat Důsledek: Aplikace nefunguje Prevence: Zpracování projektu pomocí technologií plně rozšířených v daných prostředích a vyvarování se nových a nevyzkoušených technologií Řešitel: Programátor 3.6.2.2 Nedostatečné nástroje K tvorbě projektu potřebujeme vţdy vhodné nástroje, riziko je pouţití nových nástrojů nebo nástrojů, které jsou teprve v testovacím provozu. Můţe tím docházet k chybám, které nejsme schopni ovlivnit a tím ani odstranit a chyby mohou mít katastrofální dopad Důsledek: Aplikace vykazuje neopravitelné chyby Prevence: Vyuţívání nástrojů se kterými jiţ máme dostatečné zkušenosti a víme co od nich můţeme očekávat a zda jsou schopné daný poţadavek splnit Řešitel: Programátor

20

3.6.3 Rizika implementační Rizika která mohou vzniknout při samotné implementaci jsou značná a na celou aplikaci mohou mít katastrofální vliv. Hlavně z důvodu časté chybovosti u klienta. 3.6.3.1 Nedostatečné testování Tato chyba se projeví častou chybovostí nasazené aplikace u klienta. Můţe vést k vrácení celého projektu v lepším případě k přepracování. Odstraňování takovýchto chyb ve finální fázi je poměrně pracné a je snazší testovat jednotlivé komponenty před nasazením. V případě open-source programů je často finální testování ponecháno na klientech a na chyby (bugy) je zaloţena speciální databáze, která je postupně zpracovávána a chyby odstraňovány, coţ si ale z pohledu diplomové práce nemůţeme dovolit. Důsledek: Aplikace nefunguje správně Prevence: Pečlivé testování kaţdé jednotlivé komponenty, nasazení pokusných dat a testování extrémních hodnot Řešitel: Programátor 3.6.3.2 Chybné ovládání Chybné ovládání můţe být dvojího druhu a to přímo programové, kdy jednotlivé prvky neodvádí předpokládanou práci nebo syntaktické, kdy jejich vyuţití nedává v daném případě smysl a klient tak aplikaci nepochopí. Důsledek: Odmítnutí aplikace. Prevence: Testování aplikace před ostrým nasazením na nezávislé osobě, která nemá s řešením ţádné spojitosti a nejlépe vidí celý projekt poprvé v ţivotě. Řešitel: Programátor, tester 3.6.3.3 Znalosti Pro řešení dané problematiky jsou nezbytné velmi dobré znalosti poţitých technologií a nástrojů. Důsledek: Zpomalení vývoje, chyby v interpretaci Prevence: Studium technologií, pouţívání nástrojů Řešitel: Programátor

21

3.6.4 Rizika bezpečnostní Díky bezpečnostním rizikům můţe docházet ke ztrátě dat nebo úniku dat k neklientům nebo dokonce ke konkurenci a tím i moţnost přímého vlivu na další ţivotaschopnost firmy klienta. V našem případě můţe dojít ke ztrátě dat domácího účetnictví a tím k neznalosti výdajů a jejich překročení. Tím můţeme dostat rodinu do značných problémů. 3.6.4.1 Nefunkčnost HW Jestliţe dojde k poruše na hardware, můţe tím nastat nestandardní ukončení celé aplikace a tím vést ke ztrátě dat. Důsledek: Ztráta rozpracovaný dat, poškození jiţ uloţených dat Prevence: Pravidelné zálohování, volba vhodného HW Řešitel: Programátor, uţivatel 3.6.4.2 Nefunkčnost SW Jestliţe software nebude fungovat tak jak má, můţe dojít k přístupu k datům ze strany neautorizovaného uţivatele, který můţe data měnit nebo zničit Důsledek: Ztráta dat Prevence: Kvalitní testování vč. extrémních případů Řešitel: Programátor

22

Kapitola 4 4. Analýza řešení V této kapitole rozebereme komplexní řešení námi zadaného projektu. Provedeme analýzu případů pouţití a vytvoříme konceptuální model.

4.1 Seznam aktérů Systém umoţňuje detailní správu uţivatelských rolí. Vzhledem k této skutečnosti můţe být seznam aktérů libovolný se zachováním dvou předdefinovaných přístupů. Běţný uţivatel Umoţňuje zadávat účtenky, příchozí transakce, převody mezi jednotlivými účty, přidávat a editovat kategorie a sub-kategorie, zobrazovat analýzu dat, dělat měsíční uzávěrku a zobrazovat výpisy po jednotlivých kategoriích Administrátor Má stejná oprávnění jako „Běţný uţivatel“ a navíc můţe editovat uţivatele, prohlíţet a mazat log aplikace, má umoţněn přímý přístup do databáze přes SQL konzoly a můţe přidávat moduly do aplikace

4.2 Analýza případů pouţití Analýza případů pouţití vychází z poţadavků nastavených během analýzy projektu. Vzhledem k neustálému vývoji projektu a moţnosti rozšiřitelnosti pomocí modulů jsou zde uvedeny pouze základní operace, které lze v systému provést. Jeho moţnosti jsou vzhledem k rozšiřitelnosti téměř neomezené. K popisu příkazů jsem pouţil jazyk UML a pomocí Use Case diagramů, Diagramů aktivita a Use Case textů. Pro snazší představu jsou uvedeny GUI některých operací vytvořené pomocí Qt Designeru.

4.2.1 Přihlášení uţivatele Případ Přihlášení uţivatele slouţí k přihlášení uţivatele do systému. Aktéři: Systém, uţivatel

23

Obrázek 2 - Use Case: Přihlášení uţivatele

Zdroj: autor

Tabulka 2 - Use Case: Přihlášení uţivatele

Krok

Role

Akce

1

Systém

Zobrazí přihlašovací dialog

2

Uţivatel

Zadá přihlašovací údaje

3

Systém

Ověří platnost uţivatelského jména a hesla

3a

Systém

Uţivatel zadal neplatné udaje: 3a1:

Systém

zobrazí

informaci

o

neplatném

uţivatelském jméně nebo heslo a po potvrzení informace vrátí zpět na přihlašovací dialog Zdroj: autor

Obrázek 3 - Activity Diagram - Přihlášení uţovatele

Zdroj: autor

4.2.2 Odhlášení uţivatele Případ Odhlášení uţivatele slouţí k odhlášení uţivatele ze systému. Aktéři: Systém, uţivatel

24

Obrázek 4 - Use Case: Odhlášení uţivatele

Zdroj: autor

Tabulka 3 - Use Case: Odhlášení uţivatele

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Odhlásit“

2

Systém

Odhlásí uţivatele

3

Systém

Provede reset aplikace a zamezí přístup k funkcím Zdroj: autor

Obrázek 5 - Dialog Přihlášení do systému

Zdroj: autor

4.2.3 Změna hesla přihlášeného uţivatele Případ Změna hesla slouţí ke změně hesla přihlášeného uţivatele v systému. Aktéři: Systém, uţivatel

25

Tabulka 4 - Use Case: Změna hesla

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Změna hesla“

2

Systém

Zobrazí dialog pro změnu hesla

3

Uţivatel

Zadá své aktuální heslo a dvakrát heslo nové

4

Systém

Provede kontrolu shodnosti původního hesla a kontrolu identity obou zadání hesla novéh

4a

Systém

Uţivatel zadal neplatné údaje 4a1: Systém zobrazí informaci o neplatných údajích a po potvrzení se vrátí zpět na dialog pro změnu hesla Zdroj: autor

4.2.4 Správa uţivatelů Případ Správa uţivatelů slouţí uţivateli s přístupem Administrátora pro přidání, změnu a smazání jednotlivých uţivatelů. U uţivatele můţeme měnit heslo a výši přístupu. Aktéři: Systém, uţivatel Obrázek 6 - Use Case: Správa uţivatelů

Zdroj: autor

26

Tabulka 5 - Use Case: Správa uţivatelů

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Správa uţivatelů“

2

Systém

Zobrazí dialog pro správu uţivatelů

3

Systém

Provede příslušný poţadavek

3a

Systém

Sytém přijal poţadavek na přidání uţivatele: 3a1: Systém zahájí případ Přidání uţivatele (4.2.4.1)

3b

Systém

Systém přijal poţadavek na editaci uţivatele: 3b1: Systém zahájí případ Editace uţivatele (4.2.4.2)

3c

Systém

Systém přijal poţadavek na změnu hesla uţivatele: 3c1: systém zahájí případ Změna hesla (4.2.4.3)

3d

Systém

Systém přijal poţadavek na změnu oprávnění: 3d1: systém zahájí případ Změna oprávnění (4.2.4.4)

3e

Systém

Systém přijal poţadavek na smazání uţivatele: 3e1: systém zahájí případ Smazání uţivatele (4.2.4.5)

3f

Systém

Systém přijal poţadavek na zobrazení seznamu: 3f1: systém zahájí případ Zobrazení seznamu (4.2.4.6) Zdroj: autor

4.2.4.1 Přidání uţivatele Případ Přidání uţivatele slouţí k vytvoření nového uţivatele. Aktéři: Systém, uţivatel Tabulka 6 - Use Case: Přidání uţivatele

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Přidání uţivatele“

2

Systém

Zobrazí dialog pro přidání uţivatele

3

Uţivatel

Zadá poţadované informace o uţivateli

4

Systém

Systém ověří platnost údajů a vytvoří uţivatele

4a

Systém

Uţivatel zadal neplatné údaje: 4a1: Zobrazí informace neplatnosti údajů a vrátí se zpět na krok 2 Zdroj: autor

27

Obrázek 7 - Activity Diagram: Přidání uţivatele

Zdroj: autor

4.2.4.2 Editace uţivatele Případ Editace uţivatele slouţí k editaci stávajícího uţivatele. Aktéři: Systém, uţivatel Tabulka 7 - Use Case: Editace uţivatele

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Editace uţivatele“

2

Systém

Načte informace o zvoleném uţivateli

3

Systém

Zobrazí dialog pro editaci uţivatele s uloţenými údaji

4

Uţivatel

Změní poţadované informace

5

Systém

Systém ověří platnost údajů a změní uţivatele

5a

Systém


Obrázek 8 - Activity Diagram: Editace uţivatele

Zdroj: autor

28

4.2.4.3 Změna hesla Případ Změna hesla slouţí k úpravě hesla pro zvoleného uţivatele. Pro případ, kdy uţivatel zapomene heslo má administrátor moţnost mu nastavit nové. Aktéři: Systém, uţivatel Tabulka 8 - Use Case: Změna hesla

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Změna hesla“

2

Systém

Zobrazí dialog pro změnu hesla (pouze změna)

3

Uţivatel

Zadá 2x nové heslo

4

Systém

Systém ověří platnost údajů a změní heslo uţivatele

4a

Systém


Obrázek 9 - Activity Diagram: Změna hesla

Zdroj: autor

4.2.4.4 Změna oprávnění Případ Změna oprávnění slouţí k úpravě oprávnění přístupu daného uţivatele. Jestliţe si nepřejeme, aby některý uţivatel mě přístup do některých funkcí program, můţeme změnit jeho oprávnění a dané funkce se mu jiţ nebudou po přihlášení zobrazovat. Aktéři: Systém, uţivatel Tabulka 9 - Use Case: Změna oprávnění

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Změna oprávnění“

2

Systém

Zobrazí dialog pro změnu oprávnění

29

3

Uţivatel

Zadá výši nového oprávnění

4

Systém

Systém ověří platnost údajů a změní heslo uţivatele

4a

Systém


Obrázek 10 - Activity Diagram: Změna oprávnění

Zdroj: autor

4.2.4.5 Smazání uţivatele Případ Smazání uţivatele slouţí k vymazání uţivatele z databáze a zamezení mu v dalším přístupu k datům. Aktéři: Systém, uţivatel Tabulka 10 - Use Case: Smazání uţivatele

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Smazat uţivatele“

2

Systém

Zobrazí dialog „Smazání uţivatele“

3

Uţivatel

Vybere uţivatele určeného k likvidaci

4

Systém

Ověří moţnost smazání uţivatele a smaţe ho

4a

Systém

Systém nemůţe smazat uţivatele: 4a1: Systém informuje o neprovedení a vrátí se na krok 2 Zdroj: autor

30

Obrázek 11 - Activity Diagram: Smazání uţivatele

Zdroj: autor

4.2.4.6 Zobrazení seznamu Případ Zobrazení seznamu slouţí k zobrazení seznamu uţivatelů určených k editaci. Aktéři: Systém, uţivatel Tabulka 11 - Use Case: Zobrazení seznamu

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Zobrazení seznamu“

2

Systém

Načte a zobrazí dialog „Uţivatelé“ Zdroj: autor

Obrázek 12 - Návrh GUI - Seznam uţivatelů

Zdroj: autor

31

4.2.5 Příchozí transakce Případ Příchozí transakce slouţí k uloţení, editaci a smazání jakýchkoliv získaných peněz na některý z účtů. Můţe se jednat o hotovost nebo bankovní převod. Systém lze pouţít i pro připsání stravenek, jestliţe si na ně vedeme v systému vlastní účet. Aktéři: Systém, uţivatel Obrázek 13 - Use Case: Příchozí transakce

Zdroj: autor

Tabulka 12 - Use Case: Příchozí transakce

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Vloţení příchozí transakce“

2

Systém

Načte a zobrazí dialog „Příchozí transakce“

3

Uţivatel

Zadá poţadované detaily transakce

4

Systém

Vyhodnotí vkládané údaje a uloţí příchozí transakci

4a

Systém

Údaje nelze uloţit: 4a1: Informuje uţivatele a vrátí zpět na krok2

4b

Systém

Vkládaná transakce neexistuje: 4b1: Uloţí novou transakci pod novým ID

4c

Systém

Vkládaná transakce existuje:

32

4c1: Změní transakci podle zadaných parametrů Zdroj: autor

4.2.5.1 Uloţení transakce Případ Uloţení transakce slouţí k uloţení nové nebo editaci stávající transakce. Aktéři: Systém, uţivatel Tabulka 13 - Use Case: Uloţení transakce

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Uloţit“

2

Systém

Vyhodnotí zadané údaje

2a

Systém

Údaje nelze uloţit: 2a1: Informuje o formální chybě a vrátí uţivatele na začátek

2b

Systém

Data odpovídají: 2b1: Transakce je v systému – UPDATE 2b2: Transakce není v systému - INSERT Zdroj: autor

Obrázek 14 - Activity Diagram: Uloţení transakce

Zdroj: autor

4.2.5.2 Smazání transakce Případ Smazání transakce slouţí k vymazání chybně zadané nebo neadekvátní transakce. Aktéři: Systém, uţivatel

33

Tabulka 14 - Use Case: Smazání transakce

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Smazat“

2

Systém

Vyhodnotí a smaţe danou transakci

2a

Systém

Transakce nelze smazat: 2a1: Informuje uţivatele Zdroj: autor

Obrázek 15 - Návrh GUI: Příchozí transakce

Zdroj: autor

34

4.2.6 Převod Případ Převod slouţí k uloţení, editaci a smazání jakýchkoliv převodů mezi jednotlivými účty vedenými v systému. Převod peněz je například výběr z bankomatu, kdy se jedná o převod peněz z účtu bankovního na účet Peneţenka. Use Case a Aktivity Diagram je zde velice podobné jako u příchozí transakce a není zde ţádná specialita, proto zde nebudu opakovat stejné bloky tabulek a diagramů. Aktéři: Systém, uţivatel Obrázek 16 - Návrh GUI: Převod

Zdroj: autor

4.2.7 Odchozí transakce Případ Odchozí transakce slouţí k uloţení, editaci a smazání jakýchkoliv vydaných peněz. Use Case a Aktivity Diagram je zde velice podobné jako u příchozí transakce a není zde ţádná specialita, proto zde nebudu opakovat stejné bloky tabulek a diagramů, ale zaměřím se na jednu specialitu a to přidání kategorie a sub-kategorie nazvané skupina. 35

Aktéři: Systém, uţivatel Obrázek 17 - Návrh GUI: Odchozí transakce

Zdroj: autor

4.2.7.1 Přidání kategorie Případ Přidání kategorie slouţí k přidání, editaci nebo smazání kategorie. Aktéři: Systém, uţivatel Obrázek 18 - Use Case: Přidání kategorie

Zdroj: autor

36

Tabulka 15 - Use Case: Přidání kategorie

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Uloţit“

2

Systém

Vyhodnotí zadané údaje

2a

Systém

Údaje nelze uloţit: 2a1: Informuje o formální chybě a vrátí uţivatele na začátek

2b

Systém

Data odpovídají: 2b1: Kategorie je v systému – UPDATE 2b2: Kategorie není v systému - INSERT Zdroj: autor

Obrázek 19 - Activity Diagram: Přidání kategorie

Zdroj: autor

Obrázek 20 - Návrh GUI: Přidání kategorie

Zdroj: autor

37

4.2.7.2 Smazání kategorie Případ Smazání kategorie slouţí ke smazání kategorie. Aktéři: Systém, uţivatel Tabulka 16 - Use Case: Smazání kategorie

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Smazat“

2

Systém

Systém vyhodnotí a smaţe danou kategorii

2a

Systém

Údaje nelze uloţit: 2a1: Informuje o formální chybě a vrátí uţivatele na začátek Zdroj: autor

4.2.8 Budget Případ Budget slouţí k vytvoření a editaci plánovaných výdajů na měsíc. Tento dialog se automaticky spouští po uzavření měsíce, lze však kdykoliv vyvolat z menu pro doplnění informací nebo opravu plánovaných výdajů. Aktéři: Systém, uţivatel Obrázek 21 - Use Case: Budget

Zdroj: autor

Tabulka 17 - Use Case: Budget

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Budget“

2

Systém

Otevře dialog „Budget“ 38

3

Uţivatel

Zadá plánované výdaje na zvolený měsíc

4

Systém

Systém vyhodnotí zadané údaje a uloţí je

4a

Systém

Údaje není moţné uloţit: 4a1: Informuje uţivatele a vyzve ho k nápravě, vrátí na krok 2 Zdroj: autor

Obrázek 22 - Activity Diagram: Budget

Zdroj: autor

Obrázek 23 - Návrh GUI: Budget

Zdroj: autor

4.2.9 Výpis Případ Výpis slouţí k zobrazení uskutečněných operací na účtech nebo podle transakcí. Lze tak zobrazit kolik má výdaje daný účet v dané kategorii nebo celkově. 39

Aktéři: Systém, uţivatel Obrázek 24 - Use Case: Výpis

Zdroj: autor

Tabulka 18 - Use Case: Výpis

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Výpis“

2

Systém

Otevře dialog „Výpis“

3

Uţivatel

Vybere kriterium pro zobrazení

4

Systém

Systém vyhodnotí volbu uţivatele

4a

Systém

Uţivatel vybral výpis dle kategorie 4a1:Systém zpracuje výpis dle kategorie (4.2.8.1)

4b

Systém

Uţivatel vybral výpis dle účtu 4b1: Systém zpracuje výpis dle účtu (4.2.8.2) Zdroj: autor

4.2.9.1 Výpis dle kategorie Případ Výpis dle kategorie slouţí k zobrazení uskutečněných operací v daném měsíci dle kategorií. Aktéři: Systém, uţivatel Tabulka 19 - Use Case: Výběr dle kategorie

Krok

Role

Akce

40

1

Uţivatel

Uţivatel vybere moţnost „Výpis dle kategorie“

2

Systém

Otevře dialog „Výběr kategorie“

3

Uţivatel


4

Systém

Systém vyhodnotí volbu a zobrazí všechny odchozí transakce v daném měsíci pro danou kategorii Zdroj: autor

4.2.9.2 Výpis dle účtu Případ Výpis dle účtu slouţí k zobrazení uskutečněných operací v daném měsíci dle účtu. Aktéři: Systém, uţivatel Tabulka 20 - Use Case: Výpis dle účtu

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Výpis dle účtu“

2

Systém

Otevře dialog „Výběr účtu“

3

Uţivatel


4

Systém

Systém vyhodnotí volbu a zobrazí všechny transakce v daném měsíci pro danou účet (příchozí, odchozí a převody) Zdroj: autor

41

Obrázek 25 - Návrh GUI: Výpisy

Zdroj: autor

4.2.10 Graf Případ Graf slouţí k zobrazení uskutečněných operací v daném měsíci v grafické podobě včetně plánované míry výdajů. Aktéři: Systém, uţivatel Obrázek 26 - Use Case: Graf

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Graf“

2

Systém

Otevře dialog „Graf“

3

Uţivatel

Vybere měsíc a kategorii pro zobrazení

4

Systém

Systém vyhodnotí volbu a zobrazí všechny odchozí transakce v daném měsíci pro danou kategorii jako graf Zdroj: autor

42

Obrázek 27 - Návrh GUI: Graf

Zdroj: autor

4.2.11 Inventura Případ Inventura slouţí k zadání aktuálního reálného zůstatku na účtech. Aktéři: Systém, uţivatel Obrázek 28 - Use Case: Inventura

Krok

Role

Akce

1

Uţivatel

Uţivatel vybere moţnost „Inventura“

2

Systém

Otevře dialog „Inventura“

3

Uţivatel

Zadá aktuální stav jednotlivých účtů

4

Systém

Systém zkontroluje data a uloţí je

4a

Systém

Data neodpovídají zadání: 4a1: Informuje uţivatele a vrátí se na krok 2 Zdroj: autor

43

Obrázek 29 - Návrh GUI: Inventura

Zdroj: autor

4.3 Konceptuální model Konceptuální datový model vychází z odborného článku. Jde o model doménových objektů v rámci aplikace, který bude základem pro tvorbu fyzického datového úloţiště. V systému jsou základem transakce. Transakce odchozí, příchozí a převody. Kaţdá transakce je provedena na vrub nebo ve prospěch minimálně jednoho účtu. Transakce odchozí jsou děleny do kategorií a kaţdá kategorie má svou skupinu. Kaţdá transakce spadá právě do jednoho Měsíce a kaţdý Měsíc má práce jeden Budget a jednu Inventuru.

44

Obrázek 30 - Konceptuální model

Zdroj: autor

Budget Třída obsahující všechny plánované výdaje pro jednotlivé kategorie. Měsíce Třída obsahující informace o účetních měsících, jejich začátku a konci. Inventura Třída obsahující reálný stav účtů ke konci měsíce, pro potřeby zjištění diference. Příchozí transakce Třída obsahuje všechny příchozí transakce. Kaţdá transakce obsahuje popis, ve prospěch kterého účtu je vedena, datum kdy dorazila, částku transakce a je volitelně doplněna poznámkou Odchozí transakce Třída obsahuje všechny odchozí transakce. Kaţdá transakce obsahuje popis, na vrub kterého účtu je vedena, datum kdy dorazila, částku transakce, a skupinu do které transakce spadá a je volitelně doplněna poznámkou Převod Třída obsahuje všechny převody mezi dvěma účty. Kaţdá transakce obsahuje důvod převodu, oba účty, datum provedení a částku převodu Účty Třída obsahuje všechny účty zaloţené v systému. Kaţdý účet obsahuje popis slouţící pro snazší rozpoznání při zadávání Kategorie 45

Třída obsahuje všechny kategorie v systému. Kategori jsou pouţity pro plánování výdajů a pro ukládání ochozích transakcí Skupiny Třída obsahuje všechny skupiny, které jsou v systému. Kaţdá kategorie má pod sebou minimálně jednu skupinu. Pomáhá nám pro bliţší rozklíčování výdajů. Plánované výdaje jsou na kategorie a skupina nám pomáhá při detailní analýze našich výdajů.

46

Kapitola 5 5. Návrh a implementace Vzhledem k jednoduchosti fyzického datového modelu není potřeby vytvářet ER model, nebo závislosti jsou patrné jiţ z konceptuálního modelu a tvorba ER diagramu by byla v tomto případě zbytečná.

5.1 Fyzický datový model Fyzický datový model vychází z konceptuální datového modelu z předchozí kapitoly a definuje přímo databázové tabulky.

5.2 Databázové tabulky Tabulka uzivatele je určena k ukládání jednotlivých uţivatelů. Uţivatel má svou úrove přístupu, podle níţ se mu po spuštění programu vygeneruje menu a toolbar dle oprávnění přístupu. Tabulka 21 - Databázové tabulky: Uzivatele

Key Název PK

ID Username

Typ

Porovnávání

tinyint(4) varchar(20)

collate utf8_czech_ci

Null NOT

auto_incre

NULL

ment

NOT NULL

Jmeno

varchar(40)


NOT NULL

Heslo

varchar(255)


NOT NULL

Uroven

tinyint(4)

NOT

default '0'

NULL Zdroj: autor

Tabulka ucty obsahuje veškeré účty které jsou zadané v systému. Tabulka obsahuje pouze primární klíč ID a textový popis daného účtu pro lepší rozpoznávání uţivatelů během zadávání. 47

Tabulka 22 - Databázové tabulky: Ucty

Key Název

Typ

PK

int(4)

ID Cislo_uctu

varchar(30)

Porovnávání


Null NOT

auto_incre

NULL

ment

NOT NULL

Zdroj: autor

Tabulka kategorie obsahuje veškeré kategorie, které jsou v systému. Tabulka obsahuje pouze primární klíč ID a textový popis daného kategorie pro lepší rozpoznávání uţivatelů během zadávání. Kaţdá kategorie má několik skupin, ale kaţdá skupina má pouze jednu kategorii. Tabulka 23 - Databázové tabulky: Kategorie

Key Název

Typ

PK

int(4)

ID Nazev

varchar(30)

Porovnávání


Null NOT

auto_incre

NULL

ment

NOT NULL

Zdroj: autor

Tabulka skupiny obsahuje veškeré skupiny, které jsou v systému. Tabulka obsahuje pouze primární klíč ID a textový popis daného kategorie pro lepší rozpoznávání uţivatelů během zadávání, další je Kaţdá kategorie má několik skupin, ale kaţdá skupina má pouze jednu kategorii. Tabulka 24 - Databázové tabulky: Skupiny

Key Název

Typ

PK

int(4)

ID Nazev

varchar(30)

Porovnávání


Null NOT

auto_incre

NULL

ment

NOT NULL

FK

Kategorie

int(4)

NOT 48

NULL Zdroj: autor

Tabulka mesice je určena k uloţení informací o účetních měsících. Účetní měsíc pro většinu rodin začíná příjmem výplaty (například 9-tý den v měsíci). Kaţdý záznam obsahuje primární klíč ID, poloţku Nazev, která obsahuje slovní popis měsíce (například Leden pro měsíc od 9.1.-9.2.) a dva typy date pro OD a DO. Tabulka zároveň obsahuje informaci o aktuálně otevřeném měsíci a to tak, ţe jeho poloţka DO je nastavena na ‘0000-00-00’ Tabulka 25 - Databázové tabulky: Mesice

Key Název

Typ

PK

int(4)

ID Nazev

varchar(30)

Porovnávání


Null NOT

auto_incre

NULL

ment

NOT NULL

OD

date

NOT

Default

NULL

„0000-0000“

DO

date

NOT

Default

NULL

„0000-0000“

Zdroj: autor

Tabulka budget je určena k uloţení informací o plánovaných výdajích na jednotlivé měsíce a po jednotlivých kategoriích. Primární klíč je ID a tabulka obsahuje ještě dva cizí klíče odkazující na tabulku mesice a tabulku kategorie. Dále pak tabulka obsahuje částku, která je na daný měsíc plánována na útratu. Tabulka 26 - Databázové tabulky: Budget

Key Název

Typ

PK

int(4)

FK

ID Kategorie

Porovnávání

int(4)

Null NOT

auto_incre

NULL

ment

NOT 49

NULL FK

Mesic

int(4)

NOT NULL

Castka

float

NOT NULL Zdroj: autor

Tabulka inventura ukládá reálné výsledky hospodaření za jednotlivé účetní měsíce. Tabulka nám pomáhá sledovat pro statistické účely jak důsledně zadáváme účty do systému. Pomocí tabulky se také udrţuje konzistence dat, protoţe aktuální stav účtů se vţdy zobrazuje jako součet všech transakcí od data poslední inventury. Tabulka má jeden primární klíč ID a dva cizí klíče odkazující na tabulky mesic a ucet. Dále pak float hodnotu reálu na našem účtu. Tabulka 27 - Databázové tabulky: Inventura

Key Název

Typ

PK

int(4)

FK

ID Ucet

Porovnávání

int(4)

Null NOT

auto_incre

NULL

ment

NOT NULL

FK

Mesic

int(4)

NOT NULL

Hodnota_r

float

NOT

eal

NULL Zdroj: autor

Tabulka prichozi obsahuje všechny příchozí transakce. Kaţdá transakce má svůj primární klíč označený ID a cizí klíč Kam odkazující na tabulku ucty. Pak má poloţku Cas typu date, která nese informaci kdy byla poloţka zúčtována. Samozřejmostí je poloţka Kolik, obsahující informaci o částce, poloţka Odkud, která není cizím klíčem a umoţňuje nám zadat jakýkoliv zdroj příjmů bez nutnosti měnit databázy. Poloţka Poznamka je pro upřesnění platby (pro případ více příchozích plateb v měsíci od jednoho zdroje je dobré u kaţdé vést důvod).

50

Tabulka 28 - Databázové tabulky: Prichozi

Key Název

Typ

PK

int(4)

ID Cas

Porovnávání

date

Null NOT

auto_incre

NULL

ment

NOT

Default

NULL

„0000-0000“

FK

Kam

int(4)

NOT NULL

Odkud

varchar(30)


NOT NULL

Kolik Poznamka

float(7,2) text

NOT

Default

NULL

„00.00“


Tabulka odchozi obsahuje všechny odchozí transakce. Kaţdá transakce má svůj primární klíč označený ID a cizí klíč Odkud odkazující na tabulku ucty. Pak má poloţku Cas typu date, která nese informaci kdy byla poloţka zúčtována. Samozřejmostí je poloţka Kolik, obsahující informaci o částce, poloţka Co, která není cizím klíčem a umoţňuje nám zadat jakýkoliv důvod výdaje, například jméno obchodníka nebo produktu. Poloţka Poznamka je pro upřesnění platby (pro případ více příchozích plateb v měsíci od jednoho zdroje je dobré u kaţdé vést důvod). Dalším cizím klíčem této tabulky je poloţka Skupina odkazující na tabulku skupina. Díky tomu, ţe kaţdá skupina má pouze jednu kategorii nemusíme v tabulce drţet informaci i o kategorii, neboť propojením tabulek tuto informaci snadno získáme. Tabulka 29 - Databázové tabulky: Odchozi

Key Název

Typ

PK

int(4)

ID Cas

Porovnávání

date

51

Null NOT

auto_incre

NULL

ment

NOT

Default

NULL

„0000-00-

00“ FK

Odkud

int(4)

NOT NULL

Co

varchar(30)


NOT NULL

Kolik Skupina

float(7,2) int(4)

NOT

Default

NULL

„00.00“

NOT NULL

Poznamka

text


Tabulka prevody obsahuje všechny převodové transakce mezi účty. Kaţdá transakce má svůj primární klíč označený ID a dva cizí klíče Odkud a Kam odkazující na tabulku ucty. Pak má poloţku Datum typu date, která nese informaci kdy byla poloţka zúčtována. Samozřejmostí je poloţka Kolik, obsahující informaci o částce. Tabulka 30 - Databázové tabulky: Prevody

Key Název

Typ

PK

int(4)

FK

ID Odkud

Porovnávání

int(4)

Null NOT

auto_incre

NULL

ment

NOT NULL

FK

Kam

int(4)

NOT NULL

Kolik Datum

float(7,2) date

NOT

Default

NULL

„00.00“

NOT

Default

NULL

„0000-0000“

Zdroj: autor

52

To byli tabulky týkající se přímo statistické práce s účetnictvím, nyní budou následovat dvě tabulky nezbytné pro správný běh program. První tabulka obsahuje informace nezbytné pro generování menu a druhá je pro panel nástrojů. Tabulka menu obsahuje všechny poloţky které se po přihlášení natáhnout do paměti a vytvoří se na jejich základě kompletní menu. Kaţdá poloţka menu má svůj unikátní klíč, je moţnost přiřadit zkratku a kaţdá poloţka je označena výší přístupu. Máme tak jistotu, ţe uţivatel s přístupem 1 se nedostane k poloţkám 0 ale pouze >=1. Získáme tím unikátní moţnost, ţe kaţdý uţivatel s vyšším přístupem automaticky získává přístup nejen do svých „speciálních“ funkcí, ale i do všech funkcí, které jeho úrovni předcházejí. Abychom zajistili přístup do menu i pro nepřihlášeného uţivatele má i ten svůj kód, který je nejvyšším v tabulce. Ten umoţňuje přístup pouze do menu na přihlášení do systému a ukončení celého programu. Tabulka obsahuje prvek Pristup, který určuje propojení v menu. Je tím moţnost vytvářet i větvené nabídky a podnabídky. Tabulka 31 - Databázové tabulky: Menu

Key Název

Typ

PK

int(4)

ID Nazev

varchar(30)

Porovnávání

utf8_czech_ci

Null NOT

auto_incre

NULL

ment

NOT NULL

Zkratka

varchar(30)

utf8_czech_ci

NOT NULL

Propojeni

int(4)

NOT

Default „0“

NULL Pristup

tinyint(4)

NOT

Default „0“

NULL Action

varchar(30)

utf8_czech_ci

NOT NULL

Zdroj: autor

Tabulka toolbar obsahuje všechny poloţky které se po přihlášení natáhnout do paměti a vytvoří se na jejich základě lišta s ikonami odkazující na nejčastěji pouţívané poloţky menu. Stejně jako u menu i zde má kaţdá poloţka svůj unikátní klíč, je moţnost jí 53

přiřadit popisek, který se zobrazí po krátkém podrţení kurzoru myši nad ikonou a kaţdá poloţka je označena výší přístupu. Máme tak jistotu, ţe uţivatel s přístupem 1 se nedostane k poloţkám 0 ale pouze >=1. Tím máme opět jistotu, ţe kaţdý uţivatel s vyšším přístupem automaticky získává přístup nejen do svých „speciálních“ funkcí, ale i do všech funkcí, které jeho úrovni předcházejí. I zde je pro nepřihlášeného uţivatele jedna ikona a to ikona ukončení programu. Další specialitou je i poloţka TB odkazující na název nástrojové lišty (toolbaru). Díky ní můţeme sdruţovat ikony podobného zájmu do skupin. Tabulka 32 - Databázové tabulky: Toolbar

Key Název

Typ

PK

int(4)

ID Popisek

varchar(30)

Porovnávání

utf8_czech_ci

Null NOT

auto_incre

NULL

ment

NOT NULL

Ikona

varchar(120)

utf8_czech_ci

NOT NULL

TB Akce

varchar(20) varchar(30)

utf8_czech_ci utf8_czech_ci

NOT

Default

NULL

„Toolbar“

NOT NULL

Pristup

tinyint(4)

NOT

Default „0“

NULL Zdroj: autor

5.2 Popis komponent Jak jiţ bylo napsáno úvodní studii, tak pro generování grafů není pouţit vlastní program, ale je vyuţita komponenta PyGoogleChart. Jádro samotného programu je tedy napsáno v jazyce Python, ale tento modul je volán externě jako on-line modul. Další moţností rozšíření tohoto jádra je moţnost napsání vlastních modulů. Zde je velká výhoda poměrně malý rozměr kódu a dobrá dokumentace tabulek, tím lze snadno komunikovat přes toto rozhraní a vytvářet vlastní moduly snadno a rychle.

54

5.2.1 PyGoogleChart Tento modul obsahuje několik tříd zajištující tvorbu různých druhů grafů. Celý modul je importován do našeho programu, takţe můţeme vyuţívat všechny moţnosti tohoto modulu. Těchto tříd je několik a jejich podrobnější popis uvádím v následujícím seznamu. Jejich vyuţití najdeme při psaní vlastního modulu pro tento systém. SimpleLineChart Třída umoţňující namalování jednoduchého grafu PieChart3D a PieChart Třída umoţňující malování koláčových 2D a 3D grafů QRChart Třída pro tvorbu čárových kódů Jednotlivé třídy voláme vţdy s parametrem rozměrů poţadovaného výstupu a dala zadáváme pomocí pole, viz následující příklad. # Vytvoří koláčový graf o rozměrech 250x100 bodů chart = PieChart3D(250, 100) # Přidáme data, rozdělíme v poměru 2:1 chart.add_data([20, 10]) # Popíšeme jednotlivé části grafu chart.set_pie_labels(['první', 'druhý']) # A nyní máme připravený obrázek, který si můžeme stáhnout a zpracovat chart.download('pie-hello-world.png')

5.2.2 Tvorba vlastního modulu Díky tomu, ţe menu se generuje dynamicky a kaţdá poloţka má u sebe i akci kterou volá, je moţné zakomponovat i volání na externí program. To znamená, ţe jádro našeho programu se připojí k databázi a autorizuje přístup. Nyní můţeme pomocí utility SQL_dotaz posílat SQL poţadavky na MySQL server. V rámci bezpečnosti tato utilita veškeré dotazování loguje do souboru a je moţné ji nastavit tak, aby výrazy před spuštěním kontrolovala dotazy a případná rizika dopředu eliminovala. Rozhraní je zatím pouze základní a předpokládá dobrou znalost kódu, ale v budoucnosti můţe být připraven manuál na psaní modulů, kde budou všechny utility detailně popsány a navrţeno jejich vyuţití. 55

V současné době je toto rozhraní připraveno pro další vývoj a ţádný aktuální prvek není napsán jako rozšiřující modul.

5.3 GUI Pro grafické prostředí je vyuţitá knihovna Qt. Vyuţita je verze 4.2.3. Všechna dialogová okna jsou vytvořena pomocí Qt Designeru. Pouze hlavní okno se generuje dynamicky. Knihovna Qt je šířena pod licencí GNU GPL 3.0 pro open-source vyuţití. V případě komerčního vyuţití je zpoplatněna. Ale díky tomu, ţe tento projekt bude téţ šířen pod licencí GNU GPL budou podmínky dané licence splněny. Obrázek 31 - Návrh GUI: Hlavní okno

Zdroj: autor

56

Kapitola 6 6. Testování Testování je důleţitým krokem ve fázi ţivota programu. Dovolím si říci, ţe čím více testovacích procedur provedeme před vypuštěním projektu mezi koncové uţivatele, tím méně servisních zásahů u uţivatele. Stejně jako samotný vývoj projektu, je i testování rozděleno do několika částí.

6.1 Testování kódu Samotné testování kódu by mělo probíhat jiţ během vývoje samotných komponent, protoţe díky němu získáváme výsledná data. Testování by mělo probíhat pomocí zadávání co největšího mnoţství dat i extrémních hodnot a porovnávání výsledků získaných naší komponentou s předpokládanými výsledky. Pro získání vstupních dat se pouţívají nejčastěji dvě metody. „White-box“ a „black-box“ testy.

6.1.1 White-box testy Jak jiţ ze samotného názvu vyplívá (někdy se také označuje jako clear-box), tak během testování „máme otevřené oči“. Tím je míněno, ţe vidíme kód a známe přesně jeho funkce a vím co se odehrává. Je proto nejlepší, kdyţ toto testování udělají samotní programátoři. Ani zde to nebylo výjimkou a všechno testování v této fázi jsem udělal sám. Většinu testování komponent jsem prováděl uţ během psaní programu a výsledky jsem ihned zakomponoval do programu.

6.1.2 Black-box testy Black-box testování je zase opakem. Testy probíhají bez znalosti vnitřních procesů a proto musí uţivatel znát obecné funkce očekávané od systému a porovnávat výsledky s předpokládaným výsledkem. Zde je doporučeno, aby test prováděl někdo nezávislý. Pro náš případ jsem vyuţil sluţeb své manţelky, která se jiţ delší dobu stará o naše společné rodinné finance a dobře se proto orientuje v problematice.

57

Z tohoto testování vzešla řada doporučení a poţadavků, hlavně na optimalizaci procesů, zjednodušení procedur a ergonomii grafických rozhraní.

6.2 Testování databáze Testování databáze nebylo příliš obtíţné, protoţe vyuţití sluţeb MySQL je poměrně silnou zárukou kvality a hlavní část testování se týkala samotných tabulek, primárních klíčů a propojení jednotlivých tabulek. Testování jsem prováděl řadou dotazů pomocí jazyka SQL a aplikace phpMyAdmin, která velice dobře zobrazovala výsledky a případné chyby se snadno opravovali.

6.3 Testování GUI Protoţe jsem zvolil pro náš projekt knihovnu Qt ve verzi 4.2 (aktuální verze je 4.5) je jiţ většina chyb odstraněna, takţe hlavní testování probíhalo v opakovaném načítání a restartování jednotlivých dialogů. Velmi jsem byl potěšen rychlostí práce knihovny během resetování některých prvků. V minulosti jsem často pracoval s GUI pro VBA13 a zde mi nevyhovovalo, ţe funkce clear() pro ComboBoxy a ListBoxy byla vidět na obrazovce a aplikace na ně musela čekat.

6.4 Test pouţitelnosti Jeden z nejdůleţitějších testů je test pouţitelnosti. Často kdyţ projekt vzniká v laboratorních podmínkách, tak sice splňuje všechny podmínky a parametry na něj kladené, ale zapomíná se na skupinu uţivatelů, kteří produkt budou ve finále reálně vyuţívat. V našem případě bude cílová skupina většinou ţeny (podle statistik převládají ţeny ve vedení domácího účetnictví). Během testování programu na této skupině obyvatel vzniklo hodně podnětů na obměnu barev, pozadí a tlačítek pro lepší přizpůsobivost očím. Většina těchto podnětů byla okamţitě zapracována do programu a GUI bylo dotvořeno dle poţadavků. 13

VBA = Visual Basic for Aplication = programovací jazyk převáţně pouţíván pro psaní maker do produktů řady Microsoft

Office

58

Kapitola 7 7. Závěr 7.1 Zhodnocení Cílem práce bylo vytvořit systém domácího účetnictví pro OS Linux. Mohu prohlásit, ţe cíle diplomové práce byli bezezbytku splněny. Začal jsem analýzou aktuální situace na trhu. Zde jsem zjistil, ţe většina aktuálních projektů se zaměřuje na komerční vyuţití a tudíţ i podnikatelskou klientelu menších a středních firem. Na poli domácího účetnictví je situace spíše ţalostná a některé systémy tuto moţnost nabízejí jako okrajovou. Proto jsem dospěl k závěru ţe nejvhodnějším řešením bude vytvoření vlastního produktu, který bude přesně odpovídat poţadavkům. Primárním poţadavkem byla jednoduchost, kterou jsem splnil bezezbytku. Výsledný program obsahuje pouze základní funkce pro jednoduchou evidenci a snadné vyhodnocování domácích výdajů. Pro získání potřebných informací bylo nejprve nutné problematiku důkladně analyzovat. V této fázi přípravy jsem spolupracoval se svým okolím, kde většina domácností jiţ nějakým způsobem domácí účty vedou a snaţí se výdaje si plánovat. Kaţdý měl nějaké nápady a nějaké finty, které jsou pro účetnictví potřebné. Výsledkem byla velmi obsáhlá analýza, jejíţ část je i součástí této diplomové práce. Po provedení analýzy jsem přistoupil k samotné implementaci, kterou předcházelo intenzivní studium technologií. Důleţitou a nedílnou součástí bylo i vytvoření instalační příručky pro snazší rozšiřitelnost produktu. Projekt má také zaloţený web na http://www.sourceforge.net a je zde pod ID 259485. Zatím jsou zde umístěny jen obrázky z aplikace, kód zde bude aţ po obhájení práce, aby byl splněna podmínka, vypracování diplomové práce pouze mou osobou. Největším přínosem práce bylo seznámení se s nástroji pro tvorbu a detailní rozbor všech technologií umoţňující vývoj takovéhoto projektu. Musím říct, ţe osobně jsem rád, ţe jsem si vyzkoušel projektové plánování v praxi, protoţe teorie je velice daleko od praxe a mnoho věcí, které jsem si myslel, ţe nikdy nevyuţiji se mi v praktickém ţivotě projevila jako nezbytná a pomohla mi uspořit mnoho času a práce. Jiţ delší dobu jsem vyuţíval jazyk Python jako skriptovací jazyk, ale ţádný větší 59

projekt jsem si netroufal zahájit. Jsem rád, ţe jsem jeho vyuţití zvládl, protoţe jak jsem jiţ psal v úvodu, tento jazyk má velice jednoduchou syntaxi, ale velice obsáhlou dokumentaci. I po dokončení tohoto projektu, nebo respektive po dokončení jeho jádra, nemohu říci, ţe bych obsáhl všechny aspekty jazyka a je zde prostor k dalšímu studiu an který se uţ těším.

7.2 Budoucnost projektu Systém je v současnosti postaven jako jádro pro další rozvoj. Kaţdá rodina má svoje vlastní poţadavky a díky snadné rozšiřitelnosti pomocí modulů bude moţné tyto poţadavky přidat a snadno spravovat. V současné verzi nelze napojit systém přímo na výpisy zasílané bankou (většina dnešních bank uţ umoţňuje zasílání výpisů elektronickou cestou) a také by zde byla moţnost psát moduly přímo v programu jako jistý druh maker. Tyto moţnosti jsou však jiţ věcí budoucnosti a prostorem pro další rozvoj. Vzhledem k tomu, ţe systém je jiţ nasazen pro naši domácnost vznikne jeho dalším pouţíváním řada podnětů které nevyplynuli během testování.

60

Systém domácího účetnictví pro OS Linux

Recommend Documents