Cheltenham Football Club: System Analysis and Design using UML

This project presents a comprehensive system design for the Cheltenham Football Club, addressing the need for a digital management system. The solution employs an object-oriented analysis and design approach, using Unified Modeling Language (UML) to visualize the proposed system. The project encompasses a detailed analysis of functional requirements, including recording member details, managing accounts, and handling payments. It includes use case diagrams to depict user interactions, class diagrams to illustrate system structure, sequence diagrams for process flows, collaboration diagrams to show object interactions, and flowchart/activity diagrams to represent workflows. The diagrams are accompanied by detailed descriptions and justifications, providing a clear understanding of the system's design and functionality. The project covers key aspects such as member registration, fee management, player suspension, and match details recording, offering a complete solution for the club's information management needs. The appendix provides additional context and definitions of key UML concepts. This project is an example of applying software engineering principles to real-world scenarios.

Use case diagram
1.1 Functional requirements
The main functional requirements of the system are:
 The system should be able to record the details of the members of the club.
 The system should be able to record the details which includes the name, contact
details, role, date of joining the club.
 The system should provide the club members with the option to view their profile
on the system and also add, modify their details on the portal.
 The system should also be able to maintain a record keeping option for the
accounts of the club. The system would be able to fine the players in case they are
not paying the fees on time. The system should be able to dismiss the players
would be dismissed from the club if they do not pay the fees for a long period of
time.
 In addition to this, the system should be able to store the details of the game. In
case the game is cancelled or postponed the system would store the details as null
in the tables created in the system.
 The system should be able to record the training session of the players who are
members for the club.
 The members should be able to view and update their profile.
 The system should be able to provide the user with the option of searching for the
possible options in the system. The system should also be able to provide the
reports for the requested by the users in the system.
1.2 use case diagram
1

2

2) use case diagram documentation
Primary use case 1
Use Case
Title: Record Details
Actors: Players, Admin
Description: The admin would be storing the details of the players in the system.
Each and every detail of the player would be stored in to the
information system implemented for the club.
Precondition The pre-condition is that the player should be eligible for registration
into the system.
Flow 1.Record details
2.Add Details
3.Modify Details
Alternative
Flow
1. Log In
2. Add Details
3. Record Details
4. Delete Details
Primary use case 2
Use Case Title: Update Account
Actors: Player
Description: The Player or the member who is attached to the system
would be able to update their details on the portal
Precondition The player would be able to view their profile on the system.
Flow 1. Record Details
2. View Account
3. Update Account
Primary use case 3
Use Case Title: Record Match Details
Actors: System
3

Description: The system would be able to store the details of the matches
that take place.
Precondition The admin should be logged in to the system.
Flow 1. Log in
2. Record Match Details
Primary use case 4
Use Case Title: Suspend Players
Actors: Players, System
Description: The system would be checking the fess payments made by
the players. If the player does not make the payment, then the
system would be suspending the player.
Precondition Check Payment
Flow 1. Check Payment
2. Suspend Player
Primary use case 5
Use Case Title: Modify details
Actors: Admin, Players
Description: The admin would be modifying the details stored in the
system for the players.
Precondition Record Details
Flow 1. Log In
2. Add Details
3. Record Details
4. Modify Details
10 use cases - brief description
Use case 1: Log in: The Admin would be logging into the system
Use case 2: Add Details: The Admin would be adding the details of the players in the
system.
Use case 3: Record Details: The details of the players would be recorded in to the system.
Use case 4: Modify Details: the admin would be modifying the details of the players into
the system.
Use case 5: Delete Details: The records which are no longer required in to the system
4

would be deleted by the admin.
Use case 6: Pay Fees: The members and the players would be paying the fees to the club
via the system and the system would be recording the details of the payment in the
system.
Use case 7: Check Payment: The system would be checking the payments made by the
players for the club.
Use case 8: Suspend Players: The players who would be not be paying the fees on time
would be suspended by the system.
Use case 9: View Account: The players would be able to view the accounts created for
themselves by the admin.
Use case 10: Update Account: The players would be able to update their accounts in case
there is a need for changing the details of their accounts.
5

3) Class diagram including conceptual classes and associations, generalization, aggregation
and/or composition if applicable with a brief description
Class Diagram
Provide brief description of all key classes and main attributes:
Class name Description
Account The accounts class would store the details of the members of the club
who are associated with the system. The name of the account and the
account id are displayed in the system by the members of the system.
The account also includes the status of the system.
Coaches The class represents the coaches in the club whose details are included
in the system. The coach id, name of the coach, address of coaches is
stored in the system.
Members The members of the system include all the classes of the system, such
6

as the coaches, staffs and the players. The details of the members such
as the member id, member name, member address and the contact of
the member is provided are stored in the system.
Payments Payments class stores the details of the fees paid by the members to
continue their membership in the system.
Matches The system would be storing the details of the matches in the system
such as the match id, the information about the teams participating in
the match and the results of the matches are also provided in the
system.
Training
Sessions
The training class involves the data of the training sessions to be
included in the system. The status of the players attending the training
sessions and also the players who are not attending the training
sessions would be stored by the class and reported to the coach
Administrator The class stores the details of the administrator in the system. The id of
the administrator and the name of the administrator is stored in the
system. The administrator is a staffs and hence the administrator is
derived from the class staffs.
Players The players class is inherited from the member’s class and is basically
used for storing the details of the players in the system. The player id,
player name and the address and contacts of the players are included
in this class.
Staffs The staffs class is inherited from the member’s class and is basically
used for storing the details of the players in the system. The staff id,
staff name , staff address and the staff contacts are included in this
class.
4) Interaction diagram
Sequence Diagram
7

8

Sequence Diagram - description and justifications
The sequence diagram is provided for the description of the flow of activities in the
Information system developed for the Cheltenham Club. The main actor objects considered
for the system are the members and the admin. The main object of the system is the
information system of the organization. The flow of the messages has been displayed in the
system. The administrator would log in to the system and record the details of the members
provided to them. The administrator would add the details, modify them if required and
also delete the details recorded in the system. After the details of the members have been
recorded in the system the members would be able to view their details and also update
their account if required. In addition to this the system would also record the fees payment
done by the members and the players in the system. The recording of all the matches would
be done in the system by the administrator. The system would also be recording the all the
details of the training sessions and the details of the players that are attending the training
session. The system would be notifying the coach if the players do not attend the training
sessions. In addition to this, the system would be recording the payment details and would
be suspending the players if they do not provide the fees on time.
Collaboration diagram
9

Collaboration Diagram: description and justifications
The collaboration diagram has been created by considering the member as a single class to the
system. In addition to this, the main fuctions identified for the system are recording, accounts and
payments and suspension. The member would enter the details to the system. The recoridng fuction
would then cosider three methods within itself. It would either Create records, modify records and
delete records. The account option allows the members to view their account and also the update
account method has been included in the fuction which would allow the members to update the
account in case there are nessecary changes to be made to the system. The payment fucntion is also
maintained with the system where the payment of a perticular member is checked and the member
is suspended in case the payment is done in a timely manner. The system also checks the payment
clause on its own. The the if function is already defined in the system. The suspend function is called
if the condition is met. The EnterDetail() option is avaikled by the member so that the adin can
record their details in the database of the system.
Flowchart/Activity Diagram
10

11

Flowchart Diagram Description and Justifications
The flowchart has been used for the description of the flow of events that take place within the
organization for the set up of the account of the Member and the payement of fees by the players.
The process starts with the admin loging in the system. After the admin has logged into the system
he fecthes the details of the players in the system and adds the details in the system. In case there is
some alterations or modifictaions to be made in the records the admin is provided with the option
to either update the details of the players or to delete them completely. Once the account has been
developed the member would be able to view his account and also make chages and update his
account. In addition to this, the member then makes the payment of the fees for the system. The
system would be recording the details of the payments made by the members. The admin would be
storing the details in the database of the infromation system created for the club. In addditon to
this, the adim would also be able to view the details of the payment from the database and the
process ends.
Appendix
12