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

Question

我创建DFD的第一步。然后我继续创建一个类图。虽然这样做我觉得我应该首先创建ER图。因为有许多细节无法在类图中捕获。 所以，我的问题是我应该先创建ERD OR Class Diagrams吗？

你的宝贵意见得到赞赏！感谢您的阅读

Answer 1

在建模时，我倾向于考虑按照当时对我最有意义的顺序做图表。有时这首先是类图，有时候是实体关系图，有时甚至是序列图。要记住的主要事情是你试图理解并把它们写下来，以便其他人也能理解它们;如果想知道订购你的想法的最佳方式是什么，那就不仅仅是为了解决它并编写你 所理解的那些部分。

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

Answer 2

OO纯粹主义者倾向于先做类图。具有数据库背景的人首先执行ER图并从中“派生”类图（这种方法被OO纯粹主义者不赞成）

我更喜欢混合方法。

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

一旦您就高级别的实体达成一致，请按照并行方向继续进行类图和ER图 - 因为每个“关系”都不同。 （如果你是唯一一个处理它们的人，那么首先从类图开始，然后从ERD开始。但是首先确定有权的。）

在我看来，高级实体应该在数据库和应用程序（Java / C＃...）上相同。并且很容易继续使用公共基础 - 特别是如果有不同的人在不同的部分（类，数据库）工作。

Answer 3

我会说这实际上取决于你的申请。 ＆amp;我对UML有点了解，我知道你可以使用标准的UML类图来建模关系多重性以及主键，所以通常类图就足够了。我喜欢从类图开始，因为我喜欢使用面向对象的分析和设计，用例，用例实现和分析类。另一方面，良好的数据库设计要求规范化，有时还要求非规范化，对数据查询进行不同的优化......但首先，我需要知道我将要查询的内容以及可能的方法。我个人认为大多数应用程序的关系部分只是作为存储机制，我在面向对象编程方面考虑系统。这对于例如Ruby on Rails特别有用，这要归功于Active Record模式完全从关系模型中抽象出来，所以我不需要模拟两次。

Answer 4

ER图作为开始时很糟糕 - 因为它们包含的LESS信息比对象图少，其中包含有关对象和继承树方法的更多信息 - 这两个元素都将错过ER图。

因此，您最好从对象层次结构（类图）开始，然后移动到映射方面;）