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