Moina - A Time Saving Personal Financial Management...

Moina - A Time Saving PersonalFinancial Management Solution

Morten Hillebo

Kongens Lyngby 2011IMM-B.Eng-2010-66

Technical University of DenmarkInformatics and Mathematical ModellingBuilding 321, DK-2800 Kongens Lyngby, DenmarkPhone +45 45253351, Fax +45 [email protected]

IMM-B.Eng-2010-66

Abstract

Managing personal finances can be a difficult and time-consuming matter. Gath-ering and processing financial information, categorizing transactions and addingup all the numbers are all considered very dull work tasks. Most people wouldhowever like to keep their finances in check, but haven’t got the time needed byfinancial management tools available today.

The purpose of this project is to build an online Personal Financial Management(PFM) solution that could save users the time and agony of obtaining the finan-cial perspective themselves. The solution’s primary time saving features shouldbe importing, categorizing and visualisation of the user’s financial transactions.

To make the transactions categorization selection, various algorithms and tech-nologies must be evaluated. The majority of this work will lie in the fields ofdata filtering, data mining and algorithms.

The prototype of the system will be programmed in C# .NET with a MVCweb frontend. The system architecture will be build through Domain DrivenDesign principles, and the technologies used in the system should make it highlytestable, scalable and agile.

The result should be a fast and functional solution with an acceptable lowamount of categorization errors and transactions that could not be categorized.

The project should provide proof of concept for the solution as a time savingPFM solution.

Preface

This project was prepared at the Department of Informatics and Mathemati-cal Modelling (IMM) at the Technical University of Denmark (DTU) in partialfulfilment of the requirements for acquiring the degree Bachelor of Engineering(B.Eng).

This project is the result of the work carried out in the period from Febuary2011 to April 2011, with the work load equivalent to 15 ECTS credits

This project deals with the development of a personal finance managementsolution. The work related with the development of the solution will be themain focus of the project.

Lyngby, April 2011

Morten Hillebo

Acknowledgements

First and foremost, I would like to thank my supervisor Bjarne Poulsen for hispatient guidance and support during the project.

Thanks to the eight test group participants for taking part in the project re-quirements, development and test phases. Without the data gathered from oursessions Moina wouldn’t have been the same.

I would like to thank my sister Katrine for providing the stunning graphicsfor Moina and my brother in law Rune for his guidance in report structure,information and ideas for the project.

Special thanks goes to Christian Pejrup for his time in teaching me about properprogramming techniques and structured system architecture. His invaluablehelp has made it possible for me to keep a high programming standard in Moinaand made me a better programmer.

Also, thanks to Spiir.dk, Banklog, Nordea, Danske Bank and Nykredit for show-ing interest in the project and providing various valuable informations.

In addition, I would also like to thank the people helping me with proofreadingChristian Pejrup, Rune H. Wiinberg and Preben Hillebo.

Last but not least, I would like to express my profound appreciation to mydear girlfriend, family and friends for their encouragement, understanding andpatience during the project period.

Contents

Abstract i

Preface iii

Acknowledgements v

1 Introduction 11.1 Background & Motivation . . . . . . . . . . . . . . . . . . . . . . 21.2 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Chosen Technologies & Methods . . . . . . . . . . . . . . . . . . 41.4 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Analysis 92.1 User Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Time Consuming Tasks . . . . . . . . . . . . . . . . . . . . . . . 152.4 Categorizing Approaches . . . . . . . . . . . . . . . . . . . . . . . 182.5 Moina Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Design 333.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Development & Test 474.1 Requirement Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Technologies & Third-party Components . . . . . . . . . . . . . . 514.4 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5 Implementation Examples . . . . . . . . . . . . . . . . . . . . . . 53

viii CONTENTS

4.6 User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Conclusion 635.1 Short Project Description . . . . . . . . . . . . . . . . . . . . . . 635.2 Chapter Tasks & Conclusions . . . . . . . . . . . . . . . . . . . . 645.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A Entrepreneurship Course Survey 69

B Test Group Interviews 73

C Users Requirements & Preferences 77

D Domain Driven Design Glossary 79

E Unit Test Example 81

F Product Backlog 83

G List of Acronyms 87

H Moina Screendumps 89

Chapter 1

Introduction

This chapter provides a short introduction to the project, and describes thebackground and motivation for choosing it. A description of the project and itsvisions for the solution. A summary of the technologies and methods chosen forthe project and an outline of the project chapters and their content.

Personal Financial Management (PFM) is currently, and has in the past coupleof years, been a market in rapid growth. This is the result of an increasing focuson PFM, since the global financial crises started in 2007.

Before the crises started, there were only a few old PFM solutions available onthe Danish market. These solutions never got commercial success, due to theamount of time needed by the users to manage their finances.

A new generation of PFM solutions are coming, and the development of timesaving features and good user interfaces is amongst the highest rated criteria’sfor their success.

This chapter will introduce the projects time saving PFM solution - Moina.

2 Introduction

1.1 Background & Motivation

In entrepreneurship there is a phenomenon called "The burning eye for oppor-tunities". It is a persons ability to see problems around him self, while havingthe capability to solve them and start a business based on the solution. In thewinter semester of 2009 at the DTU course 42435 Entrepreneurship the idea ofsolving peoples lack of financial perspective raised in a brainstorm. The problemwas thoroughly examined during the course and a survey1 with over 100 partic-ipants, showed that the main factor for peoples lack of financial perspective wasthe amount of time needed to acquire the perspective through available PFMsolutions. A time saving PFM solution was needed to solve the problem. Themotivation for choosing this project was to explore the possibilities of makingsuch a PFM solution, that could help people manage their personal finances.

1.2 Project Description

This project addresses the creation of a time efficient PFM solutions and be-fore such a PFM solution can be developed, a number of challenges must beaddressed.

Moina must be tailor made to suite the users preferences. Moina should thereforetake its origins in the users requirements. By knowing the users requirementsmore indepth, better decisions can be made on which features and function-alities a successful solution should provide. Related work in the PFM marketshould be examined with functionality, features and categorizing in mind, toavoid reinventing existing technologies and learn about the PFM market. Thepreviously acquired knowledge on the need for time saving features, leaves onlythe question of which interactions or processes is responsible for the high timeconsumption. Given that the key interest in this project is to bring down thisamount of time needed to get the financial perspective. What tasks are thenresulting in the unwanted large consumption of time? All the time demandingtasks, should be evaluated and examined for possible time saving possibilities.The previously discussed categorising feature is estimated to have high potentialin its time saving capabilities. This feature is likely to have many different cat-egorisation approaches, where some might be better than others. The differentapproaches should be toughly tested to evaluate their capabilities. Given theproject size, not all features and functionalities can be implemented in Moina. Aevaluation of the features and functionalities must be made to limit the solutionto the projects constraints.

1The surway can be found in appendix A

1.2 Project Description 3

The following tasks were identified and will be handled in the analysis chapter.

Task 1 Users requirements and preferences. Section 2.1

Task 2 Related work in the PFM market. Section 2.2

Task 3 Time consuming tasks of PFM tools. Section 2.3

Task 4 Categorization possibilities. Section 2.4

Task 5 Evaluate requirements. Section 2.5

User opinions for the final solution is mainly based on the looks and feel of theinterface. The interface is therefore rated as a high success criteria, and a suit-able user interface must therefore be properly developed to heighten the successrate. From the developers point of view, the system architecture and infras-tructure is just as important as the Interface. The architectural design shouldtherefore be made to follow some well documented and standardised guide linesand pre-approved software architectures.

This is summarized to the following tasks, handled in the design chapter.

Task 6 User interface. Section 3.1

Task 7 System architecture. Section 3.2

In order to finalize the requirement list for Moina, requirement testing shouldbe conducted. The requirements implementation status in Moina should berevealed. The technologies and patterns used to develop Moina should be ex-plained. Examples of requirement implementations in Moina should be shownand the user interface testing results listed. Finally Moina’s proof of concept asa time saving PFM solution should evaluated.

Hereby the following tasks which will be described in the development- & testchapter.

4 Introduction

Task 8 Requirement tests. Section 4.1

Task 9 Product backlog & implementation status. Section 4.2

Task 10 Technologies used. Section 4.3

Task 11 Design patterns used. Section 4.4

Task 12 Implementation examples. Section 4.5

Task 13 User tests. Section 4.6

Task 14 Proof of concept. Section 4.7

VisionThe vision for this project is to provide the basis for the practical use of Moinaas time saving online PFM solution. Moina’s interface should be appealing, andit’s features should make it easy for the users to manage their finances. Thecategorization features should categorize effectively and with high categorizationcorrectness. By reaching these goals Moina will reach its "Proof of Concept"milestone.

1.3 Chosen Technologies & Methods

Before starting the project, the technological boundaries has to be determined.In this section the various choices made for architectural design and program-ming technologies will be briefly elaborated on. This will provide an insight intothe fundamental technologies and methods used in the project, and why theywere chosen.

1.3.1 Architectural design

A lot of effort was put in learning about proper system architectural design.Amongst the highest rated was Domain Driven Design (DDD) which had somegood fundamental principles. DDD is an approach to developing good software.Its key principles is to place the projects primary focus on the domain and thecollaboration between technical and domain experts. To heighten the commu-nication and understanding between domain and technical experts a ubiquitouslanguage should be made to ensure that people agree on fundamental under-standing of the domain[7]. "DDD is not a technology or a methodology, itprovides a structure of practices and terminology for making design decisions,

1.3 Chosen Technologies & Methods 5

that focuses and accelerate software projects, when dealing with complicateddomains" as referred to in the DDD book[29]. DDD is known for its idealsconcerning system architectural structure. The structure should provide theoptimal conditions for proper and agile systems development, that reflects thecore domain of the project. The domain of this project is in this case a financialInstitute and would typically reflect some of the actions of eBanking restrictedto only viewing financial data. Knowing the domain is the key to developing theubiquitous domain language and therefore the system. The surrounding layersof the domain should all be able to be change without changing the domain. Bydoing so the system components can be seen as individual building blocks, thatall can be changed to test or implement new tools.

1.3.2 Frameworks

The different .NET 4.0 front-end frameworks was taken into consideration tofind the UI framework best suited for Moina. The goal was to find a frameworkthat would work on the broadest range of computers and operating systems,while providing an optimised working environment for the UI development. Inthe end the ASP.NET MVC 3 framework was chosen. ASP.NET MVC 3 empha-sizes clean architecture, design patterns, testability and is browsable from allplatforms, without downloading extra software, packages or plugins like Flash,Java, Silverlight and so on. This third and new version of the framework in-cludes many new and exiting features, that has made it a popular choice for.NET developers.

1.3.3 Object Relational Mapping

Object Relational Mapping (ORM) is a programming technique to convert databetween incompatible systems types. It provides a virtual object database thatcan be used from within the object-orientated programming language. [22].The three most popular free .NET compatible ORM frameworks available isNhibernate, Linq2SQL and Entity Framework. Linq2SQL work well and has afast learning curve. But the project has been terminated by Microsoft and willno longer be updated or supported. Entity Framework (EF) 4.0 has a mediumlearning process, is rather new on the market and has in previous versionshad critical bugs and lack the functionality of more mature ORM frameworks.The general opinion on the EF 4.0 version has been rather good, but as withmany new tools, if you get stuck at a problem, there is not much help to get.NHibernate has been developed in the Java community for over 16 years. Inthat time it has also been ported to the .NET Framework with great success

6 Introduction

and is today used in many big software development companies. It is extremelypowerful but comes with the cost of a hard learning process as referred to byayende[32] and gurustop[31]. The ORM framework chosen for the system was avariation of NHibernate called Fluent NHibernate. Fluent NHibernate offers analternative to NHibernate’s standard XML mapping files by letting developerswrite mappings in strongly typed C# code. This allows for easy re-factoring,improved readability and more concise code[11]. Fluent Nhibernate will handleall database interactions in Moina, and the creation of the databases.

1.3.4 Database

Fluent NHibernate is able to work with a lot of different databases: MicrosoftSQL Server, Microsoft Access, Oracle, MySQL, SQLite and many others. Thebest database types for the project came down to three possible types: MasterDatabase File (MDF), MSSQL and SQLite. For the development, testing andexperimenting a fast and easy workable database would be the best choice.Initially the MDF was tested, but eliminated as a candidate after few days dueto inconvenient work flow. The work flow was greatly enhanced with SQLite.As the name gives away its a very light database intended for speeding updevelopment phase implementations, speed up tests, and it can even act as anin-memory database to speed up the process further. The only real weakness wasthe lack of login security, but since this database is only meant for developmentand will not be used in the final release, it was perfect. For the final releasesto the Surftown hosted servers the MSSQL was chosen as it is in their standardselection of services and has a history of positive references.

1.3.5 Project Management

The development of software can be a complicated and unforeseeable process.Acknowledging highly probable development problems would therefore be thekey to provide a better development process. Following problems have beenidentified and acknowledged: Not all requirements can be known from the be-ginning, requirements may change during the process and new tools or tech-nologies may alter the process. Given these known problems it is needless tosay that agile software development is needed. SCRUM is one of the top 10agile project management tools available, and has in previews projects provenitself as a highly reliable project management tool. The SCRUM developmentprocess is not a linear process. It has no guidelines for right or wrong sequen-tial activities. Instead SCRUM processes makes everything as agile as possible.Agile scheduling, agile deadlines and many more agile strategies, all to achieve

1.4 Report Structure 7

a proper agile development process. In this project several changes has beenmade to the SCRUM tools and strategies. This was required to fit the projecttime span and the fact that it is a one man group. The SCRUM Backlog tool isone of the key scheduling and work plan combined tool in the managing process.The product backlog is a prioritised list of all the requirements for the system.Each of the product backlog items contains a sprint backlog with several sprints,that should take a pre-set maximum number of days to complete.

Hours

Figure 1.1: Modified image from Wikpedia [1]

1.4 Report Structure

An overview of the remaining chapters and their tasks, described in the projectdescription section 1.2 on page 3.

Analysis This chapter will handle the analysing and research tasks of theproject. Gathering the users ideas, requirements and preferences for func-tionalities and features in Moina. Exploring related work in the Danishand foreign PFM markets. Examine the time demanding tasks of com-monly used PFM tools and finding possible time saving solutions. Explorethe possibilities of helping and automating transaction categorisation inMoina. Finally evaluate and prioritize all found features for the projectsdevelopment of Moina. The chapter will thereby handle project descrip-tion task 1-5.

8 Introduction

Design In this chapter the user interface and system architecture will be de-signed. To design the User Interface some standardized guidelines onusability and user focused design will be examined before the making theschematics of the siteview and pageviews. The System Architecture sec-tion will describe how the DDD architecture should be designed in Moina.The chapter will thereby handle project description task 6 and 7.

Implementation & Test This chapter will elaborate on the implementationof the system and its various tests. Requirement test validations, theproduct backlog and implementation status of requirements, technologiesand design patterns used, implementation examples, the results of the usertests and finally the proof of concept evaluation. The chapter will therebyhandle project description task 8-14.

Conclusion In the conclusion chapter all the results and findings in the projectwill be summarised. The project will as a whole be concluded and futurework discussed.

Chapter 2

Analysis

This chapter will address the following tasks from the project description insection 1.2: task 1- the requirements and preferences of the users, task 2- relatedwork in the PFM market, task 3- time demanding tasks and their time savingsolutions, task 4- the transaction categorization possibilities and finally task 5the evaluation of requirements to be implemented.

2.1 User Preferences

With the knowledge acquired from the previous entrepreneurship course sur-vey1, the users need for a time saving PFM solution was established. Given thecriteria of success being the users opinion of the product, a deeper and betterunderstanding of the users preferences must be obtained. The relevant infor-mation to obtain at this point, would be the users opinions on the interfacelanguage and the available features.

1See the survey in appendix A

10 Analysis

With a small test group of eight potential Moina users in the age group 19-35,male and female participants, the stage is set for getting to know the userspreferences better. The test group members will be individually interviewedto document their preferences on language and features. The full interviewsessions can be found in appendix B, this section will only summarize certaininformations obtained from the interviews.

All group members agreed with the previous survey conclusion, when acknowl-edging that they would get a higher value from PFM solution that demands lesstime.

Below is listed the groups interesting and popular thoughts on features forMoina. The full list can be seen in appendix C.

Popular user requirements

• A quick and easy process to get the financial perspective.

• See financial data per month and per year.

• Remember previous manually categorized transactions.

• Static categories and subcategories.

• Visualise financial data with point and column charts.

• Automatic categorisation.

Interesting user requirements

• Few and intuitive key presses.

• Interactions with the charts leading to the relevant data.

• Manually adjust transactions to belong to different months.

• Preference for quality categorization, not quantity.

• Transaction text cleaned and filtered for irrelevant material.

• Split-up transactions.

• Input cash in hand purchases.

• Take the data directly from the bank.

• Anonymity and Budgets.

2.1 User Preferences 11

In the matter of interface language there is a tie between English and Danish,with three participants for English three for Danish and two with no languagepreference. The prototype version of Moina should only include one language,leaving the possibility of multi language functionality for future work.Project wise it would be preferred to have consistency between interface, appli-cation layer and documentation.

The English language has been chosen as interface language for the Moina pro-totype.

The users preferences shows a clear difference in age across the test group. Theyounger participants requirements an extremely easy solution that deals withtheir finances in terms of how much money they spend on partying, fast-food,phone bills and such. The elder participants are mainly concerned with thesolution being able to provide budgeting features to manage their fixed expensesand is prepared to spend more time to get the perspective.To limit the prototype an age segmentation must be done. Moina needs tospecify its primary target group in order to specify its features.

The systems primary target group will favour the younger users in the age group18-25.

This target group is chosen since the younger user requirements are predesessorsfor the budgeting requirements needed by the elder users.

All the test group members inputs on Moina features will be further processedin section 2.5. Here they will be evaluated with the rest of the analysis sectionsresulting features and produce a prioritised list of the features chosen for theMoina prototype.

2.1.1 Summary

The users preferences and requirements has been analysed in depth. This has ledto a better understanding of the context of use and the expected requirementsof users. A vast number of requirements has been found here for the Moinarequirements. The prototype user interface language has been set to be Englishand an age segmentation of the systems primary target group has been limitedto the age range of 18-25 years.

12 Analysis

2.2 Related Work

To learn about the PFM domain, market and trends, the current and upcomingsolutions on the market will be explored. The idea of providing a financialoverview by auto categorizing transactions has shown not to be a new or uniqueidea. The year 2010 was indeed a year with many new European PFM solutionsand rapid growth in the PFM market. In this section related work will beexamined with functionality, features and categorizing in mind. The Danishsolutions will primarily be in focus, but some of the interesting foreign solutionswill also be inspected.

2.2.1 Banklog.dk

With the help of Rasmus A. Makwarth, one of the founders of Banklog, somegood information was provided on their solution and a beta testing accountcreated. Banklog started in 2010 and is produced as a White-label2 product.Banklog started their closed beta testing late 2010. In this closed beta testingthey request their users to import their transactions with the csv file obtainedfrom their financial institute. Banklogs still intends to use only the cvs file data,if they get purchased and integrated with a financial institute, and thereby nottake advantage of the "extra data" the finance Institutes could give. They jus-tify this choice by the easing of workload and complications when implementingthe solution for a new client.

Banklog categorizes their users transactions with a algorithm that takes severaltransaction parameters into consideration; Transaction text, previous catego-rizations, user weighting, date and time.

In this projects test of the Banklog’s PFM solution 71% of the transactionswhere categorized, but unfortunately with many categorization errors. Thesolution had also a tendency to be very slow when importing and displayingtransactions.

2A product produced by one company (the producer) that other companies (the marketers)rebrand to make it appear as if they made it.)

2.2 Related Work 13

2.2.2 Nykredit.dk - Forbrugs Overblik

Information on Nykredit Forbrugs Overblik was gathered with the help of ThomasE. Kragh Senior Vice President Head of Nykredit Digital Channels. The Danishfinancial institute Nykredit has on their eBanking site a subsite named ForbrugsOverblik. The Forbrugs Overblik site is like the main site made in Java/Flashand they made their first public release in December 2010. Four months laterthe PFM solution was capable of categorizing approximately 80-85 % of theusers transactions and soon they should be able to do 90% with additional dataagreements. Being a financial institute also means that they only provide theirPFM service for their own customers. Forbrugs Overblik also uses static cate-gories and sub categories.

Nykredit has many advantage and privileges of being a financial institute. Theyget the customers transactions directly from sources like PBS, Visa, Mastercardand BEC 3. This direct stream of data means avoiding the tedious import andexport of transactions. The transaction data from the direct feed has some"extra information" not visible to the users and thereby not possible to export,hence not possible for solutions like Moina to obtain. Nykredit uses this datain a inhouse database named Informica, that amongst many other informationscontains all BEC transaction categories and their equivalent categories for theForbrugs Overblik solution. Further more they use data mining on the userschoices to improve the categorization. Unfortunately Forbrugs Overblik is onlyfor Nykredit customers, and therefore not possible for this project to test.

2.2.3 Spiir.dk

After a short talk with Spiir, they invited to a meeting on the 23 of February attheir offices in AArhus. Here the Spiir development crew introduced their solu-tion and heard about the Moina project. Spiir is a free Danish produced .NETonline PFM solution that was founded in August 2010. Spiir started closed betaFebruary 2011 and is still not an open public service. Their solution requires theusers to export a transaction file from their financial institute in order to uploadand import the transactions to Spiir. Their development of the solution has hada high focus on load time, they know from previous experience that slow systemswill results in a drop of users. The solution has predefined static categories andsubcategories, which they have spend many hours on deciding, given that theymust include a broad range of transaction types. Users can therefore not createtheir own categories. Spiir thinks it would be best to avoid individual categoriesto maintain the systems categorizing abilities. The system has had no use of

3Bankernes Edb Central

14 Analysis

dummy data, they just started with their own financial information and movedon to a small test group. All members of their test group categorized their owntransactions to start up the system.

Spiir has based their categorization engine on word recognition. The word recog-nition approach splits up the transaction text in individual words, and each ofthe words will have a statistical probability to become one of the categoriespreviously chosen for the words. The probability for a category being chosenfor a transaction is weighted by the amount of users involved in the calculation,the users individual previous category choices and the global category choices.In their Alpha phase Spiir was solely depended on the word recognition, but thesolution had a tendency to increment incorrect categories and the Spiir develop-ment team therefore now manually approves all the word categorisation rules.This manual labour requires a lot of extra work.

In this projects testing of the Spiir PFM solution, 39% of the transactions wascategorized and some categorization features was not working correctly. Spiir’ssolution is however the best public service PFM solution seen in Denmark so far.This judgement is not based on the categorization percentage but on the factthat Spiir provides a public service, where the two other Danish PFM solutions,Banklog and Forbrugs overblik, only provide a service for individual financialinstitute customers.

2.2.4 Foreign PFM Solutions

The Spiir, Banklog and Nykredit systems is well on their way on the Danishmarket. PFM solutions can also be found in other countries around the world.USA is leading the way with more than a hundred retail banks rolling out PFMsolutions. Europe is behind USA in terms of PFM awareness, as only a handfulof PFM offerings have emerged in Europe and most markets still have no PFMservice. BBVA (Spain) and Islandsbanki (Iceland) were the first Europeansfinancial institutes to offer comprehensive PFM functionality to their customersand in both cases PFM became an instant success[16].

Mint.com started in 2005 and has today over 4 million users and is addingover 3,000 new users every day. It is a free service and America’s number onein online personal financial services. They connect directly to all the usersfinancial institutes and insurance companies since they use the same securitysystems that major financial institutions use. They take advantage of the directstream of financial information without the tedious import export. Mint.com isproperly the leading PFM system in the world with millions of users, outstandingfunctionalities and direct integration with then American financial system.

2.3 Time Consuming Tasks 15

Meniga.is is a White-label PFM Solution for Financial Institutions. Menigaoriginated from Iceland and went live in 2009 in partnership with Islandsbanki.Over 6% of Iceland’s population uses Meniga and they are growing every day.They have since expanded to Meniga.com and is now available in Sweden, Ger-many and England.

2.2.5 Summary

While exploring related work in domestic and foreign countries a better under-standing on the PFM Domain and market has been established. Analysing thedifferent PFM solutions has led to many new requirements for Moina. The mar-kets different ways of categorization has been noted for evaluation as Moina’scategorizing engine. Its was made clear, that static categorise for the catego-rizing, would help get better results in the start-up phase of Moina. The greatadvantages of having a direct feed with a bank has been established. The Dan-ish PFM market is far behind in PFM awareness, resulting in Danish financialinstitutes being unwilling to share informations as first movers with third-partyapplications like Moina. The Danish market also showed that only one of thePFM solutions where actually a public service solutions. The free public servicePFM solution Spiir has potential, but their categorization percentage was, inthis projects test under 40%. Better ways of doing the categorizing the trans-actions must be possible, to get higher transaction categorization percentage inMoina.

2.3 Time Consuming Tasks

This section will look at the time consuming tasks of today’s commonly usedPFM tools and discuss possible time saving features to ease the tasks. Sincethere are no open public PFM services available in Denmark, this project willgo through the process of gaining a financial perspective with the available andmost commonly used tools today. To learn what tools people uses to managetheir personal finances this project has contacted the financial advisers of thetwo Danish financial institutes Nordea and Danske Bank. Both institutes hadthe same standard response to all customers seeking PFM tools,the MS Excelsoftware used by an estimated 450 million users world wide. Excel is by farthe most commonly known and used tool to help people manage their personalfinances world wide. This project will run through a simple scenario of managing

16 Analysis

a persons finances with Excel, to find the time consuming tasks and discusstime saving solutions. All time estimates in this section is approximated onthe time consumption of an average user. An average user is in this case anuser with no technical or financial background and no expertise in Excel. Tospecify the amount of work to be done in this scenario one month of transactionswill be processed. The average amount of transaction per month has beenapproximated with statistical information4 on Danish citizens in the year 2009to be 32 transactions per month per citizen.

The fist step is to retrieve the transaction data from the financial institutes andpersist it. This data can be retrieved by getting the transaction on paper, on aexported csv5 file or in special cases with a direct data feed from the financialinstitute.

The paper version would require several hours of work given that the user wouldhave to type in all the information by hand. The exported file version wouldrequire an estimated five minutes of the user, allowing him to login to his finan-cial institute and export the file. The direct feed would be the optimal solutionwith no time required.

For excel the fastest possible way would be to import the csv file and for thisproject the following solutions has come into consideration.

• The direct feed would be the optimal choice, but haven’t been obtainabledue to neither Nordea nor Danske Bank being willing to provide such aservice.

• With the file version being the least time demanding choice left, uploadand import features could be implemented to allow the importation oftransactions.

Secondly the transactions should be categorized. Returning to Excel, the trans-action data is now displayed in a column list form with a row for each transac-tion. Each of the transaction listed must be inspected by the user to figure outwhich category it should be associated with. This is approximated to 30 minof work per month. This is a tremendous monthly workload for the user andpossibly the main reason for the lack of peoples financial perspective

To ease this massive time demanding task, categorizing features must beenfound. These categorization features will be the subject of section 2.4.

4Statistics from Finansraadet[9] and Danmarks Statistik[6]5Comma-Separated Values

2.3 Time Consuming Tasks 17

With the transactions categorized the next step would be a simple numericsummary of the transaction data. Setting up an Excel sheet to summarizeall the different transactions based on their category and provide the numericperspective is not an easy task for the average user and would require some timeand effort. The workload is estimated to 2 hours of work for setting up the excelsheet and an estimated 10 minutes per month to maintain the sheet structure.

• A group based summary feature should provide the relevant numeric fi-nancial perspectives.

The Visualization of the transaction data is the last step in providing the finan-cial perspective. Here the data must be visualized using relevant excel graphs.Setting this up graphs in Excel to interact with the different groups is esti-mated to 30 minutes of work in the setup process and and 10 minutes of workper month to maintain.

• A visualization feature should provide the user with a the visual financialperspective.

This concludes the simple Excel scenario. A total estimated work load to setupExcel and process one month of transactions is 3 hours and an additional 50min for each extra month of transactions. The more advanced Excel scenariosand their optimizations and maintenance difficulties will not be discussed inthis section. The resulting time saving features from both simple and advancedscenarios will be processed in Moina Requirements section 2.5 on page 29.

2.3.1 Summary

The users most commonly used PFM tool is found to be Excel. With Excel asPFM tool the process of getting a financial perspective has been analysed leadingto new requirements for Moina. The possibility of a direct transaction data feedhas been declined by the financial institutes. The amount of transactions for anaverage Dane has been calculated to 32 per month, with statistical informationfrom 2009. The requirement for time saving categorizing features has beenestablished. It is estimated that an average user would in order to acquire aproper financial perspective need 3 hours to setup and organizing to handle onemonths transaction in Excel and an extra 50 min for every additional month oftransactions.

18 Analysis

2.4 Categorizing Approaches

The categorization feature has been rated as a high potential time saving feature.With the knowledge gained from this chapters test group interviews and therelated work research, a overview of the users categorization requirements andcategorization possibilities has been acquired. At this point of the project, threetime saving categorization strategies looks like they have potential:

• Mass categorization allowing multiple transactions to be categorizedsimultaneously.

• Previous categorization helping the user categorize transactions accor-dantly to his previously categorized transactions.

• Network categorization taking advantage of data gathered in a collab-orative network to categorize transactions.

These categorizations strategies is the main subject of this section and will beanalysed for their potential. But before addressing categorizations strategies, itis necessary to analyse the data they should work on.

2.4.1 Transaction data

This project has access to personal transaction data from the two Danish finan-cial institutes Nordea and Danske Bank. These two Institutes is amongst thebiggest financial institutes in Denmark and therefore also a good place to startanalysing transaction data. Lets first inspect the transaction data exportedfrom Nordea in the given csv file format.

Listing 2.1: Sample of data from a Nordea csv file

12-08-2010;Dankort-nota Falkoner Bio 86741;12-08-2010;-20; 35310-08-2010;Dankort-nota The Bagel Co. 23337;10-08-2010;-68; 37409-08-2010;Bs betaling DK HOSTMASTER A/S;09-08-2010;-45,00;443,1309-08-2010;Bgs Sommerhus tur;09-08-2010;-1093,29;488,13

The Nordea transaction data in listing 2.1 has the following five data fields; Date,Text, Rate Date, and Balance. The most important field here to analyse is thetext data field, containing the vital information enabling the categorization.The first Nordea transaction text field "Dankort-nota Falkoner Bio 86741"has 3 different types of information embedded. The "Dankort-nota" describesthe transaction type, "Falkoner Bio " describing the transaction place and

2.4 Categorizing Approaches 19

finally the number sequence "86741". By consulting Mark Helmbo from Nets6Verification Operation and Regression Test apartment, the numbers was clari-fied as transaction serial numbers provided by the credit card terminals. Sincethese numbers are incremented serial numbers, they provide a unique number foreach transaction on each terminal. These numbers obstruct with the categoriza-tion possibilities given that they make the text fields different from transactionto transaction, making them unique and not full text comparable. These num-bers should be excluded from the categorization process. The transaction typeswould also obstruct the categorization process, given that the different creditcards types includes their own text like "Dankort-nota" making them less com-parable to other transactions from the same place but with a different creditcard type. The transaction type should also be excluded in the categorizationprocess. The remaining text "Falkoner Bio " specifics the transaction placeand should be used as basis information for the categorization. The informationis also polluted with white spaces and should be trimmed before processed. Thecorrectly formatted information is shown in listing 2.2

Listing 2.2: Trimmed Nordea basis categorization data in csv file format

12-08-2010;Falkoner Bio;-2010-08-2010;The Bagel Co.;-6809-08-2010;DK HOSTMASTER A/S;-45,0009-08-2010;Sommerhus tur;-1093,29

Listing 2.3: Sample of data from a Danske Bank csv file

"05.01.2010";"Imperial 56125";"-61,00";"8.699,79";"Udfort";"Nej""06.01.2010";"Bagergaarden 74604";"-23,50";"8.676,29";"Udfort";"Nej""06.01.2010";"Illum 47454";"-900,00";"7.776,29";"Udfort";"Nej""06.01.2010";"Georg A/S 18158";"-100,00";"7.676,29";"Udfort";"Nej"

In listing 2.4 the exported transaction data from Danske Bank shows someobvious difference from the Nordea data, in both format and structure. Here thedata structure is given by six data fields; Date, Text, Amount, Balance, Statusand Settled, where all the data field informations are surrounded by quotationmarks and the dates is differently formatted with dots instead of dashes. Wheninspecting the transaction text, the transaction place and serial number is stillpresent but the credit card type information is left out.

To be able to compare transactions between different financial institutes, onlythe comparable data should be used and must therefore be the same format. Toachieve this comparability the transactions should be processed and trimmed tomeet at common transaction standard format in data fields, text and formats.The date, amount and transaction text’s place information should be includedas information for the categorization and their formatting differences corrected.

6Previously known as PBS

20 Analysis

Listing 2.4: Trimmed Danske Bank basis categorization data in csv file format

05-01-2010;Imperial;-61,0006-01-2010;Bagergaarden;-23,5006-01-2010;Illum;-900,0006-01-2010;Georg A/S;-100,00

Nordea and Danske bank is, as previously stated, amongst the biggest financialinstitutes in Denmark and as shown in the two data samples, they each have theirown way of formatting their export data. The two institutes data formats willbe the first two data formats supported by Moina. The reason for choosing bothNordea and Danske bank is also to show the possibility of handling multiple dataformats. The next supported data format should undoubtedly be the BEC7 dataformat. BEC provides eBanking solutions for most of the medium and smallerfinancial institutes in Denmark.

Import Data Requirement Tests

• Format and trim transactions to meet a common standard.

2.4.1.1 Data vulnerabilities

In the research of related work and the financial institute domain, some vulner-abilities concerning the financial data has occurred. The projects PFS solutionshould sort already existing transaction from new transaction to avoid redun-dant data, easily done by checking for existing transactions before importing.To enable this check for existing transactions the transactions themself musthave a unique identifier. The transactions unique identifier should use the origi-nal text field in a combination with other transaction data fields and some otherpersonal id like the user id or financial account id. To uphold the uniqueness ofthese transactions, none of the data fields included in the combinatorial uniqueidentifier must change over time. Unfortunately in rare occasions the transac-tion place information embedded in the transaction text field could, be changedif requested by the terminal owners. This would normally not be a problem,but the financial institutes also updates their old transactions with this newinformation making them new to the unique identifier and adding them to thedatabase creating redundant data. Simply excluding the text field from thetransaction identifier is not an option, due to the small amount of data avail-able per transaction. to make them unique. Simply processing the newer datedtransactions would also make complications, if the user wanted to import oldertransactions. The problem is weighted as a nice to have feature due to its low

7Bankernes Edb Central


occurrence frequency and its minimal impact on the proof of concept prototypeversion. Changes in Nordea or Danske bank could result in formatting changesin their transaction export files. New formatting in these files would providesome maintenance work, to keep Moina’s import functionality up do date.

2.4.2 Mass categorization

The mass categorization strategy is supposed to save users time by letting themcategorize more than one transaction at a time. But how should the user getthe relevant transactions for the mass categorization.

An approach could be to list all the identical uncategorised transactions in stackssorted by the number of identical transactions in the stacks, making it possiblefor the user to categorize identical transactions with the same category.

Another approach could be to make it possible for the user to search in his trans-actions. Searching for "Netto" would for example result in all of his transac-tions with "Netto" embedded in the transaction text, like the "Netto Finsensv"transaction text and so forth. A single categorization field could then allow theresulting transactions to be categorized as a group. To save the user furthertime in typing these words, the transaction text could be split up in individualwords allowing the user to just click the word to initiate a search with the word.

The third and last approach for mass categorization at this point, is the manualselection of multiple transactions on a list. For this selection a separate cate-gorizing field should be provided to make it possible to categorize the selectedtransactions as a group.

Mass Categorization Requirement Tests

• Stack identical transactions and mass categorize them.

• Split the text up in words, search for transactions with the word and masscategorize them.

• Select multiple transactions on a list and mass categorize them.

2.4.3 Previous Categorization

This strategy is intended to help users by categorizing newly imported trans-actions, according to the transactions previously categorized by the individual

22 Analysis

Previous categorizing algorithm - Process a transaction

Processing transaction done

Search the users transactions for similar

transactions with categories.

Pick the category with the highest

transaction count

Pick the category from the result

Multible Results

No Results

One Result

Leave the transactions

category to its default value

Figure 2.1: Previous Categorization actions flow

users themself. The test group showed a specific interest in this particularfeature and it should therefore be the first automated categorization featureimplemented in Moina.

New transactions should be processed with this strategy directly after beingimported, trimmed and formatted.

It provides a reliable consistency between the specific transactions and the cate-gory, they should receive. To keep this consistency the strategy should only usethe trimmed full transaction text as comparison parameters and avoid compari-son approaches like words comparisons and so on. It could also be a possibility toprocess transactions on-the-go and not just when importing; but the functional-ity of handling multiple transactions is best handled by the mass categorizationstrategy.

In this strategy’s query for previously categorised transactions, three differentscenarios can occur. In fig. 2.1 the flow chart visualises the three differentscenarios. If no categorized transactions is found with the same transaction text,the category will remain at its default value, indicating that it has no category.If only one transaction is found the processed transaction should receive the


same category as the transaction found. Finally if multiple transactions shouldbe the result of the query, the category with the highest transaction count shouldbe chosen.

Previous Categorization Requirement Tests

• Query for previous transactions with full text comparison

• Selecting a category for the processed transaction based on the count oftransactions in the found categories.

2.4.4 Network categorization

Taking automated categorization to the next level would be to exclude the usertotally from the categorization process and thereby maximizing the time savingfactor. This would be possible by "sharing" the users categorization data acrossa collaborative network. By taking the advantage of a collaborative networkthe whole network now provides informations on how a transaction should becategorized, thereby implicitly helping each other categorize transactions. Theknowledge shared between users would make it possible for a new user to takeadvantage of the existing categorization data. By correcting categories on hisown transactions and categorize the uncategorised transactions he contributesto the network. The expression "Give a little, get a lot" is the fundamental ideabehind this type of networks.

Lets look at some approaches to achieve the transaction categorizing function-ality, using the advantage of a collaborative network.

2.4.4.1 Collaborative Filtering

Collaborative filtering (CF) is amongst the most used technologies for filteringdata sets for information, using techniques that involves collaboration betweenmultiple data sources. CF methods can be applied to many different types ofdata, most known to the public is it usage in web 2.0 applications like IMDB8

or Last.fm9. Collaborative filtering is here used to make predictions (filtering)about the films or music interests of a user, by collecting information from manyother users (collaborating). The fundamental idea of the CF approach is that

8The Internet Movie Database9Music data collecting service

24 Analysis

"those who agreed in the past, tend to agree again in the future", this soundpromising for categorizing purposes.

In this section CF will be analysed for its capability as a categorisation func-tionality for financial transactions in Moina. Lets take a look at the data andthen decide what CF methods to use.

In applications like the IMDB and Last.fm the data used in the CF calculationsis either users ratings on films or the amount of times a user has heard songs.These data types differs from the data types available in a transaction catego-rization comparison. Film ratings is typically a numeric value between one andten, where one is dislike and teen is like. This numeric data can be used inmathematical calculations to produce continues numeric valued summaries likemean and average. In Last.fm the amount of times a user has heard a song isalso a numeric value indicating how much the user likes the song, giving thesame mathematical possibilities as film ratings.

The financial transactions is for categorization purpose only comparable by itscategories and herein lies a problem. Transaction categories are only comparableby equal and not equal discrete values, like the boolean values true and false.The categories can therefore not produce continues numeric summery values,limiting their mathematical capabilities. A custom CF formula would have tobe made, but before getting ahead of ourselves, lets look at some CF methodsand their capabilities.

The most traditional way to construct CF recommendations functionality isto use either Nearest Neighbour, Clustering or Graph Theory in the field ofmemory based CF. The Nearest Neighbour and Clustering methods is usedin both Last.fm[15] and IMDB[5] applications. The two methods uses eitherEuclidian Distance10 or the Pearson Correlation11 to provide User-To-User andItem-To-Item similarity approximations. If the two similarity approximationswere transformed into their resulting functionality with a system like Moina thefollowing functionalities would be possible.

Item-To-Item Provides a number indicating how similar two categories are.This could possible be used to sort categories in their main and sub cat-egories. But the functionality would only be usable if the categories werenon static categories created by the Moina users. At this point the cate-gories in Moina has been determined to be static, to heighten the catego-rizing possibilities. Not much use for this functionality.

10Euclidian Distance - a way to calculate the distance between objects in a space11Pearson Correlation - a way to calculate the distance between one objects and the corre-

lation line of multiple objects


User-To-User Providing a number indicating how similar two users are basedon their transactions categorization choices. This would allow Moina tocalculate the similarity between users in the system and only use the mostidentical users for categorization purposes.

The big question is now whether users with high similarity in their categorizingwould categorize that much different from other people with less similarity. Toexplore this further let’s focus on the categorization of some transaction typesand see if the functionality of identifying similar users, would give differentcategorizing results.

The average user would most likely categorise transaction types like supermar-kets, cafes, shopping centres and restaurants the same. Transaction types wherethe similarity information would come into play, could be transaction types likea gas station where a high school student might categorize the transaction asa kiosk and a 40 years old married man would categorize it as transportationexpenses. But with these types of scenarios it would be much easier just tomake amount limiters, choosing different categories if the amount was over orunder the limit. The limit should be set with static limits by the system, asthis project has no scope for dynamic limiter functionalities like system lean-ing abilities. Few other transaction types has been found, where the similaritycome in to play and all of them has easier solutions to overcome the differentcategorization patterns. It is the assumption of this project that transactioncategorization data would only in special cases be improved by a similar usercategorizations other than that of an average user.

The CF similarity approximation methods Nearest Neighbour and Clusteringhas been assumed to have insufficient capabilities for this projects data. As aresult to this the CF strategy will be marked inadequate for the project andexcluded from the network categorization approaches.

2.4.4.2 Custom Categorization Algorithm

The main problem with the Collaborative filtering approach was its perspectiveon the data being wrong, for the purpose of categorizing transactions. With theknowledge learned from the CF strategy, let’s explore the possibilities of makinga custom build algorithm utilising the advantages of a collaborative network forthe purpose of categorizing.

The two most important parameters in the categorizing must be the transac-tion’s text and category. With these two informations, statistical and mathe-

26 Analysis

matical operations can be used on the transaction data sets to provide infor-mation showing the norms for the categorizations. This type of information isgathered from all transaction in the data set and not just the transactions ofsimilar users. Gathering a transaction’s categorizing information from the en-tire dataset would provide all the different categories chosen for a transaction,leaving many options for the final category choice. Choosing the most appro-priate category would require the wisdom of the crowd, being the law of largenumbers. This means that the average user would be most likely to choose thesame category as most of the other users have chosen. To calculate this informa-tion all the categories that a transaction has previously been categorized with,should be listed in a group. Each of the categories in the group should then begiven a numeric value indication of, how many times this specific category hasbeen paired with the specific transaction. All the numbers should be added up,and each of the categories in the group should get a continues numeric valueindicating how big a percentage of the total category selections they have.

In other words when processing a transaction for its category, the category thathas been selected most frequently for the transaction in the past should bechosen.

Limitations could insure that only categories with a high percentage of belongingtransactions in the query should be chosen. A category choice between 3 cate-gories with 30%, 30% and 36% of belonging transactions in the query, resultingin the category with 36% being selected just because it had the highest percent-age number of the three would obstruct with the quality of the categorizations.Quality selection limiters will however be a "nice to have" requirement, untilimplemented count will do for the selection calculation.

When looking for other parameters to make the custom algorithm better, notmany suitable parameters can be found. The transaction itself contains twoother parameters usable in special scenarios, the date and the amount. Thedate could be used to see patterns in the users habits in different monthly oryearly periods like Christmas presents, vacations and such. But this idea is abit far stretched for special transaction scenarios only and not suitable for theprototype. The amount could be used as a limiter in special transaction scenar-ios like the previous mentioned gas station scenario, where the amount is usedas a limiter for the different categories. This could be a possible parameter forthe algorithm but again it’s only for special scenarios and not for the prototype.The user could provide some parameters in the form of demographical data likegender, age and geographical location. They would however also only help inspecial scenarios and would not be for the prototype.

One of the first parameter, the transaction text, holds a little more usableinformation, than it would seem. So far in this algorithm the transaction text


has been seen as a whole text only comparable by its full length of text. Butwhat if the words embedded in the text, were to be used instead of, or side byside with the text.

Word recognition - Extracting words from the transaction text would makeit possible to categorize transactions based on categorized words instead of cat-egorized transactions. This would make it possible to cross-reference wordsfrom different transactions and still use their categorization data, even thou thetransaction texts are not fully identical.

Adding the functionality of the word recognition to the present algorithm wouldneed some small modifications in the final category choosing. The rest of thestrategies for the full text approach is directly transcendent to the word recog-nition approach.

The end result would be an algorithm using both the full text approach and theword recognition approach weighted as equals in the final category choosing.

Transaction

Category

Custom Algorithm

Transaction text

Transaction words

Query similair

Calculate categories

Select category

Figure 2.2: Custom algorithm function machine

Custom Categorization Algorithm Requirement Tests

1. Split transaction text in words and persist the words for future usage.

2. Query for words and text resulting in the different categories they havebeen given in the past.

3. Frequency values on the category, word and text pairs.

28 Analysis

4. Calculate the categories individual percentage of the total category selec-tion.

5. Selecting the final category by evaluating with the found information be-tween the remaining categories.

2.4.5 Categorization Kick Starter

The categorization features should provide the Moina "wauw effect", by "au-tomatically" categorizing the users transactions as best it can, with the dataavailable. But power of the crowd comes into play here. The more users reg-istered in Moina the greater the "wauw effect" it can provide and the greaterthe "wauw effect" are the more users will sign up. But unfortunately it has alsothe reverse effect, the less "wauw effect", the less new subscribing users. The"give a little, get a lot" idea falls to the ground, when Moina’s first users feelsthey give a lot and get very little in return. To get the "wauw effect" going andget users to register, some sort of kick-starter for the categorization would beneeded. Moina needs start up data to be able to give something back to thefirst users, but how should Moina get a hold of such data?

An idea would be to feed the system with word and category pairs that has beenpre-approved by Moina. The pre-approved list could for example be all Danishsupermarkets names saved as words paired with a category, indicating that theywhere category type groceries. Other examples of easy categorised words couldbe the names of retail stores, restaurants, cinemas, gas stations and so on.

This kick starter strategy would be a "nice too have" approach, given that itsonly for the convenience of the first Moina users and therefore not a part of theproof of concept

2.4.6 Summary

The import transaction csv data has been analysed for data structure, patterns,possibilities and vulnerabilities. A trimming and formatting of the transactionsdata is necessary to be compatible with multiple financial institutes and to pro-vide less polluted transaction texts to the user. The Import data requirementtest has been described. The BEC format should be the next transaction datacompatible format type. The Mass Categorization approach was analysed for itspossibilities and its requirement tests described. The Previous Categorisationapproach has been analysed and prioritised as the first categorizing requirement

2.5 Moina Requirements 29

to be implemented in Moina and its requirement tests described. The NetworkCategorization approach was analysed for the possibility of using the collabo-rative filtering method as its categorizing engine, but it was found unsuitablefor the task. With knowledge from the collaborative filtering, testing analysinga custom algorithm including word recognition was planned to handle Moinasnetwork categorization and its requirement test described. The different waysof kick starting the categorizing feature and thereby provide a better startupphase for Moina’s first users has been analysed and its possibilities added to therequirements.

2.5 Moina Requirements

This section will summarize, prioritise and evaluate all requirements found inthis analysing chapter for the projects PFM solution Moina. The requirementswill be displayed in the prioritised list form in the must have, should haveand nice to have order. Knowing from DDD that not all requirements can beknown at this point of the project, this list can be seen as an consecutive andcontinuously updating list that will eventually be turned in the prioritized im-plementation list, the Product Backlog. The list below will only contain theitems discussed in the report up until now and not all the specifications or in-tuitive basic application development information. These types of informationswill be visible in either the Product Backlog items or Sprint backlogs items.

Must Have:

• Import financial data from a CSV file.

• Import comparability with multiple financial institutes.

• List financial data by relevant group like year, month category and soforth.

• Help users categorize their transactions based on their individually previ-ously categorizations.

• Provide static categories to categorize transactions.

• Users must be able to categorize and recategorize their transactions.

• Simple numeric overview of the transaction data.

• Simple graphical visualisation of financial data in relevant graphs.

30 Analysis

Should Have:

• Multiple financial accounts compatibility for users.

• Prototype version login security with user authentication.

• Custom categorizing algorithm to help categorize the transactions withthe help of other users work.

• Unit Test on prioritised elements.

Nice To Have:

• Month tags to let the user decide which month their transactions shouldreside in.

• Manually mass categorize multiple transactions.

• Static subcategories.

• Kick starter strategy - pre approved word category pairs lists.

• Manual input entries with cash in hand purchases.


• Search functionality.

• BEC data import comparability - compatibility with hundreds of smallerDanish financial institutes.

• Split up transactions.

• Prototype version login security with user, roles authentication and ad-ministration.

• Comparability with transaction changing text with backwards effect onimported transactions.

• Quality category selection limiters

Possible future features:

• User individual categories.

• Multi language integration with English and Danish.

2.5 Moina Requirements 31

• Budget.

• Take the data directly from the financial institutes.

• Transaction Tags.

• SMS Notification.

• Custom algorithm updated with time and date parameters for specialscenarios.

Intuitive & non functional requirements

• A quick and easy process to the get the financial perspective.

• Anonymity.


• Separate income and expenses.

• Uphold a quick UI to avoid user dropping.

• Make all the financial summations and calculations.



• Transactions not overlapping.

2.5.1 Summary

All requirements found in the analysing phase was evaluated and prioritized inthe must-, should- and nice-to-have form. This was done based on the projecttime constraints, project objectives, proof of concept demands and with weight-ing of the primary target group requirements.

32 Analysis

Chapter 3

Design

This chapter will address the project description design tasks from section 1.2 onpage 2. Task 6 user interface will be addressed first, handling the usability, pagesetup and graphical layout of Moina. The second half of the chapter will addresstask 7 system architecture, concerning Moina’s system architecture, layers andtheir dependencies.

3.1 User Interface

Designing a successful graphical user interface (UI) can be a challenging andcomplex process. It involves elements from other fields such as design and psy-chological behaviour. These elements are not a part of the computer science-/software engineering fields, but still commonly acknowledged as important fac-tors for the development of successful software applications. Users opinionswill always be subjective and as a result, no complete guide can be made on asuccessful UI design. But there are however some well documented and stan-dardised guidelines. Lets first take a look at some guidelines for usability andhow they could be implemented in the Moina interface.

34 Design

3.1.1 Usability

Users focus has today shifted from features offered, to the ease and convenienceof operation, and how fast the software can be mastered - the users focus is nowon the user interface.

Users of software will today check issues like how many key strokes are requiredto perform tasks. Are the flow of key strokes and help guides intuitive enoughor are they confusing? In other words, the user is reviewing usability as one ofthe parameters while deciding the choice of software. Usability is defined as theease of use and learnability of a human-made object.

In this project the object is the web site Moina and the usability therefore relatedto the human interaction of its user interface. The usability of Moina will focussolely on interactions with its interface, and how it can be made simpler, fasterand more efficient.

Many well planned and high-end websites has failed to become successful, dueto confusing and non-intuitive user interfaces. To avoid this, standardized inter-face design must be incorporated in an early stage and become a part of everydevelopment task.

The ISO 9241/110 standard[12] describes standardized usability requirementsfor interface design from its Look & Feel perspectives. The "Feel" is the dynamicinteraction with the interface and the "Look" is the static representation ofthe site. The standard emphasises easily understood interfaces and intuitiveplacements of information and interaction objects. The Look, Feel and Guidanceperspectives of the standard will be described in the following sections, and howthey should be incorporated in Moina.

Look

Visualization: The users should be keept well informed of Moina’s currentstate by always visualising the state on the interface. Users awarenesscould also be achieved by using status messages to inform about currentsystem actions and providing progress bars on time demanding tasks likethe upload transactions functionality. These would also help the user fromgetting impatient during load time and informing him of the process incurrent actions.

Detectability: Draw the users attention towards the desired part of the inter-face. This makes it less confusing for the user and speeds up interaction

3.1 User Interface 35

with the interface. An example of this could be, when the user shouldfill out a form like the Moina user registration form, where different datafields has individual validation requirements. If the data fields in the formhad invalid data input, detectability should direct the user to the invaliddata fields by highlighting them and describing the validation error.

Comprehensibility: Everything written on the website should be easily un-derstood for all types of users. To achieve this, Moina’s written text shouldbe of proper language structure, readable font type and size, and with anappropriate background texture and color for easy readability with thefont colours.

Self-descriptiveness: It should be clear for the user, what to do in eachstep of every action. A way to make this possible in Moina would beto provide self explanatory headlines, short introductions on interactionsand feedback on the users actions and lead them to actions, if they areapparent by the system. An example of this, could be when a first timeuser logs in, he gets redirect to the create financial account, because hehas no accounts.

Feel

Flexibility: The interface should support a wide variety of users with differentbackgrounds and qualifications. Understanding the different user levels isneeded to design Moina with only one interface supporting all user levels.Different ways of accomplishing tasks should be provided for different userlevels. Wizard mode could help first time users retrieve the transactionscsv file from their financial institutes, where intermediate or advancedusers should have a more direct approach.

Safety: The interface should provide safety nets for the users. Safety nets areadditional user safety options making it possible to do actions like verify,cancel or edit informations about to be submitted. The idea is to have theuser become more comfortable with the system and his actions. Moinashould implement safety nets on information changes like delete, edit andupdate objects. Safety nets must however not reduce the experience of theactions like changing categories on transactions or tagging transactions.

Learning: Users interacting with an interface becomes better at using it andwill discover new features and better ways to accomplish tasks. This learn-ing curve is a testable factor, where the objective is to shorten the periodof time, it takes a user to go from first time user to expert user. An exam-ple of discovering new features could be the first time users categorizing

36 Design

each transaction individually, where an expert user would use the masscategorization functionality.

Efficiency: Providing less work for the users to accomplish tasks or havingthe user become an expert in a system features, allowing him to accom-plice tasks faster. This is yet another testable factor commonly used incalculating the time, it should take to follow steps needed to accomplish atask. An example of less work could be to automate and exclude a step inthe process like the previously mentioned create financial account step fora first time user, allowing the user to faster start importing transaction tothe financial account automatically created for him.

Guidance

Help: Helping the user is another way to guide the user in the right direc-tion. A short and well written explanation of the task at hand in a pop-upmessages, wizzard, or step-by-step guide, would make the user more likelyto use the system as intended. An example could be the import feature,where the user should provide a csv file exported from his financial insti-tute. A guide could be provided with instructions on, how the file shouldbe exported from the institute, and how the file is then imported to Moina.

Error management: Error management is the systems ability to handleerrors. Errors could be illegal actions or malfunctioning functionality inthe system. These errors should be handled internally in the system, andthe system should then provide custom error messages for the user. If theusability aspects Help and Self-descriptiveness is properly implemented, itwould result in a minimal amount of user prevented errors, hereby greatlyeasing the systems error management task.

If the Look and Feel perspectives are kept in mind during development, andthe interface corrected during development with feedback from a test group,the Interface design has a good chance of becoming a successful user-centeredinterface.

Lets take a closer look at, how user-centered interface design is done beforeproceeding to the actual design of the Moina UI.


Figure 3.1: ISO 13407 Model[27]

3.1.2 User-Centered Design

The idea behind User Centered Design (UCD) is to actively involve the usersin the project to customize the interface to their requirements. This gives thedevelopers a unique opportunity to test their expectations on interface usageand correct them with the help of the users feedback. It is important in thisuser-centric process to base UCD on an indepth, clear-cut understanding of thecontext of use and the expected nature of users.

The ISO-standard 13407 1[27] standard provides a framework for user-centereddevelopment activities. These activities can be adapted to numerous develop-ment methods including the SCRUMmethod used in this project. The UsabilityModel described in ISO 13407 and displayed in figure 3.1 shows the five stagesof the model, four of which are in a loop.

The first three stages of the usability model has been accomplished previously inthe project with the specification of the target group and the users involvementin the requirement specification. These tasks are described in the users prefer-ences section 2.1 on page 9. With the target group and requirements found, thenext tasks in the Usability Model and UCD is to design, develop and performuser testing. This will insure that the users requirements are met and theirsuggestions for changes evaluated for the next cycle of development. To ensure

1ISO 13407 - Human-centred design processes for interactive systems

38 Design

proper UCD testing of Moina interface and features, the previously mentionedtest group will be collaborating with the developers in the development andtesting phases.

3.1.3 Designing Moina

With the knowledge acquired about UCD and usability with the ISO 9241, thestage is set for designing the UI for Moina. In the design phase the UI is notlimited by the boundaries of the front end framework and other programmingcapabilities. The design should therefore be seen as guidelines to the UI, not anexact final solution. The UI design process can be split in two separate tasks:Designing the site view and designing the page views. Let’s start with the siteview and then proceed to the page views.

3.1.3.1 Site View

Being able to see the whole site is an important perspective when structuring.In much the same way as a house needs to be architecturally blueprinted, a sitealso needs to have its structure drawn[30]. This information will translate intoa sitemap which will serve as a backbone of the entire site.

My Moina

The Team What Is Moina BlogLogin Register

Home

ProfileFinancial Accounts

Import Transactions Statistics

GUEST USER LEVEL

REGISTERED USER LEVEL

Figure 3.2: Moina site map v. 1.0

The sitemap in 3.2 shows the proposed links and main navigation paths ofMoina. All users will have access to the guest user level pages, and registeredusers, who has been validated though login, will be able to access the registereduser level pages. All the individual pages and their purposes will be explainedin further details in the Page Views section on page 41.


3.1.3.2 The Site Wire Frame

Wire framing is a purely informational, architectural schematic showing themajor content placement, primary and secondary navigation, and some timeslight functionality[30].

Googlehttp://domain.com

Web Page Title

Content

MenuMenuMenuMenuActiveMenu

Footer

Title1

2

3

4

Figure 3.3: Moina site wire frame v.1.0

In figur 3.3 the first version of the site wire frame is schematically drawn withnumbered arrows indicating the placement of the following site elements.

1. The top banner image of the site including the site title.

2. The menu bar showing the available options for navigation.

3. The sites content placement holder encapsulates the pages to make them apart of the site view. This part of the site should be extensible, illustratedwith curly ends.

4. The footer will contain site and layout copyright information.

Knowing that the graphical design of a site has a big impact on the users, abest practice graphical design should be provided for Moina.

40 Design

3.1.3.3 Graphic design

The task of creating a proper graphic design for a web site is not a task fit forthe average developer. The graphic design of a web site should be handled bypeople in the field of design. For Moina the graphic design was done by one ofits test group members Katrine H. Wiinberg. She has with her education as agraphic designer the correct background for the task. The site wire frame andits measurements were exchanged, and after some days of communication andwork the graphic design was done.

Figure 3.4: Moina Graphic Design

The material provided by the designer was a site view image shown in figure 3.4and the same picture cut into several images for the implementation. In thedesign process the possibility of a multi language site option has been thoughtin to the design and resulted in non specific currency cash being piled up in thetop banner and menu background images. The implementation of the design,will be done in the development phase.


3.1.3.4 Page Views

The pages wire frames shown in figure 3.5 are like the site wire frame onlyarchitectural schematic. This time the wire frames are used to visualize thepages that resides in the sites content placement holder. Let’s run throughthem and explain their purposes on the site.

Heading 1

Heading 2

Heading 2

• Lorem ipsum dolor sit amet consectateur nonummy lorenzino.

• Interdum volgus videt, est ubi peccat.

• Si veteres ita miratur laudatque poetas

• Ut nihil anteferat, nihil illis comparet, errat.

Far far away, behind the word mountains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live inHeading 4

Far far away, behind the word mountains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of the Semantics, a large language ocean.

A small river named Duden flows by their place and supplies it with the necessary regelialia. It is a paradisematic country, in which roasted parts of sentences fly into your mouth.

Home

R. [email protected]


The Team





What Is Moina

Email

Password

Login

Login

textEmail

textEmail

textPassword

textPassword

Register or Cancel

Register



Paragraphs



Paragraphs

Blog

Figure 3.5: Guest User Page Wire Frames v.1.0

Home: The front page of Moina used to welcome the user end expose importantand catchy Moina material.

The Team: Providing contact information and facts on the people behindMoina.

What Is Moina: A quick overview of Moina and its features.

Login: The login page validates users to allow them into restricted areas.

Blog: This page will be used to post updates and Moina related material.

Register: The registration page where new Moina users provide their registra-tion information.

42 Design

The registered and validated users are able to enter the area of Moina, which iscalled My Moina. Here they can manage their personal finances on the registereduser level pages. These pages are shown as page wire frames in figure 3.6 andexplained below.

My Moina

Numeric OverView

Information Information

Pofile

textLabel

textLabel

textLabel

textLabel

textLabel

textLabel

textLabel

textLabel

Save or Cancel

Financial Accounts

Heading

Table cell

Table cell

Table cell

Table cell

Table cell

Edit

Edit

Edit

Edit

Edit

Add

Import

BrowsePathFile input

Import

Transactions

Table cell Table cell

Table cell

Table cell

Table cell

Table cell

Table cell

Table cell

Table cell

Table cell

Table cell

Heading

Table cell

Table cell

Heading

Table cell

Heading

Table cell

Heading

Table cell

Table cell

Table cell

Table cell

Table cell

Table cellTable cellTable cellTable cell






Statistics

Statistics main

Statistics second

Statistics extra

Figure 3.6: Registered User Page Wire Frames v.1.0

My Moina Shows the users a quick numeric overview of his finance.

Profile Show and edit the users profile information.

Financial Accounts Lists the users financial accounts and edit options.

Import The import form making it possible to import transactions.

Transactions Listing the transactions and edit options.

Statistics Relevant statistic information on the users finance.

3.1.4 summary

To accommodate the users focus in software, its usability has improved by fol-lowing the look and feel perspectives of ISO 9241/11 [12]. UCD has been uphold

3.2 System Architecture 43

in the project by following ISO 13407 [27] standards and models. The site view2

and site wire frame has been constructed. With the help of a professional graphicdesigner the graphical content for the page was made, and finally the individualpages for the Moina was designed also in wire framing.

3.2 System Architecture

The Domain Driven Design (DDD) was chosen previously in the project for thesystems architectural design. By using DDD architectural guidelines, optimalconditions should be made possible for proper and agile systems development.One of DDD’s key principle is the collaboration between technical and domainexperts3. To heighten the communication and understanding between domainand technical experts a Ubiquitous language must be made.

3.2.1 Ubiquitous Language

The concept of the Ubiquities Language(UL) is meant to form an linguisticunderstanding between domain experts and developers. The concept states,that developers and domain experts should share a common language, thatboth understand to mean the same things. The UL terms must be in businessterminology, not technical terminology. The domain of a PFM solution is closelycoupled with the domain of a financial institute. The financial institute providesall the essential financial data for the system, and a financial institute wouldbe the most likely future business partner. The financial institutes domain hastherefore been chosen as business domain for the UL in this project. To helpcreate the UL, domain expert Mathias Dam from the Nordea ebanking hasshared his knowledge of the business domain and its terminology.

Customer(s) Registered or new potential user(s).

Financial Account(s) A registered user’s financial account(s) referring to thefinancial account(s) they have in their financial institute(s).

Transaction(s) A registered user’s financial account related transactions/posts/statments/movements.

Bank(s) A financial institute providing financial services for its customers.

2Generally known as site tree3People that are experts in their specific business domain

44 Design

3.2.2 Domain Driven Design Layers

With information from the book Domain Driven Design Quickly[29] the firstversion of the systems architecture was made. DDD architecture can be scaledin size and layers to counter complex domains. This projects domain is rathersimple, and as a result the amount of DDD layers has been kept to a minimum,while still upholding basic DDD standards. The figure 3.7 shows the first versionof the system architecture. Each layer in the figure will be explained in thefollowing sections.

Web

Database

Views, viewModels and UI Components

Presentation-Specific

Domain-Specific

Database-Specific

Web.Controller Controllers

Data Access ORM using Fluent NHibernate

Core Domain objects Models

Test

Repository Data objects

Helpers and Handlers

Application-Specific

Figure 3.7: First version of the systems architecture

3.2 System Architecture 45

3.2.3 Domain Core Layer

DDD focuses mainly on the domain and it is therefore the appropriate layer tostart with. The core layer is a domain specific layer, where all the informationsabout the domain should reside. It is the core of the system and thus a placefor business object and business logic called domain logic and domain entities inDDD. Domain entities should reflect the objects of a finance institute domainrelevant to the PFM solution. Examples of this projects domain entities couldbe User, Financial Account, Transaction and so forth. These domain objectsshould be used to transfer domain specific data to keep everything as objectorientated as possible. The domain logic should be logic, that never changesunless of-course the real life domain changes. Examples of domain logic in thisproject could be core functionality like the Import Transactions Handler.

3.2.4 Database Access Layer

All entities from the domain layer should be reflected in the database, each of thedomain entities should therefore be assigned with a Fluent NHibernate mapper.The mapper is the entities equivalent representation in the database and willtherefore model the database tables with keys, relations, properties and so forth.The layer should be capable of providing access to both development database (SQLite ) and deployment database (MSSQL). This projects designated databasehandler, the ORM tool Fluent NHibernate will handle all interactions with thedatabase. Fluent NHibernate should be implemented with a Factory pattern andshould be able to switch easily between the two databases. For easy readabilityand optimal interaction with the ORM tool, LinQ should be used in databasequeries.

3.2.5 Controller Layer

All the data needed for the views should be handled by web controllers. Thecontrollers must reside in web layer due to the MVC project structure not al-lowing the separation of its controllers to other layers. The controllers is theseparation layer between the view and the domain core data and functionality.The controllers should implement functionality to help mapping domain entitiesdata to view model to avoid using domain specific objects in the view.

46 Design

3.2.6 Presentation Web Layer

All the applications views and visual information will reside in the web layer.This layer should have no knowledge of Domain entities or functionality. Theviews visual styling information should be separated from the view files andhandled separately in a CSS resource files

3.2.7 Test Layer

The Test layer should be able to perform tests on other testable layers in thesystem architecture. Test should be made with Visual Studio Unit Test projectsto perform the best possible tests. Proper Testing is a science of its own and isvery time demanding in the development process. This project is not conductedunder test driven development and taking in perspective of the project size andthe time span, only selected requirements will be unit tested.

3.2.8 Summary

As DDD for-scribes the ubiquitous language has been formed and the systemsarchitectural layers has been designed to uphold the basics principles for DDDsystem architecture.

Chapter 4

Development & Test

This chapter will address the following tasks from the project description insection 1.2: Task 8- Moina’s requirement test validations, task 9- the prod-uct backlog and implementation status of Moina requirements, task 10- listingtechnologies used in Moina, task 11- the design patterns used, task 12- imple-mentation examples, task 13- the results of the test group user tests of Moinaand finally task 14- proof of concept evaluation.

48 Development & Test

4.1 Requirement Tests

All requirement tests must be handled before finalizing the product backlog.Selected requirement tests are performed with unit testing the rest is conductedwith manual and user testing. An example of one of the unit tests can be foundin appendix E; the rest of the unit tests can be found in Moina’s test project forthe service layer. A listing of all the requirement tests and their testing statuscan be seen below.

Import Data Requirement Tests

1. 3 Format and trim transactions to meet a common standard.

Mass Categorization Requirement Tests

2. 3 Stack identical transactions and mass categorize them.

3. 3 Split text up in words, search for transactions with the word andmass categorize them.

4. 3 Select multiple transactions on a list and mass categorize them.

Previous Categorization Requirement Tests

5. 3 Query for previous transactions with full text comparison.

6. 3 Selecting a category for the processed transaction based on thecount of transactions in the found categories.

Custom Categorization Algorithm Requirement Tests

7. 3 Split transaction text in words and persist the words for futureusage.

8. 3 Query for words and text resulting in the different categories, theyhave been given in the past.

9. 3 Frequency values on the category, word and text pairs.

10. 3 Calculate the categories individual percentage of the total categoryselection.

11. 3 Selecting the final category by evaluating with the found informa-tion between the remaining categories.

12. 3 Quality category selection limiters.

4.2 Product Backlog 49

4.2 Product Backlog

In a SCRUM product backlog it is unorthodox to have must-, should- andnice-to-have listing in the backlog. Never the less it provides an easy obtain-able perspective of the products progress and milestones. This listing type hastherefore been chosen for the minimal report version of the product backlog.

The listing below will contain the Moina product backlog items and the im-plementation status. Specifications for the backlog items can be seen in theirrespective sprint backlogs available in the properly formatted and sprint backlogincluded product backlog in Appendix F.

Must Have Items:

1. 3 Import financial data: CSV format.

2. 3 Import comparability: Multiple financial institutes.

3. 3 Transaction: CRUD1

4. 3 Financial Account: CRUD

5. 3 Customer: CRUD

6. 3 Bank: CRUD

7. 3 Category: CRUD

8. 3 List finance data: Group-By functionality.

9. 3 Previous Categorization.

10. 3 Category: Static category: Categorize transactions.

11. 3 Numeric overview: Simple.

12. 3 Graphical visualisation overview: Simple.

1Create Retrieve Update Delete


Should Have Items:

13. 3 Customer: Multiple financial accounts compatibility.

14. 3 Login security: Prototype version: User authentication.

15. 3 Custom categorizing algorithm.

16. 3 Unit Test: Prioritised elements.

Nice To Have Items:

16. 7 Transaction: Month tags.

17. 7 Mass categorizing.

18. 7 Category: Static subcategories: Categorize transactions.

19. 7 Kick starter strategy: Pre approved word category pairs.

20. 7 Transaction: Cash in hand creation.

21. 7 Graphical visualisation overview: Interactive.

22. 7 Transaction: Search functionality: Words.

23. 7 Import comparability: BEC data format.

24. 7 Transaction: Split up.

25. 7 Login security: Release version: user/roles authentication.

26. 7 Bug: Data redundancy: Transaction text being changed in the financialinstitute database has backwards effect on older transactions. Changedtransactions will appear as new transactions to Moina.

4.3 Technologies & Third-party Components 51

4.3 Technologies & Third-party Components

Listed below is the technologies and third-party components used in Moinafollowed by a short introduction to their functionality. Further informationabout the components is referred to after each section

.NET 4.0 Framework The newest .NET Framework released April 2010 withVisual Studio 2010. Introducing features like the PLINQ and Lambdaexpressions which has greatly improved query actions in Moina.[18]

ASP.NET MVC 3 The newest MVC framework, released in RTM versionJanuary 2011. Introducing many new features like the new Razor viewengine and scaffolding templates making the Moina UI more dynamic.[3]

NHibernate An Object-relational mapping (ORM) solution for the .NET plat-form. It provides a framework for mapping an object-oriented domainmodel to a traditional relational database. This technology provides thebasic database interaction and creation in Moina.[19]

Fluent NHibernate A fluent API for mapping classes with NHibernate withXML-less, compile safe and convention-based mappings.[10]

JQuery UI Providing abstractions for low-level interaction, animation effectsand themeable widgets. JQuery UI is built on the jQuery JavaScriptlibrary, both natively provided in Visual Studio MVC3 projects.[14]

jqGrid A server-side grid component customised for MVC, built on the jQueryplugin jqGrid. The grid will list and handle interact with transactionsin Moina. jqGrid is produced by the company Trirand, who had thegenerosity of sponsoring the project with a licensed version of jqGrid.[13]

AutoMapper An object-object mapper transforming an input object of onetype into an output object of a different type. AutoMapper is in chargeof mapping Moina Domain models to UI View-models upholding the sep-arations in MVC.[4]

Ninject A lightweight dependency injection framework. Ninject modules areused to register the various model types in the system with IoC2 contain-ers. With the IoC containers registered only one place in Moina inter-changing, modifying and testing is made easier.[20]

Rhino Mocks A dynamic mock object framework for the .NET platform. Itspurpose is to ease testing by allowing the developer to create mock imple-mentations of custom objects and verify the interactions using unit testingas done in the unit test project of the Moina service layer.[24]

2Inversion of Control


4.4 Design Patterns

In the development of Moina the following design patterns were used to solvecommonly occurring problems in software design. All patterns has been cus-tomised before implementation to best fit the circumstances in Moina. Furtherinformation on the patterns are referred to after each section

One session per request pattern A rather special pattern used to handlethe NHibernate sessions. The pattern has been implemented in the MoinaData Access layer’s NHibernateWebHandler.[23][2]

MVC pattern Separating the Model, View and Controller in Moina’s presen-tation layer.[17]

View model pattern A special pattern used to separate view-model objectsfrom the domain model objects. The conversion is implemented in Moina’spresentation layer’s different controllers and view-models.[28]

Factory pattern Used mainly to build the NHibernate sessions. The patternhas been implemented in the Moina Data Access layer’s NHibernateWebHandler.[8]

Service locater pattern Used to provide the correct service at runtime. Thispattern has been implemented in the service layers Import-Handler tolocate the correct financial account Data-Handler.[25]

Strategy pattern Used to provide common Interfaces for multiple objects,allowing easier interchangeability. This pattern has been implemented inall layers of Moina.[26]

Null object pattern Handles possible null exceptions on the code. Imple-mented in all Moina layers.[21]

4.5 Implementation Examples 53

4.5 Implementation Examples

Three requirements from the product backlog in section 4.2 has been chosen asMoina implementation examples. These examples will only show less than apercentage of the work put into the development of Moina. A list has thereforebeen provided after the examples referencing to other interesting implementa-tions in Moina. Additionally a DDD glossary has been provided in appendix Dto clear any misunderstandings with DDD development terminology. All codeexamples has been formatted to fit the report listings.

4.5.1 Create Customer

The create customer requirement is a rather simple example. But following atop-down scenario of a customer creation and explaining the different mecha-nisms on its path through the system will give a good idea of, how the systembehind Moina works, and what is needed for its basic functionality.

If directed to the url moina.dk/customer/create, the mvc projects global.asaxfiles routing table will direct the call to the customer controllers GET type createmethod shown in listing 4.1. In the instantiation of the Customer Controller thecontrollers constructor has a dependency injection on a ICustomerRepositoryencapsulated in a IoC Container. The IoC Container injection itself is handledby Ninject, and can be seen in the global.asax and NinjectDependencyResolverfiles in the root of the presentation layer.

Listing 4.1: CustomerController Create (GET)Method

[HandleError] // HandleError Action Filterpublic class CustomerController : Controller{

public CustomerController(ICustomerRepository repository){

_customerRepository = repository;}...//Getpublic ActionResult Create(){

return View("Create", new CustomerRegisterView());}...

}


The controller class in listing 4.1 counters error handling with action filtersobserving all class methods. The Create method returns a Create view with aCustomerRegisterView model attached. This CustomerRegisterView model isonly for the creation of a customer, were other actions on a customer in theview would require a different viewmodels made specifically for that purpose.

Listing 4.2: ViewModel CustomerRegisterView

public class CustomerRegisterView{

[DisplayName("Email")][Required(ErrorMessage = "Email Required")][RegularExpression("^([0-9a-zA-Z]([-.\\w]*[0-9a-zA-Z])*@

([0-9a-zA-Z][-\\w]*[0-9a-zA-Z]\\.)+[a-zA-Z]{2,9})\$",ErrorMessage = "Email not valid")]

[Remote("CheckEmail", "Customer", ErrorMessage = "Email isalready registerd")]

public string email { get; set; }

[Required][DataType(DataType.Password)][Display(Name = "Password")]public string password { get; set; }

[DataType(DataType.Password)][Display(Name = "Confirm password")][Compare("password", ErrorMessage = "The password and

confirmation password do not match.")]public string confirmPassword { get; set; }

}

public class CustomerView{...}public class CustomerDetailsView{...}public class CustomerChangePasswordView{...}public class CustomerLogOnView {...}

The CustomerRegisterView in listing 4.2 has few attributes, saving the usersfrom a dreary registration process, where each of the attribute has filters forerror handling. The email attribute for instance checks for Required field, Reg-ularExpression email validation and a Remote filter action calling the Check-Email method, which returns a JsonResult based on the emails existence inthe database. A submit form is auto-generated for the viewModel in the Scaf-foling generated view with the @Html.EditForModel() html helper visible inthe /View/Customer/Create view file. Submitting the form will redirect to thePOST type Create method in listing 4.3 of the Customer Controller indicatedwith the action filter [HttpPost].


Listing 4.3: CustomerController Create (POST)Method

public class CustomerController : Controller{

. . .[HttpPost]public ActionResult Create(CustomerRegisterView viewModel){

if (ModelState.IsValid){

Customer newCustomer = new Customer();Mapper.Map(viewModel, newCustomer);_customerRepository.AddCustomer(newCustomer);return RedirectToAction("Index", "MyMoina");

}else{

return View(viewModel);}

}. . .

}

If the model is validated, the viewModel is converted through AutoMapper to itsequivalent domain entity representation the customer class and saved throughthe _customerRepository AddCustomer method shown in listing 4.4.

Listing 4.4: CustomerRepository

public class CustomerRepository : ICustomerRepository{

public ISession Session{

get { return NHibernateWebHandler.GetCurrentSession(); }}

public void AddCustomer(Customer customer AddCustomer method){

Session.SaveOrUpdate(customer);}public IQueryable<Customer> GetAllCustomers() { . . . }public Customer GetCustomer(int id) { . . . }public Customer GetCustomer(string email) { . . . }public void DeleteCustomer(Customer customer) { . . . }public void SaveOrUpdateCustomer(Customer customer) { . . . }public Customer ValidateCustomer(string email, string password)

{ . . . }}

In the Data Access layers CustomerRepository, which is based on the ICustomer-Repository interface, the AddCustomer method calls the NHibernate ISessionattribute’s method SaveOrUpdate with the customer object as parameter per-


sisting the customer object in the database using the ORM NHibernate tool.The ISession and database is generated in the ISessionFactory of the NHiber-nateWebHandler, also visible in the Data access layer. This concludes the top-down creation scenario of a customer in Moina.

4.5.2 Import

In this import scenario the user and his financial account has already beencreated, and he has chosen his csv file to be imported in the Import view andpressed import leading him to the POST type Import method of the ImportController shown in listing 4.5. Here the method acquires the current usersid saved in the login cookie and the current financial account Id saved in theHttp Session context. With both id’s and the users file information saved inthe HttpPostedFileBase file type as parameter the importData method of the_importHandler is called to handle the import process.

In the importData method shown in listing 4.6 the account being handled isvalidated to belong in the current user’s accounts. If the account is validatedthe correct datahandler for the specific account will be instanciated by the Get-DataHandler through standard service locater pattern strategy. The file is savedlocally and its local server path validated before processing the file. The file isprocessed in the appropriate financial institute type dataHandler, trimming,cleaning and creating the transaction objects. The words are extracted fromthe transactions text attribute and unique words persisted. The month groupis set making it possible for the user to change the belonging month for a trans-action without changing the actual transaction date. All the transaction cat-egories are set to the NoCategory category object. All Transactions are thensaved on to the customers account and the account is then persisted/updatedwith the saveOrUpdate method of the _accountRepository. Finally the Cate-gorizeEmptyAccountsTransactions method is called to query all transactions onthe users account, both newly imported and old transactions, with the noCate-gory and process them for categorization. This concludes the Import scenario.

Listing 4.5: ImportController Import method

[HttpPost]public ActionResult Import(HttpPostedFileBase file){

int currentAccountId = HttpContextExtensions.GetCurrentAccountId(System.Web.HttpContext.Current);

int currentCustomerId = CurrentUser.Id;_importHandler.importData(file, currentAccountId,

currentCustomerId);return RedirectToAction("Index","Transaction");

}


Listing 4.6: ImportHandler importData method

public void importData(HttpPostedFileBase file, int accountId, intcustomerId)

{var account = _accountRepository.GetAccount(accountId)

if (account.customer.id == customerId){

DataHandler dataHandler = DataHandler.GetDataHandler(account.bank.name);

//Saves the file to "~/FileUploads"string filepath = SaveFile(file);if (filepath != null){

//Get the regex cleaned list of TransactionsList<Transaction> transactionList = dataHandler.

ProcessData(filepath, account);

//Extracts words from text’s and persists unique wordsvar words = _wordHandler.GetWordsFromTransactions(

transactionList);_wordHandler.SaveNewWords(words);

//Sets Month Group On TransactionsSetTransactionsMonthGroup(transactionList);

// Set categories to noCategorytransactionList = _categorizingHandler.SetNoCategory(

transactionList);

//Save transactions on the account objectaccount.AddRangeOfTransactions(transactionList);

//SaveOrUpdate the account to db_accountRepository.SaveOrUpdateAccount(account);

//Categorize account transactions with noCategory_categorizingHandler.CategorizeEmptyAccountsTransactions(

accountId);} } }

4.5.3 Categorize

Following a scenario with a list of transactions being processed for categoriza-tion in the CategorizeData method where the first transaction being processedhas no categorization results in PreviousCategorization approach method andhas multiple transaction results in the NetworkCategorization method lead-ing the processed transaction to the GetCategoryFromMultibleExistingTrans-actions method in listing 4.7.


Listing 4.7: GetCategoryFromMultibleExistingTransactions method

public class CategorizingHandler : ICategorizingHandler{

...public List<Transaction> CategorizeData(List<Transaction>

transList, int accountId, int customerId){...}private Transaction ProcessOneTransaction(Transaction t) {...}private Transaction PreviousCategorization(Transaction t) {...}private Transaction NetworkCategorization(Transaction t) {...}

private Transaction GetCategoryFromMultibleExistingTransactions(Transaction t, IEnumerable<Transaction> Transactions)

{var destinctCategories = (from m in Transactions select m.

category).Distinct<Category>();if (destinctCategories.Count() == 1){

var category = destinctCategories.SingleOrDefault();t.category = category;

}if (destinctCategories.Count() > 1){

var categoriesTransactionCountPairs =from transaction in Transactionsgroup transaction by transaction.category into catselect new { Category = cat.Key, TransactionCount =

cat.Count() };//Mode ~ typetal ~ hyppigstvar CategoryMode = categoriesTransactionCountPairs.

GroupBy(n => n).OrderByDescending(g => g.Count()).Select(g => g.Key.Category).FirstOrDefault();

t.category = CategoryMode;}return t;

}private Transaction GetCategoryFromOneExistingTransaction(

Transaction t, IEnumerable<Transaction> Transactions){...}public IEnumerable<Transaction> MassCategorizeTransactions(

Category category, IEnumerable<Transaction> Transactions){...}

}

The distinct categories from the transaction collection are first found. Shouldall categories be the same, eg. only one distinct category, the category will bechosen; else if multiple categories are found, each category will be listed with acount number indicating how many transactions each of them are linked to in thequery. The list of category-count pairs are then sorted and the category with thehighest count is selected for the transaction. This concludes the categorizationscenario.

4.6 User Tests 59

4.5.4 Other interesting Implementations

If more knowledge on the development and implementations of Moina is sought,the following sections in the layers shows some interesting development chal-lenges and their solutions.

Moina Layer implementationsFile / Path Implementation DescriptionPresentation LayerAutoMapperConfiguration Configuring AutoMapper conversionsMoina.css Layout compatibility for all popular browsersMyMoinaController The flow of navigating users to correct placesSecurityController The login validation and cookie creationTransactionController Transaction jqGrid creationHelpers/ Html, session, cookie and custom helpersView/Shared/ Registered & guest Moina layoutNinjectDependencyResolverGlobal.asax

The Implementation of Ninject

Core LayerModels/ The domain entitiesService LayerCategorizingHandler The various categorization methodsImportData/ The import data handlingDataAccess LayerNHibernate/ The NHibernate ORM tool implementation

Table 4.1: Other interesting implementations

4.6 User Tests

With the help of the test group, development and testing has been parallelrunning tasks in the project as required in UCD. During these test sessions theusers would be asked to test out a number of features in Moina and providefeedback, while being monitored by the developer. This led to some interestingcriticism and problems, all of which has been described in table 4.2 on page 60.


Criticism Problem SolutionMette K. Hjorth

Navigation to MoinaHome from the Moinalogo in the banner.

The logo is mergedwith the banner fromgraphic design.

A transparent imageover the logo redirect-ing to Moina Home.

The year graph coulduse an indication of themonthly outcome andits evolution.

The graph needs a ten-dency indication of themonthly outcome.

A tendency line hasbeen added to thegraph.

Katrine H. WiinbergThe blue coloured titleof paragraphs blendsin too much with thebackground.

The paragraph fontcolor is obstructingwith the comprehensi-bility of the usability.

The paragraph fonthas been changed tobrown in the css.

Peter Toft JolvingWould it be possibleto edit the transactioncategory directly in thelist?

Editing transactions inthe grid results in apop-up window for theediting.

In-row editing hasbeen set up in thetransaction grid

Christian PejrupI would also like to seemy different monthlyincome sources

Only the monthly ex-penses are shown inthe monthly graphs.

A monthly incomegraph has been addedshowing the differentsources of income

How can I log out Only the monthly ex-penses are shown inthe monthly graphs.

An monthly incomegraph has been addedshowing the differentsources of income

Table 4.2: UCD user tests

4.7 Proof of Concept

The proof of concept for the project was to provide basis for the practical useof Moina as a time saving PFM solution.

To provide the time saving functionalities in Moina, several features, function-alities and requirements has been analysed and tested to ease the time demand-ing tasks involved in achieving the financial perspective. Amongst the mostpromising of the time saving features, was the import transactions feature andtransaction categorization features. These has been explicitly tested for Moinaand implemented with success. The importation of an average users monthly

4.7 Proof of Concept 61

transactions is now done in under 3 seconds and the importer has become com-patible with two of the largest financial institutes in Denmark. The catego-rization quality and and efficiency of the implemented categorization features;previous categorization and network categorization are based on the amount ofcategorized data in the system.

In this prototype of Moina, two users has imported and categorized over 500personal transactions to Moina as test data. This amount of data has beensufficient to test the previous categorization feature, but not enough data totest the network categorization feature. To sufficiently test the network cate-gorization feature, a large scale test would have to be conducted. A large scaletest is not in the scope of the proof of concept prototype and will be a taskfor future work. The time saving factor for both categorizing features will in-crease with the amount of data categorized in Moina, by the user himself in theprevious categorization feature or other users through the network categoriza-tion feature. An categorization experiment with the importation of 2 identicalCSV files were made with 2 financial accounts on the same user. The first ac-count was categorized manually in Moina and the second processed through theprevious categorization feature, utilising the maximal potential of the previouscategorization feature. The result was 100% of transaction being categorizedwith no categorization errors. This categorization was done with 326 transac-tions, which is about one year of transactions for the average user, and it tookincluding the the importation process less than 5 seconds.

The visualization of the users financial data is handled with column and piecharts handling yearly, monthly and categorized groups perspectives. The chartsare generated in less than a second, and provides a fast and easy obtainableperspective of the user’s financial data.

Moina’s interface has been produced with an appealing UI, introducing profes-sionally custom made graphics for Moina’s primary target group. Screen dumpsof Moina’s transaction listing and graphs can be seen in appendix H.

Time saving features has successfully been implementations in all aspects of theMoina development.

By reaching all the goals sought in the proof of concept prototype, Moina hasmade its "Proof of Concept" milestone.

Chapter 5

Conclusion

This chapter will summarize all the tasks, results, findings and conclusions forthe different chapters in the Moina project. The project itself will be concludedas a whole, and future work for the project will be described. Let’s first sum-marize what the project was all about, and which problems it sought to solve.

5.1 Short Project Description

Organizing and managing personal finances can be a tedious and time consum-ing matter. The purpose of this project is to build an online Personal FinancialManagement (PFM) solution, that could save the users time and agony of ob-taining the financial perspective themselves. To do this, various time savingfeatures must be analysed and tested for their possibilities. The design of thesolution’s user interface will become a success-criteria, and the user interfaceshould therefore provide an appealing interface with high usability. The systemarchitecture should be designed to provide the optimal development conditionsand finally the system must be evaluated for its proof of concept milestone.

64 Conclusion

5.2 Chapter Tasks & Conclusions

The description of the different chapter tasks can be seen in the project descrip-tion section 1.2 on page 3.

5.2.1 Analysis Chapter Task 1 - 5

In the analysis chapter interviews was conducted on a test group to gatherinformation on their preferences for PFM features in Moina and its interfacelanguage. The Danish and foreign PFM markets were analysed with functional-ity, features and categorization approaches in mind. Five solutions were foundand analysed; three of which was in the Danish market and two in foreign mar-kets. A scenario was conducted to produce a financial perspective, with the mostcommonly used PFM tools available in Denmark today. This should pinpointthe time consuming tasks, and make it possible to work on features, that couldease the tasks. One of the most potential timesaving tasks was the categoriza-tion of transactions. To make this feature possible the transaction data wereanalysed for their formatting differences, categorizing possibilities and vulner-abilities. Three possible time saving transaction categorizing approaches wasfound and analysed, namely the mass categorization, previous categorizationand network categorization. Finally all the requirements for Moina, found inthis chapter, was evaluated and prioritized.

On the work described above, the following was concluded:

Based on the user interviews and their requirements Moina’s primary targetgroup was set to the age group of 18-25 years. All user requirements were savedfor future evaluation, and the interface language was set to English. Throughrelated work a better understanding of the PFM market and domain was ac-quired. This resulted in many new requirements and categorizations ideas forMoina. In the time consuming tasks section the average Dane was found to have32 monthly transactions, and by using Excel as PFM tool he was estimated touse 3 hours to produce a financial perspective and an additional 50 min for eachadditional month of transactions. Solutions and ideas for easing the time con-suming tasks were found for Moina. For the categorization features a commonfinancial data format was found, optimizing the capabilities of the categoriza-tion and import features. Theoretical solutions were found for all categorizationapproaches, and their requirement tests described. All the requirements foundin this chapter was listed in must have should and nice to have order, weightedby the projects time constraints, proof of concept objectives and the primarytarget group.

5.2 Chapter Tasks & Conclusions 65

5.2.2 Design Chapter Task 6 - 7

In the design chapter the usability, design methods and graphic design of Moina’suser interface was conducted to provide the best possible chances for a success-ful user interface. The system architecture of Moina was designed to produceoptimal development conditions.

For the work done in the design chapter, the following was concluded:

The design of the user interface was conducted to uphold the standards inusability ISO 9241/11 and user centered design ISO 13407. The site-tree anddesign for the site and pages was produced, and the graphics for the layoutwas custom made for Moina by a professional. The ubiquitous language wasformed with a domain expert, and Moina’s architectural layers were designed,upholding the basics principles for Domain Driven Design system architecture.

5.2.3 Development Chapter Task 8 - 14

In the development chapter the requirements in need of testing was conductedbefore being added to the product backlog. The finalized product backlog re-quirements and their implementation status were listed. To sum up some infor-mation about the system development, the technologies, third-party componentsand design patterns used in Moina, should be listed. To illustrate some of thechallenges that were overcome in the development phase, examples should beprovided of interesting requirement implementations. The user testing of Moinaand their criticism and results should be listed, and finally a status on whetheror not Moina had reached its proof of concept milestone was made.

The work involved with the development chapter had the following conclusions.

Testing of selected requirements were conducted. All tests were successful andthey were therefore added to the product backlog. The product backlog wasfinalized, and all the "must have" and "should have" requirements was success-fully implemented in Moina. All the design patterns, technologies and third-party components used in Moina was listed and the create customer, importtransactions and categorize transactions implementation examples logic wasbriefly explained. The users testing of the UI has helped to enhance Moinato the users preferences and the results of the testing results was listed. Moinahas by accomplishing all sought goals in the proof of concept prototype versionreached its proof of concept mile-stone.

66 Conclusion

5.2.4 Project conclusion

The Moina project has analysed, designed and developed a FPM prototypesolution with all the "must have" and "should have" prioritized requirementssuccessfully implemented. Moina is functional under the these requirements,and this has together with positive results from the time saving feature and afunctional and appealing interface, made it possible for Moina to reach its proofof concept milestone. By reaching this milestone the Moina project has providedbasis for the practical use of Moina as a time saving PFM solution.

The project has come a long way in a short amount of time, and unfortunatelythere was not time to implement the lower prioritized "nice to have" require-ments and conduct large scale test on the categorization efficiency and quality.These requirements will now be a task for the future work.

5.3 Future Work 67

5.3 Future Work

In the future work with the Moina project, it would be interesting to look atsome new requirements and tests. But first and foremost all the "nice to have"requirements should be implemented. A large scale test could be conducted ofthe network categorization feature with either real, fictive, aggregated or dummydata. Another large scale test could also be conducted on Moina’s categorizationalgorithm against another categorization algorithm like Spiir or Banklog’s. Dif-ferent fields of artificial intelligence, like neural networks or learning-by-example,could be analysed for their categorization possibilities.

• Month tags on transaction letting user decide which month their transac-tions should belong to.

• Manually mass categorize multiple transactions.

• Static subcategories.

• Categorization kick-starter strategies.

• Manually inputting transactions with cash in hand purchases.


• Search functionality.

• BEC data import compatibility.

• Split up transactions.

• Large scale testing of the network categorization.

• Large scale testing of difference in quality between various PFM solutionscategorizing algorithms.

• Artificial intelligence categorizing possibilities.

• The implementation of multi-language options in the interface.

• Direct data feed agreements with financial institutes.

• Implement budgets to make the system interesting to elder users.

• SMS notifications on the budgets with the direct data feed.

• Transaction tags to uniquely identify groups of transactions.

• Update the custom algorithm with time and date parameters.

• Self adjusting dynamic amount limiters to categorize based on the amount.

68 Conclusion

Appendix A

Entrepreneurship CourseSurvey

The survey in this appendix was conducted in the 42435 Knowledge based en-trepreneurship DTU course spring of 2009.

70 Entrepreneurship Course Survey

72 Entrepreneurship Course Survey

Appendix B

Test Group Interviews

The test group interviews was conducted in Danish and has since been translatedto English.

74 Test Group Interviews

Interview Questions

A Would you prefer Danish or English as interface language for PFS?

B Would a less time demanding financial system have higher value for you?

C Which features and functionalities whould you like PFS to have?

Name Age A: B:Mette K. Hjorth 22 Danish YesC: Mette needs a system, that would give her an overview of, what shespends here money on. She also wants to be able to make a budget forfuture economy. The system should only take the utter most necessarytime from her to get her personal financial perspective, since she at thispoint don’t believe, she has a need for the system.Niklas L. Bjerregaard 19 Danish / English YesC: Niklas would like a quick and easy overview of his economy. His mainconcern is to see, how much he spends per month and year on partying,fast food and vacations.Rikke Noerhave 24 Danish YesC: Rikke would like to have budget and nested budgets. This nestingwas clarified to also encounter the sub categorisation of transaction cate-gories. The system should do all the calculations and visualize the resultis some suited graphs. The categories could be static from the start, butit would be nice to be able to change the names.Christian Bech 25 English YesC: Christian would like for the system to visualize his economy for himand show it in point and column charts. A numeric overview of differedmonths and years would also be nice. Interactions with the chart couldbe a nice feature, so you could click on a month, category and so on,and get at list of the transactions involved. He would like to be able tomanually adjust, what month some transactions should be in to avoidtypical financial overview errors when receiving bills and paycheck justbefore or after the last day in the month. Giving him the wrong pictureof his economy. He doesn’t really care, if he should spend some hourscategorising his transactions, as long as he gets the right results in theend. He would rather teach the system, how it should be done insteadfor relying on it to categorize it for him. The system should rememberhis previous categorizations and categorise new transactions accordantly.

75

Interview Questions

A Would you prefer Danish or English as interface language for PFS?

B Would a less time demanding financial system have higher value for you?

C Which features and functionalities whould you like PFS to have?

Name Age A: B:Katrine H. Wiinberg 30 Danish YesC: Katrine would like an easy financial Overview. The transactionsshould be categorized in categories and subcategories. Separation forincome and expenses. It should be possible to split up transactions. Itshould be possible to make manually input new cash in hand transac-tions. It would be nice, if the system could take information directlyfrom the bank. It should be possible to make your own categories. Thesystem should recognize previous categorized transactions.Joakim Allerup 35 Danish / English YesC: The system should be very simple. Not any more difficult that Excel.I would like to have a budget and the possibility to see if I have kept mybudget. Budgets is the most important thing for me. My own privateeconomy is not a concern of mine.Peter Toft Jolving 25 English YesC: Peter would like the system to import his financial bank transactionsfrom the file he exports from his online bank. Every transactions shouldbe cleaned and filtered for relevant information before use in the system.The categorization of his transactions should be done by the system asmuch as possible. The system should remember his previous categoryselections. The transactions should be visualized in graphs, lists andnumeric in month and year intervals.Christian Pejrup 30 English YesC: A fast perspective of my economy; very few and intuitive key press,personal categories only for people with special needs, Visualisation ofdata in graphs, graphs should show data over time. I don’t like the ideaof the system knowing my logon to the bank, I would therefore prefer tomanage the export/import part myself. I would like to be anonymousin the system.

76 Test Group Interviews

Appendix C

Users Requirements &Preferences

78 Users Requirements & Preferences

• A quick and easy process to get the financial perspective.

• See financial data per month and per year.

• Remember previous manually categorized transactions

• See what the money was spend on.

• Static categories and subcategories

• Make all the calculations.

• Visualize financial data with point and column charts.

• Static categories

• Make own categories

• Point and column charts

• Numeric overview of months and years.

• Automatic categorisation

• Few and intuitive key presses

• Interactions with the charts leading to the relevant data

• Manually adjust transactions to belong to differed months.


• Import transactions


• Separate income and expenses

• Split-up transactions

• Manual input entries with cash in hand purchases

• Take the data directly from the bank

• Graphs over time

• No automated transaction import.

• Anonymity

• Budgets.

Appendix D

Domain Driven DesignGlossary

80 Domain Driven Design Glossary

In the book Domain-Driven DesignCITE Erik Evans, a specialist in domainmodeling, talks about ideal concepts, practices and terminology of DDD. Tobetter comprehend the DDD concepts and language used in this projects thedevelopment the terminology will be explained in the glossary below.

Entity Object with a distinct identity. An example could be the Core layer’sCustomer entity, identified by a distinct Id number.

Domain Entity Object from the Domain Core layer. In common languagealso refereed to as domain objects.

Value Objects Object that contains attributes but no distinct identity. Anexample could be the Service layer’s Data object only holding data andno identifier.

Factory Object used to create entities. Decouple the invoking code from know-ing implementation details, thus making it easier to switch implementa-tions; an example could be the Data Access layers’s Fluent Nhibernatefactory handling all entity creations.

Repository Object used to make CRUD operations on usually a specific do-main entity, so that alternative storage implementations may be easilyinterchanged. An example of a repository could be the DataAccess layer’sCustomerRepository, handling CRUD operations on the Customer entity.

Service An operation that do not belong to a specific object, decouple themand helps avoiding code duplication. The Service concept is called "PureFabrication" in GRASP. An example of this could be the Service layer’scategorizationHandler providing a service with several categorizing meth-ods.

Aggregate A collection of objects that are bound together by a root entity,otherwise known as an aggregate root. Aggregates are treated as a singleunit for the purpose of persistence, and references are only allowed by theAggregate Root. An example could be the Service layer’s DataHandlerNordeaData, being a member of the DataHandler Aggregate.

Aggregate Root The Aggregate Root is the parent Entity to all other Entitiesand Value Objects within the Aggregate. The Aggregate Root guaranteesthe consistency of changes being made within the Aggregate. An examplecould be the Service layer’s ImportHandler being the root entity for theBank DataHandlers Aggregate

Appendix E

Unit Test Example

82 Unit Test Example

Listing E.1: Unit tests of WordHandler GetWordsFromTransaction method

[TestClass()]public class WordHandlerTest{. . .[TestMethod()]//Naming convention = WhatsBeingTested_Input_ExpextedOutputpublic void

GetWordsFromTransactionTest_ValidTransaction_ListAreEqual(){

//ArrangeWordHandler target = new WordHandler();Transaction transactions = new Transaction() {cleanText="Magasin

Du Nor"};List<Word> expected = new List<Word>();expected.Add(new Word() { name = "Magasin" });expected.Add(new Word() { name = "Du" });expected.Add(new Word() { name = "Nor" });expected.Add(new Word() { name = "Magasin Du Nor" });//ActList<Word> actual = target.GetWordsFromTransaction(transactions)

;//AssertAssert.AreEqual(expected.Count, actual.Count, "Word list length

does not match!");foreach (Word word in expected){

Assert.IsTrue(actual.Contains(word), word.name + " not foundin list!");

}}

[TestMethod()]public void

GetWordsFromTransactionTest_NoNameTransaction_ListAreEqual(){

//ArrangeWordHandler target = new WordHandler();Transaction transactions = new Transaction() { cleanText = "" };List<Word> expected = new List<Word>();//ActList<Word> actual = target.GetWordsFromTransaction(transactions)

;//AssertAssert.AreEqual(expected.Count, actual.Count, "Word list length

does not match!")foreach (Word word in expected){

Assert.IsTrue(actual.Contains(word), word.name + " not foundin list!");

}}}

Appendix F

Product Backlog

84 Product Backlog

1. Import financial data: CSV format.

• Validate file extension

• Validate file data

• Trim and format transaction data to meet a common standard

– Remove text string white-spaces– Extract data from text string, serial number, credit card type

and clean text– Trim transaction text string

2. Import comparability: Multiple financial institutes.

• Import compatibility with multiple financial institutes

• Nordea compatibility

• Danske Bank compatibility

3. Transaction: CRUD1

• CRUD Transaction

• Unique transactions on import and in database

• Validate Create and Update input data

4. Financial Account: CRUD

• CRUD Account

• Account naming

• Validate data on Create and Update

5. Customer: CRUD

• CRUD customer

• Unique Emails validation on create, update and in the database.

• Some form of Anonymity

6. Bank: CRUD

• CRUD Category for Administrator

7. Category: CRUD

• CRUD Category

• Validate data on Create and Update1Create Retrieve Update Delete

85

8. List finance data: Group-By functionality.

• Sort rows

• Show only relevant data

• Edit in-row

• Chose transaction category from a drop-down box

• Show category name

9. Previous Categorization.

• Query for transactions with identical text

• Process results to find category

– Zero or one result– Multible results

10. Category: Static category: Categorize transactions.

• CRUD Category for Administrator.

• Select category for a transaction.

11. Numeric overview: Simple.

• Separate income and expenses.

• Make all the financial summations and calculations.

12. Graphical visualisation overview: Simple.

• Chart showing negative and positive transactions groups

• Show only relevant data

• Time-line economy diagrams

• View transactions in specific time periods

13. Customer: Multiple financial accounts compatibility.

14. Login security: Prototype version: user authentication.

15. Custom categorizing algorithm.

• Query for text resulting in the categories its been given in the past

• Frequency values on text-category pairs.

• Calculate the individual text-category pairs percentage of the group

• Quality selection limiters

• Word recognition

86 Product Backlog

– Split transaction text in words– Query for a word resulting in the categories its been given in the

past– Frequency values on word-category pairs.– Calculate the individual word-category pairs percentage of the

group– Quality selection limiters

• Final category selection

16. Unit Test: Prioritised elements.

17. Transaction: Month tags.

18. Mass categorizing.

• Stack identical transactions

• Select multiple transactions in a list

• Mass categorize group of transactions

19. Category: Static subcategories: Categorize transactions.

20. Kick starter strategy: Pre approved word category pairs.

21. Transaction: Cash in hand creation.

22. Graphical visualisation overview: Interactive.

23. Transaction: Search functionality: Words.

24. Import comparability: BEC data format.

25. Transaction: Split up.

26. Login security: Release version: user/roles authentication.

27. Bug: Data redundancy: Transaction text being changed in the financialinsitute database has backwards effect on older transactions. Changedtransactions will appear as new transactions to Moina.

28. Optimization

• Quality category selection limiters

• A quick and easy process to the get the financial perspective.


• Uphold a quick UI to avoid user dropping.

Appendix G

List of Acronyms

BEC Bankernes Edb Central

CF Collaborative Filtering

CSV Comma Separated Values

DDD Domain Driven Design

DI Dependency Injection

EF Entity Framework

MDF Master Database File

MVC Model View Controller

ORM Object Relational Mapping

PBS Pengeinstitutternes Betalings Systemer

PFM Personal Financial Management

UCD User Centred Design

UI User Interface

UL Ubiquities Language

88 List of Acronyms

Appendix H

Moina Screendumps

90 Moina Screendumps

Figure H.1: Moina Transactions

91

Figure H.2: MyMoina Graphs

92 Moina Screendumps

Bibliography

[1] Scrum development. http://en.wikipedia.org/wiki/Scrum_%28development%29, December 2010.

[2] Architecture current session. http://nhforge.org/doc/nh/en/index.html#architecture-current-session, April 2011.

[3] Asp.net mvc3. http://www.asp.net/mvc/mvc3, April 2011.

[4] Automapper. http://www.codeplex.com/AutoMapper, April 2011.

[5] Content-boosted collaborative filtering for improved recommenda-tions. https://www.aaai.org/Papers/AAAI/2002/AAAI02-029.pdf, April 2011.

[6] Danmarks statistik 2009 befolkning antal. http://www.dst.dk/TilSalg/abonnementer/StE/emneopdelt.aspx?psi=1216, April2011.

[7] Domain driven design. http://en.wikipedia.org/wiki/Domain-driven_design, April 2011.

[8] Factory pattern. http://msdn.microsoft.com/en-us/library/ee817667.aspx, April 2011.

[9] Finansraadet statistik 2009 betalingsformidling. http://www.finansraadet.dk/tal--fakta/statistik-og-tal/betalingsformidling.aspx, April 2011.

[10] Fluent nhibernate. http://www.fluentnhibernate.org/, April2011.

http://en.wikipedia.org/wiki/Scrum_%28development%29

http://en.wikipedia.org/wiki/Scrum_%28development%29

http://nhforge.org/doc/nh/en/index.html#architecture-current-session

http://nhforge.org/doc/nh/en/index.html#architecture-current-session

http://www.asp.net/mvc/mvc3

http://www.codeplex.com/AutoMapper

https://www.aaai.org/Papers/AAAI/2002/AAAI02-029.pdf

https://www.aaai.org/Papers/AAAI/2002/AAAI02-029.pdf

http://www.dst.dk/TilSalg/abonnementer/StE/emneopdelt.aspx?psi=1216

http://www.dst.dk/TilSalg/abonnementer/StE/emneopdelt.aspx?psi=1216

http://en.wikipedia.org/wiki/Domain-driven_design

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/library/ee817667.aspx

http://msdn.microsoft.com/en-us/library/ee817667.aspx

http://www.finansraadet.dk/tal--fakta/statistik-og-tal/betalingsformidling.aspx



http://www.fluentnhibernate.org/

94 BIBLIOGRAPHY

[11] An introduction to coldfusion frameworks. http://www.adobe.com/devnet/coldfusion/articles/frameworks_intro.html, April2011.

[12] Iso 9241/110 - usability. http://www.userfocus.co.uk/articles/ISO9241_update.html, April 2011.

[13] jq grid. http://www.trirand.net/demoaspnetmvc.aspx, April2011.

[14] Jquery ui. http://jqueryui.com/, April 2011.

[15] Last.fm. http://en.wikipedia.org/wiki/Last.fm, April 2011.

[16] Meniga - pfm is the future of banking. http://www.meniga.com/upload/Meniga-PFM_is_the_Future_of_Online_Banking.pdf,April 2011.

[17] Mvc pattern. http://msdn.microsoft.com/en-us/library/ff649643.aspx, April 2011.

[18] .net 4 framework. http://msdn.microsoft.com/en-us/library/w0x726c2.aspx, April 2011.

[19] Nhibernate. http://nhforge.org/, April 2011.

[20] Ninject. http://ninject.org/, April 2011.

[21] Null object pattern. http://en.wikipedia.org/wiki/Null_Object_pattern#C.23, April 2011.

[22] Object-relational mapping. http://en.wikipedia.org/wiki/Object-relational_mapping, April 2011.

[23] One session per request pattern. http://nhprof.com/learn/alerts/MultipleSessionsInTheSameRequest, April 2011.

[24] Rhino mocks. http://www.ayende.com/projects/rhino-mocks.aspx, April 2011.

[25] Service locater pattern. http://msdn.microsoft.com/en-us/library/ff648968.aspx, April 2011.

[26] Strategy pattern. http://www.dofactory.com/Patterns/PatternStrategy.aspx, April 2011.

[27] User-centred design and agile development. http://journal.code4lib.org/articles/561, April 2011.

http://www.adobe.com/devnet/coldfusion/articles/frameworks_intro.html

http://www.adobe.com/devnet/coldfusion/articles/frameworks_intro.html

http://www.userfocus.co.uk/articles/ISO9241_update.html

http://www.userfocus.co.uk/articles/ISO9241_update.html

http://www.trirand.net/demoaspnetmvc.aspx

http://jqueryui.com/

http://en.wikipedia.org/wiki/Last.fm

http://www.meniga.com/upload/Meniga-PFM_is_the_Future_of_Online_Banking.pdf

http://www.meniga.com/upload/Meniga-PFM_is_the_Future_of_Online_Banking.pdf

http://msdn.microsoft.com/en-us/library/ff649643.aspx


http://msdn.microsoft.com/en-us/library/w0x726c2.aspx

http://msdn.microsoft.com/en-us/library/w0x726c2.aspx

http://nhforge.org/

http://ninject.org/

http://en.wikipedia.org/wiki/Null_Object_pattern#C.23

http://en.wikipedia.org/wiki/Null_Object_pattern#C.23

http://en.wikipedia.org/wiki/Object-relational_mapping

http://en.wikipedia.org/wiki/Object-relational_mapping

http://nhprof.com/learn/alerts/MultipleSessionsInTheSameRequest

http://nhprof.com/learn/alerts/MultipleSessionsInTheSameRequest

http://www.ayende.com/projects/rhino-mocks.aspx

http://www.ayende.com/projects/rhino-mocks.aspx



http://www.dofactory.com/Patterns/PatternStrategy.aspx

http://www.dofactory.com/Patterns/PatternStrategy.aspx

http://journal.code4lib.org/articles/561

http://journal.code4lib.org/articles/561

BIBLIOGRAPHY 95

[28] View model pattern. http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx, April 2011.

[29] Floyd Marinescu Abel Avram. Domain-Driven Design Quickly. C4Media,2006.

[30] Kelly Goto and Emily Cotler. Web ReDesign 2.0. Number 0-7357-1433-9.Peachpit Press, 2005.

[31] Mohamed Meligy. Which orm? linq to sql, entity framework? ll-blgen? nhibernate?. . . ? http://gurustop.net/blog/2009/10/31/which-orm-linq-to-sql-entity-framework-llblgen-nhibernate/,Sep 2009.

[32] Ayende Rahien. Nhibernate vs. entity framework 4.0. http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx, January 2010.

http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx




http://gurustop.net/blog/2009/10/31/which-orm-linq-to-sql-entity-framework-llblgen-nhibernate/

http://gurustop.net/blog/2009/10/31/which-orm-linq-to-sql-entity-framework-llblgen-nhibernate/

http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx



Moina - A Time Saving Personal Financial Management...

Documents

Transcript of Moina - A Time Saving Personal Financial Management...