第9章 需求分析与用例模型.ppt

第9章需求分析与用例模型,9.1需求分析9.2参与者（Actor）及其关系9.3用例及其关系9.4用例图和用例模型9.5用例规格说明（specification）9.6用例描述中常见的错误举例9.7使用用例方法发现和确定系统功能需求,9.1需求分析9.1.1系统需求和需求描述根据来源的不同，需求可以分成用户需求、业务需求和系统需求，其中系统需求是用户需求和业务需求在系统中的反映，是综合各种需求因素以及系统约束之后确定的系统规格。需求描述是指系统的规格化描述，也称为软件需求规格说明(SRS)，其目的在于收集和组织有关项目的所有需求，包括功能需求和非功能需求。在RUP中，系统的功能需求由用例模型给出，非功能需求则由相关文档进行描述。,9.1.2需求类型需求有多种类型，其中一种需求分类方法为FURPS+。F代表Functionality(功能)、U代表Usability(可用性或者可操作性)、R代表Reliability(可靠性)、P代表Performance(性能)、S代表Supportability(可支持性)。+表示还包含如下需求：设计约束、实现需求、接口需求、物理需求等。功能需求说明一个系统在不考虑物理约束的情况下必须要执行的行为，它在用例模型中可以得到很好的描述。功能需求也说明了系统的输入、输出行为(用户输入什么，系统响应什么)。除功能需求之外的其他需求都称为非功能需求。,关于非功能需求简单介绍如下。可用性需求包括文化因素、美学、用户界面一致性、在线帮助和上下文敏感帮助、向导和代理、用户文档、培训资料等。可靠性需求指的是产品失效的频率和严重性、可恢复性、可预测性、精确性、平均失效间隔(MTBF)。性能需求是指功能需求的条件和约束。例如：对于某个行为(功能)，可以制定其性能参数，如速度、效率、有效性、精确度、吞吐量、响应时间、恢复时间、资源用法等。,可支持性包括可测试性、可扩展性、可适应性、可维护性、可兼容性、可配置性、可服务性、可安装性、可本地化性(国际化)等。设计约束指定系统设计的约束，例如使用MVC模式、CORBA等。实现需求指定编码或者建造系统的约束，例如：需要的标准、实现的语言、数据库完整性策略、资源限制、操作环境等。接口需求是指系统和外部交互的需求，包括格式、时间及其他约束。物理需求说明系统的物理特性，如物质、形状、尺寸、重量等，也可以描述硬件需求，如物理网络配置等。,9.1.3需求与用例模型用例(UseCase)是从使用者的角度或者说从系统外部观察系统的功能。它是系统功能抽象的使用案例，描述了系统功能的使用过程或者与用户的交互过程。用例可以看成是一种观察系统、描述系统的角度，从用例角度来看，系统被看成是黑盒，不涉及或者不关心系统内部如何实现，只关注系统做什么。这正符合需求分析阶段的主要任务，即定义系统做什么，而不是如何去做。,用例模型就是描述系统中所有功能的用例集合，定义了系统做什么。用例分析方法是一种和用户交流并获取需求的技术和手段，具有简单直观、容易上手的特点。与结构化分析方法(SA)中的数据流+数据字典方法、传统的面向对象软件工程(OOSE)方法中的对象模型方法相比较，用例模型更容易被用户和开发者理解，从而更便于对系统的需求取得共识，更适合作为系统分析人员和用户之间交流的工具。,用例模型本身是以系统功能为目标，从外部来观察其实现或者操作过程。从认识论角度来看，用例也可以扩充成从实现者的角度来观察用例的实现过程，即用例实现(UseCaseRealization)，这正符合了从外至内、由表及里的认识规律，也比较适用于逐步改进的迭代式开发方法。在用例模型中仅包含有参与者(Actor)、用例(UseCase)及其关系等三种建模元素，因此比较简单，容易掌握，下面分别对三种元素进行说明。,9.2Actor及其关系9.2.1Actor从字面上看，Actor有演员、角色、参与者、作用者、行动者和行为者的意思。在RUP中，Actor被定义为一组系统用户扮演的用于和系统交互的角色(Role)。RationalRose中对Actor的定义是：Actor代表系统用户，用来界定系统并给出系统应该做什么的清晰的图示。Actor只和用例交互，而并非控制用例。可以根据下面几点来确定Actor。(1)使用系统并和系统交互。(2)给系统提供输入或者从系统获取信息。(3)是系统外部的因素，不控制用例。,图9.1参与者图例,Actor可以代表系统用户，也可以代表系统之外其他的任何事物，如其他软件系统、打印机等。Actor可以是系统之外但和系统有关的任何元素，包括影响系统和受系统影响的任何元素。利用Actor可以帮助定义系统边界(定界或者界定系统)。凡是抽象成Actor的都是系统之外的元素，凡是抽象成UseCase的都是系统之内的功能。从而给出一个系统做什么、不做什么的清晰的全景图。需求阶段的主要任务就是确定系统边界，即决定系统做什么，不做什么，因此Actor和UseCase组合起来正好完成这一任务。为了全面地理解和界定系统，就不能不对系统之外的和系统有关的因素，如用户、环境等进行分析。Actor是抽象的，相当于用户类型或者用户类，其实例才是用户。Actor和用户的关系是多对多的关系。,定义Actor需要给出Actor的名字及其描述，例如学生，使用选课系统的用户之一。更详细的描述可以给出该Actor与其他Actor的关系(一般是泛化关系)，还可以利用UML的扩展机制，如tag来对其进行扩充，例如author,version等。Actor举例：用户、客户、仓库管理员、学生、打印机、财务系统、信用系统。每个参与者应该给出适当的说明。如用户：使用系统的各种人员；客户：订购公司产品的人员；财务系统：处理日常帐务的系统，等等。,9.2.2如何发现ActorActor是和系统有关的外部事物或者元素。我们可以从将要使用系统的具体用户开始分析，将其分类，抽象其类型。还可以从和系统有关的人或者环境方面进行分析，逐一识别出使用系统和维护系统的人(如提供、使用、删除信息的人)、使用系统功能的人、对系统需求感兴趣的人(投资商、管理者等)、系统所在的环境、系统在哪个部门被使用、系统使用的外部硬件和资源、需要和系统交互的其他系统，等等。,对于一个组织(如企业)来说，为了实现组织的目标，需要定义相应的岗位，每个岗位都有自己相应的职责，然后根据这些岗位来聘用员工，即所谓定岗定编。对于企业来说，也可以从某个业务的系统实现过程的描述开始，将所涉及到的系统之外的因素都找出来，作为参与者的候选对象。RationalRose的帮助文档中指出，可以通过检查下面元素来发现参与者：(1)直接使用系统的人。(2)负责维护系统的人。(3)系统使用的外部硬件。(4)其他需要和该系统交互的系统。,根据Actor的职责和需求来开发系统功能或者用例，可以保证系统需求将是用户所希望的，也是和系统运行环境一致的。很多组织(企业)经过业务重组(改制)、规范和优化，整合了核心业务，划分为不同的组织部门。对每个组织部门都设置主要职责和目标，为实现这些职责和目标又设计了不同的岗位，实行定岗定员、岗位责任制。其中，岗位就符合Actor定义的所有特征要素，如抽象性、系统外部性和相关性，可以将其抽象成Actor。,岗位是Actor非常好的业务原型，每个岗位都有确定的目标和职责，每个岗位的职责就可能变成该Actor的职责，也就可能会演化成系统的功能用例。一个岗位可以有多个具体的人承担，一个具体的人也可以承担多个岗位，例如销售统计岗、生产管理岗等。但是需要注意的是，在业务模型中，岗位可能被定义成业务工人(BussinessWorker)，是系统内部的对象，这也说明了业务模型和系统模型抽取的系统边界是不同的。如果在建立业务模型时已经描述了业务工人的特性，则将其转换为Actor后，所有特性依然有效。,9.2.3Actor之间的关系参与者的元数据类型是类，是类的一种特殊版型。因此，类之间的关系都适合于参与者之间，如泛化、关联关系等。因为参与者一般是系统之外的对象，只需要观察其对系统的影响或者受系统的影响，通常不需要详细建模。但是，有一部分参与者本身会转换为系统内部对象，如用户对象等。因此对这些参与者有必要进行详细建模，只不过应该在系统建模阶段来细化对象之间的关系。一般来说，在确定系统边界和功能的期间不宜细化这种对象的细节，但在不影响直观性的前提下，可以定义参与者之间的泛化(Generalization)关系。,泛化关系就是一种分类或者抽象关系。这时候可以把参与者看成是一般对象，只不过是系统之外的对象。具体的参与者和更加抽象的参与者之间的关系可以使用泛化关系来表示。比如说，课程注册系统的用户分为几种类型：用户、系统管理员、教师用户、学生用户等。用户是抽象的，分为三种具体类型，分别是系统管理员、教师、学生等。参与者之间的关系如图9.2所示。又例如网上教学系统(教学网站)的用户类型有：普通用户、游客、教师、家长、学生、管理员等。企业信息管理系统的用户类型有：信息输入员、报表统计员、生产协调员等。,图9.2参与者之间的关系,参与者之间也可以有关联关系。因为参与者是系统之外的对象，一般不需要对这些关系建模。我们研究参与者的目的是为了从系统之外的相关因素(环境因素)来认识和建模系统，这是由于系统本身的复杂性所致。参与者作为对象具有两种状态(多态性)，一是外部操作者，二是内部对象。很多参与者对象都会转换成系统的内部对象，如用户、供应商、客户等。这样就需要在系统的逻辑模型中定义这些对象及其相关对象。这实际上是同一个对象实例的两种形态，一种是系统之外的操作者，另一种是系统内部的信息实体。对参与者的进一步描述应该包括对其职责的描述，这种职责最终会对应系统的功能。,9.3用例及其关系9.3.1用例(UseCase)用例(UseCase)的全称为使用案例，是用户为了获取有价值的目标(为了达到一定的目的)，对系统功能的执行过程。用例包括一个或者多个交互活动序列。简而言之，用例是系统功能执行过程的抽象，也是参与者为了达到一定目的而和系统交互过程的抽象，是特殊的过程对象的抽象。在UML中，用例使用带有文字描述的椭圆图标来表示，如图9.3所示。,在用例定义中有两点需要注意：(1)用例必须获取有价值的目标或者达到一定的目的。(2)通过一个或者多个交互活动序列来完成该目标。这两点是抽取用例、确定用例粒度和描述用例的基础，例如在ATM机上取款是一个用例，其目的很明确，也需要通过一系列的交互活动来达到此目的。输入密码则不是一个用例，因为其没有包含一系列的系统交互活动。,图9.3用例的图符,UML的主要提出者Rational公司给出的用例定义为：简单地说，用例可以描述为从用户或者参与者(Actor)的角度使用系统的具体方式；具体地说，一个用例是系统展示的外部行为模式或者模板、由参与者和系统执行的一个交互事务序列、给参与者提交一些有价值的结果。该定义同样强调了交互序列和获取有价值的结果这两个要点。同时还指出，用例是系统外部行为(功能)模式。从这一点来看，用例也可以看成是场景(scenario)的抽象，而场景是对系统功能的一次具体执行过程。用例是过程对象的抽象，其原型也是类(class)，因此也具有类之间的关系，例如泛化关系等。用例作为过程对象的抽象，有别于类作为实体对象的抽象。前者关心的是其动态的过程结构，而后者则关注其静态的数据和行为结构。,用例把系统看成是黑盒，只关心其做什么而不关心怎么做，因此非常适合于定义系统需求规格。用例提供了一种能够比较简单直观地获取系统需求、支持开发者与终端用户及领域专家进行交流、测试系统的方式。需求分析阶段的用例可以作为开发阶段的实现用例、测试阶段的测试用例、维护阶段的维护用例的基础。用例也是一种思维方式或者方法，强调用具体生动的过程交互细节描述来刻画一个过程事物的外部和动态的特性。用例本身也不失抽象性，能够将同一个功能的各种具体交互的场景统一于一个用例之下，还可以将多个用例的共性部分抽象为父用例。,获取用例的方法主要是通过检查参与者并定义该参与者利用系统所做的事情或者所完成的功能。参与者或者对象的命名一般都是名词或者名词短语，表示一个事物，而用例则表示一个过程。一般使用动词短语来为用例命名。例如转账、取款、查询余额、加入购物车、选课、修改密码、维护(新增、删除、修改)学生基本资料、录入学生成绩、录入客户资料、下载课件、观看课件，等等。,要注意，这里所提及的用例和第8章中的业务用例之间是有区别的。用例和业务用例本质上是一样的，都是对活动序列的描述，但其描述的对象不一样。用例是指信息系统或者软件系统功能的执行过程，业务用例则是指原始系统(可能是现实世界或者问题域)某个业务功能执行的过程。业务用例是用例的基础，用例是业务用例在计算机系统中的映射和实现。有时候也把用例叫做系统用例，实际上业务用例和系统用例是抽象用例的两种特殊情况或者类型，可以用版型来区别它们。用例和业务用例之间的关系是依赖关系。图9.4中，采购业务用例表示组织中实际的采购过程，采购用例表示以此业务用例为基础开发的信息系统中的采购功能的执行过程。,图9.4用例和业务用例的关系,9.3.2用例的版型(Stereotype)及用例观点可以使用UML的不同版型(Stereotype)来对用例进行分类。如业务用例版型为，业务用例实现版型为，用例实现版型为，等等。在业务建模部分中已经就业务用例和业务用例实现问题进行了阐述，用例实现将在分析设计模型中加以说明，此处不再赘述。正如对象观是一种世界观一样，用例观也是世界观的一种。前者所抽象的是事物的组成结构，是静态的；后者所抽象的是事物的过程结构或者行为结构，是动态的。用例的实质在于从使用者或者参与者的角度来观察某个事物的进行过程，观察者不同，则观察结果不同。,根据观察者所属的角色不同，观察结果也是截然不同的。很明显，业务人员的观察结果和开发人员的观察结果就是不同的。从系统外部看到的用例是系统用例，从系统内部观察的用例是用例实现。因为内部和外部是相对的，所以说用例和用例实现也是相对的。对于用户来说，系统功能的操作过程是用例，其内部实现是用例实现；对于程序员来说，程序是用例、程序的内部执行过程是用例实现。类似的，还可以定义测试用例、开发用例、部署用例等。总之，用例的本质在于案例，案例的本质在于过程，所有为达到一定目的或者获取一定结果而执行的动态过程都可以抽象为案例(Case)。案例的特点在于它是直观的(intuitionistic)、生动的(lively)、动态的(actively)、面向过程的(processoriented)。,9.3.3用例之间的关系1包含关系包含关系连接一个基本用例和被包含用例。被包含用例描述了将被插入到基本用例中的行为片断。基本用例控制包含关系，并且依赖于被包含用例的执行结果，但基本用例和被包含用例都不能互访其属性。被包含用例封装了可在多个用例中重用的行为。使用包含关系可以从基本用例中分解出公共行为，该公共行为的实现方法对理解基本用例的目的而言是无关的，基本用例仅仅依赖于其结果(即不关注被包含用例的过程，只关注其结果)，也可以将两个或者两个以上用例的公共部分分离出来，经封装后形成被包含用例。,例如：在ATM系统中，取钱、存钱、转账用例都需要包含客户认证过程。这个公共过程可以被抽象成一个客户认证用例。基本用例与客户认证的方法无关，只与认证的结果有关。因此该过程被封装在被包含用例中。从基本用例的角度来看，使用磁卡认证还是图像认证是无关的，仅仅依赖于认证的结果。从被包含用例角度来看，它也不关心基本用例是如何使用该结果的。包含用例有点类似于函数调用。一个基本用例可以包含多个被包含用例，一个被包含用例也可以被多个基本用例包含，它们彼此呈现多对多关系。同一个基本用例也可以多次包含同一个包含用例，插入到不同的地方。,包含关系定义了插入的位置，它也可以嵌套。被包含用例不需要参与者与其直接关联，只有当被包含用例的行为需要显式地和参与者交互时才需要通信关联关系。包含关系使用特殊的依赖关系(版型为)来表示，见图9.5。,图9.5用例之间的包含关系,图9.6用例包含关系举例,2.扩展关系扩展关系用来把一个扩展用例连接到基本用例，可以定义基本用例中的扩展点。其目的或者是表示基本用例的一部分行为是可选的，将可选部分和必须部分分离开来；或者表示扩展用例代表的子工作流仅在某个条件满足时才被执行；或者表示有一组行为片断，其中一个或多个被插入到基本用例的扩展点。扩展是有条件的，即依赖于基本用例的执行情况。基本用例不控制扩展的条件，条件在扩展关系中描述。扩展用例可以访问和修改基本用例的属性，但基本用例不能看到扩展用例也不能访问其属性。基本用例隐含地被扩展用例修改，或者说基本用例定义一个模块框架，扩展用例可以向其中添加行为(有点像继承关系中父类和子类的关系)。,图9.7用例之间的扩展关系,例如，在电话系统中，提供给用户的最基本的服务是打电话，可选的服务是：三方通话、来电显示，因此三方通话、来电显示都是打电话用例的扩展。注意：打电话用例本身是有完整意义的，不需要了解其扩展就可以理解其初始目的，因此扩展用例是可选的。如果基本用例和扩展用例都必须显式地实例化，或者想让扩展用例修改基本用例的行为，则应该使用泛化(generalization)关系。,扩展用例可以包含多个插入片断，每个片段都是一个可选路径。这些插入片段增量式地修改基本用例的行为。一个扩展用例的每个插入片段插入到基本用例中的不同位置。这意味着扩展关系有一个扩展点列表，扩展点数等于扩展用例中插入片断的个数。每个扩展点都必须定义在基本用例中。一个基本用例可以包括多个扩展关系，这意味着一个用例实现可以跟随多个扩展点，一个扩展用例可以扩展几个基本用例，但这并不暗指这些基本用例之间具有依赖关系。在同一个扩展用例和基本用例之间可以具有多个扩展关系，这意味着不同的扩展关系会被插入到不同的扩展点上。一个扩展用例本身也可能同时是扩展、包含、泛化的基本用例。,电话会议(多方通话)用例描述：基本流：1.呼叫方按下挂起按钮。2.系统产生3短声表示响应。第39步完全和基本用例的39步相同。这样，呼叫方又和接收方建立起连接。其中37步可以抽取出来作为一个包含用例：建立连接用例。三方通话用例扩展的关系图如图9.8所示。,图9.8电话会议用例扩展的基本通话用例,3泛化关系(generalization)泛化关系是一般和特殊、共性和个性、抽象和具体之间的关系。该关系具有普遍性，在UML中可以应用于参与者(Actor)、用例(UseCase)和类(Class)之间。泛化关系应用于用例时，具有一般性的用例称为父用例，具有特殊性的用例称为子用例。父用例可以被一个或多个子用例具体化。父用例一般定义成抽象的，子用例继承了父用例所有的结构、行为和关系。如果发现两个或者多个用例在目的、结构、行为有共性时，就可以使用泛化关系来设计用例之间的关系，也就是用例结构，将公共的部分定义成抽象的父用例，然后由子用例具体化。例如：银行挂失可以分成电话挂失、网上挂失、柜台挂失、短信挂失等，其目的、结构、行为相似，但每种用例的实现细节有所不同，因此可以提取父用例“银行挂失”，如图9.9所示。,图9.9用例之间的泛化关系,银行挂失是一个一般性业务用语，对一般性的银行挂失，应该有着一般性挂失描述。但对于电话和网上挂失，应该在一般性的挂失基础上增加新的特性、行为，也可以修改其行为。又如教师上课用例也可以分为：传统课堂授课、电视授课和网络授课。,如果父用例是抽象的，其行为中有些部分是不完整的，子用例必须完成这些不完整的部分。抽象用例不需要和参与者关联。如果两个用例继承同一个父用例，则其执行两个完全不同的用例实例，这与扩展或者包含关系不一样，后者执行的是同一个基本用例(正像类的继承和关联关系之间的区别一样)。用例泛化和包含关系都用来复用用例的行为，其中的区别在于：在泛化关系中，子用例依赖于父用例的结构和行为；在包含关系中，基本用例只依赖于被包含用例的执行结果。另一个区别在于，泛化关系共享目的和结构，而包含关系中，基本用例和被包含用例具有完全不同的目的。,一般来说，不需要描述泛化关系本身。在描述子用例的事件流中，需要说明插入到继承行为中的新步骤(扩展)，或者对继承行为的修改(覆盖)。如果子用例继承多个父用例，则必须说明父用例的行为序列在子用例中的继承顺序。例如打本地电话用例的事件流如表9.4所示；打长途电话的事件流如表9.5所示。,打长途电话用例继承了打本地电话用例，13步都是继承自父用例，第4步对父用例进行了修改，如图9.10所示。,图9.10打电话用例的继承关系,需要注意的是，用例的上述三种关系(包含、扩展、泛化)都只是表示用例之间的结构关系，并非通信关系或者控制关系。在描述用例关系时容易犯的错误是在用例之间使用关联关系来作为用例之间的通信关系，就像数据流一样，表示数据从一个用例传向另一个用例。虽然从概念上来看，这样做也是有道理的，但是用例强调的是某个功能的执行或者实现过程，用例图强调系统功能和系统之外有关因素之间的关系，而非用例之间的数据传送。例如图9.11中的用例图就是不合适的，把用例图画成了数据流图。在UML中，不同的功能或者活动之间如果有数据传递，可以使用活动图(Activity)来表示。可能有人会说，在一张图中表示了更多的信息有什么不好？如果在一张图中表示了过多的信息，则图就会失去其固有的直观性，喧宾夺主，淡化了该图要表示的主要目的和目标。这里需要记住UML建模中的一条原则：每种模型只建模一种特性，不要在一种模型中建模多种特性，这和本书前面指出的在画数据流图时，在一张图中不要画过多的处理的道理是一样的。,图9.11不合适的用例图,9.4用例图和用例模型9.4.1参与者与用例之间的关联1.关联(Association)关系关联(Association)关系表示两个元素之间的联系，提供了被连接的两个元素之间通信的路径，是两个具体对象实例的具体关系的模板，相当于关系类型。按照通信的方向，关联分为单向和双向两种。关联关系可以存在于参与者、用例、类、接口之间。关联关系是元素之间最一般的关系，因此语义是最弱的。只要两个元素之间存在着某种语义上的联系，则其关系就是关联关系。关联关系使用实线(双向)或者实线箭头(单向)表示，如图9.12所示。,图9.12学生启动注册用例,两个元素之间可以存在着多种关联关系，每种关联关系都具有不同的语义。比如用户和用例之间既有通信和交互的关系，也有启动的关系。前者是双向的，后者是单向的。在对元素之间的关系建模时，不一定要把所有的关系都建模出来，而是建模最关键的关系，即所谓的系统关键元素(SystemSignificantElement)。图9.13中就建模了参与者学生和注册用例之间的启动关系，学生总是该用例执行过程中的主动者，因此该关系是单向的，由学生指向用例。又比如该用例执行完毕后会对另外一个参与者(教师)产生影响，教师可以看到谁注册了自己的课程，这种关系也是单向的通信关系。虽然教师在查询该信息时是双向的操作，但那是在另外一个用例(查询注册信息用例)中做的事情。对学生注册用例来说，其对教师的影响就是单方向的，因为教师不可能代替学生去注册课程，或者控制学生注册课程。如果有一个学生委托教师替代其注册，则此时教师的身份就相当于学生，或者专门给系统增加一个用例替学生注册，但这都是不必要的。,图9.13参与者与用例之间的通信关系,2参与者与用例之间的关系Actor至少应该和一个用例之间有关联关系。该关联关系可能是启动、通信、交互、影响等。Actor和用例之间的关系是系统之外因素和系统内部功能之间的关系，是定义系统边界的直观简单的方法。图9.14表示了入库是系统的功能，而财务系统是系统之外的元素。,图9.14参与者与用例的关系是系统的边界,9.4.2用例图包括参与者、用例及其关系的图叫做用例图。一个系统会有多个用例，用例图可以形象直观地描述整个系统的关键用例及其关系，也可以描述某个功能的相关参与者和用例的关系，用例图一般放在特定的包下面，如UseCaseModel包下面。用例图形象直观地描述了系统功能的静态结构和系统边界，即系统做什么、不做什么。参与者、用例及其用例图是抽象或者定义系统功能的一个良好开端，也是一种比较容易掌握的功能需求分析方法。,用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求。包括基于基本流程的“角色”(actors，也就是与系统交互的其他实体)关系，以及系统内用例之间的关系。用例图一般表示用例的组织关系，它既可以囊括整个系统的全部用例，也可以只是完成具有某种或某类功能(如所有的销售管理)的一组用例。图9.15描述了网上选课系统的关键用例。,图9.15网上选课系统关键用例图,用例图中没有严格的规定必须表现什么，主要是有关参与者和用例。可以单独表现参与者及其关系，也可以单独表现用例及其关系，还可以按照各种分组规则如业务组或者功能组等表现参与者和用例之间的关系。具体地，在用例图中一般可以表示如下情况。(1)表示属于同一个用例包下的所有参与者。(2)表示属于同一个用例包下的所有用例。(3)表示和一个参与者交互的所有用例。(4)表示和同一组参与者交互的所有用例。,(5)描述系统关键用例，该种类型的图可以作为模型的概要，一般被包括在UseCaseView包下。(6)经常在同一个动作序列中执行的多个用例(类似于流程图)，如采购过程中的多个用例。(7)在同一次迭代周期中一起开发的用例。需要注意的是，每个参与者和用例及其关系至少应该在一个图中出现，如果能够使模型清楚，在同一个图中也可以出现多次。,9.4.3用例模型用例模型描述了系统预期的功能及其环境，它是客户和开发者之间的契约，是需求分析的任务之一，也是后期开发，如分析、设计和测试的基础。用例模型也是系统体系结构的要素之一，是从用户或者用例的角度观察系统得到的模型，体现了系统的关键功能。用例模型中包含用例包、用例、参与者及其关系。其中用例包建模了系统功能的分类和层次结构；用例及其说明描述了系统的功能及为完成该功能，外部参与者和系统之间的交互过程；参与者描述了和该系统功能有关的外部因素(一般是和系统交互的用户等)；参与者和用例之间的关系描述了参与者与用例的控制、通信、交互等关系。在用例模型中一般还包括用例图。,可以从各种角度对系统建模，每种模型都有其目的，体现了某方面相关人员的观点。用例模型是从用户的角度对系统的外部特性进行建模的结果，即UseCaseViewModel。建立用例模型的主要目的是针对系统的行为或者外部特性与用户或客户进行交流。因此用例模型必须是容易理解的。它界定了系统的边界，定义了系统要做什么、不做什么。在建立用例模型的过程中，用户及其相关的其他系统都是系统的参与者。用例模型是在充分体现参与者需求的基础上开发的，它能够保证所开发的系统的功能确实是用户所需要的功能。,9.5用例规格说明9.5.1概述如果仅仅使用用例图来表示系统的功能，还是远远不够的，因为此时只是刻画出了系统功能和外界因素之间的关系，用例的细节还有待更进一步描述。由于用例是使用者观察到的系统功能，因此可以从用例的执行过程来进一步地刻画它们。前面提取的用例只是高层次的功能，属于概念层次，而对其更详细的描述则属于具体细节描述。,有些资料上把用例模型看成是静态模型，有些书上将其看成是动态模型，其实都是有道理的，任何事物都可以从静态(如组成)和动态(如过程)两方面进行描述。只要是从使用者的角度来看待系统功能，都可以认为是用例观点。比如描述系统有哪些功能、功能之间的关系、系统和外界因素之间的关系都可以看成是用例模型静态的一方面，即功能组成及其关系。用例观点的另一方面是功能的使用过程，这是从动态的角度来看待系统功能，是对系统的某个功能进行更详细的描述。在后面的章节中，对系统内部结构进行描述的时候也是通过静态(如类结构)和动态(如对象交互)两方面进行描述的，甚至程序代码的结构也分为静态和动态两方面。,9.5.2用例的描述模板根据用例的定义，对用例的描述应该是规范的。用例描述的模板之一如表9.6所示。,不同的资料上针对用例描述模板的介绍可能略有不同。例如，有些增加了用例的唯一标识符、输入数据、输出数据、处理说明，等等。具体描述哪些要点取决于问题类型及开发过程的价值观。需要注意的是，无论描述哪些要点都要从系统外部描述，不要涉及系统内部实现。另外描述要模板化，这样易于发现规律，找出功能的外部操作之间的联系，也易于使非结构化的数据逐步结构化，从而提高开发效率。,下面以教学管理系统中“查询成绩”用例为例说明用例的描述方法。用例名称：查询学生成绩。用例描述：学生查询本学期所有课程的成绩。目的：学生通过该用例查看已完成课程的成绩单。参与者：学生、教师。前提条件：学生登录、成绩已登录完毕。事件流：开始：学生在主菜单中选择“查看成绩单”。,基本事件流：1.系统获取该学生上学期所有课程的成绩，整理并显示成绩。2.学生查看完毕，选择“关闭”。可选事件流：得不到成绩信息，显示信息，学生确认后，该用例结束。结果状态：无。其他扩展：打印学生成绩单。特殊需求：无。,9.5.3通过用例描述来获取系统的功能用例法是发现系统功能需求，尤其是用户和系统交互中的需求以及系统和系统之外元素之间关系的理想方法。参与者和系统交互的过程是直观的，比较容易理解和把握，所以用它来提取和发现、界定系统的需求。使用用户和系统交互的过程去发现或者确定系统的关键工作流和数据项也是用例思想的主要目的。下面以老师为答辩学生评分用例的描述为例，来说明这种功能分析过程。,用例名称：毕业答辩评分。目的：通过该用例的执行，教师完成给毕业设计学生的答辩情况评分。参与者：教师。前提条件(前提用例)：学生基本信息维护、答辩顺序表维护、答辩信息维护(包括论文题目、摘要、ppt、论文正文等信息)，相关信息都已经存放在系统中。交互活动流(可以使用文字、表格、活动图、顺序图来描述)：,正常工作流：1教师选择答辩评分，系统显示所有参与答辩人员的目录(姓名、论文题目、指导教师等)。2教师选择某位学生，系统显示该学生详细信息。3教师点击答辩，系统显示评分界面。4教师点击开始，系统开始计时。5可选，计时暂停/开始/结束。6教师输入各项评分及提问。7教师按下计时结束，系统显示答辩时间，可编辑。8教师点击答辩结束，系统显示该学生答辩分数。9教师点击返回则返回到毕业答辩目录页面。教师可以选择下一位学生，重复15项。,可选工作流：5-1教师点击系统计时暂停，开始。7-1教师输入调整后的时间。后置条件：该用例正常结束后，系统记录该学生的答辩分数。用例扩展：查看ppt、查看论文、修改某个学生的评分。其他：无。,9.5.4用例的描述方法及举例1文本描述方法以学生选课系统在网上选课用例为例。用例名称：选学课程。参与者：学生。用例目的：通过该用例的执行，学生可以注册14门课程进行学习。前提条件：登录。,基本工作流：1学生选择注册课程。2系统分类显示课程列表。3学生浏览课程列表。4扩展点查看课程详细介绍。5将课程加入选课单中，重复35步。6学生结束选课。7系统将选课单中的课程注册。8系统显示目前学生所选课程。,可选工作流：7-1系统注册课程出现课程冲突。8-1系统显示冲突课程名称和选择成功课程，提示用户重新选择。后置条件：系统记录学生成功注册的课程。其他：无。扩展用例：查看课程明细。,2事件流的活动图表现方法活动图类似于流程图，但有所扩充，可以表示并发流程。带有泳道的活动图可以表现出系统中不同角色的行为分配。活动图中比较适合于表现分支和并行活动，例如学生答辩、教师评分、教师提问等。教师评分用例的事件流的活动图如图9.16所示。这种方法的主要缺点是需要专用的工具，可能会将事件流绘制得非常复杂。,图9.16用活动图表示的用户交互事件流,3事件流的顺序图表现方法。顺序图的特点在于描述对象之间的交互，强调顺序性，但其不适合于描述复杂的流程和并发操作。UML2.0在顺序图中引入了分支和循环的机制，增强了顺序图的表现能力。在参与者与系统交互的工作流描述的顺序图中，只需要设定两个对象，即用户和系统，用ObjectMessage()代表用户向系统发送的消息，ReturnMessage()代表系统向用户响应的信息，自反消息()表示系统做的不需要向用户反馈的处理或者操作。用顺序图表示的教师评分用例的正常工作流如图9.17所示。其缺点是需要专门的工具，也可能会绘制得非常复杂，不适合于表示分支和并发等。,图9.17用顺序图表示的用户交互事件流,4事件流的表格表现方法事件流的表格表现方法见表9.7。这种方法兼具直观和简单两种特点，不需要任何专用的工具，但不适合于描述复杂的交互流程，也不适合于描述分支和并发。,9.6用例描述中常见的错误举例1.只描述用例目的，不描述用例的过程例如，“选修课程”用例的描述为：该用例实现了学生选修课程的功能，在该功能中学生可以查询目前开设课程的信息、任课教师信息等，学生可以选择46门课程。存在的问题：没有描述学生与系统的交互过程。,2只描述参与者的行为例如，“选修课程”用例描述如下：(1)学生查询开设课程列表。(2)学生查询任课教师信息。(3)学生选中课程，加入选课单。(4)学生提交选课单。,3只描述系统的行为例如，“选修课程”用例描述如下：(1)系统显示主界面和课程列表。(2)系统验证学生选择课程的合法性。(3)系统提示选课完成。,4描述系统的内部行为例如，“选修课程”用例描述如下：(1)学生选择选课功能，系统显示课程列表页面(CourseDisplay.jsp)。(2)学生选择课程，点击加入选课表。(3)系统调用选课表类(ChooseCourse)的加入课程方法(addCourse()，将此课程加入到临时选课表中。(4)学生提交选课结果，系统调用选课管理类(ChooseCourseManager)的校验方法Verifty()来确定选课的合法性(如该课程人数是否已满、该学生所选课程已满等)。如果没有问题，则显示选课完成；如果有问题，则提示问题类型。,5过分细致的描述以“学生注册”用例为例，描述学生注册时和系统的交互过程如下：(1)学生点击注册按钮，启动注册用例。(2)系统弹出注册页面。(3)学生输入学号、昵称、真实姓名、性别、出生年月日、联系方式、电话、地址、籍贯、专业、班级、爱好(4)系统验证用户信息是否有误，如果没有错误则提交信息到数据库，并显示注册成功。(5)如果有错误，回到(2)，并显示错误信息。,6功能分解层次太深以“维护教授基本信息”用例为例，其目的是对教授的基本资料进行维护。(1)管理员选择维护教授信息。(2)系统显示所有教授基本资料列表。(3)选择添加教授信息。(4)系统弹出新增教授对话框。(5)输入新增教授的名字、部门、专业等。(6)点击保存。(7)系统校验数据内容，提交数据库，显示新增成功对话框。(8)用户关闭对话框，新增用户显示在教授基本资料列表中。(9)选择某教授。(10)点击删除按钮。,该描述存在的问题是维护教授信息用例应该是一个大粒度用例，可以有三种不同的处理方法。一是分解成更小的用例，例如新增教授信息用例、修改教授信息用例和删除教授信息用例。另一种方法就是增加可选工作流路径，例如将新增教授信息作为基本工作流，删除教授信息和修改教授信息作为可选工作流。第三种方法就是利用用例之间的泛化或者扩展关系来重用用例的行为和特性，例如，教授的增、删、查、改用例的开始工作流都是一样的，后面具体的维护操作有可能不同。此时让具体的增、删、改、查用例继承维护用例，来具体描述其操作的工作流，此时的维护用例可以看成是抽象用例(注：这种方法的后续实现也可能采用这种继承结构，由一个父维护类和几个子维护类实现，因此功能的结构有可能映射为程序的结构，这也是面向对象方法在用例模型中的应用)。也可以把增、删、改用例描述成教授信息查询的扩展用例。两种用例结构的实现关系图如图9.18和图9.19所示。,图9.18使用继承结构实现大粒度用例,图9.19使用扩展结构实现大粒度用例,7用例的数据流描述过多此处以采购系统中的询价用例为例来说明在描述用例的过程中，过分描述数据输入、输出的不妥。用例名称：报价管理。用例目的：根据请购单数据，向各个相关厂商咨询有关商品的价格信息，并输入到数据库中，产生报价单。输入：请购单、厂商信息。工作流：1.打开报价管理功能，显示未报价的请购单。2.选择一个请购单。3.输入询价厂商，产生询价单。4.打印或者发送询价单。输出：询价单。,这种描述存在的主要问题在于：如果在用例描述中过分强调数据输入和数据输出，则用例分析很容易变成基于IPO的描述方式。该种描述方式以描述系统处理为主，可能会导致忽视用户和系统的交互，或者陷入描述处理细节中。为避免此类问题，如果该用例需要有重要的数据输入，可以作为前提条件处理；如果有重要结果，可以作为后置条件对待。对上述用例描述修改如下：前提条件：未询价的请购单、厂商资料。工作流：(和上面一样)。后置条件：产生询价单。,用例规格描述是文本文档，但又具有一定的结构和要求，否则会变得不规范或有歧义。这种文档称为半结构化文档。为了能够保证系统分析人员写出合格而高效的用例规格说明文档，可以应用XML技术定义用例规格，并将描述文档的文件类型定义为DTD或者XSD文档，然后在专用的编辑工具中就可以按照事先定义好的文档结构进行描述了。如果描述不到位或者出错，编辑工具会自动给出错误，就像在集成开发环境中写程序一样。这样就可以保证这种具有一定结构要求的文档形式的正确性和规范性。这样描述出来的文档还容易用来进行后继工作的自动化处理，如产生测试用例文档，等等。目前这种可以检查文档类型的编辑工具有很多，如Eclipse、XMLSpy等。,9.7使用用例方法发现和确定系统功能需求9.7.1通过Actor来发现用例用例模型抽象了系统的功能需求。一个复杂的系统具有大量的功能需求，如何确定并细化这些需求是需求分析阶段的一项重要任务。用户是最终系统功能的使用者，他们关心的是系统的最终功能，每个用户可能关心系统不同的功能或者说不同的侧面，所有用户对系统的功能认知情况组成了该系统的功能全息图。因此从他们的角度来描述系统，或者