A Practical Tutorial on Robustness Analysis

The Robustness Analysis is a practice that originated with Ivar Jacobson’s Objectory Method, but it was dropped from the Unified Modeling Language. This involves analyzing the narrative text of use cases, identifying the first-guess set of objects that will participate in those use cases, and classifying these objects based on the roles they play. Robustness analysis helps you to bridge the gap from Use Cases and Domain Classes, and the model-view-control (MVC) software architecture.

As I mentioned before, robustness analysis is not exactly a core part of UML; instead, it requires the use of some stereotypes. Here are the Robustness Analysis Diagram symbols:

• Boundary object (or interface object) is what actors use in communicating with the system.
• Entity object is usually an object from the domain model.
• Control objects (also known as controllers in MVC), which serve as the “glue” between boundary objects and entity objects. Figure 1 shows the visual icons for these three types of objects.

Robustness Analysis Diagram at a Glance

Suppose we have the following simple use case description in textual format:

From the student detail page, the teacher clicks on the ‘‘Add courses’’ button and the system displays the list of courses. The teacher selects the name of a course and presses the ‘‘Register’’ button. The system registers the student for the course.

Now you can create a simple robustness diagram according to the use case above:

You can also use a text label to attach the use case description on the right-hand-side of the Robustness diagram.

Robustness Diagram – 4 Connection Rules

Keep in mind that both boundary objects and entity objects are nouns and that controllers are verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs.

Here I listed the four basic connection rules which should always be mind:

• Actors can only talk to boundary objects.
• Boundary objects can only talk to controllers and actors.
• Entity objects can only talk to controllers.
• Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors

Law of Demeter

This philosophy is again consistent with the Model-View-Controller pattern which is also related to the “Law of Demeter”. The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling.

• Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
• Each unit should only talk to its friends; don’t talk to strangers.
• Only talk to your immediate friends.

The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of “information hiding”. It may be viewed as a corollary to the principle of least privilege, which dictates that a module possesses only the information and resources necessary for its legitimate purpose.

Five Steps for Creating Robustness Analysis

1. You perform robustness analysis for a use case by walking through the use case text.
2. One sentence at a time, and drawing the actors, the appropriate boundary, entity objects and controllers, and the connections among the various elements of the diagram.
3. You should be able to fit the basic course and all of the alternate courses on one diagram.
4. Anyone who reviews a robustness diagram should be able to read a course of action in the use case text, trace his finger along with the associations on the diagram, and see a clear match between text and picture.

You will probably have to rewrite your use case text as you do this, to remove ambiguity and to explicitly reference boundary objects and entity objects. Most people don’t write perfect use case text in the first draft. So we can use the robustness analysis to bridge the gap between the use case text and the diagram.

Develop Use Case Scenario Using MVC Sequence Diagrams

Base on the Robustness Analysis, we can develop use case scenarios (normal or alternatives) by using a set of related sequence diagrams in MVC format. Similarly, the MVC Sequence diagram has interface objects, controller objects and entity objects:

• Entities are objects representing system data: Customer, Product, Transaction, Cart, etc.
• Boundaries are objects that interface with system actors: UserInterface, DataBaseGateway, ServerProxy, etc.
• Controls are objects that mediate between boundaries and entities.

They orchestrate the execution of commands coming from the boundary by interacting with entities through the boundary objects. A controller object often corresponds to the use case scenario and often represented by a sequence diagram.

You can use stereotypes for the lifeline in the MVC sequence diagram to make visually clear what type of objects you are using in the MVC as the way like the Robustness Analysis Diagram above.