The ICONIX process: From use case to code with four diagrams
The ICONIX process is a lightweight, agile approach to model-based software development. Many people who come into contact with modeling for the first time are overwhelmed and often intimidated by the power of the chosen modeling language, often UML or SysML. Quite understandable, because these languages have a considerable scope and there seems to be a language feature for every exotic problem that can solve it. But in most cases, you can get by with a tiny subset of the language. And this is where ICONIX comes in: the ICONIX process uses only a small number of model elements to get from the use case to the source code.
ICONIX is used for software development, which is briefly described below. For readers of this block, the adaptation of ICONIX for embedded systems also interesting, which I will perhaps write about at another time.
ICONIX was developed for software development, but there are now also adaptations for other areas, especially for embedded systems.
The image above provides an overview of ICONIX. This can be found in many places in the ICONIX documentation and is therefore the guide through the process.
Scope: What's in it - and what's not
The ICONIX process is divided into a static and a dynamic part, which is shown with the dashed lines. Everything outside these lines is not in scope. This means that you should have already given some basic thought to the system.
Outside the dashed line are the storyboard (left), code and tests (right). Although these are discussed by the process, they are not modeled.
The process is lived from left to right, from coarse (use cases, domain model) to fine (sequence diagram, class diagram). As can already be seen, four different diagrams from the UML world are used (class diagrams are used for all three static diagrams).
Agile and iterative
The ICONIX process is designed so that it can be run through often and quickly, thus supporting agile working. So you would start with a handful of use cases, go through the entire process with them, and then repeat the whole thing with the next handful of use cases. In the course of an iteration, there are a few milestones that are linked to a review.
Requirements
Depending on the project, there are different sources and forms of requirements. The GUI storyboard shown in the picture is one possible tool used for this, but there are of course many others. It is important that the requirements are recorded in the form of use cases. These need a vocabulary, and this is documented in the form of a domain model. The first review is then the requirements review.
Analysis and preliminary design
The robustness diagram is not particularly well known. It provides a view of the interaction of object instances and refines the use cases. When the diagram is created, the use case is usually also revised. The domain model is also improved and extended at this point, for example with attributes.
Furthermore, logical system functions that are necessary for the realization of the use case are identified in this phase. These are referred to as "controllers" in ICONIX.
This phase also ends with a review of the preliminary design (Preliminary Design Review, PDR).
Detailed design
Sequence diagrams are used to document the detailed behavior of the classes. This means that the behavior is not only documented logically, but also assigned to specific classes. This takes the form of operations or functions that are added to the domain model. With attributes and operations, our domain model has suddenly become a class model.
However, before this phase is also concluded with a review, the class model should be revised and cleaned up once again. This is particularly necessary because - in contrast to the dynamic model - we have worked in the same diagram throughout the entire iteration. The review is also called a Critical Design Review (CDR).
Implementation and testing
The process ends at this point, although the following activities will of course be discussed. This includes implementation and unit testing, which hopefully goes hand in hand. In addition, testing must also take place at the higher levels, i.e. integration testing and scenario testing.
Code reviews are also recommended. It is highly likely that problems will arise during implementation that have an impact on the model. These changes should of course also be incorporated into the model.
And the next round
This completes the iteration and the next round can begin with the next use cases.
Tool support, book and training
This brings me to the end of this brief introduction to ICONIX. For interested readers, there is the possibility to deepen ICONIX with appropriate literature. The first place to go is the official ICONIX website. The creators of ICONIX have also several books worth reading written. And, of course, they offer appropriate training courses.
It is also worth mentioning that there are plug-ins for ICONIX for the popular modeling tools Enterprise Architect and MagicDraw. However, I have not yet tried these myself and therefore do not know how effective they are. In any case, ICONIX should also be usable with a generic UML tool. I would be happy about Comments from readers who can say something about this.
