需求分析之行为和模式

第十章 需求分析：行为和模式

概念:在这一章将学习需求建模的其他维度——面向行为建模、模式，以及开发WebApp时要考虑的特定需求分析问题。这里的每种模型都是基于类的方法和基于场景的方法的补充。

步骤:行为建模描述了系统及其类的状态，以及事件对这些类的影响。基于模式的建模利用现有领域的知识使得需求分析更为容易。WebApp 的需求模型特别适用于表述内容、交互操作、功能和配置相关的需求。

质量保证措施:必须评审需求建模产品的正确性、完备性和一致性。必须反映所有利益相关者的要求，为导出设计建立基础。

关键概念：分析模式、行为模型、事件、顺序图、状态图、状态表达

1 生成行为模型

前面章节讨论的建模表示方法表达了需求模型中的静态元素，现在则是把它转换成系统或产品的动态行为的时候了。要实现这一任务，可以把系统行为表示成一个特定的事件和时间的函数。

行为模型显示了软件如何对外部事件或激励做出响应。要生成模型,分析师必须按如下步骤进行:

（1）评估所有的用例，以保证完全理解系统内的交互顺序;

（2）识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联;

（3）为每个用例生成序列;

（4）创建系统状态图;

（5）评审行为模型以验证准确性和一致性。

2 识别用例事件

在第8章中，我们知道用例表现了涉及参与者和系统的活动顺序。一般而言，只要系统和参与者之间交换了信息就发生事件。事件应该不是被交换的信息而是已交换信息的事实。

3 状态表达

在行为建模中，必须考虑两种不同的状态描述：

(1）系统执行其功能时每个类的状态;

(2）系统执行其功能时从外部观察到的系统状态。

类状态具有主动和被动两种特征，被动状态只是某个对象所有属性的当前状态。对象的主动状态指的是对象进行持续变换或处理时的当前状态。类Player可能具有如下的主动状态:移动、休息、受伤、疗伤、被捕失踪等。事件（有时称为触发器）才能迫使对象做出从一个主动状态到另一个主动状态的转移。

分析类的状态图。UML状态图就是一种行为模型，该图为每个类呈现了主动状态和导致这些主动状态发生变化的事件(触发器)。

4 需求建模的模式

软件模式是获取领域知识的一种机制，在遇到新问题时可以反复使用。分析模式的最初创作者没有“创建”模式，但在需求工程工作中发现了模式。第7章引入了分析模式的概念并指明这些模式表示了某些应用领域(例如一个类、一个功能或一个行为)，当为这个领域的应用执行需求建模时会重复使用这些模式。

4.1 发现分析模式

需求模型由各种元素组成:基于场景(用例)、基于类(对象和类)和行为(事件和状态)。其中每个元素都是从不同的视角检查问题，并且每一个都提供一种发现模式的机会，可能发生在整个应用领域,或者发生在类似但不同的应用领域。