Key Points to Remember | Agile Development with ICONIX Process: People, Process, and Pragmatism

This chapter is a (very) condensed summation of Doug’s other books on ICONIX Process, and those books are in turn a compact distillation of the UML and Jacobson’s Objectory method. So you could view this chapter as one big “key point to remember.” However, it’s still worth closing with the most important take-away concepts, which are presented in the sections that follow.

Key Terms

When applying ICONIX Process to an agile project, keep these terms and their definitions in mind:

Elicitation: Writing the requirements and use cases down. For use cases, this includes basic and alternative courses (sunny-day/rainy-day scenarios).
Disambiguation: Removing the ambiguity from the requirements that have just been elicited.
Object discovery: Deciding what classes and objects you’ll need to support the disambiguated requirements (this happens concurrently with disambiguation during robustness analysis).
Prefactoring/model refactoring: Mapping the set of software functions you’ve identified to implement the (disambiguated) requirements onto the set of classes you’ve discovered. Making sure this mapping is clean and that each class is responsible for a cohesive set of methods, following the principles of responsibility-driven development. Prefactoring is best accomplished on sequence diagrams, which are used to allocate operations to classes on class diagrams. (We revisit prefactoring in more detail in Chapter 4.)

Core Analysis Modeling Practices

ICONIX Process’ analysis phase centers on these three essential activities:

Functional requirements definition (write ’em down)
Behavioral requirements capture (use cases)
Requirements disambiguation (robustness analysis)

If you perform all three of these activities (in one form or another), then you greatly increase the chances of your project succeeding.

Core Design Modeling Practices

ICONIX Process’ design phase centers on these essential activities:

Cleaning up, adding infrastructure/scaffolding to, and applying design patterns on (if appropriate) the class diagrams. (That is, moving the class model from a pure problem domain model into a solution space model that reflects the detailed technical architecture of the system. This includes nailing down “plumbing” issues on both the GUI and the database ends.)
Prefactoring operations to classes (behavior allocation by drawing message arrows on sequence diagrams).
Reviewing and cleaning up the detailed class diagrams, adding in details like parameter-passing on the operations, and doing any other preparation needed to finalize the class diagrams before coding. This is done in parallel with the sequence diagrams.
Writing unit tests (see Chapter 12).
Generating code skeletons.

As with the core analysis modeling practices, performing these activities will greatly increase your project’s chances of success.

Putting It All Together

So, what does all this stuff about “elicitation, disambiguation, and prefactoring” mean in practice?

ICONIX Process attempts to provide the most efficient path to building high-quality OO code. This doesn’t mean “just start coding immediately,” because, while jumping in prematurely might be the quickest path to code, it isn’t usually the quickest path to high-quality code. Rather, it’s more often the quickest path to code that “smells funny.”^[10.] Before we can get high-quality code, a few things need to happen:

A shared understanding of the problem domain and accompanying vocabulary for describing it must exist.
Requirements need to be defined by the customer.
Requirements need to be unambiguously communicated from the customer to the developer.
Both sunny- and rainy-day scenarios need to be explored as a detailed understanding of required system behavior is gained.
Classes need to be defined that can encapsulate the required behavior of the system.
A clean allocation of functions to classes must be performed.

While there are differences of opinion on how these steps should be accomplished, nearly every approach to software development—including agile approaches—at least acknowledges the existence of the steps. In XP, for example, the list looks like this:

1. Create a system metaphor.^[11.]
2 and 3. Co-locate the on-site customer with the programmers. Rely on error-free verbal communication.^[12.]
4. YAGNI^[13.] the rainy-day scenarios—just code what you need today.
5. Code the simplest thing that can possibly work (DTSTTCPW).
6. Perform Constant Refactoring After Programming.

So, the steps are the same, but the approach is very different. Here’s how the steps look in ICONIX Process:

1. Perform domain modeling. Draw a simplified class diagram that identifies the major nouns (objects) from the problem domain. Use generalization and aggregation relationships as appropriate to relate these classes to one another. Don’t spend more than half a day on your domain model.
2 and 3. Elicit requirements. Write the requirements down. You’ll be amazed how this exercise helps to focus your view of the system.

Obviously, this is a customer-driven activity. You’ll be amazed at how much less you’ll need to rely on a full-time on-site customer if the customer just writes a (brief, minimalist) statement of what the system has to do. A two- or three-page list of requirements can go a long way. See the mapplet requirements in Chapter 6 for an example of how to do this.
4a. Write first-draft use cases. Keep them to about two paragraphs apiece, and make sure they have both sunny- and rainy-day sections. Expect them to be vague, ambiguous, incomplete, and (in some cases) incorrect. Also expect them to be a heck of a lot better than what you’d have if you didn’t write them.

Review the use cases with your customer, and try to clean them up the best you can. Try especially hard to make sure you haven’t forgotten any of the rainy-day scenarios.
4b. Disambiguate the use cases (remove the ambiguity from them) using a robustness diagram. Drawing an “object picture” of the use case works incredibly well as a disambiguation technique. Once you learn the technique, these diagrams take about 10 minutes apiece to draw.
5. Discover classes/objects. This is also accomplished on robustness diagrams concurrently with disambiguation. When you draw an “object picture” of a use case, you may discover that you’ve forgotten some objects. So you add them and produce an updated domain model. Time spent to do this is included in the preceding 10 minutes per robustness diagram estimate.
6. Perform prefactoring. Allocate methods to classes. Do this using a sequence diagram, and with modern tools the operations automatically get assigned to the classes. Spending half an hour drawing a sequence diagram is a lot more efficient than refactoring it and rewriting your unit tests, rerunning your unit tests, and so on.

^[10.]As we explored in Extreme Programming Refactored: The Case Against XP, XPers often like to talk about “code smells,” meaning crufty code (i.e., badly written code that’s trying to tell you it needs rewriting).

^[11.]A system metaphor is an overview of the architecture. It’s a simple, shared story of how the system works. See http://c2.com/cgi/wiki?SystemMetaphor.

^[12.]Riiiight …

^[13.]YAGNI is an acronym for You Aren’t Gonna Need It. That is, don’t code what you think you need, just code what the tests need to make them pass. To put it another way, “Don’t worry, be happy.”