基于UML用例图的系统需求分析

基于UML用例图的系统需求分析

一、UML简介

UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二、用例建模简介

用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为，图示化系统的主事件流程。

用例图主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。

●用例图

包含了用例Use Case）和参与者（Actor）。用例之间用关联来连接，以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

●用例描述

用来详细描述用例图中每个用例，用文本文档来完成。

三、用例图说明

●参与者

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

●用例

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。可以简单的理解为用例是参与者想要系统做的事情。对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

用例之间也可以存在包含(include)、扩展(extend)和泛化(generalization)等关系：（1）包含关系：如果一个用例（基本用例）包含另一个用例（包含用例）的功能，那么认为这两个用例之间存在包含关系。

（2）扩展关系：在UML 建模中，可以使用扩展关系来指定一个用例（扩展）扩展另一个用例（基本）的行为。这种类型的关系将揭示有关通常隐藏在用例中的

系统或应用程序的详细信息。

可以对模型添加扩展关系以显示下列情况：

∙用例的作为可选系统行为的一部分

∙仅在某些情况下才执行的子流

∙可插入到基本用例中的一组行为段

（3）泛化关系：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

用例间的泛化关系和类间的泛化关系类似，即在用例泛化中，子用例表示父用

例的特殊形式，子用例从父用例处继承行为和属性，还可以添加行为或覆盖，

改变已继承行为。当系统中具有一个或多个用例是较一般用例的特化时，就使

用用例泛化。

通讯关联

通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些用例（或者说系统所提供的用例被哪些参与者使用）。

通讯关联以箭头或实线表示。若使用箭头，箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者（Actor）来启动；如果不强调对话中的主动与被动关系，则可以使用不带箭头的关联实线。