軟件體系結構2012年9月軟件體系結構

出版社：清華大學出版社

作者：張友生軟件體系結構第一章軟件體系結構概論軟件體系結構軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。軟件危機的表現軟件成本日益增長開發進度難以控制軟件質量差軟件維護困難1.1從軟件危機談起軟件體系結構

軟件成本日益增長

20世紀50年代，軟件成本在整個計算機系統成本中所占的比例為10%-20%。到20世紀60年代中期，軟件成本在計算機系統中所占的比例已經增長到50%左右。而且，該數字還在不斷地遞增，下面是一組來自美國空軍計算機系統的數據：1955年，軟件費用約占總費用的18%，1970年達到60%，1975年達到72%，1980年達到80%，1985年達到85%左右。軟件危機的表現軟件體系結構開發進度難以控制由于軟件是邏輯、智力產品，軟件的開發需建立龐大的邏輯體系，這是與其他產品的生產不一樣的。在軟件開發過程中，用戶需求變化等各種意想不到的情況層出不窮，令軟件開發過程很難保證按預定的計劃實現，給項目計劃和論證工作帶來了很大的困難。盲目增加軟件開發人員并不能成比例地提高軟件開發能力。相反，隨著人員數量的增加，人員的組織、協調、通信、培訓和管理等方面的問題將更為嚴重。軟件體系結構軟件質量差軟件項目即使能按預定日期完成，結果卻不盡人意。1965年至1970年，美國范登堡基地發射火箭多次失敗，絕大部分故障是由應用程序錯誤造成的。在“軟件作坊”里，由于缺乏工程化思想的指導，程序員幾乎總是習慣性地以自己的想法去代替用戶對軟件的需求，軟件設計帶有隨意性，很多功能只是程序員的“一廂情愿”而已，這是造成軟件不能令人滿意的重要因素。軟件體系結構軟件維護困難由于在軟件設計和開發過程中，沒有嚴格遵循軟件開發標準，各種隨意性很大，沒有完整的真實反映系統狀況的記錄文檔，給軟件維護造成了巨大的困難。特別是在軟件使用過程中，原來的開發人員可能因各種原因已經離開原來的開發組織，使得軟件幾乎不可維護。有資料表明，工業界為維護軟件支付的費用占全部硬件和軟件費用的40%-75%。軟件體系結構用戶需求不明確在軟件開發完成之前，用戶不清楚軟件的具體需求；用戶對軟件需求的描述不精確，可能有遺漏、有二義性、甚至有錯誤；在軟件開發過程中，用戶還提出修改軟件功能、界面、支撐環境等方面的要求；開發人員對用戶需求的理解與用戶本來愿望有差異。軟件危機的原因軟件體系結構缺乏正確的理論指導缺乏有力的方法學和工具方面的支持。由于軟件不同于大多數其他工業產品，其開發過程是復雜的邏輯思維過程，其產品極大程度地依賴于開發人員高度的智力投入。由于過分地依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件產品的個性化，也是發生軟件危機的一個重要原因。軟件體系結構軟件規模越來越大隨著軟件應用范圍的增廣，軟件規模愈來愈大。大型軟件項目需要組織一定的人力共同完成，而多數管理人員缺乏開發大型軟件系統的經驗，而多數軟件開發人員又缺乏管理方面的經驗。各類人員的信息交流不及時、不準確、有時還會產生誤解。軟件項目開發人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤。軟件體系結構軟件復雜度越來越高軟件不僅僅是在規模上快速地發展擴大，而且其復雜性也急劇地增加。軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。所謂“復雜問題”的概念是相對的，一旦人們采用先進的組織形式、開發方法和工具提高了軟件開發效率和能力，新的、更大的、更復雜的問題又擺在人們的面前。軟件體系結構如何克服軟件危機軟件危機的原因：“人們面臨的不光是技術問題，更重要的是管理問題。管理不善必然導致失敗。”要提高軟件開發效率，提高軟件產品質量，必須采用工程化的開發方法與工業化的生產技術----軟件工程在技術上，應該采用基于重用的軟件生產技術；在管理上，應該采用多維的工程管理模式。軟件體系結構軟件工程的三大要素：方法：完成軟件工程項目的技術手段工具：為軟件工程方法提供自動或半自動的軟件支撐環境過程：軟件工程的方法和工具綜合起來以達到合理、及時地進行計算機軟件開發的目的軟件體系結構當前社會的信息化過程對軟件需求的增長非常迅速，但是目前軟件的開發與生產能力卻相對不足。提高軟件開發效率和軟件產品質量，則必須采用工程化的開發方法與工程化的生產技術。技術方面：采用基于重用的軟件生產技術管理方面：采用多維的工程管理模式1.2構件與軟件重用軟件體系結構在工程化的軟件開發過程中構件是核心和基礎重用是必要的手段軟件體系結構構件是指語義完整、語法正確和有可重用價值的單位軟件，是軟件重用過程中可以明確辨識的系統；結構上，它是語義描述、通訊接口和實現代碼的復合體。具有一定功能，能夠獨立工作或能同其他構件裝配起來協調工作的程序體，使用上同它的開發、生產無關。軟件體系結構軟件重用是指在兩次或多次不同的軟件開發過程中重復使用相同或相近軟件元素的過程。軟件元素包括：程序代碼測試用例設計文檔設計過程需求分析文檔領域知識軟件體系結構構件模型是對構件本質特征的抽象描述。構件模型的三個主要流派：OMG（ObjectManagementGroup，對象管理集團）的CORBA（CommonObjectRequestBrokerArchitecture，通用對象請求代理結構）Sun的EJB（EnterpriseJavaBean）Microsoft的DCOM（DistributedComponentObjectModel，分布式構件對象模型）。軟件體系結構構件獲取途徑：從現有構件中獲得符合要求的構件，直接使用或作適應性修改，得到可重用的構件；通過遺留工程，將具有潛在重用價值的構件提取出來，得到可重用的構件；從市場上購買現成的商業構件，即COTS（CommercialOff-The-Shell）構件；開發新的符合要求的構件。軟件體系結構構件描述構件模型是對構件本質的抽象描述，主要是為構件的制作與構件的重用提供依據；從管理角度出發，也需要對構件進行描述，例如：實現方式、實現體、注釋、生產者、生產日期、大小、價格、版本和關聯構件等信息，它們與構件模型共同組成了對構件的完整描述。構件管理軟件體系結構構件分類與組織為了給使用者在查詢構件時提供方便，同時也為了更好地重用構件，必須對收集和開發的構件進行分類并置于構件庫德適當位置。構件庫組織方法的要求：支持構件庫的各種維護動作不僅要支持精確匹配，還要支持相似構件的查找不僅能進行簡單的語法匹配，而且能夠查找在功能或行為方面的等價或相似的構件對應用領域具有較強的描述能力和較好的描述精度庫管理員和用戶容易使用軟件體系結構分類方法：關鍵字分類法是一種最簡單的構件庫組織方法。思路是：根據領域分析的結果將應用領域的概念按照從抽象到具體的順序逐次分解為樹形或有向無回路圖結構。每個概念用一個描述性的關鍵字表示。不可分解的原子級關鍵字包含隸屬它的某些構件。軟件體系結構軟件體系結構刻面分類法定義若干用于刻畫構件特征的“面”，每個面包含若干概念，這些概念表述構件在面上的特征。刻面可以描述構件執行的功能被操作的數據構件應用的語境任意其他特征格式：{function,objecttype,systemtype,...}軟件體系結構超文本組織法是基于全文檢索技術。是所有構件必須輔以詳盡的功能或行為說明文檔。說明中出現的重要概念或構件以網狀鏈接方式相互連接；檢索者在閱讀文檔的過程中可按照人類的聯想思維方式任意跳轉到包含相關概念或構件的文檔。全文檢索系統將用戶給出的關鍵字與說明文檔中的文字進行匹配，實現構件的瀏覽式檢索。軟件體系結構軟件體系結構商業構件的分類：用戶界面類、數據庫類商務應用類工具類、網絡通訊類核心技術類軟件體系結構構件的外部形態分類：獨立而成熟的構件有限制的構件適應性構件裝配的構件可修改的構件軟件體系結構人員及權限管理訪問構件庫的不用使用者的訪問權限作出適當的限制，以保證數據安全。一般來講，構件庫系統可包括五類用戶，即注冊用戶、公共用戶、構件提交者、一般系統管理員和超級系統管理員。軟件體系結構構件重用為了讓構件在新的軟件項目中發揮作用，構件庫的使用者必須完成以下的工作：檢索與提取構件

理解與評價構件修改構件構件組裝軟件體系結構檢索與提取構件基于關鍵字的檢索刻面檢索法構造查詢檢索構件對構件進行排序超文本檢索法其他檢索方法軟件體系結構理解與評價構件構件的功能與行為相關的領域知識可適應性約束條件與例外情形可以預見的修改部分及修改方法軟件體系結構修改構件理想的情形是對庫中的構件不作修改而直接用于新的軟件項目。但是，在大多數情況下，必須對構件進行或多或少的修改，以適應新的需求。為了減少構件修改的工作量，要求開發人員盡量使構件的功能、行為和接口設計更為抽象化、通用化和參數化。軟件體系結構基于功能的組裝技術基于功能的組裝技術采用子程序調用和參數傳遞的方式將構件組裝起來。它要求庫中的構件以子程序/過程/函數的形式出現，并且接口說明必須清晰。當使用這種組裝技術進行軟件開發時，開發人員首先應對目標軟件系統進行功能分解，將系統分解為強內聚、松耦合的功能模塊。然后根據各模塊的功能需求提取構件，對它進行適應性修改后再掛接在上述功能分解框架中。構件組裝軟件體系結構基于數據的組裝技術首先根據當前軟件問題的核心數據結構設計出一個框架，然后根據框架中各結點的需求提取構件并進行適應性修改，再將構件逐個分配至框架中的適當位置。此后，構件的組裝方式仍然是傳統的子程序調用與參數傳遞。這種組裝技術也要求庫中構件以子程序形式出現，但它所依賴的軟件設計方法不再是功能分解，而是面向數據的設計方法，例如Jackson系統開發方法。軟件體系結構面向對象的組裝技術如果類庫中的基類能夠滿足新軟件需求，則可以直接應用；否則，必須以類庫中的基類為父類，采用構造法或子類法生成子類。構造法在子類中引進基類的對象作為子類的成員變量，然后在子類中通過成員變量重用基類的屬性和方法。子類法將新子類直接說明為庫中基類的子類，通過繼承和修改基類的屬性與行為完成新子類的定義。軟件體系結構classPerson{public: Person(char*name,intage) ~Person();protected: char*name; intage;};//基類構造函數Person::Person(char*name,intage){ Person::name=newchar[strlen(name)+1]; strcpy(Person::name,name); Person::age=age; cout<<"ConstructPerson"<<name<<","<<age<<".\n";}//基類析構函數Person::~Person(){ cout<<"DestructPerson"<<name<<","<<age<<".\n"; deletename; return;}軟件體系結構//采用構造法生成TeacherclassTeacher{public: Teacher(char*name,intage,char*teaching); ~Teacher();protected: Tperson*Person; char*course;};Teacher::Teacher(char*name,intage,char*teaching){ Tperson=newPerson(name,age); strcpy(course,teaching); return;}Teacher::~Teacher(){ deleteTperson;}軟件體系結構classPerson{public: Person(char*name,intage) ~Person();protected: char*name; intage;};//基類構造函數Person::Person(char*name,intage){ Person::name=newchar[strlen(name)+1]; strcpy(Person::name,name); Person::age=age; cout<<"ConstructPerson"<<name<<","<<age<<".\n";}//基類西溝函數Person::~Person(){ cout<<"DestructPerson"<<name<<","<<age<<".\n"; deletename; return;}軟件體系結構//采用子類法構造TeacherclassTeacher::Person{public: Teacher(char*name,intage,char*teaching):Person(name,age)

{ course=newchar[strlen(teaching)+1]; strcpy(course,teaching); return;

} ~Teacher()

{ deletecourse; return;

}protected: char*course;};軟件體系結構隨著軟件系統規模越來越大、越來越復雜，整個系統的結構和規格說明顯得越來越重要。對于大規模的復雜軟件系統來說，對總體的系統結構設計和規格說明比起對計算的算法和數據結構的選擇已經變得明顯重要得多。對軟件體系結構的系統、深入的研究將會成為提高軟件生產率和解決軟件維護問題的新的最有希望的途徑。事實上，軟件總是有體系結構的，不存在沒有體系結構的軟件。軟件體系結構雖脫胎于軟件工程，但其形成同時借鑒了計算機體系結構和網絡體系結構中很多寶貴的思想和方法，最近幾年軟件體系結構研究已完全獨立于軟件工程的研究，成為計算機科學的一個最新的研究方向和獨立學科分支。1.3體系結構的興起和發展軟件體系結構◎DewaynePerry和A1exanderWo1f軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工數據構件是被加工的信息連接構件把體系結構的不同部分組合連接起來。這一定義注重區分處理構件、數據構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。軟件體系結構的定義軟件體系結構◎MaryShaw和DavidGarlan軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。體系結構問題包括總體組織和全局控制、通訊協議、同步、數據存取，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數據結構之上關于整體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數據存取的協議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現等。軟件體系結構◎Kruchten軟件體系結構有四個角度，它們從不同方面對系統進行描述：概念角度描述系統的主要構件及它們之間的關系；模塊角度包含功能分解與層次結構；運行角度描述了一個系統的動態結構；代碼角度描述了各種代碼和庫函數在開發環境中的組織。軟件體系結構◎HayesRoth軟件體系結構是一個抽象的系統規范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系。軟件體系結構◎DavidGarlan和DewnePerry軟件體系結構是一個程序／系統各構件的結構、它們之間的相互關系以及進行設計的原則和隨時間演化的指導方針。軟件體系結構◎BarryBoehm軟件體系結構包括一個軟件和系統構件，互聯及約束的集合；一個系統需求說明的集合；一個基本原理用以說明這一構件，互聯和約束能夠滿足系統需求。軟件體系結構◎Bass，Ctements和Kazman軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。其中，“軟件外部的可見特性”是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。軟件體系結構◎我們的定義軟件體系結構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。軟件體系結構不僅指定了系統的組織結構和拓撲結構，并且顯示了系統需求和構成系統的元素之間的對應關系，提供了一些設計決策的基本原理。軟件體系結構架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設計；同時，也為軟件架構的理解、交流和歸檔提供了方便。軟件體系結構體系結構是風險承擔者進行交流的手段軟件體系結構代表了系統的公共的高層次的抽象。這樣，系統的大部分有關人員（即使不是全部）能把它作為建立一個互相理解的基礎，形成統一認識，互相交流。體系結構提供了一種共同語言來表達各種關注和協商，進而對大型復雜系統能進行理智的管理。這對項目最終的質量和使用有極大的影響。*“風險承擔人”：最終用戶、開發人員、系統工程師、項目經理等。軟件體系結構的意義軟件體系結構體系結構是早期設計決策的體現

（1）軟件體系結構明確了對系統實現的約束條件（2）軟件體系結構決定了開發和維護組織的組織結構（3）軟件體系結構制約著系統的質量屬性（4）通過研究軟件體系結構可能預測軟件的質量（5）軟件體系結構使推理和控制更改更簡單（6）軟件體系結構有助于循序漸進的原型設計（7）軟件體系結構可以作為培訓的基礎軟件體系結構軟件體系結構是可傳遞和可重用的模型軟件體系結構級的重用意味著體系結構的決策能在具有相似需求的多個系統中發生影響，這比代碼級的重用要有更大的好處。軟件體系結構軟件體系結構的發展史“無體系結構”設計階段萌芽階段以匯編語言進行小規模應用程序開發為特征以描述系統的高層抽象結構為中心，不關心具體的建模細節，劃分了體系結構模型與傳統軟件結構的界限，該階段以Kruchten提出的“4+1”模型為標志出現了從不同側面描述系統的結構模型，以UML為典型代表。出現了程序結構設計主題，以控制流圖和數據流圖構成軟件結構為特征高級階段初期階段軟件體系結構軟件體系結構描述語言ADL提供了具體的語法與刻畫體系結構的概念框架。ADL使得系統開發者能夠很好地描述他們設計的體系結構，以便與他人交流，能夠用提供的工具對許多實例進行分析。1.4體系結構的應用現狀軟件體系結構體系結構描述構造與表示（1）按照一定的描述方法，用體系結構描述語言對體系結構進行說明的結果則稱為體系結構的表示，而將描述體系結構的過程稱為體系結構構造軟件體系結構（1）Kruchten提出的“4+1”模型。（2）Booch從UML的角度給出了一種由設計視圖、過程視圖、實現視圖和部署視圖，再加上一個用例視圖構成的體系結構描述模型。（3）IEEE于1995年成立了體系結構工作組，起草了體系結構描述框架標準IEEEP1471。（4）Rational從資產重用的角度提出了體系結構描述的規格說明框架。軟件體系結構體系結構分析、設計與驗證（1）體系結構分析的內容可分為:結構分析功能分析非功能分析。非功能分析：定量分析方法推斷分析方法。軟件體系結構Kazman等人提出了一種非功能分析的體系結構分析方法SAAM，并運用場景技術，提出了基于場景的體系結構分析方法Barbacci等人提出了多質量屬性情況下的體系結構質量模型、分析與權衡方法ATAM。軟件體系結構體系結構分析、設計與驗證（2）生成一個滿足軟件需求的體系結構的過程即為體系結構設計。體系結構設計過程的本質在于：將系統分解成相應的組成成分（如構件、連接件），并將這些成分重新組裝成一個系統。軟件體系結構體系結構分析、設計與驗證（3）體系結構設計有兩大類方法：過程驅動方法問題列表驅動方法。基于過程驅動的體系結構設計方法適用范圍廣，易于裁減，具備動態特點，通用性與實踐性強。問題列表驅動法的基本思想是枚舉設計空間，并考慮設計維的相關性，以此來選擇體系結構的風格。該方法適用于特定領域，是靜態的，并可以實現量化體系結構設計空間。軟件體系結構體系結構分析、設計與驗證（4）體系結構設計研究的重點內容之一就是體系結構風格或模式。體系結構模式在本質上反映了一些特定的元素、按照特定的方式組成一個特定的結構，該結構應有利于上下文環境下的特定問題的解決。軟件體系結構體系結構分析、設計與驗證（5）體系結構模式分為兩個大類：固定術語參考模型。已知的固定術語類的體系結構模型包括管道過濾器、客戶/服務器、面向對象、黑板、分層、對等模式、狀態轉換、一些派生的固定術語類的體系結構模式，包括GenVoca，C2和REST等；參考模型則相對較多，常常與特定領域相關。軟件體系結構體系結構分析、設計與驗證（6）體系結構測試著重于仿真系統模型，解決體系結構層的主要問題。由于測試的抽象層次不同，體系結構測試策略可以分為單元/子系統/集成/驗收測試等階段的測試策略。在體系結構集成測試階段，Debra等人提出了一組針對體系結構的測試覆蓋標準，PaolaInveradi提出了一種基于CHAM的體系結構語義驗證技術。軟件體系結構體系結構發現、演化與重用（1）體系結構發現解決如何從已經存在的系統中提取軟件的體系結構，屬于逆向工程范疇。Waters等人提出了一種迭代式體系結構發現過程，即由不同的人員對系統進行描述，然后對這些描述進行分類并融合，發現并解除沖突，將體系結構新屬性加入到已有的體系結構模型中，并重復該過程直至體系結構描述充分。軟件體系結構體系結構發現、演化與重用（2）由于系統需求、技術、環境、分布等因素的變化而最終導致軟件體系結構的變動，稱之為軟件體系結構演化。軟件系統在運行時刻的體系結構變化稱為體系結構的動態性，而將體系結構的靜態修改稱為體系結構擴展。體系結構擴展與體系結構動態性都是體系結構適應性和演化性的研究范疇。軟件體系結構體系結構發現、演化與重用（3）體系結構重用屬于設計重用，比代碼重用更抽象。由于軟件體系結構是系統的高層抽象，反映了系統的主要組成元素及其交互關系，因而較算法更穩定，更適合于重用。體系結構模式就是體系結構重用研究的一個成果，而體系結構參考模型則是特定域軟件體系結構的重用的成熟的象征。軟件體系結構基于體系結構的軟件開發方法（1）在引入了體系結構的軟件開發之后，應用系統的構造過程變為“問題定義—>軟件需求—>軟件體系結構—>軟件設計—>軟件實現”，可以認為軟件體系結構架起了軟件需求與軟件設計之間的一座橋梁。軟件體系結構基于體系結構的軟件開發方法（2）軟件開發模型是跨越整個軟件生存周期的系統開發、運行、維護所實施的全部工作和任務的結構框架，給出了軟件開發活動各階段之間的關系。目前，常見的軟件開發模型大致可分為三種類型:（1）以軟件需求完全確定為前提的瀑布模型。（2）在軟件開發初始階段只能提供基本需求時采用的漸進式開發模型，如螺旋模型等。（3）以形式化開發方法為基礎的變換模型。軟件體系結構基于體系結構的軟件開發方法（3）所有開發方法都是要解決需求與實現之間的差距。但是，這三種類型的軟件開發模型都存在這樣或那樣的缺陷，不能很好地支持基于軟件體系結構的開