工件:
|
![]() |
用例包是用例、参与者、关系、图和其它包的集合;用于通过将用例模型划分成更小的部分来构造用例模型。 |
---|---|
其它关系: |
部分的 用例模型
|
角色: | 需求指定者 |
可选/发生: | 可以不包括 <<用例包>>。 |
模板和报告: |
|
示例: | |
UML 表示: | 用例模型中的包,可以是顶级包或构造为 <<用例包>> |
更多信息: |
活动的输入: | 活动的输出: |
以下人员使用用例包:
属性名 |
简述 |
UML 表示 |
---|---|---|
名称 | 包的名称。 | 模型元素上的属性“名称”。 |
简述 | 包的角色和用途的简短描述。 | “短文本”类型的标注值。 |
用例 | 直接包含在包中的用例。 | 通过聚集“所有”拥有。 |
参与者 | 直接包含在包中的参与者。 | - " - |
关系 | 直接包含在包中的关系。 | - " - |
图 | 直接包含在包中的图。 | - " - |
用例包 | 直接包含在包中的包。 | - " - |
一旦用例模型过大而无法维持为一个平面结构,即分割用例包。这可能是在先启阶段的早期或是后来的精化或构造阶段。
需求指定者负责包的完整性,确保:
建议需求指定者在负责用例包的同时负责该包所包含的用例。有关更多信息,请参阅指南:用例。
+ 提供具有单独功能单元的分层模型结构。如果用例模型和系统比较大,则该结构比平面模型结构(没有包)更容易理解。
+ 使用户有很好的机会按照几个开发人员的能力范围向他们分配工作和职责。这在构建大型系统时尤其重要。如果需要确保开发人员之间的机密性,用例包还可提供安全基础,这样只有少数人知道系统的完整功能。
+ 由于用例包应为高度聚集的单元,因此对某个包的变更将不会影响其它的包。
- 维护用例包意味着用例建模组有了更多的工作。
- 使用用例包意味着开发人员还要领会其它的符号概念。
如果使用此项技术,则必须确定要使用的包的级别数。根据经验,每个用例包应包含大约 3 至 10 个更小的单元(用例、参与者或其它的包)。下表就在给定用例和参与者数量的情况下应使用的包的数量提供了一些建议。如果数量存在重叠,则是因为不可能给出精确的指导信息。
Rational Unified Process
|