Anteprima
Vedrai una selezione di 7 pagine su 30
Software Design - final project Pag. 1 Software Design - final project Pag. 2
Anteprima di 7 pagg. su 30.
Scarica il documento per vederlo tutto.
Software Design - final project Pag. 6
Anteprima di 7 pagg. su 30.
Scarica il documento per vederlo tutto.
Software Design - final project Pag. 11
Anteprima di 7 pagg. su 30.
Scarica il documento per vederlo tutto.
Software Design - final project Pag. 16
Anteprima di 7 pagg. su 30.
Scarica il documento per vederlo tutto.
Software Design - final project Pag. 21
Anteprima di 7 pagg. su 30.
Scarica il documento per vederlo tutto.
Software Design - final project Pag. 26
1 su 30
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Software Design – Group 3

Haitham Habli

Hamalainen, Olli 08.12.13

Instructor, TI00AA56-3001

6

1 Introduction

The “Car Race Game Manager” organizes car race games and finally calculate player’s

scores. It also sets up the game, prepare the players, allocate them into ongoing com-

petition and distribute them among the tracks. The game can be played virtually or

online.

1.1 Purpose

The purpose of this game is set up a platform/pool for participants to join a car race

competition, populate the business and make a profit out of it. In this document, we are

going to write down the specifications regarding the “Car Race Game Manager” software.

The document will help the software team implementing this game to understand the

general view of it and the details of the specifications.

1.2 Scope

The main scopes of this product are the following:

1. Identify the software product to be produced by name : “Car Race Game Man-

ager”;

2. The software product will sign up/register a participant, give him access to the

game, configure the settings he/she desires and then manage his/her enrollment

to the competition;

3. This product can be used as a template for virtual car race games to enroll par-

ticipants online. Besides, providing ready platform to manage car race games.

In addition, the product could be an open source that helps software designers

communities.

1.3 Definitions, Acronyms, and Abbreviations

In this subsection there are the definitions of all terms, acronyms, and abbreviations

required to properly interpret the SRS. 7

Abbreviation Definition

CRGM Car Race Game Manager

DLC Downloadable Content

Table 1.1: Abbreviations

Term Definition

Player Who wants to join the game

Sign Up Enter your personal data in a form to be stored into a database

Sign In Process that allow the user to join the game (after he/she has entered Id and password)

Table 1.2: Terms

1.4 References

In this section you can find a complete list of all referenced elsewhere in the SRS and

there is the sources from which the references can be obtained.

Here some references:

Qt - http://qt.digia.com

1.5 Overview

In the second part of the document, there will be a general description of “Car Race Game

Manager” (in the first part it is said something general about the product), while in the

third part we provided more detailed description and illustrate the specific requirements.

In the last part, we are going to list all analysis models used in developing specific

requirements previously given in this SRS. Each model should include an introduction

and a narrative description (called “scenario”).

8

2 General Description

The CRGM allows players to take part in a competition virtually or online. In the

second case the user need to provide his/her personal information to be registered in

the system and get access to the game. After that he/she will be able to configure the

settings and join the competition where he/she can decide to have a free practice, go

directly to a real race or participate in both of them. Finally a ranking will be shown to

the players and he/she can choose to join a new competition or sign out from the game.

2.1 Product Function

The software will perform the following functions:

1. Register a user into the system;

2. Allow the user to have access the game system (by using identification Id and

password);

3. Permit the user to configure settings before the race;

4. Enroll the user in a competition;

5. Choose “free practice race”, “real race” or both of them;

6. Show scores;

7. Re-join the game;

8. Exit (leave the game)

2.2 User Characteristics

The general characteristics of the users are the following:

1. Score of the player

2. Car of the player

3. Track of the player

4. Competition Type

5. Weather 9

2.3 General Constraints

The general constraints that could limit the developer’s options for designing the system

are:

1. Maximum number of players that can join the competition

2. Minimum number of players that can join the competition

10

3 Specific Requirements

This section will give the D-requirements that are used to guide the project’s software

design, implementation, and testing.

3.1 External Interface Requirements

3.1.1 User Interfaces

The application shall be compatible to any operating systems (such as : Windows,

Linux, Unix, ect. . . ). The commands are entered using a shell script as token of strings

and calls appropriate relevant functions. Several stations running any operating systems

connected through a communication link provide a platform for playing such kind of

game (i.e. CRGM). Since the game can be played virtually and online the commands

can be connected to web links that by clicking one of them allows you to choose your

command or relevant functions.

3.1.2 Hardware Interfaces

Since the application can run over the internet, all the hardware shall require to connect

internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,

Ethernet Cross-Cable. The game can be playable also using a joy-stick instead of the

computer keyboard.

3.1.3 Software Interfaces

There is a configurable file that contains a list of the tracks available. The controller

manages a database where is stored information regarding every competition; its player’s

information and the tracks are used. The game will be coded using C++ language and

using the “Qt” software tools, thus it facilitates having the game running on Linux and

Windows platforms.

3.1.4 Communications Interfaces

The CRGM system shall use the HTTP protocol for communication over the internet

and for the intranet communication will be through TCP/IP protocol suite. It shall use

also HTTPS protocol (which is more secure than HTTP but slower) for the sign up and

for the log in the system. 11

3.2 Functional Requirements

This section describes specific features of the software project.

3.2.1 Introduction

This subsection contains the requirements for the CRGM. These requirements are orga-

nized by the features discussed in the vision document. Features from vision documents

are then refined into use case diagrams and to sequence diagram to best capture the

functional requirements of the system.

3.2.2 Membership Functional Requirements

1. For every new member(player), the system must get the following information:

first name, last name, proficiency level, date of birth, username, password, email

address.

2. The system must check for the availability of the username.

3. The system must allocate a unique member ID for each member.

4. The system must validate and record the information received from the user.

3.2.3 Registration Functional Requirements

1. The system must get the following information from players who wish to enroll for

a competition: the member ID of the participants, the event they would like to

participate.

2. The system must give a unique player’s nickname for the registered participants(if

the participants didn’t choose their game names).

3. The system must validate and record the information received from the user.

4. The system must allow the registered participants to withdraw from the competi-

tion.

3.2.4 Score Calculation Functional Requirements

1. The system must display the score of the players(time, place, etc. . . ).

2. The system must calculate the scores for all players that were registered in that

competiotion.

3. For the final round, the system must calculate the players ranking, and display the

winner. 12

3.3 Use Cases

The use case diagram of the CRGM is shown in 3.1

Figure 3.1: Use Cases Diagram

3.3.1 Sign Up

Player signs up to register for new username and password.

3.3.2 Sign In

Player logs in using his/her username and password.

13

3.3.3 Configure Settings

Player gets to set up new settings or change setting he/she desires.

3.3.4 Choose Car

Player chooses the Car and can upgrade its features: car shape, car color, drive wheels

type, tire type, in according to the race he plan to join, car shape, car color, drive wheels

type, tire type.

3.3.5 Choose OutFit

Player chooses his/her outfit in the game.

3.3.6 Partecipate In Competition

Player participates in competition which can be either free practice or campaign race.

3.3.7 Choose Track

Player chooses the track that defines the game difficulty level, where the race will take

place.

3.3.8 Play Free Practice Race

Player participates in a free practice race.

3.3.9 Play Compaign Race

Player participates in a campaign race.

3.3.10 View Score

The race finishes and player gets to see his/her score and time spent in race.

3.3.11 View Ranking Statistics

Player view his/her scores and time compared to other players scores and ranked in

players score list. 14

3.4 Class / Objects

In 3.2 is showed the class diagram regarding CRGM:

Figure 3.2: Class Diagram

15

3.4.1 Class Car

Each car class has following getters and setters functions and the attributes stated below:

3.4.1.1 Attributes

The attributes of this class are:

• String Colour;

• String Shape;

• Int Steerings, range varies between 10 -100;

• Int Dwheels, could be back-wheel or 4-wheel;

• String Tyretypes: it is either normal, rain or studded.

3.4.1.2 Functions

The functions are the following:

• String getColour();

• String getShape();

• Int getSteerings();

• Int getDwheels();

• String getTyretypes();

• Void setColour();

• Void setShape();

• Void setSteerings();

• Void setDwheels();

• Void setTyretypes().

3.4.2 Class Player

Player class is responsible for the details of each player joining the competition. Each

player object consists of: a unique name, score, car1 and car2 (of data type car class).

Player also has tuneCar()function which sets the steering, drive wheel type and tyre

type for particular car of the player. 16

3.4.2.1 Attributes

• String name;

• Int score;

• Car* car1, e.g. used for free practice race;

• Car* car2, e.g. used for campaign race.

3.4.2.2 Functions

The functions are the following:

• void tuneCar(car* car, int steer, int d_wh, string tytp);

• void printCarSettings();

• void print_competitions();

• void print_score();

• void set_steerings( int st, string car_no);

• void set_dwheels( int dwh, string car_no );

• void set_tyretypes(string tt, string car_no );

• String set_player_name();

• String getName();

• String signUp();

• String signIn();

• int get_steering_car( car* c);

• int get_Dwheels( car* c);

• string get_tyretypes( car* c);

• string get_player_name();

Dettagli
Publisher
A.A. 2013-2014
30 pagine
SSD Ingegneria industriale e dell'informazione ING-INF/05 Sistemi di elaborazione delle informazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher tito1992 di informazioni apprese con la frequenza delle lezioni di Software Engineering e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Camerino o del prof Culmone Rosario.