活动:
|
目的
|
角色: 系统分析人员 |
频率:按照要求,一般每个迭代至少一次,特别是在“先启”和“精化”(可能还有“构造”)中。 |
步骤 |
输入工件: | 结果工件: |
工具向导: |
工作流程明细: |
构造用例模型的第一步是了解多个用例都有的需求。复审每个用例,记录任何通用的情况。
在以后的步骤(创建包含的、扩展的和泛化的用例)使用这些记录,将冗余度降到最低。目标是让需求更容易理解、更容易维护,而不定义带入设计中的功能分解。
创建新的用例并非总是处理通用需求的最佳办法。请考虑将通用的内容移入其它需求工件(如术语表和补充规范),并按需要从用例中引用。
如果内容与具体的用例相关,还要考虑将内容从补充规范移入用例中。
如果用例包含的行为段中只有结果(不是获得结果的方法)对其余用例有意义,该行为就可以归到新的包含用例中。 然后原始用例就成为与包含用例之间存在包含关系的基本用例。另请参阅指南:用例模型和指南:包含关系。
两个用例间的包含关系意味着遵照基本用例的说明的用例实例还需要遵照包含用例的说明才能完整。
包含关系可以通过以下方法帮助澄清用例:
一般情况下,多个用例必须包含一个包含用例,才值得维护一个额外的用例和包含关系。
只有基本用例知道两个用例间的关系;包含用例不知道其它哪些用例将它包含了。
描述包含关系:简单陈述包含的目的以及基本用例中要插入包含的位置。
在描述基本用例的事件流程时,您应该参考插入了包含的位置上的包含。
如果用例的一些行为段在特征上是可选的或是例外的,并且不会增强对用例的主要目的的理解,请将这样的用例归到新的扩展用例中。然后原始用例就成为基本用例,扩展用例与它是扩展关系。另请参阅指南:用例模型和指南:扩展关系。
在基本用例中,您声明扩展点,扩展点定义基本用例中可以作出扩展的位置。另请参阅指南:用例。
首先考虑将复杂的子流程和可选的行为分到扩展用例。这种行为通常可能很复杂、很难描述:将其包含在用例的事件流程中会使“正常”的行为难以看见。 将其抽取出来应该能提高用例模型的可理解程度。
请确保基本用例的事件流程不引用扩展用例时自己仍然完整,仍然可以理解。
只有扩展用例知道两个用例之间的关系。基本用例只知道它有扩展点,而不知道使用这些扩展点的是哪些扩展用例。
简单描述您定义的每个扩展关系。定义发生扩展必须满足的条件。确保在基本用例中定义了应该插入扩展的扩展点。
如果两个或多个用例在结构和行为上有相似点,就可以归纳出这些通用行为来创建新的父用例。 然后原始用例就成为与父用例之间存在泛化关系的子用例。子用例继承为父用例描述的所有行为。另请参阅指南:用例模型和指南:用例泛化关系。
两个用例间的泛化关系意味着遵照子用例的说明的用例实例还需要遵照父用例的说明才能认为是完整的。
一般情况下,要值得维护父用例以及它与子用例的泛化关系,就需要至少有两个子用例继承同一个父用例。例外的情况是:您有两个用例,其中一个是另一个的特殊化,但是两个都需要可以单独实例化。
只有子用例知道两个用例间的关系;父用例不知道哪些子用例将它特殊化了。
要帮助其他人理解模型,就应该简单描述泛化关系。请说明您为什么创建了泛化关系。
在子用例的事件流程中,您需要说明子用例将如何通过插入新的行为段来修改继承的行为序列。
参与者会有通用的特征,您应该使用参与者泛化关系来构建模型。当您在用例模型中进行了最初的尝试后,这部分工作将得到最佳执行。
简单说明参与者泛化关系,并将它们包含在用例图中以便进一步澄清。
另请参阅指南:参与者泛化关系。
您应该与客户和用户不断讨论包含关系、扩展关系和泛化关系的并入,并确保他们对结果用例和参与者有清晰的了解,并确保他们同意其说明。
请在这个阶段检查用例模型来验证您的工作是否在正确的轨道上,但不要详细复审模型。您应该与客户和用户一起复审和讨论新并入的用例和关系,从而让他们对用例有清晰的了解并同意用例的说明。
如果需要,您可以作出决定将用例组织为多个用例包。关于何时考虑作此选择的更多信息,请参阅指南:用例包。
您还应该在对用例模型进行操作时考虑用例模型的检查点。请特别参阅活动:复审需求中的参与者、用例和用例模型的检查点。
Rational Unified Process
|