Virtual Game Project

illinoiseggoSoftware and s/w Development

Oct 28, 2013 (3 years and 5 months ago)

76 views

System Design| Software Trinity







Virtual Game Project






Cos 315
-
Sofware Engineering

Customer: John Galletly

1
1
/
15
/2010
















T
T
R
R
I
I
N
N
I
I
T
T
Y
Y


G
G
R
R
O
O
U
U
P
P



















































Xhesika Fezga











Plamen Dimitrov
























Radu Filip

System Design| Software Trinity





Table of Contents


1. Introduction

1.1 Purpose of the system…………………………………………………………....

3

1.2 Product Scope……………………………………………………………………..

3

1.3 Design
Goals……………………………………………………………………… 4

1.
4

References
…………………………………………………………………………

5



2. Proposed system architecture

2.1

Architectural Design……………………………………………………………
. 7

2.2 Decomposition Description
……………………………………………………

11

3. Hardware/software mapping
………
……………………………………………………

17

4. Access control and security
……………………………………………………………. 18

5. Boundary conditions
………………………………………………………………………

19

6. Global software control

………………………………………………………………….

21

7. Persistent Data Design (Data Repositories)…………………………
……………….
. 22


7.1 Database Descriptions…………………………………………………………. 22


7.2 File Descriptions……………………………………………………………….. 24

8. Subsystem Services
……………………………………………………………………… 25


























System Design| Software Trinity




1.

Introduction

In this part of the design our team decided to work with a reduced set of actors,
namely Operator, Player and Advertiser. We considered that these actors will provide
us with the opportunity to depict a representative range of functionalities offered by th
e
system. We also decided do work with a reduced set of core functionalities for each
actor in order to minimize the complexity of the system design presented in this part of
the documentation. The functionalities selected for each actor are presented belo
w.

1.1

Purpose of the system


The purpose of the current document is to specify an Object
-
Oriented Design for
the “Virtual Game”


software as its main
goal is to provide a generic infrastructure for
supporting several virtual game communities.

We decided to
choose three (Operator,
Player, Advertiser) out of five users that are supported by the system.
The System
Design of this software is an actual logical continuation of the Analysis Phase and what
is more important it gives a solid and clear framework on
how the gathered information
during requirements elicitation and the analytic work done throughout analysis would be
actually designed into different subsystem of the software. The basic issues to be
addressed by the Object
-
Oriented Design are: the system

architectural design,
description of each subsystem, specification of system components (detailed
description of class methods and attributes), and description of the system database.

In the following pages we will define and describe how the new system w
ill
function and how to work out the problem stated in the “Requirements & Analysis”
document.


1.2

Product Scope

This project is a new framework that supports a virtual communication system. The
main purpose of the “Virtual Game” software as specified in th
e Requirements
Specification phase is to create a generic infrastructure that will support different virtual
game communities.
Some

of

the major goals this new system must achieve are:
Provide an infrastructure for operating multi
-
player, multi
-
spectator g
ames; Provide a
System Design| Software Trinity



framework for league owners to customize the number and sequence of matches and
the accumulation of expert rating points; Provide a framework for game developers as
well as for advertisers and a lot of other objectives regarding the usabili
ty, reliability,
maintenance etc of the software.


With reference to the benefits of the system, the objective the client wants to achieve in
acquiring the new system is to reduce the disadvantages evoked from different game
companies supporting different
infrastructures, concepts and game levels.


1.3

Design Goals

Based on the non
-
functional requirement identified in the Software Requirements
Specification document, the system developers will pursue the following design goals:


1.3.1 Usability

▪ Simple to
install and administer so that an operator that is not an expert in system
management can do it.


▪ Must provide all types of users with information that might be of their interest


new
games and tournaments for players, games and tournaments in progre
ss, individual
game and player history for players and spectators, balance and advertisements
statistics for advertisers, etc.


1.3.2.
Reliability



▪ Although the system is not responsible for games’ internal structure, they must be
loaded successfully a
nd in acceptable time interval of up to 10 seconds. In case of
unsuccessful game loading players and spectators must be notified.


▪ Server must be available 24 hours a day.


1
.3.3.

Performance



▪ Must support up to 10 games in parallel performance.



Game capacity is 64 players and 300 simultaneous spectators.


▪ Games must be played successfully via a slow
-
speed (dial
-
up) Internet connection.

System Design| Software Trinity




1
.3.4.
Supportability



▪ The system must prevent more than 64 players in a game as well as more than 300
s
imultaneous spectator connections to it.


▪ The history of each game and player has duration of one year as all information that
originates from earlier is to be erased.


▪ Different tournament types


knock
-
outs, championships and best of series.


▪ Virtual Game will be offered only in English speaking markets. The system will
therefore support English encoding (windows
-
1251).


1
.3.5.

Implementation


▪ Virtual Game must be implemented in Java using the JavaServer Pages (JSP)
technology for devel
oping web applications.


▪ Games must be implemented as Java applets.


▪ System must support JavaScript


1
.3.7.
Packaging


▪ Must run on UNIX operating system.


▪ Must be accessed through web browser with Java support on the user side and only
offline
(through a local network) on the administrator side.




1.4

References

The Software Design Specification for “Virtual Game” builds upon the models developed
in the Software Requirements Specification. Therefore, the documentation from the
latter is extensively used.

In the development of this document, we have also considere
d the Carnegie Mellon
University description of Object
-
Oriented Design and Bruegge and Dutoit’s book
“Object
-
Oriented Software Engineering”.
Additionally the book “Object
-
Oriented
System Design| Software Trinity



Systems Analysis and Design” (Bennett, MCRobb and Farmer) and Prof. John Gal
letly’s
PowerPoint slides were very helpful while designing the architecture.



Below is a list of references used for the development of the current document:

1. Mike Bray, “Object Oriented Design.” Carnegie Mellon University. October 27
th

1997.
http://www.sei.cmu.edu/str/descriptions/oodesign.html

2. Bruegge, Bernd. Dutoit, Allen H “Object
-
Oriented Software Engineering”, Prentice
Hall 2004

System Design| Software Trinity




2. Proposed system architecture


2.1
Architectural Design


As we already know the concepts of coherence and coupling help the designer to
develop components with better functional independence. To facilitate a good design,
with reference to an increase in robustness, reliability and reusabili
ty, our goal is to
minimize coupling and maximize cohesion
on each subsystem.

In order to achieve this objective the decomposition of the “Virtual Game” system will be
based in three main layers.


The architecture of “Virtual Game” is divided horizontally

into a three layers:


1.

Presentation layer:

describes the interface of the system with its users. It
incorporates boundary classes.


2.

Business Logic layer:

represents the functionality of the software and includes
control classes.


3.

Database layer:

describes the system data repository. It consists of entity
classes realized into a database, which keeps information for each important
entity in the system.


It consists of a closed architecture, where messages may only be sent to the adjacent
lower lay
er.


The Presentation layer is further partitioned into three subsystems:



1.

Operator interface


Represents the pages, which are displayed during all the processes taken care
by the operator. The Operator Interface handles the interface for the operator’s
main page, management of the users
/games

etc.

System Design| Software Trinity





2.

Player Interface


Represents the pages, which are displayed to the player during every action he/she
decides to undertake. It takes care of the interface for playing a new game, viewing
different games, check
ing his/her messages etc


3.

Advertiser Interface

Represents the pages, which are displayed during all the processes
undertaken

by
the advertiser. It takes care of the interface for uploading/canceling advertisements,
selecting a proper advertising scheme etc



The Business Logic layer is partitioned into five subsystems:



1.

User Management Subsystem


Allows the system operator to add/remove
/edit

different users from the system.


2.

Games Management Subsystem


Allows the system operator to add/remove/edit
different games that are part of
the system.


3.

Notification Subsystem


Sends e
-
mails to winners and or notifies different users about all the changes
done in the system
.



System Design| Software Trinity




4.

Advertising Subsystem


Allows the advertiser to add/remove/edit different
advertisement from the
system.


5.

Navigation Subsystem


Allows the system users to browse and navigate the system according to their
purposes.




The Database layer is partitioned into two subsystems:


1.

The User


table


2.

The Games
table


3.

The Advertisement
table


The organization of the subsystems is intended to go well with the client
-
server model.


System Design| Software Trinity




Fig 2.1.1 The three layered diagram of the system architecture



The Presentation layer.

The Presentation Layer is the highest layer in the system
decomposition. It consists of
the Operator Interface, the Player Interface and the Advertiser Interface. Each of these
subsystems includes the necessary forms and screens as described below.

The
Operator
I
nterface

consists of all the screens that provide t
he Operator with
the access to the necessary functionalities after they are logged in. These functionalities
are:

System Design| Software Trinity



-

Browsing contained in the User Table and viewing the profiles of the users
registered in the system;

-

Adding, editing, suspending and deleting
user profiles;

-

Browsing the data contained in the Games Table and viewing the information
about the games currently installed in the system;

-

Adding, editing and deleting games from the system;

-

Sending and receiving various notifications through the Notific
ations
Subsystem


The
Player
I
nterface

consists of all the screens that provide the Player with the
access to the necessary functionalities after they are logged in. These functionalities
are:

-

Browsing the games available in the system using a number of fi
lters and
sorting options;

-

Playing any of the games installed in the system;

-

Sending and receiving various notifications through the Notifications
Subsystem;


The
Advertiser

I
nterface

consists of all the screens that provide the
Advertiser

with the access to the necessary functionalities after they are logged in. These
functionalities are:

-

Browsing the advertisements stored in the Advertisements Table that are
owned by the user.

-

Adding, Editing or Deleting any of the Advertisements owned by

the current
user


The Business Logic layer.


System Design| Software Trinity



The business layer is the middle layer that facilitates the interaction between the
presentation layer and the database layer. It consists of the following subsystems:

User
Management, Games Management,
Notification, Advertising, Navigation.


The

Notification
subsystem can be accessed by all the users through the Operator
Interface, Player Interface and Advertiser Interface respectively. The users will be
provided with notifications about any changes in t
he system or events taking place.


The

User Management
subsystem can be accessed only by the Operator from the
Operator Interface. The Operator will be able to

add new

users

to the system, edit the
profile information, suspend or delete a user account. Th
is subsystem will connect with
the User Database and the Notification Subsystem that will provide the user with the
notification of any changes made.




System Design| Software Trinity




The

Games Management
subsystem can be accessed only by the Operator from the
Operator Interface. The

Operator will be able

to add/remove/edit different games that
are part of the system. This subsystem will connect with the Games Database and the
Notification Subsystem that will provide the user with the notification of any changes
made.






The
Advertising
subsystem can be accessed by
Advertiser from the Advertiser
interface. The A
dvertiser

will be able

to add/remove/edit different advertisement from
the system.

This subsystem will connect with the Advertisement Database and the
System Design| Software Trinity



Notification subs
ystem that will provide the user with the notification of any changes
made.






The
Navigation
subsystem can be accessed by all users through their respective
Interface subsystem. The users will be able to browse and search for specific data in a
databas
e. They will also have a few options for filtering and sorting the data extracted
from the database. The player will be able to view games in a specific category or sort
them alphabetically by name. There will be restrictions in place to prevent the
unaut
horized access of some parts of the databases. The This subsystem will be
connected to the User Database, Games Database and Advertisement Database.


System Design| Software Trinity





System Design| Software Trinity




3.
Hardware Mapping

Since Java Server Pages is the technology used for the development of the
system, the
last is highly portable and only requires Apache Tomcat server on its platform. The
system also has to offer full support for the basic browsers on the internet: Mozilla
Firefox, Internet Explorer, Apple Safari as well as Google Chrome and Oper
a. The
database for the system should be highly reliable and well optimized since it will be
frequently accessed during system’s functioning.

The system provides offline access only to the operator with a special interface to
control the users as well as g
ames parts of the database and additional functionality for
full control. The system also supports low connection (dial
-
up) speed by restricting
some of its heavier functionalities. At a later stage the system can also be expanded
across multiple servers.



Fig. 3.1 The

diagram
representing the decomposition diagram



System Design| Software Trinity



4. Access control and security


The system will include three levels of access: Players, Advertisers and Operators. As
there exist a set of rights, which specify the kind of access a subject is allowed to
process with regard to an object,
Players

and
Advertisers will

have limited privile
ges,
while the
Operator

will be a more privileged user. His main possible operations include
adding, deleting and changing/editing games and users from the system. While in terms
of the advertisement their only act is to
create new accounts, approve the ap
plications
for any kind of advertiser account or delete any of the existing accounts.

The
Player
will have
fewer privileges than the operator; he will be able to only
browse/search the database of games, or even play different games and announce
matches bu
t not change or define new games available in the system. Meanwhile the
Advertiser

is able to Upload new advertisements, Select an advertisement scheme
(e.g., tournament sponsor, league sponsor), Check balance due, and Cancel
advertisements in the Advertis
ement database.

In order to avoid misuse of the software by customers or outsiders, a proper
authentication mechanism is required.
Authentication

is the process of establishing
whether a client is who or what it claims to be in a particular context.

In our

case
t
he
authentication system will be implemented through username and password that are
stored in the database. No additional encryption will be implemented in this stage, but it
can be easily added in further maintenance. This method represents the tec
hnique the
software uses against unauthorized access.



Operator

Player

Advertiser

User Database

Read, write, execute, own

Read

Read

Games Database

Read, write, execute, own

Read

Read

Advertisement Database

Read

Read

Read, write, execute, own


System Design| Software Trinity



5.
Boundary conditions

The Boundary conditions refer to the

initialization and termination of the system as well
as to the possible failures or errors that the system may encounter.

All users will be able
to access any game with a web browser supporting cookies, Java
-
script, and Java
applets and the
Virtual Game

software will run on any UNIX operating system (e.g.
MacOS X, Linux, and Solaris).

As for the availability of the system it
will be accessible
24 hours a day.

The application
server is never shut down except if failure happens or its services are no longer needed.


System Start
-
up.


Because the system will be active all the time, it starts up when different users connect
to the

server by navigating to the starting web page, and terminates it by logging off. As
for the operator, his administrative functions
will not be available through the web
, as a
result is not necessary for him to access the web page in case he wants to under
take
any actions.


System Shutdown

The system might shut down in cases of maintenance, break
-
downs or due to a power
shortage. From the user’s viewpoint, the system shuts down when the web interface is
closed.

Error Handling.

All exceptions are

handled by
the system. In the case of
any unforeseen failure
s,

the
common errors that might occur during the use of the software are:



A network failure might occur and the system will display a warning
message informing the user of the error.



A server failure. In th
is case, the back
-
up system server will start
operating.

System Design| Software Trinity





The client machine does not have the Java Runtime Environment installed
the appropriate message will be displayed with a link and instructions for
downloading and installing the latest JRE.



The clien
t’s browser does not support JavaScript or has JavaScript
disabled. In this case a message will be displayed with instructions how to
turn JavaScript on or where to download a browser that supports JavaScript









Fig. XX

Use case regarding the Initialization, Termination and Error handling for the Server side


System Design| Software Trinity
















6.

Global Software Control

Fig. XX

Use case regarding the Initialization, Termination and Error handling for the Client side


System Design| Software Trinity



Due to its nature Virtual Game software will be considered as an event driven system.
When users are presented with a main page they will have the option of choosing on a
number of activities (add/delete game, play game, add/cancel advertisement etc).
When
ever the user chooses a specific activity, it is dispatched to the appropriate object
for processing and a function in the corresponding subsystem will be invoked. Functions
in a subsystem may call other functions within that same subsystem or they may
com
municate with other
sub
systems using the interface provided.



7.

Persistent Data Design (Data Repositories)



7.1 Database Descriptions


Optimization requires the system to have one compact relational database that contains
all necessary information for its
correct functioning. The main entities and their
respective relations are shown in the ER diagram below. The database is used through
communication with its individual server. Another useful technology to be used here is
Java Beans which provides the devel
opment process with direct object oriented
transition from the database entities to entity objects which can significantly facilitate the
data processing.

The database is convenient for keeping track of large amount of objects and their
states. The functio
nalities provided to the player work mostly with the Games and
Tournaments tables while the ones provided to the operator


with the Users and
Games tables. The advertiser user type modifies the entries in the Advertisements table
to which they have access

while the league owner works mainly with the Tournaments
table. In a more detailed view disjoint tables can be used for further classification of the
user table and further clarification of its relation to the other entities.


System Design| Software Trinity
















System Design| Software Trinity





Fig. 7.1
General ER diagram










System Design| Software Trinity



7.2.

File Descriptions


The software will include the following files:




7.2.1 ReadMe File

The
ReadMe

file will contain instructions on how to use the software. These instructions
will help the
operator

or
different
users get started with the software and will provide
details about the functionalities and requirements of system. Furthermore, the
ReadMe

file will include the version of the software and the company that developed it.


7.2.2

Help File

The
Help

file will include a frequent Q&A section where the user will find the answers to
some of the most common questions s
he
/he might have about the software.
Furthermore, information regarding parts and functionalities of the software will be
present. This fil
e will help the user with the common difficulties that might emerge during
the use of this new software.


8.

Subsystem Services

Subsystem services describe the services provided by each subsystem in terms of
operations provided for other subsystems
.

Below

is a representation of the services
provided by the subsystems:


Player Interface

1.

Log In

2.

Browse Database

3.

Register for a game

4.

Participate in a game

5.

Cancel participation

6.

View history and statistics

7.

Communicate with other users

8.

Log Out

System Design| Software Trinity



Operator Interface

1.

Log In

2.

Browse Database

3.

Add

Game

4.

Delete Game

5.

Edit Game

6.

Define new tournament styles

7.

Manage players

8.

Define new expert rating formulae

9.

Register new league owners and
advertisers

10.

Log out

Advertiser Interface

1.

Log In

2.

Browse Database

3.

Choose a scheme

4.

Add a new
advertisement

5.

Edit an existing advertisement

6.

Delete an advertisement

7.

View balance

8.

View info about advertisement

9.

Log Out

User
Table

1.

Store user Data

2.

Modify user Data

3.

Show user Data

Game
Table

1.

Store Games Data

2.

Modify Games Data

3.

Show Games Data


Advertiser Table


1.


Store
Advertisement

Data

2.

Modify
Advertisement

Data

3.

Show
Advertisement

Data