Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-12-22
2001-12-18
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000
Reexamination Certificate
active
06332210
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer software, and particularly to methods of creating software components that can be used in different systems with minimal modification.
2. Description of the Related Art
Creating and debugging software code has been and continues to be a very labor-intensive and expensive process. As a result, efforts have been made on many fronts to create “re-usable” code; i.e., code that can function as designed—without modification—in a variety of systems, thereby minimizing the amount of new code that must be created for a given system. As used herein, a “system” refers to software designed for a particular application.
“Object-oriented programming” (OOP) is one technique that facilitates the re-usability of software code. OOP produces application programs that are very modular, and the resulting modules of code can presumably be plugged into other applications. This presumption generally proves to be true for lower level objects, such as an abstract data structure. However, OOP techniques do not necessarily lead to good re-usability for higher level objects. For example, an “aircraft track” object that maintains the speed and altitude of an aircraft may be difficult to re-use, because the actions taken as a result of the data received by the object are dependent on the specific system in which it is employed. The object might be found, for example, in a civilian air traffic control system or a military command and control system, with different reactions required for the same input data. These responsive actions are system-specific and are typically embedded in the object, making them unsuitable for use in a different system.
An illustration of this problem using a fictitious air defense system is shown in
FIG. 1
a,
which is an “event trace diagram” for such a system. This system is implemented using OOP techniques, with the objects involved in the handling of a new radar report, such as “Radar”, “Air Track”, “Flying Object”, etc. shown across the top of the diagram. “Events”, which cause the control of the program to be passed from one object to another, are shown below the objects.
A typical system event trace starts with a “Radar” object
10
receiving a new report, which it relays to the “Air Track” object
12
; i.e., the “event”
14
of “Radar” receiving a new report is the stimulus that causes program control to be transferred to “Air Track”. “Air Track”
12
sends control to the “Flying Object” object
16
, which recognizes the track as a potentially hostile aircraft and transfers control to the “Enemy Aircraft” object
18
. “Enemy Aircraft” evaluates the threat, and transfers control to the “Threat” object
20
as a result. “Threat” creates a report, and the report and program control are sent to the “Battle Manager” object
22
. “Battle Manager” interacts with other objects, with control ultimately transferred to an “Interceptor” object
24
. The “Battle Manager” object also reports status to a “Higher Echelon” object
26
.
Using conventional OOP techniques, the control sequences needed to execute the event trace in
FIG. 1
a
are built directly into the objects, i.e., “Radar” will call “Air Track”, which will call “Flying Object”, and so on. However, by so doing, the re-usability of these objects is compromised, because in a different system, the event trace for dealing with a new radar report may be quite different. This is illustrated in
FIG. 1
b
. This different air defense system requires objects having functions similar to those in the
FIG. 1
a
system, but the event traces are different. Here, the “Air Track” object
32
sends track reports directly to the “Higher Echelon” object
34
, and the “Battle Manager” object
36
is invoked by the “Higher Echelon” object. To re-use the original “Air Track” or “Battle Manager” objects (
12
,
22
) in the new system, the control sequences encoded within those objects must be replaced with new ones that will implement the new event traces. Thus, these objects are “re-usable” only after modification, with the modification process repeated each time the object is to be re-used in a new system.
Efforts have been made to isolate the program control tasks from a system's functions. For example, Hatley and Pirbhai,
Strategies for Real
-
Time System Specification,
Dorset House Publishing (1988), pp. 59-72, and Ward and Mellor,
Structured Development for Real
-
Time Systems,
Yourdon Press (1985), pp. 41-70, discuss the concept of a “controller” that handles program control. However, both of these describe systems designed using functional approaches using structured analysis and structured design, which results in a system architecture that is organized by the specific functions the system has to provide. Unfortunately, the software components created using these approaches remain closely tied to the specific application systems for which they were originally designed, making them difficult to re-use in other systems.
SUMMARY OF THE INVENTION
A method of creating and using system-independent software components is presented, with the resulting code being re-usable in a variety of systems with little to no modification
The novel process is used to develop OOP-based systems. A high level of re-usability is achieved by using a design scheme that results in three types of software components: “core” objects, “view manager” objects, and “controller” objects. The core objects embody the essential behavior required by an application, i.e., its core functionalities, and the controller objects represent the control behavior of the underlying system. Separating the core functionalities from the control behavior enables the resulting system-independent core objects to be re-used in different systems.
The view manager objects are used to allow a “server” core object communicate with multiple “client” core objects without creating permanent communication links between the server object and the client objects. The view manager objects also enable a server object to automatically notify all of its client objects whenever there is a state change within the server object. The use of view manager objects further enhances the re-usability of core objects.
Once separated, a system's control behavior is embodied in one or more “control objects”, which invoke the operation of various core objects as needed to execute a particular event trace. Because the control objects handle the program flow, the core objects can be re-used in other applications—with little to no modification—by merely modifying the associated control object to accommodate the system-specific event traces.
The inventive concept can be scaled up or down. Thus, a control object can be a “segment controller”, controlling the program flow among a group of core objects identified as a “segment” and which perform a higher-level system function, or a “core object controller” which serves the same purpose for a group of lower-level objects which, in combination, make up a core object.
Further features and advantages of the invention will be apparent to those skilled in the art from the following detailed description, taken together with the accompanying drawings.
REFERENCES:
patent: 5724589 (1998-03-01), Wold
patent: 5872971 (1999-02-01), Knapman et al.
patent: 5936860 (1999-08-01), Arnold et al.
patent: 6016495 (2000-01-01), McKeehan et al.
Rumbaugh et al., Object-oriented Modeling and Design, Prentice-Hall, Inc., Nov. 1990.*
Jacobson, Object-oriented Development in an Industrial Environment, OOPSLA 87 Proceedings, Oct. 1987.*
Eriksson-Penker, UML Toolkit, Chapter 6, Advanced Dynamic Modeling: Real-Time Systems, Wiley, Oct. 1997.*
Booch-Rumbaugh-Jacobson, The Unified Modeling Language User Guide, Chapter 16, Use Cases, Addison-Wesley, Oct. 1998.*
Batory-O'Malley, The Design and Implementation of Hierarchical Software Systems with Reusable Components, ACM Transactions on Software Engineering and Methodology, vol. 1, No. 4, pp. 355-398, Nov. 1990.*
Hatley et al., Strategies for
Barkataki Shan
Dousette Patricia J.
Frederick Dale F.
Harte Stuart H.
Johnson Gary R.
Koppel & Jacobs
Litton Systems Inc.
Nguyen-Ba Hoang-Vu Antony
Powell Mark R.
LandOfFree
Method of creating and using system-independent software... 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 of creating and using system-independent software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of creating and using system-independent software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2588717