Re-design of Guest Tracker Application Report 2022

Re-design of Guest Tracker Application
Design Document
10/13/2019
Student details:

Table of Contents
I. Introduction...................................................................................................................................................3
Purpose...........................................................................................................................................................3
Overview.........................................................................................................................................................3
II. Design Goals..............................................................................................................................................4
III. Architectural View Model........................................................................................................................4
Logical View.......................................................................................................................................................4
Figure 1 below show class diagram of guest checker website...................................................................5
Development View.............................................................................................................................................6
Figure 2 below show implementation diagram of guest checker website................................................7
Physical View....................................................................................................................................................10
Figure 3 below shows Logical structures of guest checker website for deployment....................................11
Figure 4 below shows physical structure deployment diagram of guest checker website....................11
Process View.....................................................................................................................................................12
Figure 5 below shows sequence diagram of quest checker system...............................................................13
Figure 6 below show activity diagram of guest Tracker Website.................................................................14
Use Case View..................................................................................................................................................14
Figure 7 below show use case diagram of guest tracker website............................................................15
Table 1 below shows Register use case description................................................................................16
Table 3 below shows create booking use case description........................................................................17
Table 4 below shows manage booking use case description.......................................................................17
Table 5 below shows manage customer preference use case description...................................................17
Table 6 below shows generate report use case description.........................................................................18
Table 7 below shows order food use case description................................................................................18
IV. Architectural Design Pattern.....................................................................................................................19
A. Model / Back-end design / Database design.............................................................................................19
Table 8 below shows customer database design........................................................................................19
Table 9 below shows Administrator database design.................................................................................20
Table 10 below shows booking database design.........................................................................................20
Table 11 below shows order database design.............................................................................................20
Table 12 below shows food database design................................................................................................21
Data Dictionary..................................................................................................................................................21
Table 13 below shows Data dictionary.......................................................................................................21
B. View / Front-end design............................................................................................................................22
C. Controller / Link to Front-end and Back-end design................................................................................22
V. Security in Design.........................................................................................................................................22
VI. Summary..................................................................................................................................................23
VII. References.................................................................................................................................................24

I. Introduction.
The documents is to design the hotel guest tracker web based system .The hotel guest
tracker is web based system running online and users who has internet can access it through
the url on the web Lethbridge et al (2016).. The user of the system shall first need to register
and system administrator accept registration or deny. When registration is accepted the
system generate username and password for user to login. The system shall enable customer
to book for room, order food, check in and out. The system administrator shall be able to
manage booking and manage customer.
This report will define the high level design and technology decisions of the hotel guest
tracker web based system.
This document defines and describes the use of each view, the architectural constraints of the
system, the functional requirements with a significant impact on the architecture, use-case
realization, concurrency aspects, the layers and subsystems of the application, performance
issues and constraints.
Purpose.
This document is a deliverable of the architectural and design phase of software development
Satzinger et al (2016). It entails an overview of the proposed system design for the hotel
guest tracker web based system .It encompasses a general description of the functionality,
context and design of the application together with a high level overview of how
responsibilities of the system were partitioned and then assigned to subsystems. It also
provides a description of how the major data or system entities are stored, processed and
organized and an overview of the user interface. The document is intended for the
supervisors, development team and other interested parties.
Overview.
This document is divided into 8 sections. Section 1 provides an introduction to the system
design document including the purpose of the document and guidelines on how to read the
document. Section 2, the System Overview provides an abstract view of the system
architecture including a general description of the functionality, context and design of the
application, leading into the third section, System Architecture which gives a more detailed
description at a modular program structure level and explains the relationships between the

modules that help to achieve the complete functionality of the system. The section goes on to
discuss the rationale for selecting the architecture described. The fourth section, Data Design
provides a data description explaining how the information domain of the system is
transformed into data structures. It also alphabetically lists the major data along with their
types and descriptions. In the fifth section, Component Design, the document provides an
analysis of what each component does in a more systematic way. Section six, Human
Interface Design describes the functionality of the system from the user’s perspective.
Towards the end, section 7 Requirements Matrix uses a tabular format to show which system
components satisfy each of the functional requirements from the SRS. It provides a cross
reference that traces components and data structures to the requirements in the SRS
document. The final chapter is the appendix.
II. Design Goals.
The goal of design is to ensure the usability of the system.
To increase profit of the organization through reduced cost and increase of revenue.
To ensure the architecture meets the needs of the stakeholders.
To Speed up implementation to be used.
To increase quality for example Usability, Efficiency, Reliability, Maintainability and
Reusability to reduce cost and increase revenues.
III. Architectural View Model.
Logical View.
The logical view is about the functional requirements the system provides to its end users
such as customer ( Alsaleh, and Haron,2016).. The logical view represents the vital
components of the design and interaction between elements
The system designer breaks down system into process of abstracting something, mostly got
from the domain problem(Sommerville, 2016) .The class diagram mostly represent attributes
and methods used.
Class diagram.

The class diagram is to demonstrate how different classes integrate with each other and
relationship between them .The customer, order, Room, Food and Administrator classes are
identified and illustrated in details. The full attributes and their methods are developed.
Audience: End users such as customer and administrator.
Area: class diagram: The class shall address the objects by identifying the attributes and
methods. Example customer, food, order, book and administrator classes.
Related Artifacts: logical model.
Figure 1 below show class diagram of guest checker website.
The class diagram is developed according to the targeted system to be developed. It is object
oriented.
The class diagram has 4 class .These classes represents the logical view which the model is
also tested and validated against user requirements.
The correctness of class diagram is ensured when all class attributes and methods are
captured and meet the requirement of the system.
The logical data model should be tested to ensure it supports all the functionalities of the
users such as customers and administrators.

Development View.
The development view focuses on the organization of the actual software modules in the
software-development environment. The software is packaged in small chunks-program
libraries or subsystems-that can be developed by one or more developers. The subsystems are
organized in a hierarchy of layers, each layer providing a narrow and well-defined interface
to the layers above it.
Components are related by “is submodule of”.
This where actual developing of the guest checker takes place the developer code the final by
using the language of their choice. The language going to be used to develop the system is
java languages. The java files with java class are customer, order, food,and administrator
classes.
Audience: System Developers.
Area: components and objects: The application shall be implemented using java language.
Related Artifacts: Development model.
Development environment.
Basically all the development work was done on Window 10 professional operating system
machine where all the programming IDE were installed and utilised.
Mobile application
The android mobile application was developed using Android studio IDE from Google which
replaced the Eclipse IDE that comes with the Android plug-in. This is due to the fact that
Android studio was made the default Android development editor and comes with the
Material designs framework recommended by Google for the Android applications.
Android applications are developed using the java programming language.
The minimum software development kit (SDK) was set to application programming interface
(API) level 14 and the targeted SDK was API level 23.
Choice of java programming language for mobile development.
The object oriented language such as java are used to development of the Android mobile
application offers inbuilt security features that include the following;
There is no need to use pointers like C/C++ that would cause unauthorized access to memory
blocks when other programs get the pointer values.
Exception handling concept
It enables java to capture a series of errors that helps developers to get rid of risk of crashing
the whole phone system.
Test code reusability
This allows the developers to re-use the code that has already been tested while developing
Java enterprise applications (Pressman, 2018).

Garbage collection mechanism
It provides a transparent storage allocation and recovering unutilized memory rather than de-
allocating memory through manual action. It will help developers to ensure the integrity of
the program during its execution and avoids any JVM (Java Virtual Machine) crash due to
incorrect freeing of memory.
Figure 2 below show implementation diagram of guest checker website.

COMPONENT DESIGN
Class Method Pseudo code
Authentication Register()
Enter username AND AND password
Insert them into database
IF Error
PRINT Unsuccessful
ELSE
PRINT Added successful
Login()
Enter username AND password
Check user details in database
IF user exists
Grant Access
ELSE
Deny Access
ENDIF

Class Method Pseudo code
Customer
createBooking()
Enter booking details
Insert them into database
IF Error
PRINT Unsuccessful
ELSE
PRINT Added successful
Login()
Enter username AND password
Check user details in database
IF user exists
Grant Access
ELSE
Deny Access
ENDIF

Physical View.
The physical view takes into account the system's nonfunctional requirements such as system
availability, reliability (fault-tolerance), performance (throughput), and
scalability(Sommerville, 2016). The software executes on a network of computers (the
processing nodes). The various elements identified in the logical, process, and development
views-networks, processes, tasks, and objects-must be mapped onto the various nodes.
Several different physical configurations will be used-some for development and testing,
others for system deployment at various sites or for different customers. The mapping of the
software to the nodes must therefore be highly flexible and have a minimal impact on the
source code itself.
This view illustrates how the guest checker system is installed and customers are able to use
it.
Audience: System Developers.
Area: Topology: The mapping of application to other devices such as desktop, server and
mobile devices.
Related Artifacts: Deployment model.
Figure 3 below shows Logical structures of guest checker website for deployment.
There is need to use internet services to access the guest checker website using url.
The firewall protocol is used to make system secure and safe to use.
The application server is where main system operation takes place.
The domain firewall it protects system domain from external attackers.
The database it is where storage take places.

Figure 4 below shows physical structure deployment diagram of guest checker website.
The components required to be deployed includes mobile phones, laptops, operational server,
and workstation and database server. The customer mobile phone or laptops is connected on
internet and customer can access guest checker system and data stored in the database server.
The running pattern is applicable.
The implementation is done on addition application server.
The guested checker is deployed in two working application server in cluster.
The Application servers are IBM servers running Jboss Application Server
The Database server is IBM server running MySQL server.
All application servers and Database server have redundancy using mirroring RAID mode.
The Workstations run Linux and use Eclipse platform for development.

Process View.
The process view takes into account some nonfunctional requirements, such as performance
and system availability. It addresses concurrency and distribution, system integrity, and fault-
tolerance. The process view also specifies which thread of control executes each operation of
each class identified in the logical view(Sommerville, 2016).
So the process view describes the mapping of functions to runtime elements. It concerns the
dynamics of the system. A process is a group of tasks which form a logical unit. A process
can be started, stopped, resumed, etc., and there is communication between processes.
The customer interact with system by first registering, the system verify registration details
then system responds registration by accepting or being delayed. After registration the
customer login on the system .The system verify the login by allowing customer access
system features .The customer create booking and order food. The system administrator
manages customer preference by accepting or rejecting customer preference .The
administrator manages booking.
The figure below is a process interaction diagram. It mainly shows the runtime view of the
system.
The sequence diagram is drawn to represent how actors interact with the system.
Figure 5 below shows sequence diagram of quest checker system.
The customer starts by registering on the system .The system verify the registration details
then login .The system verify the login details .The customer can now create booking ,order
food and administrator can manage booking and customer preference on the system.

Figure 6 below show activity diagram of guest Tracker Website.
The customer starts by registering on the system .The system verify the registration details
then login .The system verify the login details .The customer can now create booking, order
food and administrator can manage booking and customer preference on the system.
There are three swim lane customer, guest tracker website and administrator.
Use Case View.
The scenario view consists of a small subset of important scenarios-instances of use cases-to
show that the elements of the four views work together seamlessly. For each scenario, we
describe the corresponding scripts (sequences of interactions between objects and between
processes). This view is redundant with the other ones (hence the "+1"), but it plays two
critical roles(Sommerville, 2016).

it acts as a driver to help designers discover architectural elements during the architecture
design;
it validates and illustrates the architecture design, both on paper and as the starting point for
the tests of an architectural prototype.
The scenario view is important for stakeholder communication.
The create booking, manage booking. Manage customer preferences and generate report use
cases are identified.
Audience: customer, Hotel and administrator.
Area: The description of use cases identify significant to functionality of the quest checker
system.
Related Artifacts: use case diagram.
Figure 7 below show use case diagram of guest tracker website.
.;

USE CASE #1 DESCRIPTION
Table 1 below shows Register use case description.
USE CASE #1 Register
Initiating Actor customer
Actor’s goals To register on system.
Participating actors Customer and system administrator
Pre-conditions The customer is first time user of the
system.
Post-conditions The customer has registered and registration
details stored in the system database.
Success Scenario i. Customer open guest system on
his /her device
ii. Customer access system features
iii. Customer select create account
option
iv. Customer enters registration details.
v. Customer submits registration
details.
USE CASE #2 DESCRIPTION.
Table 2 below shows Login use case description.
USE CASE #2 Login
Initiating Actor customer
Actor’s goals To login on guest system.
Participating actors Customer and system administrator.
Pre-conditions The customer has not yet login.
Post-conditions The customer has provided correct login
details and is login in.
Success Scenario i. Customer launch Quest checker
system.
ii. Open log in page.
iii. Enter login details.
iv. Clicks on login button and customer
is successfully login.

USE CASE #3 DESCRIPTION.
Table 3 below shows create booking use case description.
USE CASE #3 Create booking
Initiating Actor customer
Actor’s goals To book room
Participating actors Administrator and customer
Pre-conditions The customer has not room booking
Post-conditions The customer has already created booking
Success Scenario vi. Customer opens application on
mobile device
vii. Customer login
viii. Customer open main page
ix. Customer selects create booking
x. Customer enters booking details.
xi. submits booking
USE CASE #4 DESCRIPTION.
Table 4 below shows manage booking use case description.
USE CASE #4 Mange Booking
Initiating Actor System administrator
Actor’s goals To manage booking
Participating actors Administrator and customer
Pre-conditions The customer has made booking
Post-conditions The administrator has managed booking.
Success Scenario i. Customer opens application on
mobile device
ii. Customer login.
iii. Customer makes booking.
iv. Administrator manages booking by
accepting it or denying it.

v.
USE CASE #5 DESCRIPTION.
Table 5 below shows manage customer preference use case description.
USE CASE #5 Mange customer preference
Initiating Actor System administrator
Actor’s goals To manage customer preference
Participating actors Administrator and customer
Pre-conditions The customer has made booking
Post-conditions The administrator has managed customer
preference
Success Scenario i. Customer opens application on
mobile device
ii. Customer login.
iii. Customer makes booking or order
food.
iv. Administrator manages customer
preference by updating the booking
details.
USE CASE #5 DESCRIPTION.
Table 6 below shows generate report use case description.
USE CASE #5 Generate Report
Initiating Actor System administrator
Actor’s goals To generate report.
Participating actors Administrator and customer
Pre-conditions The customer has made booking
Post-conditions The administrator has already generated
report.
Success Scenario i. Administrator successfully generates
report of the customer bookings and
order.
USE CASE #6 DESCRIPTION.
Table 7 below shows order food use case description.
USE CASE #6 Order food
Initiating Actor customer
Actor’s goals To order food.
Participating actors Administrator and customer

Pre-conditions The customer has not yet order food.
Post-conditions The customer has order food.
Success Scenario i. Customer login on system.
ii. Customer access order menu on
system.
iii. Customer insert order details.
iv. Customer submits order details
v. System administrator verify food
order and accept it.
vi. Customer successful order food and
food is delivered to him/her.
IV. Architectural Design Pattern
A. Model / Back-end design / Database design
The model view is where data manipulation take place. The data is stored in the database.
The database responds to customer query.
Customer.
Table 8 below shows customer database design.
Customer _id INT () Primary key
customer name VARCHAR() Not Null
Password STRING() Not Null
Phone Number INT() Not Null
Email String() Not Null
Age INT() Not Null
Location String() Not Null
sex String() Not Null

Administrator.
Table 9 below shows Administrator database design.
Administrator _id INT () Primary key
email Address VARCHAR () Not Null
Administrator Name Varchar() Not Null
Position Varchar() Not Null
Age Varchar() Not Null
sex Varchar() Not Null
Booking.
Table 10 below shows booking database design.
BookingName Varchar() Not Null
BookingID String() Primary key
Type String() Not Null
Vm
=Charges
Int() Not Null
Bookingdate date Not Null
CheckInDate date Not Null
CheckOutDATE date Not Null
1 m ljji666
Order

Table 11 below shows order database design.
orderid INT() Primary key
ordername VARCHAR() Not Null
ordercharge DOUBLE() Not Null
orderCategory Varchar() Not Null
Orderdate Date Not null
Food
Table 12 below shows food database design.
Food_Number VARCHAR() Primary key
Food_name VARCHAR() Not Null
FoodType VARCHAR() Not Null
FoodCategory VARCHAR() Not Null
Data Dictionary
Table 13 below shows Data dictionary.
Class/Object Attributes Methods Parameters
customer username
Password
Name
CustomerId
email
age
Location
sex
Login()
Register()
Booking()
String username
String password
String Name
string CustomerId
string email
Integer age
string Location
string sex
Name Booking()

Booking Type
ID
Category
Charges
Booking Date
Booking Time
CheckIndate
check Outdate
String Name
String Type
String ID
string Category
Int Charges
Date BookingDate
Time BookingTime
Date CheckIndate
Date checkOutDate
Room
RoomName
RoomNumber
BookRoom()
RoomCharges()
String RoomNumber
String RoomName
Food
Name:string
FoodNumber
Category
orderFood() String Name
String FoodNumber
String Category
Order orderlDate
OrderId
OrderName
Category
cost:
Orderfood()
Foodcharges()
Date orderlDate
String OrderId:
String OrderName
String Category
Int cost
B. View / Front-end design
This is the user interface where customer interacts with the system .The interfaces includes
registration, login and dashboard which shows main system features. The Front-end design it
is where customer interact with by input data and requesting. For example registration and
login page is a good example of front ends. The customer input registration details such as
first name, last name, city, country, email, and password and confirm password detail. The
customer insert username and password to login.
C. Controller / Link to Front-end and Back-end design
Controller it is the intermediate between model and view. When customer make a request to
book a room. The controller process booking request and query database to reply the booking
detail by details of booking for example cost, room number and name.
V. Security in Design
The security measure designed is use of username and Password to identify the user of the
system.

The guest checker system shall secure customer to transact online.
The vital secure behaviors include
Authenticating: Login page all user to input user name and password.
Authorizing: Allowing customer who are registered only to access system.
Controls level: Different roles shall access different information.
Confidentiality: encrypting sensitive information.
Safety: sensitive data is kept in the database.
Data integrity: The information shared on the system should not be corrupted or changed.
Input validation at the client side
There is need to restrict the type of the input values required such as String type for
username and password, indirect input selection where the user clicks on already provided
parking data to avoid dangerous characters that can cause the SQL injection in the database.
VI. Summary.
The design document has covered detailed designs of guest checker system. The logical,
process, use case, development and deployment views has been identified and described in
details in the report. The report is fully detailed and when adopted to be used in the
implementation of the guest system can be of great help to programmers.
VII. References
Alsaleh, S., & Haron, H. (2016). The Most Important Functional and Non-Functional
Requirements of Knowledge Sharing System at Public Academic Institutions: A Case
Study. Lecture Notes On Software Engineering, 4(2), 157-161. doi:
10.7763/lnse.2016.v4.242.
Satzinger, W, J ,Jackson,B,R and Burd ,D,S (2016).System Analysis and Design in
A changing World (8th Ed).Boston Course Technology.
Sommerville, I (2016). Software engineering (10th Ed.).
University of St Andrews, Scotland: Pearson.
Pressman, S,R,Ph.D. (2018).Software Engineering. Practitioner’s Approach (8thEd.). Inc.,
1221 Avenue of the Americas, New York, McGraw-Hill.
Lethbridge, C, T and Laganiere,R.(2016) Object-Oriented Software Engineering:

Practical Software Development Using UML and Java (3ndEd.). New York,
McGraHill.