用例的本質

2021-04-19 18:41:08 字數 2380 閱讀 7383

提到uml中的用例,很多人可能都會覺得很熟悉經常聽說。如果問一句什麼是用例,很多的回答就是用例圖中的乙個橢圓。用例僅僅是用例圖中的乙個橢圓嗎?當然不是,那麼用例的本質是什麼呢?

1、用例發展史

為了搞清用例的本質我們首先了解一下用例技術的發展史。uml中的用例概念是由有uml之父ivar jacobson在60年代提出。後來alistair cockburn從ivar jacobson那裡學習了用例,並且結合自己的實踐對用例進行了繼承和發展,提出了「基於目標的用例」。在uml形成的時候,用例uml作為乙個重要的部分被納入了uml。用例被認為是第二代物件導向技術的標誌。

2、用例的本質

用例的本質並不是uml中的乙個橢圓符號,而是描述系統中各個相關人員之間就系統的行為所達成的契約,它應用功能分解的方法,站在系統之外,使用文字表達系統的功能性需求。在uml中為了視覺化使用乙個橢圓來表示,用例的具體內容通過使用用例模板來表達。用例技術是迄今為止最為深刻、準確和有效的系統功能需求描述方法。

用例技術有如下的一些特點:用例是一種半角化的方式,它不是使用一種形式化的語言,而是使用自然語言來描述需求。但是它卻明確的提出了角色和用例的概念,以及角色和用例進行通訊的規則,以及用例模板的主要內容。嚴格的結構和形式會使需求變得生硬、無用,沒有結構和形式的需求又不易交流。這種半形式結構使得人們的創造性得以發揮,也使得系統的終端使用者能夠輕鬆的閱讀;在每個用例和所有的描述層次中,都描述了錯誤時的系統處理。系統複雜性大部分都是處理錯誤情況,這樣能夠在需求分析階段檢測出相關的問題進行分析,而不是在以後的階段中發現。這是我在使用用例過程中最為深刻的一點,我們在寫需求的時候僅僅描述正確的使用者需求,很少提及錯誤情況;用例提供了可以在其上處理其他專案資訊的骨架,從而實現用例驅動。

3、用例與需求

很多人使用用例描述需求後,就會產生疑問用例和需求到底是什麼關係。用例是需求,但並不是系統的全部需求,用例描述的只是功能性方面的需求。不要試圖把所有的需求都以用例的方式表示出來。有些人認為用例可以表示所有的系統需求,因此用uml來表示那些事實上很難用用例表示的需求,這樣做是不對的。用用例分析需求有如下的特點:

1.      用例從使用系統的角度描述系統中的資訊,即站在系統外部**系統的功能,而不考慮系統內部對該功能的具體實現方式。

2.      用例描述了使用者提出的一些可能需求,對應乙個具體的使用者目標,用例可以促進與使用者溝通、理解正確的需求,同時也可以用來劃分系統與外部實體的界限,是物件導向系統設計的起點,是類、物件、操作的**。

3.      用例是對系統行為的動態描述。

4、用例驅動

可能很多人都聽說過資料驅動、用例驅動這樣的字眼。為什麼說使用uml進行軟體開發是用例驅動的?因為用例代表系統中各個相關人員之間就系統的行為所達成的契約,乙個軟體的開發就是從分析這些工作開始的。軟體的開發過程分為需求分析、設計、實現、測試等階段,用例把所有這些都**再一起,用例分析的結果也為**系統的開發時間和預算提供依據,保證專案的順利進行,從各個方面綜合起來講軟體開發是用例驅動的。

5、用例模板

用例圖只是簡單地視覺化描述系統,我們還需要對用例進行詳細的說明。為了明確的描述用例我們需要乙個用例模板,但是至今並沒有統一的用例模板。用例模板的內容一般包括:簡要描述、前置條件、後置條件、基本事件流、備選事件流等等。

簡要描述:對用例的角色、目的的簡要描述。

前置條件:執行用例之前系統必須要處於的狀態,或者要滿足的條件。

後置條件:用例一旦執行後系統所處的狀態。

基本事件流:描述該用例的基本流程,指每個流程都「正常」運作時所發生的事情,沒有任何備選流而只有最有可能發生的事件流。

備選事件流:表示這個行為或流程是可選的或備選的,並不是總要總要執行它們。

下面是乙個用例模板的示例:  

用例:《編號》《名稱》

特徵資訊:

用例在系統中的目標(用例目標描述)

範圍(當前考慮的是哪個系統)

級別(概要任務/首要任務/子功能)

前提條件(用例執行前系統用具有的狀態)

成功後繼條件(用例成功執行後應具有的狀態)

失效後繼條件(用例沒有完成目標的狀態)

首要角色(與該用例關聯的首要角色)

觸發(啟動該用例執行的系統動作)

主要步驟:

《步驟編號》《動作描述》

擴充套件:《有變化情況的步驟編號》《條件》:《動作或另外乙個用例》

變異:《步驟或變化編號》《變異列表》

優先順序(該用例對於系統組織的關鍵程度)

效能目標(該用例的執行時間耗費)

頻度(該用例被執行的頻度)

從屬用例:(可選)

下屬用例:

與首要角色的聯絡渠道(包括互動式、靜態檔案、資料庫等)

公開問題:(可選)

列出關於該用例的未解決的問題

用例的本質

提到uml中的用例,很多人可能都會覺得很熟悉經常聽說。如果問一句什麼是用例,很多的回答就是用例圖中的乙個橢圓。用例僅僅是用例圖中的乙個橢圓嗎?當然不是,那麼用例的本質是什麼呢?1 用例發展史 為了搞清用例的本質我們首先了解一下用例技術的發展史。uml中的用例概念是由有uml之父ivar jacobs...

業務用例與系統用例的區別

1 業務用例就是要完成的業務,系統用例是系統要做的事情,兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務,需求模型主要是描述為了滿足業務需求系統要做什麼,因此,需求模型與業務模型相比,它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統,它可以滿足使用者的取款 改密 查詢等需...

業務用例和系統用例

拋開前一篇文章談的總體思路,我們今天來談一下需求分析工作實質性的做些什麼。在這裡,我們,將主要關注於分析層面,也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作,因為它包含了設計模型的概念,但是我又把它歸納了一塊到需求分析階段,原因在於邏輯模型中存在了業務物件...