用例建模

目录

  1. 需求建模
  2. 用例
  3. 参与者
  4. 确定用例
  5. 用例图
  6. 用例描述
  7. 用例关系

1 需求建模

1.1 需求和需求建模

  • 描述了用户对系统的期望，主要涉及系统的外部特性
  • 类型： 包括功能需求和非功能需求
  • 目的： 代替手工系统或者替代旧系统
  • 建模： 包含需求分析和需求规约

1.2 相关问题

  • 需求分析需要考虑的问题：涉众扮演的角色、系统使用、特性、优势和局限性。
  • 需求规约：与用户达成共识的文档。也就是需求分析说明书。需求规约的质量属性：正确、完整、无二义性；一致、可验证、易理解特性；可修改、可追踪。
  • 非公能需求：性能、可用性、安全。

2 用例

2.1 用例作用

用例建模是用来描述系统功能的一种方法。用例定义了一个或多个参与者与系统交互的序列。用例不关心具体实现，总是从参与者的输入开始。

2.2 用例表示

  • 用例名称
  • 概述
  • 依赖：是否依赖、包含、扩展了其他用例。
  • 参与者
  • 前置条件：用例启动的条件
  • 主序列：主场景
  • 备选序列：在某些决策点上进入的场景
  • 非公能需求：性能和安全性的需求
  • 后置条件：用例执行完后总是为真的结果
  • 未解决的问题：需要讨论的问题

3 参与者

3.1 参与者作用

描述了一个与系统交互的外部用户。是一类外部用户，单个用户是参与者的实例。

3.2 参与者分类

  • 人类参与者
  • 外部系统参与者
  • 设备参与者
  • 计时器参与者

4 确定用例

5 用例关系

5.1 包含关系

  • 包含用例和基用例
  • 多个包含用例构成了一个交互序列，包含用例是抽象的，不能独立执行。
  • 包含用例反映了多个用例之间的共同功能。
  • 基用例包含并执行包含用例。
  • 包含用例用来组织冗长交互序列的用例（将大量交互序列进行分成多个用例中的交互序列）。是一种层层细分的建模思路。基用例提供了用户与系统之间高层抽象交互序列，包含用例提供了用户与系统底层细分的交互序列。

5.2 扩展关系

  • 将可替换的、备选的、异常的分支作为新的用例。基用例，扩展用例。
  • 根据条件确定基用例以不同的方式扩展。扩展用例依赖于基用例，需要基用例在满足一定条件时执行。
  • 扩展点，用来扩展基用例的位置。可以根据条件分成多个扩展用例。扩展条件，是在基用例运行时确定的。

6 用例组织

  • 用例包：描述系统主要功能的集合，表示更高层的集合。
  • 可以基于用例的主要参与者，组织成用例包
  • 可以根据具有相同非公能需求的用例，组织成用例包。

7 活动图

描述控制流和活动序列的UML图。（就像平时说的流程图）显示了活动序列、决策点、循环、并发活动。用例模型可以使用活动图来描述主序列和备选序列。

这里很明显说明了建模过程中的需求建模包含了建模方法：用例建模（表示功能需求）和静态建模（表示数据需求）其中用例建模可以使用UML图形工具中的用例图（表示用例关系）和活动图（表示用例执行序列）来实现。
对建模过程、建模方法、建模工具进行了很好的区分。

对软件生存周期中的建模过程和这里的建模方法的关系进行说明：一个是描述具体实践是建模的过程，另个一描述的是建模的方法。需求建模、分析建模、设计建模分别是生存周期当中，三个不同的建模阶段，每个建模阶段可能采取的方法也不止，比如需求建模可能包括：用例建模方法表示功能，静态建模方法表示数据。

对软件的建模方法和UML图的关系进行说明。UML图是一种图形工具，用来更好的表示方法，而不是方法不慎。所以UML画的图可以更好的描述建模的过程。用例建模用到了用例图，静态建模用到了类图、对象图、包图、构件图等。所以要区分过程、方法和工具。

我觉得现在的知识体系有点乱，首先应该把所有的基础内容都了解一下，至少看一遍。然后，花费大量时间，对学到的知识进行总结，构件知识体系。此时应该可以使用头脑风暴的图，来整理相关领域的知识。