❶ 基於構件應用開發的優點有哪些
構件的最大優點是重用，軟體之所以那麼難做，就是難以重用。這方面硬體要好得多，硬體容易重用，CPU、存儲器、硬碟、光碟機、顯示器等等都可以重用，將它們裝配在一起就成了一台新計算機。軟體就很難達到這樣的重用程度，構件的出現是一個進步
另外補充一下，通過一些特殊的處理，如dll動態鏈接庫的應用，提高了程序的執行效率，即：當需要某部分功能時才載入某個dll庫，使程序具備了比較好的伸縮和可擴展性，當某個功能發生變動時，只需要更新相應的dll文件即可
❷ 基於構件的軟體開發包括哪些要素，其核心是什麼
與傳統的軟體開發方式相比，基於構件的軟體開發方法有什麼突破呢？ 一、體系結構 軟體體系結構代表了系統公共的高層次的抽象，它是系統設計成敗的關鍵。其設計的核心是能否使用重復的體系模式。傳 統的應用系統體系結構從基於主機的集中式框架，到在網路的客戶端上通過網路訪問伺服器的框架，都不能適應目前企業所處的商業環境，原因是： 企業過分地依賴於某個供應商的軟體和硬體產品。這種單一供應商使得企業難以利用計算供應商的免費市場，將計算基礎設施的重要決定交給第三方處理，這顯然不利於企業在合作夥伴之間共享信息。 不能適應遠程訪問的分布式、多層次異構系統。 封裝的應用系統在出現某種組織需要時，難以用定製來維護系統，從而難以滿足多變的需求。 不能實現分析、設計核心功能重用，最多隻能實現代碼重用。 如今，應用系統已經發展成為在Intranet和Internet上的各種客戶端可遠程訪問的分布式、多層次異構系統。CBSD為開發這樣的應用系統提供了新的系統體系結構。它是標準定義的、分布式、模塊化結構，使應用系統可分成幾個獨立部分開發，可用增量方式開發。 這樣的體系結構實現了CBSD的以下幾點目標: 能夠通過內部開發的、第三方提供的或市場上購買的現有構件，來集成和定製應用軟體系統。 鼓勵在各種應用系統中重用核心功能,努力實現分析、設計的重用。 系統都應具有靈活方便的升級和系統模塊的更新維護能力。 封裝最好的實踐案例，並使其在商業條件改變的情況下，還能夠被採用，並能保留已有資源。 由此看出,CDSD從系統高層次的抽象上解決了復用性與異構互操作性，這正是分布式網路系統所希望解決的難題。 二、開發過程 傳統的軟體開發過程在重用元素、開發方法上都與CBSD有很大的不同。雖然面向對象技術促進了軟體重用，但是，只實現了類和類繼承的重用。在整個系統和類之間還存在很大的缺口。為填補這個缺口，人們曾想了許多方法，如系統體系結構、框架、設計模式等。 自從構件出現以來，軟體的重用才得到了根本改變。CBSD實現了分析、設計、類等多層次上的重用。圖1顯示了它的重用元素分層實現。在分析抽象層上，重用元素有子系統、類；在設計層上重用元素有系統體系結構、子系統體系結構、設計模式、框架、容器、構件、類庫、模板、抽象類等。 在軟體開發方法上，CBSD引導軟體開發從應用系統開發轉變為應用系統集成。建立一個應用系統需要重用很多已有的構件模塊，這些構件模塊可能是在不同的時間、由不同的人員開發的，並有各種不同的用途。在這種情況下，應用系統的開發過程就變成對構件介面、構件上下文以及框架環境一致性的逐漸探索過程。例如，在J2EE平台上，用EJB框架開發應用系統，主要工作是將應用邏輯,按session Bean、entity Bean設計開發,並利用JTS事務處理的服務實現應用系統。其主要難點是事務劃分、構件的部署與開發環境配置。概括地說，傳統的軟體開發過程是串列瀑布式、流水線的過程;而CBSD是並發進化式，不斷升級完善的過程。圖2顯示了它們的不同。 三、軟體方法學 軟體方法學是從各種不同角度、不同思路去認識軟體的本質。傳統的軟體方法學是從面向機器、面向數據、面向過程、面向功能、面向數據流、面向對象等不斷創新的觀點反映問題的本質。整個軟體的發展歷程使人們越來越認識到應按客觀世界規律去解決軟體方法學問題。直到面向對象方法的出現，才使軟體方法學邁進了一大步。但是，高層次上的重用、分布式異構互操作的難點還沒有解決。CBSD發展到今天，才在軟體方法學上為解決這個難題提供了機會。它把應用業務和實現分離，即邏輯與數據的分離，提供標准介面和框架，使軟體開發方法變成構件的組合。因此，軟體方法學是以介面為中心，面向行為的設計。圖3是其開發過程。 歸納起來，CBSD的軟體開發方法學應包括下面幾方面： 對構件有明確的定義。 基於構件的概念需要有構件的描述技術和規范，如UML、JavaBean、EJB、Servlet規范等。 開發應用系統必須按構件裁剪劃分組織，包括分配不同的角色。 有支持檢驗構件特性和生成文檔的工具，確保構件規范的實現和質量測試。 總之，傳統的軟體方法學從草稿自頂向下進行，對重用沒有提供更多的輔助。CBSD的軟體方法學要豐富得多，它是即插即用，基於體系結構，以介面為中心，將構件有機組合，它把自頂向下和自底向上方法結合起來進行開發。 四、開發組織機構 傳統軟體的開發組織一般由分析員、設計員、程序員和測試員組成。對一個小的應用系統來說，一個熟練的開發人員，可能兼顧以上多個角色。但對CBSD來說,因為構件開發與應用系統集成往往是分開進行的，因此整個開發過程由六個角色來完成，他們是: 構件開發者 也是構件供貨商，這些大多數是中間件構件提供(續致信網上一頁內容)者。 應用構件集成者 針對某應用領域將已有構件組合成更大的構件模塊或容器， 作為系統部署的基本單元。 應用系統部署者 將系統部署基本單元放入選定的平台環境或基本框架中，完成軟體定製的要求。 開發平台伺服器供應商 提供伺服器、操作系統和資料庫等基本軟體。 應用系統開發工具供應商 提供構件公共設施服務。 系統管理員 配置硬體、網路和操作系統，監督和維護應用系統者。 這六個角色的工作專業性很強，要兼顧成為多面手很不容易。目前已形成構件開放市場，而且還很火紅。這也是當今軟體人才大戰所遇的一個困惑。因此，在CBSD中，如何組織好開發隊伍尤為重要，必須按本企業所具備人才來組織。特別重要的是:開發初期必須選好標准框架，以及統一的開發指導方針，保證在整個開發過程中,各角色能隨時互相溝通。一般來說，CBSD的人員素質決定了構件的重用率。 五、構造方法 傳統應用軟體的構造是用白盒子方法，應用系統的實現全在代碼中，應用邏輯和數據粘結在一起。而CBSD 的構造是用白盒子和黑盒子相結合的方法。 基於構件的框架是用兩個概念來支持演變：第一個概念是構件有很強的性能介面，使構件邏輯功能和構件模型的實現都隱藏起來。這樣，只要介面相同，構件就可以被替換。 第二個概念是隱式調用，即在基於構件的框架中，從來不直接給構件的介面分配地址，只在識別構件用戶後才分配地址。因此，構件用戶只要了解介面要求和為構件介面提供的引用後的返回信息 (該引用可能是一個構件，也可能是一個構件代理。對構件用戶來說，構件代理就是構件，不用區分) 。 構件介面的信息並不存入構件內，而是存入構件倉庫或注冊處。這樣才能保證構件替換靈活，並很容易利用隱式調用去重新部署構件。由於構件的實現對用戶透明，因此也使構件能適應各種不同的個性化要求。為此，構件提供自檢和規范化兩個機制。自檢保證在不了解構件的具體實現時，就能獲得構件介面信息。例如，JavaBean提供的自檢機制是Reflection和BeanInfo， 通過Reflection 可直接獲得Bean構件的全部方法，通過BeanInfo可直接獲得構件的許多復雜信息。 規范化允許不訪問構件就可以修改它，如JavaBean提供的規范化是property sheet和customizer(定製器)。 通過property sheet提供一組簡單參數，修改Bean的屬性。復雜的修改由用戶通過定製器設置參數完成。
❸ 簡述基於構件的軟體開發的核心是什麼急急急！！！
與傳統的軟體開發方式相比，基於構件的 軟體開發方法 有什麼突破呢？ 一、體系結構 軟體體系結構 代表了系統公共的高層次的抽象，它是系統設計成敗的關鍵。其設計的核心是能否使用重復的體系模式。傳 統的應用 系統體系結構 從基於主機的集中式框架，到在網路的客戶端上通過網路訪問伺服器的框架，都不能適應目前企業所處的商業環境，原因是： 企業過分地依賴於某個供應商的軟體和硬體產品。這種單一供應商使得企業難以利用計算供應商的免費市場，將計算基礎設施的重要決定交給第三方處理，這顯然不利於企業在合作夥伴之間共享信息。 不能適應遠程訪問的分布式、多層次異構系統。 封裝的應用系統在出現某種組織需要時，難以用定製來維護系統，從而難以滿足多變的需求。 不能實現分析、設計核心功能重用，最多隻能實現代碼重用。 如今，應用系統已經發展成為在Intranet和Internet上的各種客戶端可遠程訪問的分布式、多層次異構系統。CBSD為開發這樣的應用系統提供了新的 系統體系結構 。它是標準定義的、分布式、模塊化結構，使應用系統可分成幾個獨立部分開發，可用增量方式開發。 這樣的體系結構實現了CBSD的以下幾點目標: 能夠通過內部開發的、第三方提供的或市場上購買的現有構件，來集成和定製應用軟體系統。 鼓勵在各種應用系統中重用核心功能,努力實現分析、設計的重用。 系統都應具有靈活方便的升級和系統模塊的更新維護能力。 封裝最好的實踐案例，並使其在商業條件改變的情況下，還能夠被採用，並能保留已有資源。 由此看出,CDSD從系統高層次的抽象上解決了復用性與異構互操作性，這正是分布式網路系統所希望解決的難題。 二、開發過程 傳統的軟體開發過程在重用元素、開發方法上都與CBSD有很大的不同。雖然面向對象技術促進了軟體重用，但是，只實現了類和類繼承的重用。在整個系統和類之間還存在很大的缺口。為填補這個缺口，人們曾想了許多方法，如 系統體系結構 、框架、設計模式等。 自從構件出現以來，軟體的重用才得到了根本改變。CBSD實現了分析、設計、類等多層次上的重用。圖1顯示了它的重用元素分層實現。在分析抽象層上，重用元素有子系統、類；在設計層上重用元素有 系統體系結構 、子 系統體系結構 、設計模式、框架、容器、構件、類庫、模板、抽象類等。 在 軟體開發方法 上，CBSD引導軟體開發從應用系統開發轉變為應用系統集成。建立一個應用系統需要重用很多已有的構件模塊，這些構件模塊可能是在不同的時間、由不同的人員開發的，並有各種不同的用途。在這種情況下，應用系統的開發過程就變成對構件介面、構件上下文以及框架環境一致性的逐漸探索過程。例如，在J2EE平台上，用EJB框架開發應用系統，主要工作是將應用邏輯,按session Bean、entity Bean設計開發,並利用JTS事務處理的服務實現應用系統。其主要難點是事務劃分、構件的部署與開發環境配置。概括地說，傳統的軟體開發過程是串列瀑布式、流水線的過程;而CBSD是並發進化式，不斷升級完善的過程。圖2顯示了它們的不同。 三、軟體方法學 軟體方法學是從各種不同角度、不同思路去認識軟體的本質。傳統的軟體方法學是從面向機器、面向數據、面向過程、面向功能、面向數據流、面向對象等不斷創新的觀點反映問題的本質。整個軟體的發展歷程使人們越來越認識到應按客觀世界規律去解決軟體方法學問題。直到 面向對象方法 的出現，才使軟體方法學邁進了一大步。但是，高層次上的重用、分布式異構互操作的難點還沒有解決。CBSD發展到今天，才在軟體方法學上為解決這個難題提供了機會。它把應用業務和實現分離，即邏輯與數據的分離，提供標准介面和框架，使 軟體開發方法 變成構件的組合。因此，軟體方法學是以介面為中心，面向行為的設計。圖3是其開發過程。 歸納起來，CBSD的 軟體開發方法 學應包括下面幾方面： 對構件有明確的定義。 基於構件的概念需要有構件的描述技術和規范，如UML、JavaBean、EJB、Servlet規范等。 開發應用系統必須按構件裁剪劃分組織，包括分配不同的角色。 有支持檢驗構件特性和生成文檔的工具，確保構件規范的實現和質量測試。 總之，傳統的軟體方法學從草稿自頂向下進行，對重用沒有提供更多的輔助。CBSD的軟體方法學要豐富得多，它是即插即用，基於體系結構，以介面為中心，將構件有機組合，它把自頂向下和自底向上方法結合起來進行開發。 四、開發組織機構 傳統軟體的開發組織一般由分析員、設計員、程序員和測試員組成。對一個小的應用系統來說，一個熟練的開發人員，可能兼顧以上多個角色。但對CBSD來說,因為構件開發與應用系統集成往往是分開進行的，因此整個開發過程由六個角色來完成，他們是: 構件開發者 也是構件供貨商，這些大多數是中間件構件提供(續致信網上一頁內容)者。 應用構件集成者 針對某應用領域將已有構件組合成更大的構件模塊或容器， 作為系統部署的基本單元。 應用系統部署者 將系統部署基本單元放入選定的平台環境或基本框架中，完成軟體定製的要求。 開發平台伺服器供應商 提供伺服器、 操作系統 和資料庫等基本軟體。 應用系統開發工具供應商 提供構件公共設施服務。 系統管理員 配置硬體、網路和 操作系統 ，監督和維護應用系統者。 這六個角色的工作專業性很強，要兼顧成為多面手很不容易。目前已形成構件開放市場，而且還很火紅。這也是當今軟體人才大戰所遇的一個困惑。因此，在CBSD中，如何組織好開發隊伍尤為重要，必須按本企業所具備人才來組織。特別重要的是:開發初期必須選好標准框架，以及統一的開發指導方針，保證在整個開發過程中,各角色能隨時互相溝通。一般來說，CBSD的人員素質決定了構件的重用率。 五、構造方法 傳統應用軟體的構造是用白盒子方法，應用系統的實現全在代碼中，應用邏輯和數據粘結在一起。而CBSD 的構造是用白盒子和黑盒子相結合的方法。 基於構件的框架是用兩個概念來支持演變：第一個概念是構件有很強的性能介面，使構件邏輯功能和構件模型的實現都隱藏起來。這樣，只要介面相同，構件就可以被替換。 第二個概念是隱式調用，即在基於構件的框架中，從來不直接給構件的介面分配地址，只在識別構件用戶後才分配地址。因此，構件用戶只要了解介面要求和為構件介面提供的引用後的返回信息 (該引用可能是一個構件，也可能是一個構件代理。對構件用戶來說，構件代理就是構件，不用區分) 。 構件介面的信息並不存入構件內，而是存入構件倉庫或注冊處。這樣才能保證構件替換靈活，並很容易利用隱式調用去重新部署構件。由於構件的實現對用戶透明，因此也使構件能適應各種不同的個性化要求。為此，構件提供自檢和規范化兩個機制。自檢保證在不了解構件的具體實現時，就能獲得構件介面信息。例如，JavaBean提供的自檢機制是Reflection和BeanInfo， 通過Reflection 可直接獲得Bean構件的全部方法，通過BeanInfo可直接獲得構件的許多復雜信息。 規范化允許不訪問構件就可以修改它，如JavaBean提供的規范化是property sheet和customizer(定製器)。 通過property sheet提供一組簡單參數，修改Bean的屬性。
❹ 什麼叫基於構件的實現
是一種基於分布對象技術、強調通過可復用構件設計與構造軟體系統的軟體復用途徑。基於構件的軟體系統中的構件可以是COTS（Commercial-Off-the-Shelf）構件，也可以是通過其它途徑獲得的構件（如自行開發）。這種技術體現了「購買而不是重新構造」的哲學，將軟體開發的重點從程序編寫轉移到了基於已有構件的組裝，以更快地構造系統，減輕用來支持和升級大型系統所需要的維護負擔 ，從而降低軟體開發的費用。
❺ 《軟體工程》高手請進
從日益注重的信息化 科學化 智能化 電子政務 電子商務 物流配送等等
現代企業應具備 切被大家認為改具備的方面著手 抓重點
管理學你改有課本吧
❻ 基於構件的軟體開發過程由什麼和什麼兩個並行的活動組成
軟體體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組組合連接起來。這一定義注重區分處理構件、數據構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。（1）結構模型這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，並力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是體系結構描述語言。管道/過濾器風格的體系結構（2）框架模型框架模型與結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。（3）動態模型動態模型是對結構或框架模型的補充，研究系統的"大顆粒"的行為性質。例如，描述系統的重新配置或演化。動態可能指系統總體結構的配置、建立或拆除通信通道或計算的過程。這類系統常是激勵型的。（4）過程模型過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程腳本的結果。（5）功能模型該模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。它可以看作是一種特殊的框架模型。這5種模型各有所長，也許將5種模型有機地統一在一起，形成一個完整的模型來刻畫軟體體系結構更合適。例如，Kruchten在1995年提出了一個"4+1"的視角模型。"4+1"模型從5個不同的視角包括邏輯視角、過程視角、物理視角、開發視角和場景視角來描述軟體體系結構。每一個視角只關心系統的一個側面，5個視角結合在一起才能夠反映系統的軟體體系結構的全部內容。
❼ 解釋為什麼基於構件的軟體開發提高了軟體開發的生產效率
摘要
基於構件的軟體復用和開發被認為是提高軟體開發效率和質量的有效途徑,並在分布式系統中得到了廣泛的應用.但是,目前的軟體構件技術主要還是著眼於構件實現模型和運行時互操作,缺乏一套系統的方法以指導整個開發過程.近年來,以構件為基本單元的軟體體系結構研究取得了較大的發展.它通過對軟體系統整體結構和特性的描述,為面向構件的軟體開發提供了一個自頂向下的途徑.介紹了一種以軟體體系結構為指導,面向構件的軟體開發方法,試圖為基於構件的軟體復用提供一種有效的解決方案.這種方法主要是將軟體體系結構引入到軟體開發的各個階段,作為系統開發的藍圖,利用工具支持的自動轉換機制縮小從高層設計到實現的距離,而後在構件平台的運行支持下實現自動的系統組裝生成.
❽ 基於構件的軟體開發包括哪些要素
與傳統的軟體開發方式相比，基於構件的軟體開發方法有什麼突破呢？
一、體系結構
軟體體系結構代表了系統公共的高層次的抽象，它是系統設計成敗的關鍵。其設計的核心是能否使用重復的體系模式。傳統的應用系統體系結構從基於主機的集中式框架，到在網路的客戶端上通過網路訪問伺服器的框架，都不能適應目前企業所處的商業環境，原因是：
企業過分地依賴於某個供應商的軟體和硬體產品。這種單一供應商使得企業難以利用計算供應商的免費市場，將計算基礎設施的重要決定交給第三方處理，這顯然不利於企業在合作夥伴之間共享信息。
不能適應遠程訪問的分布式、多層次異構系統。
封裝的應用系統在出現某種組織需要時，難以用定製來維護系統，從而難以滿足多變的需求。
不能實現分析、設計核心功能重用，最多隻能實現代碼重用。
如今，應用系統已經發展成為在Intranet和Internet上的各種客戶端可遠程訪問的分布式、多層次異構系統。CBSD為開發這樣的應用系統提供
了新的系統體系結構。它是標準定義的、分布式、模塊化結構，使應用系統可分成幾個獨立部分開發，可用增量方式開發。
這樣的體系結構實現了CBSD的以下幾點目標:
能夠通過內部開發的、第三方提供的或市場上購買的現有構件，來集成和定製應用軟體系統。
鼓勵在各種應用系統中重用核心功能,努力實現分析、設計的重用。
系統都應具有靈活方便的升級和系統模塊的更新維護能力。
封裝最好的實踐案例，並使其在商業條件改變的情況下，還能夠被採用，並能保留已有資源。
由此看出,CDSD從系統高層次的抽象上解決了復用性與異構互操作性，這正是分布式網路系統所希望解決的難題。
二、開發過程
傳統的軟體開發過程在重用元素、開發方法上都與CBSD有很大的不同。雖然面向對象技術促進了軟體重用，但是，只實現了類和類繼承的重用。在整個系統和類之間還存在很大的缺口。為填補這個缺口，人們曾想了許多方法，如系統體系結構、框架、設計模式等。
自從構件出現以來，軟體的重用才得到了根本改變。CBSD實現了分析、設計、類等多層次上的重用。圖1顯示了它的重用元素分層實現。在分析抽象層上，重用
元素有子系統、類；在設計層上重用元素有系統體系結構、子系統體系結構、設計模式、框架、容器、構件、類庫、模板、抽象類等。
在軟體開發方法上，CBSD引導軟體開發從應用系統開發轉變為應用系統集成。建立一個應用系統需要重用很多已有的構件模塊，這些構件模塊可能是在不同的時
間、由不同的人員開發的，並有各種不同的用途。在這種情況下，應用系統的開發過程就變成對構件介面、構件上下文以及框架環境一致性的逐漸探索過程。例如，
在J2EE平台上，用EJB框架開發應用系統，主要工作是將應用邏輯,按session Bean、entity
Bean設計開發,並利用JTS事務處理的服務實現應用系統。其主要難點是事務劃分、構件的部署與開發環境配置。概括地說，傳統的軟體開發過程是串列瀑布
式、流水線的過程;而CBSD是並發進化式，不斷升級完善的過程。圖2顯示了它們的不同。
三、軟體方法學
軟體方法學是從各種不同角度、不同思路去認識軟體的本質。傳統的軟體方法學是從面向機器、面向數據、面向過程、面向功能、面向數據流、面向對象等不斷創新
的觀點反映問題的本質。整個軟體的發展歷程使人們越來越認識到應按客觀世界規律去解決軟體方法學問題。直到面向對象方法的出現，才使軟體方法學邁進了一大
步。但是，高層次上的重用、分布式異構互操作的難點還沒有解決。CBSD發展到今天，才在軟體方法學上為解決這個難題提供了機會。它把應用業務和實現分
離，即邏輯與數據的分離，提供標准介面和框架，使軟體開發方法變成構件的組合。因此，軟體方法學是以介面為中心，面向行為的設計。圖3是其開發過程。
歸納起來，CBSD的軟體開發方法學應包括下面幾方面：
對構件有明確的定義。
基於構件的概念需要有構件的描述技術和規范，如UML、JavaBean、EJB、Servlet規范等。
開發應用系統必須按構件裁剪劃分組織，包括分配不同的角色。
有支持檢驗構件特性和生成文檔的工具，確保構件規范的實現和質量測試。
總之，傳統的軟體方法學從草稿自頂向下進行，對重用沒有提供更多的輔助。CBSD的軟體方法學要豐富得多，它是即插即用，基於體系結構，以介面為中心，將構件有機組合，它把自頂向下和自底向上方法結合起來進行開發。
四、開發組織機構
傳統軟體的開發組織一般由分析員、設計員、程序員和測試員組成。對一個小的應用系統來說，一個熟練的開發人員，可能兼顧以上多個角色。但對CBSD來說,因為構件開發與應用系統集成往往是分開進行的，因此整個開發過程由六個角色來完成，他們是:
構件開發者 也是構件供貨商，這些大多數是中間件構件提供者。
應用構件集成者 針對某應用領域將已有構件組合成更大的構件模塊或容器， 作為系統部署的基本單元。
應用系統部署者 將系統部署基本單元放入選定的平台環境或基本框架中，完成軟體定製的要求。
開發平台伺服器供應商 提供伺服器、操作系統和資料庫等基本軟體。
應用系統開發工具供應商 提供構件公共設施服務。
系統管理員 配置硬體、網路和操作系統，監督和維護應用系統者。
這六個角色的工作專業性很強，要兼顧成為多面手很不容易。目前已形成構件開放市場，而且還很火紅。這也是當今軟體人才大戰所遇的
一個困惑。因此，在CBSD中，如何組織好開發隊伍尤為重要，必須按本企業所具備人才來組織。特別重要的是:開發初期必須選好標准框架，以及統一的開發指
導方針，保證在整個開發過程中,各角色能隨時互相溝通。一般來說，CBSD的人員素質決定了構件的重用率。
五、構造方法
傳統應用軟體的構造是用白盒子方法，應用系統的實現全在代碼中，應用邏輯和數據粘結在一起。而CBSD 的構造是用白盒子和黑盒子相結合的方法。 基於構件的框架是用兩個概念來支持演變：第一個概念是構件有很強的性能介面，使構件邏輯功能和構件模型的實現都隱藏起來。這樣，只要介面相同，構件就可以被替換。
第二個概念是隱式調用，即在基於構件的框
架中，從來不直接給構件的介面分配地址，只在識別構件用戶後才分配地址。因此，構件用戶只要了解介面要求和為構件介面提供的引用後的返回信息
(該引用可能是一個構件，也可能是一個構件代理。對構件用戶來說，構件代理就是構件，不用區分) 。
構件介面的信息並不存入構件內，而是存入構件倉庫或注冊處。這樣才能保證構件替換靈活，並很容易利用隱式調用去重新部署構件。由於構件的實現對用戶透明，
因此也使構件能適應各種不同的個性化要求。為此，構件提供自檢和規范化兩個機制。自檢保證在不了解構件的具體實現時，就能獲得構件介面信息。例
如，JavaBean提供的自檢機制是Reflection和BeanInfo， 通過Reflection
可直接獲得Bean構件的全部方法，通過BeanInfo可直接獲得構件的許多復雜信息。
規范化允許不訪問構件就可以修改它，如JavaBean提供的規范化是property sheet和customizer(定製器)。 通過property sheet提供一組簡單參數，修改Bean的屬性。復雜的修改由用戶通過定製器設置參數完成。
❾ 基於構件的軟體開發過程與傳統的過程有什麼不同
不是的，您理解錯了，計劃，分析等步驟幾乎不變的，所謂基於構件只得是軟體的開發過程，就是說以前編寫程序是逐行的，可是現在可以基於控制項了，不用重復勞動了，比如這塊都需要打開文件這個模塊，那麼直接調用寫好的控制項就可以了，而不需要再重新寫這部分代碼。和軟體的發布，分析，都沒有關系的