软件和系统可视化方法和工具
24.05.2025, 24.05.2025 - Old-David-Wang
Software and Systems Visualisation Methods and Tools
软件和业务背景下的图和分析技术
摘要
图示是理解、沟通和分析软件和业务领域复杂系统的重要工具。本文综合利用现有资料，概述了流程图、数据流图、业务流程模型、软件架构图、实体关系图和UML图等不同类型的图示。文章还深入探讨了软件工程中使用的特定图示和分析技术，如控制流图、数据流分析、控制依赖图和程序依赖图，并重点介绍了它们在程序切片和别名分析等领域的应用。本文的讨论完全基于所提供的原始资料，旨在阐述这些不同表示方法的特征、组成部分和用途。
工具清单
图形/模型类型工具列表（含开源状态）
如下是各类图表类型和工具
1. 业务流程模型 (Business Process Models)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| BPMN (方法/符号) | 不适用（符号） |
| Open ModelSphere | 是 |
| Software Ideas Modeler | 否 |
| PowerDesigner | 否 |
| UModel | 否 |
| Modelio (BPMN2) | 是 |
2. 数据流图 (DFD) (Data Flow Diagrams)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| Astah | 不明确 |
| Software Ideas Modeler | 否 |
| Dia | 是 |
| Diagrams.net (draw.io) | 是 |
UML 活动图 (可替代其作用)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| （无特定工具） | 不适用（图形类型） |
流程图 (Flowcharts)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| Astah | 不明确 |
| Software Ideas Modeler | 否 |
| Diagrams.net (draw.io) | 是 |
| mermaid | 是 |
| excalidraw | 是 |
| Inkscape | 是 |
| PowerPoint | 否 |
| Matplotlib | 是 (Python 库) |
| Adobe Illustrator | 否 |
| Dia | 是 |
| OmniGraffle | 否 |
| yEd | 否 |
| TikZ | 是 (LaTeX 包) |
| Drakon-chart | 未指定 |
软件架构图 (Software Architecture Diagrams)
| 备注 | 开源状态（基于上文） |
|---|---|
| 未列出特定工具 | 请参阅相关图形类型和下方的通用绘图工具 |
实体关系图 (ERD) (Entity Relationship Diagrams)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| Lucidchart | 否 |
| Astah | 不明确 |
| Open ModelSphere | 是 |
| Software Ideas Modeler | 否 |
| ERROL (查询语言) | 不适用（语言） |
统一建模语言 (UML) 图 (Unified Modeling Language Diagrams)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| ArgoUML | 是 (已归档) |
| Astah | 不明确 |
| ATL | 是 (Eclipse M2M 项目) |
| Together | 否 |
| BOUML | 不明确 |
| Cacoo | 不明确 |
| clang-uml | 是 (根据 GitHub 链接推断) |
| Dia | 是 |
| Diagrams.net | 是 |
| Eclipse UML2 Tools | 是 (Eclipse 项目) |
| Enterprise Architect | 否 |
| Gliffy | 不明确 |
| JetUML | 是 (根据 GitHub 链接推断) |
| Lucidchart | 否 |
| MagicDraw | 否 |
| Microsoft Visio | 否 |
| Modelio | 是 |
| MyEclipse | 不明确 |
| NClass | 是 (根据 GitHub 链接推断) |
| NetBeans | 是 (NetBeans IDE 的一部分) |
| Open ModelSphere | 是 |
| Papyrus | 是 (Eclipse 项目) |
| PlantUML | 是 |
| PowerDesigner | 否 |
| PragmaDev Studio | 否 |
| Prosa UML Modeller | 不明确 |
| Rational Rose XDE | 否 |
| Rational Software Architect | 否 |
| Rational Software Modeler | 否 |
| Rational System Architect | 否 |
| Reactive Blocks | 是 (Eclipse 项目) |
| Rhapsody | 否 |
| Software Ideas Modeler | 否 |
| StarUML | 否 |
| Umbrello UML Modeller | 是 (KDE 项目) |
| UML Designer | 是 (Eclipse 项目) |
| UMLet | 是 |
| UModel | 否 |
| UmpleClass | 是 (根据 GitHub 链接推断) |
| WhiteStarUML | 是 (StarUML 的分支) |
| yEd | 否 |
系统建模语言 (SysML) 图 (Systems Modeling Language Diagrams)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| Enterprise Architect | 否 |
| Modelio | 是 |
| Rhapsody | 否 |
| Software Ideas Modeler | 否 |
| UModel | 否 |
通用数据模型 (General Data Models)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| Open ModelSphere | 是 |
| PowerDesigner | 否 |
| UModel | 否 |
其他提到的图形类型 (Other Mentioned Diagram Types)
威胁模型 (Thread Models)
| 备注 | 开源状态（基于上文） |
|---|---|
| 未列出特定工具 | - |
Petri 网 (Petri Nets)
| 备注 | 开源状态（基于上文） |
|---|---|
| 未列出特定工具 | - |
程序网络图 (Program Network Charts)
| 备注 | 开源状态（基于上文） |
|---|---|
| 未列出特定工具 | - |
系统资源图 (System Resources Charts)
| 备注 | 开源状态（基于上文） |
|---|---|
| 未列出特定工具 | - |
通用绘图工具 (General Diagramming Tools)
| 工具名称 | 开源状态（基于上文） |
|---|---|
| diagrams.net (draw.io) | 是 |
| mermaid | 是 |
| excalidraw | 是 |
| Inkscape | 是 |
| PowerPoint | 否 |
| Matplotlib | 是 (Python 库) |
| Adobe Illustrator | 否 |
| Dia | 是 |
| OmniGraffle | 否 |
| yEd | 否 |
| TikZ | 是 (LaTeX 包) |
| Excel | 否 |
Article
1. 引言
可视化表示，或称图示，对于将复杂系统抽象成更易理解的形式至关重要，有助于不同利益相关者（从业务负责人到软件工程师）之间的沟通。不同的图示服务于不同的目的，侧重于系统的各个方面，如工作流程、数据流、结构或控制流…。
本文根据所提供的资料，探讨了一系列图示和分析技术，阐述了它们的独特特征和应用。
2. 业务和系统建模的图示类型
在业务和技术背景下，使用多种图示类型来建模流程、数据和系统结构。
2.1. 流程图 (Flowcharts)
流程图是一种表示工作流程或过程的图示。它也可以定义为算法的图示表示，概述了解决任务的逐步方法。流程图使用不同类型的方框表示步骤，并使用连接箭头的顺序表示。这种图示表示有助于说明给定问题的解决方案模型，并用于分析、设计、文档化或管理过程或程序。
流程图的标准符号由美国国家标准协会 (ANSI) 在20世纪60年代制定，并于1970年由国际标准化组织 (ISO) 采用，当前标准为 ISO 58074。
- 流程图通常从上到下、从左到右流动。
- 主要符号包括表示操作顺序的流线（带箭头的线）。
- 终端符号（体育场形、椭圆形或圆角矩形）表示程序或子过程的开始和结束，通常包含“开始”或“结束”等词语。
- 过程用矩形表示，代表改变数据值、形式或位置的一组操作。
- 判定是菱形，表示确定程序将采用的两个路径之一的条件操作，通常是是/否问题。
- 输入/输出用平行四边形表示，指示数据的输入和输出。
- 注释（带有虚线或实线连接到相应符号的开放矩形）提供附加信息。
- 预定义过程（带有双竖边框的矩形）表示在其他地方定义的命名过程。
- 同页连接器和跨页连接器（小圆圈和本垒板形五边形）用于替代长线条或连接到其他页面。
- 还有其他符号用于数据文件/数据库（圆柱形）、文档、手动操作、手动输入和准备/初始化。
- 流程图还可以使用水平线或条形图表示并行处理，指示同时操作的开始或结束。
流程图通常侧重于某种类型的控制流。它们通常与其他类型的图示互补。石川馨将流程图确定为质量控制的七种基本工具之一。在 UML 中，活动图是一种流程图…。 流程图的其他名称包括过程图、流程图、功能流程图、过程地图、过程图表、功能过程图表、业务流程模型、过程模型、过程流图、工作流图和业务流图。存在各种流程图分类，例如系统流程图、程序流程图、决策流程图、逻辑流程图、系统流程图、产品流程图和过程流程图。
2.2. 数据流图 (DFD)
数据流图 (DFD) 是结构化分析、数据建模和威胁建模中的工具3。它起源于20世纪70年代中期的结构化分析和设计技术 (SADT)，并由 Tom DeMarco 和 Edward Yourdon 等人推广。与可能包含大量细节的业务流程模型相反，DFD 可能专注于数据的移动，从而将过程描绘简化为“角色输入数据；应用程序接受数据；角色查看数据”等步骤。
DFD 由四个主要组成部分构成：过程、流、仓库和终端。
- 过程（功能、转换）是系统中将输入转换为输出的部分。它通常用圆、椭圆、矩形或圆角矩形表示，并命名以表达其本质。
- 数据流（流、数据流）用箭头表示信息的传输（有时也表示物料）。它理想情况下只传输一种类型的信息。流连接过程、仓库和终端。
- 仓库（数据存储、数据存储、文件、数据库）用于存储数据以便后续使用。通常用两条水平线表示，其名称通常是复数名词。仓库可以表示数据文件、文档文件夹或文件柜，其表示与实现无关。流到仓库通常表示数据输入/更新，而流从仓库通常表示读取。
- 终端是与系统通信但位于系统外部的外部实体。它可以是组织、人群、机构、部门或另一个系统。
创建 DFD 的规则包括使实体名称易于理解且通用但具体。过程应编号以便于参考。为了清晰起见，建议 DFD 包含 6 到 9 个过程，最少 3 个，但上下文图除外，它将整个系统表示为与所有终端交互的单个过程。可以使用另一个 DFD 将过程细化为更详细的表示。DFD 可以看作是反向的 Petri 网。在 UML 中，活动图通常接管DFD的角色。
2.3. 业务流程模型 (BPM)
业务流程模型描述了操作性业务流程，可能包含大量细节。与侧重于数据流动的数据流图不同，BPM 旨在描绘业务流程的步骤和流程。验证活动是否是步骤的一种技术是使用名词-动词名称（例如，“验证许可证”）并检查将其反转（“许可证已验证”）是否仍然有意义并确认存在转换。存在多种建模方法，例如 BPMN。为了让利益相关者清楚理解，使用简单的泳道图等符号。
2.4. 软件架构图 （Software Architecture Diagram）
什么是软件架构图？ 它是一个系统结构的视觉化表示，就像一个蓝图，它说明了系统的组件、它们之间的交互和关系。软件架构图是用于简化复杂系统和改善不同利益相关者（包括软件工程师、CEO 和 CIO）之间沟通的强大工具。通过将复杂的结构分解为易于理解的视觉效果，它们有助于协调技术团队和业务利益相关者。
创建软件架构图包括列出主要系统组件，如服务器、数据库、微服务和 API，确保不遗漏任何关键元素。然后，定义这些组件如何交互，考虑数据流、依赖关系和外部系统。抽象级别应与图示的目的相符：
- 概念级 (Conceptual)：突出关键系统元素及其广义关系，适用于业务利益相关者。
- 逻辑级 (Logical)：侧重于组件之间的功能和连接，对架构师有用。
- 物理级 (Physical)：详细描述硬件、网络配置和部署细节，面向工程师。
目的和重要性： 软件架构图对于简化复杂系统非常有用。它是连接技术团队和业务干系人（如 CEO 和 CIO）之间的桥梁，帮助所有人理解复杂系统，无论其技术背景如何。它能增强协作、支持决策、减少错误，并提高项目效率。
2.5. 实体关系图 (ERD)
实体关系图 (ERD) 用于可视化实体之间的关系，通常在数据库设计的上下文中。关键概念包括：
- 实体类型 (Entity type)：可存储信息或对象的类别，例如“学生”。
- 实体集 (Entity set)：特定时间点所有特定类型的实体，例如“今天上课的学生”。实例是集合中的一个具体的人或车。
- 实体类别 (Entity categories)：实体分为强实体（仅凭自身属性定义）、弱实体（不能仅凭自身属性定义）或关联实体（关联实体集内的实体）。
- 实体键 (Entity keys)：唯一标识实体的属性21。类型包括超键（一个或多个属性定义一个实体）、候选键（最小超键）、主键（选定的候选键）和外键（标识实体之间的关系）。
- 关系 (Relationship)：描述实体如何交互或关联，通常被视为动词（例如，学生注册课程）。关系通常用菱形或连接线上的标签表示。递归关系是指同一个实体多次参与关系。
- 属性 (Attributes)：描述实体（像形容词，例如“二年级学生”）或关系（像副词，例如“以数字方式”）的特性。
存在多种 ERD 表示风格，包括 Chen、Crow’s Foot/Martin/Information Engineering、Bachman、IDEF1X 和 Barker。ER 模型和数据模型可以绘制在不同详细程度上：概念级（最高级别，细节最少，显示总体范围）、逻辑级（更多细节，定义操作/事务实体，技术无关）和物理级（用于数据库实现的特定技术细节）。这些级别与其他图示类型（如 DFD）中使用的级别类似，但与软件工程中的三模式方法不同。
2.6. 统一建模语言 (UML) 图
统一建模语言 (UML) 是软件开发中使用的标准概念建模表示法。它包含许多不同的图示类型。UML 中的活动图是一种流程图。UML 图可用于技术文档。用例图是一种 UML 图，有助于澄清需求、检测问题并简化系统设计。UML 图分为结构图（类图、组件图、复合结构图、部署图、对象图、包图、配置文件图）、行为图（活动图、状态机图、用例图）和交互图（通信图、序列图、交互概览图、时序图）。存在许多支持创建 UML 图的软件工具…。SysML 被提及为一种相关但不同的建模语言。
3. 软件分析的图示和技术
除了通用的系统建模之外，在软件工程中还使用特定的图形表示和分析技术来理解和分析程序代码。
3.1. 控制流图 (CFG)
控制流图 (CFG) 是有向图，其中每个节点代表一个基本块，每条边代表基本块之间的控制流。基本块是连续语句的序列，控制流从开头进入并在结尾离开，除了结尾处不能有分支。通过识别“领导者”（程序中的第一条语句、goto 语句的目标、紧跟在 goto 语句之后的语句）来构造基本块。每个基本块以领导者开始，并包含后续语句直到下一个领导者或程序结束。虽然基本块可以是语句的最大序列，但在源代码分析中，每条语句通常被视为一个基本块。边代表控制流，条件转移（如 while、if-else、switch）标记为“T”或“F”35。节点可以根据边具有后继和前驱。为了清晰起见，可以在控制流合并的地方插入“连接”节点。switch 语句可以用一个具有多个标记的出边的节点表示，每个 case 值一个。非可执行的结构性语句（如 end 或 else）通常不作为节点包含在内。
3.2. 数据流分析
数据流分析将变量引用分类为定义（当变量获得一个值时）或使用（当变量的值被获取时）…。使用进一步分为计算使用 (c-uses)，影响计算或输出，以及谓词使用 (p-uses)，影响控制流。
一个关键概念是可达定义 (reaching definitions)：可能沿着某个路径到达特定程序点且未被同一变量的其他定义“杀死”的定义。 数据流分析算法为每个程序节点计算以下集合：
- GEN 集 (GEN set)：节点内部生成的定义。
- KILL 集 (KILL set)：如果到达节点的入口则被杀死的定义。
- IN 集 (IN set)：到达节点前一点的定义。它是其直接前驱节点的 OUT 集的并集。
- OUT 集 (OUT set)：到达节点后一点的定义。它包括在节点中生成的定义，或到达入口并在节点内未被杀死的定义 (GEN ∪ (IN - KILL))。
算法 ReachingDefs 迭代计算 IN 和 OUT 集直到稳定，本质上模拟所有可能的程序执行，以尽可能远地传播定义而不被杀死…。该分析可用于解决其他问题，如可达使用、可用表达式和活跃变量。
3.3. 定义-使用对 (Definition-Use Pairs) 和数据依赖图 (Data Dependence Graphs)
变量 v 的定义-使用对 (DU pair) 是一个有序对 (D, U)，其中语句 D 定义 v，语句 U 使用 v，并且在 CFG 中存在一条从 D 到 U 的路径，该路径上没有重新定义 v（一条def-clear 路径）…。这些对表示数据交互，其中 U 处的计算取决于 D 处计算的数据，这称为流依赖 (flow dependence)…。节点内的upwards exposed use 是指到达节点入口的定义可以触及的使用。
可以使用数据依赖图 (DDG) 以图形方式表示数据依赖关系，其中节点代表定义/使用位置，边代表依赖关系。另外，可以在 CFG 中添加数据依赖边；对于每个 DU 对 (D, U)，添加一条边 (D, U)。
3.4. 程序路径 (Program Paths)
CFG 中的路径是节点通过边连接的序列。完整路径是从入口节点到出口节点的路径。不可行路径 (infeasible path) 是由于条件语句而无法由任何程序输入执行的路径。du-path 是连接定义节点和使用节点（针对变量）的路径，该路径对该变量是 def-clear 的。
3.5. 控制依赖图 (CDG)
控制依赖图 (CDG) 表示控制依赖关系，其中节点代表具有共同控制依赖关系的语句或代码区域54。CDG 的构建可以包括使用开始/结束节点增强 CFG 并构建后继支配树…。CDG 包含语句节点（圆形）和谓词节点（圆角框），标记的边从谓词节点发出。可以添加区域节点（六边形）来总结区域内语句的控制依赖关系。
3.6. 程序依赖图 (PDG)
程序依赖图 (PDG) 结合了控制依赖和数据依赖信息。它可以被视为添加了数据依赖边的 CFG…。PDG 节点对应于程序语句、谓词或区域。边表示控制依赖（带标签）和数据依赖。
3.7. 程序切片 (Slicing)
程序切片最初用于调试，它提取可能影响特定程序点上变量值的语句和谓词。切片可以使用 PDG 计算，方法是从感兴趣的点开始进行反向遍历，包括通过控制依赖和数据依赖前驱可到达的所有节点…。动态切片 (dynamic slice) 考虑特定的执行路径，并将静态切片限制在遍历的节点上。前向切片 (forward slice) 识别受变量在某点的值影响的语句和谓词，通过直接依赖关系的传递闭包计算…。
3.8. 别名分析 (Alias Analysis)
别名分析识别在给定程序点上不同名称（如变量或解引用指针）指向同一内存位置的情况。这在包含指针的语言中尤其重要。结果通常使用points-to sets表示，指示指针可能引用哪些固定位置变量（非指针变量）。别名分析有助于揭示间接内存修改带来的副作用。Points-to 信息通常是MAY信息，意味着它可能在执行期间为真，具体取决于执行路径…。
传统的定义-使用分析 (DUA) 因指针而复杂。为解决此问题，变量引用被分为四种类型：DDEF（确定定义）、PDEF（通过指针的可能定义）、DUSE（确定使用）和PUSE（通过指针的可能使用）。数据流算法进行了调整，以在识别 DU 对时考虑确定和可能的定义/使用，但只有确定定义才被视为杀死其他定义。解引用指针 (*p) 可以被视为 *p 的确定定义（及其别名的可能定义）以及指针变量 p 本身的确定使用。
4. 图示工具
有多种软件工具可用于创建这些图示。资料中提到了诸如 draw.io (app.diagrams.net)…、TikZ (用于 LaTeX)…、Mermaid、Excalidraw、Ipe、Inkscape…、Dia、Omnigraffle、Powerpoint、Matplotlib、Adobe Illustrator、Figma、PlantUML、Lucidchart…、Visio 和 Miro 等工具。其中许多工具支持创建多种类型的图示，包括本文讨论的图示。
5. 结论
资料展示了业务和软件开发中使用的各种图示。从高级业务流程模型和软件架构视图到详细的程序控制流图和依赖分析，每种图示类型都提供了独特的视角，并服务于特定的分析或沟通目标。理解这些不同的图示类型及其相关的技术对于有效的系统设计、开发和分析至关重要。