那你显然误会大了. 我说的Class Diagram就是资料库模型,而不是程式设计方案. 如果你之前所提 "资料库通常是比class diagram先设计出来", 若在此class diagram是指程式,显然不是我所提的重点. 请你回头看一看我所提的Class Diagram,所指皆为资料库模型,而不是程式模型! 所以我会一直讲 "ER model 是 Class Diagram 的子集",你认为是在讲什麽? 讲的全是资料库啊! ※ 引述《come ()》之铭言： : 我是说先有资料库才有程式喔 : 你完全误会了 : ※ 引述《razor (=_=)》之铭言： : : ※ 引述《come ()》之铭言： : : : 另外资料库通常是比class diagram先设计出来的 : : : 在analysis阶段DB就应该设计好了 : : : 而且生命周期会比class diagram来的长 : : : 所以应该是class diagram要迁就ER的可能性来的高一些 : : 针对这一点,我摇头. : : 你意思就好像是说,程式都是比UML图型先做出来吗? : : 但回想UML是用来干嘛的? 塑模啊! : : 没错,资料库可能是先比模型图先弄出来,不过那又怎样? : : 这就好比未经过构思胡乱做出一个成品一样, : : 是啊,是有东西没错,但是没设计过! : : 更不用说什麽生命周期了. : : 语意丰富的Class Diagram迁就语意较少的E-R model? 可笑! : 这跟class diagram的语意一点都没关系 : 这是跟资料库的设计和整个软体开发流程的先後顺序有关 : 资料库是在analysis阶段就完成 : analysis阶段的class diagram只是一个雏形而已 : 到了design阶段的class diagram还必须根据data base schema重新设计一次 : 那你觉得这时候class diagram的设计是要迁就DB : 还是要回头改DB设计? : spiral model的开发模型是可以这样搞 : 不过改到DB通常表示需求分析有问题 那你觉得这时候class diagram的设计是要迁就DB还是要回头改DB设计? 拜托,不要只丢问题而不给答案,然後要从下文回头推敲你所支持的是哪一点, 这样很累耶,你支持哪一点明说就好了,不是吗? OK,言归正传, 为什麽会有回头改DB设计的问题? 我不会有这样的问题啊! 我从一开始就是用Class Diagram来分析这个资料库, 之後实作资料库的时候,若在程式规格上有疑义,觉得需要改个资料库程式会比较好写, 那我就去改资料库的实作版本,同时也修改我的Class Diagram. Class Diagram本身就包含了database schema的语意了, 这就是我说Class Diagram语意丰富的原因. 我建资料表,根本就是看着Class Diagram就建出资料表来了, 还顺道把各类别的方法用触发程序或预储程序写出来. 我根本不需要另一套对应的schema,因为Class Diagram就是我的schema. Class Diagram跟E-R model是同构的, 我可以看着Class Diagram,在脑中将它看成是E-R model的模样. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.160.211.33 ※ 编辑: razor 来自: 218.160.211.33 (07/20 00:36)