Addis Ababa University Institute of

Technology
Centre of Information Technology and
Scientific Computing
BSc Program in Software Engineering

E-Mapper location finder and event sharing

Project Stakeholders:
Getahun kiros, Kedir Abdurahman & Simon Teka

JAN 15 2016

Table of Contents
CHAPTER1 SRS documentation3
Abstract.3
Executive summary.4
Product/service description.5
Requirements 6
CHAPTER 2 FUNCTIONAL REQUIREMENTS.18
Use case diagram.26
Analysis model...39
Active diagram...39
Sequence diagram.41
CHAPTER 3 SYSTEM MODE.56
Deployment design ...56
Architectural design.57
User Interface design.. ................................................................... 58
Data structure design ............................................................................................................................ 64
Algorithm design ................................................................................................................................... 65
Test design ............................................................................................................................................ 66

Abstract
The motivation for every location based information system is: To assist with the exact
information, at right place in real time with personalized setup and location sensitiveness. In this era
we are dealing with palmtops and iPhones, android which are going to replace the bulky desktops
even for computational purposes. We have vast number of applications and usage where a person
sitting in a roadside cafe needs to get relevant data and information. Such needs can only be catered
with the help of LBS. These applications include security
related jobs, general survey regarding traffic patterns, decision based on vehicular information for
validity of registration and license numbers etc. A very appealing application includes surveillance
where instant information is needed to decide if the people being monitored are any real threat or an
erroneous target. We have been able to create a number of different applications where we provide
the user with information regarding a place he or she wants to visit. But these applications are limited
to desktops only. We need to import them on mobile devices. We must ensure that a person when
visiting places need not carry the travel guides with him. All the information must be available in his
mobile device and also in user customized format.

1. Executive Summary
1.1

Project Overview

The (E-Mapper) App is going to be an android application which help users search closest POI,
navigate to the specified destination and share location or event among users. The users of this app are
going to be users with android phone which support GPS receiver antenna and geographical boundry
of Ethiopia country.

1.2

Purpose

The purpose of this document is to give a detailed description of the requirements for the E-Mapper
software. It will illustrate the purpose and complete declaration for the development of system. It will
also explain system constraints, interface and interactions with other external applications. This
document is primarily intended to be proposed to a customer for its approval and a reference for
developing the first version of the system for the development team.

1.2 Scope
The E-Mapper is a GPS-based mobile application which helps people to find the closest needed
places based on the users current position, route to destination, share event, make group, make
frends and set location based reminder .
Furthermore, the software needs both Internet and GPS connection to fetch and display results. All
system information is maintained in a database, which is located on a web-server. The software also
interacts with the GPS-Navigator software which is required to be an already installed application on
the users mobile phone. By using the GPS-Navigator, users can view desired restaurants on a map
and be navigated to them. The application also has the capability of representing both summary and
detailed information about the restaurants.

2. Product/Service Description
2.1 User Characteristics
There are two types of users that interact with the system: users of the mobile application and
administrators. Each of these two types of users has different use of the system so each of them has
their own requirements. The mobile application users can use the application to find POI and do all
with in the features. In order for the users to get a relevant search result there are multiple criteria the
users can specify and all results matches all of those. The service owners will use the mobile
application to manage the information about their service, for example a description of a restaurant,

contact information. The administrators also only interact with the web portal. They are managing the
overall system so there is no incorrect information within it. The administrator can manage the
information for each service place as well as the options for both the mobile application users and the
service owners.

2.2 Assumptions
One assumption about the product is that it will always be used on mobile phones that have enough
performance. If the phone does not have enough hardware resources available for the application,
For example the users might have allocated them with other applications, there may be scenarios
where the application does not work as intended or even at all.

Systems should be implemented within 5 months after the contract.

Another assumption is that the GPS components in all phones work in the same way. If the phones
have different interfaces to the GPS, the application need to be specifically adjusted to each interface
and that would mean the integration with the GPS would have different requirements than what is
stated in this specification.

2.3 Constraints
The mobile application is constrained by the system interface to the GPS navigation system within the
mobile phone. Since there are multiple system and multiple GPS manufacturers, the interface will
most likely not be the same for every one of them. Also, there may be a difference between what
navigation features each of them provide. The Internet connection is also a constraint for the
application. Since the application fetches data from the database over the Internet, it is crucial that
there is an Internet connection for the application to function. Both the web portal and the mobile
application will be constrained by the capacity of the database. Since the database is shared between
both application it may be forced to queue incoming requests and therefor increase the time it takes to
fetch data.

3. Requirements

3.1 Functional requirements

All functional requirement listed below are decided as required to the system by all 3 group members
of the project.

FR-1

Registration
1. Input user details
- User should input first name, last name, email, password and phone number
- Password should include uppercase letter, lowercase and alphanumeric
- User should confirm the password
2 validate users
The system should validate the user details so that supply right input.
3 validate
The system should register the user after correct validation.

FR2
Log in
1 User basic info input
user should email and password to access the system
Optionally he/she can use their username.
2 Authentication
Authenticated if he/she is the right user.
Carefully designed to prevent from sql injection.
FR3
Friend relation
1 Add

User can add another user as friend

2 Unfriend

Users can quit friendship if he/she want by unfriending.

3 Notify

The System should include request notifications to the user

4 Confirm request

User can confirm or ignore to any request sent to him/her.

5 Search friend
A user can search a friend or other user.

FR 4
Search Location
1 Input search option
User can search on the search category (health, bank, transport, food.).
2 Input search keyword
User must write the location/POI name or location coordinate values (latitude and longitude)
on the search box to search that on map
3 Location inquiry
The system should find a location with that name and show it/them on the map with pin symbol
under it.

FR 5
Routing
1 Location info input
User should provide source and destination location.
2 Make route path
The system shall make the route path using the source and destination.
3 Travel detail input

User can give to the system travel option (car or bicycle) he/she want.
4 Update travel
When the user travel to the destination he/she refresh the system and the system shall show the
updated path, time and distance he/she left.

FR 6
Bookmark
1. Bookmark details input
Pin the desired location to be bookmarked and supply details (bookmark name and description)
The bookmark might come after searching a location then get bookmarked.
2. Update bookmark details
User can update the bookmark details if he/she want to change.

FR 7
Reminder
1 supply bookmarked location
A location a user shall enter to the reminder must be bookmarked location.
2 set reminder details
User shall provide reminder details (description or name)
3 Set Alarm
User should set time and date to set the reminder alarm.
4 alarm
The system must remind the user about the description and location at the specified alarm date
and time.

FR 8
Make group
1 Group info
Input group name, description
Add friends to the group
2 Delete group
The one who creates the group can delete it.
Deactivate group
Remove friends from group
3 Update group
Edit group info
4 Inquire group
Search for members of a group
View group info
View group members

FR 9
Invite friend
1 Group name selection
The user firstly must have the group to be invited in.
2 List friends
The friend to be invited must be selected.
3 Send invitation

Once having list of users, user can send the group invitation to them. Or he/she can send them
individually.
4 Notify user
After the user send the invitation to users, there must be an invitation notification on the users
so that they will notice and respond.

FR 10
Make event
1Event info input
User should supply event info to create an event. Event information are Event Name, Event
Description, and photo which describes the event.
2Event info delete
User can delete the event which is created by them.
Admin can also delete if it is not valid event.
3Event info update
User can update event info after creation.
4Event info inquiry
User can see the event and its info later by inquiring.

FR 11
Share event
1 event input
User must have event to be share.
2 Share event

The user can share the event to friends, group, or selected users. also the users can send to other
friends, users who they want to be participate.
3 notify
Once the user send the event to users, there must be an event notification on the users so that
they will notice and respond or get announced.

3.2 User Interface Requirements

This section contains all of the functional and quality requirements of the system. It gives a
detailed description of the system and all its features.
Provides a detailed description of all inputs into and outputs from the system. It also gives a
description of the hardware, software and communication interfaces and provides basic
prototypes of the user interface.

3.3 Usability
This application used because a lot of people are getting stack when they need to find a
specific places, services or something they want so, they can get search what they want
through this application.
Users can easily get where they are currently.
Find services around
Offline and online search options
Users can easily switch between Amharic and English according their need
Easily familiarized with the app how they can use it.
Search through sub city

3.4 Performance
The search feature should be prominent and easy to find for the user. The results displayed in
the list view should be user friendly and easy to understand. Selecting an element in the result

list should only take one click. 5 second is about the limit for having the user feel that the
system is reacting instantaneously, meaning that no special feedback is necessary except to
display the result. 95% of the operations carried out in the system must respond within 5
seconds. The system has to support 100 concurrent users.

3.4.1 Capacity
The application can support around 1000 users at one time with a little load. It needs network
connection in order to users get full information they need such as map view and need memory
capacity in order to view.

3.4.2 Availability
The hours of operations
MUST: No more than 5 seconds 100% of the time.
WISH: No more than 2 second 100% of the time.
Addis Mapper will cover a geographic area of Addis Ababa city.
the degree to which AM operates without failure under conditions of good network connection and a
GPS supporting device will be high given the app version and necessary updates are get updated. The
applications mean time between failures shall be at least 1 year. The scope of failure is localized to
functional area, external actor or an API.
3.4.3 Latency
This application will use best libraries in order to view information as fast as possible. It needs little
time in order to get information to user but it need phone with good performance in order to best fast
load.

3.5 Manageability/Maintainability

3.5.1 Monitoring

There will be service owner authentication for the delivery of exact information of the service
on the map point of that location. Failure conditions may be occurred when the GPS device
on the phone get failed or network failure happened, or by any case the Google map API
failed.

Our application needs enough internet connection in order to function properly since
application needs to communicate with GPS satellite through the phones interaction System.
It developed by minimizing failure conditions and sends an alarm to the developers if an error
occurs.
3.5.2 Maintenance
The system is modularized as user, admin and owner classes of development. And since it is
a mobile based and web based app to be, all subsystems will be managed and maintained
easily. basically the program development is going to be object oriented so that each entity is
encapsulated as object and easily apply the maintenance to the class corresponding.
The application is developed to be maintaining it easily since it give error occurrence
message to the developers and they can take action. It is not going to end at the first version
but there are some features that are going to be extended to the next version. We are going to
prepare different ways in order to make the application as much as good for users. One of the
great aspects when your software goes public is that you get more feedback.
If something is missing or not working as expected, your customers will tell you faster than
you can fix or implement it.
3.5.2 Operations
Only the admin can verify and manipulate the map locations of all the services to be on the
search including the database on the web portal of the system. The service owner have no full
access and privilege to edit his own service location information. The user only can search
the targeted location based on the search categories and access the info related to that service.
The system has no very crucial privacy issues related with the users or with the system itself
and no much need of encryption is going to be used.
This application doesnt need any special operations users have to do. What users only need
to do is just open internet connection during the application usage and the application have
three options:
GETME: this points the user where he/she is and some known places, services
around.

ONLINE SEARCH: users can search service locations they want using network
connection and can see their map location. They can get information they want like on
the services, historical places through his/her phone easily.
OFFLINE SEARCH: this operation comprises users to search some specific known
areas and sub city level module of Addis Ababa city, users can get information special
places, services in specific sub city offline.
Routing and travel.
Event sharing.
Making group.
Location based reminder.
The application is always applicable as long as users download it and install in to their
phone.
3.6 System Interface/Integration
This system will consist of two parts: one mobile application and one web portal. The mobile
application will be used to find restaurants and view information about them while the web
portal will be used for managing the information about the restaurants and the system as a
whole.

The mobile application will need to communicate to a GPS application within the mobile
phone, which in turn communicates with a physical GPS device to find the location of the
user, see Figure 1. The GPS will provide the mobile application with locations of both the
user and the services and the distance between them, but it will also provide maps and the
functionality to display the applications data on the map. The functionality provided by
the GPS will be embedded into the application in order for the user to be able to use the
functions in the application in a seamlessly manner.
Since this is a data-centric product it will need somewhere to store the data. For that, a
database will be used. Both the mobile application and web portal will communicate with
the database, however in slightly different ways. The mobile application will only use the
database to get data while the web portal will also add and modify data. All of the
database communication will go over the Internet.

3.6.1 Hardware and Network Interface

Since neither the mobile application nor the web portal have any designated hardware, it does
not have any direct hardware interfaces. The physical GPS is managed by the GPS
application in the mobile phone and the hardware connection to the database server is
managed by the underlying operating system on the mobile phone and the web server.
The network communication between the different parts of the system is important since they
depend on each other. However, in what way the communication is achieved is not important
for the system and is therefore handled by the underlying operating systems for both the
mobile application and the web portal.
3.6.2 System Interfaces
Data is interfaced between the users mobile interface and the web portal where most of the
operations are done in. data of one location information is uploaded from the service owners
page on the mobile application to the web portal.
When the user get to search a service location, the mobile app identifies where he is and
search around based on search categories fetching the saved service locations around on the
database of the system on the web portal.

3.7 Security

3.7.1 Protection
Only the admin can verify and manipulate the map locations of all the services to be on the
search including the database on the web portal of the system. The service owners have no
full access and privilege to edit his own service location information. The user only can
search the targeted location based on the search categories and access the info related to that
service. The system has no very crucial privacy issues related with the users or with the
system itself and no much need of encryption is going to be used. But the communication
between owners and the database is going to be security in mind.

3.7.2 Authorization and Authentication

No actual login operation is going to have for all users of the real system. The admin and the
service owners will have so that the admin verifies when the service owner tries to pin and
edit his service location information.
3.8 Data Management
Data management is the most important part of our application in order to function properly
and as we expected. Since the data exchange between the application and Google map API
must handled properly.
The communication between the web portal & data base must managed in secure way.

3.9 Standard Compliance

Login account to be verified (authentication) is one standard we use and feedback control on
the site we use as portal. Detection configuration problems on the agent, Configuration Best
Practices of MySQL Database are some standards we use from the existing standards. The
interfacing our logic with the Google map API should be on standard as well.
3.10

Portability

The system will be portable on both android OS mobile application and the site on any host
OS. The system should operate the same regardless of operating systems, networks, and
development or production environments. The proven languages alongside with the
development are Php, java, android, JavaScript, MySQL.

Chapter 2 Functional Requirements

This is the systems function list hierarchy.
Req no

BR-1

Req name

Function list

Req contents

Main function

Major function

Function

Unit function

E-Mapper

User info

Register

Input user details

Validate details
sign up
User basic info input
User authentication

login

Friend relation

Search friend

Location

Search location

Routing

Bookmark

Add friend request

Confirm request
Unfriend
Search friend
|User name input
User info inquiry
Input search option
Input search keyword
Location inquiry
Location info input
Make route path
Travel detail input
Update travel
Location info input
Update location info

Group

Remind

Location info input

Save location info
Set reminder

Make Group

Group info input

Group info delete
Group info update
Group info inquire
Group name selection
List friends
Send invitation
Notify user
Event info input
Event info delete
Event info update
Event info inquiry
Share option input
Share event
notify

Invite Friend

Event

make event

Share event

2. Functional Requirements
The following requirements are functional requirements of the system.
Req .no

FR-1

Req name

Registration

Req contents

1. Input user details

- User should input first name, last name, email, password and phone number
- Password should include uppercase letter, lowercase and alphanumeric
- User should confirm the password
2 validate users
The system should validate the user details so that supply right input.
3 validate
The system should register the user after correct validation.
Input data
Registration details

Data
information

Output data

Registration info

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

function

Req .no

FR2

Req name

Log in

Req contents

1 User basic info input

user should email and password to access the system
Optionally he/she can use their username.
2 Authentication
Authenticated if he/she is the right user.
Carefully designed to prevent from sql injection.

Data
information

Input data

User credentials

Output data

Text value saved to DB

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

Function

Performance

Req .no

FR3

Req name

Friend relation

Req contents

1.Add
User can add another user as friend
2.Unfriend
Users can quit friendship if he/she want by unfriending.
3.Notify
The System should include request notifications to the user
4.Confirm request
User can confirm or ignore to any request sent to him/her.
5 Search friend
A user can search a friend or other user.
Input data

Performance

Friend

Quality

Quality

Interface

Interface

Data Operation

Data Operation

constraints

constraints

Data
information

Output data

Friend ship

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

Function

Performance

Req .no

FR 4

Req name

Search Location

Req contents

1 Input search option

User can search on the search category (health, bank, transport, food.).
2 Input search keyword
User must write the location/POI name, street, city or location coordinate
values(latitude and longitude) on the search box to search that on map
3 Location inquiry
The system should find a location with that name and show it/them on the map with
pin symbol under it.
Input data
Location name

Data
information

Output data

Quality Interface

Data Operation

Constraints

Location

In/out type
File type

ILF(Location info DB)

Application
name

EMapper location finder and event sharing

Related
requirements

function

Performance

Req .no

FR 5

Quality

Interface

Data Operation

constraints

Req name

Routing

Req contents

1 Location info input

User should provide source and destination location.
2 Make route path
The system shall make the route path using the source and destination.
3 Travel detail input
User can give to the system travel option(car or bicycle) he/she want.
4 Update travel
When the user travel to the destination he/she refresh the system and the system
shall show the updated path, time and distance he/she left.
Input data
Source and destination location

Data
information

Output data

Route info

In/out type
File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

function

Performance

Req .no

FR 6

Req name

Bookmark

Req contents

1. Bookmark details input

Pin the desired location to be bookmarked and supply details (bookmark name and
description)
The bookmark might come after searching a location then get bookmarked.
2. Update bookmark details
User can update the bookmark details if he/she want to change.
Input data
Location and details

Data
information

Quality

Interface

Data Operation

Output data

Bookmark url

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

constraints

Related
requirements

function

Req .no

FR 7

Req name

Reminder

Req contents

1 supply bookmarked location

A location a user shall enter to the reminder must be bookmarked location.
2 set reminder details
User shall provide reminder details (description or name)
3 Set Alarm
User should set time and date to set the reminder alarm.
4 alarm
The system must remind the user about the description and location at the specified
alarm date and time.
Input data
Location and description

Data
information

Performance

Quality

Interface

Data Operation

Output data

Alarming info

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

Function

Performance

Req .no

FR 8

Req name

Make group

Quality Interface

Req contents
1.Group info
Input group name, description
Add friends to the group
2.Delete group
The one who creates the group can delete it.
Deactivate group
Remove friends from group
3.update group
Edit group info

Data Operation

constraints

Constraints

4.inquire group
Search for members of a group
View group info
View group members
Data
information

Input data

Group info

Output data

Group info

In/out type

EI

File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

Function

Performance

Req .no

FR 9

Req name

Invite friend

Req contents

1 Group name selection

The user firstly must have the group to be invited in.
2 List friends
The friend to be invited must be selected.
3 Send invitation
Once having list of users, user can send the group invitation to them. Or he/she can
send them individually.
4 Notify user
After the user send the invitation to users, there must be an invitation notification
on the users so that they will notice and respond.
Input data
Group info

Data
information

Output data

Quality Interface

Data Operation

Group

In/out type
File type

ILF

Application
name

EMapper location finder and event sharing

Constraints

Related
requirements

Function

Req .no

FR 10

0Req name

Make event

Req contents

1Event info input

User should supply event info to create an event. Event information are
EventName, EventDescription, and photo which describes the event.
2Event info delete
User can delete the event which is created by them.
Admin can also delete if it is not valid event.
3Event info update
User can update event info after creation.
4Event info inquiry
User can see the event and its info later by inquiring.
Input data
Event info

Data
information

Output data

Performance

Quality

Interface

Data Operation

constraints

Event

In/out type
File type

ILF

Application
name

EMapper location finder and event sharing

Related
requirements

function

Performance

Req .no

FR 11

Req name

Share event

Req contents

1 event input
User must have event to be share.
2 Share event
The user can share the event to friends, group, or selected users. also the users can
send to other friends, users who they want to be participate.

Quality

Interface

Data Operation

constraints

Data
information

3 notify
Once the user send the event to users, there must be an event notification on the
users so that they will notice and respond or get announced.
Input data
Event info
Output data

Event

In/out type

Related
requirements

File type

ILF

Application
name

EMapper location finder and event sharing

function

Performance

Quality

Interface

Data Operation

constraints

Use Case Diagram

Fig 1 authentication use case.

Use case No.

Use case name

Use case

Registration
This use case describes how a user/admin registers into the EMapper app System.

description
Use case flow

1.a user shall enter basic info(username, first name, last name, email,
password) to proceed to get registered.
2.user checks the checkbox to agree the terms of use and privacy policy
of EMapper to sign up.
3. if the email of the user is already in use the system should ask the user
to enter another email.
4 finally the user get registered and should confirm on the email address
sent from the system.
.

Use case No.

Use case name

Use case
Description
Use case flow

Log in
This use case describes how a user/admin logs into the EMapper app
System.
1 The system should request that the user/admin to enter his/her email and
password on the home page.
2 The user/admin enters his/her email and password.
3 The system validates the entered email and password and logs the
user/admin into the system.
4 If in the Basic Flow the user/admin enters an invalid email and/or password,
the system displays an error message. The user/admin can choose to either return
to the beginning of the Basic Flow or cancel the login, at which point the use
case ends.
5 he/she can possibly skip the log in use case.

Fig 2 location find use case.

Use case No.

Use case name

Use case
Description
Use case flow

Search Location
This use case describes how a user searches location/POI with the
EMapper app.
1 a user supplies a location/POI name on the search box, giving the
location coordinate values or writing the street name.
2 the system should show the list view of categories below the search box
to the user to select from.
3 the system should show error of no result if it is invalid keyword.
4 up on the search the user can bookmark that or another specific selected
location by tapping it for couple of seconds.

Use case No.

Use case name

Use case
Description
Use case flow

Share Location
This use case describes how a user shares location/POI with the EMapper
app.
1 the user shall have the location to be shared first from the search result
or from bookmarked locations
2 the user should select to whom the location is going to be shared.
3 the system shall provide the location is going to be shared with. i.e
facebook, gmail, hangout, viber, whatsapp or twitter.

Use case No.

Use case name

Use case
Description
Use case flow

Bookmark Location
This use case describes how a user bookmarks location/POI with the
EMapper app.
1 Up on the search the user can bookmark that or another specific selected
location.
2 The user shall provide the basic bookmark details (bookmark name &
description).

Ucd 3 Route

Fig 3 route use case.

Use case No.

Use case name

Use case
Description
Use case flow

Route path
This use case describes how a user/admin routes from source to
destination on the map with in the EMapper app.
1 a user can view the route path from source to destination locations
entered by him/her.
2 the system gets the destination from the source and shows the path

Use case No.

Use case name

Use case
Description
Use case flow

Travel
This use case describes how a user travels from source to destination on
the map with in the EMapper app.
2 the system gets the destination from the source and shows the path and
the user can have a travel options to select(foot, bicycle & car) and have
to select one.
3 the system shall show the distance and calculated time to travel with
different travel rides.

Use case No.

Use case name

Use case
Description

Update travel
This use case describes how a user/system updates travel details from
source to destination on the map with in the EMapper app.

Use case flow

1 The user can refresh the travel to update the travel details.
2 the system must show updated the travel details of the route path after
the user refresh it.

Fig 4 user relation use case.

Use case No.

Use case name

Use case
Description
Use case flow

Add user
This use case describes how a user adds a user as friend on the EMapper
app.
1 a user can search his/her friend entering user name of to be searched
user.
2 this use case may followed from to add user or to share location/event.
3 the system should return a list of users by that user name.
4 the user can select the user to go with it.

Use case No.

10

Use case name

Use case
Description
Use case flow

Confirm a user
This use case describes how a user confirms to a user request.

Use case No.

11

Use case name

Unfriend

Use case
Description
Use case flow

This use case describes how a user can unfriend a friend who doesnt want
him/her no longer as friend.
1 a user can select/search a friend from his friend list to be unfriended.
2 he/she shall tap the unfriend button to unfriend him without the his
permission.
3 the system must update that the two users are not friends.

Use case No.

12

1 The user must go to the notification page and select the user to be
confirmed
2 The user shall accept the user tapping the confirm button on it to confirm
the request.
3 The system must update that the two are friends.

Use case name

Use case
Description
Use case flow

Search nearby user/friend

This use case describes how a user searches nearby friend or user from his
group on the EMapper app.
1 a user shall tap the find nearby button to search nearby user.
2 the system must search and display all nearby friends or users from his
group with order of their distance from the user.

Use case No.

13

Use case name

Search User

Use case
Description
Use case flow

This use case describes how a user searches users on the EMapper app.

Use case No.

14

Use case name

Use case
Description
Use case flow

Edit profile
This use case describes how a user can edit his profile.

1 a user can search his/her friend entering user name of to be searched

user.
2 the system should return a list of users by that user name.

1 a user must be on his profile page to edit his/her detail information.

2 he/she can edit his/her detail info on each profile name (profile name
profile picture, work)
3 the system must update the profile updating the users profile on the
database.

Fig 5 Group management use case.

Use case No.

15

Use case name

Use case
Description
Use case flow

Create group
This use case describes how a user creates group.

Use case No.

16

Use case name

Use case
Description

Delete group
This use case describes how a user delete a group he/she created.

1 a user can create group tapping the create group button on the menu.
2 he/she must provide the group detail info (group name, group type &
description).
3 after finishing entering the details he/she must tap create button.
4 the system must update the database and show the created group back
to the user.

Use case flow

1 a user should select a group to be deleted.

2 he/she delete the group tapping the delete button on it.
3 the system shall return a message to the user that tells the group is
deleted.

Use case No.

17

Use case name

Update group

Use case
Description
Use case flow

This use case describes how a user updates group detail.

Use case No.

18

Use case name

Use case
Description
Use case flow

Invite group
This use case describes how a user invites a group to users.

Use case No.

19

Use case name

Use case
Description
Use case flow

Inquire group
This use case describes how a user inquires a group details.

1 a user can post/add events or update group detail (name and description).
2 the system must update the group details on the database including the
number of members on the group .

1 a user must specify the users to be invited.

2 he/she can invite them of as a group or friends the group selected.
3 the system should send the invitation to each users and they must be
notified.
4 users can accept or ignore the invitation.
5 when the users accept the invitation the system should update the group
members on the database.

1 a user shall inquire group details.

2 admin can also inquire group info for some purposes.
2 the system should provide the details querying the database to the user.

Fig 6 event management use case.

Use case No.

20

Use case name

Use case
Description
Use case flow

Create event
This use case describes how a user creates event.

Use case No.

21

Use case name

Use case
Description

Delete event
This use case describes how a user deletes created event.

1 A user can create an event giving event name on the name text box,
event description on description text area and upload photo that describes
the event and the location where the event is going to be conducted.
2 the system must return that the event is created and insert it to the event
database.

Use case flow

1 A user can delete already created events if they are no longer usable.
2 the system should update the database to delete the group from the
system.

Use case No.

22

Use case name

Use case
Description
Use case flow

Update event
This use case describes how a user updates event details.

Use case No.

23

Use case name

Use case
Description
Use case flow

Share event
This use case describes how a user can share an event.

Use case No.

24

Use case name

Inquire event info

Use case
Description
Use case flow

This use case describes how a user inquires event info

1 a user who created the event can update the event details.
2 the system shall update the event on the database and on all the users
who get the event.

1 a user can share an event who created or he/she is on by selecting the

users.
2 he/she can share the event tapping the share event button.
3 the system should notify the users that they get the event and update the
database.

1 A user can inquire event details to see what is in it.

2 the system shall query the event info and details on the database and
return or show to the user.

Fig 7 Reminder use case.

Use case No.

25

Use case name

Use case
Description
Use case flow

Add bookmarked location

This use case describes add a bookmarked location to the reminder.

Use case No.

26

Use case name

Use case
Description
Use case flow

Update bookmark details

This use case describes how a user updates bookmark details

1 since the locations to be supplied to the reminder should be bookmarked

locations user shall add bookmarked location to the reminder.
2 the system shall set the location is that the added bookmarked location

1 A user can update or change the bookmarked location details.

2 the system should update the location details on the reminder.

Use case No.

27

Use case name

Use case
Description
Use case flow

Add reminder details

This use case describes how a user adds reminder details.

Use case No.

28

Use case name

Use case
Description
Use case flow

Update reminder details

This use case describes how a user updates reminder details.

1 a user shall enter the reminder details (reminder description) and set time
and date.
2 the system should set the details so that it will be showed on the specified
time and date.

1 A user can change or update the reminder details if he/she want to

change.
2 the system shall update the details and show the updated details.

2 analysis models
This is an activity diagram for all the account related activities in the whole system.

Fig 9 activity diagram of the account related activities on the system.

This is an activity diagram for all account unrelated activities in the whole system.

Fig 10 activity diagram for account related activities on the system.

Sequence diagram of each use scenarios are designed below.

Registration sequence diagram

Fig 11 Registration sequence diagram.

Log in sequence diagram

Fig 12 Login sequence diagram.

Fig 13 search location sequence diagram.

Fig 14 share location sequence diagram.

Fig 15 bookmarking sequence diagram.

Fig 16 route path location sequence diagram.

Fig 17 travel sequence diagram.

Fig 18 friend sequence diagram.

Fig 19 Search nearby friend sequence diagram.

Fig 20 Edit profile sequence diagram.

Fig 21 Group mgmt sequence diagram.

Fig 22 Invite group sequence diagram.

Fig 23 Event mgmt sequence diagram.

Fig 24 event share sequence diagram.

Fig 25 Bookmarked location to reminder sequence diagram.

Fig 26 update bookmark sequence diagram.

Fig 27 add/set reminder sequence diagram.

Fig 28 update reminder details sequence diagram.

CHAPTER-3 SYSTEM DESIGN

1. Deployment diagram
The deployment diagram of our app is like in the figure below.

Fig 29 deployment diagram of E-mapper design

2. Architectural design

Fig 30 class diagram of E-Mapper app design.

3. User Interface Design

The following figures will show the apps basic user interfaces that a user communicate
with. This includes sample screen images, GUI standards and some layouts to appear on
every screen, keyboard shortcuts and error message display standards.

Fig 31 The first page of E-Mapper app UI design.

1. By default Ethiopia map comes out you can zoom in to find specific areas or locations.

Use your fingers to zoom.

Double tab the screen
Click on + icon you can make it visible in Menu setting.

2. To determine your location, tab the Geolocation button at the bottom left corner.
3. To activate GPS, enable location services in your device.
4. If you have difficulty determining your location, enable Google location reporting
5. If you have difficulty determining your location, enable (disable, if enabled) use Google
play services in app settings, then restart your phone.
6. tap the star to add location to bookmark.

Route interface

Fig 32 The route page of E-Mapper app UI design.

To start following the route tab Go!, distance to your destination will be displayed.
If you want to stop following the route, tap the cross icon.

Search interface
Tab the search icon,

The first time when you tab on the search field it shows as follows:

Fig 33 The search UI design of E-Mapper .

You can search using any of the following:

Name of the place

Keyword
Coordinate
Address(city, street)

Where do I share my location

Choose the share button at the top of the application,

And share as a map or kml file this depends on the app which we are going to share with,

Fig 34 The location share UI design of E-Mapper.

Bookmark?
Choose the star button on the bottom of the map to bookmark the desired location

You can send your book mark via text message, email or copy and paste the link in another
app. Users can also use the app to involve in events, groups but they need to have account to
do such activities. user need to login to create group and event and access others posted by
another user.

Login page of users

Fig 35 Sign in UI design of E-Mapper.

If they dont have email and password, they need to register with the following specification

Fig 36 registration UI design of E-Mapper.

Event showing user interface

User can see different events in their city defined by location based and categorized with
specific name example music, film, sports etc. sample events are designed as follows:

Fig 37 event UI design of E-Mapper.

What E-Mappers group looks like

Fig 38 Group UI design of E-Mapper.

This is what the reminder page looks like.

Fig 39 reminder UI design of E-Mapper.

4. Data structure design

The following diagram is the entity relationship diagram of the systems database data
structure design. There will be 4 entities (users, group, event and friends) each with their
purely designed attributes and interactions or relationships among the entities.

Fig 40 ER diagram design.

5. Algorithm Design

5.1 Popularity algorithm

p = (p + t) / 2

Here, p is the popularity value stored in the database and t is the current timestamp.
When an item is first created, p must be initialized. There are two possible initialization
methods:
1. Initialize p with the current timestamp t
2. Initialize p with the average of all p values in the database
Our system is going to use this algorithm on the event filtering a user give more rates.

5.2 Recommendation algorithm

We shall use this algorithm on the event filtering a user is favorite of, or number of search
an event of that type
The algorithm generates recommendations based on a few customers who are most
similar to the user. It can measure the similarity of two customers, A and B, in various
ways; a common method is to measure the cosine of the angle between the two vectors:

The algorithm can select recommendations from the similar customers items using
various methods as well, a common technique is to rank each item according to how
many similar customers purchased it.
For each event in user, u1
For each event C who searches i1
For each event i2 purchased by
user C
Record that a user searched 11
and i2
For each item i2
Compute the similarity between i1 and i2
.

6. Test Design

Our E-Mapper apps test design have a test plan that test each use case activity
whether it works fine or not. The nonfunctional requirement test case are going also
included.

Fig 41 The test plan of the whole system.