如何进行UML需求分析及其意义解析

本节向大家介绍一下UML需求分析，主要包括为什么要用UML进行需求分析和，如何进行UML需求分析，以及用例图绘制等内容，希望通过本节的学习你对UML需求分析有全面的认识。

1.UML需求分析培训

1.1为什么要用UML进行需求分析

什么是UML？

UnifiedModelingLanguage(UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

我这里就不讲需求分析在软件产品开发中的地位了,我从项目开发的实际情况讲一下为什么要用UML进行需求分析

1:UML需求分析是一项重要且贯穿整个项目开发的过程,这样就需要一份很好文档提供给每一个阶段的开发人员,包括:测试人员,维护人员

2:需求分析文档是要给需求管理人员,项目经理,用户,测试人员,项目开发人员看的,如何把需求分析人员所知道的需求很好描述出来也是一件很重要的工作,因为需求分析出来的主要是给别人看;这是仅仅用文字描述是不够的,还需要用图表等多种情形展现需求

1.2如何进行UML需求分析？

UML的展现形式有多种,如:类图,用例图,顺序图,活动图,状态图等,要跟具实际情况进行选用,我一般在做需求分析时选用"用例图"和"活动图"

1:用例图中清楚的、简要的用例描述每个角色能够使用的功能,方便在用户确认需求时很清楚有哪些功能及每个角色的权限.

2:活动图反应的是一个业务的工作流程,使用活动图有以下好处:

(1):方便用户确认需求,因为用户最了解工作流程,在确认需求时,用户通过我们的活动图,就很容易发现是否满足需求.

(2):有利于于开发人员对整个业务的了解,知道自己在做些什么及如何做.提出不同的解决方案

1.2.1用例图

用例图的作用及描述

UML需求分析中用例图说明的是谁要使用系统以及他们使用该系统可以做些什么?(用例图说明的是业务需求)它描述了系统提供的一个功能单元。

====主要目的

用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，以及系统内用例之间的关系。用例图一般表示出用例的组织关系.
反应每个角色的权限,清楚的、简要的描述每个角色能够使用的功能,方便在用户确认需求时很清楚每个角色的权限.

用例图的画法

名词解释

1:参与者
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

2:用例
用例是用户期望系统具备的动作.创立一个用例名时,要尽量使用主动语态动词和可以描述系统上执行的功能的名词.

3:箭头
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

UML需求分析中角色之间的关系：

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

1:泛化
是一种用于表示UML中项目的继承的技术.泛化可以应用于参与者和用例来表示其子项从父项继承功能,而且泛化还表示父亲的每个孩子都有着略微不同的功能或目的以确保自己的惟一性.
泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

◆只要能说出"A项是B项的一种",你就找到了一个泛化.

UML需求分析中用例与用例之间的关系

1:泛化

2:包含关系：
基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

◆当一个用例要一直使用另一个用例时就确定为包含关系.

3:扩展关系