CS 230 Project Software Design - Tolentino Project 2

.docx

School

Southern New Hampshire University *

*We aren’t endorsed by this school

Course

230

Subject

Computer Science

Date

Feb 20, 2024

Type

docx

Pages

8

Uploaded by UltraCamelMaster345

Report
Draw It or Lose It CS 230 Project Software Design Template Version 1.0
Table of Contents CS 230 Project Software Design Template 1 Table of Contents 2 Document Revision History 2 Executive Summary 3 Requirements 3 Design Constraints 3 System Architecture View 3 Domain Model 3 Evaluation 4 Recommendations 5 Document Revision History Version Date Author Comments 1.0 9 Jul 2023 Raphael Tolentino Changes made to GameService java. Implemented Singleton pattern. Implemented iterators for addGame and getGame methods to ensure only 1 instance of each class 1.1 16 Jul 2023 Raphael Tolentino Added new classes Entity, TeamService, PlayerService. Entity will be parent class for Player, Game, and Team. Added Executive Summary, updated Design constraints and requirements. 2
Executive Summary The Gaming Room currently has an app currently only available on Android called Draw It or Lose it. The company would like to develop a web-based game that serves multiple platforms based off the current game. The game revolves around multiple teams and players guessing what is being drawn by the other team of players. The Gaming Room staff needs assistance in setting up the correct app environment for the game to function on a web-based platform and consulted our company to facilitate its development. Requirements - Games will consist of four rounds of 1-minute each. - Drawings need to be completed at the 30-second mark. - Game pulls from an image library of stock drawings. - Allows the competing team to “steal” the guess if the guessing team does not guess the puzzle on time. - Client wants to streamline development into the web-based version. Design Constraints - Needs to have one or more teams - Each team needs to support multiple players assigned to it - Game and Team Names must be unique - Create unique identifiers for each game instance, team, or player to prevent memory leak System Architecture View Please note: There is nothing required here for these projects, but this section serves as a reminder that describing the system and subsystem architecture present in the application, including physical components or tiers, may be required for other projects. A logical topology of the communication and storage aspects is also necessary to understand the overall architecture and should be provided. Domain Model ProgramDriver class contains main() method and uses Directed Association with the SingletonTester to test if there’s already an instance of GameService. Entity class is the parent class to Game, Team, and Player Classes. Game, Team, and Player all inherity Entity’s required attributes. It goes from Game > Team > Player, which means a Player cannot have a Team, but a Team can have a Player, and a Team cannot have a Game, but the Game can have a Team. A Game cannot have a GameService but a GameService can have a Game. GameService must only have one instance of each game running at any time. Each Game can only have one unique Team at any time. Each Team can only have one of Each individual Player at one time. 3
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help