Preface | Domain modeling | Use case modeling | Robustness Analysis | Interaction Modeling | Addressing Requirements

robustness analysis

It involves analyzing the narrative text of each use case and identifying a first-guess set of objects that will participate in the use case.

The objects found are classified into stereotypes:

1. Boundary objects: which actors use in communicating with the system (often referred as interface objects).
2. Entity objects: which are usually objects from the domain model.
3. Control objects: which serve as the "glue" between boundary objects and entity objects.

This kind of analysis is the link between the analysis (what) and the design (how).

Key roles of robustness analysis

• Sanity check: it helps to make sure that the use case text used is correct and that it does not specify system behavior that is unreasonable (or impossible).
  • You should replace the generic nouns in your use case text with the proper names of the objects that appear in your robustness diagrams (this change transfer the context of the use cases from the user manual to the object model one).
  • Robustness analysis is not a separate step in modeling. It is an integral part of the use cases writing.
• Completeness check: it helps to be sure that the use cases match all the alternate course of action.
• Object identification: you may have missed some objects
  • This phase helps also to find discrepancies and conflicts between names => use the names from the domain model for your entity objects.
  • By the time you finish the robustness analysis you should have identified most part of the domain classes. This is very important because allocating behavior across an incomplete set of objects is likely to be messy.
• Preliminary design: robustness diagrams are less complex and easy to read than sequence diagrams.

Alert: don't try to do detailed design on robustness diagrams

Performing robustness analysis

Robustness diagram symbols

When performing robustness analysis there two principles to guide your choices:

1. Small number (between two and five) of controllers per average use case. If you have more than 10 controllers per use case you better consider to split it into more use cases.
2. Arrows between objects should follow the schema shown below. In this case (unlike on sequence diagrams) arrows do not represent software messages, they simply indicate logical associations. You will not code starting from these diagrams, so focus on the logical behavior.

The essence of the previous diagram can be captured by the following sentences:

1. Actors can talk only to boundary objects.
2. Boundary objects can talk only to controllers and actors.
3. Entity objects can also talk only to controllers.
4. Controllers can talk to both boundary objects and controllers, but not to actors.

Example: "Basic Course: The Assistant Trader (AT) uses a bond trade entry window
          to enter the primary values for the trade. The system validates both
          general trade values and bond-specific values (for instance, it makes sure
          the cupon rate is "reasonable") before processing the trade.

          Alternate Course: If the validation fails, notify the user, highlight the
          erroneous values, and get new values from the user."

After drawing the robustness diagram inspired from the example, we can modify the basic course of the use case as follow:

"The system creates a new trade with the ticket number

 attached to the order. It also brings up a Bond Trade Entry
 window. The AT uses this window to enter the appropriate
 values for the trade. When the AT chooses to submit the

 trade, the system validates both general trade values and
 bond-specific values (for instance, it makes sure the coupon
 rate is "reasonable") before processing the trade. If the trade

 passes all validation tests, the system submits it to the Trade
 Queue, from which the trade is later sent to the Back Office

 System to be cleared and processed further."

Updating your domain (static) model

The next necessary step, before moving to the interaction modeling, is to update your domain model.

In fact the best thing to do is to update continuously the static model while working through use cases and during the robustness analysis:

• as we put use cases in the context of use case diagrams, we refine them in their basic and alternate course of action and we discover new entity objects. We need to add them to the robustness diagram and most of all to our static diagrams;
• by introducing windows and screens in the form of boundary objects, we start tracing data associated with those objects. The natural result to this process is to add attributes to the classes in our domain model;
• this process allow us to "itemize" all the required behavior of the use case in form of control objects. This means to identify properly all the functions needed by our system.

Top 10 benefits of Robustness Analysis

1. It forces you to write your use cases using a consistent style.
2. It forces you to write your use cases in the correct voice.
3. It provides sanity and completeness checks for the use cases.
4. It allows you to apply syntax rules (i.e. "actors talk only to boundary objects") to your use cases.
5. Robustness diagrams are quicker to draw and easier to read than sequence diagrams.
6. It helps you partition objects within a Model-View-Controller paradigm.
7. It helps you layer objects in a GUI-Logic-Repository framework
8. It allows a reuse pass across all your use cases before begin design.
9. It provides traceability between what the system does (use cases) and how the system works (sequence diagrams).
10. It plugs the semantic gap between analysis and design.