4、 物件設計
在架構規範的指導下，設計從技術上擴充套件和修改了分析結果。雖然分析階段的領域物件建模應該與技術細節無關，但是物件設計完全依賴於技術因素，包括平台、語 言的型別和架構開發階段選擇的**商。分析時，抬頭望著星星，但在設計階段，則要腳踏實地。理論上，為了維持業務物件的基本屬性和行為，除非絕對必要，不 應該破壞它們。
在架構結果的指導下，詳細設計工作應該說明所有類的規格，包括必須實現的屬性、它們的詳細介面和偽**或操作的純文字描述。規格說明應該足夠詳細使得和模 型圖結合時，它可以提供所有必須的編碼資訊。在許多自動化軟體生產過程中，我們可以從物件導向圖生成**框架。圖5和6 說明了對一些領域物件的高層和詳 細設計物件。注意樁（stub）和框架（skeleton）在圖中經常是不可見的，因為它們對設計人員和程式設計員來說是透明的。我將它們包括在圖6中以說明 ejb的基礎部分。
圖6 物件設計模型：訂單ejb詳細設計
在完成了詳細物件設計後，還需要完成領域物件的物件-關係對映。原因是雖然物件導向方法學現在非常流行，但是大多數流行且成熟的持續性儲存卻是關係型的。 另外，在許多情況下，客戶的it基礎設施已經反映了對商業rdbms**商的投資和偏愛。所以，將領域物件轉換成關係模型或資料庫表是非常重要的。雖然有 許多容器管理的持續性工具，但它們不能取代好的關聯式資料庫設計。
5、 實現
在良好的架構和詳細設計條件下，實現應該是乙個明確的任務。另外，因為我們設計和實現架構原型階段的縱向聯合部分，所以實現階段應該更沒有什麼值得驚訝 的。在許多組織中，開發者經常過早地到達實現階段。尤其當管理者盯著開發人員確保在編碼，而不是做他們認為在浪費公司時間的其他事情時，這種情況變得更加 嚴重。
結果，不再花數小時或數天繪出uml草圖，而是通常在髮費數週或數月編碼的同時測試自己的想法。由於在這種情況下，所有地架構決定和設計都是在編碼階段做出來的，所以經常過了數月後才發現開發的方向出錯了。
6、 驗證
驗證包括測試驗證系統按設計要求執行並滿足需求。驗證過程發生在整個開發生命週期的開發和產品環境中。單元測試、整合測試和使用者測試本身就是非常重要的主題。
7、 裝配和部署
構件裝配和解決方案部署在j2ee開發中特別重要。開發和產品環境可能非常不同。如果ejb在系統中，你需要使用**商特定的工具得到容器自動生成的類， 因為，正如我以前指出的，web和應用程式構件配置對不同的**商來說是不同的。你也必須考慮要部署的系統是否含有**商特定**實現。在可擴充套件架構中， 系統結構應該是穩定的但也應該在不影響整個系統的條件下支援新或老構件的增量部署。
8、 執行和維護
在最後階段，應用程式到了使用者手中，你必須給他們提供培訓和文件。使用者會發現錯誤並可能要求新特性。你必須適當地改變管理過程來處理這些情況。你不必為了部署乙個新構件或取代老構件而關閉乙個正在執行的系統。
架構開發過程
知道了必須做出許多架構決定，因此我們必須為架構開發描繪乙個過程。對於乙個企業來說通常有許多應用專案，它們中的一些可能跨越數年，結果是系統演化包含 許多週期。在你的領域裡存在著許多跨越多個專案的通用需求。你應該不費力地在它的生命週期或其他專案中使用以前專案週期的可擴充套件且可重用的架構。為一系列 軟體應用提供同屬結構和行為的通用框架和可重用軟體架構是非常需要的。
如果是第乙個j2ee專案，架構必須做原型、測試、度量、分析並在迭代中進行推敲。藍圖提供了許多好的設計指導和實踐，寵物店示例程式可以作為乙個很好的 參考架構。最有效地快速、高質量發布好的解決方案的方法是接受和擴充套件藍圖參考架構並插入你自己的業務構件。你最後要做的就是改造車輪。
接受乙個參考架構
就我的理解，寵物店架構的精華是模型-檢視-控制和命令模式。你可以將這些模式應用到以web為中心和以ejb為中心的系統中。對於每個領域物件，檢視用 巢狀的jsp表示。控制器處理相關的業務事件，領域物件封裝業務邏輯、事物和安全。我們使用門戶servlet作為中心控制器接受和截獲所有使用者的動作。 它將業務事件分發給特定的呼叫領域物件改變持續狀態的領域物件控制器。依靠事件處理結果，控制器選擇下乙個要展現的檢視。下面是我們可以修改並在大多數 j2ee應用程式中使用的主要構件：
a、 mainservlet：門戶構件，web容器和框架之間的介面
b、 modelupdatelistener：獲得模型更新事件物件的介面
c、 modelupdatenotifier：當更新模型事件發生時通知偵聽器
d、 requestprocessor：處理所有從mainservlet來的請求。
e、 requesthandler：即插即用請求處理構件介面
g、 requesttoeventtranslator：中心請求處理器根據請求處理對映規則**即插即用請求處理構件的請求。將http請求轉換為業務事件
h、 estoreevent：業務事件
i、 shoppingclientcontrollerwebimpl：**ejb層門戶控制器
j、 screenflowmanager：控制螢幕流，選擇檢視
k、 modelupdatemanager：ejb層模型更新管理器，通知什麼模型由於事件發生了改變
l、 shoppingclientcontrollerejb：ejb層門戶，為ejb客戶提供遠端服務
m、 statemachine：中心事件處理器，根據狀態處理對映規則**即插即用處理構件的事件處理
n、 statehandler：ejb層狀態處理介面
擴充套件參考架構
雖然藍圖標例程式是乙個好的起點，但應該根據每個專案或領域修改它。設計模式是可重用的微體系結構，可以使用它擴充套件參考架構。提供了一組有用的j2ee模 式目錄的藍圖和23個"四人幫"模式都是非常不錯的資源。例如，如果想擴充套件參考架構支援工作流管理，你可以在部署或執行時動態地在中心控制器註冊事件處理 器。中心控制器會詢問每個註冊的事件處理器直到乙個處理器返回訊息表明到了命令鏈的末端。
插入你的業務構件
j2ee技術對每個人都是一樣的，但是不同的領域，我們要解決的問題是不同的。一旦建立了乙個基本的j2ee框架，必須實現一些用例來說明架構確實可以為 你的領域服務。可以通過選用捕獲系統關鍵功能的場景來實現，這些場景經常使用來展現關鍵的技術風險。從領域分析模型入手，可以象我們在圖5和6中那樣將領 域物件對映成高層和低層設計模型。實現低層設計模型並測試是否真正在工作。如果每件事都按計畫執行，那麼重新評估風險開始下乙個迭代，擴充套件要考慮的場景並 選擇更多的場景擴充套件架構的覆蓋範圍。經過幾次迭代後，原始的架構原型應該變得穩定。識別要購買的構件，要保留的遺留系統和怎樣將它們對接。下一步是軟體設 計，你可以使用設計指導中規定好的類似方法和過程繼續開發。
一步一步
我們使用乙個過程來將乙個複雜問題分解為較小的幾個問題，這使得我們可以更容易的理解和解決它們。在本文中，我們將j2ee開發分解為八個步驟，主要集中在架構和設計。我已經闡述了重要的架構並為架構決定提供了乙個過程。我也討論了j2ee架構師的角色和可交付產品。
學習使用這些步驟開發j2ee解決方案就象學習跳舞的步驟一樣。首先需要自覺並持之以恆地練習基本步驟。但是，一旦你對它們相當熟悉後，應該將它們放在一 起並將注意力更多地集中在規模、速度、流和特定上下文中每一步的節奏。但永遠不要讓乙個過程限制了創造性。而應該接受和擴充套件過程以滿足自己特殊需要。記 住，最終目的是提供滿足客戶需求的完整的j2ee解決方案。
J2EE專案架構最佳實踐
基於專案的最差實踐，可以總結出一套專案架構的最佳實踐原則以便今後的復用和改進。原則1.時間總是非常緊，需求總是在變化，技術問題總是層出不窮，千萬不要認為軟體工程的問題不會發生在規範的公司和專案。每次一定要根據自己所處的位置作出正確的評估，比如專案經理做評估要留出足夠的時間buffer，開發人員應當正...
J2EE專案架構最佳實踐
基於專案的最差實踐，可以總結出一套專案架構的最佳實踐原則以便今後的復用和改進。原則1.時間總是非常緊，需求總是在變化，技術問題總是層出不窮，千萬不要認為軟體工程的問題不會發生在規範的公司和專案。每次一定要根據自己所處的位置作出正確的評估，比如專案經理做評估要留出足夠的時間buffer，開發人員應當正...
j2ee自學心得
學習是一件快樂的事，學習是一件痛苦的事，它讓你能夠把學到的東西帶來財富，它也能讓你仁慈學到的東西帶來無用武之地 看書 當你買了一本新書的時候，不要瀑布式的往下看，這是傳統的學習方法，不適合 現代高科技社會的學習方法，尤其是電腦科學，為什麼以前的瀑布式軟體開發方法到 今天會失敗，因為瀑布式的方法很難看...