Mass Observation

Design Description

Version 0.6

Doc. No.:
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Revision History
Date Version Description Author
2010-10-07 0.1 Initial Draft, Mobile application Josip Petrić
2010-10-07 0.2 Web application Sandi Winter
2010-10-08 0.3 Web application (Database model) Igor Bučec
2010-10-08 0.4 Introduction and minor revisions Sureshkumar Yadav
2010-10-08 0.5 Web application (MVC architecture) Igor Bučec
2010-10-08 0.6 Web application (Error handling) Sandi Winter

Page 3
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Table of Contents
1. Introduction 5
1.1 Purpose of this document 5
1.2 Intended Audience 5
1.3 Scope 5
1.4 Definitions and acronyms 5
1.4.1 Definitions 5
1.4.2 Acronyms and abbreviations 5
1.5 References 6

2. External interfaces 6
2.1 Web application user interface 6
2.2 Web user interface login examples 7
2.3 Web application modularization 7
2.4 Mobile application user interface 7

3. Software architecture 9
3.1 Conceptual design 9
3.1.1 Web application architecture 9
3.1.2 Mobile application architecture 11
3.2 System specification 11
3.3 Error handling 12

4. Detailed software design 13

4.1 Directory structure 13
4.1.1 Web application directory structure 13
4.1.2 Mobile application directory structure 14
4.1.3 Web application Class diagram 15
4.2 Sequence diagrams 16
4.2.1 Mobile application sequence diagram 16
4.3 Database model 17
4.3.1 Admin module 17
4.3.2 Initiator module 17
4.3.3 Observer module 17
4.3.4 Customer module 17

5. Approvals 17

Page 4
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

1. Introduction

1.1 Purpose of this document

Mass Observation is a SCORE project whose intent is to create a web-based tool supporting observations from
mobile devices. This typical client/server application requires creating an observation event on web and
distributing it to the specific group of people for massive input on server part. It also requires the people who are
chosen to observe to submit the observation by mobile application on the client part.

The purpose of this document is to present the design description of Mass Observation project.

1.2 Intended Audience

• MOb proponent and customer[Stephen Fickas]

• MOb project supervisor
• DSD teachers
• Project team members
• All other stakeholders who are interested in this project

1.3 Scope
This document describes the detailed design of the project. The web application, database application and
mobile application architectures and the interfaces are explained in this document.

1.4 Definitions and acronyms

1.4.1 Definitions

Keyword Definitions
MOb Mass Observation
SCORE International student contest on software engineering

1.4.2 Acronyms and abbreviations

Acronym or
Definitions
abbreviation
W3C World Wide Web Consortium
CSS Cascading Style Sheets
HTML HyperText Markup Language
MA Mobile Application
UI User Interface
MVC Model-View-Controller pattern
OE Observation Event
XML EXtensible Markup Language
GUI Graphical User Interface
MOb Mass Observation
PHP Hypertext Preprocessor
Page 5
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

1.5 References

2. External interfaces
The MOb system presents a web-based GUI to the user for purpose of creating observation events and
monitoring it. Mobile based GUI is provided for the purpose of receiving instructions and recording observation
events.

2.1 Web application user interface

The user interface of the Mass Observation system is a standards-compliant and user-friendly web application
user interface.

It is based on HTML, CSS and JavaScript (with the jQuery framework). This conforms to the best practices that
the W3C recommends.

Figure 1: Web application user interface sketch

The sketch of the web application user interface shows regions of the site the user is going to interact with.

The navigation is based on two menus. We have a main menu that is generated depending on the permissions
that a user has. Side menu displays the options that are available depending on the module that was selected in
main menu.
All users can see the user bar for logout, change profile preferences and additional functions if necessary.
Forms, lists, status messages and other main content will appear within a Main content region.
Copyrights, site info and a link list are displayed in the footer part.

Page 6
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

2.2 Web user interface login examples

Figure 2: Web user interface login examples

1. User who has the role of Consumer and the initiator

2. User who has the role of Consumer, initiator, observer, admin

2.3 Web application modularization

Each user can have permissions/roles to specific modules (Initiator, Observer, Consumer and Admin). Main
menu will be generated by special library depending on the permissions that a user has. Each of the modules
will be implemented within its controller. The controller will load the view with main content and side menu.

2.4 Mobile application user interface

Mobile application user interface is composed of standard Android GUI components. User interface is built to
be user friendly and intuitive. Part of user interface is written using XML layout files and part are generated
using Java (in code generated components). XML layout is used to generate fixed user interface component.
Java is used to generate user interface components at run-time.

Page 7
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Figure 3: Mobile application Login View Figure 4: Mobile application Main View sketch
sketch

Figure 5: New OE View sketch Figure 6: OE View sketch

Mobile application user interface is composed of several views which change regarding users actions. On the
pictures above four main views are shown: login view, main application view, new OE view and OE. Using
main application view (Figure 2) user can download new Observation Event or access to currently available
Observation Events. Using New OE view user can accept or decline OE invitation. Using OE view user can
make observations for selected OE.

Page 8
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

3. Software architecture

3.1 Conceptual design

MOb system contains of three main components: Web Application, Mobile Application and Database. In next
sections each component will be described separately.
3.1.1 Web application architecture

Figure 7: Web application model

Page 9
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

3.1.2 The MVC architecture

Figure 8 MVC Architecture

The aim of using MVC architecture is to devide application logic from the presentation and busniess logic.
The anvantage of using MVC:
• Easier maintenance, testing, update the application
• Flexibility in planning and implementing object Model.
• Reuseability and morularoity
• Parallel developmnet of objects
• The application is extensible and scalable

Model – Business logic. It represents data structures. Provide functions for retrieve, insert and update
information in our database.
View – Presentation logic. It is the information that is being presented to a user. Normally, this is the web page,
but in Codeigniter a view can also be a page fragment (header or footer). Also it can be RSS page, or any other
type of “page”.
Controller – Application logic – contains logic of the page. It joins everything together and generates the page
for the user

Page 10
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

3.1.3 Mobile application architecture

Figure 9: Mobile application model

Mobile application is built using modified MVC architectural pattern. Main application components are: Model,
View, Controller, XML Parser module, Communication module and Security module. MVC pattern is modified
because Controller and View component are not strictly divided. Web-services module shown on the figure is
not part of mobile application but is shown to clarify model.
View component is used to represent data to the user in simple way. View component consists of XML layout
files, resource files (e.g. pictures) and Activity type classes. XML layout files define components used to
implement user interface. Some UI components need to be created at run-time. To make that possible those UI
components are created in Activity type classes.
Controller is component that receives input from View and instructs model and View to make actions based on
that input. Controller is implemented in Activity type classes.
Model is used to manage data and information and is separated from View or Controller.
Mobile application and Web application are using web-services to communicate. To make that communication
secured some security protocols needs to be implemented. Security module implements all necessary security
protocols. All the communication with Web application goes through Communication module which uses
Security module methods if necessary.
XML Parser module is used to parse XML files received in communication with Web application.

3.2 System specification

Web application is powered by:

Virtual machine: Linux OS

Server: Apache 2.2
Database: MySQL 5.x
Languages: PHP, Javascript
Frameworks: Codeigniter (the PHP framework), JQuery (Javascript framework)
Styles: HTML, CSS
Page 11
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Web application
Mobile application is Android based application and because of that is will be written using Java programming
language. Mobile application will be developed using Eclipse development tool and will be written for Android
1.5 operating system. It won’t have problems running on mobile phones with higher operating system.

3.3 Error handling

We will use several methods to capture errors:

show_error('message')

This function will display the error message supplied to it using the following error template:
“application/errors/error_general.php”

show_404('page')

This function will display the 404 error message supplied to it using the following error template:
“application/errors/error_404.php”

log_message('level', 'message')
There are three message types (error, debug, info):

1. Error Messages. These are actual errors, such as PHP errors or user errors.

2. Debug Messages. These are messages that assist in debugging. For example, if a class has been
initialized, you could log this as debugging info.

3. Informational Messages. These are the lowest priority messages, simply giving information regarding
some process.
Error occurred while processing the form will be caught by Form Validation Library

Error Action
page doesn’t exist Show 404 error page
username or password is incorrect Message incorrect username or password
the user name already exists in the database, Message: user already exists
when adding the user
forbidden characters appear in URL Alert URL is incorrect
Failed connection to database Alert user and administrator
PHP scripting error Alert user and administrator
Field not filled Message: Field is required.
Invalid email address Message: Field must contain a valid email address
Invalid url in form Message: Field must contain a valid URL
If alphabetical character is inserted, but not allowed Message: Field may only contain alpha-numeric
characters

Page 12
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

4. Detailed software design

4.1 Directory structure

4.1.1 Web application directory structure

systems

application mass_observation

cache
config

config
codeigniter
controllers

database controllers

errors

fonts errors

helpers

helpers helpers
language

language
language
libraries

libraries
logs
models

logs models

views

views views

Figure 10: Web application directory structure

Using the CodeIgniter framework we have the ability to make few applications with the same framework core.
For example, if we want to make a new application, only what we have to do is create a new folder with the
application name inside the application folder (in our case we have created a new folder with name
“mass_observation”). Additional we have to copy all of folders from the application to our new application
folder (config, controllers, errors…). Same steps are for second application.
If we have only one application, it is not needed to make previous actions, simple we can use application folder
as the main folder of our application.
Directories description:
• system – the main folder. It separates Web application from the other files and folders on the server. This
folder contains an application folder for our application(s) and other folders and files which describe
application core. Commonly we will not use any other folder than application folder because it can be
“dangerous” change file from the application core.

• application – as said before, this is the folder of our application. Application folder consists of:
▪ config – the configuration folder consist all files necessary for configure our application (e.g.,
base url, index page, default language, database connectivity settings, routing, …)
▪ controllers – in the controllers folder we make our controllers as requires MVC (model – view
– controller) architecture. Controller is the hart of our application, as they determine how
HTTP request should be handled.

Page 13
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

▪ errors – folder for specifying errors for application. We can separate errors from the our
controller what is very important for maintenance.
▪ helpers – consists files (classes) which help us with tasks. Each helper file is simply a
collection of functions in a particular category. For example we have “URL Helpers” that
assist in creating links, “Form Helpers” that help us create form elements…
▪ language – as the name of folder says this folder help us to create multi language application.
▪ libraries – libraries folder consists modules for our application. CodeIgniter have much default
libraries (e.g. Calendar, Database, Email, File uploading…). The one library is described as
class which has configurations and methods for module.
▪ models – models folder consist PHP classes that are designed to work with information in our
database. For example, model class contains functions to insert, update and retrieve our page.
Models are required by the MVC architecture.
▪ views – views folder consist view files. View files are simply a web page, or a page fragment,
like a header, footer, sidebar, etc. Views are never called directly; they must be loaded by a
controller as required by the MVC architecture.

4.1.2 Mobile application directory structure

Figure 11: Mobile application directory structure

Mobile application directory structure is shown on figure 6. There are two main groups of folders:
source and resource folders.
Folders description:
• src – contains all the Java source code for the application.
▪ ma.mob.main – view and controller source files (Activity classes)
▪ ma.mob.model – all the necessary classes to implement data model
▪ ma.mob.security – classes for Security module
▪ ma.mob.parser – classes for XML Parser module
▪ ma.mob.utility – utility classes for the application
Page 14
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

▪ ma.mob.interfaces – all the interfaces for the application

• res – contains all the resources for mobile application
▪ drawable – all the images used by the application
▪ layout – holds all XML files used to define components and layout of user interface
▪ values – XML file holding values of some variables used in XML layout files
▪ resources – all other resources for mobile application

4.1.3 Web application Class diagram

Web services modul
Webservice
«uses» SecurityLibrary
CodeIgniter Framework
+login()
+get_interface() +encrypt()
+make_ob() +decrypt()
+list_ob()
CodeIgniter
Libraries

Web services modul

UserAuthLibrary
Authentication
«uses»
+set_table()
Controller +index() +set_identity()
CI_Base
-_ci_scaffolding +login() +set_credential()
-instance +logout() +authenticate()
-_ci_scaff_table
- +registration() +is_valid()
+Controller()
+CI_Base() +has_identity()
+_ci_initialize()
+get_instance()
+_ci_scaffolding()

Admin modul
Accounts_model
MOB_Controller Admin
ACLLibrary «uses»
«uses» +create_account()
+init() +index() +get_accounts()
+add_role()
+add_user() +get_by_username()
+add_resource()
+edit_user() +get_type()
+allow()
+delete_user() +update_account()
+is_allowed()
+list() +update_password()
+delete_account()

Initiator modul ObservationEvents_model

Observation modul «uses» +create_oe()

Initiator +get_oe()
+update_oe()
Observations_model Observer +start_oe()
«uses»
+index() +stop_oe()
+create_oe()
+create_ob() +index()
+edit_oe() «uses»
+ignore_ob() +make_ob() InterfaceComponents_model
+start_oe()
+read_ob() +list()
+stop_oe()
+list()
+add_checkbox()
+add_image_capture()
+add_voice_recording()
+add_writen_node()
+get_oe_components()
+get_component_types()

Figure 12: Web application initial class diagram

Page 15
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Image shows class diagram which contains representative classes of the model and controller layers of the
application, and shows how those classes are connected and dependant on each other. Each of the modules will
be implemented within its controller. Each controller inherits the basic controller.

• MOB_Controller - Used to check access and initiate specific resources common to all controllers.
• Webservice controller – Needs to implement web service actions for login, get interface of observation
event, make and list observations events available for specific user.
• Authentication controller - Needs to implement actions for login, logout and registration new users.
• Admin controller - Needs to implement actions for add user, edit user, delete user and list available
users.
• Initiator controller – Needs to implement actions for create, edit, start, stop and list observation events.
• Observer controller - Needs to implement actions for make and list available observations.
• Accounts_model - Needs to implement methods for manipulating accounts data in the database.
• ObservationEvents_model - Needs to implement methods for manipulating observations events data in
the database.
• InterfaceComponents_model - Needs to implement methods for manipulating interface of observation
event.
• Observations_model - Needs to implement methods for save and read observations data in the
database.
• SecurityLibrary - There is to maintain the security of data transfer which is non-functional requirement
• UserAuthLibrary - Needs to implement authentication functionality and maintaining the session.
• ACLLibrary - Needs to implement Access control list functionality. You can add role and application
resources (Controller, method and parameters) and allow user access to certain resources. After that is
used to check if the user has access to certain resources.

4.2 Sequence diagrams

4.2.1 Mobile application sequence diagram

Figure 13: MA sequence diagram

Page 16
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Sequence diagram shown on figure 7 shows how mobile application communicates with web-server
using web services.

4.3 Database model

Figure 14: Database model

Figure 11 shows ER model. We have four modules: the admin, the initiator, the observer and the customer
module.
4.3.1 Admin module
Administration module consists of the authentication and the administrator module – user control, group control,
observation event control, observations control. Account describes a user who has an account. Every account
(user) has role (admin, initiator, customer or observer). Every user can have more than one role. Also every user
can belong to any group. Group has one or more users. It can be group of observers, or group of customers.
4.3.2 Initiator module
Initiator module consists of the observation event. Every initiator can develop observation event. Every
observation event has one or more interface component. The interface component describes component which
initiator want to use for observation event. Every interface component has type of component. Type of
component determines which table to use for form generation. As required we have four elementary tables:
checkbox, image capture, voice recording and written notes (more types may be added later). Every table is
specific in relation to type. So, every interface component can have one type or more types.
4.3.3 Observer module
Observation module consists of the observation. Every observation has one observation event, one group of
observers, time and location stamp. Location can have exactly name of location and x, y coordinate. One
location has one observation.
4.3.4 Customer module
Customer model will contain all the tables necessary to represent observations data in more details and suitable
for further analysis.

5. Approvals

Page 17
Mass Observation Version: 0.6
Design Description Date: 2010-10-08

Date
Name Title Signature
yyyy-mm-dd
Mr. Stephan Fickas Project Customer
Mr. Thomas Leveque Project Supervisor

Page 18