Managing Software Development
Project 1: Requirements, Choose Implementation, Reusable Assets
Spring 2008
Karl Lieberherr  
Out: Jan. 7, 2008

Due date: Jan.  14, 2008

We will develop a product line around 
the Specker Derivative Game (SDG), an algorithmic
trading game for financial derivatives.
The informal requirements for a specific product, 
called SDG-F07, in the product line is given here:
http://www.ccs.neu.edu/home/lieber/evergreen/specker/game.html
We call the product line SDG-PL-SP08 which will be a family of SDG-F07-like games 
implemented in Java. The requirements for SDG-PL-SP08 will be gradually developed
during the course.

We have several implementations of SDG-F07 from an earlier undergraduate course.
/home/fengzhou/csg110/project1
In this course we want to extract reusable assets from those implementations
and then configure those assets into implementations of new products
in the family SDG-PL-SP08 of SDG-like games.
We want to create new games SDG-SP08-1, SDG-SP08-2, etc. that all belong
to the same family SDG-PL-SP08.
Ideally, at all times, we want to have running players that
successfully compete in games.
We will make incremental changes to those running players.

What is an SDG-like game? It is a game where participants 
sell and buy derivatives of a given family of types. 
The buyer of a derivative only knows the type. 
Each derivative has an owner, a type T, a price in [0,1], a set
of possible outcomes constrained by T
and a pay function that maps outcomes to [0,1].
The outcome may be determined by the buyer and seller of the derivative only
or by the context only or by a combination of the two.
The context could be the weather, or the stock market.

Examples:
SDG-F07-gen:
outcome determined by seller and buyer:
derivative: raw material type T
price p in [0,1]
outcomes: raw materials r of type T and finished products finished(r).
pay(r, finished(r)) = quality of finished product.

SDG-F07:
outcome determined by seller and buyer:
derivative: conjunctive normal form type T.
price p in [0,1]
outcomes: 
weighted conjuctive normal form F of type T,
assignment J for F
pay(F,J) = fraction of weighted clauses satisfied by J in F

SDG-F07-2:
same as SDG-F07 but with a different pay function.
pay(F,J,p) = 1 if fraction of weighted clauses satisfied by J in F is > price p.
             0 otherwise.

Weather prediction:
outcome determined by context (weather):
derivative: no frost in Orlando, Florida in February 2008.
(here derivative type and derivative are the same)
price p in [0,1]
outcomes: number of frost days frostORL in Orlando, Florida in February 2008.
pay(frostORL) = 1 iff frostORL > 0, 0 otherwise.

Stock market:
outcome determined by context (stock market):
derivative: right to buy 1 share of MS stock for $25 on May 1, 2008.
price p in [0,1]
outcomes: MS stock price on May 1, 2008 is x.
pay(x) = 1 if x>25, 0 otherwise.


What to turn in for project 1:

PART 1:

Critique the requirements document
http://www.ccs.neu.edu/home/lieber/evergreen/specker/game.html
Is it clear; are there ambiguities? Discuss at least one 
problematic issue of the requirements document.

PART 2:

Experiment with algorithmic players from the last semester.
/home/fengzhou/csg110/project1
Run them and study their source code. You are encouraged to learn to use
Eclipse to browse and develop Java code.
Select one player as your favorite player for further evolution
and extracting core assets for a product line.
Discuss possible reusable assets in your selected player.
Discuss the impact of the following requirements change:
Instead of CNFs we use Boolean CSPs. Note that CNFs
are a special case of Boolean CSPs.
(see e.g. http://www.ccs.neu.edu/home/guaraldi/csg260/#csp)

What to turn in: The name of the algorithmic player you have selected.
A rationale why you selected the player. What features convinced you that
your player is well written and easy to evolve?
A report on the bugs you found in your selected player.
Impact analysis sketch for the transition from CNFs to Boolean CSPs.

PART 3:

The Law of Demeter, proposed at Northeastern University by one of my PhD students,
is still a topic of interest:
http://www.javalobby.org/java/forums/t104659.html

We will follow the Law of Demeter using DemeterF.
DemeterF is a tool that supports Adaptive Programming by abstracting out traversals
in a powerful way.  DemeterF helps that you don't have to write many small methods
as described in the above link.

Study the DemeterF page:
http://www.ccs.neu.edu/research/demeter/DemeterF/

including the paper: 
Abstraction of Communication in Traversal-Related Concerns
(ECOOP submission)

What to turn in:
One paragraph about your intuition how DemeterF might help to
develop software product lines.
It is not expected that you know how to program in DemeterF after reading
the DemeterF page: This is your first opportunity to familiarize
yourself with DemeterF. There will be many more.