軟體復用

軟體復用是一種計算機軟體工程方法和理論。60年代的“軟體危機”使程序設計人員明白難於維護的軟體成本是極其高昂的，當軟體的規模不斷擴大時，這種軟體的綜合成本可以說是沒有人能負擔的，並且即使投入了高昂的資金也難以得到可靠的產品，而軟體重用的思想是解決這一問題的根本方法。

軟體復用的主要思想是，將軟體看成是由不同功能部分的“組件”所組成的有機體，每一個組件在設計編寫時可以被設計成完成同類工作的通用工具，這樣，如果完成各種工作的組件被建立起來以後，編寫一特定軟體的工作就變成了將各種不同組件組織連接體來的簡單問題，這對於軟體產品的最終質量和維護工作都有本質性的改變。

軟體復用就是將已有的軟體成分用於構造新的軟體系統。可以被複用的軟體成分一般稱作可復用構件，無論對可復用構件原封不動地使用還是作適當的修改後再使用，只要是用來構造新軟體，則都可稱作復用。軟體復用不僅僅是對程序的復用，它還包括對軟體生產過程中任何活動所產生的製成品的復用，如項目計劃、可行性報告、需求定義、分析模型、設計模型、詳細說明、源程序、測試用例等等。如果是在一個系統中多次使用一個相同的軟體成分，則不稱作復用，而稱作共享；對一個軟體進行修改，使它運行於新的軟硬體平台也不稱作復用，而稱作軟體移值。

目前及近期的未來最有可能產生顯著效益的復用是對軟體生命周期中一些主要開發階段的軟體製品的復用，按抽象程度的高低，可以劃分為如下的復用級別：

包括目標代碼和源代碼的復用。其中目標代碼的復用級別最低，歷史也最久，當前大部分編程語言的運行支持系統都提供了連接（Link）、綁定(Binding)等功能來支持這種復用。源代碼的復用級別略高於目標代碼的復用，程序員在編程時把一些想復用的代碼段複製到自己的程序中，但這樣往往會產生一些新舊代碼不匹配的錯誤。想大規模的實現源程序的復用只有依靠含有大量可復用構件的構件庫。如”對象鏈接及嵌入”（OLE）技術，既支持在源程序級定義構件並用以構造新的系統，又使這些構件在目標代碼的級別上仍然是一些獨立的可復用構件，能夠在運行時被靈活的得新組合為各種不同的應用。

設計結果比源程序的抽象級別更高，因此它的復用受實現環境的影響較少，從而使可復用構件被複用的機會更多，並且所需的修改更少。這種復用有三種途徑，第一種途徑是從現有系統的設計結果中提取一些可復用的設計構件，並把這些構件應用於新系統的設計；第二種途徑是把一個現有系統的全部設計文檔在新的軟硬體平台上重新實現，也就是把一個設計運用於多個具體的實現；第三種途徑是獨立於任何具體的應用，有計劃地開發一些可復用的設計構件。

這是比設計結果更高級別的復用，可復用的分析構件是針對問題域的某些事物或某些問題的抽象程度更高的解法，受設計技術及實現條件的影響很少，所以可復用的機會更大。復用的途徑也有三種，即從現有系統的分析結果中提取可復用構件用於新系統的分析；用一份完整的分析文檔作輸入產生針對不同軟硬體平台和其它實現條件的多項設計；獨立於具體應用，專門開發一些可復用的分析構件。

主要包括測試用例的復用和測試過程信息的復用。前者是把一個軟體的測試用例在新的軟體測試中使用，或者在軟體作出修改時在新的一輪測試中使用。後者是在測試過程中通過軟體工具自動地記錄測試的過程信息，包括測試員的每一個操作、輸入參數、測試用例及運行環境等一切信息。這種復用的級別，不便和分析、設計、編程的復用級別作準確的比較，因為被複用的不是同一事物的不同抽象層次，而是另一種信息，但從這些信息的形態看，大體處於與程序代碼相當的級別。

由於軟體生產過程主要是正向過程，即大部分軟體的生產過程是使軟體產品從抽象級別較高的形態向抽象級別較低的形態演化，所以較高級別的復用容易帶動較低級別的復用，因而復用的級別越高，可得到的回報也越大，因此分析結果和設計結果在目前很受重視。用戶可購買生產商的分析件和設計件，自己設計或編程，掌握系統的剪裁、擴充、維護、演化等活動。

軟體復用各方面的困難，無論是技術問題還是非技術問題，都影響著軟體復用的廣泛實行。

構件與應用系統之間的差異。一些開發者開發的構件，要做到在被另一些人開發的系統中使用時正好合適，從內容到對外介面都恰好相符，或者作很少的修改，這不是一件簡單的事；構件要達到一定的數量，才能支持有效的復用，而大量構件的獲得需要有很高的投入和長期的積累；發現合用構件的困難，當構件達到較大的數量時，使用者要從中找到一個自己想要的構件，並斷定它確實是自己需要的，不是一件輕而易舉的事；基於復用的軟體開發方法和軟體過程是一個新的研究實踐領域，需要一些新的理論、技術及支持環境，目前這方面的研究成果和實踐經驗都不夠充分。

軟體開發是一種創造性工作，長期從事這個行業的人們形成了一種職業習慣：喜歡自己創造而不喜歡使用別人的東西，特別是當要對別人開發的軟體作一些修改再使用時，他們常常喜歡自己另寫一個。

在軟體生產的管理中，從以往沿習了一些與復用的目標很不協調的制度與政策，如計算工作量時，對復用的部分打很大的折扣，甚至不算工作量；另外，不是在項目開始時自覺地向著造就可復用構件的方向努力，而是在它完成之後，看看是否能從中找到一些可復用構件。這些弊端妨礙了復用水平的提高和復用規模的擴大，甚至會挫傷致力於復用的人員的積極性。

在軟體科學技術的教育與培訓中，缺乏關於軟體復用的內容，很少有這方面的專門教材及課程，即使在其它教材及課程中提到軟體復用，其篇幅及內容也相當薄弱。

在法律上還存在一些問題，例如，一個可復用構件在某個應用系統中出現了錯誤，而構件的開發者和應用系統的開發者不是一個廠商，那麼責任應該由誰負？此外，在版權、政府政策等方面也存在一些懸而未決的問題。

另外，軟體產品是一種精神產品，它的產生幾乎完全是人腦思維的結果，它的價值，也幾乎完全在於其中所凝結的思想；它的物質載體的製造過程與價值含量都是微不足道的。物質產品的生產受到人類製造能力的限制，現有的一切物質產品的複雜性都沒有超過這種限度，軟體卻沒有這種限制，只要人的大腦能想到的問題，都可能要求軟體去解決，人腦所能思考的問題的複雜性，遠遠超出了人類能製造的物質產品的複雜性，因而使軟體的復用更為困難。

支持軟體復用是人們對面向對象方法寄託的主要希望之一，也是這種方法受到廣泛重視的主要原因之一。面向對象方法之所以特別有利於軟體復用，是由於它的主要概念及原則與軟體復用的要求十分吻合。

面向對象方法從面向對象的編程發展到面向對象的分析與設計，使這種方法支持軟體復用的固有特徵能夠從軟體生命周期的前期階段開始發揮作用，從而使OO方法對軟體復用的支持達到了較高的級別。與其它軟體工程方法相比，面向對象方法的一個重要優點是，它可以在整個軟體生命周期達到概念、原則、術語及表示法的高度一致。這種一致性使得各個系統成分儘管在不同的開發與演化階段有不同的形態，但可具有貫穿整個軟體生命周期的良好映射。這一優點使OO方法不但能在各個級別支持軟體復用，而且能對各個級別的復用形成統一的、高效的支持，達到良好的全局效果。做到這一點的必要條件是，從面向對象軟體開發的前期階段---OOA就把支持軟體復用作為一個重點問題來考慮。運用OOA方法所定義的對象類具有適合作為可復用構件的許多特徵，OOA結果對問題域的良好映射，使同類系統的開發者容易從問題出發，在已有的OOA結果中發現不同粒度的可復用構件。

（1）OOA模型

OOA方法建立的系統模型分為基本模型（類圖）和補充模型（主題圖與交互圖），強調在OOA基本模型中只表示最重要的系統建模信息，較為細節的信息則在詳細說明中結出。這種表示策略使OOA基本模型體現了更高的抽象，更容易成為一個可復用的系統構架。當這個構架在不同的應用系統中復用時，在很多情況下可通過不同的詳細說明體現系統之間的差異，因此對系統構件的改動較少。

(2）OOA與OOD的分工

OOA只注重與問題域及系統責任有關的信息，OOD考慮與實現條件有關的因素。這種分工使OOA模型獨立於具體的實現條件，從而使分析結果可以在問題域及系統責任相同而實現條件互異的多個系統中復用，並為從同一領域的多個系統的分析模型提煉領域模型創造了有利條件。

（3）對象的表示

所有的對象都用類作為其抽象描述。對象的一卻信息，包括對象的屬性、行為及其對外關係等等都是通過對象類來表示的。類作為一種可復用構件，在運用於不同系統時，不會出現因該類對象實例不同而使系統模型有所不同的情況。

（4）一般-特殊結構

引入對一般-特殊結構中多態性的表示法，從而增強了類的可復用性。通過對多態性的表示，使一個類可以在需求相似而未必完全相同的系統中被複用。

（5）整體-部分結構

把部分類作為可復用構件在整個類中使用，這種策略的原理與在特殊類中使用一般類是一致的，但在某些情況下，對問題域的映射比通過繼承實現復用顯得更為自然。另外還可通過整體-部分結構支持領域復用的策略---從整體對象中分離出一組可在領域範圍內復用的屬性與服務，定義為部分對象，使之成為領域復用構件。

（6）實例連接

建議用簡單的二元關係表示各種複雜關係和多元關係。這一策略使構成系統的基本成分（對象類）以及它們之間的關係在表示形式和實現技術上都是規範和一致的這種規範性和一致性對於可復用構件的組織、管理和使用，都是很有益的。

（7）類描述模板

作為OOA詳細說明主要成分的類描述模板，對於對象之間關係的描述注意到使用者與被使用者的區別，僅在使用者一端給出類之間關係的描述信息。這說明可復用構件之間的依賴關係不是對等的。因此，在繼承、聚合、實例連接及消息連接等關係的使用者一端描述這些關係，有利於這些關係信息和由它們指出的被依賴成份的同時復用。在被用者一端不描述這些關係，則避免了因復用場合的不同所引起的修改。

（8）使用CASE

由於使用CASE是對用戶需求的一種規範化描述，因此它比普通形式的需求文檔具有更強的可復用性。每個使用case 是對一個活動者使用系統的一項功能時的交互活動所進行描述，它具有完整性和一定的獨立性，因此很適於作為可復用構件。

面向對象的軟體開發和軟體復用之間的關係是相輔相成的。一方面，OO方法的基本概念、原則與技術提供了實現軟體復用的有利條件；另一方面，軟體復用技術也對面向對象的軟體開發提供了有力的支持。

（1）類庫

在面向對象的軟體開發中，類庫是實現對象類復用的基本條件。人們已經開發了許多基於各種OOPL的編程類庫，有力地支持了源程序級的軟體復用，但要在更高的級別上實現軟體復用，僅有編程類庫是不夠的。實現OOA結果和OOD結果的復用，必須有分析類庫和設計類庫的支持。為了更好地支持多個級別的軟體復用，可以在OOA類庫、OOD類庫和OOP類庫之間建立各個類在不同開發階段的對應與演化關係。即建立一種線索，表明每個OOA的類對應著哪個（或哪些）OOD類，以及每個OOD類對應著各種OO編程語言類庫中的哪個OOP類。

（2）構件庫

類庫可以看作一種特殊的可復用構件庫，它為在面向對象的軟體開發中實現軟體復用提供了一種基本的支持。但類庫只能存儲和管理以類為單位的可復用構件，不能保存其它形式的構件；但是它可以更多地保持類構件之間的結構與連接關係。構件庫中的可復用構件，既可以是類，也可以是其它系統單位；其組織方式，可以不考慮對象類特有的各種關係，只按一般的構件描述、分類及檢索方法進行組織。在面向對象的軟體開發中，可以提煉比對象類粒度更大的可復用構件，例如把某些結構或某些主題作為可復用構件；也可以提煉其它形式的構件，例如use case 或交互圖。這些構件庫中，構件的形式及內容比類庫更豐富，可為面向對象的軟體開發擔供更強的支持。

（3）構架庫

如果在某個應用領域中已經運用OOA技術建立過一個或幾個系統的OOA模型，則每個OOA模型都應該保存起來，為該領域新系統的開發提供參考。當一個領域已有多個OOA模型時，可以通過進一步抽象而產生一個可復用的軟體構架。形成這種可復用軟體構架的更正規的途徑是開展領域分析。通過正規的領域分析獲得的軟體構架將更準確地反映一個領域中各個應用系統的共性，具有更強的可復用價值。

（4）工具

有效的實行軟體復用需要有一些支持復用的軟體工具，包括類庫或構件/構架庫的管理、維護與瀏覽工具，構件提取及描述工具，以及構件檢索工具等等。以復用支持為背景的OOA工具和OOD工具在設計上也有相應的要求，工具對OOA/OOD過程的支持功能應包括：從類庫或構件/構架庫中尋找可復用構件；對構件進行修改，並加入當前的系統模型；把當前系統開發中新定義的類（或其它構件）提交到類庫（或構件庫）。

（5）OOA過程

在復用技術支持下的OOA過程，可以按兩種策略進行組織。第一種策略是，基本保持某種OOA方法所建議的OOA過程原貌，在此基礎上對其中的各個活動引入復用技術的支持；另一種策略是重新組織OOA過程。

第一種策略是在原有的OOA過程基礎上增加復用技術的支持，應補充說明的一點是，復用技術支持下的OOA過程應增加一個提交新構件的活動。即在一個具體應用系統的開發中，如果定義了一些有希望被其它系統復用的構件，則應該把它提交到可復用構件庫中。第二種策略的前提是：在對一個系統進行面向對象的分析之前，已經用面向對象方法對該系統所屬的領域進行過領域分析，得到了一個用面向對象方法表示的領域構架和一批類構件，並且具有構件/構架庫、類庫及相應工具的支持。在這種條件下，重新考慮OOA過程中各個活動的內容及活動之間的關係，力求以組裝的方式產生OOA模型，將使OOA過程更為合理，並達到更高的開發效率。