After successful Requirement Analysis phase, we started the system design phase. In this phase, the system behavior and functionalities are defined in broad overview.
Core Objective
At its basic, the application is required to collect a series of data from the user and perform different operations based on the data. The data in this case are related to a basic transaction(Income/Expense). According to our customer, following data has to be present for each transaction
- Date
- Amount
- Brief Note
- Category
- Type (Income/Expense)
- Source(Payment Type, z.B. Cash/Bank etc)
A brief Example of what and how the user wants to enter can be seen in the following mockup diagram we created for the data entry page of our application.
This Data will be then listed on the Timeline(shown below) or could be filtered using different available fields.
Class Diagrams
Hence, our core data is surrounding the transaction. Initially, we designed an ER Diagram for all the data related to every transaction.
In the ER diagram, we see that we have three entities:
- Transaction: Stores core information(note,date,amount)
- Category: Stores the category information
- PaymentType: Stores the payment type
These entities are now connected by an intermediary table Transaction_Category_Source(marked as “Of”), which will be useful later on if we want to store multiple payment type or category in the future.
Following is a basic overview of the class diagram for the complete combination. The intermediate table is not marked as it is used by our Controller solely to combine the transaction into a whole information set.
From the diagram we observe that Transaction/Category/PaymentType are our main classes, which provide fields to store crucial information related to the classes. These classes also provide certain methods(such as getAllTransactions) to access their corresponding data from the database.
The main classes and their purposes are
- Transaction: Store the note, date, amount of the transaction as well as reference to the category and payment type
- Category: Stores the information regarding its name, icon(will be accessed as drawable resouce)
- PaymentType: Stores the information of which method of payment was used(Cash/Bank/Credit Card) and icon name(similar to Catgory)
- DBHelper: This class is the controller of our application, this will handle all communication with database and generate appropriate data required by the Views(Activities)
- TimelineActivity: Lists the recent transactions and total balance
- AddTransactionActivity: Allow user to save new transaction information
At this stage, we agreed with customer that, each transaction can have 1 to 1 cardinality(relation) with Category and PaymentType, that is, each transaction may only have 1 category and paymenttype.
The DBHelper aggregates the transactions/categories/paymenttypes using the corresponding methods, as well as uses its own private methods(not shown in the diagram) to combine and share the corresponding data as required by the application to provide access to user.
Interaction Diagram
For our first sprint, we are to build the basic functionality of
- Onboarding where we collect username and currency when the user installs the application for th first time. This process takes place only once.
- A timeline to show most recent 15 transactions and the balance of all transactions in the Timeline screen.
- Add new transaction
Following is our interaction diagram.
Design Patterns
Our core pattern is MVC(Model View Controller).
They are as following
- Model: Transaction/Category/PaymentType
- View: Activities
- Controller: DBHelper
We used the DBHelper to control all communication with Database and update the Views. This will allow us to keep our concerns separate.
Development Strategy
We used ZenHub as well as group meetings to arrange and divide the implementation tasks.
We also divide all major features into small sprints, so everyone is contributing.
With Zenhub each feature is assigned to a person, if the assigned person can not or do not complete the task in time, it is moved to next sprint. It is also possible to switch person responsible for certain tasks if there are issues with the current assigned person.
Summary Of Changes
We did not have any major changes in our development and requirements. However, we realized that certain key changes during our design, which would help us to accelerate and keep our progress consistent.
Some of the changes are
- Introduction of MVC Pattern
- Onboarding Activities for pleasing user experience
- Using Transaction Type to manipulat transaction amount instead of making extra field for transaction type
- Separation of Models(Category & PaymentType) as independent classes instead being stored as Strings in Transaction table
- Rearrangement of Responsibilities for Group members(as some of our members are facing personal issues and failign to contribute required time)