RECURSOS

Frame-based systems are closely allied to object-oriented systems. Frame- based systems evolved from artificial intelligence research, whereas OOP has its origins in more general software engineering. Frames provide a means of representing and organizing knowledge. They use some of the key features of object-orientation for organizing information, but they do not have the behaviors or methods of objects. As relations can be created between frames, they can be used to model physical or abstract connections. Just as object instances are derived from object classes, so frame instances can be derived from frame classes, taking advantage of inheritance.

Section 4.3 quoted Pascoe’s [1] definition of OOP. Frame-based systems are less rigidly defined, so a corresponding definition might be:

Frame-based systems offer data abstraction and inheritance. In general, they do not offer either encapsulation or dynamic (late) binding.

The absence of encapsulation is the key feature that distinguishes frames from objects. Since frames do not have ownership of their own functions, they are passive structures. Without encapsulation, the concept of dynamic binding becomes meaningless. This does not, however, detract from their usefulness. In fact they provide an extremely useful way of organizing data and knowledge in a knowledge-based system.

Gauge

Daemon: display Transducer

Active value: voltage

watching

The frame-based view is that an item such as my truck can be represented by a data structure, i.e., a frame instance, which we can call my_truck. This

instance can inherit from a class of frame such as Truck, which can itself inherit from a parent class such as Vehicle. Thus, frame-based systems

support data abstraction by allowing the definition of new classes. They also support inheritance between classes and from a class to its instances.

We can hang extra information onto a frame, such as the number of wheels on my truck. Thus number_of_wheels could be a slot (see

Section 4.4.3) associated with the frame instance my_truck. This slot could use the default value of 4 inherited from Vehicle or it may be a locally

defined value that overrides the default. The value associated with a slot can be a number, a description, a number range, a procedure, another frame, or anything allowed by the particular implementation. Some frame-based systems allow us to place multiple values in a slot. In such systems, the different pieces of information that we might want to associate with a slot are known as its facets . Each facet can have a value associated with it, as shown in Figure 4.16. For instance, we may wish to specify limits on the number of wheels, provide a default, or calculate a value using a function known as an access function. In this example, an access function count_wheels could calculate the number of wheels when a value is not previously known.

It was pointed out above that frame-based systems do not, in general, provide encapsulation. Consider the following example, written using the syntax of Flex, a knowledge-based and frame-based toolkit [3]:

Truck

number_of_wheels range = 4..12 value: Integer

slots facets

access function = count_wheels

length value: Real

units = metres

location value: Place

/* define a frame */ frame vehicle;

default location is garage and default number_of_wheels is 4 and default mass_in_tonnes is 1 . /* define another frame */

frame truck is a kind of vehicle; default mass_in_tonnes is 10 .

/* create an instance of frame truck */ instance my_truck is a truck .

/* create another instance of frame truck */ instance your_truck is a truck;

number_of_wheels is my_truck`s number_of_wheels + 2 .

In this example, the default number of wheels is inherited by my_truck. The number of wheels on your_truck is derived by an access function defined within the frame and which does not need to be explicitly named. The access function in your_truck makes use of a value in my_truck, though this would be forbidden under the principle of encapsulation. As the access function is not calculated until run-time, the example also demonstrates that Flex offers dynamic binding.

Frames can be applied to physical things such as trucks or abstract things such as plans or designs. A special kind of frame, known as a script, can be used to describe actions or sequences of actions. For instance, in a system for fixing plumbing faults we might construct scripts called changing_a_washer

or unblocking_a_pipe.

The term frame has been used so far here to imply a framework onto which information can be hung. However, frames are also analogous to the frames of a movie film or video tape. In associating values with the slots of a frame we are taking a snapshot of the world at a given instant. At one moment the slot location on my_truck might contain the value smallville, while sometime later it might contain the value largetown.

4.13 Summary

We began with the premise that object-oriented programming requires the following language capabilities:

• Data Abstraction: New types (classes) can be defined and a full set of operations provided for each, so that the new classes behave like built-in

ones. Operator overloading enhances this perception, since it allows the new data types to be used as though they were built-in types such as int

and float.

• Inheritance: Class definitions can be treated as specializations of other (parent) classes. This ability maximizes code reuse and minimizes duplication. OOP therefore helps us to build a world model that maps directly onto the real world. This model is expressed in terms of the classes of objects that the world manipulates, and OOP helps us to successively refine our understanding of these classes.

• Encapsulation: Data and code are bundled together into objects and are hidden from other objects. This simplifies program maintenance, helps to ensure that interactions between objects are clearly defined and predictable, and provides a realistic world model.

• Dynamic (late) binding: The object (and, hence, its class) that is associated with a given variable is not determined until run-time. Although the parent class may be specified and checked at compile-time (depending on the language), the instance used at run-time could legitimately belong to a subclass of that parent. Therefore, it cannot be known at compile-time whether the object will use methods defined within the parent class or specialized versions of them. Different objects can, therefore, respond to a single command in a way that is appropriate for those objects, and which may be different from the response of other objects. This property is known as polymorphism.

Stroustrup [4] has pointed out that although it is possible to build these capabilities in many computer languages, a language can only be described as object-oriented if it supports these features, i.e., it makes these features convenient for the programmer.

Class definitions act as templates from which multiple instances (i.e., objects) can be created. Classes and instances are easily inspected, modified, and reused. All of these capabilities assist in the construction of large, complex software systems by breaking the system down into smaller, independent, manageable chunks. The problem representation is also more natural, allowing more time to be spent designing a system and less on coding, testing, and integration.

We saw that frame-based systems support data abstraction and inheritance, but that they do not necessarily offer encapsulation or dynamic binding. As a result, frames are passive in the sense that, like entries in a database, they do

not perform any tasks themselves. Their ability to calculate values for slots through access functions might be regarded as an exception to this generality. Although frames are more limited than a fully fledged object-oriented system, they nonetheless provide a useful way of organizing and managing knowledge in a knowledge-based system.

References

1. Pascoe, G. A., “Elements of object-oriented programming,” Byte, pp. 139– 144, August 1986.

2. Booch, G., Rumbaugh, J., and Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley, 1999.

3. Vasey, P., Westwood, D., and Johns, N., Flex Reference Manual, Logic Programming Associates Ltd., 1996.

4. Stroustrup, B., “What is object-oriented programming?” IEEE Software, pp. 10–20, May 1988.

Further reading

• Booch, G., Object-Oriented Analysis and Design with Applications, 2nd ed., Addison-Wesley, 1994.

• Budd, T., An Introduction to Object-Oriented Programming, 2nd ed., Addison-Wesley, 1996.

• Cox, B. and Novobilski, A., Object-Oriented Programming: an evolutionary approach, 2nd ed., Addison-Wesley, 1991.

• Goldberg, A. and Robson, D., Smalltalk-80: the language, Addison- Wesley, 1989.

• Lalonde, W. R., Discovering Smalltalk, Addison-Wesley, 1994.

• Meyer, B., Object-Oriented Software Construction, 2nd ed., Prentice-Hall, 1997.

• Mullin, M., Object-Oriented Program Design, with Examples in C++, Addison-Wesley, 1989.

• Stevens, P. and Pooley, R., Using UML: software engineering with objects and components, Addison-Wesley, 2000.

• Stroustrop, B., The C++ Programming Language, 3rd ed., Addison- Wesley, 1997.

• Touretzky, D. S., The Mathematics of Inheritance Systems, Pitman/Morgan Kaufmann, 1986.