Addis Ababa Science and Technology University

College of Electrical and Mechanical

Engineering
Department of Software Engineering
SOFTWARE DESIGN AND ARCHITECTURE GROUP
ASSIGNMENT

Group members ID

Duresa Feyisa……………………..……………. ETS-0388/13

Gemechis Elias……………………….………… ETS-0539/13

Etsubdenk Hayelom…………………………….. ETS-0448/13

F/Silassie Kelemework……….………………… ETS-0504/13

Habte-Yesus Tadesse……………………………. ETS-0566/13

Table of Contents
1. LOGICAL VIEW...............................................................................................................................3
2. Process view..................................................................................................................................5
3. DEVELOPMENT (IMPLEMENTAL) VIEW..........................................................................................6
4. PHYSCIAL (DEPLOYMENT) VIEW....................................................................................................8
5. SCENARIO....................................................................................................................................10

Diagrams
Figure 1: Class diagram......................................................................................................................4
Figure 2: Activity Diagram..................................................................................................................5
Figure 4: component diagram model................................................................................................7
Figure 5: deployment diagram...........................................................................................................9
Figure 6: use case model.................................................................................................................11
 4+1 VIEWS OF ARSE HOTEL SOFTWARE

1. LOGICAL VIEW
Classes
People Class: This class serves as the base class for all individuals interacting with the
system, including administrators, staff, and guests. It encapsulates common attributes such as
name, password, and registration date. The People class serves as the base class for Admin,
Staff, and Guest classes, demonstrating inheritance to encapsulate common attributes and
behaviours.

Admin Class: Represents administrative personnel within the hotel management system.
Admins have additional privileges and responsibilities compared to other user types.

Staff Class: Represents staff members working within the hotel. They have specific roles and
permissions within the system.

Guest Class: Represents guests or customers utilizing the hotel's services. They interact with
the system primarily for booking and managing their reservations.

Room Class: Represents individual rooms within the hotel. It encapsulates details such as
room number, type, availability, and pricing.

Booking Class: Represents a booking made by a guest for a specific room and duration. It
manages reservation details such as check-in/out dates, guest information, and room
allocation.

Payment Class: Represents a payment made by a guest for their booking. It includes
payment details such as amount, method, and transaction ID.

Payment Bill Class: Represents the billing information associated with a payment.
Class Diagram for arse hotel booking and managing software

: People
#email:string
#passward:string
+regsterDate:string

: guest
#name: string
: admin :staff #email: string
#name: string #name: string #password: string
#email: string #email: string +admin: bool
#password: string #password: string
+admin: bool +admin: bool +viewbooking()
+register()
+manegerecord() +viewrecord() +login()
+manageguestprofile() +viewaveilability () +manageguestprofile()
+manageroom() +viewbooking() +viewaveilability
+paymentdetail() +messeging() +paymentdetail()
+managereport() 1.1 1.1
+acesscontrol()
+messeging()
1.* 1.* Makes
1.*

Manages
Customizes Makes

0.1 Has
1.*

: room 1.* 0.*

: Payment
#roomnumber: int
+roomtype: string
:booking
+paymentid:string
#roomid: string #bookid:string
+paymentbill:string
+roomprice: double #guestname:string
+paymentdate:string
+block/floor: string +bookingdate:string
+guestname:string
+startdate:string
+addroom() +paymentamount
+enddate:string
+editroom()
+delateroom() 1.1 has a 1.* +roomtype:string
+startpayment()
+searchroom() +paymentdetail:string
+cancelpayment()
+viewpaymentbill()
+addbooking()
+searchpayment()
+delatebooking()
+searchbooking()
1.1
+verifybooking() 1.*
Pays for
:paymentbill
1.1
+billid:string
+billbooking:string
+billdate:string

1.1 generates 1.*1 +printbill()

Figure 1: Class diagram

 2. Process view
Admin system Staff/guest

Admin login login

login page information

No No
Valid data

yes

Monitor booking Choose

Display admin
display service accommodation
dashboard

show saved Show accommodation

Monitor rooms
booking data detail book?

Display room
Booking detail
information
and payment
Conform
payment?

display record Save booking

/release bill

Update/cancel
booking?

yes
 Figure 2: Activity Diagram

3. DEVELOPMENT (IMPLEMENTAL) VIEW

A UML component diagram for our system could have the following components and
relationships:

1. Admin Component: Represents the administration module, responsible for managing

room types, rates, and promotions.

2. Guest Component: Represents the customer module, responsible for handling customer
information, booking requests, and payment.

3. Booking Component: Represents the booking module, responsible for managing room
reservations and availability.

4. Rooms Component: Represents the rooms module, responsible for storing information
about the rooms and their availability.

5. Staff Component: Represents the receptionist module, responsible for handling check-in
and check-out processes.

6. Payment Component: Represents the payment module, responsible for processing

payments and generating bills.

7. payment Bill Component: Represents the bill module, responsible for generating invoices
and receipts for customers.

To connect these components, we draw connectors between them, representing the flow of
information and interaction between the components. For example:

 Admin Component can be connected to Rooms Component to update room

information.
 Guest Component can be connected to Booking Component to request a reservation.
 Booking Component can be connected to Rooms Component to check room
availability and make a reservation.
 Staff Component can be connected to Rooms Component to update room status after
checkin and check-out.
 Payment Component can be connected to Customer Component to process payment
for a reservation.
 Payment Bill Component can be connected to Payment Component to generate an
invoice based on the payment.
 Booking

Update data
Room
Admin
Hotel
Management

Process payment
Guest

Payment
System Admin

Staff

Data access
Generate

Payment

Bill

Figure 4: component diagram model

 4. PHYSCIAL (DEPLOYMENT) VIEW
Nodes:

1. Web Server:
 The web server node hosts the web application of the hotel booking and
management software. It serves client requests and manages the
communication between the clients and the application server.

2. Application Server:
 The application server node hosts the core business logic and processing
modules of the software. It handles tasks such as user authentication, booking
management, payment processing, and data retrieval from the database.

3. Database Server:
 The database server node hosts the central database where all the data related
to hotel bookings, guest information, room availability, and payment
transactions are stored. It ensures data integrity, security, and scalability for
the system. for our project we use my sql data base system.
Connections:

 Client-Server Communication:

 Communication between the client devices and the web server occurs over the
HTTP or HTTPS protocols, ensuring secure data transmission over the
internet.

 Web Server-Application Server Communication (RMI):

 The web server communicates with the application server using RMI, enabling
remote method invocation to access the business logic and perform various
operations on behalf of the client requests.

 Application-Database Interaction:

 The application server communicates with the database server using DBMS in
python.
Deployment diagram for arse hotel booking software

:Applicationserver
<<Divice>>
{os=window}

guest

staff
:db server
<<device>>
: WEBSERVER booking <<DBMS>>

<<RMI>>
HOMEPAGE MYSQL DB
<<PYTHON>> rooms <<Database>>

billing

Admin

online booking system

<<server >>

Figure 5: deployment diagram

 5. SCENARIO
UML USE CASE MODEL

3.1 Identifying Actors

 Guests: These are the individuals who use the system to search for and book rooms. They
can also view and manage their reservations.
 Hotel staff: These are the people who work at the hotel and have access to the system to
manage room availability, check in and check out guests, and handle any issues with
reservations.
 Admin: This person has access to the system's backend and can manage the system's
settings, such as room availability, pricing, and staff access.

3.2 Identifying Use Case

 Room Booking: The customer searches for available rooms based on their preferred
dates and location, selects a room, enters their personal and payment information, and
the system confirms the reservation.
 Cancellation: The customer requests to cancel a reservation and the system verify the
cancellation policy and, if met, the system cancels the reservation and issues a refund
or credit if applicable.
 Modification: The customer requests to modify a reservation, such as changing the
dates or room type, and the system verify the availability and update the reservation
accordingly.
 Check-In/Check-Out: The hotel staff checks in and checks out guests and updates the
room availability in the system.
 Payment: The customer makes a payment for a reservation and the system processes
the payment and confirms the payment has been received.
 Viewing Reservations: The customer can view their current and past reservations,
including details such as booking dates, room type, and payment status.
 Room Management: The hotel staff can view and manage room availability, pricing,
and other details in the system.
 Customer Management: The hotel staff can view and manage customer information,
such as contact details and past bookings. 15 Admin Management: The system
administrator can manage the system's settings, such as room availability, pricing, and
staff access.
Extend:

 Display Error Message: The system will display an error message if the login credentials
entered by the user are incorrect or if the user's account is locked or disabled.

Figure 6: use case model