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