UML用例模型中依赖关系的比较与分析

2021-12-27苏晶

科学与信息化 2021年12期

苏晶

山东理工大学山东淄博 255049

前言

UML用例模型是系统需求获取及分析的重要手段，是最终用户与开发人员沟通和交流的有效途径。用例模型一旦被确定，所有分析、设计和开发，包括之后的部署及测试等工作都需要以此为依据开展。

用例图中的模型元素之间并非相互独立，参与者之间、用例之间、参与者与用例之间均存在着不同类型的关系。从用户层面来看，关系描述了模型元素间具体化的语义连接，反映了参与者使用系统的具体方式；从开发者层面来看，关系体现了事件处理的流程与协作，决定了系统功能的实现方式。由此可以看出，关系的识别在构建用例模型的过程中发挥着至关重要的作用。

其中，用例间的依赖关系是表现形式及使用方法最为相似且最容易产生混淆的一类关系，本文以网上选课系统为例，对常用依赖关系的建模要点进行比较和分析。

1 用例间的依赖关系

用例之间存在着多种不同的依赖关系，为了强化其具体语义，可通过附加不同的构造型表示不同的关系，用户也可以自定义带有新构造型的依赖关系。其中，包含和扩展关系是用例图中应用最广泛的两种依赖关系[1]。

1.1 包含关系

包含关系是指一个用例可以简单地包含其他用例具有的行为，并将其所包含的用例行为作为自身行为的一部分，这两个用例分别被称为基础用例和被包含用例。包含关系的具体表现形式为被包含用例的事件流可插入至基础用例的事件流中。

在对用例的事件流进行描述的过程中，若发现多个用例同时使用到同一段行为，则可将这段共同的行为单独抽象成为一个用例，然后建立两者之间的包含关系，从而实现重用并简化事件流描述的目的。

以网上选课系统为例，学生可以进行“查看课程信息”、“选择课程”和“删除已选课程”操作，管理员可以进行“维护课程信息”操作，所有操作均需在“登录系统”后方可完成。根据描述，“登录系统”为多个用例的共同行为，可将其抽象出来，成为一个新的用例，并建立其与4个基础用例之间的包含关系。关系一旦创建，这4个基础用例在用例规约的事件流描述中可直接对“登录系统”用例的事件流进行引用，避免了对公共行为的重复描述，提高了模型的可维护性。

1.2 扩展关系

扩展关系是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，只有在满足特定条件的情况下才会被执行，这两个用例分别被称为扩展用例和基础用例。

在网上选课系统中，学生和管理员进行“登录系统”操作时，如果忘记密码，则可使用“找回密码”功能。根据描述，作为“找回密码”这一操作，虽然不是由参与者主观意愿驱动执行的，但却是“登录系统”用例执行过程中所产生的一个值得关注的可选行为，因此考虑将“找回密码”抽象为一个扩展用例，并建立其与基础用例之间的扩展关系。

扩展关系往往被用于处理异常或者构建灵活的系统框架。使用扩展关系可以降低系统的复杂度，有利于系统的扩展、提高系统的性能。扩展关系还可用于处理基础用例中那些不易描述的问题，使系统显得更加清晰、易于理解[2]。