UML关系总结——画uml图、流程图、软件结构图、类图、顺序图的方法

UML关系总结

[转载]

在UML类图中，常见的有如下几种关系:泛化（Generalization）,  实现（Realization）,关联（Association）,聚合（Aggregation）,组合(Composition)，依赖(Dependency)

 

1.泛化(Generalization)

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

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

2.实现（Realization)

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

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

3.关联（Association）

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

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

【代码体现】：成员变量

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

 

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

 

上图为自身关联：

 

4. 聚合（Aggregation）

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

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

【代码体现】：成员变量

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

 

 

5. 组合(Composition)

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

【代码体现】：成员变量

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

 

 

6. 依赖(Dependency)

【依赖关系】：是一种使用的关系,因此要尽可能不使用双向的互相依赖。

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

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

 

各类关系的强弱顺序：

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

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

 

画uml图、流程图、软件结构图、类图、顺序图的方法

[转载]

软件开发中，分析和设计时，文档的编写和思想的交流，常常要绘制各类各样的图。相对于人类的天然语言，描绘复杂结构，图具备直观和总体的特征，有着不可替代的表现力。

软件开发是创造性的劳动，开发人员几乎在每一分钟都要作出某些选择，每个选择都好像决定着最后的结果。绘图的时候也是如此，脑中有完整或不完整的想法，要清晰的表现出来时至关不容易。事实上，我发现许多老手不会画图。

在实践的过程当中，我总结了一些经验，得出了一些结论。

1. 不画没有必要的图。若是简单的文字就能说得很清楚，还画图干什么？对代码级别的细节，不要画图来表现；不要借助图来让你的文档得变大；画蛇莫要添足。

2. 忽略底层的细节。软件是一个多层的东西，一个图只展示恰当抽象层次之上的细节。一个过细的图，大量的信息会掩盖真正重要的东西。好比：在一个流程图上，不须要把“文件打开的错误判断”也做为一个分支画在图上，除非你“无聊到”要强调这个显而易见的异常处理；
  
3. 图不要太大。若是一个图上包含上百个对象，看起来不舒服，应该化整为零，使用多个图，每一个图描述不一样的部分。
  
4. 画纯种的图。图传递的信息应该明确，无歧义。必定要明确图中的各个组成元素都是什么东西，整个图要表现什么。尽可能使用规范的图。好比：流程图中，应关注控制的传递，不要有从文件中读取数据的数据流；软件结构图中，描述模块之间的父子关系的同时，不要有模块之间的数据流。我常见到这样的图：在图中既有“控制流”，也有“数据流”，不三不四，名之曰“示意图”。我的认为，交流时，这种示意图在白板上随手画画还能够，决不该该出如今正式的文档上。这些图中的控制流，实是一个模糊概念，A->B能够表示：1)A调用B，把控制传递给B；2）A启动B,把控制传递给B；3）A向B传递一个控制信号；4)有一个第三者调用A完成后，立刻调用B。

5. 图的布局要简洁，美观。我据说：书写大幅的毛笔字，特别讲究布局。一样道理，画软件图，尽可能密度分布均匀，减小连线的交叉。 为了减小连线的交叉， 一样的单元能够在图中出现屡次。

6. 其实并不须要完备的图。使用UML有三种方式：UML as sketch(草图)，使用不完备的图进行系统某一部分或某一方面的内容进行交流；UML as blueprint（篮图），经过完备的UML图表现详细设计的全部决定；UML as programming language，自动精确的UML图，直接编译成可执行的代码（如今好像尚未实现）。Martin Fowler说：使用UML绘制草图的人，真正关注UML的精髓（大师就是大师，说话就是不同）。所谓“不足胜有余”，无论什么图，图应该集中表现其关注的方面，恰当的忽略一些细节时必要的。类图中，每每没有必要包含类的全部函数合成员说明；在表现对象之间协做的顺序图中，大多时候也没有必要表现存在的分支和循环。
  
7. 全部的规则都是用来遵照和打破的。上面的全部道理，也并不是是不变的真理。可是，道理被打破之前，你应该了解它，熟悉它，批评它，忘记它（追求相似张三丰太极剑的境界）。古人云：事有反道而适权，伪经而和道者。笑傲江湖说：独孤九剑，无招胜有招。萧大侠：删繁就简，取精用宏。 规劝朋友也规劝本身：连有招的境界还没有达到，应该知道本身该作什么。

参考文章：

UML关系总结:

https://blog.csdn.net/woailuo453786790/article/details/51647011

画uml图、流程图、软件结构图、类图、顺序图的方法:

https://blog.csdn.net/claram/article/details/3026152