Data processing: software development – installation – and managem – Software program development tool – Linking
Reexamination Certificate
1999-07-20
2002-10-15
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Linking
C717S163000, C717S100000, C717S106000
Reexamination Certificate
active
06467086
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to creating software, and more particularly to aspect-oriented programming and aspect libraries.
BACKGROUND OF THE INVENTION
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 different objects of the same object class may be used for different purposes. Common object-oriented programming languages include Smalftalk, C++, and Java. Object classes for implementing commonly-encountered issues are often packaged as class libraries which developers can call upon, rather than having to re-create new object classes.
Other non-OOP approaches are also commonly used, such as embodied in procedural programming languages and functional programming languages.
When design features may be cleanly divided among distinct elements, these approaches provide good support for programming those features in a modular way. However, these approaches fail to provide the proper support in certain situations, such as those involving shared resources, error handling, or other systemic issues where the same or similar functionality affects or is affected by many different elements.
The reason why these approaches are insufficient is that those issues cross-cut the primary modularization of the systems. Cross-cutting occurs when some particular concern depends on and/or must affect parts of the implementation of several of the functional modules of the system. Many cross-cuts are not weaknesses of the designs; they are a natural and unavoidable phenomena in complex systems, and they are the basis for the concept of “aspect.”
Implementing those cross-cutting concerns in traditional programming languages, even object-oriented ones, typically requires scattering bits of code throughout the program, resulting in code that is tangled.
For example, non-trivial performance optimizations tend to cross-cut many modules when writing programs using traditional programming languages. So, for example, using Lisp or Java, the implementation of a cross-cutting performance optimization ends up affecting the non-optimized, modular implementation of the components in ways that are all but obvious, resulting in code that is tangled and in loss of the optimization abstraction.
SUMMARY OF THE INVENTION
An aspect is a concern that cross-cuts the primary modularization of a software system. An aspect-oriented programming language extends traditional programming languages with constructs for programming aspects. Such constructs can localize the implementation of cross-cutting concerns in a small number of special program modules, rather than spreading the implementation of such concerns throughout the primary program modules.
In order to capture the cross-cutting nature of aspects, such special program modules break the traditional rules of encapsulation in principled ways. They can affect the implementation of the primary modules without the explicit consent of those primary modules; further, they can do that for several primary modules simultaneously.
Aspect oriented programming (AOP) extends the expressive facilities available to the programmer, so that many design decisions can be expressed locally. The AOP programmer writes the base program in a traditional programming language, and also writes pieces of aspect code, each of which affects executions that are described in some parts of the base program.
In such a manner, aspect code can localize the implementation of some design patterns in a few modules, rather than spreading the fields and methods of those patterns throughout the classes, and can capture the tracing, debugging and instrumentation support for a complex system in a few modules, capture error handling protocols involving several classes in a single module, and capture resource sharing algorithms involving several classes in a single module, rather than as multiple code fragments tangled throughout the classes.
The special program modules for programming aspects enable this by cross-cutting the modularity of classes in principled ways. So one of those special program modules can affect the implementation of several classes (or several methods within a single class) in a clean, principled way. Aspect-Object interaction differs from Object-Object interaction and other traditional programming paradigms in that with the traditional approaches, all behaviors of the objects are encapsulated in the objects themselves, either as a direct implementation in the object class definition, as a request encoded in the object class definition to use the behaviors of other objects (e.g., a method call), or as a request in the object class definition to reuse the implementations of other object classes (e.g., through inheritance). Thus, in these traditional approaches, all control of an object's behavior lies with the object itself. In the AOP environment, on the other hand, a part of the object's behavior can be defined in an aspect outside of the object without the object having to request the behavior in any way. Thus, it can be said that a part of the object's behavior is transparently forced on the object by the aspect. Moreover, aspects have a more global effect in that one aspect can forces its behavior on multiple objects, possibly of different classes.
The paradigm of Aspect-Oriented Programming was first introduced in Gregor Kiczales et al., Aspect-Oriented Programming in Proceedings of the European Conference on Object-Oriented Programming (ECOOP 97), June 1997 (“Kiczalles”), which is hereby incorporated by reference. In Kiczales, a new unit of software modularity, called an aspect, was provided that appears to provide a better handle on managing cross-cutting concerns.
In Kiczales, only highly domain-specific aspect-oriented systems had been developed. There was also a goal of developing a general purpose AOP mechanism . At the time of the prior art, it was unknown how to generalize from the very specific examples of AOP to conceive of the necessary abstractions in order to create a general model. Thus, t
Boyapati Chandrasekhar
Hilsdale Erik A.
Hugunin James J.
Kiczales Gregor J.
Lamping John O.
Das Chameli Chaudhui
Morse Gregory
Wang Peter Y
Xerox Corporation
LandOfFree
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 Aspect-oriented programming, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Aspect-oriented programming will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2994827