Modeling: Analysis and Design

ICONIX Process at its heart has two phases: analysis and design (see Chapter 3). The analysis phase consists of domain modeling and use cases analysis, and the design phase involves drawing sequence diagrams, filling in the details on the domain model to create a static model, plus coding and testing. The bridge between the two phases is robustness analysis, which involves plugging gaps in the use cases while also identifying the objects (aka classes) that will be used in the design.

The analysis and design phases can be thought of as inner phases comprising the core modeling activities. Wrapped around these activities, it’s possible to divide the planning process into two outer phases: inception and construction. This approach is adapted from FDD’s two-phase approach, except it’s tailored to suit the ICONIX modeling approach.

During the inception phase, some ICONIX modeling (the analysis part) takes place. During the construction phase, both of the inner ICONIX phases (analysis and design) take place; these in turn are mainly for modeling purposes.

Planning: Inception

The inception phase takes place only once for the entire project. It’s a planning and exploration phase, during which the team gets started, explores the requirements, gets familiar with the technology, does some prototyping, and so on. If you can produce a stable customer release from this first phase, then so much the better, but if the result of the inception phase is simply a bunch of prototype code and a set of requirements, then it’s still a pretty good start. In our example mapplet project, the first release is a prototyping phase during which the team members familiarize themselves with the beta server that they’re working with (see Chapter 6).

Toward the end of this phase, the work should be formalized into a set of use cases (ideally produced with the customer’s direct involvement), which the project stakeholders can review and sign off on. Some preliminary design work should also be done in the inception phase.

DOMAIN MODELING: THE FIRST INCEPTION ACTIVITY

Domain modeling (projectwide) and creating use case diagrams within packages (a package per subsystem) across the project should be done during the inception phase. Just the creation of these diagrams (domain, use case, and package) tends to help make sure we haven’t left any “holes big enough to drive a truck through” out of the original concept.

Also, a sincere attempt to write down the functional requirements needs to happen at this level.After doing this once, we can choose which use cases to attack during each release of the software. The other projectwide parts of the model can adjust during and after each successive release.

The expectation is neither that we can perfectly model the ideal class structure in the domain model nor that we will perfectly be able to diagram out all the use cases of the system up front. We’ll probably miss a few requirements, too, but making a sincere and dedicated effort to do the best we can up front (i.e., trying to get it right the first time) has an enormously beneficial effect. You can usually hit the most important 80% of these things up front, and that makes a huge difference.

The domain model in particular results in a well-defined set of names for the business classes that will participate in the use cases. Almost inevitably, each organization has some name ambiguity in this area, which we can resolve up front.

Planning: Construction

The construction phase takes place for the remainder of the project. This consists of an ongoing series of small frequent releases, each of which may be further divided into smaller iterations for planning purposes.

The core of ICONIX Process is formed of two distinct modeling phases: analysis and design (in which each modeling phase includes specific modeling activities; see Chapter 3). The construction planning phase can be seen as a rapid series of fine-grained analysis and design modeling phases.

Release and maintenance are considered to be part of the construction phase. This is because a product really goes into maintenance from the moment its first release goes to the customer. Similarly, release management is a constant and ongoing activity throughout the construction phase.