软件工程——用例建模

目录

用例在需求管理过程中的作用：??

用例模型的表示——文本描述??

用例模型的表示——用例图??

用例图的主要元素：

用例：

参与者：

关联：

场景是用例的实例?

 用例建模的步骤：

寻找参与者：?

识别参与者：是谁在和系统交互/p>

参与者的描述：?

参与者建模的检查项：?

寻找用例：用穷举的方式考虑每个参与者与系统的交互情况?

识别用例：?

用例的描述：?

用例的命名：

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

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

用例的全生命周期：?

用例文档模板：?

用例建模规范：

设定系统边界：

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

何时使用包含关系：

何时使用扩展关系：   

用例图中的主要图标：?

常用的建模工具：

系统建模工具的主要功能：

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

• 用例图的主要元素：

      用例 、参与者、关联

• 用例：

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

• 参与者：

1. 与系统交互的人
2. 与系统交互的硬件组件
3. 或者其他的外部系统
4. 关注的重点是所承担的角色
5. 参与者的名要明确定义其角色

• 关联：

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

•  用例建模的步骤：

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

• 用例的命名：

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

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

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

• 用例建模规范：

• 设定系统边界：

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

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

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

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

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

• 何时使用包含关系：

1.    当多个用例有共享行为时，使用包含关系

• 何时使用扩展关系：   

1.    一个用例与另外一个用例近似，只有少许额外的活动
2.    将代表普遍或基本行为的情况定义为一个用例
3.    将特殊的、例外的部分定义为扩展用例

• 常用的建模工具：

• 系统建模工具的主要功能：

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

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

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