软件架构在很大程度上依赖于系统交互方式的清晰定义。在建模复杂应用时，复合结构图（CSD）提供了分类器内部结构的详细视图。然而，组件之间的边界常常成为混淆的来源。这些边界中的歧义可能导致实现错误、集成失败以及维护噩梦。本指南深入探讨了如何使用标准建模技术来解决这些结构性不确定性。
理解核心概念 🏗️
复合结构图是统一建模语言（UML）中的一种特殊类型图表。它描绘了分类器的内部结构及其各部分之间的交互关系。与关注静态关系的类图，或关注动态行为的顺序图不同，CSD专注于系统的物理和逻辑组装。
主要挑战在于定义组件边界。该边界充当契约。它规定了哪些内容向外部世界暴露，哪些内容保留在组件内部。当该边界未被明确定义时，会出现以下问题：
- 依赖混淆：组件内部的部件依赖于未正式暴露的外部服务。
- 接口不匹配：所需接口与其它部件提供的接口不匹配。
- 逻辑泄露：内部实现细节对外部使用者变得可见。
- 部署错误：物理部署与逻辑结构不一致。
为了解决这些问题，必须理解构成组件边界的基本要素。这些要素包括部件、端口、接口和连接器。
组件边界的解剖结构 🔍
在修复歧义之前，我们必须明确边界由什么构成。在UML建模中，组件是系统的一个模块化、可替换的部分。边界是组件进行通信的接口。
1. 部件与角色
部件是构成复合结构的内部组件。每个部件都必须具有明确的角色。角色定义了部件在复合结构上下文中的预期行为。如果部件没有角色，其与系统其余部分的连接就会变得模糊。
- 强类型： 确保每个部件都使用特定的分类器进行类型定义。
- 多重性： 定义在边界内可以存在多少个部件的实例（例如，一对一、一对多）。
- 所有权： 明确部件是由复合体拥有，还是与其他复合体共享。
2. 端口与接口
端口是交互的点。它们是消息进入或离开组件的网关。接口定义了该端口上可用的操作集合。
- 提供的接口： 组件向外部世界提供的操作。
- 所需接口：组件从外部世界需要的操作。
- 内部端口：严格在边界内的连接。
当一个部分与外部世界交互但未通过端口时，歧义常常发生。这会绕过边界契约。为了解决这个问题，所有外部交互都必须通过显式端口进行路由。
常见歧义及解决策略 🛠️
建模者经常遇到边界定义变得模糊的特定场景。下表概述了常见问题及其技术解决方案。
| 歧义类型 | 描述 | 解决策略 |
|---|---|---|
| 共享状态 | 多个部分直接访问同一数据存储。 | 将数据存储封装在单个部分内，并通过提供的接口暴露它。 |
| 直接连接 | 部分直接连接到其他复合体，而没有端口。 | 在复合体边界上插入一个端口，并将连接通过该端口进行路由。 |
| 接口继承 | 一个部分需要一个在复合体级别未定义的接口。 | 确保复合体需要该接口，或将该需求委托给特定部分。 |
| 边界穿越 | 连接器在没有端口的情况下跨越边界线。 | 重新绘制连接器，使其在边界上的端口节点处终止。 |
| 实现泄露 | 内部类依赖被暴露为公共的。 | 将内部类移至私有包或内部隔间。 |
解决接口与端口冲突 ⚡
歧义最持久的来源之一是组件所需与所提供的不匹配。这种情况在大型系统中经常发生，多个团队在架构的不同部分工作。
契约原则
每个端口都代表一个契约。如果端口被标记为需要，则复合体假设它将在外部找到实现。如果被标记为提供，则复合体承诺实现它。当出现以下情况时，会产生混淆：
- 一个需要的接口过于通用，允许任何实现。
- 提供的接口暴露了本应隐藏的内部逻辑。
- 实现关系是隐含的，而不是明确的。
逐步解决
- 确定需求来源： 确定是哪个内部部分需要该服务。是整个组件，还是仅仅一个子部分？
- 定义接口签名： 创建清晰的接口定义。避免将数据结构与行为混合。
- 分配端口： 将接口连接到边界上的特定端口。
- 验证实现： 确保另一个组件提供了该接口的实现。
- 检查多重性： 确认提供的实例数量与所需的实例数量相匹配。
内部结构与外部视图 🧱
当内部结构与外部视图混淆时，清晰性常常丧失。组合结构图应明确区分可见部分与隐藏部分。
内部分隔区
使用分类器的内部分隔区来展示各部分的排列方式。除非连接器是复合体内部的，否则不要在此处放置外部连接器。如果连接器离开了边界，必须连接到端口。
- 内部连接器： 这些连接器连接同一边界内的部分，不会跨越边界线。
- 外部连接器： 这些连接器跨越边界线，必须连接到端口。
可见性约束
可见性修饰符（+、-、#）在边界定义中起着关键作用。
- 公共（+）： 对所有外部客户端可见。
- 私有（-）： 仅对内部部分可见。
- 受保护（#）： 对子类和内部部分可见。
当内部部分被标记为公共但本应保持私有时，就会产生歧义。请检查每个部分的可见性，以确保封装性得到维护。
验证与确认技术 ✅
草图绘制完成后，需要进行验证。此过程确保结构模型与行为模型和部署模型保持一致。
一致性检查
对您的图表执行以下检查：
- 端口完整性：所有外部连接是否都连接到了端口？
- 接口一致性：所有必需的接口是否都有相应的提供接口？
- 角色分配：每个部件是否都有明确定义的角色？
- 无循环：内部部件之间是否存在不通过端口传递的循环依赖？
行为一致性
结构必须支持行为。如果顺序图显示向某个部件发送消息，则复合结构图必须显示该消息的路径。该路径应通过适当的端口。
- 可追溯性：将状态机图与它们交互的组件部分关联起来。
- 消息流向：确保连接器上的箭头方向与数据流向一致。
高级场景与边缘情况 🚀
标准建模规则涵盖了大多数情况，但复杂的架构常常引入需要仔细处理的边缘情况。
1. 嵌套复合体
当一个组件将另一个组件作为其部件时，内部组件的边界变为内部边界。除非通过外部组件的端口显式路由，否则不要将内部组件的端口直接暴露给外部世界。
- 封装： 外部组件应作为内部组件的外观。
- 委托： 使用委托连接器，将来自外部端口的请求路由到内部端口。
2. 共享部件
有时一个部件在多个复合体之间共享。这可能会导致关于所有权和生命周期的潜在歧义。
- 共享聚合： 使用共享聚合来表明该部件独立于复合体存在。
- 生命周期管理： 明确指定谁负责创建和销毁共享部分。
3. 动态结构
某些系统在运行时会改变其结构。静态的复合结构图无法捕捉每一种动态变化。
- 工厂模式： 在图中使用工厂模式来建模部件的创建。
- 配置： 使用配置文件或元数据来定义运行时结构，并在图的注释中引用它们。
清晰性最佳实践 📝
为了长期保持高质量的模型，请遵循这些最佳实践。
- 保持图的简洁： 如果一个组件过于复杂，应将其拆分为子复合体。单个图应专注于一个抽象层次。
- 使用命名规范： 根据端口所使用的接口来命名，而不是根据其连接的部件。这能使接口契约更清晰。
- 记录假设： 如果边界假设非常规，请在图中添加注释以解释该约束。
- 迭代审查： 不要试图在第一稿中就完美定义边界。随着系统设计的演进，逐步优化它。
- 标准化符号： 确保所有图中提供的和需要的接口符号保持一致。
排查常见错误 🔧
即使经验丰富的建模者也会犯错。在审查过程中遇到常见错误时，可采取以下具体步骤。
错误：连接器跨越了边界
解决方案： 在边界线上插入一个端口。将连接器的一端移动到与该端口对齐。确保该端口具有正确的接口类型。
错误：部件处于漂浮状态
解决方案： 部件必须连接到其他对象。如果某个部件没有连接，很可能是错误。应将其删除或连接到一个端口。
错误：接口不匹配
解决方案： 比较所需接口和提供接口的操作签名。确保参数类型完全匹配。
错误：循环依赖
解决方案： 通过引入一个中间接口，或重构逻辑以消除直接依赖，来打破循环。
自动化在边界解析中的作用 🤖
尽管人工审查至关重要，但建模工具可以帮助检测边界违规。自动化分析可以检查：
- 未连接的端口。
- 缺失的接口实现。
- 违反封装规则。
在建模环境中使用验证规则有助于保持一致性。然而，自动化无法替代人类对边界语义含义的判断。
关键要点总结 📌
解决组件边界中的模糊性需要对UML建模采取严谨的方法。通过严格遵守端口、接口和连接器的规则，你可以创建一个稳健的架构模型。
- 明确界定边界： 所有外部交互均使用端口。
- 区分内部与外部： 不要将内部连接器与外部连接混用。
- 验证接口： 确保所有所需接口都有提供者。
- 保持封装性： 将内部细节隐藏在提供的接口之后。
- 迭代与优化： 将图表视为随系统演进的动态文档。
遵循这些指南，可以确保复合结构图发挥其作用：为系统实现提供清晰、无歧义的蓝图。