🔍 理解包图的范围
UML包图作为组织复杂软件系统的架构基石。它们使建模者能够将相关元素分组为称为包的可管理单元。虽然包的概念很简单——作为命名空间——但这些包之间的交互常常带来歧义。工程师们经常难以区分不同关系类型、可见性规则和导入机制。
本指南解答了关于包交互最常见的问题。我们将探讨依赖关系的语义、可见性修饰符的影响，以及如何在不引入不必要的耦合的情况下保持模型结构的清晰。通过澄清这些交互，可以确保系统架构在长期中保持可维护性和可扩展性。
❓ 关于包依赖的常见问题
依赖关系是包图中最常见的交互形式。它们表示一种使用关系，即一个包依赖于另一个包中定义的元素。然而，符号表示和含义会根据上下文而有所不同。
Q1：依赖箭头的具体含义是什么？
依赖箭头表示供应包的规范发生变化可能会影响客户端包。这是一种弱关系，通常描述为“使用”。与关联不同，依赖关系并不表示系统运行期间持续存在的结构性链接。它们仅表示对某个定义的访问需求。
- 客户端： 使用该元素的包。
- 供应方： 提供该元素的包。
- 箭头方向： 从客户端指向供应方。
Q2：依赖关系与关联有何不同？
混淆常常产生于两者都涉及元素之间的连接。区别在于链接的生命周期和强度。
- 依赖关系： 临时使用。客户端需要供应方来编译或运行，但不会将其作为属性持有引用。示例：包A中的一个类使用包B中的一个工具函数。
- 关联： 结构性关系。客户端将供应方作为成员变量或属性持有引用。示例：一个
订单包包含一个客户包的引用。
Q3：我应在何时为依赖关系使用构造型？
构造型为关系提供了语义上的清晰性。标准UML允许使用自定义构造型来定义交互的性质。常见的构造型包括：
- «use»： 表示标准的依赖关系。
- «import»： 表示供应包中的元素在客户端命名空间中无需限定即可可见。
- «访问»： 表示元素可见，但未导入命名空间。
Q4：有效的模型中可以存在循环依赖吗？
从技术上讲，是的，但通常被认为是一种设计缺陷。当包A依赖于包B，而包B又依赖于包A时，就会产生循环依赖。这会造成紧密耦合，使得重构困难且测试复杂。在许多构建系统中，循环依赖会阻止成功编译。
为了解决这个问题，可以考虑引入一个中间包来定义共享的接口或抽象。这样通过强制两个原始包都依赖于抽象而非彼此直接依赖，从而打破循环。
🔗 关系类型与符号表示对比
理解视觉符号表示对于准确阅读和创建图表至关重要。下表总结了包之间使用的关键关系类型。
| 关系类型 | 符号表示 | 含义 | 耦合强度 |
|---|---|---|---|
| 依赖 | 带空心箭头的虚线 | 客户端使用供应商的定义 | 低 |
| 关联 | 实线（通常带标签） | 结构连接；持有引用 | 中等 |
| 泛化（继承） | 带空心三角形的实线 | 包扩展另一个包的结构 | 高 |
| 实现 | 带空心三角形的虚线 | 包实现其他地方定义的接口 | 中等 |
| 导入 | 带空心三角形的虚线或«import» | 将外部名称引入本地命名空间 | 高（可见性） |
🛡️ 可见性与访问控制规则
可见性决定了包内哪些元素可以被其他包访问。误解这些规则常常会导致“命名空间污染”或意外的编译错误。
公共可见性 (+)
标记为公共的元素可以被系统中的任何包访问。这是大多数建模工具的默认设置。虽然方便，但过度使用公共可见性会降低封装性。
- 任何包都可以引用一个公共元素。
- 推荐用于接口和API定义。
私有可见性 (-)
标记为私有的元素只能在其定义的包内访问。其他包无法直接查看或使用它们。
- 防止外部对内部逻辑的修改。
- 用于辅助函数或实现细节。
受保护的可见性 (~)
受保护的元素在当前包内以及任何泛化（扩展）当前包的包中都可访问。与类图相比，在包图中这种情况较少见，但仍适用于包结构。
Q5：«access» 和 «import» 有什么区别？
这常常是混淆的来源。两者都允许可见性，但命名空间的行为不同。
- «import»： 供应商包中的名称会被添加到客户端包的命名空间中。你可以使用简单名称（无需前缀）来引用供应商包中的类。
- «access»： 名称是可见的，但必须使用限定名称（前缀）来访问它们。客户端包的命名空间保持不变。
使用 import 可以减少代码的冗余，但会增加名称冲突的风险。使用 access 可以保持严格的命名空间分离。
🏗️ 组织大型模型
随着系统规模的扩大，包的数量也随之增加。管理这些交互需要一种在组织性与灵活性之间取得平衡的策略。
分层与关注点分离
按架构层组织包是一种标准做法。这确保了依赖关系单向流动，通常是从高层到低层。
- UI层： 依赖于应用逻辑。
- 应用逻辑： 依赖于领域模型。
- 领域模型： 依赖于基础设施。
避免让基础设施层依赖于UI层。这会导致依赖倒置，使测试和部署变得复杂。
垂直切片
与水平分层不同，某些架构使用垂直切片。每个切片都包含交付特定功能所需的所有包。
- 功能包 A： 包含功能 A 的 UI、逻辑和数据。
- 功能包 B： 包含功能 B 的 UI、逻辑和数据。
这种方法支持独立部署。然而，如果共享功能没有被提取到一个公共包中，可能会导致代码重复。
Q6：如何处理共享工具？
为通用功能（如日志记录、字符串操作或数学计算）创建一个专用包。其他包应依赖于此通用 包。
- 保持此包尽可能小且稳定。
- 不要在通用包中添加业务逻辑。
- 确保通用包不依赖于其他业务包，以避免循环依赖。
⚠️ 常见错误与修正
即使是经验丰富的建模者也会犯错。及早识别这些模式可以节省大量返工时间。
错误 1：过度细化
创建过多小型包会导致出现混乱的依赖图，其中每个包几乎都依赖于其他所有包。如果你发现自己为单个类创建包，应重新考虑结构。
- 修正： 合并具有单一一致目的的包。将相关的类组合在一起。
错误 2：隐式依赖
建模者有时会省略依赖箭头，因为他们认为关系显而易见。UML 要求使用显式符号以避免歧义。
- 修正： 每个使用关系都应明确绘制。如果包 A 使用包 B 中的元素，则应绘制依赖关系。
错误 3：混用实现与接口
通常会将接口定义和具体实现放在同一个包中。这可能会使以后更换实现变得困难。
- 更正： 将接口分离到一个 API 包中，将实现分离到一个 Impl 包中。API 包不应依赖 Impl 包。
📊 分析耦合度量
可以通过度量来分析包之间的交互，以评估模型的健康状况。高耦合度表示脆弱性，而高内聚度则表示稳健性。
对象之间的耦合度（CBO）
尽管这一概念通常应用于类，但它同样适用于包。衡量一个包依赖于其他包的数量。
- 低 CBO： 该包是独立的，易于测试。
- 高 CBO： 该包脆弱，其他包的更改会对其产生显著影响。
入向耦合（Ca）
这衡量的是有多少包依赖于当前包。高入向耦合表明该包是核心组件。更改它需要仔细考虑。
出向耦合（Ce）
这衡量的是当前包依赖于多少个其他包。高出向耦合表明该包严重依赖其他包。这通常是工具层的标志。
🚀 维护的最佳实践
保持模型的整洁需要纪律。以下是一些实用步骤，以确保包之间的交互保持清晰。
1. 定义命名规范
一致的命名有助于开发者在不阅读代码的情况下理解关系。使用前缀或后缀来表示包的角色。
- core： 核心领域逻辑。
- service： 业务逻辑和编排。
- data： 持久化和数据库访问。
2. 记录设计意图
使用注释或文档字段来解释为什么存在依赖关系。并非所有依赖都是代码级别的；有些是架构需求。
3. 定期重构
随着需求的变化，依赖关系也会随之改变。定期审查包图以识别：
- 未使用的依赖。
- 循环引用。
- 包之间的职责重叠。
4. 强制执行构建规则
使用构建工具来强制执行模型中定义的依赖结构。如果模型表明包A依赖于包B，构建脚本就应该反映这一点。如果代码违反了这一规则，构建应失败。这确保了文档与实际情况一致。
🧩 高级交互场景
有时，标准关系无法捕捉系统的复杂性。高级场景需要仔细建模。
Q7：我该如何建模框架集成？
在与外部框架集成时，你通常会从该框架导入包。你应该将框架视为供应商包。
- 使用«import»构造型来引入必要的类。
- 将你的业务逻辑与框架的内部包隔离。
- 记录框架的版本以追踪兼容性。
Q8：包之间的版本控制怎么办？
当包演进时，版本号变得重要。你可以在包名称中表示版本，或作为属性。
- 版本 1：初始发布。
- 版本 2：向后兼容的更改。
- 版本 3：破坏性更改。
依赖项应指定所需的最低版本。这可以防止在升级包时出现运行时错误。
📝 关键要点总结
包之间的交互构成了UML模型的结构完整性。通过理解依赖、关联和可见性规则之间的细微差别，你可以创建准确反映系统设计的图表。
需要记住的关键点：
- 明确优于隐式：始终绘制依赖箭头。
- 保持耦合度低：避免循环依赖和过度的跨包使用。
- 使用构造型：使用诸如以下标签来明确交互类型：
«导入»或«访问». - 尊重可见性：使用公共、私有和受保护的修饰符来控制访问。
- 分层你的架构：确保依赖关系从用户界面到数据层逻辑流动。
遵循这些原则将产生一个不仅作为视觉辅助工具，更是开发功能蓝图的模型。它减少了工程团队的歧义，并在无需承担技术债务负担的情况下支持系统的长期演进。