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

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

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

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

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

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

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

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

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

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

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

Lehman的結(jié)論揭示了軟件演化的普遍特性，現(xiàn)實(shí)環(huán)境決定了軟件系統(tǒng)不可避免地發(fā)生變更，軟件的持續(xù)變更又會引入新的缺陷，甚至?xí)茐脑械南到y(tǒng)結(jié)構(gòu)。對于軟件變更引起的各種問題，人們通常采用不同的策略進(jìn)行處理，即進(jìn)行軟件維護(hù)和軟件再工程。13.1.2遺留系統(tǒng)問題

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

13.2軟件維護(hù)

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

1．軟件維護(hù)的類型

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

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

2．軟件維護(hù)成本

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

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

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

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

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

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

維護(hù)工作量可以用一個模型表達(dá)：

M=P+

K×exp(c-d)

其中，M是維護(hù)的工作量；P是生產(chǎn)性工作量；K是經(jīng)驗(yàn)常數(shù)；c是因?yàn)槿狈玫姆椒ê臀臋n而導(dǎo)致軟件的復(fù)雜度；d是維護(hù)人員對軟件熟悉的程度。

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

3．降低維護(hù)成本的策略

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

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

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

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

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

1．軟件維護(hù)組織

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

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

2．軟件維護(hù)申請報告

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

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

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

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

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

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

3．軟件維護(hù)流程

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

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

4．軟件維護(hù)記錄

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

●程序標(biāo)識(名稱)；

●源程序行數(shù)；

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

●所用的程序設(shè)計語言：

●程序安裝的日期；

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

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

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

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

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

●程序修改的日期；

●軟件維護(hù)人員的姓名；

●維護(hù)申請報告的標(biāo)識(名稱)；

●維護(hù)類型；

●維護(hù)的開始時間和結(jié)束時間；

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

●完成維護(hù)任務(wù)的純收益。

5．軟件維護(hù)評價

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

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

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

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

●因?yàn)榫S護(hù)而增加或刪除一個源程序語句，平均花費(fèi)的“人時”數(shù)；

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

●維護(hù)申請報告的平均處理時間；

●各類維護(hù)申請的百分比。

13.3軟?件?再?工?程

13.3.1再工程活動

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

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

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

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

(2)逆向工程。對程序進(jìn)行分析并從中抽取信息以獲取系統(tǒng)的結(jié)構(gòu)和功能信息、恢復(fù)系統(tǒng)文檔。

(3)程序結(jié)構(gòu)改善。對程序的控制結(jié)構(gòu)進(jìn)行分析和修改，使它更容易讀和理解。

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

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

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

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

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

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

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

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

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

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

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

在系統(tǒng)設(shè)計文檔產(chǎn)生出來之后，通常需要對系統(tǒng)結(jié)構(gòu)做進(jìn)一步的手工注釋，因?yàn)槊枋霾豢赡芡耆珡南到y(tǒng)模型中自動導(dǎo)出。13.3.4程序結(jié)構(gòu)改善

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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