1 / 35

Road Map

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

emmanuel-hale
Download Presentation

Road Map

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Advanced Software EngineeringAssociation for Computing MachineryHigh School Competition SystemProf: Masoud Sadjadi Fall 2004Second DeliverableBy: 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. • Web based registration system • Using ASP deployed on IIS • With flat table database deployed on MS SQL server • 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 GangOfFourSingletonPattern.

  23. Singleton Pattern • 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.

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

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

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

  27. Game Communication Framework Class Diagram

  28. Subsystems Dependencies

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

  30. Game Server Class Diagram

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

  32. Scoring Class Diagram

  33. Thank you

More Related