通知应该是 class 图表中的 class 吗？
Should notifications be a class in the class diagram?
假设我为社交网络系统（例如 facebook）制作了一个 class 图。通知和讨论消息是否应该有自己的 classes？
我确实认为他们应该这样做。我为这样的系统制作了一个完整的 class 图，通知和消息为 classes，但我的老师告诉我要排除它们。现在我很困惑。
由于三个原因，这是一个非常有趣的问题。
1。范围是什么？
这是您在开发人员职业生涯中从事的任何工作的核心问题：系统的范围是什么？
- 它是否只是一对多通信的核心社交网络功能，就像您早期在 Facebook 上使用的那样？
- 或者它是 facebook 的完整克隆，包括它的消息传递功能，还有它的广告和调节功能？
如果是第一个，那你做的太多了。如果是第二个，你忘记了重要的部分。
规则 1： 每当对范围有疑问时，请先用 coach/manager/stakeholder 澄清一下，然后再认为您知道该做什么。
这将避免您因从事不受重视的工作而感到沮丧。这将避免您的未来客户因没有得到他们期望的东西或为他们没有要求的东西付出太多而感到沮丧。
2。方法是什么？
每当您对某些软件进行建模时，都是有目的的。 Class 图表可用于不同的目的。例如：
- 是为了分析需求吗？在这个域中，你肯定会有
Post、Comment 和 UserAccounts 的 class 以及它们之间的关联。但是您会将自己局限于“问题 space”，而不是解决软件解决方案及其 UI.
- 是为了设计的系统？那么它可能应该说明系统将如何工作，并提供有关 UI 将如何与域对象交互的更多详细信息。这种图表可能会更详细并显示“解决方案space”。
规则 2：如果被要求做一些建模，一定要明确目的。在现实世界中，如果没有明确要求建模，请阐明您团队中商定的方法。
3。始终向最接近消息来源的人澄清
(字幕已经是规则)
现在，通知是 UI 的一部分，因为它们显示已更改的帖子并且它是解决方案设计的一部分吗？或者它是域的一部分，因为通知的需要独立于所选择的软件解决方案？而且因为还需要跟踪和传递通知，并且它们在移动应用程序（推送）和网页（拉取）上的工作方式不同？如您所见，有一定的解释空间，根据his/her论点，老师不一定是错的。
结论
如你所见，这没有对错之分：两者之间有很多细微差别。有很多理由可以证明你老师的立场是正确的。我至少看到另外两个不相关的：
- 根据您的平均能力调整练习时间 class（这对您来说是个好兆头）
- 因为老师已经知道接下来的问题，并且 he/she 已经知道通知会让事情变得更加困难（这表明老师很好）。
我的建议：相信你的老师，无论如何都要进行讨论以理解论点，然后再迅速得出未经证实的结论。
要点：需求分析和建模是一种交流 activity 而不是技术 activity。每当有疑问时，在网上向陌生人寻求建议之前，先与您的利益相关者进行讨论 ;-)
假设我为社交网络系统（例如 facebook）制作了一个 class 图。通知和讨论消息是否应该有自己的 classes？
我确实认为他们应该这样做。我为这样的系统制作了一个完整的 class 图，通知和消息为 classes，但我的老师告诉我要排除它们。现在我很困惑。
由于三个原因，这是一个非常有趣的问题。
1。范围是什么？
这是您在开发人员职业生涯中从事的任何工作的核心问题：系统的范围是什么？
- 它是否只是一对多通信的核心社交网络功能，就像您早期在 Facebook 上使用的那样？
- 或者它是 facebook 的完整克隆，包括它的消息传递功能，还有它的广告和调节功能？
如果是第一个，那你做的太多了。如果是第二个，你忘记了重要的部分。
规则 1： 每当对范围有疑问时，请先用 coach/manager/stakeholder 澄清一下，然后再认为您知道该做什么。
这将避免您因从事不受重视的工作而感到沮丧。这将避免您的未来客户因没有得到他们期望的东西或为他们没有要求的东西付出太多而感到沮丧。
2。方法是什么？
每当您对某些软件进行建模时，都是有目的的。 Class 图表可用于不同的目的。例如：
- 是为了分析需求吗？在这个域中，你肯定会有
Post、Comment和UserAccounts的 class 以及它们之间的关联。但是您会将自己局限于“问题 space”，而不是解决软件解决方案及其 UI. - 是为了设计的系统？那么它可能应该说明系统将如何工作，并提供有关 UI 将如何与域对象交互的更多详细信息。这种图表可能会更详细并显示“解决方案space”。
规则 2：如果被要求做一些建模，一定要明确目的。在现实世界中，如果没有明确要求建模，请阐明您团队中商定的方法。
3。始终向最接近消息来源的人澄清
(字幕已经是规则)
现在，通知是 UI 的一部分，因为它们显示已更改的帖子并且它是解决方案设计的一部分吗？或者它是域的一部分，因为通知的需要独立于所选择的软件解决方案？而且因为还需要跟踪和传递通知，并且它们在移动应用程序（推送）和网页（拉取）上的工作方式不同？如您所见，有一定的解释空间，根据his/her论点，老师不一定是错的。
结论
如你所见，这没有对错之分：两者之间有很多细微差别。有很多理由可以证明你老师的立场是正确的。我至少看到另外两个不相关的：
- 根据您的平均能力调整练习时间 class（这对您来说是个好兆头）
- 因为老师已经知道接下来的问题，并且 he/she 已经知道通知会让事情变得更加困难（这表明老师很好）。
我的建议：相信你的老师，无论如何都要进行讨论以理解论点，然后再迅速得出未经证实的结论。
要点：需求分析和建模是一种交流 activity 而不是技术 activity。每当有疑问时，在网上向陌生人寻求建议之前，先与您的利益相关者进行讨论 ;-)