班级图
在软件工程， 一个班级图在里面统一的建模语言（UML）是一种静态结构图，它通过显示系统的结构来描述系统的结构课程，它们的属性，操作（或方法）以及对象之间的关系。
班级图是面向对象造型。它用于一般概念建模应用程序的结构，以及详细的建模，将模型转化为编程代码。课堂图也可以用于数据建模.[1]类图中的类代表主要元素，应用程序中的交互以及要编程的类。
在图中，类用包含三个隔间的框表示：
- 顶部隔间包含班级的名称。它以粗体和中心印刷，首字母已大写。
- 中间隔间包含类的属性。它们是左对齐的，第一个字母是小写。
- 底部隔层包含类可以执行的操作。它们也被左对齐，第一个字母是小写。
在系统的设计中，在类图中确定了许多类并将其分组在一起，以帮助确定它们之间的静态关系。在详细的建模中，概念设计的类别通常分为子类。
为了进一步描述系统的行为，可以通过状态图或者UML状态机.[2]
成员
UML提供了表示类成员的机制，例如属性和方法，以及有关它们等构造函数的其他信息。
能见度
要指定类成员的可见性（即任何属性或方法），必须将这些符号放在成员名称之前：[3]
+ | 上市 |
- | 私人的 |
# | 受保护 |
~ | 包裹 |
一个派生的属性是一种属性，其价值（或值）是从其他信息中产生或计算的，例如，使用其他属性的值。
派生的属性以其名称为先于前向斜线'/'显示。[4]
范围
UML指定了两种类型的范围适用于成员：实例和班级，后者由下划线的名称.[5]
- 实例成员范围范围为特定实例。
- 属性值在实例之间可能有所不同
- 方法调用可能会影响实例的状态（即更改实例的属性）
- 班级成员在许多编程语言中通常被认为是“静态”。范围的范围是类本身。
- 所有实例的属性值都是相等的
- 方法调用不会影响分类器的状态
要指示成员的分类器范围，必须强调其名称。否则，默认情况下假设实例范围。
关系
关系是一个一般术语，涵盖了类和对像图上发现的特定类型的逻辑连接类型。UML定义以下关系：
实例级关系
依赖性
一个依赖性是一种关联，在依赖模型元素和独立模型元素之间存在语义联系。[6]如果对一个元素的定义（服务器或目标）的定义更改可能会导致另一个元素（客户端或源）的更改，则它存在于两个元素之间。该关联是单向的。依赖关系显示为一条虚线，带有开放箭头，该箭头指向供应商。
协会
一个协会代表一个链接家族。通常将二进制关联（具有两端）表示为线。协会可以链接任何数量的类。与三个链接的关联称为三元协会。可以命名协会，并且可以用角色名称，所有权指标，多重性，可见性和其他属性装饰协会的末端。
有四种不同类型的关联：双向，单向，聚集（包括组成聚集）和反射性。双向和单向关联是最常见的关联。
例如，飞行类别与平面类别相关联。协会代表两个类别之间共享的静态关系。
聚合
聚合是“具有”关联关系的变体；聚集比关联更具体。它是代表部分或部分关系的关联。如图所示，教授“有”课程要教。作为一种关联，可以命名聚合，并具有与关联所能相同的装饰。但是，聚合可能不超过两个类别。它必须是二进制协会。此外，实施过程中的聚合和关联之间几乎没有差异，该图可能会完全跳过聚合关系。[7]
聚合当课程是其他类的集合或容器时，可能会发生，但是包含的类没有强大的生命周期依赖性在容器上。当容器被破坏时，容器的内容仍然存在。
在嗯，图形表示为空洞的钻石形状在包含的类上，带有将其连接到包含类的单行。总体上是语义上的扩展对象，在许多操作中被视为单位，尽管实际上它是由几个较小的对象制成的。
作品
组成关系的UML表示形式显示为填充连接类（ES）与包含类的线的包含类末端的钻石形状。
组成和聚合之间的差异
- 组成关系
- 1.试图代表现实世界的整个部分关系时，例如发动机是汽车的一部分。
- 2.当容器被破坏时，内容物也会被破坏，例如大学及其系。
- 聚集关系
- 1.表示软件或数据库关系时，例如汽车型号ENG01是CAR Model CM01的一部分，作为引擎ENG01，也许也是不同汽车型号的一部分。[8]
- 2.当容器被破坏时，内容物通常不会被破坏，例如教授有学生；教授去世时，学生不会与他们一起死。
因此，聚集关系通常是“目录”的遏制，以将其与构图的“物理”遏制区分开。
班级关系
概括/继承
它表明两个相关类之一（子类）被认为是对方的一种专业形式（超级类型）和超类被认为是子类的概括。实际上，这意味着子类型的任何实例也是超类的实例。在此形式的概括树中发现了一个示例性的树生物分类：人类是猿猴，这是一个子类哺乳动物， 等等。“ a a is a a b'一词最容易理解这种关系（人是哺乳动物，哺乳动物是动物）。
概括的UML图形表示是空心三角形将其连接到一个或多个子类型的线的超类端（或线的树）上的形状。
象征实现（子类）_______▻（超类）
概括关系也称为遗产或者“是”关系。
这超类（基类）在概括关系中也称为“父母”，超类，基类， 或者基本类型.
这亚型在专业关系中也称为“孩子”，子类，派生的类，派生类型，继承类， 或者继承类型.
请注意，这种关系与生物父母的关系没有任何相似之处：这些术语的使用非常普遍，但可能会产生误导。
- A是B
- 例如，“橡木是一棵树”，“汽车是一种车辆”
概括只能显示在类图和用例图.
实现/实现
在UML建模中，实现关系是两个模型元素之间的关系，其中一个模型元素（客户端）意识到（或执行）另一个模型元素（供应商）指定的行为。
实现的UML图形表示是界面端的空心三角形形状虚线将其连接到一个或多个实施者的行（或行树）。在虚线的接口端，将其连接到用户的接口端，使用了一个普通的箭头头。在组件图中，使用了球形插座图形约定（实施者暴露了球或棒棒糖，而用户显示插座）。实现只能显示在类或组件图上。实现是将客户元素与供应商元素联系起来的类，接口，组件和软件包之间的关系。类/组件和接口之间的实现关系表明，类/组件实现了接口提供的操作。
象征实现（实施者）-------▻（接口）
一般关系
依赖性
依赖性可以是一种较弱的键形式，表明一个类取决于另一类，因为它在某个时间点使用它。一个类取决于另一个类别，如果独立类是相关类方法的参数变量或局部变量。有时，两个类之间的关系非常薄弱。它们根本没有成员变量实现。相反，它们可以作为成员函数参数实现。
多重性
这种关联关系表明（至少）两个相关类别之一就是参考另一个。这种关系通常被描述为“ A有B”（母猫有小猫，小猫有母猫）。
关联的UML表示是连接两个关联类的行。在行的两端都有可选的符号。例如，我们可以使用箭头指出，从箭头尾部可见尖端。我们可以通过放置球来指示所有权，这是该角色的名称以及该角色的作用，以及多重性该实体的实例（从另一端的角度，参与关联的对像数量范围）。
| 0 | 没有实例（稀有） |
| 0..1 | 没有实例或一个实例 |
| 1 | 正是一个实例 |
| 1..1 | 正是一个实例 |
| 0 ..* | 零或更多实例 |
| * | 零或更多实例 |
| 1 ..* | 一个或多个实例 |
分析刻板印象
实体
实体类模拟系统处理的长寿命信息，有时甚至与信息相关的行为。它们不应被识别为数据库表或其他数据商店。
它们被绘制为圆圈，短线连接到圆的底部。另外，可以使用“实体”刻板印像在类名称上方绘制它们作为普通类。
也可以看看
- 相关图
参考
- ^火花，杰弗里。“ UML中的数据库建模”。检索9月8日2011.
- ^Scott W. Ambler（2009）UML 2班级图。 WebDoc 2003-2009。 2009年12月2日访问
- ^UML参考卡，版本2.1.2，Holub Associates，2007年8月，检索3月12日2011
- ^“ UML派生的属性是属性，该属性是从其他信息中生成或计算的，例如使用其他属性”.www.uml-diagrams.org。检索2019-01-24.
- ^OMG统一建模语言（OMG UML）上层建筑，版本2.3：2010年5月。检索2010年9月23日。
- ^Fowler（2003）UML蒸馏：标准对象建模语言的简短指南
- ^“ UML教程第1部分：课程图”（PDF）。存档原本的（PDF）在2007-01-03。检索2015-07-18.
- ^古德温，大卫。“建模和模拟，第26页”（PDF）.沃里克大学。检索11月28日2015.
