Knowledge Based Software Assistant

The transformation rules that KBSA used were different than traditional rules for expert systems. Transformation rules matched against specification and implementation languages rather than against facts in the world. It was possible to specify transformations using patterns, wildcards, and recursion on both the right and left hand sides of a rule. The left hand expression would specify patterns in the existing knowledge base to search for. The right hand expression could specify a new pattern to transform the left hand side into. For example, transform a set theoretic data type into code using an Ada set library.[4]

The initial purpose for transformation rules was to refine a high level logical specification into well designed code for a specific hardware and software platform. This was inspired by early work on theorem proving and automatic programming. However, researchers at the Information Sciences Institute (ISI) developed the concept of evolution transformations.[5] Rather than transforming a specification into code an evolution transformation was meant to automate various stereotypical changes at the specification level, for example developing a new superclass by extracting various capabilities from an existing class that can be shared more generally. Evolution transformations were developed at approximately the same time as the emergence of the software patterns community and the two groups shared concepts and technology. Evolution transformations were essentially what is known as refactoring in the object-oriented software patterns community.[6]

A key concept of KBSA was that all artifacts: requirements, specifications, transformations, designs, code, process models, etc. were represented as objects in a knowledge-based repository. The original KBSA report describes what was called a Wide Spectrum Language. The requirement was for a knowledge representation framework that could support the entire life cycle: requirements, specification, and code as well as the software process itself. The core representation for the knowledge base was meant to utilize the same framework although various layers could be added to support specific presentations and implementations.

These early knowledge-base frameworks were developed primarily by ISI and Kestrel building on top of Lisp and Lisp machine environments. The Kestrel environment was eventually turned into a commercial product called Refine which was developed and supported by a spin-off company from Kestrel called Reasoning Systems Incorporated.

The Refine language and environment also proved to be applicable to the problem of software reverse engineering: taking legacy code that is critical to the business but that lacks proper documentation and using tools to analyze it and transform it to a more maintainable form. With the growing concern of the Y2K problem reverse engineering was a major business concern for many large US corporations and it was a focus area for KBSA research in the 1990s.[7][8]

There was significant interaction between the KBSA communities and the Frame language and object-oriented communities. The early KBSA knowledge-bases were implemented in object-based languages rather than object-oriented. Objects were represented as classes and sub-classes but it was not possible to define methods on the objects. In later versions of KBSA such as the Andersen Consulting Concept Demo the specification language was expanded to support message passing as well.

KBSA took a different approach than traditional expert systems when it came to how to solve problems and work with users. In the traditional expert system approach the user answers a series of interactive questions and the system provides a solution. The KBSA approach left the user in control. Where as an expert system tried to, to some extent replace and remove the need for the expert the intelligent assistant approach in KBSA sought to re-invent the process with technology. This led to a number of innovations at the user interface level.

An example of the collaboration between the object-oriented community and KBSA was the architecture used for KBSA user interfaces. KBSA systems utilized a model-view-controller (MVC) user interface. This was an idea incorporated from Smalltalk environments.[9] The MVC architecture was especially well suited to the KBSA user interface. KBSA environments featured multiple heterogeneous views of the knowledge-base. It might be useful to look at an emerging model from the standpoint of entities and relations, object interactions, class hierarchies, dataflow, and many other possible views. The MVC architecture facilitated this. With the MVC architecture the underlying model was always the knowledge base which was a meta-model description of the specification and implementation languages. When an analyst made some change via a particular diagram (e.g. added a class to the class hierarchy) that change was made at the underlying model level and the various views of the model were all automatically updated.[10]

One of the benefits of using a transformation was that many aspects of the specification and implementation could be modified at once. For small scale prototypes the resulting diagrams were simple enough that basic layout algorithms combined with reliance on users to clean up diagrams was sufficient. However, when a transformation can radically redraw models with tens or even hundreds of nodes and links the constant updating of the various views becomes a task in itself. Researchers at Andersen Consulting incorporated work from the University of Illinois on graph theory to automatically update the various views associated with the knowledge base and to generate graphs that have minimal intersection of links and also take into account domain and user specific layout constraints.

Another concept used to provide intelligent assistance was automatic text generation. Early research at ISI investigated the feasibility of extracting formal specifications from informal natural language text documents. They determined that the approach was not viable. Natural language is by nature simply too ambiguous to serve as a good format for defining a system. However, natural language generation was seen to be feasible as a way to generate textual descriptions that could be read by managers and non-technical personnel. This was especially appealing to the air force since by law they required all contractors to generate various reports that describe the system from different points of view. Researchers at ISI and later Cogentext and Andersen Consulting demonstrated the viability of the approach by using their own technology to generate the documentation required by their air force contracts.[11]