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