Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1997-04-25
2001-05-08
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000
Reexamination Certificate
active
06230309
ABSTRACT:
FIELD OF THE INVENTION
This application relates to object-based computer systems and applications, and in particular to the automatic generation and management of object-based computer system applications.
BACKGROUND OF THE INVENTION
Description of the Prior Art
Object-based computing systems, in particular distributed object computing systems, are increasingly being adopted as an effective means of enabling business information systems to respond more rapidly to changes in business needs. This is achieved today by making available programs and sub-programs as components in an object-based computing system, and manually configuring those components into applications.
Increasingly powerful desktop computers can provide graphical human-computer interfaces for access to applications modelled on the real world. Business information applications running on the desktop computers typically need to collaborate with programs running on shared ‘server’ computers. The server computers may be microprocessor-based systems, or alternatively minicomputer or mainframe computer systems.
The advent of object-based computing systems provides a possibility for reusability of components in complex applications like business information applications. Before the use of object-based systems, complex applications were typically based on purpose-built collections of cooperating modules or components which were constructed with little thought to their reusability.
The use of proprietary protocols for messages exchanged between components and the lack of standards for describing the format and meaning of arguments passed between the components typically meant that components were poorly optimised for reuse. The result of the poor optimisation for reuse is that the creation of new applications built of such components takes considerable time due to the necessity to create the “glue” for connecting those components.
There is considerable pressure on application developers to reduce the application development cycle time from the identification of needs to the delivery of a solution. Assembling applications from reusable components offers the potential to reduce this cycle time.
A number of proprietary computing environments and systems allow components to be made available as “black boxes” to the rest of the computing environment. Examples of this are the Object Linking and Embedding (OLE) environment from Microsoft Corporation (OLE is a trademark of Microsoft Corporation), the Distributed System Object Model (DSOM) environment from IBM Corporation, the Common Object Request Broker Architecture (CORBA) specification managed by the Object Management Group (OMG) and the Arranger environment from Texas Instruments Software. Details of the OLE environment can be found in “Inside OLE”, 2nd Edition by K Brockschmidt published in 1995 by Microsoft Press ISBN 1-55615-843-2. Details of CORBA can be found in “CORBA Services: Common Object Server Specification”, Revised Edition, Mar. 31, 1995, OMG Document Number 95-3-31.
The environmental system provides a standard way to define a component so that other components or applications within the computing environment may be assembled to use the services (or features) of any other component. A component is defined here as an executable module which implements a useful, clearly defined unit of functionality and provides a well defined interface such that the details of its underlying implementation are not visible externally. A component may be used a part of another component, used in the provision of applications, or used directly by the end user of the computing environment.
FIG. 1
of the accompanying drawings shows an example of an application
10
assembled from two components
12
and
14
. A first component
12
supplies a list of customers and the second component provides a list of orders for a particular customer. To build this application, the designer needs to find the desired components, represent the desired components in a user interface and provide a way for a chosen customer from the customer component
12
to be supplied to the list order service of the order component
14
.
As mentioned above, a mechanism for providing support for the concept of a component in such environments is the use of an object-oriented model. Under this model, objects implement components and the operations of an object implement the services of a component. Thus the process of assembling components is actually achieved through the use of objects and their operations.
The Arranger product mentioned above provided a significant step towards a reduction in application development cycle times by providing an infrastructure for supplying components ready for assembly. However, the process of assembling components into end applications remains a largely manual process. As has been illustrated with reference to
FIG. 1
, the application designer needs to:
identify the components of interest;
write program code that defines how each component will be used by the application including describing how information received from one component will be used by another component; and
represent information from components to the end user of the application through the use of software routines and the provision of a graphical user interface.
In the object-oriented model, objects provide access to objects via units of software functionality, usually referred to as operations or methods. An operation is generally thought of as having two parts, namely an external definition and an internal implementation.
The internal implementation is specified as algorithms or rules and turned into an executing unit via suitable tools. The algorithm may act on the particular object to which the operation belongs and may also invoke any operation of any other object within the scope of the system, subject to any constraints of the system.
However, to a client which requires access to a component object, the internal implementation is of little interest. Indeed, it is often only physically present in the computing environment as compiled computer code. In contrast, a client which requires access to an operation would have at least some part of the external definition of the operation available. The mechanism varies with the object system, but at some level it is possible to discover how the operation is invoked and what it does.
The external definition of an operation, of a specific object, may also include the object to which it applies, and may also include a number of additional parameters or argument definitions. Typically, the parameters are defined in the formal syntax of the object system. Other defined information may also be available such as non-formal descriptions of the parameters, formal and non-formal descriptions of the operation, formal and non-formal precondition information.
FIG. 2
of the accompanying drawings is a schematic representation of this.
Parameters define elements which will either be used (inputs), returned (outputs), or used and returned (inputs and outputs) by the operation. In general, the definition of parameters is limited only by the scope of the system, i.e, a parameter can potentially be any object or data type value within the scope of the system.
For example, suppose an operation to return information about the “Orders a Customer has Placed” is required. This could be defined as an operation called, say “List Orders for Customer”, for which the customer is a required input parameter, and for which outputs include a list of orders, a count of the total number of orders and the last order fulfilled.
FIG. 3
of the accompanying drawings is a schematic representation of this.
To carry out some user task or function in an application which utilises a component object system, the use of one or more operations is required, often from different objects (components). In most cases, for the task to be achieved, information output by one operation is required as input to another operation to achieve some overall effect. For example, with reference to
FIG. 4
of the accompanying d
Gibson William E.
Hogan Patrick M.
Turner Stephen J.
Baker & Botts L.L.P.
Khatri Anil
Powell Mark R.
Sterling Software, Inc
LandOfFree
Method and system for assembling and utilizing components in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for assembling and utilizing components in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for assembling and utilizing components in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2569677