Advanced Software Engineering Association for Computing Machinery High

Road Map Introduction p Current System p Proposed System Overview p Requirement (Functional, Non-Functional)

Introduction The Programming Competition brings high school teams to FIU to compete for the

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

Proposed System Overview Registration p Game-Management. p 5

Registration Subsystem Requirements p Functional Requirement n p Non-Functional Requirement n n n p

Game Mgt. Subsystem Requirements p Functional Requirement n n n p Controlled Solution Submission.

Game Mgt. Subsystem Requirements p Constraints n n n Ease of installation. Database Independence

Road Map p Registration Sub-System Scenarios n n p Registration Sub-System Scenario 1 (Hien)

Actor Specification Actors: • Coach • ACMOfficer • E-Mail System Actors Description: • Coach:

Add Team Use Case Specification Brief Description This use case allows a Coach or

Manage Account & Teams User Interfaces 18

Manage Account & Teams Use Case Specification Brief Description This use case allows a

Manage Account & Teams Sequence Diagram 20

Modify Team Use Case Specification Brief Description The use case allows a Coach or

Scenarios of Check-in Subsystem p p p Name: Participating Actors: Flow of Events: n

Use Case Diagram for Check-in Subsystem 28

Actors Specification p Actors: n n p Judge Team Actors Description: n n Judge:

Competition Sub-System p Brief Description This Use Case allows the Team to submit the

Receive Solution Use Case p Brief Description This Use Case describes the process that

Actors Specification p Actors: n p Judge Actors Description: n Judge: Uses the system

Competition Sub-System p Brief Description This Use Case allows the Judge to enter into

Slides: 50

Download presentation

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

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

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

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

Proposed System Overview Registration p Game-Management. p 5

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

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

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

Road Map p Registration Sub-System Scenarios n n p Registration Sub-System Scenario 1 (Hien) Registration Sub-System Scenario 2 (Jose) Game Management Sub-System Scenarios n n 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) 9

Web Registration Use Case Diagram 10

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

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

Add Team Sequence Diagram 13

Add Team User Interface 14

Web Registration Use Case 17

Manage Account & Teams User Interfaces 18

Manage Account & Teams Use 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. 19

Manage Account & Teams Sequence Diagram 20

Web Registration Use Case 21

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

Modify Team Sequence Diagram 23

Web Registration Class Diagram 25

Road Map p Registration Sub-System Scenarios n n p Registration Sub-System Scenario 1 (Hien) Registration Sub-System Scenario 2 (Jose) Game Management Sub-System Scenarios n n 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) 26

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

Use Case Diagram for Check-in Subsystem 28

Sequence Diagram for Check-in 29

Sequence Diagram for Prepare 30

Class Diagram for Check-in Subsystem 31

Competition Use Case 33

Actors Specification p Actors: n n p Judge Team Actors Description: n n 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. 34

Competition Sub-System p Brief Description This Use Case allows the Team to submit the solution that is solved. p p Participating Actors: Flow of Events: n n n p p Team, Judge. 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. 35

Sequence Diagram for Submit Solution 36

Class Diagram for Submit Solution 37

Game Mgt. Use Case Diagram 39

Receive Solution Use Case p Brief Description This Use Case describes the process that the Judge follows upon receipt of a solution. p p Participating Actors: Team, Judge. Flow of Events: n n n p 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 p Exit Condition: Judge Submits a grade report to team 40

Sequence Diagram: Receive Solution 41

Game Mgt. Use Case Diagram 42

Game Mgt. Use Case Diagram 44

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

Competition Sub-System p Brief Description This Use Case allows the Judge to enter into the system the evaluation of a submitted solution. p p Participating Actors: Flow of Events: n n p p Judge enters into the Grade. Solution. Form 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. 46

Sequence Diagram for Grade Solution 47

Class Diagram for Grade Solution 48

Game Mgt. Class Diagram 49

Thank you 50