Designing the Crosscutting Themes

In this example, we moved from designing our concept-sharing, or base, themes to designing the crosscutting theme, preempt. This is not a rigid order. It might be that working with the crosscutting themes prior to designing the base themes is more appropriate or convenient. In most cases, going back and forth a little probably makes sense.

We associated R5 and R6 with the preempt theme. Figure 8-6 shows its individual theme view. The only elements fully owned by the preempt theme are mute, audio-save, audio-pause, and audio-resume. The rest are all likely templates from the perspective of this theme. We can once again look at these requirements and consider whether they behaviorally crosscut the base themes. If they do, we can be confident that this theme is appropriate as an aspect. Upon inspection, you can see that if the behavior described in this theme were replaced in the base, there would be duplicated preemption handling in all of the grayed themes.

Figure 8-6. Preempt individual-theme view.

As you can see in Figure 8-7, each requirement has been captured in its own sequence diagram. The sequence diagram on the left deals with the simple case of muting a sound if a notification is coming through. The design introduces two classes: HighPriority and Preempted. The sequence diagram on the right deals with pausing activities during a voice call. Of course, the notification and the voice call are represented as templates here, as simply sound() and as the start() of a HighPriority behavior. In the left-hand sequence diagram, the sound() method triggers the behavior. HighPriority.sound() is bound to both VoiceCall.ring() and SMS.alert().

Figure 8-7. Preempt design bound to the base phone theme.

Several design choices are carried out in the Preempt theme design. Notice that the mute, restore, pause, save, and resume behaviors are all template parameters. This reveals the assumption that the base themes will all have their own such behavior to which these parameters can be bound. This choice was made because of a belief that these methods would be used more widely than just for this theme. For example, muting and pausing are both functions that the media player (and in fact all Audible classes) needs regardless of audio preemption. However, if these methods were used only by this theme, it would be a better design strategy to specify their behavior within the preempt theme rather than place them in the base just as hooks.

Referring back to Figure 8-6 you can see, once again, the grouping of ring as a subtheme of voice call and alert as a subtheme of sms. We noted earlier that we might have also chosen to group ring and alert under the preempt theme. Such a grouping would have altered the design of both the base and this theme. Had we chosen to perform this grouping, the preempt theme view would have looked like Figure 8-8, in which the signal sms, signal call, alert, and ring themes are all local to preempt. The sms and voice call themes would not have needed ring() or alert() methods, since notification behavior (specified in R3 and R4) would have been handled by the preempt theme. The left-hand sequence diagram in the preempt Theme/UML design in Figure 8-7 would be only slightly changed to invoke the ring sound. R5 now becomes an internally triggered requirement, since the alerts and rings would be coming from within the preempt theme.

Figure 8-8. Preempt individual view, had we chosen to group ring and alert with preempt.

Figure 8-9 shows the design for option 2 (grouping alert and ring under preempt). You can see that the ringing and beeping is explicitly invoked from within this theme, rather than using a template parameter as was done in the design shown in Figure 8-7. Two separate sequence diagrams provide the functionality described in R3, R4, and R5: One responds to incoming voice calls (sd Ring.incoming), and one responds to incoming SMSs (sd Beep.incoming). The third sequence diagram (sd start) is the same as the sd start from Figure 8-7. It remains unchanged since the behavior of the response to an actual voice call connection was not altered by the regrouping.

Figure 8-9. Preempt design for Option 2.

At this point, we may rethink our earlier choice and decide that we should have chosen the second option. We might even choose a third option and encapsulate all ringing and alerts in one audio theme, or a fourth, and make separate ring and beep themes. It's likely that when you reach design, you will find that some of your early choices were less than ideal. It is fine to make new choices at design and reflect those choices by reassociating or regrouping themes at the Theme/Doc level. By propagating those changes backwards, you both enhance system traceability from design back to requirements and get a sense of how your new choices affect the other theme relationships in your system.