Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1997-09-11
2002-06-11
Courtenay, III, St. John (Department: 2151)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C709S241000
Reexamination Certificate
active
06405360
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to a framework being used for developing software system e.g. for a business application, said framework including a number of object oriented classes which may be processed by a computer system.
BACKGROUND
More and more, the software industry uses object oriented technology to develop software for e.g. a business application. For that purpose, object oriented classes are created so that instantiated objects of these classes are able to process the business application on a computer system. Thereby, the instantiated objects are the implementations of the classes and include programming code.
Object oriented technology has the advantage that a software developer is able to work on a specific class or object without the knowledge of the other classes or objects.
For that purpose, a class should be designed such that each instantiated object of the class is a mirror of an object in the real world. E.g., a business partner class should be designed such that each of its instantiated business partner objects relates to one real business partner and that all data concerning this real business partner should be accessible by using this business partner object.
For some time, the software industry has tried to develop standardized classes which may be used again and again for the solution of a specific problem. These classes are then taken together in a so-called framework and are used to develop software systems, e.g. for business applications. This approach has the advantage that the reusability of the developed programming code is increased.
Such frameworks may have for example two levels. In a first level, a framework provider develops general classes which may be adapted to be used in any application. Then, in a second level, a solution provider adapts this framework to a specific application, e.g. to a business application or a warehouse application and so on. This solution is finally used by e.g. an insurance company or a retail company to run its business.
Prior art frameworks often include the business partner class as a base class with one or more additional subclasses. Such subclasses may be e.g. a business partner with shipping zone subclass that adds a shipping zone attribute and a business partner with freight charge subclass that adds a freight charge attribute. As known in object oriented technology, the subclasses derive their characteristics from the base class by inheritance.
In an example, a first application may use a business partner with shipping zone object by instantiating the business partner with shipping zone subclass and a second application may use a business partner with freight charge object by instantiating the business partner with freight charge subclass. By using these objects, the first and the second application are able to process specific functions. In particular, the first application assigns a specific shipping zone to objects of its specific business partner subclass, and the second application adds a specific freight charge to objects of its specific business partner subclass.
However, if the two applications described need to share business partner objects, a problem arises. The first application expects to work with objects of its own specific subclass of business partner, i.e. the business partner with shipping zone subclass. The second application knows nothing of the business partner with shipping zone subclass and will be unable to pass its business partner objects derived from its own business partner with freight charge subclass to any interfaces provided by the first application. Thus it is impossible to share business partner objects between the two applications.
SUMMARY
It is therefore an object of the invention to provide an object oriented technology which prevents the described problem.
The invention solves this problem with a class which provides the ability that specific data may be added to its instantiated object by reference.
In particular, the invention provides an interface and a base class which implements this interface that allows specific data to be added to the objects of classes supporting the interface at runtime without the need for subclassing of the original class. Specific data added in this way to an object are referred to as properties of the object, and the interface introduced by this invention is referred to as the property container interface.
In the case of the above example, the invention only provides a business partner class that supports the property container interface but no subclasses. If an application wants to assign a shipping zone to a specific business partner, the specific data relating to the shipping zone may be added to the business partner object without creating a subclass. As well, if an application wants to calculate a freight charge for a specific business partner, the specific data relating to the freight charge may be added to the business partner object without creating a subclass. Instead, the shipping zone or the freight charge may be assigned to the specific business partner object at runtime as properties.
As well, it is possible that an application adds not only one, but several specific data to the business partner object, i.e. the specific data relating to the shipping zone, the specific data relating to the freight charge, specific data relating to an account code, and so on, without creating any subclass. Instead, these specific data may be assigned to the business partner object as properties.
This has the advantage, that all data relating to a business partner are included or referenced in the respective business partner object. The business partner class has no subclasses so that the data relating to the business partner is not partitioned into different objects. It is therefore possible that an application accesses all data relating to the business partner in the respective business partner object.
Compared to the prior art in which the business partner class is customized by creating subclasses, the invention provides the ability to customize the object of an instantiated class. This has the described advantage that only one business partner object exists for each business partner which includes or references all specific data of this business partner.
REFERENCES:
patent: 5603031 (1997-02-01), White
patent: 5613099 (1997-03-01), Erickson et al.
patent: 5623657 (1997-04-01), Conner et al.
SOMobjects Developer Toolkit Users Guide ver 2.0, IBM, Jun. 1993, p. 7-1-7-7.
Bohrer Kathy
Graser Timothy
Courtenay III St. John
Gamon Owen J.
Truelson Roy W.
LandOfFree
Property container type objects does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Property container type objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Property container type objects will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2921207