Object-Oriented Analysis And Design Approach For Cheltenham Football Club Information System

Primary use case 2

Primary use case 3

Primary use case 4

Primary use case 5

10 use cases – brief description

Use case 1:Login

This use case allows a coach, member or the manager to login into the system where by upon successful login, the system grants access or denies access to the user if the details entered are incorrect.

Use case 2:Add member

This use case allows a coach to  add a new member who does not exist in the system. The user fills a member registration form and submits it. The system validates that the details entered by the user are correct and saves the member details.

Use case 3:update member

This use case allows the coach or the member to update the member details. The coach can update member details for a certain member or the member can update the details themselves

Use case 4:record monthly contribution

This use case allows the coach to record monthly contributions for a certain player. A record is created for the monthly payment and associated with the user.

Use case 5:Search

This use case allows the coach or the manager to search for a member. The user can search using different search details for example using the member name or the member id. The system displays results for all records that match the search value submitted by the user

Use case 6:Generate report

This use case allows a manager to generate a report. The report can be generated for a certain period of time thus the user has to enter the dates between which the report should be generated

Use case 7:View notifications

This use case allows the user to view notifications by opening the notifications page. If a notification is unread and the user opens it, the status of the notification is changed to read.

Use case 8:Suspend player

This use case allows a manager to suspend a player. Only the manager has the privilege to perform this action thus no other can perform this action. When a player is suspended their status is changed.

Use case 9:Update match details

This use case allows the user to update match details for a game. After a successful update a notification is generated and sent to all users

Use case 10:Record registration fee

This use case allows the coach to record a registration fee for a member. A record is created and associated with the respective member.

3) Class diagram including conceptual classes and associations, generalization, aggregation and/or composition if applicable with a brief description

Provide brief description of all key classes and main attributes:

4) Interaction diagram

Sequence Diagram

The sequence diagram above shows the systematic flow and interaction of events for update match details use case. The use case has one actor and two objects i.e. the system and the database. The database is considered as an independent object from the system.

Collaboration Diagram

The diagram above shows the collaboration diagram for the update match details primary use case. It shows the control classes needed and the interaction between the classes for a successful execution of the use case.

Flowchart/Activity Diagram

The flow chart shown in the diagram above shows the logic flow for execution of the add member primary use case. The activity diagram has swim lanes to show the user side and the system side of the execution.

The proposed design as modelled using different stuctural and behavioral diagrams is based on the functional requirements of the proposed system. Meeting the functional requirements requires core non functional requirements to be followed for example ensuring that the system performs all tasks using the least amount of time possible.

References

Erikson, U., 2012. FUNCTIONAL REQUIREMENTS VS NON FUNCTIONAL REQUIREMENTS. reqtest. Available at: https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/ [Accessed August 25, 2017].