Architecture 应该首先创建哪个ER图或类图？

我创建DFD的第一步。然后我继续创建一个类图。在这样做的时候，我觉得我应该先创建ER图。因为有许多细节无法在类图中捕获。 那么，我的问题是，我应该创建ERD优先图还是类图

---

非常感谢你们的宝贵意见！！！感谢您阅读ER图，因为它们包含的信息比对象图少，对象图包含了更多关于对象和继承树的方法的信息，所以ER图将错过这两个元素

---

因此，最好从对象层次结构（类图）开始，然后转到事物的映射端；）

在建模时，我倾向于按照当时对我最有意义的顺序绘制图表。有时首先是类图，有时是实体关系图，有时甚至是序列图。要记住的主要一点是，你试图理解一些事情，并把它们写下来，以便其他人也能理解它们；担心什么是整理思想的最佳方式，远不如认真地写下那些你确实理解的部分

---

[编辑]：FWIW，我也倾向于在纸上或白板上开始建模，只有当我越来越接近我所了解的情况时，我才会切换到使用计算机。（我想我只是不喜欢在计算机上画画。）关键是建模是关于理解，而不是（非常）关于计算机。

面向对象纯粹主义者倾向于先做类图。有数据库背景的人首先做ER图，然后从中“派生”类图（这种方法受到OO纯粹主义者的反对）

我更喜欢混合方法

首先确定实体。从数据库和应用程序（类）的角度来看，这应该是相同的

一旦您在高层对实体达成一致，就可以并行地处理类图和ER图，因为每种关系中的“关系”是不同的。（如果您是唯一一个处理它们的人，那么首先从类图开始，然后是ERD。但首先要确定实体）

---

在我看来，数据库和应用程序（Java/C#…）上的高级实体应该是相同的。使用公共基础非常容易——特别是如果有不同的人在不同的部分（类、数据库）上工作的话。

我认为这取决于您的应用程序&我对UML有一点了解，我知道您可以使用标准UML类图来建模关系多样性以及主键，所以类图通常就足够了。我喜欢从类图开始，因为我喜欢使用面向对象的分析和设计、用例、用例实现和分析类。另一方面，好的数据库设计要求规范化，有时要求非规范化，对数据查询进行不同的优化。。。但对于这一点，首先我需要知道我将查询什么，以及可能如何查询。我个人认为大多数应用程序的关系部分只是一种存储机制，我从面向对象编程的角度考虑系统。这对于RubyonRails尤其有用，这要归功于活动记录模式完全从关系模型中抽象出来，因此我不必再建模两次。

为什么从较少（更一般）的信息开始是不好的？这是一种从更高层次开始，并在进行过程中提供更多细节的常见方法。你首先要做一些设计决策，比如一个人是否应该和宠物有关系，而不是我们是否应该在对象模型中包含一个人的名字和姓氏。但是无知是没有好处的。忽略继承意味着您最终会遇到愚蠢的设计，例如客户表中的对象“customer”，员工表中的对象“employee”，等等。是的，我同意您当时尽可能具体。如果您尚未充实属性，您可能会发现映射关系是合乎逻辑的第一步。