资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,了解可行性研究与风险分析的方法,掌握,可行性分析报告的书写格式,掌握,客户需求分析的要点,及需求分析规格说,明报告的书写格式,掌握通过绘制,用例图,及其正文,描述,来完成客,户需求分析的方法,掌握,UML,的用例模型建模方法,本章目的：,第三章 需求分析与用例建模,2024/9/27,1,1.系统本钱费用分析,设备购置费用。,系统开发费用。,系统安装、运行和维护费用。,人员培训费用。,2.系统效益分析,经济效益。,社会效益。,3.1.1 经济可行性研究,3.1,可行性研究与风险分析,2024/9/27,2,2024/9/27,3,1.,风险分析,3. 技术分析,反映系统动态特性：,综合系统的全部因素：,突出系统的重要因素,：,结构简单：,3.1.2 技术可行性分析,3.1.3 法律可行性分析,3.1.4,开发方案可行性分析研究,1.,提出待选方案,2. 评价待选方案,3. 确定开发方案,2024/9/27,4,3.1.5 可行性分析报告文档格式,2024/9/27,5,3.2 客户需求分析与用例建模,用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。,分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。,用例的捕获手段,抽象,2024/9/27,6,3.2.1 建造需求模型用例建模,用例建模的主要目标是：,将需求规约变为可视化模型，并得到用户确认；,给出清晰、一致的关于系统做什么的描述，确定系统的功能要求；,提供从功能需求到系统分析、设计、实现各阶段的度量标准；,为最终系统测试提供基准，据此验证系统是否到达功能要求；,为工程目标进度管理和风险管理提供依据。,2024/9/27,7,用例建模的步骤,确定系统的,范围,和,边界,；,确定系统的,执行者,和,用例,；,对用例进行,描述,；,定义用例之间的,关系,；,审核用例模型。,2024/9/27,8,3.2.2 用例图,2024/9/27,9,找出系统中的执行者和用例,这项任务通常是由与潜在用户会见的系统分析员完成的。,在某些情况下，该任务还包括你与顾客面对面的访谈，在访谈中可以提出问题，了解他们的需求。访谈过程中，你可以整理出一个手抄本，或者简单地多做些记录以备后用。,在另外一些情况下，公司中的一些人会向你提供工程的业务需求列表。对于这些业务需求，你需要向提供者提出一些问题以得到你所需要的答案。这些需求和你得到的答案将成为创立用例图的笔记。,2024/9/27,10,3.2.3 定义系统的边界和范围,系统边界包括,：,整个组织：如一个企业；,一个组织的某个部门：如企业的财务处；,计算机系统的硬件,/,软件边界：如企业的进、销、存计算机管理系统。,1,定义系统的范围,2定义系统的边界,2024/9/27,11,3.2.4 确定执行者,(,参与者,),执行者actor是指在系统外部与系统交互的人或其他系统，他以某种方式参与了系统内用例的执行。,Actor：在系统之外与系统交互的某人或某事物。,Actor在建模过程中是处于核心地位的。,2024/9/27,12,2024/9/27,13,14,谁是执行者？,小王去银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。,2024/9/27,14,答复以下问题,谁对系统有着明确的目标和要求并且主动发出动作？,系统是为谁效劳的？,2024/9/27,15,参与者,业务工人,2024/9/27,16,执行者可以非人,需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。,原那么： 不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。,2024/9/27,17,1定义执行者时应注意的几个问题,1执行者之间可以有继承关系,2执行者代表一种角色而不是具体某个人,3对同一个人担任角色的限制,4执行者可分成主执行者和副执行者,5执行者还可细分为主动执行者和被动执行者,2024/9/27,18,2024/9/27,19,2寻找和确定执行者,2024/9/27,20,情况一,2024/9/27,21,情况二,2024/9/27,22,情况三,2024/9/27,23,情况四,2024/9/27,24,3.2.5 确定用例,用例,，,就是一件事情，要完成这件事情，需要做一系列的活动；,而做一件事情可以有很多不同的方法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在,UML,中我们称之为,场景,。一个场景就是一个用例的实例。,2024/9/27,25,3.2.5.,确定用例,1.,用例的特征,响应性。,一个用例不自动执行，总是有,执行者启动,。,回执性。,用例执行完毕，向执行者提供,可识别,的返回值。,完整性。,用例表示一个完整的功能，必须是一完整的描述。,必须以向执行者提供返回值作为该,用例完整性的标志,。,2024/9/27,26,用例的特征,-,响应性,这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。,2024/9/27,27,用例的特征,-,完整性,用例是相对独立的，即用例的“功能是完备的,2024/9/27,28,一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元甚至部署单元。,2024/9/27,29,用例的特征,-,回执性,用例的执行结果对执行者来说是可观测和有意义的,2024/9/27,30,用例的执行结果对参与者来说是可观测的和有意义的。,如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成局部，但它在需求阶段却不应该作为用例出现。,因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。,又比方，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？,2024/9/27,31,用例的特征,-,动宾短语,用例必然是以动宾短语形式出现的。,2024/9/27,32,用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。,例如，喝水是一个有效的用例，而“喝和“水却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的.,但是我们所见的很多用例中类似“计算，“统计，“报表，“输出，“录入之类的并不在少数。,2024/9/27,33,3.2.5.2.,寻找和确定用例,业务用例,：开始阶段，在确定用户需求过程中，系统分析员通过与客户交流建立业务模型来发现和确定的用例。,系统用例,：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根据系统的需求建立的用例。,2024/9/27,34,在系统开发的开端阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例,2024/9/27,35,建立用例模型时，可询问：,用户(执行者)需要系统提供哪些业务功能,即系统能做什么?,用户最关心系统中哪些事件?从功能观点看,这些事件表示什么?,用户要了解系统在工作中发生了哪些事件及其结果?,用户自己需要做什么?,用户是否要在系统中创立、删除、读、修改或存储某类业务数据？,系统为了维持正常运转需要增加的功能和信息的交互；,这些信息从何而来，到哪里去？,实现当前系统可能是人工系统而不是自动化系统的关键问题是什么？,2024/9/27,36,通过与用户反复交流，确定主要业务用例和次要业务用例。,对于建立的每一个业务用例，都需要一组系统用例来辅助和支持。不严谨,系统用例是执行者与系统的交互，它描述了系统的功能需求和动态行为。,系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例。活动图,2024/9/27,37,如何获得用例,访谈,您对系统有什么期望？,您打算在这个系统里面做些什么事情？,您做这件事的目的是什么？,您做完这件事情希望有一个什么样的结果？,一个明确的有效地目标才是一个用例的来源。,一个真实的目标应当完备地表达执行者的期望。,一个有效地目标应当在系统边界内，由主角发动，并具有明确的后果。,2024/9/27,38,应领先建立业务用例模型，然后再从业务用例模型向系统用例模型映射。,注意用例图的层次，从系统到子系统逐层建立用例图。,2024/9/27,39,用例和功能的误区,用例就是功能划分？,在描述一个事物的时候，我们可以从以下三个观点出发：,这个事物是什么？结构性观点,这个事物能做什么？功能性观点,人们能用这个事物做什么？使用者观点,2024/9/27,40,结构性观点：自行车是一种交通工具，它由传动系统、刹车系统等局部组成。,功能性观点：自行车可以骑行。,使用者观点：人们可以用双脚蹬动踏板而向前行进，可以用手捏合刹车使自行车停下来。,2024/9/27,41,总结：,功能是脱离使用者的愿望而存在的。,功能是孤立的，给一个输入，通过计算就有一个固定的输出只要按下开关灯就亮。,用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯，结果是什么。,功能描述的是一个个点。,用例描述的是一个系统性工作。,2024/9/27,42,目标和步骤的误区,2024/9/27,43,用例的粒度,ATM,取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？,用例粒度的划分,最标准的方法,应该是：,以该用例是否完成了参与者的某个完整目的为依据的,。,同一个需求阶段，用例的粒度应该时,同一级别的,。,粒度选取的问题本质上还是因为,边界认定不同,而产生的。,2024/9/27,44,ATM例如,客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳水费、电费和 等费用；为了平安起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。,2024/9/27,45,判断题,支持跨行业务,插入卡片,输入密码,选择效劳,取钱,存钱,挂失卡片,交纳费用,警示骗子,三次错误吞没卡片,2024/9/27,46,判断题参考答案,支持跨行业务错，这是一个业务规那么，限定业务的范围,插入卡片错，这是一个过程步骤，不是完整目标,输入密码错，这是一个过程步骤，不是完整目标,选择效劳错，这是一个过程步骤，不是完整目标,取钱对，这是一个完整有效的目标,存钱对，这是一个完整有效的目标,挂失卡片对，这是一个完整有效的目标,交纳费用对，这是一个完整有效的目标,警示骗子错，已超出了边界范围,三次错误吞没卡片错，这是一个业务规那么，限定业务的范围,2024/9/27,47,3.2.5.3.,描述用例,用例名：,简单名：,路径名：,2024/9/27,48,用例的文字描述,应包括以下内容:,用例的目的功能；,该用例在什么情况下被哪个执行者启动执行；,用例与执行者之间交互哪些消息来通知对方作出决定；,交互的主消息流及因此被使用或修改的实体；,用例中可供选择的异常事件流；,用例结束标志：给执行者返回一个可识别的值。,2024/9/27,49,举例,用例名称：学生选课 执行者：学生,目的：完成一次学生选课的完整过程。,类型：主要的、根本的,级别：一级,过程描述：,1学生输入标识码ID，系统识别标识码的有效性；,2对学生进行注册识别；,3流览本学期预开课程；,4选择学生自己要上的课程并确认；,5退出系统，系统给出所选课程列表及相应学分合计。,2024/9/27,50,异常事件流处理：,1标识码有效性检查失败，允许学生重新输入3次时机。,2注册识别失败，没有注册尙未交学费的学生不能选课。,3选择课程确认失败，所选几门课程中在上课时间上发生冲 突时，系统提示重选。,2024/9/27,51,3.2.6 用例之间的关联,1继承关联,2.,扩展关联,3.,包含关联,4.,使用关联,2024/9/27,52,1.,继承关联,-,泛化,(generalization),当多个用例,共同拥有一种类似的结构和行为,的时候,我们可以将它们的共性抽象成为父用例，其他的用例,作为泛化关系中的子用例。,2024/9/27,53,泛化举例一：,2024/9/27,54,泛化举例二：,2024/9/27,55,2.扩展(extend),箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为根本用例。,扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。,2024/9/27,56,扩展(extend),将扩展用例的事件流在一定的条件下按照相应的扩展点插入到根底用例中。,根底用例不必知道扩展用例的任何细节，它仅为其提供扩展点。,扩展用例的行为是否被执行要取决于主事件流中的判定点。,2024/9/27,57,扩展(extend),2024/9/27,58,扩展(extend),扩展举例一：,2024/9/27,59,扩展(extend),扩展举例二：,2024/9/27,60,3.包含(include),包含是指根本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到根底用例的事件流中。包含用例是可重用的用例多个用例的公共用例。,2024/9/27,61,包含(include),箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为根本用例。,包含用例是必选的，如果缺少包含用例，根底用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。,2024/9/27,62,包含(include),2024/9/27,63,包含(include),包含举例一：,2024/9/27,64,包含(include),包含举例二：,2024/9/27,65,用例之间的关系,包含用例与扩展用例的区别,相对于根底用例，扩展用例是可选的，而包含用例那么不是。,如果缺少扩展用例，根底用例还是完整的，而缺少包含用例，那么根底用例就不完整了。,扩展用例的执行需要满足某种条件，而包含用例不需要。,扩展用例的执行会改变根底用例的行为，而包含用例不会。,2024/9/27,66,使用关联,使用关联也是一种继承关系,.,在使用关联中,一个用例使用另一个用例的功能和行为,.,2024/9/27,67,考虑用例的关联类型,2024/9/27,68,2024/9/27,69,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,仍然是个完整的用例？,(,a),是的(,b),不是,5).4,能够参与,2,吗？,1,能够参与,5,吗？,(,a),可以，不可以 (,b),不可以，可以,习题答案,：,1,、(,a)(d) 2,、(,b)(c) 3,、(,b) 4,、(,b) 5,、(,b),习题,2024/9/27,70,3.2.7 用例图实例,2024/9/27,71,3.3 定义系统的对象和类(第4章讲),类-责任-协作者简称CRC技术.,2024/9/27,72,3.4 客户需求分析规格说明,2024/9/27,73,补充知识点：,ROSE,用例视图,在Rose用例视图中，可建立系统的用例模型，它包含所有的角色、用例、用例图，还可能包含一些描述用例功能的顺序图、活动图。,Rose用例模型分成两个层次：,业务用例模型Business Use Case Model,系统用例模型System Use Case Model,业务用例模型关注的是企业的业务功能，系统建立前的组织机构、角色和他们之间的相互关系，即机构内部实际业务工作流。,系统用例模型是针对将创立的系统描述其功能需求。,用例图模型只是描述系统及其功能需求，不考虑系统设计与实现。,2024/9/27,74,建立业务用例模型的目的：,了解企业的组织机制；,了解企业组织中当前存在的问题并确定改进的可能性；,确保客户、最终用户和开发人员就企业业务流程达成共识；,描述企业部门的业务功能。,一、业务用例模型,业务用例模型是企业最核心、最概括的业务说明，主要由以下两局部组成。,业务角色和业务员工。一个角色既可以是一个用户，也可以是一个信息系统。业务角色是机构外部与机构交互的对象，业务角色与企业的业务活动有关；业务员工是机构内部的角色，通过描述每个业务员工，可以了解这些角色在系统中的责任和活动。,1,、业务用例模型的组成,2024/9/27,75,2、业务用例模型的根本元素,业务用例,。业务用例是机构中的一组相关工作流。机构中的全部用例一起完整地描述了企业的业务目标。这些业务用例是建立新系统的功能需求。,2024/9/27,76,l业务角色BusinessActor,业务角色是与企业机构交互的一切人或系统。业务角色不包含单位机构内部人员。,2业务员工BusinessWorker,业务员工是企业机构内部人员，代表业务中的一个或一组角色。业务员工参与业务用例实现时，业务员工和业务用例进行交互，并使用和控制业务实体。,3业务用例BusinessUseCase,业务用例是企业中的一组相关工作流，对业务角色提供效劳。业务用例描述告诉人们单位机构做什么，以及做什么会有利于业务和参与人员的工作，单位中的全部业务用例一起完整地描述业务目标。,4业务实体Business Entity,业务实体也被称为业务对象Business Object 业务实体代表业务角色中处理或使用的“事物。例如超市管理系统中涉及到很多业务实体：购物清单、订货清单等。业务实体是企业中很根本的要素。,2024/9/27,77,5部门单元Organization Unit,部门单元是业务员工、业务实体和业务模型元素的集合，部门单元是系统中组织机构的描述。,2、业务用例模型的创立,1部门单元,一般企业机构都是以业务职能设置机构。如超市按业务职能可划分为以下部门：销售部、库存管理部、订货管理部、统计管理部等，它们是超市组织机构的反映。,下面以超市进销存系统为例，描述其业务用例模型。,2024/9/27,78,2024/9/27,79,2业务角色与业务员工,2024/9/27,80,3业务用例分析,业务用例分析是对企业各部门现行的业务建模。业务建模时，必须有系统分析人员、业务人员共同完成。建立的业务模型是新开发系统的环境、根底。,以超市销售管理的业务过程为例，描述如下：售货员接收顾客的购物，按购置的商品价格和总数计算总价，顾客完成付款，开具购物清单交给顾客。,由以上的描述可以看出，超市销售管理的业务角色是,顾客,。顾客是公司外部的角色；,售货员,是业务员工，他处理公司的内部事务；业务用例是,商品销售,，它对公司销售业务的概括说明。售货员启动商品销售用例，顾客从商品销售用例得到销售清单。,2024/9/27,81,2024/9/27,82,3业务用例模型图的创立,创立部门单元包,创立业务角色和员工,创立业务用例,建立业务用例关联,描述业务用例细节,业务用例图的修改完善,2024/9/27,83,二、系统用例模型,系统用例模型描述系统中的用例与角色间的交互，主要针对系统自动化后的过程，演示系统的需求，描述系统的功能。系统用例模型不再将企业或企业一个部门作为一个功能的整体，而是划分得相对详细一些。在系统用例模型中，一般把各系统划分成子系统，用不同的包来建模。系统的大局部信息都可以从系统用例图中看到。,图素,业务用例模型,系统用例模型,用例,描述部门业务,描述业务中的工作,角色,部门外的,系统外,业务人员,部门内的,不使用,业务用例图模型与系统用例图模型使用的图素区别,2024/9/27,84,
展开阅读全文