主題

簡介

Rational Unified Process 介紹的業務建模方法中包括為支援業務工具或系統生成需求的方法。這種方法簡明而直接。很好地理解業務流程對於構建正確的系統至關重要。如果您使用人員的角色和職責，以及業務所處理物件的定義作為構建系統的基礎，這個模型將更有價值。正是通過這種對業務更加深入的內部分析（在業務物件模型中表示），才能瞭解它與系統模型最緊密的關係。

業務模型和支援資訊系統模型之間的關係

從構架的角度來看，如果您要構建的系統屬於以下型別，那麼具有適當的業務模型會十分有用：

• 為某個特殊行業的一個或多個公司專門定製的系統，例如銀行和保險公司。
• 用於開放市場的一系列應用程式，例如訂單處理系統、結帳系統和航空管制系統。

業務模型為分析模型中給出的用例檢視和邏輯檢視提供輸入。您還可以在分析級別上找到核心機制（稱為分析機制）。

應該考慮以下幾點：

• 對於每個將被系統支援的業務用例，在分析模型中確定一個子系統。子系統處於應用程式層中，我們把它看作基本的原型迭代。例如，如果業務用例模型中有一個訂單流程和一個結帳流程，您就應該在分析模型的應用程式層確定一個訂單子系統和一個結帳子系統。您可能會認為訂單和結帳都是獨立的系統。沒錯，但這只是規模的問題。如果您把所有業務工具看做一個具有多個應用程式（這些應用程式共享構架）的系統，那麼訂單和結帳就是應用程式子系統。但如果您只是要構建一個“訂單管理”應用程式，那麼“訂單管理”就是整個系統，前邊的建議就沒有意義了。只有當您將組織內的所有業務工具看做一個系統時，這種做法才有意義。
• 為系統所支援的每個業務角色確定用例來表示需要自動化的物件。
• 為系統所支援的每個業務實體在分析模型中確定實體類。其中一部分作為系統中的候選核心機制（即構件實體）。
• 在業務專用層中為業務實體簇建立一個子系統，業務實體簇是指一組只用於一個業務用例的業務實體，或者一組緊密聯絡的業務實體。

在一個四層的系統構架中，業務模型為頂部兩層提供輸入

為每個業務角色確定一個候選的系統主角。為該業務主角參與的每個業務用例建立一個候選系統用例。

為了確定資訊系統用例，從業務物件模型中的業務角色著手。對每個業務角色執行以下步驟：

• 確定業務角色是否需要使用資訊系統。
• 如果需要，在資訊系統的用例模型中為資訊系統確定一個主角。賦予該主角與業務角色相同的名稱。
• 為業務角色參與的每個業務用例建立一個系統用例。
• 對所有業務角色重複這些步驟。

示例：

基於銀行業務模型，您可以匯出候選的系統主角和系統用例。

如果您要構建一個系統來完全自動地完成一套業務流程，例如當您要構建一個電子商務應用程式時，業務角色將不再成為系統主角。此時，業務主角將直接和系統進行通訊併成為系統主角。

當構建這樣一個應用程式時，您實際上改變了業務執行的方式。業務角色的職責將轉移到業務主角。

示例：

當為某個銀行構建電子商務站點時，您將改變流程實現的方式。

• 職員 (Clerk) 的職責將轉移到客戶 (Customer)。

• 建立一個相當於業務主角“客戶”的系統主角“客戶”。

• 移去系統主角“職員”。

• 相應修改系統用例貨幣交易 1 (Money Transaction 1) 來配合系統主角“客戶”，而不再是以前的“職員”。

對業務角色的完全自動化改變了業務流程實現的方式，也改變了您查詢系統主角和用例的方法。

在系統的分析模型中為每個業務實體建立一個類

資訊系統管理的每個業務實體都將與資訊系統分析模型中的一個實體相對應。但有時候，讓業務實體的屬性與資訊系統模型中的實體對應會更合適。可以有多個業務角色訪問一個業務實體。因此，系統中對應的實體可以參與到多個資訊系統用例中。

示例：

業務實體客戶簡檔 (Customer Profile)、帳戶 (Account) 和貸款 (Loan) 都將進行自動化。

您如何理解業務模型中角色間的關係？您必須瞭解資訊系統是如何支援角色進行通訊的。由於在整個資訊系統中都可以得到資訊，這樣就避免了角色之間的資訊傳輸。

如果要使用業務物件模型進行資源計劃，或用作模擬的基礎，您應該對模型進行更新以反映所使用資源的型別。您需要對其進行修改，讓每個業務角色和業務實體只由一種型別的資源實施。如果要在業務物件模型的第一次迭代中重建業務流程，則不需要考慮資源。這樣做使您更多地關注現有的解決方案，而不是去確定那些可以使用新解決方案解決的問題。以下是一個考慮過程的示例：

• 在業務物件模型的第一次迭代中，不考慮將用於業務實施的資源或系統。
• 討論哪些部分可以實現自動化。
• 討論自動化將如何改變業務流程，開始草擬系統用例模型和系統需求。
• 在業務物件模型的第二次迭代中對其進行更新，使之可以反映所使用的資源和要實現自動化的部分。
  • 某些業務角色將被標註為自動角色。
  • 某些業務角色將被一分為二 - 一個是自動的，另一個不是自動的。
  • 兩個業務角色的某些部分可以分離出來形成一個新的自動角色。
  • 業務角色的部分職責可以移出組織，成為某個業務主角的職責。

  示例：

在銀行這個示例中，我們決定更新業務物件模型，將其用在資源計劃中。

• “職員”業務角色完全自動化，成為一個自動職員 (Automated Clerk)。銀行將只進行線上業務。

• 貸款專家 (Loan Specialist) 實現了部分自動化，分成自動貸款專家 (Automated Loan Specialist) 和貸款專家 (Loan Specialist)。

修改業務角色以反映自動化

摘要表

下表對業務模型和系統模型之間的關係進行了概括。