设计模式-UML类图基础

设计模式之序-UML类图那点事儿

打14年年底就像写那么一个系列，用于讲设计模式的，代码基于JAVA语言，最早接触设计模式是大一还是大二来着，那时候网上有人给推荐书，其中就有设计模式，当时给我推荐的书我还隐约记得，叫GoF的，书名是《Design Patterns: Elements of Reusable Object-Oriented Software》，也即《设计模式》，机械出版社的将其翻译为《设计模式-可复用面向对象软件的基础》。至于为什么叫做GoF，那时候因为作者是四个人，被称为（Gang of Four），至于作者分别交什么？自行度娘或者谷歌去吧。好吧扯远了，继续刚才的说。虽然打算来写这么一个基于JAVA语言实现的设计模式系列，但是由于懒病深钟，且已病入膏肓，便无疾而终。直至前些天，群里有人并让我教他设计模式，他是一个做前端的，因此不禁念头又生，说道：那我写一个系列用于讲设计模式的算了，群里其他人也纷纷表示要学习。于是便有了此文。身为设计模式方面的半吊子，重温设计模式（以前看过小菜版的大话设计模式，不过是C++写的），文中若有不对之处，请各位大神务必指出，可不要让我误人子弟。闲话少说，在设计模式正文开始之前先介绍一下UML类图。

UML以及UML类图简介

　　Unified Modeling Language (UML)又称统一建模语言或标准建模语言。UML从考虑系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图。这些图从不同的侧面对系统进行描述。系统模型将这些不同的侧面综合成一致的整体，便于系统的分析和构造。尽管UML和其它开发工具还会设计出许多派生的视图，但上述这些图和其它辅助性的文档是软件开发人员所见的最基本的构造。首先对9种图做个简要介绍：

　　1.UML用例图与OOSE中的用例图类似。

　　2.UML的类图综合了OMT、Booch等面向对象方法中的类图。

　　3.UML状态图是对David Harel所提出状态图的改进。

　　4.UML活动图的基本语义和状态图大致相同，它类似于许多方法（包括面向对象技术之前的一些方法）中的工作流图。

　　5.UML的协作图是通过对Booch方法的对象图、Fusion方法的对象交互图以及其它一些方法中的相关图表改造而成的。

　　6.UML的构建图和部署图是在Booch方法中的模块和进程图（处理关系图、处理器图）的基础上发展起来的。

　　当然在此主要介绍类图。在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。建模工具也主要根据类图来产生代码。James Rumbaugh对类的定义是：类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象系统中最重要的构造块。类图显示了一组类、接口、协作以及 他们之间的关系。在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。类加上他们之间的关系就构成了类图，类图中还可 以包含接口、包等元素，也可以包括对象、链等实例。

类的UML表示

　　类的命名尽量应用领域中的术语，应明确、无岐义，以利于相互交流和理解。类的属性、操作中的可见性使用＋、#、－分别表示public、protected、private。

　　

　　我们通过以上的图来分别解释行是什么含义（感谢百度百科提供的图）：

　　第一行是类的名称，抽象类是用斜体表示。

　　第二行是类里面所具有的属性：比如说如果这个类是一个动物的话，那么color、name之类的都可以在此描述。

　　第三行是类里面所包含的方法，比如说跑，跳，说话等等等等~

　　说完了类的UML表示，那么重点内容就要来了（PS：警报，前方高能、、、）

UML类图的几种关系

　　在UML类图中，当然不可能仅仅一个类孤立的存在着，这样也没有什么意义，就如同人一般，必须是群体性的，既然有多个类图，那么自然就有各种关系，就像人，人与人之间有基友，损友，诤友blablabla、、、好吧，那些都是朋友~那么类图之间有什么关系呢？常见的有以下几种：实现（Realization）、泛化（Generalization）、关联（Association）、聚合（Aggregation）、组合(Composition)、依赖(Dependency)这么几种。下面具体介绍。（PS：以下内容来自tianhai110）。

实现(Realization)　　　　

　　【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

　　【箭头指向】：带三角箭头的虚线，箭头指向接口。

　　

泛化(Generalization)

　　【泛化关系】：是一种继承关系,它指定了子类如何特化父类的所有特征和行为例如：老虎是动物的一种。

　　【箭头指向】：带三角箭头的实线，箭头指向父类。

　

关联（Association）

　【关联关系】：是一种拥有的关系,它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子。

　 关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

　【代码体现】：成员变量。

　【箭头及指向】：带普通箭头的实心线，指向被拥有者。

　上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。当然也会有自身的关联。如下图所示就是自身的关联。

　　

聚合（Aggregation）

　　【聚合关系】：是整体与部分的关系.如车和轮胎是整体和部分的关系。

　　 聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

　　【代码体现】：成员变量。

　　【箭头及指向】：带空心菱形的实心线，菱形指向整体。

组合(Composition)

　　【组合关系】：是整体与部分的关系.,没有公司就不存在部门      组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

　　【代码体现】：成员变量。

　　【箭头及指向】：带实心菱形的实线，菱形指向整体。

依赖(Dependency)

　　【依赖关系】：是一种使用的关系,所以要尽量不使用双向的互相依赖。

　　【代码表现】：局部变量、方法的参数或者对静态方法的调用。

　　【箭头及指向】：带箭头的虚线，指向被使用者。

　　各种关系的强弱顺序：

　　泛化= 实现> 组合> 聚合> 关联> 依赖

　　下面这张UML图，比较形象地展示了各种类图关系：

　　以上就是有设计模式的序章的全部内容，主要介绍了UML、UML的九种图、类图以及类图间的关系。设计模式中有好些需要用到类图间的关系，所以在序章先打下基础了~