《uml系统建模基础教程 教学资料》由会员分享，可在线阅读，更多相关《uml系统建模基础教程 教学资料（25页珍藏版）》请在金锄头文库上搜索。
1、重点内容： 什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的各种重要关系 使用Rose创建用例图的步骤说明 使用Rose创建用例图的步骤说明,第6章 用例图,一、 什么叫用例图,由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。 要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。,1
2、、用例图的含义,一、 什么叫用例图,在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。,1、用例图的含义,一、 什么叫用例图,用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。
3、,2、用例图的作用,二、用例图的构成要素,参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。,1、参与者,二、用例图的构成要素,由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。 泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关
4、系。,2、参与者间的关系,二、用例图的构成要素,在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。 系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。,3、系统边界,三、用例的重要元素,任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。
5、可以通过以下问题来寻找用例： 1 参与者希望系统提供什么功能？ 2 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ 3 参与者是否会将外部的某些事件通知给系统？ 4 系统中发生的事件是否通知参与者？ 5 是否存在影响系统的外部事件。,1、识别用例,三、用例的重要元素,用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数
6、目过少会造成用例的粒度太大，不便于进一步的充分分析。,2、用例的粒度,三、用例的重要元素,用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。,2、用例的粒度,三、用例的重要元素,比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。,2、用例的粒度,我们还可以根据具
7、体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。,三、用例的重要元素,对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。 每一个用例的用例规约都应该包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，
8、包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。,3、用例规约,四、用例之间的各种重要关系,包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。,1、包含,四、用例之
9、间的各种重要关系,包含关系代表着基础用例会用到被包含用例，具体的讲就是将被包含用例的事件流插入到基础用例的事件流中。需要注意的是，包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)。,1、包含,四、用例之间的各种重要关系,在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系： 第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽 象成为一个用例，然后让其他用例来包含这一用例。 第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的
10、目的。,1、包含,四、用例之间的各种重要关系,在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。 一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。,2、扩展,四、用例之间的各种重要关系,用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。 在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。 子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用
11、例指向父用例来表示。,3、泛化,四、用例之间的各种重要关系,泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM机存款”为子用例。,3、泛化,五、使用Rose创建用例图的步骤说明,“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包
12、括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理
13、者都通过自己的用户名称和密码登录到各自的管理系统中。,1、需求分析,五、使用Rose创建用例图的步骤说明,（1）销售员：为客户客提供销售产品的服务。 （2）仓库管理员：负责库存产品的管理活动。 （3）采购员：负责企业生产原料的订购。 （4）会计：负责企业经营状况的统计。 （5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。,2、识别参与者,五、使用Rose创建用例图的步骤说明,销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。,3、构建用例模型,销售员用例图,五、使用Rose创建用例图的步骤说明,仓库
14、管理员能够通过该系统进行如下活动： （1）处理盘点，每天需要对库存产品信息进行盘点。 （3）产品入库。当产品生产后，将产品进行入库。 （4）产品出库。当产品销售发货后，进行出库处理。 （5）管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。,3、构建用例模型,仓库管理员用例图,五、使用Rose创建用例图的步骤说明,采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。,3、构建用例模型,采购员用例图,五、使用Rose创建用例图的步骤说明,会计负责产品的统计分析管理，它能够通过该系统进行如下活动： （1）查询基本信息。会计能够查询产品的基本
15、信息，根据产品的基本信息，制定出相应的方案。 （2）查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。 （3）查询供应商信息。会计能够查询供应商信息。 （4）查询缺货信息。会计能够查询缺货信息。 （5）查询报损信息。会计能够查询报损信息。,3、构建用例模型,会计用例图,五、使用Rose创建用例图的步骤说明,系统管理员能够通过该系统进行如下活动： （1）维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。 （2）维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。 （3）系统设置。系统管理员能够根据一些需要进行必要的系统设置。,3、构建用例模型,系统管理员用例图,
