Section 3.5. RELATED WORK


3.5. RELATED WORK

We discuss two categories of related work: approaches that can (loosely, perhaps) be considered instantiations of our model for particular types of artifacts, and different approaches to similar problems.

Subject-oriented programming [7, 17] partially realizes our model for object-oriented code artifacts. The units are classes, methods and instance variables. Systems are built as compositions of subjectshypersliceseach of which is a class hierarchy modeling its domain from a particular point of view. We have built composition support for C++ and CORBA IDL, prototype support for Smalltalk, and are currently building support for Java. Composition rules, specified textually for C++ and through an interactive user interface for the other systems, provide considerable matching and reconciliation flexibility, and the support is a framework allowing addition of new matchers and reconcilers. We have several small, running examples that demonstrate the value of decomposition into subjects. We are also currently exploring the manifestation of subjects and composition rules in UML, to allow co-structuring of subject-oriented designs and code.

Aspect-oriented programming (AOP) [10] expands on the concepts of subject-oriented programming by identifying and illustrating several useful, non-functional concerns to be separated, such as concurrency properties, distribution properties, persistence and other "emergent entities" [11]. Initial work used different aspect languages (e.g., [12]) to represent different aspects. This is appealing, since a programming language is not necessarily the best formalism for expressing non-functional requirements, but it results in a need for special-purpose compositors (called weavers. More recent work is aimed at providing a general-purpose weaver for hyperslices written in Java [10].

AOP distinguishes the notion of "core classes," which encapsulate a system's functional requirements, from "aspects," which encapsulate non-functional, cross-cutting requirements. Aspects are written with respect to core classes and are essentially orthogonal to one another. Relative to our model, each aspect is a hyperslice, and a set of aspects together with the core classes approximate a hypermodule. The core classes are distinguished; all aspects refer to them, and therefore share the same view of the overall class structure. The hypermodule does not have a central composition rule. Instead, each aspect contains its part of the rule, specifying how that aspect is to be woven into the base classes. This makes the approach subject to the disadvantages discussed in Section 3.3.3, particularly that handling of overlapping concerns (i.e., interaction among aspects) is perforce done in a standard, default manner by the weaver.

Holland discusses the building of systems using compositions of contracts [8]. Each contract specifies a set of participant objects and their interactions, expressed as obligations. Its primary intent is to encapsulate these particular interactions and obligations so that they are clearly separated from other interactions involving the same objects. A single object can participate in multiple contracts, in which case it must satisfy all their obligations. Holland describes a variety of combination rules for contracts. A contract corresponds to a hyperslice in our model, cutting across classes that describe objects. The combination rules provide some alternative means of combining specifications in different contracts that apply to the same participant.

Similarly, role models (e.g., in OORAM/OORAS [1]) are essentially hyperslices. Each model describes particular roles played by objects, and how those roles interact. Role models must be composed, usually manually, to produce object definitions that satisfy all needed roles. VanHilst and Notkin propose an approach to implementing roles with templates [24]. Each template defines a role, and instantiation expressions create classes that satisfy all required roles. Collections of related templates, such as those defining similar or interacting roles for objects, constitute hyperslices in our model, and instantiation expressions are composition rules.

Adaptive programming is another approach to providing modules other than classes within object-oriented systems. A class graph describes some classes and their relationships, from a particular point of view. Class graphs do not contain code; instead, code is written in separate propagation patterns. Propagation patterns can be used with any collection of concrete classes that conform to the class graph against which they were defined. Adaptive programs are transformed into standard object-oriented programs by the Demeter tools [3]. With respect to this generated program, each propagation pattern is a hyperslice, since it contains method code that cuts across classes. The composition is performed by the Demeter tool, with matching being based on specification of class graph conformance. Propagation patterns do not overlap, howevereach defines its own methodso reconciliation is not an issue. In a recent paper [13], collaboration-based decomposition is discussed, of which contracts are an example. Collaborations are hyperslices, cutting across classes.

Catalysis [4] facilitates building reusable design frameworks in UML. It incorporates a simple notion of composition based on the union of design models. It therefore represents an instantiation of our model for UML. Catalysis' matching and reconciliation rules are fairly simple, which limits the dimensions along which design models can be decomposed and composed, but makes reasoning about properties of the composed design in terms of its component design models more tractable.

The Viewpoints project [15] is an approach to requirements engineering. Modules, called viewpoints, encapsulate developers' views of both the requirements-building process and the pieces of the requirements artifact being developed. Different viewpoints may describe the same requirements artifacts in different notations, and they may create conflicting definitions for given requirements. The Viewpoints system defines mechanisms (based on theorem proving) for identifying and helping developers cope with inconsistency.

The Viewpoints approach shares a number of points in common with ours but also has corresponding differences. Both approaches are predicated on the belief that not all concerns can be modularized orthogonally, and that it must be possible to view systems as potentially overlapping pieces. Another similarity is a concern with resolving semantic differences between different aspects or elements of a system (views or hyperslices). Viewpoints emphasizes the detection and characterization of inconsistencies while deferring their resolution (reconciliation) to the encompassing requirements process. We have focused on the activity of composing concerns after they have been separated, including identifying and, especially, reconciling inconsistencies according to a composition rule. Finally, we are primarily concerned with how artifacts are constructed, while the Viewpoints approach is primarily concerned with how they are viewed.

Some of the problems addressed by our approach can be tackled differently. Attempts have been made to address the problem of traceability with environment support for capturing and maintaining the relationships among artifacts (e.g., [9]). The disparate structures of the artifacts make this a particularly tough problem.

The problem of limiting the impact of change has been addressed by various architectures and mechanisms, like implicit invocation [14], mediators [22], event-based integration [20], and design patterns [5]. These are all valuable, but they suffer from the drawback that the kinds of changes they permitthe open pointsmust be anticipated. Retrofitting any of these mechanisms where not originally planned requires invasive change.

A great deal of work has been done to promote reuse, and other researchers and developers have recognized the importance of large-component reuse (e.g., [2]). Effective reuse requires powerful adaptation and customization mechanisms, but current customization technology is usually restricted to interface adaptation using some sort of adapter or transformation layer, or to substituting alternative modules at predetermined points, such as in object-oriented frameworks. Interesting recent work builds on adaptive programming to support "adaptive plug-and-play components" [13].



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net