UML统一建模语言chapter06

UML统一建模语言重点内容：什么叫用例图用例图的构成要素用例的重要元素用例之间的各种重要关系使用Rose创建用例图的步骤说明使用Rose创建用例图的步骤说明第6章用例图UML统一建模语言一、什么叫用例图由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。1、用例图的含义UML统一建模语言用例图的符号参与者系统用例关联extendinclude泛化包含扩展UML统一建模语言一、什么叫用例图在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。1、用例图的含义UML统一建模语言一、什么叫用例图用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。2、用例图的作用UML统一建模语言二、用例图的构成要素参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。1、参与者UML统一建模语言•参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者UML统一建模语言二、用例图的构成要素由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。2、参与者间的关系UML统一建模语言二、用例图的构成要素在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。3、系统边界UML统一建模语言二、用例图的构成要素用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景用例应该给参与者带来可见的价值，这点十分关键4、用例UML统一建模语言三、用例的重要元素任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。可以通过以下问题来寻找用例：1参与者希望系统提供什么功能？2参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？3参与者是否会将外部的某些事件通知给系统？4系统中发生的事件是否通知参与者？5是否存在影响系统的外部事件。1、识别用例UML统一建模语言三、用例的重要元素用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。2、用例的粒度UML统一建模语言三、用例的重要元素比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。2、用例的粒度我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。UML统一建模语言三、用例的重要元素对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。3、用例规约UML统一建模语言用例描述模板（1/2）用例编号[为用例制定一个唯一的编号，通常格式为UCxx]用例名称[应为一个动词短语，让读者一目了然地知道用例的目标]用例概述[用例的目标，一个概要性的描述]范围[用例的设计范围]主参与者[该用例的主Actor，在此列出名称，并简要的描述它]次要参与者[该用例的次要Actor，在此列出名称，并简要的描述它]项目相关人利益说明项目相关人利益[项目相关人员名称][从该用例获取的利益]…………前置条件[即启动该用例所应该满足的条件。]后置条件[即该用例完成之后，将执行什么动作。]成功保证[描述当前目标完成后，环境变化情况。]UML统一建模语言用例描述模板（2/2）基本事件流步骤活动1[在这里写出触发事件到目标完成以及清除的步骤。]2……(其中可以包含子事件流，以子事件流编号来表示)扩展事件流1a[1a表示是对1的扩展，其中应说明条件和活动]1b……(其中可以包含子事件流，以子事件流编号来表示)子事件流[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]规则与约束[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]UML统一建模语言用例：购买商品基本事件流1.顾客浏览货单并选择要买的商品2.顾客选择付款3.顾客填写采购信息（地址、隔天或3天送货）4.系统显示价目信息5.顾客填写信用卡信息6.系统检查信用卡的合法性7.系统确认销售8.系统给客户发出确认电子邮件UML统一建模语言扩展事件流：固定客户•3a.系统显示当前购物信息、价格信息、信用卡的最后四位数字•3b.顾客接受或修改这些隐含值。转至主场景的第6步扩展事件流：信用卡失效•6a.系统检查信用卡失败。允许客户重新执行第5步UML统一建模语言四、用例之间的各种重要关系用例图中可以出现以下几种关系：①.关联关系②.包含关系③.扩展关系④.泛化关系UML统一建模语言参与者与用例之间是关联关系，表示参与者与用例之间具有使用、交互信息的关联。–用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动–每个用例都有参与者启动，除包含和扩展用例–习惯上，无论用例和参与者之间是否存在双向数据交流，关联总是由参与者指向用例四、用例之间的各种重要关系1、关联UML统一建模语言四、用例之间的各种重要关系包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。2、包含UML统一建模语言四、用例之间的各种重要关系两个用例之间，一个用例(基本用例)的行为包含了另外一个用例(被包含用例)的行为。两个以上用例有共同功能，可分解到单独用例，形成包含依赖。（执行基本用例时，每次都必须调用被包含用例）UML统一建模语言•一个用例功能过多需分解成小用例，构成包含依赖UML统一建模语言四、用例之间的各种重要关系在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。UML统一建模语言四、用例之间的各种重要关系在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。3、扩展UML统一建模语言–基本用例提供了一组扩展点（extensionpoints），在这些扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点–一般情况下，基本用例的执行不会涉及扩展用例的行为；如果特定条件发生，扩展用例的行为才被执行–扩展用例依赖于基本用例，只是部分片段组成，不是完整的独立用例，无法单独执行UML统一建模语言四、用例之间的各种重要关系用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。4、泛化UML统一建模语言四、用例之间的各种重要关系泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM机存款”为子用例。4、泛化UML统一建模语言五、使用Rose创建用例图的步骤说明“企业进、存、销管理系统”功能性需求包括以下内容：（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。（2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。（3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。（4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。（5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。1、需求分析UML统一建模语言五、使用Rose创建用例图的步骤说明（1）销售员：为客户客提供销售产品的服务。（2）仓库管理员：负责库存产品的管理活动。（3）采购员：负责企业生产原料的订购。（4）会计：负责企业经营状况的统计。（5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。2、识别参与者UML统一建模语言五、使用Rose创建用例图的步骤说明销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。3、构建用例模型销售员用例图UML统一建模语言五、使用Rose创建用例图的步骤说明仓库管理员能够通过该系统进行如下活动：（1）处理盘点，每天需要对库存产品信息进行盘点。（3）产品入库。当产品生产后，将产品进行入库。（4）产品出库。当产品销售发货后，进行出库处理。（5）管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。3、构建用例模型仓库管理员用例图UML统一建模语言五、使用Rose创建用例图的步骤说明采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。3、构建用例模型采购员用例图UML统一建模语言五、使用Rose创建用例图的步骤说明会计负责产品的统计分析管理，它能够通过该系统进行如下活动：（1）查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。（2）查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。（3）查询供应商信息。会计能够查询供应商信息。（4）查询缺货信息。会计能够查询缺货信息。（5）查询报损信息。会计能够查询报损信息。3、构建用例模型会