Hotel Reservation Android App Report

Addis Ababa University
Addis Ababa Institute of Technology (AAIT)

Faculty of Electrical and Computer Engineering
Department of Computer Engineering
Software Engineering (ECEG-4201) Course Project
Semester 1, Year 2009 EC / 2016 GC
Report 2: System Architecture & Design Report
Hotel Reservation Android App
For
Hotel Managers
Submitted by:
Biruk Tesfaw
ATR/4514/05
Bisratemichael Moges ATR/6015/05

Daniel G/Yohannes
ATR/3676/05
Dawit Samuel
ATR/1378/05
Yared Abera
ENR/1849/04
Submitted to:
Sahilu Wendeson
29 /12 /2016
Addis Ababa
Ethiopia
Software Engineering (ECEG 4201), Year 2009 EC016 GC
Individual Contributions Breakdown

Responsibility
Biruk
Tesfaw
Part 1: Interaction
33%
Diagram
Part 2: Class
Diagram
Team Members and Contribution

Bisratemicha Daniel
Dawit
G/Yohannes
Samuel
el Moges
33%
34%
50%
Yared
Abera
50%
Part 3: System
Architecture and
design
30%
70%
Part 4: User
interface
20%
80%
Part 5: Testing
Design
Part 6: Project
Management
33%
67%
50%
50%
Table of contents
Individual Contributions Breakdown............................................................................ i
Table of figures........................................................................................................... iii
List of tables.............................................................................................................. iv
1.
2.
Interaction Diagram............................................................................................. 1
1.1.
Sequence Diagrams....................................................................................... 1
1.2.
Design Principles............................................................................................ 9
Class Diagram.................................................................................................... 10
2.1.
3.
Description................................................................................................... 11
System Architecture........................................................................................... 12
3.1.
Persistent Data Storage...............................................................................13
3.2.
Concurrency................................................................................................. 13
4.
Testing Design.................................................................................................... 13
5.
Project Management and Plan of Work...............................................................19
6.
5.1.
Merging Contributions from Individual Members.........................................19
5.2.
Project coordination and progress report.....................................................19
5.3.
Plan of Work................................................................................................. 19
5.4.
Breakdowns For responsibilities...................................................................20
References......................................................................................................... 21
Table of figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1:UC1............................................................................................................... 1
2:UC2............................................................................................................... 2
3: UC3.............................................................................................................. 3
4: UC 4 & UC 5................................................................................................. 4
5: UC 6............................................................................................................. 5
6: UC 8............................................................................................................. 6
7: UC 9............................................................................................................. 7
8: UC 10........................................................................................................... 8
9: Class Diagram............................................................................................ 10
10: Architecture For The Web App.................................................................12
11: Client-Server Architecture........................................................................12
12: Plan of work............................................................................................. 20
List of tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1: user authentication..................................................................................... 13
2: Display list on app....................................................................................... 14
3: Search for hotels......................................................................................... 14
4:Display current data..................................................................................... 15
5: Book a room................................................................................................ 15
6:Connect multiple cell phones.......................................................................16
7: Write review................................................................................................ 16
8: Add hotel data............................................................................................. 17
9:Edit hotel data.............................................................................................. 17
10: Manage profile.......................................................................................... 18
11: View Hotels Data....................................................................................... 18
1. Interaction Diagram
1.1. Sequence Diagrams
UC 1
Figure 1:UC1
Description
The above interaction diagram is for Use case 1 Search info. The user inputs the
search parameters. The search filter filters out wrong characters and wrong inputs.
The system or database searches for the desired hotels and displays the results
from the best much down.
System Specification Document |Biruk ATR/4514/05, Bisratemichael

ATR/6015/05, Daniel ATR/3676/05, Dawit ATR/1378/05, Yared ATR/1849/05
Hotel Reservation App
Addis Ababa, Ethiopia
1 | Page
UC2
Figure 2:UC2
Description
The above interaction diagram is for Use case 2 Signup. User clicks on sign up. Then
user enters personal information on the signup form. If the entered information is
incorrect displays error message. If information is valid displays user profile created.

2 | Page
UC 3
Figure 3: UC3
Description
The above interaction diagram is for Use case 3 give feedback. The user opens the
leave review dialogue box. If the comments or review is longer than the allowed
number of characters it returns invalid comment to the user. If the comment is valid

3 | Page
UC 4 &UC 5
Figure 4: UC 4 & UC 5
Description
The above interaction diagram is for Use case 4 Online Payment and Use case 5
Book rooms. User logs in to page. System authenticates validity of the user. If the
user is valid the user moves on to book rooms. Check balance checks if the user has
sufficient balance. If the user has sufficient balance the user books the room and
GUI displays room booked. But if user doesnt have sufficient balance it displays
insufficient balance.

4 | Page

UC 6
Figure 5: UC 6
Description
The above interaction diagram is for Use case 6 Edit Account. User logs into
account. User gets authenticated. If user is valid, user edits personal information
such as names and bank account or paying information. The system then displays
updated information.

5 | Page

UC 8
Figure 6: UC 8
Description
The above interaction diagram is for Use case 8 Update Profile. Hotel admin logs in
to page. The information gets authenticated. If the submitted information is invalid
system displays error message. If user input is correct, hotel admin updates
information of their hotel. The system then displays successful information.

6 | Page

UC 9
Figure 7: UC 9
Description
The above interaction diagram is for Use case 9 browse information. Hotel admin
logs into page using the correct information or username and password. If
information submitted is incorrect system displays error message. After user gets
authenticated, user searches or inputs for specific information concerning their
hotel. System displays the results or information.

7 | Page
UC 10
Figure 8: UC 10
Description
The above interaction diagram is for Use case 10 Authorize Hotels. System admin
logs in to system. User gets authenticated. System admin then authorizes or adds
new hotels to the system. If successful system the displays the successful
information.

8 | Page
1.2. Design Principles

We will have In-app search feature amplifies the usability of an app for the end
users. More intuitive is the in-app search, better is the experience that a user
derives from the app. There are predefined proven search patterns that make the
in-app search feature a treat for the end-users. Which will apply use case 7.
We also applied the interface segregation principle rule. This principle teaches us
to take care of how we write our interfaces. When we write our interfaces we should
take care to add only methods that should be there. If we add methods that should
not be there the classes implementing the interface will have to implement those
methods as well. Therefore we will be having this in mind.

9 | Page
2. Class Diagram
Figure 9: Class Diagram

10 | P a g e
2.1. Description
User user class is a class that parents customer and hotel manager classes. It has
the string attributes name, username and password. The user class employs the
method updateAccount() which allows the user to make changes to their account
this method is implemented both in hotel manager and customer classes.
Customer has the method search() which runs searches and displays data, it also
has the method make reservation which would call other functions related to
reservations. Customer has methods to implement viewing and writing reviews.
Hotel Admin has methods
manageRoomType() - edits the type of room
viewReservations() retrieves reservation data about the hotel in question
viewCustomerInfo() retrieves information of customer of the hotel the hotel
manager is responsible for
manageServices() adds services and offers to hotels attributes
offers() allows hotel manager to make offers to customers
Hotel has attributes keeping track of the hotels address, name and location
(possibly coordinates) and parents rooms which connect via its id.
Room has attributes pertaining to room #, type of room, price of booking the
room and whether or not it allows smoking. It employs the method getAvailability()
which returns a Boolean describing current status of the room
Reservation has attributes that keep track of check-in time, check-out time, the
customers id and the total cost. Reservation class employs a method reservation
status() which returns true if reservation process goes through flawlessly meaning
no flags on payment.
System Admin has user name and password for authentication and has methods
allowing for addition and removal of hotels and hotel managers.
Payment has the attribute payment type declaring the type of payment to be
performed and attribute payment status holding the value of successful payment.

11 | P a g e
3. System Architecture
The architecture that we use for the web app is the three tier architecture, the
tiers are the presentation tier, the business tier & the data tier. The role of the
presentation tier is providing an interface that the user can interact with where as
the Business tier is where the main business logic exists .The data tier which is
responsible for interacting with a database, so data persistence is executed in this
tier.
The advantage of using three tier architecture is separation of concern. The
presentation tier can be changed without changing the other tiers similarly the
business logic can change without affecting the presentation tier, so this separation
into components will help the division of tasks even further, aids in maintenance of
the system and prompts scalability and extensibility.
Figure 10: Architecture For The Web App
Finally our web app is also a Restful web service meaning it provides access
to any device irrespective of its platform. In the REST architectural style, every
piece of information is a resource, and these resources are addressed using Uniform
Resource Identifiers (URIs), typically links on the Web. The resources are acted on
by using a set of simple, well-defined operations. The REST client-server
architectural style is designed to exchange representations of these resources using
a defined interface and protocol. These principles encourage RESTful applications to
be simple and lightweight, and to have high performance.

12 | P a g e
Figure 11: Client-Server Architecture
3.1. Persistent Data Storage

The main persistent storage solution for our project is the MySQL relational
database. in these database all the relevant details of user information hotel details
are stored. the android app also utilizes the SQLite local relational database, the
database primary is used for storing cached network data, storing them in the
database provides quick access.
3.2. Concurrency
In android the main thread is the ui thread it is in this thread all views are drawn so
any task that takes longer time to complete like network I/o file I/o will block the
main thread and as a result causes hang-up and freeze up to the ui . Therefore in
order for the ui to be fluid and responsive this tasks should run on separate
background thread.
Hardware Requirement
android phone running kitkat or any newer version

Internet connection
4. Testing Design
user authentication
Test covers : security
Assumption: Hotel manager is trying to log in to his/her account to view or
make changes to their hotel.

13 | P a g e
Unit Testing
Steps :
Hotel manager enters user authentication page
Hotel manager inputs user id and pass
Expected : if user id and pass check out Hotel manager gets access to next
page
Fails if :
System doesnt allow access with correct id and pass entered
System allows access with fake credentials
Table 1: user authentication
Display list on app

Test covers : user interface
Assumption : user is trying to browse through a list of hotels on their device
and have navigated to the right page
Integration Testing
Steps :
User runs app
Expected : app lists a tabulated list of hotels with details attached
Fails if :
App is unable to retrieve a list
Table 2: Display list on app
Search for hotels

Assumption: user is trying to run a search for hotels has navigated to the right
page
Unit Testing
Steps :
Fill in search parameters

14 | P a g e
Press search
Expected : app runs search, retrieves data from the database and displays a
list of hotels matching search parameters
Fails if :
System cant run search
System presents search results not matching parameters
Table 3: Search for hotels

15 | P a g e
Display current data

Test covers : functionality
Assumption : user is trying to view data of a hotel
Functional Testing
Steps :
Select hotel to view data
Expected : user should view up-to-date information on the page they are
currently viewing, like how many rooms available, any price changes and any
other change to the hotel should propagate to users apps
Fails if :
App doesnt show current data
App doesnt show changes when page is reloaded
Table 4:Display current data
Book a room
Assumption : user has chosen a room and is trying to book online
Functional Testing
Steps :
Enter payment information
Confirm payment
Expected : once user enters payment data and payment comes through room
is set to be booked and database updated
Fails if :
All affected members of database are not updated
Table 5: Book a room
Connect multiple cell phones

16 | P a g e
Test covers : scalability

Assumption : multiple users of the app are trying to use it at the same time
Integration Testing
Steps :
Run app on multiple cell phones at the same time
Expected : all devices are able to run the app and access the system at the
same time
Fails if :
System doesnt support multiple access
Changes are not immediately updated
Table 6:Connect multiple cell phones
Write review
Assumption : user wants to post a review about a hotel or about the app itself
and has navigated to the right page to do that
Unit Testing
Steps :
Write comment and post
Expected : review is added and available for viewing by others
Fails if :
Review is not posted on site
Table 7: Write review

17 | P a g e
Add hotel data

Assumption : Hotel manager has logged on to account and is trying to set
features of their hotel
Integration Testing
Steps :
Hotel manager enters the hotels data (pictures, location, )
Presses button to set data
Expected : data is uploaded to database
Fails if :
Data is not there on next open
Table 8: Add hotel data
Edit hotel data

Assumption : Hotel manager has logged in and has navigated to the right
place to make changes to their hotel
Functional Testing
Steps :
Hotel manager updates data
Confirms changes
Expected : database is updated making if update doesnt cause current data
to be corrupted
Fails if :
Changes are ignored without stating reason
Table 9:Edit hotel data

18 | P a g e
Manage profile
Assumption : Hotel manager wants to change user name or pass and has
navigated to the right page
Unit Testing
Steps :
Enter new information
Confirm change with old password
Expected : user name and pass get updated and functional on next log in
Fails if :
System doesnt allow login with new credentials
old pass and username still work
Table 10: Manage profile
View hotels data

Assumption : Hotel manager has inserted and updated data about their hotel
and want to view current data about their hotel
Unit Testing
Steps :
Hotel manager requests data on their hotels status
Expected : System displays information about their hotel and customers
Fails if :
System is unable to retrieve any existing data about the hotel
Table 11: View Hotels Data

19 | P a g e
5. Project Management and Plan of Work

5.1. Merging Contributions from Individual Members
This report was written by the participation of all members of the group. One of
our members Bisratemichael took control of compiling the report, doing the
formatting, ensuring consistency and uniform formatting and appearance. No
extreme issues were encountered in compiling the report.
5.2. Project coordination and progress report

Before this part, we created 10 Use Cases and their class, sequence diagram
and they are in different progress. So far, UC-2, UC-3 and UC-6 have been
implemented. UC-1, UC-4,UC-5 are already functional. Some of the Use Cases
havent yet been implemented, but for the first demo we will have a fully functional
user interface and a working database.
5.3. Plan of Work

We plan on tackling this project in 3 different parts. Namely Data Gathering,
Website, App and UI design and Website and App programing.
We have already done the first phase as we submitted the project proposal. It
took us around two weeks to gather the necessary information, such as systems
that are widely applied, issues in the current system, ways to solve these issues.
Each of the 5 group members participated in collecting the information. We
collected information by directly going to hotels and observing the currently used
system. We also asked frequent hotel users questions on the current system, faults
or problems they have faced and what they would do to solve those issues. We then
based our project on this collected information.
We have started on Website, App and UI design after we finished gathering
information. This will take a lot of time as this will be an integral part in the
development of the project. The UI design will be done mainly by Bisrat and Daniel.
They will be responsible in designing an easy on the eye graphics as well as
designing the system. They will be the ones who will discuss in detail about the UI
design to the other members. They will design the system on the user side (App),
from the hotel admin side, the receptionist and from the system admin side which
are all websites.
This phase will be started as soon as the UI designers finish the design. This
phase will be mainly done by Biruk and Dawit while Yared designs the back end
database. Those three will work very closely in trying to achieve maximum
efficiency. This will be done in 3 up to 4 weeks. The other members will also be
given some modules to program as this will be too vast to handle for two.

20 | P a g e

Alongside this phases or tasks, group members will be in continuous
discussion on how to progress and check on progresses made. Any alteration to be
made on the project will be discussed and changed accordingly.
Figure 12: Plan of work
5.4. Breakdowns For responsibilities

i. For the Project
(1)Android App Biruk
(2) Database Design Dawit and Daniel
(3) Website Structure Design Bisratemichael and Yared
(4) Functions implementations
(a). Register and Log in Dawit and Biruk
(b). Search for Rooms to make reservation- Biruk and Daniel
(c). Browse Information and update profile - Bisratemichael
(d). Online Payment using Hello Cash - Yared
(f). Get hotel feedback and suggestion Biruk and Bisratemichael
(g). Contact providers Daniel and Dawit
ii. For the Report
(1) Class, Use-case, State ,Sequence Diagrams Daniel and Yared
(2) Use-case, Class, Sequence Diagrams Description - Bisratemichael
(3) Design Principles Dawit and Biruk
(4) Project Management and Plan of work
(a) Merging the Contributions from Individual Team Members -Dawit
(b) Project Coordination and Progress Report -Bisratemichael
(c) Plan of work - Daniel
(d) Breakdown of responsibility Biruk and Yared

21 | P a g e
6. References
1. Report 2,Prepared forPersonal Health Monitoring,Prepared by: Yuanxi Li,
Xiaoran Fan, Lun Li, Jingsong Yuan, Tian Xie,Oct. 22,2014
2. beginning java EE 7, by Antonio Goncalves
3. UML - Interaction Diagrams, Tutorials Point
4. Slides on interaction diagram, class diagram Supplied to us by Sahilu
Wendeson
5. Software Architecture in Practice, Book by Len Bass, Paul Clements, and Rick
Kazman
6. Just Enough Software Architecture: A Risk-driven Approach, Book by George
Fairbanks
7. A Practitioner's Guide To Software Test Design, Book by Lee Copeland

22 | P a g e

Hotel Reservation Android App Report

Uploaded by

Copyright:

Available Formats

Hotel Reservation Android App Report

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hotel Reservation Android App Report

Uploaded by

Copyright:

Available Formats

Addis Ababa University

Addis Ababa Institute of Technology (AAIT)

Bisratemichael Moges ATR/6015/05

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Individual Contributions Breakdown

Team Members and Contribution

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Persistent Data Storage...............................................................................13

Project Management and Plan of Work...............................................................19

Merging Contributions from Individual Members.........................................19

Project coordination and progress report.....................................................19

Breakdowns For responsibilities...................................................................20

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

1.2. Design Principles

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Figure 9: Class Diagram

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Figure 10: Architecture For The Web App

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Figure 11: Client-Server Architecture

3.1. Persistent Data Storage

android phone running kitkat or any newer version

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Display list on app

Search for hotels

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Display current data

Connect multiple cell phones

System Specification Document |Biruk ATR/4514/05, Bisratemichael

Software Engineering (ECEG 4201), Year 2009 EC016 GC

Test covers : scalability

System Specification Document |Biruk ATR/4514/05, Bisratemichael