软件方法（上）读书笔记 业务建模与需求

软件方法（上）读书笔记
原著作者：潘加宇

车厂女工的课外读物

为什么要建模？如果想要完成一个优秀、规范的系统，就要在一开始采取规范的建模方法。不要以为自己的系统是小系统，或者觉得自己的系统很特别（比如重构系统、内部系统...）就放弃建模。原著金句：“见识少的病人总以为自己得了怪病，其实到医院让医生一看，太普通了”

建模工作流

业务建模 and 需求 =>需求
分析 and 设计 =>设计

建模工作流的工具——UML

UML可以当作一种基本共识，like五线谱、源代码，不应该只存在于某个人的描述或理解中，而应该作为一种规范、共识体现在模型中（原著金句：“这种做法的本质是想通过形式上的丑陋来掩盖内容上的丑陋”）

敏捷方法论虽然淡化了需求文档的必要性，但是如果是“有口号无方法”，可能会导致比“无口号无方法”更糟糕的结果。

愿景（Vision）

愿景是需求排序的主要依据。愿景=系统最应该卖给谁？系统带来了什么好处？以下是愿景定义的

1. 定位目标组织和老大。系统将为谁带来好处？谁就是目标系统。老大是目标系统的代表，一定要让他满意!!!
2. 提炼改进目标。目标并不是功能需求，“提高xxx转化率”是目标，“提供xxxx功能”是需求。目标也不是质量需求，“缩短响应周期”是目标，“响应速度2s内”是质量需求。定位目标可以用鱼骨图或者UML的类图
   (下图是第一次用ea系统画的愿景图，红圈圈出的是需要用到的工具)
   
   
   

业务建模之业务用例图

愿景让我们明白了老大对哪些指标不满意，我们仍需知道是哪些环节导致了这些不理想的现状。业务建模的目的——得到需求。
"业务"通常指向核心域知识，或组织级别的知识。

一、认清现实。

1. 软件是组织的一个零件，就像公司的马桶，没有这个马桶大家照样有办法带薪拉屎，没有某个系统，公司的业务仍有办法正常运作。因此软件应该关注怎样解决核心问题，更好地提供服务。
2. “需求变化多”是因为没有进行正确的业务建模，而得出的假需求，真正的需求是没有变的。

二、识别业务执行者

1. 业务执行者：组织之外和组织交互的人或机构。
2. 业务工人：组织内的打工人。
3. 业务实体：“我在开发一个新系统”=“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”

三、识别业务用例

1. 业务用例：业务执行者希望通过和 组织 交互 获得的价值。例如，用户去银行包含的业务用例存款、取款、转账、理财等等…
2. 业务流程：业务用例的实现过程。业务用例代表了一个组织的本质价值，一般不变，需要优化改变的是业务流程。
3. 识别业务用例的思路：

• 业务执行者开始，挖掘业务执行者和组织交互的目的。
• 观察组织内部活动，向外推导组织外部的业务执行者。

业务建模之业务用例图

序列图是描述业务流程的一种手段，除此之外还有文本、活动图

用文本描述业务流程:
文本虽然不生动，但也很常用，因为更加精确，而且可以描述业务规则、性能等无法用UML表述的内容。

用活动图描述业务流程:

用序列图描述业务流程:

活动图和序列图都是UML描述业务流程的办法，它们之间相较而言：

• 活动图关注人，序列图把人当系统。由于现在的业务流程中很多逻辑封装在业务实体中，而不是业务工人，若只关注人，可能会遗漏一些信息。
• 活动图关注动作，序列图关注动作背后的目的。
• 活动图灵活。可以指向任何地方。
  

业务序列图要点:

一、消息代表责任分配，not数据流动

序列图最重要的是消息的含义。A指向B的消息=A请求B做某事，也就是说这个消息是B要做的事情，相当于一个输入输出的参数。

二、抽象级别是系统之间的协作

牢记：业务建模的对象是组织，序列图各条线上的对象最小颗粒度是系统(人或者非人系统)。不要随便加一些乱七八糟的东西。

1. 易错点一：
   把“客户表”这个系统的组件当作对象。

• 易错点二：
  抽象级别跳跃。销售支持呵使用CRM系统记录客户资料，只需要一条消息“记录客户资料”就够了。像图中这样记录的过于细节，其实是把需求和分析的工作流带入了业务建模。

• 易错点三：
  不要把不具备智能的物品放在生命线上。比如“申请单”“报销单”这种东西，生命线上的东西都是人或者非人的系统。

三、只关注核心域的系统

核心域相关的系统应当出现在序列图中，非核心域的系统可以不画。比如一个业务工人输出一份文档，需不需要把Word、微信等系统画进去呢？当然不！

四、把时间看作特殊的业务实体

五、为业务对象分配合适的责任

现状业务序列图:

亲临现场，把目标组织正在进行的业务流程绘制出来，就是现状业务序列图。
此处一定要尊重现状，保证真实，“存在即合理”，要深入观察访谈，了解目前的业务流程合理性，再去思考如何着手改变。

改进业务序列图:

基于现状，我们下一步应该思考系统能如何改进现状。以下是几种改进模式：

• 改进模式一：物流变成信息流。比如下图，不仅解决了报纸的流动，也解决的人的流动。要注意人也是一个非常重的物。

• 改进模式二：改善信息流转。一个人为了达到某个目的可能需要使用多个系统，如果把各个系统的协调工作集成到一个系统上完成，会减少很多麻烦。
• 改进模式三：封装领域逻辑。提炼人脑的逻辑，封装到系统中，可以避免人的成本高、状态不稳定、徇私舞弊行为。
• 目前许多新兴的应用软件大多是使用了改进一、改进二，改进三在未来占的比重会越来越大。

阿布思考法：

阿布代指俄罗斯大富翁Roman Abramovich，源于书籍
why not?:how to use everyday ingenuity to solve problems big and small。许多改善人类生活的创新，都是用廉价的方法复制富豪们的生活体验。阿布思考法分为两步：

1. 假设资源充足，制定一个完美方案
2. 用手上现有资源去山寨这个完美方案

需求之系统用例图

业务建模focus on组织，需求focus on具体的系统。
系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值

一、系统执行者：对象系统之外，与该系统发生功能性交互的其他系统。

• 系统是能独立对外提供服务的整体。
• 系统边界是责任的边界
• 系统执行者和系统有交互。比如旅客去火车站买票，售票员使用售票系统出票，那么售票系统的执行者是售票员而非旅客，旅客是涉众（用例必须在它的路径、步骤、补充约束中考虑涉众的利益，执行者是台上的演员，涉众是观众）。而如果在出票过程中需要旅客有意识的按某些键，旅客就成为了这个系统的（辅）执行者。
• 交互是功能性交互。比如售票员使用售票系统，需要鼠标、操作系统，但这些东西不是需求。
• 系统执行者可以是人或者非人类

业务序列图要点:

• 价值是买卖的平衡点

• 认清系统的价值，能够提供什么样的服务让用户买单。
  系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。
  “储户→登录"不是用例，因为储户期望ATM提供的服务并不是登录这么简单，“储户→取钱"“储户→查余额"“储户→存钱"才是用例。

• 价值≠“可以这样做”
  一个办公系统，科员有两个用例，比科员级别高的还有科长、处长，这些人当然也可以使用这些功能，但是在用例图中，并不需要体现领导和这两个用例的关系，只需要体现领导专用的几个用例。
  用例执行者是表明用例是为了这一类执行者而做的，并不代表权限控制。

• "增删改查用例"的根源是从设计映射需求(这是错误的)
  
  

• “复用”用例也是从设计映射需求（这也是错的）
  用例是涉众愿意购买的，虽然在开发者看来都是查询一个数据表，但是对涉众来说目的却不同，所以不能复用。
  

• 系统用例不存在层次问题

• 用例的命名是动宾结构

识别系统用例:

如果前期业务建模的工作做好了，那么业务序列图中，从外部指向系统的消息，可以直接映射为系统用例

从执行者指向用例的叫做用例的主执行者，主动发起与用例的交互，用例指向执行者的叫做用例的辅执行者，交互过程中被动参与进来。

需求之系统用例规约

用例规约是以用例为核心来组织需求内容的需求规约，可以表达用例背后封装的不同级别的需求。

下图中的执行者、用例相关内容都可以从用例图照搬。

前置条件和后置条件

用例通过前置条件和后置条件，以契约的形式表达需求。

系统用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径走，系统就能达到后置条件。

前、后置条件必须是系统能检测的（如：顾客带着孩子进入商店，不能作为前置条件）

前置条件必须是用例开始前系统能检测的（如：确认顾客携带足够现金，不能作为前置条件）

前、后置条件是状态，不是动作；要用核心域词汇描述，不要用“系统运行正常”等非常笼统的词汇描述 

“已登录”不能作为前置条件。比如：会员登陆以后可以下单，也可以查看订单，如果画成这样就会变成，用户以下单的方式登录，意思就错了，这里要注意extend的用法。正确的做法是include。

如上图所示，登陆用例本来不存在，但是在写用例规约时，发现“下单”和“查看以往订单”都有步骤“提交身份信息”“验证身份信息”“保存会员登录信息”，为了少些一点用例规约，可以把这些步骤集合起来，作为一个用例单独写规约。这个用例只被其它用例包含，不由执行者指向。这样的话，“下单”的用例规约的步骤里，就会包含“登录”的步骤集合。我们可以用【登录】表示这是一个被包含用例。

涉众利益

如果只考虑目标，而不考虑涉众利益，就得不到正确的需求。
当我想要100万现金，我可以“去 骗！去 偷袭！”别人家的塞满了钱的床底，或者“去 骗！去 偷袭！”别人的银行卡，结果我发现，银行卡还要去ATM插卡取钱，要被监控，还要输密码。
背后的原因是涉众利益不同，家里的床底，一般都是亲人才会看到，我不需要加密。而银行的客户会担心钱被盗取，银行负责人也并不想因此负责，所以需要加密。
需求就是涉众利益的冲突和平衡来决定的，比如银行的六位密码就是在安全和方便的平衡之下决定的。

识别涉众

之前有提到，用例的执行者是台上的演员，涉众是台下的观众。为了寻找涉众，我们可以假设台上的演员突然发疯说了一些会被和谐的台词，台下的哪些观众最担心？就是这个用例的涉众。

• 涉众来源一：人类执行者
• 涉众来源二：上游
  执行者使用系统做某个用例，可能会需要一些资源，资源提供者很可能是此用例的涉众。比如：保安帮我办门禁卡，门禁卡申请表是我提供的，我是涉众。
• 涉众来源三：下游
  一个用例执行后会影响到的人，也可能是涉众。保安帮我办门禁卡，如果没给我开IT楼的权限，IT楼的门卫就得帮我开门了。
• 涉众来源四：信息的主人
  保安帮我开门禁卡，需要高级经理签字并且写上工号，高级经理就是涉众。

基本路径

把用例的场景描述出来，就得到了用例的路径和步骤。
一个用例会有多个场景，其中一个场景描述了最成功的一种情况，一路畅通直到后置条件达成，这个叫做基本路径。
比如办门禁卡：
（1）我填写申请表、给领导签字、保安帮我开卡，真顺畅！
（2）我填写申请表，性别填错了，被拒绝…
（3）我填写申请表，领导说：你怎么天天丢卡！别让我看见你！
以上场景只有（1）是我想要的，虽然2、3也可能出现，但是1才是我的期望😏

书写路径步骤的要点

• 按照交互四部曲书写
  执行者和系统按照回合交互，可能需要多个回合。但是一个回合基本分为四个步骤：请求、验证、改变、回应。请求是必备的，其他三个至少有一个。
  需要注意：
  （一）时间为主执行者的用例
  当到达时间周期时 --------------------请求
  系统根据比例计算评分---------------改变
  （二）验证步骤不要写“是否”，直接写通过的条件
  （三）系统和辅执行者之间的交互可以看作一种回应步骤，写成系统请求辅执行者做某事。
• 只写系统能感知和承诺的内容
  例如系统显示应收金额，“顾客付款”“收银员找零”这样的步骤就不能写，一旦写了，就会潜意识地认为这两个步骤一定会发生，其实顾客忘记付款和收银员忘记找零正是系统要解决的一个问题。
• 用主动语句理清责任
  比如：会员保存订单-------------------×
  会员提交订单信息----------------------√
  系统保存订单----------------------------√
  再比如：会员查询订单-----------------×
  会员提交查询条件-----------------------√
  系统查询商品-----------------------------√
  系统反馈查询结果-----------------------√
• 主语只能是主执行者或者系统
  如果出现“系统请求xxx”"客户端请求xxx"这样的就不对
• 使用核心域术语描述
  系统建立连接，打开连接，执行SQL语句，-----------------×
  会员提交查询条件-----------------------√
• 不需要涉及界面细节
  系统显示列表→系统反馈信息
  会员把商品加入购物车，选择优惠券，单击结算→会员输入商品和优惠券信息，请求结算
  • 不需要涉及交互细节
  • 需求=“不这样不行”
    如果你问，界面这样设计行吗？得到的回答很可能是"行啊！反正我也不懂"，但如果问“界面不这样可以吗？”可能就会得到“不可以！这是领导要求的”。

扩展路径

基本路径的每个步骤都有可能发生意外，处理意外的路径就是扩展路径。扩展路径标号的方法，2a表示步骤2的第a条路径；扩展路径也有自己的步骤，比如2a1、2a2。

常见的扩展路径，比如验证不通过的时候，或者和辅执行者交互的时候，会出现。要注意
（一）能感知&要处理的意外才是扩展
（二）设计技能不足导致的错误不是扩展
（三）不引起交互行为变化的选择不是扩展
（四）界面跳转不是扩展

补充约束

路径步骤里描述的需求时不完整的，比如：员工输入个人信息（个人信息包括哪些内容？需要字段列表）系统验证信息充分（充分指什么？需要业务规则）以及整个流程需要多久结束？（需要质量需求）
补充约束如果是针对某个步骤，就在前面写上步骤的编号；如果是不针对单一步骤，前面的编号用*。

• 字段列表的表述方法：
  个人信息包括：姓名 工号 照片
  个人信息=姓名＋工号＋照片+（座机可填可不填 ）+{联系地址可能有多个 }
  员工状态=[工作ing|休假|离职]

• 业务规则的表述方法：
  例如：步骤 3.验证个人信息充分
  业务规则 3.必须包括姓名、工号

• 质量需求的表述方法：
  可用性（5次操作以内能完成审批）
  性能（标准工作负荷下，CPU占用率少于50%）
  可靠性（平均修复时间<5min）
  可支持性（系统升级和修复的能力，比如升级时保存用户个人设置）

  设计约束

  设计约束也是一种需求，但不是功能或质量需求。比如：“用Oracle数据库保存数据”，凭什么？哦原来是客户已经采购了，不用很浪费，增加成本。
  我们要避免一些假的设计约束。比如：注册页面分三个，一个页面写完单击下一步，去下一个页面。如果追问，为什么要分三个？哦原来是因为，性能需求，要求系统3秒内显示页面。需求是问题，设计是解决方案，以前网速慢，为了快点显示，只能分三个页面。现在网速快了，完全就不需要这样了。但3秒内显示页面的需求没有变，只是设计变了。