4)服務分配及組件規范
如先前所述,我們通過將流程分解合并及對現有系統的分析來確定所有需要的服務。在這一步中,我們確保所有已確定的服務都有一個起點,它們都可以被業務流程及支持的組件追蹤到。
在這個過程中,我們進一步提煉并重構了候選服務,按照它們與邏輯業務組件的調整。最終,我們確定了業務應用程序服務的有限集,并將它們映射到提供這些服務的實現和管理的業務組件中。隨后,我們擴展了邏輯組件的規范使其包含分配的服務。
圖 7. 組件的服務分配
在這一階段,我們開發了實際平臺、產品和具備獨立供應商的以零售為中心的由邏輯 CBM 功能組件(可以被看作 CBM 零售組件模型的擴展)分類的服務的清單。
5)構造企業組件
在這一步中,我們分析并構建了所有選定的 COTS POS 應用程序組件、客戶端遺留應用程序和數據系統,從當前或今后系統的上下文中啟動并保持與所選的 CBM 邏輯組件的協調。我們稱那些技術組件為子系統。技術子系統是現有的客戶端企業系統或遺留系統,由供應商的產品或伙伴系統、或新確定的用于消除 COTS 產品性能與客戶端需求之間的障礙的應用程序封裝。該確定的 CBM 組件被映射到那些基于功能匹配的技術子系統中。
此外,我們將應用程序集成模式(流程集成及協作)應用到構建集成組件中。我們采用了企業服務總線(Enterprise Service Bus,ESB)模式來為所有應用程序提供統一的集成層。圖 8 描述了高級集成系統的視圖。
圖 8. 體系結構:系統視圖
6)確定及構建技術子系統
如同我們前面所討論的一樣,SoT 的關鍵決策之一是使用 COTS POS 應用程序組件并將對這些 COTS 產品和客戶端遺留系統的更改降到最小;谝惶坠餐_發的選擇標準,我們必須選擇一些 COTS 產品。此外,為了滿足標準業務的需求,我們必須定制 COTS 產品并設計開發一些新的應用程序組件。
在這一步中,我們采用從下至上的解決方案來分析如何構建 COTS 產品、新的應用程序組件和客戶端遺留系統,來幫助邏輯組件和服務的設計向物理實現的轉變。為了簡化,我們使用現有的 COTS 應用程序組件作為供應商封裝的解決方案和從新的應用程序中創建的新技術子系統。圖 9 展示了我們確定的技術子系統。
圖 9. 技術子系統確定
7)將功能組件映射到技術子系統中
在這一步中,我們將每個邏輯業務組件都映射到體系結構中的技術子系統中。下面是為了達到該目的而設計的電子表格的實例:
圖 10. 技術組件的服務分配
為了擴展 CBM,我們創建了下面的映射電子表格來說明 CBM 邏輯零售組件如何能被映射到確定的技術子系統中。
圖 11. 將 CBM 邏輯零售組件映射到確定的技術子系統中
文章來源于領測軟件測試網 http://www.kjueaiud.com/