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

UML應用實作細節(jié)——UML業(yè)務建模

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

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

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

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

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

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

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

1.信息流轉
2.演繹復雜邏輯
3.記錄實體信息
4.自動工作,時間驅動
這些改進點有一個共同的特點，就是都是計算機擅長而人不善于做的事

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

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

【編輯推薦】

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