Advanced Software Engineering Association for Computing Machinery High School Competition System Prof: Masoud Sadjadi Fall 2004 First Deliverable By: Prasad Tummala, Hien Nguyen, Jose Ballesteros, Pablo A. Maurin, Bin Liu, Rafael Alpízar (Team four)

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

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

Current System Registration Table A highly successful program, Needs Automation and streamlining

Proposed System Overview  Registration  Game-Management.  Data Transfer

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

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

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

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 (Prasad) Game Management Sub-System Scenario 1 (Pablo) Game Management Sub-System Scenario 1 (Bin) Game Management Sub-System Scenario 1 (Rafael)

Web Registration Use Case Diagram

Actor Specification Actors: Coach ACMOfficer 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. System: actor in charge of sending s.

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

Add Team Sequence Diagram

Add Team User Interface

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 (Prasad) Game Management Sub-System Scenario 1 (Pablo) Game Management Sub-System Scenario 1 (Bin) Game Management Sub-System Scenario 1 (Rafael)

Web Registration Use Case

Manage Account & Teams User Interfaces

Manage Account & Teams Use Case Specification Brief Description This use case allows a Coach or ACMOfficer to modify a team. Participating actors: Coach, ACMOfficer, 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.

Manage Account & Teams Sequence Diagram

Web Registration Use Case

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

Modify Team Sequence Diagram

Web Registration Class Diagram

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 (Prasad) Game Management Sub-System Scenario 1 (Bin) Game Management Sub-System Scenario 1 (Rafael)

Competition Use Case

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.

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.

Sequence Diagram for Submit Solution

Class Diagram for Submit Solution

Game Mgt. Class Diagram

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 (Prasad) Game Management Sub-System Scenario 1 (Bin) Game Management Sub-System Scenario 1 (Rafael)

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

Game Mgt. Use Case Diagram

Use Case Diagram for Check-in Subsystem

Sequence Diagram for Check-in

Sequence Diagram for Prepare

Class Diagram for Check-in Subsystem

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 (Prasad) Game Management Sub-System Scenario 1 (Bin) Game Management Sub-System Scenario 1 (Rafael)

Game Mgt. Use Case Diagram

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 following Otherwise 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

Sequence Diagram: Receive Solution

Game Mgt. Use Case Diagram

Thank you