🌈个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客
💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
[1. 前言](#1. 前言)
[2. UML概述](#2. UML概述)
[2.1 UML的分类与功能](#2.1 UML的分类与功能)
[2.2 UML的语法与各图关系](#2.2 UML的语法与各图关系)
[3. 四种图的概述](#3. 四种图的概述)
[3.1 状态图](#3.1 状态图)
[3.2 活动图(Activity Diagram)](#3.2 活动图(Activity Diagram))
[3.3 构件图(Component Diagram)](#3.3 构件图(Component Diagram))
[3.4 部署图(Deployment Diagram)](#3.4 部署图(Deployment Diagram))
[4. 状态图](#4. 状态图)
[4.1 状态图概要](#4.1 状态图概要)
[4.2 状态图中的事物及解释](#4.2 状态图中的事物及解释)
[4.3 状态的可选活动表](#4.3 状态的可选活动表)
[4.4 实例](#4.4 实例)
[5. 活动图](#5. 活动图)
[5.1 活动图概要](#5.1 活动图概要)
[5.2 活动图和状态图的关系](#5.2 活动图和状态图的关系)
[5.3 活动图事物编辑](#5.3 活动图事物编辑)
[5.4 活动图关系](#5.4 活动图关系)
[5.5 实例](#5.5 实例)
[6. 构件图](#6. 构件图)
[6.1 构件图概要](#6.1 构件图概要)
[6.2 构件图中的事物及解释](#6.2 构件图中的事物及解释)
[6.3 构件图中的关系及解释](#6.3 构件图中的关系及解释)
[6.4 实例](#6.4 实例)
[7. 部署图](#7. 部署图)
[7.1 部署图概要](#7.1 部署图概要)
[7.2 部署图中的事物及解释编辑](#7.2 部署图中的事物及解释编辑)
[7.3 部署图中的关系及解释](#7.3 部署图中的关系及解释)
[7.4 实例](#7.4 实例)
[7.5 部署图与构件图的关系](#7.5 部署图与构件图的关系)
[8. 总结](#8. 总结)
1. 前言
2. UML概述
所谓UML（Unified Modeling Language，统一建模语言），一种用来对软件密集系统进行可视化建模的语言。
这样的概念大概解释了UML是什么，不过还不够直观。
我们可以换个问题，UML做到了什么，让人们愿意为之喝彩？
答案就是，它统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。它是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。
如此一来，UML的本质也就呼之欲出了。UML的本质就是为了交流。
一句话：一个UML就能完成整个软件开发中的交流需要
2.1 UML的分类与功能
UML2.0一共有12种图形（UML1.5定义了9种，2.0增加了3种）。
分别是：用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图9种，包图、组合结构图、交互概览图3种。
"UML无用论"在很多年前就被提了出来，更是引发了业内不少争议。有用户将它捧上天，甚至"封神"，也有人斥之为垃圾，甚至称其"反人类"。
那么问题来了，UML 真的无用吗？或者用题主的话来说，UML 还有用吗？
我想先说自己的判断：UML 依然有用。
之所以这么判断，主要基于以下三点事实：
第一，图比代码更清晰
在复杂需求中，UML图是非常必要的。
用例图描述系统的外部交互、序列图描述系统的内部交互、状态图描述系统的动态特性、部署图描述系统的物理节点、类图与对象图描述依赖关系......
所有的图都是协助团队策划稿能源更高效地厘清问题，掌握知识，高效解决问题的。
试问下，在敏捷开发中，如果没有流程图、序列图、状态图进行辅助，你如何在代码过程中保证业务流程、系统前后端、多个系统切换开发做到敏捷高效？
在敏捷开发时，面对稍复杂点的需求，如果要求团队提前用UML图厘清问题，后续填坑可以少很多。
第二，"假敏捷开发"太多
正如@萝魏紫 所言，中国假敏捷太多了，以敏捷为借口少写甚至不写文档，以至于大量项目在本不应出问题的沟通层面出现大量问题，没有统一的标准，沟通不出问题才怪。
UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。
不过，我们也必须注意到，UML不是万能的，但是在系统研发中的沟通作用，效果还是比较好的。
第三，UML 在业界依然在被应用
UML的实际应用例子，大家在这个问答中可以找到不少：
比如，@Milo Yip 表示，"腾讯没有统一、从上而下的软件工程方法论，毕竟业务差异很大。但在各种文档及简报中也经常以 UML 图来呈现一些信息，算是一种辅助沟通的方法。"另外，"我在面试时会让候选人做一些简单设计，用 UML 最好，不会的也可用他熟悉的编程语言表示。"
@fantiny 也举了自己前公司产品ExchangeUSE的例子，据介绍，当时UML在前期需求分析和架构设计阶段起到一定的作用，包括需求分析与共通化整理，系统模块化分析工具，架构设计的交流工具，实现合理性的分析工具。
2.2 UML的语法与各图关系
各图关系：
UML语法描述： 
3. 四种图的概述
这一部分先对 状态图、活动图、构件图和部署图 做一个简单的概述。
3.1 状态图
状态图是一个类对象所可能经历的所有历程的模型图。状态图由对象的各个状态和连接这些状态的转换组成。
**状态图描述对象：**一个类对象
**状态图组成：**一个类对象的各种状态、状态转化动作
3.2 活动图(Activity Diagram)
- 活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动
- 活动图描述了一组顺序的或并发的活动
状态图和活动图：
1、状态图针对每一个类
2、活动图针对整合算法系统
3.3 构件图(Component Diagram)
构件图为系统的构件建模型---构件即构造应用的软件单元---还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响。
构件图（Component Diagram） 是 UML（统一建模语言）中用于描述系统物理构件及其相互关系的图。它展示了系统中各个"构件"（如可执行程序、库、模块等）之间的关系，以及它们如何通过接口进行交互。构件图通常用于描述系统的静态结构，尤其是关注系统的物理实现层次。
构件图的主要元素：
构件（Component） ：表示系统中的一个物理模块或部件，它是一个可执行的或可部署的单位。构件可以是程序文件、库文件、Web 服务、数据库、或者任何其他具有独立功能的部分。
- 符号：构件通常用一个矩形表示，矩形的右上角有一个小的折角。
接口（Interface） ：构件之间的交互通常通过接口完成。接口定义了构件提供的服务或其所需的服务。
- 符号：接口通常是一个小圆圈或带有名字的"半圆"。
依赖关系（Dependency）：构件图中，构件之间可能有依赖关系，这表示一个构件依赖于另一个构件的功能或服务。
- 符号：依赖关系通常用带箭头的虚线表示，箭头指向被依赖的构件。
端口（Port）：端口是构件和外界进行交互的地方，通常用来定义通过接口暴露的功能。
- 符号：端口通常表示为构件矩形的一部分，形状如小小的矩形或圆圈。
3.4 部署图(Deployment Diagram)
部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配。
4. 状态图
4.1 状态图概要
- 说明对象在它的生命期中响应事件所经历的状态序列，以及它们对那些事件的响应。
- 揭示Actor、类、子系统和组件的复杂特性。 为实时系统建模。
- 对象的状态是指在这个对象的生命期中的一个条件或状况，在此期间对象将满足某些条件、执行某些活动，或等待某些事件。
- 转移是由一种状态到另一种状态的迁移。这种转移由被建模实体内部或外部事件触发。
- 对一个类来说，转移通常是调用了一个可以引起状态发生重要变化的操作的结果。
4.2 状态图中的事物及解释
4.3 状态的可选活动表
4.4 实例
(1)网上银行登录系统
5. 活动图
5.1 活动图概要
- 描述系统的动态行为。
- 包含活动状态(ActionState)，活动状态是指业务用例的一个执行步骤或一个操作，不是普通对象的状态。
- 活动图适合描述在没有外部事件触发的情况下的系统内部的逻辑执行过程；否则，状态图更容易描述。
- 类似于传统意义上的流程图。
- 活动图主要用于：
- 业务建模时，用于详述业务用例，描述一项业务的执行过程；
- 设计时，描述操作的流程。
5.2 活动图和状态图的关系
- 活动图和状态图都体现状态在活动中变化。
- 状态图是一个类对象在活动中状态发生变化。
- 活动图是整个系统在活动中状态发生变化。
5.3 活动图事物
5.4 活动图关系
5.5 实例
-
本活动图描述一个处理订单的用例执行过
(1)执行setup order
(2)根据order的类型是执行不同的分支：
-
single order：执行assign seat、charge credit card
-
subscription：同时执行assignseats、debit account或 award bonus
-
single order与subscription两步可同时进行
(3) 最后mail packet。
-
6. 构件图
6.1 构件图概要
- 构件图用于静态建模，是表示构件类型的组织以及各种构件之间依赖关系的图。
- 构件图通过对构件间依赖关系的描述来估计对系统构件的修改给系统可能带来的影响。
6.2 构件图中的事物及解释
- 可替换的物理部分包括软件代码、脚本或命令行文件，也可以表示运行时的对象，文档，数据库等。
- 节点(node)是运行时的物理对象，代表一个计算机资源。具体请参见教程"部署图(deployment diagram)"部分。
6.3 构件图中的关系及解释
6.4 实例
实例1
- 图中的构件名称是Dictionary字典。
- 该构件向外提供两个接口，即两个服务Spell-check拼写检查、Synonyms同义词。
实例2
- 图中"Planner计划者"构件向外提供一个"update更新"接口服务。
- 同时，该构件要求外部接口提供一个"Reservations预定"服务。
7. 部署图
7.1 部署图概要
- 部署图用于静态建模，是表示运行时过程节点结构、构件实例及其对象结构的图。
- 如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。
- 部署图的两种表现形式：实例层部署图和描述层部署图(会在后面的实例中给出)。
7.2 部署图中的事物及解释
7.3 部署图中的关系及解释
7.4 实例
实例1
- 实例层部署图描述各节点和它们之间的连接。
- 本图中的信息与上张描述层部署图中的内容是相互对应的。
- 图中的关系是各个节点之间存在的通信关系。
实例2
- 描述层部署图表示了系统中的各节点和每个节点包含的构件。
- 图中包括的各种关系如下：
- 通信链关系(不带箭头的直线)
- TicketServe票服务器与Kiosk信息厅之间存在一对多的通信关联；与SalesTerminal售票终端也存在一对多的通信关联；
- 依赖关系(带箭头的虚线)
- TicketSeller售票构件依赖CreditCardCharges信用卡付款构件和TicketDB票数据库构件提供的服务。
- 通信链关系(不带箭头的直线)
7.5 部署图与构件图的关系
部署图（Deployment Diagram） 和 构件图（Component Diagram） 都是 UML 中用于描述系统的静态结构，但它们关注的层次不同，功能上也有所区别。
-
构件图 主要关注系统的逻辑结构和软件层面，描述系统中的各个构件（如模块、库、服务等）及其相互关系，强调模块间的依赖、接口和交互。
-
部署图 主要关注系统的物理部署和硬件层面，展示节点（如服务器、工作站、设备等）之间的关系，并标明哪些构件部署到哪些节点上。
关系：
- 构件图 描述的是系统的软件组件 及其内部结构，而 部署图 描述的是这些组件如何在物理硬件上部署和运行。
- 构件图 中的构件通常会在 部署图 中被映射到一个或多个节点上，显示它们的实际部署情况。
- 例如，构件图中的业务逻辑组件可能会被部署到一个服务器节点上，而数据库组件则可能被部署到另一台数据库服务器节点。
8. 总结
本文到这里就结束啦~~
目前已经完成：
【软件工程】一篇入门UML建模图（类图）_uml图教程-CSDN博客
【软件工程】一篇入门UML建模图（用例图、对象图、顺序图与协作图）-CSDN博客
本篇讲述：状态图、活动图、构件图、部署图
如果觉得对你有帮助，友友们可以点个赞，收个藏呀~
