聚合或组合或简单的关联？ [英] Aggregation or composition or simple association?

问题描述

有一个例子，在UML解释关联。

There is one example to explaining associations in UML.

一个人在一家公司;公司设有多个办事处。

A person works for a company; a company has a number offices.

但我无法理解的人，公司和Office类之间的关系。我的理解是：

But I am unable to understand the relationship between Person, Company, and Office classes. My understanding is:

1. 公司由许多人的员工，但这些类独立存在，这样是0简单关联.. *在Person类'端的多样性


2. 一个公司拥有众多的办事处，如果没有公司，所以这是组合物，其公司作为父类和0 .. *对科级'端的多样性。
这些办事处将不存在

1. a company consists of many persons as employees but these classes exist independently so that is simple association with 0..* multiplicity on Person class' end
2. a company has many offices and those offices will not exist if there is no company so that is composition having Company as the parent class and 0..* multiplicity on Branch class' end.

但我不知道第二个点。如果我错了，请大家指正。

But I am not sure of 2nd point. Please correct me if I am wrong.

感谢您。

推荐答案

为什么要使用组合或聚合在这种情况下呢？在UML规范离开聚集到建模的含义。那你想让它意味着你的观众？和组成的意思大概是这种情况太强大了。因此，为什么在这里使用它呢？我建议你​​使用一个简单的关联。

Why use composition or aggregation in this situation at all? The UML spec leaves the meaning of aggregation to the modeler. What do you want it to mean to your audience? And the meaning of composition is probably too strong for this situation. Thus, why use it here? I recommend you use a simple association.

如果我是你，我会留到更真实的问题域。在我所知道的世界上，办事处不停止时，公司倒闭的存在。相反，一个公司的占据的为一些有限的时间一定数目的办事处。如果公司倒闭，该办事处得到出售或出租给其他公司。该办事处没有被夷为平地。

If I were you, I would stay truer to the problem domain. In the world I know, Offices don't cease to exist when a Company goes out of business. Rather, a Company occupies some number of Offices for some limited period of time. If a Company goes out of business, the Offices get sold or leased to some other Company. The Offices are not burned to the ground.

如果你不是真正的在应用程序的问题域，然后你把快捷方式将会失效时客户更改要求该应用程序。域名的问题实际上并没有太大变化，只是你被允许采取捷径。如果你走捷径，以满足未对齐的问题领域的方式的要求，它是昂贵的调整申请。您的客户变得不快乐，你风加班。保存自己和大家的烦恼！

If you aren't true to the problem domain in an application, then the shortcuts you take will become invalid when the customer "changes the requirements" for that application. The problem domain doesn't actually change much, just the shortcuts you are allowed to take. If you take shortcuts to satisfy requirements in a way that are misaligned with the problem domain, it is expensive to adjust the application. Your customer becomes unhappy and you wind up working overtime. Save yourself and everyone the trouble!

这篇关于聚合或组合或简单的关联？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！