Let's Play Chess Software Design Document, Lab Reports of Software Engineering

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.

Revision History

Name Date Description Version All Members 3 Mar 2009 Traceability Tables, Minor Revisions

Chris DiJoseph 2 Mar 2009 Uml Class diagrams 1.2.0. Isaac 2 Mar 2009 Sequence Diags. 1.1.0. Chris DiJoseph 26 Feb 2009 Initial Version 1.0.0.

1. Introduction

1.1. Purpose

The purpose of this document is to specify the entire software architecture of the Let’s Play Chess software system. The design decisions herein relate directly and indirectly to the performance, functionality, interfaces, attributes of said system. The Let’s Play Chess software system is an electronic simulation of the game of chess. It is meant to serve as a lightweight, portable chess-playing tool for users ranging from the novice player to seasoned pros.

1.2. Scope

This document is intended primarily for the architects, developers, testers, and managers of the Let’s Play Chess project. It is intended to describe the software requirements of the initial release of the software.

1.3. Definitions, Acronyms, and Abbreviations

UML Component Diagram – Diagram depicting how a software system is split up into components and shows the dependencies among these components. UML Class Diagram – Diagram describing the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Sequence Diagram – Diagram showing how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespan of objects relative to those messages. Requirements Traceability Table – Table verifying that each functional requirement used in the development matches those established for test cases. This lets testing teams double-check that all required system features are tested.

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

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

• Handles the display of the board
• Keeps track of where each piece is located 3.1.5. Menu
• Displays the main menu to the player or players
• Displays the in-game menus to the player or players 3.1.6. Piece
• An interface that handles each type of game piece 3.1.6.1. Pawn
• Implements a chess pawn
• Handles a pawn’s special first move 3.1.6.2. Knight
• Implements a knight
• Handles the move of a knight 3.1.6.3. Bishop
• Implements a bishop
• Handles a bishop’s move 3.1.6.4. Rook
• Implements a rook
• Handles a rook’s move
• Handles a rook’s role in castling and castling eligibility 3.1.6.5. Queen
• Implements a queen
• Handles a queen’s move 3.1.6.6. King
• Implements a king
• Handles a king’s move
• Handles castling and determines whether a king is eligible for castling 3.1.7. XmlConverter
• Converts a game’s status into xml format
• Saves a game in xml format
• Loads a game from an xml file

4.2. Sequence diagram for “Load New Game” use case (5.1.1 in SRS)

4.3. Sequence diagram for “Load Saved Game” use case (5.1.2 in SRS)

4.5. Sequence diagram for “Making a Move” use case (5.2 in SRS)

4.6. Sequence diagram for “Winning the Game” use case (5.3 in SRS)

5. Requirement Traceability Table

5.1. Traceability by Requirement Numbers

Req # Design Component 100 NFR 110 NFR 120 NFR 130 NFR 200 2.1. 210 2.1.1, 3.1.2. 220 2.1. 230 2.1.3, 3.1.3, 3.1.3.1, 3.1.3. 240 2.1. 250 2.1.4, 3.1. 260 2.1.4, 3.1. 270 2.1.4, 3.1. 280 2.1.4, 3.1. 290 2.1.1, 3.1. 300 2.1.1, 3.1. 305 2.1.1, 3.1. 310 2.1.1, 3.1. 315 2.1. 320 2.1. 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. 340 2.1. 350 2.1.3, 3.1.

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

210, 230, 250, 260, 270, 280, 290, 300, 305, 310, 330, 350 NFR 100, 110, 120, 130