Five-Step UML: OOAD for Short Attention Spans - Design, Repeat - Example (Page 3 of 13 )
Let’s start of with an interface for the Owner Info swimlane (which appeared on many of the diagrams we examined in Step 3).
Owner Info Interface We’ll put a corresponding interface on the (currently trivial) Component Diagram, depicted in Figure 2-19.
Figure 2-19. Initial Component Diagram for the Kennel Management System
At the same time, we’ll add the interface to a Class Diagram. Then, looking at the swimlaned Activity Diagrams shown earlier in this chapter, we can pick out the operations of Owner Info. You’ll find that we need two operations: Get or Add Owner and Validate ID. (Some other possible operations are Look Up Owner and Add Owner Record; but because these have been converted to activities inside Get or Add Owner and are no longer called from other swimlanes, we can skip these as operations. We could choose to make them operations, giving us flexibility in the future; but so far, nothing in our architecture requires them to be operations.) So our initial Class Diagram for our interfaces looks like Figure 2-20.
Figure 2-20. Initial interface Class Diagram for the Kennel Management System
Kennel Management Engine Component
Let’s assume that the Owner Info interface will be provided by the Kennel Management Engine, which we’ve just defined. The Kennel Management Engine shall provide a wide range of data management and validation services. It is essentially the middle tier between presentation and storage. We’ll add this as a component to our Component Diagram, which should now look like Figure 2-21.
Figure 2-21. Revised Component Diagram for the Kennel Management System
Other interfaces we can define from our swimlanes (in the earlier Activity Diagrams) are Pet Info and Vital Stats Info. Adding these, our interface Class Diagram looks like Figure 2-22.
Figure 2-22. Revised interface Class Diagram for the Kennel Management System
Both of the new services really belong in our middle tier, and thus belong to the Kennel Management Engine. So our revised Component Diagram looks like Figure 2-23.
Figure 2-23. Component Diagram for the Kennel Management System, second revision
Hmmm . . . not very informative yet, is it? Well, it is, a little: it tells us three sets of things that we can ask the Kennel Management Engine to do. But it will tell us a lot more when we add dependencies.
When we look at our swimlaned Activity Diagrams, however, we see that almost all of our “calls” to our interfaces come from user interface swimlanes, not interface swimlanes. The only exception, as shown in Figure 2-13, is that the Pet Info swimlane has a transition to the Vital Stats Info swimlane. The provider of the Pet Info interface is the Kennel Management Engine; so this implies that the Kennel Management Engine is dependent on the Vital Stats Info interface, as shown in Figure 2-24.
Figure 2-24. Component Diagram for the Kennel Management System, third revision
Although this is legal UML, is it meaningful? Perhaps.
Perhaps we believe that components yet to be defined will need the Vital Stats Info interface, so we need it in our architecture; and then Figure 2-23 would indicate both that the interface exists and that the Kennel Management Engine accesses vital stats through the interface, not through its internal mechanisms. (We might choose this approach so that we may change the architecture to add a separate vital stats component without having to significantly rewrite the Kennel Management Engine.)
On the other hand, we could decide that vital stats will only ever be accessed by the Kennel Management Engine. In that case, we can “collapse” the Vital Stats Info interface, demoting it to a mere class within the Kennel Management Engine. Don’t be afraid to collapse interfaces: discovering superfluous interfaces is a natural part of an evolving architecture. Similarly, don’t be afraid to preserve a seemingly superfluous interface: modularizing and exposing your “internal” services gives you a wide range of architectural choices down the road. You have to select your own balance between simplicity and flexibility; and whichever choice you make, you can always change your mind later. It just may entail some work— maybe a lot of work . . .
In this example, we’ll collapse the interface to yield the diagram shown in Figure 2-25.
Figure 2-25. Component Diagram for the Kennel Management System, fourth revision
OK, so we’ve resolved the vital stats issue; but in the process, we’re back to a pretty simplistic Component Diagram. Looking at our Activity Diagrams, we can see some dependencies that are pretty clearly implied: our user interface swim-lanes have transitions to our interface swimlanes, so some sort of user interface components must lie behind those swimlanes. We just need to define them. Looking at the swimlanes, it appears we need some sort of Check In Form and some sort of Check Out Form. We can add these to the Component Diagram as components, add the dependencies implied by the Activity Diagrams, and voilŕ! We have the Component Diagram shown earlier in Figure 2-18.
Next: Working with User Interfaces >>
More Practices Articles
More By Apress Publishing
|
 This article is from chapter 2 of UML Applied A .NET Perspective written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872). Check it out at your favorite bookstore. Buy this book now.
|
|
/ 7 
