面向对象分析与设计 侯爱民 chapter03

3.1 用例
用例图中的建模元素： 用例 参与者 关系 参与者之间的关系 参与者与用例的关系 用例之间的关系
3.1 用例
用例(use case)的定义: 定义1：用例是对一个活动者(actor)使用系 统的一项功能时所进行的交互过程的一个 文字描述序列。 定义2：用例是系统、子系统或类和外部的 参与者 (actor) 交互的动作序列的说明，包 括可选的动作序列和会出现异常的动作序 列。
依赖关系： 依赖是两个元素或元素集之间的关系。 被依赖的元素称为目标元素，依赖元素称 为源元素。 当目标元素改变时，源元素也要做相应的 改变。 包含关系和扩展关系都属于依赖关系。
3.4.4 用例的3种关系的比较
考虑因素： 如果需要重复处理两个或多个用例时，可 以考虑使用包含关系。 当处理正常行为的变型，而且只是偶尔描 述时，可以考虑使用泛化关系。 当描述正常行为的变型，而且希望采用更 多的控制方式时，可以在基本用例中设置 扩展点，使用扩展关系。
3.4.4 用例的3种关系的比较
3.4 用例间的关系
用例与参与者的关系：关联关系。
用例之间的关系：泛化关系，包含关系， 扩展关系。
参与者之间的关系：继承（泛化）关系。
3.4.1 用例间的泛化关系
泛化代表一般与特殊的关系，与继承关系 类似。 在泛化关系中，子用例继承了父用例的行 为和含义，也可以增加新的行为和含义， 或覆盖父用例中的行为和含义。
12、系统修改后台数据库中的储户资金表（一个 动作）。
13、完成本次取款操作。转相应的后续处理。
3.1 用例
总结：
用例描述活动者与系统交互中的对话。 例如，活动者向系统发出请求做某项数据处理， 并向系统输入初始数据。系统响应活动者的请求， 进行所要求的处理，把结果返回给活动者。 这种对话表达了活动者与系统的交互过程，它可 以用一系列的步骤来描述。这些步骤构成一个 “场景”。而“场景”的集合就是用例。
3.1 用例
用例分析实际操作：
参与者有哪些？ 用例有哪些？ 分析读者“借书”用例。（指具体的交互 过程）
3.1 用例
用例用一个椭圆表示。 用例名用动宾结构或主谓结构命名。 例1：在字处理程序中，“置正文为黑体” 是一个用例。
置正文为黑体 较简单的用例
创建索引 较复杂的用例
3.3 脚本
脚本指贯穿用例的一条单一路径，用来显 示用例中的某种特殊情况。 脚本是用例的实例。 脚本与用例的关系，好比对象与类的关系。 每个用例都有一系列的脚本，其中包括一 个主要脚本，以及多个次要脚本。 次要脚本描述了执行路径中的异常情况或 可选择的情况。
3.3 脚本
例4：在“订货”用例中，可能会有以下一 些脚本。 一个是订货进行顺利的脚本。 一个是相关货源不足的脚本。 一个是涉及购货者的信用卡被拒的脚本。 “订货”用例在代码实现阶段，会对应一 个流程框图。该框图会有几个分支判断， 相应地会产生几个分支路径。每个路径就 是一个脚本。
3.1 用例
静态建模机制包括： 类图，对象图，构件图，部署图。 动态建模机制包括： 用例图，顺序图，协作图，状态图，活动 图。
3.1 用例
对于功能性需求，可以用用例表示出来。 对于非功能性需求（如术语表），很难用 用例表示出来。往往采用附加补充文档的 形式。 编写需求分析，应当根据特定的需求大纲 来写。
第3章 用例和用例图
3.1 3.2 3.3 3.4 3.5 3.6 3.7 用例 参与者 脚本 用例间的关系 用例图 用例的描述 寻找用例的方法
3.1 用例
画好用例图是从软件需求到最终实现的第 一步。 在 UML中，用例图用于对系统、子系统、 或类的行为的可视化。 是从用户的角度来描述的软件产品外部特 性，即用户使用软件产品时所看到的操作 功能。 至于怎么实现的，用户不需关心，也没必 要关系。
3.1 用例
案例——储户使用ATM机取款：
5、系统将卡中信息和输入的密码到后台数 据库中进行核对（一个动作）。后台数据 库中的一张用户信息表就是一个实体类， 每个记录就是一个实例化的对象。 6、核对不成功，系统就弹出“密码输入错 误”窗口（一个边界类）。转步骤3。
3.1 用例
案例——储户使用ATM机取款：
3.1 用例
定义3：用例是对一个系统或一个应用的一 种单一的使用方式所作的描述，是关于单 个活动者在与系统对话中所执行的处理行 为的陈述序列。
定义4：用例是用来描述参与者使用系统完 成某个事件时的事情发生顺序。
3.1 用例
案例——储户使用ATM机取款： 注：以下为需求分析时获得的知识。没有 考虑将来的系统如何实现“取款”操作。 1、参与者：储户 2、用例：取款 3、用例所包含的交互过程： 3.1、读取储户输入的账户信息和密码信息。
Search PersΒιβλιοθήκη nSearch Teacher
Search Student
3.4.2 用例间的包含关系
在包含关系中，一个用例（基本用例）的 行为包含了另一个用例（包含用例）的行 为。基本用例将包含用例的行为作为自身 行为的一部分。 使用带箭头的虚线表示包含关系，从基本 用例指向包含用例。
use case之间的关 系
<<extend>>
3.4.4 用例的3种关系的比较
总结：
关系是模型元素之间具体的语义联系。 关系可以分为：关联，泛化，依赖，实现 等几种。
3.4.4 用例的3种关系的比较
关联关系：
关联是两个或多个类元之间的关系。 描述了类元的实例之间的联系。 类元是一种建模元素，常见的类元包括： 类，参与者，组件，数据类型，接口， 结点，信号，子系统，用例
Login realization Login
协作用虚线 椭圆表示
Login realization (with security)
3.2 参与者
参与者是指系统以外的、需要使用系统 或与系统交互的东西，包括人、设备、 外部系统等。
例3：在一个银行业务系统中，可能会有以 下一些参与者。
客户，管理人员，厂商，mail系统
3.1 用例
用例分析实际操作：
图书馆管理系统。 用户的需求信息如下： 读者的借书、还书、书籍预订、借阅信息 的查询。 图书馆管理员的书籍借出处理、书籍归还 处理、预订信息处理。
3.1 用例
用例分析实际操作：
系统管理员的系统维护。包括：增加、删 除、更新书目；增加、删除书籍；增加、 删除、更新读者账户信息；增加、删除、 更新图书馆管理员账户信息；书目信息查 询；书籍信息查询；借阅信息查询，读者 信息查询，图书馆管理员信息查询。
也就是说，基本用例是依赖于包含用例的。
3.4.2 用例间的包含关系
一般而言，把几个用例的公共步骤分离出 来，形成一个单独的用例（即为包含用 例）。
<<include>> ChangePersonDetails <<include>> ViewPersonDetails User <<include>> SearchPerson
3.4.3 用例间的扩展关系
扩展关系为处理异常或构建灵活系统框架提供一 种有效方法。 使用带箭头的虚线表示扩展关系，从扩展用例指 向基本用例。
Buy Merchandise
Customer
<<extend>>
<<include>>
Browse Web Site
Add Order to Warehouse System
参与者、用例间的关系类型
关系类型 关联(association) 泛化 (generalization) 包含(include) 说明 actor和use case 之间的关系 actor之间或 use case之间的关系 use case之间的关 系 表示符号
<<include>>
扩展(extend)
为以后逐层细化具体 的实现用例作铺垫
3.1 用例
例2：在一个银行业务系统中，可能会有以 下一些用例。
浏览帐户余额，列出交易内容，划拨资金， 支付帐款，登录，退出系统，编辑配置文 件，买进证券，卖出证券 这些用例，每一个都说明了银行业务系统 中的一项功能。
3.1 用例
用例特点： 从使用系统的角度描述系统中的信息，即 站在系统外部察看系统功能，而不考虑系 统内部对该功能的具体实现方式。 描述了用户提出的一些可见需求，对应一 个个具体的用户目标。 是对系统行为的动态描述，属于UML的动 态建模部分。
3.2 参与者
参与者的3种表现形式
人形图 标表示 参与者 是人 带版型标 记的类图 标表示参 与者是外 部系统 <<Actor>> Actor1
Actor1
Actor1 Icon形式
Label形式
Decoration形式
3.2 参与者
参与者之间的继承（泛化）关系
顾客（一般 化的参与者）
商业顾客 （特殊化的 参与者）
3.1 用例
案例——储户使用ATM机取款： 3.2、验证储户的身份。 3.3、不合法，则退出“取款”操作。 3.4、合法，则读取储户输入的欲取金额。 3.5、验证金额的有效性。 3.6、无效，则退出“取款”操作。 3.7、有效，则吐出等额的货币，退出“取 款”操作。
3.1 用例
3.4.4 用例的3种关系的比较
判断标准：
“is a”：泛化关系和扩展关系表示的是用 例之间的”is a”关系。 “has a”：包含关系表示的是用例之间 的”has a”关系。