UML用例图 开发软件产品的第一步是对产品进行需求分析。需求分析是指根据用户对 产品的功能需求,提取产品外部功能的描述。UML 中的用例图(UseCase Diagram)就是支持产品外部功能描述的视图。用例图是从软件产品使用者的 角度,而不是从开发者的角度描述用户对开发产品的需求,并分析产品所需的功 能及动态行为。 在用例图中,对用户需求的描述包括参与者(Actor)与用例(UseCase)两方 面,通过描述这两方面之间的关系,用例图完整地描述了用户需求。本章以一个 学生成绩管理系统为例,介绍用例图中的概念和术语———参与者、用例、脚本、关 系,以及在Rose建模环境下创建用例图的方法和步骤。 3.用例 1 用例是一个参与者使用系统的一项功能时进行交互过程的文字描述。例 如,在学生成绩管理系统中,可能会有以下用例。 .记录成绩。 .浏览成绩。 .分发成绩报告单。 .创建成绩报告单。 在UML 中,用例用一个椭圆形表示,用例的名称一般用动宾结构(英文命 名)或主谓结构命名(1是用例的示例。 中文命名)。图3. 图3.用例的示例 1 在进行需求分析时,用例具有以下主要特点。 19 第3章UML 用例图 .用例是从使用系统的角度描述系统中的信息。 .用例描述了用户提出的一些可见需求。 .用例是对系统行为的动态描述,属于动态建模。 .用例分析是一种功能分解技术,并未使用OO 的实现。 .用例是与实现无关的系统功能描述。 3.参与者 2 参与者是指系统以外、需要使用系统或与系统交互的对象,包括人、设备、外 部系统等。在UML 中,参与者既可以用人形图标表示,也可以用类图表示。用 人形图标表示的参与者是人,用类图标表示的参与者是外部系统。 一个参与者可以执行多个用例,一个用例也可以被多个参与者使用。注意: 参与者实际上并不是系统的一部分,尽管在模型中会使用参与者。例如,在一个 学生成绩管理系统中,可能会有以下参与者。 .教师———记录成绩、浏览成绩、发布成绩报告单。 .学生———浏览成绩。 .管理员———创建学生成绩报告单和浏览成绩。 图3.参与者与用例之间的连线表示两者 2是学生成绩管理系统的用例图 , 之间的关联关系 。 图3.学生成绩管理系统的用例图 2 20 UML应用开发教程———基于RationalRose、Java与MySQL实现 3.脚本 3 脚本(Scenario)也称情景、场景、情节、剧本等。UML中的脚本是指贯穿用 例执行过程的一条单一路径,用来显示用例中的某种特殊情况。脚本是用例的 实例,脚本与用例的关系相当于对象与类的关系。每个用例都有一系列的脚本, 包括一个主脚本以及多个次要脚本。对于主脚本来说,次要脚本描述了执行路 径中的异常或可选择的情况。在用例图中,如果没有对用例做具体说明,那么就 不清楚这个用例完成的功能。用例是一个“文字描述序列”,是“动作序列的说 明”。用例的描述才是用例的主要部分,是后续对交互图和类图进行分析的基 础。下面通过一个网上购物的示例说明用例的描述方法。 .UseCase:Something .Actor:Customer 主要事件的执行流程 : ①顾客使用ID和密码进入系统; ②系统验证顾客身份; ③顾客提供个人信息(包括姓名、送货地址、电话号码等),选择要购买的商 品和数量; ④系统验证顾客的会员等级; ⑤系统使用库存系统验证顾客购买的商品数量是否少于库存量; . 3.泛化关系 4 泛化(Generalization)代表一般与特殊的关系。在泛化关系中,子用例继承 了父用例的行为和含义。另一方面,子用例也可以增加新的行为和含义,或者覆 盖父用例中的行为和含义。图3. 3是表示泛化关系示例的用例图。 图3.泛化关系的示例 3 21 第3章UML 用例图 3.包含关系 包含(e)指一个用例(基本用例)的行为包含另一个用例(包含用例) 的行为。在包含关系中,箭头的方向是从基本用例到包含用例,即基本用例依赖 于包含用例。表示包含关系的用例图如图3. Includ 4所示。 图3.包含关系的示例 4 3.扩展关系 6 扩展(Extend)关系的基本含义与泛化关系类似,但对于扩展用例,有以下 规则进行限制。 .基本用例必须声明若干“扩展点”。 .扩展用例只能在这些扩展点上增加新的行为和含义。 .扩展关系中的箭头是从扩展用例到基本用例,即扩展用例依赖于基本 用例 。 图3. 5是表示扩展关系的用例图。 图3.扩展关系的示例 5 22 UML 应用开发教程———基于RationalRose、Java与MySQL 实现 3.三种关系的比较 7 .泛化和扩展表示的是用例之间的“sa” i的关系。 .扩展与泛化关系相比,多了扩展点的概念,即一个扩展用例只能在基本 用例的扩展点上进行扩展。 .包含关系表示的是用例之间的“hasa”的关系。 3.用例建模 8 用例建模是用于描述一个系统“应该做什么”的建模技术,因此用例建模不 仅可用于新系统的需求获取,还可以用于已有系统的升级。用例建模是通过开 发者和用户为导出需求分析而进行的交互过程建立的。 用例建模的主要元素有用例、参与者和系统。系统被看作一个提供用例的 黑盒子,系统如何做、用例如何实现、内部如何工作,这些对用例建模来说并不是 最重要的。系统的边界定义了系统的功能,而功能可用用例表示,每个用例均指 明了一个完整的功能。 创建用例的工作包括定义系统、寻找参与者和用例、描述用例、定义用例之 间的关系,最后确认用例模型。用例模型由用例图组成,用例图展示了参与者、 用例以及它们之间的关系,用例通常用正文描述。 3.1 确定参与者 8. 参与者是指与系统交互的人和其他系统。“与系统交互”是指参与者向系统 发送消息,或者从系统接收消息,或者与系统交换消息,即参与者执行用例。参 与者可以分为主参与者和副参与者。主参与者使用系统的主要功能,副参与者 处理系统的辅助功能。这两类参与者都要建模,以保证描述系统完整的功能特 征。参与者还可以分为主动参与者和被动参与者。主动参与者启动一个用例, 而被动参与者从不启动用例,只是参与一个或多个用例。可以通过以下问题确 定参与者。 .谁使用系统的主要功能(主参与者)? .谁需要从系统中得到对日常工作的支持? .谁需要维护、管理和维持系统的日常运行(副参与者)? .系统需要与其他哪些系统交互? .哪些人或哪些系统对系统产生的结果负责? 第3章UML 用例图 23 8.确定用例 3.2 一个用例表示被参与者感受到的一个完整功能。用例具有以下基本特征。 .用例总是被参与者启动。参与者必须直接或间接地指示系统执行用例。 .用例向参与者提供结果,这些结果必须是可识别的。 .用例是完整的,一个用例必须是一个完整的描述 。 可以通过让每个参与者回答下列问题寻找用例 。 .参与者需要系统提供哪些功能? 参与者需要做什么? .参与者是否需要读、创建、删除或存储系统中的某类信息? .参与者是否要被系统中的事件提醒,或者参与者是否要提醒系统中的某 些事情? 从功能观点来看,这些事件表示什么? .参与者的日常工作是否因为系统的新功能而被简化或提高了工作效率? 3.3 描述用例 8. 用例的描述用脚本完成,它是一份关于行为者与用例之间如何交互的简明 和一致的说明书。用例的描述着眼于系统的外部行为,而忽略系统的内部实现。 描述中应尽可能地使用用户的语言和术语。用例的描述一般包含以下内容。 .用例的目的———用例的最终目的是什么? .用例是如何启动的———哪一个参与者在什么情况下自动启动用例的 执行? .参与者与用例之间的消息流———用例和参与者之间交换什么消息或事 件以通知对方改变或恢复信息,并帮助对方做出决定? 描述系统与参与 者之间的主消息流是什么? 系统中哪些实体被使用或修改? .用例中可供选择的流———用例中的活动是否可以根据条件或异常有选 择地执行? .如何通过给参与者一个值结束用例———描述何时可以认为用例已经 结束。 3.4 用例图建模示例 8. 学生成绩管理系统的业务需求包括以下内容。 ①教师可以使用系统输入、更新学生成绩。 ②系统管理员根据教师提供的成绩创建学生成绩报告单。 ③教师需要通过系统分发学生成绩报告单。 ④系统允许教师与学生查询记录的成绩。 24 UML 应用开发教程———基于RationalRose、Java与MySQL 实现 根据上述业务需求,创建学生成绩管理系统的用例模型。 1. 确定参与者 根据上述需求描述的分析,可以确定系统的参与者为教师、学生和系统管 理员。 2. 确定用例 确定参与者使用的用例,可以通过提出“系统要做什么”这样的问题完成。 学生成绩管理系统的用例有输入成绩、查询成绩、更新成绩、创建学生成绩报告 单、检查学生成绩报告单的准确性、分发学生成绩报告单。 对于上述已经确定的用例,还要进一步明确它们之间的优先次序。对于学 生成绩管理系统来说,其用例的优先次序如下。 ①输入成绩。 ②查询成绩。 ③更新成绩。 ④创建学生成绩报告单。 ⑤检查学生成绩报告单的准确性。 ⑥分发学生成绩报告单。 3. 描述用例 .UseCase:InputGrades .参与者:Teacher 主要事件的执行流程 。 ①教师登录系统。 ②教师确定要记录哪些学生的成绩。 ③系统要保证学生的自然情况数据已经存储在数据库中。 ④教师选择要输入成绩的课程。 ⑤系统开始数据库的一项事务处理。 ⑥教师输入学生的成绩。 ⑦系统校对输入的成绩以确保其属于正确的值域。 ⑧系统保存本门课程的成绩。 ⑨系统结束事务的处理。 ⑩ 系统提示教师成绩保存完毕。 .UseCase:ViewGrades .参与者:Teacher,Student 主要事件的执行流程 。 第3章UML 用例图 25 ①教师或学生登录系统。 ②教师或学生选择要查询成绩的课程。 ③教师或学生输入查询条件。 ④系统开始数据库的一项事务处理。 ⑤系统加载满足条件的学生成绩。 ⑥系统显示学生成绩。 ⑦系统结束事务处理。 ⑧系统提示教师或学生成绩显示完毕。 .UseCase:UpdateGrades .参与者:Teacher 主要事件的执行流程 。 ①教师登录系统。 ②教师选择要更新的成绩单课程。 ③教师输入更新条件。 ④系统开始处理数据库的一项事务。 ⑤系统加载满足条件的学生成绩。 ⑥系统显示学生成绩。 ⑦教师更新学生成绩。 ⑧系统保存本次更新。 ⑨系统结束事务处理。 ⑩ 系统提示教师成绩保存完毕。 因为“检查学生成绩报告单的准确性”用例是一个人工处理过程,而不是一 个系统处理过程,因此可以把这个用例从脚本中删除。 .UseCase:GenerateReportCards .参与者:Administrator 主要事件的执行流程 。 创建学生某一门课程的成绩报告单 。 .UseCase:DistributeReportCards .参与者:Teacher 主要事件的执行流程 。 ①教师登录系统。 ②教师在网上发布某一门课程的成绩报告单。 在对上述系统用例进行详细描述之后,除了原有的用例之外,还产生了3个 新的用例———系统登录(Login)、加载成绩(LoadGrades)以及保存成绩(Save 26 UML 应用开发教程———基于RationalRose、Java与MySQL 实现 Grades)。 4. 创建用例模型 根据以上分析,学生成绩管理系统的用例模型的功能如下。 ①教师可以输入学生成绩。 ②输入成绩包含保存学生成绩。 ③教师可以更新成绩。 ④更新学生成绩包含加载、保存成绩。 ⑤教师、管理员和学生可以查询成绩。 ⑥查询成绩包含系统登录。 ⑦管理员可以创建学生成绩报告单。 ⑧教师可以在网上分发学生成绩报告单。 根据以上系统用例模型的功能,可以在Ros6所示 e建模环境下绘制出图3. 的学生成绩管理系统的用例模型。 图3.学生成绩管理系统的用例模型 6 第3章UML用例图 27 3.5 基于Rse创建用例图 8.o 图3.se提供的用例图的建模图形的符号。 7是Ro 图3.用例图的建模图形符号 7 下面以“学生成绩管理系统”为例,介绍在Rose建模环境下创建用例模型 的方法和操作步骤。 (1)创建一个名为“学生成绩管理系统.mdl”的Rose文件。 (2)在浏览窗口,单击UseCaseView中的Main按钮,弹出一个用例窗口, 再单击图标栏上的Actor图标,将光标移动到用例窗口上(此时光标将呈现“+” 状),单击即可在用例窗口中出现参与者的图标, as, 8所示。 名为NewCl如图3. 图3.添加参与者 8 (3)修改参与者的名称有以下两种方法。 .在用例窗口中,双击NewClas 弹出图3. 图标,9所示的对话框。选择 28 UML应用开发教程———基于RationalRose、Java与MySQL实现 General选项卡,将名称改为Teacher,单击OK按钮,完成修改。 图3. s 对话框 9 Clas SpecificationforNewCla .在用例窗口中将光标置于NewClas 处,直接将其修改为Teacher。 (4)采用同样的方法,在用例图中添加Student和Administrator参与者, 如图3. 10所示。 图3.添加St和Admir参与者 10 tudennistrato (5)单击图标栏中的UseCase图标,将光标移动到用例窗口(此时光标将 呈现“+”状),再次单击,则将在窗口中显示用例的椭圆形图标。将用例的名称 改为InputGrades, 11所示。 如图3. (6)单击图标栏中的UnidirectionalRational图标,将光标从Teacher指向 InputGrades,在两者之间添加关联关系,如图3. 12所示。 (7)在用例窗口中添加一个SaveGrades用例,并创建InputGrades与 第3章UML 用例图 29 图3.添加Ips用例 11 nutGrade 图3.添加用例之间的关联关系 12 SaveGrades之间的关联关系。双击这个关联线,在图3. 13 所示的对话框中的 Stereotype下拉列表中选择include关系。 图3.添加Ips与Ss之间的包含关系 13 nutGradeaveGrade 30 UML 应用开发教程———基于RationalRose、Java与MySQL 实现 (8)重复上述步骤,就可以完成图3. 6所示的用例模型。 (9)双击InputGrades用例图标, 14 所示的UseCaseSpecification 弹出图3. forInputGrades对话框,在Documentation文本框中输入该用例的事件流。 图3.添加用例Is的事件流 14 nputGrade 3.本章小结 9 任何一个涉及系统功能活动的人员都要用到用例模型。对用户而言,用例 模型指明了系统的功能,描述了系统如何使用。用例建模时,用户的积极参与也 是十分重要的,这是因为能够充分反映用户的需求,并且可以用用户的语言和术 语描述用例。对于开发者而言,用例模型可以帮助他们充分理解系统要做什么, 同时为今后的其他模型的建模、结构设计、系统实现等提供依据。系统测试人员 可以根据用例测试系统,以验证系统是否完成了用例制定的功能。