PROJECT DOCUMENTATION

Course: Software Design and Analysis

Course code: CS-324

BS (CS)-D

Batch: Fall 2018

Submitted by:

Hassan Shahzad 18i-0441

Abeera Fatima 18i-0411

Sana Ali Khan 18i-0439

Azka Khurram 18i-0461

Submitted to:

Ma’am Maheen Arshad

Date of Submission:

26-12-2020

1
Event Management System

2
 Acknowledgement

In the name of Allah, the Most Beneficent and the Most Merciful Alhamdulillah, all praises to Allah for the
strengths and His blessings in completing this project. We would like to thank all the people who made this
possible especially Ma’am Maheen Arshad for guiding us throughout the project. She was our source of
inspiration and knowledge. Her guidance, advice and patient encouragement enabled us to work in this domain.
Her helping us after office hours, solving our issues really made our project to reach the stage where it is right
now.

We must also express our gratitude towards our fellow batchmates Adil Fayyaz and Zaynab Batool for
contributing towards debugging of our errors at really odd times too.

3
 Table of Contents
Introduction ......................................................................................................................................................................................6
Project Scope ....................................................................................................................................................................................8
Project Stakeholders ...................................................................................................................................................................... 10
High Level Goals of Stakeholders................................................................................................................................................... 12
List of Features .............................................................................................................................................................................. 14
Functional Requirements ............................................................................................................................................................... 16
Non-Functional Requirements ....................................................................................................................................................... 21
Use Cases ....................................................................................................................................................................................... 24
Use Case Diagram.......................................................................................................................................................................... 27
High-Level Use Cases ..................................................................................................................................................................... 29
Expanded Use Cases ...................................................................................................................................................................... 35
Domain Model ............................................................................................................................................................................... 41
System Sequence Diagrams ........................................................................................................................................................... 43
Sequence Diagrams ....................................................................................................................................................................... 47
Class Diagram ................................................................................................................................................................................ 52
Interface Description (UI) .............................................................................................................................................................. 55
Database Description .................................................................................................................................................................... 67
Implementation Description .......................................................................................................................................................... 70
1. Development Setup: .......................................................................................................................................................... 70
2. Implementation:................................................................................................................................................................ 71
3. Error Handling: .................................................................................................................................................................. 71
Flow Diagram ................................................................................................................................................................................ 74
Testing ........................................................................................................................................................................................... 76
Results ........................................................................................................................................................................................... 78
Conclusion...................................................................................................................................................................................... 80

4
Chapter 1

5
 Introduction
For our Software Design and Analysis project, we are designing a cross platform (accessed through the internet and
mobile applications) Event Management System for a fictional Event Management firm named “A.S.H Events”. It
will provide the clients of the firm with an easy-to-use platform for communicating with the organizers, whilst
also reducing the firm’s labor load (taking orders will be digitalized). Our purpose is to override the problems
prevailing in the practicing manual system and provide OUR clients (A.S.H Events) with a system which will link
them to their account, store and categorize their orders (according to dates/ most time required for planning/level
of urgency etc.) so they can function efficiently and provide their best service.

Our management system has 2 basic categories:

• For Employees of the Firm

• For Customers of the Firm

For the employees, this management system will provide them access to digitalize all their personnel records
and manager would be given access to add/edit/remove an employee along with viewing the orders/vendors
and more. Similarly, for customers, this management system will be providing them with ease of access. For a
customer, this system will be divided into the following three sections:

1. Event Venue bookings and Scheduling

2. Catering Services
3. Multimedia Services

No formal knowledge is needed for the user to use this system as we tried to keep it as minimal as possible,
making it a user-friendly software.

The clients will be able to select either pre-defined packages or customize a package according to his/her need.
Clients will create an account to use the application, select the option for obtaining event management services
and then fill in the respective sections with what they desire. All the information will be stored in a database,
from which the firm will access it according to their needs.

Our Management System is not only digitalizing the booking of orders providing ease of access to the customers,
but will also digitalize the firm’s functionalities such as adding/removing employees, vendors etc. In short, our
management system will digitalize the whole firm along with its jobs.

6
Chapter 2

7
 Project Scope

The scope of our EMS is to automate the existing manual system by the help of computerized equipments and
a software that is fulfilling their requirements so their information can be stored for a longer period along with
ease of access to that information. It manages the details of event, organizers, attendees, payments etc. The
EMS is built at administrative access, hence only the manager is guaranteed the access to information
mentioned above whereas the customer has access to only his/her information (limited access). Similarly,
customer would also be benefitted as he/she can access this software from anywhere, as to access it the only
requirement is having an internet connection.

Our project aims at business process automation. We tried to computerize as many processes of Event
Management as we could such as:

• User can get a number of copies of the information he/she entered within seconds

• To utilize our resources in an efficient manner using automation

• Satisfy the user requirements

• Be easy to use for the user and operator

• Easy to operate

• Have a good interface

• Be expandable

8
Chapter 3

9
 Project Stakeholders

A formal definition of a stakeholder is: “individuals and organizations who are actively involved in the project,
or whose interests may be positively or negatively affected as a result of project execution or
successful project completion” (Project Management Institute (PMI®), 1996).

For our EMS, we have following stakeholders:

• Manager

• Customer

• Employees

• Vendors

• Members of the Public

10
Chapter 4

11
 High Level Goals of Stakeholders

Stakeholder Goals in System

➢ Manager ✓ Manager can view/edit and delete the events created by a customer.

✓ Manager can add/edit/delete an employee of his firm.

✓ Manager can view/edit all the vendors that are affiliated with the firm.

✓ Manager can edit his information.

✓ Manager can confirm a booking of an event.

➢ Customer ✓ Create/Edit Account.

✓ Book an Event.

✓ View an Event.

➢ Employee ✓ Login to the system.

✓ Edit Account Details.

➢ Vendors ✓ Vendors are indirectly affected as whatever is booked using our EMS,

needs to be informed to the vendors and they need to fulfill the

customer’s requirements.

✓ Following are the categories of the vendors:

• Media

• Catering

➢ Members of Public ✓ These are the guests that will attend that particular event.

✓ They will also be indirectly affected.

12
Chapter 5

13
 List of Features
Following is the list of some of the features of our Event Management System:

1. Minimal and Aesthetic UI (User Interface)

2. Easy to Use

3. Expandable Implementation

4. Accuracy in Work

5. Smooth Flow

6. Easy and Fast Retrieval of Information

7. Error Handling

8. Additional Comments for more information

9. Robust Database Backend

10. Cross-Platform Support

11. Access of Information Individually

12. Easy to Update Information

13. Well Designed and Minimal Reports (e.g., Summary of event booked, Payment Confirmation)

14. Decreases the Load of the Person Involved in Existing Manual System

15. Time Efficiency

16. Space Efficiency

14
Chapter 6

15
 Functional Requirements
Following are the functional requirements of our EMS:

1. Add/Delete Client Orders:

▪ The system provides this facility to the manager and customer both. Customer can add
his/her order whereas manager can add, view and delete customers’ orders.

2. Create/Edit/Delete Client Account:

▪ Customer can create and edit his/her account details, whereas the manager can delete
customers’ account, along with editing and viewing it.

3. View Services:
▪ Customer has an option to view the list of services offered by the firm.

4. Cancel Bookings:
▪ Manager can cancel any customer’s booking.

5. Data Entry to Database:

▪ All of the data inserted into the system is stored into a database in the backend.
▪ The database that we used for this project is “MySQL”.

6. Customized Catering Menu:

▪ Customer is able to create a custom menu depending on his/her preferences.

7. Customized Media Services:

▪ Customer is able to customise their media requirements.

8. Generate Event ID:

▪ A unique id is allocated to each event in order to access it easily.

16
9. Generate Customer ID:
▪ Each customer will be assigned a unique id associated with his/her email address.

10. Generate Employee ID:

▪ Each employee will be assigned a unique id associated with his/her email address.

11. Generate Catering ID:

▪ A unique id is associated with each caterer (vendor) to access their information from database.

12. Generate Media ID:

▪ A unique id is associated with each media requirement in the database for ease of access.

13. Generate Menu ID:

▪ A unique id is associated with each menu in the database for ease of access.

14. Generate Studio ID:

▪ A unique id is associated with each studio in the database for ease of access.

15. Generate Venue ID:

▪ A unique id is associated with each venue in the database for ease of access.

16. Generate Total Bill:

▪ In the end a total bill will be computed from all the choices selected by the customer inclusive
of taxes and this bill will be displayed on the screen which user can print.

17. Enter Payment Details:

▪ Customer will be asked to enter payment details after selecting payment option.

18. Order Confirmation:

▪ This screen will be displayed showing that the order has been confirmed and awaiting
approval.

17
19. Tax Calculation:
▪ Tax will be calculated as per government regulations and added to the final bill.

20. Book Event:

▪ Customer can book event as per his/her requirements.

21. Add/Remove Employee:

▪ Manager will have the facility to add or remove an employee from the database.

22. Approve/Deny Order:

▪ All the confirmed orders will need to be approved from the manager.

23. Add/Remove Vendors:

▪ Manager has the facility to add or remove a vendor (caterer or studio).

24. View Orders:

▪ Customer is able to view his order. Moreover, manager can view a particular order and he/she
can view all orders too.

25. Client Sign In:

▪ When a customer signs in, his/her credentials are verified from the database and then
allowed access into the system.

26. Manager Sign In:

▪ When a manager signs in, his/her credentials are verified from the database and then allowed
access into the system.

27. Employee Sign in:

▪ When an employee signs in, his/her credentials are verified from the database and then
allowed access into the system.

18
28. Pop-up Message:
▪ Whenever there is an error, a popup message with the error details will be displayed.

29. Error Alarms:

▪ Whenever there is an error, a notification beep will be played to gain the user’s attention
followed by an error popup.

30. Sign Out:

▪ When a user clicks “Sign Out” button, they are logged out of the system and the flow returns
back to the main menu screen.

19
Chapter 7

20
 Non-Functional Requirements

1. Minimal Interface:

▪ Interface should be simple and easy for users to adapt to.

2. Speed:

▪ System should be fast and responsive, with as minimal lag as possible.

3. Portability:

▪ There should be abstraction between the application logic and the system interface –

system should be modular

4. Reliability:

▪ System should be stable, not prone to crashes. User should expect to have a consistent

experience every time they use it.

5. Scalability:

▪ System should be extendable if required, and adapt to greater number of users. It should

be open for more functionalities to be added if required.

6. Security:

▪ User data and/or other private details must be kept confidential and only visible to those

authorized to view them.

21
7. Data Integrity:

• Data stored should not be compromised, and should be accurate and reliable.

22
Chapter 8

23
 Use Cases

A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The

use case is made up of a set of possible sequences of interactions between systems and users in a particular

environment and related to a particular goal.

For our EMS, we have the following use cases:

• Creating Client Account

• Editing Client Account

• Deleting Client Account

• Creating Booking

• Deleting Booking

• Viewing Booking

• Editing Booking

• Viewing Services

• Customizing Media Requirements

• Customizing Menu

• Entering Bank Details

• Adding Employee

• Editing Employee

24
• Removing Employee

• Adding Vendor

• Removing Vendor

• Signing In

• Signing Out

• Viewing All Bookings

25
Chapter 9

26
 Use Case Diagram
Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They
enable you to visualize the different types of roles in a system and how those roles interact with the system.

The use case diagram of our EMS is as follows:

27
Chapter 10

28
 High-Level Use Cases

The high-level use case is simply a summary description of the task. Its purpose is to provide just enough detail
to give you a feel for its complexity.

The high-level use cases for our EMS are as follows:

Use Case: Creating Client Account

Actors: Client
1:
Type: Primary
Description: Client opens the software. Then he/she clicks on “Register”. After entering
information and creating account, the information is stored in the database.

Use Case: Editing Client Account

Actors: Client
2:
Type: Primary
Description: Client decides to update his/her contact number in account information. They log in
to their account and go to profile, make the desired changes and save the changes.

Use Case: Deleting Client Account

Actors: Manager
3:
Type: Primary

Description: Clients want to delete his/her account. They will contact the manager and the
manager will delete the account from the database.

29
 Use Case: Creating Booking

Actors: Client
4:
Type: Primary

Description: Client opens the software. After signing in, he/she clicks on “Book an Event”. After
entering all required details, his event is confirmed and sent to manager for
approval.

Use Case: Deleting Booking

Actors: Manager
5:
Type: Primary

Description: Client changes his/her mind about booking an event. He/She will request the
manager who will upon reviewing the progress of event, cancel the event. Note that
advance will be refunded only if booking is deleted within a certain period of time.

Use Case: Viewing Booking

Actors: Manager, Customer

6:
Type: Primary

Description: Manager and Customer, both can view a specific booking by simply entering the
event ID.

Use Case: Editing Booking

Actors: Client, Manager

7:
Type: Primary
Description: Client and manager can both edit the booking information for a specific event.

30
 Use Case: Viewing Services

Actors: Customer
8:
Type: Primary

Description: Customer can also view the list of services provided by the firm.

Use Case: Customizing Media Requirements

Actors: Client
9:
Type: Primary

Description: Client can customize the media services he/she wants according to personal
requirements.

Use Case: Customizing Menu

Actors: Client
10:
Type: Primary

Description: Client can customize the food menu he/she wants according to personal
requirements.

Use Case: Entering Bank Details

Actors: Client
11:
Type: Primary

Description: After confirming a booking, the customer will be asked to select his/her payment
option. For this the customer will have to enter their payment details.

31
 Use Case: Adding Employee

Actors: Manager
12:
Type: Primary

Description: A new employee joins the firm. Manager has the authorization to create their
account by entering their details.

Use Case: Editing Employee

Actors: Manager, Employee

13:
Type: Primary

Description: Employee can edit his/her information to some extent whereas the manager can
edit every information about the employee.

Use Case: Removing Employee

Actors: Manager
14:
Type: Primary

Description: An employee retires/leaves the firm, then the manager will have the facility to
delete their account from the database.

Use Case: Adding Vendor

Actors: Manager
15:
Type: Primary

Description: A contract is signed with a new vendor. Manager has the facility to add any new
vendor by simply entering their details in the database.

32
 Use Case: Removing Vendor

Actors: Manager
16:
Type: Primary

Description: The contract has been expired with a specific vendor. Manager has the facility to
remove any vendor.

Use Case: Signing In

Actors: Manager, Customer, Employee

17:
Type: Primary

Description: In order to access the software, each user needs to sign in to get authenticated.

Use Case: Signing Out

Actors: Manager, Employee, Customer

18:
Type: Primary

Description: After the user has finished using the software, they must sign out to ensure privacy
and security.

Use Case: Viewing All Bookings

Actors: Manager
19:
Type: Primary

Description: The manager has been facilitated such that he can view all of the booking currently
under progress from the database.

33
Chapter 11

34
 Expanded Use Cases
Use case name: Book an Event

Scope: Event Management System

Level: User-goal
1: Primary Actor: Client, Manager

Stakeholders and Interests: ✓ Client wants to book an event and will provide all the details
related to that event
✓ Manager will approve/deny the event

Pre-conditions: Client signs in to the software in order to book the event.

Post-Conditions: Event is successfully booked and stored in the database and the total
bill is displayed.

Main Success Scenario:

Actor Action System Response

1: User selects the option “Book an Event”.

2: System opens a window with fields to be filled with

the details of that event.

3: User enters all the details in the respective fields.

4: System books an event and stores it into the DB.

5: User logs out.

Extensions:
➢ Customer enters invalid number of guests (i.e., a non-numeric value)
a. An error is detected and error message is displayed as a pop-up with a beep
b. User is asked to re-enter the number of guests
➢ Customer forgets to enter the date of event
a. An error is detected and error message is displayed as a pop-up with a beep
b. User is asked to select the date of the event
➢ Customer selects a date that has past
a. An error is detected and error message is displayed as a pop-up with a beep
b. User is asked to enter the correct date

35
 Use case name: Add Employee

Scope: Event Management System

Level: User-goal
2: Primary Actor: Manager

Stakeholders and Interests: ✓ Manager is responsible for adding a new employee to the
database.
✓ Oversees every employee.

Pre-conditions: Manager is signed into the system. Manager selects the option of
“Adding an Employee”.

Post-Conditions: New employee is successfully stored in the DB and manager logs out.

Main Success Scenario:

Actor Action System Response

1: Manager selects “Add Employee” option

2: Asks for employee information

3: Enters the employee’s information

4: Saves the information into the DB

5: Manager logs out of the system.

Extensions:
➢ Managers misses to add cnic of the employee
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. Manager is asked to re-enter the cnic of the employee
➢ Managers adds a non-numeric value in cnic
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. Manager is asked to re-enter the cnic of the employee

36
 Use case name: Edit Employee Information

Scope: Event Management System

Level: User-goal
1: Primary Actor: Employee, Manager

Stakeholders and Interests: ✓ Employee can edit his/her account information with limited
access.
✓ Manager can however completely access and edit employee’s
information

Pre-conditions: Employee/Manger signs into the system and clicks on edit information.

Post-Conditions: Updated information is successfully stored in Db and

manager/employee sign out.

Main Success Scenario:

Actor Action System Response

1: Employee/Manger clicks on “Edit Employee”

2: A screen with information is displayed.

3: Employee/Manger makes the required changes

4: The updated information is saved into the DB.

5: Employee/Manger logs out of the system

Extensions:
➢ Manager enters negative account number
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. Manager is asked to re-enter the account number of the employee

37
 Use case name: Creating Client Account

Scope: Event Management System

Level: User-goal
1: Primary Actor: Customer

Stakeholders and Interests: ✓ Customer needs to create his account in order to access the
software.

Pre-conditions: Client wants to book an event. He/She needs to create an account.

He/She clicks on “Register”

Post-Conditions: Account was successfully created and he/she can now log in.

Main Success Scenario:

Actor Action System Response

1: Customer selects option “Register”

2: System opens a screen having information fields

3: Customer fills information in those fields

4: The information is stored into the system

5: Customer is taken back to sign in screen

6: Customer signs in

Extensions:
➢ Customer enters age less than 18 years
a. An error is detected
b. The error message is displayed as a pop-up on the interface displaying “The minimum age
requirement to create an account is 18 years old”
c. Customer is asked to enter the age again
➢ Customer enters an invalid email
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. Customer is asked to re-enter his email address

38
 Use case name: Edit Customer Information

Scope: Event Management System

Level: User-goal
1: Primary Actor: Customer, Manager

Stakeholders and Interests: ✓ Customer can edit his/her account information with limited
access.
✓ Manager can however completely access and edit customer’s
information

Pre-conditions: Customer/Manger signs into the system and clicks on edit information.

Post-Conditions: Updated information is successfully stored in Db and

manager/customer sign out.

Main Success Scenario:

Actor Action System Response

1: Customer/Manger clicks on “Edit Customer”

2: A screen with information is displayed.

3: Customer/Manger makes the required changes

4: The updated information is saved into the DB.

5: Customer/Manger logs out of the system

Extensions:
➢ Manager enters a negative age
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. User is asked to re-enter the age
➢ Managers tries to edit cnic of the customer
a. An error is detected
b. The error message is displayed as a pop-up on the interface
c. Manager is told that he/she cannot edit the cnic of the customer

39
Chapter 12

40
 Domain Model

In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior
and data. The model can then be used to solve problems related to that domain. The domain model is a
representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software.

The domain model diagram of our EMS is as follows:

41
Chapter 13

42
 System Sequence Diagrams

In software engineering, a system sequence diagram is a sequence diagram that shows, for a particular scenario
of a use case, the events that external actors generate, their order, and possible inter-system events. System
sequence diagrams are visual summaries of the individual use cases.

The system sequence diagrams of the 5 selected use cases from our EMS are as follows:

1. Book Event:

43
2. Add Employee:

3. Edit Employee Information:

44
4. Add Customer Account:

5. Edit Customer Information:

45
Chapter 14

46
 Sequence Diagrams

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the functionality
of the scenario.

The sequence diagrams of the 5 selected use cases from our EMS are as follows:

1. Book Event:

47
2. Add Employee:

48
3. Edit Employee Information:

4. Add Customer Account:

49
5. Edit Customer Account:

50
Chapter 15

51
 Class Diagram

In software engineering, a class diagram in the Unified Modeling Language is a type of static structure diagram
that describes the structure of a system by showing the system's classes, their attributes, operations, and the
relationships among objects.

The class diagram of our EMS is as follows:

52
53
Chapter 16

54
 Interface Description (UI)

At the most basic level, the user interface (UI) is the series of screens, pages, and visual elements—like buttons
and icons—that enable a person to interact with a product or service. Interface has the most pivoted role in the
whole implementation as in order to please the customers, the software needs to have an appealing UI Design.

So, we had to brainstorm a lot regarding the interface designs and concepts and we shortlisted many too. After
designing and analysis of the designs, we discarded many and picked our final design.

For our interface, we wanted it to be aesthetic along with being minimalist at the same time. We wanted it to
give out a happy concept to the users keeping it simple and self-explanatory. Our interface stood our from the
rest of our competitors because of the uniqueness of our designs. We also tried to synchronize the images with
the context as much as we can so they may be self-explanatory.

For our front-end, we decided to use Java FX instead of Java Swing as it had numerous options and functionalities
and better designs. Though Java FX is considered a bit complicated than Java Swing, which we also had to agree
with during our implementation, but the expected output turned out to be better than we imagined due to
which we decided to stick to it.

We used the following libraries in our interface:

✓ Java FX SDK 15.0.1

✓ Jfoenix 9.0.10 (used for better designing)
✓ MySQL connector java 8.0.22 (used to connect our implementation with DB)

Some of the examples from our UI design are as follows:

55
Fig 1. Start Screen of the Software

Fig 2. Sign in Screen of Customer

56
 Fig 3. Welcome Screen of Customer

If the client chooses to book an event, the flow of interfaces will be as follows:

Fig 4. Event Details Screen

57
Fig 5. Venue Choice Screen

Fig 6. Caterer Choice Screen

58
Fig 7. Menu Choice Screen

Fig 8. Studio Choice Screen

59
 Fig 9. Checkout Screen

The client can also edit his/her information as follows:

Fig 10. Customer Edit Info Screen

Customer can also view his booked event as follows:

60
 Fig 11. View Current Event Screen

Manager can however perform multiple tasks. The flow of these tasks are as follows:

Fig 12. Manager/Employee Sign In Screen

61
Fig 13. Manager Welcome Screen

Fig 14. Edit Employee Info Screen

62
Fig 15. Edit Caterers Screen

Fig 16. Edit Studios Screen

63
 Fig 17. Edit Venues Screen

Fig 18. View All Events Screen

64
Fig 18. View All Employees Screen

65
Chapter 17

66
 Database Description

A database is a collection of information that is organized so that it can be easily accessed, managed and
updated. Computer databases typically contain aggregations of data records or files, containing information
about sales transactions or interactions with specific customers.

For our EMS, we started off with Oracle 11g as 2 of the members had it installed and configured in their systems
already. We made all the tables, columns, backend etc.

During the final stages of our project, we wanted it to run on every system, so we started by installing Oracle
11g on 2 remaining systems, however it kept failing. We tried to search online for issue but still no use. So, at
this stage, we decided to convert all of our code into a different database. We had 3 databases in mind: MySQL,
MariaDB, Firebase. After a bit of research and analysis, we found MySQL to be easiest and the closest to the
Oracle 11g so we wouldn’t need to change our code entirely. So, we shifted our code to MySQL.

The query language used was SQL.

We are using:

✓ MySQL 8.0
✓ 10 Tables

Following is the details of the tables along with their columns:

67
 Table Columns

CATERING • (catering_id, name, contact, specialty, days, charges)

CUSTOMER • (cust_id, name, cnic, age, phone_no, email, account_number,

priority_status)

CUSTOMERPASS • (cust_id, password)

• cust_id references cust_id in CUSTOMER

EMPLOYEE • (emp_id, name, dob, email, phone_no, cnic, account_number, wage_type,

wage_rate, points, mgr_id)
• mgr_id references emp_id in EMPLOYEE

EMPLOYEEPASS • (emp_id, password)

• emp_id references emp_id in EMPLOYEE

EVENT • (event_id, name, type varchar(30), event_date, guests, total_cost,

starting_time, ending_time, cust_id, venue_id, studio_id, menu_id,
catering_id, media_id, approved)
• media_id references media_id from MEDIA_REQUIREMENTS
• studio_id references studio_id from STUDIO
• catering_id references catering_id from CATERING
• venue_id references from venue_id from VENUE
• menu_id references menu_id from MENU
• cust_id references cust_id from CUSTOMER

MEDIA_REQUIREMENTS • (media_id, photography, videography, album, drone, crane)

MENU • (menu_id, rice, bread, protein, coke, miranda, sprite, water, dryfruit,
sugarfree, icecream, cake, cost)

STUDIO • (studio_id, name, contact_info, cost)

VENUE • (venue_id, name, location, address, max_capacity, description, category,

contact_info, cost)

68
Chapter 18

69
 Implementation Description

This chapter includes the details of the implementation of our backend code.

This includes the following parts:

1. Development Setup:

The setup that we used to implement our software is as follows:

• Programming Language:

▪ For this we decided to go with JAVA, as it is not only cross-platform, but we also

got to learn a new programming language.

• Frontend:

▪ For the frontend, we decided to use FXML as it is not only easy to use but also

easy to adjust.

• Hardware Interface:

▪ The interface of our hardware was Windows 10.

• Database:

▪ The database that we used was MySQL.

• Framework:

▪ We used Java FX for our front end and as our framework.

• Tools:

▪ We used IntelliJ IDEA 2020.3 by JetBrains as it is very responsive and easy to use.

• Libraries Included:

▪ We used java sdk 15.0.1, Jfoenix 9.0.10 and MySQL java connector 8.0.22.

70
2. Implementation:

For implementation of this software, we started off by following basic OOP concepts. Instead of writing all of

the back-end code in a single file, we decided to make multiple files. Each file has a different class having

different functionalities. We used controllers to link the front-end to the backend, which is then further linked

to the database to ensure smooth flow of information.

We also left 2 types of comments:

a. A comment at start of each file describing the purpose of the file, its functionalities and the

flow of the file/class.

b. Small comments inside the code for the sole purpose of better understanding, so that this

code can be understood and modified by anyone.

We also used inheritance in our classes just for the sake of ease and efficiency. Along with this, the names of

variables have also been kept meaningful, so that a reader can simply understand the use of those variables by

simply reading the names of the variables.

Moreover, for error handling, we added a small beep which is played whenever an error occurs, followed by a

popup message having the description of the error message. This pop up will prompt the user that an error has

occurred and will also guide the user regarding the steps to further prevent this error.

The overall implementation of the software was very fluent and efficient keeping in mind all of the efficient

programming practices.

3. Error Handling:

In order for a perfect and authentic execution, we implemented numerous error handling conditions in our

software. A few of these checks/error handling conditions are as follows:

71
✓ No input fields should be left blank

✓ No empty strings should be entered in input fields

✓ Only numeric input is accepted for numeric values (i.e., Account number, guests etc.)

✓ No negative values entered

✓ Proper email address format should be followed

✓ A customer can book only 1 event at a time

✓ Customer cannot view another customer’s event

✓ Minimum age to register is 18

✓ Each email can have a single account

✓ Log in fails with incorrect email/password

✓ A caterer, venue and a studio must be selected before an event is booked

✓ Venue can not be selected if its capacity is less than the number of guests

✓ Number of guests must be more than 0

✓ Selected date for event must be after the current date

✓ A single event per date

✓ CNIC cannot have alphabets

✓ Selected event id (for viewing, approving, editing event) must exist.

Fig 19. Error Pop-up Screen

72
Chapter 19

73
Flow Diagram

74
Chapter 20

75
 Testing

We performed different types of tests on our software. A few of those tests are as follows:

✓ White Box Testing:

✓ In white box testing, a close examination of the logical parts is done to check different
conditions, loops and the execution of the program. This enables the developers to
understand if there are any logical errors such as a loop iterating more than it should etc.
We performed white box testing on our system which proved to be successful.

✓ Black Box Testing:

✓ In black box testing, a fixed set of inputs and outputs are used to test the software and
the results are compared with the manually calculated results to see if the software is
working well. Our software passed this test too.

✓ Alpha Testing:
✓ Alpha testing is also known as acceptance testing. In this, a system is designed as for a
single user and that user keeps testing until both the user and developer agree that the
software runs perfectly for that user. In our case, the user was a fellow friend and the test
proved to be successful.

✓ Beta Testing:
✓ Before official launch of any product into the market, beta testing is carried out. In this,
the product is given to potential people who use the products and point out if any flaws.
During this test, we provided our software to 3 different people from different universities
and from different domains. One issue was caught which was later on fixed.

✓ Validation Testing:
✓ In this testing, we made sure that all the functional and performance requirements are
met.

76
Chapter 21

77
 Results

After performing the above-mentioned tests, we came up with following results:

1. Percentage of Completion:

We have completed our project 100%. We have met all functional requirements which we discussed earlier.

2. Percentage of Accuracy:

Our project is working 100% accurate. It fulfills all the functional and non-functional requirements along

with proper error handling.

3. Percentage of Correctness:

As we tested all the requirements using different test cases in the black box testing, and we cleared the error

that was brought to light, we can confidently say that our project is 100% correct.

78
Chapter 22

79
 Conclusion

Our project is only a humble venture to satisfy the needs to manage their project work. Several user-friendly

coding techniques have also been adopted. This package shall prove to be a powerful package in satisfying the

requirements of both the customer and the firm. The objective if software planning is to provide a frame work

that enables the manager to make reasonable estimate made within a limited time frame at the beginning of

the software project and should be updated regularly.

At the end, we will conclude by saying that we made efforts in following areas:

✓ A description of introduction and context of project and its relation to the work already

done in this area

✓ Project Scope, purpose and stakeholders discussed

✓ We defined the project on which we worked

✓ We described the requirement specification of the system and actions that can be done

on these things

✓ We designed user interface and ensured privacy of information.

✓ Finally, the system was implemented and tested accordingly.

80