The following page is excerpted from Chapter 1 of Use Case Driven Object Modeling with UML: Theory and Practice.

Also see the ICONIX Process Roadmap (included as part of Enterprise Architect).

ICONIX Process Overview

The ICONIX Process is an open, free-to-use object modeling process. It’s minimal, use case driven, and agile. The process focuses on the area that lies in between use cases and code. Its emphasis is on what needs to happen at that point in the life cycle where you’re starting out: you have a start on some use cases, and now you need to do good analysis and design.

ICONIX Process (click for a larger image)

The ICONIX Process is divided into dynamic and static workflows, which are highly iterative: you might go through one iteration of the whole process for a small batch of use cases (perhaps a couple of packages’ worth, which isn’t a huge amount given that each use case is only a couple of paragraphs), all the way to source code and unit tests. For this reason, the ICONIX Process is well suited to agile projects, where swift feedback is needed on such factors as the requirements, the design, and estimates.

  1. REQUIREMENTS
    1. Functional requirements: Define what the system should be capable of doing. Depending on how your project is organized, either you’ll be involved in creating the functional requirements or the requirements will be “handed down from on high” by a customer or a team of business analysts.
    2. Domain modeling: Understand the problem space in unambiguous terms.
    3. Behavioral requirements: Define how the user and the system will interact (i.e., write the first-draft use cases).We recommend that you start with a GUI prototype (storyboarding the GUI) and identify all the use cases you’re going to implement, or at least come up with a first-pass list of use cases, which you would reasonably expect to change as you explore the requirements in more depth.
    4. Milestone 1: Requirements Review: Make sure that the use case text matches the customer’s expectations. Note that you might review the use cases in small batches, just prior to designing them. Then in each iteration (i.e., for a small batch of use cases), you do the following.
  2. ANALYSIS/PRELIMINARY DESIGN
    1. Robustness analysis: Draw a robustness diagram (an “object picture” of the steps in a use case), rewriting the use case text as you go.
    2. Update the domain model while you’re writing the use case and drawing the robustness diagram. Here you will discover missing classes, correct ambiguities, and add attributes to the domain objects (e.g., identify that a Book object has a Title, Author, Synopsis, etc.).
    3. Name all the logical software functions (controllers) needed to make the use case work.
    4. Rewrite the first draft use cases.
  3. Milestone 2: Preliminary Design Review (PDR)
  4. DETAILED DESIGN
    1. Sequence diagramming: Draw a sequence diagram (one sequence diagram per use case) to show in detail how you’re going to implement the use case. The primary function of sequence diagramming is to allocate behavior to your classes.
    2. Update the domain model while you’re drawing the sequence diagram, and add operations1 to the domain objects. By this stage, the domain objects are really domain classes, or entities, and the domain model should be fast becoming a static model, or class diagram—a crucial part of your detailed design.
    3. Clean up the static model.
  5. Milestone 3: Critical Design Review (CDR)
  6. IMPLEMENTATION
    1. Coding/unit testing:Write the code and the unit tests. (Or, depending on your preferences, write the unit tests and then the code.
    2. Integration and scenario testing: Base the integration tests on the use cases, so that you’re testing both the basic course and the alternate courses.
    3. Perform a Code Review and Model Update to prepare for the next round of development work.
Follow

Get every new post delivered to your Inbox.