Agile Development with ICONIX Process: People, Process, and Pragmatism - page 23

Summary

In this chapter, we set a primary goal for this book of identifying the sweet spot between agile, feedback-driven software processes and disciplined, plan-driven software processes. We then dissected a software process into its subcomponents and analyzed each subcomponent individually, discussing the trade-offs that you can make within each layer. We followed that with a “fact or fiction ” discussion that focused on the human-centric communication issues related to software process.

The next chapter presents a brief introduction to ICONIX Process, a use case–driven approach that uses a minimalist core subset of UML. In Chapter 4, we’ll next attempt to define a minimalist core subset of agile practices. Then we’ll see how close we came to the sweet spot by exploring the design and code for our example project.

Chapter 3: ICONIX Process—A Core UML Subset

Overview

In this chapter, we provide an overview of ICONIX Process, a minimal object modeling process that is well suited to agile development. This overview should give you enough information to get started using the modeling techniques in your own project. For an in-depth description of ICONIX Process, see Doug’s previous two books, Use Case Driven Object Modeling with UML: A Practical Approach ^[1.] and Applying Use Case Driven Object Modeling with UML . ^[2.]

Note

Doug and Matt are currently under contract with Addison-Wesley to replace the two previously mentioned titles with a combined title: Use Case Driven Object Modeling: Theory and Practice . ^[3.]

You’ll find that we don’t cover software agility much in this chapter. We’re presenting ICONIX Process as a core object modeling process, then in Part 2 of this book we’ll show an example of how to apply Agile ICONIX to a real-life project.

Note

In later chapters we provide lots of practical examples to show exactly how ICONIX Process is applied. So in reading this chapter, you might find it useful to skip ahead and look at some of the later examples. Similarly, when reading the later chapters in detail, you might find it useful to refer back to this chapter frequently to get a reminder of the underlying theory.

Figure 3-1 shows how ICONIX Process defines a practical core subset of the Unified Modeling Language (UML). This diagram ties in with Figure 4-1, which shows how Agile ICONIX defines a core subset of agile practices.

image from book
Figure 3-1: ICONIX Process core UML subset

^[1.] Doug Rosenberg and Kendall Scott, Use Case Driven Object Modeling with UML: A Practical Approach (New York: Addison-Wesley, 1999).

^[2.] Doug Rosenberg and Kendall Scott, Applying Use Case Driven Object Modeling with UML (New York: Addison-Wesley, 2001).

^[3.] Doug Rosenberg, Matt Stephens, and Kendall Scott, Use Case Driven Object Modeling: Theory and Practice (New York: Addison-Wesley, 2005).

A Brief History of ICONIX Process

In this section, Doug explains the history and background of ICONIX Process.

ICONIX Process originated several years before the UML and the Unified Process as a synthesis and distillation of the best techniques from the original methodologies that formed the UML: Jim Rumbaugh’s Object Modeling Technique (OMT), Ivar Jacobson’s Objectory method, and Grady Booch’s Booch method.

We attempted a synthesis of these three very different schools of object-oriented (OO) thought because the strengths and weaknesses of these methodologies seemed to complement each another. OMT was useful for problem domain (analysis-level) modeling, but it was not as strong for solution space (detailed design) class modeling, while the Booch method was strong at the detailed level but unintuitive at the analysis level. The Objectory method took Booch’s concept of a dynamic model and extended it with a step-by-step approach that leads cleanly from a use case view to a detailed design (sequence diagram) view of the runtime behavior. Both OMT and the Booch method were stronger for static (class) modeling, while the Objectory method is mostly focused on dynamic runtime behavior. Booch also introduced component and deployment views of the system.

Rather than taking the complete contents of three 400-page methodology books and encompassing everything about everything (see The Unified Modeling Language User Guide ^[4.] ), we preferred to focus on a core subset of these techniques that removed the redundancy and overlap from the notations. For example, both sequence and collaboration diagrams show essentially the same thing: a runtime view of object collaboration. These views are so redundant that you can draw a sequence diagram in Rational Rose, press F5, and automatically generate a collaboration diagram. Over the decade or so that we’ve been teaching this material, we discovered that most people generally prefer learning (and using) a smaller set of diagrams over a larger set, and we were able to consistently get good results by focusing our students more intensively on a smaller set of diagrams. ^[5.] Ultimately, we wound up with a UML core subset consisting of the following:

Class diagrams , at both an analysis (problem domain) and design (Booch) level of abstraction.
Use cases (diagrams and text).
Sequence diagrams . We skipped collaboration diagrams because they were redundant, and we deemphasized state diagrams because we discovered that many projects needed fewer of them than we anticipated if project teams rigorously created sequence diagrams.
Robustness diagrams . We “rescued” these from Jacobson’s Objectory work because we discovered that use case–driven development simply worked better with these diagrams than without them.

^[4.] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide (New York: Addison-Wesley, 1998).

^[5.] We’re happy to note that some enlightened visual modeling tool vendors have recognized that the UML is just too big for many folks and that a core subset is much easier to work with. For example, the Enterprise Architect tool from Sparx Systems, which fully supports UML2, and which we used for the example project in this book, offers an “ICONIX Process visual layout” that hides about 70% of the UML from users who prefer a minimalist, streamlined approach to modeling.