OFFICIAL BLOG ARTICLE 3: SYSTEM DESIGN
Hello all, we are done with the requirements analysis (If this is new to you, then have a look at our previous article about the Requirements of our activity tracking app.). Now we are ready to move on to the next milestone: the system design. So, what is this blog about? It will be about Interaction Diagrams, Class Diagrams, Design Pattern and our Development Strategy to specify the Logic and Workflow of our software-application. Thus, let us start with the first interaction diagram belonging to the pre-defined user stories.
Interaction Diagrams
Acoording to Wikipedia, Interaction Diagrams are models that describe how a group of objects collaborate in some behaviour-typically single use case. We made three interaction sequence Diagrams as shown below.
Use Case: Login Activity
Our tracking app will only show up with a login-screen, if the user enabled the PIN-Security, previously. After entering the PIN the application will automatically check the validity of the number-input with an basic database system. Only if the entered PIN is correct, the app-process will be continued, otherwise the user receive an error message.
Use Case: Create New Activity
After the user successfully completed the PIN-Security-Check, as described earlier, the user can add a new activity, characterized with the follwing attributes: category, sub-category, description, start-time and the end-time.
Sequence Diagram
The sequence diagram represents the complete system design of our application, for example the PIN-Process, the Create-Activity-Process and the Storing-Process, as shown in the picture above.
Class Diagram
Essentially, the overall class diagram for our time tracking application is quiet elementary. Hence, we only need five additional classes for the implementation in Android Studio, which are the Activity, Category, Overview, LocalStorage and the Settings class. To amplify this further: When the user adds a new activty a new Activity object is created, which provides the following properties: a timespan (start and end time), a belonging category and additionally a sub-catergory and a short description. In order to deal with this optional properties we provide several constructor functions. Furthermore, we added for every adaptable variable a getter and a setter method to verify particular constraints for each variable. Moreover, the Category class is characterized by its name, color (for the visualization) and the activity stack, which holds all assigned activities, as well as a similar stack for the sub-categories (category objects), thereby it is theoretically possible to draw up a infinty long linked list (what we should limit for sure). Additional filter methods are for the overview and visualization purpose to filter particular activities or sub-categories out of the total stack. The Overview class provides methods to visualize the specific activities in a textual list, table or pie chart shape. In general, the LocalStorage class represents the database class and is associated with the three classes, described previously. It provides two main storage options: The first one is the standard way of storing data in an txt-file without decoding, whereas the other option stores the handed data by decode it at first. Therewith, we can store all user settings, activities and the optional PIN in an appropriate way. Moreover, the Settings class provides all user settings and is associated, as well as the LocalStorage class with the first three classes. The settings are the color for the categories, as mentioned before, the user PIN and finally the history or log timespan for the amount of data, which will be stored on the device.
Design Pattern
Design Patterns gives the solution to the recurring problems. We intend on using Singleton and the MVC design patterns.
The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.
In singleton design pattern we take a class and let the class mange the instance on its own and preventing the other classes creating a new instance.
Since we are tracking time spent on one activity by one single user here, when we are multi-tasking, there should not be two instances of activities recorded. That makes the data invalid and non-efficient. So, we use this design pattern so that we can only record one task at any point of given time.
We also use the MVC pattern. MVC Pattern stands for Model-View-Controller Pattern. This pattern is used to separate different layers of the application. MVC also facilitates easy and fast code changes and maintenance.
Model - Model represents an object. It updates the controller if its data changes.
View - View represents the visualization of the data that model contains.
Controller - Controller acts on both model and view. It controls the data flow into model object and updates the view whenever data changes. It keeps view and model separate.
There are chances that activities changes all the time and may be the user wants a different kind of view in the app, we use MVC so that we can create a view with the existing data without changing the entire code to just insert one activity or the view required.
Development Strategy
We keep up with the tasks already done and the upcoming tasks using Zenhub.
We will keep up with the regular sprint meetings.
We will start with the implementationa and see that there are no backlogs.
We will be meeting with the Cusomer.
Hopefully, you enjoyed reading our third blog article, so be excited of our next one.
Your Team myTimeTrackers