Subject: Notes on changing complex software systems

From: [email-masked]
Date: Sun, 21 Nov 1993 05:22:18 -0800

Gustavo's suggestions ("wouldn't it be nice if ...") and Pavel's response
("yes, and it would not be hard, but existing code would break ...") are an
example of a problem that shows up in all computing application areas: the
albatross of existing code.  Those people and organizations who cannot afford
to wait until they can write or buy the "last" version of a system or language
are forced to write the "first" version instead: they must make some design
decisions that they would prefer not to make.  It is in the nature of many of
those decisions that at a later time they might be made differently, except
for the existing code that would be broken.  I'm going to offer some
suggestions for a change in attitude about producing code.  They are not
criticisms of MOO; ALL long-lived programs or programming systems eventually
have the same problem.  Programs built by many people are especially subject
to this problem because different people prefer different styles of
programming.

I work in an application area (space systems) in which very large systems are
routinely millions of lines of code, take years to produce and live for
decades; we face this problem in every project.  Not only do many people (even
many companies) cooperate to write these programs, but they contain many
different programming styles because they perform many different kinds of
functions.  Because there are no good methods for producing code of this
magnitude and heterogeneity, and no methods of any kind for revising it on the
fly, this albatross problem of Software ReUse is particularly important to us.
We have been conducting basic research in this area for some years, and I
think it might be useful to this community to read some of what we have
learned.

What we have been doing in our research is to begin with this aspect of
computing, and take multiplicity as a fundamental characteristic of the system
that must be supported by our software infrastructure.  Our goal in this
research is to determine the kinds of infrastructure needed to manage this
complexity.  Another way to describe this fundamental characteristic is to
note that no one model suffices to describe a complex system; no one
programming methodology; no one programming language.  There is even ample
evidence that people do not use one hierarchy of simple objects (see George
Lakoff's book "Women, Fire and Dangerous Things", which reports on some
interesting research of Eleanor Rosch).  One result is that whenever we think
of a way to do something, we must choose whether or not it is the "last" way
we will use; almost always it is not.  So the question becomes "How can we
maintain the flexibility we think we will need, so that all of these questions
can be given different answers as we learn more about the processes required?"

Though it is sometimes hard to tell in our business, there have been some
fundamental advances in the practice of computing over the last 30 years.  The
layering that makes computer networks as ubiquitous as they are now is one way
to manage certain kinds of complexity.  Another is the object style of
modeling the components of a program.  Another is the ease with which
programming language interpreters and compilers can be built for simple
languages.  Another is the notion of "meta-", that is, explicit knowledge
bases that contain declarative knowledge about processes in the program.  For
you non-historians out there, all of these are between 20 and 30 years old;
they have been greatly refined in the interim, but not fundamentally changed.

OK, enough background; here is what I recommend for infrastructure in complex
systems.  We call it the "wrapping" approach; there are lots of papers now
about it.  I will come back to MOO TOO 8-) at the end.

First, every part of a system is a "resource" that provides some kind of
"information service".  This includes tools, programs, external files,
databases, user interfaces, other communication interfaces, etc.
(Everything!).  Then every resource has one or more "wrappings", which are
explicit machine-processible descriptions of the uses of the resource.

The wrapping descriptions are used for the "Intelligent User Support"
functions: "Selection" (which resource should be used for a particular
problem), "Assembly" (how is it used: data formats and protocols, the
syntactic information), "Integration" (when should it be used: assumptions and
limitations, the semantic information), "Adaptation" (how is it set up for a
particular kind of problem), and "Explanation" (why was it used in this
context).

The processes that read and interpret wrappings are equally important, since
they organize the information services provided by the resources.  Our notion
of problems deals with context as an explicit part of the problem study
process.  Therefore, problem study always occurs after a context is chosen and
a problem is posed.  The basic problem study sequence is monitored by a
resource called the "Study Manager", which has the following simple steps:

	interpret problem:
		match resources
		resolve resources
		select resource
		adapt resource
		advise poser
	apply resource
	assess results

"Matching" resources means finding a set of resources that might apply to the
current problem in the current context.  It is intended to allow a superficial
first pass through a possibly large Knowledge Base of wrappings.  "Resolving"
resources means eliminating those that do not apply.  It is intended to allow
negotiations between problem poser and wrapping about each resource to
determine whether it can be applied.  "Selecting" a resource is simply making
a choice of which of the remaining candidate resources (if any) to use.
"Adapting" a resource is setting it up for the current problem and problem
context.  "Advising" the poser is notifying the problem poser (who could be a
user or another part of the system) of what resource was chosen and how it was
set up.  "Applying" a resource is using it to provide its information service,
either doing something or presenting something.  "Assessing" results is
determining if the application succeeded or failed, and helping to decide what
to do next.

OK, so far this is just a simple-minded planner-type algorithm.  Several
additional design features make it a framework for something more.  First, all
of the wrapping processes are themselves wrapped.  Second, the processing is
completely recursive: "Posing" a problem is itself a problem, and is solved
using the same steps, as is "finding" a context and "applying" a resource and
ALL of the other steps listed above.  The simple-minded form is just the
bottom of the recursion.  These two things mean that every new planning idea
that applies to a particular problem domain (which information would be part
of the context) can be written as a resource that is selectable according to
context; it also means that every new mechanism we find for adaptation or
every specialization we have for application can be implemented as a separate
resource and selected at an appropriate time.

Furthermore, since the Study Manager steps above are the only ones that
interact with the Wrapping Knowledge Base (WKB), we can use completely
different syntax and semantics for different parts of the WKB in different
contexts, and select the appropriate processing according to context.
Finally, the Study Manager is only one of a family of processes called
"Problem Managers", each of which is wrapped and selectable according to
context, and each of which can pose problems and organize their study in
different ways.  For example, the original context and problem that starts the
processing are problems

	find context
	pose problem

posed by the Coordination Manager.  The kinds of resources that might be
chosen to apply to these problems would be menus or other requests to the
human user to make a choice of context and problem.

All of this is layered on top of a message-passing mechanism that keeps track
of which resource is interested in which messages, how to apply the resources
(the interface between the application request and the operating system), and
how to deliver messages; it collects and distributes messages accordingly.

Many more details can be found in the references below; this is not a complete
theory; it is more like a framework for a theory, and we think it makes a very
good approach to the problem of software infrastructure for large system
integration (nothing says the resources have to be software).

For the MOO, what this approach offers is the following intriguing property:
changing the fundamental nature of the programming language, not by replacing
the old one with a new one, but by adding a new one to work side by side with
the old one, with context information used to disambiguate if the expressions
themselves do not.  There would be "little languages" with little parsers to
make the connection between language expressions and activity in the server or
the database, and ALL of those choices would be variable.  Compatibility is
not an issue; NO one language can express all the things we might want to
express, so there cannot be one comprehensive compatible organization; we have
to start with the notion that there will be multiple partially incompatible
languages.  As I have now come full circle to the point with which this note
began, I will stop here.  Comments are welcome.

more later,
cal

			Christopher Landauer
			Systems Planning and Development Division
			The Aerospace Corporation
			[email-masked]
			(703) 318-1666

References

Kirstie L. Bellman,
	``An Approach to Integrating and Creating Flexible Software
		Environments Supporting the Design of Complex Systems'',
	Proceedings of the Artificial Intelligence in Logistics Meeting,
	8-10 March 1993, Williamsburg, Va.,
		American Defense Preparedness Association (1993)

Kirstie L. Bellman,
	``The Challenges in Testing Heterogeneous Software Environments'',
	Proceedings AIAA Computers in Aerospace 9 Conference,
	19-21 October 1993, San Diego (1993)

Kirstie L. Bellman, April Gillam, Christopher Landauer,
	``Challenges for Conceptual Design Environments:
		The VEHICLES Experience'',
	Rev. Int. de CFAO et d'Infographie, Hermes, Paris (September 1993)

Christopher Landauer,
	``Applications of the Wrapping Approach in Software Engineering'',
	Proceedings AIAA Computers in Aerospace 9 Conference,
	19-21 October 1993, San Diego (1993)

Christopher Landauer, Kirstie Bellman,
	``Integrated Simulation Environments'' (invited paper),
	Proceedings of DARPA Variable Resolution Modeling Conference,
	5-6 May 1992, Herndon, Virginia, 
	Conference Proceedings CF-103-DARPA, published by RAND (March 1993);
		shortened version in
	Proceedings of the Artificial Intelligence in Logistics Meeting,
	8-10 March 1993, Williamsburg, Va.,
		American Defense Preparedness Association (1993)

Christopher Landauer, Kirstie L. Bellman,
	``The Role of Self-Referential Logics in a Software Architecture
		Using Wrappings'',
	Proceedings of ISS '93: the 3rd Irvine Software Symposium,
	30 April 1993, U.C. Irvine, California (1993)

Christopher Landauer, Kirstie L. Bellman,
	``Designing Testable, Heterogeneous Software Environments'',
	Proceedings AAAI '93 Workshop on Verification and Validation
		of Knowledge-Based Systems,
	12 July 1993, Washington, D.C. (1993)

Christopher Landauer, Kirstie L. Bellman, April Gillam,
	``Software Infrastructure for System Engineering Support'',
	Proceedings AAAI '93 Workshop on Artificial Intelligence
		for Software Engineering,
	12 July 1993, Washington, D.C. (1993)