Project: The Watson Game



Project: The Watson Game

Function: Server

Subsystem: Challenge Dispatching

Author: Bryan Sullivan

Date: 5/12/05

1 Introduction 3

1.1 Goals and objectives 3

1.2 Statement of scope 3

1.3 Software context 3

1.4 Major constraints 3

2 Data design 4

2.1 Internal software data structure 4

2.2 Global data structure 4

2.3 Temporary data structure 4

2.4 Database description 4

3 Architectural and component-level design 4

3.1 Program Structure 5

3.1.1 Architecture diagram 5

3.1.2 Alternatives 5

3.2 Description for Challenge Handler 5

3.2.1 Processing narrative (PSPEC) for challenge handler 6

3.2.2 Challenge Handler processing detail 6

3.3 Software Interface Description 6

3.3.1 External machine interfaces 7

3.3.2 External system interfaces 7

3.3.3 Human interface 7

4 User interface design 7

4.1 Description of the user interface 7

4.1.1 Screen images 7

4.1.2 Objects and actions 7

4.2 Interface design rules 7

4.3 Components available 7

4.4 UIDS description 8

5 Restrictions, limitations, and constraints 8

6 Testing Issues 8

6.1 Classes of tests 8

6.2 Expected software response 8

6.3 Performance bounds 8

6.4 Identification of critical components 8

7 Appendices 8

7.1 Requirements traceability matrix 9

7.2 Packaging and installation issues 9

7.3 Design metrics to be used 9

7.4 Supplementary information (as required) 9

SOFTWARE DESIGN SPECIFICATION

Introduction

The Watson Adventure Game (WAG) is a great project that has been under development by seniors at Binghamton University for the past four semesters. Currently n the developmental stage the project allows seniors to showcase their problem solving and coding abilities they have acquired throughout their undergraduate career. When the project is finalized it will be used as a unique tool to recruit students interested in computer science and Binghamton University.

1 Goals and objectives

The long term objective of this project is to create a bug free, easy to use, interactive game illustrating the academic program at the Watson School of Engineering and Applied Science at Binghamton University.

2 Statement of scope

The WAG is designed as a 3D first person view game where the student makes their way through the Watson building completing tasks, tests, and challenges. Much like an actual Watson student, the player will need to sign up for classes and try to finish the program with a grade point average of 4. Among academics, the game also presents the player with everyday challenges (referred to as life challenges in this document) which include the need to eat and drink, fix your broken laptop, and make sure you have pencils for a test to name a few.

3 Software context

The software is being developed by Binghamton University Seniors participating in Senior Seminar (a mandatory class for all Computer Science Undergraduates) under the direction of Professor Richard Steflik. The client for the WAG is being developed with C++, the server is written in Java, and although the database has been Microsoft Access, this semester it was converted to a MySql database.

4 Major constraints

Major constraints of the WAG are that the user’s computer must be capable of rendering 3D models at a reasonable rate to prevent choppiness. The client must be able to handle 30+ concurrent users accessing the system, and the database must also be able to handle transactions from many users simultaneously.

Data design

The three classes used by the challenge dispatcher are WGconnection, WGcommand, and WatsonResultSet. These data structures provide the challenge dispatcher with the socket connection, the type of results requested by the client, and the actual result set returned from the database respectively.

1 Internal software data structure

As stated above the WGconnection provides the socket to write back to, WGcommand provides the type of results (hotspot ID) and the WatsonResultSet stores the dataset that was retrieved

2 Global data structure

Once again the three structures, WGconnection, WGcommand, and WatsonResultSet that are used here are available to the entire program.

3 Temporary data structure

A vector is used to take in all arguments from WGcommand.

4 Database description

The database contains all hotspot ID’s and all the challenges related to that hotspot. This semester’s database team had added life challenges to make a total of twenty-six. The challenge dispatcher uses an object from DatabaseObject.java to get the challenge for the correct hotspot ID from the database.

Architectural and component-level design

A description of the program architecture is presented.

1 Program Structure

The program consists of a server, client, and database. All these components must mesh together seamlessly in order to ensure a fully operable system. Included in this document is how the challenge dispatcher works with the components.

1 Architecture diagram

[pic]

2 Alternatives

There have been no other alternatives discussed this semester.

2 Description for Challenge Handler

The ChallengeDispatcher method receives the communication port to the client and the hotspotID of the challenge. The dispatcher distinguishes whether the challenge is an academic challenge or a life challenge. If the challenge is a life challenge, the dispatcher calls LifeChallengeHandler. The dispatcher then uses DatabaseObject to query the database and find the challenge corresponding to the hotspotID. When the challenge is found the results are returned to the client.

1 Processing narrative (PSPEC) for challenge handler

N/A

1 Challenge Handler interface description.

N/A

2 Challenge Handler processing detail

N/A

1 Interface description

N/A

2 Algorithmic model (e.g., PDL)

N/A

3 Restrictions/limitations

N/A

4 Local data structures

N/A

5 Performance issues3.2.3.6 Design constraints

N/A

3 Software Interface Description

The software interfaces with the client’s machine, the databaseObject, and the lifeChallengeHandler. The client’s machine sends requests to the challenge handler, which then uses the databaseObject to query the database. After receiving the data from the database the challenge handler returns it to the client’s machine. The lifeChallengeHandler is called if the data returned from the database is for a life challenge.

1 External machine interfaces

The challenge dispatcher communicates with the client through a socket over the network.

2 External system interfaces

The challenge dispatcher interfaces with the Sql database using the databaseObject.

3 Human interface

No human interfaces

User interface design

The user has no direct interface with the challenge dispatcher

1 Description of the user interface

N/A

1 Screen images

N/A

2 Objects and actions

N/A

2 Interface design rules

N/A

3 Components available

N/A

4 UIDS description

N/A

Restrictions, limitations, and constraints

The main restriction on the system is the efficiency of the server. The server must be able to handle the amount of users that may be logged on at one time and the amount of traffic over the network.

Testing Issues

1 Classes of tests

2 Expected software response

3 Performance bounds

4 Identification of critical components

Appendices

1 Requirements traceability matrix

2 Packaging and installation issues

N/A

3 Design metrics to be used

N/A

4 Supplementary information (as required)

N/A

-----------------------

Challenge Dispatcher:

Queries database for info, results are sent back to client

Database:

Queried for challenge info by hotspot coordinates, returns all challenge info.

Server:

Receives request and calls Challenge Dispatcher.

Client:

Request for Challenge at a given hotspot location

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download