Designing the Themes

Now that we have an overall concept of how the themes of the system should fit together, we can move forward to designing them using Theme/UML. You may recall that there are essentially two portions to this system: the registration/upload/download portion (as described in the use case depicted in Figure 9-1 and the application-usage and license-enforcement portion (described in Figure 9-2).

Registration/Download Themes

There are three themes that cover the functionality for application and usage registration and download. We will now discuss each theme and then address how they are merged together.

Application Registration

Application registration is described in the first five requirements of the set. This theme is fairly straightforward, though it contains a significant amount of functionality. It provides all the registration functionality for vendors, collects authentication information, and prompts and handles the upload of applications and licensing models to the server. Here, however, we won't provide a design for this theme, since it doesn't reflect anything interesting from an aspect-oriented perspective.

Usage Registration

In the set of requirements for this case study, there are no requirements central to the concept of usage registration. Earlier, we decided to remove the bill and server contact themes for this same reason. We could have made the same choice with the usage registration theme, but in this case we choose to keep it in and design it using placeholders for when more details about its functionality are elicited. Once these details are determined, they can be reflected in the requirements set, and the Theme/Doc diagrams shown in the previous section can be regenerated automatically to reflect the additions. The option of using placeholder designs for bill and server contact was also available to us. As Figure 9-9 shows, we've added a theme that contains the most basic concepts of a registration theme.

Figure 9-9. Usage registration design.

Download

This theme provides functionality for downloading the application. It also sparks the composition of the application launch and licensing themes. The download theme allows a user to select an application and a usage model (for instance, a document editor program on a 30-day trial license), and then download the application, which would be compiled together with enforcement code for that type of license. This kind of functionality requires a dynamic composition model and appropriate implementation language support, since the composition specification is made not by the initial developer, but by a running system. Theme/UML has no specific notation for dynamically determining binding. Instead, as Figure 9-10 illustrates, we use the standard UML approach and annotate the download theme with a note that indicates that at the point of download, the binding for the application and license model is determined and performed. This note is a reminder that weaving the selected license model with the requested application must take place at runtime. Later (Figures 9-15 and 9-16), we present examples of an application combined with different licensing models.

Figure 9-10. Download theme, showing invocation of the dynamic determination of the bind specification for the application and license model.

Figure 9-15. Design for the feature-based license model.

Figure 9-16. Time-based design.

Composing Application Registration, Usage Registration, and Download

No special ordering relationships are needed to compose this group of themes. Using the match[name] attachment to the composition relationship to compose all three is sufficient.

Licensing Themes

In the requirements provided for this case study, eight licensing models are described. Interestingly, only four of them explicitly mention at which point the license should be checked (feature-based, subscription-based, pay-per-use, and audit-based). As you can see by looking at the crosscutting Theme/Doc view (Figure 9-8), these four explicitly note that the license should be checked at launch time. Individual requirements specify whether the launch should be a feature-launch or the launch of the entire application. While designing the internal details of the four other licensing themes comes a little later, it is straightforward to assume that these four will also crosscut the launch theme and so will have template parameters that bind to application or feature launch. A sketch of this is shown in Figure 9-11. Examples of the actual composition relationships with bind[] specifications are shown for the feature-based licensing model (Figure 9-15) and for the time-based licensing model (Figure 9-16).

Figure 9-11. An initial sketch of the relationship between four of the license models and the launch base theme. Only one of the bind relationships would be chosen upon the download request from the purchaser.

Now that we come to design the licensing themes, it is imperative that we determine when the other four licenses should be checked. Inspecting the requirements associated with those licenses, an implicit assumption that they are checked at launch time is evident. This represents another instance at which we can backtrack to take functionality into account that wasn't explicitly mentioned in the requirements. It is fairly straightforward to add the requirements that describe when the other licenses are checked and to regenerate the diagrams. This regeneration reflects that each of the other licensing model themes crosscuts the launch theme. Their overall template and binding design are the same as those depicted in Figure 9-11.

Each model actually performs its own checking and keeps track of all the information necessary to determine whether usage should be allowed. Any logging that's needed happens within the particular model. We will see an example of a model design in Figures 9-15 and 9-16. The overall binding and template structure so far is shown in Figure 9-12.

Figure 9-12. Overall design for the registration and license model themes.

The launch theme shown in Figure 9-11 and Figure 9-12 handles the application and feature startup. Figure 9-13 shows the structural design for the launch theme.

Figure 9-13. structural design for the launch theme.

Next, we put in place the license-enforcement functionality. The individual model themes check whether the license is valid or invalid, but what happens once that determination is made belongs to the yet undesigned enforce theme. As discussed earlier, enforcement could have been built into each licensing model. For instance, looking at Figure 9-12, you can see that the generic license model theme is triggered by the Application.launch() as the trigger() method, and then never call the _do_trigger() method. However, this separation is handy, since at some future point, you may want to alter the way in which enforcement occurs without having to change every underlying licensing model. You may, for example, want to issue a warning message rather than simply denying service. Changing that warning method behavior is more convenient if it is encapsulated in the enforcement theme.

The enforce theme actually crosscuts the license themes. Its role is to intercept the license checking, grab the result of the check (whether the license is valid or invalid), and then deny usage if the check is not valid. The enforce theme can be designed as depicted in Figure 9-14. Notice that the current denial of service is simply a system exit (the application is killed). If you want something more elegant to happen, that functionality could be inserted in addition to the call to exit. Notice also that there is no "continue" behavior described in the enforcement theme. The underlying license model theme (which we look at next) is what allows the application to continue start-up once if no enforcement action was taken. The rest of the behavior of the model theme is continued after the final return from the enforce theme.

Figure 9-14. Design of the enforce theme.

Figure 9-15 depicts the feature-based license modelchecking functionality and also the tailored binding specification for the bundled application. Both binding specifications (1 and 2, as marked in the figure) are generated automatically, and composition is performed automatically. The way in which this is carried out depends on the capabilities of the language you choose. We do not delve into dynamic aspect-language details in this book, however.

You can see that the feature-based license actually has two sequence diagrams, one for catching the start of features (at which point the license is checked) and another for triggering logging functionality (which takes place only at application start-up). Had logging occurred at the same time as the license checking, the logging functionality would have been included in the checking sequence diagram. You may recall that it is not allowed in Theme/UML to have two sequence diagrams within a theme both triggered by the same behavior.

Figure 9-16 shows another example of a license model bound to the enforce theme and the base launch theme. In this case, the trigger for enforcement is the start of time logging.