UML - 技术栈

UML整体类型

随着软件带来的价值增加，寻找自动化软件生产技术，来提高软件质量，减少成本和提高开发效率。自动化生产软件技术包含有组件化，可视化编程，模式和框架。

同时，也在寻找管理复杂系统的技术。特别是，需要解决反复出现的体系结构问题，例如物理分布、并发性、安全性、负载平衡和容错。统一建模语言（UML）被设计用来解决这些需求。

统一建模语言（UML）是一种通用的可视化建模语言，旨在提供一种标准的方法来可视化系统的设计。

UML是开发面向对象软件和软件开发过程中非常重要的组成部分。使用UML可以帮助项目团队进行交流，探索潜在的设计，并验证软件的体系结构设计。

UML为许多类型的图提供了一种标准符号，这些图可以大致分为三大类：行为图、交互图和结构图。

类图

类图是一种静态结构图，通过显示系统的类、它们的属性、操作（或方法）以及类之间的关系来描述系统的结构。

类符号

一个class包含三部分：

class名

类的名称出现在第一个分区中。

class属性

属性显示在第二个分区中。
属性类型显示在冒号之后。
属性映射到代码中的成员变量（数据成员）。

class操作

操作显示在第三个分区中。它们是类提供的服务。
方法的返回数据类型显示在方法名末尾的冒号之后。
方法参数数据类型显示在参数名称后面的冒号后面。
操作映射到代码中的类方法。

关系

实例化层次关系

关联

一个类的对象和另一个类的对象存在连接，一个类的属性指向另一个类（或多个）实例。

例如：汽车和司机，一辆车对应一个特定的司机，一个司机可以驾驶多辆车。

聚合

聚合关系是更加具体的一种关联关系，它是"has a"的关联关系。它是一种代表部分整体关系的关联。表示类的整体和部分之间的关系，成员对象是整体对象的一部分，但成员对象可以独立于整体对象而存在。

组合

组合关系是一种更强的聚合关系，其中聚合控制其聚合元素的生命周期。整体与部分的关系，但整体与部分不能分离。组合关系表示类的整体和部分之间的关系，整体和部分具有一致的生命周期。一旦整体对象不存在，部分对象也就不存在了，它们都将在同一生命中死去。

聚合关系与组合关系对比

组合关系

表示整体部分的关系，如发动机是汽车的一部分。
当容器被销毁时，容器内的内容也会被销毁，如大学和它包含的院系。

聚合关系

表示整体与部分的关系，如软件与数据库的关系，软件包含数据库，数据库也可以被其他软件使用。
当容器被销毁时，容器内的内容通常不会被销毁，如教授有学生；当教授离开大学时，学生们并没有随教授一起离开。

因此，聚合关系通常是"目录"包含，以区别于组合的"物理"包含。

汽车有一个发动机，发动机是汽车的一部分。发动机不能作为单独的部件存在，不能从汽车上分离出来。

一个池塘有0个或多个鸭子，而一个鸭子至多有一个池塘（一次）。鸭子可以独立于池塘而存在，例如它可以生活在湖泊附近。当我们摧毁一个池塘时，我们通常不会杀死所有的鸭子。

类层次关系

继承

继承，用于描述父类和子类之间的关系。

在继承关系中，子类继承父类的所有函数，父类拥有所有的属性、方法和子类。子类除了包含与父类相同的特性，还包含自己的特性。

Student类和Professor类继承了Person类。

实现

实现（Implementation）主要用于指定interface与实现class之间的关系。

interface（包括abstract class）是方法的集合。类中的方法实现接口声明的所有方法。

如：汽车和船都是交通工具，交通工具只是一种移动工具的抽象概念，船和船实现了具体的移动功能。

通用层次关系

依赖

依赖关系可以是一种较弱的绑定形式，表明一个类依赖于另一个类，因为它在某个时间点使用了另一个类。如果独立类是依赖类的方法的参数变量或局部变量，则一个类依赖于另一个类。有时两个类之间的关系非常弱。它们根本不是用成员变量实现的。相反，它们可以作为成员函数参数实现的。

依赖关系是一个"使用"关系。一个特定事物的改变可能会影响其他使用它的事物，并且当需要表明一个事物使用另一个事物时使用依赖项。这辆车依靠汽油。如果没有汽油，汽车将无法行驶。

类图例子

组件图

组件和模块的区别

模块和组件都是封装特定功能一个集合。模块是一个逻辑组织集合，用于管理代码的逻辑，把一个复杂系统代码组装成一个个模块，使代码逻辑清晰，易于维护扩展与复用。如财务模块，人力模块。组件是一个物理上的组织集合，顾名思义，软件系统组件是系统的一个完整独立的部件。

例如，在下面的图中，我们展示了一组模块，其中每个模块嵌入了一组类：

在上图中，尽管类被分成多个模块，但它们并没有按照下面的截图进行物理分离。

例如，我们在应用服务器上部署了两个物理组件，

MyWeb.war是Web层上的物理封装。
MyEJB.jar是业务层上的物理封装。

软件抽象粒度层次结构

抽象的软件粒度层次如下：

想象一下，如果只是使用基本数据开发软件系统，代码是很难维护和阅读的。将小的、简单的、功能有限的、目的抽象的东西组合成更大的、更复杂的、功能更强的、目的更明确的东西。将软件系统不同层次抽象出来使开发更容易，更快，更简单和更安全。

组件图

组件图用于对系统的物理方面进行建模，组件图本质是类图一种变形。与类图不同的是，组件图关注的是系统的组件，对一个系统的静态实现视图建模。

组件图把系统分解成不同层次的子功能。每个组件是整个系统的职责明确的特定功能，并且与外部交互。

上面的例子展示了一个较大组件的内部组件：

数据（帐户和检查ID）通过右侧的端口流入组件，并被转换为内部组件可以使用的格式。右边的接口被称为必需的接口，它表示组件执行其职责所需的服务。
然后，数据通过各种连接传递到其他几个组件，然后在左侧的端口输出。左边的那些接口被称为提供的接口，它表示要由展示组件交付的服务。
重要的是要注意，内部组件被一个大的"盒子"包围着，这个"盒子"可以是整个系统本身（在这种情况下，右上角不会有组件符号），也可以是整个系统的子系统或组件（在这种情况下，"盒子"是组件本身）。

组件图的基本概念

在UML 2中，一个组件被绘制成一个矩形，其中有垂直堆叠的可选分隔。在UML 2中，组件的高级抽象视图可以建模为：