软件工程用例图复习过程
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图可视化地表达了系统的需求，具有直观、规范 等优点，克服了纯文字性说明的不足。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
1. 参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、 子系统或类的外部实体的抽象。
可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。
用例的重要元素
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
用例之间的关系
在处理包含关系时，具体的做法就是把几个用例的公 共部分单独的抽象出来成为一个新的用例。主要有两 种情况需要用到包含关系：
第一，多个用例用到同一段的行为，则可以把这段共 同的行为单独抽 象成为一个用例，然后让其他用例 来包含这一用例。
第二，某一个用例的功能过多、事件流过于复杂时， 我们也可以把某一段事件流抽象成为一个被包含的用 例，以达到简化描述的目的。
什么叫用例图பைடு நூலகம்
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。
第五章 用例图
学习内容
什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的关系 使用Rose创建用例的步骤说明
什么叫用例图
1. 用例图的含义
• 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的 用于描述系统功能的动态视图称为 用例图。要在用例图上显示某个用 例，可绘制一个椭圆，然后将用例 的名称放在椭圆的中心或椭圆下面 的中间位置。 • 要在用例图上绘制一个参与者 （表示一个系统用户），可绘制一 个人形符号。参与者和用例之间的 关系使用带箭头或者不带箭头的线 段来描述，箭头表示在这一关系中 哪一方是对话的主动发起者，箭头 所指方是对话的被动接受者。
2. 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多，反 之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。 如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析。
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例之间的关系
包含关系代表着基础用例会用到被包含用例，具体的 讲就是将被包含用例的事件流插入到基础用例的事件 流中。需要注意的是，包含关系是UML1.3中的表述， 在UML1.1中，同等语义的关系被表述为使用(uses)。
每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流 程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特 殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。 例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要 求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在 某个用例执行完后，必须执行另一个用例。
系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此， 系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统 相关联的其他部分，称之为系统环境。
用例的重要元素
1. 识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参 与者也必须要有与之关联的用例。所以识别用例的最好方法就是 从分析系统参与者开始，在这个过程中往往会发现新的参与者。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参 与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图 标下面。
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
用例的重要元素
• 比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、 修改会员信息、删除会员信息等操作。
• 我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是 完全一样的。
用例的重要元素
3. 用例规约
对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个 系统有一个更加详细的了解，这些信息包含在用例规约之中。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
1. 参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、 子系统或类的外部实体的抽象。
可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。
用例的重要元素
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
用例之间的关系
在处理包含关系时，具体的做法就是把几个用例的公 共部分单独的抽象出来成为一个新的用例。主要有两 种情况需要用到包含关系：
第一，多个用例用到同一段的行为，则可以把这段共 同的行为单独抽 象成为一个用例，然后让其他用例 来包含这一用例。
第二，某一个用例的功能过多、事件流过于复杂时， 我们也可以把某一段事件流抽象成为一个被包含的用 例，以达到简化描述的目的。
什么叫用例图பைடு நூலகம்
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。
第五章 用例图
学习内容
什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的关系 使用Rose创建用例的步骤说明
什么叫用例图
1. 用例图的含义
• 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的 用于描述系统功能的动态视图称为 用例图。要在用例图上显示某个用 例，可绘制一个椭圆，然后将用例 的名称放在椭圆的中心或椭圆下面 的中间位置。 • 要在用例图上绘制一个参与者 （表示一个系统用户），可绘制一 个人形符号。参与者和用例之间的 关系使用带箭头或者不带箭头的线 段来描述，箭头表示在这一关系中 哪一方是对话的主动发起者，箭头 所指方是对话的被动接受者。
2. 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多，反 之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。 如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析。
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例之间的关系
包含关系代表着基础用例会用到被包含用例，具体的 讲就是将被包含用例的事件流插入到基础用例的事件 流中。需要注意的是，包含关系是UML1.3中的表述， 在UML1.1中，同等语义的关系被表述为使用(uses)。
每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流 程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特 殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。 例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要 求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在 某个用例执行完后，必须执行另一个用例。
系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此， 系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统 相关联的其他部分，称之为系统环境。
用例的重要元素
1. 识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参 与者也必须要有与之关联的用例。所以识别用例的最好方法就是 从分析系统参与者开始，在这个过程中往往会发现新的参与者。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参 与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图 标下面。
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
用例的重要元素
• 比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、 修改会员信息、删除会员信息等操作。
• 我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是 完全一样的。
用例的重要元素
3. 用例规约
对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个 系统有一个更加详细的了解，这些信息包含在用例规约之中。