初纏之業務建模

作者：江南白衣， 原文出處：http://blog.csdn.net/calvinxiu/archive/2007/04/13/1562846.aspx，轉載請保留。

     業務建模是整個RUP 四段式還沒開始前一個可選的序章：

    1.Team Dev對目標組織的業務非常白癡，沒法開展系統用例需求。
    2.尋求商務程序改造(BPR)和自動化。

    這兩個可能的原因，層次上相差甚遠，但目標都是端平客戶與Team Dev的視線。對於小團隊，可以只對--與待開發軟體系統相關的，最不清晰，最重要的一小部分業務進行建模。

    RUP很聰明的把用例建模的很多概念和流程複用到了業務建模中。IBM DW中文站有一個很好的教程《理解需要解決的問題:業務建模技術簡介》（需免費註冊DW帳號)，看完就差不多了，業務建模已超出了軟體範疇，RUP的細節描述和那本《UML業務建模》都未必絕對正確，所以RUP文檔裡的種種細節都不必深究細看。

    簡單說來，業務建模的產出工件，最實用的是--業務詞彙表、業務用例模型和業務分析模型。
    業務用例和系統用例是同胞兄弟，只不過後者的主角是待開發的軟體系統及其提供的功能，而前者的主角轉向了整個目標組織，及其核心業務和支撐、管理的業務，而且通常組織裡不止你一個系統。

    分析模型表達了組織內部如何的實現業務用例。為了照顧閱讀者的水平，使用比較直觀易懂的泳道活動圖表而不是分析模型常用的順序圖來表達。我通常在用例底下直接添加活動圖表，而不是建立一個UseCase Realize。
  
   這兩個圖裡一般有四種圖元：
   Bussiness Use Case，業務用例。
   Bussiness Actor ，目標組織外的客戶或夥伴，系統。
   Bussiness Worker，目標組織內的員工和系統。
   Bussiness Entity，業務實體，適合那些對資料對象盯得很緊的資訊系統。

   可以很簡單的從業務分析模型轉換出系統用例模型來。業務用例中待開發系統參與的活動就是用例，活動前後的Bussieness Actor或Worker 就是 Actor。

   參考資料：

• IBM DW中文站教程《理解需要解決的問題:業務建模技術簡介》（需免費註冊DW帳號)
    

  PS.罪過啊，CSDN北京遊記現在還沒時間寫。