用例建模

• • UML需求建模圖示
  • • • 需求分析階段的工作任務
      • 什么是業務用例建模
      • 什么是用例圖
      • 用例圖的作用
      • 用例圖對開發的意義
      • 大學信息系統的一個用例圖
      • 如何建立用例模型
      • 用例圖的組成
  • UML需求建模過程
  • • • 用例建模技術
      • 確定系統的范圍和邊界
      • 識別參與者
      • 識別用例
      • 識別用例間的關系
      • • ***（1）參與者與用例之間的關系***
        • ***（2）參與者之間關系***
        • ***（3）用例之間關系***
        • • 詳解：包含(include)關系
          • 詳解：擴展(extend)關系
          • 詳解：泛化(generalization)關系
      • 用例闡述
      • 審核用例模型

UML需求建模圖示

需求分析階段的工作任務

什么是業務用例建模

1.業務需求是從客戶角度提出的對系統的要求，一般也稱為初始需求。
2.業務用例建模在創建模型的初始階段，用來勾畫系統的大致輪廓。
3.隨著對需求的深入理解及與用戶不斷的溝通交流，進一步對用例進行細化，并根據實際需要，加入一些前期沒有被標識出來的用例。

什么是用例圖

1.用例圖(Use Case Diagram)是顯示一組用例、參與者以及它們之間關系的圖。把客戶的想法用更加容易理解的圖形化樣式展現給用戶，它描述的是參與者從系統外部來看系統該有的功能。
在軟件項目開發中，用例圖是業務調研后，最先用來和用戶交流討論的重要的UML圖。
也就是說，用例圖中描述的是系統該有哪些功能，而不是怎么實現。
在UML中，一個用例模型由若干個用例圖描述。

用例圖的作用

用例圖對開發的意義

用例圖是從需求分析報告到軟件系統設計的第一步，也是系統整個分析過程中最重要的圖，它的改變將影響到其它圖，用例建模貫穿整個軟件開發的過程。

大學信息系統的一個用例圖

如何建立用例模型

建立系統用例模型的過程就是對系統進行功能需求分析的過程。

用例圖的組成

1.參與者（actor），又叫執行者，是指系統外部與系統交互的人或其他系統。

2.用例（use case）是系統所提供的一個功能（或某一特定用法）的描述，是執行者和系統交互的一個完整過程。用例具有響應性、回執性、完整性，分為業務用例和系統用例。

UML需求建模過程

用例建模技術

確定系統的范圍和邊界

1.系統的范圍是指系統問題域的目標、任務、規模和系統提供的功能和服務。
2.系統的邊界就是系統內外的分界線，用一個實線方框表示。
3.系統開發的主要任務是對系統邊界內的元素進行分析、設計和實現，系統邊界外部的事物統稱為執行者。

識別參與者

1.參與者：又稱執行者。是在系統之外，透過系統邊界與系統進行有意義交互的任何事物。
2.參與者可以是人、另外一個系統、硬件設備、其它用例等系統外部的實體。有主要參與者、協助參與者、幕后參與者之分。
3.參與者是用來執行用例的。
4.識別參與者的方法：
~誰使用系統的主要功能
~誰改變系統的數據
~誰從系統獲取信息
~誰需要系統的支持以完成日常工作任務
~誰負責日常維護、管理并保證系統正常運行
~系統需要應付（處理）哪些硬件設備
~系統需要和哪些外部系統交互
~誰（或什么）對系統運行產生的結果（值）感興趣
時間、氣溫等內部外部條件
5.識別參與者

識別用例

1.什么是用例
（1）在UML中，用例被定義成系統執行的一個動作（功能單元）。只顯示系統外部的功能表現，不考慮系統內部的實現過程。
（2）用戶與計算機之間的典型交互。
（3）惟一的名字。
（4）表示方法
參與者和用例分別描述了**“誰來做？”和“做什么？”**這兩個問題。

2.識別用例
~參與者希望系統提供什么功能；
~系統是否存儲和檢索信息，如讀取、創建、刪除、修改、存儲等；如果是，這個行為由哪個參與者觸發；
~當系統改變狀態時，是否通知參與者；
~是否存在影響系統的外部事件，是哪個參與者通知系統這些外部事件。
~系統需要哪些輸入輸出？誰從系統獲取信息？
一般是抽取業務調研報告中的動詞或動詞詞組。

需要注意的是：用例必須是由某一個參與者觸發而產生的活動，如果存在跟參與者不進行交互的用例，則可以考慮并入其它用例，或者檢查是否缺少參與者。反之，每個參與者也必須至少涉及一個用例。

3.識別用例的方法
~在具體的需求分析過程中，先從用戶角度識別出系統的大致功能（大用例），就像一個黑盒一樣，不涉及其內部的任何信息。
~如果該用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部結構，找出黑盒內部的參與者和用例（小用例）。
~就這樣不斷的打開黑盒，分析黑盒，再打開新的黑盒，直到整個系統可以被清晰的了解為止。

識別用例間的關系

1.用例圖中的關系
用例圖中有以下幾種關系，應用這些關系的目的是為了從系統中抽取出公共行為和其變體。

（1）參與者與用例之間的關系

關聯關系：表示參與者與用例之間的通信。

（2）參與者之間關系

泛化關系：
參與者之間可以有共同的屬性和行為，因此可使用泛化關系來描述多個參與者之間的公共行為。它們之間有特殊和一般的關系。

（3）用例之間關系

a.包含關系（Include）
指一個用例可以包含其他用例具有的行為，并把它所包含的用例行為作為自身用例的一部分。其實就是基礎用例中一個不得不執行的用例部分。

詳解：包含(include)關系

包含關系中的基本用例(base use case) 的執行依賴于包含用例的執行，如果沒有包含用例，則基本用例的執行是不完整的。

包含用例是可重用的用例──多個用例的公共用例（公共行為）。

該用例本身具有獨立的業務邏輯，同時也可能被其它用例所引用，或者這個用例需要獨立封裝。

要使用包含關系，必須在子用例中說明基礎用例行為包含的詳細位置，類似于功能調用。


b. 擴展關系（Extend）
一個用例也可以被定義為基礎用例的增量擴展，這稱作擴展關系，擴展關系是把新行為插入到已有用例的方法。

詳解：擴展(extend)關系

擴展關系表示一個業務用例的執行有時需要對用例的功能進行擴展。將擴展用例的事件流在一定的條件下按照相應的擴展點插入到基礎用例中。

基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。基礎用例沒有擴展用例也是完整的。

擴展用例的行為是否被執行要取決于主事件流中的判定點。如果特定條件發生，擴展用例的行為才被執行。
4.值得注意的是擴展用例的事件流往往也可以抽象為基礎用例的備選流。

擴展用例是以隱含形式插入基用例的，它并不在基本用例中顯示。
在以下情況下，可使用擴展用例：
1.表明用例的某一部分是可選的系統行為（這樣就可以將模型中的可選行為和必選行為分開）。
2.表明只在特定條件下才執行的分支流。


c. 泛化關系（Generalization）
一個用例可以被特別列舉為一個或多個子用例，這被稱為用例泛化。

詳解：泛化(generalization)關系

~當多個用例共同擁有一種類似的結構和行為的時候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。
~泛化關系是對父用例具有一定的強依賴關系，子用例表示父用例的特殊形式，可以繼承父用例的行為和屬性，還可以添加自己的行為和屬性。

用例闡述

審核用例模型

總結

以上是生活随笔為你收集整理的用例建模的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。