我目前正在阅读 Martin Fowler 的 UML Distilled。我刚刚介绍了关于类图的部分，他非常强调在建模类图之前需要理清一个观点。但是，我对实际绘制类图时的实际外观感到有些困惑。我理解理论含义会改变关联的含义，例如从一个角度到另一个角度。
我想我的主要问题是，例如，如果我像他在书中所做的那样对一个简单的排序系统进行建模，那么从一个角度到另一个角度，类图是否会看起来不同并且包含不同数量的符号。例如，从概念的角度来看，我会只展示类和一些模糊的关联及其多样性，然后在规范角度建模时包括可导航性和基本的类操作和字段。
我非常感谢您对此提供一些指导，因为我真的很想更好地掌握这个主题。
【问题讨论】：
好问题。以下是我个人经验的一些想法；不能说马丁是否会同意（！）但希望仍然有用。
总之：主要区别在于关系的形式和设计选择。
我发现以下有用：
基本结构：大致映射到 Fowler 的 UML 作为草图，并在白板上交互完成。主要目的是了解整体结构。非常非正式。特别是，关注关系只是为了识别它们，而不是形式化 - 因此没有基数、删除行为、容器类的选择等。
域模型。一个精确的模型，专注于关系的形式化。具体来说，命名关联结束，定义基数并确认删除行为。不考虑基数 >1 的可导航性或容器类的选择。我所知道的用于学习问题领域的最佳技术之一。
我几乎总是会使用上述两种方法。领域模型的关键是使用基于动词的命名而不是基于角色的命名——因为它描述了关系存在的原因（有效地展示了业务规则：例如，“订单必须由一个客户下单”）。我使用Simsion & Witt的书中描述的命名模板。
在将域模型转换为工作代码方面需要做一些工作，特别是在关系方面。编程语言不能很好地支持关系，因此必须将关联转换为参与类的属性。正是在这一点上，可导航性开始发挥作用，同时选择多重性> 1的集合类型。这也是需要指定所有操作的地方。我个人并不觉得这种类型的图表特别有用。域模型加上代码给了我我需要的一切。
如果我使用的是可执行的 UML 工具，我只会使用“UML 作为编程语言”。
抱歉，如果这有点漫不经心，希望对您有所帮助......
PS：如果你想要一个更好的基于动词命名的例子，我有一个post on my blog。请不要把这当成是自我推销，这里不再赘述。
【讨论】：
UML tag 的努力，你真的很棒，我希望你继续在你的博客中写关于UML 和相关主题的文章。我希望我也能这样做，但我我还是初学者
以下是我向开发人员解释这些想法的方式。
概念是关系。这是应该发生耦合的级别。你不应该看到从概念到实现的耦合——这是一个糟糕设计的信号。
规范定义算法而不定义实现。在类图中，这可能表示为抽象类。 Alan Shalloway 将属于这个领域的方法称为“中士方法”：他们只是发出命令。
实施是实际工作发生的地方。这可能由实现您的抽象规范的具体类来表示。
【讨论】：
确切地说，UML 类图只是一种符号，您可以（并且应该）根据您所处的软件开发阶段不同。您可以仅从类、属性和关联开始，然后细化图表以添加类型信息属性，然后是导航、类方法、关联限定符……直到你为实现阶段准备好完整的类图
请注意，您甚至可以迭代到删除关联并用复杂类型的属性替换它们的点，以获得更类似于最终实现的类图。如何在每个阶段使用类图取决于您。
【讨论】：
Martin Fowler 一开始谈论类图，他的书对我来说就是垃圾（例如我个人的感觉）！我同意其他图表，但类图应该更实用，而不仅仅是高级设计！
您需要在更高的抽象层次上建模，然后再建模您真正需要的东西，这始终是同一个理论。 我更喜欢快速提供运行代码并将其展示给客户。从第一阶段开始，我们开始建模，以便有功能需求和代码。一旦我们完成了第二阶段，我们将再次向客户展示它，并再次提供 UML 类图来更改需要完成的工作。经过 10 次迭代后，我的项目通常完成。 例如我的项目持续 3 到 6 个月。这是一个非常复杂的项目，我的客户通常都很满意。如果使用 Martin fowler 的建议，我的项目将不会在 12 到 18 个月内完成，客户肯定会感到失望。
【讨论】：