ADDIS ABABA INSTITUTE OF

TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND
SCIENTIFIC COMPUTING
DEPARTMENT OF SOFTWARE ENGINEERING

Navigation System for AAiT

Team Members
Blen Aklilu – ATR/1561/05
Imran Abdulkadir – ATR/4616/05
Samson Tekleab – ATR/5296/05
Zeyneb Abdulkader – ATR/4661/05

Advisor: Mr. Fistum Alemu

March ,2017
 Addis Ababa Institute of Technology
Information Technology and Scientific Computing

<Navigation System for AAiT >

This Project documentation submitted in partial fulfillment of the requirements for the Degree of
Bachelor of Science in Software Engineering.

Project Advised by: Mr. Fistum Alemu

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

March, 2017

i
 Declaration of Originality

We declare that this project is our original work and has not been presented for a degree in any
other university.

Name Signature Date

1. Blen Aklilu __________________ __________________

2. Imran Abdulkadir __________________ __________________

3. Samson Tekleab __________________ __________________

4. Zeyneb Abdulkader __________________ __________________

This project documentation has been submitted for examination with my approval as university
advisor:

Advisor Name Mr. Fistum Alemu

March, 2017

ii
 ACKNOWLEDGEMENT

Firstly, we would like to thank our department Center for Information Technology and Scientific
Computing for providing the opportunity and infrastructure to do this real project and creating
this chance to demonstrate our skill we gained on our five year stay in the campus.

Secondly, we would like to thank the project coordinating committee for giving us orientation
about the entire project procedure, providing a project guideline and templets for the
documentations.

Thirdly, we would also like to thank our advisor, Mr. Fitsum Alemu for his continuous help and
support throughout the project.

Last but not list we would like to expand our deepest gratitude for all individuals who have
made significant contribution to the success of this project

iii
 ABSTRACT

Landmark-based navigation is the most natural concept for humans to navigate themselves
through their environment, especially if the environment is new. It is therefore desirable to
incorporate this concept into mobile systems since the availability of maps in digital form and
since GPS is supported by the current mobile technology. This project is specifically intended for
Addis Ababa Institute of Technology compound that helps newly joining apprentices, guests and
clients to get their way around.

The Navigation System is user friendly with an interactive map which helps all kind of users.
The system is enriched with course mapper, path tracker and continuous update of position by
GPS.

iv
 Table of Contents
List of Figures..............................................................................................................................viii

List of Tables..................................................................................................................................ix

ACRONYMS..................................................................................................................................xi

Chapter 1: INTRODUCTION.........................................................................................................1

1.1 Background............................................................................................................................1

1.2 The Existing System..............................................................................................................2

1.3 Statement of the Problem.......................................................................................................2

1.4 Objective of the Project.........................................................................................................4

1.4.1 General Objective......................................................................................................4

1.4.2 Specific Objective......................................................................................................4

1.5 Proposed System....................................................................................................................4

1.6 Feasibility Study....................................................................................................................5

1.6.1 Economic Feasibility......................................................................................................5

1.6.2 Technical Feasibility.......................................................................................................6

1.6.3 Schedule Feasibility........................................................................................................6

1.7 Scope......................................................................................................................................7

1.8 Methodology..........................................................................................................................8

1.9 Project Management plan....................................................................................................10

1.9.1. Time Management plan...............................................................................................10

1.9.1. Quality Management Plan...........................................................................................12

1.9.2. Communication Management Plan.............................................................................13

Chapter 2: Requirement Analysis..................................................................................................14

2.1 Introduction..........................................................................................................................14

2.2 Scope....................................................................................................................................14

v
 2.3 General Description.............................................................................................................14

2.4 Product Perspective.............................................................................................................14

2.5 Product Functions................................................................................................................15

2.6 User Characteristics.............................................................................................................15

2.7 General Constraints.............................................................................................................16

2.8 Assumptions and Dependencies..........................................................................................16

2.9 External Interface Requirements.........................................................................................17

2.9.1 User Interfaces..............................................................................................................17

2.9.2 Hardware Interfaces......................................................................................................20

2.9.3 Software Interfaces.......................................................................................................20

2.9.4 Communications Interfaces..........................................................................................20

2.10 Functional Requirements...................................................................................................20

3.11 Use Cases...........................................................................................................................25

3.3.1. Use Case Diagram......................................................................................................25

3.3.2. Use cases......................................................................................................................26

2.12 Non-Functional Requirements...........................................................................................34

2.12.1 Error handling.............................................................................................................34

2.12.2 Availability.................................................................................................................34

2.12.3 Performance................................................................................................................34

2.12.4 Maintainability............................................................................................................34

2.13 Inverse Requirements........................................................................................................34

2.14 Design Constraints.............................................................................................................34

2.15 Other Requirements...........................................................................................................35

2.16 Change Management Process............................................................................................35

Chapter 3: SYSTEM DESIGN......................................................................................................36

vi
 3.1 General Overview................................................................................................................36

3.2 Development Methods & Contingencies.............................................................................37

3.3 System Architecture.............................................................................................................38

3.3.1 Subsystem decomposition............................................................................................38

3.3.2 Hardware/software mapping.........................................................................................40

4.4 Object Model.......................................................................................................................41

4.4.1 Class Diagram...............................................................................................................41

4.4.2 Sequence Diagram........................................................................................................42

...................................................................................................................................................45

4.5 Detailed Design...................................................................................................................47

BIBLIOGRAPHY..........................................................................................................................57

APPENDIX....................................................................................................................................58

List of Figures

vii
Figure 1 - Network Diagram..........................................................................................................11
Figure 2 System Flow Diagram.....................................................................................................16
Figure 3 User Interface for Map view...........................................................................................17
Figure 4 User Interface for Search.................................................................................................18
Figure 5 User Interface for Get Description..................................................................................18
Figure 6- User Interface for Map Information...............................................................................19
Figure 7- Use Case Diagram..........................................................................................................25
Figure 8 - Context diagram............................................................................................................37
Figure 9- Layer 1...........................................................................................................................38
Figure 10 - Layer 2........................................................................................................................39
Figure 11 - Layer 3........................................................................................................................39
Figure 12 - Deployment Diagram..................................................................................................40
Figure 13 - Class diagram..............................................................................................................41
Figure 14 - Get Map Information..................................................................................................42
Figure 15 - Locate User.................................................................................................................43
Figure 16 - Recognize Voice.........................................................................................................43
Figure 17 - Respond with voice.....................................................................................................44
Figure 18 – Search.........................................................................................................................45
Figure 19 - Set Preferences............................................................................................................45
Figure 20 - Set location..................................................................................................................45
Figure 21 - Show Important Landmarks........................................................................................46
Figure 22 - Track User...................................................................................................................47

viii
 List of Tables

Table 1- Price List...........................................................................................................................6

Table 2- Activity Table..................................................................................................................10
Table 3 - Communication Plan......................................................................................................13
Table 4 - Functional Requirement 01............................................................................................20
Table 5- Functional Requirement 02.............................................................................................21
Table 6 - Functional Requirement 03............................................................................................21
Table 7 - Functional Requirement 04............................................................................................21
Table 8 - Functional Requirement 05............................................................................................22
Table 9 - Functional Requirement 06............................................................................................22
Table 10 - Functional Requirement 07..........................................................................................23
Table 11 -Functional Requirement 08...........................................................................................23
Table 12 - Functional Requirement 09..........................................................................................24
Table 13 - Functional Requirement 10..........................................................................................24
Table 14 - Register.........................................................................................................................26
Table 15 - UC - 02 Render Map....................................................................................................27
Table 16 - UC- 03 Get current location.........................................................................................27
Table 17- UC-04 Vocal Search......................................................................................................28
Table 18- UC-05 Text Search........................................................................................................29
Table 19- UC-06 Important Landmarks........................................................................................29
Table 20- UC-07 Track User.........................................................................................................30
Table 21 - UC - 08 Set Location....................................................................................................31
Table 22 - UC – 09 Locate User....................................................................................................32
Table 23 – UC – 10 Set preference................................................................................................33
Table 24 - Map Class.....................................................................................................................47
Table 25 - Attributes description for Map Class...........................................................................48
Table 26 Operation Description for Map class..............................................................................49

ix
Table 27- User Class......................................................................................................................49
Table 28 - Attribute Description for User Class............................................................................50
Table 29 - Operation Description for User Class..........................................................................50
Table 30 - Route Class...................................................................................................................51
Table 31 - Attributes description for Route class..........................................................................51
Table 32 - Operation description for Route class..........................................................................51
Table 33 - Location class...............................................................................................................52
Table 34 - Attributes description for Location class.....................................................................52
Table 35 - Operation description for Location class.....................................................................52
Table 36 - Map Information class..................................................................................................52
Table 37 - Attributes description for Map Information class........................................................53
Table 38 - Operation description for Map Information class........................................................53
Table 39 - Speech Recognizer class..............................................................................................53
Table 40 - Attributes description for Speech Recognizer class.....................................................54
Table 41 - Operation description for Speech Recognizer class.....................................................54
Table 42 - Speech Responder class...............................................................................................55
Table 43 - Operation description for Speech Responder class......................................................55
Table 44 - Navigation Class..........................................................................................................55
Table 45 - Attributes description for Navigation class..................................................................56
Table 46 - Operation description for Navigation class..................................................................56

x
 ACRONYMS

AAiT: Addis Ababa Institute of Technology

ArcGIS: Aeronautical Reconnaissance Coverage Geographic Information System
GIS: Geographic Information System
GPS: Global Positioning System
LS: Last Start
LF: Last Finish
ES: Earliest Start
EF: Earliest Finish
EDWM: Evolutionary Development Waterfall Model
JS: JavaScript

xi
 Chapter 1: INTRODUCTION

1.1 Background
Software Development is becoming one of the key trending problem solving process all over the
world. It has branched into almost all our daily routines starting from the moment we wake up in
the morning to the moment we go to bed. We probably have used an application on our phone or
personal computer to get most of our errands done, whether it's for personal matters like where to
eat or which path to take during traffic jams and so on.

Of the all the paradigms of software development, mobile application has wide uses for its vast
functioning area like calling, messaging, browsing, chatting, social network communication,
audio, video, game etc. Mobile application is easy, user friendly, inexpensive, download able and
can run in most of the mobile phone including inexpensive and entry level phone. The usefulness
of mobile devices has increased greatly in recent years allowing users to perform navigation
tasks in a mobile context. The use of devices such as smart phones and tablets which come along
with the excessive use of mobile applications is becoming more and more common, especially in
the university domain majority of these mobile devices have built-in techniques to determine
geographical position. In the last decade, navigation devices have used digital maps to locate the
position of the user and assist in providing navigational directions. Recently, maps have become
more than just visualization tool in navigation systems; they are now an aiding tool for
enhancing the reliability of the obtained navigation solutions.

A navigation system is an electronic map combined with route instructions, usually displayed on
a dashboard video screen. Global Positioning System (GPS) is one of the commonest navigation
systems in the world. Our information system uses GPS which is usually used by civilians as a
navigation system, for this system to function well there needs to be a computer system on the
ground that triangulates its own position by getting bearings from at least three satellites. The
result is provided in a form of geographic positions – longitude and latitude - to, for most
receivers, within an accuracy of 10-100 meters. Software applications can then use those
coordinates to provide driving or walking instructions [1]. GPS accuracies are generally of two
kinds: static mode, accuracy of positions over known control points and dynamic mode, accuracy
of a traveled route in relation to the actual route [2].

1
 GIS is a computer system for capturing, storing, checking, and displaying data related to
positions on Earth’s surface. GIS can show many kinds of data on one map. This enables people
to more easily see, analyze, and understand patterns and relationships from the GPS data. With
GIS technology, people can compare the locations of different things in order to discover how
they relate to each other [3]. Both systems have their own unique capabilities, but when paired
together, they create an invaluable resource for a variety of disciplines, including urban planning,
disaster management, and agriculture [4].

Addis Ababa Institute of Technology, which is the part of Software Engineering Department, is
one of the biggest Institute in Ethiopia with an average of 10,000 graduates per year. AAiT
accepts over 15,000 students with prestigious scores from all over Ethiopia every year [5]. As we
all know being a fresh-student in the 5kilo campus is not an easy walk, knowing where classes
are, where the library is or even where the male and female bathrooms are one of the main
challenges. Noticing these problems that these students face every year we as Software
Engineering Students of AAiT wanted to be the first to offer the campus an Information System
that provides all the needed Information for any campus student or guest that needs navigation
throughout the campus.

1.2 The Existing System

There was no prior software system for getting information about Addis Ababa Institute of
Technology as such. Unfortunately, at the AAiT campus it was the traditional way of getting
information that is used to be practiced and still is practiced i.e. someone may ask for a
destination, the reply sometimes is a mockery or false information that leads to inappropriate
destination. People asking for a Registrar office may be directed to a toilet or the reverse. In
result time and energy is wasted wondering here and there trying to find the exact location that
they are looking for.

1.3 Statement of the Problem

Addis Ababa Institute of Technology is one of the major contributors in Ethiopia’s information
technology development. AAiT is the first-hand user of full automation on different aspects of its
operation but currently operating under non-structured manual compound guidance.

2
The AAiT campus is composed of a lot of departments with their respective assigned classes,
offices, common library, cafeteria and so on. With little physical indications, such as signs or
building block numbers, navigating the compound to get a certain location is a huge hustle.

The campus faces daily different customers starting from its main user’s, campus students to its
one-time visitor. Being part of the AAiT campus for five years, it’s been observed repeatedly
that newly joining apprentices, guests and clients face difficulty in identifying their objective
destination. Per the current process one uses by passers of the compound to ask for a specific
information which is time consuming for both parties and at the same time could easily be
misguided depending on the nature of the by passer.

The second problem the compound faces is in relation to disabled people. Visually impaired and
physically disabled people are the most affected in regards to poor directional system as well as
inapt infrastructure.

AAiT campus facing all the above stated problems would greatly benefit if one develops an
application where a certain user would get all the necessary information about the needed
location from their hand-held device. Likely our society is becoming more and more users of
different gadgets, smartphones, tablets etc. These devices combined with the right software can
provide new users with location-based information on buildings and facilities in the university
campus. In this proposal, an android application is presented to assist students, guests,
handicapped people and others for easier, timely and effective navigation.

3
1.4 Objective of the Project
1.4.1 General Objective

The objective of this project is to develop a navigation platform for Addis Ababa Institute of
Technology compound.

1.4.2 Specific Objective

In order to achieve the general objective, the following tasks will be done

 To gather data and information about the project

 Identify the requirements that must involve in the system
 Analyze the requirements and design the system
 Design an interactive map using QGIS
 Adding a Voice input capabilities and Voice Response for visually impaired
people

1.5 Proposed System

The system offers an android application of a digital map of the compound that will be available
for download as a person approaches the compound. It will have the location of all the important
landmarks of the compound pre-stored so that the user can search for where they want to go and
find out where it is. Furthermore, there will be a course mapper and tracker which will show the
user a path towards where they want to go and continually track and update their position by
using GPS for outdoor navigation but once the user loses GPS signal the application will provide
an indoor navigation by using Indoor Atlas SDK. Lastly, the application will be able to locate
academic staff that are willing to be located.

To begin with, the system will first be integrated with the universities network system to be
downloaded by a user at first connection. The design of this application will be very simple with
understandable user interface that will be easy to use. A user will be able to view a topographic
map of the campus with location areas visible for those who have a rough idea as to where they
want to go. In addition to that, there will be a search bar available at the top of the page that
he/she can use to search for a specific location they want to go to.

4
When a user searches for a location, a location pin will drop on the place where they want to go
and a path way will be drawn on the map. The user can follow this line, which will be
continually be updated with the change of position of the user. A user can also search for
academic staff, if the academic staff have their visibility preferences on.

Finally, the system will have other functionalities that can be accessed from the menu of the
application. These options include a list and location of the major offices of campus staff,
important locations such as where the cafeteria or security can be found and an offering of a
small piece of literature about the campus.

1.6 Feasibility Study

1.6.1 Economic Feasibility
1.6.1.1 Developmental cost
The Developmental cost for the proposed system is negligible since that we are all student
developers and have all the resources we need like good working computers; therefore, we can
say the cost while developing this navigation system is our time.

1.6.1.2 Operational Cost

We plan to have specialized access points that are easily accessible and we plan to serve our
application using them. So, the cost of the access points must be factored in. We can also
repurpose existing infrastructure to serve our application. Considering that operation costs are
nonexistent.

The other factor that must be considered is in case of indoor navigation, Atlas indoor requires
pricing per month as the number of users increase to connect to the system. The pricing is listed
in tabular form below.

5
Table 1- Price List

Users per Month Cost per Month

101 – 1,000 $100
1,001 – 5,000 $300
5,001 – 10,000 $500
10,001 – 50,000 $1,700
50,001 – 100,000 $3,000
100,001 – 500,000 $11,000
500,001- 1000,000 $20,000

1.6.2 Technical Feasibility

The main problem will be user (students) that don’t speak English fluently. They might be
threatened by the platform and never use it. We plan to make the application support English as
well as Amharic text and pre-defined Amharic audio in regards to communication with the user.
The other technical limitation is, in case of indoor navigation our application needs internet
connection.

1.6.3 Schedule Feasibility

The overall schedule of the project is stated in the time management plan. In an ideal condition
and environment, we are positive we will deliver in the specified time. Some concepts and tools
used in our project maybe new to us and they might have some effect on project delivery time.

6
1.7 Scope
The Project will concern itself in the confines of the AAiT campus and will have modular parts
for it to be applicable at other campuses as well as other large institutions. So, it can be built out
to serve others.

The System will have the following services

 An interactive map of the AAiT campus

 That takes dynamic queries about the campus and will compute to provide
purposeful information
 Voice Recognition and Voice Response for Visually Impaired Persons
 It provides relevant and important geospatial data
 It also supports GPS based outdoor navigation
 It has searching capabilities to query for specific locations
 It calculates distance to destinations
 Locate academic staff members

7
1.8 Methodology
1.8.1. Data Collection Methods

The data collection mechanisms that we plan to deploy are

 Conducting interviews with campus staff

 Handing out questionnaires to students to know what kind of information they
need and how to clearly present it to students for it to be the most effective.
 We will also be adding our personal experiences and observations since we are a
part of the student body.
 We also plan to collect real-time location data using GPS devices for the actual
map used in our application.

We will try to filter and perform a rudimentary data analysis on our data collection. With data
gathered from stakeholders we plant to have a clear and well defined requirement.

1.8.2. Description of Data

The Data that we will acquire is that of the most important and essential information that a
student will need during his study at AAiT.

We will have locations of important landmarks inside the campus like

 The Library
 The Registrar
 The Cost-Sharing Office
 Classrooms
 Department Staff Offices

8
We will also have full information on major procedures that a student is involved in such as

 How to obtain a booklet to borrow books from the library

 Who to contact and what to do in the case of loss of student ID Card
 Where to go if they need to add or drop classes
 How to locate their lecturers
 How to register

1.8.3. Implementation

For our development process, we plan to use Evolutionary Development Waterfall Model
(EDWM). This model is an evolution of the traditional Waterfall Model. It adds feedback
mechanisms and iterative approaches to software development, that are missing from the
traditional Waterfall Model [6]. Using this model, we will sequentially develop our application.
We may have some uncovered angles in our requirement and this model will help us make up
solutions during the development process. The other strong point of this model is that it
minimizes the risk of our project not fulfilling its objective since we will be developing
incrementally.

The main staples of implementation will be

• Native android framework, we looked at Mobile JS frameworks such as Phone

Gap and Ionic but they have shortcomings in their Graphics Implementations
[7]
• We will also make use of tools like QGIS, an open source alternative to
ArcGIS that has essential features to design our interactive map
• We will use smartphone built in GPS signal for outdoor navigation.
• We will use Indoor Atlas Android SDK for indoor navigation, which provides
an API to create location- aware application for navigation inside building by
using device hardware sensors like compass, gyroscope and accelerometer.
• We will use Pocket Sphinx for speech recognition tool set.

9
We plan to have unit test major and essential functions in our applications. We also plan to test it
with different users and get their feedback to make adjustments before we release our final
application.

1.9 Project Management plan

1.9.1. Time Management plan
An Activity Network Diagram is a diagram of project activities that shows the sequential
relationships of activities using arrows and nodes. An activity network diagram tool is used
extensively in project management and is necessary for the identification of a project’s critical
path (which is used to determine the expected completion time of the project) [6].

We created this chart – Activity Network Diagram – where the nodes (the boxes) represent the
nine major steps involved in building this project. Arrows that connect the nodes show the flow
of the process.

Table 2- Activity Table

Activity Time(days)

A Brainstorming Ideas 2

B Title Approval 6

C Proposal Development and Presentation 13

D Requirement 30

E Data Collection 16

F Design 30

G Implementation 84

H Testing 30

I Finalizing project 30

10
 Figure 1 - Network Diagram

Some of the process steps (nodes A and E) run in series, while other process steps (nodes D, E,
F, G and H) run in parallel. Notice that Step B cannot happen until step A has been completed.
Likewise, step C cannot happen until step B has completed. Step H cannot happen until steps D,
E, and F have completed – and ALL need to be completed before Step H. So, nodes A and E are
running in series. Nodes D, E, F, G and H run in parallel. This is important to know because
those steps that are running in parallel most likely will have different expected completion times

The legends that are presented on top of each task present four quadrants: The upper quadrant
present the earliest start (ES), earliest finish(EF). For Example, the earliest start of task C starts
on day 8 which is the earliest possible time task B ends. The lower quadrants present the latest
possible time a task could start and finish (LS, LF).

The number that is on top of each legend is called Total slack. The total slack can be calculated
late finish and subtract early finish.

11
The Critical Path means is that this tasks must be finished on time as regarded as their estimated
time duration for overall project to remain on schedule. As you can see this project has 0 slack
for each task which means every task will be delivered on time.

1.9.1. Quality Management Plan

Literature on navigation system designing are to be read and similar Navigation systems will be
assessed and adapted localizing them to the need of AAIT campus navigation. The formulated
AAIT campus navigation system is to be discussed with friends and advisers for further
development. The AAIT Navigation system will be tested within the campus before it is released
for end users.

The project team will be handling Quality Assurance related issues and tasks in a coordinated
manner. There will be constant dialogue, sharing of information and several ways of
communicating (by phone, MeisterTask, Slack and direct meetings) to keep the quality in what
we do at a satisfying level. By establishing a mutual agreement on roles, routines and
responsibilities we will reach our Quality Assurance goals. The main goal is to develop a system
based on the specifications from the customer.

All the members of the project have different backgrounds, skills and competence. The best way
to bring quality to both product and process in the project will be to establish a good working
environment. This will be important since the process of developing software systems often is
carried out by the means of creativity, skills and experience.

We have agreed upon certain issues that will give us a quality management:

 The use of a structured repository for documents, objects and code

 All project members monitor their colleagues’ work with both the final system
and the learning process in mind.
 Frequent status reporting
 The use of coding conventions to keep the source code readable for both
internal and external persons and create class description headers for easy
access and overview.

12
 1.9.2. Communication Management Plan

Table 3 - Communication Plan

Type of Method / Tool Frequency Information Participants /

Communication /Schedule Responsible
Internal Communication:
Project Meetings Direct meetings, Four days a Project status, problems,
Slack, week risks, changed Project
MeisterTask requirements Members
Sharing of project Slack, When All project documentation Project Team
data MeisterTask, available and reports Members
Bitbucket

Milestone Direct Meetings Before Project status Project

Meetings milestones Members and
Advisor
Final Project Direct Meetings Before final Wrap-up Project Team
Meeting project Experiences and Advisor
External Communication and Reporting:
Project Report Hard and Soft Monthly Project status, progress, Project
Copy release Members and
documentation, project
Presentation committee
and demo

13
 Chapter 2: Requirement Analysis

2.1 Introduction
requirements analysis encompasses those tasks that go into determining the needs or conditions
to meet for a new or altered product or project, taking account of the possibly conflicting
requirements of the various stakeholders, analyzing, documenting, validating and managing
software or system requirements [9]

2.2 Scope
The Project Navigation System for AAiT will concern itself in the confines of the AAiT campus
and will have modular parts for it to be applicable at other campuses as well as other large
institutions. So, it can be built out to serve others.

The System will have the following services

 An interactive map of the AAiT campus

 That takes dynamic queries about the campus and will compute to provide
purposeful information
 Voice Recognition and Voice Response for Visually Impaired Persons
 It provides relevant and important geospatial data
 It also supports GPS based outdoor navigation
 It also supports indoor navigation by using Indoor Atlas
 It has searching capabilities to query for specific locations
 It calculates distance to destinations
 Locate academic staff members

2.3 General Description

2.4 Product Perspective
Mobile navigation System has been implemented in western countries vastly and are being in use
since the late 1999’s [1].

14
Navigation system throughout the technological world have been mainly dominated by general
directives to major cities and town.

There are applications like CampusNav, an android application providing navigation for eight
universities located in the United States. The system was designed to navigate to any building,
filed, dining hall and many more location at the school [2]. This application is only providing
navigation for those eight universities and it is fairly unresponsive and unstable, thus making
ineffective. We aim to make our application fairly stable and efficient compared to its peers.

The navigation system for AAiT here at hand specifies the general idea and focuses on detailed
information representation of the AAiT campus, easing the process in terms of time efficiency
and adequacy when it comes to information distribution.

2.5 Product Functions

The system will provide a map that will have location. It will have the location of all the
important landmarks of the compound pre-stored so that the user can search for where they want
to go and find out its location. Furthermore, there will be a course mapper and tracker which will
show the user a path towards where the user wants to go and continually track and update their
position by using GPS for outdoor navigation but once the user loses GPS signal the application
will provide an indoor navigation by using Indoor Atlas SDK. Furthermore, the system offers
voice recognition capability and as well as voice response for visually impaired people.

2.6 User Characteristics

Navigation system for AAiT can incorporate anyone within the premises of the campus with the
access of our servers, in order to download our application, with the help of the several WLAN
routers located in the vicinity of AAiT.

Users with basic linguistic ability of either Amharic or English to navigate through the interfaces
placed within the application and that of a considerable know-how on to work in tandem with
basic website characters and the internet in general.

15
Figure 2 System Flow Diagram

2.7 General Constraints

Internet connection is a constraint for the application when the user is using indoor navigation.
Since the application fetches data from the database over the Internet, it is crucial that there is an
Internet connection for this specific feature to function.

Another constraint that can be mentioned is that Amharic accents are not recognized in android
systems withholding us from being able to assist those using the voice navigation of our system.
We plan to build and train our own model.

2.8 Assumptions and Dependencies

One assumption about the product is that, it will always be used on mobile phones that have a
performance level above or equal to our emulator or testing device

16
Mic and GPS capabilities of phones (hardware wise) using our system are assumed to be within
the same range of performance as our testing devices. Newer devices are assumed to have better
results because they use the Wi-Fi and Bluetooth interfaces in addition to the GPS. It is also
assumed the user will have GPS turned on while using the application

2.9 External Interface Requirements

2.9.1 User Interfaces
As the user approaches the compound the user will be notified to download the system from the
server. Once the user installs the application, the first layout would be a search bar and the AAiT
campus map underneath with the user current location. The user can search for any location they
desire using text or voice, once the path is drawn on the map the application will guide the user
with a map tracker to the destination.

Figure 3 User Interface for Map view

17
Figure 4 User Interface for Search

Figure 5 User Interface for Get Description

18
Figure 6- User Interface for Map Information

19
 2.9.2 Hardware Interfaces
There is no specific hardware requirement

2.9.3 Software Interfaces

The navigation system communicates with the GPS application in order to get geographical
information about where the user is located.

2.9.4 Communications Interfaces

The Navigation System for AAiT will require to connect with LAN network to communicate
with the database on local servers. This uses a standard HTTP protocol to access the servers.

2.10 Functional Requirements

Table 4 - Functional Requirement 01

ID FR:01

Name Register

Summary System registers user

Description User shall register to use the application

Reference UC-01: Register

20
 Table 5- Functional Requirement 02

ID FR:02

Name Render Map

Summary Provides a digital map of the compound

Description This view shall display map of the AAiT

compound

Reference UC-02: Render Map

Table 6 - Functional Requirement 03

ID FR:03

Name Show Current Location

Summary Current Location is Identified by GPS

Description This shows the current location of the user on

the map at the specified time

Reference UC-03: Show Current Location

Table 7 - Functional Requirement 04

ID FR:04

Name Text Search

Summary Provides a Navigation search through text

Description The user gives the input about the place s/he

21
 has to reach using text input

Reference UC-04: Text Search

Table 8 - Functional Requirement 05

ID FR:05

Name Vocal Search

Summary A user should be able to conduct a search by

voice input

Description The user gives the input about the place s/he
has to reach using voice input

Reference UC-05: Vocal Search

Table 9 - Functional Requirement 06

ID FR:06

Name Show Important Landmarks

Summary Important landmarks of AAiT

Description Provides a list view of important landmarks

of AAiT compound

Reference UC-06: Show Important Landmarks

22
 Table 10 - Functional Requirement 07

ID FR:07

Name Track User

Summary User can navigate and detailed information

shall be provided at the destination

Description A path will be drawn to the destination and

the user can be guided with map tracker
through voice and detailed information shall
be provided about the destination

Reference UC-07: Track User

Table 11 -Functional Requirement 08

ID FR:08

Name Set Location

Summary System sets(update) users location

Description System continuously updates users location

on the local server

Reference UC-08: Set Location

23
 Table 12 - Functional Requirement 09

ID FR:09

Name Locate User

Summary User can locate another user

Description User can search and locate another user that

has set their location

Reference UC-09: Locate User

Table 13 - Functional Requirement 10

ID FR:10

Name Set Preference

Summary User sets their preference

Description User can toggle their visibility

Reference UC-10: Set Preference

24
3.11 Use Cases
3.3.1. Use Case Diagram

Figure 7- Use Case Diagram

25
3.3.2. Use cases

Table 14 – Register

Use case name: UC-01: Register

Goal: To Register a user

Primary Actors: Mobile User

Preconditions: User shouldn’t already be register, User should connect to a local area network

Post-conditions: User will be Registered

Main Success Scenario

S 1. System will provide a Registration form

S 2. User will fill out form
S 3. System will validate input
S 4. System will direct the user to render map page

Extensions

- If user input is invalid

S 1. system will show error and prompt the user to fill the form again
- If user is already registered
S 1. System informs user is already registered. So, no need of registering rather update the
information if necessary
- User name is in use
S 1. System finds that the user name is already in use by another user
S 2. System informs user to try another user name
S 3. User enters another user name
S 4. Use case resumes at S 3 of main success scenario

26
Table 15 - UC - 02 Render Map

Use case name: UC-02: Render Map

Goal: To show the map of the compound

Primary Actors: Mobile User

Preconditions: - The user should approach the AAiT campus and install the application

Post-conditions: The application will display the map

Main Success Scenario

S 1. The system will render the map

S 2. The user will view the map

Extensions

- If the GPS is turned off,

S 1. system will show a prompt to turn on GPS

Table 16 - UC- 03 Get current location

Use case name: UC-03: Get Current Location

Goal: User can see current location

Primary Actors: Mobile User

Preconditions: The map should be loaded, GPS must be on

Post-conditions: The user will know where they are in comparison to the compound

Main Success Scenario

S 1. The system will load the map

S 2. The user will press the Current location button
S 3. The system will show the current location

Extensions

- If the GPS is turned off

S 1. system will show error

27
Table 17- UC-04 Vocal Search

Use case name: UC-04: Vocal Search

Goal: User can search the desired location by Voice capability

Primary Actors: Visually Impaired User

Secondary Actors: Mobile User

Preconditions: The mic must be running

Post-conditions: The user will get a list of search results

Main Success Scenario

S 1. The user will input voice recording

S 2. The system will record the voice message
S 3. The system will match the recorded voice
S 4. The system will return detected words along with certainty ratio
S 5. The system will search the request
S 6. The system will return a list view of search requests
S 7. The user will choose a destination from the returned list view

Extensions

- If there is no search result

S 1. The system will prompt again
- If voice is not captured
S1. The system will show “Voice not captured” message

28
Table 18- UC-05 Text Search

Use case name: UC-05: Text Search

Goal: User can search the desired location by text input

Primary Actors: Mobile User

Preconditions: The application must be running

Post-conditions: The user will get a list of search results

Main Success Scenario

S 1. The system will display search bar

S 2. The user will fill with text input
S 3. The system will search the request
S 4. The system search result will be given through a list view
S 5. The user will choose a location from the returned list view

Extensions

- If there is no search result

S 1. system will prompt again

Table 19- UC-06 Important Landmarks

Use case name: UC-06: Show Important Landmarks

Goal: The user can get locations that are important

Primary Actors: The user can get locations that are important

Preconditions: The application must be running

Post-conditions: The user will get locations without the need for searching

Main Success Scenario

S 1. The system will display from important location list view

S 2. The user can choose from these lists or can search
S 3. The system will show the selected location

Extensions

29
Table 20- UC-07 Track User

Use case name: UC-07: Track User

Goal: A path will be drawn on the map along with description of the destination

Primary Actors: Mobile User

Preconditions: Users need to choose a destination

Post-conditions: User will get the route and detail of their end point

Main Success Scenario

S 1. The system will provide a route and a description about the destination
S 2. The system will draw the route on the map view
S 3. The system will provide direction via voice output

Extensions

- If the GPS is turned off

S 1. system will show error

30
Table 21 - UC - 08 Set Location

Use case name: UC-08 Set Location

Goal: To set the location of the user

Primary Actors: Mobile User

Preconditions: User should connect to Local Area Network, GPS must be on and User
Preference must be visible

Post-conditions: User location is known

Main Success Scenario

S 1. System will update user location

S 2. System will send updated location to server

Extensions

- If GPS is turned off

S 1. System will prompt the user to turn the GPS on
- If Server is down
S1. System will show “Server is down” message
- If user is not connected to LAN
S1. System will prompt user to connect
- If user hasn’t chosen visible preference
S1. System will prompt user to turn visibility on

31
Table 22 - UC – 09 Locate User

Use case name: UC-09 Locate User

Goal: To set the location of the user

Primary Actors: Mobile User

Preconditions: User should connect to Local Area Network, GPS must be on and User
Preference must be visible

Post-conditions: User location is known

Main Success Scenario

S 1. System will update user location

S 2. System will send updated location to server

Extensions

- If GPS is turned off

S 1. System will prompt the user to turn the GPS on
- If Server is down
S1. System will show “Server is down” message
- If user is not connected to LAN
S1. System will prompt user to connect
- If user hasn’t chosen visible preference
S1. System will prompt user to turn visibility on

32
Table 23 – UC – 10 Set preference

Use case name: UC-10 Set preference

Goal: To set the location of the user

Primary Actors: Mobile User

Preconditions: User should connect to Local Area Network, GPS must be on and User
Preference must be visible

Post-conditions: User location is known

Main Success Scenario

S 1. System will update user location

S 2. System will send updated location to server

Extensions

- If GPS is turned off

S 1. System will prompt the user to turn the GPS on
- If Server is down
S1. System will show “Server is down” message
- If user is not connected to LAN
S1. System will prompt user to connect
- If user hasn’t chosen visible preference
S1. System will prompt user to turn visibility on

33
2.12 Non-Functional Requirements
2.12.1 Error handling
The system is expected to handle errors encountered during run time. If an error occurs, the
system will try to identify the error and notify the user so that he/she can take an appropriate
correction.

2.12.2 Availability
The server should be available 24 by 7 uptime to serve user requests. It will be available any
time with internet connection

2.12.3 Performance
The new system accomplishes tasks within good response time within 100 to 200 milliseconds
and produce output within good throughput time. The application will show a splash screen
while it loads the map view and other slow components or indicate that loading is in progress
and fill the information asynchronously.

2.12.4 Maintainability
The application should be easy to extend. The code should be written in a way that it favors
implementation of new functions.

In order to make maintainability easy for new coders in the future commenting will be included
for the code.

Adding new map update is up to the developer.

2.13 Inverse Requirements

The Navigation System for AAiT is not a full-fledged navigation application like Google Maps
and OpenStreetMap. It only provides navigation system within the AAiT campus. Any landmark
or place outside the campus vicinity.

The information provided by the application about certain landmarks’ functions is not absolute.
Many business processes and their associated places are subject to change without regards of the
application, so the information will not be very specific and up to date.

The Voice Recognition is not a dynamic in the sense that it will not support various
commands(inquiries) than more dynamic applications such as google assistant and Siri. The

34
2.14 Design Constraints
Since the application is designated for mobile handsets, limited screen size and resolution will be
a major consideration. Creating a user interface which is both effective and easily navigable will
pose a difficult challenge. Other constrains such as limited memory and processing power are
also worth considering.

2.15 Other Requirements

It will have a helper guide to familiarize users with the application. The application will be
delivered as an installable apk.

2.16 Change Management Process

If there are new requirements during development there will be a group meeting involving all
group members and the advisor, it will be decided by group consensus to provide alternative
methods.

35
 Chapter 3: SYSTEM DESIGN

3.1 General Overview

In android application development, the basic application architecture follows the View-Model
architecture. We will have a view in which we try to integrate business logic and background
tasks to.

This leaves as with “everything is connected with everything” [1], meaning we will have many
and very complex classes that are interconnected. We can list out the difficulties the basic
architecture such as: -

1. Complexities in our Activity classes may lead to God Objects which are untestable and
unmaintainable
2. Restarting Background tasks is often not clearly defined in the basic architecture and
sometimes will result in "progress bar forever" bug [2].

To overcome these difficulties, we will make use of the Model-View-Presenter architecture.

So, what is MVP?

- View is a layer that displays data and reacts to user actions. On Android, this could be an
Activity, a Fragment, an android. View or a Dialog.
- Model is a data access layer such as database API or remote server API.
- Presenter is a layer that provides View with data from Model. Presenter also handles
background tasks.

On Android MVP is a way to separate background tasks from activities/views/fragments to make

them independent of most lifecycle-related events. This way an application becomes simpler,
overall application reliability increases up to 10 times, application code becomes shorter, code
maintainability becomes better and developer’s life becomes easier [1].

We choose MVP because firstly we are trying to decouple our application easily and since we
are using multiple API’s the MVP architecture will handle them separately. The presenter class
will take over business logic parts of the view class. Our view layer will become simple and
linear and will only be concerned with the interface.

36
Secondly restart of background tasks in the case of a process restart, the presenter just
remembers which requests it should execute, and if a process restarts during execution, Presenter
will execute them again.

Figure 8 - Context diagram

3.2 Development Methods & Contingencies

The approach used for designing the system is an UML approach with MVP architectural
pattern. Java programming language will be used for our Android development. For Voice
Recognition, we will use a library called PocketSphinx. PocketSphinx is a lightweight speech
recognition engine, specifically tuned for handheld and mobile devices.

Lastly, we will also make use of an indoor navigation SDK called Indoor Atlas. Indoor Atlas
Android SDK for indoor navigation, which provides an API to create location- aware application
for navigation inside building by using device hardware sensors like compass, gyroscope and
accelerometer.

37
3.3 System Architecture
3.3.1 Subsystem decomposition

Figure 9- Layer 1

38
Figure 10 - Layer 2

Figure 11 - Layer 3

39
 3.3.2 Hardware/software mapping

Figure 12 - Deployment Diagram

40
4.4 Object Model
4.4.1 Class Diagram

Figure 13 - Class diagram

41
 4.4.2 Sequence Diagram

Figure 14 - Get Map Information

42
Figure 15 - Locate User

Figure 16 - Recognize Voice

43
Figure 17 - Respond with voice

44
Figure 18 – Search

Figure 19 - Set Preferences

Figure 20 - Set location

45
Figure 21 - Show Important Landmarks

46
Figure 22 - Track User

4.5 Detailed Design

Table 24 - Map Class

47
 Map Class
-MapFile: File
+MapType:String
-CurrentLocation: Location
-RouteList: <Route>
-MapInfoList: < MapInfo>
+getCurrentLocation()
+getRouteList()
+getMapInfoList()
+getMapFile()
+search()

Table 25 - Attributes description for Map Class

Attribute Type Visibility Invariant

MapFile File Private Map File <> NULL. File should only contain the map.
MapType String Public MapType <> NULL.
MapType E {‘indoor’, ‘outdoor’}
CurrentLocation Location Private CurrentLocation <> NULL. It should contain the current
location of the user.
RouteList List Private It should contain a list of route object. It must contain at least
one route.
MapInfoList List Private It should contain a list of information objects

48
Table 26 Operation Description for Map class

Operation Visibility Return Argument Pre-Condition Post Condition

type
getMapFile Public File String Map file must be Retrieves map
present file
getCurrentLocation Public Location void Map must load Users location
should exist
getRouteList Public <Route> void User must search Retrieves a list of
for a location routes
getMapInfo Public <MapInfo> void Map must load Retrieves a list of
information about
the location
search Public String keyTerm: Keyterm must be Retrieves a list of
String provided search results

Table 27- User Class

User Class
-lastKnownLocation: <Location>
49
 -name: String
-preference: boolean
+staff: boolean
+getPreferences()
+setPreferences()
+getName()
+setName()
+getLastKnownLocation()
+setLastKnownLocation()

Table 28 - Attribute Description for User Class

Attribute Type Visibility Invariant

lastKnownLocation Location Private lastKnownLocation<> NULL. It should contain a location
object..
name String Private name <> NULL
Range is <=255
preference boolean Private preference <> NULL
staff boolean Public Staff <> NULL

Table 29 - Operation Description for User Class

Operation Visibility Return Argument Pre-Condition Post Condition

type
getPrefernces() Public boolean void Users should be It returns
registered. preference
attribute.
setPrefernces() Public void boolean Users should be Sets the preference
registered. of the user
getName() Public String void Valid string name Returns the name
must be provided attribute.
setName() Public void String Sets the name

50
 attribute
getLastKnownLocation( Public Location void Preferences must It returns the
) be set to visible lastKnownLocation
attribute.
setLastKnownLocation() Public void Location GPS must be Sets the last known
turned on. location of the user

Table 30 - Route Class

Route Class
+pathCoordinates : <Location>
+distance: Long

+calculateDistance()

Table 31 - Attributes description for Route class

Attribute Type Visibility Invariant

pathCoordinates List Public pathCoordinates <> NULL. It should contain a location list.

distance Long Public Distance <> NULL

Table 32 - Operation description for Route class

Operation Visibility Return Argument Pre-Condition Post Condition

type

51
 calculateDistance Public Long startingLocation:Long Start and end The distance
endLocation:Long point should be will be
given calculated

Table 33 - Location class

Location Class
-Latitude: Long
-Longitude: Long
+getLat()
+getLong()

Table 34 - Attributes description for Location class

Attribute Type Visibility Invariant

Latitude Long Private Latitude <> NULL
Longitude Long Private Longitude <> NULL

Table 35 - Operation description for Location class

Operation Visibility Return Argument Pre-Condition Post Condition

type
getLatitude Public Long void GPS must be on Latitude is
retrived
getLongitude Public Long void GPS must be on Longitude is
retrieved.

Table 36 - Map Information class

Map Info
-location: Location

52
 -locationName: String
-locationDescription: String
+getLocation()
+getLocationName()
+getLocationDescription()

Table 37 - Attributes description for Map Information class

Attribute Type Visibility Invariant

location Location Private Location<> NULL
locationName String Private It should contain location name

locationDescription String Private It should contain location description

Table 38 - Operation description for Map Information class

Operation Visibility Return Argument Pre-Condition Post Condition

type
getLocation Public Location void GPS must be on Retrieves a list of
locations
getLocationName Public String void User must click a Retrieves a list of
button location names
getLocationDescription Public String void User must click User will get a
description button description of the
desired location

Table 39 - Speech Recognizer class

Speech Recognizer Class

+utterance: Object[]

53
 +match()
+startRecognition()
+stopRecognition()

Table 40 - Attributes description for Speech Recognizer class

Attribute Type Visibility Invariant

utterance List Public utterance <> NULL

Table 41 - Operation description for Speech Recognizer class

Operation Visibility Return Argument Pre-Condition Post Condition

type
Match() Public String void User must input Matches key
key word word with
existing terms
startRecognition Public void void User must input System records
key word voice for
matching
stopRecognition Public void void The system must System returns
have started voice recording
recognition for matching

Table 42 - Speech Responder class

Speech Responder Class

54
 +respond()

Table 43 - Operation description for Speech Responder class

Operation Visibility Return Argument Pre-Condition Post Condition

type
respond() Public String void User must input System starts
key word voice response.

Table 44 - Navigation Class

Navigation Class
+ navigationType: String
+ mapList: <Map>
-currentMap: Map

+showCurrentMap()
+showRoute()

Table 45 - Attributes description for Navigation class

Attribute Type Visibility Invariant

55
 navigationType String Public navigationType <> NULL
mapList List Public It should contain a list of maps

currentMap Map Private currentMap <> NULL

Table 46 - Operation description for Navigation class

Operation Visibility Return Argument Pre-Condition Post Condition

type
showCurrentMap Public String Map currentMap It should display
attribute must be current map
set
showRoute Public void void Map must load It should display
route

BIBLIOGRAPHY

56
[1] http://www.gsmarena.com/glossary.php3?term=gps, last accessed on: November 1, 2016
[2] http://gps.sref.info/course/7a.html, last accessed: November 1, 2016
[3]http://nationalgeographic.org/encyclopedia/geographic-information-system-gis/, last accessed:
November 1, 2016
[4] https://www.fleetmatics.co.uk/resources/articles/the-difference-between-gps-and-gis, last
accessed: November 1, 2016
[5] http://www.aait.edu.et/about-aait, AAiT Website, last accessed: October 29, 2016
[6] https://intland.com/blog/why-upgrade-from-waterfall-to-evolutionary-development-evo/, last
accessed: November 4, 2016
[7] https://www.quora.com/What-are-the-limitations-of-the-PhoneGap-app-development-tool,
last accessed: November 4, 2016
[8] http://www.sixsigmadaily.com/the-activity-network-diagram/ , last accessed: November 2,
2016
[9] Kotonya, G. and Sommerville, I. 1998. Requirements Engineering: Processes and
Techniques Chichester, UK: John Wiley and Sons

APPENDIX

57