After I reviewed several projects yesterday and I talked with
Doug Orleans about your progress, I noticed that the
idea of growth plans and structural simplification has not
found a place in several of your projects. This leads to
an unproductive use of your time.

Growth plans are important and you are encouraged to use them.
Each project needs to have a growth plan of at least length 3.
A project which fails this test will have 25% taken off.

-- Karl Lieberherr

===================
Adaptive Programming (AP) supports effective 
structural simplification during software development.
The class dictionary for a project should grow according to
the rules of a growth plan (GP) (a simple C++ example is
on page 155 of the AP book, for a formal definition, see
page 489 of the AP book; follow also the index entry "growth plan" of the book
to get more information).
Informally, a growth plan for a class dictionary c and
project p consists of
a sequence of growing class dictionaries culminating in c.
Each element of the sequence defines a simpler,
but self-contained,
class structure which is sufficient to implement some useful behavior
for project p.

The main benefit of structural simplification is reduced
compile time for adaptive programs. 
Growth plans are very important for developing programs in Demeter/Java
or Demeter/C++. They can cut the compilation time by several
factors.

Example:
You have an adaptive program:

A{
  traversal t(Visitor v){ to Z;}
  ...
}
Visitor{
  before A (@ ...; host.get_b(); ... @)
  before K (@ ...; host.get_l(); ... @)
  before Z (@ ...; host.get_a(); ... @)
}

Your class graph contains more than 50 classes.

Instead of using a class dictionary with over 50 classes,
it is sufficient (assuming there are no other traversals)
to use the class dictionary:

A = K B.
B = "b".
K = Z L.
L = "l".
Z = [A}.

or maybe:

A = <ks> List(K) B.
B = "b".
K = <zs> List(Z) L.
L = "l".
Z = [A].
List(S) ~ {S}.

This reduction of the class dictionary is part of a growth plan
for the big class dictionary.
Using this simplified class dictionary
leads to a reduction of the compilation time by a factor of 10
(if the first solution is chosen and if we assume the
compilation time is proportional to the number of classes.)

When the program is debugged for the small class dictionary,
you can test it on the "next larger one" in the growth plan for
the big class dictionary.

In the small class dictionary you should use the same names
as in the big class dictionary so that the program runs
unchanged with the big and small class dictionaries.

Growth plans are very convenient to use by beginners of AP
so that you get a fast turn-around time. 

Each project needs to consist of a small sequence of directories
called 

project_name_gp1
project_name_gp2
project_name_gp2
...

and a file growth-plan-rationale. Each directory contains the
*.cd file for a growth phase along with the *.beh file
for that growth phase. An interesting property of growth plans
is that the behavior file for growth phase i will also
work with growth phase i+1. This clearly shows that the
work you do for early growth phases will be reused 100%
in later growth phases.


In file growth-plan-rationale you explain the rationale behind
your problem decomposition. 

Example:
I assume a project which implements some behavior for
class dictionaries.

gp1:
Construction classes and required construction edges only.
gp2:
Added alternation classes and edges.
gp3:
Added syntax.
gp4:
Added repetition classes and required repetition edges.
gp5:
Added optional construction and repetition edges.
gp6:
added parameterized classes.
...

The sequence depends on your project.

To conserve disk space, run "make clean" on the current
growth phase when you go to the next growth phase.