基本介紹
- 中文名：CBSE
- 外文名：component-based software engineering
基本信息,系統開發,領域工程,CBSE過程,基於組件開發,分類檢索組件,CBSE經濟學,
基本信息
Clements對CBSE有如下描述：
[CBSE]正在改變大型軟體系統被開發的方式。[CBSE]體現了Fred Brooks等人支持的“購買，而非建造”的思想。就像早期的子例程將程式設計師從思考細節中解放出來一樣，[CBSE]將考慮的重點從編程軟體移到組裝軟體系統。“實現”已經讓位給“集成”作為考慮的焦點。這樣做的基礎是假定在很多大型軟體系統中存在足夠多的共性，從而使得開發可復用軟體組件來滿足這些共性是值得的。
系統開發
從表面看，CBSE似乎類似於傳統的或面向對象的軟體工程。當軟體小組使用傳統的需求誘導技術建立了待建造系統的需求時，該過程開始，系統結構設計被建立，但是，並不是立即轉向更細節的設計任務，小組檢查需求以確定系統的什麼子集可以直接通過組裝而不是構造完成。也就是說，小組針對每個系統需求詢問如下問題：
l 是否存在商用成品組件（component off-the-shelf，COTS）可實現該需求？
l 是否存在內部開發的可復用組件可實現該需求？
l 可用組件的接口與待建系統兼容嗎？
小組試圖修改或去除那些不能用COTS和自有組件實現的系統需求。如果需求不能被修改或刪除，傳統的或面向對象的軟體工程方法被用於開發那些必須被開發以滿足需求的新組件。但是，對那些可被現存組件滿足的需求，採用不同的軟體工程活動：
l 組件合格性認證。系統需求和體系結構定義了所需的組件。可復用的組件（不管是COTS的還是自有的）通常是通過它們的接口特徵來標識的，即“被提供的服務，以及客戶訪問這些服務的方式”被作為組件接口的一部分而描述。但是，接口並不提供組件是否符合體系結構和需求的全面描述。軟體工程師必須通過一個發現和分析過程來認證每個組件的合格性。
l 組件適應性修改。軟體體系結構表示了由組件（功能性單元）、連線和協同構成的設計模式。在某些情形中，現存的可復用組件可能和體系結構的設計規則不匹配，這些組件必須被自適應以滿足體系結構的需要或被丟棄而被其它更合適的組件代替。
l 組件更新。當系統由COTS組件實現時，更新由於第三方的進入而變得複雜（即開發可復用組件的組織可能是在軟體工程組織的直接控制範圍之外）。
領域工程
CBSE過程
CBSE過程的刻畫：不僅標識候選的組件，還認證每個組件接口合格性、適應性修改組件以消除體系結構不匹配、組裝組件到選擇的體系結構風格中以及當系統需求變化時更新組件。
基於組件的軟體工程的工程模型強調並行的軌跡，其中領域工程和基於組件的開發並發地發生。領域工程完成一系列工作，以建立一組可以被其它軟體工程師復用的軟體結構，然後這些軟體結構被越過分隔領域工程和基於組件的開發的“邊界”傳送
圖3.1 CBSE過程
上圖是一個典型的過程模型，它顯然適應CBSE。領域工程創建套用領域的模型，該模型被用作在軟體工程流中分析用戶需求的基礎。類屬的軟體體系結構為套用的設計提供了輸入。最後，在可復用組件已經被購買、從現存庫中選出或構造好後（作為領域工程的一部分），它們可以被從事基於組件開發的軟體工程師使用。
基於組件開發
基於組件的開發是一個和領域工程並行發生的CBSE活動。一旦體系結構被建立，它必須用組件去充實，這些組件或者可從復用庫中獲得，或者根據專門需要而開發。因此，基於組件的開發的任務流有兩個並行的路徑（如上圖）。當可復用組件可被用於潛在地集成進體系結構中時，它們必須被進行鑑定和適應性修改。當需要新的組件時，必須重新開發，然後，產生的新組件被“組裝”（集成）到體系結構模板中，並進行全面測試。
組件鑑定、適應性修改和組裝
不幸的是，可復用組件的存在並不能保證這些組件可以被容易地或有效地集成到為新套用選擇的體系結構中。正是為此，當某些組件被提交復用時，一系列基於組件的開發活動被進行。
(1)組件鑑定
組件的鑑定保證某候選組件將完成所需的功能，將合適地“安裝”到為系統選定的體系結構風格中，並且將展示該套用所需的質量特性（如性能、可靠性、可用性）。
接口描述提供了關於組件的操作和使用的有用信息，但是，它並不提供確定是否被提出的組件能夠事實上被有效地復用於新的套用中所需的所有信息。在組件認證中考慮的很多因素是：
l 套用編程接口（API）。
l 組件所需的開發和集成。
l 運行時需求，包括資源使用（如記憶體和存儲器）、時間或速度以及網路協定。
l 服務需求，包括作業系統接口和來自其它組件的支持。
l 安全特徵，包括訪問控制和身份驗證協定。
l 嵌入式設計假定，包括特定的數值或非數值算法的使用。
l 異常處理。
當開發自身的可復用組件被提出時，這些因素的每一個均是相當容易評估的。如果好的軟體工程實踐被套用於軟體開發中，對所列出的這些問題的回答可以得到。然而，確定COTS或第三方組件的內部細節是相當困難的，因為唯一可用的信息可能只是接口規定本身。
(2)組件適應性修改
l 對庫中的所有組件已經實現了一致的資源管理方法
l 對所有組件存在諸如數據管理等公共活動
l 已經以一致的方式實現了體系結構內部及外部環境的接口
在現實中，即使在組件已經針對在套用體系結構中的使用而進行過認證，它也可能在剛才提到的一個或多個區域中展示出衝突。為了緩解這些衝突，經常使用一種稱為組件包裝的適應性技術。當軟體小組對某組件的內部設計和代碼有完全的訪問權時，可以進行白盒包裝。和其軟體測試中的對應物一樣，白盒包裝檢查組件的內部處理細節，並通過代碼級的修改以消除任何衝突。當組件庫提供了使得能夠消除或掩蓋衝突的組件擴展語言或API時，可以使用黑盒包裝。黑盒包裝需要在組件接口中引入前處理、後處理以消除或掩蓋衝突。軟體小組必須確定是否適應性地包裝組件所需的工作量是值得的或是否應該代之以開發定製組件（專門設計以消除遇到的衝突）。
(3)組件組裝
組件組裝任務將認證後的、適應性修改後的和開發的組件組裝到為套用建立的體系結構中。為了達成此目標，必須建立一個基礎設施以綁定組件到某運行系統中。該基礎設施（通常是專門組件的庫）提供了組件協同的模型和使組件能夠相互協同並完成共同任務的特定服務。
在很多用於創建有效的基礎設施的機制中，一組4個“體系結構成分”將用於實現組件的組裝：
l 數據交換模型。對所有的可復用組件應該定義使用戶和套用間能夠互動和傳遞數據的機制（例如，拖和放、剪下和貼上）。數據交換機制不僅應允許人到軟體、組件到組件的數據傳遞，而且也應使得能夠在系統資源間進行數據傳遞（例如，將一個檔案拖到某印表機圖符上以實現輸出）。
l 自動化。應實現一系列工具、宏和腳本以幫助可復用組件間的互動。
l 結構化存儲。包含在一個“複合文檔”中的異質數據（例如，圖形數據、聲音、文本和數值數據）應該被作為單獨的數據結構組織和訪問，而不是作為一組分開的檔案。“結構化數據維持了嵌套結構的一個描述性索引，套用可以自由地進行導航瀏覽以定位、創建或編輯個體數據內容，就像終端用戶直接操作一樣”。
l 底層對象模型。對象模型保證在不同平台上用不同程式設計語言開發的組件可以互操作，也就是說，對象必須能夠跨網路進行通信。為了達到這個目標，對象模型定義了組件互操作的標準。
因為復用和CBSE對軟體產業的潛在影響非常巨大，一些主要的公司和產業聯盟已經提出了一些構件軟體的建議標準：
l SunJavaBean。SunJavaBean組件系統是一個可移植的、平台獨立的CBSE基礎設施，使用Java程式設計語言開發。JavaBean系統擴展了Java Applet以適應基於組件的軟體開發所需的更複雜的軟體構件。JavaBean構件系統包含一組工具，稱為Bean開發工具箱（Bean Development Kit,BDK），它允許開發者作以下工作：
Ø 分析現存的Bean（構件）如何工作
Ø 定製他們的行為和外觀
Ø 建立協同和通訊機制
Ø 開發用於特定套用的定製Bean
Ø 測試和評估Bean的行為
這些標準中哪一個將在產業中占據支配地位？這不是當前容易回答的問題。雖然很多開發者已經選擇了某個標準，但是，根據套用的類別和選定的平台有可能大型軟體組織將選擇使用所有三個標準。
為了復用的分析和設計
理想地，分析模型被分析以確定模型中的那些指向現存的可復用軟體製品的元素。問題是以能夠導致“規則匹配” 的形式從需求模型中抽取信息。Bellinzoni、Gugini和Pernici描述了一種針對面向對象系統的方法：
組件被在不同的抽象層次定義和存儲為規約、設計和實現類——每個類是來自以前套用的某產品的工程化描述。規約知識（開發知識）被以復用建議類的形式存儲，它們包括各種用法指導，例如，對以組件的描述為基礎檢索可復用組件的指導，對在組件檢索完成後組裝和剪裁組件的指導。
自動工具被用於瀏覽組件庫，通過試圖匹配在當前規約中記錄的需求和那些對現存可復用組件（類）描述的需求。領域特徵和關鍵字被用於發現潛在的可復用組件。
如果規約匹配產生符合當前套用的組件，設計者可以從可復用組件庫中提取這些組件並將它們用於新系統的設計中。如果設計組件沒能找到，軟體工程師必須套用傳統的或面向對象的設計方法去創建它們。正是在這點（當設計者開始創建新的組件時）為了復用的設計（Design for reuse,DFR）應該被考慮。
作為為了復用的設計的基礎而應該考慮的一系列關鍵問題：
l 標準數據。應該研究套用領域，標識出標準的全局數據結構（例如，檔案結構或完整的資料庫），所有設計組件可以通過使用這些標準數據結構來刻畫。
l 標準接口協定。應該建立三個層次的接口協定：模組內接口的本質、外部技術（非人）接口的設計以及人機界面。
l 程式模板。結構模板可作為新程式的體系結構設計的模板。
一旦標準數據、接口和程式模板已經建立，設計者就有了一個可在其中創建設計的框架，新的符合這個框架的組件對以後的復用有更高的機率。
分類檢索組件
考慮一個大的大學圖書館，數萬本的書籍、期刊和其它信息資源都是可用的。但是為了訪問這些資源，必須有合適的分類模式。為了在這些大量的信息中導航瀏覽，圖書館管理者定義了一種分類模式，它包括分類碼、關鍵字、作者名以及其它索引條目，所有這些都使用戶可以快速而方便地找到需要的資源。
描述可復用組件
可復用軟體組件可用很多方法來描述，但是理想的描述是圍繞Tracz提出的3C模型——概念、內容和語境。
軟體組件的概念是“對組件做什麼的描述”。組件的接口被完整地描述，而且在前置條件和後置條件的語境中被表示的語義標識。概念將傳達組件的意圖。
組件的內容描述概念如何被實現。在本質上，內容是對一般用戶隱藏的信息，只有那些企圖修改該組件的人需要了解它。
為了在實際環境中可用，概念、內容和語境必須被翻譯為具體的規約模式。
目前，主要使用圖書館科學方法進行組件分類。
圖3.2 圖書館科學方法組件分類示意圖
上圖給出了源於圖書館索引方法的一個分類法，“受控的索引辭彙”限制了可以用來分類對象（組件）的術語和語法，“不受控的索引辭彙”則對描述的性質沒有限制。大多數軟體組件分類模式可歸為以下三類：
(1)枚舉分類。通過定義一個層次結構來描述組件，在該層次中定義了軟體組件的類以及子類的不同層次。實際的組件被羅列在枚舉層次的任何路徑的最低層，例如，對視窗操作的枚舉層次可能是：
window operations
display
open
menu-based
openwindow
system-based
sysWindow
close
via pointer
…
resize
via command
setWindowSize,stdResize,shrinkWindow
via drag
pullWindow,stretchWindow
up/down shuffle
…
move
…
close
…
枚舉分類模式的層次結構使得它易於理解和使用，然而，在建立層次之前，必須進行領域工程，使得在層次中適當的項含有足夠的信息。
(2)刻面分類。領域被分析，可以標識出一組基本的描述特徵，這些特徵成為刻面，刻面被根據其重要性區分優先次序並被聯繫到組件。一個刻面可以描述組件完成的功能、被操作的數據、組件套用的語境或任意其它特徵。描述組件的刻面的集合稱為刻面描述子，通常，刻面描述被限制在不超過7或8個刻面。
作為一個簡單的使用刻面組件分類的例子，考慮使用下列組件描述子的模式：
{function,object type,system type}
在刻面描述子中的每個刻面可取一個或多個值，這些詞一般是描述性關鍵字，例如，如果功能是某組件的刻面，可賦給該刻面的典型值可能為：
function=(copy,from) or (copy,replace,all)
(3)屬性-值分類。為領域中的所有組件定義一組屬性，然後為這些屬性賦值，其方式和刻面分類方法非常相似。事實上，屬性-值分類方法和刻面分類方法是類似的，除了下面幾點不同：
l 對使用的屬性的數量沒有限制
l 屬性沒有優先權
l 不使用詞典功能
復用環境
軟體組件復用必須有環境的支撐，一個復用環境應包含如下元素：
l 能存儲組件和查找組件必需的組件分類信息的組件資料庫。
l 提供對組件資料庫訪問的庫管理系統。
l 支持被復用的組件到新設計或新實現中集成的CASE工具。
這些功能的每一個在復用庫的範圍內互動或者被包含在復用庫中。
復用庫是一個大型CASE中心存儲庫的一個元素，並且為一系列可復用軟體製品（例如，規約、設計、代碼、測試案例、用戶指南）的存儲提供設施。復用庫包含了一個資料庫以及必需的支持資料庫查詢和組件檢索的工具，組件分類模式是組件庫查詢的基礎。
查詢經常用前面描述的3C模型中的語境來刻畫，如果某初始查詢產生大量的候選組件，則查詢被求精以減少候選對象。然後，概念和內容信息被抽取出來（在候選組件集得到後）以輔助開發者選擇合適的組件。
CBSE經濟學
在直覺上，基於組件的軟體工程是很有吸引力的。從理論上講，它將為軟體組織提供在質量和時間上的優勢，而這些將直接導致成本的節省。
對質量、生產率和成本的影響
大量來自產業實例研究的證據表明從積極的軟體復用可以導出實質性的商業收益、開發生產率和整體成本都將得到改善。
(1)質量
理想情況下，為了復用而開發的軟體組件已被驗證是正確的且不含有錯誤。在現實中，形式化驗證並不能例行公事地進行，錯誤可能而且也確實存在。然而，隨著每一次復用，錯誤被發現和消除，組件的質量也隨之改善。隨著時間的推移，組件變成實質上無錯誤的。
在HP公司的研究中，Lim報告說：被復用代碼的缺陷率是每KLOC有0.9個缺陷，而新開發代碼的缺陷率是每KLOC有4.1個缺陷。對一個包含復用代碼的套用來說，缺陷率是每KLOC有2.0個缺陷——相對套用的無復用開發，對期望的缺陷率有51%的改善。Henry和Faller的研究指出在質量上有35%的改善。雖然不同的報告跨越了質量改善百分率的一個合理的範圍，但是，顯然我們可以說，復用對交付的軟體在質量和可靠性方面確實帶來的實質性的收益。
(2)生產率
當可復用軟體製品被套用於軟體開發過程中，在創建對開發一個可交付系統所需要的計畫、模型、文檔、代碼和數據方面所花費的時間自然要少，導致的結果是：用較少的努力給客戶提供了相同級別的功能，因此生產率得到了改善。雖然，對生產率改善百分率的報告是眾所周知難於解釋的，但是，似乎30%到50%的復用可以生產25%到40%的生產率改善。
(3)成本
復用帶來的純成本節省如下估算：估算出項目如果是從頭開始開發所需的成本Cs，然後減去和復用關聯的成本Cr與軟體被交付時實際Cd的本質和。
和復用相關的成本Cr包括：
l 領域分析和建模。
l 領域體系結構開發。
l 為方便復用所增加的文檔量。
l 可復用組件的支持和增強。
l 對從外部獲取的組件的版稅和許可證費。
l 可復用組件中心存儲庫操作的創建或者獲得。
l 對設計和構造復用人員的培訓。
復用度量
為了測試復用在基於計算機的系統中的收益，已有一系列的軟體度量體系被提出。在系統S中和復用關聯的收益可以表示為：
R(S)=(Cnoreuse-Creuse)/Cnoreuse (3.1)
其中，Cnoreuse是不基於復用開發的成本， Creuse是基於復用開發的成本。R(S)為如下範圍內的無量綱值：
0=<R(S)<=1
在面向對象系統中對復用的一種一般性測度，稱為復用倍率(reuse leverage)，被定義如下：
Rlev=OBJreused/OBJbuilt (3.2)
其中，OBJreused是系統中復用的對象數，OBJbuilt是構件系統的對象數。
