WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING

EVENT MANAGEMENT SYSTEM

SAD COURSE FINAL PROJECT
BY
NAME OF THE STUDENTS ID NO
1. Abdi Tefera NSR/0017/13
2. Yusuf Abubaker NSR/2298/13
3. Hayder Abdela NSR/1112/13
4. Kalab Solomon NSR/1215/13
5. Tigistu Shewangzaw NSR/2058/13
6. Sitra Shemsu NSR/1922/13

PROJECT ADVISOR: Mr. Seifu D.

June, 2023
 WOLKITE UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS
DEPARTMENT OF SOFTWARE ENGINEERING

EVENT MANAGEMENT SYSTEM

SUBMITED TO DEPARTMENT OF SOFTWARE ENGINEERING IN PARTIAL
FULFILMENT OF THE REQUIREMENT FOR
THE DEGREE OF BACHLER OF SCIENCE IN SOFTWARE ENGINEERING
BY
NAME OF THE STUDENTS ID NO
1. Abdi Tefera NSR/0017/13
2. Yusuf Abubaker NSR/2298/13
3. Hayder Abdela NSR/1112/13
4. Kalab Solomon NSR/1215/13
5. Tigistu Shewangzaw NSR/2058/13
6. Sitra Shemsu NSR/1922/13

PROJECT ADVISOR: Mr. Seifu D.

Wolkite University, Wolkite, Ethiopia

June, 2023

I
 Declarations
This is to declare that this project work which is done under the supervision of Mr. Seifu Desto
and having the title Event Management system is the sole contribution of:
Name of the students
1. Sitra Shemsu
2. Abdi Tefera
3. Yusuf Abubaker
4. Hayder Abdela
5. Kalab Solomon
6. Tigistu Shewangzaw
No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have been
cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.
Date:____________________
Group Members:
Full Name Signature
________________________________________ ____________________
________________________________________ ____________________
________________________________________ ____________________
________________________________________ ____________________
________________________________________ ____________________
________________________________________ ____________________

II
 Approval Form
This is to confirm that the project report entitled Wolkite University Health Center submitted to
Wolkite University, College of Computing and Informatics Department of Software Engineering
by: <<list group members name here>>
Name of the students
1. Sitra Shemsu
2. Abdi Tefera
3. Yusuf Abubaker
4. Hayder Abdela
5. Kalab Solomon
6. Tigistu Shewangzaw
is approved for submission.

_____________________ ___________ ___________

Advisors Name Signature Date

_____________________ ___________ ___________

Department Head Name Signature Date

_____________________ ___________ ___________

Examiner 1 Name Signature Date

_____________________ ___________ ___________

Examiner2 Name Signature Date

_____________________ ___________ ___________

Examiner 3 Name Signature Date

III
Table of Contents
Title of Project ........................................................................................................................................... I
Declarations ............................................................................................................................................. II
Approval Form ....................................................................................................................................... III
CHAPTER FIVE ........................................................................................................................................ 1
SYSTEM DESIGN .................................................................................................................................. 1
INTRODUCTION................................................................................................................................... 1
System Overview ..................................................................................................................................... 1
5.1. Design Goals ..................................................................................................................................... 2
5.2. Proposed System Architecture ........................................................................................................ 4
5.2.1. Architectural Design ................................................................................................................. 6
5.2.2 DATA DESIGN ......................................................................................................................... 10
5.2.3. Subsystem Decomposition and Description .......................................................................... 11
5.2.4. Hardware/Software Mapping ................................................................................................ 19
5.2.5. Detailed Class Diagram .......................................................................................................... 20
5.2.6. Persistent Data Management ................................................................................................. 21
5.2.7. Access Control and Security................................................................................................... 21
5.3. Packages .......................................................................................................................................... 23
5.4. Algorithm Design ........................................................................................................................... 26
5.5. User Interface Design..................................................................................................................... 32

IV
 CHAPTER FIVE
SYSTEM DESIGN

INTRODUCTION

The design goals of the Event Management System project are to create a comprehensive software
solution that facilitates efficient management of events. The system aims to automate various tasks
involved in event planning, organization, and execution, streamlining the overall process and
improving user experience. The current software architecture of the Event Management System
typically follows a client-server model. The system consists of multiple components, including a
front-end user interface, a back-end server, and a database for persistent data storage. The proposed
software architecture for the Event Management System project would allow for better scalability,
flexibility, and fault tolerance. The system could be divided into smaller, independent services that
communicate with each other through APIs. The Event Management System can be deployed on
various hardware setups depending on the scale and requirements of the project. Persistent data
management in the Event Management System involves storing and retrieving data related to
events, attendees, location, schedules, and other relevant information. Access control and security
are crucial aspects of the Event Management System. User authentication and authorization
mechanisms should be implemented to ensure that only authorized individuals can access and
modify sensitive data.

System Overview

The Event Management System project aims to provide a software solution that simplifies the
process of planning, organizing, and managing events. This system is designed to cater to various
types of events, including conferences, seminars, workshops, weddings, and corporate gatherings.
The Event Management System offers a range of functionality to different user roles. The Event
Management System operates within the context of event planning and management. The design

1
of the Event Management System focuses on usability, scalability, and flexibility. The user
interface is intuitive and user-friendly, allowing users to navigate through various features easily.

5.1. Design Goals

User Interface and Human Factors:

✓ Provide a user-friendly and intuitive interface for easy interaction with the system.
✓ Consider usability principles to ensure a positive user experience.
✓ Incorporate accessibility features to accommodate users with disabilities.

Hardware Consideration:

✓ Design the system to be compatible with the hardware infrastructure.

✓ Optimize resource utilization to ensure efficient utilization of hardware resources.
✓ Consider scalability to handle increased user load and accommodate future hardware
upgrades.

Security Issues:

✓ Implement robust security measures to protect the system against unauthorized access, data
breaches, and malicious attacks.
✓ Apply encryption techniques to secure sensitive data at rest and in transit.
✓ Implement authentication and authorization mechanisms to control access to system
resources.

Performance Consideration:

✓ Design the system to be responsive and performant, ensuring quick response times for user
interactions.
✓ Optimize database queries and system processes to minimize latency and improve overall
performance.
✓ Conduct performance testing and tuning to identify and address any bottlenecks or
performance issues.

2
Error Handling and Validation:

✓ Implement robust error handling mechanisms to gracefully handle and recover from system
errors, exceptions, and failures.
✓ Validate user inputs to ensure data integrity and prevent potential vulnerabilities such as
injection attacks or data corruption.

Quality Issues:

✓ Adhere to coding standards, best practices, and software engineering principles to ensure
code quality and maintainability.
✓ Conduct thorough testing, including unit testing, integration testing, and system testing, to
ensure the system functions as expected and meets the specified requirements.

Backup and Recovery:

✓ Implement regular backup mechanisms to protect data against loss or corruption.

✓ Design a disaster recovery plan to ensure system availability and minimize downtime in
the event of a failure or disaster.

Physical Environment:

✓ Consider environmental factors such as temperature, humidity, and power supply

requirements for the system's hardware components.
✓ Ensure the system can operate reliably in the designated physical environment.

Resource Issues and Documentation:

✓ Efficiently manage system resources such as memory, disk space, and network bandwidth.
✓ Provide comprehensive documentation, including system architecture, design
specifications, user manuals, and troubleshooting guides, to facilitate system maintenance
and support.

3
5.2. Proposed System Architecture

In this section, we will present the proposed system architecture for our event management system.
We will discuss the rationale behind selecting this architecture, including critical issues and trade-
offs considered during the decision-making process. The aim is to provide a holistic view of the
system's architecture and highlight the assignment of functionality to each subsystem.

Rationale for Selected Architecture

The selected architecture for our event management system is a layered architecture. This
architectural style was chosen due to its benefits in terms of modularity, scalability, and
maintainability. By organizing the system into distinct layers, we can achieve separation of
concerns and ensure that each layer has specific responsibilities and interfaces, making the system
easier to develop, test, and maintain.

Critical Issues and Trade-offs Considered

Several architectural options were considered before selecting the layered architecture. These
included a client-server architecture and a microservices architecture. However, the layered
architecture was chosen for the following reasons:

1. Modularity: The layered architecture promotes modularity by separating the system into
logical layers. This allows for independent development and maintenance of each layer,
making it easier to understand, modify, and enhance specific components without affecting
the entire system.

2. Scalability: The layered architecture provides scalability by allowing each layer to be

scaled independently. For example, if the event registration subsystem experiences high
traffic, it can be scaled up without impacting other subsystems.

3. Maintainability: The layered architecture simplifies maintenance efforts by providing

clear boundaries between layers. Each layer can be updated or replaced without affecting
other layers, facilitating future enhancements and upgrades.

4
 4. Interoperability: The layered architecture enables interoperability between subsystems
through well-defined interfaces. This allows for easier integration with external systems
and services, promoting flexibility and extensibility.

Overall, the layered architecture was chosen to strike a balance between modularity, scalability,
maintainability, and interoperability.

Holistic View of the System Architecture

The proposed system architecture consists of several high-level subsystems, each responsible for
specific functionalities:

1. Event Creation Subsystem: Handles the creation and storage of event details.

2. Event Registration Subsystem: Manages participant registration and ticket availability.

3. Ticketing and Payment Subsystem: Manages ticketing functionalities and payment

processing.

4. Event Management Subsystem: Manages event details, modifications, and cancellations.

5. Attendance Management Subsystem: Facilitates attendance tracking and generates

attendee lists.

6. Communication and Notifications Subsystem: Sends notifications and updates to

participants.

7. Reporting and Analytics Subsystem: Provides reporting capabilities and data analysis.

These subsystems collaborate with each other through well-defined interfaces and interactions to
achieve the desired functionality of the system. The layered architecture allows for clear separation
of concerns and promotes modular development and maintainability.

Overall, the proposed system architecture aims to provide a robust, scalable, and maintainable
solution for event management, ensuring a smooth user experience and efficient event
organization.

5
5.2.1. Architectural Design

The proposed architectural pattern for the Event Management System is a microservices
architecture. This architecture involves breaking down the system into smaller, independent
services that communicate with each other through APIs.

System Model

I. Logical View

I.I. Sequence Diagram

Figure 5.1. Create event Sequence diagram

6
I.II. State Diagram

Figure 5.2. Create event State diagram

7
 II. Process View

Figure 5.3. Activity diagram Event Management System

8
 III. Scenario view

Figure 5.4 Use Case Diagram of Event Management System

9
5.2.2 DATA DESIGN

The data design phase focuses on transforming the information domain of the system into data
structures that can be stored, processed, and organized efficiently. It involves identifying the major
data entities, determining how they are related, and designing the databases or data storage items
to accommodate the system's data requirements.

5.2.2.1 Data Description

The data description section explains how the information domain of the system is transformed
into data structures. It outlines how the major data or system entities are stored, processed, and
organized. Additionally, it lists any databases or data storage items used in the system.

In our system, the following data entities are considered:

1. Event: This entity represents an event and includes attributes such as event ID, name, date,
time, location, description, and additional information. The event data is stored in the Event
Repository component.

2. Registration: This entity represents a participant's registration for an event and includes
attributes such as registration ID, participant information, selected ticket type, and
registration status. The registration data is stored in the Registration Repository component.

3. Ticket: This entity represents a ticket for an event and includes attributes such as ticket ID,
event ID, ticket type, and ticket status. The ticket data is stored in the Ticket Repository
component.

4. Attendee: This entity represents an attendee of an event and includes attributes such as
attendee ID, registration ID, and attendance status. The attendee data is stored in the
Attendee Repository component.

10
5.2.2.2 Data Dictionary

Database Entities Attributes Type Description

S Event eventID INTEGER Stores information about
name VARCHAR(255) events, including event ID,
data DATETIME name, date, time, location,
time DATETIME and description.
location VARCHAR(255)
description VARCHAR(255)
EMS Participant participantID INTEGER Stores information about
name VARCHAR(255) participants, including
email VARCHAR(255) participant ID, name, email,
contactInfo VARCHAR(255) and contact details.
EMS Ticket ticketID INTEGER Stores information about
eventID INTEGER tickets, including ticket ID,
participantID INTEGER event ID, participant ID,
type VARCHAR(255) ticket type, and payment
price FLOOT details.
EMS Registration registrationID INTEGER Stores information about
eventID INTEGER event registrations, including
participantID INTEGER registration ID, event ID,
ticketType VARCHAR(255) participant ID, registration
regDateTime DATETIME date, and payment details.
Table 5.1 Data Dictionary of Event management system

5.2.3. Subsystem Decomposition and Description

The architectural design of the Event Management System is based on a modular program
structure, where responsibilities are divided among subsystems. Each subsystem has specific roles
and responsibilities assigned to it, and they collaborate with each other to achieve the desired
functionality.

11
The Event Management System is decomposed into the following subsystems:

1. Event Creation Subsystem:

• Responsibilities:

• Allows event organizers to create new events by providing event details such as
name, date, time, location, description, and additional information.

• Validates the entered event information for accuracy and completeness.

• Stores the event information in the system's database.

• Makes the created event available for registration by interacting with the Event
Management subsystem.

• Collaborates with: Event Management Subsystem to store and retrieve event

information, and Event Registration Subsystem to make the created event available
for registration.

• Components:

• Event Form: Provides a user interface for event organizers to input event details.

• Event Validator: Validates the entered event information to ensure it meets the
required criteria.

• Event Repository: Handles the storage and retrieval of event data in the database.

2. Event Registration Subsystem:

• Responsibilities:

• Enables participants to register for events by providing personal information and

selecting ticket types.

• Validates participant information and ensures its correctness.

• Checks the availability of tickets for the selected event and ticket type.

• Stores the registration details in the system's database.

12
 • Updates the attendee count for the registered event.

• Collaborates with: Event Management Subsystem to check ticket availability and

update attendee counts, and Ticketing and Payment Subsystem to validate ticket
purchases and process payments.

• Components:

• Registration Form: Provides a user interface for participants to input their

registration details.

• Participant Validator: Validates the participant information to ensure it is

complete and accurate.

• Ticket Availability Checker: Checks the availability of tickets for the selected
event and ticket type.

• Registration Repository: Handles the storage and retrieval of registration data in

the database.

3. Ticketing and Payment Subsystem:

• Responsibilities:

• Handles ticketing functionalities for event participants.

• Provides a secure platform for purchasing tickets.

• Integrates with external payment gateways to process payments securely.

• Validates ticket purchases and ensures their authenticity.

• Generates tickets for successful purchases.

• Collaborates with: Event Registration Subsystem to validate ticket purchases and

process payments.

Integrates with external payment gateways for secure payment processing.

• Components:

13
 • Ticket Purchase Form: Provides a user interface for participants to purchase
tickets.

• Payment Gateway: Integrates with external payment services to process payments

securely.

• Ticket Validator: Validates the authenticity of ticket purchases.

• Ticket Generator: Generates tickets for successful purchases.

• Ticket Repository: Handles the storage and retrieval of ticket data in the database.

4. Event Management Subsystem:

• Responsibilities:

• Manages event details, including modifying event information, updating ticket

availability, and handling event cancellations.

• Retrieves event information from the Event Creation subsystem for display and
modification.

• Updates the ticket availability based on registrations and cancellations.

• Notifies the Communication and Notifications subsystem about event changes or

cancellations.

• Collaborates with: Event Creation Subsystem to store and retrieve event information,
Event Registration Subsystem to update attendee counts and handle cancellations, and
Communication and Notifications Subsystem to notify about event changes or
cancellations.

• Components:

• Event Details Viewer: Retrieves event information from the Event Creation
subsystem for display and modification.

• Ticket Availability Updater: Updates ticket availability based on registrations and

cancellations.

14
 • Event Modifier: Handles modifications to event details.

• Event Canceller: Handles event cancellations.

• Notification Sender: Notifies the Communication and Notifications subsystem

about event changes or cancellations.

• Event Repository: Handles the storage and retrieval of event data in the database.

5. Attendance Management Subsystem:

• Responsibilities:

• Facilitates attendance management for event organizers.

• Provides functionality to view and manage participant registrations.

• Tracks attendance for events.

• Generates attendee lists for event organizers.

• Retrieves attendee information for reporting purposes.

• Collaborates with: Event Registration Subsystem to retrieve registration details and

attendance information, and Event Management Subsystem to update attendee counts.

• Components:

• Registration Viewer: Retrieves and displays participant registration details.

• Attendance Tracker: Tracks and updates attendance for events.

• Attendee List Generator: Generates attendee lists for event organizers.

• Attendee Repository: Handles the storage and retrieval of attendee data in the
database.

6. Communication and Notifications Subsystem:

• Responsibilities:

• Enables event organizers to send notifications and updates to participants

regarding event changes, reminders, or cancellations.
15
 • Retrieves participant contact information from the Event Registration subsystem.

• Communicates with external email or messaging services to send notifications.

• Interacts with external email or messaging services to send notifications.

• Collaborates with: Event Registration Subsystem to retrieve participant contact

information.

• Components:

• Contact Information Retriever: Retrieves participant contact information from the

Event Registration subsystem.

• Notification Sender: Sends notifications and updates to participants.

• Email Service: Communicates with external email service to send notifications.

• Messaging Service: Communicates with external messaging service to send

notifications.

7. Reporting and Analytics Subsystem:

• Responsibilities:

• Provides event organizers with reporting capabilities to generate analytics and

insights on event attendance, ticket sales, and participant demographics.

• Retrieves relevant data from the Event Registration and Event Management
subsystems.

• Performs data analysis and generates reports based on specified criteria.

• Collaborates with: Event Registration Subsystem and Event Management Subsystem

to retrieve relevant data for generating reports and performing analytics.

• Components:

• Data Retriever: Retrieves relevant data from the Event Registration and Event
Management subsystems.

16
 • Data Analyzer: Performs data analysis and generates insights.

• Report Generator: Generates reports based on specified criteria.

• Report Repository: Handles the storage and retrieval of report data in the
database.

Subsystem Dependencies:

The subsystems in the Event Management System have the following dependencies:

• The Event Creation subsystem depends on the Event Management subsystem to store event
information and make it available for registration.

• The Event Registration subsystem depends on the Event Management subsystem to check
ticket availability and update attendee counts.

• The Ticketing and Payment subsystem depends on the Event Registration subsystem to
validate ticket purchases and process payments.

• The Event Management subsystem interacts with the Event Creation subsystem to store
and retrieve event information.

• The Event Management subsystem communicates with the Event Registration subsystem
to update attendee counts and handle cancellations.

• The Communication and Notifications subsystem relies on the Event Registration

subsystem to retrieve participant contact information.

• The Reporting and Analytics subsystem retrieves relevant data from the Event Registration
and Event Management subsystems.

17
Figure 5.5 Component Diagram of Event management system

18
5.2.4. Hardware/Software Mapping

Hardware/software mapping describes how subsystems are assigned to hardware . Here, we use
UML deployment diagram to represent the hardware/software mapping diagrammatically

Figure 5.6. Deployment Diagram of Event management system

19
5.2.5. Detailed Class Diagram

Figure 5.7. Class Diagram of Event Management System

20
5.2.6. Persistent Data Management

Figure 5.8. Persistent Diagram of Event Management System

5.2.7. Access Control and Security

User Model and Access Privileges

The access control and security of the event management system are crucial for ensuring the
confidentiality, integrity, and availability of the system and its data. The user model defines the
access privileges assigned to different actors in the system. Here is an example of a global access
table showcasing the access relations between actors, objects, and operations:

21
 Actor Object Operations
Event Organizer Event Create, Update, Delete
Participant View, Add, Remove
Registration View, Add, Remove
Participant Event View, Register
Registration View, Update, Cancel
Administrator Event View, Update, Cancel
Participant View
Registration View
Table 5.2. Global access table of Event Management System

In the above table, different actors such as Event Organizers, Participants, and Administrators are
listed. The objects include Events, Participants, and Registrations. The operations allowed for each
actor-object combination are specified.

Security Mechanisms and Considerations

Authentication: To ensure secure access to the system, an authentication mechanism will be

implemented. This can involve username-password authentication, two-factor authentication, or
integration with external identity providers.

Encryption: To protect sensitive data, encryption techniques will be employed. This includes
encrypting data at rest in the database and during transmission over the network using secure
protocols such as SSL/TLS.

Role-Based Access Control (RBAC): RBAC can be implemented to control access to system
resources based on the roles assigned to users. Each role will have a set of permissions associated
with it, allowing fine-grained control over user privileges.

Secure Communication: Secure communication protocols, such as HTTPS, will be used for
communication between the system components, ensuring data integrity and confidentiality.

22
Key Management: Proper key management practices will be followed to secure encryption keys
and ensure their integrity. This includes generating strong keys, securely storing them, and rotating
them periodically.

User Privilege Management: Access privileges of users will be regularly reviewed and updated
as required. The principle of least privilege will be followed, granting users only the necessary
permissions required to perform their tasks.

Audit Logging: Logging mechanisms will be implemented to record user activities and system
events for auditing and monitoring purposes. This helps in identifying and investigating security
incidents or suspicious activities.

By implementing these security mechanisms and considering security best practices, the event
management system can ensure the protection of sensitive data, prevent unauthorized access, and
maintain the integrity and availability of the system.

5.3. Packages

1. Event Creation Package:

• Files: EventCreator.java, EventEditor.java, EventValidator.java, ...

• Dependencies: depend on the EventManagement package to retrieve event

information and update event details. May also depend on the Ticketing package to
check ticket availability during event creation.

• Usage: This package is responsible for creating and managing events. It provides
functionality for event creation, editing, and validation.

2. Event Registration Package:

• Files: RegistrationForm.java, RegistrationProcessor.java,

RegistrationValidator.java, ...

23
 • Dependencies: depend on the EventManagement package to check event details
during the registration process. May also depend on the Ticketing package to
validate ticket purchases.

• Usage: This package handles participant registration for events. It provides

functionality for registration form processing, validation, and storage.

3. Ticketing Package:

• Files: TicketGenerator.java, TicketValidator.java, TicketManager.java, ...

• Dependencies: depend on the EventManagement package to retrieve event details.

May also depend on the Payment package for ticket payment processing.

• Usage: This package is responsible for ticketing functionalities. It provides

functionality for generating tickets, validating ticket authenticity, and managing
ticket-related operations.

4. Payment Package:

• Files: PaymentProcessor.java, PaymentGatewayAdapter.java,

PaymentValidator.java, ...

• Dependencies: depend on external payment gateway APIs or libraries for payment

processing.

• Usage: This package handles payment processing for ticket purchases. It provides
functionality for payment validation, processing, and integration with external
payment gateways.

5. Event Management Package:

• Files: EventManager.java, EventUpdater.java, EventCanceller.java, ...

• Dependencies: depend on the EventCreation package for event creation and editing.
May also interact with the EventRegistration package to update attendee counts and
handle event cancellations.

24
 • Usage: This package manages the overall event details. It provides functionality for
event management, updates, and cancellations.

6. Attendee Management Package:

• Files: AttendeeListGenerator.java, AttendanceTracker.java,

AttendeeDataAnalyzer.java, ...

• Dependencies: depend on the EventRegistration package to retrieve participant

registrations and attendance information.

• Usage: This package handles attendee management for events. It provides

functionality for generating attendee lists, tracking attendance, and performing data
analysis.

7. Communication Package:

• Files: NotificationSender.java, EmailServiceAdapter.java,

NotificationTemplateManager.java, ...

• Dependencies: depend on the EventRegistration package to retrieve participant

contact information.

• Usage: This package facilitates communication and notifications between

organizers and participants. It provides functionality for sending notifications,
integrating with email services, and managing notification templates.

8. Reporting Package:

• Files: ReportGenerator.java, AnalyticsProcessor.java, DataExporter.java, ...

• Dependencies: depend on the EventRegistration and EventManagement packages

to retrieve relevant event data for reporting and analytics.

Usage: This package provides reporting and analytics capabilities for event data. It provides
functionality for generating reports, performing data analysis, and exporting data.

25
Figure 5.9. Package Diagram of Event Management System

5.4. Algorithm Design

In the algorithm design phase, we define the algorithms required for each element identified in the
architectural design to accomplish their tasks.

Algorithms provide a step-by-step sequence of instructions to solve a specific problem or achieve

a specific task. Pseudocode is used to describe the algorithms in a high-level, language-
independent manner.

1. Event Creation Subsystem:

Algorithm: CreateEvent(eventName, eventDate, eventTime, eventLocation, eventDescription,

additionalInfo)

Input: eventName, eventDate, eventTime, eventLocation, eventDescription, additionalInfo (event

details)

Output: eventID (unique identifier for the created event)

1. Validate the input event details to ensure completeness and accuracy.

2. If the event details are invalid or incomplete, display an error message and handle the appropriate
error handling mechanism.

26
3. Generate a unique eventID for the new event.

4. Create an event object using the input event details and the generated eventID.

5. Store the event object in the Event Repository.

6. Display a success message indicating that the event has been created.

7. Return the eventID as the output.

2. Event Registration Subsystem:

Algorithm: RegisterParticipant(eventID, participantDetails)

Input: eventID (identifier of the event to register for), participantDetails (object containing
participant information)

Output: registrationID (unique identifier for the registration)

1. Validate participantDetails for completeness and accuracy.

2. Check ticket availability for the specified event.

3. If tickets are available:

4. Generate a unique registrationID for the registration.

5. Store registration details (eventID, participantDetails, registrationID) in the Registration

Repository.

6. Update the attendee count for the registered event in the Event Management Subsystem.

7. Return the registrationID as the output.

8. If tickets are not available, display an error message.

3. Ticketing and Payment Subsystem:

Algorithm: TicketingAndPayment(eventID, participantID, ticketType, paymentDetails)

27
Input: eventID (identifier of the event), participantID (identifier of the participant), ticketType
(type of ticket), paymentDetails (object containing payment information)

Output: ticket (issued ticket for the participant)

1. Validate paymentDetails for completeness and accuracy.

2. Calculate the total ticket price based on the ticket type and any applicable fees.

3. Process the payment using the paymentDetails and the total ticket price.

4. If the payment is successful:

5. Generate a unique ticket ID for the participant.

6. Create a ticket object with the eventID, participantID, ticketType, and ticket ID.

7. Store the ticket object in the Ticket Repository.

8. Return the ticket as the output.

9. If the payment fails, display an error message and handle the appropriate error handling
mechanism.

4. Event Management Subsystem:

Algorithm: EventManagement(eventID, action, eventData)

Input: eventID (identifier of the event), action (action to be performed), eventData (data related
to the action)

Output: None (or specific output as per the action)

1. Retrieve the event details for the specified eventID from the Event Repository.

2. If the event does not exist, display an error message and handle the appropriate error handling
mechanism.

3. Based on the action:

a. If action is "ModifyEvent":

✓ Validate and update the event data provided in eventData.

28
 ✓ Store the updated event details in the Event Repository.
✓ Display a success message indicating that the event has been modified.

b. If action is "UpdateTicketAvailability":

✓ Validate and update the ticket availability for the specified eventID based on the data
provided in eventData.
✓ Store the updated ticket availability in the Event Repository.
✓ Display a success message indicating that the ticket availability has been updated.

c. If action is "CancelEvent":

✓ Validate and handle the cancellation of the event based on the cancellation policy and
data provided in eventData.
✓ Update the event status and handle any necessary refund processes.
✓ Display a success message indicating that the event has been cancelled.
5. Attendance Management Subsystem

Algorithm: AttendanceManagement(eventID, action, eventData)

Input: eventID (identifier of the event), action (action to be performed), eventData (data related
to the action)

Output: None (or specific output as per the action)

1. Retrieve the event details for the specified eventID from the Event Repository.

2. If the event does not exist, display an error message and handle the appropriate error handling
mechanism.

3. Based on the action:

a. If action is "ViewRegistrations":

• Retrieve the list of registered participants for the event from the Registration
Repository.
• Display the attendee list to the event organizer.

b. If action is "MarkAttendance":
29
 • Validate the attendee data provided in eventData.
• Update the attendance status for the specified attendee(s) in the Registration
Repository.
• Display a success message indicating that the attendance has been marked.

c. If action is "GenerateAttendeeList":

• Retrieve the list of registered participants for the event from the Registration
Repository.
• Generate an attendee list based on the retrieved data.
• Return the attendee list as the output.
6. Communication and Notifications Subsystem:

Algorithm: CommunicationAndNotifications(eventID, notificationType, notificationData)

Input: eventID (identifier of the event), notificationType (type of notification to be sent),

notificationData (data related to the notification)

Output: None

1. Retrieve the event details for the specified eventID from the Event Repository.

2. If the event does not exist, display an error message and handle the appropriate error handling
mechanism.

3. Based on the notificationType:

a. If notificationType is "EventChange":

✓ Validate the notificationData for event changes.

✓ Retrieve the list of registered participants for the event from the Registration
Repository.
✓ Send event change notifications to the participants using the notificationData.

b. If notificationType is "Reminder":

✓ Validate the notificationData for reminder settings.

30
 ✓ Retrieve the list of registered participants for the event from the Registration
Repository.
✓ Send event reminder notifications to the participants using the notificationData.

c. If notificationType is "Cancellation":

✓ Validate the notificationData for cancellation details.

✓ Retrieve the list of registered participants for the event from the Registration
Repository.
✓ Send event cancellation notifications to the participants using the notificationData.
7. Reporting and Analytics Subsystem:

Algorithm: ReportingAndAnalytics(eventID)

Input: eventID (identifier of the event)

Output: analyticsData (generated analytics and insights)

1. Retrieve the event details for the specified eventID from the Event Repository.

2. If the event does not exist, display an error message and handle the appropriate error handling
mechanism.

3. Retrieve the list of registered participants for the event from the Registration Repository.

4. If the list of registered participants is empty, display a message indicating no registrations are
available.

5. Perform the following analytics and generate insights based on the retrieved data:

✓ Calculate the total number of registered participants:totalParticipants =

CountParticipants(registrations)
✓ Calculate the total number of attendees: totalAttendees = CountAttendees(registrations)
✓ Calculate the attendance percentage: attendancePercentage = (totalAttendees /
totalParticipants) * 100
✓ Generate a demographic breakdown of participants based on age, gender, location, etc.
✓ Generate ticket sales analysis: revenue = CalculateRevenue(registrations)
✓ (Additional analytics and insights can be added as required)
31
6. Store the generated analytics and insights in the Analytics Repository.

7. Return the analyticsData as the output.

5.5. User Interface Design

In the Event Management System, user interfaces play a crucial role in facilitating user interactions
and providing a seamless experience. The following are some screen of the system.

5.6.1. Create Event Page

32
5.6.2. Register Participant Page

33