《軟件工程-理論、方法與實踐》課件第13章

第13章軟件演化13.1軟件演化的動態(tài)特性13.2軟件維護13.3軟件再工程本章小結習題

13.1軟件演化的動態(tài)特性

13.1.1軟件的本質(zhì)特性

Lehman和Belady對軟件演化的動態(tài)特性進行了系統(tǒng)的研究，提出了著名的關于系統(tǒng)變更的定律，被稱為Lehman定律，該定律總結了軟件在變更過程中的演化特性。

Lehman定律的主要內(nèi)容包括：

(1)軟件維護是一個必然的過程?，F(xiàn)實環(huán)境是在不斷變化的，新的需求會不斷地涌現(xiàn)，因此運行在相應環(huán)境中的軟件也應隨之發(fā)生變化，從而繼續(xù)發(fā)揮其作用。

(2)軟件的不斷修改會導致軟件的退化。因此為了防止這種退化，必須改善軟件的結構和質(zhì)量。

(3)軟件系統(tǒng)的演化特性是在早期的開發(fā)階段建立起來的。軟件規(guī)模限制著較大的變更發(fā)生，較大的變更會引起更多新的缺陷。在大型軟件開發(fā)組織中，較大的軟件變更需要組織的決策和預算的變動，而這種決策過程也制約著新版本的時間周期。

(4)軟件開發(fā)的效率與投入的資源無關。在大型軟件開發(fā)項目中，團隊成員數(shù)量的增加使項目的有效交流變得十分困難，過多的溝通時間使得開發(fā)人員沒有足夠的時間完成自己的開發(fā)任務，也會導致開發(fā)效率的相對低下。

(5)在軟件系統(tǒng)中添加新的功能不可避免地會產(chǎn)生新的缺陷，因此若軟件的功能增量較大意味著需要發(fā)布一個新版本，若新增功能較少，則其主要任務是修補這些新產(chǎn)生的軟件缺陷。

Lehman的結論揭示了軟件演化的普遍特性，現(xiàn)實環(huán)境決定了軟件系統(tǒng)不可避免地發(fā)生變更，軟件的持續(xù)變更又會引入新的缺陷，甚至會破壞原有的系統(tǒng)結構。對于軟件變更引起的各種問題，人們通常采用不同的策略進行處理，即進行軟件維護和軟件再工程。13.1.2遺留系統(tǒng)問題

許多大型系統(tǒng)往往具有較長的生命周期，使用時間多為10年以上。由于某些軟件在業(yè)務中的重要性和穩(wěn)定性，一些機構甚至仍然依賴于已經(jīng)有20多年歷史的軟件系統(tǒng)，因此，這些老系統(tǒng)出現(xiàn)任何問題都會對機構的業(yè)務帶來巨大影響。人們把這些老系統(tǒng)稱為遺留系統(tǒng)。經(jīng)歷長時間運行的遺留系統(tǒng)往往已不是最初交付的系統(tǒng)，這期間系統(tǒng)內(nèi)、外部環(huán)境的變化，如市場、法規(guī)、管理上的變化以及軟、硬件技術的發(fā)展等，都使軟件系統(tǒng)面對新的需求，需要隨著業(yè)務的變化而改變。因此，遺留系統(tǒng)在其生命周期中是不斷變更著的，但如果要拋棄一個遺留軟件系統(tǒng)，用一個全新開發(fā)的軟件系統(tǒng)去替換它，則存在巨大風險，其原因在于：首先，遺留系統(tǒng)很少具有完整的文檔，往往最初的文檔已經(jīng)不存在了，即使存在，也很難包含所做變更的所有細節(jié)，因此，很難有一個簡單的方法可以產(chǎn)生與遺留系統(tǒng)功能相同的新系統(tǒng)。其次，業(yè)務過程和遺留系統(tǒng)的操作方式緊密地“交織”在一起。這些業(yè)務過程已經(jīng)根據(jù)軟件服務的特點做了調(diào)整，為的是充分發(fā)揮軟件服務的優(yōu)勢，彌補其不足。如果系統(tǒng)被替換，這些過程也必須改變。這樣一來，替換的成本以及對業(yè)務的影響就難以估量。另外，重要的業(yè)務規(guī)則隱藏在軟件內(nèi)部，業(yè)務規(guī)則是對某些業(yè)務功能施加的約束，新的系統(tǒng)可能會打破這些規(guī)則，從而會給業(yè)務帶來不可預知的結果。例如，一家保險公司可能將保單申請的風險評估規(guī)則嵌入到軟件中，如果不保留這些規(guī)則，公司就可能接受高風險保單，由此帶來日后昂貴的賠付。同時，開發(fā)新軟件本身是有風險的，所以新系統(tǒng)會遇到難以預料的問題。它可能無法按時交付，對軟件支付的價格也可能要超出預期的估計。在這種情況下，繼續(xù)使用遺留系統(tǒng)則可以避免以上所述風險，但是對現(xiàn)有軟件進行變更也會帶來較大的代價，越老的系統(tǒng)越是如此。其主要的原因在于：系統(tǒng)的不同部分是由不同的團隊實現(xiàn)的，整個系統(tǒng)中的程序設計風格是不一致的；系統(tǒng)的部分或全部可能是用一種已被淘汰的編程語言寫的，目前已難以找到能使用這種語言的程序員；系統(tǒng)文檔通常是不充分的和過時的。有些時候，系統(tǒng)源代碼是唯一的系統(tǒng)文檔，而有些時候系統(tǒng)源代碼已經(jīng)不復存在，只剩下系統(tǒng)的可執(zhí)行版本；經(jīng)過許多年的維護，系統(tǒng)結構可能已經(jīng)被破壞，理解系統(tǒng)設計的難度逐漸加大。加進來的新程序可能以一種特別的接口方式與系統(tǒng)的其他部分對接；系統(tǒng)可能對空間或運行速度進行了優(yōu)化，但可讀性不好，這對那些掌握現(xiàn)代軟件工程技術的人員來說理解起來是相當困難的。源程序中可能使用了許多小的程序設計竅門，對新人來說同樣是極難弄懂的。系統(tǒng)所處理的數(shù)據(jù)可能保留在一些結構不相容的文件中，這些文件中的數(shù)據(jù)可能存在重復現(xiàn)象，數(shù)據(jù)也已經(jīng)過時、不精確，也不完整。因此，如果繼續(xù)使用遺留系統(tǒng)，根據(jù)需要做系統(tǒng)變更，成本不可避免地要增加。如果用新系統(tǒng)替換遺留系統(tǒng)，費用和風險也會很高，而且新系統(tǒng)不一定能像遺留系統(tǒng)那樣對系統(tǒng)提供有力的支持。所以需要有軟件工程技術來延長遺留系統(tǒng)的生命周期，降低系統(tǒng)的維護成本，即進行軟件維護和軟件再工程。

13.2軟件維護

13.2.1軟件維護內(nèi)容

1．軟件維護的類型

軟件維護活動可以分為三種典型的類別：改正性維護、適應性維護、完善性維護。另外不排除其他類型的一些維護，如預防性維護。在軟件交付使用后，由于開發(fā)時測試的不徹底、不完全，必然會有一部分隱藏的錯誤被帶到運行階段來，這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當對軟件進行診斷和修正錯誤，稱之為改正性維護。例如，改正性維護可以是改正原來程序中未使開關復原的錯誤；解決開發(fā)時未能測試各種可能情況帶來的問題等。適應性維護是指隨著計算機的飛速發(fā)展，外部環(huán)境(新的硬、軟件配置)或數(shù)據(jù)環(huán)境(數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入輸出方式、數(shù)據(jù)存儲介質(zhì))可能發(fā)生變化，為了使軟件適應這種變化，而去修改軟件的過程。例如，適應性維護可以是為現(xiàn)有的某個應用問題實現(xiàn)一個數(shù)據(jù)庫，對某個指定的事務編碼進行修改，增加字符個數(shù)；調(diào)整兩個程序，使它們可以使用相同的記錄結構；修改程序，使其適用于另外一種終端。完善性維護是指在軟件的使用過程中，根據(jù)用戶對軟件提出的新的功能與性能要求，來修改、再開發(fā)軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。例如，完善性維護可能是修改一個計算工資的程序，使其增加新的扣除項目；提高系統(tǒng)響應速度，以達到特定的要求；改進用戶與程序的對話方式；改進圖形輸出，增加聯(lián)機幫助功能；為軟件的運行增加監(jiān)控設施等。在維護階段的頭兩年，改正性維護的工作量較大。隨著錯誤發(fā)現(xiàn)率急劇降低，并趨于穩(wěn)定，就進入了正常使用期。然而，由于變化的需求，適應性維護和完善性維護的工作量逐步增加，在這種維護過程中又會引入新的錯誤，從而加重了維護的工作量。實踐表明，在幾種維護活動中，完善性維護所占的比重最大，即大部分維護工作是改變和加強軟件，而不是糾錯。所以，維護是有計劃、有預謀的一種再開發(fā)活動。統(tǒng)計說明，來自用戶要求擴充、加強軟件功能和性能的維護活動約占整個維護工作的50%。預防性維護是為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎。通常，預防性維護定義為：“把今天的方法用于昨天的系統(tǒng)以滿足明天的需要。”

如圖13.1所示，在整個維護階段的全部工作中，預防性維護只占很小的比例，而完善性維護占了近1/2的工作量。從圖13.2中可知，軟件維護花費的工作占整個生存期工作量的70%以上，這是由于在軟件運行過程中要不斷對軟件進行修改，以改正新發(fā)現(xiàn)的錯誤、適應新的環(huán)境和用戶新的要求。這些修改需要花費很多精力和時間，而且有時修改不正確，還會引入新的錯誤。同時，軟件維護技術不像開發(fā)技術那樣成熟、規(guī)范化，自然消耗工作量就較多。圖13.1幾類維護占總維護的比例圖13.2維護在軟件生存期所占的比例

2．軟件維護成本

在系統(tǒng)的維護過程中，需要花費較大的工作量，不可避免地涉及到軟件的維護成本問題。隨著軟件規(guī)模和復雜性的不斷增長，軟件維護的成本呈現(xiàn)上升的趨勢。除此之外，軟件維護還有無形的代價，由于維護工作占據(jù)著軟件開發(fā)的可用資源，因而有可能使新的軟件開發(fā)因投入的資源不足而受到影響，甚至錯失市場良機。況且，由于維護時對軟件的修改，在軟件中引入了潛在的故障，從而降低了軟件的質(zhì)量。系統(tǒng)的大小、程序設計語言、系統(tǒng)的生命周期長短、軟件所采用的開發(fā)技術等是維護工作量的決定因素。

通常，系統(tǒng)越大、越復雜，維護人員閱讀和理解該軟件就越困難，因此，需要維護的工作量和成本就越大。

使用功能強的程序設計語言，可以比較好地控制程序的規(guī)模，所生成的指令數(shù)也比較少；反之，實現(xiàn)相同的功能所需的語句就越多，相應程序就越大。早期，很多軟件使用的程序設計語言較落后，所編寫的程序邏輯性混亂，且程序的內(nèi)聚和封裝特性較差，導致程序的可讀性、可維護性較差。早期的老系統(tǒng)(遺留系統(tǒng))除了設計結構上存在的缺陷，通常還會面臨沒有文檔，或文檔太少的問題。另一方面，隨著軟件的不斷修改，系統(tǒng)結構嚴重退化，長期的維護過程使得文檔與程序不一致，程序也變得越來越難理解。所以，老系統(tǒng)和生命周期較長的系統(tǒng)需要更多的維護成本。

近年來，數(shù)據(jù)庫技術越來越成熟，在數(shù)據(jù)管理的應用領域中起著非常重要的作用。使用數(shù)據(jù)庫可以簡單有效地存儲和管理程序中的數(shù)據(jù)，數(shù)據(jù)庫工具可以很方便地修改和擴充報表等，因此，數(shù)據(jù)庫技術的應用可以減少維護工作量。在軟件開發(fā)中，如果使用能使軟件結構比較穩(wěn)定的分析與設計方法以及程序設計技術，如復用技術、面向對象技術等，將大大減少軟件的維護成本。

另外，軟件在程序中是否使用了數(shù)學模型、任務的難度、IF嵌套的深度等因素都會對系統(tǒng)維護成本有影響。

用于維護的工作量可以分成生產(chǎn)性活動和非生產(chǎn)性活動。例如，分析評價、修改設計和實現(xiàn)的源代碼等是生產(chǎn)性活動；理解程序的功能、解釋與判斷數(shù)據(jù)結構、接口特點、性能的限度等是非生產(chǎn)性活動。

維護工作量可以用一個模型表達：

M=P+

K×exp(c-d)

其中，M是維護的工作量；P是生產(chǎn)性工作量；K是經(jīng)驗常數(shù)；c是因為缺乏好的方法和文檔而導致軟件的復雜度；d是維護人員對軟件熟悉的程度。

該模型說明，如果沒有一個好的軟件開發(fā)途徑，原來的開發(fā)人員不能參加維護工作，則維護工作量(成本)將按指數(shù)級增加。

3．降低維護成本的策略

根據(jù)影響軟件維護工作量的各種因素，一些策略被用于軟件開發(fā)過程，以控制維護成本。

在軟件開發(fā)過程中，通過采用新技術，可大大提高可靠性，并減少進行改正性維護的需要。這些技術包括數(shù)據(jù)庫管理系統(tǒng)、軟件開發(fā)環(huán)境、程序自動生成系統(tǒng)和較高級(第四代)語言，應用這四種技術可產(chǎn)生更加可靠的代碼。此外，利用應用軟件包可開發(fā)出比完全由用戶自己開發(fā)的系統(tǒng)可靠性更高的軟件；采用面向對象和結構化技術可以使軟件有良好的可維護性；將自檢能力引入程序，通過非正常狀態(tài)的檢查，提供審查跟蹤，可降低發(fā)現(xiàn)和改正錯誤的代價；周期性維護審查易于在形成維護問題之前就可確定質(zhì)量缺陷。軟件的適應性維護不可避免，但可以控制。在開發(fā)過程中，若配置管理時，把硬件、操作系統(tǒng)和其他相關環(huán)境因素的可能變化考慮在內(nèi)，可以減少某些適應性維護的工作量；把硬件、操作系統(tǒng)，以及其他外圍設備有關的程序歸到特定的程序模塊中，可以把因環(huán)境變化而必須修改的程序局限在某些程序模塊之中；使用內(nèi)部程序列表、外部文件，以及處理的例行程序包，可為維護時修改程序提供方便。

開發(fā)過程可建立軟件系統(tǒng)的原型，在實際系統(tǒng)開發(fā)之前把它提供給用戶，用戶通過研究原型進一步完善它們的功能要求，就可以減少以后完善性維護的需要。13.2.2軟件維護過程

軟件維護過程又稱為軟件維護活動。由于在軟件的運行過程中，需要不斷地進行修改和完善，使得維護工作量逐年上升。軟件維護過程與軟件類型、軟件開發(fā)過程以及人員因素有著密切的關系。

軟件維護過程由一系列變更請求觸發(fā)。變更請求可能來自系統(tǒng)用戶、管理層或者客戶。一旦變更請求獲得批準，就要對系統(tǒng)規(guī)劃一個新版本，然后實現(xiàn)這個變更。軟件維護過程的參考模型如圖13.3所示。圖13.3軟件維護過程模型

1．軟件維護組織

通常并不需要建立一個正式的維護機構，在一個維護過程中，每一位參加維護的人員都要明確自己的責任，為了減少維護過程的混亂，建立一種非正式的組織還是有必要的。軟件維護組織如圖13.4所示圖13.4軟件維護組織維護申請?zhí)峤唤o一個維護管理員，維護管理員將申請交給某個系統(tǒng)監(jiān)督員去評價。系統(tǒng)監(jiān)督員是技術人員，他必須熟悉產(chǎn)品程序的某一部分。一旦做出評價，由修改負責人確定如何進行修改。在維護人員對程序進行修改的過程中，由配置管理員嚴格把關，控制修改的范圍，對軟件配置進行審計。

維護管理員、系統(tǒng)監(jiān)督員、修改負責人等，均代表維護工作的某個職責范圍。修改負責人、維護管理員可以是指定的某個人，也可以是一個包括管理人員、高級技術人員在內(nèi)的小組。系統(tǒng)監(jiān)督員可以有其他職責，但應具體分管某一個軟件包。

2．軟件維護申請報告

應該用標準的格式提出軟件維護的申請。維護申請報告是由軟件組織外部提交的文檔，它是軟件維護工作的基礎。維護組織接到的申請報告由維護管理員和系統(tǒng)監(jiān)督員來研究處理。

軟件維護申請報告應說明產(chǎn)生錯誤的情況，如輸入的數(shù)據(jù)、錯誤的清單等。如果申請的是適應性和完善性維護，用戶必須提出一份修改說明書，列出所有希望的修改。維護申請報告由維護管理員和系統(tǒng)監(jiān)督員來研究處理。維護申請報告是由軟件組織外部提交的文檔，它是計劃維護工作的基礎。軟件組織內(nèi)部應相應地做出軟件修改報告(SCR)，指明以下問題。

(1)所需要修改的性質(zhì)；

(2)申請修改的優(yōu)先級；

(3)為滿足某一項維護申請所需要的工作量；

(4)預計修改后的狀況。

3．軟件維護流程

軟件維護流程如圖13.5所示，維護流程的第一步是先確認維護要求，弄清錯誤概況及對業(yè)務影響的大小，以及用戶希望做什么樣的修改，并把這些情況存入故障數(shù)據(jù)庫，然后由維護組織管理員確認維護類型。圖13.5維護的工作流程對于改正性維護申請，從評價錯誤的嚴重性開始。如果存在嚴重的錯誤，則必須安排人員在系統(tǒng)監(jiān)督員的指導下，進行問題分析、尋找問題發(fā)生的原因、進行“救火”性的緊急維護；對于不嚴重的錯誤，可根據(jù)任務，視輕重緩急進行排隊，統(tǒng)一安排時間。

對于適應性維護和完善性維護申請，需要先確定每項申請的優(yōu)先次序。若某項申請的優(yōu)先級非常高，就可以立即開始維護工作。否則，維護申請和其他的開發(fā)工作一樣，進行排隊，統(tǒng)一安排時間。并不是所有的完善性維護申請都必須承擔，因為它相當于做二次開發(fā)，工作量很大，所以要根據(jù)業(yè)務需要，可利用資源的情況，以及其他的考慮，決定是否承擔。

4．軟件維護記錄

為了估計軟件維護的有效程度，應該做好維護記錄。記錄的內(nèi)容可考慮以下項目：

●程序標識(名稱)；

●源程序行數(shù)；

●機器指令條數(shù)；

●所用的程序設計語言：

●程序安裝的日期；

●程序安裝后運行的次數(shù)；

●程序安裝后失敗的次數(shù)；●程序改變的層次及名稱；

●修改程序所增加的源程序行數(shù)；

●修改程序所減少的源程序行數(shù)；

●每次修改所付出的“人時”數(shù)；

●程序修改的日期；

●軟件維護人員的姓名；

●維護申請報告的標識(名稱)；

●維護類型；

●維護的開始時間和結束時間；

●累計用于維護的“人時”數(shù)；

●完成維護任務的純收益。

5．軟件維護評價

如果已具有軟件維護記錄，則可以對維護工作進行評價?？晒﹨⒖嫉亩攘恐凳牵?/p>

●程序每次運行的平均失效次數(shù)；

●各類維護活動所花費的總“人時”數(shù)；

●每個程序、每種語言、每種維護類型所做的程序變動平均數(shù)；

●因為維護而增加或刪除一個源程序語句，平均花費的“人時”數(shù)；

●維護每一種語言的程序所花費的“人時”數(shù)；

●維護申請報告的平均處理時間；

●各類維護申請的百分比。

13.3軟?件?再?工?程

13.3.1再工程活動

從技術角度來看，軟件再工程似乎是軟件演化問題的一個次優(yōu)級解決方案。比如將集中式的軟件體系結構轉換為分布式非常困難；通常也不大可能從根本上改變系統(tǒng)所用的程序語言，這意味著一些老系統(tǒng)難以被轉換到如Java或C++?這樣的面向對象程序設計語言上；且由于軟件功能沒有變化，所以系統(tǒng)原有的局限性仍然存在。然而，從業(yè)務角度看，對于有較高使用價值的軟件系統(tǒng)，再工程可能是保證遺留系統(tǒng)能繼續(xù)提供服務唯一可行的方法。改用其他任何方案都將帶來更高的費用和更高風險。原因在于遺留系統(tǒng)中的代碼量是極大的。

20世紀90年代以后，支持業(yè)務過程的計算機應用在大幅增加。因此，估計到目前為止，大約有2500億行源代碼需要維護；其中大部分都不是采用面向對象語言編寫的，而且它們大多數(shù)是運行在大型機平臺上。軟件系統(tǒng)再工程方法與其他方法相比有兩個絕對優(yōu)勢：一是可減少風險。對機構所用的某個基本軟件系統(tǒng)做重新開發(fā)是個高風險的決策，比如系統(tǒng)中會發(fā)生錯誤，會出現(xiàn)開發(fā)中的種種問題等；二是可降低成本。再工程的成本較之重新開發(fā)一個軟件的成本來說要小得多。比如一個商業(yè)系統(tǒng)，該系統(tǒng)新開發(fā)的成本高達5000萬美元，而再工程的成本僅僅1200萬美元。有數(shù)據(jù)表明，再工程的費用大約是重寫同一個系統(tǒng)費用的1/4。另外，軟件再工程和業(yè)務過程再工程有密切的關聯(lián)。業(yè)務過程再工程是指重新設計業(yè)務過程來減少多余的活動并提高過程的效率。由于遺留系統(tǒng)與現(xiàn)有業(yè)務過程存在著固有的依賴關系，業(yè)務再工程通常是軟件進化的驅動器。由于軟件系統(tǒng)與業(yè)務過程存在著這些聯(lián)系，因此，當業(yè)務過程再工程需要對軟件系統(tǒng)做大的改變，而這又不可能通過程序維護達到時，就需要對軟件系統(tǒng)進行再工程。再工程與新軟件開發(fā)之間的重要差別在于軟件開發(fā)的起點上。再工程不是從系統(tǒng)需求定義開始，而是將舊系統(tǒng)作為新系統(tǒng)的定義。如果稱傳統(tǒng)的開發(fā)為正向工程，則正向工程和再工程的區(qū)別如圖13.6所示。正向工程開始于系統(tǒng)定義，并進行設計和實現(xiàn)。再工程開始于已有的系統(tǒng)，開發(fā)過程基于對原始系統(tǒng)的理解和轉換。圖13.6正向工程和再工程

圖13.7所示是一個可能的再工程過程。過程的輸入是一個遺留程序，輸出是一個結構化和模塊化的程序新版本。在程序再工程的同時，系統(tǒng)的數(shù)據(jù)也可能要被再工程。圖13.7再工程過程再工程過程中的主要活動有：

(1)源代碼轉換。程序從舊的程序設計語言轉換到相同語言的一個較新的版本或另一種語言。

(2)逆向工程。對程序進行分析并從中抽取信息以獲取系統(tǒng)的結構和功能信息、恢復系統(tǒng)文檔。

(3)程序結構改善。對程序的控制結構進行分析和修改，使它更容易讀和理解。

(4)程序模塊化。程序的相關部分被收集在一起，在一定程度上消除冗余。在某些情況下，這個階段可能會產(chǎn)生軟件系統(tǒng)體系結構的轉換。

(5)數(shù)據(jù)再工程。對程序處理的數(shù)據(jù)做改變來反映程序變更。再工程不一定需要圖13.7中的所有步驟，如果所用的程序設計語言仍能得到編譯器支持，源代碼就沒有必要做轉換；如果再工程完全依賴于自動化工具，那么通過逆向工程來恢復文檔就沒有必要。數(shù)據(jù)再工程只有在程序中數(shù)據(jù)結構發(fā)生改變時才需要。再工程不管怎樣總是包括一些程序重建工作。

再工程的成本明顯依賴于所做的工作范圍。圖13.8給出了再工程可能使用的方法，成本從左到右逐漸增長，所以源代碼轉換是最經(jīng)濟的活動，而再工程加上一部分體系結構改變是費用最高的活動。圖13.8再工程方法除了再工程的范圍之外，影響再工程成本的主要因素還有：

(1)需要再工程的軟件的質(zhì)量。軟件和相關文檔(如果存在)越少，再工程的成本就會越高。

(2)可用的工具支持。除非能使用CASE工具自動完成大多數(shù)的程序變更，否則一般來說再工程的成本會很高。

(3)所需的數(shù)據(jù)轉換的范圍。如果再工程需要對大量數(shù)據(jù)做轉換，這將極大地增加過程的成本。

(4)成員的可用性。如果負責維護系統(tǒng)的人員不能參與到再工程過程中來，這將會增加成本，系統(tǒng)再工程人員需要花很多的時間來理解系統(tǒng)。再工程的缺點是系統(tǒng)經(jīng)過再工程得以改善的范圍有限。比如，它不能把面向功能的系統(tǒng)轉換為面向對象的系統(tǒng)；主要體系結構的變更或對系統(tǒng)數(shù)據(jù)管理的重新組織不能自動地執(zhí)行，因此需要額外的高成本；雖然再工程能改善可維護性，但經(jīng)過再工程的系統(tǒng)不可能像用現(xiàn)代軟件工程方法開發(fā)的新系統(tǒng)一樣容易維護。13.3.2源代碼轉換

軟件再工程的一個最簡單的形式是程序轉換，將原用一種語言編寫的源代碼轉換為以另一種語言編寫的源代碼，程序本身的結構和組織不發(fā)生變化。目標語言可以是原先使用

的語言的新版本，例如從COBOL-74到COBOL-85；或者是一種全新的語言，例如從FORTRAN到C語言。源代碼轉換有時是必要的，一是因為硬件平臺升級，硬件平臺升級后，最初語言編譯器可能無法在新硬件平臺上使用；二是技術人員不足。軟件的生命周期較長時，受過最初語言維護培訓的人員可能越來越缺乏，例如，原金融系統(tǒng)普遍采用的COBOL語言，在我國的軟件人員中，熟練掌握的較少。另外，機構的政策變更也是一個因素。機構可能決定統(tǒng)一所用的語言，從而將支持軟件成本減到最少。再者，原有系統(tǒng)可能缺乏軟件和工具的支持。例如，語言編譯器的提供商可能不再從事這項業(yè)務，或者是不再支持這個產(chǎn)品，市場上也缺乏支持這些語言的維護和開發(fā)工具。圖13.9說明了源代碼轉換的過程。在這個過程中，不需要理解軟件運行的詳細內(nèi)容，也沒有必要修改系統(tǒng)體系結構。所需的分析集中在編程語言本身，如考慮程序的控制結構等價性等。圖13.9程序轉換過程值得注意的是，只有存在源代碼的自動轉換軟件能對大部分源代碼自動進行轉換時，源代碼轉換才是經(jīng)濟的。源代碼轉換器可能是從一種語言轉換到另一種語言的專門工具或是模式匹配系統(tǒng)。如果是模式匹配系統(tǒng)，必須給出一組規(guī)則描述說明該如何從一種表示法轉換到另外一種表示法。源語言中的參數(shù)化模式是需要定義的，然后將它映射到目標語言，作為一種等價模式。在許多情況下，完全的自動轉換是不存在的。源語言中的結構可能在目標語言中沒有直接的等價形式，比如源代碼中嵌入的條件編譯指令在目標語言中得不到支持。在這些情形下，需要手工完成系統(tǒng)的代碼轉換。13.3.3逆向工程

很多情況下，時間的流逝和開發(fā)過程的不規(guī)范會造成軟件文檔的缺失，為維護帶來較大困難，逆向工程致力于解決這類問題。逆向工程是以復原軟件的描述和設計為目標的對軟件的分析過程。程序本身經(jīng)過逆向工程過程并無變化。逆向工程過程通常從軟件源程序代碼著手，如果源代碼遺失，逆向工程只好從可執(zhí)行代碼分析開始。

逆向工程不同于再工程，逆向工程的目標是要從軟件的源程序代碼導出系統(tǒng)的設計和描述，而再工程的目標是產(chǎn)生一個新的更易維護的系統(tǒng)。軟件再工程過程借助逆向工程來復原程序設計，以幫助工程師在重組系統(tǒng)的結構之前理解程序。盡管如此，逆向工程并不總是與再工程一起進行，一是對現(xiàn)行系統(tǒng)進行逆向工程所生成的設計和描述可以作為系統(tǒng)替代品的需求描述的參考，以利于構造和開發(fā)新系統(tǒng)；二是逆向工程所得的設計和描述有助于程序的維護，通過逆向工程恢復的信息和文檔，可以不必再對系統(tǒng)源代碼進行再工程。圖13.10說明了逆向工程的過程。逆向工程始于一個分析階段。在這個階段中，使用自動化工具對系統(tǒng)進行分析來發(fā)現(xiàn)它的結構。但這不足以重建出系統(tǒng)的設計，還要參考系統(tǒng)源代碼和系統(tǒng)的結構模型，在對系統(tǒng)理解的基礎上添加信息到所收集的設計信息中。這些信息被組織為有向圖模型，這些模型與程序源代碼相關聯(lián)，例如程序的控制流圖、數(shù)據(jù)流圖等。圖13.10逆向工程過程文檔生成工具可以將信息庫的圖結構和代碼生成為可被開發(fā)人員理解的各類文檔，并使用分析的信息加以注釋，例如程序和數(shù)據(jù)結構圖、可追溯矩陣等。可追溯矩陣表示出程序實體是在系統(tǒng)何處定義的又是在何處被引用的，如對一個函數(shù)，其追溯矩陣可表示出函數(shù)的算法設計、需求定義出處等。文檔生成的過程是個循環(huán)的過程，因為設計信息又可以用于對系統(tǒng)存儲中的信息做進一步的提煉。用于程序理解的工具可以用于支持逆向工程過程。這些工具通常依據(jù)不同的建模規(guī)范和建模角度表現(xiàn)出不同的系統(tǒng)視圖，例如有的逆向工具可生成UML模型視圖，而有的工具則生成控制流程圖。視圖提供在源程序代碼間的導航。

在系統(tǒng)設計文檔產(chǎn)生出來之后，通常需要對系統(tǒng)結構做進一步的手工注釋，因為描述不可能完全從系統(tǒng)模型中自動導出。13.3.4程序結構改善

許多遺留系統(tǒng)的結構較差，受當時的軟件技術所限，在程序的控制結構中可能存在很多無條件分支和難以理解的控制邏輯，而頻繁的維護往往會使控制結構變得更糟。例如，對程序所做的變更可能使得某些代碼變得根本不可達，而維護人員也不敢輕易刪除這些代碼，以防萬一這些代碼被間接訪問到。

表13.1中的例子是個供暖系統(tǒng)控制器，這是一個相對較簡單的程序，但由于使用非結構化的程序設計而使其控制邏輯變得復雜和難以理解。該程序是使用類似于FORTRAN語言編寫的。在該例子中，面板開關可以設置為On、Off或Controlled。如果系統(tǒng)處于受控狀態(tài)，那么開關置于開和關狀態(tài)依賴于定時器和溫度調(diào)節(jié)裝置的設定。如果加熱器處于開狀態(tài)，Switch-heating把它轉換為關狀態(tài)，反之亦然。

在這個示例中，大量使用了無條件轉移語句，致使程序結構不是很好，也較難理解。隨著維護過程中不斷進行修改，程序中的邏輯結構變得更為復雜。新的條件和相關的動作被添加進舊的控制結構中。在短期內(nèi)，這是一種降低風險的做法，因為減少了向系統(tǒng)中引入缺陷的可能性。但是，長期來看，這樣做的后果是使代碼難以理解，同時，修改過程中程序員試圖避免代碼重復造成了復雜的代碼結構。表13.2給出的是用結構化控制語句對同一控制系統(tǒng)的改寫。程序可以從上到下順序閱讀，所以要容易理解得多。三個開關位置(開、關和受控)被清晰地表示出來并連接到相應代碼。因為最初的語言不是面向對象的，所以未用面向對象的語言來改寫。表13.1中無結構的控制，使復雜的條件語句在程序結構重構過程中得到簡化。表13.3說明了含有“非”邏輯的條件語句是如何簡化的，從而使程序變得更容易理解。程序結構的重構和改善可以采用自動程序重構工具來實現(xiàn)?？梢宰C明任何程序都可以用簡單的if-then-else條件語句和while-loop語句重寫，無條件goto語句是不必要的，這是自動程序重構的基礎。圖13.11給出了運用軟件工具實現(xiàn)自動程序結構重構的幾個階段。首先是將待重構的原程序轉換為有向圖，然后依據(jù)有向圖生成一個不帶goto語句的結構化的等價程序。圖13.11自動的程序結構化過程有向圖為程序流圖模型，可以描述程序中的控制轉移結構，類似于第12章中介紹的自動靜態(tài)分析技術，通過它可以檢測出代碼中的不可達部分并刪除之。在此基礎上，根據(jù)程序的重寫規(guī)則就可以生成新的程序。while-loop語句和簡單條件語句代替了基于goto的語句控制。重構后的程序可以使用原先的語言，也可以使用一種不同的語言，例如可以從FORTRAN語言轉換為C語言。使用自動程序結構重構工具會帶來注釋和文檔信息的缺失。如果原程序中有內(nèi)嵌的注釋，會因使用軟件重構工具而造成注釋不可再現(xiàn)；外部的程序文檔和原程序之間的映射關系也會因結構重構而變得不再有效。

另外，結構重構工具的算法較為復雜，如果需要重構的系統(tǒng)較為龐大，則重構計算的過程需要很大的計算量和較長的時間。而通常，需要重構的系統(tǒng)不會是一個簡單系統(tǒng)。代碼結構重構對于那些非結構化程序系統(tǒng)和非良構的結構化系統(tǒng)較為有效。如果程序是數(shù)據(jù)驅動的，則組件間通過共享數(shù)據(jù)結構緊密地耦合在一起，代碼結構重構就不一定能帶來很大的改善。

在某些情況下，對系統(tǒng)所有程序做結構重構并不合理，因為系統(tǒng)中有些程序的質(zhì)量較好，而有些則沒有經(jīng)過頻繁變更。一般情況下，應該收集數(shù)據(jù)幫助分析哪些程序通過結構重構能得到較大的改善?？梢酝ㄟ^度量程序的失效率、源代碼每年變更的百分比、組件復雜性以及組件達到現(xiàn)行標準的等級找出結構重構的候選對象。13.3.5程序模塊化

程序模塊化也是對程序重新組織的過程，其目標是改善原有老系統(tǒng)的模塊化特性。程序模塊化將系統(tǒng)中具有緊密關聯(lián)的程序部分聚集在一起作為單一模塊。程序模塊化能消除相關組件中的冗余、優(yōu)化組件間的交互、弱化它們與其他程序的耦合。例如對于一個氣象數(shù)據(jù)收集和氣象地圖生成處理系統(tǒng)，與數(shù)據(jù)的圖形化表示相關的操作可以被集合在一起作為一個模塊，負責驅動設備采集數(shù)據(jù)的程序作為一個模塊，負責傳送處理分布于各個氣象站的數(shù)據(jù)的程序作為一個模塊。在程序模塊化過程中創(chuàng)建的模塊類型可以有很多，包括：

(1)數(shù)據(jù)抽象模塊。將數(shù)據(jù)和處理部分相關聯(lián)，形成抽象數(shù)據(jù)類型。例如，對于面向對象的系統(tǒng)，這些模塊可被封裝成一個對象類，通過對象接口對其訪問。

(2)硬件模塊。這些模塊是與硬件緊密相關的，把控制特殊硬件設備的功能集中在一起。

(3)功能模塊。這些模塊是相似功能或與任務緊密相關的功能的集合。例如，所有的有關輸入和輸出有效性驗證的功能可以被放在一個模塊中。

(4)過程模塊。這些模塊是支持一個特定業(yè)務過程所需要的功能和數(shù)據(jù)的集合。例如，在圖書館管理系統(tǒng)中，過程模塊可能包括支持圖書發(fā)放和歸還所需的所有功能處理。13.3.6數(shù)據(jù)再工程

迄今為止，有關軟件演化的大多數(shù)討論把重心集中在程序和軟件系統(tǒng)變更上。然而在許多情況下，軟件演化還涉及到數(shù)據(jù)進化的問題。遺留系統(tǒng)所處理的數(shù)據(jù)，其存儲、組織和格式也須經(jīng)過演化來適應軟件的變更。對數(shù)據(jù)結構的分析和重組過程，有時還包括對系統(tǒng)中的數(shù)據(jù)值的分析過程，被稱為數(shù)據(jù)再工程，這些過程有助于更好地理解這些數(shù)據(jù)結構及其值。原則上講，如果系統(tǒng)的功能沒有發(fā)生改變，那么數(shù)據(jù)再工程就沒有必要。但在實際過程中，會因種種原因使得在對遺留系統(tǒng)的程序做修改時也需要同時修改數(shù)據(jù)結構或數(shù)據(jù)。

首先，由于系統(tǒng)的數(shù)據(jù)可能會退化。隨著時間的推移，數(shù)據(jù)的質(zhì)量在逐步下降。長期的維護過程中，由于對數(shù)據(jù)的變更引入了錯誤，數(shù)據(jù)可能產(chǎn)生了多個副本，來自外部環(huán)境的變更也可能沒有反映到數(shù)據(jù)中。其次，是因為程序本身的限制。在進行最初的設計時，很多程序的開發(fā)者對所處理的數(shù)據(jù)量都有一定的限制。然而，程序現(xiàn)在時常需要處理比估計的數(shù)據(jù)量多的數(shù)據(jù)。數(shù)據(jù)再工程需要修正或取消這些限制。例如，20和21世紀之交的千年蟲問題，就引起了全球大量系統(tǒng)的再工程。

另外，體系結構需要進化。例如，現(xiàn)在的系統(tǒng)廣泛建立在計算機網(wǎng)絡的基礎上，其系統(tǒng)結構是分布式的。如果一個老的遺留系統(tǒng)，其集中式的處理要轉換到分布式體系中，其核心是能被遠程客戶機訪問的數(shù)據(jù)庫管理系統(tǒng)，就需要較大的數(shù)據(jù)再工程工作量。表13.4反映了數(shù)據(jù)再工程的方法遺留系統(tǒng)中的數(shù)據(jù)可能有如下問題：

(1)數(shù)據(jù)的命名問題。所用的名字可能很晦澀、難以理解。在系統(tǒng)的不同程序中會給相同的邏輯實體命名不同的名字(同義)。同一個名字在不同的程序中可能用來指不同的實體。

(2)域長度問題。這個問