第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)找到参与者之后，据此来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说执行者是如何使用系统的。寻找用例可以从以下问题入手(针对每一个参与者)：参与者使用该系统执行什么任务？参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，执行者又是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？系统是否会将内部的某些事件通知该执行者？用例的特征v这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。v用例是相对独立的，即用例的“功能”是完备的v用例的执行结果对执行者来说是可观测和有意义的v用例必然是以动宾短语形式出现的。识别用例 例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 图书馆系统中有如下用例，请确定用例之间的关系借书还书验证读者超期罚款includeinclude密码验证智能卡验证练习面向对象的需求分析 1 结构化分析方法的不足 2面向对象的软件工程 3用例是什么？用例建模的基本过程 4 用例模型的提交物 1 用例模型 2 每个用例的详细描述 3 术语表：所用到的术语说明 4 补充规约：非功能性需求的说明个人观点供参考，欢迎讨论