This simple and useful technique links the what of business analysis to the how of design by ensuring your use case text is correct. It addresses necessary courses of action and allows you to continue to discover objects.
The Forgotten Diagram
Robustness Analysis, is a practice that originated with Ivar Jacobson but was dropped from the Rational implementation of UML. This involves analyzing the narrative text of use cases, identifying a first-guess set of objects that will participate in those use cases, and classifying these objects based on the roles they play.
Ø Boundary or Interface objects are what actors use in communicating with the system.
Ø Entity objects are usually objects from the domain model.
Ø Control objects (which we usually call controllers because they often aren't real objects), which serve as the "glue" between boundary objects and entity objects. Figure 1 shows the visual icons for these three types of objects.
Figure 1 shows the visual icons for these three types of objects.
Robustness analysis serves as preliminary design within the project lifecycle and provides the missing link between analysis and detailed design.
Figure 1. Visual Icons of Three Stereotypes
This simple but highly useful technique serves as a crucial link between analysis—the what—and design—the how, as shown in Figure 2.
Robustness analysis plays several essential roles within the 4D process. Robustness analysis asks the systems analyst to perform a sanity check on the client’s business case by providing a logical interpretation of the use case to ensure you haven't specified system behaviour that is unreasonable—or impossible—given the set of objects you have. This refinement of the use case text changes the nature of that text from a pure user manual perspective to a usage description in the context of the object model.
It also provides a completeness and correctness check by helping you determine if the use cases address all necessary alternate courses of action. The time spent drawing robustness diagrams toward this end is invariably made up three- or four-fold in time saved in future design and development.
Figure 2. Purpose of Robustness Analysis
Robustness analysis enables the ongoing discovery of objects and helps you ensure that you've identified most of the major domain classes before starting any additional design or development.
Boundary objects are the objects with which the actors (for instance, the users) will be interacting in the new system. These frequently include windows, screens, dialogs and menus. You should be able to easily pick boundary objects out of your use case text.
Entity objects often map to the database tables and files that contain the information that needs to "outlive" use case execution. Some of your entity objects are "transient" objects, such as search results, that "die" when the use case ends.
Control objects (controllers) embody much of the application logic and serve as the connecting tissue between the users and the stored data. This is where you capture frequently changing business rules and policies, and localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are "real objects" in a design, but controllers usually serve as placeholders to assure that you don't forget any functionality and system behaviour required by your use cases.
You perform robustness analysis for a use case by walking through the use case text, 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. You should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:
Robustness Analysis 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. Figure 3 summarizes the robustness diagram rules.
Anyone who reviews a robustness diagram should be able to read a course of action in the use case text, trace his finger along 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.
In addition to using the results of robustness analysis to tighten up the use case text, you should be formulating your class model. The objects you discover drawing the diagrams should become part of your class diagrams when you discover them, and this is also the right time to identify some key attributes to your more significant classes.
Key Issues in Robustness Analysis
Don't violate the robustness diagram rules. These rules are in place primarily to get your text into noun-verb-noun format and to help ensure that you don't start allocating behaviour to objects before you have enough information to make good design decisions. The rules about boundary objects are in place to ensure that you explicitly specify the boundaries of the system, outside of which reside the actors involved in your use cases.
Use robustness analysis to help you use a consistent format for your use case text. The boundary object-controller-entity object pattern tends to closely correlates with the subject-verb-object pattern of basic English sentences and the Model-View-Controller paradigm of the J2EE architecture. You should use robustness analysis to make the text of your use cases stylistically consistent across those boundaries.
Include alternate courses on robustness diagrams. You need to perform robustness analysis on all of your use case text, not just the basic courses. Much of the interesting behaviour of a system occurs in the context of alternate courses, so it's important to analyze that behaviour as part of your modeling efforts. Robustness analysis can also help you discover new alternate courses, especially when you draw controllers with labels such as Verify and Validate.
Don't include too few or too many controllers. There should generally be three to seven controllers on a robustness diagram. If you only have one controller per use case, you're likely to have a lot of very small use cases, each of which don't really describe enough behaviour. On the other hand, if you have more than 10 controllers on one diagram, you should consider splitting your use case up into more manageable chunks.
Don't take too much time trying to perfect robustness diagrams. The robustness diagram serves as a "booster-stage engine" that gets the process of driving use cases forward into an object-oriented design off the ground. Robustness analysis helps us discover objects, allocate attributes, and check the use case text for completeness and correctness. But once we've accomplished the overall mission, we don't need to maintain the work product. It's a means to an end, not an end in itself.
Don't try to do detailed design on robustness diagrams. The concept of throwaway diagrams is useful in connection with preliminary design; it's not a useful concept when it comes to detailed design. Sequence and class diagrams are the appropriate place for detailed design. Robustness analysis should be a quick pass across all of the scenarios you're going to build, in order to provide maximum value to your project. If your preliminary design takes as long as detailed design, you'll lose the benefits of this quick sanity check.
A well-prepared robustness diagram is a very useful tool for explaining the intended operation of the system to clients and other developers. Whenever possible it is beneficial to keep the three object types in columns so that the users can easily follow the path of the scenario. The robustness diagram below is an example of a clean, easy to read diagram.
The client can easily see that all the boundary objects are presented to the user (as web pages in this example) and are located on the left hand side. All the business logic resides in the middle section with control objects that have descriptive names. The Entity objects represent data stored in various systems and their placement down the right hand side of the diagram reinforce their background status relative to the user.