Free Software

接下來我要介紹的是問題領域相關的模型。一種描述問題領域模型的方式就是使用UML，大家都知道UML最初是由Grady Booch、Ivar Jacobson和我共同創建的，後來OMG裏的其他成員也陸續對這個語言進行了擴展。現UML已經成為物件領域被全世界開發人員廣為使用的一種語言。跟編程語言相比UML是一種更加高級的描述語言，在這種語言裏我們減少了很多不必要的、細節的描述。理論上講UML可以應用於很多領域，我們可以對UML加以改造，利用一種稱之為UML Profile的機制可以使UML用於某些特定的領域。UML Profile是在UML的基礎上針對某些特定的領域進行一些改造，使得它能夠支持這些業務領域裏特定的業務概念。但即便是我們使用UML Profile這種特殊的機制，UML本身還是一種非常通用的語言，裏面還是包含了很多重複性的細節。另外一種方式就是利用稱之為領域描述語言的DSL語言來描述問題領域的這些概念。DSL是一種特殊的語言，有它自己的語法和語意，它是針對某一種業務領域而設計的。DSL是利用一些比較高級的概念來描述問題領域的概念，這樣它可以減少業務領域跟具體實現之間的差距。DSL裏也可以包括一些預先置好的資料與模式，基於DSL的模型可以減少一些重複性的控制邏輯的描述，同時生成更加底層、詳細的代碼。這裏我們來看一些現有的DSL的例子。

         首先大家想不到的是在30年以前我們就有這樣一種DSL語言，就yacc，在這個yacc裏用巴柯斯範式BNF來構建編譯器。yacc編譯器就可以利用你所描述的BNF來構建複雜的語法編譯工具，從而減少手工開發這種編譯工具的難度。另外一種大家想像不到的DSL是大家經常用的GUI編程工具，來幫助你搭建用戶介面。在這種工具裏就可以在螢幕上畫上你想要的表格、圖表或者是控制項等等。大家看到在螢幕上畫了這些控制項，在內部代表著上千行的代碼。但是開發人員不用去描述這些細節的控制邏輯，工具會幫你做到所有的這一切，這樣大大簡化了開發人員的工作量。另外一種DSL大家可能都想像不到，就是我們日常在使用的桌面編輯工具，像FrameMaker 或者是Word工具。作者可以很容易地用這個工具來寫下他們所編輯的書或者是插入一些他們想要的控制邏輯，像圖片等等。另外一種就是大家知道的MIDI，用於在樂器跟電腦之間的一種描述語言，它可以讓電腦也能夠產生音樂。音樂家利用MIDI這種語言不用編程就可以創造出音樂。另外一個例子就是數學上的一些應用工具，利用這些工具用戶可以直接用數學運算式、數學公式來描述一些複雜的概念。

         這裏我再給大家介紹另外一種特殊的DSL，就是以前大家廣為使用的SDL。SDL是國際電信聯盟ITU所通過的一種標準，很多電信製造商都在利用這種標準來描述他們的電信設備，如交換機。很多知名的電信企業如摩托羅拉、愛立信等都在使用SDL來描述他們的應用。這種語言提供了複雜的描述手段，使得這些企業能夠利用它來描述電信上的一些複雜協議。我跟這些企業的開發人員都有過一些合作，我發現他們在使用一些工具時都存在著一些困難。因為隨著時代的進步SDL逐漸退出了主要的潮流，它並沒有包括一些最新的像UML工具裏的一些特性。最近物件管理組OMG剛剛完成一項專案，就是把UML升級到UML2.0。來自於摩托羅拉、愛立信的開發人員成為這個項目組的成員之一，在這個專案裏我們把SDL的一些概念也加入到UML2.0裏面。所以當UML2.0出來之後現在可以把SDL做成UML的一種Profile。這意味著傳統的SDL的用戶也可以利用UML工具來繼續你的軟體發展，同時也可以利用UML裏其他的一些特性。這也是一個很好的DSL語言的發展歷程，在這個歷程中大家看到如果一種概念型的領域描述語言比較有用的話，其實還會繼續延伸它的生命力，比如像SDL被加入到UML2.0裏去。

         有關這個領域描述語言有幾種不同的類型，有一種形式稱之為描述式 (Declarative) 的。在這種描述式的語言裏只需要描述我們需要做什麼，但是並不需要描述詳細的控制邏輯。這就像我們用數學公式來描述複雜的數學問題一樣，並沒有說明我們應該如何來解決這個問題。這種形式的DSL被廣為使用，因為簡化了開發的工作量，他們並不需要描述詳細的控制邏輯。如果電腦能夠自動地生成這種解決方案的話，這其實是一個非常有用的方式。但是實際的情況並不是如此，所以會有另外一種形式的DSL語言稱之為命令式(Imperative) 的，需要寫出一行行的指令來告訴如何解決這個問題。這種形式的DSL詳細描述了具體的控制邏輯，當然也給開發人員帶來了難度，因為它更難以使用。所以我們想出一種折中的方式把這兩種形式結合起來。在這種方式裏我們就用一些高級的描述性的方式來描述這些問題領域的概念。在開發的後期我們可以使用低級的命令行的方式來描述這些細化的控制邏輯。這種方式實際上是結合了前面兩種描述方式的優點。現在又有了一個非常流行的概念叫做觀點導向編程 (AOP – Aspect Oriented Programming) ，在這種方法裏我們是把不同的需要解決的問題劃分成不同功能的Aspect，一些有關Aspect的例子就包括如何控制安全性、如何永久地保存資料、如何提供一種併發的處理機制、以及如何記錄一些日常資訊等等。所以每一種Aspect實際上可以幫助我們來解決某一個特定領域的問題，但是這種解決方案是橫跨整個系統的。在這種方式裏我們需要有一個翻譯軟體把這些Aspect轉化成具體的代碼。解釋軟體應該知道Aspect之間的差異和相互的交互，應該能夠補充一些必要的代碼把他們整合起來。實際上從本質上講AOP方法跟剛才講的DSL語言是非常接近的，在每一種方法裏都有一種高級的描述方法來描述問題領域的這些概念，同時都需要有一種翻譯軟體把這個模型翻譯成最終的實現。現有的這些AOP語言並不是太好，有些並沒有我們想像中工作得那麼好。翻譯工具不能很好地工作，開發人員還是需要去描述一些他們之間實現的細節。我認為在AOP這種技術真正非常流行之前，我預期到AOP的下一個版本一定要增強轉換 (transform) 的功能，這樣才能能使得它更加流行。我認為這種DSL語言可以幫助我們來描述這種AOP 的自動生成、自動轉換功能。

  接下來我們來看一下架構框架。架構包括好幾樣東西，首先在構建架構時要做的是將系統分解成為一些子系統，這些子系統本身應該有完整的功能，同時應該能夠相互交互。子系統之間功能上不應該有重疊，在這種架構裏我們需要描述子系統之間交互的拓撲邏輯，常見的拓撲邏輯包括像流水線、星形結構等等。架構的另外一個方面就是要描述子系統之間的交互規則以及他們所交換的資料格式。另外架構設計師也需要描述有關資源管理的規則，這樣使得不同的開發人員能夠更加有效地來使用這些資源，這裏提到的資源就包括像記憶體、系統進程等等這些概念。所謂好的架構跟差的架構之間的差別就在於一個好的架構它能夠更好地適應系統將來的變化，注意這個變化是不會自動發生的，是應該由架構設計師為將來的變化做好準備。在一些好的架構裏會使用“鉤子（Hook）”這種機制，它可以使得我們不用修改這個系統就可以增加一些新的功能。我們經常看到很多專案延期的情況，原因就是專案裏的很多測試工作被忽略掉了。舉一個類比，大家想想現在汽車裏的發動機，發動機裏有很多感測器，這樣汽車上的電腦可以隨時感知發動機裏的工作狀態。大家想像一下如果先把發動機造出來再把感測器放進去，這實際上是行不通的，在設計發動機時就應該考慮要把感測器放進去。在做開發時架構設計師也要把測試這個概念加入到開發過程中去，使得測試成為我們開發過程的一部分。所以我們應該在早期設計架構的時候就應該考慮到測試，這樣能夠有效地提高軟體的品質。實際上大家都知道架構是很難去搭建的，我們想方設法使得架構這種工作對開發人員來說變得更加簡單。所以我們是把其他開發人員在開發過程中得到的一些好的架構經驗總結出來，稱之為架構框架。所謂的架構框架實際上是一種可重用的架構模式，這種模式是從好的架構模式裏總結出來，這些架構模式可以進一步地被其他人所重用。

         架構框架包括好幾樣東西，首先我指的是執行環境的框架，這裏包括很多小的元件，這些元件之間是相互繼承的。這些小的控制單元對用戶來講並沒有提供它的價值，它所關注的只是這些小的控制單元內部的控制邏輯。它也包括預先定義好的系統之間交互的介面、資料格式等等。所以我們可以預先構建好一個系統，逐漸地往裏面增加它的功能。實際上我們很難把所有的東西都組合在一起，一下子把它構成一個可運行的系統。如果你試圖把所有的東西一下子都集成起來的話，這實際上是非常困難的。一種比較簡單的方法就是你從一個小系統開始，在開發的過程中逐漸往這個系統裏增加功能，逐漸地把這個系統建立起來。基於這種開發理念，我們在設計架構框架的時候就會預留好一些擴展點，通過這些擴展點可以增加更多的功能，這些功能有可能體現為一些插件。在構造系統時就是把不同的插件插到不同的系統上去，好的架構框架應該也包括一些可重用的構件。開發人員應該利用現有的構件來開發系統，而不需要寫代碼。在構建一些複雜系統時，開發人員有可能也需要自己去開發一些構件，但是並不需要所有的構件都從頭做起。一切好的架構框架實際上都應該包括一些好的例子，這樣對我們可以有更大的幫助。實際上大家都有這種經驗，當你採用一種新技術時很難判斷怎麼樣把各種部件集成在一起，但是如果這時有一些很好的例子的話，我們的工作就會變得簡單。這裏大家看到的一些有關架構框架的例子就包括我們經常談到的Eclipse、.NET或者是J2EE架構。

         使用架構框架可以給我們帶來很多好處，它可以使我們非常容易地利用DSL來描述一些現有的概念，也可以幫助我們來保證系統的一致性。如果系統是由很多小組來開發的話，這種框架可以在不同小組搭建的系統之間保持高度的一致性。另外它也可以保證基於同一種架構框架的不同開發應用也保持高度的一致性。另外它使得用戶的介面所使用的資料模式、用戶的體驗等等在不同的應用之間也保持高度的一致性。架構框架也可以很好地幫助增量式的開發，可以從一個小的系統開始，基於這種框架來逐步增加它的功能。另外架構框架也可以減少我們開發設計的工作量，使得不同的開發人員在設計的時候減少他們的分歧。

         我們有很多種方法來幫助我們描述一個架構框架，第一種方式是可以用UML模型來描述架構框架，可以描述結構模型、介面模型、描述模式等等。基於那種框架我們可以描述DSL語言的語法和語意。每一種架構框架都會包含一些具體的代碼，象C++或者是Java等等。每一個框架也應該包含一些文字描述來告訴使用者如何來使用這個框架。總而言之架構框架的基本思想是要從專家手裏把一些好的經驗總結出來，使得所有人都能夠共用這些好的經驗。一個類似的例子就是模式 (Pattern) ，模式已經是十年前的一個概念了。模式可以幫助我們來構建架構和解決一些具體的技術問題。什麼是模式呢？模式是針對常見問題提供的解決方案。很多模式都有不同的參數，這些參數使得模式可以應用於不同的領域。所謂的模式有很多種級別，有些是比較低級的，象通常我們講的設計模式，也有一些是幫助我們來構建模型的，也有一些是幫助我們來搭建系統架構的。跟我們剛才提到的架構框架一樣，每一個模式它都應該有這樣幾部分，包括架構、結構、內部的交互規則以及一些使用指南等等。另外一種共用經驗的方式就是來構建可重用的構件，構件是為一種特定的架構所設計的，在這個架構下不同的構件可以很好地相互合作。

          接下來我再給大家介紹的是MDA技術中有關自動化工具的部分。我們在做MDA開發時需要的是一個建模工具，這個建模工具可以幫助我們來描述模型以及各種模式。如果你開發的是一個小系統，只有兩三個人的小專案，就不需要建模工具。但是即便是簡單的問題也有必要來使用工具，例如你會使用計算器來把資料加在一起，這樣使你的工作更加簡便。對於一些大的專案、十幾個人的專案當然需要一個建模工具來幫助你們團隊協作、幫助你們來記錄你們設計的結果。假如沒有工具來協調大家工作的話，在建模過程中你們的工作有可能會相互重疊、相互衝突，有些資訊可能會丟失。工具同時也可以幫助我們來找出你設計中的一些錯誤或者是瓶頸之所在，幫助我們避免一些問題。一個好的自動化工具也可以根據你所指定的特定架構和平臺來生成可運行的代碼。自動化工具在生成代碼時也會生成一些追蹤資訊，就是從模型到代碼之間的關聯關係也會被記錄下來。對於一些大的專案而言，有可能你們會使用很多種不同的工具，這些工具有可能帶來的困難是他們之間很難進行資訊的交流。在這種情況下我們需要有一個公共的存儲庫來存放和管理所有的這些工具所產生的資料。這種公共的存儲庫應該可以使開發人員自由地修改資料，而並不影響其他人的結果。用於構建這種存儲庫的技術就包括MOF（Meta-Object Facility元物件設施），另外一個是XML (eXtended Markup Language) 。

          用於MDA開發的另外一種工具主要是翻譯工具，可以幫助我們把模型自動地翻譯成為代碼。一個好的工具可以基於某種特定的平臺幫助我們生成代碼。另外一種翻譯工具就是一些代碼優化工具。一個例子是，大家可以把這種優化想像成為它可以把一個簡單的代碼映射成為複雜的代碼，從而提高運行效率。另外的轉化工具包括重新排版、組合這些代碼等等。實際上一個好的轉化工具是很難得到的，現在我們有很多種不同的變換工具，現在物件管理OMG正在進行的一個專案稱之為QVT (Query-View-Transformation) 項目，就是查詢、察看和變換，這個專案的主要目的是為變換工具制定一個標準。這個項目預定是在明年的第一季度結束，一旦這個標準出臺的話，它就可以使得不同的變換工具之間的協作變得更加簡單。

  對於這種變換工具我們到底有哪些要求呢？首先這種變換工具一定要理解源和目的語言的語法，同時在這種工具在生成代碼時，不要指望它生成的是最好的代碼（可能是比較好的代碼），因為通過這種工具已經減少了我們很大的工作量。實際上在這種變換工具上已經有很多年經驗的積累，比如大家經常用到的編譯器，我們希望把編譯器上好的經驗吸收過來。一方面需要構建自動化的變換工具來幫助我們轉換代碼，但是同時也要注意到我們現有的項目有很多歷史代碼。我們希望這種新的QVT標準能夠接受插件，以插件的方式來支援現有的這些代碼。對於這個變換工具的另外一個要求是要使得它能夠維護代碼跟模型之間的關聯，因為每當你對模型作出一個小的修改時，我們是希望這個工具能夠相應地生成變化的代碼，而不是每當你修改一部分模型之後這個工具需要把整個模型重新生成一遍，這是非常費時的。為了滿足這種要求，變換工具需要保持模型跟代碼之間的關聯關係。對於這種變換實際上我們有幾種不同的方式。第一種就是部分的轉換，在這種方式裏我們是把模型轉換為代碼，但是在這種轉換裏很多實現的細節是被忽略掉的。比如說現在大家正使用的很多UML工具實現的就是這種轉換，這種轉換只是幫你生成資料結構或者是一些簡單的代碼框架。所以這種變換方式生成代碼非常快，但是開發人員或者是編程人員需要做更多的工作來增加細節的描述。當然在這種變化裏存在著風險：如果編程人員修改代碼的話，有可能會破壞掉代碼跟模型之間的關聯。我們稱之為雙向變換的技術實際上是可能的，只要我們在這種變換工具裏，在生成的代碼裏保持這種代碼跟模型之間的關聯關係就可以了。所以每當開發人員修改模型的話，我們就知道相應的哪一塊代碼需要做相應的修改了。但是這種逆向的變換往往是比較模糊的，從代碼到模型我們往往不知道怎麼樣根據代碼生成一個什麼樣的模型。主要的原因是因為代碼比模型包含的資訊更少，但是這種部分的變換技術其實是比較切實可行的技術，因為我們可以快速地利用它來建立我們的模型，並且生成我們的代碼。但是從長遠的角度來看這有可能並不是一個很好的解決方案。

          另外一種取而代之的方法是完全生成，在這種技術裏我們只有一種單向變換，就是從模型直接變換到代碼，而且是百分之百地生成代碼。在這種方法裏開發人員是不會去修改生成的代碼。但是這也對DSL語言提出要求，DSL應該有能力來描述足夠的細節。編譯器就是一種完全生成的很好例子。大家都有這種經驗，只會用編譯器生成代碼，但是從來不會去修改編譯器所生成的彙編代碼或者是資訊代碼。當我在很多年以前開發工作時這並不是一個事實，那個年代人們對編譯器還不是非常信任，開發人員經常去檢查編譯器所生成的代碼。現在編譯器已經發展得足夠成熟、足夠好了，所以大家都非常信任這種變換。現在大家用的另外一種完全生成的例子包括格式的轉換，比方現在有些工具可以幫助我們從UML模型生成XML格式。完全生成這種技術有可能適用於那些我們能夠掌控所有細節的場合下使用。儘管現在這種完全生成的技術不是非常成熟，但是我預期在將來這種技術應該是越來越可用的。

         第三種方式其實是把前面兩種方式都結合在一起，就是把代碼嵌入到模型中去。在這種方法裏開發人員會把代碼的片段插入到模型中去。在這種模型裏如果DSL的描述能力不夠的話，開發人員就會用編程語言來描述這些細節。當變換工具生成代碼時就會把開發人員插入的代碼嵌入到最後生成的代碼中去。所以如果開發人員想修改最終生成的代碼的話會修改這個模型中插入的代碼片段，重新利用這個模型來生成代碼。這種方式有可能更象我們談到的部分生成的例子，因為在這種技術裏開發人員還是需要來寫一些編程代碼。但是他們還是有不同的，因為在這種技術裏我們是把模型跟代碼存放在同一個檔裏。與其他的技術相比這種方式避免了我們丟失了模型跟代碼之間一致性的危險。因為這個變換工具知道插入的代碼在模型的什麼地方，所以它可以很好地在模型跟生成的代碼之間搭建這個映射。實際上這是一種非常靈活的技術，這種技術在幾十年以前，在剛才提到的編譯器的生成裏面就已經用到這種技術了。這是一種非常靈活的工作方式，但是它要求開發人員同時在兩個不同的層次進行工作，他既應該在高層次模型這個級別工作，同時也需要開發人員在低層次代碼這一級別進行開發工作。但是在當前這個情況下，在我們有更好的完全生成的解決方案之前，這有可能是一種比較實際的技術。最後是一種更加先進的變換技術，在這種變換技術裏我們為這種變換本身搭建起一個變換的模型。在這種技術裏面，我們會針對這種變換來建立起一個模型，並且利用這個模型把原模型跟目標代碼聯繫起來。利用這種開發技術進行開發的話，就意味著我們通常所講的設計就是要去構建出這樣一個變換。一旦我們搭建起這樣一個變換模型就可以把這種變換應用到很多源模型上去。比如說我們可以應用這種技術來構建一些模式，利用這個模式應用到很多領域上去。這是一種非常強大的技術，但是我並不認為這是每一個開發人員都適用的一種技術。這種技術需要一些特定的技能以及相關的知識。但我還是認為這種技術可以給大家帶來益處。誰可以用這種技術呢？是一些在開發團隊裏專門負責構建這個模式或者是構建架構框架的人，有一部分人可以用這種技術來構建出比較好的模式或者是架構框架，使得這種好的經驗可以使更多的開發人員受益。

          很多對於建模的批評就集中在模型是不可以運行的，我並不認為這是一種很好、很正確的想法。並不是說你看到一個模型就可以去執行它，實際上你可以利用一些自動化的工具來執行這個模型。早期的模型應該是不完整的，所以你不能期望它是可運行的。因為這個模型是不完整的，它裏面有可能缺少一些必要的資料或者是一些未知的決策，這些都會阻礙這個模型成為可運行的模型。在某些開發模型裏我們並不在意這種可運行，因為有些架構設計師他只關注於這種模式，但是並不在意具體的資料結構。這裏可以採用的一種技術就是儘早地對架構進行一些測試，有可能還有很多細節不清楚，但是我們還是有辦法對架構進行測試的，在IBM內部我們正在開發這種技術。也有人建議把UML變成一種可運行的語言，但是我認為這並不是一個很好的主意。基本的UML實際上是不可運行的，因為UML是一個作用非常廣泛的語言。UML在設計時就被設計成用來支持很多種不同的運行平臺、很多種不同的編程語言，所以如果想把UML變成可運行的跟你的想法之間就有一定的差距。另外UML本身作為一種建模語言，在其內部缺少了一些運行方面的語意，比如說你是不是需要多工，還是外部的資料交換的格式等等。怎麼樣使得UML變得可運行呢？你可以針對某一個特定的運行平臺來制定一個特定的UML Profile。比如說有一個現實的例子就是RealTime Profile，這個Profile使得UML可以在即時系統設計這個領域變得可運行。但是大家注意UML本身還是一個通用的描述語言，DSL可能是在很多情況下表述能力都要更強一些。我的想法是可以把UML作為DSL最終實現的過渡語言。我們可以把DSL所描述的語言模型轉換成為用UML描述的一個中間產品。然後可以用工具把這種中間化的UML模型進一步轉換成特定平臺上可以運行的代碼。這就等於是構建了從不同的DSL模型到最終可運行平臺的轉換跟變換。

剛才介紹了很多MDA的概念，下面做一下總結。MDA還是一種非常早期的技術，我預計要再過四到五年才可以看到MDA技術被廣泛地接受和採用。現在很多團隊還只是把MDA在一些小的試點專案裏應用，現在也有很多有關MDA技術的片斷，但是這些片斷其實並沒有在一起很好地協作。我建議大家如果有興趣的話還是要儘早地去嘗試這種技術，這樣可以更好、更早地來體會MDA給你帶來的好處。DSL這種語言還很少用到，但是會有更多的DSL語言出現。舉個例子，微軟最近也宣佈支持DSL，說明大家跟IBM都有同樣的想法。從這裏大家可以看到越來越多的企業在支援這些新的想法和概念。現在我們也有一些非常通用的框架存在，比如說剛才介紹的一些常用的像.NET、J2EE等。一些業界的標準化組織也在逐步地開發特定領域裏的框架模型。比如說OMG裏有一個專案正在開發針對醫療領域的框架模型，利用這種框架模型使得不同的醫療設備、診斷儀器之間可以很好地協作。現在也有一些團體在另外一些框架模型上工作，比如說針對金融行業、運輸行業的。為了更好地推廣應用MDA技術我們也需要有一個好的變換技術，當然這個變換技術現在還處於一個比較早期的階段。可以預見的是明年QVT技術可以成為現實，這就是一個很好的開端。但是在我們廣泛接受這種變換技術之前我想還是需要一段時間來適應、應用這種技術，一個更新版本之後這種技術才能得到更為廣泛的應用。我們也有很多經驗可以來自于現有的編譯器技術，可以把這些經驗加到變換技術裏去。現在看起來MDA技術還是一個非常新的技術，但是可以預見到它在將來的幾年裏會對整個軟體發展行業產生非常重大的影響。謝謝大家!