第3章 UML系统建模与分析设计-需求分析与用例建模01.ppt

1、2020/9/5,软件工程方法,1,了解可行性研究与风险分析的方法 掌握可行性分析报告的书写格式 掌握客户需求分析的要点及需求分析规格说 明报告的书写格式 掌握通过绘制用例图及其正文描述来完成客 户需求分析的方法 掌握UML的用例模型建模方法,本章目的：,第三章 需求分析与用例建模,2020/9/5,软件工程方法,2,1.系统成本费用分析 设备购置费用。 系统开发费用。 系统安装、运行和维护费用。 人员培训费用。 2.系统效益分析 经济效益。 社会效益。,3.1.1 经济可行性研究,3.1 可行性研究与风险分析,2020/9/5,软件工程方法,3,2020/9/5,软件工程方法,4,1.风险分

2、析 2.资源分析 3. 技术分析 反映系统动态特性： 综合系统的全部因素： 突出系统的重要因素： 结构简单：,3.1.2 技术可行性分析,3.1.3 法律可行性分析,3.1.4 开发方案可行性分析研究,1. 提出待选方案,2. 评价待选方案,3. 确定开发方案,2020/9/5,软件工程方法,5,3.1.5 可行性分析报告文档格式,2020/9/5,软件工程方法,6,3.2 客户需求分析与用例建模,用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。 分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。 用例的捕获手段抽象,2020/9/5,软件工程方法,7,3.2.1

3、 建造需求模型用例建模,用例建模的主要目标是： 将需求规约变为可视化模型，并得到用户确认； 给出清晰、一致的关于系统做什么的描述，确定系统的功能要求； 提供从功能需求到系统分析、设计、实现各阶段的度量标准； 为最终系统测试提供基准，据此验证系统是否达到功能要求； 为项目目标进度管理和风险管理提供依据。,2020/9/5,软件工程方法,8,用例建模的步骤,确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。,2020/9/5,软件工程方法,9,3.2.2 用例图,2020/9/5,软件工程方法,10,找出系统中的执行者和用例,这项任务通常是由与

4、潜在用户会见的系统分析员完成的。 在某些情况下，该任务还包括你与顾客面对面的访谈，在访谈中可以提出问题，了解他们的需求。访谈过程中，你可以整理出一个手抄本，或者简单地多做些记录以备后用。 在另外一些情况下，公司中的一些人会向你提供项目的业务需求列表。对于这些业务需求，你需要向提供者提出一些问题以得到你所需要的答案。这些需求和你得到的答案将成为创建用例图的笔记。,2020/9/5,软件工程方法,11,3.2.3 定义系统的边界和范围,系统边界包括： 整个组织：如一个企业； 一个组织的某个部门：如企业的财务处； 计算机系统的硬件/软件边界：如企业的进、销、存计算机管理系统。 1定义系统的范围 2定

5、义系统的边界,2020/9/5,软件工程方法,12,3.2.4 确定执行者(参与者),执行者（actor）是指在系统外部与系统交互的人或其他系统，他以某种方式参与了系统内用例的执行。 Actor：在系统之外与系统交互的某人或某事物。 Actor在建模过程中是处于核心地位的。,2020/9/5,软件工程方法,13,2020/9/5,软件工程方法,14,14,谁是执行者？,小王去银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。,2020/9/5,软件工程方法,15,回答问题,谁对系统有着明确的目标和要求并且主动发出动作？ 系统是为谁服务的？,2020/9/5,软件工程

6、方法,16,参与者 业务工人,2020/9/5,软件工程方法,17,执行者可以非人,需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。 原则： 不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。,2020/9/5,软件工程方法,18,1定义执行者时应注意的几个问题,（1）执行者之间可以有继承关系 （2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者,2020/9/5,软件工程方法,19,2020/9/5,软件工程方法,20,2寻找和确定执行者,2020/9

7、/5,软件工程方法,21,情况一,2020/9/5,软件工程方法,22,情况二,2020/9/5,软件工程方法,23,情况三,2020/9/5,软件工程方法,24,情况四,2020/9/5,软件工程方法,25,3.2.5 确定用例,用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的方法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中我们称之为场景。一个场景就是一个用例的实例。,2020/9/5,软件工程方法,26,3.2.5.确定用例1.用例的特征,响应性。一个用例不自动执行，总是有执行者启动。 回执性。 用例执行完

8、毕，向执行者提供可识别的返回值。 完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。,2020/9/5,软件工程方法,27,用例的特征-响应性,这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。,2020/9/5,软件工程方法,28,用例的特征-完整性,用例是相对独立的，即用例的“功能”是完备的,2020/9/5,软件工程方法,29,一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元甚至部署单元。,2020/9/5,软件工程方法,30,用例的特征-回执性,用例的执行结

9、果对执行者来说是可观测和有意义的,2020/9/5,软件工程方法,31,用例的执行结果对参与者来说是可观测的和有意义的。 如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。 因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。 又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？,2020/9/5,软件工程方法,32,用例的特征-动宾短语,用例必然是以动宾短语形式出现的。

10、,2020/9/5,软件工程方法,33,用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的. 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。,2020/9/5,软件工程方法,34,3.2.5.2.寻找和确定用例,业务用例：开始阶段，在确定用户需求过程中，系统分析员通过与客户交流建立业务模型来发现和确定的用例。 系统用例：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根

11、据系统的需求建立的用例。,2020/9/5,软件工程方法,35,在系统开发的开端阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例,2020/9/5,软件工程方法,36,建立用例模型时，可询问：,用户(执行者)需要系统提供哪些业务功能,即系统能做什么? 用户最关心系统中哪些事件?从功能观点看,这些事件表示什么? 用户要了解系统在工作中发生了哪些事件及其结果? 用户自己需要做什么? 用户是否要在系统中创建、删除、读、修改或存储某类业务数据？ 系统为了维持正常运转需要增加的功能和信息的交互； 这些信息从何而来，到哪里去？ 实现当前系统（可能是人工系统而不是自动化系统）的关键问题是

12、什么？,2020/9/5,软件工程方法,37,通过与用户反复交流，确定主要业务用例和次要业务用例。 对于建立的每一个业务用例，都需要一组系统用例来辅助和支持。（不严谨） 系统用例是执行者与系统的交互，它描述了系统的功能需求和动态行为。 系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例。（活动图）,2020/9/5,软件工程方法,38,如何获得用例访谈,您对系统有什么期望？ 您打算在这个系统里面做些什么事情？ 您做这件事的目的是什么？ 您做完这件事情希望有一个什么样的结果？ 一个明确的有效地目标才是一个用例的来源。 一个真实的目标应当完备地表达执行者的期望。 一个

13、有效地目标应当在系统边界内，由主角发动，并具有明确的后果。,2020/9/5,软件工程方法,39,应当先建立业务用例模型，然后再从业务用例模型向系统用例模型映射。 注意用例图的层次，从系统到子系统逐层建立用例图。,2020/9/5,软件工程方法,40,用例和功能的误区,用例就是功能划分？ 在描述一个事物的时候，我们可以从以下三个观点出发： 这个事物是什么？结构性观点 这个事物能做什么？功能性观点 人们能用这个事物做什么？使用者观点,2020/9/5,软件工程方法,41,结构性观点：自行车是一种交通工具，它由传动系统、刹车系统等部分组成。 功能性观点：自行车可以骑行。 使用者观点：人们可以用双脚

14、蹬动踏板而向前行进，可以用手捏合刹车使自行车停下来。,2020/9/5,软件工程方法,42,总结： 功能是脱离使用者的愿望而存在的。 功能是孤立的，给一个输入，通过计算就有一个固定的输出只要按下开关灯就亮。 用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯，结果是什么。 功能描述的是一个个点。 用例描述的是一个系统性工作。,2020/9/5,软件工程方法,43,目标和步骤的误区,2020/9/5,软件工程方法,44,用例的粒度,ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？ 用例粒度的划分最标准的方法应该是：以该用例是否完成了参与者的某个完整目的为依据的。 同一

15、个需求阶段，用例的粒度应该时同一级别的。 粒度选取的问题本质上还是因为边界认定不同而产生的。,2020/9/5,软件工程方法,45,ATM示例,客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳水费、电费和电话等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。,2020/9/5,软件工程方法,46,判断题,支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没

16、卡片,2020/9/5,软件工程方法,47,判断题参考答案,支持跨行业务错，这是一个业务规则，限定业务的范围 插入卡片错，这是一个过程步骤，不是完整目标 输入密码错，这是一个过程步骤，不是完整目标 选择服务错，这是一个过程步骤，不是完整目标 取钱对，这是一个完整有效的目标 存钱对，这是一个完整有效的目标 挂失卡片对，这是一个完整有效的目标 交纳费用对，这是一个完整有效的目标 警示骗子错，已超出了边界范围 三次错误吞没卡片错，这是一个业务规则，限定业务的范围,2020/9/5,软件工程方法,48,3.2.5.3.描述用例,用例名： 简单名： 路径名：,2020/9/5,软件工程方法,49,用例的

17、文字描述应包括以下内容:,用例的目的（功能）； 该用例在什么情况下被哪个执行者启动执行； 用例与执行者之间交互哪些消息来通知对方作出决定； 交互的主消息流及因此被使用或修改的实体； 用例中可供选择的异常事件流； 用例结束标志：给执行者返回一个可识别的值。,2020/9/5,软件工程方法,50,举例,用例名称：学生选课 执行者：学生 目的：完成一次学生选课的完整过程。 类型：主要的、基本的 级别：一级 过程描述： （1）学生输入标识码（ID），系统识别标识码的有效性； （2）对学生进行注册识别； （3）流览本学期预开课程； （4）选择学生自己要上的课程并确认； （5）退出系统，系统给出所选课程列

18、表及相应学分合计。,2020/9/5,软件工程方法,51,异常事件流处理： （1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲 突时，系统提示重选。,2020/9/5,软件工程方法,52,3.2.6 用例之间的关联,1继承关联 2.扩展关联 3.包含关联 4.使用关联,2020/9/5,软件工程方法,53,1.继承关联-泛化(generalization),当多个用例共同拥有一种类似的结构和行为的时候 我们可以将它们的共性抽象成为父用例，其他的用例 作为泛化关系中的子用

19、例。,2020/9/5,软件工程方法,54,泛化举例（一）：,2020/9/5,软件工程方法,55,泛化举例（二）：,2020/9/5,软件工程方法,56,2.扩展(extend),箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基本用例。 扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。,2020/9/5,软件工程方法,57,扩展(extend),将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事

20、件流中的判定点。,2020/9/5,软件工程方法,58,扩展(extend),2020/9/5,软件工程方法,59,扩展(extend),扩展举例（一）：,2020/9/5,软件工程方法,60,扩展(extend),扩展举例（二）：,2020/9/5,软件工程方法,61,3.包含(include),包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例多个用例的公共用例。,2020/9/5,软件工程方法,62,包含(include),箭头指向的用例为被包含的用例，称为包含用例；箭头出发

21、的用例为基本用例。 包含用例是必选的，如果缺少包含用例，基础用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。,2020/9/5,软件工程方法,63,包含(include),2020/9/5,软件工程方法,64,包含(include),包含举例（一）：,2020/9/5,软件工程方法,65,包含(include),包含举例（二）：,2020/9/5,软件工程方法,66,用例之间的关系,包含用例与扩展用例的区别 相对于基础用例，扩展用例是可选的，而包含用例则不是。 如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 扩展用例的执行需要满

22、足某种条件，而包含用例不需要。 扩展用例的执行会改变基础用例的行为，而包含用例不会。,2020/9/5,软件工程方法,67,使用关联,使用关联也是一种继承关系. 在使用关联中,一个用例使用另一个用例的功能和行为.,2020/9/5,软件工程方法,68,考虑用例的关联类型,2020/9/5,软件工程方法,69,2020/9/5,软件工程方法,70,1).图中的参与者有？ (a) 1 (b) 2 (c) 3 (d) 4 2).图中的用例有？ (a) 1 (b) 2 (c) 3 (d) 4 3). 2和3之间是什么关系？5和6呢？ (a) 扩展，包含(b) 包含，扩展 4).5缺少了3仍然是个完整的

23、用例？ (a) 是的(b) 不是 5).4能够参与2吗？1能够参与5吗？ (a) 可以，不可以 (b) 不可以，可以,习题答案： 1、(a)(d) 2、(b)(c) 3、(b) 4、(b) 5、(b),习题,2020/9/5,软件工程方法,71,3.2.7 用例图实例,2020/9/5,软件工程方法,72,3.3 定义系统的对象和类(第4章讲) 类-责任-协作者（简称CRC）技术.,2020/9/5,软件工程方法,73,3.4 客户需求分析规格说明,2020/9/5,软件工程方法,74,补充知识点：ROSE用例视图,在Rose用例视图中，可建立系统的用例模型，它包含所有的角色、用例、用例图，还

24、可能包含一些描述用例功能的顺序图、活动图。 Rose用例模型分成两个层次： 业务用例模型（Business Use Case Model） 系统用例模型（System Use Case Model） 业务用例模型关注的是企业的业务功能，系统建立前的组织机构、角色和他们之间的相互关系，即机构内部实际业务工作流。 系统用例模型是针对将创建的系统描述其功能需求。 用例图模型只是描述系统及其功能需求，不考虑系统设计与实现。,2020/9/5,软件工程方法,75,建立业务用例模型的目的： 了解企业的组织机制； 了解企业组织中当前存在的问题并确定改进的可能性； 确保客户、最终用户和开发人员就企业业务流程达

25、成共识； 描述企业部门的业务功能。,一、业务用例模型,业务用例模型是企业最核心、最概括的业务说明，主要由以下两部分组成。 业务角色和业务员工。一个角色既可以是一个用户，也可以是一个信息系统。业务角色是机构外部与机构交互的对象，业务角色与企业的业务活动有关；业务员工是机构内部的角色，通过描述每个业务员工，可以了解这些角色在系统中的责任和活动。,1、业务用例模型的组成,2020/9/5,软件工程方法,76,2、业务用例模型的基本元素,业务用例。业务用例是机构中的一组相关工作流。机构中的全部用例一起完整地描述了企业的业务目标。这些业务用例是建立新系统的功能需求。,2020/9/5,软件工程方法,77

26、,（l）业务角色（BusinessActor） 业务角色是与企业机构交互的一切人或系统。业务角色不包含单位机构内部人员。 （2）业务员工（BusinessWorker） 业务员工是企业机构内部人员，代表业务中的一个或一组角色。业务员工参与业务用例实现时，业务员工和业务用例进行交互，并使用和控制业务实体。 （3）业务用例（BusinessUseCase） 业务用例是企业中的一组相关工作流，对业务角色提供服务。业务用例描述告诉人们单位机构做什么，以及做什么会有利于业务和参与人员的工作，单位中的全部业务用例一起完整地描述业务目标。 （4）业务实体（Business Entity） 业务实体也被称为业务对象（Business Object） 业务实体代表业务角色中处理或使用的“事物”。例如