UML應用實作細節——UML業務建模
本節和大家學習一下UML業務建模方面的內容那個，UML業務建模的過程幫助我們理解了問題域的業務，同時，也可以啟發我們尋找改進點，這些改進點往往形成了以后軟件系統的需求。
UML應用實作細節——UML業務建模
在實施UML業務建模之前，我們首先應該問自己兩個問題:
1."軟件開發是否一定要做UML業務建模?"
2."業務模型是否可以直接映射到系統模型?"
答案都是否定的：業務建模不一定是必須的，很多軟件項目面臨的問題域（業務）可能很簡單，就不需要UML業務建模，這也是總則中把UML業務建模定為軟件開發第0步的原因；即是做了業務建模，由于它所表達的只是問題域當前是什么樣，而不是使用軟件系統時會怎樣，因此，也不能把業務模型，直接映射到系統模型。
那么業務建模有什么用?答案是它可以幫助我們了解現狀,啟發愿景和需求,是進行精確有效的分析與設計的參考
實施UML業務建模的步驟可以分為:
1.確定研究范圍：這里是指我們要觀察的問題域范圍，譬如一個要實施OA系統的企業，我們需要研究的范圍可能包括整個企業的各個部門，也可能只包括相關的幾個部門，這取決于我們將來要在多大范圍內為系統服務（軟件系統影響到多大范圍）；這一步是基本前提，如果范圍不明確，會導致以后的分析缺乏依據，或者產生矛盾；當然，以后的分析中如果發現問題，這個范圍也是可以調整的。
2.識別業務執行者：注意，執行者是在系統之外的，這里的系統，并不是指軟件系統，而是將要使用我們軟件的活生生的業務系統，譬如一家銀行，一家汽車制造廠，一個政府部門等等；因此，這里的系統范圍，往往要比我們以后要做的軟件系統范圍大，軟件系統的actor，很可能只是業務系統內部的一個業務工人（businessworker），而真正的顧客，才是業務系統的執行者，如銀行的儲戶，汽車零售店等等。
3.識別業務用例：用例應該對執行者（actor）提供完整的價值，因此要從執行者的角度去考慮用例。比如對于病人來說，醫院可以提供“診治”的用例，而”掛號“，”吃藥“等等就不是用例——因為這些都不能滿足患者的需要，即不能提供完整的價值；事實上，”掛號“很有可能是”診治“用例中的一個步驟。
發現用例時不應忽略一些支持性事件，比如”企業內部人員的發展與維護“”安全性活動“等等，它們為一些特殊的actor（如領導、董事會、政府）提供了價值
4.識別業務對象：業務對象是系統內部的東西，又分為業務工人和業務實體，它們的區別僅在于是否是人。很多時候，他們是可以互相替代的，例如銀行的營業員和自動取款機。業務用例是通過業務對象的交互實現的。
這里的步驟本身就是迭代的過程，比如在識別業務對象的時候，可能又啟發了新的業務用例，對業務用例的描述也可以從簡單的文本轉化為體現業務對象職責的活動圖（泳道）和序列圖。
UML業務建模過程幫助我們理解了問題域的業務，同時，也可以啟發我們尋找改進點，這些改進點往往形成了以后軟件系統的需求：
1.信息流轉
2.演繹復雜邏輯
3.記錄實體信息
4.自動工作,時間驅動
這些改進點有一個共同的特點，就是都是計算機擅長而人不善于做的事
盡管業務模型不能直接映射到系統模型，但它們之間還是存在一些可能（注意：只是可能，不是必然）的映射關系，具體如下：
1.業務用例可能映射到一個子系統
2.業務用例的一個步驟可能映射到軟件系統的一個用例
3.業務執行者可能成為系統執行者
4.業務工人可能成為系統執行者
5.業務實體可能成為系統實體
【編輯推薦】
