軟件測試開發技術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.kjueaiud.com/