那你顯然誤會大了. 我說的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)