第4章+用例图

上节课重点
U M L 理 论 及 实 践
UML的的语法和语义规则




名字（Names）：为事物、关系、图起的名 字 范围（Scope）：使名字具有特定含义的语境 可见性（Visibility）：如何让其他成分看到和 使用这些名字 完整性（Integrity）：事物如何正确、一致 的相互联系 执行（Execution）：运行或者模拟动态模型 意味着什么
Home
Use Case的确定
U M L 理 论 及 实 践
注意Use Case的大小。 不要只用一个Use Case就把一个系统或子系统 的功能行为全部包括在内，也不要把Use Case划分得过于琐碎细小。 一般应该把系统或子系统中主要的业务流找 出来，对每一个业务流建立一个相应的Use Case。 为业务处理的各种例外（异常）情况的事件 流单独建立一个相应的Use Case。
Home
Use Case的确定
U M L 理 论 及 实 践
Use Case的种类大体如下： （1）系统的开始和停止的Use Case。 （2）系统维护的Use Case。 如添加新用户，设置用户的操作模板（profile）等。 （3）维护系统中存储数据的Use Case。 如所建造的系统要与现存的系统数据同步。 （4）修改系统行为的功能的Use Case。 如创建一个新报表，而不是对一个一个的报表进行 单独的编程。
泛化关系

如果用例已经泛化，并且一个活动者使用了一 个已经泛化用例，那个活动者就不应该是使用 已泛化用例的父用例的活动者。
U M L 理 论 及 实 践
扩展关系范例
Record grades
《include》
《extend》
teacher
Save grades update grades
《include》
Notify guardians
用例间的关系
U M L 理 论 及 实 践
扩展关系范例
《include》
《extend》 Save grades Extension points: Failing grade is saved
用例
U M L 理 论 及 实 践
用例的名称：

简单名 路径名
用例
U M L 理 论 及 实 践
识别用例


识别用例最好的方法就是从分析系统的活动者 开始，考虑每个活动者是如何使用系统的。 如何识别用例。
活动者要求系统提供哪些功能
活动者需要读、产生、删除、修改或存储系统中的
信息有哪些类型 必须提醒活动者的系统事件有哪些 活动者必须提醒系统事件有哪些
Use Case的确定
U M L 理 论 及 实 践
在标识Use Case时需要考虑的问题如下：
对于每一个已经确定的活动者，系统将有一 些什么任务，提供什么服务。 在系统中是否需要传递信息给活动者。 活动者是否需要通知系统某些突然的外部变 化。 系统是否为领域业务提供了正确的行为。 Use Case的运行特征是否标识出来了。 Use Case将支持和维护的系统功能是什么。
用例与事件流
U M L 理 论 及 实 践
事件流的目的是在建档时说明用例的逻辑流程， 即详细描述系统用户的工作和系统本身的工作。 主要包括：

简要说明：描述用例的作用。 前提条件：列出开始用例之前必须满足的条件。 主事件流和其他事件流：
用例如何开始 用例的各种路径
用例的正常（主）流程
用例与事件流
U M L 理 论 及 实 践
建立事件流的主要问题是确定描述的详细 程度，可根据用户来确定。事件流的主要 用户包括：



客户，客户通过该文档确定是否准确反映客户 的期望。 系统设计人员，用其创建系统设计并最终建立 系统。 质检人员，用其创建测试脚本（测试用例）。
U M L 理 论 及 实 践
活动者
U M L 理 论 及 实 践
注意事项：




活动者对于系统而言总是外部的； 活动者直接同系统交互； 活动者表示人或事物与系统交互时所扮演的角 色； 一个人或事物在与系统交互时可以同时或不同 时扮演多个角色； 每个活动者需要有一个反映业务的名字； 每个活动者必须有简短的描述，从业务角度描 述活动者是什么。
概述
U M L 理 论 及 实 践
用例图主要功能




用例图是使用统一建模语言设计新系统的起点， 在初始阶段完成。 用例图提供了系统的一个概览，为系统提供给 用户的功能进行说明。 从形式上讲，用例记录用户使用系统时从头到 尾的一系列事件。 是用户和开发者一起深入剖析系统功能的起点。 在开发项目的初期，用例图可以描述现实世界 中的活动和动机。同时可以在项目后期改进用 例图以反映用户界面和设计细节。
Home
用例与事件流
U M L 理 论 及 实 践
用例分析是处于系统的需求分析阶段，这 个阶段应该尽量的避免去考虑系统实现的 细节问题。也就是说，用例描述的是一个 系统做什么，而不是怎么做。 如何来描述用例的执行流程呢？可以通过 一个清晰的，易被用户理解的事件流来说 明一个用例的行为。这个事件流包括用例 何时开始和结束，用例何时和活动者交互， 什么对象被交互以及该行为的基本流和可 选流。
上节课重点
U M L 理 论 及 实 践
RUP的主要特点：
1.面向对象。 e Case驱动。 3.以体系结构为中心。 4.螺旋上升式的开发过程。 5.以质量控制和风险管理为目标。 6.与UML配套。 7.适应性强。
Home
UML理论及实践
第4章 用例图
内容提要
U M L 理 论 及 实 践
UML的扩展机制包括：

上节课重点
U M L 理 论 及 实 践
UML的“4+1”视图
设计视图（Design View）或逻辑视图 （Logical View） 进程视图(process view)： 实现视图(implementation view)：
部署视图(deployment view)：
用例图的概念 用例图建模技术 实例
概述
U M L 理 论 及 实 践
用例是对系统行为的描述，该描述是从一 个让系统完成一些特定工作的用户的角度 编写的。 用例记录了系统响应单个用户刺激所经历 的可视事件序列。
概述
U M L 理 论 及 实 践
用例图显示谁将是相关的用户、用户希望 系统提供什么服务以及用户需要为系统提 供的服务。 用例图最常用来描述系统以及子系统。
Home
U M L 理 论 及 实 践
异动处理：信用卡有效性检查失败。 本Use Case包含了两个剧本：成功的商 品交易的 “购买商品” 剧本，“信用卡有 效性检查失败”的剧本。
用例间的关系
U M L 理 论 及 实 践
关联关系 包含关系 扩展关系 泛化关系
用例间的关系
U M L 理 论 及 实 践
例：一个网上商店，顾客购买商品的过程的Use Case 可以用文字列表描述如下。 购买商品 （1）顾客浏览查询产品分类目录，找出所需要的产品。 （2）顾客准备结算。 （3）顾客填写购货信息（产品信息，数量、送货地址、送 货日期）。 （4）系统显示价格和应付款项。 （5）顾客填写信用卡信息。 （6）系统检查信用卡的有效性，确认交易成功。 （7）系统确定发货时间，发出发货通知。 （8）系统发确认成交的电子邮件给顾客。
Record grades
teacher
update grades
《include》
扩展点
用例间的关系
U M L 理 论 及 实 践
泛化关系

父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添 加行为或覆盖、改变继承的行为。
用例间的关系
用例的主事件流（其他事件流）的变形 错误流

事后条件
用例与事件流
U M L 理 论 及 实 践
范例：用户登录用例事件流



主事件流：活动者管理人员或操作人员输入自 己的密码时，用例开始。输入的密码被提交后 服务器判断是否正确。如果正确，用户登录成 功，系统根据用户的类型（管理员或操作员） 为其分配相应的权限。 异常事件流：用户密码错误，不能登录，用例 重新开始。 异常事件流：在密码提交前，用户清除输入密 码，重新填写。
活动者
U M L 理 论 及 实 践
活动者的种类：

系统用户 与所建造的系统交互的其他系统 一些可以运行的进程
活动者
U M L 理 论 及 实 践
如何确定活动者：



谁使用系统的主要功能 谁需要系统支持他们的主要工作 谁来维护、管理系统使其能正常工作 系统需要控制哪些硬件 系统需要与哪些系统交互 对系统产生的结果感兴趣的是哪些人或哪些事 物
U M L 理 论 及 实 践
泛化关系范例
Compile application developer Compile software GUI Compilation Command line compilation scheduler
developer
scheduler
用例间的关系
U M L 理 论 及 实 践
概述
U M L 理 论 及 实 践
用例图包含6个元素：



活动者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）
概述
U M L 理 论 及 实 践