Overview of the ThemeDoc Process


Overview of the Theme/Doc Process

The Theme/Doc portion of the Theme approach contains three main components: deciding on a set of themes to include in your system, determining the responsibilities of those themes, and planning for design. These three activities are depicted in Figure 4-5.

Figure 4-5. General view of the analysis process.


The activity at the top of the figure is Decide on the Themes. In that part of the process, you attempt to arrive at different pieces of functionality, each described separately.

Moving clockwise, the bottom right activity is Determine Theme Responsibilities. This is a more general way to say, "Decide which themes are aspects and which are base." The reason we describe it as deciding on responsibilities is that if a theme is responsible for behavior that is triggered in another theme, than the first theme is an aspect of the second.

Finally, there is the Plan for Design activity in which you consider the structure and behavior that you will model using Theme/UML.

It is likely that, at least at first, these activities will take place in the order shown, so that you first think about which themes you want to implement, then decide what those themes will do (which requirements they will cover, how they relate to other themes, whether they are aspects or base), and then do initial designs for the themes. But once that initial iteration is over, it's likely that you'll choose to mix up the process a little. For instance, after thinking about the design of a theme, you may realize that you're not happy with the responsibilities of that theme, and you may backtrack and assign the theme different responsibilities (by associating it with different requirements). Or, you may decide that you don't think the theme works at all and that you'd rather get rid of it. In that case, you review the themes you plan to keep and reconsider how to split up the responsibilities from your unwanted theme.

You may have noticed that in Figure 4-5, the activities have particular Theme/Doc views associated with them. The relationship view is suggested as a way to help you decide on which themes should be included in your system; the crosscutting view can help you determine the responsibilities of a theme (and hence which themes crosscut other themes); the individual view is suggested to help you plan for design. However, it is not the case that you have to stick religiously to those suggestions; any of these views might be helpful when performing the other activities. Just as you will likely have to iterate between the three main activities, you will probably find that switching between views is helpful.

A more realistic look at how views might be used for tasks is shown in Figure 4-6. The relationship view is depicted as being useful for both deciding on which themes to have and determining theme responsibilities. The individual view seems most relevant when looking at whether the themes you have chosen are appropriate (part of the process of deciding on themes). The crosscutting view is what reflects choices about requirements associations (and postponed associations), so that view is mainly useful when deciding on aspect-base relationships. All three views, however, are useful when planning for design.

Figure 4-6. Focused look at the activities involved in choosing themes and deciding on their responsibilities.


Figure 4-6 shows operations you can perform on requirements and themes as ovals. These operations are available when using the Theme/Doc view-generation tool regardless of the view you are using. Four operations can be performed while adjusting themes: adding themes, deleting themes, splitting up themes, and grouping themes. Five operations can be performed on requirements: adding a new one, splitting them up (essentially adds new ones to the end of the list of requirements and marks the requirement as "split"), attaching them to a particular theme, associating them with a particular theme (to specify crosscutting), and postponing their association until more information becomes available.

The rest of this chapter looks at how these operations are used when analyzing the requirements from the Crystal Game (provided in the appendix). The description of the approach in this chapter is very linear: first we describe deciding on the themes, then determining which themes are aspects and which are base, and finally, preparing for design. The application of the views in this chapter is also simplified such that all the views in the chapter are used in the task context depicted in Figure 4-5. As we discussed above, you should not feel limited to the ordering of events as described below. The case studies at the end of this book provide examples of mingling these activities, using views in different contexts, and interleaving these activities with design.



Aspect-Oriented Analysis and Design(c) The Theme Approach
Aspect-Oriented Analysis and Design: The Theme Approach
ISBN: 0321246748
EAN: 2147483647
Year: 2006
Pages: 109

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net