Textbook

第一章 軟件體系結構概論

軟件危機

• 表現
  1、軟件成本日益增長。
  2、開發進度難以控制。
  （用戶需求變化等意想不到的原因）
  3、軟件質量差。
  （程序員習慣以自己的想法替代用戶需求）
  4、軟件維護困難。
  （缺標準，開發人員的流失，軟件修改十分“危險”很容易出bug）

• 原因
  1、用戶需求不明確。
  （用戶不清楚具體需求，用戶需求有遺漏、二義甚至錯誤，用戶需求變化，開發者與用戶之間理解的差異）
  2、缺乏正確、全面的理論指導。
  （軟件開發過分依賴開發者的高度智力投入，以及技巧與創造性。使得軟件開發個性化強）
  3、軟件規模越來越大。
  （大型項目需要團隊共同完成，而團隊之間不一定能有效協作）
  4、軟件復雜度越來越高。

• 克服方法
  探索用工程的方法進行軟件生成的可能性，即用現代工程概念、原理、技術和方法進行計算機軟件開發、維護和管理。
  軟件工程：用工程、科學和數學的原則與方法，研制和維護計算機軟件的有關技術以及管理方法。

軟件重用

• 概念：在兩次貨多次不同的軟件開發過程之中，重復使用相同或相近的軟件元素的過程。

構件

概念

• 可重用的軟件元素：
  程序代碼，測試用例，設計文檔，設計過程，需求分析，領域知識。

• 可重用構件：語義完整、語法正確和有重用價值的單位軟件。

• 粒度：可重用軟件元素的大小。

• 構件的3C模型
  1、概念（Concept）-構件做什么的描述
  2、內容（Content）-構件如何實現概念
  3、語境（Context）-描述構件的應用場景以及修改指導。

構件獲取

• 領域：一組相似或相近軟件需求的應用系統所覆蓋的功能區域。
• 領域工程：領域分析，領域設計，領域實現等。

構件管理

• 種類
  1、構件描述：方便搜尋
  2、構件分類：方便管理
  3、構件庫組織：方便管理與搜尋
  4、人員及權限管理：安全性
  5、用戶意見反饋：方便迭代開發

• 構件描述
  對構件的制作和重用提供依據以及方便管理。
  如：實現方式，編程語言，注釋，生產日期，價格等。

• 構件分類方法
  1、關鍵字分類法：每個概念用一個描述性關鍵字表示。
  2、刻面分類法：定義一些刻畫構件特征的“面”（3C模型中的概念），通常不超過七八個刻面。
  eg. 青鳥構件庫的刻面分類：使用環境，應用領域，功能，層次，表示方法。
  3、超文本組織方法。

• 構件種類
  1、獨立而成熟的構件。
  2、有限制的構件。
  3、適應性構件。
  4、裝配構件。
  （要使用膠水代碼進行連接使用）
  5、可修改的構件。
  （開發中使用得多）

基于構件的軟件開發

• 優勢：降低開成本，縮短開發時間。

• 劣勢：兼容性，獨創性缺失從而競爭力下降。對構件提供者的依賴性。

• 獲取構件的途徑：
  1、在現有構件中搜尋，直接使用或修改后使用。
  2、通過遺留工程，將有重用價值的構件重組后使用。
  3、從市場上購買現成的商業構件COTS（Commercial Off-The-Shell）
  4、開發新構件。

• 構件重用

• 可重用構件的特殊要求
  1、功能上獨立與完整。
  2、通用性高，靈活。
  3、穩定性高，質量保證。
  4、標準化程度高。

• 應用廣泛的構件技術規范
  CORBA（Common Object Request Broker Architecture）通用對象請求代理結構；
  OMG（Object Management Group）對象管理組織；
  EJB（Enterprise Java Bean）Sun公司；
  DCOM（Distributed Component Object Model）分布式構件對象模型 Microsoft；
  它們都實現了接口對象的分離，提供了構件交互能力。

軟件體系結構

• 概念：是在處理算法與數據結構之上的，關于整體系統結構設計和描述方面的問題。是軟件系統的一個結構、行為和熟悉的高級抽象。（除了概念的組織結構與系統的拓撲結構外，還有系統需求與元素的對應關系。）
  重設計重用。

• 軟件體系結構組成部分：
  1、構件（Component）：一組代碼，或程序塊或一個獨立的程序。（如SQL服務器）
  2、連接件（Connector）：關系的抽象，用以表示構件之間的相互作用。（如過程調用、管道等）
  3、配置（Configuration）：用于對構件與連接件的語義說明。
  4、端口：表示構件與外部環境的交互點。
  5、角色：連接件的接口。
  

  軟件體系結構核心模型

• 軟件體系結構的意義
  1、是系統開發中不同參與者進行交流和信息傳播的媒介。
  2、是早期設計決策的體現。
  3、可以反映軟件的的質量以及瓶頸。
  4、本身也是一種可傳遞可重用的模型。

• 軟件體系結構應用現狀
  1、ADL（Architecture Description Language）軟件體系結構描述語言：描述體系結構的概念框架。（C2，Wright，Aesop，Unicon等）
  優秀的ADL的特性：組裝性，抽象性，重用性，可配置性，異構性，可分析性等。
  2、軟件體系結構描述構造與表示：用一定描述方法，對體系結構進行描述。
  eg. “4+1”模型：由邏輯視圖，開發視圖，過程視圖，和物理視圖組成。用應用場景將這4個有機結合起來。比較細致地描述了需求和體系結構之間的關系。
  3、體系結構的設計、分析與驗證：如何將系統分解成相應的組成成分（構件，連接件）
  eg. 風格設計。結構分析，功能分析，非功能分析。
  4、體系結構的發現、演化與重用：對已有的系統，提取體系結構等。
  5、基于體系結構等軟件開發；
  6、特定領域的體積結構；
  7、軟件體系結構的支持工具：軟件體系結構的支持工具。
  8、軟件產品線體系結構：提高重用性。
  9、建立軟件體系結構的方法；

• 軟件體系結構的研究與應用之中的不足之處：
  1、缺乏統一的軟件體系結構概念，導致軟件體系結構的研究范圍模糊。
  2、ADL繁多，缺乏統一的ADL標準。
  3、軟件體系結構研究缺乏統一的理論模型支持。
  4、市面上的多種標準規范或建議標準不易于操作。
  5、軟件體系結構性質的研究尚不充分，不能明確給出一個良好的體系極高的屬性或評斷標準，也沒有給出良好體系就高的設計指導原則，因此對于軟件開發實踐缺乏有力的促進作用。
  6、缺乏有效的支持環境，以及軟件體系結構理論研究與環境支持不同步，缺乏有效的體系結構分析、設計、方針和驗證工具支持，導致體系結構應用困難。
  7、缺乏有效的體系結構復用方案。
  8、體系結構發現方法研究相對欠缺。

第二章 軟件體系結構建模

軟件體系結構模型：

1、結構模型：最直觀最普遍的建模方法，通過體系結構的構件、連接件和其他概念來刻畫結構；力圖通過結構，來反映系統的重要語義內容。
包括：系統的配置，約束，隱含的假設條件，風格，性質。
2、框架模型：與結構模型類似，但不側重結構的細節，而側重整體的結構。主要以一些特殊的問題作為目標，建立只針對和適應這類問題的結構。
3、動態模型：對結構或框架模型的補充，研究系統的“大粒度”的行為及其性質。如系統總體結構的配置或演化、通信通道或計算過程的建立或拆除等方面的行為。
4、過程模型：研究構造系統的步驟與過程，因而其機構是遵循某些腳本的結果。
5、功能模型：體系機構的一組功能構件，按照層次組成，下層向上層提供服務，可以看作為一種特殊的框架模型。

“4 + 1”視圖模型

5個角度：邏輯視圖，開發視圖，進程視圖，物理視圖，場景視圖。

“4 + 1”視圖模型

• 邏輯視圖：系統提供給最終用戶的服務。
  
  邏輯視圖中使用的標記符號

某通信系統體系結構的邏輯視圖

eg 會話使用轉換服務與連接服務。

• 開發視圖：側重于軟件模塊的組織管理。
  

  開發視圖的標記符號

• 進程視圖：側重系統的運行特性，并關注一些非功能性需求，如系統性能與可用性。
  強調：并發性，分布性，系統集成性，容錯性等。
  

  進程視圖使用的標記符號

ACS系統的進程視圖（部分）

• 物理視圖：重視目標程序的靜態位置問題，決定拓撲結構，系統安裝，通訊方面的問題。
  
  物理視圖使用的標記符號

ACS系統的物理視圖

• 場景：重要系統獲得的抽象，將其他4個視圖聯系起來。
  
  本地呼叫的一個原型

軟件開發的主要階段

1、需求分析階段。
2、建立軟件體系結構。
3、詳細設計階段。
4、實現階段。

軟件體系結構的抽象化描述

定義1:
構件描述：C = （A，O，X，P）
A：構件屬性集合
O：組成構件的所有對象的集合
X：構件動作的集合
P：構件端口的集合

定義2：
先執行構件C1，后執行C2

構件順序結構關系圖

……

• 問題： 引入軟件體系結構以后，傳統軟件過程發生了哪些變化？這種變化有什么好處？

• 問題： 軟件體系結構的神明周期模型與軟件生命周期模型有什么關系？