CodeCrafters - Compulsory Assignment

q
Computer Science, 2. Semester
Erhvervsakademi Sydvest, Esbjerg

Meile Kapisaite
Andrei Ionut Grosu
Nelson Veríssimo

Date: 19/04/2024
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Preface

EcoStruxure IT Software Services in Schneider Electric provide various services, such as

installation, customization services and configuration. It is a global organization with personnel
located in various regions and countries, aiming to serve both local and global market.
Currently the rates for personnel are calculated in an excel sheet, which poses a high risk in
errors and inefficiency, as this is a very manual task to execute with limited possibilities.

This report documents the development process of a dynamic rate calculation application for
EcoStruxure IT Software Services. Conducted over a multi-week period, this project is aimed at
replacing the current error-prone and manual Excel-based system with an efficient, reliable
application. This new application will facilitate the calculation and overview of regional and
country day rates, supporting the global operations of EcoStruxure IT Software Services.

Our project journey started with an introduction to the case and initial preparation, followed
by development cycles which adhere to the agile methodologies. Two review meetings were
held in this cycle to evaluate our progress, gather feedback and improve our application in
order to ensure that technical and functional requirements made by stakeholders are
followed.

Through vigilant work our team managed to build an application which has 100% of the
features initially requested by the stakeholders. The application we developed allows users to
experience comfortable work when inputting various employees, calculating rates for
employees, teams, regions and countries, modelling distribution, managing teams and seeing a
good overview of the state.

Given the complexity of the application, we focused our documentation on the most critical
user stories and essential code snippets, providing a clear understanding of the system's core
functionalities and technical implementations

1 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Contents
1 Introduction........................................................................................................4
1.1 Background............................................................................................................4
1.2 Problem definition..................................................................................................4
1.3 Product vision.........................................................................................................4
1.4 Strategic analysis....................................................................................................5
1.4.1 Stakeholder Analysis.........................................................................................................5
1.4.2 Risk Analysis......................................................................................................................6

2 Pre-Game/Background.......................................................................................8
2.1 Project organization...............................................................................................8
2.1.1 Roles..................................................................................................................................8
2.1.2 Tools..................................................................................................................................8
2.1.3 Definition of Done.............................................................................................................9
2.2 Overall Project schedule.......................................................................................10
2.2.1 Work Breakdown Structure.............................................................................................10
2.3 Initial product backlog..........................................................................................10
2.4 Architecture.........................................................................................................11
2.5 Low-Fidelity Prototype.........................................................................................15
2.5.1 Main screen.....................................................................................................................15
2.5.2 Customizable ticket screen..............................................................................................15
2.5.3 Special ticket screen........................................................................................................16
2.5.4 Selling ticket screen.........................................................................................................17
2.5.5 Single page application....................................................................................................17

3 Sprint 1.............................................................................................................19
3.1 Sprint planning.....................................................................................................19
3.2 GUI.......................................................................................................................20
3.2.1 Create event view...........................................................................................................20
3.2.2 Add ticket view................................................................................................................21
3.2.3 Event coordinator main page..........................................................................................22
3.3 Data model...........................................................................................................22
3.4 Implementation....................................................................................................24
3.4.1 As an Event Coordinator, I want to be able to create events..........................................24
3.4.2 As a User, I want to have a main window with the upcoming events information.........24
3.4.3 As an Event Coordinator, I want to be able to create event tickets for customers,
ensuring each ticket contains a unique QR code and corresponding 1D barcode............................26
3.5 File Handler..........................................................................................................27
3.6 Design Patterns.....................................................................................................27
3.6.1 Singleton.........................................................................................................................27
3.6.2 Observable......................................................................................................................28

2 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3.7 Sprint Review.......................................................................................................28

3.8 Sprint Retrospective.............................................................................................28
3.8.1 What went well?.............................................................................................................29
3.8.2 What to do better, to improve next time?......................................................................29

4 Sprint 2.............................................................................................................30
4.1 Sprint planning.....................................................................................................30
4.2 GUI.......................................................................................................................31
4.2.1 Login view.......................................................................................................................31
4.2.2 Selling view......................................................................................................................32
4.2.3 Event management view.................................................................................................33
4.2.4 Ticket management view................................................................................................36
4.2.5 Add ticket view (on create event view)...........................................................................37
4.2.6 Special tickets view.........................................................................................................38
4.2.7 Administrator page main view window...........................................................................38
4.3 Implementation....................................................................................................43
4.3.1 As an Event Coordinator, I want to sell tickets to customers..........................................43
4.3.2 As an Admin/Event Coordinator, I want to log in using a username and password........46
4.3.3 As an Event Coordinator, I want to manage events........................................................47
4.3.4 As a User, I want to delete events (Admin and Event Coordinator)................................48
4.3.5 As a User, I want to search for an event..........................................................................49
4.3.6 As an Event Coordinator, I want to add/create “special” tickets.....................................50
4.4 Design Patterns.....................................................................................................51
4.5 Sprint Review.......................................................................................................52
4.6 Sprint Retrospective.............................................................................................52
4.7 What went well?..................................................................................................53
4.8 What to do better, to improve next time?.............................................................53
5 Test Documentation..........................................................................................54
5.1 Junit tests for the AdminManagementLogic..........................................................54
6 Conclusion........................................................................................................55
7 Appendices.......................................................................................................56
7.1 Group contract.....................................................................................................56

3 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

1 Introduction

1.1 Background

As a global entity, EcoStruxure IT Services (provided by Schneider Electric) has a workforce

dispersed across various regions and countries, aiming to serve both local and international
markets effectively.
Currently, the organization calculates its regional and country day rates for these services
manually using an Excel spreadsheet. As these rates form the foundation for the company's
performance and financial health, there is a critical need for a more reliable and automated
solution.

Recognizing this need, Schneider Electric has collaborated with Business Academy South-West
(EASV) to provide a project for the final exam for the students of the first year. The focus of
this project is to develop a tool that can dynamically and accurately calculate these rates,
thereby enhancing operational efficiency, reducing possibility of errors and improving business
accuracy. This project was developed by Andrei Grosu, Meile Kapisaite and Nelson Veríssimo.

The proposed system involves functionalities such as geography management, employee

management, rates overview by region, country or team, teams management, history and
possibility of distributing costs between teams. Implemented in Java using JavaFX and
leveraging MSSQL Server for data persistence, the project adheres to Scrum methodologies and
incorporates design patterns to ensure a structured development process.

1.2 Problem definition

The current method of calculating daily and hourly rates is inefficient and error-prone. Relying
on Excel spreadsheets, it’s a manual process and susceptible to mistakes such as typos, that can
cause inaccurate calculations, therefore, leading to incorrect conclusions. The current system
does not accommodate the dynamic nature of the organization, which frequently adjusts its size
and operations according to market demands. Moreover, tracking historical rate calculations is
challenging, making it difficult to understand the basis for rates at any given point in time. As
the daily and hourly rates are crucial for assessing the organization's performance, it is essential
to have a streamlined, accurate, and automated system for rate calculation and management. An
efficient tool is needed to support the continuous adjustments in the organization and to ensure
the reliability and integrity of the rate calculation process, which is fundamental to maintaining
a healthy business.

1.3 Product vision

The purpose of this app is to be a tool for Schneider Electric that will assist in managing the
costs of their products by accurately accounting for the overhead costs of employees and
teams. The tool will provide insights into the cost distribution across different teams enabling
better budget allocation and cost-saving strategies.

4 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

This product addresses the following pain points:

 High likelihood of errors and typos: our system prevents the user to enter invalid
data through an input validation process, thereby reducing the risk off errors and
typos.
 Very manual way of working with rates: our system automates the calculation of
employee and team rates, updating day rates and hour rates whenever there are
changes in employee cost values. This automation also applies when an employee is
removed from the system, taken off a team, or their utilization within a team
changes. Additionally, the process of overhead distribution is automated, ensuring
that new team rates are calculated seamlessly.
 Hard history navigation: our system facilitates easy history navigation by saving
all operations related to employee and team overhead calculations. Users can easily
navigate to specific points in the history to see which values were used.
Additionally, the system provides a graph that displays an employee's history for a
specific year.

Primary Features:
 Employees creation: creating a new employee in our system is a seamless process.
The system enforces the entry of only valid data through a robust validation
process. Additionally, users can easily assign the newly created employee to
existing teams within the system.
 Team management: the system provides an intuitive interface for team
management, allowing users to easily add or remove employees and adjust their
utilization. By using charts, this process also becomes visual, enabling users to
dynamically see team modifications.
 Overhead distribution management: this process allows users to simulate
different values for the teams selected for the overhead distribution process before
the results are saved into the teams' history. It also includes validation checks. For
example, if the distribution percentage exceeds 100%, the user will be informed via
a message, and the distribution process will not be executed.
 Region management: allows users to efficiently create and manage regions within
the system through an intuitive interface. This tool streamlines the process, ensuring
that users can easily define and modify regional settings to suit their organizational
needs.

Business Objectives:
By automating the calculation of employee and team rates and incorporating robust
input validation, the app minimizes errors and inconsistencies, ensuring more reliable financial
data.

The app facilitates better decision-making by allowing managers to simulate different overhead
distribution scenarios and visualize their impact before finalizing changes. Administrative
processes are streamlined through intuitive interfaces for creating and managing employees,
teams, and regions, reducing overhead and enhancing user experience. Easy access to historical
data supports performance analysis and future planning.

The app promotes cost transparency by providing a clear view of overhead cost distribution and
utilization, fostering transparency and accountability. It also supports proactive cost

5 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

management by enabling dynamic adjustments to team compositions and utilization rates based
on real-time data.

1.4 Strategic analysis

1.4.1 Stakeholder Analysis

Figure 1: Interest-power matrix.

Keep Satisfied: Client

The client holds a significant level of power in the project as they are the primary stakeholders
funding and driving the development of the event management system. While their day-to-day
involvement might not be as high as other stakeholders, their interest in the project's success
remains substantial. Keeping the client satisfied is crucial to maintaining a positive working
relationship and ensuring their needs and expectations are met throughout the project.

Manage Closely: Developers and Scrum Master

The developers and Scrum Master hold high levels of power and interest in the project.
Developers are directly responsible for implementing technical requirements and ensuring the
successful delivery of the event management system. They posesess technical skills and
knowledge critical for the project's execution. The Scrum Master, on the other hand, plays a
pivotal role in managing the Scrum framework, facilitating communication within the team, and
removing any obstacles hindering progress.

6 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Keep Informed: Teachers, Customers, Admin, Coordinators, and Competitors

While these stakeholders may not have as much direct power over the project's execution, they
have a high level of interest and play important roles in its success. Teachers are invested in the
educational outcomes of the project, providing guidance and feedback to students throughout
the development process. Customers, including end users, admin, and event coordinators, are
vital for providing insights into user needs and ensuring the system meets their requirements.
Competitors also play a crucial role, influencing market dynamics. Keeping these stakeholders
informed ensures their needs are considered, feedback is incorporated, and potential risks are
identified and addressed effectively.

1.4.2 Risk Analysis

Risk Level of Risk Risk Management

Illness low Should a team member become ill, fast
notification of the group is important.
Remote work can serve as a backup plan
unless the illness significantly affects
productivity.
Team Conflicts medium Given the potential for conflicts in
groups, keeping open communication
and embracing democratic decision-
making processes are essential for
effective conflict resolution.
Loss of data Medium/high GitHub is used for version control and to
avoid data loss, frequent commits should
be done.
Improper time management high Disregarding proper time management
practices poses a significant risk to
project success. Ignoring time
management could result in inefficient
resource allocation and hinder the
project’s overall productivity and
success.
Loss of Customer Extreme Recognizing the heightened competition,
ongoing refinement based on customer
feedback is crucial for mitigating the risk
of customer loss
Table 1: Risk Analysis

7 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

2 Pre-Game/Background
2.1 Project organization

2.1.1 Roles

Roles Responsibilities
Product Owner o Crafting a product vision that meets the
Schneider Electric specifications of the client and stakeholders.
o Relaying both initial and updated product
requirements to the team.
o Providing feedback during review meetings in
order to get the best possible result.
Scrum Master o Setting up effective communication channels
Nelson Veríssimo within the team.
o Maintaining adherence to Scrum methodologies
throughout the project.
o Leading daily stand-up meetings to ensure team
alignment.
o Resolving any issues faced by the team promptly.

Team Members o Committing to high-quality deliverables.

Nelson Veríssimo o Ensuring alignment with the product vision and
Meile Kapisaite sprint objectives.
Grosu Ionut-Andrei o Working closely with team members to improve
organization.
o Estimating task requirements and accurately
tracking work hours.
o Actively participating in daily stand-up meetings
to share updates and help each other.
Table 2: Roles in the project

2.1.2 Tools
For this project, we will use a variety of tools to ensure efficient work development and
management. The main tool for development of this project will be IntelliJ IDEA serving as our
development environment for programming with Java language. This tool will help us to
improve our process by providing debugging and other features offered. For version control and
code storage, we will use GitHub as a main tool. We will maintain a main repository and each
team member will create their own local and remote branches to ensure a smooth process. Each
team member will be responsible for merging and any conflicts solving, but we will also help
each other in more severe merging conflicts.

8 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

In addition to our development tools, we will utilize Scrumwise for task management,
assignment, time tracking and sprint planning. This tool will assist us in helping to organize and
complete our project in a timely manner. Furthermore, another tool that will be used in this
project will be Figma for creating prototypes of our application. Figma will allow us to design
our application before we start the real one, which will allow us to have a cohesive design
throughout our application.

2.1.3 Definition of Done

According to Huether (2021), the “Definition of Done” (DoD) ensures that development quality
stays high by establishing clear guidelines which a software product must meet to be considered
complete. Various organizations use different definitions of this term, but in the end the goal
remains the same, to prevent incomplete features from being delivered to customers. At the user
story level, DoD includes passing unit tests, code reviews, and meeting acceptance criteria. The
consistent application of a clear DoD is essential for reducing refactoring and ensuring that
deliverables meet all required standards (Huether, 2021).
In this project we have tried follow this definition, as it was crucial that we do not stray away
from delivering a complete application. In order to do so we established that once a backlog
item is fully complete we count it as done. At the start of each sprint we distributed the backlog
tasks among us ensuring a clear line of what needs to be done by who until what time. When a
task was finished the team member was responsible to test to ensure that everything was
completed according to the description of the task. After completing an entire backlog the team
tested the implemented backlog together to ensure that nothing was missed. If the backlog was
approved by the group it was put as completed.

2.2 Overall Project schedule

9 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

2.3 Overall Project schedule

2.3.1 Work Breakdown Structure

Figure 2: WBS for the project.

2.4 Initial product backlog

Our initial product backlog, with all the user stories and functionalities based on the
requirements of the project.

1. User Authentication and Access Management:

 As an Admin or Event Coordinator, I want to log in using a username and
password.
 As an Admin, I should be able to create and manage all other users.
 As an Admin, I should be able to assign coordinators and delete events.

10 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

 As an Event Coordinator, I should be able to manage events.

 As an Event Coordinator, I should be able to add tickets to events (only for
events assigned to me by the admin).

2. Event Management:
 As an Event Coordinator, I should be able to create events and manage event
information such as Time, Location, Name of Event, Notes, etc., including
optional information.
 As an Event Coordinator, I should be able to assign other coordinators to have
access to events.

3. Ticket Generation and Management:

 As an Event Coordinator, I should be able to print event tickets for customers,
either physically or by email (PDF or Image) ensuring each ticket contains a
unique QR code and corresponding 1D barcode.
 As an Event Coordinator, I should be able to add/create “special”
(customizable) tickets to events (e.g., Free Beer, VIP Ticket, etc.).
 Each ticket must be connected to the name and email address of the customer
who bought the ticket. One customer can buy multiple tickets.
 We must be able to print separate free tickets for an event, such as "one free
beer", "50% off one drink", "1 set of free earplugs", etc.

4. Customer Management:
 As an Event Coordinator, I should be able to create, manage, and delete
customers.
 As an Event Coordinator, I should be able to assign tickets to customers or
assign customers to tickets when selling.

2.5 Architecture
Our project employs the MVC (Model-View-Controller) architectural pattern within the
presentation layer. This approach allows us to effectively separate user interactions from the
actual state and logic of the application. By dividing the layer into Model, View, and Controller,
we enhance clarity and maintainability.

The business logic layer provides a crucial separation between the presentation layer and the
underlying application logic. This separation not only decouples the view from the logic but
also simplifies extensions to the application. It is designed to easily incorporate additional layers
that can interact with various models or even the same model, enhancing flexibility and
scalability.

Responsible for data management, the data access layer handles the storage and retrieval of
data. It operates with both databases and local storage files, ensuring efficient data accessibility
and integrity.

To ensure that the Event Management and Administrator modules operate independently, we
have implemented separate models, each backed by its own business logic layer.

11 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

This design allows each module to function autonomously, enhancing maintainability and
scalability. In the data access layer, however, we have optimized our resources by reusing some
functionalities across both modules. This approach not only reduces redundancy but also
ensures consistency in data handling.

Our system accommodates two types of users: Admin and Event Coordinator. To facilitate this,
we have structured our project with a login layer that determines which part of the application to
grant access to, based on the user's role either "admin" or "event coordinator".

This role-based access control ensures that each user experiences a tailored interface and
functionality specific to their responsibilities and permissions.

Figure 3: Model View Controller Architecture

The image above (Figure 3) illustrates the relationships between the Event Coordinator model,
the Business Logic Layer, and the Data Access Layer. This diagram provides a visual
representation of how these components interact within our system.

12 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 4: Event Coordinator Layer Architecture

Figure 5 illustrates the relationship between the Administrator Layer of the application and its
associated Business Logic Layer and Data Access Layer. This diagram provides a clear
visualization of how these components are interconnected within our system.

Figure 5: Administrator layer architecture.

13 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Our system also includes components that are independent of the specific layers and can be
utilized by both. One such component is the "delete" feature, which is used by both layers, each
providing the necessary functionality.

Figure 6: Delete component architecture.

Similarly, the "search" component is designed for use across both application layers, adhering to
the same requirements as the delete component.

Figure 7: Search component architecture.

14 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

2.6 Low-Fidelity Prototype

2.6.1 Main screen

Figure 88: Main screen sketch.

This low-fidelity prototype presents the main screen upon user login, featuring a centralized
table providing an overview of events. Within this layout, users have easy access to core
functionalities such as event creation through a prominent button. Additionally, the top section
offers quick navigation to specialized features, including ticket management, sales tracking, and
user administration, enhancing user efficiency and engagement. This design prioritizes clarity
and accessibility, laying a solid foundation for a user-friendly event management platform.

2.6.2 Customizable ticket screen

Figure 99: Customizable ticket sketch.

15 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

The prototype in figure 9 showcases a customizable ticket interface, presenting users with a
visual representation of the ticket at the top of the screen. Beneath this preview, users can
interact with customizable ticket information fields, enabling them to input details such as ticket
type, colour, price and more. As users input data, they receive instant feedback, dynamically
updating the ticket preview above to reflect the changes made. This intuitive design empowers
users to tailor ticket information to their specific needs while providing real-time visual
feedback and interactive ticket customization experience.

2.6.3 Special ticket screen

Figure 1010: Specials ticket screen sketch.

The special ticket screen is divided into two distinct sections for efficient management and
customization. On the left side, users are presented with a dropdown menu to select an event of
interest. Below this, a list displays all tickets associated with the selected event, providing users
with the option to edit ticket details as needed. Meanwhile, the right side of the screen offers a
visual representation of the selected special ticket, allowing users to customize its appearance
and attributes. Additionally, users can assign the special ticket to a specific event and receive
real-time visual feedback on how the customized ticket will appear.

2.6.4 Selling ticket screen

Figure 1111: Selling screen sketch.

16 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

In the selling screen of your low-fidelity prototype, users are provided with a simple interface
for managing ticket sales efficiently. The screen features input fields for capturing buyer
information such as name, last name, and email address. Additionally, users can select the
desired event from a dropdown menu and choose tickets from the available options.
Furthermore, users have the ability to select special tickets and add them to the sales list, where
they can review and remove items as needed. Users also have options to cancel, save, and print
tickets, facilitating seamless transaction management.

2.6.5 Single page application

Figure 1212: FXML swapping and layering.

Nowadays single-page application (SPA) architecture is widely used and normal due to its
ability to provide a seamless user experience by updating content in a single page. Therefore,
our desktop application uses (SPA) as well.

In JavaFX, SPAs can be implemented by utilizing FXML for defining individual "pages" or
sections of the application, and Stack Panes for layering and content swapping. Each "page" of
the application is represented by a separate FXML file, which defines the layout and
components specific to that page. Stack Pane, a layout pane in JavaFX, is used as the root node
of the application. It allows children nodes to be stacked on top of each other, facilitating the
layering of different views.

Besides the Stack Pane, we also manipulate children within layout panes to achieve content
swapping seamlessly. For example, we switch the children of main layout with children from
another FXML to load selling page or special tickets page in child that holds the overview of the
tickets. The transition between these sections occurs swiftly, giving users the impression of
navigating between distinct pages while remaining within the same application window.

17 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3 Sprint 1
3.1 Sprint planning
After receiving information about our project, we held a team meeting where we planned our
further actions before the sprint started. During this session we discussed about our project and
brainstormed the user stories. Once we had enough user stories, we decided to prioritize the
most important ones. This approach allowed us to allocate resources well, especially
considering the time constraints imposed by the project. That is why we knew that even if we
run out of time, the most important functions will be completed.

Due to fist sprint being very short, we have set only 38 hours collectively. We have chosen three
user stories for this sprint, one user story per person. Although it was only three user stories,
they were the most important ones and required a lot of effort to complete. We were determined
that we will be able to finish these stories in time. Estimating time for user stories and tasks was
tough. Each story had its own complexities and breaking them down into tasks added more
layers of difficulty. We decided to roughly split the time almost equally for each story and
estimated the time for the tasks based on our previous project experience.

18 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 1313: First sprint backlog.

3.2 GUI
3.2.1 Create event view

19 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 1414: Create event view.

We have chosen to use beige background to fit the colour palette of our application as well as
bring a little contrast between elements in the view. The white box with rounded edges serves as
a focal point within the interface, effectively organizing the input fields for event details such as
name, date, description, and location. By encapsulating these elements within a visually distinct
container, users can easily identify and interact with the relevant information without
distraction.

Furthermore, the use of rounded edges softens the overall look of the interface, creating a sense
of harmony and balance in the design. In addition, incorporating coloured buttons, such as blue
for cancel and green for save, adds a pop of colour and visual interest to the interface. These
colour buttons serve as intuitive indicators, guiding users to perform specific actions with
clarity.

20 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3.2.2 Add ticket view

Figure 1515: Add ticket view.

Initially, to create a ticket (when the user presses “Add ticket”), we decided the user could
design the ticket in the first place (Figure 15).
For this, following the colours of our application, we applied some contrast on the main colour
(beige / brownish) to differentiate this pane from the event’s one. Here the highlight is the ticket
itself, and how the user wants the ticket to look like, the user can personalize the ticket colour
and the identification of the ticket (type), the price and quantity are fixed values. While
personalizing, the user has a visualization of this in real time, so it facilitates user’s choice.

21 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3.2.3 Event coordinator main page

Figure 1616: Event coordinator main page.

The main page of the Event Coordinator layer is designed for optimal user accessibility. It
features a navigation bar equipped with buttons for Events, Selling, and Special Tickets pages,
providing easy access to all subparts of the application.

Create Button: Prominently visible and designed to contrast with the application’s colour
palette to highlight its importance, the Create button’s background colour is deliberately chosen
to stand out.

Events Description Boxes: These boxes follow the same colour palette as the Create button to
ensure they are easily noticeable against the rest of the content.

Edit Icon: Located within the event description box, the edit icon matches the colour of the
surrounding text, subtly indicating its association with event management.

Delete Button: This button is coloured red, making it visually distinct from other elements and
signalling the potential risk of data loss associated with its function.

3.3 Data model

We identified the essential information required for persistence in the database and structured it
accordingly. Utilizing database normalization forms, we developed the database architecture as
shown in the image below (Figure 17). This illustration provides a clear visual representation of
our database's structure.

22 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 1717: Data Model.

We have identified the key business

entities necessary for mapping to
our database model to facilitate data
usage within our application. These
entities include:

Event Entity: Stores data related to

various events.

User Entity: Contains information

pertaining to users within the
system.

Ticket Entity: Holds data relevant

to tickets, establishing a connection
between customers and events.

These entities are crucial for

managing relationships and
interactions within our system.

Figure 1818: Business entities.

23 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3.4 Implementation
3.4.1 As an Event Coordinator, I want to be able to create events

In the event creation feature, we have developed user interface using JavaFX, consisting of
input fields for event details like name, description, start and end dates, start and end times, and
location. In the controller class CreateEventController, upon successful validation of event
details, the controller constructs an Event object with the provided information. The event
object is then passed to the model, manager and finally DAO layer to be inserted into database.

The validation process implemented in the event creation feature was crucial for ensuring data
integrity and enhancing user experience. It involved various techniques and strategies to
validate user inputs effectively. One interesting aspect was the utilization of JavaFX pseudo-
classes, which allowed for dynamic styling of input fields based on their validity state. This
feature provides immediate visual feedback to users, highlighting invalid inputs and guiding
them to correct any errors promptly. Additionally, real-time event listeners were employed to
monitor changes in input fields, enabling instant validation and error detection.

Figure 1919: End date checker.

This code snippet defines a method EndDateChecker() that sets up a listener for changes in the
endDate property. When the endDate changes, it checks if the new value is before the startDate.
If it is, it sets the endDate back to null and displays an error message indicating that the end date
cannot be before the start date. Additionally, it schedules a task to clear the error message after
5 seconds using a PauseTransition.

3.4.2 As a User, I want to have a main window with the upcoming events information.
The main window of the Event Coordinator displays all events related to that coordinator,
providing not just basic event information—such as name, start/end date and time, and available
tickets—but also actions related to event management. Additionally, it shows the status of each
event, categorized as Upcoming, Ongoing, or Finalized.

Events are sorted based on their status and starting date. Those with starting dates closest to the
current date are displayed at the top, ensuring easy access to the most immediate events.

24 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

To achieve the desired appearance for each event, we developed a custom component that is
dynamically generated based on the data retrieved from the database. Each component is
designed to encapsulate all necessary information for managing and deleting operations.

Figure 2020: Event Description component.

The page includes a dynamic feature that checks the start date and time of each event every
minute and compares it with the current date and time. Based on this comparison, the status of
the event is updated accordingly.

Figure 2121: Event status update handler.

25 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

3.4.3 As an Event Coordinator, I want to be able to create event tickets for customers,
ensuring each ticket contains a unique QR code and corresponding 1D barcode.

Figure 2222: Method to add a ticket to event.

For the backlog item mentioned above, the code snippet (Figure 22), implements the
functionality to add ticket to an event.
Overall, this method manages the addition of new tickets in response to some action (in this
case, button click). It ensures validation of ticket information, creates and updates
corresponding GUI components, handles user interactions and performs necessary model
updates.

Firstly, we check if the inputs for the ticket information are valid (using TicketValidator class).
If the requirements are not met, the application will warn the user that the inputs are not valid
and will provide guidance to the user. If the validation is successful, a Ticket object is created
using the inputs, this object will encapsulate the details about the ticket type, quantity, and price.

26 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

After ensuring we have all the information needed to create and display the ticket, we
dynamically create the GUI components. A Hyperlink is used to display the ticket type and give
the possibility to the user to click on this link to edit a created ticket (underlined to indicate it is
clickable). It’s showed the quantity as well and a button “Remove” to delete this object /
component.
To edit or remove a ticket, we have event handling where we are passing the corresponding
ticket object and its parent (VBox), so we can perform the operations of editing, creating a new
ticket component and deleting the previous one, and removing where we simply delete the ticket
components from the GUI.
Regarding saving this on the database, we only perform this operation when the user clicks to
save the event, so the model is responsible for managing a list of tickets to be added to the
database and assigning these to the corresponding event. This list is updated when we add or
remove a ticket from the GUI with the methods getNewAddedTicket() and removeTicket().
After finishing adding a ticket to the event, closeWindow() method is called so we disable and
set the visibility to false of the stack pane where this window was, so we return to the previous
pane (create event).

It was challenging to dynamically achieve this, because we are creating components and
allowing the user to manage these components afterwards with event handling, then we need to
make sure that we get the correct information to create, update or remove a ticket. Also, the fact
that we only save this when we save the event brought even more challenge since we needed to
save the state of the inserted tickets precisely and correctly so we could later save it on the
database (together with the event).

3.5 File Handler

To safeguard our database credentials, we created a CSV file to store the login data. This file
was then added to the gitignore to prevent it from being tracked by version control systems.

To retrieve the login data securely, we implemented a FileHandler module. This module reads
from the CSV file and returns the parsed data as a string array. This data is then utilized by the
Connection Manager class for establishing database connections.

3.6 Design Patterns

3.6.1 Singleton

During this sprint we have implemented singleton design pattern to ensure there is only one
instance of the Model class throughout the whole application. By enforcing a single instance of
the Model class, we ensured that all components of our application interact with a consistent
and centralized data source. This was crucial for maintaining data integrity and avoiding
conflicts that could arise from multiple instances attempting to modify the same data
concurrently.

Although singleton allows for easy management of global state of the application, it also has
some drawbacks. Singleton leads to tight coupling between components which might result in
challenging maintainability and testing. Besides this fact, singleton poses many other

27 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

challenges, but we have chosen to use in order to reduce the overall complexity of the
application.

3.6.2 Observable
To ensure dynamic updates of displayed event statuses, we implemented an observer interface
alongside its respective implementation. This setup continuously monitors for any changes by
comparing the scheduled event date and time with the current time. Should there be any
alterations in the event status, all subscribers are promptly notified. This mechanism guarantees
that the displayed statuses are consistently accurate and up to date.

3.7 Sprint Review

Our first sprint review was very successful. Both Product Owner and Stakeholders were very
pleased with the value that our program and functionalities had at the time of this review
meeting. We were able to implement all user stories, only some small technical tasks were not
completed, but these didn’t compromise what we had implemented so far, therefore our
presentation could be done as planned.

The teachers feedback was tremendously positive, they were amazed by the amount of work
(functionalities) we were able to complete in a short period of time. Not just related to the
project itself, but they also congratulated us for the fact that we managed very well our work
using Scrumwise, since this is the first time we have used this tool more professionally.

Our main critiques were related to the design of the application (mainly the colours that were
used on panes, buttons, etc.), which we took into consideration for the next sprint. Also, the
tasks that were not finished, were transferred for the second sprint, giving these tasks priority to
develop.

3.8 Sprint Retrospective

Figure 2323: Burndown chart Sprint 1.

28 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Our burndown chart shows that we had a steep rise at the start, which was caused by adding a
big backlog after the sprint started. In the beginning it was difficult to estimate time, user stories
and tasks, but from the burndown chart we can see that our work quickly improved after the
initial mistake.

3.8.1 What went well?

The product owner was satisfied with progress that we have made in the short period of time we
have before Sprint one review meeting. Our idea to start with essential parts of the application,
like event creation, event table and ticket creation instead of login proved to be successful
because we had a lot to show and discuss.

3.8.2 What to do better, to improve next time?

For the upcoming review, we will focus on presenting only fully functional features, ensuring
that all demonstrated capabilities are operational. Additionally, we will address the structuring
of Epic Stories by dividing them into smaller, more detailed user stories. This approach will
facilitate better understanding and tracking of progress, enhancing both the manageability and
clarity of our project goals.

29 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4 Sprint 2
4.1 Sprint planning
After completing our initial brief sprint, we successfully identified all the user stories required
to meet the application's specifications. Considering our ongoing class schedules, we have
agreed that each team member will dedicate four hours per day to this project. However, this
schedule does not account for the upcoming Easter holiday. Based on our commitments and
timelines, we estimate that a total of 143 hours will be needed to complete this sprint
successfully.

Utilizing the planning poker technique for planning and estimation, we assigned a specific
amount of time to each task. This method allowed us to collaboratively assess the effort
required for each component of the project, ensuring a well-informed and balanced allocation of
time for task completion.

Based on the user stories we identified, we divided them into specific tasks. Each team member
then selected tasks to implement according to their personal preferences. This approach ensures
that everyone is working on aspects of the project they are most interested in, promoting
engagement and efficiency.

Based on our time estimations, we decided to incorporate an additional feature that enhances
our system with a search functionality. This new feature will enable users to determine if a
specific entity exists within the system. Specifically, it will allow for the searching of events by
name, and users by last name, providing a more efficient and user-friendly experience.

Figure 24:24 Sprint 2 backlog.

30 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2 GUI
4.2.1 Login view

Figure 2525: Login view.

The login view of our application was designed with functionality and aesthetics in mind.
Visually, the view features a sleek and modern design, characterized by a semi-transparent
black background with rounded corners, which effectively directs the user's attention to the
login form. In addition, we have placed the transparent black background centrally within the
interface in order for it to be the main focus visually.

Furthermore, we chose to implement a blue colour scheme for the login to maintain consistency
with the design theme of the application. Blue hues were adopted as accent colours across
various views, ensuring a cohesive visual experience for users. Additionally, a background
image depicting people celebrating was strategically incorporated to convey the essence of the
application's focus on events.

Moreover, we included application's logo and name at the top of the interface to serve a dual
purpose of branding and context-setting. By prominently displaying the logo alongside the
application name, users are reminded of the application's identity and purpose.

31 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2.2 Selling view

Figure 2626: Selling view.

The selling view was designed to facilitate the process of selling tickets to customers in a user-
friendly and efficient manner. We have placed a blue background on top of white to make the
essential parts of the selling stand out more. We decided to make the layout clean and intuitive
to enhance the user experience. The blue rounded background is divided into two main sections:
customer details and ticket selection.

In the customer details section, clear labels facilitate the input of essential information like
name, last name, and email address, ensuring accurate data collection. The well-organized
layout, with appropriate spacing and alignment, enhances readability and usability.

Meanwhile, the ticket selection section offers dropdown menus for choosing events and tickets,
alongside options to specify quantities. A dynamic list summarizes selected tickets, enabling
users to review choices before finalizing sales.

32 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2.3 Event management view

Figure 2727: Event management page.

The Event Management page adheres to the same colour palette as the rest of the application. A
distinctive feature is the introduction of red around input fields to indicate invalid inputs. For
instance, as shown in Figure 27, the starting date field is highlighted in red because the date
entered is ahead of the current date, which is invalid.

The Ticket Management subpage maintains consistency with the design of the event description
component. This uniformity ensures a cohesive and appealing visual experience across the
platform. Similarly, the 'Add Ticket' button follows the same design principles to maintain
familiarity and ease of use for users.

When an event coordinator opts to delete an event or a ticket, a confirmation window is

displayed to emphasize that the operation is permanent. This window adheres to the same colour
palette as the rest of the application. However, to visually communicate the nature of each
action, we use colour variations for the buttons: a shade of green for the 'Cancel' button
symbolizes that cancelling the operation will not harm the application, while a shade of red for
the 'Confirm' button indicates that the operation could negatively impact the application's data
integrity by removing an entity from the database.

33 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 2828: Confirmation window.

While the delete operation is in progress, we display a loading window to inform the user that
the action is being processed. This helps in maintaining transparency and managing user
expectations during the operation.

Figure 2929: Loading component.

34 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

If the delete operation fails for any reason, we promptly display a message to inform the user
that the operation was not successful. This notification ensures that users are immediately
aware of any issues, allowing them to take necessary actions or contact support if needed.

Figure 3030: Error message information.

35 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2.4 Ticket management view

Figure 3131: Ticket management view.

Still on event management view, based on the feedback we got from the first review meeting,
we have decided that it would make more sense to change the ticket designing to this part
(previously was in create event window). So, when the user clicks on the button “Add ticket” or
press the button “manage” on the ticket component, this window will pop up. This way, the user
can now not only update/change the ticket details, but also customize the ticket colour.

36 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2.5 Add ticket view (on create event view)

Figure 3232: Add ticket view.

Since we changed the managing and designing of the ticket to the event management view, we
had to implement a new way of creating a new ticket when creating a new event. Therefore, we
decided to apply a simple user interface for this effect, maintaining a similar design to the pane
below (create event) as shown on the figure above.

Here the user can input the ticket information like type, price, and quantity, these are obligated
fields to fulfil, and if the input is invalid the user will get an alert with guidance on the invalid
information.

37 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.2.6 Special tickets view

Figure 3333: Special tickets view.

The design of the special tickets window is following the design and colour pallets of the
program (other windows) and has a similar approach like the managing ticket view (Figure 33).
Here the logged user has an overview of all the events that has assigned, and depending on
which event the user chooses, it will show on the list below the special tickets generated for that
event, with the information of type of ticket, quantity, and price.
The user can create, edit, and remove a ticket. We use the same validation and guidance of
inputs, the user can create a special ticket for an event or to be available for all the events
(choosing the option “Not Related to Events”), so for the selling part the event coordinator
could see not only the tickets related to the events that has assigned but could also see the
tickets not related to any event.

4.2.7 Administrator page main view window

The main view window of the Administrator page is the central hub for overseeing and
managing all administrative functions within the application. This interface is designed to
provide administrators with efficient access to various features, like user management,
event coordinators assignment.

38 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 3434: Administrator main page window.

The design of the Administrator page, as illustrated in Figure 34, mirrors that of the Event
Coordinator page, maintaining a consistent user interface across the application. An additional
feature specific to this page is the inclusion of shortcut buttons. These buttons allow users to
quickly sort events by their status, facilitating easier management and access to event
information.

To enable administrators to effectively manage the users of the application, we have developed
a separate, dedicated window. This specialized interface is equipped with all the necessary tools
required for comprehensive user management. Administrators can effortlessly add or remove
ensuring they have full control over user access and responsibilities within the application.

39 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 3535: Events coordinators management.

Figure 3636: Users management page.

To enhance user experience, we have maintained the same layout for the user management
window as is used on the events page. This design consistency helps users navigate the
40 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

application more intuitively and efficiently, as they become familiar with a unified interface
across different sections.

Administrators can add new users to the system via the user creation page. This interface is
equipped with all the necessary tools for comprehensive user setup. It allows administrators to
enter user details such as name, role, password, and user image, ensuring a seamless and
efficient process for integrating new users into the application.

Figure 3737: User creation page.

41 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

To edit user information, we provide a similar interface to the user creation page. The key
difference is that the input fields are pre-populated with the selected user's existing data. This
design choice streamlines the editing process, allowing administrators to quickly update user
details without needing to re-enter all information.

Figure 3838: User edit page.

To enhance user experience, we have integrated a search functionality into the application. The
search results are displayed in a popup window that overlays the main page content. When a
user selects a result from this popup, the corresponding page (events or users) automatically
updates to show detailed information related to the selected search result. This seamless
integration ensures that users can quickly and easily access the data they need without
navigating away from their current workflow.

The same search interface is utilized throughout the application, whether on the Event
Coordinator layout or the Administrator layout. This consistent interface supports search
functionality for all entities within the system that users might need to find. By maintaining a
uniform search experience across different user roles and entities, we streamline user interaction
and enhance efficiency across the platform.

42 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 3939: Search window.

4.3 Implementation
4.3.1 As an Event Coordinator, I want to sell tickets to customers

Selling part of the application facilitates many functions like fetching data of events and tickets
and saving new data. In the model class we have implemented several key components to
facilitate event and ticket management for the selling function. Firstly, the class maintains a
centralized data structure allEvents, an ObservableMap, to store all events, enabling efficient
access and manipulation. This map was populated using the returnAllEvents() method, which
retrieves events from the database. For ticket management, we made two separate
ObservableMap objects, eventTickets and specialTickets, to store regular and special tickets.
Methods such as getTicketsForEvent(int eventId) and getSpecialTicketsForEventOrNot(int
eventId) are responsible for retrieving tickets associated with specific events, special tickets for
all events and only related and populating the corresponding maps.

Upon initialization, the controller loads the event names into a combo box (allEvents) to allow
users to select the event they want to buy tickets for. Event listeners are set up to dynamically
fetch ticket information based on the selected event id. If a valid event ID is obtained, the
method proceeds to fetch the tickets for that event using the model.getTicketsForEvent(eventId)
method and populate combo boxes (allEventTickets and specialTickets) with available ticket
options. The model.getTicketsForEvent(eventId) method returns an ObservableMap<Integer,
Ticket>, where each entry consists of a ticket ID (key) and its corresponding Ticket object
(value). This map structure enables efficient lookup and retrieval of ticket data based on their
unique IDs. The retrieved tickets are then stored in the ticketsMap. Subsequently, the ticket data
43 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

stored in the ticketsMap is converted into a List<Ticket> to facilitate presentation in the user
interface. In addition, we made a copy constructor in “Ticket” BE to ensure that when Ticket
objects are passed between methods or manipulated within the SellingViewController class,
they remain distinct instances with independent state. This is crucial for maintaining data
integrity, as it prevents unintended modifications to Ticket object. This ensures that any
subsequent modifications made to the selected Ticket object, such as changes in quantity or
price, only affect the copy stored in the list of selected tickets, leaving the original Ticket object
unchanged.

In the selling process, when users add tickets by selecting them from combo boxes and entering
quantities, the controller validates the input and updates the list view with the selected tickets. It
calculates the total price dynamically based on the selected tickets and quantities. Users can also
remove tickets from the list view if needed. When users confirm their selection by clicking
"Save," the sell() method ensures the input is valid via SellingValidator and then triggers a
background service (Service<Void> sellingService) to execute the ticket-selling logic
asynchronously. The initializeService() method sets up the selling service to run the
sellTickets() method in a background thread. Upon successful completion, the UI is updated
with a loading indicator.

Figure 4040: InsertSoldTickets() method.

This code segment is a crucial part of the ticket-selling system, which ensures data insertion
consistency. It was complex to implement due to multiple database operations within a single
transaction. If a customer is provided, their information is added to the database, and their
unique ID is retrieved.

44 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Next, the list of selected tickets is split into two categories: special tickets and regular event
tickets. This classification facilitates separate processing for each ticket type. Special tickets are
inserted into the database using the insertSoldSpecialTicket() method, and their quantities are
deducted from the available inventory through deductSpecialQuantity(). Similarly, normal event
tickets undergo insertion and quantity deduction using insertSoldTicket() and deductQuantity()
methods.

Once all database operations are completed successfully, the transaction is committed, ensuring
that either all changes are applied or none. In case of any exceptions during the transaction or
database operations, the transaction is rolled back to maintain data integrity. Finally, the
database connection is closed to release resources.

4.3.1.1 Printing tickets

To facilitate the printing of customized tickets, we developed the TicketComponentDescription

within a separate component that stores the design information in the database. When an event
coordinator opts to print a sold ticket, this description is regenerated and placed within a JavaFX
Scene to capture a snapshot, which is then used to produce the actual ticket image.

This regeneration process must be executed on the JavaFX thread, which can occasionally cause
the UI to become unresponsive. To minimize the load on the JavaFX thread and enhance user
experience, we implement separate tasks to pre-load necessary data, such as the QR code image,
before the snapshot operation. These tasks also manage data processing after the snapshot is
created, ensuring efficient handling and a smoother user interface performance.

Figure 4141: Ticket printing system.

The finalized ticket as shown in Figure 41 is saved in a designated directory, enabling the event
coordinator to access it via the operating system. From there, they can select the appropriate
printer, adjust the print sizes, and execute the printing. This approach offers flexibility and
control over the final printed output, ensuring that the tickets meet the specific requirements of
the event.

45 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 42: 42Actual ticket for printing.

4.3.2 As an Admin/Event Coordinator, I want to log in using a username and password

Figure 4343: signIn() method.

46 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Upon clicking, the signIn() method is triggered, which retrieves the entered username and
password from the input fields. Once the username and password are obtained, the controller
invokes the checkUser() method of the Model class, passing the username and password as
parameters. This method initiates the authentication process by delegating the task to the
LogInManager.

The LogInManager interacts with the LogInDAO, which handles database operations related to
user authentication. Using a prepared statement, the LogInDAO queries the database to verify
the entered username and password. If a matching user record is found, the DAO retrieves the
user's information and constructs a User object. Back in the LogInManager, the retrieved User
object is returned to the Model class, indicating a successful authentication. The Model then sets
this logged-in user object using the setLoggedUser() method, ensuring it is accessible across the
application.

Upon receiving the logged-in user object, the LogInController proceeds to close the login
window and open the appropriate main window based on the user's role. This action involves
invoking methods such as loadAdminPage() or loadCoordinatorPage(), which handle the
window navigation logic.

Throughout this process, error handling mechanisms are in place to manage exceptions and
provide informative error messages to the user in case of authentication failures or other issues.
The use of enums helps differentiate between different user roles, enabling role-based access
control.

4.3.3 As an Event Coordinator, I want to manage events.

To ensure data integrity when editing event details, the system performs rigorous input
validations. For instance, if a user attempts to set the starting date to a past date, the system will
flag the start date as invalid. This becomes more complex for events that have already taken
place, whose start dates are naturally in the past.

To navigate this, the system compares the original event data against the newly edited data. If
no changes are detected, the edit operation is deemed unnecessary, and the editing window is
closed without making any modifications.

However, if there are changes, the system performs a detailed comparison of the date fields.
Each date is validated individually to ensure its correctness. If any date or time entry is found to
be invalid—such as an end date that precedes the start date, or a start time that is not feasible—
the system specifically identifies and displays an error message for that input.

This methodical approach ensures that all event details are accurate and that any modifications
made do not compromise the validity of the event information.

To enforce rigorous validation within the business logic layer, we developed a class named
EventInvalidResponse. This class is responsible for encapsulating all validation data derived
from input verification. Should the inputs prove invalid, an error object is instantiated within the
Model layer. This allows the View layer to accurately display the corresponding errors.

47 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 4444: Event date validation.

4.3.4 As a User, I want to delete events (Admin and Event Coordinator).

We designed the delete component to be highly versatile and not confined to specific part of our
application, such as "delete a user" or "delete an event". Instead, it is designed for reuse
throughout the application. Its functionality adapts based on the context in which it is used,
ensuring it provides the appropriate deletion capabilities required by the current user.

Figure 4545: Delete component controller.

We achieved this functionality by employing Interfaces and Enums. Specifically, the

component relies on the CommonModel interface, which provides the necessary deletion
functionality. This interface uses the entityId to determine the entity to be deleted.
Furthermore, the DeleteOperation enum is used to specify the type of deletion operation to be
performed, such as "delete event", "delete user", or "unassign user".

48 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

Figure 4646: CommonModel interface.

Upon creation of the delete component, the client is required to supply the specific
implementation of the CommonModel, the identifier of the entity to be managed, and the type
of delete operation to be executed.

Figure 4747: Actual usage of delete component.

4.3.5 As a User, I want to search for an event.

During our analysis of the search functionality, we identified that it needed to accommodate
both events and users uniformly. To achieve this, we designed the search component to be
reusable through the utilization of Java Generics.

Figure 4848: Search component.

To further decouple this component from our models, we implemented an interface called
DataHandler<T>.

This interface is tasked with executing the search operations and delivering the necessary
response data resulting from these operations. By leveraging Generics, we facilitated the
specification of the entity type—whether "Event" or "User"—at the component's instantiation,
thus enabling a single component to handle both entity types efficiently.

Figure 4949: DataHandler Interface.

49 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

To streamline the management of profile pictures, we have opted for a cloud-based system,
specifically using the Cloudinary image API. This choice eliminates the complexities associated
with local file management. We store the images on Cloudinary and maintain the
corresponding URLs in our local database. This setup allows for easy retrieval and display of
the profile pictures in our application when needed.

Figure 50: 50Cloudinary image API.

4.3.6 As an Event Coordinator, I want to add/create “special” tickets.

Figure 5151: addTicket() method.

50 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

In our special tickets window (Fig. 51), the addTicket() method plays a crucial role in allowing
users to input information about new tickets or update existing ones.
Firstly, when a user attempts to add a ticket, the system checks if the entered ticket details are
valid. This step ensures that the type, price, and quantity of the ticket are in the correct format, if
any input is invalid, an alert message will appear with some guidance for the user.
Next, the method extracts the ticket details, this includes the ticket type, quantity, price, and
colour. Depending on whether the user is adding a new ticket or updating an existing one, the
method takes appropriate action. A Ticket object is created, this will be used to create a new
ticket. If it's an update, the existing ticket details are modified accordingly (to selectedTicket
variable). If the user has associated the ticket with a specific event, the method ensures that this
association is executed in our system. All these operations are saved on the database, if
successful.
Furthermore, if the ticket is associated with an event that is currently selected in the system, the
method updates the user interface accordingly. The ticket is displayed in the list of tickets
related to that event, providing users with clear and dynamic visibility.
Finally, the method clears the input fields to prepare for the next operation. This ensures a
smooth user experience.

4.4 Design Patterns

Commander

To execute the actual, delete operation, the delete component issues commands to the
CommonModel interface. The implementation of CommonModel then carries out the necessary
deletion tasks by invoking the business layer. This structured approach ensures that delete
operations are performed efficiently and adhere to the application's architectural protocols.

Facade

Due to the complexity of the ticket printing system, which involves both pre- and post-image
processing operations, we have employed the façade design pattern to streamline interaction.
This pattern conceals the underlying complexities by depending on a model injected through the
constructor. It exposes a single method, printTicket(), simplifying the user interface while
maintaining robust functionality behind the scenes.

Dependency Injection

Throughout our application, we have implemented the dependency injection pattern to manage
dependencies externally, ensuring that all necessary components are instantiated and provided at
the time of creation. We specifically utilized constructor dependency injection. This approach
not only streamlines component setup but also eliminates hidden dependencies, thereby
maintaining transparency and predictability for the client.

51 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.5 Sprint Review

We were able to implement all the functional requirements of the project, as well as some “nice
to have” features. Which was considered a success.

We had some minor bugs during the presentation, which didn't compromise our performance,
and one of the extra functionalities was still not developed but it appeared on the user interface.
Nevertheless, both Product Owner and Stakeholders recognized the amount of work we put into
the project and congratulated us for achieving such result. We also improved our project
management skills thanks to Scrumwise, we learned from our first sprint how to better organize
and plan our sprints and work going forward, hence the improvement in this so important field.

Our main critiques were related to the design of the application, the feedback was that the
design on the different windows didn’t match, it could give the idea to the user that different
windows were different applications. Which wasn't our goal.
It was suggested that we finished the remaining functionality and took into consideration the
design feedback, until the hand in date.

4.6 Sprint Retrospective

Figure 52: Burndown chart for Sprint 2

The work that was done during sprint 1 and 2 helped us vastly to achieve this good result that
can be seen in figure 52. Our team has started implementing functionalities that were most
crucial from the start, giving as more time to focus on what was important. This allowed us to
implement the requests for the final sprint and more. Although we had a few requests and other
aspects to improve during sprint 2, our good organisation skills allowed us to stay on track.
52 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

4.7 What went well?

During second sprint our team had a better understanding of task distribution and time
management. From figure 52 we can see that overall, our project management has improved
since last sprint. Although we can see slight fluctuations in the chart, we have followed our
initial plan well. This improvement happened due to our constant meetings and trust in each
other, as well as a better understanding of each other’s capabilities.

4.8 What to do better, to improve next time?

For the upcoming sprint, we plan to refine our approach to user stories by breaking them down
into smaller, more manageable segments. This decision comes in response to a previous user
story that extended to 30 hours, highlighting the need for more granular tasks. Additionally, we
aim to enhance the consistency of our user interface. To modernize our UI, we will transition
from text-based commands to more intuitive icons where feasible, streamlining user interactions
and improving aesthetic appeal.

5 Test Documentation
5.1 Junit tests for the AdminManagementLogic
We chose to evaluate this section of the application due to its critical role in managing the
search and sorting logic.

53 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

The search functionality was rigorously tested using both valid and invalid input parameters. A
similar methodology was applied to the sorting operations, where tests were conducted with
both appropriate and inappropriate data.

Essentially, we developed two separate tests: one containing events that correspond to the
search filter, and another devoid of events that match the search filter. The same approach was
adopted for the sorting functionality.

Figure 5352: Search functionality test.

6 Conclusion

In conclusion, the development of this event management system has been an undoubtedly
rewarding journey of growth, learning, and collaboration, providing us with valuable insights
and practical experience. By achieving the specified functional and technical requirements, we
have not only demonstrated our proficiency in programming, but also our collaborative and
project management skills have improved along the way, since we were a new team and finding

54 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

out how each other work, but having the right persons in the team, with the right motivation,
everything is possible.

One of the significant achievements of this project is the dynamic nature of the application, we
learned how to use components that can be instantiated on demand, as well as how to design
components that offer consistent functionality throughout the entire application to ensure
reusability. From user authentication and role-based access control to event creation and
management, ticket management and printing functionalities, we have addressed diverse
challenges while striving for usability and efficiency.

The tool ScrumWise enabled us to have an organized, planned, and structured project and
workflow. Through regular sprint reviews and continuous communication with product owner
and stakeholders, we iteratively refined our understanding of user needs and improved the
application's functionality and usability.

Moreover, the technical intricacies involved implementing features such as threading, input
validation, isolation levels, exception handling, and database transactions have enriched our
understanding of programming, software architecture and design. We made use of design
patterns to promote modularity, flexibility, and maintainability.

In essence, this project has not only prepared us for the final examination but has also equipped
us with the practical skills, theoretical understanding, and collaborative mindset essential for
success in not just in software development, but also for working in teams. We are grateful for
the opportunity to undertake this project and look forward to applying our newfound knowledge
and expertise on the exam!

7 References
Huether, D. (2021, November 4). Definition of done. LeadingAgile.
https://www.leadingagile.com/2017/02/definition-of-done/

55 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

8 Appendices

8.1 Group contract

Project Name: Event Tickets EASV Bar (EventHub)

Project Due Date: April 19th, 2024

Team Members:
Name Phone N. Email Personality
Nelson Veríssimo 50 18 38 33 [email protected] INFJ-A
Meile Kapisaite 52 82 89 09 [email protected] ENFJ-T
Andrei Ionut 20 77 71 82 [email protected] INFP-T

Team Agreement and Ground Rules:

Topic Agreement

o Every weekday after classes (4h).

o We have daily scrum to check the
stage of the project.
o In case a task is not completed in the
working hours or in other timeline
Working and Group Meeting hours defined, we must make an extra effort
(working more hours) to catch the
timeline goals.
o If needed, we will adjust the working
hours (more hours) to achieve the final
goal.

o This group will apply 3-strike rule. Once

a person collects 3 strikes, he/she will
be eliminated from group. Strikes will be
given in case of these situations
occurring:
 Absence.
 Disrespect.
Rules  Passive work.

o Attendance: Everyday attendance

during the week project is necessary
from all group members.
o Workload Distribution: Equal workload
distribution.
o Quality Standards: Aim for the best
results.

Relations o Team Building: We will foster positive

56 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

relationships within our group by getting

to know each other, understanding each
other’s personalities, individual
strengths, weaknesses, and promoting
open communication.

o Conflict Resolution: We will encourage

open and respectful discussions to
resolve disagreements.

Project Leader: Nelson

o Overall responsibility for the

project's success.
o Ensure that the project stays on
track and within scope.
o Facilitate communication among
team members.

Technology and Tools Expert: Andrei

o Manage and troubleshoot any

technical issues related to project
tools or software.
o Stay updated on relevant software
or tools that can enhance the
project.
Roles
Quality Assurance: Meile

o Review and proofread all project

materials to ensure accuracy and
consistency.
o Check for grammar, spelling, and
formatting errors.

Specific Roles:

o Programmers: All of us.

o Report writers: All of us.

o UML: To be decided.

o Reflection: We will encourage regular

Rim reflection on the project's progress,
including what is working well and what
needs improvement through daily
scrum.
o Continuous Improvement: We will use

57 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

feedback and reflections to make

improvements to our project processes.
Adjust the project plan, roles, and rules
if necessary.
o We are flexible but responsible for our
own actions.
o In case anyone has a situation that
doesn’t allow you to work on that day or
if you will get late to any meeting, it’s
your responsibility to let the other
colleagues know about this in advance
in a reasonable time.
Exceptions
o Some tasks might take more time than
initially predicted, but it’s our
responsibility to let other colleagues
know about any delays or issues that
might occur and therefore postpone the
deadline of the task.

o Brief feedback from each of us on the

Daily scrum status of our project / tasks.
o Discussing the steps / tasks we are
taking on the day.

Description of Project:
This project is a simple event management system for the EASV bar.

Research needed:
Previous research about each step/task we need to make.
Books and Stack Overflow.
Java documentation.
Jeppe’s videos (in case we need to review them).
Precious Dr. Google.

Motivation:
Our group is motivated to complete our project in timely manner and achieve 7 or
higher.
Understand and learn how to apply the code and learn new techniques of
programming.

Signatures:

58 / 60
SCO/SDE/ITO/DBOS 2nd semester
EventHub – compulsory assignment
Hand-in: Meile, Andrei, Nelson

59 / 60