Use Use case modeling of gym meets assignment help.Case Modeling of Gym Meets

Use Case Modeling of Gym Meets 

Clubs and Club Members

At the beginning of the season, before any competition can take place, every club thatwishes to participate in the competition must register with ESG. Each club is knownby a unique name; however, for ease of reference, each is also given an ID, which is ashort sequence of characters. Each club must provide a contact person’s name and phonenumber, and the club’s address and fax number.

In registering with ESG, a club submits a list of their members who will participate inthe season’s competitions. During the season, additional members can be registered whilethe season’s competitions are in progress. The date a gymnast registers for competition isrecorded. Those who register when the club is registered have the first day of the seasonas the registered date. For each gymnast, ESG requires their name, date of birth, genderand phone contact. ESG then issues them with a unique ID.

Meets, Competitions and Events

The competitions are organized into a series of meets. Each meet is held in the course ofone day at one particular venue.

Each meet consists of competitions in all four divisions: Women’s Junior (WJ), Women’sSenior (WS), Men’s Junior (MJ), and Men’s Senior (MS). A division is identified by acode (e.g. WJ) and has a name (e.g. Women’s Junior). Junior divisions are for gymnastsup to 15 years of age by the first date of the season.

Each competition consists of a series of events run on different equipment. The events ina competition are drawn from a standard list of event types. Each type of event has acode and a descriptive name that is also unique. Certain event types are for women or formen only.

A sample of the result of a competition in a meet is shown below.

Each meet is identified by an ID (e.g. “M01”), and has a name (e.g. Vacation Classic). Acompetition within a meet is identified across the system by the combination of the meetID and the division code.

Teams in Competitions

When a club registers for a competition in a meet, the club submits an appropriate listof its members as participants. These participants form the team representing the clubfor the competition. A team thus registered must participate in all the events of thatcompetition. Moreover, a team must have the same set of members competing for eachevent within a competition.

Scoring

Each event in a meet has a judging panel assigned to it. These people are qualified togive scores for this event. ESG (and the system) maintains a list of judges including theirpersonal details (name, phone number) and the types of events they are qualified to judge.

For ease of reference, each judge is given a unique ID.

Each judge rates the performance of a gymnast on an event. The highest and lowest scoreswill be thrown out, and the rest averaged to be the gymnast’s score for the event. Thisaverage will be entered into the system. The event score for a team is the sum of all itsmembers’ scores for the event. The competition score for a team (which is also referredto as the team’s meet score) is the sum of the team’s event scores.

(The season’s ranking of a club for a particular division depends not only on their totalscores for the meets but also on other factors, for example, the team sizes and the bestperformances of the members for various events. The rules and procedure for ranking,however, do not concern us here).

Further Details and Requirements

None of the IDs are automatically generated by the system.

The details about divisions and event types are taken from existing standards. However,the system must provide facilities for the user to enter these details into the system.

To avoid some unnecessary complications, it has been decided that the system wouldallow us to register a club at the start of the season without having to enter its membersat the same time. 

Tasks

For Part 1 of the assignment, you are required to do the tasks described below.

Clearly state any assumption you make. Your assumptions must not be inconsistent withwhat are given the description above.

Task 1 – Use Case Modeling

Identify the use cases up to the point at which the score for a gymnast for an event canbe recorded.

Restrict your use cases to those that do add some new information into the informationbase.

That is, you are not required to consider use cases which change details about existingobjects or relationships, or delete these objects or relationships. Nor do you need toconsider any query use cases.

Present the use cases in a list and number them.

Describe each of the use cases in the list, using the Main Flow/Extensions format.

Make sure you clearly number the use cases.

Notes:

– You are not required to draw use case diagrams.

– You are required to identify and specify all use cases that fit the requirements givenabove. As for marking, about 5 of those use cases will be marked.

– Your use case descriptions should capture the functional requirements precisely andconcisely. Use case descriptions with superfluous details may result in marks beingdeducted.

Task 2 – Domain Modeling

Construct a domain class model, which may consist of one or more class diagrams.

You should use enumerated types whenever appropriate (rather just using characters orstrings).

You are required to use Enterprise Architect to draw the class diagrams.

Diagrams that are drawn by hand or with other software will have up to 50% of itsmarks deducted.

You should include your class diagrams in your pdf document, not in separate files.

An issue to ponder: There are some concepts of the application domain that can be represented in two ways: (a) as associations of arity (degree) 2, 3 or more, or (b) explicitly as classes. Which representations would you prefer? More specifically, which one would produce a model that is easier to understand? 

Solution 

Task 1

Use case to register a club in a season:

Use case name: register for a season

Trigger/Goal: A club wants to participate in some competitions of a given season and has to register on ESG system

Actors: team representative

Main Flow:

The team representative provides his name and phone number, and the club’s name, ID, its address and fax number and the season its club want to participate in.

The system checks if the competition has not started yet.

The system checks if all required information are provided and that the club is not already in the competition before validating its participation.

Extensions:

1a- The team representative provides a list of gymnasts:

(see the following use case, please bear in mind that the “current date” in the 4th step is the “season’s start” date for this case)

2a- If the season has already started:

System notifies the team representative and ends the use case

3a- If there is a missing information:

System notifies the team representative, and asks him to provide the missing information

3b- If the club is already registered for the season:

System informs the team representative and ends the use case

Use case to add a gymnast for a season:

Use case name: add a new gymnast for a given season competitions

Trigger/Goal: After the season started, a club wants to add another gymnast to its team

Actors: team representative

Main Flow:

The team representative selects the season, to which he is willing to add a new gymnast, provides his/her information

The system checks if the season has not ended yet.

The system checks if all required information are provided and that the gymnast is not already in the chosen season (maybe in the same club or in another one).

The system validate the gymnast participation, assign the current date to his/her registration date and generates a unique ID for him/her.

Extensions:

2a- The season has already ended:

The system notifies the team representative and ends the use case

3a- There is a missing information:

The system notifies the team representative and asks him to provide the missing one(s)

3b- The gymnast is already in the season:

The system notifies the team representative and ends the use case

Use case to create a competition:

Use case name: create a competition for a season

Trigger/Goal: An ESG administrator wants to add a competition for the current season

Actors: ESG administrator

Main Flow:

The administrator selects the current season

The system provides the available events and division

The administrator checks the wanted events and assign a start time to each of them with their possible divisions

The system save the competition details

CRUD for Event types:

Use case name: Create Read Update Delete event types

Trigger/Goal: An ESG administrator wants to manage event types

Actors: ESG administrator

Main Flow: we will detail the add event

The administrator selects the current season

The system provides the available events

The administrator chooses to add an event type and provides its code and descriptive name

The system checks that the code and the descriptive name are not being used by another event type before it validates the new event type

Extensions:

3a- The administrator can check (e.g: radio button) to specify that the event type he is providing is gender specific and then choose if it is for men or women.

4a- If the check does not pass, the system notifies the administrator and ends the use case

CRUD for Divisions

Use case name: Create Read Update Delete division

Trigger/Goal: An ESG administrator wants to manage divisions

Actors: ESG administrator

Main Flow: we will detail the add division

The administrator selects the current season

The system provides the available division

The administrator chooses to add a division and provides its code and name

The system checks that the code and the name are not being used by another division before it validates the new event type

Extensions:

3a- The administrator can specify that the division he is providing is gender specific and then choose if it is for men or women or specify a minimum age or maximum one

4a- If the check does not pass, the system notifies the administrator and ends the use case 

CRUD for judges list

Use case name: Create Read Update Delete judge entry

Trigger/Goal: An ESG administrator wants to manage judges

Actors: ESG administrator

Main Flow: we will detail the add judge

The administrator selects the current season

The system provides a list of available judges

The administrator chooses to add a judge and provides his/her information: ID, name, phone number, and the event type he/she can judge

The system checks that the ID is unique, the chosen event type are available (references) before validating the new judge

Extensions:

4a- If the check does not pass, the system notifies the administrator and ends the use case 

use case to register for a competition:

Use case name: register for a competition

Trigger/Goal: A club, already registered in the season, wants to participate in a specific competition of that given season

Actors: team representative

Main Flow:

The team representative selects to participate in a competition of the current season

The system provides the club gymnasts, provided in use case a or/and b, and the list of events for that specific competition with its different divisions

The team representative assign the wanted gymnasts for the team, each to a specific event/division

For each selected gymnast the system checks if he/she satisfies the requirements of the assigned event/division and save the participation

Extensions:

4a- It he/she does not satisfies requirements:

The system notifies the team representative and asks him to correct the assignment or to cancel the gymnast’s participation.

use case to calculate the scores:

Use case name: calculate scores

Trigger/Goal: An ESG administrator submits the score of a given gymnast for a specific event

Actors: ESG administrator

Main Flow:

The ESG administrator selects an event and a gymnast and submits his/her average score

The system selects the corresponding club and adds the provided score to its event score

The system selects the corresponding club and adds the provided score to its meet score (the competition score).

Task 2

Note:max_age from Division class, gender from Event class, if not specified it means, respectively, there is no maximum age restriction and no gender restriction

An issue to ponder: using explicit classes would be very helpful to easily understand the relation between classes for the simple reason that having an explicit class with its attributes will contribute to rapidly get the detailed relationship between the different classes.