Docstoc

Project The Watson Game brow liner

Document Sample
Project The Watson Game brow liner Powered By Docstoc
					                         Project: The Watson Game
                            Function: Database
                 Subsystem: Overall Database Responsibility
                         Author: Marc Van Gelder
                               Date: 5/8/2005




Class: CS 495 Spring 2005                             Author: Marc Van Gelder
Project: The Watson Game                                       Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
1      Introduction ................................................................................................................. 4
    1.1      Goals and objectives ........................................................................................... 4
    1.2      Statement of scope .............................................................................................. 4
    1.3      Software context ................................................................................................. 4
    1.4      Major constraints ................................................................................................ 4
2      Data design.................................................................................................................. 5
    2.1      Internal software data structure ........................................................................... 5
    2.2      Global data structure ........................................................................................... 5
    2.3      Temporary data structure .................................................................................... 5
    2.4      Database description ........................................................................................... 5
3      Architectural and component-level design ................................................................. 7
    3.1      Program Structure ............................................................................................... 7
       3.1.1      Architecture diagram .................................................................................. 8
       3.1.2      Alternatives ................................................................................................. 8
    3.2      Description for Component 1: ‘elevator’ Table .................................................. 8
       3.2.1      Processing narrative (PSPEC) for Component 1 ........................................ 8
       3.2.2      Component 1 interface description. ............................................................ 9
       3.2.3      Component 1 processing detail ................................................................... 9
    3.3      Description for Component 2: ‘lifechallenges’ Table ........................................ 9
       3.3.1      Processing narrative (PSPEC) for Component 2 ........................................ 9
       3.3.2      Component 2 interface description. .......................................................... 10
       3.3.3      Component 2 processing detail ................................................................. 10
    3.4      Description for Component 3: ‘objectlist’ Table .............................................. 10
       3.4.1      Processing narrative (PSPEC) for Component 3 ...................................... 10
       3.4.2      Component 3 interface description. .......................................................... 11
       3.4.3      Component 3 processing detail ................................................................. 11
    3.5      Software Interface Description ......................................................................... 11
       3.5.1      External machine interfaces ...................................................................... 12
       3.5.2      External system interfaces ........................................................................ 12
       3.5.3      Human interface ........................................................................................ 12
4      User interface design................................................................................................. 12
    4.1      Description of the user interface ....................................................................... 12
       4.1.1      Screen images ........................................................................................... 12
       4.1.2      Objects and actions ................................................................................... 12
    4.2      Interface design rules ........................................................................................ 12
    4.3      Components available ....................................................................................... 12
    4.4      UIDS description .............................................................................................. 13
5      Restrictions, limitations, and constraints .................................................................. 13
6      Testing Issues ............................................................................................................ 13
    6.1      Classes of tests .................................................................................................. 13
    6.2      Expected software response .............................................................................. 13
    6.3      Performance bounds.......................................................................................... 13
    6.4      Identification of critical components ................................................................ 13
Class: CS 495 Spring 2005                                                                             Author: Marc Van Gelder
Project: The Watson Game                                                                                       Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
7      Appendices ................................................................................................................ 14
    7.1    Requirements traceability matrix ...................................................................... 14
    7.2    Packaging and installation issues ...................................................................... 14
    7.3    Design metrics to be used ................................................................................. 14
    7.4    Supplementary information (as required) ......................................................... 14
    7.5    Mantis ............................................................................................................... 14
    7.6    Subversion......................................................................................................... 14




Class: CS 495 Spring 2005                                                                           Author: Marc Van Gelder
Project: The Watson Game                                                                                     Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
SOFTWARE DESIGN SPECIFICATION



1                 Introduction
      The Watson Game (WAG) is a three-dimensional interactive multiplayer
      online role-playing game currently based on Binghamton University’s
      Watson Building. New players start the game as a freshman and
      progress through each of the four years of college until graduation.
      Academic and life challenges measure each player’s progress through
      the game.


1.1                 Goals and objectives
       The objective of the game is to succeed in the progression from
       freshman to graduation in 4 years with the highest possible GPA.
       The player’s information is stored in a Microsoft Access Database.
       There will be a set number of academic challenges per school year
       to reach the next rank. Life challenges will occur at different
       locations and times throughout the game. The end of the game is
       accomplished when the player graduates.


1.2                Statement of scope
       The Watson Game consists of a server, client, web-client, and
       database. The server communicates with the database through the SQL
       language to obtain information requested by the client. The
       database contains all of the stored information needed throughout
       the game. This includes information such as faculty, elevator, and
       knapsack. The web-client allows a browser with a required plug-in
       to interface with the Watson Game, instead of using the client
       software. The client software is a three-dimensional interface for
       use by the users to interact within this game.


1.3                 Software context
       The original intent of this software was for use within Binghamton
       University’s Computer Science Program. It is a project that is
       continually worked on by sections of CS 495. This game is intended
       to be expanded, eventually cover the Watson Building, and then to
       the rest of the campus. In the end, it is to be used as a
       recruiting tool for Binghamton University.


1.4                Major constraints

Class: CS 495 Spring 2005                               Author: Marc Van Gelder
Project: The Watson Game                                         Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
       The only two major constraints are time and communication. Each
       semester there is only about four weeks to complete improvements to
       the Watson Game. Communication between individuals and groups is
       key. Busy schedules prevented everyone to really coordinate meeting
       times. Each group had a different idea on how the game should
       progress.



2                Data design
      The database is a Microsoft Access database. There are currently 15
      separate tables, which are challenge, character, coordinate, course,
      doors, elevator, faculty, hotspot, knapsack, lifechallenges,
      npcharacter, object, objectlist, prerequisite, and question. All of
      the data needed throughout the game are saved in these tables.


2.1                Internal software data structure
       The challenge table contains the questions and answers for each of
       the academic challenges. The character table consists of the user’s
       attributes, completed challenges, and other required information.
       The coordinate table holds the coordinates of items and hotspots.
       The knapsack table has the items that each user has in their
       knapsack. The object table contains the name, weight, and
       description of all the objects in the game. This table is linked to
       the objectlist table, which allows the user to obtain the item, and
       now allows how many.


2.2                Global data structure
       All of the tables are available to be used by the server and
       client.


2.3                Temporary data structure
       There are currently four tables that are not used yet in the game.
       These tables are course, npcharacter, prerequisite, and question.
       The course table contains the Computer Science courses needed to
       graduate. The npcharacter table has the location and attributes of
       non-player characters. The prerequisite table shows what courses
       must be done prior to taking the core courses listed in the course
       table. The question table has questions and answers posed to show
       the player around the game.


2.4                 Database description

Class: CS 495 Spring 2005                               Author: Marc Van Gelder
Project: The Watson Game                                         Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
      The database used is a Microsoft Access database. There are 15
      tables currently involved.

      challenge – Contains the questions and answers used in the various
      courses.

      character – This contains the player’s information. Some of these
      attributes will be eventually used to affect game play.

      coordinate – This table represents a three dimensional point in the
      game space.

      course – This contains the college courses that are required in
      order to advance in the game or to graduate, if they are already a
      senior.

      doors – This table represents the door at each office and whether
      they are open or closed.

      elevator – This new table represents the elevator, what floor it is
      on, and whether the doors are open or closed.

      faculty – This contains the members of the Binghamton University
      Watson building faculty. These members may pose challenges or
      provide hints.

      hotspot – Contains the points in the three dimensional space that
      signals the beginning of a challenge whenever the player walks into
      it.

      knapsack – This represents a bag that the player carries with them.
      Currently, there is no cap on the number of objects per knapsack.

      lifechallenges – This represents life challenges that players may
      face in the real world. There are a set number of experience points
      (XP) that the player can gain or lose depending on what they choose
      to do about the challenge.

      npcharacter – This contains the non-playing characters. NPCs may
      pose questions or comments to the player and generally hinder
      progress in the game.

      object – This represents an object in the game, such as a pencil,
      paper, or piece of paper.

      objectlist – This represents what object is in what knapsack and
      how many of the item there are.

      prerequisite – Contains the courses that are required to have been
      taken before the current wanted course.

      question - This represents a question posed to the player. This
      isn’t currently implemented.

Class: CS 495 Spring 2005                              Author: Marc Van Gelder
Project: The Watson Game                                        Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
3                 Architectural and component-level design
      The Watson game is built from three main components: the server
      program, the client program, and the database. There is an optional
      fourth component for playing the game from within a web browser.
      This is the web-client program.


3.1                Program Structure
       There are eleven relationships between the tables. Based on the
       requirements, they were either one-to-one or one-to-many. The
       relationships are shown here:

              course and prerequisite (one-to-many) – Linked by CourseID.
               This relationship shows which courses are prerequisites to
               the core CS curriculum classes. It is not being used in this
               implementation.
              course and faculty (one-to-many) – Linked by CourseID. It
               determines which faculty member teaches a specific CS course.
               Not used in implementation.
              course and challenge (one-to-many) - Linked by CourseID. This
               relationship determines which challenge questions belong to a
               CS course.
              challenge and faculty (one-to-many) – Linked by ChallengeID.
               This relationship shows which professor extends a specific
               challenge.
              hotspot and faculty (one-to-many) – Linked by HotSpotID.
               Determines the relationship between the professor’s office
               and the hotspot associated.
              hotspot and coordinate (one-to-many) – Linked by
               CenterCoordinateID. This shows at which coordinate a hotspot
               is located.
              hotspot and npcharacter (one-to-many) – Linked by HotSpotID.
               This relationship shows where a non-playing character is
               considered a hotspot in the game. It is not being used in
               this implementation.
              question and npcharacter (one-to-many) – Linked by
               QuestionID. This relationship shows which questions are being
               asked by a non-playing character.
              knapsack and character (one-to-many) – Linked by KnapsackID.
               This relationship identifies the knapsack associated with
               that character.
              knapsack and objectlist (one-to-one) – Linked by
               ObjectListID. This relationship is used to show which objects
               are currently in the knapsack.
              ObjectList and Object (One-to-Many) – Linked by ObjectID.
               This relationship links the characteristics of the objects to
               the object list.



Class: CS 495 Spring 2005                                 Author: Marc Van Gelder
Project: The Watson Game                                           Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
3.1.1                    Architecture diagram




3.1.2                    Alternatives
        There are no alternative architectural styles used for the
        database.


3.2                Description for Component 1: ‘elevator’ Table

3.2.1                  Processing narrative (PSPEC) for Component 1
              The elevator table contains three fields. The primary key
        is the ElevatorID field, which shows what elevator is being
        queried. This key is an automatically incremented positive
        number. The fields are shown as follows:

        ElevatorID – primary key, number, required (no duplicates)
        Location – text, 2 character limit, required
        StateOfDoors – text, 10 character limit, required




Class: CS 495 Spring 2005                               Author: Marc Van Gelder
Project: The Watson Game                                         Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
3.2.2                   Component 1 interface description.
                All interaction is done via the Structured Query Language
                (SQL)


3.2.3                Component 1 processing detail
                There is no algorithmic behavior with this table.


3.2.3.1         Interface description

                Not applicable.

3.2.3.2         Algorithmic model (e.g., PDL)

                Not applicable.

3.2.3.3         Restrictions/limitations

                See section 3.2.1 for the field restrictions.

3.2.3.4         Local data structures

                Not applicable.

3.2.3.5         Performance issues

                As the database size increases, the search time will increase, but this isn’t
                a problem that is anticipated anytime in the near future.

3.2.3.6         Design constraints

                The field restrictions are described in section 3.2.1.


3.3                Description for Component 2: ‘lifechallenges’ Table

3.3.1                  Processing narrative (PSPEC) for Component 2
                The lifechallenges table contains four fields. The primary
          key is the LifeChallengeID field, which shows what life challenge
          is being queried. This key is an automatically incremented
          positive number. The fields are shown as follows:


Class: CS 495 Spring 2005                                              Author: Marc Van Gelder
Project: The Watson Game                                                        Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
          LifeChallengeID – primary key, number, required (no duplicates)
          LifeChallengeName – text, 50 character limit, required
          Points – number, integer, required
          HotSpotID = number, integer, required (duplicates ok)

3.3.2                   Component 2 interface description.
                All interaction is done via the Structured Query Language
                (SQL)


3.3.3                Component 2 processing detail
                There is no algorithmic behavior with this table.


3.3.3.1         Interface description

                Not applicable.

3.3.3.2         Algorithmic model (e.g., PDL)

                Not applicable.

3.3.3.3         Restrictions/limitations

                See section 3.3.1 for the field restrictions.

3.3.3.4         Local data structures

                Not applicable.

3.3.3.5         Performance issues

                As the database size increases, the search time will increase, but this isn’t
                a problem that is anticipated anytime in the near future.

3.3.3.6         Design constraints

                The field restrictions are described in section 3.3.1.


3.4                Description for Component 3: ‘objectlist’ Table

3.4.1                  Processing narrative (PSPEC) for Component 3

Class: CS 495 Spring 2005                                              Author: Marc Van Gelder
Project: The Watson Game                                                        Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
                The objectlist table contains three fields. The primary key
          is the ObjectListID field. This key is an automatically
          incremented positive number. The fields are shown as follows:

          ObjectListID – primary key, number, required (no duplicates)
          ObjectID – number, integer, required
          NumberOf – number, long integer
          KnapsackID = number, integer, required (duplicates ok)

3.4.2                   Component 3 interface description.
                All interaction is done via the Structured Query Language
                (SQL)


3.4.3                Component 3 processing detail
                There is no algorithmic behavior with this table.


3.4.3.1         Interface description

                Not applicable.

3.4.3.2         Algorithmic model (e.g., PDL)

                Not applicable.

3.4.3.3         Restrictions/limitations

                See section 3.4.1 for the field restrictions.

3.4.3.4         Local data structures

                Not applicable.

3.4.3.5         Performance issues

                As the database size increases, the search time will increase, but this isn’t
                a problem that is anticipated anytime in the near future.

3.4.3.6         Design constraints

                The field restrictions are described in section 3.4.1.


3.5                      Software Interface Description
Class: CS 495 Spring 2005                                                Author: Marc Van Gelder
Project: The Watson Game                                                          Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
          The client and server software communications to the database
          using the Structured Query Language (SQL)


3.5.1                   External machine interfaces
                Not applicable.


3.5.2                   External system interfaces
                Not applicable.


3.5.3                   Human interface
                Not applicable.



4                User interface design
        There is no human interface for the database.


4.1                Description of the user interface
                Not applicable.


4.1.1                Screen images
                Not applicable.


4.1.2                Objects and actions
                Not applicable.


4.2                 Interface design rules
                Not applicable.


4.3                Components available
      Not applicable.
Class: CS 495 Spring 2005                                Author: Marc Van Gelder
Project: The Watson Game                                          Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
4.4                      UIDS description
       Not applicable.



5                Restrictions, limitations, and constraints
      The Watson Game currently relies on a Microsoft Access database for
      the disconnected mode. The database is to be ported to MySQL so that
      it isn’t tied to any one operating system. The client program,
      doesn’t have any such dependency, and should be usable on any
      operating system.

      This game is not meant to be a Massively Multiplayer Online Role-
      Playing Game (MMORPG) and has a limit on how many concurrent
      connections that can be made. The limit has not been tested or
      explicitly implemented.



6                Testing Issues
       Databases are not usually tested, since they only contain data.
       Often the queries used to request or modify data do have to be
       tested fully before being used in a finished product.

6.1                Classes of tests
       Each query is currently written using Microsoft Access using the
       Structured Query Language (SQL). The white-box testing method will
       be used to determine whether the expected result has occurred.
       Black-box testing is not necessary at this point.


6.2                Expected software response
       Each query is expected to return the requested rows, values, and
       formats specified.


6.3                Performance bounds
       Not applicable.


6.4                Identification of critical components

Class: CS 495 Spring 2005                                  Author: Marc Van Gelder
Project: The Watson Game                                            Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility
      The queries used for courses, challenges, and hotspots are the most
      important. The queries for the npcharacter, questions, and
      prerequisite are the least critical at this stage of game play.



7                Appendices

7.1                Requirements traceability matrix

      Request#           Request                                                    Section
      1.                 Needs an elevator table                                    3.2.1
      2.                 Needs life challenges table                                3.3.1
      3.                 Needs to keep the number of each object in each knapsack   3.4.1


7.2                Packaging and installation issues
      This software should at a minimum be portable so it can be run on
      any chosen operation systems. These include Windows, Linux, and
      Macintosh. The database, when totally ported, to MySQL, will then
      be able to be run on any operating system.


7.3                Design metrics to be used
      Not applicable.


7.4                 Supplementary information (as required)
      Not applicable.




7.5                Mantis

      This is the bug/issue tracker used. All three database components
      had an initial bug submitted to this system. Each issue was
      resolved and comments were added to Mantis.

7.6                Subversion

      All database updates were centrally located in the subversion
      repository. This was used as a replacement for the old concurrent
      versions system (CVS).

Class: CS 495 Spring 2005                                           Author: Marc Van Gelder
Project: The Watson Game                                                     Date: 5/8/2005
Function: Database
Subsystem: Overall Database Responsibility

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:6
posted:7/2/2010
language:English
pages:14
Description: Project The Watson Game brow liner