02需求分析与用例建模

9.3 面向对象的需求分析
– 用例组织： 对用例图分层
9.3 面向对象的需求分析
– 用例组织注意：在建模的开始阶段，不要对它 进行过细的分解，以免使得模型中出现过多的 用例而影响了对系统功能和结构的总体把握。
3.5.3 层次化用例图
用例的粒度问题
(1) 用例的粒度问题 对于一个目标系统进行用例分析后得到
财务管理系统、生产调度管理系统。
（3）系统运行用户界面 销售合同管理用户界面 采购合同管理用户界面 仓库货物清单管理用户界面
（4）系统运行的软件、硬件环境 1）系统运行的软件环境 2）系统运行的硬件环境
3.6.2 确定系统范围和系统边界
1．进销存管理子系统的业务范围 2．进销存管理子系统的系统边界
• 9.3.4 系统需求建模 – 系统需求建模：将业务需求转化成系统需 求。
• 业务需求主要是从用户的角度去分析系统的业务流 程；
• 系统需求则是从开发者的角度去分析业务流程，并 得出新系统要实现的功能。
– 系统用例模型比业务用例模型更详细、更 具说明性。
9.3 面向对象的需求分析
• 9.3.4.1 系统参与者与系统用例
– 系统用例：为了反映用户界面约束之类的实现 细节，从业务用例中导出应用性的用例，称为 系统用例。
• 可以从一个业务用例中导出一个或多个系统用例。 • 开发人员使用这种用例说明详细的需求，辅助评价和规划，交
流编程需求，形成用户文档的基础。
9.3 面向对象的需求分析
• 9.3.4.2 确定用例间的关系：包含、泛化和扩展
• 请用ＵＭＬ画出其用例图，并写出详细的用例描述。
练习二
3.6 需求分析用例建模案例
3.6.1 客户需求分析
1．业务组织结构（综述）
“企业综合信息管理系统”的用户是企业各级管理部门 的工作人员、公司经理和系统操作人员。该系统主要提供 “财务管理”、“人力资源管理”、“生产调度管理”、 “进销存管理”、“设备安全管理”、和“行政事务管理” 等方面的服务。
⒈ 系统参与者：
– 也称角色，是与所建系统交互的人或物。 – 它与业务需求建模中的参与者有所不同，前者是从业
务层分析与系统相关的事物，这里的角色主要是和系 统直接交互的参与者。
9.3 面向对象的需求分析
⒉ 系统用例：
– 业务需求用例：面向业务，反映了系统期望行 为的高层视图。其中没有技术细节，并可以包 含手工活动和将被自动化的活动。
– 业务需求分析首先要从分析和认识现行组织系 统入手。
9.3 面向对象的需求分析
创建业务需求用例模型步骤：
确定业务参与者 确定业务需求用例
创建用例模型 描述业务需求用例
9.3 面向对象的需求分析
1.确定业务参与者：
– 业务参与者又称业务角色，是指在业务中扮演 某种角色的事物，可以是人、部门或独立的软 件系统。
⒉ 确定业务需求用例 – 业务需求用例：
• 反映了用户与系统的交互过程，是实际业务的一部 分，并没有技术细节和实现细节。
• 用例命名：动词+名词，如录入教职工信息。
– 在业务需求分析阶段，出于时间和经费的考虑， 只粗略地确定和记录最关键、最复杂和最重要 的用例，称为基本用例。
9.3 面向对象的需求分析
扩展关系：一个基本用例执行时, 可以执行或不执行扩展 用例.
包含关系：执行基本用例时, 一定会执行包含用例.
用例要采用多种控制方式对异常或任选动作进行处理时， 采用扩展关联。
两个以上用例重复处理同样的动作，可以采用使用关联或 包含关联。
一个用例偶尔使用另一个用例的功能描述时，采用继承关 联。
9.3 面向对象的需求分析
⒊ 创建用例模型
– 用例模型：描述系统范围和边界，参与者和用例之间 的关系。
– 用例模型图中不支持双向箭头，只绘出触发用例的参 与者，即发起参与者，而接受参与者通常略去。
9.3 面向对象的需求分析
⒋ 描述业务需求用例
9.3 面向对象的需求分析
9.3 面向对象的需求分析
用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执
行者：“财务管理子系统”和“生产调度管理子系
统”。
目 的: 合同管理员将与客户签订的销售合同的详细内容录 入管理系统，用于对销售合同进行统计、查询、检查 是否履约等，监控正在履约的合同。
类 型： 端点、主要的、基本的 级 别： 一级
02 需求分析与用例建模
掌握：
面向对象需求分析方法 用例建模（用例图） 活动图
9.3 面向对象的需求分析
• 9.3.1 面向对象的需求分析 从业务模型到系统
业务需求建模
系统需求建模

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