A Practical Tutorial on Robustness Analysis

A Practical Tutorial on Robustness Analysis

5-6 minutes

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.