計算機軟體開發的進展研究論文
1引言
當前，計算機技術的迅速更新、軟體處理物件如企業業務過程的不斷變化以及軟體開發競爭的日趨激烈已經使傳統的從原始碼級開發軟體系統的方法面臨越來越大的挑戰。利用傳統開發方法開發的大多數系統所使用的是在開發初始時所能得到的技術，面向的是當時所需處理的問題，要使這些軟體系統適應處理物件如業務過程的變化以及計算機技術的進步是一件非常複雜的工作，往往必須對原有系統在程式碼上進行重大修改，這種修改代價較高並且也有一定的風險，從而造成軟體的可擴充性Scalabiltiy)較差。在開發過程中，為減少軟體開發費用、縮短軟體開發週期，保持開發者的技術水平變得越來越重要，因為只有這樣才能達到一個較高的開發效率，使得專案按時完成。而在傳統的開發方法中，由於開發不同的軟體時常需要不同的開發工具，這使得開發者必須不斷學習新的開發工具，原有的技巧以及已具備的經驗難以被再次利用。當今的軟體開發經常需要利用現有成果，開發時可能要整合不同的系統、新的應用、標準的軟體包以及已在業務開展中使用了的與任務有關的現有資料與系統，透過整合可以減少不必要的工作量，提高軟體的可用性，加快開發進度。但是傳統的程式碼開發方法主要著眼於從無到有的構造，對軟體整合Integration)的支援不夠，大量的開發時間被投入到底層程式設計中，這種程式設計不僅耗時而且可能是重複勞動，從長遠看還會造成程式碼難於維護。
隨著軟體構件技術的成熟，大量的構件作為現成的商品在軟體市場出現，基於構件的軟體開發CBSD：Component-basedSoftwareDevelopment)也作為一種新的工業化的軟體開發方法被提了出來。該方法是對以前傳統開發方法的一種改變，它使得軟體開發從程式碼開發轉移到對已測試、已使用的，並且在內部互操作的構件的整合是軟體重用的一種例項。透過加強系統的靈活性以及可維護性，CBSD可以被用來減少軟體的開發費用、快速的整合系統以及減少與支援升級大型系統相關的維護費用，從而使軟體開發者處於有利的競爭地位。該方法的基礎是基於這樣的假設：大型軟體系統的某些部分會不斷重現；系統的公用部分應當編寫一次而不是多次；公共系統應透過重用被整合而不是一而再，再而三的重寫，它體現了FredBrooks所支援的購買而不構造”的開發思想。在CBSD中的構件主要是指可以透過商業手段獲取的構件CommercialOff-the-shellComponent)，主要是遵循已有的C0M/DC0M、C0GBA以及JAVABEALS構件標準的構件、開發者可以加以剪裁的應用框架以及已被其他應用整合或擴充套件的獨立軟體系統。當今世界上許多研宄機構如美國的卡耐基梅隆大學、加拿大的國立研宄委員會NationalResearchCouncil)都在積極對CBSD展開研究，該文將對這一領域的研究成果、進展加以綜述。
2CBSD的主要活動
CBSD的開展主要是透過整合已存在的構件來進行的，這與傳統的開發方法有著明顯的不同，在後者中，系統整合通常是實現工作的結束部分，而在CBSD中，構件整合是構造系統的核心內容。因此，在決定獲取、重用甚至構造構件時，可整合性是所需考慮的關鍵因素。
CBSD由4個主要活動組成：構件的評選、構件的適配、構件的組裝以及系統的演化。
2.1構件的評選
構件的評選是一個從市場上的一批相互競爭的構件中加以選擇的過程，該過程要求在眾多侯選者中選出最適合在該軟體環境中使用的構件。在安全性要求較高的應用中，構件的選擇可以擴充到包括對建立與維護構件的開發過程的選擇，但這樣也會減少使用現有構件的一些好處。
一個適合使用的構件可能本身就是一個複雜的軟體，為了有效地使用該構件，必須深入瞭解它。但較好地瞭解一個構件並不是一件容易的事情。首先構件的文件可能不全或者錯誤。即使構件的提供者有意識作好文件，一個複雜的軟體是不可能在文件中被完全並且正確說明的。即使不完全的文件可能也是龐大的，除了非常有經驗的使用者，其他人將很難理解；其次構件的介面可能非常複雜。許多構件有上百個API呼叫，即使編制這些構件的人都很難知道每個API呼叫的行為或者特殊呼叫序列的結果；最後在構件中存在錯誤。所有這些問題都對了解構件造成困難。
構件的評選有兩個階段：發現與評價。在發現階段，要判別構件的特性。這些特性包括構件的功能提供什麼樣的服務）、構件介面的其他方面如使用的標準）以及其他難以分離出的質量特點如構件的可靠性，可預測性以及可用性。在一些情況下，在發現構件時也應該考慮構件的非技術特性，如提供者的市場佔有率、以前的業績以及構件開發組織的過程成熟度。發現構件是一個艱難的無法精確定義的過程，所需的資訊很難量化，有時也難以得到。
構件的評價是一種決策。評價構件用來支援作出編制還是購買、買A還是買B以及使用特徵A還是使用特徵B的決定。當前已經存在了一些相對成熟的評價技術，如ISO的通用標準以及IEEE的特定域的構件評價技術，但就構件評價本身來說是不確定的，這主要是由於使用難以互相比較的標準、不明確的系統期望、不精確的評價方法以及構件的快速修改，這意味著構件評價帶有一定的錯誤。確定構件的適應性是構件評價的目標，構件對系統百分之百的適應是不大可能的，一般都存在一定的權衡，而構件對系統的不適應程度由不適應的型別、修補不適應的費用以及不適應性所導致的風險所決定。對於每一個評價活動，由於存在各自不同型別的決定、系統環境評價過程都是有針對性的，對開發者有用的應該是一種系統的方法，該方法能夠在眾多可變的因素中加以選擇以說明有用的評價標準。
2.2構件的適配
由於每個構件在編制時針對的是滿足不同需求的，並且是基於上下文的不同假設，在應用到一個新系統時構件常常必須被改寫。構件必須被改寫的前提是保證構件間的衝突最小。對構件內部結構的理解程度決定了對構件適應的不同方法*2+：
1)白盒子法。使用者可以獲得構件的原始碼，這樣可以透過改寫構件以使構件能與其他構件進行互操作。這種方法可以對構件的特性進行非常細緻的控制，不過由於需要修改原始碼，從長遠看可能會導致嚴重的維護和升級的問題，使得基於構件開發的許多優點被丟失。
2)黑盒子法。只能得到構件的二進位制可執行形式，構件沒有提供擴充套件機制或API。
3)灰盒子法。在這種情況下，構件的原始碼是不可更改的，但構件提供了它自身的擴充套件機制或可程式設計的介面API。
對構件自身的擴充套件機制加以呼叫的方式一般稱之為構件的剪裁ComponentTailoring)，它指構件的使用者以構件提供者所提供的方式來增強構件的功能，包括指令碼Script)、外掛Plug-in)的使用和繼承inheritance)三種方式。卻本方式是指構件在某些特定事件下執行某一特定的指令碼過程，早期的指令碼是由簡單的宏語言來編寫的，在當前許多新的應用中指令碼描述能力已經越來越高階，使用者可以使用完善的程式語言和直譯器來編寫指令碼如VBA、tcl以及Perl。外掛是指在一個封閉應用中註冊的構件，當應用需要該外掛功能時會對外掛執行一個回撥Callback)。繼承允許構件內部的某一特定部分被修改和限定，當前的面向物件標準允許構件被開發者使用，儘管使用者只能得到構件的二進位制程式碼，繼承的使用要求深入瞭解構件結構，在通常情況下僅僅被專業開發者所使用。對構件可程式設計介面的呼叫一般會涉及到在構件周圍編寫一個遮蔽構件工作區以及延伸的包容器Wrapper)以提供對構件介面的更高階抽象。把構件包容起來有很多好處：可以使構件遵循標準，如在已有系統上的COGBA包容器；為某一範圍的構件提供一個標準介面；增加或隱藏）構件的功能；為構件提供一個單一的訪問介面；儘管該整合者無法控制構件，構件的包容器能給構件的整合者一種直觀的感覺。構件的整合者可以控制和訪問包容器。
2.3構件的組裝
構件的組裝較易發生錯誤，需要一定量的編碼，並且難以除錯和測試，此外，構件還較易發生變化，商業構件經常面臨頻繁的升級。這些升級所增加的功能或消除的問題不一定是使用者所希望的，在上一版本的關鍵功能可能在後續的版本中被刪去了，在這種情況下，使用者可能會希望在系統新的釋出版本中使用由其他供應商提供的同類型構件。
為了處理在搭建系統時所遇到的問題，整合構件的體系結構應該有以下一些特點：
1)構件可插拔。系統的體系結構必須允許構件的替換，這種替換包括更新為構件的新版本和將構件替換為由其他供應商所提供的同類型構件。
2)構件間鬆散耦合。構件間的耦合必須儘可能的小，耦合可能包括功能耦合如過程呼叫以及其他型別的依賴如資源競爭或結構上的假設。體系結構必須允許構件間的隔離。
3)隱藏不必要的功能。為了使自己的構件區別於其他人提供的構件，構件供應商給他的構件加上過多功能，這對構件的組裝不利，系統結構設計者可能因此希望去掉這些功能，系統的體系結構必須提供對功能隱藏的支援。
4)除錯與測試。由於在開發過程中構件基本上是以灰/黑盒子的形式來使用的，所以不可能對構件內部加以除錯和測試。軟體的體系結構無法克服這一問題，但是它可以包括在執行時對構件的行為加以監控及驗證的能力，並且可以防止構件的錯誤擴充套件到系統的其他部分。
在由構件開發軟體系統時，可以使用以下幾種體系結構型別：
1)資料庫結構。在該結構中對所有操作資料的集中控制是系統在構件間共享資訊的關鍵。
2)黑板模型。構件間的資料共享是隨意的，涉及降低系統的開銷水平。
3)訊息匯流排。構件有各自不同的資料儲存，這些區域性資料透過變化訊息來加以協調。
4)訊息請求代理0)B)協調，0)*技術提供了與語言無關的介面定義和物件定位與激發的機制。
組裝構件時，在許多時候必須編寫一些粘接程式碼GlueCode)，這些程式碼可以透過必須的資料轉換等手段來消除構件間介面不相容的問題，使底層構件的功能按需激發，從而提供把不同的構件結合在一起的功能。不僅如此，透過捕獲異常，粘接程式碼還能為系統提供統一的異常處理機制。
2.4系統的演化
系統是不斷改變的；系統中的構件也是不斷變化的。系統與其構件的演化對系統的維護造成了多種影響。在把新版本的構件加入到系統時需要做許多工作，對於一個由多個構件組成的系統，每個構件都有其自身的升級安排，把每個構件的每一個新版本加入到系統中代價非常高昂，造成這種困難的原因是因為在構件的新版本中，構件的行為、介面、前提、效能以及錯誤的消除都可能發生變化；在舊版本的構件上進行的定製、擴充套件以及相關工作必須施加到新構件上。
在基於構件的系統中沒有在機械系統中定義的‘一致”的概念，在機械系統中各個部件完美結合而在軟體系統中各構件的結合是在一定的限度之內的。一種處理系統演化的方法是假髮生，系統可能依賴於已不再使用或已被升級的特殊平臺；也可能在新版本中需要去除錯誤。整合新版本的構件需要作出較大的努力。首先，新版本的構件必須被評價以確定在舊版本上作了什麼改變；其次，新構件必須被整合到系統中。這可能包括新增或移去構件的工作區，增加新的擴充以考慮構件新的行為，升級文件和培訓過程等等；最後，系統必須被測試和確認。
3使用CBSD的優缺點
作為一種新的軟體開發方法，CBSD具有自身的特點，這些特點把它與傳統的程式碼開發方法區分開來。使用CBSD可以給軟體開發帶來以下好處構件的開發者可以使用最適合的開發工具而不必學習新的語言和工具，這樣就允許企業可以利用已有的技術；當使用預先建立及測試的構件時，在組裝過程中應用的開發者可以關注業務問題而不用擔心技術以及外部設施等問題，減少了系統完成時間。
在市場上出現的構件大多經過市場的檢驗而變的比較成熟，對這些構件的使用可以使系統比在使用自己編制的構件的情況下更可靠、設計更合理。
由於系統的開發基於組裝過程，構件能被較容易的替換為更便宜、有更多附加值、使用更好技術並且具有類似功能的構件。這樣使得系統的靈活性更好，開發者也不會過分依賴於某個供應商。
CBSD可以降低軟體開發費用，由於構件的供應商開發及維護構件是針對多個使用者的，那麼使用該構件的軟體在該構件部分的開發及維護費用被多個使用者分擔。
雖然CBSD有許多優點，但也存在不少缺點，這些缺點給軟體開發帶來一定的風險。
首先開發者無法得到構件的原始碼，也就無法透過修改原始碼來改變構件的功能，這就意味著分析、除錯以及測試構件必須完全以黑盒子的.形式進行。不僅如此，在許多時候，完整並且正確的特性說明也是拿不到的。雖然構件的提供商提供了功能描述但是對於那些想掌握構件更詳細的特性以及所需資源的開發者來說，這種說明往往難以滿足需要。構件整合者也可能會使用未被構件提供商所預見的構件使用方式。
其次，構件的使用者無法控制構件的升級。構件的使用者僅僅是構件提供商許多客戶中的一個，雖然從總體來說，構件的升級是由客戶來驅動的，但單個客戶不可能有對構件升級的全部控制權。
再次，在構件整合時，所選用的構件之間可能不匹配或者是作為單獨應用設計的構件與軟體的其他部分不易互動。構件之間的不匹配可以由許多原因導致，如資料模型、功能不匹配、資源衝突、過程模型等等。在有些時候這種不匹配在開發階段的後期才會暴露出來。
4CBSD開發時建議遵循的原則
透過對大量基於構件軟體開發過程的分析，可以得到一套有助於利用構件成功開發軟體的原則43，|。這些原則從經驗中來，遵循這些原則，可以簡化開發及系統演化的工作。
1)包容所有的構件
系統中所有的構件都應該有包容器把它們給包容起來。提出這一原則的理由在於包容器提供了系統開發者對構件介面以及構件間互動的唯一機制，並且使系統的其他構件不受該構件改變的影響。此外，系統中所有提供重要功能而由手工編寫的部分應與對待構件相似的方式對待，也應該用包容器包起來，這樣當以後如果出現同樣功能的構件時，開發者可以較容易地把手工編寫部分改成構件。
2)粘接程式碼獨立於構件
粘接程式碼應該獨立於與其粘接的構件，在構件替換時不必改寫，構件的替換被構件的包容和剪裁獨立所隱藏，粘接程式碼與構件的互動是透過包容器間接進行的。粘接程式碼所提供的功能不應該依賴於所訪問的特定構件，諸如異常處理、控制流等服務的升級應獨立於多粘接的構件，這樣當構件升級或修改時，粘接程式碼可以保持不變。透過提供構件周圍用來隔絕的包容器粘接程式碼可以使用標準方法訪問構件。
3)檢驗構件的版本一致性
構件以新版本釋出的形式快速升級，系統通常與使用構件的哪一個版本執行有關係，一個特殊的構件被升級到一個新版本經常意味著包容器以及其他構件也要被升級。
系統的開發者無論如何都需要保證當前構件的配置版本一致，理想的版本檢查是自動進行的，版本驗證可以在建立、安裝或執行時進行，這與構件的連線時間有關。Perl和使用Ac?tiveX構件的VisualBasic都有對版本驗證的支援。在Perl中，構件開發者在每個釋出的軟體模組中加入一個版本號，構件使用者在連線該模組時必須說明所需的版本，在執行時系統會檢查所連的模組的版本是否等於或高於所需版本。ActiveX構件對構件及介面都有一個版本號，構件的版本號是由開發者確定的，它被安裝程式使用來決定已安裝的構件是否應該被新版本的構件所替換。介面的版本號是在編譯時自動分配的，它用來記錄一個構件介面的不同版本的一致性。在執行時，當一個VisualBasic程式連線到ActiveX構件時，一個驗證構件所暴露的介面是否是VisualBasic程式所預期介面的檢查會自動進行。如果版本不一致的話，系統整合者可以捕獲異常。
4)在包容及粘接中加入斷言
在許多情況下為了確認執行時的斷言在包容及粘接中所進行的高層次檢查是非常有用的。這些斷言可以僅僅是驗證引數值或型別，也可以更為複雜，斷言資料值之間的關係或所需要事件的臨時順序。這種執行時的檢查主要位於包容器及粘接程式碼中，透過在構件間新增斷言並且在斷言違背時發出異常，錯誤能很快被發現並且從系統中分離出來。
5)使用開放的標準
使用遵循開放標準的構件能使不同供應商的構件間較容易地替換，而選擇遵循特殊標準的構件會給系統的可移植性以及用不同來源的構件配置系統時帶來問題。如果使用不開放的標準，系統開發者會過分依賴某一特定的供應商，即使有其他供應商提供相同功能並且效能或費用上更可取的構件，開發者也無法採用。
6)—致的體系結構型別
通常開發者無法控制構件內部的結構以及構件的演化與維護，他們所能決定的是系統體系結構及體系結構型別。透過定義在系統整個生命週期內都可維護的靈活的體系結構並且保證構件都遵循這一結構能使在系統中新增構件較易進行，系統內的服務也能按照需要剪裁和修改。如果在開發過程中過早地束縛於一個特殊的體系結構，會使構件的整合變得困難，構件的完全利用也不太可能實現。
5小結
基於構件的軟體開發已經越來越廣泛地應用於包括企業資訊系統在內的多個領域的軟體生產中，並且成功地開發出許多系統，但在對安全性要求苛刻的系統中，使用該方法風險仍然太大。為了方便該方法的開展，當前出現了不少開發工具如compuware公司的Uniface、SuperNova公司的Visualconcepts，這些工具在構件組裝、部署等方面提供了許多支援，使得基於構件的開發能更加有效地進行。