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)

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

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.

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

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.

Proposed Software Architecture  Two main subsystems Web Based Subsystem Game Management Subsystem  Three other ancillary subsystems DB Access Subsystem subsystem Utility Subsystem

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

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

Proposed Software Architecture (Diagram)

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

Component Diagram For Web Subsystem

Deployment Diagram For Web Subsystem

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

Component Diagram For Game Management Subsystem

Deployment Diagram For Game Management Subsystem

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

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

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

Subsystem Package Diagram

Subsystems Dependencies

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.

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

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

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

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

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

Game Communication Framework Class Diagram

Subsystems Dependencies

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.

Game Server Class Diagram

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.

Scoring Class Diagram

Thank you