| 类是一个分类器，它描述一组共享相同的对象。
类显示为包含类名的实心轮廓矩形，并且可选地具有由包含特征或分类器其他成员的水平线分隔的分隔区。
由于class是最广泛使用的分类器，因此不需要在类名的上方添加guilmets中的“class”关键字。类名应居中并以粗体显示，类名的第一个字母大写（如果字符集支持大写）。
类客户 - 禁止显示详细信息
类的特性是属性和操作。
当类显示为三个分隔符时，中间分隔符包含属性列表，底部分隔符包含操作列表。属性和操作应该在平面上保持对齐，名称的第一个字母用小写
SearchService类
- 分析级别详信息
功能表示的特征可以是单独考虑的分类器实例（非静态）或分类器本身（静态）。同一功能在一个上下文中不能是静态的，在另一个上下文中不能是非静态的。
关于静态特征，可以识别两种替代语义。静态功能可能包括：
不同特征分类器的不同值，或所有特色分类器的值相同。
根据这种语义，允许继承静态特征的值，但UML 2 不需要。
静态功能有下划线 - 但只有名称。省略号（…）作为功能列表的最后一个元素，表示存在其他功能，但不显示在该列表中。
类的属性由类拥有的属性实例表示。其中一些属性可能表示二进制关联的可导航端。
类的对象必须包含属于该类成员的每个属性的值，具体取决于属性的特性，例如属性的类型和多重性。
SearchService类-实现级别详细信息。
CreateEngine是静态操作
属性或操作可以按可见性分组。在这种情况下，可以为具有相同可见性的多个功能提供一次可见性关键字或符号。
SearchService类-按可见性分组的属性和操作
可以提供附加隔室以显示其他细节，例如约束，或仅仅划分特征。
UML中的类可以用作其他分类器的命名空间，包括类、接口、用例等。嵌套的分类器仅在包含类的命名空间中可见。
在UML2.5中，通过扩展封装分类器和行为分类器，类变得结构化、封装和行为化。因此，任何类都可能具有一些内部结构和端口。
库服务是通过SearchPort端口封装的结构化类。
在结构化类范围内定义的分类器嵌套将分类器的可见性限制在包含结构化类的命名空间范围内，从而支持通过端口进行封装（信息隐藏）。
结构化类网上购物，具有购物端口和内部结构。
抽象类
UML 2.4提到抽象类，但没有提供定义。我们可以将抽象分类器的定义与抽象类联系起来。我们可以假设在UML
2.x中，抽象类没有完整的声明，并且“通常”不能被实例化。抽象类用于其他分类器（例如，作为泛化关系的目标）。
UML 2.4没有解释“不完整的类声明”，也没有解释它是否与抽象操作的概念相关——这个概念也出现在UML
1.4.2中，在UML 2.x中没有。
尝试创建抽象类的实例是未定义的-某些语言可能使此操作非法，其他语言可能创建用于测试的部分实例。
抽象类的名称以斜体显示。
SearchRequest类是抽象类
抽象分类器也可以使用名称后面或下面的关键字abstract来显示。
修订在UML 1.4.2中，抽象类被定义为不能直接实例化的类。抽象类只存在于要从其继承并支持重用其声明的功能的其他类中。任何对象都不能是抽象类的直接实例，尽管对象可以是通过非抽象子类间接引用的实例。
标准类原型
有几个标准的UML原型应用于类：
标准UML类原型
|
名称 |
描述 |
| "辅助"-Auxiliary |
辅助类是支持另一个更为中心或基本类的类，通常通过实现辅助逻辑或控制流来实现。辅助支持的类可以使用焦点类显式定义，也可以通过依赖关系隐式定义。
辅助类通常用于在设计阶段指定组件的辅助业务逻辑或控制流。 |
| “焦点”-Focus |
Focus是为一个或多个支持类定义核心逻辑或控制流的类。支持类可以使用辅助类显式定义，也可以通过依赖关系隐式定义。
焦点类通常用于在设计阶段指定核心业务逻辑或控制组件流。 |
| "实现"-ImplementationClass |
在某些编程语言（例如，C++、SimalTalk、Java）中实现一个类，其中实例可能不具有一个以上的类。
这与UML类不同，对于UML类，一个实例可能一次有多个类，并且可能随着时间的推移而增加或减少类，并且一个对象可能动态地有多个类。
一个实现类可以实现许多不同的类型。实现类的物理属性和关联不必与它实现的任何分类器的物理属性和关联相同，并且实现类可以根据其物理属性和关联为其操作提供方法。 |
| "元类"-Metaclass |
一个类，其实例也是类。 |
| “类型”Type |
Type是一个类，它指定对象的域以及适用于对象的操作，而不定义这些对象的物理实现。
类型可以具有属性和关联。类型操作的行为规范可以使用例如活动图来表示。一个对象最多可以有一个实现类，但是它可以符合多种不同的类型。 |
| “工具”Utility |
实用工具是只具有类范围的静态属性和操作的类。因此，实用程序类通常没有实例。
Math是实用程序类-具有静态属性和操作（带下划线） |
注意，在UML2.4.1中，原型和应用的原型的命名约定被更改为大写的第一个字母。您仍然可以在小写字母中看到原型，例如《focus》、《type》，因为切换到新符号需要一些时间。
在几个UML工具中有几种非标准但常规使用的类定型，包括IBM
Rational Software Architect（RSA）和Sparx Enterprise
Architect： “边界”， “控制”， “实体”。
这些类定型是RSA中分析配置文件的一部分，默认使用分析模型模板应用。刻板印象大致对应于模型
- 视图 - 控制器（MVC）设计模式的部分，其中边界表示视图，控制是控制器，实体对应于模型。
|
名称 |
描述 |
| “边界”Boundary |
边界是表示某些系统边界的定型类或对象，例如用户界面屏幕、系统界面或设备界面对象。它可以用于开发的分析或概念阶段，以捕获与正在开发的系统交互的用户或外部系统。它通常用于序列图中，以演示用户与系统的交互。
边界被画成一个圆圈，与左边的一条垂直线相连，它也可以显示为一个带有?boundary?原型的类。 |
| “控制”Control |
控件是一个定型的类或对象，用于对控制流或行为中的某些协调进行建模。一个或多个控制类可以描述用例实现。系统控制表示设计系统的动态，通常描述一些“业务逻辑”。
控件被绘制为一个顶部带有嵌入箭头的圆。它也可以显示为具有《control》原型的类。
注意，UML具有适用于类的标准?focus?原型，这些类可用于在设计期间指定核心业务逻辑或控制组件流。 |
| “实体”Entity |
实体是表示某些信息或数据的定型类或对象，通常但不一定是持久的。
实体被绘制为一个圆，线附着在圆的底部。它也可以显示为具有?实体?原型的类。
业务实体代表业务人员在进行业务时处理、使用或处理的一些“事物”、项目、文档或信息。商业实体的例子包括医生办公室的处方、餐馆的菜单、机场的机票。
系统实体表示系统处理的一些信息或数据，通常但不一定是持久的。
注意，在UML 1.4.2中，“实体”原型表示一个被动类，即对象本身不启动交互的类。UML
2.0更新了“实体”标准原型，以适用于组件并表示持久信息的业务概念。 |
类模板
UML类可以模板化或绑定。
下面的示例显示了 具有两个正式模板参数的模板类Array 。第一个模板参数T是一个无约束的类模板参数。第二个模板参数n是整数表达式模板参数。模板结合
为结合的类的顾客用替代类的客户，并与整数值24。因此边界n中的不受约束的T级，结合的类的顾客是Customer类24个的对象的数组。
|
