Patient Observation: Specification Model

Figure 11-4 reflects modifications I made to the domain model to take into account some of the factors associated with a target language.

Figure 11-4. Patient Observation Specification Model

The patient observation model is now at the specification perspective. It shows the class interfaces rather than the classes themselves . I might keep the conceptual model for another day, but more likely, I will work only with the specification model from this point forward. I try not to keep too many models around. My rule of thumb is that if I cannot keep a model up to date, it goes in the bin. (I know I'm lazy, too!)

Now let's look at the behavior associated with our patient observation model.

The first scenario asks for the latest heart rate of the patient. The first question is: Whose responsibility is it to handle this request? The Patient seems the natural choice. The Patient needs to look at all its observations, determine which are measurements of the Phenomenon Type "heart rate," and find the latest value. To do this, I will have to add a timepoint to Measurement. Because this can apply to other observations as well, I'll add it to Observation, too.

Patient has a similar responsibility exists for Phenomenon: Find the latest Category Observation that has a Phenomenon for the given Phenomenon Type.

Figure 11-5 shows operations that I've added to Patient to reflect my thinking.

Figure 11-5. Patient Observation Operations

Don't try too hard to come up with operations if they are not obvious just yet. The most important thing to go for is a statement of responsibility. If you can cast that in the form of an operation, that's fine; otherwise , a short phrase is useful in describing the responsibility.

Updating the patient's level of consciousness involves creating a new Observation of the appropriate Phenomenon. In doing that, the user would usually like to pick a Phenomenon from a pop-up list. We can handle that by getting the Phenomenon objects associated with a particular Phenomenon Type, as this responsibility is implied by the association between the two.

In adding a measurement, we need to create a new Measurement. An additional complication comes from the fact that the Measurement needs to look to see whether there is a Phenomenon that can be assigned. Here the Measurement can ask its associated Phenomenon Type whether there is a Phenomenon to assign.

There is some collaboration among the objects here. This suggests that this is a good place for a sequence diagram (see Figure 11-6).

Figure 11-6. Patient Observation Sequence Diagram

Do you have to draw all of these diagrams?

Not necessarily . Much depends on how well you can visualize what is going on and how easy it is to work in your programming language. In Smalltalk, it's often just as easy to write the code as it is to think with the diagrams. With C++, the diagrams are more useful.

The diagrams don't have to be works of art. I usually sketch them out on a paper pad or a small whiteboard. I transfer them to a drawing tool (or CASE tool) only if I think it's worth the effort of keeping them up to date because they help clarify the behavior of the classes. At this point in a project, I might also use CRC cards (see page 75) in addition to or instead of the diagrams I've been describing in this chapter.