“Multiplayer Gaming Simplified”

1
Swirl
“Multiplayer Gaming Simplified”
CS4512 – Systems Analysis and Design
Assignment 1 –2010
Marque Browne – 0814547
Manuel Honegger - 0837997
Kieran O' Brien – 0866946
2
BLANK MARKING SCHEME
3
TABLE OF CONTENTS
Blank Marking Scheme.....................................................................................................................................2
Narrative Description.......................................................................................................................................5
Software Lifecycle Model.................................................................................................................................6
Risk Management Strategy………………………………………………………………………………………………………………8
Project Plan and Allocation of Roles.................................................................................................................9
System Architecture........................................................................................................................................10
Three-Tier Architecture.......................................................................................................................12
Discussion of the UML Workbench Used............................................................................................14
Requirements..................................................................................................................................................15
Functional............................................................................................................................................15
Non Functional....................................................................................................................................25
Use Case Diagrams..............................................................................................................................26
GUI Prototypes....................................................................................................................................30
Analysis...........................................................................................................................................................37
Candidate Objects...............................................................................................................................37
Class Diagram......................................................................................................................................38
Sequence Diagram..............................................................................................................................40
Communication Diagram....................................................................................................................41
State Chart..........................................................................................................................................42
Entity Relationship Diagram................................................................................................................43
Design..............................................................................................................................................................44
Architectural Style...............................................................................................................................44
State Pattern.......................................................................................................................................44
Adapter Pattern...................................................................................................................................45
Model-View-Controller Pattern………………………………………………………………………………………………………45
Client Package………………………………………………………………………………………………………………………..………46
Database Package………………………………………………………………………………………………………………..…………47
4
Game Package………………………………………………………………………………………………………………………………..48
Match Package....................................................................................................................................49
Network
Package.................................................................................................................................50
Server Package....................................................................................................................................51
UI Package...........................................................................................................................................52
Data
Dictionary................................................................................................................................................53
References.......................................................................................................................................................5
6
5
NARRATIVE DESCRIPTION
"Swirl" is a new company that has created a multiplayer game server browser system. What they have
achieved is a system that supplies a multi-platform client with the ability for users to initiate, search, create
and join game servers.
The client must have an internet connection, be able to access the network and successfully maintain the
connection before accessing the database and allowing the user access to the main interface.
Upon successful connection to the system, the client begins to search the user’s computer for known and
supported games that are listed on the systems database. Supported games that are found are listed in the
interface every time the client is initiated. If the client does not find any supported games, the client closes.
When the main interface is presented the user is be supplied with the list of supported games. They may
choose to create and host their own server or simply search a list of available servers. When choosing to
create their own server they are presented with a choice of game types and maps for the game they
selected. When then server is launched it is listed on the systems database until the client closes the
server.
If the player decides to join a game, a list of available servers is presented to them which are listed from
the database. Options for filtering servers by game play type and the ability to refresh the server lists is also
available to the user.
When the user selects a server, the list of maps on the server is retrieved, if only one map is available only
that map is displayed. The user can then join the server.
The ability to revert to any previous step is available to the client at all times.
Validation System consists of two queries. Firstly, the client checks the user’s computer for an active
internet connection. If a connection is found the user can connect to the network, otherwise the client
terminates. Secondly, the client checks the user’s computer for games. These games are cross examined
with the list of supported games on the systems database. If one or more supported games are found they
are listed in the client. If no supported games are found the client closes.
Game Selection/Setup System handles the user’s choice of game and server. From the list of games in the
clients interface the user chooses a game they wish to play. The client then lists all available servers for
that game from the system database. The user can also refresh the list at anytime. Once a server is picked
the client lists the map rotation on that server and the game will launch.
Server Configuration System handles the user’s creation/ configuration of a server. From the create server
interface the user has the option to set the number of maximum players, game type and map list. The user
may also enter in a server password if needed. The user is also given the option to enable cheats on their
server. Once configuration is complete the user may host their game.
6
SOFTWARE LIFECYCLE MODEL
For this project we have chosen the most well known software lifecycle development model – the
Waterfall Lifecycle Model. It is often considered the classic approach to the systems development life cycle
as it describes a development method that is linear and sequential. Waterfall development has certain
goals that need to be met for each phase of development. Once a phase has been completed, the
development proceeds to the next step. These phases generally are System Engineering, Requirements
Analysis, Design, Implementation, Testing, Installation and Maintenance.
1. System Engineering
The first phase, this involves identifying the major requirements for the software system and then
identifying the parts of the system which are most important and best implemented in the software. This
creates a high-level architectural specification that defines how these major parts of the system will
interact with each other.
2. Requirements Analysis
This phase deals with more intense gathering of systems requirements and involves making sure that these
requirements are clearly defined. If the system contains large elements, that require implementation into
the software, then these will be the main focus of this phase. The main goal here, being the identification
of what the user requirements are, from the system. Identifying the requirements for very large and
complex systems, benefit from fact-finding techniques such as background reading, interviews,
observation, document sampling and questionnaires. User requirements will be of benefit in the later
stages of the lifecycle in regards to developing the criteria for user acceptance testing.
3. Design
This phase consists of looking at the chosen requirements for the system, and determining how best to
create a system that delivers these requirements. At first, design is concerned with the specification of the
software architecture that defines the structure and relationship of the various components of the system.
This involves reaching a balance between requirements that could conflict with each other (e.g
performance, portability etc) within the constraints of the implementation environment.
4. Implementation
Implementation deals with taking the completed design of the system and translating it into a
programming language code. Depending on how the design was completed, part of the implementation
may be automated. Construction may also cover various different programming languages as well as
different database management systems for different parts of the system.
5. Testing
7
During this phase the system is tested to ensure that it conforms to the user requirements. Typically,
several levels of testing are performed such as unit testing (individual components), integration testing
(components together as subsystem), system testing (all subsystems together) and acceptance testing (by
the users).
6. Installation
Once this stage has been reached, the system has been tested satisfactorily and is delivered and installed
to the users. The introduction of the system has been managed carefully to minimize disruption. To ensure
this, both old and new systems may be run side by side to ensure that the new system works and performs
correctly before the old system is phased out. Even though this idea is an expensive test, a contingency
plan should be in place to cover the level of risk.
7. Maintenance
As is with most software, no single program will be perfect. Most programs will be subject to change during
its life. The developed system may operate incorrectly and it may need to be updated to fix these issues
(corrective maintenance). Certain aspects of the systems features may not have been fully implemented
due to time or cost constraints but are then completed during the maintenance phase (perfective
maintenance). The operating environment may also change and need support (adaptive maintenance).
Advantages of the Waterfall Model:
•
•
•
•
•
Ease of explanation – Documentation at every phase
Linear Model – Ease of implementation
Phases and progression are well defined
Effectively helps in planning and scheduling of the project
Verification at each stage ensures early problem/error detection
Disadvantages/Criticisms of the Waterfall Model:
•
•
•
•
Once a phase is complete you cannot go back. If design phase goes wrong, things can get very
complicated and messy in the implementation phase.
If the client is not clear about what he exactly wants, any changes that he mentions in between may
cause a lot of problems.
Working model of the software is not available to the client until the final phase is complete.
Adjusting scope during the life cycle can kill a project
High amounts of risk and uncertainty.
•
Poor model for complex and long projects.
•
Poor model where requirements are at a moderate to high risk of changing
•
RISK MANAGEMENT STRATEGY
8
There are many risks involved with software development especially if things go wrong in the early analysis
phase which then mushroom into the design phase. It is therefore necessary to have a risk management
strategy to avoid or minimize these risks from occurring.
It is often the case that poorly defined requirements, unrealistic schedules/budgets, incorrect development
of the UI and a continuing stream of changing requirements that most often bring a software development
project to its knees.
To effectively control these risks, it’s best to break up the management strategy into two main activities:
Risk Assessment
•
•
•
Creating a list of all potential risks that could affect the project
Assessing the probability of occurrence and the potential issues caused by each risk
Ranking the risks in order of highest to lowest risk
Risk Control
•
•
•
Brainstorming techniques and strategies to control the most likely risks
Implementing the strategies to mitigate the highest risks
Monitoring the effectiveness of the strategies and the changing levels of risk throughout the project
PROJECT PLAN AND ALLOCATION OF ROLES
9
Week
7, 13
7
7
7
8
8
8
8
8
9
9
9
10
10
10
11
11
12
12
12
7
13
Description
Document Design/Creation
Narrative Description
Software Lifecycle
Risk Management Strategy
System Architecture Diagram
Requirements
Use Case Descriptions
Non-Functional Requirements
GUI Prototypes
Use Case Diagrams
Analysis
List Candidate Objects
Communication Diagram
Sequence Diagram
State Chart
Entity Relationship Diagram
Class Diagram
Design
Architectural Style
State Design
Adapter Pattern
Model-View-Controller Pattern
Data Dictionary
Extras
Project Plan / Roles
References
Allocation
Manuel Honegger
Manuel Honegger, Kieran O' Brien
Manuel Honegger
Manuel Honegger
Marque Browne, Manuel Honegger
Kieran O' Brien
Kieran O' Brien
Manuel Honegger
Marque Browne, Manuel Honegger, Kieran O' Brien
Manuel Honegger
Marque Browne
Marque Browne
Marque Browne
Marque Browne
Marque Browne
Marque Browne, Manuel Honegger, Kieran O' Brien
Marque Browne, Manuel Honegger, Kieran O' Brien
Marque Browne, Manuel Honegger, Kieran O' Brien
Marque Browne, Manuel Honegger, Kieran O' Brien
Kieran O' Brien
Manuel Honegger
Marque Browne, Manuel Honegger, Kieran O' Brien
SYSTEM ARCHITECTURE
10
There are many integrated parts which make up the Swirl system. Each part has its own functionality and
so the decision was made to separate these parts of the system into their own distinct packages. In order
to group these parts, it was essential to look at the different responsibilities of each integrated part. The
packages were hence grouped as follows:
•
Database Package
This package handles all database operations that will be used when communicating with the
company’s database.
•
Network Package
This package handles the operations for testing that we have communication with the company’s
database. It opens connections to servers and downloads information about current matches. Also
feeds back the latency of the server.
•
Game Package
This package handles the information of the games and the system. Also includes a list of servers
that the game will be able to connect to, as well as containing information pertinent to launching
dedicated servers.
•
Server Package
This package holds information about servers for specific games. Includes information required for
configuring and launching dedicated servers.
•
Match Package
This package contains information about the matches for a given server.
•
Client Package
This package controls the flow of information between the network and Game and Server packages.
The package diagram below shows the dependencies between each package in the system as well as their
respective interfaces.
11
THREE-TIER ARCHITECTURE
12
The architecture we have chosen for our project is the Three Tier Architecture. This architecture deals with
three main layers:
•
User/Client Layer
Lists the various GUIs used in the system.
•
Business/Application Layer
Contains all the business logic of the system
•
Data Layer
Contains all information needed for communication and operation.
An example of this implementation is illustrated below:
13
DISCUSSION OF THE UML WORKBENCH
14
The development tools we have been assigned for this project work is the “Select Solution Factory”
software package from “Select Business Solutions”. http://www.selectbs.com/
“Select Solution Factory” is an integrated set of products and modeling tools for Service and Component
Based Development, design review, service/component management, requirements management, code
generation and reuse.
As the complexity of components increases, “Select Solution Factory” plays a greater role as a sophisticated
UML modeling tool that helps tailor components to specific requirements. It includes both analysis and
design functionality and uses visual tools to build components, manage component assets and support the
assembly of components into entire applications.
For our project we will solely focus on the UML modeling tools provided by the “Select Architect” software
of the “Select Solution Factory” package.
“Select Architect” features a scaleable design environment for pragmatic Business Motivation Modeling
(BMM), Business Process Modeling (BPM), service and Component based development and design, UML
and database design. It will be used to create and model all of the diagrams needed for the project.
At first it was difficult to come to terms with all the features that “Select Architect” offers but after 4-5
weeks of use, we had learned the functionality of the program and creating diagrams became a quick and
easy task. Overall, “Select Architect” saved us a lot of time and made the creation and modifying of the
various diagrams very fast and efficient.
REQUIREMENTS - FUNCTIONAL - USE CASE DESCRIPTIONS
15
USE CASE 1
Play Game
Goal in Context
User requests to play game
Scope & Level
User has an internet connection.
Preconditions
Client has found supported game(s).
User has been allowed to play selected game.
Success End Condition
Failed End Condition
Primary, Secondary,
Actors
User has not been allowed to play selected game.
Client, Network, Games, Servers, Database, Matches,
Request to play Game
Trigger
DESCRIPTION
EXTENSIONS
Step
Action
1
User launches Client
2
Client checks for internet connection
3
Client checks for supported games
4
User chooses Game
5
User selects Server
6
User selects Match
7
Client launches Game
Step
Branching Action
2a
Client fails to connect to Network
2ai
Client closes
3a
Client finds no supported game
3ai
Client closes
5a
User requests Server list refresh
5ai
Client refreshes Server list
VARIATIONS
Branching Action
RELATED INFORMATION
Priority:
Play Game
Performance
Highly variable depending on computer specification and hard drive
Top
16
capacity.
Frequency
High variable frequency 100’s – 100,000’s a day
Channels to actors
Internet
OPEN ISSUES
What if our Servers are down / crashed?
What if the client’s connection is disconnected during connection attempt
to the server?
Due Date
Release 1.0
…any other management
information…
<as…needed>
Superordinates
Find connection, Find Game
Subordinates
Client joins Network
USE CASE 2
Description
In order for the user to play games or host servers the client must first connect to the
network.
Preconditions
Post-conditions
Actor Actions
System Response
User has
an internet
connection
.
Client is
connected to the
network.
1. User launches
Client
2. Client connects to Network
Extension
At step 2 the client may fail to connect to network and will close.
17
Client checks Games
USE CASE 3
Description
In order for the user to play games or host servers they must have supported games on
their computer. The client searches the user's computer for any of these games.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
Client finds new
game(s).
1. User launches
Client
2. Client connects to Network
3. Client searches for games
Extension
At step 2 the client may fail to connect to network and will close.
At step 3 the client may fail to find supported game(s) and will close.
Client finds new Games
USE CASE 4
Description
The Client has found at least 1 game.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
Client is updated
with list of found
games
1. User launches
Client
2. Client connects to Network
3. Client searches for games
4. Client lists games
Extension
At step 2 the client may fail to connect to network and will close.
At step 3 the client may fail to find supported games and will close.
18
Games checks Database
USE CASE 5
Description
The Client cross references the list of found games with the list of supported games on the
systems database.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
Client is updated
with list of found
supported games
1. User launches
Client
2. Client connects to Network
3. Client searches for games
4. Client lists games
5. Client cross references list of found games with
list of supported games on the database
Extension
At step 2 the client may fail to connect to network and will close.
At step 5 the client may fail to find supported games and will close.
Client chooses Game
USE CASE 6
Description
User chooses any one of the supported games found by the Client.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has chosen
a game to play
and a list of
servers for that
game are
displayed.
1. User highlights
a game from the
list of supported
games.
3. Client displays a list of available servers for the
selected game from the database.
Clients has
found
supported
games
2. The “Select
Game” button is
selected.
Extension
None
Client selects Server
USE CASE 7
Description
The user selects any one of the servers listed by the Client.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
User has chosen
1. User highlights
3. Client displays a list of available matches.
19
connected
to the
Network.
a server.
a server from the
list of servers.
2. The “Select
Server” button is
selected.
Client has
found
supported
games.
Extension
At step 1, 2 or 3 the client may wish to refresh the list of servers.
Client selects Type
USE CASE 8
Description
The user selects the game type they wish to play.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has chosen
a game type and
the client lists
servers of that
game type.
1. User selects a
game type from
the drop down
list.
2. Client updates server list.
Client has
found
supported
games.
Client has
selected a
server.
Extension
None
Database lists Servers
USE CASE 9
Description
The Client updates with a list of servers from the database.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
Client is updated
with a list of
1. User highlights
a game from the
3. Client displays a list of available servers for the
20
to the
Network.
servers from the
database.
list of supported
games.
selected game from the database.
Client has
found
supported
games.
Extension
None
Client select Matches
USE CASE 10
Description
The user selects the match they wish to play.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has selected
a match.
1. Users
highlights a
match from the
list.
3. Client allows the user to join the selected match.
Client has
found
supported
games.
2. The “Select
Match” button is
selected
Client has
selected a
server.
Extension
None
Server list Matches
USE CASE 11
Description
The Client updates with a list of matches from the database.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Client is updated
with a list of
matches from
1. User highlights
a server from the
3. Client updates with a list of matches on the
selected server.
21
Network.
the database.
list of servers.
Client has
found
supported
games.
2. The “Select
Server” button is
selected.
Client has
selected a
server.
Extension
None
Client launches Game
USE CASE 12
Description
The Client launches the game.
Pre-conditions
Postconditio
ns
Actor Actions
System Response
Client is connected
to the Network.
User
plays
configur
ed
game.
1. The “Join
Server” button is
selected.
2. Client launches the game.
Client has found
supported games.
Client has selected
a server.
Client has selected
a match.
Extension
None
Client creates Server
USE CASE 13
Description
The user creates a server they wish to host.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has chosen
a game they wish
to create a server
for.
1. User highlights
a game from the
list of supported
games.
2. Client now allows user to configure a server for
the selected game.
22
Client has
found
supported
games.
Extension
None
Client configures Server
USE CASE 14
Description
The user customizes the server they wish to host.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has
configured their
server.
1. User selects a
game type from
the drop down
list.
3. Client now allows the user to host the configured
server.
Client has
found
supported
games.
2. User selects a
map list from the
drop down list.
Extension
At step 1, 2 or 3 the user may wish to quit the client and it will close.
Client sets type
USE CASE 15
Description
The user sets the game type they wish their server to have.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has set the
game type.
1. User selects a
game type from
the drop down
list.
2. Client updates the server game type.
Client has
23
found
supported
games.
Extension
None
Client sets maps
USE CASE 16
Description
The user sets the map list they wish their server to have.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User has set the
map list.
1. User selects a
map list from the
drop down list.
2. Client updates the server map list.
Client has
found
supported
games.
Extension
None
Client hosts Server
USE CASE 17
Description
The user hosts the server they have configured.
Precondition
s
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User hosts their
configured
server.
1. The “Host
Server” button is
selected.
2. Client launches the user’s server.
24
Client has
found
supported
games.
Extension
None
Server listed on Database
USE CASE 18
Description
The user hosts their server and it is listed on the database.
Preconditions
Post-conditions
Actor Actions
System Response
Client is
connected
to the
Network.
User's server is
listed on the
database
1. The “Host
Server” button is
selected.
2. The user’s server is added to the database.
Client has
found
supported
games.
Extension
None
NON FUNCTIONAL
Non-Functional Requirement
Description
Availability
As the system is accessible to clients worldwide it
must be available at all times.
Quality
The system fulfills the customer’s expectations by
25
conforming to the customer’s requirements of
gaming online.
Reliability
The system is reliable as the required databases and
servers have a 99.9% guarantee.
Scalability
The databases and servers for the system will often
be required to increase in size due to increasing
users and usage. For this reason it needs to be easily
scalable.
Usability
As the system is utilized by customers the user
interface is required to be very user friendly and bug
free.
USE CASE DIAGRAMS
Authentication
26
Game Browsing
First Cut of Game Selection Use Case Diagram
27
Navigation System
28
Game Hosting
29
GUI PROTOTYPES
Authentication – UI
30
31
Welcome – UI
32
Choose Game – UI
33
Choose Server – UI
34
Choose Match – UI
35
Create Server - UI
36
ANALYSIS
Candidate Objects
37
To identify the candidate objects we pick out the nouns from the description.
Playing a Game
The client must first successfully establish a connection to the network and then have his computer
scanned with at least 1 supported game being found and accepted by the database. The user must then
choose a game to play. From here the user can browse for game servers where numerous options are
available for filtering by such as max players, game type, maps, latency etc. Once the user has joined a
server he may choose to join any found matches that are found on that server. The user can also choose to
host and configure his own server.
Candidate Objects
Client
Network
Database
Game
Server
Match
CLASS DIAGRAM
38
39
SEQUENCE DIAGRAM
40
COMMUNICATION DIAGRAM
41
STATE CHART
42
E-R Diagram
43
DESIGN
ARCHITECTURAL STYLE
44
On finalization of the class diagram, a thorough analysis was conducted to examine which design patterns
would best suit our problems at hand. This involved choosing and applying structural and behavioral
patterns. The State Design Pattern (Behavioral) was applied to the Client package. The Adapter Design
Pattern (Structural) was applied to the Server package. The Model-View-Controller Pattern was applied to
the UI package.
STATE PATTERN
Intent
•
Allow an object to change its behavior. The object will appear to change its class.
Problem
•
An objects behavior is a function of its state, and it must change its behavior at run-time depending
on the state.
Discussion
The State Pattern is a solution to the problem of how to make behavior dependant on state.
Implementation
Client class is used as a boundary class for the rest of the system. We use this as our model when
developing our MVC controller. Because we use a state based design pattern in our model we reflect this
with an alternate state and controllers that will be based on each state available for the client.
ADAPTER PATTERN
Intent
45
•
Convert the interface of a class into another interface clients expect. Adapter lets classes work
together that couldn’t otherwise because of incompatible interfaces.
Problem
•
An “off the shelf” component offers compelling functionality that you would like to reuse, but its
“view of the world” is not compatible with the philosophy and architecture of the system currently
being developed.
Discussion
Adapter is about creating an intermediary abstraction that maps the old component to the new system.
Clients call methods on the Adapter object which redirects them into calls to the old component. This
strategy can be implemented either with inheritance or with aggregation. Adapter functions as a wrapper
or modifier of an existing class. It provides a different or translated view of that class.
Implementation
The Adapter Pattern was used to instantiate game and player type objects. Both inherit the basic attributes
from the server while implementing alternate interfaces to ensure that they can be implemented
differently within the system.
MODEL-VIEW-CONTROLLER PATTERN
Intent
•
Separation of objects into one of three categories - models for maintaining data, views for
displaying all or a portion of the data, and controllers for handling events that affect the model or
view(s).
Problem
•
Events typically cause a controller to change a model, or view, or both. Whenever a controller
changes a model’s data or properties, all dependent views are automatically updated. Similarly,
46
whenever a controller changes a view, for example, by revealing areas that were previously hidden,
the view gets data from the underlying model to refresh itself.
Discussion
MVC is a classic design pattern often used by applications that need the ability to maintain multiple views
of the same data. Separation, multiple views and controllers can interface with the same model. Even new
types of views and controllers that never existed before can interface with a model without forcing a
change in the model design.
Client Package
47
Database Package
48
Game Package
Match Package
49
Network Package
50
Server Package
51
UI Package
52
DATA DICTIONARY
Name: Network
Type: Actor
Description: Network represents all the information about the network such as:
53
Name: Servers
Type: Actor
Description: Servers represents an entity on the network that hosts matches for games.
Name: Database
Type: Actor
Description: The Database holds server information for each game, games settings and any information
needed for parsing.
Name: Games
Type: Actor
Description: Games represents the games found on the user’s computer by the client after successful connection to the Network.
Name: Matches
Type: Actor
Description: Matches represents a list of matches for each server.
Name: Client
Type: Actor
Description: The Client connects to the Network and searches the user’s computer for supported games. Using it the user can 1. Select a game to play
2. Launch a game
3. Create a server
4. Configure a server
5. Host a server
Name: Game
Type: Logical Entity
Description: The Game is used to store information about the various supported games. Such info includes:
game name, version, selected server and launch command.
54
Name: Server
Type: Logical Entity
Description: The Server is used to store information about the various servers. Such info includes: game
name and game version.
Name: Match
Type: Logical Entity
Description: The Match is used to store information about the various matches being held. Such info includes: score, players and players score.
Name: Database
Type: Logical Entity
Description: The Database is used to store addresses.
Name: GameServer
Type: Logical Entity
Description: The GameServer is used to store information about the various game servers. Such info includes: address and matches on the server.
Name: Network
Type: Logical Entity
Description: The Network is used to store information about the network. Such info includes: address and
network state.
Name: serverOptions [Server.Pserver$]
Type: Attribute
Description: Used to represent the server options available to the user when configuring a server.
55
Name: version [Game.Game$]
Type: Attribute
Description: Used to represent the version of a particular game.
Name: matches [Server.GameServer$]
Type: Attribute
Description: Used to represent the list of matches which is used to hold data on current matches of a server.
Name: Score [Match.Matches$]
Type: Attribute
Description: Used to represent a score which is used to hold score data of a match.
Name: PServer
Type: Interface
Description: The PServer interface provides the functionality needed to manage player server
configuration.
REFERENCES
Bennet, et al. (2005) Objected-Orientated Systems Analysis and Design using UML, 3 rd Edition.
McGraw Hill
2. Fowler, M (2003) UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3 rd
Edition. Addison-Wesley Professional
1.
56
http://www.selectbs.com/adt/analysis-and-design/select-architect Select Architect (BMM, BPMN,
UML) | Analysis and Design. [Accessed 19-3-2010]
4. http://baz.com/kjordan/swse625/intro.html Introduction to Risk & Risk Management in Software
Project Management. [Accessed 21-3-2010]
5. http://sourcemaking.com/design_patterns/adapter Adapter Design Pattern. [Accessed 12/4/2010]
6. http://www.enode.com/x/markup/tutorial/mvc.html Model-View-Controller Pattern. [Accessed
16/4/2010]
3.