Software Architecture Document

iRoute
Bus Route Management System

Software Architecture Document
Version 1.1

Software Architecture Document_090534V.pdf
Version:
1.1
Date: 27/03/2012
Revision History
Date
Version
Description
Author
11/01/2012
1.0
Software Architecture Document - Initial

Version
Vidana Pathiranage L.C
27/03/2012
1.1
Software Architecture Document-V1.1
Vidana Pathiranage L.C
Confidential
iRoute , 2012
Page 2 of 12

Version:
1.1
Date: 27/03/2012
Table of Contents
1.
Introduction
1.1
1.2
1.3
1.4
1.5
4
4
4
4
4
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview
2.
Architectural Representation
3.
Architectural Goals and Constraints
4.
Use-Case View
4.1
5.
Use-Case Realizations
Logical View
5.1
5.2
6
6
Overview
Architecturally Significant Design Packages
6.
Process View
7.
Implementation View
7.1
7.2
9
9
Overview
Layers
8.
Deployment View
10
9.
Data View
11
10.
11.
Size and Performance
11
Response Time
Transactions per second
Capacity
Resource Utilization
11
11
11
11
Quality
12
11.1
Usability
Simple, Graphical User interface
Minimal surprise
Ease of use
User Guidance
11.2
Reliability
Availability
Accuracy
Mean time to recover
11.3
Extensibility
Confidential
12
12
12
12
12
12
12
12
12
12
iRoute , 2012
Page 3 of 12

Version:
1.1
Date: 27/03/2012

1.
Introduction
1.1 Purpose
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the
significant architectural decisions which have been made on the system.
1.2 Scope
This Software Architecture Document provides an architectural overview of the iRoute Bus
Management System. The iRoute System is being developed for Android mobile platform and the
application will output best possible bus route, given source and the destination.
1.3 Definitions, Acronyms, and Abbreviations

RUP Rational Unified Process
BMS Bus Route Management System
API Application Programming Interface
UML Unified modeling language
SAD Software Architecture Document
SDK Software Development Kit
ADT Android Development Toolkit
IDE Integrated Development Environment
UI User Interface
1.4 References
The Rational Unified Process - Artifact: Software Architecture Document

http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_sadoc.htm
Android Developers web
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_devcs.htm
Android Application Deployment
http://www.uml-diagrams.org/deployment-diagrams-examples.html
Help me find bus route
https://github.com/pulasthi7/Help-Me-Find-Bus-Routes
Bus Route Finder
https://github.com/thimal/Bus-Route-Finder
1.5 Overview
The first chapter of the document is the introduction containing the purpose, scope, references and series of
definition of terms. Chapter 2 includes the overview of the system together with the description of its basic
functionality. The overall system design is described in chapter 3. This system design includes the first
level decomposition of the system into functional components with diagrams. Starting from chapter 4, each
chapter is devoted to the description of a single component. It includes what the component is, what is the
purpose, what it does, how it is decomposed, the interfaces and the dependencies with other components.
Confidential
iRoute , 2012
Page 4 of 12

2.
Version:
1.1
Date: 27/03/2012
Architectural Representation
This section describes what software architecture is for the current system, and how it is represented. Of the
Use-Case, Logical, Process, Deployment, and Implementation Views, it enumerates the views that are
necessary, and for each view, explains what types of model elements it contains. These are views on an
underlying Unified Modeling Language (UML) model.
3.
Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on the architecture.
They are:
4.
The iRoute Bus Management System will be implemented as a client-server system. The client
portion resides on Android device (handset) and the server portion must operate on the web server.
The server should be able to handle reasonable amount of traffic.
The application does not require any authentication and does not keep any private data. Therefore
there is no issue in safety or privacy of the user and data integrity is not affected.
All performance and loading requirements, as stipulated in the Project Vision Document and the
Requirements Specification, must be taken into consideration as the architecture is being
developed.
System will be developed for Android API and will have to be within the constraints of android
platform.
System development will be in lined with the project schedule and any architecture which is being
proposed has to be implemented within the time constrains of the project.
Product should be freely available for Android users to download via Android Market and Google
Code.
Use-Case View
4.1 Use-Case Realizations
Open
Application
Enter start & End

locations
User
View Bus Route
View Route in
Google Maps
Android Application
Confidential
iRoute , 2012
Page 5 of 12

Version:
1.1
Date: 27/03/2012
When the user starts the application he/she is prompted to select the starting location and the end location
from the autocomplete list. For the given source and the destination shortest bus route will be given from
the application. Users can see the generated list of buses, bus names, bus numbers, from where to get in and
out, etc. In addition another option is provided to navigate with Google maps, which provides the user to
view the marked bus route with his current position while travelling.
Develop
Application
Modify route
database
Modify Routing
Algorithm
Developer
Release new
versions
Developer should be responsible in accessing Android APIs, other related documentation to gather
knowledge on android application development and develop the application. Developer can contribute to
release modified versions and make updates on the server/database side. Updates will be on developing the
Routing algorithm and add new locations and buses to the database.
5.
Logical View
5.1 Overview
This provides a description of the logical view of the architecture. Logical view describes the most
important classes, their organization and relationships.
5.2 Architecturally Significant Design Packages

DatabaseHandler handles insertion, deletion and modification of SQL database and making a connection
with the database. Administrator can update the database by adding bus details, location details and route
details via DatabaseHandler. When user connects to the server user inputs (start and destination locations)
are fed to the RouteSelector via DatabaseHandler. RouteSelector then takes the locationIDs of the two
locations and does a database lookup via Route Class. Relevant entries are fetched from the database and
manipulations are done based on a path selection algorithm. Selected routes are the mapped to the Google
Maps API and FavouritesManager for further processing.
Confidential
iRoute , 2012
Page 6 of 12

Version:
1.1
Date: 27/03/2012
UML Class Diagram
6.
Process View
Accept User Input
After starting the application users are provided with a simple user interface to input (type) their
start and end bus stations. The drop down lists which will output an alphabetically sorted list of
available bus stations in the database, while typing. Users can use the touch screen keyboard or the
physical keyboard of the handset if available. Users are only allowed to input a location given in
the list. If not, application will generate an error message.
Output possible bus routes
Once the inputs are taken they are processed in the PHP server and outputs trivial bus route
according to an optimal path finding algorithm which minimizes the mismatches and conflicts
among routes. The server will output the best bust route which has the minimum Manhattan
distance.
Navigate with Google Maps
Once the user selects a particular bus route he/she is provided with an option to navigate with
Google Maps. Users can preview their bus route in the map and can also view the location of their
own. This option is important in seeing the current position of the journey and planning the
transition of busses along the way.
Confidential
iRoute , 2012
Page 7 of 12

Application User
Confidential
Version:
1.1
Date: 27/03/2012
Android Client
Server Side
User starts the application and enters the start and end locations to the application.
Application then sends the user request to the server via HTTP request.
PHP server receives the request and DB Handler opens the DB and passes it to the controller.
Controller then handles the queries and outputs data to Finder which contains the logic part.
Finder then generates the best route and responds to the client again as a HTTP response.
TableView decodes the server response and displays it.
TableView passes the longitudes and latitudes of the locations to the MapRouteActivity to display
in the Google Map.
MapRouteActivity obtains the coordinates and displays it in the Map with the users current
location obtained by GPS.
User can the close the application.
iRoute , 2012
Page 8 of 12

7.
Version:
1.1
Date: 27/03/2012
Implementation View
This section describes the overall structure of the implementation model, the decomposition of the software
into layers and subsystems in the implementation model, and any architecturally significant components.
7.1 Overview
The system is mainly built as client-server architecture. User inputs the start and destinations to the android
application (client) and it connects and sends the details to the web server via HTTP/JSON. Server
responds to the client request again via HTTP/JSON response. Logic layer in the server side responds the
user request by sending it through various modules and generating the best possible bus route and again
returning it. If user wants to navigate with Google Maps, client uses the external Google Maps library. Path
overlaying part is also done using a Google library.
Logic layer, data access layer and database layer in the web server provides the functionality to handle user
requests and respond with the best route form the database.
7.2 Layers
User Interface
Client
Android API
Google Maps
HTTP/JSON
Logic Layer
Data Access Layer
Database
Web Server
MySQL
Layered Architecture
Confidential
iRoute , 2012
Page 9 of 12

Version:
1.1
Date: 27/03/2012
Client Side
User Interface
This layer provides the graphical interface to user within the application. It provides a common
interface for a user to directly interact with the system. Users can input data using the on-screen
keyboard or physical keyboard on the device.
Android API
Whole system is buit on Android API. The application must employ common modules and
libraries to achieve core functionality of an android application. In addition it uses Maps API and
other libraries to include additional functionalities.
Server Side
Logic Layer
This layer controls the whole logic behind the route selection. The logic layer contains all the
components related to selection of bus routes according to the algorithm. It gathers all the
subsystems that meet the needs of the application domain.
8.
Data Access Layer

Data access layer provides simplified access to data stored in persistent storage such as an entityrelational database.
Database
Database will be implemented in MySQL and will reside in the web server to serve client requests.
Deployment View
Android applications are composed of one or more application components (activities, services,
content providers, and broadcast receivers). Each component performs a different role in the
overall application behavior, and each one can be activated individually.
<<Android application>>
iRoute.apk
<<Mobile Device>>
<<Web Server>>
Internet
<<compiled classes>>
classes.dex
<<compiled resouces>>
resources.arsc
<<uncompiled classes>>
<<deploy>>
<<Execution Environment>>
Android
<<deployment spec >>
Confidential
iRoute , 2012
Page 10 of 12

9.
Version:
1.1
Date: 27/03/2012
Data View
Database for buses and routes will be available in the web server and basic structure will be as follows.
Database schema diagram:
Halt
id
name
latitude
longitude
alias
special
Route
id
number
start_id
end_id
description
Route_Halt
halt_id
route_id
Halt table stores unique location ids, names of the bus stations and Google map coordinates of the
particular location. id is the primary key of the table.
Route table stores unique bus ids, route numbers, bus starting station id and destination id Description
includes bus route number and bus name. Primary key is id.
Route_Halt table contains primary keys of both tables Halt and Route. Halt and Route has one-to-many
relationship.
10.
Size and Performance

Response Time
The output should be generated within a maximum of 10 seconds depending on the internet
connection speed and handset performance.
Transactions per second
The database can handle 20 transactions per second
Capacity
System can serve 20 users simultaneously.
Resource Utilization
Confidential
The application utilizes minimum amount of CPU and memory of the device. Separate processes
and android services are used in design to reduce processor consumption.
iRoute , 2012
Page 11 of 12

11.
Quality
11.1
Usability
Version:
1.1
Date: 27/03/2012
Simple, Graphical User interface
The user interface is designed to be simple to use with graphical elements. Texts are simple, clear
and readable. Colors are used according to a theme which makes it more usable.
Minimal surprise
Interface is designed considering the user experience of using android application with providing
minimal surprise.
Ease of use
Full screen is used with right size buttons to suit big fingers. Easy navigation among windows and
menus.
User Guidance
Users are provided with a small help guide and tool tips.
11.2 Reliability
Availability
The server should be available 24/7/365 standby to serve user requests except the time of
maintenance or upgrade. Down time shall not exceed 5% of the up time .
Accuracy
The output should be accurate to the best possible percentage and should avoid conflicting and
misleading outputs when the inputs are confusing. (Minimum defect rate). i.e critical bugs have to
be eliminated.
Mean time to recover
In a case of failure, system should be able to recover within 1 day or so. (depending on the type of
damage) i.e database failure
11.3 Extensibility
Confidential
Upgrades to the client portion of iRoute bus management system shall be downloadable from the
Android market or from the Google code. Updates should be available to the application when the
client connects to the internet.
Source code is available under General public license for anyone to extend and further modify the
system with additional functionality.
iRoute , 2012
Page 12 of 12

Software Architecture Document

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture Document

Uploaded by

Copyright:

Available Formats

iRoute

Bus Route Management System

Bus Route Management System