Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment Marque Browne Manuel Honegger

Transcription

1 1 Swirl Multiplayer Gaming Simplified CS4512 Systems Analysis and Design Assignment Marque Browne Manuel Honegger Kieran O' Brien

2 2 BLANK MARKING SCHEME

3 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 4 Game Package..48 Match Package...49 Network Package...50 Server Package...51 UI Package...52 Data Dictionary...53 References...5 6

5 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 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 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 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 9 Week 7, 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 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 11 THREE-TIER ARCHITECTURE

12 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 13 DISCUSSION OF THE UML WORKBENCH

14 14 The development tools we have been assigned for this project work is the Select Solution Factory software package from Select Business Solutions. 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 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 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 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 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 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 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 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 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 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 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 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 26 Game Browsing First Cut of Game Selection Use Case Diagram

27 27 Navigation System

28 28 Game Hosting

29 29 GUI PROTOTYPES Authentication UI

30 30

31 31 Welcome UI

32 32 Choose Game UI

33 33 Choose Server UI

34 34 Choose Match UI

35 35 Create Server - UI

36 36 ANALYSIS Candidate Objects

37 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 38

39 39 SEQUENCE DIAGRAM

40 40 COMMUNICATION DIAGRAM

41 41 STATE CHART

42 42 E-R Diagram

43 43 DESIGN ARCHITECTURAL STYLE

44 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 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 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 47 Database Package

48 48 Game Package Match Package

49 49 Network Package

50 50 Server Package

51 51 UI Package

52 52 DATA DICTIONARY Name: Network Type: Actor Description: Network represents all the information about the network such as:

53 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 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 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 56 Select Architect (BMM, BPMN, UML) Analysis and Design. [Accessed ] 4. Introduction to Risk & Risk Management in Software Project Management. [Accessed ] 5. Adapter Design Pattern. [Accessed 12/4/2010] 6. Model-View-Controller Pattern. [Accessed 16/4/2010] 3.