架構師書庫 點選檢視第二章 點選檢視第三章 軟體架構理論與實踐
第1章 軟體架構概述
最初，軟體架構（Software Architecture，又稱軟體體系結構）是用來刻畫軟體系統整體抽象結構的一種手段，軟體架構設計是軟體開發過程中的一個重要環節，但随着研究的深入和應用的推廣，軟體架構逐漸成為軟體工程學科的重要分支方向，在基礎理論、技術方法和工程實踐等方面形成了自己獨特的理念和完整的體系。作為軟體架構的背景知識，本章簡要介紹軟體架構産生的背景、主要思想、特征和發展軌迹。
1.1 軟體架構産生的背景
衆所周知，20世紀60年代中期開始爆發大規模的軟體危機，軟體危機的突出表現就是軟體生産不僅效率低，而且品質差。究其原因，主要是因為軟體開發的理論方法不夠系統、技術手段相對滞後，主要的軟體生産都是手工作坊式的。為了解決軟體危機，北大西洋公約組織（NATO）分别于1968年和1969年連續召開兩次著名的軟體會議，後人稱之為NATO會議。NATO會議提出了軟體工程的概念，發展了軟體工程的理論和方法，形成了軟體工程專業的教育、培養和訓練體系，為軟體産業的發展指明了方向。
但是随着軟體規模的進一步擴大和軟體複雜性的不斷提高，新一輪的軟體危機再次出現。1995年，Standish Group研究機構以美國境内8000個軟體工程項目作為調查樣本進行調查，其結果顯示，有84％的軟體項目無法按時按需完成，超過30％的項目夭折，工程項目耗費平均超出預算189％。軟體工程遇到了前所未有的困難[1]。
通過避免軟體開發中重複勞動的方式提升軟體開發效率、保障軟體品質，軟體重用與元件化成為解決此次危機的行之有效的方案。随着元件化軟體開發方式的發展，如何在設計階段對軟體系統進行抽象，擷取系統藍圖以支援系統開發中的決策成為迫切而現實的問題。分析問題的根源和産生的原因，以下現象應該獲得關注：
1）軟體複雜、易變，其行為特性難以預見，軟體開發過程中需求和設計之間缺乏有效的轉換，導緻軟體開發過程困難和不可控。
2）随着軟體系統規模越來越大、越來越複雜，整個系統的結構和規格說明顯得越來越重要。
3）對于大規模的複雜軟體系統，相較于對計算算法和資料結構的選擇，總體的系統結構設計和規格說明已經變得明顯重要得多。
4）對軟體系統結構的深入研究将會成為提高軟體生産率和解決軟體維護問題的最有希望的新途徑。
在這種情況下，軟體架構應運而生。
20世紀90年代，研究人員展開了關于軟體架構的基礎研究，主要集中于架構風格（模式）、架構描述語言、架構文檔和形式化方法。衆多研究機構在促進軟體架構成為一門學科的過程中發揮了舉足輕重的作用。例如，卡内基–梅隆大學的Mary Shaw和David Garlan的專著推廣了軟體架構的概念，即元件、連接配接件和風格的集合。加州大學歐文分校針對架構風格、架構描述語言和動态架構也開展了深入的研究。
軟體架構在高層次上對軟體進行描述，便于軟體開發過程中各個視角（如使用者、業務和系統）的統一，能夠及早發現開發中的問題并支援各種解決方案的評估和預測[2]。
軟體架構的意義貫穿軟體生命周期的各個階段：需求分析階段需要使用軟體架構的理念對規約進行完善，繼而支援由需求模型向架構模型的轉化；通過驗證的架構設計借助形式化或多角度具象描述，成為進一步細化設計的基礎；在程式的開發和維護階段，架構能夠幫助開發和維護人員了解軟體、盡早地發現和修複問題。是以良好的架構是軟體得以順利實作過程中至關重要的因素。
1.2 軟體架構的主要思想和特征
1.2.1 軟體架構的主要思想
軟體架構是一個軟體系統的設計圖，并不僅限于軟體系統的總體結構，還包含一些品質屬性以及功能與結構之間的映射關系，即設計決策[3]。軟體架構的兩個主要焦點是系統的總體結構以及需求和實作之間的對應。軟體架構的主要思想是将注意力集中在系統總體結構的組織上，實作的手段是運用抽象方法來屏蔽錯綜複雜的子產品間連接配接，使人們的認知提升并保持在整體結構的元件互動層次，并進一步将互動從計算中分離出來，建立“元件+連接配接件+配置”的軟體系統高層結構組織方式。
1.2.2 軟體架構的特征
（1）注重可重用性
重用是軟體開發中避免重複勞動的解決方案，其出發點是應用系統的開發不再采用一切“從零開始”的模式，而是充分利用已有系統開發中積累的知識和經驗[4]。通過重用不僅可以提高軟體開發效率，而且因為可以避免重新開發引入新的錯誤，進而可提高目前軟體的品質。軟體架構中的元件就是重用思想的重要展現，此外有關軟體架構風格的研究還提供了架構級别的重用。
（2）利益相關者較多
軟體系統通常有多個利益相關者，每個利益相關者都會因為利益關系而對系統有一定的需求，軟體系統需要滿足每個利益相關者的需求[3]。架構設計工作就是要平衡這些需求并将它們反映到系統中。
（3）關注點分離
關注點分離是計算科學和軟體工程在長期實踐中确立的一項方法論原則[5]，此原則在業界更多的時候以“分而治之”（divide-and-conquer）的形式出現，即将整體看成為部分的組合體并對各部分分别加以處理[6]。子產品化（modularization）是其中最有代表性的具體設計原則之一。軟體架構的關注點就是指在軟體架構設計中對利益相關者的利益來說比較關鍵或重要的方面。已有的架構方法采用分離關注點的辦法來簡化複雜性，以此來驅動設計，這種分離被稱作“架構視角”。
（4）品質驅動
軟體系統的設計已經從傳統的功能性需求及資料流驅動逐漸向品質驅動轉變，利益相關者的關注點往往展現在品質屬性的需求上，如可靠性、可擴充性需求等[3]。品質屬性需求是影響軟體系統複雜度的關鍵因素，軟體架構是處理品質屬性需求和控制複雜性的主要手段，品質屬性是軟體架構中最為重要的關注點。
（5）提倡概念完整性
軟體架構的設計決策是一個持續的過程，每個決策都要在其前面設計決策的基礎上進行，既要符合前面設計決策所規定的設計規則和限制，又要解決本身的特定問題和關注點[3]。是以，每個設計決策的上下文環境、規則、限制都是不同的。但是有一個至高的設計規則是所有的設計決策都必須遵守的，即概念完整性。Frederick Brooks首先在軟體系統設計中明确提出了概念完整性規則：“我認為概念完整性是系統設計中最重要的考慮因素。一個為了反映一組設計思想而省略不規則特性及改進的系統，要好過一個包含很多雖然好但獨立、不協調的設計思想的系統。”[7]簡單地說，概念完整性是要求用相似的方法做相似的事情。
（6）循環風格
與建築架構類似，軟體架構也提出了标準的方法來處理反複出現的問題。這些方法的命名被看作不同層次的抽象，常見的如架構風格、架構政策、參考結構、架構模式等[3]。
1.3 軟體架構的發展階段
軟體架構自概念誕生之初便得到了廣泛關注，至今已經曆了一系列發展階段。整體上來看，軟體架構的發展可以分為如下幾個階段。
1.3.1 基礎研究階段（1968—1994）
術語“軟體架構”在1968年的北大西洋公約組織會議上第一次出現，但并沒有得到明确定義。直到20世紀80年代，“架構”一詞在大部分情況下被用于表示計算機系統的實體結構，偶爾被用于表示計算機指令集的特定體系。從20世紀80年代起，為應對大型軟體開發中存在的危機，對軟體結構進行描述的方法開始在大型軟體開發過程中廣泛使用，并在實踐中積累了大量經驗，經研究者總結歸納，逐漸形成了以描述軟體高層次結構為目的的理論體系，實質上形成了軟體架構研究領域的雛形。在這一階段，随着軟體規模增大，開發者已經開始嘗試子產品化的實踐，為後續軟體架構理論的發展奠定了基礎。
具體來說，子產品化指的是一種軟體開發方法，即把一個待開發的軟體分解成若幹小的簡單的部分，稱為子產品。每一個子產品都獨立地開發、測試，最後再組裝出整個軟體。這種開發方法是對待複雜事物的“分而治之”的一般原則在軟體開發領域的具體展現。
在軟體中，子產品是執行一個特殊任務或實作一個特殊的抽象資料類型的一組例程和資料結構，通常由接口和實作兩部分組成。接口使得子產品内部的具體實作被隐藏，使得能夠面向接口開發而不是面向具體應用開發，展現了良好的封裝性，易于獨立的開發、修改和測試。
子產品化開發方法涉及的主要問題是子產品設計的規則，即系統如何分解成子產品。在把系統分解成子產品時，應該遵循以下規則：①最高子產品内聚。也就是在一個子產品内部的元素最大限度地關聯。隻實作一種功能的子產品是最高内聚的，具有三種以上功能的子產品則是低内聚的。②最低耦合。也就是不同子產品之間的關系盡可能弱，以利于軟體的更新和擴充。
③子產品大小适度。粒度過大會造成子產品内部維護困難，而粒度過小又會導緻子產品間的耦合增加。④子產品調用鍊的深度（嵌套層次）不可過多。⑤接口幹淨，資訊隐蔽。⑥盡可能地複用已有子產品。
一般來說，子產品的粒度小于服務元件的粒度。服務元件可以在應用之間複用。由于服務的調用通常是基于分布式協定（比如SOAP、HTTP、RMI/IIOP）的，且通常是遠端調用，是以出于分布式請求性能的考慮一般粒度比較大。而當隻想複用服務中特定的行為時，複制代碼或者暴露新的服務接口都不是很好的選擇，這時基于子產品則可以得到一種更為優雅的解決方案。由于子產品比服務粒度更小，而且又是一種部署單元，是以可以将這種特定的行為實作為子產品，這樣不僅支援複用，同時為組裝應用帶來了更大的靈活性。
随着全球化的發展趨勢和全球化市場競争壓力的增加，一方面企業需要提高業務靈活性和創新能力；另一方面随着IT環境複雜度和曆史遺留系統的增加，企業面臨新的挑戰。子產品化的思想恰恰能夠幫助企業從根本上解決這一問題，它一方面通過抽象、封裝、分解、階層化等基本的科學方法，對各種軟體元件和軟體應用進行打包，提高對企業現有資産的重用水準和能力；另一方面，基于子產品化思想，業界提出了面向服務架構（Service-Oriented Architecture，SOA）思想，它提供一組基于标準的方法和技術，通過有效整合和重用現有應用系統和各種資源實作服務元件化，并基于服務元件實作各種新業務應用的快速組裝，幫助企業更好地應對業務的靈活性要求。它通過有效平衡業務的靈活性和IT的複雜度，為開發者提供了新的視角，有效拉近了IT和業務的距離。
1.3.2 概念體系和核心技術形成階段（1991—2000）
基于工程實踐經驗，研究者對軟體開發中所采用的結構描述方法進行了反思，軟體架構概念作為一個獨立的研究領域出現是在20世紀90年代，Winston W. Royce 與 Walker Royce 在1991年的一篇文章中首次對軟體架構進行了定義[8]。1992年D.E.Perry與A.L.Wolf對軟體架構進行了闡述，創造性地提出了著名的“{elements, forms, rationale} = software architecture”公式[9]，使之成為後續軟體架構概念發展的基礎。與此同時，大量關于軟體架構的研究陸續展開并卓有成效，其中最著名的是卡内基–梅隆大學軟體工程研究所（CMU/SEI）進行的研究。1996年CMU/SEI的Mary Shaw和David Garlan出版了《Software Architecture: Perspectives on an Emerging Discipline》[10]，其對軟體架構概念的内涵與外延進行了詳盡闡述，這對軟體架構概念的形成起到了至關重要的作用。
從1995年起，軟體架構研究領域開始進入快速發展階段，來自于工業界與學術界的研究成果大量出現。在這一階段中，研究關注點主要集中于對前一階段研究成果進行整合與完善，使得軟體架構作為一個技術領域日漸成熟。在此階段中，對軟體架構概念的探讨越加深入，Booch、Rumbaugh和Jacobson從另一個角度對軟體架構的概念進行了全新的诠
釋[11]，認為架構是一系列重要決策的集合。此階段還提出了第一個由軟體工程研究機構提出的軟體架構實踐方法體系—SAAM[12]；企業界也提出并完善了多視角軟體架構表示方法以及針對軟體架構的特定設計模式[13–14]。Siemens、Nokia、Philips、Nortel、Lockheed Martin、IBM，以及其他一些大型軟體開發組織開始關注軟體架構，并聯手進行了軟體産品線架構的重用性調查。Rechtin 與 Mark Maier在1998年出版的《The Art of Systems Architecting》一書中很好地闡述了系統與軟體的關系[15]。
2000年，IEEE 1471—2000的“軟體密集型系統架構描述的推薦實踐”釋出[16]，第一次定義了軟體架構的形式化标準。這标志着軟體架構理論體系已基本建立，并已具備普及應用的基礎。
這一階段最重要的成果之一就是軟體元件化技術，通過沿用20世紀的工業元件概念，提升了軟體重用能力和品質。
軟體技術發展在幾十年裡經曆了面向機器、面向過程、面向對象、面向元件的發展曆程，每個階段較于前一個階段在關注點和思維層次上都有一定的升華，并解決了某類問題，對當時的軟體發展起到了重要作用。
首先，業務元件之間相對獨立，并且具有可組裝性和可插拔性。每個元件的運作僅依賴于平台或者容器，元件與元件之間不存在直接的耦合關系。同時，元件與元件之間又并非絕對的獨立。元件經過組裝後可以與其他元件進行業務上的互動。
元件化開發并不等同于子產品化開發。子產品化開發隻是在邏輯上做了切分，實體上（開發出的系統代碼）通常并沒有真正意義上的隔離。元件化也不等同于應用內建，應用內建是将一些基于不同平台或不同方案的應用軟體和系統有機地內建到一個無縫的、并列的、易于通路的單一系統中，以建立一個統一的綜合應用。元件化應比子產品化更獨立，但比應用內建結合得更加緊密。
1.3.3 理論體系完善與發展階段（1996年至今）
随着基于元件軟體架構理論的建立，與之相關的一些研究方向逐漸成為軟體工程領域的研究熱點，主要包括：軟體架構的描述與表示；軟體架構分析、設計與測試；軟體架構發現、演化與重用；基于軟體架構的開發方法；軟體架構風格等。
1998年，P. Bengtsson和J. Bosch在ICSR（International Conference on Software Reuse）上發表了《Scenario-based Software Architecture Reengineering》[17]，展開軟體架構的“再工程”。P. Oreizy、N. Medvidovic和R. N. Taylor在ICSE會議上發表了《Architecture-based Runtime Software Evolution》[18]，開創了動态軟體架構的研究。
1.3.4 普及應用階段（1999年至今）
在軟體架構發展曆程中1999年是一個關鍵年份，這一年召開了第一屆IFIP軟體架構會議[19]，并成立了IFIP工作組2.10與全球軟體架構師協會，許多企業開始将軟體架構相關理論投入實踐，為了使架構描述能夠在實踐中得到更廣泛的應用，Open Group 提出了ADML[20]，它是一種基于XML的架構描述語言，支援廣泛的架構模型共享。由于企業對重用以及産品族的形成有着更多考慮，是以軟體産品線成為軟體架構的一個重要分支，吸引了大量大型企業的關注。2000年，IEEE 1471—2000的釋出[16]為軟體架構的普及應用制定了标準化規範，為軟體架構的後續發展奠定了基礎，該标準随後分别于2007年與2011年得到擴充與修改。2003年，L. Bass、P. Clements和 R. Kazman出版了《Software Architecture in Practice》一書[21]，引起巨大反響，書中總結了軟體架構研究領域的最新成果，并介紹了如何在實踐中應用這些理論成果。
縱觀軟體架構的發展曆程，其完成了由實踐上升到理論，再由理論回報指導實踐的過程，理論與實踐均處于健康發展中，已經形成良性的發展循環。
1.4 軟體架構研究和應用現狀
目前，軟體架構尚處于迅速發展之中，至今尚無統一的定義，但軟體架構作為軟體工程領域中的一個組成部分，已經取得了長足的發展，成為軟體工程領域的研究熱點，作為一門學科受到越來越多軟體系統設計和研究人員的重視。目前軟體架構的相關研究主要集中在以下兩個方面。
1.4.1 軟體架構理論和方法研究
（1）軟體架構描述與構造表示
ADL是一種規範化架構描述，提供了具體的文法與刻畫架構的概念架構，是支援架構描述和推理的形式化語言。目前已經提出了許多軟體架構描述語言。國外比較典型的有基于元件和消息的軟體架構描述語言C2 SADL[22]，分布、并發類型的架構描述語言Wright[23]，架構互換語言ACME[24]，基于元件和連接配接的架構描述語言UniCon[25]，基于事件的架構描述語言Rapide[26]，以及其他比較有影響力的Darwin、MetaH、Aesop、Weaves、SADL、xADL等架構描述語言[36]。國内提出的ADL有基于架構和角色模型的軟體架構規約FRADL[27]、多智能體系統架構描述語言A-ADL[28]、基于主動連接配接件的架構描述語言Tracer[29]、基于XML的軟體架構描述語言ABC/ADL[30]、功耗-體系結構描述語言XP-ADL[31]、基于層次消息總線的軟體架構描述語言JB/SADL[32]、基于時序邏輯的可視化架構描述語言XYZ/ADL[33–34]、基于高階多型π演算的動态架構語言D-ADL[35]等。
架構表示是指按照一定的描述方法，用架構描述語言對架構進行說明的結果，并将描述架構的過程稱為架構構造。目前常見的架構描述方法包括形式化的架構描述方法、Kruchten的“4+1”架構模型、使用UML的架構描述方法以及IEEE的軟體架構描述規範等[36]。
形式化方法是指在嚴格的數學基礎（邏輯、代數、自動機、圖論等）之上的方法。該方法按所采用的技術可以分為五類：基于模型的方法、代數方法、過程代數方法、基于邏輯的方法以及基于網格的方法。目前被廣泛使用的形式化方法Z規約語言，是一種以狀态機為模型的形式規約語言，可以把架構描述的基本文法元素（元件、連接配接件以及對應的配置）形式化。
Kruchten的“4+1”架構模型從5個不同的視角（包括邏輯視角、過程視角、實體視角、開發視角和場景視角）來描述軟體架構。每一個視角隻關心系統的一個側面，5個視角結合在一起才能夠反映系統軟體架構的全部内容，比較細緻地描述了需求和架構之間的關系[37]。類似的還有Siemens的四視角模型，其由Siemens公司研究所開發，從概念、執行、子產品和代碼架構四個視角分離不同的工程關注點，進而降低架構設計任務的複雜性[38]。
統一模組化語言（Unified Modeling Language，UML）是一種通過可視化方法對系統進行描述、實施和說明的标準語言。UML不屬于ADL，它更關心使用性，更多地适用于應用軟體系統設計，對系統的可建構性模組化能力較弱，不具備ADL可構造的元件–連接配接器架構特征。Medvovonic總結了用UML描述架構的3種途徑：不改變UML用法而直接對架構模組化；利用UML支援的擴充機制擴充UML的元模型以實作對架構模組化概念的支援；對UML進行擴充，增加架構模組化元素[36]。
IEEE于1995年成立了架構工作組（AWG），起草了架構描述架構标準[39]，即IEEE 1471—2000，該标準建立了架構描述的架構，定義了架構描述的内容，并提供了關鍵概念和術語的基本原理、與其他标準之間的關系和用法的例子，用于處理軟體密集系統架構的建立、分析和支援，以及用架構描述術語記錄這些架構。
此外，Rational起草了可重用的軟體資産規格說明，并專門讨論了架構描述的規格說明，提出了一套易于重用的架構描述規範[40]。該規範是基于RUP（Rational United Process）開發的，采用UML模型來描述軟體架構；認為架構描述的關鍵是定義視點、視圖以及各種模組化元素之間的映射關系。
（2）軟體架構分析、設計與測試
架構分析的内容可分為結構分析、功能分析和非功能分析。軟體架構分析的目的是在系統被實際構造之前預測其品質屬性。目前存在的方法有基于場景的架構分析方法SAAM[41]及其3個擴充，其中一個是基于複雜場景的SAAMCS[42]，另兩個是對可重用性擴充的ESAAMI[43]和SAAMER[44]；架構折中分析方法ATAM[45]；基于場景的架構再工程SBAR[46]；架構層次的軟體可維護性預測ALPSM[47]；軟體架構評估模型SAEM[48]等。
軟體架構設計指生成一個滿足使用者需求的軟體架構的過程[49]。主要的設計方法有從工件描述中提取架構描述的工件驅動（artifact-driven）方法、從用例導出架構抽象的用例驅動（use-case-driven）方法、從模式導出架構抽象的模式驅動（pattern-driven）方法、從領域模型導出架構抽象的域驅動（domain-driven）方法，以及從設計過程中獲得架構品質屬性需求的屬性驅動設計（attribute-driven design）方法等。
軟體架構測試着重于仿真系統模型、解決架構層的主要問題。由于測試的抽象層次不同、架構測試政策可以分為單元、子系統、內建、驗收測試等階段的測試政策。在架構內建測試階段提出了多種技術，其中包括Debra等人提出的一組針對架構的測試覆寫準則，如元件覆寫準則等[50]；基于霍爾公理的元件設計正确性驗證技術[51]；基于CHAM（CHemical Abstract Machine）的架構動态語義驗證技術等[52]。
（3）軟體架構發現、演化與複用
軟體架構發現解決如何從已經存在的系統中提取軟體架構的問題，屬于逆向工程。Waters等人提出了一種疊代式架構發現過程，即由不同的人員對系統進行描述，然後對這些描述進行分類并融合，發現并解除沖突，将架構新屬性加入已有的架構模型中，并重複該過程直至架構描述充分[53]。
軟體架構的演化即由于系統需求、技術、環境、分布等因素的變化而最終導緻軟體架構的變動。軟體系統在運作時刻的架構變化稱為架構動态性，而将架構的靜态修改稱為架構擴充。架構擴充與架構動态性都是架構适應性和演化性的研究範疇。Darwin和C2直接支援結構動态性，CHAM、Wright、Rapide支援語義動态性。在C2中定義有專門支援架構修改的描述語言AML，而Darwin對架構的修改則采用相應的腳本語言，CHAM通過多值演算實作系統架構的變換，Wright通過順序通信程序CSP描述元件的互動語義[36]。
軟體架構複用屬于設計重用，比代碼重用更抽象。架構模式就是架構複用的一個研究成果。
（4）基于軟體架構的開發模型
軟體開發模型是跨越整個軟體生存周期的系統開發、運作、維護所實施的全部工作和任務的結構架構，給出了軟體開發活動各階段之間的關系。目前，常見的軟體開發模型大緻可分為三種類型:①以軟體需求完全确定為前提的瀑布模型。②在軟體開發初始階段隻能提供基本需求時采用的漸進式開發模型，如螺旋模型等。③以形式化開發方法為基礎的變換模型。為了更好地支援軟體開發，Bass等人提出了基于架構的軟體開發過程[21]。
（5）軟體架構風格與模式
人們在軟體開發實踐中總結出了許多軟體架構風格。架構風格（架構模式）是針對給定場景中經常出現的問題提供的一般性可重用方案，它反映了領域中衆多系統所共有的結構和語義特性，并指導如何将各個子產品和子系統有效地組織成一個完整的系統。對軟體架構風格的研究和實踐促進了對設計的複用，一些經過實踐證明的解決方案也可以可靠地用于解決新的問題。
David Garlan和Mary Shaw等人總結出若幹被廣泛接受的架構風格，并将其分成五種主要的類型[54]：
1）資料流風格：批處理序列；管道–過濾器。
2）調用/傳回風格：主程式/子程式；面向對象；階層化結構。
3）獨立元件風格：程序通信；事件系統。
4）虛拟機風格：解釋器；基于規則的系統。
5）倉庫風格：資料庫系統；超文本系統；黑闆系統。
之後仍有擴充，如出現了C2風格、GenVoca風格、REST風格等。此外，針對不同的系統類型又提出若幹種架構風格，如分布式系統、互動式系統和适應性系統的架構風格等[55]。
（6）軟體産品線架構
軟體産品線表示着一組具有公共的系統需求集的軟體系統，它們都是根據基本的使用者需求對标準的産品線架構進行定制，将可重用元件與系統獨有的部分內建而得到的[48]。在這種開發生産中，基于同一個軟體架構，可以建立具有不同功能的多個系統。在軟體産品族之間共享架構和一組可重用的元件，可以降低開發和維護成本。由美國國防部支援的兩個典型項目—關于基于特定領域軟體架構的軟體開發方法的研究項目（DSSA）與關于過程驅動、特定領域和基于重用的軟體開發方法的研究項目（STARS），分别從軟體架構和軟體重用兩個方面推動了軟體産品線的研究和發展。
軟體産品線架構的發展是依托着特定領域軟體架構（Domain Specific Software Architecture，DSSA）的研究深入而進行的[43]。盡管業界對 DSSA尚無統一的定義，但各種觀點中DSSA都必須具備以下4個特征：①一個嚴格定義的問題域/解域；②具有普遍性，使其可以用于領域中某個特定應用的開發；③對整個領域的适度抽象；④具備該領域固定的、典型的在開發過程中可複用的元素。目前已有一些較好的DSSA應用，如IBM/Aerospace/ MIT/UCI開發的适用于航空電子領域的軟體架構，北京大學楊芙清院士牽頭實作的支援元件複用的青鳥Ⅲ型系統等[49]。
（7）軟體架構支援工具
在軟體架構支援工具中，支援架構分析的工具包含支援靜态分析的工具、支援類型檢查的工具、支援架構層次依賴分析的工具、支援架構動态特性仿真的工具、支援架構性能仿真的工具等；然而支援架構設計的工具還很不成熟，相關研究成果較少，難以進行實用化比較。著名的軟體架構支援工具包括卡内基–梅隆大學研發的Acme，其以Acme架構語言為基礎，提供了Acme工具開發人員庫（Acmelib），用于表示和操作Acme的設計，并提供了一個具有圖形化使用者界面的軟體架構開發環境AcmeStudio；支援C2架構風格的ArchStudio3、UniCon、Aesop等架構支援環境；支援主動連接配接件的Tracer工具等[49]。
1.4.2 軟體架構的應用研究
（1）軟體架構風格的應用
軟體架構風格是在實踐中被多次應用，綜合若幹設計思想得出的，具有已經被熟知的特性，并且可以實作有效複用，在實際設計和開發中具有指導性作用。不同的架構風格具有各自的優缺點和應用場景。例如管道-過濾器風格适用于将系統分成幾個獨立的處理步驟；主程式/子程式和面向對象的架構風格可用來對元件内部進行設計；虛拟機風格經常用于構造解釋器或專家系統；C/S和B/S風格适合于資料和處理分布在一定範圍、通過網絡連接配接構成的系統；平台/插件風格适用于具有插件擴充功能的應用程式；MVC風格被廣泛地應用于使用者互動程式的設計；SOA風格應用在企業內建等方面；JB/HMB風格的典型應用是青鳥軟體生産線；C2風格适用于GUI軟體開發，用以建構靈活和可擴充的應用系統，等等。
現代大型軟體很少采用單一架構風格進行設計和開發，而是混合多種風格。了解“純”的架構風格有助于在設計時選擇更為合理的架構并對各種架構進行有效組合，同時，了解背離此種風格所帶來的結果和影響對保障軟體的可靠性、可擴充性、可維護性等也有所幫助。
（2）軟體架構在開發過程中的應用
軟體架構是軟體生命周期中的重要産物，它影響軟體開發的各個階段[36,56]。
需求階段：把SA的概念引入需求分析階段，有助于保證需求規約和系統設計之間的可追蹤性和一緻性。該階段主要是根據需求來決定系統的功能，在此階段，設計者應對目标對象和環境進行細緻深入的調查，收集目标對象的基本資訊，從中找出有用資訊，這是一個抽象思維、邏輯推理的過程，結果是軟體規格說明。
從需求模型向軟體架構模型的轉換：該階段主要關注兩個問題，一是如何根據需求模型建構SA模型，二是如何保證模型轉換的可追蹤性。這兩個問題的解決方案因所采用的需求模型的不同而各異。在需求階段研究SA，有助于将SA的概念貫穿整個軟體生命周期，進而保證軟體開發過程的概念完整性，有利于各階段參與者的交流，也易于維護各階段的可追蹤性。
設計階段：設計階段是SA研究關注得最早和最多的階段，這一階段的SA研究主要包括SA模型的描述、SA模型的設計與分析方法，以及對SA設計經驗的總結與複用等。該階段需要細化至對系統進行子產品化并標明描述各個部件間的詳細接口、算法和資料類型，對上支援建立架構階段形成的架構，對下提供實作基礎。
實作階段：将設計階段設計的算法及資料類型用程式設計語言進行表示，滿足設計、架構和需求分析要求，進而得到滿足設計需求的目标系統。軟體架構在系統開發的全過程中起着基礎作用，是設計的起點和依據，同時也是裝配和維護的指南。
維護階段：為了保證軟體具有良好的維護性，在軟體架構中針對維護性目标進行分析時，需要對一些有關維護性的屬性（如可擴充性、可替換性等）進行規定，當架構經過一定的開發過程實作和形成軟體系統時，這些屬性也相應地反映了軟體的維護性。
（3）常見軟體産品的架構
1）人人網采用JavaEE技術作為主要的業務解決方案，基本按照通用的JavaEE模型進行架構設計：①Web層基于REST風格和MVC風格，為使用者提供基于Web的通路接口，人人網采用的是自己開發的Web架構Rose，該架構基于Spring Framework，類似RoR架構，增強了對Controller編碼部分的預設約定和REST風格URL的支援；②業務層封裝業務邏輯，為Web層提供業務接口，操作由資料通路層提供的資料。人人網開發了自己的SOA架構XOA以支援業務層抽象，該架構結合Rose架構，以REST風格對業務進行分類、消息格式封裝和路由。XOA支援遠端調用，并可以通過簡單添加伺服器的方式進行橫向擴充。③資料通路層提供對資料庫通路的封裝。人人網使用Java語言開發了自己的Object-Relation Mapping 架構JADE（Java Database Engine），并支援資料庫的水準橫向切分。④資料持久層實作資料的持久存儲，人人網主要采用MySQL資料庫，并且開發了自己的海量存儲系統Nuclear。
2）金蝶EAS（Enterprise Application Suite）是金蝶國際軟體集團推出的新一代企業應用套件。金蝶EAS建構于金蝶自主研發的業務作業系統—金蝶BOS（Business Operating System）之上，提供了內建的集團财務管理、集團人力資源管理、集團采購管理、集團分銷管理、供應鍊管理、協同平台等50多個應用子產品，并為企業提供行業及個性化解決方案、移動商務解決方案，實作企業間的業務協作和電子商務的應用內建。基于金蝶BOS建構的金蝶EAS系統在架構模型上遵循SOA架構體系，由四部分構成：①資訊門戶。将企業不同角色的相關人員通過Internet緊密地結合在一起協同工作，并能有效整合第三方系統。
②業務流程。涉及可靈活配置的流程引擎。其中業務流程和工作流都是可視的，企業可以随時查閱每一項業務的流程規則、路線、處理狀态及參與者，使用者的操作也變得更加簡單和直覺。③業務服務。提供統一的接口标準，使所有業務都作為功能插件連接配接在業務流程上，這些服務可以根據使用者的需要來決定是否使用甚至更換。④基礎平台。将包含各種底層存儲、計算和傳輸的技術細節通過封裝進行屏蔽，有效降低系統內建、應用部署的複雜度。
3）Lucene作為一個優秀的全文檢索引擎，其系統架構具有強烈的面向對象特征。首先其定義了一個與平台無關的索引檔案格式，其次通過抽象将系統的核心組成部分設計為抽象類，具體的平台實作部分設計為抽象類的實作，此外與具體平台相關的部分比如檔案存儲也封裝為類，經過層層的面向對象式的處理，最終實作一個低耦合高效率、容易二次開發的檢索引擎系統。Lucene的一大優勢在于其開源。這樣我們對于Lucene的架構分析可以直接從它的包以及雲代碼入手。
4）OpenStack實際上是由衆多服務組合而成的，服務之間的關聯或多或少，而且具有一定的層次關系，每個服務就像積木塊一樣，可以根據實際需要進行取舍并組合搭建，是以良好的營運架構整合能力是應用OpenStack的前提。實際上，OpenStack既是一個社群，也是一個項目和一個開源軟體，它提供了一個部署雲的操作平台或工具集。其宗旨在于幫助組織為虛拟計算或存儲服務的雲，為公有雲、私有雲，也為大雲、小雲提供可擴充的、靈活的雲計算。
5）12306網站或系統采用的是兩地三中心混合雲架構。12306的後端架構由阿裡巴巴的技術團隊提供支援，從阿裡自己的業務上來看，這套架構可以承載“雙十一”和“雙十二”這樣的大型搶購活動。這種軟體架構需要很好地支撐并發業務，支援高可靠、高性能業務的需求。該系統的架構設計應該能夠面對系統資料、使用者數增長10倍以上的情況，并且能夠提供一個穩定的響應時間，不能出現劇烈的波動等。
6）大資料時代，移動互聯、社交網絡、資料分析、雲服務等應用的迅速普及，對資料中心提出革命性需求，存儲基礎架構已經成為IT核心之一。資料的價值日益突顯，資料已經成為不可或缺的資産。作為資料的載體和驅動力量，存儲系統成為大資料基礎架構中最為關鍵的核心。資料驅動的軟體架構（Data-Driven Software Architecture，DDSA）目前在各行各業得到研究開發和推廣應用。
1.5 本章小結
作為本書的第1章，本章簡要介紹了軟體架構産生的背景，以及軟體架構的核心思想、典型特征和發展軌迹。
思考題
1.1 結合生活中遇到的各種架構（如橋梁架構、房屋架構等），闡述軟體架構的理論意義和工程意義。
1.2 根據你的經驗判斷：軟體架構的現有理論研究成果與工程實踐還存在哪些差距？
1.3 你熟悉的軟體架構都是什麼樣子的？用簡潔的語言描述其存在的問題。
參考文獻
[ 1 ] 維基百科[EB/OL].
http://zh.wikipedia.org/wiki/.[ 2 ] Chapter 1: What is Software Architecture? [EB/OL].
http://msdn.microsoft.com/en-us/libary/ee658098.aspx, 2009.
[ 3 ] Software architecture[EB/OL].
http://en.wikipedia.org/wiki/Software_architecture.[ 4 ] 梅宏, 李克勤.軟體複用與軟體構件技術[J].電子學報, 1999, 27(2): 51-68.
[ 5 ] D L Parnas. On the criteria to be used in decomposing systems into modules[J]. Communications of the ACM, 1972, 15(12): 1053-1058.
[ 6 ] E W Dijkstra.On the cruelty of really teaching computing science[J].Communications of the ACM, 1989, 32(12): 1398-1404.
[ 7 ] F P Brooks. The mythical man-month[M]. Addison-Wesley, 1975.
[ 8 ] W Royce, W Royce.Software architecture: Integrating process and technology[J].TRW Quest, 1991, 14(1): 2-15.
[ 9 ] D E Perry, A L Wolf.Foundations for the study of software architecture[J].ACM SIGSOFT Software Engineering Notes, 1992, 17(4): 40-52.
[10] M Shaw, D Garlan.Software Architecture: Perspectives on an Emerging Discipline[J].Prentice-Hall, 1996, 24(1):129-132(4).
[11] G Booch, J Rumbaugh, I Jacobson.The unified modeling language user guide[M].Pearson Education India, 1999.
[12] R Kazman, L Bass, G Abowd, et al.SAAM: A method for analyzing the properties of software architectures[C]. Proceedings of 16th International Conference on Software Engineering. IEEE, 1994: 81-90.
[13] P Kruchten.The 4+1 view model of architecture[J].Software, IEEE, 1995, 12(6): 42-50.
[14] D Soni, R Nord, C Hofmeister.Software architecture in industrial applications[C].Proceedings of the 17th International Conference on Software Engineering.IEEE, 1995: 196-196.
[15] M Maier, E Rechtin. The art of systems architecting[M]. CRC Press, 2000.
[16] R Hilliard.IEEE-std-1471—2000 recommended practice for architectural description of software-intensive systems[S/OL].
http://standards.ieee.org.[17] P O Bengtsson, J Bosch.Scenario-based software architecture reengineering[C].Proceedings of the 5th International Conference on Software Reuse. IEEE, 1998: 308-317.
[18] P Oreizy, N Medvidovic , R N Taylor.Architecture-based runtime software evolution[C].Proceedings of the 20th International Conference on Software Engineering.IEEE Computer Society, 1998: 177-186.
[19] Software Architecture—1st IFIP Conf. Software Architecture (WICSA 1) [C].Kluwer Academic Publishers, 1999.
[20] J Spencer.Architecture Description Markup Language (ADML): creating an open market for IT Architecture tools[R]. Open Group White Paper, 2000.
[21] L. Bass, P. Clements, R. Kazman Software architecture in practice[M]. Addison Wesley, 2003.
[22] N Medvidovic, D Rosenblum, R Taylor.A language and environment for architecture-based software development and evolution[C].Proceedings of the 1999 International Conference on Software Engineering, 1999: 44-53.
[23] R Allen, D Garlan.A formal basis for architectural connection[J].ACM Transactions on Software Engineering and Methodology (TOSEM), 1997, 6(3): 213-249.
[24] D Garlan, R T Monroe, D Wile.Acme: Architectural description of component-based systems[J].Foundations of component-based systems, 2000（68）: 47-68.
[25] M Shaw, R DeLine, D V Klein, et al.Abstractions for software architecture and tools to support them[J].IEEE Transactions on Software Engineering, 1995, 21(4): 314-335.
[26] D C Luckham, J J Kenney, L M Augustin, et al.Specification and analysis of system architecture using Rapide[J].IEEE Transactions on Software Engineering, 1995, 21(4): 336-354.
[27] 馬鐵, 張臯晨, 陳偉, 等.基于架構和角色模型的軟體體系結構規約[J].軟體學報, 2000 (8): 1078-1086.
[28] 馬俊濤, 傅韶勇, 劉積仁.A-ADL: 一種多智能體系統體系結構描述語言[J].軟體學報, 2000, 11(10): 1382-1389.
[29] 張家晨,馮鐵,陳偉,等.基于主動連接配接的軟體體系結構及其描述方法[J].軟體學報, 2000, 11(8): 1047-1052.
[30] H Mei, F Chen, Q Wang, et al.ABC/ADL: An ADL supporting component composition [M]//Formal Methods and Software Engineering.Springer Berlin Heidelberg, 2002: 38-47.
[31] 熊悅, 李曦, 周學海, 等.功耗–體系結構描述語言XP-ADL及其設計環境[J].小型微型計算機系統, 2003, 24(8): 1470-1473.
[32] 張世琨, 王立福, 常欣, 等.基于層次消息總線的軟體體系結構描述語言[J].電子學報, 2001, 29(5): 581-584.
[33] X Y Zhu, Z S Tang.A temporal logic-based software architecture description language XYZ/ADL[J].Journal of Software, 2003, 14(4): 713-720.
[34] 駱華俊, 唐稚松, 鄭建丹.可視化體系結構描述語言 XYZ/ADL[J].軟體學報, 2000, 11(8): 1024-1029.
[35] 李長雲, 李贛生, 何頻捷.一種形式化的動态體系結構描述語言[J].軟體學報, 2006, 17(6): 1349-1359.
[36] 孫昌愛, 金茂忠, 劉超.軟體體系結構研究綜述[J].軟體學報, 2002, 13(7): 1228-1237.
[37] P B Kruchten.The 4+1 view model of architecture[J].IEEE Software, 1995, 12(6): 42-50.
[38] C Hofmeister, P Kruchten, R L Nord, et al.A general model of software architecture design derived from five industrial approaches[J].Journal of Systems and Software, 2007, 80(1): 106-126.
[39] IEEE ARG.IEEE 1471—2000 Recommended Practice for Architectural Description[S].2000.
[40] IBM Knowledge Center [EB/OL].
https://www.ibm.com/support/knowledgecenter/.[41] R Kazman, L Bass, M Webb, et al.SAAM: A method for analyzing the properties of software architectures[C].Proceedings of the 16th international conference on Software engineering. IEEE Computer Society Press, 1994: 81-90.
[42] N Lassing, D Rijsenbrij, H van Vliet.On software architecture analysis of flexibility, Complexity of changes: Size isn't everything[C].Proceedings of the Second Nordic Software Architecture Workshop NOSA.1999: 1103-1581.
[43] G Molter.Integrating SAAM in domain-centric and reuse-based development processes[C].Proceedings of the 2nd Nordic Workshop on Software Architecture, Ronneby.1999: 1-10.
[44] C H Lung, S Bot, K Kalaichelvan, et al.An approach to software architecture analysis for evolution and reusability[C].Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research.IBM Press, 1997: 15.
[45] R Kazman, M Klein, M Barbacci, et al.The architecture tradeoff analysis method[C].Proceedings of the 4th IEEE International Conference on Engineering of Complex Computer Systems, 1998( ICECCS'98).IEEE, 1998: 68-78.
[46] P O Bengtsson, J Bosch.Scenario-based software architecture reengineering[C].Proceedings of the 5th International Conference on Software Reuse.IEEE, 1998: 308-317.
[47] P Bengtsson, J Bosch.Architecture level prediction of software maintenance[C].Proceedings of the 3rd European Conference on Software Maintenance and Reengineering, IEEE, 1999: 139-147.
[48] J C Due?as, W L de Oliveira, A Juan.A software architecture evaluation model[M]//Development and Evolution of Software Architectures for Product Families.Springer Berlin Heidelberg, 1998: 148-157.
[49] 王映輝.軟體構件與體系結構: 原理, 方法與技術[M].北京：機械工業出版社, 2009.
[50] D J Richardson, A L Wolf.Software testing at the architectural level[C].Proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints' 96) on SIGSOFT'96 workshops. ACM, 1996: 68-71.
[51] 雲曉春, 方濱興.基于構件設計的正确性驗證[J].小型微型計算機系統, 1999, 20(5): 330-334.
[52] P Inverardi, A Wolf, D Yankelevich.Behavioral type checking of architectural components based on assumptions[R].Technical Report CU-CS-861-98, University of Colorado, Department of Computer Science, 1998.
[53] R Waters, G D Abowd.Architectural synthesis: Integrating multiple architectural perspectives[C].Proceedings of the 6th Working Conference on Reverse Engineering.IEEE, 1999: 2-12.
[54] M Shaw, D Garlan.Software Architecture[M].Tsinghua University Press/Prentice Hall, 1997.
[55] 梅宏, 申峻嵘.軟體體系結構研究進展[J].軟體學報, 2006, 17(6): 1257-1275.
[56] 任雪蓮.軟體體系結構在軟體開發過程中的實踐研究[J].才智, 2009(1): 131.
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)