其設計的核心是能否使用重復的系統模式。
傳統的應用系統架構，從基於主機的集中式框架，到在網絡客戶端訪問服務器的框架，已經不能適應企業當前的業務環境，因為企業過於依賴某個供應商的軟硬件產品。
這種單壹的供應商使得企業很難利用計算供應商的自由市場，將計算基礎設施的重要決策交給第三方，這顯然不利於企業在合作夥伴之間享受信息。
無法適應遠程訪問的分布式、多級異構系統
當組織需要時，很難通過定制來維護打包的應用系統，因此很難滿足不斷變化的需求。
分析和設計的核心功能不能復用，最多只能復用代碼。
如今，應用系統已經發展成為壹個分布式的、多層次的異構系統，各種客戶端都可以在Intranet和Internet上遠程訪問。
CBSD為開發這樣壹個應用系統提供了壹個新的系統架構。
它是壹種標準定義的、分布式的、模塊化的結構，因此應用系統可以分成幾個獨立的部分，並以增量的方式開發。
這種架構實現了CBSD的以下目標:它可以通過內部開發、第三方提供或在市場上購買的現有組件來集成和定制應用軟件系統。
鼓勵各種應用系統中核心功能的重用，努力實現分析和設計的重用。
系統應具有靈活方便的升級，以及更新和維護系統模塊的能力。
封裝最佳實踐案例，使它們能夠在業務條件變化時被采用，並保留現有資源。
可以看出，CDSD從系統的高層抽象上解決了復用性和異構互操作性的問題，這也正是分布式網絡系統希望解決的問題。
二、開發流程傳統的軟件開發流程在復用元素和開發方法上與CBSD有很大的不同。
面向對象技術雖然促進了軟件復用，但只是實現了類的復用和類的繼承。
整個體系和班級還是有很大差距的。
為了填補這個空白，人們想了很多方法，比如系統架構、框架、設計模式等等。
自從組件的出現，軟件的復用性得到了根本的改變。
CBSD實現了分析、設計、類的多層次復用。
圖1顯示了重用元素的分層實現。
在分析抽象層上，復用元素包括子系統和類；設計層的復用元素包括系統架構、子系統架構、設計模式、框架、容器、組件、類庫、模板、抽象類等等。
在軟件開發方法方面，CBSD指導軟件開發從應用系統開發到應用系統集成。
構建壹個應用系統需要重用很多已有的組件模塊，這些組件模塊可能在不同的時間由不同的人開發，有不同的用途。
在這種情況下，應用系統的開發過程就變成了壹個逐步探索組件接口、組件上下文和框架環境壹致性的過程。
比如在J2EE平臺上，使用EJB框架開發壹個應用系統，主要工作是根據sessionBean和entityBean設計開發應用邏輯，使用JTS事務服務實現應用系統。
主要難點是事務劃分、組件部署和開發環境配置。
壹般來說，傳統的軟件開發過程是壹個串行的瀑布和流水線過程；而CBSD是壹個並行進化、不斷升級完善的過程。
圖2顯示了它們的區別。
三、軟件方法論軟件方法論就是從不同的角度、不同的思路去理解軟件的本質。
傳統的軟件方法學從面向機器、面向數據、面向過程、面向功能、面向數據流和面向對象的創新觀點反映了問題的本質。
整個軟件開發過程使人們越來越認識到，我們應該根據客觀世界的規律來解決軟件方法論問題。
直到面向對象方法的出現，軟件方法論才向前邁進了壹大步。
但是，高層重用和分布式異構互操作的困難還沒有解決。
直到今天，CBSD的發展提供了壹個在軟件方法論上解決這個問題的機會。
它將應用業務與實現分離，即邏輯和數據的分離，提供了標準的接口和框架，將軟件開發方法變成了組件的組合。
因此，軟件方法論是以界面為中心、面向行為的設計。
圖3是它的開發過程。
綜上所述，CBSD的軟件開發方法論應該包括以下幾個方面:清晰的組件定義。
基於組件的概念需要組件的描述技術和規範，如UML、JavaBean、EJB、Servlet規範等。
應用系統的開發必須按照組件切割來組織，包括分配不同的角色。
有工具支持對組件特性的檢查並生成文檔，以確保組件規格和質量測試的實現。
總之，傳統的軟件方法論是自頂向下進行的，並沒有為復用提供更多的幫助。
CBSD的軟件方法論要豐富得多。它是即插即用的，基於架構的，以接口為中心的，有機結合組件的。它結合了自頂向下和自底向上的開發方法。
四、開發組織傳統軟件的開發組織壹般由分析師、設計師、程序員和測試人員組成。
對於壹個小型的應用系統，壹個熟練的開發人員可能會考慮上述角色。
但對於CBSD來說，由於組件開發和應用系統集成往往是分開進行的，整個開發過程由六個角色來完成:組件開發者和組件供應商，其中大部分是中間件組件提供商(繼續發函互聯網壹頁)。
應用組件集成商將現有的組件組合成更大的組件模塊或容器，用於某個應用領域，作為系統部署的基本單元。
應用系統部署人員將系統部署的基本單元放入選定的平臺環境或基本框架中，以滿足軟件定制的需求。
開發平臺服務器廠商提供服務器、操作系統、數據庫等基礎軟件。
應用系統開發工具供應商提供組件公共設施服務。
系統管理員配置硬件、網絡和操作系統，並監督和維護應用系統。
這六個角色的工作都很專業，同時多才多藝也不容易。
目前已經形成了壹個開放的組件市場，而且還是很火熱的。
這也是當今軟件人才大戰中的壹個謎題。
因此，在CBSD，如何組織開發團隊就顯得尤為重要，而且必須根據企業所擁有的人才來組織。
尤其重要的是，必須在開發的初始階段選擇標準框架和統壹的開發指南，以確保在整個開發過程中，所有角色可以隨時相互通信。
壹般來說，CBSD的人員素質決定了組件的復用率。
動詞 （verb的縮寫）構造方法傳統的應用軟件是用白盒法構造的，應用系統的實現都在代碼中，應用邏輯和數據是綁定在壹起的。
CBSD的結構是白盒和黑盒的結合。
基於組件的框架用兩個概念支持演化:第壹個概念是組件具有強性能接口，隱藏了組件的邏輯功能和組件模型的實現。
這樣，只要接口相同，就可以更換組件。
第二個概念是隱式調用，即在基於組件的框架中，從不直接給組件的接口分配地址，而是在標識組件的用戶後才分配。
因此，組件用戶只需要知道接口需求和引用後為組件接口提供的返回信息(引用可以是組件，也可以是組件代理)
對於組件用戶來說，組件代理就是組件，沒有區別)。
組件接口的信息不存儲在組件中，而是存儲在組件倉庫或註冊表中。
只有這樣才能保證組件替換的靈活性，並且很容易使用隱式調用來重新部署組件。
由於組件的實現對用戶是透明的，這也使得組件能夠適應各種個性化的需求。
因此，該組件提供了兩種機制:自檢和規範化。
自檢可以確保在不知道組件具體實現的情況下獲得組件接口信息。
比如JavaBean提供的自檢機制是Reflection和BeanInfo，通過它們可以直接獲取Bean組件的所有方法，通過BeanInfo可以直接獲取組件的很多復雜信息。
規範化允許您在不訪問組件的情況下修改組件。比如JavaBean提供的規範化就是propertysheet和customizer。
通過propertysheet提供壹組簡單的參數來修改Bean的屬性。