在设计复杂软件系统时，标准类图往往力不从心。它们擅长展示单个对象之间的关系，但在描绘系统不同部分在结构层面如何交互方面却显得捉襟见肘。这正是“复合结构图发挥作用的关键。它能清晰地展现分类器的内部架构，特别关注构成组件的各个部分以及这些部分之间的连接方式。在本指南中，我们将通过这种特定的UML符号，从零开始演示如何建模一个多层应用程序。
为什么要使用复合结构图？🧩
传统建模通常止步于类层面。然而，现实世界的应用程序是由子系统、模块和硬件组件构建而成的。复合结构图可以帮助你：
- 分解复杂性：将一个大型类分解为可管理的内部组成部分。
- 可视化交互：展示数据在内部组件之间如何流动。
- 定义接口：明确各部分通信所遵循的精确契约（端口）。
- 映射架构：使图表与实际部署约束保持一致。
对于多层应用程序而言，该图表至关重要。它能够区分表示层、业务逻辑层和数据持久层，确保依赖关系得到正确管理。
核心概念与术语 📐
在深入建模步骤之前，理解基本构建模块至关重要。与标准类图不同，复合结构图依赖于特定的概念：
1. 部分 🧱
部分表示一个存在于另一个分类器内部的分类器实例。在多层上下文中，一个部分可以是一个控制器，一个存储库，或一个视图。每个部分都有一个明确的类型和可选的角色。
2. 端口 🚪
端口是交互点。它们定义了部分暴露功能或接收数据的位置。端口分为以下几类：
- 提供的接口（棒棒糖）：部分向外部世界提供的功能。
- 所需的接口（插座）： 零件从外部世界需要的功能。
3. 连接器 🔗
连接器将端口连接在一起。它们代表信息的流动。连接器将一个部件的所需接口与另一个部件的提供接口绑定在一起。
4. 角色 🎭
角色定义了部件在连接器中所扮演的特定位置。它明确了部件在特定上下文中的交互方式。
理解多层架构 🏢
多层架构将关注点分离为不同的层次。这种分离提高了可维护性、可扩展性和安全性。标准模型通常包括三个层次：
- 表示层： 处理用户交互和显示。
- 业务逻辑层： 包含核心规则和处理逻辑。
- 数据访问层： 管理信息的存储和检索。
以下是复合结构模型中各层级职责的分解。
| 层级 | 主要职责 | 关键部件 | 典型接口 |
|---|---|---|---|
| 表示 | 渲染用户界面，捕获输入 | 视图，控制器 | 显示数据，提交操作 |
| 业务逻辑 | 处理规则，验证 | 服务，管理器 | 处理订单，验证用户 |
| 数据访问 | 持久化状态，查询 | 仓库，数据访问对象 | 保存记录，获取数据 |
逐步建模指南 📝
现在，我们将构建该图。我们将假设一个涉及订单管理系统的场景。我们不会引用任何特定的软件工具；重点仍放在结构建模技术上。
步骤 1：定义复合结构 🏗️
首先定义主要的分类器。在这种情况下，我们将其称为OrderSystem。该分类器充当整个多层架构的容器。
- 创建一个名为OrderSystem.
- 启用复合结构视图（通常以被划分为多个部分的矩形表示）。
- 此视图表示内部组成现在已可见。
步骤 2：添加部件（层级） 🧱
接下来，将系统分解为其逻辑层级。这些将成为OrderSystem.
- 部件 1：PresentationPart
- 类型：ClientApplication
- 角色：用户界面
- 部件 2：BusinessPart
- 类型：CoreServices
- 角色：逻辑引擎
- 部件 3：DataPart
- 类型：StorageManager
- 角色：持久化层
将这些部件绘制在OrderSystem分类器的边界内。每个部件都应清楚地标明其类型和角色。
步骤 3：定义端口和接口 🚪
这是确保松散耦合最关键的一步。每个部分都需要确切地知道它需要什么以及它提供什么。
展示部分端口
- 需要： 需要调用业务逻辑。创建一个名为 BusinessAccess.
- 提供： 需要向用户显示结果。创建一个名为 UserDisplay.
业务部分端口
- 需要： 需要保存数据。创建一个名为 DataAccess.
- 提供： 需要接收来自展示部分的请求。创建一个名为 OrderProcessing.
数据部分端口
- 提供： 需要允许读写操作。创建一个名为 StorageInterface.
- 需要： 无（通常位于链的底部）。
步骤 4：连接各部分 🔗
现在，建立端口之间的连接。这可以可视化数据流。
- 连接 1： 连接 业务访问（必需）在 展示部分到 订单处理（提供）在 业务部分.
- 连接 2： 连接 数据访问（必需）在 业务部分到 存储接口（提供）在 数据部分.
这些连接器代表运行时发生的 API 调用或方法调用。它们确保展示层无法直接与数据层通信。这强化了架构边界。
高级建模模式 🔍
随着系统规模的增长，简单的连接可能不再足够。对于复杂场景，应考虑这些高级模式。
1. 嵌套的复合结构
如果 业务部分足够大时，它可以拥有自己的内部结构。你可以将 业务部分本身建模为一个复合体，包含如 验证服务 和 事务管理器这种递归方法允许深度嵌套，而不会使主图变得杂乱。
2. 外部接口
并非所有连接都是内部的。您的多层应用程序可能需要与外部支付网关通信。您可以使用一个边界或一个通过连接器与业务部分.
3. 基于状态的交互
有时，某个部分仅在特定状态下提供接口。尽管标准UML并不总能在静态图中捕捉动态状态变化，但您可以通过前置条件标注端口。例如，存储接口可能要求系统处于活动状态。
常见陷阱及避免方法 ⚠️
在创建这些图时，团队常常犯一些特定错误，从而降低图表的价值。请审查此列表以确保准确性。
- 跳过端口：在没有端口的情况下直接连接部件会造成紧密耦合。请为每个连接都定义一个端口。
- 过度建模：不要为每个变量都建模。应关注结构边界和主要数据流。
- 忽略类型：确保部件的类型与实现相匹配。如果部件是仓库，那么类型也应反映这一点。
- 循环依赖：检查数据是否形成循环流动（例如：数据 → 业务 → 表现 → 数据）。这表明存在设计缺陷。
验证与优化 🔨
一旦绘制完成图表，就必须进行验证。请根据以下标准审查结构：
- 关注点分离：表示层是否仅处理用户界面逻辑？数据层是否仅处理存储？
- 接口一致性： 提供的和所需接口的名称和签名是否一致？
- 完整性： 是否从用户界面到数据库，每个主要用户操作都有对应的路径？
- 可扩展性： 是否可以轻松地将 DataPart 替换为不同的存储机制，而无需更改 PresentationPart?
映射到部署 ⚙️
组合结构图通常在部署图之前绘制。此处定义的各个部分通常映射到基础设施中的物理节点。
- PresentationPart → Web服务器 / 客户端设备
- BusinessPart → 应用服务器
- DataPart → 数据库服务器
通过保持这种映射关系，可以确保逻辑模型与物理现实一致。如果某个部分过于庞大，可能需要将其拆分到多个物理节点上，而组合结构图可以帮助规划这一过程。
这种方法的优势 ✅
采用这种结构化方法相较于随意建模具有多项优势：
- 清晰性：利益相关者可以看清系统的内部连接，而不会迷失在代码中。
- 文档化： 该图作为动态文档，有助于新开发人员快速上手。
- 测试： 定义的接口为单元测试和集成测试提供了明确的目标。
- 重构： 在更改后端时，该图有助于识别前端哪些部分会受到影响。
最终考虑事项 🚀
建模多层应用程序需要纪律。仅仅画出方框和线条是不够的；你必须理解这些方框之间的契约。复合结构图正是强制执行这种纪律的工具。通过关注部件、端口和连接器，你将创建一个能够抵御变化的蓝图。
请记住，图表是沟通工具。如果一个新团队成员无法理解某个图表，那么它就失去了作用。保持符号使用的一致性。为端口使用清晰的名称。确保层级结构合理。经过练习，这种技术会自然地融入你的架构设计过程。
随着技能的提升，你会发现这些图表有助于及早发现架构漂移。当开发人员试图绕过业务层时，图表会清楚地显示出这种违规行为。这种主动的设计方法在开发和维护阶段能节省大量时间。
从小处着手。先建模单个模块，然后再扩展到整个系统。这种渐进式方法可以避免过度负担，并确保每个连接都是有意为之且有记录的。