University of Pretoria

EPE 321 Software Engineering 321

Software Requirements, Analysis and Modeling

James Shorten 28106182

Paul De Kock 29614092

August 22, 2011

UNIVERSITY OF PRETORIA FACULTY OF ENGINEERING, THE BUILT ENVIRONMENT & IT DEPARTMENT OF EECE The Department of EECE places specic emphasis on integrity and ethical behavior with regard to the preparation of all written work to be submitted for academic evaluation. Although academic personnel will provide you with information regarding reference techniques as well as ways to avoid plagiarism, you also have a responsibility to fulll in this regard. Should you at any time feel unsure about the requirements, you must consult the lecturer concerned before you submit any written work. You are guilty of plagiarism when you extract information from a book, article or web page without acknowledging the source and pretend that it is your own work. In truth, you are stealing someone elses property. This doesnt only apply to cases where you quote verbatim, but also when you present someone elses work in a somewhat amended format (paraphrase), or even when you use someone elses deliberation without the necessary acknowledgement. You are not allowed to use another students previous work. You are furthermore not allowed to let anyone copy or use your work with the intention of presenting it as his/her own. Students who are guilty of plagiarism will forfeit all credit for the work concerned. In addition, the matter can also be referred to the Committee for Discipline (Students) for a ruling to be made. Plagiarism is considered a serious violation of the Universitys regulations and may lead to suspension from the University. For the period that you are a student at the Department of EEC, the under mentioned declaration must accompany all written work to be submitted. No written work will be accepted unless the declaration has been completed and attached. We (full names): Student Numbers: Subject of work: Declaration: 1. We understand what plagiarism entails and am aware of the Universitys policy in this regard. 2. We declare that this report is our own, original work. Where someone elses work was used (whether from a printed source, the internet or any other source) due acknowledgement was given and reference was made according to departmental requirements. 3. We did not make use of another students previous work and submitted it as our own. 4. We did not allow and will not allow anyone to copy our work with the intention of presenting it as his or her own work. James Richard Shorten Paul De Kock 28106182 29614092 Software Engineering

Signatures: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contents
1 Introduction 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2 Overall Description 2.1 Product Perspective . . . . . 2.1.1 Existing Systems . . . 2.1.2 Proposed System . . . 2.2 Product Functions . . . . . . 2.3 User Characteristics . . . . . 2.4 Constraints, Assumptions and 3 Specic Requirements 3.1 External Interface . . . . . 3.2 Functions . . . . . . . . . . 3.3 Performance Requirements 3.3.1 Articial Intelligence 3.3.2 User Interface . . . . 3.3.3 Game Logic . . . . . 3.3.4 Networking . . . . . 3.4 Key Features . . . . . . . . 3 3 3 3 4 4 4 4 4 6 6 6 6 6 6 6 9 9 9 9 9 9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dependancies .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 System Archetectural Design 4.1 Chosen System Architecture . . . . . . . . . . . . . . . . . . .

List of Figures
2.1 3.1 3.2 4.1 Use Case Diagram . . . . . Act. Diagram for Program . Game Flow . . . . . . . . . Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7 8 11

List of Tables

1
1.1

Introduction
Purpose

The Purpose of this project is to create (using good Software Engineering methodology) a multiplayer chess game. This involves the creation of three basic modules: 1. Graphical User Interface (GUI) 2. Networking 3. Articial Intelligence Apart from conforming to the rules of standard chess the game should restrict players and the AI to no more than 60 seconds per move. The code needs to comply with the EPE 321 coding standard (the Google c++ Style Guide [1]). All requirements for this project are based on those given in the General Requirements [2] document.

1.2

Scope

The scope of the software involves the realisation three components described in Section 1.1 within a software product. This implies the development of an entirely new system.

1.3

System Overview

The System will comprise four main components: 1. Game Logic to ensure that only correct moves are made and to check for win, lose and stalemate conditions and to enforce the turn time limits. 2. Networking to provide reliable communications with another chess game via a protocol that is to be dened at a later date. 3. AI to select intelligent moves for the computer to make. 4. User Interface to provide an attractive, intuitive interface for the program.

2
2.1

Overall Description
Product Perspective
Existing Systems

2.1.1

We shall focus on GNU Chess as it is representative of most chess programs in the market. GNU Chess is part of the GNU project. It is mainly a computer chess program (AI). GNU Chess plays against either another computer program or a human player. It is thus merely a GUI and an AI component. GNU Chess has a very strong AI component. [3] GNU Chess is, however, limited to a simple two dimensional interface(Winboard or Xboard) and has no support for multiple human players. 2.1.2 Proposed System

The proposed system will correct these shortcomings by implementing an attractive and intuitive three-dimensional user interface. It will also include a network component that will allow for two human players, a human and a AI player or two AI players. The AI will not be neglected but it is not critical to the success of the product.

2.2

Product Functions

Figure 2.1 shows a Use Case Diagram for the product. It identies the following functions: 1. Start local game: Play on the local machine either against a friend or the computer. 2. Start network game: Play against a friend over the network or pit your programs AI against an opponent across the network. 3. Connect to hosted game: Connect to a friends game and play yourself or let the AI play. 4. Make a move: Make a legal move in a game. 5. Change the view: Move the view in 3d space. 6. Choose color: When hosting a game choose the color to play as. 7. Forfeit game: Give the game to your opponent.

Start Local Multiplayer

Start Local Singleplayer

Start Network Multiplayer

Player 1

Start Network AI Play

AI

Connect to Hosted Game

Connect to Hosted AI Game

Make Move

Change View Player 2 Player 1 Choose Colour Network

Figure 2.1: Use Case Diagram

2.3

User Characteristics

The users of this program will all be technically oriented (they are all computer engineering students) thus the program can be technically sophisticated. This does not, however, relax the requirement for good user interface design.

2.4

Constraints, Assumptions and Dependancies

The computer has support for three-dimensional graphics. The computer is running Windows, Linux or Mac OS X. There is network connectivity.

3
3.1 3.2

Specic Requirements
External Interface Functions

The overall program ow is shown (as an activity diagram) in Figure 3.1 and the ow of a generic game (valid for both network and local games with AI and human players) is shown in Figure 3.2. The program ow is fairly self explanatory. The user selects a game type, plays a game and then either starts a new game or exits the program. The ow of a Game is rather more complicated. First the White player is required to make a move. The program waits until either a valid move is made or the timer expires. If the timer expires then the player is assumed to have forfeited the game as black wins. If a valid move is made the program checks for win, lose, and stalemate conditions if none of these are satised then it is the black players turn. The same process is repeated for the black player and if the game is not one the whole process is repeated

3.3
3.3.1

Performance Requirements
Articial Intelligence

The performance of the algorithms for the AI is critical. All modern computer chess algorithms use some form of the mini-max algorithm, generally with alpha-beta pruning. The deeper the computer can search (the further ahead it can look) the better the resulting moves. This depth is entirely dependent on algorithmic eciency [4]. With the 60 second per move time limit this becomes increasingly important.

Start

Select Game Type Select Game Type

Local Local Multiplayer Multiplayer

Local Local Singleplayer Singleplayer

Network Network Multiplayer Multiplayer

Network AI Play Network AI Play

Connect to Connect to Game Game

Connect AI to Connect AI to Game Game

Make Move Make Move

Change View Change View

Player 1 Player 1 Chooses Colour Chooses Colour

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Play Game Play Game

Figure 3.1: Activity Diagram for Whole Program

White Move White Move

Invalid

Check if Valid

Valid Yes

Black Wins Black Wins

Check for Time Expiration

No

White Wins White Wins

Yes

Check for Checkmate

No

Black Move Black Move

Invalid

Check if Valid

Valid Yes

White Wins White Wins

Check for Time Expiration

No

Yes

Black Wins Black Wins

Check for Checkmate

No

Figure 3.2: Game Flow Diagram

3.3.2

User Interface

The only requirement here is that the UI reamins responsive at all times. In other words the UI must never freeze. Thus we need to ensure that no operation will ever block the UI thread for any signicant time. 3.3.3 Game Logic

The performance of the game logic is not critical provided that it does not take an inordinate length of time to complete things like validity checks. Correctness is of far greater importance. 3.3.4 Networking

Networking performance is important but is reliant on the protocol to a large degree. Thus, when the protocol is discussed we must push for a very ecient specication.

3.4

Key Features

1. Network Play This is a feature that is not available in most other chess games therefore its successful implementation is critical. It is important for us to implement the protocol correctly and eciently in order to get adequate performance here. 2. Three-dimensional Graphics The 3D graphics will be important for the UI and it is critical to focus on this area as neither of us has experience in this area. 3. Articial Intelligence The AI requires specic attention as this is the focus of the competition at the end of the module. Thus we need to devote A fair amount of design work to this feature to ensure it is correct and has excellent performance.

4
4.1

System Archetectural Design

Chosen System Architecture

We have chosen to base our architecture on the proven Model View Controller (MVC) design pattern. This design pattern is used by many APIs and other systems. It provides great separation of data (the Model) and User Interface (the View). The two communicate only with the Controller and the trac is one way; from the controller to the other class. Design patterns such as delegate allow the model and the view to notify the controller of changes. Thus the View does not need to know how the data is stored and the Model has no need to understand how that data is displayed. 9

Figure 4.1 shows a basic class diagram of the proposed architecture. The Controller class contains a View, a GameState and 2 Player objects. The GameState and Player objects are data model objects and the View object is naturally a View. Player itself is an abstract class with three concrete subclasses: HumanPlayer: Manages the interaction with a human player by notifying the Controller when input is needed. It thus farms out most of its functionality to the controller. AIPlayer: Manages the AI component of the program and provides an interface that allows the AI to appear to the program as if it is another program. The AI system is likely to be mostly separate from the rest of the program (another thread or even a separate process) so this class ill manage that in a way that abstracts it from the rest of the program. NetworkPlayer: Manages the network connection to another chess program and allows this connection to be seen as just another player by the program. This player architecture allows the generic game ow from Figure 3.2 and Section 3.2 to be used regardless of the mix of players. In other words the game logic no longer has to care what type of player it is dealing with. The GameState class keeps track of the current status of the game. It looks after such things as the turn timer and the position (current layout of the board). It contains a Position object that is an aggregate of Pieces. The Piece class is an abstract class that is subclassed by the various pieces. The class contains an interface that allows one to determine its position on the board, its color and its moves. The Position class will then determine wich of the moves are actually available.

10

-Parent

Controller

-Parent

-Child -Child View -Child

GameState

Player

1 Position HumanPlayer

1 Piece AIPlayer

Pawn

NetworkPlayer

Knight

Bishop

Rook

King

Queen

Figure 4.1: System Architecture

11

References
[1] B. Weinberger, C. Silverstein, G. Eitzmann, M. Mentovai, and T. Landray, Google c++ style guide. http://google-styleguide. googlecode.com/svn/trunk/cppguide.xml, Accessed 22 August 2011. [2] H. Myburgh, General requirements. http://www.ee.up.ac.za/main/ _media/en/undergrad/subjects/epe321/general_requirements. doc, August 2011. [3] Gnu chess. http://www.gnu.org/s/chess/, Accessed 22 August 2011, April 2011. [4] Computer chess. http://en.wikipedia.org/wiki/Computer_chess, Accessed 22 August 2011, August 2011.

12