use case,面向對象和功能分解的問題

http://www.umlchina.com/best/g36/u1155625.htm

作者 內容 
 agilemind   use case,面向對象和功能分解的問題，請各位大俠賜教!
　
--------------------------------------------------------------------------------
 
我現在面向對象的設計的做法是按一定的功能抽象出use case, 
比如說打印報表，綜合查詢，綜合統計，權限模塊等等use case, 
然后按use case抽象出相應的接口(抽象基類)， 
每個模塊都繼承自這些接口， 
功能擴展的話，都采用delegate(組合)，不采用繼承， 
但我覺得這樣似乎得出來的設計還是功能分解的。 
請各位賜教~~~ 
謝謝!
 
 04/05/11 18:13 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 smilemac  設計接口的方法不對。
　
--------------------------------------------------------------------------------
 
 04/05/11 18:50 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 agilemind  回復: 設計接口的方法不對。
　
--------------------------------------------------------------------------------
 
該怎么設計呢?謝謝!
 
 04/05/11 19:11 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus  use case 不是這么用的
　
--------------------------------------------------------------------------------
 
這樣的use case 更像以前的功能模塊（modules）, 也就是“功能分解”， use case 不應該用來做功能分解， 功能分解應該在作domain model， 也就是不同層次的class diagram 來做， 而且不是按照功能模塊來， 應該按照OO來。 

use case是需求分析， 用來cover用戶的需求， 然后驅動整個項目的開發進程。不管用什么方式approch, 它的核心是“Identify the actors/support actors" 以及這些用戶各自要用該系統做什么事情。 

個人覺得用分解功能模塊來代替use case 似乎有類似之處， 但是不能達到use case這個工具的目的：盡量cover全部的需求. 因為use case 的分析方法/思路 與 分解功能模塊 不太一樣。而且分解功能模塊已經參雜了技術分析，可能蒙蔽一些另外可用的解決方案， use case更加面對客戶的業務(business)。
 
 04/05/11 21:50 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 agilemind  回復: use case 不是這么用的
　
--------------------------------------------------------------------------------
 
關鍵是我的需求大概也就是這些功能模塊， 
因為這些功能模塊已經是長時間的項目后， 
用戶確定下來所需要的， 
我現在的問題是要把它們轉成OO的形式， 
如何設計接口呢？ 
多謝!
 
 04/05/11 21:57 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus  這樣的情況確實在很多公司存在，包括我們自己
　
--------------------------------------------------------------------------------
 
我個人的經驗是原來的功能模塊和現在的OO在基本的思路上， 或者思維方式上不一樣。就是要如何thinking in OO的問題。OO是根據名詞來劃分domain， 然后再找出每個名詞要做的動作（這些抽象的名詞+抽象的動作就是接口，它們有很強的通用性）, 功能模塊是根據動作來劃分， 然后再找出需要操作的名詞（這樣也可以有接口， 但是它們是通過動作導出的，如何保證接口的通用以及如何標定接口的適用范圍就有問題）。 

use cases雖然也是按照功能劃分， 但是并不用來“導出”設計， 它們是用來驅動項目的進程。 

不是用oo概念設計的系統，其architecture和OO系統不兼容，oo系統的architecture 有一個參考實現：http://www.ratio.co.uk/architectural_reference_model.pdf 您可以看看這篇文章。 

不是用oo概念設計的系統轉化成為OO系統有很多風險，你們應該仔細調研一下。個人認為首先確定轉成oo的目的和好處：常見的就是提高維護性，擴展性(scalability)。 

然后確定是否需要對現有的系統作改動以達到這些好處：如果你已有的系統沒有很強的擴展需求， 還是用舊設計，舊方法，舊流程比較穩妥。如果你的系統原來是為一個specific用戶設計的， 但是現在想把它做成一個有一定通用性的產品，個人建議是重新來過！看起來好像浪費了前面的成果，其實不然： 
1。 以前項目的最重要成果還在使用：客戶的業務需求。而且你可以跳出原來的系統設計，利用rup/uml更加全面，抽象地描述需求， 
2。 為了適應更加廣泛的需求，或者其他特別需求， 重新按照oo方法進行分析設計比起打補丁在短期內看似乎花費更多資源時間， 但是長期來說系統的維護性，擴展性要好很多，如果你考慮作產品， 一定要下這個決心， architecture上面的問題是補不過來的。我們公司有很多實際的例子，補丁打完后根本沒辦法維護，經常還要再補。但是這么做一定要解決skill & technology risk(參考UML_Distilled_2e.chm chapter 2, 在文件共享中有). 
 
 04/05/11 22:43 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 smilemac  回復: 設計接口的方法不對。
　
--------------------------------------------------------------------------------
 
一般的方法是先識別對象，再設計接口。而不是反過來。但是先設計接口可不可以呢？也是可以的，但不是如你這般理解的接口。在我的weblog上有一片文章與此有一點點關系，可以給你參考一下。smilemac.blogbus.com
 
 04/05/12 09:42 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 xiaoysh   回復: use case,面向對象和功能分解的問題，請各位大俠賜教!
　
--------------------------------------------------------------------------------
 
我個人認為，問題不在于沒有區分清楚use case和功能分解，而是因為你沒有一個architecture為依據，而只好從功能角度做設計了。 
　
 
 04/05/12 14:02 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 frankwoo   回復: 這樣的情況確實在很多公司存在，包括我們自己
　
--------------------------------------------------------------------------------
 
構架方面的refactory是要做的.畢竟是靈魂:)
 
 04/05/13 03:26 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus   說得對.作為了解refactoring重要性的開發人員和architect, 這個決定是顯而易見的
　
--------------------------------------------------------------------------------
 
但是作為公司的經理和sponsor(負責項目成本的)， 他們不知道這個道理， 總是認為把已有的東西丟掉太浪費。他們的architecture技術層面大都也停留在c/s 2 層結構和用功能分解進行項目設計上， 要說服他們真的很難。 

采用RUP進行軟件開發的不同iteration之間進行比較底層的refactoring有好處這個結論幾乎已經被大家接受。然而Architecture上的refactoring 對項目的好處和帶來的風險至今沒有統一的結論， 至少在北美沒有相關的統計數據來支持，老板一提到我們這個項目要從vb6 轉 .NET就是說要逐步進行， 先不要轉數據庫設計， 再不要一次轉原來用vb做的COM,只能部分轉。 我心里說：那么什么都不能動了。原來按照功能分解的模塊怎么能轉到.NET上還能賦予.NET提供的scalability等等優點？ 而且全是用aggregation實現的功能要不從頭設計， 根本沒有辦法做到interface development。
 
 04/05/13 04:23 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 xiaoysh   回復: 說得對.作為了解refactoring重要性的開發人員和architect, 這個決定是顯而易見的
　
--------------------------------------------------------------------------------
 
還有一種情況就是老板要你一股腦從頭到尾全部重新來搞，不過對不起，時間只有1個月，人員就這么多，到時候你就得拿出東西應用到若干具體項目。 
最近我們做的項目就是這樣，前面這周的人員分工，架構設計，業務設計，開發測試的迭代做得很不錯，感覺很多地方其實是契合了一些主要的過程原理的(由于具體原因，沒有專門進行過程設計上的工作)。 
可惜，昨天聽到消息就是1個月內要全部搞定，心里立刻很惱火，為了進度不求質量，預定了后期無休止的維護修改工作，累死累活的又是我們。
 
 04/05/13 13:14 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 orientphoebus  作為技術人員，在這種情況下只好向上反映，然后老板應該和architect坐下來找找解決的辦法
　
--------------------------------------------------------------------------------
 
或者挑出幾個關鍵的use case做1~2個iteration來滿足客戶目前緊迫的需要， 如果全新的做法不能在短時間滿足客戶需求, 就當機立斷按照原來的做法添加幾個緊急補丁(當然還是要建立相應的文檔以便后續工作進行)。理性的老板應該能在了解情況后迅速召開會議制定應變方案. 

個人認為,不管這么樣，這么短的時間如果走完整的SDLC不可能的話，只能走emergency process, 一個成熟的公司, 不管它的管理層技術水平如何, 一套應對不同業務需求的processes必須建立. 如果沒有, 作為QA,如果沒有QA, architect必須利用這樣的機會向管理層建議這么一個應急process,包括如何考慮風險, 如何選擇方案. 這樣以后遇到類似的情況就有據可依. 

商場如戰場,軟件開發最終也是為了商業利益. 商場變化無端, 技術上的戰略戰術也應該有相應變化,最好是事先準備--emergency process: 有正規軍正規作戰走RUP, 但是也要有快速反應流程甚至游擊戰. 但是不能像阿拉伯人那樣一輩子打游擊戰和自殺攻擊, 要發展內需,提高自我綜合能力, 為轉變正規戰做準備, 并主動創造條件, 一旦條件成熟,正規作戰才能取得最終勝利. 

如果一個公司的老板不能理性的接受這些提議的話, 這樣的老板根本沒有前途, 我會乘早走人. 寧可到一個公司老板技術能力不強,但是至少明白作事情有個過程這個道理, 像現在, 我雖然覺得郁悶, 但是不會被整天壓著加班做的還是垃圾然后煩躁生氣. 老板和客戶溝通的能力對下面的人影響很大, 會溝通的老板也懂得體恤下屬, 知道該急的事情急, 該緩的事情緩, 張弛有道下屬也會做好配合.