班级图
在软件工程中，统一建模语言（UML）中的类图是一种静态结构图，它通过显示系统的类，其属性，操作（或方法）以及对象之间的关系来描述系统的结构。
类图是面向对象建模的主要构建块。它用于对应用程序结构以及详细建模的一般概念建模，将模型转化为编程代码。类图也可以用于数据建模。类图中的类代表主要元素，应用程序中的交互以及要编程的类。
在图中，类用包含三个隔间的框表示：
- 顶部车厢包含班级的名称。它以粗体和中心印刷，首字母已大写。
- 中间隔间包含类的属性。它们是左边的，第一个字母是小写。
- 底部车厢包含类可以执行的操作。它们也被左对齐，第一个字母是小写。
在系统的设计中，在类图中识别了许多类并将其分组在一起，以帮助确定它们之间的静态关系。在详细的建模中，概念设计的类别通常分为子类。
为了进一步描述系统的行为，可以通过状态图或UML状态机对这些类图进行补充。
成员
UML提供了表示类成员的机制，例如属性和方法，以及有关它们（例如构造函数）的其他信息。
能见度
要指定类成员的可见性（即任何属性或方法），必须将这些符号放在成员名称之前：
+ |
民众 |
- |
私人的 |
# |
受保护 |
~ |
包裹 |
派生属性是一种属性，其值（或值）是通过使用其他属性的值从其他信息中产生或计算的。
派生的属性以其名称为先于前向斜线'/'显示。
范围
UML指定成员的两种类型的范围：实例和类，后者由下划线的名称表示。
-
实例成员范围范围为特定实例。
- 属性值在实例之间可能有所不同
- 方法调用可能会影响实例状态（即更改实例的属性）
-
在许多编程语言中，班级成员通常被认为是“静态”。范围的范围是类本身。
- 所有实例的属性值都是相等的
- 方法调用不会影响分类器的状态
要指示成员的分类器范围，必须强调其名称。否则，默认情况下假设实例范围。
关系
关系是一个一般术语，涵盖了类和对像图上发现的特定类型的逻辑连接类型。 UML定义以下关系：
实例级关系
依赖性
依赖性是一种关联类型，在依赖模型元素和独立模型元素之间存在语义联系。如果对一个元素的定义（服务器或目标）的定义更改可能会导致另一个元素（客户端或源）的更改，则它存在于两个元素之间。该关联是单向的。依赖关系显示为带有开放箭头的虚线，该箭头从客户端指向供应商。
协会
协会代表一个结构联系的家族。二进制关联表示为两个类之间的实线。反思性关联是班级和自身之间的二元关联。两个以上类之间的关联表示为与每个相关类别的实线连接的钻石。三个类之间的关联是三元协会。更多类之间的关联称为N- ARY关联。
可以命名关联，并且可以用角色名称，聚合指标，多样性，可见性，可通道和其他属性来装饰关联的末端。例如，点符号允许在一个类的一侧用一个小点表示关联端由另一侧所有。
关联有三种类型：简单关联，共享聚合，复合聚合（组成）。可以在一个或多个方向上导航协会。不必明确指定导航性。在类文档的一侧，可以从相反的一侧有效地到达班级文档的敞开箭头。显示了单向导航，在班级侧面的关联线上有一点交叉，无法达到。例如，飞行类别与平面类别的双向相关联。
聚合
聚集是“具有”关联关系的变体。聚集比关联更具体。它是代表部分或部分关系的关联。如图所示，教授“有”课程要教。作为一种关联类型，可以命名聚合，并具有与关联相同的装饰。但是，聚合可能不超过两个类别。它一定是二进制协会。此外，实施过程中的聚合和关联之间几乎没有差异，并且该图可能会完全跳过聚合关系。
当类是其他类的集合或容器时，可能会发生聚合，但是包含的类对容器的生命周期依赖性不强。当容器被破坏时，容器的内容仍然存在。
在UML中，它以图形方式表示为包含类的空心钻石形状，并带有将其连接到包含类的单线。总体上是语义上的扩展对象，在许多操作中被视为单位，尽管物理上是由几个较小的对象制成的。
作品
复合聚集（俗称组成）关系是一种更强的聚集形式，其中聚集体控制其聚集的元素的生命周期。图形表示是连接包含类（ES）与包含类的类的类末端的填充钻石形状。
组成和聚合之间的差异
- 组成关系
- 1.试图代表现实世界的整个零件关系时，例如发动机是汽车的一部分。
- 2.当容器被销毁时，内容也将被销毁，例如大学及其部门。
- 聚合关系
- 1.代表软件或数据库关系时，例如汽车模型引擎ENG01是CAR型CM01的一部分，作为引擎ENG01，也许也是不同汽车型号的一部分。
- 2.当容器被销毁时，内容通常不会被破坏，例如教授有学生；当教授离开大学时，学生不会与教授一起离开。
因此，聚集关系通常是“目录”的遏制，以将其与构图的“物理”遏制区分开。与简单关联相比，UML 2没有为聚合指定任何语义。
班级关系
概括/继承
它表明两个相关类别（子类）之一被认为是另一种（超级类型）的一种专业形式，并且超类被认为是子类的概括。实际上，这意味着子类型的任何实例也是超类的实例。在生物学分类中发现了这种形式的概括树的示例性树：人类是Simian的一个子类，它是哺乳动物的子类，依此类推。 “ a a is a a b”一词最容易理解这种关系（人是哺乳动物，哺乳动物是动物）。
概括的UML图形表示是将其连接到一个或多个子类型的线（或线上树）上的超类端（或线的树）上的空心三角形。
symbolic of realization (subclass) _______▻ (superclass)
概括关系也称为继承或“是”关系。
概括关系中的超类（基类）也称为“父” ，超类，基类或基本类型。
专业关系中的子类型也称为“儿童” ，子类，派生类，派生类型，继承类或继承类型。
请注意，这种关系与生物父母的关系没有相似之处：这些术语的使用非常普遍，但可能会产生误导。
- A是B
- 例如，“橡木是一棵树”，“汽车是一种车辆”
概括只能显示在类图和用例图上。
实现/实现
在UML建模中，实现关系是两个模型元素之间的关系，其中一个模型元素（客户端）意识到（或执行）另一个模型元素（供应商）指定的行为。
实现的UML图形表示是将其连接到一个或多个实现者的虚线（或线的树）接口端（或线的树）上的空心三角形。在虚线的接口端，将其连接到用户的接口端，使用了一个普通的箭头头。在组件图中，使用了球形插座图形约定（实现者暴露了球或棒棒糖，而用户显示插座）。实现只能显示在类或组件图上。实现是将客户元素与供应商元素联系起来的类，接口，组件和软件包之间的关系。类/组件和接口之间的实现关系表明，类/组件实现了接口提供的操作。
symbolic of realization (implementer) -------▻ (interface)
一般关系
依赖性
依赖性可能是债券的较弱形式，表明一个类取决于另一个类，因为它在某个时间点使用它。一个类取决于另一个类别，如果独立类是相关类方法的参数变量或局部变量。有时，两个类之间的关系非常薄弱。它们根本没有成员变量实现。相反，它们可能被用作成员函数参数。
多重性
这种关联关系表明（至少）两个相关类别中的一个参考另一个。这种关系通常被描述为“ A有B”（母猫有小猫，小猫有母猫）。
关联的UML表示是连接两个相关类的线。在行的两端都有可选的符号。例如，我们可以使用箭头指出，从箭头尾部可见尖端。我们可以通过放置球来表明所有权，即通过提供角色名称的角色扮演的角色以及该实体的多样性（从角度来参与关联的对像数量范围另一端）。
| 0 | 没有实例（稀有） |
| 0..1 | 没有实例或一个实例 |
| 1 | 正是一个实例 |
| 1..1 | 正是一个实例 |
| 0..* | 零或更多实例 |
| * | 零或更多实例 |
| 1..* | 一个或多个实例 |
分析刻板印象
实体
实体类模拟系统处理的长寿命信息，有时甚至与信息相关的行为。它们不应被识别为数据库表或其他数据商店。
它们被绘制为圆圈，短线连接到圆的底部。另外，可以使用“实体”刻板印象符号在类名称上方绘制为普通类。
也可以看看
- 相关图