UML 类图概念 vs 规范 vs 实现
我目前正在阅读 Martin Fowler 的《UML Distilled》。我刚刚介绍了有关类图的部分，他在其中强调了在对类图进行建模之前理清自己的观点的必要性。然而，在实际绘制类图时，我对它的实际外观有点困惑。例如，我理解理论含义会改变关联的含义从一个角度到下一个角度。
我想我的主要问题是，如果我像他在书中那样建模一个简单的排序系统，那么从一个角度到另一个角度，类图看起来会有所不同并且包含不同数量的符号。例如，从概念的角度来看，我只会显示类和一些模糊的关联及其多重性，然后在规范角度进行建模时包括可导航性和基本的类操作和字段。
我真的很感谢对此的一些指导，因为我真的很想更好地掌握这个主题。
I am currently reading Martin Fowler's UML Distilled. I have just covered the section on class diagrams, where he places strong emphasis on the need to sort out ones perspective before modelling class diagrams. However, I am slightly confused as to how this looks practically when actually drawing class diagrams. I understand that the theoretical implications change the meaning of an association from one perspective to the next for example.
I guess my main question would be that if for example I was modelling a simple ordering system like he does in the book, would the class diagrams look different and contain different amounts of notation from one perspective to another. For example, from a conceptual perspective would I just show the classes and some vague associations and their multiplicity and then when modelling at the specification perspective include navigability and basic class operations and fields.
I would really appreciate some guidance on this as I would really like to have a better grasp of this subject.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好问题。以下是我根据自己的经验得出的一些想法；不能说马丁是否会同意（！）但希望仍然有用。
总之：主要区别来自于关系的形式和设计选择。
我发现以下内容很有用：
基本结构：大致映射到 Fowler 的 UML 作为草图，并在白板上交互地完成。主要目的是了解整体结构。非常不正式。特别是，对关系的关注只是为了识别它们，而不是形式化 - 因此没有基数、删除行为、容器类的选择等。
域模型。一个精确的模型，专注于形式化关系。具体来说，命名关联结束、定义基数并确认删除行为。不考虑基数>1 的可导航性或容器类的选择。我所知道的学习问题域的最佳技术之一。
我几乎总是会使用以上两者。域模型的关键是使用基于动词的命名而不是基于角色的命名 - 因为它描述了关系存在的原因（有效地表达了业务规则：例如“订单必须由一个客户下达”）。我使用 Simsion & 中描述的命名模板。维特的书。
将领域模型转换为工作代码还有很多工作要做，特别是在关系方面。编程语言不能很好地支持关系，因此必须将关联转换为参与类的属性。正是在这一点上，可导航性以及多重性>1的集合类型的选择开始发挥作用。这也是需要指定所有操作的地方。我个人并不认为这种类型的图表特别有用。领域模型加上代码给了我所需的一切。
如果我使用可执行的 UML 工具，我只会使用“UML 作为编程语言”。
抱歉，如果这有点漫无目的，希望它有所帮助...
PS：如果您想要基于动词的命名的更好示例，我有一个 在我的博客上发帖。请不要将此视为自我推销，这里没有必要重复。
Good question. Here's some thoughts from my own experience; can't say whether Martin would agree (!) but hopefully useful nonetheless.
In summary: main difference comes from formality and design choices for relationships.
I have found the following useful:
Basic structure: roughly maps to Fowler's UML as sketch, and done on the whiteboard interactively. Main purpose is to understand overall structure. Very informal. In particular, focus on relationships is just to identify them, not formalise - so no cardinality, delete behaviour, choice of container classes, etc.
Domain Model. A precise model, focused on formalising the relationships. Specifically, naming the association ends, defining cardinality and confirming delete behaviour. Does not consider navigability or choice of container classes for cardinality >1. One of the best techniques I know for learning a problem domain.
I'll nearly always use both of the above. Key thing from the domain model is to use verb-based naming rather than role based - because it describes why the relationship exists (effectively surfaces business rules: e.g. "An order must be placed by exactly one Customer"). I use the naming template described in Simsion & Witt's book.
There's work to be done in translating the domain model to working code, specifically in the relationships. Programming languages don't support relationships very well, so the associations have to be translated into attributes of the participating classes. It's at that point that navigability comes into play, along with choice of collection type for multiplicity >1. It's also where all the operations need to be specified. I don't personally find this type of diagram particularly useful. A domain model plus the code give me everything I need.
I'll only ever use "UML as programming language" if I'm using an executable UML tool.
Apologies if that's a bit rambling, hope it helps...
PS: If you want a better example of verb-based naming, I have a post on my blog. Please don't take that as self-promotion, just no point in repeating here.
以下是我向开发人员解释这些想法的方式。
概念是关系。这是耦合应该发生的级别。您不应该看到从概念到实现的耦合 - 这是设计不佳的信号。
规范定义了算法，但没有定义实现。在类图中，这可能表示为抽象类。艾伦·沙洛韦将属于这一领域的方法称为“中士方法”：他们只是发出命令。
实施是实际工作发生的地方。这可能由实现抽象规范的具体类来表示。
Here's how I explain the ideas to developers.
Conceptual is the relationships. This is the level where coupling should happen. You shouldn't see coupling from conceptual to implementation - that's a signal of a poor design.
Specification defines the algorithm without defining the implementation. In a class diagram, this might be represented as an abstract class. Alan Shalloway calls methods which fall into this realm "Sergeant methods": They just bark orders.
Implementation is where the actual work happens. This might be represented by concrete classes which implement your abstract specifications.
确切地说，UML 类图只是一种表示法，根据您所处的软件开发阶段，您可以（并且应该）采用不同的表示法。您可以仅从类、属性和关联开始，然后细化该图以添加属性的类型信息，然后导航、类方法、关联限定符...直到为实现阶段准备好完整的类图。
请注意，您甚至可以迭代到删除关联并用复杂类型的属性替换它们以拥有一个类该图与最终实现更加相似。如何在每个阶段使用类图取决于您。
Exactly, UML class diagrams are just a notation that you could (and should) differently depending on the sofware development phase you are in. You can start with only classes, attributes and associations, then refine the diagram to add types information for the attributes, then navigation, class methods, qualifiers for associations ... until you get a complete class diagram ready for the implementation phase
Note that you could even iterate to the point in which you remove associations and replace them by attributes of complex types to have a class diagram even more similar to the final implementation. It's up to you how to use class diagrams in each phase.
马丁福勒的书对我来说就是垃圾（例如我个人的感觉），一旦他开始谈论类图！我同意其他图，但类图应该更实用，而不仅仅是高层设计！
您需要在更高的抽象级别进行建模，然后对您真正需要的内容进行建模，这始终是相同的理论。
我更喜欢快速提供运行代码并将其展示给客户。从第一阶段开始，我们开始建模，以便满足功能需求和代码需求。一旦我们完成第二阶段，我们就会再次向客户展示它，并再次提供 UML 类图来更改需要完成的操作。经过 10 次迭代后，我的项目通常就完成了。
例如我的项目持续了 3 到 6 个月。这是一个非常复杂的项目，我的客户通常都很满意。如果按照 Martin Fowler 的建议，我的项目将在 12-18 个月内无法完成，客户肯定会感到失望。
Martin fowler's books are crap for me (e.g my personal feeling) as soon as he is starting to talk about the class diagram!! I agree for the other diagrams but the class diagram should be more pragmatic and not just high level designs !!
It is always the same theory that you need to model at higher level of abstraction and then to model what you really need.
I prefer to quickly provide a running code and show it to the customer. From that first stage we start modeling in order to have functional demands but also code. Once we finish this second stage we show it again to the customer and again provides UML class diagrams to change what need to be done. After 10 iterations my project is usually finished.
For example my project last 3 to 6 months. This is a really complex project and my customers is usually satisfied. Using Martin fowler's recommendation my project would have not been finished in 12-18 months and the customer would certainly be disappointed.