第八章 基于场景的方法
概念:文字记录是极好的交流工具，但并不一定是表达计算机软件需求的最好方式。需求建模使用文字和图表的综合形式，以相对容易理解的方式描绘需求，更重要的是，可以更直接地评审它们的正确性、完整性和一致性。
步骤:基于场景的建模从用户的角度表现系统。在基于场景建模时，将更好地理解用户如何与软件交互，发现没有覆盖到的利益相关者所需的主要系统功能和特性。
质量保证措施:必须评审需求建模工作产品的正确性、完整性和一致性，必须反映所有利益相关者的要求并为从中导出设计建立基础。
1 需求分析
需求分析产生软件工作特征的规格说明，指明软件和其他系统元素的接口，规定软件必须满足的约束。在需求分析过程中，软件工程师(有时这个角色也被称作分析师或建模师）可以细化在前期需求工程的起始、获取、协商任务中建立的基础需求（第7章)。需求建模动作结果为以下一种或多种模型类型：
场景模型：出自各种系统“参与者”观点的需求。
面向类的模型：表示面向对象类（属性和操作）的模型，其方式为通过类的协作获得
系统需求。
基于行为和模式的模型：描述如何将软件行为看作外部“事件”后续的模型。
数据模型：描述问题信息域的模型。
面向流的模型：表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行
数据变换。
需求模型的三个主要目标：描述客户需要什么、为软件设计奠定基础、定义在软件完成后可以被确认的一组需求。
1.2 分析经验的原则
1.2.1 模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。“不要陷人细节”即不要试图解释系统将如何工作。
1.2.2 需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。
1.2.3 关于基础结构和其他非功能的模型应推延到设计阶段再考虑。例如，可能需要一个数据库，但是只有在已经完成问题域分析之后才应考虑实现数据库所必需的类、访问数据库所需的功能以及使用时所表现出的行为。
1.2.4 最小化整个系统内的关联。表现类和功能之间的联系非常重要，但是，如果“互联”的层次非常高，则应该想办法减少互联。
1.2.5 确认需求模型为所有利益相关者都带来价值。对模型来说，每个客户都有自己的使用目的。例如，业务人员将使用模型确认需求，设计人员将使用模型作为设计的基础，质量保证人员将使用模型帮助规划验收测试。
1.2.6 尽可能保持模型简洁。如果没有提供新的信息，就不要添加附加图表;如果一个简单列表够用，就不要使用复杂的表示方法。
1.3 域分析
软件域分析是指识别、分析和详细说明某个特定应用领域的共同需求，特别是那些在该应用领域内被多个项目重复使用的……(面向对象的域分析是）在某个特定应用领域内，根据通用的对象、类、部件和框架，识别、分析和详细说明公共的、可复用的能力。域分析的目标很简单：查找或创建那些广泛应用的分析类或分析模式，使其能够复用。
使用本书前面介绍的术语，域分析可以被看作软件过程的一个普适性活动。意思是域分析是正在进行的软件工程活动，而不是与任何一个软件项目相关的。域分析师的角色有些类似于重型机械制造业中一名优秀的刀具工的角色。刀具工的工作是设计并制造工具，这些工具可被很多人用来进行类似的而不一定是同样的工作。
如下图说明了域分析过程的关键输人和输出。应该调查领域知识的来源以便确定可以在整个领域内复用的对象。
1.4 需求建模的方法
第一种考虑数据和处理的需求建模方法称作结构化分析，其中处理过程将数据作为独立实体加以转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理过程将如何转换数据。
需求建模的第二种方法称作面向对象的分析，这种方法关注类的定义和影响客户需求的类之间的协作方式。UML 和统一过程（第4章）主要是面向对象的分析方法。
基于场景的元素表述用户如何与系统和使用软件时出现的特定活动序列进行交互。基于类的元素的内容包括：系统操作的对象，应用在这些对象间影响操作和对象间关系（某层级）的操作，以及定义的类间发生的协作。行为元素描述了外部事件如何改变系统或驻留在系统里的类的状态。最后，面向流的元素表示信息转换的系统，描述了数据对象在流过各种系统功能时是如何转换的。
如图8-3所示，需求模型的每个元素表示源自不同观点如下图：
需求模型导出每个建模元素的派生类。然而，每个元素（即用于构建元素和模型的图表)的特定内容可能因项目而异。就像我们在本书中多次提到的那样，软件团队必须想办法保持模型的简单性。只有那些为模型增加价值的建模元素才能使用。
2 基于场景建模
使用UML需求建模将从开发用例、活动图和泳道图形式的场景开始。
2.1 创建初始用例
第7章中我们已经提到，用例从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。但是我们如何知道:(1）编写什么?(2)写多少?(3）编写说明应该多详细?(4）如何组织说明?如果想让用例像一个需求建模工具那样提供价值，那么必须回答这些问题。
2.1 细化初始用例
2.2 编写正式用例
这三个过程也是一个迭代的过程，从简单到复杂，从简易到完善。
3 补充用例的UML模型
很多基于文本的需求建模情景（即使和用例一样简单）不能简明扼要地传递信息。在这种情况下，你应能从大量的UML图形模型中进行选择。
3.1 开发活动图
UML 活动图在特定场景内通过提供迭代流的图形化表示来补充用例。一个通过互联网访问摄像机监视设备并显示摄像机视图功能的活动图例子如下图：
3.2 泳道图
UML泳道图表现了活动流和一些判定，并指明由哪个参与者实施。同时指出哪个参与者（如果在某个特定用例中涉及了多个参与者)或分析类（第9章）负责由活动矩形所描述的活动。职责由纵向分割图中的并行条表示，就像游泳池中的泳道。
例如，接口类表示房主可见的用户接口。活动图标记出对接口负责的两个提示——“提示重新输入”和“提示另一视图”。这些提示以及与此相关的判定都落人了接口泳道。但是，从该泳道发出的箭头返回到房主泳道，这是因为房主的活动在房主泳道中发生。一个通过互联网访问摄像机监视设备并显示摄像机视图功能的泳道图如下图
借助活动图和泳道图，面向过程的用例表示出各种参与者行使的一些特定功能（或其他处理步骤)，以便满足系统需求。但是需求的过程视图仅表示系统的单一维度，在第9章和第10章，我们将考察需求建模的其他维度。