Eiffel語言教程——Eiffel語言的軟體開發過程（An Eiffel Tutorial——ET: The Software Process in Eiffel）

Eiffel語言的軟體開發過程

前面已提到，Eiffel支援整個生命週期。下述軟體開發週期觀點不僅從根本上不同於傳統的“直瀑”模型（指一連串的獨立步驟，如需求分析、總體設計、詳細設計、實現，由主要的方法和標記法分開）， 同時也不同於其最新變種，如螺旋模型或“快速原型”這種依然基於同步的，全生產過程，同時還保留著成功步驟間的空白時間。

很明顯，並不是所有Eiffel使用者都會遵循下面提出的原則；事實上，一些非常成熟成功的Eiffel開發人員並不完全同意用這些原則，而去使用不同的過程模型。儘管它可能匹配不了開發人員的思維模式，但在作者的心目中，這些原則能最好的和本語言以及其它的方法相適合。

內容

• 聚集和聚集模式
• 無縫性和可逆性
• 範化和重用
• 長期可用性
• 編譯技術
• 品質和功能性

聚集和聚集模式

不像早期的一些方法，Eiffel假定軟體系統被分成一些子系統或聚集。每個聚集保持用直瀑連續方法開發（無間隙地）。但整體進程並發進行，如所示：

 在以後開發手法中，特別是資訊隱藏和契約式設計，通過一些手斷使並行開發過程變為可能，這些手斷是：使聚集通過清晰定義的介面互相依賴，嚴格限制使用聚集所需要的資料量和允許單獨測試。當一個工程發生了不可避免的意外，工程領導可以利用模組的靈活性將不同的聚集提前或延期，並逐步執行資源的再分配。

每個獨立的聚集生命週期都基於一系列連續的活動，從更抽象到更面向實現：

 

您可以將這張圖片看作是一個不斷積累的過程（就像是鐘乳石的積累那樣），在這裡每一步不斷豐富著前一步的結果。不像傳統的觀點那樣強調軟體開發的多樣性——需求分析、總體和詳細設計、程式編寫、維護報告……，這裡的原則是將軟體看作是一個重複精鍊的，可擴充的，改進的單獨產品。Eiffel語言通過提供從系統模組化的，最普遍的、軟體獨立的活動到為最優的運行時表現而調試的實現的嚴格細節提供可用於整個生命週期進階方法對些觀點的支援。

這些性質使Eiffel語言跨越了兩個範圍——“物件導向方法” 和與之相關的表達方法，如UML和支援CASE工具（儘管大多數這樣的解決方案並不產生可執行檔結果），還有“程式設計語言”（儘管大多此類語言並不適合設計和分析）。

無縫性和可逆性

前述思想定義了Eiffel包含的無縫方法。伴隨無縫性的往往是可逆性：回溯的能力，甚至從進程的結尾回溯到進程的開頭。因為開發人員基於一個單獨的產品開發，所以他們可以利用可以有後知後覺機會的優勢——比如在實現過程中發現了添加一個新函數的好想法——並把他們整合至產品中。傳統方法傾向於不鼓勵可逆特性，因為要保證分析和設計與後來的變化同步更新很困難。但對於單產品原則，這很容易實現。

無縫性和可逆性提供了從解決方案的結構到問題描述結構的直接映射，這使得擴充性得到了加強，也使得對客戶更改的要求作出快速有效應對措施。它們也避免了客戶與開發人員之間的誤解，從而增進了可靠性。同時它們也增強了維護性。普遍來說，它們創造了一個平滑、一直的、高品質、高生產力的軟體開發過程。

泛化和重用

聚集的最後一步，泛化，是傳統模型中不具備的。它的任務是通過尋找含有普遍適用性的元素並將其重組進庫中為實現工程間的重用準備聚集的結果。

最近的有關物件導向的文獻都使用了“重構”一詞來描述已發行的軟體的不斷改進過程。泛化包含了重構，但它追求一個更具雄心的目標：協助程式元素（僅對某一特定程式有用的軟體模組）變為軟體組件——含有它們自己的一個值的可重用的部分，並已經準備被可以從中獲益的不同程式使用。

當然並不是所有使用這個方法的人都會準備好去用泛化的表達方法。但那些使用了的人會發現在他們軟體的可重用性被大大增強了。

長期可用性

完善先驅規則的想法是這樣的：在聚集的生命週期，Team Dev（由工程領導的負責）應當在任何時候維護一個當前工作的樣本，儘管它僅為最終軟體系統的一部分，但它可以運行良好，並可以當作示範品，或——可以在合適的時候——作為早期發行版。這不是一種註定要拋棄“原型”，而是向著最終產品的進化的迴圈；成功的迴圈將會向著最終產品不斷演化。

編譯技術

先驅目標得利於反覆檢查當前迴圈的正常性和健壯性的能力。在EiffelStudio中，Eiffel通過如融冰技術這樣的機制支援高效的編譯機制。融冰技術可以在代碼發生改變後進行立即重編譯，保證重編譯時間是變更代碼大小的一個函數，而不是整個系統大小的函數。即使對於一個有著上千個類，上萬行代碼的系統，修改過個另類後重新啟動的時間，在一個當代電腦上，也就是幾秒的事。

這樣一次“融化”（重編譯）會立即捕獲類型錯誤（與語法錯誤）——常常是概念錯誤的徵兆，如果對這些錯誤置之不理，將會在開發的後期甚至在操作中引起嚴重的損害。一旦類型錯誤被改正，依靠斷言的力量——在“契約式設計 斷言，異常”中有詳細敘述——開發人員應當開始測試新的功能，將bugs扼殺在搖籃裡。如此大量的單元與系統測試，不斷的交錯在開發過程中，在確保“當前樣本”是否可靠和是否能生產出一個正確強壯的產品中起著重要的作用。

品質和功能性

貫穿整個開發過程，Eiffel方法建議維護一個固定的品質標準 ：應用所有的語言規範、加入所有的斷言、進行錯誤處理（而不是太司空見慣地認為以後會有人“將產品變得健壯的”）、強制使用合適的體繫結構。這適用於除了可能的可重用性外所有品質因素（因為一個開發人員可能不知道以後要了最好怎樣才能泛化一個組件，而且如果嘗試完全泛化一切可能導致與迅速地解決手頭上的明確的問題相衝突）。一切變數便是功能性：隨著工程的進展和聚集的到位，更多的產品計劃中層面變為現實。關於工程最常見的問題是，“我們能發布一些什麼了嗎？”，翻譯過來就是“我們完成的夠多了嗎？”，而不是“它夠好了嗎？”（換一種方式就是“它不會崩潰吧？”）。

當然不是所有Eiffel使用者（比使用其它方法的人要多）可以保證當前的觀念會一直保持不變。但它是這個方法傾向的理論方案。它解釋了Eiffel在令一切正常運轉上的重點：宏偉的結構，平淡的細節。就細節而論，在Eiffel書目中引用的圖書，包括了許多規則，其中一些第一眼看很不錯，關於如如何選擇類名和屬性（包括其文法分類）名、軟體文本的縮排、注釋風格（包括是否存在結尾）和空格的使用這樣的低級層面上的問題。應用這些規則當然不能就保證了品質；但他們和一些更激進的設計原則一樣都是面向品質的開發過程的一部分。另外，他們對於構建作為Eiffel的中心目標的高品質庫特別重要。

無論它們何時與空間限制想匹配，本章節和本書的其它章節都會將這些規則應用到執行個體中去。

英文原文地址：http://docs.eiffel.com/book/method/et-software-process-eiffel