論“用例”的獲取方法

一、RUP的簡介及基本原理

1. RUP的簡介

RUP是Rational Software公司開發的一種軟件開發過程，其特點是：“用例”驅動；以架構為中心；迭代和增量開發。“用例”(use case)不僅可以描述系統需求，而且驅動系統的設計、實現和測試。

2. RUP的基本原理

在RUP中，有五個場景(View）：Use Case場景(Use Case View)、邏輯場景(Logic View)、進程場景(process View)、實現場景(Implementation View)和發布場景(Deployment View)。在Use Case場景中，客戶和商務分析員對Use Case進行描述；在邏輯場景中，設計師對系統進行分析和設計；在進程場景中，設計師對系統可能出現的并發性、運行速度和分布特性進行描述。實現場景則反映了程序開發員開發實現的過程。發布場景是描述系統管理員和組裝人員實施系統發布和管理的過程。值得強調的是，系統構架的設計是在邏輯場景中描述的。

另外在RUP中還有四個模型，即Use Case模型(Use Case Model）、分析模型(Analysis Model)、設計模型(Design Model)和實現模型(Implementation Model)。Ue Casse模型包含Use Case Diagram和Use Case文檔。Use Case模型是其他三個模型的基礎，分析模型即是概念模型(Conceptual Model)，是系統分析所得到的結果，分析模型包含了類圖(Class Diagram)、次序圖(Sequence Diagram)以及活動圖(Activity Diagram)。設計模型則是構架設計和系統設計的結果。當設計模型完成后，開發編程人員便可以進行編程了。設計模型主要包含了類圖、次序圖和狀態圖(State Chart Diagrams)。分析模型和設計模型看起來有許多相似之處，但兩者的含義有本質的區別。分析模型強調的是問題的范圍，但并不給出解決問題的方案，分析模型并不涉及具體的技術和平臺。最后一個模型是實現模型。實現模型包含構件圖（Component Diagram），從這個模型出發，開發編程人員可以產生骨架源程序(Skeleton Source Code)，也可以從源程序出發更新設計模型。

二、“用例”的獲取及建模

在UML中，“用例”被定義成系統執行的一系列動作，動作執行的結果能被指定執行者察覺到。

“用例”有以下特點：“用例”捕獲某些用戶可見的需求，實現一個具體的用戶目標；“用例”由執行者激活，并提供確切的值給執行者；“用例”可大可小，但它必須是對一個具體的用戶目標實現的完整描述。

1. “用例”獲取的工作步驟

“用例”獲取的過程中最關鍵的因素是和客戶的溝通。

“用例”是從用戶的角度看待系統，而不是基于程序員的角度。這樣的話“用例”驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整地體現。用戶和程序員間通過“用例”溝通，避免了牛頭馬嘴的尷尬局面。從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什么。在Jacobson發明了“用例”的概念之后，需求獲取就變成問用戶要利用系統做什么。這是立場不同導致的結果。用戶通常并不關心系統是如何實現的，對他們來說，更重要的是要達到其目的。相反大部分程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，“用例”方法能夠調和雙方的矛盾，因為雖然“用例”是來源于用戶，服務于用戶，但是它同樣可以用于開發的流程。當系統的開發過程都是基于“用例”的，用“用例”獲取需求，用“用例”設計，用“用例”編碼，用“用例”測試的時候，這個開發過程就是”用例”驅動的。

有三種方法來確定“用例”：首先，明確執行者和他們的角色，然后確定業務過程，在這一過程中每一個參與者都在為確定“用例”而努力。其次，確定系統所能反映的外部事件，然后把這些事件與參與的執行者和特定的“用例”聯系起來。最后，以特定的說明形式表達業務過程或日常行為，從這些說明中獲得“用例”，并確定參與到“用例”中的執行者，有可能從現在的功能需求說明中獲得“用例”。

獲取“用例”主要有兩個過程：

(1)獲取執行者。獲取“用例”首先要找出系統的執行者?？梢酝ㄟ^用戶回答一些問題的答案來識別執行者。以下問題可供參考：誰使用系統的主要功能(主要使用者)；誰需要系統支持他們的日常工作；誰來維護、管理使系統正常工作(輔助使用者)；系統需要操縱哪些硬件。

(2)獲取“用例”。一旦獲取了執行者，就可以對每個執行者提出問題，以獲取“用例”。

2. 參與者的識別

參與者是指在系統之外，透過系統邊界和系統進行有意義的交互的任何事物。面對一個系統時，你應該問以下問題：

(1)誰使用系統?(2)誰改變系統數據?(3)誰從系統獲取信息?(4)誰需要系統的支持來完成日常工作?(5)誰負責管理并維護系統正常運行?(6)系統要應付哪些硬設備?(7)系統要和其他的系統交互嗎?(8)誰對系統產生的結果感興趣?(9)時間、氣候等外部條件呢?

當你回答完這些問題之后，你的答案基本上就涵蓋了參與者的候選人。

3. “用例”的識別

識別“用例”是從業務建模開始的，也就是說我們描述“用例”是從用戶的角度即用戶觀點出發的識別行為，描述“用例”是用純粹的業務語言，而不是技術語言。因此，用戶的命名也是從用戶的角度出發，描述用戶要做的一件通過系統完成有目的、有結果的行為。

4. 建立”用例”模型

長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情境來了解需求。但是，這些使用情境是非正式的，雖然經常使用，卻難以建立正式文檔。

“用例”模型描述的是外部執行者(Actor)所理解的系統功能?！坝美蹦Ｐ陀糜谛枨蠓治鲭A段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成的共識。首先，它描述了待開發系統的功能需求；其次，它將系統看做黑盒，從外部執行者的角度來理解系統；第三，它驅動了需求分析之后各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的系統，從而影響到開發工作的各個階段和 UML 的各個模型。在UML中，一個“用例”模型由若干個“用例”圖描述，“用例”圖主要元素是“用例”和執行者。

三、 “用例”的不足

“用例”的出現雖然能夠解決很大一部分問題，但是它并不是萬能的。首先，把像UML那樣的設計圖交給程序員來實現是一件極為困難的事情。問題的關鍵在于那種設計看上去不錯，可你打算編程來實現它的時候就出現了問題。

其次，不但是分析員和程序員之間的溝通存在問題，客戶和分析員之間的隔閡更大?？蛻魧τ凇坝美钡挠^點仍然不能夠接受，這仍然需要開發人員作出不懈的努力來調和這一矛盾。再次，單純的憑借沒有完善理論支撐的設計圖就輕率地決定這個軟件的設計是極其危險的。一開始寫出的“用例”在項目結束時一看往往會嚇一大跳：設計和實現已經完全脫節了。其中主要的代溝有兩個：客戶和開發人員之間，分析員和程序員之間。

參考文獻：

[1]劉偉琴，劉洪濤.軟件需求(第2版)[M].北京：清華大學出版社，2004.

[2]蔣慧.軟件需求管理”用例”方法(第2版)[M].北京:中國電力出版社，2004.

(江西省信息科技學校)