6. 退出系統，取回信用卡
在這個例子中，多個用例需要用到同一段行為，我們可以把這段共同的行為單獨抽象成為一個用例，然后讓其他的用例來包含這一用例。從而避免在多個用例中重復性地描述同一段行為，也可以防止該段行為在多個用例中的描述出現不一致性。當需要修改這段公共的需求時，我們也只需要修改一個用例，避免同時修改多個用例而產生的不一致性和重復性工作。
有時當某一個用例的事件流過于復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例。這種情況類似于在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調用這一子過程。
4.2.2 擴展(extend)
擴展（extend）關系如下圖所示，基礎用例(Base)中定義有一至多個已命名的擴展點，擴展關系是指將擴展用例(Extension)的事件流在一定的條件下按照相應的擴展點插入到基礎用例(Base)中。對于包含關系而言，子用例中的事件流是一定插入到基礎用例中去的，并且插入點只有一個。而擴展關系可以根據一定的條件來決定是否將擴展用例的事件流插入基礎用例事件流，并且插入點可以有多個。
例如對于電話業務，可以在基本通話(Call)業務上擴展出一些增值業務如：呼叫等待(Call Waiting)和呼叫轉移(Call Transfer)。我們可以用擴展關系將這些業務的用例模型描述如下。
在這個例子中，呼叫等待和呼叫轉移都是對基本通話用例的擴展，但是這兩個用例只有在一定的條件下（如應答方正忙或應答方無應答）才會將被擴展用例的事件流嵌入基本通話用例的擴展點，并重用基本通話用例中的事件流。
值得注意的是擴展用例的事件流往往可以也可抽象為基礎用例的備選流，如上例中的呼叫等待和呼叫轉移都可以作為基本通話用例的備選流而存在。但是基本通話用例已經是一個很復雜的用例了，選用擴展關系將增值業務抽象成為單獨的用例可以避免基礎用例過于復雜，并且把一些可選的操作獨立封裝在另外的用例中。
4.2.3 泛化(generalization)
當多個用例共同擁有一種類似的結構和行為的時候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。在用例的泛化關系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結構、行為和關系。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。
以下是一個用例泛化關系的例子，執行交易是一種交易抽象，執行房產交易和執行證券交易都是一種特殊的交易形式。
用例泛化關系中的事件流示例如下：
用例模型建成之后，我們可以對用例模型進行檢視，看是否可以進一步簡化用例模型、提高重用程度、增加模型的可維護性。主要可以從以下檢查點(checkpoints)入手: 用例之間是否相互獨立？如果兩個用例總是以同樣的順序被激活，可能需要將它們合并為一個用例。 多個用例之間是否有非常相似的行為或事件流？如果有，可以考慮將它們合并為一個用例。 用例事件流的一部分是否已被構建為另一個用例？如果是，可以讓該用例包含(include)另一用例。 是否應該將一個用例的事件流插入另一個用例的事件流中？如果是，利用與另一個用例的擴展關系(extend)來建立此模型。5. 管理用例模型復雜度
一般小型的系統，其用例模型中包含的參與者和用例不會太多，一個用例圖就可以容納所有的參與者，所有的參與者和用例也可以并存于同一個層次結構中。對于較復雜的大中型系統，用例模型中的參與者和用例會大大增加，我們需要一些方法來有效地管理由于規模上升而造成的復雜度。
5.1 用例包
包(Package)是UML中最常用的管理模型復雜度的機制，包也是UML中語義最簡單的一種模型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其他的包）。在用例模型中，我們可以用構造型(Sterotype)<>來擴展標準UML包的語義，這種新的包叫作用例包(Use Case Package)，用于分類管理用例模型中的模型元素。
我們可以根據參與者和用例的特性來對它們進行分類，分別置于不同的用例包管理之下。例如對于一個大型的企業管理信息系統，我們可以根據參與者和用例的內容將它們分別歸于人力資源、財務、采購、銷售、客務服務這些用例包之下。這樣我們將整個用例模型劃分成為兩個層次，在第一層次我們看到的是系統功能總共分為五部分，在第二層次我們可以分別看到每一用例包內部的參與者和用例。
個用例模型需要有多少個用例包取決你想怎么樣來管理用例模型的復雜度（包括參與者和用例的個數，以及它們之間的相互關系）。UML中的包其實就類似于文件系統中的目錄，文件數量少的時候不需要額外的目錄，文件數量一多就需要有多個目錄來分類管理，同樣一組文件不同的人會創建不同的目錄結構來進行管理，關鍵是要保證在目錄結構下每一個文件都要易于訪問。同樣的道理存在于用例建模之中，如何創建用例包以及用例包的個數取決于不同的系統和系統分析員，但要保證整個用例模型易于理解。
5.2 用例的粒度
我的系統需要有多少個用例？這是很多人在用例建模時會產生的疑惑。描述同一個系統，不同的人會產生不同的用例模型。例如對于各種系統中常見的"維護用戶"用例，它里面包含了添加用戶、修改用戶信息、刪除用戶等操作，這些操作在該用例的事件流可以表述成為基本流的子事件流(subflow)。
維護用戶-基本事件流
該基本流由三個子事件流構成：
(1) 添加用戶子事件流
…
(2) 修改用戶 子事件流
…
(3) 刪除用戶子事件流
…
但是你也可以根據該用例中的具體操作把它抽象成為三個用例，它所表示的系統需求和單個用例的模型是完全一樣的。
應該如何確定用例的粒度呢？在一次技術研討會上，有人問起Ivar Jacoboson博士，一個系統需要有多少個用例？大師的回答是20個，當然他的意思是最好將用例模型的規�？刂圃趲资畟�用例左右，這樣比較容易來管理用例模型的復雜度。在用例個數大致確定的條件下，我們就很容易來確定用例粒度的大小。對于較復雜的系統，我們需要控制用例模型一級的復雜度，所以可以將復雜度適當地移往每一個用例的內部，也就是讓一個用例包含較多的需求信息量。對于比較簡單的系統，我們則可以將復雜度適度地曝露在模型一級，也就是我們可以將較復雜的用例分解成為多個用例。
用例的粒度不但決定了用例模型級的復雜度，而且也決定了每一個用例內部的復雜度。我們應該根據每個系統的具體情況，因時因宜地來把握各個層次的復雜度，在盡可能保證整個用例模型的易理解性前提下決定用例的大小和數目。
5.3 用例圖
用例圖的主要作用是描述參與者和用例之間的關系，簡單的系統中只需要有一個用例圖就可以把所有的關系都描述清楚。復雜的系統中可以有多個用例圖，例如每個用例包都可以有一個獨立的用例圖來描述該用例包中所有的參與者和用例的關系。
在一個用例模型中，如果參與者和用例之間存在著多對多的關系，并且他們之間的關系比較復雜，如果在同一個用例圖中表述所有的參與者和用例就顯得不夠清晰，這時我們可創建多個用例圖來分別表示各種關系。
如果想要強調某一個參與者和多個用例的關系，你就可以以該參與者為中心，用一個用例圖表述出該參與者和多個用例之間的關系。在這個用例圖中，我們強調的是該參與者會使用系統所提供的哪些服務。
如果想要強調某一個用例和多個參與者之間的關系，你就可以以該用例為中心，用一個用例圖表述出該用例和多個參與者之間的關系。在這個用例圖中，我們強調的是該用例會涉及到哪些參與者，或者說該用例所表示的系統服務有哪些使用者。
總之在用例建模過程中，你可以根據自己的需要創建任意多個用例圖，用不同的用例來強調參與者和用例之間不同的關系。但是最重要的是要考慮整個用例模型的可理解性，如果可以用一個用例圖把意思表述清楚，就不要再用第二個，因為越是簡潔的模型越易于理解。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
