249.軟件體系結構起源和發展

 

1.軟件體系結構的定義

　　軟件體系結構尚處在發展期，對於其定義，目前學術界還沒有造成統一意見，不一樣學者有不一樣的見解。如下介紹並分析幾個具備表明性的定義。

 

　　定義1  IEEE610. 12—1990軟件工程標準詞彙中的定義

　　體系結構是以構件、構件之間的關係、構件與環境之間的關係爲內容的某一系統的基本組織以及指導上述內容設計與演化的原理，即

　　軟件體系結構={構件，鏈接件，環境，原理}

 

　　定義2  Booch&Rumbaugh&Jacobson的定義

　　體系結構是一系列重要決策的集合，這些決策與如下內容相關：軟件的組織、構成系統的結構元素及其接口的選擇，這些元素在相互協做中明確表現出的行爲、這些結構元素和行爲元素進一步組合構成的更大規模的子系統，和引導這一組織(包括這些元素及其接口、它們的協做、它們的組合)的體系結構風格，即

　　　軟件體系結構={組織，元素，子系統，風格}

 

　　定義3  Bass的定義

　　程序或計算系統的軟件體系結構是系統的一個或多個結構，包括軟件構件、構件的外部可視屬性和構件之間的關係。這個定義有如下含義：首先，體系結構定義了構件，描述了構件間如何交互，這意味着體系結構略去了那些僅與某構件自身有關的信息。同時，這個定義明確指出系統能夠包含多個結構，但沒有其中的哪個能夠被稱爲是體系結構。這個定義還意味着每個軟件系統都有一個體繫結構，由於每一個軟件系統都是由若干構件及其之間的關係構成的。此外，只要一個構件的行爲能夠被其餘構件觀察或辨明，這個構件就是體系結構的一部分。 

　　這裏的外部可視屬性，是指其餘構件認爲該構件所具有的特徵，如所提供的服務、具備的性能特色、錯誤處理機制、共享資源的用法等。須要注意的是，此定義中，特地未指明什麼是構件，什麼是關係。構件既能夠是對象，也能夠是進程，還能夠是函數庫或是數據庫。

 

　　定義4  Shaw的定義

　　在第一屆軟件系統體系結構國際研討會上，Mary Shaw對於當時術語使用的混亂狀況予以了澄清：不一樣學者的軟件體系結構定義之間並不相互抵觸，在回答什麼是軟件體系結構這樣的問題時，也並無根本的衝突。實際上，它們表明了軟件體系結構研究者對於體系結構研究重點的一系列不一樣見解。在會上，Shaw對當時的各類觀點作了以下的分類。

(1) 結構模型：結構模型認爲，軟件體系結構由構件、構件之間的鏈接和一些其餘方面組成。這些方面包括以下幾類：

　　· 配置，風格；

　　· 約束，語義；

　　· 分析，屬性；

　　· 原理，需求。

 

(2) 框架模型：框架模型的觀點與結構模型類似，但其重點在於整個系統的連貫結構(這種結構一般是惟一的)，這與重視其組成剛好相反。框架模型常以某種特定領域或某類問題爲目標。

 

(3) 動態模型：動態模型強調系統的行爲質量。「動態」能夠有多種含義。它能夠是指整個系統配置的變化，也能夠是指禁止預先激活了的通訊或交互，還能夠是指計算中表現出的動態特性，如改變數據的值。

 

(4) 過程模型：過程模型關注系統結構的構建及其步驟和過程。在這一觀點下，體系結構是所進行的一系列過程的結果。

 

 

　　定義5  Garlan&Shaw的模型

　　　軟件體系結構={構件，鏈接件，約束}

　　(1) 構件(Component)能夠是一組代碼，如程序的模塊，也能夠是一個獨立的程序，如數據庫服務器。構件是相關對象的集合，運行後實現某計算邏輯。它們或是結構相關或是邏輯相關。構件相對獨立，僅經過接口與外部相互做用，可做爲獨立單元嵌入到不一樣應用系統中。構件的定製和規範化對於實現構件的重用有重要意義。



　　(2) 鏈接件(Connector)能夠是過程調用、管道、遠程過程調用等，用於表示構件之間的相互做用，它把不一樣的構件鏈接起來構成體系結構的一部分。鏈接件也是一組對象。它通常表現爲框架式對象或轉換式對象(調用遠程構件資源)，例如「樁」、「代理」對象等。

　　(3) 約束(Constrain)通常爲對象鏈接時的規則，或指明構件鏈接的姿態和條件。例如，上層構件可要求下層構件的服務，反之不行；兩個對象不得以遞歸方式發送消息；代碼複製遷移的一致性約束；在什麼條件下此種鏈接無效等。主要針對鏈接件的一些約束規則。

 

 

　　定義6  Perry&Wolf的模型

　　軟件體系結構是一組具備特定形式的體系結構元素(Elements)。這組元素分爲3類：負責完成數據加工的處理元素(Processing Elements)、被加工的數據元素(Data Elements)和用於把體系結構的不一樣部分組合鏈接到一塊兒的鏈接元素(Connecting Elements)。軟件體系結構形式由專有特性和關係組成。專有特性用於限制軟件體系結構元素的選擇，關係用於限制軟件體系結構元素組合的拓撲結構。在多個體繫結構方案中選擇合適的體系結構方案每每基於一組準則，即

　　　軟件體系結構={元素，形式，準則}

 

 

　　定義7  Garlan&Perry的定義

　　1995年，David Garlan和Dewne Perry在IEEE軟件工程學報上所作的特約評論中提出：軟件體系結構是一個程序或系統各構件的結構、它們的相互關係以及進行設計的原則和指導方針，這些原則和方針隨時間變化而變化。

 

　　定義8  Boehm的模型

　　軟件體系結構包括系統構件、鏈接件、約束的集合，反映不一樣人員需求的集合，以及準則的集合。其中，這些準則可以說明由構件、鏈接件和約束所定義的系統在實現時是如何知足系統不一樣人員需求的，即

　　　軟件體系結構={構件，鏈接件，約束，不一樣人員的需求，準則}

　　比較上述體系結構定義，能夠發現：儘管各類定義都從不一樣的角度關注軟件體系結構，研究對象各有側重，但其核心內容都是軟件的系統結構，而且都蘊含構件、構件之間的關係、構件和鏈接件之間的關係等實體。

 

　　定義9 國內

　　根據國內廣泛承認的見解，能夠將體系結構定義爲構件、鏈接件和約束。軟件體系結構指可預製和可重構的軟件框架結構。構件是可預製和可重用的軟件部件，是組成體系結構的基本計算單元或數據存儲單元；鏈接件也是可預製和可重用的構件部件，是構件之間的鏈接單元；構件和鏈接件之間的關係用約束來描述。這樣就能夠把軟件體系結構寫成：

　　　體系結構(Architecture)=構件(Components)+鏈接件(Connectors)+約束(Constraints)

　　除了構件、鏈接件和約束這3個最基本的組成元素，軟件體系結構還包括端口(Port)和角色(Role)兩種元素。構件做爲一個封裝的實體，僅經過其接口與外部環境交互，而構件的接口由一組端口組成，每一個端口表示了構件和外部環境的交互點。鏈接件做爲建模軟件體系結構的主要實體，一樣也有接口。鏈接件的接口由一組角色組成，鏈接的每一個角色定義了該鏈接表示的交互的參與者。圖2-1形式化地描述了軟件體系結構的基本概念。

 

 圖2-1  軟件體系結構的基本概念

 

 

　　其中：

　　軟件體系結構∷= 軟件體系模型 | 體系結構風格

　　軟件體系模型∷= { 構件，鏈接件，約束 }

　　構件∷= { 端口1，端口2，…，端口ｎ }

　　鏈接件∷= { 角色１，角色２，…，角色m  }

　　約束∷= { (端口i，角色j)，… }

　　體系結構風格∷= { 管道-過濾器，層次系統，客戶/服務器，…，解釋器 }

 

　　下面，咱們對構件、鏈接件、約束這3個基本概念做進一步的解釋。

 

　　1．構件

　　通常認爲，構件是指具備必定功能、可明確辨識的軟件單位，而且具有如下特色：語義完整、語法正確、有可重用價值。這就意味着，在結構上，構件是語義描述、通訊接口和實現代碼的複合體。更具體地說，能夠把構件視爲用於實現某種計算邏輯的相關對象的集合，這些對象或是結構相關或是邏輯相關。在體系結構中，構件能夠有不一樣的粒度。一個構件能夠小到只有一個過程，也能夠大到包含一個應用程序。它能夠包括函數、例程、對象、二進制對象、類庫、數據包等。

　　構件內部包含了多種屬性，如端口、類型、語義、約束、演化、非功能屬性等。端口是構件與外部世界交互的一組接口。構件端口說明了構件提供哪些服務(消息、操做、變量)。它定義了構件可以提交的計算委託及其用途上的約束。構件類型是實現構件重用的手段。構件類型保證了構件自身可以在體系結構的描述中屢次實例化。

　　從抽象程度來看，構件是對一組類的組合進行封裝，並表明完成一個或多個功能的特定服務，也爲用戶提供了多個接口。構件之間是相對獨立的。構件隱藏其具體實現，只經過接口提供服務。若是不用指定的接口與之通訊，則外界不會對它的運行形成任何影響。所以，構件能夠做爲獨立單元被應用於不一樣的體系結構和軟件系統中，實現構件的重用。構件的使用與它的開發也是獨立的。

 

　　2.鏈接件

　　鏈接件是用來創建構件間的交互以及支配這些交互規則的體系結構構造模塊。構件之間的交互包括消息或信號量的傳遞，功能或方法調用，數據的傳送和轉換，構件之間的同步關係、依賴關係等。在最簡單的狀況下，構件之間能夠直接完成交互，這時體系結構中的鏈接件就退化爲直接鏈接。在比較複雜的狀況下，構件間交互的處理和維持都須要鏈接件來實現。常見的鏈接件有管道(在管道-過濾器結構中)、通訊協議或通訊機制(在客戶/服務器結構中)等。

　　鏈接件的接口由它與所鏈接構件之間的一組交互點構成，這些交互點稱作角色。角色表明了所鏈接構件的做用和地位，並體現了鏈接所具備的方向性。所以，角色存在主動和被動、請求和響應之分。

　　體系結構級的通訊須要有複雜協議來表達，爲了抽象這些協議並使之可以重用，能夠將鏈接件構造爲類型。

　　鏈接件的主要特性有可擴展性、互操做性、動態鏈接性和請求響應特性。鏈接件的可擴展性是鏈接件容許動態改變被關聯構件的集合和交互關係的性質。互操做性指的是被鏈接的構件經過鏈接件對其餘構件進行直接或間接操做的能力。動態鏈接性是對鏈接的動態約束，即鏈接件對於不一樣的所鏈接構件實施不一樣的動態處理方法的能力。請求響應特性包括響應的併發性和時序性。在並行和併發系統中，多個構件有可能並行或併發地提出交互請求，這就要求鏈接件可以正確協調這些交互請求之間的邏輯關係和時序關係。

　　對於構件而言，鏈接件是構件的黏合劑，是構件交互的實現。鏈接件和構件的區別主要在於它們在體系結構中承擔着不一樣的做用。鏈接件也是一組對象。它把不一樣的構件鏈接起來，造成體系結構的一部分，通常表現爲框架式對象或轉換式對象(調用遠程構件資源)。

 

　　3．約束(配置)

　　體系結構的約束描述了體系結構配置和拓撲的要求，肯定了體系結構的構件與鏈接件的鏈接關係。它是基於規則和參數配置的。體系結構約束提供限制以肯定構件是否正確鏈接、接口是否匹配、鏈接件構成的通訊是否正確，並說明實現所要求行爲的組合語義。

　　體系結構每每用於大型的、生存期長的軟件系統的描述。爲了更好地在一個較高的抽象層上理解系統的分析和設計，同時爲了方便系統開發者、使用者等多種有關人員之間的交流，須要簡單的、可理解的語法來配置結構化(拓撲的)信息。理想的狀況是從約束說明中澄清系統結構，即不需研究構件與鏈接件就能使構件系統的各類參與者理解系統。

 

 

 

 

 

 2.軟件體系結構的研究意義

　　軟件體系結構是軟件系統的高級抽象，每每體現了系統開發中最先作出的決策。它體現了根本性的系統設計思路，對系統起着最爲深遠的影響。體系結構在明確了系統的各個組成部分的同時，也限定了各部分間的交互方式。這將進一步影響到開發資源的配置和開發團隊的組織等其餘方方面面的開發活動，並影響着最終的軟件產品質量。 

　　在大型軟件系統中，軟件體系結構是決定系統可否順利實現的關鍵因素之一，不當的體系結構會給整個系統帶來災難性的後果。

 

　　良好的體系結構對於軟件系統的重要意義在軟件生命週期中的各個階段都有體現，這主要有以下4個方面。

　　1．對系統分析的意義

　　在系統分析階段，軟件體系結構發揮着巨大做用。

　　一方面，藉助於軟件體系結構進行描述，能夠使問題得以進一步抽象，使整個系統更易於被系統分析設計人員把握，更清晰地認識系統，完善對系統的理解。除此以外，體系結構對於系統分析帶來的優點還體如今，它爲系統分析設計人員提供了新的思路。好比，在更高層次上進行系統一致性檢查、使用成熟的軟件體系結構風格等。

　　另外一方面，它可以幫助軟件系統的各有關權益方(客戶、用戶、項目管理人員、設計開發人員以及測試人員等)造成統一認識，互相交流。交流是軟件開發的重要組成部分。在軟件開發活動中，各有關權益方承擔着不一樣角色，關注同一軟件系統不一樣的側面，這要求他們要從不一樣的角度交流對共同面對的軟件系統的認識。 

　　例如，用戶關心繫統是否知足可用性及可靠性需求；客戶關心此結構可否定期按預算實現；管理人員擔憂在經費支出和進度條件下，按此體系結構可否使開發組成員在必定程度上獨立開發，並有條不紊地有序地交互；開發人員關心達到所有目的的策略。體系結構表明了系統的公共的高層次的抽象，是你們都關心的一個重要因素。它做爲項目參與人員共同使用的語言，還具備很強的描述能力，起到了難以替代的溝通做用。系統的大部分有關人員(即便不是所有)能把它做爲創建互相理解的基礎，經過體系結構的概念、術語和規範，設計者與用戶之間、設計者之間等各方面相關人員能夠更好地彼此理解。

 

　　2.對軟件開發的意義

　　軟件體系結構表明了系統早期的設計決策。與開發、設計、編碼或運行服務及維護階段相比，早期設計決策的處理難度最大，對系統的生命期的影響也最大。同時，軟件體系結構也難於改變，會對整個系統開發活動形成深遠影響。

　　軟件體系結構是系統實現的基本約束，即系統的後繼開發工做要遵循體系結構所描述的設計決策。每一個構件或鏈接件必須知足體系結構規格說明中指定的功能、語義和接口，而且按體系結構配置中所規定的方式完成交互。這樣，構件或鏈接件的開發人員在體系結構給定的約束下進行工做，他們既不關心其餘構件或鏈接件的開發，也不會對其產生影響。而體系結構設計者也沒必要設計算法或精通編程語言。

　　軟件體系結構決定了開發和維護項目的組織活動。軟件體系結構也會反映到開發工做的分解，以及項目的人員組織。項目組成員還要使用構件的接口規格說明相互交流。即便到了維護期，項目維護人員的組織形式也經常要依據特定的軟件體系結構成分來安排。此外，對於項目組新成員，能夠用軟件體系結構做爲培訓基礎或高層次的系統概述，使他們迅速、準確地認識系統和本身的任務，快速進入開發角色。

　　軟件體系結構對於軟件質量控制有重要意義。軟件質量特性可分爲兩類：第一類是能夠經過運行軟件並觀察其效果來度量的特性，如功能、性能、安全性及可靠性等；第二類是指那些沒法經過觀察系統來度量，只能經過觀察開發活動或維護活動來考察的特性，包括各類可維護性問題，如可適應性、可移植性、可重用性等(例如，可重用性依賴於系統中的構件與其餘構件的聯繫狀況)。軟件體系結構在很大程度上肯定了系統是否能達到其需求的質量特性。 

　　使用軟件體系結構的一些評估技術(如SAAM)，對軟件體系結構加以分析，可以對軟件的某些質量特性加以預測。但同時，也必須認識到，好的軟件體系結構是成功的必要條件，但不是充分條件。僅重視軟件體系結構並不能保證系統所要求的功能和質量——低劣的設計及實現都會損害整個體系結構。

 

　　3．對軟件重用的意義

　　重用是提升軟件開發效率、保證軟件質量的重要手段。軟件開發經歷了從機器語言、彙編語言、結構化程序設計語言、面向對象程序設計語言、形式化(非形式化)規格說明語言(如體系結構描述語言)的發展過程，愈來愈適合開發人員的思惟活動模型，代碼重用的級別也在不斷地提高。體系結構技術的研究，使軟件重用從代碼重用發展到設計重用和過程重用，實現多層次的軟件重用。

　　構件的重用是體系結構良好的軟件系統最基本的一點。面向體系結構的開發方法經常注意構件的組合與裝配，而不必定把編程做爲主要活動。有效地利用標準構件，或是識別並重用系統內部的構件，或是購買第三方構件，只要這些構件與當前體系結構相容，都能減小開發中的重複勞動和系統中的重複代碼。體系結構起了組織產品的構件、接口及運行的做用。這裏要着重指出的是標準構件的應用。應用標準構件庫的關鍵在於要可以從總體上對庫中構件進行把握。一旦作到了這點，就能夠快速、靈活地在構件庫中選擇出合適的構件應用到系統中去；反之，構件的選取就只能經過反覆地瀏覽來尋找，這實際上影響到了體系結構所帶來的優點，形成了沒必要要的資源浪費。

　　體系結構良好的軟件系統中，不只構件庫可以重用，還能夠在更高層次上實現軟件子系統乃至軟件系統框架的重用。軟件體系結構級的重用意味着體系結構的決策能在具備類似需求的多個系統中發生影響，這比代碼級的重用要有更大的好處。經過對體系結構的抽象能夠使設計者可以對一些實踐證實有效的體系結構構件進行重用，從而提升設計效率和可靠性。在設計過程當中咱們經常會發現，對一個體繫結構構件稍加抽象，就能夠將它應用到其餘設計中去，這樣會大大下降設計的複雜度。 

　　例如，咱們在某個設計中採用了管道-過濾器風格，當咱們將系統映射到Unix系統中時，咱們就會發現Unix系統已經爲咱們提供了功能豐富的管道-過濾器功能，這樣咱們就能夠充分利用Unix系統提供的這些構件來簡化咱們的設計和開發。當前，針對特定領域的體系結構，人們開展了許多研究和實踐工做。這在某種意義上也是一種重用。軟件重用的層次越高，所帶來的收益也就越大。某些狀況下，重用的設計方案自己也許不是最適合該系統的，可是從總體上權衡，經過重用帶來的成本節約和質量提供可以讓重用變得很是值得。

　　軟件體系結構有利於造成完整的軟件生產線。1976年Parnas提出了發展軟件族的軟件生產線。軟件族的軟件生產線成功的關鍵問題是設計決策的次序問題，要求對於最容易發生變更的決策應當儘可能放在最遲做出。事實上，軟件族的軟件生產線表明了早期決策的總和，將影響軟件族的軟件生產線的全體成員。能夠說，體系結構在必定程度上限制了設計選擇的範圍或內容。要認識到這種決策對於每個部分來講不必定是最優，但其優勢通常能夠補償失去的特定領域優化的損失。

 

 

　　4．對系統演化的意義

　　對軟件系統的演化過程當中，維護人員須要不斷地進行調整、修改、增長新的功能或構件等工做。一般狀況下，軟件系統的開發成本中，有80%是在初次投入使用以後產生的。所以，解決好系統演化階段的開發問題具備重要意義。

　　軟件體系結構決定着系統構件的劃分和交互方式。一方面，在設計系統的體系結構之初，就應當充分考慮到未來可能的系統演化；另外一方面，在進行系統演化階段的開發時，因爲體系結構充分地刻畫了當前系統，清晰地描述了構件及其相互關係和整個系統的框架，因此應當充分利用。

　　以現有體系結構爲基礎，把握須要進行的系統變更，在系統範圍內綜合考慮，有助於肯定系統維護的最優方案，更好地控制軟件質量和維護成本。軟件爲主的系統老是存在着「利用軟件做爲增長或修改系統整體功能的工具」的傾向。重要的是要決定什麼時候進行改動，肯定哪一種改動風險最小，評估改動的後果，仲裁改動的順序及優先級。全部這些都須要深刻地洞察系統各部分的關係、相互依存關係、性能及行爲特性。而在軟件體系結構這一級進行討論，就能提供這種觀察力，更重要的是軟件體系結構能夠把可能發生的變更分爲3類：局部的、非局部的和體系結構級的。 

　　局部的是指只要修改單個構件自己；非局部的是指要修改幾個構件，但不影響基礎體系結構的變更；而體系結構級是指會影響各部分的相互關係，甚至要改動整個系統。顯然，局部改動應是最常常發生的，也是最容易進行的。軟件體系結構承擔了「保證最常常發生的變更是最容易進行的」這一重任。

 

 

3.軟件體系結構的發展歷程

　　軟件工程做爲一門獨立的學科，其發展已逾30年。不管從應用規模仍是從技術水平看，計算機軟件產業所經歷的發展都是迅猛的。這體如今諸多方面。首先，軟件系統的應用領域從實驗室滲透到了人類社會的各個角落。最初的軟件是以穿孔紙帶或卡片的形式出如今實驗室和機房中用於科學計算的；而在今天的人類社會中，各類軟件系統運行在從手持設備(如手機)到大型機(如進行天氣預報的服務器)的各類規模和用途的信息處理設備上。其次，軟件系統的規模也迅速增加。 

　　從微機不斷躍增的內存配置就能夠明顯看出這一點。1981年，IBM公司推出的第一臺PC機的配置是16 KB的內存；2003年，主流PC機的內存配置是256 MB；2008年，主流PC機的內存配置是2 GB。此外，隨着計算機產業的發展，軟件成本也在增加。20世紀50年代，軟件成本在整個計算機系統成本中所佔的比例爲10%～20%。到20世紀60年代中期，軟件成本在計算機系統中所佔的比例已經增加到50%左右。相反，計算機硬件價格隨着技術進步和生產規模擴大卻在不斷降低。軟件成本在計算機系統中所佔的比例愈來愈大。 

　　下面是一組來自美國空軍計算機系統的數據：1955年，軟件費用約佔總費用的18%，1970年達到60%，1975年達到72%，1980年達到80%，1985年達到85%左右。

　　在軟件應用規模和應用領域迅速擴大的同時，軟件開發技術也在發生着根本性的變革。軟件規模的迅速增加使得軟件開發成爲了一項過去不可思議的系統工程。根據微軟公司公佈的數據， Windows 2000開發過程當中測試用代碼行數超過1000萬行，測試兼容性的應用軟件數量約1000種，應用軟件測試中所使用的腳本程序約6500種，每個月備份的數據約88 TB，每晚模擬打印數量約25萬頁，每週刻錄CD約12 000盤。

　　在此過程當中，軟件體系結構也經歷了與之相對應的一系列變革，由最初的模糊概念發展成爲一門日益成熟的技術。下面咱們分階段進行討論。

 

 

3.1  「無體系結構」設計階段

　　1946年，隨着具備里程碑意義的ENIAC機的問世，軟件行業開始在美國和歐洲的實驗室出現。1955～1965年間，運算速度愈來愈快、價格愈來愈低的新計算機不斷涌現。這期間的軟件多數應用於學術界，或者是政府、軍隊及私人公司。可是，因爲當時的計算機硬件向着專用方向發展，科學與商業領域使用徹底不一樣的機器硬件。不斷地針對不一樣計算機編寫軟件讓軟件工做人員目不暇接，反覆地開發相同或相似的軟件使得軟件研究者開始着手處理軟件的移植問題，即設法使一種機器的彙編語言程序可以自動移植到另外一臺機器上去。但研究人員很快發現這難以實現，大量複雜代碼仍必須由程序員進行改寫。

　　在這樣的背景下，高級語言應運而生。FORTRAN語言誕生於20世紀50年代中期，是最先發布的高級語言；50年代後期，COBOL語言出現；60年代早期，ALGOL語言出現。而在當時，高級語言不能被程序編制人員所接受，他們認爲真正的程序員應使用匯編語言。

　　總的說來，20世紀70年代之前，尤爲是在以ALGOL 68爲表明的高級語言出現之前，軟件開發基本上都是用匯編程序設計。儘管此階段軟件工做者開始逐漸造成模塊編程的方法，但軟件投入的資金和人力沒法預測，軟件完工的時間沒法肯定，軟件的可靠性沒法控制等問題開始表露出來，軟件危機今後階段開始出現。一個著名的例子是1962年7月美國飛往金星的火箭控制系統中的指令，「DO 5 I=1, 3」誤寫成「DO 5 I=1.3」，致使火箭偏離軌道，被迫炸燬。

　　由於此階段系統規模較小，不多明確考慮軟件體系結構，因此通常不存在軟件系統的建模工做。

 

 

 3.2  萌芽階段

　　在1968年NATO會議上，「軟件工程」的概念首次被提出。自此，圍繞軟件項目，開展了有關開發模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，開發了一些結構化程序設計語言(例如PASCAL語言、Ada語言)，結構化軟件開發技術，而且圍繞項目管理提出了費用估算、文檔複審等方法和工具。

 　　結構化軟件開發技術在20世紀70年代中後期出現，以PASCAL、COBOL等程序設計語言和關係數據庫管理系統爲標誌，以強調數據結構、程序模塊化結構爲特徵，採用自頂向下逐步求精的設計方法和單入口單出口的控制結構。隨着結構化開發技術的出現與普遍應用，軟件開發中出現了以數據流設計和控制流設計爲主要任務的概要設計和詳細設計。伴隨着結構化軟件技術而出現的軟件工程方法(包括CASE工具)，使軟件工做的範圍從只考慮程序的編寫擴展到從定義、編碼、測試到使用、維護等活動的整個軟件生命週期。

　　 總的說來，在此階段，軟件體系結構已是系統開發中的一個明確概念。結構化程序中，由語句構成模塊，模塊的彙集和嵌套又構成層層調用的高層結構。這種程序(表達)結構和(計算的)邏輯結構的一致性造成告終構化程序的體系結構。

　　結構化程序設計時代程序規模不算大，同時，採用結構化程序設計方法進行自頂向下逐步求精的設計，並注意模塊的耦合性，就能夠獲得相對良好的結構。所以，體系結構問題並非當時軟件開發中的主要問題，也就沒有開展深刻的研究工做。

 

 

 3.3  初級階段

　　20世紀80年代初，面向對象開發技術逐漸興起。隨着面向對象技術成爲研究的熱點，出現了幾十種支持軟件開發的面向對象方法。其中，Booch、Coad/Yourdon、OMT和Jacobson的方法在面向對象軟件開發界獲得了普遍的承認。

　　面向對象開發技術以對象做爲最基本的元素，將軟件系統當作是離散的對象的集合。一個對象既包括數據，也包括行爲。 

 　　面向對象方法都支持3種基本的活動：識別對象和類，描述對象和類之間的關係，以及經過描述每一個類的功能定義對象的行爲。對象技術的優勢在於，它能讓分析者、設計者及用戶更清楚地表達概念，相互交流；同時，它做爲描述、分析和創建軟件文檔的一種手段，大大提升了軟件的易讀性、可維護性、可重用性；使得從軟件分析到軟件設計的過渡很是天然，所以可顯著下降軟件開發成本。另外，面向對象技術中的繼承、封裝、多態性等機制，直接爲軟件重用提供了進一步的支持。在面向對象開發方法階段，因爲對象是對數據及其操做的封裝，於是數據流設計與控制流設計統一爲對象建模。 

 　　同時，面向對象方法還提出了一些其餘的結構視圖。如OMT方法提出了功能視圖、對象視圖和動態視圖，Booch方法提出了類視圖、對象視圖、狀態遷移圖、交互做用圖、模塊圖、進程圖，UML則從功能模型、靜態模型、動態模型、配置模型等方面描述應用系統的結構。

 　　從1994年開始，Booch、Rumbaugh和Jacobson三人通過共同努力，推出了統一建模語言UML(Unified Modeling Language)。它結合了Booch、OMT和Jacobson方法的優勢，統一了符號體系，並從其餘的方法和工程實踐中吸取了許多通過實際檢驗的經驗和技術。對象管理組織OMG於1997年11月正式採納UML1.1做爲建模語言規範，而後成立任務組不斷修訂。儘管UML取得了巨大成功，但仍然有一些批評意見。工業界的批評主要是，它的龐大和複雜使得多數用戶難以實際應用或只能應用少量概念。學術界的批評則主要針對它在理論上的缺陷和錯誤，包括語言體系結構、語法、語義等方面的問題。

 　　隨着抽象數據類型和麪向對象技術的出現，體系結構研究逐漸獲得重視。這是由如下因素決定的：對象的封裝減低了模塊間的耦合，爲構件層次上的軟件重用提供了可能；此外，類庫的構造、分佈式應用系統的設計等規模大、複雜性高的系統，也須要對體系結構進行研究。

 

3.4  高級階段

　　20世紀90年代後，軟件開發技術進入了基於構件的軟件開發階段。軟件開發的目標是軟件具有很強的自適應性、互操做性、可擴展性和可重用性，軟件開發強調採用構件化技術和體系結構技術。

　　軟件構件技術與面向對象技術有着重要的不一樣。面向對象技術中的軟件重用主要是源代碼形式的重用，這要求設計者在重用軟件時必須理解其設計思路和編程風格。軟件構件技術則實現了對軟件的最終形式——可執行二進制碼的重用。這樣，構件的實現是徹底與實現語言無關的。任何一種過程化語言，從Ada到C到Java到C#，都可用來開發構件，而且任何一種程序設計語言均可以直接或稍做修改後使用構件技術。一個軟件可被切分紅一些構件，這些構件能夠單獨開發、單獨編譯，甚至單獨調試與測試。當完成了全部構件的開發，再對它們加以組合，就獲得了完整的軟件系統。在投入使用後，不一樣的構件還能夠在不影響系統的其餘部分的狀況下，分別進行維護和升級。

　　此階段中，軟件體系結構逐漸成爲軟件工程的重要研究領域，並最終做爲一門學科獲得了業界的廣泛認同。在基於構件和體系結構的軟件開發方法下，程序開發模式也相應地發生了根本變化。軟件開發再也不是「算法+數據結構」，而是「構件開發+基於體系結構的構件組裝」。軟件體系結構做爲開發文檔和中間產品，開始出如今軟件過程當中。有研究人員認爲，「將來的年代將是研究軟件體系結構的時代」。

 

3.5 綜合　　

　　從軟件技術的發展過程能夠看出，在各個時期，軟件體系結構的問題實際上老是存在的，可是它是隨着軟件系統的規模和複雜性的日益膨脹才逐漸表露、被人們發現和研究的。從最初的「無體系結構」設計到今天的基於體系結構的軟件開發，軟件體系結構技術大體經歷瞭如下4個階段：

• 　　(1) 「無體系結構」設計階段：開發主要採用彙編語言，規模通常較小。
• 　　(2) 萌芽階段：主要採用結構化的開發技術。
• 　　(3) 初級階段：主要採用面向對象的開發技術，從多種角度對系統建模(如UML)。
• 　　(4) 高級階段：該階段以Kruchten提出的「4+1」模型爲標誌。軟件開發的中心是描述系統的高層抽象結構模型，相比之下，傳統的軟件結構更關心具體的建模細節。

　　軟件體系結構技術仍存在諸多問題，如概念定義尚不統1、描述規範不能一致等。有研究人員認爲在軟件開發實踐中軟件體系結構尚不能發揮重要做用，軟件體系結構技術仍有待研究、發展和完善。
　

 

4.軟件體系結構的研究現狀及發展方向

4.1 軟件體系結構的研究現狀

　　軟件體系結構做爲軟件工程研究領域的一部分，已經取得了長足的發展，受到大多數軟件系統設計和研究人員的重視。但當前，體系結構還是一個處在不斷髮展中的新研究領域，許多定義還不夠統一，概括現有體系結構的研究活動，主要的討論和研究大體集中在如下幾個方面。　　

1．軟件體系結構描述研究

　　構建軟件體系結構的目的之一就是創建一個可供各類人員交流的平臺，而且要具有系統架構級的可重用性。所以如何恰當、準確地對軟件體系結構進行描述是相當重要的。這種描述應當可以爲各類人員提供不一樣的視圖以知足其不一樣的要求；同時，當要構建新的應用或對應用進行系統級更改時，這種描述應該可以快速提供可重用的系統架構視圖或系統模塊視圖。這方面的研究包括軟件體系結構描述語言、使用「4+1」 模型描述軟件體系結構、使用UML描述軟件體系結構等方面的研究。

　　1) 軟件體系結構描述語言
　　現有的一些軟件體系結構描述方法採用非形式化的方法，體系結構設計常常難以理解，難以對體系結構進行形式化分析和模擬，缺少相應的支持工具幫助設計師完成設計工做。爲了解決這個問題，用於描述和推理的形式化語言得以發展，這些語言就叫作體系結構描述語言(Architecture Description Language，ADL)，ADL尋求增長軟件體系結構設計的可理解性和重用性。
　　ADL是這樣一種語言，系統設計師能夠利用它所提供的特性進行軟件系統概念體系結構建模。ADL提供了具體的語法與刻畫體系結構的概念框架。它使得系統開發者可以很好地描述他們設計的體系結構，以便與他人交流，可以用提供的工具對許多實例進行分析。
　　研究人員已經設計出了若干種ADL，典型的有Aesop、MetaH、C二、Rapide、SADL、UniCon和Wright等，儘管它們都描述軟件體系結構，卻有不一樣的特色：Aesop支持體系結構風格的應用；MetaH爲設計者提供了關於實時電子控制軟件系統的設計指導；C2支持基於消息傳遞風格的用戶界面系統的描述；Rapide支持體系結構設計的模擬並提供了分析模擬結果的工具；SADL提供了關於體系結構加細的形式化基礎；UniCon支持異構的構件和鏈接件類型，並提供了關於體系結構的高層編譯器；Wright支持體系結構構件之間交互的說明和分析。
　　這些ADL及它們的支持工具、描述方法和形式各不相同，強調了體系結構不一樣的側面，對體系結構的研究和應用起到了重要的做用，但也有負面的影響。每一種ADL都以獨立的形式存在，描述語法不一樣且互不兼容。同時又有許多共同的特徵，這使設計人員很難選擇一種合適的ADL；大部分ADL都是領域相關的，不利於對不一樣領域的體系結構進行分析；一些ADL在某些方面大同小異，有不少冗餘的部分。
　　針對這些不足，已出現一些交換語言，其目標是提供一個公共形式把各類語言綜合起來，以此來綜合不一樣的體系結構描述。ACME就是其中較有影響的一個，它的目標是抽取諸多ADL中與具體ADL無關的信息做爲交換的依據，同時，容許併入相關信息做爲保留的輔助信息。另一個研究熱點是開發基於XML的體系結構描述語言。XML是可擴展標記語言，它簡單並易於實現，所以被工業界普遍使用。若能用XML來表示軟件體系結構，必能極大推進軟件體系結構領域的研究成果在軟件產業界的應用。因爲XML在體系結構描述上的許多優勢，研究者們已經開發出了不一樣的基於XML的體系結構描述語言，如XADL1.0、XBA、XCOBA等。

　　2) 使用「4+1」 模型描述軟件體系結構
　　按照必定的描述方法，用體系結構描述語言對體系結構進行說明的結果稱爲體系結構的表示，而將描述體系結構的過程稱爲體系結構構造。在體系結構描述方面，Kruchten提出的「4+1」模型是當前軟件體系結構描述的一個經典範例，該模型由邏輯視圖、開發視圖、過程視圖和物理視圖組成，並經過場景將這4個視圖有機地結合起來，比較細緻地描述了需求和體系結構之間的關係。
　　「4+1」模型實際上使得有不一樣需求的人員可以獲得他們對於軟件體系結構想要了解的東西。系統工程師先從物理視圖，而後從過程視圖靠近體系結構。最終使用者、客戶、數據專家從邏輯視圖看體系結構；項目經理、軟件配置人員從開發視圖看體系結構。

　　3) 使用UML描述軟件體系結構
　　Booch從UML的角度給出了一種由設計視圖、過程視圖、實現視圖和部署視圖，再加上一個用例視圖構成的體系結構描述模型。Medividovic則總結了用UML描述體系結構的三種途徑：不改變UML用法而直接對體系結構建模；利用UML支持的擴充機制擴展UML的元模型對體系結構建模概念的支持；對UML進行擴充，增長體系結構建模元素。本書第3章介紹了不改變UML用法而直接對體系結構建模的方法。UML的靜態建模機制包括用例圖、類圖、對象圖、包、構件圖和部署圖。UML的動態建模機制包括順序圖、協做圖、狀態圖和活動圖。能夠使用UML對構件交互模式進行靜態建模和動態建模。

　　2.軟件體系結構設計研究

　　軟件體系結構設計研究包括體系結構風格研究、體系結構設計原理、設計模式和設計方法研究。
　　1) 體系結構風格研究
　　體系結構設計研究的重點內容之一就是體系結構風格的研究。人們在開發不一樣系統時，會逐漸發現一類系統的體系結構上有許多共性，因而抽取出這些共性構成一些富有表明性和被普遍接受的體系結構風格。因此說體系結構風格是用來刻畫具備類似結構和語義性質的一類系統族的。它定義一組構件、鏈接件的類型以及它們之間應該如何鏈接的約束。
　　通常來講，一個系統不必定只具備一種風格，在不一樣層次或抽象級別上，可具備多種風格。雖然系統組織方式能夠是無窮的，但若是能用少許的風格類型表達出較多的系統組織方式，不只能夠縮短系統分析設計的時間，還能大大提升大規模軟件重用的機會。
　　Garlan和Shaw給出了對通用體系結構風格的分類：數據流風格、調用/返回風格、獨立構件風格、虛擬機風格和倉庫風格。

　　2) 體系結構設計原理
　　參照軟件工程、結構化程序設計和麪向對象程序設計原理，結合軟件體系結構設計自己的特色，能夠總結出軟件體系結構設計過程當中用到的原理主要有如下幾個：抽象、封裝、信息隱藏、模塊化、注意點分離、耦合和內聚、接口和實現分離、分而治之、層次化等。

　　3) 體系結構設計模式
　　設計模式的概念最先是由美國的一位叫作Christopher Alexander的建築理論家提出來的，他試圖找到一種結構化、可重用的方法，以在圖紙上捕捉到建築物的基本要素。後來被做爲總結軟件設計，特別是面向對象設計的實踐和經驗而提出。在幾十年的軟件設計研究和實踐中，設計人員和程序員積累了大量的實際經驗，發現並提出了大量在衆多應用中廣泛存在的軟件結構和結構關係，模式被用於軟件體系結構設計中。利用設計模式能夠方便地重用成功的設計和結構。把已經證明的技術表示爲設計模式，使它們更加容易被新系統的開發者所接受。設計模式幫助設計師選擇可以使系統重用的設計方案，避免選擇危害到可重用性的方案。

　　4) 體系結構設計方法
　　生成一個知足軟件需求的體系結構的過程即爲體系結構設計。體系結構設計過程的本質在於：將系統分解成相應的組成成分(如構件、鏈接件)，並將這些成分從新組裝成一個系統。經常使用的體系結構設計方法有4類，分別爲製品驅動(artifact-driven)的方法，用例驅動(use-case-driven)的方法，模式驅動(pattern-driven)的方法和領域驅動(domain-driven)的方法。每種方法在過程的順序上、在概念的特定內容上有所不一樣，但最後都生成對體系結構的描述。

　　3．基於體系結構的軟件開發方法

　　本質上，軟件體系結構是對軟件需求的一種抽象解決方案。在引入了體系結構的軟件開發中，應用系統的構造過程變爲「問題定義→軟件需求→軟件體系結構→軟件設計→軟件實現」，能夠認爲軟件體系結構架起了軟件需求與軟件設計之間的一座橋樑。而在由軟件體系結構到實現的過程當中，藉助必定的中間件技術與軟件總線技術，軟件體系結構易於映射成相應的實現。Bass等人提出了一種基於體系結構的軟件開發過程，該過程包括6個步驟：導出體系結構需求；設計體系結構；文檔化體系結構；分析體系結構；實現體系結構；維護體系結構。對此在本書第5章中會進行介紹。
　　軟件開發模型是跨越整個軟件生存週期的系統開發、運行、維護所實施的所有工做和任務的結構框架，給出了軟件開發活動各階段之間的關係。目前，常見的軟件開發模型大體可分爲3種類型：
　　(1) 以軟件需求徹底肯定爲前提的瀑布模型。
　　(2) 在軟件開發初始階段只能提供基本需求時採用的漸進式開發模型，如螺旋模型等。
　　(3) 以形式化開發方法爲基礎的變換模型。
　　全部開發方法都是要解決需求與實現之間的差距。可是，這3種類型的軟件開發模型都存在這樣或那樣的缺陷，不能很好地支持基於軟件體系結構的開發過程。所以，研究人員在發展基於體系結構的軟件開發模型方面作了必定的工做。
　　在基於構件和基於體系結構的軟件開發逐漸成爲主流的開發方法的狀況下，已經出現了基於構件的軟件工程。可是，對體系結構的描述、表示、設計和分析以及驗證等內容的研究還相對不足，隨着需求複雜化及其演化，切實可行的體系結構設計規則與方法將更爲重要。

　　4．軟件體系結構評估

　　軟件體系結構的設計是整個軟件開發過程當中關鍵的一步。對於當今世界上龐大而複雜的系統來講，沒有一個合適的體系結構而要有一個成功的軟件設計幾乎是不可想象的。不一樣類型的系統須要不一樣的體系結構，甚至一個系統的不一樣子系統也須要不一樣的體系結構。體系結構的選擇是一個軟件系統設計成敗的關鍵。
　　可是，怎樣才能知道爲軟件系統所選用的體系結構是否恰當？如何確保按照所選用的體系結構能順利地開發出成功的軟件產品呢？要回答這些問題，須要使用專門的方法對軟件體系結構進行分析和評估。
　　經常使用的軟件體系結構評估方法有軟件體系結構分析方法(Software Architecture Analysis Method，SAAM)和體系結構權衡分析方法(Architecture Tradeoff Analysis Method，ATAM)。它們都是基於場景的軟件體系結構評估方法，這類評估方法分析軟件體系結構對場景也就是對系統的使用或修改活動的支持程度，從而判斷該體系結構對這一場景所表明的質量需求的知足程度。例如，用一系列對軟件的修改來反映易修改性方面的需求，用一系列攻擊性操做來表明安全性方面的需求等。SAAM本質上是一個尋找受場景影響的體系結構元素的方法，而ATAM創建在SAAM基礎上，關注對風險、非風險、敏感點和權衡點的識別。

　　5．特定領域的體系結構框架

　　特定領域的應用一般具備類似的特徵，若是可以充分挖掘系統所在領域的共同特徵，提煉出領域的通常需求，抽象出領域模型，概括總結出這類系統的軟件開發方法，就可以指導領域內其餘系統的開發，提升軟件質量和開發效率、節省軟件開發成本。正是基於這種考慮，人們在軟件的理論研究和工程實踐中，逐漸造成一種稱之爲特定領域的軟件體系結構(Domain Specific Software Architecture，DSSA)的理論與工程方法，它對軟件設計與開發過程具備必定參考和指導意義，已經成爲軟件體系結構研究的一個重要方向。
　　Rick Hayers-Roth和Will Tracz分別對DSSA給出了不一樣的定義，前者側重於DSSA的特徵，強調系統由構件組成，適用於特定領域，有利於開發成功應用程序的標準結構；後者側重於DSSA的組成要素，指出DSSA應該包括領域模型、參考需求、參考體系結構、相應的支持環境或設施、實例化、細化或評估的方法與過程。兩種DSSA定義都強調了參考體系結構的重要性。
　　特定領域的體系結構是將體系結構理論應用到具體領域的過程，常見的例子有：
　　(1) 用戶界面工具和框架。能夠爲開發者提供可重用框架以及像菜單、對話框等可重用構件的集合。
　　(2) 編譯器的標準分解。體系結構的重用能使語言編譯系統的開發變得很是簡單。
　　(3) 標準化的通訊協議。經過在不一樣層次的抽象上提供服務，可實現跨平臺的交互。

　　6．軟件體系結構支持工具

　　幾乎每種體系結構都有相應的支持工具，如UniCon、Aesop等體系結構支持環境，C2的支持環境ArchStudio，Acme的支持環境AcmeStudio，支持主動鏈接件的Tracer工具等。另外，還出現了不少支持體系結構的分析工具，如支持靜態分析的工具、支持類型檢查的工具、支持體系結構層次依賴分析的工具、支持體系結構動態特性仿真工具、體系結構性能仿真工具等。但與其餘成熟的軟件工程環境相比，體系結構設計的支持工具還很不成熟，難以實用化。本書經過兩個較爲著名的軟件體系結構集成開發環境ArchStudio4和AcmeStudio，介紹軟件體系結構集成開發環境的具體功能。

 

 

 

4.2 軟件體系結構的發展方向　　

1．各類軟件體系結構語言之間的信息互換　　

　　現有的各類軟件體系結構描述語言大可能是與領域相關的，因此不利於對不一樣領域體系結構的說明。但這些針對不一樣領域的軟件體系結構描述語言在某些方面又大同小異，形成資源的冗餘。其實，大多數軟件體系結構描述語言具備一系列共同概念。如何用一種公共形式把各類語言綜合起來，使得可以交換各類體系結構描述信息，將是從此軟件體系結構研究和實踐的重點之一。

2.設計工具和環境

　　軟件體系結構設計做爲軟件工程的一部分，它的計算機輔助實現手段是至關重要的。應當開發出一些軟件工具來實現體系結構的描述和分析，開發階段轉換工具能夠實現階段成果的自動轉換，例如，把需求規格說明自動轉換爲構件等。目前關於這方面的研究成果不多，特別是能夠應用到實際項目開發中的工具和環境就更少。

3．體系結構再工程問題

　　如今軟件系統的規模變得愈來愈大，結構也愈來愈複雜，同時從頭開始構建的大系統數量在急劇地減小，於是不少遺留系統正在被逐步地利用。從遺留系統軟件代碼和系統中抽取結構信息，通過描述、統1、抽象、通常化與實例化等處理，可總結出系統的體系結構。

 

5 本 章 小 結

　　本章首先介紹了軟件體系結構的各類定義和基本概念，它們是本章的重點。考慮到定義的通常適用性和被普遍接受的程度，咱們所提到的軟件體系結構，都以定義5中的軟件體系結構概念爲基礎。構件、鏈接件和約束(配置)等概念是軟件體系結構最基本的元素。
　　接下來介紹了軟件體系結構研究的意義，良好的體系結構對於軟件系統的重要意義在軟件生命週期中的各個階段都有體現。
　　軟件體系結構發展到如今共經歷了4個發展階段：「無體系結構」設計階段、萌芽階段、初級階段和高級階段，對每一階段進行了簡單介紹。概括現有軟件體系結構的研究活動，介紹了軟件體系結構研究現狀和發展方向。當前的體系結構研究主要集中在軟件體系結構描述研究、設計研究、分析與評估、支持工具，基於體系結構的開發方法、特定領域的體系結構框架等方面。
　　軟件體系結構技術目前仍存在諸多問題，如概念定義尚不統1、描述規範不能一致等。有研究人員認爲在軟件開發實踐中軟件體系結構尚不能發揮重要做用，軟件體系結構技術仍有待研究、發展和完善。

　　1．爲何要研究軟件體系結構？
　　1.根據軟件體系結構的定義，你認爲軟件體系結構的模型應該由哪些部分組成？
　　3．軟件體系結構的概念和建築中的體系結構的概念相相似，兩者有什麼共同之處？這種類比對於咱們認識和研究軟件體系結構有何幫助？
　　4．結合本身曾參與開發的軟件項目，思考構件、鏈接件和約束的概念，並用本身的語言描述構件、鏈接件和約束的特色，進一步論述構件、鏈接件和約束分別對於軟件體系結構的重要意義。
　　5．查閱相關文獻，比較各類軟件體系結構定義，進一步討論它們的聯繫和區別。