by Doug Rosenberg and Kendall Scott

We need to see more use case and Unified Modeling Language examples" is a demand we hear fairly often these days. Although we present a fairly extensive example in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), we recently convinced Addison-Wesley to let us produce a companion workbook, in which we will dissect the design of an Internet bookstore, step-by-step, in great detail. This will involve showing many common mistakes, and then showing the model with its mistakes corrected.

This article is the first in a series of five that will provide a prepublication look at the annotated example from the workbook (to be called Applied Use Case Driven Object Modeling, conveniently enough) as it evolves. We'll be following the process detailed in our book (also known as the ICONIX process), which sits somewhere between the very large Rational Unified Process (RUP) and the very small Extreme Programming (XP) approach.

The ICONIX process is use case driven, like RUP, but lacks a lot of the overhead that RUP brings to the table. It's also relatively small and tight, like XP, but it doesn't discard analysis and design like XP does. This process also makes streamlined use of UML while keeping a sharp focus on the traceability of requirements. And, the process stays true to Jacobson's original vision of what "use case driven" means, in that it results in concrete, specific, readily understandable use cases that a project team can actually use to drive the development effort.

Each of the articles that follow this one will address an essential aspect of the process by focusing on one of the four critical diagrams used in the Iconix process. These four articles will have the same basic look and feel, with these shared elements:

• A "top 10" list that describes modeling errors to avoid.
• A diagram that shows two or three violations of these top 10 rules, as committed by students in classes that we've taught.
• Another diagram that shows corrections of the erroneous material.

Best of Breed
Figure 1 shows the "big picture" for the process. The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently. The approach is flexible and open; you can always select from the other aspects of UML to supplement the basic materials.

The second article will discuss domain modeling. This is the task of discovering classes that represent the things and concepts related to the problem that a system is being designed to solve. We'll describe how the domain model serves as a glossary of terms that people can use in writing use cases.

Domain modeling involves working outward from the data requirements to build a static model of the problem domain relevant to the proposed system. We'll point out how the approach emphasizes domain modeling more than RUP, and certainly more than XP.

The third article will discuss how to write use cases that detail the scenarios that the users will be performing. We'll describe how to write complete and unambiguous use cases that describe individual aspects of system usage without presuming any specific design or implementation.

Use case modeling involves working inward from the user requirements to start building a dynamic model of the solution space for the proposed system. We'll talk about how use cases, by extension, drive the entire development effort.

The Forgotten Diagram
The fourth article in the series will discuss robustness analysis, a practice that originated with Ivar Jacobson but was dropped from the Rational implementation of UML. This involves analyzing the narrative text of use cases, identifying a first-guess set of objects that will participate in those use cases, and classifying these objects based on the roles they play.

• Boundary objects are what actors use in communicating with the system.
• Entity objects are usually objects from the domain model.
• Controllers serve as the "glue" between boundary objects and entity objects.

We'll show how robustness analysis, which serves as preliminary design within the process, provides the missing link between analysis and detailed design.

The fifth and last article will discuss interaction modeling, the phase in which people build the threads that weave their objects together and enable them to start seeing how the new system will perform useful behavior. We'll demonstrate how to build sequence diagrams, which enable designers to perform three key tasks:

1. Allocate behavior among boundary objects, entity objects, and controllers that will become full objects in the model.
2. Show the detailed interactions that occur over time among the objects associated with each use case.
3. Finalize the distribution of operations among classes.

We'll explain how the detailed, design-level class diagrams that result from interaction modeling represent a suitable foundation for moving into the coding phase of a project.

We'd like to point out three significant features of this approach.

First, it's iterative and incremental. Multiple iterations occur between developing the domain model and identifying and analyzing the use cases. Other iterations exist, as well, as the team proceeds through the life cycle. The static model gets refined incrementally during the successive iterations through the dynamic model (composed of use cases, robustness analysis and sequence diagrams). Please note, though, that the approach doesn't require formal milestones and lots of bookkeeping; rather, the refinement efforts result in natural milestones as the project team gains knowledge and experience.

Second, the approach offers a high degree of traceability. At every step along the way, you refer back to the requirements in some way. There is never a point at which the process allows you to stray too far from the user's needs. Traceability also refers to the fact that you can track objects from step to step as analysis melds into design.

Third, the approach offers streamlined usage of UML. The steps that we'll describe in the upcoming articles represent a "minimalist" approach-they comprise the minimal set of steps that we've found to be necessary and sufficient on the road to a successful OO development project. By focusing on a subset of the large and often unwieldy UML, a project team can also head off "analysis paralysis" at the pass.

E-Commerce Example
We'll demonstrate these aspects of the ICONIX process in the context of an on-line bookstore. The focus will be on the customer's view of the system.

Article two will describe how to build a domain model that has loosely coupled classes, each of which does one thing well.

Article three will discuss how to write small, concise use cases that capture functional requirements in terms of user actions and system responses in a way that's easy for readers to understand at a glance.

Article four will demonstrate how to do robustness analysis in order to tighten up use cases and make it easier to head into detailed design.

Article five will explore sequence diagrams, which we'll use to allocate the behavior specified by use cases to the objects mentioned in those use cases.

See you next month.