第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 从“执行者都是人”到“执行者有一些是人”
用例的优势在这里得到了体现。第2章说过，用例技术使用“执行者”和“涉众”代替了原来的“用户”，从而把演员和观众分开了。演员（执行者）在台上表演，观众（涉众）在台下看，演员表演什么是由观众的口味决定的，演员可以不是人，但观众是肯定人。演员如果是人类，那么在观众席上也会有一个位置，不过在第几排就不知道了。
用例使用“执行者”和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”，这是错误的。所谓“用户”，就是上台表演的人类演员。找用户调研需求，相当于找演员问剧本应该是什么内容，岂不是很荒谬？剧本应该由编剧找观众调研编写出来，然后由各路演员在台上演出来。
上面已经说过，在台上当“用户”当得越欢的涉众，往往在涉众排行榜上排位越靠后。整天操作电脑搞得手僵脖子硬的“用户”，有几个是职位高的呢？真正位高权重的涉众，虽然偶尔也会上台表演，但更多时候是坐在台下看戏。建模人员如果过多地关注“用户”，花在重要的前排涉众身上的时间可能就不够了。
像“用户故事”这样的方法在开发一些面向大众的互联网系统时还能应付，因为这类系统的执行者往往属于前排涉众。如果开发涉众较多、利益冲突微妙的系统，应该采用用例这样更严谨的需求技能。