一、軟件業面臨的挑戰——適應技術和需求易變性

??? 荷馬在他的史詩中描述了西西弗斯的故事，他必須將一塊巨石推上海蒂斯的一座小山，但每當接近山頂時，巨石又會滾下來，因此西西弗斯的苦役用無止境。而當今的IT軟件人正是現在版的西西弗斯——面臨的是快速變化的技術和越來越復雜的需求。(摘自《應用MDA》)

許多軟件業同仁已經察覺到，軟件業正站到了一個新的巨大的技術變革的前沿。看看最近炙手可熱的技術和標準：面向構件編程、面向方面編程（AOP）、產生式編程（GP）、動態語言、模型驅動架構（MDA）、語義Web（Semantic Web）、Web服務、面向服務架構（SOA）、BPEL等等。事實上，我們已經再一次被大量全新的技術和標準所包圍。在諸多的新標準和技術中，究竟那一種方案，會讓軟件業迎來一次革命性的變革？在這些看似不同的方案中，他們是否有共同的方向？這個共同的、最重要的方向是什么？面對洶涌而來的新標準和新技術浪潮，在變革的前夜，探尋軟件技術變革和突破的走向，就是我這一年學習和思索的主題。

??? 需求推動IT發展，IT發展又刺激新的更大更復雜的需求，這是IT發展的巨大動力源泉。軟件業從硬件分化出來那天開始，就面臨著適應技術變化和需求變化的挑戰。特別是，硬件、網絡和通訊的快速發展拉近了時空，以前所未有的速度影響人們的生活、企業的經營和社會的發展，這更使軟件業雪上加霜，面臨更加嚴重的危機和挑戰。

??? 正是技術和需求的易變性，導致軟件危機，也催生一次又一次的軟件業變革。更好的適應技術和需求的易變性既是軟件業變革的推動力也是變革的方向和檢驗標準。

二、迎接挑戰——分離模型與實現

?????? OMG組織以特有的影響力將MDA推到了這場變革的中心。MDA定義了平臺無關模型(PIM)、平臺相關模型（PSM）和代碼以及它們之間的關系。MDA的關鍵思想包含兩部分：模型和驅動，這里的模型是指PIM，驅動的方法是將PIM通過變換工具自動生成平臺相關模型（PSM），進一步生成代碼。

????? PIM的“獨立于平臺”這個說法有模糊性，容易讓人誤解。正是因為這一點，PIM遭到業界部分人士（包括知名人士）的質疑，認為PIM根本就不存在，是空中樓閣。我們先來看看《應用MDA》一書中關于PIM的一個小結：

l?? PIM更準確的定義應該是“獨立于平臺的計算模型”。

l?? 平臺獨立性是一個相對的說法。當聲稱某個語言或者模型是獨立于平臺的，你必須說明獨立于哪些平臺技術。

l?? 當前，獨立于平臺意味著獨立于信息格式化技術、3GL、4GL、分布式組件中間件和消息中間件。

這個解釋還是不夠清晰，我們再看看《解析MDA》中對PIM的描述：

PIM是具有高抽象層次、獨立于任何實現技術的模型。

這里指出了“獨立于平臺”實際上是獨立于實現技術。這對我們理解MDA非常重要。

??? 我的理解，任何軟件系統包括模型和實現兩部分，模型是對系統的描述，實現是利用特定技術在特定平臺或環境中對模型的解釋。模型僅僅負責對系統的描述，與實現技術無關。我把這一點稱為模型的實現技術無關性。分離模型與實現，這樣做具有合理性嗎？有什么好處呢？ 是否符合軟件業變革的方向和檢驗標準呢？

??? 讓我們再聽聽布魯克斯在《沒有銀彈》文中的論述：“所有軟件活動包括根本任務——打造構成抽象軟件實體的復雜概念結構，次要任務——使用編程語言表達這些抽象實體，在空間和時間限制內將它們影射成機器語言” 。

??? 我把布魯克斯的根本任務理解為表達模型，次要任務理解為實現模型。分離模型與實現就是分離軟件活動中的根本任務與次要任務這兩個關注面。模型實現是軟件活動的次要任務，當然，這并不是說它不重要。我理解布魯克斯的觀點是根本任務的復雜性遠遠超過次要任務的復雜性，換句話說，就是次要任務相比根本任務，要容易解決的多。

??? 在討論分離的合理性與好處之前，我們先關注模型實現的兩種方式。一種是直接執行，就是使用動態執行引擎直接執行，我把這個動態執行引擎稱為模型的運行平臺；另一種是模型變換，就是把模型變換為更容易執行的目標語言表達的模型，目標語言一般情況是抽象程度更低的語言，這里的變換通常需要變換定義和相應的變換工具。

下面，討論分離能否迎接軟件業面臨的挑戰——適應技術和需求的易變性。

??? 首先，模型與實現分離后，能夠很好的適應技術易變性。由于實現往往高度依賴特定技術和特定平臺，當技術發生遷移時，只需針對這種技術作相應的實現，編寫相應的運行平臺或變換工具。所以，能夠比較好的應對實現技術發展帶來的挑戰。

??? 其次，我們看看適應需求易變性方面。模型與實現分離后，應對需求的變更，就是調整模型，然后重新實現即可。看看重新實現的代價，如果模型的實現是采用直接執行方式，我們不需要做任何事情，如果采用模型變換方式，只需重新變換，然后發布實施即可。從這里可以看出，模型的實現是很容易適應需求變化的。分離后，能否適應需求易變性，關鍵是看模型本身是否比較容易隨需而變。如果模型本身不容易改變，則適應需求易變性就是空話。

??? 舉個例子，看看互聯網，網站就是一個模型，HTML和URL是這個模型的描述語言，它的實現方式是直接執行，Web服務器和瀏覽器是運行平臺。想想，如果沒有Web這種模型和實現分離的手段，而采用3GL編程的模式，現在的Web會是怎樣的一種景象。

讓我們再看看MDA，MDA的思路分離了模型和實現，這無疑邁出了迎接挑戰的最重要的步伐。但是，到目前為止依然有不少質疑MDA方向的聲音，這是為什么？MDA在模型表達方面做的工作還遠遠不夠。MDA 的四層模型表達能力雖然比3GL提升不少，但依然不夠，很多的業務邏輯無法直接描述，只能用過程型的計算邏輯表達。而OMG組織在MDA的方向重點是模型變換，也就是說，MDA目前的努力依然是在解決次要任務。

??? 相對于復雜概念結構的模型表達，模型的實現方式是變換還是直接執行并不重要。響應布魯克斯的呼吁吧，我們是該關注根本任務的時候了。

三、關注根本任務——模型表達

?????? 3GL的問題到底在哪？讓我們先做個假設，SOA 時代已經變為現實，整個互聯網就像運行著的一個進程，調用遠程服務與調用內部方法一樣方便。是否就解決布魯克斯說的根本復雜性了呢？當然還存在問題。

??? 機器指令、匯編語言、第三代編程語言（包括結構化3GL和面向對象3GL）和網絡出現之后的各種RPC（包括CORBA、DCOM、EJB、SOAP等）的發展都是以計算為核心、圍繞提升計算平臺的抽象層次，其主體是采用過程性表達，用指令告訴計算平臺如何做。

?????? 3GL的表達范式不適合用來表達復雜概念結構，不適合用來表達多種多樣的模型，不適合用來表達計算無關模型（CIM），導致了軟件業的根本困難，使軟件業無法應對需求的易變性和復雜性。如何表達這些多種多樣的模型呢？

??? 事實上，由于3GL表達的局限性，已經產生了多種專用的領域表達語言，就我熟悉的企業應用軟件領域來看，比如SQL語言、工作流描述語言（XPDL、BPEL、XLANG、WSFL、BPML、WSCI）、規則描述語言、權限描述語言、界面描述語言等等。這些語言的共同特征是表達目標領域比較自然、簡潔和表達能力強，而且與實現無關。它們都能比較好的適應技術和需求變化。

??? 這能給我們什么啟發呢？要表達模型，需要用合適的表達語言。當然，通用的模型表達語言并不容易突破，這也許是3GL后的抽象層次提升到現在都不理想的原因吧。但不要悲觀，我們看看可能的方向。

??? 模型表達是知識的表達。知識表達按范式分有說明性（Declarative paradigm）和過程性（Imperative paradigm），按作用分有結構和動態表達。到目前為止，并沒有適合計算機處理的統一知識表達手段。但有多種領域、學科在做探索。比如人工智能學科。人工智能中有多種知識表達方式，比如演繹系統、產生式系統、框架結構、語義網絡、描述邏輯和過程性知識。這些方式構成了強大的知識表達體系和應用能力，其中有不少在軟件中以得到應用，比如目前主流的規則引擎都是采用產生式系統，不少專家推理和知識系統采用一階謂詞邏輯表達。

??? 我們再看看Web的發展方向。W3C明確指出，語義Web是方向，而且已經做了不少工作，取得不少進展。今年剛剛通過OWL（Web Ontology Language）為推薦標準，這為語義Web的發展奠定了堅實的基礎。OWL基于描述邏輯（Description Logic），在表達結構和語義方面有其獨到之處。最近，根據OWL，OMG也開始定義自己的本體表達語言ODM（Ontology Definition Metamodel）。這些情況表明，形式化的語義表達和推理即將姍姍來遲，這將為模型提供結構方面的形式化語義表達能力。這一點非常重要，因為到目前為止，軟件處理的都是弱語義數據。這不但容易引起非常多的不應該產生的錯誤，而且軟件幾乎沒有語義關聯和推理等智能處理能力。

??? 如何融合聲明性和過程性、結構和動態表達方式，形成協調、適合計算機處理、表達能力強和富語義的模型表達體系，甚至統一的模型表達語言，也許是突破根本復雜性的希望所在。

四、希望現代版西西弗斯的苦役早日結束

??? 面對苦役，我們技術人員應該怎么辦？首先，認清各種技術的實質是解決根本問題還是次要問題。其次，深入領域，學習、應用甚至創造特定領域模型表達語言是應對技術和需求易變性的不變之策。

摘自：http://blog.csdn.net/coofucoo/archive/2005/05/28/382722.aspx

總結

以上是生活随笔為你收集整理的变革前的思索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。