RJLRef: $PH/06f522/SetGame06f/schedule_rlFdbk061117.doc

See my comments at [RJL:...] below -

Bob Lechner

From: Anthony J Gabrielson Nov 15, 06 01:10:26 PM -0500

To: Chris Guffey <cguffey@gmail.com>

cc: all

Subject: Re: Final Project

Chris,

I had been thinking about that:

On Wed, 15 Nov 2006, Chris Guffey wrote:

>Message 30/1456 From Chris Guffey Nov 15, 06 12:30:56 PM -0500

>To: "Anthony J Gabrielson" <agabriel@cs.uml.edu>

>Subject: Re: Final Project

>cc: all

> I don't mind doing more than what I'm listed for there. It doesn't

> look like much as it is but maybe once I see a more detailed

> explanation than it will look like more. Otherwise I probably help

> either you or Alison with your end.

That's what I was hoping. In my outline proposal I'm really hoping to

align leads with areas of expertise (that I know of). If I missed

someone's expertise, my apologies. I think this project should be a lot of

fun, it looks like a neat game.

> The only thing not really listed in your timeline is that we need some

> time to understand the code written by the 04 group. And also testing.

>

[RJL - And how! ]

In the next week we should all at least look at the code from '04. I am

hoping Alison has time to do a test run on the network code that is there

and get an idea of what she likes/dislikes. I'm hoping to start working

on an initial version of the GUI tomorrow night that can do *something*.

>> Timeline:

>> 11/21/06: Write up what needs to change for this to work.

>> 11/28/06: Good implementation of basic test cases

>> 12/05/06: Networking Demos working & GUI demos working

>> Network: Should have a good stand alone demo that sends properly formed

>> messages to simulate a game.

>> GUI: Should interface with Middleware to play a stand alone game

>> 12/12/06: GUI should be plugged into networking code for full functionality

>> Should have a fully functional network game

Do others think this timeline look feasible?

Thanks,

Anthony

On 11/14/06, Anthony J Gabrielson <agabriel@cs.uml.edu> wrote:

> 522 Final Project

>

> Project Definition:

> We need to create a distributed graphical Set game.

[RJL: I'd like a more robust proof-of-concept for distributed system

apps and a color graphics display of the game table (card layout)

as it changes during game play.

> We are to reuse {most | all} of the existing code.

[RJL: Including auto-generated code for data structures

(from SetGame06f.sch via chgen13) and state models and

message-passing events as defined in the database for LCP in SetGame04s. ]

> We must generate a GUI for this.

[RJL: That is: generate a bitmapped card layout background picture

(underneath bde's canvas overlay?) with mouse clicks to select cards,

and log/replay to propagate card layout initialization and updates

from layout table in database to remote process of each player?]

> Based on: http://setgame.com/

> Existing Code Location:

> http://www.cs.uml.edu/~lechner/06f522/COOL-LCP/SetGame04s/

>

[RJL: Most of Networking is too brief and cryptic - but redesign is up for grabs

since existing networking code is outside the current scope of COOL-GEn/LCP/BDE.

It needs more explanation and writeup for a Detailed Design Review (probably 11/28)]

You need to separate concerns of administration and operation of the data collection

and distribution as messaging services and event communications, as an abstract layer above

the communication ports and surrogate processes. You MUST NOT use any shared memory; copy events between buffers for inter-process communication. [Log and replay are persistent database-level concepts. They do NOT depend on bde.]

> Networking Lead: Alison

> Server (4 ports)

> Register a new client

> Send a new board

> Accept Combination

> {increment | decrement} score

> Workstation (3 ports)

> Register self on startup

> Accept a new board

> Accept score

> Needs an interface methods for GUI/Test

> To send 3

> Set global with score

> Test Cases.

>

> GUI Lead: Anthony

> Display the game board.

> Three network threads running in the background.

> Figure out which 3 are to be checked

> Change bkg [background?] slightly on selected objects.

> Be able to clear some set of selected objects.

> Display score

> Needs to call Generate Card to put a card in a spot

[RJL: Existing 04s code does random selection without replacement,

and keeps track of the (symbolic) 12-card layout, in current data and state models.

Again, all computation should be independent of the bitmapped GUI level

where the 12-card layout picture is generated and displayed. Goal is to make this layout

re-integratable as a background (screen-saver-like) with bde's active drawing

canvas, if bde does not get integrated into your design.]

[RJL: NOTE: This process of re-introducing your card layout under bde's canvas

is vital to future evolution of COOL support for distributed projects.

This must be a section of your project's Final Report.]

> Middleware

> Generate 81 Lead: Chris

> Factorial to come up with attributes.

> Generate Card Lead: Nitin

> GL code capable of generating 81 different cards

> Assume GUI will deliver to proper coord's for card placement.

> Take a set of attributes to automatically generate proper card.

[RJL: Four 3-valued attributes define one card. 3*23*3*3 = 81 special cases.

Cards should be scalable, depending on window height and width,

which should be configuration parameters under control of individual players.

Each card will occupy 1/3 of width and 1/4 of height of this window. Layout updates will

be passed as EventInstance messages and will specify 3 new cards and their positions. ]

[RJL: This also is too cryptic. Re-use the state model code from SetGame04s:]

> Verification

> Based on just 3 serial numbers determine if match exists

[RJL: It takes 4 property values from each card, which are stored in the database

at an indexed or pkey-ed location in the 81-instance deck of cards. (SetGame04s might

have only used three of them. Some of my slides used only 3 for readability.]

[RJL: WHenever possible after reading SetGame04s, reuse their nomenclare

so documentation is readable. In fact, I'd prefer that your document[s] be extensions

of and build upon SetGame04s reports, to ease your job and that of future readers.]

[RJL: What on earth does Generate 81 mean?]

> (will use Generate 81)

>

> Integration Lead: Keith w\ help from Nitin

> Get everything compiling on Linux

>

[RJL: Integration means more than compile and link, of course.

All residual bugs should be documented after project testing.]

> Writeup Lead: Keith

> Good overall explanation of how everything works

Detailed description of reuse achieved

[RJL: What about archiving? I'd like you to put the 04s version

and 06f revisions into one new CVS repository.]

>

> Timeline:

> 11/21/06: Write up what needs to change for this to work.

> 11/28/06: Good implementation of basic test cases

> 12/05/06: Networking Demos working & GUI demos working

> Network: Should have a good stand alone demo that sends properly formed

> messages to simulate a game.

[RJL: log layout updates at Server and interpret them at client sites as layout change events.]

[RJL: What ' stand-alone game' means is unclear to me.

Do you mean shared memory or multiple threads on same CPU?

Please elaborate for the 11/28 Design Review.]

> GUI: Should interface with Middleware to play a stand alone game

> 12/12/06: GUI should be plugged into networking code for full functionality

> Should have a fully functional network game

>

> Most of the project areas seemed to be agreed upon after class. If you

> don't like the area, let it be known on the list so we can figure it out

> quickly. The legacy code needs to be looked at soon and we should report

> to Prof. Lechner and the group what needs to change by next week.

>

[RJL: It is a very good first cut. Not clear yet is who does what.]

> Hopefully this sounds good; Thanks,

> Anthony