AN OBJECT-ORIENTED GRAPHICS ANIMATION SYSTEM

ion: Entities of a system are grouped according to common properties and operations Modularization: Parts of a system that have localized behavior are grouped together with well defined interfaces In the context of object-oriented systems, these three principles complement rather than compete with each other. No compromises are required to apply all three to their limit. Object-oriented systems are characterized by abstract constructs called objects that contain data and procedures to manipulate that data. The data describe the local state of the object and are only accessible to the outside world through the object's procedures, called methods, that are executed when the object receives a message. Messages are the only means by which objects can communicate with each other, and they provide a uniform mechanism for inter-object communication. An object is created by making a copy or instance of a particular class of objects. Classes are the only abstractions of these systems. Not only do Manuscript received 3/ 13/86 they define the data structures associated with the class but also the methods for manipulating the data. These data are called instance variables. When an object is created by instancing a class, the object receives not just the data structures but also the methods to manipulate the data structures. Through the mechanism called inheritance, new classes can be created by sharing the description of other classes and changing or adding to their data and methods. A final important point: only the objects know their data structures and methods. Nothing outside the object can directly access these structures. If a new algorithm is required to do a task, the data structure may require change, but only the object itself is affected by this change. This property applies the software engineering notions of information hiding and modularity to data as well as procedures. 2.1 Prior Work One early object-oriented system was Ivan Sutherland's Sketchpad [I]. Sketchpad is a general purpose graphics system for interactive creation and editing of pictures on a graphics display. Geometric transformations were applied to master (class) definitions of objects resulting in an instance of the geometric object. Although the concept of an object-oriented system was not defined in 1963, Sutherland's user-interface had many properties in common with such systems. The Smalltalk effort [2] at Xerox's Palo Alto Research Center (PARC) is most often associated with object-oriented systems. This system uses the concepts of objects, messages, and classes to produce a programming environment and a user interface. It differs from other object-oriented systems in that it does not have any conventional typing and procedural constructs that might violate the rigorous application of objects and message passing. The only construct in the system is an object that even controls program flow. Each class has methods it uses to process messages, all of which takes place inside the objects. New classes can be defined by adding data and methods to other classes called super classes. When a message is received by a Smalltalk object and an associated method is found, it is executed; otherwise, the message is passed to the object's super class. This process proceeds until the message is either recognized or rejected. This hierarchical inheritance property allows the Smalltalk system to rely heavily on previous software and to build incremental systems without substantial software development. The Flavor System [3] of Symbolic's Lisp Machine is an implementation of objects in a dialect of Lisp. This system extends the hierarchical inheritance concepts of Smalltalk classes to allow non-hierarchical combinations of classes called flavors. When a new flavor is created, it can inherit the attributes of multiple flavors. Methods for handling messages are defined as combinations of methods from the other flavors. Conflicts can arise when two combined flavors process the same message in different ways, but the flavor concept resolves these conflicts in a uniform, prescribed manner. The Lisp Machine Window System [4] is a practical implementation of flavors. The Window System manages communication between processes and the user. The user communicates to processes through windows via a keyboard and a pointer device (mouse). Methods for windows have been classified into several flavors. For instance, all windows use the basic flavor minimum-window. It contains the minimum functionality that a window must have to behave as a window. The window flavor adds more sophistication. This flavor is the minimum-window plus methods (called mixins) to handle stream input, draw borders, draw labels, and do graphic operations. When a window is instanced, the process specifies the flavor and any initial values for internal states. The Lisp system returns an object descriptor of the particular window created. To communicate with the window, the process sends messages to the window object, the messages then prescribe a uniform syntax and semantics for object communication. For example, to draw a vector in a particular window, the process sends the message :draw-line to the window and a vector will appear. In summary, the user has complete control over the characteristics of the window and can easily communicate with multiple windows by sending messages to the appropriate objects. The cursors, menu system and keyboard are also handled via the flavor concept. 3. OBJECT-ORIENTED DESIGN The principles and properties of object-oriented systems can be applied to the software design process. Examples in the previous section illustrated implementations of object-oriented systems. In this section, the emphasis is on the design process without regard to implementation. The methodology outlined is appropriate at both the preliminary and detailed design stages of the software engineering life cycle. 3.1 Booch's Methodology Grady Booch [ 5 ] outlines one approach for designing systems for objects. His procedure consists of three steps: 1. Define the problem. This is the conventional process to describe the system to be built. Iterations with the other steps are required as new aspects of the system are discovered. 2. Develop an informal strategy. A written narration is used to describe the operations and objects of the system. 3. Formalize the strategy. Using simple rules and the narrative description of the system, identify the objects (nouns), attributes (adjectives), and operations (verbs) required. Booch uses Adam to describe the visible interfaces to each object and the explicit operations that can be applied to the objects. This process is successively applied to refinements of the system. Booch uses this methodology to solve five design problems ranging from leaf counting on trees to a heads-up display system for fighter pilots. At first glance, Booch's approach seems attractive. One just writes down a description of the system to be modeled, underlines the nouns (these become objects), then the verbs (these become operations) and translates the design into Ada. But he has not described a design methodology, only given guidelines for translating a design into an object-oriented implementation. Although his guidelines are useful for that step, moving from the problem definition step to the informal strategy is the most difficult step of the design process. 3.2 A New Methodology This section presents an object-oriented methodology that is intended to define the overall design of the system to be developed. The new method does not extract objects from the design but builds the design from abstractions of the objects themselves. Therefore, the primary effort in this approach is the definition and characterization of the abstractions. The following steps are involved: 1. Identify the data abstractions for each subsystem. These data abstractions will be the objects of the system. Often the objects correspond to physical objects within the system being modeled. If this is not the case, the use of analogies, drawn from the designer's experience on past system designs, is helpful. This is by far the most difficult step in the design process and the selection of these abstractions influences the entire system design. 2. Identify the attributes for each abstraction. The attributes become the instance variables for each object. Many times, if the objects correspond to physical objects, the required instance variables will be obvious. Other instance variables may be required to respond to requests from other objects in the system. 3. Identify the operations for each abstraction. The operations are the methods for each object. Some methods are required to access and update instance variables. Others execute operations singular to the object. The details of the methods' implementations need not be specified now, only the functionalities. Ada is a trademark of the Deparment of Defense 4. Identify the communication between objects. This step defines the messages that objects can send to each other. This protocol must be decided on by the design team. Consistency in message naming should be a primary goal. 5. Test the design with scenarios. Scenarios consisting of messages to objects are needed to test the design's ability to match the system's requirements. In fact, the designers should write a scenario of messages for each requirement in the system specification. 6. Apply inheritance where appropriate. Once some objects have been designed, common data and operations often surface. These common instance variables and methods can be combined into a class. This class may or may not have meaning as an object by itself. If its sole purpose is to collect common instance variables and methods, it is called an abstract class. This process must be repeated at each level of abstraction. Through successive refinements of the design, the designer's view of the system changes depending on the needs at the mo