Why Should We Care?

Why should we look to the powerful tools of object oriented design and other complex programming paradigms at all? We can give a partial answer that stems from our own interests in the use of neurobiological models to develop a variety of computational processes that are capable of learning on their own. Hence, in this document, we attempt to put down on paper our current thoughts on what is to us a fairly ambitious development project for adaptive control. For some time now, we have been interested in developing an environment that allows us to do rapid prototyping of algorithm designs for the control of nonlinear systems using on-line information obtained from sensors in a real-time frame. This requires that we build models of the state and the performance of our system and then use those models to estimate the next time steps control action. This endeavor can be quite mathematical and the implementation of these mathematical ideas into a robust set of software tools is equally daunting. In addition, we have focused on models that are built using function approximation techniques that are loosely based on rather simplistic models of animal neurophysiology-the so-called artificial neural architectures.

We have always believed that we could do much better if we could find the right abstraction of the wealth of neurobiological detail that is available; the right design to guide us in the development of our software environment. Indeed, we feel very strongly that there are three distinct and equally important areas that must be jointly investigated, understood and synthesized for us to make major progress in these areas. We refer to this as the SWH triangle, Figure 1.1;

  

Figure 1.1: Software-Hardware-Wetware Triangle

we use the term wetware to indicate things that are of neurobiological scope. We use double-edged arrows to indicate that ideas from these disciplines can both enhance and modify ideas from the others. The labels on the edges indicate possible intellectual pathways we can travel upon in our quest for unification and synthesis: ANALOG VLSI is an almost classical chip building strategy which in conjunction with the VHDL layout language provides us with a means to take neurobiological information and implement it on a silicon substrate; hardware and software of the kinds we envision are typically event driven ( and we will have much more to say about that issue); and abstraction is the principle tool that we can use to move back and forth in the two fertile grounds of neurobiology and software.

Our current software implementation has required us to attempt to master many new concepts in software engineering. An annotated list (never complete and always changing) takes the form:

Object Oriented Design:

We have purposely chosen to use the C+ + programming language to implement our object oriented ideas. There were several reasons for this:

1.

The language is readily available at almost all sites and to use our software only requires a robust compiler such as SUNPRO or gnu. These compilers are either bundled with the workstation or available at no cost.

2.

The C+ + language works reasonably well using the somewhat clumsy X Windows/ Motif Widgets Graphical User Interface to provide our visualization tools. Our software environment must provide a rich suite of visualization aids. A new option here is to use the C+ + Graphical User Interface or GUI called V written by Bruce Wampler. This has been investigated via a semester long project by Brian Kamery during Spring 1997.

Graphical User Interfaces:

Our choice of the standard X Windows/ Motif Widget set was based on availability. This GUI is bundled into the Solaris 2.5 operating system. We have always known that visualization tools were very important, but it was never clear which method we should use in the development process. However, the large installed base of this system made us confident that whatever we did create in this area, would be useable by many others in a relatively painless way. Further, to program well in X Windows and Motif Widgets made us learn several important underlying concepts:

1.

Client-Server Architecture Ideas; specifically, the notion of programming within an asynchronous event based architecture. This is having a profound affect on our thinking.

2.

The User Interface is NOT a quick add-on at the end of the programming effort. It requires as much intellectual effort as anything else in the development process.

Mutable Software Architectures:

Our studies of neurobiological structure and our attempts at finding a reasonable core set of abstractions from neurobiology as guidelines for our software design convince us that our design must possess sufficient plasticity to be able to respond to environmental signals via structural modification. Currently, we can provide some measure of plasticity via what is called polymorphism and dynamic binding. If an object is typed at compile-time, it is called a statically bound object; however, if its type is bound during the running of the program (that is, at construction time within a function call), it is called dynamically bound. Dynamically bound objects give us some ability to alter the structure of our software architecture at run-time, but within C+ +, it is really not possible to obtain type information of objects or do other things at the class level. For a nice discussion of these ideas, see [Eliens, 11]. The ability to dynamically alter software constructions at the class level requires what is called metaclass information and tools. This also implies a means of communication between objects at a very high level-one such tool for doing this is to use what are called agents.

Hence, we are inevitably being driven to several cutting edge ideas:

1.

MetaClass Capability

2.

MetaObject Protocols, where a software environment can be built and altered via traditional programming and can also be changed at the structural level.

3.

Message passing between existing objects that requires an overseer system of some sort to coordinate and make decisions. A typical event-based message system that may be useful for our needs is the relatively new field of intelligent software agents. Agents are essentially more controlled versions of what are also known as computer viruses. These software constructions may play the role of hormones in our extended software environment for control.

Now to the organization of this work. First, this work has been (and is continuing to be) very difficult to write. Since this document pulls in threads from neurobiology, mathematics and fairly advanced software engineering, the resulting tapestry is a bit hard for the uninitiated to view. It seems very awkward and virtually impossible to write this material in a completely tutorial way. No matter where we start, there are questions left unresolved and unanswered until later sections. So, upfront, we wish to offer our sincere apologies to you the reader for our inability to structure this explanation as well as we would like. However, with that said, here are the threads we need to discuss and then combine:

Dynamic Binding:

We are attempting to illustrate the notion of dynamic binding by example. We have written up two separate sample classes with inheritance. We then show how dynamic binding can be used to help us implement dynamic modification of an application's software architecture. The problem is that both examples are quite fragmentary. The first example is an old and tried class of SHAPE objects, such as triangles and boxes. That is straightforward, but our use of dynamic binding is within the context of an associated X Windows/ Motif Widget GUI and we make no attempt to explain all of the underlying details. Hence, we use terms such as client-data and callback function and so forth with little warning. The second example uses dynamically bound objects as arguments to the constructor of a particular type of neural architecture called a CMAC. Again, the full explanation of a CMAC is not given (as it is readily available elsewhere, [Peterson,  25]) and only the barest bones of the dynamic binding of the objects into the CMAC constructor are mentioned.

Also, one of the problems we have had with dynamic binding and polymorphism is that the treatments we find in basic books on C+ + programming are just not technical enough. We find it helpful to understand how a compiler implements such things; for example, a thing called the virtual function table needs to be built at compile time for both simple inheritance and complex inheritance trees. It has been most helpful to find a book which talks about the details of implementing an object-oriented compiler; we heartily recommend [Wilhem, 32]. Our understanding of these issues has been helped enormously by many conversations with Kelly Waters during the process of a funded research effort into Object Persistence during Spring 1997.

Neurobiological Structure:

There is so much to say here. We focus on the notion of information processing within neural systems and show our attempts to abstract out of this knowledge, prototypical software constructs. We discuss rather completely the catecholamine neurotransmitter family and what it has to say about how we should build a core class of computational object called an IOMAP. The problem is that within all of these discussions, we freely use both neurobiological and software engineering language. They are intertwined completely and we are somewhat at a loss as to how to present it differently. After all, we want to show how to pull specific neurobiological detail into software implementation.

Software Implementation;

There must be a lot of detail here, but it is still essentially at best code fragments. We must, of necessity, assume both software engineering and object oriented design maturity.

Unfortunately, as we have tried to show, all of the aforementioned items are very nicely (or very horribly!) intertwined (it depends on your point of view!). We hope that you the reader will persevere. As you have noticed, our style in this report is to use the ``royal'' we rather than any sort of third person narrative. We have always felt that this should be interpreted as the author asking the reader to explore the material with the author. To this end, the text is liberally sprinkled with you to encourage this point of view. Please take an active role!