應用Rational 工具簡化基于J2EE的項目 

第 5 部分 ：架構與設計

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

當這個正在進行的應用 RUP 和其他的 Rational 工具的 J2EE 樣例項目從用例轉換成架構和設計時（包括數據建模和構建測試設計假想的原型），這個項目已經進入了更加技術的階段了。
這個系列的第 5 部分首先檢查了一下項目的時間進度，然后當我們進入了架構、設計、數據建模和創建原型時，我們已經在下一個階段進行細化階段中了。

在第 5 部分演示的工具和技術：

• Rational Rose 企業版 用于創建設計模型（包括使用 Rose 的 data modeler 進行數據建模）
• Rational RequisitePRo — 用于添加或者細化需求

產生或者被更新的產物：

• 設計模型 （Rational Rose） — 被創建來添加架構和設計信息（包括數據庫計劃（schema））
• RequisitePro database — 被更新以添加或者細化基于架構和設計探索的需求

項目的時間進度

在開始進行具體的架構和設計工作之前，讓我們來檢查一下 ASDI 項目的整體進度。就像你可以第 1 部分回想起來的，這個由多個部分組成的系列文章覆蓋了項目的第 1 個階段：以一系列需求、一個參考架構和代碼（理想的可重用的）為結果的概念的驗證。到目前為止，我們大概使用了整個第 1 階段預算的三分之一，但我們已經接近了項目時間進度的一半了。這是在我們的預料之中的，因為我們有意的讓進度稍微慢一點。分析和計劃活動總是以較慢的步伐移動，團隊應該在項目開始時逐步的將他們建立起來。

因為第 1 階段要求一個相關的結構化的和正式的概念的證據，我們將它作為一個小的項目處理，通過在演進的產品上進行測試和 QA（同級審查）來完成它。RUP 有一些用于開發概念證據的機制，基本在分析和設計工作流的執行架構的合成的活動中。我們正在進一步的將概念的證據轉化成可用的 beta 版產品。我們能夠將更多的功能、風險的降低和產品的成熟放到這個階段中，我們越多的將技能和知識用到系統的產品版本中，我們的客戶就越興奮。

這個接下來的一系列的任務將比之前的活動更加具有技術性。我們正很好的向架構。設計、數據建模和原型前進。在第 4 部分中我們討論了一些原型和評估如何進行我們的工具選擇；現在我們的原型的關注點在測試我們設想的需求、系統說明和設計上。

過渡到架構和設計

架構和設計活動是在 ASDI 項目中最令人愉快和具有創造力的任務。我們為我們將系統計劃的高效、安全和簡單優雅而自豪。技術方案的遠景在多次令人興奮的會面、自由討論和技術探索中最終形產生了。

簡單的講，架構意在捕捉技術上靈活的方案，這個方案可以覆蓋上個月我們定義出來的系統需求。不論是向前看（對于設計）還是向后看（對于需求），架構團隊都將承受巨大的壓力。 Rational Rose 的集成開發環境通過讓我們能夠做以下的事情簡化了這個挑戰：

• 使用 SoDA 產生文檔以答應架構和設計元素的分發，簡化了檢查并保持每個人都有一致的當前遠景。
• 從場景直接更新類的簽名（方法和屬性），以使我們不必回到類的說明中添加缺少的方法。
• 為自動化的任務比如產生類的骨架、檢查模型的命名習慣和測試模型的完整性和有效性生成 RoseScripts （可以通過訪問 Tools 菜單得到）。
• 使用 Rose 的 RUP 模板，提供一個附帶 RUP 指南的模型框架。
• 在 Rose 中從提供的 J2EE 類框架中拖出類。
• 用 Rose 的”單元控制“特性將模型分解成為能夠被團隊進行版本控制和并行工作的片斷。

注重，因為我們在過去的項目中創建的系統與目前這個系統類似，因此假如我們引用一些參考架構，我們的架構將會從中受益。然而，我們不能在已存在的包或者設計模式中找到任何可重用的機會，因此我們只是引用了已存在系統中可能會在將來用到的思想和類。

從用例到設計類的轉化
從用例到設計類的轉化過程是緩慢的，需要進行多次的迭代。這牽扯到分析人員和設計人員，因為我們有很少的既可以舒適的與客戶討論業務領域又可以使用特定的工具進行分析、細化設計產物的人員。

這個活動的目標

有時將需求直接的轉換成代碼是誘人的。實際上，我們在以前的項目中就是這樣做的（因為我們有非常具體的需求說明），我們在我們對項目的理解上非常自信。這樣就產生了一個錯誤。需求被遺漏，范圍很難被跟蹤，并且大量的工作和返工是無用的。使用設計模型來連接在需求和代碼之間的鴻溝是重要的；設計模型可以在開發和測試之前很久捕捉錯誤和有問題的假設。

在從用例向設計類轉化的過程中，我們希望能夠實現：

• 將分析小組的知識傳授給工程團隊。
• 識別能夠滿足所有需求的技術方案 — 或者，什么地方不是可能的，識別與技術方案沖突的需求，并確定是否他們是重要的或者被改變或者被刪除。
• 識別能夠幫助確定團隊結構、架構層次和對于購買軟件的候選的接口。
• 指定技術方案的細節并開始計劃如何在團隊之中分配工作。
• 基于設計模型的細化時間進行計劃和預算的預估。
• 分配類到平臺、產品和私有代碼。
• 為了反饋和同步的目的，生成軟件架構文檔，軟件架構文檔能夠被分發到內部和外部的團隊成員。

實現穩定的設計

從用例和分析類到設計和設計類的轉化是不可避免的模糊的。在我們能夠擁有我們感到滿足的設計之前，我們需要做大量的工作。圖 1 顯示了我們以我們的方法定義一個穩定的設計的主要活動。

前面的文章部分討論了多數的在圖 1 中作為”架構“預備的活動和產物（非凡是 SOW 需求、用例、業務對象模型和分析類）。此外，這些其他的活動對設計工作也是重要的：

• 確定包的結構
• 建模數據（創建數據庫計劃）
• 創建原型和屏幕模擬

這些將在接下來的部分連同如何處理新的和改變的需求一起被討論。

打包和子系統結構

在開始考慮設計類之前，整個團隊要對一個良好的包結構達成一致同意。不管我們最后的決定是什么，它都應該成為設計過程中的指導方針，所有團隊成員都要遵守這個指導方針。

包結構的選擇