用例图教学ppt,复习.pptx

唐姗 计算机与信息学院,第三讲 用例图,内容提要,上节回顾 用例的概念 用例建模技术,2,建模的简单流程,3,分析模型 捕获系统需求，建立“现实世界”的类和协作的模型 设计模型 在考虑实现环境的情况下，将分析模型扩展为可行的技术方案 实现模型 编写并编译程序源代码 部署模型 实现系统在物理结构中的部署,三种模型,4,类模型：系统中的对象及相互关系 表示系统静态的、结构化的数据层面 描述系统中对象的结构（标识，属性，操作，与其他对象的关系） 状态模型：对象的生命周期 表示系统时序的、行为的控制层面 标记变化的事件，界定事件上下文的状态,5,交互模型：对象如何交互 表示独立对象的协作，系统的交互层面 描述对象之间的交互。独立对象如何协作，从整体上完成系统的行为和功能 用例图、活动图、顺序图描述交互模型 用例图描述系统和外部参与者之间交互的主要内容 活动图显示程序实现步骤之间的控制流 顺序图显示交互的对象和交互的时间顺序,视图（Views）,6,完整地描述系统需要一组视图反映系统的各个方面 每个视图代表系统的一个抽象，反映了系统中的一个特定方面，从而使不同的人员关注系统的不同方面,用例视图,7,用例视图描述系统应该具有的功能集，它从系统外部用户(参与者)的角度出发，实现对系统的抽象表示 在用例视图中，参与者（Stakeholder）代表外部用户或其他系统，用例（Use-case）表示系统能够提供的功能，通过列举参与者和用例，显示参与者在每个用例中的参与情况 用例视图是其他视图的核心和基础，其他视图的构造和发展依赖于用例视图所描述的内容,8,用例图,逻辑视图,9,逻辑视图用来揭示系统功能的内部设计和协作情况 它利用静态结构和动态行为描述系统的功能 静态结构描述类、对象及其关系等 动态行为主要描述对象之间发送消息时产生的动态协作、一致性和并发性等 接口和类的内部结构需要在逻辑视图中定义,10,类图,11,协作图,并发视图,12,并发视图主要考虑资源的有效利用，描述系统的并发工作状况 并发视图包含形成并发与同步机制的线程和进程，主要使用者是开发人员和系统集成人员,组件视图,13,组件视图由一些独立的组件和文件组成，显示实现模块及它们之间的依赖关系,构件图,配置视图,14,配置视图主要描述系统的物理架构，显示系统硬件拓扑结构的节点，提供给开发人员、集成人员和测试人员,配置图,内容提要,上节回顾 用例的概念 用例建模技术,15,需求获得技术：用例建模,16,用例建模是由Jacobson在1994年首次提出的 用例建模是软件项目开发的第一步 用例图用于描述人们希望如何使用一个系统 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务,用例图,17,用例图（Use Case Diagram） 从系统使用者的角度来理解，为系统的总体功能 建立于系统需求阶段，是开发者和用户对系统需求达成的共识 用例图中包含的元素有： 用例（Use Case） 参与者（Actor） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）,用例,18,外部可见的系统功能单元 描述一个系统做什么 在不揭示系统内部构造的前提下，定义连贯的行为 不是需求或功能的规格说明，但也展示和体现其所描述的过程中的需求情况,取款,19,每个用例都必须有一个惟一的名字以区别于其他用例 用例的名字是一个字符串，包括： 简单名（simple name） 路径名（path name） 在用例名前加上所属包的名称,识别用例,20,识别用例是从业务建模开始的，识别用例最好的方法是从分析系统的参与者开始，也就是说一旦获取了参与者,就可以对每个参与者提出问题以获取用例 在识别用例的过程中，通过回答如下问题，系统的分析人员可以获得帮助： 参与者希望系统提供什么功能？ 参与者需要读取、删除、修改或存储系统中的信息有哪些类型？ 参与者需要将外部的哪些事件通知给系统？ 系统中发生的哪些事件需要通知给用户？,用例与事件流,21,用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统实现的细节问题 但是要实际建立系统，则需要更加具体的细节，这些细节写在事件流文件中 事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作 用例模型指的不仅仅是用例图，而是由用例图和每一个用例的详细描述所组成的 事件流通常包括： 简要说明 前置条件 事件流（主事件流、其他事件流、错误流 ） 后置条件,22,简要说明 描述该用例的作用，应包括执行用例的不同类型用户通过这个用例要达到的结果 前置条件表示用例开始时必须满足的条件(系统所处的状态) 后置条件表示用例结束时必须满足的条件(系统所处的状态) 事件流 从执行者的角度来看，事件流是一系列陈述句，它列出了用例的各个步骤,用例间的关系,23,用例除了与其参与者发生关联外，还可以具有系统中的多个关系，以便从系统中抽取出公共行为和其变体，这些关系包括： 关联关系 包含关系 扩展关系 泛化关系,关联关系（Association）,24,关联关系用于描述参与者与用例之间的通信 不同的参与者可以访问相同的用例,包含关系（Include）,25,虽然每个用例的实例都是独立的，但是一个用例可以用其他更简单的用例来描述 一个用例可以包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这种关系称之为“包含关系”,扩展关系（Extend）,26,扩展关系指的是一个用例可以增强另一个用例的行为 扩展用例被定义为基础用例的增量扩展 扩展用例提供了一个离散的行为，可以将自己添加到基础（执行）用例中 基础用例提供扩展点以添加新的行为 使用扩展可以使我们在不改变基础用例的同时，根据需要自由地往系统中添加行为,27,扩展点是一个条件，决定扩展是否会被使用。一旦条件满足，扩展用例就将自己加入到执行用例中。这是与包含关系的本质区别 例如：订单系统中需要判断如果是VIP客户买商品增加折扣,28,泛化关系（Generalization）,29,用例泛化：一个用例可以被特别列举为一个或多个子用例 子用例表示父用例的特殊形式 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为,30,参与者,31,参与者是系统外部的一个实体 表示用例的使用者在与用例交互时所扮演的角色，可以是：人、硬件设备或一个系统 参与用例的执行过程 通过向系统输入或请求系统输入某些事件来触发系统的执行 由参与用例时所担当的角色来表示 每个参与者可以参与一个或多个用例,如何确定参与者,32,系统开发人员可以通过回答以下问题来定义系统的参与者： 谁使用该系统的主要功能 谁需要维护、管理和维持系统的正常运行 谁读、写或修改系统中的信息 系统需要控制哪些硬件设备 系统需要与哪些其它外部设备交互 哪些人或哪些外部系统对本系统产生的结果感兴趣,参与者之间的关系,33,因为参与者是类，所以多个参与者之间可以具有与类之间相同的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为,内容提要,上节回顾 用例的概念 用例建模技术,34,用例模型的主要目标,35,将需求变为可视化模型，并得到用户确认 给出清晰、一致的关于系统做什么的描述，确定系统的功能要求 提供从功能需求到系统分析、设计实现等各阶段的度量标准 为最终系统测试提供基准，据此验证系统是否达到功能要求 为项目目标进度管理和风险管理提供依据,用例建模的步骤,36,确定系统的范围和边界 确定参与者和用例 对用例进行描述 定义用例之间的关系 审核用例模型,确定系统边界,37,软件开发过程的初始阶段一项重要的任务是清晰地确定未来系统边界 找出系统中有什么（这部分需要我们投入全部精力） 找出系统外有什么（这部分不需要实现，但需要考虑系统与它们的接口）,对环境建模,对需求建模,38,通过确定参与者和用例来确定系统边界 参与者是指在系统之外，与系统交互的所有事情，如：人、其它软件、硬件设备、数据存储或者网络 每一个执行者被定义成一种特定的角色。每一个系统之外的实体可以用一个或者多个执行者来代表 执行者一定是在系统之外 一个执行者可以启动多个用例 一个用例也可以被多个执行者启动,对用例进行描述,39,每一个用例都需要一个描述的名字和一两句简短的话描述，这些都应该标注在用例图中 描述用例必须描述需要完成哪些步骤才能实现这个用例的功能 描述用例时需要考虑基本功能、所有可选方案、异常情况、进入用例之前及退出用例时必须的条件 描述用例时可以使用条件、分支和循环,用例的特征,40,响应性：用例总是被执行者启动，用例不会自己主动执行, 回执性：用例执行完毕后，应向行为者提供可识别的返回值。 完整性：用例表示一个完整的功能，必须是一个完整的描述，可大可小 用例代表某些用户可见的功能，实现一个具体的用户目标 用例在以后开发过程中，可以进行独立的功能检测,41,完整的描述用例的模板 用例名: 名字需唯一 用例简述：用简洁明要地对用例进行概述 参与执行者: 与用例交互的执行者 前置条件: 用例启动前需要满足的条件 事件流: 用例的动作序列 通常情况 例外情况 后置条件: 用例完成后满足的条件 特殊需求: 非功能性需求,用例用自然语言编写, 便于开发人员和客户交流,42,用例名:订购商品 用例简述：合法用户订购产品 参与执行者: 系统用户 前置条件：一个合法用户已经登录到这个系统 事件流： 1.当客户选择订购货物时，用例开始； 2.客户输入自己的姓名和地址； 3.客户选择或输入购买产品的代码； 4.系统给出产品的描述和价格； 5.系统保存已经订购的产品清单； 6.客户输入信用卡支付信息； 7.客户选择提交； 8.系统检验输入的信息,把该订单作为未完成的较易保存,同时向记帐系统转发支付信息.如果客户提交的信息不正确,系统提示用户修改； 9.支付确认后,订单被标识为已经确认,同时返回给客户一个订单ID,用例结束.如果支付没有被确认,系统将提示客户改正支付信息或者取消.如果客户选择修改信息,回到(6),如果选择取消,用例结束。 后置条件：如果订单没有被取消，它将被保存在系统中，并做上标记。,订购商品用例描述,43,用例名: 购买单程车票 参与执行者