第一步我创建了一个 DFD。然后我继续创建一个类图。在这样做的同时，我觉得我应该首先创建 ER 图。因为有许多细节无法在类图中捕获。所以，我的问题是我应该先创建 ERD 还是类图？
感谢您的宝贵意见！谢谢阅读
问问题
6565 次
4 回答
12
在建模时，我倾向于按照当时对我来说最有意义的任何顺序来制作图表。有时首先是类图，有时是实体关系图，有时甚至是序列图。要记住的主要事情是，您正在尝试理解事物并将其写下来，以便其他人也能理解它们；担心什么是最好的整理你的想法的方法并不像只写下你理解的那些部分那么有用。
[编辑]：FWIW，我也倾向于在纸上或白板上开始我的建模，并且只有在我越来越接近我所理解的情况时才切换到使用计算机。（我想我只是不喜欢在计算机上绘图。）关键是建模是关于理解，而不是（非常）关于计算机。
于 2010-04-26T09:39:30.957 回答
3
OO 纯粹主义者倾向于先做类图。有数据库背景的人先做 ER 图，然后从中“派生”出类图（OO 纯粹主义者不赞成这种方法）
我更喜欢混合方法。
首先识别实体。从数据库和应用程序（类）的角度来看，这应该是相同的。
一旦您在高层上就实体达成一致，请继续并行方向的类图和 ER 图 - 因为每个“关系”都不同。（如果你是唯一一个研究它们的人，那么首先从类图开始，然后是 ERD。但首先确定实体）。
在我看来，数据库和应用程序（Java/C#...）上的高级实体应该是相同的。使用通用基础非常容易 - 特别是如果有不同的人在不同的部分（类、数据库）上工作。
于 2010-04-26T09:54:36.193 回答
2
我会说这真的取决于你的应用程序。&我对 UML 有所了解，并且我知道您可以仅使用标准 UML 类图对关系多重性和主键进行建模，因此类图通常就足够了。我喜欢从类图开始，因为我喜欢使用面向对象的分析和设计、用例、用例实现和分析类。另一方面，良好的数据库设计要求规范化，有时需要非规范化，数据查询的不同优化......但为此，首先我需要知道我将查询什么以及可能如何查询。我个人认为大多数应用程序的关系部分只是一种存储机制，我从面向对象编程的角度来考虑系统。这对于例如 Ruby on Rails 尤其有用，
于 2010-04-26T16:02:48.870 回答
0
ER 图很糟糕——因为它们包含的信息比对象图少，对象图包含更多关于对象和继承树的方法的信息——这两个元素都会被 ER 图遗漏。
因此，您最好从对象层次结构（类图）开始，然后转到事物的映射方面；）
于 2010-04-26T09:38:48.887 回答