那我们怎么描述？--形式和内容是什么 形式和内容是什么！ （2）那我们怎么描述？--形式和内容是什么！
因为我们在系统开发时必须要了解并准确描述用户的各 个方面的需求，这包括功能、 个方面的需求，这包括功能、非功能以及环境的约束等方面 需求。同时， 需求。同时，我们所采用的方法能否避免常规的方法所带来 的问题？ 的问题？
（1）用例及其定义—某种特定的功能 用例及其定义 某种特定的功能
用例的确定只是与 用户交流的目的， 用户交流的目的， 而不是交流的手段
（2）用例的分类 业务用例：如报表数据汇总计算 业务用例：
系统用例： 系统用例：如报表打印
获得用例的手段可以有很 多种---可以是“ ---可以是 多种---可以是“不择手 段”！
请见文档中的说明 书写用例的模板格式
UML中的用例图 四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具， 用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
可以实现从用户角度来描述系统所应该具有的功能， 可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统， 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
说法不一，见仁见智！ 说法不一，见仁见智！ 不同项目和面向不同的 用户都不一样！ 用户都不一样！
如何确定系统中的用例-----参考文档说明 （3）如何确定系统中的用例---参考文档说明
识别用例有一个简单的判断方法：用户（活动者） 识别用例有一个简单的判断方法：用户（活动者）通过 系统实现×××目的。 ×××目的 系统实现×××目的。 一个系统中的用例的种类大致如下： 一个系统中的用例的种类大致如下：系统的开始和停止的 用例、系统维护的用例、维护系统中存储的数据的用例、 用例、系统维护的用例、维护系统中存储的数据的用例、修 改系统行为的功能的用例和系统中代表业务功能的用例。 改系统行为的功能的用例和系统中代表业务功能的用例。
提供用例图的目的之二是帮助开发团队理解 客户对系统的各种功能需求。 客户对系统的各种功能需求。
本讲的简要回顾
1、子曰：“学而不思则罔，思而不学则殆。” 子曰： 学而不思则罔，思而不学则殆。 学而时习之” “学而时习之” 2、子曰：“知之者不如好之者,好之者不如乐之者” 子曰： 知之者不如好之者,好之者不如乐之者”
用例的纵向方面的关系---------泛化关联 （2）用例的纵向方面的关系-----泛化关联
泛化关联代表一般与特殊的关系， 泛化关联代表一般与特殊的关系，它充分体现了面向对象 的继承性 根据继承关系：子类具有父类的所有属性， 根据继承关系：子类具有父类的所有属性，还可以拥有自 己的属性特点及行为---因此， ---因此 己的属性特点及行为---因此，父子用例也应该具有这些 特性。 特性。
因此，参与者不 因此， 完全都是“ 完全都是“人”
（3）某项目中的各个参与者示例说明
（4）参与者之间的主要关系---泛化关系 参与者之间的主要关系---泛化关系 --特化或者继 承
（5）所要注意的问题
（6）如何获得系统中的参与者
用例模型中的用例（UseCase） 4、用例模型中的用例（UseCase）
子曰： 三人行,必有我师焉” 3、子曰：“三人行,必有我师焉” 子曰： 我非生而知之者,好古,敏以求之者也” 4、子曰：“我非生而知之者,好古,敏以求之者也”
UML中的用例之间的关系 二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
用例的层次化（纵向方面） （1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层） 按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 统层（可以再细分）和对象类层（最低层） 系统层用例图：描述系统提供的全部主要的功能或服务。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务， 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作， 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。 外部交互者可以是其他对象类或高一层活动者。
一般是采用自然语言（如中文）来描述对系统的需求， 一般是采用自然语言（如中文）来描述对系统的需求，这 样的方法有几个致命的缺陷。 样的方法有几个致命的缺陷。 缺乏描述的形式化，随意性较大， 缺乏描述的形式化，随意性较大，常常产生理解上的含混 及不确定性-------自然语言的描述容易产生歧义 及不确定性----自然语言的描述容易产生歧义 ； 没有统一的格式，不能自动化地验证 ； 没有统一的格式， 不能保证文档与程序同步。 不能保证文档与程序同步。
参与者和用例之间的使用关系， 参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
（3）用例图的组成元素
在一个用例图中， 在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 泛化、 （泛化、使用和扩展等 三种形式）。 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
在Rose中的 Rose中的 实现状态 在Visio中 Visio中 的实现状态
（4）用例的横向方面的联 系---扩展关联
基本的用例必须声明若干新 的规则-----扩展点 的规则---扩展点 扩展用例只能在这些扩展点 上增加新的行为并且基本用 例不需要了解扩展用例的实 其一侧重于问题的特殊性， 其一侧重于问题的特殊性，而另一种则侧重 现细节
网上银行 系统中的 用例关系
人员管理 系统中的 用例关系
用例的横向方面的联系-----包含关联 （3）用例的横向方面的联系---包含关联
包含关联指一个基本用 例的行为包含了另一个 用例的行为 这种包含关联是一种依 赖关系， 赖关系，被包含的用例 不能独立存在， 不能独立存在，只能作 为包含它的用例的一部 分
用例建模方法最主要的优点-------在于它是用户导向的 3、用例建模方法最主要的优点----在于它是用户导向的
（1）用户可以根据自己所对应的用例来不断细化自己的需求。 用户可以根据自己所对应的用例来不断细化自己的需求。 此外，使用用例还可以方便地得到系统功能的测试用例。 （2）此外，使用用例还可以方便地得到系统功能的测试用例。
（4）用例的命名
每个用例应有唯一的名称 命名的方式： 名词短语来命名---命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
命名用例一般要 用动词开头 ！
用例的UML UML图示 （5）用例的UML图示
5、用例模型中的系统
（1）什么是系统 系统代表的是一部机器设备或者是一个商务活动等， 系统代表的是一部机器设备或者是一个商务活动等，而并 不是所要实现的最终软件系统； 不是所要实现的最终软件系统； 系统的边界用来说明构建的用例模型的应用范围（ 系统的边界用来说明构建的用例模型的应用范围（用例在 系统之内）。 系统之内）。 工具中没有体现！ 在Rose 工具中没有体现！ （2）表示形式 用例图中的系统采用一个长方形框表示， 用例图中的系统采用一个长方形框表示，系统的名字写在 方框的上面或者方框内
2、用例模型中的基本组成部件 用例（UseCase） （1）用例（UseCase） （2）的参与者
（1）参与者：参与者表示系统用户所扮演的各个角色(role） 参与者：参与者表示系统用户所扮演的各个角色(role） (role
（2）参与者可能有 三大类 系统用户 （使用者或 者操作员） 者操作员） 与所建系统 交互的其他 系统 其它设备
于问题的延续性（ 于问题的延续性（在修改和录入中都有保存的功 但还提供了除保存之外的附加功能）。 能，但还提供了除保存之外的附加功能）。
注意区分扩展关系与前面的泛化关系的不同
三、如何进行用例建模
1、用例建模的主要步骤
2、如何编写用例
3、各种用例示例点评
（1）用例示例点评一：错误用例：提取现金 用例示例点评一：错误用例： （2）用例示例点评二：错误用例：提取现金 用例示例点评二：错误用例： 用例示例点评三：错误用例： （3）用例示例点评三：错误用例：买东西
利用用例图描述用户需求（ 利用用例图描述用户需求（用例建模 ）
在本讲您能了解如下知识点
UML中的用例 UML中的用例 用例之间的关系 用例图的组成部件 UML中的用例图及项目实例 UML中的用例图及项目实例
UML中的用例及用例图 一、UML中的用例及用例图
1、用例及用例建模技术产生的背景概述 UML之前对系统的需求描述方法 （1）UML之前对系统的需求描述方法
我们可以采用UML中的用例模型方法！ UML中的用例模型方法 （3）我们可以采用UML中的用例模型方法！
项目开始时， Case视图的主要使用者是客户 视图的主要使用者是客户、 项目开始时，Use Case视图的主要使用者是客户、分析人 员和项目管理员。 员和项目管理员。 这些人利用使用案例、 Case框图和使用文档来确定系 这些人利用使用案例、Use Case框图和使用文档来确定系 统的高层视图