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的另一种表示。

  • 主动类

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

  • 关联类

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

类图注意事项

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

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

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

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

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

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

原文地址:https://www.cnblogs.com/coolstream/p/9572846.html

时间: 2024-10-26 15:09:16

Python设计模式 - UML - 类图(Class Diagram)的相关文章

Python设计模式 - UML - 组件图(Component Diagram)

简介 组件图又称构建图,用于显示系统各组件及各组件关系的物理视图. 组件图通常包括组件.接口.关系.端口和连接器,用来显示程序代码中相应的模块.源文件或源文件集合之间的依赖和泛化关系. 组件图中的组件通常由类图中的一个或多个类(对象)实现为系统中的模块.源文件.过程文件或可执行文件,最终构成系统的绝大部分功能单元. 组件图建模步骤 - 确定系统有哪些对外接口或端口 - 确定系统要用到哪些组件,识别出系统中的重要模块.库文件.源代码文件.数据表或文件.可执行文件或文档等,将其建模为一个个组件 -

Python设计模式 - UML - 包图(Package Diagram)

简介 包图是对各个包及包之间关系的描述,展现系统中模块与模块之间的依赖关系.一个包图可以由任何一种UML图组成,可容纳的元素有类.接口.组件.用例和其他包等.包是UML中非常常用的元素,主要作用是分类.容纳其他元素.包与包之间的关系有泛化.细化和依赖,主要取决于包内部成员之间的关系. 包图建模步骤 - 分析系统的模型元素,运用分层设计把概念.语义和逻辑上相近的元素包含在同一个包中 - 对于每个包,分析包内每个元素的可访问属性,并标识出该元素的可见性 - 确定包与包中元素之间的泛化.细化.依赖关系

设计模式-UML类图的各符号含义(转)

UML类图的各符号含义 类图基本符号可拆分为虚线,箭头,实线,空心右三角,实心右三角,空心菱形和实心菱形.由这些基本的图形进行组合构成了类图的基本符号.这里要注意这几个符号的顺序,代表了类与类之间关系的耦合程 度.越向右耦合度越高. 其中虚线+箭头是表示即依赖的关系,实线+箭头表示关联的关系,虚线+空心右三角表示implements,实线+空心右三角表示的是泛化,即类的继承关系.实线+空心菱形表示的是聚合的关系,实线+实心菱形则表示 组合的关系. 另外一点是在看类图的时候要注意.类图的思想其实也

[设计模式]-UML类图的各符号含义

UML类图的各符号含义 类图基本符号可拆分为虚线,箭头,实线,空心右三角,实心右三角,空心菱形和实心菱形.由这些基本的图形进行组合构成了类图的基本符号.这里要注意这几个符号的顺序,代表了类与类之间关系的耦合程 度.越向右耦合度越高. 其中虚线+箭头是表示即依赖的关系,实线+箭头表示关联的关系,虚线+空心右三角表示implements,实线+空心右三角表示的是泛化,即类的继承关系.实线+空心菱形表示的是聚合的关系,实线+实心菱形则表示 组合的关系. 另外一点是在看类图的时候要注意.类图的思想其实也

java设计模式--UML类图

2016-06-07 22:46:16 下面简单介绍UML类图:(图是截取的,大家可以用UML工具去画) 1.描述类的类图 类:Person 属性:name   age   sex 访问权限:-  表示私有的private   +:表示公共的public  #:表示protected 方法: getName():String   setName(name:String)   getAge():int   setAge(age:int)   getSex():String   setSex(sex

大话设计模式---UML类图

 类图 两种接口图 继承类与实现接口 关联引用 聚合 组合 依赖

设计模式——1.概述&amp;UML类图和时序图

声明:设计模式相关文章均整理修改自网络,原文地址:图说设计模式 学习设计模式的3个层次—— 1.熟悉所有设计模式: 2.能够用代码实现: 3.运用到工作的项目中. 设计模式指导软件开发,学习设计模式首先需要了解相关UML图,下面将对UML类图做相关介绍. 重点需要明白,类图中各个类之间的关系,各个类之间线条.箭头的含义. 应该能将类图所表达的含义和最终的代码对应起来. 一.从一个示例开始 请看下面的类图,类之间的关系是我们需要关注的: 1.车的类图结构为<<abstract>>,表

设计模式前言——UML类图

设计模式前言--UML类图 一.UML类图 1.类 类(Class)封装了数据和行为,是面向对象的重要组成部分,是具有相同属性.操作.关系的对象集合的总称.在系统中,每个类都具有一定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务.一个类可以有多种职责,设计得好的类一般只有一种职责.在定义类的时候,将类的职责分解成为类的属性和操作(即方法).类的属性即类的数据职责,类的操作即类的行为职责.设计类是面向对象设计中最重要的组成部分,也是最复杂和最耗时的部分.在软件系统运行时,类将被实例化成

设计模式之序章-UML类图那点事儿

设计模式之序-UML类图那点事儿 序 打14年年底就像写那么一个系列,用于讲设计模式的,代码基于JAVA语言,最早接触设计模式是大一还是大二来着,那时候网上有人给推荐书,其中就有设计模式,当时给我推荐的书我还隐约记得,叫GoF的,书名是<Design Patterns: Elements of Reusable Object-Oriented Software>,也即<设计模式>,机械出版社的将其翻译为<设计模式-可复用面向对象软件的基础>.至于为什么叫做GoF,那时候