Section 4.1.  Building Systems in Overlays with Use-Case Slices

4.1. Building Systems in Overlays with Use-Case Slices When you realize a use case, you identify the required classes and features (attributes, operations, and relationships) of these classes. Some of these classes and their features are specific to this use-case realization, while others are needed by other use-case realizations. In this section, we introduce the concept of a use-case slice. Each use-case slice keeps the specifics of a use-case realization in one model (e.g., the design model). Those generic and reusable parts are kept in non-use-case-specific slices. All these slices are then superimposed to form the entire design model. Recall our home construction analogy in the preface. This analogy helps us understand what a use-case slice is. When an electrician wants to wire the house, he first describes his intent by drawing lines on a floor plan. The floor plan gives the locations and dimensions of walls, doorways, and so on. From this information, the electrician knows how much work needs to be done. If another specialist wishes to lay phone lines, she takes a floor plan and draws out where the phone lines will be laid. You can get each specialist to draw what he or she intends to do on an overlay (a transparency used on overhead projectors). You can easily sum up the work done by stacking up these overlays and projecting them on the screen. Of course, each overlay must be based on the same floor plan and the same scale. So, use-case slices are analogous to overlays, and composition is simply stacking them on top of each other. The floor plan is analogous to what we call the element structure. A model (e.g., a design model) comprises a hierarchy of elements. You find packages containing classes, classes containing operations, and so on. This hierarchical organization is the element structure. An element's qualified name within the element structure is the path from the top-most element to the element itself. This means that you can uniquely identify a particular element in the model by looking at its fully qualified name. This qualified name is extremely important during composition because it is used by the composition mechanism to determine if elements on two separate use-case slices refer to the same element in the element structure. Use-case slices are separate from the element structure. They are overlaid on top of the element structure and define its contents; that is, they define behaviors that extend the element structure. Use-case slices have dependencies among themselves that describe which use-case slice (or overlay) should be placed first, which should be next, and so on. This leads to another structure, which we call the use-case structure. It is a hierarchy of use-case slices. Thus, a model comprises two structures: The element structure, which identifies elements. The use-case structure, which defines the content within these elements. This composition is illustrated in Figure 4-1. On the left, you see the element structure organized hierarchically in terms of layers, packages, and classes. On the right, you see the use-case structure. For simplicity, we show only one use-case slice, which is stereotyped as «use-case slice». The use-case slice contains element extensions that will be composed (such as through an aspect weaver) into the model with reference to the element structure. Figure 4-1. Element structure space and use-case slices. [View full size image] As can be seen in the figure, the element structure is just a means to identify where elements in the model reside. You treat the elements (i.e., classes) like empty boxes. Their contents (i.e., behavior) will be filled by use-case slices during composition. Up until now, the use-case structure could not be kept separate from the element structure. A developer would have to collate all responsibilities on each class from different use cases and develop the class. This leads to tangling and scattering. But now, by keeping the use-case structure separate from the element structure, the separation of use cases can be preserved. Sidebar 4-1: How Are Use-Case Slices and Hyperslices Related? The term use-case slice is very much in line with the concept of hyperslices in a particular branch of aspect-orientation research known as multidimensional separation of concerns (MDSOC) [Tarr et al. 1999], [Tarr et al. 2000]. Whereas aspects allow you to add features into existing classes, hyperslices allow you to add new classes as well. In essence, when two hyperslices are merged, elements that coincide at the same namespace are merged. This is similar to the «merge» dependency in UML. However, AOP has rich and expressive power for you to define how you can add extensions into existing classes and in multiple extension points at once through the use of wildcards and regular expressions in pointcuts. In this book, we discuss how use-case slices are modeled and implemented through AOP and particularly as a programming language extension like AspectJ [Laddad 2003]. Note that use-case slices are still applicable even if you use MDSOC or, in general, any aspect technology. Although there are similarities between use-case slices and hyperslices, they have different roots and motivations. Hyperslices have their roots in subject-oriented programming. [Harrison et al. 1993]. Use-case slices are motivated by the need to keep peers and extensions separate. Their origins are discussed in Section 1.3.1, "Early Support for Extensions."