10.1 生成行为模型

• 行为模型显示了软件如何对外部事件或激励作出响应。
• 类模型侧重的是系统的静态结构。
• 行为模型侧重的是系统的动态表示。
• 系统行为表示成一个特定事件和时间的函数。
• 可以简单理解成系统运行起来后，事件发生时系统如何转换，或随着时间的推移系统如何运转。

生成行为模型的步骤：

1. 评估所有的用例，以保证完全理解系统内的交互顺序。
2. 识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联。
3. 为每个用例生成序列。
4. 创建系统中的状态图。
5. 评审行为模型以验证准确性和一致性。

10.2 识别用例事件

• 用例表现了涉及的参与者和系统的活动顺序。
• 一般而言，只要系统和参与者之间交换了信息就发生事件。
• 识别用例事件，就是从场景中，找到事件及参与者，标记交换的信息及条件和限制。

SafeHome实例

分配事件到涉及对象

• 一旦确定了所有的事件后，这些事件需要被分配到所涉及的对象。
• 对象生成事件
  • 房主生成输入密码事件
• 对象响应事件
  • 控制面板识别比较密码事件
• 响应事件的对象一般会发生状态变化

10.3 状态表达

• 行为建模中，必须考虑两种不同的状态描述：
• 系统执行其功能时每个类的状态；
• 系统执行其功能时从外部观察到的系统状态。
• 类状态具有被动和主动两种特征。
• 被动状态是某个对象所有属性的当前状态。
• 对象的主动状态指的是对象进行持续变换和处理时的当前状态。
• 事件促使对象从一个状态转移到另一个状态。

分析类的状态图

• 行为模型的组成之一是UML状态图
• UML状态图为每个类表现活动状态和导致这些活动状态变化的事件（触发器）。
• 状态图中需要说明导致转移发生的事件。
• 状态转移发生一般需要满足条件，守卫是为了保证转移发生而必需满足的一个布尔条件。
• 一般而言，转移的守卫通常依赖于某个对象的一个或多个属性值。
• 动作是和状态转移同时发生的。状态转移通常动作包含对象的一个或多个操作。

补充：

一：状态图组成

椭圆或圆角矩形：表示对象的一种状态，内部填写状态名等信息。

箭头线：表示的状态转移。

事件：引起状态转换的原因，事件名可在箭头线上方标出。
条件：事件名后可加方括号，括号内写状态转换条件。
实心圆：初始状态。

内部实心的同心圆：最终状态。

二：顺序图（时序图）

• 顺序图也是UML中表现行为的方式
• 顺序图能说明事件如何引发从一个对象到另一个对象的转移。
• 顺序图是用时间函数表现事件如何从一个对象到另一个对象。
• 可以作为用例的速记版本。
• 一旦完成了完整的顺序图，所有导致系统对象之间转移的事件都可以被整理为输入事件集合和输出事件集合。

SafeHome安全功能的顺序图（部分）

顺序图说明：

顺序图将交互关系表示为一个二维图。
纵向是时间轴，时间沿竖线向下延伸。
横向轴代表了在协作中各对象的角色。
角色用生命线表示。
    当对象存在时，角色用一条虚线表示，
    当对象的过程处于激活状态时，生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

三：顺序图和状态图实例

10.4 需求建模的模式

• 软件模式是获取领域知识的一种机制从而遇到新问题时可以反复使用。
• 在某些情况下，领域知识在同一应用领域中用于解决新问题。
• 在一些情况下，通过模式获取的领域知识可借助模拟用于完全不同的应用领域。
• 模式应“明确的常见问题：哪种模式适用、规定的解决方案、在实践中使用模式的假设和约束，以及关于模式的某些常见的其他消息，注入使用模式的动机和驱动力，讨论模式的优缺点，参考在实践应用中某些已知的使用模式的样例”。
• 需求建模模式是一些经验总结，需求建模套路，模板。

小结

• 基于场景的建模，从用户用系统做什么切入。
• 基于类的建模，关注系统有什么
• 行为建模，描述系统的动态特性
• 流模型，关注数据流动和加工
• 他们的视角不同，但是目的相同。总之，需求分析建模的目的是为了解决系统“做什么”的问题。