《绘制用例》PPT课件.ppt

,系统分析师UML用例实战介绍如何通过用例掌握UML。系统分析师UML用例实战的案例基于Wesley和Richard两个角色叙述，从两人开始接到一个书店系统的项目，到动手建立用例模型，并且应用用例技术来估算工时，系统记述了UML用例的应用方法。,第1章 绘制用例图,系统分析师UML用例实战,理解需求,什么是需求？ 系统必须提供的能力和必须遵从的条件 需求工作的最根本挑战在于：如何去发现、交流并记住（即记录）什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解 这个过程的最大难题是如何使得需求的定义没有二义性,理解需求（续）,需求管理推崇用“一种条理化的方法寻找、记录、组织和跟踪系统不断变化的需求”,影响软件项目的因素,其它50%,其它50%,不充分的用户输入13%,不完整需求 12%,变更需求 12%,技术技能不足 7%,员工不足 6%,用例到底用在哪？,What,How,Do,用例图,用例描述,“用例”先睹为快用例图,记录预约,取消预约,显示预约,接待员,记录预约到达,记录未预约到达,前台,调换餐桌,领班,餐饮管理系统,“用例”先睹为快用例描述,用例建模 基本概念,用例视图是UML中起着支配作用的视图，描述的系统外部可见的行为 基于系统需求的用例视图驱动和约束着后续的开发 用例视图展示的是系统功能的结构化视图，视图定义了参与者和参与者可以参与的用例,用例图,以图解的形式概括了系统中不同参与者和用例，并显示了哪些参与者能够参与哪些用例 参与者用一个像人一样的图标表示 用例用包含有用例名字的椭圆表示 UML允许在用例图中包含更多的结构，来定义用例之间以及参与者之间的各种关系 在实践中不值得花费很多时间细化用例图，额外的关系对后面的开发起不到很大作用,用例图,参与者模型化了用户与系统进行交互时可能充当的角色 用例描述了用户使用系统能够完成一项特定的任务,用例,绘制用例图,确立系统边界 需要的留下，不需要的剁掉,确立系统边界,分内外，向系统内找用例，向系统外找参与者。 找出位于系统外部的事物，画小人 找出系统内部的事物，画椭圆,用例,找参与者,一个用例描述了系统及其用户之间的一类交互 系统通常有不同种类的用户，他们能够执行系统功能的不同子集 用户与系统在进行交互时能够担任的不同角色称为参与者,参与者：代表了与系统交互的事物 定义：是系统外部的一个实体，它以某种方式参与了用例的执行过程。 参与者可以是：人担当的角色、计算机系统、机械或者电子设备； 参与者由他们参与用例时所担当的角色来代表，例如，顾客。 一个参与者并不时指一个特定的人或一个特定的实体,某个参与者可被认为是一个有形的、与系统交互的、扮演某种角色的外部实体,注意：,角色,为什么要定义参与者？,某个特定参与者初始化某个用例的原因几乎总是为什么需要该用例的主要原因 参与者在环境中的角色和其独一无二的行为及其系统职责会对用例产生重要的影响,？,为什么不先找用例？,先找参与者的原因,参与者比用例明显 参与者的个数远比用例的个数少 找到一个参与者，就可以找到一堆用例 参与者是系统外部人物的代表，所以是先找出参与者，才能够从参与者的角度去寻找用例。,先找参与者的原因(续),关注参与者，就能将注意力集中于如何使用系统而不是如何创建或实现系统。 参与者还决定了系统需求的完整性,如何确定参与者,谁或什么将初始化与系统有关的事件 谁或什么与系统交互将有助于系统对某个事件做出响应 有报告界面吗？ 有系统管理界面吗？ 系统需要与其他遗留系统交互吗？ 是否已定义过该系统的参与者？ 如果系统中发生了一个事件，是否需要通知某个外部实体？系统是否需要与外部实体交互以帮助自己完成任务？,参与者一定是直接并且主动向系统发出动作并获得反馈的,否则就不是参与者.,案例2：谁是参与者？,小王到银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折，在这个场景中，谁是参与者？ 小王？ 柜台职员？ 大厅经理？,案例2（续）,谁对系统有着明确的目标和要求并且主动发出动作？ 系统是为谁服务的？,小王,主角,主要参与者,主动参与者,案例三:机票预订系统,1. 机票购买者通过登录网站购买机票 -机票购买者就是参与者,有趣的问题：哪个参与者启动了用例？,有时候，一个用例是由一个并不与系统实际进行物理交互的实体的需求所触发。,业务参与者,系统参与者,业务用例 建模,系统用例 建模,案例三:机票预订系统(续),2. 假如机票购买者通过呼叫中心,由人工座席操作订票系统购买机票 -人工座席是系统参与者 -机票购买者是呼叫中心的参与者,案例三:机票预订系统(续),3.如果机票购买者通过呼叫中心的自动语音预订机票而不是通过人工座席呢?,业务参与者,系统参与者,案例三:机票预订系统(续),4.如果扩大系统边界,让呼叫中心称为机票预订系统的一个子系统,并且夹着机票购买者可以自主选择通过人工座席,自动语音还是网站预订机票呢?,业务工人,如何区分参与者还是工人呢?,人工座席属于哪一类?,参与者的角色,用例建模,用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例 用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的,用例就是需求,F,关键问题,用例分析的关键是专注于“怎样才能使系统为用户提供可观察的数值，或帮助用户实现他们的目标，而不是简单认为系统需求就是列举系统的特征和功能”,黑箱用例,描述系统具有哪些职责,做什么,用例特征,用例是相对独立的 用例的执行结构对参与者来说是可观测和有意义的,用例的获得,用例准备工作：,发现参与者,用例的获得（续）,引导业务代表来获取用例： 您对系统有什么期望 您打算在这个系统里做些什么事情 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？,用例的获得（续）,P19 表1-9用例的问题列表,如果我们是“顾客”，我们会怎么使用系统？什么时候我们会开始使用系统？,画流程，看看顾客使用系统的流程，然后再来核对，看看需要增加什么用例,UML活动图,注意，画UML活动图只是为了辅助我们抓用例，所以不要陷入细节中。,用例的目标和范围,发现用例确定用例的目标和范围 用例应该在什么级别和范围上表述呢？,怎样发现用例？,谈判一个供货合同 处理返回值 登录 在游戏板上移动棋子,是否是有效的用例?,可以认为这些都是用例，但它们处于不同的级别，依赖于系统边界、参与者和目标。 与其泛泛地问“什么是有效的用例？”，不如更直接地问：“对应用的需求分析来说，在什么级别上描述用例最有帮助？,测试用例,老板测试 规模测试 测试,测试用例（续）,老板测试 用例的执行结构对参与者来说是可观测和有意义的 如果该用例不同通过老板测试，这意味着该用例与达到可量化价值的结果没有太大关系“也许是更低级别的用例”,登录,填写取款单,测试用例（续）,规模测试 用例很少由单独的活动或步骤组成,在游戏板上移动棋子,输入商品编号,测试用例（续）,EBP指导原则 EBP用例：对计算机应用进行需求分析的时候，应关注于“基本业务过程”(EBP)级别的用例 一个主要成功场景会包含5-10个小步骤 用例也不是一个需要好几天和很多对话才能完成的工作 它是能够在一个对话、几分钟或一个小时的时间内就可以完成的任务。 用例强调了能够增加可见的或可度量的业务价值,EBP级别上的用例,一个EBP级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户来实现自己的目标 找出用户的目标 为每个目标定义一个用例,你想做什么？ 你的目标是什么？,解决方案和过程,增加可见的或可以度量的业务价值,对EBP原则的合理违反,尽管一个应用的“基本”用例应该满足EBP原则，但我们经常会创建一些单独的“子”用例来表示基本用例中的子任务或步骤。用例有时候不必符合EBP原则。EBP的指导原则只在对应用进行需求分析时用来寻找主要用例，也即命名、写出主要用例。 例子:“信用卡支付”。,用例的其他特征,必须由一个参与者发起 用例必须以动宾形式出现的 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元和部署单元,ATM吐钞,统计,喝,用例的粒度,用例的粒度以每个用例能够说明一件完整的事情为宜 或者说，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜 例：某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前的借阅记录以确保没有未归还的书，最后借到了书。从这段话中能够得出多少个用例呢？,借书,用例的粒度（续）,例：主角说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳电话费、水费、电费等费用；为了安全起见，ATM应当有警示小心骗子的提示条，还有摄像头例如过输入三次密码错误，卡片应当被自动吞没,用例的获得（续）,这些是有效的用例吗？,误区一：,用例是功能的划分和描述 软件是一种还不存在的事物，对于正准备开发的软件，我们不能从结构观点去描述它，也不能从功能观点去描述它，最好的方法就是从使用者的观点去描述它。 功能性观点和结构性观点，则可以通过使用者观点推导出来。,误区一：（续）,例，对电视的描述 从功能的角度： 开关、显示、调频道、调声音。 从用例角度： 观看电视节目：打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下。,误区二：,目标和完成目标的步骤 一个用例是参与者对目标系统的一个愿望，一个完整的事件。 完成一个完整的事件需要经由很多步骤，但这些步骤不能够完整的反映参与者的目标，不能够作为用例。,误区二：（续）,例：去邮局寄信,例如：对于销售点终端系统来说，一些可能的参与者和他们发起的过程有：,通过事件分析找出参与者和目标,确定外部事件 有哪些事件，从哪儿产生，为了什么？,确定用例EBP级别的用例 一个好的用例为参与者产生一种可以估量的价值结果 描述参与者想要系统完成的事情,用例,一组用例是一个系统的用户能够使用系统完成的不同任务 可以通过考虑在系统实现后参与者能够用它来做什么，简单地草拟出这次迭代的一组初步的用例,定义用例时的一些经验,命名用例的时候以动词开头 每个用户目标有一个用例 例外：C