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