The ICONIX Process

Do It Once, Do It Right

• Extreme Programming is one end of the spectrum
  • If your requirements are always perpetually in flux, focus your process on adapting to/coping with change
• This lecture looks at the other end
  • Well, one of the other ends—it's not like programmers would ever make anything as simple as a two-ended spectrum
• The ICONIX process was developed by Doug Rosenberg and colleagues
  • See [Rosenberg & Stephens 2005] for the definitive guide
  • A simple alternative to the Rational Unified Process (RUP) and other heavyweight paperwork-oriented processes
• Emphasizes up-front analysis and design
  • Reduces total cost and time to delivery dramatically…
  • …provided your requirements are relatively stable
• Probably not appropriate for small, exploratory projects
  • But probably is if you're writing software that's going into a space probe
• Comment on this slide

The Unified Modeling Language

• Many disciplines rely on graphical notations with precisely-defined semantics for design and communication
  • Architectural blueprints
  • Circuit diagrams
  • Feynman diagrams
• Thousands have been invented for programming, but only a handful have ever gained widespread acceptance
  • Flowcharts

    • Figure 27.1: Flowcharts

    • More useful than advocates of structured programming in the 1970s believed
    • See [Scanlan 1989] for evidence and discussion
  • Entity-relationship diagrams
    • Used to design database tables

    • Figure 27.2: Entity-Relationship Diagrams

  • Class diagrams

    • Figure 27.3: Class Diagrams

    • Who inherits from whom?
    • Which classes refer directly to which others
• The Unified Modeling Language (UML) combines several notations used in object-oriented analysis and design (OOAD)
  • Its three principal authors all had their favorite ways of doing things
  • Unlike most designs by committee, this one actually (mostly) makes sense
• UML 2.0 is very large
  • The ICONIX process uses only five kinds of diagram
    • Four from UML, plus one to bridge an important gap
  • Each diagram corresponds to a step in the analysis and design process
• Comment on this slide

From Here to There

• What we have: a prototype of a user interface
  • [Johnson 2000] will help you avoid horrible mistakes
  • If you're trying to get a group talking, [Powazek 2001] is essential reading as well
• Draw it on paper (one screenshot per page)
  • Use sticky notes and the like for menus, dialogs, etc.
  • Test subjects are less likely to hold back criticism of something that looks thrown together
• Write some HTML pages by hand
• Fire up Visual Basic or another drag-and-drop GUI builder
• Make it very clear that this is just a prototype!
  • Or your boss will want to ship it to the customer
• What we want: working code
  • That does what it's supposed to
  • That's been tested
  • That we can maintain

  • Figure 27.4: ICONIX: Start and End Points

• Comment on this slide

Use Cases

• First step is to translate our fuzzy ideas about how the interface should be used into something more exact
• A use case is a short point-form story that describes how a user accomplishes a particular task
  • Usually written point-form
• Example: Sally wants to run a mitosis simulator for each temperature in a range
  • Sally selects “File… Set Simulation Parameters”
    • System displays “Simulation Parameters” dialog with default values
  • Sally changes “Temperature” from “Single” to “Range”
    • System disables temperature entry control for single temperature
    • System enables temperature entry controls for “Start”, “Increment”, and “End”
  • Sally enters values and clicks “OK”
    • If any values illegal or inconsistent, dialog beeps and displays error message explaining the problem
    • Otherwise, simulator updates its values, and dialog disappears
  • Sally selects “File… Run”
    • System enables “Pause” and “Stop” buttons and begins running simulations
• Yes, it's a lot of detail
  • But you're going to have to work it all out at some point
  • And many studies have shown that writing it down and checking it before you start coding leads to a working program faster
  • Also allows QA and technical writing to overlap their work with development
    • Note: make sure they're involved in writing test cases
    • If QA can't think of a way to test something, fix it
    • Ditto if technical writer can't think of a way to explain it
• A use case diagram shows the relationships between
  • The actors in the system (i.e., the users and major system components)
  • The individual use cases
• Comment on this slide

Domain Model

• At this point, have a rough idea of the major elements of the domain model
  • The set of abstractions the system will use to represent the real world
• Example: domain model for a traffic simulator may contain:
  • Vehicles
  • Vehicle types
    • E.g., bicycle, motorcycle, small car, family car, light truck, heavy truck…
    • Each vehicle is an instance of exactly one vehicle type
  • Drivers
  • Driver behaviors
    • A set of statistical rules determining speed, likelihood of signalling, etc.
    • Typically shared by many drivers
  • Road segments
  • Intersections
    • Each road segments connects to exactly two intersections
    • Each intersection connects to one or more road segments
    • “One” in order to model dead end streets
  • Graphical display and other GUI elements
  • Configuration files
  • Etc.
• Domain model diagram shows relationships between domain model elements

  • Figure 27.5: Domain Model Diagram

  • Inheritance: one element is a specialization of another
  • Association: one element refers to another (or two elements refer to each other)
    • Usually annotate with multiplicity
    • I.e., one-to-one, one-to-many, many-to-many
• If you don't get the domain model right, everything else will go wrong
• Note: writing use cases, and defining a domain model, is always iterative
  • Discussion about use cases uncovers new domain model elements
  • Discussion about domain model uncovers new use cases
  • Use a whiteboard, colored markers, and patience
• Like any notation, domain model diagrams exist to help you think and communicate
  • Add comments as appropriate to make meaning clear
• Comment on this slide

Robustness Diagrams

• Re-read the use cases, and classify the objects in the domain model into:
  • Boundary objects, which actors use to communicate with the system
    • The simulator's input widgets and graphical display
  • Entity objects, which are from the core of the domain
    • Vehicle types, road segments, etc.
  • Control objects, which connect boundary objects to entity objects
    • Represent the “intelligence” in the application
    • E.g., driver behaviors
• A robustness diagram shows actors' relationships with these objects

  • Figure 27.6: Robustness Diagram

• The bridge between “what” and “how”
  • What's being implemented: use cases and domain model
  • How it's being implemented: we'll see in a moment
• Rules make intuitive sense from definitions:
  • Actors communicate only with boundary objects
  • Boundary objects communicate only with actors and controllers
  • Controllers communicate with anything except actors
  • Entity objects can only talk to controllers
• These rules are what the graphical notation is for
  • Forces us to classify things
  • Limits how those things can use each other
  • Yes, it's constraining: that's the whole point
• Comment on this slide

Class Diagrams

• A class diagram shows:
  • What members and methods each class has
  • How classes are derived from each other
  • Which classes talk directly to each other
    • Either by holding references
    • Or by being passed to one another as parameters
• Note:
  • Show classes, not individual objects
  • Don't show exact nature of relationship (for example, list vs. dictionary)
    • Some things are better left to code
• Might seem redundant, given that we already have a domain model diagram
  • And given that they use the same notation
• Class diagram (almost) always contains more information than domain model diagram
  • Extra objects added to manage relationships between main classes
  • What members each class has, what its methods will be called, etc.
• Domain model is for talking to users; class diagram is for talking to developers
• An easy way to spot flaws in a design
  • Tangled lines are usually a sign of tangled flow of control
  • One big class in the middle that talks to all the others are usually a sign of poor decomposition
  • Twenty-seven layers of derivation are usually a sign that you should switch to decaf
• Comment on this slide

Sequence Diagrams

• Last piece of the puzzle is to connect the system's static and dynamic aspects
• A sequence diagram shows what methods objects call to communicate with each other during a particular use case
  • Object shown at the top
  • Lifespan of method invocation shown by rectangle
  • Method invocations shown by arrows

  • Figure 27.7: Sequence Diagram

• Note: creating class diagram and sequence diagrams is also iterative
  • “Discover” methods as you realize there's no way for X to ask Y to do something
  • Sometimes realize that one entity ought to be split into several, or vice versa
  • Again, the discussion around the diagrams is as important as the diagrams themselves
• Comment on this slide

Actual Order

• Now that you know what the pieces are, let's put them together
• Phase 1:
  • Identify real-world domain objects and their relationships
  • Start drawing domain model diagram
  • Draw use case diagrams
    • Don't write the use cases themselves yet
• Phase 2:
  • Start writing use cases
  • Create robustness diagram
    • Iterate, iterate, iterate
  • Update domain model diagram to reflect your discoveries
• Phase 3:
  • Draw sequence diagram for each use case
  • Create class diagram by combining information from domain model and sequence diagrams
• Phase 4:
  • Write code that implements class diagram
• Most important rule: if you change something, update everything upstream from it that refers to it
  • E.g., if you add a method while writing code, put it in the class diagram and sequence diagram
• Comment on this slide

A Note on Tools

• Drawing UML diagrams by hand is tedious, error-prone, and counter-productive
  • “Counter-productive” because there's no way to automatically check a hand-drawn diagram against your actual code
• Specialized tools to aid in constructing diagrams have been around a long time
• Span the spectrum from:
  • Pure modeling tools: help users create diagrams, but don't integrate with code
  • Round-trip engineering tools: can translate models into skeletal code, and modified code back into models
  • Some integrate with IDEs, support multiple languages, can talk to databases, etc.
  • ArgoUML is probably the most advanced open source UML tool available
• Most programmers haven't adopted UML modeling tools because:
  • The tools are expensive and/or difficult to learn
    • If people can't do something useful with a tool in the first hour, they usually stop trying
  • But more importantly, they don't find modeling useful
    • “Use the source, Luke”
  • There's a lot of chicken-and-egg in this
    • Until enough programmers create models, and can read them, there's little incentive for any particular programmer to do so
• Comment on this slide

Summary

• Seems like a lot of work, doesn't it?
• But remember:
  • You're going to do all of this anyway
    • You're just doing it in your head…
    • …where it's no use to anyone else
  • It takes less total time
    • See [Glass 2002] , [McConnell 2004] , and [McConnell 1996] for the evidence
    • And the next time someone tells you that XYZ will improve your productivity, ask them for similar evidence…
• So why don't all large projects use this kind of process?
  • Ignorance, laziness, and lack of competitive pressure
    • American car makers in the 1970s sold lots of gas-guzzling rust buckets
    • Then Volkswagen and Toyota arrived
  • It's inappropriate
    • Not good at handling rapidly-changing requirements
  • Learning curve
    • Yes, it'll make you faster on future projects…
    • …but learning it will slow you down on this one…
    • …and if you don't meet this deadline, there won't be any future projects
• Comment on this slide