Software Reality
Programming with
a dose of satire.

Site Map Search

Agile Development
Extreme Programming
Code Generation


Check out our ageing Reviews Section

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.


Agile Development with ICONIX Process: Table of Contents

A page from the book

The ICONIX Process is an open, free-to-use object modeling process. It's minimal, use case driven, and agile.

Book overview

PART 1: ICONIX and Agility

The first part of this book lays the groundwork for the discussions and examples that follow.

Chapter 1: What is Agility?
We begin in Chapter 1 with an introduction to software agility, including a discussion of what agility is and isn’t. We also compare some of the popular agile processes which are available "out there", including XP, Scrum, FDD and the Crystal series.

Chapter 2: What are the Qualities of an Agile Development Process?
In Chapter 2 we hunt for the “sweet spot” between agility and discipline, and focus on the human-centric and communication issues that are strongly stressed in agile processes.

Chapter 3: The ICONIX Process (a Core UML Subset)
In Chapter 3 we summarize ICONIX Process (as defined in Doug’s first two books). ICONIX Process is a lightweight, pragmatic A&D process for getting from use cases to source code reliably, in as few steps as possible. Essentially, ICONIX Process is a core subset of UML diagrams and techniques.

Chapter 4: Agile ICONIX Process: A Core Subset of Agile Practices
In Chapter 4 we define a minimalist core subset of agile methods, which we illustrate by example in Part 2.


PART 2: Agile ICONIX Process in Practice: The Mapplet Project

This part of the book features a running example project that will thread through the various chapters. We’ll illustrate many of the points we made in Part 1 using this example project. The project is real—it’s not an academic exercise—and we’ve taken snapshots during the various iterations of modeling, prototyping, and C# coding. And, not only can you see the use cases and the design evolve in the book, but you can interact with the finished product on the website and compare the live software to the original requirements.

This being a book about agile development (i.e., adapting to changing requirements over time), our idea is to present the original project requirements and show that even though the requirements evolved over the course of the project, we were still able to incorporate up-front modeling into the development process. The story that unfolds is very much the story of how to approach this situation.

Chapter 5: Introducing the Mapplet Project
This chapter provides an overview of the central example project. The "mapplet" (map applet) project is a web-based hotel finder built on top of ESRI's ArcGIS Server platform. We also show the initial version of the domain model (which evolves throughout the project) and the team's "first-pass" attempt at some use cases; and we create a release plan from the use cases.

Chapter 6: Modeling the Mapplet (Release 1)
This chapter chronicles the development of release 1 of the mapplet. Release 1 was in fact an exploratory prototype, and the team did minimal modeling as their main concern was to familiarize themselves with the server technology.

Chapter 7: Synchronizing Model and Code: One Small Release at a Time
It turned out that the prototype was good enough to base the main product on. So in this chapter we show the refactoring (both of the code and the model) which took place to kick it into commercial-grade shape. This chapter also demonstrates the value of bringing the code and the design model in sync at the end of each release increment; enabling the next effort. We discuss some nifty features of the Enterprise Architect modeling tool from Sparx Systems that can help you accomplish this.

Chapter 8: Mapplet Release 2
This chapter covers the second release increment of the mapplet project. We begin with some new use cases and take them through to source code. This chapter also introduces an extension to ICONIX Process, persona analysis (described in detail in Chapter 10), to help drive the requirements.


PART 3: Extensions to the ICONIX Process

In this final section of the book, we define some extensions to ICONIX Process that two of this book’s authors have tested and found to work well in an agile environment. Specifically, these extensions relate to adaptive planning, persona analysis, and a combined usage of test-driven and use case–driven development.

Chapter 9: Agile Planning
Planning an agile, iterative, and incremental project involves many concerns, trade-offs, and judgment calls. In this chapter, we discuss a number of agile planning principles to help you plan (and maintain the plan for) an Agile ICONIX project. These principles are summarized as a top 10 list at the end of the chapter.

Chapter 10: Persona Analysis
The approach that this chapter proposes makes actors more concrete, more tangible for project stakeholders (the businesspeople—usually nontechnical—who must contribute to and understand the use cases). Many people find actors and use cases too abstract, so this chapter addresses the issue head-on.

Chapter 11: Vanilla TDD Example
This chapter shows a Test Driven Development (TDD) example, using the Java code and the JUnit tests to drive the design. The purpose is to contrast the issues addressed by the process with a combined ICONIX+TDD process, which we show in the next chapter.

Chapter 12: TDD and the ICONIX Process
In this chapter we repeat the example from Chapter 11, using a combination of ICONIX Process and TDD. We show how to drive the unit tests (and thus the low-level design) from the controllers on your robustness and sequence diagrams (which in turn are driven from the use cases and domain model). Using this combined ICONIX+TDD process, TDD comes into its own as a form of design validation.



<< Back to Design

<< Back to the Front Page


All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.