UMLchina網站潘加宇與網友的聊天實錄

網友：領域模型、概念模型、業務模型三者之間有什么關系？

UMLchina_潘加宇: 三者是基本一樣的。說的都是現實中的模型，要說有區別，應該是：前兩者說的是類圖，后一個不只是類圖。

網友: 可以不確切的將分析類中entity class看作是業務模型的主要成分，對否？

UMLchina_潘加宇: 分析類中entity class是系統的一部分，是分析階段的工件。業務模型（如果有）里應該是業務對象圖。

網友：用例是為了更好地進行需求分析？

UMLchina_潘加宇:用例是幫助開發者獲得有價值需求的技術。

網友：對于入門者請潘先生能不能先介紹一番。

UMLchina_潘加宇：入門者請看http://www.umlchina.net/training/umlchina_1.pdf，http://www.umlchina.net/training/umlchina_2.pdf。

網友：是不是很多小型的項目，用類圖，就很足夠了？

UMLchina_潘加宇：類圖是武器，用例是目標。目標錯了，拿著AK47又有什么用？后果是，一旦出了問題，受懷疑的不是目標，而是AK47

網友：use case 和 時序圖、類圖有何關系？

UMLchina_潘加宇：通過順序圖把用例文檔的系統責任分配到類上。

網友：請問是不是需要我們客戶也需要學習UML？

UMLchina_潘加宇: NO！

網友：感覺在實際使用中，特別是小項目中用起來比較費勁。

UMLchina_潘加宇: 那是因為誤用的人太多，只領會了形式。

UMLchina_潘加宇: mdl里有的只是uml提供的符號，在分析階段開始才比較管用。

網友: 如何掌握use case的粒度問題？

UMLchina_潘加宇: 用例要有路徑、路徑要有步驟，而這一切都是“可觀測”的。例如：“到數據庫取某字段”對客戶是不可理解和驗證的，當然，是客戶提出的又是另外一回事。

網友：我覺得用例的粒度問題，應該是，用例分析過程中應該是逐步求精的過程。即先有個大框架，然后再進一步細化，直至一切都可觀測。不知道潘老師怎么認為？

UMLchina_潘加宇：我沒有理解你的問題。但用例確實可以是自外而內的推進。

網友：請問你設計了那么多案例，有沒有一些基本的自我設計的一些原則總結呢，即使很籠統地我們也想聽聽。

UMLchina_潘加宇: 原則不敢說，體會最深就一句話：形式正確容易，內容正確難。UML在第一關幫助很大，但第二關要靠我們自己。

網友：在分析系統的用例時，怎樣才算找到準確的用例，即找用例的標準是什么？

UMLchina_潘加宇: 準確有兩個層次。第一層、粒度，內容符合用例的定義。這一層是形式正確，容易做到－－標準是理解用例的含義。第2層，識別的用例符合了客戶的需要。這是內容正確，較難，標準是理解涉眾的需要。

網友：一個信息管理系統中，對某一個實體信息的管理維護，是分出增加、刪除、修改還是只看作一個維護用例？

UMLchina_潘加宇：請看��http://www.umlchina.net/training/umlchina_2.pdf��

網友: 對某一個實體信息的管理維護，是分出增加、刪除、修改還是只看作一個維護用例？

UMLchina_潘加宇：關鍵是要找出CRUD背后可能隱藏的業務。

網友：我覺得對一個實體的操作還是當作一個用例吧。

UMLchina_潘加宇：不是，用例是系統提供價值的體現，嚴格上與面向對象無關。

網友: 在類圖理解上，最容易出錯的地方大概是什么呢？

UMLchina_潘加宇：對初學者來說，估計是泛化和關聯的混淆。

網友: 泛化和關聯，怎用才能不混淆，有什么竅門么？

UMLchina_潘加宇：沒竅門。除了理解OO，理解業務。泛化是集合的關系，關聯是個體的關系。泛化是類級別的復用，關聯是個體的組裝。

網友: 用UML設計程序，用戶界面應在什么階段設計？

UMLchina_潘加宇：在設計階段，由分析階段的界面類責任導出。

網友：在實際中，很多可能自定義的類是從系統的一些類泛化出來的。

UMLchina_潘加宇：通過泛化來復用另一領域的類（如系統類）并不是個好主意。

網友: 分析階段的類圖應該到什么程度？

UMLchina_潘加宇：該有的都有，只是與平臺無關。

網友: 把類的泛化和關聯等都要做出來么？

UMLchina_潘加宇：那自然，否則你分析什么。

網友: RUP現在是否只停留在理論階段？

UMLchina_潘加宇：UP的思想和實踐已經無處不在，可能有很多種表現形式，真正成功的軟件開發，沒有UP的思想無法想像其結果。

網友: 系統類已經提供很好了，只有一點點沒有。

UMLchina_潘加宇：這一點點就是業務吧，這才是你真正要花時間去搞明白的東西�，F在的開發，代碼的95%都是微軟等幫你寫的，你應該把精力集中到你的5%上。

網友: 那我需要用到的功能，系統類已經提供很好了。

UMLchina_潘加宇：所有的開發，只要不是從頭做起，都是“系統類已經提供很好了”的，但這只能說明，我們要超越“能運行”的階段，向做出有用的軟件邁進。

網友: 是否可以迅速掌握UML建模？

UMLchina_潘加宇：沒有捷徑，實踐＋學習＋思考。

網友: 迅速掌握UML建模呢？

UMLchina_潘加宇：即使是參加uMLChina訓練，我們也只會說，團隊把用例、類、順序圖三步都用好，時間要一年。

網友: 能不能在賽迪網看到 潘先生的文章？

UMLchina_潘加宇：我的文章本來就很少，希望下面階段能抽時間把積累的東西整理整理，幫助大家真正把UML用起來。

網友: 如何判斷泛化？

UMLchina_潘加宇：判斷泛化的一個好方法是，超類的對象集合包含所有子類的對象集合。

網友:是先有類，還是先有順序圖��？

UMLchina_潘加宇：對于不是專家者，我建議先有類，后有順序圖。對于這方面的細節，現在的各方書、資料等說得不夠詳細。我們的第一本指定教材《有效用例模式》很快就會出版。

網友: 分析階段出的模型和設計階段初的模型有什么區別？

UMLchina_潘加宇：一個平臺無關，一個平臺相關。

網友: 需求獲取與分析的比例？

UMLchina_潘加宇：不同階段是不同的，在初始階段和精化階段，需求科目比例很大。在后面的階段，需求比例越來越小，分析設計科目比例增大。

網友: 具體什么時候可以看到《有效用例模式》？

UMLchina_潘加宇：應該是8月底。例子都是實際項目，而且一個mdl看出來的東西很少，我會盡量寫一些文章在《非程序員》，里面爭取80以上都是實踐例子。

網友: 是否有好書推薦？

UMLchina_潘加宇：用例只推薦兩本：編寫有效用例和有效用例模式，其他書很多地方有強烈誤導。

網友:《有效用例模式》有電子版嗎？

UMLchina_潘加宇：英文的有，中文的只有樣章，http://wwwumlchina.com/book/book2.htm

網友: 是否大部分工作是在分析階段做完的，設計階段只是根據分析的結果并把他們移植到要采用的平臺上？

UMLchina_潘加宇：與業務相關的工作是的。但也依賴于項目的性質，有的項目設計也是非�；üぷ髁康�，有的項目則不然。

網友: 類怎么得出來？

UMLchina_潘加宇：需要認真研究需求（用例文檔），從用例文檔中抽取。

網友: RUP是什么東東？

UMLchina_潘加宇：不知道RUP不要緊的。

網友: 設計階段不就只是說把相關的分析內容再應用的要采用的開發語言么？

UMLchina_潘加宇：對，這有的時候很容易（象普通的商務系統），有的時候比較麻煩的（運行平臺很特殊，硬件也特殊）

網友: RUP分析出類的時候,有沒有一些指導性的原則?

UMLchina_潘加宇：用例文檔要做好、理解，要理解OO概念。

網友: 有沒有一些指導性的原則?

UMLchina_潘加宇：有一些輔助的工作細節，這里就很難演示了。

網友: 到底要畫哪些圖？序列圖是必須的嗎？

UMLchina_潘加宇：如果不是面向對象開發，只有用例文檔是必須的，然后直接編代碼都可以。如果是面向對象開發，需要用類圖描述結構，順序圖分配責任。