用例模型作為UML中4+1視圖中非常重要的一員，非常集中地體現了面向對象的分析與設計思想。用例模型將現實世界中連續的一個一個業務流程，按照場景劃分到了一個一個的用例中。由于場景的出現，使得用例中的業務流程存在著高度的內聚性，從而成為了日后各種對象的雛形。同時，在用例分析中，又將那些存在于各個用例中的，相同或相近的業務操作提取出來，形成一個一個的子用例或擴展用例，又體現了面向對象設計中的復用性。現在我們來談談用例分析中的子用例與擴展用例吧。

前面我們在用例說明中提到了基本流程。基本流程就是所有步驟都非常理想地正確執行，并最終完成所有操作的那個“最佳流程”。在基本流程中，可能有些步驟是多個用例都共有的，可以相互共享的流程。將這部分流程提取出來形成的就是子用例。子用例應當是在邏輯上相對獨立的一系統流程組成的用例。這個用例應當是抽象的，沒有自己的參與者，只有在調用它的用例中，才能真正明確它的使用者。




如圖是一個子用例使用的例子。圖中，用例“調整前信息查詢”、“調整后信息查詢”、“調整前時間段查詢”、“調整后時間段查詢”都用到了“按單位匯總考核結果”。它們是一種使用關系或者包含關系，因此被繪制成一條虛線，從使用者指向被使用者，并標注為use或include。

另外，在用例中還存在許多擴展流和異常流。當系統在運行到基本流程中某個步驟時，由于滿足了某個分支條件或異常條件，這時系統就從基本流程流轉到了擴展流或異常流中。擴展流和異常流其實不那么涇渭分明。在業務邏輯上擴展流依然是一種正常的操作，僅僅只是正常操作的另一個操作，而異常流其本身就是有什么東西不對勁了，需要進行一些異常處理，比如用戶密碼輸錯了、用戶忘帶身份證了，等等。擴展流和異常流最終都可能回到基本流程中，也可能不能回來，而從另一個結束點結束。

與子用例相似，擴展流和異常流中的流程如果相對獨立、可以為其它流程所共享，則可以提取出來，形成一個單獨的用例，叫擴展用例。如果擴展用例是直接從基本流程中某個環節擴展出來，則該環節被成為擴展點，進入擴展用例的條件叫擴展條件。在用例圖中，擴展關系被繪制成一根虛線，從擴展用例指向被擴展的用例，并標注為extend。

用例分析中對子用例與擴展用例的分析，使我們對系統的設計，從一開始就將公共的、可共享的部分提取出來，使我們在日后的設計與開發中得以很好地復用，提高了系統的內聚并降低了系統的耦合，是一個優秀軟件設計的開始。

我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會

（續）

我們應當怎樣做需求分析：子用例與擴展用例