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图表示如下：
虚线箭头表示依赖，箭头指向被依赖的类。
综上，有一个简单的判断原则：某个类以成员变量的形式出现在另一个类中，二者是关联关系；某个类以局部变量的形式出现在另一个类中，二者是依赖关系。
注意：本文为了方便讲解，一直是拿类当例子，这并不是一种好的设计思维。实际开发中，为了更好的实现"开-闭原则"，一般都是定义接口，依赖于接口，依赖于抽象，而不是根据具体编程，希望读者不要被小菜误导！！
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
原文地址：https://www.cnblogs.com/aidata/p/11450229.html