Section 24.5. MODELING BENEFITS FROM ASPECT-ORIENTED DEPENDENCY MANAGEMENT


24.5. MODELING BENEFITS FROM ASPECT-ORIENTED DEPENDENCY MANAGEMENT

The areas of aspect-oriented analysis and design are today in the early stages of exploration [8, 18]. However, there already seems to be an added bonus to aspect-oriented designs for class or component connectivitythe resulting designs more closely match the real world.

Dependency management addresses the theme of connectivity and extensibility between a service and its clients. AOSD naturally moves extensions of base functionality to aspects and makes the core classes more stable, less concrete, and more reusable. In terms of the Open/Closed Principle (which states that modules should be open for extension and closed for modification) [12, 13], classes are the closed part and aspects are the open part in an aspect-oriented design of this type.

Several years ago, software components were hailed as the integrated circuits of the software engineering profession [3]. Component technology has justifiably displaced object technology as the sharpest tool in the programmer's toolbox, but components have not achieved their promise as parts on a shelf waiting for assembly. There are many reasons, but one is that connecting software components is far more complex than connecting electronic or mechanical components. Figure 24-14 suggests that mechanical and electronic parts in relation to their connectors (nuts, bolts, adhesive; wires, pin patterns, bus standards) and assemblies (cars, houses, computers, VCRs) have the correct directionality of dependency. However, software connectors are more concrete and less stable than their mechanical counterparts (see Figure 24-15). The natural dependency from software part to software connector is therefore improper according to the dependency principles. This conundrum is the current justification for many design patterns, Observer being chief among them.

Figure 24-14. Mechanical and electronic assemblies have dependencies upon parts and connectors that have the proper directionality in stability and abstractness.


Figure 24-15. Unlike mechanical or electronic connectors, software connectors (static or dynamic relationships and dynamic collaborations) are more concrete with higher penalties for change. Therefore, the natural dependency of parts upon connectors is improper according to the DIP and SDP.


Why are software connectors less stable and more concrete than software parts, in contrast to their electronic or mechanical analogs? Mechanical connectors are defined by their size and shape, strength, adhesive properties, or materialall of which can be standardized without much loss of design flexibility. Electronic connectors add to this list a defined behavior for the signals carried through them. This makes them less stable and abstract than their mechanical cousins. However, the variety of electrical signals (5V 66MHz digital, 12V analog, 120V 60Hz AC, etc.) is still manageably finite and well standardized. Software "signals" through software connectors, however, are as varied as software itself. The variety of information carried between software modules is precisely what makes software so valuable.

Aspect-oriented software development has the potential to build upon all that we as a profession have learned about object-oriented and component-based development and to solve several remaining issues, like this need for an inverted dependency between part and connector. Aspect-oriented connectors can insert themselves in precise, unanticipated ways into the parts they connect. Like an imaginary engine block with no boltholes, the parts need never have been designed for a particular connection mechanism. Figure 24-16 shows the dependency inversion accomplished by an aspect-oriented solution that pushes connections into aspects and leaves only core functionality in classes, components, or software parts.

Figure 24-16. Placing software connectors mainly in aspects successfully inverts the dependency between software parts and software connectors.


Today's aspect-oriented technologies generally provide a declarative definition for "when" functionality applies in the code while keeping an imperative definition for "what" to do there. Tomorrow's technologies will likely make the declarative "when" even more powerful. Our ability to cleanly manage dependencies with aspect-oriented techniques is already a great improvement over long-trusted object-oriented techniques and only promises to improve over time. Software designs that manage dependencies with a skilled mix of object-oriented and aspect-oriented techniques can nicely balance the qualities of practicality, comprehensibility, and flexibility for future change.



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