“UML應用實作細節”（by Think, UMLChina）複習筆記(3)——業務建模

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