软件方法笔记-5系统用例

 系统用例图
1,让我们把聚光灯从组织转到我们要研究的系统。有了业务建模的铺垫，系统的用例图实际上已经呼之欲出，但是我们还是要先来讲解一下系统执行者和系统用例的要点，再看看如何从业务序列图映射出系统用例图。执行者和用例的概念在业务建模的章节已经出现过。现在要研究的执行者和用例，与业务建模时研究的执行者和用例相比，不同之处是研究对象，之前研究组织，现在研究系统
2,系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统.系统外。系统执行者不是所研究系统的一部分，是该系统边界外的一个系统。要正确理解这里的系统边界：不是物理的边界，而是责任的边界.交互,系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者.系统执行者和重要无关。系统执行者只关注谁和这个系统接口，不关心这个谁是重要人物，还是非重要人物
3,功能性交互。这里又引出一个问题：售票员是使用键盘鼠标和售票系统交互的，按道理，比起售票员来，鼠标离售票系统更近，为什么不把鼠标作为售票系统的执行者呢？还有，假设售票系统运行在Windows操作系统之上，那么Windows是不是售票系统的执行者？辨别的要点就是：执行者和系统发生的交互是系统的功能需求。一个人能自如地控制鼠标，猴子则做不到，是因为人脑里安装了如何使用鼠标的专家系统，可能是他父母安装的，也可能是他老师安装的。鼠标的移动如何变成屏幕上的信号，则是由鼠标驱动程序负责的，这些都不是售票系统关注的核心领域，售票系统关注的是售票员和售票系统之间的交互，所以售票员才是售票系统的执行者
4,系统。系统可以是一个人肉系统，也可以是一个非人智能系统，甚至是一个特别的外系统——时间。在软件业的早期，一个系统的执行者往往全部都是人。随着时间的推移，系统的执行者中非人执行者越来越多。
5,这体现了用例技术的优势。第2章已经说过，用例技术使用“执行者”和“涉众”代替了原来的“用户”，从而把演员和观众分开了。演员（执行者）在台上表演，观众（涉众）在台下看，演员表演什么是由观众的口味决定的，演员可以不是人，但观众是人。“用户”这个词混淆了演员和观众的界限。
6,如何识别系统执行者？以前的做法是头脑风暴，想一想谁使用系统来工作？谁维护系统？系统需要和哪些其他智能系统交互？有没有时间引发的事件？不过，有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可
7,从图可以看出，和监狱系统交互（存在实的消息线）的系统有监狱管理员、数码相机、指纹采集仪、医护人员，它们是监狱系统的执行者。映射出来的用例图如图.故意把系统执行者和系统用例分成两次识别，此处只识别系统执行者。实际工作中，系统执行者和系统用例是一起识别的
8,不要把执行者和权限管理混淆。有的人以为执行者映射了权限管理，意味着系统需要有相应的权限控制，这是一种误解。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。微信的“摇一摇”，是为年轻人提供的，但没有权限控制要先“登录并获得年轻人权限”才能使用，只是在考虑这个用例包含的各种需求时，要多考虑年轻人的利益。也许系统确实也有权限控制，而且角色的划分和执行者相近，但这两者要分开，更不可以因为系统不设权限控制，所以把执行者的名字合并为：用户。
9,“用户”这个词还是懒惰的表现。这个功能给谁用？给用户用。这样的回答，和“东西卖给消费者”一样，是正确而无用的废话。所以在给执行者命名时，尽量不要使用“用户”这个词，而是使用具体的执行者名称：储户、顾客、科长、验质员、检斤员…。当然，设计时尽可以抽象出“用户”这样的超类，这样许多特征都可以复用，但做需求时是不考虑复用的。
10,系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。
11,用例可以看作执行者和系统之间买卖的平衡点，期望和承诺的平衡点。还是以被说滥了的取款机为例。储户来到取款机面前，插卡输密码，拿到两百元后，到隔壁投注站买了10张福彩刮刮乐即开彩票，哇噻，中奖五万元。那么，取款机的用例到底是什么，“登录”、“取款”还是“中奖”？或者说“都对，从辩证的角度看嘛”？


“登录”不是取款机的用例，因为取款机不能这么叫卖自己：“来啊来啊！我这里能登录啊”，然后储户就说，“哇，真棒，这正是我想要取款机提供的服务，好，我去用一用”。储户对取款机的期望可不止这么多。“中奖”也不是取款机的用例，储户倒是很想从取款机那里得到这个服务，可惜，取款机没法承诺。“取款”才是取款机能承诺，而且储户乐意因此而使用取款机的服务。
12,用例之前的许多需求方法学，把需求定义为思考系统“做什么”，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。对于仍然习惯用学生思维思考、喜欢背标准答案的开发人员，思考“什么是系统的价值”有时甚至会让他痛苦到想要逃避，或者干脆用模糊不清的功能、特性等词语代替。


但是逃是逃不开的，生活中处处都需要这样的思考。人们求职、求偶、求**……不就是要搞清楚“我”这个人肉系统到底应该卖给谁，卖什么服务的最佳答案吗？我想卖给你的你不要，你想买的我又没有，就是人生的痛苦所在。许多时候，我们像没头苍蝇一样投简历、相亲，却不舍得抽出时间静下来思考“价值”的问题。
13,“用例的“粒度”是经常被讨论的一个问题。如果您做对了上面的题目，理解了“买卖”的要点，“粒度”的困惑就迎刃而解了。注意，“粒度”加了双引号，也就是说，所谓“粒度”，其实并不存在。用例不是面团，任由开发人员关在办公室里乱捏“我觉得那个用例粒度大了，捏小一点，那个用例粒度小了，捏大一点”，开发人员只能根据涉众心中对系统的期望，最后确定系统能提供什么，不能提供什么。有的书中会给出“粒度原则”，例如：一个系统的用例最好控制在××个之内、一个用例的基本路径最好控制在×步到×步之间……。“粒度”、“层次”这些概念迎合了开发人员的“设计瘾”，对开发人员的误导相当严重。开发人员不要玩弄“粒度原则”、“分层技巧”，应该把屁股坐过涉众那边去，揣摩涉众的心理，实事求是写下来。对于“用例是否用对了”，有一个朴素的判断标准：是否加强了和涉众的联系。如果不是，那就用错了——别管某些书上怎么说。
14,不是用例。Include（包含）关系也不是这样用的。Include的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个大用例Include一个小用例。看到这种一个用例Include许多个用例的形状，基本上可以判断它犯了把步骤当作用例的错误。喜欢犯“把步骤当作用例”错误的开发人员，在设计类的时候，暴露的操作往往也是“get**”、“set**”之类。
15,另一个经常碰到的问题是CRUD问题。打开一些开发人员画的用例图，看到的用例是四个四个一组的，仔细一看，刚好对应了数据库的四种操作，相当于把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字。后来，很多用例书籍和文章都提到了这个典型的错误，所以开发人员学乖了，干脆把每四个用例合并，改名叫管理××（或××管理），如图5-9——可惜，依然是换汤不换药。
16,乍一看好像也可以理解。不管前面的业务多复杂，到数据库这一层，不都是新增、检索、修改、删除吗？有位开发人员和我说过，“潘老师，我找到了抑制需求变更的好方法，把数据库的表当成需求不就行了吗？业务变来变去，数据库的表是相对稳定的。”


我还见到过这样的信息系统：在界面上把所有的“新增”功能都放在一起，根本不管这些功能是给不同的人在不同时间和不同业务流程中使用的。开发人员肯定想“反正都是数据库里新增一条记录嘛”。


问题在于：做需求的目的不是为了安慰自己或走过场，而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，不能贪图方便选择一个自己熟悉的视角应付了事。如果允许应付了事，我还有更好的绝招：我就是程序，程序就是我。您问我，某某系统的需求是什么？我回答：就是0和1的组合。对吗？对得不得了。可惜，这种正确而无用的废话，对做出好卖的系统没有帮助。“对好卖有帮助”是判断所做的的需求工作是否有意义的标准。
17,如何避免这样的错误呢？老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的系统用例是不会骗人的。新增、修改、删除、查询、管理、改变状态……这些词是数据库（或面向对象）里的“鸟语”，不是领域里的“人话”。业务流程中不会有人说，小张等一下，我到系统哪里去做一下发票管理，只会说，我去开一张发票，我去作废一张发票，我去开一张红字发票……而且，这些事情以不同的频率发生在不同的业务流程中
18,是否存在“管理××”用例呢？有的，但这样的用例往往是给系统管理员管理基本数据用的，而且都是千篇一律，不必花太多心思在上面。我们只要老老实实做业务建模，老老实实从业务流程映射系统用例。有一些用例无法从业务流程中映射，但系统需要它们来支撑，例如：系统管理员→管理系统用户，新系统尚未引入之前，业务流程中不会存在系统管理员这样一个业务工人。对于这种用于支撑的管理基本数据的用例，才用“管理××”来打扫战场
19,业务序列图中，从外部指向所研究系统的消息，可以映射为该系统的用例
20,有的箭头是从执行者指向用例，这样的执行者称为用例的主执行者，有的箭头是从用例指向执行者，这样的执行者称为用例的辅执行者。主执行者主动发起用例的交互，辅执行者在交互的过程中被动参与进来，但是，这两者都是达到用例的目标所需要的。例如图5-14中，如果指纹采集仪坏掉了，采集犯人指纹的用例就不能成功，只不过这个用例不是指纹采集仪首先发起而已。UML标准中，执行者和用例之间没有要求使用箭头，但我认为加上箭头表示主辅执行者是有意义的。
21,营业员使用营业受理系统为储户转账，在用例交互过程中，需要储户配合输入账户密码，否则转账用例不能成功，所以储户是合适的辅执行者。一般来说，辅执行者是人肉系统（例如图5-16中的储户）的情况比较少，更多情况下，辅执行者是另一个非人智能系统。


主辅执行者是针对某个用例来说的，一个系统在这个用例充当主执行者，也可以在另一个用例充当辅执行者。“××是系统的主（辅）执行者”的说法是错误的。如果时间要引发系统显示拓扑图，需要调度人员帮忙，实际并非如此，调度人员睡着了或者因突发心脏病倒下，不影响系统按照时间周期不断显示拓扑图。
22,用例很多时，可以将用例分包，但用例包是从外部对系统功能所做的分包，和子系统的概念是不一样的，子系统是根据内部部件的耦合和内聚切割得到。打开这样的“子系统”用例包，往往会发现里面的用例其实是步骤，甚至是某个类的操作。
23,从内外两个角度分割系统的区别。我们可以说吃喝拉撒是“人”的功能，但不能说是 “人的吃喝拉撒子系统”的功能。
24,研究对象是一个人事系统，员工先通过系统交请假单，主管使用系统批假，然后人事部专员使用系统备案
25,但有时候开发人员会觉得，哎呀，没请到假，怎么能算价值呢.人事系统只能向员工承诺“你把请假单交给我，我要是没保存好，你可以骂我”，员工不能指望仅仅和人事系统打交道就能请到假，这个价值是由【人事系统＋主管＋人事部专员】一起提供的
26,针对不同执行者、不同业务流程，系统提供的价值可大可小，大的是用例，不妨碍小的也是用例，只要是从涉众的视角得到的
27,用例的命名是动宾结构，例如“取款”。动词前面可以加状语，宾语前面可以加定语，把一句话的主语砍掉，剩下的可以作为用例的名字.用例之前的需求技术，有的可能是以“名字+动词”的形式命名系统的功能，例如“发票作废”，后来要改成用例的动宾结构了，开发人员就在前面加一个弱动词“进行”，就变成了“进行发票作废”，这个也是不合适的。如果“名词+动词”已经成为行业中的一个术语，也未必要严格的动宾结构。例如“成果分析”在某行业是一个术语，也就不必硬要倒过来变成“分析成果”了