Designing the Concept Sharing Themes

We can now design the base themes for sms, game, voice call, and media player. These themes are quite simple, so we don't need to investigate their individual-theme views to help clarify the structures that should be involved. It's enough just to read the requirements associated with each theme and move quickly to design from there. In straightforward cases like this, it's fine to skip specifying the structure at the Theme/Doc level altogether.

The only interesting base theme is menu, which dominated the postponed requirement, R1. The individual view for the menu theme is shown in Figure 8-4. R2 describes the main menu theme operation. R2's functionality will be modeled within the menu theme, whereas the implementation of R1 will likely be spread throughout all five themes. You'll notice that there are no structural nodes in this viewthat's because here, too, we chose to skip the step of specifying structural elements this time around. You may have noticed by now that with the exception of the heuristics for aspect identification, the activities available in the Theme/Doc process should be used when convenient and helpful, but are not meant to be religiously adhered to.

Figure 8-4. Menu individual-theme view.

The design for each of the base themes is displayed in Figure 8-5. You can see that we have added an audible theme to describe in detail the behavior related to volume. The Audible behavior and the class hierarchy in the audible theme could have been repeated in the other themes, but in this case, it's fine to place them in a separate theme. However, if any of the themes were to make explicit use of any of the methods in the Audible class, you would need to provide a minimal specification of those methods in the relevant themes, in anticipation of being composed with the audible theme. This minimal specification maintains the completeness of each theme and allows them to be understood in isolation from other themes.

Figure 8-5. Concept-sharing themes and their merge specifications.

Because we have specified merge integration (as denoted by arrows at each end of the composition relationship), all the themes will simply be merged together and any redundancy removed. For instance, there is a Menu class in each of the themes, with the exception of the audible theme. The menu theme itself includes only the behavior from R2 (scroll() and select_item()) from the menu individual-theme view in Figure 8-4.

The postponed R1 requirement (the menu consists of several options...) is not designed as being "owned" by a particular theme. Instead, each theme has its own Menu class that will be merged to the main Menu class (found in the menu theme) on composition.

The phone theme is the product of the merge, as specified by the ThemeName["Phone"] tag.

You'll probably spot that these themes together would not make a working phone. At this point, that's fine. The requirements that we were given for the phone were not comprehensive enough to allow us to make all the design decisions we needed to in order to arrive at a fully functioning phone. In this case study, we just work with these requirements and assume that the rest of the requirements for actually getting things up and running are forthcoming. They can be added in later. They may motivate changes to these themes or may require new themes of their own. For more discussion on what to do with new requirements, refer to the "Incorporating New Requirements" section in Chapter 4.