UML学习心得耿庆博

UML学习心得

(一) UML（Unified Modeling Language，统一建模语言）是一组用于描述OOAD过程的图形化表达方式。

UML为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。(二) UML由9个不同类型的图组成：

用例图：显示了系统的外部可视行为。

用例图描述了系统外的人员和系统的交互动作，以及系统的响应，该类型的图可以用于描述系统的功能需求。

活动图：显示系统行为的峡谷纳西描述。

活动图描述了单个功能需求内部的细节行为，包括基本的场景和一些可选的场景。

组件图：显示了系统的体系结构。

组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）以及一些借口，可部署单元通过这些接口进行交互，该图可以用于研究系统的体系结构。

顺序图：显示了对象随着时间的交互。

顺序图描述了某个功能需求的路径或场景内相对时间的详细行为，该图可用于理解系统元素之间的消息流程。

协作图：显示了对象的交互，强调对象之间的关系。（在UML2.0里面找不到了）

类图：显示了类的定义和关系。

类图描述了系统设计中的类和接口，以及他们之间的关系。该图可用于定义内部的，面向对象的代码结构。

状态图：显示了响应时间的状态改变。

状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每个事件都被适当的处理。

部署图：显示了系统的物理体系结构。

部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被赋予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。

包图：显示了设计的层次结构。

包图描述了设计的相关元素如何按组结合在一起，以及他们之间的关系。

(三) 各种图的作用

1.用例图（UseCaseDiagram）

它是UML中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。

2.类图（ClassDiagram）

UML面向对象中是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。

3.对象图

UML面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

4.状态图

描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。

5.时序图

又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。

顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。UML面向对象中顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。

6.协作图

UML面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。

协作图用途：

通过描绘对象之间消息的移动情况来反映具体的方案。

显示对象及其交互关系的空间组织结构，而非交互的顺序。

7.活动图（ActivityDiagram）

UML面向对象中UML活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。

活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。

8.组件图（ComponentDiagram）

组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。

组件图的主要目的是显示系统组件间的结构关系。

9.配置图

UML面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。

在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。

UML是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作，用什么模型，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的

理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开始就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。对软件的维护和技术支持者而言，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。建模并不是仅对大型的软件系统，甚至一个小型的留言本也能从建模的过程中受益。利用UML可以有效地解决软件设计和分析过程中的沟通和交流问题，可以高效的了解整个系统结构，并且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施过程中程序员离开的风险。UML可以贯穿软件开发周期中的没一个阶段，在开发阶段，他可以用于说明、可视化、构建和书写面向对象软件制品的设计语言。

UML能贯穿整个软件开发过程是因为在每个阶段都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。在需求分析过程中，应该分为两个过程：1 需求的获取2、需求的分析。需求的获取，往往不受到重视，在网上经常看到有人说，特别是国内目前的情况，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司以往做过的项目做蓝本，然后再根据顾客的需求改动，再次开发，测试，交付就完工了。但如果需求的获取，做不好，往往对后面的步骤流程造成很大的影响，造成太多的改动和损失。所以为了得到更好的需求，使用UML建模能变得相对简单。例如需求的用例图对系统的功能模型的搭建。用例间的关系有包含、扩展、泛化三类。用例图包括角色、用例和关系。角色可以有角色的描述，用例可以有用例的描述，这些描述在交流或评审中会非常有用。用例可以泛化，泛化用例具有基本用例的功能，还可以做得更多。角色也可以泛化，泛化角色能执行原角色能执行的所有用例，还可以执行更多的用例。除了基本用例，角色不能与包含用例、扩展用例和泛化用例有联系。一个用例可以对应一个类图。增、删、改、查一般来说对于大多数应用做为一个简单的操作即可，不必要作为一个用例来分析。