【UML】最简单的类图

Rational Rose简明实用教程 https://blog.csdn.net/gz153016/article/details/49641847

Rational Rose是Rational公司出品的一种面向对象的统一建模语言的可视化建模工具。用于可视化建模和公司级水平软件应用的组件构造。现在比较少的公司在使用已Rose。IBM推出了Rational Software Architect来替代Rational Rose。

如何用Rational Rose 画组合聚合关系（实心菱形）

聚合关系包括基本聚合（空心菱形）和组合聚合关系（实心菱形）

也有的称为聚合aggregation（空心菱形）和组合composition（实心菱形）

聚合是一种相对松散的关系，在ROSE里面生成的代码和组合是一样的。

Rose 2003并不提供“组合关系”这种图形（实心菱形）

1.可以先画一个aggregation（空心）的关系（下拉菜单栏tools--->aggregation），

2.然后右键单击这个关系，open specification ->Role B Detail,

3.你会发现有三项选（By Value, By Reference, Unspecified），在你选上By Value的时候，菱形就变成实心的了。

双击线条，设置Role B General和Role A General

共有可见性(+):对能看到这个类的任何元素都可见。
保护可见性(#):对这个类及其子类的其他元素可见。
私有可见性(-):对这个类的其他元素可见。
包可见性(~):对同一个包中的其他元素可见。

类关系

类很少是独立的，类之间的基本联系包括关联、泛化、聚合和组合。

1.关联和依赖

对于很多刚刚接触UML的童鞋，可能会对类之间的关联与依赖关系不太理解，今天小菜就浅薄的讲一下。

依赖

表现为函数中的参数(use a)，是类与类之间的连接，表示一个类依赖于另一个类的定义，其中一个类的变化将影响另外一个类。例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用。如电视(TV)依赖于频道(channel)常见的依赖关系如下：
（1）类B以参数的形式传入类A的方法。我个人将它就取名为“参数依赖”。
（2）类B以局部变量的形式存在于类A的方法中。我个人将它就取名为“局部依赖”。
（3）类A调用类B的静态属性或方法。我个人将它就取名为“静态依赖”。
UML图中实现使用一条带有箭头的虚线指向被依赖的类，如下：

关联（委派）

表现为变量(has a)，类与类之间的联接，它使一个类知道另一个类的属性和方法。例如如果A关联于B，则B体现为A的全局变量，如person类和company类。
关联关系有双向关联和单向关联：
1、双向关联：两个类相互都知道另一个类的公共属性和操作。
2、单向关联：只有一个类知道另外一个类的公共属性和操作。
大多数关联应该是单向的，单向关系更容易建立和维护，有助于寻找可服用的类。
UML图中实现使用一条实线(有的地方用带箭头的实线)连接相同或不同类，如下：

这块的确是有点乱，不过小菜突然找到了一个比较好的切入点，拿出来分享一下。

接触过设计模式的读者，会经常看到这样的场景：在实例化A类的时候，需要B类作为构造方法的参数，这说明A类需要持有一个B类的引用。比如代理模式、装饰模式等，都会这样做。例如Java中的IO流采用的就是装饰模式，所以我们会经常看到这样的语句：new BufferInputStream(new FileInputStream("c:\\1.db"));

person与company之间的关联关系也叫委派关系（我自己称呼的）。

这种持有引用，就是简单的关联关系。在代码中表现为：在A类中有一个成员变量，变量的类型是B类，A类中持有了B类的引用，就说明A类和B类发生了关联关系。

用UML图表示如下：

稍加说明，由于是A类持有B类的引用，因此关联是从A类中发出的(由A类引起)，因此箭头要从A类指向B类。

通常情况下，这种简单的单向关联就够用了，但是关联关系主要还是应用在数据库设计中。

在数据库设计中，无论是一对一、一对多、多对多，都不是单向的。

从表的角度分析，它们均可以从任意一端确定另一端。就拿一对多来说，有了one端的主键，可以根据many端表的外键查出many端数据；有了many端外键，可以根据one端表的主键查出one端数据。

从实体类的角度分析，同样可以从任意一端确定另一端。还是拿一对多来说，one端的实体类会持有一个many端的引用集合，例如private Set<B> bs;，查询到了one端，可以直接从这个集合中读取many端；many端的实体类会持有一个one端的引用，例如private A a;，查询到了many端，可以直接从这个引用确定每一个many端的one端。

这样一来，就成了双向关联，用UML画关联关系的时候，两边都要加箭头，这样太难看，索性就都不加了。

例如部门实体类和员工实体类的关系，就可以这样表示：

由于是数据库实体类间的关联关系，因此还要加上数量关系，1代表one端，0..n代表many端，说明一个部门可以有多个员工，但一个员工只能属于一个部门，通过UML图描述了一对多。

这个才是关联关系典型的应用。

不得不提的是，关联关系还可以细分为聚合和组合(二者的具体概念读者自行搜索)。

小菜发现聚合、组合可以从另一个角度去理解。

先说说聚合，它是一种弱关联，大概意思就是整体和部分可以独立存在。如果我们换个角度，可以看成是数据库的级联操作。

就拿小组和组员来说，删除某个小组的时候，把该组的组员也删除，这显然是不科学的，因为小组和组员是一种弱关联，小组可以拥有任意一个组员，一个组员也可以去任意一个小组，这个小组不存在了，可以去另一个小组，它们没有必然的关联，可以称为聚合。

因此，我们在设计数据库的时候，往往不会设置级联删除，也就是说，删除小组时不会删除组员。

UML图表示如下：

空心菱形表示聚合，指向one端。

再说说组合，组合是一种强关联，大概意思是整体和部分不可分割，不能独立存在。同样从级联操作理解。

就拿学生和学生证来说，假如某个学生退学，不再属于这个学校，那么可以考虑将该学生信息删除，删除的时候，学生对应的学生证信息也会被删除，在此处可以加级联删除。因为学生证属于某个学生专有的信息，学生不存在了，学生证又不能让他人使用，因此是一种强关联，可以称为组合。

UML图表示如下：

最后要谈的是依赖关系。

假如A类的某个方法中，使用了B类，那么就说A类依赖于B类，它们是依赖关系。

A类的某个方法使用B类，可能是方法的参数是B类，也可能是在方法中获得了一个B类实例。但无论是哪种情况，B类在A类中都是以局部变量的形式存在的。

因此，A类中有B类型的局部变量，就说A类依赖于B类。

UML图表示如下：

虚线箭头表示依赖，箭头指向被依赖的类。

综上，有一个简单的判断原则：某个类以成员变量的形式出现在另一个类中，二者是关联关系；某个类以局部变量的形式出现在另一个类中，二者是依赖关系。

注意：本文为了方便讲解，一直是拿类当例子，这并不是一种好的设计思维。实际开发中，为了更好的实现"开-闭原则"，一般都是定义接口，依赖于接口，依赖于抽象，而不是根据具体编程，希望读者不要被小菜误导！！

原文链接：https://www.cnblogs.com/igoodful/p/9441316.html

Association关联关系表现为变量(has a )。类与类之间的联接，它使一个类知道另一个类的属性和方法。例如如果A依赖于B，则B体现为A的全局变量。关联关系有双向关联和单向关联。双向关联：两个类都知道另一个类的公共属性和操作。单向关联：只有一个类知道另外一个类的公共属性和操作。大多数关联应该是单向的，单向关系更容易建立和维护，有助于寻找可服用的类。

参考链接：https://blog.csdn.net/wdjxxl/article/details/79608796

2.组合和聚合

菱形代表的意思就是全体 - 部分的关系。也就是说不管实心还是空心，都代表全体 - 部分 / part - of 的含义。

空心，全体和部分的连接可以是宽松的，代表聚合关系，全体和部分可以相互脱离独立存在。
实心，全体和部分的连接是强关联，代表组合关系。组合也是关联关系的一种，一种比聚合关系强的关系。组合关系中的部分类不能独立于整体类存在。整体类和部分类有相同的生命周期。

参考链接：https://blog.csdn.net/huuinn/article/details/78176946

3.泛化

在上图中，空心的三角表示继承关系（类继承），在UML的术语中，这种关系被称为泛化（Generalization）。Person(人)是基类，Teacher(教师)、Student(学生)、Guest(来宾)是子类。
若在逻辑上B是A的“一种”，并且A的所有功能和属性对B而言都有意义，则允许B继承A的功能和属性。
例如，教师是人，Teacher 是Person的“一种”（a kind of ）。那么类Teacher可以从类Person派生（继承）。
如果A是基类，B是A的派生类，那么B将继承A的数据和函数。

如果类A和类B毫不相关，不可以为了使B的功能更多些而让B继承A的功能和属性。
若在逻辑上B是A的“一种”（a kind of ），则允许B继承A的功能和属性。

参考链接：https://blog.csdn.net/gz153016/article/details/49641847