軟件體系結構期末復習
標簽（空格分隔）： 未分類
回顧課本和TTP課件
內容總概
章節回顧
第1章、軟件體系結構概論
0.軟件體系結構的發展過程經歷了四個階段：
(1)無體系結構階段、(2)萌芽階段、(3)初期階段、(4)高級階段
1.軟件重用
軟件重用：也稱為軟件復用，就是利用已開發的且對應用有貢獻的軟件元素來構建新軟件系統。 軟件重用的基本過程：軟件對象的開發、軟件對象的理解和軟件對象的重用。 軟件重用的過程可歸納為：抽象、選取、實例化和集成。 廣義的三個層次：知識重用、方法和標準重用、軟件成分重用。 軟件成分的重用： 源代碼的重用； 目標代碼級重用（以函數庫方式體現）； 設計和分析結果重用（易于移植）； 類的重用； 構件重用
2.構件
軟件構件是將大而復雜的應用軟件分解為一系列可先行實現、易于開發、理解、重用和調整的軟件單元。 構件的分類方式： 構件根據功能用途可分為系統構件 、支撐構件 和領域構件 。 識別技術包括領域分析法、聚類分析法、CRUD分析法、基于穩定性方法等。 構件獲取的主要四種方式 從構件庫 中，按照適合新系統的原則選取，并作適應性修改以獲得可重用的構件。 根據新功能模塊進行自行開發 ，以獲取新構件。 對遺留系統 進行功能分析，將具有潛在應用價值的模塊提取出來，使其接口進行標準化以獲得可重用性構件。 通過商業方式購買 合適的構件，利用互聯網資源進行共享或免費獲取。 構建模型
3.習題
（ 軟件危機 ）主要包含兩方面的問題：如何開發軟件以滿足對軟件日益增長的需求；如何維護數量不斷高速增長的已有軟件。
軟件體系結構的核心模型主要包括：（構件、連接件、配置約束）。
（軟件重用技術）有助于提高軟件開發的生產率，提高軟件系統的可靠性，減少軟件維護的負擔。
（軟件構件技術）是軟件重用的核心與基礎。
基于構件的軟件開發的基本思想是？
第2章 、軟件體系結構建模
1.建模概述
軟件體系結構應該以模型的形式具體化。
2.建模語言
實踐派風格：使用通用的建模符號，強調實踐可行性。
圖形表示方法。 模塊內連接語言。 基于構件的系統描述語言。 UML描述方法。 學院派風格：使用了體系結構描述語言(ADL)，側重于軟件體系結構形式化理論的研究。
ADL集中描述了整個系統的高層結構。 有無工具的支持是ADL是否可用的重要標志。 軟件體系結構模型的三個基本組成成分：構件 、連接件 和配置關系 。 構件 描述規范：(1)接口。(2)類型。(3)語義。(4)約束。(5)演化。(6)非功能特性。連接件 描述規范：考慮的內容與構件相似配置關系 描述規范：可理解性。組合能力。對異構的支持。可伸縮能力。進化能力。動態支持。 體系結構描述語言有
ACME 的基本特征： 提供了基本的體系結構元素來描述系統的體系結構，并提供了相應的擴展機制 。 提供了靈活的注解機制 來描述系統的非結構性信息。 提供了可對軟件體系結構風格進行重用的模板機制 。 提供了一種開放的語義框架 ，可以對體系結構描述進行形式化推理。 Rapide 的五種子語言： 類型(Types)語言——定義接口類型和函數類型，支持通過繼承已有的接口來構造新的接口類型； 模式(Pattern)語言——定義具有因果、獨立和時序等關系的事件所構成的事件模式； 可執行(Executable)語言——包含描述構件行為的控制結構； 體系結構(Architecture)語言——通過定義同步和通信連接來描述構件之間的事件流； 約束(Constraint)語言——定義構件行為和體系結構所滿足的形式化約束，其中約束為需要的或禁止的偏序集模式。 Unicon 的設計緊緊圍繞著構件和連接件 這兩個基本概念。Wright 的主要思想是把連接件定義為明確的、用協議 的集合來表示語義實體 ，協議代表了交互的各個參與角色及其相互作用。Darwin 使用接口來定義構件類型。Aesop 的目標是建立一個工具包，為特定領域的體系結構快速構建提供設計支持環境。SADL 語言提供了軟件體系結構的文本化表示方法，同時保留了直觀的線框圖模型。MetaH 主要支持實時、容錯、安全、多處理和嵌入式軟件系統的分析、驗證以及開發。 UML與ADL之間的關系
體系結構描述語言ADL是一種描述體系結構模型的形式化工具。 ADL是研究軟件體系結構規范的出發點。 統一建模語言(Unified Modeling Language，UML)是一個通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統的文檔。 基于UML的軟件體系結構描述
UML應用于用例驅動的、以體系結構為中心的、迭代的和漸增式的開發過程。
Kruchten提出了“4+1”視圖模型 “。
邏輯視圖，也稱概念視圖。主要支持系統功能需求的抽象描述。 開發視圖，也稱模塊視圖。主要側重于描述系統的組織。 過程視圖。主要側重于描述系統的動態屬性。 物理視圖。主要描述如何把軟件映射到硬件上。 場景視圖。場景是用戶需求和系統功能實例的抽象。 邏輯視圖定義了系統的目標；開發視圖和過程視圖提供了詳細的系統設計實現方案；物理視圖解決了系統的拓撲結構、安裝和通信問題；場景反映了完成上述任務的組織結構。
UML視圖和圖
主要的域 視圖 圖 主要概念 結構 靜態視圖 類圖 類、關聯、泛化、依賴關系、實現、接口 用例視圖 用例圖 用例、參與者、關聯、擴展、包括、用例泛化 實現視圖 構件圖 構件、接口、依賴關系、實現 部署視圖 部署圖 節點、構件、依賴關系、位置 動態 狀態視圖 狀態圖 狀態、事件、轉換、動作、 活動視圖 活動圖 狀態、活動、完成轉換、分叉、結合 交互視圖 順序圖 交互、對象、消息、激活 協作圖 協作、交互、協作角色、消息 模型管理 模型管理視圖 類圖 報、子系統、模型 可擴展性 所有 所有 約束、構造型、標記值
3.基于UML體系結構描述方式的案例分析
圖書管理系統實驗
4.軟件體系結構的生命周期
具體的軟件體系結構的設計包括非形式化描述、規范描述、求精及驗證、實施、改革或擴展、評估和度量以及終結 等七個階段
5.基于體系結構的軟件開發過程
6.習題
軟件架構是降低成本、改進質量、按時和按需交付產品的關鍵因素。以下關于軟件架構的描述，錯誤的是（A）。 下面哪種視圖不屬于軟件體系結構中定義的“4+1”視圖?（B） 在RUP （Rational Unified Process，統一軟件開發過程）中采用“4+1”視圖模型來描述軟件系統的體系結構。在該模型中，最終用戶側重于（C），系統工程師側重于（D）。 在基于構件的軟件開發中，（ A）描述系統設計藍圖以保證系統提供適當的功能；（B ）用來了解系統的性能、吞吐率等非功能性屬性。
第3章 、軟件體系結構風格
1.軟件體系結構風格概述
軟件體系結構的核心模型：（構件、連接件、配置約束 ） 軟件框架設計的核心問題 是：能否達到成型的體系結構 方案級別的重用。（架構級別的重用）
2.常用的軟件體系結構風格
軟件體系結構風格的定義：由組織規則及結構構成，是描述領域中系統組織方式的慣用模式。是對某一特定領域中系統所共有的結構和語義特性的反映。
體系結構風格的分類：
數據流風格：
批處理序列 管道/過濾器（傳統的編譯器） 包括過濾器和管道兩種元素。基本單元如圖： 管道/過濾器風格的系統架構圖如下圖所示： 優點： 設計人員將整個系統的輸入輸出行為理解為單個過濾器行為的疊加與組合。 任何兩個過濾器，只要它們之間傳送的數據遵守共同的規約就可以相連接。 整個系統易于維護和升級 。 支持并發 執行。缺點： 通常導致進程成為批處理的結構； 不適合處理交互 的應用；每個過濾器都增加了解析和合成數據 的工作，導致系統功能下降 ； 其固有結構，決定了很難制定錯誤處理 的一般性策略。 傳統的編譯器 編譯器由詞法分析、語法分析、語義分析、中間代碼生成、中間代碼優化和目標代碼生成組成，如圖： 調用/返回風格：
主程序/子程序
面向對象風格
將系統組織為多個獨立的對象，每個對象封裝其內部的數據，并基于數據對外提供服務。不同對象之間通過協作機制共同完成系統任務。面向對象體系結構如圖所示： 重要設計決策及約束： 依照對數據的使用情況，用信息內聚的標準，為系統建立對象部件。每個對象部件基于內部數據提供對外服務接口，并隱藏內部數據的表示。 基于方法調用（Method Invocation）機制建立連接件，將對象部件連接起來 每個對象負責維護其自身數據的一致性與完整性，并以此為基礎對外提供“正確”的服務。 每個對象都是一個自治單位，不同對象之間是平級的，沒有主次、從屬、層次、分解等關系。 優點： 缺點： 層次結構
層次風格組織成一個層次結構，通過分解，能夠將復雜系統劃分為多個獨立的層次，每一層都具有高度的內聚性，并要求每一層為上層服務，并作為下層的客戶，較高層面向特定應用問題，較低層則更具有一般性。如圖：
優點：
支持基于抽象程度遞增的系統設計。 支持功能增強。 支持重用。 提高了系統的可變性、可維護性、可靠性和可重用性。 典例：OSI指定的分層通信協議，計算機網絡的TCP/IP協議、操作系統和數據庫系統。
虛擬機構格：
解釋器 解釋器系統由四個部分組成：被解釋的程序、執行引擎、被解釋程序的當前狀態和執行引擎的當前狀態。解釋器的框架如圖所示: 例子(手機瀏覽器)如圖所示： 優點： 能夠提高應用程序的移植能力和編程語言的跨平臺移植能力。 實際測試工作可能非常復雜，測試代價及其昂貴，具有一定的風險型。但可以利用解釋器對未實現的硬件進行仿真。 缺點： 由于使用了特定語言和自定義操作規則，增加了系統運行的開銷。 解釋器系統難以設計和測試。 基于規則的系統 C/S體系結構風格
客戶機/服務器(C/S)就是Client/Server模式，針對資源不對等問題而提出的一種共享策略。C/S結構通過將任務合理分配到Client端和Server端，降低了系統的通訊開銷，充分利用兩端硬件環境的優勢。
C/S主要包括三個部分：數據庫服務器、客戶機和網絡。
對于數據庫應用程序，DBMS可以為應用程序提供針對底層結構的管理。應用的服務器部分是運行在遠程主機上的數據庫引擎。而該應用的客戶部分則是運行在本地計算機上的數據庫查詢程序，它們之間的通信是借助于DBMS提供的網絡協議實現的。如下圖所示：
兩層C/S體系結構的處理流程如下圖：
C/S暴露出的不足：
開發成本較高。 在開發C/S結構系統時，大部分工作都集中在客戶機程序的設計上，增加了設計的復雜度。 信息內容和形式單一。 如果對C/S體系結構的系統進行升級，開發人員需要到現場來更新客戶機程序，同時需要對運行環境進行重新配置，增加了維護費用； 兩層C/S結構采用了單一的服務器，同時以局域網為中心，因此難以擴展到Intranet和Internet； 數據安全性不高。 三層C/S體系結構：將客戶機和服務器中的部分業務邏輯抽取出來，形成功能層，放在應用服務器上。
三層C/S結構同樣包括客戶機、應用服務器和數據庫服務器三個部分。三層C/S體系結構如圖所示：
三層C/S結構體系結構的處理流程如下圖所示:
中間件是客戶從服務器獲得服務的粘合劑。它的引入使原來較為簡單的兩層分布模型(客戶-服務器)被更加精確的三層模型(客戶-中間件-服務器)所替代。如圖：
B/S體系結構風格
瀏覽器/服務器結構(Browser/Server)B/S體系結構如圖所示：
在B/S結構模式中，數據庫是存儲數據的主要場所。B/S結構模式如下圖所示：
B/S結構的一個典型的例子是教務在線管理平臺的系統架構，如下圖所示：
優點：
系統開發、維護和升級方便且經濟。 具有很強的開放性。 具有易擴展性。 用戶界面的一致性。 具有更強的信息系統集成性。 提供靈活的信息交流和信息發布服務。 C/S 與 B/S 區別
硬件環境不同： B/S 建立在廣域網之上的， 不必是專門的網絡硬件環境，而C/S 一般建立在專用的網絡上，局域網之間再通過專門服務器提供連接和數據交換服務。 對安全要求不同：C/S 一般面向相對固定的用戶群， 對信息安全的控制能力很強。 一般高度機密的信息系統采用C/S 結構適宜，可以通過B/S發布部分可公開信息。 B/S 建立在廣域網之上， 對安全的控制能力相對弱， 面向是不可知的用戶群。 用戶接口不同 ：C/S 多是建立在Window平臺上，表現方法有限，對程序員普遍要求較高。 B/S 建立在瀏覽器上， 有更加豐富和生動的表現方式與用戶交流， 并且大部分難度減低，降低開發成本。 獨立構件風格：
進程通迅
事件驅動體系結構風格
事件驅動架構是由一系列的系統組件構成的，組件之間共同作用完成系統的功能。如圖所示，這些組件之間的聯接是管道化的和多模塊化的，通過形成并發的事件流對企業業務事件進行處理。
事件驅動架構的組成如圖所示：
將這些不同的組件細分為五類：
事件元數據：用來實現事件定義和事件處理規則預定義。 事件處理：包括事件處理引擎和事件處理對象實例兩部分。事件處理引擎按照所處理的事件類型分為簡單事件處理和復雜事件處理兩種。 事件工具：由事件開發工具和事件管理工具兩種組成。 企業系統集成：事件驅動架構中為了實現架構與現有系統的融合與事件的提取傳遞，必須有一個聯接樞紐，這就是企業系統集成。 事件資源：事件驅動架構是在現存的企業資源的基礎上建立的，包括企業已有的各種資源、如業務數據、數據倉庫、服務、現有系統等。這是企業事件的來源和基礎，為事件驅動的后續動作提供基礎事件數據。 優點：
事件聲明者不需要知道哪些構件會響應事件，因此，不能確定構件處理的先后順序，甚至不能確定事件會引發哪些過程調用。 提高了軟件重用能力。只要在系統事件中注冊構件，就可以將該構件集成到系統中。 便于系統升級。只要構件名和事件中所注冊的過程名保持不變，原有構件就可以被新構件所替代。 缺點：
數據共享體系結構風格（倉庫風格）
數據庫系統
超文本系統
黑板系統
優點
便于多客戶共享大量數據，而不必關心數據是何時產生的、由誰提供的以及通過何種途徑來提供。 便于將構件作為知識源添加到系統中來。 現代編譯器就是黑板體系結構的風格，如圖：
C2體系結構風格
C2風格用來設計具有用戶界面的應用程序，用戶界面軟件常常可以看作由大量應用軟件片段所組成，是基于構件和消息的架構風格。架構風格如圖： 構件連接：一個構件的“頂部”或“底部”可以連接到一個連接件的“底部”或“頂部”；對于一個連接件，和其相連的構件或連接件的數量沒有限制，但是構件和構件之間不能直接相連。消息類型是向上發送的請求信息和向下發送的通知消息兩種。 MVC體系結構風格
MVC模式屬于結構型設計模式，即將應用類和對象組合獲得比較復雜的結構。它是第一個將表示邏輯和業務邏輯分開的設計模式。MVC設計模式的出現使得模型層、視圖層和控制層各層層次分明，各個模塊之間相互獨立，提高了靈活性。 MVC： 視圖(View)：代表用戶交互界面，對于Web應用來說，可以概括為HTML界面，但也有可能為XHTML、XML和Applet。 模型(Model)：就是業務流程狀態的處理以及業務規則的制定。 控制器(Controller)：可以理解為從用戶接收請求，將模型與視圖匹配在一起，共同完成用戶的請求。 MVC模式的目的就是實現Web系統的職能分工。 反饋控制環體系結構風格
從過程控制的角度來分析和解釋構件之間的交互，同時，應用這種交互來改善系統性能。如圖： 反饋控制環結構能夠處理復雜的自適應問題，如機器學習。機器學習模型如圖所示： 公共對象請求代理體系結構風格
CORBA ：公共對象請求代理(CORBA)是由對象管理組織(OMG)提出來的，是一套完整的對象技術規范，其核心包括標準語言、接口和協議。在異構分布式環境下，可以利用CORBA來實現應用程序之間的交互操作，同時，CORBA也提供了獨立于開發平臺和編程語言的對象重用方法。對象管理組織由5個部分組成：對象請求代理(ORB)、對象服務、通用設施、域接口和應用接口。最核心的部分是對象請求代理實現客戶和服務對象之間的通信交互 。 CORBA系統的體系結構圖： CORBA體系結構風格具有以下優點： 實現了客戶端程序與服務器程序的分離。 將分布式計算模式與面向對象技術結合起來，提高了軟件重用效率。 提供了軟件總線機制，軟件總線是指一組定義完整的接口規范。 CORBA能夠支持不同的編程語言和操作系統，在更大的范圍內，開發人員能夠相互利用已有的開發成果。 Garlan和Show對體系結構的分類圖：
3.新型體系結構風格
正交軟件體系結構風格
正交軟件體系結構由組織層和線索的構件構成。 特征： 由完成不同功能的n(n>1)個線索(子系統)組成； 系統具有m(m>1)個不同抽象級別的層； 線索之間是相互獨立的(正交的)； 系統有一個公共驅動層(一般為最高層)和公共數據結構(一般為最低層)。 構件：構件是一個計算單元或數據存儲。也就是說，構件是計算與狀態存在的場所。 線索：線索是子系統的特例，它是由完成不同層次功能的構件組成(通過連接件來關聯)。 正交軟件體系結構的核心模型如圖： RIA(Rich Internet Application) 體系風格
RIA 將桌面型計算機軟件應用的最佳用戶界面功能性與Web應用程序的普遍采納和低成本部署以及互動多媒體通信的長處集于一體，可以提供更直觀、響應更快和更有效的用戶體驗，簡化并改進了Web應用程序的用戶交互。它不僅具備了桌面型系統的長處，包括在確認和格式編排方面提供互動用戶界面、在無刷新頁面之下提供快捷的界面響應時間、提供通用的用戶界面特性，而且保留了Web的優點，并且支持雙向互動聲音和圖像。 RIA應用程序的層次模型如圖： 優點： 強交互性。RIA支持豐富的UI組件。 直接管理。局部的數據更新，通過客戶端計算可直接實現對用戶請求的響應。 多步驟處理。所有內容在一個界面中添加轉換效果，使應用程序的狀態在各步驟中輕松移動。 文本獨立性。RIA集成XML特性，簡化異質系統的通信，方便數據的存取。 平臺無關性。應用層次對所有RIA客戶端都是一致的。 典例：Ext/ExtJS REST軟件體系結構風格
表述性狀態轉移(REST)是Roy Fielding在他的博士論文中發明的一個新名詞，是對Web體系結構設計原則的一種描述。如圖： 設計準則： 網絡上的所有事物都被抽象為資源； 每個資源對應一個唯一的資源標識符； 通過通用的連接器接口對資源進行操作； 對資源的各種操作不會改變資源標識符； 所有的操作都是無狀態的； REST強調中間媒介的作用。 優點： 統一接口，簡化了對資源的操作； REST的無狀態性提高了系統的伸縮性(無狀態性使得服務器端可以很容易的釋放資源， 為服務器端不必在多個Request中保存狀態)和可靠性(無狀態性減少了服務器從局部錯誤中恢復的任務量)； 基于緩存機制，提高了系統的處理性能和負載量； RESTfulWeb 服務是符合REST風格的輕量級Web服務架構，它以完成業務為目標，將一切與業務相關的事物抽象為資源，并為每個資源賦予一個URI標識，用戶在提交請求時，將作用域信息置于URI中，并且使用不同的HTTP方法提交請求，即可對該URI代表的資源執行相關操作，其中常見的HTTP方法為POST、GET、PUT 和DELETE，對應資源的創建、讀取、更新和刪除操作，簡稱CRUD 操作。如圖： 插件體系結構風格以
插件風格結構如圖 優點： 實現真正意義上的軟件部件的“即插即用”； 在二進制級上集成軟件，避免重新編譯內核功能，方便功能擴展和升級； 能夠很好實現軟件模塊的分工和分期開發； 面向服務(Service Oriented Architecture，SOA)軟件體系結構風格
服務是一種粗粒度、可發現、松耦合、自治的分布式組件。 SOA是通過一定的原則來組合一系列可以相互交互的服務進行軟件應用開發的一種架構解決方案。SOA本身不是一種具體的技術，而是一個組件模型，一種架構風格。
4.習題
下列哪個選項是描述系統的靜態結構( A)
Unicon提供了一組預先定義的構件和連接件，這是為了達到（ A）
下列選項中關于ADL與其他語言的比較說法中錯誤的是（ B）
軟件架構模式描述了如何將各個模塊和子系統有效地組織成一個完整的系統。諸如Word和Excel這類圖形界面應用軟件所采用的架構模式是(D )。
為了解決C/S模式中客戶機負荷過重的問題，軟件架構發展形成了（C ）模式。
與基于C/S架構的信息系統相比，基于B/S架構的信息系統（C ）。
軟件重用長期以來一直是軟件工程界不斷追求的目標。（√)
軟件體系結構的核心由5種元素組成：構件、連接件、配置、端口和角色。其中，構件、連接件和配置是最基本的元素（√）
體系結構設計是整個軟件生命周期中關鍵的一環，一般在需求分析之前進行。(×)（需求分析之后，軟件設計之前）
基于事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。(√)
層次系統中支持抽象程度遞增的系統設計是設計師可以把一個復雜系統按照遞增的步驟進行分解，同時支持功能增強，但是不支持重用。(×)
正交軟件體系結構由組織層和線索的構件構成。(√)
SOA模型具有松散耦合、細粒度服務、標準化接口等特征。(×)（粗粒度，SOA是一個組件模型）
層次系統最廣泛的應用是分層通信協議。(√)
MVC模式的中的M，V，C分別對應Model，View，Controller 三種單詞。
黑板系統主要由知識源 、黑板 和控制組件 組成。
什么是軟件體系結構風格？答：軟件體系結構風格是描述某一特定領域中系統組織方式的慣用模式。
請設計一個具體B/S結構登錄模塊的體系結構，并說明每層的作用：
第一層：客戶層（或表現層、界面層），第二層：業務邏輯層（或應用層、功能層、應用服務器層），第三層：數據層。
第一層只有瀏覽器，通過訪問第二層的網頁實現用戶界面，即接受用戶的名稱、密碼的輸入，并向第二層傳送用戶名和密碼，最后將登錄結果顯示出來；
第二層接受第一層的用戶名和密碼，并通過訪問第三層判斷用戶合法性，最后將登錄結果以網頁形式返回給第一層；
第三層在數據庫或文件中存儲用戶名和密碼，并為第二層提供數據訪問服務。
第4章 、特定領域的軟件體系結構
1特定領域軟件體系結構概述
特定領域軟件體系結構(DSSA)的設計是系統級軟件重用 的主要研究內容之一
2 DSSA的定義及組成
DSSA就是在一個特定應用領域中為一組應用提供組織結構參考的標準軟件框架。 DSSA的定義： DSSA是軟件構件的集合 ，以標準結構組合而成，對于一種特殊類型的任務具有通用性，可以有效地、成功地用于新應用系統的構建。在該定義中，構件 是指一個抽象的具有特征的軟件單元 ，它能為其他單元提供相應的服務。 DSSA是問題元素和解元素的樣本，同時給出了問題元素和解元素之間的映射關系。 DSSA的特征 是對整個領域適度的抽象； 具有嚴格定義的問題域或解決方案域； 具備該領域固有的、典型的在開發過程中可重用元素； 具有普遍性，即可用于領域中某個特定應用的開發。 領域模型是DSSA的關鍵部分，它描述了領域內系統需求上的共性。如圖： DSSA包含兩個過程，即領域工程和應用工程。
3 特定領域軟件體系結構的領域工程
領域工程有助于解決可重用信息的識別 、組織和利用的問題，有助于產生具有較高可重用性的構件，對開發者重用構件提供了有力的支持。
領域分析(Domain Analysis) 含義是指識別、捕獲和組織特定領域中一類相似系統的對象及操作等可重用信息的過程，其目標是 支持系統化的軟件重用 ，主要目標是建立領域模型 。領域設計 是領域工程的第二個階段，此階段的主要目標是針對領域分析階段獲得的對目標領域的問題域系統責任的認識，相應的設計模型的開發 ，應該緊緊地圍繞著領域模型 展開領域設計。領域實現 的主要目標是根據領域模型、DSSA來開發和組織可重用軟件元素 。4 特定領域軟件體系結構的應用工程
應用工程 是在領域工程基礎上，針對某一具體應用所實施的開發過程。應用工程是對領域模型的實例化過程 ，可以為單個應用設計提供最佳的解決方案。 應用工程可以劃分為應用系統分析、應用系統設計和應用系統實現與測試三個階段。
5 DSSA的生命周期
軟件開發生命周期，如圖：
特定領域軟件體系結構的雙生命周期模型，如圖：
6 特定領域軟件體系結構的建立
DSSA領域分析的過程框架，如圖：
7 基于特定領域軟件體系結構的開發過程
基于DSSA的應用開發步驟及其相關的支持工具如下圖：
基于DSSA的應用開發過程分為兩個步驟，如圖：
DSSA和應用系統架構之間的關系，如圖：
在整個生命周期中，特定領域軟件體系結構 和可重用構件 始終是開發過程中的核心內容。基于DSSA的開發過程，如圖：
8 特定領域軟件體系結構對軟件開發的意義
具有更好的可操作性和可行性。 基于DSSA的開發方法更高效、更實用。 DSSA開發方法使軟件項目投資的成本最小化。 對領域進行建模，吸納更多的領域知識，為特定應用的求解提供信息源。 領域分析過程化，有利于對分析過程進行動態建模，便于DSSA的更新與完善。
第5章、Web Services與SOA
1 Web Services概述
W3C將Web Services定義為：Web Services是為實現跨網絡操作 而設計的軟件系統，目標是消除語言差異、平臺差異、協議差異和數據結構差異 ，成為不同構件模型和異構系統之間的集成技術 。
2 Web Services技術
優點 良好的封裝性、開放性、維護性和伸縮性。 高度的集成性、跨平臺和語言獨立性。 自描述和發現性以及協議通用性。 協約的規范性。 松散的耦合性。 Web Services體系結構模型描述了三種角色，包括服務提供者、服務注冊中心和服務請求者，定義了三種操作，即查找服務、發布服務和綁定服務，同時給出了服務和服務描述兩種操作對象。 如圖： 發布服務 ：服務提供者定義了Web Service描述，在服務注冊中心上發布這些服務描述信息。查找服務 ：服務請求者使用查找服務操作從本地或服務注冊中心搜索符合條件的Web Service描述，可以通過用戶界面提交，也可以由其他Web Service發起。綁定服務 ：一旦服務請求者發現合適的Web Service，將根據服務描述中的相關信息調用相關的服務。Web Services的執行過程，如圖： Web Services協議棧體系結構圖，如圖： Web Services工作機制 ： Web Services主要采用可擴展標記語言XML、簡單對象訪問協議SOAP、Web Services描述語言WSDL、統一描述、查找和集成協議UDDI、Web Services流程語言WSFL以及業務流程執行語言BPEL等核心技術。 XML是Web Services進行數據交換時所采用的標準，同時也是Web Services技術的全部規范和技術基礎。 SOAP是以XML為基礎，獨立于編程語言和操作平臺，交換結構化信息的輕量級協議。 一個WSDL文檔將服務定義為一個網絡端點或端口的集合。 UDDI 是一套Web服務信息注冊標準規范，信息注冊中心通過實現這套規范開放各個Web Services的注冊和查詢服務。
3 SOA
SOA的實質就是將系統模型與系統實現分離 ，SOA覆蓋了軟件開發的整個生命周期，包括軟件建模、開發、整合、部署、運行等環節。工作原理如圖： SOA是一種軟件系統架構，而不是一種計算機語言，也不是一種具體的技術，更不是一種產品。 服務是SOA實現的核心，SOA的基本元素是服務。 SOA的三個抽象級別 操作 ：代表單個邏輯工作單元（LUW）的事務。執行操作通常會導致讀、寫、或修改一個或多個持久性數據。服務 ：代表操作的邏輯分組。服務可以分層，以降低耦合度和復雜性。一個服務粒度的大小和系統的性能息息相關。業務流程 ：業務流程是為了實現特定的業務目標而執行的一組長期運行的動作或者活動。在SOA中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。SOA的優點 具有良好的平臺無關性、可適應性和可擴展性。 技術與業務對齊，更好的集成效果、更好的定價和銷售模式。 減少系統耦合，提高系統的復用粒度，降低開發成本。 使企業的信息化建設真正以業務為核心，業務人員根據需求編排服務，而不必考慮技術細節。 SOA的缺點與問題 降低了系統的性能。 服務的劃分和編排困難。 如果選擇的接口標準有問題，會帶來系統的額外開銷，并因此而最終導致整個系統不穩定性的增加。 對IT硬件資源并沒有重用。 目前主流實現方式接口很多，從而比較松散、脆弱。 目前主流實現方式只局限于不帶界面的服務共享。從業務角度思考，能共享的應該不僅僅局限在服務層面。 SOA和Web Services的關系 SOA不是Web Services，Web服務是技術規范，而SOA是設計原則； SOA本質上是一種將軟件組織在一起的抽象概念，依賴于XML和Web Services等更加具體的實現技術； Web Services是SOA的一個特定實現。 Web Services是實現SOA的最好方式，但SOA的實現并不僅僅局限于Web Services。
4 網格服務體系結構
網格技術的權威Ian Foster將網格體系結構定義為“劃分系統基本組件，指定系統組件的目的與功能，說明組件之間如何相互作用的技術”。
五層沙漏結構 五層沙漏體系結構由構造層、連接層、資源層、匯聚層和應用層等五層組成。 資源層和連接層共同組成瓶頸部分，形成核心層，促進資源共享。 開放網格服務體系結構(Open Grid Service Architecture，OGSA) Web服務資源框架(Web Service Resource Framework，WSRF)
5 Web Services實現技術
Web Services不僅提供了基于http協議的組件服務，作為分布式應用程序的發展趨勢，它已經成為一種標準。 Web Services表現出了比較好的平臺無關性，很多語計算機語言都針對Web Services開發提供了具體的實現方法。 .net實現(開發環境：Visual Studio) JavaEE實現(開發環境：Eclipse+Apache CXF框架)
6 習題
【問題1】
開發人員不需要重新設計業務模式，是需要在原有系統的界面和中間層添加Web Services，可以繼承原有系統的所有業務。
節約了開發的時間和工作量，將系統升級。
可以不修改原有的Web服務和中間層，可以直接擴展新的服務。
【問題2】
WSDL:是Web Services的描述語言，描述Web Services的服務，接口綁定等信息，為用戶提供詳細的接口說明書；
SOAP:是通信協議，以服務的方式發布有用的程序模塊。
UDDI:提供統一的發布、查找、定位WebServices的方法。
【問題3】
? 在Web Service模型的解決方案中，服務提供者定義并實現Web Service,使用服務描述語言（WSDL）描述Web Service，然后將服務描述發布到服務請求或者服務注冊中心；服務請求這使用查找操作從本地或者服務注冊中心檢索服務描述，然后使用服務描述與服務提供者進行綁定并調用Web Service.服務注冊中心是整個模型中的可選角色，它是連接服務提供者和服務請求者的紐帶
# 第6章、軟件演化技術
# 第7章、軟件產品線
第8章、軟件體系結構評估
1 軟件體系結構評估
軟件體系結構評估，是對系統的某些值得關心的屬性(性能、可修改性、可靠性等)進行評價和判斷。目的 是為了識別體系結構設計中的潛在風險 。
2 評估技術
詢問技術。用于生成一個體系結構將要問到的質量問題，可適用于任何質量屬性，并可用于對開發中任何狀態的任何部分進行調查。 度量技術。采用某種工具對體系結構進行度量。
3 基于場景的軟件體系結構評估方式
三種軟件體系結構評估方式
基于問卷調查或檢查表 的軟件體系結構評估方式
基于場景 的軟件體系結構評估方式
基于場景的方式由SEI首先提出并應用在SAAM 和ATAM 中
基于度量和預測 的軟件體系結構評估方式
4 基于場景的軟件體系結構評估方法
SAAM SAAM (Scenario-based Architecture Analysis Method)主要分析體系結構的可修改性 ；也可以對系統屬性 及系統功能 進行快速評估。 SAAM評估步驟 SAAM 的評估包括六個活動： 場景形成 。通過集體討論, 風險承擔者提出反映自己需求的場景。SA 描述 。SAAM 定義了功能性、結構和分配三個視角來描述SA。場景的分類 。在分析過程中需要確定一個場景是否需要修改該體系結構。不需要修改的場景稱為直接場景, 需要修改的場景則稱為間接場景。另一方面需要對場景設置優先級,以保證在評估的有限時間內考慮最重要的場景。單個場景的評估 。主要針對間接場景, 列出為支持該場景所需要對體系結構做出的修改, 并估計出這些修改的代價。而對于直接場景只需弄清體系結構是如何實現這些場景的。場景交互的評估 。兩個或多個間接場景要求更改體系結構的同一個組件就稱為場景交互。對場景交互的評估, 能夠暴露設計中的功能分配。總體評估 。按照相對重要性為每個場景及場景交互設置一個權值, 根據權值得出總體評價。ATAM 體系結構權衡分析法ATAM (Architecture Trade of Analysis Method) 方法是SEI于2000年在SAAM方法基礎上提出的，它考慮了可修改性、性能、可靠性和安全性等多種質量屬性 ，并能確定這些相互制約屬性之間的折中點 。 ATAM 評估方法包括4個部分，分為9個步驟： 表述，分三個步驟： ATAM方法表述 商業動機表述 軟件體系結構表述 調查分析，包括三個步驟 確定軟件架構的方法 生成質量效用樹 分析軟件架構方法 測試，包括兩個步驟 集體討論并確定場景的優先級 分析軟件體系結構方法 形成報告 質量效用樹
5 習題
特定領域軟件架構（DSSA)是在一個特定應用領域為一組應用提供組織結構參考的標準軟件架構。實施DSSA的過程包括一系列基本活動，其中（C）活動的主要目的是為了獲得DSSA。該活動參加人員中，（A）的主要任務是提供關于領域系統的需求規約和實現的知識。
某服務器軟件系統能夠正確運行并得出計算結果，但存在“系統出錯后不能在要求的時間內恢復到正常狀態”和“對系統進行二次開發時總要超過半年時間”兩個問題，上述問題依次與質量屬性中的（D ）相關。
計算機系統的可用性可從多個方面來評測，但不包括（ C ）。
以下關于系統性能的敘述中，不正確的是（ A ）
“系統在提供服務給合法用戶的同時抵制未授權使用的能力”這是哪種質量屬性關心的問題：(D)
某網上購物電子商務公司擬升級正在使用的在線交易系統，以提高用戶網上購物在線支付環節的效率和安全性。在系統的需求分析與架構設計階段，公司提出的需求和關鍵質量屬性場景如下：
【問題1】
答案：a:可修改性、b:可用性、c:6、d:12、e:8、f:2
【問題2】
在架構評估過程中，需要正確識別系統的架構風險、敏感點和權衡點，并進行合理的架構決策。請給出系統架構風險、敏感點和權衡點的定義，并從題干1-13中各選出1各對系統架構風險、敏感點和權衡點最恰當的描述。
答案：系統架構風險：是指架構設計中潛在的、存在問題的架構決策所帶來的隱患；11描述的是架構風險
敏感點：是指為了實現某種特定的質量屬性，一個或多個系統組件所具有的特性；3描述的是敏感點
權衡點：是指影響多個質量屬性，并對多個質量屬性來說都是敏感點的系統屬性；7描述的是權衡點。
第10章 、云計算
1 云計算服務的分類
?
將基礎設施作為服務(Infrastructure as a Service，IaaS ) 將云計算軟件開發平臺作為服務(Platform as a Service，PaaS ) 將軟件作為服務(Software as a Service，SaaS )
2 云計算的體系結構
服務管理中間件層和虛擬化資源層是云計算技術的核心部分 。 云計算核心技術 Google云計算核心技術 分布式海量數據存儲技術 分布式海量數據編程模型 分布式海量數據的鎖服務 分布式海量數據管理技術
3 習題
云計算的計算模式為( D ).
A W/S B C/S C B/S D B/C
（ B ）是公有云計算基礎架構的基石。
A 虛擬化 B 分布式 C 并行 D 集中式
（ A ）是私有云計算基礎架構的基石。
A 虛擬化 B 分布式 C 并行 D 集中式
網格計算是利用（ B ）技術，把分散在不同地理位置的計算機組成一臺虛擬超級計算機。
A 對等網 B 因特網 C 廣域 D 無線網
云計算就是把計算資源都放到（ B )
A 對等網 B 因特網 C 廣域 D 無線網
用戶可通過（ A ）從列表中選擇所需的服務，其請求通過管理系統調度相應的資源，并通過部署工具分發請求、配置Web應用。
A 云用戶端 B 服務目錄
C 管理系統和部署工具D 監控端
SaaS是（ 軟件即服務 ）的簡稱。
PAAS是（ 平臺即服務 ）的簡稱
IaaS是（ 基礎設施即服務 ）的簡稱。
A 軟件即服務 B 平臺即服務
C 基礎設施即服務D 硬件即服務
云計算是對分布式處理（DistributedComputing）、并行處理（Parallel Computing）和網格計算（Grid Computing）及分布式數據庫的改進處理。（ √ ）
利用并行計算解決大型問題的網格計算和將計算資源作為可計量的服務提供的公用計算，在互聯網寬帶技術和虛擬化技術高速發展后萌生出云計算。（ √ ）
云計算的基本原理為：利用非本地或遠程服務器（集群）的分布式計算機為互聯網用戶提供服務（計算、存儲、軟硬件等服務）。（ √ ）
云計算可以把普通的服務器或者PC連接起來以獲得超級計算機的計算和存儲等功能，但是成本偏高。 （ × ）
云計算真正實現了按需計算，從而有效地提高了對軟硬件資源的利用效率。 （ √ ）
云計算模式中用戶不需要了解服務器在哪里，不用關心內部如何運作，通過高速互聯網就可以透明地使用各種資源。（ √ ）
Amazon EC2在基礎設施云中使用公共服務器池。 （ √ ）
所謂“云”計算就是一種計算平臺或者應用模式。（ × ）
總習題
軟件重用是為了解決 _____ 軟件危機 _。
綜合各種不同軟件體系結構定義，認為軟件體系結構主要包括_____構件、連接件和配置約束 _ 3個部分。
軟件體系結構應建立于傳統的軟件開發過程的需求分析 和軟件設計 階段之間。
體系結構評估中，一般采用刺激 ，環境 ，和響應 三方面來對場景進行描述。
UML是一種通用的面向對象的建模語言，在很大程度上獨立于建模過程，在實際的應用中，建模人員往往把UML應用于__用例__ 驅動的、以__體系結構__ 為中心的， 迭代的__和__漸增式 的開發過程。
Kruchten提出了“4+1”視圖模型，從5個不同的視角來描述軟件體系結構，這5個視角包括邏輯視圖、開發視圖、過程視圖、物理視圖、場景視圖 。
黑板系統主要由知識源 、黑板 和控制組件 組成。
三層C/S結構風格是由表示層 、功能層 和 數據層 構成的。
領域工程階段的主要任務有領域分析 、領域設計 和領域實現 三個階段。
XML 是Web Services進行數據交換時所采用的標準，同時也是Web Services技術的全部規范和技術基礎。SOAP、WSDL、UDDI都是使用它進行描述的。
理解SOA和Web Service關系上， SOA 所表示的是一個概念模型，Web Service 是SOA的一個特定實現。
SAAM評估方法可以對許多__質量屬性__以及__系統功能__進行快速評估。
體系結構評估中一般采用___刺激__ 、環境 和__響應___三方面來對場景進行描述。
考試題型
填空（20分） 選擇（30分） 判斷（20分） 簡答題（10分） 問答題（10分） 分析題（10分）
考點
第1章 軟件體系結構概論 軟件體系結構產生背景 軟件重用的定義 了解軟件重用類型及軟件成分重用的形式 主流的核心模型 （本書定義的）軟件構件的定義 基于構件的軟件開發思想 第2章 軟件體系結構建模 了解什么是ADL，廣泛使用的ADL有哪些？（ACME） 描述體系結構的兩種方法：實踐派、學院派； 了解ACME 的基本特征； 簡單了解UML與ADL的關系； 掌握Kruchten提出了**“4+1”視圖模型**，包括組成要素和各要素的特點 ； 簡單了解基于體系結構的軟件開發過程 第3章 軟件體系結構風格 軟件體系結構風格的定義 ； 各種風格的優缺點和應用場合 （課堂上講過的） 第4章 特定領域軟件體系結構 理解DSSA定義 ； 了解DSSA具有的特征； 了解DSSA包含的兩個過程：領域工程與應用工程，并了解兩個過程之間的關系； 了解領域工程的三個階段，及每個階段的目標； 第5章 Web Service 與SOA Web Service定義 ；了解Web Service的目標； 了解Web Service的優點； Web Service體系結構模型 ；了解Web Services工作機制； 了解SOA定義 了解SOA優缺點 理解Web Service與SOA關系 第8章 軟件體系結構評估 了解評估的定義和目的； 評估技術兩種：詢問和度量 評估中場景的描述 ； 評估方法三種 ：了解SAAM和ATAM的不同之處。 第10章 云計算 理解云計算、公共云、私有云、混合云 云服務類型 了解云計算的體系結構及核心技術
總結
以上是生活随笔 為你收集整理的软件体系结构期末复习 的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯，歡迎將生活随笔 推薦給好友。
