group five design - design_doc_v1.0

8/2/2019 Group Five Design - Design_Doc_v1.0

http://slidepdf.com/reader/full/group-five-design-designdocv10 1/15

System Design & DetailedDesign Specifications

for

Or de l’Acadie – British Side

Version 1.0 approved

Prepared by Stu Penner

Group Five Design

March 2nd, 2012



System Design & Detailed Design Specifications for British Side

Table of Contents

1. Introduction................................................................................................................................11.1 Purpose ............................................................................................................................................... 11.2 Scope................................................................................................................................................... 1

1.3 Definitions, Acronyms and Abbreviations......................................................................................... 11.4 References........................................................................................................................................... 1

2. High Level Design...................................................................................................................... 12.1 Design Considerations........................................................................................................................ 1

2.1.1 Design Options............................................................................................................................. 12.1.2 Assumptions................................................................................................................................. 22.1.3 Constraints.................................................................................................................................... 2

2.2 System Overview................................................................................................................................ 2

3. Detailed Design (Component Design).......................................................................................33.1 Component/Feature: Translator.......................................................................................................... 3

3.1.1 Object Model................................................................................................................................ 33.1.2 Scenarios...................................................................................................................................... 43.1.3 Sequence Diagram........................................................................................................................ 5

3.1.3.1 Class: Solider........................................................................................................... 53.1.4 Interfaces...................................................................................................................................... 53.1.5 Dependencies............................................................................................................................... 53.1.6 Error Handling.............................................................................................................................. 53.1.7 GUI Mockups............................................................................................................................... 6

3.1.3.2 Class: Puzzle............................................................................................................ 63.1.7 Interfaces...................................................................................................................................... 63.1.8 Dependencies............................................................................................................................... 63.1.9 Error Handling.............................................................................................................................. 63.1.10 GUI Mockups............................................................................................................................. 6

3.1.3.2 Class: frenchDictionary.......................................................................................... 63.1.11 Interfaces.................................................................................................................................... 63.1.12 Dependencies............................................................................................................................. 73.1.13 Error Handling............................................................................................................................ 73.1.14 GUI Mockups............................................................................................................................. 7

3.1.3.3 Class: translatedWord............................................................................................. 73.1.15 Interfaces.................................................................................................................................... 73.1.16 Dependencies............................................................................................................................. 73.1.17 Error Handling............................................................................................................................ 73.1.18 GUI Mockups............................................................................................................................. 7

3.2 Component/Feature: NPC Messenger................................................................................................. 83.2.1 Object Model................................................................................................................................ 83.2.2 Scenarios...................................................................................................................................... 83.2.3 Sequence Diagram........................................................................................................................ 9

3.2.3.1 Class: BritishSoldier............................................................................................... 9

3.2.1 Interfaces...................................................................................................................................... 93.2.2 Dependencies............................................................................................................................... 93.2.3 Error Handling.............................................................................................................................. 93.2.4 GUI Mockups............................................................................................................................. 10

3.2.3.2 Class: Messenger.................................................................................................. 103.2.8 Interfaces.................................................................................................................................... 103.2.9 Dependencies............................................................................................................................. 103.2.10 Error Handling.......................................................................................................................... 103.2.11 GUI Mockups........................................................................................................................... 10

Page ii




3.1.3.2 Class: Message......................................................................................................103.2.12 Interfaces.................................................................................................................................. 103.2.13 Dependencies........................................................................................................................... 113.2.14 Error Handling.......................................................................................................................... 113.2.15 GUI Mockups........................................................................................................................... 11

4. Appendix A: Definitions, Acronyms, and Abbreviations.....................................................12

Revision History

Name Date Reason For Changes Version

Stu Penner 02/03/12 First Edition 1.0

Page iii




1. Introduction

1.1 Purpose

The main purpose of this document is to outline the architectural level and detailed design level for theBritish Side in the Or de L’Acadie game.

This document should be read by someone with a technical background and has experience in reading UMLdiagrams.

This design document will support the verification Software Requirement Specification (SRS) version 1.1and will support any test plan or test cases.

1.2 Scope

The design scope will build off of what was defined in the Requirement phase and what was writtenin the SRS document.

1.3 Definitions, Acronyms and Abbreviations

Please refer to Appendix A for a detailed list of Definitions, Acronyms and Abbreviations.

1.4 References

Please refer to SRS version 1.1

2. High Level Design

2.1 Design Considerations

This section will provide a high level overview of the design and explores some of the issues beforedeveloping a complete design solution.

2.1.1 Design Options

The design will take on the look and feel of the Or de l’Acadie environment making it look and feelas if these processes could be occurring in that time period. The messenger NPC avatar will havethe look of British solider during that time period and will speak (in text) with an appropriatedialect. The puzzle systems will appear as if you are reading parchment or from an old French journal. The puzzle will be kept simple during the development stages and additional features will be added on during the development stages pending time constraint analysis.

Page 1




2.1.2 Assumptions

The design of this system makes several assumptions about the hardware and software. All of theenvironmental requirements can be found in the SRS document. We are assuming that the heads updisplay that is built into openwonderland can be properly used to implement the puzzle system.Also, that the messenger NPC will be able to successfully track the other British players in the

game. The last assumption is that we will be able to implement a reward system that can beincorporated into the existing game framework.

2.1.3 Constraints

The biggest constraint on design is the fact that the modules created both NPC Messenger andTranslator are in strict conformance with the openwonderland framework. We are aiming to keepthe design simple to ensure a meaningful deliverable at the end of the production period rather thanattempting something beyond the scope of our design team.

2.2 System Overview

High Level Diagram

Page 2

T C P

Darkstar Server (Game Server) Application Server Web Server

Internet

ClientClient ClientT C P

T C P

T C P

TC

P

T C P




3. Detailed Design (Component Design)

3.1 Component/Feature: Translator

3.1.1 Object Model

Page 3




3.1.2 Scenarios

The scenarios can be outlined for both the translator puzzle and the clue word jumble through thefollowing activity diagrams. These show the step-by-step actions that take place when a puzzlescenario occurs.

Both diagrams follow similar paths and actions so that the same system can be used for twodifferent puzzle types.

Page 4




3.1.3 Sequence Diagram

Soldier – An interface used by the user to which is used to initiate the Puzzle or FrenchDictionaryclass.

Puzzle – An object, which represents a word jumble puzzle, which is in both French and English.

FrenchDictionary – An object, which contains every translated word found by the user.

TranslatedWord – An object, which represents a translated word found in the game. These are usedin the FrenchDictionary Class.

3.1.3.1 Class: Solider

3.1.4 Interfaces

The Soldier class itself will be a human-computer interface used by the user to interact with thepuzzle and dictionary.

3.1.5 Dependencies

The player will be required to have a character in openwonderland that they can use to perform theactions required to use the puzzle.

3.1.6 Error Handling

This class is built into the openwonderland framework and will follow any error detection that theyhave built into the system.

Page 5




3.1.7 GUI Mockups

3.1.3.2 Class: Puzzle

3.1.7 Interfaces

Has a graphical user interface to display the image to the screen in the heads up display built intoopenwonderland.

3.1.8 Dependencies

The puzzle class depends on the ability for the soldier class to recognize it as a puzzle. It alsodepends on the ability of the puzzle to be integrated into the heads up display module of openwonderland.


Any error handle will be inherent in the system being used to run the designed modules. Since themodules we create are dealing with static objects that do not interact directly in the world the errorswill be limited to closing the heads up display and making the object unclickable for further use.

3.1.10 GUI Mockups

3.1.3.2 Class: frenchDictionary

3.1.11 Interfaces

Has a graphical user interface to display image to screen.

Page 6




3.1.12 Dependencies

The frenchDictionary class depends on the ability for the soldier class to recognize it.


The object will not be able to be opened if an error occurs. Possible dialogue box giving a simpleerror message to the user may be implemented.

3.1.14 GUI Mockups

3.1.3.3 Class: translatedWord

3.1.15 Interfaces

The translatedWord class will be interfaced with openwonderland’s heads up display to allow easyaccess using existing module design. This will tell the user if the correct translation has beenachieved or not.

3.1.16 Dependencies

The translatedWord class depends on the ability for the frenchDictionary class to recognize it.


Null pointers will need to be handled if the user neglects to put in any input when attempting to

translate a puzzle. Catching this should not case an error attempt but should be recognized as afailed attempt at solving the puzzle. It will then follow that path on the activity diagram thatcontinues after a failed attempt.

3.1.18 GUI Mockups

Not available at this moment. A basic description of this class will be upon successful or failedcompletion of either puzzle a window will display a meaningful message described what hasoccurred and if successful the reward to be received.

Page 7




3.2 Component/Feature: NPC Messenger

3.2.1 Object Model

3.2.2 Scenarios

The scenarios can be outlined for both the translator puzzle and the clue word jumble through the

following activity diagrams. These show the step-by-step actions that take place when a message isgoing to be sent and what happens when the messenger reaches the final destination.

Page 8

-createMessage(in message : string, in author : string, in recipient : string) : void-deleteMessage() : void-updateMessage(in message : string, in author : string, in recipient : string) : void

-message : string-dateSent : Date-author: string

-recipient : string

Message

-delieverMessage() : void

-name : string-theMessage : Message

Messenger

1

1

-summonMessenger() : void

-charName : string

Soldier1...* 1

Or de L’Acadie – British Side NPC Messenger




3.2.3 Sequence Diagram

BritishSoldier – An interface used by the user to which is used to call a Messenger

Messenger – An object that delivers a message to another BritishSoldier

Message – An object which contains the given Message

3.2.3.1 Class: BritishSoldier

3.2.1 Interfaces

The Soldier class itself will be a human-computer interface used by the user to interact with thepuzzle and dictionary.

3.2.2 Dependencies

The player will be required to have a character in openwonderland that they can use to perform theactions required to use the puzzle.


This class is built into the openwonderland framework and will follow any error detection that they

have built into the system.

Page 9




3.2.4 GUI Mockups

3.2.3.2 Class: Messenger

3.2.8 Interfaces

The messenger will interface with the heads up display to ask the user information about the

message they want to send to another player character.

3.2.9 Dependencies

The messenger class depends on the ability for the soldier class to call the messenger. It alsodepends on the ability of the messenger to be integrated into the heads up display module of openwonderland.


Any error with the information provided to the messenger will cause the messenger to display astandard error message to the player and disappear from site. The messenger can then be calledupon again to reattempt a message.

3.2.11 GUI Mockups

This mockup does not display the standard British soldier garb that the messenger will be wearing.

3.1.3.2 Class: Message

3.2.12 Interfaces

The direct interface for this class is invisible and will appear as a text box in the heads up displayfrom the messenger class.

Page 10




3.2.13 Dependencies

This class will depend on the successful creation of a messenger object to call upon the functionswithin this class. It will also depend on proper message input from the player user.


Empty messages are not permitted and they will prompt the user to enter another message thatcontains some text. Any other more serious errors will cause the messenger system to exit and theNPC character will disappear. It will have to be recalled to try and send a message again.

3.2.15 GUI Mockups

A GUI mockup is not available at this time but it will appear as a heads up display asking the user toenter the message they want to create. This will be created when the British Solider calls on themessenger system.

Page 11




4. Appendix A: Definitions, Acronyms, and Abbreviations

openwonderland: A Java open source toolkit for creating collaborative 3D virtual worlds. Please

refer to http://openwonderland.org/about for more detailed information.

NPC: Non-player character

Page 12

http://openwonderland.org/about

http://openwonderland.org/about

group five design - design_doc_v1.0

Documents