對(duì)業(yè)務(wù)建模的思考——為什么要業(yè)務(wù)建模 (轉(zhuǎn))

totoo130

了解目標(biāo)組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機(jī)制。了解目標(biāo)組織中當(dāng)前存在的問(wèn)題并確定改進(jìn)的可能性。確保客戶(hù)、最終用戶(hù)和開(kāi)發(fā)人員就目標(biāo)組織達(dá)成共識(shí)。導(dǎo)出支持目標(biāo)組織所需的系統(tǒng)需求。 （來(lái)自RUPCN）

以上大家可以理解，我們有沒(méi)有更深的理解呢？我先從業(yè)務(wù)主角和業(yè)務(wù)角色說(shuō)起業(yè)務(wù)建模，在業(yè)務(wù)建模中主要有業(yè)務(wù)主角（BUSINESS ACTOR）和業(yè)務(wù)角色（BUSINESS WORKER），對(duì)此我們有什么了解呢。我先做出定義：業(yè)務(wù)主角是服務(wù)對(duì)象，如對(duì)商店進(jìn)行業(yè)務(wù)建模， 業(yè)務(wù)主角是顧客。業(yè)務(wù)角色是服務(wù)人員或系統(tǒng)，如對(duì)商店進(jìn)行業(yè)務(wù)建模，業(yè)務(wù)角色是售貨員。業(yè)務(wù)主角是為誰(shuí)提供服務(wù)，產(chǎn)生了用例。業(yè)務(wù)角色是提供服務(wù)，完成了用例�？梢宰屑�(xì)看看RUPCN。這兩個(gè)東西它們?cè)赗OSE中圖形的表示也不一樣。

但大家有沒(méi)有想過(guò)，業(yè)務(wù)建模更深的意義，我們?cè)趥鹘y(tǒng)的軟件工程來(lái)說(shuō)并沒(méi)有類(lèi)似業(yè)務(wù)建模這個(gè)概念，而RATIONAL公司又要將此放入，在軟件工程中，它又到底起了什么作用呢？

一般說(shuō)來(lái)，我們做一個(gè)軟件項(xiàng)目基本上都是從需求調(diào)研后就到需求建模和需求分析了，沒(méi)怎么去想業(yè)務(wù)建模。而大家有沒(méi)有想過(guò)，我們對(duì)需求的處理比較表象，如界面、功能和數(shù)據(jù)，對(duì)業(yè)務(wù)處理過(guò)程缺少規(guī)范的說(shuō)明，而這正是開(kāi)發(fā)必須的。你有沒(méi)有覺(jué)得你以前很多開(kāi)發(fā)沒(méi)有準(zhǔn)確反應(yīng)需求，是否有一個(gè)原因，不是需求不清，而是對(duì)需求的實(shí)現(xiàn)過(guò)程不清，即沒(méi)有了解好業(yè)務(wù)，從RUP的角度來(lái)說(shuō)，也就是缺少了業(yè)務(wù)建模這一關(guān)鍵環(huán)節(jié)。我曾經(jīng)思索過(guò)業(yè)務(wù)建模最主要解決什么問(wèn)題，我的看法就是業(yè)務(wù)建模就是創(chuàng)建業(yè)務(wù)處理模型，是進(jìn)行需求分析的依據(jù)。而需求分析的結(jié)果，將要確定一個(gè)開(kāi)發(fā)規(guī)范，正確的實(shí)現(xiàn)業(yè)務(wù)處理過(guò)程應(yīng)當(dāng)是它的一個(gè)重要內(nèi)容，而我們?cè)谛枨笳{(diào)研時(shí)，往往忽視了這一點(diǎn)。

那么，在需求調(diào)研中，需求建模與業(yè)務(wù)建模誰(shuí)先誰(shuí)后呢？個(gè)人認(rèn)為，業(yè)務(wù)是本來(lái)就存在的，不管有沒(méi)有這個(gè)軟件或項(xiàng)目，它都存在，它都在按一定的模式運(yùn)作，因此業(yè)務(wù)建模與需求調(diào)研、需求建模是無(wú)關(guān)的，立項(xiàng)之前業(yè)務(wù)模型就可以存在. 或是立項(xiàng)以前，業(yè)務(wù)建模就可以完成的。 然而，實(shí)際并非如此，用戶(hù)只知道如何處理業(yè)務(wù)，卻很少有一個(gè)完整的業(yè)務(wù)模型，當(dāng)立項(xiàng)時(shí)，就需求承建方邦助客戶(hù)創(chuàng)建它。因?yàn)槌薪ǚ讲涣私饪蛻?hù)的業(yè)務(wù)過(guò)程是不能建模的， 又必須了解客戶(hù)的業(yè)務(wù)。

對(duì)于軟件開(kāi)發(fā)過(guò)程，從軟件工程的角度來(lái)說(shuō)大多數(shù)人都清楚從需求調(diào)研，到需求建模，需求分析，系統(tǒng)分析，系統(tǒng)結(jié)構(gòu)設(shè)計(jì)，系統(tǒng)代碼設(shè)計(jì)，系統(tǒng)測(cè)試，系統(tǒng)維護(hù)這一過(guò)程，我參與過(guò)的項(xiàng)目，讓我感到，有些項(xiàng)目失敗或是非常難做，不在于以上這些環(huán)節(jié)沒(méi)做好，而在于少了業(yè)務(wù)的環(huán)節(jié)。

很多人也許會(huì)說(shuō)，業(yè)務(wù)不就是需求嗎，沒(méi)錯(cuò)，但更多的時(shí)候我們關(guān)注的是界面、功能、和數(shù)據(jù)，卻很少注意功能之間的聯(lián)系即業(yè)務(wù)過(guò)程。

有沒(méi)有想過(guò)，我們將軟件所有的功能做成菜單，讓用戶(hù)自己選擇他們要做什么，而沒(méi)有一個(gè)業(yè)務(wù)過(guò)程的概念，用戶(hù)要自己知道用了某個(gè)功能后下一個(gè)該用哪個(gè)。這樣的系統(tǒng)其實(shí)不是應(yīng)用系統(tǒng)，只是一個(gè)數(shù)據(jù)處理機(jī)或者說(shuō)是一個(gè)比較復(fù)雜的計(jì)算機(jī)器。它把業(yè)務(wù)過(guò)程分解為一些獨(dú)立/分散的功能，而沒(méi)有把這些功能組織起來(lái)。因此，有必要將業(yè)務(wù)從需求中分離而進(jìn)行強(qiáng)調(diào)。我想，這也就是RATIONAL 公司引入業(yè)務(wù)建模這個(gè)重要的概念吧，

無(wú)論是從我的經(jīng)驗(yàn)、觀點(diǎn)和教訓(xùn)來(lái)說(shuō)，還是看了RUP的觀點(diǎn)來(lái)年，我個(gè)人認(rèn)為新的軟件開(kāi)發(fā)過(guò)程是：業(yè)務(wù)調(diào)研，業(yè)務(wù)建模(業(yè)務(wù)分析)，(業(yè)務(wù)模型分析)需求調(diào)研（這時(shí)，已經(jīng)有一部分需求可從來(lái)務(wù)模型中獲得）, 需求建模，需求分析……因?yàn)榻�模的過(guò)程也是分析的過(guò)程，所以業(yè)務(wù)建模和業(yè)務(wù)分析可能交叉在一起。如果遇到一個(gè)客戶(hù)，規(guī)范到已經(jīng)有了現(xiàn)成的業(yè)務(wù)模型，那么直接就拿來(lái)就可以了。如果業(yè)務(wù)建模與需求調(diào)研是同一班人，那么需求調(diào)研中的業(yè)務(wù)模型分析工作就比較容易了。


業(yè)務(wù)建模當(dāng)中又要注意什么呢？我個(gè)人的看法是：千萬(wàn)別把業(yè)務(wù)建模和需示分析混在一起啦。如網(wǎng)上訂單系統(tǒng)，一個(gè)人下了訂單，當(dāng)然此訂單是通過(guò)系統(tǒng)自動(dòng)完成，并沒(méi)有后臺(tái)人員的支持，此時(shí)，業(yè)務(wù)主角當(dāng)然是下訂單的人，那業(yè)務(wù)角色呢 是否是沒(méi)有，還是下訂單的人？ 對(duì)于系統(tǒng)來(lái)說(shuō)，業(yè)務(wù)主角當(dāng)然是下訂單的人，而業(yè)務(wù)角色呢？不太可能是系統(tǒng)自已吧？ 而我的看法是業(yè)務(wù)角色就是系統(tǒng)自已，那不是很矛盾嗎？其實(shí)，關(guān)鍵一點(diǎn)是業(yè)務(wù)建模你不能有需求分析的概念，在這里，系統(tǒng)并不是軟件系統(tǒng)，而是完成業(yè)務(wù)主角的訂單，即一個(gè)用例的東西，根據(jù)業(yè)務(wù)建模的概念，完成了訂單這個(gè)用例只能是訂單系統(tǒng)，那么業(yè)務(wù)角色也就是訂單系統(tǒng)。因?yàn)樗�是下訂單這一業(yè)務(wù)中。

無(wú)論業(yè)務(wù)角色還是業(yè)務(wù)主角，都是對(duì)角色的抽象，不能具體到某個(gè)人的。而一個(gè)具體的事務(wù)，可能會(huì)兼任兩個(gè)不同的角色，但此時(shí)，大部分發(fā)生了身份或崗位的轉(zhuǎn)移。

原文 http://www.javaeye.com/topic/164