uml業(yè)務(wù)建模實(shí)例分析

1、UML業(yè)務(wù)建模實(shí)例分析在我國(guó)十年前ATM（自動(dòng)取款機(jī)）還是一個(gè)很新鮮的事物，現(xiàn)在在城市的大街小巷隨處可見(jiàn)。我們?cè)谌粘Ｉ钪幸步?jīng)常和ATM打交道。本章我們將以簡(jiǎn)化的ATM系統(tǒng)為例將前面幾章中學(xué)到的用例圖、類圖、順序圖、狀態(tài)圖、活動(dòng)圖及協(xié)作圖知識(shí)運(yùn)用到此例中。5.1用例圖參與者"銀行儲(chǔ)戶"和ATM機(jī)。簡(jiǎn)化后的ATM機(jī)僅有取款、存款及其余功能。其余功能不做詳細(xì)說(shuō)明。圖5.1 自動(dòng)取款機(jī)（ATM）系統(tǒng)用例圖 銀行儲(chǔ)戶在ATM機(jī)上完成取款、存款及其他業(yè)務(wù)。5.2類圖圖5.2所示的銀行系統(tǒng)類圖和圖3.5是類似的，只是將工作人員換成了ATM。整個(gè)銀行系統(tǒng)包括了帳戶庫(kù)、銀行儲(chǔ)戶庫(kù)及ATM系

2、統(tǒng)。許多單個(gè)的帳戶組成了帳戶庫(kù)。帳戶具有帳戶類型、帳戶號(hào)、余額三個(gè)屬性，均為private，其類型分別為char，int，double。六個(gè)操作分別為setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance為protected其余均為public。 setType設(shè)置帳戶類型，返回類型為void，參數(shù)類型為char，輸入帳戶類型。 getType獲取帳戶類型，返回類型為char，無(wú)參數(shù)。 setAccountNumbe設(shè)置帳戶號(hào)，返回類型為void，參數(shù)類型為int，輸

3、入帳戶號(hào)。 getAccountNumbe獲取帳戶號(hào)，返回類型為int，無(wú)參數(shù)。 caculateBalance計(jì)算余額，返回類型為void，參數(shù)為double，第一個(gè)參數(shù)為輸入存取款數(shù)額，第二個(gè)參數(shù)為存款余額，既為輸入也為輸出。 getBalance獲取帳戶余額，返回類型為double，無(wú)參數(shù)。許多銀行儲(chǔ)戶組成了儲(chǔ)戶庫(kù)。ATM系統(tǒng)包含了許多ATM機(jī)。銀行儲(chǔ)戶及ATM機(jī)兩個(gè)類包含哪些屬性，哪些操作，它們的可見(jiàn)性及操作的返回類型、參數(shù)個(gè)數(shù)、參數(shù)類型從類圖上都一目了然。更多的屬性及操作都可以一一加上，使這個(gè)類圖更詳細(xì)更完整，從而使參與項(xiàng)目的每個(gè)成員都能無(wú)歧義的明了整個(gè)設(shè)計(jì)的類的結(jié)構(gòu)。同樣對(duì)于一個(gè)真

4、正的銀行系統(tǒng)，這個(gè)類圖過(guò)于簡(jiǎn)單。比如帳戶類型我們可以先定義一個(gè)abstract class，它包含一個(gè)帳戶最基本的屬性及操作。而有些操作先定義為abstract，如余額的計(jì)算。然后再繼承這個(gè)abstract class，我們可以有saving account 和checking account等等。不同的帳戶有不同的余額計(jì)算方法，我們可以加上具體的算法。對(duì)于不同的帳戶可能還有一些它特有的操作，我們也可以加上，比如saving account在存款達(dá)到多少時(shí)可以享受機(jī)票打折的優(yōu)惠。通過(guò)類圖不僅可以使設(shè)計(jì)者明確的表達(dá)自己的設(shè)計(jì)意圖，也能幫組自己整理思路，充實(shí)及優(yōu)化自己的設(shè)計(jì)。 圖5.2 銀行系統(tǒng)類

5、圖5.3順序圖圖5.3描述了顧客在ATM機(jī)上取款時(shí)信息的流動(dòng)情況。以時(shí)間為順序。因?yàn)閮H是示例，所以整個(gè)過(guò)程是沒(méi)有出現(xiàn)任何故障時(shí)的流程，并且只畫(huà)到了取款結(jié)束。通過(guò)這個(gè)圖，我們可以看出消息是如何在系統(tǒng)中不同對(duì)象之間進(jìn)行交互。通過(guò)流程圖我們可以很清楚地看到系統(tǒng)是如何工作的，系統(tǒng)各部分之間的信息及控制是如何發(fā)送的，整個(gè)流程是否合理。流程圖對(duì)我們的設(shè)計(jì)起到了很好的幫助作用。注意在本圖沒(méi)有一個(gè)生命線終端有一個(gè)"X"，這是因?yàn)檫@個(gè)流程中還未遇到有對(duì)象生命結(jié)束。當(dāng)有對(duì)象生命結(jié)束時(shí)需在對(duì)應(yīng)的生命線終端畫(huà)"X"，表明這個(gè)對(duì)象在這時(shí)被銷毀。首先銀行儲(chǔ)戶將ATM卡插入讀卡機(jī)，讀

6、卡機(jī)將信息傳給客戶管理，客戶管理提出查詢密碼，顯示部分將輸入密碼請(qǐng)求顯示出來(lái).因?yàn)檫@個(gè)順序圖較長(zhǎng)，且很清晰，即便是初學(xué)者也很容易讀懂，在此就不對(duì)本圖做過(guò)多的解釋。圖5.3 ATM取款順序圖圖5.4描述了顧客在ATM機(jī)上進(jìn)行操作會(huì)經(jīng)歷的幾種狀態(tài)，及各種狀態(tài)之間轉(zhuǎn)換的條件。因?yàn)槭呛?jiǎn)化了的例子，所以除了等待顧客插入磁卡的起始狀態(tài)和結(jié)束服務(wù)的終止?fàn)顟B(tài)，顧客會(huì)處于輸入密碼、選擇服務(wù)類型、存款及取款四種狀態(tài)。 插入磁卡后進(jìn)入輸密碼狀態(tài)，當(dāng)密碼輸入正確時(shí)進(jìn)入選擇服務(wù)類型狀態(tài)，當(dāng)輸入密碼不正確時(shí)，停留在原狀態(tài)，但如果三次不正確，服務(wù)結(jié)束。進(jìn)入選擇服務(wù)類型后根據(jù)選擇的不同，顧客可進(jìn)入存款和取款狀態(tài)。存、取款結(jié)束

7、后，顧客既可以選擇結(jié)束服務(wù)到最終狀態(tài)，也可以選擇繼續(xù)服務(wù)回到選擇服務(wù)類型狀態(tài)。通過(guò)狀態(tài)圖我們可以無(wú)歧義的了解各個(gè)活動(dòng)角色是如何在不同狀況下轉(zhuǎn)換的，轉(zhuǎn)換的條件是什么，是否會(huì)出現(xiàn)死鎖現(xiàn)象，是否有條件沒(méi)考慮周全，是否有狀態(tài)無(wú)法達(dá)到。狀態(tài)圖可以幫助我們發(fā)現(xiàn)問(wèn)題，并及時(shí)改正。 5.5活動(dòng)圖圖5.5參考了Randy Miller的A Hands-On Introduction for Developers一文，5.3圖中的客戶管理和事物管理對(duì)應(yīng)于5.5圖中的Bank，圖5.3中的讀卡機(jī)、顯示、輸入設(shè)備及點(diǎn)鈔機(jī)對(duì)應(yīng)于5.5圖中的ATM Machina，銀行儲(chǔ)戶就是Customer。初看活動(dòng)圖和順序圖表達(dá)的意

8、義很接近。但我們可以注意到順序圖著重時(shí)間的順序，而活動(dòng)圖側(cè)重于各部分之間的相互制約，對(duì)于一些并行的活動(dòng)能夠有效的表示出來(lái)。例如5.5圖中fork和join處，我們可以很清楚的看到一些并行活動(dòng)的存在。這個(gè)活動(dòng)圖以顧客插入卡為開(kāi)始，以顧客取卡結(jié)束。我們可以看到活動(dòng)圖的重點(diǎn)雖然不在時(shí)間順序，但我們同樣可以得到時(shí)間的信息。 圖5.5 ATM銀行系統(tǒng)活動(dòng)圖5.6協(xié)作圖在第四章中我們知道協(xié)作圖和順序圖是可以無(wú)信息損失的相互轉(zhuǎn)換，只是它們的側(cè)重點(diǎn)是不一樣的。順序圖著重于對(duì)象間消息傳遞的時(shí)間順序，協(xié)作圖著重于表達(dá)對(duì)象之間的靜態(tài)連接關(guān)系。圖5.6將5.3圖轉(zhuǎn)換為協(xié)作圖。1. 插入ATM卡2. 接受ATM卡3.

9、查詢密碼4. 顯示輸入密碼請(qǐng)求5. 輸入密碼6. 密碼傳遞7. 請(qǐng)求確認(rèn)密碼合法性8. 確認(rèn)密碼合法性9. 詢問(wèn)服務(wù)類別10. 顯示輸入服務(wù)服務(wù)類別請(qǐng)求11. 輸入取款請(qǐng)求12. 取款請(qǐng)求 13. 詢問(wèn)取款數(shù)額14. 顯示輸入數(shù)額請(qǐng)求15. 輸入取款數(shù)額16. 傳遞取款數(shù)額17. 詢問(wèn)取款數(shù)額確認(rèn)18. 顯示確認(rèn)數(shù)額請(qǐng)求19. 輸入確認(rèn)20. 傳遞確認(rèn)信息21. 數(shù)額合法性確認(rèn)請(qǐng)求22. 確認(rèn)數(shù)額和法性23. 出鈔請(qǐng)求24. 計(jì)算帳戶余額25. 出鈔26. 取鈔27. 傳遞余額并詢問(wèn)是否還需要其他服務(wù)28. 顯示帳戶余額并提示選擇下面的服務(wù) 從圖上我們可以看出協(xié)作圖的角色和順序圖的對(duì)象是一一對(duì)

10、應(yīng)的，而協(xié)作圖上的各對(duì)象上的協(xié)作關(guān)系和順序圖上的消息傳遞是一一對(duì)應(yīng)的。 例解基于UML的面向?qū)ο蠓治雠c設(shè)計(jì) 摘要      本文以實(shí)例的方式，展示了如何使用UML進(jìn)行面向?qū)ο蟮姆治雠c設(shè)計(jì)。本文將假設(shè)讀者對(duì)UML、面向?qū)ο蟮阮I(lǐng)域的基本內(nèi)容已了然于胸，所以將不會(huì)過(guò)多闡述，而將重點(diǎn)放在應(yīng)用過(guò)程上。本文的目的是通過(guò)一個(gè)完整的實(shí)例，展現(xiàn)基于UML的OOA&D過(guò)程的一個(gè)簡(jiǎn)化模式，幫助朋友們更好的認(rèn)識(shí)UML在OOA&D中起的作用。前言      經(jīng)常聽(tīng)到有朋友抱怨，說(shuō)學(xué)了UML不知該怎么用，或

11、者畫(huà)了UML卻覺(jué)得沒(méi)什么作用。其實(shí)，就UML本身來(lái)說(shuō)，它只是一種交流工具，它作為一種標(biāo)準(zhǔn)化交流符號(hào)，在OOA&D過(guò)程中開(kāi)發(fā)人員間甚至開(kāi)發(fā)人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現(xiàn)形式，可以說(shuō)“OO是神，而UML是型”。所以，想用好UML，扎實(shí)的OO思想基礎(chǔ)是必不可少的。然而，在UML應(yīng)用到開(kāi)發(fā)過(guò)程中時(shí)，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個(gè)啟發(fā)式過(guò)程，而不是說(shuō)一定要遵循這個(gè)流程。）下面，我們通過(guò)一個(gè)CMS系統(tǒng)的分析設(shè)計(jì)實(shí)例，看看如何將UML應(yīng)用到實(shí)際的開(kāi)發(fā)中。1.從需求到業(yè)務(wù)用例圖   

12、60;  OOA&D的第一步，就是了解用戶需求，并將其轉(zhuǎn)換為業(yè)務(wù)用例圖。我們的CMS系統(tǒng)需求非常簡(jiǎn)單，大致課做如下描述：這個(gè)系統(tǒng)主要用來(lái)發(fā)布新聞，管理員只需要一個(gè)，登錄后可以在后臺(tái)發(fā)布新聞。任何人可以瀏覽新聞，瀏覽者可以注冊(cè)成為系統(tǒng)會(huì)員，注冊(cè)后可對(duì)新聞進(jìn)行評(píng)論。管理員在后臺(tái)可以對(duì)新聞、評(píng)論、注冊(cè)會(huì)員進(jìn)行管理，如修改、刪除等。      通過(guò)以上需求描述，我們畫(huà)出如下的業(yè)務(wù)用例圖：      這里要注意三點(diǎn)：      1.業(yè)務(wù)用

13、例是僅從系統(tǒng)業(yè)務(wù)角度關(guān)注的用例，而不是具體系統(tǒng)的用例。它描述的是“該實(shí)現(xiàn)什么業(yè)務(wù)”，而不是“系統(tǒng)該提供什么操作”。例如，在實(shí)際系統(tǒng)中，“登錄”肯定要作為一個(gè)用例，但是這是軟件系統(tǒng)中的操作，而用戶所關(guān)注的業(yè)務(wù)是不包含“登錄”的。      2.業(yè)務(wù)用例僅包含客戶“感興趣”的內(nèi)容。      3.業(yè)務(wù)用例所有的用例名應(yīng)該讓客戶能看懂，如果某個(gè)用例的名字客戶看不懂什么意思，它也許就不適合作為業(yè)務(wù)用例。2.從業(yè)務(wù)用例圖到活動(dòng)圖      完成了業(yè)務(wù)用例圖

14、后，我們要為每一個(gè)業(yè)務(wù)用例繪制一幅活動(dòng)圖?；顒?dòng)圖描述了這個(gè)業(yè)務(wù)用例中，用戶可能會(huì)進(jìn)行的操作序列?；顒?dòng)圖有個(gè)很重要的使命：從業(yè)務(wù)用例分析出系統(tǒng)用例。例如，下面是“新聞管理”的活動(dòng)圖：      可以看到，一個(gè)“新聞管理”這個(gè)業(yè)務(wù)用例，分解出N多系統(tǒng)操作。這里要特別注意這些操作，其中很多“活動(dòng)”都很可能是一個(gè)系統(tǒng)用例（當(dāng)然，不是每個(gè)都是）。例如，由這個(gè)活動(dòng)圖可以看出，系統(tǒng)中至少要包含以下備選系統(tǒng)用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。      這樣，將每個(gè)業(yè)務(wù)用例都繪制出相應(yīng)的活動(dòng)

15、圖，再將其中的“活動(dòng)”整合，就得出所有備選系統(tǒng)用例。3.從活動(dòng)圖到系統(tǒng)用例圖      找出所有的備選系統(tǒng)用例后，我們要對(duì)他們進(jìn)行合并和篩選。合并就是將相同的用例合并成一個(gè)，篩選就是將不符合系統(tǒng)用例條件的備選用例去掉。      一個(gè)系統(tǒng)用例應(yīng)該是實(shí)際使用系統(tǒng)的用戶所進(jìn)行的一個(gè)操作，例如，“查看新聞列表”就不能算一個(gè)系統(tǒng)用例，因?yàn)樗皇悄诚到y(tǒng)用例的一個(gè)序列項(xiàng)。      最終我們得出的系統(tǒng)用例圖如下：4.從系統(tǒng)用例圖到用例規(guī)約 

16、0;    得出系統(tǒng)用例圖后，我們應(yīng)該對(duì)每一個(gè)系統(tǒng)用例給出用例規(guī)約。關(guān)于用例規(guī)約，沒(méi)有一個(gè)通用的格式，大家可以按照習(xí)慣的格式進(jìn)行編寫(xiě)。對(duì)用例規(guī)約唯一的要求就是“清晰易懂”。      下面給出“登錄”這個(gè)系統(tǒng)用例的一個(gè)規(guī)約：5.繪制業(yè)務(wù)領(lǐng)域類圖      完成了上面幾步，下面應(yīng)該是繪制業(yè)務(wù)領(lǐng)域類圖了。所謂業(yè)務(wù)領(lǐng)域類圖要描述一下三點(diǎn)：      1.系統(tǒng)中有哪些實(shí)體。    &#

17、160; 2.這些實(shí)體能做什么操作。      3.實(shí)體間的關(guān)系。      這里要特別強(qiáng)調(diào)：這里的實(shí)體不是Actor，而是Actor使用系統(tǒng)時(shí)使用的所調(diào)用的實(shí)體，是處在系統(tǒng)邊界之內(nèi)的實(shí)體。例如，管理員就沒(méi)有作為一個(gè)實(shí)體出現(xiàn)在這里，因?yàn)楣芾韱T處在系統(tǒng)邊界之外，它所有的工作都可以通過(guò)調(diào)用這三個(gè)類的方法完成。并且，這里的“注冊(cè)會(huì)員”實(shí)體也不是剛才用例圖中注冊(cè)會(huì)員這個(gè)Actor，而是作為一個(gè)系統(tǒng)內(nèi)的業(yè)務(wù)實(shí)體，供Actor們使用的。例如，其中的注冊(cè)功能是給注冊(cè)會(huì)員這個(gè)Actor使用，而移除則是給管理員這

18、個(gè)Actor使用的。      理解以上這段話非常重要，我經(jīng)?？吹接捎诨煜藢?shí)體和Actor的關(guān)系而導(dǎo)致畫(huà)出的領(lǐng)域類圖不準(zhǔn)確或職責(zé)分配不準(zhǔn)確。      大家可能還注意到，我們這里沒(méi)有給出每個(gè)實(shí)體的屬性。其實(shí)，在領(lǐng)域分析階段，實(shí)體的屬性并不重要，重要的是找出實(shí)體的操作。  6.繪制實(shí)現(xiàn)類圖      以上這幾步，就是分析的過(guò)程。而下面的步驟就是設(shè)計(jì)了。      設(shè)計(jì)沒(méi)有分析那

19、么好描述，因?yàn)榉治鍪恰翱蛻裘妗?，它只關(guān)心系統(tǒng)本身的功能和業(yè)務(wù)，而不關(guān)心任何和計(jì)算機(jī)有關(guān)的東西。但是，設(shè)計(jì)和平臺(tái)、語(yǔ)言、開(kāi)發(fā)模型等內(nèi)容關(guān)系緊密，因而很難找出一個(gè)一致的過(guò)程。但是，一般在設(shè)計(jì)過(guò)程中實(shí)現(xiàn)類圖是要繪制的。      實(shí)現(xiàn)類圖和領(lǐng)域類圖不一樣，它描述的是真正系統(tǒng)的靜態(tài)結(jié)構(gòu)，是和最后的代碼完全一致的。因此，它和平臺(tái)關(guān)系密切，必須準(zhǔn)確給出系統(tǒng)中的實(shí)體類、控制類、界面類、接口等元素以及其中的關(guān)系。因此，實(shí)現(xiàn)類圖是很復(fù)雜的，而且是平臺(tái)技術(shù)有關(guān)的。所以，我在這里不可能給出一個(gè)準(zhǔn)確的實(shí)現(xiàn)類圖，不過(guò)為了描述，我還是給出一個(gè)簡(jiǎn)化了的實(shí)現(xiàn)類圖，當(dāng)然，它是不

20、準(zhǔn)確的，而只是從形式上給出實(shí)現(xiàn)類圖的樣子。      我們假設(shè)這個(gè)系統(tǒng)建構(gòu)于.NET 3.5平臺(tái)上，并且使用ASP.NET MVC作為表示層，整體使用三層架構(gòu)。那么，用戶模塊體系的實(shí)現(xiàn)類圖大體是這樣子（不準(zhǔn)確）：7.繪制序列圖      有了靜態(tài)結(jié)構(gòu)，我們還要給出動(dòng)態(tài)結(jié)構(gòu)，這樣，才能看清系統(tǒng)間的類是如何交互的，從而有效幫助程序員進(jìn)行編碼工作。      上圖給出的是用戶登錄的序列圖。首先注冊(cè)會(huì)員作為Actor，調(diào)用UserController的L

21、ogin方法啟動(dòng)序列，然后序列按圖示步驟執(zhí)行。其中UserServices作為業(yè)務(wù)組件，首先調(diào)用數(shù)據(jù)訪問(wèn)組件的GetByName確定用戶是否存在，如果存在，再調(diào)用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業(yè)務(wù)功能。      要注意，序列圖在實(shí)際中是很多的，幾乎每個(gè)類方法都配有相應(yīng)的序列圖。8.后面的步驟      在完成了上面的過(guò)程后，就可以進(jìn)行編碼、調(diào)試、測(cè)試等工作了。但這些已經(jīng)超出了本文討論的范圍。總結(jié)    &

22、#160; 本文簡(jiǎn)要給出了使用UML進(jìn)行OOA&D的過(guò)程。當(dāng)然，由于示例較小，而且本人水平有限，所以給出的相關(guān)內(nèi)容可能不是很準(zhǔn)確。而且軟件分析設(shè)計(jì)本來(lái)就不是一個(gè)固定模式的過(guò)程，隨著系統(tǒng)的不同整個(gè)過(guò)程會(huì)有變化。本文只是想起到一個(gè)拋磚引玉的作用，讓朋友們大致了解UML的使用流程。至于實(shí)際的分析設(shè)計(jì)，還需要深入的學(xué)習(xí)和實(shí)踐的積累。UML業(yè)務(wù)建模實(shí)例分析 作者: 范里程 出處:軟件世界 對(duì)于大中型信息系統(tǒng)，很難直接進(jìn)行需求分析設(shè)計(jì)，需要借助模型來(lái)分析設(shè)計(jì)系統(tǒng)，根據(jù)系統(tǒng)調(diào)研數(shù)據(jù)，建立起目標(biāo)系統(tǒng)的邏輯模型。 在軟件工程的歷史中，很長(zhǎng)時(shí)間里人們一直認(rèn)為需求分析是整個(gè)軟件工程中最簡(jiǎn)

23、單的一個(gè)步驟，但在過(guò)去十年中越來(lái)越多的人認(rèn)識(shí)到它是整個(gè)過(guò)程中最為關(guān)鍵的一個(gè)過(guò)程。假如在需求分析時(shí)分析者們未能正確地認(rèn)識(shí)到客戶的需求的話，那么最后的軟件實(shí)際上不可能達(dá)到客戶的要求，或者導(dǎo)致需求的頻繁變更，而軟件無(wú)法在規(guī)定的時(shí)間里完工。 在需求分析階段，要對(duì)經(jīng)過(guò)可行性分析所確定的系統(tǒng)目標(biāo)和功能作進(jìn)一步的詳細(xì)論述，確定系統(tǒng)“做什么？”的問(wèn)題，最終建立起目標(biāo)系統(tǒng)的邏輯模型。 首先是獲得當(dāng)前系統(tǒng)的物理模型。物理模型是對(duì)當(dāng)前系統(tǒng)的真實(shí)寫(xiě)照，可能是一個(gè)由人工操作的過(guò)程，也可能是一個(gè)已有的但需要改進(jìn)的計(jì)算機(jī)系統(tǒng)。首先是要對(duì)現(xiàn)行系統(tǒng)進(jìn)行分析、理解，了解它的組織情況、數(shù)據(jù)流向、輸入輸出，資源利用情況等，在分析的基

24、礎(chǔ)上畫(huà)出它的物理模型。然后抽象出當(dāng)前系統(tǒng)的邏輯模型。 邏輯模型是在物理模型基礎(chǔ)上，去掉一些次要的因素，建立起反映系統(tǒng)本質(zhì)的邏輯模型。接下來(lái)建立目標(biāo)系統(tǒng)的邏輯模型。通過(guò)分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)在邏輯上的區(qū)別，建立符合用戶需求的目標(biāo)系統(tǒng)的邏輯模型。最后補(bǔ)充目標(biāo)系統(tǒng)的邏輯模型。對(duì)目標(biāo)系統(tǒng)進(jìn)行補(bǔ)充完善 ,將一些次要的因素補(bǔ)充進(jìn)去，例如出錯(cuò)處理等。 UML（The Unified Modeling Language，即統(tǒng)一建模語(yǔ)言）是一種編制系統(tǒng)藍(lán)圖的標(biāo)準(zhǔn)化語(yǔ)言，可以對(duì)復(fù)雜的系統(tǒng)建立可視化的系統(tǒng)模型，目前已經(jīng)被工業(yè)標(biāo)準(zhǔn)化組織OMG（Object Management Group）接受，一經(jīng)推出便得到許多著

25、名的計(jì)算機(jī)廠商如Microsoft、HP、IBM、Oracle等的支持，也在逐步開(kāi)始應(yīng)用到需求分析過(guò)程中。 在使用UML建立當(dāng)前系統(tǒng)邏輯模型過(guò)程中，初學(xué)者通常會(huì)遇到一些問(wèn)題： 1.什么時(shí)候真正需要業(yè)務(wù)模型？什么時(shí)候用例模型獨(dú)立存在？ 2.在進(jìn)行精確的業(yè)務(wù)建模時(shí)能用哪些UML圖形？如何知道是否用順序圖或者交互圖？ 3.業(yè)務(wù)模型如何涉及到其他模型（如領(lǐng)域模型，用例模型等等）呢？如何有機(jī)地組織這些模型？ 本文將通過(guò)圖書(shū)館管理系統(tǒng)這個(gè)簡(jiǎn)單而典型的實(shí)例來(lái)進(jìn)行一次UML需求分析實(shí)踐之旅。 許多讀者對(duì)圖書(shū)館圖書(shū)管理工作比較熟悉，主要是圍繞讀者、圖書(shū)和工作人員的借還書(shū)展開(kāi)工作。我們先看看圖書(shū)館工作人員和部分讀

26、者的需求。 讀者來(lái)圖書(shū)館借書(shū)，可能先查詢書(shū)庫(kù)的圖書(shū)記錄。查詢可以按書(shū)名、作者、圖書(shū)編號(hào)、關(guān)鍵字查詢。查詢有兩種結(jié)果，如果查到則記下書(shū)號(hào)，交給工作人員，然后等候辦理借書(shū)手續(xù)。如果該書(shū)已經(jīng)被全部借出，則可做借書(shū)登記，等待有書(shū)時(shí)被通知。如果圖書(shū)館沒(méi)有該書(shū)的記錄，則做缺書(shū)登記。 辦理借書(shū)手續(xù)時(shí)先要出示圖書(shū)證，沒(méi)有圖書(shū)證則去申請(qǐng)圖書(shū)證。如果借書(shū)數(shù)量超出規(guī)定，則提示“借書(shū)數(shù)量超限，不能繼續(xù)借閱”。工作人員登記借閱人信息、借閱的圖書(shū)信息、借出時(shí)間和應(yīng)還書(shū)時(shí)間。系統(tǒng)自動(dòng)修改書(shū)庫(kù)的圖書(shū)記錄、讀者庫(kù)信息。 當(dāng)一位讀者還書(shū)時(shí)，工作人員根據(jù)圖書(shū)證編號(hào)，找到讀者的借書(shū)信息，查看是否超期，如果已經(jīng)超期，則進(jìn)行超期處罰。

27、如果圖書(shū)有破損、丟失，則進(jìn)行破損處罰。清除借閱記錄，同時(shí)系統(tǒng)自動(dòng)查看是否有等待借閱登記，如果有則發(fā)出通知，修改書(shū)庫(kù)記錄，該書(shū)設(shè)置為已預(yù)訂狀態(tài)，否則設(shè)置為可借狀態(tài)。 圖書(shū)采購(gòu)人員進(jìn)行圖書(shū)采購(gòu)時(shí)，要參考各類圖書(shū)的庫(kù)存數(shù)和借閱率，注意合理采購(gòu)。如果有缺書(shū)登記則隨時(shí)進(jìn)行采購(gòu)。正在采購(gòu)的圖書(shū)組成一個(gè)采購(gòu)中書(shū)庫(kù)。 采購(gòu)到貨后，進(jìn)行驗(yàn)收，編號(hào)，同時(shí)加入圖書(shū)庫(kù)，修改采購(gòu)中書(shū)庫(kù)，并且查看訂閱庫(kù)，發(fā)出到書(shū)通知，并且已經(jīng)修改書(shū)庫(kù)的圖書(shū)記錄為已預(yù)訂狀態(tài)。 借書(shū)登記是當(dāng)欲借的書(shū)被借空后，讀者自愿選擇的一種操作，它應(yīng)該記錄讀者名和聯(lián)系方式，一旦有這本書(shū)后可通知讀者。 到書(shū)通知，當(dāng)讀者預(yù)訂的書(shū)來(lái)到之后，按照讀者給出的聯(lián)系方

28、式發(fā)出通知。 缺書(shū)登記是當(dāng)讀者需要的書(shū)庫(kù)內(nèi)查詢沒(méi)有記錄時(shí)，將此信息轉(zhuǎn)入缺貨庫(kù)，通知采購(gòu)員采購(gòu)。 圖書(shū)注銷，如果圖書(shū)丟失或舊書(shū)淘汰，則將該書(shū)從書(shū)庫(kù)中清除。 根據(jù)需求描述整理一張需求表： 需求分析時(shí)首先要識(shí)別出系統(tǒng)的參與者，在簡(jiǎn)單的圖書(shū)館管理系統(tǒng)中，可以劃分出兩種參與者：讀者和管理員。當(dāng)然，根據(jù)業(yè)務(wù)的復(fù)雜程度，參與者也可以進(jìn)行細(xì)分，比如讀者可以再分為學(xué)生讀者、教師讀者、校外讀者，管理員根據(jù)業(yè)務(wù)和權(quán)限的不同可以再細(xì)分為庫(kù)房管理員、借還書(shū)操作員、系統(tǒng)維護(hù)人員、圖書(shū)館管理人員等不同角色。在這里，為了簡(jiǎn)化處理，我們只列出了讀者和管理員。對(duì)參與者描述如下： （1）讀者 描述：讀者可以借閱、預(yù)定、歸還物理書(shū)刊

29、，可以對(duì)書(shū)籍和個(gè)人信息進(jìn)行查詢，可以取消預(yù)定，可以提出辦卡申請(qǐng)。 示例：持有借閱卡的任何人和組織。（2）管理員 描述：圖書(shū)管理員對(duì)系統(tǒng)進(jìn)行維護(hù)，包括讀者信息的創(chuàng)建、修改、刪除，書(shū)刊信息的維護(hù)，條目信息的維護(hù)，還有系統(tǒng)信息的維護(hù)。 示例：圖書(shū)管理員。 通過(guò)識(shí)別的參與者，對(duì)需求進(jìn)一步分析，將業(yè)務(wù)需求進(jìn)行分解，獲得每個(gè)參與者的使用用例。在本例中，我們可以得到以下用例： 1.書(shū)籍借出：提供借閱物理書(shū)刊的功能。 2.書(shū)籍歸還：提供歸還物理書(shū)刊的功能。 3.讀者辦卡：提供為讀者辦理借閱卡的功能。 4.預(yù)定書(shū)刊：提供對(duì)某一個(gè)種類的書(shū)刊的預(yù)約功能。 5.取消預(yù)定：提供對(duì)預(yù)定進(jìn)行取消的功能。 6.書(shū)籍查詢：為讀

30、者提供網(wǎng)上的書(shū)籍查詢功能。 7.信息查詢：為讀者提供信息查詢的功能。 8.讀者信息維護(hù)：提供讀者信息的錄入、修改、查詢、刪除的功能。 9.書(shū)刊信息維護(hù)：提供物理書(shū)刊的錄入、修改、查詢、刪除的功能。 10.條目信息維護(hù)：提供書(shū)刊條目的錄入、修改、查詢、刪除的功能。 11.系統(tǒng)信息維護(hù)：提供對(duì)系統(tǒng)的參數(shù)的設(shè)置。 12.登錄：管理員需要先登錄才能進(jìn)入系統(tǒng)。 并且，可以畫(huà)出如下系統(tǒng)用例圖： 通過(guò)用例圖，可以對(duì)系統(tǒng)功能有一個(gè)大概的了解，對(duì)于復(fù)雜系統(tǒng)，我們可以結(jié)合IDEF方法，通過(guò)分層分解，逐步細(xì)化的方法來(lái)描述系統(tǒng)的功能。對(duì)于用例圖，建議不要畫(huà)的過(guò)于復(fù)雜，特別是用例之間的關(guān)系，因?yàn)閺?fù)雜的用例圖不僅不能讓需

31、求分析人員與客戶之間更好的溝通，反而是制造了一種溝通障礙。 下一步就是編制每一個(gè)用例的詳細(xì)說(shuō)明，對(duì)用例說(shuō)明的主要信息包括有：用例名稱、編號(hào)、用例的簡(jiǎn)短描述、用例的參與者、與其他用例的管理、用例啟動(dòng)的前提條件、用例結(jié)束后的事后條件、用例的輸入、輸出、用例的執(zhí)行事件流等。在實(shí)際項(xiàng)目中，我們并不一定要面面俱到，而是根據(jù)實(shí)際情況對(duì)用例描述進(jìn)行裁減。其中有幾點(diǎn)重要信息是不能裁減的：用例名稱、描述、輸入、輸出、執(zhí)行事件流、參與者。另外，如果實(shí)際情況需要，還可以使用MS Visio等工具畫(huà)出界面的示意圖來(lái)。 如上例所述，我們對(duì)每一個(gè)用例都進(jìn)行詳細(xì)的描述，建立當(dāng)前系統(tǒng)的功能用例模型。需求溝通與分析是一個(gè)迭代的

32、過(guò)程，通過(guò)與用戶的不斷溝通，最終達(dá)成對(duì)目標(biāo)系統(tǒng)的一致理解。如果用戶確認(rèn)了需求分析的成果，一般是需求規(guī)格說(shuō)明書(shū)之后，項(xiàng)目開(kāi)始進(jìn)入系統(tǒng)分析設(shè)計(jì)階段，也就是開(kāi)始構(gòu)造目標(biāo)系統(tǒng)的邏輯模型。 為了讓系統(tǒng)設(shè)計(jì)能夠以結(jié)構(gòu)、組織方式和代碼重用的形式表現(xiàn)出來(lái)，要對(duì)系統(tǒng)進(jìn)行設(shè)計(jì)規(guī)劃，設(shè)計(jì)階段應(yīng)該與分析階段交迭。需求是不斷地發(fā)展，而設(shè)計(jì)本身也會(huì)推動(dòng)需求的發(fā)展(反之亦然) 。在圖書(shū)館管理系統(tǒng)的建模設(shè)計(jì)中，以下3個(gè)方面的問(wèn)題是要關(guān)注的：業(yè)務(wù)對(duì)象的表示、業(yè)務(wù)服務(wù)的實(shí)現(xiàn)、用戶界面的組織。 業(yè)務(wù)對(duì)象的表示 在圖書(shū)館管理系統(tǒng)系統(tǒng)中，業(yè)務(wù)對(duì)象主要是數(shù)據(jù)庫(kù)和數(shù)據(jù)實(shí)體類的表示方式。建模時(shí)，可以構(gòu)造出系統(tǒng)的靜態(tài)模型，也就是系統(tǒng)類圖來(lái)表示

33、。如下圖則描述了借書(shū)這一用例的靜態(tài)結(jié)構(gòu)圖。為了體現(xiàn)類之間的關(guān)系，在下圖中沒(méi)有顯示出每一個(gè)類的屬性和基本操作。 業(yè)務(wù)服務(wù)的實(shí)現(xiàn) 業(yè)務(wù)服務(wù)的實(shí)現(xiàn)需要完成的功能是各種業(yè)務(wù)規(guī)則和邏輯的實(shí)現(xiàn),如借書(shū)處理的業(yè)務(wù)邏輯。每個(gè)模塊的信息錄入、修改、刪除、查詢等。業(yè)務(wù)規(guī)則和邏輯的實(shí)現(xiàn)基本相似，沒(méi)有太多的規(guī)律可循。采用UML來(lái)進(jìn)行業(yè)務(wù)服務(wù)的建模，可以使用UML 的序列圖、狀態(tài)圖、活動(dòng)圖。這個(gè)部分的工作,通常通過(guò)一系列的類之間的交互來(lái)完成。為了在更動(dòng)態(tài)的層面上描述系統(tǒng)，UML 提供了許多其他類型的圖。 對(duì)于B/S系統(tǒng)設(shè)計(jì)而言，情節(jié)圖(Scenario Diagram) 特別有用。情節(jié)圖分成兩種：協(xié)作圖(Collabo

34、ration Diagram) ，序列圖(Sequence Diagram) 。UML 建模工具Rational Rose 能夠從協(xié)作圖生成序列圖也可以從序列圖生成協(xié)作圖。例如，借閱書(shū)刊的業(yè)務(wù)過(guò)程可以采用如下序列圖來(lái)描述： 借閱書(shū)刊過(guò)程主要包括：管理員選擇“借閱書(shū)刊”菜單，彈出對(duì)話框，管理員輸入書(shū)刊信息和用戶信息，系統(tǒng)查找數(shù)據(jù)庫(kù)，是否存在該種物理書(shū)刊，如果不存在，顯示提示信息，用例結(jié)束;是否存在借閱者信息，如果不存在，顯示提示信息，用例結(jié)束;否則，管理員單擊確認(rèn)按鈕后，該圖書(shū)借閱給該借閱者，系統(tǒng)存儲(chǔ)借閱信息到數(shù)據(jù)庫(kù)。 用戶界面的組織 用戶界面布局圖能夠幫助組織系統(tǒng)頁(yè)面、文件、服務(wù)的布局結(jié)構(gòu)。在

35、UML 中，對(duì)于頁(yè)面和文件的組織，可以使用構(gòu)件圖(Component Diagram) 或類圖(Class Diagram) 建模型。本系統(tǒng)中使用類圖對(duì)界面組織建模，頁(yè)面結(jié)構(gòu)以及各種業(yè)務(wù)服務(wù)被捆綁到不同的區(qū)域。 在 UML 中，系統(tǒng)的體系結(jié)構(gòu)使用部署圖(DeploymentDiagram) 來(lái)完成。應(yīng)用部署的規(guī)劃對(duì)于規(guī)劃整個(gè)B/ S 系統(tǒng)是很有用的。它確定了一種有效的應(yīng)用部署的規(guī)劃組織方式,還可以作為一個(gè)模式在多個(gè)類似B/ S 系統(tǒng)上應(yīng)用。 在建模完成后，開(kāi)發(fā)人員利用一些UML Case工具如Rational ROSE生成程序代碼框架，并對(duì)代碼框架進(jìn)行修改和補(bǔ)充，形成完整代碼;而且，還可根據(jù)代

36、碼逆向生成 UML模型。這就較好地保證了模型與代碼的一致性。 測(cè)試必須在整個(gè)項(xiàng)目周期中進(jìn)行，對(duì)每個(gè)階段都要用所建立的模型進(jìn)行測(cè)試，這樣才能保證開(kāi)發(fā)的質(zhì)量，減少開(kāi)發(fā)的風(fēng)險(xiǎn)。 統(tǒng)一建模語(yǔ)言 UML 是國(guó)際軟件工程領(lǐng)域具有劃時(shí)代意義的重要成果，適用于以面向?qū)ο蠹夹g(shù)來(lái)描述任何類型的系統(tǒng)，而且適用于系統(tǒng)開(kāi)發(fā)的不同階段，從需求規(guī)格描述直至系統(tǒng)完成后的測(cè)試和維護(hù)。軟件系統(tǒng)的規(guī)模越來(lái)越大，復(fù)雜度不斷提高，RUP迭代式增量開(kāi)發(fā)方式可以降低風(fēng)險(xiǎn)，同時(shí)可以適應(yīng)需求變化的需要。 在本次UML實(shí)踐之旅中，我們通過(guò)對(duì)圖書(shū)館管理系統(tǒng)的需求進(jìn)行分析，將 UML 應(yīng)用于系統(tǒng)開(kāi)發(fā)的各個(gè)階段，建立了系統(tǒng)的需求模型、靜態(tài)模型和動(dòng)態(tài)模

37、型，同時(shí)遵循Rationl統(tǒng)一過(guò)程(RUP)的核心思想和基本原則，采用以用例為驅(qū)動(dòng)、以體系構(gòu)架為核心的迭代化面向?qū)ο蠓治龊驮O(shè)計(jì)過(guò)程。    圖1：系統(tǒng)用例圖圖2：用況活動(dòng)圖圖3：借書(shū)部分的類結(jié)構(gòu)圖UML行為圖 用況圖（use case diagram）描述了一組用況和參與者（一種特殊的類）以及它們之間的關(guān)系。 交互圖（interaction diagram）是順序圖和協(xié)作圖的統(tǒng)稱。 順序圖(sequence diagram)是強(qiáng)調(diào)消息的時(shí)間次序的交互圖。 協(xié)作圖(collaboration diagram)是強(qiáng)調(diào)收發(fā)消息的對(duì)象的結(jié)構(gòu)組織的交互圖。 狀態(tài)圖顯示了一個(gè)由狀態(tài)，轉(zhuǎn)

38、換，事件和活動(dòng)組成的狀態(tài)機(jī)。 活動(dòng)圖顯示了系統(tǒng)中從活動(dòng)到活動(dòng)的流。  UML實(shí)例：銷售管理系統(tǒng)的UML分析與設(shè)計(jì) 作者：王文豪 | 轉(zhuǎn)貼自：UML軟件工程組織 | 點(diǎn)擊數(shù)：1553 | 更新時(shí)間：2006-8-29 | 文章錄入：admin 摘 要 銷售管理系統(tǒng)是現(xiàn)代企業(yè)管理系統(tǒng)的一個(gè)重要組成部分，傳統(tǒng)的系統(tǒng)分析設(shè)計(jì)方法已經(jīng)難以保證軟件開(kāi)發(fā)的效率和質(zhì)量，通過(guò)將UML應(yīng)用于銷售管理系統(tǒng)建模，可以加速軟件開(kāi)發(fā)進(jìn)程，提高軟件質(zhì)量，支持動(dòng)態(tài)的業(yè)務(wù)需求，并方便地集成已有的企業(yè)管理資源。 關(guān)鍵詞 銷售管理系統(tǒng)；UML

39、；分析；實(shí)現(xiàn)1 引言當(dāng)前社會(huì)對(duì)信息系統(tǒng)的需求日益增長(zhǎng)，需求變化也越來(lái)越快，軟件開(kāi)發(fā)的技術(shù)發(fā)展方向已經(jīng)從“提升被開(kāi)發(fā)系統(tǒng)的執(zhí)行效率”轉(zhuǎn)變?yōu)椤疤嵘_(kāi)發(fā)效率”。面向?qū)ο螅∣O）技術(shù)降低了解決方法域與問(wèn)題域的差別，提供了良好的復(fù)用機(jī)制，能夠更加有效提高軟件開(kāi)發(fā)效率，完全順應(yīng)了軟件開(kāi)發(fā)技術(shù)的發(fā)展方向。 UML(The Unified Modeling Language,即統(tǒng)一建模語(yǔ)言) 是一個(gè)通用的標(biāo)準(zhǔn)建模語(yǔ)言，可以對(duì)復(fù)雜的系統(tǒng)建立可視化系統(tǒng)模型，目前已經(jīng)被工業(yè)標(biāo)準(zhǔn)組織OMG(Object Management Group)接受，一經(jīng)推出便得到許多著名計(jì)算機(jī)廠商如Microsoft,HP,IB

40、M,Oracle等支持，在國(guó)際上應(yīng)用日益廣泛。本文通過(guò)一個(gè)銷售管理系統(tǒng)的分析與設(shè)計(jì)，闡述如何通過(guò)UML降低開(kāi)發(fā)難度和提高開(kāi)發(fā)效率。2 銷售管理系統(tǒng)的基本特征和功能模塊本系統(tǒng)以“訂單”為核心，構(gòu)建出了以“客戶”為中心的管理模式。該系統(tǒng)具有以下一些特征：（1） 先進(jìn)的系統(tǒng)結(jié)構(gòu)，面向銷售流程，能適應(yīng)原有銷售工作流程并進(jìn)行合理的改進(jìn)，從而更貼近實(shí)際的應(yīng)用；（2） 針對(duì)大型企業(yè)銷售管理人員多，銷售管理復(fù)雜的特點(diǎn)，通過(guò)系統(tǒng)提供的靈活的人員權(quán)限設(shè)置和全面的財(cái)務(wù)核算方式，實(shí)現(xiàn)真正的銷售網(wǎng)絡(luò)化辦公；（3） 在實(shí)現(xiàn)訂單的電子化、工作流程的數(shù)字化同時(shí)，幫助公司領(lǐng)導(dǎo)提高決策的科學(xué)化水平；（4） 通過(guò)對(duì)客戶信息的管理，

41、實(shí)現(xiàn)對(duì)客戶廣告走勢(shì)和重要客戶情況統(tǒng)計(jì)和分析。整個(gè)系統(tǒng)操作業(yè)務(wù)人員包括：銷售員、銷售經(jīng)理、倉(cāng)庫(kù)管理員、審計(jì)員、公司銷售主管、和系統(tǒng)管理員。各個(gè)角色承擔(dān)不同的系統(tǒng)任務(wù)，通過(guò)網(wǎng)絡(luò)和通信系統(tǒng)，連接到銷售管理系統(tǒng)，使用統(tǒng)一的訪問(wèn)界面，進(jìn)行日常的銷售業(yè)務(wù)操作，最終實(shí)現(xiàn)銷售部門業(yè)務(wù)的正常運(yùn)轉(zhuǎn)。3 系統(tǒng)的UML分析與實(shí)現(xiàn)UML概述及特點(diǎn)UML是一種編制系統(tǒng)藍(lán)圖的標(biāo)準(zhǔn)化語(yǔ)言，可以對(duì)大型復(fù)雜系統(tǒng)的各種成分可視化說(shuō)明并構(gòu)造系統(tǒng)模型，以及建立各種必要的文檔。UML通過(guò)三類圖形建立系統(tǒng)模型：Use Case圖，靜態(tài)結(jié)構(gòu)圖（類圖，對(duì)象圖，組件圖，配置圖）和動(dòng)態(tài)行為圖（順序圖，協(xié)同圖，狀態(tài)圖，活動(dòng)圖），這些圖可以從不同抽象

42、角度使系統(tǒng)可視化。UML具有面向?qū)ο?、可視化、?dú)立與開(kāi)發(fā)過(guò)程和程序設(shè)計(jì)語(yǔ)言以及易于掌握使用等特點(diǎn)。UML適用于各種規(guī)模的系統(tǒng)開(kāi)發(fā)，能促進(jìn)軟件復(fù)用，方便地集成已有的系統(tǒng)并有效減少開(kāi)發(fā)中的各種風(fēng)險(xiǎn)。UML在銷售管理系統(tǒng)中的實(shí)際應(yīng)用UML是一種建模語(yǔ)言，是系統(tǒng)開(kāi)發(fā)的一個(gè)組成部分，本身并沒(méi)有關(guān)于開(kāi)發(fā)過(guò)程概念的定義和表示符號(hào)。UML的創(chuàng)始人 booch,Jacobson和Rum Baugh在rational公司的支持下綜合了多種系統(tǒng)開(kāi)發(fā)過(guò)程的長(zhǎng)處，提出新的面向?qū)ο蟮拈_(kāi)發(fā)過(guò)程，稱為Rational統(tǒng)一過(guò)程（Rational Unified Process,RUP）。RUP過(guò)程的核心工作流程包括：業(yè)務(wù)建模、

43、需求分析、系統(tǒng)分析與設(shè)計(jì)和實(shí)現(xiàn)、實(shí)現(xiàn)、測(cè)試和系統(tǒng)部署。下面通過(guò)UML來(lái)分析并構(gòu)造銷售管理系統(tǒng)模型，并結(jié)合Rational統(tǒng)一過(guò)程加以描述，圖形使用Rational Rose 工具軟件繪制。3.1 銷售管理系統(tǒng)的業(yè)務(wù)建模和需求分析業(yè)務(wù)模型和需求分析的目的是對(duì)系統(tǒng)進(jìn)行評(píng)估，采集和分析系統(tǒng)的需求，理解系統(tǒng)要解決的問(wèn)題，重點(diǎn)是充分考慮系統(tǒng)的實(shí)用性。結(jié)果可以用一個(gè)業(yè)務(wù)用例（Business Use Case）框圖表達(dá)，根據(jù)銷售系統(tǒng)的基本特征和功能可得到 本系統(tǒng)的用例圖，如圖2。圖1 銷售管理系統(tǒng)業(yè)務(wù)用例框圖模型中的活動(dòng)者代表外部與系統(tǒng)交互的單元，包括銷售員、銷售經(jīng)理、倉(cāng)庫(kù)管理員、審計(jì)員、公司銷售主管、和

44、系統(tǒng)管理員；業(yè)務(wù)用例框圖是對(duì)系統(tǒng)需求的描述，表達(dá)了系統(tǒng)的功能和所提供的服務(wù)，包括客戶管理子系統(tǒng)、訂單管理子系統(tǒng)、銷售統(tǒng)計(jì)子系統(tǒng)、產(chǎn)品管理子系統(tǒng)系統(tǒng)管理子系統(tǒng)。圖2是銷售管理系統(tǒng)層次的用例模型，只包含了最基本的Use Case模型，是系統(tǒng)的高層抽象。在開(kāi)發(fā)過(guò)程中，隨著對(duì)系統(tǒng)需求認(rèn)識(shí)的不斷加深，用例模型可以從頂向下不斷細(xì)化，演化出更加詳細(xì)的Use Case模型。 根據(jù)系統(tǒng)的用例圖，可以對(duì)系統(tǒng)的持久對(duì)象進(jìn)行設(shè)計(jì)，下圖是本系統(tǒng)持久對(duì)象類及類之間關(guān)系圖。圖2 核心業(yè)務(wù)對(duì)象類及類之間關(guān)系3.2 銷售管理系統(tǒng)設(shè)計(jì)系統(tǒng)分析與設(shè)計(jì)是研究欲采用的實(shí)現(xiàn)環(huán)境和系統(tǒng)結(jié)構(gòu)，結(jié)果是產(chǎn)生一個(gè)對(duì)象模型，也就是設(shè)計(jì)模型。設(shè)計(jì)模型

45、包含了Use Case的實(shí)現(xiàn)，可以表現(xiàn)對(duì)象如何相互通信和運(yùn)作來(lái)實(shí)現(xiàn)Use Case流的。對(duì)于系統(tǒng)的靜態(tài)結(jié)構(gòu)，可以通過(guò)類圖、對(duì)象圖、組件圖和配置圖來(lái)描述；對(duì)于系統(tǒng)的動(dòng)態(tài)行為，可以通過(guò)順序圖、協(xié)同圖、狀態(tài)圖、活動(dòng)圖描述。這些圖在加上說(shuō)明文檔就構(gòu)成一個(gè)完整的設(shè)計(jì)模型。3.2.1系統(tǒng)架構(gòu)設(shè)計(jì)銷售管理系統(tǒng)擁有大量銷售信息資源，這些資源包括各種客戶、訂單、和產(chǎn)品等信息。其數(shù)據(jù)量大、信息變化快，非結(jié)構(gòu)化信息與結(jié)構(gòu)化信息共存。使用UML對(duì)銷售管理系統(tǒng)進(jìn)行基于面向?qū)ο蟮姆治龊蛯?shí)現(xiàn)，可以從開(kāi)發(fā)的第一步開(kāi)始，從系統(tǒng)的底層就把握住銷售信息資源的特征，為下一步具體實(shí)現(xiàn)打好基礎(chǔ)。在銷售管理系統(tǒng)建立模型時(shí)要涉及到處理大量的

46、模型元素，如類、進(jìn)口、組件、節(jié)點(diǎn)、圖等，可以將語(yǔ)意上相近的模型元素組織在一起，這就構(gòu)成了UML的包，包從較高的層次來(lái)組織管理系統(tǒng)模型。系統(tǒng)主要有以下四個(gè)包：（1）用戶接口包（ser Interface Package）用戶接口包在其他包的頂層次，為系統(tǒng)用戶提供訪問(wèn)信息和服務(wù)。要注意一點(diǎn)，由于開(kāi)發(fā)工具使用不同，該接口描述也是有區(qū)別的。如果采用Java Web開(kāi)發(fā)，就要以JSP(Java Server Pages)為基礎(chǔ)，如果采取Microsoft的A開(kāi)發(fā)，其基礎(chǔ)就是標(biāo)準(zhǔn)化控件組。本系統(tǒng)在此將使用Java Web開(kāi)發(fā)，下面有關(guān)代碼的描述都是基于Java的。（2）業(yè)務(wù)邏輯包(Business Rul

47、e Package)該包是銷售管理系統(tǒng)業(yè)務(wù)的核心實(shí)現(xiàn)部分，包括客戶管理、訂單管理、產(chǎn)品管理等，其他包可以通過(guò)訪問(wèn)該包提供的接口，實(shí)現(xiàn)業(yè)務(wù)邏輯，如客戶管理業(yè)務(wù)等。（3）數(shù)據(jù)持久訪問(wèn)包(Data Persistence Package)該包實(shí)現(xiàn)數(shù)據(jù)的持久化，也就是與數(shù)據(jù)庫(kù)交互，實(shí)現(xiàn)數(shù)據(jù)的存取、修改等操作。（4）通用工具包（til Package）該包主要包括應(yīng)用程序安全檢查的類，可以為上面三個(gè)包提供安全檢查，如客戶端檢查和服務(wù)器端業(yè)務(wù)規(guī)則檢查等，同時(shí)包括一些系統(tǒng)異常檢查與拋出處理以及系統(tǒng)日志服務(wù)等。3.2.2系統(tǒng)詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)主要是描述在系統(tǒng)分析階段產(chǎn)生的類，與分析階段類的區(qū)別就是偏重于技術(shù)層面

48、和類的細(xì)節(jié)實(shí)現(xiàn)。銷售管理系統(tǒng)提供的各種服務(wù)都是建立在分布、開(kāi)放的信息結(jié)構(gòu)之上，依托高速、可靠的網(wǎng)絡(luò)環(huán)境來(lái)完成的。每項(xiàng)服務(wù)都可以看作一個(gè)事件流，由若干相關(guān)的對(duì)象交互合作來(lái)完成。對(duì)于這種系統(tǒng)內(nèi)部的協(xié)作關(guān)系和過(guò)程行為，可以通過(guò)繪制序列（Sequence）框圖和協(xié)作（Collaboration）框圖來(lái)幫助觀察和理解。此外，描述工作流和并發(fā)行為還可以通過(guò)活動(dòng)框圖，表達(dá)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的控制流。同時(shí)，可以在理解這些圖的基礎(chǔ)上，抽象出系統(tǒng)的類圖，為系統(tǒng)編碼階段繼續(xù)細(xì)化提供基礎(chǔ)。下面以Java Web開(kāi)發(fā)為例，介紹客戶管理子系統(tǒng)的詳細(xì)設(shè)計(jì)1.客戶管理子系統(tǒng)的基本結(jié)構(gòu)建模：下圖是客戶管理子系統(tǒng)主要類極其關(guān)系的詳細(xì)設(shè)計(jì)圖3 客戶關(guān)系子系統(tǒng)類的詳細(xì)設(shè)計(jì)及類之間關(guān)系2.序列圖：序列圖是一種對(duì)象交互圖，著重強(qiáng)調(diào)了時(shí)間序列，而不是靜態(tài)對(duì)象的關(guān)系，通過(guò)序列圖可以清楚地看到“誰(shuí)在什么時(shí)間對(duì)誰(shuí)說(shuō)了