单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,下页,末页,上页,首页,目录,第9章 面向对象分析,*,9.2获取需求建立用例模型,获取需求,一用例图介绍,用例图的基本概念：,用例图（UseCaseDiagram）是由软件需求分析到最终实现的第一步，它描述人们希望如何使用一个系统。用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务，以便使系统的用户更容易地理解这些元素的用途，也便于软件开发人员最终实现这些元素。,1,9.2获取需求建立用例模型,获取需求,用例图主要包含4中元素，分别是：,参与者、用例、关联和系统边界,。用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组合成更大的模块。用例图模型如下图所示，参与者用人形图标表示，用例用椭圆形符号表示，连线表示它们之间的关系。,2,（1）参与者,参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由参与用例时所担当的角色来表示。参与者用名字写在下面的人形图标表示。,每个参与者可以参与一个或多个用例。参与者有三大类：,系统用户,与所建造的系统交互的其他系统,一些可以运行的进程。,3,参与者可以划分为发起参与者和参加参与者。发起参与者发起用例的执行过程，一个用例只有一个发起参与者，但可以有若干个参加参与者。,参与者还可以划分为主要参与者和次要参与者，主要参与者是执行系统主要功能的参与者，次要参与者是使用系统次要功能的参与者。通过主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。,4,寻找参与者可以从以下几个问题入手：,系统开发出来后，主要功能被谁使用？,谁需要借助系统来完成日常工作？,系统需要从哪里获得数据？,系统会为哪些人或其他系统提供数据？,系统会与那些系统交互？,系统由谁负责管理和维护？,谁对本系统的结果感兴趣？,5,（2）用例,用例是外部可见的系统功能单元，这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。,用例的定义包含它所必需的所有行为(执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期反应)。用例不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。在,UML,中，用例用一个椭圆来表示，用例的名字可以书写在椭圆的下方，如图所示。,6,识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。,在识别用例的过程中，通过回答以下的几个问题,特定参与者希望系统提供什么功能；,系统是否存储和检索信息，如果是，由哪个参与者触发；,当系统改变状态时，是否通知参与者；,是否存在影响系统的外部事件；,哪个参与者通知系统这些事件。,用例的粒度指的是用例所包含的,系统服务或功能单元的多少。,用例粒度示例,7,（3）用例之间的关系,关系是指用例图中参与者与用例，用例与用例之间的联系。,除用例与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。,应用这些关系的目的是为了从系统中抽取出公共行为及其变体。,关系,说明,记号,关联,执行者与他所参与的一个用例之间的通信路径,扩展,扩展的用例到基本用例的一种关系，它指出扩展的用例所定义的行为如何插入到基本用例所定义的行为中。扩展的用例通过模块化方式增量地修改基本用例,extend,8,关系,说明,记号,包含,从基本用例到另一个用例（称为包含用例）的一种关系，它指出包含用例定义的行为被包含在基本用例所定义的行为中。基本用例能看到包含用例，并依赖于执行包含用例后的结果，但两者相互间不能访问其它属性,用例泛化,一个一般用例与一个更特殊的用例之间的关系，特殊用例可继承一般用例的特征,include,关联关系示例,关联关系,9,包含,是指基本用例会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。,包含用例是可重用的用例多个用例的公共用例。,10,包含关系：,11,基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。,扩展用例的行为是否被执行要取决于主事件流中的判定点。,扩展是,将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。,12,扩展关系,：,13,泛化,：同一业务目的的不同技术实现。,当多个用例,共同拥有一种类似的结构和行为,的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。,14,（4）系统边界,系统边界是指系统之间的界限。通常所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。,系统同时又是相对的，一个系统本身可以使另一个更大系统的组成部分，因为系统与系统之间需要使用系统边界进行区分，把系统边界以外的同系统相关联的其他部分统称为系统环境。,15,9.2获取需求建立用例模型,获取需求,二、获取业务用例,（1）发现业务参与者,业务参与者是参与者的一个版型，专门用于定义业务相关的参与者。业务参与者在遵守参与者定义的同时，也有其自身的特点。业务参与者的特点在于，它针对的是业务人员而不是系统使用者。所以在查找业务参与者的时候，要抛开计算机的概念。业务参与者是实际业务工作的参与者，没有抽象的计算机角色。要确认参与者是否为业务参与者可从以下几个问题入手：,16,业务参与者的名称是否是客户的业务术语？,业务参与者的职责是否在客户的岗位手册中查到？,业务主角的业务用例是否为客户的业务术语？,客户是否可以对业务主角顺利理解？,学生选课系统的业务参与者：,17,（2）获取业务用例,业务用例是用例版型中的一种，它专门用于需求阶段的业务建模。业务建模是针对客户业务的模型。,业务用例面对的问题领域是客观存在的业务领域，没有将来的计算机系统的参与。相应的，它的参与者就是业务参与者。,18,获取方法：从用户相关的文档中获取(岗位手册、业务流程指南，职务说明)，或者涉众分析。,调查问卷：,现在的业务流程是什么？有什么问题？,对系统的期望是什么？,希望系统能够帮助做哪些工作？,做这件事的目的是什么？,希望有一个什么样的结果,19,学生选课系统业务用例,20,学生选课系统业务用例,21,（3）建立业务模型,在完成了业务用例分析后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。,活动图有个很重要的使命就是从业务用例分析出系统用例。,学生选课系统的活动图有：,22,活动图二：校领导查询,活动图一：教务处课程管理,23,活动图四：学生选课,活动图三：教师管理课程,24,9.2获取需求建立用例模型,四、需求分析,（1）建立系统用例,需求分析就是在业务用例图和相关的活动图的基础上，形成用例图和用例规约。,课程设置用例,课程情况查询用例,教师课程管理用例,学生选课管理用例,人员信息管理用例,账号管理用例。,学生选课系统的系统用例：,25,校领导系统用例,教务处课程管理员系统用例,26,学生系统用例,教师系统用例,27,系统管理员系统用例,人员信息管理员系统用例,28,9.2获取需求建立用例模型,四、需求分析,（2）建立用例规约,用例规约就是对用例的详细描述和说明，主要内容有：,简要说明：简要介绍该用例的作用和目的。,事件流：包括基本流和备选流，基本流描述的是用例的基本流程，是指用例“正常”运行时的场景；备选流描述的是用例执行过程中可能发生的异常或偶然情况。基本流和备选流综合起来能够覆盖一个用例所有可能发生的场景。,29,用例场景：同一个用例在实际执行的时候会有很多不同的情况发成，称之为用例场景。,用例场景就是用例的实例，包括成功场景和失败场景。在用例规约中，由基本流和备选流组合来对场景进行描述。,在描述用例的时候要注意覆盖所有的用例场景。此外场景还能帮助测试人员进行测试，帮助开发人员检查是否完成所有的需求。,30,特殊需求：描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。,前置条件：执行用例之前系统必须所处的状态，例如前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。,后置条件：用例执行完毕后系统可能处于的一组状态，例如要求在某个用例执行完成后，必须执行某一用例。,31,录入学生成绩用例说明,用例说明一般没有通用的格式，最大的要求就是“清晰易懂”,32,