UML类图是描述系统结构的唯一表示法吗？有哪些替代方案？

首先明确：UML类图不是描述系统结构的唯一表示法。它只是面向对象设计范式普及后通用度较高的一类图形化建模标准，本身存在符号冗余、视角偏代码实现层、对非面向对象范式适配差的问题，不同场景下有大量更适配的结构描述方案。

• 实体关系图（ERD）：诞生早于UML，是数据结构建模领域的主流方案，核心聚焦实体、属性、实体间的关联基数，不会混入面向对象的继承、方法这类和数据存储无关的概念，是数据库设计、业务数据域梳理场景最常用的表示法。
• 架构描述语言（ADL）：面向高严谨度架构建模的形式化语言，常见的包括Acme、Wright、xADL等，有严格的语法规则，可以精确定义系统组件、交互端口、连接规则、配置约束，支持形式化正确性校验，多用于航空、金融等高可靠系统的架构结构描述。
• C4模型：当前互联网研发领域普及度很高的轻量化结构建模方法，按粒度分层描述系统：从最顶层的系统上下文、容器、服务组件，到最细粒度的代码类结构，符号规则简单，没有UML繁杂的语义约定，技术、非技术角色都能快速读懂，可覆盖从业务全局到代码实现的全层级结构描述需求。
• 结构化设计结构图：是传统结构化开发范式的核心结构表示法，聚焦模块层级、模块间调用关系、数据与控制流传递规则，在嵌入式开发、底层系统开发场景至今仍被广泛使用，完全不依赖面向对象的建模逻辑。
• 文本式领域建模语言：包括PlantUML、Mermaid类图这类可通过纯文本定义结构的标记语言，能直接嵌入代码仓库做版本管理，不用依赖专用建模工具；云原生场景下的Terraform HCL、Kubernetes资源定义YAML，本身就是基础设施层结构的精确描述语言；函数式编程场景下的代数数据类型定义，本身就是代码层面数据结构的可执行表示，比示意性的UML类图更贴合实际实现。
• 业务域建模表示法：比如事件驱动过程链（EPC）配套的业务对象模型，多用于企业级业务系统的域结构梳理，核心对齐业务事件、业务对象、组织角色的关联关系，不会强行套用面向对象的建模规则，更贴合业务侧的实际结构认知。

内容的提问来源于stack exchange，提问作者MissCatarinaV