Section用例和用例图

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,用例和用例图,1,概述,用例图着重从系统外部执行者的角度来描述系统需要提供哪些功能，执行者可以是人或外部系统。,2,概述,用例图的组成元素,图中的元素包括：参与者、用例、一些表示关系的连接线,参与者与用例的关系：在参与者和用例之间的关联是用一根线来表示的,用例之间的关系：,1,）包含关系,2,）扩展关系,3,）泛化关系,3,基于用例的建模过程,获取原始需求,识别参与者,识别用例,识别用例之间的关系,描述脚本,构建用例图,进行用例描述,4,获取原始需求：石头问题,我要一块石头,差不多，但我要小一点的,很好，不过我要蓝色的,啊，没有那么小,咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！,5,获取原始需求：如此脆弱,客户,/,用户的要求,/,想法,/,期望,软件设计,软件产品,分析和设计,编码和测试,验 收,没价值的软件需求,补文档,6,获取原始需求：也需要开发,客户,/,用户的要求,/,想法,/,期望,软件设计,软件产品,开发,编码和测试,验收,有价值的软件需求,分析和设计,7,技巧,描述,实地观察,直接观察个人工作的情况，以发现现存的实践方式和问题,访谈,从个人处收集特定信息,特定群体调查,对一组人员进行调查，以便了解工作态度和共同看法,问卷调查,收集详细数据和统计意义上比较重要的数据,用户指导,让最终用户告诉你，他们是如何操作系统的,原型制作,模拟一个无法直接测试的系统,统计版本,使用具有统计功能的应用程序来记录用户完成任务的方式,获取原始需求：技巧,8,目标：构建一个棋牌馆管理系统,问题描述：,客户通过,Internet,预订座位，检查座位详情，如果没有空闲的座位或满意的座位，可以选择进入等候队列。,总台服务员在客户到棋牌馆时，根据客户的预订信息，安排客户座位。,当客户要离开棋牌馆时，客户到总台服务员办理结账，可以采用两种方式，一种是现金结账，另一种是银行卡结账，而银行卡结账将通过与银联,POS,系统交互来完成。,获取原始需求,9,识别参与者,(actor),对于一个大系统，难以列出所有用例的清单。此时，应先列出所有的参与者，然后在对每个参与者列出他所需的所有用例。即提供了一种获取用例的系统化过程。,“参与者”（活动者、执行者）,是指在,系统之外,，透过,系统边界,与系统进行,有意义交互,的,任何事物,。,10,识别参与者,UML,中的,Actor,实际上是一个版型化的类,可以有三种表示形式,Icon,形式,Label,形式,Decoration,形式,11,识别参与者：参与者要点,系统外,参与者代表在系统边界之外的真实事物，并不是系统的成分,系统边界,参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定,有意义交互,任何事物,人、外部系统、外部因素等,12,识别参与者：参与者要点,参与者指在系统中所扮演的角色。即在确定参与者时，应主要考虑他的角色，而不是这个角色的实例。,某些组织中可能有很多营销人员，但他们均起着同一种作用，扮演着相同的角色。,一个用户也可以扮演多种角色：一个高级营销人员既可以是贸易经理，也可以是普通的营销人员。,一个参与者可以执行多个用例。,一个用例也可以由多个参与者使用。,13,识别参与者：任何事物,参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟,1,）其它系统：当系统需要与其它系统交互时，如,ATM,柜员机系统中，银行后台系统就是一个参与者；,2,）硬件设备：如果系统需要与硬件设备交互时，如在开发,IC,卡门禁系统时，,IC,卡读写器就是一个参与者；,3,）时钟：当系统需要定时触发时，时钟就是参与者,14,思考：,识别参与者？,寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于,35,度，还要提醒用户注意防暑；,在这个叙述里，谁是寻呼台系统的,Actor,？用户？气温？时间？,时间作为参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例,15,识别参与者：参与者与系统边界,系统边界的确定就是要确定我们要开发的系统和外部环境之间的界限，也就是要区分系统本身和它的外部环境。,某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接,某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分,16,思考：系统边界？,一个银行系统，它的系统边界如何确定呢？,银行系统的外部活动者有储户、前台出纳员、银行管理员，这些都不属于银行系统本身，他们是此系统的外部环境；,银行系统要打印交易凭条，打印机对于系统来说是外部环境；,银行系统可能与客户的工作单位的工资发放系统有交互，那么客户工作单位的工资发放系统也是外部环境。,而对于银行系统来说，使用此系统的银行的建筑格局、人员构成、所处地域等就是此系统的内部环境。,17,识别参与者：确定系统边界的作用,系统边界一确定，我们就已经知道有哪些外部对象在与系统进行交互，于是我们就可以在系统中为该对象设计相应的接口，从而实现这些交互。,如果这些外部环境改变了，我们可能要重新设计我们的接口。但不在系统边界上的因素我们就不用考虑。,18,谁使用系统的主要功能,谁改变系统的数据,谁从系统获取信息,谁需要系统的支持以完成日常工作任务,谁负责日常维护、管理并保证系统正常运行,系统需要应付（处理）那些硬设备,系统需要和那些外部系统交互,谁（或什么）对系统运行产生的结果（值）感兴趣,时间、气温等内部外部条件,识别参与者：技巧,19,识别参与者：棋牌馆管理系统,目标：构建一个棋牌馆管理系统,问题描述：,客户,通过,Internet,预订座位，检查座位详情，如果没有空闲的座位或满意的座位，可以选择进入等候队列。,总台服务员,在客户到棋牌馆时，根据客户的预订信息，安排客户座位。,当客户要离开棋牌馆时，客户到总台服务员办理结账，可以采用两种方式，一种是现金结账，另一种是银行卡结账，而银行卡结账将通过与,银联,POS,系统,交互来完成。,20,识别参与者：参与者的泛化,参与者的泛化表示一个一般性的参与者（父参与者）与另一个更为特殊的参与者（子参与者）之间的联系。,子参与者继承了父参与者的行为和含义，还可以增加自己特有的行为和含义，子参与者可以出现在父参与者能出现的任何位置上。,如系统中经理可以参加雇员的所有用例,21,识别参与者：泛化关系的误用,22,识别用例（,use case,）,分析典型用例是开发者准确迅速地,了解用户要求,的最常用也是最有效的方法，是用户和开发者一起深入剖析,系统功能需求,的起点。,“用例”,是,Ivar Jacobson,于,20,世纪,6070,年代在爱立信公司开发,AKE,、,AXE,系列时发明的。,“Object-oriented software engineering: a use case driven approach”,用例实例是在,系统中执行,的,一系列动作,，这些动作将生成特定,参与者可见,的,价值结果,。,一个用例定义,一组用例实例,，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景,23,可观测,用例止于系统边界,价值结果,用例是有意义的目标,系统执行,结果值由系统生成,由参与者观测,业务语言、用户观点,一组用例实例,用例的粒度,识别用例：用例要点,24,在系统外部描述与系统功能的交互，而不考虑系统内部对该功能的实现方式。,用例要点：用例止于系统边界,25,用例要点：有意义的目标,26,系统需要处理的，由系统生成,用例要点：结果值由系统生成,27,用户词汇，而不是技术词汇,如：发票，商品，洗衣机,而不是：记录，字段，,COM,，,C+,等,用例要点：业务语言而非技术语言,28,用户观点,系统观点,用例要点：用户观点而非系统观点,29,用例,VS.,功能,呼叫某人,接听电话,发送短信,记住电话号码,传输,/,接收,电源,/,基站,输入输出（显示、键盘）,电话簿管理,用户观点,系统观点,30,识别用例：用例的命名,执行者视角：,（状语）动词,+,（定语,）宾语,31,识别用例：用例粒度,最常犯错误：粒度过细，陷入功能分解,把步骤当作用例,把系统活动当作用例,32,“四轮马车”,CRUD,CRUD,能为,Actor,提供价值？,CRUD,掩盖业务，,锐变成关系数据库的建模：,“系统就是数据的增删改查”,关心数据的存储和维护，反而忽略了用户的目的,用例粒度,33,如果确实是,CRUD,？,如果,CRUD,不涉及复杂的交互，一个用例“管理,”,即可,不管是,C,、,R,、,U,、,D,，都是为了完成“管理”目标,甚至很多种的基本数据管理都可以用一个用例表示,用例粒度,34,灵活处理,CRUD,可以把包含复杂交互的路径独立出去形成用例,用例粒度,35,思考：识别用例,Email,客户端（如：,outlook express,），,A,在北京发邮件给上海的,B,，,B,收邮件,36,识别用例：用例的获取,找出用例的最简单途径是对参与者提问，然后从答案中获取用例,:,参与者的主要任务是什么,?,参与者需要了解系统的什么信息,?,需要修改系统的什么信息,?,参与者是否需要把系统外部的变化通知系统,?,参与者是否希望系统把异常情况通知自己,?,37,目标：构建一个棋牌馆管理系统,问题描述：,客户,通过,Internet,预订座位,，,检查座位详情,，如果没有空闲的座位或满意的座位，可以选择,进入等候队列,。,总台服务员,在客户到棋牌馆时，根据客户的预订信息，,安排客户座位,。,当客户要离开棋牌馆时，客户到总台服务员,办理结账,，可以采用两种方式，一种是,现金结账,，另一种是,银行卡结账,，而银行卡结账将通过与,银联,POS,系统,交互来完成。,识别用例：棋牌馆管理系统,38,Extend,Include,Generalization,用例之间的关系,泛化关系中，子用例继承父用例的行为和含义，子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义,一个用例（称作基本用例）的行为包含了另一个用例（称作包含用例）的行为,扩展关系比泛化关系用更多的规则限制，基础用例提供扩展点，扩展用例只能在这些扩展点上增加新的行为。,39,泛化关系,同一业务目的不同技术实现,一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）,用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,40,一个售货员可以终止任何交易，除了那些需要特殊的售货员（高级代理）终止的超过了一定限制的交易,泛化的危害,41,扩展关系,常规动作放在一个基本的用例中，将非常规动作放在它的扩展用例中。,基本用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展 。,扩展用例通过引用扩展点（,extension point,）建立与基用例的联系，扩展点指明了在基本用例中的扩展位置,42,扩展关系的误用,43,识别扩展关系,系统验证,步骤失败,44,包含关系,某些步骤在多个用例重复出现，且单独形成价值,被包含的用例不是孤立存在的，它仅作为某些包含它的更大的基用例的一部分出现,用例步骤较多时，可用,Include,简化（慎用）,45,包含关系的误用,包含关系使用不当容易诱使人们进行功能分解，从而导致对用例的误用,46,包含：由用例,A,连向用例,B,，表示用例,A,中使用了用例,B,中的行为或功能,一个基本用例执行时，一定会执行包含用例的部分。,扩展：由用例,B,连向用例,A,，表示用例,A,描述了一项基本需求，而用例,B,则描述了该基本需求的特殊情况，即一种扩展,扩展用例的目的是在不改变某个已存在（或假定存在）的用例的前提下为之增添新行为。,一个基本用例执行时，可以执行、也可以不执行扩展部分。,扩展,VS,包含,47,扩展和包含用例本质上其实非常相似，都表示从基本用例中抽取一些行为放到一个单独的用例中。,扩展和包含用例都与基本用例相联。在基用例的执行过程中，可能在某种条件下基本用例的执行被中断，转而执行扩展或包含用例（附加用例）。当附加用例执行完毕，控制将返回到基用例原来被中断的那个位置恢复执行。,它们的主要区别在于用例实例中断基本用例、执行附加用例的方式,包含用例一定会执行，扩展用例只有在特殊情况下才能执行。,扩展,VS,包含,48,老大知道老二,老二知道老大,什么时候该我上场呢？不知道！,出现这种情况，就该我上场了！,扩展,VS,包含,49,采用不同关系，文档结构不同,扩展,VS,泛化,50,基本用例,(,扩展关系中,),扩展用例,(,扩展关系中,),基本用例,(,包含关系中,),包含用例,(,包含关系中,),用例之间的关系：网上购物的部分用例,51,用例之间的关系：几种关系的符号,52,当描述一般行为的某种变化时，采用泛化关系。,当描述一般行为的某种变异且希望通过基用例中的扩展点来加以控制时，则应采用扩展关系。,当两个或更多的用例中出现重复描述而又想避免这种重复时，采用包含关系。,用例之间的关系：,用例关系的应用,53,脚本,(scenario),在,UML,中指贯穿用例的一条单一路径,用来显示用例中的某种特殊情况,.,其它译名,:,情景、场景、情节、剧本,.,每个用例有一系列脚本,包括一个主要脚本,以及几个次要脚本,.,相对于主要脚本,次要脚本描述了执行路径中的异常或可选择的情况,.,例：在“订货”用例中包括几个相关脚本：,订货顺利进行的脚本,;,相关货源不足时的脚本,;,购货者的信用卡被拒绝时的脚本,;,脚本,54,方法,1,一个用例,/,三个脚本,方法,2,三个用例,脚本示例,55,构建用例图,56,用例描述,用例描述是指对一个用例的功能进行的文字描述,是参与者与系统交互动作序列的说明,.,用例描述才是用例的主要部分,是后续的交互图分析和类图分析必不可少的部分,.,用例采用自然语言描述参与者与系统的交互行为,要易于理解,.,其读者是开发人员、用户、项目经理、测试人员等,.,57,用例描述：用例描述的内容,用例的目标,用例是怎么启动的,参与者与用例之间的消息如何传送,用例中除了主路径外,其它路径是什么,用例结束后系统的状态,其它需要描述的内容,描述用例时的原则是尽可能写得“充分”,而不是形式化、完整或漂亮,.,58,描述项,说明,用例名称,表明用户的意图或用例的用途,标识符,可选,惟一标识符,便于引用该用例,用例描述,概述用例的几句话,参与者,与此用例相关的参与者,优先级,一个有序的排列, 1,代表优先级最高,状态,可选,用例状态,可以是,:,进行中,等待审查,通过审查,未通过审查,前置条件,一个条件列表,这些条件必须在访问用例前得到满足,后置条件,一个条件列表,这些条件必须在用例完成之后得到满足,基本操作流程,描述用例中各项工作都顺利进行时用例的工作方式,可选操作流程,描述变异工作方式、出现异常或发生错误的情况下的路径,用例描述：用例的描述格式,59,描述项,说明,被泛化的用例,此用例所泛化的用例列表,被包含的用例,此用例所包含的用例列表,被扩展的用例,此用例所扩展的用例列表,修改历史记录,可选,关于用例的修改时间、修改原因、修改人的详细信息,问题,可选,与此用例的开发有关的问题列表,决策,可选,关键决策的列表,将这些决策信息记录下来以便维护时使用,频率,可选,参与者访问此用例的频率,如,:,每日一次,/,每月一次等,用例的描述格式,(,续表,),60,用例描述：描述用例时易出现的错误,只描述系统的行为,没有描述参与者的行为,只描述参与者的行为,没有描述系统的行为,在用例描述中就设定了对用户界面的设计的要求,描述过于冗长,61,Use case: Withdraw cash,Actor: customer,主事件流：,储户插入,ATM,卡,并输入密码,储户按“取款”按钮,并输入取款数目,储户取走现金,/ATM,卡,/,收据,储户离开,Use case: Withdraw cash,Actor: customer,主事件流：,ATM,系统获得,ATM,卡和密码,设置交易类型为“取款”,ATM,系统获得取款金额,输出现金、收据和,ATM,卡,系统复位,ATM,系统,“,取款,”,用例的两个错误描述：,只描述了,actor,的行为,只描述了,System,的行为,62,Use case: Withdraw cash,Actor: customer,主事件流：,储户通过读卡机插入,ATM,卡,ATM,系统从卡上读取银行,ID,、账号、加密密码,并通过主银行系统验证银行,ID,和账号,储户输入密码, ATM,系统根据加密密码对输入密码进行验证,储户按 “取款”按钮,并输入取款数目,该数目应该为,$5,的倍数,ATM,系统通知主银行系统,传递账号和金额,并接收返回的确认信息和账户余额,ATM,系统输出现金、,ATM,卡和收据,ATM,系统记录交易到日志文件,ATM,系统,“,取款,”,用例的正确描述,63,用例描述：,前置、后置条件,-1,前置条件约束在用例开始前系统的状态,把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件,说明在用例触发之前什么必须为真,后置条件约束用例执行后系统的状态,用例执行后什么必须为真,对于有多个操作流的用例，则应该有多个后置条件,64,用例描述：,前置、后置条件,-2,某些用例依赖于其他用例,一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）,有助于识别漏掉的用例,如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,65,用例描述示例,1.,用例名称：处理银行卡结帐,2.,标识符：,3.,用例描述：客户来到付款处，总台服务员记录客户离开信息并接受付款，付款完成后，客户离开。,4.,参与者：总台服务员，,POS,系统,5.,前置条件：客户退出棋牌桌。,6.,后置条件：无,7.,基本操作流,8.,可选操作流,4.,非功能需求,7.,扩展点：无,8.,优先级：最高（满意度,5,，不满意度,5,）,66,用例描述示例,基本操作流,1.,系统显示客户的消费总额。,2.,总台服务员接收客户的银行卡。,3.,客户输入密码，,POS,系统对密码进行验证。,4.POS,系统返回确认消息。,5.,系统打印付款收据,6.,总台服务员将银行卡和打印付款收据交给客户,7.,系统记录本次交易,8.,客户离开,可选操作流,第,2,步：如果输入的密码不正确，系统显示出错信息,第,7,步：客户没有足够的现金，则系统显示出错信息，付款不成功。,67,用例描述：操作,流描述要点,只书写“可观测”的（说人话）,使用主动语句,句子必须以参与者或系统作为主语,不要涉及界面细节,分支和循环,68,要点,1,：只写“可观测”的,系统通过,ADO,建立数据库连接，传送,SQL,查询语句，从“商品表”查询商品的详细信息,系统按照查询条件搜索商品的详细信息,69,要点,2,：主动语句,欧文丛贝克汉姆处得到传球，守门员,贝克汉姆传球给欧文，欧文射门，守门员扑救,出纳员,系统,70,要点,3,：以参与者或系统作主语,参与者,系统,出纳员接收顾客的付款,顾客的付款数可能高于商品总额,出纳员录入顾客所付的现金总额,系统显示出应找还给顾客的余额，打印付款收据,71,要点,4,：不涉及界面细节,会员从下拉框中选择类别,会员在相应文本框中输入查询条件,会员点击“确定”按钮,72,要点,5,：分支和循环,分支：放到扩展路径,参与者的选择,另一条成功线路,系统进行验证,循环：直接描述,循环执行步骤,x,到,y,，直到条件满足,73,思考：旅店管理系统,某公司要开发一个旅店管理系统，该旅店可对外开放,10,个双人间和,10,个单人间，房间,费用视情况按季节调整,，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间,预定指定档次的房间,，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并,计算出总费用,。预定的同时旅客按规定须提交,10%,定金。六个小时之内旅店允许旅客,取消预定,，并,退回所有定金，超过六个小时定金不退还,。每周一系统,自动打印一周预定情况清单,。采用哪种费用支付方式和何种类型操作界面尚不确定。,74,References,Cock00, Alistair Cockburn, Writing Effective Use Cases,（王雷，张莉译，编写有效用例，机械工业出版社，,2002,年）,Schn00, Geri Schneider, Jason P.Winters, Applying Use Cases, Second Edition,（姚淑珍，李巍译，用例分析技术，机械工业出版社，,2002,年）,Arri02CT Arrington, Enterprise Java with UML,（马波，李雄锋译，,Enterprise Java with UML,中文版，机械工业出版社，,2003,年）,DEV475IBM Rational, Mastering Object-Oriented Analysis and Design with UML, 2003,75,