流行的軟體工程過程 Rational統一過程

rup提供了乙個給角色分配任務和責任的嚴格方法，在j2ee開發中使用rup出於以下三個原因：

rup以架構為中心；在將資源分配給全面開發之前，它先開發乙個可執行的架構原型。

up是迭代並基於構件的。

rup利用一門工業標準語言——uml，視覺化建模系統的架構和構件。

從8個方面來說明:

需求分析：需求分析描述系統應該做什麼或不應該做什麼使得開發者和客戶可以簽署乙份原始的商業合同。可以使用業務概念、領域術語、用例和使用者介面（ui）模型形成功能需求文件。

對於非功能需求，如效能和事務，可以在需求文件附件中詳細說明。根據參與專案深度的不同，確定在紙上還是使用html建造高層ui模型。

物件導向分析：人員構造問題領域模型：類、物件和互動。

分析應該與技術和實現細節無關，幷包含乙個理想的模型。

因為業務過程的改變比資訊科技的改變要慢得多，所以必須要維持乙個不含技術細節的純領域模型。

需求分析中得到主要概念，把這些概念建模為物件，並標識他們的關係，為開發架構，可以使用橫向聯合部分來設計物件，實現，測試來部署，橫向聯合部分,乙個rup概念，是指系統的一小部分，他的實現結果是包括前端ui，中間業務及後端資料的完整功能的小系統。

架構規格說明：經過需求分析以及物件導向後的領域問題後，

將工作集中在技術策略和架構上。架構是指所有構件組合定義系統的乙個藍圖：結構、介面和通訊機制。

架構可以分為：企業級架構，應用級架構

企業級架構：包括硬體和軟體基礎設施，網路部局，開發，測試，生產環境等，反映企業的長期投資。

構件組成：web瀏覽器客戶端，乙個http伺服器（web伺服器主表示層，業務邏輯構件），關係型資料庫主資料與資料邏輯。

你的系統架構型別依賴於：安全，效能和可靠性的需求，也依賴於客戶的財務狀況。

架構和設計完全不同，應用架構範圍包括，系統主要結構，架構設計模式，可增加構件的框架，主要考濾非功能性方面。

設計主要考濾的是業務用例. 物件設計在架構規範下進行，設計從技術擴充套件跟修改分析階段產生的領域物件模型，領域物件模型雖然與技術實現無關，

但依賴於技術因素，包括：平台，語言等等因素。

理論上，為了維持業務物件的基本屬性和行為，除非絕對必要，不應該破壞它們。在架構結果的指導下，詳細設計工作應該說明所有類的規格，包括必須實現的屬性、它們的詳細介面和偽**或操作的純文字描述。

規格說明應該足夠詳細使得和模型圖結合時，它可以提供所有必須的編碼資訊。

-------

物件設計模型：在完成物件設計的詳細設計後，還需要完成領域物件的物件-關係對映，將領域物件轉化為關係模型或物件的資料庫表是非常重要的。

實現：設計乙個規範的架構，跟編寫乙份詳細的高設計是非常重要的事情，不在需求分析定義物件模型，關係模型，對應的資料庫表，以後開發過程中的各種規範，極有可能使用開發後期經常的測試功能，甚至可能到最後才發現方向跟結構不合理。

驗證：裝配跟布暑：構件裝配和解決方案部署在j2ee開發中特別重要。

執行跟維護：用程式到了使用者手中，你必須給他們提供培訓和文件。

客戶可能對不足提出更改，我們的更改應該盡量不影響系統的執行，新增乙個新的構件或去掉乙個老的構掉，盡量不以關閉執行為前提。

軟體架構過程必須做許多架構決定，必須為架構開發描述乙個開發過程，在我們開發的多個專案中可能存在一些可通用的需求，在我們的專案週期中應該盡量使用以前專案所生成的成熟的可擴充套件，可重用的架構，為一系列軟體應用提供同屬結構和行為的通用框架和可重用軟體架構是非常需要的。

可以使用設計模式來擴充套件參考架構，提供一組j2ee模式目錄的藍圖及提從「四人幫」模式都是不錯的資源。一旦建立了乙個基本的j2ee框架，必須實現一些用例來說明架構確實可以為你的領域服務。可以通過選用捕獲系統關鍵功能的場景來實現，這些場景經常使用來展現關鍵的技術風險。

從領域分析模型入手，可以將領域物件對映成高層和低層設計模型。如果每件事都按計畫執行，那麼重新評估風險開始下乙個迭代，擴充套件要考慮的場景並選擇更多的場景擴充套件架構的覆蓋範圍。經過幾次迭代後，原始的架構原型應該變得穩定。識別要購買的構件，要保留的遺留系統和怎樣將它們對接。