Vdashneg, Diversity and Square Root Board Inc Initial Design and - - PowerPoint PPT Presentation

vdashneg diversity and square root board inc initial
SMART_READER_LITE
LIVE PREVIEW

Vdashneg, Diversity and Square Root Board Inc Initial Design and - - PowerPoint PPT Presentation

Vdashneg, Diversity and Square Root Board Inc Initial Design and Intent of the Framework Architecture Interaction among teams. Interaction among teams. Testing Experience Plurals Demo RMI Service Create Start Game


slide-1
SLIDE 1

Vdashneg, Diversity and Square Root Board Inc

slide-2
SLIDE 2

Initial Design and Intent of the Framework Architecture Interaction among teams. Interaction among teams. Testing Experience Plurals Demo

slide-3
SLIDE 3
slide-4
SLIDE 4

RMI Service

slide-5
SLIDE 5

Create Start Game

<RequestMessage> <Operation Name=“Start”/> <RequestMessage> <ResponseMessage> <Game InstanceID =“100”/> <More fields……> < ResponseMessage >

RMI Service

slide-6
SLIDE 6

<RequestMessage> <Game InstanceID=“100”/> <Operation Name=“Move”> <Param Name=“Colum” Value=“1”> <RequestMessage> <ResponseMessage> <Game InstanceID =“100”/> <More fields……> < ResponseMessage >

RMI Service

slide-7
SLIDE 7

Main Feature:

Decoupling of game development and UI

development once a protocol of communication was agreed on communication was agreed on

We used RMI and java interface methods as

protocol

There was one change:

Communication from asynchronous to

synchronous

slide-8
SLIDE 8

Clear interfaces defined by Java interface. Only clarification required was the type of

commands being passed around. commands being passed around.

Minimal interaction was required between

game team and framework team.

However…

slide-9
SLIDE 9

The communication protocol was not clearly

defined (web service? RMI?). RMI was chosen. Generality of the framework was unrealistic

Generality of the framework was unrealistic

for the amount of development resource.

Some modification in framework was

required to accommodate resource. Two players play on one screen.

slide-10
SLIDE 10

What worked: Initial meeting with all three teams. Clear definition of interfaces. What didn’t work: Ideal, general framework is not realistic in terms

  • f resource.

Critical path. Some teams depended on other

teams to finish.

slide-11
SLIDE 11

Unit testing required scaffold tests. Difficult to automate test for the UI. Use of

Selenium testing tool considered. Selenium testing tool considered.

System tests passed smoothly. Good

coordination among teams.

Game plug-in bug found at UI system test

(draw).

slide-12
SLIDE 12

The below method did everything…

processCommand (GameState gameState, Command c)

Behavior different according to instance of

  • Command. Plural states can’t change states
  • Command. Plural states can’t change states

according to instance of Command.

Would require major refactoring to work around

plural.

All teams needed to coordinate to make plural

work, instead of using it as verification.

slide-13
SLIDE 13

Let’s play:

slide-14
SLIDE 14