System Design

28 May 2018

Reading time ~11 minutes

Welcome to our Third Blog Article, this post explains in detail about the next development phase; that is System Design of our Activity Monitoring Android Application.

We, the Team ATOM are glad to launch the name of our application, SYMBIOTE which is a kind of host-parasite relationship between two systems. From the Application perspective, this Activity monitoring App, Symbiote act as a parasite, depending highly on its host which is the User. Unlike the ideal parasite, SYMBIOTE improves the efficiency of the user spotting out all the wasted time.

The Application’s Logo -:

complimentary

As per the customer requirements, we have formulated a list of 20 user stories. Two behavioral/ interaction diagrams are designed based on the following user stories and use cases.

Activity Entering

As a user, I would like to create a new activity under a category so that a new type of activity can be entered as per his wish
As a user, I want to add description about the activity so that the desired details can be entered.
As a user, I want to add date on which that particular activity has been carried out.
As a user, I want to specify duration when the activity has been carried out so that the time consumed for each activity can be known.
As a user, I want to customize colors for each activity so that each activity can be distinguished from another.
As a user, I want to repeat the same activity do that the duplicate entering of the same activities can be avoided.

Based on the above user stories, A use case diagram has been designed and updated in the last blog from which the below sequence diagram has been derived.

The Sequence diagram of Activity Entering use case is as below:

complimentary

This interaction diagrams describes the event of activity entering where the application fetches the relevant input data from the user and then processes and validates the inputs and eventually store them in the database. Hence, this interaction diagram involves the sequence or interaction between three systems: User, Application (Activity Entering) and database.

The user inputs the category in the provided field asynchronously.
The application checks if that category exists in the database which is a synchronous call to the database and can only proceed further once the database responds.
The database responds with an acknowledgement Yes or No.
The negative acknowledgement from the database triggers the event which expects the user to add that category as a new category.
The user enters the required fields namely activity, date, duration, description and color asynchronously.
The user is given the privilege to enable or disable repetition for that activity if it’s a routine activity.
If Disabled, the application stores “FALSE” in the database and otherwise, the application stores “TRUE” which in turn triggers the database with a synchronous call to return the result set as M, W, D.
The application triggers a synchronous event to get input from the user for choosing the repetition and the application validates the user input.
The user now clicks submit which triggers the application to start a synchronous call to insert all these data onto the database such that an activity with all its relevant properties are stored in the database
On successful update in the database, The Database returns a positive acknowledgement which prompts the application to inform the user, the message stating that “ the activity entered successfully”.

As a result, the user remains active throughout the process and hence represented with a continuous action bar and the application as well remains active throughout the entire sequence of events, and hence, having a continuous action bar. On the other hand, the database is only being active at certain instances whenever any update or retrieve process happens at the database.

Activity Log Monitoring

As a user, I want to have a monitor log so that the undergone activities can be tracked later.
As a user, I want to filter by date so that the different activities done during a particular period can be retrieved.
As a user, I want to filter by activity so that a specific activity done during different times can be retrieved.
As a user, I want to filter by category so that all the activities under one particular category can be retrieved.

Based on these above user stories, A Log Amonitoring use case diagram has been designed as shown below.

ActivityMonitoring Use Case

The Sequence diagram for this Use case is as below:

complimentary

This interaction diagrams describes the event of activity Log monitoring where the application fetches the relevant input data from the user and then processes and validates the inputs and eventually retrieves the data as per the selection from the database. Hence, this interaction diagram involves the sequence or interaction between three systems: User, Application (Activity Log Monitoring) and database.

The User sets the range or duration that is, the Start date and End date to retrieve all the activities undergone during that period.
The application validates the entry for Start date and End date such that the End Date must be greater than Start Date.
On successful validation, the user clicks on the Submit button which triggers the application to launch a synchronous event to retrieve the activities as per selection (date) from the database.
The database sends the selection data to the application which is displayed onto the user from the application via the method display filter_date.
The User sets the category to retrieve all the undergone activities of that category during that period.
The application validates the entry for category to check if it’s a valid category defined in the database.
On successful validation, the user clicks on the Submit button which triggers the application to launch a synchronous event to retrieve the activities as per selection (date, category) from the database.
The database sends the selection data to the application which is displayed onto the user from the application via the method display filter_category.
The User sets the activity to retrieve all that particular activities of that particular category during a defined period.
The application validates the entry for activity to check if it’s a valid activity defined in the database.
On successful validation, the user clicks on the Submit button which triggers the application to launch a synchronous event to retrieve the activities as per selection (date, category, activity) from the database.
The database sends the selection data to the application which is displayed onto the user from the application via the method display filter_activity.
The User sets the range or duration that is, the Start date and End date to retrieve all the activities undergone during that period.
The application validates the entry for Start date and End date such that the End Date must be greater than Start Date.
On successful validation, the user clicks on the Submit button which triggers the application to launch a synchronous event to retrieve the activities as per selection (overview) from the database.
The database sends the selection data to the application which is displayed onto the user from the application via the method display overview.

Class Diagrams

complimentary

The User Class is defined for the user which stores the properties of a user like Name, email address, PIN. The User Class is supposed to create only one user object as the application is designed for a single user and not multiple users in a single device.

An Activity class is also defined with its attributes namely Activity, Category, Color, Description, Date, Time, Repeat and End Date. An Activity belongs to one and only one category but, a category can have n number of activities tagged under it. The activity forms a subset of category. The category as its own, doesn’t have any specific properties and can be regarded as one property of activity which is why, the category hasn’t been defined with a separate class. The User class and the activity class is related to each other based on the create association, that is, each user can create as many as activities as he wishes to create. A User can have a minimum of one activity and can have a maximum of N activities which gives the multiplicity as [1,*] .On the other hand, a activity can have minimum and maximum of only one user which gives the multiplicity as [1,1].

A Log-Overview class is also defined for the purpose of filtering the activities as per the user selection. The user selection includes the input fields like Start Date and End Date which specifies the duration or range of time based on which the activities are filtered out. Apart from that, the user selection criteria also contain input fields like activity and category so that all the activities tagged under a specific category can be filtered out and all the activities of a particular name can be filtered out. To incorporate all these functionalities, specific methods are defined within the class. The Overview class is a view association of the User class, that is, A User do have the proficiency to view the logs and overview of all the activities that he had undergone.

The Database manager class is equipped with a number of methods which is required for the proper insert, update operations from all the other classes. The Database helper is the sole responsible for the core functionalities like creating and managing the user account, managing the activities and categories, PIN authentications, Filter and Display methods as per the user filter selection criteria to retrieve the required information, Activity Completion status and so on. Therefore, all the classes are having composition relation with the database manager; the existence of all other classes namely User class, activity class and Log_Overview class are highly dependent on database manager class. These classes will not exist if the database manager doesn’t exist.

User Class Attributes

complimentary

User Class Methods

complimentary

Activity Class Attributes

complimentary

Activity Class Methods

complimentary

Log_Overview Class Attributes

complimentary

Log_Overview Class Methods

complimentary

DB Manager Class Methods

complimentary

Our Design Pattern

complimentary

We are implementing Facade design pattern for our part of system implementation.

Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. This type of design pattern comes under structural pattern as this pattern adds an interface to existing system to hide its complexities. This pattern involves a single class which provides simplified methods required by client and delegates calls to methods of existing system classes.

For instance in our case : Assuming Class A to be User and Class B to be category and Class C to be Activity. The Facade class will be helpful as all methods of Class A ,B and C can be accessed by using Facade Class via an Interface making it a hassle free experience for user from UI perspective.

Development Strategy

Since the system design was agreed and fixed with customer by mid of May, we have quickly started with the layout implementation of the application. The progress monitoring always happens through GitHub where team members were assigned with a task on regular basis. The same was reviewed on team meetings. Since the timeframe was estimated for each use case story earlier, we will try to finish it without any deadline slip. In each sprint, a steady progress is always mandatory which helps in predicting that the end product completion happens in time. As of now, we will follow the software prototyping method along with continuous integration which means that incomplete developments of the end product will happen along with merging of all development copies to a common repository.

In Sprint 1, we had grouped the total layout creation and login page for the user with a time frame of one week scheduled to finish by end of May, 2018. This sprint is being worked on by the teammates now.
In Sprint 2, we will proceed on to the home page creation where user will have the choice of entering what he/she is doing. The time required is again estimated to be one week, scheduled to end by June 7th,2018.
In Sprint 3, the workload is comparatively bigger which requires two weeks of time in total for database integration and programming of activity/ category creation.
In Sprint 4, we will move on to the export/ log view for the data along with the integration testing, scheduled to end by week 4 of June, 2018 so that completion status will be 100% within the deadline.

complimentary

As a part of Scrum methodology we are using Zenhub to track our efforts.Hence by doing so we make sure that there are no discrepancies crated in future and all our efforts are deployed well ahead of the deadline. We have created issues in Zenhub and assigned to all our team members.As seen in the image we have commenced our Layout and DB implementation.Eventually we will be starting to work on export and filter feature.

complimentary

Summary of Changes

Finally, we have fixed a name for the application. It is called as “Symbiote”. Since there is a new suggestion from the customer to implement the see log and overview/export feature together in one page, a slight modification may be required on the design. Moreover, we have regrouped the team with each member assigned a development task that will happen in background irrespective of the sprint timelines.

That’s all for this week. See you all soon with the progress!!