"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
|