5章 需求 之 系统用例图

返回>>

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

《爱情买卖》;词:何欣,曲:周洪涛,唱:慕容晓晓;2009

 

让我们把聚光灯从组织转到我们要研究的系统。有了业务建模的铺垫,系统的用例图实际上已经呼之欲出,但是我们还是要先来讲解一下系统执行者和系统用例的要点,再看看如何从业务序列图映射出系统用例图。执行者和用例的概念在业务建模的章节已经出现过。现在要研究的执行者和用例,与业务建模时研究的执行者和用例相比,不同之处是研究对象,之前研究组织,现在研究系统。

5.1 系统执行者要点

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

系统外。系统执行者不是所研究系统的一部分,是该系统边界外的一个系统。要正确理解这里的系统边界:不是物理的边界,而是责任的边界。不能说运行在同一台电脑中,共享内存和硬盘,就是同一个系统。Google网站的边界在哪里?服务器分布在全球,桌面上还有一个客户端,物理位置看起来好像说不清道不明,但是,哪一段代码是Google的开发人员写的,哪一段代码是微软的开发人员写的,哪一段代码是这个项目的开发人员写的,责任很清楚。

交互。系统执行者必须和系统有交互,不和系统交互的不算是系统的执行者。一名旅客来到火车票售票点,告诉售票员目的地和车次,售票员使用售票系统打出火车票。这个场景中,和火车票售票系统交互的是售票员,他/她是售票系统的执行者,旅客不是。可能有的开发人员碰到类似问题时会想:难道售票员不是在执行旅客的指令(也许旅客又是执行老婆的指令)吗?旅客比售票员重要,不把旅客当作执行者会不会忽略了旅客的利益?

系统执行者和重要无关。系统执行者只关注谁和这个系统接口,不关心这个谁是重要人物,还是非重要人物。如果执行者是一个非人系统,就更谈不上重不重要了。从平时的工作和生活经验我们也可以知道,当系统执行者当得最欢,整天和电脑打交道的人,往往是一线的打工仔(营业员、办事员、客服……),真正重要的人物会整天坐在电脑前面摸键盘弄鼠标吗?虽然偶尔也会用系统看看报表,但更多时间是摸高尔夫球杆吧?

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

旅客担心出错票,更担心拿到了错票自己还不察觉;担心票是打出来了,信息却没有传到后头;担心指定日期没那个车次的票

售票点老板担心售票员玩忽职守,出错影响声誉;担心售票员匿旅客的钱,出假票,然后拿钱开溜

售票员担心操作太复杂,一天下来手指麻木;担心不好用,出错票被老板扣钱

火车站担心重复出票造成纠纷

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

如果火车票售票系统提供旅客购票的接口,例如互联网购票、售票机等,旅客可以自行和这些系统交互来达到购票的目的,这个时候旅客就成了系统执行者。“售票员→售票”和“旅客→购票”是两个不同的用例,重点关注的涉众利益不同,相应的需求自然也不同。和旅客打交道的用例,交互可以生动一点,节奏可以慢一点,甚至可以卖卖广告,还要特别注意容量、安全等问题;和售票员打交道的用例,交互应该直截了当,甚至连鼠标都不要用。

功能性交互。这里又引出一个问题:售票员是使用键盘鼠标和售票系统交互的,按道理,比起售票员来,鼠标离售票系统更近,为什么不把鼠标作为售票系统的执行者呢?还有,假设售票系统运行在Windows操作系统之上,那么Windows是不是售票系统的执行者?

5-1 售票员鼠标售票系统

辨别的要点就是:执行者和系统发生的交互是系统的功能需求。一个人能自如地控制鼠标,猴子则做不到,是因为人脑里安装了如何使用鼠标的专家系统,可能是他父母安装的,也可能是他老师安装的。鼠标的移动如何变成屏幕上的信号,则是由鼠标驱动程序负责的,这些都不是售票系统关注的核心领域,售票系统关注的是售票员和售票系统之间的交互,所以售票员才是售票系统的执行者。

如果研究对象是鼠标驱动这样的系统,鼠标就会成为合适的执行者,因为这个时候,和鼠标之间的交互成为鼠标驱动的功能需求。

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

系统。系统可以是一个人肉系统,也可以是一个非人智能系统,甚至是一个特别的外系统——时间。在软件业的早期,一个系统的执行者往往全部都是人。随着时间的推移,系统的执行者中非人执行者越来越多。

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

这体现了用例技术的优势。第2章已经说过,用例技术使用“执行者”和“涉众”代替了原来的“用户”,从而把演员和观众分开了。演员(执行者)在台上表演,观众(涉众)在台下看,演员表演什么是由观众的口味决定的,演员可以不是人,但观众是人。“用户”这个词混淆了演员和观众的界限。

5.2 【需求步骤2-1】识别系统执行者

如何识别系统执行者?以前的做法是头脑风暴,想一想谁使用系统来工作?谁维护系统?系统需要和哪些其他智能系统交互?有没有时间引发的事件?不过,有了前面的业务建模,就不需要头脑风暴了,直接从业务序列图映射即可。

5-3 业务序列图:法警押送犯人入狱

从图5-3可以看出,和监狱系统交互(存在实的消息线)的系统有监狱管理员、数码相机、指纹采集仪、医护人员,它们是监狱系统的执行者。映射出来的用例图如图5-4

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

  

5-4 从图5-3映射得到的监狱系统执行者

不要把执行者和权限管理混淆。有的人以为执行者映射了权限管理,意味着系统需要有相应的权限控制,这是一种误解。用例的主执行者只是表明这个用例是为这一类执行者而做,但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。微信的“摇一摇”,是为年轻人提供的,但没有权限控制要先“登录并获得年轻人权限”才能使用,只是在考虑这个用例包含的各种需求时,要多考虑年轻人的利益。也许系统确实也有权限控制,而且角色的划分和执行者相近,但这两者要分开,更不可以因为系统不设权限控制,所以把执行者的名字合并为:用户。

“用户”这个词还是懒惰的表现。这个功能给谁用?给用户用。这样的回答,和“东西卖给消费者”一样,是正确而无用的废话。所以在给执行者命名时,尽量不要使用“用户”这个词,而是使用具体的执行者名称:储户、顾客、科长、验质员、检斤员。当然,设计时尽可以抽象出“用户”这样的超类,这样许多特征都可以复用,但做需求时是不考虑复用的。

5-5 不要简单命名执行者为“用户”

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

 A) Word

 B) 财务报表系统

 C) Photoshop

 D) 打印管理器

 E) OA系统

 F) PowerPoint

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

 A) 执行者应是市民,因为市民比营业员重要。

 B) 执行者应是营业员,因为营业员比市民重要

 C) 执行者应是市民,毕竟营业员最终执行的是市民的指令

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

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

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


 

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

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

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

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

4. 以下说法不正确的是(多选):

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

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

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

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

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

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

 

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

 

 

5.3 系统用例要点

系统用例的定义:系统能够为执行者提供的、涉众可以接受的价值。

用例可以看作执行者和系统之间买卖的平衡点,期望和承诺的平衡点。还是以被说滥了的取款机为例。储户来到取款机面前,插卡输密码,拿到两百元后,到隔壁投注站买了10张福彩刮刮乐即开彩票,哇噻,中奖五万元。那么,取款机的用例到底是什么,“登录”、“取款”还是“中奖”?或者说“都对,从辩证的角度看嘛”?

“登录”不是取款机的用例,因为取款机不能这么叫卖自己:“来啊来啊!我这里能登录啊”,然后储户就说,“哇,真棒,这正是我想要取款机提供的服务,好,我去用一用”。储户对取款机的期望可不止这么多。“中奖”也不是取款机的用例,储户倒是很想从取款机那里得到这个服务,可惜,取款机没法承诺。“取款”才是取款机能承诺,而且储户乐意因此而使用取款机的服务。

5-6 取款机的用例

用例之前的许多需求方法学,把需求定义为思考系统“做什么”,用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的,因为它没有标准答案,只有最佳答案。对于仍然习惯用学生思维思考、喜欢背标准答案的开发人员,思考“什么是系统的价值”有时甚至会让他痛苦到想要逃避,或者干脆用模糊不清的功能、特性等词语代替。

但是逃是逃不开的,生活中处处都需要这样的思考。人们求职、求偶、求**……不就是要搞清楚“我”这个人肉系统到底应该卖给谁,卖什么服务的最佳答案吗?我想卖给你的你不要,你想买的我又没有,就是人生的痛苦所在。许多时候,我们像没头苍蝇一样投简历、相亲,却不舍得抽出时间静下来思考“价值”的问题。

我们来看“程序员”这个人肉系统,它为老板提供的用例是什么?安装开发工具?编码?为公司赚钱?答案是编码,这是老板对程序员的期望以及程序员可以提供的承诺的平衡点,或者说,这是程序员能卖,老板愿意买的价值。程序员不能因为装了个Visual Studio就理直气壮向老板要报酬,老板不给就生气;程序员按要求编出了代码,老板就不能因为销售部门不给力导致软件卖不出去赚不到钱而责怪程序员。

5-7 程序员人肉系统的用例

程序员如果摆错了自己的位置,没有好好完成本职工作,反倒是向老板上“万言书”,对公司的发展方向大放厥词,指手画脚,老板是不会喜欢的,因为他不期望从程序员身上“购买”这个服务(用某知名企业领导人的话说就是:有精神病就送医院,没精神病就辞退)。可见,搞清楚自己的“用例”,认清自己的定位,对人生多么重要。当然,随着时间的发展,人肉系统可以不断升级,淘汰旧的用例,开发新的用例。

思考用例的过程就是发现价值的过程。如果您不断通过用例思维来思考系统的需求,就能训练出越来越强大的发现价值的能力。无论打工还是创业,这种发现价值的能力是非常有帮助的。用例思维可以让您终身受益。


 

1. _____这样的系统为研究对象时,“登录”作为用例是合适的

 A) ERP

 B) 电子商务网站如淘宝

 C) 取款机

 D) 门禁

 E) OA系统

 F) 指纹扫描仪

2. _____这样的系统为研究对象时,“输入密码”作为用例是合适的

 A) 密码保险箱

 B) 电子商务网站如淘宝

 C) 取款机

 D) 门禁

 E) OA系统

 F) 指纹扫描仪

 

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

 

 

“用例的“粒度”是经常被讨论的一个问题。如果您做对了上面的题目,理解了“买卖”的要点,“粒度”的困惑就迎刃而解了。注意,“粒度”加了双引号,也就是说,所谓“粒度”,其实并不存在。用例不是面团,任由开发人员关在办公室里乱捏“我觉得那个用例粒度大了,捏小一点,那个用例粒度小了,捏大一点”,开发人员只能根据涉众心中对系统的期望,最后确定系统能提供什么,不能提供什么。

有的书中会给出“粒度原则”,例如:一个系统的用例最好控制在××个之内、一个用例的基本路径最好控制在×步到×步之间……。“粒度”、“层次”这些概念迎合了开发人员的“设计瘾”,对开发人员的误导相当严重。开发人员不要玩弄“粒度原则”、“分层技巧”,应该把屁股坐过涉众那边去,揣摩涉众的心理,实事求是写下来。对于“用例是否用对了”,有一个朴素的判断标准:是否加强了和涉众的联系。如果不是,那就用错了——别管某些书上怎么说。

如果开发人员在热烈讨论粒度问题,纠缠不清,有可能是犯了错误。最常犯的错误是:把步骤当作用例。如图5-8中的用例:

5-8 最常犯错误:把步骤当作用例

右边的“验密码”和“扣除取款金额”其实只是用例“取款”的步骤(一眼可以看出来,主语是系统),不是用例。Include(包含)关系也不是这样用的。Include的目的是为了复用在多个用例中重复出现的步骤集合,形状往往是多个大用例Include一个小用例。看到这种一个用例Include许多个用例的形状,基本上可以判断它犯了把步骤当作用例的错误。

喜欢犯“把步骤当作用例”错误的开发人员,在设计类的时候,暴露的操作往往也是“get**”、“set**”之类。

另一个经常碰到的问题是CRUD问题。打开一些开发人员画的用例图,看到的用例是四个四个一组的,仔细一看,刚好对应了数据库的四种操作,相当于把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字。后来,很多用例书籍和文章都提到了这个典型的错误,所以开发人员学乖了,干脆把每四个用例合并,改名叫管理××(或××管理),如图5-9——可惜,依然是换汤不换药。

 

 

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

乍一看好像也可以理解。不管前面的业务多复杂,到数据库这一层,不都是新增、检索、修改、删除吗?有位开发人员和我说过,“潘老师,我找到了抑制需求变更的好方法,把数据库的表当成需求不就行了吗?业务变来变去,数据库的表是相对稳定的。”

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

问题在于:做需求的目的不是为了安慰自己或走过场,而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。即使再难,也只能从涉众的视角来定义需求,不能贪图方便选择一个自己熟悉的视角应付了事。如果允许应付了事,我还有更好的绝招:我就是程序,程序就是我。您问我,某某系统的需求是什么?我回答:就是01的组合。对吗?对得不得了。可惜,这种正确而无用的废话,对做出好卖的系统没有帮助。“对好卖有帮助”是判断所做的的需求工作是否有意义的标准。

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

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

5-11 “说人话”的正确用例

是否存在“管理××”用例呢?有的,但这样的用例往往是给系统管理员管理基本数据用的,而且都是千篇一律,不必花太多心思在上面。我们只要老老实实做业务建模,老老实实从业务流程映射系统用例。有一些用例无法从业务流程中映射,但系统需要它们来支撑,例如:系统管理员→管理系统用户,新系统尚未引入之前,业务流程中不会存在系统管理员这样一个业务工人。对于这种用于支撑的管理基本数据的用例,才用“管理××”来打扫战场,例如图5-12

5-12 管理××用例

软件工程和计算机科学的关键区别在于人。软件是为人开发的,所以我们要做需求;软件是由人开发的,所以我们要做设计。考虑到人的因素,软件工程更接近于经济学,而非计算机科学。本书的目标读者是软件开发人员,所做的工作中软件工程的成分要比计算机科学的成分大。

现在的大学计算机教育,基本还是以教授计算机科学为主,所教的软件工程仅是聊胜于无。这本来也没什么问题,毕竟象牙塔里的教授要教出好的软件工程也不容易,开发人员还是要在业界历练学习。不过,因为软件工程看起来没有计算机科学那么“深奥”,开发人员常会误认为只要掌握了计算机科学的基本知识,软件工程就是手到擒来。其实,这是两个不同领域的知识。

事实上,以我所见所闻,研究计算机科学某个领域多年,一张口仍然是“软件工程盲”的情况,并不鲜见,既有名校教授,也有著名跨国IT公司研究院资深人员。同样作为一名软件工程的研究者,我没有贬低计算机科学研究的意思,只是稍作提醒其中的区别。这中间的区别不清,会造成一些开发人员对“底层”的迷恋。

某开发人员喜欢钻研“底层”,明明分配给他的工作是编写一段计费的C#代码,他偏偏要花时间深入研究到编译器、操作系统甚至硬件,而且确实也搞清楚了一些门道。虽然工作是耽搁了,但该开发人员却获得了“勤奋好钻研”的名声。如果他擅长写博客或微博,很可能会受到粉丝们的崇拜。

软件开发还有另一个更值得钻研的“底层”:怎样才能使这段代码更容易维护和扩展?这段代码达到的功能和性能对涉众意味着什么?……过分热衷于钻研“底层”,这样的行为更像是偷懒而不是勤奋,毕竟比起离开电脑去搞清楚质管部和生产部之间有什么利益上的冲突,研究MSIL的语法要容易得多,愉快得多。

所谓“底层”也只是另一个领域的知识,那个领域自有另外的人去研究。玩票式的钻研,在真正专注研究这个领域的研究者看来,实在是不值一提。但是人性的弱点如此,正如钱钟书所说:“人和蝙蝠不同,人喜欢在兽群里当鸟,在鸟群里作兽。”

5-13 另一个更深不可测的“底层”——藏在涉众心底里的各种希望和担心

5.4 【需求步骤2-2】识别系统用例

业务序列图中,从外部指向所研究系统的消息,可以映射为该系统的用例。还是以图5-3的业务序列图为例。

5-14 从图5-3映射得到的监狱系统用例图

5-14的用例图中,有的箭头是从执行者指向用例,这样的执行者称为用例的主执行者,有的箭头是从用例指向执行者,这样的执行者称为用例的辅执行者。主执行者主动发起用例的交互,辅执行者在交互的过程中被动参与进来,但是,这两者都是达到用例的目标所需要的。例如图5-14中,如果指纹采集仪坏掉了,采集犯人指纹的用例就不能成功,只不过这个用例不是指纹采集仪首先发起而已。UML标准中,执行者和用例之间没有要求使用箭头,但我认为加上箭头表示主辅执行者是有意义的。

关于辅执行者,最常见的误用是把箭头误解成数据传送的方向,例如,电网调度系统有这么一个用例,每隔一个时间周期,系统会显示实时拓扑图给调度人员看。建模人员就认为既然“系统显示给调度人员看”,应该画一个箭头指向调度人员,就像有一道光线从电脑屏幕射向调度人员的眼睛。于是得到下图:

5-15 辅执行者的误用

这样的做法是错的。图5-15的意思是如果时间要引发系统显示拓扑图,需要调度人员帮忙,实际并非如此,调度人员睡着了或者因突发心脏病倒下,不影响系统按照时间周期不断显示拓扑图。

5-16的辅助执行者是正确的:

5-16 合适的辅执行者

营业员使用营业受理系统为储户转账,在用例交互过程中,需要储户配合输入账户密码,否则转账用例不能成功,所以储户是合适的辅执行者。一般来说,辅执行者是人肉系统(例如图5-16中的储户)的情况比较少,更多情况下,辅执行者是另一个非人智能系统。

主辅执行者是针对某个用例来说的,一个系统在这个用例充当主执行者,也可以在另一个用例充当辅执行者。“××是系统的主(辅)执行者”的说法是错误的。

1. 主执行者和辅执行者的区别是

 A) 主执行者直接和系统交互,辅执行者间接和系统交互

 B) 主执行者发起用例,辅执行者被动参与

 C) 主执行者发送数据,辅执行者接收数据

 D) 主执行者出现在用例图上,辅执行者不出现在用例图上

 E) 主执行者是人,辅执行者不是人

 F) 主执行者有用例,辅执行者没有用例

2. 根据以下业务序列图,请问属于“一卡通系统”用例的是(可以多选)

 A) 外来办事人员→登记

 B) 一卡通系统判断黑名单

 C) 大院门口保安记录来访人员信息

 D) 受访人确认来访

 E) 来车监控系统保存车牌信息

 F) 时间检查是否来车

3. 以下用例图的错误应该如何改正?

 

 A) 提交维修单信息是客服的责任,应该删掉

 B) <<include>>箭头方向反过来

 C) 右边四个只是步骤不是用例,删掉

 D) 标出各用例的先后顺序

 E) <<include>>改成<<extend>>

 F) 将右边四个放在下一层次用例包中

 

 

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

 

 

 

5.5 用例的进一步讲解

5.5.1 错误:玩弄“复用”

前面提到的CRUD实际上就是“复用”用例的一种情况。再看下面的例子:

5-17 “复用”用例错误示例——缺陷管理系统

从业务序列图应该得到右边的四个用例,但有的开发人员会动起心思:这些实现起来不都是针对“缺陷”表来“Select ××× from 缺陷 where ×××”吗,合并成一个用例“检索缺陷”多好!于是得到左边的结果。实际上,右边这四个用例面对的执行者不同,背后的涉众利益也有差别。

用例是涉众愿意“购买”的、对系统的一种“用法”,只要涉众愿意“购买”,当然是越多越好。同样的制作材料,变出更多可卖的功能,说明您的设计能力强,制作成本低,何乐而不为?可惜开发人员经常会犯傻,不自觉地合并用例,相当于告诉涉众说,你真笨,你买我这些功能,其实我只用了同样几个类灵活组装出来。干脆,你成本价把我的零件买走,自己去组装吧!顾客不乐意买,因为他有其他事情要忙。开发人员也赚不到钱。

说到这里,可能有人就会说了:哇,这样用例岂不是很多?如果说真的按照“卖”的思路去找,确实是这么多,那是好事还是坏事?好事来着!说明您用少数的材料(成本)组装出了很多可以“卖”的价值。事实上,往往用例的大量膨胀根本不是因为这个,而是因为开发人员把很多不是用例的步骤当成用例画出来了!

害怕用例多了会导致工作量大增,背后可能隐藏着这样的问题:开发人员的设计能力太弱。做设计时只是把需求直通通地映射,缺乏抽象能力,当然会害怕用例变多了。开发人员没有掌握有序、系统地抽象的能力,当发现“此处似乎可以抽象”时,迫不及待想露一手,因为他害怕此时不露一手,没准以后露一手的能力和机会就消失了。这和小孩刚学习一个新东西,什么地方都想表现一下是类似的。

讲到这里,有必要再重申本书开始时的内容:


 

利润=需求-设计

需求

设计

卖的视角

做的视角

具体

抽象

产品当项目做

项目当产品做

设计源于需求,高于需求

我去面馆就餐,点了一碗馄饨。过了一会,老板端来一碗饺子。我说,“老板,这是饺子,不是馄饨!”老板还嘲笑我,“笨,饺子和馄饨98%是一样的,都是面粉和肉菜的组合,你就将就着吃吧,你们这些刁嘴顾客,一会饺子一会馄饨一会锅贴的,你不怕我累着了?要不你自己到厨房去,材料都在那里,想吃什么自己做!”老板可以把饺子拿回去,经过快速分解,重新组合,变出馄饨卖给我,但不能让我闭着眼睛把饺子当成馄饨吃下去。

面馆老板的赚钱之道就是用少量的材料(设计组件)灵活组合出不同的需求(用例)卖给不同的顾客。同样是以面粉、肉、菜为主原料,面馆就可以做出许多的“用例”:馒头、包子、花卷、烧饼、饺子、馄饨、锅贴、烧麦、春卷、油条、发糕……拉面、刀削面、擀面、擦面、哨子面、扯面、油泼面、担担面、拌面、焖面、面疙瘩、揪面片、手擀面、拉条子、炒面……臊子面、沙茶面、茄丁面、酸菜面、鸡蛋面、虾仁面、牛肉面……。

从图5-18的肯德基菜单中,您能看出设计和需求的奥妙吗?

 

5-18 从肯德基的菜单思考其中的需求和设计

需求是不考虑“复用”的,如果在考虑“复用”,要警惕自己是不是已经转换到了设计视角来思考问题。

类似的错例还有:因为都参与了退货的流程,干脆共用一个用例“退货”,如5-19

5-19 “复用”用例的错误

正确的用例图如图5-20

5-20 正确的用例图

因为最终结果都是导致数据库的“保单”表里增加一行,干脆共用一个用例“新增保单”,如图5-21

5-21 “复用”用例的错误

正确的用例图如图5-22

5-22 正确的用例图

退货例子中的错误还比较好避免,保单例子中的错误却是非常容易犯的。从“卖”的角度来看,这是系统的三种不同用法,背后的涉众利益也不同。客户在家里通过网络投保,操心的是“可别上当”;客户代表录入自己代理的客户的保单时,操心的是“佣金要高”;内勤面对堆积如山的待录入保单,操心的是“省力一点”。这些不同,不能用“都是往数据库的保单表里插入一条记录啊”这样的理由合并。

5-17、图5-19、图5-21的错误用例图有一个共同点:多个主执行者指向同一个用例,从这样的形状我们就可以判断出此图有问题。如果已完工的用例图出现这样的形状,可以有两种修改方法。如果我们揣摩系统的这个用例针对这几个执行者来说并无区别,就泛化出抽象的执行者,或者不需要泛化关系,直接用单个更合适的主执行者代替;反之,如果对不同执行者来说有区别,就把该用例分成几个不同的用例。后一种往往更常见。

如果对此有疑问,您可能需要复习本章前面部分的内容,以及第二章的内容。系统的功能要“为他且只为他”而做,才能卖得出去。

5-23 出现多主执行者时的修改

5.5.2 错误:玩弄“层次”

像医院信息系统的用例,有人会画成这样:

5-24 错误的“高层”用例,偷换了研究对象

其实这个“层次”是建模人员头脑里不知不觉偷换了研究对象,把“医院系统”的契约和“医院”的契约混在一起了。

再看下面防汛系统的错例:

5-25 错误的“高层”用例,把愿望当成功能

“提高防汛决策准确度”只是某类涉众(领导)希望系统给组织带来的改进愿望,就像储户希望取款机“操作方便”一样,不是系统的一个功能。系统没有提供这样一个功能,领导输入一个准确度,提交,唰的一下,防汛决策准确度就提高了。

5.5.3 错误:玩弄“子系统”

这种错误的特征是把用例分到许多个包,每个包命名为“某某子系统”或“某某模块”,如图5-26所示。

5-26 错误的“子系统”用例

用例很多时,可以将用例分包,但用例包是从外部对系统功能所做的分包,和子系统的概念是不一样的,子系统是根据内部部件的耦合和内聚切割得到。打开这样的“子系统”用例包,往往会发现里面的用例其实是步骤,甚至是某个类的操作。

5-27展示了从内外两个角度分割系统的区别。我们可以说吃喝拉撒是“人”的功能,但不能说是 “人的吃喝拉撒子系统”的功能。

5-27 内外分割的区别

5.5.4 错误:模糊的价值

研究对象是一个人事系统,员工先通过系统交请假单,主管使用系统批假,然后人事部专员使用系统备案。5-28是正确的:

5-28 人事系统的用例,三个用例

但有时候开发人员会觉得,哎呀,没请到假,怎么能算价值呢,用例图应该是这样才对:

 

5-29 人事系统的用例,一个用例

这个时候,业务序列图可以帮我们理清楚:

5-30 从业务序列图看清系统责任

从图5-30可以看出,人事系统只能向员工承诺“你把请假单交给我,我要是没保存好,你可以骂我”,员工不能指望仅仅和人事系统打交道就能请到假,这个价值是由【人事系统+主管+人事部专员】一起提供的。如果业务序列图像图5-31这样,结果就不一样了,图5-29的用例图变成正确的,因为人事系统确实可以为员工提供请假的价值。

5-31 人事系统能自己批假

或者换一个研究对象,研究虚构的组织——“请假部”,结果也不一样:

5-32 研究对象改变,用例也随之而变

可能还会有人会画成下面这样,把主管和人事部专员画成辅助执行者。

5-33 一个用例,执行者一主二辅

这样画也是不对的。员工和人事系统交互时,心中没有这样的期待:我要等着人事系统找主管和人事专员帮忙,得到批假结果再离开。这和5-16是不一样的,图5-16中,营业员等待着储户输密码,如果储户不输密码,营业员结束交互没有意义。

5.5.5 提示:大用例无妨小用例

针对不同执行者、不同业务流程,系统提供的价值可大可小,大的是用例,不妨碍小的也是用例,只要是从涉众的视角得到的。下图是可以的。

5-34 大用例无妨小用例

5.5.6 提示:用例的命名

用例的命名是动宾结构,例如“取款”。动词前面可以加状语,宾语前面可以加定语,把一句话的主语砍掉,剩下的可以作为用例的名字。

用例之前的需求技术,有的可能是以“名字+动词”的形式命名系统的功能,例如“发票作废”,后来要改成用例的动宾结构了,开发人员就在前面加一个弱动词“进行”,就变成了“进行发票作废”,这个也是不合适的。

5-35 用例命名当心弱动词

如果“名词+动词”已经成为行业中的一个术语,也未必要严格的动宾结构。例如“成果分析”在某行业是一个术语,也就不必硬要倒过来变成“分析成果”了。

1. 某城市目前工商、国税、地税、质监部门都有自己的系统,但相互信息不联通,经常出现漏管户和偷逃税情况。市政府打算开发一个基础信息交换系统,系统的目标是通过各部门的企业数据之间的比对,发现数据差异,减少漏管户,防止偷逃税。工商、国税、地税、质监各部门人员使用自己的系统录入企业数据,每个月末,市政府专人会给基础信息交换系统发送一个比对命令,基础信息交换系统会从各部门业务系统把各部门本月的企业数据导入,进行比对,然后给各部门业务系统返回结果。请问:以下哪些用例属于“基础信息交换系统”的用例集?

 A)

 

 B)

 C)

 

 D)

 

2. 以下形状中,哪些是已完成的、正确的用例图可以出现的:

A)        B)

 C)   D)

 

 

 

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player


 


5.6 案例

UMLChina系统的第一批用例可以从业务序列图图4-68映射出来。

5-36 UMLChina系统第一批用例

5.7 工具操作

【步骤1】展开2-需求包下的系统用例包,双击系统用例用例图,出现空白的系统用例图。

5-37 空白的系统用例图

【步骤2】点击工具箱中的,再点击图的顶部中间,在弹出的属性框中输入UMLChina系统,点击OK。拖动边界框的边调整到合适的大小。

5-38 放置边界框

【步骤3】点击工具箱中的,点击边界框的左侧,在弹出属性框的Name栏输入公司助理,点击确定

5-39 添加系统执行者

【步骤4】用同样的方法,继续添加执行者时间

5-40 UMLChina系统的执行者

【步骤5】点击工具箱中的,点击边界框内,在弹出属性框中的Name栏输入为公开课创建通知任务,点击确定

5-41 放置系统用例

【步骤6】用同样的方法,继续添加用例执行通知任务

5-42 继续添加用例

【步骤7】按住公司助理执行者右侧的小箭头(Quick Link),拖到为公开课创建通知任务用例上,松开鼠标按键,从快捷菜单中选择Association

5-43 建立执行者和用例之间的关联

【步骤8】双击执行者和用例之间的关联线,在弹出属性框的Direction选择框中选择SourceDestination

5-44 设置关联线的方向

【步骤9】同样,在执行者时间和用例执行通知任务之间建立关联,并设置关联方向为时间指向执行通知任务

5-45 完成系统用例图

【步骤10】点击用例为公开课创建通知任务,按F2键,将鼠标光标置于“建”字后,在按住Ctrl的情况下,按回车键,可以看到用例名称分成两行

5-46 将长用例名折行

5.8 总结

用例的背后是市场经济的思想。在市场经济中,商品的价格是由供求关系决定的,和成本并没有必然的关系。人们可以出于自己的个人意愿以任何价格交易,不存在一个绝对正确的标准来裁定交易是否合理。