軟體進化是軟體產品交付給客戶之後所發生的一系列改進活動,是有目的地從早期版本來產生新版本的過程,是 軟體工程中的一個重要領域。
基本介紹
- 中文名：軟體進化
定義,發展歷程,主要的研究內容,軟體進化的方法,
定義
進化可以從許多不同的觀點和領域來解釋和研究,在軟體領域中,它通過對軟體系統從最初的概念到可操作實現的過程研究,通過對軟體系統為了更好地適應外部環境而進行相應的進化和擴展的研究,來研究軟體進化的方法和意義。進化在軟體領域的觀點主要集中在進化的機制和工具上。
軟體進化關心的是軟體產品交付給客戶之後對其的修改維護,是軟體工程的一個子領域。對軟體進化目前沒有統一的定義,以下為幾種定義:
RISE(The Research Institute for Software Evolution)認為，一般的軟體進化涉及到了軟體交付給客戶之後所發生的所有活動。它定義軟體進化為一系列的活動,包括技術上和管理上的,這些活動能夠確保軟體產品不斷達到商業要求的目標,且是低成本高效的完成。
Manny M.Lehman and Juan F.Ramil定義軟體進化為:有目的地從早期的可操作版本來產生新的軟體版本的所有規劃設計活動。
L.A.Belady的定義為:軟體系統在它們的生命周期里被維護和增強的動態行為。
Ned Chapin定義軟體進化為:它是軟體維護活動和過程的一個運用,以及對這些活動和過程質量的保證和管理。這些活動和過程是用來從一個早期的可運行版本中來產生一個新的軟體版本,這個新的軟體必須滿足客戶要求改變的功能或屬性。
儘管軟體進化的定義沒有統一,但其實質都是一樣的,軟體進化是一個過程,在這個過程中,程式要改 變其形態來適應市場的要求和從先前程式中繼承而來的特性。實現進化的最終目標是使軟體能夠更好地實現客戶的需求,更好地適應環境的改變,使軟體的功能不斷地完善和增強。
發展歷程
在有計算機的早期,軟體進化的行為主要就是給新的套用編寫新的程式。直到20世紀60年代後期, 人們才開始意識到舊的軟體系統不能只是簡單地被淘汰,軟體需要被管理,軟體的維護和進化是一個重要的活動。
現在人們普遍接受這個觀點,反映現實世界套用的經常使用的軟體必須持續不斷地被改進和增強來維持人們對它的滿意程度。這個觀點第一次出現是被作為軟體進化的原則陳述出來的。對這個觀點,早在1968年在Garmisch會議上就被公開討論過。同時, IBM公司於1968年開始了對軟體過程的研究, Lehman等人在IBM中研究了規劃設計過程,而用來檢驗和建模持續變化過程的一份研究報告被套用到了IBM的OS/360^2作業系統上,這份報告是關於支持軟體版本實現的計畫和管理的工具等系統進化的很簡單的模型。儘管這個模型的發展是相對簡單的,但對它 的研究促進了軟體進化的發展及軟體進化原則的出現。1971年,人們第一次把對軟體過程看作是一個反饋系統(feedback system)進行了討論。1979年開始,人們把軟體進行了SPE三種類型的分類,認為E類型系統解決的問題、從事的套用都是現實世界中的, 是現實世界中模型的反映,並認為E類型軟體必須要持續不斷地進行進化。從1974年開始一直到1996年,人們逐漸形成並完善了軟體進化的8個基本原則,這些基本原則都是針對E類型軟體的。
人們早期對於進化研究的數據是從IBM OS/360-370作業系統上獲得的,隨後是其他作業系統。早期的研究主要集中在進化的行為上。Lehman等人在對軟體進化的研究中認為進化是大型程式的內在特 性,每個特定系統都存在潛在的進化要求,這個現象可以被系統地研究和建模,且這些相關的模型可被用來預測未來系統的發展情況。
早期的研究在很大程度上不被計算機科學和軟體工程組織重視,儘管如此,這個現象逐漸吸引了其他人的注意。由於程式的動態增長及其過程中各種因素的影響,1989年,出現了軟體不確定原則,隨後是1993年FEAST(Feedback,Evolution And Software Technology)假設,該假設認為全球的E類型軟體系統的進化過程是一個自我穩定的系統,一個複雜的多循環、多層次、多代理的反饋系統,該假設是以前研究的一個總的反映。在1996年和2001年期間,人們開展了 FEAST/1和FEAST/2工程,這些工程是依賴於FEAST假設的,它研究了在E類型軟體系統的進化和軟體過程的改進中反饋韻作用和影響。直到現在,軟體進化一直被人們進行著廣泛系統的研究。
主要的研究內容
現在,軟體進化被人們廣泛系統地研究著,人們對它研究主要是從兩個方面來進行的。一個是把進化看作名詞,主要是研究進化的本質、原因、特徵、結果、影響、管理、控制等。如:什麼是進化;為什麼需要進化;什麼驅動、控制和限制著進化;進化對成本、時間、進化過程的價值及產品的影響是什麼等等的問題。
另一方面是作為動詞來研究的,主要考慮的是進化過程的實現。包括提供和改進的方法、過程、行為、語言和工具等。比如:進化行為的目標是什麼;為了達到目標,哪些地方需要進化;採用什麼方法和技術比較合適;採用什麼工具比較恰當;還需要哪些資源和技能等等。上述兩方面是相輔相成的。加強對進化特性、管理和控制等的理解有利於過程管理和過程改進。對進化原因、屬性和影響的研究有助於更系統有效地管 理和制定計畫,更有效地控制其過程和行為,這意味著更加需要有效的方法和合理的工具。而反過來,對於軟體進化方法、語言、工具、過程等的研究,又進一步幫 助發現在軟體進化理論和基礎方面的缺陷和問題,有利於彌補進化理論基礎方面的不足,有利於理論和框架的發展,並且有利於加速軟體進化的過程。因此,軟體進化的兩個方面必須共同前進。
軟體進化的方法
目前,快速增長變化的需求使得大多數的軟體變得很難維護。然而,拋棄現在的系統而重新開始設計 完成系統在經濟和時間上是不可行的。因此,就迫切 需要有效的方法來指導和控制它們的進化。但是,目 前有效而系統的進化方法還不是很多,以下為幾個典型的軟體進化方法。
文獻[2]提出了一種形式化的程式轉換方法,該方法是基於一個形式化的語言WSL(wide spectrum language)和方法的。這些轉換在一個程式改變其形式的時候可保持其語義不變。它們被套用於重構系統以及抽象其中高層的表示。藉助於一系列合適的轉換, 可以使這些抽象的表示等同於代碼。
WSL是這個方法的關鍵,因為所有的轉換都用它來表示,它必須能夠方便地表示底層的一些命令語句和高層的一些規範文檔,且要能很容易地證明程式在一系列的轉換中是否等價。利用該語言,可證明一個程式是否正確地實現了一個規範要求,一個規範是否正確地描述了一個程式的行為。該方法首先將給定的一個原程式P轉換為一個用WSL語言表示的等價形式P’。然後從P’開始,從一個預先被證明好的轉換庫中選擇一個轉換,這將可能產生新的中間形式S1,然後,接下來的一系列轉換將使軟體被轉換成S2,S3,⋯, Si。最終的結果是要依賴於使用者需要的,比如希望只是簡單的重構還是需要提煉出一個抽象的規範說明。
這個方法中有三種基本的操作:程式轉換,細化和抽象。轉換操作可以修改一個程式變成一個不同的形式,但卻有著同樣的外部行為;細化使一個程式的行為更加被確定化;而抽象操作與細化相反。其更詳細的描述可參考文獻[2]。
Maritta Heisel等人也提出了一種指導軟體進化的方法,這個方法依賴於一系列在需求和代碼之間由映射連線的中間製品(artifact),這些中間製品及其連線可以被構造和維護,它們可以用一個系統的方法來指導軟體的進化過程。
該方法把軟體開發中的問題和解答領域分離開來,問題領域包含了軟體的需求,對軟體的內部沒有涉及,解答領域包含了程式代碼以及實現代碼時所建立的文檔。
問題領域概念是指在問題領域中有意義的一些概念(如軟體將要模擬和交流的環境等)。這些概念可以在需求中出現,如一些對象等。但還包括一些需求中沒有的領域知識,它們是需求中有關概念的隱性信息, 但在規範說明的編寫中非常有用。而解答領域概念是在抽象代碼和軟體架構中使用的(如圖1所示)。
Artifacts and mappings規範說明是一個可實現的需求,但要避免過多的實現細節,它描述了軟體對外的接口,不考慮其內部工作。它只允許使用在問題領域中有表示的概念,因此, 和純粹的問題領域概念無直接關聯。而抽象代碼對於理解原始碼的原理很有幫助,且易於文檔化。但達到一定的高度時,抽象代碼就不再合適了,這就需要軟體構架來更好地描述其工作原理,軟體構架主要考慮了軟體的內部結構和工作原理。同時,兩個領域問必須 要有一個聯繫,至少兩者概念可以互相轉換,而共享的概念則實現了將兩者相匹配的概念合併的功能。但這個匹配過程的關鍵是不同領域中概念的語義必須相匹 配。而那些沒有匹配的概念則被劃到各自的純粹領域中。
文獻中描述了如何構建這些映射及一些相關確認規則。一旦軟體要改變的要求被確定下來,首先會影響到問題領域的概念,使原有的概念作廢或添加新的進去,而這些受影響的概念可被概念和需求間的映射所捕獲。同樣,需求的改變多少都會影響到共享概念, 有些是直接的,有些是通過純粹問題領域概念來間接影響的。這樣逐層往下,所有的改變都可影響到代碼層。為了支持這種自頂向下的結構,標籤被引入進來。一種改變標籤和每個要改變的需求、概念和結構元素相關聯,每個改變標籤包含了要必須修改的一些描述。另一種違例標籤被自動創建來檢查是否在這個過程中 違反一些確認規則。在這個過程中,標籤可用來決定是否一個底層的中間製品要考慮被修改。根據改變標 簽上的線索可以知道改變的過程,確認標籤同樣幫助了這個過程。這樣,就使整個軟體進化過程從上到下可以有條不紊地進行,這種方法有效地指導了軟體進化的過程。
唐亞哲等人提出了一種基於開放實現與反射的軟體進化模型。傳統的軟體擴充機制,如基於原始碼的軟體擴充和二次開發擴充等方法,要么信息量太大, 要么適用條件有限,都不能得到廣泛的套用。開放實現與反射技術從一種全新的角度和系統化、結構化的 方法為軟體進化提供了新的方法和手段。與以往方法相比,基於開放實現與反射技術的軟體進化不僅為軟體進化和擴充提供了清晰的接口,且由於較好地實現了分離原則,大大降低了軟體擴充的風險和提高了軟體質量。
開放實現是與傳統軟體開‘發的“黑盒”原則相對的,簡單說,開放實現就是模組或對象不僅提供功能接口,而且提供定製接口(就是配置接口,對模組或對象內部具體實現的某些方面進行設定)。定製接口的提供有各種方式,其中最主要的就是元對象協定MOP (Meta Object Protoc01)。MOP是反射技術術語,與元對象相對的是基對象。它是正常系統套用對象,而元 對象是表達基對象如何實現的對象,即元對象控制基對象的操作。通過該技術可實現軟體運行時動態變化。就是說系統不僅向用戶提供功能,且提供用戶進行高級定製的接口,並在系統內部將這些定製接口與系統功能進行因果關聯。
該方法的研究基於這樣一個認識:系統的擴充和進化不是隨意的,而是可以在相當程度上預見的。其目的就是儘可能多地預見系統的進化,並用一種有組織的結構化方法來實施這種進化。同時，方法引入了“軟體運行進化”的概念，,並將其形式化定義為六元組C.
C={代碼,二進制代碼,編譯器,解釋器,用戶配置,二次開發}
顯然,六元組與軟體生命周期的各個階段有關。在設計階段就要明確係統的進化特點,比如哪些方面容易變化等,最好能詳細記錄這些信息。在原始碼設計階段,可以使用反射語言或定義元對象來支持進化。
這種方法有利於幫助進化。首先,它們強調分離原則,將大量非功能與功能屬性用不同的模組來表達, 它們的耦合關係由自動工具來實現,減少了程式設計師進行程式閱讀和修改的工作量,並提供可靠性。其次,該技術將原本由程式邏輯隱含表達的系統內部實現細節用元層對象表達,提供了基層程式設計師操縱程式實現細節的高層接口。第三,該技術提供了一種結構化的方法來實現軟體動態擴充,使軟體擴充的整個過程處於嚴格控制之下,軟體的修改和擴充不再是一種隨意性 的活動,確保了軟體進化的質量。
以上提到的三種支持進化的方法中,第一種只是對程式進行了等價轉換,其轉換操作可以修改程式變成不同的形式,但卻有著同樣的外部行為。因此,這種方法對於添加新的功能和刪除一些功能有些限制,這種方法主要是集中在了代碼層的進化上,有一定的局限性。第二種方法從巨觀的方面對軟體過程進行了跟 蹤和進化,從軟體工程的角度對進化進行了控制,從最初的需求改變直到最後的編碼設計,都有效同步地控制了進化的過程。最後一種方法,可以說是對軟體的進化進行了預處理,提前就分析了系統的進化特性,在 設計實現的時候提供了充分的用戶定製接口,大大降低了軟體進化的難度。
