4.6. CONCLUSION In Section 4.1.1, we presented the objectives for the CF model: composability, evolvability, robustness, implementation-independence, and dynamics. In this section, we briefly discuss each of these objectivesto what extent they are met with the present model and how they relate to the presented example whenever applicable, and in some cases, we refer to related or future work. Composability. The CF model supports composability at two levels: composition of filters and composition of concerns. Composition of filters is supported because all filters are based on the same underlying model of message manipulation. Only specific semantic dependencies between filters can cause interference problems. Second, filter expressions support the composition of behavior of concerns, most notably the signatures of concerns. The example evolution scenario that we used in this paper illustrates the stepwise composition of the final application from several concerns. For example, an instance of ProtectedClaimDocument after the final evolution is a composition of the ClaimDocument and ProtectedClaimDocument concerns, with the (superimposed) filter modules DocWithViews and NotifyLogger. As a result, such an instance composes the redirect Meta filter (line 9 of Listing 4-2), the protection filter of type Error (lines 11-17 of Listing 4-1), and the inh filter of type Dispatch (in line 18 of Listing 4-1). Crosscutting concerns require the composition of filter modules; this is essentially similar to the composition of (multiple) filters. Further, declarative completeness of filter modules makes it easier to check composability at compile time or instantiation time. Superimposition among crosscutting concerns is also possible, as demonstrated by the workflow and logging concern in our example. Evolvability. The CF model extends traditional object models with possibly crosscutting behavior. This is achieved by extending objects with filters (filter modules). This is possible for virtually any object or component model. The only possible issue is that inheritance of the implementation language and inheritance of the CF model are orthogonal: developers must take care to avoid implementation language inheritance relations between CF objects. Robustness. A number of properties of the CF model contribute to robustness, including the overall language design and the chosen abstractions and their syntax and semantics. Verifying or even discussing robustness in general is quite hard; hence, we focus on the following properties: Encapsulation. The implementation of a CF concern is strongly encapsulated; superimposition of filter-interfaces, objects, methods, and conditions is restricted to the interface level. Therefore, superimposed concerns do not rely on the details of the implementation (even the implementation language is encapsulated). Several other approaches, such as AspectJ [25], allow the crosscutting concerns (aspects) to refer to, and depend on, implementation details of the base-level abstractions. This makes the aspects less reusable and more vulnerable to implementation changes. Although researchers do not all agree whether the benefits of respecting encapsulation outweigh the limitations, it seems fair to state that encapsulation is beneficial for robustness. High-level semantics. Filter specifications use a common pattern matching language and adopt filter types to add concern semantics. The semantics of filter types are well defined and highly expressive in their specific concern domains [8, 10]. As shown in the example, Error, Dispatch, and Meta filters could effectively express multiple views, delegation and message reflection, respectively. Given the availability of suitable filter types, this enables the programmer to express his intents clearly and concisely. Analyzable aspect description language. Most aspect-oriented approaches adopt general-purpose programming languages for specifying concern. In general, reasoning about the semantics of such concerns is hard to do (e.g., consider the undecidability problems of Turing-complete languages). The restricted (pattern matching) language used to define filters provides better opportunities for automated analysis of correctness. We have started to explore this area in [9, 18].
Implementation-independence. The CF model is largely independent of specific implementation techniques, programming language, and platforms. This was demonstrated in Section 4.5.1 through the discussion of eight implementations of the composition filters model that are all substantially different in one or more respects. In particular, this is made possible by the declarativeness of filter specifications. Dynamics. To a large extent, the implementation independence supports the dynamic adaptation of structure and behavior. Again, declarative specifications of filters and superimposition are helpful, but in particular, it must be possible to explain and implement the language through an operational model.
The CF model addresses the quality objectives as depicted in Section 4.3; for each objective, one or more specific properties of the CF model contributes to meeting the objective. Our future work will mainly focus on new verification techniques, new filter types, and robust CF development tools. In addition, we continue to explore ways to improve composability. |
