UML 类图概念、规范、实现

我目前正在阅读 Martin Fowler 的《UML Distilled》。我刚刚介绍了有关类图的部分，他在其中强调了在对类图进行建模之前理清自己的观点的必要性。然而，在实际绘制类图时，我对它的实际外观有点困惑。例如，我理解理论含义会改变关联的含义从一个角度到下一个角度。

我想我的主要问题是，如果我像他在书中那样建模一个简单的排序系统，那么从一个角度到另一个角度，类图看起来会有所不同并且包含不同数量的符号。例如，从概念的角度来看，我只会显示类和一些模糊的关联及其多重性，然后在规范角度进行建模时包括可导航性和基本的类操作和字段。

我真的很感谢对此的一些指导，因为我真的很想更好地掌握这个主题。

好问题。以下是我根据自己的经验得出的一些想法；不能说马丁是否会同意（！）但希望仍然有用。

总之：主要区别来自于关系的形式和设计选择。

我发现以下有用：

• 基本结构：大致映射到Fowler的UML作为草图，并在白板上交互地完成。主要目的是了解整体结构。非常不正式。特别是，对关系的关注只是为了识别它们，而不是形式化 - 因此没有基数、删除行为、容器类的选择等。

• 域模型。一个精确的模型，专注于形式化关系。具体来说，命名关联结束、定义基数并确认删除行为。不考虑可导航性或基数 >1 的容器类选择。我所知道的学习问题领域的最佳技术之一。

我几乎总是会使用以上两者。领域模型的关键是使用基于动词的命名而不是基于角色的命名 - 因为它描述了关系存在的原因（有效地表达了业务规则：例如“订单必须由一个客户下达”）。我使用中描述的命名模板西姆森和维特 https://rads.stackoverflow.com/amzn/click/com/0126445516's book.

将领域模型转换为工作代码还有很多工作要做，特别是在关系方面。编程语言不能很好地支持关系，因此必须将关联转换为参与类的属性。正是在这一点上，可导航性以及多重性 >1 的集合类型的选择开始发挥作用。这也是需要指定所有操作的地方。我个人并不认为这种类型的图表特别有用。领域模型加上代码给了我所需的一切。

如果我使用可执行的 UML 工具，我只会使用“UML 作为编程语言”。

如果说得有点啰嗦，请见谅，希望对你有帮助……

PS：如果你想要一个更好的基于动词的命名的例子，我有一个在我的博客上发帖 http://randomcognition.blogspot.com/2009/03/relationships-are-more-fun.html。请不要将此视为自我推销，这里没有必要重复。