軟件測試開發技術UMLchina網站潘加宇與網友的聊天實錄

軟件測試開發技術UMLchina網站潘加宇與網友的聊天實錄 UML模型

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

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

原文轉自：http://www.anti-gravitydesign.com