Python设计模式 - UML - 类图(Class Diagram)

简介

类图是面向对象分析和设计的核心，用来描述系统各个模块中类与类之间、接口与接口之间、类与接口之间的关系，以及每个类的属性、操作等特性，一般在详细设计过程中实施。

类图本身就是现实世界的抽象，是对系统中各种概念进行建模，并描绘出它们之间的关系，所以类图关注的对象就是元素及元素之间的关系。

类图建模步骤

　　　　- 抽象出类实体

　　　　- 识别出类的主要属性

　　　　- 画出类之间的关系

　　　　- 对各个类进行分析、梳理、设计

类图的元素

类图中包含以下几种模型元素：类、接口、关系、协作、注释、约束、包。

• 类

　　在UML的图形表示中，类的表示法是一个矩形，有三格组成，分别是类名、类属性、类操作。抽象类中的类名及抽象方法都用斜体表示。

　　　- 类名：首字母大写

　　　- 类属性：格式为可见性 属性名：类型 =默认值，如-name: String

　　　　　　　　可见性包括四种：

　　　　　　　　　　　　+　   public

　　　　　　　　　　　　-　　private

　　　　　　　　　　　　#　   protected

　　　　　　　　　　　　*　　package

　　　　　　　　属性名：单字属性名小写；多字属性名出第一个单词外其余单词的首字母大写

　　　- 类操作：格式为可见性 操作名(参数)： 返回值类型，如+getName(): String

• 接口

　　在UML的图形表示中，接口的表示法是分为两种：圆形表示法和构造型表示法。

　　 接口由两栏组成，第一栏顶端是接口名称，第二栏是接口方法。接口无属性只包含操作，且没有对外可见的关联。

　　　　　　- 圆形表示法

　　

　　　　　　- 构造型表示法

• 关系

类图中类与类之间有泛化、依赖、关联、聚合、组合关系；接口与接口之间有继承关系；类与接口之间有实现关系。这些关系本身就是类图中的元素，用不同的连线表示。

　　　　　　- 泛化关系

　　　　　　- 依赖关系

　　　　　　- 关联关系

　　　　　　- 聚合关系

　　　　　　- 组合关系

　　　　　　- 实现关系

　　　类图中的关系较为复杂，以下分别详述。

　　　　

• 协作

　　协作是指一些类、接口、关系等元素提供的交互行为，能够协助其他元素执行活动、实现功能的辅助类。

• 注释

　　对某些类和接口进行注释。

• 约束

　　指定某些类和接口要满足的一个或多个规则，UML中使用花括号括起来的自由文本标识。

• 包

　　UML中的包直接对应java中的包，用来表示层次和组织内容。

类图的关系

类图中类与类、接口与接口、类与接口之间的关系有四大类：依赖、关联、泛化、实现，其中关联有存在聚合、组合两个特例。

• 依赖

　　依赖是一种单向使用关系，如果一个类为实现某一功能，使用了其他类作为参数或者调用了其他类的方法，这两个类之间就产生了依赖关系。

　　 依赖关系表现在在一个类中使用另一个类作为局部变量或者方法参数，以及对另一个类静态方法的调用。

　　 依赖关系又有五种细分类型：绑定(Binding)依赖、实现(Realization)依赖、使用(Usage)依赖、抽象(Abstraction)依赖、授权(Permission)依赖

　　　　　绑定依赖

　　　　　绑定<<bind>>: 以模板参数指定值，生成一个新的模型元素

　　　　　关键字<<bind>>应用于较高级的依赖，用于绑定模板以创建新的模型元素，箭头指向被绑定的模板

　　　　　实现依赖

　　　　   实现<<realize>>：实际上是两个类/接口之间的契约，也就是说一个类/接口只定义抽象的行为，另一个类定义具体的结构和行为。

　　　　　使用依赖

　　　　　使用依赖表示客户端使用提供者提供的服务帮助实现自身的功能，通常有以下几种具体应用：

　　　　　　　　- 使用<<use>>：比较宽泛的概念，表示一个类的行为或实现会影响到另一个类的行为或者实现

　　　　　　　　- 调用<<call>>：在一个类的方法中调用另一个类的操作

　　　　　　　　- 参数<<parameter>>：一个类作为另一个类的方法参数

　　　　　　　　- 发送<<send>>：用一个类中的方法把信号发送到另一个类

　　　　　　　　- 实例化<<instantiate>>：用一个类的方法创建了另一个类的实例

　　　　　　　　

　　　　　授权依赖

　　　　　授权依赖表示一个包/类/元素对另一个包/类/元素进行访问的权限和能力，包含访问、导入、友元等依赖关系：

　　　　　　　　- 访问<<access>>：允许一个包/类访问另一个包/类的内容

　　　　　　　　- 导入<<import>>：允许一个包/类访问另一个包/类的内容

　　　　　　　　- 友元<<friend>>： 允许一个元素访问另一个元素

　　　　　抽象依赖

　　　　　抽象依赖表示客户端与提供者在不同抽象层次上的关系，包括跟踪、精化、导出等依赖关系：

　　　　　　　　- 跟踪<<trace>>：不同模型元素之间的非强相关连接

　　　　　　　　- 精化<<refine>>：由基本类分解出更明确、更精细的子类

　　　　　　　　- 导出<<derive>>：一个实例可以从另一个实例导出

　　　　　　　　

• 关联

　　关联是两个类之间或者类与接口之间的强依赖关系。可以是单向的，也可以是双向的。

关联关系一般长期性的、拥有性的关系，而且双方的关系一般是平等的，如学校与学生之间、老师与学生之间。被关联类B以类的属性形式出现在关联类A中，关联可以是单向的，也可以是双向的。

　　

　　关联关系在代码上体现为四种形式：

　　　　- 单向关联：单向拥有关系，只有一个类知道另一个类的属性和方法

　　　　- 双向关联：双向拥有关系，双方都知道对方的属性和方法

　　　　- 自身关联：自己关联自己，这种情况比较少但也有用到，如链表

　　　　- 多重性关联：表示两个类的对象在数量上的对应关系，多重性可在关联线上用数字范围表示

　　　　　　　　　　multiplicity: 多重性　　

　　　　　　　　　　　   1　   　　仅为1

　　　　　  　　　　　　 *　　　　从0到无穷大

　　　  　　　　　　0..1  　　0 或者 1

　　　　　　　　　　　　n..m 　　 [n, m]之间的任何数

　　　　

UML中使用直线箭头表示，箭头指向为被关联的类，从类A指向类B

单向关联

双向关联

自我关联

多重性关联

• 聚合

聚合关系是也是关联关系的特例。普通关联关系的两个类一般处于同一平等层次上，而聚合关系的两个类处于不同的层次，是整体与部分的关系。聚合关系中的整体和部分是可以分离的，生命周期也是相互独立的，如公司与员工之间。

　　UML中使用空心菱形+实线箭头表示，空心菱形边指向类School(整体)，实现箭头边指向部分类Student(部分)

• 组合

组合关系也是关联关系的特例，属于强聚合，本身也表示整体与部分的关系，但是组合关系中的整体和部分是不可分离的，整体生命周期的结束时也是部分的生命周期到头时。如人和大脑。

聚合和组合其实都是关联的特例，都是整体与部分的关系。它们的区别在于整体和部分是否可分离，聚合的两个对象之间是可分离的，且具有各自的生命周期，而组合的两个对象往往表现为一种同命相连的关系。

　　UML中使用实心菱形+实线箭头表示，实心菱形边指向类Person(整体)，实线箭头边指向类Brain(部分)

• 泛化

泛化指的是子类继承父类、或子接口继承父接口的功能并增加自己新功能的过程，是两个类之间耦合度最大的关系之一。父类称为基类或超类，子类也称为派生类。子类可以继承自抽象类或普通类。

　　UML中使用实线+空心箭头表示，箭头由子类指向父类、或子接口指向父接口

• 实现

实现关系是指一个类实现一个或多个接口功能的过程，这里的接口更多的是一种契约或规范。实现是两个类之间或类与接口之间耦合度最大的关系之一，在这种关系中，类实现了接口或接口类中所声明的操作。

　　UML中使用虚线+空心箭头表示，箭头由实现类指向接口

类图的高级特性

　　　　

• 抽象类

抽象类是不能直接实例化的类，UML中不论是抽象类名还是抽象方法都是以斜体表示。在不严格要求的文档中也可以普通类加<<abstract>>前缀的方式标识抽象类名和抽象方法。

　　因为是python设计模式，所以方法名采用了更pythonic的写法。

　　标准表示法

　　　构造表示法

　　　

• 模板类

UML中引入模板类的目的是应用泛型编程。在类模板声明的时候根据占位符或参数来定义类，而不用说明属性、方法参数、方法返回值的实际类型。使用时通过实际值替代占位符或参数即可创建新类/方法/属性。

　　python因为是动态语言的原因，所以泛型在python中没有什么应用场景，以下以Java为例说明模板类的应用。

• 嵌套类

　　嵌套类是在类中定义的类，相应地把拥有嵌套类的类称为外部类。嵌套类和外部类之间耦合度更高，并且与外部类更加紧密，在UML中是Composition的另一种表示。

• 主动类

　　主动类是一种特殊的类，其对象至少拥有一个进程或线程，能够控制活动中的类。之所以使用主动类是因为开发中需要一些类来控制其他类的运行状态。

• 关联类

　　关联类既是关联又是类，它不仅像关联那样连接两个类，而且可以定义一组属于关联本身的特性。

类图注意事项

　　　　- 类图设计初期力求重点突出、简洁易懂，根据需求变化保持更新

　　　　- 类图中的元素名称应该直观、清晰、有意义，不同类的属性名尽量在全图中唯一

　　　　- 类图中多个元素之间有依赖关系时需避免循环依赖

　　　　- 类图中类属性尽量少避免整个图过于繁杂

　　　　- 类图中可适当使用注释使系统更清晰易懂

　　　　- 对于需求频繁变化的项目，可多使用草图进行组内沟通，节省开发和返工时间