基於構件的軟件開發

開發基於構件的軟件系統受到以下幾方面因素的影響：1、COTS構件質量的提高和種類的增加；2、要求降低系統開發和維護成本的經濟壓力；3、構件集成技術的出現；4、軟件開發組織內可以用於新系統開發的已有軟件製品的數量增加。

CBSD整個過程從需求開始，由開發團隊使用傳統的需求獲取技術建立系統的需求規約。在完成體系結構設計後，並不立即開始詳細設計，而是確定哪些部分可由構件組裝而成。此時開發人員面臨的設計決策包括“是否存在滿足某種需求的COTS 構件”，“是否存在滿足某種需求的內部開發的可複用構件”，“這些可用構件的接口與體系結構的設計是否匹配”等。對於那些無法通過已有構件滿足的需求，就只能採用傳統的或面向對象的軟件工程方法開發新構件。對於那些滿足需求的可用構件，開發人員通常需要進行如下活動：

（qualification）：通過接口以及其它約束判斷COTS 構件是否可在新系統中複用。構件鑑定分為發現和評估兩個階段。發現階段需要確定COTS 構件的各種屬性，如構件接口的功能性（構件能夠提供什麼服務）及其附加屬性（如，是否遵循某種標準）、構件的質量屬性（如，可靠性）等。構件發現難度較大，因為構件的屬性往往難以獲取、無法量化。評估階段根據COTS 構件屬性以及新系統的需求判斷構件是否可在系統中複用。評估方法常常涉及分析構件文檔、與構件已有用户交流經驗、甚至開發系統原型。構件鑑定有時還需要考慮非技術因素，如構件提供商的市場佔有率、構件開發商的過程成熟度等級等。

（adaptation）：獨立開發的可複用構件滿足不同的應用需求，並對運行上下文做出了某些假設。系統的軟件體系結構定義了系統中所有構件的設計規則、連接模式和交互模式。如果被複用的構件不符合目標系統的軟件體系結構就可能導致該構件無法正常工作，甚至影響整個系統的運行，這種情形稱為失配（mismatch）。調整構件使之滿足體系結構要求的行為就是構件適配。構件適配可通過白盒、灰盒或黑盒的方式對構件進行修改或配置。白盒方式允許直接修改構件源代碼；灰盒方式不允許直接修改構件源代碼，但提供了可修改構件行為的擴展語言或編程接口；黑盒方式是指調整那些只有可執行代碼且沒有任何擴展機制的構件。如果構件無法適配，就不得不尋找其它適合的構件。

構件組裝（composition）：構件必須通過某些良好定義的基礎設施才能組裝成目標系統。體系風格決定了構件之間連接或協調的機制，是構件組裝成功與否的關鍵因素之一。典型的體系風格包括黑板、消息總線、對象請求代理等。

構件更新（update）：基於構件的系統演化往往表現為構件的替換或增加，其關鍵在於如何充分測試新構件以保證其正確工作且不對其它構件的運行產生負面影響，對於由COTS 構件組裝而成的系統，其更新的工作往往由提供COTS 構件的第三方完成。