Download Let's Play Chess Software Design Document and more Lab Reports Software Engineering in PDF only on Docsity! Technology Business Development (TBD) Software Design Document Let’s Play Chess® Prepared by: Greta Evans, Chris DiJoseph, Chris Dulsky, Oleg Pistolet, Isaac Gerhart-Hines Version 1.3 5 Revision History Name Date Description Version All Members 3 Mar 2009 Traceability Tables, Minor Revisions 1.3.0.0 Chris DiJoseph 2 Mar 2009 Uml Class diagrams 1.2.0.0 Isaac 2 Mar 2009 Sequence Diags. 1.1.0.0 Chris DiJoseph 26 Feb 2009 Initial Version 1.0.0.0 8 2. Architecture Design 2.1. UML Component Diagram 2.1.1. Driver Requirements satisfied: 200, 210, 290, 300, 310, 305 The Driver begins each game and delegates control of the game to each individual class. Driver uses the Game interface. 2.1.2. Player Requirements satisfied: 315, 320 Player is responsible for decision making of the computer player (AI) and human players. Player provides the Player interface which is utilized by the AIPlayer and HumanPlayer classes. 2.1.3. Game Requirements satisfied: 220, 230, 240, 340, 350 Game contains data including player instances, board class instances, time, and instances of pieces on the board. Responsible for the type of game being played: timed or standard game. Game provides the Game interface, and it utilizes the Piece interface which is used for the different possible pieces: rook, pawn, bishop, knight, king, and queen. Game also uses the XML Converter interface and the Player interface. 2.1.4. Save/Load System 9 Requirements satisfied: 250, 260, 270, 280 The Save/Load System is responsible for saving and loading chess games through XML conversion. This includes player status, board layout, and piece placement. It provides the XML Converter interface. 10 3. Static Design Structure Modeling 3.1. UML class diagram 3.1.1. Driver class - This is the class that holds the main function. - It starts the game and hands control of the game over to the other classes. 3.1.2. Game - This class is an interface that handles how to play the game. - Contains player and board class instances 3.1.2.1. TimedGame - Plays a timed game - Keeps track of each players times 3.1.2.2. NormalGame - Plays a standard game 3.1.3. Player - This is an interface that determines which type of players are playing - Is a part of the Game class 3.1.3.1. HumanPlayer - Implements a human player 3.1.3.2. AIPlayer - Implements an AI player 3.1.4. Board 13 4.2. Sequence diagram for “Load New Game” use case (5.1.1 in SRS) 14 4.3. Sequence diagram for “Load Saved Game” use case (5.1.2 in SRS) 15 4.4. Sequence diagram for “Quitting Game” use case (5.1.3 in SRS) 18 4.7. Sequence diagram for “Modifying the Board” use case (5.4 in SRS) 19 5. Requirement Traceability Table 5.1. Traceability by Requirement Numbers Req # Design Component 100 NFR 110 NFR 120 NFR 130 NFR 200 2.1.1 210 2.1.1, 3.1.2.1 220 2.1.3 230 2.1.3, 3.1.3, 3.1.3.1, 3.1.3.2 240 2.1.3 250 2.1.4, 3.1.7 260 2.1.4, 3.1.7 270 2.1.4, 3.1.7 280 2.1.4, 3.1.7 290 2.1.1, 3.1.5 300 2.1.1, 3.1.5 305 2.1.1, 3.1.5 310 2.1.1, 3.1.5 315 2.1.2 320 2.1.2 330 3.1.6, 3.1.6.1, 3.1.6.2, 3.1.6.3, 3.1.6.4, 3.1.6.5, 3.1.6.6, 3.1.4 340 2.1.3 350 2.1.3, 3.1.2 5.2. Traceability by Design Component Design Component: Req # 2.1.1 200, 210, 290, 300, 305, 310 2.1.2 315, 320 2.1.3 220, 230, 240, 340, 350 2.1.4 250, 260, 270, 280 3.1 210, 230, 250, 260, 270, 280, 290, 300, 305, 310, 330, 350 NFR 100, 110, 120, 130
