Report 2: System Analysis & Architectural Design Report (Design Phase)

1. System Overview
- Briefly describe the purpose and functionality of the system.
- Mention the intended users and target platform.

2. UML Diagrams
Include relevant UML diagrams:

- Use Case Diagram

- Class Diagram
- Sequence Diagram

Describe each diagram briefly. Generate diagrams with AI (Tutorial in file “Guide to
Generating Diagrams with AI”).

3. Database Design
- Present Entity-Relationship Diagram (ERD).
- Include database schema and table descriptions.

4. User Interface (UI) Mockups

a. Login Window:
Description: This is the entry point for all users of the EZSTAY system. It features a
simple layout with fields for Username and Password, and "Login" and "Exit"
buttons.
Design Rationale:
 Simplicity: A minimalist design ensures that the focus is solely on authentication.
 Clarity: Clearly labeled fields and buttons guide the user.
 Security: This is the gatekeeper to the entire system, ensuring only authorized
personnel can access it.
User Flow:
1. User launches the EZSTAY application.
2. The Login screen appears.
3. User enters their Username and Password.
4. User clicks "Login."
5. If credentials are valid, the user is redirected to the appropriate dashboard (likely
the Manager Dashboard for a manager role).
6. If credentials are invalid, an error message (not shown but implied) would appear.
7. User can click "Exit" to close the application.

1
b. Manager Dashboard:
Description: This is the central hub for managers, providing quick access to
different functional modules of the hotel management system. It displays prominent
buttons for "Customer Management," "Report," "Room Management,"
"CheckIn/Checkout Management," and "Reservation Management."
Design Rationale:
 Navigation Hub: Acts as a clear starting point for various management tasks.
 Role-Based Access: This dashboard is likely specific to manager roles, providing
access to all high-level functionalities.
 Clear Categorization: Buttons are distinct and represent major operational areas.
User Flow:
1. After successful login (if the user has a manager role), the Manager Dashboard is
displayed.
2. The manager can click on any of the five buttons to navigate to the respective
module:
o "Customer Management" → Customer Management screen.
o "Report" → Manager Report screen.
o "Room Management" → Room Management screen.
o "CheckIn/Checkout Management" → Hotel Check-in / Check-out screen.
o "Reservation Management" → Room Reservation screen.

2
c. Room Reservation Screen:
Description: This screen displays available and unavailable rooms, allowing staff to
initiate new reservations. It shows room images, names, bed count, bathroom count,
and price per night. There's a search bar and "Available" / "Not Available" toggles.
Design Rationale:
 Visual Appeal: Room images help in quickly identifying room types and amenities.
 Clear Status: "Available" and "Not Available" toggles provide quick filtering.
 Essential Information: Displays critical details like price, bed count, and bathroom
count upfront.
 Direct Action: "Make Reservation" buttons are prominently displayed for each
room.
User Flow:
1. From the Manager Dashboard, click "Reservation Management."
2. The Room Reservation screen appears, showing available rooms by default.
3. User can use the search bar to find specific rooms or toggle between "Available" and
"Not Available" rooms.
4. To make a reservation, the user clicks the "Make Reservation" button next to the
desired room.
5. This action leads to the "Make a Reservation" form (described next).
6. The back arrow at the top left can return to the Manager Dashboard.

3
d. Make a Reservation Form:
Description: This form is used to collect customer information for a new
reservation. Fields include Full Name, Email, Phone, Identity Number, Check-in Date,
Check-out Date, and Address. It has "Cancel" and "Confirm Reservation" buttons.
Design Rationale:
 Comprehensive Data Capture: Ensures all necessary customer details for a
reservation are collected.
 Date Pickers: The calendar icon next to date fields (
15∘
) suggests a date picker will be used, improving data entry accuracy.
 Clear Call to Action: "Confirm Reservation" is a prominent green button, indicating
the primary action.
User Flow:
1. After clicking "Make Reservation" from the Room Reservation screen.
2. The "Make a Reservation" form opens, potentially pre-filled with room details.
3. User fills in all required customer information.
4. User selects "Checkin Date" and "Checkout Date" using the date picker.
5. User clicks "Confirm Reservation" to finalize the booking. This would then update
the room status and potentially appear in upcoming reservations.
6. User can click "Cancel" to close the form without making a reservation.

4
e. Room Management Screen:
Description: This screen allows staff to view, search, add, edit, and delete room
details. It displays a table with room ID, Room Number, Room Type, Capacity, Price,
and Status. Below the table are search filters and input fields for adding/modifying
room details, along with "Thêm phòng mới" (Add new room), "Sửa" (Edit), "Xóa"
(Delete), and "Exit" buttons.
Design Rationale:
 Data Grid: Presents room information in a clear, tabular format for easy viewing
and management.
 Search and Filter: Provides multiple ways to search for rooms (by ID, room
number, type, capacity, price, status).
 CRUD Operations: Directly supports the core "Create, Read, Update, Delete"
operations for room inventory.
 Language: Uses Vietnamese terms ("Thêm phòng mới", "Sửa", "Xóa", "Tìm")
indicating the target user base.
User Flow:
1. From the Manager Dashboard, click "Room Management."
2. The Room Management screen appears, displaying a list of rooms.
3. To search: Enter criteria in the search fields (e.g., "Sức Chứa" for capacity) and click
"Tìm" (Search).

5
4. To add a new room: Fill in the details in the input fields below the table and click
"Thêm phòng mới" (Add new room).
5. To edit a room: Select a room from the table, modify the details in the input fields,
and click "Sửa" (Edit).
6. To delete a room: Select a room from the table and click "Xóa" (Delete).
7. Click "Exit" to return to the Manager Dashboard.

f. Hotel Check-in/Check-out Screen:

Description: This screen is designed for managing guest check-ins and check-outs.
It has two main sections: "Upcoming Reservations" and "Currently Checked-in
Guests." Central buttons include "Check-in," "Check-out," "Refresh," and "Exit."
Design Rationale:
 Task-Oriented: Directly supports the primary front-desk operations of checking
guests in and out.
 Clear Distinction: Separates upcoming reservations from current guests, making it
easy to manage daily operations.
 Action Buttons: Prominently displays "Check-in" and "Check-out" as the main
actions.
 Efficiency: The "Refresh" button helps ensure the lists are up-to-date.
 Language: Uses Vietnamese terms for columns ("ID Mã Khách Reserve," "Check-in,"
"Check-out").
User Flow:
1. From the Manager Dashboard, click "CheckIn/Checkout Management."

6
2. The Hotel Check-in / Check-out screen appears.
3. To Check-in a guest:
o Select an upcoming reservation from the "Upcoming Reservations" list.
o Click "Check-in." The system would likely prompt for confirmation or
additional details, then move the guest to "Currently Checked-in Guests."
4. To Check-out a guest:
o Select a guest from the "Currently Checked-in Guests" list.
o Click "Check-out." The system would likely process payment/finalization,
then remove the guest from the list.
5. Click "Refresh" to update the lists.
6. Click "Exit" to return to the Manager Dashboard.

g. Customer Management Screen:

Description: This screen allows managing customer records. It displays a table with
Customer ID, Full Name, Email, Phone, Identity Number, Address, and Created At.
Below, there are input fields for adding/editing customer details and "Add,"
"Update," "Delete," "Clear," and "Back" buttons.
Design Rationale:
 Centralized Customer Data: Provides a dedicated interface to manage customer
profiles.
 CRUD Operations: Supports adding new customers, updating existing ones, and
deleting records.
 Consistency: Similar layout and button styling to the Room Management screen,
promoting familiarity.

7
 User Flow:
1. From the Manager Dashboard, click "Customer Management."
2. The Customer Management screen appears, listing existing customers.
3. To add a new customer: Fill in the details in the input fields (Full Name, Email,
Address, Phone, Identity Number) and click "Add." The "Date Created" field
automatically defaults to the current date.
4. To update a customer: Select a customer from the table, modify their details in the
input fields, and click "Update."
5. To delete a customer: Select a customer from the table and click "Delete."
6. Click "Clear" to clear the input fields.
7. Click "Back" to return to the Manager Dashboard.

h. Staff Management Screen:

Description: This screen is for managing user accounts (staff members). It shows a
table with User ID, Username, Password (likely masked), Full Name, Email, Role, and
Date Created. Below are input fields for adding/editing staff details, including a
"Role" dropdown (e.g., Admin). Buttons include "Add," "Update," "Delete," "Clear,"
and "Back."
Design Rationale:
 User Account Control: Enables management of who can access the system and with
what permissions.
 Role-Based Access Control (RBAC): The "Role" dropdown suggests that different
access levels can be assigned (e.g., Admin, Manager, Front Desk).
 Security: Allows for password management and user creation/deletion.

8
 User Flow:
1. (Access to this screen is likely only for "Admin" or specific "Manager" roles, possibly
through a hidden or separate menu item, or part of a "Settings" or "User
Management" section not directly visible on the Manager Dashboard mock-up).
2. The Staff Management screen appears, listing existing staff accounts.
3. To add a new staff member: Fill in the details (Full Name, Email, Role, Username,
Password) and click "Add."
4. To update a staff member: Select a staff member from the table, modify their
details, and click "Update."
5. To delete a staff member: Select a staff member from the table and click "Delete."
6. Click "Clear" to clear the input fields.
7. Click "Back" to return to the previous screen (likely the Manager Dashboard if this
was accessed from there).

i. Manager Report Screen:

Description: This screen provides various reports for managers. It features top-
level summary cards for "Customers," "Available Rooms," and "Today's Revenue."
Below these are tabs for "Recent Reservations," "Check-in/out History," "Room
Status," "Room Cleaning," and "Active Staff." The initial tab shown is "Recent
Reservations," displaying columns for Customer Name, Room Number, Check-in
Date, Check-out Date, and Reserved By.
Design Rationale:
 Overview at a Glance: The top summary cards provide quick, high-level insights
into key operational metrics.

9
  Tabbed Navigation: Allows managers to easily switch between different types of
reports without leaving the screen.
 Detailed Data: Each tab would likely display relevant tabular data for deeper
analysis.
 Decision Support: Provides crucial information for operational decision-making.
User Flow:
1. From the Manager Dashboard, click "Report."
2. The Manager Report screen appears, with "Recent Reservations" selected by default.
3. The manager can view the summary cards for "Customers," "Available Rooms," and
"Today's Revenue."
4. The manager can click on different tabs to view specific reports:
o "Recent Reservations" (shown)
o "Check-in/out History" (would show past check-ins and check-outs)
o "Room Status" (would show the current status of all rooms, e.g., occupied,
vacant, cleaning needed)
o "Room Cleaning" (would show rooms requiring cleaning and cleaning staff
assignments)
o "Active Staff" (would show currently logged-in or on-duty staff)
5. Click "Exit" to return to the Manager Dashboard.

5. CI/CD Planning

10
 6. CI/CD Plan for EZSTAY Hotel Management System

This document explains how we plan to build and deliver the EZSTAY Hotel Management
System using a modern approach called CI/CD. CI/CD helps us make sure our software is
always working well and can be updated easily and quickly.

1. Tools We Will Use for CI/CD

To make our CI/CD process work, we'll use several important tools:

 Version Control System (VCS): Git (like using GitHub or GitLab)

o Why we use it: Git is like a super-smart save system for our code. It helps all
developers work on the same project without stepping on each other's toes.
It keeps track of every change, so we can always go back to an older version
if needed.

 CI/CD Automation Tool: GitHub Actions (if we use GitHub) or GitLab CI/CD (if we
use GitLab) / Jenkins

o Why we use it: This tool is the "brain" of our CI/CD process. It automatically
runs all the steps we define, like building and testing our code, whenever
someone makes a change. It's like having a robot that handles all the
repetitive tasks for us. We're leaning towards GitHub Actions because it's
easy to use and widely adopted.

 Tools to Build Our Software:

o For the part users see (Frontend, like React): npm/Yarn, Webpack/Vite

o For the part that works behind the scenes (Backend, like Node.js):
npm/Yarn (for Node.js), pip/Poetry (for Python), Maven/Gradle (for Java)

o Why we use them: These are like the construction tools that turn our raw
code into a working program. They gather all the pieces and put them
together correctly.

 Tools for Testing:

o Small Tests (Unit/Integration Tests): Jest/React Testing Library

(Frontend), Pytest/JUnit (Backend)

o Full System Tests (End-to-End or E2E Tests): Cypress/Playwright (for

testing the website's user interface)

o Why we use them: We use these tools to automatically check if our code
works as expected. Small tests check individual parts, while full system tests

11
 check if the whole program works together correctly, just like a user would
use it.

 Tools to Check Code Quality: ESLint/Prettier (Frontend), SonarQube/Flake8

(Backend)

o Why we use them: These tools are like grammar and spell checkers for
code. They help us write clean, organized code and catch simple mistakes
early on.

 Tool for Packaging Our Application: Docker

o Why we use it: Docker puts our application and all its necessary parts (like
libraries and settings) into a neat, self-contained package called a
"container." This means our application will run exactly the same way
everywhere, whether it's on a developer's computer or on our main servers.

 Tool for Running Many Packaged Applications (for the live version):
Kubernetes (or similar services like AWS ECS, Azure AKS, Google GKE)

o Why we use it: When our application is used by many people, we need a
way to manage many Docker containers. Kubernetes helps us run, manage,
and scale these containers automatically, making sure our system can
handle many users.

 Where We Host Our Application: A Cloud Provider (like AWS, Azure, Google Cloud
Platform)

o Why we use it: This is where our application "lives" on the internet. Cloud
providers give us the computers and services we need to run our software
without having to buy and maintain our own physical servers.

 Tools for Watching and Recording: Prometheus/Grafana, ELK Stack

(Elasticsearch, Logstash, Kibana)

o Why we use them: These tools help us keep an eye on our application when
it's live. They collect information about how it's performing and if there are
any problems, so we can fix them quickly.

2. How Our CI/CD Pipelines Work

We'll set up two main automated workflows, or "pipelines," that run whenever we make
changes to our code.

2.1. Continuous Integration (CI) Pipeline

This pipeline focuses on making sure new code changes fit well with the existing code.

12
When it starts: Every time a developer saves their code changes (a "git push") or creates a
"pull request" (asking to merge their changes).

Steps (Stages):

1. Get the Code:

o What happens: The system copies the latest code from our save system
(Git).

o Why: To make sure we're working with the most up-to-date version.

2. Set Up the Project:

o What happens: All the necessary tools and libraries that our code needs are
installed.

o Why: To get the environment ready for building and testing.

3. Check Code Style and Quality:

o What happens: Tools automatically check our code for any style mistakes
or simple errors.

o Why: To keep our code clean and easy to read, and to catch small problems
early.

4. Build the Application:

o What happens: The raw code is put together to create a working program
(or parts of it).

o Why: To make sure our code can actually be turned into something
runnable.

5. Run Small Tests:

o What happens: Automated tests run on small pieces of our code to check if
they work correctly on their own.

o Why: To quickly find bugs in individual parts of the program.

6. Run Connection Tests:

o What happens: Automated tests check if different parts of our application

work well together.

o Why: To make sure the pieces connect and interact as they should.

13
 7. Create the Application Package (Docker Image):

o What happens: Our application is put into a Docker container, which is a

standardized package.

o Why: To make sure the application runs the same way everywhere, no
matter where we deploy it.

8. Save the Package:

o What happens: This Docker package is saved in a special online storage

place (a "registry").

o Why: So we can easily get this exact version of the application whenever we
need to deploy it.

What happens if it passes: If all these steps run successfully, it means the new code
changes are stable and ready for the next step (delivery). If anything fails, the process stops,
and the developers are immediately told to fix it.

2.2. Continuous Delivery/Deployment (CD) Pipeline

This pipeline focuses on getting the tested code ready for users, or directly to them.

When it starts:

 Continuous Delivery (CDel): We manually tell it to start after the CI pipeline

finishes successfully on our main code branch, or after a new feature is approved.
This gives us a chance to review before it goes live.

 Continuous Deployment (CDep): It starts automatically after the CI pipeline

finishes successfully on our main code branch. (At first, we'll use Continuous
Delivery for more control, but we aim to move to Continuous Deployment later).

Steps (Stages) for each environment (like a test environment or the live
environment):

1. Get the Application Package:

o What happens: The system gets the latest approved Docker package from
our storage.

o Why: To make sure we're deploying the correct and fully tested version.

2. Check Package Security:

o What happens: The Docker package is scanned for any known security
weaknesses.

14
 o Why: To add an extra security check before the application goes live.

3. Put It on the Test Server (Staging):

o What happens: The Docker package is deployed to a special test

environment called "Staging." This environment is set up to be as similar to
the live environment as possible.

o Why: To allow for more thorough testing in a realistic setting.

4. Run Full System Tests:

o What happens: Automated tests that simulate how a real user would use
the application are run on the Staging environment.

o Why: To make sure everything works perfectly from a user's point of view.

5. User Checks (Staging only):

o What happens: (This is a manual step for Continuous Delivery) People who
represent the users (like product owners or quality assurance teams) try out
the application on the Staging environment.

o Why: To make sure the new features meet all the requirements and are
ready for real users.

6. Approval to Go Live (for Production):

o What happens: (This is a manual step for Continuous Delivery) A specific

team or person has to give a final "OK" before the application can go to the
live environment.

o Why: To have a final human check for very important updates.

7. Put It on the Live Server (Production):

o What happens: The exact same Docker package that passed all tests in
Staging is deployed to the live environment where users can access it. We
use smart ways to do this, like "blue-green deployment" (where we switch
between two identical live setups) or "canary release" (where we slowly roll
out to a few users first) to avoid any downtime or problems.

o Why: To make the new version available to everyone.

8. Quick Check After Going Live:

o What happens: A few quick automated tests are run right after the
application is live to make sure it's working properly.

15
 o Why: To immediately confirm that the deployment was successful.

9. Watch and Be Ready to Fix:

o What happens: We continuously watch how the application is performing

on the live server. If something goes wrong, we have a plan to quickly switch
back to the previous working version.

o Why: To ensure the application stays stable and to recover quickly if there
are any issues.

3. How We Use Our Code Save System (Git)

Git is the main place where all our code is stored, and it's what kicks off our automated
processes.

 How We Organize Code Changes (Branching Strategy): We'll use a system where
developers work on new features in separate "branches" (like parallel versions of
the code).

o Feature Branches: These are temporary copies where developers work on

new features or fix bugs.

o Pull Requests (PRs): When a developer finishes their work, they create a
PR to ask for their changes to be reviewed and merged into the main
development code.

o Main Branch: This special branch always holds the code that is ready to be
used by customers. Only code that has been fully tested and approved will be
put here.

 Automatic Start Signals (Webhooks): Our CI/CD tool will be set up to "listen" for
specific actions in Git:

o When code is saved to a feature branch or a PR is created/updated: This

starts the CI Pipeline.

o When a PR is merged into the main branch: This starts the CD Pipeline (or
makes it ready for us to start it manually).

 Pipeline Settings in Code: The instructions for our CI/CD pipelines will be saved as
code files directly within our project's Git repository. This means everyone can see,
change, and track the history of our pipeline settings, just like our application code.

4. How We Release Our Software

We will release our software step-by-step to reduce risks and make sure everything is
stable.

16
  Developer's Test Area (Development Environment):

o When it's used: When developers are actively working on new features.

o How it's deployed: Developers can put their new code on their own
computers or a shared test server to quickly see if it works. This is usually a
very quick test, separate from the main pipeline.

 Main Test Area (Staging Environment):

o When it's used: After code has passed the initial CI checks and is ready for
more thorough testing.

o How it's deployed: The CD pipeline puts the approved Docker package onto
the Staging environment. This environment is built to be just like the live
version customers use.

o Why: This is where our quality assurance team and business people do their
final checks to make sure everything works perfectly and meets all the
requirements.

 Live for Customers (Production Environment):

o When it's used: After the application has been fully tested and approved in
the Staging environment.

o How it's deployed: The exact same Docker package that was tested in
Staging is put onto the live servers. We use smart ways like:

 Blue-Green Deployment: We have two identical live setups. We

update one while the other is serving users, then switch traffic
instantly. This means no downtime and an easy way to switch back if
there's a problem.

 Canary Release: We slowly release the new version to a small group

of users first. If everything looks good, we then release it to
everyone. This helps us find problems early with less impact.

o What if something goes wrong: If a big problem happens after we deploy,

our CI/CD pipeline has a way to quickly switch back to the previous working
version of the application.

By following this CI/CD plan, EZSTAY aims to deliver new features and fixes faster, more
reliably, and with higher quality, making our hotel management system better and better
over time.

17
7. Team Contributions
- Outline which parts of the design were handled by each team member.

18