Hello Everyone! Welcome to our third blog on System Design. After analyzing the requirements and formulating the corresponding user stories, we are now in the design phase. This process involves defining the architecture, modules, interfaces, and data for our system to satisfy specified requirements.

We have used interaction diagrams to represent the behavior of the system and class diagrams for the classes and methods that will be used. We will introduce the design pattern which we will be adapting in our development process. We will also see the development strategy of our team and some changes that occurred in the past two weeks.

Behavioral Diagram

Interaction diagram for use case “Logging an activity”

Activity diagram for use case “review activity”

Class Diagrams

Login

HomeScreen

Settings

Review

NavigationPane

LogActivity

RoomDatabase

Category

ActivityClass

Design Pattern

The main object of our application is to manage logs of activity. We have to create many objects of the same class with different variations like the start time, end time, duration, category, status, alert … Normally, creating and assembling all parts of a complex object directly within a class itseft is stiff and not flexible; therefore we chose to use a creational pattern for our application for easier constructing and directing our objects.

Among many creational pattern, the builder pattern introduced by the Gang of Four stands out as flexible solution to various object creation problems. It helps solving the problem of creating different representations of a complex object and simplifying that process into customizing a normal object. The clear advantages ^[2] of the Builder pattern are:

• Allows you to vary a product’s internal representation.
• Encapsulates code for construction and representation.
• Provides control over steps of construction process.

The constructing can then be delegate to the builder class to acchieve the seperation of the construction and representation of every complex objects. Below is a sample class diagram of a Builder pattern ^[3]

Development Strategy

To manage and monitor our work and especially our progress we stay in close contact with each other. Most importantly to mention are our regular meetings. Apart from meeting directly after the customer meeting, we also started to meet at least one more time during the week. Meetings after the appointment with the customer are used to discuss the outcome of that meeting, new or changed information and to plan the next sprint. That includes adding user stories to the dashboard or modify existing ones. That is followed by estimating the user stories included in the next sprint and split work accordingly.

Additional meetings are set when there is a specific topic to be discussed like, e.g., how our system design should look like. Those meetings are precisely documented to keep a general view over our progress.When everyone has gotten his or her responsibilities for the next week we start working on the respective topic, update the other team members or ask for support via slack and move the user stories on the dashboard according to our progress.Our experience over the last weeks is, that this approach works out pretty good for our team. Everybody gets kept in the loop, knows where possible risks are and where additional effort is necessary. That helps us to reach optimal success in our project.

Summary of changes

During our team meetings, we came across few requirements which we were uncertain about. For instance, we were not sure if we need to include a calendar view in the home screen to review the activities. Likewise, what happens when a user adds more than one activity for the same time stamp. We discussed these questions with the customer and decided to go with below requirements.

• Home screen will not have a calendar view but it should display last 10 activities.
• User can add multiple activities with overlapping time period.

Thank you for visiting our blog!! See you next time with more interesting details on Implementation.

Resources

[1] - www.classes.cs.uchicago.edu. Retrieved 2016-03-03.

[2] - The Builder design pattern - Structure and Collaboration. w3sDesign.com. Retrieved 2017-08-12.