基于场景需求建模

• 8.1 需求分析
• • 8.1.1 需求分析目标和原理
  • 8.1.2 分析的经验原则
  • 8.1.3 域分析
  • 8.1.4 需求建模的方法
• 8.2 基于场景建模
• • 8.2.1 创建初始用例
  • 8.2.2 细化初始用例
  • 8.2.3 编写正式用例
• 8.3 用例图
• • 8.4 活动图

8.1 需求分析

• 需求分析目的是产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。
• 需求分析是细化基础要求，这些基础需求在前期需求工程的起始、导出、协商任务中建立的。
• 需求建模是使用文字、图表等综合形式，以相对容易理解的方式描述需求，特别是为了能够直接评审其正确性、完整性和一致性。

需求建模的结果为以下一种或多种模型类型：

• 场景建模：出自各系统“参与者”观点的需求。
• 数据模型：描述问题信息域的模型。
• 面向类的模型：表示面向对象类的模型，其方式为通过类的协作获得系统需求。
• 面向流程的模型：表示系统的功能元素并且描述当前功能元素在系统中运行时怎样进行数据变换的模型。
• 行为模型：描述如何将软件行为看做是外部“事件”后续的模型。

8.1.1 需求分析目标和原理

• 在整个需求分析建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面。
• 具体包括
  • 在特定环境下发生哪些用户交互？
  • 系统处理什么对象？
  • 系统必须执行什么功能？
  • 系统显示什么行为？
  • 定义什么接口？
  • 有什么约束？

总体目标和原理

• 需求分析建立的模型必须实现三个主要目标：
  • 描述客户需要什么；
  • 为软件设计奠定基础；
  • 定义在软件完成后可以被确认的一组需求。
• 需求模型是系统描述和设计之间的桥梁。
• 需求模型的所有元素都可以直接跟踪到设计模型。

三者的关系

• 需求模型（也称分析模型）
• 通常难以清楚地区分需求建模和设计建模活动之间的设计和分析工作
• 需求分析中有系统设计，系统设计中也有部分分析。

8.1.2 分析的经验原则

• 需求分析模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些，”不要陷入细节“。
• 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。
• 关于基础结构和其他非功能的模型应推延到设计阶段再考虑。
• 最小化整个系统内的关联。
• 确认分析模型为所有利益相关者都带来价值。
• 尽可能保持模型简洁。

8.1.3 域分析

• 软件域分析是识别、分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的。
• 面向对象的域分析是在某个特定应用领域内，根据通用的对象、类、部件和框架、识别、分析和详细说明公共的、可复用的能力。
• 域分析的目标是：查找或创建那些广泛应用的分析类或分析模式，使其能够复用。

域分析的输入和输出

说明：
域分析是为了领域内复用，形成过程资产价值。

8.1.4 需求建模的方法

• 需求建模的两种方法：
  • 结构化分析方法和面向对象分析方法。
• 结构化分析方法：基本观点认为系统是数据和对数据的加工，建模是为了明确数据在系统中如何流动处理加工和转换。
• 面向对象的分析方法：关注于定义类和影响客户需求的类之间的协作方式。
• UML和统一过程主要是面向对象的。
• 软件团队往往 - 结构化分析方法和面向对象分析方法。中的所有表示手段。问题不是哪一种方法最好，而是怎么组合这些表示手段才能够提供最好的软件需求模型和过渡到软件设计的最有效方法。
• 需求模型的元素可以按照不同观点进行分类。
  • 基于场景的模型：用户如何和系统交互
  • 类模型：系统有哪些类和对象及它们如何协作
  • 行为模型：如何改变系统或系统内状态
  • 流模型：数据在流过各个功能时如何转换。

需求模型的元素

8.2 基于场景建模

• 如果软件工程师了解最终用户（或参与者）希望如何与系统交互（场景），软件团队将能够更好地、更准确地刻画系统，更有针对性的完成分析和设计模型。
• UML时分析建模很好的工具，建模时可以从开发用例、活动图和泳道图等形式的场景开始。
• 基于场景建模步骤：
  • 创建初始用例
  • 细化用例
  • 编写正式用例
  • 过程中，使用UML图作为建模的有力工具

8.2.1 创建初始用例

• 用例是从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。
• 用例要有价值就必须知道：
  • 1）编写什么？
  • 2）写多少？
  • 3）编写说明应该有多详细？
  • 4）如何组织说明？
• 开始开发用例时，要列出特定参与者执行的功能或活动。
• 功能或活动的获得方式：
  • 可以从所需系统功能列表中获得，
  • 通过与客户或最终用户交流获得，
  • 通过评估活动图获得。

举例：开发一个初始用户场景

• SafeHome的第二次需求收集会议
• 通过需求收集会议得到，SafeHome住宅监视功能（子系统）由参与者房主执行的功能：
  • 选择将要查看的摄像机。
  • 提供所有摄像机的缩略视图。
  • 在计算机的窗口中显示摄像机视图。
  • 控制某个特定摄像机的镜头转动和缩放。
  • 可选择地记录摄像机的输出。
  • 回放摄像机的输出。
  • 通过Internet访问摄像机监视功能
• 随着和利益相关者更多地交谈，需求收集团队为每一个标记的功能开发用例。
• 通常，用例首先用非正式的描述性风格编写。
• 如果需要更正式一些，可以使用结构化的形式重新编写同样的用例。

用例 - 描述性书写（非正式的）

用例：访问摄像头监视设备 ---- 显示摄像头视图（ACS - DCV）
参与者：房主
描述：
  如果我位于远方，我可以使用任何计算机上的合适的浏览器软件登陆SafeHome产品网站。输入我的用户ID和两级密码，一旦被确认，我可以访问已安装的SafeHome系统的所有功能。为取得某个摄像头视图，从显示的主功能按钮中选择”监视“，然后选择”选取摄像头“，将会显示房屋的平面设计图，再选择感兴趣的摄像头，另一种可选方法是，通过选择”所有摄像头“，可以同时从所有的摄像头查看缩略视图快照。当选择了某个摄像头时，可以选择”查看“，然后以每秒一帧速度显示的图像就可以在窗口中显示。如果希望切换摄像头，选择”选取摄像头“，原来窗口显示的信息消失，并且再次显示房间的平面设计图，然后就可以选择感兴趣的摄像头，以便显示新的查看窗口。

用例 - 用活动序列表现交互（正式点）

用例：访问摄像头监视设备 ---- 显示摄像头视图（ACS - DCV）
参与者：房主
描述：
  1.房主登录SafeHome产品网站。
  2.房主输入用户ID。
  3.房主输入两个密码（每个至少八个字符长度）。
  4.系统显示所有的主要功能按钮。
  5.房主从主要功能按钮中选择”监视“。
  6.房主选择”选取摄像头“。
  7.系统显示房屋的平面设计图。
  8.房主从平面设计图中选择某个摄像头图标。
  9.房主选择”查看“按钮。

说明：

• 上面用例的连接的陈述没有考虑其他可能的交互。这种类型的用例有时被称作主场景。
• 因此，初始用例需要进一步细化。

8.2.2 细化初始用例

• 要完整地理解所描述的功能，必须说明所有可能的交互。
• 主场景中的每个步骤要通过如下提问进行评估：
  • 在这一步，参与者能进行一些其他活动吗？
  • 在这一步，参与者有没有可能遇到一些错误的情况？
  • 在这一步，参与者有没有可能遇到一些其他的行为？如果有，是什么？
• 这些问题的答案会得出一些次场景，次场景属于原始用例的一部分，是可供选择的行为。

举例：次场景

例如，考虑前面描述的主场景的第6步和第7步：
6.房主选择”选取摄像头“。
7.系统显示房屋的平面设计图。
 在这一点上，参与者能进行一些其他活动吗？答案是肯定的。参考非正式的描述说明，参与者可以选择同时查看所有摄像头的缩略视图。因此，一个次场景可能是“查看所有摄像头的缩略视图”。
 在这一点，参与者有没有可能遇到一些错误的情况？作为基于计算机的系统操作，可能出现许多错误情况。在这里，我们仅仅考虑在第6步和第7步中说明的活动的直接错误条件，问题的答案还是肯定的。带有摄像头图标的房屋平面可能还没有形式，这样选择“选取摄像头”就导致错误情况：“没有为该房屋配置平面设计图”。该错误情况就成为一个次场景。
 在这一点，参与者有没有可能遇到一些其他的行为？问题的答案再依次是肯定的。当第6步和第7步发生时，系统可能遇到报警。这将导致系统显示一个特殊的报警通知（类型、地点、系统动作），并向参与者提供和报警性质相关的一组操作。因为这个次场景可以在所有的实际交互中发生，所以不会成为ACS-DCV用例的一部分。而且，将开发一个单独的用例—“遇到报警条件”，这个用例可以根据需要被其他用例引用。

• 除了以上三个常规问题外，还应该问下面的问题：
  • 在这个用例中是否有某些具有“有效功能”的用例出现？包括：引用确认功能，可能出现的出错条件
  • 在这个用例中是否有支持功能（或参与者）的应答失败？如：应答超时
  • 性能差的系统是否会导致无法预期或不正确的用户活动？如：速度慢时用户的多重选择

8.2.3 编写正式用例

• 非正式用例对于需求建模常常是够用的。
• 但是，对于复杂的步骤场景，则需要更正的用例描述。
• 正式用例一般会有一个模板。模板内容包括：用例编号，用例名，参与者，前提条件，主要流程，异常处理等等。
• 模板内容细节可以根据情况微调。
• 下面是一个模板实例。

用例模板举例：监视的用例

用例：通过互联网访问摄像头监视 —— 显示摄像头视图（ACS - DCV）
迭代：2
最新更新记录：1月14日
主要参与者：房主
情境目标：从任何远程地点通过互联网查看遍布房间的摄像头输出
前提条件：必须完整配置系统；获得正确的用户身份证号和密码
启动：房主在远离家的时候决定查看房屋内部
场景：
  1.房主登录SafeHome产品网站。
  2. 房主输入用户身份证号。
  3. 房主输入两个密码（每个都至少）。
  4. 系统显示所有的主要功能按钮。
  5. 房主从主要功能按钮中选择“监视”。
  6. 房主选择“选取摄像头”。
  7. 系统显示房屋的平面设计图。
  8. 房主从房屋的平面设计图中选择某个摄像头的图表。
  9. 房主选择“视图按钮”。
  10. 系统显示一个由摄像头编号确定的视图窗口。
  11. 系统在视图窗口中以每秒一帧显示视频输出。
异常：
1.身份证号或密码不正确或无法确认。-- 参看用例：“确认身份证号和密码”。
2.没有为该系统配置监视功能。 – 系统显示恰当的错误信息；参看用例：“配置监视功能”。
3.房主选择“查看所有摄像头的缩略视图快照” – 参看用例：“查看所有摄像头的缩略视图快照”。
4.平面设计图不可用或未配置 – 显示恰当的错误信息，参看用例：“配置平面设计图”。
5.遇到报警条件 – 参看用例：“遇到报警条件”。
优先级：必须在基础功能之后实现，中等优先级。
何时可用：第三个增量。
使用频率：中等频度。
使用方式：通过基于个人计算机的浏览器和互联网连接到SafeHome网站。
次要参与者：系统管理员，摄像头。
次要参与者的使用方式：
1.系统管理员：基于个人计算机的系统
2.摄像头：无线连接。
未解决的问题：
1.有什么机制保护SafeHome产品的雇员在未授权的情况下能使用该功能？
2.足够安全吗？黑客入侵该功能将使最主要的个人隐私受侵。
3.在给定摄像机视图所要求的带宽下，可以接受通过互联网的系统响应吗？
4.当可以使用高带宽的连接时，能开发出比每秒一帧更快的视频速度吗？

说明：

1.用例关注功能和行为需求，一般不适合非功能需求。
2.模板也可以做成表格的形式
3.在很多情况下，不需要创建使用场景的图形化表示。
4.图形化表示可以促进理解，尤其是当场景比较复杂时。
5.UML为用例提供了图形化表现能力。

SafeHome系统的初步用例图

SafeHome系统ACS-DCV功能的活动图

泳道图

小节

• 为了确认软件需求，我们需要从不同的视角检验需求，本章主要从场景的观点考虑需求建模并检验。
• 基于场景建模产生的面向文本的表达称作“用例”。用例描述了特定交互方式，形成非正式或更加结构化或正规化的自然特征。这些用例能补充大量不同的UML图，覆盖更多交互的程序化观点。

8.3 用例图

1.用例图的含义

 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的视图称为用例图。

2.用例图的作用

• 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的理解系统的功能。
• 借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
• 用例图可视化地表达，具有直观、规范等优点，克服了纯文字性说明的不足。

3.用例图构成

3.用例之间的关系

（1）包含

• 包含关系指用例可以简单地包含其他用例，把它所包含的用例行为作为自身行为的一部分。
• 在UML中，包含关系是通过带箭头的虚线段加<< include >>字样来表示，箭头由基础用例（Base）指向被包含用例(Inclusion)。
  
  

（2）扩展

• 在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（Extension），原有的用例叫做基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。
• 一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。
  
  

（3）泛化

• 用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
• 子用例还可以添加、覆盖、改变继承的行为。
• 在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。
  

8.4 活动图

1.活动图的基本概念

• 活动图是一种用于描述系统行为的模型视图，它可用来描述动作和动作导致状态改变的结果。
• 通常，活动图用来描述单个用例或商业过程的逻辑流程、以及单个操作或方法的逻辑。
• 在UML中，活动的起点是活动图的开始状态，用黑的实心圆表示。活动的终止点是活动图的终止状态，用一个含有实心圆的空心圆表示。活动图中的活动既可以是手动执行的任务，也可以是自动执行的任务，用圆角矩阵表示。

2.活动图主要作用
1）描述一个操作执行过程中所完成的工作。说明角色、工作流、组织和对象是如何工作的。
2）活动图对用例描述尤其有用。它可描述用例的工作流，显示用例内部和用例之间的逻辑，可以说明用例的实例时如何执行动作以及如何改变对象状态。
3）活动图对理解业务处理过程十分有用。活动图可以画出工作流用以描述业务，有利于与领域专家进行交流。通过活动图可以明确业务处理操作是如何进行的，以及可能产生的变化。
4）描述复杂过程的算法，在一点活动图和传统的程序流程图的功能相似。

3.活动图的组成
1）动作状态

• 动作状态（action state）是基本（原子）动作或操作的执行状态，它不能被外部事件中断。
• 在UML中，动作状态使用圆角矩形表示，动作状态名字写在矩形内部。
• 两个特殊状态：开始状态、结束状态。
  

2）活动状态

• 活动状态是非原子性的，表示一个具有子结构的状态。
• 活动状态可以分解成其他子活动或动作状态。
• 前面提到的动作状态是一种特殊的活动状态。可以把动作状态理解为一种原子的活动状态，即它只有一个入口动作，并且它活动时不会被转换所中断。
• 活动状态和动作状态的表示图标相同，都是平滑的圆角矩形。两者不同的是活动状态可以在图标中给出入口动作和出口动作等信息。
  
  3）组合活动
• 组合活动是一种内嵌活动图的状态
• 如果一些活动状态比较复杂，就会用到组合活动。
  
  4）分叉与结合
• 对于一些复杂的大型系统而言，对象在运行时往往不止存在一个控制流，而是存在两个或者多个并发运行的控制流。为了对并发的控制流建模，在UML中有分叉和汇合的概念。
• 分叉用来表示将一个控制流分成两个或者多个并发运行的分支，结合用来表示分支在此得到同步。
  
  5）分支与合并
• 分支将转换路径分成多个，根据条件（布尔值）的真假来判定动作流向。
• 分支的每个路径的监护条件应该是互斥的，保证只有一条路径的转换被激发。
• 合并指的是两个或者多个控制路径在此汇合的情况。
• 合并和分支常常成对使用，合并表示从对应分支开始的条件行为的结束。
  
  6）泳道
  泳道是为了对活动的职责进行组织在活动图中将活动状态分为不同的组

标签：需求,--,实践者,系统,建模,视图,用例,软件工程,摄像头
来源： https://blog.csdn.net/weixin_40247263/article/details/113751804