基于UML的用例图模型创建

张景峰 胡晓红 陈海燕 常莹 张燕宁

摘要：用例视图是其他视图的核心，因为用例视图描述了系统应该具备的主要功能，系统要提供的功能都要在用例视图中具体描述。并且用例视图如有修改，那么都会对其他所有视图产生直接影响。该文主要介绍用例视图在软件工程设计中的地位和作用。结合实际案例分析用例图的设计角度，组成元素，和构造原理以及各元素之间的独特关系。通过图书管理系统的实际案例进行说明。

关键词：软件工程;Rose软件;视图分析;模型设计

中图分类号：G642 文献标识码：A

文章编号：1009-3044（2019）32-0104-02

1引入

软件工程的模型设计有多种形式，UML的视图就包括五种，有逻辑视图、组件视图、并发视图、配置视图和用例视图。其中，用例视图是其他视图的核心，因为用例视图描述了系统应该具备的主要功能，系统要提供的功能都要在用例视图中具體描述。并且用例视图如有修改，那么都会对其他所有视图产生直接影响。用例视图强调的是从用户的角度看系统所需要的功能。它描述了用户希望如何使用一个系统，用户希望系统提供什么服务。软件工程的产品通常主要是通过外部特性动态的呈现给用户，至于系统是怎样实现的，系统内部的结构如何，并不是他们所关心的内容。所以，在整个软件工程的开发过程中，用例图的制作情况最为重要，因此，它的合理性和正确与否直接影响到用户对最终产品的满意度。

2用例图的构造原理与创建

2.1用例图的构成原理

UML中，用例图是由参与者（actor）、用例（use case）、和他们之间的关系（relationships）等元素构成的。

1）其中，参与者通过向系统输入或者是请求系统输人某个需求，来触发系统完成预想事件。参与者不仅仅代表人，还可以代表事物或者是进程。比如，人们在取款机上取款的过程中，人是参与者，取款机是参与者，安装在取款机中软件系统同样是参与者。

还有一种参与者比较隐秘，只有在特定时刻才能产生作用。举个例子，学生去图书馆借书，假设是一个月的期限，就需要学生在一个月之内及时把书还了，如果超出一个月不还，那么从超出一个月的时刻开始，系统就会提示你要提交罚款。在这个过程中，时间所推动的进程，就是一个系统参与者。所以，综合来说，参与者包括人、相关事物和时间进程。

2）在用例视图中，另一个重要的组成元素是“用例”。它是一个叙述型的对象，主要描述了“做什么”的问题。是活动者在与系统对话过程中对所执行的行为的描述序列。用例表达了系统的功能和所提供的服务。它是系统参与者与系统在交互过程中需要完成的工作，识别用例的最好的办法就是从分析参与者开始，分析系统参与者是如何使用系统的，比如：参与者希望系统提供什么功能;系统是否需要存储，是否要进行信息检索，如果需要，是由哪个参与者触发的;还有当系统状态改变时，是否通知参与者;是哪些参与者通知系统相关事件;以及是否存在影响系统的外部事件等等。根据存在的参与者不同，可以将系统分为不同的用例图分别加以描述。

3）用例视图中第三个重要的元素就是参与者与用例之间的关系。因为有了某种关系，才会触发特定事件的产生。在用例视图中，参与者与用例的关系主要有四种：关联关系、泛化关系、包含关系、扩展关系。

关联关系：泛指两个对象之间发生联系。比如一个对象访问另一个对象。而且在参与者与用例之间的关联关系是有方向的。

泛化关系：是定义了一般元素和特殊元素的分类关系。比如，“交通工具”与“汽车”“火车”“自行车”之间;再比如，“图书借阅者”与“学生”和“老师”之间。

包含关系：包含关系是用例视图中特有的一种关系。是指一个用例的行为包含了另一个用例的行为。比如，“查询用户”与“修改用户信息”和“删除用户信息”之间就是这样。在用例图中，泛化关系主要描述多个参与者之间的公共行为。如果一个系统中存在几个参与者，既扮演自身，同时也扮演一般化的角色，那么特殊化的参与者与一般化的角色之间就可以用泛化关系来描述他们。

扩展关系：是指在已有用例基础上，由于某个事件的触发，而产生了新的用例，就像在某一个节点上又生出了新的节点。比如，在图书馆还书时，因为超出了期限，又要额外交罚款。这就是扩展关系。

4）用例图建模技术

对于一个软件工程系统而言，有些事物是存在于系统的内部，他们的任务是完成工程所期望的系统行为;而有些事物是存在于系统的外部，即构成了系统存在的环境。所以，在uML建模过程中，用例视图是对工程系统的语境进行建模，它主要考虑系统做什么，而基本不考虑系统怎么做。根据用户对产品功能的期望，提出产品外部功能描述。用例图是表达和管理系统主要的功能需求。在对系统外部语境建模的过程中，首先要识别系统外部的参与者。如：谁使用该系统;为什么使用;交互中，他们扮演什么角色;谁安装系统;谁从系统中获取信息;谁维护系统;谁启动和关闭系统;谁提供信息给系统等等。

在参与者的建模中，还有几个要点需要注意：

每个参与者需要具有一个有针对含义的名字，不要使用模糊含义的名字。

参与者在系统外部，直接与系统交互，容易定义系统范围。

参与者是交互时扮演的角色，不是特定的人或特定的事物。

一个对象在与系统交互过程中，可以扮演多个角色。

2.2用例图的创建

为了更深入的理解用例图的构造原理，下面引用一个实际案例来具体说明。以大学图书馆的图书管理系统为例，运用Rational Rose建立图书管理系统用例图。

大学图书馆图书管理系统软件是一套功能强大，操作方便简单、实用的自动化管理软件，大学图书馆专业图书和其他各种图书众多，从师生等读者角度，会经常频繁的进行图书查询、借阅、归还等等;从图书管理员角度，需要进行借书处理，还书处理等等;从系统管理员的角度，需要进行图书系统维护、增加新书目删除旧书目、管理读者信息等等。所以，应该包括用户信息管理、系统参数设置、图书数据录入、图书数据查询、借阅管理、归还管理、系统维护等等。系统应该具备较好的功能扩充。开发图书管理系统软件，是为了满足广大师生查阅和借阅图书方便的要求，以高效率、现代化的模式进行学习和工作。

图书管理系统应该具备主要的功能需求：

1）用户登录：首先要求用户进行注册和登录。要求用户名和密码匹配，验证通过才能允许用户进入系统。

2）修改注册信息：登录后，可以重新修改密码等信息。

3）权限设置：系统管理员进行。

4）图书信息录入：录人新图书的相关信息。

5）数据查询：根据用户输入的条件进行相应查询。

6）数据修改：增加圖书、删除图书、图书辅助信息的调整（且有管理权限的用户可以操作。）

7）图书借阅：外借登记、归还记录等（具有管理权限的用户可以操作）

8）数据备份：实现系统数据的备份和恢复机制。

9）数据维护：系统管理人员操作。

10）查阅操作日志：具有权限的用户操作。

确定系统的主要参与者：

首先，有借阅者的参与。借阅者登录系统，浏览查询图书，选定并借阅图书，最后归还图书。

第二，有图书馆管理人员的参与。处理借书、还书的操作

第三，有系统管理员的参与。增加图书、删除图书、更新图书、还有借阅者信息的管理等工作。

图书管理系统的用例确定：

1）借阅者用例：登录系统、查询信息、预定图书、借阅图书、归还图书。

2）图书馆工作人员用例：处理图书借阅、处理图书归还

3）系统管理人员：查询图书信息、增加图书信息、删除图书信息、更新图书信息、管理借阅者信息。

运用Rational Rose制作用例图：

1）借阅者用例图：用泛化关系将参与者进行连接，“学生”“教师”属于特殊化角色，“借阅者”是一般化角色，关系的方向指向一般角色。由于设计思路和设计理念的不同，用例图呈现的最终结果也不尽相同，有的设计，涉及的所有查询借阅工作，都是在成功登录系统之后才能进行。而有的设计是查询查阅不需要登录就能进行。在这里，提供一种设计形式。

2）图书馆工作人员的用例图：在这个用例图中，参与者一个，就是“图书管理员”。主要的用例有三个，即“图书借出”“图书归还”“处理预约”。其中，在“图书借出”之前，工作人员需要首先“检查读者账户”信息，看是否超出借阅数量或者是其他情况不能继续借阅，所以这两个人用例之间是包含关系。另外，在“图书归还”之前，管理员也要检查是否超出期限，如果是，则需要增加新的用例“收取罚款”，所以，两者之间是扩展关系。

3）系统管理员的用例图：参与者是“系统管理员”。主要用例是：“系统维护”“图书管理”“用户管理”。其中，在“图书管理”中，包括“添加图书信息”“编辑图书信息”“删除图书信息”等子用例;在“用户管理”用例中，包括“添加用户信息”“修改用户信息”“查询用户信息”等子用例。

3总结

用例视图是UML所有视图中最重要的视图，它的设计优劣直接影响到用户对工程产品的满意度。尽管每个模型都有不同的设计方案和表达形式，但是最好的模型总是能够最大可能的切合实际，节约成本。而且，越庞大的项目，建模的重要性越大。只有好的模型的帮助，才能更好地理解和完成项目。

【通联编辑：王力】