Christabel Teo Hwee Teng - Project Portfolio

Adds an existing person displayed in the Person list on the user interface into an existing competition displayed in the Competition list on the user interface. User also needs to supply 3 weight attempts for each of the following events:

Format: addParticipation n/Athlete Name c/Competition Name s/S1/S2/S3 b/B1/B2/B3 d/D1/D2/D3

Example:

Note: S1 means the 1st attempted weight for the Squat and so on.

Note that the user can choose to provide a competition name or not.

Format: listParticipation c/COMPETITION_NAME

Example: To display all persons for all competitions:

To display all persons for NUS 2022 competition only:

Deletes the participation identified by the index number, used in Participation list (shown in the GUI).

Format: deleteParticipation INDEX

Examples:

Retrieves the next lifter according to weight lifted for that attempt, the weights he/she is going for that particular lift and attempt. If there are no more attempts to be made by any lifter, this command will trigger the end of the competition.

Format/Example: next

Updates whether the person (athlete) succeeds in his/her attempt, or fails it. The lift updated will be the one that was just called up.

Format: lift Y/N

Examples:

This is done using an instance of the Session class, which is exposed from the model manager. The session has a competition field to indicate the current competition that is ongoing during the session. If there is no competition set in the session, then there is no ongoing session. Using this simple but highly effective method, we are able to use very simple logic to achieve the necessary context-switching behaviour described in the above diagram.

One of the main purpose of the in-session function is to generate the next lifter and his attempt details accordingly. In the Session class, the list of ParticipationAttempt is maintained so that athletes can make their attempt in order of the type of lift, attempt number, and in increasing weight to be attempted. Upon calling the next command, the next lifter is called up, and the following lifter should be asked to prepare for his lift, after the next lifter.

Format: next

Given below is the example flow of what the model does when the NextLifterCommand is executed after being parsed through the LogicManager.

Step 1: A new NextLifterCommand is constructed when the user inputs next in the command box. When NextLifterCommand#execute() is called, the model will get the following lifter, and store the ParticipationAttempt retrieved from Session#getFollowingLifter() in a local variable, to be returned together with the CommandResult later on.

Step 2: The ModelManager will call Session#NextLifter() to generate the next lifter and attempt in the form of a ParticipationAttempt object. If the Session is not prepared, which means that the imported ParticipationAttempts are not sorted, prepare() will be called internally. When this method is called, the ParticipationAttempt list in the Session will be sorted according to the new ParticipationAttemptComparator. When this is done, the session is now prepared, and next or following lifters can be generated based on this sorted list. (This method is usually called once just after starting the session.)

Step 3: The Session#NextLifter() method will then return the first ParticipationAttempt in the list. This is equivalent to the next lifter to make his attempt, since he is the top most in the sorted list.

Step 4: A new CommandResult will be returned. Details of the next and following ParticipationAttempt will be included and displayed in the Dialogue Box to the user.

This feature ends the session, and shifts the user back to the out-session state. All data stored in the session will be reset to default.

Format: endSession

When we first implemented the session feature, the session can only be ended when a competition has ended, which means there are no more attempts to be made. However, we have now made it such that the user can switch between sessions as and when, even in the middle of the competition. This gives users more flexibility to switch between session states, without worrying about the state of the competition.

The start session feature is a command to start a new competition session, when a user is not in competition state. As mentioned in Section 4.2. above, Session allows the user to start any competition session as and when, even when a competition has not ended (there are still attempts left to be made). To start a session, the user can enter the command with the specified competition.

Format: startSession c/COMPETITION_NAME

Given below is the flow of execution in the model after a StartSessionCommand#execute() is called.

Step 1: Model#startSession(comp, partList) is called, where comp is the Competition object to start the session with, and partList is the list of Participation who will be participating in this competition session. The method then calls Session#start(comp, partList).

Step 2: An internal call in the start() method, loadAttempts(p, p.getAttempts()), is made for every Participation object, p, by looping through the partList, loading all unattempted attempts into the participationAttemptList temporarily stored in the Session instance. (p.getAttempts() retrieves the list of all 9 Attempt instance that the participation has submitted at the start.)

Step 3: The loadAttempts() method will loop through all the 9 Attempt objects taken in as parameter, and checks if each has been attempted. If an Attempt by that Participation has not been attempted, a new ParticipationAttempt object will be created and added to the list.

Because of the way Session handles the initialising of every new session, be it starting a new competition, resuming a competition, or even starting a session with a competition that has already ended (all attempts have been made by the athletes) is made possible.