需求分析与用例建模课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,02 需求分析与用例建模,掌握：,面向对象需求分析方法,用例建模（用例图）,活动图,9.3 面向对象的需求分析,9.3.1 面向对象的需求分析,业务需求建模,系统需求建模,从业务模型到系统,9.3 面向对象的需求分析,9.3.3 业务需求建模,构造业务需求模型的目的：提取和分析足够的信息需求，准备一个模型，该模型表述了用户需要什么，而不涉及系统将如何构造和实现的特定细节。,业务需求分析首先要从分析和认识现行组织系统入手。,9.3 面向对象的需求分析,确定业务参与者,确定业务需求用例,创建用例模型,描述业务需求用例,创建业务需求用例模型步骤：,9.3 面向对象的需求分析,1.,确定,业务参与者,：,业务参与者又称业务角色，是指在业务中扮演某种角色的事物，可以是人、部门或独立的软件系统。,怎样识别活动者？,谁向系统提供信息？,谁从系统获取（使用）信息？,谁操作系统？,谁维护系统？,系统使用哪些外部资源？,系统是否和已经存在的系统交互？,由于Actor实际上是一个,类, 因此它们之间可以存在一定的关系,如：,执行者之间可以有继承关系。,9.3 面向对象的需求分析, 确定,业务需求用例,业务需求用例：,反映了用户与系统的交互过程，是实际业务的一部分，并没有技术细节和实现细节。,用例命名：动词+名词，如录入教职工信息。,在业务需求分析阶段，出于时间和经费的考虑，只粗略地确定和记录最关键、最复杂和最重要的用例，称为,基本用例,。,9.3 面向对象的需求分析,寻找业务需求用例的方法：,检查参与者以及他们如何使用系统。,可以通过下列问题来寻找业务用例：,参与者的主要任务是什么？,参与者需要系统什么信息？,参与者为系统提供什么信息？,参与者是否需要系统的反馈信息？如果需要的话，需要什么样的反馈信息？,9.3 面向对象的需求分析,9.3 面向对象的需求分析,9.3 面向对象的需求分析, 创建,用例模型,用例模型：描述系统范围和边界，参与者和用例之间的关系。,用例模型图中不支持双向箭头，只绘出触发用例的参与者，即发起参与者，而接受参与者通常略去。,9.3 面向对象的需求分析,9.3 面向对象的需求分析,描述,业务需求,用例,9.3 面向对象的需求分析,9.3.4 系统需求建模,系统需求建模：将业务需求转化成系统需求。,业务需求主要是从,用户的角度,去分析系统的业务流程；,系统需求则是,从开发者的角度,去分析业务流程，并得出新系统要实现的功能。,系统用例模型比业务用例模型更详细、更具说明性。,9.3 面向对象的需求分析,9.3.4.1 系统参与者与系统用例,系统参与者,：,也称角色，是与所建系统交互的人或物。,它与业务需求建模中的参与者有所不同，前者是从业务层分析与系统相关的事物，这里的角色主要是,和系统直接交互的参与者,。,9.3 面向对象的需求分析,系统用例,：,业务需求用例：面向业务，反映了系统期望行为的高层视图。其中没有技术细节，并可以包含,手工活动和将被自动化,的活动。,系统用例：为了反映用户界面约束之类的实现细节，从业务用例中导出应用性的用例，称为系统用例。,可以从一个业务用例中导出一个或多个系统用例。,开发人员使用这种用例说明详细的需求，辅助评价和规划，交流编程需求，形成用户文档的基础。,9.3 面向对象的需求分析,9.3.4.2 确定用例间的关系：包含、泛化和扩展,基本用例：通常称为业务用例或抽象用例，而在以后各阶段的用例，是为了满足系统的要求而演变来的。这些用例和基本用例之间存在如下关系：,包含关系,基本用例的行为包含了另一个用例的行为（公共行为）。箭头从基本用例指向公共用例。,往往是一个用例功能过多需分解成小用例，构成包含依赖。,9.3 面向对象的需求分析,泛化关系,代表一般与特殊的关系（继承）。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。,9.3 面向对象的需求分析,扩展关系,基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。,4,使用关联,几种关系的比较,扩展关系：一个基本用例执行时,可以执行或不执行扩展用例,.,包含关系：执行基本用例时,一定会执行包含用例,.,用例要采用多种控制方式对异常或任选动作进行处理时，采用,扩展关联,。,两个以上用例重复处理同样的动作，可以采用使用关联或,包含关联,。,一个用例偶尔使用另一个用例的功能描述时，采用,继承关联,。,9.3 面向对象的需求分析,9.3.4.3 构造系统用例模型,业务需求用例模型转换成系统用例模型步骤：, 确定、定义并记录新的参与者。, 确定、定义并记录新的用例。, 确定任何复用的可能性。, 细化用例模型图。, 记录系统用例描述。,用例图 = 参与者 + 用例 + 关系,Use Case Diagram = Actors + Use Cases + Relationships,9.3 面向对象的需求分析,第1步：识别新的参与者,系统分析员与用户人员交谈继续了解系统功能需要什么。通过这些努力，有可能会发现需要被定义和记录的新的参与者。,9.3 面向对象的需求分析,第2步：识别新的用例,新的参与者产生了新的用例。,第3步：精简用例步骤,提取公共步骤形成独立的共享公共用例：包含用例、泛化用例、扩展用例。,9.3 面向对象的需求分析,9.3 面向对象的需求分析,第4步：细化用例模型图,对于增加的新参与者和用例，修改前面构造的用例模型图。,9.3 面向对象的需求分析,第5步：记录系统分析用例描述,描述系统用户用来与系统交互的手段、过程，没有太多的实现细节。,9.3 面向对象的需求分析,9.3 面向对象的需求分析,9.3.4.4 用例的组织,用例的组织：,较大的系统往往包含许多用例，为了更好地理解和管理它们，在分析用例的过程中可以把用例按照一定的逻辑关系组合成子系统。,包：,将一些关系紧密的用例放到一个包里，并且为包确定一个主题。 用UML中的包（Package）符号表示。,9.3 面向对象的需求分析,用例组织： 对用例图分层,9.3 面向对象的需求分析,用例组织注意：在建模的开始阶段，不要对它进行过细的分解，以免使得模型中出现过多的用例而影响了对系统功能和结构的总体把握。,3.5.3 层次化用例图,(1) 用例的粒度问题,对于一个目标系统进行用例分析后得到的用例数目有多少比较合适?,用例的粒度问题,用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右。,(2) 用例的分解/合并,系统中相似的功能, 是合并为一个用例还是分解为几个用例?,方法1,一个用例/三个脚本(scenario),方法2 三个用例,用例的粒度问题,情景、场景、情节、剧本,练习一,有一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够删除记录。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时限进行统计。,练习一,通常结果,可选结果,实例优化,优化结果1,优化结果2,练习二,网上选课系统：,管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。管理员负责维护各项信息。这些操作结果存入数据库中。,请用画出其用例图，并写出详细的用例描述。,练习二,3.6.1 客户需求分析,1,业务组织结构（综述）,“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。该系统主要提供“财务管理”、“人力资源管理”、“生产调度管理”、“进销存管理”、“设备安全管理”、和“行政事务管理”等方面的服务。,3.6 需求分析用例建模案例,2,具体功能要求,本案例只对其中的“进销存管理子系统”进行详细的需求分析用例建模。,（,1,）销售管理,1,）制定销售计划,2,）与客户签订销售合同,3,）检查合同履约率,4,）生产调度管理部门组织生产,5,）库存管理部门对产品进行入库、出库处理,6,）财务管理部门收取客户货款,7,）售后服务,（,2,）采购管理,1,）制定原材料（零部件）采购计划,2,）与客户签订采购合同,3,）检查合同履约率,4,）库存管理部门对原材料进行入库验收、存储,5,）财务管理部门支付货款,（,3,）库存管理,1,）产品入库管理,2,）原材料（零部件）入库管理,3,）原材料（零部件）出库管理,4,）产品出库管理,5,）库存管理,6,）采购管理部门组织采购,7,）生产调度管理部门安排生产,8,）财务管理部门对库存物资进行核算,3,需求补充说明,（,1,）数据保存,采购合同：每个合同执行期可能多达几个月，合同,需要长期保留。,销售合同：每个合同执行期可能多达几个月，合同,需要长期保留,。,历年履约合同：履约后的合同需要长期（几十年）,保留，以备查使用。,库存货物清单：库存货物量随出、入库有所消长，,长期保存。,货物损毁报表：长期保留，以备查使用。,入库单：长期保留，以备查核算使用。,出库单：长期保留，以备查核算使用。,库存货物资产核对表：长期保留，以备查使用。,（2）系统的用户,客户、仓库管理员、销售人员、采购人员、公司经理、财务管理系统、生产调度管理系统。,（3）系统运行用户界面,销售合同管理用户界面,采购合同管理用户界面,仓库货物清单管理用户界面,（4）系统运行的软件、硬件环境,1）系统运行的软件环境,2）系统运行的硬件环境,3.6.2 确定系统范围和系统边界,1进销存管理子系统的业务范围,2进销存管理子系统的系统边界,3.6.3 确定执行者,“进销存管理子系统”有,5,个人执行者和,2,个系统执行者，即“采购人员”、“销售人员”、“仓库管理员”、“客户”、“公司经理”、“生产调度管理子系统”和,“,财务管理子系统”。,3.6.4 确定用例,（1）“企业综合信息管理系统”中的用例（一层）,财务管理；,人力资源管理；,生产调度管理；,进销存管理；,设备安全管理；,行政事务管理。,（,2,）“进销存管理子系统”中的用例（第二层）,销售管理；,采购管理；,库存管理。,（3）“销售管理子系统”中的用例（第三层）,制定产品销售计划；签订销售合同；,督促客户付款；监督产品发货；,检查合同履约；提供售后服务。,（,4,）“采购管理子系统”中的用例（第三层）,制定采购计划；签订采购合同；,货物入库检验；支付货款；检查合同履约。,（,5,）“库存管理子系统”中的用例（第三层）,入库管理；,出库管理；,库存管理。,3.6.5 分层绘制用例图,1,最高层用例图,2,第,2,层用例图,3,第,3,层用例图,4,第,4,层用例图,3.6.6 描述用例,1,“增加销售合同”用例,用例编号：（共有,4,层用例图结构，每层用,2,位数字表,示， 采用,8,位编号。）,用例名：,增加销售合同,执行者: 人执行者：合同管理员、客户、公司经理。系统执,行者：“财务管理子系统”和“生产调度管理子系统”,。,目 的: 合同管理员将与客户签订的销售合同的详细内容录入管理系统，用于对销售合同进行统计、查询、检查是否履约等，监控正在履约的合同。,类 型：,端点、主要的、基本的,级 别：,一级,过程描述：,（,1,）合同管理员输入标识码（,ID,），系统识别标识码的有效性；,（,2,）初始化一个新销售合同，设置各种处室标志；,（,3,）输入一个新的具有唯一性的合同编号；,（,4,）将与客户签订的销售合同的详细内容录入管理系统；,（,5,）退出系统。,与其它用例的关联：过程描述（,1,）中包含身份验证用例；（,4,）中包含编号自动生成用例。,异常事件流处理：,（,1,）标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。,（,2,）编号也可以由合同管理员手动输入，系统自动进行唯一性检查。出现错误，允许重新输入。,9.3 面向对象的需求分析,9.3.4.5 用活动图描述系统用例,UML为我们提供了一种描述用例结构的工具活动图；,活动图是用来图形化地描述业务过程、用例的步骤和对象行为（方法）的逻辑的流程的图形。,活动图的基本符号,示例,示例,示例,示例,需求规格说明书,