軟件工廠的問題和新方法

領測軟件測試網

本頁內容

	是什么讓我們裹足不前
	目前的經濟模型
	長期的軟件開發問題
	我們怎么前進呢？
	系統重復利用
	模型驅動的開發
	組裝開發
	過程框架
	總結

是什么讓我們裹足不前

為什么我們無法提高軟件開發的自動化水平？主要有兩個原因：

目前的經濟模型

第一個原因就是目前的商業持續再使用經濟模型。在上一篇文章里，我們討論了語言框架模式，它描述了通向自動化的進展：

•	在開發完一些問題領域系統后，我們標識了一套可再利用的領域抽象，為了利用這些領域抽象我們文檔化了一套模型。
•	我們開發了一個運行環境，如同一個框架或者服務器，去編輯領域抽象和模型。我們通過示例、調整，配置和集成由運行環境定義的組件來構建一個領域系統。
•	然后我們定義了一種語言，同時創建了一些支持這種語言工具，比如編輯器、編譯器、和調試器去自動執行裝配過程。這些使我們更快的響應需求的變化，一旦有部分實現已經發生，也能夠容易改變。

這個模型的頭兩部分大多數組織都能夠做到，第三部分卻不能做到。開發基于語言的工具目前是相當昂貴的，因此經濟意識僅僅在寬而平的領域，例如用戶接口構造和數據訪問，這些必要的投資由龐大的用戶群體來分期清償。由于這個原因，語言框架模型的商業實現幾乎都由平臺賣主來提供。這個經濟模型是由抽象的范圍和價值交替的。如Jackson所述，抽象的價值會隨著問題域的特性而增長 。抽象的水平越高，領域應用就越窄，但是在該領域解決問題的價值越多，如圖1所示：

圖1 抽象的范圍與價值交互圖

我們正處在軟件產業的發展時期，框架和工具必須能更好的垂直交匯，以實現更高的生產力。它們必須為更小的問題種類提供更多價值。這違反了目前的經濟模型，因為垂直交匯的框架和工具太小了以至于不能支持平臺運行，同時由于需要去發展它們的領域知識主要在終端用戶組織那里，這些組織也一般不是軟件供應者。

長期的軟件開發問題

第二個原因是伴隨著軟件開發方法和實踐的長期問題。四大問題阻礙了其解決至少20年了，主要是整體性構架、沒有必要的一般性、一次性開發和過程的不成熟性。

整體性構造

我們不能夠通過在重大商業規模上的組裝來實現開發。問題不是我們不能夠認識機會。通過組裝的開發是工業先鋒先見之明的一部分已經數十年，當然自從面向對象產生，如果不早一點。我們也沒有為了實現這些目標正去投資。組裝的開發已經是學術和商業投資于面向對象和基于組件開發的目標。Garlan和其他人有如下建議：

•	通訊協議和組件實現技術聯系相當緊密，它使跨平臺邊界變得困難，包括同一種產品不同版本或者不同配置。
•	弱的組件規約和包裝技術使廠商很難交流一些關于組件和它們之間交互的信息，使得用戶很難預知由組裝導致的軟件屬性。例如，假如有一套任意的組件，一般很難知道它們做什么，它們之間的依賴是什么，它們消耗什么資源，它們體現什么功能，它們導致了什么安全風險。未聲明和有沖突的設想使構架不匹配，使組裝變得困難和不可能，降低了系統的操作質量。
•	封裝的技術，它在開發期間設定了組件邊界，使組件在組裝、開發或執行期間為了稍微不同的組件能有一定的聯系都變得很難。
•	軟件產業中供應商之間的聯系較之于其他產業顯得不成熟，由于缺乏有預見性、持續性和對用戶和廠商都有益的復用技術的技術和實踐。

沒有必要的一般性

目前的軟件開發方法和實踐一般提供了更多的自由度，對絕大多數應用程序是必須的。絕大多數商業應用程序，比如由基礎模型組成的。它們從數據庫中讀取數據，封裝有商業規則，體現給用戶，使用戶在商業規則的控制下進行操作，最后將結果寫回數據庫。當然，這只是個簡單的應用，現實中的商業應用一般包含了各種挑戰，比如和老式系統的交互，巨大的數據量，非常多的并發用戶，高質量的服務約束，這一切使得實現這些基礎模型比我們說的難多了。已經開發了許多商業應用程序的人會意識到，雖然有一些東西使得項目具有唯一性、特殊性，但是絕大多數項目之間是相似的。我們需要利用其一般性，用第三代語言(3GLs)如c#和java去開發更多的小部分典型商業應用程序嗎？當然不是，那為什么呢，我們需要排他性的依賴它們嗎？

•

第一個原因是未成熟的建模語言標準。UML，在某種意義上說很適合文檔化建模，但是不適合模型驅動的開發，因為它缺乏必要的集中性、可擴展性和語義的嚴格性，從而有效產生軟件代碼的和其他方面的自動化。另外一個原因是很難產生軟件代碼和雙向工程，不能夠和軟件生命周期的其他方面集成建模。CASE工具試圖通過模型來自動進行軟件開發。這些工具都因為許多原因而慘敗。也許最重要而有明顯的原因是無法按照承諾從與平臺無關的模型為多平臺生成代碼，當平臺技術改變時允許客戶保護其已有的投資。它們試圖通過生成大量的源代碼來填補抽象和平臺之間的鴻溝，如圖2所示。不同于程序語言編譯器，它們不能夠有效開發平臺特性，生產出一些無用的、無效的、缺乏公共命名的代碼。同樣，雙向工程的方法也是脆弱的，很難整理已產生的代碼，或者集成一些必要的手工代碼去完成復雜的行為。當它們在開發過程進行的差不多時，由于這些原因導致了開發者放棄模型而用手工的方式去寫代碼。迭代開發的實踐激化了這些問題，因為每一次迭代增加了新的需求，或者改變了原有的需求，導致了模型、自動生成的代碼和手工代碼的修改。 圖 2 幼稚的代碼生成

•

CASE工具不能按照交付時的承諾利用模型捕獲的元數據集成軟件生命周期。它們提供的例子也是不具有說服力的。比如，通過需求來捕獲的信息將被用來用例測試和測試用具開發。測試結果將用來作為缺陷記錄，劃定組件缺陷范圍。關于架構的依賴信息用來檢驗配置，在執行環境中自動提供資源。分析設計階段的努力試圖標準化軟件生命周期的信息模型，由于它們和實現特別緊密，所以即便是小小的改變也得看眾多賣主的意見，這些最后被證明是站不住的。通過開發工具來捕獲信息在軟件生命周期中集成也是差的。一個問題的原因是文件和常住信息數據庫之間的緊張關系。模型不能成為第一類開發工件，直到它們完全成為了基于文檔的軟件開發。其他的一個問題是錯誤的關注標準工具的構架而不是信息交互格式。工具的集成要求各供應商同意一致的交互格式。構架標準是不需要的，正如基于XML信息交互的不透明組件服務的成功。

一次性開發

我們不能夠完成重要商業水準的重復利用，超出了我們平臺的技術。主要原因是我們絕大多數軟件產品是和其他軟件產品孤立的，沒有聯系。我們把每一個產品看成是唯一的，盡管絕大多數產品之間的相同點大于其不同之處。如果在軟件產品計劃時期能夠將多版本、多產品綜合考慮，那么我們在軟件開發階段的投資回報將會更多。因此，我們很少在識別、收獲、包裝和分配可利用資產方面做重要的商業投資。重復利用有時是暫時的，但那不是系統的。假如將組件聯系起來再利用而不是為每一個組件都做一次設計是低效的，暫時的重復利用幾乎就是矛盾的。重復利用很難做到，除非事先能夠明確的計劃好。

過程的不成熟

我們不能夠在計劃和預算下持續的開發軟件，說明我們的軟件過程不成熟。大多數都傾向兩種極端之一。他們過度的規范，優化復雜管理，以管理不能變化為代價，或者過度的許可、優化管理變化，以復雜管理為代價。一個成熟的軟件過程首先必須是自動的，因為工具不能夠自動定義任務。

我們怎么前進呢？

通過應用重要的新方法能夠克服阻礙從技術到生產轉變的經濟和技術問題，這些方法在對付復雜性和變化方面采取了新的方式。這些新的方法目前也存在，同時在商業產品方面表現出了明顯的潛力，盡管它們大多數還不成熟。主要在四個方面：系統重復利用、組裝開發、模型驅動開發、過程框架。讓我們逐一進行考慮。

系統重復利用

軟件開發中一種最重要的新方法是定義軟件產品族，它們的成員在變化，但是卻共享著許多共性的特征。像Parnas，這樣一個族提供了一種環境使成員中共性的問題能夠集體解決。通過識別和區別特性，這些特性或多或少的存在于多產品和那些變化中，我們能夠采用一種系統的方法去重復利用。一個軟件產品族由組件或整個產品組成。比如，一個族應當包含不同的應用程序投資管理，包含不同用戶管理框架，用戶管理框架是由應用程序投資管理和用戶關系管理應用程序使用的。

軟件產品族是由系統整合業者(SIs)開發的， 從一個用戶到一個用戶移植應用程序，或者改進已存在的應用程序來創建新的應用程序。他們也通過獨立的軟件供應商開發軟件產品族， 開發區域多應用程序像CRM，或者多版本應用程序通過維護和改進。他們也通過IT組織來開發軟件產品族，改進已存在的應用程序，開發多關系的應用程序，或者多版本應用程序通過維護和改進。

軟件生產線的實踐

軟件生產線開發軟件產品族，通過標識共同特性和填寫特殊領域變化的表格，使軟件產品族中成員的開發變得更快、更便宜、更少的風險。而不是寄希望于暫時的重復利用，他們系統的捕獲如何開發家族成員的知識，使重復利用資產變得可能，在家族成員開發過程利用那些資產。作為一個家族的產品開發，可以重復利用需求、構架、框架、組件、測試和其他資產。

當然，開發一個生產線需要成本。換句話說，生產線體現了經典的成本-利益權衡。 等式一邊的利益不能夠通過在支持有限發布的市場上生產許多備份來增加收益時，但是可以通過生產許多相關的、唯一性的產品來增加收益，如許多案例研究所述[CN01]。利用軟件生產線是通向軟件工業化的第一步。使它們的創建和運行變得更加便宜是第二步。圖3在一條生產線上描述了主要任務的執行、工件生產和利用。

圖3 軟件生產線

生產線開發者應用開發資產去開發軟件族成員的方式正如平臺開發者創建設備驅動和操作系統以供應用程序開發商使用一樣。開發產品資產的一個重要的步驟是開發一個或者更多的區域模型，這些模型描述了由生產線提供的共同問題特性和描述不同的表格。這些模型共同定義生產線的范圍，被用來限定預期的軟件族成員。軟件族成員的需求就是源自于這些模型，提供了一種方式使需求的變化和構架的、實現的、執行的、開發過程的、項目環境的、和軟件生命周期的其他部分的變化相互聯系。

模型驅動的開發

在前一篇文章里，我們看到了提高抽象水平是一個重要的過程。我們也同時看到了，它減少了抽象的范圍，因此實現的時候也減少了開發者的控制。失去控制的損失是權力相應的增加。大多數商業應用程序開發者，比如寧愿使用更高水平的像這些用C#和.NET框架的抽象，而不是組裝語言和系統調用。更高水平的抽象產生許多好處，包括更高的生產率，更少的缺陷，更易維護和改進。

不幸的是，我們看到了提高抽象水平和工具非常昂貴。假如我們能夠找一些方法使它變得更快、更便宜、更容易，不過我們能夠為小的問題域提供更高水平的自動化。這就是模型驅動開發（MDD）的目標。模型驅動開發利用模型驅捕獲高層次的信息，通常是非正式的表述，自動實現，或者通過編譯模型來執行，或者通過它們使人工開發執行變得容易。這是重要的，因為信息目前在低層的工件里還找不到，比如源代碼文件、很難進行跟蹤，維護和持續改進。

一些開發活動，比如構建、配置和調試目前都是通過利用從源代碼文件和其他實現工件中捕獲的信息來實現部分或者完全的自動化的。利用通過模型捕獲的信息，MDD也能夠提供更多可擴展的自動化活動，和更多自動化優化表格，比如模型調試和自動化配置工具。以下是一些例子：

•	日常的任務，比如從一種東西生產另外一種東西，通常能夠充分的自動化。比如，測試用具通常能夠從用戶界面模型自動生產，使頁面之間進行轉換以模擬用戶的活動。
•	其他任務，比如解決工件之間的差別，能夠部分實現自動化。比如，表中的列和表單的域中可能是滿滿的問題待用戶去解決，然后由用戶決定自動進行校正。
•	適配器，比如Web service wrappers 在實現技術里能夠從模型到橋的差別自動生成。模型也能夠用來表示，協議配置，和其他適應的集成機制。
•	模型可以用來定義工件配置，這些工件由配置單元組成，使配置過程自動化。模型的配置環境能夠用來約束設計，以便能夠正確的實現設計。
•	模型能夠用來描述配置部件的配置，捕獲操作特征的信息，比如下載平衡，失敗恢復，資源分配策略，自動化管理活動，數據收集和報告。

特有領域語言

為了MDD，我們不再對一些末端語言如4GLs感興趣，也不對用一種高水平的語言以實現所有方面的開發感興趣。這些戰略的弱點已經被充分證明。我們也不再對會議上提交的模型感興趣，還有筆記。不幸的是，模型通常用來編成文件供人來用而不是計算機。這些造成了一種印象，模型不是第一類用源代碼的開發工件。我們對用工具來處理模型感興趣，我們也計劃用同樣的源代碼方式去用它們。用這種方式，文檔設計的模型不能用語言來表達。模型必須是準確的不含糊的。同時，為了提高抽象水平，建模語言必須著眼于小的區域而不是一種通用的編程語言。有如下要求：

•	語言設計的目標必須明確規定，以便熟悉領域的評審人員能夠評價語言和決定它是否實現了目標。
•	這種語言必須要能使工作在該領域的人員能夠捕獲業務概念。用于開發和裝配Web服務的語言必須包含一些概念如Web服務、Web方法、協議和基于協議的連接。同樣的，一種語言用來可視化和編輯C#源代碼必須包含一些概念（像C#那樣），比如類、成員、域、方法、屬性、事件和代理。
•	這種語言必須讓其用戶熟悉其概念的名稱。比如，一個C#開發人員發現一個擁有域和方法的類的模型比發現個擁有屬性和操作的類的模型更自然。
•	語言的符號，是圖片或者文字，必須要容易用來解決問題。人們日常作的事情必須容易用概念來表達。比如，它必須要容易用一種可視化和C#源代碼編輯的語言來操作一個繼承。
•	這種語言必須要有一套定義好的規則，叫做語法，管理組成概念的表達式。這樣使得用工具檢測表達式是否正確變得可能，同時幫助用戶寫概念。
•	每一個表達式的語義都必須定義完好，以便用戶能創建其他人也理解的模型，工具能夠從模型中產生合法的實現，從模型中捕獲的元數據當用來處理任務時能夠做其所期望的事情，像配置服務器。

滿足這些標準的語言稱為領域專用語言(DSL)，應為它為那些特殊領域概念進行建模。DSL比一般的建模語言更加嚴格。像一種編程語言，它也有文字或者圖片符號。SQL和HTML就是DSL的兩個例子，分別為關系數據定義和Web頁面定義服務。

圖 4 是兩個說明DSL的圖示的例子，是Microsoft Visual Studio 2005 Team System的一個屏幕截圖。左邊的DSL描述了組件，像Web服務。它被用來實現組件開發和配置自動化。右邊的DSL描述了數據中心的邏輯服務類型。它被用來設計和實現數據中心配置。Web服務開發是通過把服務部件拖到邏輯服務器上。邏輯服務器上資源需求和可用之間的不同，充滿了確認錯誤和圖示。

圖4 領域專用語言

增量代碼生成

高效代碼生成的關鍵是少生成概念上差別小的代碼。這樣就可以允許工具利用平臺特點，生產集中的、高效的、平臺特性的實現。一種使代碼生成增加更多的方式是讓模型更切近平臺，如圖5 所示。比如，用編程語言類型系統定義的專用編程語言比使用類型系統定義的建模語言能實現更加真實的建模。這個模型現在變成了一個代碼視圖，開發者圖形化操作程序結構像操作類和方法定義一樣。這個工具體現了在代碼中難以看到的關系和依賴，節省了為程序結構生成代碼的時間和努力。它使得實現了像基于關系收集的編程風格，或者提供高級的特性像重現和模式構造、應用和評估。

圖5 編程語言建模

當然，通過限制在可用的平臺上進行抽象，這減弱了建模的作用，或者作用不大像編程風格。 那我們如何工作在較高的抽象層呢？我們使用了更加抽象的模型，通過框架或者轉換使平臺和模型更緊密，如圖6所示。讓我們逐一看看這些。

圖6 使用高層抽象

•	我們可以用框架去實現模塊中的高層抽象，用這些模塊在框架擴展點去生成小段代碼。相反，模型幫助用戶完成框架通過可視化框架概念和用直覺的方式體現擴展。當開始用微軟的操作系統時，比如構建圖形應用是困難的。隨后，Microsoft Visual Basic通過表單和控制概念使得圖形應用變得更加容易。
•	我們可以創建更低層次的DSL描述語言，代替構架或模型語言。為了領導這種革命性的變革，我們還可以利用兩個以上的DSL描述語言跨越更寬的跨度，用最高層次的DSL語言描述的模型可以通過提煉轉換成可執行的軟，如圖6所示。這說明了編譯器如何工作，如何將高級語言像c#和java轉換成中間代碼像字節或IL，通過JIT編譯成目標平臺的二進制格式。

組成機制

當然，手寫的代碼必須通常和框架代碼結合產生一個完整可執行程序。一些不同的機制可以用來做這些東西。它們之間重要的區別是幫定時間。

圖 7 設計時間的組成

運行時綁定的兩個優點是，通過接口使手寫代碼和框架代碼結合起來，允許通過對象置換來實現動態配置。同時，委派類允許手寫代碼通過再生來進行保護。一個比較小的缺點是運行時間經常是方法調用。在組件編程模型中，一些基于運行時綁定的機制非常流行，如圖8所示。它們在大規模的商業產品中都非常成功。

•	在編譯之前，在同一個工件中的設計時間主要是手寫代碼時間和框架代碼兩者的時間，如圖7所示。這包括為了避免用戶修改框架代碼的編輯經驗的約束（比如，用只讀區域的編輯器）。在其他工具中，用戶在一個特別的窗口中添加手寫代碼。通過異步回調，運行時綁定合并手寫代碼和框架代碼。一種基于代理的運行時綁定機制通過設計模型來描述， 比如、以下從Gamma, et. al.: events (Observer), adapters (Adapter), policy objects (Strategy), factories (Abstract Factory), orchestration (Mediator), wrappers (Decorator), proxies (Proxy), commands (Command)?and?filters (Chain of Responsibility) [GHJV95]. 運行時綁定的兩個優點是，通過接口使手寫代碼和框架代碼結合起來，允許通過對象置換來實現動態配置。同時，委派類允許手寫代碼通過再生來進行保護。一個比較小的缺點是運行時間經常是方法調用。在組件編程模型中，一些基于運行時綁定的機制非常流行，如圖8所示。它們在大規模的商業產品中都非常成功。
•	手寫SUB類。用戶提供手寫代碼在框架里的SUB類中。在框架代碼中的抽象方法定義了顯示覆蓋點。比如，用戶寫了一個框架實體子集，域內通過模板方法模式引用了手寫代碼，和突出函數調用。
•	框架SUB類。用戶在框架代碼的父類中提供了手寫代碼。手寫代碼的一個抽象方法在框架代碼中被重寫。比如，一個框架實體域引入了關于手寫代碼的父類函數調用，和突出函數調用。
•	手寫委托類。用戶在委托類中提補充寫代碼。比如，一個框架實體在制定處調用一個手寫實體，在設置屬性值的之前或之后。其實是一種代理服務器模式。
•	框架委托類。用戶補充手寫代碼去獲得框架服務。比如，一個手寫代碼實體調用框架實體去設置或者得到屬性值。 圖8 運行時構成
•	在編譯期間綁定合并手寫代碼和框架代碼，如圖 9所示。在編譯期間利用部分規格和編譯時合并是一種很好的方式。在Visual Studio 2005中的Visual Basic和C#語言就是編譯期間構成。 圖 9 編譯時構成

組裝開發

平臺無關協議領域的重要革新有，自描述，變量的封裝，通過流程的組裝和構架驅動的開發。

平臺無關協議

Web服務技術成功了，早期的組件組裝技術從實現技術中分離出用于特定和組裝的組件卻失敗了。由于XML是一種管理信息的技術，不是一種構建組件的技術，Web服務利用封裝去映射Web方法調用到本地方法調用，基于下面的組件實現技術。雖然CORBA試圖用一種相似的策略，它的復雜性需要平臺供應商的大量投資，為此也限制了它的使用范圍�；�于XML的簡單協議明顯降低了實現困難，確保它們的普遍性。通過編碼遠程方法調用請求像XML，它們避免了由平臺特殊遠程調用編碼和參數集結所引起的協同工作問題。同時，通過獲得廣泛的工業標準認可，它們從一開始就設計了平臺的協同工作能力。

自描述

通過改進組件包裝來使推斷，依賴，行為，資源消耗，性能和證明明顯，自描述減少了構架不匹配的情況。它提供的元數據可以用來自動進行組件發現，選擇，許可，獲得，安裝，調整，組裝，測試，配置，部署，控制和管理。

自描述最重要的表格是用來描述組件推斷，依賴和行為，因此開發者可以推出組件之間的交互，工具才能夠驗證組裝。在面向對象中用途對廣泛的規格表是類和接口聲明。它們定義了類提供的行為，但是通過在方法簽名中命名其他類和接口，僅僅說明了重要的推斷和依賴。合約是一種豐富的規格說明。一個合約管理著組件之間的交互。它不知道何時去調用一個組件。一個合約描述了交互順序，和響應協議非法和其他不可預知的條件。

當然，合約除非是強迫的否則也沒有什么用。這有兩種方法強制合約。

•	不用不匹配的合約來組裝組件
•	用合約提供的信息去提供適配器，這種適配器使的組件之間直接交互，或者協調它們之間的交互。

Garlan建議使用標準適配技術菜譜和提供封裝與數據轉換的工具[Gar96]。一種最有希望的適配策略是發布部分組件，這些組件能夠在組裝期間通過封裝各個方面來完成，這些方面提供了組裝需要的代碼。這種策略，稱之為變量封裝，描述如下。

關于自描述的另外一個重要方面是證明。假如組件能夠證明僅僅有指定的依賴，消耗了指定的資源，在一定的條件下具有特定的功能特性，或者有一些公開的弱點，那么它能夠推斷由這些組件組裝成的軟件所具有的功能特性和操作特性。這已經在卡內基梅隆大學軟件工程學院里進行研究，它被認為是可保證組件的可預見組裝(PACC)。

變量封裝

我們已經看到，靜態封裝減少了這種可能性--一個的組件通過靜態綁定其功能方面或者沒有功能或上下關聯的內在方面能夠用于特定裝配。變量封裝減少了構架之間的不匹配通過發布部分封裝的組件，這些組件通過利用其功能性方面來選擇和編制適當的非功能性方面，使得能夠適應新的上下文關系，如圖10所示。在特定組裝中的組件形式能夠通過它位置上的上下文來決定。通過使得組件邊界更有彈性，和減少構架之間的不匹配可以改進靈活性。通過移除非功能性假設，能夠允許功能性部分在組件邊界上進行重制。有效的調整可以預先標識，在一些例子中甚至可以通過工具來自動完成。

圖10 變量封裝

變量封裝是面向切面編程的改寫(AOP)。AOP是系統的不同方面各自進行先分離后組合的方法[KLM97]。變量封裝在三個方面和AOP不同。

•	變量封裝編入了封裝的方面，然而AOP，作為普通的實踐，編入了非封裝的代碼行。編入非封裝方面，當組裝不好的組件包時產生了同樣的問題，叫做構架不匹配和不可預見。的確，基于方面編入源代碼更傾向于這些問題而不是組件組裝，因為組件至少有描述行為和一些防止無依賴的包裝。AOP缺乏包裝使得開發者難于推斷個方面的兼容性和編入的功能特性，或者執行結果特性，幾乎使得利用工具檢查方面編入都不可能。
•	在組件開發期間AOP編入方面，但是變量封裝編入卻比他們晚，比如在組件組裝或者配置期間。這非常重要，因為組件可能置入的上下文直到組件 發布時才知道。事實上，為了支持組裝開發，如文章所述，第三部分必須能夠預知組裝和部署無依賴的開發組件。這需要一種正式的方式去分割方面，封裝方面，說明方面和包裝方面。變量封裝也可以是累進的，它可以在不同的階段發生。比如，我們可以綁定一些方面在組裝期間，一些方面在開發期間，一些方面在運行期間。
•	變量封裝是構架驅動的，然而AOP卻不是。這些從功能內核分離出來的方面必須通過接口、抽象類、WSDL文件或其他形式的合約來明顯定義。

流程管理組裝

如果有充足的合約機制，服務可以通過流程管理引擎，比如Microsoft BizTalk Server，去管理它們之間交流的信息順序，如圖11所示。流程管理組裝使得組裝開發更加容易，因為服務之間的依賴遠比二進制組件少。不像類，它們沒有必要駐留在同一個執行中。不像組件，需要平臺特定的協議，它們能夠通過平臺邊界來組裝。如果它們之間的合約是兼容的，兩種服務之間可以相互作用。它們可以分別開發和部署，然后通過流程管理來進行組裝。假如適當的攔截重道服務可用，它們甚至能夠駐留在不同的管理和組織區域。換句話說，流程管理組裝消除了不同組件之間的設計、編譯、部署時間依賴。

圖 11 流程管理組裝

流程管理組裝實質上是一種仲裁，像Gamma的仲裁模式描述的那樣。一個仲裁管理組件之間的交互流程。一個仲裁有強大的屬性。其中一個功能是過濾或者翻譯組件交互時的信息。另外一個功能是控制交互，如有必要可以通過多路調用來維持狀態。這允許仲裁去推斷交互，如有必要可以通過條件邏輯改變它們。仲裁同時能夠執行一些有用的功能，比如日志，加強安全策略，不同技術或者同一種技術的不同版本之間的聯系。一個仲裁同樣能夠成為組裝的功能部分，加強商業規則或者執行商業功能，比如達成商業交易。

架構驅動的開發

當防止組裝不匹配組件好過于構建非法的組裝時，那么就沒有必要提升匹配好的組件的可用性。這就是架構的目標。依照Shaw 和 Garlan，一個軟件構架描述了組件的組裝，它們之間的交互和可接受的構成模式，減少了良好設計的構架不匹配和約束設計決定的風險。

當然，開發軟件架構是具有挑戰性的。這使得很多架構師花費了許多年才能夠精通有限的構架風格或者應用領域。如果沒有在架構實踐方面明顯的進步和軟件構架方面更多的信任，組裝開發不能夠在工業規模上實現。

這些是架構驅動的軟件開發（ADD）的目標，包括：

•	用于描述、復述和使用架構的標準。
•	用于預知設計決定效用的方法。
•	模式或者架構風格，它用來整理設計專家意見，幫助設計者開發組件分割再現模式。

一個架構風格是一個粗糙的模型，它給抽象框架提供了一組家族系統。它定義了一套指定不同種類組件的規則，這些組件能夠用來組裝一個系統，不同種類組件的關系可以用在組裝中、組裝時的約束中和組裝的設想中。比如，一個Web服務成分風格可用來指定組件提供端口。這些成分是Web服務定義好的，通過連接端口來建立聯系，只有兩個端口兼容才可以連接，通過HTTP用SOAP來進行通信。其他的架構風格包括：數據流、分層和MVC風格。一個架構風格通過提供頻繁出現問題的解決方案，促進了劃分和提高了設計重用，同時也有如下促進。

•	通過標識普通的架構元素來實現再使用，這些構架元素是基于這種風格的、被系統共享的。
•	通過定義標準構架來表示明白。
•	通過定義標準的通信機制來提高協同工作能力。
•	通過定義標準的表示法來提高可視化。
•	通過定義強制的約束來提高工具開發。
•	通過標識基于這種風格的系統突出特性來分析。

一個構架描述就是一個定義了軟件構架的文檔。 IEEE標準 1471，被推薦用來描述密集型軟件構架，提供了描述構架的指導方針[IEEE1471]。根據這些指導方針，一個系統有一個或者更多的股東。一個股東有特殊的關注和關于系統某些方面的利益。為了對股東們有用，一個架構描述必須要求有能使股東們明白的形式和結構。ADS就是一個用來描述一個系統家族架構的模板。一個正式的場景定義了一個視圖，這個視圖可以描述軟件產品的一部分；它也提供了一種模式，這種模式用來進行描述，定義范圍，目標和聽眾，習俗語言和用來開發它的方法。

這些突出的元素用來詳細說明一個場景包括：

•	一個標識符和其他介紹性的信息（比如，作者，日期，參考文件，等等）。
•	與場景的利害關系。
•	習俗、語言和基于場景用來產生視圖的方法。
•	確認視圖的一致性和完成測試。

一個視圖從一個給定的場景描述了一個軟件產品。一個視圖是語義上接近的，意味著它從那個場景描述了一個軟件產品。一個視圖包含一個或者多個工件，每一個都根據場景需求來開發。一個視圖是一個場景的實例，為了更好的成形視圖必須和場景是一致的。一個視圖遵循網頁設計場景，比如，應該描述特殊軟件產品的網頁布局，應該用場景定義好的符號來描述網頁布局。這些突出的元素用來詳細說明一個視圖包括：

•	一個標識符和其他介紹性的信息（比如，作者，日期，參考文件，等等）。
•	視圖遵循的場景標識符。
•	用習俗、語言和場景定義的方法構建的軟件產品描述。

為了明白視圖和它的場景差別，考慮為商業應用程序進行邏輯數據庫設計。邏輯數據庫設計是應用程序的一個視圖，更確切一點，是一個構成組件的視圖。應用程序方面和用來描述它的語言都在邏輯數據庫設計場景中規定好了。許多不同的商業應用程序能夠規定下來，通過用相同的場景，產生了不同的視圖，每個視圖描述了一個為一些商業應用程序的邏輯數據庫。這些視圖能夠描述同樣的方面，用同一種語言，但是它們會有不同的內容，因此每個內容都描述了一個不同的應用程序。一個組裝視圖可以從相同的場景中分解出各個組件的視圖。

根據IEEE1471，一個架構描述必須標識所用的場景和用這些場景的原理。作為特殊目標的ADS，可以通過列舉其所用的一套場景來定義。比如，一個消費者對商業的Web應用程序的ADS可能需要一個對網頁布局的場景和一個對商業數據布局的場景。每一個在架構描述中的視圖，都必須遵循一個由ADS定義的場景。

過程框架

隨著項目規模、地理分布或者時間而復雜度提高時，過程成熟的關鍵是保持靈活性。經驗告訴我們很少有結構通過減少必須的工作量增加了靈活性。這原理能夠在軟件產品家族中應用，通過運用過程框架去管理復雜的產品同時不減少靈活性。

正式過程的一些困難是它們太抽象了。它們提供的指導對于老程序員是明顯的，但是對于初學者就不怎么具體充分了。為了增加使用價值，它必須降低目前項目的細節，因為每一個項目在許多方面都是獨特的，我們不可能產生一種能滿足所有項目的過程。我們知道如何解決此類問題，我們可以為一個特殊產品家族定制和裁剪出一個正式的過程。如果沒有專業供應商，以上的東西是不能在市場上成功的。一些供應商為了給特殊用戶定制過程，通常從其他過程如XP添加一些有用的東西。其他的，尤其是系統集成者和ISVs，裁剪過程以適應特殊的產品或者咨詢性的實踐。每一個方式，高效使用任何過程的關鍵是使其對于一個給定的項目高度特殊化，以便它僅僅包含直接可用的資源。由這種定制產生的改變是非常復雜的，產生了和原來過程很少相似的結果。

一個高度集中的過程包括詳細的項目信息，如工具配置、網絡共享路徑、開發者根據指導來工作、API文檔、 關鍵過程的重要聯系人物的名字像CM，缺陷跟蹤和處理，關于check-in的小組策略，編程風格和同等檢查，還有其他的關于項目和項目小組的細節特征。和其他形式的系統重用一起，僅當我們能夠不止一次用它，這種定制才會有用。同樣，重用高集中的過程資源通過消除工作增加了其靈活性，就如同其他的重用資源一樣。如同Jacobson常說的，構建東西最快的方式是重用一些已經存在的東西，尤其可重用的資源能夠定制和擴展。很多東西都可以系統地重用，開發過程也一樣。

一個過程框架分解成一些更小的過程，這些過程附上了ADS的場景。每一個小的過程描述了產生視圖的需求。它能夠列舉出關鍵的決策點，標識了每個決策點的轉換聯系，描述了必須和可選的活動，描述了每個活動所需的資源和產生的產品。每個工件處理之前都有一些約束，和一些后置條件，工件穩定時所需的不變環境。比如，我們需要在循環開始之前得到循環條件，在退出時得到結束條件。我們需要所有的代碼都構建和測試正確。我們稱這種架構為過程框架，因為它定義了可能合并過程的空間，依賴于給定項目的需求和環境，而沒有必要為所有的項目都描述一個過程。當一個過程框架定義好了，小的過程能夠組合成項目所需的任一工作流，包括自頂而下，自下而上，由里到外，測試編碼和編碼測試，任何組合或者混合流。

這些工作流可以由資源來驅動，允許通過PERT和CPM來進行優化，當資源可用時啟動工作流。許多種類資源可以驅動計劃，包括需求和源代碼，開發人員和程序管理人員，配置管理產品或者缺陷跟蹤系統，像在服務器上打開一個端口或者分配存儲器的設備。這稱為基于約束的計劃�；�于約束的計劃利用少量的架構需求，平衡了靈活性的需求�；�于約束的計劃提供了指導，在開發工件上添加了約束，而不是規定過程。靈活性的產生，可以通過一個工作流在約束中動態產生來得到，適應大量環境變量，同時總結學習經驗，減少知識再發現的費用和時間。

一個過程框架沒有必要太大或者過細，可能包含或多或少的需要的細節。這提供了一種衡量過程大小的方式，依賴于環境。比如，一個小而靈活的小組可以使用小的框架，這種框架僅提供了一些主要的關鍵實踐，如XP。一個大的組織，可以添加許多構建過程的細節，檢查過程，測試過程或者組件共享規則。

總結

本文主要講述了阻礙軟件從技術到生產必然轉變的長期問題，和能夠克服這些問題的重要新方法。雖然每一個重要的新方法都有重要的前景，但是沒有一個能夠獨自促進這種轉變。關鍵的是集成這些重要的新方法到一個綜合方法上。這是軟件工廠的目標。在本文中，許多問題都討論的很簡單，可能使得讀者沒有明白或者需要更多的討論。在《軟件工廠：用模式、模型、框架和工具組裝應用程序》由 Jack Greenfield 、 Keith Short, 、John Wiley 、 Sons編寫的一書中，關于軟件工廠有詳細的討論。

文章來源于領測軟件測試網 http://www.kjueaiud.com/