Software Design Description

Web Based GTD with Time Tracking

Version 0.1

July 30, 2014

http://goo.gl/W8cw34



Department of Software Engineering
College of Computer Science and Information Studies
GC University Faisalabad

Revisions
Overview
The document completely illustrates the design and architecture of the application. The
document is prepared after the detailed analysis and research upon the different designs and
architectures that may have been applicable to our application and describes the finally chosen
design and architecture for our application.
Target Audience
This document will act as a reference of what needs to be developed for our whole team.
It would provide information necessary to understand the design and architecture of the system.
Project Team Members
The team members are:
i. Kamran Ahmed
ii. Hafiz M. Hussain
Version Control History

Version


Primary
Author(s)

Description of Version

Date Completed


First
Draft


Kamran Ahmed

This is the first draft of this document and
the modifications are expected as the project
progresses.


June 18, 2014




___________________
Signatures for approval

Table of Contents

List Of figures: ................................................................................................................................1
List Of tables: ..................................................................................................................................1
1. Introduction .............................................................................................................................2
1.1. Design Overview .....................................................................................................................2
2. System Architectural Design...................................................................................................... 2
2.1. Chosen System Architecture.................................................................... 2
2.2. Discussion of Alternative Designs .......................................................................................... 3
2.3. System Interface Description ...................................................................................................4
3. Detailed Description of components....4
3.1 Web Application... 5
3.1.1. Controller.. 5
3.1.2. Model ... 5
3.1.3. View.......5
3.2. Web Server............................................................................................................................5
4. User Interface Design......5
4.1. Description of the User Interfaces............................................5
4.1.1. Figures....6
4.1.1 Fig.3 Inbox Interface...6
4.1.1 Fig.4 Agenda for Today..6
4.1.1 Fig.5 Project Interface.....7



1

List of Figures
Figure

Description
Figure 1

Context Diagram
Figure 2

Web Application
Figure 3

Inbox Interface
Figure 4

Agenda for today
Figure 5

Project Interface
List of Tables
Figure

Description
Table 1

Comparison of suitable architectures



2

1. Introduction
1.1. Design overview
The design pattern that we have chosen for our application is MVC and there are
several reasons for this choice. Apart from this, the others that we may have implemented
were the modular pattern, repository pattern, n tier architecture but
each one had its pros and cons, so after detailed analysis we decided to go with MVC
pattern. The details are given ahead.
2. System Architectural Design
Following section describes the chosen architecture:
2.1. Chosen System Architecture
The context diagram of the architecture that we have chosen for our application is
as follows:

Fig. 1. Context Diagram
The figure above shows that the application consists of basically two parts the web
application that runs on the users browser and the second one is web server that further
has an API and the database. The web application running in the browser sends a request
to the API on server. API decides the action that needs to be performed based upon the
request, gets the data from database (not necessarily) and returns the response back to the
web application running in the browser. The detailed look at the internal processing of
the web application can be viewed from the diagram shown below:

3



Fig. 2. Web Application
It can be seen that the web application block has 4 distinct entities i.e. a controller, model,
services and views. The users request is received by the controller which uses the
services to fetch data from the server, this data is then passed to the models and after that
processing, the data is sent to the view and the view is finally rendered to the user.
2.2. Discussion of alternative designs
The comparison table for each of the alternative designs is shown below:
The nonfunctional requirements of the application are following:

Design Patterns

Comments
i. Repository Pattern


Web application having most of the functionality on the
client side and accessing repository for each and every
action, repository pattern was best suitable for our project
but when we did some research there werent any
javascript available libraries or frameworks that may
have helped us implement that and everything would
have to be built from scratch, so the pattern wasnt
adopted.

ii. Singleton Pattern


4

We thought to use singleton pattern initially as we were
planning on creating a website and not a web application
but later on there were change of plans and we decided to
go with the web application for which the singleton
pattern wasnt suitable and thus not adopted

iii. MVC Pattern


MVC pattern was the best design pattern that suited our
application and fortunately we found a wonderful
framework called Angular JS which has wonderful data
binding, directives and other great features that made it
the best possible framework for our project. There were
other alternatives such as Backbone JS etc but the
features of Angular JS weighted more over the others.

Table 1. Discussion of suitable architectures

2.3. System Interface Descriptions
The list below shows the interfaces the system will have:
i. In respect of user interfaces the system will be having the following interaces:
a. Project Interface that will be displaying the project, its tasks and other
related actions
b. Agenda interface, showing the tasks grouped together based upon the due
date.
c. Parent interface having the application wide options e.g. print option,
projects and navigation etc.
ii. In respect of the hardware, the application will be interfacing with the web
server
iii. In respect of software, the system will be interfacing with the SMS API, the
database and the web browser.

3. Detailed Description of Components
Following is the list of different components of the system:
i. Web Application
ii. Web Server
a. API
b. Database

5

The detail of each of the components is given ahead:
3.1. Web Application
The fig. 2. represents the application. It can be seen that the application has 4 distinct
parts:
i. Controller
ii. Model
iii. View
iv. Services

3.1.1. Controller
We may say that the controller is the most important part of our application. Its where all
the processing is performed i.e. every data binding in our application is being done in the
controller section of the application. It is the part of the application that populates the
models, renders the views etc.
3.1.2. Model
It is the part where the data exists. In our architecture, the model is the part which has
data for example, it contains the tasks, other information regarding tasks and projects etc.
3.1.3. View
View is the part which is finally rendered and shown to the user.
3.2. Web Server
As it can be seen from the fig. 1, the web server has further two parts i.e.
i. API
ii. Database
API receives the requests, parses them and finally decides what needs to be done. API
then, depending upon, the request received uses the entity classes and the data is fetched
from the database. The resultant data is then encoded into JSON and then returned back
to the user.
4. User Interface Design
Following section shows and describes the interfaces that the application will have.
4.1. Description of the User Interfaces
The application basically consists of two major interfaces which are rendered in different
ways in different cases. These interfaces are the project interface and the agenda
interface. The project interface consists of plain tasks and the related options whereas the

6

agenda interface consists of the tasks grouped together based upon their due dates. Below
are the screen images showing the interfaces of our application:
4.1.1 Figures

Fig. 3. Inbox Interface
Fig. 3. shows the inbox interface of the application. Its the place where the tasks are added by
default i.e. the tasks having no associations with any of the projects.

Fig. 4. Agenda for Today
Fig. 4. shows the agenda for today that is the tasks having that need to be performed today. In the
same way there are interfaces for tomorrow, next 7 days and yesterday. Also there is an archive
page that shows all the tasks.

7


Fig. 5. Project Interface
Figure 5. represents the interface of a project i.e. a grouping of tasks having a specific name.