第3章3.2用例驱动的需求分析.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,用例驱动的需求分析,什么是用例,(Use Case),？,用例,(Use Case),：表示系统所提供的服务或可执行的某种行为,定义了系统是如何被参与者所使用的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段,“,对话,”,。,用例的概念在,1986,年由,Ivar Jacobson,正式提出之后被广泛接受，迅速发展，已成为,OO,、,UML,、,RUP,的标准规范和方法。,描述需求的时候：,系统有谁在用？,这些人通过系统来做什么？,用例图的要素,用例方法的基本思想：从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的。,用例模型主要由以下模型元素构成：,参与者,(Actor),：存在于被定义系统外部并与该系统发生交互的人或其他系统，代表系统的使用者或使用环境。,用例,(Use Case),通讯关联,(Communication Association),：用于表示参与者和用例之间的对应 关系，它表示参与者使用了系统中的哪些服务,(,用例,),、系统所提供的服务,(,用 例,),是被哪些参与者所使用的。,参与者,用例,通讯关联,一种新的需求分析技术：用例,用例方法的优点,系统被看作是一个黑箱，并不关心系统内部是如何完成它所提供的功能的。,首先描述了被定义系统有哪些外部使用者,(,抽象为,Actor),、这些使用者与被定义系统发生交互；,针对每一执行者，又描述了系统为这些执行者提供了什么样的服务,(,抽象成为,Use Case),、或者说系统是如何被这些执行者使用的；,用例建模的基本过程,Step 1：,确定系统边界,Step 2,：识别并描述参与者,(actor),；,Step 3,：识别用例,(use case),，并给出简要描述；,Step 4,：识别执行者与用例之间的关联,(Association),；,Step 5,：给出每一个用例的详细描述,Step 6,：细化用例模型,Step 1,：确定系统边界,系统目标,系统范围,例：学生成绩管理系统,目标：大学？中小学？,范围：单机、网络？学籍？课程？,Step 2,：识别并描述参与者,(actor),参与者（,actor）,是指在,系统外部,与系统交互的人或其他系统，他以某种方式参与了系统内用例的执行,。,参与者的类型,参与者一般分为三种：,人：与,系统存在交互关系,的使用者，管理员，用户等,设备：与,系统存在交互关系,的外部设备，条码扫描仪，,ic,读卡器，监控摄像头等,其他系统：与,系统存在交互关系,的其他系统，成绩管理系统的选课数据由选课系统提供。,时间：有些用例需要系统时钟定时触发，如员工生日祝福操作由系统时钟检测到生日时间后出发,识别参与者,通过以下问题来识别,Actor,：,谁使用这个系统的功能？,谁从该系统获得信息？,谁向该系统提供信息？,该系统需要访问,(,读写,),那些外部硬件设备？,谁来负责维护和管理这个系统以保证其正常运行？,该系统需要与其他系统进行交互吗？,系统的主要功能使用者,系统的硬件设备,系统的维护、管理人员,其他系统,例,1,：对一个图书管理系统来说，有哪些参与者？,读者,图书管理者,例,2,：对,ATM,系统来说，有哪些参与者？,银行客户,ATM,维护人员,后台服务器,读者,图书管理员,银行客户,维护人员,后台服务器,参与者的特点,在建模参与者过程中，记住以下要点。,（,1,）参与者对于系统而言总是外部的，因此它们在你的控制之外。,（,2,）参与者直接同系统交互，这可以帮助定义系统边界。,（,3,）参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物。,（,4,）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。例如，某研究生担任某教授的助教，同职业的角度看，他扮演了两个角色,学生和助教。,（,5,）每一个参与者需要有一个具有业务一样的名字，在建模中，不推荐使用诸如,NewActor,这样的名字。,（,6,）每个参与者必须有简短的描述，从业务角度描述参与者是什么。,（,7,）像类一样，参与者可以具有分栏，表示参与者属性和它可接受的事件。一般情况下，这种分栏使用的并不多，很少显示在用例图中。,分组讨论：找出参与者,按照分组选择题目进行讨论,时间：,5,分钟,1,、图书管理系统的参与者（,1-4,组）,2,、学生餐饮管理系统的参与者（,5-8,组）,Step 3,：识别用例,(use case),找到参与者之后，据此来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说执行者是如何使用系统的。,寻找用例可以从以下问题入手,(,针对每一个参与者,),：,参与者使用该系统执行什么任务？,参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，执行者又是如何来完成这些操作的？,参与者是否会将外部的某些事件通知给该系统？,系统是否会将内部的某些事件通知该执行者？,用例的特征,这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。,用例是相对独立的，即用例的“功能”是完备的,用例的执行结果对执行者来说是可观测和有意义的,用例必然是以动宾短语形式出现的。,识别用例,例,1,：对图书馆管理系统来说，有哪些参与者和用例？,图书管理员,管理读者信息,管理图书信息,登记借书,登记还书,例,2,：对,ATM,系统来说，有哪些参与者和用例？,银行客户,查询,取款,转账,普通读者：,预订图书,取消预订,查询浏览图书信息,ATM,维护人员,维护系统,后台服务器,周期性操作,Step 4,：识别执行者与用例之间的关联,数据流向,由谁启动,Step 3,：识别执行者与用例之间的关联,数据流向,由谁启动,Step 3,：识别执行者与用例之间的关联,数据流向,由谁启动,参与者与用例的关系,启动用例,获取用例的服务,为用例提供服务,给系统提供信息,讨论,讨论下面的用例图，有什么问题？,目标和步骤的误区,用户观点而非系统观点,用户观点,系统观点,用例的粒度,ATM,取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？,用例粒度的划分最标准的方法应该是：以该用例是否完成了执行者的某个完整目的为依据的。,案例：,ATM,的用例,客户代表,说：我希望这台,ATM,能,支持跨行业务,，我,插入卡片,并,输入密码,后，可以让我,选择,是,取钱,还是,存钱,；为了方便，可以设置一些默认的存取金额按钮；我可以,修改密码,，也可以,挂失,；还有我希望可以,交纳,水费、电费和电话等,费用,；为了安全起见，,ATM,上应当有,警示小心骗子,的提示条，还有摄像头；如果,输入三次密码,错误，卡片应当被自动吞没。,判断下列操作，哪些是用例,支持跨行业务,插入卡片,输入密码,选择服务,取钱,存钱,修改密码,挂失卡片,交纳费用,警示骗子,三次错误吞没卡片,支持跨行业务,错，这是一个业务规则，限定业务的范围,插入卡片,错，这是一个过程步骤，不是完整目标,输入密码,错，这是一个过程步骤，不是完整目标,选择服务,错，这是一个过程步骤，不是完整目标,取钱,对，这是一个完整有效的目标,存钱,对，这是一个完整有效的目标,修改密码,对，这是一个完整有效的目标,挂失卡片,对，这是一个完整有效的目标,交纳费用,对，这是一个完整有效的目标,警示骗子,错，已超出了边界范围,三次错误吞没卡片,错，这是一个业务规则，限定业务的范围,ATM,的用例,“四轮马车”,C(Create)R(Read)U(Update)D(Delete),所有业务最终对会成为,CRUD,？,CRUD,能为,Actor,提供价值？,CRUD,掩盖业务，,锐变成关系数据库的建模：,“系统就是数据的增删改查”,关心数据的存储和维护，反而忽略了用户的目的,用例的粒度,2,如果确实是,CRUD,？,如果,CRUD,不涉及复杂的交互，一个用例“管理,”,即可,不管是,C,、,R,、,U,、,D,，都是为了完成“管理”目标,甚至很多种的基本数据管理都可以用一个用例表示,讨论,电子邮件系统，有如下功能：,发件人,A,发送邮件给,B,，系统提醒,B,你有“新邮件”，收件人,B,接收邮件。,画出用例图,Step 5,：给出用例的详细描述,单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息。,用例名称,用例标识,涉及的参与者,描述,用例的规格说明,前置条件,PreConditions,后置条件,PostConditions,正常事件流,Flow of events,备选事件流,Alternate flow,其它,非功能需求、设计约束、尚存在的问题,前置、后置条件,前置条件约束在用例开始前系统的状态,把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件,说明在用例触发之前什么必须为真,后置条件约束用例执行后系统的状态,用例执行后什么必须为真,对于有多个事件流的用例，则应该有多个后置条件,某些用例依赖于其他用例,一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）,有助于识别漏掉的用例,如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,事件流,用例的事件流：,说明用例如何启动，即哪些执行者在何种情况下启动用例？,说明执行者与用例之间的信息处理过程；,说明用例在不同条件下可以选择执行的多种方案；,说明用例在什么情况下才能被视作完成；,分为常规流和备选流两类：,常规流：描述该用例最正常的一种场景，系统执行一系列,活动步骤来响应执行者提出的服务请求；,备选流：负责描述用例执行过程中异常的或偶尔发生的一,些情况。,常规事件流,每一个步骤都需要用数字编号以清楚地,标明步骤的先后顺序。,用一句简短的标题来概括每一步骤的主要内容。,对每一步骤，从两个方面来描述：,执行者向系统提交了什么信息；,对此系统有什么样的响应。,备选事件流,备选流的描述格式可以与基本流的格式一致，,也需要编号并以标题概述其内容。,起点：该备选流从事件流的哪一步开始；,条件：在什么条件下会触发该备选流；,动作：系统在该备选流下会采取哪些动作；,恢复：该备选流结束之后，该用例应如何,继续执行。,事件流描述要点,1.,只书写“可观测”的（说人话）,2.,使用主动语句,3.,句子必须以参与者或系统作为主语,4.,不要涉及界面细节,5.,分支和循环,只写“可观测”的,系统通过,ADO,建立数据库连接，传送,SQL,查询语句，从“商品表”查询商品的详细信息,系统按照查询条件搜索商品的详细信息,主动语句,欧文丛贝克汉姆处得到传球，守门员,贝克汉姆传球给欧文，欧文射门，守门员扑救,出纳员,系统,以参与者或系统作主语,参与者,系统,出纳员接收顾客的付款,顾客的付款数可能高于商品总额,出纳员录入顾客所付的现金总额,系统显示出应找还给顾客的余额，打印付款收据,不涉及界面细节,会员从下拉框中选择类别,会员在相应文本框中输入查询条件,会员点击“确定”按钮,分支和循环,分支：放到扩展路径（备选事件流）,参与者的选择,另一条成功线路,系统进行验证,循环：直接描述,处理销售,1.,顾客携带所购商品或服务到收银台通过,POS,机付款。,2.,收银员开始一次新的销售交易。,3.,收银员输入商品条码。,4.,系统逐条记录出售的商品，并显示该商品的描述、价格和累计金额。价格通过一组价格规则来计算。,5.,收银员重复,3-4,步，直到输入结束。,6.,收银员告知顾客总额，并请顾客付款。,7.,顾客付款，系统显示找零信息，并处理支付。,8.,系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。,9.,系统打印票据。,10.,顾客携带商品和票据离开。,处理销售的用例描述,用例名称：处理销售,参与者与关注点：,收银员：希望准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其工资中扣除。,前置条件：收银员必须经过确认和认证,后置条件：存储销售信息。准确计算税金。更新账务和库存信息。,基本流程：,1.,顾客携带所购商品或服务到收银台通过,POS,机付款。,2.,收银员开始一次新的销售交易。,3.,收银员输入商品条码,扩展流程：,3a.,无效商品,ID,（在系统中未发现）：,系统提示错误并拒绝输入该,ID,。,收银员响应该错误,特殊需求：,使用大尺寸平面显示器触摸屏，文本信息可见距离为,1,米,发生频率：可能会不断地发生,未解决问题：提成处理规则不确定 收银员换班时如何处理,Step6,：细化用例模型,执行者与执行者之间的泛化,(generalization),用例和用例之间的包含,(include),用例和用例之间的扩展,(extend),用例和用例之间的泛化,(generalization),关系,利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来复用，使得用例模型更易于维护。,泛化,(Generalization),关系,执行者之间的泛化,泛化,(Generalization),用例之间的泛化,用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,包含,(Include),箭头指向的用例为,被包含的用例,，称为,包含用例,；箭头出发的用例为,基本用例,。,包含用例是必选的，如果缺少包含用例，基础用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。,包含,(Include),某些步骤在多个用例重复出现，且单独形成价值,用例步骤较多时，可用,Include,简化,银行客户,查询,取款,转帐,打印回执,扩展,(Extend),将扩展用例的事件流在一定的条件下按照相应的,扩展点,插入到基础用例中。,基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。,扩展用例的行为是否被执行要取决于主事件流中的判定点。,箭头指向的用例为,被扩展的用例,，称为,扩展用例,；箭头出发的用例为,基本用例,。,扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。,扩展,(Extend),包含与扩展的区别,扩展,(Extend),扩展举例（一）：,扩展,(Extend),扩展举例（二）：,extend,图书馆系统中有如下用例，请确定用例之间的关系,借书,还书,验证读者,超期罚款,include,include,密码验证,智能卡验证,练习,面向对象的需求分析,1,结构化分析方法的不足,2,面向对象的软件工程,3,用例是什么？用例建模的基本过程,4,用例模型的提交物,1,用例模型,2,每个用例的详细描述,3,术语表：所用到的术语说明,4,补充规约：非功能性需求的说明,