UMLchina_潘加宇：我沒有理解你的問題。但用例確實可以是自外而內的推進。
網友：請問你設計了那么多案例，有沒有一些基本的自我設計的一些原則總結呢，即使很籠統地我們也想聽聽。
UMLchina_潘加宇: 原則不敢說，體會最深就一句話：形式正確容易，內容正確難。UML在第一關幫助很大，但第二關要靠我們自己。
網友：在分析系統的用例時，怎樣才算找到準確的用例，即找用例的標準是什么？
UMLchina_潘加宇: 準確有兩個層次。第一層、粒度，內容符合用例的定義。這一層是形式正確，容易做到－－標準是理解用例的含義。第2層，識別的用例符合了客戶的需要。這是內容正確，較難，標準是理解涉眾的需要。
網友：一個信息管理系統中，對某一個實體信息的管理維護，是分出增加、刪除、修改還是只看作一個維護用例？
UMLchina_潘加宇：請看http://www.umlchina.net/training/umlchina_2.pdf
網友: 對某一個實體信息的管理維護，是分出增加、刪除、修改還是只看作一個維護用例？
UMLchina_潘加宇：關鍵是要找出CRUD背后可能隱藏的業務。
網友：我覺得對一個實體的操作還是當作一個用例吧。
UMLchina_潘加宇：不是，用例是系統提供價值的體現，嚴格上與面向對象無關。
網友: 在類圖理解上，最容易出錯的地方大概是什么呢？
UMLchina_潘加宇：對初學者來說，估計是泛化和關聯的混淆。
網友: 泛化和關聯，怎用才能不混淆，有什么竅門么？
UMLchina_潘加宇：沒竅門。除了理解OO，理解業務。泛化是集合的關系，關聯是個體的關系。泛化是類級別的復用，關聯是個體的組裝。
網友: 用UML設計程序，用戶界面應在什么階段設計？
UMLchina_潘加宇：在設計階段，由分析階段的界面類責任導出。
網友：在實際中，很多可能自定義的類是從系統的一些類泛化出來的。
UMLchina_潘加宇：通過泛化來復用另一領域的類（如系統類）并不是個好主意。
網友: 分析階段的類圖應該到什么程度？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
