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