Eastern Suburb Gymnastics (ESG) is a regional organization that is responsible for running competitions among the gymnastics clubs in eastern suburbs of Melbourne. The competitions are organized into seasons. ESG needs a system to help organize and maintain records of the competitions that take place in a single season. The system, in essence, needs to keep information on the gymnasts, their clubs, the organization of the competitions, and the competition results.
At the beginning of the season, before any competition can take place, every club that wishes to participate in the competition must register with ESG. Each club is known by a unique name; however, for ease of reference, each is also given an ID, which is a short sequence of characters. Each club must provide a contact person’s name and phone number, and the club’s address and fax number.
In registering with ESG, a club submits a list of their members who will participate in the season’s competitions. During the season, additional members can be registered while the season’s competitions are in progress. The date a gymnast registers for competition is recorded. Those who register when the club is registered have the first day of the season as the registered date. For each gymnast, ESG requires their name, date of birth, gender and phone contact. ESG then issues them with a unique ID.
The competitions are organized into a series of meets. Each meet is held in the course of one day at one particular venue.
Each meet consists of competitions in four divisions: Women’s Junior (WJ), Women’s Senior (WS), Men’s Junior (MJ), and Men’s Senior (MS). A division is identified by a code (e.g. WJ) and has a name (e.g. Women’s Junior). Junior divisions are for gymnasts up 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 in a competition are drawn from a standard list of event types. Each type of event has a code and a descriptive name that is also unique. Certain event types are for women or for men only.
A sample of the result of a competition in a meet is shown below.
Meet: M01 – Vacation Classic
Date: June 15, 2009
Division: Women's Senior
Event Scores
Club Uneven Balance Vault Floor
Bars Beam Exercises
Blackburn 42.2 41.0 37.4 39.6
Box Hill 40.6 42.5 43.8 38.5
Donvale 38.4 39.8 42.6 41.3
Eltham 41.5 40.2 44.8 43.6
Each meet is identified by an ID (e.g. “M01”), and has a name (e.g. Vacation Classic). A competition within a meet is identified across the system by the combination of the meet ID and the division code.
When a club registers for a particular meet, the club enters a subset of its members. This subset is known as a team. When a team is at a meet, it must participate in all the events of that competition. A team must have the same set of members competing for each event within a competition.
Each event in a meet has a judging panel assigned to it. These people are qualified to give scores for this event. ESG (and the system) maintains a list of judges including their personal 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 scores will be thrown out, and the rest averaged to be the gymnast's score for the event. This average will be entered into the system. The event score for a team is the sum of all its members' scores for the event. The competition score for a team (which is also its meet score) is the sum of the team’s event scores.
(The season’s ranking of the teams depends not only on their total scores for the meets but also on other factors, for example, the team sizes and the best performances of the members for various events. The rules and procedure for ranking, however, do not concern us here).
Identify and describe all the use cases that are needed to enter data into the system.
In addition, describe the use case to generate the report on the performance of a given gymnast in a meet.
You are not required to consider use cases which change details about existing objects or relationships, or delete these objects or relationships. Nor do you need to consider any query use cases except the one stated above.
Make a list of the use cases and number them. Then describe them using the Main Flow-Extension format.
Note: You are required to specify identify and specify all use cases that fit the requirements given above. As for marking, about 5 of such use cases will be marked.
Construct the domain class model (a.k.a. structural class model).
For each class, include both attribute names and attribute types. You don’t need to include methods. For relationships, among other things, include all relationship multiplicities. If necessary, you can use more than one class diagrams to avoid cluttering your model.
Clearly state any assumptions you make, or any decisions you take that, in your opinion, require clarification of your position.