ICONIX

ICONIX is a lightweight, use-case-driven software development methodology that uses a small subset of UML to carry a project from requirements to code through a tightly defined sequence of modeling steps. It was developed by Doug Rosenberg of ICONIX International and published in Use Case Driven Object Modeling with UML (Rosenberg & Scott, 1999). The name combines the firm’s name with the methodology.

ICONIX sits between two extremes of its era. On one side, the Rational Unified Process (RUP) provided a rich but heavyweight framework of disciplines, phases, and artifacts. On the other, agile methods such as Extreme Programming (XP) favored working code over modeling and documentation. ICONIX’s pitch was that most teams using UML were either over-modeling, RUP-style, or under-modeling, XP-style, and falling into the same trap. Use cases were written but never cleanly connected to a design. ICONIX supplies just enough process to close that gap.

The ICONIX Process

The methodology is built around four core activities, performed iteratively and incrementally.

  • Requirements. Capture the system’s behavior as use cases, each describing an interaction between an actor and the system in pursuit of a goal.
  • Analysis. Build a domain model, a class diagram of the problem domain, and perform robustness analysis – sketching each use case’s main and alternate flows on a robustness diagram using three stereotyped elements: boundary objects, controllers, and entities.
  • Design. Translate each use case’s robustness diagram into a sequence diagram, assigning operations to classes and refining the domain model into a design class diagram.
  • Implementation. Write the code against the design, with the diagrams acting as the blueprint.

The distinctive step is robustness analysis. Robustness diagrams, originally described by Ivar Jacobson and adapted by Rosenberg, force the analyst to decompose each use-case narrative into object interactions before committing to the more detailed sequence diagrams. This intermediate artifact is where ICONIX locates the usual breakdown. Use cases read as prose on one side, a code-shaped design sits on the other, and nothing rigorous connects them.

Why it matters

ICONIX was influential less for its market share than for the critique it embodied. Domain modeling and use-case analysis are only useful when something forces them to meet in the middle. Robustness analysis is that forcing function, and the methodology packages it with a minimal, traceable path from requirements to design. The same insight – that the connection between behavior and structure is where modeling breaks down – recurs in other approaches to software architecture and design, even where the ICONIX notation itself is no longer used.

ICONIX also shares the use-case-driven, iterative ethos of the broader Unified Process family, from which it borrows, but it deliberately drops the phasing, disciplines, and artifact volume that made RUP heavyweight. Where RUP and agile methods diverged on how much modeling is enough, ICONIX argued for a fixed, minimal amount and a specific order to apply it in.

See also

References

  • Rosenberg, D. & Scott, K. (1999). Use Case Driven Object Modeling with UML: Theory and Practice. Addison-Wesley.