Better Software - March 2009 - (Page 46) 3. docuMent reAlizAtions oF crosscuttinG concerns Up to this point, crosscutting concerns were just abstract categories of requirements that supported our analysis to answer such questions as: Which crosscutting concerns affect a given use case? and Where and how do they impact a use case context? Now, the purpose of this step is to refine the impact of crosscutting concerns and specify their particular realizations in the use case context. As shown in figure 3, these details can be captured in a separate appendix section. This section has a table that, for each composition pointer presented as a bookmark, includes brief descriptions (just ideas) of particular realizations of crosscutting concerns at a given join point and references to detailed specifications of crosscutting concerns. For example, the composition pointer FV-override2 that we included in step 7 in figure 3 points to the realization of the FV concern. Such a realization is specified in the appendix where the table provides detail about which fields should be individually validated at this join point. Another composition pointer DDVoverride3 points to the realization of the DDV concern that provides details about which field combinations should be validated, and so on. Realization descriptions in the appendix do not need to be very detailed and can be captured at a high level of abstraction, which is sufficient for understanding the impact. For the complete details of crosscutting concerns, we refer in the appendix to their respective sections in supplementary requirements. However, such references can be completed only after the supplementary requirements have been developed. be invoked. This sequence can be determined based on the following guidelines: • We place composition pointers for concerns with the override rule before the concerns with the overlap rule, because when a crosscutting concern overrides the outcome of a use case step, the overlapping crosscutting concerns will not be invoked, either. • Composition pointers for crosscutting concerns having the same composition rule (i.e., override or overlap) are specified in the order of their business priority. In our example in figure 3, step 7 is a join point impacted by four crosscutting concerns with the same composition rule override. The sequence of their composition pointers at step 7 illustrates how the conflicts were resolved—i.e., the system invokes first the FV concern, then the DDV concern, and so on. With this step, we have completed the analysis and specification of the use case “UC.01.04 Check in Guest.” By following the AORE techniques, we identified crosscutting concerns affecting the use case, selected related composition rules, modeled concern composition using UML, and specified the impact and realizations of crosscutting concerns by identifying join points and including composition pointers in the use case specification. This specification now captures the necessary details about the impact of crosscutting concerns, thus providing a structured and holistic view of the application functionality in the use case context. In this article I discuss a new methodology known as aspect-oriented requirements engineering and use examples to illustrate its techniques and benefits. AORE focuses on resolving issues with the scattering and tangling of requirements to improve the modularization, maintainability, and completeness of requirements models. AORE does not replace but rather complements any of the existing requirements methodologies by adding effective analysis and specification techniques. As summarized in figure 1 at the beginning of this article, when we follow AORE in the analysis phase, we separate concerns by core and crosscutting categories and then analyze and document the impact of crosscutting concerns on core features in the new analysis artifact called requirements composition table. In the specification phase, AORE introduces the concepts of join points, composition rules, and composition pointers that we use to document the impact of crosscutting concerns in the core feature specifications. Thus, by applying the AORE analysis and specification techniques we can improve the structure and completeness of requirements models that, in turn, can help us improve requirements maintainability and reduce the cost of developing requirements. Finally, AORE is a relatively young methodology that is still evolving, exploring its benefits, and making its way to practitioners. At this point, AORE faces such challenges as consolidating various composition rules into a standard set of rules, adopting standard UML techniques to support aspect-oriented requirements modeling, and reconciling the differences between the two schools—i.e., two-dimensional vs. multidimensional separation of concerns to form a consistent methodology. Resolving these challenges is imperative for the faster adoption of the AORE methodology by practitioners in the software industry. {end} reFerences [1] Brito, Isabel and Ana Moreira. “Towards a Composition Process for Aspect-Oriented Requirements.” Workshop at AOSD Conference, 2003. 4. AnAlyze And resolve conFlicts As previously mentioned, a given join point can be affected by multiple crosscutting concerns. Step 7 in the use case specification is an example. In this case, we should analyze whether any of the crosscutting concerns can conflict with each other at the same join point. If so, we can specify the conflict resolution by listing composition pointers in a particular sequence, reflecting the order in which crosscutting concerns should 46 BETTER SOFTWARE MARCH 2009 www.StickyMinds.com http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.