2011-04-23 96 views
0

我正在創建劇院簡單預訂系統的類圖。我想知道該圖是否有意義,如果需要更改(箭頭方向)以使其正確?關於UML類圖的反饋

謝謝。 enter image description here 圖片網址:http://i.stack.imgur.com/zWiGW.jpg

+1

就其本身而言,類圖幾乎沒有任何意義。爲了能夠給出評論,我們需要知道的不僅僅是圖表。當然,我們通常可以使用我們對席位和票據以及UML的瞭解,但最終我們需要知道您試圖展示的系統才能提供正確的反饋。 – 2011-04-23 16:15:33

回答

1

這裏有一些建議,你認爲合適,你可以自由地合併或忽略:

  • 我不展和地點之間的關係達成一致。預訂保持展會與場館之間的關係似乎更自然。
  • 我在任何地方都看不到日期。我錯過了嗎?這似乎很重要。
  • 表演沒有座位;一個場地有座位。
  • 門票應使您有權在某個特定日期的某個場館舉辦座位。我沒有看到。
  • TicketType應該只是一個枚舉。
  • 將用戶分解爲具有名稱,地址和憑證類別。從用戶分離出憑證。
  • 一個真正的支付系統將需要遠遠超過你已經顯示(如信用卡式等)

什麼,我認爲你的模型需要大量的工作。

+0

感謝您的反饋。 1.我如何顯示預訂維持關係,我是否將預訂連接到兩個班級之間的線路上? 2.增加日期3.更正場地有席位。 4.更正有票需要座位。 5和6.在完成我目前與模型有關的任何問題後,他們將繼續工作。 – 2011-04-23 16:24:17

+0

不,您會在預定的日期將預訂與單個展示相關聯。你會刪除你現在擁有的關係。 – duffymo 2011-04-23 18:05:45

+0

確定這樣嗎? http://i.imgur.com/QdSAV。jpg – 2011-04-23 18:11:55

0

除了duffymo所說的以外,這裏還有一些通用的觀察並不是與這個特定的圖相關,而是你的建模實踐。

  • 如果關聯是單向導航,則不需要命名兩端。你已經命名了所有關聯的兩端,但只有可導航的結尾需要一個名字。

  • 從所有關聯端刪除'可以'。在某些情況下,有一個方便的術語,例如,可以在場館舉辦託管。但在其他情況下,名稱關聯的結尾與此類的結尾完全相同也是非常好的,甚至是常見的做法。 (所以命名座椅端部只是座椅),如果你能

  • 避免多對多的關係。如果你不能再考慮添加一個關聯類,它幾乎總是有意義的。