本節(jié)和大家學(xué)習(xí)一下UML業(yè)務(wù)建模方面的內(nèi)容那個(gè)，UML業(yè)務(wù)建模的過程幫助我們理解了問題域的業(yè)務(wù)，同時(shí)，也可以啟發(fā)我們尋找改進(jìn)點(diǎn)，這些改進(jìn)點(diǎn)往往形成了以后軟件系統(tǒng)的需求。

UML應(yīng)用實(shí)作細(xì)節(jié)——UML業(yè)務(wù)建模

在實(shí)施UML業(yè)務(wù)建模之前，我們首先應(yīng)該問自己兩個(gè)問題:
1."軟件開發(fā)是否一定要做UML業(yè)務(wù)建模?"
2."業(yè)務(wù)模型是否可以直接映射到系統(tǒng)模型?"
答案都是否定的：業(yè)務(wù)建模不一定是必須的，很多軟件項(xiàng)目面臨的問題域（業(yè)務(wù)）可能很簡單，就不需要UML業(yè)務(wù)建模，這也是總則中把UML業(yè)務(wù)建模定為軟件開發(fā)第0步的原因；即是做了業(yè)務(wù)建模，由于它所表達(dá)的只是問題域當(dāng)前是什么樣，而不是使用軟件系統(tǒng)時(shí)會(huì)怎樣，因此，也不能把業(yè)務(wù)模型，直接映射到系統(tǒng)模型。
那么業(yè)務(wù)建模有什么用?答案是它可以幫助我們了解現(xiàn)狀,啟發(fā)愿景和需求,是進(jìn)行精確有效的分析與設(shè)計(jì)的參考

實(shí)施UML業(yè)務(wù)建模的步驟可以分為:

1.確定研究范圍：這里是指我們要觀察的問題域范圍，譬如一個(gè)要實(shí)施OA系統(tǒng)的企業(yè)，我們需要研究的范圍可能包括整個(gè)企業(yè)的各個(gè)部門，也可能只包括相關(guān)的幾個(gè)部門，這取決于我們將來要在多大范圍內(nèi)為系統(tǒng)服務(wù)（軟件系統(tǒng)影響到多大范圍）；這一步是基本前提，如果范圍不明確，會(huì)導(dǎo)致以后的分析缺乏依據(jù)，或者產(chǎn)生矛盾；當(dāng)然，以后的分析中如果發(fā)現(xiàn)問題，這個(gè)范圍也是可以調(diào)整的。

2.識(shí)別業(yè)務(wù)執(zhí)行者：注意，執(zhí)行者是在系統(tǒng)之外的，這里的系統(tǒng)，并不是指軟件系統(tǒng)，而是將要使用我們軟件的活生生的業(yè)務(wù)系統(tǒng)，譬如一家銀行，一家汽車制造廠，一個(gè)政府部門等等；因此，這里的系統(tǒng)范圍，往往要比我們以后要做的軟件系統(tǒng)范圍大，軟件系統(tǒng)的actor，很可能只是業(yè)務(wù)系統(tǒng)內(nèi)部的一個(gè)業(yè)務(wù)工人（businessworker），而真正的顧客，才是業(yè)務(wù)系統(tǒng)的執(zhí)行者，如銀行的儲(chǔ)戶，汽車零售店等等。

3.識(shí)別業(yè)務(wù)用例：用例應(yīng)該對(duì)執(zhí)行者（actor）提供完整的價(jià)值，因此要從執(zhí)行者的角度去考慮用例。比如對(duì)于病人來說，醫(yī)院可以提供“診治”的用例，而”掛號(hào)“，”吃藥“等等就不是用例——因?yàn)檫@些都不能滿足患者的需要，即不能提供完整的價(jià)值；事實(shí)上，”掛號(hào)“很有可能是”診治“用例中的一個(gè)步驟。
發(fā)現(xiàn)用例時(shí)不應(yīng)忽略一些支持性事件，比如”企業(yè)內(nèi)部人員的發(fā)展與維護(hù)“”安全性活動(dòng)“等等，它們?yōu)橐恍┨厥獾腶ctor（如領(lǐng)導(dǎo)、董事會(huì)、政府）提供了價(jià)值

4.識(shí)別業(yè)務(wù)對(duì)象：業(yè)務(wù)對(duì)象是系統(tǒng)內(nèi)部的東西，又分為業(yè)務(wù)工人和業(yè)務(wù)實(shí)體，它們的區(qū)別僅在于是否是人。很多時(shí)候，他們是可以互相替代的，例如銀行的營業(yè)員和自動(dòng)取款機(jī)。業(yè)務(wù)用例是通過業(yè)務(wù)對(duì)象的交互實(shí)現(xiàn)的。
這里的步驟本身就是迭代的過程，比如在識(shí)別業(yè)務(wù)對(duì)象的時(shí)候，可能又啟發(fā)了新的業(yè)務(wù)用例，對(duì)業(yè)務(wù)用例的描述也可以從簡單的文本轉(zhuǎn)化為體現(xiàn)業(yè)務(wù)對(duì)象職責(zé)的活動(dòng)圖（泳道）和序列圖。

UML業(yè)務(wù)建模過程幫助我們理解了問題域的業(yè)務(wù)，同時(shí)，也可以啟發(fā)我們尋找改進(jìn)點(diǎn)，這些改進(jìn)點(diǎn)往往形成了以后軟件系統(tǒng)的需求：

1.信息流轉(zhuǎn)
2.演繹復(fù)雜邏輯
3.記錄實(shí)體信息
4.自動(dòng)工作,時(shí)間驅(qū)動(dòng)
這些改進(jìn)點(diǎn)有一個(gè)共同的特點(diǎn)，就是都是計(jì)算機(jī)擅長而人不善于做的事

盡管業(yè)務(wù)模型不能直接映射到系統(tǒng)模型，但它們之間還是存在一些可能（注意：只是可能，不是必然）的映射關(guān)系，具體如下：

1.業(yè)務(wù)用例可能映射到一個(gè)子系統(tǒng)
2.業(yè)務(wù)用例的一個(gè)步驟可能映射到軟件系統(tǒng)的一個(gè)用例
3.業(yè)務(wù)執(zhí)行者可能成為系統(tǒng)執(zhí)行者
4.業(yè)務(wù)工人可能成為系統(tǒng)執(zhí)行者
5.業(yè)務(wù)實(shí)體可能成為系統(tǒng)實(shí)體

【編輯推薦】

1. UML業(yè)務(wù)建模實(shí)例 圖書管理系統(tǒng)建模分析
2. 名師點(diǎn)評(píng) 如何進(jìn)行UML業(yè)務(wù)建模實(shí)例分析
3. 專家指導(dǎo) UML建模分析步驟
4. UML建模時(shí)需要注意的四大問題
5. UML業(yè)務(wù)建模實(shí)例分析