UML系统建模专题---1、UML概述和理论

2023-12-18 12:05:01

概述

什么是uml

Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言，
语言，也就是一个表达思想的符号约定。

uml的发展与版本

  • 建模语言出现在二十世纪70年代，80年代末开始迅速发展，建模语言达到了50多种，百家争鸣
  • 后来，Rumbaugh于1994年加入Booch所在的Rational公司，他们一起研究一种统一的方法
  • 一年后，Unified Method 0.8诞生
  • 经过他们三年的共同努力，UML0.9和UML0.91于1996年相继面世。
  • 此后UML创始人Booch等人，邀请计算机界的知名人士与企业IBM，HP，Microsoft，Oracle等对 UML进行评论，听取意见。
  • 1997年1月，Rational公司向OMG（对象管理组织）提交了UML1.0
  • 1997年11月，OMG宣布接受UML，认定为标准的建模语言
  • 1998年发布了UML 1.2
  • 1999年发布了UML 1.3
  • 2003年3月发布了UML 1.5
  • 2004年推出UML2.0

uml可以做什么

从命名上分析：统一、建模、语言

统一：没有规矩不成方圆，它指定了一种标准，一种约束，使得大家的表达变得一致。它被OMG（Object Management Group）所认可。

OMG是一个国际化的、开放成员的、非盈利性的计算机行业标准协会，该协会成立于1989年，他是软件行业中一个标准的认可。包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。uml成为他们工作中统一的沟通工具，用于充分理解和表达自己所关注的内容

建模：复杂业务系统建模，即建立软件系统模型。uml的创始人之一Booch，曾用建一座摩天大楼来比喻uml的必要性。简单系统下，可有可无，系统复杂或大到一定程度，建模和文档成为系统周期里非常重要的一环。

语言：面向对象思想的表达。互相之间的沟通工具。一种按照特定规则和模式组成的符号系统。

关于uml的争议

观点一：uml是鸡肋，离程序员真正需要的设计工具还差得很远。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。

观点二：uml设计相当的严谨与全面，在面向对象的系统架构上，可以便捷的表达你想要表达的一切想法，优美切无可替代。

个人观点：一项技能和工具，学会并不难，需要的时候能拿来用就好，艺不压身。

切忌形式化

  • 不要把uml过度神化
  • 一个表达想法的工具而已
  • 当用则用，不要刻意去套

理论

关系

关系是现实世界中事物与事物之间相互关系的符号表达，抽象到面向对象理念上，大致分为6种。

泛化（Generalization）

定义：

  • java里的extends，可用于接口与接口之间，或父子类之间
  • 单向，箭头指向父类，如Tiger指向Anima

代码：

//类
public class Animal {
}
public class Cat extends Animal {
}
//接口
public interface Action {
}
public interface Jump extends Action {
}

实现（Realization）

定义：

  • java里的implements，箭头指向接口
  • 单向，如Tiger扩展了Sleep接口，那么箭头指向Sleep

代码：

public interface Jump {
}
public class Tiger implements Jump {
}

依赖（Dependency）

定义：

  • 某个类或对象实例，依赖于另一个而存在，在其关键方法中用到了对方
  • 如果一方属性发生变动，另一方可能会收到影响
  • 一般为单向，例如动物依赖于食物，eat(Food food)
  • 类比在表结构上，更像是外键

代码：方法参数，局部变量

关联（Association）

定义：

  • 是一种拥有的关系，双方不一定属于同一类事物，箭头指向被拥有者
  • 可以单向，也可以双向，例如Tiger与Zookeeper
  • 类比在表结构上，更像是存在中间表关系

代码：成员变量

聚合（Aggregation）

定义：

  • 单向，空心菱形起始的箭头，箭头指向被拥有者
  • 一种很弱的拥有关系，A可以拥有B，但是不是离了B就无法生存
  • 群体与个体的关系，如小组包含组员

代码：成员变量，多为集合

组合（Composition）

定义：

  • 单向，实心菱形为起始，箭头指向子模块
  • 一种整体与部分的关系，A是由B组成的，离开B则不完整。
  • 单向，如人和四肢的关系

代码：成员变量，多为集合

实例

一张图涵盖所有的关系：

在这里插入图片描述

总结

  • 继承和实现几乎不会搞混，一个上下父子关系，一个是类与接口
  • 组合与聚合要注意，聚合为聚集，群体与个体。组合为组成，整体与部分
  • 关联和依赖要注意，关联一般为同级别有相关性，这种相关性是长期存在的。依赖为需求关系，一
  • 方需要依赖另一方，可能会因另一方的改变而改变。
  • 关系的强弱顺序：继承=实现>组合>聚合>关联>依赖

图

概述

在这里插入图片描述
uml中的图形非常多，按类型分为结构图和行为图，其中，最常用，最典型的为9种，下面分开来介绍。

  • 用例图：从用户角度描述系统功能。
  • 类图：描述系统中类的静态结构。
  • 对象图：系统中的多个对象在某一时刻的状态。
  • 状态图：是描述状态到状态控制流，用于表达系统状态的变化
  • 活动图：描述了业务实现用例的工作流程，强调的是动作之间的衔接
  • 序列图：对象之间的动态合作关系，强调对象发送消息的顺序
  • 协作图：描述对象之间的协助关系，强调对象之间的合作关系
  • 组件图：描述系统各个组件及其相关关系的静态视图
  • 部署图：定义系统中软硬件的物理体系结构

类图

  1. 说明
  • 面向对象系统建模中最常用和最重要的图，是定义其它图的基础
  • 主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型
  • 描述细化相关的属性和操作，是一个对业务模型面向对象化的过程，也是对系统的约束
  • 可以直接构建可执行代码，但真正使用的场景相对较少
  1. 可用元素
    在这里插入图片描述
  • 类：
  • 在这里插入图片描述
  • 接口：
    在这里插入图片描述
  • 关系：可以使用上述中的6大关系。
  1. 实例
    在这里插入图片描述

对象图

  1. 说明
  • 对象图和类图一样反映系统的静态过程，但它表达的是一个实际场景。
  • 对象图显示某时刻对象和对象之间的关系。可看成一个类图的快照。
  • 对象图是类图的实例，所以几乎使用与类图完全相同的标识
  1. 可用元素
    对象：
    在这里插入图片描述
  2. 关系
    对象图因为是运行在某个时间节点的对象镜像，所以关系比较单一，描述的是类与类的实例之间。不涉 及接口
  • 关联：对象之间存在关联关系，如用户和订单
  • 依赖：对象实例之间的依赖关系，如商品对象依赖店铺
  1. 图例
    在这里插入图片描述

组件图

  1. 说明
  • UML1.1中，组件图是用来描述一个系统的物理构件。包括文件，可执行文件，库等
  • UML2 中，关注组件间的关联（使用什么接口，通过什么端口通讯），强调通过接口来描述组件行 为
  • 对于后端来说，组件图比较适用于 SOA 架构、微服务架构，描述整个系统的结构以及子系统间的 通讯方式
  • 对于前端来说，组件图适合在使用类似 react、vue 这样组件化的前端技术框架时，表达对组件的 设计，比如一个页面会有个骨架组件，骨架组件包含了导航组件，列表组件等等
  1. 可用元素
    在这里插入图片描述
    在这里插入图片描述
  • 组件：描述的是系统的其中一个组成部分，一个完整的可独立服务的模块或单元，比如订单服务， k8s里的一个pod
  • 部件：组件内可能细化为多个子模块
  • 端口：组件对外提供服务就必须暴露对应的端口。如http rest服务默认的80
  • 接口：部件/组件之间的一种约定，分提供者和需求者同时展示了某个部件提供出的功能
  1. 关系
  • 泛化：用于接口与接口之间存在的父子关系，组件之间也可能存在，但相对用的较少
  • 实现：接口和其实现者（提供服务的组件）之间
  • 关联：Require link / Connector ，接口与调用者（需要接口的组件）之间
  1. 图例
    在这里插入图片描述

部署图

  1. 说明
  • 一种展示运行时进行处理的节点和在节点上存在的组件配置的图。
  • 阐述了在实际应用中软件和它的运行环境的关系，并且描述了软件部署在硬件上的具体方式。
  1. 可用元素
    在这里插入图片描述

  • 节点
    早先单实例MVC架构下，节点可以认为是某台物理服务器，微服务及容器化下，物理服务器大多纳 入编排管理，docker实例由系统在物理节点见自由调度，组件无法锁定在某个固定物理节点上，这 种环境下的node可以理解为一个容器，或k8s中的pod。

  • 组件实例
    相当于组件里的实例化，类比于类和对象

  1. 关系
  • 依赖：发生于组件之间，如用户组件依赖于订单组件
  • 关联：node association，发生于节点之间，例如应用服务器需要关联mysql数据库
  1. 图例
    在这里插入图片描述

用例图

  1. 说明
  • 用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图
  • 主要用于需求分析阶段，和产品文档比较贴近
  • 用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。
  1. 可用元素
  • 参与者：使用系统的人，有多少种角色就有多少参与者。
  • 用例：参与者可用做的事情
  1. 关系
  • 泛化：参与者之间可用泛化，例如用户与普通会员；用例也可用泛化，如用户管理与修改密码
  • 关联：发生于参与者和用例之间，表示该角色可用有哪些用例（行为）
  • 依赖：发生与用例之间，例如登录依赖于注册
  1. 图例
    在这里插入图片描述

交互图

交互图分为序列图和协作图，两者既可以相互转换而不丢失信息，又存在一定差异。下面分开讲再类比

序列图
  1. 说明
  • 序列图主要用于按照交互发生的一系列顺序，显示对象之间的消息或行为传递。
  • 序列图可以形象表达整个流程，和流程图有相似之处，但是流程图偏业务逻辑，序列图则是系统面 向对象化建模后，对应到对象上的交互过程。趋向于开发者角度。
  1. 可用元素
    在这里插入图片描述
  • 对象：提供功能和交互的类的实例
  • 参与者：同用例种的参与人，多为一段流程的发起点
  • 时间线：对象在整个交互流程中的生命周期
  • 消息：对象间需要发送和返回的消息，可以自己发给自己
  • 外部参考：序列图可以引入外部的一段作为参考，或参与序列中与当前图的元素交互
  • 片段：将某一段序列纳入片段管理，该片段像原子一样，发生某些整体的行为，例如循环
  1. 关系
  • 不会用到6大关系，相互之间使用message交互。代表的是信息流动。
  1. 图例
    在这里插入图片描述

文章来源:https://blog.csdn.net/u014526891/article/details/135012124
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。