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:
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.
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:
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.
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.
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.
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:
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.