開始複習《軟體體系結構》，雖然為了考試要背誦的內容比較多，但是從軟體工程到軟體測試，我發現這樣的課程，總可以增強自己的理解能力，更重要的是對於“軟體工程”的認識。天氣炎熱，能靜下心來複習也是一件美好的事情。小毛蟲，加油嘍。

一、軟體危機 software crisis

       軟體危機是指在計算機軟體的開發（development）和維護（maintenance）過程中遇到的一系列嚴重問題。

1.軟體危機的表現（4個）

    1)       軟體成本日益增長

    2)       開發進度難以控制

    3)       軟體質量差

    4)       軟體維護困難

2.軟體危機的成因

    1)       使用者需求不明確

    2)       缺乏正確的理論指導

    3)       軟體規模越來越大

    4)       軟體複雜度越來越高

3、如何克服軟體危機

       人們面臨的不僅是技術問題，更重要的是管理問題。應用現代工程的概念、原理、技術、方法進行計算機軟體的開發、管理和維護。

       軟體工程是用工程、科學、數學的原則與方法研製、維護計算機軟體的有關技術以及管理方法。三要素：方法、工程、過程。

二、構件與軟體重用

1.要提高軟體的開發效率，提高軟體的開發質量，必須採用工程化的開發方法與工業化的生產技術。包括技術和管理兩方面的問題。技術上：基於重用的軟體生產技術；管理上：採用多維的工程管理模式。

2.要真正解決軟體危機，實現軟體工業化生產是唯一可行的途徑，其中構件是核心和基礎，重用是必須手段。

3.軟體重用

定義：

    軟體重用是指在兩次或多次不同的軟體開發過程中重複使用相同或相近軟體元素的過程。

    軟體元素包括程式程式碼、測試用例、設計文件、設計過程、需求分析文件甚至領域知識。通常，把這種可重用的元素稱作軟構件（software component），簡稱構件。可重用的軟體元素越大，我們就說重用的力度越

意義：

        ★提高軟體生產率，降低開發成本；

        ★ 有助於改善質量；

        ★ 提高軟體的靈活性和標準化程度

4.構件

定義：

    語義完整、語法正確和有可重用價值的單位軟體，是軟體重用過程中可以明確辨識的系統；結構上，它是語義描述、通訊介面和實現程式碼的複合體。簡單的說，構件是具有一定的功能，能夠獨立工作或能同其它構件裝配起來協調工作的程式體，構件的使用同它的開發、生產無關。

    構件將抽象的程度提到一個更高的層次，是對一組類的組合進行封裝，並代表完成一個或多個功能的特定服務，也為使用者提供了多個介面。整個構件隱藏了具體的實現，只用介面對外提供服務。

5.構件模型model

定義：

    構件模型是對構件本質特徵的抽象描述。

三大流派：

    （1）OMG（ObjectManagement Group，物件管理集團）的CORBA（Common Object Request BrokerArchitecture，通用物件請求代理結構）

    （2）Sun的EJB（Enterprise Java Bean）

    （3）Microsoft的DCOM（DistributedComponent Object Model，分散式構件物件模型）

國內：青鳥構件模型

6.構件的獲取途徑

    1)       從現有構件中獲得符合要求的構件，直接使用或作適應性修改，得到可重用的構件；

    2)       通過遺留工程，將具有潛在重用價值的構件提取出來，得到可重用的構件；

    3)       從市場上購買現成的商業構件，即COTS（Commercial Off-The-Shell）構件；

    4)       開發新的符合要求的構件。

7.構件的分類方法

    1)       關鍵字分類法 keyword classification

    2)       刻面分類法   faceted classification

    3)       超文字組織方法 hypertext classification

8.構件重用步驟

    1)       檢索與提取構件

    2)       理解與評價構件

    3)       修改構件

    4)       構件組裝

9.構件組裝技術

    1)       基於功能的組裝技術：採用子程式呼叫和引數傳遞的方式將構件組裝起來；

    2)       基於資料的組裝技術：也要求庫中構件以子程式形式出現，但它所依賴的軟體設計方法不再是功能分解，而是面向資料的設計方法；

    3)       面向物件的組裝技術：構造法、子類法。

三、軟體體系結構的發展

    事實上，軟體總是有體系結構的，不存在沒有體系結構的軟體。

1.軟體體系結構的定義

    軟體體系結構為軟體系統提供了一個結構、行為和屬性的高階抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素整合的模式以及這些模式的約束組成。

2.軟體體系結構的意義（需要詳細闡述）

    1)       體系結構是風險承擔者進行交流的手段

    2)       體系結構是早期設計決策的體現

              軟體體系結構明確了對系統實現的約束條件

              軟體體系結構決定了開發和維護組織的組織結構

              軟體體系結構制約著系統的質量屬性

              通過研究軟體體系結構可能預測軟體的質量

              軟體體系結構使推理和控制更改更簡單

              軟體體系結構有助於循序漸進的原型設計

              軟體體系結構可以作為培訓的基礎

    3)       軟體體系結構是可傳遞和可重用的模型

3.軟體體系結構的發展史（四個階段）

    a)        無體系結構設計階段：以組合語言進行小規模應用程式開發為特徵

    b)       萌芽階段：出現了程式結構設計主題，以控制流圖和資料流圖構成軟體結構為特徵

    c)        初期階段：出現了從不同側面描述系統的結構模型，以UML為典型代表

    d)       高階階段：以描述系統的高層抽象結構為中心，不關心具體的建模細節，劃分了體系結構模型與傳統軟體結構的界限，該階段以Kruchten提出的“4+1”模型為標誌

4.軟體體系結構的評價方法

    （1）體系結構權衡分析方法（ATAM方法）architecture tradeoff analysis method

    （2）軟體體系結構分析方法（SAAM方法）software architecture analysis method

    （3）中間設計的積極評審（ARID方法）active reviews for intermediate design