Thinking In UML 读书笔记（二）获取需求

定义边界

以边界外的业务目标定义系统边界，就是将系统看成一个整体，暂时忽略系统内的业务期望。
采用业务模块的缺点就是模块之间的耦合可能比较复杂，不利于提炼清晰的需求。

第一步讨论

第一个讨论

从业务目标得出的边界是有明确的理由的，在边界内可以得出的用力也是有明确的依据的。
假设一个涉众的工作职责有10个，而其中5个是与业务目标相关的，则系统边界内只容纳这5个，其他的还是要依靠涉众自己执行。

第二个讨论

从业务目标的角度划分边界，可以得到一个明确的目标，将与目标有关的用例放在边界内，这样可以让业务需求更清晰。
要在业务目标的基础上划分边界，在边界的基础上获取用例。

第三个讨论

不是所有的系统都有业务目标。
如果系统是以计算、控制、自动化为目的的，就很难找到业务目标，但这些系统有明确的功能目标（对于这一点，我表示有异议，很多情况下甲方很难提出明确的功能目标），可以利用功能目标划分系统边界。边界一旦定义，则在边界外与改边界有利益关系的一切东西，无论他是人还是物还是系统，都是业务主角，主角对系统提出期望，就是业务用例。

发现主角

一个涉众可以衍生出多个主角。
涉众直接与系统边界发生了交互，则才能成为主角。

获取业务用例

每一个主角对系统的期望都是系统的业务用例，可以通过查找业务手册，岗位说明，涉众分析，涉众访谈等形式获取到。
业务用例是比较高层次的业务抽象。
目前比较流行的项目估算方法是工作分解结构WBS，而业务用例就可以作为工作分解的起点。将业务用例分解成小的，易于估算的工作包。小的项目分成的工作包为一个人一周的工作量，大的可以分解成一个人两周的工作量。工作包的估算可以是经验、Delphi法，LOC法。

业务建模

一个完整的业务模型包括：
+ 业务用例视图
+ 业务用例场景
+ 业务用例规约
+ 业务规则
+ 业务对象模型
+ 业务用例实现视图
+ 业务用例实现场景
+ 包图

业务用例场景

描述该业务在实际过程中是如何做的，潘老师的书上主要是利用顺序图，我也觉得顺序图适用于大部分的情况。

业务用例规约

将用例进行文字描述，包含用例名称、用例描述、执行者、前置条件、后置条件、主过程描述、分支过程描述、异常过程描述、业务规则、涉及的业务实体、涉及的业务实体。

个人感觉潘老师的《软件方法（上）》对这部分介绍的更具有参考性。

业务对象模型

业务对象模型是对业务用例中涉及的业务实体进行建模。可以利用用例图进行表示，将用例进行细化。

业务用例实现场景

业务用例实现场景说明业务执行是如何实现的，是对业务用例场景的补充。

包图

在本部分，包图主要用于信息分类。

领域建模

1. 
   
2. 假设领域是一个方程类似的东西，则先提取出所有的变量。
3. 遍历所有场景，探寻不同变量之间的互相影响关系，最终绘制出领域模型静态图。（可以用顺序图表示）
4. 验证领域模型
   

感觉书中这部分的组织不如《软件方法》讲得透彻。

提炼业务规则

全局规则

安全性要求等规则，对大部分业务都适用的规则。

交互规则

交互过程中所涉及的限制性条件的规则，如表单中哪些是必须填写的。

内禀规则

对象本身具备的，不因为外部交互而变化的规则。如身份证号是15或者18位。

获取非功能性需求

主要是指可靠性、可用性、有效性（性能、可伸缩性、可扩展性）、可移植性。