一個class diagram的問題

http://www.umlchina.com/best/g36/u1155672.htm
　
--------------------------------------------------------------------------------
 
現在有一個期刊管理系統，小弟在做class diagram是遇到了一些問題： 
對于每篇論文，都有幾個專家來審查，每個專家都給出分數，主編會在系統中給出一個分數的上，下限（可能每期都不同），如果總平均分高出上限，則論文通過，低于下限，則拒絕。 如果在上限和下限之間，則專家進行投票，只有在同意票數高于拒絕票數時，才能通過。 此外，系統還提供了一個利害關系檢測功能，如果專家是作者本人，則不能參加評分以及投票。 

我在class diagram中加入了一個 conflict list 的 class，將其作為 paper 和 expert 之間的 associated class，大家覺得如何？ 還有就是 投票 和 設定上下限 如何在class diagram 中體現呢？ 

謝謝 
　
 
 04/05/14 22:49 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus  你的思路還是功能分解， 想把功能分解成一個個class, 要加一些thinking in OO的思路
　
--------------------------------------------------------------------------------
 
以下例子都是以Java做的 
1.Conflict判斷是一個business rule, 假如你要單獨實現這一條business rule，個人認為沒必要加conflict list class 
設計時: person作為base class, 實現equals(), expert 和 author 繼承之 
如果這個conflict判斷只有“專家是作者本人”一個條件 
expert.evaluate(paper)作為一個method，其中加入比較: 
if (this.equals(paper.author.name)){ 
throw ExpertOperationException("Authoer is not allowed to evaluate."); 
} 

如果你要設定比較復雜的conflict 關系， 也有簡單(通用性不強)做法和復雜（通用和擴展性很好）做法： 
a)簡單: 因為這個關系只是存在于expert和paper之間，而且只在做評分時需要判斷。只要在這兩個對象中任何一個實現一個method--expert.isConflict(paper) / paper.isConflict(expert)，然后在 evaluate 中調用就可以了。 

b)復雜：從architecture層次上說，一個系統最好在底層獨立建立一個business rules處理機制，這種機制應該符合一定的標準。如果你的系統采用XML, 我建議參考XACML -- Extensible Access Control Markup Language ( http://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html ) 
這是OASIS標準組織開發的一個很實用的標準。用這個標準建立起系統的authorization機制. 這個機制可以把各種business rules集中管理. 
有了這個機制后, 在OO設計上,實現一個interface: Security.BusinessRule.isAllowed(java.lang.reflect.Method, Object[]) 
每個具體的class 實現上述interface, 在實現中調用上述XACML建立的機制(或者可以設計一個base class 來implemete上述機制)來進行各種business rules的比較. 
每個具體的class的具體method,做任何實際工作前,調用本class對上述interface的實現, 參數: method是自己這個方法本身, objects[]基本上是自己這個方法的參數. 

2. "投票"也是動作. 投票要考慮是記名還是不記名? 如果不記名,那么在paper中加上幾個properties: 可投票人數, 參加人數, 同意數, 否定數,無效票數. 然后每個expert有一個方法: expert.vote(paper).注意這個操作中要有business rule 的判斷.其中調用paper.vote(boolean agree), 注意這個必須是thread safe. 如果記名, 每個paper就必須有個related class, 用composite 1:0..*關系,其中記錄投票結果和誰投的. 

3. "設定上下限"也是動作,它是主編這個class的一個method, 它的操作對象(method的參數)是期刊(每個期刊和paper的關系是0..1:1..*的aggregation關系) 

所有這些動作造成各個class之間有一定的聯系(比如 expert-paper, 主編--期刊) 這些聯系不需要再class diagram中表示, 而是在use case中和sequence diagram 等動態圖中表示的. class diagram 表示的是系統設計的一種靜態view. 除非你要表示一個expert只能負責某一種類型的paper的審核, 那么在class diagram中添加一個paperType class, 然后expert 用 aggregation來聯系paperType
 
 04/05/15 00:04 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 y051313  回復: 你的思路還是功能分解， 想把功能分解成一個個class, 要加一些thinking in OO的思路
　
--------------------------------------------------------------------------------
 
謝謝，但是關于vote，并不是每個paper都需要投票的啊，放到paper里合適嗎？
 
 04/05/15 05:16 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus  投票的結果和paper是1:0..1對應, 你當然也可以用expert和投票結果1:n對應,但是不夠準確表示對象關系,而且操作復雜
　
--------------------------------------------------------------------------------
 
如果是無記名投票, 用它們做paper的屬性還是比較合適, 運算也簡單. 
"可參加投票的人數" 這個屬性可以用來設定某些paper不需要投票. 或者添加一個paper狀態屬性.
 
 04/05/17 11:38 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 spide   好實例！