Dynamic Objects Features Make Allegro CL Ideal for Knowledge-Based Applications

November 1997


In the article Knowledge-Based Application Development with Dynamic Objects Technology (October 1997) we introduced a new series of articles on the topic of knowledge-based applications. We talked about what kind of applications are included in this category, how they are being integrated into multi-tier client-server computing architectures, and how Allegro CL has become the "tool of choice" for development of knowledge-based systems.

This month, we continue this new series with a discussion of some of the Dynamic Objects features which make Allegro CL ideal for the development of knowledge-based applications.

Dynamic Objects and Knowledge-Based Applications
As we discussed last month, Dynamic Objects systems like Allegro CL have a long history of being the "tool of choice" for developing knowledge-based applications.

Beginning in the late 1970's, continuing throughout the heyday of artificial intelligence (AI) technology in the 1980's, and carrying through to the current "renaissance" of knowledge systems in corporate computing worldwide, Dynamic Object systems such as CLOS and Common Lisp (CL) have been the natural choice for application development involving symbolic computation, inference, and other knowledge-based programming techniques.

Allegro CL is the world's most widely used Dynamic Objects system, and is one of the most popular development environments for building knowledge-based applications ranging from intelligent software agents, to expert systems, to knowledge-based engineering applications.

There are several reasons behind this trend. Dynamic Objects systems offer a number of important features pertaining to knowledge-based systems development that make them ideal for this kind of project. This month, we'll take a look at one of these key features: Allegro CL's runtime extensibility.

Dynamic Objects and Runtime Extensibility
Allegro CL's Dynamic Objects technology enables applications to evolve after deployment, without source code recompilation. New objects, new classes and new behavior can be added on the fly. Even the structure of the object system itself can be changed in a running application.

How do Dynamic Object systems achieve the magic of incremental change? These systems use an additional level of abstraction called meta-data which describes the class hierarchy, objects and methods. This meta-data is maintained at runtime, so that changes made to class definitions while the system is running, such as adding or deleting data members, cause the meta-data, not the objects themselves, to be updated.

Whenever an object is accessed, it is first checked to ensure the meta-data describing it is current. If not, the object updates itself to conform to its new definition as described by the updated meta-data, and then normal processing resumes.

The change is incremental, and the application "pays" for the update only once per object access. This ensures the highest performance while retaining scalability. Moreover, this lazy evaluation technique ensures that even applications with millions of objects get their objects updated only on an as-needed basis. In this way, the benefits of incremental change can be retained even in very large applications.

Building similarly modifiable applications in static object languages such as C++ would clearly be much more difficult. See our article comparing C++ and CLOS.

By exposing a framework by which end users can manipulate and flexibly add functionality to the application on-the-fly, Dynamic Objects applications become customizable and configurable to a degree which cannot be approached by other technologies.

An Example of Runtime Extensibility
The following diagram shows part of a simple object hierarchy for an industrial design application, where the Part class is being modified at runtime by the user.

Runtime Diagram

In industrial design systems, knowledge is encoded into the system using an attribute grammar: objects are assigned various properties. Properties of objects are often defined as expressions involving other objects. For example, the length property might be calculated by summing the length properties of other subcomponents.

In the diagram above, the length property is modified at runtime by the user. This causes the meta-data for the object system to be updated for all other properties calculated using the value in length. Whenever an object is accessed which has a property reliant upon that value, an object update takes place.

A great deal of flexibility is required in representing this kind of knowledge. As a user adds new types of objects to the knowledge base, the system must create new classes. It must also remember the dependencies of classes and subclasses, so that when changes are made to various objects, these changes can be automatically propagated throughout the entire system, to all of the subclasses that inherit behavior from the modified objects.

The dynamic redefinition of classes and their attributes must gracefully allow other objects dependent on these classes to redefine themselves as well. All of this must occur in real time, without bringing the system to a halt.

This kind of real-time dynamic behavior, so critical to knowledge-based applications such as the industrial design system presented in the example, is feasible only with Dynamic Objects technology. The capability to runtime-extend and reconfigure knowledge very efficiently is the primary reason why Dynamic Object systems such as Allegro CL remain pre-eminent in advanced knowledge-based systems development today.

With the next article, The Meta-Object Protocol and Knowledge-Based Systems (December 1997), we'll continue our discussion of Dynamic Objects features pertinent to knowledge-based application development with a look at the Meta-Object Protocol of Allegro CL.

Copyright © 2023 Franz Inc., All Rights Reserved | Privacy Statement Twitter