第一章

 

就在同一時期，其餘的相關研究也正逐漸起步。這些研究的目的是試圖從那些非正式、

 

不標準的經驗知識中，提煉和組織出構造軟件架構可利用的、類似的問題解決手段和設計

 

風格。這樣，研究的成果就能夠被不一樣的領域、在解決類似的問題時所重用。這些研究都

 

是針對當時一些著名系統進行分析和總結的，試圖識別出那些通用的系統架構風格和設計

 

手法。其中，由Gregory Andrews領導的研究小組，分析和識別了不少不一樣類型系統的架

 

構形式；由Robert Allen和David Garlan領導的研究小組，嘗試找到和應用一些通用的方

 

法來描述不隨型的系統結構。他們的不懈努力最終奠基了後人前進的基石。1992年之後，

 

後人在他們研究成果的基礎上，完善和創建了一些著名的系統架構風格，例如：pipe-filter

 

架構風格、repository架構風格、隱式調用、流程協同等。他們的研究成果和基礎思想，直 到今天還被不少文章引用。

 

架構基本概念和模型的確立它是以五個方面的長足進展爲標誌的：架構推述語言的發展、 初步的架構表述及分析規則的制定、架構元素及架構風格的分類研究、架構的評估方法（例 如SAAM)、可借鑑的架構視角（例如4+1視角）。處於這個階段的人們下意識地把主要

 

的精力放在了全部軟件系統結構中可能具備的共性方面。但願經過總結性的研究，發現那 些在實踐中反覆出現的、具備共性的結構；而且可以把這些發現以比較嚴格的邏輯和規則 統一描述出來，以方便業界同行的交流、改進和重用。

 

Redwine/Riddle模型代表，在概念確立階段還須要不斷地提煉和完善所研究問題的結 構。架構評估技術和方法就是在這個時期應運而生的。早期的架構設計人員經過本身終年 的實踐經驗意識到：要設計一個架構，並檢驗該架構的有效性，通常是先明確該系統在質 量方面的要求（即要解決的問題)，而後從衆多候選問題的解決方法中選用最適當的方法， 這樣的過程就是後來架構領域常常提到的一個用語一 「設計決策」。只有系統在質量方面 的要求與設計決策徹底對應起來，才能確保該系統架構是有效的。因此該時期出現的一些 經常使用方法有：Richard W. Selby與Ronald Reimer提出的衡量大型軟件系統內各個部件互 聯關係的標準；AT&T公司提供給架構師的檢查列表；C.Smith提出的基於系統的不一樣屬性 要求（例如性能要求）而能夠採用的架構分析評估方法等。綜合上面這些經驗，R.Kazman 等人在1994年彙總造成了更爲通用的架構評估方法SAAM (Software Architecture Analysis Method)。

 

概念確立階段的最後的一個重要實踐總結，是爲後人發揚光大的「架構視角 (Architecture View)」 概念。其實，早在 1974 年，D. L. Pamas 在《On a 「buzzword」: hierarchical structure》一文中就已經爲架構視角的研究開創了先河。他在對衆多軟件系統 進行研究後提出了本身的成果：不一樣的軟件系統運用不一樣形式的結構來構建和表述，是因 爲不一樣的構建形式可以知足不一樣的工程需求和目標。以後，架構視角的研究自己也經歷了 本身完整的Redwine/Riddle週期。期間出現了衆多高質童的研究結果，當中最著名的是 P.Kruchten在1995年提出的「4+1」視角，他爲之後的架構實踐莫定了堅實的基礎。當 今設計領域常常應用的那些UML視圖，就是一個很典型的例子。

1992年至1996年期間，國際上開始組織衆多國際會議（例如軟件設計國際大會）， 明顯地完成了 Redwine/Riddle模型中概念確立階段的職能：溝通基本思想和概念並造成統

 

技術徹底穩定下來，這爲1998年後架構技術的大規模工程應用奠基了基礎。Len Bass、 Paul Clements、C.Hofmeister及R.Nord等人都紛紛在這個階段把架構的理論投入到實踐 中。他們面對不一樣類型的真實系統，嚴格應用和校驗了架構前期發展的結果。後來發表的 —些研究結果，表明了他們爲架構領域成熟作出的重要貢獻。同時，前期總結提煉出的種 種系統架構風格(Architectural Style)也演化成了真正意義上的系統架構模式(Architectural Pattern)。架構模式與設計模式（Design Pattern)結合在一塊兒，實現了系統設計上比較嚴 格的高低層次搭配。

 

同期，軟件架構領域內的系統及架構分析與評估也逐漸走向了完善。例如：Robert Allen 與David Garlan的研究，大量地集中在針對一些真實系統的架構設計所進行的正式而全面 的分析，從而試圖識別出系統髙層架構、設計方面與功能、質量要求不一致的方面，從而 避免了系統實施階段的大量設計修改。SEI的R. Kazman在1994年最先提出的架構評估 方法SAAM,通過5年的實踐檢驗，在不一樣領域、不一樣系統中獲得了錘鍊（例如SAAM方 法曾經在美國國家航天局的一些軟件項目中獲得了寶貴的實踐經驗)，並最終在1999年成功演化爲業界備受推崇的軟件架構分析及評估方法ATAM (Architecture Tradeoff Analysis Method)。最終，P.CIements 在 2001 年提交的研究結果，與 P. Clemente 和 R. Kazman 在2002年發表的論著，成爲這個時期系統及架構分析與評估方面成熟的標誌和里程碑。 這兩個重要的研究成果,是基於當時p. Clements和R. Kazman分別選定的一些業務領域， 針對該業務領域內的一些生產運行系統或正在開發的新系統進行的分析評估，從而總結出 的架構評估實戰經驗，爲後人提供了可貴的架構設計與分析指導。

 

在1996年至2003年這個軟件架構技術從理論走向實踐的重要階段，爲了使工業界的 系統架構與設計活動可以徹底符合系統質量所要求的屬性，研究人員付出了巨大的努力， 並逐漸在實際應用過程當中總結了一些比較全面的經驗。Mario R.Barbacci在1996年就己經 認識到了分析和評估系統質量的需求對所設計系統的重要性；他力圖經過系統化的方法分 析出質量的要求，而且以此爲依據對構建的軟件架構進行評測，從而可以科學、系統地使 所進行的架構設計知足質量上的要求（例如系統性能上的需求、可修改性的需求等）。出於近乎類似的目的，Felix Bachmann通過幾年的探索和實踐，在2003年發表的研究結果中 提出了一系列架構模式。這些模式都是一些有助於實現系統質量的要求而可採用的典型的 戰術性手段，即後來所謂的架構戰術手段（Achitectural Tactics),以便其餘設計人員可以參考他提出的分析和決策模式，方便地從衆多架構設計方法中進行抉擇，使選擇的架構能 夠真正知足質量上所要求的特徵。

 

軟件架構通過1996年至2003年的內部改進和拓展階段，發展到21世紀初的今天， 己經初步具有了系統設計自動化的模型：即有效地分析和評估質量要求、有效地將質量要 求關聯到架構的戰術手段、有效地分析和評測所設計的架構的有效性（是否知足質量上的 要求）。這是一個軟件架構界的夢想，咱們距離夢想成真愈來愈近了。

 

5.外部改進拓展階段（1998年至今）

其中，架構風格這個軟件架構家族成員的暴風式地普及並商業化，就是最好的一個例 證。固然，它得益於2000年之後迅猛激增的World Wide Web和電子商務的商業推進力^ 經歷了 15年的沉澱，架構風格的研究成果如雨後春筍通常出現，它們都成爲市場上搶手的 技術：N層的客戶端/服務器架構風格、基於代理的架構風格、面向服務的架構風格（SOA)

 

在軟件架構技術普及應用階段的另一項重要任務是：使已經產品化的新技術可以逐 步地標準化。在架構技術興起以前，計算機工程界就已經爲構件和接口的重用而進行了標 準化工做（例如COM、CORBA、XML等h可是這些特殊構件級的標準化，還不能算是 架構技術的標準化。2000年，ANSI與舊EE總結規範了先前的最佳實踐，聯合推出了 「大 型複雜軟件系統的架構描述」標準，試圖推進架構技術在應用領域的規範化和重用能力。 同時其餘一些標準也相繼出現，其中2005年由SAE (Society of Automotive Engineers) 推出了 AADL(Architecture Analysis & Design Language)這種所謂的「純架構描述語言」, 做爲架構領域的標準。

 

從2000年至今這個架構技術大規模普及的階段，同時出現了一些頗有趣的現象。很 多人根據本身的經驗和概念而冠名了許多新的術語。比爾•蓋茨就把本身叫作微軟的「首 席軟件架構師」（固然，他在微軟能夠隨便給本身任何頭銜)。OMG組織把本身推出的架構 設計與系統開發的理念冠名爲「以模型爲驅動的軟件架構」-MDA (Model Driven Architecture),它其實就是把商業和應用邏輯的分析和建模，與實現這些邏輯的具體平臺 技術割裂開，最終造成必定程度上的模型與實現技術的自動轉化。SEI這個著名的學術機 構，發起了一場有趣的活動：爲「軟件架構」這個詞進行定義。截止到2005年，共有來 自24個國家的架構從業人員提交了 156個定義，可見公衆對架構技術的熱情和參與度。 固然，普及和熱情也致使了這樣的現象出現：一些人根據我的的理解、經驗和興趣發明了 形形色色每誕的術語了爾如「程序架構師」（Program Architect)，真是讓人匪夷所思。

 

若是放眼這個時期的學術界，一樣出現了很大的改觀。先前的大學裏，通常只可能在

 

很明顯，從上述這些問題中，咱們彷佛看到了一個架構從生成、進化、老化到消亡的 過程的影子，如同宇宙萬物，架構彷佛也存在一個生命週期的概念。筆者借鑑了經典的「倒 浴缸（Revise-BathtubCurve)」模型，在探索架構發展和演化的規律基礎上，正式提出了 「架構生命週期（Arch丨tecture Lifecycle)」這個重要概念！

 

把握共同的規律、預知將來的發展、選擇最佳的路徑，儘量減小成長的煩惱，儘可 能保持成熟的穩定，讓軟件研發企業充分享受到屬於架構整個生命階段的華彩，正是研究 架構生命週期的目的之所在！

 

爲便於分析’咱們將架構生命週期劃分爲以下5個階段：架構初步構建階段、架構逐 步優化階段、架構成熟階段、架構老化階段以及架構消亡階段，如圖1-10所示。

圖1-10中須要特別指出的是，在單一產品架構發展的過程當中，架構可能會進化到更高 境界的一個層次，那就是產品線架構。隨着單一產品架構的消亡，產品線架構橫空出世， 生命即將在更高層次演奏出更加華美的樂章。

 

完整的架構生命週期（Architecture Lifecycle),這將是本書的核心思想’也將成爲下 述各個章節討論的主線。本書第4章「軟件架構與設計流程」其實就是在談架構初步構建階段的核心要點；本書第5章「軟件架構及軟件質量」、第6章「軟件架構的評審」所涉及 的內容都是在談架構逐步優化階段的各項任務及最佳實踐；本書第7章「軟件架構的恢復 與重構」主要探討架構老化階段以及架構消亡階段所發生的各類可能狀況。本書第8章「軟 件產品線架構」則會升華到架構的另外一個生命週期——產品線架構！