软件工程——用例建模

用例在需求管理过程中的作用： 用例模型的表示——文本描述 用例模型的表示——用例图 用例图的主要元素：

用例 、参与者、关联

用例：

1. 定义一个参与者要用到的系统功能
2. 描述系统为实现参与者价值所开展的行为序列
3. 对参与者与系统之间的交互活动进行建模
4. 从特定的用户角度出发，是完整的、实现特定用户价值的事件流

参与者：

1. 与系统交互的人
2. 与系统交互的硬件组件
3. 或者其他的外部系统
4. 参与者的名要明确定义其角色

关联：

1. 参与者与用例之间的交互通道
2. 用一条直线表示交互：有箭头的关联指出是谁发起的交互、没有箭头则表明双方都可以发起交互
3. 每一个交互代表一个完整的对话

场景是用例的实例 用例建模的步骤：

1. 找到所有参与者和用例（识别出参与者、用例，并做简单的描述）
2. 编写用例（划分用例事件流程的等级，按照重要程度的排序详细描述事件流程）

寻找参与者： 识别参与者：是谁在和系统交互？ 参与者的描述： 参与者建模的检查项： 寻找用例：用穷举的方式考虑每个参与者与系统的交互情况 识别用例： 用例的描述： 用例的命名：

将主参与者的名称与应用的名称连成句子，看是否有实际的意义来判断命名是否合适

用例模式过程中的检查项：

用例建模的过程：用例图--用例提纲--用例详细规约

用例的全生命周期： 用例文档模板： 用例建模规范： 设定系统边界：

系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线

系统边界会对用例以及参与者的定义有所影响

不要把用例定义为功能分解:

功能分解：将问题分解为粒度小，独立的部分。不同的模块协同工作，体现系统的功能。通常， 一些功能分解并没有实际的意义。

用例：不是功能分解的过程！综合所有功能一起描述系统如何使用，需要包含语境信息。

何时使用包含关系：

1. 当多个用例有共享行为时，使用包含关系
2. 为共享行为单独创建用例，被相关用例“包含”

何时使用扩展关系：

1. 一个用例与另外一个用例近似，只有少许额外的活动
2. 将代表普遍或基本行为的情况定义为一个用例
3. 将特殊的、例外的部分定义为扩展用例
4. 在定义扩展用例关系时，需要说明扩展条件以及扩展点

用例图中的主要图标： 常用的建模工具： 系统建模工具的主要功能：

1. 可视化模型表达;UML、Web、数据库、用户自定义模型
2. 画图工具
3. 辅助开发流程中的项目管理

常用系统建模工具（UML2.0）：

1. IBM Rational Rose
2. JUDE
3. Enterprise Architect(EA)