|
|
Robustness analysis plays several essential roles within the ICONIX process. Note that you will refine both your use case text and your static model as a result of robustness analysis, as shown in Figure 5-4.
It provides a sanity check by helping you make sure that your use case text is correct and that you haven't specified system behavior that's unreasonable-or impossible-given the set of objects you have to work with. 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 make sure the use cases address all necessary alternate courses of action (which we discussed in Chapter 3). In our experience, the time spent drawing robustness diagrams toward this end, and also toward the end of producing text that adheres to some well-defined guidelines, is invariably made up threefold or fourfold in time saved in drawing sequence diagrams, which we'll talk about in Chapter 7.
It enables ongoing discovery of objects, which is important because you almost certainly missed some objects during domain modeling. You can also address object naming discrepancies and conflicts before they cause serious problems. And, robustness analysis helps ensure that we've identified most of the entity and boundary classes before starting sequence diagrams.
And, it serves the role of preliminary design, by closing the gap between analysis and detailed design, as we mentioned at the beginning of the chapter.
Let's take a closer look at the three stereotypes that we apply to objects during robustness analysis.
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. If you have a GUI prototype in place, you can see what many of your primary boundary objects will be. If you follow the guidelines we gave you in Chapter 3, you can also easily pick boundary objects out of your use case text.
Entity objects often map to the database tables and files that hold 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. Many of your entity objects will come from your domain model.
Control objects (controllers) embody much of the application logic. They serve as the connecting tissue between the users and the stored data. This is where you capture your frequently changing business rules and policies, with the idea that you can 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 most of the time, controllers serve as placeholders to make sure that you don't forget any functionality and system behavior 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 actor(s), the appropriate boundary and 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:
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, entity objects, and other controllers, but not to actors.
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 5-5 summarizes the robustness diagram rules.
A reviewer of a robustness diagram should be able to read a course of action in the use case text, trace his or her 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 also continuously refine your static model. The new objects you discover drawing the diagrams should become part of your class diagrams when you discover them. This is also the right time to add some key attributes to your more significant classes.
|
|