Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
1999-10-22
2002-08-27
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S127000
Reexamination Certificate
active
06442750
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to designing software applications, and more particularly to an aspect-oriented programming implementation for designing by contract.
BACKGROUND OF THE INVENTION
Modem software program are large and complex creations, often created by teams of developers. Because of the collaborative nature of software development, incompatible program modules commonly result, and debugging is required to resolve these differences. However, as is often the case, the resources expended in debugging a software program can rival those required to create the software program in the first place.
This situation can be avoided by not creating the incompatibilities in the first place. This may be done through Design by Contract. Design by Contract is a design methodology in which every program module designed states very explicitly and clearly the preconditions for using that module correctly and the postconditions that module guarantees. The benefit of stating these up front is that bugs in the implementation may be detected more quickly because the preconditions and postconditions may be checked at runtime. Reliability is built into the software program so no debugging is necessary later.
This methodology is referred to as Design by Contract because it acts in a way that mirrors human contracts. In essence, a program offers to provide something in exchange for something else. More specifically, the program module guarantees that certain postconditions will be satisfied if the caller satisfies certain preconditions.
For instance, if a precondition is violated, then the software calling the module is doing something wrong. If, on the other hand, a postcondition is violated, then an error exists in the implementation of the module.
Design by Contract is typically used during the development of software, but when the final product is ready for shipment, the preconditions and postconditions are removed to improve performance. By defining preconditions and postconditions, a routine and its callers may be bound in a contract. In other words, if a caller promises to call a routine with the preconditions satisfied, then the routine promises to deliver a final state in which the postconditions are satisfied. With this convention programming style is considerably simplified because by having the constraints which calls to a routine must observe specified as preconditions, the developer may assume when writing the routine body that the constraints are satisfied, and does not need to test for them in the body.
So if a square root function, meant to produce a real number as a result, is of the form
sqrt (x: REAL): REAL is
—Square root of x
require
x>=0
do . . . end
the developer may write the algorithm for computing the square root without any concern for the case in which x is negative because this is taken care of by the precondition and becomes the responsibility of the clients.
While conventional programming wisdom would suggest that in order to create reliable software every component of the system should be designed so that it protects itself as much as possible, such as by providing checks, under the theory that while a redundant check may not help, at least it won't hurt.
However, the “at least it won't hurt” theory ignores the cost of computing. Redundant checks imply a performance penalty because the checks must be executed. If the checks are used, then they must be later removed to remove the performance penalty.
With Design by Contract, the checks are no longer needed because of the guarantee that for every interaction between two elements there is an explicit roster of mutual obligations and benefits, i.e., the contract. The contract specifies which party is responsible for the enforcement of each specified condition that could jeopardize a routine's proper functioning.
If the caller is to be responsible for enforcement of a particular condition, the condition is specified as a precondition of the routine. If the routine is to be responsible, then the condition will be expressed as a conditional instruction, or some functional equivalent, in the body of the routine.
A programming language called Eiffel was created to facilitate Design by Contract. Eiffel provides built-in features to support the implementation of Design by Contract. The example below illustrates those features. The following example shows a partial implementation of a bounded queue, with methods put and remove. The pre- and post-conditions for those methods are coded explicitly with the “require” and “ensure” features of Eiffel.
class BoundedQueue[G] feature
put(x:G) is
-- add x as newest element
require
not full
do
-- implementation of put
. . .
ensure
not empty
end;
remove is
-- remove oldest element
require
not empty
do
-- implementation of remove
. . .
ensure
not full
end;
empty: BOOLEAN is
-- is the queue empty?
do Result:=. . . end;
full: BOOLEAN is
-- is the queue full?
do Result:=. . . end;
end
The assertions are checked at run-time. This checking can be turned on or off as a result of a compilation switch.
Design by Contract and the Eiffel programming language are described in more detail in Bertrand Meyer, Object-Oriented Software Construction, 2/e, Prentice-Hall PTR, 1997, which is hereby incorporated by reference.
In most traditional programming languages, Design by Contract is implemented by intertwining the implementation of the preconditions and postconditions with the implementation of the modules, such as in Table 1, which will be described in greater detail below.
With aspect-oriented programming, the implementations of the preconditions and postconditions may be extracted into aspects, so that they are easier to plug in and unplug from the program module being developed.
Traditional programming languages typically work well for design decisions that define a unit of functionality, such as a procedure or an object. Procedural languages such as for Fortran, Pascal, and C are useful for defining programs where the execution is straightforward, beginning at a starting point and executing in a stepwise manner to an end. In this model, design issues can be addressed by units of contiguous program execution. Deviations from the straightforward path are provided by function calls which allow program execution to jump from the main routine to the subroutine, and back again to the main routine. The use of subroutines allows for programming efficiency for implementing common routines; however, with programs becoming increasingly more complicated, and the number of common routines also growing, programs written in procedural languages are becoming increasingly complicated and difficult to maintain.
With modem computer programs becoming increasingly long and complex creations which may have many millions of lines of code, the concept of modularity is becoming increasingly important in the development of software. With a modular approach, the various functions of a computer program may be separated into modules which various programmers can work on independently. One popular programming paradigm that embodies the concept of modularity is that of object-oriented programming (OOP).
The central idea behind object-oriented programming is the object model, where all programs are structured as collections of interrelated objects, each of which represents an instance of some class in a hierarchy of object classes.
Object-oriented programming involves defining, creating, using, and reusing “objects,” which can be used to model ideas and things in terms of their features (data) and behaviors (methods). Each object is a self-contained software element including data and methods for operating on the data. Objects are created by defining object classes from which objects are created, or “instantiated.” The object classes are templates for creating objects. Each object created from a particular object class includes all the data and methods of the object class, as well as data and methods from its superclasses, and dif
Hilsdale Erik A.
Lippert Martin
Lopes Cristina V.
Chavis John Q.
Morse Gregory
Wang Peter Y.
Xerox Corporation
LandOfFree
Design by contract with aspect-oriented programming does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Design by contract with aspect-oriented programming, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Design by contract with aspect-oriented programming will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2895826