High School Competition Management System

1. Advanced Software EngineeringAssociation for Computing MachineryHigh School Competition SystemProf: Masoud Sadjadi Fall 2004First DeliverableBy: Prasad Tummala, Hien Nguyen, Jose Ballesteros, Pablo A. Maurin, Bin Liu, Rafael Alpízar (Team four)

2. Road Map • Introduction • Current System • Proposed System Overview • Requirement (Functional, Non-Functional) • Registration Sub-System • Game Management Sub-System

3. Introduction The Programming Competition brings high school teams to FIU to compete for the prestigious FIU-ACM awards.

4. Current System Registration Table A successful event, Needs Automation and streamlining

5. Proposed System Overview • Registration • Game-Management.

6. Registration Subsystem Requirements • Functional Requirement • Web Registration • Non-Functional Requirement • Ease Backup/Restore • User Friendly • Scalable • Constraints • Ease of backup/restore. • Database Independence

7. Game Mgt. Subsystem Requirements • Functional Requirement • Controlled Solution Submission. • In system Judging/feedback. • Automatic Result Generation • Non-Functional Requirement • Ease Backup/Restore • User Friendly • Maintain Team anonymity

8. Game Mgt. Subsystem Requirements • Constraints • Ease of installation. • Database Independence • Interconnectivity Constraint • Platform independence • System must Standalone

9. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 2 (Prasad) • Game Management Sub-System Scenario 3 (Rafael) • Game Management Sub-System Scenario 4 (Pablo)

10. Web Registration Use Case Diagram

11. Actor Specification • Actors: • Coach • ACMOfficer • E-Mail System • Actors Description: • Coach: uses the system to create an account that allows him to register teams for the competition. Moreover, he can manage his account and teams. • ACMOfficer: uses the system to maintain team information and coach accounts. • E-mail System: actor in charge of sending e-mails.

12. Add Team Use Case Specification Brief Description This use case allows a Coach or ACMOfficer to add a new team. Flow of Events 1. System displays the form used to register a team. 2. Coach or ACMOfficer enters all the required information and submits data. 3. System validates that the required info was entered. 4. System sends a confirmation e-mail to the Coach. 5. System storages the new team data. Entry Condition: Coach or ACMOfficer is presented with the registration form. Exit Conditions: Coach or ACMOfficer adds a team and receives confirmation message and an e-mail.

13. Add Team Sequence Diagram

14. Add Team User Interface

16. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 2 (Prasad) • Game Management Sub-System Scenario 3 (Rafael) • Game Management Sub-System Scenario 4 (Pablo)

17. Web Registration Use Case

18. Manage Account & TeamsUser Interfaces

19. Manage Account & TeamsUse Case Specification Brief Description This use case allows a Coach or ACMOfficer to modify a team. Participating actors: Coach, ACMOfficer, E-mail System. Flow of events: 1. A Coach or an ACMOfficer logs into the system. 2. If the user is a Coach, System presents all the information about the teams from his school and a list of possible actions (Add Team, Delete Team, Modify Team and Manage Account), excluding the actions Report Payment and Write Comment. 3. If the user is an ACMOfficer, System presents a list of all posible actions and all the information about all schools and their respective teams. 4. Coach or ACMOfficer selects an action and team(s) if the action is to be applied to a team. 5. Include the corresponding use case. Entry Condition: Coach or ACMOfficer logs into the system. Exit Conditions: An action is carried out.

20. Manage Account & Teams Sequence Diagram

21. Web Registration Use Case

22. Modify Team Use Case Specification Brief Description The use case allows a Coach or ACMOfficer to modify a team. Flow of events: 1. System presents existing information and allows modifications. 2. Coach or ACMOfficer modifies information and submits the new data. 3. System validates that the required information was entered. 4. System sends a confirmation e-mail. 5. System updates the team data. Entry Condition: Coach or ACMOfficer is presented with current information of a team. Exit Conditions: Information about the team is updated.

23. Modify Team Sequence Diagram

25. Web Registration Class Diagram

26. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 1 (Prasad) • Game Management Sub-System Scenario 1 (Rafael) • Game Management Sub-System Scenario 1 (Pablo)

27. Scenarios of Check-in Subsystem • Name: Prepare the System • Participating Actors: Administrator • Flow of Events: • Administrator create a folder to store the team’s solution. • Administrator enter the information of judge • Administrator enter and confirm competition rules • Name: Check-In Teams • Participating Actors: Administrator • Flow of Events: • Administrator verify the team information and payment status • Assign each team an unique team ID

28. Use Case Diagram for Check-in Subsystem

29. Sequence Diagram for Check-in

30. Sequence Diagram for Prepare

31. Class Diagram for Check-in Subsystem

32. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 2 (Prasad) • Game Management Sub-System Scenario 3 (Rafael) • Game Management Sub-System Scenario 4 (Pablo)

33. Competition Use Case

34. Actors Specification • Actors: • Judge • Team • Actors Description: • Judge: Uses the system to grade the solutions and to update the scores for each team. • Team: Uses the system to participate in the Competition and solves the problem those are given during the Competition.

35. Competition Sub-System • Brief Description This Use Case allows the Team to submit the solution that is solved. • Participating Actors: Team, Judge. • Flow of Events: • Team selects the question number they want to submit. • Team selects the location of the directory or file where is the answer. • Team submits data. • System removes the submitted question number from the list of question numbers. • Judge is alerted of the new submission. • Entry Condition: • Team is able to select the question number and browse for the file location. • Exit Condition: • Judge is alerted of new submission.

36. Sequence Diagram for Submit Solution

37. Class Diagram for Submit Solution

38. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 2 (Prasad) • Game Management Sub-System Scenario 3 (Rafael) • Game Management Sub-System Scenario 4 (Pablo)

39. Game Mgt. Use Case Diagram

40. Receive Solution Use Case • Brief Description This Use Case describes the process that the Judge follows upon receipt of a solution. • Participating Actors:Team, Judge. • Flow of Events: • Judge is alerted that a team has submitted a solution • If she chooses to grade this solution she does the followingOtherwise she does nothing. • Downloads the files • Inspects and grades the solution • Submits a grade report to the team • Entry Condition: Judge is alerted that a team has submitted a solution • Exit Condition: Judge Submits a grade report to team

41. Sequence Diagram: Receive Solution

42. Game Mgt. Use Case Diagram

43. Road Map • Registration Sub-System Scenarios • Registration Sub-System Scenario 1 (Hien) • Registration Sub-System Scenario 2 (Jose) • Game Management Sub-System Scenarios • Game Management Sub-System Scenario 1 (Bin) • Game Management Sub-System Scenario 2 (Prasad) • Game Management Sub-System Scenario 3 (Rafael) • Game Management Sub-System Scenario 4 (Pablo)

44. Game Mgt. Use Case Diagram

45. Actors Specification • Actors: • Judge • Actors Description: • Judge: Uses the system to grade the solutions and to update the scores for graded solution.

46. Competition Sub-System • Brief Description This Use Case allows the Judge to enter into the system the evaluation of a submitted solution. • Participating Actors: Judge. • Flow of Events: • Judge enters into the GradeSolutionForm his evaluation of solution. • System records score for submitted solution • System invokes rules engine to compute new team scores and rankings. • System notifies and updates Scoreboard. • Entry Condition: • After Judge finishes grading a solution, the results of his evaluation are need to be entered. • Exit Condition: • Judge is alerted of new submission.

47. Sequence Diagram for Grade Solution

48. Class Diagram for Grade Solution

49. Game Mgt. Class Diagram

50. Thank you