uml类图用什么表达 uml类图详解

UML用例图、类图

首先需要先了解一下对象之间的关系，以及它们对应的符号

uml类图用什么表达 uml类图详解

uml类图用什么表达 uml类图详解

通常对象之间的关系可以分为以下几类：

1、泛化/继承（Generalization）：实线+三角形空心

相当于类继承，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

2、关联关系（association） ：实线箭头

关联关系：指的是类与类之间的联接，它使一个类知道另一个类的属性和方法（实例变量体现）。A类依赖于B对象,并且把B作为A的一个成员变量, 则A和B存在关联关系.

关联可以是双向的，也可以是单向的。两个类之前是一个层次的，不存在部分跟整体之间的关系。

单向：只能从A通过属性导航到B，B不能导航到A。

双向：A可以通过属性导航到B，B也可以通过属性导航到（双向即为嵌套）

3、聚合关系（aggregtion）棱形空心+实线

聚合(aggregation)关系是关联关系的一种,是强关联关系,是整合和部分的关系,是has-a的关系.

聚合关系也是通过成员对象来实现,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象单独存在.(可替换)

4、依赖(Dependency) 虚线+箭头

依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。

动物依赖氧气和水。调用新陈代谢方法需要氧气类与水类的实例作为参数

5、实现关系（realization）虚线三角形空心

实现关系：指的是一个class类实现 intece接口（可以实现多个接口）的功能；实现是类与接口之间常见的关系；

在Ja中此关系通过关键字implements明确标识。

6，组合关系（comition）

组合是一种强的‘拥有’关系，是一种contains-a的关系，体现了严格的部分和整体关系，部分和整体的生命周期一样。

示例：

鸟和翅膀就是组合关系，因为它们是部分和整体的关系，并且翅膀和鸟的生命周期是相同的。

一张完整的类图：

参考： UML用例图 ， UML类图 ， UML中的类图及常见类图关系

UML类图的介绍

在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。建模工具也主要根据类图来产生代码。类图在UML的9个图中占据了一个相当重要的地位。James Rumbaugh对类的定义是：类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象系统中重要的构造块。类图显示了一组类、接口、协作以及他们之间的关系。在UML中问题域终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。类加上他们之间的关系就构成了类图，类图中还可以包含接口、包等元素，也可以包括对象、链等实例。接口在类图中通过版型来表示<>，下面的介绍将主要介绍类，接口和类类似。

UML设计中分析类图和设计类图的区别

UML类图的概念

一、概述

UML类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。UML类图是定义其他图的基础，在UML类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。

UML类图包括7个元素：类（Class）、接口（Intece）、协作（collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）以及实现关系（Realization）。

二、类

类定义了一组有着状态和行为的对象。其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用有身份的对象之间的关系表示。行为由作来描述，方法是作的实现。对象的生命期则由附加给类的状态机来描述。

1、 名称：类的名称是每个类中所必有的构成元素。

2、 属性（Attribute）

（1） 可见性：类中属性的可见性主要包括公有（public）、私有（Private）和受保护（Protected）。在UML中，公有类型的用“+”表达，私有类型用“-”表达，而受保护类型则用“#”表达。UML的类中不存在默认的可见性，如果没有显示任何一种符号，就表示没有定义该属性的可见性。

（2） 属性名：按照UML的约定，单字属性名小写。如果属性名包含多个单词，这些单词要合并，且除了个单词外其余单词的首字母要大写。

（3） 属性字符串。属性字符串用来指定关于属性的其他信息，例如某个属性应该是的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。

（4） 类属性。属性也可以作为一个类属属性来定义，这就意味着此属性被该类的所有对象共享。在UML类图中，类属性带有一条下划线。

3、 作。类的作是对类的对象所能做的事务的抽象，相当于一个服务的实现。

4、 职责：在作部分下面的区域，可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本，写一个短语，一个句子等。在UML中，把职责列在UML类图底部的分隔栏中。

5、 约束。说明类的职责是消除二义性的一种非形式化的方法，形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个花括号括起来的自由文本。

三、接口

接口包含作但不包含属性，且它没有对外界可见的关联。

四、类之间的关系

类之间的关系常见的有四种：依赖关系、泛化关系、管理关系、实现关系。

UML对象图

一、概述

UML对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是UML类图在某一时刻的实例。

在UML中，对象图使用的是与UML类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中可以是对象也可以是类，连线表示对象之间的关系：

二、UML类图和对象图的区别

UML建模|类图

类图（Class Diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。

类图中通常包含以下内容：

1）类。

2）接口。

3）协作。

4）依赖、关联、泛化和实现关系。

UML（Unified Modeling Language，统一建模语言）中有4种关系：依赖、关联、泛化和实现。

下面介绍下类、泛化关系、实现关系、关联关系、依赖关系的描述和表示。

1） 类

类（Class）封装了数据和行为，是面向对象的重要组成部分，它是具有相同的属性、作、关系的对象的总称。

（类对应的UML图是一个矩形，分为三层，顶层的是类名，中间层的是属性，层的是方法。

属性的表示方式为：【可见性】【属性名称】：【类型】=｛缺省值，可选｝

方法的表示方式为：【可见性】【方法名称】（【参数列表】）：【类型】

可见性都是一样的，“-”表示private，“+”表示public，“#”表示protected。）

2） 泛化关系

泛化关系（Generalization）也叫继承关系，用于描述父子类之间的关系，父类又称为基类或者超类，子类又称为派生类。

（实线，带空心三角形的在父类那边）

3） 实现关系

实现关系（Implementation），是对接口和实现类之间的关系，<>表示一个接口，接口没有属性（有属性也要注意都是常量），而且所有的作都是抽象的，只有作的声明没有作的实现。

（虚线，带空心三角形的在接口那边）

4） 关联关系

关联关系（Association）是类与类之间常见的一种关系，它是一种结构化的关系，表示一类对象与另一类对象之间的关系。关联关系用实线连接，如一个类的对象作为另一个类的成员变量。

关联关系中还有聚合关系和组合关系，都是表示整体和部分之间的关系。不同的是，

在 聚合关系（Aggregation） 中，成员对象是整体的一部分，但是成员对象可以脱离整体对象存在。

（实线，带空心菱形的在整体那边）

在 组合关系（Comition） 中，整体对象可以控制成员对象的生命周期，一旦整体对象不存在，成员对象也不存在。

（实线，带实心菱形的在整体那边）

5） 依赖关系

依赖关系（Dependency）是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系，大多数情况下依赖关系体现在某个类A的方法使用了另一个类B的对象作为参数。

（虚线，带箭头，由依赖的一方指向被依赖的一方，如A指向B）

依赖关系通常有三种方式来实现：1、将一个类的对象作为另一个类中方法的参数；2、在一个类的方法中将另一个类的对象作为其对象的局部变量；3、在一个类的方法中调用另一个类的静态方法；

UML关系图

在设计的时候多多少少都避免不了接触UML设计图。我们在此简单的介绍下UML设计图的相关内容。

依赖用虚线箭头表示。

依赖表明的是一种松耦合的关系。一般作为某个成员函数的返回值、形参、方法局部变量等的调用。

比如：

关联关系用实线加箭头表示，类之间的关系比依赖要强。学生与老师是关联的，学生可以不用电脑，但是学生不能没有老师。如下图所示：

关联与依赖的对比：

相似之处：

关联暗示了依赖，二者都用来表示无法用聚合和组合表示的关系。

区别：

（1）发生依赖关系的两个类都不会增加属性。其中的一个类作为另一个类的方法的参数或者返回值，或者是某个方法的变量而已。

发生关联关系的两个类，类A成为类B的属性，而属性是一种更为紧密的耦合，更为长久的持有关系。

（2）从关系的生命周期来看，依赖关系是仅当类的方法被调用时而产生，伴随着方法的结束而结束。关联关系当类实例化的时候产生，当类对象销毁的时候关系结束。相比依赖，关联关系的生存期更长。

关联关系有单向关联、双向关联、自身关联、关联等等。其中后三个可以不加箭头。

单向关联

聚合关系使用实线加空心菱形表示。聚合用来表示集体与个体之间的关联关系。例如班级与学生之间存在聚合关系，类图表示如下：

复合关系使用实线加实心菱形表示。组合又叫复合，用来表示个体与组成部分之间的关联关系。例如学生与心之间存在复合关系，类图表示如下：

（1）聚合关系没有组合紧密。

学生不会因为班级的解散而无法存在，聚合关系的类具有不同的生命周期；而学生如果没有心将无法存活，组合关系的类具有相同的生命周期。

这个从构造函数可以看出。聚合类的构造函数中包含另一个类的实例作为参数，因为构造函数中传递另一个类的实例，因此学生可以脱离班级体存在。组合类的构造函数包含另一个类的实例化。因为在构造函数中进行实例化，因此两者紧密耦合在一起，同生同灭，学生不能脱离心而存在。

（2）信息的封装性不同。

在聚合关系中，客户端可以同时了解Classes类和Student类，因为他们是的。

在组合关系中，客户端只认识Student类，根本不知道Heart类的存在，因为心类被严密地封装在学生类中。

理解聚合与复合的区别，主要在于聚合的成员可，复合的成员必须依赖于整体才有意义。

泛化是学术名称，通俗来讲，泛化指的是类与类之间的继承关系和类与接口之间的实现关系。

继承关系使用直线加空心三角形表示。类图结构如下：

类接口的实现关系使用虚线加空心三角形表示。类图结构如下：

关于 关联 ， 聚合 ， 组合 之间的关系我们需要特殊说明下。关联主要代表的是同级别的内容，比如人和电脑。而聚合和组合之间则表示的是整体和部分的逻辑。而组合的耦合关系是要紧于聚合的。比如我们在聚合的例子中(Student和Class的关系)，Student是作为Class的一个构建函数入参来构建的。而在组合的关系中(Student和Heart的关系)， Heart这个成员变量是在构建函数中new出来的。所以Heart的生命周期和Student的生命周期是一致的。

参考资料：

认识 UML 类关系——依赖、关联、聚合、组合、泛化

详解八大UML类图符号的表示法

UML图的关系及箭头使用

近UML类图使用较多，有些关系和箭头的使用在这里记载一下

用来描述系统的结构化设计，类图是常见的一种UML图，用类图可以表示类，接口之间的静态结构关系。

元素分为两种，

关系分为六种

依赖关系是一种上级的概念，一个类拥创建并使用另外一个类的实例（绑定）、一个类拥有另外一个类的实例（使用）、子类实现父类（泛化）等一个类中引入了另外一个类的关系都算作是依赖。在类图中，这种关系用虚线箭头表示，箭头指向为依赖的方向。

泛化就是类之间的继承，子类实现父类就是一种泛化，类图中使用空心三角形+实线表示

聚合是一种较弱的耦合关系，比如在一个List包含了某一类，这就算做聚合，类图中用空心菱形+实线表示

着重描述整体与部分之间的关联，车需要轮子，那么车这个类就组合了轮子类，这种关系在类图中用实心菱形+实线表示

关联关系分为双向关联和单向关联，比如手机上有很多app，这就是手机单向关联了app，人和组织是一种双向的，一个人可能属于很多组织，组织也会有很多人，这就是一种双向关联，在类图中，这种关联关系用实线加开口箭头表示

描述实现类与所实现的接口之间的关系，使用空心三角形+虚线来表示

软件设计师UML知识点：第七章类图

前言

类图是在面向对象的系统模型中使用得普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。

你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。

类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。

术语和概念

类图：类图是一组类、接口和协作以及他们之间的关系构成的。

类图通常包含如下的内容：

l 类

l 接口

l 协作

l 依赖关系、继承关系、关联关系

同其他的图一样，类图也可以包含注解和限制。

类图中也可以包含包和子系统，这两者用来将元素分组。有时后你也可以将类的实例放到类图中。

注：组件图和分布图和类图类似，虽然他们不包含类而是分别包含组件和。

你通常通过下面三种方式使用类图：

1，为系统词汇建模型

为系统的词汇建模实际上是从词汇表中发现类，发现它的。

2，模型化简单的协作

协作是指一些类、接口和其他的元素一起工作提供一些合作的行为，这些行为不是简单地将元素加能得到的。例如：当你为一个分布式的系统中的事务处理过程建模型时，你不可能只通过一个类来明白事务是怎样进行的，事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。

3，模型化一个逻辑数据库模式

想象模式是概念上设计数据库的蓝图。在很多领域，你将想保存持久性数据到关系数据库活面向对象的数据库。你可以用类图为这些数据库模式建立模型。

通用建模技术

没有类是单独存在的，他们通常和别的类协作，创造比单独工作更大的语义。因此，除了捕获系统的词汇以外，还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作。

l 确定你建模的机制。机制代表了部分你建模的系统的一些功能和行为，这些功能和行为是一组类、接口和其他事物相互作用的结果。

l 对于每个机制，确定类、接口和其他的参与这个协作的协作。同时确定这些事物之间的关系。

l 用场景来预排这些事物，沿着这条路你将发现模型中忽略的部分和定义错误的部分。

l 确定用这些事物的内容来填充它们。对于类，开始于获得一个（类的职责），然后，将它转化为具体的属性和方法。

图 7-1 模型化简单的协作

图7-1是一个自治机器人的类图。这张的图焦点聚集那些让机器人在路上行走的机制对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类：SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系，和CollisionSensor有1对n的关系。

在这个系统中其实还有很多其他的类，但这张图的重点是放在那些将机器人移动的类上的。在其他的图中你可能也会看到这些类。通过将焦点放在不通的功能上，可以获得从不通的角度对整个系统的认识，终达到认识整个系统。

很多系统都是有持久性数据的，也就是说要将这些数据保存到数据库中以便下一次使用。通常你会使用关系型数据库或面向对象的数据库，或其它类型的数据库来保存数据。UML很适合为逻辑数据库模式建模。

UML的类图是E-R图（为逻辑数据库建模的通用工具）的超集，尽管E-R图的重点是数据，类图的扩展允许模型化行为。在物理数据库中这些逻辑作一半转化为触发器或存储过程。

确定那些状态比其生命周期要长的类。

创建一张包含这些类的图，标记它们为持久性的。

详细定义它们的属性。

对于使得物理数据库设计复杂的模式如：循环关系、1对1关系、N元关系，考虑创建中间抽象来使得逻辑结构复杂。

详细定义这些类的作，特别是那些访问数据和涉及数据完整性的方法。

如果可能的话使用工具来将你的逻辑设计转化为物理设计。