UML 类图综合指南

类示例

狗有状态——颜色、名字、品种以及行为——摇摆、吠叫、进食。对象是类的一个实例。

UML 类表示法

类表示封装状态（属性）和行为（操作）的概念。每个属性都有一个类型。每个 操作 都有一个 签名。 类名是 唯一的强制性信息。

班级名称：

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

类属性：

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

类操作（方法）：

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

类关系

一个类可能涉及与其他类的一种或多种关系。关系可以是以下类型之一：（有关关系的图形表示，请参见右图）。

关系类型	图示
继承 （或泛化）： 表示“is-a”关系。 抽象类名称以斜体显示。 SubClass1 和 SubClass2 是 Super Class 的特化。 带有空心箭头的实线，从子类指向父类
简单关联： 两个对等类之间的结构链接。 Class1 和 Class2 之间存在关联 连接两个类的实线
聚合：一种特殊类型的关联。它代表关系的“一部分”。 Class2 是 Class1 的一部分。 Class2 的许多实例（用 * 表示）可以与 Class1 相关联。 Class1 和 Class2 的对象具有不同的生命周期。 连接到复合类的关联端带有未填充菱形的实线
组成：一种特殊类型的聚合，当整体被破坏时，部分被破坏。 Class2 的对象与 Class1 一起生存和死亡。 Class2 无法独立存在。 与复合材料类相连的关联处带有实心菱形的实线
依赖： 如果对一个类的定义的更改可能导致对另一个类的更改（但不是相反），则存在于两个类之间。 Class1 依赖于 Class2 带有空心箭头的虚线

关系名称

• 关系名称写在关联行的中间。
• 当您大声朗读它们时，好的关系名称是有意义的：
  • “每个电子表格都 包含 一些单元格”，
  • “表达式 求 值”
• 它们通常有一个 小箭头来显示 读取关系的方向，例如，表达式计算为值，但值不计算为表达式。

关系——角色

• 角色是关联的方向性目的。
• 角色写在关联行的末尾，描述了该类在关系中的作用。
  • 例如，一个单元格与一个表达式相关。关系的本质是表达式是单元格的 公式 。

可导航性

箭头表示，给定一个参与关系的实例，是否可以确定与其相关的另一个类的实例。

上图表明，

• 给定一个电子表格，我们可以找到它包含的所有单元格，但是
  • 我们无法从单元格中确定它包含在哪个电子表格中。
• 给定一个单元格，我们可以获得相关的表达式和值，但是
  • 给定一个值（或表达式），我们找不到那些是属性的单元格。

类属性和操作的可见性

在面向对象的设计中，属性和操作有一个可见性的表示法。UML 标识了四种类型的可见性：  public、  protected、  private和 package。

类中属性和操作名称前的 +、-、# 和 ~ 符号表示属性和操作的可见性。

• + 表示公共属性或操作
• – 表示私有属性或操作
• # 表示受保护的属性或操作
• ~ 表示包属性或操作

类可见性示例

在上面的例子中：

• MyClassName 的 attribute1 和 op1 是公共的
• attribute3 和 op3 受到保护。
• attribute2 和 op2 是私有的。

下面为不同类的成员显示了每种可见性类型的访问权限。

多样性

每个类有多少个对象参与关系和多重性可以表示为：

• 正好一个 – 1
• 零或一 – 0..1
• 许多 – 0..* 或 *
• 一个或多个 – 1..*
• 确切数字 – 例如 3..4 或 6
• 或复杂的关系——例如 0..1、3..4、6.* 表示除 2 或 5 之外的任意数量的对象

多重性示例

• 要求：一个学生可以参加多门课程，许多学生可以参加一门课程。
• 在下面的示例中， 类图 （左侧）描述了上述静态模型的需求陈述，而对象图（右侧）显示了课程注册的快照（类图的实例）分别是软件工程和数据库管理课程）

聚合示例 – 计算机和部件

• 聚合是关联的一种特殊情况，表示“包含”层次结构
• 聚合是父类，组件是子类

继承示例——细胞分类

• 继承是表示“种类”层次结构的关联的另一个特例
• 继承通过引入分类法来简化分析模型
• 子类继承父类的属性和操作。

类图 – 图表工具示例

类图也可能附有类或关系的注释。注释以灰色显示。

在上面的例子中：

我们可以通过阅读以下几点来解释上述类图的含义。

1. 形状是一个抽象类。它以斜体显示。
2. 形状是一个超类。Circle、Rectangle 和 Polygon 是从 Shape 派生的。换句话说，圆就是形状。这是一种泛化/继承关系。
3. DialogBox 和 DataController 之间存在关联。
4. 形状是窗口的一部分。这是一种聚合关系。形状可以在没有窗口的情况下存在。
5. 点是圆的一部分。这是一种组合关系。没有圆，点就不能存在。
6. 窗口依赖于事件。但是，Event 不依赖于 Window。
7. Circle 的属性是半径和中心。这是一个实体类。
8. Circle 的方法名称是 area()、circ()、setCenter() 和 setRadius()。
9. Circle 中的参数 radius 是 float 类型的 in 参数。
10. Circle 类的方法 area() 返回一个 double 类型的值。
11. Rectangle 的属性和方法名是隐藏的。图中的其他一些类也隐藏了它们的属性和方法名称。

处理复杂系统——多类图还是单类图？

不可避免地，如果您正在对大型系统或大型业务领域进行建模，那么您必须考虑许多实体。我们应该使用多个还是单个类图来建模问题？答案是：

• 与其在单个类图上对每个实体及其关系进行建模，不如使用多个类图。
• 将系统划分为多个类图使系统更易于理解，特别是如果每​​个图都是系统特定部分的图形表示。

软件开发生命周期中类图的观点

我们可以在软件开发生命周期的不同开发阶段使用类图，  并且通常通过在我们前进的过程中逐步在三个不同的视角（详细程度）中对类图进行建模：

概念视角：图表被解释为描述现实世界中的事物。因此，如果您从概念的角度来看，您将绘制一个表示所研究领域中概念的图表。这些概念自然会与实现它们的类相关。概念视角被 认为与语言无关。

规范视角：这些图被解释为描述具有规范和接口但不承诺特定实现的软件抽象或组件。因此，如果您从规范的角度来看，我们正在 查看软件的接口，而不是实现。

实施视角：这些图被解释为以特定技术和 语言描述软件实施。因此，如果您从实施的角度来看，我们正在 研究软件实施。