《大象：thinking in uml 》(第二版) 9章获取需求 5-8节领域建模、提炼业务规则、获取非功能性需求、主要成果物

只供参考，喜欢请支持正版图书

9.5.2 现在行动：建立领域模型

建立领域模型首先要确定领域，才能为之建模。何为领域？所谓领域就是我们分析问题时将整体分解以后的相对独立的部分

在实际工作中，并不需要把问题完全分解成领域，也不需要为每个领域都建模，而只挑选那些对业务来说重要的、对过程来说核心的或者对系统来说复杂和困难的那些部分来建模。目的是在项目的初期就把对项目成败影响最为关键的那些部分搞清楚

建立领域模型，我们需经过提出领域问题、分析领域问题、建立领域模型和检验领域模型这些步骤

9.5.2.1 提出领域问题

从图9.18中我们看到，我们现在面临的问题领域是许多业务部门都对用户档案有着不同的业务要求。要对领域进行分析，首先就要了解关心该领域的所有可能的涉众是如何理解和要求该领域的。下面对这些问题进行描述，之后再来建立领域模型

■　业务服务部门，问题一
业务服务部门将负责建立基本用户档案，包括客户资料、用电情况基本资料等。如果客户要改变档案，必须通过业务服务部门办理相关变更业务。

■　用电检查部门，问题二
用电检查部门将根据客户的电气资料、用电情况基本资料安排检查计划，并记录检查结果，检查结果和检查过程中发现的问题、处理结果等都将归入用户档案。若用户发生违章用电或窃电行为，处理结果将影响用电业务的办理。如问题未解决不得增加用电容量。

■　资产管理部门，问题三
资产管理部门将根据用户档案和用电情况为其配备计量资产，制定资产管理计划和轮换计划。该资产在用户的使用过程中发生的维修、校调、丢失等情况将记入用户档案。由于资产计量不准确引起的计费误差将反映到电费管理部门给予修正。

■　电费管理部门，问题四
电费管理部门将根据用户档案中的用电情况和电气资料情况核定电价，并每月根据电表抄表部门所抄录的电表示数计算电费。一些特殊的费用，例如计量设备误差引起的计费不准，在核准后将进行差额计算。电费计算记录和收费记录将进入用户档案，以备查询之用。

■　电表抄表部门，问题五
电表抄表部门将根据用户档案中的用户地址、电表所搭接的变压器位置等信息编排抄表计划。若抄表过程中发生电表示数异常，例如长时间不转动或用电量突然大量增加，这些情况要反映到用户档案中，由用电检查部门负责调查。

■　现场施工部门，问题六
现场施工部门将根据用户基本资料确定如何为客户安装用电设备，安装结果将形成电气资料，归入用户档案。作为用电检查、电价核定以及将来维修等的依据。

■　财务管理部门，问题七
财务管理部门将根据用户的电费和欠费情况统计各类营业报表。同时欠费记录将记入用户档案。欠费将由业务服务部门负责追缴，未清欠之前业务服务部门不再为该用户办理其他业务。

9.5.2.2 分析领域问题

领域建模过程是一个提出问题和求解的过程。上面部分我们已经提出了问题，接下来就将进行求解过程

现在让我们回头看看图9.13低压用电申请业务用例场景的时序图，该业务用例场景的最终结果就是建立用户档案，从图中我们可以看到，申请单、现场勘察单、现场安装工作单、电表表底等业务对象构成了建立档案的基本条件，这些业务对象就是业务服务部门将建立和变更用户档案的依据；扩展开来，如果我们将所有业务服务部门的业务用例场景都遍历，并且寻找到所有与建立与修改用户档案相关的那些业务过程和业务对象，那么我们就会得到一组可以解决问题一的，即如何建立与修改用户档案的方程。

鉴于我们并不知道用户档案是什么，我们只知道用户档案的输入，我们可以假设说这些输入的结果形成了用户档案组成的一个部分，例如针对申请单这个输入，在用户档案中应当对应地也建立一个领域对象，我们可以给它取一个名字叫基本资料。由此我们说，经过低压用电申请业务用例场景的处理以后，申请单业务对象构成了用户档案中的一个组成部分：基本资料

9.5.2.3 建立领域模型

9.5.2.4 验证领域模型

与业务用例模型一样，领域模型也有静态模型和动态模型之分。为了验证我们得出的领域模型是不是正确，我们可以将得出的领域对象代入方程来检验，也就是将领域对象代入各个业务用例模型中，看它们是否能够满足业务要求。例如图9.23展示了将领域对象代入抄表部门编排抄表计划业务用例场景的结果。如果它能够很好地符合业务要求，则可以证明我们得出的领域模型是正确的

9.6 提炼业务规则

9.6.2 现在行动：提炼业务规则

业务规则对于一个系统来说其重要性不亚于业务需求本身。业务需求仅说明了人们希望一个系统能为他们做些什么，而业务规则则用来说明人们希望这个系统怎么做

我们可以将业务规则分为三类：全局规则、交互规则和内禀规则

9.6.2.1 全局规则

全局规则是指对于系统大部分业务或系统设计都起约束作用的那些规则。在这里，所谓全局是与用例相关的。我们知道，用例是带有原子性的相对独立的需求点，全局规则就是跨用例的规则

全局规则一般与所有用例都相关而不是与特定用例相关，举例来说，比如参与者要操作用例必须获得相应的授权，这条规则就是对所有用例都有效的；再比如用户在系统中的所有操作都要被记录下来，这一规则也是对所有的用例都有效的。这类规则就是全局规则。

全局规则的书写格式可以采用表格形式，每一条规则占据一行。最好为其编号，这样，在需要用到它们的时候直接引用编号就可以了。下面笔者给出一个简单的示例供读者参考，如表9-2所示。读者也可以自己定义全局规则的书写格式
■　编号。编号可以自行编制。在例子中采用“．”号来表示规则的版本，每次变更增加一个小数值。在需要引用全局规则的文档里，直接引用主编号即可。为减少文档维护量，可以不引用版本号，默认地将最大版本号的全局规则视为当前规则

9.6.2.2 交互规则

交互规则产生于用例场景当中。我们知道，用例场景是由活动图、交互图等来描述的，不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性的条件。这些条件就是交互规则

交互规则一般要写到用例规约中，因为它们是与特定的用例场景相关的，仅在该用例场景当中生效

交互规则当中有两个特殊的规则是UML专用的，一个是入口条件，也称为前置条件，即参与者必须满足什么条件后才能启动和执行用例；另一个是出口条件，也称为后置条件，即当用例结束后会产生哪些后果

9.6.2.3 内禀规则

内禀规则是指那些业务对象本身具备的，并且不因为外部的交互而变化的规则

例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。另一个例子是大家都很熟悉和常用的数据校验规则，例如身份证号必须是15或18位，邮编必须是6位等

9.6.2.4 分类业务规则的意义

9.6.3 进一步讨论

9.7 获取非功能性需求

9.7.2 现在行动：获取非功能性需求

非功能性需求主要是围绕下面几个方面展开的：

9.7.2.1 可靠性

可靠性包括安全性、事务性和稳定性三个方面
■　安全性
■　事务性
简言之，事务性就是保障系统的ACID能力，ACID分指四个属性
■　稳定性

9.7.2.2 可用性

可用性用来衡量人们使用一个软件产品的满意程度。一般来说，可以从以下几个方面去考虑：

■　容易学习
■　使用效率
■　记忆性
■　错误恢复
■　主观满意度
■　人员因素
■　美观
■　用户界面的一致性
■　联机帮助和环境相关帮助
■　向导和代理
■　用户手册和培训材料

9.7.2.3 有效性

有效性包括性能、可伸缩性、可扩展性这三个方面的话题
■　性能
■　可伸缩性
■　可扩展性

9.7.2.4 可移植性

9.7.3 进一步讨论

9.7.3.1 第一个讨论：如何采集非功能性需求

9.7.3.2 第二个讨论：如何记录非功能性需求

9.8 主要成果物

■　定义边界
■　发现主角
■　获取业务用例
■　业务建模
■　领域建模
■　提炼业务规则
■　获取非功能性需求

只供参考，喜欢请支持正版图书