chap8 面向对象设计-用例分析E.ppt

* * The Use-Case Model Supplementary Specification and Glossary are described in detail in the Requirements Overview module. The Use-Case Modeling Guidelines define the modeling conventions used in the Use-Case Model. Designers need this information to correctly read and interpret the use-case model. The classes represent an early conceptual model for ‘things in the system which have responsibilities and behavior.’ classes are used to capture a “first-draft”, rough-cut of the object model of the system. The Analysis Model describes the realization of use cases, and serves as an abstraction of the Design Model. It contains the classes and their relationships. If your project is maintaining separate Analysis and Design models, then an Analysis Model is a formal artifact from Use-Case Analysis. Otherwise, the identified classes and their relationships are just placed in the Design Model. These classes will be refined into design elements (for example, classes, packages, and subsystems) during the design activities. In many cases, the Analysis Model only exists for the brief duration of Use-Case Analysis. Once the classes are transformed into design classes/subsystems, the model generally vanishes. * One technique for capturing this additional detail if Word is used to document the use cases is to add the detail in the form of comments in the Word document. That way the detail can be “turned on or off,” depending on the audience. * Some of the work done in Analysis is thrown away. This is not bad, since you need to play with the ideas to see what works and what doesn’t, but you should expect that much of the work done during analysis is a kind of “structured doodling.” The biggest mistakes happened when people assign too much value to the early results of analysis. The need to define classes in UML terms creates a sense that they are more formal than they are. An instructor once referred to classes as “CRC-like cards, on which you can scribble anything you w