Refining the Set of Themes

As usual, we go through the requirements and select key terms that are our potential themes. We identify all the pieces of behavior that we can.

We can also use the behavior depicted in the use case as behaviors in our list of potential themes. Here, the use cases can give us hints as to which pieces of behavior (such as downloading and certain kinds of registration) might be important and which represent separable functionality. It is not necessarily the case, though, that each action-bubble in a use case will become a theme down the road, but the high-level thinking that went into specifying the use case can be drawn upon here. In other circumstances, and depending on the use case, you might decide the entire thing deserves to be a theme. That's fine. Obviously, the granularity of a use case is not fixed, and neither is the breadth of responsibility of a theme, so the knowledge that went into the use case can be more helpful here than trying to form any rigid mapping.

We also include each of the licensing models as a separate potential theme. This choice is made because, from a read of the requirements, it seems as though separate processing is needed to evaluate different licensing models.

We arrive at the following set of themes:

allow (or disallow)

application registration (or register applications, application registering)

audit-based

bill

browse

concurrent

download

enforce

extend

feature-based

identify

launch

log

named-user license

node-locked

pay-per-use

send (or sent)

server contact

subscription-based

time limited

unlimited-usage

upload

usage registration (or registered for use)

As you can see, we incorporated the step of locating synonyms in the requirements into the initial identification process. The synonyms we have identified are listed in parentheses.

These themes result in the theme-relationship view shown in Figure 9-3 . We must now group and refine the set of themes.

Figure 9-3. Licensing system, initial relationship view.

Remove Minor Themes

As you might have guessed, there is a log theme in the proposed set. But let's take a closer look at the requirements that mention the log theme, just to ensure that we really have crosscutting behavior. Figure 9-4 shows the four requirements that mention logging. Each one is significantly different, though they each refer, conceptually, to logging. One response to this variety in behavior might be to include all four kinds of logging in one logging theme. Another response might be to remove the log theme altogether and place the appropriate functionality into the other themes that require it. For instance, if we wind up with a pay-per-use theme, it will handle its own logging at application launch. This second alternative makes better sense when thinking from an aspect-oriented perspective. The logging functionality may seem like it should be crosscutting, but it in fact isn't. Remember that the final step in determining whether an aspect is an aspect is checking whether the theme's functionality is repeated in base themes. If functionality is special to one location in a base theme (as in these four special cases of logging), it should remain in that location in the base theme. So, according to that reasoning, we remove the log theme. Of course, logging functionality is still implemented where appropriate; it just isn't enclosed in a theme of its own.

Figure 9-4. Requirements mentioning logging expanded.

The send theme is another theme that is likely not really significant. The potential send theme is mentioned with relation to sending logs and billing information to the server (R22: In an audit-based model, in order to extend the time-limited usage rights, users must send the logs of the previous application usage to the server for billing; and R27: For the audit-based model, the logged usage data is sent to the server once a month for customer billing purposes). Usage data is sent to the server only in the context of the audit-based licensing model. For this reason, we decide that send, too, should be removed.

Since this is a partial list of requirements, it is likely that more functionality related to send will become needed. You may recall from the Crystal Game example, that communication-level themes arose at design that were not explicitly mentioned in the requirements. The same thing may happen in this situation, or indeed, more requirements may be added that describe this functionality. We can add a new send theme to cover that functionality when it is identified.

Grouping Themes

The extend theme is mentioned in only one location in the requirements. The amount of credit a client has under the time-limited model can be extended if the client purchases more. Since extension is (currently) allowed in only one model, we can group the extend theme with the time-limited model. If, in later evolutions of the system, more models are revealed to require similar extension behavior, we can extract the extend theme out into its own theme again. You may recall from Chapter 6 that if you were to specify new functionality that is to take the place of old functionality, the override composition relationship can be used. In this case, if we broke out a whole new extend theme, we could either move the extend functionality to that theme or override the license extension behavior in the audit-based theme.

Two fairly obvious groups are upload/identify/application registration, (present in requirements R1R5) and download/browse (present in requirements R7 and R8). Uploading and identification only happen at the time of application registration, so these make a nice natural group of functionality. Downloading and browsing also mesh well together.

The final grouping made here is allow/enforce. These two terms represent two sides of the same coin: allowing a client to exercise usage rights is the same as enforcing the usage rights. If you look at the requirement shared by the two proposed themes (R6: The enforcement code allows or disallows usage of an application according to a particular usage rights model), it is clear that the term allow actually refers to license enforcement. Because the senses of these words are so similar, it seems logical to group them.

Once these themes are grouped, we arrive at the relationship view shown in Figure 9-5.

Figure 9-5. Relationship view with removed and grouped themes.