在具體的需求過程中，有大的用例（業(yè)務(wù)用例），也有小的用例。主要是由于用例的范 圍決定的。用例像是一個(gè)黑盒，它沒有包括任何和實(shí)現(xiàn)有關(guān)或是內(nèi)部的一些信息。它很容易就被用戶（也包括開發(fā)者）所理解（簡單的謂詞短語）。如果用例不足以表達(dá)足夠的信息來支持系統(tǒng)的開發(fā)，就有必要把用例黑盒打開，審視其內(nèi)部的結(jié)構(gòu)，找出黑盒內(nèi)部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個(gè)系統(tǒng)可以被清晰的了解為止。
為什么要采用這種分析方法呢？計(jì)算機(jī)系統(tǒng)除了在與外界系統(tǒng)、人員有一系列的交互，在系統(tǒng)內(nèi)部也往往存在著復(fù)雜的交互。因此，在系統(tǒng)建模時(shí)，除了描述系統(tǒng)與外界的交互，同時(shí)還要描述系統(tǒng)內(nèi)部的交互。傳統(tǒng)的MIS系統(tǒng)中，系統(tǒng)與外界的交互較多。典型的，如ATM取款機(jī)：存在著大量的用戶與ATM，ATM與其它系統(tǒng)的交互。而電信領(lǐng)域的系統(tǒng)，與外界的交互較少。例如，系統(tǒng)的輸入可能僅僅是從交換機(jī)上采集信息，然后由系統(tǒng)進(jìn)行處理。系統(tǒng)的復(fù)雜邏輯包含在系統(tǒng)內(nèi)部處理的流程上，而非與外部系統(tǒng)的交互。建模主要任務(wù)是表達(dá)系統(tǒng)內(nèi)部的交互。
用例圖適于表達(dá)交互，之所以上面使用了電信系統(tǒng)，是因?yàn)橛美钤鐏碜杂贓ricsson的交換機(jī)系統(tǒng)。當(dāng)時(shí)，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，并于1994年提出了OOSE方法，其最大特點(diǎn)是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業(yè)工程和需求分析。隨著用例的發(fā)展，用例被大量的用于對功能進(jìn)行描述。每個(gè)用例代表了系統(tǒng)與外部ACTOR的交互?？梢圆扇№樞驁D來表達(dá)用例的具體操作程序。ACTOR用于確定系統(tǒng)的邊界。
ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：
1. 需求并不是在項(xiàng)目一開始就很明確，往往是隨著項(xiàng)目的推進(jìn)，逐漸細(xì)化。
2. 人的認(rèn)知往往具有層次的特性。從粗到細(xì)、從一般到特殊。采用不同的層次來描述，適于認(rèn)知的過程。
在開發(fā)過程的初始階段，可以根據(jù)具體的項(xiàng)目特點(diǎn)，制訂開發(fā)各個(gè)視圖之間的關(guān)聯(lián)原則，指導(dǎo)規(guī)范。在開發(fā)的過程中，視圖的組織原則應(yīng)不斷進(jìn)行維護(hù)、更新。 識別ACTOR來識別系統(tǒng)與外界交互的實(shí)體。ACTOR具有特定領(lǐng)域的特征，例如：交換機(jī)（采集系統(tǒng)）、97信息系統(tǒng)等。在系統(tǒng)層次的ACTOR確定了系統(tǒng)的邊界。
識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細(xì)化。注：系統(tǒng)開發(fā)需要一定的規(guī)則來確定，如何來分解用例；可能基于原有系統(tǒng)的經(jīng)驗(yàn)，或是參考現(xiàn)有資料。
當(dāng)用例細(xì)化到可以被理解的層次。需要基于用例進(jìn)行下一步的開發(fā)。如前面提到的，用例主要用來描述交互。因此，存在交互的實(shí)體和交互的細(xì)節(jié)。交互的實(shí)體采用類圖來描述；而交互的細(xì)節(jié)，采用順序圖來描述。
當(dāng)系統(tǒng)復(fù)雜到一定層次時(shí)，類圖和順序圖可能不能足以描述其復(fù)雜程度。在該情況下，需要使用狀態(tài)圖來輔助闡述。狀態(tài)圖和順序圖之間使用事件聯(lián)結(jié)在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規(guī)范強(qiáng)制一致性。
可以說，之前說的所有的東西都是為了能夠?qū)С鲇美谛枨笾械淖饔?。用例是從用戶的角度看待系統(tǒng)，而不是基于程序員的角度。這樣的話，用例驅(qū)動(dòng)的系統(tǒng)能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統(tǒng)開發(fā)鏈中完整的體現(xiàn)。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統(tǒng)開發(fā)者總是通過情節(jié)來獲取需求，是問用戶希望系統(tǒng)為他做什么。在Jacobson發(fā)明了用例的概念之后，需求獲取就變成
項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
