"Environment tests"

Richard Staehli rastaehli at mac.com
Wed Nov 5 19:41:00 UTC 2003


Researchers in component-based software are looking for good ways to 
write a "contract" between a software component and the environment in 
which it executes.  There are simple ways to do this, such as 
specifying that the environment "MUST BE Squeak 3.2 with no changes", 
and there are harder ways, such as specifying that the environment must 
supply some explicit set of objects referenced from the component and 
that those objects "must BEHAVE the same as corresponding objects in 
Squeak 3.2".

For the near term, I think we could do very well to concentrate on the 
simple approach.  This approach becomes very useful as we break the 
Squeak image into much smaller packages (or components).  Then, a 
component that depends on "Squeak Core 3.8" and "Balloon3D 2.5" will 
run happily in an image that also has some arbitrary other component 
like "Celeste x.x".  This approach assumes that you have already tested 
exhaustively with the behavior of a particular version, and that you 
can use the version name to positively identify that behavior at 
link/load time.

I don't know a complete and general way to test for behavioral 
equivalence.  I guess it is equivalent to the halting problem.  For 
simplified computational models, the Model Driven Architecture (MDA) 
community does have some positive results.  I was just reading 
"Verified Systems by Composition from Verified Components" by Fei Xie 
and James C. Brown of University of Texas at Austin.  They have a 
formal model of environmental assumptions and component properties that 
can be derived from an executable component specification, and they 
have applied this model to a narrow domain of sensor network components.

Richard Staehli




More information about the Squeak-dev mailing list