1.需求建模_生成行为模型

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

1.1生成行为模型的步骤

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

1.2识别用例事件

  • 用例表现了涉及的参与者和系统的活动顺序。
  • 一般而言，只要系统和参与者之间交换了信息就发生事件。
  • 一旦确定了所有的事件，这些事件将被分配到所涉及的对象，对象负责生成事件或识别已经在其他地方发生的事件。
  • 识别用例事件，就是从场景中，找到事件及参与者，标记交换的信息及条件和限制。

1.3状态表达

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

    • 1)系统执行其功能时每个类的状态；
    • 2)系统执行其功能时从外部观察到的系统状态。

  • 类状态具有被动和主动两种特征。

    • 被动状态是某个对象所有属性的当前状态。
    • 对象的主动状态指的是对象进行持续变换和处理时的当前状态。

  • 事件促使对象从一个状态转移到另一状态。

1.4分析类的状态图

  • 状态图中需要说明导致转移发生的事件。
  • 状态转移发生一般需要满足条件，守卫是为了保证转移发生而必须满足的一个布尔条件。
  • 一般而言，转移的守卫通常依赖于某个对象的一个或多个属性值。
  • 动作是和状态转移同时发生的。状态转移通常动作包含对象的一个或多个操作。

2.1顺序图

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

3.1结论

  • 基于场景的建模，从用户用系统做什么切入。
    答：用例图、用例规约、活动图
  • 基于类的建模，关注系统有什么
    答：类对象图，表达对象之间的关联关系及属性和方法
  • 行为建模，描述系统的动态特性
    答：顺序图、状态图、协作图
  • 流模型，关注数据流动和加工
    答：数据流图、数据字典、加工说明
  • 他们的视角不同，但是目的相同

总之，需求分析建模的目的是为了解决系统“做什么”的问题

三种需求模型的关系

  • 三个侧面反映系统的场景、类、和行为
  • 分析过程没有先后，是不断迭代的过程