Designing the Concept Sharing Themes
We can now design the base themes for
sms, game, voice call
. These themes are quite simple, so we don't need to investigate their
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
, which dominated the postponed requirement, R1. The individual view for the
theme is shown in Figure 8-4. R2 describes the main
theme operation. R2's functionality will be
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
and helpful, but are not
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
theme to describe in detail the behavior
to volume. The
behavior and the class hierarchy in the
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
class, you would need to provide a minimal specification of those methods in the relevant themes, in anticipation of being
theme. This minimal specification maintains the completeness of each theme and allows them to be
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
class in each of the themes, with the exception of the
theme itself includes only the behavior from R2 (
) from the
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
class that will be merged to the main
class (found in the
theme) on composition.
theme is the product of the merge, as specified by the
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
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.