5-6 minutes<\/p>\n
The Robustness Analysis is a practice that originated with Ivar Jacobson\u2019s 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.<\/p>\n
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:<\/p>\n
Boundary object (or interface object) is what actors use in communicating with the system.<\/p>\n
Entity object is usually an object from the domain model.<\/p>\n
Control objects (also known as controllers in MVC), which serve as the \u201cglue\u201d between boundary objects and entity objects. Figure 1 shows the visual icons for these three types of objects.<\/p>\n
Suppose we have the following simple use case description in textual format:<\/p>\n
From the student detail page, the teacher clicks on the \u2018\u2018Add courses\u2019\u2019 button and the system displays the list of courses. The teacher selects the name of a course and presses the \u2018\u2018Register\u2019\u2019 button. The system registers the student for the course.<\/p>\n
Now you can create a simple robustness diagram according to the use case above:<\/p>\n
You can also use a text label to attach the use case description on the right-hand-side of the Robustness diagram.<\/p>\n
Keep in mind that both boundary objects and entity objects are nouns and that controllers are verbs. Nouns can\u2019t talk to other nouns, but verbs can talk to either nouns or verbs.<\/p>\n
This philosophy is again consistent with the Model-View-Controller pattern which is also related to the \u201cLaw of Demeter\u201d. 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.<\/p>\n
Each unit should have only limited knowledge about other units: only units \u201cclosely\u201d related to the current unit.<\/p>\n
Each unit should only talk to its friends; don\u2019t talk to strangers.<\/p>\n
Only talk to your immediate friends.<\/p>\n
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 \u201cinformation hiding\u201d. 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.<\/p>\n","protected":false},"excerpt":{"rendered":"