The realizations of use cases are modeled using collaborations. Use cases describe a system from the external perspective—how actors interact with the system. Use cases do not describe a system’s internals—how classes within the system collaborate to realize the use case. The internals are modeled by collaborations. A collaboration defines a set of class instances that cooperate to achieve a given task. The task can be the realization of a use case or the realization of an infrastructure mechanism, and so on. Thus, use cases and collaborations are two sides of a coin—the use case describes the system from the external perspective and the collaboration describes the system from an internal perspective. Figure 8-2 depicts the relationship between the Reserve Room use case and its realization modeled as a collaboration. UML denotes a collaboration as a dashed ellipse icon containing the name of the collaboration, and the dashed arrow with a triangle arrowhead in Figure 8-2 denotes the realization relationship in UML.

Figure 8-2. A use case is realized by a collaboration.

A collaboration identifies different roles classes play to realize a use case. The collaboration demands a number of features (i.e., attributes, operations, and relationships) on classes that play these roles. For example, the Reserve Room use-case realization (see Figure 8-3) requires a class to play the role of the resource being reserved. This role is fulfilled by the Room class. Assuming that the Room class at this moment has no such features, you have to extend (i.e., add onto) the Room class with the two required operations updateAvailability() and retrieve().

Figure 8-3. Collaboration identifies class extensions.

A class extension is a modular extension to an existing class to play the role identified by a collaboration (use-case realization). Sometimes, you do not need to add complete operations into the existing class. Instead, you might need only to extend an existing operation with some behaviors to play the role identified by the collaboration. This modular extension to an existing operation is known as an operation extension.

When you realize a use case, you identify classes that participate in the realization and the required roles thereafter expressed as features of these classes. You do this by walking through the use-case specifications, and at each step of a use-case flow, determining the classes you need. In the case of the Reserve Room use-case realization, we have identified two classes: the ReserveRoomHandler class and the Room class. Regarding the Reserve Room collaboration, the classes ReserveRoomHandler and Room play two different roles.

In reality, more classes are involved (e.g., a Reservation class), but for simplicity, we restrict our discussion to just these two classes. We deal with more complex examples in the next part of the book. In addition, the classes ReserveRoomHandler and Room may play other roles in other collaborations (i.e., use-case realizations).

You identify the features required for each class by walking through each step of a use-case description and determining how a particular class instance invokes another class instance. This can be represented using interaction diagrams such as that depicted in Figure 8-4. An interaction diagram depicts the chronological ordering from one class instance to another class instance.

Figure 8-4. An interaction diagram for the Reserve Room use-case realization.

Figure 8-4 shows the sequence of actions that occur when some client invokes the makeReservation() operation on a ReserveRoomHandler instance. The ReserveRoomHandler instance retrieves details of rooms and updates their availability accordingly. This is achieved by calling two operations on a Room instance: retrieve() and updateAvailability().

Once you have identified the required features of each class, you present them in a collaboration, as shown in Figure 8-5. The roles played by the ReserveRoomHandler and Room classes are denoted by labels on the ends of the solid lines (known as associations in UML) joining the collaboration and the class extensions in Figure 8-5.

Figure 8-5. Class extensions required to realize the Reserve Room use case.

In Figure 8-5, each class extension identifies only a subset of a class’s features. Consider the Room class extension. It identifies only the operations updateAvailability() and retrieve(). The complete Room class will have other operations. The final Room class is a composition of all Room class extensions over all use-case realizations.

Figure 8-5 shows only operations in class extensions. In general, a collaboration identifies other kinds of features in a class extension, such as attributes and relationships. You identify these similarly to the way you identify operations. So, it suffices for us to limit our discussion to operations throughout this chapter. We want to keep the discussion simple.

To illustrate how the realization of peer use cases overlaps, we need the help of another use-case realization—the realization of the Check In Customer use case. It involves a new CheckInHandler class, which plays the role of a controller and the same Room class we had earlier. The interaction between these classes when a client invokes the checkIn() operation on a CheckInHandler instance is illustrated in Figure 8-6.

Figure 8-6. An interaction diagram for another use-case realization: Check In Customer.

When a client invokes the checkIn() operation on a CheckInHandler instance, the latter retrieves details of rooms and assigns a lodger to the room. This is achieved by invoking two operations on a Room instance: retrieve() and assignLodger().

The roles played by the classes and the operations required by the Check In Customer use-case realization are summarized in Figure 8-7.

Figure 8-7. Classes extensions required to realize the Check In Customer use case.

Consider the realization of the two use cases above—Reserve Room and Check In Customer. You find that the roles in the Check In Customer collaboration and those in the Reserve Room collaboration are the same. This, however, does not constitute overlap, since these roles belong to different collaborations. This is analogous to two classes having some attributes with the same name. It is legal, and it does not constitute an overlap.

The two use-case realizations require classes that are specific to them, such as ReserveRoomHandler and CheckInHandler. They require classes that are shared—the Room class—which constitutes overlap (i.e., overlapping classes). In addition, the retrieve() operation needed in the Room class extension is used in both collaborations—this also constitutes overlap (i.e., overlapping operations).

In the absence of aspect orientation, a developer today would collate the extensions for each class before implementing the class itself. Some of these classes would be existing classes, and he or she would add the new features into them. Some of these would be new classes that have not been previously identified, and the developer would need to create them in the correct package in the design model. This, as we all know, leads to scattering of the use-case realization and tangling of classes. You need to keep the specifics of a use-case realization separate, which we demonstrate in the next section.

Let us look at how the classes specific to a use-case realization are composed into the design model by considering the ReserveRoomHandler class. Suppose you have organized your design model into layers and packages and you have an application layer, which contains a customer application package within it, and you want to add the ReserveRoomHandler class into it.

You can add this class directly into the designated package in the design model, but that will result in a problem. If you want to remove the use-case slice, you would have to remove all classes that the use-case slice has added as well.

Instead, you want to keep the ReserveRoomHandler class within the Reserve Room use-case slice, as depicted in Figure 8-9. The left-hand side of Figure 8-9 depicts the design element structure. A structure is basically a containment hierarchy of elements of some kind—in this case, of the design element structure. It comprises layers and packages, and classes. The right-hand side depicts a use-case slice containing the specifics of the use-case realization.

Figure 8-9. Overlaying classes within use-case slice onto design element structure.

We now discuss how to overlay the ReserveRoomHandler class in the Reserve Room use-case slice onto the design element structure (see Figure 8-9). First, you need to identify the class uniquely in the design element structure. This is achieved by giving a fully qualified name in the design element structure. Do note that at this moment, the ReserveRoomHandler in the design element structure is empty—you only have its name (see ). A composition mechanism (such as a compiler) would then compose the ReserveRoomHandler in the use-case slice (indicated by ) into the design element structure.

Today, composing use-case-specific classes such as the one in Figure 8-9 is achievable in all compilers. Identifying a fully qualified name is achieved by specifying the namespace of the class in the design model. Namespaces are available in most conventional languages like C++, Java, and C#. In Java, this is achieved with the package keyword, as shown in Listing 8-1.

1.  package app.customer ;
2.  public class ReserveRoomHandler {
3.    public void makeReservation() {
4.      // code
5.    }
6.  }

In line 1, we define the namespace for ReserveRoomHandler as residing in the customer package within the app (application) layer. After defining the namespace, we can start to define the ReserveRoomHandler class, as shown in line 2. Thereafter, we add the makeReservation() operation in lines 3, 4, and 5. Thus, we can keep classes specific to a use-case realization separate in a use-case slice.

When you are working with source code, you are dealing with the implementation model. The implementation use-case structure represents your source files (i.e., *.java). The implementation element structure represents the binary files (i.e., *.class). Note that AspectJ can perform what is known as byte code—it can insert behavior into binaries even without source code.

Let us now look at how to compose class extensions onto existing classes in the design element structure. This capability was not available in conventional languages until the advent of AOP. AOP provides you with intertype declarations to add features on top of existing classes. This is depicted in Figure 8-10 by the arrow labeled compose. The features to be overlaid onto an existing class are collated within a class extension.

Figure 8-10. Overlaying class extensions within use-case slices onto the design element structure.

In our example, the Room class is an existing class within the design element structure. It has been previously overlaid onto the design element structure, and now we want to overlay additional class extensions. Let’s assume that the Room class resides in the room package in a domain layer. Having identified the Room class, we can now overlay the Room class extension specific to the Reserve Room use-case slice onto the Room class in the design element structure.

This is achieved in AOP using aspects with intertype declarations. We call this aspect ReserveRoom, since it is used in the realization of the Reserve Room use case—we simply remove the space within string “Reserve Room.” Compilers today don’t like spaces. Listing 8-2 shows how you can add an operation to the existing Room class.

1.  package app.customer ;
2.  import domain.room.Room;
3.  public aspect ReserveRoom {
4.  public void Room.updateAvailability() {
5.  // code
6.  }
7.  }

Like the ReserveRoomHandler class, the ReserveRoom aspect resides in the application-layer customer package (see line 1 of Listing 8-2). This is the namespace for the aspect, not the class you are extending. Line 2 identifies the existing Room class that you want to extend. In lines 4, 5, and 6, we extend the Room class in the design element structure with a new operation, updateAvailability().

In this case, the aspect contains an intertype declaration for only one class. However, in general, you will compose multiple operations onto multiple classes. It will be natural for you to organize these intertype declarations that add features to the same class together, which is not required by AOP or AspectJ, in particular, but we find it a good practice to do so. That is why we have class extensions—they are modular extensions onto existing classes.

In addition, it is important to have a means to visualize and understand the overall effects aspects have on each individual class. Hence, it is extremely useful to explicitly model all advices and intertype declarations on each existing class. Moreover, this is how you work with collaborations today—you identify roles and then the attributes, operations, and so on, for that role. So, you see that class extensions are derived naturally when you identify roles in a collaboration. Thus, there is indeed methodological support for using class extensions.

Our proposed UML aspect contains class extensions, as depicted in Figure 8-11. This figure shows the ReserveRoom aspect containing a class extension called Room. The class extension is named this way so that you know which class its features must be composed into. In this case, the class extension has an updateAvailability() operation. During compilation, this will be composed into the existing Room class.

Figure 8-11. Proposed UML aspect construct containing class extensions.

Recall that a use-case slice also has a collaboration describing the realization of the use case. The collaboration only describes a view of the model’s internal structure (comprising classes, subsystems, components, etc.) to show which of these elements are needed to realize the use case. The collaboration is not part of the internal structure itself. Consequently, you do not need an implementation construct for a collaboration.

How to Implement Use-Case Slices with Eclipse

For those who are familiar with Eclipse Integrated Development Environment (IDE), we show how to keep the use-case structure and the element structure separate. Note that this is but one example of applying the concept of use-case slices. In this case, we apply compile-time composition of use-case slices.

Each use-case slice or non-use-case-specific slice has its own source folder ( in the figure above). This is where developers spend their time writing Java codes for each slice. The design element structure is located in the output folder ( in the figure above). Basically, the AspectJ compiler compiles each use-case slice and composes the result into the design element structure.

An included use-case slice is used to factor out commonalities across use-case realizations. Figure 8-12 shows the Reserve Room use case, including the Check Room Details use case. The Check Room Details use case is a utility use case that contains a set of flows that are useful for making general queries on rooms, such as checking room availability, checking room rates, checking who is staying in the room at the moment, and checking the outstanding charges for the room. Such flows are included not only by the Reserve Room use case but also by many other use cases in the Hotel Management System, such as Check In Customer and Check Out Customer use cases.

Figure 8-12. Factoring out common behaviors with use-case include.

The Check Room Details use case provides the ability to retrieve rooms. Let’s assume that this functionality is used often and there is some caching mechanism to make retrieval faster. The realization of the Check Room Details use case comprises two classes: CheckRoomHandler, which plays the role of a controller, and the Room class, which plays the role of a resource.

Figure 8-13 shows the interaction between instances of the two classes. Let’s assume that the CheckRoomHandler maintains a local cache containing data values of room details to minimize retrievals from the data-store. When some client invokes the retrieveRoom() operation on a CheckRoomHandler instance, the latter first tries to get data values from its cache. If the data values are not available, CheckRoomHandler instance invokes retrieve() on a Room instance to retrieve them from the datastore. If local data values are available, it is returned to the client.

Figure 8-13. Interaction diagram: Check Room Detail use-case realization.

Let us see how the include relationship between use cases gets propagated to their use-case realizations and, hence, how the including use-case slice can make use of the included use-case slice. This is modeled as a dependency between use-case slices. Figure 8-14 shows the Reserve Room (i.e., including) use-case slice, including the Check Room Details (i.e., included) use-case slice. We model the include relationship between use-case slices as a dependency stereotyped as «include».

Figure 8-14. Include across use-case slices.

Recall that a use-case slice comprises collaborations, classes, and features specific to a use case in a model. Thus, semantics of the include relationship between use cases gets translated to relationships between these elements.

Recall that a parent use case has two purposes. First, it defines common behaviors that can be inherited by their children. Second, it acts like a template for their children. Figure 8-15 shows the Reserve Room use case inheriting from a Reserve Facility use case. The Reserve Facility use case is an abstract use case that describes in general terms the sequence of actions leading to the reservation of a facility. The Reserve Room use case specializes the Reserve Facility use case for making room reservations.

Figure 8-15. Factoring out common behaviors with use-case generalization.

The realization of the parent use case is depicted through an interaction diagram in Figure 8-16. It shows the interaction between instances of the two classes. When some client invokes the makeReservation() operation on a ReserveFacilityHandler instance, the latter invokes retrieve() on a Facility and thereafter updates its availability.

Figure 8-16. Interaction diagram: Reserve Facility use-case realization.

Let us see how the generalization relationship between use cases is propagated to their use-case realizations and, hence, how the child use-case slice can utilize the parent use-case slice. Figure 8-17 shows the contents of the two use-case slices. We call the Reserve Room use-case slice the child use-case slice and the Reserve Facility use-case slice the parent use-case slice. For the purpose of discussion, let’s assume that both operations, makeReservation() and updateAvailability(), are abstract and that the retrieve() operation is concrete.

Figure 8-17. Generalization across use-case slice.

Some classes are part of the problem domain, and they are used in many use-case realizations. The realization of the Reserve Room use case and the Check In Customer use case need the same Room class. In fact, this Room class us needed by many other use-case realizations, even included use-case slices like the Check Room Details discussed above.

The Room class is part of the domain and is fundamental to the Hotel Management System. Without rooms, there wouldn’t be a hotel, let alone a Hotel Management System. Hence, the Room class is not use-case-specific and should not be defined in a use-case slice. Instead, it is part of what we call a non-use-case-specific slice. It is stereotyped as «non-uc specific slice». Other use-case slices will extend it, as depicted in Figure 8-18.

Figure 8-18. Dependencies on non-use-case–specific slice.

A non-use-case-specific slice is different from a use-case slice in that it contains no aspects. This is because it defines a base and does not need to add to any existing classes. Non-use-case-specific slices usually represent a domain of some kind. It can be a business domain, such as Hotel Management (see Figure 8-18), or it can be used to represent some technical or infrastructural domain, such as user interfaces or communications. These also normally need a set of common classes, which individual use-case slices will add on to. For example, different use-case slices might need to add their respective menu options to a common menu bar. We present many examples of non-use-case-specific slices in Part IV of the book when we discuss how to establish an architecture based on use cases and aspects.