第三讲用例图

,*,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第,3,章 用例图,目录,3.1,需求技术,3.2 RUP,开发过程,3.3,用例图的概念,3.4,用例图的表示,3.5,参与者之间的关系,目录,3.6,用例之间的关系,3.7,参与者与用例之间的关系,3.8,阅读用例图,3.9,用例图应用,3.10,建模要点,第,3,章 用例图,用例图是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。,3.1,需求技术,获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中，,RUP,过程中的用例技术、,XP,中的用户故事（,User Story,）技术、,FDD,的,Feature,描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来描述系统，定义系统三种需求技术的特点见表,3-1,所示。,需求技术种类,描述,用例,(Use case),描绘一个系统外在可见的需求情况，是代表系统中各个项目,相关人员,(,风险承担人，,Stakeholder),之间就系统的行为所达,成的契约,用户故事,(user story),由客户参与编写，说明他们需要系统为他们做什么，一般用,客户的术语编写，其长度约为三句话左右,需求特性,(Feature),就是一个小的，具有客户价值的功能，通常表示为,表,3-1 3,种获取需求的技术,3.2 RUP,开发过程,RUP,开发过程是“用例驱动”的开发过程，在,RUP,开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成,用例模型,；然后对需求模型进行分析,、,整理,、验证，建立分析模型；,最后,以,分析模型,为基础，设计系统，,来满足这些用例模型的要求。因此，软件的整个开发过程，就是建立模型的过程，从建立用例模型开始，其次是分析模型，接着是,设计模型,和,实现模型,，在建立了这些模型之后，还将根据用例模型设计出测试模型来对系统进行验证。,所有模型的建立过程不是线性转变的，而是是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代,、修改、删除、优化、,精化的过程。,下面是对,5,个模型的定义：,1.,用例模型：能够有效地帮助开发人员发现真正的功能需求，并用,UML,设计语言来描述需求，如，用例图。,3.2 RUP,开发过程,2.,分析模型：通过,协作图,来描述用例，检验,、验证用例的一致性、正确性、完备性、可行性。,分析的结果表示为,类图、包图,。,3.,设计模型：在分析模型的基础上，把分析阶段的类分解为语言能实现的软件类，利用各种实现技术构造系统,、子系统；,并把设计类进行分组，打包、定义子系统和类的接口。这一阶段的产品有：,（类图、对象图、包图、构件图）,4.,部署模型：定义可计算节点系统的物理结构，并验证运行在这些节点上的构件想法是否实现了用例。,（构件图、部署图）,5.,测试模型：根据用例中所描述的功能来构建,测试模型,。,采用用例技术的优点有,2,点：一是，用例表达了用户对软件的目标要求，用例是系统向其用户提供的增值功能。二是，用例很直观，用户和客户根本无法了解复杂符号，而用例这种简单、自然的表述法可以使其易于阅读，并提出修改意见。,3.3,用例图的概念,1.,用例图,用例图是描述用例,、,参与者及其关系的图。与所有,UML,的其它图一样，用例图可以包括注释,、约束。图,3-1,是棋牌管理系统对应的用例图。,图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。 方框内是,棋牌管理系统的多个用例，方框外是外部参与者。,图,3-1,棋牌管理系统的用例图,3.3,用例图的概念,2.,用例图的作用,用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。,用例图主要用来描述用户的,功能需求,。,UML,侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术。,3.,用例图的组成元素,用例图的组成元素包括用例,、参与者、关系,(,用例间的关系，参与者之间的关系，参与者与用例之间的关系,),。,3.4,用例图的表示,多个用例,组成一个系统，,参与者是系统外部的一个实体,，它以某种方式与系统交互，请求系统执行用例，以获得,参与者,需要的价值。,在用例图中,最为核心,的两个元素是,参与者（,Actor,）,和用例,（,Use Case,）,。,3.4.1,参与者的表示,参与者是为了完成某个任务，而与系统进行交互的实体。参与者是用户相对系统而言所扮演的角色。,1.,参与者的表示,参与者有两种表示方法，如图,3-2,所示。,图,3-2,参与者的两种表示法,3.4.1,参与者的表示,2.,参与者分类,参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。对参与者有两种分类方法：一种是按参与者本身的性质分，一种是按参与者的重要性来分。,（,1,） 按参与者性质分,1,）其它系统：当系统需要与其它系统交互时，如,ATM,柜员机系统中，银行后台系统就是一个参与者；,2,）硬件设备：如果系统需要与硬件设备交互时，如在开发,IC,卡门禁系统时，,IC,卡读写器就是一个参与者；,3,）时钟：当系统需要定时触发时，时钟就是参与者,3.4.1,参与者的表示,（,2,）按参与者重要性分：,与某个用例交互的参与者可能有多个，按参与者对用例的重要性分为以下两类：,1,）主要参与者：从系统获得可度量价值的用户，他的需求驱动了用例所表示的行为或功能。,2,）次要参与者：在系统中提供服务，并且不能脱离主要参与者而存在。,3.4.2,用例的表示,用例是对一组场景共同特征的抽象，即，用例是对一组场景共同行为的抽象，场景就是用例的一次完整的,、,具体的执行过程。用例与场景的关系，如同类与对象的关系，用例应该给参与者带来可见的价值。,.,场景,在系统中，按照某个顺序执行的一系列相关的动作后，实现了某种功能，把完成了这一功能的操作的集合称为场景。 “场景”就是用户使用系统的一个实际的、特定的场面 。,下面列举一个场景例子。,开发者与用户,、,客户进行交流，构建场景和用例规格描述。一个场景就是描述用户与系统之间的一系列交互活动，描述了系统一次具体执行的行为路径，即，一次完整的事件流。如，小刘通过银行柜圆机,(ATM,系统,),取款,3000,元的场景，如图,3-3,所示。,3.4.2,用例的表示,场景名称 取款,3000,元,参与者 客户小刘,事件流,（,1,） 小刘将银行卡插入柜员机。,（,2,）,柜员,机要求客户输入卡密码。,（,3,）小刘输入卡密码，并确认密码。,（,4,）,柜员,机屏幕提示，请客户选择服务类型。,（,5,）小刘选择取款服务。,（,3,）,柜员,机提示：请客户输入取款数目。,（,7,）客户输入,3000,，并确认。,（,8,）,柜员,机出钱口输出,30,张一佰元的人民币。,（,9,）小刘取回,30,张,100,元面额的人民币。,（,10,）,柜员,机提示服务类型：确认、或继续，或退卡。,（,11,）小刘选择服务类型退卡，结束服务。,图,3-3,小刘取款场景,3.4.2,用例的表示,开发者获取需求的步骤是：第一步，开发者首先将用户的工作流程表示为场景，然后，将同一类场景抽象为用例，以描述系统的功能；第二步，客户和用户通过审查场景，并测试开发者提供的原型系统，以验证和确认需求规格说明书。第三步，当系统需求定义成熟和稳定后，开发者和客户共同对需求规格说明进行确认，包括，系统的功能性需求、非功能需求、用例和场景在内的需求确认。,事件流：用例执行时动作的有序集合称为事件流。,3.4.2,用例的表示,2,用例的表示,每个用例都有一个名字，即，用例的名称，用例的名称有两种表示方法：,简单名：没有标识用例所属的包。,路径名：在用例名前标识了用例所属的包。,图,3-,用例的名称表示,3.5.1,识别 参与者,需求获取的第一步是，标识参与者。这一服务定义了系统的边界，并从开发者要考虑的系统中，找出所有的观察点。开发者通过回答下面问题来寻找参与者：,系统支持哪些用户组完成他们的工作？,哪一个用户组执行系统的主要功能？,次要功能由哪一个用户组完成，比如维护或管理？,与该系统进行交互的外部硬件和软件系统是哪些？,在确定具体参与者时，可以通过以下一些常见的问题来帮助分析：谁使用这个系统、谁安装这个系统、谁启动这个系统、谁维护这个系统、谁关闭这个系统、哪些其他的系统使用这个系统、谁从这个系统获取信息、谁为这个系统提供信息。是否有事情自动在预计的时间发生（说明有定时器）、系统是否需要与外部实体交互以帮助自己完成任务。,一旦参与者被标识出来后，需求获取的下一步活动是，决定每一个参与者将访问的功能。,3.5.2,参与者之间的,泛化,关系,参与者之间的关系一般表现为特殊,/,一般化关系，即，泛化关系。泛化关系的表示如图,3-5,所示。,图,3-5,参与者是泛化关系,3.5.2,参与者之间的,泛化,关系,对于参与者而言，泛化关系的引用可以有效地降低模型的复杂度。例如：在图,3,1,所示的用例图中，我们希望引入一个“迎宾员”的角色，并且为了缓解总台服务员的压力，希望让迎宾员也能完成“安排座位”的职责，那么就可以通过泛化来更有效地组织这个用例图。,图,3,3,表述了：总台服务员是一种“特殊”地迎宾员，它不仅可以安排座位，还能够办理结帐。,图,3-3,参与者泛化,3.3,用例之间的关系,3.3.1,识别用例,在需求分析时，当标识出了参与者以后，下一步就是识别用例，寻找用例最好的方法是，从参与者的角度看，参与者是如何使用系统的，通过回答以下问题，可以识别用例：,每个参与者希望系统提供什么功能？,系统是否存储和检索信息？如果是，由哪个参与者触发？,系统改变状态时，是否通知参与者？,哪些外部事件触发系统？,哪个参与者发出事件？,通过回答以上问题，得到一个候选用例列表。,3.3.2,标识用例间的关系,下面以一个“棋牌馆管理系统”的局部用例模型为例，说明用例之间的三种关系：包含关系,、,扩展关系,、,泛化关系,该系统的主要功能是：以,Internet,的形式向客户提供座位预订服务，如果暂时无法获取座位信息时，允许客户进入“等候队列“，当有人退订之后将及时通知客户。另外，该系统还将为总台服务员提供座位安排以及结帐的功能，要求能够支持现金和银行卡两种结帐方式。,在图,3-,中可以看到,4,种元素：参与者、用例、一个方框和一些表示关系的连接线。前面已经介绍了参与者和用例的表示法，不难知道该图中有客户、总台服务员和银联,POS,系统,3,个参与者，还包括预订座位、安排座位、办理结帐等,8,个用例。,3.3.2,标识用例间的关系,1.,系统边界,从图,3-1,中可以看到有一个方框，所有的用例都在这个方框内，而且它还有个名字：棋牌馆管理系统。在,UML,表示法中，这个方框称为,”,系统边界,”,，也叫做,“,系统范围,”，,他用来定义系统的界限，系统的用例都置于其中，参与者则置于边界之外。通过这个系统边界可以很清晰地标识出了系统的范围。,例如，图,3-1,中也明确地指出了该系统在处理银行卡结帐时将通过系统外的,“,银联,POS,系统,”,来完成，该系统是位于,“,棋牌馆管理系统,”,外的。因此,，“,银联,POS,系统,”,也是参与者,。,3.3.2,标识用例间的关系,包含关系,在,UML,中，包含关系用构造型,include,表示，它是指基用例（,base use case,）在它内部的某一个位置上显式地合并了另一个用例的行为。,(1),包含用例的表示,包含是指一个用例被另一个用例使用，被使用的用例就是包含用例，使用包含用例的是基用例。,图,3-7,说明：查询,、提款、转帐三个是基用例，它们都包含打印回执用例基用例执行时必须执行包含用例，否则，基用例是不完整的，,包含用例不是孤立存在的，它仅作为基用例的一部分出现,图中，包含关系的箭头是从基用例指向包含用例,只有当某个事件流片断在多个用例中出现时，才将这个事件流片段抽取出来，放在一个单独的用例中，把这个用例用作包含用例。,3.3.2,标识用例间的关系,图,3-7,包含用例,3.3.2,标识用例间的关系,(2),基用例与包含用例事件流,例如在图,3-1,中，用例预定座位就包含了用例检查座位信息。可以设想，当客户预定座位时，必须知道座位的信息（是否有座位、有哪些空座位等），因此这两个用例的事件流执行顺序如图,3-8,所示。,图,3-8,两个用例的事件流执行顺序,3.3.2,标识用例间的关系,3.,扩展关系,(1),扩展用例的表示,在,UML,中，扩展关系用构造型,extend,表示（箭头方向是从扩展用例指向基用例），它表示基用例在在某个条件成立时，合并执行扩展用例。基用例独立于扩展用例而存在，只是在特定的条件下，它的行为可以被另一个用例,(,扩展,),所扩展。,例如对于电话业务，可以在基本通话,(Call),业务上扩展出一些增值业务，如：呼叫等待,(Call Waiting),和呼叫转移,(Call Transfer),。我们可以用扩展关系将这些业务的用例模型，如图,3-9,所示。,3.3.2,标识用例间的关系,上图说明：用户打电话时，有可能进入呼叫等待，也有可能进入呼叫转移呼叫等待用例和呼叫转移用例都是打电话用例的扩展用例。,图,3-9,扩展用例,3.3.2,标识用例间的关系,(2),基用例与扩展用例的事件流,例如在图,3,中，用例处理等候队列就是对用例预定座位的一个扩展。当客户预定座位时，如果没有空座位或客户指定的座位时，客户就有两种选择：一是取消预定操作，二是进入等候队列中，等待系统通知；如果有客户想要地座位，就无需进入等候队列了，也就是说，用户预定座位时，并不是在每次都要执行处理等候队列用例。因此，这两个用例的事件流执行顺序如图,3-10,所示。,3.3.2,标识用例间的关系,图,3-10,两个用例的事件流执行顺序,也就是说，基用例可以独立于扩展用例存在地，只是在特定的条件下，它的行为可,以被扩展用例进行扩展,在实际建模中，我们把可选的行为封装为扩展用例，通过这种方式，可以把可选的行为从必须的行为中分离出来。,3.3.2,标识用例间的关系,4.,泛化关系,(1),泛化用例的表示,在,UML,中，用例的泛化关系和类图中的泛化关系是一样的。用例的泛化就是指父用例的行为被子用例继承或覆盖表示泛化关系，如图,3-11,。,图,3-11,泛化关系,3.3.2,标识用例间的关系,(2),父用例与子用例的事件流,用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例还可以出现在父用例出现地位置。例如，在图,3-1,中，用例收款只定义收款的一般过程，而处理现金结帐和处理银行卡结帐则是两个子用例，它们完成不同的情况下的收款工作。父用例和子用例之间的时间流如图,3-12,所示。,图,3-12,父用例和子用例之间的事件流,3.7,参与者与用例之间的关系,参与者用例之间是关联关系，表示了参与者与用例间的通信用一条实线箭头表示，由参与者指向用例如图,3-13,所示。,图,3-13,参与者与用例之间的关联关系,3.8,阅读用例图,通过对用例图的讲解，我们来理解图,3,表示的用例图的含义。这张用例图定义了三个基用例：预定座位、安排座位和处理结帐。,（,1,）客户通过,Internet,启动,“,预定座位,”,用例，在,“,预定座位,”,用例的执行过程中，将,“,检查座位信息,”,（包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例,“,处理等候队列,”,。,（,2,）在客户到棋牌馆时，总台服务员启动“安排座位”用例，在执行过程中，将启动包含用例“检查座位信息”。,（,3,）当客户要离开棋牌馆时，总台服务员将启动,“,处理结账,”,用例，并且定义了两种,“,收款,”,用例，一个是,“,处理现金结账,”,，另一个是,“,处理银行卡结账,”,，后一个用例将通过与外部系统,“,银联,POS,系统,”,交互完成。,3.8,阅读用例图,对用例的描述有两种方法：用例图和用例描述。用例图只能描述了系统的大概功能，是一种视图；用例描述才能表示系统活动的细节。用例描述又分为用例概述和用例详述,用例描述的是一个系统做什么（,what,）的信息，并不说明怎么做（,how,），怎么做是设计模型的事。,3.8.1,用例描述模板,为了说明一个用例的行为，描述一个用例的关键要素包括：用例何时开始（前置条件）、何时结束（后置条件）、参与者何时与用例交互、交互了什么信息，以及用例执行的基本事件流和扩展事件流。,1.,事件流,事件流就是用例执行时，由一序列活动组成的控制流。事件流分为基本事件流和扩展事件流两种下面是事件流模型，如图,3-14,所示。,3.8.1,用例描述模板,2.,用例描述模板,用例描述有两种格式：一种是纯文本格式，另一种是表格形式，表,3-2,所示就是一个经典的表格式用例描述模板，其中加粗显示的是必须编写的部分。,后置条件,前置条件,基本事件流,扩展事件流,图,3-14,事件流模型,3.8.1,用例描述模板,用例编号,为用例制定一个唯一的编号，通常格式为,UCxx,用例名称,应为一个动词短语，让读者一目了然地知道用例的目标,用例概述,用例的目标，一个概要性的描述,范围,用例的设计范围,主参与者,该用例的主,Actor,，在此列出名称，并简要的描述它,次要参与者,该用例的次要,Actor,，在此列出名称，并简要的描述它,项目相关人,利益说明,项目相关人,利益,项目相关人员名称,从该用例获取的利益,前置条件,即启动该用例所应该满足的条件。,后置条件,即该用例完成之后，将执行什么动作。,成功保证,描述当前目标完成后，环境变化情况。,基本事件流,步骤,活动,1,在这里写出触发事件到目标完成以及清除的步骤。,2,(,其中可以包含子事件流，以子事件流编号来表示,),扩展事件流,1a,1a,表示是对,1,的扩展，其中应说明条件和活动,1b,(,其中可以包含子事件流，以子事件流编号来表示,),子事件流,对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。,规则与约束,对该用例实现时需要考虑的业务规则、非功能需求、设计约束等,表,3-2,用例描述模板,3.8.1,用例描述模板,1,）前置条件：指在用例启动时参与者（,actor,）与系统应置于什么状态，这个状态应该是系统能检测到的、可观测的。,2),后置条件：用例结束时系统应置于什么状态，这个状态也应该是系统能检测到的、可观测的。,3,）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为,Happy day,场景，这是大部分事件所遇到的场景，它将体现系统的核心价值。,4,）扩展事件流：主要是对一些异常情况、选择分支进行描述。,3.8.2,用例描述举例,用例描述分两个步骤：第一步，对用例概要描述，第二步，对用例详细描述,下面就以用例,UC01“,新增书籍信息”为例，说明如何细化用例描述。,1.,用例概要描述,根据用例的事件流，搭建一个框架（在该例子中采用纯文本的描述方式）：,（,1,）用例名称：新增书籍信息（,UC01,）。,（,2,）简要说明：录入新购书籍信息，并自动存储建档。,（,3,）事件流：基本事件流,和,扩展事件流,（,4,）非功能需求,（,5,）前置条件：用户进入图书管理系统。,（,3,）后置条件：完成新书信息的存储建档。,（,7,） 扩展点：无,（,8,）优先级：最高（满意度,5,，不满意度,5,）,3.8.2,用例描述举例,在最初的迭代中，应该对每个用例都写出概要描述。概要描述阶段中，在填写各个部分的内容时，应分别注意以下几个要点：,用例名称：应该与用例图相符，并写上其相应的编号。,简要说明：对该用例对参与者所传递的价值结果进行描述，应该注意语言要简要，使用用户能够阅读的自然语言。,前置条件：是执行用例之前必须存在的系统状态，这部分内容如果现在不容易确定可以在后面再细化。,后置条件：用例执行完毕系统可能处于的一组状态，这部分内容如果现在不容易确定也可以在后面再细化。,扩展点：如果包含扩展用例或者包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。在本例中，用例图里没有相应的内容，因此可以直接写“无”；如果有，则应该在编写事件流的同时进行编写。,优先级：说明用户对该用例的期望值，可以为今后开发时制定先后顺序。可以采用满意度、不满意度指标进行说明，其中满意度的值为,0-5,，是指如果实现该功能，用户的满意程度；而不满意度的值为,0-5,，是指如果不实现该功能，用户的不满意程度。,3.8.2,用例描述举例,2.,详细描述,详细描述就是将事件流进行细化，在实际的开发工作中，要不要对一个用例进行细化、细化到什么程度主要根据项目的迭代的计划来决定。例如，对于本例而言，其细化的事件流描述如下所示,。,（,1,）基本事件流,图书管理员向系统发出,“,新增书籍信息,”,请求。,系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类。,图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号。,3.8.2,用例描述举例,图书管理员输入书籍的相关信息，包括：书名、作者、出版社、,ISBN,号、开本。页数、定价。是否有,CD-ROM,。,系统确认输入的信息中，书名没有重名。,系统将所输入的信息存储建档。,（,2,） 扩展事件流,如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入,图书管理员选择取消输入，则结束用例，不做存储建档工作。,图书管理员选择修改书名后，转到,5,对于功能需求，无特殊要求,3.8.2,用例描述举例,编写用例事件流时，为了使读者清晰地了解其所表达的含义，应该注意以下几点：,使用简单的语法：主语明确，语义易于理解。,明确写出“谁控制”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。,从俯视的角度来编写：指出参与者的动作以及系统的响应，也就是从第三者的观察的角来编写用例。,显示过程向前推移：也就是第一步都是有前进感的（例如，用户按下,Tab,键作为一个事件就是不合适的）。,3.8.2,用例描述举例,显示参与者的意图而非动作（如果只描述了动作，人们不能很容易地直接从事件流描述中理解用例）。,包括,“,合理的活动集,”,（带数据的请求、系统确认、更改内部、返回结果）。,用,“,确认,”,而非“检查是否”，例如,“,系统确认所输入的信息中书名没有重名,”,。,可选择地提及时间限制。,采用,“,用户让系统,A,与系统,B,交互,”,的习惯用语。,3.8.2,用例描述举例,采用,“,循环执行步骤,X,到,Y,，直到条件满足,”,的习惯用语。,另外，事件流的编写过程也是可以分阶段、迭代进行的，对于优先级高的用例花更多的时间，更细化；对优先级低的用例，可以先简略地将主要事件流描述清楚，其余的留到以后处理。另外，对于一些较为复杂的事件流，可以在用例描述中引用顺序图、状态图、协作图等手段。,3.,补缺漏,在将用例描述细化以后，要多与用户的沟通，对用例描述进行验证，然后不断地进行补缺漏，以保证用例描述完整、清晰、正确。,3.8.3,用例粒度,用例的粒度，就是用来描述用户目标的大小的程度。从大到小可将用例分成三个层次：概述级、用户目标级、子功能级。下面以读者阅读图书为例，说明用例的三个级别。,概述级,概述级,参与者把整个系统看成一个用例。如图,3-15,所示。,图,3-15,概述级,3.8.3,用例粒度,2.,用户目标级,目标级用例是对概述级进一步细化，如图,3-13,所示,3.,子功能级,子功能级用例是对目标级用例的进一步细化，如图,3-17,所示,图,3-13,用户目标级,图,3-17,子功能级,3.9.1,问题描述,当需求分析人员对用户和客户进行访谈后，就要记录下用户和客户对业务系统的描述。,开发人员必须把客户对业务系统的陈述转化为完整的，清晰的、可用于开发系统的描述，这种描述业务系统的格式，必须是客户能理解的、认可的标准格式。当然，“完整”和“清晰”实际上是做不到的。第一次是不可能非常接近这些目标的。但是，最终应有一个文档描述了系统应完成的所有工作（和系统不应完成的工作），而且没有误解。,例如，下面就是汽车租赁系统的业务陈述,(Nowhere Cars,任务陈述,),：,3.9.1,问题描述,商店将汽车的跟踪自动化了,使用条形码、柜台终端和激光阅读器，这有许多优点：租凭助手的效率提高了,20%,，汽车很少失踪，客户群很快变大（根据市场调查，其部分原因至少是专业化和效率的显著提高）。,管理层认为，,Internet,会提供进一步提高效率、降低成本的机会。例如，现在不是打印可用汽车的目录，而可以让每个,Internet,冲浪人员在线浏览这些目录。对于有特权的客户，可以提供额外的服务，例如通过鼠标点击进行预约。这个领域的目标是每个商店的运营成本降低,15%,。,在两年内，使用电子商务的所有功能，通过,Web,浏览器提供所有的服务，在客户中完成汽车的交付和收回，以达到虚拟租凭公司的最终目标，将未预约业务的运营成本降到最低。,3.9.1,问题描述,上面有,3,个段落的任务陈述包含了许多信息：公司的自动化历史；客户对日期的满意度；在线目录和预约；有特权和无特权的客户；节约成本的历史和目标；公司的最终目标（“虚拟租凭公司”）。当然，管理层的一些想法实现起来还有很长的路要走（客户适应虚拟租凭商店的时间可能会超过两年），但调查至少有两个很好的起点：公司的商店目前提供什么服务？哪些适合于在,Internet,上提供？,上述任务陈述是下面案例分析的基础。虚拟公司的新系统称为,Coot,，客户可使用的,Internet,功能集合称为,iCoot,.,3.9.1,问题描述,开发,Nowhere Cars,系统的优点是：在延长的期限内爱好者出租专用汽车。由于不可能出租所有型号的汽车，客户在要租汽车时，必须找到一家租凭货店。汽车的租凭方式是先到先得到服务，客户可以在当前可用的汽车中选择。另外，如果客户要租用的某型号汽车目前没有，还可以预约，当有匹配的型号汽车时，助手就会与客户直接签约；客户必须在两天内取车（或交抵押金，先于其他客户取车）。会员必须注册，才能电话预约。,3.9.2,定义术语表,每个业务领域都具有它本身独一无二的词汇，需求分析的目的就是理解和定义这些词汇。词汇应该被项目相关人所理解。术语表必须解决同音异义和同义异音问题。,一般来说，我们从问题描述中提取术语表。,下面是汽车租赁系统的术语表如表,3-3,所示。,3.9.2,定义术语表,术 语,定 义,Car,（业务对象）,由商店保存的、用于出租的,CarModel,（业务对象）,目录中的一个模型，可用于预约,Customer,（业务参与者，业务对象）,为获得一个标准服务而付费的人,Member,（业务对象）,其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过,Internet,预约）,表,3-3 Nowhere Cars,术语表,3.9.2,定义术语表,术语表中的每一项都定义了一个术语，其定义可短可长。,从案例分析的术语表中可以看出，可以记录每个术语与开发阶段之间的关系（业务参与者、系统参与者）。下面是可以使用的关系列表（每一项都可以用于多种关系）：,业务参与者：业务需求中出现的参与者,业务对象：业务需求中出现的参与者,系统对象：系统需求中出现（在系统内部）的对象,分析对象：分析模型中出现的对象,部署制品：在系统中部署的某个信息，例如文件,设计对象：设计模型中出现的对象,设计节点：构成系统体系结构的计算机或过程,设计层：子系统的垂直部分,设计包：把多个相关类组织在一起，用于组织开发。,收集需求的活动结束后，开发者建立了两个产品：第一个产品是对业务系统的问题描述；第二个产品是对业务系统中词汇的定义。,3.9.3,标识参与者,首先，需要标识业务参与者。参与者是在业务中扮演某个角色的人、部门或者独立的软件系统。一般来说，参与者使用系统或给系统提供服务。,与现实生活一样，参与者可以在不同的时刻，扮演不同的业务角色。例如，小刘在,Nowhere Cars,商店上班时，他是一个助手；如果他在回家之前要租用一辆汽车，就成为一个顾客。,3.9.4,标识系统用例,一旦有了参与者，就可以从参与者的角度看系统,问系统能给参与者提供哪些服务,?,通过一问一答,就可以查找用例。,iCoot,系统用例列表,:,U1,：浏览索引：顾客浏览汽车型号的索引。,U2,：查看结果：给顾客显示检索到的汽车型号子集。,U3,：查看汽车型号细节：给顾客显示检索到的汽车型号细节，例如描述和广告。,U4,：搜索：顾客指定类别、构造和引擎规格，搜索汽车型号。,U5,：登录：会员使用会员号和当前密码登录,iCoot,。,3.9.4,标识系统用例,U3,：查看会员信息：会员查看,iCoot,存储的会员信息子集，例如姓名、地址和信用卡调节。,U7,：进行预约：会员在查看汽车型号的细节时，预约一种汽车型号。,U8,：查看租用情况：会员查看当前租用的汽车的汇总信息。,U9,：修改密码：会员修改用于登录的密码。,U10,：查看预约情况：会员查看还没有结束的预约汇总信息，例如日期、时间和汽车型号。,U11,：取消预约：会员取消还没有结束的预约。,U12,：注销：会员从,iCoot,中注销。,系统用例可以在用例图上描述，显示参与者与特定用例的关系,这有助于了解系统的使用方式。,iCoot,的用例图如图,3-18,所示。,3.9.4,标识系统用例,图,3-18,iCoot,的一个简单的用例图,3.9.4,标识系统用例,在用例图中，每个用例都在一个椭圆中显示为一个序号和一个标题。包含所有用例的方框表示系统的边界,可以把系统名称放在方框中。在系统边界的外部，显示参与者，在用例和使用它们的参与者之间添加关联。,3.10,建模要点,构建结构良好的用例：,1,）为系统和部分系统中单个的、可标识和合理的原子行为命名；,2,）将公共的行为抽取出来，放到一个被包含用例中，再将它,include,进来；,3,）对于变化部分，将其抽取出来，放到一个扩展用例（用,extent,连接）中；,4,）清晰地描述事件流，使得读者能够轻而易举地理解,构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；,根据系统实际情况控制粒度,小结,本章详细地阐述了参与者和用例的概念 ，结合了一个“棋牌馆管理系统”的用例图，讲解了系统边界、包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及相关的要点。,