Review of an old book about ICONIX

I read the book, got inspired and want to tell about it. The book is old, originally written in 2002, but at the same time quite capacious. And, most importantly, the book describes the system design process well: from the interface prototype to setting development tasks. The book also shows in detail the mutual influence of UML diagrams on each other.
Here is a lyrical digression in the form of a chant to the motive of B.B. Grebenshchikov:

UML is dead and I’m not yet…

So, it’s time to reveal the first secret. What is this book?

The title of the book is: Applying Object Modeling Using the UML and Analyzing Use Cases in an Online Bookstore.  Written by Doug Rosenberg and Kendall Scott.
The title of the book is: Applying Object Modeling Using the UML and Analyzing Use Cases in an Online Bookstore. Written by Doug Rosenberg and Kendall Scott.

The design process described in the book, in my opinion, is aimed primarily at ensuring the completeness of the requirements.

The authors talk about the system models and the connections between them. A set of models is known to reduce the risk of missing requirements and the risk of implementing functionality that does not meet requirements.

After all, what are models? It is a simplified representation of some particular aspect of the system that is useful. And here the rule applies – if we missed some points on one model, then there is a high probability that we can notice them on another model. Each model is a kind of point of view on the future system.

How can you not remember the old aphorism:

All models are wrong, but some are useful

And it’s time to reveal the second secret. What is the name of the process described in the book?

The book describes the process by methodology ICONIX. The methodology is based on the UML language. At the same time, she (quote):

lighter than RUP, generates more documentation than XP and helps you get rid of “analysis paralysis” without sacrificing analysis and design

Almost the main advantage of the book is the illustrative examples based on the case study. The creation of an online bookstore was chosen as a training case. The example, of course, is refined, but, nevertheless, it illustrates the theory well. For an even better understanding of the topics in the books, exercises for finding errors in training diagrams are provided along with the correct diagrams.

Memory throws up another flashback in the form of a quote:

The difference between theory and practice is that theoretically there shouldn’t be such a difference, but in practice it does exist.

Move on. The book, like ICONIX itself, is based on 4 key UML diagrams:

  1. Use case model

  2. sequence diagram

  3. Suitability Chart

  4. class diagram

Diagrams are divided into two groups:

  1. dynamic model

  2. static model.

Screenshot from the book. ICONIX Process Diagram

Taken together, these diagrams illustrate the principles on which
the whole process is based (from inside to outside, from outside to inside and from top to bottom – everything
simultaneously):

  1. We move inside, starting from the requirements of the user

  2. We move outward, starting from the main abstractions of the subject area.

  3. We go down from high-level models to a detailed design.

Let’s take a closer look at each chart type.

Class Diagram and Use Case Diagram

The development of the system begins with the identification of objects in the subject area, the relationship between them and the first version of the class diagram. Also at this stage, the authors recommend creating rough prototypes of the interface, if possible.

After that, they move on to identifying precedents and creating a diagram of precedents grouped by similarity. If interface prototypes are created, then the first objects and precedents can be extracted from them.

Use cases are the starting point for detailed design:

go through all the stages from a partial understanding of each use case through sequence diagrams to the detailed design elements associated with them.

And also use cases help to check models for compliance with the requirements before moving on to coding:

ensure that the implementation (how) provided in the detailed design conforms to the specification (what)

Suitability Chart

Separately, I want to highlight the suitability diagram. It is created after the first version of the class diagram and use case model. For myself, I determined that the suitability diagram can be viewed as a projection from a two-dimensional space of precedents with measurements сущности and времяto a space with one dimension: сущности.

The suitability diagram links the dynamic and static models that were mentioned earlier.

To build a fitness chart, you need to answer two questions:

  1. What kind objects needed for each use case?

  2. What kind functions will execute objects?

Essentially, a suitability diagram is a class diagram that displays three kinds of icons:

  1. Boundary object – objects used by actors (note: this is a quote from the book, I myself prefer the word “actor”) to interact with the system

  2. Entity object – usually, this is an object from the domain model

  3. Control object – controllers that act as a “glue” between entity and boundary objects

A suitability diagram helps you find missing objects, attributes, and interactions by checking simple rules.

The book introduces four basic rules:

  1. Actors can only communicate with boundary objects.

  2. Boundary objects can only communicate with controllers and actors.

  3. Entity objects can only communicate with controllers.

  4. Controllers can communicate with boundary objects, entity objects, and other controllers, but not with actors.

The authors propose to conduct a suitability analysis for each case, including its main and all alternative flows.

Here is another full-fledged example of a chart from a book for a bookstore:

So, the suitability diagram allows you to:

  • Identify the objects that are needed for each use case. Thereby, refine both the domain model, and lay the foundation for the design of sequence diagrams

  • Refine use cases by finding inconsistencies and gaps in descriptions

Quote from the book:

A suitability diagram is similar to a UML collaboration diagram: it depicts the objects involved in a scenario and how they interact. Suitability analysis is not part of the UML core, but requires some stereotypes. It was part of the Objectory method created by Jacobson. This informal technique is very useful for refining use cases and identifying objects that are necessary for them, but for some reason were not included in the domain model. When creating the UML language, the “three amigos” knew about the existence of this technique, but did not include it in the main part of the standard. Instead, they developed specialized extensions to the Objectory process using a stereotyping mechanism that allows custom icons to be associated with any symbol. In suitability analysis, class pictograms act as such stereotypes.

sequence diagram

Further the domain model is supplemented. And build sequence diagrams. Interactions are nothing more than methods on objects. For each interaction, there must be a corresponding method in the objects that implements it. Thus, we will fill our objects with methods.

And further. Note that the text of the use case is written next to the sequence diagram. It is very convenient that both the text and the diagram illustrating it are in one place.

Conclusion

The diagramming process ensures consistency between them and sufficient elaboration for a relatively easy transition to coding. In the end, I will note what I liked and what I did not like about the book.

What we liked:

  • The path from interface prototypes to setting a task for development is clearly shown

  • Specific exercises are given in which typical errors are analyzed.

  • The book is heavy. In total with exercises and applications – 160 pages. About a hundred content.

What did not like:

  • The description of precedents, although it has a formalized character, is still rather “raw” and impractical. I would prefer descriptions that are closer to Alistair Cockburn

  • Sequence diagrams are not always drawn correctly. For example, the answer is often not shown

  • A separate system in vacuum was considered. In reality, there are quite a lot of integrations. Although, to be honest, it is not so difficult to approximate.

In terms of content and meaning, it was very reminiscent of the book by Eduard Galiaskanov “Analysis and design of systems using UML. Textbook for universities”.

I hope the article has opened something new for the readers or stimulated interest in reading the book on their own.

Similar Posts

Leave a Reply Cancel reply