Dividing Behavioral Responsibilities

We now have many themes, each of which makes sense as an independently understandable feature of the system. We essentially have one theme for each license model, a theme for billing, a theme for downloading, two for registration (vendor and purchaser), one for enforcement, and one for server contact. As you can see, there are many shared requirements, which means we're not yet clear which theme should be responsible for which behavior. The next step is to address the relationships between these themes to determine how functionality should be parceled out.

To begin thinking about the shared requirements, it might be helpful to expand them in the relationship view. Figure 9-6 shows the same relationship view as in Figure 9-5 above, but with some of the shared requirements expanded.

Figure 9-6. Relationship view for the system, with some shared requirements expanded.

We now go through each shared requirement and see which themes should take responsibility for them.

Requirements to Split

R20 and R26 are shared requirements that can be rewritten to remove theme overlap. R20 (Pay-per-use or audit-based: Each time an application is launched, the client is billed), for instance, can be changed into R29: In pay-per-use, each time an application is launched, the client is billed, and similarly, R30: In audit-based, each time an application is launched, the client is billed.

R25 (The audit-based model, pay-per-use model, and concurrent usage model require server contact to determine usage allowance) is a shared requirement between three licensing models and between the server contact theme. The fact that this requirement doesn't mention anything specific about how the server should be contacted suggests that server contact should be removed for now. When new requirements are elicited that make clear the kind of special behavior required for server contact, it will be straightforward to add in a server contact crosscutting theme that preempts regular server contact behavior and performs its own function. To handle the sharing of R25, it's necessary to split it into three requirements, in the same way as we split R20 and R26.

Requirements to Postpone

R5 (After application registration, the developer uploads the application and the usage rights enforcement code) links the enforce theme and the application registration theme. It explains that the application registration must happen before the usage rights enforcement code is downloaded.

This will likely be handled by a check for proof of registration when a developer tries to upload the application. Since this requirement cannot be split, and since it refers to an implied ordering rather than a triggering relationship between the themes, it is postponed.

R14 (Under a named-user license, if a client is registered for use, usage is allowed.) is shared between user registration and named-user license. This requirement also refers to user registration in quite broad terms and does not refer to its functionality directly, but to a check of whether usage registration has occurred. The best option for this requirement is to postpone decisions about the functionality, as we did with R5. While it is true that the requirement describes a kind of precedence (that a named-user license checks that usage registration has been done), it is not the case that license checks necessarily happen before usage registration has been performed. A purchaser might attempt to use a license, but without having registered. In order to determine whether or not a user is registered, the license checking theme will likely access registration logs shared by the two themes.

Requirements Shared by the Enforce Theme

The most prominent shared requirement is R11, which lists all the usage rights models that can be enforced. Though this is a straightforward listing, it reveals something quite important about the functionality to be provided by this system. Many different models are to be put in place, but the fact of their enforcement is common to all of them. Ultimately, once the license model is checked, usage rights are either granted or not granted. This suggests that enforcement is actually a behavior triggered by each of the individual models. Enforcement as an aspect is also supported by the dominance-means-association heuristic of associating a requirement with the theme that most dominates it. While R11 lists many themes, it is clearly the concept of enforcement that is dominant. Because R11 cannot be split, enforce dominates the requirement, and enforce is triggered by the license models, we associate R11 with the enforce theme. That association means that the enforce theme is an aspect of all the other licensing model themes.

But, the relationship between enforce and the licensing model themes is not that simple. Each license model theme has other requirements that discuss the concept of enforcement, but from its own perspective. Requirements such as R12 (Unlimited-usage: With this model, the server retains evidence of a single payment by the client, which, when found, allows usage.) describe very specifically what it takes to get usage access under particular models. R12 is dominated by the description of the unlimited-usage license model, even though the enforce theme behavior (allow) is triggered. R12 fails the third aspect-identification test: the dominant theme must also be the triggered theme. This means that R12 does not reveal an aspect relationship between enforce and unlimited-usage. As it stands, the enforce theme (which at the moment encompasses allow) both crosscuts (from R11) and does not crosscut (from R12) the licensing model themes. This is a contradiction that we must resolve to determine how to move forward to design. One way to handle this contradiction is by removing the enforce theme altogether. However, the enforcement behavior is crosscutting, so we want to keep it in an aspect theme. Also, our earlier reasoning already ruled out removing the enforce theme and letting each licensing model enforce itself. We need to carefully consider how to handle the relationship between the enforce theme and the individual licensing model themes.

In this case, we can use intuition to see that these license model requirements do not describe in any detail what it means to deny usage (how to control access); they only describe situations in which denial is appropriate (how to detect allowance). It makes sense that usage denial (control) should be in the domain of the enforce theme, whereas determining access (detection) should stay with the license model themes.

Recall that we made an early decision to group enforce and allow, stating that these are two sides of the same coin. We now can see that the distinction between allow and enforce is, in fact, the very difference between the concept of the detecting rights (determining allowance) and actually imposing control or denying usage rights (enforcing). We can simplify our reasoning considerably if we backtrack to remove the allow theme and let it be handled by each license model theme individually.

Figure 9-7 shows the far more straightforward relationship between the enforce theme and the individual license model themes. Associating R11with the enforce theme results in the crosscutting view shown in Figure 9-8.

Figure 9-7. New relationship view with the allow theme removed.

Figure 9-8. Crosscutting view

Requirements Shared by the Bill Theme

R20, R22, and R27 are all requirements shared with the bill theme. The boundaries between what should be billing functionality and what should be license evaluation functionality are very blurred. If we really consider these three requirements, we can see that billing is not described in any depth. Really, there are some requirements missing: the ones that describe actual billing functionality. For instance, perhaps e-commerce functionality is needed to bill customers. Or perhaps an e-mail is sent to them. None of this is described. Though these requirements mention billing and tell us that we need some kind of billing functionality, the requirements here are certainly more associated with each individual licensing model theme than with the concept of billing. We need to backtrack and remove the bill theme as it's described here. Removing the bill theme takes care of the sharing of R22 and R27.

Later in our development phase, however, we would need to provide answers to all those questions about how billing is really carried out. Those new requirements would then be added to the set, and a new bill theme would be introduced to accommodate them as appropriate.

Requirements Shared by the Launch Theme.

The final shared requirements are between some of the license models and the launch theme. R19 (Subscription-based: The user pays a monthly fee and checks at application launch whether the fee has been received) is one of those requirements. The others are R29, R30, R31, R32, and R33. Those requirements are the result of splitting R20 (Pay-per-use or audit-based: Each time an application is launched, the client is billed) into R29 and R30, and splitting R26 (For pay-per-use, audit-based, and feature-based models, usage data is logged at application launch and, additionally, according to the usage model) into R31, R32, and R33. We consider these requirements in a bundle for brevity. R29, for instance, reads, In pay-per-use, each time an application is launched, the client is billed. This requirement has already been split as far as it can be. There is no way to decouple billing (which is now in the domain of each of the licensing models, and not a theme in its own right) from application launch. The theme is dominated by the concept of billing and hence by the particular license model. The billing is triggered by the application launch. In this case, we have identified that the billing behavior (hence the pay-per-use theme) is an aspect of the launch theme. This determination is made because a theme that is both dominant and triggered by the other themes in a requirement crosscuts those other themes.

Figure 9-8 shows the resultant crosscutting hierarchy for the licensing system. As you can see, all of the licensing models are crosscut by the enforcement theme. Some of the licensing models crosscut the launch theme.