1、軟件體系結構的定義國內(nèi)普遍看法：體系結構=構件+連接件+約束2、軟件體系結構涉及哪幾種結構：1、模塊結構(Module)系統(tǒng)如何被構造為一組代碼或數(shù)據(jù)單元的決策2、構件和連接件結構(Component-And-Connector,C&C)系統(tǒng)如何被設計為一組具有運行時行為(構件)和交互(連接件)的元素3、分配結構(Allocation)展示如何將來自于模塊結構或C&C結構的單元映射到非軟件結構(硬件、開發(fā)組和文件系統(tǒng))3、視圖視點模型視點(Viewpoint)ISO/IEC42010:2007(IEEE-Std-1471-2000)中規(guī)定：視點是一個有關單個視圖的規(guī)格說明。視圖是基于某一視點對整個系統(tǒng)的一種表達。一個視圖可由一個或多個架構模型組成架構模型架構意義上的圖及其文字描述(如軟件架構結構圖)視圖模型一個視圖是關于整個系統(tǒng)某一方面的表達,一個視圖模型則是指一組用來構建4、軟件體系結構核心原模型1、構件是具有某種功能的可復用的軟件結構單元,表示了系統(tǒng)中主要的計算元素和數(shù)據(jù)存儲。連接件(Connector)：表示構件之間的交互并實現(xiàn)構件之間的連接第二章1、軟件功能需求、質(zhì)量屬性需求、約束分別對軟件架構產(chǎn)生的影響功能性需求：系統(tǒng)必須實現(xiàn)的功能，以及系統(tǒng)在運行時接收外部激勵時所做出的行為或響應。質(zhì)量屬性需求：這些需求對功能或整個產(chǎn)品的質(zhì)量描述。約束：一種零度自由的設計決策，如使用特定的編程語言。質(zhì)量原意是指好的程度，與目標吻合的程度，在軟件工程領域，目標自然就是需求。對任何系統(tǒng)而言，能按照功能需求正確執(zhí)行應是對其最基本的要求。正確性是指軟件按照需求正確執(zhí)行任務的能力，這無疑是第一重要的軟件質(zhì)量屬性。質(zhì)量屬性的優(yōu)劣程度反映了設計是否成功以及軟件系統(tǒng)的整體質(zhì)量。系統(tǒng)或軟件架構的相關視圖的集合，這樣一組從不同視角表達系統(tǒng)的視圖組合在一起構成對系統(tǒng)比較完整的表達2、質(zhì)量屬性質(zhì)量屬性兀他質(zhì)屜屬性叮支拌性J叮檢測性Q「系統(tǒng)質(zhì)屋屬匝卜cf―了功能正確性)2、質(zhì)量屬性質(zhì)量屬性兀他質(zhì)屜屬性叮支拌性J叮檢測性Q「系統(tǒng)質(zhì)屋屬匝卜cf―了功能正確性)*——‘/廠槪念死蜃件計時質(zhì)址屈性》&一町維護性J可重用性廠町用性/Q用戶頂屋屬性｝~O—蚣用件一環(huán)忡適應性*可定制件—互操作性理性一性葩一?？啃砸欢Ｉ祓?安全性廠町箜性—叮穢苗性一開矍的可分布加「町部畐性一馬創(chuàng)性3、系統(tǒng)非功能性需求？包括哪些質(zhì)量屬性非功能性需求：用戶對軟件質(zhì)量屬性、運行環(huán)境、資源約束、外部接口等方面的要求或期望，包括：性能需求：用戶在軟件響應速度、結果精度、運行時資源消耗量等方面的要求?？煽啃孕枨螅河脩粼谲浖У念l率、嚴重程度、易恢復性，以及故障可預測性等方面的要求。易用性需求：用戶在界面的易用性、美觀性，以及對面向用戶的文檔和培訓資料等方面的要求。安全性需求：用戶在身份認證、授權控制、私密性等方面的要求（5）外部接口：用戶對待開發(fā)軟件系統(tǒng)與其他軟件系統(tǒng)或硬件設備之間的接口的要求。（6）可保障性（supportable）需求：用戶在軟件可配置性、可擴展性、可維護性、可移植性等方面的要求?？煽啃钥捎眯詤^(qū)別可靠性通常低于可用性，因為可靠性要求系統(tǒng)在［0,t］的整個時間段內(nèi)需正常（注意是“連續(xù)”!）運行；可用性大于或等于可靠性，對于可用性，要求就沒有那么高，系統(tǒng)可以發(fā)生故障，然后在時間段［0,t］內(nèi)修復。修復以后，只要系統(tǒng)能夠正常運行，它仍然計入系統(tǒng)的可用性。計算：1、軟件架構風格（是一個面向一類給定環(huán)境的架構設計決策的集合，這些通用的設計決策形成了一種特定的模式，為一族系統(tǒng)提供粗粒度的抽象框架。每一個軟件系統(tǒng)都有其占主導地位的軟件架構風格?！皬能浖衼?，到軟件中去”架構風格通過為常見的問題提供解決方案，增強了對問題的分解能力、提升了設計重用的水平。）1）獨立構建風格：（這種風格的主要特點是：事件的觸發(fā)者并不知道哪些構件會被這些事件影響，相互保持獨立。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調(diào)用；各個構件之間彼此無直接的連接關系，各自獨立存在，通過對事件的發(fā)布和注冊實現(xiàn)關聯(lián)。）進程通信體系結構風格：構件是獨立的進程，連接件是消息傳遞。消息傳遞通常用來實現(xiàn)進程之間的同步和對共享資源的互斥操作典型例子：客戶-服務器架構，其中服務器通常用來為一個或多個客戶端提供數(shù)據(jù)服務，客戶端則用來向服務器發(fā)出請求，針對這些請求服務器通過同步或異步方式進行請求響應。基于事件的隱式調(diào)用風格構件不直接調(diào)用一個過程，而是觸發(fā)或廣播一個或多個事件。系統(tǒng)中的其它構件中的過程在一個或多個事件中注冊。當一個事件被觸發(fā)/發(fā)布，系統(tǒng)自動調(diào)用在這個事件中注冊的所有過程。這樣，一個事件的觸發(fā)就導致了另一模塊中的過程的調(diào)用。?這種系統(tǒng)，稱為基于事件的系統(tǒng)（Event-basedsystem）,采用隱式調(diào)用（Implicitinvocation）的方式。2）層次風格優(yōu)點：通過把邏輯層分布到多個物理層中，可以提高可伸縮性、容錯性faulttolerance）和性能。可重用性。每一層提供的功能都是獨立的和定義良好的。不同層之間有明確的接口,在解決一個新的問題時,使開發(fā)人員更容易地重用一個已有的層?？蓽y試性。由于有了明確定義的接口,以及可以在層接口的不同實現(xiàn)之間實現(xiàn)按需切換,可測試性明顯增強了。標準化。清晰定義并且廣泛接受的抽象層次能夠促進實現(xiàn)標準化的任務和接口開發(fā),同樣接口的不同實現(xiàn)能夠互換使用。缺點：1）并不是每個系統(tǒng)都可以很容易地劃分為分層的模式,甚至即使一個系統(tǒng)的邏輯結構是層次化的,出于對系統(tǒng)性能的考慮,系統(tǒng)設計師不得不把一些低級或高級的功能綜合起來；2）效率的降低：由分層風格構成的系統(tǒng),運行效率往往低于整體結構。在上層中的服務如果有很多依賴于最底層,則相關的數(shù)據(jù)必須通過一些中間層的若干次轉(zhuǎn)化,才能傳到；3）很難找到合適的、正確的層次抽象方法：層數(shù)太少，分層不能完全發(fā)揮這種風格的可復用性、可修改性和可移植性上的潛力。層數(shù)過多，則引入不必要的復雜性和層間隔離冗余以及層間傳輸開銷。3）虛擬機風格：不管何種類別的虛擬機，本質(zhì)上都是在高層次抽象的用戶與低層次抽象的OS/硬件之間建立一道屏障。但是，如何把上層應用的請求映射到下層OS/硬件系統(tǒng)的執(zhí)行？解釋器（Interpreter）基于規(guī)則的系統(tǒng)（Rule-basedSystem）解釋器：是一個用來執(zhí)行其他程序的程序.基本構件：解釋器引擎存儲區(qū)連接器：?對存儲區(qū)的數(shù)據(jù)訪問基于規(guī)則的系統(tǒng)：核心思想：將業(yè)務邏輯中可能頻繁發(fā)生變化的代碼從源代碼中分離出來；基本過程：使用規(guī)則定義語言（IF???THEN…的形式，通?；赬ML或自然語言，但絕不是程序設計語言），將這些變化部分定義為“規(guī)則”；4）客戶機/服務器：一個應用系統(tǒng)被分為兩個邏輯上分離的部分，每一部分充當不同的角色、完成不同的功能，多臺計算機共同完成統(tǒng)一的任務。1）客戶機（前端，front-end）:接受用戶的輸入，并把輸入進行適當組織，轉(zhuǎn)換成服務器接受的形式，通過網(wǎng)絡傳遞給服務器，同時，負責接收服務器的回送消息，并表back-end）2）服務器:提供各種服務，通常在高檔計算機（服務器）上運行。服務器軟件根據(jù)客戶機的請求提供相應的服務，如數(shù)據(jù)庫服務、郵件服務、Web服務等。3）連接件:建立在網(wǎng)絡協(xié)議上，駐留在服務器和客戶機兩端，提供透明的網(wǎng)絡連接和服務。5）基于B/S體系結構的軟件優(yōu)點?系統(tǒng)維護成本低:?客戶端無任何業(yè)務邏輯?良好的靈活性和可擴展性?較好的安全性?良好的容錯能力和負載平衡能力。缺點?客戶端瀏覽器一般情況下以同步的請求/響應模式交換數(shù)據(jù)，每請求一次服務器就要刷新一次頁面；?受HTTP協(xié)議“基于文本的數(shù)據(jù)交換”的限制，在數(shù)據(jù)查詢等響應速度上，要遠遠低于C/S體系結構；?提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務處理（OLTP）應用；?受限于HTML的表達能力，難以支持復雜GUI（如報表等）。6）SOA風格定義：面向服務的體系結構（Service-OrientedArchitecture，SOA）是一個構件模型，它將應用程序的不同功能單元通過定義良好的接口和契約聯(lián)系起來接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構建在各種這樣的系統(tǒng)中的服務可以以一種統(tǒng)一和通用的方式進行交互。服務（service）是封裝成用于業(yè)務流程的可復用構件的應用程序函數(shù)。它提供信息或簡化業(yè)務數(shù)據(jù)從一個有效的、一致的狀態(tài)向另一個狀態(tài)的轉(zhuǎn)變用于實現(xiàn)特定服務的流程并不重要，只要它響應命令并為請求提供高質(zhì)量的服務就可以了服務特征：可在網(wǎng)際間請求調(diào)用具有良好的兼容性粗粒度的操作松散耦合的關聯(lián)基于接口的設計具有透明的搜索和查詢SOA好處:利用現(xiàn)有的資產(chǎn)更快的響應和上市速度減少成本和增加復用更易于集成和管理復雜性說到做到2．WebServices定義部署在Web上的對象從外部使用者的角度來看，WebServices是部署在Web上的對象，具備以下特征：完好的封裝性（數(shù)據(jù)和處理）松散耦合使用協(xié)約的規(guī)范性標準化高度可集成能力3、WebService與SOA區(qū)別WebService是技術規(guī)范，而SOA是設計原則。從本質(zhì)上來說，SOA是一種架構模式，而WebService是利用一組標準實現(xiàn)的服務。WebService是實現(xiàn)SOA的方式之一。為什么WebServices是最佳解決方案？HTTP+XML,最通用的訪問方式基于規(guī)范協(xié)議的訪問接口,可支持所有平臺和應用僅使用WebService作為訪問界面，使得所有接入模塊的編寫變得容易開發(fā)代價顯著降低：程序員無需與多種平臺進行交互，只需與WebService進行交互；其調(diào)用接口使用XML及其相關技術，在代碼實現(xiàn)上的代價也顯著降低部署和集成的費用大大降低，流程的更改也無需更改大量的代碼，甚至無需更改代碼只有使用WebServices架構，今后的大規(guī)模的面向公眾的系統(tǒng)對接才成為可能第四章1、常用SA描述方法線框描述法:優(yōu)點：靈活能夠直觀反應系統(tǒng)架構，同時也易于理解缺點：二義性：圖形的本質(zhì)所決定的模糊性，不同人有不同的理解；矛盾性：模型中可能存在相互沖突的陳述；不完備：無法描述所有的細節(jié)；異構性：各個建模規(guī)范不同，模型也不同，難以支持模型在各個建模工具之交換；無法自動化：只能由人理解，靠軟件工具來理解比較困難，因此無法實現(xiàn)自動化的驗證與推理。形式化描述法:優(yōu)點：表達架構的一個正式方式可做到人機可讀在一個比以前更高的水平上描述系統(tǒng)允許在完整性、一致性、歧義性和性能等方面分析和評估架構支持自動生成軟件系統(tǒng)ADL的缺點：使用類計算機高級語言的形式描述，表達不夠直觀，難以理解對于ADLs應該表達什么，沒有一個普遍共識，特別是關于架構的行為目前使用表達解析相對比較困難，沒有很好的商業(yè)工具提供支持UML描述2、4+1視圖第五章2、屬性驅(qū)動的設計方法(Attribute-DrivenDesign,ADD)是定義軟件架構的一種方法,可根據(jù)軟件質(zhì)量屬性需求實施架構設計過程ADD通過一個分解系統(tǒng)或者系統(tǒng)元素的循環(huán)過程，使用架構模式和策略來滿足系統(tǒng)質(zhì)量屬性需求，以完成分解操作和模式3、質(zhì)量屬性設計策略計策略(2/5)曾對攻擊維性設計策略［計策略啡件創(chuàng)達的|寸間限制?內(nèi)生成的響應盜源需求覆髙計郭效率減少計算？rti管理嶼件率｛制収樣頻率慌源管理引入并發(fā)維持多個刷本增加可用資源資源仲遞m?略4、模塊設計評價標準:可分解性可組合型可理解性可持續(xù)性(連續(xù)性)可保護性模塊化五大規(guī)則:直接映射、少的接口、小的接口、顯示接口、信息隱藏模塊化設計的基本原則類設計原則:單一責任原則開放-封閉原則里氏替換原則依賴倒置原則接口隔離原則(包聚合設計原則)?(REP)TheReuse/ReleaseEquivalencyPrinciple復用/發(fā)布等價原則?(CCP)TheCommonClosurePrinciple共同封閉原則?(CRP)TheCommonReusePrinciple共同復用原則3.PRINCIPLESOFPACKAGECOUPLING(包耦合設計原則):?(ADP)TheAcyclicDependenciesPrin