軟件開發方法發展回顧與展望*

馬曉星,劉譞哲,謝 冰,余 萍,張 天,卜 磊,李宣東

1(計算機軟件新技術國家重點實驗室(南京大學),江蘇 南京 210023)

2(南京大學 計算機科學與技術系,江蘇 南京 210023)

3(北京大學 信息科學技術學院 軟件研究所,北京 100871)

4(高可信軟件技術教育部重點實驗室(北京大學),北京 100871)

隨著計算機技術的飛速發展,軟件的使能空間得到了廣泛和持續的拓展,軟件系統的規模和復雜性也隨之不斷增大,人類正在進入“軟件無處不在、軟件定義一切、軟件使能一切”的時代.開發和演化軟件系統,成為人類創造財富、延續文明的重要需求和途徑.

軟件是人類制造的最復雜的一類制品,是人類大腦思維活動的體現.開發和演化軟件系統需要方法,軟件開發方法一般指“軟件開發過程需要遵循的辦法和步驟”[1](軟件開發方法在英文中常使用兩個不同的術語“Software Development Method”和“Software Development Methodology”,后者亦常翻譯為軟件開發方法學.后者傳統上更強調某種特定的覆蓋整個軟件開發周期的完整過程和技術體系,近年甚至常被誤用為軟件開發過程“Software Development Process”的同義詞.本文在較寬泛的意義下討論軟件開發方法,并使用前一英譯).長期以來,軟件開發方法的發展和演變歸納起來主要與3個方面相關聯.

· 其一是外在因素,包括運行環境(硬件、網絡、外設的發展和普及)的驅動、應用需求的牽引、信息領域技術浪潮(例如近年來涌現的大數據、云計算、物聯網、虛擬現實、人工智能等等)的推動;

· 其二是內在動力,包括效率、質量和成本.解決軟件系統規模和復雜性所導致的問題,從而高效、高質量、低成本地開發和演化軟件系統,一直是學術界和工業界追求的共同目標;

· 其三是人本屬性.人是開發和演化軟件系統的主體,軟件開發和演化方法一方面要遵循人的認識規律,另一方面要能夠充分激發、調動和管理人力資源.

自 20世紀 60年代末提出軟件工程概念至今已有 50年,其間,軟件開發方法取得了長足的發展,本文回顧50多年來軟件開發方法發展過程中的重要里程碑,包括基本方法(結構化程序設計、模塊化方法)、面向對象方法、構件化方法、面向方面方法、模型驅動的方法、服務化方法等,進而對“軟件無處不在、軟件定義一切、軟件使能一切”時代下軟件開發方法的發展趨勢進行展望.

1 軟件及其開發方法

究其本質,軟件乃是以計算為工具實現應用目標的解決方案.不同于一般物品,軟件是一種人工制品[2],同時也是一種純粹的邏輯制品[3].作為一種人工制品,其需以適應其所處環境的方式完成應用目標;作為邏輯制品,其困難不在于物理限制而在于邏輯構造.因此,軟件開發活動本質上不同于傳統工程制造.

· 后者在于“造物”;前者可謂“擬人”——即表達人腦思維形成的問題解決方案;

· 后者可有規模效應;而對前者而言,每一個軟件系統都是獨一無二的創造.

軟件開發方法所討論的是如何高效、低成本地構造高質量的軟件,這也是軟件工程學科的基本科學問題.Wirth教授在回顧軟件工程發展歷史時寫到:“如果我們能從過去學到什么的話,那就是計算機科學實際上是一門方法論學科”[4].Brooks在其“沒有銀彈”的經典演講[5]中指出:究其本質而言,軟件開發是一項困難的任務,而困難可區分為實質性的(essential)和附屬性的(accidental).可以認為,前者來自于軟件所要解決問題本身所固有的復雜性和多變性,而后者源自解決問題時所用技術手段和過程步驟方面的不妥.軟件開發方法旨在消除附屬性困難,并幫助開發者理解和駕馭問題本身的實質性困難.

軟件開發方法給出構造軟件所需的系統化的過程步驟和技術手段.這種過程和技術的背后是用于指導軟件開發這種創造性活動的思維模式.如前所述,軟件是人腦力的替代,若把軟件比擬為人,則開發方法的思維模式可比擬為軟件系統的“世界觀”和“方法論”.

· 所謂世界觀是指軟件如何抽象其所處環境和應用目標;

· 所謂方法論是指軟件本身的范型抽象,包括:結構模型,即軟件的組成元素、組合方式等靜態構成形式;運行機理,即軟件各組成元素動態運行及其間交互的機制和原理;構造方式,即如何通過層次化的問題分解和步驟分解來使系統構造成為高效可行的任務;質量保障,即如何定義并改善所構造軟件滿足目標的程度.

縱觀 50年來軟件開發方法研究和實踐的發展狀況,可以說對軟件開發和使用中各方面復雜性的應對是其一個不變的主題.早期的結構化程序設計和模塊化方法主要針對的是軟件程序本身的復雜性,而后的面向對象方法在其基礎上增強了應對應用領域問題復雜性的能力.進而,面向方面的方法又增強了面向對象方法在處理安全、日志等貫穿性的非功能屬性方面的能力.此外,軟件復用與構件化方法通過重復使用已有的軟件部件來消除重復開發的復雜性;模型驅動的方法則力圖通過提高解決問題的抽象層次來應對軟件系統日益增長的復雜性;服務化的方法通過中立的訪問協議和顯式的服務契約解耦服務的提供者和使用者,應對開放異構的互聯網環境所帶來的復雜性,并簡化了軟件的獲取和使用方式.這些方法的基本思想和實現技術成為當前軟件開發實踐的主流依托,也是本文回顧的重點.需要說明的是:這些方法之間并非是相互競爭排斥的關系,其歷史進程上也未必是線性發展的.本文回顧的順序組織只是為了便于理解的需要.除以上提及的軟件開發方法外,還有一系列的方法從人本屬性角度、在軟件組織與管理的層面被提出來并產生重要影響,比如原型方法、敏捷方法、運維一體化方法(DevOps)等,由于在本期特刊中另有論文專門討論,本文不再贅述.

當前,互聯網的不斷拓展和深化也促成了一種人機物三元融合的發展態勢,軟件日益成為信息化社會的基礎設施,其復雜程度持續提高.本文亦將在此背景下展望軟件開發方法進一步的發展趨勢.

2 基本方法

20世紀50年代末誕生的高級程序設計語言在很大程度上提高了軟件的開發效率,從而進一步催生了對軟件系統的需求,軟件系統的規模和復雜性也隨之增大,各類軟件開發方法開始出現并不斷發展.軟件開發方法是指軟件開發過程需要遵循的辦法和步驟,早期人們一般性地認為軟件開發過程主要包括問題定義、需求分析、設計、編碼、測試、維護等階段,而軟件開發方法起步于解決軟件設計階段的問題.軟件設計又分為概要設計和詳細設計兩個不同抽象階段(分別建立軟件結構和程序過程),與之對應的基本方法分別是模塊化設計方法和結構化程序設計.

2.1 結構化程序設計

結構化程序設計關注軟件詳細設計階段的程序過程(代碼)描述.1968年,Dijkstra提出了程序中無條件轉移語句(goto)有害的觀點[6],從而引起了大范圍的學術討論.經過討論,人們得到共識:goto語句使得程序的靜態結構與程序的動態執行不一致,從而使得程序難以理解和調試.在此基礎上,進一步形成了結構化程序設計的主要思想.

結構化程序設計的主要思想是:使用(僅使用)順序、選擇和重復這3種結構表示程序過程.由于這3種結構具有單入口和單出口特性,因而能夠降低程序的復雜性,易于程序理解和維護,提高了可靠性.

2.2 模塊化開發方法

模塊化方法關注軟件概要設計階段的軟件體系結構表示.面對大規模的復雜問題,人們通常的解決辦法是分而治之,把大問題看成是若干小問題的集合、把復雜問題看成是若干簡單問題的集合.軟件開發也是如此,與之對應的是模塊化方法.

軟件概要設計就是要把軟件系統的需求(功能)對應到軟件系統的各個組成部分,這些組成部分稱為模塊.模塊化是指把軟件系統劃分成獨立命名和可獨立訪問的模塊,每個模塊完成一個子功能,它們集成到一起滿足軟件的整體功能需求.實現模塊化的手段是抽象和信息隱蔽:抽象是指抽出事物的本質特性而暫時不考慮它們的細節;信息隱蔽意指應該這樣設計和確定模塊,使得一個模塊內包含的信息(過程和數據)對于不需要這些信息的模塊來說是不可訪問的.模塊化方法強調模塊獨立性,模塊獨立是指開發具有獨立功能并且與其他模塊之間沒有過多相互作用的模塊;模塊獨立的意義在于功能分割、簡化接口、易于測試和維護、易于多人合作開發同一系統.

3 面向對象方法

復雜性是軟件開發過程中所固有的特質[7],而軟件開發方法的核心在于幫助開發者駕馭這種復雜性.結構化程序設計和早期的模塊化方法圍繞功能構造系統,其本質是功能分解、過程抽象、自頂向下、逐步求精.這種方法有助于幫助開發者駕馭軟件設計和實現的復雜性,但在應對應用需求的復雜性方面考慮不多.隨著軟件應用范圍的拓展和復雜程度的提高,以及軟件需求變化導致的軟件演化日益頻繁,面向對象的軟件開發方法逐漸成為主流.

3.1 基本思想

面向對象的軟件系統通過一組對象的交互來完成系統的功能.對象是數據及其所允許操作的封裝體,是應用領域現實實體的軟件抽象.面向對象的軟件構造乃是基于系統所操作之對象類型,而非系統需實現之功能,來架構系統的途徑[8].面向對象方法的實施步驟包含了面向對象分析、面向對象設計和面向對象實現等.

· 面向對象分析主要包括識別應用領域應被抽象的對象,并分類組織這些對象,形成對象概念模型;刻畫這些對象的內部行為和外部交互,以及系統功能目標何以因之達成,形成用例模型;

· 面向對象的設計要在系統各種實施條件的約束下,給出上述概念模型和用例模型的實現方案,包括確定對象模型的操作、設計實現操作的算法、優化數據的訪問、調整類結構以提高繼承性等,形成面向實現的類模型、對象交互模型、對象狀態模型和存儲模型等;

· 面向對象實現通常使用面向對象程序設計語言和對象持久化設施等將上述設計具體地加以實現.

在應對需求復雜性方面,面向對象的軟件開發方法通過建立與現實世界中的實體、概念、關系和結構直接對應的軟件抽象來刻畫需求,并支持該軟件抽象在需求、設計、實現之間的無縫過渡,有助于彌合問題空間與解空間之間的語義鴻溝.在應對需求變化方面,結構化方法下功能的變化將導致如此設計的系統結構發生較大的變化.而應用領域的概念和結構遠比應用功能更穩定.因此,較之結構化方法,面向對象方法開發的軟件具有更好的結構穩定性、可修改性和可復用性.

3.2 核心機制與設計原則

面向對象方法的核心機制包括封裝、繼承和多態.

· 數據抽象提供了面向對象計算的起點,即定義數據類型和施加于該類型對象上的操作,并限定了對象的值只能通過使用這些操作才能修改和觀察,從而自然地形成模塊封裝和信息隱藏.面向對象通過類比發現對象間的相似性,即對象間的共同屬性,是構成對象類的依據;

· 繼承是類與類之間的一種層次關系,是實現利用可復用軟件構件構成系統的有效語言機制.相比過程復用,面向對象是對數據及其上操作的整體復用,而非僅復用操作功能.對象間的相互聯系是通過傳遞“消息”來完成的.通過對象之間的消息通信驅動對象執行一系列的操作,從而完成某一任務;

· 多態性是指相同的操作或函數、過程可作用于多種類型的對象上并獲得不同的結果.不同的對象收到同一消息可以產生不同的結果.多態性增強了軟件的靈活性和可復用性.綜上,面向對象的設計可以進一步總結為把軟件系統構作成類(或謂抽象數據類型實現)的結構化集合[9].

為了使開發的軟件具有能夠快速適應變化的敏捷性,必須遵循面向對象的設計原則[10].其中,

· 開放封閉原則是面向對象設計的核心,即:對擴展開放,對修改封閉[8].Liskov提出的替換法則指出,子類應該可以在任何地方替換它的父類[11];

· 依賴倒置原則要求面向對象的設計要對結構化的方法進行倒置,即高層模塊不應依賴低層模塊,兩者都應依賴于抽象.依賴關系的倒置正是好的面向對象設計的標志所在;

· 單一職責原則要求類的職責單一,引起類變化的原因單一,這是實現軟件靈活性的前提;

· 接口隔離原則強調接口的高內聚和低耦合;

· 迪米特原則要求控制對象之間的信息流量、流向及信息的影響,即注意信息的隱藏;

· 組合/聚合復用原則指出:相比于使用繼承來實現復用,更應優先使用組合/聚合的復用方式.通過對象的組合/聚合,可以在運行時動態地配置新對象的功能,并防止類層次規模的爆炸性增長.

3.3 源流與發展

盡管MIT的一些學者早在20世紀60年代初就開始使用對象這一概念,公認的面向對象的思想肇始于Dahl和Nygaard設計的Simula 67語言[12],該語言已完整提出了對象、類、繼承、多態等面向對象程序設計的核心概念.并不令人意外,Simula語言原本用于計算機模擬離散事件系統,其基本理念被廣泛用于通用的程序設計和軟件開發仍有賴于此后二三十年間的軟件思想、方法和技術進展的推動.20世紀70年代,Parnas提出了模塊化與信息隱蔽的基本思想[13];Hoare和Liskov等人引領了數據抽象和抽象數據類型的研究[14,15];Chen發表了著名的實體關系模型的論文[16],推動了對應用領域現實世界的概念建模;Kay領導開發的Smalltalk-80[17]推動了面向對象程序設計語言的發展和廣泛應用.

隨著面向對象程序設計的日益普及,20世紀80年代末和90年代初涌現了一批面向對象的軟件分析和設計方法,其中包括:Booch于1990年提出的Booch方法[7];1989年,Coad和Yourdon提出的Coad方法[18,19];1991年,由Rumbaugh等5人提出的OMT方法[20];Jacobson于1992年提出的OOSE方法[21]等.此后,統一建模語言(UML)不僅統一了Booch、Rumbaugh和Jacobson的表示方法,而且對其作了進一步的發展,并最終統一為大眾所接受的標準建模語言.UML不僅支持面向對象的分析與設計,還支持從業務建模、需求獲取、分析、設計、實現、測試到部署的不斷迭代軟件開發活動,在此基礎上,形成了所謂統一的軟件開發過程[22].

在面向對象設計技術發展方面,對微觀對象式設計經驗的總結和升華形成了設計模式,而對宏觀系統架構的關注催生了對軟件體系結構研究.1994年,Gamma、Helm、Johnson和 Vlissides的著作《Design Patterns:Elements of Reusable Object-Oriented Software》共總結了三大類型(創建型、結構型和行為型)共計23種設計模式[23].設計模式代表了面向對象設計和實現的最佳實踐,正確應用設計模式可以使得系統實現更易復用、更易理解、更易維護,并且更加可靠.軟件體系結構從比類更大的粒度、更高的抽象層次上刻畫系統的構件組成、構件之間的關聯結構及其交互行為,并給出這種宏觀設計的動機,即其在功能、非功能目標以及各種制約因素之間的權衡取舍[24].

在面向對象需求分析方面,隨著軟件應用的日益深入,軟件本身亦應被考慮為現實世界的重要組成部分.因而,僅通過模擬現實世界實體的結構和行為不足以指導軟件的構造.為此,必須考慮包括軟件本身在內的整個系統如何共同滿足組織機構的應用目標.這些應用目標不限于通常的面向對象分析所擅長的功能性需求,也包含用戶體驗、經濟性、安全性、適應性等非功能需求.在這方面,目標導向的需求工程給出了面向對象分析的補充[25].目標導向的需求工程考慮應用目標的層次分解,分析不同目標選擇,管理目標之間協同和沖突關系,最終將應用目標落實到面向對象分析可應對的具體需求上.

4 面向方面的方法

隨著軟件系統規模的擴大,其復雜性也急速增長且難以控制.以日志、安全等為典型代表的非功能性屬性在常規的面向對象開發當中分布于業務邏輯的各個角落,難以有效統一處理,給軟件的理解與維護帶來較大障礙.面向方面方法作為面向對象方法的一個有效補充,將相關屬性統一為橫切關注點進行理解與整理,并將其抽象為“方面”這一概念,從而可以一體化設計與實現,大幅度增加了代碼的可理解性與可維護能力.

4.1 面向方面程序設計

隨著軟件系統規模的快速擴大,軟件開發過程中,程序開發人員頻繁遇到特定屬性散布于多個功能模塊,導致難以統一維護、更新與管理的情況.以系統級關注點為例,如日志記錄、安全檢測等,它們與系統基本任務屬性之間是橫切的關系,分布在各個功能模塊之中.

傳統的面向對象程序設計(object-oriented programming,簡稱 OOP)方法主要著眼于系統核心業務需求,將數據和對應操作緊密地連結并封閉在一起.因此,使用面向對象方法實現上文所述的日志記錄、安全檢測等任務,自然就會將其與相關對象封裝在各自的類中,從而導致處理這些關注點的代碼在程序中多次重復出現.可以想象,這些關注點的代碼實現其實是高度類似甚或一致的.同樣的代碼在整個系統中散落且頻繁出現,會很容易降低程序的可理解性,而在面對后期潛在的需求變更時,其維護性也會受到很大影響,進而影響系統的質量.這也就是所謂的代碼分散(code scattering)現象[26].相對應地,另一個廣為人知的問題則是代碼纏結(code tangling)[26],即同一個模塊的代碼中要同時處理安全、功能、性能等各類關注點.可想而知,這樣的代碼,其可讀性和可維護性也自然會存在較大問題.

上述問題由來以久,Dijkstra就曾在《A Discipline of Programming》一書中提到“關注點分離(separation of concern)”的概念,即每次處理某一個特定的關注點相關部分.而隨著系統規模的快速擴大,代碼分散與代碼纏結等問題使得“關注點分離”更加必要且迫切.針對這一問題,Kiczales等人在 1997年歐洲面向對象編程大會(ECOOP’97)上提出了面向方面的程序設計(aspect oriented programming,簡稱AOP)[27,28]這一思想.相比于OOP,AOP把系統關注點分為核心關注點與橫切關注點(crosscutting concern)兩類:核心關注點即業務處理中主要商業邏輯與流程;而橫切關注點則是分布在各核心關注點內的共享關注點,如上文所提到的日志、安全等.

AOP將上文中這些影響了多個類的橫切關注點封裝到一個可重用模塊,命名為“Aspect”,即方面.在此基礎上,進一步提供了類和方面的自動編織(weave)機制,將橫切關注點對應的方面編織到特點的連接點(join point)位置,實現代碼整合.通過對這些“方面”的封裝以及方面與類的自動編織來減少系統的重復代碼,降低模塊間的耦合度,并有利于未來的可操作性和可維護性.

顯然,AOP是在OOP的基礎上針對“關注點分離”這一目標的一個有力補充.在OOP處理核心關注點及其業務邏輯的基礎上,AOP以一種模塊化的方式來理解、封裝與處理橫切關注點相關“方面”.然后,在運行或編譯時應用這些方面,從而實現與原核心業務邏輯的結合.這一機制使橫切關注點的實現更加模塊化,降低了代碼的理解和維護難度,并提高了系統適應不斷變化的需求的能力.

4.2 面向方面方法

長期以來,AOP思想一直受到了學術界和工業界的共同關注,其思想已被引入了需求分析、代碼實現、測試維護等各個階段,并衍生出面向方面軟件開發(aspect-oriented software development,簡稱AOSD)、面向方面需求工程(aspect-oriented requirement engineering,簡稱 AORE)等多個方向及子研究領域.同時也出現了以AspectJ[28]、AspectC[29]及 AspectC++[30]等為代表的面向方面程序設計語言.其中,AspectJ是目前使用得最為廣泛的AOP語言,其是對Java程序設計語言面向方面的擴展,經編譯后生成的類文件可以直接在Java虛擬機上執行,因此,其也得到了相關領域的廣泛應用與實踐.在軟件開發的各個階段,如需求分析、建模、測試與驗證、重構與應用等方面,AOP的相關思想和技術也得到不斷的發展.

· 面向方面需求分析

需求分析是軟件開發的首要步驟,只有在得到正確需求的情況下才可以進行后續開發.AOP的主要出發點即橫切關注點提取,因此,如何提取與表達橫切關注點是 AOP相關領域的重點關注問題.在橫切關注點提取方面,如何對需求文檔進行分析并自動提取是一個熱點方向.EA-Mine[31]是一個采用自然語言技術尋找橫切點的代表性工具.類似地,文獻[32]采用詞匯鏈分析技術來識別文本需求中的 Aspect.而在表達橫切關注點方面,則存在基于狀態機的表達[33,34]、基于用例圖擴充[35]等多種方法來具體描述相關橫切需求.這部分內容將在下面的面向方面建模中進一步展開討論.

· 面向方面建模

以 UML為代表的建模工具主要關注的是系統的核心業務邏輯,對于橫切關注點缺乏必要的支撐.因此,如何對UML進行擴展[36]以支持橫切關注點建模,是相關領域的研究熱點所在.相關擴展可分為輕量級、重量級兩類:所謂輕量級即利用UML所提供的Stereotype、Tagged Value、Constraint等擴展機制進行模型擴展,如文獻[37,38]等,其優點在于可直接利用 UML建模工具進行建模;而重量級擴展則主要在元模型層面進行直接擴展,給出Aspect建模的新型建模元素[39].這種方法所建立的模型更加直觀,但卻需要對應的工具支撐.相關方向存在大量工作分布在狀態機圖、用例圖、順序圖、交互概觀圖乃至活動圖以及 Petri網等多種建模語言上.受篇幅所限,此處不再贅述.感興趣的讀者可以閱讀Wimmer等人的綜述[40],對其發展進行詳細的了解.

· 面向方面測試與驗證

系統正確性測試與驗證是保障系統質量的重要手段.面向方向方法也給相關問題帶來了新的挑戰,如橫切關注點實現的正確性、一致性等.當然,直接把經過編織后的代碼當作常規代碼進行測試[41]是一種可行手段.除此之外,也仍有大量工作從AOP的問題特性出發去研制對應的測試方法,包括面向方面的單元測試[42]、集成測試[43]、回歸測試[44,45]等,并研發了相關工具,如 Wrasp[41]、Raspect[46]、EAT[47]、Rambutans[48]等.在驗證方向上,也有系列工作采用模型檢驗技術驗證集成后模型與需求的一致性[49],以及驗證編織后系統中是否含有死鎖等不希望行為等[50].

· 面向方面的重構與應用

除了上述幾個方向之外,將面向方面的思想利用到系統重構領域,特別是針對Aspect來基于橫切關注點進行重構,是相關領域的熱點所在[51].其中的主要問題自然就關注在兩個層面:如何發現與識別橫切關注點、如何基于相關橫切點進行重構等[52-54].

在上述系列開發工作的基礎上,AOP思想也在各類領域得到了大量的實際應用,如安全[55,56]、數據存儲[57,58]、云計算[59]、競爭檢測[60]等.國內相關研究者也在操作系統[61]、構件化開發[62]、軌道計算[63]等領域上展開了面向方面思想的應用與嘗試.受篇幅所限,以上工作僅為相關應用的一小部分,近幾年仍然可以持續看到AOP思想在各類領域的新型應用持續出現.感興趣的讀者可對相關問題進一步加以關注.

5 軟件復用與構件化方法

復用是提高效率的基本途徑,軟件復用是指重復使用已有軟件的構件.長期以來,復用一直是軟件技術和產業發展的重要關注點,軟件復用不僅能夠提高開發效率,而且由于使用的越多就越容易發現錯誤,所以能夠保障質量.一般而言,重復使用最為核心的構件是軟件代碼.程序語言大都提供了使用外部構件的能力,匯編語言的子程序(subroutine)、結構化程序設計中的函數模塊(function)以及面向對象程序中的類(class),都是可以復用的基本構件.1968年,Mcllroy在NATO軟件工程會議上發表的論文“大量生產的軟件構件”提出了大規模復用的考慮[64].早期具有代表性的工作是美國自然科學基金會組織構建的數學函數庫,在20世紀80年代中期,基本上完成了所有可能的數學函數的子程序,使得在程序中應用各種類數學函數都可以直接復用.從 20世紀 90年代中期開始,伴隨著面向對象技術開發技術的成熟,類(class)因其直接對應客觀世界的實體特性,更易于成為復用的組織單元,而類間結構和聯系也體現出了客觀實體的關聯關系.可以說,面向對象分析設計方法的成熟,使得軟件復用可以在更全面的范圍內得以實施.

軟件復用被視為解決軟件危機、提高軟件生產效率和軟件質量的現實可行的途徑[65,66].一般而言,軟件開發中都會考慮復用以前的工作基礎,例如復用部分程序代碼、使用相同領域有過開發經驗的人員等等.系統化的軟件復用則特指將軟件復用全過程、全技術緊密結合的開發過程,使軟件復用從早期的關注代碼復用逐步發展到基于復用的軟件開發全過程,可以包括3個主要階段.

1)有目的地開發為復用而做的軟件(development for reuse);

2)管理已有的可復用軟件(management for reuse);

3)復用已有的軟件開發新軟件(development by reuse).

這時的軟件復用體現了其核心思想,即:軟件系統的開發以現有的工作為基礎,充分利用以往軟件系統開發過程中積累的知識和經驗進行新的軟件系統的開發.

5.1 基于構件的軟件開發和復用

基于構件的軟件開發(component based software development)便是一種典型的軟件復用形式.基于構件的軟件開發將軟件的生產模式從傳統的軟件編碼工作轉換為以軟件構件為基礎的系統集成和組裝.軟件構件充當基本復用對象的角色,軟件構件技術是軟件復用技術的核心和基礎.構件是指軟件系統中具有相對獨立功能、可以明確辨識、接口由契約指定、與語境有明顯依賴關系、可獨立部署且多由第三方提供的可組裝軟件實體[67].構件模型是構件本質特征及構件間關系的抽象描述.構件模型中,實際包括軟件體系結構(software architecture)和構件(component)兩部分的定義.

在基于構件的軟件復用中,著重研究了3方面的技術.

· 一是如何識別可以復用的成分:針對特定領域來分析領域的共性需求及其實現,而非僅針對單獨的項目需求進行開發,有利于開發出有復用價值的構件.這部分形成了領域工程研究方向;

· 二是如何組織管理可復用的軟件:對軟件構件進行描述、分類、存儲,提供簡單且準確的檢索機制.這部分形成了軟件構件庫研究方向;

· 三是如何組裝已有構件形成新的系統:設計適當的構件模型,將軟件代碼封裝成為可以單獨使用的成分,基于構件模型的接口進行集成組裝.這部分形成了應用工程研究方向.

代表性的基于構件軟件復用方法是卡內基?梅隆大學(CMU)提出的軟件產品線方法(software product line Conf.,簡稱 SPLC)和歐洲提出的產品家族工程(product family engineering).一個產品線是共享一組共同設計及標準的產品族,從市場角度來看,是在某市場片斷中的一組相似的產品.產品線基于保證最大限度復用的產品族可復用構件而建立.產品線方法可以通過各種可復用軟件構件,如需求、需求規約、構架、代碼構件、文檔、測試策略和計劃、測試案例和數據、開發人員的知識和技能、過程、方法及工具等,支持系統化的軟件復用.北京大學楊芙清教授提出的軟件工業化生產模式及其對應的青鳥軟件生產線系統則提出了完整的支持復用全過程的開發平臺以及基于構件/構架的軟件復用開發方法.

從1990年代中期開始,軟件工程界出現了軟件復用的研究和實踐熱潮.這一時期出現了兩個專業的軟件復用學術會議:Int’l Conf.on Software Reuse(ICSR)和 The Software Product Line Conf.(SPLC).在產業界,基于復用、基于構件以及產品線工程的實踐成為主要軟件企業的技術提升途徑.

軟件復用的基本單元從程序代碼開始,發展到了面向對象的類以及封裝的構件,包括運行態的構件(如CORBA、EJB、DCOM 等分布式運行構件)一直在向大粒度方向進化,為的是復用的粒度大,效益更為明顯.21世紀開始的Web服務(Web service)及其面向服務的架構分析設計技術(service-oriented architecture,簡稱SOA)提供了互聯網上可訪問的服務實體,這使得軟件復用的研究和應用領域擴展到了互聯網的軟件實體中.針對Web服務的選擇、服務質量(QoS)預測和服務組裝的研究,成為軟件復用領域的技術和應用新擴展.

5.2 基于開源軟件的軟件開發和復用

開源軟件的發展,則為軟件復用提供了更加廣闊的空間.軟件復用的關鍵因素在于要有大量可以復用的軟件資源.開源軟件的海量資源,成就了軟件復用新的發展空間:一方面,信息檢索技術的發展為查詢合適的可復用軟件提供了一種可行的機制;另一方面,程序語言及開發環境中支持復用的機制有所發展,如Python語言等能夠更為容易地嵌入已有構件.開源軟件的發展不僅僅是代碼庫的積累和開放,大量涉及開發技術細節的文獻、信息也被開放在互聯網上,更大程度地帶來了開發社區和生態的新環境.在開發社區中,開發的需求討論、缺陷修改的方案等都被郵件信息、缺陷報告工具、版本管理工具等記錄.在開發生態系統中,Stackoverflow這樣的技術問答網站直接為用戶回答技術細節問題.這些技術文獻的搜集、組織和應用,形成了當前的軟件復用的主要可復用資源池.

開源軟件的開放源代碼是復用的基本資源.不同于傳統的基于構件的復用中爭取代碼封裝以備組裝使用的專門技術方案,開源軟件的代碼復用更多地是通過代碼直接調用程序接口(API)來實現的,這對提供高質量、廣泛代表性的使用樣例(或使用示例)提出了更高的要求,從而也帶來了開源軟件中軟件包關聯過于復雜、龐大的系列問題.開源軟件的另一主要復用機制則是代碼框架的廣泛使用,取代傳統軟件體系結構的專門定義,代碼框架成為復用中的體系結構.在框架中增補相對應的軟件代碼,成為整體協同定制和發展的基礎技術.以往的軟件復用主要是針對企業局域、小規模的領域和組織,其數據內容、可復用資源數量有限,主要依托工程化方法實施.從開源軟件的海量復用資源以及復用機制的轉變來看,開源軟件復用的核心問題已轉變為在互聯網廣域環境下,面對軟件大數據基礎,如何高效實現大規模群體敏捷化開發的問題.

5.3 知識驅動的軟件開發和復用

我們認為,知識驅動的軟件開發方法(knowledge-driven software development,簡稱KDSD)已成為當前軟件復用的主要研究方向.可復用的軟件實體仍然包括了代碼片段、API、軟件包、Web服務、框架等軟件基礎資源.復用的核心關注點則轉變為以軟件知識為核心關注點,研究如何基于特定的知識結構以及認知方法和機制來描述、理解和利用可復用的軟件實體.這其中,主要涉及的問題包括:

· 知識的表示:采用語義網絡(semantic network)知識圖譜(knowledge graph)等技術來表達豐富的軟件開發知識和領域知識;

· 知識的來源:可從軟件代碼獲取高度結構化、精簡、準確的領域知識體系,也可從豐富的軟件相關信息中獲取自然語言表達的知識;

· 知識的語義關聯:建立軟件代碼知識和自然語言知識的關聯,形成領域的語義模型.

在此基礎上,軟件開發工具能夠以智能推薦的方式為開發人員提供幫助;更進一步地,可能部分實現基于自然語言需求描述自動生成對應的程序.當代的知識表示、信息檢索和機器學習技術為這方面的發展提供了全新的技術途徑.我們可以期望未來出現一種軟件開發的智能化方法,盡可能準確地提供代碼推薦和生成,從而使得軟件復用方法的研究和實踐從面向復用的對象轉向基于知識驅動的智能化開發方法.

6 模型驅動的方法

如何高效、低成本地開發優質的軟件產品,一直是計算機軟件領域重點關注和研究的問題[68].伴隨著信息化進程的迅猛發展,軟件的復雜度在不斷提高.同時,軟件的演進形態也日益多樣化[69].在這種情況下,如何有效地解決上述問題成為學術和工業界共同關注的焦點.模型驅動方法正是在這樣的背景下逐漸受到重視,被認為是可以應對“高效、低成本地開發優質軟件”的一條有效途徑.而這一認識也伴隨著實踐不斷得到深化,經歷了從統一建模語言(unified modeling language,簡稱UML)到模型驅動架構(model-driven architecture,簡稱MDA)、從模型驅動架構到模型驅動工程(model-driven engineering,簡稱 MDE)、從模型驅動(model-driven)到基于模型(model-based)的過程.

6.1 從UML到MDA

在軟件開發的長期摸索過程中,人們逐漸認識到,“提高解決問題的抽象層次”是有效利用抽象手段解決軟件開發問題的一個非常具體而實用的途徑(與軟件技術發展密切相關的3個要素是計算機平臺、人的思維模式和問題的基本特征[2].文中出現的“提高解決問題的抽象層次”中的“提高”指的就是向著更接近于人的思維模式方向上的提高).Mellor在21世紀初曾指出[70]:過去的50多年里,人們利用“提高解決問題的抽象層次”處理軟件開發的問題已經取得了兩個較為顯著的進展:(1) 開發出了具有較高抽象層次的程序設計語言;(2) 能夠在更高抽象層次上實現軟件復用.

然而這個發展道路也并非一帆風順,在面向對象的語言、方法和技術逐漸成為主流的過程中,Booch、Jacobson和Rumbaugh各自創建的Booch、OOSE和OMT方法都獲得了工業界的支持,并形成了互不兼容的3種模型和方法體系.不同的工業應用在這 3種不同的體系下形成了彼此之間難以理解和復用的軟件制品,這讓當時原本就不成熟的軟件行業更是雪上加霜.如何形成一個能夠支撐從需求到實現的軟件行業標準,成為當時擺在軟件發展道路上的一個亟需解決的問題.在這種情況下,3位面向對象方法學的大師走到一起,融合了他們的3種軟件開發方法和模型表示法,形成了統一建模語言(unified modeling language,簡稱UML),通過非盈利的國際標準化組織對象管理組(object management group,簡稱OMG)發布為建模規范,并最終在2005年被國際標準組織(Int’l Organization for Standardization,簡稱ISO)采納為工業標準.

由于UML設計者和OMG的共同影響力,UML從20世紀90年代開始構造起就受到工業界的關注,在1997年發布1.0草案版時已經獲得了工業界的普遍支持,并反過來引起學術界的研究熱情,再歷經1.1～1.3版本的演化,最終在1.4版本時成為ISO工業標準,更是奠定了UML在整個軟件行業中的毋容置疑的通用建模標準的地位,這也形成了面向對象方法學發展道路上的一個重要的里程碑.

有了這樣的技術積累,人們開始嘗試在更高的抽象層次上開發軟件,中間件的形成與發展也正是在這樣的背景下逐步明晰和受到重視的.商家往往能夠最早嗅探到技術發展背后的商機,并善加利用以推動自身的發展.于是,J2EE、.NET等中間件技術開始各自占據市場,又仿佛當年Booch、OOSE和OMT方法之間的爭斗.在這種情況下,OMG再次提出了以模型為中心的軟件開發框架性標準——模型驅動體系結構(model driven architecture,簡稱MDA)[71],又一次得到了來自學術界和工業界的普遍關注.盡管MDA提出的直接動因是為了解決異構中間件(middleware)平臺的互操作障礙問題[71],但是由它所倡導的以模型為中心進行軟件開發的思想很快得到了廣泛支持,迅速成為研究熱點.MDA整合了OMG在建模語言、模型存儲以及模型交換等方面的一系列標準,形成了一套基于模型技術的軟件系統開發方法和標準體系.

6.2 從MDA到MDE

隨著 MDA研究熱潮的迅速興起,模型驅動軟件開發這個詞語逐漸被越來越多的學者所使用.此間,與模型相關的不同字眼也不斷出現在不同的學術機構和社區(community)中,如 model-driven、model-based、modelrelated、model-engineering等等.2005年,模型驅動軟件開發領域最重要的年會之一——UML Series(Int’l Conf.on the Unified Modeling Language)正式更名為 MoDELS/UML Series(Int’l Conf.on Model Driven Engineering Languages and Systems),這開始引起了人們對模型驅動軟件開發領域自身術語使用上的關注.2007年,模型驅動工程MDE這個術語正式出現在第29屆ICSE年會的FoSE(the Future of Software Engineering)分會上[72],標志著MDE成為模型驅動軟件開發領域的代名詞.

模型驅動工程以模型為首要軟件制品(software artifact),通過建模為問題域構造軟件系統的業務模型(business model),然后依靠模型轉換(model transformation)驅動軟件開發,(半)自動地產生最終完備的應用程序[73].可見,MDE下的一切工作都是圍繞著模型展開的.模型對于模型驅動工程而言,就如同對象對于面向對象軟件開發一樣,是基本的開發元素,這也就是為什么稱其為“模型驅動”的原因之一.模型驅動使軟件開發的抽象層次進一步提高到模型這個層次.有學者認為:模型驅動的思想,或者說以模型為中心的軟件開發思想,正是抽象層次提高到一定程度的一個自然而然的結果[74].

在 MDE中,模型指的是為了分析或解決問題而對系統某些方面的抽象描述.從廣義上講,它涵蓋了軟件系統的任意部分[75],包括需求、設計、文檔、代碼、部署、配置和測試用例等.代碼也可以看作軟件系統的模型,這是因為代碼反映了軟件程序被執行時的行為.然而,通常所指的 MDE下的模型,更多的是狹義上的“設計草圖”[76],即今天的開發模型(development models).如文獻[77]中提到,模型是用來對問題域進行求解的手段;文獻[78,79]認為:模型是針對實際問題或者業務邏輯構造,而抽象層次高于可執行代碼或最終完備的應用程序的軟件制品.

圍繞著模型展開的一系列工作實際上也就構成了 MDE中的各項研究工作.2007年的國際軟工大會上,France等人[72]將目前這些工作中最重要和亟待解決的問題歸結為如下幾類挑戰.

· 建模語言的挑戰:這一類挑戰主要來自于如何使建模語言支持在問題層面上進行建模,以及如何對模型進行嚴格的分析.

· 關注點劃分的挑戰:這一類挑戰來源于對同一系統進行多視圖建模的結果.由于不同側面的模型可能是基于異構的語言開發的,而模型間又存在相互重疊的部分,因而很容易出現不一致等問題.

· 對模型操縱和管理的挑戰:這一類挑戰包括:(1) 對模型轉換的定義、分析和使用;(2) 維護模型元素間的可追溯性,以支持模型演化(model evolution)和雙向工程(roundtrip engineering);(3) 維護不同視點(viewpoint)之間的一致性;(4) 版本追蹤;(5) 在運行期使用模型.

其中,前兩類是針對建模的問題,最后一類主要是轉換的問題.可以看出,模型驅動思想的核心就是建模和模型轉換,它們也是完成 MDE開發的兩個最主要的過程.并且,建模過程和模型轉換過程又是相互交織的,建模過程涵蓋了一系列不同抽象層次模型的構造過程,而相應的轉換過程也包括了不同抽象層次間以及相同抽象層次上的轉換.

6.3 從Model-Driven到Model-Based

近年來,隨著MoDELS國際會議影響力的不斷擴大,軟工領域的各個研究分支也在不斷將工作發表在該會議上,這在很大程度上推動了整個軟工領域對“模型”更為深入的思考,最開始的那種以“模型”為中心來驅動軟件開發的想法也慢慢演化為如何將模型作為有效的抽象手段來刻畫軟件的某些重要性質,從而更好地支撐在不同研究領域的應用,如測試、驗證、推薦、復用等等.在這種背景下,“Model-Driven”的含義慢慢向“Model-Based”靠近.

模型驅動(model-driven)的術語主要是從MDA中產生出來,其最初的含義是強調系統的構造是通過以模型為中心來完成的,也就是說,模型的主要用來“驅動”軟件從需求開始向實現過渡的這個過程.而隨著 MDE研究領域的逐漸形成,模型的價值在整個軟工更大范圍內得到關注,模型的概念也從最早的 UML這個具象的對應體,慢慢回歸到作為軟件系統的“抽象描述”這樣的本質上來.因而,基于模型(model-based)這個說法就成為更能夠表達其寬泛含義的術語,在 MDE領域得到了更多的應用,如基于模型的軟件開發(model-based software development)、基于模型的測試(model-based testing)、基于模型的規約(model-based specification)等等.

這樣一來,大大拓寬了MDE研究領域的范圍,也極大地增強了軟件工程各個研究分支與MDE的融合.其中,在最近幾年比較受關注的研究熱點有模型對運行時的支持,模型資產庫的構造與應用,模型與人工智能、機器學習的結合以及更加寬泛的建模IDE的研究等.

· 模型對運行時的支持主要是通過預先定義或者動態獲得的系統行為模型,對軟件系統在運行時的行為進行監控,從而預判甚至是干預和調整系統動態行為;

· 模型資產庫的構造與應用是近來備受關注的工作,特別是隨著互聯網上開源軟件的急劇增加,可以被直接獲得的軟件資產已經形成了相當的規模.如何有效地使用這些軟件資產,引起了學術界和工業界的格外關注.模型作為軟件的抽象描述,可以從不同的視角和維度展示軟件的語義信息,進而形成海量軟件資產的“索引”,極大地提高了對開源軟件的理解和復用能力;

· 模型與人工智能、機器學習結合的研究,是最近人工智能和機器學習熱潮下的一個趨勢.雖然具體的研究內容還沒有得到普遍共識,但總的來講,一方面是研究基于模型的人工智能和機器學習,另一方面是將人工智能和機器學習技術用到MDE研究中.目前來看,后者的研究工作更多一些.

建模IDE的研究一直都是MDE領域的一個重要研究方向,而且具有很好的實用價值.但與之前研究工作不同的是,目前建模IDE的研究不僅僅是UML家族或者MDA框架下的模型概念,更加泛化的模型是目前的一個趨勢,甚至是手繪草圖、形式化模型等都被逐漸納入到所討論的范疇中.

7 服務化方法

隨著以互聯網為主干,電信網、移動網、傳感網等多種網絡正在不斷滲透融合,軟件系統的運行環境正在逐步從靜態、封閉、固定的單機環境轉變為動態、開放、多變的網絡環境.為了應對網絡環境中各類分布式資源的共享和集成對計算機軟件技術的挑戰,軟件服務得到了學術界和工業界的廣泛關注[80].

7.1 基本思想

軟件服務是指將軟件的功能以服務的形式通過互聯網來交付,可以被使用者(最終用戶或者第三方客戶端程序)直接使用的獨立的基本單元.就其形態而言,軟件服務一般基于可共享和集成的應用系統和資源來構建,對外則表現為一組相對獨立的業務功能單元(通常是可供外部直接調用的應用編程接口,即API),更加方便使用者直接使用.軟件服務的一個重要目標是屏蔽開放網絡環境帶來的異構性問題,因而一般具有較高的抽象級別和獨立性.這種獨立性也帶來了軟件服務之間更加松散的耦合關系,從而使得使用者可以靈活選擇服務并進行組裝來生成增值服務.特別地,由于開放環境下存在大量類似的資源,使用者可以在量大面廣、推陳出新的多個相同或相似服務中不斷選擇最合適的服務.

目前,軟件服務不僅成為網絡環境下最為重要的一種軟件形態,也改變了傳統的軟件交付方式,使得軟件產業開始從“以產品為中心的制造業”向“以用戶為中心的服務業”轉變.軟件由服務的運營商負責運維,用戶無需擁有軟件的本地拷貝,也不必考慮軟件的維護和升級,還可以按需定制和購買軟件.軟件服務使其使用者能夠在不擁有軟件產品的前提下,直接使用軟件的功能,從而實現“即拿即用”的效果[81].這種“只求使用,不求擁有”的特性,也只有通過互聯網和軟件的組合才可能實現.進一步地,軟件服務的使用者可以更加靈活地進行服務組裝以生成增值服務,并能不斷地選擇最優服務來滿足適應性的需求.

7.2 主要角色和開發過程

一般而言,基于服務的軟件開發主要包含3類主要角色,即服務提供者、服務使用者和服務代理.其中,

· 服務提供者按照服務契約(service contract)實現了提供業務功能的軟件模塊.從業務角度看,它是服務的擁有者;從體系結構看,它是訪問服務的平臺.對于提供同一業務功能的服務,可以有多種不同的服務提供者;

· 服務使用者(即服務的用戶)調用服務提供者所實現的服務,以完成特定的業務需求.從業務角度看,它是請求特定功能的業務;從系統體系看,它是尋找并調用服務或啟動與服務交互的應用.服務請求者可以是用戶通過客戶端應用程序(如瀏覽器或智能手機)實現,也可以是沒有用戶界面的程序實現(如另一個服務);

· 服務代理是一個可搜索的第三方注冊機構,如 UDDI等.服務提供者將服務描述發布給服務代理,服務請求者在服務代理處查找服務并進行綁定(可分為靜態綁定和動態綁定)和調用.

某種程度上看,軟件服務可以看成是軟件構件在網絡環境下的進一步延伸和發展.圍繞軟件服務的開發過程可以分為如下幾個[82].

· 服務封裝和生成.服務提供者將軟件系統中需要開放的功能和數據按照一定的標準(如Web服務)進行封裝并發布.服務的生成一般是對已有的軟件系統的功能和數據進行封裝,也可以是服務提供者新開發的功能和數據;

· 服務查找和選擇.服務使用者查找并選擇滿足其功能和非功能需求的服務.服務查找既可以通過統一的服務代理(如UDDI),也可以通過搜索引擎來進行;

· 服務組裝.服務使用者對若干服務進行組裝來形成新的增值服務應用.組裝的過程既可以按照預先定義的規則(如業務流程規約 WS-BPEL或 WSCI)及其引擎自動/半自動地完成,也可以根據當前的情境以人機協同的方式來完成(如Web Mashups);

· 服務演化.由于每個軟件服務是相對獨立的實體,其功能和質量均可能發生演化.相應地,通過服務組裝而成的應用也會隨之發生演化,可表現為服務的升級/降級、增加、退出和替換等.

7.3 發展過程

· 面向服務的體系結構和Web服務.

軟件服務的思想可以追溯到20世紀90年代中期出現的“應用服務提供商(application service provider,簡稱ASP)”.21世紀的前 10年,軟件服務開始成為學術界和工業界的研究實踐熱點,其代表為面向服務的體系結構(service oriented architecture,簡稱SOA)及其主要的實現技術——Web服務的興起[82].圍繞Web服務互操作協議、發現、組裝、語義、管理和質量保障等問題,已經有了大量的工作.從實際應用情況看,在互聯網上,基于SOAP(簡單對象訪問協議)的Web服務數量還比較少,且大多只提供相對簡單的數據查詢功能(如天氣、股票查詢等),Web服務之間也很少構成復雜的業務邏輯.這里既有 Web服務技術體系存在自身缺陷的原因,如廣域網中基于SOAP協議的消息傳輸性能較差、服務質量難以保障等,也有一些非技術的因素,如Web服務相關的技術標準過于繁雜難以統一、面向互聯網的服務注冊中心(UDDI)難以管理和維護等.

· RESTful服務.

2004年前后,隨著Web 2.0的興起,對數據/內容開放共享、多方協同、用戶交互體驗的需求不斷增加,越來越多的 Web系統所有者均開始關注如何將自身的功能和數據以服務的形式開放出來.由于傳統的基于 SOAP的Web服務在互聯網環境下難以進行規模化應用,于是,基于REST(representational state transfer)體系結構風格的軟件服務技術得到了廣泛關注和使用.REST由 Roy Fielding(Roy Fielding是 HTTP 1.1規范的起草者和Apache Web服務器的開發者,并且倡導創建了Apache開源軟件基金會)于2000年左右提出[83],是WWW架構最為核心的應用軟件體系結構風格.與 SOAP相比,REST體系結構風格提供了一種相對輕量的應用協議,通過描述資源狀態變化的方式而不是遠程過程調用(remote procedure call)的方式來使用軟件服務,更加適合萬維網環境.特別地,2007年起,云計算開始成為互聯網環境下最為重要的應用模式[84],基于REST體系結構風格的軟件服務成為云計算的基礎使能技術之一.幾乎所有的主流軟件服務提供商(主要是互聯網公司,如谷歌、亞馬遜、Facebook、Salesforce.com、百度、騰訊等),都開始采用遵循REST的Web API來發布軟件服務供用戶在線使用[85].此外,基于 REST的 Web服務功能也不僅限于簡單的數據查詢,應用的業務范圍更廣,如谷歌的 Gmail服務、Salesforce.com的 CRM(客戶關系管理)服務和亞馬遜的存儲服務等,都是基于REST的 Web服務.當然,在云計算環境下,軟件服務仍有很多問題需要解決,包括對“黑盒”形態的遺產系統“解耦”和“安全”的服務化封裝、服務的交付與展現、服務動態組裝、服務的跨域安全性、服務資源管理等.

· 微服務和開發運行一體化.

近年來,“微服務”得到軟件服務研究實踐者的廣泛關注[86].微服務是一種基于一組獨立部署運行的小型服務來構建應用的方法.與傳統的面向服務體系結構SOA應用相比,這些小型服務主要圍繞應用系統業務能力來構建,采用盡量去中心化的機制管理,使用不同技術棧開發,通過輕量級通信機制交互.圍繞微服務架構,一些新的研究正在不斷涌現,如面向主流編程語言并支持微服務架構的軟件開發框架、事件驅動的開發運行一體化(如DevOps)基礎設施架構[87]、細粒度基礎資源及其狀態監控、在線測試和快速部署、容錯等關鍵技術等.

8 展望:面向人機物融合應用的軟件開發方法

縱觀軟件開發方法和技術的發展歷史,新方法與技術體系的誕生總是由軟件基礎支撐平臺和相應的應用需求的重大變化來驅動的.宏觀來說,軟件開發就是給定待解的應用問題,由軟件開發者通過智力活動過程構造出能夠在所提供的平臺上有效運行的、能夠解決問題的軟件.因而,軟件開發方法的 3個宏觀要素可抽象概括為平臺空間、認知空間、問題空間.軟件方法與技術體系的發展過程就是在平臺和需求變化驅動力的推動之下,對這3個空間的認識不斷深化并在其間有效協同的過程[88],從而幫助駕馭軟件開發的復雜性.即:盡量避免引入附屬性的復雜性,更好地理解和應對本質性的復雜性.例如:前文所述的結構化方法乃是由于20世紀70年代計算機基礎能力(計算、存儲與外設)的快速發展和軟件危機的出現而導致人們對基礎的程序設計方法與語言的科學思考而產生的,它較好地協同了軟件開發的平臺空間與認知空間;面向對象方法與技術體系則進一步發展了從宏觀角度控制復雜性的手段,如關注分離、信息隱蔽、模塊化等,并強調將問題空間納入軟件設計的范疇,提出了與問題結構具有良好對應關系的面向對象程序模型的概念與支撐機制,從而協調了軟件設計平臺空間、認知空間以及問題空間[88].然而,經典的結構化和對象化方法與技術體系誕生于靜態、封閉、可控的環境,難以完全適應像Internet這樣開放、動態與難控的環境和多變的用戶需求,為此,需要探索新的軟件方法與技術體系.

8.1 面向Internet的軟件方法與技術探索

21世紀以來,Internet的快速發展與普及為軟件方法技術的發展帶來新的驅動力:其基礎平臺從Mainframe經過網絡化、微型化、并行化而逐步形成一個所謂的Global Ubiquitous Computer[89];其應用方式從經典封閉應用模式經過資源化、普適化與服務化,逐步形成了以X-Computing(grid computing,cloud computing,service computing,pervasive computing等)、X-Systems(embedded system,hybrid system,cyber-physical system 等)和XData(very large scale data,massive data,big data)為代表的多樣化開放式應用模式.于是,計算平臺空間已經從單個或多個可控計算機向開放的 Internet平臺發展,其主要作用已開始從“計算為主”逐步向“通信連接為主”的方面轉變;認知空間已開始從“面向個體程序員”開始向“群體化和服務化方式”過渡,其關注點在面向對象的“平臺?程序員?問題”的基礎上,開始向關注“個體?群體開發者?大量使用者”的方面過渡;問題空間已從確定環境下的單個問題求解,到開放開發環境下的群體問題求解,開始向非確定環境下如何為大量最終用戶提供優質服務的方面發展,其關注點已從求解問題轉變到開放環境下資源的共享與協同[88].

為此,人們從不同角度對面向 Internet的軟件方法和技術[90]進行了探索,例如自適應軟件系統[91]、面向Agent的軟件工程[92]、面向 IoT的程序設計[93]、自組織系統[94]等等.而網構軟件是中國學者提出的一種面向Internet的新軟件范型[95-97].網構軟件范型針對前述Internet計算平臺和應用模式的特點,強調軟件的自治性,即軟件系統由分布于網絡中自主獨立的實體構成;協同性,即這些自治實體通過動態聯盟協作共同達成應用目標;適應性,即軟件系統自主感知環境和需求變化并主動適應之;演化性,即軟件系統的結構和行為能夠動態演化從而長期生存;激發性(emergent),即軟件系統可能呈現由自主實體交互而激發的非預設行為;以及可信性,即以應用目標和用戶體驗為導向的軟件質量保障.為支持網構軟件范型,研究者從軟件的架構模型、構造方法、運行支撐以及質量保障等方面展開了一系列研究.例如,在架構模型方面提出了基于動態體系結構的模型[98]和環境驅動的模型[99]等;在構造方法方面,提出了以體系結構為中心方法[100]和基于環境本體的能力規約[101]等;在運行支撐方面,提出了基于雙向轉換的運行時體系結構技術、動態軟件更新技術等;在質量保障方面,研究了服務化網構軟件的時序性質的規約與監控[102]、特征驅動的需求依賴分析[103]等.

8.2 新型軟件開發方法與技術展望

當前,Internet網絡互聯不斷拓展和深化,它已從計算機的網絡拓展到無處不在的物理世界中的各種傳感和執行設備.同時,它也深入支撐并改造了人類用戶的各種社會關系,形成一種人機物一體融合的綜合發展態勢.這或許孕育著對軟件開發方法和技術體系的革命性挑戰和機遇.

人機物融合中的所謂“機”,主要是指軟件的基礎平臺支撐,它經歷了從計算機經過計算平臺到計算思維的轉變.在此過程中,計算機開始從以工具為主要形態演變為與機器形態無關的平臺概念,然后上升為計算思維的概念,變為人類除理論與實驗之外認識世界的第3種手段.所謂“物”,主要是指面向現實世界的信息化空間.在宏觀上,它經歷了從個體化空間經過社會化空間逐步向自然化空間的轉變,預示信息化技術不斷從個體化機構化的應用逐步向人類社會與自然界的拓展與深入.所謂“人”,即是信息化社會的主要載體,經歷了從信息化的工作人與娛樂人經過網絡支持的虛擬社會人到各類信息及時支撐的自然化超人的轉變,其在自然界與人類社會的能力越來越強,但其對信息技術的依賴也越來越大.

如果從前述(平臺空間、認知空間、問題空間)三要素的觀點看,這三者大致對應于上述機、人和物.但這里的平臺空間也包括了人和物在計算思維下的抽象.要支持這種抽象,構造新型軟件所運行的平臺,必須要有新的技術手段.軟件定義(software-defined,簡稱 SD)[104]的思路和技術給出了一種可能的途徑.這里的問題空間與傳統軟件應用有很大的不同:傳統軟件只是負責現實世界業務過程中的信息處理環節,而現在的軟件日益成為信息化了的現實世界中的應用的價值觀的主要載體.這里,認知空間的主要問題就成為如何支持所謂自然化超人.這種以人為本的軟件構造需要不同于傳統的基于規約的軟件構造,需要新的方法和技術的支持.

人機物三者的綜合與協同發展是信息技術進步的主題,也是推動軟件方法與技術不斷發展的動力.例如,(人:信息化工作人,機:Wintel模式,物:信息化工作空間,理念:人人一臺PC)、(人:被信息化服務人,機:Google模式,物:信息化服務空間,理念:人人可以使用全世界的信息)、(人:虛擬社會人,機:Web As a Platform,物:虛擬化社會空間,理念:我為人人與人人為我)等均代表了信息技術發展的不同模式與發展階段.在此意義下,當前正在發展與追求的主要目標是(人:自然化與信息化結合的超人,機:物聯網/云計算/大數據/CPS,物:智慧校園/智慧城市/智慧地球,理念:Anytime,Anywhere,AnyService).在這樣一個發展過程中,將推動軟件方法與技術體系逐步從封閉獨立軟件系統到開放協同軟件系統,從靈活好用的軟件系統到智能可信軟件系統的重大轉型,進而推動軟件方法與技術體系從“經典的面向對象軟件方法與技術體系”經過“面向Internet軟件方法與技術體系”逐步向“面向人機物融合的軟件方法與技術體系”的跨越.