UML概述与详解

Longronglin之UML：

 因为上面写了个设计模式而没有UML所以贴了上来。这些都是我2004年上半年无聊的时候整理的。望对大家有用

统一建模语言(UML:Unified Modeling Language)

1．能够从不同的角度来看待系统的结构，行为，功能（需求）。

2．能够在不同抽象程度上考虑系统，而仅仅是源代码是不够的。源代码是非常细化的内部结构，不能用来建造复杂的系统。

UML图及其目的
当你……	使用UML图……
在分析阶段	用例图，它们包含和系统交互的实体以及需要实现的功能点。
活动图，它们将焦点集中于问题域（人们以及其它主体工作的实际空间，程序的主题域）的工作流而不是程序的逻辑流。
观察对象交互	交互图，它们展示特定的对象彼如何此交互。由于它们处理特定案例而不是一般情况，因此它们在检验需求和检验设计时都能有所帮助。最流行的交互图是顺序图。
在设计阶段	类图，它们详述类与类之间的关系。
观察对象的行为，这些行为因对象所处的状态而不同	状态图，它们详述一个对象可能处于的不同状态以及这些状态之间的过渡。
在布署阶段	布署图，它们展示了不同的模块将被如何部署。我不会在此讨论它们。

 

UML的定义包括UML语义和UML表示法两个部分：

UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。
·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

静态视图：

类元

关系的种类

用例之间的关系

状态的种类

总结：

行为：事物随着时间进行的改变。状态图和活动图描述个别类型的行为。例如，用例，类，子系统，组件：顺序图描述一组类型的协作：我们使用协作图。许多类潜在的结构，来定义对象的协作，这些协作实现用例，或完成一个用例。协作是一组对象实现一个用例。状态图是对象的行为描述。

 

售票系统设计（大家熟悉）：

用例视图

 

顺序图

协作图
　　

状态机视图

活动视图

物理视图

构件图
　　

部署图（描述层）
　　

实例层部署图

模型管理视图

 

全面认识UML类图元素 （http://blog.csdn.net/legendinfo/）

类（Class）

类（图A）是对象的蓝图，其中包含3个组成部分。第一个是Java中定义的类名。第二个是属性（attributes）。第三个是该类提供的方法。
属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型，如图A的“Java”区域所示。

图A

包（Package）

包（图B）是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。进行建模时，你通常拥有逻辑性的包，它主要用于对你的模型进行组织。你还会拥有物理性的包，它直接转换成系统中的Java包。每个包的名称对这个包进行了惟一性的标识。

图B

接口（Interface）

接口（图C）是一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口既可用图C的那个图标来表示，也可由附加了<<interface>>的一个标准类来表示。通常，根据接口在类图上的样子，就能知道与其他类的关系。

图C

关系

后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。

依赖（Dependency）

实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。

图D

关联（Association）

实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E）转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个Employee。

图E

聚合（Aggregation）

聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。
关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。

图F

合成（Composition）

合成 （图G）是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。

Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。

图G

泛化（Generalization）

泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。

图H

实现（Realization）

实例（图I）关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。

图I

 

术语大全

access（访问）
访问是一种许可依赖关系，允许一个包引用另一个包中的元素。
见friend、import、visibility。
语义
一个包（客户）如果要引用另一个包（提供者）内的元素，那么它必须引入一个包，该包包括客户包到提供者包的《access》或《import》依赖关系上的元素。一个包可以隐含地获得对由包含该包的任何包所引入的包的访问权（即，嵌套包可以看到包含包可以看到的一切）。
包中的元素可以访问包内所有可见的元素。可见性规则可以总结如下：
* 一个包中定义的元素在同一个包中是可见的。
* 如果一个元素在一个包中是可见的，那么它对所有嵌套在这个包中的所有包都是可见的。
* 如果一个包访问或引入另一个包，那么在要被引入或访问的包中定义为公共可见性的元素对引入包都是可见的。
* 如果一个包是另一个包的孩子，那么所有在父包中定义为公共的或受保护的可见性的元素对子包是可见的。
* 访问或引入依赖关系是不能传递的，如果A能看到B，且B能看到C，这并不意味着A能看到C。
结论：除非一个包能够访问它的嵌套包且嵌套包的内容是公共可见的，否则这个包不能看到它自己的嵌套包的内部。
下面是有关可见性的更深一步的规则：
* 如果一个类元的内容，如它的属性和操作以及嵌套类，在类元中具有公共可见性，那么它们在包中是可见的。请注意一个子系统的未组织的内容是由上面提到的包规则指导的，但是任何子系统本身的属性或操作由这条规则指导。
* 如果一个类元的内容有公共的或受保护的可见性，那么它们对后代类元是可见的。
* 一个类元的所有内容对类元内的元素都是可见的，包括类元的方法或状态机中的元素。
一般情况下都会涉及到对等包中的元素。在这种情况下，一个元素能看到它自己包内的所有元素和被它所在包引入的包的具有公共可见性的所有元素。一个类可以看到其他类中的公共特征。一个类也可以看到它的祖先的受保护的特征。
表示法
访问依赖关系用一个从客户包指向提供者包的虚箭头表示。箭头用关键字《access》作为标号。
讨论
图为一个两个包间的对等层访问的例子。包P能够访问包Q，但是包Q不能访问包P。P包中的类K和L能看到包Q中的类M，但是它们看不到私有类N。除了具有公共可见性的类K之外，类M和N看不到包P中的任何类，因为包Q不能访问包P。要想一个类对对等包是可见的，这个类必须具有公共可见性，并且它的包必须被对等包访问或引入。

图对等访问

图访问规则
图为一个有关可见性和访问声明的更复杂的例子。元素名字前的符号代表了它的可见性：+代表公共的，#代表是受保护的（只对后代可见），-代表是私有的（对外界是不可见的）。
类A能看到C和E因为它们包含在包Y和X内。
类C和A能够看到D，因为包Y引入了包Z。类A嵌套在包Y中并且能够看到Y能看到的一切。
类A、C和E能看到B，因为它们嵌套在包X中，而X引入包含B的包V，但是，它们看不到F，因为F在它的包V中是有私有可见性。所以，类F在包V外是看不到的。
类E看不到D因为D在包Z中，而Z并没有被包X访问。
类C和E都看不到A。类A在包U中，U没有被任何包访问。
类B和F能够看到类D和E，D和E建立在包含包中。它们也能看到C，C在包Y中，而包Y被包含包访问。虽然F是私有的，但这并不影响它看到其他的类，而其他的类看不到F。
类B和F能够互相看到，因为它们在同一个包中。类F对外面的包中的类是私有的，但对它自己包中的类不是这样。

 

UML与设计模式（设计模式请查询相关资料）

 

 

参考文献：

http://blog.csdn.net/legendinfo/

http://blog.csdn.net/dwater/

http://blog.csdn.net/cwj007/

《UML参考手册》

《The Unified Modeling Language Reference Language》

《标准建模语言UML及其支持环境》北京航空航天大学软件工程研究所

《UML Programming Guide》

《OMG Unified Modeling Language Specification》

《X-Programmar》

注：转载请注明出处和参考文献（本文的原著），请遵守相关法律，仅供学习研究。不得用于商业目的。

转载出处：http://blog.csdn.net/longronglin/archive/2006/12/22/1454329.aspx