《第3章用况图课件.ppt》由会员分享，可在线阅读，更多相关《第3章用况图课件.ppt（34页珍藏版）》请在三一办公上搜索。
1、第3章 用况图,本章的主要概念系统边界、参与者、用况、包含、扩展、泛化问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。,系统是由一条边界包围起来的未知空间,把内外交互情况描述清楚，就确切地定义了系统的需求,捕获与整理需求：即要发现业务逻辑和需求，并用用况描述进行描述。描述需求的范围：功能、属性、约束、风险等。系统功能：系统应该做。明显的（应该做的，显式的）、隐藏的（应该做的，隐式的）。系统属性：系统的特性或系统的度量，如易用性、容错性、响应时间、界面形式、零售价格
2、、应用平台。系统属性的使用范围：整个系统或部分。用况不是需求或功能的规格说明，但也展示了和体现了其所描述的过程中的需求情况。一个用况是一个或几个参与者使用系统的一项功能时所进行的交互过程的描述。,用况图：主要用于对系统、子系统或“类”的功能行为进行建模。益处：易于对需求规范化有利于进行OOA有助于发现主动对象对系统测试来说，产生测试用例。,系统边界,系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。系统：是由“用户”使用的软件，以及所有与其相关的硬件。指被开发的计算机软硬件系统，不是指现实世界的系统。系统成分：,参与者：在系统边界以外，与系统进行交互的事物人员、设备、外系统,系
3、统边界与参与者,31系统边界,定义：系统边界是一个系统所包含的所有系统成分与系统以外各种事物的分界线。系统是指被开发的计算机软硬系统自身，而不是泛指问题域的全部事物所构成的现实系统。如果在其中使用一个原来已经存在的系统，这样的系统就应该放在正开发的系统之外，把它看作是一个外系统。如果一个大系统在任务分解时，被划分成几个子系统，则每个子系统的开发者都可以把其他子系统看作是外系统，系统边界以内只包括自己所负责的子系统。,现实世界中的事物与系统的关系包括如下几种情况：某些事物位于系统边界内，作为系统成分。如超市中的商品，抽象为系统内的“商品”对象。某些事物位于系统边界外，作为参与者。某些事物可能既有
4、一个对象作为其抽象描述，而本身又是在系统边界以外与系统进行交互的参与者。如超市中的收款员，他本身是现实中的人，作为参与者；在系统边界内，又有一个相应的“收款员”对象来模拟其行为或管理其信息，作为系统成分。某些事物即使属于问题域，也与系统责任没有什么关系。如超市中的保安员，在现实中与超市有关系，但与所开发的系统超市商品管理系统无关系。这样的事物既不位于系统边界内，也不作为系统的参与者。,认识清楚上述事物之间的关系，也就划分出了系统边界。,32 参与者,简言之，参与者是在系统之外的与系统进行交互的任何事物。321 概念与表示法定义：用况的使用者在与这些用况交互时所扮演的一组功能高内聚的角色。参与者
5、是与系统交互的任何事务。,收款,检查,工作人员,参与者,用况,用况,关联,关联,参与者可以发出对系统服务的请求参与者能够初始系统部分的动作按系统的要求提供服务响应系统的请求（例如：提款机）通过参与者和系统之间服务请求的复杂对话与系统交互所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界。系统从来不会对没有被设计的问题域部分作出响应，也就是说它不处理没有被设计的请求输入。一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。它们存在于系统之外。,一些参与者可能具有共同的对系统调用的请求。一种做法是显式地将这样的每一
6、个请求与每一个参与者相关联。（不推荐）如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，它们再从中继承，把这种关系称为参与者之间的泛化关系。,322 识别参与者,下面是一些指导：1首先将精力集中于启动系统行为的参与者。这些是最容易识别的参与者，从中可以找出其他参与者。2从用户的角度考虑，怎样使用这个系统。3识别单个参与者在系统中可能担当的角色，然后确定参与者的各个角色。4.对识别出来的参与者，记录它们的责任。5.通过识别一般的或较特殊的角色来组织参与者。,从如下方面寻找参与者 用户从直接使用系统的人员中发现参与者。这里强调的是直接使用，而不是间接的。特定的人，在系统中可扮
7、演不同的角色。例如，添加数据、使用数据及产生报告的那个人就扮演了三种不同的角色，反映为三种不同的参与者。例如，用户角色的类别可为：目标终端用户、管理员、经理或顾客。外部系统所有与系统交互的外部应用系统都是参与者。从系统边界的角度，应该把与软件系统一起运行以完成特定任务的应用系统，看作是外部的应用。,设备识别所有与系统交互的设备。这样的设备与系统相连，向系统提供外界信息，或在系统的控制下运行。通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类型设备，但我们考虑外部传感器（输入信息）和受控马达（输出信息）。外部事件当构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变得更加重要了。例如
8、，一种说法：由时间的流逝而激发系统的活动是常见的情况。可以把时间事件作为一个参与者，也可以把时间事件作为系统的一部分，还可以把二者结合起来使用。,总结：如何发现参与者？人员系统的直接使用者直接为系统服务的人员设备与系统直接相联的设备为系统提供信息在系统控制下运行外系统上级系统子系统其它系统外部事件,33用况 用况是对参与者使用系统的一项功能时所进行的交互过程的描述。,1、使用用况的原因 用况是对用户需求（主要是功能需求）的规范化的描述。为领域专家、最终用户和开发者提供一种相互交流的手段。为开发者提供一种认识和理解系统的方法。用况是开发期间随着演化而测试每个元素的基础。使用用况，有助于捕获界面需
9、求。,定义：用况是对参与者使用系统的一项功能时所进行的交互过程的一个文字描述序列。几点说明：（1）一个用况描述参与者对一项或几项系统功能的使用情况。而且只有当外部的参与者与该系统或类目进行交互时，该功能才发挥作用。（2）陈述参与者和系统在交互过程中双方所做的事。（3）描述彼此为对方直接地做什么事，不描述怎么做，内部细节不要在其中描述。（4）描述应力求准确、清晰，允许概括，但不要把双方的行为混在一起。,2 定义及表示法,3 用况与参与者之间的关系,定义：用况与参与者间的关联是参与者在用况中的参与。参与者和用况之间的唯一关系：若没有进行特殊的说明，任何一方都可发送和接收消息，即交互是双向的。即，参
10、与者能够产生对系统的请求；系统要求参与者采取某些动作。,收款,检查,售货员,一个用况可能要与系统的一个或几个参与者交互。,统计员,4 用况之间的关系1）扩展关系,extend,从用况A到用况B的扩展关系是指，用况B的实例是可以被用况A指定的行为扩充。,4 用况之间的关系2）包含关系,B,A,include,从用况A到用况B的包含关系表明，用况A的一个实例也包含了用况B所指定的行为。,3）泛化子用况继承父用况的行为和含义；子用况还可以增加或覆盖父用况的行为；子用况可以出现在父用况出现的任何位置。用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。,B,A,父用况,子用况,5 捕获
11、用况,1）利用参与者捕获用况,对所有的参与者（把自己作为参与者），提问下列问题：每个参与者的主要任务是什么？为了达到某种目的，它们参加什么活动？该参与者是否将读写系统的任何信息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通知自己？在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？它们参加了什么在本质上是不同的过程？是什么事件引起了与系统进行交互的序列？,2）从系统功能角度捕获用况用于本步骤的一些简单的指导如下：（1）一个用况描述一项功能，这项功能不能过大。如粒度太大则细化。（2）全面地认识和定义每一个用况，要点是以穷举的方式考虑每一个参与者与系统的
12、交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理。（3）以穷举的方式检查用户对系统的功能需求是否能在各个用况中体现出来。（4）一个用况应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用况的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用况对待。,场景,用况,抽象,3）、使用场景技术,6、描述用况 对用况的功能描述，可采用自然语言，也可以采用用户定义的语言。大多数用况是简单的；只是一个操作的逻辑序列，该序列具有一个来自外界的出发操作。有一些用况要复杂一些，具有多个例外的情况（例如出错）或
13、不同的交互路径（可进行分支）。很多人在使用用况图时，还使用文本描述（捕获前置条件、后置条件、例外、不变条件和变元）；还有的人在此时还使用类图（概念类）、顺序图（捕获交互）、活动图。,用况文档模板,用况名描述：对该用况的一句或两句的描述。参与者：参与该用况的参与者。包含：该用况所包含的用况，以及包含它的用况。扩展：该用况可以扩展的用况，以及扩展它的用况。泛化：如该用况的子用况和父用况。前置条件：启动此用况所必须具备的条件。细节：该用况的细节。后置条件：在该用况结束时确保成立的条件。例外：在该用况的执行的过程中可能引起的例外。限制：在应用中可能出现的任何限制。注释：提供可能对该用况是重要的任何附加
14、信息。,34 用况图用况图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。定义 用况图呈现了一些参与者和一些用况，以及它们之间的关系。在图形上，用况图是一幅由一组参与者、一组用况以及这些元素之间的关系组成的图。这些关系是参与者和用况之间的关联、参与者之间的泛化，以及用况之间的泛化、扩展和包含。可以选择把一些用况用一个矩形围起来，用来表示系统、子系统或“类”的边界。用况图可以包含注解和约束。,use case a,use case b,use case c,用况图,参与者 s,参与者 g,被包含的use case,该用况应优先开发,运输公司,职
15、员,订购货物,获取订单状态,获取目录,取消订单,客户,退货,客户代表,运送货物,发送货物,计算运费,供货商,对系统的需求建模，要遵循如下策略：通过识别系统周围的参与者来建立系统的语境。对于每个参与者，考虑它期望的或需要系统提供的行为。把上述的行为命名为用况。分解公共行为，放入新的用况中，以供其他的用况使用；分解异常行为，放入新的用况中，以延伸较为主要的控制流。在用况图中对这些用况、参与者以及它们的关系进行建模。用陈述非功能需求的注解或约束来修饰这些用况，可能还要把其中的一些附加到整个系统。注：有人把不与系统进行内外交互的情况也作为一个用况，如在一个信用卡验证的系统中，把系统内的对信用卡的欺诈检
16、查也作为一个用况。,3.5 审查参与者 确定系统环境中的所有角色，并都归入了相应的参与者。每个参与者都至少和一个用况关联；若一个参与者是另一个参与者的一部分，或扮演了类似的角色，考虑在它们之间使用泛化关系；用况 每个用况都至少和一个参与者相关；若两个用况有相同或相似的序列，可能需要合并它们，或抽取出一个新用况，在它们之间使用包含、扩展或泛化关系。若用况过于复杂，为了易于理解，考虑进行分解；若一个用况中有完全不同的事件流，最好把它分解成不同的用况,3.6 用况图的适用范围适用 系统是面向功能的，具有多种类型的用户和功能行为。如：商业系统、多用户系统、大量功能性需求、少量设计约束。不适用 若系统的用户较少且接口也很少，或非功能性需求和设计约束占主导地位时，用况并不适用。如：科学计算系统、少量的功能性需求、大量的设计约束。,习题通常自动售货机会按用户的要求进行自动售货。供货员会巡查向其内供货，取款员会定时取款。请建立用况图，并描述各个用况。,
