第2章软件开发方法与技术( 功能模型—用例图)

IssueFind (交纳罚金)
<<extend>>
BorrowBook (借书)
NoBorrowBook (拒绝借书)
§2．5 用例图的应用
1．为系统的上下文建模 上下文：亦称为语境，它定义了系统存在的环境，它
强调系统外部的参与者（与系统交互作用的 一类事物） 为系统的上下文建模时可参考如下方法： （1）识别系统的参与者； （2）将彼此类似的参与者组织成泛化关系 （3）为了帮助理解，可以为每个参与者提供原型（具体 名称） （4）规定每个参与者到系统用例的通信路径
如图：
Relationship
Actor
UseCase
6.用例图中也可以有注释和约束，还可以有包(Package)
§2. 2 参与者（Actor） 参与者 (Actor) 是指系统以外的，需要使用系统或与 系
统交互的实体（如：人、设备、外部系统等） UML中参与者的表示形式：
ActorName
说明： 1.在构造用例图时，为获取“用例”，首先要确定系统的
例1.基于参与者之间的泛化关系
学生
电信客户
本科生
研究生
电话客户 网络客户
例2. 基于用例之间的泛化关系
购物
商场购物
电话购物
网上购物
说明：用例之间最好不用泛化关系，泛化是指静态事物之 间的联系（复用），而“用例”是动态的。
3．包含关系（Include） 包含关系是指可以简单的包含其他用例具有的行为，并
控制之外。 (2)参与者直接同系统交互，这可以帮助定义系统边界 (3)参与者表示人和事物与系统发生交互时所扮演的角
色，而不是特定的人或特定的事物。 (4) 一个人或事物在与系统发生交互时，可以同时或不
同时扮演多个角色。 (5) 每一个参与者需要有一个具有业务一样的名字。 (6) 每个参与者必须有简短的描述，从业务角度描述参
参与者（Actor），可以根据以下问题来寻找系统的 参与者：
(1) 谁是系统的主要用户？ (4) 谁管理、维护系统？ (2) 谁从该系统获得信息？ (5) 与该系统交互的是什么系统？ (3) 谁向系统提供信息？ (6) 系统从那里获得信息？
2.在确定“参与者”过程中，记住以下要点。 (1)参与者对于系统而言总是外部的，因此它们在你的
成为一个用例，然后让其他用例来包含这个用例。 例如：
客户
Librarian (工作人员)
CreateAccount <<include>> (建立账户)
<<include>>
提供者
ModifyAccount
QueryAccount
(修改账户)
( 查询账户)
<<include>>
DeleteAccount (删除账户)
把它所包含的行为作为自身行为的一部分。 其中：包含用例称为“客户”用例 被包含用例称为“提供者”用例
包含关系用原型为<<include>>的依赖关系来表示。
其图形表示如下：
<<include> >
如：
<<include>>
客户
提供者
说明：主要有两种情况需要用到包含关系 ⑴ 多个用例用到同一段行为，则可以把这段共同的行为单独抽象
例1：
Librarian (工作人员)
Borrower (读者)
Teacher Student (教师) (学生)
为系统的上下文建模
|—— Lib—ra—ry—inf—or—ma—tio—n—sy—ste—m——|
|
|
|
|
|
|
|
ReturnBook
|
|
(还书)
|
|
|
|
|
|
|
| | |
BorrowBook (借书)
关联包括双向关联和单向关联，其图形表示分别如下：
例如：
Librarian (工作人员)
Borrower (读者)
LendBook (借书)
ReturnBook (还书)
Search (查询)
2.泛化关系（Generalization） 是一种结构关系，描述一般到特殊之间的关系（继承
关系） 例如：学生和研究生、本科生 泛化关系，其图形表示如下：
例的方法。 其中：前者被称为“扩展”用例 后者被称为“基础”用例 扩展关系用原型为<<extend>>的依赖关系来表示，其
图形表示如下：
<<extend>>
Extension point OverdueBook
基础用例
扩展用例
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
与者是什么。
§2. 3 用例（Use case） 用例（Use case）是参与者(Actor)可以感受到的一项系 统责任或功能单元。 说明： 1.用例定义了系统责任和完整的功能，描述了参与者使
用系统所提供的一项完整功能时而与系统所进行的交 互过程（一段对话），该过程可用一组文字描述序列 来表达。 2.用例从建立模型的角度可描述如下： 用例=用例元素(图形符号)+事件流(文字描述序列) UML中用例元素表示为：
(3) 读者还书（通过工作人员） 根据图书证号、图书号，从“借阅图书文件”中读出该图书相关 的记录（判断是否超期，如果超期则按相应标准收取罚金），登记 还书信息（日期等）, 且将所还书的所有信息存入“借阅历史档案” 中，然后从“借阅图书文件”中注销该图书借阅信息 (4) 管理维护系统（系统管理员通过后台终端），包括：增、减或 更新图书数据；增、减或更新读者账户信息。
统中的信息吗? (3) 什么用例会创建、存储、改变、删除、或读取这个
信息？ (4) 参与者需要通知系统外部的突然变化吗? (5) 需要通知参与者系统中正在发生的事情吗? (6) 什么用例将支持和维护系统?
例：某图书馆开发一个图书管理系统，该系统要求实现下列功能： (1) 读者查询（直接通过外部终端进行） 读者查询图书，通过书的种类、出版社、书名、作者等方式查询；
| | |
|
|
|
|
| | |
SQeuaerrcyh
((查查询询))
| | |
|
|
|
|
|
|
|
MaintainBorrower
|
|
(维护读者)
|
|
|
|
|
|
|
| | |
MaintainBook (维护图书)
| | |
|—————————————— |
Administrator (管理员)
2．为系统的需求建模 需求规定了用户期望系统做什么。系统的全部或大部分 功能可以表达为用例。UML的用例图可以表达和管理系 统大多数的功能需求。
RegisterBook (注册图书)
MaintainBook <<include>> (维护图书)
UpdateBook (更新图书)
或：
Labrarian Borrower
LabrarianLogin
<<include>> CheckUserInfo
BorrowBook
wk.baidu.com
<<include>>
其参与者和用例图形元素为：
§2．4 用例与事件流
用例的事件流：指对一个用例的具体细节的描述文档 事件流通常包括： 1.简要说明：简要描述该用例的作用和目标（用例要
达到的结果） 2.前置条件：列出用例之前必须满足的条件（如：前
驱用例或运行权限） 注意：并不是所有用例都有前置条件。 3.主事件流和其他事件流：描述用例的工作流程的事 件流。 包括：用例是怎样开始的； 用例是怎样结束的； 用例如何与参与者交互； 用例的主流程； 用例的非正常流程（其他事件流）； 用例所需要的数据；
4. 后置条件：是用例执行完毕后必须满足的条件（如，使一个标 记为‘真’）
注意：并不是所有用例都有后置条件 说明:事件流的“描述”位置可以放在用例的Specification (规格
说明/属性)对话框General(综合) 页面的Documentation (文档)处
§2．5 用例间的关系
1.关联关系（Association relationship） 是一种结构+语义（动态行为）关系，表示一个事物的
说明：需求来源于问题域，需求的目的是把问题域中的“问题”提 炼成系统责任，用例图就是描述系统责任的良好工具。
• 问题域：指被开发系统的应用领域，即在现实世界中这个系统所 涉及的业务范围。
• 系统责任：指被开发系统应该具备的职能。即在计算机世界中这 个系统所涉及的业务范围。
3.它是由软件需求到最终实现的第一步，它驱动了需求分析之后 的各阶段的开发工作；
⑵ 某一个用例的功能过多、事件流过于复杂时可以把某一段事件 流抽象成为一个被包含的用例（提供者），以达到简化描述的 目的。 例如：
Query (查询)
<<include>>
<<include>>
QueryBorrows (查询借阅情况)
QueryBooks (查询图书)
4．扩展关系（Extend） 是把可选的、只在特定条件下运行的行为插入到已有用
在为系统的需求建模时应考虑： （1）确定系统外部的参与者，从而建立系统的上下文 （2）考虑每个参与者所期望的或要求系统提供的行为 （3）把公共行为命名为用例 （4）确定被其他用例使用的用例或用来扩展其他用例
的用例 （5）在用例图中描述这些用例、参与者以及它们之间
的关系。 （6）用描述非功能性需求的注释点缀用例图
对象与另一个事物的对象间的特定的联系（链接）。 例如：教师和学生：存在“老师教学生”关联 员工和公司：存在“员工受聘于公司”关联 用户和软件：存在“用户使用软件”关联
工作人员和读者：存在“业务员为读者办理业务”关 联
注意：参与者（Actor）同用例（Use case）之间的 关系是关联关系（主要体现在“行为”上）。
UseCaseName
3.用例是对系统行为的动态描述，它可以促进开发人员 与用户沟通，理解正确的需求；
4.用例可以划分系统与外部实体的界限，是系统设计的 起点，是类、对象、操作的来源。
5.基于参与者，可以通过回答下述问题来帮助识别用例： (1) 每个参与者的任务是什么? (2) 有参与者将要创建、存储、改变、删除、或读取系
例2：
为系统的需求建模
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
<<include>>
IssueFind (交纳罚金)
BorrowBook (借书)
CheckUserInfo (检 查 用 户 合 法 性 )
<<include>>
Borrower (读者)
<<include>>
Login (登录)
SQeuaerrcyh
(查询询))
CheckBorrowInfo (检 查 借 阅 权 限 )
RegisterBorrower
(注册读者)
<<include>>
UpdateBorrower (更新读者)
MaintainBorrower (维护读者)
<<include>>
Administrator (管理员)
4.它是描述系统的动态模型，即是5个UML动态视图之一; 其中,5个UML动态视图是: “用例图”、“状态图”、“活动图”、“时序图”、“协作图”
5．它描述了一组用例、参与者以及它们之间的关系，因此用例图 包括以下3方面内容： (1) 用例（Use case） (2) 参与者（Actor） (3) 关系（Relationship ） •关联关系（Association ） •泛化关系（Generalization ） •依赖关系（Dependence ）
读者查询借阅图书情况，通过姓名和图书证号等方式查询。 (2) 读者借书（通过工作人员） 读者凭图书证(书卡)借书。系统首先检查该读者(图书证号)是否有
效，若无效，则拒绝借书；否则进一步检查该读者所借图书是否达 到限额数，若达到限额数，则拒绝借书，否则读者可以借书.把图书 证号、图书号、借书日期和还书日期等登记在借阅图书文件中
第2章 用例图
§2.1 用例图（Use-Case Diagram）
用例图是参与者（Actor）所能观察到的描述系统功能视图，它 通过用例（Use-Case）来捕获系统的需求。 其中：
1.用例图描述了待开发系统的功能需求，是软件产品外部特性描 述的视图；
2.用例图是从用户的角度而不是从开发者的角度描述软件产品的 需求，分析产品所需的功能和动态行为；
根据上述需求陈述，可得： 参与者 (Actor) ：
读者（教工、学生） 工作人员（业务员） 管理人员 用例（Use case） ： 基于读者的用例： 查询（包括查询图书和查询读者借阅情况） 基于工作人员的用例： 登录 借书 (包括：检查用户借阅凭证合法性、检查借阅权限) 还书（包括：交纳罚金） 基于管理人员的用例： 登录 维护读者(包括：注册、更新等)、 维护图书（包括：注册、更新等）