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

2. Road Map  Introduction  Proposed Software Architecture  System Decomposition Component Diagram Deployment Diagram  Sub System Services  Object Design

3. Introduction  Purpose Build a system that will manage the ACM Programming Competition including the registration of teams on the web, and the game operations. The system will minimize errors inherent in manual operations, decrease the number of staff required to run the games, increase the communications with the participants prior to the event, and provide current and final results automatically.

4. Introduction  Design Goal Usability User Friendly Response time Maintenance No dependencies to commercial software component.

5. Current Software Architecture  Composed of two separate systems that do not have any communications with each other. 1. Web based registration system  Using ASP deployed on IIS  With flat table database deployed on MS SQL server 2. Game Management  Web-based system deployed on Tomcat.  Polling based notification of the judges that a solution has been submitted.

6. Proposed Software Architecture  Two main subsystems Web Based Subsystem Game Management Subsystem  Three other ancillary subsystems DB Access Subsystem E-mail subsystem Utility Subsystem

7. Subsystem Decomposition  Web Based Subsystem Security Subsystem Team Information Management Subsystem Game Configuration Subsystem

8. Subsystem Decomposition  Game Management Login Judge Interface Team Player Interface Score Board Game Server Scoring Game Communication Framework

9. Proposed Software Architecture (Diagram)

10. Hardware/Software Mapping  Web Based System Components  WebBrowser  Security  Email  ManageTeamServlet  DBInterface  Database Deployed on two nodes:  PC  HostMachine

11. Component Diagram For Web Subsystem

12. Deployment Diagram For Web Subsystem

13. Hardware/Software Mapping  Game Management Subsystem Components  Login  TeamInterface  JudgeInterface  ScoreBoard  GameServer  Scoring  GameCommunicationFramework  DBInterface  Database Deployed on many nodes:  1 Game server  n TeamPC  m JudgePC  1 ScoreBoard

14. Component Diagram For Game Management Subsystem

15. Deployment Diagram For Game Management Subsystem

16. Object Design Trade-Off  Use MS-SQL Server vs. new database  MS Access database vs. other database  Java vs. other languages  Java Messaging System (JMS) vs. Sockets  Tomcat webserver vs. ISS  Servlet & JSP vs. ASP

17. Sub System Services & Object Design  DB Access Subsystem saveTeam saveAccount updateTeam updateAccount getTeam getAccount deleteTeam saveJudge getJudge deleteJudge setNewScore saveScore

18. Sub System Services & Object Design  Web-based  Team Information createNewTeam validateInfo updateTeam deleteTeam reportPay recordComment assignTeamID verifyTeam

19. Subsystem Package Diagram

20. Subsystems Dependencies

21. DB Access Subsystem  Provides an interface to interact with the database and is responsible for all object relational mappings.  We solve this problem by applying the Façade Pattern.

22. DB Access Subsystem  Part of querying a database involves setting up a connection to the database.  Creating and initializing the connection is the most expensive part of a database query.  Avoid creating a connection if at all possible.  Allow all components in a process to use a single global connection resource.  We solve this problem by applying the GangOfFour SingletonPattern. GangOfFourSingletonPattern

23.  If a system only needs one instance of a class, and that instance needs to be accessible in many different parts of a system, you control both instantiation and access by making that class a singleton.  Ensure a class only has one instance  Provide a global point of access to it  The DBAccess class is made a Singleton, so the single connection will be shared by all components.

26. Game Communication Framework  Heart of Game Management Subsystem.  Sits on top of JMS  Provides abstraction layer for Server Judge Team Scoreboard

27. Game Communication Framework  What is JMS?  A framework that provides mechanism for messaging between nodes in distributed network environment.  Provides Point-to-Point Publisher/Subscriber

28. Software Architecture (Diagram) TCP JMS Server Game Communication Framework Score Board Team Interface Judge Interface  GameManagement Subsytem Layers

29. Game Communication Framework Class Diagram

30. Subsystems Dependencies

31. Game Server Subsystem  Manages all relevant game events Maintaining scores Generating final score report Keeps Game clock. Stores solutions for later retreival.  Sits on top of Game Communications Framework  Implements receiveSolutionNotification() callback method.

32. Game Server Class Diagram

33. Scorer Subsystem.  Computes Standing for the game  Rules of the game can potentially change  Two Classes Scorer class provides methods to the Server subsystem for computing standings RulesEngine Interface defines the expected behavior of a RulesEngine to be used by the Scorer class.

34. Scoring Class Diagram

35. Thank you