步入J2EE架構和過程基礎教程（2）

2019-11-18 12:25:33

字體：大中小

來源：轉載

供稿：網友

　　4、對象設計
　　在架構規范的指導下，設計從技術上擴展和修改了分析結果。雖然分析階段的領域對象建模應該與技術細節無關，但是對象設計完全依靠于技術因素，包括平臺、語言的類型和架構開發階段選擇的供給商。分析時，抬頭望著星星，但在設計階段，則要腳踏實地。理論上，為了維持業務對象的基本屬性和行為，除非絕對必要，不應該破壞它們。
　　
　　在架構結果的指導下，具體設計工作應該說明所有類的規格，包括必須實現的屬性、它們的具體接口和偽代碼或操作的純文本描述。規格說明應該足夠具體使得和模型圖結合時，它可以提供所有必須的編碼信息。在許多自動化軟件生產過程中，我們可以從面向對象圖生成代碼框架。圖5和6 說明了對一些領域對象的高層和具體設計對象。注重樁（stub）和框架（skeleton）在圖中經常是不可見的，因為它們對設計人員和編程員來說是透明的。我將它們包括在圖6中以說明EJB的基礎部分。
　　
　　步入J2EE架構和過程基礎教程（2）

　　圖6 對象設計模型：訂單EJB具體設計
　　
　　在完成了具體對象設計后，還需要完成領域對象的對象-關系映射。原因是雖然面向對象方法學現在非常流行，但是大多數流行且成熟的持續性存儲卻是關系型的。另外，在許多情況下，客戶的IT基礎設施已經反映了對商業RDBMS供給商的投資和偏愛。所以，將領域對象轉換成關系模型或數據庫表是非常重要的。雖然有許多容器治理的持續性工具，但它們不能取代好的關系數據庫設計。
　　
　　5、實現
　　
　　在良好的架構和具體設計條件下，實現應該是一個明確的任務。另外，因為我們設計和實現架構原型階段的縱向聯合部分，所以實現階段應該更沒有什么值得驚奇的。在許多組織中，開發者經常過早地到達實現階段。尤其當治理者盯著開發人員確保在編碼，而不是做他們認為在浪費公司時間的其他事情時，這種情況變得更加嚴重。
　　
　　結果，不再花數小時或數天繪出UML草圖，而是通常在發費數周或數月編碼的同時測試自己的想法。由于在這種情況下，所有地架構決定和設計都是在編碼階段做出來的，所以經常過了數月后才發現開發的方向出錯了。
　　
　　6、驗證
　　
　　驗證包括測試驗證系統按設計要求運行并滿足需求。驗證過程發生在整個開發生命周期的開發和產品環境中。單元測試、集成測試和用戶測試本身就是非常重要的主題。
　　
　　7、裝配和部署
　　
　　構件裝配和解決方案部署在J2EE開發中非凡重要。開發和產品環境可能非常不同。假如EJB在系統中，你需要使用供給商特定的工具得到容器自動生成的類，因為，正如我以前指出的，Web和應用程序構件配置對不同的供給商來說是不同的。你也必須考慮要部署的系統是否含有供給商特定代碼實現。在可擴展架構中，系統結構應該是穩定的但也應該在不影響整個系統的條件下支持新或老構件的增量部署。
　　
　　8、運行和維護
　　
　　在最后階段，應用程序到了用戶手中，你必須給他們提供培訓和文檔。用戶會發現錯誤并可能要求新特性。你必須適當地改變治理過程來處理這些情況。你不必為了部署一個新構件或取代老構件而關閉一個正在運行的系統。
　　
　　架構開發過程
　　
　　知道了必須做出許多架構決定，因此我們必須為架構開發描繪一個過程。對于一個企業來說通常有許多應用項目，它們中的一些可能跨越數年，結果是系統演化包含許多周期。在你的領域里存在著許多跨越多個項目的通用需求。你應該不費力地在它的生命周期或其他項目中使用以前項目周期的可擴展且可重用的架構。為一系列軟件應用提供同屬結構和行為的通用框架和可重用軟件架構是非常需要的。
　　
　　假如是第一個J2EE項目，架構必須做原型、測試、度量、分析并在迭代中進行推敲。藍圖提供了許多好的設計指導和實踐，寵物店示例程序可以作為一個很好的參考架構。最有效地快速、高質量發布好的解決方案的方法是接受和擴展藍圖參考架構并插入你自己的業務構件。你最后要做的就是改造車輪。
　　
　　接受一個參考架構
　　
　　就我的理解，寵物店架構的精華是模型-視圖-控制和命令模式。你可以將這些模式應用到以Web為中心和以EJB為中心的系統中。對于每個領域對象，視圖用嵌套的jsp表示?？刂破魈幚硐嚓P的業務事件，領域對象封裝業務邏輯、事物和安全。我們使用門戶servlet作為中心控制器接受和截獲所有用戶的動作。它將業務事件分發給特定的調用領域對象改變持續狀態的領域對象控制器。依靠事件處理結果，控制器選擇下一個要展現的視圖。下面是我們可以修改并在大多數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解決方案。

上一篇：高手教您使用MIDP底層用戶接口API的方法

下一篇：詳解用J2EE架構企業級應用