UML用例模型及其應用解析
本節向大家描述一下UML用例模型，主要包括UML用例模型與需求分析，如何建立UML用例模型，用例圖等內容，希望本節的介紹對你的學習有所幫助。下面就是具體介紹。
對UML用例模型及其應用的一次有益的探討
前言：這是一次對用例模型的探討。怎樣建立用例模型，怎樣編寫用例說明，它與需求規格說明書有什么區別，它能替代需求規格說明書嗎？也許在這里可以找到你要的答案。
進入軟件業稍微久一點兒的人恐怕都不會陌生，軟件開發的最初階段都是談需求、寫需求規格說明書。需求規格說明書是與客戶最終確認到紙上的，非常正式的公文。軟件開發應當做什么，做成什么樣子，什么東西不做，項目范圍有多寬，需求規格說明書都是白紙黑字寫得清清楚楚，誰都無法抵賴。所以，需求規格說明書一直都是軟件項目開發合同的重要附件，地位相當重要。
但是，隨著RUP的引入，人們開始困惑了。在RUP中沒有需求規格說明書，而是為用例模型所替代。現在，一些信息化走在比較前列的公司，都紛紛要求按照RUP統一過程進行開發，我們也開始嘗試使用用例模型來替代需求規格說明書。然而，相信一些關于用例模型的幾個重要問題一直困惑著不少人（當然也包括我）：用例模型與需求規格說明書的區別在哪里？用例模型的優勢在哪里？用例模型能替代需求規格說明書嗎？圍繞著這幾個問題我們進行一次用例模型的探討之旅吧。
在開始我的探討之旅之前，我們***能帶上一個問題去探討：
UML用例模型與需求規格說明書的區別在哪里？
看到這個問題，你也許會非常不屑一顧，認為這個問題不值一提。確實，在編寫格式上，用例模型與需求規格說明書的差別顯而易見。但是，從更深層次來討論，你會發現，這個問題并不是那么簡單。有些人由于對用例模型的膚淺認識，將用例模型當成需求規格說明書來寫，格式雖說是用例模型的格式，內容卻不是用例模型的內容，換湯不換藥，反倒弄巧成拙，讓人困惑。需求規格說明書是面向過程時代的產物，因此它的核心就是按照面向過程的設計思想編寫需求；用例模型是面向對象分析/設計的產物，因此它的核心思想就是OOA/D（面向對象分析/設計）。我認為，把握這一點實在太重要了。明白了它，才能明白用例模型應當怎樣設計，才能明白它與需求規格說明書的區別，才能明白其作用和優勢在何處。下面，我們看看用例模型應當怎么設計。
如何建立UML用例模型
一些初學者認為，用例模型就是畫張用例圖。其實這是錯誤的，用例模型包括用例圖、用例說明，有時還要輔之一些簡單的行動圖、狀態圖和序列圖。用例圖采用圖形的方式，形象生動地展現了用例、參與者和系統邊界之間的關系。而用例說明，是對用例、參與者和系統邊界進行的詳細描述。在描述過程中，還可以對一些關鍵的流程，以及這些流程中關鍵類的狀態變化，使用行動圖、狀態圖和序列圖進行圖形化地展現。
UML用例圖
用例圖是建立UML用例模型的開始。用例模型的建立過程通常都是：先畫用例圖，然后對用例圖編寫用例說明。在編寫用例說明的時候，對一些復雜的、認為有必要的地方，繪制行動圖、狀態圖和序列圖，方便閱讀者理解。用例圖關注的是三部分內容：用例、參與者和系統邊界。
1.用例
用例就是一個用來描述參與者如何使用系統來實現其目標的一組場景的集合。這句話聽起來比較抽象，但我通常都把它暫時理解為功能中的模塊（雖然這并不嚴密，但更加實用）。用例強調的是一組場景，在這組場景不多但相互之間存在功能上的共性，就像一個大功能模塊下的多個子模塊。這組場景中的每一個，又分別形成一個個子用例。子用例再細分，又可以再形成各自的子用例。用例分析就是這樣由粗到細的逐步細分，從而形成一系統的用例圖。用例圖分析到多細，應當由業務需求的情況決定。分得過粗，就不足以說清楚業務的相關細節，或者使一張用例圖信息過多，影響人們的理解；分得過細，不僅會增加工作量，還會丟失許多用例間的相互關系，得不償失。總之，較為復雜的部分細一些，簡單的部分粗一些，保證每個用例圖都保持強烈的相關性，指導日后的功能劃分。
同時，用例強調的是參與者與系統功能的交互，用例就是系統的功能，而參與者可以暫時理解為使用系統的人。因此，大多數用例都對應著一個或數個參與者（但部分從用例中包含著的子用例，或擴展出來的擴展用例沒有參與者）。
用例與用例之間通常有兩種關系：包含與擴展。包含關系表示一種從屬關系，即子用例是主用例中相對獨立的、必須調用的一部分功能。在用例分析中，我們應當將多個用例都共有的、相對獨立的功能提取出來形成一個子用例，為日后代碼復用提供有力保障。擴展關系表示一個功能是對另一個功能的擴展，即被擴展功能不一定調用擴展功能，但擴展功能是對被擴展功能的加強與延伸。在繪制用例關系時，包含關系應繪制成從主用例指向子用例的虛線箭頭，并標注為“include”，表示主用例包含子用例；擴展關系應繪制成從擴展用例指向被擴展用例的虛線箭頭，并標注為“extend”，表示擴展用例是對被擴展用例的擴展。虛線箭頭在UML中代表的是一種依賴關系，即客戶元素了解供應者，并且供應者的變化會影響到客戶元素（依賴是從客戶元素指向供應者的）。
封裝性是面向對象設計的重要思想之一。而實現封裝的前提之一，就是要對需求進行整理的基礎上加以功能劃分，使具有強烈相關性的功能劃分在一起，只有少量接口與外界交互。用例分析，從一開始就對原始需求進行了功能劃分，將相關功能劃分到一起，將共有功能提取出來，標志出功能間的依賴與非依賴關系（包含表示的是一種依賴關系，而擴展表示的是一種非依賴關系）。這是一種OOA/D，它為日后的OO設計提供了強有力地支持。而這些都是需求規格說明書所不具有，或者不完全具體的功能。
2.參與者
現在再來說說UML用例模型中的參與者。參與者給大家最直觀的認識就是操作系統的那些人，但更準確的說應當是操作系統的那些角色。用例模型要求我們描述清楚系統中的每一個場景的每一步操作，操作者是誰。同時，我們關注的這個操作者并不是某個具體的人，而是一群有著相同職責的人，即角色。用例模型中對參與者的分析，為我們之后在開發過程中，進行功能、角色、用戶的劃分提供了依據。
用例模型中的參與者，除了表示操作系統的人，還表示處于系統邊界之外，與系統邊界內的用例有關聯的其它系統。因此，只有定義好一個系統的邊界，才能定義哪些是這個系統內的用例，哪些是這個系統內外的參與者。用例模型對本系統與其它系統相互關聯的分析，為我們日后開發過程中，為其它系統提供接口，或與其它系統進行接口，提供了依據。
參與者之間的關系只有一種——繼承關系，表示功能職責上的繼承。譬如，通常軟件系統中都有“普通操作者”，代表的是進入系統的所有用戶都應當具有的功能。而軟件系統又有很多“特殊職能者”，他們除了具有普通操作者的功能外，還有自己獨特的功能。在這里，“特殊職能者”是對“普通操作者”的繼承，繼承了“普通操作者”的所有功能。然而，“特殊職能者”又有“普通操作者”不具備的，自己獨特的功能。
參與者與用例之間是一種關聯關系，即實線表示。通常，參與者與用例之間的關系不用定義導航關系（即畫出箭頭），但部分UML的書籍也定義了這種導航關系。如果參與者要使用用例，則箭頭從參與者指向用例；如果參與者要接受用例提供的數據或查詢結果，則箭頭從用例指向參與者。
用例分析將參與者放到了一個十分顯著的位置，同時還關注的參與者的期望（即“涉眾利益”，在后面詳細描述），這也是需求規格說明書所不具有的。
3.系統邊界
UML用例模型中系統邊界是一個軟件系統需要處理的整個問題空間的范圍。一個軟件系統不可能處理所有問題，我們必須得給它定義這個問題空間的范圍。哪些是我們這個軟件可以處理的，哪些則是我們這個軟件不能處理的，也就是項目管理中所說的項目范圍。與需求規格說明書相比，用例分析通過圖形的方式，更加明確地定義出了項目范圍，以及與其它系統之間的關系，使其更加清楚明了。
【編輯推薦】
- UML用例建模的慨念和應用
- 解析UML面向對象分析與建模中交互圖
- UML基礎與應用--UML用例圖
- UML建模過程中需要注意要點專家提醒
- 體驗免費UML建模工具
