Gynmnast Competition

Problem Statement

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.

Clubs and Club Members

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.

Meets, Competitions and Events

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.

Teams in Competitions

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.

Scoring

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).

Further Details and Requirements

• None of the IDs are automatically generated by the system.
• Though the divisions and event types are taken from existing standards, the system must provide facilities for the user to enter their details into the system. Moreover, it is the responsibility of the user to ensure that these details are entered correctly.
• To avoid some undesirable complications, it is decided that the system would allow us to register a club at the start of the season without having to enter its members at the same time.

Your Tasks

Task 1

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.

Task 2

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.

Part 2

For Part 2 of the assignment, you are to continue with the Gymnastics System described in Part

1. Whereas Part 1 is concerned with the analysis phase, Part 2 will be concerned with design, prototyping and testing.

As the starting point for Part 2, assume that the following design class diagrams have been adopted. Figure 1 shows the classes representing the domain objects, and Figure 2 shows the system class.

Figure 1 – Design Class Diagram Showing Classes for Domain Objects and Their Attributes See image.

Figure 2 – The System Class – With Attributes See image.

Task 1 – Atomic Use Case Specifications

Formally specify the following atomic use cases:

• Add a club
• Add a gymnast
• Add a division
• Add an event type
• Add a judge
• Add a meet (and the competitions for the meet)
• Add an event for a competition
• Assign a judge to an event (in a competition)
• Register a team
• Register a member for a team
• Enter the score for a gymnast (member of a team) for an event
• Generate a report on the performance of a gymnast in a meet (optional)

Note 1:

• In your answer, number the use cases (from 1 to 12) as shown above.
• Your specifications must be based on the design class diagrams given.
• If necessary, refer to the problem statement given in Part 1 of the assignment.

Note 2:

You are required to specify 11 atomic use cases (not counting use case 12). But about five atomic use cases will be selected for marking.

Task 2 – Prototyping

Prototype all the atomic use cases listed for Task 1 in Java. (Use case 12 is of course optional.)

Your implementation of the prototype must be done in a systematic manner. In particular, for each use case, the preconditions should be checked first, and the postconditions should then be realized.

Note 1: You should use the Helper class given in the labs to search a collection on the basis of a simple or composite key.

Note 2: The Appendix provides a sample “quick-and-dirty” test program. You can use the tests given in this program as a means to quickly test your in-progress implementation. Your implementation must be such that we can run this test program without any change. This means in particular, the method signatures of the system class have to be compatible.

Note 3: Similarly to the previous task, about five atomic use cases will be selected for marking.

Task 3 – Testing the Prototype

For each atomic use case, design the test cases and include them in a Java program, called GymnasticsScoringSystemTester, to carry out the testing.

Organizing Test Cases

• Arrange the testing in a number of test methods
• Each method is to test one atomic use case only. An atomic use case must have at least two test methods: one to test the successful cases; and one (at least) to test the invalid request.
• The test methods must be named as follows: use case number, followed by test number for that use case. For example: UC01Test01()
• Each test method must be commented to indicate (a) Whether it is for successful cases or unsuccessfully cases; and (b) for unsuccessful cases, the reasons for them to be unsuccessful.

Note: The sample test program given in the Appendix is only for a quick test. Your test program required for this task must be organized into a number of methods as described above.

Note: You should perform the testing for each atomic use case as soon as you finish implement it.

Appendix – Quick Test Program

import java.util.*;
public class GymnasticsScoringSystemQuickTester
{
public static void main(String [] args) throws Exception
{
int test = 1;
// new sytem
System.out.println("...Test " + (test++) + ": Create gymnastic system");
GymnasticsScoringSystem gss = new GymnasticsScoringSystem();
System.out.println( gss );
// 1. add clubs
System.out.println("...Test " + (test++) + ": Add clubs");
gss.addClub("CLUB-10", "Acrobats", "1010");
System.out.println( gss );
// 2. add gymnasts
System.out.println("...Test " + (test++) + ": Add gymnasts");
gss.addGymnast("GYMNAST-10", "Smith", 'M', 20, "CLUB-10");
System.out.println( gss );
// 3. add divisions
System.out.println("...Test " + (test++) + ": Add divisions");
gss.addDivision("MJ", "Mens Juniors", 'M', 10, 15);
gss.addDivision("MS", "Mens Seniors", 'M', 16, 80);
gss.addDivision("WJ", "Womens Juniors", 'F', 10, 15);
gss.addDivision("WS", "Womens seniors", 'F', 16, 80);
System.out.println( gss );
// 4. add 3 event types
System.out.println("...Test " + (test++) + ": Add event types");
gss.addEventType("EVENT-TYPE-10", "floor", true, true);
gss.addEventType("EVENT-TYPE-20", "bar", true, false);
gss.addEventType("EVENT-TYPE-30", "beam", false, true);
System.out.println( gss );
// 5. add judges
System.out.println("...Test " + (test++) + ": Add judges");
List eventTypeCodes = new ArrayList();
eventTypeCodes.add("EVENT-TYPE-10");
eventTypeCodes.add("EVENT-TYPE-20");
gss.addJudge("JUDGE-10", "Adams", "1111", eventTypeCodes);
System.out.println( gss );
// 6. add meets
System.out.println("...Test " + (test++) + ": Add meets");
gss.addMeet("MEET-10", "Town Hall 10", "Town Hall", 10);
System.out.println( gss );
// 7. add events
System.out.println("...Test " + (test++) + ": Add events");
gss.addEvent("MEET-10", "MS", "EVENT-TYPE-10");
System.out.println( gss );
// 8. assign judge to event
System.out.println("...Test " + (test++) + ": Add events");
gss.assignJudge("JUDGE-10", "MEET-10", "MS", "EVENT-TYPE-10");
// 9. add teams
System.out.println("...Test " + (test++) + ": Add teams");
gss.addteam("CLUB-10", "MEET-10", "MS");
System.out.println( gss );
// 10. add team members
System.out.println("...Test " + (test++) + ": Add members");
gss.addTeamMember("GYMNAST-10", "MEET-10");
// CLUB-10 and MS (division) can be computed
System.out.println( gss );
// 11. add scores
System.out.println("...Test " + (test++) + ": Add scores");
gss.addScore("GYMNAST-10", "MEET-10", "EVENT-TYPE-10", 100);
// CLUB-10, MS (division code) can be deduced
System.out.println( gss );
}
}