UML类图概念与规范vs实现

我正在阅读Martin Fowler的UML Distilled。我刚刚介绍了关于类图的部分，他在构建类图之前强调需要对视图进行分类。但是，我对实际绘制类图时的实际情况略有困惑。例如，我理解理论含义会从一个角度改变协会的含义。UML类图概念与规范vs实现

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

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

来源

2011-04-28 Simon H

[用意义建模]（https://martinfowler.com/ieeeSoftware/purpose.pdf）2002年IEEE出版的John Daniels的文章发表在Martin Fowler的网站上。本文描述了概念，规范和实现模型之间的有用区别。 – 2018-02-21 05:30:51

好问题。以下是我自己经历的一些想法;不能说马丁是否会同意（！）但希望有用。

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

我发现下面的有用：

基本结构：大致映射到福勒的UML作为草图，并以交互白板上进行。主要目的是了解整体结构。非常非正式。特别是，关注关系只是为了识别它们，而不是形式化 - 所以没有基数，删除行为，容器类别的选择等。
Domain Model。一个精确的模型，着重于形式化关系。具体来说，命名关联结束，定义基数并确认删除行为。不考虑导航性或选择容器类的基数> 1。我知道用于学习问题域的最好技术之一。

我几乎总是会使用上述两者。领域模型的关键之处在于使用基于动词的命名而不是基于角色 - 因为它描述了关系存在的原因（有效地表达业务规则：例如“一个订单必须由一个客户放置”）。我使用Simsion & Witt的书中描述的命名模板。

将领域模型转换为工作代码需要做的工作，特别是在关系中。编程语言不能很好地支持关系，所以关联必须被翻译成参与类的属性。正是在这一点上，适航性才发挥作用，以及选择多样性> 1的集合类型。这也是需要指定所有操作的地方。我个人觉得这种类型的图表特别有用。域模型加上代码给了我所需要的一切。

如果我使用可执行的UML工具，我将只使用“UML as programming language”。

道歉，如果这是一个有点散漫，希望它可以帮助...

PS：如果你想以动词命名的一个更好的例子，我有一个post on my blog。请不要把它当作自我推销，在这里重复就没有意义。

来源

2011-04-28 07:36:51 sfinnie

好久不见，感谢您在'UML tag'中的努力，您真是太棒了，希望您继续在您的博客中撰写关于UML和相关主题的文章。我希望我能做到这一点，但我仍然是初学者 – user2019510 2013-07-02 20:46:30

一旦他开始谈论班级图，马丁福勒的书对我来说是废话（例如我个人的感觉）！我同意其他图，但类图应该更实用，而不仅仅是高层次的设计！

它始终是相同的理论，你需要在更高的抽象层次进行建模，然后模拟你真正需要的东西。我更愿意快速提供正在运行的代码并将其显示给客户。从第一阶段开始，我们开始进行建模，以便实现功能需求，但也包含代码。一旦我们完成了第二阶段，我们再次向客户展示它，并再次提供UML类图来改变需要完成的事情。经过10次迭代后，我的项目通常会完成。例如我的项目持续3至6个月。这是一个非常复杂的项目，我的客户通常很满意。使用Martin fowler的推荐，我的项目在12-18个月内还没有完成，客户肯定会感到失望。

来源

2011-04-28 08:55:13

确切地说，UML类图只是一个符号，您可以（也应该）以不同的方式取决于您所处的软件开发阶段。您只能从类，属性和关联开始，然后细化图以添加类型信息对于属性，然后是导航，类方法，关联的限定符......直到您获得完整的类图准备执行阶段

请注意，您甚至可以迭代到删除关联并将其替换为复杂类型的属性具有更类似于最终实现的类图。这取决于你如何在每个阶段使用类图。

来源

2011-04-28 10:24:41

下面是我向开发人员解释这些想法的方法。