Systém pro správu bankovních účtů. Dominik Mervart

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Systém pro správu bankovních účtů Dominik Mervart

Vedoucí práce: Ing. Jiří Chludil

Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 8. června 2009

iv

v

Poděkování Děkuji panu Ing. Jiřímu Chludilovi za vedení mé bakalářské práce. Dále bych chtěl poděkovat své rodině a přítelkyni Lídě za podporu a trpělivost. Děkuji také panu Lukovi Skywalkerovi za inspiraci a morální podporu.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 8. 6. 2009

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

viii

Abstract This bachelor thesis deals with analysis, design and implementation of the system for bank account management. This system provides effective management of statements and transactions, their import, export, filtering and searching. The objective of this thesis is to remove some of the shortcomings of internet banking systems in the field of passive account operations. Considering the data sensitivity, the security measures are taken into account in the design and implementation phases. In the first part of the thesis is an introduction to the history and principles of electronic banking. The second part describes features and requirements laid on the system. The third part deals with analysis and design of the system. The fourth part attends to its implementation and testing.

Abstrakt Tato bakalářská práce se zabývá analýzou, návrhem a implementací systému pro správu bankovních účtů. Tento systém umožňuje efektivní správu výpisů a transakcí, jejich import, export, filtrování a prohledávání. Cílem této práce je odstranit některé nedostatky internetových bankovnictví v oblasti pasivních operací s účtem. Při návrhu a implementaci je vzhledem k citlivosti těchto dat dbáno na zabezpečení aplikace. V první části je uvedena historie a principy elektronického bankovnictví. Druhá část popisuje vlastnosti a požadavky kladené na systém. Třetí část se zabývá analýzou a návrhem systému. Čtvrtá část se věnuje jeho implementaci a testování.

ix

x

Obsah 1 Úvod

1

2 Popis problému, cíle a požadavky 2.1 Elektronické bankovnictví . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Bankovní operace . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Historie e-bankingu . . . . . . . . . . . . . . . . . . . . . . . 2.2 Formy elektronického bankovnictví . . . . . . . . . . . . . . . . . . . 2.2.1 Platební karty . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Telefonní bankovnictví (telebanking, phone banking) . . . . . 2.2.3 Home banking . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Internetové bankovnictví (internet banking) . . . . . . . . . . 2.3 České banky a jejich elektronické služby . . . . . . . . . . . . . . . . 2.3.1 Souhrn údajů o 9 největších českých bankách za rok 2007 . . 2.3.2 Žebříček českých bank podle velikosti . . . . . . . . . . . . . 2.4 Popis systému a cíle bakalářské práce . . . . . . . . . . . . . . . . . 2.4.1 Co bude aplikace umožňovat . . . . . . . . . . . . . . . . . . 2.4.2 Výhody oproti online systémům internetového bankovnictví . 2.4.3 Nevýhody oproti online systémům internetového bankovnictví 2.4.4 Požadavky na systém . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Cíl bakalářské práce . . . . . . . . . . . . . . . . . . . . . . . 2.5 Struktura bakalářské práce . . . . . . . . . . . . . . . . . . . . . . . 2.6 Existující implementace obdobného systému . . . . . . . . . . . . . . 2.6.1 Aconto Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 DSMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 POHODA 2009 START . . . . . . . . . . . . . . . . . . . . . 2.6.4 Další programy . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.5 Zhodnocení existujících aplikací obdobného typu . . . . . . . 3 Analýza a návrh řešení 3.1 Formáty bankovních výpisů . . . . . . . . . . . . . . . . . . . 3.1.1 Česká Spořitelna . . . . . . . . . . . . . . . . . . . . . 3.1.2 Komerční banka . . . . . . . . . . . . . . . . . . . . . 3.1.3 Československá obchodní banka . . . . . . . . . . . . . 3.1.4 mBank . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 Důležitá informační pole společná pro všechny banky .

xi

. . . . . .

. . . . . .

. . . . . .

. . . . . .

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

. . . . . .

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

. . . . . .

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

. . . . . .

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

. . . . . .

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

3 3 4 4 5 5 5 7 7 8 8 8 11 11 11 12 12 12 13 13 14 15 16 18 18

. . . . . .

19 19 20 21 21 21 22

xii

OBSAH

3.2

3.3

3.4

3.5

Automatické stahování výpisů . . . . . . . . . . . . . . . . . . . . . 3.2.1 Programové ovládání prvků webové stránky . . . . . . . . . 3.2.2 Bezpečnostní riziko . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Výsledek rešerše o automatickém stahování výpisů . . . . . Výběr technologií pro implementaci . . . . . . . . . . . . . . . . . . 3.3.1 Výběr typu aplikace . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Výběr programovacího jazyka . . . . . . . . . . . . . . . . . 3.3.3 Výběr datového úložiště . . . . . . . . . . . . . . . . . . . . Zabezpečení uživatelských dat . . . . . . . . . . . . . . . . . . . . . 3.4.1 Bezpečnost databázových dat . . . . . . . . . . . . . . . . . 3.4.2 Oddělený přístup uživatelů do aplikace pomocí autentizace Softwarový návrh aplikace . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Katalog požadavků . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Uživatelé a jejich práva . . . . . . . . . . . . . . . . . . . . 3.5.3 Diagramy aktivit . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Diagram komponent aplikace . . . . . . . . . . . . . . . . . 3.5.5 Návrh relační databáze . . . . . . . . . . . . . . . . . . . .

4 Implementace 4.1 GUI - grafické uživatelské rozhraní . . . . 4.2 Struktura aplikace . . . . . . . . . . . . . 4.3 Ukládání dat do databáze . . . . . . . . . 4.4 Ukládání nastavení programu do databáze 4.5 Logování varování a chyb . . . . . . . . . 4.6 Import výpisů . . . . . . . . . . . . . . . . 4.7 Verzování zdrojového kódu . . . . . . . . . 4.8 Dokumentace zdrojového kódu . . . . . .

. . . a . . . .

. . . . . . . . . . . . XML . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

23 24 25 25 25 25 28 28 30 31 32 33 33 34 34 34 35

. . . . . . . .

37 37 38 38 39 39 39 40 40

5 Testování 41 5.1 Průběh a výsledky testování prototypu . . . . . . . . . . . . . . . . . . . . . . 41 6 Závěr

43

Literatura

45

A Seznam použitých zkratek

47

B Slovník

49

C Formáty bankovních výpisů C.1 Česká spořitelna . . . . . . . . C.2 Komerční banka . . . . . . . . C.3 Československá obchodní banka C.4 mBank . . . . . . . . . . . . . .

51 51 53 57 58

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

OBSAH

D UML diagramy D.1 Vybrané diagramy aktivit . D.2 Schéma relační databáze . . D.2.1 Systémová databáze D.2.2 Uživatelská databáze

xiii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

61 61 65 65 66

E Grafické uživatelské rozhraní

67

F Uživatelská příručka

71

G Obsah přiloženého CD

79

xiv

OBSAH

Seznam obrázků 2.1 2.2 2.3 2.4 2.5 2.6

Co se klientům líbí na přímém bankovnictví . . . . . . . . . . . . . . . . . . Průzkum používanosti produktů přímého bankovnictví v ČR v roce 2004 . . Jednotlivci starší 16 let používající v ČR vybrané informační technologie . . Pohled na formulář pro import bankovních výpisů v programu Aconto Free Program DSMan s načtenými výpisy z GPC souboru Komerční banky . . . Program Pohoda s načtenými výpisy z účtu Komerční banky . . . . . . . .

3.1

Diagram komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9

Vzorový datový výpis České spořitelny . . . . . . . . . . . Vzorový výpis transakční historie České spořitelny . . . . Hierarchická struktura formátu KB Best . . . . . . . . . . Formát KB Best - hlavička (HO) a patička (TO) . . . . . Formát KB Best - obratová věta 51 (obecné údaje výpisu) Formát KB Best - transakční věta 52 nebo 53 (transakce) Vzorový výpis KB Best Komerční banky . . . . . . . . . . Vzorový výpis transakční historie ČSOB . . . . . . . . . . Vzorový výpis transakční historie mBank . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

52 53 54 54 55 56 57 57 60

D.1 D.2 D.3 D.4 D.5 D.6 D.7

Diagram aktivit - Přihlášení uživatele Diagram aktivit - Spuštění aplikace . . Diagram aktivit - Vytvoření uživatele . Diagram aktivit - Import výpisů . . . Diagram aktivit - Filtrování výpisů . . Schéma systémové databáze . . . . . . Schéma uživatelské databáze . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

61 62 63 64 65 65 66

E.1 E.2 E.3 E.4 E.5 E.6

Přihlášení do aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . Přehled účtů se zobrazeným oknem úprava účtu . . . . . . . . . . . . Přehled načtených výpisů a transakcí . . . . . . . . . . . . . . . . . . Filtrování výpisů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Přehled typů transakcí se zobrazeným oknem úprava typu transakce Import výpisů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

67 68 68 69 70 70

xv

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 3 . 6 . 8 . 15 . 16 . 17

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1 2.2 2.3 2.4 2.5

Počty uživatelů přímého bankovnictví v ČR v letech 1999/2000 . . . Údaje o Citibank, Commerzbank AG a České spořitelně za rok 2007 Údaje o ČSOB, GE Money Bank a Komerční bance za rok 2007 . . . Údaje o mBank, Raiffeisenbank a UniCredit Bank za rok 2007 . . . Žebříček českých bank podle velikosti . . . . . . . . . . . . . . . . .

3.1 3.2

Obecná informační pole výpisu . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Obecná informační pole transakcí . . . . . . . . . . . . . . . . . . . . . . . . . 23

C.1 C.2 C.3 C.4 C.5 C.6

Datový výpis České spořitelny - údaje o celém výpisu . . Datový výpis České spořitelny - transakce . . . . . . . . . Výpis transakční historie České spořitelny . . . . . . . . . Formát transakční historie ČSOB . . . . . . . . . . . . . . Formát transakční historie mBank - údaje o celém výpisu Formát transakční historie mBank - transakce . . . . . . .

xvii

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. 5 . 9 . 9 . 10 . 10

. . . . . .

51 52 53 58 59 60

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Nástup éry osobních počítačů a internetu poznamenal život člověka v mnoha směrech. Umožnil rychlý přístup k informacím, zábavě a poskytl pro mnoho lidí nástroj obživy. Dopad počítačů nebyl ale znát jen v oblasti pracovní, vzdělávací a zábavní, mnoha lidem doslova revolučně změnil jejich všednodenní život. Hlavně internet umožnil nejen pasivní příjem informací, ale také aktivní komunikaci a komunikace je to, co pohání celý dnešní svět. Činnosti jako odeslání dopisu na poště, zaplacení faktury či složenky v bance, objednání a zakoupení zboží v obchodě, komunikace s úřady, ty všechny a jiné už v posledních letech nepředstavují osobní návštěvu příslušné instituce a z toho často plynoucí ztrátu drahocenného času nebo zaplacení nemalých poplatků za vyřízení. Internet umožnil realizování těchto činností elektronickou podobou z pohodlí domova či zaměstnání a poskytl tak způsob jak ušetřit čas na straně klienta a jak snížit náklady, zrychlit vyřízení a poskytnout výhodnější cenové podmínky klientům na straně firem a úřadů. Jedná se ve své podstatě o další stádium evoluce v mezilidské komunikaci, jakých lidská populace za své existence zažila už několik. Toto stádium ale je výjimečné v tom, že jednotlivé dílčí změny se dějí velmi rychle, na čemž se velkou měrou podílí rychlý rozvoj vědy a techniky. Elektronické bankovnictví (2.1) je mezi uvedenými činnostmi specifické, protože v mnoha případech učinilo návštěvu pobočky banky zcela zbytečnou. Jeho jednoduchost navíc zvyšuje oblibu placení za zboží u obchodníka elektronickým převodem z účtu na účet a zákazník se tak úplně vyhne manipulaci s hotovostí. Elektronická správa financí se tak stala jednoduchou činností, kterou banky podporují kvůli rychlému automatizovanému zpracování a nabízejí svoje elektronické služby za nízké poplatky nebo případně úplně zdarma. Mezi další výhody pro klienty patří např. žádné čekání ve frontách na pobočce, stav účtu a pohyby peněz mají neustále k dispozici a mohou s nimi kdykoliv efektivně a snadno manipulovat. Přes všechny výhody s sebou nese e-banking jedno velké riziko - bezpečnost. Peníze odjakživa přitahovaly nekalé živly a i systémy elektronického bankovnictví a lidé je používající musejí neustále snášet útoky podvodníků a hackerů. Proto musí být na aplikace pracující s penězi a soukromými daty kladeny vysoké bezpečnostní požadavky s několika úrovněmi zabezpečení. Elektronické bankovnictví probíhá formou aktivní, které umožňuje manipulaci s penězi, a pasivní, které slouží ke kontrole účtu a sledování peněz. Nejrozšířenější je internetové bankovnictví, které vedle telefonického umožňuje mnohem větší rozsah služeb. Zatímco aktivní

1

2

KAPITOLA 1. ÚVOD

operace jsou obvykle zpracovány na velmi vysoké úrovni, na pasivní operace není kladen tak velký důraz a často jsou obsaženy pouze v základní podobě - pohyby na účtu jsou archivovány pouze krátkou dobu, vyhledávání a filtrování je omezené, není možná správa více účtů v jednom bankovním systému a další. Mým cílem je navrhnout a vytvořit systém pro správu bankovních účtů, který odstraní některé z hlavních nedostatků pasivního internetového bankovnictví, přidá další funkce a umožní efektivní a rychlé získávání informací o stavu peněz na účtech v domácím nebo firemním prostředí. Aneb slovy klasika: „Peníze jsou nenasytné, samotným se jim stejská, chtějí se rozmnožovat.“ Edward Albee

Kapitola 2

Popis problému, cíle a požadavky Tato kapitola popíše formy elektronického bankovnictví, jeho historii a jak elektronické bankovnictví vypadá v současnosti v České republice. Dále bude nastíněn popis implementovaného systému a cíle bakalářské práce. Kapitolu uzavře srovnání s konkurenčními produkty.

2.1

Elektronické bankovnictví

Elektronické bankovnictví (také označováno jako e-banking nebo přímé bankovnictví) je způsob komunikace banky a klienta, kdy klient nemusí přijít osobně na pobočku banky a komunikuje s ní prostřednictvím elektronických zařízení - např. počítač, mobilní telefon, platební karta, bankomat.

Obrázek 2.1: Co se klientům líbí na přímém bankovnictví Zdroj: Výzkum NFO AISA pro GE Capital Bank a [1]

3

4

KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY

2.1.1

Bankovní operace

Pasivní bankovní operace jsou činnosti, které nemanipulují, na rozdíl od aktivních operací, s vlastními finančními prostředky na účtu. Mezi aktivní bankovní operace patří: • příkaz k úhradě na jiný účet v české nebo zahraniční měně • zřízení, změna a zrušení inkasa nebo trvalého příkazu k úhradě Mezi pasivní bankovní operace patří: • přehled informací o účtech • zjištění zůstatku na účtu • přehled transakční historie • stažení účetních dat, výpisů • nastavení bankovních služeb (např. frekvence zasílání výpisů, upozornění na změny zůstatku) • informace o bankovních produktech, kurzu měn, úrokových sazbách

2.1.2

Historie e-bankingu

První formou elektronického bankovnictví byla debetní platební karta (2.2.1), kterou vydala v roce 1950 americká společnost Diners’ Club, Inc. První bankomat (zařízení pro výběr hotovosti pomocí elektronické karty) byl nainstalován v Londýně v roce 1967. Počátkem 80. let se začaly v obchodech objevovat první platební terminály, kde bylo možné platit kartou. S komercializací internetu na začátku 90. let se stalo běžným placení elektronickou kartou za zboží objednané na dálku přes internet. Současné bankomaty také umožňují další funkce vedle výběru hotovosti jako například dobíjení předplacených mobilních kupónů nebo podání jednorázového příkazu k úhradě. Nová generace bankomatů bude umožňovat i vklad hotovosti na účet. Velký rozvoj dalších forem elektronického bankovnictví nastal v 80. a 90. letech s rozvojem telekomunikačních technologií. Počátky home bankingu (2.2.3) se datují do 80. let, kdy vznikly systémy, které umožňovaly provádění transakcí na dálku pomocí počítače nebo klávesnice a televizoru připojených k telefonu. Mezi nejznámější home bankingový systém patřil britský systém Homelink, který byl vyvinut v roce 1983. V roce 1993 přestal být internet doménou univerzitních a vládních institucí a začaly na něj vstupovat velké komerční firmy a k prvnímu systému internetového bankovnictví (2.2.4) už zbýval jen malý krok. Celosvětově první institucí, která poskytla klientům internetové bankovní služby, byla banka Stanford Federal Credit Union v říjnu 1994. Prvním českým finančním ústavem, který zavedl internetové bankovnictví, byla v roce 1997 Rodinná družstevní záložna SFP, následovaná Fio, družstevní záložnou v roce 1998 a Expandia bankou (později eBanka, dnes Raiffeisenbank) v roce 1999. Telefonní bankovnictví (2.2.2) začalo v ČR po vzniku mobilních

2.2. FORMY ELEKTRONICKÉHO BANKOVNICTVÍ

Home Banking GSM Banking (pouze SIM Toolkit) Internet Phonebanking (pouze aktivní)

Konec roku 1999 30 666 1 433 22 209 168 375

5 Konec roku 2000 57 801 85 621 41 390 447 489

Tabulka 2.1: Počty uživatelů přímého bankovnictví v ČR v letech 1999/2000 Zdroj: [2]

sítí GSM v roce 1996. Nejdříve byly dostupné pouze pasivní operace, později přibyly i aktivní operace. Jak se internet po roce 2000 rychle rozšiřoval mezi obyvatele, rychle rostla i obliba přímého bankovnictví. To dokazuje nárůst počtu zákazníků českých bank za rok 2003, který např. u České spořitelny dosáhl 128 % z 259 000 klientů na 593 000, Volksbank CZ vykázala meziroční růst 350 %, ČSOB 159 % a Raiffeisenbank 122 % [1]. V roce 2007 např. vzrostl počet uživatelů internetového bankovnictví Komerční banky o 25 % a jeho služeb využívalo 500 000 klientů. 930 000 klientů z celkového počtu 1 607 000 klientů Komerční banky využívalo některý z kanálů přímého bankovnictví [3]. V současné době (rok 2009) už všechny banky internetové a telefonní bankovnictví poskytují. Počet uživatelů využívajících některou z forem přímého bankovnictví neustále roste, přičemž zdaleka nejvíce používané jsou internetové bankovnictví a platební karty viz obrázek 2.2. S oblíbeností internetového bankovnictví začaly vznikat banky, které s klienty komunikovaly výhradně prostřednictvím internetu - tzv. internetové banky. První z nich byla na počátku 90. let americká Security First Network Bank. U nás se za první internetovou banku nechá považovat Expandia banka založená roku 1998 (od roku 2001 eBanka), která ale měla také několik kamenných poboček. První čistě internetovou bankou se stala mBanka, která do ČR přišla v roce 2007 a neprovozuje pobočky, pouze informační kiosky a finanční centra. Další informace o historii různých typů e-bankingu viz [5], [6].

2.2 2.2.1

Formy elektronického bankovnictví Platební karty

Platební karty patří do elektronického bankovnictví, ale jsou specifické svým úzkým zaměřením - používají se pouze k placení za služby a k výběru peněz z bankomatu (ATM). Dnes existují různé druhy platebních karet - např. tuzemské, mezinárodní, specializované (karty pouze pro internetové platby, platby za pohonné hmoty, předplatní karty). Karty vydávají různé nadnárodní společnosti jako je Visa International, MasterCard International, American Express a jiné.

2.2.2

Telefonní bankovnictví (telebanking, phone banking)

Telefonní bankovnictví využívá pevnou telefonní linku nebo mobilní telefon ke zprostředkování bankovních operací. Poskytované služby se liší, některé banky umožňují plnohodnotné

6


Obrázek 2.2: Průzkum používanosti produktů přímého bankovnictví v ČR v roce 2004 Zdroj: [4]

ovládání účtu, jiné poskytují např. pouze informace o zůstatku peněz na účtu. Nevýhodou je přenos dat po telefonní lince nebo mobilní síti, který je zpoplatněný (některé banky používají telefonní čísla, u kterých klient neplatí poplatek za hovor). Do této kategorie patří: • Použití SMS pro zasílání informativních zpráv (např. o stavu účtu). • Využití služeb Call centra k uskutečnění operací prostřednictvím operátora/ky. • IVR (Interactive Voice Response) - ovládání služby tónovou volbou telefonu, kdy je uživatel navigován lidským nebo elektronickým hlasem. • Kombinace dvou výše uvedených, např. pro dodatečné ověření telefonním operátorem pro potvrzení aktivní operace. • GSM bankovnictví - komunikace probíhá formou SMS zpráv, které obsahují text ve specifickém formátu. Kvůli vysoké obtížnosti existuje zjednodušení ve formě GSM SIM Toolkitu, kdy jsou bankovní služby dostupné jako součást menu mobilního telefonu. • WAP bankovnictví - komunikace se speciálním internetovým bankovním rozhraním pomocí WAP protokolu. Wapové stránky jsou zjednodušenou podobou internetových stránek.

2.2. FORMY ELEKTRONICKÉHO BANKOVNICTVÍ

7

• Java bankovnictví - použití bankovní aplikace pro mobilní telefony napsané v programovacím jazyce Java. Telefonní bankovnictví se k intenzivnější správě účtu nehodí, protože neposkytuje příliš velké pohodlí, např. vzhledem k malé velikosti obrazovky a klávesnice mobilního telefonu. Rozsah služeb také bývá omezený. V budoucnu se tato situace s příchodem chytrých komunikačních zařízení může změnit. V neposlední řadě je telefonní bankovnictví obvykle méně zabezpečené než např. internetové bankovnictví. Obvykle se používá pouze autentizace přístupovým jménem a heslem (hlasová komunikace, IVR), někdy také šifrovaná komunikace (GSM, WAP). V současnosti využívá telebanking méně lidí než internet banking viz graf 2.2.

2.2.3

Home banking

Home banking umožňuje komunikaci s bankou prostřednictvím speciální aplikace, kterou má klient nainstalovanou na svém počítači. Služby, které home banking poskytuje se příliš neliší od internetového bankovnictví, včetně zabezpečení, kdy je obvykle použito ověření identity klienta jménem, heslem a osobním digitálním certifikátem nebo hardwarovým klíčem a komunikace je samozřejmě šifrována. Velkou výhodou home bankingu je, že je možné ho propojit s firemní aplikací a odesílat platby přímo z jejího účetního systému. Pro střední a velké firmy, které potřebují zadat velké množství transakcí denně, je tato forma bankovnictví nepostradatelná a nenahraditelná. Hlavně pro fyzickou osobu je nevýhodou, že banky poskytují home banking za výrazně vyšší měsíční poplatek než internetové bankovnictví. Další nevýhodou je nutnost instalace aplikace a to, že home bankingové aplikace jsou obvykle určeny pouze pro operační systém Microsoft Windows.

2.2.4

Internetové bankovnictví (internet banking)

Internetové bankovnictví probíhá prostřednictvím webových stránek spuštěných v rámci internetového prohlížeče. Uživatel tedy nepotřebuje nic jiného než počítač s připojením k internetu. Internetové bankovnictví obvykle umožňuje největší rozsah aktivních a pasivních operací. Měsíční poplatky za provozování internetového bankovnictví jsou většinou nízké nebo je poskytováno úplně zdarma. Poplatky za aktivní operace vyjdou levněji než u telefonního bankovnictví, protože není potřeba platit za spojení. Některé banky rozlišují internetové bankovnictví pro různé cílové skupiny lidí, např. studenty, fyzické osoby, podnikatele, a podle toho jim zpřístupňují určitou podmnožinu bankovních služeb. Komunikace probíhá pomocí protokolu HTTPS a je šifrována digitálním certifikátem. Pro autentizaci je nutné zadat přihlašovací jména a heslo, často navíc banky nabízejí dodatečné zabezpečení ve formě osobního podpisového certifikátu nebo hardwarového klíče. Aktivní operace jsou v systémech internetového bankovnictví obvykle ještě více zabezpečeny než samotné prohlížení stránek bankovnictví a pasivní operace, takovou formou zabezpečení může být například autorizace transakce kódem zaslaným pomocí SMS na mobilní telefon uživatele nebo čipovou kartou. Tuto dodatečnou úroveň zabezpečení zavedly v uplynulých letech téměř všechny české banky. Obliba internetového bankovnictví každoročně vzrůstá, stejně jako obliba a rozšíření internetu mezi lidmi jako takového viz graf 2.3.

8


Obrázek 2.3: Jednotlivci starší 16 let používající v ČR vybrané informační technologie Zdroj: [7]

Podrobnější informace o jednotlivých formách přímého bankovnictví viz [8] a [9].

2.3 2.3.1

České banky a jejich elektronické služby Souhrn údajů o 9 největších českých bankách za rok 2007

V tabulkách 2.2, 2.3, 2.4 je uveden přehled základních údajů o 9 největších českých bankách. Zbylé české banky tvoří poměrně zanedbatelnou část bankovního trhu a nebudou v této práci brány v potaz. Uvedené údaje jsou z roku 2007, případné výjimky jsou označeny. Zdroje se v některých údajích lehce rozcházely, takže jsem je zaokrouhlil, ale jejich vypovídající hodnota se tím nezmenšila.

2.3.2

Žebříček českých bank podle velikosti

Z údajů v tabulkách 2.2, 2.3, 2.4 jsem sestavil žebříček bank podle velikosti viz tabulka 2.5. V úvahu byly vzaty počty klientů a celková aktiva za rok 2007, resp. celková aktiva za rok 2006 u Citibanky, počty klientů za rok 2008 u Komerční banky a za rok 2009 u mBanky.

2.3. ČESKÉ BANKY A JEJICH ELEKTRONICKÉ SLUŽBY

Název Kód banky www Vznik v ČR Celková aktiva v mld. Kč Počet klientů v tis. Počet klientů přímého bank. v tis. Počet poboček Internet banking Home banking Telebanking

9

Citibank 2600 citibank.cz 1991

Commerzbank AG 6200 commerzbank.cz 1992

Česká spořitelna 0800 csas.cz 1991

132 (2006)

81

814

n/a

n/a

5326

n/a

n/a

994

11 Citibank Online

5

646 SERVIS 24, BUSINESS 24

IBS

Ne

MultiCash Gemini

MultiCash

CitiPhone

Ne

Servis 24 Telebanking, Servis 24 GSM banking

Tabulka 2.2: Údaje o Citibank, Commerzbank AG a České spořitelně za rok 2007 Zdroj: [10], [11] a domovské stránky bank

Název Kód banky www Vznik v ČR Celková aktiva v mld. Kč Počet klientů v tis. Počet klientů přímého bank. v tis. Počet poboček Internet banking

Československá obchodní banka 0300 csob.cz 1964

GE Money Bank

Komerční banka

0600 gemoney.cz 1998

0100 kb.cz 1992

925

85

662

3015

911

1629 (2008)

1302

363

917 (2008)

234 InternetBanking 24, BussinessBanking 24

201

389 (2008)

Internet Banka

Mojebanka

Home banking

Homebanking 24

BankKlient

Telebanking

Info 24, Linka 24, Mobil 24

Telefon banka, Mobil banka

Profibanka, Přímý kanál Expresní linka, Mobilní banka

Tabulka 2.3: Údaje o ČSOB, GE Money Bank a Komerční bance za rok 2007 Zdroj: [10], [11] a domovské stránky bank

10


Název Kód banky www Vznik v ČR Celková aktiva v mld. Kč Počet klientů v tis. Počet klientů přímého bank. v tis. Počet poboček Internet banking

mBank (BRE Bank S.A., o.s.p.) 6210 mbank.cz 2007

Raiffeisenbank

UniCredit Bank

5500 rb.cz 1993

2700 unicreditbank.cz 2007

0,7 (2008)

117

269

200 (2009)

300

200

200 (2009)

n/a

n/a

9 finančních center, 17 mKiosků Internetové bankovnictví

64

61

Internetové bankovnictví

Ne

MultiCash

mLinka

Telefonní bankovnictví, GSM bankovnictví

Online Banking, Online Card, BusinessNet MultiCash, Eltrans 2000 Telebanking, SmartBanking, Business Linka

Home banking Telebanking

Tabulka 2.4: Údaje o mBank, Raiffeisenbank a UniCredit Bank za rok 2007 Zdroj: [10], [11] a domovské stránky bank

Pořadí 1 2 3 4 5 6 7 8 9

Název Česká spořitelna Československá obchodní banka (ČSOB) Komerční banka GE Money Bank Raiffeisenbank mBank UniCredit Bank Citibank Commerzbank AG

Počet klientů (v tis.) 5326

Počet klientů přímého bankovnictví (v tis.) 994

3015

1302

1629 911 300 200 200 n/a n/a

917 363 n/a 200 n/a n/a n/a

Tabulka 2.5: Žebříček českých bank podle velikosti (Údaje jsou z let 2007-2009)

2.4. POPIS SYSTÉMU A CÍLE BAKALÁŘSKÉ PRÁCE

2.4

11

Popis systému a cíle bakalářské práce

Systém pro správu bankovních účtů je aplikace, která uživateli umožní mít přehled o svých bankovních účtech, transakcích na účtech a dalších informacích. Pracovní název aplikace je Bankovní účty. Protože aktivní bankovní operace podléhají vysoké úrovni zabezpečení a stávající elektronické systémy jednotlivých bank s nimi umožňují pracovat více než dostatečně, bude se systém Bankovní účty soustředit na pasivní operace, které nejsou v internetových bankovnictvích tak dobře propracovány, ale přesto tvoří významnou část práce s účtem. Internetová bankovnictví archivují pohyby na účtu obvykle pouze krátkou dobu (nejčastěji v řádu měsíců), neumožňují komplexní vyhledávání a filtrování v platbách. Dále neposkytují grafické znázornění pohybů na účtu a jiné statistické informace. Obvykle je podporován pouze export v několika málo formátech, obvykle buď TXT nebo CSV a kopie tištěných výpisů v PDF, takže není možné dělat reporty např. v HTML nebo XML. Protože každá banka má své vlastní proprietární bankovnictví, není možná správa více účtů v jednom bankovním systému. Protože existuje velké množství uživatelů, ať už jednotlivců nebo firem, které mají z různých důvodů několik účtů, nemožnost vytvářet přehledy, reporty a statistiky pro více účtů najednou může být velmi kontraproduktivní. Tyto nedostatky budou v systému Bankovní účty odstraněny a přibudou některé další užitečné funkce tak, aby systém jako celek zefektivnil správu pasivních operací s účty.

2.4.1

Co bude aplikace umožňovat

• se systémem bude moct pracovat více uživatelů (v různý čas) • každý uživatel bude mít přístup pouze ke svým datům • evidenci bankovních účtů uživatele • import textových bankovních výpisů • zobrazení importovaných výpisů a transakcí • editaci importovaných výpisů a transakcí (např. přidání nebo změnu poznámky) • filtrování a vyhledávání ve výpisech a transakcích • export do různých formátů (např. HTML, CSV) • statistické informace o zůstatku na účtu, přehledy o transakcích podle typu nebo data

2.4.2

Výhody oproti online systémům internetového bankovnictví

• víceuživatelský přístup (např. členové rodiny, oddělení ve firmě) • více bankovních účtů na jednom místě • neomezená doba archivace výpisů a transakcí • možnost editace a mazání výpisů a transakcí podle libosti uživatele

12


• možnost vyhledávání a filtrování výpisů a transakcí podle různých údajů • statistické informace, přehledy • aplikace bude přenositelná - bude ji možné snadno přenášet z jednoho počítače na jiný • aplikace bude fungovat i na operačních systémech a jejich konfiguracích, na kterých by některé online bankovnictví nefungovalo (např. Linux, Solaris) • export do dalších formátů

2.4.3

Nevýhody oproti online systémům internetového bankovnictví

• aplikace nebude umožňovat zadávání aktivních finančních operací • k použití aplikace nebude stačit pouze webový prohlížeč • aplikace bude náchylná na některé změny internetových bankovnictví (např. změna exportního formátu výpisů)

2.4.4

Požadavky na systém

• Reálná využitelnost aplikace - chci, aby byla opravdu užitečná, dostala se do povědomí lidí a nezapadla prachem. • Aplikace bude zdarma (bude šířena jako open source). • Bezpečnost aplikace nade vše - šifrování dat, přístup chráněný heslem, bez bezpečnostních děr. Data jsou citlivá a musí být chráněna alespoň stejnou měrou, jakou jsou v internetovém bankovnictví. • Možnost více účtů pro jednotlivé osoby - oddělené bankovnictví - uživatelé si navzájem nevidí do svých dat. • Multiplatformnost - systém bude fungovat na operačních systémech Microsoft Windows a Linux • Pokud to bude možné, aplikace bude co nejvíce nezávislá na internetu. • Data budou snadno zálohovatelná. • Aplikace bude co nejméně zasahovat do systému, na kterém běží. To umožní její snadné přemístění na jiný počítač. • Automatické stahování výpisů z internetového bankovnictví, pokud se po provedení rešerše ukáže jako implementovatelné.

2.4.5

Cíl bakalářské práce

Cílem této bakalářské práce je analyzovat, navrhnout a implementovat funkční systém, který co nejlépe splní uvedené vlastnosti a požadavky.

2.5. STRUKTURA BAKALÁŘSKÉ PRÁCE

2.5

13

Struktura bakalářské práce

Kapitola 2 se zabývá shrnutím základních faktů o elektronickém bankovnictví obecně a o tom, jak se vyvíjelo ve světě a v ČR. Jsou ukázány nedostatky, kterými trpí pasivní bankovní operace v internetových bankovnictvích a návrhy jak je řešit. Je uveden přehled vlastností a požadavků na navrhovanou aplikaci Systém pro správu bankovních účtů. V poslední části bude přehled a srovnání s již existujícími aplikacemi obdobného zaměření. Kapitola 3 se věnuje analýze projektu a softwarovému návrhu systému. Budou vybrány banky, jejichž výpisy bude možné v prototypu aplikace importovat. Proběhne rešerše, zda a jakým způsobem je možné implementovat do systému automatické stahování výpisů z webů internetových bankovnictví. Bude zvolena forma aplikace, programovací jazyk a datové úložiště. Bude provedena diskuze nad jednotlivými typy zabezpečení, které budou chránit data a uživatele systému. Kapitolu uzavře softwarový návrh systému včetně vybraných UML diagramů. V kapitole 4 budou zmíněna použitá řešení dílčích problémů. Kapitola 5 nastíní proces testování, předvede výsledky testování funkčního systému a navrhne případné změny v aplikaci. Kapitola 6 shrne splnění vytyčených cílů a načrtne možný budoucí vývoj aplikace.

2.6

Existující implementace obdobného systému

Systému pro správu bankovních účtů mohou z uvedených forem přímého bankovnictví konkurovat pouze home banking a internet banking. Každá banka má své vlastní internetové bankovnictví, které neumožňuje práci s účty různých bank a má další již uvedené nedostatky. Home bankingové aplikace umožňují správu bankovnictví trochu jiným způsobem, např. dávkové zadávání transakcí nebo přímo propojení s firemním účetním systémem, obvykle ale pracují nad stejnými daty, která jsou dostupná v internetovém bankovnictví, takže jsou archivována jen určitou dobu. Pouze některé home bankingové systémy umožňují správu více účtů různých bank. Většina aplikací zabývajících se tímto segmentem softwaru je určena pro střední a velké firmy, takže je také patřičně zpoplatněna. To platí jak pro home bankingové aplikace, tak pro účetní systémy vybavené funkcemi pro práci s účtem. Mnou navrhovaná aplikace sice bude umět jen podmnožinu obvyklých funkcí těchto systémů (pasivní operace), ale zato bude zdarma. Srovnání s existujícími aplikacemi bude také užitečné v tom, že můžu objevit nedostatky nebo chyby, kterých se při návrhu a implementaci poté vyvaruji, a také mohu narazit na zajímavou nebo užitečnou funkci, která nebyla zatím uvedena a mohla by být v budoucnu implementována. Nyní uvedu některé příklady aplikací obdobného typu. Stručně budou uvedeny výhody a nevýhody daného řešení a jak se liší od mnou zamýšleného řešení systému. Protože bude systém primárně zaměřen na české banky, i v této rešerši se zaměřím na tuzemské produkty. Zde uvedené systémy jsou dostupné ke stažení v plné verzi nebo demo verzi a je možné je tedy otestovat. Existují další systémy pro správu bankovních účtů, ty ale nejsou veřejně dostupné ke stažení a vyzkoušení zdarma, jsou pouze prodávány za poměrně vysoké částky.

14


Dále existují aplikace určené pro interní potřeby firem. Oba tyto druhy aplikací nejsou pro tuto rešerši podstatné, protože jsou určeny pro jiné cílové skupiny než volně a zdarma šiřitelný nástroj, jakým má Systém pro správu bankovních účtů být. V této části jsou zmíněny některé textové formáty používané českými bankami pro export výpisů a transakcí, např. univerzální GPC nebo CSV a BEST Komerční banky. Jejich bližší popis je v kapitole 3.1.

2.6.1

Aconto Free

autor: verze: cena:

PCS - Software, s.r.o. 2.92 omezená verze zdarma, plná verze stojí podle modulů a počtu licencí 10 600 - 139 900 Kč forma: funkční verze s různými omezeními OS: Microsoft Windows odkaz: http://www.aconto.cz/aconto-free Aconto Free je program pro evidenci faktur, objednávek, bankovních výpisů, vedení pokladny a podvojného účetnictví a daňovou evidenci příjmů a výdajů. Program je určen pro živnostníky a menší společnosti a v této variantě je poskytován zdarma. Některé jeho funkce jsou ale omezeny, např. velikost databáze (max. 2 GB), počet daňových dokladů (max. 100), a neobsahuje moduly Sklad, Evidence majetku, Mzdy a Kasa. Funkce podobné Systému pro správu bankovních účtů: • vedení účtů v tuzemské i zahraniční měně • import bankovních výpisů pro banky: ČSOB, Komerční banka, Česká spořitelna, Raiffeisen bank a další • přímé napojení na vybrané banky • párování výpisů s odpovídajícími evidovanými položkami (faktury atp.) V programu je uvedeno, že umí importovat výpisu typu GPC z České spořitelny, ČSOB a Komerční banky, tyto formy výpisů ale nejsou u běžných účtů dostupné a běžné formáty transakční historie neumí. Formát BEST Komerční banky se mi nepodařilo naimportovat, ačkoli jsem postupoval přesně podle návodu, tak program vždy skončil s chybovou hláškou. Ovládání programu a taktéž importu výpisů je velmi složité, k čemuž přispívá i staromódní uživatelské prostředí. Několikrát mi program také spadl bez udání důvodu. Aconto Free je velmi rozsáhlý nástroj umožňující správu kompletního chodu firmy, bohužel jeho velikost jej činí příliš složitým a, troufnu si říct, nepoužitelným čistě pro správu účtů fyzických osob a malých podnikatelů. Mezi další nevýhody programu patří velikost zabraného místa na disku po instalaci, která je úctyhodných 130 MB, a program také není multiplatformní.

2.6. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU

15

Obrázek 2.4: Pohled na formulář pro import bankovních výpisů v programu Aconto Free

2.6.2

DSMan

autor: verze: cena:

DAVID ŠAUER - DS-SOFT 1.52 základní verze zdarma, plná verze je placená podle počtu modulů a licencí, licence pro 1 uživatele s modulem základní fakturace stojí 582 Kč forma: funkční verze s několika omezeními OS: Microsoft Windows odkaz: http://www.ds-soft.info/dsman/banka-evidence-bankovnich-uctu DSMan je nástroj pro správu kontaktů, plánování a evidenci pro jednotlivce a malé firmy. Skládá se z různých modulů, které spolu funkčně příliš nesouvisí, např. kalendář, alarmy, číselníky, úkoly, fakturace, evidence zboží a modul pro práci s bankovními účty. Bankovní modul umožňuje tyto činnosti: • evidence účtů • import výpisů ve formátu GPC a ruční přidávání plateb • párování výpisů s fakturami • vyhledávání a filtrování v transakcích

16


Formát GPC ale poskytují jen některé české banky a význam některých polí se u jednotlivých bank liší. V DSMan se importují ze souboru výpisů pouze transakce, ke kterým se přidají informace o výpisu, nelze tedy zobrazit jen informaci o výpisu za dané období. Program umožňuje jednoduché vyhledávání a filtrování výpisů a plateb.

Obrázek 2.5: Program DSMan s načtenými výpisy z GPC souboru Komerční banky

Uživatelské rozhraní programu je jednoduché a přehledné, program je snadno ovladatelný. Bohužel neumí importovat jiné výpisy než GPC, takže jeho používání je omezeno jen na některé banky, které navíc export do formátu GPC nabízejí až u účtů pro podnikatele. Také není multiplatformní.

2.6.3

POHODA 2009 START

autor: verze: cena: forma: OS: odkaz:

STORMWARE s.r.o. 9200 CZ verze na vyzkoušení je zdarma, plnohodnotné varianty stojí 1980 - 13 980 Kč tzv. startovací verze na vyzkoušení Microsoft Windows http://www.stormware.cz/pohoda/homebanking.aspx

Ekonomický systém POHODA 2009 je jedním z největších účetních a ekonomických software produktů na českém trhu. Je určen pro malé, střední a větší firmy. Umožňuje vést účetnictví i daňovou evidenci a nabízí množství podpůrných nástrojů pro další ekonomické činnosti. Omezení verze START spočívá v limitovaném množství účetních operací, které je možné do systému zanést, jedná se např. o maximálně 200 položek účetního deníku, 100 bankovních položek, 100 faktur nebo 10 mezd.

2.6. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU

17

Součástí systému POHODA 2009 je sada funkcí Homebanking, která umožňuje pracovat se soubory pro komunikaci s bankou a to jak pro vytváření souborů se zadanými platbami pro banku, tak pro import bankovních výpisů. Podporovány jsou výpisy většiny českých bank, např. Komerční banka, ČSOB, Česká spořitelna, Citibank, Raiffeisenbank a další. Modul Homebanking umožňuje: • import bankovních výpisů • export transakcí, které je třeba odeslat bance, do příslušného exportního formátu • ruční zadání transakcí • načíst kurzy cizích měn z internetových stránek České národní banky POHODA 2009 Homebanking dokáže naimportovat téměř všechny druhy výpisů českých bank, hlavně těch, které banky umožňují stáhnout svým firemním klientům. Cílovou skupinou celého systému je firemní klientela a pro nepodnikatele by nenašel pravděpodobně uplatnění, protože nedokáže naimportovat výpisy ve formě transakční historie, které jsou jedinou možností exportu například u běžných účtů ČSOB, České spořitelny nebo mBank. Přestože je program velmi komplexní a umožňuje velké množství činností, na první pohled je vidět profesionální uživatelsky přívětivé prostředí s dobře rozvrženými ovládacími prvky a všudypřítomnou nápovědou po ruce.

Obrázek 2.6: Program Pohoda s načtenými výpisy z účtu Komerční banky Účetní systém POHODA 2009 je velmi dobrý produkt, který je ale určen hlavně pro podnikatele. Pro běžného uživatele nebo menší firmu, která si chce sama vést přehled o bankovních platbách a účetní agendu nechává na jiné společnosti, je takto rozměrný produkt

18


zbytečný a drahý. Navíc nepodporuje import formátů výpisů z běžných účtů některých bank, jak bylo zmíněno výše. Dalším aspektem je, že aplikace není multiplatformní.

2.6.4

Další programy

Během hledání konkurenčních produktů jsem narazil na několik dalších, které jsou velmi podobné předchozím uvedeným nebo mi přijde zajímavé je zmínit. RQ Money odkaz: http://www.rq.sk/rqmoney.html RQ Money je jednoduchý finanční program určený hlavně pro domácnosti. Pochází z dílny slovenského autora Slavomira Svetlika. Jeho hlavní funkcí je ruční přidávání příjmů a výdajů přiřazených do kategorií, k účtům a osobám. Program umí filtrovat transakce, hledat v nich, vykreslit graf příjmů a výdajů a zobrazit další statistické údaje. Je jednoduše ovladatelný, přehledný, využívá vestavěnou databázi SQLite a nemusí se instalovat, takže je snadno přenosný. Existuje pouze ve verzi pro Windows a je zdarma. Zaujal mě, protože se mi jeví jako vhodný doplněk k systému Bankovní účty, ve kterém by bylo možné evidovat hotovostní transakce domácností a malých firem. WinStrom 10 odkaz: http://www.winstrom.cz/produkty/10/ WinStrom 10 je komplexní ekonomický balík, který je svou funkčností a cenou velmi podobný systému POHODA 2009 a je to vlastně jeho přímý konkurent. Část aplikace zabývající se bankovními účty a výpisy funguje téměř stejně jako POHODA 2009, je podporován import výpisů bank používajících formát GPC. Výhodou WinStromu 10 je jeho multiplatformnost, je napsán z většiny v programovacím jazyku Java a existují verze pro Windows, Linux a Mac OS X.

2.6.5

Zhodnocení existujících aplikací obdobného typu

Z uvedených údajů je vidět, že pouze drahé komplexní účetní a ekonomické systémy dokáží importovat textové bankovní výpisy stažené z internetových bankovnictví různých českých bank. V těchto velkých systémech je správa bankovních operací pouze malou podmnožinou funkcí, kde zbytek tvoří nástroje pro účetní a daňové operace. Pro potřeby fyzických osob nebo podnikatelů, kterým účetnictví spravuje externí firma, jsou takové rozsáhlé a drahé programy obvykle zbytečné. Přesto tito lidé chtějí sledovat stav a pohyby peněz na svých účtech, které často mají u různých bank. V současnosti neexistuje v ČR program, který by to umožňoval a k tomu byl zdarma, uživatelsky přívětivý, nenáročný na ovládání a fungoval na různých operačních systémech. Zde vidím mezeru na trhu, kterou by mohl zaplnit Systém pro správu bankovních účtů.

Kapitola 3

Analýza a návrh řešení V této kapitole bude provedena analýza formátů výpisů používaných českými bankami. Následovat bude rešerše zabývající se možnostmi automatického stahování výpisů přímo z internetových bankovnictví. V další části části bude popsán výběr typu aplikace, programovacího jazyka, databáze a budou prozkoumány možnosti zabezpečení uživatelských dat. Poslední část této kapitoly se bude věnovat softwarovému návrhu aplikace.

3.1

Formáty bankovních výpisů

Protože nemám přístup do všech internetových bankovnictví českých bank a ani do všech různých verzí poskytovaných jednou bankou, je potřeba vybrat banky a konkrétní formáty výpisů, které budou implementovány v prototypu aplikace. Z tabulky 2.5 vyplývá, že více jak 3,2 milionu uživatelů přímého bankovnictví, tedy asi 75% uživatelů této formy bankovnictví, je klienty tří největších českých bank - České spořitelny, Československé obchodní banky a Komerční banky. Za zmínku stojí také mBanka, která je nejnovější bankou v ČR a vykazuje za minulý rok největší nárůst počtu klientů ze všech českých bank. Z tohoto důvodu a protože mám k dispozici výpisy pouze těchto čtyř bank, bude provedena analýza a implementován import výpisů pouze těchto bank: Komerční banka, Česká spořitelna, ČSOB a mBank. Další banky mohou být přidány v budoucím vývoji systému. Aplikace internetového bankovnictví Komerční banky (Mojebanka), České spořitelny (Business 24 Internetbanking) a ČSOB (ČSOB BusinessBanking 24) umožňují export ve formátu ABO (GPC), některá pole ale u každé banky mají jiný význam a může dojít k případnému zkrácení textových informací v důsledku pevné délky textových polí, která není příliš velká. Formát ABO neboli GPC je standardní komunikační bankovní formát pro tuzemský trh, byl vytvořen Českou národní bankou (ČNB). Protože nemám zatím k dispozici internet bankingy určené pro podnikatele a kvůli omezením formátu GPC, budou implementovány dostupné alternativy k GPC, které jsou dostupné všem uživatelům (podnikatelských i nepodnikatelských internet bankingů). Nyní budou podrobněji popsány jednotlivé typy formátů výpisů, které tyto banky používají, a budou zvoleny vhodné formáty pro strojové zpracování. Protože každý typ výpisu obsahuje různý počet informačních polí, budou zvolena ta, která mohou být pro uživatele důležitá, a s těmi bude aplikace dále pracovat.

19

20

3.1.1

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Česká Spořitelna

adresy internetových bankovnictví: https://www.servis24.cz https://www.business24.cz K dispozici mám službu Servis 24 Internetbanking. Výpisy ze služby Business 24 Internetbanking nebudou zatím implementovány. Další informace se týkají služby Servis 24 Internetbanking. Česká spořitelna umožňuje export výpisů v textovém formátu ABO (GPC) a CSV. Export je dostupný v e-bankingu jako volba „Export výpisů -> Datové výpisy“. Bohužel tato možnost není k dispozici u běžných (nepodnikatelských) účtů. Export transakcí je dostupný také pod volbou „Přehled účtů a zůstatků -> Transakční historie“ a jedná se o zjednodušený výpis ve formátu CSV. Tento typ výpisu ale neobsahuje některé údaje (např. období výpisu, zůstatek na účtu) a bylo by nutné tyto údaje případně zadat do aplikace ručně. Je to jediná možnost exportu u standardních účtů (nepočítáme-li klasický tištěný výpis v elektronické podobě ve formátu PDF) a tento typ účtu má pravděpodobně velká část klientů České spořitelny (fyzických osob). Jako typ výpisu jsem zvolil formát CSV (data oddělená středníkem nebo čárkou), protože není svázán pevnou délkou řádku jako formát ABO a nedochází tak u něj ke krácení informačních polí. Bude implementován import obou druhů CSV výpisů (Datový výpis i Výpis transakční historie). Struktura formátu CSV České spořitelny u Datového výpisu Podle informací České spořitelny tento typ výpisu není dostupný u nepodnikatelských účtů. Jedná se o netypický CSV formát. Údaje týkající se celého výpisu jsou na prvních 12 řádcích, poté následuje prázdný řádek, hlavičkový řádek a pak jednotlivé transakce v klasickém CSV formátu, kdy textová pole jsou uzavřená v uvozovkách a oddělená středníkem. Neobvyklé je formátování čísel, kde mezi řádem tisíců a stovek je mezera. Občas se objeví i netradičně mezera po znaménku (- 100,00). Popis polí tohoto formátu a příklad je v příloze C.1. Struktura formátu CSV České spořitelny u Výpisu transakční historie Výpis transakční historie je typický CSV formát, kdy textová pole jsou uzavřená v uvozovkách a oddělená středníkem nebo čárkou, podporovány budou oba druhy oddělovačů. Oproti kompletnímu datovému výpisu (viz výše) chybí úplně část týkající se obecných informací o výpisu. Počáteční zůstatek bude muset uživatel zadat při importu ručně, další údaje budou spočítány z transakcí (počáteční datum, koncové datum, debet, kredit a konečná balance). Popis polí a ukázka je v příloze C.1.

3.1. FORMÁTY BANKOVNÍCH VÝPISŮ

3.1.2

21

Komerční banka

adresa internetového bankovnictví: https://www.mojebanka.cz Komerční banka umožňuje export výpisů v textových formátech KB Best - OKM, Kompatibilní média - ABO (GPC) a CSV. Export je dostupný pod volbou „Přehledy -> Přehled obratů“ nebo „Přehledy -> Stažení účetních dat“. Formát KB Best OKM je vlastní formát Komerční banky. U formát GPC dochází ke krácení informačních polí kvůli pevné délce řádku a neobsahuje textové informační AV pole (dodatečné informace). Rozdíl mezi informační hodnotou formátů KB Best a CSV není téměř žádný (KB Best má dostatečně velká pole, takže nedochází ke krácení textových informací), rozhodl jsem se tedy pro implementaci formátu KB Best, protože je lépe strojově zpracovatelný. Formát KB Best má pevnou délku řádku 475 bajtů a jednotlivá informační pole mají pevně stanovené umístění na řádku a délku. V tom je podobný formátu ABO, ale délka textových polí je větší, takže nedojde k oříznutí delšího textu. Popis polí a ukázka výpisu je v příloze C.2.

3.1.3

Československá obchodní banka

adresy internetových bankovnictví: https://ib24.csob.cz/ https://bb24.csob.cz/ K dispozici mám službu ČSOB InternetBanking 24. ČSOB InternetBanking 24 umožňuje export výpisů v textovém formátu TXT a SLK (pro Microsoft Excel). U ČSOB BusinessBanking 24 je dostupný také formát ABO (GPC), ten nebude ale zatím implementován. Další informace se týkají služby ČSOB InternetBanking 24. Export je dostupný jako volba „Informace o účtech -> Pohyby“. Jako typ výpisu jsem zvolil formát transakční historie TXT, protože je snáze zpracovatelný než SLK a obsahuje stejné údaje. Obodobně jako u formátu transakční historie České spořitelny neobsahuje exportní formát TXT u ČSOB některé důležité údaje týkající se celého výpisu. Tyto údaje budou při importu spočítány z transakcí (počáteční a koncové datum, debet a kredit, počáteční a konečný zůstatek). Popis polí výpisu a jeho ukázka je v příloze C.3.

3.1.4

mBank

adresa internetového bankovnictví: https://cz.mbank.eu mBank je první internetová banka v ČR a poskytuje svoje finanční služby výhradně přes internet. Export výpisů je dostupný jako volba „Moje účty -> Historie transakcí -> Uskutečněné transakce“. Export je umožněn ve formátech CSV a PDF. Zvolil jsem formát CSV, protože je snadněji zpracovatelný. Výpis ve formátu CSV je typický CSV soubor, který je formátován tak, aby byl uživatelem snadno čitelný, což ztíží jeho strojové zpracování. Řád tisíců a stovek odděluje mezera.

22


Formát má sice standardní strukturu, ale položky transakcí jsou zřetězeny v poli popis, což je nevýhodné pro počítačové zpracování. Popis polí a ukázka výpisu je v příloze C.4.

3.1.5

Důležitá informační pole společná pro všechny banky

Ve výpisech (hlavně Best KB) existují pole, která nejsou pro tuzemské platby využívána nebo obsahují nepodstatnou informaci. S těmito poli se nebude pracovat a nebudou ukládána. Protože formát výpisu u každé banky obsahuje jiný počet položek, je třeba určit obecné položky, které jsou ve všech výpisech a/nebo mohou být pro uživatele důležité, a sjednotit tak návrh datového úložiště. Tyto položky bude aplikace uchovávat a pracovat s nimi. Obecná informační pole výpisu Název pole Číslo účtu Kód banky Název účtu Kód měny účtu Pořadové číslo výpisu Počáteční datum výpisu Koncové datum výpisu Debet Kredit Počáteční zůstatek Konečný zůstatek

Datový typ [délka] String [20] String [4] String [50] String [3] Integer Date Date BigDecimal[15,2] BigDecimal[15,2] BigDecimal[15,2] BigDecimal[15,2]

Poznámka

Např. CZK, EUR např. 1-12, 1-52, 1-356

Suma odchozích částek plateb Suma příchozích částek plateb

Tabulka 3.1: Obecná informační pole výpisu

3.2. AUTOMATICKÉ STAHOVÁNÍ VÝPISŮ

23

Obecná informační pole transakcí Název pole Číslo protiúčtu Kód banky protiúčtu Název protiúčtu Částka Kód měny Originální částka

Datový typ [délka] String [20] String [4] String [50] BigDecimal[15,2] String [3] BigDecimal[15,2]

Kód měny protiúčtu Variabilní symbol 1 Variabilní symbol 2 Konstantní symbol Specifický symbol Datum splatnosti (valuta) Datum zaúčtování

String [3] Long Long Integer Long Date Date

Poznámka 1

String [100]

Poznámka 2

String [100]

Zpráva AV

String [200]

Systémový popis

String [100]

Storno

String [20]

Označení transakce

String [30]

Poznámka Číslo protiúčtu Kód banky protiúčtu Název protiúčtu Částka transakce v měně účtu Kód měny účtu Originální částka v měně protiúčtu Kód měny protiúčtu Variabilní symbol Variabilní symbol protiúčtu Konstantní symbol Specifický symbol Datum splatnosti Datum zpracování v bance Poznámka (např. dlouhý název protiúčtu, zpráva pro příkazce) Poznámka 2 (např. zpráva pro příjemce) Doplňující text Systémový popis (např. typ platby) Udává, jestli došlo ke stornování transakce Označení transakce v bankovním systému dané banky

Tabulka 3.2: Obecná informační pole transakcí

3.2

Automatické stahování výpisů

Hlavní idea za automatickým stahováním výpisů je tato: Do aplikace se budou importovat výpisy. Bylo by dobré, kdyby uživatel měl volbu naimportovat je ručně ze souborů stažených z online bankovnictví a nebo si aplikace sama požadované informace stáhla (ať už ve formě souboru nebo webové stránky). Možné překážky: • Online bankovnictví používají komplexní webové stránky, které mají silné zabezpečení, tudíž není možné prosté stažení stránky pomocí HTTP protokolu a její zpracování. Je nutná interakce s webovou stránkou (vyplnění jména a hesla a případně zadání cesty k osobnímu certifikátu, výběr stránky v systému online bankovnictví).

24


• Použití maker nebo skriptů, které by simulovali činnost člověka sedícího u počítače by bylo velmi obtížné, protože v různých prohlížečích a jejich verzích, různých operačních systémech a na různých počítačích jsou ovládací prvky na webové stránce umístěny na různých místech a nebylo by možné k nim přistupovat pomocí absolutních souřadnic na obrazovce. • Aby aplikace získala přístup do internetového bankovnictví, musel by do ní uživatel zadat svoje přihlašovací údaje do bankovnictví. Zde vidím velký problém s důvěrou k aplikaci.

3.2.1

Programové ovládání prvků webové stránky

Řešením programového ovládání aplikace je použití prohlížeče integrovaného do aplikace. Takový prohlížeč by dokázal načíst danou webovou stránku, zadat do ní programově přihlašovací údaje a navigovat se na příslušnou stránku s výpisy. Při tomto procesu by se využívalo procházení stromu komponent, které tvoří webovou stránku, tzv. Document Object Model (DOM). Kvůli multiplatformnosti aplikace je vhodným kandidátem Mozilla Firefox, resp. jeho jádro Gecko (renderovací jádro používané produkty Mozilla pro vykreslování webových stránek). Mozilla poskytuje prostředky k integraci tohoto jádra do aplikací a vytvoření jednoduchého integrovaného (embedded) prohlížeče fungujícího v rámci aplikace. Tyto prostředky nejdou ale přímo zabudovat do aplikace, proto jsem se snažil najít už hotové komponenty embedded prohlížečů s jádrem Gecko, které by bylo možné použít v aplikaci napsané v programovacím jazyku Java, který je zamýšleným programovacím jazykem celého systému kvůli své multiplatformnosti a nenáročnosti aplikace napsané v Javě na správu uživatelem (není potřeba instalovat a složitě nastavovat). Velkou nevýhodou některých těchto embedded prohlížečů je, jak jsem zjistil, že nedokáží pracovat se stránkami, které obsahují Java applety, což by znemožnilo stahování výpisů např. z internetového bankovnictví Komerční banky, kde je přihlašování založeno na Java appletu. Problém s Java applety v embedded prohlížečích založených na Javě je v zásadě v tom, že není možné spustit pro applet nový Java Virtual Machine (JVM) uvnitř Java Virtual Machine, ve kterém běží vlastní aplikace s embedded prohlížečem. Existují komerční embedded prohlížeče, které problém s Java applety nemají. Jejich cena je bohužel vysoká a jsou určeny pro profesionální a rozsáhlé aplikace. Mezi tyto prohlížeče patří WebRenderer [12] a JxBrowser [13], oba jsou založeny na technologii od firmy Mozilla, jsou určené pro integraci do Java aplikací, jsou multiplatformní a plně podporují Java applety. Cena JxBrowseru začíná na 285 e, cena WebRenderu je ještě vyšší. Open source alternativy těchto embedded prohlížečů existují, ale nepodporují Java applety a mají další omezení nebo byl jejich vývoj před několika lety zastaven. Jediný open source embedded prohlížeč, který by podle tvůrců neměl mít problémy s Java applety, je JDic Browser [14]. JDic Browser funguje tak, že nalezne výchozí prohlížeč v systému a bude fungovat jako prostředník mezi ním a aplikací. V Microsoft Windows to může být buď Internet Explorer nebo Mozilla, pod Linux jen Mozilla. Bohužel projekt JDic byl opuštěn v polovině roku

3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI

25

2006, poslední verze JDic 0.9.5 podporuje Internet Explorer 5-6 a Mozilla Firefox 2. Se současnými verzemi těchto prohlížečů (Internet Explorer 8 a Mozilla Firefox 3) JDic nedokáže spolupracovat. Protože JDic pracuje pouze s výchozím prohlížečem nastaveným v operačním systému, bylo by na uživateli aplikace, aby měl jako výchozí prohlížeč nastavený např. multiplatformní prohlížeč Mozilla Firefox 2. Nezdá se mi ale rozumné nutit uživatele, aby kvůli automatickému stahování výpisů používal prohlížeč, který je už v současné době zastaralý a nahrazený novou verzí.

3.2.2

Bezpečnostní riziko

Poskytnutí svých přihlašovacích údajů do internetového bankovnictví aplikaci, o které uživatel vlastně nic neví, je z jeho hlediska velké bezpečnostní riziko. Systém pro správu bankovních výpisů by tedy musel být opatřen digitálním certifikátem ověřeným důvěryhodnou certifikační autoritou, která by potvrdila bezpečnost uživatelem poskytnutých citlivých údajů a nemožnost jejich zneužití aplikací.

3.2.3

Výsledek rešerše o automatickém stahování výpisů

V současné době neexistuje použitelné open source řešení integrovatelného prohlížeče, který by dokázal pracovat s Java applety, a komerční řešení jsou příliš drahá a v rozporu s požadavkem na dostupnost aplikace zdarma. Získání digitálního certifikátu, abych zaručil, že aplikace je bezpečná, by bylo také velmi složité a neobešlo se bez finančních nákladů. Z uvedených argumentů vyplývá, že implementovat automatické stahování výpisů z online systémů internetového bankovnictví, by byla nejistá a časově a finančně náročná záležitost, a vzhledem k cílové skupině uživatelů aplikace, kterou jsou fyzické osoby a malé firmy, by se to nevyplatilo. Automatické stahování výpisů tedy nebude v této fázi implementováno, může ale přijít ke slovu v budoucnosti, kdy bude lepší podpora Java appletů ze strany open source embedded prohlížečů nebo bude komponenta webového prohlížeče přímo integrována do budoucí edice platformy Java (v současnosti je ve vývoji, více [15]).

3.3

Výběr technologií pro implementaci

3.3.1

Výběr typu aplikace

Jakého typ aplikace bude, je velice důležitá otázka, protože zásadně ovlivní některá kritéria, která jsou na aplikaci kladeny. Internetová aplikace běžící kompletně na serveru (přístup pomocí webového prohlížeče) Výhody: • Klient není závislý na použité technologii, používá k přístupu pouze svůj webový prohlížeč.

26


• Přístup z libovolného počítače vybaveného internetem. • Zapouzdření - snadná správa a úpravy aplikace, které nemají žádný dopad na uživatele. • Více uživatelů by mohlo pracovat najednou. Případně i jeden uživatel na více počítačích. Nevýhody: • Výhradní závislost aplikace na internetu - v případě poruchy serverového stroje by aplikace nebyla vůbec dostupná (použitelná). • Nekompatibilita různých prohlížečů a nových verzí podporovaných prohlížečů by mohla způsobit špatnou funkčnost aplikace. • Velké přenosy dat, např. transakcí za delší období apod., by mohly být v řádu jednotek megabajtů i více, což by mohlo značně zpomalit práci s aplikací při pomalém připojení k internetu. • Aplikace je zamýšlena jako volně šiřitelná a náklady na provoz serveru by nebyly nulové, obzvlášť při větším rozšíření aplikace mezi lidi, takže by aplikace nemohla být provozována zdarma. • Potřeba správce serverového stroje. • Data všech uživatelů by byla uložena na jednom centrálním místě, pokud by došlo k havárii serveru a ztrátě dat, následky by byly vážné. Desktopová aplikace s datovým úložištěm na serveru Desktopová aplikace je termín označující aplikaci, která je spuštěna a běží na PC uživatele. Není tedy na serveru a komunikace neprobíhá přes internet. Jsou možné tři varianty umístění databázového serveru. Centrální server pro všechny uživatele aplikace (podobně jako u celé internetové aplikace výše), jeden server pro celou lokální firemní síť nebo server nainstalovaný vždy lokálně na počítači, kde je aplikace. Výhody: • Více uživatelů nebo jeden uživatel přihlášený na více počítačích by mohli pracovat najednou. Tento přístup by byl vhodný pro menší a střední firmy, kde by více lidí mohlo s aplikací pracovat najednou. • Pokud by bylo datové úložiště v lokální síti, data by byla okamžitě k dispozici, nemuselo by se na ně čekat. Nevýhody: • U centrálního serveru by byla opět závislost na funkčnosti internetového spojení.


27

• Silná závislost aplikace na databázovém stroji - v případě poruchy by aplikace nebyla použitelná, data by nebyla k dispozici. • Velké přenosy dat, např. transakcí za delší období apod., by mohly být v řádu jednotek megabajtů i více, což by mohlo zpomalit práci s aplikací, pokud by databázový server nebyl v lokální síti. • Aplikace je zamýšlena jako volně šiřitelná a náklady na provoz centrálního databázového serveru by nebyly nulové. Při využití ve firmě, která má svůj vlastní databázový server v lokální síti, a pro lokální server na PC by to nebyl problém. • Počáteční instalace by zahrnovala poměrně složitou konfiguraci databázového stroje, vytvoření databáze a nastavení přístupových práv uživatelů. • Potřeba správce databázového stroje. • Otázkou je, zda by bylo opodstatněné vícenásobné současné používání aplikace, protože v menších firmách má většinou na starosti tuto agendu jedna osoba. Desktopová aplikace Výhody: • Data jsou okamžitě k dispozici, nemusí se na ně čekat. • Nezávislost na internetu, internet by byl potřeba pouze pro stažení výpisů (čili menších objemů dat) a aplikace by byla plně funkční i bez dočasně nefunkčního internetu. Výpisy se nechají stáhnout a importovat i za několik dní zpětně, takže by bylo možné aplikaci plně používat. • Dostupnost aplikace není omezená funkčností serveru. • Aplikace může být naprogramována tak, aby nevyžadovala žádnou počáteční instalaci, ruční vytvoření databáze ani správce serveru. Byla by také možnost snadné přenositelnosti na jiný počítač bez nutnosti jakékoliv další konfigurace. • Nevyskytovaly by se žádné dodatečné náklady spojené s provozem a správou aplikace, takže by mohla být šiřitelná plně zdarma. • V menších firmách má většinou na starosti tuto agendu jedna osoba, takže požadavek vícenásobného současného přístupu k datům není potřeba. • Je možné dodatečně v budoucnu implementovat možnost serverového datového úložiště (pro větší firmu). Nevýhody:

28


• Aktualizace a vylepšování aplikace by znamenalo pro uživatele vyměnit starou verzi za novou, což by s sebou také neslo riziko přesunu dat. Pokud by došlo pouze ke změně vlastní aplikace a ne databáze, nemusela by se data přesouvat do nové verze databáze, jinak by řešením byl kompletní export a import dat do nové verze. Případně by update na novou verzi vyřešil speciální program napsaný pro tuto příležitost. • S aplikací by mohl najednou pracovat pouze jeden uživatel. • Zlomyslný uživatel může smazat data ostatních uživatelů. Databázi ale navrhnu tak, aby nemohl získat data obsažená v databázových souborech. Po zvážení požadavků na aplikaci a výhod a nevýhod jednotlivých variant jsem se rozhodl pro desktopovou aplikaci. Mým cílem tedy bude implementovat Systém pro správu bankovních účtů jako desktopovou aplikaci, která nebude závislá na internetu, bude malá a přenositelná z počítače na počítač bez potřeby větších uživatelských zásahů, nebude ve velké míře závislá na hardwarovém vybavení počítače. Datové úložiště bude přímo součástí aplikace, takže nad daty budou moct operace probíhat rychle a uživatel bude svůj čas trávit efektivně a ne čekáním na odezvu serveru. Různé kopie aplikace budou moct používat nezávislí uživatelé bez jakýchkoliv omezení na funkčnosti. V případě potřeby, např. u střední firmy, může být v budoucnu přidána alternativa mít centralizované datové úložiště na lokálním databázovém serveru.

3.3.2

Výběr programovacího jazyka

Protože jsem se rozhodl pro desktopovou aplikaci a jedním z požadavků je multiplatformnost, zvolil jsem jako programovací jazyk Javu. V současné době je Java rozšířený, oblíbený, podporovaný a rozvíjený jazyk, má velký potenciál a měl by umožnit implementaci všech funkčních prvků aplikace. Jistou nevýhodou Javy může být její závislost na Java Virtual Machine a verzi JRE (Java Runtime Environment) - prostředí umožňujícího běh Java aplikací. V současné době je aktuální verze Java 6 a verze JRE 6 Update 14. Na této verze bude aplikace vyvíjena a testována. Uživatel musí mít pro spuštění aplikace nainstalované na svém počítači Java Runtime Environment, které je možné stáhnout z [16].

3.3.3

Výběr datového úložiště

Protože jsem se rozhodl implementovat desktopovou aplikaci, která není závislá na internetu a současně je snadno přenositelná a klade co nejmenší nároky na znalosti uživatele, databáze bude součástí aplikace (tzv. embedded databáze). Embedded databáze je opakem architektury klient-server, aplikace pro přístup k datům nevyužívá databázový server, ale databázi, která je spuštěná v adresovém prostoru aplikace, která ji využívá. Aplikace přistupuje prostřednictvím databázové knihovny přímo k souborům s daty. Z toho plyne, že embedded databáze jsou primárně určeny pro práci v single-user režimu (současně obsluhují jen jednoho uživatele). Vlastní databáze je uživateli skrytá a nevyžaduje údržbu. Výhody embedded databází:


29

• jednoduché API (aplikační programové rozhraní) - obvykle poskytují jen množinu funkcí, která aplikace potřebuje • malá velikost • snadná instalace - buď v operačním systému nebo přímo jako součást aplikace, uživatel nic neinstaluje a nekonfiguruje • neprovádí se externí údržba databáze mimo aplikaci • rychlost - při práci s menšími objemy dat jsou mnohonásobně rychlejší než databázové servery • snadná záloha, přesun dat - databáze je obvykle tvořena složkou s několika soubory, takže stačí složku zkopírovat na jiné místo Nevýhody embedded databází: • většinou neobsahují přístupová práva, systém přístupových práv k datům se řeší na aplikační úrovni • transakční mechanismy nejsou většinou ve velké míře implementovány • některé nepodporují dotazovací jazyk SQL (používají jiný, pro ně optimálnější, dotazovací jazyk) • konzistence dat - z důvodu rychlosti jsou data kešována v paměti a bez korektního uzavření DB mohou být datové struktury na disku poškozeny Zdroj: [17], [18] Problémem by také mohla být multiplatformnost. Pokusím se tedy najít databázi, která podporuje dotazovací jazyk SQL, který ovládám, je multiplatformní, dokáže spolupracovat s Java aplikací a podporuje transakce a přístupová práva. Embedded databází je velké množství, zaměřil jsem se na tyto tři nejznámější: Oracle Berkeley DB Java Edition odkaz: http://www.oracle.com/technology/documentation/berkeley-db/je Jedná se o embedded databázi od světového databázového lídra Oracle. Je open source a kompletně napsaná v Javě, takže je multiplatformní. Podporuje transakce. Nepodporuje ale SQL dotazovací jazyk. Používá dotazování na bázi B-stromu, které je údajně rychlejší než SQL. SQL je mi ale známější.

30


SQLite odkaz: http://www.sqlite.org SQLite je rychlá rozšířená relační embedded databáze. Je open source a podporuje transakční principy. Umí SQL dotazování. SQLite je napsaná v jazyce C a existují verze pro Microsoft Windows i Linux, to by ale znamenalo mít v aplikaci verze knihoven pro každý operační systém zvlášť. Existuje rozhraní pro práci s SQLite databází (JDBC).

Apache Derby odkaz: http://db.apache.org/derby/ Apache Derby je další open source relační databáze s SQL dotazováním. Derby je napsaná kompletně v Javě a je tak multiplatformní. Podporuje transakční zpracování a téměř úplně standard SQL99. Derby podporuje přístupová práva uživatelů a šifrování dat. Její velikost je velmi malá (knihovny mají velikost pouze 2,5 MB). Od roku 2006 je Derby standardně dodávána s Java Devolopment Kit 6 (balík vývojových nástrojů) pod názvem JavaDB (bez jakýchkoliv změn). SQLite a Derby jsou z pohledu mé aplikace podobné. Derby je napsaná v Javě a tudíž její knihovny jsou multiplatformní, takže nejsou potřeba knihovny pro každý operační systém zvlášť. Systém pro správu bankovních účtů bude tedy využívat jako embedded databázi Apache Derby (JavaDB). V případě potřeby, např. u menší firmy, je možné v budoucnu implementovat jako alternativu centralizované datové úložiště na lokálním databázovém serveru, se kterým by desktopová aplikace pracovala. To by ale vyžadovalo větší administrativní úkony ze strany správce aplikace. Výhodou by byla možnost používat několik kopií aplikace na různých místech v jednom okamžiku (stejný uživatel i různí uživatelé).

3.4

Zabezpečení uživatelských dat

Bezpečnost aplikace bude rozdělena do dvou úrovní: • bezpečnost dat (databáze) • oddělený přístup uživatelů (uživatelských účtů) pomocí autentizace Programovací jazyk Java byl od začátku navržen jako bezpečný jazyk, obsahuje množství API, nástrojů a implementací běžně používaných bezpečnostních algoritmů a protokolů (včetně šifrování, zabezpečené komunikace, autentizace a autorizace.

3.4. ZABEZPEČENÍ UŽIVATELSKÝCH DAT

3.4.1

31

Bezpečnost databázových dat

Bezpečnost databázových dat spočívá ve 3 hlavních úkolech: • zašifrování fyzických databázových souborů na pevném disku • povolení přístupu do databáze pouze po autentizaci • omezení práv uživatelů pouze na jejich data Všechny tyto prvky databáze Apache Derby umožňuje. Zašifrování fyzických databázových souborů na pevném disku Každý uživatel bude mít svoji databázi. Databáze je adresář se soubory, pro každou databázi je adresář unikátní. Pro připojení k databázi bude nutné bootovací heslo, které bude použito k fyzickému šifrování a dešifrování databázových souborů. Jako symetrický šifrovací algoritmus bude použito 128-bitové šifrování AES, které je považováno za jeden z nejbezpečnějších šifrovacích algoritmů současnosti. Povolení přístupu do databáze pouze po autentizaci Jako přihlašovací jméno do databáze bude sloužit uživatelovo přihlašovací jméno do aplikace a jako heslo bude použit SHA-1 otisk zřetězení přihlašovacího jména a hesla do aplikace zkrácený o minimum(délka přihlašovacího hesla uživatele, 24) znaků. Omezení práv uživatelů pouze na jejich data Protože každý uživatel bude mít svoji vlastní databázi, bude jejím výhradním vlastníkem a bude tak mít přístup ke svým datům pouze on sám. Pokud by byla jedna databáze společná pro všechny uživatele, představovalo by to problém, protože by celá databáze byla šifrovaná jedním klíčem, který by musel být uložen na bezpečném místě (tedy ne ve zdrojovém kódu nebo v souboru s nastavením). Při větším počtu uživatelů a dat by mohl být problém s rychlostí databáze. A co se mi jeví jako nejpodstatnější problém, uživatel by nemohl svá data zálohovat prostým zkopírováním složky s databází. Různá databázová schémata pro každého uživatele v rámci jedné databáze s příslušným nastavením přístupových práv by vyřešila otázku oddělení dat uživatelů, bohužel by musel existovat nějaký nadřazený uživatel (systém nebo administrátor), který by práva nastavoval. Role administrátora by byla vytvořena pouze pro tento účel a navíc by data uživatelů nebyla před ním chráněna (pokud by nebyla šifrována ještě uvnitř databáze, což je zbytečné). Pokud by se o přidělování práv staral systém (aplikace), byl by opět problém, kam uložit jeho heslo pro přístup do databáze. Uložení hesel a jiných citlivých údajů přímo do zdrojového kódu není vůbec bezpečné, protože řetězce jsou v Javě po zkompilování v *.class souborech snadno čitelné. Generování šifrovacího klíče podle nějakého pravidla by bylo odhalitelné pomocí reverzního inženýrství.

32


Ochranou proti reveznímu inženýrství je metoda zvaná obfuskace [19]. Jde o tzv. „matení“ kódu. Ve zdrojovém kódu jsou přejmenovány proměnné, metody a třídy na kombinaci (často nečitelných) znaků. Obfuskátory často umožňují také optimalizaci a kompresi kódu. Ne všechny obfuskátory ale dokáží zamaskovat (zašifrovat) konstantní řetězce znaků a i u těch, které to dokáží, není pro hackera velký problém získat informaci zpět, protože všechny obfuskační metody jsou ze své podstaty reverzibilní. Z uvedených důvodů není metoda obfuskace pro tuto aplikaci vhodná, protože její účinnost je omezená. Proto jsem se rozhodl, že každý uživatel bude mít svoji vlastní databázi chráněnou jeho přístupovým jménem a heslem a protože se tyto informace zadávají při přihlašování, nebudou uvedené ve zdrojovém kódu ani nikde jinde. Ve zdrojovém kódu bude uvedeno přihlašovací jméno a heslo do systémové databáze, ve které budou uvedeny pouze nezneužitelné informace jako je přihlašovací jméno uživatele a jednosměrně zašifrovaný otisk hesla (zahashovaný pomocí 160-bitového algoritmu SHA-1). Při přihlášení bude otisk zadaného hesla porovnán s otiskem v databázi, vlastní heslo nikde uloženo nebude. Tato metoda se pro autentizaci běžně používá. Jako bootovací heslo uživatelské databáze a heslo pro přístup do uživatelské databáze bude použit SHA-1 otisk zřetězeného přihlašovacího jména a hesla. To je vhodné kvůli tomu, aby byla splněna minimální délka hesla u 128-bitového šifrovacího algoritmu AES, která je 16 (128 bitů = 16 bajtů). Použití otisku samotného hesla by představovalo velké bezpečnostní riziko, protože tento otisk je uložen v systémové databázi. Aby délka tohoto hesla do databáze nebyla vždy 40 znaků, což je délka otisku SHA-1, a ztížilo se tak prolomení hesla, bude jako databázové heslo sloužit SHA-1 otisk zřetězeného přihlašovacího jména a hesla zkrácený o mininum(délka přihlašovacího hesla uživatele, 24) znaků. Tento způsob ochrany dat uživatelů se mi jeví jako neproniknutelný případným útočníkem, protože bez znalosti hesla nebude možné dostat se k uživatelovým datům a v důsledku také zjednoduší implementaci aplikace, návrh databáze a databázové dotazování. Nevýhodou oddělených databází pro každého uživatele je, že zlomyslný uživatel může smazat databáze ostatních uživatelů. Tento problém by nebyl odstraněn ani společným umístěním dat všech uživatelů v jedné databázi. Toto riziko bude ponecháno na uživatelích a jejich nastavení systémových přístupových práv.

3.4.2

Oddělený přístup uživatelů do aplikace pomocí autentizace

Jelikož aplikace bude umožňovat správu bankovních účtů různých uživatelů, bude z důvodu bezpečnosti před začátkem práce s ní požadována autorizace přihlašovacím jménem a heslem. Tím bude zabezpečeno výhradní právo práce s daty pro vlastníka těchto dat. Při ověřování přihlašovacích údajů se aplikace dotáže své systémové databáze, kde bude uloženo uživatelské jméno a otisk jeho hesla (zahashovaný algoritmem SHA-1). Přihlašovací jméno a heslo do systémové databáze bude ve zdrojovém kódu programu, což nepředstavuje bezpečnostní riziko, protože systémová databáze nebude obsahovat žádné zneužitelné informace (místo hesla uživatele bude uložen pouze jeho otisk).

3.5. SOFTWAROVÝ NÁVRH APLIKACE

3.5

33

Softwarový návrh aplikace

V rámci analýzy jsem provedl softwarový návrh systému, který byl v některých částech zjednodušen, protože vlastní aplikace nebude natolik komplexní, aby vyžadovala podrobnou dokumentaci. Jako dostačující považuji katalog požadavků, uživatelské role, diagramy složitějších aktivit, diagram komponent aplikace a návrh relační databáze. Diagramy byly vytvořeny v programu Enterprise Architect od firmy Sparx Systems.

3.5.1

Katalog požadavků

Katalog požadavků udává požadavky, které musí implementovaný systém splňovat. Funkční požadavky udávají, jakou funkčnost musí program mít. Nefunkční požadavky kladou omezení na vzhled a způsob fungování aplikace.

Funkční požadavky F1. Systém bude umožňovat vytváření a správu více nezávislých uživatelských účtů. F1.1. Každý uživatel může změnit nebo smazat pouze svůj účet a má přístup pouze ke svým datům. F2. Uživatel bude moct evidovat své bankovní účty. F3. Uživatel bude moct importovat výpisy transakcí z internetových bankovnictví. F3.1. Import bude probíhat pomocí textového souboru F3.2. Budou podporovány výpisy těchto českých bank: Komerční banka, Česká spořitelna, ČSOB, mBank. F3.3. Uživatel bude moct importovat výpisy pouze k účtům, které vytvořil v systému. F4. Uživatel bude moct zobrazit, spravovat a filtrovat výpisy a transakce a vyhledávat v nich. F4.1. Bude možné spárovat transakci s předdefinovaným typem transakce, což umožní snadné odlišení transakcí. F5. Uživatel bude moct exportovat data do výstupního formátu HTML a CSV. F6. Systém bude umožňovat zobrazení statistických informací. F6.1. Bude možné zobrazit aktuální zůstatek na účtu. F6.2. Bude možné zobrazit počet výpisů a transakcí za určité období.

34


Nefunkční požadavky N1. Aplikace musí být bezpečná - šifrování databázových souborů, autorizace uživatelů. N2. Aplikace bude multiplatformní - bude fungovat na operačních systémech Microsoft Windows a Linux. N3. Databáze bude integrovaná v programu - embedded databáze. N4. Aplikace bude desktopová a nebude vyžadovat připojení k internetu. N5. Aplikace bude snadno přenositelná.

3.5.2

Uživatelé a jejich práva

V systému bude pouze jedna uživatelská role. Každý uživatel bude moct: • spravovat své účty, výpisy, transakce a nastavení • exportovat a importovat data • upravit nebo smazat svůj uživatelský účet Uživatel bude mít přístup pouze ke svým datům.

3.5.3

Diagramy aktivit

Diagramy aktivit se používají pro popis dynamických prvků systému. Ukazují, jak jdou po sobě jednotlivé dílčí aktivity od začátku činnosti do jejího konce. Vybrané diagramy aktivit jsou v příloze D.1.

3.5.4

Diagram komponent aplikace

Diagram komponent 3.1 ukazuje komponenty použité v systému a jejich vztahy. Komponenta je modulární část systému, která zapouzdřuje svůj obsah a je vyměnitelná za jinou komponentu, která má stejnou funkčnost a používá stejná rozhraní. Aplikace bude využívat GUI knihovnu uživatelských prvků Swing jazyka Java. Popis komponent Java Virtual Machine (JVM) je virtuální stroj umožňující běh aplikace napsané v programovacím jazyce Java. Aplikační modul je modul využívající GUI knihovnu nástrojů Swing a umožňující vlastní funkčnost aplikace.

3.5. SOFTWAROVÝ NÁVRH APLIKACE

35

Obrázek 3.1: Diagram komponent

Java Persistence API (JPA) je objektově-relační mapovací framework a zprostředkovává ukládání objektů do databáze. Java Database Connectivity (JDBC) je API poskytující základní rozhraní pro jednotný přístup k databázím. Database Management System (DBMS) - Apache Derby (JavaDB) (Systém řízení báze dat) je modul zapouzdřující ukládání dat a nabízející rozhraní pro další aplikace, které tato data mohou využívat.

3.5.5

Návrh relační databáze

Databáze jsou dvojího typu - systémová databáze a uživatelské databáze.

Systémová databáze Systémová databáze obsahuje pouze tabulku „uzivatele“, ve které jsou uchovávána přihlašovací jména a otisky hesel uživatelů. Systémová databáze se používá pouze při registraci a přihlašování uživatele. Její schéma je v příloze D.2.1. Poznámka: Globální nastavení aplikace bude uloženo v konfiguračním XML souboru.

36


Uživatelská databáze Každý uživatel má svoji uživatelskou databázi obsahující informace o nastavení, účtech, výpisech a transakcích. Schéma uživatelské databáze je v příloze D.2.2. Tabulka „udaje“ obsahuje údaje o uživateli. Tabulka „nastaveni“ obsahuje nastavení uživatelského prostředí (každý uživatel má své vlastní nastavení). Ukládá se aktuální použitý Look & Feel (vzhled GUI), oddělovač v CSV při exportu, a naposledy použité cesty při importu a export dat. Tabulka „ucty“ obsahuje uložené účty uživatele. Tabulka „banky“ obsahuje předdefinované české banky a jejich údaje, uživatel má možnost tato data změnit a přidat nové banky. Tabulka „vypisy“ obsahuje položky, které se týkají celých výpisů. Tabulka „transakce“ obsahuje položky, které se týkají jednotlivých transakcí. Tabulka „kategorie“ obsahuje typy transakcí nadefinované uživatelem.

Kapitola 4

Implementace V této kapitole bude přiblížena implementace Systému pro správu bankovních účtů. Budou zde uvedeny použité technologie a popsány jednotlivé dílčí celky aplikace. Pro usnadnění implementace aplikace jsem použil vývojové prostředí NetBeans IDE 6.5.1 [20], které umožňuje velmi efektivní psaní zdrojového kódu programu a obsahuje i velmi dobře propracovaný designér grafického uživatelského rozhraní. Mezi další dovednosti NetBeans IDE patří spouštění a debuggování programu, podpora verzování kódu, kontrola syntaxe, obsahuje různé šablony a dokáže chytře doplňovat zdrojový kód či zobrazit dokumentaci.

4.1

GUI - grafické uživatelské rozhraní

Grafické uživatelské rozhraní (GUI) je uživatelské rozhraní, které umožňuje ovládat aplikaci pomocí grafických prvků zobrazených na obrazovce monitoru. Vzhled GUI je obvykle jedním z nejdůležitějších aspektů aplikace, protože je to první věc, se kterou uživatel přijde po spuštění programu do styku. Pokud GUI nevypadá hezky a neovládá se dobře, může uživatele odradit od používání jinak velice dobře fungující aplikace. K tvorbě GUI jsem použil designér integrovaný v NetBeans IDE, protože ruční tvorba GUI by vzhledem k velkému množství ovládacích prvků zabrali výrazně více času. Designér například umožňuje dodržet pravidla v rozložení prvků v okně, která mohou být velmi komplexní a bylo by obtížné je popsat ručně zdrojovým kódem. Designér na základě vytvořené grafické podoby vygeneruje zdrojový kód sám. Při tvorbě GUI jsem se snažil dbát na správné rozmístění ovládacích prvků v okně a decentní používání barev. Okna neobsahují příliš velké množství ovládacích prvků, dělá je to nepřehlednými a složitými na orientaci. Část ovládacích prvků byla přesunuta kvůli zpřehlednění aplikace do menu. Ovládací prvky, které zobrazují text, nebo tabulky byly vybaveny kontextovým menu, které umožňuje například zkopírovat vybraný text do schránky nebo označit řádek nebo sloupec v tabulce. Tím se zvýšila interaktivnost aplikace. V aplikaci je možné vybrat jeden z předvolených vzhledů - Look & Feel, které jsou součástí platformy Java, některé jsou multiplatformní (Metal, Nimbus, Motif), další jsou pouze pro Microsoft Windows (standardní Windows vzhled) nebo Linux (GTK).

37

38

KAPITOLA 4. IMPLEMENTACE

Pokud je nezbytné, aby v okně bylo větší množství ovládacích prvků, přidal jsem k nim popisné texty a nápovědu, která se zobrazí při najetí myší na prvek (tzv. tool-tip). Pokud je uživatel vyzván k zadání údajů, je mu přesně oznámeno co a v jakém tvaru má zadat a jaké jsou povolené hodnoty. Pokud zadá špatnou hodnotu, aplikace mu oznámí, kde udělal chybu. Pokud se provádí akce, která trvá delší dobu a program během ní nebude reagovat, aplikace o tom dá uživateli vědět změnou kurzoru z obyčejného na zaneprázdněný. Ke zvýšení dostupnosti ovládacích prvků (accessibility) a rychlosti práce s aplikací jsem využil přiřazení klávesových zkratek, ať už běžně používaných (např. Ctrl+F pro hledání v tabulce, F1 pro nápovědu atp.) nebo tzv. mnemoniky, která umožňuje rychlou navigaci pomocí klávesnice (označení komponenty nebo provedení akce po stisknutí Alt + podtržené písmeno v popisce komponenty). Do programu byla také integrována nápověda ve formě uživatelské příručky, viz příloha F. Dodržováním těchto pravidel jsem se snažil udělat program uživatelsky přívětivý. Jak grafické uživatelské rozhraní aplikace vypadá, je možné vidět z obrázků v příloze E.

4.2

Struktura aplikace

Aplikace se skládá z několika dílčích částí: • přihlášení uživatele • registrace nového uživatele • přehled účtů uživatele • import bankovních výpisů • přehled naimportovaných výpisů a transakcí • přehled nadefinovaných typů transakcí a párování s transakcemi • export dat v tabulkách do HTML a CSV • změna nastavení a údajů uživatele • nápověda (uživatelská příručka) a informace o autorovi Tyto části jsou v aplikaci buď reprezentovány plochou v hlavním okně (záložkou) nebo dialogovým oknem.

4.3

Ukládání dat do databáze

Pro usnadnění práci s databází jsem použil objektově-relační mapovací framework Java Persistence API (JPA), který umožňuje jednoduchý přístup k persistování (ukládání) objektů do databáze a slouží jako nadstavba nad přímým psaním SQL dotazů.

4.4. UKLÁDÁNÍ NASTAVENÍ PROGRAMU DO DATABÁZE A XML

39

Mimo jiné není JPA závislé na jednom konkrétním typu databáze, takže přechod k jinému typu databáze by znamenal pouze jednoduchou úpravu konfigurace. JPA se může samo postarat o vytvoření tabulek, pokud neexistují. K relačně-objektovému mapování na databázi je použit jazyk anotací (meta informací) zavedený ve verzi Java 5, který zjednodušuje popis mapování a vztahů mezi objekty a není tak potřeba tyto informace definovat v konfiguračním XML, jako tomu bylo předtím. Dojde také ke zvýšení přehlednosti zdrojového kódu, protože anotace je uvedena přímo u kódu, který ovlivňuje. Při ukládání a změně dat v databázi byly důsledně používány databázové transakce, takže pokud by během práce s databází došlo k chybě, data, která jsou v databázi, budou vždy platná. Například není možné, aby se do databáze kvůli chybě uložila pouze polovina transakcí z výpisu, buď se uloží celý výpis nebo se vůbec neuloží. K propojení seznamu načtených objektů z databáze s tabulkou jsem s výhodou použil knihovnu Beans Binding [21], která je součástí NetBeans IDE. Tato knihovna slouží k synchronizaci vybraných vlastností dvou objektů (např. seznam objektů a datový model tabulky). Toto propojení může být jednosměrné (čtení - změna vlastnosti v jednom objektu se projeví v druhém, ale obráceně to neplatí) nebo obousměrné (čtení a zápis).

4.4

Ukládání nastavení programu do databáze a XML

Uživatelské nastavení každého uživatele se ukládá do jeho databáze. Globální nastavení týkající se celé aplikace se ukládá do XML souboru. V prototypu aplikace se ukládá pouze jméno posledního přihlášeného uživatele, tento uživatel je pak automaticky přednastaven při dalším zobrazení přihlašovacího okna.

4.5

Logování varování a chyb

Pokud vznikne nějaká výjimka v aplikaci, je zapsána (zalogována) do souboru. Uživatel tak má možnost zjistit podrobnější informace, proč k výjimce došlo a zabránit opakovanému vzniknutí takovéto situace. Uživateli je také oznámeno přímo v aplikaci, že k výjimce došlo a podle povahy výjimky se pokračuje v běhu programu (varování) nebo se program ukončí (chyba). Pokud vznikne neočekávaná běhová (run-time) výjimka neboli chyba v programu, není zalogována a je na uživateli, aby o ní dal vědět tvůrci aplikace, aby mohla být opravena.

4.6

Import výpisů

V prototypu aplikace je podporován import 4 českých bank. Systém je navržen modulárně tak, aby přidání importu z další banky bylo co nejjednodušší. Každé bance odpovídá jedna metoda, která je zodpovědná za pársování souborů s výpisy a vytvoření a předání seznamu výpisů metodě, která je uloží do databáze. Při přidání importu výpisů nové banky tak stačí přidat pouze jednu odpovídající metodu.

40

4.7

KAPITOLA 4. IMPLEMENTACE

Verzování zdrojového kódu

Zdrojový kód systému byl po celou dobu implementace verzován pomocí systému pro správu a verzování zdrojových kódů Subversion [22]. Díky tomu není problém podívat se kdykoliv na předchozí verzi zdrojového kódu, např. z důvodu opravení chyby v programu.

4.8

Dokumentace zdrojového kódu

Zdrojový kód byl pečlivě komentován, tam kde si to situace žádala. Kromě toho byl využit standardní dokumentační nástroj jazyka Java - Javadoc, pomocí kterého je možné vytvořit dokumentaci aplikačního programového rozhraní celého systému ve formátu HTML. Vygenerovaná dokumentace Javadoc Systému pro správu bankovních účtů je umístěna na přiloženém CD.

Kapitola 5

Testování Tato kapitola se bude věnovat procesu testování aplikace a navrhne případné změny z něj plynoucí. Po celou dobu implementace byl systém neustále testován. Byly vyzkoušeny různé možnosti vstupů uživatele a práce s grafickým uživatelským rozhraním. Nalezené chyby byly odstraněny a předpokládám, že takto byla eliminována většina chyb. Nelze samozřejmě popřít Murphyho zákony, např. „Software bugs are impossible to detect by anybody except the end user.“ Proto bude provedeno testování prototypu dvěma potenciálními uživateli, kteří se na vývoji systému nepodíleli. Jejich úkolem bude otestovat funkčnost programu, posoudit grafické uživatelské rozhraní a jeho ovládání a celkovou uživatelskou přívětivost aplikace.

5.1

Průběh a výsledky testování prototypu

Dvěma testovacím uživatelům (muž, student, 22 let, operační systém Linux; žena, studentka, 22 let, operační systém Windows XP) byl předán archiv s aplikací Systém pro správu bankovních účtů bez bližších pokynů či vysvětlení, pouze s uživatelskou příručkou a běžnými soubory s výpisy staženými z internetového bankovnictví. Uživatelé měli za úkol vyzkoušet ovládání a běžnou práci s aplikací a všímat si případných obtížně řešitelných úkolů, vzhledu a ovládání uživatelského rozhraní a chybného chování aplikace. Po skončení práce s aplikací ohlásili uživatelé tyto výsledky: • Oba: Uživatelské prostředí je přehledné a je jasné, kde kterou funkci hledat. • Oba: Možnosti ovládání programu myší a klávesnicí jsou standardní. Muž: Je výhoda, že veškerá činnost se nechá provádět pouze pomocí klávesnice. • Oba: Program reagoval rychle na všechny požadavky.

41

42

KAPITOLA 5. TESTOVÁNÍ

• Žena: Nezaznamenala žádné chyby. Muž si všiml varovných hlášení vypisovaných do konzole při spuštění na Linuxu a při použití vzhledu GTK. • Oba: Aplikace reaguje přesně tak, jak očekávali, žádné nelogičnosti nebo chybné chování nebylo zaznamenáno. Po prozkoumání uvedených varovných hlášení na Linuxu při použití vzhledu GTK bylo zjištěno, že jde o chybu v Java platformě, která se vyskytovala u stylu GTK při vykreslování kombo boxu. Tato chyba byla opravena ve verzi JRE 6 Update 12. Z výsledků testování plyne, že dodržování zásad správného návrhu GUI (4.1) mělo svůj význam a uživatelé, kteří testovali aplikaci, s ní byli spokojení po stránce uživatelské přívětivosti i funkčnosti. Uživatelským testováním nebyly objeveny žádné chyby v programu. To může ale pouze znamenat, že se na tyto chyby nenarazilo. Potenciální problém vidím v importu výpisů, kdy stažený bankovní výpis může mít trochu odchylnou strukturu, což může být způsobeno jeho chybným vygenerováním v systému banky nebo neúplnou implementací pársování daného formátu, a aplikace ho poté ohlásí jako neplatný nebo dojde ke špatnému naimportování dat. Tento problém může nastat také, pokud banka změní strukturu exportního formátu. Aplikace nebyla testována na jiných operačních systémech než Microsoft Windows a Linux, ale vzhledem k tomu, že využívá komponenty napsané pouze v Javě, je pravděpodobné, že bude fungovat i na operačních systémech Solaris a Mac OS X.

Kapitola 6

Závěr Systém pro správu bankovních výpisů byl úspěšně implementován a otestován. Splněny byly všechny požadavky na něj kladené a aplikace je připravena na běžné používaní. Jestli se uchytí a najde své uživatele, ukáže až čas. Rešerše ukázala, že automatické načítání výpisů z online systémů internetového bankovnictví by v současné době bylo pouze velmi špatně implementovatelné, navíc problém důvěry zákazníka v to, že aplikace nezneužije jeho přihlašovací údaje do internetového bankovnictví, tu bude stále. Pro menší firmy není tato funkce prioritní, protože nemají tak velký objem transakcí, a větší firmy si mohou dovolit zaplatit přímý zabezpečený kanál do bankovního systému. Přesto může být tato funkce implementována v budoucnu za použití nových technologií. Analýzou byly určeny bezpečnostní prvky určené k ochraně dat uživatele a byly všechny implementovány v prototypu. S uživatelskými daty tedy nemůže pracovat nikdo jiný než jejich vlastník. V budoucnu by mohla být aplikace rozšířena o import dalších formátů výpisů u zatím nepodporovaných bank a přidání nových formátů ke stávajícím bankám. Mezi další možná rozšíření může patřit například vytváření grafů o stavu peněz na účtu nebo počtu transakcí za určité období.

43

44

KAPITOLA 6. ZÁVĚR

Literatura [1] Kristýna Havligerová. Peníze.cz — Obliba e-bankingu v ČR, 2003. http://www.penize.cz/16321-pocet-priznivcu-primeho-bankovnictvi-roste. [2] Petr Vykoukal. Peníze.cz — Přímé bankovnictví v ČR, 2000. http://www.penize.cz/14041-nechodte-do-banky-vzdyt-nemusite. [3] KB.cz — Tiskové prohlášení: Internetové bankovnictví Mojebanka používá již 500 tisíc klientů Komerční banky, 2008. http://www.kb.cz/cs/com/press/news/339.shtml. [4] Marek Lutonský a Jan Staněk. Mobilmania.cz, Měšec.cz — Průzkum používanosti produktů přímého bankovnictví v ČR, 2004. http://www.mobilmania.cz/clanky/banka-v-mobilu-i-jinde-vysledky-pruzkumu/ sc-3-a-1106954. [5] Wikipedia.org — Historie platebních karet. http://cs.wikipedia.org/wiki/Historie_platebních_karet. [6] Wikipedia.org — Internetové bankovnictví. http://en.wikipedia.org/wiki/Internet_banking. [7] Český statistický úřad — Kolik a kdo z nás používá Internet?, 2008. http://www.czso.cz/csu/redakce.nsf/i/1_kolik_a_kdo_z_nas_pouziva_ internet. [8] Měšec — přímé bankovnictví. http://www.mesec.cz/prime-bankovnictvi/. [9] Peníze.cz — přímé bankovnictví. http://www.finance.cz/bankovnictvi/informace/prime-bankovnictvi/. [10] Kniha Seznamů.cz — Komerční banky. http://www.knihaseznamu.cz/seznam/Komercni-banky. [11] Peníze.cz — Banky. http://www.penize.cz/banky. [12] WebRenderer — Embedded Java browser. http://www.webrenderer.com/products/swing/product/.

45

46

LITERATURA

[13] JxBrowser — Embedded Java browser. http://www.teamdev.com/jxbrowser/index.jsf. [14] JDesktop Integration Components (JDIC) project. http://jdic.dev.java.net. [15] Java and integrated web browser component, 2008. http://blogs.sun.com/thejavatutorials/entry/html_component. [16] Java SE Downloads — Java Runtime Environment. http://java.sun.com/javase/downloads/index.jsp. [17] Radim Kolář. Root.cz — Embedded databáze, 2004. http://www.root.cz/clanky/embedded-databaze-uvod/. [18] Wikipedia.org — Embedded database. http://en.wikipedia.org/wiki/Embedded_Database. [19] Douglas Low. Protecting Java Code Via Code Obfuscation. http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/ obfuscation.html. [20] Vývojové prostředí Netbeans IDE. http://www.netbeans.org. [21] Beans Binding — Knihovna pro synchronizaci vlastností 2 objektů. https://beansbinding.dev.java.net. [22] Subversion — Systém pro správu a verzování zdrojových kódů. http://subversion.tigris.org.

Příloha A

Seznam použitých zkratek AES Advanced Encryption Standard API Application Programming Interface ATM Automated Teller Machine CRC Cyclic Redundancy Check CSV Comma Separated Values DBMS Database Management System DES Data Encryption Standard DOM Document Object Model DSA Digital Signature Algorithm GUI Graphical User Interface GSM Global System for Mobile communications HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IVR Interactive Voice Response JDBC Java Database Connectivity JDK Java Development Kit JPA Java Persistence API JRE Java Runtime Environment JVM Java Virtual Machine

47

48

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

MD5 Message-Digest algorithm 5 n/a non-available (nedostupné) PDF Portable Document Format RSA Rivest, Shamir, & Adleman (autoři algoritmu) SHA-1 Secure Hash Algorithm 1 SIM Subscriber Identity Module SMS Short Message Service SSL Secure Sockets Layer TXT TeXT UML Unified Modeling Language WAP Wireless Aplication Protocol WWW World Wide Web XML eXtensible Markup Language

Příloha B

Slovník Applet je softwarová komponenta, která běží v kontextu jiného programu, např. webového prohlížeče nebo v panelu pro přepínání oken v grafickém uživatelském prostředí. Bývá většinou orientován na plnění konkrétní funkce v daném kontextu a nepředpokládá se, že bude používán jako samostatná aplikace. Asymetrické šifrování používá volně dostupný veřejný klíč k zašifrování zprávy a soukromý (tajný) klíč pro dešifrování (tedy 2 různé klíče). Klíče jsou spolu matematicky svázány, ale nelze z jednoho vypočítat druhý. Soukromý klíč musí uživatel držet v tajnosti. Příkladem asymetrických šifrovacích algoritmů je RSA, DSA nebo DiffieHellman. Autentizace je proces ověření identity daného uživatele. Autorizace je činnost, při které se ověřuje, zda má uživatel dostatečná práva k provedení určité akce. Databázová transakce je operace nad databázovými daty, má tyto vlastnosti: provede se celá nebo vůbec (atomicita); po jejím provedení bude databáze obsahovat pouze platná data (konzistence); transakce o sobě navzájem nevědí a nevidí zpracovávaná data u jiné transakce (izolovanost); změny, které jsou v databázi provedeny, jsou trvalé a nemohou být ztraceny (trvalost). Digitální certifikát je veřejný šifrovací klíč elektronicky podepsaný certifikační autoritou a používá se v asymetrickém šifrování. Certifikační autorita je hodnověrná instituce, která ověří identitu osoby, které certifikát vydává. Součástí digitálního certifikátu je elektronický podpis, který slouží k ověření identity majitele. E-banking viz Elektronické bankovnictví. Elektronické bankovnictví je způsob komunikace banky a klienta, kdy klient nemusí přijít osobně na pobočku banky a komunikuje s ní prostřednictvím elektronických zařízení - počítač, mobilní telefon, platební karta. Elektronický podpis jsou elektronické identifikační údaje autora. Připojuje se k elektronickému dokumentu kvůli ověření identity dané osoby a zaručení integrity - neměnnosti dokumentu.

49

50

PŘÍLOHA B. SLOVNÍK

Hacker je původně počítačový expert, dnes je toto označení používáno pro osobu nabourávající se do počítačových systémů nejčastěji za účelem poukázat na jejich špatné zabezpečení nebo získat tajné údaje či peníze. Hardwarový klíč je elektronické zařízení na ochranu programu proti nelegálnímu používání, bez něj nelze program spustit. Hashovací funkce je metoda pro převod libovolného množství dat do krátkého textového řetězce pevné délky (otisk či hash), který je pro stejná vstupní data stejný. Tento převod je jednosměrný a je velmi obtížné zjistit původní data. Hashování se využívá v šifrování, pro kontrolu a porovnávání, indexování a vyhledávání dat. Pravděpodobnost, že 2 vstupní řetězce se stejným otiskem jsou různé, je velmi malá. Příkladem hashovacích funkcí jsou CRC, MD5 nebo SHA-1. Java Virtual Machine (JVM) je sada počítačových programů a datových struktur, které využívají model virtuálního stroje pro vykonávání počítačových programů napsaných v jazyce Java. Look & Feel je termín používaný k popisu grafického uživatelského rozhraní (GUI). Look & Feel zahrnuje vzhled a rozmístění ovládacích prvků (look) a jejich chování vzhledem k činnosti uživatele (feel). Meta informace je termín pro tzv. informace o informacích. Jedná se o značky (nebo také tagy), které blíže určují některé vlastnosti daného cíle, ke kterému se vztahují. Příkladem mohou být anotace v jazyce Java (od verze 5), které umožňují blíže určit vlastnosti daného zdrojového kódu, např. že je daná metoda zastaralá a neměla by se používat (@Deprecated) nebo že se mají ignorovat varování (@SuppressWarnings). Open source je počítačový software s otevřeným zdrojovým kódem. Otevřenost znamená, že autor veřejně poskytuje zdrojový kód a licence softwaru při dodržení podmínek umožňuje uživatelům zdrojový kód využívat, například prohlížet a upravovat. Šifrování (kryptografie) je způsob (také vědní obor), jak utajit zprávu před přečtením neoprávněnou osobou. Základem šifrování je šifra, což je algoritmus, kterým se převede prostý text (nebo binární soubor) do nečitelné (zašifrované) podoby. Klíč je tajná informace, bez které není možné zašifrový text přečíst (dešifrovat). Existují různé způsoby šifrování, např. symetrické a asymetrické šifrování. Někdy se do šifrování řadí i hashovací funkce. Symetrické šifrování využívá pro šifrování i dešifrování zprávy stejný klíč. Oproti asymetrickému šifrování má výhodu ve značně menší výpočetní náročnosti. Jeho nevýhodou je nutnost sdílet stejný klíč, takže si odesílatel a příjemce zprávy musí nejdříve klíč vyměnit nějakou bezpečnou cestou. Příkladem asymetrických šifrovacích algoritmů je AES, DES a vylepšený Triple DES nebo Blowfish.

Příloha C

Formáty bankovních výpisů V této příloze je podrobně rozebrána struktura výpisů bank, jejichž import bude implementován.

C.1

Česká spořitelna

Oba formáty České spořitelny jsou soubory typu CSV.

Datový výpis České spořitelny Část týkající se celého výpisu: Řádek 1 2 3 4 5 6 7

Název pole Account number Account currency Statement number Statement date Statement frequency Account name Number of transactions

Typ text text číslo s 2 deset. místy datum YYYY/MM/DD text text číslo

8

Pending transactions

číslo s 2 deset. místy

9 10 11 12 13

Debit (-) Credit Initial balance Final balance

číslo s 2 deset. místy číslo s 2 deset. místy číslo s 2 deset. místy číslo s 2 deset. místy [ prázdný řádek ]

Popis Číslo účtu Měna účtu Číslo výpisu (Koncové) datum Frekvence vyhotovení Jméno účtu Celkový počet transakcí Suma neukončených transakcí Suma odchozích plateb Suma příchozích plateb Počáteční zůstatek Konečný zůstatek

Tabulka C.1: Datový výpis České spořitelny - údaje o celém výpisu

51

52

PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ

Následuje část týkající se transakcí - jedna transakce na řádek: Pořadí 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Název pole Due date Payment Counter-acc. no. Transaction Currency Depreciation date Info on Payment Counter-acc. name Var.symb.1 Bank record Constant symbol Specific symbol Var.symb.2 ISO Amount Currency Transaction ex. Rate Accounts ex. Rate Payment reference Payer code Payee code Koncový znak

Typ datum YYYY/MM/DD text text číslo s 2 deset. místy text datum YYYY/MM/DD text text číslo text číslo číslo číslo číslo s 2 deset. místy text číslo s 2 deset. místy číslo s 2 deset. místy text text text -

Popis Datum splatnosti Systémový popis platby Číslo protiúčtu/kód banky Částka v měně účtu Měna Datum zaúčtování Poznámka o platbě Název protiúčtu Variabilní symbol Označení transakce v bance Konstantní symbol Specifický symbol Variabilní symbol protiúčtu Částka v měně protiúčtu Měna protiúčtu Směnný kurz transakce Směnný kurz účtu Poznámka 2 Označení plátce Označení příjemce

Tabulka C.2: Datový výpis České spořitelny - transakce

Obrázek C.1: Vzorový datový výpis České spořitelny Zdroj: Česká spořitelna

C.2. KOMERČNÍ BANKA

53

Výpis transakční historie České spořitelny Jedné transakci odpovídá jeden řádek výpisu. Pořadí 1 2 3 4 5 6 7 8 9 10 11 12 13

Název pole Položka Valuta zaúčt. Var.symb.2 Částka CZK Bankovní spojení Dat.zprac. Var.symb.1 Storno Název protiúčtu Konst.symb. Spec.symb. Zpráva pro příjemce Referenční číslo

Typ text datum YYYY/MM/DD číslo číslo s 2 deset. místy text datum YYYY/MM/DD číslo text text číslo číslo text číslo

Popis Systémový popis Datum splatnosti Variabilní symbol protiúčtu Částka číslo protiúčtu/kód banky Datum zaúčtování Variabilní symbol Informace o stornu platby Název protiúčtu Konstantní symbol Specifický symbol Zpráva pro příjemce Označení v systému banky

Tabulka C.3: Výpis transakční historie České spořitelny

Obrázek C.2: Vzorový výpis transakční historie České spořitelny Zdroj: Česká spořitelna

C.2

Komerční banka

Komerční banka využívá pro export výpisů vlastní vytvořený formát KB Best.

Formát KB Best

54


Obrázek C.3: Hierarchická struktura formátu KB Best Zdroj: Komerční banka

Obrázek C.4: Formát KB Best - hlavička (HO) a patička (TO) Zdroj: Komerční banka

C.2. KOMERČNÍ BANKA

Obrázek C.5: Formát KB Best - obratová věta 51 (obecné údaje výpisu) Zdroj: Komerční banka

55

56


Obrázek C.6: Formát KB Best - transakční věta 52 nebo 53 (transakce) Zdroj: Komerční banka Věta 53 bude ignorována, protože neobsahuje účetní informace (pohyby na účtu).

C.3. ČESKOSLOVENSKÁ OBCHODNÍ BANKA

Obrázek C.7: Vzorový výpis KB Best Komerční banky Zdroj: Komerční banka

C.3

Československá obchodní banka

Formát transakční historie

Obrázek C.8: Vzorový výpis transakční historie ČSOB Zdroj: ČSOB

57

58


Číslo řádku 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Název pole Informační řádek o výpisu

Hodnota Pohyby na účtu č.: {číslo}, ze dne {čas DD.MM.YYYY H:MM} [ prázdný řádek ] Datum zaúčtování datum zaúčtování: {datum D.M.YYYY} Částka částka: {číslo s 2 deset. místy} Měna měna: {text} Zůstatek na účtu zůstatek: {číslo s 2 deset. místy} Konstantní symbol konstantní symbol: {číslo} Variabilní symbol variabilní symbol: {číslo} Specifický symbol specifický symbol: {číslo} Systémový popis označení operace: {text} Název protiúčtu název protiúčtu: {text} Bankovní spojení protiúčet: {text} Poznámka 1. řádek poznámka: {text} Poznámka 2. řádek {text} [ prázdný řádek ] pro další transakce se opakují řádky 3-15 Tabulka C.4: Formát transakční historie ČSOB Pozn.: značky { typ } označují hodnotu typu typ.

C.4

mBank

Formát transakční historie Formát CSV má sice standardní strukturu, ale položky transakcí jsou zřetězeny v poli popis, což je nevýhodné pro počítačové zpracování.

C.4. MBANK

59

Část týkající se celého výpisu: Interval řádků 1-6 7-9

Popis pole Informace o bance Informace o klientovi Informace o období výpisu

10 - 18

19 - 27

Informace o účtu

Informace o částkách 28 - 34

debetu, kreditu a počátečním zůstatku

35 36 - (35+n) (35+n+1) - (35+n+5)

Konečný zůstatek

Řádek

Hodnota

[ nedůležitá ] {název klienta}; {začátek};{konec}; {datum vyhotovení}; {způsob zasílání}; {typ účtu}; {měna účtu}; {číslo účtu}; {úroková sazba}%; Kred. položky;{počet}; 29 {částka} {měna}; Debet. položky;{počet}; 30 {částka} {měna}; Součet;{počet}; 31 {částka} {měna}; ;;;#Počáteční zůstatek:; 33 {částka} {měna}; Hlavičkový řádek 1 - n transakcí (35+ ;;;#Konečný zůstatek:; n+3) {částka} {měna}; 8 13 15 17 20 22 24 26

Typ {text} 2x {datum} {datum} {text} {text} {text} {text} {deset. číslo} {číslo}{deset. číslo}{text} {číslo}{deset. číslo}{text} {číslo}{deset. číslo}{text} {deset. číslo} {text}

{deset. číslo} {text}

Tabulka C.5: Formát transakční historie mBank - údaje o celém výpisu Pozn.: značky { hodnota } označují název položky na řádku, značky { typ } označují hodnotu typu typ.

60


Následuje část týkající se transakcí - jedna transakce na řádek: Pořadí 1 2

Název pole Datum uskutečnění Datum zaúčtování

Typ datum DD-MM-YYYY datum DD-MM-YYYY

3

Popis transakce

text (zřetězené položky)

4 5

Částka transakce Zůstatek

číslo s 2 deset. místy číslo s 2 deset. místy

Popis Datum splatnosti Datum zaúčtování Systémový popis transakce Poznámka 1 Poznámka 2 Konstantní symbol Variabilní symbol Specifický symbol Název protiúčtu Číslo protiúčtu Kód banky protiúčtu Částka transakce Zůstatek po transakci

Tabulka C.6: Formát transakční historie mBank - transakce Pozn.: Ne všechny položky se musí vždy v popisu transakce vyskytovat, jejich délka také není pevně daná.

Obrázek C.9: Vzorový výpis transakční historie mBank Zdroj: mBank

Příloha D

UML diagramy V této části jsou uvedeny vybrané UML diagramy, které nebyly zařazeny do hlavní části práce z důvodu přehlednosti.

D.1

Vybrané diagramy aktivit

Obrázek D.1: Diagram aktivit - Přihlášení uživatele

61

62

PŘÍLOHA D. UML DIAGRAMY

Obrázek D.2: Diagram aktivit - Spuštění aplikace

D.1. VYBRANÉ DIAGRAMY AKTIVIT

Obrázek D.3: Diagram aktivit - Vytvoření uživatele

63

64


Obrázek D.4: Diagram aktivit - Import výpisů

D.2. SCHÉMA RELAČNÍ DATABÁZE

Obrázek D.5: Diagram aktivit - Filtrování výpisů

D.2 D.2.1

Schéma relační databáze Systémová databáze

Obrázek D.6: Schéma systémové databáze

65

66

D.2.2


Uživatelská databáze

Obrázek D.7: Schéma uživatelské databáze

Příloha E

Grafické uživatelské rozhraní Tato příloha obsahuje několik ukázek grafického uživatelského rozhraní implementované aplikace. Jsou ukázány příklady rozmístění prvků v okně a také jejich různý vzhled podle použitého Look & Feel.

Obrázek E.1: Přihlášení do aplikace Vzhled: Windows

67

68

PŘÍLOHA E. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ

Obrázek E.2: Přehled účtů se zobrazeným oknem úprava účtu Vzhled: Windows

Obrázek E.3: Přehled načtených výpisů a transakcí Vzhled: Windows

69

Obrázek E.4: Filtrování výpisů Vzhled: Metal

70

PŘÍLOHA E. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ

Obrázek E.5: Přehled typů transakcí se zobrazeným oknem úprava typu transakce Vzhled: Nimbus

Obrázek E.6: Import výpisů Vzhled: Nimbus

Příloha F

Uživatelská příručka Systém pro správu bankovních účtů (Bankovní účty) autor: Dominik Mervart červen 2009

1. Úvod Tato uživatelská příručka je určena uživatelům aplikace Bankovní účty a obsahuje rady a postupy pro její ovládání. Aplikace smí být volně šířena pod licencí GNU General Public License.

2. Popis aplikace Bankovní účty jsou aplikací, která slouží k efektivní správě bankovních účtů a umožňuje import a evidenci bankovních výpisů a transakcí, export dat do HTML a CSV a další činnosti. Funkce aplikace: • vytváření a správa více nezávislých uživatelských účtů • evidence bankovních účtů • import textových výpisů stažených ze systému internetového bankovnictví • vyhledávání, filtrování a editace výpisů a jednotlivých transakcí • možnost definovat typy transakcí a přiřadit je k transakcím • export dat do HTML a CSV souboru

71

72

PŘÍLOHA F. UŽIVATELSKÁ PŘÍRUČKA

• statistické informace - aktuální zůstatek na účtu, přehled příjmů a výdajů podle období a typu transakce Vlastnosti aplikace: • aplikace zaručuje bezpečné uložení dat (šifrování, povolení přístupu pouze po zadání hesla) • aplikace je multiplatformní - funguje pod operačními systémy Microsoft Windows, Linux, Solaris, Mac OS X • aplikace se nemusí instalovat, stačí ji spustit, nevyžaduje žádnou dodatečnou konfiguraci systému ani údržbu • složku s aplikací je možné libovolně přemisťovat v rámci počítače i mezi počítači (pouze je nutné dbát na to, aby byly přesunuty všechny soubory a složky) Výhody aplikace oproti online systémům internetového bankovnictví: • správa více bankovních účtů na jednom místě • neomezená doba archivace transakcí - banky archivují transakce jen po omezenou dobu (často pouze několik měsíců) • možnost vyhledávání a filtrování výpisů a transakcí podle různých údajů • export do dalších formátů • statistické informace, přehledy • přenositelnost aplikace, není nutné připojení k internetu • aplikace funguje i na operačních systémech a jejich konfiguracích, na kterých by online bankovnictví nemuselo fungovat Požadavky na systém: • výkon počítače: běžný kancelářský počítač vyrobený po roce 2000 • operační systém: Microsoft Windows 2000, XP, Vista, 7, Linux, Solaris, Mac OS X • nainstalované Java Runtime Environment verze 6, alespoň JRE 6 Update 12 (možno stáhnout zde: http://java.sun.com/javase/downloads/index.jsp)

73

3. Práce s aplikací 3.1. Spuštění aplikace Aplikace je distribuována v archivu RAR. Rozbalte ji nejdříve do libovolné složky některým z běžných archivačních programů (WinRAR, WinZip, Unrar). Aplikace vyžaduje pro svůj běh nainstalované Java Runtime Environment (JRE). Pokud je JRE správně nainstalováno, stačí spustit aplikaci poklepáním na spouštěcí soubor BankovniUcty.jar v hlavním adresáři aplikace. Pokud se nepodaří aplikaci takto spustit, je třeba otevřít příkazový řádek, (ve Windows: Start - Spustit - cmd.exe) a spustit aplikaci příkazem: java -jar cesta/BankovniUcty.jar případně cesta_k_JRE/java -jar cesta/BankovniUcty.jar Aplikace nevyžaduje instalaci ani jinou konfiguraci. Po prvním spuštění aplikace je vytvořena systémová databáze ve složce cesta/databaze/. V případě vzniku chyby nebo varování je podrobnější informace zapsána do logovacího souboru cesta/log.txt.

3.2. Přihlášení a registrace uživatele Po spuštění aplikace uživatel buď vybere své uživatelské jméno, pod kterým se registroval, a zadá heslo pro přihlášení do aplikace, nebo stiskne tlačítko Registrovat a vyplní registrační formulář. Při registraci je každému uživateli vytvořena jeho databáze ve složce cesta/databaze/, která bude obsahovat jeho uživatelská data. Při registraci nemůže uživatel použít jméno „System“. Po úspěšné registraci je přihlášen do aplikace. Odhlásit se z aplikace je možné v menu Administrace -> Odhlásit se. Poté se znovu zobrazí přihlašovací dialog.

3.3. Práce s bankovními účty Aby uživatel mohl importovat výpisy, musí nejdříve vytvořit bankovní účet, ke kterému budou výpisy přiřazeny. Seznam evidovaných bankovních účtů je na záložce Přehled účtů. Přidat nebo upravit účet je možné v menu Účty. V menu Účty je také možné přidat novou banku nebo upravit údaje o stávajících. Při registraci je 9 největších českých bank vytvořeno v systému automaticky.

3.4. Import výpisů V současné době je podporován import výpisů pouze z těchto bank: • Komerční banka - formát KB Best - OKM (v bankovnictví Mojebanka jako volba „Přehledy -> Přehled obratů“ nebo „Přehledy -> Stažení účetních dat“)

74


• Česká spořitelna - formát CSV (v bankovnictví Servis 24 Internetbanking jako volba „Export výpisů -> Datové výpisy“) a formát Transakční historie CSV (v bankovnictví Servis 24 Internetbanking jako volba „Přehled účtů a zůstatků -> Transakční historie“) • ČSOB - formát Transakční historie TXT (v bankovnictví ČSOB InternetBanking 24 jako volba „Informace o účtech -> Pohyby“) • mBank - formát CSV (v bankovnictví jako volba „Moje účty -> Historie transakcí -> Uskutečněné transakce“) Postup při importu Uživatel na záložce Import výpisů vybere účet, pro který chce importovat výpisy. Poté vybere importní soubory a stiskne tlačítko Importovat výpisy do systému. Pokud je mezi výpisy formát Transakční historie České spořitelny, bude uživatel požádán o zadání počátečního zůstatku na účtu na začátku období daného výpisu, protože tato informace ve výpisu není uvedena. Pokud už některý výpis byl dříve do systému naimportován, uživatel na to bude upozorněn a musí potvrdit, zda chce výpis přeskočit nebo ho znovu naimportovat. Po naimportování všech souborů bude zobrazena informace o úspěchu nebo případných chybách.

3.5. Práce s výpisy a transakcemi Na záložce Zobrazení výpisů a transakcí jsou v tabulce Výpisy naimportované výpisy v systému. Při vybrání výpisu se v tabulce Transakce zobrazí odpovídající transakce výpisu (pokud není zapnuto filtrování transakcí). Výpis lze upravit nebo smazat buď z menu Výpisy nebo poklepáním na odpovídající řádek v tabulce Výpisy. Totéž platí pro transakce. Výpisy lze filtrovat podle několika kritérií nebo jejich kombinací, nastavení filtru se provede v menu Výpisy -> Filtrovat výpisy. Zrušení filtru je také v tomto menu. Transakce lze také filtrovat podle několika kritérií nebo jejich kombinací, nastavení filtru se provede v menu Transakce -> Filtrovat transakce. Zrušení filtru je také v tomto menu. Pokud je aktivní filtrování transakcí, tabulky výpisů a transakcí budou nezávislé, tzn. při vybrání výpisu se nezobrazí jeho transakce. Je potřeba zrušit filtr transakcí, aby se obnovilo standardní chování.

3.6. Typy transakcí Transakce je možné snadno rozlišit přiřazením typu transakce. Transakce pak bude mít v tabulce uveden název typu transakce podbarvený nadefinovanou barvou. Typy transakcí je možné přidat, upravit nebo smazat v menu Typy transakcí. Aktuálně definované typy transakcí jsou v tabulce na záložce Typy transakcí a párování. Typ transakce lze transakci přiřadit buď ručně v menu Transakce -> Upravit transakci nebo je možné využít automatického spárování podle klíčových slov. Typ transakce bude k transakci přiřazen, pokud je klíčové slovo obsaženo v některé z těchto položek transakce:

75

• číslo protiúčtu • kód banky protiúčtu • název protiúčtu • variabilní symbol • specifický symbol • poznámka • poznámka 2 • zpráva AV • systémový popis Pokud bylo zadáno k typu transakce klíčové slovo 2, musí být také obsaženo v některé z těchto položek, aby došlo ke spárování. Při porovnávání klíčových slov a položek není brán ohled na velikost písmen. Pokud byl při párování k transakci přiřazen špatný typ, je možné typ u transakce kdykoliv změnit ručně.

3.7. Obecná práce s tabulkami a vstupními poli Při kliknutí pravým tlačítkem na tabulku nebo vstupní pole se zobrazí kontextové menu. V kontextovém menu tabulky je možné zvolit: • Hledání výskytu zadaného textu nebo čísla v tabulce. • Zkopírování označených buněk do schránky. • Vybrání řádku, sloupce nebo všech buněk tabulky. V kontextovém menu vstupního pole je možné zvolit: • Vyjmutí nebo zkopírování textu do schránky. • Vložení textu ze schránky. • Odstranění textu z pole. • Označení textu v poli.

3.8. Export dat Je možné exportovat data v tabulkách Účty, Výpisy, Transakce a Typy transakcí do formátu HTML nebo CSV po zvolení příslušné volby v menu Export.

76


3.9. Nastavení V menu nastavení je možné změnit vzhled programu. Na výběr jsou multiplatformní vzhledy Metal, Nimbus a Motif nebo platformově specifické vzhledy Windows (OS Microsoft Windows) a GTK (OS Linux). Standardní oddělovač použitý při exportu do CSV souboru je možné změnit v menu Nastavení -> Změnit nastavení programu. Pokud se rozhodnete z jakéhokoliv důvodu smazat svůj uživatelský účet v této aplikaci, je tak možné učinit v menu Nastavení -> Změnit nastavení programu. Pozor: celá databáze s daty bude poté smazána!

3.10. Zobrazení nápovědy Tuto uživatelskou příručku je v programu možné zobrazit v menu Nápověda -> Uživatelská příručka nebo stisknutím klávesy F1.

4. Zálohování dat Protože databáze je pouze složka se soubory na disku, je možné ji zálohovat prostým zkopírováním na jiné místo v počítači. Proces obnovy dat je složitější, je nutné provést pečlivě tyto kroky: • Ujistit se, že je uživatel v systému registrován se stejným jménem a heslem. Pokud není, musí se registrovat. Je nutné, aby bylo použito stejné jméno a heslo, protože těmito údaji jsou šifrována data v databázi! • Pokud existuje ve složce cesta/databaze/ složka se stejným názvem jako je přihlašovací jméno uživatele, je nutné ji smazat! • Umístit zálohovanou složku s databází do složky cesta/databaze/. Jméno zálohované složky s databází musí být stejné jako přihlašovací jméno uživatele. Pokud jsou tyto kroky provedeny správně, data mohou být poté po spuštění aplikace a přihlášení uživatele řádně používána.

5. Bezpečnost uživatelských dat Všechna data uživatele v jeho databázi jsou šifrována bezpečným 128-bitovým symetrickým šifrovacím algoritmem AES. Součástí šifrovacího klíče je jméno a heslo uživatele, proto je velmi důležité, aby uživatel své heslo nezapomněl, protože tím by přišel o svá data! Přístup do aplikace je povolen až po správném zadání přihlašovacího jména a hesla. Přihlašovací heslo uživatele není nikde uloženo, nehrozí tedy jeho zneužití. Těmito způsoby ochrany je zajištěno, že data uživatele nemohou být žádným způsobem zneužita nebo zjištěna a pracovat s nimi může pouze jejich vlastník po přihlášení do aplikace.

77

6. Chybová hlášení Pokud dojde v aplikaci k závažné chybě a nelze pokračovat v běhu programu, je zobrazeno okno o tom, že se stala chyba, podrobnější informace je zapsána do logovacího souboru cesta/log.txt a aplikace je ukončena. Pokud není chyba závažná, je pouze zobrazena informace o chybě a je zapsána do logu jako varování, ale program není ukončen. Pokud vznikne neočekávaná běhová (run-time) výjimka způsobená chybou v programu, není zalogována a je na uživateli, aby o ní a okolnostech jejího vzniku dal vědět tvůrci aplikace, aby mohla být opravena.

Možné chybové zprávy a jejich řešení Selhání spuštění databáze. Aplikace už byla spuštěna. V jeden okamžik může v systému běžet pouze jedna instance aplikace. Různé databázové chyby. Došlo k chybě při spojení s databází, ukončete aplikaci a akci zopakujte. Nelze nastavit Look & Feel. Požadovaný vzhled není v této verzi Java Runtime Environment podporován, nainstalujte si prosím aktuální verzi JRE. Nelze číst/zapisovat z nebo do souboru. Nemáte přístupová práva ke čtení nebo zápisu do tohoto souboru nebo je název souboru neplatný. Změňte cestu nebo název souboru. Nelze načíst dokument z JAR archivu. Spouštěcí soubor aplikace byl poškozen, nahraďte ho prosím originálním souborem. Neplatný formát souboru. Při importu došlo k chybě, protože byl rozpoznán neplatný formát souboru. Ujistěte se, že je soubor stejný jako když byl stažen z internetového bankovnictví. Pokud je soubor v pořádku a myslíte si, že jde o chybné chování programu, kontaktujte prosím autora. Nelze spočítat otisk řetězce hešovací funkcí SHA-1. Hešovací funkce SHA-1 není v této verzi Java Runtime Environment podporována, nainstalujte si prosím aktuální verzi JRE. Bez této funkce nebude aplikace fungovat.

78


Příloha G

Obsah přiloženého CD Na přiloženém CD jsou následující soubory a adresáře: - index.html - rozcestník k jednotlivým souborům a složkám na CD - readme.txt - popis obsahu CD a postup spuštění aplikace - text/ - adresář s textem bakalářské práce ve formátu PDF a zdrojový kód LATEX - dist/ - adresář se spustitelným programem a knihovnami - src/ - zdrojové kódy programu - data/ - doplňkové soubory - vypisy/ - příklady výpisů bank - uml/ - UML diagramy a projekt v nástroji Enterprise Architect - html/ - dokumentace - abstrakt/ - český a anglický abstrakt - dokumentace/ - dokumentace zdrojového kódu Javadoc - prirucka/ - text uživatelské příručky

79

Systém pro správu bankovních účtů. Dominik Mervart

Recommend Documents