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

Step 5(b): And Again? - 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).

  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



Some use case practitioners may take issue with the steps I’m recommending here. “Too detailed!” they’ll say. There are business analysts who employ use cases who will argue that the largest of organizations might be modeled with maybe 15 use cases. They will argue— strongly—that more than that is a sign that you’re thinking in too much detail. They will further tell you that you can’t “decompose” a use case into smaller pieces.

But then there are system designers who say, “I was working on a small system last month. It was only around 80 use cases.” (I’ve even heard both perspectives— a few large use cases versus many small use cases—coming from two different people within the same organization.)

So who’s right? Remember: if you ask me “ A or B?” my answer is usually “Yes” or “ C.” This is another “Yes” answer. I think business analysts are right: when trying to think of how to organize a business’s operations, you have to look at very high-level operations. If you have a large number of operations, you can lose track of everything. Their use cases are often along the lines of Accounting and Facilities and Human Resources.

But I think system designers who have more and more detailed use cases are right in that these use cases are more concrete and more implementable. If I ask ten programmers to implement a use case like Facilities, I’ll probably get 20 different implementations—or I’ll get ten programmers throwing things at me for giving them such a lousy spec. But if I ask ten programmers to implement Display Available Facilities, I’ll get a lot closer to consensus.

So it’s important that, at various stages of software development, you have use cases of varying size and scope, ranging from large and broad to small and detailed. I think that the same basic strategy embodied in Five-Step UML— define your system requirements in terms of the use cases needed by something outside your system; refine each use case into a set of activities; assign those activities to parts of your system; design the relationships among those parts; and repeat at the scope of a more detailed part of your system, in an iterative fashion—is a useful strategy across all the scopes of use cases. (It’s also neither new nor earth-shattering; but I think that when merged with UML, it becomes very clear and easy to apply.)

The scopes to which I believe this Five-Step strategy may be applied can be summarized in Table 2-1.

Table 2-1. Five-Step UML at Varying Scopes of Analysis and Design


At this scope, you’re analyzing the organization and functions of an entire business or organization, with a focus on its interactions with other businesses, governments, etc. 

Actors reflect broad categories of external entities: governments, vendors, suppliers, customers, etc.

Use cases reflect the basic operations of the organization.

Structural elements reflect the business units or departments that carry out the operations.


At this scope, you’re analyzing the organization and functions related to particular services of the organization. For instance, if the service is Purchasing, then operations might include ordering, tracking, receiving, and returns. (This scope, falling somewhere in between Business and Domain, won’t be necessary except for larger organizations.)

Actors reflect the individuals and systems that require and carry out these operations.

Use cases reflect the services performed by the business units or departments.

Structural elements reflect broad categories of domain objects that must be maintained, subunits of departments that carry out particular operations, and facilities where operations take place.


At this scope, you’re analyzing particular domain objects that must be represented or maintained in the system.Actors reflect the individuals who require the domain objects, along with the individuals who maintain them.

Use cases reflect the maintenance and transfer of domain objects (documents, schedules, etc.) that support the services of the business units.

Structural elements reflect the specific domain objects maintained, particular teams that carry out operations, and particular machines or devices used in maintaining or producing domain objects.  


At this scope, you’re analyzing the workflows involved in maintaining particular domain objects, along with the user interfaces and components that support those workflows.

Actors reflect the individuals who implement the workflow.

Use cases reflect the steps in the workflow. Use cases may also reflect detailed user interface interactions, when this helps to explain the user interface.

Structural elements reflect the user interfaces, interfaces to other systems, the components that provide the interfaces and user interfaces, other components, and interfaces between the components.


At this scope, you’re designing particular components of the system.

Actors reflect persons and other systems and other components that interact with the component.

Use cases reflect the requests made through interfaces and user interfaces.

Structural elements represent classes and interfaces within each component.


At this scope, you're designing particular classes.

No actors.

No use cases, simply class operations; but these may be analyzed in a fashion similar to use cases.

Structural elements represent attributes, associations, dependencies, and interfaces of each class.

The strategy is important; it’s not just rigid rules about counting use cases. It’s a way of thinking about problems and communicating your thoughts and solutions.

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

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- 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: