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