Evaluations of Adaptive Programming
===================================

The latest information is at:
http://www.ccs.neu.edu/research/demeter/evaluation/success.html

Before reading the evaluation below,
you are invited to read Alan Davis' 
column in IEEE Software, March 1996,
page 4. We agree partially with his view that 

  if a new method or tool has an obvious 
  positive effect on quality and/or
  productivity, adopt it. If you must 
  run an experiment to determine
  the degree of usefulness, then the 
  benefit is _not_ obvious.

In our view, the benefits of Adaptive 
Programming (AP) are absolutely
obvious: it has the double benefit 
of making programs simpler
and much more flexible.
I think that experiments are still 
necessary to confirm the obviousness.

We give results of 
uses of Adaptive Programming below.

How does the use of Adaptive Programming 
influence the software development process?
Does it decrease/increase the 
time to develop software
or decrease/increase the quality of 
software designs or code?

Some of the claims that have been made are:

 - Results in code that is more 
   reusable, flexible, and
   understandable
 - Results in an architecture that is 
   smaller, simpler and more 
   understandable

Is there any evidence to back up those claims?

Currently, there are no 
controlled experiments, but
many case studies and anecdotal 
evidence from outside the development group.

The case studies can be summarized as follows:

For small projects, Adaptive Programming 
does not save time or make the programs
considerably smaller. However, 
the programs are perceived to be
easier to understand and maintain.

For medium-sized projects, Adaptive Programming 
saves significantly: Development time
is shortened and code size shrinks.

Adaptive Programming works best 
for larger projects and
when the project has no 
predefined application-specific
languages and the programmer is in 
control to design his/her own
languages.

Some quantitative measurements 
for case studies are below.

You can see the source code of 
the case studies, by browsing
this directory: 

http://www.ccs.neu.edu/research/demeter/evaluation

Look at files README-project 
and README in each subdirectory.

CASE STUDIES:
=============

CASE STUDY: Design rule checker 
for structural object-oriented designs.
Author: Dino Dibiaso: directory 
dibiaso (email: dibiaso@ccs.neu.edu)

An excerpt from file: README-project

I realize that a project of this 
scope could never be accomplished in the
time it took me to do it without 
using the adaptive software techniques.
The large number of traversals required 
to perform all of the class 
dictionary semantic checking functions 
would have been overwhelming in
itself to write in straight C++. 

Also, 3/4 of the way through 
my implementation I
realized that I was not using the 
latest CD for Demeter C++ class
dictionaries and had to change my 
CD! The changes minimally affected
some of the propagation patterns, but 
did not change too much considering
how much code was already developed.

NOTE: this project was done in about 
four weeks. Development of the
same software without using Adaptive 
Programming took several
years (includes design time 
and theory development).

      49286 characters of adaptive code 
	    was translated by Demeter into 
     259859 characters of documented 
	    C++ member functions.

====================================================================
CASE STUDY: Network routing algorithms
Spyros Matsoukas: directory 
mats, (email: mats@ccs.neu.edu)

An excerpt from file: README-project

Comparison between the original C version and the 
Demeter version of the program:

1) The code size is the same, approximately 
   1800 lines. 
2) The C program uses arrays to represent 
   the network topology, traffic
   matrix, ring and routing tables, resulting 
   in code which is hard to understand 
   and maintain. Also, the representation of 
   the structures is hard-coded and 
   very difficult to change. 
   But execution is faster.
   With Demeter, the structures used by the 
   program are all defined in the class
   dictionary, and minor changes/additions 
   of parts can be performed very easily.
   Also, the code is much easier to understand 
   and maintain. But the list traversals
   result in slower execution.
3) Both programs took about the same 
   time to implement, i.e., 3 weeks. 



===============================================================================
CASE STUDY: Bus system simulation
Ali Ozmez: directory ozmez, 
(email: ozmez@ccs.neu.edu)

An excerpt from file: README-project

The project I did is a demonstration 
project. The original program had
been done using C++ only. I rewrote 
it as an adaptive program from scratch.

The resulting adaptive program has a 
code size of around half of the original
one (226 lines versus 381 lines, excluding 
the main program), and much more
flexible (bus speed, bus capacity, etc. 
are not fixed as contrary to the
original C++ program). Both took 
the same amount of time to finish (around
2 weeks). The adaptive program is easy 
to understand, and maintain.

I learned about adaptive software 
through the COM3360 class; reading
the Demeter Book, the users guide, 
the lab guide, and doing the
homeworks. Well, the difficulty of 
learning adaptive software might be
getting used to decoupling data 
structures (class dictionary graphs) and
the the actual program code (propagation 
patterns). Once you get used to
that everything works well.

============================================
Sizable projects done with Demeter are in:

http://www.ccs.neu.edu/research/demeter/course/projects
=======================================================

More anecdotal evidence is at URL:

ftp://ftp.ccs.neu.edu/pub/people/lieber/Demeter-interest