6.2 Connecting the Object Model with the Use Case Model

Now let's look at a number of strategies for identifying the objects and, subsequently, the classes inherent in a system. It's important to connect the object model with the preceding use case model for a couple of reasons.

First, the use case model drives the object model. Each use case will be realized by a set of objects working together. In the UML, this is called a collaboration. As a model element, a collaboration is represented as an oval, similar to a use case but with a dashed line (see Figure 6-2). The collaboration represents a set of objects, assuming specific roles in order to achieve the use case. By concentrating on a use case at a time, we can have help guide our analytic efforts in fruitful directions.

Figure 6-2. Use Cases, Collaborations, and Objects

Second, if we make sure to connect the identified objects to the use case model, we are more likely to build the best system that actually meets the requirements. Some developers ignore the requirements of a system, but they do so at their own peril. It is unfortunately too common to add features to a system so that it does more than is actually required while at the same time failing to meet the specified requirements. Both of these problems can be avoided by letting the use case model drive the object analysis.

Once the object model has been created for the use case, the system-level use cases can be refined to take into account the identified objects and their relations. This allows checking that the object model actually does meet the requirements specified in the use cases as well as illustrating how the objects work together to do it.

In object domain analysis, we want to avoid introducing design, because we want to construct a model of the underlying application domain first. If we are constructing a model of an ECG system Display Waveforms use case, first we want to focus on the essential concepts of that use case, things that are meaningful to the physicians and nurses who will use the system: the heart rate, arrhythmias, scaling in time in (12.5, 25, or 50 mm/sec display speeds are common), scaling in amplitude, and so on. We don't want to worry yet about internal queues to hold data, whether we will use spinlocks or mutex semaphores, how many task threads there are, and so on. The users of the system don't care about those things, but if the system doesn't allow scaling in those two dimensions, if it doesn't understand or produce a heart rate, then the system is fundamentally wrong. The essential or domain model is the construction of an object (and class) model that includes these key concepts and their essential relationships. Later, in design, we will refine the domain model into a design model, but first we need to get the domain model correct.

Every application domain has its own specialized vocabulary and concepts. In actuality, a system is always constructed from elements taken from a large number of domains. Some of these domains are closely related to the problem space while others are closely related to the solution space. For example, in our anesthesia system, the problem-domain domains might be Cardiology, Physiology, and Anesthesiology, as shown in Figure 6-3. These are realized in terms of the more concrete domains of computer science, which are ultimately realized in terms of hardware of various kinds.

Figure 6-3. Domains

The domain diagram^[3] in Figure 6-3 shows several things of interest. First, domains implemented in the UML as a stereotype of Package, and as such hold types and classes. In the UML, packages are used to organize models and have no existence at runtime. The UML does not provide guidance as to how the packages should be organized or how elements should be partitioned into packages.

^[3] Which is nothing more than a class diagram showing the domains as packages.

In the ROPES process, packages are used to organize the model in specific ways by providing specific guidance. In the ROPES process, a domain is a stereotype of Package that adds a criterion for element inclusion the element falls within the subject matter of concern of the domain. Thus, domains serve to represent what the ROPES process calls the logical architecture that is, the organization of things that exist at design time. We can see that each of these packages only contains types and classes relevant to that particular subject matter; the User Interface domain, for example, has user interface things WaveforView, TextView, IconicView, Scrollbar, and so on while the Abstract Hardware domain contains things like sensors and actuators. Other types of organization are, of course, possible, but this one has been successful at organizing systems from tiny to huge, allowing teams to effectively collaborate.

In object domain analysis, objects are uncovered using the strategies outlined in the following section; once they are typed into classes, each class is placed into the relevant domain. Each class is placed into only a single domain in fact, one test for the usefulness of the identified classes and the domain selection is that each class falls in exactly one domain. If a class seems to fall in multiple domains, then the class is probably overly complex and should be decomposed into its independent concepts. For example, consider the ECG concept of a waveform this is both the organization of a set of data samples and a way to visualize this information on a display. In the model in Figure 6-3, "Waveform" is broken up into the notion of the information (the waveform per se) and the notion of a WaveformView.

The use of domains as a model-organizational principle has a number of advantages. First, domains themselves tend to be stable and can isolate the majority of your model from things that are likely to change. For example, suppose that you're not sure whether you're going to implement the system in Windows CE, XP, or VxWorks. By creating a set of OS domain concepts that are isolated from the system, you are ensuring that most of the system will be relatively unaffected by your ultimate decision. Domains can even be subclassed from an abstract domain (such as AbstractOS), which provides the essential concepts of the domain, into specific realizations (such as WindowsCE or VxWorks). This also allows the system to be ported among different domains, such as when you change the OS or networking architecture. Furthermore, if your company produces different products that will work on the same platform environment, then domains help by providing a reusable infrastructure onto which different application or problem domains can sit.