软件工程：需求分析与验证-分析模型的表示

需求分析与验证

需求分析的任务：在需求获取阶段的输出制品的基础上，获得对软件需求更加深入、更加完整的理解，并且将软件需求表示为面向软件设计人员、易于修改和维护的分析模型

构建分析模型的原因：

1. 分析模型比用例模型更加结构化，更加清晰直观（所以构建过程实际上是不断深入理解用例模型的过程，同时也是去除自然语言中描述的可能存在的模糊性和不一致性）
2. 分析模型是用例模型与软件设计模型之间的“桥梁”（分析模型比用例模型更加近设计模型，更适合软件设计师设计软件系统的结构、构思软件求解算法，更容易给不熟悉业务的软件设计师理解）

分析模型的表示

交互图

• 顺序图

  侧重点：强调信息传递的时间序

  构成：对象以及生命线与活跃期，消息传递，注解（纵向代表时间轴 横向由多个参与交互的对象构成）

  对象：表示为嵌于矩形框内形如[对象名]：[类名]的文本，其中对象、类名至少存在一个。当同一类有多个对象参与同一张顺序图所示的交互时，或者当对象将作为参数出现在本图汇总的某条消息中时，对象名不能省略（消除二义性）

  ------------------------

  对象分为主动对象和被动对象

  主动对象：该对象的消息在时间段内直接或间接的引起了其他对象的活跃（注：一张顺序图中可能存在多个主动对象，此时主动对象的控制流将并发执行。两个主动对象之间的消息传递应该是异步）

  被动对象：该对象在时间段内直接或间接的被其他对象的消息引起活跃（注：被动对象在响应、处理消息时接受消息源对象的控制，在消息处理完毕后将控制权交还。因此被动对象活跃期的顶部位于消息接收点，底部位于消息处理完成时刻点）

  生命线：对象之下的垂直虚线为生命线，表示对象在始于对象表示图元所处的时间起点、止于对象生命终结符之间的时间段内的软件系统中存在。

  注：可以在对象生命线上嵌入状态符，表示对象在状态符所处的时间点上必定进入相应的状态。还可以用状态符来表示来自其他对象的某条消息将导致对象状态的改变，此时状态符应该在时间轴方向上靠近那条消息。

  消息传递：对象间的消息传递表示为对象生命线之间的有向边，边上可以标注[*] [监护条件] [返回值：=]消息名 [（参数表）]（注： * 为迭代标记，表示同一消息对同一类的多个对象发送）

  注：顺序图中的消息分为同步和异步，分别使用实心三角形箭头和普通三角形箭头（同步消息的发送者等待消息接收对象将消息处理完成后再继续，异步消息的发送者在发送完消息后不等待接收方就继续自己的处理）

  消息：

  • 自消息：指一个对象传向其自身的消息
  • 返回消息：指当一个对象将消息发送给另一个对象后，另一个对象返回的虚线有向边，表示原消息已处理的消息
  • 创建消息：表示对消息传递目标对象的创建（注：< < create > >）
  • 销毁消息：表示对消息传递目标对象的删除（注：< < destroy> >）

  注解：顺序图的左侧可以增加注解，来阐释消息的意义、有关的月初以及消息传递时间点之间的延时约束。（注：注解所处的位置应该在水平方向上于对应的消息对齐。为了精确的描述延时约束，可以在对象的生命线或者活跃期上标注时间标签）

  建模规则：

  1. 在业务分析和需求分析阶段，建模者并不需要过于精细地刻画顺序图的所有图形元素。消息名和消息传递条件均可以采用业务术语以及自然语言描述，消息的参数表可以省略
  2. 无论是在分析阶段还是设计阶段，建模者都应该聚焦于对象间的关键的主要的交互，避免因为过多的 细节而导致顺序图含混不清，复杂不堪
     • 作为业务分析或者需求分析模型的顺序图，不必考虑用户界面对象和业务对象之间的交互、数据的持久存储等问题
     • 除非特别的必要，一般尽量避免显示表达返回、创建、销毁消息以及对象生命终结符，也不需要显示区分同步、异步消息
     • 无需过多考虑对象的活跃期图元，也不需要显示表示活跃期的嵌套，一般利用建模工具自动生成的活跃期图元即可
  3. 在设计和事先模型中，消息名和返回值类型，在不会造成歧义的情况下，可以省略消息名。（若省略消息名，则类型需要大写，若省略类型，则消息名小写）

  布局规则：

  1. 如果有用例的主动执行者的实例，那么他应该位于顺序图的左侧；对称地，如果有用例的被动执行者的实例，则他应该位于顺序图的右侧
  2. 当采用分层设计思想的时候，应该将同层 的对象放置到一起。每层对象集合的排序规则是：接近用户界面的层靠左，接近后台处理的层靠右；对于在软件分层结构中相邻的层，其对象集合在顺序图的水平布局汇中也相邻。因为同层对象的交互比较多，相邻层面的交互比较少，跨层交互更少，所以此排序规则可以有效的缩短消息边的长度，简化顺序图
  3. 对象的排序应该尽量缩短消息边的长度，并且尽量使得消息边的方向从左往右

  关于文字的规则：

  1. 将文字置于读者易于辨识的一段
  2. 返回消息上的文字一定要置于消息的目标端

• 通信图

  侧重点：突出交换消息的对象之间的合作关系

  关系：通信图是顺序图的另一种表现形式，两者等价，但是侧重点不同

  构成元素：

  1. 通信图的结点是参与交互的对象，这些对象的标识方法与顺序图相同。但是由于不在设置单独的时间维度，所以在对象在通信图中可以自由定位
  2. 对象之间的连接成为连接器，它扮演对象之间的消息传递通道的角色。连接器可以有向（支持双向消息传递）也可以无向（消息沿着方向传递）。连接器的两端可以标注角色名，与类图的关联边相似
  3. 在连接器上可以标识一到多条消息，每条消息的传递方向用靠近消息的小箭头表示。通信图也可以区分同步、异步消息以及返回消息、创建消息和销毁消息。
  4. 消息的
  5. 描述语法为：[序号] [迭代描述符] [：] [条件] [返回值：=] 消息名 [（参数表）] [：返回类型]

  布局规则：

  1. 对象按行上下对齐，按列左右对齐，连接器绘制成水平线段，垂直线段或者由水平、垂直两种线段组合而成的折现，避免斜线
  2. 主动执行者位于左上方，被动执行者位于右侧
  3. 采用分层设计的思想时，分层对象的布局方法与顺序图中的类似，不过通信图允许同层的多个对象布局成多行、多列。
  4. 对象的排列应该尽量缩短连接器的长度，并且尽量是消息的传递方向从左往右从上往下。

• 两者的选择

  1. 当强调消息传递的时间顺序、刻画用例的动作序列、业务分析和需求建模阶段，使用顺序图
  2. 当强调对象之间的交互、协作关系时、刻画软件内部等某项功能的实现构想时、设计和实现阶段，使用通信图

状态图

构成：

作用：描述一个实体在时间刺激下的反应式动态行为

内容：包含实体所有可能的状态，在每个状态下能够响应的时间以及时间发生时的状态变迁与响应动作

状态：对象的具有统一行为模式的某个生命周期阶段。（状态对应于对象的属性构成的约束条件，当满足条件时，对象对于时间的响应行为完全一样）

事件：对象的生命周期中某个时刻点上发生的值得关注的针对该对象的一种刺激或者触动

• 消息型事件–其他对象传向该对象的同步消息，表现为 消息名[(参数表)]
• 信号型事件–其他对象传向该对象的异步信号，表现为 信号名[(参数表)]（命名最好表达为过去式，如“…以改变”）
• 时间型事件–时间到达指定的绝对时刻点（表达为at（绝对时间点））到达指定时间之后的相对时刻点（after（基准时间点，时延））
• 条件型事件–对象所处的环境以及对象属性值的变化导致某个条件成立，表示为 when（条件表达式）

活动：一种计算过程；在过程中向对象发送同步或者异步信号，创建删除对象等等。差异：活动位于状态中，他可以比动作复杂，执行时间较长

动作：一种计算过程；在过程中向对象发送同步或者异步信号，创建删除对象等等。差异：位于状态之间的迁移边上，较为简单，执行时间较短

事件：对象的生命周期中的某个时刻点上发生的、值得关注的针对该对象的一种瞬时刺激或者触动

• 消息型事件—其他对象传向该对象的同步消息，表示为 消息名[（参数表）]
• 信号型事件–其他对象传向该对象的异步信号，表示为 信号名[（参数表）]（命名最好采用过去式，如“…属性以改变”）
• 时间型事件–时间到达指定的绝对时刻点（表达为 at（绝对时间点））；到达指定时间之后的相对时刻点（表达为after（基准时间点，时延））
• 条件型事件–对象所处的环境以及对象属性值的变化导致某个条件成立，表示为 when（条件表达式）

活动：一种计算过程，在过程中向对象发送同步消息或者异步信号，创建或者删除对象等。

动作：同动作一致。差异：动作位于状态之间的迁移边上，较简单，执行时间很短；活动位于状态中，比动作复杂，执行时间较长。

基本机制：

状态图的构成：

• 状态节点：

  • 状态名：简洁且恰当的描述对象处于此状态时的业务含义

  • 入口活动：当对象经过迁移边从其他状态进入本状态，则入口活动执行

  • 出口活动：当对象经过迁移边从本状态进入其他状态，则出口活动执行

  • do活动：当对象进入状态执行入口活动后应该执行的活动

  • 内部迁移：

    注：与后面的外部迁移的内容几乎相同，参照外部迁移即可

• 迁移边：表示状态之间因为时间激励而出发的对象的状态变化，表示为状态结点之间的有向边。

  自迁移：源状态节点与目标状态节点相同的特殊的外部迁移。

  （注：有向边上面可以标注[事件] [监护条件] [/动作]；事件表示触发此次状态变迁的事件，监护条件表示约束状态迁移真正发生的条件表达式；动作表示状态前一期间应该执行的动作）

• 初态—一种伪状态，并不真正对应对象的属性值的约束（因为对象不能真正位于初态）

• 终态—表示对象即将消亡

  注：一张状态图应该恰有一个初态和一到多个终态。

  ​ 初态只能发出迁移边，终态只能作为迁移边的目标

  ​ 从初态触发的迁移边上不能出现触发事件，并且如果从初态触发的迁移边唯一，那么此边上不能出现监护条件

  ​ 如果有多条初态触发的迁移边上均包含监护条件，那么这些条件必须覆盖所有的可能性，不能出现这些监护条件均为不成立的情形

  ​ 指向终态的迁移边与普通的迁移边无异

结构化机制：

• AND逻辑复合：对象处于状态s当且仅当对象同时处于s1…，就可以认为复合状态对应的有关对象属性值的约束公式能够被分解为n个必须同时成立的子公式，每个子公式由一个子状态来表示
• XOR逻辑复合：对象处于状态s当且仅当对象同时处于s1…，就可以认为子状态si继承了复合状态有关的对象属性值的约束，并且增强了这种约束来使得子状态之间可以相互区分

建模规则：

1. 要高度警惕某些并非初态的状态结点上只有离开的迁移边，没有到达的迁移边，或者某些并非终态的状态节点上只有到达的迁移边，没有出发的迁移边
2. 在顶层状态图中表示出初态与终态，可以使得状态图体现对象在其完整的生命周期中的行为。在子状态图中，初态和终态可以看实际条件需要而设置
3. 状态中的入口活动必须适用于所有的到达迁移，出口活动必须适用于所有的离开迁移
4. 从同一状态触发、由同一事件触发的迁移边上的监护条件应该是互斥的。
5. 使用结构化状态图来描述对象的复杂行为，避免过于庞大的平板化状态图
6. 利用复合状态合并迁移边

UML扩充机制

• 约束
• 标记值
• 构造型