包含用例是一種什麼技術

1. UseCase是個什麼概念

在軟體工程中，用例是一種在開發新系統或者軟體改造時捕獲潛在需求的技術。每個用例提供了一個或多個場景，該場景揭示了系統是如何同最終用戶或其它系統交互的，從而獲得一個明確的業務目標。用例要避免技術術語，取而代之的是最終用戶或者領域專家的語言。用例一般是由軟體開發者和最終用戶共同創作的。

在1986年，Ivar Jacobson，UML和統一過程的重要貢獻者，提出了用例的概念。Jacobson的思想很有影響力，也很有發展力。之後在這個科目上又有很多貢獻，在定義用例是什麼和怎麼有效的書寫用例方面最重要，最有影響力也最全面的，是Alistair Cockburn，他寫的書籍是《編寫有效用例》。

用例迅速成為獲取功能需求的最常用的手段。用例最初是和面向對象一同提出的。但是它不止局限於面向對象系統，因為用例實質上不是面向對象。

用例范圍和目標
每個用例集中描述如何獲得一個業務目標或任務。從傳統的軟體工程視角來看，用例只是描述了系統的一個特徵。所以對大部分軟體項目來說，這就意味著需要很多（有可能是數十個）用例來完整的描述新系統。一個特殊軟體項目的正規度和項目的不同階段將會影響每一用例需要的詳細程度。

一個用例定義了外部執行者和被考慮的系統之間的交互來實現一個業務目標。執行者是在系統外部和系統交互的人；一個執行者可以是一類用戶，用戶可以扮演的角色或者其它系統。

用例把系統看作"黑盒"，同系統的交互，包括系統的響應都是可以在系統外部感知的。它是一個deliberate policy，因為它簡化了需求的描述，避免了對功能如何實現做出假設的陷阱。

用例應該:

描述了滿足業務目標的業務活動
沒有涉及特定的實現語言
要求合適的細節級別
足夠短，使得在一次發布中能夠被一個軟體開發人員實現
[編輯]
用例圖
Image:UMLUSE.PNG許多人通過UML認識了用例，UML定義為展現用例的圖形符號。 UML並沒有為描述用例定義書寫格式的標准，因此許多人誤認為這些圖形符號就是用例本身；然而，圖形符號只能給出最簡單的一個或一組用例的概要。

UML是用例圖形符號最流行的標准。但是，還有一些其它的可選擇的標准。

[編輯]
書寫用例
[編輯]
細度
Alistair Cockburn 在編寫有效用例一書中確定了三種書寫用例的細度。

[編輯]
摘要
摘要用例有很少的句子組成來總結的用例。它十分適合在電子表格中計劃軟體開發。一個摘要用例能夠簡單插入電子表格的單元格中並且用表格中的其它列記述業務優先順序，技術復雜度，版本號等。

[編輯]
非正式
一個非正式的用例由文本段落組成，包括了上面提到的那些列，用總結或故事的形式詳細的描述了用例。

[編輯]
完整正式
一個完整正式或者復雜的用例是一個以包含了不同部分的長模版為基礎的正規的文檔。該用例在下面的用例模版部分進行討論。

[編輯]
適當使用
一些軟體開發方法學只需要非正式的用例來定義需求。然而，開發方法學需要完整正式或詳細的用例來定義需求。較大且較復雜的項目更需要使用完整正式的用例。

[編輯]
用例模版
沒有一個意見一致的模版來編寫詳細的或fully dressed 用例。 There is no agreed template for documenting detailed or fully dressed use cases. There are a number of competing schemes and indivials are encouraged to use templates that work for them or the project they are on. Standardisation for each project is more important than the detail of a specific template. However, there is considerable agreement about the core sections; and so beneath different terminology and order there is an underlying similiarity between most use cases. (現在存在很多相互競爭的模板。同時，程序員們也被鼓勵用那些適合於他們的工作或者他們所做項目的模板，相對於某個指定模板的細節來說，項目的標准化要重要的多，但是這些模板的關鍵部分都是大體相同的，所以，雖然在某些術語上或者其他一些方面上存在不同，但是這些用例從本質上來說，是大同小異的。)

典型部分包括:

用例名
迭代
綜述
前置條件
觸發器
基本事件流
備選路徑
後置條件
業務規則
說明
作者和日期
不同的模版經常有其它部分，如，假設，異常，建議，技術要求。也會有行業細節部分。

[編輯]
用例名
用例名為用例提供了一個唯一標示。它要用動/賓格式書寫，並且要充分，達到最終用戶能夠明白用例中描述的是什麼。

[編輯]
迭代
迭代部分通常需要告知讀者用例完成的階段。最初，為業務分析和確定范圍的用例和用於軟體開發的用例肯定會有許多不同。老版本的用例可能還在當前文檔中，因為它們對不同的用戶群可能會有價值。

[編輯]
綜述
綜述 部分用於在主體完成之前捕獲基本場景。它提供了快速的總結，避免了讀者瀏覽全部內容，能夠很快的理解該用例的用途。

[編輯]
前置條件
前置條件 部分用來表達當用戶開始用例時某些條件必須為真。但是它們不是啟動用例的觸發器。

[編輯]
觸發器
觸發器 部分描述了啟動用例的起始條件。

[編輯]
基本事件流
最低限度，每一個用例都需要描述一個主場景或者典型事件流。主事件流一般是一組有編號的步驟，如：

1) 系統提示用戶登錄。
2) 用戶輸入他的名字和密碼。
3) 系統驗證用戶信息。
4) 系統使該用戶登錄入系統
...其他

[編輯]
備選路徑
用例可能包含第二條路徑，或者和主題不同的備選場景。異常或當出錯時會發生什麼事情也需要描述出來，這種描述可以在備選路徑中或者在它本身的部分。備選路徑使用基本事件流中的序號來標示在哪一點上同基本場景不同，並且如果合適它從哪一點回到基本場景中。目的是避免不必要的重復信息。

備選路徑的例子:

1) 系統識別用戶機器上的cookie
2) 到步驟4（主路徑）
異常路徑的例子:

3) 系統不能識別用戶登錄信息
4) 到步驟1（主路徑）
[編輯]
後置條件
後置條件 部分總結了在場景結束後事務的狀態。

[編輯]
業務規則
業務規則是一些成文的或未成文的規則，對於用例來說它決定了一個組織是如何執行業務的。業務規則是一個特殊種類的假定。它可能適用於某一個用例或者整個用例，甚至整個業務。

[編輯]
注釋
經驗告訴我們，不管採用何種模版，分析人員發現總有重要的信息不適合模版的結構。因此每一種模版通常包含了這種明顯不能避免的信息的部分。

[編輯]
作者與日期
這部分列出創建用例的版本和誰書寫的。還需要列出開發過程中從早期階段開始的每個用例版本的日期。作者習慣在下面列出，因為它不被認為是重要的信息；用例是共同努力的結晶，並且它們被所有人擁有。

[編輯]
用例的效益
用例是一個較新的，比較敏捷的捕獲軟體需求的形式。用例經常和大的，統一的文檔形成對比。這些大文檔想要在新系統開始構成前，完整的表達出所有可能的需求，但這種做法通常都是失敗的。

用例的幾點優勢:

用例已經證實更容易被業務用戶理解，因此它也是開發人員和最終用戶的很好的溝通橋梁。
用例對於確定范圍很有用。用例使分階段交付從而一步步完成項目變得容易； 它們能夠在優先度變化時相對較容易的添加或從軟體項目移去。
用例可跟蹤。
用例能夠作為估計，制定進度和驗證成果的基礎。
用例防止了不成熟的設計
用例不使用特定語言
用例允許我們去講故事。能夠容易的採用將需求轉換為故事或場景這一具體的方法來描述用例。
用例在項目中可復用。 用例在每一次迭代中都能進一步演化，用例可以用於捕獲需求，成為程序員的開發依據，發展為測試用例，到最後成為用戶手冊。
用例與用戶和系統交互相關。它們使軟體開發者在開發之前或當中就能夠開始用戶介面設計。
用例將需求置於上下文中，它們能夠清楚地描述業務活動間的關系。
[編輯]
用例的局限性
用例不是沒有局限性:

用例在捕獲系統功能需求上表現很優秀，但是它們並不適合方便的捕獲非功能需求。盡管一些用例支持者過於熱心的主張，還是需要其它的方法去捕獲非功能需求。
用例模版不能自動保證清晰。清晰要依靠書寫者的技巧。
用例並不像支持者說的那樣易於理解。 There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.(如何正確地向最終用戶和程序員解釋這些用例是一個需要花費時間學習的事情。)
極限編程的說明者通常認為用例是沒用的文檔，他們更喜歡用較簡單的用戶故事這一方法。
可用性設計人員批評用例在開發過程中過早的引入了用戶介面設計。他們指出用例描述用戶和系統之間的交互，很顯然它和用戶介面設計重疊了。不好的用例描述將過細的，專斷的用戶介面設計包含於交互的描述中，即使用例的一個原則是不要加入實現的細節。

2. 什麼是用例

什麼是用例？
用例是向參與者提供重要價值的操作序列。認識它的另一種途徑是：用例描述實際參與者與系統交互的方式。基本用例是一種簡化、抽象且通用的用例，它以獨立於技術和實現的方式描述用戶的意圖。基本用例是一種結構化的敘述，用應用程序領域和用戶的語言來表達，它包含對任務或交互的簡化、通用、抽象、與技術無關且獨立於實現的描述。從擔當某個（或某些）系統角色的用戶的觀點來看，基本用例是完整而有意義的，並且設計得很好，這就體現了交互背後的目的或意圖。

3. 用例是什麼

用例，英文為use case，或譯使用案例、用況，是軟體工程或系統工程中對系統如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術。

在UML的文檔中，Use Case的定義是：在不展現一個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。

每個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰可以用系統做什麼，從而獲得一個明確的業務目標。編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例一般是由軟體開發者和最終用戶共同創作的。

Use Case 由以下元素組成：名稱、簡單描述、事件流、關系、活動圖和狀態圖、Use Case 圖、特殊需求、前條件、後條件。

(3)包含用例是一種什麼技術擴展閱讀：

使用 use case 十大誤區

1、系統的boundary 沒有定義或經常改變；

2、從系統觀點而不是actor觀點來定義Use Case；

3、Actor的名稱不一致；

4、Use Case 定義過多；

5、Use Case 和actor之間的關系象蜘蛛網一樣錯綜復雜；

6、Use Case的說明太長；

7、Use Case的說明不清楚；

8、Use Case沒有正確的描述功能需求；

9、用戶無法理解Use Case；

10、Use Case 無法正常結束。

4. 基用例和包含用例的功能分別是什麼

用例圖的包含關系和擴展關系區別為：使用不同、執行不同、添加不同。

1、用例：是軟體工程或系統工程中對系統如何反應外界請求的描述。

2、用例圖：是對包括變數在內的一組動作序列的描述，系統執行這些動作，並產生傳遞特定參與者的價值的可觀察結果。

包含關系是：一個用例可以簡單地包含其他用例具有的行為，並把它所包含 的用例行為作為自身行為的一部分。

擴展關系是：一個用例被定義為基礎用例的增量 擴展，是把新的行為插入到已有的用例中的辦法。

核心原則：

當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟體。用AM的說法就是，如果你現在並不需要這項額外功能，那就不要在模型中增加它。

要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要基於現有的需求進行建模，日後需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。