統一建模語言UML輕松入門之用例

2019-11-17 04:50:55

字體：大中小

來源：轉載

供稿：網友

　　目前，在的內地版《神雕俠侶》中，楊過和小龍女有一份不為人知的默契與浪漫，那就是他們所繪制的并肩小人圖。這樣的小人圖，是UML用例圖的一部分，被稱為參與者。

　　2.1 用例與用例圖

　　用例是需求分析中最重要的概念，需求表征了一個系統的設計特性、特征和行為，描述一個系統的需求意味著描述了建立在該系統外部的事物與系統之間的契約，契約上聲明了期望系統做什么。

　　需求獲取(Requirement Elicitation) 是需求工程的主體，其主要工作是建立待開發系統的模型，而用例就是用于建立這種模型的良好方法。用例最初由Ivar Jackboson博士提出，后被綜合到UML規范之中，成為需求表述的標準化體系。前文已經提到，整個RUP流程都是"用例驅動"的，各種類型的開發活動包括項目治理、分析、設計、測試、實現等以用例為主要輸入工件，用例模型奠定了整個系統軟件開發的基礎，用例被認作第二代面向對象技術的標志，可見其重要性非同一般。

　　我們先來給出一個具體而簡單的用例圖，即"圖書治理系統"用例圖，如圖2.1。在用例圖中主要涉及到參與者（又稱角色、執行者）、用例以及二者之間的通訊關聯。

圖2.1 圖書治理系統用例圖

　　參與者

　　參與者是與系統、子系統或類發生交互的外部用戶、進程或其他系統。參與者可以是人、另一個計算機系統或一些可運行的進程。在圖2.1中，"讀者"和"治理員"即為參與者。

　　參與者之間可以存在泛化關系，例如，在圖2.1所示圖書館治理系統用例圖中，可以認為"讀者"是"學生讀者"和"教師讀者"的泛化，而"學生讀者"還可以具體化為"本科生讀者"和"研究生讀者"；同樣，"圖書治理人員"也是"采購員"、"編目員"及"借閱人員"的泛化。圖2.2表示出了參與者之間的泛化關系。

圖2.2 參與者泛化關系

　　用例

　　用例是外部可見的一個系統功能，這些功能由系統所提供，并通過與參與者之間消息的交換來表達。用例的用途是在不揭示系統內部構造的情況下定義行為序列，它把系統當作一個黑箱，表達整個系統對外部用戶可見的行為。

　　鑒于用例的特點，用例一般被命名為一個能夠說明目標的動名詞組。如圖2.1中的"借書"、"還書"和"治理圖書"皆為動名詞組。

　　用例之間也可以存在包含、擴展和泛化等關系：

　?。?）包含關系：用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為做為自身行為的一部分，這被稱作包含關系。

　?。?）擴展關系：擴展關系是從擴展用例到基本用例的關系，它說明為擴展用例定義的行為如何插入到為基本用例定義的行為中。它是以隱含形式插入的，也就是說，擴展用例并不在基本用例中顯示。在以下幾種情況下，可使用擴展用例：

　　a.表明用例的某一部分是可選的系統行為（這樣，您就可以將模型中的可選行為和必選行為分開）；

　　b.表明只在特定條件（如例外條件）下才執行的分支流；

　　c.表明可能有一組行為段，其中的一個或多個段可以在基本用例中的擴展點處插入。所插入的行為段和插入的順序取決于在執行基本用例時與主角進行的交互。

　　圖2.3給出了一個擴展關系的例子，在還書的過程中，只有在例外條件（讀者遺失書籍）的情況下，才會執行賠償遺失書籍的分支流。

圖2.3用例擴展關系

　?。?）泛化關系：用例可以被非凡列舉為一個或多個子用例，這被稱做用例泛化。當父用例能夠被使用時，任何子用例也可以被使用。如在圖2.4中，訂票是電話訂票和網上訂票的抽象。

圖2.4用例泛化關系

QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器通訊關聯

　　通訊關聯用于表示參與者和用例之間的對應關系，它表示參與者使用了系統中的哪些用例（或者說系統所提供的用例被哪些參與者使用）。

　　通訊關聯以箭頭或實線表示。若使用箭頭，箭頭所指方將是對話的被動接受者；假如不強調對話中的主動與被動關系，則可以使用不帶箭頭的關聯實線。

　　2.2建立用例模型

　　知道了用例與用例圖的概念，我們還需要懂得怎樣建立用例模型，即怎樣找出參與者、用例以及定義用例的過程。一般來說，建立用例模型的步驟為：

　?。?）確定誰會直接使用該系統，即參與者（Actor），為了發現參與者，我們可以嘗試問如下問題：

　　a. 誰/什么使用系統？

　　b. 誰/什么從系統獲得信息？

　　c. 誰/什么向系統提供信息？

　　d. 誰/什么支持、維護系統？

　　e. 哪些其它系統使用此系統？

　　f. 公司的哪個部門使用系統？

　　…

　?。?）選取其中一個參與者；

　?。?）定義該參與者希望系統做什么，參與者希望系統做的每件事成為一個用例，為了發現用例，我們可以嘗試問如下問題：

　　a. 為什么該參與者想要使用此系統？

　　b. 該參與者是否要創建、保存、更改、移動或讀取系統的數據？假如是，為什么？

　　c. 該參與者是否要通知系統外部事件或變化？

　　d. 該參與者是否需要知道系統內部的特定事件？

　　…

　?。?）對每件事來說，何時參與者會使用系統，通常會發生什么，這就是用例的基本過程；

　　（5）描述該用例的基本過程；

　?。?）考慮一些可變情況，把他們創建為擴展用例；

　　（7）復審不同用例的描述，找出其中的相同點，抽出相同點作為共同的用例；

　?。?）重復步驟2-7找出每一個用例。

　　參與者檢查的參考標準如下：

　?。?）是否您已找到所有的參與者？也就是說，是否您已經對系統環境中的所有參與者都進行了說明和建模？

　?。?）每個參與者是否至少涉及到一個用例？

　?。?）您能否列出至少兩名可以作為特定參與者的人員？

　?。?）是否有參與者擔任與系統相關的相似參與者？假如有，您應該將他們合并到一個參與者中。

　　用例檢查的參考標準如下：

　　（1）用例模型的簡介部分簡明清楚地概述此系統的目的和功能；

　?。?）所有的用例已確定，這些用例共同說明所有的必要行為；

　?。?）所有的功能性需求都至少映射到一個用例；

　　（4）該用例模型不包含多余的行為，所有的用例都可回溯到某個功能性需求來證實其合理性。

　　用例圖從總體上大致描述了系統所能提供的各種服務，讓我們對于系統的功能有一個總體的熟悉，僅此還是不夠的，我們還需要描述每一個用例的具體信息，即用例規約。用例模型正是由用例圖和每一個用例的具體描述――用例規約所組成的。RUP中提供了用例規約的模板，包含以下內容：

　　（1）簡要說明 (Brief Description)：簡要介紹該用例的作用和目的；

　?。?）事件流 (Flow of Event)：包括基本流和備選流，事件流應該表示出所有的場景；

　　（3）用例場景 (Use-Case Scenario) ：包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的；

　　（4）非凡需求 (Special Requirement)：描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統、開發工具等）；

　?。?）前置條件 (PRe-Condition)：執行用例之前系統必須所處的狀態；

　?。?）后置條件 (Post-Condition)：用例執行完畢后系統可能處于的一組狀態。

　　用例規約基本上是用文本方式來表述的，為了更加清楚地描述事件流，也可以選擇使用狀態圖、活動圖或序列圖來輔助說明（狀態圖有助于描述與狀態相關的系統行為，活動圖有助于描述復雜的決策流程，序列圖適合于描述基于時間順序的消息傳遞）。另外，只要對簡潔明了地表達用例有幫助，我們就可以在用例中任意粘貼用戶界面、流程的圖形化顯示方式及其他圖形。

上一篇：統一建模語言UML輕松入門之類和對象

下一篇：如何編寫高質量“軟件需求說明書”