第 5 部分 ：架構與設計
Steven Franklin
軟件設計師和過程專家
2004 年 4 月
當這個正在進行的應用 RUP 和其他的 Rational 工具的 J2EE 樣例項目從用例轉換成架構和設計時（包括數據建模和構建測試設計假想的原型），這個項目已經進入了更加技術的階段了。
這個系列的第 5 部分首先檢查了一下項目的時間進度，然后當我們進入了架構、設計、數據建模和創建原型時，我們已經在下一個階段進行細化階段中了。
在第 5 部分演示的工具和技術：
產生或者被更新的產物：
項目的時間進度
在開始進行具體的架構和設計工作之前，讓我們來檢查一下 ASDI 項目的整體進度。就像你可以第 1 部分回想起來的，這個由多個部分組成的系列文章覆蓋了項目的第 1 個階段：以一系列需求、一個參考架構和代碼（理想的可重用的）為結果的概念的驗證。到目前為止，我們大概使用了整個第 1 階段預算的三分之一，但我們已經接近了項目時間進度的一半了。這是在我們的預料之中的，因為我們有意的讓進度稍微慢一點。分析和計劃活動總是以較慢的步伐移動，團隊應該在項目開始時逐步的將他們建立起來。
因為第 1 階段要求一個相關的結構化的和正式的概念的證據，我們將它作為一個小的項目處理，通過在演進的產品上進行測試和 QA（同級審查）來完成它。RUP 有一些用于開發概念證據的機制，基本在分析和設計工作流的執行架構的合成的活動中。我們正在進一步的將概念的證據轉化成可用的 beta 版產品。我們能夠將更多的功能、風險的降低和產品的成熟放到這個階段中，我們越多的將技能和知識用到系統的產品版本中，我們的客戶就越興奮。
這個接下來的一系列的任務將比之前的活動更加具有技術性。我們正很好的向架構。設計、數據建模和原型前進。在第 4 部分中我們討論了一些原型和評估如何進行我們的工具選擇；現在我們的原型的關注點在測試我們設想的需求、系統說明和設計上。
過渡到架構和設計
架構和設計活動是在 ASDI 項目中最令人愉快和具有創造力的任務。我們為我們將系統計劃的高效、安全和簡單優雅而自豪。技術方案的遠景在多次令人興奮的會面、自由討論和技術探索中最終形產生了。
簡單的講，架構意在捕捉技術上靈活的方案，這個方案可以覆蓋上個月我們定義出來的系統需求。不論是向前看（對于設計）還是向后看（對于需求），架構團隊都將承受巨大的壓力。 Rational Rose 的集成開發環境通過讓我們能夠做以下的事情簡化了這個挑戰：
注重，因為我們在過去的項目中創建的系統與目前這個系統類似，因此假如我們引用一些參考架構，我們的架構將會從中受益。然而，我們不能在已存在的包或者設計模式中找到任何可重用的機會，因此我們只是引用了已存在系統中可能會在將來用到的思想和類。
從用例到設計類的轉化
從用例到設計類的轉化過程是緩慢的，需要進行多次的迭代。這牽扯到分析人員和設計人員，因為我們有很少的既可以舒適的與客戶討論業務領域又可以使用特定的工具進行分析、細化設計產物的人員。
這個活動的目標
有時將需求直接的轉換成代碼是誘人的。實際上，我們在以前的項目中就是這樣做的（因為我們有非常具體的需求說明），我們在我們對項目的理解上非常自信。這樣就產生了一個錯誤。需求被遺漏，范圍很難被跟蹤，并且大量的工作和返工是無用的。使用設計模型來連接在需求和代碼之間的鴻溝是重要的；設計模型可以在開發和測試之前很久捕捉錯誤和有問題的假設。
在從用例向設計類轉化的過程中，我們希望能夠實現：
實現穩定的設計
從用例和分析類到設計和設計類的轉化是不可避免的模糊的。在我們能夠擁有我們感到滿足的設計之前，我們需要做大量的工作。圖 1 顯示了我們以我們的方法定義一個穩定的設計的主要活動。
圖 1: 從用例模型到設計模型的轉化前面的文章部分討論了多數的在圖 1 中作為”架構“預備的活動和產物（非凡是 SOW 需求、用例、業務對象模型和分析類）。此外，這些其他的活動對設計工作也是重要的：
新聞熱點
疑難解答
