《系统分析师UML实务手册》-- 笔记

由于上周发一篇uml关系的笔记，但是忘了里面那个是哪本书说的，花了两天找着了，然后读了一遍。
这本书整体不难，说话有好听，超喜欢的。而且顺着作者思路，砍去细枝末节，至少让我们知道整体的骨架是什么样，虽然写的是系统分析师，但是还是挺适合咱们初级程序员读的。由需求到类图，这个系统抽象的过程，让我学到了好多，我只是一只小菜鸟，不过有收获就行~，以后慢慢填充。
这本书安利一波~
笔记开始：

---

做好系统分析

CIM-1：定义业务流程

作用：

定义及分析业务流程(Business Process)：
* 为了尽快理清系统范围
* 挑选与系统有关的业务流程
* 以便估算开发成本及时间

生成：

• 业务用例图

  • 每一个业务用例代表一条业务流程
  • 业务执行者则代表位于企业外但会启动或参与业务流程的人

• 简述

CIM-2：分析业务流程

生成：

• 针对每一个业务用例，系统分析员开始分析它的工作流程
• 绘制活动图(Activity Diagram)
• 与业务人员取得共识

CIM-3：定义系统范围

根据 CIM-1 和 CIM-2 之后，整理成 系统用例图

CIM3与前三者的关联性

• CIM-2活动图中的每一个动作，都可能成为CIM-3的系统用例
• CIM-1中的业务执行者，以及CIM-2的动作负责人，都可能成为CIM-3的系统执行者

PIM-1：分析系统流程

针对每一个系统用例，分析其内部细节，并编写相近的 系统用例叙述(UC Description)

用例叙述格式

目前没有统一格式，不过主要细节需要暴露出来，如：
* 用例名称
* 用例简述
* 用例图
* 主要流程
* 替代流程
* 例外流程
* 业务规则

PIM-2：分析业务规则

• 企业通过一组规则(Business Rules)来控制整体的运作，包括人员，流程，系统，概念的运作，皆受制于业务规则。
• 使用UML的 状态图 来呈现重要的业务规则

PIM-3：定义静态结构

• 用 类图 来表他系统内部的静态结构。
• 只有具备稳定且弹性的静态结构，才能顺应需求变更，迅速支撑多样化的系统用例。
• 类图是程序员最关切的设计图之一，程序员通常会按照类图的内容，来编写并组织源代码

需要遵守的

• 优先寻找操作
• 有的主要属性可以直接从PIM-1中找到

PIM-4：定义操作及方法

• 用 序列图 来表达，系统内部一群对象合力完成某个系统用例时，执行期间的交互情形。
• PIM-1的系统用例叙述 与PIM-3的类图 相结合，画出序列图

绘制序列图的大致方法

通过序列图的思考与表达，视图安排依据类们所生成的一群对象之间的交互，让这一群对象可以合力完成某一个系统用例。

同时，在序列图中，一群对象交互所引发的操作，则可以反馈给类图，定义出更多的操作及属性，甚至发现之前未发现的其他类及关系。

绘制序列图：
* 扮演启动者的执行者对象放置于序列图最左方；扮演支持者的执行者对象放置于序列图的最右方
* 针对系统用例叙述里所记载每项流程步骤，判断执行时需要使用到那些数据，且可指派拥有该数据的对象负责该项工作
* 试着执行序列图，以便调整流程，并且为操作加上参数

* 把绘制序列图时所找到的操作及属性，反馈给类图

---

定义业务流程(详述)

为什么定义业务流程

• 尽快理清系统范围
• 估算开发成本及时间

CIM-1：定义业务流程 – 需要注意的点

访谈对象的选择

业务组织内部充斥着各式的流程，不过系统分析员仅需注意跟 系统有关的业务流程， 另外访谈对象能够有头有尾地沟通出完整流程，所以访谈对象一般可选择：
* 熟知业务组织运作的资深员工
* 具有广泛观点的主管人员或领域专家

CIM-1定义业务流程(业务用例模型)的生成

• 业务用例图

  • 业务执行者
  • 代表位于业务组织外但会启动或参与业务流程的人
  • 业务用例
  • 每一个业务用例代表一条业务流程

• 业务用例简述

  • 主要用来记录和区分业务流程

沟通时可大致提出的问题

• 系统上线后，可能会影响到哪几条流程？(绘制业务用例)
• 什么情况下会开始执行某流程，可有业务组织外部的人士会启动或参与流程？(绘制业务执行者)
• 针对每一个业务用例，请用一两句话简单说明它是做什么用的？(撰写业务用例简述)

—

CIM-2：分析业务流程

WHY: 用活动图(Activity Diagram)分析工作流程

• 活动图能够让分析人员聚焦流程内部的一连串工作
• 工作项目属性复杂，包括：
  
  • 纯人工操作
  • 背后可能有系统的协助
• 找出可信息化的工作项目，并以此定义出系统未来可以提供的服务项目，就可以定义出初步的系统范围了

切分工作项目 可以借鉴的 准则

• 依时间间隔切分工作项目
  
  • 时间间隔代表执行可以不连续，具备 可切分性
• 纯人工/可信息化的工作项目
• 记录系统上线之后的工作项目
• 每项工作只有一位负责人

—

CIM-3： 定义系统范围

CIM-1 和 CIM-2 的文件与CIM-3的关联性

• CIM-2活动图中的每一个动作，都可能成为CIM-3的系统用例
• CIM-1的业务执行者，以及CIM-2中的动作负责人，都可能成为CIM-3的系统执行者(System Actor)

CIM-3 的文件生成

• 1. 系统用例图
• 1. 系统用例简述

定义系统用例时，可参考的建议

• 每个系统用例最好只有一个启动者
• 系统用例执行期间，如果有联机其他系统，将它们列为支持者
• 遇到定时启动的系统用例，可以定义一个“定时启动者(Timer)”的虚拟启动者

概念

• 启动者(Initiator)

  • 启动用例的执行者
  • 通常直接操作计算机的用户，可以列为系统用例启动者

• 支持者(Support)

  • 剩下的不具有启动特质的执行者
  • 在系统用例执行期间，需要联机其他系统取得协助的联机系统是支持者

绘制系统用例图时，常见的做法

• 采用带箭头关系线，让启动者指向用例，用例指向支持者
  
  • 好处：从图上可以明确分辨出启动者与支持者。
• 一个用例通常只有一个启动者，不过可能出现多个支持者
• 若出现多个启动者的情况，尝试切割成一人一会话(One User, One Session)
• 有时不同用户都具有启动用例的特性，建议在图上绘出最重要或最主要的启动者，其余启动者记录在用例叙述里
  
  • 好处：降低图面上的复杂度

---

分析系统流程

PIM-1 ~ PIM4的产生结果

PIM-1 ~ PIM-4的产生结果作为需求文件中的一部分。
* PIM-1：分析系统流程(系统用例叙述)
* PIM-2：分析业务规则(状态图)
* PIM-3：定义静态结构(类图)
* PIM-4：定义操作及方法(序列图)

系统用例叙述

用例叙述一般包含
* 1. 用例基本数据
* 用例名称
* 用例编号(ID)
* 用例简述
* 用例图
* 系统
* 执行者
* 相关用例

• 2. 执行流程

  • 主要流程(Basic Flow)
  • 替代流程(Alternate Flows)
  • 例外流程(Exception Flows)

• 3. 条件及规则

  • 启动事件或条件(Triggers)
  • 前置条件(Preconditions)
  • 后置条件(Postconditions on Success)
  • 失败时状态(Status on Failure)
  • 业务规则(Business Rule)

• 4. 相关文档

  • 用例叙述的历史版本
  • UML图
  • 参考画面
  • 其他非UML文档

• 5. 其他事项

  • 优先性(Priority)
  • 迭代等级(Iteration)
  • 待解决问题(Issues)
  • 基本假设(Assumptions)
  • 相关人员
  • 特殊需求(Special Requirements)

用例基本数据->FULL

用例名称

一个用例拥有一份用例叙述，所以用例叙述文件里面，一定要标示出对应的用例名称

用例编号

用例叙述是用例的一部分，所以用例叙述没有自己的编号，而是拿用例的编号当做用例叙述的编号

用例简述

用一两句话简洁说明该用例，以增强叙述的可理解性

用例图

在用例叙述的开头处附上相关的Use-Case Diagram，丰富用例叙述的表达方式

系统

就是提供此用例的系统名称。有时候在所附上的用例图件里可能出现负责提供此用例的系统名称

执行者

执行者可能具备不同特质，有时候会被细分：启动者及支持者

相关用例

常见的相关性有两方面
* 执行用例前必须先行执行过某相关用例
* 执行用例期间可能驱动其他的包含用例(Inclusion Use Case),或是因条件符合 驱动其他的扩展用例(Extension Use Case)

• 包含关系

  • 包含关系来自于抽象(Abstraction)，即从数个不同的用例之中剥离处于共同的部分，而成为重用的用例

• 扩展关系

  • 用以表示某一个用例的对话流程，可能会依条件临时插入另一个用例的对话流程。前者称为“扩展用例”(Extension UC), 后者称为“基用例”(Base UC)
  • 有了扩展关系，我们可以将特定条件下引发的流程记录于扩展用例中。
  • 扩展关系来自于用例内执行活动的过程分为主要过程(Main Course)以及可选择过程(Alternative Course)

执行流程->FULL

主要流程

这是用例叙述最核心的部分，记载了整个用例正常的执行过程

替代流程

一个用例叙述里面通常会包含主要流程，同时可以包含数段替代流程。替代流程最终要走回主要流程。

例外流程

一旦例外流程，系统将不会继续执行完剩下的主要流程

条件及规则->FULL

启动事件或条件

记录启动用例的 重要事件或条件

前置条件

这是执行用例之前的检验，唯有在满足某些重要条件时，才会执行该用例，以确保用例可正确执行

后置条件

相对于前置条件，后置条件代表用例执行完毕时，可以通过后置条件自行检验是否执行成功

失败时状态

记录用例执行失败时的状态

业务规则

重要的业务规则或计算公式都要记录下来

相关文档->FULL

用例驱动，使用用例叙述作为系统开发文件的汇集点，由它链接到相关的文档。一旦业务流程或者需求 变化，可以通过用例快速定位一连串文档。
常见的相关文档：

用例叙述的历史版本

记录变更的过程，以及历史版本的具体用例叙述

UML图

该用例相关的业务用例图，活动图，系统用例图，状态图或顺序图等

参考画面

一般是参考界面

其他非UML文档

会议记录，表设计等等

其他事项->FUll

优先性

设定该用例开发的优先级

迭代等级

给用例标示出其细致度或迭代等级。

待解决问题

在分析与开发期间出现的 没有定论的问题

基本假设

如果该用例基于某个基本假设而设计出来的，记下这个重要的基本假设

相关人员

每一份用例叙述涉及集中不同身份的相关人员，包括制作者，阅读者，审核者等等。
在用例驱动的系统开发中，常常将一个用例当做一个工作单元，加上相关人员的签核之后，用例叙述文件就成了现成的工作票，可通过工作流工具来管理

特殊需求

跟该用例相关的非功能性需求等特殊需求，都记录在这个字段中

—

分析业务规则

为什么分析业务规则

企业通过一组业务规则(Buiness Rules)来控制整体的运作，包括人员、流程、系统、概念的运作，皆受制于业务规则

什么是业务规则

企业领域中任何一项必须遵守的规则。
* 条件(Conditions)
* 约束(Constraints)
* 政策(Policies)

一般业务规则分类

• 两大类

  • 约束规则(Constraints Rules)
  • 主要用来约束对象结构和行为
  • 衍生规则(Derivation Rules)
  • 主要推论约束或计算公式

• 细分

  • 约束规则(Constraints Rules)
  • 1. 刺激/反应规则(Stimulus/Response Rules)
  • 1. 操作规则(Operation Constraints Rules)
  • 1. 结构规则(Structure Constraints Rules)

  • 衍生规则(Derivation Rules)

  • 1. 推论规则(Inference Rules)
  • 1. 计算规则(Computation Rules)

刺激/反应规则->FULL

使用 状态图 分析及呈现刺激反应规则。 WHEN and IF条件成立时，对象就会有THEN的反应。
* 当(WHEN)某个重要的外界事件发生
* 而且(and)对象如果(IF)恰好处于某种状态下时
* (THEN)对象就会做出某种实现约定好的行为

操作规则->FULL

用来保证操作会正确执行。通常分为
* 操作前规则(Operation Precondition Rules)
* 操作后规则(Operation Postcondition Rules)

举例：

• 定期定额申购类提供了一项“自动申购”操作。只要(ONLY IF)在交易状态为正常扣款，且(and)扣款账户余额大于或等于交易金额(申购金额 + 手续费)的情况下，将执行“自动申购”这项操作，则自动申购的 操作前规则：

Execute 自动申购
ONLY IF 交易状态 = 正常扣款
  and 扣款账户的余额 >= (申购金额 + 手续费)

• 执行(Execute)”自动申购”操作 正确完成(IS CORRECTLY COMPLETED)之后,扣款账户最新余额只会是(ONLY IF) 先前的余额扣减交易金额(申购金额 + 手续费), 且(and)基金最新库存单位数只会是 先前的库存单位数 加上 本次申购单位数(申购金额 / 申购净值)，自动申购后的 操作后规则：

Execute 自动申购 IS CORRECTLY COMPLETED
ONLY IF 扣款账户最新余额 = 余额 - (申购金额 + 手续费)
  and 基金最新库存单位数 = 库存单位数 + (申购金额 / 申购净值)

结构规则 ->FULL

用来约束对象种类或关联关系必须永远遵守规则

举例：
任一笔申购交易只能发生在某一个基金账户底下，最多最少都只能链接到一个基金账户，而且这项结构规则在发生任何事件时、在执行任何操作前后，都必须遵守：

IT MUST ALWAYS HOLD THAT
任一笔申购交易只能发生于某一个基金账户底下

通常结构规则会记录在类图的多重性处

## 推论规则->FULL
指出某事实(Facts)为真(True)时，结论(Conclusion)可以被推论得出

举例：
投资人上网申购单笔基金，如果扣款不成功的话，单笔申购交易理所当然是不成立的

IF 扣款不成功
  THEN 单笔申购交易不成立

计算规则->FULL

就是一般所谓的计算公式

举例：

交易款项 IS COMPUTED AS FOLLOW
  申购金额 + 手续费
手续费 IS COMPUTED AS FOLLOW
  申购金额 * 基金管理费 * 银行折扣

---

PIM-2： 分析业务规则

业务规则散落四处，通过不同的UML图重新组织业务规则
* PIM-1的 系统用例叙述， 以系统流程为主，记录约束流程的业务规则
* PIM-2的 状态图， 以对象行为为主， 记录刺激对象反应的业务规则
* PIM-3的 类图， 以静态结构为主，记录约束对象种类或关联关系的业务规则

使用状态图

• 可以用状态图呈现某一种重要对象一生的行为
• 从对象诞生到灭亡期间，它会对那些时间(Event)有所反应
• 因而转换(Transition)其内在状态(State)
• 并且执行某些特定的动作(Action)
• 使用方法：
  
  • 对象执行两种执行动作的方式
  • 对象进入状态后，执行状态内部指定的动作
  • 对象在转换状态瞬间，执行一项不可中断的操作
    
    • 标注在事件后， 用 “/” 分离

关于动作

• 转换动作通常执行时间短暂，有不可中断的特质
• 状态动作通常执行时间长，而且可能因事件中断执行，转换到另一个状态
• 可用 “动作”(Action)表示不可中断的动作
  
  • 所以：转换上的动作称为 动作
• “活动(Activity)”表示可中断的动作

* 所以：状态内部的do动作称为 do活动

定义静态结构

从PIM-2的状态图中，分可以分析出定义 类内部的属性(Attributes)及操作(Operations). 而从PIM-4中的序列图，可以产生更多的操作以及操作的方法

定义静态结构好处

系统分析员可以通过类图，记录约束对象种类或关联关系的业务规则。在PIM-3中系统分析员通过类图来表达系统内部的静态结构。
* 系统具备稳定且具弹性的静态结构，才能顺应需求编程，迅速支撑多样化的系统用例
* 程序员通常会按照类图的内容，来编写并组织源代码

PIM-3过程

• 重要的业务概念会对影成业务对象，在PIM-3过程中，系统分析员会为业务对象建立类以及对象之间的静态关系。
• 业务人员在执行业务流程的过程中，会使用到许多重要的业务概念
• 系统在支持业务流程的运作的过程中，通常也会使用这些业务概念
• 所以，把重要且稳定的业务概念，作为系统内部核心的静态结构

类图主要

• 类与其间的关联关系是类图的基本组成元素
• 类内部记载对象的属性和可执行的操作
• 关联关系的两端标示出两端对象可以链接(Link)的多重性(Mulitiplicity)

---

定义操作及方法

PIM-4 定义操作及方法

• 在PIM-4中，系统分析员可以用序列图来表达：系统内部一群对象合力完成某一个系统用例时执行期间的交互情形。
• 同时，在序列图中，一群对象交互所引发的操作，可以反馈给类图，定义更多的操作及属性，甚至发现之前未发现的其他类的关系

序列图

序列图内有数个对象，执行者对象启动系统用例时，对象会遵照箭头方向传送消息(Message)给另一个对象，也因此而引发了接受消息之对象的某一项操作。数个对象之间，传送一连串消息并引发操作的的过程，形成一群对象的交互

其中序列图主要组成元素有：
* 对象
* 调用消息(Call Message)
* 执行规格(Execution Specification)
* 生命线(Lifeline)

调用消息

• 同步消息(Synchronous Message)
  
  • 发送对象 在发送 同步消息 之后，会等待 接收对象 执行完毕后才会接着传送下一个消息。
• 异步消息(Asynchronous Message)
  
  • 发送对象 在发送 异步消息 之后， 不等待 接收对象 执行完毕，就继续向下发送消息

创建消息 和 销毁消息

• 创建消息
  
  • 用来创建对象
• 销毁消息
  
  • 用来销毁对象

几项建议

• 主要流程与其他流程 分别置于 不同的序列图中。
  
  • 千万别在一张序列图里表达多条流程，避免造成图面过于复杂，难以阅读
• 扮演启动者的执行者对象 放置于 序列图最左方；扮演支持者的执行者对象 放置于 序列图的最右方
  
  • 消息方向尽量由左指向右，符合书写与阅读的习惯
• 自有消息可以引发接收对象自身的公开操作 或私有操作。
  
  • 一般消息只能引发公开操作，不能引发私有操作
  • 公开操作就是对外公开，其他对象都可以调用
  • 私有操作只有对象自身可以调用
• 对象之间优先通过静态关系传送消息，否则可于操作中建立暂时性的关系，以便传送消息

使用到对象本身属性或操作时：

• 不得直接提及对象的属性
• 不得假设对象的执行方法
• 仅能够使用对象的操作