何伟潮的《软件方法》读书笔记（用其他工具把书里的图画了一遍）（1-3）系统用例图

用户6288414

发布于 2020-07-14 15:33:30

6660

发布于 2020-07-14 15:33:30

文章被收录于专栏：软件方法软件方法

以下是何伟潮的读书笔记，难得的是，他用其他工具把书中的图自己画了一遍。

1、建模

1.1、业务建模之愿景

重点1：通俗一点讲，一个东西的愿景就是：东西最应该卖个谁，对他有什么好处？

重点2：愿景是需求排序的主要依据。

重点3：老大、愿景、需求都是基于现状寻找最值得的改进。改进过后，又是新的现状了，还是基于现状寻找最值得的改进。进一步说也可以说，需求只有真假对错，没有变化。说需求有变化，那是从一个静止时间点来看的。

1.1.1、愿景

1.2、业务建模之业务用例图

有了愿景，我们知道老大对他所代表的组织的现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模（Business modeling）的主要内容。

重点1：软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统。

重点2：开发团队发现需求“容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的系统需求是错的。

1.2.1、业务角色

① 业务执行者

以某组织为研究对象，在组织之外和组织交互的其他组织（人群或机构）就是该组织的执行者。以一家商业银行为研究对象，观察在它边界之外和它打交道的人群或机构，可以看到储户来存钱，企业来贷款，人民银行要它作监督等等，这些就是该商业银行的执行者，如下图所示：

这里要注意的是，作为观察者的建模人员本身是一个人脑系统，所以在观察组织边界时，直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互，但是一定要把它理解成组织间的交互，因为谈论业务执行者时，研究对象是组织，所以外部对应物——业务执行者也应该是组织。例如：以某国税局为研究对象，可以观察到企业财务人员到国税局报税，但业务执行者不是企业财务人员，而是企业。也许到后来，企业财务人员和国税系统交互，又或许再后来是企业系统与国税系统交互，从组织的抽象级别来看，都应该理解为企业和国税局这两个机构之间的交互，如下图所示：

② 业务工人

组织内的人称为业务工人，例如某商业银行里面的营业员。业务工人是可以被替换的人脑零件，它可能被其他业务工人替换，但更有可能被业务实体替换。

③ 业务实体

业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统。

1.2.2、识别业务用例

重点1：业务用例指业务执行者希望通过和所研究组织交互获得的价值。业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消失而改变，好比如300年前的商业银行和当前的银行的业务用例是不变的，因为银行提供价值的本质没有改变。所以“这个系统的业务用例是什么”这样的说法是错误的。

重点2：用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点、买卖的平衡点。例如以“医院”为研究对象，真正的用例是“患者→看病”，而不是“患者→挂号”，患者→挂号”可以是以“挂号室”为研究对象的业务用例（如下图）。所以做任何事情之前，要搞清楚“边界”，没有边界会很容易盲目“拍脑袋”做一些努力但没效果的事情。

1.2.2.1、识别业务用例思路

识别业务用例的思路有两条：

【从外到内】从业务执行者开始考虑，思考业务执行者和组织交互的目的（主要）；

【从内到外】通过观察组织的内部活动，一直问为什么，向外推导出组织外部的某个业务执行者（补漏）。

1.2.2.1.1、识别业务用例常犯错误

错误1 ：把业务工人的行为当做业务用例。

错误2：业务用例随待引入系统伸缩。

错误3：把害怕遗漏掉的扩展路径片段提升为业务用例。

错误4：管理型业务用例。

总结：错误的根源主要源于：建模人员分不清问题和问题的解决方案。

1.3、业务建模之业务序列图

1.3.1、描述业务流程的手段

本章节主要讨论的是业务建模中最繁重的工作——描述业务用例的实现，即业务流程，然后改进它，推导出待引入系统的用例。目前描述业务流程的可选择手段有文本、活动图和序列图，它们的主要区别如下（以财务部“员工→报销”用例的实现为样例）：

● 文本

文本的缺点是不够生动，所以在描述业务流程时很少使用文本方式。不过，描述系统用例（即系统需求）的流程时，文本是常用的，因为此时更注重精确，而且还要表达业务规则、性能等目前尚未被UML标准覆盖的内容。

● 活动图

活动图的前身是流程图，应该是在建模人员中使用频率最高的图形，是随机械工程领域慢慢引入到计算机领域。不过，随着编程语言表达能力越来越强，针对简单的分支或循环逻辑画图在很多情况下已经变得没有必要。

● 序列图

序列图与活动图的比较如下：

1）活动图只关注人，序列图把人当作系统；

在上一章节中已经提到，现在的业务流程中已经有很多领域逻辑是封装在业务实体而不是业务工人中，如果忽略非人智能系统，很多重要信息就丢掉了。

2）活动图表示动作，序列图强迫思考动作背后的目的；

序列图可以更加清晰地表述业务工人或业务实体对外的责任，也就是用例的期望值。期望和承诺是用例和对象技术的关键思想，使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地惯窃业务建模和系统建模的始终。

3）活动图“灵活”，序列图“不灵活”；

不少人认为活动图胜过序列图的地方是它灵活，但这灵活是一把双刃剑。活动图很灵活，他的控制箭头可以指向任何地方，就像编码原始时代的“goto”语句，所以活动图很容易画。不过，“很容易画”的活动图也比较容易掩盖建模人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图可通过alt、loop等结构化控制片段来描述业务流程，强迫建模人员用这种方式思考。

1.3.2、业务序列图要点

1.3.2.1、消息代表责任分配而不是数据流动

序列图中最重要的要点是消息的含义。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，而“做某事”是B的一个责任。

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

业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统，包括人和非人系统，而系统之间最主要突出的是协作。所以“系统粒度”和“协作”是业务序列图的关键要点，如果记住了这两个关键点，就可以避免了对组织对象抽象的错误以及对协作理解的错误。

以上说的两种错误是把需求和分析的工作流的工作带入了业务建模。第一样例图提到的系统内部的组件，应该在分析和设计工作流中描述；第二样例图提到了交互步骤，应该在需求工作流中描述。除了以上两种抽象级别的错误，还有一种是：业务序列图的内容和业务用例图差不多，如下所示：

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

业务序列图中，我们把时间看作特殊的业务实体。把时间看作上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息，这样，就和后面需要工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。

值得注意的一点是，时间和定时器不是一个概念，时间是“外系统”，定时器是其他系统用来和时间打交道的“边界类”。世界上只有一个时间系统，但有无数的定时器。如果建模人员在识别系统用例时说“执行者是定时器”，那就错了，执行者是时间。

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

分配给业务对象的责任必须是该对象有能力承担的，这需要我们自身必须对理解要十分清晰，毕竟我们自己说话有时候的会含糊。例如“工作人员用Word写标书”这样的说法好像可以接受，但如果按照说话的文字不假思索地随便画，会很容易导致对象责任分配不准确。

1.3.3、现状业务序列图

业务序列图描述的是业务流程，建模需要通过在现状的业务序列图基础上找出改进的要点。如果要把现状序列图画出来，就必须让自己站在客观的角度“亲临现场”，“如实”地把所看到的记录下来，尽力描绘出真实的现状。但说起来非常简单，做到却极其困难。总结到这里，忽然让我想起了彼得·德鲁克。下面列出一些描述现状时经常犯的错误。

1）错误：把想象中的改进当成现状

很多时候造成这种错误，背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识，只好想像一个改进后的场景来应付。

2）错误：把“现状”误解为“纯手工”

有的建模人员以为人做的事情才是本质，所以他画的业务流程中，只有人，没有非人系统，完全忽略了在技术进步下慢慢可以替代人的这些“业务实体”。

3）错误：把“现状”误解为“本开发团队未参与之前”

开发团队很容易会误以为当他们开始参与组织流程完善而开发系统的时候当作“现状”，这就是典型的“技术思维”，很多时候在开发团队在参与组织流程完善前，组织已经经过了许多次“非系统级”的流程改进，这是站在组织角度去看问题的。

4）错误：把“现状”误解为“规范”

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的，毕竟上有政策，下有对策。

5）错误：“我是创新，没有现状”

互联网创业公司的建模人员很容易犯的这个错误，动不动就说“我做的是互联网创新，没有现状”，但他们已经忘记了历史上所有的创新都是站在前辈这些巨人的肩膀之上这个事实。

6）错误：“我做产品，没有现状”

非定制系统的开发团队进程拿这句话做接口。A公司的流程和B公司的流程有差异，中国的流程和外国的流程有差异，画谁的现状好的？问这个问题的时候，我想是开始开发团队忘记了“做需求时把产品当项目做”的道理，在第2章节中也提到过“谁比谁更像”的重点。

1.3.4、改进业务序列图

上面提到的现状业务序列图是对组织现状的客观描述，而改进业务序列图是通过信息化手段去思考对业务现状序列图的一些改进。通常，信息化给人类的工作和生活带来的改进有三种模式。

1.3.4.1、改进模式一：物流变成信息流

和信息的光电运输比起来，用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息，在需要发生物流的地方，改为通过软件系统交互信息，需要物的时候再将信息变成物，这样就可以大大增加流转速度和降低流转成本。

1.3.4.2、改进模式二：改善信息流转

软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为一个软件系统来完成，人只需要和单个软件系统打交道，信息的流转就改进了。

1.3.4.3、改进模式三：封装领域逻辑

在业务流程中，有很多步骤是由人脑来判断和计算的，领域逻辑封装在人脑中。相对于计算机，人脑（业务人才）存在成本高，状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。换句话说，领域逻辑的封装是对系统“内在”价值的提升，相对于前两个改进模式有更高的要求和更大的困难。

1.3.4.4、改进思考方式：阿布思考法

在软件开发团队中，当有人提出新的想法时，经常会被马上否定“太难了，做不了”，最终得到一个平庸的、毫无竞争力的系统。学会像阿布（俄罗斯大富豪罗曼·阿布拉莫维奇）一样思考，有助于克服普通人因资源受限而不敢展开想象的思维障碍。阿布思考法分两步：

1）假设有充足的资源去解决问题，得到一个完美的方案；

2）用手上现有的资源去山寨这个完美的方案。

其实，阿布思考法的核心思想就是，不要闭门造车，要“接地气”的行动起来，主动去观察，或主动寻找有用的信息去分析和调研，不要被各种局限被迫让步。

2、需求

2.1、需求之系统用例图

在“建模”阶段我们研究和思考的对象是组织，从组织的整体性客观地去发现组织如何可以通过信息化手段去优化流程。有了客观的整体性分析和改进认知，接下来的“需求”阶段需要深入到系统层面去思考了。按正常逻辑，每一步都有“承上启下”的作用，本章节所研究的系统用例就是通过上一步业务序列图中所映射出来的。

执行者和用例的概念在业务建模的学习中已经出现过，现在要研究的执行者和用例与业务建模时研究的执行者和用例相比，不同之处是研究对象，之前研究的是组织，现在研究的是系统。

2.1.1、系统执行者要点

系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统。

2.1.1.1、系统是能独立对外提供服务的整体

封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。不了解这点，建模人员很容易把“添加一些功能”当作“研发新系统”。

2.1.1.2、系统边界是责任的边界

系统执行者不是所研究系统的一部分，是该系统边界外的另一个系统。这里的系统边界不是物理的边界，而是责任的边界。

2.1.1.3、系统执行者和系统有交互

外系统必须和系统有交互，否则不能算是系统的执行者。如一名旅客来到火车站售票窗口，告诉售票员目的地和车次，售票员使用售票系统帮助旅客购买火车票，这个场景中，和火车票系统交互的是售票员，他是售票系统的执行者。

如果火车售票系统现在已经提供了旅客自行购票的接口，例如互联网购票、售票机等，这种情况下，旅客也是售票系统的执行者。不过“售票员→售票”和“旅客→购票”是两个不同的用例。

2.1.1.4、交互是功能性交互

上面说的交互还引出一个问题：假设售票员使用鼠标和售票系统交互，按道理，比起销售员，鼠标里售票系统更近，为什么不把鼠标作为售票系统的执行者呢？还有，假设售票系统运行在Windows操作系统之上，那么Windows是不是售票系统的执行者？其实吧，辨别这些问题的要点就是：执行者和系统发生的交互是系统的功能需求。鼠标和操作系统跟售票系统的交互都不是售票系统的核心域概念。售票员和售票系统之间的交互才是，所以售票员才是售票系统的执行者。

2.1.1.5、系统执行者可以是人或非人系统

系统执行者可以是一个人脑系统，也可以是一个非人智能系统，甚至是一个特别的系统——时间。在软件业的早期，一个系统的执行者往往全部都是人。随着时间的推移，系统的执行者中非人执行者所占的比例越来越多。用例的优势在于“执行者”和“涉众”的概念，把演员和观众分开。演员（执行者）在台上表演，观众（涉众）在台下看，演员表演什么是由观众的口味决定的，演员可以不是人，但观众肯定是人。演员如果是人类，那么在观众席上也会有一个位置，不过在第几排就不知道了（权重等级）。用例使用“执行者”和“涉众”代替了原来的“用户”是一个非常大的突破，建模人员如果过多地关注“用户”，混淆了真正真正重要的前排“涉众”的需求，把操作人员当前重要的调研对象（非关键人员），那么花在重要的前排涉众（关键人）身上的时间可能就不够了。越来越多的系统执行者不是人类，也就是说没有“用户”。

2.1.1、识别系统执行者

2.1.2.1、从业务序列图映射系统执行者

如果没有做业务建模，识别系统执行者只能靠头脑风暴。例如：什么人会使用系统来工作？什么人负责维护系统？系统需要和哪些其他智能系统交互？有没有定时引发的事件？等等问题。有了业务建模，可以直接从业务序列图映射即可。业务序列图上，和所研究系统有实线相连的对象映射为所研究系统的执行者。

2.1.3、系统用例要点

2.1.3.1、价值的买卖的平衡点

系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。和业务用例相比，研究对象从组织变成了系统，要理解好系统用例，重点依然是之前所强调的买卖平衡点、期望和承诺平衡点。

用例之前的许多需求方法学，把需求定义为思考系统“做什么”，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。要得到这个答案，不能靠拍脑袋，必须揣摩涉众。要得到合适的用例，需要有一颗善于体察他人的心。

2.1.3.2、价值不等于可以这样做

有些人会较真，还是以ATM为例子，有些人会因为“难道ATM放在那里我就不能登录一下就离开吗？我今晚下班就去ATM那里登录一下给你看，然后走人。”ATM确实能登录，但登录功能并非ATM的卖点，如果以一个“门禁系统”为研究对象，登录就可以作为它的用例。

还有一种情况，例如科员可以有A和B用例，科长因为比科员的权力大，所以就能拥有科员的用例。用例的执行者只是表明这个用例是为这一类执行者而做的。但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。即时系统确实需要有权限控制，而且角色的划分和执行者相近，也要把这两者分开，更不可以因为系统不设权限控制，所以把执行者的名字合并为“用户”。

有些书中会给出“最佳粒度原则”。例如：一个系统的用例最好控制在XXX个之内，一个用例的基本路径最好控制在X步到X步之间……这些是没有根据的。市场需要各种各样的系统，有功能众多的，也有功能单一的，也有交付复杂的，应该把屁股坐到涉众那边去，揣摩涉众的心里，实事求是地写下来。如果建模人员在粒度问题上激烈争吵以及纠缠不清，有可能已经犯了错误，最常犯的错误是把步骤当作用例。

2.1.3.3、增删改查用例的根源是从设计映射需求

有一些用例图，映入眼帘的用例是四个四个一组的，仔细一看，刚好对应看数据库的四种操作。相当于把数据库的各个表名加上新增、删除、修改、查询，就得到了用例的名字。有些建模人员确实也知道这个错误，但他们学乖了，干脆把每四个用例合并，改名叫“管理XX”或（“XX管理”），然后新增、删除、修改、查询等用例再扩展它，可惜依然是换汤不换药。

2.1.3.4、从设计映射需求错误二：“复用”用例

增删改查用例实际上就是从设计映射需求，导致“复用”用例的一种情况。在看看以下例子：

从不同的业务序列图分别映射得到系统有右边四个用例，但有的建模人员会动起心思：这些实现起来不都是针对“缺陷”表来“select X X X from缺陷表where X X X”吗，合并成一个用例“查询缺陷”多好！于是得到左边的结果。实际上，右边这四个用例面对的执行者不同，背后的涉众利益也有差别。

当然，如果真的像这位建模人员讲的，把“数据库”，买回去就好，想怎么折腾这信息都可以那不是更加简单。其实，用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然越多越好。讲到这里，就要来说一个需求的基本要点：需求不考虑“复用”，如果考虑“复用”，要警惕自己是不是已经转换到了设计视角来思考问题。

2.1.3.5、系统用例不存在层次问题

系统用例的研究对象就是某特定系统，不是组织，也不是系统内部的组件。如果存在“层次”上的疑惑，背后的原因是研究对象不知不觉改变了。

像医院信息系统的用例，有人会画成如下图所示，原因可能是前面没有画业务用例图和业务序列图，所以建模人员头脑里不知不觉把医院信息系统的价值和医院的价值混在一起了。