《需求之系统用例.ppt》由会员分享，可在线阅读，更多相关《需求之系统用例.ppt（59页珍藏版）》请在三一办公上搜索。
1、需求之系统用例图（System use case）,2023年9月,2,系统执行者要点,系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统。系统外。系统执行者不是所研究系统的一部分，是该系统边界外的一个系统。要正确理解这里的系统边界：不是物理的边界，而是责任的边界。不能说运行在同一台电脑中，共享内存和硬盘，就是同一个系统。交互。系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者。一名旅客来到火车票售票点，告诉售票员目的地和车次，售票员使用售票系统打出火车票。这个场景中，和火车票售票系统交互的是售票员，他/她是售票系统的执行者，旅客不是。,3,系统执行者要点,系统执行者
2、和重要无关。系统执行者只关注谁和这个系统接口，不关心这个谁是重要人物，还是非重要人物，甚至有的执行者不是人，是另一个电脑系统，更谈不上重不重要了。从平时的工作和生活经验我们也可以知道，当系统执行者当得最欢，整天和电脑打交道的人，往往是一线的打工仔（营业员、办事员、客服.），真正重要的人物会整天坐在电脑前面摸键盘弄鼠标吗？虽然偶尔也会用系统看看报表，但更多时间是摸高尔夫球杆吧？,4,涉众的利益,旅客担心出错票，更担心拿到了错票自己还不察觉；担心票是打出来了，信息却没有传到后头；担心指定日期没那个车次的票售票点老板担心售票员玩忽职守，出错影响声誉；担心售票员匿旅客的钱，出假票，然后拿钱开溜售票员担
3、心操作太复杂，一天下来手指麻木；担心不好用，出错票被老板扣钱火车站担心重复出票造成纠纷,5,旅客成为系统执行者,如果火车票售票系统提供旅客购票的接口，例如互联网购票、售票机等，旅客可以自行和这些系统交互来达到购票的目的，这个时候旅客就成了系统执行者。“售票员-售票”和“旅客-购票”是两个不同的用例，重点关注的涉众利益不同，相应的需求自然也不同。和旅客打交道的用例，交互可以生动一点，节奏可以慢一点，甚至可以卖卖广告，还要特别注意容量、安全等问题；和售票员打交道的用例，交互应该直截了当，甚至连鼠标都不要用。,6,功能性交互,售票员是使用键盘鼠标和售票系统交互的，按道理，比起售票员来，鼠标离售票系统
4、更近，为什么不把鼠标作为售票系统的执行者呢？还有，假设售票系统运行在Windows操作系统之上，那么Windows是不是售票系统的执行者？,7,功能性交互,执行者和系统发生的交互是系统的功能需求。一个人能自如地控制鼠标，猴子则做不到，是因为人脑里安装了如何使用鼠标的专家系统，可能是他父母安装的，也可能是他老师安装的。鼠标的移动如何变成屏幕上的信号，是由鼠标驱动程序负责的，这些都不是售票系统关注的核心领域，售票系统关注的是售票员和售票系统之间的交互，所以售票员才是售票系统的执行者。,系统,系统可以是一个人肉系统，也可以是一个智能系统，甚至是一个特别的外系统时间。在软件业的早期，一个系统的执行者往
5、往全部都是人。随着时间的推移，系统的执行者中非人执行者越来越多。,8,9,【需求步骤2-1】识别系统执行者,10,【需求步骤2-1】识别系统执行者,11,不要把执行者和权限管理混淆,用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。微信的“摇一摇”，是为年轻人提供的，但没有权限控制要先“登录并获得年轻人权限”才能使用，只是在考虑这个用例包含的各种需求时，要多考虑年轻人的利益。,12,不要把执行者和权限管理混淆,“用户”这个词还是懒惰的表现，这个功能给谁用？给用户用。这样的回答，和“东西卖给消费者”一样，是正确而无用的废话。所以在
6、给执行者命名时，尽量不要使用“用户”这个词，而是使用具体的执行者名称：储户、顾客、科长、验质员、检斤员。当然，设计时尽可以抽象出“用户”这样的超类，这样许多特征都可以复用，但做需求时是不考虑复用的。,13,不要把执行者和权限管理混淆,14,练习(exercises),1.以类似_这样的系统为研究对象时，“打印机”作为执行者是合适的。A)WordB)财务报表系统C)PhotoshopD)打印管理器E)OA 系统F)PowerPoint,15,练习(exercises),2.市民想给交通卡充值，来到营业点把钱和卡一起递给营业员，营业员操作“充值系统”充值。针对“充值系统”的执行者，以下看法正确的是
7、A)执行者应是市民，因为市民比营业员重要。B)执行者应是营业员，因为营业员比市民重要C)执行者应是市民，毕竟营业员最终执行的是市民的指令D)执行者应该是充值系统，因为充值由充值系统完成E)执行者应该是营业员，系统执行者与重要无关F)市民和营业员一起作为执行者,16,练习(exercises),3.以下说法不正确的是（多选）：A)业务执行者一定是系统执行者B)系统执行者一定是业务执行者C)系统执行者一定是业务工人D)系统执行者一定要和系统交互E)系统执行者一定是系统的涉众F)系统的涉众一定是系统执行者,17,系统用例要点,系统用例的定义：系统能够为执行者提供的，涉众可以接受的价值。用例可以看作执
8、行者和系统之间买卖的平衡点，期望和承诺的平衡点。还是以被说滥了的取款机为例。储户来到取款机面前，插卡输密码，拿到两百元后，到隔壁投注站买了10 张福彩刮刮乐即开彩票，哇噻，中奖五万元。那么，取款机的用例到底是什么，“登录”、“取款”还是“中奖”？或者说“都对，从辩证的角度看嘛”？,18,系统用例要点,“登录”不是取款机的用例，因为取款机不能这么叫卖自己：“来啊来啊！我这里能登录啊”，然后储户就说，“哇，真棒，这正是我想要取款机提供的服务，好，我去用一用”。储户对取款机的期望可不止这么多。“中奖”也不是取款机的用例，储户倒是很想从取款机那里得到这个服务，可惜，取款机没法承诺。“取款”才是取款机能
9、承诺，而且储户乐意因此而使用取款机的服务。,19,系统用例要点,用例之前的许多需求方法学，把需求定义为思考系统“做”什么，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。对于仍然习惯用学生思维思考、喜欢背标准答案的开发人员，思考“什么是系统的价值”有时甚至会让他痛苦到想要逃避，或者干脆用模糊不清的功能、特性等词语代替。,20,系统用例要点,人们求职、求偶、求*.不就是要搞清楚“我”这个人肉系统到底应该卖给谁，卖什么服务的最佳答案吗？我想卖给你的你不要，你想买的我又没有，就是人生的痛苦所在。许多时候，我们象没头苍蝇一样投简历、相亲，却不舍得抽出时
10、间静下来思考“价值”的问题。,21,系统用例要点,“程序员”这个人肉系统为老板提供的用例是什么？安装开发工具？编码？为公司赚钱？编码，这是老板对程序员的期望以及程序员可以提供的承诺的平衡点，或者说，这是程序员能卖，老板愿意买的价值。程序员不能因为装了个VisualStudio 就理直气壮向老板要报酬，老板不给就生气；程序员按要求编出了代码，老板就不能因为销售部门不给力导致软件卖不出去赚不到钱而责怪程序员。,22,系统用例要点,程序员如果摆错了自己的位置，没有好好完成本职工作，反倒是向老板上“万言书”，对公司的发展方向大放厥词，指手画脚，老板是不会喜欢的，因为他不期望从程序员身上“购买”这个服务
11、（用某知名企业领导人的话说就是：有精神病就送医院，没精神病就辞退）。可见，搞清楚自己的“用例”，认清自己的定位，对人生多么重要。当然，随着时间的发展，人肉系统可以不断升级，淘汰旧的用例，开发新的用例。,23,系统用例要点,思考用例的过程就是发现价值的过程。如果您不断通过用例思维来思考系统的需求，就能训练出越来越强大的发现价值的能力。无论打工还是创业，这种发现价值的能力是非常有帮助的。用例思维可以让您终身受益。,24,练习(exercises),1.以_这样的系统为研究对象时，“登录”作为用例是合适的A)ERPB)电子商务网站如淘宝C)取款机D)门禁E)OA 系统F)指纹扫描仪,25,练习(ex
12、ercises),2.以_这样的系统为研究对象时，“输入密码”作为用例是合适的A)密码保险箱B)电子商务网站如淘宝C)取款机D)门禁E)OA 系统F)指纹扫描仪,26,最常犯的错误是：把步骤当作用例。,27,CRUD 问题,28,CRUD 问题,乍一看好像也可以理解。不管前面的业务多复杂，到数据库这一层，不都是新增修改删除查询吗？有位开发人员和我说过，“潘老师，我找到了抑制需求变更的好方法，把数据库的表当成需求不就行了吗？业务变来变去，数据库的表是相对稳定的。”我还见到过这样的信息系统：在界面上把所有的“新增”功能都放在一起，根本不管这些功能是给不同的人在不同时间和不同业务流程中使用的。开发人
13、员肯定想“反正都是数据库里新增一条记录嘛”。,29,CRUD 问题,问题在于：做需求的目的不是为了安慰自己或走过场，而是让产品更加好卖。不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，不能贪图方便选择一个自己熟悉的视角应付了事。如果允许应付了事，我还有更好的绝招：我就是程序，程序就是我。你问我，某某系统的需求是什么？我回答：就是0 和1 的组合。对吗？对得不得了。可惜，这种正确而无用的废话，对做出好卖的系统没有帮助。,30,CRUD 问题,如何避免这样的错误，慢慢学会“说人话”呢？老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的
14、系统用例是不会骗人的。新增、修改、删除、查询、管理、改变状态.这些词是数据库（或面向对象）里的“鸟语”，不是领域里的“人话”。业务流程中不会有人说，小张等一下，我到系统哪里去做一下发票管理，只会说，我去开一张发票，我去作废一张发票，我去开一张红字发票.而且，这些事情以不同的频率发生在不同的业务流程中。,31,CRUD 问题,32,【需求步骤2-2】识别系统用例,业务序列图中，从外部指向所研究系统的消息，可以映射为该系统的用例。,33,【需求步骤2-2】识别系统用例,主执行者和辅执行者,上图中有的箭头是从执行者指向用例，这样的执行者称为用例的主执行者，有的箭头是从用例指向执行者，这样的执行者称为
15、用例的辅执行者。主执行者主动发起用例的交互，辅执行者在交互的过程中被动参与进来，但是，这两者都是达到用例的目标所需要的。上图中，如果指纹采集仪坏掉了，采集犯人指纹的用例就不能成功，只不过这个用例不是指纹采集仪首先发起而已。UML 标准中，执行者和用例之间没有要求使用箭头，但我认为加上箭头表示主辅执行者是有意义的。,34,主执行者和辅执行者,关于辅执行者，最常见的误用是把箭头误解成数据传送的方向，例如，在一个电网调度系统有这么一个用例，每隔一个时间周期，系统会显示实时拓扑图给调度人员看。建模人员就认为既然“系统显示给调度人员看”，应该画一个箭头指向调度人员，就像有一道光线从电脑屏幕射向调度人员的
16、眼睛。,35,主执行者和辅执行者,36,主执行者和辅执行者,如果时间要引发系统显示拓扑图，需要调度人员帮忙，实际并非如此，调度人员睡着了或者因突发心脏病倒下，不影响系统按照时间周期不断显示拓扑图。,37,主执行者和辅执行者,38,主执行者和辅执行者,营业员使用营业受理系统为储户转账，在用例交互过程中，需要储户配合输入账户密码，否则转账用例不能成功，所以储户是合适的辅执行者。一般来说，辅执行者是人肉系统（例如图5-6 中的储户）的情况比较少，更多情况下，辅执行者是另一个非人智能系统。,39,玩弄复用,40,玩弄复用,业务序列图应该得到右边的四个用例，但有的开发人员会动起心思：这些实现起来不都是针
17、对“缺陷”表来“Select from 缺陷 where”吗，合并成一个用例“检索缺陷”多好！于是得到左边的结果。实际上，右边这四个用例面对的执行者不同，背后的涉众利益也有差别。,41,玩弄复用,用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。同样的制作材料，变出更多可卖的功能，说明你的设计能力强，制作成本低，何乐而不为？可惜开发人员经常会犯傻，不自觉地合并用例，相当于告诉涉众说，你真笨，你买我这些功能，其实我只用了同样几个类灵活组装出来。干脆，你成本价把我的零件买走，自己去组装吧！顾客不乐意买，开发人员也赚不到钱。,42,玩弄复用,43,玩弄复用,44,
18、玩弄复用,45,玩弄复用,46,玩弄复用,从“卖”的角度来看，这是系统的三种不同用法，背后的涉众利益也不同。客户在家里通过网络投保，操心的是“可别上当”；客户代表录入自己代理的客户的保单时，操心的是“佣金要高”；录单员面对堆积如山的待录入保单，操心的是“省力一点”。这些不同，不能用“都是往数据库的保单表里插入一条记录啊”这样的理由合并。,47,玩弄层次,48,玩弄层次,“高层”实际上是头脑里不知不觉偷换了研究对象，把“医院系统”的契约换成了“医院”的契约。还有下面这个,49,玩弄层次,50,玩弄“子系统”,用例很多时，可以将用例分包，但用例包是从外部对系统功能所做的分包。子系统是根据内部部件的
19、耦合和内聚切割得到。,51,玩弄“子系统”,用例很多时，可以将用例分包，但用例包是从外部对系统功能所做的分包。子系统是根据内部部件的耦合和内聚切割得到。,52,模糊的价值,研究对象是一个人事系统，员工通过系统交请假单，主管使用系统批假，然后人事部专员使用系统备案。,53,模糊的价值,有时候开发人员会觉得，哎呀，没请到假，怎么能算价值呢，用例图应该是这样才对：,54,模糊的价值,人事系统只能向员工承诺“你把请假单交给我，我要是没保存好，你可以骂我”，员工不能指望仅仅和人事系统打交道就能请到假，这个价值是由【人事系统主管人事部专员】一起提供的。,55,模糊的价值,如果业务序列图像下图这样，结果就不一样了，前面图的用例图变成正确的，因为人事系统确实可以为员工提供请假的价值。,56,模糊的价值,或者换一个研究对象，研究虚构的组织“请假部”，结果也不一样：,57,提示：大用例无妨小用例,针对不同执行者、不同业务流程，系统提供的价值可大可小，大的是用例，不妨碍小的也是用例。,58,提示：用例的命名,用例的命名是动宾结构，例如“取款”。动词前面可以加状语，宾语前面可以加定语。用例之前的需求技术，有的可能是以“名字+动词”的形式命名系统的功能，例如“发票作废”，后来要改成用例的动宾结构了，开发人员就在前面加一个弱动词“进行”，就变成了“进行发票作废”，这个也是不合适的。,59,
