Home arrow Practices arrow Page 3 - Five-Step UML: OOAD for Short Attention Spans - Design, Repeat

Example - Practices

This article continues our introduction to the concepts of Five-Step UML, working from beginning to end. It introduces UML notation and goes into great detail. This article covers the final two steps of a five-step process. It is from chapter 2 of UML Applied A .NET Perspective, written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872).

TABLE OF CONTENTS:
  1. Five-Step UML: OOAD for Short Attention Spans - Design, Repeat
  2. Step 4: Process in Detail
  3. Example
  4. Working with User Interfaces
  5. Step 5: Repeat
  6. Step 5: Process in Detail
  7. Creating Activity Diagrams
  8. Adding Swimlanes
  9. Object Flow States
  10. Step 5(a): Process in Detail
  11. Step 5(b): And Again?
  12. Step 5(c): Repeat (In Reverse)
  13. Summary
By: Apress Publishing
Rating: starstarstarstarstar / 11
August 04, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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.



 
 
>>> More Practices Articles          >>> More By Apress Publishing
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: