|
|
1
9
在建模时,我倾向于按照当时对我来说最有意义的顺序来绘制图表。有时是类图,有时是实体关系图,有时甚至是序列图。最重要的是你要记住,你试图理解并把它们写下来,这样其他人也能理解它们;担心什么是最好的方式来安排你的想法,并不像只是开始写下你的想法那样有帮助 做 理解。 [编辑]:fwiw,我也倾向于在纸上或白板上开始我的建模,只有当我越来越接近我所了解的情况时,才会切换到使用电脑。(我想我只是不喜欢在电脑上画画)关键是建模是为了理解,而不是(非常)关于电脑。 |
|
|
2
3
oo纯粹主义者倾向于先做类图。有数据库背景的人首先做er图,然后从中“派生”类图(oo纯粹主义者不赞成这种方法) 我更喜欢混合方法。 首先确定实体。从数据库和应用程序(类)的角度来看,这应该是相同的。 一旦您在一个较高的层次上同意了这些实体,就可以并行地处理类图和er图,因为每个类图和er图中的“关系”是不同的。(如果您是唯一处理它们的人,那么首先从类图开始,然后从erd开始。但首先要确定实体)。 在我看来,高级实体应该是相同的,无论是在数据库和应用程序(Java/C……)。使用公共基础非常容易,特别是如果有不同的人处理不同的部分(类、数据库)。 |
|
|
3
2
我认为这取决于你的申请。&我对UML有一点了解,我知道您可以使用标准UML类图来建模关系的多样性以及主键,所以类图通常就足够了。我喜欢从类图开始,因为我喜欢使用面向对象的分析和设计、用例、用例实现和分析类。另一方面,良好的数据库设计要求规范化,有时要求非规范化,数据查询的不同优化…但为此,首先我需要知道我将查询什么,可能如何查询。我个人认为大多数应用程序的关系部分只是一种存储机制,我从面向对象编程的角度考虑系统。这对于ruby on rails来说尤其有用,因为活动记录模式完全是从关系模型中抽象出来的,所以我不必建模两次。 |
|
|
4
0
ER图很糟糕,因为它们包含的信息比对象图少,对象图包含的关于对象和继承树的方法的信息要多得多,这两个元素都是ER图将忽略的。 因此,最好从对象层次结构(类图)开始,然后移动到事物的映射端;) |