- A Walk (Backwards) though the ICONIX Process
- Key Features of the ICONIX Process
- Process Fundamentals
- The Process in a Nutshell
- Requirements List for The Internet Bookstore
Key Features of the ICONIX Process
Figure 1-7 shows the essence of a streamlined approach to software development that includes a minimal set of UML diagrams, and some valuable techniques, that you can use to get from use cases to code quickly and efficiently. The approach is flexible and open; you can always elect to use other aspects of the UML to supplement the basic materials.
){kind=link}
We'd like to point out three significant features of this approach.
First, the approach offers streamlined usage of the UML. The steps that we describe in the upcoming chapters represent a "minimalist" approach—they comprise the minimal set of steps that we've found to be necessary and sufficient on the road to a successful OO development project. By focusing on a subset of the large and often unwieldy UML, a project team can also head off "analysis paralysis" at the pass.
Second, the approach offers a high degree of traceability. At every step along the way, you refer back to the requirements in some way. There is never a point at which the process allows you to stray too far from the user's needs. Traceability also refers to the fact that you can track objects from step to step, as well, as analysis melds into design.
Third, the approach is iterative and incremental, although we might not be using these terms in the traditional sense. Multiple iterations occur between developing the domain model and identifying and analyzing the use cases. Other iterations exist, as well, as the team proceeds through the life cycle. The static model gets refined incrementally during the successive iterations through the dynamic model (composed of use cases, robustness analysis, and sequence diagrams). Please note, though, that the approach doesn't require formal milestones and a lot of bookkeeping; rather, the refinement efforts result in natural milestones as the project team gains knowledge and experience.
As we described in the Preface, we're going to demonstrate these aspects of the ICONIX process in the context of an on-line bookstore; the focus will be on the customer's view of the system.
The fact that we've been able to teach this process, with only minimal changes, over an entire decade, with it remaining useful and relevant today, is made possible because our process is based on finding the answers to some fundamentally important questions about a system. These questions include the following:
Who are the users of the system (the actors), and what are they trying to do?
What are the "real world" (problem domain) objects and the associations among them?
What objects are needed for each use case?
How do the objects collaborating within each use case interact?
How will we handle real-time control issues?
How are we really going to build this system on a nuts-and-bolts level?
We have yet to come across a system that doesn't need to have these basic questions answered (especially the first four questions), or one that couldn't use the techniques described in this book to help answer them using an iterative, incremental, opportunistic (when you see the answer, capture it) approach. Although the full approach presents the steps in a specific order, it's not crucial that you follow the steps in that order. Many a project has died a horrible death because of a heavy, restrictive, overly prescriptive "cement collar" process, and we are by no means proponents of this approach. What we are saying is that missing answers to any of these questions will add a significant amount of risk to a development effort.