近况
软考也不知道能不能过，害，总之尽力吧，万一过不了确实要浪费很多时间，不过不管成功失败，软考中级我总要过的
近期在学习软考中UML统一建模语言，除了UML还学习了一些软件工程中其他的图，所以打算再水一篇关于
软件开发中各种图的认识，学习一下这些图的基本概念，弄清楚它们的用途和它们之间的区别，以后如果有需要
也可以尝试画一画，到时候看到这篇博客，可以快速理解温习一下。
我将这些图分成两部分吧，一部分是软件工程中的图，一部分是UML中的图。
网上对于分类这些图形比较乱，流程图，程序流程图并不是指一个意思，可能也不是包含关系，
这么说是因为亿图图示的画图工具中它的图形符号分类中，程序流程图在软件工程一栏下，流程图下并没有程序流程图
流程图的应用很广，不仅仅在软件工程方向上有影响，在其他企业，工程管理方面同样也有影响，
而程序流程图则是专门应用于软件工程领域的图，所以本篇博客中不关注流程图。
软件工程中的图
程序流程图
定义
程序流程图又称程序框图，是描述程序流向的图形
一般由处理框、判断框、起止框、连接点、流程线、注释框等元素构成。
程序框图的设计是在处理流程图的基础上，通过对输入输出数据和处理过程的详细分析，
将计算机的主要运行步骤和内容标识出来。某位大佬说：
程序流程图描述的是完整的业务流程，以业务逻辑处理过程为中心。不强调数据流动，但强调控制/处理过程。
程序流程图表示对信息进行加工处理的【控制】过程，也称为【控制流】元素组成
不管定义如何复杂，程序流程图是最简单的图，实际上在亿图图示的画图工具中，程序流程图只有4个元素
案例
案例1：
案例2：
数据流程图(数据流图)
定义
Data Flow Diagram，缩写为DFD。中文名数据流图或数据流程图。
数据流图DFD是描述系统中数据流程的一种图形工具，它标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。值得注意的是，数据流图不是传统的流程图或框图，数据流也不是控制流。
数据流图是从数据的角度来描述一个系统，而框图是从对数据进行加工的工作人员的角度来描述系统。关于数据流程图是不是属于流程图中一类图，我不太清楚，在亿图图示中流程图下有数据流程图
但是亿图图示的软件工程下同样有一个数据流模型图，而且这两个图的元素和软件设计师教程中数据流程图的元素各不相同
我更倾向于亿图图示的软件工程一栏下的数据流模型图中元素才是真正的数据流程图元素，
但在本篇博客中，我选择软件设计师教程第5版中数据流程图的元素展示，不仅因为元素简单，数量少，而且我发现很多数据流程图的案例中，仅仅只使用这几个元素。数据流图与程序流程图的区别：
数据流图是从数据的角度来描述一个系统的，而程序流程图则是从对数据加工的角度来描述系统的； 数据流图中的箭头是数据流，而程序流程图中的箭头则是控制流,它表达的是程序执行的次序； 数据流图适合于宏观地分析一个组织业务概况，而程序流程图只适合于描述系统中某个加工的执行细节。元素组成
软件设计师教程第5版中数据流程图所具有的元素
基本概念
数据流程图其架构是多层次的，这些数据流程图被分成多层，下层数据流图是上层数据流图的再细化
- 第0层DFD称为系统基本模型，可以将整个软件系统表示为一个具有输入和输出的黑匣子。用一个圆圈表示。
- 上一层DFD中的每一个圆圈可以进一步扩展成一个独立的数据流图，以揭示系统中程序的细节部分。
- 循序渐进继续进行，直到最低层的图仅描述原子过程操作为止。 每一层数据流图必须与它上一层数据流图保持平衡和一致，因此，子图的所有输入输出流要与其父图相匹配。
案例
基于公式的即时家教系统
L0层：
L1层：
L2层：
实体-联系图(ER图)
定义
ER图是基于ER模型（实体联系模型）绘制的，属于概念模型，抽象了现实世界中的实体及其关系。
ER模型也被称为实体联系模型，实体关系模型或实体联系模式图(ERD)，
大部分数据库设计产品使用实体-联系模型（ER模型）帮助用户进行数据库设计。啥是模型？啥是概念模型？
基本概念
ER模型的三要素：实体，联系，属性，将ER模型用图形画出来，就是ER图，在ER图中：
矩形框：表示实体，在框中记入实体名。 菱形框：表示联系，在框中记入联系名。 椭圆形框：表示实体或联系的属性，将属性名记入框中。对于主属性名(主键)，则在其名称下划一下划线。 连线：实体与属性之间；实体与联系之间；联系与属性之间用直线相连，并在直线上标注联系的类型。 对于一对一联系，要在两个实体连线方向各写1; 对于一对多联系，要在一的一方写1，多的一方写N; 对于多对多关系，则要在两个实体连线方向各写N,M。关于ER图更多概念，例如多值属性，派生属性等知识点，请看本文最下方的推荐文章
元素组成
软件设计师教程第5版中关于ER图的元素
案例
案例1：
案例2：
甘特图(Gantt图)
甘特图，PERT图和项目活动图都是用于规划项目进度安排的图形，实际上这三个图形并不属于软件开发或软件工程，而是属于项目管理领域。
在亿图图示中，它们都属于工程管理一栏下，之所以把它们拿出来介绍一番，是因为想填充一下博客的篇幅
况且我恰好学了这几个图，就当是记录一下了哈哈哈哈哈定义
甘特图以图示通过活动列表和时间刻度表示出特定项目的顺序与持续时间。
一条线条图，横轴表示时间，纵轴表示项目，线条表示期间计划和实际完成情况。
直观表明计划何时进行，进展与要求的对比。便于管理者弄清项目的剩余任务，评估工作进度。甘特图可以清晰的描述每个人物从何时开始，到何时结束。同时还可以展示任务的进展情况和任务的并发情况。
但它并不能反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。案例
案例1：
案例2：
PERT图/项目活动图
定义
PERT图，全称Program Evaluation & Review Technique，即项目计划评审技术图
和甘特图一样，是项目管理中使用的图，用于确保项目能够在规定时间内如期完成
甘特图不能够反映任务之间的依赖关系，如果我们想从图上看出这一点，我们需要借助PERT图。它是一个有向图，图中的箭头表示任务，它可以标上完成任务所需的时间。图中的节点表示流入节点的任务的结束，并开始流出节点的任务。
只有当流入该节点的所有任务都结束时，节点所表示的事件才出现，流出节点的任务才可以开始。
项目活动图是在PERT图的基础上进行了简化，不再关注结点的最早最晚开始时间了
所以在网络上大多数人把项目活动图也当成PERT图看待。
基本概念
1.一个结点的最早开始时刻等于前一个结点的最早开始时刻加上任务需要执行的时间 2.开始结点的最早开始时刻是0，最晚开始时刻并不一定是0，结束结点的最早开始时刻等于最晚开始时刻 3.如果一个结点有多个前结点，则该结点的最早时刻等于前结点加任务执行时间的最大值 如上图，E结点前有B，C两结点，通过计算，B结点最早开始时刻为7，C结点最早开始时刻为5 则E节点最早开始时刻为：7+4=11，而不是5+3=8，因为E节点需要等到前结点全部执行完才能开始执行 如果为8，则B结点任务还未执行完毕 4.如果一个结点有多个后节点，则该结点最晚开始时刻等于后结点最晚时刻减去任务执行时间的最小值 如果一个结点指向多个其他节点，则该结点有多个后节点，如果一个结点被多个其他节点指向，则该节点有多个前结点 如上图，B结点的最晚开始时刻等于D节点最晚时刻减2的值与B节点最晚时刻减4的值，两者之中的最小值 5.松弛时间，指的是该结点的最晚开始时间减去该结点最早开始时间的值 松弛时间表示的含义是：在不影响整个工期的前提下完成该任务有多少机动余地。 6.关联路径，指的是PERT图中，松弛时间为0的结点所组成的路径，一个PERT图中不止有一条关联路径 找到关键路径，只需要看从开始结点到结束结点哪条路径的任务执行时间之和最大，哪条路就是关键路径。 注意：以上所说的结点都指的是大项目中的一个个任务，而箭头指向的值则是任务执行的时间。案例
案例1：
案例2：
UML中的图
UML
定义
UML是统一建模语言的简称，它是一种由一整套图表组成的标准化建模语言。UML主要使用图形符号来表示软件项目的设计，使用UML可以帮助项目团队沟通、探索潜在的设计和验证软件的架构设计。
UML 涉及很多不同的图表（模型），其原因是提供从许多不同的角度来審視系统。
静态建模指的是创建并建立一个系统的静态特征，动态建模指的是用来展示系统的行为以下是软考中常考的9种UML图：
基本概念
UML的词汇表包含3种构造块：事物，关系和图，事物是对模型中最具代表性的成分的抽象，关系把事物结合在一起，图聚集了相关事物。
UML中有4种事物：结构事物，行为事物，分组事物和注释事物
- 结构事物
结构事物是UML模型中的名词，它们通常是模型的静态部分，描述概念或物理元素，结构事物图形化如下：
- 行为事物
行为事物是UML模型的动态部分，它们是模型中的动词，描述了跨越时间和空间的行为，行为事物图形化如下：
- 分组事物
分组事物是UML模型的组织部分，是一些由模型分解成的”盒子”，在所有分组事物中，最主要的分组事物是包
包是把元素组织成组的机制，下面是包的图形化
- 注释事物
注释事物是UML模型的解释部分，这些注释事物用来描述，说明和标注模型的任何元素，注解是一种主要的注释事物
注解是一个依附于一个元素或一组元素之上，对它进行约束或解释的符号，注解的图形化如下：
UML中有4种关系：依赖，关联，泛化和实现
依赖
依赖是两个事物间的语义关系，其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义
关联
关联是一种结构关系，它描述了一组链，链是对象之间的连接，聚集(聚合)和组合是特殊的关联关系
它描述了整体和部分间的结构关系，在关联上可以标注重复度和角色，下面是相应图形：
聚合与组合的区别在于：
当出现一个对象(部分)消失时，另一个对象(整体)也随之消失，就是组合关系，组合关系中部分与整体是有相同的生命周期的。
当出现一个对象(部分)消失时，另一个对象(整体)不随之消失，就是聚合关系，聚合关系中部分与整体的生命周期不一致。
聚合是实线+空白菱形，如上图，而组合是实线+实心菱形关联关系中的多重复指的是：一个类的实例能够与另一个类的多少个实例相关联
泛化
泛化是一种特殊/一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象
用这种方式，子元素共享了父元素的结构和行为，在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素
实现
实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约
在两种情况下会使用实现关系，一种是在接口和实现它们的类或构件之间，另一种是在用例和实现它们的协作之间。
图是一组元素的图形表示，大多数情况下把图画成顶点(代表事物)和弧(代表关系)的连通图
为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。
UML中有13种图，分别是：类图，对象图，用例图，序列图，通信图，状态图，活动图，构件图，组合结构图，部署图，包图，交互概览图和计时图- 结构事物
类图
定义
类图是一种静态结构图，即属于静态建模，类图将在现实生活中的各种对象及它们之间的关系抽象成模型。
描述系统的静态结构能够说明系统包含些什么以及它们之间的关系，但它并不解释系统中的各个对象是如何协作来实现系统的功能。类图中通常包含：类，接口，协作，依赖,泛化和关联关系
类图展现了一组对象，接口，协作和它们之间的关系，下面是类图的示例：
基本概念
类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务
当对系统的静态设计视图建模时，通常以下述3中方式之一使用类图。- 对系统的词汇建模
对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外，用类图详细描述这些抽象和它们的职责 - 对简单的协作建模
协作是一些共同工作的类，接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。
例如，当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义
用类图对这组类以及它们之间的关系进行可视化和详述。 - 对逻辑数据库模式建模
将模式看作为数据库的概念设计的蓝图，在很多领域中，要在关系数据库或面向对象数据库中存储永久信息，可以用类图对这些数据库的模式建模
- 对系统的词汇建模
案例
案例1：
案例2：
对象图
定义
对象图展现了某一时刻一组对象以及它们之间的关系，描述了在类图中所建立的事物的实例的静态快照在对系统的静态设计视图或静态进程视图建模时，主要是使用对象图对对象结构进行建模
对象结构建模涉及在给定时刻抓取系统中对象的快照，对象图表示了交互图表示的动态场景的一个静态画面
可以使用对象图可视化，详述，构造和文档化系统中存在的实例以及它们之间的相互关系
案例
案例1：
案例2：
用例图
定义
用例图展现了一组用例，参与组以及它们之间的关系，用例图通常包含用例，参与者，
用例之间的扩展关系和包含关系，参与者与用例之间的关联关系，用例与用例以及参与者与参与者之间的泛化关系参与者：参与者是与系统交互的外部实体，可能是使用者，也可能是与系统交互的外部系统，基础设备等
用例：用例是从用户角度描述系统的行为，它将系统的一个功能描述成一系列的事件，这些事件最终对操作者产生有价值的观测结果。
用例是一个类，它代表一类功能而不是使用该功能的某一具体实例。包含关系(include)：用例A包含用例B，用例A执行，那用例B也会执行
扩展关系(extend)：一个用例执行的时候，可能会发生一些特殊的情况或可选的情况，这种情况就是这个用例的扩展用例
案例
案例1：
案例2：
序列图
定义
序列图也叫顺序图，时序图，序列图是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动序列图是交互图的一种，交互图用于对系统的动态方面进行建模。一张交互图表现的是一个交互，
由一组对象和它们之间的关系组成，包含它们之间可能传递的消息。交互图表现为序列图，通信图，交互概览图和计时图
每种针对不同的目的，能适用于不同的情况，序列图是强调消息时间顺序的交互图，
通信图是强调接收和发送消息的对象的结构组织的交互图，交互概览图强调控制流的交互图
交互图可以单独使用，来可视化，详述，构造和文档化一个特定的对象群体的动态方面，也可以用来对一个用例的特定的控制流进行建模交互图一般包含对象，链和消息
案例
案例1：
案例2：
通信图
定义
通信图又被成为协作图，通信图强调收发消息的对象的结构组织
序列图和通信图都是交互图，且它们是同构的，它们之间可以相互转换
案例
案例1：
案例2：
案例3：
状态图
定义
状态图展现了一个状态机，它由状态，转换，事件和活动组成，状态图关注系统的动态视图
对于接口，类和协作的行为建模尤为重要，强调对象行为的事件顺序。当对系统，类或用例的动态方面建模时，通常是对反应型对象建模
基本概念
状态分为状态名和活动表，活动表是由很多动作组成，通常我们可以把活动看作为是动作
转换是一个状态转移到另一个状态的过程，转换也可以被称为转移
事件则是驱动状态发生转移的先前条件，一个状态转移到另一个状态不仅需要有相应的事件，还要满足监护条件(守卫条件,监护状态)。
状态的介绍
事件的介绍
案例
案例1：
案例2：
活动图
定义
活动图是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程，活动图专注于系统的动态视图
它对于系统的功能建模特别重要，并强调对象间的控制流程活动图一般包括活动状态和动作状态，转换和对象，活动图可以表示分支，合并，分岔和汇合
当对一个系统的动态方面建模时，通常有两种使用活动图的方式
- 对工作流建模
此时所关注的是与系统进行协作的参与者所观察到的活动，工作流常常位于软件系统的边缘，
用于可视化，详述，构造和文档化开发系统所涉及的业务过程，在活动图的这种用法中，
对对象流的建模是特别重要的，常采用泳道将活动图中的活动状态分组。 - 对操作建模
此时是把活动图作为流程图使用，对一个计算的细节部分建模。在活动图的这种用法中，
对分支，合并，分岔和汇合状态的建模是特别重要的，用于这种方式的活动图语境包括该操作的参数和它的局部对象。
- 对工作流建模
案例
案例1
案例2：
构件图
定义
构件图也叫组件图，构件图展现了一组构件之间的组织和依赖，构件图专注于系统的静态实现视图
它与类图相关，通常把构件映射为一个或多个类，接口或协作。实线+半圆为需接口，实线+圆为供接口
案例
案例1：
案例2：
部署图
定义
部署图是用来对面向对象系统的物理方面建模的方法，展现了运行时处理结点以及其中构件(制品)的配置
这里的构件可以理解为项目的某个功能模块，部署图对系统的静态部署视图进行建模，它与构件图相关部署图展现了系统的软件与硬件之间的关系，在实施阶段使用
案例
案例1：
案例2：
推荐文章
