MASARYKOVA UNIVERZITA,

MASARYKOVA UNIVERZITA, FAKULTA INFORMATIKY

Diplomová práce

Systém pro správu osobních financí

Bc. Martin Habr

Brno, jaro 2012

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování Na tomto místě bych rád poděkoval svému vedoucím práce panu Martinu Jakubičkovi za jeho rady a nápady k této diplomové práci.

Vedoucí práce RNDr. Martin Jakubička 2

Shrnutí Hlavním cílem této práce je návrh a implementace systému pro správu osobních financí. Nejprve je provedena analýza problémové oblasti. Na základě získaných informací je navržen systém, který uživatelům poskytuje nástroje pro správu finančních produktů, rozpočtování a finanční plánování. Systém je implementován formou webové aplikace na platformě .NET. Velký důraz je kladen na zabezpečení osobních údajů.

Klíčová slova osobní finance, finanční plánování, platforma .NET, MVC framework, bezpečnost webových aplikací 3

Obsah 1 Úvod.......................................................................................................................................6 2 Správa osobních financí....................................................................................................8 2.1 Vymezení osobních financí....................................................................................................................8 2.2 Finanční plánování...............................................................................................................................9 2.3 Charakteristika vybraných finančních produktů................................................................................11 2.3.1 Osobní a spořící účet...............................................................................................................11 2.3.2 Stavební spoření.......................................................................................................................11 2.3.3 Penzijní připojištění.................................................................................................................12 2.3.4 Úvěry..........................................................................................................................................13 2.3.5 Ostatní produkty......................................................................................................................13

3 Nástroje pro správu osobních financí...........................................................................14 3.1 eÚčty.cz...............................................................................................................................................14 3.2 Mořefinancí.cz....................................................................................................................................15 3.3 Mint.com.............................................................................................................................................16 3.4 Shrnutí................................................................................................................................................16

4 Analýza a návrh informačních systémů.......................................................................18 4.1 Metodika RUP....................................................................................................................................19 4.2 Životní cyklus projektu.......................................................................................................................21 4.3 Jazyk UML..........................................................................................................................................23 4.4 Nástroje CASE....................................................................................................................................24

5 Analýza a návrh systému Personal Finance.................................................................26 5.1 Specifikace základních požadavků.......................................................................................................27 5.2 Definice požadavků pomocí případů užití..........................................................................................28 5.3 Identifikace zakladních prvků systému a diagram tříd......................................................................31 5.4 Datový model......................................................................................................................................34

6 Implementace systému.....................................................................................................36 6.1 Platforma .NET...................................................................................................................................36 6.2 ASP.NET a MVC 3 framework..........................................................................................................37 6.3 Vývojové prostředí..............................................................................................................................39 6.4 Vrstva Model a persistence dat...........................................................................................................39 6.5 Vrstvy Controller a View.....................................................................................................................43 6.6 Wizards...............................................................................................................................................43 6.7 Import elektronických výpisů z účtu..................................................................................................44 6.8 Internacionalizace a lokalizace............................................................................................................46

7 Bezpečnost webových aplikací.......................................................................................48 4

7.1 Autentizace a autorizace.....................................................................................................................49 7.2 Šifrování dat........................................................................................................................................50 7.3 Cross-site scripting and HTML injection..........................................................................................50 7.4 Cross-site request forgery....................................................................................................................52 7.5 SQL Injection......................................................................................................................................53

8 Možnosti rozšíření systému............................................................................................55 8.1 Rozhraní webových služeb..................................................................................................................55 8.2 Mobilní aplikace..................................................................................................................................57 8.3 Přímé propojení s bankovními systémy..............................................................................................58 8.4 Rozšíření funkcionality pro finanční poradce.....................................................................................59

9 Závěr....................................................................................................................................60 10 Použitá literatura.............................................................................................................61 11 Přílohy...............................................................................................................................63 11.1 Obsah CD..........................................................................................................................................63 11.2 Scénáře pro model případů užití.......................................................................................................63 11.3 Snímky obrazovek systému Personal Finance..................................................................................66

5

1 Úvod Během posledního desetiletí dochází k nebývale rychlému rozvoji v oblasti finančních služeb a paralelně s tím se také mění chování české populace. Tradiční konzervativní postoj ke správě financí střídají tendence k rychlé spotřebě i ochota domácností k zadlužování. Tyto tendence s sebou přináší velké množství rizik a vyvolávají potřebu zlepšení orientace obyvatel ve světě financí. Podle nedávné analýzy provedené Českým statistickým úřadem 1, dluží české domácnosti bankám přes bilion korun. Alarmující je zejména rychlost jakou se domácnosti zadlužují. Od roku 2000 vzrostl celkový dluh dokonce osmkrát. Zvýšené zadlužení se projevuje v počtu rodin, které nejsou schopné dostát svým závazkům a čelí nepříjemným situacím v podobě exekucí. Za hlavní příčinu tohoto negativního vývoje bývá označována nízká finanční gramotnost obyvatel. Pod pojmem finanční gramotnost si lze představit soubor znalostí, dovedností a postojů člověka potřebných pro jeho dostatečné finanční zabezpečení a aktivní vystupování na trhu finančních produktů. Lidé často nemají dostatečný přehled o svých finančních aktivech a transakcích, které s nimi byly provedeny. Velké problémy jim dělá také orientace v nabízených finančních produktech a porozumění principu ceny peněz v čase. Bohužel se neobjevuje mnoho domácností, které by si pravidelně sestavovaly rodinný rozpočet a vedly záznamy o výši a struktuře příjmů a výdajů. Pomocí těchto jednoduchých nástrojů lze přitom získat dostatek informací pro provádění finančního plánování. Pouze touto cestou je možné získat kontrolu nad budoucím směřováním finanční situace jednotlivce, případně celé rodiny. Cílem této práce je navrhnout a implementovat komplexní systém, který bude uživatelům poskytovat užitečné nástroje potřebné při správě osobních financí. Systém bude implementován formou webové aplikace, což umožní uživatelům snadný přístup z jakéhokoli místa. Systém bude umožňovat správu velkého množství finančních produktů a sledování uskutečněných transakcí. Pro účely získání přehledu o aktuální finanční situaci budou poskytovány funkce pro kategorizaci transakcí a vytváření rozpočtů. Důležitou součástí správy osobních 1 http://www.czso.cz/csu/csu.nsf/informace/ckta120310.doc

6

financí je provádění finančního plánování, které bude podporováno nástroji pro vytváření statistik a plánování cílů. V závěru se práce věnuje problematice zabezpečení osobních údajů v rámci webových aplikací. Jsou představeny nejčastější bezpečnostní hrozby a jejich řešení na úrovni vytvářeného systému.

7

2 Správa osobních financí Slovo finance pochází z latinského "finare", které původně znamenalo odsouzení k nějaké platbě podle soudního rozhodnutí, později se stalo označením pro jakoukoliv platbu [1]. Většina lidí si pod slovem finance představí jednoduše peníze. Tento pohled podporuje i definice z finančního slovníku, který na finance nahlíží jako na obor zabývající se penězi, jejich využitím a vztahem k času a riziku [2]. Jako další definici lze uvést například tuto: Finance jsou speciální částí mikroekonomie zabývající se chováním finančních trhů a ohodnocováním (resp. oceňováním) obchodovaných finančních instrumentů [1].

2.1 Vymezení osobních financí Pohled na finance může být značně odlišný v závislosti na tom jak velký ekonomický subjekt je předmětem našeho zkoumání. Z tohoto pohledu můžeme finance rozdělit do následujících čtyř sektorů [1]. Podnikové finance berou jako základní ekonomický subjekt podnik. V souvislosti s fungováním podniku dochází k pohybu peněžních prostředků, kapitálu a ostatních finančních prostředků. Přesunem těchto zdrojů se potom podnik ocitá v různých situacích, na které je potřeba odpovídajícím způsobem reagovat tak, aby mohlo dojít k naplnění jeho základních cílů. Mezi priority každého podniku patří zejména snaha o zajištění dlouhodobé existence a rozvoje, stejně jako maximalizace jeho tržní hodnoty. V případě akciové společnosti lze mluvit o maximalizaci tržní hodnoty akcií. Veřejné finance se zabývají vztahy mezi orgány a institucemi veřejné správy na straně jedné a ostatními ekonomickými subjekty (občané, podniky, neziskové organizace atd.) na straně druhé. Cílem veřejných financí je zabezpečování veřejných statků a naplňování veřejného zájmu. Mezinárodní finance se zabývají tokem finančních prostředků mezi zahraničními subjekty. Jejich základním cílem je vytvořit měnové, úvěrové a platební podmínky umožňující plynulý rozvoj mezinárodní spolupráce.

8

Poslední oblastí a pro účely této práce nejdůležitější jsou osobní finance, které se zabývají pohybem peněz, majetku a zdrojů jeho financování na úrovni jednotlivce případně celé rodiny. Znamená to, že předmětem našeho zájmu bude vůbec nejmenší ekonomický subjekt - člověk. Při utváření finančních rozhodnutí jsou jednotlivci stejně jako podniky motivováni snahou o naplnění svých potřeb a cílů. Často bývá jednou z hlavních priorit snaha o maximalizaci tržní hodnoty majetku a udržení dlouhodobě rostoucí životní úrovně. Přesné vymezení oblasti osobních financí je však s ohledem na subjektivní vnímaní tohoto pojmu velmi složité. Nejlepším způsobem jak si přiblížit tuto problematiku, je hledání odpovědí na následující otázky [3]: •

Jak vysoké jsou měsíční (roční) příjmy moje a mé rodiny? Z čeho se skládají? Jak se bude jejich výše měnit v budoucnosti?

•

Je možné zvýšit moje příjmy? Pokud ano, tak jakým způsobem?

•

Jakým způsobem mohu své příjmy co nejlépe využít?

•

Jak vysoké jsou měsíční (roční) výdaje moje a mé rodiny? Jaká je jejich struktura a jak se bude měnit v budoucnosti?

•

Kolik jsme schopni ušetřit - za měsíc, za rok, za celý život? Jakým způsobem bude pro nás nejlepší zhodnocovat ušetřené finanční prostředky?

•

Jak vysoký je náš majetek a jak vysoké jsou naše závazky? Je možné (výhodné) se ještě více zadlužit? Jsme schopni zvládnout současná i budoucí rizika?

2.2 Finanční plánování Finanční plánování představuje činnost, pomocí které hledáme odpovědi na otázky uvedené v předchozí kapitole. Proces finančního plánování je možné rozdělit do několika fází, které za sebou logicky následují a společně pak tvoří uzavřený kruh [4]. Finanční plánování je tedy jinými slovy kontinuální proces, který nikdy nekončí. Viz obr. 2.1.

9

Obrázek 2.1: Finanční plánování (Zdroj: SOPHIA FINANCE)

Vstupním bodem do celého procesu je fáze analýzy. Před vytvořením vlastního finančního plánu je potřeba zmapovat současnou situaci z několika hledisek. Zejména je nutné zjistit výši a strukturu aktiv, závazků, příjmů a výdajů. V případě, že příjmy převyšují výdaje, dochází k tvorbě zdrojů, prostřednictvím kterých je možné postupně navyšovat majetek. V opačném případě stojí člověk před dlouhodobě neudržitelnou situací, kdy musí hledat nové zdroje příjmů, nebo omezit výdaje tak, aby došlo ke stabilizaci jeho finanční situace. Následujícím krokem je vymezení cílů a potřeb. Dosažení každého cíle by mělo být měřitelné a každému cíli by měl být přiřazen realistický horizont splnění, tj. doba, za kterou ho chceme dosáhnout. V této fázi je třeba si uvědomit, že naše potřeby jsou neomezené, zatímco naše možnosti (zdroje) omezené. Na základě definovaných cílů a provedené analýzy finanční situace může být vytvořen finanční plán, který představuje návrh konkrétních postupů jak daných cílů efektivně dosáhnout. Plán by měl být vytvářen takovým způsobem, aby ho bylo možné v budoucnosti upravovat (např. z důvodu změn ve výší příjmů nebo výdajů). Vytvořený plán je samozřejmě nezbytné následně také realizovat uzavřením smluv na vybrané finanční a pojistné produkty. Tím ale proces finančního plánování zdaleka nekončí. Je totiž velmi důležité pravidelně situaci kontrolovat a analyzovat zda nedošlo k nějakým změnám, které vyžadují úpravy původního plánu. Touto

10

cestou se dostáváme opět na začátek plánovacího procesu a pomyslný kruh se tak uzavírá.

2.3 Charakteristika vybraných finančních produktů Finanční plán jednotlivce obecně obsahuje čtyři základní komponenty - ošetření osobních rizik, plánování nezávislého penzijního věku, plán vzdělání dětí a investiční plán. V současnosti lze na finanční trhu najít mnoho produktů, které nám umožňují řešit jenotlivé oblasti plánování. Důležitou otázkou však zůstává, jaké produkty zvolit do svého portfolia, aby došlo k naplnění našich cílů s ohledem na podstoupené riziko. V následující části práce jsou představeny nejčastěji využívané finanční instrumenty [3]. 2.3.1

Osobní a spořící účet

Běžný účet lze považovat za základní bankovní produkt, který stojí na počátku vztahu mezi klientem a bankou a je často předpokladem pro využití ostatních finančních produktů. Pro účely této práce se budeme zabývat pouze osobním účtem, což je speciální podtyp běžného účtu, který je směřovaný na fyzické osoby nepodnikatele. Jde o účet, zřízený klientem za účelem vkládání volných finančních prostředků a uskutečňování hotovostního i bezhotovostního platebního styku. Běžný účet může být veden v libovolné měně, nejčasteji je však zřizován v oficiální měně daného státu. Pro tento typ účtu je charakteristická nízká úroková sazba, která z něho dělá poměrně nevýhodný produkt pro účely spoření. Tento nedostatek částečně odstraňují spořící účty a úsporné vklady. Vyšší zhodnocení vložených prostředků je však vykoupeno skutečností, že při výběru prostředků z tohoto typu účtu je třeba dodržet výpovědní lhůtu (případně jiné omezení výběru), jinak je klient penalizován poplatky. 2.3.2

Stavební spoření

Stavební spoření patří mezi nejoblíbenější a nejrozšířenější spořící produkty. Jeho obliba pramení zejména ze štědré státní podpory, která z něho dělá prakticky bezkonkurenční způsob zhodnocení peněz (pouze v omezené míře). Vklady klientů jsou spolu se státní podporou úročeny roční úrokovou sazbou kolem 2%. Účastník 11

stavebního spoření nemusí tento produkt využívat pouze pro účely spoření, kompletní produkt totiž zahrnuje i možnost poskytnutí účelového stavebního úvěru (peníze z úvěru mohou být využity pouze za účelem bydlení). V blízké budoucnosti pravděpodobně dojde ke změnám zákona o stavebním spoření 2. Diskutovanou otázkou je především výše a bezúčelovost státní podpory. 2.3.3

Penzijní připojištění

Dalším z vhodných způsobů akumulace a zhodnocení peněz je penzijní připojištění, které tvoří tzv. třetí pilíř chystané důchodové reformy. Nepříznivý demografický vývoj totiž dostává do problémů náš model státního důchodového systému, který je založený na průběžném financování. Aby si občané zajistili dostatečnou životní úroveň i v penzijním věku, mají možnost část svých peněz přesměrovat do penzijních fondů, kde jsou na základě investičního plánu daného fondu zhodnocovány. Navíc jsou na účet penzijního připojištění připisovány státní příspěvky a účastníci spoření mohou čerpat daňové úlevy. Penzijní připojištění je upraveno příslušnou právní normou3.

2 Zákon č. 96/1993 Sb., o stavebním spoření 3 Zákon 42/1994 Sb., o penzijním připojištění se státním příspěvkem

12

2.3.4

Úvěry

Úvěrové produkty představují možnost jak financovat investiční záměry z cizích zdrojů. Úvěrem se myslí dočasně poskytnuté finanční prostředky věřitelem, který po uplynutí sjednané doby (často i v jejím průběhu) inkasuje od dlužníka peněžitou prémii ve formě úroku. Na trhu lze nalézt úvěry úzce specializované pouze na přesně vymezený účel (např. hypotéční úvěr, úvěr ze stavebního spoření), ale i produkty, které nejsou vázané ke konkrétnímu způsobu využití. Pro účely této práce je nejdůležitějším typem úvěr spotřebitelský, jehož příjemcem je fyzická osoba. Obvyklá průměrná výše spotřebitelského úvěru je ve srovnání s podnikatelským podstatně nižší. Poskytovatel spotřebitelského úvěru je ze zákona 4 povinen informovat spotřebitele o úrovni ročních procentních nákladů na úvěr (tzv. RPSN). Výpočet tohoto ukazatele zahrnuje veškeré náklady spojené s daným úvěrem (úrok, poplatky, atd.), klient tak získává možnost jednoduše posoudit výhodnost jednotlivých úvěrů. Jako další úvěrový produkt bude představena hypotéka. Jedná se o dlouhodobý úvěr, jehož splacení je zajištěno zástavním právem k nemovitosti. Získané finanční prostředky jsou většinou účelově vázány ke koupi, výstavbě nebo opravě nemovitosti (s výjimkou tzv. americké hypotéky). Výše hypotéčního úvěru je ovlivněná několika faktory, zejména cenou zástavy a výší disponibilních zdrojů klienta. Doba splatnosti se pohybuje od 5 do 30 let a klient má možnost zaplacené úroky odečíst od základu daně. Bližší informace o hypotéčním úvěru lze opět nalézt v příslušné zákonné normě5. 2.3.5

Ostatní produkty

Uvedené produkty slouží pouze jako přehled nejčastěji využívaných nástrojů pro správu a zhodnocení finančních prostředků v podmínkách České republiky. V investičním portfoliu českých domácností lze nalézt i cenné papíry jako jsou akcie, dluhopisy, indexové certifikáty nebo cenné papíry kolektivního investování. Detailní popis uvedených finančních instrumentů by již přesahoval rámec této práce. 4 Zákon č. 145/2010 Sb., o spotřebitelském úvěru a o změně některých zákonů 5 Zákon č. 190/2004 Sb., o dluhopisech

13

3 Nástroje pro správu osobních financí Mezi základní nástroje používané při aktivním řízení osobních a rodinných financí patří osobní (resp. rodinný) rozpočet a výkaz příjmů a výdajů. Osobní rozpočet si můžeme představit jako souhrn plánovaných příjmů a výdajů jednotlivce za určité období. Výkazem příjmů a výdajů se rozumí souhrn skutečných realizovaných příjmů a výdajů daného jedince za stanovené období [3]. Sestavení rozpočtu není vůbec náročné a stačí k němu pouze tužka a papír. Mnohem vhodnějším způsobem je však využití specializovaného software. Existuje celá řada desktopových aplikací, které slouží pro potřeby domácího účetnictví. Desktopové aplikace, které se instalují přímo na počítač uživatele, s sebou však přinášejí několik nevýhod. Mezi největší patří bezesporu velmi špatná dostupnost. Jediným přístupovým bodem takového systému je totiž pouze počítač na kterém je aplikace nainstalovaná. Uživateli tak chybí především dostatečná pružnost a mobilita. Webové aplikace jsou na rozdíl od těch desktopových dostupné z jakéhokoli zařízení připojeného k internetu a vybaveného webovým prohlížečem. Požadovaná dostupnost však paradoxně přináší další velký problém a tím je nedostatečná bezpečnost dat. Této problematice bude věnována celá kapitola. V následující části práce jsou představeny tři konkrétní webové aplikace pro správu osobních financí.

3.1 eÚčty.cz Aplikace eÚčty.cz6 je v současnosti jednou z nejpropracovanějších nekomerčních služeb pro správu osobních financí v prostředí českého internetu. Systém poskytuje základní funkce pro vedení domácího účetnictví. Uživatel má možnost definovat několik účtů, nad kterými bude evidovat uskutečněné transakce, což mu umožňuje získat přehled o běžném účtu, spořícím účtu nebo třeba penězi pod polštářem. Transakce jsou při vkládání tříděny do různých kategorií, které jsou následně k dispozici jako filtry v přehledu příjmů a výdajů. Správa transakcí je doplněna o 6 Aplikace je dostupná na http://www.eucty.cz

14

možnost importovat výpisy z elektronického bankovnictví (podporována je většina bank působících v ČR). Pokud uživatel používá zejména bezhotovostní platební styk nebo platební karty, dochází díky této funkci k výraznému snížení administrativní náročnosti. Nad rámec základní funkcionality systém disponuje několika zajímavými nástroji, které naleznou uplatnění v různých oblastech správy rodinných financí. Příkladem může být nástroj pro správu hypotéky, evidence automobilů a záručních lhůt.

3.2 Mořefinancí.cz Aplikací jako jsou eÚčty.cz lze na českém internetu nalézt několik. Společným jmenovatelem těchto produktů je zejména to, že se jedná o nekomerční aplikace, jejichž posláním není generovat zisk. Investiční příležitosti v této oblasti se snaží využít projekt Mořefinancí.cz7, který byl zahájen na počátku roku 2011. Jedná se o aplikaci, která je stejně jako ta předchozí dostupná uživatelům zcela zdarma. Narozdíl od nich však přichází s propracovaným obchodním modelem. Zisk bude v budoucnosti generován prostřednictvím provizí nezávislých poradců, kteří budou zpracovávat anonymní poptávku po finančních produktech od uživatelů. O tom, že se jedná o perspektivní projekt svědčí i partnerství společnosti s renomovaným investičním portálem Patria Online8 Z hlediska funkčnosti nepřichází Moře financí oproti dříve zmíněné aplikaci eÚčty.cz s žádnou velkou novinkou. Uživatel má k dispozici správu účtů, kategorizaci transakcí i jednoduché statistiky. Systém předpokládá, že základním zdrojem dat bude import elektronických výpisů bank, tomu odpovídá i množství podporovaných formátů souborů. Velkou výhodou aplikace je samozřejmě již zmíněná možnost vyhledat z nabídky dostupných finančních produktů ten nejvýhodnější a případný zájem o pořízení pak konzultovat s některým z nezávislých finančních poradců. Moře financí nemodeluje oblast osobních financí pouze pomocí virtuálních účtů, ale díky aplikaci pro porovnávání nejlepších nabídek na trhu umožňuje práci 7 Aplikace je dostupná na http://www.more-financi.cz 8 Dostupné na http://www.patria.cz/

15

přímo s konkrétními typy produktů (spořící účet, životní pojištění atd.). Uživatel tak získává mnohem lepší přehled o své skutečné finanční situaci, který mu přílišná abstrakce formou účtů nemohla nabídnout. Protože se jedná o komerční produkt je velká pozornost věnována také dostatečnému zabezpečení osobních informací, na které jsou lidé velice citliví. Provozovatel portálu je registrován u Úřadu pro ochranu osobních údajů. Projekt se i po roce provozu neustále vyvíjí a provozovatelé slibují implementovat řadu nových funkcí.

3.3 Mint.com Jako poslední je uveden nástroj Mint.com9. Jedná se o nejpropracovanější systém, který lze v současné době na trhu najít. Bohužel jeho služby mohou využívat pouze zákazníci v USA a Kanadě. Velkou výhodou aplikace je, že se propojuje přímo s finančními institucemi a stahuje aktuální informace o uživatelem držených produktech. Stačí tedy zadat přihlašovací údaje do bankovních systémů a Mint už zařídí samotný přenos dat. Tento způsob získávání transakčních údajů opět zvyšuje požadavky na bezpečnost osobních informací. Jednotlivé transfery dat od finančních institucí jsou zabezpečené na úrovni daných systémů. Komunikace je navíc jednosměrná, Mint má oprávnění data pouze číst a přes aplikaci tak nemůže přijít požadavek na jakékoli přemístění finančních prostředků. Systém přidává i bezpečnostní prvky jako je například notifikace uživatele při podezřelých pohybech na účtu. Z hlediska funkčnosti Mint nabízí pokročilou kategorizaci transakcí (dostupná je autokategorizační funkce), užitečné plánování cílů a podrobné statistiky. Největší nevýhodou tedy zůstává zaměření výhradně na americký trh.

3.4 Shrnutí Existuje mnoho softwarových nástrojů, které se snaží usnadnit správu osobních a rodinných financí. Většina z nich nabízí dostatečné funkce pro vedení záznamů o příjmech a výdajích a jejich kategorizaci. Problémem zůstává často zbytečná 9 Dostupný na https://www.mint.com

16

abstrakce situace s využitím virtuálních účtů a nedostatečná funkcionalita pro podporu finančního plánování (správa cílů, statistiky). Online nástroje jsou téměř bez výjimky dostupné zdarma a jejich obchodní model (pokud existuje) bývá založen na provizích nezávislých poradců, kteří mohou sytémy využívat pro cílenou nabídku finančních produktů. Rozvinutost amerického finančního sektoru umožňuje vytvořit systém, který se přímo propojuje s bankovními účty uživatele a celý proces správy financí je značně automatizován. V podmínkách České republiky není možné takový model v současné době realizovat, zejména z důvodů neochoty finančních institucí zpřístupnit jejich systémy přes řádně zdokumentované aplikační rozhraní.

17

4 Analýza a návrh informačních systémů Vývoj aplikací a zejména informačních systémů je komplexní proces vyžadující spolupráci odborníků z různých oblastí. Rozdílnost profesí s sebou samozřejmě přináší i odlišný pohled na danou problematiku. Často tak dochází k problémům v komunikaci a výsledný produkt vytvořený vývojářským týmem nemusí plně odpovídat požadavkům a přání zákazníka. Není výjimkou, že zákazník sám neví jak má aplikace vypadat z uživatelského pohledu a nemá ani dostatečně propracovanou a zdokumentovanou její funkční stránku. Z tohoto důvodu byly vytvořeny metodiky pro vývoj software, které se snaží o formalizaci celého procesu tak, aby došlo k rychlému, kvalitnímu a hlavně požadovanému výstupu. Jednou z nejstarších metodik vývoje je tzv. vodopád. Tento přístup postupoval ve vývojových aktivitách přísně sekvenčně. To znamená, že nejprve probíhala kompletní analýza systému, potom kompletní návrh a konečně kódování celé aplikace a její testování [5]. Tento způsob vývoje s sebou přináší mnoho problémů [6]: •

Všechny požadavky na projekt musí být známy už na začátku a výrazně se v průběhu prací nesmí měnit. Sekvenční způsob vývoje totiž neumožňuje jednoduché zakomponování změn.

•

Neefektivní řízení rizik. Není možné identifikovat všechna rizika spojená s projektem. V případě, že dojde k odhalení rizika v některé z pozdějších fází projektu je složité na vzniklou situaci reagovat.

•

O používaných technoligiích je rozhodnuto již ve fázi analýzy. V případě, že implementace požadavků zákazníka není možná nebo je neobvykle složitá vzhledem k vybraným technologiím, je často obtížné použít novou technologii bez změn požadavků.

•

Vzhledem k sekvenční povaze metodiky dochází k nízké efektivitě využívání lidských zdrojů (práci lze velmi obtížně paralelizovat). 18

Výše zmíněné nedostatky vodopádu vedou často k výraznému překročení plánovaného rozpočtu, prodloužení dodací lhůty zákazníkovi nebo v horším případě neúspěchu celého projektu. Snahy o vylepšení způsobu vývoje vedly k vytvoření mnoha nových metodik. Většina z nich se vyznačuje tzv. iterativním (případně přírustkovým) způsobem vývoje. Nové systémy jsou vytvářeny v menších přírustcích, přičemž každý přírustek zahrnuje sadu analytických, návrhových a vývojových aktivit a je zakončen dodáním smysluplné funkční části aplikace [5]. Největší výhodou takového přístupu je fakt, že zákazník velmi rychle dostane částečně funkční prototyp aplikace. Na případné připomínky tak lze reagovat prakticky ihned v další iteraci. Proces vývoje je tím pádem mnohem flexibilnější a umožňuje včas vyhovět měnícím se požadavkům klienta. Návrhy a implementační řešení jsou pravidelně revidovány v souvislosti s rostoucí znalostí o vytvářeném systému. Vzhledem k tomu, že se v každé iteraci vystřídají veškeré aktivity související s návrhem a vývojem projektu, lze celý proces paralelizovat za účelem lepšího využití lidských zdrojů. Konec iterace je důležitým mezníkem každého projektu. Dochází k setkání celého týmu, kde jsou představeny dosažené výsledky i problémy, se kterými se musel tým v průběhu iterace vypořádat. Shromážděné informace umožňují upravit následující přírustek tak, aby vývoj probíhal stále tím nejefektivnějším způsobem. Výhody tohoto přístupu však nesouvisí pouze s řízením projektu. Díky pravidelnému setkávání celého týmu a možnosti přímé účasti zákazníka dochází k posílení týmové spolupráce, která má velký vliv na úspěšnost celého projektu.

4.1 Metodika RUP Rational Unified Process (dále jen RUP) je komerční metodika vývoje software vyvinutá firmou IBM10. Na RUP lze také nahlížet jako na komplexní produkt sestávající z vlastní metodiky a sady pomocných softwarových nástrojů. Celý framework je komponentově orientovaný, takže může být jednoduše konfigurován, redukován nebo naopak rozšířen na základě aktuálních potřeb daného projektu. 10 Více informací na adrese http://www-01.ibm.com/software/awdtools/rup/

19

Historie Rational Unified Process vychází z velké části z metodiky Objectory Process, kterou vytvořil Ivar Jocobson již v roce 1987. Metodika vznikla v rámci švédské firmy Objectory AB a byla postavená na objektovém přístupu, kde silnou roli hrály modely případů užití. Po sloučení s Rational Software Corporation v roce 1995 došlo ke vzniku nové metodiky Rational Objectory Process 4.0. Od roku 1996 používá metodika modelovací jazyk UML, který bude blíže představen v následující kapitole. Verze Rational Unified Process 5.0 obsahuje mnohá zdokonalení v oblasti modelování dat, procesů a řízení projektu. Produkt se neustále vyvíjí a aktuálně lze zakoupit ve verzi 7.5. Metodika RUP je postavena na šesti základních praktikách z oblasti moderního vývoje software [8]:

Iterativní způsob vývoje Vzhledem k již zmíněným nevýhodám lineárního přístupu (vodopád) je RUP založený na iterativním způsobu vývoje. Metodika je tedy dostatečně robustní a dokáže se úspěšně vypořádat s problémem měnících se požadavků. Systém není předán zákazníkovi v jedné dodávce, ale celý proces vývoje je rozdělený do šesti až devíti iterací. Jednotlivé přírustky jsou do systému postupně integrovány.

Správa požadavků Aktivní správa požadavků je systematický proces, který umožňuje lepší kontrolu nad celým vývojem komplexního produktu. Zapojení zákazníka do vývoje dává možnost reagovat na jeho připomínky a zvyšuje požadovanou kvalitu výstupu. Další výhodou tohoto přístupu je redukce nákladů na projekt a zabránění zpoždění dodávky.

Architektura a využití komponentového přístupu Základním posláním počátečních iterací je definovat architekturu aplikace a ověřit její správnost. Iterativní způsob vývoje umožňuje doladit případné nedostatky až v průběhu prací na projektu. Metodika se snaží využít výhod komponentového přístupu. Komponentou se rozumí netriviální část systému (modul, balík, subsystém) s jasně definovanou funkcionalitou. Jedná se vlastně o realizaci abstrakce 20

používané ve fázi návrhu. Izolovanost jednotlivych komponent umožňuje jejich samostatný návrh, vývoj a testování. Rozdělení systému na komponenty tak vytváří prostor k paralelizaci práce.

Modelování a UML Velká část metodiky RUP se věnuje tvorbě modelů. Modely jsou vlastně zjednodušením reality a slouží k lepšímu pochopení problému a hledání jeho řešení. RUP pro modelování používá grafický jazyk UML, pomocí kterého formalizuje tvorbu jednotlivých modelů.

Kvalita procesů a výsledného produktu Z pohledu RUP je kvalita výsledného produktu zodpovědností celého vývojářského týmu. V metodice tedy není uvedena žádná role, která by měla tuto oblast výhradně na starost. Hlavním nástrojem pro zajištění kvality je proces testování.

Konfigurace a řízení změn Důležitou oblastí celého procesu vývoje software je management změn, které přicházejí od zákazníka. V případě, že jsou změny relevantní, musí být řádně zdokumentovány a zakomponovány do systému.

4.2 Životní cyklus projektu Životní cyklus se v Rational Unified Process metodice dělí do čtyř základních fází [7]. Na konci každé fáze je provedeno zhodnocení dosažených výsledků. Projekt může zahájit další fázi pouze v případě, že byly splněny veškeré požadavky té předchozí. Náročnost jednotlivých částí z hlediska množství spotřebovaného času a zdrojů není stejná, ale liší se v závislosti na konkrétním zaměření daného projektu. Životní cyklus projektu a jeho jednotlivé fáze jsou schématicky znázorněny na obrázku 4.1.

21

Obrázek 4.1: Schéma metodiky RUP (Zdroj: http://objekty.vse.cz )

Fáze zahájení (Inception) V první fázi pracují všechny do projektu zainteresované skupiny (management zákazníka, marketing, investoři, systémoví analytici) na vytvoření vize a definování rozsahu působnosti vyvíjeného produktu. Systémový analytik spolu se zaměstnanci zadavatele provede analýzu problémové oblasti a zdokumentuje podnikové procesy, které se dotýkají vytvářeného systému. Na základě schůzek se zástupci zákazníka jsou identifikovány stěžejní funkce systému. Často bývá vytvořen slovník zpracovávané oblasti za účelem udržení konzistence specifikací a vytvářených modelů. Součástí výstupu je také studie uskutečnitelnosti a ekonomické návratnosti, jejichž výsledek je určujícím faktorem pro rozhodnutí zda v projektu pokračovat, nebo ho včas zastavit, aby nedocházelo ke zbytečnému plýtvání zdroji. Pro další řízení projektu je také důležité vytvoření prvního plánu iterací.

22

Fáze přípravy (Elaboration) Cílem této fáze je navrhnout na základě sepsaných klíčových požadavků stabilní model architektury systému. Na výsledné architektuře je potom postaven první funkční prototyp, který je následně předveden zákazníkovi. Jednotlivé analytické modely by měly být již detailně zpracovány, zejména model případů užití a identifikace všech aktérů. Z pohledu projektového řízení dochází ke zpřesnění plánu iterací (tvorba akceptačních kritérií pro jednotlivé iterace) a upravení seznamu rizik.

Fáze konstrukce (Construction) V této fázi by mělo dojít k identifikaci všech požadavků a jejich zapracování do návrhových modelů. Analytické a návrhové modely by měly být již kompletní. Vytvářený systém je řádně otestován, aby mohl být nasazený pro testování u zákazníka. Zákazníkovi je předána první funkční verze vyvíjeného systému. Je vytvořen plán iterací na poslední fázi a plán nasazení.

Fáze předávání (Transition) Poslední fáze má za cíl předání finální verze systému zákazníkovi. Na základě připomínek jsou implementovány drobné úpravy. Největší důraz je kladen na testování systému a odstraňování nalezených defektů. V této fázi již nedochází k žádným zásadním změnám funkcionality. Vytváří se dokumentace a materiály pro zaškolení personálu na straně zákazníka. Úspěšným předáním systému končí vývoj a začíná stádium poinstalační podpory.

4.3 Jazyk UML V části zabývající se metodologií pro vývoj software RUP je zmíněno využívání jazyka UML (Unified Modeling Language) pro tvorbu analytických modelů a diagramů. Jazyk je výsledkem snah o sjednocení různých modelovacích metod a syntaxí. První verze byla vytvořena v roce 1997 pod záštitou firmy Rational a postupně se z ní stal průmyslový standard. Aktuání verze jazyka nese označení UML 2.0.

23

Pomocí UML lze modelovat jednoduché i složité aplikace na základě stejné formální syntaxe [5]. Tato vlastnost umožňuje sdílení analytických a návrhových modelů v rámci celého projektu. Výsledným modelům tedy rozumí nejen architekti, analytici nebo vývojáři, ale jsou dostatečně srozumitelné i pro management a zákazníka. Snižuje se tak riziko, že dojde ke špatné interpretaci dokumentace na různých úrovních vývojářského týmu. Specifikace UML definuje syntax na úrovni jednotlivých modelů. Jedná se vlastně o soubor pravidel pro znázornění tříd, objektů, aktérů, případů užití, aktivit, procesů a vztahů mezi nimi. Množina použitých prvků vždy úzce souvisí s výběrem konkrétního pohledu na modelovaný systém (resp. s výběrem UML diagramu). Důležitou součástí každého modelu je definice jeho sémantiky. Pokud by bylo použité pouze grafické znázornění, výsledný model by často neobsahoval dostatek informací, nebo by mohl být nejednoznačný. Proto UML podporuje i nástroje pro doplnění sémantiky jednotlivým diagramům. Sémantika je většinou zapsána pomocí textové notace. UML dává vývojářům k dispozici celkem 14 diagramů pro modelování různých pohledů na systém. Mohou být rozděleny na základě těchto kritérií [9]: •

Model případů užití - popisuje požadavky na systém z pohledu uživatele. Diagram: diagram případů užití

•

Statické modely - popisují jednotlivé prvky systému a vztahy mezi nimi. Diagramy: diagram tříd, diagram komponent, diagram nasazení

•

Dynamické modely - sledují chování systému v závislosti na čase. Diagramy: diagram aktivit, komunikační diagram, sekvenční diagram, stavový diagram

Výběr použitých diagramů je značně individuální a záleží především na rozsahu a zaměření modelovaného systému. Diagramy využité pro účely této práce jsou detailněji rozebrány v následující kapitole.

4.4 Nástroje CASE Diagramy v jazyce UML je možné vytvářet pomocí běžných kreslících programů. Tento způsob je však zbytečně pracný a neumožňuje plné využití potenciálu UML. Z 24

těchto důvodů existují na trhu objektově orientované nástroje CASE (Computer Aided Software Engineering), které vetšinou nabízejí řadu vylepšení nad rámec základní funkcionality pro tvorbu modelů. CASE nástroje mohou být integrovány s vývojovým prostředím a umožňují například generování částí kódu nebo databázových schémat na základě vytvořených diagramů. Z hlediska týmové spolupráce a sdílení zdrojů v rámci týmu bývají tyto nástroje napojeny na projektové úložiště (tzv. repository pro verzování dokumentů). Na trhu existuje mnoho komerčních produktů např. Rational Rose, PowerDesigner, Enterprise Architect a řada dalších. Pro účely této práce byl zvolen nástroj Visual Paradigm for UML11 (Community Edition), který je poskytován zdarma pro nekomerční užití. Funkcionalita této verze je však značně omezená a aplikace tak byla využita pouze pro tvorbu modelů.

11 Dostupný na http://www.visual-paradigm.com/product/vpuml/

25

5 Analýza a návrh systému Personal Finance Cílem této kapitoly je na základě získaných poznatků z oblasti osobních a rodinných financí provést analýzu a návrh systému, který danou oblast pokrývá. Prvním a pro úspěšnost projektů naprosto klíčový krokem je definice uživatelských požadavků. Této oblasti je potřeba věnovat maximální pozornost, protože na ní závisí téměř všechny další etapy životního cyklu aplikace. Zásadní chyba v této fázi většinou znamená pro projekt velké ztráty lidských i finančních zdrojů. Na první pohled se zdá, že UML poskytuje dostatečný nástroj pro modelování oblasti uživatelských požadavků ve formě diagramu případů užití. To však neplatí vždy. Každý případ užití totiž popisuje jeden způsob (resp. důvod) užití systému z hlediska uživatele. Soubor všech případů užití potom reprezentuje všechny uživatelské funkce, které budoucí systém nabídne [5]. Problémem případů užití je fakt, že jich není možné využít při specifikaci tzv. nefunkčních požadavků. Jako příklad může sloužit požadavek na dodržování standardů komunikace (formáty vstupu, výstupu), kvalitativní stránka systému (rychlost odezvy, množství uživatelů naráz používajících daný systém) nebo využití externích systémů pro implementaci určité funkcionality. Při sbíraní požadavků na vytvoření většího projektu (pro účely této práce není relevantní, ale stojí za zmínku) je třeba správně zvolit do svého týmu zástupce zákazníka, aby byl pohled na systém dostatečně objektivní. Nejlepší způsob je angažovat pracovníky ze všech oblasti podniku. Výstupem první části této kapitoly jsou funkční i nefunkční požadavky na systém doplněné diagramem případu užití. S využitím nashromážděných uživatelských požadavků lze identifikovat jednotlivé části systému a popsat jejich vzájemné vztahy. K tomuto účelu slouží v UML diagramy objektů a tříd, které představují statický pohled na zpracovávanou problematiku. V případě objektově orientovaného přístupu se jedná o velmi důležitý pohled na systém. Objekt je seskupením dat a funkcionality, který má svou identitu, vlastnosti chování a zodpovědnost. Na třídu lze nahlížet jako na předpis pro tvorbu 26

objektu. V průběhu analytických prací jsou identifikovány objekty v problémové oblasti zákazníka (tzv. doména) [5]. Často se pro hledání objektů v doméně projektu používá speciálních technik jako je například metoda brainstormingu 12. Výstupem této části je diagram tříd. Téměř celý proces návrhu a vývoje aplikace dnes probíhá na základě objektově orientovaného přístupu, nicméně drtivá většina datových úložišť je stále implementována pomocí relačních databází. Diagram tříd je tedy potřeba transformovat na datový model pro uložení dat do databáze. Výstupem této části je tedy datový model vytvořený pomocí ER diagramu.

5.1 Specifikace základních požadavků Specifikace základních požadavků je provedena formou narativního popisu. Formální pohled bude prezentován jako součást modelu případů užití. Nefunkční požadavky jsou zachyceny pouze v této části.

Základní požadavky Chci vytvořit informační systém s názvem Personal Finance, který bude uživatelům usnadňovat správu osobních a rodinných financí. Systém bude implementován formou webové aplikace. Anonymním uživatelům bude umožněno pouze vytvoření nového účtu na základě registrace. Registrovaní uživatelé budou mít možnost v systému spravovat většinu svých finančních produktů. Finančním produktem se rozumí osobní účet, spořící účet, stavební spoření, penzijní připojištění, spotřebitelský úvěr nebo hypotéka. Systém může být v budoucnosti rozšířený o nové produkty. Na produkty bude nahlíženo jako na účty, nad kterými jsou zaznamenávány uskutečněné transakce. Transakce bude možné zadávat manuálně nebo importovat z elektronických výpisů. Systém bude podporovat formáty výpisů největších bank v ČR. Systém bude umožňovat hromadné zadávání transakcí. Nad účty bude možné provádět rozpočtování. Rozpočtováním se rozumí řazení uskutečněných transakcí do uživatelem specifikovaných kategorií. Nad těmito kategoriemi budou uživatelé nastavovat limity a sledovat jejich dodržování. Pokud uživatel kategorii při zadávání transakce sám nenastaví, bude použita implicitní. Uživatel bude mít možnost exportovat vybrané transakce do souboru. Systém umožní zadání a správu pravidelných plateb. Pravidelná platba je 12 Více informací o této metodě na http://cs.wikipedia.org/wiki/Brainstorming

27

předpisem, podle kterého budou automaticky generovány transakce. Kromě základních uživatelů budou do systému vstupovat administrátoři a poradci. Administrátor bude mít na starost správu systému, správu uživatelů, přidělování oprávnění a budou mu k dispozici statistiky o systému jako celku. Poradci budou mít možnost editovat přidělené části systému a to zejména šablony produktu. Šablony jsou konkrétní nastavení parametrů určitého finančního produktu. Uživatel bude mít možnost při vytváření produktu vybrat některou z šablon nebo vyplnit informace o produktu ručne. Uživatelům budou k dispozici statistiky příjmů a výdajů. Statistiky budou podporovat filtry podle produktů a časového rozsahu. Systém bude shromažďovat minimum osobních údajů vedoucích k identifikaci uživatele a bude dostatečně zabezpečen. Nebudou zejména ukládány adresy ani čísla účtů. Systém bude lokalizován do češtiny a angličtiny.

5.2 Definice požadavků pomocí případů užití Model případů užití zachycuje požadovanou funkčnost vytvářeného informačního systému. První fází tvorby modelu je specifikování aktérů na základě analýzy firemních procesů. Pojmem aktér se rozumí role, ve které vystupuje uživatel v rámci své komunikace se systémem [5]. Fyzický uživatel nemusí být vázán pouze na jednu roli. Na množinu rolí určitého uživatele je potom možné nahlížet jako na oprávnění dané fyzické osoby užívat definované funkce systému. Jazyk UML využívá pro znázornění aktérů symbol postavičky. Tento způsob značení může být často poněkud zavádějící, protože jako aktér může vystupovat například externí systém. Po identifikaci akterů přichází na řadu nalezení jednotlivých případů užití. Případ užití se definuje jako množina scénářů, které spojuje dohromady společný cíl [5]. Scénářem se v tomto případě myslí sekvence kroků popisujících interakci mezi aktérem a systémem. Případ užití je většinou popsán jedním hlavním scénářem, na který jsou napojené alternativní posloupnosti kroků. Jazyk UML používá pro znázornění případu užití symbol oválu obsahující název daného případu. Přiřazení jednotlivých případů užití akterům je realizováno pomocí spojovacích linek. Kromě těchto vztahů je možné identifikovat také vztahy mezi samotnými případy užití. Prvním z nich je relace <>, která se objevuje tam, kde se opakuje stále stejná část scénáře. Druhým je vztah typu <<extend>>, pomocí kterého se přidává

28

doplňkové chování. A posledním je zobecnění určitého případu užití, které je realizováno pomocí relace generalizace/specializace. Diagram případů užití pro systém Personal Finance se nachází na obrázku 5.1. Aby byl model kompletní, musí být diagram doplněn o popis jednotlivých scénářů. Z důvodů konsistence textu práce je popis případů uveden v příloze.

29

Obrázek 5.1: Diagram případů užití

30

5.3 Identifikace zakladních prvků systému a diagram tříd Objektově orientovaný přístup umožňuje vytvářet systémy, které jsou poskládané z menších stabilních celků (objektů). Objekt je vlastně seskupením dat a funkcionality, který má předobraz v problémové doméně projektu. K identifikaci jednotlivých objektů se využívá různých technik. Pro účely této práce byla použita metoda analýzy podstatných jmen. Základem této metody je zvýraznění podstatných jmen v popisu problémové oblasti (případně je možné využít i narativního popisu zadání). Nalezená podstatná jména následně slouží jako hlavní zdroj informací pro vznikající model tříd. Vzájemný vztah třídy a objektu byl nastíněn již v úvodu této kapitoly. Třída je vlastně šablonou pro vytvoření jednotlivých objektů, která je definována svými atributy (vlastnosti příslušného objektu) a metodami (chování příslušného objektu). Každému atributu je přiřazeno jméno, formát (většinou jsou podporovány základní datové typy objektových vývojových prostředí) a viditelnost. Zatímco atributy slouží k zachycení statické struktury objektové třídy, metody určují chování objektu. Podobně jako atributy jsou i metody definovány jménem, seznamem parametrů a návratovým typem. Této charakteristice se říká signatura metody a musí být v rámci třídy jedinečná [5]. Důležitou součástí modelu tříd je určení jejich vzájemných vztahů. V jazyce UML

lze

nalézt

vztahy

typu

asociace,

kompozice,

agregace

a

generalizace/specializace. Popis jednotlivých detailů diagramu tříd by již přesahoval rámec této práce. V případě nejasností lze využít citované literatury, která posloužila jako základní zdroj při tvorbě modelu. Na obrázku 5.2 je zobrazen diagram tříd pro jádro aplikace Personal Finance. Diagram je doplněn o textový popis základních tříd (viz. Obrázek 5.2).

31

Obrázek 5.2: Diagram tříd

32

Uzivatel Třída Uživatel je reprezentací konkrétního uživatele přistupujícího k systému. Jedná se o základní prvek modelu z hlediska uživatelského přístupu. Uživatel je identifikován jedinečným uživatelským jménem a heslem, které je ukládáno v šifrované podobě. Z důvodů minimalizace informací použitelných k identifikaci osoby uživatele jsou dále ukládány pouze volitelné údaje o křestním jménu, příjmení a emailu.

Role Třída Role je zodpovědná za řízení oprávnění přístupu. Každý uživatel může vystupovat při komunikaci se systémem v několika rolích, které ho opravňují využívat určitou část jeho funkcionality. Role je jednoznačně identifikována svým názvem.

Produkt Třída Produkt je abstrakcí finančního instrumentu. Jedná se tedy o základní prvek funkční stránky systému. Systém nahlíží na produkt jako na účet, nad kterým je možné evidovat uskutečněné transakce. Každému produktu je přiřazen jeho název a typ, kterými je jednoznačně identifikován. Z účetního pohledu jsou důležitou položkou atributy zůstatek na účtu a měna (jedná se o kód měny, ve které je daný produkt veden). Systém navíc ukládá informaci o datu vytvoření produktu. V závislosti na aktuální fázi životního cyklu se může produkt nacházet v několika stavech. Pokud byl produkt založen, ale nebyl ještě aktivován, je status nastaven na created. Status active označuje aktivní produkt, který podporuje veškerou funkcionalitu systému. Uživatel má možnost libovolný produkt ze systému odebrat. Stav takového produktu je nastaven na disabled a systém neumožňuje jeho aktivní správu. Data související s produktem jsou však zachována (zejména transakční historie). Konkrétní produkty (stavební spoření, penzijní připojištění atd.) dědí veškerou funkcionalitu produktu a přidávají navíc atributy sloužící k popisu specifických vlastností daných finančních instrumentů. Tento přístup umožňuje v budoucnosti systém jednoduše rozšířit o nové typy produktů.

33

Transakce Třída Transakce reprezentuje pohyb peněz na účtu (produktu). Objekt nese informace o množství peněz, které bylo přemístěno na účet (případně z účtu), a měně. Každá transakce je opatřena volitelným popisem. Kromě data zaúčtování transakce do systému je možné evidovat i datum uskutečnění vlastní platby. Pole pro datum platby, výši transakce, měnu a popis jsou dostupná na všech výpisech transakční historie sledovaných finančních institucí.

RozpoctovaKategorie Třída RozpoctovaKategorie slouží ke kategorizaci transakcí (rozpočtování). Každá transakce je zařazena do nějaké kategorie. Uživatel má možnost explicitně definovat kategorii při zadávání transakce do systému. Pokud tak neučiní, bude automaticky vybrána základní kategorie. Kategoriím lze kromě názvu přiřadit i typ a limit. Pomocí atributu Typ jsou odlišeny příjmové kategorie (např. Výplata) od výdajových (např. Nákupy). Atribut Limit slouží k definování plánovaného příjmu (pro příjmové kategorie) nebo výdaje (pro výdajové kategorie).

PravidelnaPlatba PravidelnaPlatba slouží jako předpis pro generování pravidelných transakcí. Základní atributy definované nad transakcí (množství, měna, popis) jsou doplněny údaji potřebnými pro automatické generování. Dobu platnosti pravidelné transakce vymezují atributy Zacatek a Konec. Atribut Frekvence určuje frekvenci generování transakcí a nabývá hodnot týdně, měsíčně, čtvrtletně a ročně. Pravidelné transakce jsou generovány vždy po přihlášení uživatele do systému.

5.4 Datový model Informační systémy zpracovávají a ukládají obrovské objemy dat. Proto je nezbytné definovat jak budou informace ukládány a organizovány již v době návrhu systému. Technika datového modelování doplňuje většinu metodologií pro vývoj aplikací z

34

důvodu potřeby transformovat objektový model systému do prostředí relačních databází13. Nejprve bývá vytvořen logický datový model, který je nezávislý na implementaci a není tak potřeba brát v úvahu cílové prostředí. Na jeho základě je následně vytvořen fyzický model, který již zohledňuje konkrétní relační databázi. Pro reprezentaci logického modelu se v době návrhu používají Entitně-Relační diagramy doplňené o popis sémantiky entit a jejich vazeb. Fyzický datový model již bývá znázorněn pomocí konkrétních tabulek, sloupců a klíčů. V procesu převodu logického modelu na fyzický je často použita technika normalizace. Normalizace je proces založený na přesných matematických pravidlech, který slouží ke sdružení dat do optimálních skupin, vyřešení nejednoznačností, odstranění redundance a zefektivnění výsledného schématu. V době návrhu systému Personal Finance bylo rozhodnuto, že při implementaci bude využit tzv. Code first přístup, který umožňuje vyvíjet systémy bez nutnosti pracovat přímo s určitou databází. Na základě již navrženého diagramu tříd jsou vytvořeny třídy reprezentující tzv. POCO objekty (Plain Old CLR Objects). Tyto třídy se omezují pouze na definici atributů, vztahů, dědičnosti a případně dalších omezení z hlediska persistence dat (k tomuto účelu se využívá tzv. anotací). Databázové schéma je následně automaticky generováno Entity Frameworkem přímo z kódu. Tento přístup má mnoho výhod a bude blíže představen v kapitole, která se zabývá implementací systému Personal Finance. Z důvodu použití výše zmíněného přístupu, nebyl v analytické části práce vytvářen samostatný datový model.

13 Největší výrobci databázových strojů (Oracle, Informix, Sybase) investovali nemalé finanční prostředky do vývoje objektových databází. Většina systémů je však stále implemetována pomocí relačních databází.

35

6 Implementace systému Webová aplikace je aplikace typu klient-server, která používá webový prohlížeč jako klientský program a poskytuje interaktivní služby připojením k serverům přes počítačovou síť internet (intranet). Snadná dostupnost a udržovatelnost jsou hlavními důvody, proč je tato architektura použita pro implementaci mnoha informačních systémů. Základy webových aplikací stojí zejména na síťových protokolech HTTP, FTP, SMTP a značkovacím jazyku HTML. Při vývoji webových aplikací lze použít mnoho technologií a nástrojů, které tyto nízkoúrovňové prvky zapouzdřují a před vývojářem skrývají. Mnoho systémů je implementováno s využitím skriptovacích jazyků jako PHP nebo Perl. Právě zmíněný jazyk PHP je jedním z nejrozšířenějších nástrojů pro tvorbu webových aplikací. Důkazem jeho síly je fakt, že jsou v něm implementovány i velké internetové projekty typu Wikipedia nebo Facebook 14. Skriptovací jazyky s sebou však přináší mnoho nevýhod např. nižší výkon, špatnou škálovatelnost nebo neudržovatelný kód. Tyto nevýhody částečně odstraňují robustní technologie postavené na platformách JAVA nebo .NET.

6.1 Platforma .NET Pro implementaci aplikace Personal Finance byla vybrána platforma .NET. Jádrem celé platformy je rozhraní .NET Framework, které podporuje vytváření a spouštění aplikací a XML webových služeb. Rozhraní je navrženo tak, aby splňovalo tyto cíle [11]: •

Poskytnout konzistentní objektovně orientované programovací prostředí

•

Poskytnout prostředí pro zpracování kódu, které minimalizuje konflikty nasazení a správy verzí softwaru.

•

Poskytnout prostředí pro zpracování kódu, které eliminuje výkonostní problémy skriptovaných nebo interpretovaných prostředí.

14 http://en.wikipedia.org/wiki/PHP

36

•

Činit vývojářské zkušenosti konzistentními napříč nejrůznějšími typy aplikací, jako jsou například aplikace určené pro systém Windows nebo webové aplikace.

•

Vytvářet veškerou komunikaci na průmyslových standardech, aby se zajistilo to, že kód založený na rozhraní .NET Framework lze integrovat s jakýmkoliv jiným kódem.

Rozhraní .NET Framework je možné rozdělit na dva důležité celky: modul CLR a knihovnu tříd .NET Framework. Modul CLR (Common Language Runtime) si lze představit jako agenta, který spravuje kód v době jeho provádění. Jedná se vlastně o virtuální stroj, který kompiluje tzv. mezikód CIL (Common Intermediate Language) přímo na spustitelné instrukce cílové platformy. V tomto procesu je využito technologie JIT (Just-In-Time) kompilace, která umožňuje výsledný nativní kód optimalizovat pro cílovou platformu a výrazně ho tak zrychlit. Modul CLR zajišťuje základní služby jako je správa paměti, správa vláken, správa výjimek a striktní kontrola datových typů. Druhou hlavní komponentou .NET Frameworku je knihovna tříd, která představuje kolekci všeobecných, opakovaně použitelných typů a tříd, potřebných při vývoji aplikací. Knihovna tříd umožňuje vytvářet aplikace pro příkazovou řádku, aplikace s vlastním grafickým rozhraním, webové aplikace nebo XML webové služby. Platforma .NET nepředepisuje použití konkrétního programovacího jazyka, protože kód je kompilátorem vždy přeložen do mezijazyka Common Intermediate Language. Tato architektura poskytuje vývojářům možnost využít velkého množství objektově orientovaných programovacích jazyků splňujících příslušné normy. Jedním z nejpoužívanějších jazyků je C Sharp (C#) , který byl vyvinutý firmou Microsoft zároveň s platformou .NET. Jedná se o vysokoúrovňový jazyk založený na jazycích C++ a Java.

6.2 ASP.NET a MVC 3 framework Prakticky již od vzniku platformy .NET je její součástí i ASP.NET framework určený pro vývoj webových aplikací [12]. V prvních verzích mohli vývojáři využít pouze 37

komponentového přístupu, který nabízela technologie Web Forms. Microsoft chtěl pomocí komponentového přístupu zakrýt bezstavovou povahu protokolu HTTP. Jeho hlavní myšlenkou bylo vytvořit pro vývojáře podobné prostředí, jako používají při programování aplikací pro windows. Tento přístup však nebyl dostatečně flexibilní a nedokázal držet krok s aktuálními trendy v oblasti vývoje webových aplikací. Jedním z velkých problémů technologie Web Forms byla nemožnost vytváření automatických testů. Tento nedostatek neumožňoval využití populárních agilních metodik vývoje, které jsou založené na tzv. Test Driven Developement (vývoj řízený testy). Microsoft vyslyšel přání vývojářů a rozhodl se vytvořil alternativu pro komerčně velmi úspěšné Web Forms. Vznikl tak ASP.NET MVC framework vycházející z architektury MVC (Model-View-Controller). Tato architektura rozděluje aplikaci do tří nezávislých vrstev: •

Model - doménová vrstva - představuje data, s nimiž aplikace pracuje

•

View - pohledová vrstva - stará se o zobrazení dat z modelu uživateli

•

Controller - řadič - na základě uživatelského vstupu z pohledové vrstvy zajišťuje změny v modelu.

Cyklus MVC aplikace začíná zpracováním uživatelského vstupu na jehož základě jsou změněna data v modelu a uživateli je zobrazen aktualizovaný pohled. Tento přístup je v souladu s chováním protokolu HTTP, který je založen na principu požadavek/odpověď. Vývojáři tak nejsou svázáni implementací komponent, ale mají plnou kontrolu nad komunikací mezi serverem a webovým prohlížečem. Rozdělení aplikace na 3 nezávislé vrstvy přináší možnosti pro vytváření automatických testů, tím MVC framework odstraňuje jednu z hlavních nevýhod svého předchůdce Web Forms a umožňuje tak použití metodiky vývoje řízeného testy. Výsledné aplikace jsou také díky rozdělení zodpovědnosti kódu mnohem lépe udržovatelné. V této souvislosti je důležité zmínit, že výsledný HTML kód je jednoduchý, čistý a zejména validní. Tato vlastnost umožňuje na pohledové vrstvě snadné využití technologií jako Css Layouts nebo jQuery.

38

6.3 Vývojové prostředí Pro vývoj webových aplikací je nezbytné nainstalovat a nakonfigurovat řadu nástrojů. Základní komponenty jsou .NET framework, vývojové prostředí, databázový a webový server. Microsoft poskytuje vývojářům webový nástroj Webplatform Installer15, který usnadňuje instalaci a konfiguraci celého prostředí. Jednotlivé komponenty jsou dostupné v různých verzích a liší se zejména ve funkční výbavě (s tou samozřejmě souvisí i cena). Pro účely této práce byla vybrána edice Express, která je k dispozici zcela zdarma i pro komerční využití. Základem balíčku je vývojové prostředí Visual Web Developer Express, zaměřené přímo na vývoj webových aplikací. Kromě kompilátoru a textového editoru nabízí mnoho užitečných funkcí např. debugger (lze připojit k již běžícímu procesu), nástroj pro práci s SQL databázovým serverem, validátory pro Javascript a značkovací jazyky nebo nástroj IntelliSense pro kompletaci textu. SQL Server Express vznikl také odlehčením placené verze. Kromě základní funkcionality SQL serveru je k dispozici grafické rozhraní pro administrativu a dotazování. Nevýhodou jsou nastavené limity, které omezují jeho použití pouze pro malé projekty (např. velikost databáze je maximálne 4GB a může běžet pouze na jednom procesoru). Visual Studio má v sobě integrovaný webový server, který ale neobsahuje velké množství funkcí (chybí například podpora SSL). Je proto výhodné nainstalovat Express verzi webového serveru IIS (Internet Information Services).

6.4 Vrstva Model a persistence dat Pro implementaci datové vrstvy byla vybrána metoda Code First [13]. Metoda umožňuje automatické vytvoření databázového schématu přímo z entitních tříd. Tyto třídy se označují jako POCO (Plain Old CLR Object), protože neobsahují žádnou logiku a nesou pouze informace nezbytné pro tvorbu modelu jako jsou atributy a vazby na ostatní třídy. Příkladem mohou být zjednodušené třídy Role a User využívané aplikací Personal Finance pro reprezentaci uživatelů a řízení přístupových práv.

15 http://www.microsoft.com/web/downloads/platform.aspx

39

public class Role { public virtual [Required] public virtual public virtual public virtual } public class User { public virtual [Required] public virtual [Required] public virtual public virtual }

Guid Id { get; set; } string RoleName { get; set; } string Description { get; set; } ICollection<User> Users { get; set; }

Guid Id { get; set; } String Username { get; set; } String Password { get; set; } ICollection Roles { get; set; }

modelBuilder.Entity().HasRequired(p => p.User) .WithMany(u => u.Products) .HasForeignKey(p => p.UserId) .WillCascadeOnDelete(true);

S POCO objekty pracuje knihovna Entity framework .NET, která má na starost objektově-relační mapování. Entity framework převádí data z doménového objektu do tabulky v databázi a zpět. Tento proces však není jednoduchý a vyžaduje specifikaci mapovacích pravidel, které bývají často uloženy ve speciálním XML souboru. Výsledkem takového přístupu je často nepřehledný kód, protože pravidla jsou uložena mimo kód tříd a bývá jich velké množství. Entity framework .NET však využívá metody konvence nad konfigurací, která předpokládá standardní chování, pokud programátor nespecifikuje jinak. Entity framework tak například sám pozná, že má namapovat atribut Id třídy Role na sloupec Id tabulky Roles a definovat tento sloupec jako primární klíč. Vyskytují se však i případy, kdy nám konvence z nějakého důvodu nevyhovuje, nebo je potřeba specifikovat komplexnější mapovací pravidlo. Pro tyto účely se využívá tzv. anotací, které představují rozšíření programovacího jazyka o možnost přidat atributům, metodám nebo typům dodatečná metadata. Příkladem může být anotace [Required], která oznamuje Entity frameworku, že příslušný sloupec v databázové tabulce Users bude mít omezení NOT NULL (jeho hodnota musí být vždy definována). Používání anotací je jednoduché a hlavně přehledné, protože je přímo součástí kódu třídy. Existují i mapovací pravidla, která jsou natolik 40

komplexní, že je není možné zapsat pomocí anotací. V takovém případě je nutné využít tzv. Fluent API, které přepisuje pravidla aplikovaná na základě konvencí. Nejčastěji se toto rozhraní používá při definování vztahů mezi objekty (kardinalita vazeb, referenční integrita). Pravidla zapsaná pomocí Fluent API se nachází v metodě OnModelCreating příslušného DBContextu (třída určená pro přístup k datům). Entitní třídy, konvence a explicitně definovaná mapovací pravidla pomocí anotací a Fluent API umožňují plně popsat datovou vrstvu aplikace. Entity framework při prvním spuštění systému zjistí, že na SQL serveru zatím neexistuje databáze pro daný model a v případě, že jsou mapovací pravidla správně utvořená (nedochází k žádným kolizím), vygeneruje celé databázové schéma.

Obrázek 6.1: Příklad vygenerovaného schématu

Pro dotazování nad daty se používá třída DbContext, která pro každou entitu vrací objekt typu DbSet implementující rozhraní IQueryable. Toto rozhraní umožňuje využití obecného dotazovacího jazyka LINQ (Language Integrated Query) [14], který byl představen spolu s .NET Frameworkem 3.5. LINQ byl navržen tak, aby byl využitelný pro práci s různým typem dat. Mezi jeho nejdůležitější implementace patří: •

LINQ To Objects - Manipulace s kolekcemi objektů

•

LINQ To SQL - Manipulace s daty v relační databázi

•

LINQ To DataSet - Manipulace s daty uloženými v ADO.NET datasetech

•

LINQ To XML - Manipulace s XML daty

Ze syntaktického hlediska je LINQ velmi podobný jazyku SQL a nabízí také většinu jeho funkcionality. Pro zápis příkazů je možné zvolit i úspornější formu s využitím 41

lambda výrazů. Jako praktický příklad použití je uveden výběr aktivních produktů daného uživatele, který je seřazen sestupně podle typu produktu a výběr transakcí podle uživatele a časového rozmezí. var sortedProducts = from p in user.Products where p.Active orderby p.Type descending select p; var transactions = _db.Transactions .Where(p => p.UserId == userId) .Where(p => p.PayDate >= model.DateSince && p.PayDate <= model.DateUntil) .ToList();

Většina aplikací založených na třívrstvé architektuře často implementuje návrhový vzor Repository pattern [15]. Tento přístup spočívá ve vytvoření rozhraní nad doménovou vrstvou, které umožňuje generický přistup k doménovým objektům. Vzor je zaváděn zejména z důvodů minimalizace redundace dotazů nad doménovými objekty. Na vyšších vrstvách (v případě MVC aplikace zejména na vrstvě Controller) lze repository jednoduše nahradit implementací, která místo databázového úložiště používá data uložená v operační paměti, což umožňuje snadné vytvoření unit testů. Z důvodů velkého využívání Repository pattern mezi vývojáři existuje mnoho návodů jak zavést podobnou abstrakci i v prostředí ASP.NET [16]. V případě využití entity frameworku a třídy DBContext pro přístup k doménovým objektům je však implementace vzoru nadbytečná. DBContext se totiž chová stejně jako Repository a výsledkem by tak místo výše zmíněných výhod byla pouze duplicita kódu. Vrstva model představuje data, která jsou předávána pohledové vrstvě. Na úrovni modelu není vhodné používat přímo entitní třídy. Mnohem lepší přístup je vytvořit speciální třídu, která bude reprezentovat pouze data potřebná ke zobrazení na dané stránce (v této souvislosti se objevuje termín ViewModel). V entitních třídách jsou uvedeny informace potřebné pro datovou vrstvu (anotace se používají k definici databázového schématu), zatímco v modelových třídách je možné specifikovat údaje pro pohledovou vrstvu jako jsou validační pravidla nebo formát zobrazení. Nevýhodou tohoto přístupu je nutnost přemapovávat modelovou třídu na entitní před každým použitím databáze. Pro usnadnění práce lze využít funkcí 42

knihovny Automapper, která umožňuje definování pravidel pro automatické mapování mezi objekty.

6.5 Vrstvy Controller a View Vrstva Controller je v MVC Frameworku zodpovědá za zpracování příchozího požadavku, provádění operací nad doménovými objekty a vybírání pohledu, který bude uživateli prezentován jako odpověď. Základním prvkem této vrstvy je třída Controller, která implementuje všechna potřebná rozhraní. Aplikace Personal Finance rozšiřuje tuto třídu o funkce pro správu aktuálně přihlášeného uživatele a získávání informací o HTTP požadavku. Plnou kontrolu nad protokolem HTTP umožňuje třída ControllerContext. Pro vytváření modelů potřebuje Controller přístup k instanci třídy DBContext. Aby nedošlo k vytvoření pevné vazby mezi těmito vrstvami, obsahuje každý Controller pouze referenci na rozhraní typu IDBContext. Konkrétní instance třídy DBContext je přiřazena až v době inicializace objektu. Tento přístup využívá návrhového vzoru Dependency injection [17]. Pro implementaci vzoru v aplikaci Personal finance byla využita knihovna StructureMap 16. Striktní oddělení obou vrstev umožňuje vytváření automatických testů na úrovni vrstvy Controller. Pohledová vrstva je v MVC 3 Frameworku implementována standardně s využitím nového systému Razor [12]. Kvůli zpětné kompatibilitě je však stále podporována i možnost psát pohledy ve formě ASPX stránek. Pro účely aplikace Personal Finance byl zvolen systém Razor, zejména kvůli přehlednější syntaxi a podpoře šablon.

6.6 Wizards Uživatelské rozhraní aplikace musí být navrženo tak, aby bylo maximálně přehledné a intuitivní. Toto pravidlo platí samozřejmě i pro webové aplikace. Často je potřeba, aby uživatel zadal větší množství údajů, které není možné zobrazit na jediné stránce bez potřeby jejího posunování. Vhodným řešením takové situace je rozdělení údajů do několika menších vzájemně propojených stránek (kroků). Uživatel potom 16 http://docs.structuremap.net/

43

zobrazuje jednotlivé kroky pomocí navigačních tlačítek (v anglické literatuře je tato struktura označována termínem wizards). Tento přístup mimo jiné umožňuje validovat uživatelský vstup na úrovni jednotlivých kroků a uživatel tak může opravovat případné chyby již v průběhu vyplňování údajů (nemusí čekat až na odeslání formuláře). Zadávání velkého množství dat bývá také časově náročné, zejména když se musí jednotlivé údaje zjišťovat a ověřovat z několika různých zdrojů. V takovém případě je vhodné dát uživateli možnost celý formulář uložit a k jeho vyplňování se vrátit později. V aplikaci Personal Finance je tento přístup implementován pro vytváření nového produktu. Model formuláře, který slouží pro zachycení informací o konkrétním produktu, je navázán na třídu WizardSession (viz. Obrázek 6.2). Tato třída obsahuje data potřebná pro návrat uživatele k vyplňování formuláře.

Obrázek 6.2: Databázové schéma WizardSession

6.7 Import elektronických výpisů z účtu V kapitole zabývající se identifikací uživatelských požadavků pomocí případů užití byl definován scénář pro import transakční historie z elektronických výpisů největších bank v ČR. Při implementaci tohoto požadavku musel být vyřešen problém s různorodostí formátů souborů poskytovaných jednotlivými bankami. Většina účetních a e-banking systému alespoň částečně implementuje formát ABO [20], který je standardem ČNB17 určeným pro výměnu finančních zpráv mezi 17 Česká národní banka - http://www.cnb.cz

44

bankami. Standard definuje elektronický výpis z účtu jako prostý datový soubor v textovém formátu. Nevýhodou tohoto formátu je pevná délka jednotlivých polí, což působí zejména v případě textového popisu transakce jako značně limitující faktor. Formát souboru neslouží pouze k přenosu informací o transakční historii, ale definuje také příkaz k úhradě. Vzhledem k výše zmíněným nedostatkům formátu ABO a jeho různé implementaci e-banking systémy byly zvoleny alternativní formáty výpisů pro největší banky v ČR. Systém Personal Finance obsahuje zatím jen parsery pro soubory dostupné v systémech České spořitelny a ČSOB.

ČSOB Služba ČSOB Internet banking umožňuje export výpisu v textovém formátu TXT. Funkce je v systému dostupná pod volbou Informace o účtech -> Pohyby. Soubor neobsahuje veškeré informace, které lze nalézt na standardním výpisu z účtu, nicméně pro potřeby aplikace Personal finance jsou uvedené údaje plně dostačující. Příklad výpisu: datum zaúčtování: částka: měna: zůstatek: konstantní symbol: variabilní symbol: specifický symbol: označení operace: název protiúčtu: protiúčet: poznámka:

2.2.2012 -500.00 CZK 15000.00 0000 000000000 000000000 Transakce platební kartou Částka: 300 CZK 29.01.2012 Místo: BRNO

Česká spořitelna Funkce exportu transakční historie do soubroru je dostupná pod volbou Přehled účtů a zůstatků -> Transakční historie. Výstupem je zjednodušený výpis ve formátu CSV (pole jsou oddělené středníkem a mají libovolnou délku).

45

Příklad výpisu: 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 Platba kartou;19.2.2012;111111;-500;11111111/111;19.2.2012;111111;;;;;;1682 TP k úhradě;18.2.2012;222222;-6000;22222222/222;18.2.2012;222222;;Jan Novák;;;Nájem;1723

6.8 Internacionalizace a lokalizace Pojmem internacionalizace se rozumí jednorázový proces návrhu či úpravy aplikace tak, aby byla schopna pracovat v jazykovém a kulturním prostředí uživatele. Jinými slovy jde o vyvíjení programu tak, aby ho bylo možné bez zásahu do zdrojového kódu

lokalizovat,

tj.

přizpůsobit

konkrétním

národním

zvyklostem

[18].

Internacializované aplikace se vyznačují umístěním textů a obrázků do externích souborů, které mohou být následně lokalizovány do různých jazyků i osobami bez programátorských zkušeností. Platforma .NET je navržena tak, aby umožňovala vývoj aplikací pro různá jazyková a kulturní prostředí. Záznam o aktuálním prosředí je v .NET aplikacích uchovaný ve třídě Thread.CurrentThread.CurrentUICulture a může být kdykoli manuálně změněn. Pro formát data a kód měny aktuálního prostředí je využívána třída CurrentCulture. Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US"); Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");

Změny těchto hodnot by však neměly být prováděné manuálně. Aplikace většinou sama určí vhodné prostředí v závislosti na nastavení počítače (.NET Frameworku) na kterém běží. V případě webových aplikací (aplikací typu klient-server obecně) je situace

odlišná.

Uživatel

přistupuje

na

server

pomocí

klientské

aplikace

(internetového prohlížeče) a systém by měl nastavit kulturní prostředí podle ní. Internetové prohlížeče ohlašují jazykové nastavení na straně klienta v hlavičce Accept-Languages HTTP požadavku.

46

GET http://www.google.com HTTP/1.1 Connection: keep-alive Cache-Control: max-age=0 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8

K tomu, aby .NET Framework správně nastavil aktuální kulturní prostředí podle údajů z HTTP požadavku, je potřeba modifikovat konfigurační soubor web.config [19]. <system.web>

Lokalizovaná data (texty, obrázky, ikony) jsou uložena v externích souborech, tzv. zdrojích (Resources). Tyto soubory mají hierarchickou strukturu podle úrovně specializace na konkrétní kulturní prostředí. Jména souborů odpovídají schématu Název_zdroje[.jazyk[.země]].resx. PersonalFinanceResources.cs.CZ.resx PersonalFinanceResources.cs.resx PersonalFinanceResources.resx

Zdrojové soubory obsahují seznam dvojic klíč, hodnota. Klíče identifikují konkrétní zdroj (text, obrázek) a jsou stejné ve všech resx souborech. Hodnoty obsahují lokalizovaná data pro dané prostředí. V kódu programu jsou uvedeny pouze odkazy na klíče a aplikace podle aktuálního nastavení zjistí, jaký soubor zdrojů má použít. Postupuje se při tom hierarchicky od nejvíc specifického souboru. Aplikace Personal Finance byla navržena a implementována s ohledem na práci v různých kulturních prostředích. Oblast osobních financí je však pro jednotlivé země poměrně specifická. Finanční trh nabízí odlišné finanční produkty, nebo se podstatně liší jejich parametry (státní podpora atd.). Ačkoli je aplikace Personal Finance v tomto směru zaměřena plně na český trh, je lokalizována také do anglického prostředí.

47

7 Bezpečnost webových aplikací V současnosti jsou téměř všechny podnikové aplikace řešeny na bázi klient/server, kde klientem je internetový prohlížeč. Hlavní výhodou této architektury je snadný přístup do systému prakticky z jakéhokoli místa. V souvislosti s otevřením firemních systémů směrem do internetu se však objevují bezpečnostní hrozby, na které musí být webové aplikace připraveny. Základním cílem z hlediska bezpečnosti je ochránit citlivá data před zneužitím nepovolanými osobami. Definovat bezpečnost webových aplikací pouze protřednictvím snahy o zachování důvěrnosti dat by však bylo krátkozraké. Mnohem lépe situaci vystihuje statistika deseti největších hrozeb v oblasti bezpečnosti webových aplikací vytvořená v rámci projektu OWASP (Open Web Application Security Project18) [21]: 1. Injection 2. Cross Site Scripting 3. Broken Authentication and Session Management 4. Insecure Direct Object References 5. Cross Site Request Forgery 6. Security Misconfiguration 7. Insecure Cryptographic storage 8. Failure to Restrict URL Access 9. Insufficient Transport Layer Protection 10. Unvalidated Redirects and Forwards Z uvedeného seznamu je zřejmé, že bezpečnostní problémy musí být řešeny na všech vrstvách aplikace (prezentační, aplikační, datová) i z pohledu infrastruktury (webové servery, databáze, síťové prvky). V této kapitole jsou nejprve představeny základní bezpečnostní mechanismy jako autentizace uživatelů, ověření přístupových práv v 18 OWASP je název projektu zabývajícího se oblastí bezpečnosti webových aplikací. V rámci projektu došlo k vytvoření komunity lidí, neziskových organizací a korporací, která produkuje články, dokumenty, metodologie a nástroje pro zvýšení bezpečnosti webu.

48

rámci systému a vytvoření šifrovaného spojení na transportní vrstvě. Druhá část se věnuje nejčastějším typům útoků na webové aplikace. Po seznámení s principem útoku je popsáno řešení implementované aplikací Personal Finance.

7.1 Autentizace a autorizace Z hlediska bezpečnosti jsou pro systém nejdůležitější procesy autentizace a autorizace. Tyto dva pojmy však bývají velmi často chybně interpretovány. Komunikace uživatele se systémem začíná fází autentizace, kdy je ověřena jeho identita. Na úspěšnou autentizaci navazuje určení množiny funkcí, které je uživatel oprávněn v systému využívat. Autorizace je tedy kontrola, zda může daný uživatel přistupovat k určité části systému. Platforma .NET nabízí dva způsoby autentizace [12]. Základní volbou po vytvoření nového projektu ve Visual Studiu je tzv. Windows Authentication. Tento způsob je určený pro intranetové aplikace, protože využívá funkce pro správu uživatelů a oprávnění v systému Windows (např. Active Directory). V případě webové aplikace je třeba využít druhé možnosti, kterou je metoda Forms Authentication. Základem této metody je objekt FormsAuthenticationTicket, který obsahuje informace o identitě přihlášeného uživatele. Objekt je uložen v zašifrované podobě v Cookies prohlížeče (případně je posílán v hlavičce HTTP požadavku). Vzhledem k tomu, že autentizační informace jsou zašifrované a digitálně podepsané, není možné je při případném odposlechu komunikace číst ani modifikovat. Nastavení autentizační metody je uloženo v souboru Web.config.

Atribut loginUrl určuje adresu, na kterou je přesměrovaný prohlížeč při zpracování neautentizovaného požadavku. Pro správu uživatelů a rolí používá .NET Framework třídy MemberShipProvider a RoleProvider. Jejich základní implementace však neumožňuje využívat vlastní třídy pro ukládání informací o uživateli. Z tohoto důvodu byly pro účely aplikace Personal Finance implementováni poskytovatelé, kteří využívají entit User a Role a dávají tak aplikaci plnou kontrolu nad správou

49

uživatelů. Nastavení vlastních poskytovatelů je uloženo opět v konfiguračním souboru Web.config. Oprávnění přístupu jsou v MVC Frameworku přidělována pomocí filtru [Auhorize] na úrovni controlleru nebo jeho akcí. Filter [Authorize] umožňuje přístupovat k dané funkcionalitě pouze autentizovanému uživateli. Výčtem rolí lze potom omezit oprávnění pouze na určitou skupinu uživatelů. Následující příklad ukazuje controller, ke kterému mohou přistupovat pouze autentizovaní uživatelé. Oprávnění pro akci ShowStatistics je přiděleno pouze administratorům. [Authorize] public class StatisticController{ public ActionResult Index(){ return View(); }

}

[Authorize(Roles="admin")] public ActionResult ShowStatistics(){ return View(); }

7.2 Šifrování dat Protokol HTTP přenáší veškerá data ve formě prostého textu. Proto vznikla jeho nadstavba HTTPS, která využívá protokol SSL (Secure Socket Layer) pro šifrování přenosu a autentizaci komunikujících stran. V případě transportu citlivých informací (jméno, heslo, autentizační cookie) by se měl vždy používat šifrovaný kanál. Použití protokolu

HTTPS

lze

v

MVC

Frameworku

vynutit

uvedením

atributu

[RequireHttps], který se podobně jako v případě autorizace nastavuje na úrovni controllerů nebo jednotlivých akcí. Protože SSL spojení je vytvořeno mezi serverem a webovým prohlížečem, je nutné provést konfiguraci IIS serveru včetně importu SSL certifikátů [22].

7.3 Cross-site scripting and HTML injection Cross-site scripting je jednou z nejrozšířenějších bezpečnostních slabin webových aplikací. Tato metoda je známá již několik let a je detailně popsána například v CERT dokumentaci [23]. Princip útoku je založený na vložení nebezpečného kódu

50

napsaného v klientském skriptovacím jazyce (nejčastěji se jedná o javascript) do obsahu stránky. Spuštěním vloženého kódu získá útočník přístup ke kontextu webové aplikace a může tak manipulovat s cookies nebo objektovým modelem stránky. Existují dva druhy útoku [12]: •

•

Persistent - útočníkovi se podaří uložit škodlivý kód přímo do databáze (například jeho vložením do komentáře pod stránkou). Pokud uživatel přistoupí na stránku zobrazující uložené informace, dojde ke spuštění nebezpečného kódu. Nonpersistent - škodlivý kód je vložen do HTTP požadavku na stránku nejčastěji formou GET parametru v URL. Ke spuštění kódu dojde v případě, že stránka tento parametr nějakým způsobem zobrazuje (například v nadpisu).

Příklad útoku na MVC aplikaci je demonstrován na části kódu stránky, která generuje hypertextový odkaz na základě hodnoty předané z modelu: Continue shopping

Útočník může do takové stránky vložit nebezpečný kód pomocí vhodně zapsaného požadavku: http://yoursite/Cart/Index? returnUrl="+onmousemove="alert('MaliciousInput!')"+style="position:absolute ;left:0;top:0;width:100%;height:100%;

Ochrana proti Cross-site scripting útokům spočívá zejména v důsledné kontrole uživatelského vstupu a příchozích požadavků. MVC Framework je navržen a implementován tak, aby výše zmíněnému útoku zabránil. Razor view engine totiž implicitně převádí hodnoty uvozené znakem @ na bezpečný HTML kód (např: znak < je převeden na >). Podobným způsobem je ošetřen i požadavek na stránku. MVC Framework jednoduše zablokuje veškeré požadavky obsahující potenciálně nebezpečný kód. Takové chování však často vede k zamítnutí validního požadavku. Z tohoto důvodu je umožněno implicitní kontroly vypnout uvedením atributu [ValidateInput(false)] na úrovni controlleru nebo jednotlivých akcí.

51

7.4 Cross-site request forgery Druhým a často přehlíženým typem aktivního útoku na webovou aplikaci je Crosssite request forgery. Jeho princip lze nejlépe demonstrovat na příkladu stránky, která umožňuje přihlášeným uživatelům spravovat jejich profil přes

UserProfileController

controller [12]: public class UserProfileController : Controller { public ViewResult Edit() { var userProfile = GetExistingUserProfile(); return View(userProfile); } [HttpPost] public ActionResult Edit(string email, string hobby) { var userProfile = GetExistingUserProfile(); userProfile.Email = email; SaveUserProfile(userProfile); return RedirectToAction("Index", "Home"); } }

Uživatel nejprve přistoupí k bezparametrické akci Edit(), která vrátí stránku obsahující formulář s detailem jeho profilu. Po vyplnění a odeslání formuláře je zavolána HTTP metodou POST akce

Edit(string email, string hobby),

která uloží

informace o profilu do databáze. Uvedený kód není napadnutelný útokem typu Cross-site scripting. Útočník však může donutit uživatele, aby v rámci stejné instance webového prohlížeče navštívil stránku s následujícím kódem:

Pro přihlášeného uživatele má webový prohlížeč uloženo jeho autentizační cookie. Systém nepozná, že se jedná o podvrženou stránku a po odeslání formuláře data zpracuje stejným způsobem, jako by je odeslal sám uživatel (celá instance webového prohlížeče je v tuto chvíli autentizovaná). MVC Framework poskytuje nástroj, který umožňuje výše zmíněnému útoku zabránit. Do kódu stránky je vložena kostrukce Html.AntiForgeryToken(), která zajistí 52

vytvoření skrytého formulářového pole s názvem _RequestVerificationToken. Zároveň se v prohlížeči uloží i stejně pojmenované cookie. Následně jsou obě hodnoty na úrovni controlleru testovány na shodu. Princip této metody je založený na neschopnosti útočníka získat hodnotu uloženého cookie.

7.5 SQL Injection Jako poslední je představen pravděpodobně nejznámější typ útoku tzv. SQL Injection. Jeho princip spočívá v nedostatečném ošetření uživatelského vstupu a propojení aplikační a datové vrstvy. Pro snadné pochopení je vše demonstrováno na jednoduchém příkladu [12]: [HttpPost] public ActionResult LogIn(string username, string password) { string sql = string.Format( "SELECT 1 FROM [Users] WHERE Username='{0}' AND Password='{1}'",username,password);

}

DataTable results = MyDatabase.ExecuteCommand(new SqlCommand(sql)); if (results.Rows.Count > 0) { return RedirectToAction("Index", "Home"); } else { return RedirectToAction("LoginPrompt"); }

Utočník se může pokusit vložit do pole pro heslo následující kus kódu "OR 1=1;". Díky změněné podmínce vrátí databázový dotaz požadované údaje i bez znalosti správného jména a hesla. Způsobem jak podobnému útoku zabránit je použití parametrizovaného dotazu: string query = "SELECT 1 FROM [Users] WHERE Username=@username AND Password=@pwd"; SqlCommand command = new SqlCommand(query); command.Parameters.Add("@username", SqlDbType.NVarChar, 50).Value = username; command.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = password; DataTable results = MyDatabase.ExecuteCommand(command);

Parametry jsou uloženy mimo vlastní SQL dotaz, což umožňuje při jejich vyhodnocení provést silnou typovou kontrolu a ošetřit textové řetězce nahrazením nebezpečných znaků.

53

Aplikace Personal Finance využívá mezi doménovou a datovou vrstvou entitně relační mapování. Entity framework vytváří vždy parametrizované dotazy, které aplikaci chrání před popsaným typem útoku.

54

8 Možnosti rozšíření systému Vytvořený systém Personal Finance může sloužit uživatelům jako výkonný pomocník při správě jejich osobních financí. Před jeho nasazením do produčního prostředí však musí být provedeno důkladné testování z pohledu funkcionality a zabezpečení osobních údajů. Systém byl vyvíjen od úplného počátku jako součást diplomové práce, což se stalo hlavním limitujícím faktorem pro množství odvedené práce. V budoucnosti snad dojde k rozšíření vývojářského týmu, což umožní projektu v krátké době dosáhnout cíle ve formě kompletního produktu pro správu financí. Systém je navržen a implementován způsobem umožňujícím jeho rozšíření o množství nových funkcí, které by uživatelé od podobné aplikace očekávali. V oblasti webových aplikací je velmi důležitý vzhled uživatelského rozhraní, který má přilákat potenciální zájemce o nabízené služby. Lze tedy očekávat, že střídmý a praktický design aplikace dozná v budoucnu velkých změn. Z hlediska funkcionality musí dojít zejména k podpoře většího množství elektronických výpisů, které jsou hlavním zdrojem dat od uživatelů. Systém by v případě spoléhání na manualní zadávání uskutečněných transakcí pravděpodobně nedosáhl velkého úspěchu. Dalším krokem by mělo být rozšíření statistických funkcí o nové grafy schopné predikovat vývoj peněžních toků v budoucnosti. Statistické nástroje totiž odlišují systém od běžných programů pro vedení účetnictví. Popsaná vylepšení vychází z implementované funkcionality, kterou v podstatě jen rozšiřují. Při analyzování možností, kam múže budoucí vývoj systému směřovat, bylo identifikováno několik oblastí, které jsou blíže popsány v následující části kapitoly.

8.1 Rozhraní webových služeb Jedním z velkých nedostatků systému Personal Finance je jeho značná izolovanost. K systému lze v současné podobě přistupovat pouze prostřednictvím webového rozhraní, což je značně limitující faktor. V budoucnosti se mohou vyskytnout požadavky na propojení aplikace se systémy třetích stran, které budou vyžadovat zpřístupnění funkcionality prostřednictvím oboustranné komunikace. Příkladem 55

může být mobilní aplikace, přes kterou by uživatelé zadávali transakce ihned po jejich uskutečnění, nebo internetové bankovnictví nabízející funkci automatického stahování výpisu z účtu. Webové služby představují způsob jak umožnit spolupráci mezi externími systémy vytvořením standardizovaného rozhraní. Existují dvě běžné architektury pro implementaci webových služeb: služby založené na protokolu SOAP (Simple Object Access Protocol) a služby založené na modelu REST (Representational State Transfer) [24]. Obě architektury se opírají o protokol HTTP a schéma adres používané na internetu. V této práci je blíže představen pouze protokol SOAP, který využívá tzv. procedurálního přístupu. Hlavní rozdíl oproti běžné desktopové aplikaci spočívá v tom, že procedury běží na vzdáleném webovém serveru. Klientská aplikace využívá popsaného rozhraní pro zasílaní XML zpráv, které obsahují název volané funkce (webové služby) a popis vstupních parametrů. Server následně posílá odpověď ve formě XML zprávy obsahující návratovou hodnotu funkce. Formát vyměňovaných zpráv je definován v dokumentech určených pro popis webových služeb prostřednictvím standardizovaného jazyka WSDL (Web Services Description Language). V závěru této části je uveden příklad jak může vypadat zpráva od klienta, který se dotazuje na zůstatek na účtu určitého produktu: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <productID>16789

56

Odpovědí webového serveru by mohla být zpráva: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> 20000 <currency>CZK

8.2 Mobilní aplikace V oblasti komunikací se v posledních letech dostávají do popředí tzv. chytré mobilní telefony, které poskytují uživatelům pokročilé funkce jako například přehrávání hudby, videohovory a připojení k internetu. Jádrem mobilních telefonů jsou výkonné operační systémy, které umožňují tvorbu vlastních aplikací. Z pohledu budoucího vývoje systému Personal Finance se tak otevírá možnost pro vytvoření klienta, přes kterého by uživatelé snadno spravovali své osobní finance prakticky z jakéhokoli místa.

Problémem

v

této

oblasti

bylo

vždy

velké

množství

vzájemně

nekompatibilních operačních systémů. V současné době však většinu trhu pokrývají platformy Android a iOS, což značně ulehčuje situaci vývojářúm. V případě, že by došlo k rozhodnutí o vytvoření nového mobilního klienta, přednost by pravděpodobně dostala platforma Android. Velkou výhodou tohoto systému jsou zejména malé finanční náklady spojené s vývojem aplikací a cenová dostupnost koncových zařízení. Platforma je vyvíjena jako open source produkt pod záštitou konsorcia firem Open Handset Alliance19. Platforma v sobě zahrnuje operační systém založený na linuxovém jádru, které poskytuje služby pro správu paměti, správu sítí, správu procesů a nechybí ani zabudované ovladače pro hardware [25]. Aplikace pro Android jsou vyvíjeny v jazyce JAVA, pro který byly vytvořeny vlastní implementace běhového prostředí Dalvik a knihoven tříd (platforma Java ME není využita z licenčních důvodů). Jazyk Java představuje další výhodu Androidu v porovnání s

19 http://www.openhandsetalliance.com/

57

konkurencí, protože pro něj existuje velké množství open source nástrojů pro podporu vývoje (Netbeans, Eclipse). Podmínkou pro implementaci mobilního klienta je vytvoření rozhraní, které by mu umožňovalo se systémem Personal Finance komunikovat. K tomuto účelu mohou sloužit výše zmíněné webové služby.

8.3 Přímé propojení s bankovními systémy Manuální nahrávání bankovních výpisů není z pohledu běžného uživatele ideální prostředek pro komunikaci se systémem. Očekávaným požadavkem v této oblasti je tedy automatizace celého procesu. Uživatelé by mohli uvést přihlašovací údaje do svých bankovních systémů a aplikace Personal Finance by automaticky stáhla nové výpisy transakční historie (podobnou funkcionalitu nabízí aplikace Mint, bohužel pouze v USA). Implementace tohoto řešení by však s sebou přinášela mnoho problémů. Velkou roli by opět hrála otázka zabezpečení citlivých informací. V tomto případě jde zejména o ochranu proti zneužití autentizačních údajů pro vlastní bankovní systémy, které umožňují přímou manipulaci s finančními prostředky uživatelů. Aplikace Personal Finance by musela splňovat přísná bezpečnostní kriteria včetně získání certifikace uznávanou autoritou, což by přinášelo nemalé finanční náklady. Vlastní implementace by narážela zejména na neexistenci rozhraní pro komunikaci se systémy elektronického bankovnictví. Jediným způsobem, jak tuto situaci řešit, je přímá simulace interakce s uživatelem. K tomuto účelu lze na platformě .NET využít knihovnu WebClient [26], která poskytuje metody pro správu HTTP spojení, včetně autentizace a správy cookies. Knihovna je však určena zejména pro stahování internetových zdrojů (webové stránky, soubory). Překonat robustní autentizační metody bankovních systémů, jako je nahrávání certifikátů nebo autentizace přes GSM formou SMS, je touto cestou prakticky nerealizovatelné.

58

8.4 Rozšíření funkcionality pro finanční poradce Velký prostor pro budoucí rozšíření představuje oblast finančního poradenství. V současné implementaci je role poradce spojená s rolí administrátora a dostupné funkce jsou omezené pouze na správu šablon a jednoduché statistiky počtu registrovaných uživatelů. Po fyzickém oddělení těchto rolí bude možné rozšířit podporu systému v oblasti finančního poradenství. Uživatelé budou moci explicitně povolit přístup finančních poradců ke statistikám a konkrétním parametrům jejich finančních produktů. Ověření nezávislí poradci potom budou na základě dostupných údajů poskytovat nabídky výhodných finančních produktů ušitých klientům tzv. na míru. Implementace finančních poradců bude umožňovat vytvoření obchodního modelu, který bude založený na poplatcích z provizí při uzavření smlouvy o zprostředkování finančního produktu klientovi. Podobnou obchodní strategii implementuje portál Moře financí.

59

9 Závěr Cílem této práce bylo navrhnout a implementovat systém, který poskytuje uživatelům nástroje pro správu osobních financí. V úvodní části práce byla provedena analýza oblasti osobních financí, na základě které byl vymezen rozsah požadavků na vytvářený systém. Po představení metodologie RUP pro vývoj aplikací byl vytvořen návrh informačního systému, který dostal název Personal Finance. Systém byl navržen tak, aby uživatelům poskytoval základní nástroje pro správu finančních produktů a pomáhal jim při finančním plánování. K systému mají kromě základních uživatelů přístup ještě administrátoři a finanční poradci. Koncept finančních poradců umožňuje v budoucnosti vytvořit obchodní model založený na provizích ze sjednaných smluv. Při návrhu systému byl kladen důraz na možnost jeho rozšíření o podporu nových finančních produktů. Aplikace Personal Finance je implementována na platformě .NET s využitím nejmodernějších nástrojů. Výhodou zvolené platformy je její robustnost, která umožňuje budoucí rozšíření do podoby komplexního systému. Implementační část práce se zabývá specifickými prvky platformy .NET a vytvářeného systému. Podrobně je také zpracována kapitola o bezpečnosti webových aplikací, kde lze nalézt konkrétní způsoby řešení bezpečnostní problémů systémem Personal Finance (resp. platformou .NET). Z důvodu chystaného pokračování ve vývoji jsou v závěru představeny základní možnosti budoucího rozšíření systému. Vytvořený systém splňuje většinu požadavků, které na něj byly od počátku kladeny. Na rozdíl od ostatních systémů na českém trhu se snaží poskytnout komplexní pohled na správu osobních financí. Stěžejní funkcionalitu nad rámec běžné evidence výdajů představují nástroje pro správu cílů a statistické ukazatele. Velký přínos je možné očekávat od implementace podpory pro finanční poradce. Zhodnocení úspěšnosti celého systému bude možné udělat až na základě pilotního provozu. Do té doby je třeba provést serii detailních testů zejména v oblasti zabezpečení osobních údajů.

60

10 Použitá literatura [1]: [2]: [3]: [4]: [5]: [6]: [7]: [8]: [9]:

[10]: [11]: [12]: [13]:

[14]:

[15]: [16]:

SVOBODA, Martin. Základy financí. 1. vyd. Brno: Masarykova univerzita, 2009, 195 s. ISBN 978-802-1049-765. Farlex Financial Dictionary. [online]. [cit. 2012-04-30]. Dostupné z: http://financial-dictionary.thefreedictionary.com/finance MÁLEK, Petr, Gabriela OŠKRDALOVÁ a Petr VALOUCH. Osobní finance. 1. vyd. Brno: Masarykova univerzita, 2010, 203 s. ISBN 978-802-1051-577. SYROVÝ, Petr, Gabriela OŠKRDALOVÁ a Petr VALOUCH. Osobní a rodinné finance. 2. aktualiz. vyd. Praha: Grada, 2005, 176 s. ISBN 80-247-1098-6. KANISOVÁ, Hana a Miroslav MÜLLER. UML srozumitelně. 2. aktualiz. vyd. Brno: Computer Press, 2006, 176 s. ISBN 80-251-1083-4. JULINEK, Pavel. Použití RUP pro malé SW projekty. Brno, 2008. Diplomová práce. Masarykova univerzita. Vedoucí práce Jaroslav Ráček. ALDORF, Filip. Metodika RUP [online]. [cit. 2007-04-11]. Dostupné z: http://objekty.vse.cz/Objekty/RUP KRUCHTEN, Philippe. The rational unified process: an introduction. 2nd ed. Reading, MA: Addison-Wesley, 2000, 298 s. ISBN 02-017-0710-1. POOLEY, Perdita Stevens with Rob. Using UML: software engineering with objects and components. 2nd ed. Harlow, Angleterre: Addison-Wesley, 2006. ISBN 03-212-6967-5. KRUCHTEN, Philippe. The rational unified process: an introduction. 2nd ed. Reading, MA: Addison-Wesley, 2000, 298 s. ISBN 02-017-0710-1. Vývoj na platformě .NET [online]. 2012 [cit. 2012-05-13]. Dostupné z: http://msdn.microsoft.com/cs-cz/library/zw4w595w ADAM FREEMAN, Steven Sanderson. Pro Asp.net MVC 3 framework. 3rd ed. New York: Apress. ISBN 978-143-0234-050. Code-First Development with Entity Framework 4. [online]. [cit. 2012-05-15]. Dostupné z: http://weblogs.asp.net/scottgu/archive/2010/07/16/code-firstdevelopment-with-entity-framework-4.aspx ADAM FREEMAN AND JOSEPH C. RATTZ, Adam Freeman and Joseph C.Jr a Technical reviewer: Fabio Claudio FERRACCHIATI. Pro LINQ language integrated query in C♯ 2010. New York: Apress, 2010. ISBN 978-1-4302-2654-3. HIEATT, Edward. Repository. [online]. [cit. 2012-05-19]. Dostupné z: http://martinfowler.com/eaaCatalog/repository.html Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC 61

[17]:

[18]: [19]:

[20]:

[21]: [22]:

[23]:

[24]: [25]: [26]:

Application. [online]. [cit. 2012-05-19]. Dostupné z: http://www.asp.net/mvc/tutorials/getting-started-with-ef-usingmvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-netmvc-application FOWLER, Martin. Inversion of Control Containers and the Dependency Injection pattern. [online]. [cit. 2012-05-19]. Dostupné z: http://martinfowler.com/articles/injection.html KRPATA, Jan. Tvorba webových aplikací pomocí komponentně orientovaného rámce. Brno, 2008. Diplomová práce. Masarykova univerzita. HANSELMAN, Scott. Globalization, Internationalization and Localization in ASP.NET MVC 3. [online]. [cit. 2012-05-20]. Dostupné z: http://www.hanselman.com/blog/GlobalizationInternationalizationAndLocali zationInASPNETMVC3JavaScriptAndJQueryPart1.aspx Technický popis struktury ABO formátu pro programátory. [online]. [cit. 201205-20]. Dostupné z: http://www.csas.cz/banka/content/inet/internet/cs/ABO_format.pdf Top 10 2010. [online]. [cit. 2012-05-20]. Dostupné z: https://www.owasp.org/index.php/Top_10_2010-Main HANSELMAN, Scott. Working with SSL at Development Time is easier with IISExpress. [online]. [cit. 2012-05-21]. Dostupné z: http://www.hanselman.com/blog/WorkingWithSSLAtDevelopmentTimeIsEasi erWithIISExpress.aspx CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests. [online]. [cit. 2012-05-22]. Dostupné z: http://www.cert.org/advisories/CA-2000-02.html SHARP, John. Microsoft Visual C# 2010: krok za krokem. Vyd. 1. Brno: Computer Press, 2010, 696 s. ISBN 978-80-251-3147-3. MEIER, Reto. Professional Android application development. Indianapolis, IN: Wiley, 2009. ISBN 978-047-0344-712. C# WebClient Tutorial. [online]. [cit. 2012-05-26]. Dostupné z: http://www.dotnetperls.com/webclient

62

11 Přílohy 11.1 Obsah CD •

Zdrojový kód vytvořeného systému

•

Příklady elektronických výpisů pro ČSOB a Českou spořitelnu

•

Elektronická verze diplomové práce ve formátu PDF

11.2 Scénáře pro model případů užití Základní uživatel •

Rozpočtování - Rozpočtováním se myslí řazení transakcí do různých kategorií. Součástí rozpočtování jsou případy vytvoření kategorie, definice limitu a editace kategorie.

•

Vytvoření kategorie - Uživatel zvolí název nové kategorie a uvede její typ (příjmová/výdajová). Po odeslání formuláře je vytvořená kategorie ihned dostupná.

•

Definice limitu - Pro danou kategorii uživatel nastaví sledovaný limit. Limit se projeví ve statistikách příjmů a výdajů.

•

Editace kategorie - Parametry uložených kategorií je možné změnit.

•

Správa transakcí - Uživatel bude mít možnost spravovat proběhlé transakce nad jednotlivými účty. Součástí správy transakcí jsou případy vytvoření transakce, zařazení do kategorie a editace transakce.

•

Vytvoření transakce - Uživatel vybere produkt a vyplní údaje o částce, měně a kategorii transakce. Po přidání platby je možné v zadávání pokračovat. Po odeslání transakcí je zobrazen jejich editovatelný přehled. Po potvrzení jsou transakce vloženy do systému.

•

Zařazení do kategorie - Uživatel má možnost zařadit transakci do příslušné kategorie. V případě že tak neučiní bude automaticky zvolena implicitní kategorie.

63

•

Editace transakce - Parametry uložených transakcí je možné v budoucnu změnit.

•

Správa produktů - Uživatel má možnost spravovat své finanční produkty. Součástí správy jsou případy definování parametrů produktu, odebrání produktu, vytvoření produktu, uložení formuláře, editace parametrů, pokračování v editaci a vyrovnání stavu.

•

Definování parametrů produktu - Uživatel v průběhu vytváření/editace produktu definuje parametry daného typu produktu.

•

Odebrání produktu - Uživatel může vybraný produkt odebrat. Odebráním se nesmažou údaje o transakční historii. Dojde pouze k deaktivaci daného produktu.

•

Vytvoření produktu - Uživatel má možnost vybrat typ nového produktu. Na základě typu je mu umožněno vyplnit příslušné parametry produktu. Po odeslání formuláře je vytvořen aktivní produkt. Uživatel má možnost v průběhu vyplňování formulář uložit.

•

Uložení formuláře - Uživatel může v průběhu vytváření produktu formulář uložit.

•

Editace parametrů - Uživatel má možnost editovat parametry již vytvořeného produktu. Uživatelské rozhraní bude stejné jako v případě vytváření produktu.

•

Vyrovnání stavu - Uživatel má možnost vyrovnat stav účtu na vybraném produktu k aktuálnímu datu. Systém vytvoří speciální transakci, která dorovná stav na definovanou hodnotu.

•

Pokračování v editaci - Uživatel má možnost dokončit vyplňování uloženého formuláře a jeho odesláním vytvořit nový produkt.

•

Import výpisu z účtu - Uživatel má možnost importovat výpis z bankovního účtu. Prvním krokem je definování cesty k souboru výpisu, výběr formátu souboru a implicitní kategorie. V případě úspěšného zpracování souboru může uživatel nahrané transakce editovat. Teprve po odeslání budou transakce fyzicky vloženy do systému.

64

•

Export transakční historie - Uživatel bude mít možnost exportovat transakční historii do souboru typu CSV. Transakce lze filtrovat na základě výběru produktu a časového rozmezí.

•

Prohlížení statistik - Uživatel bude mít možnost generovat statistiky o své finanční situaci. Zejména mu bude přístupný graf historie zůstatků na účtech a graf příjmů a výdajů podle rozpočtových kategorií

•

Správa cílů - Uživatel má možnost definovat cílovou hodnotu na vybraném produktu a datum kdy má být cíl splněn. Systém následně ukazuje průběh plnění.

•

Správa plateb - Uživatel má možnost definovat šablony pro pravidelné platby. Šablony je možné v budoucnosti editovat. Po přihlášení uživatele jsou kontrolovány nevygenerované platby. Pokud nějaké existují, systém vytvoří odpovídající transakce.

Poradce •

Správa šablon - Poradce bude mít možnost vytvářet a spravovat šablony finančních produktů. Šablony jsou produkty s předvyplněnými údaji. Součástí správy šablon jsou případy vytvoření šablony a editace šablon.

•

Vytvoření šablony - Poradce nejprve vybere produkt. Následně ve formuláři nastaví parametry šablony a odešle informace ke zpracování.

•

Editace šablon - Poradce bude mít možnost neplatné šablony ze systému odstranit.

Administrátor •

Prohlížení statistik na úrovni systému - Administrátor bude oprávněn prohlížet statistiky o systému jako celku. Zejména mu bude dostupná statistika o počtu registrovaných uživatelů.

•

Správa uživatelů - Administrátor bude mít možnost vytvářet nové uživatele v rolích poradce a administrátor.

•

Přidělování oprávnění - Administrátor bude mít možnost přidělovat existujícím účtům rozšířená oprávnění.

65

Anonymní uživatel •

Registrace - Anonymní uživatel má možnost registrace nového účtu. Po vyplnění a odeslání požadovaných údajů je vytvořen aktivní účet. Uživatel je zařazen do role BasicUser. Ihned po registraci je možné se do systému přihlásit.

•

Přihlášení - Anonymní uživatel na přihlašovací obrazovce vyplní uživatelské jméno a heslo. V případě úspěšné autentizace je přihlášen do systému.

11.3 Snímky obrazovek systému Personal Finance

66

67