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

Use Case:
Use cases specify the expected behaviour (what), and not the exact method of making it happen
(how).
Use cases once specified can be denoted both textual and visual representation (such as UML).
A key concept of use case modeling is that it helps us design a system from end user's perspective.
It is an effective technique for communicating system behavior in the user's terms by specifying all
externally visible system behavior.
Actor is nothing but who interacts with the system and at times even a system can be an actor.
Use Case Description:
The use case description is narration of the process that is a step by step process that allows the
descriptio of the pictorial use case in a step by step process. The interation and the daailogs of the
actors in the system are also described efficiently by the use case descriptions. The steps are written
after business transactions are completed. The trascations are genrally initaited by the actors and
the details of the transactions are provide by the primary actor who is acting for the use case.
Class Diagram:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static
structure diagramthat describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among objects.
Purpose of Class Diagrams
 Shows static structure of classifiers in a system
 Diagram provides basic notation for other structure diagrams prescribed by UML
 Helpful for developers and other team members too
 Business Analysts can use class diagrams to model systems from business perspective
Sequence Diagram:
In software engineering a sequence diagram that shows, for a particular scenario of a use case, the
events that external actors generate, their order, and possible inter-system events.
A sequence diagram is an interaction diagram that shows how objects send messages with one
another and in what order.
Sequence Diagram is a kind of behavioral diagrams visualize, specify, construct, document the
dynamic aspects of a system.
Difference between activity diagram and sequence daigram:
13

An Activity Diagram shows a workflow - a starting point, actions, decisions, splits and joins to show
concurrent activities, and ending points. It's essentially a flowchart for a process or workflow, usually
written using domain specific terms. It doesn't show classes, objects, or calls to methods/functions.
A Sequence Diagram shows interactions between actors and objects and between two objects.
Usually, this is at a method/function call level, perhaps even including parameters and return types.
The lifelines also show the creation and deletion of instances of objects, if they occur during the
sequence shown.
Typically the Activity Diagrams is used for showing a workflow at a level that is understandable by
users who don't necessarily care about the implementation detail, but use Sequence Diagrams for
capturing implementation details useful for helping people to write or understand code or to help in
testing the software.
Collaboration Diagram:
Communication diagram, also called collaboration diagram in UML 1.x, is a kind of UML diagram that
is designed for illustrating the dynamic view of the system. It emphasizes the structural organization
of the objects' send and receive messages. UML communication diagrams, like the sequence
diagrams - a kind of interaction diagram, shows how objects interact. A communication diagram is
an extension of object diagram that shows the objects along with the messages that travel from one
to another. In addition to the associations among objects, communication diagram shows the
messages the objects send each other.
Purpose of Communication Diagram
 Model message passing between objects or roles that deliver the functionalities of use cases
and operations
 Model mechanisms within the architectural design of the system
 Capture interactions that show the passed messages between objects and roles within the
collaboration scenario
 Model alternative scenarios within use cases or operations that involve the collaboration of
different objects and interactions
 Support the identification of objects (hence classes), and their attributes (parameters of
message) and operations (messages) that participate in use cases
Diffrence between collaboration diagram and sequence diagram:
Collaboration diagram: Emphasizes on the “structural organization” of the objects that send and
receive messages. It is better for visualizing all the effect on a given object.
Sequence diagram: Unlike Collaboration, sequence diagram emphasizes on “time sequence or
message ordering”. It is better for visualizing the overall flow.
14

Acitivity Disgram/Flowchart
Flowchart is a type of diagram that represents a workflow or process, showing the steps as boxes of
various kinds, and their order by connecting them with arrows.
Flowcharts are used to visually illustrate processes from beginning to end. The many flowchart
symbols create visual clarity, thus allowing the viewers to follow through the stages of a process
easier and without experiencing complications. Generally flowcharts are used to display a process in
all of its stages. To further ease understanding, flowcharts use a number of shapes (also called
symbols) which help you understand each step of the process even without reading the description.
Those shapes serve various functions, such as indicating when it's time to take a decision, when
information should be filed or added to a database; when a process is terminated, etc.
There are different types of flowcharts:
 Data Flowchart - the type of flowchart showing the processing of data within a system or
organization.
 Workflow Flowchart - the structure of a business or a process within an organization,
allowing the viewer (user) to follow through each stage of document processing.
 Process Flowchart - the most general type of flowchart, used for various processes such as
administrative, service, manufacturing, or basically anything which has a beginning and an
end.
 Cross-Functional Flowchart - another process flowchart which is split in several stages (cross-
functions), thus allowing the visual representation to be separated via departments or
another more general criteria.
References
15

Achouri, A. and Ayed, L.J.B., 2016. A formal semantic for uml 2.0 activity diagram based on
institution theory. arXiv preprint arXiv:1606.02311.
Adler, O., Razinkov, N. and Yorav, K., International Business Machines Corp, 2016.
Verification of UML state machines. U.S. Patent 9,454,382.
Afanasyev, A.N., Voit, N.N., Voevodin, E.Y. and Gainullin, R.F., 2015, October. Control of
UML diagrams in designing automated systems software. In Application of Information and
Communication Technologies (AICT), 2015 9th International Conference on (pp. 285-288).
IEEE.
Allaki, D., Dahchour, M. and En-Nouaary, A., 2016, April. A Constraint-based Approach for
Checking Vertical Inconsistencies between Class and Sequence UML Diagrams. In ICEIS
(1) (pp. 441-447).
Barayan, O. and Ali, N.M., 2018. ID NO. UPM009 TOPIC: Designing UML Diagram using
Tablet/Smartphone on Android Platform. UNIVERSITY CARNIVAL on e-LEARNING
(IUCEL) 2018, p.413.
Bashir, R.S., Lee, S.P., Khan, S.U.R., Chang, V. and Farid, S., 2016. UML models
consistency management: Guidelines for software quality manager. International Journal of
Information Management, 36(6), pp.883-899.
Fernandes, F. and Song, M., 2014. UML-Checker: An Approach for Verifying UML
Behavioral Diagrams. JSW, 9(5), pp.1229-1236.
Fernández-Sáez, A.M., Genero, M., Chaudron, M.R., Caivano, D. and Ramos, I., 2015. Are
Forward Designed or Reverse-Engineered UML diagrams more helpful for code
maintenance?: A family of experiments. Information and Software Technology, 57, pp.644-
663.
Germann, M., Kaufmann, J., Steudler, D., Lemmen, C., Van Oosterom, P. and De Zeeuw, K.,
2017. The LADM based on INTERLIS. In Cadastre: Geo-Information Innovations in Land
Administration (pp. 113-119). Springer, Cham.
Gogolla, M., Hilken, F., Niemann, P. and Wille, R., 2017, July. Formulating model
verification tasks prover-independently as UML diagrams. In European Conference on
Modelling Foundations and Applications (pp. 232-247). Springer, Cham.
Gregorovič, L., Polasek, I. and Sobota, B., 2015. Software model creation with
multidimensional UML. In Information and Communication Technology (pp. 343-352).
Springer, Cham.
Hu, J., Huang, L., Cao, B. and Chang, X., 2014. Extended DEVSML as a Model
Transformation Intermediary to Make UML Diagrams Executable. In SEKE (pp. 314-317).
Khurana, N. and Chillar, R.S., 2015. Test case generation and optimization using UML
models and genetic algorithm. Procedia Computer Science, 57, pp.996-1004.
Knapp, A., Mossakowski, T. and Roggenbach, M., 2015. Towards an Institutional
Framework for Heterogeneous Formal Development in UML. In Software, Services, and
Systems (pp. 215-230). Springer, Cham.
Kumar, B. and Singh, K., 2015. Testing uml designs using class, sequence and activity
diagrams. International Journal for Innovative Research in Science and Technology, 2(3),
pp.71-81.
Madanayake, R., Dias, G.K.A. and Kodikara, N.D., 2016. Use Stories vs UML Use Cases in
Modular Transformation. International Journal of Scientific Engineering and Applied
Science (IJSEAS)–Volume-3, Issue-1, ISSN, pp.2395-3470.
Mani, P. and Prasanna, M., 2017. Test case generation for embedded system software using
UML interaction diagram. J Eng Sci Technol, 12(4), pp.860-874.
Maylawati, D.S.A., Ramdhani, M.A. and Amin, A.S., 2018. Tracing the Linkage of Several
Unified Modelling Language Diagrams in Software Modelling Based on Best Practices.
16

International Journal of Engineering & Technology (UEA), 7(2.19), pp.776-780.
Mikkelsen, A., Honningsøy, S., Grønli, T.M. and Ghinea, G., 2017, November. Exploring
microsoft hololens for interactive visualization of uml diagrams. In Proceedings of the 9th
International Conference on Management of Digital EcoSystems (pp. 121-127). ACM.
Osman, H. and Chaudron, M.R., 2018. Correctness and Completeness of CASE Tools in
Reverse EngineeringSource Code into UML Model. GSTF Journal on Computing (JoC),
2(1).
Reggio, G., Leotta, M., Ricca, F. and Clerissi, D., 2014, January. What are the used UML
diagram constructs? A document and tool analysis study covering activity and use case
diagrams. In International Conference on Model-Driven Engineering and Software
Development (pp. 66-83). Springer, Cham.
Safdar, S.A., Iqbal, M.Z. and Khan, M.U., 2015, July. Empirical evaluation of UML
modeling tools–a controlled experiment. In European Conference on Modelling Foundations
and Applications (pp. 33-44). Springer, Cham.
Sharma, C., Sabharwal, S. and Sibal, R., 2014. Applying genetic algorithm for prioritization
of test case scenarios derived from UML diagrams. arXiv preprint arXiv:1410.4838.
Störrle, H., 2018. On the impact of size to the understanding of UML diagrams. Software &
Systems Modeling, 17(1), pp.115-134.
Torre, D., Labiche, Y., Genero, M. and Elaasar, M., 2018. A systematic identification of
consistency rules for UML diagrams. Journal of Systems and Software.
Touseef, M., Butt, N.A., Hussain, A. and Nadeem, A., 2015. Testing from UML Design
using Activity Diagram: A Comparison of Techniques. International Journal of Computer
Applications, 131(5), pp.41-47.
Wei, B. and Delugach, H.S., 2016, July. Transforming uml models to and from conceptual
graphs to identify missing requirements. In International Conference on Conceptual
Structures (pp. 72-79). Springer, Cham.
17

18