電子商務領域模型反饋

我一直在努力整理一個基本上允許用戶轉售音樂會門票的電子商務網站的粗略概念模型。這純粹是概念性的，而不是我實際製作的東西！電子商務領域模型反饋

無論如何，我已經把一個領域模型放在一起，我希望得到一些反饋。我之前創建了類模型並對數據庫進行了建模，但發現很難區分它們。

我見過很多富含貧血的詞彙，我相信我的模型是貧血的。簡單地指出更多的行爲會使它變得豐富嗎？

我的關係是否正確？我有沒有正確使用我的聚合和組合？

我很樂意提供任何有關改進的建議。

在此先感謝。

enter image description here

來源

2014-10-30 kidshenlong

下來的選民會介意解釋，所以我可以改善這個問題嗎？謝謝 – kidshenlong 2014-10-30 21:20:15

由於我們沒有architecturereview.stackexchange.com，我建議這可能屬於https://codereview.stackexchange.com/ – Kimvais 2014-10-31 07:49:27

你有正確的想法，但一些UML是不正確的，一個（業務）領域模型不應該有一個用戶。我

的問題的一些示例，請參閱：

一個用戶可能不是一個競買人及賣方;相反，用戶可以扮演投標人或賣方的角色。
概括不具有多重性。
對於擁有藝術家的門票我沒有任何意義。一張票通常允許一個人被允許進入一個表演，而一個藝術家在一個表演中表演。
作品最多可以有一個作曲班。

我會從概念模型中刪除組合和聚合。否則，我不認爲這是一個概念模型貧乏。接下來的步驟是將行爲添加爲OOA模型並從中生成一些代碼。請參閱Leon Starr的How to Build Articulate UML Models文章以獲取更多幫助。

來源

2014-10-30 22:35:08

謝謝您的反饋。你會如何建議實施投標人/賣方？完全刪除，支持另一個類，或只是保持用戶和角色？那麼你會如何顯示門票和藝術家之間的關係？ – kidshenlong 2014-10-30 22:59:51

請開始一個新的問題。 – 2016-04-24 05:31:09

正如吉姆所說，你不完全清楚組成和聚合如何工作。這個例子可能會有所幫助。 Tom Pender（「The UML Bible」的作者）在他的課堂上使用它。

假設你有一家汽車製造廠並且製造汽車。一輛汽車有一臺發動機。爲了成爲一輛車，它必須有一輛;如果你還沒有放進去，那還不是一輛車。而且，發動機是汽車的一部分。擁有發動機的唯一原因是將其放入汽車中。所以，引擎沒有獨立於汽車的身份或生命。這是組成。

現在，假設你有一個垃圾場。同一輛車，多年後。你可以賣掉汽車上的任何物品，它仍然是那輛車。如果您銷售發動機，則該車將是沒有發動機的汽車。這是聚合。因此，在製造環境中，汽車是零件的組成部分，而在垃圾場上下文中，汽車是零件的聚集體。重點在於，在組成部分，零件的使用壽命與汽車的壽命相關，並且在聚合中不是。

看着你的票務對象，我會說場館和藝術家與它有組合關聯。雖然場館和藝術家當然不依賴於他們存在的票據，但你必須記住上下文。你在做電子商務。您的藝術家和您的場地通過門票與電子商務系統交互，而不是以任何其他方式。所以組成。另一方面，門票絕對不是由訂單組成的。如果是這樣，就不會有無序票證這樣的事情！所以，門票和訂單有一個簡單的關聯，而不是聚合或合成。

至於你的投標人和賣家，他們是用戶。所以你有你的繼承箭頭倒退。如果投標人和賣方具有彼此獨立的專門用戶行爲（例如「OfferBid」和「AcceptBid」），則他們需要被建模爲用戶類的專業化。如果他們不這樣做，那麼他們只是兩個用戶，他們扮演不同的角色，並且可以像這樣建模。

來源

2014-10-31 18:48:58 BobRodes

電子商務領域模型反饋

回答

相關問題