COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE

FINAL DOCUMENATATION ON MOBILE BASED CAMPUS GUIDE

SYSTEM FOR HARAMAYA UNIVERSITY

Authors:

S. No STUDENT NAME ID No SIGNATURE

1 ADDISU HAILU 420/08 _____________

2 AMIR MOHAMMED 423/08 _____________

3 BONSA GEMECHU 433/08 _____________

4 MULUGETA SAID 469/08 _____________

5. SENA MULUGETA 480/08 _______________

 Acknowledgement

First of all, we would like to thank our Advisor Mr. Samuel, for his restless edition of our
document, input to the quality of this document, heart full guidance, his valuable advice,
and providing direction when we got information and reading materials to execute this
project.

At the last but not the least, even if it is unusual, the group members would like to thank
each other. The main contributors to the success of this project are teamwork, friendship
and the belief that we may achieve something we set out to do. We also hope that this
project and the documentation may be testaments to our continued friendship and better
work.
ABSRACT

The system is mobile based campus guide system. The main idea of this project is to design and
implement android base mobile application which will by visitors and people who live in the
campus to get guidance through mobile phone. Hence a mobile tour guide system can be a
solution to support peoples as well as for the campus. In this work, some functionality like
showing the route direction and location map of POIs, locating users and POIs location users are
implemented. The expected outcome of this system is to enable users to get guidance about the
campus through their mobile phone and view their request using Google map API.
List of Abbreviation

HU…………………………………Haramaya University

POI…………………………………Point of interest

GPS……………………………….. Global position system

DB…………………………………. Data Base

MBCGS……………………………..Mobile based campus guide system

GUI…………………………………..Graphical user interface

MS……………………………………..Microsoft

UML…………………………………..Unified modeling language

RAM………………………………….Random access memory

MB……………………………………Mega byte

ADT…………………………………..Android development too

List of Tables

Table 1 hard ware tools ....................................................................................................................6

Table 2 software tools ......................................................................................................................6

Table 3 business rule table .............................................................................................................10

Table 4 use-case scenario Navigate ...............................................................................................17

Table 5 use-case scenario Search ...................................................................................................18

Table 6 use-case scenario Reminder ..............................................................................................19

Table 7 use-case scenario Get my location ....................................................................................20

Table 8 use-case scenario Weather Forecast .............................................................................21

Table 9 use-case scenario Login ................................................................................................22

Table 10 use-case scenario Logout ............................................................................................23

Table 11 use-case scenario Add Place ...........................................................................................24

Table 12 use-case scenario Delete Place .......................................................................................25

Table 13 access control matrix for proposed system. ....................................................................65

Table 14 Global flow for proposed system. ...................................................................................65

List of Figures

Figure 1the Incremental development software process ..................................................................4

Figure 2 Gaunt chart ........................................................................................................................8

Figure 3 Use case Diagram of HU campus guiding system ..........................................................15

Figure 4 Class Diagram for HU campus Guiding System .............................................................26

Figure 5 Object Diagram for HU campus Guiding System ...........................................................27

Figure 6 Sequence Diagram for Navigation ..................................................................................28

Figure 7 Sequence Diagram for Search .........................................................................................29

Figure 8 Sequence Diagram of: Login ...........................................................................................30

Figure 9 Sequence Diagram for Logout.........................................................................................31

Figure 10 Sequence Diagram for Weather Forecast ......................................................................32

Figure 11 Sequence Diagram for View map..................................................................................33

Figure 12Sequence Diagram for Reminder ...................................................................................34

Figure 13 Sequence Diagram of: Add place ..................................................................................35

Figure 14 Sequence Diagram for Delete place ..............................................................................36

Figure 15 Activity Diagram for: Navigation .................................................................................37

Figure 16 Activity diagram for Search ..........................................................................................38

Figure 17 Activity Diagram for: Login ..........................................................................................39

Figure 18Activity Diagram for: Logout .........................................................................................40

Figure 19 Activity Diagram for: Weather Forecast .......................................................................41

Figure 20 Activity Diagram for: Reminder ...................................................................................42

Figure 21 Activity Diagram for: Nearby place ..............................................................................43

Figure 22 Activity Diagram for: Add place ...................................................................................44

Figure 23 Activity Diagram for: Delete place ...............................................................................45

Figure 24 State chart Diagram for: Navigation..............................................................................46

Figure 25 State chart Diagram for: Search ....................................................................................47

Figure 26 State chart Diagram for: Login ......................................................................................48

Figure 27 State chart Diagram for: Logout ....................................................................................49

Figure 28 State chart Diagram for: Nearby Place ..........................................................................50

Figure 29 State chart Diagram for: Weather Forecast ...................................................................51

Figure 30 State chart Diagram for: Reminder................................................................................52

Figure 31 State chart Diagram for: Add Place ...............................................................................53

Figure 32State chart Diagram for: Delete place ............................................................................54

Figure 33 Subsystem decomposition for MBCGS........................................................................58

Figure 34 Deployment diagram .....................................................................................................59

Figure 35 System architecture for mobile application of MBCGS................................................60

Figure 36 Hardware Software Mapping ........................................................................................61

Figure 37 Persistence data modeling ............................................................................................63

Figure 38 Relationship diagram for tables .....................................................................................64

Table of Contents
Acknowledgementi
ABSRACTii
List of Abbreviationiii
List of Tablesiv
List of Figuresv
CHAPTER ONEviii
INTODUCTIONviii
1.1.viiiviiiviii
1.2 Statement of the problemix
1.3xxx
1.3.2. General objectivex
 1.3.2. Specific objectivex
1.4 Methodologyxi
1.4.1 Data Collection Methodxi
1.4.2 System Development Modelxi
1.4.3 Software development techniquexii
1.4.4xiixiixii
1.5 Project Scope and Limitationxiv
1.5.1 Scope of the projectxiv
1.5.2 Limitation of the projectxiv
1.6 Significance of the projectxiv
1.7 work break downxv
Chapter – Twoxvi
System Requirement and Specificationxvi
2.1 Existing system descriptionxvi
2.1.2 Business Rulesxvii
2.2 Feasibility Studyxviii
1.5.1 Economic Feasibilityxviii
1.5.2 Technical Feasibilityxix
1.5.3 Schedule Feasibilityxix
1.5.3 Operational Feasibilityxix
2.3. Proposed Systemxix
2.3.1 Overviewxix
2.3.2. Functional Requirementsxx
2.3.3 Nonfunctional Requirementsxxi
Chapter Threexxiii
3. System Modelxxiii
3.1 Use case Modelxxiii
1.5xxivxxivxxiv
3.3xxxivxxxivxxxiv
3.3.1xxxivxxxivxxxiv
3.3.2 Object Diagramxxxv
 3.4 Dynamic modelxxxvi
3.4.1 Sequence Diagramxxxvi
3.4.2 Activity Diagramxlv
3.4.3 State chart Diagramliv
Chapter Fourlxiii
System Designlxiii
4.1 Introductionlxiii
4.1.1 Overview of system designlxiii
4.1.2 Design goallxiii
4.2 system Decomposition with servicelxv
4.3 Proposed software Architecturelxvii
4.4lxixlxixlxix
4.5lxixlxixlxix
4.6lxxiilxxiilxxii
4.7lxxiiilxxiiilxxiii
4.8 Boundary conditionlxxiii
REFERENCElxxv

CHAPTER ONE

INTODUCTION

1.1. Background

Haramaya University (HU) is the oldest and top teaching universities in Ethiopia and is
located in Oromia Region, Haramaya Zone. The campus occupies more than thirty hectares.
Which have many complex buildings and most of the buildings are connected each other.
And consists of number of services like dormitory, clink, library, classroom, student
cafeteria, lounge, administrative office and others. This makes it difficult find and to know
 information about the place and also services especially for new comers to the campus.
Because the current system works with tagged direction or people who know about the
campus this makes difficult for new comers.

Mobile guide is a term that starts to appear in the last two decades. It involves using mobile
device as electronic guide a specific place [1]. The tourist needs to search information about a
Point of Interest (POI) from his mobile. Mobile campus guide consists of three main
applications: information guide, event guide and navigation support.

Information guide:- is focus on providing information like library, dorm , clinic,

administrative office and so on in the campus.

Place Guide:- emphasizes on providing information about places around user’s position in a
campus.

Navigation Support:- puts navigation support as its main feature. Which help the user to
navigate and find specific location.

1.2 Statement of the problem

In the current system to guide/ know about the places in HU campus, that are done in
traditionally tagged direction. In addition everyone, who is new to the campus, is guided by
using the help of other experienced peoples. Almost all new students, teachers and other workers
in Haramaya University use this kind of techniques system in order to adapt themselves to the
campus. We had observed many short comings of the existing systems in Haramaya University.
The following are some of them.

 New peoples to the campus fully relay on experienced peoples in order to orient
themselves to campus and find specific places.

 Time consuming: it takes a lot of time to find the place we are looking for since there is
no system which navigates us to the place we want to go.

 It not able to get travel information timely when people are on the move.
  Lack of trust: - It is difficult to know whether the provided information is true or not.

 Manually tagged: the tagged direction only show us the direction not the actual place.

 Couldn’t find alternative path because the tagged direction only show us one direction
and people who help new comers take people on the path they chose.

 Change location: when there is change of location the tagged direction won’t be helpful
anymore.

1.3 Objective

1.3.2. General objective

The general objective of this project is to develop an android based campus guide system for
Haramaya University.

1.3.2. Specific objective

In order to achieve the above general objective we will have the following activities.

 Identify the problem of the existing system

 Collecting necessary information for the project
 Analyzing the system requirements
 Identify the functional and non-functional requirements of the system
 Design the proposed models or architecture based on the analyzed requirements
 Select development tool for implementation
 Develop the proposed system.
 We develop automated system that is trustworthy and reduce wastage of time.
 We will develop a system which work with change.
 We will develop a system which provide alternate paths with shortest path.
 Test and evaluate the developed system.
 Prepare user manual or help document.
1.4 Methodology
1.4.1 Data Collection Method

Interviewing:- we use this data gathering methods for collecting data’s from the students and
teachers of HU campus. We also interview the campus administrators and other workers and we
get information about how they are guiding the campus and problems on using the current
system.

Group discussions:-we use this data gathering methods in order to get Brain Storming Idea
about the need of proposed system. We had done this technique with our friends.

1.4.2 System Development Model

Before the development of the system was begun, the available sources were the functionalities
and the use of the application. So the Incremental development software process model was
decided to be used because it is based on the development of multiple versions of the application
by getting the Users comments in each version and evolving through several versions until the
system meets the requirements of the Users.

The most significant advantage of using Incremental development system development

methodology is listed as follows:

 Users are actively involved in the development.

 Errors can be detects much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identifying easily.
 Confusing or difficult functions can be identifying.
 Since in this methodology a working model of the system is provided, the users
get a better understanding of the system being developed
Figure 1the Incremental development software process
1.4.3 Software development technique

Before developing system the team crew decided to use Object-Oriented system because the
features of object oriented system are necessary for us. For example

1. Encapsulation: we have data’s which need to be encapsulated such as information about

the users.
2. Inheritance: there are some classes which inherit attributes of other classes. For example
POI inherits the attributes and methods from Place class.
3. Relationship: Most of the classes which are found in the system have a relationship
between each other.

These are the reasons which make us to choose object-oriented system, and this development
technique will help us to develop our system in the way we want to develop.

1.4.4 System Development Tools

We used different hardware and software tools to analyze the problem found on existing system
in HU campus and for development and simulation of the project.
Those hardware tools are:

No Item Purpose Specification

1 Desktop computer laptop Implementation Core i5hp 8GB RAM

purpose Storage 1TB

Cpu 2.4GHz

2 Storage device For storage and file 8GB Toshiba

sharing
Table 1 hard ware tools

The software tools we used are:

Number Item Purpose Specification

1 Microsoft office package For documentation Microsoft office 2016

2 Edraw-Max and MS-Visio For drawing UML MS visio 2013

diagrams.
Edraw-Max 2010

Table 2 software tools

1.5 Project Scope and Limitation

1.5.1 Scope of the project

The scope of this project is to develop a mobile based campus guide system for Haramaya
University. The system will have two major deliverables. The first one is mobile application that
guide the user throughout the campus. And the second one is the google map server which
responds the request of the user by searching all possible routes and calculating the shortest path
to reach the user destination, it also responds question like nearby place and searches. And the
system will provide additional service like reminding for alarmed occasions and weather
condition of Haramaya University.

1.5.2 Limitation of the project

The limitation of this project is the functionality that the system will not incorporate. The major
limitation is the system doesn’t support indoor navigation, it will not incorporate local language
to the system and the system can be used for only android smart phones, it cannot be used for
computer platform and any other types of smart phone.

1.6 Significance of the project

Mobile based guide system is a technology that uses GPS service for locating the location of user
and Google map is used to fetch the information about location detected. The system provides
information about services and events that are near to the user location. The information about
POI and event is managed by the campus administrators. The aim of the proposed system is to
minimize the drawbacks that are existed in the current (traditional) system and to make an
impact on making human life simple. In general the system has the following benefits to the
campus and individual users:-

 The System has technological significance since it support guidance to people using new
technology (smart phone).

 It avoid physical guidance

 The System reduces dependence of new comer people on others, because they can move
from place to place using developed application.
 The System increase economic development since it reduces wastage of time that means
work time will be increased.
 The System reduces time needed from experienced people to the campus to guide new
comers to the campus.

1.7 work break down

 Dec2018 Jan2019
ID TaskName Start Finish Duration
9/12 16/12 23/12 30/12 6/1 13/1 20/1

1 Introduction 12/10/2018 12/18/2018 1.4w

2 SystemRequirementandspecification 12/18/2018 12/27/2018 1.6w

3 SystemModel 12/28/2018 1/11/2019 2.2w

4 SystemDesignandReference 1/14/2019 1/21/2019 1.2w

5 finaldocumentsubmission 1/22/2019 1/24/2019 .6w

Figure 2 Gaunt chart

Chapter – Two

System Requirement and Specification

2.1 Existing system description

The current system used by new people to the campus is using manually in order to guide the
campus. That means there is no developed system for HU campus that helps new comers to the
university. In existing system the people use their friends or other people which will hired by
the campus in order to guide the campus, reach specific place , move from place to place. The
hired guide then narrates history of the place and service available around the place and there is
no surety that all narrate story is true. There are tagged place markers that are intended to help
sand navigate visitors but the place might be changed and it will be confusing for visitors. The
visitor is not aware about location or place before going there, hence the whole information is
hidden by visitors. And also consume more time in finding proper locations. These are the main
disadvantage for the visitors. In general the proposed project tries to address the above stated
problems.

2.1.2 Business Rules

Business rule ID Name Description

Before the place is add to the
database we have to get exact
BR1 Add place longitude and latitude value of
place and check in database
weather is added or not
before.
After we fill the search form
BR2 Search place we get the place if it is found
in the database.
After we get where exactly we
needs to go the system display
BR3 Navigation possible routes by calculate
 their path.

Before delating, the place

BR4 Delate place have to be stored in the
database.
The system will generate
BR5 Notification notification when the user
reaches the destination.
The user sets its reminder.
BR6 Reminder Date and time must be
recorded correctly.
User can get the weather
BR7 Weather forecast condition any time he/she
needs to get.

Table 3 business rule table

2.2 Feasibility Study

The feasibility is preliminary investigation in to the potential benefits associated with

undertaking this project to the HU campus. The feasibility of this project can be seen in to four
different aspects:

 Economic feasibility
 Technical feasibility.
 Schedule feasibility.
 Operational feasibility.

1.5.1 Economic Feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a new
system. It concern with the cost-benefit analysis while we are going to develop a proposed
system. But we are doing this project for the partial fulfillment of the requirements of Bachelor of
computer Science in 2018/2019, so we will not concern about it.
1.5.2 Technical Feasibility

Now a day we observed that most peoples in HU campus use smart mobile phone to call to their
related. They also use their mobile phone for playing audio, video recording and camera. Mobile
based campus guide system is not more complicated compared to those applications that the
people used daily. This system also makes the system easier by making the interface more users
friendly. So we can conclude using this system almost technically feasible.

1.5.3 Schedule Feasibility

Schedule feasibility concerned with the analysis and conclude whether the given project can be
completed within the time available to the project. We have a short time to develop the proposed
system because we waste much of our time in finding a project title that will be accepted by our
department. Even though we have started late, we believe that the time will be enough to
accomplish our project by using appropriate time management for our team to be successful and
to do efficiently.

1.5.3 Operational Feasibility

We perform the activity first by having understanding the main problem of traditionally tagged
direction have and we thought to change this existing system to android based system and the
project result is operational since it solve the existing problem.

2.3. Proposed System

2.3.1 Overview

To overcome the drawbacks of the existing system (techniques), the proposed system has been
evolved. In our proposed system we are going to develop a campus guide system for android
smart Mobile phones. The proposed system is a Location based campus guide system that use
GPS service for finding location and Google map to fetch the information about location that the
user is in. The Mobile application will be installed on the mobile of user and can act as a guide.

The system will provide different information about services around the user position place, rout
path for location of places where the user wants to go. The system will enables to guide users
while they are on the move without wasting their time in finding proper locations. And also it
provides necessary details about routes and descriptions of the guide objects. While there is
change of location the system will update the location of that specific place. It also provide
alterative paths with shortest path for the user and the user choose the path he/she likes.

In general this system will reduce the cost, time and effort of the user and also it will provide
such an easy way to get the location of the required places and nearby services.

2.3.2. Functional Requirements

Functional requirements are requirement that are function or operation should have to perform
even if there are a lot of constraints in the environment. Functional requirements may be
calculations, technical details, data manipulation and processing and other specific functionality
that determines the proposed system to say it campus guide system or not to the users. These
groups of requirement steers functionality that the system should support for the user.

The functional requirements to be incorporate by the system are the following:

 Navigation: - the system should allow user to navigate the campus using map with able to
see Point of interest on the map like clinic, cafe, library.. .
 Route finding: The system shall show the route between current location and POI
location with smallest estimated distance.
 Search POI and place: the system will allow the users to search places and POI in order
to get information about them.
 Notification: the system will notify users when it is around POI.
 View service: the system will allow users to see POI that are found nearest to user
location with information and event associated on that particular location.
 The system allows the administrator to manage events include: creating, view, modify
and remove events.
 The system will also provide a map to user that will be zoomed in, zoomed out and
scrolled.
 Reminder: The system help users to add reminder or note and notify them.
 Weather forecast : The system will gives information about the weather of the campus
2.3.3 Nonfunctional Requirements

Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific functions delivered by the system. They may relate to overall
performance of the system properties such as reliability, response time and store occupancy.
Non-functional requirements are often used to determine the quality of the software.

In order to give satisfaction to the client is should do all the operations of existing system in
interactive and easy way with fast response time and maximum through put. The memory used to
deploying and while performing the system in clients mobile need not be excessive.

Generally the following are some of the non-functional requirements that we will try to address
while we are developing the proposed system:

 Maintainability: the prosed system will be very suitable to be modified and expended in
both scope and functionality aspect.
 Availability: the proposed system will be working any time the user wants to use it.

 Security: Security requirements are important factors in this system as classified data will be
stored in the database. The proposed system will insure this by not including an operation on
that enable users to modify the data on the system.

 Operability: Every operation of the system must be as simple as possible for the users to
operate easily. Functions of the system must achieve the need of user. The proposed
system will achieve this by providing simple user interface.

 Robustness: is a system that does not break easily or is not wholly affected by single
application failure or invalid input. Mobile based guide system will be a robust system
by making not to accept invalid input and notify about the situation to user about the
problem to correct for the future.
 Reliability: the reliability of the proposed system much more dependent on the internet
network availability on the user smart cell phone. If there is a reliable and continues
internet network available on the user’s phone then the system will work in fine way
without lack of its functionality. The information that is going to be provided by the
proposed system is correct this makes the proposed system reliable.
 Chapter Three

3. System Model

3.1 Use case Model

exit add reminder

notification

edit reminder
navigate <<extend>> logout
<<include>>
<<extend>>

remove reminder <<include>>

<<include>>
<<extend>>
reminder

login
search place <<include>> view HU map
<<include>>
<<include>>

view map <<include>> addplace

shortest path <<include>>
user <<include>> admin
<<extend>>

nearby place <<include>>

<<extend>>
route

get my location delete place

wather forcast

Figure 3 Use case Diagram of HU campus guiding system

 1.5 Use case Scenario

Use case Navigate

Participant Actor User

Description Used to navigate user from current location to

destination

Pre-condition --Application launched

--GPS must be activated and the mobile

device should be connected to internet access.

-- User Knows valid destination

Post-condition Use reaches to destination in short distance

Flow of event 1. user press the button

2. System display a text box to get input for

the destination place

3. User enters the name of place or POI that

user wishes to reach. And then press enter.

4. System display shortest path from user

current location to destination graphically on
map.

5. The system will Tracks user current

location and it will be updated between 1-3
seconds
Exception a if user insert invalid or non-existing name of
destination place

The system asks to enter a valid

destination place.

3.b if user insert the current location place as

destination place

The system notify users that the user is now

located on it.

Table 4 use-case scenario Navigate

Use case Search

Participant Actor User

Description Used to search information about specific POI

 or Place

Pre-condition --GPS must be activated and the mobile

device should be connected to internet
access.

-- User Knows valid name for POI or place

Post-condition User will gate information about POI or Place

Flow of event 1. User Press the search button

2. System display a text box to enable user to

enter name of POI or place

3. User enters the name of POI or place that

he/she want to get information and then press
enter.

4. the system will display information of POI

or the place

Exception a. if user insert invalid or non-existing

name of POI or Place
The system display a message that the
user requesting a non-existing POI or
place.

Table 5 use-case scenario Search

Use case name Reminder

Description Let the user see his planned schedule.
pre-condition
The user must get internet connection
Flow of event 1. The User Click on Reminder button.
2. The application automatically displays the saved remainders and add new
reminder options.
3. The user long press on one saved remainder.
4. The application display options view reminder, update reminder and delete
reminder.
5. The user select view reminder.
6. The application display detailed of selected reminder.
7. The user click back arrow
8. Back to main menu.

Post condition Selected remainder information is viewed.

Table 6 use-case scenario Reminder

Use case name Get my location

Description Let the user to get and know their current location.
Actor User

pre-condition
The user must get internet connection

Enable the Location Service

Flow of event 1. The User Click on getMyLocation button.
2. The System will set location listener and update the location data.
3. The system start map activity and updates user location.
4. The user views their current location on the map.

Exception Your location not found

Post condition Your location on the map is displayed and you can zoom in and out to see well.

Table 7 use-case scenario Get my location

Use case name Weather Forecast

Description

Let the user to know the weather to determine its day, in case of wearing clothes.
Actor User

pre-condition
User must have app on his phone.
Flow of event

1. The User Click on Check Weather button.

2. The System will display the current weather condition and guide the cloth that
suits with the weather.

Week internet connection

Exception

Post condition
The system display the current weather condition and advice the user with regarding of
cloth.

Table 8 use-case scenario Weather Forecast

Use case name Login

Description This use case help the admin to login to the system .to get some
 privileges that is given by the developer.
Actor Admin
Priority High, admins has to be logged in the system to perform their task.
pre-condition The admin account must exist in the database.
Flow of event
Basic Flow of Event

1. User launches the login page.

2. Enter username and password form displayed.
3. User enters a combination of username and password.
4. System validates the combination and logins the user
successfully.
5. The admin page is displayed.

Alternative Flow
i. If incorrect username/password combination is entered, system
display, “incorrect username or password” message and request
the user to re-enter the combination.
ii. If empty field value exists, system displays corresponding error
message.

Post condition

- User logged in successfully to the system and admin page displayed.

Table 9 use-case scenario Login

Use case name Logout

Description In order to logout from the administration privilege
Actor Administrator
pre-condition The Admin must login to the system
Flow of event Basic Flow of Event
1. Admin Launch the login page
2. Admin enter his correct username and password
3. System will validate his input data and keep logged the admin
Alternative Flow of Event
I .if the admin enter incorrect username and password the system will ask
him to give the correct data
ii. if the user try to login with the empty field the system ask the user to
enter the correct inputs
Exceptions user account does not found on the data base

Post condition The user logged in successfully

Table 10 use-case scenario Logout

Use case name Add Place

Description In this application the administrators add Place
Actor Administrator
pre-condition The admin must login to the system
 Active Internet connection
Flow of event
1. Administrators enter to the application with their privilege.
2. The administrator click the Add button
3. The Administrator select the POI from the list view
4. The administrator enter the description for the selected POI
5. The click the save button
6. The application display the “successfully saved”

Post condition The details information of the Place is added

Table 11 use-case scenario Add Place

Use case name Delete Place

Description The administrator deletes the inserted place of POI
Actor Administrator
pre-condition The Place must have found
Flow of event Basic Flow of Event
1. Administrators enter to the application with their privilege.
2. The application display the name of POIs on the map
3. The administrator select POI by clicking
4. Application displays the description of the selected sights.
5. The administrator will click the delete button
6. The system Show message box “Are You Sure to delete”.
7. The administrator click “ok”
8. Show message “Successfully deleted”.
Alternative Flow of Event
1. The user follow the steps up to 6 in that dialog box if the user press
 the ‘’cancel” option, The Descriptions Of the POIs remains in the
database.

Post condition The data is deleted successfully

Table 12 use-case scenario Delete Place

 3.3 Object and Class Diagram
3.3.1 Class Diagram

person
+firstname:string
+lastnam e:string
+status:strinng
+field:string
+em ail:em ail
+getusername()
+getlastname()
+getstatus() user
getemail() 1
admin
-viewPOI()
-username:string -viewplace()
-password:varchar -viewreinder()
Crwateaccount()
1 view
manage 1..m 1
has 1
rem
inder
account map
1
Manage +name:string
+username +date:date +longtime:number
+paswword:varchar +time:tim e +latitude:number
1..m +create_account() +description:string +getlatitude()
+create_reminder() +getlongtude()
+edit_reminder() +displaylocation()
view
place +view_reminder() +view()

1..m +remove_reminder()
+name:string generate 1
+latitude:number has
+longtude;number
+add_place() 1 1
+view_place()
+remove() generate notification weather

1..m +content:string -temprature:string

+status:boolean -gettemprature()
POI
+enable() -viewtemprature()
+disable()
+type:string
+viewnotification()
+service-discription:string
+view_POI()

Figure 4 Class Diagram for HU campus Guiding System

3.3.2 Object Diagram

person
+firstname:Bonsa
+lastnam e:Gemechu
+status:Student
+field:com p
+em ail:[email protected]
om

user

admin manage

view
-username:bonsag
-password:almiye
has

rem
inder
account map
Manage +name:Birtgday
+username:bonsag +date:3/92019 +longtime:4.965874
+paswword:almiye +time:2:00 +latitude:9.357410
c +description:mybirtday view
generate

place
+name:Am el generate
+latitude:4.965874
+longtude;9.357410

notification weather
+content:Youhavereached -temprature:17C
+status:T
POI
+type:building
+service-discription:dormitery

Figure 5 Object Diagram for HU campus Guiding System

3.4 Dynamic model
3.4.1 Sequence Diagram

navigate
navigate navigate result place
user controlle GPS
button form interface database
r

press()
create() get location()

return location()
X

X
create

fill and submit()

accept()

X
check location()

return result()

alt
X
[if result = empty] error message()

view()

[else]

show direction and POI()

X
view()

X
X

Figure 6 Sequence Diagram for Navigation

 useburtton
Search Searchbutton search result
user searchbutton Searchcon seaSerch
archfo
conrm SeaGpscon
rch Searchcon Poi/d atacobnase
Search
controller interface

press
create()

creat()

fill&submit

accept

x alt
x
getsearchplace()

returnresult

if(result=empty)

errormessage() x
else

getlocation()

returnlocation()

displaylocationonmap
view()

x x
x x

Figure 7 Sequence Diagram for Search

 Loginform login home user
admin lo
<<g in
bo fo
und rm
ary>> controller page database

enterusername
andpassword()
createcontroller() checkusername
andpassword()
alt returnresult()

ifusername
andpasswordnotmatch X

return()

[else] create()

view()

X X X X

Figure 8 Sequence Diagram of: Login

 logout logout interface
admin database
button <<controller>> page

click()

createcontroler()

requestlogout

clearsession()
X
returnresult()

displaylogin() X
X
viewloginpage()

Figure 9 Sequence Diagram for Logout

 weather weather weather
user interface
button controller databese

press()

create()
getweather(()

x returnresult

x
displayresult()

view()
x
x x

Figure 10 Sequence Diagram for Weather Forecast

 view view result place
Placedatabase
user GPS database
button controller interface

press()

create()
getlocation()
getlocation()

x x returnlocaation

displayresult()

view()

x x

Figure 11 Sequence Diagram for View map

 reminder reminder reminder
user button controllore
interface
database

preess()
create()
getreminder()

returnrem
inder()

x view()
dispalyresult()
x
x
x x

Figure 12Sequence Diagram for Reminder

 addplace addplace addplace result place
admin Resultinterface
button controller form interface database

press()
create()
create()

x fill&submit()

accept()

validitycheck()
forsim ilarentry

alt returnresult

[ifresult=yes]
errorm
essage()

view

[else]
savedata()
successm
essage()

view()
x
x x x x

Figure 13 Sequence Diagram of: Add place

 remove place remove result placedata
admin display
button controller placeform base

pressbutton()
create()
create()

fillandsend

accept

x alt
getplace()

returnresult

[ifresult=empty]

errormessag()

view()

[else]

displayplace()
viewandselectplace()

accept

removeplace()
successmessage()
view()

x x x x
x

Figure 14 Sequence Diagram for Delete place

3.4.2 Activity Diagram

Navigate Button

Fill form
Verify in DB

Found Not Found

Calculate Possible Route

Display Best Route

Figure 15 Activity Diagram for: Navigation

 Search Button

Fill form
Verify in DB

exist Not exist

Display Result Dispaly Not Found

Figure 16 Activity diagram for Search

Figure 17 Activity Diagram for: Login
 Clicklogout

Go to login page

Figure 18Activity Diagram for: Logout

 Weather Button

Weather DB

Display Result

Figure 19 Activity Diagram for: Weather Forecast

 Reminder Button

Verify in DB

exist Not exist

Display Result Dispaly Not Found

Figure 20 Activity Diagram for: Reminder

 View All

Get Location

Check POI in DB

exist Not exist

Display Result Dispaly Not Found

Figure 21 Activity Diagram for: Nearby place

 Click Add Place

Fill out form

Check Validity

Display Noitifaction

Figure 22 Activity Diagram for: Add place

 ClickDeletePlace

Fill outform

Getplacein
D B

Disp
layPlace
Disp
layEmpty

Disp
layNotification SelectPlace

Figure 23 Activity Diagram for: Delete place

3.4.3 State chart Diagram

Figure 24 State chart Diagram for: Navigation

Figure 25 State chart Diagram for: Search
Figure 26 State chart Diagram for: Login
 Idle

Click Logout
button

Login Page

Figure 27 State chart Diagram for: Logout

 Idle GetLocation
Click viewbutton

Check POI
in DB

enable disable

Error message Display Result

Figure 28 State chart Diagram for: Nearby Place

 Idle

Click
Weather
button

Display
Weather

Figure 29 State chart Diagram for: Weather Forecast

 Idle Form Display
Click Reminderbutton

Fill out
form

enable disable

Active Inactive

Figure 30 State chart Diagram for: Reminder

Figure 31 State chart Diagram for: Add Place
Figure 32State chart Diagram for: Delete place
 Chapter Four

System Design

4.1 Introduction

We use System design to transform the analysis model into a system design model. Up to now
we were in the problem domain. System design is the first part to get into the solution domain in
a software development. This chapter focuses on transforming the analysis model into the design
model that takes into account the non-functional requirements and constraints described in the
problem statement and requirement analysis sections discussed earlier.[2]

The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on. The objectives of design are to model the
system with high quality. Implementing of high quality system depend on the nature of design
created by the designer. If one wants to change to the system after it has been put in to operation
depends on the quality of the system design. So if the system is design effectively, it will be easy
to make changes to it

4.1.1 Overview of system design

System design is the process through which the requirements are translated into software.[3] As
we tried to put the overall objective of Mobile based campus guide system on the requirement
analysis part, create mobile based application that improve the guidance of the campus by
allowing users to use the system with their mobile phone over the internet and the users are
guided in what they need related to the campus and navigate them throughout the campus which
is the aim of the system.

4.1.2 Design goal

The second step in software design phase is identifying the qualities that the software should
address. So the qualities of our system inferred from the non-functional requirements
documented in the requirements analysis.
The design goals can be selected from a number of quality criteria that should be incorporated in
the application. In this particular project the following design goal criteria have been identified to
be realistic.

Performance criteria: It is concerned with speed and space requirements imposed on the
system.

 Response time: The response time of our system is highly dependent on network
connection and device performance.

 Memory: As memory is one of the main constraints in mobile devices. The system
will have optimized space requirement for the application program as well as for the
data which is going to be persistently stored in the mobile device. In the development
of the proposed system we will not use any kind of experiments to testify the
performance. But by observing and analyzing projects that are similar to our project
title and scope which are available on internet and we predict that the system needs
android phones having minimum of 500MB RAM capacity.

Dependability criteria: It is concerned with the amount of effort needed in alleviating system
crash and their consequences, frequency of the system crash, and the availability of the system to
users.

 Reliability: the reliability of the proposed system much more dependent on the
internet network availability on the user smart cell phone. If there is a reliable and
continues internet network available on the user’s phone then the system will work in
fine way without lack of its functionality.

 Security: The proposed system will insure this by not including an operation on that
enable users to modify the data on the system and by authenticating admin using
login operation.

Maintenance criteria: It deals with the considerations of possible changes to be made on the
software after it has been deployed.
  Extensibility: The system should be built considering possible mechanisms for
expanding or enhancing the system to gain new capabilities without making major
changes to the system structure.

 Modifiability:-Our system is modifiable when the university needs to make the

application to include other places and location nearby.

 Readability: - The code of the system easily understood by any user who has knowledge
about java, android and xml.

End user criteria : include qualities that are desirable from a users’ point of view, but have not
yet been covered under the performance and dependability criteria.

 Usability: The system should be sufficiently intuitive to allow users to learn its
operations within short time. The system uses graphical user interfaces with
interactive features so the users exploit its utility easily to the fullest.

4.2 system Decomposition with service

In the proposed system we breakdown the system into logically connected sub systems, and
aggregating them into the complete system. In order to simplify and minimize the complexity of
the solution domain, the proposed system is decomposed into six subsystems, namely the
account management subsystem, reminder management subsystem, map management subsystem
and notification subsystem, notification subsystem and weather subsystem.

 Account management: allow Admin to manage their own account like changing
user name and password.
 Reminder management: allow users to create, modify and remove reminder and
can be seen by the mobile phone user.
 Map : allow user to see the current location of the user , POI and navigate user to
the specified place
 Notification management: allow user to receive a popup message based on the
user current position or current reminder.
  Place management: is responsible for adding and deleting place
 Weather management: is responsible for showing users the status of weather

Figure 33 Subsystem decomposition for MBCGS.

Figure 34 Deployment diagram

4.3 Proposed software Architecture

The proposed system will have two- tier architecture. In other word it is a client server
architecture where the system is organized as a set of services and associated with servers and
clients that access and uses the services.
Figure 35 System architecture for mobile application of MBCGS

The diagram above presents the general architecture of the prototype. We build the project based
on the assumption that users use their Android phones in the environment with internet and
having the ability of getting GPS data. GPS will be used for automatic localization since android
phones are usually equipped with GPS. Map Activity in red is the core and the start of
application. Map Activity imports Google Map as the map, and retrieves information of POIs
from remote Server. Map Activity calls Map Overlay to add POIs mark to Google Map. And
Map Activity calls Menu to present more functions such as reminder, search and so on.
 4.4 Hardware software mapping

The system have two main components, client machine and google map server. The user can
access the server through mobile application. The client component defines the user of the
system which access the system through map activity. So the user send the request by the
application found on client machine and the server will respond back the request to the user
using internet.

Figure 36 Hardware Software Mapping

4.5 Persistence Data management

Persistence objects are need to our system to be stored in persistence mechanism, so we use
persistence modeling to store the data on the database. This allows the programs in the system to
share the data, to do operations consistently. In addition to this storing data on the database
allows the program to perform complex queries on the large data sets. So the system will have
one database with three tables.
 Adm
istratortable
Adm
instrator
PK id:Varchar
id
nam e
nam e:Varchar
Address
Address:V archar
Designation
Designation:V archar

Rem
inder Rem
indertable

date PK Name:Varchar
start_time
nam e date:date
description starttime:time
desrciption:varchar

Placetable
Place

nam e PK name:String
lattiude:
longitude: lattiude:Number
longitude:Number
 User table
User
PK id: Varchar
id
name
name:Varchar
Address
Address:Varchar

Account
Account table
Password
Username PK Password:Varchar

Username:Varchar

Map table
Map

lattiude: lattiude:Number
PK
longitude: longitude:Number
Location name
Location name: Varchar

POI table
POI

name PK name:String
lattiude:
lattiude:Number
longitude:
longitude:Number
service_decription
service_desription:varchar

Figure 37 Persistence data modeling

Figure 38 Relationship diagram for tables

4.6 Access control and security

The android based campus guide system must stablish secure access and trust between users and
authenticating access. And some user and admin information like password should be encrypted.
People who uses the system will have their own privilege and they can only access the system
according to the privilege given to them.

Reminder Map Place Notification Route Weather

Admin Add()
Remove()

Mobile <<Create>> View() View() View() View() View()

user View()
Edit()
Remove()
Table 13 access control matrix for proposed system.

4.7 Global control flow

We are going to introduce two global control flow for mobile based campus touring system.
These two global control flows are
1. Procedural driven control flow: This advocate that users of the system should have to
follow the system procedure and wait for the system to give response before using it.
2. Event driven control flow: This flow control is responsible for handling different events
of the system and dispatching to the appropriate resource based on information
association.

Activity Procedural driven control Event driven control flow

Login An administrator of the system enters user To be logged in, the login button should
name and password and then he/she will be be clicked
authenticated after that Homepage will be
displayed
Add place An administrator of the system fills all the To be added , the Add place button
requirements to add place, after that the place should be clicked
will be added.
Delete An administrator of the system fills all the To be deleted , the delete place button
place requirements to delete place, after that the should be clicked
place will be removed or deleted.

Table 14 Global flow for proposed system.

4.8 Boundary condition

Startup: go to system login (admin)

: Directly getting to the system (user)

Shut Down: click log out (admin)

: Quit the system (user)

Error Conditions:
 Logging in:

o Username or password field can are blank.

o Username is not a 5 digit decimal number.

o Password is not 8 characters long.

o Password and username don’t match.

o Username is wrong or does not exist.

 User settings

o User is unable to change certain information or changes don’t reflect.

 Data Entry

o The system fails when the admin or use enter information.

 Relative searching for a case

o Search criteria do not return any results.

 Logging out

o Dispatcher unable to logout.

REFERENCE
1. [AudioTravel,2010]AudioTravel;AudioTravelMobileTravelGuide,http://www.audiotravel
.com/mobile-travel-guide, accessed Feb.27th 2010
2. Software engineering eighth edition, by Ivan S.
3. Essential of system analysis and design fifth eddition , by Valacich, George, and hoffer