[软件方法]CRUD的问题在于思考视角不对

会员服务 ·

[软件方法]CRUD的问题在于思考视角不对

2017 年 8 月 18 日 UMLChina 潘加宇

第5章需求之系统用例图

爱情不是你想卖，想买就能卖。

《爱情买卖》；词：何欣，曲：周洪涛，唱：慕容晓晓；2009

让我们把思考的边界从组织缩小到要研究的系统。有了业务建模的铺垫，系统的用例图已经呼之欲出，但是我们还是要先来讲解一下系统执行者和系统用例的要点，再看看如何从业务序列图映射出系统用例图。

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

5.1 系统执行者要点

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

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

封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。不了解这一点，建模人员很容易把“添加一些功能”当作“研发新系统”。如图5-1所示，系统对外提供了某些服务，这些服务被分为A和B两组，但不能说有A和B两个系统。这个错误其实就是“从需求直接映射设计”的错误，如果没有很好理解第1章所阐述的“需求和设计的区别”，建模人员很容易犯这样的错误。

图5-1 错误：把功能分包当成系统

图5-2中A系统和B系统各自封装，通过接口协作，这种情况下可以称为两个系统（或子系统、组件）。

图5-2通过接口协作的两个系统

例如，建模人员说“我们在做一个积分兑换系统”，画出用例图如图5-3。

图5-3 错误：胡乱划分系统

实际上哪里有那么多系统，只是同一系统上的功能分包而已，数据都是共享的。正确的用例图应如图5-4。

图5-4 系统只有一个

5.1.2 系统边界是责任的边界

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

现在大多数的软件运行形态是分布式的。一个系统可能有一部分组件部署在移动终端，其他部分组件可能部署在不同物理位置的Web服务器、应用服务器等等，导致建模人员会不自觉地认为自己在做多个系统，然后针对每个部分画用例图。其实他所研发的只有一个系统，上面这些组件都属于系统的设计。涉众根本不在意系统划分成几个组件以及组件之间如何分布和交互。建模人员如果没有学会从涉众视角看问题，只是从自己角度看问题，就会犯这样的错误。甚至有的人根据研发团队分几个组来判断当前在做几个系统，说两个就两个，说三个就三个，根本不管在客户眼里人家要几个。

严格来说，即使是“单机”的系统，运行形态也是“分布式”的，分布在CPU、高速缓存、主存、辅存等多个部位，互联网可以看作更大的“单机”。

图5-5 “分布式”没什么特别

如果根据责任来划分边界，那么一个系统在所研究系统之外的意思是：实现它不属于所研究系统的研发团队的责任——可能是父母通过生物编码实现，也可能是其他公司的程序员编码实现。这意味着一个系统可以分布在多个物理位置，也意味着同一个物理位置可以存在多个系统。

手机里装了很多软件，物理边界似乎说不清道不明，但从责任上看，哪一段代码是Google的程序员写的，哪一段代码是腾讯的程序员写的，哪一段代码是本公司的程序员写的，清清楚楚明明白白。

图5-6是一个通过物理位置来划分系统的错误例子。做一个通过手机遥控电视的控制软件，因为想到系统将来部署时可能会有一部分部署在手机端，另一部分部署在电视端。建模人员按照物理位置把系统分为手机端、电视端两个系统画在业务序列图上，映射到系统用例图时，得到两张系统用例图。

图5-6错误的遥控软件用例图

正确的用例图应如图5-7所示。

图5-7 正确的遥控软件用例图

边界越模糊，越需要执行者来帮助理清。有的建模人员觉得自己所研发的系统“比较特别”，执行者很难界定，干脆认为“执行者”不适合他们所研发的系统。仔细观察可以发现，该人员所在团队的成员对系统的责任范围根本没有形成共识，而且扯了几个月了还是扯不清楚。这样的想法相当于认为“把公鸡杀了，天就永远不会亮了”。

5.1.2 系统执行者和系统有交互

外系统必须和系统有交互，否则不能算是系统的执行者。

如图5-8，一名旅客来到火车站售票窗口，告诉售票员目的地和车次，售票员使用售票系统帮助旅客购买火车票。这个场景中，和火车票售票系统交互的是售票员，他是售票系统的执行者，旅客不是。有的建模人员碰到类似问题时会情不自禁地把旅客当作执行者，因为他觉得售票员是在执行旅客的指令（也许旅客又是执行其配偶的指令），或者觉得旅客比售票员重要，如果不把旅客当作执行者的话旅客的利益就会被忽略。

图5-8 旅客不是售票系统的执行者

系统执行者和重要无关。系统执行者只关注哪个外系统和所研究系统接口。这个外系统可能连人都不是，更谈不上重要不重要了。从平时的工作和生活经验我们也可以知道，当系统执行者当得最欢、整天和电脑手机打交道的人，多半不是什么大人物，而是一线的打工仔，例如营业员、办事员、客服等。大人物虽然偶尔也会用软件系统看看报表，但更多时间恐怕不是敲键盘点手机，而是摸高尔夫球杆。

和重要有关的概念是涉众。在上面提到的售票系统的“售票员→售票”用例中，旅客是很重要的涉众，而且用例不止这么一个涉众。售票员在售票的时候，好多双眼睛在盯着看呢。

旅客：担心出错票，更担心拿到了错票自己还不察觉；担心票是打出来了，信息却没有保存下来；担心指定日期没那个车次的票…

售票员：担心操作太复杂，一天下来手指麻木；担心不好用，出错票被扣钱…

火车站领导：担心售票员玩忽职守，出错票引起纠纷；担心重复出票造成纠纷…

用例必须在它的路径、步骤和补充约束中考虑这些涉众的利益。

火车票售票系统现在已经提供了旅客自行购票的接口，例如互联网购票、售票机等。这种情况下，旅客也是售票系统的执行者，不过“售票员→售票”和“旅客→购票”是两个不同的用例，它们关注的涉众利益不完全相同，相应的需求自然也不同。旅客不是天天都买票，所以和旅客打交道的用例，交互界面可以浅显一点，交互节奏可以慢一点，甚至可以卖卖广告，而且要特别注意并发容量、网络安全等问题；售票员一天要卖几百上千张票，和售票员打交道的用例，交互应该直截了当。

接下来是一个经常引起争议的问题：还是以售票系统的“售票员→售票”用例为例，假设在售票员售票过程中，旅客前面也有一个界面向旅客反馈他关心的信息，比如余票、当前选择的票等，甚至还可以根据旅客的目的地播放当地旅游景点的广告。这种情况下，旅客是售票系统的执行者吗？

依然不是，因为系统要完成用例不需要等待旅客的响应。旅客就算睡着了也不影响用例的完成。如果售票过程中需要旅客有意识地按键确认一下，否则票就出不来，那就不一样了，旅客就成了售票系统的“售票员→售票”用例的（辅）执行者。

5.1.3 交互是功能性交互

上面说的交互还引出一个问题：假设售票员使用鼠标和售票系统交互，按道理，比起售票员来，鼠标离售票系统更近，为什么不把鼠标作为售票系统的执行者呢？还有，假设售票系统运行在Windows操作系统之上，那么Windows是不是售票系统的执行者？

辨别的要点就是：执行者和系统发生的交互是系统的功能需求。如图5-9上部的序列图所示，售票员能自如地辨认并控制鼠标，是因为她的大脑里安装了如何使用鼠标的专家系统（可能是老师也可能是父母安装的）。猴子的大脑里没有这个系统，所以它很可能看到鼠标就一把抓起来往嘴里送。鼠标的移动和点击如何变成有效的输入事件，则由操作系统（包含了鼠标驱动程序）负责。以上这些交互都不是售票系统的核心域概念，售票员和售票系统之间的交互才是，所以售票员才是售票系统的执行者。

图5-9 售票系统的功能需求

Windows也不会成为售票系统的执行者，因为售票系统和Windows之间的交互很可能只是开发人员的设计，不是需求。涉众只是要求系统又快又好又稳定，并不在意操作系统用Windows还是Linux。如果涉众明确要求操作系统必须是Windows，那么Windows就会成为需求，但也只是设计约束类型的需求，不会成为功能需求。

当然，如果所研究系统是鼠标驱动程序，鼠标会成为合适的执行者，因为这时和鼠标之间的交互成为鼠标驱动程序的功能需求。

5.1.4 系统执行者可以是人或非人系统

系统执行者可以是一个人脑系统，也可以是一个非人智能系统，甚至是一个特别的外系统——时间。在软件业的早期，一个系统的执行者往往全部都是人。随着时间的推移，系统的执行者中非人执行者所占的比例越来越多。现在一个新系统上线，可能只有一半的接口是和人打交道，另一半接口是和非人智能系统打交道。如图5-10所示。

图5-10 从“执行者都是人”到“执行者有一些是人”

用例的优势在这里得到了体现。用例技术中“执行者”和“涉众”的概念，把演员和观众分开了。演员（执行者）在台上表演，观众（涉众）在台下看，演员表演什么是由观众的口味决定的，演员可以不是人，但观众肯定是人。演员如果是人类，那么在观众席上也会有一个位置，不过在第几排就不知道了。

用例使用“执行者”和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”，这是错误的。所谓“用户”，就是上台表演的人类演员。找用户调研需求，相当于找演员问剧本应该是什么内容，岂不是很荒谬？剧本应该由编剧向观众调研编写出来，然后由各路演员在台上演绎。

上面已经说过，在台上当“用户”当得越欢的涉众，往往在涉众排行榜上排位越靠后。整天操作电脑搞得手僵脖子硬的“用户”，有几个是职位高的呢？真正位高权重的涉众，虽然偶尔也会上台表演，但更多时候是坐在台下看戏。建模人员如果过多地关注“用户”，花在重要的前排涉众身上的时间可能就不够了。

像“用户故事”这样的方法在开发一些面向大众的互联网系统时还能应付，因为这类系统的执行者往往属于前排涉众。如果开发涉众较多、利益冲突微妙的系统，应该采用用例这样更严谨的需求技能。

越来越多的系统执行者不是人类，也就是说没有“用户”。两个电脑系统交互的需求，难道就不用做了，或者可以随便做？非也。那只是相当于上台表演的不是人，是功夫熊猫、变形金刚和喜羊羊灰太狼，但是台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演，涉众在台下看表演”的概念，在执行者为非人系统时对捕获需求很有帮助。

5.2 【步骤】识别系统执行者

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

如果没有做业务建模，识别系统执行者只能靠头脑风暴。可以思考类似下面的问题：什么人会使用系统来工作？什么人负责维护系统？系统需要和哪些其他智能系统交互？有没有定时引发的事件？

有了业务建模，就不需要头脑风暴了，直接从业务序列图映射即可。业务序列图上，和所研究系统有实线相连的对象映射为所研究系统的执行者。图5-11是某个房屋中介组织“寻找租客线索”的业务序列图，从中可以看出，和线索管理系统交互（有实线相连）的有线索部经理、外呼人员、电信电话系统和CRM，它们就是线索管理系统的执行者。映射到系统用例图如图5-12。

本书为了讲解需要，故意把系统执行者和系统用例分成两次识别，此处只识别系统执行者。实际工作中，系统执行者和系统用例是一起识别的。

图5-11 业务序列图：寻找租客线索

图5-12 从业务序列图映射得到系统执行者

图5-12中执行者不再带有斜杠，因为这时候研究对象是系统。有的执行者画在边界框左边，有的则画在右边，是为了方便表达主执行者和辅执行者。这方面内容稍后再详述。

本书不提供练习题答案，请扫码或访问http://www.umlchina.com/book/quiz5_1.htm完成在线测试，做到全对，自然就知道答案了。

1. 以类似_______这样的系统为研究对象时，“打印机”作为执行者是合适的。

 A) Word

 B) 财务报表系统

 C) Photoshop

 D) 打印管理器

2. 市民想给交通卡充值，来到营业点把钱和卡一起递给营业员，营业员操作“充值系统”充值。针对“充值系统”的执行者，以下看法正确的是

 A) 执行者应是市民，因为市民比营业员重要，而且营业员最终执行的是市民的指令。

 B) 执行者应该是充值系统，因为充值由充值系统完成

 C) 执行者应该是营业员，系统执行者与重要无关

 D) 市民和营业员一起作为执行者

3. 根据以下业务序列图，请问属于“一卡通系统”执行者的是（可多选）

 A) 外来办事人员  B) 一卡通系统

 C) 大院门口保安 D) 受访人\

 E) 来车监控系统 F) 时间

4. 以下说法正确的是（多选）：

 A) 业务执行者不一定是系统执行者。

 B) 系统执行者一定是业务执行者。

 C) 系统执行者一定是业务工人。

 D) 系统执行者一定要和系统交互。

 E) 系统执行者一定是系统的涉众。

 F) 系统的涉众一定是系统执行者。

5. 作为新一代的需求技术，用例用“执行者”取代了“用户”，关于这两个概念，以下说法正确的是（本题可多选）

 A) 实际上是一回事，某些方法学家炒作概念而已。

 B) “用户”把演员和观众混在一起了。

 C) “执行者”指的是“客户”，比“用户”更加值得关注。

 D) “执行者”可以不是人，“用户”默认是人。

 E) “执行者”不一定直接使用系统，“用户”一定直接使用系统。

 F) “执行者”之间可以有泛化关系，“用户”没有。

6. 类似“用户故事”之类的需求描述方式，在开发一些面向大众的互联网系统时还能应付，原因是：

 A) 互联网比较注重创新，用户故事也比较注重创新。

 B) 互联网比较注重敏捷，用户故事更敏捷。

 C) 互联网系统的“用户”和前排涉众重叠程度较高。

 D) 故事的方式更适合和低学历的大众沟通。

5.3 系统用例要点

5.3.1 价值是买卖的平衡点

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

以取款机为例，“储户→登录”不是它的用例，因为储户对取款机的期望以及取款机能做的承诺不只是登录。或者这样思考：取款机不能这么叫卖：“来啊来啊！我这里能登录啊”，然后储户就说“哇，真棒，这正是我想要取款机提供的服务，好，我去用一用”。

或者可以设想可能观察到的场景：

张三要出差，发现身上没现金，到取款机那里取现金，然后离开取款机忙别的去了。

客户给张三卡里转了5000元，电话请张三查收，张三到取款机那里看看自己的卡当前余额多少，脑子里想想是不是比之前多了5000，然后离开取款机忙别的去了。

以上两个场景在典型的业务流程中可以观察到，而下面的场景就比较离谱了：

************，张三到取款机那里登录，然后离开取款机忙别的去了。

所以，取款机正确和错误的用例如图5-13所示。

图5-13 取款机的用例

用例之前的许多需求方法学，把需求定义为思考系统“做什么”，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案，而得到这个最佳答案不是靠拍脑袋，而是要通过揣摩涉众得到。要得到合适的用例，需要有一颗善于体察他人的心。如果建模人员总是习惯于从自己的角度想问题，那么让他思考“什么是系统应该提供的价值”有时甚至会让他痛苦到想要逃避，或者干脆用功能、特性等模糊不清的词语代替。

但是逃是逃不开的，生活中处处都需要这样的思考。人们求职、求偶不就是要搞清楚“我”这个人脑系统应该卖给谁，卖什么服务的最佳答案吗？我会吃喝拉撒，你不愿意为此给我报酬；你想要长生不老，我又提供不了这么大的价值。要找到一个我能干好而且你又乐意买单的平衡点，确实很难。

例如，“程序员”这个人脑系统为它的老板提供的用例是什么？安装开发工具？编码？为公司赚钱？答案是编码，这是老板对程序员的期望以及程序员可以提供的承诺的平衡点，或者说，这是程序员能卖，老板愿意买的价值。程序员不能因为装了个Visual Studio就理直气壮向老板要报酬，老板不给就生气；程序员按要求编出了代码，老板就不能因为销售部门不给力或经济崩溃导致赚不到钱而责怪程序员。正确和错误的用例如图5-14所示。

图5-14 程序员人脑系统的用例

程序员如果摆错了自己的位置，没有好好完成编码的本职工作，反倒是动不动向老板上“万言书”，对公司的发展方向大放厥词，老板是不会喜欢的，因为他不期望从程序员身上“购买”这个服务（用某知名企业领导人的话说就是：有精神病就送医院，没精神病就辞退）。

可见，搞清楚自己的“用例”，认清自己的定位，对人生多么重要。如果您不断通过用例思维来思考系统的价值，就能训练出越来越强大的发现价值的能力。无论打工还是创业，这种发现价值的能力都可以让您受益。

5.3.2 价值不等于“可以这样做”

回到上面取款机的例子，可能有人会“较真”了：什么，你说没有人会登录了就离开？我今晚下班就去取款机那里登录一下就走人给你看！那么我们来看看下面的例子：

电视台记者小崔经受着失眠的痛苦，经常精神恍惚。有一天晚上他在取款机取现金时，居然恍惚到把银行卡往取款机一插就走开了。回家之后，发现自己可能会丢钱，心里居然生出一种舒适感，过一会就安然入睡了。小崔尝到这个甜头后，干脆睡不着时就跑到楼下取款机插一张卡，回家后果然酣然入睡。在小崔看来，千金难买安稳觉，这样做是划算的。

请问：如果世界上确实有小崔这样的人，那么插卡是取款机的用例吗？

不是。理由：小崔不是取款机的目标执行者。虽然取款机无法防止小崔这样做，但取款机被摆在大街上的初衷不是为小崔这样的人这么用的。当然，不排除有厂家看到“类小崔人群”的痛苦，分析背后的心理后，制造出面向“类小崔人群”的助眠专用取款机。那已经是另外一款产品了。

再看下面的例子。一个办公系统，科员有两个用例A和B。科长比科员级别高，所以除了自己的用例，还可以使用科员的用例。处长级别最高，想做什么就做什么，没人敢拦着。所以，建模人员画出了图5-15这样的蜘蛛网用例图，把执行者和用例的关系误解成了权限管理。

图5-15 蜘蛛网用例图

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

一罐可乐打开放在那里，乌鸦路过也可以喝，可乐本身并没有权限管理防止乌鸦喝它，但乌鸦仍然不是可乐的执行者，因为乌鸦不是可乐的目标客户。

5.3.3 粒度的困惑不存在

理解了上面两个要点，经常被讨论的“粒度”困惑就不存在了。用例不是面团，任由建模人员关在办公室里乱捏——“我觉得那个用例粒度大了，捏小一点，那个用例粒度小了，捏大一点”，你以为你爸是李刚，随便做点什么都有人买单吗？建模人员只能根据目标涉众心中对系统的期望来确定系统应该提供什么样的服务。

有的书中给出“最佳粒度原则”，例如：一个系统的用例最好控制在××个之内、一个用例的基本路径最好控制在×步到×步之间……这些是没有根据的。市场需要各种各样的系统，有功能众多的也有功能单一的，有一步到位的也有交互复杂的。应该把屁股坐到涉众那边去，揣摩涉众的心理，实事求是写下来。不过，“粒度”、“层次”这些概念迎合了建模人员的“设计瘾”，很容易误导建模人员。

如果建模人员在粒度问题上热烈争吵，纠缠不清，有可能已经犯了错误。最常犯的错误是把步骤当作用例。如图5-16，右侧的“验密码”和“扣除金额”其实只是用例“取现金”的步骤（一眼可以看出其主语是系统），不是用例。Include（包含）关系也不是这样用的。Include的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个用例Include一个用例。看到这种一个用例Include许多个用例的形状，基本上可以判断它犯了把步骤当作用例的错误。正确的做法是：把右侧的“验密码”和“扣除金额”作为步骤写在用例规约中。

图5-16 错误：把步骤当作用例

5.3.4 CRUD的问题在于思考视角不对

打开一些用例图，映入眼帘的用例是四个四个一组的。仔细一看，刚好对应了数据库的四种操作。相当于把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字。很多用例书籍和文章都提到了这个典型的错误，有的建模人员就学乖了，干脆把每四个用例合并，改名叫管理××（或××管理），如图5-17——可惜，依然是换汤不换药。

图5-17 从数据库视角得到的用例

乍一看好像也可以理解。不管前面的业务多复杂，到数据库这一层，不都是新增、检索、修改、删除吗？有位开发人员和我说过，“潘老师，我找到了抑制需求变更的好方法，把数据库的表和字段当成需求不就行了吗？业务变来变去，数据库的表和字段是相对稳定的。”我还见到过这样的软件系统：在界面上把所有的“新增”功能都放在一起，根本不管这些功能是给不同的人在不同时间和不同业务流程中使用的。程序员肯定想“反正都是数据库里新增一条记录嘛”。

问题在于：做需求的目的不是为了安慰自己或走过场，而是让系统更加好卖。需求工作中，我们所写的每一个字，所画的每一张图都必须对好卖有推动作用，否则还不如不做。所以即使再难，也只能从涉众的视角来定义需求，不能贪图方便选择一个自己熟悉的视角应付了事。如果允许应付了事，我还有更好的绝招：我就是程序，程序就是我。您问我，某某系统的需求是什么？我回答：就是0和1的组合。对吗？对得不得了。可惜，这种正确而无用的废话，对做出好卖的系统没有帮助。

图5-18 从涉众视角得到的才是用例

如何避免这样的错误呢？老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的系统用例是不会骗人的。新增、修改、删除、查询、管理、改变状态……这些词是数据库的“鸟语”，不是领域里的“人话”。业务流程中不会有人说，小张等一下，我到系统哪里去做一下发票管理，只会说，我去开一张发票，我去作废一张发票，我去开一张红字发票……而且，这些事情以不同的频率发生在不同的业务流程中。所以图5-17的用例图应该修改为图5-19。