需求分析与用例建模.pptx

《需求分析与用例建模.pptx》由会员分享，可在线阅读，更多相关《需求分析与用例建模.pptx（63页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、9.3 面向对象的需求分析9.3.3 业务需求建模构造业务需求模型的目的：提取和分析足够的信息需求，准备一个模型，该模型表述了用户需要什么，而不涉及系统将如何构造和实现的特定细节。业务需求分析首先要从分析和认识现行组织系统入手。第1页/共63页9.3 面向对象的需求分析 确定业务参与者确定业务需求用例创建用例模型描述业务需求用例创建业务需求用例模型步骤：第2页/共63页9.3 面向对象的需求分析1.确定业务参与者：业务参与者又称业务角色，是指在业务中扮演某种角色的事物，可以是人、部门或独立的软件系统。怎样识别活动者？谁向系统提供信息？谁从系统获取（使用）信息？谁操作系统？谁维护系统？系统使用哪

2、些外部资源？系统是否和已经存在的系统交互？第3页/共63页第4页/共63页由由于于ActorActor实实际际上上是是一一个个类类,因因此此它它们们之之间间可可以以存存在在一一定定的的关关系系,如：如：执行者之间可以有继承关系。执行者之间可以有继承关系。第5页/共63页9.3 面向对象的需求分析 确定业务需求用例 业务需求用例：反映了用户与系统的交互过程，是实际业务的一部分，并没有技术细节和实现细节。用例命名：动词+名词，如录入教职工信息。在业务需求分析阶段，出于时间和经费的考虑，只粗略地确定和记录最关键、最复杂和最重要的用例，称为基本用例。第6页/共63页9.3 面向对象的需求分析寻找业务需

3、求用例的方法：检查参与者以及他们如何使用系统。可以通过下列问题来寻找业务用例：参与者的主要任务是什么？参与者需要系统什么信息？参与者为系统提供什么信息？参与者是否需要系统的反馈信息？如果需要的话，需要什么样的反馈信息？第7页/共63页9.3 面向对象的需求分析第8页/共63页9.3 面向对象的需求分析第9页/共63页9.3 面向对象的需求分析 创建用例模型 用例模型：描述系统范围和边界，参与者和用例之间的关系。用例模型图中不支持双向箭头，只绘出触发用例的参与者，即发起参与者，而接受参与者通常略去。第10页/共63页9.3 面向对象的需求分析第11页/共63页9.3 面向对象的需求分析 描述业务

4、需求用例第12页/共63页9.3 面向对象的需求分析9.3.4 系统需求建模系统需求建模：将业务需求转化成系统需求。业务需求主要是从用户的角度去分析系统的业务流程；系统需求则是从开发者的角度去分析业务流程，并得出新系统要实现的功能。系统用例模型比业务用例模型更详细、更具说明性。第13页/共63页9.3 面向对象的需求分析9.3.4.1 系统参与者与系统用例 系统参与者：也称角色，是与所建系统交互的人或物。它与业务需求建模中的参与者有所不同，前者是从业务层分析与系统相关的事物，这里的角色主要是和系统直接交互的参与者。第14页/共63页9.3 面向对象的需求分析 系统用例：业务需求用例：面向业务，

5、反映了系统期望行为的高层视图。其中没有技术细节，并可以包含手工活动和将被自动化的活动。系统用例：为了反映用户界面约束之类的实现细节，从业务用例中导出应用性的用例，称为系统用例。可以从一个业务用例中导出一个或多个系统用例。开发人员使用这种用例说明详细的需求，辅助评价和规划，交流编程需求，形成用户文档的基础。第15页/共63页9.3 面向对象的需求分析9.3.4.2 确定用例间的关系：包含、泛化和扩展基本用例：通常称为业务用例或抽象用例，而在以后各阶段的用例，是为了满足系统的要求而演变来的。这些用例和基本用例之间存在如下关系：包含关系基本用例的行为包含了另一个用例的行为（公共行为）。箭头从基本用例

6、指向公共用例。第16页/共63页往往是一个用例功能过多需分解成小用例，构成包含依赖。第17页/共63页9.3 面向对象的需求分析 泛化关系 代表一般与特殊的关系（继承）。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。第18页/共63页9.3 面向对象的需求分析 扩展关系 基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。第19页/共63页4使用关联使用关联第20页/共63页第21页/共63页几种关系的比较扩展关系：一个基本用例执行时扩展关系：一个基本用例执行时,可以执行或不执行扩展用例可以执行或不执行扩展用例.包含关系

7、：执行基本用例时包含关系：执行基本用例时,一定会执行包含用例一定会执行包含用例.用例要采用多种控制方式对异常或任选动作进行处理时，采用用例要采用多种控制方式对异常或任选动作进行处理时，采用扩展关联扩展关联。两个以上用例重复处理同样的动作，可以采用使用关联或两个以上用例重复处理同样的动作，可以采用使用关联或包含关联包含关联。一个用例偶尔使用另一个用例的功能描述时，采用一个用例偶尔使用另一个用例的功能描述时，采用继承关联继承关联。第22页/共63页9.3 面向对象的需求分析9.3.4.3 构造系统用例模型业务需求用例模型转换成系统用例模型步骤：确定、定义并记录新的参与者。确定、定义并记录新的用例。

8、确定任何复用的可能性。细化用例模型图。记录系统用例描述。用例图=参与者+用例+关系Use Case Diagram=Actors+Use Cases+Relationships第23页/共63页9.3 面向对象的需求分析第1步：识别新的参与者系统分析员与用户人员交谈继续了解系统功能需要什么。通过这些努力，有可能会发现需要被定义和记录的新的参与者。第24页/共63页9.3 面向对象的需求分析第2步：识别新的用例新的参与者产生了新的用例。第3步：精简用例步骤提取公共步骤形成独立的共享公共用例：包含用例、泛化用例、扩展用例。第25页/共63页9.3 面向对象的需求分析第26页/共63页9.3 面向对

9、象的需求分析第4步：细化用例模型图对于增加的新参与者和用例，修改前面构造的用例模型图。第27页/共63页9.3 面向对象的需求分析第5步：记录系统分析用例描述描述系统用户用来与系统交互的手段、过程，没有太多的实现细节。第28页/共63页9.3 面向对象的需求分析第29页/共63页9.3 面向对象的需求分析 9.3.4.4 用例的组织用例的组织：较大的系统往往包含许多用例，为了更好地理解和管理它们，在分析用例的过程中可以把用例按照一定的逻辑关系组合成子系统。包：将一些关系紧密的用例放到一个包里，并且为包确定一个主题。用UML中的包（Package）符号表示。第30页/共63页9.3 面向对象的需

10、求分析用例组织：对用例图分层第31页/共63页9.3 面向对象的需求分析用例组织注意：在建模的开始阶段，不要对它进行过细的分解，以免使得模型中出现过多的用例而影响了对系统功能和结构的总体把握。第32页/共63页3.5.3 层次化用例图第33页/共63页(1)用例的粒度问题 对于一个目标系统进行用例分析后得到的用例数目有多少比较合适?用例的粒度问题用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右。第34页/共63页(2)用例的分解/合并 系统中相似的功能,是合并为一个用例还是分解为几个用例?方法1一个用例/三个脚本(scenario)方法2 三个用例用例的粒度问题情景、场景、

11、情节、剧本第35页/共63页练习一有一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够删除记录。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时限进行统计。第36页/共63页练习一通常结果可选结果第37页/共63页实例优化优化结果1优化结果2第38页/共63页练习二网上选课系统：管理员通过系统管理界面进入，建

12、立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。管理员负责维护各项信息。这些操作结果存入数据库中。请用画出其用例图，并写出详细的用例描述。第39页/共63页练习二第40页/共63页3.6.1 客户需求分析1业务组织结构（综述）“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。该系统主要提供“财务管理”、“人力资源管理”、“生产调度管理”、“进销存管理”、“设备安全管理”、和“行政事务管理”等方面的服务。3.6 需求分析用

13、例建模案例第41页/共63页2具体功能要求 本案例只对其中的“进销存管理子系统”进行详细的需求分析用例建模。（1）销售管理1）制定销售计划2）与客户签订销售合同3）检查合同履约率4）生产调度管理部门组织生产5）库存管理部门对产品进行入库、出库处理6）财务管理部门收取客户货款7）售后服务第42页/共63页（2）采购管理1）制定原材料（零部件）采购计划2）与客户签订采购合同3）检查合同履约率4）库存管理部门对原材料进行入库验收、存储5）财务管理部门支付货款（3）库存管理1）产品入库管理2）原材料（零部件）入库管理3）原材料（零部件）出库管理4）产品出库管理5）库存管理6）采购管理部门组织采购7）生

14、产调度管理部门安排生产8）财务管理部门对库存物资进行核算第43页/共63页3需求补充说明（1）数据保存 采购合同：每个合同执行期可能多达几个月，合同 需要长期保留。销售合同：每个合同执行期可能多达几个月，合同 需要长期保留。历年履约合同：履约后的合同需要长期（几十年）保留，以备查使用。库存货物清单：库存货物量随出、入库有所消长，长期保存。货物损毁报表：长期保留，以备查使用。入库单：长期保留，以备查核算使用。出库单：长期保留，以备查核算使用。库存货物资产核对表：长期保留，以备查使用。第44页/共63页（2）系统的用户 客户、仓库管理员、销售人员、采购人员、公司经理、财务管理系统、生产调度管理系统

15、。（3）系统运行用户界面 销售合同管理用户界面 采购合同管理用户界面 仓库货物清单管理用户界面（4）系统运行的软件、硬件环境 1）系统运行的软件环境 2）系统运行的硬件环境第45页/共63页3.6.2 确定系统范围和系统边界1进销存管理子系统的业务范围2进销存管理子系统的系统边界 3.6.3 确定执行者“进销存管理子系统”有5个人执行者和2个系统执行者，即“采购人员”、“销售人员”、“仓库管理员”、“客户”、“公司经理”、“生产调度管理子系统”和“财务管理子系统”。第46页/共63页3.6.4 确定用例（1）“企业综合信息管理系统”中的用例（一层）财务管理；人力资源管理；生产调度管理；进销存管

16、理；设备安全管理；行政事务管理。（2）“进销存管理子系统”中的用例（第二层）销售管理；采购管理；库存管理。第47页/共63页（3）“销售管理子系统”中的用例（第三层）制定产品销售计划；签订销售合同；督促客户付款；监督产品发货；检查合同履约；提供售后服务。（4）“采购管理子系统”中的用例（第三层）制定采购计划；签订采购合同；货物入库检验；支付货款；检查合同履约。（5）“库存管理子系统”中的用例（第三层）入库管理；出库管理；库存管理。第48页/共63页3.6.5 分层绘制用例图1最高层用例图第49页/共63页2第2层用例图第50页/共63页3第3层用例图第51页/共63页4第4层用例图第52页/共

17、63页第53页/共63页3.6.6 描述用例1“增加销售合同”用例用例编号：04010101（共有4层用例图结构，每层用2位数字表 示，采用8位编号。）用例名：增加销售合同执行者:人执行者：合同管理员、客户、公司经理。系统执 行者：“财务管理子系统”和“生产调度管理子系统”。目 的:合同管理员将与客户签订的销售合同的详细内容录入管理系统，用于对销售合同进行统计、查询、检查是否履约等，监控正在履约的合同。类 型：端点、主要的、基本的级 别：一级 第54页/共63页过程描述：（1）合同管理员输入标识码（ID），系统识别标识码的有效性；（2）初始化一个新销售合同，设置各种处室标志；（3）输入一个新的

18、具有唯一性的合同编号；（4）将与客户签订的销售合同的详细内容录入管理系统；（5）退出系统。与其它用例的关联：过程描述（1）中包含身份验证用例；（4）中包含编号自动生成用例。异常事件流处理：（1）标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。（2）编号也可以由合同管理员手动输入，系统自动进行唯一性检查。出现错误，允许重新输入。第55页/共63页9.3 面向对象的需求分析9.3.4.5 用活动图描述系统用例UML为我们提供了一种描述用例结构的工具活动图；活动图是用来图形化地描述业务过程、用例的步骤和对象行为（方法）的逻辑的流程的图形。第56页/共63页活动图的基本符号第57页/共63页示例第58页/共63页示例第59页/共63页示例第60页/共63页示例第61页/共63页需求规格说明书第62页/共63页感谢您的观看！第63页/共63页