苏晶
山东理工大学 山东 淄博 255049
UML用例模型是系统需求获取及分析的重要手段,是最终用户与开发人员沟通和交流的有效途径。用例模型一旦被确定,所有分析、设计和开发,包括之后的部署及测试等工作都需要以此为依据开展。
用例图中的模型元素之间并非相互独立,参与者之间、用例之间、参与者与用例之间均存在着不同类型的关系。从用户层面来看,关系描述了模型元素间具体化的语义连接,反映了参与者使用系统的具体方式;从开发者层面来看,关系体现了事件处理的流程与协作,决定了系统功能的实现方式。由此可以看出,关系的识别在构建用例模型的过程中发挥着至关重要的作用。
其中,用例间的依赖关系是表现形式及使用方法最为相似且最容易产生混淆的一类关系,本文以网上选课系统为例,对常用依赖关系的建模要点进行比较和分析。
用例之间存在着多种不同的依赖关系,为了强化其具体语义,可通过附加不同的构造型表示不同的关系,用户也可以自定义带有新构造型的依赖关系。其中,包含和扩展关系是用例图中应用最广泛的两种依赖关系[1]。
包含关系是指一个用例可以简单地包含其他用例具有的行为,并将其所包含的用例行为作为自身行为的一部分,这两个用例分别被称为基础用例和被包含用例。包含关系的具体表现形式为被包含用例的事件流可插入至基础用例的事件流中。
在对用例的事件流进行描述的过程中,若发现多个用例同时使用到同一段行为,则可将这段共同的行为单独抽象成为一个用例,然后建立两者之间的包含关系,从而实现重用并简化事件流描述的目的。
以网上选课系统为例,学生可以进行“查看课程信息”、“选择课程”和“删除已选课程”操作,管理员可以进行“维护课程信息”操作,所有操作均需在“登录系统”后方可完成。根据描述,“登录系统”为多个用例的共同行为,可将其抽象出来,成为一个新的用例,并建立其与4个基础用例之间的包含关系。关系一旦创建,这4个基础用例在用例规约的事件流描述中可直接对“登录系统”用例的事件流进行引用,避免了对公共行为的重复描述,提高了模型的可维护性。
扩展关系是指一个用例扩充了另一个用例的功能,但这个扩充功能不是必需的,只有在满足特定条件的情况下才会被执行,这两个用例分别被称为扩展用例和基础用例。
在网上选课系统中,学生和管理员进行“登录系统”操作时,如果忘记密码,则可使用“找回密码”功能。根据描述,作为“找回密码”这一操作,虽然不是由参与者主观意愿驱动执行的,但却是“登录系统”用例执行过程中所产生的一个值得关注的可选行为,因此考虑将“找回密码”抽象为一个扩展用例,并建立其与基础用例之间的扩展关系。
扩展关系往往被用于处理异常或者构建灵活的系统框架。使用扩展关系可以降低系统的复杂度,有利于系统的扩展、提高系统的性能。扩展关系还可用于处理基础用例中那些不易描述的问题,使系统显得更加清晰、易于理解[2]。
包含关系和扩展关系均属于用例间的依赖关系,且基本表现形式都是从现有用例的事件流中抽取出部分行为,将其作为一个单独的用例,从而达到增强现有用例的行为,并提高模型可维护性的目的。但两者在实际使用过程中又存在着显著的区别。以网上选课系统为例,结合用例的事件流描述过程,分析两者的区别主要包括以下三方面。
在扩展关系中,基础用例“登录系统”的执行并不一定会涉及扩展用例“找回密码”,扩展用例只有在满足特定条件的情况下才会被执行。而在包含关系中,当基础用例“选择课程”执行后,被包含用例“登录系统”是一定会被执行的。
因此扩展用例描述的是基础用例的可选行为,而被包含用例描述的是基础用例的必然行为。
在扩展关系中,即使没有扩展用例“找回密码”,基础用例“登录系统”本身也是完整的,而对于包含关系,基础用例“选择课程”在没有被包含用例“登录系统”的情况下就是不完整的存在。
在扩展关系中,扩展用例“找回密码”不是一个完整的用例,必须依赖于基础用例“登录系统”,且不能单独被参与者所调用。
而在包含关系中,被包含用例“登录系统”脱离于基础用例“选择课程”可独立存在,并且可以单独被参与者所调用[3]。
包含关系和扩展关系是用例图中应用最为广泛的两种依赖关系,两者相似度极高,为了能够做到准确识别、科学建模,有效描述用户访问行为,确保后续软件开发活动顺利开展,建议在用例模型构建过程中,遵循以下设计要点:
(1)将公共的行为抽取出来,放到一个被包含用例中,建立与基础用例间的包含关系。通过这种方式,可以避免对公共行为的重复描述,有效提高了模型的可维护性。
(2)将异常处理或变化的行为抽取出来,放到一个扩展用例中,建立与基础用例间的扩展关系。通过这种方式,可以把当前用例中值得关注的可选行为从必需的行为中分离出来,从而达到增强现有用例行为的目的。