一、ULM概述
统一建模语言(UML)是一个通用的可视化建模语言,用于对软件进行描述、可视化处
理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解,可用于
对系统的理解、设计、浏览、配置、维护和信息控制。
UML主要内容

UML的主要特点
1. 统一的建模语言
2. 支持面向对象
3. 支持可视化建模
4. 强大的表达能力
二、静态建模机制
用例图
用例视图也称用例模型,用例模型描述的是外部执行者(actor)所理解的系统功能。用
例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者
和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统
看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发
工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系
统,从而影响到开发工作的各个阶段和 UML 的各个模型。在 UML 中,一个用例模型由
若干个用例图描述,用例图中显示执行者、用例和用例之间的关系。用例图包含系统、执
行者和用例 3 种模型元素。
1.系统
系统是用例模型的一个组成部分,代表的是一部机器或一个业务活动,而不是真正实
现的软件系统。系统的边界用来说明构建的用例模型的应用范围。
2.用例
用例代表的是一个完整的功能,用例是动作序列的集合,系统执行该动作序列来为执
行者产生一个可观察的结果。动作是系统的一次执行。

3.执行者
执行者是指用户在系统中所扮演的角色,是与系统交互的人或事。
类图和对象图
类图(class diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其他图的基础。在类图的基础上,状态图、交互图等进一步描述了系统其他方面的特性。
(1)、 类的获取和命名
类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域进行仔细的分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。
(2)、类的属性
类的属性用以描述该类对象的共同特点,该项可省略。了解属性时应该考虑以下因素:
①.属性表示关于对象的信息,原则上来说,类的属性应能描述并区分每个特定的对象;
②.只有系统感兴趣的特征才包含在类的属性中;
③.系统建模的目的也会影响到属性的选取。
(3)、类的操作(Operation)
操作是一个服务的实现,是对一个对象做什么事情的抽象。一个类可以有任意数目的
操作,也可以没有操作。
2.关联关系
(1)、关联
关联(association)表示两个类之间存在某种语义上的联系。关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在 UML 中称为导航(navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联。
UML 规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。关联关系一般都是双向的,即关联的对象双方彼此都能与对方通信。根据不同的含义,关联可以分为普通关联、递归关联、限定关联、或关联、有序关联、三元关联和聚合 7 种。
(2)、关联的角色
关联两头的类以某种角色参与关联。如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。
(3)、关联类
在有些问题中,关联关系不仅需要一个名称、需要定义相关对象的角色及其参与这些角色的对象数量,而且还需要设置一些属性、操作以及其他特征。关联可能要记录一些信息,因此引入一个关联类来记录,也就是说,与一个关联关系相连的类称作关联类。关联类并不位于表示关联关系的直线两端,而是对应一个实际的关联,用关联类表示该实际关联的一些附加信息。关联类通过一根虚线与关联连接。
(4)、整体/部分关联
UML 对于整体/部分关联有特殊的表示法:组成和聚集。
组成(composition)关联表示整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失。“整体”称作组成对象,“部分”称作成分对象。
聚集(Aggregation)是一种特殊形式的关联。聚集也表示类之间的整体/部分关联,但主要强调组/成员的关联。整体被称作聚集对象,部分称作构成对象。
①.构成对象不存在,聚集对象还可以存在。
②. 在任何时候,每个对象都可以是多个聚集的构成。
③. 聚集往往是同构的,也就是,典型的聚集的构成对象将属于同一个类。
3.泛化关系
一个类(一般元素)的所有特征(属性或操作)能被另一个类(特殊元素)继承。也称泛化。泛化定义了一般元素和特殊元素之间的关系。在 UML 中, 泛化表示为一头为空心三角形的连线。UML 对定义泛化关系有下述有三个要求:
(1)、特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有。
(2)、特殊元素还应包含额外信息。
(3)、允许使用一般元素实例的地方,也应能使用特殊元素。
对象图
UML 中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类 的实例,对象之间的链(link)是类之间的关联的实例。对象的图示方法与类的图示方法几乎 一样,主要差别在于对象的名字下面要加下画线。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。
对象名有下列三种表示格式:(1)对象名:类名。(2):类名。(3)对象名。
三、动态建模机制
顺序图
顺序图用来描述对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。顺序图存在两个轴:水平轴表示不同的对象,垂直轴表示时间。在顺序图中,对象用一个带有垂直虚线的矩形框表示,在矩形框内标有对象名和类名。
在面向对象程序设计中,总体的控制流程往往是难以理解的。一个好的设计应当将很多小方法放入不同的类中,并且随时能巧妙地指出总体的行为顺序,这样可以十分有效地帮助你加速了解代码。对于首次接触面向对象程序设计的人来说尤其是如此,顺序图可以帮助你看清行为的次序。
协作图
协作图是交互图的第二种形式。协作图也是用来描述对象与对象之间的消息连接关系的,但是它更侧重于说明哪些对象之间有消息传递,而不像顺序图那样侧重于在某种特定的情形下对象之间传递消息的时序性。在协作图中,对象同样是用一个对象图符号来表示,箭头表示消息发送的方向,而消息的执行顺序则由消息的编号来标明。
状态图
状态图(State Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。
状态图适合于描述跨越多个用例的单个对象的行为,而不适合于描述多个对象之间的行为协作。
活动图
活动图显示动作及其结果,着重描述操作实现中所完成的工作以及用例实例或对象中的活动。活动图是状态图的一个变种,与状态图的目的有一些小的差别。
活动图的主要目的是描述动作(执行的工作或活动)以及对象状态改变的结果。
活动图可以用作下列目的:
(1)、描述成操作执行过程中(操作实现的实例化)所完成的工作(动作),这是活动图最常用的用途。
(2)、 描述对象内部工作。
(3)、显示如何执行一组相关的动作,以及这些动作如何影响它们周围的对象。
(4)、显示用例的实例是如何执行动作以及改变对象状态的。