利用用例图描述用户需求.pptVIP

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