我們何時可以認為軟體產品被真正地完成了呢?通常情況下,當我們不再為其提供後續支援,或者該產品已經 被其它產品替代的時候,它的生命就終結了,幾乎所有軟體產品都會經曆從開始到結束的演化過程。但存在了很長 時間的大型企業級系統卻會隨著時間的推移,向不可維護、變僵硬的趨勢發展。這導致了軟體開發的停滯,使得響 應客戶需求的時間變長。
本文說明了如何使用MDSD方法來決這些問題。文章首先介紹了我們要解決的問題——向後相容性問題和升級問 題,說明了為什麼這些問題很難解決,然後描述了在當前的軟體體繫結構中容易隱藏非功能性關注面的地方。
文章中舉了三個例子,用來說明MDSD技術如何協助我們在不損失靈活性的前提下,解決軟體生命週期問題。這 些例子都是來自於電子保健行業中的真實敏捷項目,作者還說明了其中的最佳實務可以怎樣應用於其他情況下。
項目中得到的經驗教訓被總結為拇指規則(在面對複雜環境時候採用的一種簡化或經驗性的處理方式,因為理 性的處理能力是有限的),在文章的最後,引用了一些有用的架構與工具,它們是目前解決方案的基礎。
介紹
在軟體工程領域,經過幾年的實踐,模型驅動的軟體開發(MDSD)已經證明了它並非是曇花一現。如今,MDSD 的很多承諾[1]已經變成現實,大量成功的例子也持續湧現出來。
本文說明了可以如何使用模型驅動方法來解決當前軟體系統中的一些問題。牢記MDSD最佳實務[2],我們將關注 軟體生命週期本身這個非功能性需求。
軟體生命週期
幾乎所有的現代軟體系統都面臨著生命週期問題。當產品發布或是部署時,你不得不解決向後相容以及遷移策 略等問題。我們通常會低估產品相容性問題,或是在開發中完全忽略這個問題。當我們不得不花費很多資源來解決 產品相容性問題時,才會後悔莫及。嚴肅地看待這個問題會影響到軟體產品的演化,正如我們將在下面這個例子中 所看到的。
案例:java.lang.Cloneable
Java中的java.lang.Cloneable介面說明了向後相容性是如何限制軟體演化的。該介面在JDK 1.0時被引入,僅 作為一個標記,並不提供任何介面方法,想要支援複製的類型都需要實現這個介面。
此外,它還需要提供 java.lang.Object.clone()方法合適的實現。其實clone()方法如果定義在 java.lang.Cloneable介面中似乎更有說服力,並且更自然。但事實上該介面從未改變過,因為那將會破壞向後兼 容性。引入複製介面方法會導致對所有已實現該介面的類的編譯錯誤。關於這個bug的完整曆史,請參看[3],對於 java.lang.Cloneable更詳細的討論,請參看[4]。
在分析我們系統中已經存在的生存周期問題細節以前,非常有必要建立一個公用術語表。
向後相容性
如果出現以下情況,那麼可以認為該系統是向後相容的:
它能處理以前系統的介面
它能處理以前系統的資料
該系統的使用者不必關心系統版本改變
系統的修改可能引發向後不相容的問題。通過引入相容性層可以解決這個問題,該層負責提供以前系統介面的 視圖。在這樣的環境中,權衡並設計進-出良好的介面更加重要。
關於二進位與原始碼的相容性在本文中不做討論,[5]中描述了它們和Java語言之間的差異。
更新
更新描述的是對已有軟體的改進。通過一次更新,應用的特性集是不會被擴充的。更新的主要目的在於提供額 外的健壯性(例如修複安全隱患)。更新不會涉及到介面與資料描述的改變,它不會引發向後相容性問題。OSGi版 本控制體系[6]定義了版本分類模式major.minor.micro。一次更新只增加第三位,即micro位的版本號碼。