为什么类图不包括所有类？

Question

我见过的大多数UML类图几乎都是ER图，缺少编程的类。

如果我对基于网络的应用感兴趣。这些类具有访问REST资源的类（我认为它们类似于边界元素），它们还包含提供服务或执行操作的类（可能是控制元素），最后是表示数据库中的内容的类（我想要的实体元素）。所以我看到的大多数UML示例只是绘制了实体元素。这是为什么？放置其他类是否太详细了？

例如：执行此2个用户故事的应用程序。

1. 客户端从网页执行登录。
2. 已记录的客户请求订单。

我会为以下类建模：

1. REST类，它接收来自应用程序前端的信息。
2. 登录类，执行搜索和验证REST类接收的信息的操作，然后使用该信息创建用户实例。
3. 用户类，其中包含请求订单的方法。
4. 订单类。

那么为什么所有这些类都没有在类图中建模？

Answer 1

我想这就是你或你在公司工作的公司。

在我看来，只有＆＃34;实体＆＃34;类非常重要，因为它们显示了应用程序的真实设计和结构。如果您必须对应用程序进行编程，那么您并不关心如何从外部数据库/ api收集日期。但是，您需要知道实体之间的关系如何，否则您根本无法处理该项目。

只需使用您或您的团队可以使用的内容，并确保每个人都了解应用程序的结构。在我看来，这种情况没有真正的对错。

Answer 2

UML不是关于图表，而是关于创建模型。图表是模型的特定视图。此视图包含当前视图应突出显示的内容。如果有需要，请放入所有东西。但是要获得图片，您需要将域切割为子域并分别突出显示每个域。

Answer 3

对问题域的分析对软件和数据库系统至关重要。如果不分析问题域，就无法理解系统要求，也无法正确实现系统。急于进入解决方案领域通常是失败项目的根源。

类应该是一种以比不断变化的技术或框架更耐用的方式组织信息和相关代码片段的方式。随着时间的推移，应该能够用 new 技术替换问题域类的实现，以满足非功能性需求。如果你开始使用＆＃34; REST＆＃34;上课时，你已经失去了耐久性，因为REST将在几年内成为其他东西。如果你创建一个＆＃34;登录＆＃34;上课时，你也失去了耐力。当某些近场技术使输入密码完全不相关时会发生什么？你可能会＆＃34;记录＆＃34;用户，但我敢打赌，实施将是错误的。问题领域的变化往往比技术慢得多。例如，＆＃34; trade＆＃34;的域名。自古以来就没有太大变化。

UML对于思考问题域特别有用。有些人喜欢用它来绘制草图，但是其他人已经将UML分析模型编译成代码很长一段时间了。 （有关更多内容，请参阅Mellor和Balcer的书，Executable UML: A Foundation for Model-Driven Architecture或HS Lahman的书，Model-Based Development: Applications。）您可能会惊讶地听到一些非常大的公司使用这一切任务关键型软件的时间。

UML的分析适用性是您倾向于看到更像ER图的UML类图的一个原因。 UML和ER都是分析问题领域的方法; UML可以把它带得更远。您不会看到许多设计模型的另一个原因是大多数开发人员宁愿实现而不是设计。