健壮性分析图

转载

mob604756eae43b 2012-11-30 13:26:00

文章标签 sed ide 实体类 html desktop 文章分类 代码人生

A robustness diagram is basically a simplified UML communication/collaboration diagram which uses the graphical symbols depicted in Figure 1. As you can see robustness diagrams depict several types of concepts:

Actors. This is the same concept as actors on a UML use case diagram.
Boundary elements. These represent software elements such as screens, reports, HTML pages, or system interfaces that actors interact with. Also called interface elements.
Control elements. These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. Also known as process elements or simply as controllers. It is important to understand that you may decide to implement controllers within your design as something other than objects � many controllers are simple enough to be implemented as a method of an entity or boundary class for example.
Entity elements. These are entity types that are typically found in your conceptual model, such as Student and Seminar.
Use cases (optional). Because use cases can invoke other use cases you need to be able to depict this on your robustness diagrams.

Figure 1. Robustness diagram symbols.

健壮性分析图_sed

Figure 2 shows a whiteboard sketch of a robustness diagram representing the logic contained in the Enroll in University system use case. To create the sketch I merely followed the logic of the use case and applied the following heuristics:

Add a boundary element for each major user interface element such as a screen or a report. Although some very detailed use cases will describe how actors work with buttons and edit fields I prefer to stay at a higher level and not show these details. I did however choose to show the Create Student Icon on the diagram although in hindsight this boundary class would be better labeled Desktop. I chose not to update the diagram because I follow the AM practice Update Only When it Hurts and frankly it isn�t important enough to fix this minor issue. These classes are likely to appear on your interface-flow diagrams if you choose to create them.
Add a controller to manage the overall process of the scenario being modeled. In Figure 2 this is the Enroll in University element. As you can see it provides the glue which keeps the diagram together. In your design this element could very likely be implemented as a class, as one or more operations, or via some sort of workflow engine if that is part of your overall architecture.
Add a controller for each business rule. This helps to make the business rules explicit on your diagram. Some people will not model the business rules at all, keeping their diagrams simple, but as a result they miss very important information in their diagrams. Try both ways and then choose the approach that works best for you.
Add a controller for activities that involve several other elements. An example of this is the Create Student element which interacts with a business rule as well as the Student entity.
Add an entity for each business concept. The Student and Student Fee classes are examples of this. These elements are likely to appear on your conceptual model if you chose to create one.
Add a use case whenever one is included in the scenario. I chose to depict the invocation of the Enroll in Seminar use case using standard UML notation for use cases. Another option is to depict the use case as a controller although in my experience this isn�t as clear to project stakeholders. Remember the AM principle Content is More Important Than Representation and do whatever is best for your situation.

Figure 2. Example robustness diagram.

健壮性分析图_实体类_02

By drawing a robustness diagram we quickly gain a sense for the work that we need to do to implement this use case because it helps to visualize the potential elements we�ll have to build. The boundary elements will help to bridge your use cases to your user interface development and your legacy system analysis efforts. Some of those classes are entity elements, things that should definitely appear on a conceptual model. The controllers are much closer to design concepts, so robustness diagrams help to bridge to your design.

How do you keep robustness diagrams agile? My experience is that the following AM practices are very relevant:

Active stakeholder participation. Robustness diagrams can be a very good technique, in some situations, to perform analysis with your stakeholders. As you can see in Figure 2 robustness diagrams are very straightforward and easy to draw, making them an inclusive modeling technique.
Discard temporary models. Robustness diagrams are typically drawn on a whiteboard in order to analyze the logic of a use case. Once the use case has been improved the robustness diagram will be kept around long enough to act as a bridge to the next development step, see below, then erased.
Apply the right Artifacts. Some modelers, including myself, will stop creating robustness diagrams when their stakeholders get used to making the logical jump from use cases to other development artifacts such assequence diagrams. In other words robustness diagrams are used to help train stakeholders to think abstractly and then abandoned as a technique once this goal is reached. Other modelers will continue to use robustness diagrams because the models still add significant value to their overall efforts.

What is next after robustness diagrams? Robustness diagrams often act as bridge from use cases to other models. For example, it is quite common to create sequence diagrams which represent the detailed design logic required to support the use case. It is also common to focus on the user interface for your system, perhaps via prototyping or better yet just getting right into the �real� coding, because robustness diagrams explicitly include boundary/interface elements. Furthermore, because robustness diagrams depict major business entities it is quite common to use them as an input you�re your conceptual/domain modeling efforts.