在大規模的需求調研展開之前，有一個重要的工作要做。這項工作在項目中所佔的時間跨度非常的小，但是卻有非常重要的意義。不同的人、不同的方法對這項工作有不同的描述，在我們的文章中，根據UP的思想，稱之爲"業務建模"。
業務建模（Business Modeling），業務建模是一個複雜的過程，對其下一個準確的定義是困難的事情。在RUP的詞彙表中將其解釋爲：
"包含您可用來對業務進行可視化建模的所有建模方法。這些是您可用於執行業務工程的方法的子集。"
從定義中可以看出，它是一種建模方法的集合，目的是對業務進行建模。這方面的工作可能包括了對業務流程建模，對業務組織建模，改進業務流程，領域建模等方面。
Brooks 大師說，三十多年來各式各樣的應用系統（Application Programs AP）歷經多次的修修改改，已經變得面目全非，如同一羣的怪獸，難以馴服。
Rogerson大師也說，The application is a rock in the river of change.（應用（系統）成爲改變之潮流中的頑石）。
對很多企業而言，有一個統合企業各部門的信息系統的心願似乎已經成了一種奢望。企業中或多或少都會有一些應用系統在輔助企業的自動化運作，當企業信息主管希望能夠對目前的信息系統進行整合，能夠配合企業的發展的時候，他們失望了。大多數的應用缺乏一個統一的接口，難以進行整合。
在我們進行項目開發的銀行中，我們也同樣發現了這個問題，不同部門的系統之間無法進行互聯，跨部門的業務流程必須經過手工的處理。
以前，應用程序的開發都是基於部門的功能的而建的。單純只是爲了解決目的而建立應用系統。所以這種方式建立的應用系統是針對特定的功能區域（Function Area）而建立的。至於如何使企業內的多個應用系統共同運作，就不在設計者的考慮之列了。隨着企業的發展，就會發現企業需要變化以適應市場變化，業務發展的時候，原有的一系列應用系統卻成了企業發展的攔路虎，這使得企業不得不回到手工的時代。
針對這種情況，有沒有相應的解決之道呢？解決的方法就是從業務建模入手，而不是從較低層次（部門級或以下）入手。通過用例分析技術，建立企業的業務模型，進行適當的切割，選取穩定的軟件架構，分析出企業的業務實體（Business Entity 企業中微小不可分的事物，抽象或具體的，如帳戶，契約等，又被稱爲Business Object），以此爲基礎，組裝出組件（Component），落實到相應的三層結構，建立針對特定功能區域的應用系統。
以這樣的流程做出來的企業應用系統，不論規模是部門級的，還是企業級的，都有擴展的餘地。以組件爲基礎的軟件三層構架，也能夠較好的配合企業的業務變化而變化（相應變化的代價較小）。而整個流程的第一步，就是業務建模。
在前一段時間，中國很流行企業流程再造BPR(Business Process Re-engineering)這個名詞。BPR這一名詞中的R(Re-engineering)一詞是由Dr. Hammer提出，說明企業必須推動四個層面的重新設計：Re-position、Re-organization、Re-system、Re-vitalizing之再造工程；名稱中的P(Process)，更是管理上由銷售、採購到財務、生產各層次，力求降低成本、提高產出，所必須精密設計的企業管理流程或程序。這個詞目前都是和ERP串聯在一起，成了ERP的前置工程，更成爲保證ERP能建立企業完美管理體系，以支持高績效的最重要因素。實際上呢，這個BPR就是我們所談到的業務建模。
可以看出，業務建模在ERP工程中被着重強調，而且ERP中的BPR已經成爲一門獨立的學科。不僅如此，即便是在普通的信息系統中，業務建模也是非常重要的，所不同的，僅僅是它們的規模而已。這一點上，可能大家會不理解，如果你只是爲企業的業務自動化建立應用，直接照搬企業模式不就行了嗎。這裏有兩點原因，一是企業原有的業務模式在以人爲主的環境中可能運行的很好，可是把這套模式原本不動的搬到計算機上就未必會適合了。人的能力和計算機的能力有很大的出入，所以流程必須經過調整以適應計算機；第二個原因是上面已經提到過的避免產生部門級的，部分功能區域的應用系統。
在RUP中，業務建模被作爲下游流程的輸入重點強調：業務模型是需求工作流程的一種重要輸入，用來了解對系統的需求。業務實體是分析設計工作流程的一種輸入，用來確定設計模型中的實體類。（RUP）
業務建模是需求工程中最初始的階段，也是整個項目的初始階段。需要指出的是，業務建模時間的跨度在不同的項目中有很大的差別的。在有些項目中，例如大型ERP系統，可能需要幾個月的時間。而對於普通的項目，業務建模的時間可能僅僅需要幾天的時間。
需求是技術無關（technology independent）的。在需求階段討論技術是沒有任何意義的。那隻會讓你的注意力分散。技術的實現細節是在後面的分析、設計階段才需要考慮的事情。而在業務建模階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節。因爲在業務建模階段，最重要的事情就是要了解業務的全貌，深入細節會浪費時間和精力。要知道，討論一個企業裏的業務細節，就算給你一個月的時間也沒必能夠結束。
在實際中，這兩點都是很難做到的。例如企業原先有一個系統，這就不得不由你討論和新舊系統的兼容問題。這時候就要注意，如果你是討論就有系統的架構的話，那還是屬於技術無關的範疇，如果你一旦進而討論各具體模塊/組件的細節，那就非但不是技術無關，而且也深入細節了。在不深入細節的問題上，往往你很難禁止項目涉衆（Stakeholder）①不去討論一些相關的業務細節。這個時候你可以將這些細節記錄下來，然後再回到業務建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉衆是所有會受到項目結果重大影響的人。
項目涉衆的共同願景：要想項目成功，可離不開項目涉衆的支持。在項目一開始，不論是項目涉衆還是開發人員，對項目的任務、範圍都是模糊不清的。但隨着項目的深入，原來模糊的景象會慢慢清晰、立體起來。但是爲了不浪費時間，我們有必要在項目射入之前，現在項目涉衆中豎立一個共同的願景。
共同願景的豎立可沒有想象中的那麼簡單，因爲每位涉衆都關心自己的利益，都有自己的評判標準。你可以把大家的意見都列在白板上，然後逐項集中討論，做出修正，直到大家的意見一致的時候爲止。在共同遠景的豎立過程中，其實有兩件事情也已經同時做了，項目範圍（scope）和高階（high-level）需求。
項目範圍：項目該做什麼，不該做什麼，需要在一開始就有明確的定義。對於項目範圍內的需求，一個也不要放過，而項目之外的，一個也不要去關心。雖然有的時候，範圍的變化會有利於項目本身，例如客戶的合理要求或是市場目標客戶的變化，但是這種變化應該要在"資源能夠支持"和"得到審批"的前提下進行。
項目範圍的描述可以通過陳述和圖示來進行。我建議大家使用圖示。因爲陳述語句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務系統。"這句話就是含糊不清的，你的電子商務系統是銷售什麼產品？面向什麼客戶？是否要支持在線支付？根據這些疑問，這個陳述句可以做進一步的修改，"建立在線訂貨系統，針對當前的目標客戶銷售公司的目前產品。"這樣就清楚許多了。不過圖示的方法會更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據經驗，DFD圖比較容易爲客戶所接受。
高階需求：這個部分我們在下面會詳細討論。既然是高階需求，就不能討論過多的細節。在討論高階需求的時候，儘量保證快速的討論出系統的概貌，建立需求模型，得到項目涉衆的一致通過。
取得支持：爲了保證需求計劃的順利進行，取得項目涉衆的支持至關重要。你可以選擇在這個時候告訴項目涉衆他們的權利和義務，以及開發人員的權利和義務。在這個方面，具體的我不想多說，大家可以參考『軟件需求』的第二章。主要的就是"涉衆有改變需求的權利，同時要承擔向開發人員講解需求的義務。"開發人員的權利和義務正好和涉衆相反。
業務建模會議：所有的這一切都通過業務建模會議進行，和其它會議不同的是，這個會議需要所有的項目涉衆參加，如果不能獲取所有項目涉衆的意見，那就不是完美的。會議中最重要的工具就是白板，一位出色的速記員也是必須的。
  |
|
在上一篇中我們討論了很多用例的知識，可是落實到企業中的時候，我們往往會感覺難以把握企業的用例，這一點我們在用例的誤區中也有提到。在實際的情況中，你可能會對角色的歸類，用例的劃分，粒度的把握等很細節的方面都沒有底，偏偏這些實際的東西對你的項目有非常大的影響。
RUP中，有多種的概念來支持用例的實現：業務主角（Business Actor）、業務實體（Business Entity）、業務用例（Business Use Case）、業務角色（Business Worker）、業務用例實例（Business Use-Case Instance）。爲了能夠比較清楚的展示出業務建模，我們採用了UP方法的代表――RUP。但在實際中，要視大傢俱體的情況而定，這裏所講到的概念，都是爲了幫助大家理解建模過程，並不是讓大家生搬硬套。
在我們對系統還絲毫不瞭解的時候，我們就會把系統看成一個很大很大的黑盒，這個大黑盒子我們會叫他業務域（Business Domain），把它的外部看成一個業務環境（business environment）。而那些在業務環境中和業務域有關係的人（也可能是物）就被稱爲業務主角（Business Actor）。在實際的例子中，我們可能會把信貸業務（注意不是信貸業務系統，這裏是業務建模，系統還不存在。）稱爲業務域，我們經過調查，發現平時和信貸業務打交道的有客戶，人民銀行，外匯管理局，其他銀行，信貸部門使用的其他系統，銀行內部的其他部門。所以這些人（物）就是業務主角。業務主角的實例一般包括了客戶、供應商、合作伙伴、潛在客戶（"市場"）、當地政府、在業務中未建模部分工作的同事等。必須注意的是，業務主角表示的特定類型的用戶，而不是某一個具體的用戶。一個角色可能會有很多實際用戶擔任，一個實際的用戶也可能會擔任很多的角色。
業務用例以及業務用例實例在RUP中的定義如下：
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a name.
業務用例實例是在業務中執行的一系列動作，這些動作爲業務的個體主角產生具有可見價值的結果。業務用例定義了一組業務用例實例。業務用例具有名稱。
剛開始大家可能會對業務用例以及業務用例實例有所疑問。其實可以把他們看成基類和子類的關係。在一個企業中，具體的工作流程可能有很多很多，比如你去麥當勞的時候，點漢堡和點薯條的工作流程就不一樣。衆多的流程給需求的調查工作造成了一定的難度。即使是最古老的哲學也告訴我們，表面現象是複雜的，本質是簡單的。爲了簡化需求工作，我們就把點漢堡和點薯條歸納爲點餐。這樣，點餐就是一個業務用例，而點漢堡、點薯條就是相對應的業務用例實例。
業務用例
業務角色和業務主角的概念也很容易讓人摸不着頭腦。其實看它們的英文願意會更容易理解它們的區別：Business Worker，Business Actor。Worker有工人的意思，而Actor有參與者的意思。所以它們的區別就是一個在內部，一個在外部。業務角色是實現業務用例的人，業務主角是和業務有關的人。例如，對銀行的押匯業務而言，客戶就是業務主角，他和業務有關。而押匯人員就是業務角色，因爲他們是實現業務用例的人。在RUP中，二者定義如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other workers and manipulates business entities while participating in business use-case realizations.
業務角色代表業務中的一個或一組角色。參與業務用例實現時，一個業務角色和其他角色進行交互，並操縱業務實體
A business actor represents a role played in relation to the business by someone or something in the business environment.
業務主角代表了與業務有關的角色，此角色由業務環境中的某個人或物來擔任。
業務角色
業務主角
分辨業務角色和業務主角要看環境而定。當你開發企業的ERP系統時，部門的員工都屬於業務角色，而你開發一個部門級的應用時，其他部門的員工可能屬於業務主角。
業務實體，在一些文章中被稱爲商業對象（Business Object）。不論怎麼叫，所表示的意義都是一樣的。例如在銀行信貸這個例子中，我們就涉及到很多業務實體：契約、單筆貸款、客戶等。所以業務實體就是企業中那些很基本的要素。如果覺得銀行押匯的例子不好理解。可以想象餐廳中的菜單、漢堡等都是業務實體。在RUP中，業務實體被定義爲：
A business entity represents a "thing" handled or used by business workers.
業務實體代表業務角色處理或使用的"事物"。
業務實體
在很早以前，我們討論過需求易變性。相對於需求的不斷變化，可是業務實體對象在一段相當長的時間內都存在。航空公司今天打折，明天又不打，還有明折、暗折。可是機票從來沒見有什麼大的變化，從來也只有那幾樣屬性：價格、航班、出發地、目的地。所以業務實體是比較穩定的。這對於我們是有很大的意義的：
"一個業務實體經常代表某個對多個業務用例或用例實例有價值的事物，因此，業務實體對象的生存期相當長。一般而言，一個好的業務實體不包含關於其使用主體和使用方法的信息。"（RUP）
由業務實體組成的業務用例會穩定很多。在以前，開發方式採用模塊爲基礎的方法，需求變化的時候，只好改寫模塊。如果採用穩定的業務實體來實現業務用例的話，業務用例的改變只需要對業務實體進行重新的組合。當然，這裏還需要很多的技術來實現，並沒有那麼簡單。要知道，四個現代化可不是一天就能夠實現的。
還有一個使用業務實體的重要原因：業務實體的特性決定它具有天生的重用性。就像麥當勞的銷售系統中有漢堡實體，生產系統中也有，供應鏈系統中也有。天哪，這世界真是美好！
使用業務實體一個很大的困惑是應該把它做爲類還是屬性。這個取決於業務環境對這個實體的重視程度。一個客戶在銀行信貸部門是一個很重要的類，而在押匯部門就只是信用證實例的一個屬性。這個問題非常的重要。設計時的失誤可能會導致今後系統改進的極大痛苦。例如本該設計爲類的業務實體設計成了屬性，在今後增加屬性的時候不得不面對着數據庫的調整和系統的修改。
業務用例模型（business use-case model），在RUP中定義爲：
The business use-case model is a model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.
業務用例模型是說明業務預期功能的模型。作爲一個核心輸入模型，業務用例模型用於確定組織的各個角色和可交付工件。
從業務用例模型的定義可以看出，它是企業最核心，最概括的業務說明。它主要是由業務用例和業務主角構成的，其主要目的是說明客戶和合作伙伴是如何開展業務的，它描述業務的主要方式是通過業務用例的方式。下圖爲RUP中業務用例模型的圖示。
業務用例模型
從圖中我們也可以很清楚的看出業務用例模型包括一組的業務用例。這是因爲企業中的業務通常都會由多個的業務用例的多個實例構成。這些業務用例形成的企業工作流程可能會由業務主角所引發，也可能會由業務規則②所引發。
②業務規則（Business Rules）：業務規則是必須遵守的政策或條件的聲明。（Business Rules are declarations of policy or conditions that must be satisfied.）
業務用例模型實際上就是企業經營業務的一種描述，爲了建立完整、準確的企業用例模型，應該將注意力專注於企業的業務做了些什麼事情，而不應該集中於如何做。雖然這樣可能會產生一些業務用例相沖突，相重複的情況，但是RUP的思想在於迭代，這項工作完全可以在接下去的迭代週期內完善。
業務用例模型是和企業業務最貼近的計算機模型。它的很多思想和企業日常經營如出一轍。在企業的日常活動中，業務的種類可能有很多種。在一些講述ERP思想的文章中，通常會強調三類：
一種是和主營業務密切相關的工作，例如銀行的營業部、信貸部、押匯部等。這種工作通過人的勞動，將一種資源轉變爲另一種資源，產生價值。
一種是管理型的工作，例如公司的管理層，財務部門等。這種工作本身並不產生價值，但是它通過指導、管理、檢測第一種工作，加大第一種工作的產出價值。
還有一種稱爲支持工作，例如系統管理、安全等。它並不是很重要，具有支持其他工作的性質。
業務模型同樣可以使用這種分類。通過這種分類，可以更好的把握核心業務用例，爲下一步的工作打好基礎。
有很多業務用例是由業務主角觸發的，RUP中也把和業務主角有關聯關係的業務用例稱爲核心業務用例（Core Business Use Case）。這強調了構建業務模型的目的是爲了提供以用戶爲中心的服務。這也是我們建立業務用例的時候應該注意的。
當然，有時候業務用例的觸發是爲了產生用戶需要的結果。例如企業的市場調查行爲就不是由業務主角觸發，而是企業積累了大量用戶請求的結果。而對於管理型、支持型的，不直接和業務主角的客戶類發生聯繫，但是也有其特定的業務主角，如管理型的業務用例需要和董事會爲發生聯繫，支持型的業務用例可能和供應商發生聯繫。
在建立了基本的業務用例模型之後，對此模型進行精化是非常有必要的，這時候，在上一章中我們介紹的用例的擴展關係和使用關係就有了用武之地。除了這兩種關係，還有一種新的關係。
泛化關係（Generalization）：根據我的理解，可以把它看作我們比較熟悉的繼承關係很相似的一種關係。Generalization一詞含有一般化、概括的意思。它是一個相對抽象的詞。雖然它和繼承關係非常相似，但是它們在使用環境和產生目的方面都有相異之處。下圖描述了四個業務實體之間的泛化關係：
當你去麥當勞的時候（不要誤會，我並不是很經常去的），會選擇麥香雞漢堡、麥香魚漢堡或是吉士漢堡。但是分別對這三種漢堡建立業務實體就非常沒有意義。所以可以將它們概括爲漢堡這個業務實體。同樣的道理，企業的業務流程中也可以概括出一些共有的屬性和行爲。爲了避免多次說明同一個工作流程，您可以將共有的行爲放在一個單獨的業務用例中。稱爲父用例，執行子用例的用例實例將遵循父用例的事件流，同時插入附加行爲或修改在子用例事件流中定義的行爲。
以上的原理我採用了UP的方法。但是除了UP方法，還有XP、FDD等方法。所以在做業務建模的時候，也要根據不同的方法選擇適當的工件。例如素材和功能。方法的好壞並不是我們這片文章討論的重點，我會在另一篇文章中討論方法。再一次需要強調的是，上面討論的RUP的工件只是爲了學習，所以才定義了比較複雜的工件，區分了它們之間的區別。但是在實際中，並不需要這麼多的工件，那隻會使你的項目涉衆和開發人員糊塗。這些工件的區別只要在你心中就可以了。至於具體的實踐，我們會在下一篇文章中討論。
|
||
|
林星，辰訊軟件工作室項目管理組資深項目經理，有多年項目實施經驗。辰訊軟件工作室致力於先進軟件思想、軟件技術的應用，主要的研究方向在於軟件過程思想、Linux集羣技術、OO技術和軟件工廠模式。您可以通過電子郵件 [email protected] 和他聯繫。 |
|