|
用例，或譯使用案例、用況(Use Case)是軟件工程或系統(tǒng)工程中對系統(tǒng)如何反應(yīng)外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術(shù)。每個用例提供了一個或多個場景，該場景說明了系統(tǒng)是如何同最終用戶或其它系統(tǒng)交互(interact)的，也就是誰可以用系統(tǒng)做什么，從而獲得一個明確的業(yè)務(wù)目標(biāo)。編寫用例時要避免使用技術(shù)術(shù)語，而應(yīng)該用最終用戶或者領(lǐng)域?qū)＜?/i>的語言。用例一般是由軟件開發(fā)者和最終用戶共同創(chuàng)作的。 在1986年，Ivar Jacobson，UML和統(tǒng)一過程的重要貢獻者，提出了用例的概念。Jacobson的思想很有影響力，也很有發(fā)展力。之后在這個科目上又有很多貢獻，在定義用例是什么和怎么有效的書寫用例方面最重要，最有影響力也最全面的，是Alistair Cockburn，他寫的書籍是《編寫有效用例》。 用例迅速成為獲取功能需求最常用的手段。用例最初是和面向?qū)ο笠煌岢龅?。但是它不止局限于面向?qū)ο笙到y(tǒng)，因為用例實質(zhì)上不是面向?qū)ο蟆?/p>
[編輯]用例范圍和目標(biāo)每個用例集中描述如何獲得一個業(yè)務(wù)目標(biāo)或任務(wù)。從傳統(tǒng)的軟件工程視角來看，用例只是描述了系統(tǒng)的一個特征。所以對大部分軟件項目來說，這就意味著需要很多（有可能是數(shù)十個）用例來完整的描述新系統(tǒng)。一個特殊軟件項目的正規(guī)度和項目的不同階段將會影響每一用例需要的詳細(xì)程度。 一個用例定義了外部執(zhí)行者和被考慮的系統(tǒng)之間的交互來實現(xiàn)一個業(yè)務(wù)目標(biāo)。執(zhí)行者是在系統(tǒng)外部和系統(tǒng)交互的人；一個執(zhí)行者可以是一類用戶，用戶可以扮演的角色或者其它系統(tǒng)。 用例把系統(tǒng)看作"黑盒"，同系統(tǒng)的交互，包括系統(tǒng)的響應(yīng)都是可以在系統(tǒng)外部感知的。它是一個deliberate policy，因為它簡化了需求的描述，避免了對功能如何實現(xiàn)做出假設(shè)的陷阱。 用例應(yīng)該:
[]用例圖用例圖并不是畫成了圖形的用例。用例圖包含一組用例。每一用例用橢圓表示，放置在矩形框中；矩形框表示整個系統(tǒng)。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其他軟件、硬件等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有交互。 許多人通過UML認(rèn)識了用例，UML定義為展現(xiàn)用例的圖形符號。 UML并沒有為描述用例定義書寫格式的標(biāo)準(zhǔn)，因此許多人誤認(rèn)為這些圖形符號就是用例本身；然而，圖形符號只能給出最簡單的一個或一組用例的概要。 UML是用例圖形符號最流行的標(biāo)準(zhǔn)。但是，還有一些其它的可選擇的標(biāo)準(zhǔn)。 []書寫用例[]細(xì)度Alistair Cockburn 在編寫有效用例一書中確定了三種書寫用例的細(xì)度。 []摘要摘要用例有很少的句子組成來總結(jié)的用例。它十分適合在電子表格中計劃軟件開發(fā)。一個摘要用例能夠簡單插入電子表格的單元格中并且用表格中的其它列記述業(yè)務(wù)優(yōu)先級，技術(shù)復(fù)雜度，版本號等。 []非正式一個非正式的用例由文本段落組成，包括了上面提到的那些列，用總結(jié)或故事的形式詳細(xì)的描述了用例。 []完整正式一個完整正式或者復(fù)雜的用例是一個以包含了不同部分的長模版為基礎(chǔ)的正規(guī)的文檔。該用例在下面的用例模版部分進行討論。 []適當(dāng)使用一些軟件開發(fā)方法學(xué)只需要非正式的用例來定義需求。然而，開發(fā)方法學(xué)需要完整正式或詳細(xì)的用例來定義需求。較大且較復(fù)雜的項目更需要使用完整正式的用例。 []用例模版編寫詳細(xì)的或完整的用例，尚無通用的模板(template)。 現(xiàn)在存在很多相互競爭的模板。同時，程序員們也被鼓勵用那些適合于他們的工作或者他們所做項目的模板，相對于某個指定模板的細(xì)節(jié)來說，項目的標(biāo)準(zhǔn)化要重要的多，但是這些模板的關(guān)鍵部分都是大體相同的，所以，雖然在某些術(shù)語上或者其他一些方面上存在不同，但是這些用例從本質(zhì)上來說，是大同小異的。 典型部分包括:
不同的模版經(jīng)常有其它部分，如，假設(shè)，異常，建議，技術(shù)要求。也會有行業(yè)細(xì)節(jié)部分。 []用例名用例名為用例提供了一個唯一標(biāo)識。它要用動/賓格式書寫，并且要充分，達到最終用戶能夠明白用例中描述的是什么。 []迭代迭代部分通常需要告知讀者用例完成的階段。最初，為業(yè)務(wù)分析和確定范圍的用例和用于軟件開發(fā)的用例肯定會有許多不同。老版本的用例可能還在當(dāng)前文檔中，因為它們對不同的用戶群可能會有價值。 []綜述綜述 部分用于在主體完成之前捕獲基本場景。它提供了快速的總結(jié)，避免了讀者瀏覽全部內(nèi)容，能夠很快的理解該用例的用途。 []前置條件前置條件 部分用來表達當(dāng)用戶開始用例時某些條件必須為真。但是它們不是啟動用例的觸發(fā)器。 []觸發(fā)器觸發(fā)器 部分描述了啟動用例的起始條件。 []基本事件流最低限度，每一個用例都需要描述一個主場景或者典型事件流。主事件流一般是一組有編號的步驟，如：
……其他 []備選路徑用例可能包含第二條路徑，或者和主題不同的備選場景。異?；虍?dāng)出錯時會發(fā)生什么事情也需要描述出來，這種描述可以在備選路徑中或者在它本身的部分。備選路徑使用基本事件流中的序號來標(biāo)示在哪一點上同基本場景不同，并且如果合適它從哪一點回到基本場景中。目的是避免不必要的重復(fù)信息。 備選路徑的例子：
異常路徑的例子：
[]后置條件后置條件 部分總結(jié)了在場景結(jié)束后事務(wù)的狀態(tài)。 []業(yè)務(wù)規(guī)則業(yè)務(wù)規(guī)則是一些成文的或未成文的規(guī)則，對于用例來說它決定了一個組織是如何執(zhí)行業(yè)務(wù)的。業(yè)務(wù)規(guī)則是一個特殊種類的假定。它可能適用于某一個用例或者整個用例，甚至整個業(yè)務(wù)。 []注釋經(jīng)驗告訴我們，不管采用何種模版，分析人員發(fā)現(xiàn)總有重要的信息不適合模版的結(jié)構(gòu)。因此每一種模版通常包含了這種明顯不能避免的信息的部分。 []作者與日期這部分列出創(chuàng)建用例的版本和誰書寫的。還需要列出開發(fā)過程中從早期階段開始的每個用例版本的日期。作者習(xí)慣在下面列出，因為它不被認(rèn)為是重要的信息；用例是共同努力的結(jié)晶，并且它們被所有人擁有。 []用例的效益用例是一個較新的，比較敏捷的捕獲軟件需求的形式。用例經(jīng)常和大的，統(tǒng)一的文檔形成對比。這些大文檔想要在新系統(tǒng)開始構(gòu)成前，完整的表達出所有可能的需求，但這種做法通常都是失敗的。 用例的幾點優(yōu)勢:
[]用例的局限性用例不是沒有局限性:
|
|
|
