České vysoké učení technické v Praze

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Aplikace pro správu osobních financí Personal finance software Marek Beneš

2

3 Vedoucí práce: Ing. Michal Voráček Studijní program: Softwarové technologie a management, strukturovaný, bakalářský Obor: Softwarové inženýrství 28. května 2010

4 Poděkování Rád bych poděkoval všem, kteří mě při tvorbě této práce podpořili. Obzvláště pak mému vedoucímu, panu Ing. Michalu Voráčkovi, za poskytnuté informace a vedení. iv

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

6 Abstract This thesis deals with analysis, design and implementation of application for managing personal finances. Application can manage incomes and expenses, identify in which areas the user gives his money, and not least also draw attention to the upcoming scheduled transactions (bills, payments from the employer, etc.) Abstrakt Tato práce se zabývá analýzou, návrhem a implementací aplikace pro správu osobních financí. Vytvořená aplikace umí spravovat příjmy a výdaje, zjišťovat, v jakých oblastech uživatel svoje peněžní prostředky vydává a v neposlední řadě také upozorňovat na nadcházející pravidelné transakce (platby za energie, výplaty od zaměstnavatele apod.) vi

7 Obsah Poděkování... iv Prohlášení... v Abstract... vi Abstrakt... vi Seznam obrázků... ix Seznam tabulek... x 1. Úvod Motivační příklad Popis problému, specifikace cíle Cíl bakalářské práce Existující řešení Stormware Filip eúčty.cz Microsoft Money Quicken Analýza a návrh řešení Slovníček pojmů Funkční požadavky Nefunkční požadavky Případy užití a scénáře UC1: Vytvořit účet UC2: Upravit účet UC3: Zobrazit přehled transakcí účtu UC4: Vytvořit transakci UC5: Upravit transakci UC6: Spravovat přílohy UC7: Zobrazit přehled transakcí UC8: Zobrazit přehled zboží UC9: Zobrazit výdaje dle kategorií UC10: Vytvořit pravidelnou transakci UC11: Upravit pravidelnou transakci vii

8 UC12: Zobrazit nadcházející výskyty pravidelných transakcí Diagram tříd Návrh aplikace SOLID Architektura Implementační prostředí Implementace Desktop Domain Data Access Infrastructure Ostatní moduly Testování Funkční testy Black-box a white-box testování Srovnání s existujícími řešeními Závěr Literatura Příloha A Seznam použitých zkratek Příloha B Instalační příručka B.1. Požadavky na systém B.2. Instalace B.3. Obsah CD Příloha C Uživatelská příručka C.1. Pracovní prostředí C.2. Účty C.3. Plánované transakce C.4. Zboží a záruky C.5. Sledování výdajů viii

9 Seznam obrázků Obrázek 1: Domácí účetnictví Filip Obrázek 2: eúčty.cz... 4 Obrázek 3: Microsoft Money Obrázek 4: Quicken Obrázek 5: Diagram případů užití Účty... 8 Obrázek 6: Diagram případů užití Transakce a zboží Obrázek 7: Diagram případů užití Pravidelné transakce Obrázek 8: Diagram tříd domény Obrázek 9: Kompozitní uživatelské rozhraní Obrázek 10: Přehled platformy.net Framework Obrázek 11: Vzor Model-View-ViewModel Obrázek 12: Vztah Composite Application Library a klientské aplikace Obrázek 13: Vrstvy v Entity data modelu Obrázek 14: Diagram závislostí Obrázek 15: Entity data model Obrázek 16: EFRepository a EFUnitOfWork Obrázek 17: Příjmy a výdaje Obrázek 18: Účty Obrázek 19: Plánované transakce Obrázek 20: Sledování výdajů ix

10 Seznam tabulek Tabulka 1: Slovníček pojmů.7 x

11 1. Úvod Kam ty peníze zase zmizely? Určitě jste si tuto otázku v duchu někdy položili. Sice jste si v posledním měsící nekoupili nový počítač, auto nebo značkové džíny, ale peníze z výplaty jsou stejně v nenávratnu. První věc, která asi odpovědného člověka napadne, je vytáhnout sešit nebo oblíbený tabulkový procesor a výdaje si zapisovat. To je určitě chvályhodné, bohužel však tyto snahy často končí u pátého popsaného listu, případně u 316. řádku tabulky. Proč? Komu by se chtělo údaje složitě analyzovat. Je tolik lepších věcí na práci Bohužel i já se musím pokorně přihlásit k jmenované skupině. Rozhodl jsem se proto vytvořit aplikaci, která právě analýzu příjmů a výdajů zjednoduší Motivační příklad Dejme tomu, že jste disciplinovanější než já a poctivě si zapisujete výdaje za plnou nádrž, sedmidenní dálniční známku, 3 noci v hotelu, oběd v restauraci, vstupné do muzea atp. Ke každému výdaji si zapisujete kategorii benzín, auto, ubytování, jídlo, kultura. Budiž. Co když chcete vědět kolik jste utratili za provoz auta? Správně, udržujete si kategorie dvouúrovňově auto benzín, auto ostatní. Co když se Vás zeptám, kolik jste utratili za poslední víkend na dovolené v Českém Krumlově? Jednoduše se k tomuto číslu asi nedostanete. A nebo jste si vytvořili kategorii Dovolená Český Krumlov, ale tady se zase ztrácí informace o účelu jednotlivých plateb. Přesně tuto situaci bych chtěl pomocí mojí aplikace vyřešit. 1

12 2. Popis problému, specifikace cíle 2.1. Cíl bakalářské práce Cílem této bakalářské práce je navrhnout a implementovat Aplikaci pro správu osobních financí. Aplikace bude umožňovat správu příjmů, výdajů a převodů. Tyto transakce pak bude možné prohlížet v přehledech podle časového období, kdy byly vytvořeny, či podle účtu, kterému náleží. Dále bude možné vytvořit pravidelné transakce, které se v určitém intervalu opakují. Na jednotlivé výskyty těchto transakcí bude systém uživatele upozorňovat. Dále bude aplikace poskytovat přehled zakoupeného zboží a upozorňovat na končící záruku. V neposlední řadě může také uživatel sledovat v jakých kategoriích a v jakém množství prostředky vydává Existující řešení Existuje několik softwarových produktů, které řeší správu osobních financí. Já jsem vybral nejsilnějšího českého hráče, jedno webové řešení zdarma a dvě komerční řešení od renomovaných světových výrobců Stormware Filip Tvůrce oblíbeného účetního software Pohoda, společnost Stormware, nabízí řešení pro české domácnosti. Domácí účetnictví Filip (aktuálně ve verzi 2009) nabízí správu v těchto oblastech: - Domácnost (osobní centrála, adresář, kalendář, úkoly, zápisník, smlouvy) - Účetnictví (peněžní deník, pohledávky, závazky, příkazy k úhradě, objednávky, kniha jízd) - Finance (peníze v hotovosti, bankovní účty, kreditní karty, dlouhodobé vklady, portfolia, investice, kursy investic) - Majetek (nemovitosti, vozidla, movitý majetek, katalogy sbírek) - Energie (sazby energií, elektřina, voda, plyn, pohonné hmoty) 2

13 Obrázek 1: Domácí účetnictví Filip 2009 Filip obsahuje poměrně značné množství funkcí. Za zajímavé považuji zejména možnost sledovat spotřebu energií. S funkčností bohužel úměrně narůstá i komplexita programu. Za zbytečné považuji duplování funkcí jako je adresář či kalendář, na které má většina uživatelů své vlastní prověřené aplikace, které používá. Finanční operace je možno členit pouze do jedno až dvouúrovňových kategorií, což dle mého názoru není dostačující. Licence pro jeden počítač stojí 980 Kč, každá další pak 400 Kč. 3

14 eúčty.cz Internetová aplikace eúčty.cz umožnuje spravovat příjmy a výdaje online. Výhodou je možnost spravovat svoje finance odkudkoliv, na druhou stranu by někomu mohla vadit existence dat na serveru soukromého vlastníka. eúčty.cz ale nevyžadují registraci pod reálnými údaji. Zajímavá na nich je bezesporu cena jsou zdarma. Obrázek 2: eúčty.cz 4

15 Microsoft Money Software pro správu osobních financí od Microsoftu nabízí slušnou řádku funkcí. Kromě příjmů a výdajů umí také plánovat. Velice zajímavá je také funkce online propojení s Vaším bankovním či kreditním účtem. Nejnovější verze je z roku 2008 a je také poslední. Microsoft vývoj Money ukončil. Obrázek 3: Microsoft Money

16 Quicken Quicken je asi to nejlepší, co lze na poli celosvětového trhu s produkty pro správu osobních financí najít. Umí spravovat běžné, kreditní či úvěrové účty. To vše s online synchronizací s několika tisíci bankovními institucemi (české bohužel chybí). Má také pokročilé možnosti plánování. Nevýhodou pro českého uživatele je nemožnost oficiální koupě. Licence pro jeden počítač začíná na $49,99. Obrázek 4: Quicken

17 3. Analýza a návrh řešení 3.1. Slovníček pojmů Dovolím si nejprve definovat několik pojmů v problémové doméně. Účet (Account) Transakce (Transaction) Výdaj (Expense) Příjem (Income) Převod (Transfer) Pravidelná transakce (Scheduled transaction) Bankovní či hotovostní účet Pohyb na účtu, který má určitou částku a datum vykonání Speciální typ transakce, která obsahuje informaci o tom, z kterého účtu byly vydány peněžní prostředky Speciální typ transakce, která obsahuje informaci o tom, na jaký účet byly deponovány peněžní prostředky Speciální typ transakce, která obsahuje informaci o tom, z jakého a na jaký účet byly převedeny peněžní prostředky Speciální typ transakce, která se v určitém časovém intervalu opakuje. Opakování může být buď nekonečné, ukončené po daném počtu výskytů či ukončené určitým datem. Pravidelná transakce může být výdaj, příjem nebo převod. Zboží (Comodity) Zboží (produkt) u kterého nás zajímá doba trvání záruky, případně další nepovinné informace, např. kde bylo zboží pořízeno. Je součástí nějakého výdaje. Tabulka 1: Slovníček pojmů 3.2. Funkční požadavky Funkční požadavky definují požadovanou funkcionalitu aplikace. F1. Aplikace umožní vytvářet a upravovat účty (bankovní, hotovostní aj.) F2. Aplikace umožní vytvářet a upravovat záznamy o transakcích (tj. příjmy, výdaje, převody mezi účty) F3. Aplikace umožní přiřadit transakci k účtu F4. Aplikace umožní přikládat k transakci přilohy (obrázky) F5. Aplikace umožní výdaje kategorizovat do kategorií zvolených uživatelem F6. Aplikace umožní zobrazení výdajů podle kategorií F7. Aplikace umožní vytvářet a upravovat záznamy o zboží a produktech. F8. Aplikace umožní vygenerovat upozornění na konec záruky ve formě události použitelné v organizérech (např. Microsoft Outlook) F9. Aplikace bude zobrazovat přehled všech transakcí provedených v určitém časovém období F10. Aplikace umožní zobrazení přehledu transakcí na účtu provedených v určitém časovém období F11. Aplikace umožní vytvářet a upravovat pravidelné transakce, tj. transakce, které se v určitém časovém intervalu opakují. F12. Aplikace zobrazí nadcházející výskyty pravidelných transakcí a zdůrazní výskyty, které jsou již po splatnosti 7

18 F13. Aplikace umožní vygenerovat upozornění na nadcházející výskyty plánované transakce ve formě události použitelné v organizérech (např. Microsoft Outlook) F14. Aplikace umožní dočasně deaktivovat zobrazování jednotlivých výskytů plánované transakce 3.3. Nefunkční požadavky Nefunkční požadavky definují nároky a omezení systému. S1. Aplikace bude fungovat na platformě Microsoft Windows S2. Aplikace bude implementována na platformě Microsoft.NET S3. Aplikace bude rozdělena do modulů, které budou na sobě v rámci možností nezávislé 3.4. Případy užití a scénáře Případy užití jsou vyjádřeny v diagramu. Zcela úmyslně nevyužívám všech možností specifikace UML 1 (např. stereotyp «extends»), protože se to dle [1] a [2] nedoporučuje. Následuje výčet případů užití a jejich konkrétních scénářů. Protože UML nespecifikuje přesný formát scénářů, používám jakýsi hybrid mezi formátem dle [1] a [2]. «subsystem» Účty Vytvořit účet Uživatel Upravit účet Zobrazit přehled transakcí účtu UC1: Vytvořit účet Hlavní tok událostí: Obrázek 5: Diagram případů užití Účty 1. Uživatel vybere nabídku Nový účet 2. Systém požádá uživatele o zadání údajů název účtu a počáteční zůstatek 3. Uživatel zadá údaje název účtu a počáteční zůstatek 4. Uživatel potvrdí vytvoření účtu 5. Systém vytvoří nový účet a vyvolá událost o vytvoření nového účtu 1 UML Unified Modelling Language standartizovaný modelovací jazyk používaný v oblasti softwarového inženýrství 8

19 Alternativní tok: 1. Uživatel může vytváření kdykoliv ukončit UC2: Upravit účet Hlavní tok událostí: 1. Uživatel vybere účet, který chce upravit 2. Systém načtě údaje název účtu a počáteční zůstatek a umožní jejich úpravu uživateli 3. Uživatel změní údaje název účtu a/nebo počáteční zůstatek 4. Uživatel potvrdí úpravu účtu 5. Systém upraví údaje o účtu a vyvolá událost o změně existujícího účtu Alternativní tok: 1. Uživatel může úpravu kdykoliv ukončit, změny se poté nikam nepropagují UC3: Zobrazit přehled transakcí účtu Hlavní tok událostí: 1. Uživatel vybere nabídku Účty 2. Systém zobrazí nabídku existujících účtů 3. Uživatel vybere jeden z účtů 4. Systém vybere a zobrazí defaultní časový interval 5. Systém vyhledá transakce na účtu v zadaném časovém intervalu 6. FOR každou nalezenou transakci a. Systém zobrazí typ transakce (výdaj, příjem, převod) b. Systém zobrazí údaje o transakci (částka, datum, poznámka) c. IF transakce je výdaj i. Systém zobrazí účet, z kterého byl vydán d. IF transakce je příjem i. Systém zobrazí účet, na který byl přijat e. IF transkace je převod i. Systém zobrazí účet, z kterého byl převeden ii. Systém zobrazí účet, na který byl převeden 7. Systém vypočte a zobrazí obrat příjmů, výdajů a převodů Rozšíření: 4. Uživatel vybere vlastní časový interval a. Návrat do Hlavního toku událostí krok 5 9

20 «subsystem» Transakce a zboží Vytvořit transakci «include» Spravovat přilohy Upravit transakci «include» Uživatel Zobrazit přehled transakcí Zobrazit výdaje dle kategorií Zobrazit přehled zboží 10 Obrázek 6: Diagram případů užití Transakce a zboží UC4: Vytvořit transakci Hlavní tok událostí: 1. Uživatel požádá o vytvoření nového výdaje, příjmu nebo převodu 2. Systém zobrazí údaje o transakci datum, částku a poznámku 3. Uživatel zadá povinné údaje (datum transakce, částka) 4. Uživatel může zadat nepovinný údaj (poznámka) 5. Uživatel může přidat přílohy a. INCLUDE UC Spravovat přílohy 6. IF transakce je výdaj a. Systém zobrazí seznam existujícíh účtů b. Uživatel vybere účet, z kterého byla částka vydána c. Systém zobrazí kategorie, které jsou k dispozici d. Uživatel přiřadí k výdaji libovolné množství kategorií e. Uživatel může zvolit, že součástí transakce je vytvoření zboží f. Systém zobrazí údaje o zboží (název, popis, datum začátku a konce záruky) g. Uživatel může zadat název a popis zboží, datum začátku a konce záruky 7. IF transakce je příjem a. Systém zobrazí seznam existujícíh účtů b. Uživatel vybere účet, na který byla částka přijata 8. IF transkace je převod a. Systém zobrazí dva seznamy existujících účtů b. Uživatel vybere účet, z kterého byla částka vydána

21 c. Uživatel vybere účet, na který byla částka přijata 9. Uživatel potvrdí přidání transakce 10. Systém vytvoří novou transakci a vyvolá událost o vytvoření nové transakce Alternativní tok: 1. Uživatel může přidání transakce kdykoliv přerušit UC5: Upravit transakci Hlavní tok událostí: 1. Uživatel vybere transakci, kterou chce upravit 2. Systém načtě údaje upravované transakce (datum, částka, poznámka) 3. Uživatel může změnit povinné údaje (datum transakce, částka) 4. Uživatel může změit nepovinný údaj (poznámka) 5. Uživatel může přidat/změnit přílohy a. INCLUDE UC Spravovat přílohy 6. IF transakce je výdaj a. Systém zobrazí seznam existujících účtů b. Uživatel může změnit účet, z kterého byla částka vydána c. Systém zobrazí kategorie, které jsou k dispozici d. Uživatel může přiřadit k výdaji libovolné množství kategorií e. Uživatel může zvolit, že součástí transakce je zboží f. Systém zobrazí údaje o zboží (název, popis, datum začátku a konce záruky) g. Uživatel může zadat název a popis zboží, datum začátku a konce záruky 7. IF transakce je příjem a. Systém zobrazí seznam existujících účtů b. Uživatel může změnit účet, na který byla částka přijata 8. IF transkace je převod a. Systém zobrazí dva seznamy existujících účtů b. Uživatel může změnit účet, z kterého byla částka vydána c. Uživatel může změnit účet, na který byla částka přijata 9. Uživatel potvrdí úpravu transakce 10. Systém upraví transakci a vyvolá událost o změně transakce Alternativní tok: 1. Uživatel může úpravu transakce kdykoliv přerušit UC6: Spravovat přílohy (není instancovatelný) Hlavní tok událostí: 1. Uživatel chce spravovat přílohy 2. IF transakce již má přílohy a. Systém načte a zobrazí seznam existujících příloh 11

22 12 3. Uživatel může přidat novou přílohu výběrem souboru 4. Uživatel ukončí správu příloh 5. Systém vrací tok událostí do klientského toku UC7: Zobrazit přehled transakcí Hlavní tok událostí: 1. Uživatel chce zobrazit přehled transakcí 2. Systém vybere a zobrazí defaultní časový interval 3. Systém vyhledá transakce v zadaném časovém intervalu 4. FOR každou nalezenou transakci a. Systém zobrazí typ transakce (výdaj, příjem, převod) b. Systém zobrazí údaje o transakci (částka, datum, poznámka) c. IF transakce je výdaj i. Systém zobrazí účet, z kterého byl vydán d. IF transakce je příjem i. Systém zobrazí účet, na který byl přijat e. IF transkace je převod i. Systém zobrazí účet, z kterého byl převeden ii. Systém zobrazí účet, na který byl převeden 5. Systém vypočte a zobrazí obrat příjmů a výdajů Rozšíření: 2. Uživatel vybere vlastní časový interval a. Návrat do Hlavního toku událostí krok UC8: Zobrazit přehled zboží Hlavní tok událostí: 1. Uživatel chce zobrazit přehled zboží 2. Systém vyhledá transakce, které obsahují zboží 3. FOR každou nalezenou transakci a. Systém zobrazí údaje o zboží (název, popis, datum konce záruky) b. Systém zobrazí údaje o transakci (částka, datum transakce) c. Systém umožní uživateli vygenerovat upozornění na konec záruky ve formě události v organizéru (např. Outlook) UC9: Zobrazit výdaje dle kategorií Hlavní tok událostí: 1. Uživatel chce zobrazit výdaje dle kategorií 2. Systém vybere a zobrazí defaultní časový interval 3. Systém načte a zobrazí kategorie výdajů 4. Uživatel vybere kategorie, ve kterých chce sledovat výdaje 5. Systém na základě vybraných kategorií a časového intervalu vyhledá výdaje 6. FOR každý nalezený výdaj

23 a. Systém zobrazí údaje o výdaji (částka, datum, poznámka a účet, z kterého byl vydán) 7. Systém vypočte a zobrazí součet výdajů v období a kategoriích Rozšíření: 3. Uživatel vybere vlastní časový interval a. Návrat do Hlavního toku událostí krok 3 «subsystem» Pravidelné transakce Vytvořit plánovanou transakci Uživatel Zobrazit nadcházející transakce Upravit plánovanou transakci Obrázek 7: Diagram případů užití Pravidelné transakce UC10: Vytvořit pravidelnou transakci Hlavní tok událostí: 1. Uživatel chce vytvořit pravidelný výdaj, příjem nebo převod 2. Systém zobrazí údaje o pravidelné transakci (příští datum transakce, částka, interval opakování, poznámka, způsob ukončení) 3. Uživatel zadá povinné údaje (příští datum transakce, částka, interval opakování) 4. Uživatel může zadat nepovinné údaje (poznámka, způsob ukončení) 5. IF pravidelná transakce je pravidelný výdaj a. Systém zobrazí seznam existujících účtů b. Uživatel vybere účet, z kterého bude částka vydávána c. Systém zobrazí kategorie, které jsou k dispozici d. Uživatel přiřadí k pravidelnému výdaji libovolné množství kategorií 6. IF pravidelná transakce je pravidelný příjem a. Systém zobrazí seznam existujících účtů b. Uživatel vybere účet, na který má být částka přijímána 7. IF transkace je pravidelný převod a. Systém zobrazí dva seznamy existujících účtů 13

24 14 b. Uživatel vybere účet, z kterého má být částka vydávána c. Uživatel vybere účet, na který má být částka přijímána 8. Uživatel potvrdí přidání pravidelné transakce 9. Systém vytvoří pravidelnou transakci a vyvolá událost o vytvoření nové pravidelné transakce Alternativní tok: 1. Uživatel může přidání pravidelné transakce kdykoliv přerušit UC11: Upravit pravidelnou transakci Hlavní tok událostí: 1. Uživatel vybere pravidelnou transakci, kterou chce upravit 2. Systém zobrazí údaje o vybrané transakci (příští datum transakce, částka, interval opakování, poznámka, způsob ukončení) 3. Uživatel může změnit povinné údaje (příští datum transakce, částka, interval opakování) 4. Uživatel může zadat či změnit nepovinné údaje (poznámka, způsob ukončení) 5. IF pravidelná transakce je pravidelný výdaj a. Systém zobrazí seznam existujících účtů b. Uživatel může změnit účet, z kterého bude částka vydávána c. Systém zobrazí kategorie, které jsou k dispozici d. Uživatel přiřadí k pravidelnému výdaji libovolné množství kategorií 6. IF pravidelná transakce je pravidelný příjem a. Systém zobrazí seznam existujících účtů b. Uživatel může změnit účet, na který má být částka přijímána 7. IF pravidelná transkace je pravidelný převod a. Systém zobrazí dva seznamy existujících účtů b. Uživatel může změnit účet, z kterého má být částka vydávána c. Uživatel může změnit účet, na který má být částka přijímána 8. Uživatel potvrdí úpravu pravidelné transakce 9. Systém upraví pravidelnou transakci a vyvolá událost o změně pravidelné transakce Alternativní tok: 1. Uživatel může úpravu pravidelné transakce kdykoliv přerušit, změny se pak nikam nepropagují UC12: Zobrazit nadcházející výskyty pravidelných transakcí Hlavní tok událostí: 1. Uživatel chce zobrazit nadcházející výskyty pravidelných transakcí 2. Systém vyhledá pravidelné transakce 3. FOR každou nalezenou pravidelnou transakci a. Systém vytvoří seznam výskytů pravidelné transakce v následujících 60 dnech

25 4. FOR každý výskyt pravidelné transakce a. Systém zobrazí typ transakce (výdaj, příjem, převod) b. IF datum výskytu je větší než aktuální datum i. Systém zvýrazní tento výskyt c. Systém zobrazí údaje o transakci (částka, datum, poznámka) d. Systém umožní vyvolat vytvoření nové transakce na základě tohoto opakování e. Systém umožní uživateli vygenerovat upozornění na datum splatnosti tohoto výskytu ve formě události v organizéru (např. Outlook) 15

26 3.5. Diagram tříd V této části je zobrazen diagram tříd problémové domény. Obrázek 8: Diagram tříd domény 16

27 3.6. Návrh aplikace Při návrhu aplikace jsem se snažil řídit moderními trendy v oblasti softwarového inženýrství. Za základ považuji tzv. SOLIDní design SOLID SOLID je akronym pro 5 základních principů objektově orientovaného programování. Jsou jimi: - Single responsibility principle každý objekt v modelu by měl mít pouze jedinou zodpovědnost. - Open/closed principle software (rozhraní) by měl být otevřený pro rozšíření, ale uzavřený pro modifikaci. - Liskov substitution principle, také znám jako design by contract - rozhraní v systému by mělo mít svoji specifikaci, co se týče omezení vstupních/výstupních podmínek, které požaduje. Tato omezení by měla být známá již v době kompilace. - Interface segregation principle je lepší mít mnoho menších specifických rozhraní, než jedno všeumějící obecné. - Dependency inversion principle nevytvářet závislosti na konkrétní implementaci, ale na abstrakci. Aplikací tohoto principu je použití Dependency injection Architektura Ačkoliv se nejedná o příliš rozsáhlou a složitou aplikaci, rozhodl jsem se o poměrně komplexní návrh, s důrazem na spravovatelnost a testovatelnost jednotlivých částí aplikace. Mým cílem bylo vytvořit takovou architekturu, aby jednotlivé moduly s funkcionalitou byly na sobě co nejvíce nezávislé. Na úrovni aplikace to znamená striktní oddělení doménového modelu, modulu pro přístup k datům, modulu infrastruktury a modulů realizujících jednotlivé případy užití. Na úrovni modulů pak oddělení rozhraní služeb od jejich implementace, uživatelského rozhraní od logiky atp. Pokusím se podrobněji představit několik konceptů, které jsem při vývoji používal Modularita Modularita je způsob návrhu systému, ve kterém se snažíme rozdělit aplikaci do několika funkčních jednotek modulů. Modul reprezentuje množinu příbuzných zájmů. Každý modul může obsahovat kolekci komponent vlastností, pohledů, obchodní logiky, služeb atp. Moduly jsou na sobě nezávislé. Mohou spolu komunikovat, ale pouze volnou vazbou 2 prostřednictvím definovaných rozhraní. Modularita umožňuje implementovat jednodušší spravovatelnější funkční jednotky Kompozitní uživatelské rozhraní Modulární aplikace se typicky obsahují značné množství vizuálních komponent, které jsou na sobě navzájem nezávislé. Je tedy nutné zajistit jejich sestavení do požadované podoby tak, aby tvořili kompaktní celek. Zároveň však požadujeme, aby nebyly komponenty zatíženy zbytečnou závislostí, a to mezi sebou na úrovni rozvržení aplikace. Je proto vhodné vytvořit 2 loosely coupled fashion moduly spolu komunikují typicky přez prostředníka, nemají mezi sebou závislosti 17

28 základní layout aplikace (tzv. shell ) a tyto komponenty načítat dynamicky. Jako příklad uvádím aplikaci, kde jeden modul zajišťuje zobrazení seznamu objednávek a jiný modul zajišťuje zobrazení detailu objednávky: Obrázek 9: Kompozitní uživatelské rozhraní Kontejner a dependency injection Jak jsem naznačil, jednotlivé moduly mají mezi sebou volnou vazbu. Jak tedy zařídit, aby mezi sebou mohly moduly komunikovat? Odpovědí je použití dependency injection. Princip dependency injection umožňuje snižovat závislosti na minimum. Stačí ustanovit předem definované rozhraní. Moduly poté pracují pouze s tímto rozhraní a nezajímají se o to, která konkrétní implementace za ním stojí. A právě tzv. kontejner rozhoduje o tom, kterou konkrétní instanci poskytne. Kontejner zajišťuje celý životní cyklus jednotlivých instancí, tedy od vytvoření až po zánik. Hlavní výhody použití kontejneru: - Nemusíme se starat o lokalizaci (vytváření) závislostí, stačí definovat rozhraní, které pořebujeme - Kontejner umožňuje vyměnit implementaci závislosti za jinou, aniž by ovlivnil klientskou komponentu - Kontejner zjednodušuje testovatelnost možností poskytnout tzv. mock 3 implementace - Kontejner zlepšuje spravovatelnost možností jednoduše přidat nové komponenty do existujícího systému 3 Falešná implementace služby pro účely testování 18

29 UnitOfWork a Repository Poslední koncept, kterému bych se chtěl věnovat, jsou návrhové vzory UnitOfWork a Repository. Oba tyto vzory řeší nějakým způsobem přístup k datovému zdroji. Smyslem repository je v podstatě schovat datový zdroj za rozhraní, které je podobné kolekci. UnitOfWork se nám stará o sledování entit, jejich změn apod. Typicky obsahuje metody Commit a Rollback pro potvrzení respektive zrušení provedených změn Implementační prostředí Microsoft.NET Framework Jako implementační prostředí jsem se rozhodl zvolit platformu Microsoft. NET Framework, a to konkrétně ve verzi 4.0. První verze.net Frameworku vyšla v roce 2002 jako přímá konkurence Javy. Obě platformy mají mnoho společného. Aplikace běží v řízeném (managed) prostředí (CLR Common Language Runtime), zdrojové kódy se překládají do mezijazyka (CIL - Common Intermediate Language) a až na cílové platformě do strojového kódu. Microsoft.NET Framework obsahuje také základní knihovnu běžně používaných funkcí (BCL Base Class Library), jako je práce se soubory, sítí, kolekcemi, vlákny, textem apod. Obrázek 10: Přehled platformy.net Framework Kromě zmíněné BCL obsahuje.net Framework i další knihovny a technologie, které nabízí vývojářům. Já se zmíním o podmnožině, která je zásadní pro moji aplikaci. 19

30 Windows Presentation Foundation Windows Presentation Foundation (WPF) je technologie tvorby uživatelských rozhraní (UI user interface), uvedená v roce 2006 jako součást.net Frameworku 3.0. Oproti starší (a stále podporované) technologii Windows Forms přichází s novými koncepty návrhu UI. Zatímco ve Windows Forms se vytváří UI ve formě klasického procedurálního kódu, který je typicky generován pomocí návrháře vývojového prostředí, ve WPF je vytvářen graf objektů reprezentovaný pomocí jazyka XAML (Extensible Application Markup Language). Jazyk XAML vychází z jazyka XML (Extensible Markup Language) a sémantikou je podobný např. HTML (HyperText Markup Language). Tlačítko ve Windows Forms bychom definovali nějak takto: Button button = new Button(); button.text = "OK"; button.background = Colors.Blue; button.click += new EventHandler(button_Click); Ve WPF (respektive XAML) můžeme použít např. tento fragment <Button Content="OK" Background="Blue" Click="button_Click" /> Toto by nás při výběru technologie asi neohromilo. Mnohem zajímavější je způsob, jak je ve WPF řešeno svázání s daty (databinding). Místo textového popisu raději uvedu další příklad: <TextBox Text="{Binding Jmeno, Mode=TwoWay}" /> Tímto kódem vyjádříme vazbu mezi vstupním polem formuláře a vlastností Jmeno v našem datovém modelu. Systém databindingu se sám postará o propagaci hodnoty z modelu do TextBoxu a při úpravě hodnoty zpět do modelu. Je možné definovat, jestli má být vazba obousměrná či pouze jednosměrná (z modelu do UI nebo obráceně). Zajímavou možnost nabízejí také tzv. konvertery. Jedná se o jednoduché rozhraní, které zajistí vazbu zdánlivě nekompatabilních datových typů. Například chceme, aby se číslo v textovém poli obarvilo na červeno, pokud je menší než 0 a na černo pokud je větší něž nula. K tomu nám pomůže databinding za pomocí konverteru. public class NumberToColorConverter:IValueConverter { public object Convert(object value, Type targettype, object parameter, CultureInfo culture) { var number = value as int?; if (number.hasvalue) { if (number < 0) return new SolidColorBrush(Colors.Red); } return new SolidColorBrush(Colors.Black); } } 20

31 <TextBox Text="{Binding Cislo}" Foreground="{Binding Cislo, Converter={StaticResource numbertocolorconverter}}" /> Model-View-ViewModel Architektonický vzor Model-View-ViewModel (MVVM) není sice součástí.net Frameworku, uvádím ho však zde kvůli jeho závislosti na technologii WPF. MVVM má původ v rodině vzorů Model-View-Controller (MVC). Na rozdíl od MVC však umí pohled (View) sám zpracovat uživatelský vstup. Pomocí databindingu jsou data propagována do tzv. ViewModelu. Jedná se o jakýsi adaptér mezi pohledem a modelem. ViewModel zachycuje stav uživatelského rozhraní a interaguje s modelem. ViewModel o View nic neví, veškerá interakce je řešena pomocí databindingu. View ViewModel Model Obrázek 11: Vzor Model-View-ViewModel Composite Application Library Ani Composit Application Library (CAL, také známá jako projekt Prism) není součástí žádné verze.net Frameworku. Je však vyvýjena skupinou patterns&practices, která patří přímo pod Microsoft. CAL usnadňuje vývojářům vytváření modulárních a kompozitních aplikací pomocí technologií Windows Presentation Foundation a Silverlight 4. Kromě sady tříd, usnadňující tvorbu modulů, integruje funkcionalitu dependency injection kontejneru Microsoft Unity. Dále obsahuje implementace služeb, které jsou u modulárních aplikací často používány. Příkladem je např. EventAggregator, který umožňuje zasílání událostí mezi moduly, aniž by mezi nimi musely vznikat závislosti. Další službu, kterou poskytuje, je tzv. RegionManager. Ten se stará o zobrazení pohledů, které poskytují jednotlivé moduly v regionech. Regiony definuje vývojář v tzv. Shell projektu. To je projekt, který obsahuje základní layout aplikace. Následující obrázek ukazuje vztahy mezi CAL a vytvářenou aplikací. 4 Microsoft Silverlight aplikační framework pro tvorbu interaktivních webových aplikací 21

32 Obrázek 12: Vztah Composite Application Library a klientské aplikace ADO.NET Entity Framework ADO.NET Entity Framework (EF) je objektově-relační mapovací framework (ORM) postavený nad ADO.NET. ADO.NET je sada komponent integrovaná přímo v BCL pro práci s relačními databázovými zdroji. EF je momentálně ve verzi 4, ačkoliv se jedná teprve o druhou generaci číslo verze bylo sjednoceno s vydáním.net Framework 4.0. EF je, co se funkčnosti týče, velmi podobný ostatním ORM frameworkům jako je např. Java Persistance API nebo Hibernate. Umožňuje vytvořit datový model (Entity Data Model EDM) nezávislý na použité relační databázi. Tento model má 3 vrstvy: - Konceptuální (Conceptual) definuje entity a vztahy tak, jak je zná a používá obchodní logika. K definici používá jazyk Conceptual Schema Definition Language (CSDL) - Logická (Logical Store) definuje, jak vypadá databázové schéma. K definici používá jazyk Store Schema Definition Language (SSDL). - Mapovací (Mapping) mapuje konceptuální vrstvu na logickou vrstvu. Mapování nemusí být pouze ve vztahu 1:1, můžeme mít například entitu v konceptuální vrstvě, která je namapovaná na více tabulek v logické vrstvě. K definici používá jazyk Mapping Schema Language (MSL) 22

33 Obrázek 13: Vrstvy v Entity data modelu Ačkoliv se jedná o řešení od Microsoftu, není přímo závislý na Microsoft SQL Serveru. Existuje celá řada poskytovatelů třetích stran (např. MySQL, FireBird, Oracle, PosgreSQL, SQLite a další) SQL Server Compact Poslední, co zbývá vybrat je datový zdroj, do kterého se budou ukládat lokální data. Rozhodl jsem se zvolit Microsoft SQL Server Compact (SQL CE) ve verzi 3.5. Jedná se o tzv. embedded databázi. To znamená, že tato databáze nepotřebuje instalovat nějaké vlastní běhové prostředí a dá se tak zakomponovat přímo do aplikace. To je z hlediska jednoduchosti nasazení žádoucí. 23

34 4. Implementace Aplikaci jsem rozdělil do 10 modulů. Tyto moduly jsou znázorněné na diagramu závislostí mezi moduly. Diagram závislostí je proprietární diagram, který obsahuje Microsoft Visual Studio Pokusím se postupně tyto moduly popsat. Obrázek 14: Diagram závislostí Poznámka: Vzhledem k tomu, že nemám dobré zkušenosti s implementací software v českém jazyce, jsou názvy modulů, tříd, metod, atributů apod. anglicky Desktop Tento modul obsahuje zejména Shell, tedy základní rozvržení a styl uživatelského rozhraní, definici regionů apod. Dále obsauje tzv. Bootstrapper, což je třída, která slouží ke konfiguraci použitého dependency injection kontejneru Domain Dá se říct, že tento modul je srdcem celé aplikace. Obsahuje zejména definici entit a událostí, které se objevují v systému. Entity jsou vytvořeny jako POCO (Plain Old CLR Object) objekty. To znamená, že nemají žádnou závislost na vrstvě či modulu zajišťujícím persistenci dat. Doménový model ale není v žádném případě anemický (na rozdíl od DTO 6, které jsou na první pohled POCO objektům podobné). 5 Integrované prostředí pro vývoj aplikací na platformě.net 6 DTO Data Transfer Object objekt je použit pouze pro přenos dat mezi vrstvami, nebosahuje doménovou logiku 24

35 Entity obsahují doménovou logiku, která se k nim vztahuje. Dále definuje rozhraní služeb a repozitářů pro přístup k datům (rozhraní IUnitOfWork a IRepository<T>). Neřeší však jejich implementaci Data Access O přístup k datům a implementaci repozitářů se stará právě tento modul. Je v něm definován Entity Data Model (EDM), který zajišťuje správné namapování entit na databázi. Na následujícím obrázku je současný EDM. Z tohoto diagramu je možné jednoduše vygenerovat databázové schéma. Obrázek 15: Entity data model Jsou zde implementovány třídy EFUnitOfWork a EFRepository<T> uzpůsobené pro práci s Entity Frameworkem. Z třídy EFRepository jsou pak odvozeny konkrétní implementace repozitářů dle rozhraní z Domain modulu. 25

36 Obrázek 16: EFRepository a EFUnitOfWork Díky dependency injection kontejneru mohou ostatní moduly konzumovat tyto konkrétní implementace, aniž by musely mít závislost na tomto modulu Infrastructure Tento modul obsahuje to, co se jinam nevešlo. Jsou k dispozici bázové implementace různých tříd, helper 7 třídy, konvertory apod Ostatní moduly Ostatní moduly již řeší konkrétní případy užití. Většinou obsahují dvojici View-ViewModel, která řeší daný use case. V několika případech reprodukují několik View jeden ViewModel. Případně je jeden ViewModel vnořen do jiného apod. Stručný seznam případů užití, které jednotlivé moduly řeší: - TransactionsModule řeší UC Zobrazit přehled transakcí, Vytvořit transakci, Upravit transakci a Zobrazit přehled transakcí účtu - AccountsModule řeší UC Vytvořit účet, Upravit účet - AttachmentsModule řeší UC Spravovat přílohy - ScheduledTransactionsModule řeší UC Vytvořit pravidelnou transakci, Upravit pravidelnou transakci, Zobrazit nadcházející transakci - CommoditiesModule řeší UC Zobrazit přehled zboží - SpendingsModule řeší UC Zobrazit výdaje dle kategorií 7 Třída, která usnadňuje práci s často se opakujícími činnostmi 26

37 5. Testování 5.1. Funkční testy Funkční testy porovnávají výslednou implementaci software s funkčními požadavky, zadanými na začátku vývoje. Tyto testy jsou úspěšné, podařilo se implementovat veškerou požadovanou funkčnost Black-box a white-box testování Black-box testování nahlíží na testovanou aplikaci z pohledu zvenčí a nezajímá se o vnitřní implementaci. Toto zahrnuje zejména manuální testování uživatelem. Základní funkčnost a stabilita byla ověřena, snažil jsem se minimalizovat případy neočekávaných pádu programu například po špatném uživatelském vstupu. Zatím není implementována žádná infrastruktura pro ošetření neočekávaných chyb, jako je například poškození databáze apod. V této oblasti je tedy určitě prostor pro zlepšení. To se týká i absence white-box testování, tedy zejména jednotkových a integračních testů. 27

38 6. Srovnání s existujícími řešeními Tato aplikace se co se rozsahu funkčnosti nemůže rovnat programům, jako je Microsoft Money či Quicken. Ve srovnání s eúčty.cz nabízí aplikace srovnatelnou funkčnost a subjektivně pohodlnější ovládání. Jako jediná aplikace přináší koncept sledování výdajů pomocí štítků, tedy kategorií, které nemají stromovou strukturu a uživatel je může libovolně kombinovat. 28

39 7. Závěr Domnívám se, že aplikace splnila požadavky zadání. Aplikace umožňuje pohodlnou správu příjmů, výdajů a pohybů na účtu. Upozorňuje uživatele na pravidelné transakce, jako jsou platby za energie, nájem apod. a tím snižuje riziko pokuty za opožděnou platbu. Navíc umí generovat události ve formátu ical, které jsou použitelné například v programu Microsoft Outlook. Umožňuje také sledovat v jakých kategoriích uživatel prostředky vydává. Pro mě osobně to byla výborná zkušenost. Mohl jsem si vyzkoušet vytvoření striktně modulární aplikace od zelené louky až po funkční prototyp. Rozhodně budu ve vývoji aplikace pokračovat. 29

40 8. Literatura [1] ARLOW, Jim; NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací : Objektově orientovaná analýza a návrh prakticky. 2. upravené vydání. Praha : Computer press, s. ISBN [2] FOWLER, Martin. Destilované UML. 1. Praha : Grada Publishing a.s., s. ISBN [3] - FOWLER, Martin. Patterns of Enterprise Application Architecture. 1. [s.l.] : Addison-Wesley Professional, s. ISBN [4] - NATHAN, Adam. WPF Unleashed. 1. [s.l.] : Sams, s. ISBN [5] - Microsoft patterns&practices. Microsoft Developer Network : Composite Client Application Guidance [online] [cit ]. Dostupné z WWW: < [6] - Microsoft. Microsoft Developer Network [online] [cit ]. ADO.NET Entity Framework. Dostupné z WWW: < 30

41 Příloha A Seznam použitých zkratek ADO.NET - ActiveX Data Objects.NET API - Application Programming Interface BCL - Base Class Library CAL - Composite Application Library CIL - Common Intermediate Language CLR - Common Language Runtime CSDL - Conceptual schema definition language DTO - Data Transfer Object EDM - Entity Data Model EF - Entity Framework HTML - HyperText Markup Language MSL - Mapping Schema Language MVC - Model - View - Controller MVVM - Model - View - ViewModel ORM, - Object-relational mapping POCO - Plain Old CLR Object SOLID, viz str. 17 SQL CE - Structured Query Language Compact Edition SSDL - Store Schema Definition Language UC - Use Case UI - User Interface UML - Unified Modelling Language WPF - Windows Presentation Foundation XAML - Extensible Application Markup Language XML - Extensible Markup Language 31

42 Příloha B Instalační příručka B.1. Požadavky na systém Aplikaci lze spustit v operačním systému Windows 2000 a vyšším s nainstalovanám Microsoft.NET Frameworkem 4.0 Client Profile nebo vyšším. Dalším požadavkem je instalace Microsoft SQL Serveru Compact 3.5 SP2.NET Framework 4.0 i SQL CE lze nalézt na přiloženém CD v adresáři prerequisities, případně lze stáhnout na adrese fb17111cf544&displaylang=en respektive 404C-B161-3A0B323DCE24&displaylang=en B.2. Instalace Aplikaci je možno nainstalovat spuštěním souboru /instalace/setup.exe na přiloženém CD. B.3. Obsah CD CD obsahuje složky - Instalace o Setup.exe instlační soubor aplikace - Prerekvizity o dotnetfx40_client_x86_x64.exe běhové prostředí.net Framework 4.0 o SSCERuntime_x64-ENU.msi Microsoft SQL Server Compact 3.5 SP2 64bit o SSCERuntime_x86-ENU.msi - Microsoft SQL Server Compact 3.5 SP2 32bit - Řešení o Kompletní řešení (solution) ve Visual Studiu Text o Docx a PDF soubor s elektronickou verzí textu 32

43 Příloha C Uživatelská příručka C.1. Pracovní prostředí Pracovní prostředí aplikace je rozděleno na dvě části. V horní části najdeme panel přehledů, ve spodní části panel akcí. Akcí můžeme spouštět najednou libovolné množství. Obrázek 17: Příjmy a výdaje C.2. Účty Po instalaci je vhodné přidat několik účtů. Může to být např. hotovost, běžný účet, spořící účet apod. Nejedná se o povinnost, příjmy a výdaje nemusí náležet účtu. Převod však musí definovat oba účty. 33