Better Software - March 2009 - (Page 42) modules and supplementary features that are modularized into specific categories of crosscutting concerns. An RCT also shows for each core feature’s context its composition with crosscutting concerns affecting a given core feature, thereby providing a structured and holistic view of the application functionality. Thus, as discussed in Part 1, an RCT is an important artifact of the analysis phase that can help us improve requirements maintainability. Part 2 of the article focuses on the requirements specification techniques where AORE introduces the concepts of composition rules, join points, and composition pointers, as shown in figure 1. Below I explain these concepts and illustrate by examples how to apply them on software projects to produce more complete requirements. Defining Composition Rules After we have performed requirements analysis and produced an RCT, we already know which crosscutting concerns affect each of the core features. Now, in the specification phase we need to develop ideas about how crosscutting concerns affect core features and document their impact in software requirements specifications. In general, the impact of crosscutting concerns on core features can be classified by the following three cases that I illustrate with examples from an imaginary hotel management system: • A crosscutting concern imposes a constraint on the entire context of a core feature. For example, the crosscutting concern ET-Entitlements imposes a constraint on use cases “Check in Guest” and “Check out Guest.” This means that depending on the entitlement, some users can check in and check out a guest, while other users cannot. The feature “Check in Guest” can be executed only for the reservations with the status “Reserved” and cannot be executed for reservations with other statuses; correspondingly, the feature “Check out Guest” can be executed only for reservations with the status “In House” and cannot be executed for reservations with other statuses. 42 BETTER SOFTWARE MARCH 2009 • A crosscutting concern interrupts the flow of and changes the outcome of a core feature. For example, the crosscutting concerns FV-Field Validation and CN-Connectivity are invoked when a user has completed a guest reservation and attempts to submit it. If any of these validations fails, it interrupts the flow and changes the outcome of the affected core feature. • A crosscutting concern adds detail to a core feature. For example, sending reservation data to the central reservation system and guest rewards system is the outcome of a few core features such as creating a new reservation and checking in or checking out a guest. Details of these data exchanges between the systems are encapsulated and specified in the crosscutting concern SI-System Interface that adds detail and becomes a part of the affected core feature functionality. Based on this classification, AORE defines three types of composition rules [1] and provides guidelines for applying them in core feature specifications regardless of what style we use—user stories, use cases, or traditional specifications: • Wrap: This rule is used when a crosscutting concern imposes a constraint and controls the entire context of a core feature. • Override: This rule is used when a crosscutting concern can interrupt the core feature flow and change its outcome. • Overlap: This rule is used when a crosscutting concern adds detail to a core feature. Example 1: User Story To illustrate the use of composition rules, let’s consider a user story that is a part of the imaginary hotel management system: 01.04 Check in Guest “A user can check in a guest who has a valid reservation” Often on agile projects, such user stories are written by customers to capture their needs. A project team could then www.StickyMinds.com use each story as the basis to plan the release scope, estimate the development effort, and implement and test this feature. However, this simple specification does not tell us the whole story. If we look at the same core feature in the RCT shown in figure 2, we can clearly see the other concerns such as entitlements, field validation, system interface, and so on that affect this user story and are part of its context. To complete the user story details, we can discuss with customers the impact and realizations of applicable crosscutting concerns. First, we discuss how crosscutting concerns affect a given story, and we select composition rules based on the above guidelines. Second, we discuss and document crosscutting concern realizations to add details to the user story specification as follows: • ET-wrap: To begin this story, the system validates the user privilege to check in a guest. • ST-wrap: To begin this story, the system validates the reservation status that should be “Reserved.” • FV-override: To complete this story, the system checks whether the reservation’s data-entry fields have valid values. • DDV-override: To complete this story, the system checks whether some fields have valid combinations (e.g., arrival date < departure date, departure date < credit card expiration date). • CN-override: To complete this story, the system checks whether the front end stayed connected. • CC-override: To complete this story, the system verifies that the selected room is not already taken by another front-desk clerk. • SI-overlap: To complete this story, the system sends the reservation data to the central reservation system and guest rewards system. Specifying realizations of crosscutting concerns means capturing high-level ideas about how these concerns affect a given story, whereas the complete details of these concerns can be encapsulated in their own specifications (e.g., supplementary requirements) or captured as tests when developers follow the test- 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.