Stephens and Rosenberg took extreme programming (XP) to task in their 2003 book [1]. Their latest book offers an alternative development methodology: the ICONIX process. In contrast to most agile methods, the ICONIX process has significant upfront requirements definitions and design phases, but it is still pretty lightweight. Rosenberg and Stephens are quick to criticize the unified modeling language (UML) as being too big and largely incomprehensible. They castigate methodologists who advocate for more documentation or activities than they think are needed. As a result, the ICONIX process uses only some features of a few UML diagrams and several other notations, and makes do with streamlined techniques.
Despite these restrictions, the ICONIX process sits squarely in the mainstream of contemporary object-oriented development. The process starts with requirements analysis, followed by design and implementation, with much testing and review along the way. Requirements elicitation and analysis centers on use cases and conceptual (domain) analysis. Engineering design begins with analysis models and is an iterative effort documented in sequence and class diagrams. Implementation uses computer-aided software engineering (CASE) tools to generate code from models. Testing is thorough and tool-based, and reviews occur regularly throughout the process.
The main innovation, as the book’s title suggests, is the employment of use cases as a design and traceability tool. Design details are added to use cases, which are analyzed using robustness diagrams, a sort of object diagram that helps with functional decomposition. The robustness diagrams and detail-laden use cases bridge the gap between general requirements and dynamic detailed design using sequence diagrams. Use cases are also extensively used in reviews and test case generation.
The book presents the ICONIX process in 13 chapters, divided into four parts. Part 1, on requirements definitions, has chapters about domain modeling, use case modeling, and requirements reviews. Part 2 covers robustness analysis, software architecture, and preliminary design reviews. Part 3 consists of four chapters about design and coding that discuss sequence diagrams, critical design reviews, implementation, and code reviews. The last part discusses testing and requirements traceability. The book also includes short appendices (concerning features new to UML 2.0 and the Spring Framework), an index, a preface, and an introduction.
The material is presented through example, and the examples are almost entirely based on an Internet bookstore application. Each chapter has a theory section explaining process steps, techniques, guidelines, notations (illustrated with shorter examples), and a practice section. The practice section is comprised of detailed examples, problems with answers, and short problems without answers. Rosenberg and Stephens work very hard to make the book entertaining and to help the reader keep track of the discussion. Besides taking entertaining swipes at agile methods, UML, and methodologists, they include many (mostly corny) jokes, sidebars, dialogs, lists of various kinds, and interpolated banners with tips, notes, cautions, and so forth. Many diagrams, including orientation diagrams at the beginning of each chapter, and sequences of diagrams illustrate how models change over time.
This book seems to be written for a narrow audience. The appendix about UML only skims the changes in UML 2.0. The appendix about Spring does not explain it well enough to enable readers to follow the text and examples. Consequently, the ideal reader must be familiar with the object-oriented paradigm, UML, Java, JavaBeans, Extensible Markup Language (XML), JUnit, and the Spring Framework, but ignorant of object-oriented development techniques. Such individuals are rare.
Although I agree with many of the criticisms Rosenberg and Stephens level at UML, methods, and methodologists, they dismiss too many useful notations and techniques. Furthermore, they ignore too many important modeling problems. I was not encouraged to trust their judgment when they plainly misused some notations (such as aggregation in UML class diagrams) and incorrectly explained some well-known things (such as the model-view-controller architecture).
I would recommend this book to experienced developers as a fun read. The book adopts an interesting approach that is based on analyzing use cases for design. Still, I would give a novice a more approachable discussion with a broader and more sympathetic treatment of a variety of object-oriented development notations, tools, and processes.
