绘制用例图学习.pptx

《绘制用例图学习.pptx》由会员分享，可在线阅读，更多相关《绘制用例图学习.pptx（64页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、理解需求什么是需求？系统必须提供的能力和必须遵从的条件需求工作的最根本挑战在于：如何去发现、交流并记住（即记录）什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解这个过程的最大难题是如何使得需求的定义没有二义性第1页/共64页理解需求（续）需求管理推崇用“一种条理化的方法寻找、记录、组织和跟踪系统不断变化的需求”第2页/共64页影响软件项目的因素其它50%其它50%不充分的用户输入13%不完整需求12%变更需求12%技术技能不足7%员工不足6%第3页/共64页用例到底用在哪？WhatHowDo用例图用例描述第4页/共64页“用例”先睹为快用例图记录预约取消预约显示预约接待员 记录预约到达

2、记录未预约到达前台调换餐桌领班餐饮管理系统第5页/共64页“用例”先睹为快用例描述第6页/共64页用例建模 基本概念用例视图是UML中起着支配作用的视图，描述的系统外部可见的行为基于系统需求的用例视图驱动和约束着后续的开发用例视图展示的是系统功能的结构化视图，视图定义了参与者和参与者可以参与的用例第7页/共64页用例图以图解的形式概括了系统中不同参与者和用例，并显示了哪些参与者能够参与哪些用例参与者用一个像人一样的图标表示用例用包含有用例名字的椭圆表示UML允许在用例图中包含更多的结构，来定义用例之间以及参与者之间的各种关系在实践中不值得花费很多时间细化用例图，额外的关系对后面的开发起不到很大

3、作用第8页/共64页用例图参与者模型化了用户与系统进行交互时可能充当的角色用例描述了用户使用系统能够完成一项特定的任务参与者用例第9页/共64页绘制用例图1.确立系统边界需要的留下，不需要的剁掉第10页/共64页确立系统边界分内外，向系统内找用例，向系统外找参与者。1.找出位于系统外部的事物，画小人2.找出系统内部的事物，画椭圆参与者用例第11页/共64页找参与者一个用例描述了系统及其用户之间的一类交互系统通常有不同种类的用户，他们能够执行系统功能的不同子集用户与系统在进行交互时能够担任的不同角色称为参与者第12页/共64页参与者：代表了与系统交互的事物定义：是系统外部的一个实体，它以某种方式

4、参与了用例的执行过程。参与者可以是：人担当的角色、计算机系统、机械或者电子设备；参与者由他们参与用例时所担当的角色来代表，例如，顾客。一个参与者并不时指一个特定的人或一个特定的实体 某个参与者可被认为是一个有形的、与系统交互的、扮演某种角色的外部实体第13页/共64页张三李四注意：顾客角色第14页/共64页为什么要定义参与者？某个特定参与者初始化某个用例的原因几乎总是为什么需要该用例的主要原因参与者在环境中的角色和其独一无二的行为及其系统职责会对用例产生重要的影响个体客户商业客户？第15页/共64页为什么不先找用例？第16页/共64页先找参与者的原因参与者比用例明显参与者的个数远比用例的个数少

5、找到一个参与者，就可以找到一堆用例参与者是系统外部人物的代表，所以是先找出参与者，才能够从参与者的角度去寻找用例。第17页/共64页先找参与者的原因(续)关注参与者，就能将注意力集中于如何使用系统而不是如何创建或实现系统。参与者还决定了系统需求的完整性第18页/共64页如何确定参与者谁或什么将初始化与系统有关的事件谁或什么与系统交互将有助于系统对某个事件做出响应有报告界面吗？有系统管理界面吗？系统需要与其他遗留系统交互吗？是否已定义过该系统的参与者？如果系统中发生了一个事件，是否需要通知某个外部实体？系统是否需要与外部实体交互以帮助自己完成任务？第19页/共64页参与者一定是直接并且主动向系统

6、发出动作并获得反馈的,否则就不是参与者.第20页/共64页案例2：谁是参与者？小王到银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折，在这个场景中，谁是参与者？小王？柜台职员？大厅经理？第21页/共64页案例2（续）谁对系统有着明确的目标和要求并且主动发出动作？系统是为谁服务的？小王主角主要参与者主动参与者第22页/共64页案例三:机票预订系统1.机票购买者通过登录网站购买机票-机票购买者就是参与者第23页/共64页有趣的问题：哪个参与者启动了用例？有时候，一个用例是由一个并不与系统实际进行物理交互的实体的需求所触发。业务参与者系统参与者业务用例建模系统用例建模第2

7、4页/共64页案例三:机票预订系统(续)2.假如机票购买者通过呼叫中心,由人工座席操作订票系统购买机票-人工座席是系统参与者-机票购买者是呼叫中心的参与者第25页/共64页案例三:机票预订系统(续)3.如果机票购买者通过呼叫中心的自动语音预订机票而不是通过人工座席呢?业务参与者系统参与者第26页/共64页案例三:机票预订系统(续)4.如果扩大系统边界,让呼叫中心称为机票预订系统的一个子系统,并且夹着机票购买者可以自主选择通过人工座席,自动语音还是网站预订机票呢?业务工人第27页/共64页如何区分参与者还是工人呢?人工座席属于哪一类?第28页/共64页参与者的角色角色类型行为启动者初始化用例外部

8、服务者在用例中向系统提供服务接收者从用例接收信息帮助者（代理,业务工人）为其他参与者与系统的交互提供帮助第29页/共64页用例建模用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的第30页/共64页用例就是需求F第31页/共64页关键问题用例分析的关键是专注于“怎样才能使系统为用户提供可观察的数值，或帮助用户实现他们的目标，而不是简单认为系统需求就是列举系统的特征和功能”第32页/共64页黑箱用例描述系统具有哪些职责做什么第33页/共64页用例特

9、征用例是相对独立的用例的执行结构对参与者来说是可观测和有意义的第34页/共64页用例的获得用例准备工作：发现参与者第35页/共64页用例的获得（续）引导业务代表来获取用例：您对系统有什么期望您打算在这个系统里做些什么事情您做这件事的目的是什么？您做完这件事希望有一个什么样的结果？第36页/共64页用例的获得（续）P19 表1-9用例的问题列表如果我们是“顾客”，我们会怎么使用系统？什么时候我们会开始使用系统？画流程，看看顾客使用系统的流程，然后再来核对，看看需要增加什么用例第37页/共64页UML活动图第38页/共64页注意，画UML活动图只是为了辅助我们抓用例，所以不要陷入细节中。第39页/

10、共64页用例的目标和范围发现用例确定用例的目标和范围用例应该在什么级别和范围上表述呢？第40页/共64页怎样发现用例？l谈判一个供货合同l处理返回值l登录l在游戏板上移动棋子是否是有效的用例?n可以认为这些都是用例，但它们处于不同的级别，依赖于系统边界、参与者和目标。n与其泛泛地问“什么是有效的用例？”，不如更直接地问：“对应用的需求分析来说，在什么级别上描述用例最有帮助？第41页/共64页测试用例老板测试规模测试测试第42页/共64页测试用例（续）老板测试用例的执行结构对参与者来说是可观测和有意义的如果该用例不同通过老板测试，这意味着该用例与达到可量化价值的结果没有太大关系“也许是更低级别的

11、用例”登录填写取款单第43页/共64页测试用例（续）规模测试用例很少由单独的活动或步骤组成在游戏板上移动棋子输入商品编号第44页/共64页测试用例（续）EBP指导原则EBP用例：对计算机应用进行需求分析的时候，应关注于“基本业务过程”(EBP)级别的用例一个主要成功场景会包含5-10个小步骤用例也不是一个需要好几天和很多对话才能完成的工作它是能够在一个对话、几分钟或一个小时的时间内就可以完成的任务。用例强调了能够增加可见的或可度量的业务价值第45页/共64页EBP级别上的用例一个EBP级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户来实现自己的目标找出用户的目标为每

12、个目标定义一个用例你想做什么？你的目标是什么？解决方案和过程激发新的、改进方案的想象增加可见的或可以度量的业务价值第46页/共64页对EBP原则的合理违反 尽管一个应用的“基本”用例应该满足EBP原则，但我们经常会创建一些单独的“子”用例来表示基本用例中的子任务或步骤。用例有时候不必符合EBP原则。EBP的指导原则只在对应用进行需求分析时用来寻找主要用例，也即命名、写出主要用例。例子:“信用卡支付”。第47页/共64页第48页/共64页用例的其他特征必须由一个参与者发起用例必须以动宾形式出现的一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元和部署单元ATM吐钞统计喝第49页/共

13、64页用例的粒度用例的粒度以每个用例能够说明一件完整的事情为宜或者说，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜例：某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前的借阅记录以确保没有未归还的书，最后借到了书。从这段话中能够得出多少个用例呢？借书第50页/共64页用例的粒度（续）例：主角说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳电话费、水费、电费等费用；为了安全起见，ATM应当有警示小心骗子的提示条，还有摄像头例如过输入三次密码错

14、误，卡片应当被自动吞没第51页/共64页用例的获得（续）这些是有效的用例吗？第52页/共64页误区一：用例是功能的划分和描述软件是一种还不存在的事物，对于正准备开发的软件，我们不能从结构观点去描述它，也不能从功能观点去描述它，最好的方法就是从使用者的观点去描述它。功能性观点和结构性观点，则可以通过使用者观点推导出来。第53页/共64页误区一：（续）例，对电视的描述从功能的角度：开关、显示、调频道、调声音。从用例角度：观看电视节目：打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下。第54页/共64页误区二：目标和完成目标的步骤一个用例是参与者对目标系统的一个愿望，一个完整的事件。完成一

15、个完整的事件需要经由很多步骤，但这些步骤不能够完整的反映参与者的目标，不能够作为用例。第55页/共64页误区二：（续）例：去邮局寄信第56页/共64页例如：对于销售点终端系统来说，一些可能的参与者和他们发起的过程有：参与者事件 销售员登陆用现金结算顾客购买商品退还商品第57页/共64页通过事件分析找出参与者和目标确定外部事件有哪些事件，从哪儿产生，为了什么？外部事件产生自哪个参与者目标输入单件商品收银员处理销售输入支付信息收银员或顾客处理销售第58页/共64页确定用例EBP级别的用例一个好的用例为参与者产生一种可以估量的价值结果描述参与者想要系统完成的事情第59页/共64页 用例一组用例是一个

16、系统的用户能够使用系统完成的不同任务可以通过考虑在系统实现后参与者能够用它来做什么，简单地草拟出这次迭代的一组初步的用例第60页/共64页定义用例时的一些经验命名用例的时候以动词开头每个用户目标有一个用例例外：CRUD创建搜索更新删除管理第61页/共64页简单用例图购买商品登 陆退还商品收银员顾客用例图显示了系统的一组用例，用例的参与者以及用例和参与者之间的关系。第62页/共64页例如，对于销售点终端系统，当分别以“商店”和“销售点终端的软件系统”作为系统边界时，得到的用例图如下：购买商品登陆退还商品POS图1、当以POS作为系统边界时的用例与参与者购买商品退还商品商店图2、当以商店作为系统边界时的用例与参与者出纳员顾客顾客库存系统外部记账系统外部记账系统第63页/共64页感谢您的观看。第64页/共64页