靳佩瑤

摘要：需求分析和用例建模是軟件需求工程研究的熱點，通過討論二者的作用及相互關(guān)系，得到如何使用用例分析技術(shù)為捕獲的軟件需求建立簡潔明了的邏輯模型的一般方法。首先介紹用例、軟件需求、需求建模等基本概念，然后探討軟件用例建模的一般過程，最后結(jié)合實例給出了使用用例進(jìn)行需求建模的實現(xiàn)方法及采用用例建模的優(yōu)勢所在。

關(guān)鍵詞：用例；需求分析；建模

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）29-6860-03

需求分析是指對要解決的問題進(jìn)行詳細(xì)的分析，弄清問題的要求。包括需要輸入什么數(shù)據(jù)，要得到什么結(jié)果，最后應(yīng)該輸出什么。可以說，在軟件工程當(dāng)中的需求分析就是確定要軟件實現(xiàn)的功能。假如在需求分析時分析者們未能正確地認(rèn)識到顧客的需要的話，那么最后的軟件不可能達(dá)到顧客的需要或者軟件無法在規(guī)定的時間內(nèi)完工。

用例建模是一想日益流行的基于面向?qū)ο笏枷氲男枨蠓治黾夹g(shù)，它用過用例的參與者和用例一級用力之間的關(guān)系來描繪系統(tǒng)外在可見的需求，使用戶和開發(fā)者共同剖析系統(tǒng)功能需求的起點。長期的實踐證明，建立簡介準(zhǔn)確的表示模型是解決問題的關(guān)鍵。標(biāo)準(zhǔn)建模語言UML提供了無淚模型圖，其中用例圖特別適合與需求分析領(lǐng)域。

1 重要概念

1） 用例模型（use case model）：用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型，它可以作為客戶和開發(fā)人員之間的契約。用例是貫穿整個系統(tǒng)開發(fā)的一條主線。同一個用例模型即為需求工作流程的結(jié)果，可當(dāng)作分析設(shè)計工作流程以及測試工作流程的輸入使用。

2） 用例（use case）：用例就是對系統(tǒng)功能的描述，一個用例描述的是整個系統(tǒng)功能的一部分，這一部分一定要是在邏輯上有相對完整的功能流程。在使用UML的開發(fā)過程中，需求是用用例來表達(dá)的，界面是在用例的輔助下設(shè)計的，很多類是根據(jù)用例來發(fā)現(xiàn)的，測試實例是根據(jù)用例來生成的，包括整個開發(fā)的管理和任務(wù)分配，也是依據(jù)用例來組織的。

3） 參與者（Actor）：參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統(tǒng)等等。在處理參與者時，重要的是角色，并不關(guān)心人或人的職務(wù)等屬性，其圖形化表示是一個人。

4） 用例關(guān)系：用例關(guān)系用來表示用例間的關(guān)系。主要包括擴(kuò)展（extend）、包含（include）和泛化（generalization）。為了表述用例之間的關(guān)系，使得系統(tǒng)設(shè)計有一個很好的框架，我們引入上述三種關(guān)系來表達(dá)系統(tǒng)的完整功能。

Extend 擴(kuò)展：

基用例路徑本身是完整的，可能是一條擴(kuò)展路徑。擴(kuò)展路徑步驟多；擴(kuò)展路徑內(nèi)部還有擴(kuò)展點-擴(kuò)展之?dāng)U展；擴(kuò)展路徑未定或容易變化-分離以“凍結(jié)”基用例。

Include 包含：某些步驟在多個用例重復(fù)出現(xiàn)，且單獨形成價值，當(dāng)用例步驟較多時，可用Include簡化。

Generalization 泛化：泛化是同一業(yè)務(wù)目的不同技術(shù)實現(xiàn)，一個用例可以特化另一個更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例間的泛化關(guān)系中，子用例表示父用例的特殊形式，子用例繼承了父用例的行為和屬性，也可以增加新的行為和屬性或覆蓋父用例中的行為。

2 需求分析階段的工作

2.1 需求獲取

1） 刻畫出軟件的功能和性能；2） 指明軟件與其他系統(tǒng)元素的接口；3） 建立軟件必須滿足的約束。

2.2 需求建模

需求分析建立起來的模型為日后軟件設(shè)計人員提供了可被翻譯成數(shù)據(jù)、體系結(jié)構(gòu)、接口和過程設(shè)計的模型。

2.3 需求規(guī)格說明

需求規(guī)格說明為開發(fā)人員和用戶提供軟件開發(fā)完成時質(zhì)量評價的依據(jù)。

2.4 需求評審

1） 需求分析研究的對象是用戶的要求。2） 必須全面理解用戶的各項要求，準(zhǔn)確表達(dá)被接受的用戶要求。3） 只有經(jīng)過確切描述的軟件需求才能成為軟件設(shè)計的基礎(chǔ)。

3 用例建模實例分析

3.2 用例建模

與系統(tǒng)核心功能相關(guān)的主要有兩種用戶：招生人員與信息錄入員。招生人員負(fù)責(zé)協(xié)調(diào)整個招生工作，可以參與到招生工作的各階段中；而信息錄入員則主要負(fù)責(zé)考生信息與考生成績錄入工作。在用例建模中這兩種用戶被定義為行為者。

下面主要細(xì)化已提出的兩個用例：考生錄取處理與專業(yè)考試處理。

1） 專業(yè)考試處理功能可分為：專業(yè)考試基礎(chǔ)信息維護(hù)、考生基本信息處理 、考生專業(yè)成績處理、專業(yè)考試合格證處理、招生計劃信息處理。

2） 考生錄取處理功能可分為：各省文化考試基礎(chǔ)信息維護(hù)、考生文化成績處理、考生志愿信息處理、預(yù)錄取處理、最終錄取處理。

用例建模的過程，除了圖之外，還必須給出必要的解釋。否則，建模是不完整的。圖2，“專業(yè)考試處理”用例包含（include）了“專業(yè)考試基礎(chǔ)信息維護(hù)”等5個子用例。其中信息錄入員因為權(quán)限的關(guān)系，僅參與“考生基本信息處理”和“考生專業(yè)成績處理”兩個用例，而且在這兩個子用例中間也只有錄入信息和核對信息的功能，不能做信息的修改。而招生人員具備所有用例中的處理功能（除錄入員的錄入功能外）。5個子用例之間也有一定的關(guān)聯(lián)，首先，“考生基本信息處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”子用例，這是因為，“考生基本信息處理”中間的部分內(nèi)容（如考生的考試課目），是由該考生的報考的專業(yè)決定的，而專業(yè)的情況，是“專業(yè)考試基礎(chǔ)信息維護(hù)”的功能。類似的，“考生專業(yè)成績處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”和“考生基本信息處理”子用例，這是因為，要進(jìn)行考生專業(yè)成績的錄入，維護(hù)等工作，必須在考生的基本信息和考生所報考專業(yè)的考試信息都完整的情況下進(jìn)行。“專業(yè)考試合格證處理”子用例依賴于“招生計劃信息處理”和“考生專業(yè)成績處理”子用例，這是因為發(fā)放專業(yè)考試合格證的前提是考生專業(yè)成績和招生計劃都處理完畢。

圖3，“考生錄取處理”包含（include）了“各省文化考試基礎(chǔ)信息維護(hù)”等5個子用例。信息錄入員參與了“考生文化成績處理”和“考生志愿信息處理”2個子用例，并且僅有錄入信息和核對信息的權(quán)限，不具有修改和維護(hù)的權(quán)限。招生人員具備所有用例的處理功能（除錄入員的錄入功能外）。5個子用例之間也具備一定依賴關(guān)系?！翱忌幕煽兲幚怼弊佑美蕾囉凇案魇∥幕荚嚮A(chǔ)信息維護(hù)”子用例，因為要錄入并維護(hù)考生的文化成績，前提是該考生所在省份所考類別的文化課課目的信息是完整準(zhǔn)確的。“預(yù)錄取處理”子用例依賴于“考生志愿信息處理”和“考生文化成績處理”兩個子用例，因為考生志愿、文化成績、專業(yè)成績、招生計劃（后兩者需要依賴“專業(yè)課考試處理”用例，圖3.3無法表示，可從圖3.1中看到）決定了預(yù)錄取的結(jié)果?！白罱K錄取處理”是一個審批和微調(diào)的過程，需要依賴于“預(yù)錄取處理”的結(jié)果。

4 用例建模的優(yōu)點

1） 用例建模完全是從外部站在用戶的角度上來描述系統(tǒng)功能的，把用戶需求和設(shè)計完全分離開來。用例模型主要描述系統(tǒng)的功能性需求。系統(tǒng)的設(shè)計由對象模型來描述。2） 用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)而不是分離的功能。3） 用例方法比傳統(tǒng)的方法更易于被用戶理解，用例方法是用戶和開發(fā)人員有效地溝通手段。

5 結(jié)束語

用例建模向人們展示用戶如何使用系統(tǒng)以及系統(tǒng)的工作流程。通過用例建模來觀察系統(tǒng)，有助于了解系統(tǒng)中最重要的部分，避免不必要的細(xì)節(jié)，來滿足用戶的需求和期望。用例建模技術(shù)以面向?qū)ο笏枷霝橹笇?dǎo)，注重參與者和用例一級用力之間的關(guān)系，對用戶需求有著極強(qiáng)的表述能力?？傊?，用例分析技術(shù)很好的解決了傳統(tǒng)面向過程需求分析技術(shù)對用戶需求描述不清、難以處理需求變化的問題。正確使用用例建模這項技術(shù)，會對軟件的設(shè)計、開發(fā)以及后期維護(hù)都帶來巨大的方便。

參考文獻(xiàn)：

[1] 張龍祥.UML與系統(tǒng)分析與設(shè)計[M].北京：人民郵電出版社，2001.

[2] Martin F.UML精粹[M].徐家福，譯.2版.北京：清華大學(xué)出版社，2002.

[3] 吳際，金茂忠.UML面向?qū)ο蠓治鯷M].北京：北京航空航天大學(xué)出版社，2002.endprint

摘要：需求分析和用例建模是軟件需求工程研究的熱點，通過討論二者的作用及相互關(guān)系，得到如何使用用例分析技術(shù)為捕獲的軟件需求建立簡潔明了的邏輯模型的一般方法。首先介紹用例、軟件需求、需求建模等基本概念，然后探討軟件用例建模的一般過程，最后結(jié)合實例給出了使用用例進(jìn)行需求建模的實現(xiàn)方法及采用用例建模的優(yōu)勢所在。

關(guān)鍵詞：用例；需求分析；建模

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）29-6860-03

需求分析是指對要解決的問題進(jìn)行詳細(xì)的分析，弄清問題的要求。包括需要輸入什么數(shù)據(jù)，要得到什么結(jié)果，最后應(yīng)該輸出什么?？梢哉f，在軟件工程當(dāng)中的需求分析就是確定要軟件實現(xiàn)的功能。假如在需求分析時分析者們未能正確地認(rèn)識到顧客的需要的話，那么最后的軟件不可能達(dá)到顧客的需要或者軟件無法在規(guī)定的時間內(nèi)完工。

用例建模是一想日益流行的基于面向?qū)ο笏枷氲男枨蠓治黾夹g(shù)，它用過用例的參與者和用例一級用力之間的關(guān)系來描繪系統(tǒng)外在可見的需求，使用戶和開發(fā)者共同剖析系統(tǒng)功能需求的起點。長期的實踐證明，建立簡介準(zhǔn)確的表示模型是解決問題的關(guān)鍵。標(biāo)準(zhǔn)建模語言UML提供了無淚模型圖，其中用例圖特別適合與需求分析領(lǐng)域。

1 重要概念

1） 用例模型（use case model）：用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型，它可以作為客戶和開發(fā)人員之間的契約。用例是貫穿整個系統(tǒng)開發(fā)的一條主線。同一個用例模型即為需求工作流程的結(jié)果，可當(dāng)作分析設(shè)計工作流程以及測試工作流程的輸入使用。

2） 用例（use case）：用例就是對系統(tǒng)功能的描述，一個用例描述的是整個系統(tǒng)功能的一部分，這一部分一定要是在邏輯上有相對完整的功能流程。在使用UML的開發(fā)過程中，需求是用用例來表達(dá)的，界面是在用例的輔助下設(shè)計的，很多類是根據(jù)用例來發(fā)現(xiàn)的，測試實例是根據(jù)用例來生成的，包括整個開發(fā)的管理和任務(wù)分配，也是依據(jù)用例來組織的。

3） 參與者（Actor）：參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統(tǒng)等等。在處理參與者時，重要的是角色，并不關(guān)心人或人的職務(wù)等屬性，其圖形化表示是一個人。

4） 用例關(guān)系：用例關(guān)系用來表示用例間的關(guān)系。主要包括擴(kuò)展（extend）、包含（include）和泛化（generalization）。為了表述用例之間的關(guān)系，使得系統(tǒng)設(shè)計有一個很好的框架，我們引入上述三種關(guān)系來表達(dá)系統(tǒng)的完整功能。

Extend 擴(kuò)展：

基用例路徑本身是完整的，可能是一條擴(kuò)展路徑。擴(kuò)展路徑步驟多；擴(kuò)展路徑內(nèi)部還有擴(kuò)展點-擴(kuò)展之?dāng)U展；擴(kuò)展路徑未定或容易變化-分離以“凍結(jié)”基用例。

Include 包含：某些步驟在多個用例重復(fù)出現(xiàn)，且單獨形成價值，當(dāng)用例步驟較多時，可用Include簡化。

Generalization 泛化：泛化是同一業(yè)務(wù)目的不同技術(shù)實現(xiàn)，一個用例可以特化另一個更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例間的泛化關(guān)系中，子用例表示父用例的特殊形式，子用例繼承了父用例的行為和屬性，也可以增加新的行為和屬性或覆蓋父用例中的行為。

2 需求分析階段的工作

2.1 需求獲取

1） 刻畫出軟件的功能和性能；2） 指明軟件與其他系統(tǒng)元素的接口；3） 建立軟件必須滿足的約束。

2.2 需求建模

需求分析建立起來的模型為日后軟件設(shè)計人員提供了可被翻譯成數(shù)據(jù)、體系結(jié)構(gòu)、接口和過程設(shè)計的模型。

2.3 需求規(guī)格說明

需求規(guī)格說明為開發(fā)人員和用戶提供軟件開發(fā)完成時質(zhì)量評價的依據(jù)。

2.4 需求評審

1） 需求分析研究的對象是用戶的要求。2） 必須全面理解用戶的各項要求，準(zhǔn)確表達(dá)被接受的用戶要求。3） 只有經(jīng)過確切描述的軟件需求才能成為軟件設(shè)計的基礎(chǔ)。

3 用例建模實例分析

3.2 用例建模

與系統(tǒng)核心功能相關(guān)的主要有兩種用戶：招生人員與信息錄入員。招生人員負(fù)責(zé)協(xié)調(diào)整個招生工作，可以參與到招生工作的各階段中；而信息錄入員則主要負(fù)責(zé)考生信息與考生成績錄入工作。在用例建模中這兩種用戶被定義為行為者。

下面主要細(xì)化已提出的兩個用例：考生錄取處理與專業(yè)考試處理。

1） 專業(yè)考試處理功能可分為：專業(yè)考試基礎(chǔ)信息維護(hù)、考生基本信息處理 、考生專業(yè)成績處理、專業(yè)考試合格證處理、招生計劃信息處理。

2） 考生錄取處理功能可分為：各省文化考試基礎(chǔ)信息維護(hù)、考生文化成績處理、考生志愿信息處理、預(yù)錄取處理、最終錄取處理。

用例建模的過程，除了圖之外，還必須給出必要的解釋。否則，建模是不完整的。圖2，“專業(yè)考試處理”用例包含（include）了“專業(yè)考試基礎(chǔ)信息維護(hù)”等5個子用例。其中信息錄入員因為權(quán)限的關(guān)系，僅參與“考生基本信息處理”和“考生專業(yè)成績處理”兩個用例，而且在這兩個子用例中間也只有錄入信息和核對信息的功能，不能做信息的修改。而招生人員具備所有用例中的處理功能（除錄入員的錄入功能外）。5個子用例之間也有一定的關(guān)聯(lián)，首先，“考生基本信息處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”子用例，這是因為，“考生基本信息處理”中間的部分內(nèi)容（如考生的考試課目），是由該考生的報考的專業(yè)決定的，而專業(yè)的情況，是“專業(yè)考試基礎(chǔ)信息維護(hù)”的功能。類似的，“考生專業(yè)成績處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”和“考生基本信息處理”子用例，這是因為，要進(jìn)行考生專業(yè)成績的錄入，維護(hù)等工作，必須在考生的基本信息和考生所報考專業(yè)的考試信息都完整的情況下進(jìn)行?！皩I(yè)考試合格證處理”子用例依賴于“招生計劃信息處理”和“考生專業(yè)成績處理”子用例，這是因為發(fā)放專業(yè)考試合格證的前提是考生專業(yè)成績和招生計劃都處理完畢。

圖3，“考生錄取處理”包含（include）了“各省文化考試基礎(chǔ)信息維護(hù)”等5個子用例。信息錄入員參與了“考生文化成績處理”和“考生志愿信息處理”2個子用例，并且僅有錄入信息和核對信息的權(quán)限，不具有修改和維護(hù)的權(quán)限。招生人員具備所有用例的處理功能（除錄入員的錄入功能外）。5個子用例之間也具備一定依賴關(guān)系?！翱忌幕煽兲幚怼弊佑美蕾囉凇案魇∥幕荚嚮A(chǔ)信息維護(hù)”子用例，因為要錄入并維護(hù)考生的文化成績，前提是該考生所在省份所考類別的文化課課目的信息是完整準(zhǔn)確的?！邦A(yù)錄取處理”子用例依賴于“考生志愿信息處理”和“考生文化成績處理”兩個子用例，因為考生志愿、文化成績、專業(yè)成績、招生計劃（后兩者需要依賴“專業(yè)課考試處理”用例，圖3.3無法表示，可從圖3.1中看到）決定了預(yù)錄取的結(jié)果?！白罱K錄取處理”是一個審批和微調(diào)的過程，需要依賴于“預(yù)錄取處理”的結(jié)果。

4 用例建模的優(yōu)點

1） 用例建模完全是從外部站在用戶的角度上來描述系統(tǒng)功能的，把用戶需求和設(shè)計完全分離開來。用例模型主要描述系統(tǒng)的功能性需求。系統(tǒng)的設(shè)計由對象模型來描述。2） 用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)而不是分離的功能。3） 用例方法比傳統(tǒng)的方法更易于被用戶理解，用例方法是用戶和開發(fā)人員有效地溝通手段。

5 結(jié)束語

用例建模向人們展示用戶如何使用系統(tǒng)以及系統(tǒng)的工作流程。通過用例建模來觀察系統(tǒng)，有助于了解系統(tǒng)中最重要的部分，避免不必要的細(xì)節(jié)，來滿足用戶的需求和期望。用例建模技術(shù)以面向?qū)ο笏枷霝橹笇?dǎo)，注重參與者和用例一級用力之間的關(guān)系，對用戶需求有著極強(qiáng)的表述能力?？傊?，用例分析技術(shù)很好的解決了傳統(tǒng)面向過程需求分析技術(shù)對用戶需求描述不清、難以處理需求變化的問題。正確使用用例建模這項技術(shù)，會對軟件的設(shè)計、開發(fā)以及后期維護(hù)都帶來巨大的方便。

參考文獻(xiàn)：

[1] 張龍祥.UML與系統(tǒng)分析與設(shè)計[M].北京：人民郵電出版社，2001.

[2] Martin F.UML精粹[M].徐家福，譯.2版.北京：清華大學(xué)出版社，2002.

[3] 吳際，金茂忠.UML面向?qū)ο蠓治鯷M].北京：北京航空航天大學(xué)出版社，2002.endprint

摘要：需求分析和用例建模是軟件需求工程研究的熱點，通過討論二者的作用及相互關(guān)系，得到如何使用用例分析技術(shù)為捕獲的軟件需求建立簡潔明了的邏輯模型的一般方法。首先介紹用例、軟件需求、需求建模等基本概念，然后探討軟件用例建模的一般過程，最后結(jié)合實例給出了使用用例進(jìn)行需求建模的實現(xiàn)方法及采用用例建模的優(yōu)勢所在。

關(guān)鍵詞：用例；需求分析；建模

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）29-6860-03

需求分析是指對要解決的問題進(jìn)行詳細(xì)的分析，弄清問題的要求。包括需要輸入什么數(shù)據(jù)，要得到什么結(jié)果，最后應(yīng)該輸出什么。可以說，在軟件工程當(dāng)中的需求分析就是確定要軟件實現(xiàn)的功能。假如在需求分析時分析者們未能正確地認(rèn)識到顧客的需要的話，那么最后的軟件不可能達(dá)到顧客的需要或者軟件無法在規(guī)定的時間內(nèi)完工。

用例建模是一想日益流行的基于面向?qū)ο笏枷氲男枨蠓治黾夹g(shù)，它用過用例的參與者和用例一級用力之間的關(guān)系來描繪系統(tǒng)外在可見的需求，使用戶和開發(fā)者共同剖析系統(tǒng)功能需求的起點。長期的實踐證明，建立簡介準(zhǔn)確的表示模型是解決問題的關(guān)鍵。標(biāo)準(zhǔn)建模語言UML提供了無淚模型圖，其中用例圖特別適合與需求分析領(lǐng)域。

1 重要概念

1） 用例模型（use case model）：用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型，它可以作為客戶和開發(fā)人員之間的契約。用例是貫穿整個系統(tǒng)開發(fā)的一條主線。同一個用例模型即為需求工作流程的結(jié)果，可當(dāng)作分析設(shè)計工作流程以及測試工作流程的輸入使用。

2） 用例（use case）：用例就是對系統(tǒng)功能的描述，一個用例描述的是整個系統(tǒng)功能的一部分，這一部分一定要是在邏輯上有相對完整的功能流程。在使用UML的開發(fā)過程中，需求是用用例來表達(dá)的，界面是在用例的輔助下設(shè)計的，很多類是根據(jù)用例來發(fā)現(xiàn)的，測試實例是根據(jù)用例來生成的，包括整個開發(fā)的管理和任務(wù)分配，也是依據(jù)用例來組織的。

3） 參與者（Actor）：參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統(tǒng)等等。在處理參與者時，重要的是角色，并不關(guān)心人或人的職務(wù)等屬性，其圖形化表示是一個人。

4） 用例關(guān)系：用例關(guān)系用來表示用例間的關(guān)系。主要包括擴(kuò)展（extend）、包含（include）和泛化（generalization）。為了表述用例之間的關(guān)系，使得系統(tǒng)設(shè)計有一個很好的框架，我們引入上述三種關(guān)系來表達(dá)系統(tǒng)的完整功能。

Extend 擴(kuò)展：

基用例路徑本身是完整的，可能是一條擴(kuò)展路徑。擴(kuò)展路徑步驟多；擴(kuò)展路徑內(nèi)部還有擴(kuò)展點-擴(kuò)展之?dāng)U展；擴(kuò)展路徑未定或容易變化-分離以“凍結(jié)”基用例。

Include 包含：某些步驟在多個用例重復(fù)出現(xiàn)，且單獨形成價值，當(dāng)用例步驟較多時，可用Include簡化。

Generalization 泛化：泛化是同一業(yè)務(wù)目的不同技術(shù)實現(xiàn)，一個用例可以特化另一個更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例間的泛化關(guān)系中，子用例表示父用例的特殊形式，子用例繼承了父用例的行為和屬性，也可以增加新的行為和屬性或覆蓋父用例中的行為。

2 需求分析階段的工作

2.1 需求獲取

1） 刻畫出軟件的功能和性能；2） 指明軟件與其他系統(tǒng)元素的接口；3） 建立軟件必須滿足的約束。

2.2 需求建模

需求分析建立起來的模型為日后軟件設(shè)計人員提供了可被翻譯成數(shù)據(jù)、體系結(jié)構(gòu)、接口和過程設(shè)計的模型。

2.3 需求規(guī)格說明

需求規(guī)格說明為開發(fā)人員和用戶提供軟件開發(fā)完成時質(zhì)量評價的依據(jù)。

2.4 需求評審

1） 需求分析研究的對象是用戶的要求。2） 必須全面理解用戶的各項要求，準(zhǔn)確表達(dá)被接受的用戶要求。3） 只有經(jīng)過確切描述的軟件需求才能成為軟件設(shè)計的基礎(chǔ)。

3 用例建模實例分析

3.2 用例建模

與系統(tǒng)核心功能相關(guān)的主要有兩種用戶：招生人員與信息錄入員。招生人員負(fù)責(zé)協(xié)調(diào)整個招生工作，可以參與到招生工作的各階段中；而信息錄入員則主要負(fù)責(zé)考生信息與考生成績錄入工作。在用例建模中這兩種用戶被定義為行為者。

下面主要細(xì)化已提出的兩個用例：考生錄取處理與專業(yè)考試處理。

1） 專業(yè)考試處理功能可分為：專業(yè)考試基礎(chǔ)信息維護(hù)、考生基本信息處理 、考生專業(yè)成績處理、專業(yè)考試合格證處理、招生計劃信息處理。

2） 考生錄取處理功能可分為：各省文化考試基礎(chǔ)信息維護(hù)、考生文化成績處理、考生志愿信息處理、預(yù)錄取處理、最終錄取處理。

用例建模的過程，除了圖之外，還必須給出必要的解釋。否則，建模是不完整的。圖2，“專業(yè)考試處理”用例包含（include）了“專業(yè)考試基礎(chǔ)信息維護(hù)”等5個子用例。其中信息錄入員因為權(quán)限的關(guān)系，僅參與“考生基本信息處理”和“考生專業(yè)成績處理”兩個用例，而且在這兩個子用例中間也只有錄入信息和核對信息的功能，不能做信息的修改。而招生人員具備所有用例中的處理功能（除錄入員的錄入功能外）。5個子用例之間也有一定的關(guān)聯(lián)，首先，“考生基本信息處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”子用例，這是因為，“考生基本信息處理”中間的部分內(nèi)容（如考生的考試課目），是由該考生的報考的專業(yè)決定的，而專業(yè)的情況，是“專業(yè)考試基礎(chǔ)信息維護(hù)”的功能。類似的，“考生專業(yè)成績處理”子用例依賴于“專業(yè)考試基礎(chǔ)信息維護(hù)”和“考生基本信息處理”子用例，這是因為，要進(jìn)行考生專業(yè)成績的錄入，維護(hù)等工作，必須在考生的基本信息和考生所報考專業(yè)的考試信息都完整的情況下進(jìn)行?！皩I(yè)考試合格證處理”子用例依賴于“招生計劃信息處理”和“考生專業(yè)成績處理”子用例，這是因為發(fā)放專業(yè)考試合格證的前提是考生專業(yè)成績和招生計劃都處理完畢。

圖3，“考生錄取處理”包含（include）了“各省文化考試基礎(chǔ)信息維護(hù)”等5個子用例。信息錄入員參與了“考生文化成績處理”和“考生志愿信息處理”2個子用例，并且僅有錄入信息和核對信息的權(quán)限，不具有修改和維護(hù)的權(quán)限。招生人員具備所有用例的處理功能（除錄入員的錄入功能外）。5個子用例之間也具備一定依賴關(guān)系。“考生文化成績處理”子用例依賴于“各省文化考試基礎(chǔ)信息維護(hù)”子用例，因為要錄入并維護(hù)考生的文化成績，前提是該考生所在省份所考類別的文化課課目的信息是完整準(zhǔn)確的?！邦A(yù)錄取處理”子用例依賴于“考生志愿信息處理”和“考生文化成績處理”兩個子用例，因為考生志愿、文化成績、專業(yè)成績、招生計劃（后兩者需要依賴“專業(yè)課考試處理”用例，圖3.3無法表示，可從圖3.1中看到）決定了預(yù)錄取的結(jié)果。“最終錄取處理”是一個審批和微調(diào)的過程，需要依賴于“預(yù)錄取處理”的結(jié)果。

4 用例建模的優(yōu)點

1） 用例建模完全是從外部站在用戶的角度上來描述系統(tǒng)功能的，把用戶需求和設(shè)計完全分離開來。用例模型主要描述系統(tǒng)的功能性需求。系統(tǒng)的設(shè)計由對象模型來描述。2） 用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)而不是分離的功能。3） 用例方法比傳統(tǒng)的方法更易于被用戶理解，用例方法是用戶和開發(fā)人員有效地溝通手段。

5 結(jié)束語

用例建模向人們展示用戶如何使用系統(tǒng)以及系統(tǒng)的工作流程。通過用例建模來觀察系統(tǒng)，有助于了解系統(tǒng)中最重要的部分，避免不必要的細(xì)節(jié)，來滿足用戶的需求和期望。用例建模技術(shù)以面向?qū)ο笏枷霝橹笇?dǎo)，注重參與者和用例一級用力之間的關(guān)系，對用戶需求有著極強(qiáng)的表述能力?？傊?，用例分析技術(shù)很好的解決了傳統(tǒng)面向過程需求分析技術(shù)對用戶需求描述不清、難以處理需求變化的問題。正確使用用例建模這項技術(shù)，會對軟件的設(shè)計、開發(fā)以及后期維護(hù)都帶來巨大的方便。

參考文獻(xiàn)：

[1] 張龍祥.UML與系統(tǒng)分析與設(shè)計[M].北京：人民郵電出版社，2001.

[2] Martin F.UML精粹[M].徐家福，譯.2版.北京：清華大學(xué)出版社，2002.

[3] 吳際，金茂忠.UML面向?qū)ο蠓治鯷M].北京：北京航空航天大學(xué)出版社，2002.endprint