Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-01-28
2003-03-18
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000
Reexamination Certificate
active
06536033
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to Computer Aided Software Engineering (CASE) and, more particularly, to a uniform mechanism for building containment hierarchies.
2. Background Description
Object oriented programming (OOP) is the preferred environment for building user-friendly, intelligent computer software. Key elements of OOP are data encapsulation, inheritance and polymorphism. These elements may be used to generate a graphical user interface (GUI), typically characterized by a windowing environment having icons, mouse cursors and menus. While these three key elements are common to OOP languages, most OOP languages implement the three key elements differently.
Examples of OOP languages are Smalltalk, Object Pascal and C++. Smalltalk is actually more than a language; it might more accurately be characterized as a programming environment. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. In Smalltalk, a message is sent to an object to evaluate the object itself. Messages perform a task similar to that of function calls in conventional programming languages. The programmer does not need to be concerned with the type of data; rather, the programmer need only be concerned with creating the right order of a message and using the right message. Object Pascal is the language used for Apple's Macintosh® computers. Apple developed Object Pascal with the collaboration of Niklaus Wirth, the designer of Pascal. C++ was developed by Bjarne Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of C. The key concept of C++ is class, which is a user-defined type. Classes provide object oriented programming features. C++ modules are compatible with C modules and can be linked freely so that existing C libraries may be used with C++ programs. The most widely used object based and object oriented programming languages trace their heritage to Simula developed in the 1960s by O-J. Dahl, B. Myhrhaug and K. Nygard of Norway. Further information on the subject of OOP may be had by reference to Object Oriented Design with Applications by Grady Booch, The Benjamin/Cummings Publishing Co., Inc., Redwood City, Calif. (1991).
Rapid Application Design (RAD) tools, such as Microsoft's Visual Basic, offer a way to produce a software application in a relatively short period of time. Typically, RAD tools are used to generate the “look and feel” of an application, but the code generated by these tools are generally slow in execution. Therefore, many software houses prototype the Graphic User Interface (GUI) of their applications in a RAD tool and then implement the application in C++.
Despite the benefits of object-oriented program development, implementing large applications in, for example, C++ can be expensive. One approach to reducing the cost is to reuse object implementations. Object Oriented Programming (OOP) languages provide some degree of reuse. OOP is about describing how objects interact with one another. Component Object Programming (COP) is designed to produce reusable units of software. COP use building blocks for constructing custom software. Unlike OOP objects, COP hides details above the object-interaction level. There is no inheritance between components, although the objects that make up the component may inherit behavior from other objects, possibly in other components. In other words, when using a component, the inner workings of that component are oblivious to the application using the component. The component always appears as a single interface which formalizes properties, events and behavior. As a result of its well defined interface, a component may be easily reused. Components are to software what integrated circuits (ICs) are to electronics; they encapsulate function and provide services based on a strict specification of their interface. For example, a spell-check component encapsulates the minimum knowledge to completely perform its task. Thus, by combining components, large software applications can be built.
An advantage of COP is an additional level of modularity on top of what OOP already offers. Instead of thinking about how any one given object interacts with another object, the focus is on how entire sets of functionalities interact. OOP does not encapsulate groups of classes and objects. COP hides the information at the class level. Sun Microsystems'JavaBeans is a component architecture for the cross-platform Java programming language.
Creating hierarchical containment structures is a common programming operation. For example, components are placed inside a Java object called a container. A dialog box in Java is made up of the surrounding container and the components within it needed to make the dialog box useable, such as a text field and at least one button. In current technology, the mechanisms used to create hierarchies are very much tied to the specific object types which are being composed and the operations they support. Unfortunately, this approach does not lend itself to a generalized view of containment and consequently to a generalized implementation of containment that can support arbitrary object types.
To illustrate this point, consider how user interfaces use containment for layout management. Windows may contain panels which, in turn, have other panels, buttons, text fields, etc. whose containment hierarchy defines the visual layout. Other natural examples are:
the members of a set are contained in the set,
the keys and values in a hash table are contained in the hash table,
the elements of a vector are contained in the vector, and
hierarchical data structures such as trees where child nodes are contained in parent nodes.
In each of these examples, the mechanism of how the containment creation is requested is different. For example,
Certain Java AWT components use the form:
parent.add (child)
Certain Java swing components use the form:
parent.getContentPane( ). add(child)
Java swing Tab components use the form:
parent.addTab(child, . . . )
Java Hashtables use the form:
table.put(key,value)
Java Vectors use the form:
vector.addElement(element)
Java Stacks use the form:
parent.pushChild(child)
XMLs DOM uses the form:
parent.appendChild(child)
Today, the details of how to actually add a containee to a container is encapsulated within each of these mechanisms.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to unify how containment is requested as well as a syntax which insulates the user from having to know how each type of component implements its containment creation request.
According to the invention, there is provided a uniform mechanism for building containment hierarchies by separating the code/method which actually perform the containment insertion operations on the components from the specification of the containment and then by providing an automatic way of obtaining and executing that code when containment hierarchies need to be created. The invention consists of
an abstract syntax for describing the containment relationships,
a processing mechanism for creating the containment mechanism, and
a registry containing the mechanisms for implementing specific containment policies.
Having this abstraction allows an application programmer to be able to construct hierarchies of objects without having to be concerned about the specific details of how that containment is performed. In fact, the details may be deferred until run-time (and even downloaded from elsewhere on the network). Also, having this abstraction significantly simplifies automatic generation of object hierarchy codes, both from the point of view its implementation as well as that of the code that is generated.
REFERENCES:
patent: 5206951 (1993-04-01), Khoyi et al.
patent: 5544302 (1996-08-01), Nguyen
patent: 5581686 (1996-12-01), Koppolu et al.
patent: 5625818 (1997-04-01), Zarmer et al.
patent: 5787425 (1998-07-01), Bigus
patent:
Epstein David A.
Weerawarana Sanjiva
Das Chameli C.
International Business Machines Corp.
Kaufman Stephen C.
McGuireWoods LLP
Powell Mark R.
LandOfFree
Uniform mechanism for building containment hierarchies does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Uniform mechanism for building containment hierarchies, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Uniform mechanism for building containment hierarchies will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3068761