理解系统架构需要精确的建模工具。在统一建模语言（UML）规范中，复合结构图因其能够揭示分类器内部结构而尤为突出。然而，这种图常被误解。许多刚入行的开发人员难以掌握内部部件、端口和连接器的细微差别。这些错误会导致设计模糊，难以实现或维护。
本指南针对创建UML复合结构图时常见的陷阱。它探讨了不同图类型之间产生混淆的原因，如何正确应用端口和接口，以及确保结构准确性的逻辑步骤。通过分析这些常见错误，开发人员可以构建更清晰、更稳健的系统模型。
1. 将复合结构图与类图混淆 🔄
最常见的错误是初级开发人员将复合结构图当作标准的类图来处理。虽然两者都用于建模结构，但它们的关注点有显著差异。类图通过类、属性和操作来描述系统的静态结构，并在类型层面定义继承和关联等关系。
相比之下，复合结构图聚焦于特定的分类器。它揭示了构成该分类器的内部部件及其相互作用方式。这种混淆通常源于将内部部件绘制为在整体视图中独立存在的类。
为何这种区分至关重要
-
范围：类图展示全局视图。复合结构图展示单个组件的内部视图。
-
可见性：类图关注公共接口。复合图关注内部组成和私有连接。
-
实现：由类图生成的代码定义类型。由复合结构图生成的代码定义运行时对象的组装方式。
当开发人员在未承认内部模块化的情况下，将复合图直接映射到类图时，生成的代码通常缺乏封装性。内部部件变得可见，违反了信息隐藏原则。
2. 对端口和连接器的理解错误 🔌
端口和连接器是复合结构图的定义特征。端口表示内部结构与外部环境之间的交互点。连接器定义了端口之间的通信路径。
初级开发人员常常完全省略端口，直接在部件之间画线。这虽然在视觉上简化了图表，但却破坏了模型的语义含义。没有端口，图表无法区分内部交互和外部契约。
常见的端口错误
-
缺少符号：未绘制附着在分类器边界上的小矩形。
-
多重性错误：在未定义端口在交互中所扮演角色的情况下，为其分配多重性。
-
直接连线：在未使用连接器节点的情况下，将部件A直接连接到部件B。尽管存在内部链接，但图示表示必须明确显示连接器。
端口充当委托的边界。如果一个部件需要服务，它不会直接调用该服务，而是通过端口请求。然后连接器将该请求路由到适当的提供者。跳过这一抽象会在模型中造成紧耦合，进而导致软件中的紧耦合。
3. 忽视提供的和需要的接口 🧩
接口定义了端口的契约。每个端口都必须明确说明它是提供服务（棒棒糖符号）还是需要服务（插座符号）。一个常见的疏忽是让端口未定义接口。没有接口的端口在功能上毫无用处，因为系统无法确定有哪些操作可用。
接口不匹配
开发人员常常认为接口由类类型隐含。这是错误的。一个部件可能具有特定的类类型，但其端口必须明确声明其所暴露的接口。
-
提供的接口： 该部件提供功能。图中显示一个棒棒糖连接到端口。
-
所需接口： 该部件需要功能。图中显示一个插座连接到端口。
-
委托： 如果一个部件需要一个接口，端口必须将该需求委托给容器或其他部件。这一点常常被忽略。
如果端口上没有明确的接口声明，图就无法传达依赖关系。维护者无法看出哪些外部系统是支持内部部件所必需的。
4. 忽视委托连接器 🚪
委托连接器专用于复合结构图。它们将复合分类器上的端口与该分类器内的部件连接起来。这种机制使复合体能够将其内部部件的功能暴露给外部世界。
初学者经常在部件之间绘制连接器，但忘记将复合分类器的端口与这些部件连接起来。这会破坏委托链。内部逻辑存在，但外部访问点并未与之连接。
委托流程
-
外部系统调用复合分类器端口上的服务。
-
端口将请求委托给内部部件。
-
内部部件执行操作。
如果缺少委托连接器，调用会在端口处停止。系统认为该操作可用，但实际上没有触发内部逻辑。当代码尝试执行建模的行为时，会导致运行时错误。
5. 错误理解多重性和角色 📏
多重性定义了复合体中部件实例的数量。角色定义了部件在关系上下文中的名称。此处的错误通常会导致对对象生命周期的错误心理模型。
常见的多重性错误
-
一对一假设： 假设每个部件都是单例。许多系统需要一组部件（例如，服务器中的处理器列表）。
-
零到一混淆： 无法区分可选部件和必选部件。零多重性意味着该部件在运行时可能不存在。
-
角色名称： 忽略角色名称会使区分同类型多个实例变得困难。“部件A”和“部件B”如果都是“处理器”类型，则显得模糊不清。
正确定义多重性可确保生成的代码正确处理实例化逻辑。如果图中显示多重性为0..*，则代码必须支持动态创建或空值检查。如果图中显示为1，则代码假设在初始化时已存在。
6. 混淆交互与结构 🧱
复合结构图是静态的。它们展示结构，而非行为。一个常见错误是在结构图中添加动态元素，如状态转换或顺序流箭头。
虽然连接器表示潜在的通信，但它们并不表示操作的顺序。将顺序图与复合结构图混合使用会造成视觉干扰和混淆。观察者无法区分结构依赖与时间依赖。
关注点分离
-
结构： 使用复合结构图来表示部件、端口和角色。
-
行为：使用顺序图或状态图来表示流程和逻辑。
-
交互：使用通信图来表示对象之间的消息传递。
将这些关注点分开有助于更好的维护。如果结构发生变化，结构图会更新；如果逻辑发生变化，行为图会更新。将它们混合在一起会导致一个图的更改不必要地波及到另一个图。
常见错误对比
|
图元 |
常见错误 |
正确做法 |
|---|---|---|
|
部件 |
将它们视为独立的类 |
将其定义为由复合分类器拥有 |
|
端口 |
让它们未指定类型或缺失 |
显式地附加提供的或需要的接口 |
|
连接器 |
在没有连接器的情况下直接连接部件 |
为所有交互使用显式的连接器节点 |
|
委托 |
忘记将端口连接到内部部件 |
确保外部端口将功能委托给内部组件 |
|
多重性 |
默认为单个实例 |
指定确切的基数（0..*，1..1等） |
|
作用域 |
将其用于全局系统概览 |
仅将其用于特定的复合分类器 |
7. 实现的最佳实践 🛡️
为了避免这些陷阱，开发人员在建模复合结构时应遵循结构化的方法。以下指南可确保清晰性和准确性。
-
从分类器开始： 首先定义复合分类器。这为所有内部部分设定了上下文。
-
首先定义接口： 在绘制部件之前，先定义它们所需的接口和提供的接口。这在实现之前明确了契约。
-
使用构造型： 如果标准UML符号不足以表达，可以使用构造型来指示特定类型的部件（例如，<<cache>>、<<db>>）。这增加了语义含义，而不会造成混乱。
-
限制复杂性： 不要无限嵌套复合结构。复合结构图应聚焦于一个层次的分解。如果需要更深层次的细节，应为嵌套部分创建新的图。
-
检查多重性： 始终仔细检查部件的基数。系统是否允许该部件缺失？是否允许多个实例？
-
验证委托： 从外部端口追踪到内部操作的路径。如果路径中断，该图就是无效的。
8. 何时跳过复合结构图 🚫
并非每个系统组件都需要复合结构图。过度使用这种图会导致文档膨胀。它最适合用于内部结构对理解至关重要的复杂组件。
复合结构图不必要的迹象
-
简单类： 如果一个类没有内部部件，类图就足够了。
-
行为关注点： 如果主要关注的是数据流，序列图更为合适。
-
低复杂度： 如果组件是一个单一的逻辑单元，内部结构不会增加价值。
-
高层架构： 对于系统范围的视图，组件图比详细的复合结构图更合适。
使用合适的工具完成合适的工作可以节省时间。如果类图能够传达必要信息，就不必强行将复合结构图引入工作流程。这能保持文档的聚焦性和可读性。
9. 准确建模的影响 📊
正确地建模内部结构对开发生命周期具有切实的好处。当图表准确反映设计时，代码生成工具可以生成更可靠的骨架代码。测试人员可以根据定义的接口和端口推导出测试用例。
此外，准确的图表能减少技术债务。当开发人员遇到错误时，他们可以查看图表以了解数据流向。如果图表显示了正确的委托路径，那么查找错误的范围就会被缩小到该特定交互。如果图表错误，查找过程就会变成猜测。
投入时间学习端口、连接器和接口的细微差别是值得的。这使开发人员从仅仅绘制方框转变为理解系统组成。这种更深入的理解对于维护可扩展和模块化的软件至关重要。
10. 关键要点总结 ✅
-
范围：复合结构图关注的是内部组成，而不是全局类型。
-
端口：始终使用接口（提供或需要）来定义端口。
-
连接器：对于部件与端口之间的所有交互，均使用显式的连接器。
-
委托：确保外部端口正确地将请求委托给内部部件。
-
多重性：为所有部件指定确切的基数，以定义生命周期规则。
-
分离：不要将行为流混入结构图中。
通过识别这些常见错误，开发者可以制作出符合其预期用途的图表。目标是清晰明了。难以阅读的图表是一种负担。能够准确捕捉内部结构的图表则是宝贵的资产。注重精确性，避免不必要的复杂性，并确保图表中的每个元素在系统架构中都有明确的角色。
持续审查这些图表是必要的。随着系统的发展，内部结构可能会发生变化。保持模型与实现同步，可确保文档始终是真实信息的来源，而非过时的遗迹。这种纪律性正是稳健工程与随意开发之间的区别。
