第6章 用例模型
合集下载
第6章 用例图
４、关系--Relationship
四种基本关系： 关联（association） 包含（include） 扩展（extend） 泛化（generalization）
（1）关联
描述参与者与用例之间的关系； 用单向箭头，表示谁启动用例； 每个用例都有角色启动，除包含和扩展 用例；
[即启动该用例所应该满足的条件。] [即该用例完成之后，将执行什么动作。] [描述当前目标完成后，环境变化情况。] 步骤 1 活动 [在这里写出触发事件到目标完成以及清除的步骤。]
2
扩展事件 流 子事件流 规则与约 束 1a 1b
……(其中可以包含子事件流，以子事件流编号来表示)
[1a表示是对1的扩展，其中应说明条件和活动] ……(其中可以包含子事件流，以子事件流编号来表示)
系统还需要进行意外处理
扩展事件流
事件流编写要点
使用简单的语法：主语明确，语义易于理解 明确写出“谁控制球”：通常就是指出参与 者； 从俯视的角度来编写：指出参与者的动作， 以及系统的响应，也就是跳开来； 显示过程向前推移：也就是每一步都有前进 的感觉
事件流编写要点
“确认”而不是“检查是否”；（如：系统 确认用户密码正确，而非系统检查用户密码 是否正确） 可选择地提及时间限制；
３、用例---Use Case
系统、子系统或类与外部的参与者 （actor）交互的动作序列的说明，包括 各种序列及出错序列。 用例分析可以认为是对系统功能的分解。
存款
Withraw Money
３、用例---Use Case
（1）用例的表示 简单名 路径名
３、用例---Use Case
第6章 用例图
3、构建用例模型
采 购 员 用 例 图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情 况统计所缺的生产资料，根据需要制定出订单。
UML统一建模语言
五、使用Rose创建用例图的步骤说明
3、构建用例模型
会 计 用 例 图
会计负责产品的统计分析 管理，它能够通过该系统 进行如下活动： （1）查询基本信息。会计 能够查询产品的基本信息， 根据产品的基本信息，制 定出相应的方案。 （2）查询销售信息。会计 根据销售情况汇总后交销 售部制定合理的销售方案。 （3）查询供应商信息。会 计能够查询供应商信息。 （4）查询缺货信息。会计 能够查询缺货信息。 （5）查询报损信息。会计 能够查询报损信息。
1、需求分析
“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息 统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、 处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产 品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及 时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进 行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、 查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使 用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定 价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、 供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登 录到各自的管理系统中。
第6章(2)PIM建模技术资料
– PSM
Warm up: Use Case & Use Case
Realization
• Use Case是描述需求的工具，把系统看做黑盒子。 • Use Case Realization在分析设计阶段做，不在视系统
为黑盒子，而是白盒子。
– 用分析和设计出来的类及它们之间的Collaboration来描述系统 如何完成Use Case。
– 指南：推荐的做法，在其解释、实施或使用中，允许有一定 的自由度或回旋余地。
• 10.把用例规约中的路径直接粘贴在鲁棒图的左边，以 便一一对应，逐项对象化；
• 9.直接利用域模型中的业务对象实体；
– 也用鲁棒图补充和完善域模型
• 8.在画鲁棒图时，要完善用例规约(去掉歧义)
– 画鲁棒图迫使作者逐句斟酌用例规约
• 鲁棒图示例 • 初步设计审核
– 目的与参与者 – 初步设计审核指导原则、指南和常犯的错误
• 软件体系结构及其模式*
– 体系结构风格、设计原则与常见错误 – 鲁棒图与MVC模式 – 新课程：软件体系结构
Warm up:Analysis and Design
• Design
– Realization of a concept or idea into a model or specification
• 分析模型和设计模型最早在Jacobson的OOSE中提出 来了，并非RUP首创。这两个模型的本质差别在于：
– 分析模型是对问题域的描述，独立于实现技术。 – 设计模型在使用具体技术实现分析模型。设计模型可以立即
拿去实施。 – 区分两种模型的目的：当实现技术改变时，重用分析模型。
• 基础：问题域不会如计算机技术发展得那么快。
Warm up: Use Case & Use Case
Realization
• Use Case是描述需求的工具，把系统看做黑盒子。 • Use Case Realization在分析设计阶段做，不在视系统
为黑盒子，而是白盒子。
– 用分析和设计出来的类及它们之间的Collaboration来描述系统 如何完成Use Case。
– 指南：推荐的做法，在其解释、实施或使用中，允许有一定 的自由度或回旋余地。
• 10.把用例规约中的路径直接粘贴在鲁棒图的左边，以 便一一对应，逐项对象化；
• 9.直接利用域模型中的业务对象实体；
– 也用鲁棒图补充和完善域模型
• 8.在画鲁棒图时，要完善用例规约(去掉歧义)
– 画鲁棒图迫使作者逐句斟酌用例规约
• 鲁棒图示例 • 初步设计审核
– 目的与参与者 – 初步设计审核指导原则、指南和常犯的错误
• 软件体系结构及其模式*
– 体系结构风格、设计原则与常见错误 – 鲁棒图与MVC模式 – 新课程：软件体系结构
Warm up:Analysis and Design
• Design
– Realization of a concept or idea into a model or specification
• 分析模型和设计模型最早在Jacobson的OOSE中提出 来了，并非RUP首创。这两个模型的本质差别在于：
– 分析模型是对问题域的描述，独立于实现技术。 – 设计模型在使用具体技术实现分析模型。设计模型可以立即
拿去实施。 – 区分两种模型的目的：当实现技术改变时，重用分析模型。
• 基础：问题域不会如计算机技术发展得那么快。
习 题_UML系统分析与设计教程（第2版）_[共2页]
![习 题_UML系统分析与设计教程（第2版）_[共2页]](https://img.taocdn.com/s3/m/5c2b4c2e0242a8956bece4db.png)
同样的技术也可以用于为子系统的需求建模。
对于图6.7所示的公司管理系统，该用例图可视化地描述了公司管理系统的功能需求，为最终用户、领域专家和开发人员之间的交流提供了途径。
该系统的重要行为包括雇员可以选择得到报酬的方式（用例“Select Payment Method”），可以对雇员进行考勤（用例“Maintain Timecard”），雇员可以创建工作报告（用例“Create Employee Report”），考勤记录和工作报告要保存在数据库中（用例“Maintain Timecard”和“Create Employee Report”与参与者“Project Management DB”通信，将数据保存在数据库中），管理员可以创建、修改、删除系统中雇员的信息（用例“Maintain Employee Information”），每月的固定时间要通过银行系统给雇员发薪水（参与者“System Clock”与用例“Run Payroll”通信，说明发薪水的时间到了，触发用例的行为，用例“Run Payroll”与参与者“Bank System”通信，将薪水发给雇员），并通过打印机打印出工资单（用例“Run Payroll”与参与者“Printer”通信，调用打印机打印出工资单）。
小 结用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。
用例图（Use Case Diagram）是UML中用来对系统的动态方面进行建模的7种图之一。
用例图描述了用例、参与者以及它们之间的关系。
本章介绍了用例图的语义和功能，描述了如何识别参与者、用例，如何使用事件流描述用例；还介绍了用例和脚本的关系，举例说明了用例间的类属关系、包含关系和扩充关系的语义、功能和应用；最后举例说明了如何使用用例图为系统的上下文以及系统的需求建模。
习 题6.1 用例图的功能是什么？6.2 如何识别出参与者？如何识别出用例？6.3 用例间存在哪几种关系？6.4 分析下述课程管理系统的问题描述。
第6章 用例图
•
基用例是可以独立于扩展用例存在的，只是在特定的条件下， 基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的 行为可以被另一个用例的行为所扩展
作者：冀振燕 《UML系统分析与设计教程》
23
泛化关系
作者：冀振燕 《UML系统分析与设计教程》
24
6.2 用例图建模技术
6.2.1 对语境建模 6.2.2 对需求建模
前置条件 后置条件 成功保证 基本事件流
[即启动该用例所应该满足的条件。] [即该用例完成之后，将执行什么动作。] [描述当前目标完成后，环境变化情况。] 步骤 1 2 活动 [在这里写出触发事件到目标完成以及清除的步骤。] ……(其中可以包含子事件流，以子事件流编号来表示) [1a表示是对1的扩展，其中应说明条件和活动] ……(其中可以包含子事件流，以子事件流编号来表示)
19
泛化关系
父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为 或覆盖、改变继承的行为。
作者：冀振燕 《UML系统分析与设计教程》
20
作者：冀振燕 《UML系统分析与设计教程》 含扩展和使用关系的用例图
21
• 图中的元素包括：参与者、用例、一个方框和一些表 图中的元素包括：参与者、用例、 • 所有的用例都位于方框之内，该方框称为“系统边界” 所有的用例都位于方框之内，该方框称为“系统边界” • 参与者与用例的关系：在参与者和用例之间的关联是 参与者与用例的关系： • 用例之间的关系： 用例之间的关系：
作者：冀振燕 《UML系统分析与设计教程》
14
例：新增图书用例
…… 3.事件流： 3.1 基本事件流 1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还 是非计算机类； 3）图书管理员做出选择后，显示相应界面，让图书管理 员输入信息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、 开本、页数、定价、是否有CDROM； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。 3.2 扩展事件流 5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理 …… 选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5） 4.非功能需求：无特殊要求 ……
第6章 用例图1
4.部署模型：定义可计算节点系统的物理结构，并 验证运行在这些节点上的构件想法是否实现了 用例。（构件图、部署图） 5.测试模型：根据用例中所描述的功能来构建测试 模型。 采用用例技术的优点有： 一，用例表达了用户对软件的目标要求，用例是 系统向其用户提供的增值功能。 二，用例很直观，用户和客户根本无法了解复杂 符号，而用例这种简单、自然的表述法可以使 其易于阅读，并提出修改意见。
开发者与用户、客户进行交流，构建场景和用 例规格描述。一个场景就是描述用户与系统之 间的一系列交互活动，描述了系统一次具体执 行的行为路径，即，一次完整的事件流。
例：小刘通过银行柜员机(ATM系统)取款3000元的场景
场景名称
参与者
取款3000元
客户小刘
事件流 1 小刘将银行卡插入柜员机 2 ATM机要求客户输入卡密码 3 小刘输入卡密码，并确认密码 4 柜员机屏幕提示，请客户选择服务类型 5 小刘选择取款服务 6 柜员机提示：请客户输入取款数目 7 客户输入3000,并确认 8 柜员机出钱口输出30张一佰元的人民币 9 小刘取回30张一佰元的人民币 10 柜员机提示服务类型：确认，或继续，或退卡 11 小刘选择服务类型退卡，结束服务。
用户故事(user story) 特性(Feature)
用例驱动开发过程
•
•
知名的“用例驱动”的开发过程有两个，一个就是重型 的RUP，另一个则是“离地1000公尺”的ICONIX
•
在这些开发过程中，开发人员首先捕获客户的需求，并 以用例的形式组织成用例模型。然后分析并设计系统来 满足这些用例，因此在用例模型之后就是分析模型，接 着是设计模型和实施模型。在实现了整个系统之后，还 将根据用例模型设计出测试模型来对系统进行验证
第6章统一建模语言UML
* 窗口 1 包含 *
列表框
按钮 菜单
*
/
（2）泛化关系
UML中的泛化关系就是通常所说的继承关系，它是 通用元素和具体元素之间的一种分类关系。 在UML中，用一端为空心三角形的连线表示泛化关 系，三角形的顶角紧挨着通用元素。
汽车 车厢
客车 客车车厢 载客
货车 货车车厢 载货
/
（3）依赖关系
/
2．用例
自动售货机系统 售货
顾客
供货
取货款
供货人
收银员
/
2．用例
概括地说，用例具有以下特点：
– 用例代表某些用户可见的功能，实现一个具体的 用户目标。 – 用例由执行者激活，并提供确切的值给执行者。 – 用例可大可小，但它必须是对一个具体的用户目 标实现的完整描述。
注意：用例是一个类，它代表一类功能而不 是使用该功能的某个具体实例。
/
2．UML的表示法
UML由视图、图、模型元素、通用机制和扩展机制 组成。 （1）视图
– UML视图有：静态视图、用例视图、实现视图、部署视图、 状态视图、活动视图、交互视图、模型管理视图8种。
（2）图
– 共五类图：用例图、静态图、行为图、交互图、实现图。
（3）模型元素 （4）通用机制 （5）扩展机制
/
保险单填写 界面 系统内部
保险单
客户
Oracle界面 数据库界面 {abstract}
Sybase界面
6.2.3 构件图和配置图
1．构件图 构件图代表的是实现环境中的软件模块。类 图和包图对软件的逻辑设计建模，而构件图 模拟的是实现视图，是实际的软件模块。 2．配置图 配置图描述处理器、硬件设备和软件构件在 运行时的架构，它显示系统硬件的物理拓扑 结构，以及在此结构上执行的软件。
动态模型
软件建模技术
1
第一部分 基 础 篇
2
第二部分 实 践 篇
3
第三部分 工 具 篇
第6章 动态模型
❖6.1 动态模型概述
❖6.2 活动图
▪ 6.2.1 定义活动图 ▪ 6.2.2 如何建模活动图 ▪ 6.2.3 实例——活动图在用例模型中的作用 ▪ 6.2.4 活动图与其它模型
❖6.3 顺序图
▪ 6.3.1 定义顺序图 ▪ 6.3.2 关于消息 ▪ 6.3.3 对象的创建和销毁 ▪ 6.3.4 顺序图的主要用途 ▪ 6.3.5 顺序图实例
▪ 掌握：动态建模的方法。
6.1 动态模型概述
❖ 一个完整的模型必然描述系统的静态和动态两个方面 ❖ 静态模型重在描绘系统的组成结构 ❖ 动态模型描述系统的行为
❖ UML提供如下动态模型：交互图（顺序图和协作图）、状态图、活动图
▪ 状态图用来描述某一特定对象所有可能的状态及状态间的转移， 是对类图的补充
6.3 顺序图
❖6.3.2 关于消息
❖ 2．消息的传入和传出
消息传入某个对象，表示该对象是消息的承担者；消息 由某个对象传出，表示该对象是消息的发起者、调用者
6.3 顺序图
❖6.3.2 关于消息 消息的传入和传出
6.3 顺序图
单个处理
6.2 活动图
❖6.2.1 定义活动图 ❖ ATM机“登录”用例的活动 图
6.2 活动图
❖6.2.1 定义活动图
❖ 游泳道将活动图的活动状态分组，每一组表示负 责那些活动的业务组织，直接显示动作在哪一个 业务组织中执行
❖ 每一个活动都只能明确地属于一个泳道
6.2 活动图
❖6.2.2 如何建模活动图
1．接待员输入要预约的日期 2．系统显示该日的预约 3．有一张合适的餐桌可以使用，接待员输入顾客的姓名和电话号码、
1
第一部分 基 础 篇
2
第二部分 实 践 篇
3
第三部分 工 具 篇
第6章 动态模型
❖6.1 动态模型概述
❖6.2 活动图
▪ 6.2.1 定义活动图 ▪ 6.2.2 如何建模活动图 ▪ 6.2.3 实例——活动图在用例模型中的作用 ▪ 6.2.4 活动图与其它模型
❖6.3 顺序图
▪ 6.3.1 定义顺序图 ▪ 6.3.2 关于消息 ▪ 6.3.3 对象的创建和销毁 ▪ 6.3.4 顺序图的主要用途 ▪ 6.3.5 顺序图实例
▪ 掌握：动态建模的方法。
6.1 动态模型概述
❖ 一个完整的模型必然描述系统的静态和动态两个方面 ❖ 静态模型重在描绘系统的组成结构 ❖ 动态模型描述系统的行为
❖ UML提供如下动态模型：交互图（顺序图和协作图）、状态图、活动图
▪ 状态图用来描述某一特定对象所有可能的状态及状态间的转移， 是对类图的补充
6.3 顺序图
❖6.3.2 关于消息
❖ 2．消息的传入和传出
消息传入某个对象，表示该对象是消息的承担者；消息 由某个对象传出，表示该对象是消息的发起者、调用者
6.3 顺序图
❖6.3.2 关于消息 消息的传入和传出
6.3 顺序图
单个处理
6.2 活动图
❖6.2.1 定义活动图 ❖ ATM机“登录”用例的活动 图
6.2 活动图
❖6.2.1 定义活动图
❖ 游泳道将活动图的活动状态分组，每一组表示负 责那些活动的业务组织，直接显示动作在哪一个 业务组织中执行
❖ 每一个活动都只能明确地属于一个泳道
6.2 活动图
❖6.2.2 如何建模活动图
1．接待员输入要预约的日期 2．系统显示该日的预约 3．有一张合适的餐桌可以使用，接待员输入顾客的姓名和电话号码、
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
（2）用例（Use Case）是系统对角色 的交互进行响应，并产生一个可见的结果 时所进行的一系列动作。用例描述了系统 的功能，并且不涉及到系统的实现。用例 的图型表示为：
用例名称
例3：在一节不和谐的课堂里，老师叹气道：“要是坐在后排 聊天的同学能像中间打牌的同学那么安静，就不会影响到 前排睡觉的同学。” 在这个描述中，同学们在课堂上都做 了什么呢？ 答案：聊天、打牌、睡觉。 例4：如果你去使用ATM机（自动取款机），那么你通过 ATM都可以做什么呢？ 答案是：查询、存款、取款、转账、打印等。
6.1 UML简介
UML是一种建模语言， 是用来为面向对象开发系统 的产品进行说明可视化和编 制文档的方法。它是由信息 系统（IS，Information System）和面向对象领域的 三位著名的方法学家Grady Booch ，James Rumbaugh 和Ivar Jacobson（称为“三 个好朋友”，the Three Amigos）提出的。
例1：软件开发者没有正确理解客户的要求。
例2：需求没有满足完备性和一致性，就开始了设计。
用例模型是采用面向对象的思想，是需 求分析模型的表现形式之一，主要用于表 现系统的功能性需求；是以一种更直观的 方式来表现用户对软件系统的要求。
6.3 用例模型
用例模型是使用用例的方法来描述系统 功能需求的过程。它主要包括两部分内容： 用例图和用例描述。
6.3.1 用例图
用例图(Use case diagram)从用户角 度描述系统功能,并指出各功能的操作者。 在用例图中的核心概念有角色和用例。
（1）角色（Actor），又称为参与者， 是指系统的用户在与系统按照用例的描述 进行交互时所扮演的一系列相关的角色。
角色
例1：“我的一个朋友结婚了”，在这个 事实描述里，你会想到哪些人或事呢？ 答案是：月老，新娘，新郎，亲朋好友， 玫瑰花。这些就是这个事实中的人或事， 也可以称为是这个事实描述里面存在的角 色。
设计视图
部署视图
System topology Delivery,installation communication
6.2 需求分析与用例模型
电影《其实你不懂他的心》(He's Just Not That Into You)
软件系统的需求是指用户对软件的功能和性能的要求，就是 用户希望软件能做什么事情，完成什么样的功能，达到什么 性能。 需求分析就是提供一种与客户在系统功能方面进行沟通并达 成共识的方式，使开发者能够更准确的理解系统的需求；是 把客户的功能描述转化为软件人员所能理解的功能描述，并在 客户描述的基础上去除不合理的地方，补充系统缺失的地方， 最后为系统的概要设计，详细设计提供准确，有效的数据基础。
2．视图
用例视图表达从用户角度看到的系统应有的外部功能，有时也叫 用户模型视图；用用例图来描述。 设计视图描述系统设计特征，包括结构模型视图和行为模型视图， 前者描述系统的静态结构(类图、对象图)，后者描述系统的动态行 为(交互图、状态图、活动图)。 部署视图描述系统的物理配置特征，用部署图表示。 实现视图表示系统的实现特征，常用构件图表示。 进程视图表示系统内部的控制机制。常用类图描述过程结构，用 交互图描述过程行为。
查看帖子
修改帖子
讨论区人员
回复帖子
新增帖子
用例名称：新增帖子 用例目的：完成帖子的添加 参与者：讨论区人员 前置条件：讨论区成员成功地进入讨论区，通过身份验证。 事件流： 第1步：进入分组讨论区界面 讨论区成员：选择进入相应的分组讨论区 系统：将分组讨论区中信息全部显示出来 第2步：新增帖子 讨论区成员：要求新增一条帖子信息 系统：进入新增帖子界面。 第3步：填写帖子 讨论区成员：填写帖子中的具体信息 系统：显示输入的内容。 第4步：提交 讨论区成员：提交填写好的讨论区 系统：保存该讨论区到内部数据库 后置条件：完成了帖子的增加，返回讨论区 扩展点：修改帖子
4．注释事物
注释事物是UML模型的解释部分。
5．连接关系
（1）关联：连接模型元素及链接实例；例如教师 （2）泛化：表示一般与特殊的关系，即“一般”元素是“特殊” 元素的泛化，“特殊”元素是“一般”元素 （3）依赖：表示一个元素以某种方式依赖于另一个元素； 的特化，和学生之间的关系。 （4）聚集：表示整体与部分的关系，即“部分”元素是“整体” 元素的一部分。
拓展练习： （1）根据“新增帖子”的用例描述，给出“查看帖子”、 “回复帖子”的用例描述。 （2）给出例5中“签订保险单”的用例描述。
（3）理解下面的用例图，并回答问题。 阅读报道卡片 维护教授信息 问题1：角色“学生”执行哪些用例？角色“教授”呢？ 问题2：如果李三是一个学生兼教授，哪些用例可以被执行？ 注册管理员 学生选课 维护学生信息 问题3：对用例“学生选课”，“注册”进行用例描述。
6.4.3 查找系统用例
例10：根据例9的描述，针对每一个参与者， 分析其对应的用例。
6.4.4 用例图优化
（1）参与者与参与者之间的关系 （2）用例和用例之间的关系
6.5 用例模型复审
（1）功能需求的完备性: （2）模型是否易于理解: （3）是否存在不一致性: （4）避免二义性语义:
某高校的教务管理系统中，大学生可以创 建简历、安排日程、查询课表，而任课教 师也可以安排日程、查询课表，还可以调 研新课程的开发。
学生 注册 课程总表 教授选课 注册结束
教授
成绩提交
计费系统
6.4 建立用例模型
我们建议的步骤是先确定系统边界，然后找 出系统参与者，再根据参与者确定每个参与者相 关的用例，最后再细化每一个用例的用例规约。
6.4.1 确定系统边界
6.4.2 查找系统参与者
例9：客户服务系统是对公司和客户进行统一管理的系统，根据客户 服务系统案例需求说明书，具体包括以下几个方面： (1) 基础资料维护。包括系统管理员添加、删除、修改客户服务系统 账户信息，添加、修改、删除公司产品及项目信息；客户服务人员添 加、修改、删除客户资料信息，添加、修改、删除经验库信息等。 (2) 业务处理。包括客户服务人员新增、修改、删除客户咨询信息； 维护人员处理客户问题、填写维护报告；部门领导处理投诉，安排任 务等。 (3) 统计查询。包括客户资料查询、客户来电咨询查询、经验库查询、 客户服务系统用户信息查询、回访任务及维护报告查询等。 明确以上信息后，分析系统的参与者。
用例模型的作用有（摘于IBM教材《使用UML进行面向对象分析 与设计》）： （1）在系统开发的早期就可以明确最后提交的产品功能和特性； （2）确保双方都对需求有了准确的理解标识（系统的用户群和系 统的功能）； （3）确定对系统与用户群之间接口的需求验证（是否客户所有的 需求都被捕获）； （4）确保开发团队已完全理解了客户的需求。
路径1：基本流 路径2：基本流—备选流1—基本流 路径3：基本流—备选流1—备选流2 路径4：基本流—备选流3—基本流 路径5：基本流—备选流3—备选流4 路径6：基本流—备选流3—备选流1—备选流2 路径7：基本流—备选流3—备选流1—基本流 路径8：基本流—备选流4
用例描述模板
例7：在某论坛系统中，针对讨论区成员， 存在如下用例。请给出“新增帖子”用例 的描述过程：
（3）绘制用例图：用例图是用例的集 合，通常由系统、用例、角色和关联组成。
例5：某保险商务系统，客户可以签订保险 单，保险销售员可以鉴定保险单，还可以 进行销售统计和客户统计。
保险商务系统
签订保险单
客户
销售统计
保险销售员
客户统计
6.3.2 用例描述
用例描述（也称为用例规约）主要是描述用例的静态 和动态两方面特性。包括描述用例名称、用例目的、参与 者、用例的前提条件、用例的交互过程或者事件流、用例 执行结果、用例的扩展、特殊需求等等。
XX系统
用例1
角色1
角色2
用例1描述
用例2
用例2描述
如在ATM系统中的“提款”用例可以用事件 流表述如下： 提款基本事件流 （1）用户插入信用卡。 （2）输入密码。 （3）输入提款金额。 （4）提取现金。 （5）退出系统，取回信用卡。
最常见的事件流是用基本流(Basic Flow)来描述的， 其他的事件流则是用备选流(Alternative Flow)来描述。
第6章 用例模型
如果说我看得比别人更远些,那 是因为我站在巨人的肩膀上。
——艾萨克· 牛顿
学习标
了解UML中的基本图形元素 掌握用例图的概念及基本元素 学会建立用例模型 掌握用例描述 学会使用StarUml绘制用例图
什么是模型？模型是一组具有完整语义的信息， 它是对现实世界的简化，也是对认知主体的抽象， 建模过程就是认识世界、捕捉认知对象本质的过 程。 面向对象建模是软件工程师对系统相关的问题域 的建模和求解域的建模。 用例模型是UML中从用户的观点对软件系统行为 的一个建模，定义了系统做什么，即以系统功能 为目标，从系统使用者的角度来描述系统操作的 过程。
6.6 使用StarUML绘制用例图
2.动作事物
（1）交互：是一组对象在特定上下文中，为 达到某种特定的目的而进行的一系列消息 交换组成的动作。在UML中用带箭头的直 线来表示。 （2）状态机：由一系列对象的状态组成。
3．分组事物
分组事物是UML模型中组织的部分，分组 事物只有一种，称为包。包是一种有组织 地将一系列元素分组的机制。
思考：
（1）在上面的图中，“车”，“教师”，“显示器” 等事物属于UML中的哪一个概念？ （2）“人”，“男人”，“女人”之间是UML中 的什么关系？ （3）观察周围的事物，举出“聚合”，“泛化”关 系的实例。
6.1.3 UML组织结构
1．图
图是系统架构在某个侧面的表示，UML提供了两大类——静态图 和动态图，共计9种不同的图。 静态图（Static Diagram）包括用例图、类图、对象图、构建图、 部署图。其中用例图描述系统的功能；类图描述系统的静态结构； 对象图描述系统在某个时刻的静态结构；构件图描述实现系统的 元素的组织；部署图描述系统环境元素的配置。 动态图（Dynamic Diagram）包括状态图、时序图、协作图和活 动图。其中状态图描述系统元素的状态条件和响应；时序图按时 间顺序描述系统元素间的交互；协作图按照时间和空间的顺序描 述系统元素间的交互和关系；活动图描述系统元素的活动。其中 活动图是由Jame Odell提出，状态图由David Harel提出。