第 3 部分 ：轉換到系統模型

Steven Franklin
軟件設計師和過程專家
2004 年 3 月

本文將繼續通過這個全面的應用 RUP 和 其他 Rational 工具的樣例項目來介紹創建項目的 Rational Rose 模型，本文中我們將開始創建代表“目前”業務情況的系統模型，并將此業務模型轉換成為“將來”的系統模型。

這個第 3 部分文章重點的介紹了在 Rational Rose 中完成的早期建?；顒?。首先我們來對 ASDI 現有的（“as is”）系統進行建模，通過業務用例和業務對象可以顯示當前事情是如何工作的。我們將從這個反映現有系統的模型創建出符合 ASDI 新的需求的系統模型，并且將這個系統模型作為建立軟件的基礎。

伴隨著這本文有 2 個演講稿 (來自于 Rational 用戶大會 2000) 這里討論了以下主題： Yves Holvoet 的 “維護分析模型與多個設計模型的同步” 和 Robert Bretall 的 “結構化你的 Rational Rose 模型”。后一個演講稿附帶一個 Rose 模型。

第 3 部分所使用的工具和技術：

• Rational 統一過程 (RUP) — 指導軟件開發過程，對項目的每個階段提供建議的過程和工作產物
• Rational Rose 企業版 — 為了創建“目前的”業務模型（使用統一建模語言（UML））并在分析線索的基礎上開始創建“將來的”系統模型

被創建的或者被更新的工作產物：

• 業務用例模型（Rational Rose） — 被創建用來代表系統“目前的”業務功能
• 業務對象模型 （Rational Rose） — 被創建用來捕捉系統“目前的”業務功能是如何被執行的：實體之間的協作、實體之間的交互和相關的過程和產物
• 用例模型（Rational Rose） — 不能完全的表示業務用例模型；被創建用來獲取具體的系統“將來的”執行功能（它作為構建軟件的基礎）

捕捉“目前的”系統
有太多新的和被改進了的 IT 系統在已有系統被了解之前被啟動。甚至是當已有系統還缺乏 IT 組件的時候，有必要在可選的和改進的方案被建議之前對當前的業務活動情況進行分析。然而人們總是跳過或者草草的完成這一步，但是這做會導致以下的問題：

• 對客戶的需求的理解不夠充分，減慢接下來的分析
• 對需求的不正確的解釋
• 不能準確的估計新方案所帶來的影響，導致當軟件被交付給客戶使用時對客戶的工作產生巨大的震動和要求客戶完全改變現有的工作流程
• 不一致的術語和概念，導致與客戶之間產生交流上的誤解和混亂

創建一個業務模型以捕捉“目前的”系統的情況可以是非?？焖俚娜蝿詹⒛軌虍a生有用的分析線索，這些線索將簡化對“將來的”系統的定義。在創建這個模型中能夠對我們有幫助的一件事情是工作狀態（SOW）。雖然 SOW 主要用來描述“將來的”系統的需求，但是它也提供了ASDI 的當前業務流程的有用的背景信息。

在 Rational 統一過程（RUP）初始階段部分存在一系列的用于業務建模的方法（也是就在我們項目的第 1 階段）。與 ASDI 一起創建一個 IT 系統，我們需要一個“目前的”模型以捕捉文件的流轉和他們的當前系統的交互活動。我們在 Rational Rose 中創建了下列 RUP 工作產物作為業務建模工作的部分：

• 業務用例模型， 建模“目前的”業務功能。
• 業務對象模型 (有時也稱作 領域模型)， 對執行業務功能的對象和這些對象之間的關系進行建模。一個業務對象模型可能會顯示一個發票是如何被生成并如何在系統中進行流轉，或者顯示了一個購買請求的開始到結束的過程。

注重在以前的一些項目中，我們跳過了業務建模的步驟，因為我們是建立一個全新的系統，或者是因為我們已經非常好的了解了已有的業務模型。但是因為我們對 ASDI 的業務是生疏的，因此我們覺得這一步是十分重要的。

我們也考慮到開發一個業務術語表（使用 RUP 提供的工作產物模板），但是我們發現我們的術語中的大多數是相當標準和明確的，而且這些術語在我們的業務對象模型中被充分的捕捉了。更加復雜或者嚴格的項目將會從創建業務術語表中獲益以確保在所有產物中的一致性。

當我們使用 Rational Rose 創建我們的模型時，我們感到僅僅簡單的創建圖是不夠的。我們發現僅僅通過圖的方式表達模型對圖的創建者是輕易理解的，但對圖的閱讀者來說卻是很難讀懂的，因此我們為每一個圖附加了文檔（通過在圖上點擊并在文檔窗口輸入文本）。我們也為圖中的每一項提供了文檔 — 用例、業務對象、用戶或者其他項 — 用一到兩行的文字來描述每一項的目的。