《用况和用况》PPT课件.ppt

第四章 用况和用况图,一个用况代表一个系统或系统的一部分的行为，它的主要用处是：捕获与描述系统需求，同时也驱动整个开发过程。,用况图也称为用况模型，用于对系统的用况视图建模（用况视图是系统体系结构的五大视图之一）。,多数情况下，包括对系统、子系统或类的语境建模，或对这些元素的行为需求建模。它对可视化、详述和文档化一个元素的行为是非常重要的。,用况是对一组动作序列（业务过程）的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。,1. 用况（use case）,（1）用况的图形符号,在图形上，一个用况用一个椭圆表示。,4.1 用况,（2）用况的名称,每一个用况都必须有一个区别于其他用况的名称。用况名称（name）是一个字符串。在实际应用中，用况的名称是简短的主动语态的动词词组，用来描述被建模的系统的某些行为。,单独的名称称为简单名，在用况名前加上它所属的包的名称，称为路径名。,（3）用况与参与者,一个参与者表示用况的使用者在与这些用况进行交互时所扮演的角色的一个紧密的集合。,参与者所代表的角色有：人、硬件设备，或甚至是另一个系统。,例如：如果你在银行工作，你可能是一个贷款员， 如果你在该银行有存款，那么你同时也扮演一名顾 客的角色。所以，一个参与者的一个实例代表以一 种特定的方式与系统进行单独的交互。,注意：尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。,参与者的图形符号是人形图符,可以定义参与者的一般种类（比如Customer）并通过泛化关系将其特殊化（比如Commercial Customer）。,（4）用况与事件流,可以通过足够清晰的、外部人员容易理解的文字描述一个或一些事件流来说明一个用况的行为。,事件流中应该包含用况何时开始、何时结束，用况何时和参与者交互，什么对象被交换，以及该行为的基本流和可选择流。,例：在ATM系统中，可以采用下面的主事件流和异常 事件流来描述用况Validate User的行为：,异常事件流1：顾客可以在任何时间通过按“取消”按钮 取消一个事务，这样该用况重新开始。顾客的帐户未 发生改变。,异常事件流2：顾客可以在确认之前的任何时刻消除 PIN号，并重新输入一个新的PIN号。,异常事件流3：如果顾客输入一个无效的PIN号，用况 重新开始；如果连续3次输入无效的PIN号，系统将取 消整个事务，并在60秒内阻止该顾客与ATM交易。,主事件流：在系统提示顾客输入PIN编号时用况开始。 顾客通过按键输入PIN编号；顾客按“输入”按钮确认 登录；系统校验该PIN号是否有效。如果有效，系统 承认这次登录，该用况结束。,2. 组织用况,用况之间存在泛化关系、包含关系和延伸关系，我们可以利用这些关系来组织用况。,1） 用况之间的泛化关系,用况之间的泛化关系就像类之间的泛化关系，子（特殊）用况继承父（一般）用况的行为和含义；子用况还可以增加或覆盖父用况的行为；子用况可以出现在父用况出现的任何位置。,例：ATM系统中的Validate User用况，根据校验设备 的不同可以特例化为以下二个特殊用况： Check Password用况和Retinal Scan用况。,这二个特殊用况都有Validate User的行为，并且还添 加了各自的行为： Check Password用况检查文本密码； Retinal Scan用况检查用户唯一的视网膜模式。,2） 用况之间的包含关系,用况之间的包含关系表示基础用况在它内部说明的某个位置上显式地合并了另一个用况的行为。,被包含的用况从不孤立存在，仅作为某些包含它的更大的基础用况的一部分出现。可以想象为，它向基础用况提供行为。,可以将包含关系表示成一个构造型的include依赖关系（基础用况依赖于被包含的用况）。,例：Place Order（发出订单）用况和Track Order （获取和校验订单号）与Validate User用况存在包含 关系。,Place Order,Track Order,Validate User,3） 用况之间的延伸关系,用况之间的延伸关系表示基础用况在由延伸用况间接地说明的一个位置上隐式地合并了另一个用况的行为。,基础用况可以单独存在，但在一定条件下，它的行为可以被另一个用况的行为延伸。,该基础用况只是在一个被称为它的延伸点的确定位置上被延伸。,可以将延伸关系理解为延伸用况把行为放入基础用况中。,可以将延伸关系表示成一个构造型为extend的依赖关系。,例：Place Order（发出订单）用况和Place rush Order（发出急需单号）用况之间存在延伸关系。,延伸关系用于对可能被用户看作是可选系统行为的用况的一部分建模（Place rush Order是可选的）。,通过这种方式，可以把可选行为从必须行为中分离出来。,实例应用：一个零售系统将与订货的顾客进行交互， 然后，系统将装运订货、并通告顾客付帐。可以通过将 这些元素的行为声明为用况来对系统的行为建模。,所声明的用况包括：Place order、Track order、 Ship order和Bill customer。,用况模型如下图所示：,3. 识别用况,识别用况也称为发现用况。,（1）基本方法概述,可以通过考察用户如何使用系统完成他们的工作来发现用况，也即通过捕获功能性需求来发现用况。,每个能对用户增值的系统使用方式就是一个候选用况。,对这些候选用况进行详细说明、改变、划分为更小的用 况或相反地结合成更加完整的用况。,当以客户、用户和开发人员都能理解的方式正确地捕获 了全部的功能性需求，用况模型便基本完成了。,从非功能性需求中发现用况的附加成分。,用况除了描述功能需求之外，还可以说明某些非功能性需求，例如对某个用况特定的性能、可用性、准确度和安全性等的需求。这些都有必要作为用况的附加成分，附加到相应的用况中。,银行储户从指定取款数量到得到相应的货币的响 应时间在所有用况实例的95%中应该小于30秒。,例如：对于“取款”这一用况而言，应该附加下面的性能要求：,（2）实用的识别用况的方法和步骤,比较实用的识别方法有以下两种：,基于参与者的方法,基于事件的方法,基于参与者的方法,a. 识别出与系统或组织有关的参与者。,b. 对每个参与者，识别出他们发起或参加的执行过 程，这些执行过程就是候选用况。,基于事件的方法,a. 识别出系统必须响应的外部事件。,b. 把事件与参与者及用况联系起来。,例：找出销售点终端系统的可能的参与者及他们发起 或参加的活动。,系统的所有参与者和用况以及用况之间的关系（依赖、延伸、泛化等）构成用况模型。,4.2 用况模型和用况图,参与者“银行储户” 使用ATM从帐户中 取款，或存款到帐 户中，或在不同的 帐户之间转帐。上 述行为可以由三个 用况与“银行储户” 这个参与者之间的 交互来表示。,1.用况模型,用况模型用来与用户和客户在“系统应该做什么”方面达成共识。也即用况模型表示功能性需求。,可以认为用况模型是所有可能使用系统（用况）的方式的完整的规格说明，它可以用作与客户签定合同的一部分。,用况模型用用况图来表示。,2. 用况图,术语：用况图（use case diagram）是显示一组用况、参与者以及它们之间关系的图。,1）公共特性,用况图只是图的一种特殊类型，它具有与所有UML图一样的公共特征，即一个名称以及投影到模型上的图形化的内容。,2）内容,用况图通常包括：,用况,参与者,依赖（包含、延伸）、泛化及关联关系,注解和约束。,3）一般应用,用况图用于对系统的静态用况视图建模。该视图主要支持对系统行为的描述 ，即描述该系统在它的周边环境的语境中所提供的外部可见服务。,具体而言，对系统的静态用况视图建模时，一般会以对系统的语境建模和对系统需求建模两种方式来使用用况图。,（1）对系统的语境建模,系统的语境：给定一个系统，会有一些事物存在于系统的内部，一些事物存在于系统的外部，所有存在于系统外部并与系统进行交互的事物（参与者）构成了系统的语境。语境定义了系统存在的环境。,对系统的语境建模，包括围绕整个系统画一条线，并声明有哪些参与者位于系统之外并与系统进行交互。,上图（右图）显示了一个信用卡验证系统的语境，它强调围绕在系统周围的参与者，这些参与者分为两类：人和其他事物。,在该语境中，还有代表机构的参与者（出现在模型的右边），如零售机构（顾客通过该机构刷卡，购买商品或获得服务）、主办金融机构（负责信用卡帐户的结帐服务）。在现实世界中，这两个参与者不是人，而可能是一个软件密集型系统。,出现在模型左边的的参与者是顾客，分为个人顾客和团体顾客（存在泛化关系）。这些参与者是人与系统交互时所扮演的角色。,（2）对系统语境建模所要遵循的策略（步骤）,用以下几组事物来识别系统周围的参与者：,需要从系统中得到帮助以完成其任务的组；,执行系统的功能时所必须的组；,与外部硬件或其他软件系统进行交互的组；,为了管理和维护而执行某些辅助功能的组。,（2）对系统语境建模所要遵循的策略（步骤）,在需要加深理解的地方，为每个参与者提供一个构造型。,将这些参与者放入用况图中，并说明从每个参与者到系统的用况之间的通信路径。,利用泛化关系将相类似的参与者组织成一般/特殊的结构层次。,（2）对系统语境建模所要遵循的策略（续）,（3）对系统的需求建模,需求是一个系统的设计特性、特征或行为。当陈述一个系统的需求时，就相当于陈述建立在系统外部的事物和系统之间的一份契约，契约上声明了期望系统做什么。,用况图说明了系统所能提供的行为。因此用况图使我们能够将系统看作一个黑盒子，仅仅只能观察系统外部有什么，系统怎样与那些外部事物相互作用，但却看不到系统内部是如何工作的。,对一个系统的需求建模，主要是说明这个系统应该做什么（从系统外部的一个视点出发），而不考虑系统应该怎样做。,下图是对信用卡验证系统语境模型（用况图）的扩充，它加入了一些用况，这些用况对于一般顾客虽然不可见，但仍是系统的基本行为。,新增的用况的重要性：,Detect card fraud（检测信用卡的真伪）对于零售 销售机构和主办金融机构都是很重要的行为。,Report on account status（报告帐户的状态）是系 统语境中不同机构所需的另一个行为。,Manage Network outage表示的是为保证系统的可靠 性和不间断操作所需的辅助行为。,（4）对系统需求建模所要遵循的策略（步骤）,通过识别系统周围的参与者来建立系统的语境。,对于每个参与者，考虑它期望的行为或需要系统提供的行为。,分解公共行为，放入到新的用况中，以供其他的用况使用；分解异常行为，放入新的用况中以延伸较为主要的控制流。,在用况图中对这些用况、参与者以及它们之间的关系建模。,用陈述非功能需求的注解修饰这些用况；可能还要 把其中的一些附加到整个系统。,学生利用校园卡刷卡报到，注册代理通过“一卡通刷卡报到接口”获取报到信息、通过“财务缴费接口”获取学生缴费信息、通过共享数据库获取学生的学籍信息、处分信息，实施自动注册，当“已按时报到”、“已按要求缴费或已获准缓交学费”，“上一学年未受开除学籍处分或退学处理”等三个条件同时满足，则予以注册，否则暂不予以注册。,4.2 用况模型和用况图（续）,3.用况模型设计实例学生注册系统用况模型,（1）注册业务需求概述,学生注册的主要业务包括：报到与注册、缓缴费、缓注册的申请与审批 、报到、注册情况的查询与统计。,报到与注册,（1）注册业务需求概述（续）,缓缴费、缓注册的申请与审批,学生可以在网上申请缓交学费，此申请必须经过所在院（系）审核及财务处审批。因特殊情况无法及时到校的学生可以在网上申请缓注册，此申请必须经过所在院（系）审核及教务处审批。,报到、注册情况的查询与统计,教务处、财务处、学生处及有关校领导可以及时了解全校学生的报到、注册情况，并获得所需的各种统计数据（报到率、注册率、缴费率、欠费情况、申请缓缴费情况等）。,（1）注册业务需求概述（续）,报到、注册情况的查询与统计（续）,各院（系）可以及时了解本院（系）学生的报到、注册情况，并获得所需的各种统计数据（报到率、注册率、缴费率、欠费情况、申请缓缴费情况等）。,（2）注册系统功能概述,由上述业务需求可以提炼出该系统的主要功能如下：,报到、自动注册、缓缴费申请与审批（工作流）、缓注册申请与审批（工作流）、报到情况查询与统计、注册情况查询与统计、系统维护。,（3）用况模型设计（顶层）简介,参与者,学生、相关职能部门的管理人员（教务处、学生处、财务处、院（系）、校领导。,相关业务系统、学籍管理系统、学工管理系统、财务系统（缴费接口）、共享数据库接口、一卡通接口。,高层用况,报到、自动注册、缓缴费申请、缓缴费审批、缓注册申请、缓注册审批、报到情况查询与统计、注册情况查询与统计、系统维护。,报到,自动注册,报道情况查询 与统计,注册情况查询 与统计,缓缴费申请,缓注册申请,缓缴费审批,缓注册审批,系统维护,4.3 为什么使用用况,最好的用况是能够为使用该系统的业务提供最大的价值。,用况具有益处并且被普遍采用的原因很多，其中两个主要原因是：,（1）提供了一种捕获与描述功能需求的系统的、直接 的方法。,（2）用况可以驱动整个开发过程，因为大部分活动， 如分析、设计和测试都是从用况开始执行的。设计和 测试可根据用况进行规划和协调。,（1） 用况用于捕获和描述软件系统的需求,需求捕获有两个目标：发现真正的需求并以适合于用户、客户和开发人员的方式加以表示。,第一个目标（真正的需求），是指在实现时可以给用户带来预期价值的需求。,目标二（以适合于用户、客户和开发人员的方式加以表示），是指对需求的最后描述必须能够让用户和客户理解。这是需求工作流的主要难点之一。,在寻找和确定类、子系统和接口时，在寻找并确定测试用例时，在规划开发迭代和系统集成时，均可以将用况作为主要输入。,（2）驱动整个开发过程,用况不只是捕获需求的工具，它还能够驱动整个开发过程，而且将整个过程的各个阶段结合为一个整体。,对于每一次迭代，用况驱动完成一整套工作流（从需求捕获、经由分析、设计和实现，到测试），并把这些不同的工作流结合在一起。,统一过程是从需求到测试的一系列工作流，