Section 25.7. RELATED WORK

25.7. RELATED WORK

A great deal of work has been done on separation of concerns in software development [16]. Examples of such work include viewpoint-based requirements, designs and tools [8, 13], subject-oriented programming [16], hyperslices, [37] and aspect-oriented programming [18, 20, 30]. Viewpoints, or partial views on parts of software artifacts, have been used for purposes such as requirements engineering, specification and design, and user interface construction and in various software tools. Aspects are in essence a specialization of the general notion of a viewpoint. An aspect captures particular crosscutting concerns on objects or components and thus provides a certain partial perspective on a software system design or implementation. Viewpoints of one form or another have been used in all development methods. These include the many component development methods like Catalysis, SelectPerspective, and COMO [2, 4, 21]. However, in almost all of the current component design methods and implementation technologies, a function-decompositioncentric approach is used. Such an approach results in the tangling of systemic crosscutting concerns in both the component designs and in their implementation code [11, 20, 25]. This is the same kind of problem that aspect-oriented programming tries to address for object-oriented programs. In contrast with these other approaches, we have used characterizations of crosscutting concerns to help design and implement software components in similar way to other UML extensions with aspects [34]. We have used aspect information in a more novel way at runtime to provide a mechanism to dynamically understand and interact with other components.

Hyperslices and subject-oriented programming are similar to aspect-oriented design and programming [16, 29, 37]. They attempt to provide developers with alternative views of crosscutting concerns. Our aspect-oriented component engineering views are specialized kinds of hyperslices. We have deployed this viewpoint mechanism to assist component development in this work. Much recent work has gone into developing techniques to characterize software components. Our work is but one such approach. Some component development methods have introduced specialized views of component characteristics. These notably include security and distribution issues [15]. Our aspects adopt a similar approach but provide a uniform modeling approach for components' crosscutting concerns in general. Some approaches use formal specifications of component behavior [28]. Others make use of characterizations of services that components provide [31]. Some approaches focus on both provided and required functional component services [19, 32]. Our aspects provide an implementation-encoded and run-time-accessible design characterization of software components. We have focused on using common crosscutting concerns as the "ontology" to describe components and some of their interactions. However, we feel that this approach is ultimately complementary to other description approaches.

So far, little attention has been paid to applying aspects to component-based systems. Adaptive plug-and-play components and composite adapters [25, 26] make use of components that implement something similar to the concept of our use of aspect-based decoupled interfaces. These are mixed to help realize the separation of various concerns from component implementations. Component design methods currently provide a very limited ability to identify overlapping concerns between components. However, the isolation of systemic functions (for example, communications, database access, and security) into reusable components is common in component technologies [27, 32, 39]. This partially addresses the problems of components encapsulating these systemic services. It also enables isolation of these services and access via well-defined component-based interfaces. However, not all aspects can be suitably abstracted into individual components, though some success has been achieved with middle-ware-supporting components [3]. This is due to overlaps and the eventual over-decomposition of systems. JAsCo [35] provides a component-based development method incorporating aspects, which uses the concept of aspect beans and connectors to extend JavaBeans for aspect-oriented composition. This approach is similar to our component aspects but specialized for a JavaBean-based development platform.

One of the main motivations for the use of reflective techniques and the run-time composition and configuration of components is to try to avoid compile-time weaving [30, 38, 40]. This allows running systems and their components to have aspects imposed on them after deployment. This is done typically as before/after method processing. Some technologies also support intra-method code incorporation and component reconfiguration at runtime. Aspects in such systems can be formulated at runtime and added or removed from programs and components dynamically. The crosscutting concerns are encapsulated within the introduced aspect code. Currently, most code incorporation-based techniques have a high amount of expensive performance overhead. A further issue is a current lack of design abstractions. Our aspect-oriented design approach does not preclude implementation with any of these technologies. However, our aim with decoupled interaction and introspection via aspect information was to produce software components that make use of aspect-related services in other components via well-defined component interfaces. This approach allows for controlled and efficient dynamic reconfiguration support via standardized component-supported or delegate aspect object-supported functionality access. In addition, our aspect-oriented component designs provide a consistent set of design abstractions. Our dynamic discovery approach using aspect information has some similarities with the UDDI discovery mechanism developed for web services [24]. A major difference with current UDDI registries is the ability to use categorized functional and non-functional information with our aspect-based approach.

Our use of aspect information at runtime for component repositories and deployed component validation contrasts with most other approaches. Most software repositories use type-based, keyword-based, or execution-based indexing [17]. In these approaches, the component interface, comments, or behavior are used to index and retrieve components. Run-time adaptation can also be well supported by aspects, which is illustrated in our own work and that of others more recently [5, 38]. Using aspects in addition to one or more of these techniques gives further perspectives on components that can be indexed and queried. Current component testing and validation techniques mainly focus on exhaustive functional interface testing [22, 23]. Using aspect-encoded information associated with components allows validation agents to query for expected functional behavior and non-functional constraints. Tests can then be automatically assembled and run and feedback given to developers on whether or not a component meets its aspect-codified constraints in its current deployment situation.