Python设计模式 - UML - 总览

说到设计模式就不得不涉及建模思想,说到建模思想自然而然会应用UML,目前业界开源的UML工具很多,用起来也非常便捷。近几年来随着软件应用领域开发模式转向快速迭代试错,UML在敏捷开发,尤其是web及mobile开发领域应用越来越少。

就国内软件行业发展现状来说,稳定成熟的商业软件凤毛麟角,初具雏形的互联网App大行其道,竞争中的公司更看重的是快速占领市场,小团队快速迭代试错,而不是长期、精心打磨同一款软件产品,所以注重统一规范、充分需求分析、严密框架设计的UML显得相对繁琐,自然会被灵活敏捷的各类开发过程文档取代,比如建模草图、wiki、看板、注释等轻文档。

对于敏捷开发和传统开发来说,不管是否广泛使用UML工具,建模总是必不可少的,可以帮助我们理清思路,更好地分析和设计易扩展、易维护的软件框架。从当前市面上看,基于图表的UML是熟悉建模思想及设计模式的最好选择。

UML简介

简单地说,UML的核心是图表,是与具体编程语言无关的设计规范,用来定义、细化、编写、构造软件系统中的要素,以可视化的图形定义软件开发中涉及到的参与者、实体、流程及它们之间的调用关系,覆盖软件开发所有阶段的抽象表述。

UML的优势在于分析、建模和整理设计思路。

建模思想

在最终设计和实现软件系统之前,通常都需要划一定的时间在不同的层次上抽象开发模型,稍微上点规模的项目,团队协作是必不可少了,开发模型也可以帮助团队成员更好地沟通交流,所以不管是草图还是UML,我们都需要对开发中的项目构建一些直观、明确的文档化记录。建模的出发点有以下几个方面:

- 更好地理解用户需求,避免曲解或遗漏
        - 更好地进行系统分析和设计,避免返工
        - 帮助团队交流和项目协同开发,避免埋坑
        - 帮助提高开发速度和质量,降低沟通成本

UML常用图

UML常用图有13种,大体可以归类为结构图(Structure Diagrams)和行为图(Behavior Diagrams)。

  • 结构图:强调的是系统构建的静态结构,包括类图、对象图、包图、组件图、部署图、组合结构图

  

  类图(Class Diagram)

   类图是最常用的UML图,也是其他UML图的基础。类图用来显示类、接口以及它们之间的静态结构和关系。

  类图中的元素:类,接口、关系、协作、约束、注释、包

  类图中的关系:泛化、实现、关联、聚合、组合、依赖

  对象图(Object Diagram)

    对象图可以看作是类图在系统某一时刻的镜像。

    对象图中的元素:对象、链接、包

     对象图中的关系:泛化、实现、关联、聚合、组合、依赖

  包图(Package Diagram)

    包图是对各个包及包之间关系的描述,展现系统中模块与模块之间的依赖关系。

     包图中的元素:类、接口、组件、节点、协作、用例及其他包

     包图中的关系:泛化、细化、依赖

  组件图(Component Diagram)

    组件图又称构建图,用来建模系统的各个组件,包括源代码文件、二进制文件、脚本文件、可以执行文件之间的关系

     组件图中的元素:构件、接口、关系、端口、连接器

     组件中的关系:依赖、泛化

  部署图(Deployment Diagram)

    部署图是展示运行系统中的软件和硬件的物理架构及处理节点的组件分布情况

     部署图中的元素:结点、结点实例、结点类型、结点容器、物件、连接

     部署图中的关系:依赖、关联

  组合结构图(Composite Structure Diagram)

    组合结构图用来描述某一部分及其成员的组成结构关系,成员之间的连接关系,与外部组件的接口及协作

     组合结构图的元素:部件、连接件、端口

     组合结构图的关系:关联、组合、泛化、依赖

  • 行为图:强调系统中对象的动态行为,包括用例图、活动图、状态图、交互概述图、通信图、时序图、时间图

  

  用例图(Use Case Diagram)

    用例图从客户角度展现需求模型中希望哪些参与者提供什么样的用例功能,以及功能模块之间的调用关系

    用例图中的元素:参与者、用例、关系

     用例图中的关系:关联、包含、扩展、泛化

  活动图(Activity Diagram)

    活动图用来描述用例功能所要求进行的活动以及活动之间的约束关系,有利于对象间的流程控制

    活动图的元素:活动状态、动作状态、控制点、转移、开始节点、终止节点、对象、对象流、泳道

     活动图的关系:控制转移、分支与合并、分叉与汇合

  状态图(State Machine Diagram)

    状态图用来描述特定对象所有可能的状态,以及由各事件引发的状态之间的转换变化,强调从状态到状态的控制流

     状态图的元素:状态、转换、事件、活动、动作

     状态图的关系:状态与状态之间有组合、转换关系

  交互概述图(Interaction Overview Diagram)

    交互概述图是将活动图和时序图嫁接在一起的图,合并了时序图片段和控制流构造

     交互概述图的元素:活动状态、动作状态、控制点、转移、开始节点、终止节点、对象、对象流、泳道

     交互概述图的关系:控制转移、分支与合并、分叉与汇合

  通信图(Communication)

    通信图描述发送和接受消息的对象之间的合作及调用关系

     通信图的元素:对象、链、消息

     通信图的关系:通过链让消息在不同对象间传递

  时序图(Sequence Diagram)

    时序图也叫序列图或顺序图,用来描述对象之间传送消息的时间顺序

     时序图的元素:角色、对象、生命线、控制焦点、消息

     时序图的关系:时序图对象之间有约束关系

  时间图(Timing Diagram)

    用来描述单个或多个对象随时间变化或维持的状态

     时间图的元素:时间约束、持续时间约束、生命线、状态、条件、事件

     时间图的关系:事件之间有时间约束关系,状态之间有转移关系

 

UML常用符号

  • actor: 角色/参与者

  • usecase:用例

  • class diagram: 类图 抽象类用斜体表示

  • object diagram:对象图

  • interface:接口

  • package: 包

  • start, end: 开始、结束

  • state: 状态

  • component: 构件

  • node:节点

   

  • note: 注释

  • <<include>>:包含关系

  • <<extend>>:扩展关系

  • generalization:泛化

  • dependency:依赖关系 注意箭头指向:B依赖A

  • aggregation:聚合

  • composition:组合

  • association:关联

        multiplicity: 多重性

*            - 1    仅为1

              - *  从0到无穷大

              - 0..1  0 或者 1

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

UML扩展与细化

正如本文开始所述,UML在快速迭代的互联网和移动互联网时代似乎没有以前应用那么广泛,更多时候开发人员在隐性使用UML特性,比如说绘制类、包、用例、组件等草图辅助设计,但不会花费大量时间制作正式的UML图例同时因为需求的不断变化而频繁返工。而且面向接口编程在框架设计中应用越来越多,但接口特性在UML2.0中并没有得到相应扩展和细化,所以当前软件开发过程,尤其是web & mobile app的开发过程的特点需要UML进一步升级以适应软件工程的发展。对于UML的扩展与细化,个人有以下方面不太成熟的看法,仅供参考:

  • 根据已实现代码生成UML各类图:其实这种功能在不少IDE中已经提供了,但是功能还不够全面和易用
  • 细化UML图在接口方面的规范和契约:这个尝试在UML中暂时还没有发现,在其他开发流程和工具中倒是有抽象且细化接口导入、导出、约束等契约
  • 在UML中扩展新的分支xUML(根据xUML自动生成代码):这个需要丰富的代码库支撑,暂时还不太容易做到,一旦抽象出基础代码库,应该会大大提升开发效率
  • 淘汰老化UML概念:UML常用的十三种图中,常用的也就几种,其他的规范和契约虽然都在但实用性越来越小,所以需要适当瘦身

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

时间: 2024-09-30 10:25:48

Python设计模式 - UML - 总览的相关文章

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

简介 类图是面向对象分析和设计的核心,用来描述系统各个模块中类与类之间.接口与接口之间.类与接口之间的关系,以及每个类的属性.操作等特性,一般在详细设计过程中实施. 类图本身就是现实世界的抽象,是对系统中各种概念进行建模,并描绘出它们之间的关系,所以类图关注的对象就是元素及元素之间的关系. 类图建模步骤 - 抽象出类实体 - 识别出类的主要属性 - 画出类之间的关系 - 对各个类进行分析.梳理.设计 类图的元素 类图中包含以下几种模型元素:类.接口.关系.协作.注释.约束.包. 类 在UML的图

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

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

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

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

Python设计模式 - UML - 部署图(Deployment Diagram)

简介 部署图也称配置图,用来显示系统中硬件和软件的物理架构.从中可以了解到软件和硬件组件之间的物理拓扑.连接关系以及处理节点的分布情况. 部署图建模步骤 - 找出需要进行部署的各类节点,如网络硬件设备.服务器硬件设备.及部署在硬件设备上的软件系统等 - 确定各类节点之间的连接关系及通信方式 - 从性能.可扩展性.可维护性.可移植性角度确定各类节点的数目和部署方式 - 绘制部署图,将artifact分配给各个节点 部署图主要元素 部署图中的主要元素有节点.物件和连接.其中节点根据其状态不同又有节点

python设计模式之门面模式

一.结构型设计模式 门面模式与单例模式,工厂模式不同,它是一种结构型模式. 结构型模式描述如何将对象和类组合成更大的结构 结构型模式是一种能够简化设计工作的模式,它能找出更简单的方法来认识或表示实体之间的关系. 结构型模式是类和对象模式的综合体.类模式通过继承来描述抽象,从而提供更有用的程序接口,而对象模式描述了如何将对象联系起来从而组合成更大的对象. 二.理解门面设计模式 它为子系统中的一组接口提供一个统一的接口,并定义一个高级接口来帮助客户端通过更简单的方式使用子系统. 门面所解决的问题是,

Python设计模式——设计原则

1.单一职责原则:每个类都只有一个职责,修改一个类的理由只有一个 2.开放-封闭远程(OCP):开放是指可拓展性好,封闭是指一旦一个类写好了,就尽量不要修改里面的代码,通过拓展(继承,重写等)来使旧的类满足新的需求,而不是修改一个类里面的代码. 3.依赖倒转原则:高层模块不应该依赖底层模块,两个都应该依赖抽象:抽象不应该依赖细节,细节应该依赖抽象.底层模块例如很多工具类,例如专门用于管理sql连接的类,管理文件,管理socket连接的类,高层类指具体实现需求的类.高层类和底层类都不应该相互依赖,

Python设计模式——工厂方法模式(FactoryMethod)

需求:有一个学雷锋活动,有买米和扫地两个内容,参与的人有大学生和社区志愿者,他们各自的方法不一样. 如果用简单工厂模式实现: #encoding=utf-8 __author__ = '[email protected]' class LeiFeng(): def buy_rice(self): pass def sweep(self): pass class Student(LeiFeng): def buy_rice(self): print '大学生帮你买米' def sweep(self

python设计模式浅析

今天简单聊聊python的设计模式,GOF设计模式(c++)和Head first design pattern(Java)是两本设计模式的经典,基本可以照搬在python上面,但是你会发现python有很多它特有的东西,比如它并没有多个构造函数,相对应的它有classmethod,所以python设计模式还是有值得聊聊的地方. 构造函数: python2: class Person(object): def __init__(self, name): self.name = name pyth

Python设计模式(4):行为型

承接Python设计模式(3):结构型 13. Interpreter(解释器) 意图:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 适用性: 当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时,可使用解释器模式.而当存在以下情况时该模式效果最好: 该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理.此时语法分析程序生成器这样的工具是更好的选择.它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节