UML类图概念、规范和实现的区别

Question

UML类图概念、规范和实现的区别

7

我正在阅读马丁·福勒的《UML精简版》。我刚刚阅读了有关类图的部分，他强调在建模类图之前需要梳理好自己的视角。但是，当实际绘制类图时，我还是有些困惑。例如，我知道从一个视角到另一个视角，理论上会改变关联的含义。

我的主要问题是，如果我像书中所示一样对一个简单的订购系统进行建模，不同视角下的类图是否会有所不同，并包含不同数量的符号。例如，在概念视角下，我只需要展示类和一些模糊的关联以及它们的多重性；而在规范视角下，我则需要包括导航性、基本类操作和字段。

我真的很希望能得到一些指导，因为我真的想更好地掌握这个主题。

- Simon H

“具有目的感的建模”是一篇由John Daniels于2002年发表在Martin Fowler网站上的IEEE文章。该文章描述了概念模型、规范模型和实现模型之间的有用区别。 - Nick Alexeev

4个回答

3

这是我向开发人员解释这些概念的方法。

- 概念层：定义关系。耦合应该在这个层次上发生。你不应该从概念到实现看到耦合 - 这表明设计不良。 - 规范层：定义算法，但不定义实现。在类图中，可以表示为抽象类。Alan Shalloway将属于这个领域的方法称为"指挥官方法"：它们只是下达命令。 - 实现层：实际工作发生的地方。这可以由实现您的抽象规范的具体类表示。

- Cory Foy

2

确切地说，UML类图只是一种符号表示法，您可以（并且应该）根据软件开发阶段的不同而进行不同的处理。您可以从仅包含类、属性和关联开始，然后完善图表以添加属性类型信息、导航、类方法、关联限定词……直到获得一个准备好进入实现阶段的完整类图。

请注意，您甚至可以迭代到删除关联并用复杂类型的属性替换它们的程度，以获得更接近最终实现的类图。如何在每个阶段使用类图取决于您。

- Jordi Cabot

0

Martin Fowler的书对我来说真是没用（例如我的个人感觉），只要他开始谈论类图，我就觉得无聊透顶！我同意其他图表，但类图应该更加实用，而不仅是高层次设计！

总是相同的理论，你需要在更高的抽象层次上进行建模，然后再建立你真正需要的模型。我更喜欢快速提供运行代码并向客户展示。在第一阶段，我们从展示功能需求和代码开始建模。完成第二阶段后，我们再次向客户展示并提供UML类图以更改所需的部分。经过10次迭代，我的项目通常就完成了。例如，我的项目持续3到6个月。这是一个非常复杂的项目，我的客户通常都很满意。如果按照Martin Fowler的建议，我的项目将需要12-18个月才能完成，客户肯定会失望。

- UML GURU

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- sfinnie · Accepted Answer

好问题。以下是我自己的经验分享，不敢说Martin是否同意，但希望能有所帮助。

总结一下：主要区别在于形式和关系设计选择。

我发现以下内容很有用：

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

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

我几乎总是同时使用上述两种方法。从领域模型中的关键点是使用基于动词的命名而不是基于角色的命名，因为它描述了关系存在的原因（有效地呈现业务规则：例如，“一个订单必须由一个客户下单”）。我使用Simsion & Witt书中描述的命名模板。

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

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

如果有点啰嗦，还请见谅，希望有所帮助...

PS：如果你想要一个更好的基于动词命名的例子，我在我的博客上有一篇文章。请不要把这看作是自我推销，只是没必要在这里重复。