第一章
1.1.1 系統架構師的概念
現代信息系統“架構”三要素：構件、模式、規劃;規劃是架構的基石，也是這三個貢獻中最重要的。
架構本質上存在兩個層次：概念層，物理層。
1.2.1 系統架構師的定義
負責 理解、管理 並最終確認和評估 非功能性系統需求，給出開發規範，搭建系統實現的核心架構，對整個軟件架構、關鍵構建、接口 進行總體設計 並澄清關鍵技術細節。
主要着眼於系統的“技術實現”，同時還要考慮系統的“組織協調”。
要對所屬的開發團隊有足夠的瞭解，能夠評估該開發團隊實現特定的 功能需求目標和資源代價。
1.2.2 系統架構師技術素質
對軟件工程標準規範有良好的把握。
1.2.3 系統架構師管理素質
系統架構師是一個高效工作團隊的創建者，必須儘可能使所有團隊成員的想法一致，爲一個項目訂製 清晰的、強制性的、有元件的目標 作爲整個團隊的動力;
必須提供特定的 方法和模型 作爲理想的技術解決方案;
必須避免 猶豫，必須具備及時解決技術問題的 緊迫感和自信心。
1.2.4 系統架構師與其他團隊角色的協調
系統分析師，需求分析，技術實現
系統架構師，系統設計，基於環境和資源的系統技術實現
由於 職位角度出發產生衝突制約，不可能很好地給出 開發規範，搭建系統實現的 核心架構，並澄清技術細節，掃清主要難點。
所以 把架構師定位在 項目管理師與系統分析師 之間，爲團隊規劃清晰的目標。
對於大型企業或項目，如果一人承擔多個角色，往往容易發生顧此失彼的現象。
1.3 系統架構師知識結構
需要從大量互相沖突 的系統方法和工具中 區分出 哪些是有效的，那些是無效的。
1.4 從開發人員到架構師
總結自己的架構模式，深入行業總結規律。
幾天的培訓不太可能培養出合格的軟件架構師，廠商的培訓和認證，最終目的是培養自己的市場，培養一批忠誠的用戶或產品代言人，而不是爲中國培養軟件架構師。
2011年軟考系統架構設計師學習筆記第二章
《計算機網絡基礎知識》
計算機系統 由 硬件和軟件組成，軟件通常分爲 系統軟件和應用軟件。
系統軟件支持應用軟件的運行，爲用戶開發應用軟件提供平臺，用戶可以使用它，但不能隨意修改它。
常用的系統軟件有 操作系統、語言處理程序、連接程序、診斷程序、數據庫 等。
應用軟件指 計算機用戶利用 軟硬件資源 爲某一專門的應用目的而開發的軟件。
2.1 操作系統基礎知識
操作系統 Operating System，是計算機系統的核心繫統軟件。
2.1.1 操作系統的原理、類型、結構
1、操作系統定義
硬件資源包括 中央處理器、存儲器、輸入輸出設備。
軟件資源是以 文件形式保存在存儲器上的 程序和數據。
操作系統既 有效組織和管理 系統中各種 軟硬件資源，合理地組織計算機系統的工作流程，又控制程序的執行，爲用戶使用計算機 提供了一個 良好的環境和友好的接口。
2、操作系統分類
按功能不同分：單用戶操作系統、批處理操作系統;分時操作系統、實時操作系統;網絡操作系統、分佈式操作系統;嵌入式操作系統。
3、操作系統的特徵
併發性、共享性、虛擬性、不確定性。
4、操作系統的功能
進程管理、文件管理、存儲管理、設備管理、作業管理。
2.1.2 處理機 與 進程管理
1、進程的定義及其分類
進程通常由 程序、數據、進程控制塊 PCB 組成。
2、進程的狀態轉換與控制
就緒、運行、阻塞。
進程控制是通過 進程控制原語實 現的，進程控制原語主要有：創建原語、撤銷原語、掛起原語、激活原語、阻塞原語、喚醒原語。
注：原語不可分割，不允許中斷。
3、進程互斥與同步 以及 P/V 操作
同步是使在異步環境下的各進程按一定的 順序和速度 執行。
互斥 要保證臨界資源 一次只能提供一個進程使用，稱爲 臨界資源 CR。
PV操作是低級通信原語，在執行期間不可分割，P表示申請一個資源，V表示釋放一個資源。
P操作定義：S:=S-1，若S>=0，則執行P操作的進程繼續執行，否則若S<0， 則置該進程爲阻塞狀態(因爲無可用資源)，並將其插入阻塞隊列。
V操作定義：S:=S+1，若S>0， 則執行V操作的進程繼續執行，否則若S<=0，則從阻塞狀態喚醒一個進程，並將其插入就緒隊列，然後執行V操作的進程繼續執行。
4、進程通信與管程
控制信息的交換稱爲低級通信，數據的交換稱爲高級通信。
高級通信的類型有 共享存儲系統、消息傳遞系統、管道通信。
在任一時刻最多隻有一個進程能夠真正地進入管程，其他的只能等待。
5、進程調度與死鎖
產生死鎖的四個必要條件：互斥條件、請求保持條件、不可剝奪條件、環路條件。
預防策略，破壞死鎖的四個必要條件之一。
6、線程
線程是進程中的一個實體，是被系統獨立分配和調度的基本單位。
線程只擁有一些運行中必不可少的資源。
同一個進程中的多個線程可以併發執行，線程具有：就緒、運行、阻塞，三個基本狀態。
2.1.3 存儲管理
存儲器的發展方向是：高速、大容量、小體積。
存儲管理的主要任務是：如何提高主存的 利用率、擴充主存 以及對主存信息實現有效保護。
2.1.4 設備管理
設備管理的目標是：提高設備的利用率，爲用戶提供方便統一的界面。
磁盤調度算法：先來先服務 FCFS、最短尋道時間優先 SSTF、掃描算法SCAN。
2.1.5 文件管理
隨機訪問是指對文件中的信息可以按任意次序隨機讀寫文件中的信息。
文件控制塊FCB，描述和控制文件的數據結構。
2.1.6 作業管理
常用的作業調度算法有：先來先服務、短作業優先、相應比高優先、優先級調度算法、均衡調度算法。
2.1.7 網絡操作系統 NOS
網絡操作系統分爲：集中模式、客戶機/服務器模式、對等模式。
現代操作系統已經把網絡功能包含到操作系統的內核中，作爲操作系統核心功能的一個組成部分。
2.2.1 關係數據庫基礎
數據庫的三要素：數據結構、數據操作、數據約束條件。
特別需要指出的是，E-R模型強調的是 語義。
關係數據庫設計理論的核心是 數據間的函數依賴，衡量的標準是 關係規範化的程度 及分解的無損連接 和 保持函數依賴性。
數據依賴包括：函數依賴、非平凡的函數依賴、平凡的函數依賴、完全函數依賴、部分函數依賴、傳遞依賴、碼、主屬性、非主屬性、外碼、值依賴定義、函數依賴的公理系統。
事務是數據庫環境中 不可分割 的邏輯工作單位。
四個特性：原子性、一致性、隔離性、持久性，ACID。
SQL語言中事務定義語句有三條：BEGIN TRANSACTION 事務開始、COMMIT 事務提交、ROLLBAK 事務回滾。
併發操作是指：在多用戶共享系統中，用戶可能同時對同一數據庫進行操作。
帶來的問題主要有：丟失更新、不可重複讀、讀髒數據。
併發控制主要技術是封鎖：排他鎖(簡稱 X鎖、寫鎖)、共享鎖(簡稱 S鎖、讀鎖)。
保護數據庫的關鍵技術在於 建立冗餘數據、即 備份數據。
方法是：數據轉儲、建立日誌。
2.2.2 關係數據庫設計
需求分析、概念結構設計、邏輯結構設計、物理結構設計、應用程序設計、運行維護。
E-R 方法的數據庫概念結構設計可分三步：設計局部E-R模型、設計全局E-R模型、全局E-R模型優化。
2.2.3 分佈式數據庫系統
滿足 分佈性、邏輯相關性、場地透明性、場地自治性 的數據庫系統被稱爲 完全分佈式數據庫系統。
分佈式數據庫系統的特點：數據的集中控制性、數據獨立性、數據冗餘可控性、場地自治性、存取有效性。
4層模式劃分爲：全局外層、全局概念層、局部概念、局部內層，各層還有相應的 層間映射。
2.2.4 商業智能
一般認爲：數據倉庫、連機分析處理、數據挖掘技術 是 商業智能BI 的三大組成部分。
數據倉庫的關鍵特徵：面向主題、集成的、非易失的、時變的。
三層結構：數據倉庫服務器、OLAP服務器(連機分析處理 服務器)、前端工具。
數據倉庫的實現步驟：規劃、需求研究、問題分析、數據的 抽取 清洗 集成 裝載、數據倉庫設計、數據倉庫管理、分析報表查詢、數據倉庫性能優化、數據倉庫部署發佈。
切片、切塊、下鑽、上卷、旋轉 等多維度分析與跨維度分析。
OLAP 系統架構主要分爲：基於關係數據庫的ROLAP、基於多維數據庫的MOLAP、基於混合數據組織的HOLAP。
數據挖掘是在 沒有明確架設的前提下 去挖掘信息、發現知識。
所得的信息應具有 先知、有效、實用，三個特徵。
主要功能有5類：自動預測趨勢和行爲、關聯分析、聚類、概念描述、偏差檢測。
2.3 計算機網絡基礎知識
計算機網絡
按通信距離分 廣域網、局域網、城域網;按信息交換方式分 電路交換網、分組交換網、綜合交換網;按拓撲結構分 星型網、樹形網、環形網、總線型網;按傳輸帶寬分 基帶網、寬帶網;
按使用範圍分 公用網、專用網;按通信傳播方式分 廣播式、點到點式……
OSI/RM：把複雜的問題分解開，保持了層次之間的獨立性。
物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
2.3.2 計算機網絡
1、廣域網、局域網、城域網
廣域網又稱遠程網，覆蓋範圍廣，傳輸速率相對低，以數據通信爲主要目的 的數據通信網。數據傳輸可靠性隨着傳輸介質不同而不同、拓撲結構複雜。
有公共交換電話網、各種公用數據網。
局域網是指傳輸距離有限，傳輸速度較高，以共享網絡資源爲目的的網絡系統，數據傳輸可靠 誤碼率低，網絡控制一般爲分佈式，總線拓撲、環形拓撲、星型拓撲、混合型。
城域網 是一種較大範圍的高速網絡。
網絡拓撲結構：網絡中通信線路和節點的幾何排序，反映各節點之間的結構關係，影響着整個網絡的 設計、功能、可靠性、通信費用 等重要方面。
局域網和城域網 都是IEEE802標準，決定局域網主要技術有：傳輸介質、拓撲結構、介質訪問控制方法。
決定了傳數據的類型、網絡響應時間、吞吐率、利用率，以及網絡應用。
最重要的是 介質控制訪問方法。(CSMA/CD)
無線局域網具有以下優點：安裝便捷、使用靈活、經濟解約、易於擴展。IEEE8.2.11
2、網絡互聯
網絡互聯目的是 使一個網絡的用戶能訪問其他網絡的資源，使不同網絡上的用戶能夠 互相通信、交換信息。
網絡互聯設備的作用是 連接不同網絡。
傳輸介質是信號傳輸的 媒體，常用的介質分爲 有限介質 和 無線介質。局域網中，其基本組成部件爲 服務器、客戶機、網絡設備、通信介質、網絡軟件 等。
3、Internet 及應用
世界上規模最大、覆蓋面最廣 且 最具影響力 的 計算機互聯網絡，它將分佈在世界各地的計算機利用開放系統互連協議連接在一起，用來進行數據傳輸、信息交換、資源共享。
TCP/IP作爲Internet的核心協議，已被廣泛應用於局域網和廣域網中，主要特性爲：邏輯編址、路由選擇、域名解析、錯誤檢測、流量控制、對應用程序的支持 等。
TCP/IP是一個協議族，網際層除了IP協議外，還有ICMP、ARP、RARP等幾個重要協議……
Internet的地址主要有兩種書寫形式：域名格式、IP地址格式。
www也成萬維網/全球網，是指在Internet上 以超文本爲基礎形成的 信息網。採用統一的資源定位器URL 和 圖文聲並茂的用戶界面。
2.3.3 網絡管理與網絡安全
1、網絡管理
網絡管理是對計算機網絡的 配置、運行狀態、計費 等進行管理。它提供了 監控、協調、測試 各種網絡資源 以及 網絡運行狀況的手段，還可以提供 安全處理和積分 等功能。
OSI網絡協議標準中定義了 網絡管理的5大基本功能：配置管理、性能管理、故障管理、安全管理、計費管理。
實際上還應該包括 網絡規劃、網絡操作人員管理 等。
2、計算機網絡安全
計算機網絡安全是指 計算機、網絡系統的 硬件、軟件、數據 收到保護，不因偶然或惡意的原因而遭到 破壞、更改、泄漏，確保系統能 連續、可靠 地運行，使網絡服務 不中斷。
網絡安全從本質上講 就是 網絡上的 信息安全。
信息的 傳輸、存儲、訪問 提供安全保護，以 防止信息被 竊取、篡改、非法操作。
信息安全的基本要素是 保密性、完整性、可用性、真實性、可控性。
完整的信息安全保障體系應包括：保護、檢測、響應、恢復。
信息安全術語：密碼學、鑑別、Kerberos鑑別、公鑰基礎設施、數字簽名、訪問控制
3、VPN
所謂虛擬專用網，是建立在公用網上，沒有專用物理連接，而通過ISP提供的公共網絡來實現通信，VPN內部用戶可以實現安全通信。
關鍵技術：隧道技術、加密技術、密鑰管理技術、身份認證技術。
解決方案：內聯網VPN、外連網VPN、遠程接入VPN。
2.3.4 網絡工程
網絡規劃、網絡設計階段、工程組織、實施階段、維護階段。
2.3.5 存儲及負載均衡技術
RAID磁盤陣列，目的是 建立數據冗餘、增強容錯、提高容量、增進性能。
網絡存儲體系結構大致分爲三種：直接式存儲DAS、網絡連接存儲NAS、存儲區域存儲SAN。
負載均衡 LoadBalance 從結構上分爲：本地負載均衡、全局負載均衡。
一般情況下從 傳輸鏈路聚合、採用更高層網絡交換技術、設置服務器集羣策略 三個角度實現。
集羣 Cluster，大多數模式下，集羣中所有的計算機擁有一個共同的名稱，各節點服務器通過一個內部局域網相互通訊，集羣內任一系統上運行的服務都可被所有的網絡客戶所使用，當一臺
節點服務器發生故障時，這臺服務器上所運行的應用程序將在另一節點服務器上被自動接管，客戶也能很快自動地連接到新的應用服務器上。
2.4 多媒體技術及其應用
媒體有兩種含義：信息的載體、存儲信息的實體。
根據ITU-T(原CCITT)建議，媒體有5種：感覺媒體、表示媒體、顯示媒體、存儲媒體、傳輸媒體。
International Consultative Committe On Telecommunication And Telegraphy，CCITT，國際電報電話諮詢委員會。
多媒體技術是指：以數字化爲基礎，對多種媒體信息進行 採集、編碼、存儲、傳輸、處理、表現，使之建立有機的邏輯聯繫，具有良好的 交互性 的技術。
多媒體的特徵：多樣性、集成性、交互性、實時性。
2.4.2 多媒體數據壓縮編碼技術
JPEG，Joint Photographic Experts Group，聯合圖像專家小組，是一種對靜態圖像壓縮的編碼算法。“聯合”的含義是：CCITT 和 ISO 聯合組成的圖像專家小組。
MPEG，Moving Picture Experts Group，運動圖像專家小組，是作爲一個國際標準來研究制訂的，具有很好的兼容性。
其次，比其它算法提供更好的壓縮比，最高可達 200:1。更重要的是對數據損失很小。
不存在專利問題，適合大力推廣。
數據壓縮編碼兩大類：無損壓縮編碼法(也稱 冗餘壓縮法、熵編碼法)，有損壓縮編碼法(也稱 熵壓縮法)。
2.4.4 多媒體技術的研究內容
對數據進行有效壓縮將是多媒體發展中必須要解決的最關鍵的技術之一。
數據量大、種類繁多、關係複雜，是多媒體數據的基本特徵。
虛擬現實
首先，“逼真”就是要達到 三維視覺、聽覺、觸覺 等效果;其次，通過人的感官與這個環境進行交互;最後，爲用戶提供一個逼真的操作環境。
虛擬現實是一種 多技術 多科學 相互滲透集成 的技術。
只能多媒體技術
將具有推理功能的 知識庫 與 多媒體數據庫 結合起來，形成 智能多媒體數據庫。
發展趨勢：把 多媒體和通信 功能 集成到CPU芯片中。
其一，專用設備、家電及寬帶通信設備，可以取代這些設備中的CPU及大量Asic和其他新品。
其二，與現有的計算機系列兼容，同事具有多媒體和通訊功能。
2.5 系統性能
系統性能 是一個系統提供給用戶的 衆多性能指標的集合。既包括 硬件性能，也包括軟件性能;既包括部件性能指標，也包括綜合性能指標。
系統性能包含 性能指標、性能計算、性能設計、性能評估，四個方面內容。
2.5.3 系統性能設計
是一系列重複的受控的性能試驗，循環的調整過程爲 收集、分析、配置、測試。
阿姆達爾定律 Amdahl：系統中 對某一部件採用某種更快的執行方式所獲得的系統性能改變程度，取決於這種方式被利用的頻率，或所佔總執行時間的比例。
被改進並增強的部分 在總時間中所佔的比例，增強比例，永遠小於等於1.
2.5.4 性能評估
對測試結果做出解釋，並形成一分文檔的技術。
目的是爲了性能的優化提供參考。
用得最多、最頻繁 的那部分核心程序作爲評價計算機性能的標準程序，稱爲基準測試程序 Benchmark。
2011年軟考系統架構設計師學習筆記第三章
3.1 信息的特徵
1、客觀性：反映了事物的 運動狀態和方式，既事實性。
2、普遍性：信息無所不在。
3、無限性：事物及其變化是 無限多樣的。
4、動態性：隨着時間變化而變化。
5、依附性：不能完全脫離物質而獨立存在。
6、變換性：可以用不同的載體 以不同的方法來負載。
7、傳遞性：時間上的傳遞 即存儲;空間上的傳遞 即 轉移或擴散。
8、層次性：信息可以分爲 戰略級、管理級、操作級。
9、系統性：可以形成與現實世界相對應的信息系統。
3.1.1 信息化的定義
信息化 Informationalization，是以信息資源開發利用爲核心，以網絡技術、通訊技術等高科技技術爲依託的 一種新技術擴散的過程。
3.2 信息化的內容
1、信息資源的開發利用
2、信息網絡的全面覆蓋，計算機網絡、電信網、電視網等，逐步實現三網合一。
3、信息技術的廣泛應用，這是信息化的基礎。
4、信息產業的大力發展
5、信息化人才的培養
6、信息化政策和標準規範建設
基於web的架構是 鬆散耦合的，優勢在於能夠在不同的網絡及操作系統中運行;以服務器爲中心，客戶端瘦小、簡單，容易在運行時實現自動升級。
3.3 信息化的典型應用
電子政務的內容
1、政府與政府 G2G
2、政府對企事業 G2B
3、政府對居民 G2C
4、企業對政府 B2G
5、居民對政府 C2G
3.3.1 企業資源規劃的結構和功能
物料需求計劃 MRP，物料單系統 BOM，製造資源計劃 MRPII。
1、ERP 的概念
企業的所有資源包括三大流：物流、資金流、信息流。
ERP是建立在信息技術基礎上，全面地集成了企業的所有資源信息，併爲企業提供決策、計劃、控制、經營業績評估 的全方位 和 系統化的管理平臺。
ERP是一種管理理論和管理思想，不僅僅是信息系統。
1.生產預測
市場需求是企業生存的基礎，ERP中首先需要對市場進行較準確的預測，預測主要用於計劃。
常用的預測方法有：德爾菲方法、移動平移法、指數平滑法、非線性最小二乘曲線擬合法。
2.銷售管理(計劃)
銷售管理從其計劃角度來看，屬於最高層計劃的範疇，是企業最重要的決策層計劃之一。
3.經營計劃(生產計劃大綱)
4.主生產計劃
5.物料需求計劃
根據主生產計劃 對最終產品的 需求數量和交貨期，推導出構成產品的 零部件及材料的 需求數量和需求時期，再導出自制零部件的製作訂單下達日期和採購件的採購訂單發送日期。
6.能力需求計劃 CRP
通過分析比較 MRP 的需求和企業現有生產力，及早發現 能力瓶頸所在。
7.車間作業計劃 PAC
將零部件的生產計劃以訂單的形式下達給適當的車間，屬於 ERP 執行層計劃。當前主流的車間作業計劃模式是 JIT模式。
8.採購與庫存管理
是ERP的基本模塊，從採購訂單產生至貨物受到的全過程進行 組織、實施、控制，庫存管理IM 對企業物料的 進、出、存 進行管理。
9.質量與設備管理
全面質量管理 TQM，對企業的全過程進行質量管理，而且明確指出執行質量職能是企業全體人員的責任。
設備管理對 設備壽命週期內的 所有設備 物資運動形態和價值運動形態 進行綜合管理。
10.財務管理
以貨幣的形式 反映和監督 企業的日常經濟活動，並對數據進行分類、彙總，爲企業管理和決策提供必要的信息支持。
11.ERP 有關擴展應用模塊
客戶關係管理、分銷資源管理、供應鏈管理、電子商務 等。
3、ERP 的功能
ERP 爲企業提供的功能是 多層面的 全方位的。
3.3.2 客戶關係管理在企業的應用
1、CRM 的概念
提供的信息要有利於更好地理解客戶;
流程管理要爲客戶提供高效、適當的體驗;
提供那些構件強有力關係、提高客戶忠誠度的體驗。
CRM 的核心思想就是 以客戶爲中心，
從傳統的“以產品爲中心”的經營理念解放出來，通過富有意義的交流溝通，理解並影響客戶行爲，最終實現客戶 保留、客戶忠誠、客戶創利 的目的。
將客戶信息 轉化爲 積極的客戶關係 的 反覆循環過程。
市場競爭，客戶資源逐漸減少，市場主動權讓給客戶，瞭解市場和客戶 真實需要的基礎上 提供令其滿意的 產品和服務。
客戶能根據自己的需求 量身定做 合適自己需要的產品和服務。
客戶信息是 客戶關係管理 的基礎。
更低成本、更高效率 地 滿足客戶的需求，與客戶建立起 基於學習性關係基礎，最大程度提高客戶滿意度、忠誠度。
3.3.3 銷售自動化 SFA
功能：日曆和日程安排、聯繫和客戶管理、佣金管理、商業機會、傳遞渠道管理、銷售管理、建議的生產和管理、定價、區域劃分、費用報告 等。
產品目錄和價格、購買記錄、服務記錄、存貨情況、促銷文本資料、信用記錄。
SFA 應用往往集成 電子郵件、辦公軟件 等 其它各種標準應用。
3.3.4營銷自動化 MA
集成客戶商業智能信息、產品信息、“營銷百科全書”等 信息資源。
CRM 中，客戶服務與支持主要是通過 呼叫中心 和 互聯網 來實現，在滿足客戶的個性化要求方面，高速度、準確性、高效率 來完成客戶服務人員的各種要求。
當把客戶服務與支持功能同銷售、營銷功能比較好地結合起來時，就能爲企業提供很多機會。
客戶服務與支持的內容應包括：客戶關懷;糾紛、訂貨、訂單跟蹤;現場服務;問題及解決方法數據庫;維修行爲安排調度;服務協議合同;服務請求管理 等。
商業智能是指利用 數據挖掘、知識發現 等 技術 分析和挖掘 結構化的、面向特定領域的 存儲與數據倉庫的信息，幫用戶 認清發展趨勢、識別數據模式、獲取職能決策支持、得出結論。
智能的範圍：客戶、產品、服務、競爭者 等。
收集和分析市場、銷售、服務 和整個企業的各類信息，對客戶進行全方位的瞭解，從而理順企業資源與客戶需求之間的關係。
CRM 尚未有成型的理論出現
對市場的設定、跟蹤、分析總結。
呼叫中心支持由合作的硬件廠商參與並提供全套設備，而不僅僅是提供支持呼叫中心的應用軟件。
對移動設備的支持。
決策者所掌握的信息完全，能更及時地做出決策。
不管客戶由何種渠道與企業聯繫，與客戶的互動都應該是 無縫的、統一的、高效的。
需要任命一名來自企業的 系統管理員，作爲內部系統專家。
經特殊調整的系統 必須 伴隨技術培訓。
由於數據轉換過程工作量極大，因此要精確預測該過程的時間表幾乎是不可能的。
“培訓者”必須接受由軟件供應商 進行的培訓，稱爲新系統專家。
對所有用戶的 正規培訓，用戶必須認識到 使用新系統的 即時和明顯好處。
對系統的持續支持要求公司配備至少一名全職的內部系統管理員，可保證技術上自給自足的靈活性，CRM 系統的支持是艱鉅的工作。
爲保證系統帶來所希望的益處，在將其推廣到所有用戶之前一定要加以測試。
間接電子商務，商品是有形貨物。
直接電子商務，商品是無形的貨物或服務，雙方越過地理界限直接進行交易。
3.3.5 供應鏈管理
供應鏈是企業賴以生存的商業循環系統，企業供應鏈可以耗費企業高達 25% 的運營成本。
從供應商開始，經由製造商、分銷商、零售商，直到最終客戶的全要素、全過程的集成化管理模式。
正向 推動式 運作模式是 以生產爲中心;逆向 拉動式 運作模式是 以用戶爲中心;兩種不同的運作模式 適用於不同市場環境。
2011年軟考系統架構設計師學習筆記第四章
4.1 軟件開發方法
4.1.1 軟件開發生命週期
傳統的軟件生命期 是指軟件產品 從形成概念(構思)開始，經過定義、開發、使用、維護、廢棄，的全過程。
可以把軟件生命期劃分爲 軟件定義、軟件開發、軟件運行與維護，三個階段。
1、軟件定義時期
1.問題定義，目標系統“是什麼”，系統的定位以及範圍。
2.可行性研究，技術可行性、經濟可行性、操作可行性、社會可行性。
3.需求分析，確定軟件系統的功能需求、性能需求、運行環境的約束，寫出需求規格說明書、軟件系統測試大綱、用戶手冊概要。
充分理解用戶的需求，並以書面形式寫出規格說明書，這是以後軟件設計和驗收的依據;用戶也許很難 一次性 說清楚系統應該做什麼。
系統分析員、軟件開發人員、用戶，共同完成，逐步細化、一致化、完全化 等。
軟件需求規格說明 SRS，內容可以有 系統(或子系統)名稱、功能描述、接口、基本數據結構、性能、設計需求、開發標準、驗收原則 等。
2、軟件開發時期
軟件開發時期就是軟件的設計與實現，概要設計、詳細設計、編碼、測試 等。
概要設計是在軟件需求規格說明的基礎上，建立系統的 總體結構(含子系統的劃分) 和 模塊間的關係，定義功能模塊及各功能模塊之間的關係。
詳細設計對概要設計 產生的功能模塊 逐步細化，包括 算法與結構、數據分佈、數據組織、模塊間接口信息、用戶界面 等，寫出詳細設計報告。
測試可分成 單元測試、集成測試、確認測試、系統測試 等。通常把編碼和測試 稱爲系統的實現。
3、軟件運行和維護
軟件維護就是儘可能地延長軟件的壽命，沒有維護的價值時，宣告退役，軟件的生命結束。
4.1.2 軟件開發模型
軟件生存週期模型 又稱 軟件開發模型 或 軟件過程模型，模型的特點是 簡單化，是軟件開發實際過程的 抽象與概括。
爲軟件工程管理提供 里程碑和進度表，爲軟件開發過程提供 原則和方法。軟件過程有各種各樣的模型。
1、瀑布型
瀑布型的特點是 因果關係緊密相連，前一個階段工作的結果是後一個階段工作的輸入，前一個階段的錯漏會隱蔽地帶到後一個階段，每一個階段工作完成後，都要進行審查和確認，
它的出現有利於人員的組織管理，有利於軟件開發方法和工具的研究。
2、原型模型
根據用戶提出的軟件系統的定義，快速地開發一個原型，包含目標系統的關鍵問題和反映目標系統的大致面貌。
三種途徑：
利用模擬軟件系統的人機界面和人機交互方式。
真正開發一個原型。
找來一個或幾個正在運行的類似軟件進行比較。
實際工作中，由於各種原因，大多數原型都廢棄不用，僅僅把建立原型的過程 當作幫助定義軟件需要的一種手段。
用戶對系統模糊不清，無法準確回答目標系統的需求。
經過對原型若干次修改，應該收斂到目標範圍內，否則可能會失敗。
對大型軟件來說，如果沒有現成的，就不應該考慮用原型法。
3、螺旋模型
是生命週期模型與原型模型的一個結合，分成多個階段，每一個階段都由4部分組成：
1.目標設定，指定對過程和產品的約束，並且制訂詳細的管理計劃。
2.風險分析，制訂解決辦法。
3.開發和有效性驗證，即開發軟件產品。
4.評審，確定是否需要進入螺線的下一次迴路。
增加一週，軟件系統就生成一個新版本，系統應該儘快地收斂到用戶允許或可以接受的目標範圍內。
該模型支持大型軟件開發，適用於面向規格說明、面向過程、面向對象 的軟件開發方法，也適用於幾種開發方法的組合。
4、基於可重用構件的模型
把軟件工程項目所創建的 構件 不斷地積累和存儲在一個構件庫中，系統將依賴構件的健壯性。
5、基於面向對象的模型
構件重用是非常重要的技術之一。一方面進行構件開發，另一方面進行需求開發，快速建立 OOA、OOD 原型，由重用構件組裝而成，甚至通過組裝可重用的子系統而創建更大的系統。
6、基於四代技術的原型
四代語言 完全不用變成方式來構造應用系統，而是利用一些生成器。
與通常的軟件工程環境或計算機輔助軟件工程不同，只側重於支持應用軟件開發過程中的 設計階段和實現階段，特別是支持界面以及與界面有關的處理過程
4.1.3 敏捷方法
1、敏捷方法的特點
敏捷方法是“適應性”而非“預設性”的，重型方法在計劃制定完成後拒絕變化，而敏捷方法則歡迎變化。
“面向人的”而非“面向過程的”
傳統的軟件開發方法的基本思路一般是 只要圖紙設計得合理並考慮充分，施工隊伍可以完全遵照圖紙順利構造。
但是，一些設計錯誤只能在編碼和測試時才能發現。
傳統正規開發方法是 個體不重要，角色纔是重要的，儘量減少人的因素對開發過程的影響，但是敏捷方法正好相反。
管理人員已經脫離實際開發活動相當長的時間了，如此設計出來的開發過程是難以爲開發人員所接受的。
只有在第一線的開發人員才能真正掌握和理解開發過程中的技術細節，所以技術方面的決定必須由他們來做出。
敏捷方法特別強調 相關人員之間的信息交流。因爲項目失敗的原因最終都可以追溯到信息沒有及時準確地傳遞到應該接受它的人。
特別提倡直接的面對面交流，交流成本遠遠低於文檔的交流。
按照高內聚、鬆散耦合的原則 將項目劃分爲若干個小組，以增加溝通。
2、敏捷方法的核心思想
1.適應性型，利用變化來發展。
2.以人爲本，在無過程控制和過於嚴格繁瑣的過程控制中取得一種平衡，以保證軟件的質量。
3.迭代增量式的開發過程，發行版本小型化，根據客戶需求的 優先級和開發風險，制訂版本發行計劃。
3、敏捷方法的含義及其特徵
重型方法注重開發文檔的完備和充分性;而敏捷方法認爲最根本的文檔應該是源碼。
4、敏捷方法的適用範圍
實際上，滿足工程設計標準的唯一文檔是源代碼清單。
敏捷方法比較適合需求變化比較大 或者 開發前期對需求不是很清晰的項目。
敏捷方法對設計者、開發者、客戶 之間的有效溝通和及時反饋要求比較高，不易在開發團隊比較龐大的項目中實施。
5、敏捷方法的主要內容
四個核心價值觀：溝通、簡單、反饋、勇氣。
簡單：只要滿足當前功能需求，不做假象設計。
勇氣：用於抉擇，用於實踐，用於重構。
12條實踐規則：簡單設計、測試驅動、代碼重構、結對編程、繼續集成、現場客戶、開發版本小型化、系統隱喻、代碼集體所有制、規劃策略、規範代碼、40小時工作機制。
6、主要敏捷方法簡介
極限編程
水晶系列方法
開放式源碼，任何人發現Bug都可以將補丁發給維護者。
SCRUM
Coad的功用驅動開發方法：短時迭代階段 和 可見可用的功能，一個迭代週期一般爲兩週，編程人員分爲 類程序員、首席程序員。
ASD方法，猜測、合作、學習。
4.1.4 RUP
RUP把軟件開發生命週期劃分爲多個循環(cycle)，每個cycle生成產品的一個新版本，每個cycle依次由4個連續階段(phase)組成：
初始：定義最終產品視圖和業務模型，並確定系統範圍。
細化：制定工作計劃及資源要求。
構造。
移交。
迭代並不是重複地做相同的事，而是針對不同用例細化和實現，每一個迭代都是一個完整的開發過程。
每個階段結束前有一個里程碑(milestone)評估該階段的工作。如果未能通過該里程碑的評估，則決策者應該做出決定，是取消該項目還是繼續做該階段的工作。
RUP中的核心概念
角色(Role)，who的問題，某個人或一個小組的行爲與職責。
活動(Activity)，how的問題，是一個有明確目的的獨立工作單元。
製品(Artifact)，what的問題，是活動生成、創建、修改 第一段信息。
工作流(Workflow)，when的問題，每個工作流產生一些有價值的產品，並顯示了角色之間的關係。
RUP的特點
RUP是用例驅動的、以體系結構爲中心的、迭代和增量的軟件開發過程。
用例驅動：需求分析、設計、實現、測試，都是用例驅動的。
以體系結構爲中心：刻畫了系統的整體設計，去掉了細節部分，突出了系統的重要特徵。
不依賴於具體語言，是軟件設計過程的一個層次。
體系結構層次的設計問題包括：總體組織和全局控制、通訊協議、同步、數據存取、給設計元素分配特定功能、設計元素的組織、物理分佈、系統的伸縮性、性能 等。
一個系統不可能在所有特性上都達到最優，對於一個系統，不同人員所關心的內容也是不一樣的，對於不同類型的人員，只需提供這類人員關心的視圖即可。
分析和測試人員關心用例圖，最終用戶關心邏輯視圖，程序員關心實現視圖，系統工程師關心部署視圖。
RUB強調採用迭代和增量的方法來開發軟件，每次迭代中，之考慮系統的一部分需求，每次增加一些新的功能實現。
好處：
早期就可以對關鍵的、影響大的風險進行處理。
可以提出一個軟件體系結構來指導開發。
處理不可避免的需求變更。
可以較早地得到一個可運行的系統，鼓舞開發團隊的士氣，增強項目成功的信心。
更有效工作的開發過程。
沒有一個項目會使用RUP中所有的東西，用用RUP時要裁剪，裁剪步驟：
1.確定本項目 需要哪些工作流。
2.確定每個工作流要產出哪些製品。
3.確定四個階段之間(初始階段、細化階段、構造階段、移交階段)如何演進。
4.確定每個階段內迭代計劃。
5.規劃工作流內部結構。
4.1.5 軟件系統工具
按軟件過程活動將軟件工具分爲 軟件開發工具、軟件維護工具、軟件管理和軟件支持工具。
軟件開發工具有：需求分析工具、設計工具、編碼與排錯工具、測試工具 等。
需求分析工具，生成完整的、清晰的、一致的功能規範。功能規範是軟件開發者和用戶間的契約，也是軟件設計者的和實現者的依據。正確、完整 表達清晰的、無歧義的。
需求分析工具分爲 基於自然語言或圖形描述的工具，基於形式化需求定義語言的工具。
項目管理工具：項目的 計劃、調度、通信、成本估算、資源分配、質量控制等。
4.2 需求管理
需求 最終文檔 經過評審批准後，則定義了需求基線 Baseline;構築了 功能需求 和 非功能需求 的一個 約定Agreement。約定是需求開發和需求管理之間的橋樑。
需求管理是一個 對系統 需求變更、瞭解和控制 的過程，初始需求導出的同時 就啓動了需求管理規劃。
4.2.1 需求管理原則
過程能力成熟度模型 CMM，指導軟件過程改進，5個成熟級別，6個關鍵過程域KPA。
一旦需求 文檔化了，開發組和有關團隊 需要評審文檔。發現問題應與客戶或者其他需求源協商解決。軟件開發計劃是基於 已確認的需求。
絕不要承諾 任何 無法實現的事。
關鍵處理領域 通過版本控制和變更控制 來管理需求文檔。確保與新的需求保持一致。
4.2.2 需求規格說明的版本控制
版本控制是管理需求的一個必要方面，必須統一確定需求文檔的每一個版本，當需求發生變更時，及時通知所有涉及人員。
爲了儘量減少困惑、衝突、誤傳，應該僅允許指定的人員來更新需求。
清楚地區分草稿和文檔定稿版本。
4.2.3 需求變更
遲到的 需求變更 會對已進行的工作產生非常大的影響。
如果每一個建議的需求變更都採用，該項目將可能永遠無法完成。
需求文檔應該 精確描述 要交付的產品。
項目負責人 在信息充分的條件下 做出決策。
變更成本計算 應該包括 需求文檔的修改、系統修改的設計、實現的成本。
變更控制過程 並不是給變更設置障礙，相反，它是一個渠道和過濾器，確保採納最合適的變更，使變更產生的負面影響降到最低，變更過程應該做成文檔。
絕不能 刪除或者修改 變更請求的 原始文檔。
變更控制委員會 只要能決定合適的人做正確的事就足夠了，在保證權威性的前提下 應儘可能精簡人員。
對每個變更 權衡利弊 做出決定。
“利”包括 節省資金 或 額外收入、客戶滿意度、競爭優勢、減少上市時間;
“弊”是指 增加開發費用、推遲交付日期、產品質量下降、減少功能、用戶不滿意。
變更總是有代價的，即使 拒絕的變更 也因爲決策行爲 而耗費資源。
接受了重要的需求變更時，爲了適應變更情況 要與管理部門和客戶重新協商約定。推遲交貨時間、增加人手、推遲實現尚未實現的較低優先級的需求，或質量上進行折中。
要是不能獲得一些約定的調整，應該把面臨的風險寫進風險計劃中。
4.2.4 需求跟蹤
需求、體系結構、其他設計部件、源代碼模塊、測試、幫助文件、文檔 等。
跟蹤能力(聯繫)鏈(traceability link)是優秀需求規格說明書的一個特徵，確保軟件需求規格說明包括所有客戶需求。
跟蹤能力聯繫鏈 記錄了單個需求之間的 父層、互連、依賴 的關係。
不必擁有所有種類的跟蹤能力聯繫鏈，要根據具體情況調整。
4.2.5 需求變更的代價和風險
只有在知道變更成本後 才能做出理智的選擇，一個表面上很簡單的變更 也可能轉變成很複雜的局面。
影響分析 確定對現有系統做出是修改或者拋棄的決定，創建新系統以及評估每個任務的工作量，進行 影響分析的能力 依賴於 跟蹤能力、數據的質量、完整性。
4.3 開發管理
1、範圍
可交付物、架設、約束條件 的基礎上準備詳細的項目範圍說明書，是項目成功的關鍵。
2、時間
進度安排的準確程度可能比成本估計的準確程度更重要。對於成本估計的偏差，可以靠重新定價或大量的銷售來彌補成本的增加，
如果進度計劃不能得到實施，則會導致市場機會的喪失或用戶不滿意，而且會使成本增加。
工作分解結構 Work Breakdown Structure WBS
4.3.1 配置管理 文檔管理
1、配置管理
配置項 Configuration Item CI，
屬於產品組成部分的工作成果，如 需求文檔、設計文檔、源代碼、測試用例 等。
屬於項目管理和機構支撐過程域 產生的文檔，如 工作計劃、項目質量報告、項目跟蹤報告 等。
每個配置項的主要屬性有 名稱、標識符、文件狀態、版本、作者、日期 等。
2、文檔管理
文檔是影響軟件可維護性的決定因素，使用過程中必然會經受多次修改，所以文檔比程序代碼更重要。
用戶文檔：主要描述系統功能和使用方法。
系統文檔：描述系統設計、實現、測試 等各方面內容。
軟件文檔應該滿足下述要求：
1.如何使用
2.怎樣安裝 和 管理
3.需求 和 設計
4.實現 和 測試
說明用戶操作錯誤時 應該怎樣恢復和重新啓動。
4.3.2 軟件開發的質量與風險
1、軟件質量
IOS9000 對 項目質量 的定義：一組固有特性 滿足需求的 程度。
質量 與 範圍、成本 和 時間，是項目成功的關鍵因素，通過範圍管理 轉換隱含需求爲項目需求。
質量低 說明產品或服務存在問題，而低等級的產品或服務 不一定存在問題，二者概念不同。
2、軟件開發風險
認識不足 或者 沒有足夠的力量加以控制。
瞭解、掌握 風險的來源、性質、發生規律，進而施行有效的管理。
或然性、不確定性、涉及到某種選擇時，才成爲有風險，以上三個是風險定義的必要條件，不是充分條件，具有不確定性的事件不一定是風險。
4.3.3 結構化分析與設計
結構程序設計 較流行的定義爲：採用自頂向下 逐步求精 的設計方法 和 單入口單出口的控制構件。
自頂向下逐步求精的方法是：先整體後局部，先抽象後具體，一般具有較清晰的層次。
僅使用單入口單出口的控制構件，具有良好的結構特徵。
採用結構程序設計，可能會多佔用一些時間和空間資源，這也是那些反對從高級語言中排除GOTO語句者的主要依據。實際上，硬件飛速發展，這點耗費，不再是重要的因素。
4.3.4 面向對象的分析設計
面向對象的 分析模型主要由 頂層架構圖、用例與用例圖、領域概念模型 構成;
設計模型包含：
以包圖表示的 軟件體系結構圖、
以交互圖表示的 用例實現圖、
完整精確的類圖、
針對複雜對象的狀態圖、
描述流程化處理過程的 活動圖 等。
4.4 軟件的重用
重複使用 相同或相似 軟件元素。
軟件元素：需求分析文檔、設計過程、設計文檔、程序代碼、測試用例、領域知識 等，通產這些軟件元素稱爲 軟部件。
不斷地進行軟部件的積累，並將它們組織成軟部件庫。
橫向重用(horizontal reuse)：重用不同應用領域中的軟件元素。
標準函數庫 是一種 典型的、原始的 橫向重用機制。
縱向重用廣受矚目，並稱爲軟件重用技術的真正希望所在，關鍵點是 域分析，根據應用領域的 特徵 以及 相似性 預測軟部件的可重用性。
庫的組織結構 直接影響軟部件的檢索效率。
由於軟部件大都經過嚴格的質量認證，並在實際運行環境中得到檢驗，因此重用軟部件有助於改善軟件質量。
4.5 逆向工程與重構工程
逆向工程 就是 分析已有的程序，尋找比源代碼更高級的抽象表現形式。
相關概念：
重構 Restructuring，在同一抽象級別上轉換系統描述形式;
設計恢復 design recovery，
重構工程 re-engineering，也稱 修復和改造工程。
1、恢復信息的級別
逆向工程導出的信息，4個抽象層次
1.實現級
2.結構級
3.功能級
4.領域級
2、恢復信息的方法，4類：
1.用戶指導下搜索與變換
2.變換式方法
3.基於領域知識的
4.鉛板恢復法
2011年軟考系統架構設計師學習筆記第五章
軟件架構設計
Software Architecture 簡稱 SA
5.1.1 軟件架構設計與生命週期
1、需求分析階段
需求 和 SA設計 面臨的是不同的對象：一個是問題空間;另一個是解空間。保持二者的可跟蹤性和轉換。
2、設計階段
1.傳統的設計概念只包括 構件，隨着研究的深入，構件間的 互聯機制 逐漸獨立出來，成爲與構件同等級別的實體，稱爲 連接子。
2.體系結構描述語言(Architecture Description Language ADL)對 連接子 的重視成爲區分 ADL和其他建模語言的重要特徵之一。
3.不同的視角 得到多個視圖，組織起來以描述整體的SA模型;不同側面的視圖反映所關注的系統的特定方面，體現了關注點分離的思想。
3、實現階段
團隊的 結構 應該和體系結構模型有一定的對應關係，提高軟件開發 效率和質量。
分析和記錄 不同版本構件和連接子之間的演化。
填補高層 SA模型 和 底層實現 之間的鴻溝，典型的方法如下：
1.引入實現階段的概念。
2.SA模型 逐步精化。
3.封裝底層稱爲較大粒度構件。
4、構件組裝階段
可複用構件 組裝 可以在較高層次上實現系統，研究內容包括：
1.如何互聯。
2.如何檢測並消除體系結構失配問題。
中間件跨平臺交互。
產品化的中間件更好地保證最終系統的質量，中間件導向的體系結構風格。
失配是指複用過程中，待複用構件對最終系統的體系結構和環境的架設(Assumption)與實際狀況下不同而導致的衝突。
5、部署階段
軟件構件的互聯性、硬件的拓撲結構、硬件資源佔用。
6、後開發階段
實現中的軟件往往具有動態性，一類是軟件內部執行所導致的體系結構改變，另一類變化是軟件系統外部的請求對軟件進行的重配置。
升級或進行其他修改時 不能停機。
SA重建是指 從已實現的系統中 獲取體系結構的過程。
5.2 基於架構的軟件開發方法
5.2.1 體系結構的設計方法概述
基於體系結構的軟件設計(Architecture-Based Software Design ABSD)方法。
體系結構驅動，指 構成體系結構的 商業、質量、功能 需求的組合驅動。
設計活動的開始 並不意味着 需求抽取和分析活動 就可以終止，而應該 並行，快速開始設計 至關重要。
ABSD 方法有三個基礎，功能分解、選擇體系結構風格、軟件模板的使用。
5.2.2 概念與術語
1、設計元素
ABSD方法是一個 自頂向下，遞歸細化 的方法。
2、視角與視圖
重要的是從不同的視角(perspective)來檢查，考慮體系結構的不同屬性。
3、用例和質量場景
在使用用例捕獲功能需求時，通過定義特定場景來捕獲質量需求，稱爲質量場景。捕獲變更、性能、可靠性、交互性，質量場景必須包括 預期的 和 非預期的。
5.2.3 體系結構需求
可以從需求庫中取出，加以利用和修改。
獲取需求，體系結構需求一般來自三個方面：系統的質量目標、系統的商業目標、開發人員的商業目標。
5.2.4 體系結構文檔化
體系結構規格說明 和 測試體系結構需求的質量設計說明書。
需求模型構件的 精確形式化描述，作爲 用戶和開發者 之間的一個協約。
從使用者的角度進行編寫，必須保證開發者手上的文檔是最新的。
5.2.5 體系結構複審
根據架構設計，搭建一個可運行的最小化系統 用於 評估 和 測試 體系架構是否滿足需要。是否存在可識別的技術和協作風險。
複審的目的是 標識潛在風險，及早發現 缺陷和錯誤。
5.2.6 體系結構實現
分割成規定的構件，按規定方式互相交互。
5.3 軟件架構風格
體系結構設計 核心目標是 重複的體系結構模式，體系結構級的 軟件重用。
5.3.1 軟件架構風格概述
一個體繫結構 定義 一個詞彙表 和 一組約束。詞彙表中包含 構件和連接件類型約束指出 如何 組合起來。
體系結構風格 反映了 共有的結構和語義特性，並指導如何 組織成一個完整的系統。
5.3.2 經典軟件體系結構風格
每個構件都有一組輸入和輸出，數據輸入構件，經過內部處理，然後產生數據輸出。這裏的構件稱爲 過濾器。
構件是對象。
分層系統，每一層爲上層提供服務，並作爲下層的客戶。除一些精心挑選的 輸出函數外，內部的層接口只對 相鄰層可見。由於一層最多隻影響兩層，爲軟件重用提供了強大的支持。
倉庫風格中，兩種不同的構件：中央數據結構、獨立構件。
若構件控制共享數據，則倉庫是一傳統型數據庫;若中央數據結構 的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
C2 體系結構 通過連接件綁定在一起 按照一組規則運作的並行構件網絡。構件與構件之間的連接是不允許的。
5.3.3 客戶/服務器 風格
宿主機應用程序 既負責與用戶的交互(前端)，又負責對數據的管理(後端)。
C/S 體系結構 定義了工作站如何與服務器相連，實現部分數據和應用 分佈到多個處理機上。
C/S三個主要組成部分：服務器、客戶機、網絡。
易於對系統進行擴充和縮小。
功能構件充分隔離，客戶應用程序的開發集中於數據的顯示和分析，數據庫服務器的開發集中於數據的管理，將大應用處理任務分佈到許多通過網絡連接的低成本計算機上，模型思想簡單。
開發成本高，尤其是軟件不斷升級，客戶端變得越來越臃腫。
信息內容和形式單一，用戶獲得的只是單純的字符和數字。
軟件移植困難，維護升級困難。
5.3.4 三層 C/S 結構風格。
三層 C/S 體系結構中，可以將 整個應用邏輯 駐留在應用服務器上，只有表示層存在於客戶機上，稱爲“瘦客戶機”。表示層、功能層、數據層。
表示層一般要使用圖形用戶界面 GUI。
功能層之間的數據交互 要 儘可能簡潔，一次性傳輸。
數據層不同層構件 相互獨立，層間接口簡潔，適合複雜事務處理
5.3.1 軟件架構風格概述
一個體繫結構 定義 一個詞彙表 和 一組約束。詞彙表中包含 構件和連接件類型約束指出 如何 組合起來。
體系結構風格 反映了 共有的結構和語義特性，並指導如何 組織成一個完整的系統。
5.3.2 經典軟件體系結構風格
每個構件都有一組輸入和輸出，數據輸入構件，經過內部處理，然後產生數據輸出。這裏的構件稱爲 過濾器。
構件是對象。
分層系統，每一層爲上層提供服務，並作爲下層的客戶。除一些精心挑選的 輸出函數外，內部的層接口只對 相鄰層可見。由於一層最多隻影響兩層，爲軟件重用提供了強大的支持。
倉庫風格中，兩種不同的構件：中央數據結構、獨立構件。
若構件控制共享數據，則倉庫是一傳統型數據庫;若中央數據結構 的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
C2 體系結構 通過連接件綁定在一起 按照一組規則運作的並行構件網絡。構件與構件之間的連接是不允許的。
5.3.3 客戶/服務器 風格
宿主機應用程序 既負責與用戶的交互(前端)，又負責對數據的管理(後端)。
C/S 體系結構 定義了工作站如何與服務器相連，實現部分數據和應用 分佈到多個處理機上。
C/S三個主要組成部分：服務器、客戶機、網絡。
易於對系統進行擴充和縮小。
功能構件充分隔離，客戶應用程序的開發集中於數據的顯示和分析，數據庫服務器的開發集中於數據的管理，將大應用處理任務分佈到許多通過網絡連接的低成本計算機上，模型思想簡單。
開發成本高，尤其是軟件不斷升級，客戶端變得越來越臃腫。
信息內容和形式單一，用戶獲得的只是單純的字符和數字。
軟件移植困難，維護升級困難。
5.3.4 三層 C/S 結構風格。
三層 C/S 體系結構中，可以將 整個應用邏輯 駐留在應用服務器上，只有表示層存在於客戶機上，稱爲“瘦客戶機”。表示層、功能層、數據層。
表示層一般要使用圖形用戶界面 GUI。
功能層之間的數據交互 要 儘可能簡潔，一次性傳輸。
數據層不同層構件 相互獨立，層間接口簡潔，適合複雜事務處理
5.4.4 DSSA 的建立過程
一般情況下，需要用 開發者習慣使用的工具和方法 建立DSSA模型。
DSSA建立過程分爲5個階段，過程是 併發的、遞歸的、反覆的，可能每個階段經歷幾遍，每次增加更多的細節。
1、定義領域範圍，一系列用戶的需求。
2、定義領域特定的元素，編譯領域字典、領馭屬於的同義詞詞典。
3、定義特定的設計和實現需求約束，不僅要識別出約束，並且要 記錄 約束對設計和實現 造成的後果，還要記錄對處理這些問題時所產生的所有問題的討論。
4、定義領域模型和體系結構，產生一般的體系結構，並說明構成它們的模塊或構件的語法、語義。
5、蒐集可重用的產品單元，爲DSSA增加構件。
5.5.1 系統架構的評估
評估 可以只針對一個體繫結構，也可以針對一對一組體系結構。關注的是 質量屬性。
1、性能，是指系統的響應能力，多長時間 對某個事件做出響應，或者 某段時間內系統所能處理的事件的個數。
2、可靠性，是最重要的軟件特性，平均失效等待時間 MTTF，平均失效間隔時間 MTBF
1.容錯，內部修復。
2.健壯性，不受錯誤使用和錯誤輸入的影響。
3、可用性，正常運行的時間比例。經常用兩次故障之間的時間長度或恢復正常的速度來表示。
4、安全性，阻止非授權用戶。分爲 機密性、完整性、不可否認性、可控性 等特性。
5、可修改性，通過考察 變更的代價 衡量可修改性。
1.可維護性，主要體現在問題修復上，做局部性的修改並能使對其他否見的負面影響最小化。
2.可擴展性，新特性來擴展軟件系統，改進版本來替換構件並刪除不需要的特性構件，需要鬆散耦合的構件。
3.結構重組，需要精心設計構件之間的關係。
4.可移植性。
6、功能性，完成所期望的工作 的能力。
7、可變性。
8、互操作性，精心設計的軟件入口。
5.5.2 評估中重要概念
敏感點 權衡點，是關鍵的體系結構決策。
敏感點是 構件(和/或 構建之間的關係)的特性。研究敏感點可使人員明確在實現質量目標時 應注意什麼。
權衡點 是多個質量屬性的 敏感點。
風險承擔着 或稱爲 收益相關人。
場景，首先要精確地得出具體的質量目標，爲得出這些目標採用的機制叫做場景。從風險承擔者的角度與系統的交互的簡短描述。
刺激、環境、響應，三個方面描述場景。
5.5.3 主要評估方法
1、SAAM 非功能質量屬性的體系結構分析方法，是最早形式成文檔並得到廣泛使用的分析方法。最初它用於比較不同的軟件體系結構，以分析SA的可修改性。
1.特定目標，目標是對描述應用程序屬性的文檔，驗證假設和原則，有利於評估固有的風險。
2.評估技術，使用場景技術，描述了各種系統 必須支持的活動 和 將要發生的變化。
3.質量屬性，可修改性 是 SAAM分析的主要 質量屬性。
4.風險承擔者，SAAM 協調不同參與者所感興趣的方面，作爲後續決策的基礎，提供了對系統結構的 公共理解。
5.體系結構描述，描述形式 應該被所有參與者理解。功能、結構、分配，三個主要方面。
6.方法活動，SAAM 的主要輸入問題是 描述、需求聲明、體系結構描述。
SAAM 分析評估 體系結構過程包括 5個 步驟：場景開發、體系結構描述、單個場景評估、場景交互、總體評估。
通過各類 風險承擔者協商討論，開發一些 任務場景，體現系統所支持的 各種活動。
通過對場景交互的分析，得出系統中所有場景對系統中構件所產生影響的列表。總體的 權衡 和 評價。
2、ATAM
體系結構權衡分析方法，主要針對 性能、實用性、安全性、可修改性。
確定多個質量屬性之間 這種 的必要性。
體系結構空間 受到 歷史遺留系統、互操作性 和 以前失敗的項目 約束。
邏輯視圖被分爲 功能結構 和 代碼結構。這些結構加上他們之間適當的映射可以完整地描述一個體繫結構。
用一組 消息順序圖 顯示運行時的 交互 和 場景。
從不同的體系結構角度，有三種不同場景，用例、增長場景、探測場景。
ATAM 使用定性的 啓發式分析方法 QAH，構造 精確分析模型時 要進行分析。
4個主要的活動領域(或階段)，場景和需求收集、結構視圖和場景實現、屬性模型構造和分析、分析、折中。
屬性分析是互相依賴的。獲得屬性交互的方法有兩種，敏感度分析來發現折中點、通過檢查假設。
迭代的改進。除了通常從場景派生而來的需求，還有很多對 行爲模式和執行環境的 假設。
由於屬性之間存在折中，每一個架設都要被 檢查、驗證、提問，完成所有操作後，把分析的 結果和需求 進行對比。
領馭知識庫通過基於屬性的 體系結構風格ABAS 維護，變得更爲慣例化、更可預測，得到一個標準問題集合。
2011年軟考系統架構設計師學習筆記第六章
6.1 UML 建模與架構文檔化
方法種類的膨脹，極大地妨礙了用戶的使用和交流。
UML通過統一的表示法，使不同知識背景的 領域專家、系統分析、開發人員、用戶 可以方便地交流。
6.1.1 UML 體系結構演變
UML 是用 元模型 描述的，元模型是 4層元模型體系結構模式中的一層，其他層次分別是 元-元模型、模型層、用戶對象曾。其中元模型層由 元-元模型層 導出。
元模型的體系結構模式 可以用來定義 複雜模型 所要求的 精確定義，這種複雜模型通常需要被 可靠地 保存、共享、操作 以及在工具之間進行交換。它的特點如下：
1、在每一層都遞歸地定義語義結構。
2、可用來定義 重量級和輕量級 擴展機制。
3、在體系結構上 將其他體系結構的標準統一起來。
UML 元模型又被分解爲三個邏輯子包：基礎包、行爲元素包、模型管理包。
6.2 UML 基礎
UML 通過 圖形化的表示機制 從多個側面 對系統的分析和設計模型進行刻畫。
10種視圖，四類：
1、用例圖
2、靜態圖，包括 類圖、對象圖、包圖。
類圖的邊表示類之間的聯繫，包括 繼承、關聯、依賴、聚合 等。
對象圖描述在某種狀態下或某一時間段，系統中 活躍的對象及其關係。
包由 子包、類 組成。
3、行爲圖，包括 交互圖、狀態圖、活動圖，他們從不同的側面刻畫系統的動態行爲。
交互圖分爲 順序圖、合作圖。順序圖強調 對象之間 消息發送的時序。合作圖更強調對象間 的動態協作關係。
狀態圖 描述 對象的動態行爲。
活動圖 描述 操作序列，這些操作序列 可以併發、同步，包含控制流、信息流。
4、實現圖，包括 構件圖、部署圖。描述組成和分佈情況。
部署圖 節點表示實際的計算機和設備，邊表示節點之間的物理連接，也可以顯示連接的類型及節點之間的依賴性。
6.2.1 用例和用例圖
用例圖 也翻譯爲 用況、用按 等，在 UML 中，用例用一個橢圓表示，往往用 動賓結構 或 主謂結構 命名。
可選的 動作序列 和 會出現異常的動作序列。
用例是代表系統中 各種相關人員之間 就係統的行爲所達成的契約。
需求階段 用例是 分析人員與客戶溝通的工具 項目規模估算的依據;
設計階段 用例是 系統功能設計的主要輸入;
實現階段 用例是 檢測類型爲正確性的文檔。
本質上，用力分析 是一種功能分解 的技術。
1、參與者角色，參與者實際上並不是系統的一部分。
2、用例間的關係，泛化、包含、擴展 等。
包含是比較特殊的依賴關係。
擴展，基本用例必須聲明 若干“擴展點”，而這些擴展用例只能在這些擴展點上增加新的行爲和含義。
3、用例圖
建模人員可以在途中給某些圖符加上填充色，在語義上，使用填充顏色和不使用填充顏色的模型是 一樣的。
6.2.2 交互圖
描述對象之間 對象與參與者之間 動態協作關係 協作過程中行爲次序。
通常描述用例的行爲，顯示該用例中所涉及的對象 對象之間的消息傳遞。
順序圖、協作圖 之間可以互相轉化，一個用例需要多個順序圖或協作圖。
交互圖可以幫助分析人員 對照檢查 每個用例中所描述的 用戶需求，提醒分析人員去補充遺漏的類或方法。
水平方向爲對象維，一般 主要參與者放在最左邊，次要參與者放在最右邊。
垂直方向爲時間維。
6.2.3 類圖和對象圖
一般而言，類的名字是 名詞。
類之間的關係 有 關聯、聚集、組合、泛化、依賴 等。
1、關聯，鏈 是關聯的實例，關聯表示 類與類之間的關係，鏈表示 對象與對象之間的關係。
關聯用 實線表示，角色還具有多重性。
關聯類 描述關聯的 屬性、操作、以及其他信息。
關聯類 通過一條虛線與關聯連接。
自返關聯 又稱 遞歸關聯，同一個類的兩個對象間的關係。兩個關聯端，每個關聯端的角色不同。
2、聚集和組合
聚集 是一種特殊形式的 關聯，類之間整體與部分的關係。
組合 整體與部分具有同樣的生存期，是一種特殊形式的聚集。
3、泛化關係，一般和特殊元素之間的關係，就是平常所說的繼承關係。
6.2.4 狀態圖和活動圖
1、狀態圖
描述 對象 生存期間的 動態行爲，所經歷的狀態序列，引起狀態轉移的 事件、動作。
是 UML 動態行爲建模的 5個圖之一，用 狀態機 對一個對象的生命週期建模，狀態圖 用於顯示狀態機，重點在於 狀態之間的控制流。
除了 初態和終態，還有 Idle 和 Running 兩個狀態，keyPress、finished、shutDown 是事件。
2、活動圖
是 UML 動態行爲建模的 5個圖之一，描述系統的 工作流程 和 併發行爲。狀態圖的特殊形式，一個活動結束後將立即進入下一個活動。
基本概念：活動、泳道、分支、分叉、匯合、對象流。
1.活動，注意區分 動作狀態 和 活動狀態，
動作狀態是原子的，沒有內部轉移，沒有內部活動，所佔用的時間可以忽略，目的是執行進入動作，然後轉向另一個狀態。
活動狀態是可分解的，工作完成需要一定的時間。
2.泳道，是活動圖中區域劃分，每個泳道代表一個責任區，知道和類並不是一一對應的關係。
3.分支，同一個觸發事件，可以根據不同的警戒條件轉向不同的活動，每個可能的轉移是一個分支。
4.分叉和匯合，如果要表示 系統或對象中的併發行爲，使用分叉fork 和 匯合join，匯合正好與分叉相反。
5.對象流，活動圖中可以出現對象，對象可用作爲活動的輸入輸出。活動圖中的對象流表示活動和對象之間的關係。
6.2.5 構件圖
構件是系統中 遵從一組接口 且提供其實現的 物理的、可替換 的部分。
構件圖 顯示一組構件 以及它們 之間的相互關係，包括 編譯、連接、執行時 構建之間的依賴關係。
構件就是一個實際文件，以下幾種類型：
1、部署構建
2、工作產品構件
3、執行構件
構件圖可以對以下幾個方面建模：
1、對源代碼文件之間的相互關係建模。
2、對可執行文件之間的相互關係建模。
6.2.6 部署圖
部署圖 也稱 配置圖、實施圖，顯示系統中計算節點的 拓撲結構、通信路徑、節點上運行的軟構件等。
一個系統模型只有一個部署圖，常用語幫助理解分佈式系統。
部署圖 由 體系結構設計師、網絡工程師、系統工程師 等 描述。
6.3 基於 UML 的軟件開發過程
6.3.1 開發過程概述
UML 是獨立於軟件開發過程的，能夠在幾乎任何一種軟件開發過程中使用。迭代的漸進式軟件開發過程包含四個階段：初啓、細化、構件、部署。
1、初啓
項目的發起人 確定項目的 主要目標 和 範圍，初步的可行性分析 和 經濟效益分析。
2、細化
細化階段的開始 標誌着 項目的正式確立。
1.初步的需求分析，比較重要、比較有風險的用例。
2.初步的高層設計，用例、用例圖、類、類圖 將 依據 包 的劃分方法 分屬於 不同包。
3.部分的詳細設計，根據軟件元素 的重要性和風險程度 確立優先細化原則，不能將風險的識別和解決延遲到細化階段後。
4.部分的原型構造。
3、構建
構造階段，每次迭代中實現一部分用例，用戶可以及早參與對已實現用例的實際評價。
原則：
1.用戶認爲業務價值較大的用例 應 優先安排。
2.開發人員評估後 認爲 開發風險較高的用例 優先 安排。
迭代計劃中，要確定迭代次數、每次迭代所需時間 以及 每次迭代中應完成的用例。
6.3.2 基於 UML 的需求分析
1、生成用例
如果多個用戶扮演同一角色，這些用戶將由單一執行者表示。如果一個用戶扮演多種角色，則需要多個執行者來表示同一用戶。
用例主要來源於分析人員對 場景的 分類和抽象，即將相似的場景進行歸類，使一個用例可以通過實例化和參數調節而涵蓋多個場景。
2、用活動圖表示用例
3、生成用例圖
執行者與用例之間的關係有兩種：觸發執行、信息交換。
執行者指向用例 表示 觸發執行 和/或 信息交換，用例指向執行者 表示用例將生成的信息傳遞給執行者。
4、建立頂層架構
頂層架構便於開發人員 聚焦於系統的不同部分。
模型——視圖——控制器(Model、View、Controller，MVC)模式。
模型 維護並保存數據，視圖 呈現數據，控制器將動作映射爲處理功能並實際調用。
MVC 模式特別適合於分佈式應用軟件，尤其是web應用系統。
分層模式 降低軟件系統的 耦合度。
確立頂層架構的過程中需綜合考慮以下因素：
包的數量，架構過早地陷入細節，返工的可能性很大，也不合理地限制了後續分析和設計活動的自由空間。
包之間的耦合度。
將不穩引起的軟件元素分類聚集於少數幾個包中，以提高軟件系統的可維護性。
可選功能 和 必須實現的功能 置於 不同的包。
根據開發人員 專長 劃分，使每個包都能分配給最合適的開發人員，有利於並行開發。
6.3.3 面向對象的設計方法
1、設計用例實現方案
1.提取邊界類，實現類和控制類。
邊界類用於描述 系統與外部環境之間的交互。
a.界面控制。
b.外部接口。
c.環境隔離。使目標軟件系統的 其餘部分 儘可能地 獨立於環境軟件。
邊界類，《boundary》。
實體類“內向收斂”特徵，僅提供 讀/寫 信息的必要操作 作接口，並不涉及業務邏輯處理，《entity》。
控制類，《control》。
邊界類的作用範圍可以超越單個用例
2.構造交互圖
交互圖作爲用力的精確實現方案。
事件流中的事件 直接對應交互圖中的消息，事件間的先後關係體現爲 交互圖中的時序，對消息的響應 則構成消息接收者的職責，這種職責被確立爲 類的方法。
不應該出現 穿越控制類 生命線 的消息。
爲 易於理解，應該用分離的 UML 交互圖 分別表示 事件流和每個備選事件流。
原則上，每個類都應該有一個操作來響應交互圖中指向其對象的那條消息。
2、設計技術支撐方案
當用戶需求發生變化時，技術支撐方案應具有良好的穩定性。
技術支撐方案應該位於層次結構中的較低層次。
一方面取決於 需求，另一方面取決於 對軟件技術手段把我和選取。
3、設計用戶界面
1.熟悉用戶 並對 用戶分類，以便儘量照顧到所有用戶的合理要求，並優先滿足某些特權用戶。
2.按用戶類別 分析用戶的 工作流與習慣，從每類中選取一個用戶代表，建立調查表，判斷用戶對操作界面的需求和喜好。
3.首先應考慮命令的順序，一般常用命令居先，與用戶工作習慣保持一致;其次，根據外部服務之間的聚合關係組織相應的命令;然後充分考慮人類記憶的侷限性，最好組織爲一顆兩層多叉樹;提供操作的快捷方式。
5.利用快速原型演示，改進界面設計。並評判系統是否 齊全、方便、好用。
4、精化設計模型
對模型進行改進的活動可以分爲 精化 和 合併 兩種。一般先從精化開始。設計優秀的粗粒度組件應該只是完成一項功能，這一點是它與子系統的主要區分。
粗粒度組件的範圍過於廣泛，難以發揮重用價值，粗粒度組件擁有持久化的行爲，擁有業務邏輯，需要表示層的支持。
將需求分成幾個功能組，基本上就可以得到相應的粗粒度組件了。
過小的範圍，將會造成粗粒度組件不容易使用，用戶需要理解不同的粗粒度組件之間的複雜關係。
如果可能，在粗粒度組件之間定義單項關聯可以有效的減少組件之間的耦合。
儘可能簡化組件之間的關係。
我們需要從軟件的目標領域中 識別出關鍵性的實體，或者說領域中的名詞。然後決定它們應該歸屬於那些粗粒度組件。
兩個組件之間存在重複的要素，可以從中抽取共性的部分，形成新的組件。
6.4 系統架構文檔化
6.4.1 模型概述
以精心選擇的形式 將若干結構元素進行裝配。
軟件架構 = { 元素，形式，關係/約束 }
邏輯視圖(logical view)對象模型。
過程視圖(process view)併發和同步特徵。
物理視圖(physical view)分佈式。
開發視圖(development view)靜態組織結構。
Rational 4.1 視圖模型。
每個視圖上均獨立地應用 Perry&Wolf 軟件架構公式。
對每種視圖選用特定的 架構風格(architectural style)。
6.4.2 邏輯結構
邏輯架構主要支持功能性需求，系統分解爲一系列的關鍵抽象，(大多數)來自於問題域，表現爲對象或對象類的形式。
抽象、封裝、繼承。
對於數據驅動程度高的應用程序，可以使用其他形式的邏輯視圖，如 E-R圖 代替面向對象的方法。
1、邏輯視圖的風格
採用面向對象的風格，試圖在整個系統中 保持 單一的、一致的 對象模型。
6.4.3 進程架構
進程架構考慮一些非功能性的需求，併發性、分佈性、系統完整性、容錯性，以及邏輯視圖的主要抽象如何與進程結構相配合在一起。
進程是 構成可執行單元任務的分組。
區分主要次要任務：主要任務是 可以唯一處理的架構元素;次要任務是 由於實施原因而引入的局部附加任務。
6.4.4 開發架構
開發架構關注軟件開發環境下實際模塊的組織。
開發架構用模塊和子系統圖來表達，顯示了“輸出”和“輸入”關係。
考慮因素：開發難度、軟件管理、重用性、通用性、由工具集、語言 所帶來的限制。
開發視圖 是建立產品線的 基礎。
推薦使用分層(layered)的風格，每層具有良好定義的職責。某層子系統依賴同一層或低一層的子系統，最大程度地減少了具有複雜模塊依賴關係的 網絡的開發量
6.4.5 物理架構
物理架構主要關注系統非功能性的需求，可用性、可靠性(容錯性)，性能(吞吐量)、可伸縮性。
軟件至節點的映射需要高度的靈活性 及 對源代碼產生最小的影響。
6.4.6 場景
4種視圖的元素通過數量比較少的一組重要場景(更常見的是用例)進行無縫協同工作，我們爲場景描述相應的腳本(對象之間和過程之間的交互序列)。
在某種意義上 場景是最重要的 需求抽象。
4+1 的 +1 起到了兩個作用：
作爲一項驅動因素 來發現架構設計過程中的 架構元素。
作爲架構原型測試的出發點。
場景表示法與組件邏輯視圖非常相似，但它使用過程視圖的連接符來表示對象之間的交互。
6.4.7 迭代過程
在進行文檔化時，提倡一種更具有迭代性質的方法——架構先被原型化、測試、估量、分析，然後在一系列的迭代過程中被細化。
除了減少 風險之外，還有其他優點：團隊合作、培訓、加深對架構的理解、深入程序和工具 等。使 需求被細化、成熟化。
系統大多數關鍵的功能以場景的形式被捕獲，關鍵意味着：最重要的功能、系統存在的理由、使用頻率最高的功能、必須減輕的一些重要技術風險。
2011年軟考系統架構設計師學習筆記第七章
7.1 設計模式概述
重複遇到的典型問題，描述這些共同問題和解決這些問題的方案 就形成了所謂的模式。
7.1.1 設計模式的歷史
模式分爲幾個部分：
特定的情景(Context)，指模式在 何種情況下發生作用;
動機(System of Force)，指問題或預期的目標;
解決方案(Solution)，平衡各動機 或解決所闡述問題的 構造或配置。
每個模式描述了一個在某種特定情境下不斷重複發生的問題，以及解決該問題解決方案的核心所在。
7.1.2 爲什麼要使用設計模式
面向對象設計時需要考慮 封裝性、力度大小、依賴關係、靈活性、可重用性 等。
1、簡化並加快快設計
無需從底層做起，重用成功的設計，節約開發時間，提高軟件質量。
2、方便開發人員之間的通信
可以更準確地 描述問題 及 問題的解決方案，使解決方案具有一致性。
3、降低風險
4、有助於轉到面向對象技術
開發人員對新技術往往會有抵觸或排斥心理，對成熟的設計模式具有以下特性：
1.巧妙。
2.通用，不依賴於 系統、語言、領域。
3.不僅僅停留在理論上。
4.簡單。
5.可重用。
6.面向對象。
7.1.3 設計模式的組成元素
1、模式名，簡潔地描述了 模式的本質，可以幫助我們思考。
2、問題或意圖，解釋了設計問題和問題存在的前因後果，可能描述了特定的設計問題。
3、情景，告訴我們該模式的適用性。
4、動機，描述相關的動機和約束，通常需要對各期望的目標進行有限排序，動機闡明瞭問題的複雜性，定義了在相互衝突時所採取的各種權衡手段。
5、解決方案，因爲模式就像一個模板，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的 抽象描述 和怎樣用一個 具有一般意義的 元素組合。
6、示例，幫助讀者理解模式的具體使用方法。
7、結果情景，闡述了模式後續狀態和副作用。
8、基本原理，解釋該模式 如何、爲何 能解決當前問題。
9、相關模式，包括 靜態的 和 動態的，遷到模式、後續模式、替代模式。
10、已知應用，通常好的模式前面都有一個摘要，提供簡短的總結和概述，爲模式描繪出一個清晰的圖畫，提供有關該模式能夠解決問題的快速信息。
新技術可能帶來的效果持懷疑態度。
模式應該說明它的目標讀者，以及對讀者有哪些知識要求。
7.1.4 設計模式的分類
軟件模式 主要可分爲 設計模式、分析模式、組織和過程模式等。
設計模式主要用於 得到簡潔靈活的 系統設計。
按設計模式的目的劃分，創建型、結構型、行爲型;
按設計模式範圍劃分，類設計模式、對象設計模式。
1、創建型模式，對對象實例化過程的 抽象，採用抽象類所定義的接口，封裝了對象如何創建、組合等信息。
2、結構型模式，如何組合已有的類和對象 以及獲得更大的結構。
3、行爲型模式，不僅描述對象或類的模式，還描述它們之間的通信模式，特別是描述一組對等的對象怎樣互相協作 完成其中任一對象無法單獨完成的任務。
7.2 設計模式實例
7.2.1 創建性模式
通過該了的子類來創建對象的。但是，這可能會 限制在系統內創建對象的類型或數目。
1、Abstract Factory 模式
在不指定具體類的情況下，爲創建一些列 相關 或 相互依賴的對象提供了接口。
提供了一個可以 確定合適的具體類 的抽象類。
優點：
可以與具體類分開。
更容易在產品系列中轉換。
提高了產品間的一致性。
以下情況應該使用 Abstract Factory 模式：
系統獨立於產品的 創建、組成、表示。
系統配置成 具有多個產品的 系列。
相關產品對象系列 是共同使用的，而且必須確保這一點。
你希望提供產品的類庫，只開放其接口。
2、Builder 模式
將複雜對象的 構件與表示 相分離，相同的構造過程可以創建不同的對象，通過只指定對象的 類型和內容。
一次就可以創建所有的複雜對象，而其他模式一次就只能創建一個對象。
優點：
可以對產品內部表示進行改變。
將構造代碼與表示代碼相分離。
以下情況應該使用 Builder 模式：
算法獨立於 組成對象。
構造過程必須允許已構件對象有不同表示。
3、Factory Method 模式
實例化工作交給其子類，可以在不修改代碼的情況下引入新類，因爲新類只實現了接口。
優點：
代碼只處理接口，因此可以使用任何實現了接口的類。
在類中創建對象比直接在客戶端創建要更加靈活。
以下情況中，應該使用 Factory Method 模式：
類不能預料它必須創建的對象的類。
類希望其子類指定要創建的對象。
類將責任轉給某個幫助子類，而用戶希望定位那個被授權的幫助子類。
4、Prototype 模式
只要將對象類定義成能夠複製自身就可以實現。
優點如下：
可以在運行時 添加或刪除產品。
通過改變值 指定新對象。
通過改變結構 制定新對象。
減少子類的生成和使用。
可以用類 動態地配置 應用程序。
以下情況中，應該使用Prototype 模式：
運行時，指定需要實例化的類，例如動態載入。
避免構建與產品的類層次結構相似的 工廠類層次結構。
5、Singleton 模式
確保 一個類只有一個實例，並且提供全局訪問入口，確保使用這個 實例 所有的對象 使用相同的實例。
優點：
對單個實例的受控訪問。
命名空間的減少。
允許改進操作和表示。
允許改變數目的實例。
比類操作更靈活
7.2.2 結構性模式
機構性模式 控制 較大部分之間的 關係。
它將以不同的方式 影響應用程序。
允許在補充寫代碼或自定義代碼的情況下 創建系統。
具有增強的 重複使用性和應用性能。
1、Adapter 模式
可以充當兩個類之間的媒介，可以轉換一個類的接口，被另外一個類使用，使得具有不兼容接口的類能夠系統使用。
優點：
允許多個不兼容的對象 進行交互和通信。
提高已有功能的重複使用性。
以下情況，應該使用 Adapter 模式：
要使用已有類，而該類接口與所需的接口並不匹配。
要創建可重用的類，該類可以與 不相關 或 未知類 進行協作。
要在一個 不同於已知對象接口的接口環境中 使用對象。
必須要進行多個源之間的接口轉換的時候。
2、Bridge模式
將一個複雜的組件 分成兩個獨立的 但又相關的 繼承層次結構：功能性抽象和內部實現。
優點：
接口與實現相分離。
提高了可擴展性。
對客戶端隱藏了實現的細節。
以下情況中，應該使用 Bridge 模式：
避免在抽象及其實現之間 存在永久的綁定。
抽象及其實現 可以使用子類進行擴展。
抽象的實現被改動 不用重新編譯代碼。
3、Composite 模式
創建樹形層次結構來改變複雜性。
優點：
定義了由 主要對象 和 符合對象 組成的類層次結構。
添加新的組件類型更加簡單。
結構的靈活性和可管理性的接口。
以下情況中，應該使用 Composite 模式：
想要表示對象的整個 或者部分的層次結構。
想要客戶端能夠忽略符合對象和單個對象之間的差異。
結構可以具有任何級別的複雜性，而且是動態的。
4、Decorator 模式
不修改對象外觀和功能的情況下 添加或刪除對象功能。
優點：
比靜態繼承具有更大的靈活性。
避免了特徵裝載的類 處於層次結構的 過高級別。
簡化了編碼。
改進了對象的擴展性。
在以下情況中，應該使用 Decorator 模式：
在單個對象中 動態並且透明地 添加責任，不會影響其他對象。
以後可能要修改的對象中添加責任。
無法通過靜態子類化實現擴展時。
5、Facade 模式
爲子系統中的一組接口 提供了一個統一的接口。更容易使用子系統的高級接口。
優點：
在不減少系統所提供的選項的情況下，爲複雜系統提供了簡單接口。
屏蔽了子系統組件。
提高若耦合度。
將客戶端請求轉換後 發送給能夠處理這些請求的 子系統。
以下情況中，應使用 Facade 模式：
爲複雜的子系統提供簡單的接口。
客戶端和抽象的實現類中 存在許多依賴關係。
想要對子系統進行分層。
6、Flyweight 模式
通過共享對象 減少對象數目。
通過共享一個接口來避免使用多個具有相同信息的實例 所帶來的開銷。
優點：
減少了要處理的對象數目。
如果對象能夠持續，可以減少內存和存儲設備。
以下情況中，應該使用 Flyweight 模式：
應用程序使用大量的對象。
由於對象數目巨大，導致很高的存儲開銷。
不依賴於對象的身份。
7.2.3 行爲性模式
行爲性模式 影響 系統的 狀態、行爲流。
簡化、優化 並且 提高應用程序的 可維護性。
1、Chain of Responsibility 模式
在系統中建立一個鏈，在首先接收到它的級別處 被處理，或者定位到可以處理它的對象。
優點：
降低了耦合度。
增加面向對象制定責任的 靈活性。
類的集合可以作爲一個整體。
以下情況中，應該使用 Chain of Responsibility 模式：
多個對象可以處理一個請求，而其處理器卻是未知的。
在不指定確切的 請求接受對象的情況下，向幾個對象中的 一個 發送請求。
動態地指定能夠處理請求的對象集。
2、Command 模式
在對象中封裝了請求。
優點：
將調用操作的對象 與 知道如何完成該操作的對象 相分離。
更容易添加新指令，因爲不用修改已有類。
以下情況中，應該使用 Command 模式：
要通過執行的動作 來 參數化對象。
在不同的時間 指定、排序、執行 請求。
必須支持 Undo、日誌記錄 或 事務。
3、Interpreter 模式
解釋定義其語法表示的語言，提供了語句解釋器。
優點：
容易修改並擴展語法。
更容易實現語法。
以下情況中，應該使用 Interpreter 模式：
語言的語法比較簡單。
效率並不是最主要的問題。
4、Iterator 模式
爲集合中的有序訪問提供了一致的方法，而該集合是獨立於基礎集合。
優點：
支持集合的不同遍歷。
簡化了集合的接口。
以下情況中，應該使用 Iterator 模式：
不開放集合對象內部表示的前提下，訪問集合對象內容。
支持集合對象的多重遍歷。
爲遍歷集合中的不同結構 提供了統一的接口。
5、Mediator 模式
通過引入一個能夠管理對象間消息分佈的對象，簡化了系統中對象間的通信。提高了對象間的鬆耦合度，還可以獨立地 改變 其間的交互。
優點：
去除對象間的影響。
簡化了對象間協議。
集中化了控制。
由於不再需要直接互傳消息，單個組件變得更加簡單，而且容易處理。
由於不再需要 包含邏輯 來處理組件間的通信，組件變得更加通用。
以下情況中，應該使用 Mediator 模式：
對象集合需要以 一個定義規範但複雜的方式 進行通信。
6、Memento 模式
保持對象狀態的“快照”(snapshot)，對象可以在不向外界公開其內容的情況下 返回到它的最初狀態。
優點：
保持封裝的完整性。
簡化了返回到初始狀態所需的操作。
以下情況中，應該使用 Memento 模式：
必須保存對象狀態的快照，恢復狀態。
7、Observer 模式
定義了對象間 一到多 的依賴關係，當對象改變狀態時，將自動通知 並 更新它所有的依賴對象。
優點：
抽象了主題與 Observer 之間的耦合關係。
支持廣播方式通信。
以下情況中，應該使用 Observer 模式：
對一個對象的修改 涉及對其他對象的修改，而且不知道有多少對象 需要進行相應修改。
對象應該能夠 在不同假設對象標識的前提下 通知其它對象。
8、State 模式
對象在內部狀態變化時，變更其行爲，並且修改其類。
優點：
針對不同狀態來劃分行爲，使狀態轉換顯式進行。
9、Strategy 模式
定義了一組能夠用來表示 可能行爲集合的類。這些行爲 可以在應用程序中使用，來修改應用程序功能。
優點：
另一種子類化方法。
在類自身中定義了 每一個行爲，減少了條件語句。
更容易擴展模型。
以下情況中，應該使用 Strategy 模式：
許多相關類 只是在行爲方面有所區別。
需要算法的不同變體。
算法使用客戶端未知的數據。
10、Template Method 模式
不重寫方法的前提下 允許 子類重載部分方法 的方法。
將一些步驟由子類實現。
優點：代碼重用的基礎技術。
以下情況中，應該使用 Template Method 模式：
一次實現算法的不變部分，子類實現算法的可變行爲。
11、Visitor 模式
不改變操作元素的類 的前提下 定義一個新操作。
優點：
容易添加新操作。
集中相關 排除不相關 操作。
以下情況中，應該使用 Visitor 模式：
包含許多具有不同接口的對象類，並且想要對這些 依賴具體類的對象進行操作。
定義對象結構的類很少被修改，但想要在此結構上定義新的操作
2011年軟考系統架構設計師學習筆記第八章
8.1 XML 概述
可擴展標記語言(xml)是標準通用標記語言(SGML)的一個子集;可以用XML來開發一種標記語言，它的元素和屬性多是爲專門行業和產業而定義的。
支持統一字符編碼 UCS，使得 XML 成爲了國際標準，XML 和 HTML 都支持 樣式表(style sheet)。
8.1.1 標籤語法
XML 元素的結構與 HTML基本相同，使用尖括號來界定標籤，但二者相同點也就僅此而已。
與 HTML 不同，幾乎所有的 XML 標籤 都是大小寫敏感的，主要是滿足 XML 國際化的設計目標和簡化處理過程的需要。
非英語字母可能沒有對應的大小寫，合併會存在許多缺陷。
1、字符
XML 指定的字符 均在16位的 Unicode 2.1 字符集。
2、命名
XML 命名必須以字母、下劃線或冒號 開頭，後面跟着的是 有效命名字符(數字、減號、點)。
實際應用中不應該使用冒號，除非是用作命名空間修飾的分隔符。
字母並非侷限於 ASCII 碼，這一點是非常重要的。
8.1.2 文檔部分
格式正規的 XML：
1、一個可選的序言(prolog)
2、文檔的主體(body)
3、可選的“繁雜”的尾聲(epilog)，包括：註釋、處理指令(Processing Instruction，PI) 和/或 緊跟在元素後面的空白。
8.1.3 元素
元素是 XML 標籤的基本組成部分。
元素使用標籤(tag)進行分隔：尖括號圍住元素類型名。每一個元素 都必須 由一個起始標籤 和 一個結束標籤分隔開。
空元素
只是指定一個點，而不是提供一個包容器，空元素可以用縮略形式表示，起始和結束 標籤的混合體。
文檔元素，每個文檔 有且只有一個 根節點，稱爲 文檔實體(document entity) 或 文檔根(document root)，它們的根被稱爲文檔元素(document element)。
XML 對元素 必須正確地嵌套。
如果字符串中包含單引號，分隔符必須使用雙引號，反之亦然。
8.1.4 字符數據
字符數據就是任何不是標記的文本，小於號、大於號、&號 是標記分隔符，因此他們絕不能以字符串的形式出現在字符數據中(CDATA部分除外)，必須使用轉義字符 “&It;”等。
8.1.5 屬性
元素是 XML 中的名詞，屬性是它的形容詞。
attribute name = “attribute alue”
attribute name = “attribute alue”
起始標記或空標記中屬性只允許有一個實例存在。
非法的：
XML 數據中，只有 4個字符 可以作爲 空白使用，09 水平指標(HT)，0D 回車(CR)，0A 換行(CF)，20空格。
8.1.6 註釋
8.1.7 CDATA 部分
是一種用來包含文本的方法，對希望在自己的文檔中 包含 XML 標記的使用舉例 的作者來說是最有用的。
使用這些部分時 XML 幾乎所有的優勢都喪失殆盡。
，“…”可以是任何字符串，只要不包含字符串“]]>”。
8.1.8 格式正規的文檔
元素和元素之間唯一的直接關係就是 父子關係;
兄弟關係是通過數據結構推斷出來的，既不直接也不可靠，因爲元素可能被插入到 某個元素和它的一個或多個子元素之間。
數據對象 如果滿足下列條件 就是各市正規的文檔。
1、語法合乎 XML 規範。
2、元素構成一個層次樹，只有一個根節點。
3、沒有對外部實體的引用，除非提供了 DTD。
任何 XML 解析器 發現 不是個是正規的結構，就報告一個“致命”錯誤，致命錯誤不一定導致解析器終止操作，但它不再會以正常的方式嚮應用程序傳遞字符數據 和/或 XML結構。
8.2 XML 命名空間
8.2.1 命名空間
XML 命名空間 是 解決多個 義性和名字衝突問題的方案。
命名空間是一組具有結構的名稱的集合。
8.2.2 定義和聲明命名空間
命名空間 推薦標準爲我們提供了 xmlns屬性，屬性值就是 URI。
命名空間前綴經常被提及爲前綴，而名稱本身是基本名。
默認的命名空間(沒有聲明別名的，形式爲 xmlns=“…”)，在聲明作用域裏 所有沒有經命名空間前綴修飾的 名稱 被假定屬於默認的命名空間。
8.3 DTD
一個 XML 文檔是有效的，則它必須滿足：文檔 和 文檔類型 相關聯。
8.3.1 什麼是 DTD
DTD 文檔類型定義。
主要 用來查看 XML 文檔的格式，出現在 XML 文檔的序言中，DTD 聲明不是必須出現的。
DTD 中 主要定義以下幾個方面的內容：
1、元素聲明。
2、實體聲明。
3、屬性的種類。
8.3.2 爲什麼引入 DTD
提供一種驗證的手段，對 XML 來說是一大貢獻，確保 XML 文件確實地遵守了 指定的格式，而這個格式可能是 一個 標準，或者是數據交換雙方 所共同定製 的 協議。
實現了 文件格式 的統一化，提高了文件的重用性。
使用 DTD 進行驗證，增加了操作時間。
8.3.3 實體的聲明
實體(entity)是一些預先定義好的數據。
存儲部位，內部實體，外部實體;
組成內容，可分解實體，不可分解實體。
引用方式，一般型實體，參數型實體。
不同類型的實體聲明和使用方法略有不同。
8.3.4 屬性的聲明
良構 XML 文檔中，屬性只要滿足命名規則就可以了，但是在一個有效的 XML 文檔中，屬性要經過 DTD 的屬性聲明。
DTD 聲明中，屬性的聲明語法可以歸納爲如下形式：
元素名稱指的是 屬性所屬的元素名稱。
8.4 XML Schema
DTD 儘管進行了很大的簡化，但還是一門 風格 和XML完全不同的語言，而 schema 文檔是一種特殊的 XML 文檔，容易學習和使用。
DTD 的另一個缺點是 數據類型相當有限。DTD 中根本不提供 數值數據 類型。
一個 XML 文檔只能使用一個 DTD 文檔，schema 則採用了 名域空間的機制，使得一個 XML 文檔可以調用多種 schema 文檔。
8.5 可擴展樣式表語言
(eXtensible Stylesheet Language，XSL)是描述 XML 文檔樣式信息的一種語言，W3C 制訂。
XML 的一個優點就是 形式與內容相分離，XSL 就是它的兩種樣式表單之一，
另一種是 層疊樣式表(CSS)，是一種靜態的樣式描述格式，其本身不遵從 XML 的語法規範。
而 XSL 是一個 XML 文檔。
是 XML 的一種具體應用
它有兩大部分組成：
第一部分描述了 如何將 XML 文檔進行 轉換、轉換爲可瀏覽或可輸出的格式;
第二部分定義了 格式對象(Fomatted Object，FO)源樹轉換爲可以顯示的結果樹，稱爲樹轉換，按照FO分析結果樹，產生一個輸出結果，這個過程稱爲 格式化。
轉換樹 日趨成熟，已從 XSL 中分離出來，另取名爲 XSLT(XSL Transformations)，現在一般所聽說的 XSL 大多是指 XSLT。
一同退出的還有 配套標準 Xpath(XML Path Language，XML 路徑語言)
在 XML 中 聲明 XSL 樣式單：
XSL 在網絡中的應用大體分爲兩種模式：
1、服務器端轉換模式
XML 文件下載到 瀏覽器前先轉換成 HTML。
1.動態方式，接到轉換請求時再進行實時轉換。
2.批量方式。
2、客戶端轉換模式
XML 和 XSL 文件都傳送到客戶端，瀏覽器必須支持 XML+XSL 的工作方式。
8.6 其他相關規範
8.6.1 XPath
採用簡潔的、非 XML 語法，基於 XML 文檔的 邏輯結構，在該結構中進行導航。
XPath 表達式 通常出現在 URL 和 XML 屬性值裏。
XPath 將 XML 文檔描繪爲 樹或節點 的模型，節點的類型有 根節點、元素節點、屬性節點、文本節點、註釋節點、名稱空間節點、處理指令節點 7種。
XPath 規範定義了兩個主要部分：一部分是表達式語法，另一部分是一組名爲 XPath核心庫 的基本函數。
指向某個 XML 文檔中一個特定節點的路徑 由三部分信息構成：一個軸類型、一個節點測試 和 謂詞。
軸類型 有多種，指定所選節點和環境之間的關係。節點測試 查找什麼類型的節點，測試包括通配符“*”、text()、node()、comment()、processing-instruction()等。
謂詞以“[”開始，以“]”結束，謂詞通過使用內部函數來 過濾不需要的節點。
<軸>::<節點測試>[<謂詞表達式>]
8.6.2 XLink 和 XPointer
XLink 指定一個文檔如何連接到另一個文檔，XPointer 指定文檔內部的位置，都是基於 XPath 推薦標準。
2011年軟考系統架構設計師學習筆記第九章
面向構件的軟件設計
9.1 術語、概念
1、構件
構件的特徵如下：
獨立部署單元。
作爲第三方的組裝單元。
沒有(外部的)可見狀態。
獨立可部署，意味着 必須能 跟他所在的環境 及 其他構件 完全分離。
原子性，構件不但必須具備足夠好的內聚性，還必須將自己的依賴條件和所提供的服務說明清楚。
緩存具有這樣的特徵：當它被清空時，除了可能會降低性能以外，沒有其它後果。
構建本質上沒有狀態，同一操作系統進程中 裝載多個構件的拷貝 是毫無意義的，至多會存在一個特定構件的拷貝。
許多系統中，構建被實現爲 大粒度的單元，工資管理服務程序就是一個構件，工資數據只是實例(對象)，將不易變的“模型”和易變的“實例”分離的做法避免了大量的維護問題。
2、對象
對象的特徵如下：
一個實例單元，具有唯一的標誌。
可能具有狀態，此狀態外部可見。
封裝了自己的狀態和行爲。
顯式存在的實例化方案稱爲類，也有隱式的實例化方案，既通過克隆一個已存在的對象來實現，即原型對象。
新生的對象都必須被設置一個初始狀態，創建與初始化 對象 的代碼可以是一個靜態過程——類的一部分，稱爲構造函數。
如果這個對象是專門用來創建與初始化對象的，稱爲 工廠。
對象中 專門用來返回其他 新創建的對象的方法 稱爲 工廠方法。
3、構件與對象
構件通常包含了若干類 或 不可更改的 原型對象。還包括一系列對象。
但構件並非一定要包含類元素，它甚至可以不包含類，可以擁有傳統過程體，甚至全局變量。
構件創建的對象——更確切地說是對這些對象的 引用——可以與該構件分離開來，並對構件的客戶可見。構件的客戶通常是指其他構件。
一個構件可以包含多個類元素，但是一個類元素只能屬於一個構建。將一個類拆分進行部署通常沒有什麼意義。
4、模塊
模塊化方法成熟的標誌是其對分離編譯技術的支持，包括跨模塊的正確的類型檢查能力。
模塊沒有實例化的概念，在任何情況下，模塊都可以包含多個類。類之間的繼承關係並不受模塊界限的限制。
模塊本身就可以作爲一個最簡單的構件，這些庫是功能性的，而不是面向對象的。
資源可以參數化一個構件，重新配置該構件而無需更改構件代碼，例如，本地化設置可以通過資源配置實現。
某些情況下，模塊並不適合作爲構件，構件沒有外部可見的狀態，但是模塊卻可以顯式地用全局變量來使其狀態可見。
5、白盒抽象、黑盒抽象 與 重用 白盒抽象中，可以通過繼承對構件的實現細節進行修改，白盒方式中實現細節對外界是完全可見的。
絕大多數系統中，(Application Programming Interface，API)相當於黑盒重用這些接口的實現。
白盒重用不可以輕易地被另外的軟件替換，因爲 依賴於 細節。
軟件構件是一種組裝單元，它具有規範的接口規約和顯式的語境依賴，軟件構件可以被獨立地部署並由第三方任意地組裝。
6、接口
接口是一個已命名的一組操作集合。
一個構件可以有多個接口，每個接口提供一種服務。
儘量不要重複引入功能相近的接口。
推行標準化，可能會由於笨拙官僚的“委員會設計”問題而不能達到最優;市場競爭，的 非技術本質 也可能導致結果不是最優。
接口標準化 是對消息的 格式、模式、協議 的標準化，XML 提供了一種統一的數據格式
3、構件與對象
構件通常包含了若干類 或 不可更改的 原型對象。還包括一系列對象。
但構件並非一定要包含類元素，它甚至可以不包含類，可以擁有傳統過程體，甚至全局變量。
構件創建的對象——更確切地說是對這些對象的 引用——可以與該構件分離開來，並對構件的客戶可見。構件的客戶通常是指其他構件。
一個構件可以包含多個類元素，但是一個類元素只能屬於一個構建。將一個類拆分進行部署通常沒有什麼意義。
4、模塊
模塊化方法成熟的標誌是其對分離編譯技術的支持，包括跨模塊的正確的類型檢查能力。
模塊沒有實例化的概念，在任何情況下，模塊都可以包含多個類。類之間的繼承關係並不受模塊界限的限制。
模塊本身就可以作爲一個最簡單的構件，這些庫是功能性的，而不是面向對象的。
資源可以參數化一個構件，重新配置該構件而無需更改構件代碼，例如，本地化設置可以通過資源配置實現。
某些情況下，模塊並不適合作爲構件，構件沒有外部可見的狀態，但是模塊卻可以顯式地用全局變量來使其狀態可見。
5、白盒抽象、黑盒抽象 與 重用 白盒抽象中，可以通過繼承對構件的實現細節進行修改，白盒方式中實現細節對外界是完全可見的。
絕大多數系統中，(Application Programming Interface，API)相當於黑盒重用這些接口的實現。
白盒重用不可以輕易地被另外的軟件替換，因爲 依賴於 細節。
軟件構件是一種組裝單元，它具有規範的接口規約和顯式的語境依賴，軟件構件可以被獨立地部署並由第三方任意地組裝。
6、接口
接口是一個已命名的一組操作集合。
一個構件可以有多個接口，每個接口提供一種服務。
儘量不要重複引入功能相近的接口。
推行標準化，可能會由於笨拙官僚的“委員會設計”問題而不能達到最優;市場競爭，的 非技術本質 也可能導致結果不是最優。
接口標準化 是對消息的 格式、模式、協議 的標準化，XML 提供了一種統一的數據格式。
6、構件與生成式編程
必須要精確控制實際的構件邊界，包括提供接口和需求接口，必須能精確控制同其他構件間的靜態依賴。
9.3.2 語境相關組合構建框架
COM+ 增加了可租賃線程“套間”的概念，一次只允許一個線程入住，但是多個線程能順序地入住該“套間”。
相同事務域中的對象 共享一個單獨的邏輯線程和一個單獨共享事務資源集合，一旦線程從事務域中返回，事務要麼提交要麼終止。
COM+中，如果兩個構件共享一組兼容的語境屬性集，則它們可以被看作是處於同一域中。
9.3.3 構件開發
異步問題
事件分發機制負責接收這些事件對象，並把它們發送給對其感興趣的其他構件實例。
多線程
多線程主要關注於對程序執行進行更好的分配，獲取性能最大化的手段卻根本不依賴於多線程，而是儘量在第一時間內以最快的速度處理用戶的請求。
2011年軟考系統架構設計師學習筆記第十章
構建平臺與典型架構
10.1 OMG 方式
對象管理組 OMG，通過規範化對象 開放市場的 所有層次上的互操作性。
10.1.1 對象請求代理
CORBA 的主要目標就是使用不同語言、不同實現、不同平臺 能進行交互。
CORBA 三個基本部分：一套調用接口、對象請求代理 ORB、一套對象適配器。
10.1.2 公共對象服務規範
兩類服務：一類服務應用於企業計算系統。一類服務應用於細粒度的對象操作，但目前這些服務的實用價值較差。
1、支持企業分佈式計算的服務
1.命名服務、交易器服務
命名服務 允許 任意地給對象賦予一個名字，這個名字在其所屬的命名語境中是唯一的。
命名語境所形成的層次結構，使得所有的名字形成名字樹。
交易器服務 允許給對象 賦予一個複雜的描述，從而允許客戶基於該描述來定位所需的對象。
搜尋結果往往是 滿足查詢條件的 一組對象列表。
2.事件服務、通告服務
事件服務 允許定義那些 從 時間生產者 被 發送到時間消費者 的事件對象。
信息只能從生產者流向消費者，事件必須通過事件通道傳播，事件可以具有類型，而通道可以根據類型過濾事件。
事件通道支持“推”“拉”兩種方式 的事件通告模型。
通告服務爲事件服務增加了幾個重要的特徵——服務質量 QoS 規範和管理。
3.對象事務服務
對象事務服務OTS，是建立分佈式應用最重要的服務之一。
OTS 實現必須支持平坦事務，而嵌套事務是可選的。
在基於構件的系統中，嵌套事務似乎不可避免。
平坦事務在構件系統中的價值有限，實際上，現有的主流事務中間件也不支持嵌套事務。
6.併發控制服務
支持對象資源進行 加鎖、解鎖。
鎖必須依賴於 事務的語境 或 其他語境才能獲得。
7．讀鎖、寫鎖、升級鎖。
讀鎖允許多個客戶同時執行讀操作，寫鎖允許一個客戶寫操作，升級鎖是可以升級爲寫鎖的讀鎖 支持互斥讀。
每個受保護的資源都擁有一個鎖集合。鎖集合 不是事務型 就是非事務型，並可與其他鎖集合建立關聯。
8.生命週期服務
支持 創建、複製、移動、刪除 CORBA對象，及其相關的對象組。
包含關係支持嵌套複製。
11.外部化服務
支持對象網 和 對象流 之間的雙向映射。對象網外部化後 再內部化 意味着創建該對象網副本。
外部化服務並不保證引用的完整性，僅保留同時外部化的對象之間的引用。
對象必須實現 Streamable 接口才能被外部化。
12.屬性服務
允許將任意的屬性與對象關聯起來，被關聯的對象必須實現 ProperySet接口。
13.對象查詢服務
依靠屬性定位對象。
15.時間服務
擁有衆多異步時鐘的分佈式系統 固有的誤差問題。
10.1.3 CORBA 構件模型
CORBA 對象適配器主要的作用 就是在一個 ORB 和 真正接收調用並且返回結果的 對象之間 進行交互。
10.2 SUN 公司的方式
Java 構件技術的概述
Java中，編譯器會檢查 Applet 代碼的安全性，通過了編譯器檢查的 Applet 代碼不會帶來安全隱患。
由於編譯得到的字節碼仍然可能被人修改，代碼在裝載時刻會被再次檢查(稱爲“校驗”)。
運行環境(Runtime Environment，RE)、軟件開發工具包(Software Development Kit，SDK)、參考實現。
運行環境是 Java 虛擬機 和 必須具有的 J2SE API 的實現。
10.3 Microsoft 的方式
微軟選擇的是最簡單的路線，他沒有提出一整套標準;相反，他不斷對已有的應用和平臺基礎進行再工程，這就可以獲益於以前的成功技術。
語言無關性，作爲 CLR 的一條主要原則。
10.3.1 第一個基礎關聯模型——COM
COM 所定義的一個基礎實體是接口。在二進制層面上，一個接口被表示爲指向一個接口節點的指針。
接口節點 唯一被指定的部分是 置於其內部第一個域的 另一個指針，這個指針指向一個過程變量表(或者說，函數指針表)。
每個 COM 對象都有 IUnknown接口，通常置於 COM對象圖的頂端。
他的“真實”名字是他的 IID，即 00000000-0000-0000-C000-000000000046 爲了方便，所有接口也有一個 可讀名。
根據習慣，可讀接口名以字母I開頭。與 IID 不同，可讀接口名 並不保證是唯一的。因此，編程中的接口引用均使用 IID。
IUnknown 接口的首要用途是在 最抽象的情況下 標誌 COM對象，此時 COM對象 沒有任何特殊功能。
IUnknown 接口 只提供對任何 COM接口都必須的三個強制性方法。QueryInterface、AddRef、Release，後兩個強制性方法被用來控制對象的生命週期。
類型 HRESULT 被大多數 COM接口的方法用來表示調用成功或失敗。 QueryInterface表明查詢的接口是否被支持。
每個 COM對象都會進行引用計數，引用計數變量被共享使用的情況下，COM對象 不能釋放接口節點。
一般這樣做沒有問題，也是通常的做法。
某些情況下佔用很多資源，可以使用獨立的引用計數變量，以便節點可以儘早釋放。這種根據需要創建和刪除接口節點的技術有時被稱作“快速裝卸接口(Tear-Off Interface)”
10.3.2 COM對象重用
COM不支持任何形式的實現繼承。
COM支持兩種形式的對象組裝：包含(Containment)和 聚集(Aggregation)。
包含 是一個對象 擁有 指向另一個對象的唯一引用。
外部對象 只是把請求轉發給內部對象，所謂轉發 就是調用內部對象的方法。
包含能重用內含於其他構件的實現，是完全透明的。
如果包含層次較深，或者被轉發的方法本身相對簡單，包含會存在性能上的問題。因此 COM定義第二類重用形式，聚集。
聚集直接把內部對象接口引用傳給外部對象的客戶，而不是再轉發請求。
保持透明性是很重要的，因爲外部對象的客戶無法辨別哪個特定接口是從內部對象聚集而來的。
10.3.3 接口和多態
COM接口可通過(單)接口繼承 從其他 COM接口中派生。
COM 的接口繼承與其支持的多態無關。
接口和版本化，一旦公佈，COM 接口和他的規範不允許以任何形式改變。
既解決了語法問題，也解決了弱基類問題。
IID 可用於標誌接口中的版本，因爲接口總是通過IID被請求。
CORBA 討論中所提及的傳遞性版本衝突問題 在COM中不會發生。
構件可以選擇實現接口的多個版本，處理方式就像處理 別的不同接口一樣。
基於COM的系統能併發支持舊接口和新接口。
10.3.4 COM對象的創建和COM庫
創建 COM類 的實例對象時，COM需要把給定的 CLSID 映射爲包含所請求的類的實際構件。COM 支持系統註冊器，它類似 CORBA存儲器。
進程內(inprocess)服務器、本地服務器、遠程服務器。
10.3.5 從 COM到分佈式 COM(DCOM)
代理(Proxy)對象 和 服務器 樁(Stub)對象。
爲支持 跨進程 或 跨機器 的透明通信，COM在客戶端創建代理對象，在服務器端創建樁對象。
跨進程傳遞的 接口引用需要被映射爲 對象引用。
DCOM 將數據整理成平臺無關的網絡數據表達(NDR)形式。
10.3.6 複合文檔和OLE 對象
OLE 可被 概括爲 一組預定義的 COM 接口。
文檔容器 和 文檔服務器。
文檔服務器 是提供某種內容模型 和顯示、操作內容的能力。文檔容器沒有自己的內容，但可以接受任意文檔服務器提供的內容成分。
許多文檔容器也是文檔服務器，即是說，他們支持外來的成分，同時也有自己的內容。
10.3.7 .NET 框架
沒有原始類型。
2011年軟考系統架構設計師學習筆記第十一章
信息安全技術
11.1 信息安全關鍵技術
11.1.1 加密和解密
有意的計算機犯罪和無意的數據破壞
被動攻擊：非法地從傳輸信道上截取信息，或從存儲載體上偷竊、複製信息。
主動攻擊：對傳輸或存儲的數據進行惡意的刪除、篡改 等。
密碼技術是防止數據攻擊的一種有效而經濟的方法。
信源、信宿、明文、密文。
傳輸消息的通道稱爲信道，參數稱爲密鑰，解密算法是加密算法的逆運算。
加密密鑰與解密密鑰相同，或者可以簡單相互推導的密碼體質稱爲對稱密碼體質。
不能(在有效時間內)相互推導的，稱爲非對稱密碼體質。
1、對稱密鑰密碼體質及典型算法
對稱算法(Symmetric Algorithm)，有時又稱爲 傳統密碼算法，也稱單密鑰算法。
安全通信之前，商定一個密鑰，安全性依賴於密鑰，密鑰的保密性對通信至關重要。
優點：算法實現的 效率高、速度快。
缺點：密鑰的管理過於複雜。1. DES 算法簡介
DES(Data Encryption Standard，數據加密標準)是IBM公司研製，美國國家標準局 1977年公佈，作爲非機要部門使用的數據加密標準。
DES 是一個分組加密算法，以64位爲分組對數據加密。密鑰長度56位(因爲每個第8位都用作奇偶校驗)。
2. IDEA 算法簡介
國際數據加密算法(International Data Encryption Algorithm，IDEA)前身是推薦加密標準(Proposed Encryption Standard，PES)。
分組長度 64b，密鑰長度128b。
運算非常簡單，只是 異或，速度極快，窮舉破解不現實。
2、不對稱密碼加密算法
不對稱密碼體制又稱 雙密鑰和公鑰密碼體質，1976年 由 Diffie 和 Hellman 提出的。
私鑰祕密保存。
不需要事先通過安全祕密管道交換密鑰。
RSA 的安全性依賴於大素數分解。公鑰和私鑰 都是兩個大素數(大於100個十進制位的函數)。
據猜測，從一個密鑰和密文中，推斷出明文的難度等同於分解兩個大素數的積。
具體操作時 考慮到 安全性 和 M信息量 較大等因素，一般是先做 HASH 運算。
速度慢一直是 RSA 的缺陷，因此一般來說，RSA只用於少量數據加密。
11.1.2 散列函數與數字簽名
1、MD5 散列算法
散列函數是一種公開的數學函數。散列函數運算的輸入信息叫做 報文，運算後所得的結果叫做散列碼或消息摘要。
特點：
1. 給定 M，要找到另一消息 M，使 H(M)= H(M)很難。
2. 散列函數都是單向的，反推M很難。
3. 對於任何一個報文，無法預知它的散列碼。
4. 散列碼具有固定的長度，不管原始報文長度如何。
常見的散列函數有：MD5、SHA、HMAC 等。
MD5(Message Digest 5)已成爲國際標準，產生128位(16字節)長度的散列值(或稱 消息摘要)。
通過以下4個步驟：
1. 附加填充位，填充後數據長度 MOD 512 後 餘 448。如果數據長度正好 MOD 512 餘 448，增加 512 個填充位，填充個數也就是1～512。
填充位第一個爲 1，其餘全部是 0。
2. 補足長度。
3. 初始化MD緩存器。
4個32位寄存器，A、B、C、D，初始化爲：
A: 01 23 45 67
B: 89 AB CD EF
C: FE DC BA 98
D: 76 54 32 10
4. 處理數據段。
2、數字簽名與數字水印
1. 數字簽名可以解決 否認、僞造、篡改、冒充 等問題。
凡是需要對用戶身份進行判斷的情況 都可以使用數字簽名。
三個過程：系統的初始化過程、簽名產生過程、簽名驗證過程。
簽名者必須注意保護好私有密鑰，因爲它是公開密鑰體系安全的重要基礎。
如果密鑰丟失，應該立即報告鑑定中心取消認證，鑑定中心必須能夠迅速確定用戶的身份及其密鑰的關係。
RSA、ElGamal、Fiat-Shamir、美國的數字簽名標準/算法(DSS/DSA)、橢圓曲線 等多種
2. 數字水印(Digital Watermarking)是實現版權保護的有效辦法，也是信息隱藏技術研究領域的重要分支。
通過在原始數據中嵌入祕密信息——水印(Watermark)來證實該數據段所有權。
水印可以是一段 文字、標識、序列號 等，通常是不可見或不可察的，與原始數據緊密結合並隱藏其中。
數字水印技術必須具有較強的 魯棒性、安全性、透明性。
數字水印主要應用領域：
版權保護，作品被盜版或出現版權糾紛時，所有者即可從盜版作品或水印版作品中 獲取水印信號作爲依據。
加指紋，將不同用戶端ID或序列號 作爲不同的水印(指紋)嵌入作品的合法備份中，一旦發現未授權的備份，就可以確定它的來源。
標題與註釋。
篡改提示，可將原始圖像分成多個獨立塊，再將每個塊加入不同的水印，來確定作品的完整性，這類水印必須是脆弱的，並且檢測水印信號時，不需要原始數據。
使用控制，防複製。
空域算法、變換域算法、壓縮域算法、NEC算法、生理模型算法 等。
11.1.3 密鑰分配中心與公鑰基礎設施
現代密碼系統中，算法本身的保密已經不重要了，只要密鑰能夠保密，即使加密算法公開，甚至加密設備丟失，也不會對加密系統的堅固性和正常使用產生多大影響。
如何高效地分配密鑰、安全地管理密鑰 對保證數據安全來說至關重要。
1、密鑰分配中心
密鑰自動分配 是 密鑰分配中心(Key Distribution Center，KDC)技術。
2、數字證書和公開密鑰基礎設施
數字證書的內容一般包括：唯一標識證書所有者的名稱、唯一標識證書籤發者的名稱、證書所有者的公開密鑰、證書籤發者的數字簽名、證書的有效期、證書的序列號等。
PKI(Public Key Infrastructure，公鑰基礎設施)的結構模型有三類實體：管理實體、端實體、證書庫。
管理實體是PKI的核心，是服務的提供者，端實體是PKI的用戶。
CA 和 RA 是兩種管理實體，CA 能夠 發佈和撤銷 證書，維護證書的生命週期。RA負責處理用戶請求。
證書庫的存取對象爲證書和CRL，其完整性由數字簽名來保證，因此不需要額外的安全機制。
11.1.4 訪問控制
自動、有效地防止對系統資源進行非法訪問或者不當使用。
它是建立在身份認證的基礎之上的。
1、身份認證技術
識別用戶的身份有兩種不同形式：身份認證、身份鑑定。
認證的方法 歸結爲 3大類：知道什麼、擁有什麼、是什麼。
是什麼，是一種基於生物識別技術的認證。
1. 用戶名和口令認證，三種簡單的認證方式：明文傳送、單向散列、單向散列函數和隨機函數。
2. 使用令牌認證，密鑰存儲於令牌中。
令牌是一個可以加密存儲並運行相應加密算法的設備，完成對用戶必須擁有某物的驗證。
令牌的實現分爲：質詢響應令牌、時間戳令牌，常用的是時間戳令牌。
系統的安全強度大大增加：私鑰採用令牌存儲的方式解決了 私鑰自身的安全問題，安全強度大大增加。
而且令牌有 PIN碼 保護，對令牌的非法訪問超過一定次數後，令牌會死鎖。
時間戳令牌利用時間代替隨機數，需要重點考慮時間同步問題，目前在安全性較高的認證系統中，多是採用這種方案。
3. 生物識別與三因素認證
基於生物識別技術的認證，主要根據認證者的 圖像、指紋、氣味、聲音等作爲認證數據。
2、訪問控制技術
根據 控制手段 和 具體目的 的不同，通常將 訪問控制技術 劃分爲幾個方面：入網訪問控制、網絡權限控制、目錄級安全控制、屬性安全控制、網絡服務器安全控制等。
入網訪問控制，控制准許用戶 入網的時間、准許的工作站等。
由於用戶口令驗證方式容易被攻破，很多網絡都開始採用 基於數字證書的驗證方式。
用戶 和 用戶組 被 賦予一定的權限。
訪問機制 兩種實現方式：“受託者指派”和“繼承權限屏蔽”
“受託者指派”控制用戶 和 用戶組 如何使用網絡服務器。
“繼承權限屏蔽”相當於一個過濾器，可以限制子目錄從父目錄那裏繼承哪些權限。
特殊用戶、一般用戶、審計用戶。
對目錄和文件的訪問權限 一般有 8種：系統管理員權限、讀、寫、創建、刪除、修改、查找、訪問控制。
屬性 能夠控制以下幾個方面的權限：寫 數據、複製 文件、刪除 目錄或文件、察看 目錄和文件、執行 文件、隱含 文件、共享、系統屬性等。
11.1.5 安全協議
1、IPSec 協議簡述
因特網工程任務組(IETF)，IPSec 在 IP層上 對數據包 進行高強度 的 安全處理 提供 數據源驗證、無連接數據完整性、數據機密性、抗重播、有限通信流機密性等安全服務。
1. IPSec 協議工作原理
通過使用兩種信息安全協議 來爲數據報提供高質量的安全性：認證頭(AH)協議 和 封裝安全載荷(ESP)協議，以及像 Internet 密鑰交換(Internet Key Exchange，IKE)協議這樣的密鑰管理協過程和協議。
IPSec 允許系統或網絡用戶 控制安全服務提供的粒度。
由通信雙方建立的安全關聯(Security Association，SA)來提供。
3. IPSec 協議 安全性分析
可以應用於所有跨越網絡邊界的通信。
如果所有來自外部的通信必須使用IP，且防火牆是 Internet 與 組織的唯一入口，則 IPSec 是不能被繞過的。
IPSec 位於傳輸層(TCP、UDP)之下，因此對應用程序是透明的，實現時，沒有必要在用戶或服務器上更改軟件。
IPSec 對最終用戶是透明的，沒有必要 培訓用戶掌握安全機制。
2、SSL 協議
SSL 協議(Secure Socket Layer)對計算機之間的 整個會話進行加密，位於 TCP 和 應用層 之間，可爲應用層 提供 安全業務，主要是 Web應用。
基本目標是 在通信雙方之間 建立安全的連接。
SSL 協議工作原理
兩個重要的概念：SSL 連接和SSL 會話。
連接 是 提供恰當類型服務的傳輸，對於 SSL ，連接是點到點的關係。
SSL 的會話是 客戶和服務器之間的關聯，會話通過握手協議來創建。
會話定義了 加密安全 參數的一個集合。
會話可以用來避免爲每個連接進行 昂貴的新安全參數的協商。
3、PGP 協議
1. PGP 協議的定義
PGP(Pretty Good Privacy)針對 電子郵件 在 Internet上 通信的 安全問題而設計的一種混合加密系統。
公鑰密碼和分組密碼 是在同一個系統中，PGP 的用戶擁有一張公鑰表。
PGP 應用程序具有很多優點：速度快、效率高、可移植性好。
2. PGP 協議 的 加密過程
用 IDEA 算法對明文加密，接着用接收者的 RSA公鑰 對這個IDEA密鑰進行加密。
PGP 沒有用 RSA 算法直接對明文加密，而是對 IDEA 密鑰 進行加密。
由於 IDEA 算法 速度很快，所以不會因爲郵件的數量大而耽誤時間，而IDEA的密鑰位數較少，所以使用RSA算法在速度上也不會有很大影響。
11.1.6 數據備份
1、備份的類型
備份數據常常被人們遺忘，造成的後果往往是毀滅性的。
保證數據完整性以及準確性，一直都面臨着極大的考驗。
1. 完全備份，所需時間最長，但恢復時間最短，操作最方便可靠。
2. 差異備份，備份上一次的 完全備份後發生變化的所有文件。備份時間較長，佔用空間較多，恢復時間較短。
3. 增量備份，上一次備份後，所有發生變化的文件。備份時間較短，佔用空間較少，恢復時間較長。
4. 按需備份。有很好的選擇性。
2、異地備份
數據異地備份 是 容災系統 的核心技術，確保一旦本地系統出現故障，遠程的容災中心能夠迅速進行完整的業務託管。
進行異地備份時，要注意以下幾個問題：
避免讓備份帶上病毒。
保證磁片質量，定期對其進行質量檢查。
對於光盤，最大的缺點是 兼容性不好，最好是用哪臺刻錄機刻錄 就用哪臺刻錄機讀取(有時光頭歪了也刻歪了，好光驅讀不出來)。
對於移動硬盤，要做磁盤檢查，保證其性能良好。
3、自動備份軟件
具備 多個備份的文件 無論怎樣重命名 都只備份一個。
對員工正常工作無任何干擾，就好像這個軟件不存在一樣。
11.1.7 計算機病毒免疫
1、計算機病毒定義
通過修改其他程序 使之含有該程序本身或它的一個變體，具有感染力，藉助使用者的權限感染他們的程序。
每個被感染的程序也像病毒一樣可以感染其他程序。
2、計算機病毒免疫的原理
傳染模塊一般包括傳染條件判斷和實施傳染兩部分。
一般情況下，傳染完一個對象後，都要給被傳染對象加上傳染標識，若不存在這種標識，則病毒就對該對象實施傳染。
不判斷是否存標識，反覆傳染多次，雪球越滾越大。
當某些尚不能被病毒檢測軟件檢查出來的病毒感染了文件，該文件又被免疫外殼包在裏面時，查毒軟件查不到它。
11.2 信息安全管理和評估
11.2.1 安全管理技術
安全管理技術就是 監督、組織、控制網絡通信服務以及信息處理所必須的 各種技術手段和措施的總稱。
目標是確保計算機網絡的持續正常運行，出現異常時能及時響應和排除故障。
各種網絡安全產品的作用 提現在網絡中的不同方面，統一的網絡安全管理平臺 必然要求對網絡中部署的安全設備進行協同管理。
安全設備的管理、安全策略管理、安全風險控制、安全審計，幾個方面。
安全審計：安全設備、操作系統、應用系統的日誌信息收集彙總，進一步分析，得出更深層次的分析結果。
2011年軟考系統架構設計師學習筆記第十二章
系統安全架構設計
12.1 信息系統安全架構的簡單描述
信息安全的特徵是爲了保證信息的機密性、完整性、可用性、可控性、不可抵賴性。
以風險策略爲基礎。
12.1.1 信息安全的現狀及其威脅
計算機和網絡的普及，會產生兩個方面的效應：
其一，各行各業的業務運轉幾乎完全依賴於計算機和網絡。
其二，大多數人對計算機的瞭解更加全面。
常見的安全威脅有如下幾種：
1、信息泄露。
2、破壞信息的完整性。
3、拒絕服務。
4、非法使用。
5、竊聽。
6、業務流分析，發現有價值的信息和規律。
7、假冒。
8、旁路控制。
9、授權侵犯。
10、特洛伊木馬。
11、陷阱門，設置了“機關”，提供特定的輸入數據時，允許違反安全策略。
12、抵賴。
13、重放，處於非法的目的而被重新發送。
14、計算機病毒。
15、人員不慎。
16、媒體廢棄。
17、物理侵入。
18、竊取。
19、業務欺騙。
可以從安全技術的角度提取出5個方面的內容：認證鑑別、訪問控制、內容安全、冗餘恢復、審計響應。
12.2 系統安全體系架構規劃框架及其方法
安全技術體系架構過程的目標 是 建立可持續改進的安全技術體系架構的能力。
OSI參考模型：物理、數據鏈路、網絡、傳輸、會話、表示、應用。
根據網絡中風險威脅的存在實體劃分出5個層次的實體對象：應用、存儲、主機、網絡、物理。
信息系統安全規劃是一個非常細緻和非常重要的工作，需要對企業信息化發展的歷史情況進行深入和全面的調研。
信息系統安全體系主要是由技術體系、組織結構體系、管理體系三部分共同構成。
技術體系由物理安全技術和系統安全技術兩大類組成。
組織體系由機構、崗位、人事三個模塊構成。
管理體系由法律管理、制度管理、培訓管理三部分組成。
人員安全包括 安全管理的組織結構、人員安全教育與意識機制、人員招聘及離職管理、第三方人員安全管理等。
12.3 網絡安全體系架構設計
12.3.1 OSI 的安全體系架構概述
在 OSI 7層協議中 除會話層外，每一層 均能提供相應的安全服務。
最適合配置安全服務的是 物理層、網絡層、運輸層、應用層。
ISO 開放系統互聯 安全體系的5類安全服務：鑑別、訪問控制、數據機密性、數據完整性、抗抵賴性。
分層多點安全技術體系架構，也稱爲深度防禦安全技術體系架構，通過以下方式將防禦能力分佈至整個信息系統中。
1、多點技術防禦，從內部或外部多點攻擊一個目標，通過對以下多個防禦核心區域的防禦達到抵禦所有方式的攻擊的目的。
1. 網絡和基礎設施，確保可用性，確保機密性和完整性。
2. 邊界，抵禦主動的網絡攻擊。
3. 計算環境，抵禦內部、近距離的分佈攻擊。
2、分層技術防禦，有效的措施是使用多個防禦機制。
支撐性基礎設施爲網絡、邊界、計算機環境中信息保障機制運行基礎。包括公鑰設施、檢測和響應基礎設施。
1. 公鑰基礎設施提供一種 通用的聯合處理方式，以便安全地創建、分發、管理 公鑰證書和傳統的對稱密鑰。
公鑰基礎設施 必須支持受控的互操作性，並與各用戶團體所建立的安全策略保持一致。
2. 迅速檢測並響應入侵行爲，便於結合其他相關事件觀察某個事件的“彙總”性能。
識別潛在行爲模式或者新的發展趨勢
12.3.2 鑑別框架
鑑別(Authentication)防止其他實體佔用和獨立操作被鑑別實體的身份。
鑑別有兩種重要的關係背景：
一是實體由申請者來代表，申請者與驗證者之間存在着特定的通信關係(如實體鑑別)。
二是實體爲驗證者提供數據項來源。
鑑別方式主要基於以下 5種：
1、已知的，如 一個祕密的口令。
2、擁有的，IC卡、令牌等。
3、不改變的特性，如生物特徵。
4、相信可靠的第三方建立的鑑別(遞推)。
5、環境(如主機地址等)。
鑑別信息(Artificial Intelligence，AI)是指申請者要求鑑別到 鑑別過程結束 所生成、使用、交換的信息。
交換AI、申請AI、驗證AI。
鑑別服務分爲以下階段：安裝階段、修改鑑別信息階段、分發階段、獲取階段、傳送階段、驗證階段、停活階段、重新激活階段、取消安裝階段。
12.3.3 訪問控制框架
訪問控制(Access Control)決定 允許使用哪些資源、在什麼地方適合阻止未授權訪問的過程。
ACI(訪問控制信息)用於訪問控制目的的 任何信息。
ADI(訪問控制判決信息)做出判決時 可供 ADF使用的部分(或全部)ACI。
ADF(訪問控制判決功能)做出訪問控制判決。
AEF(訪問控制實施功能)。
涉及訪問控制的有 發起者、AEF、ADF、目標
12.3.4 機密框架
機密性(Confidentiality)服務確保信息僅僅是對被授權者可用。
數據只對那些擁有某種關鍵信息的人才是可訪問的。
被保護的環境被交疊保護的環境。
從一個環境移到另一個環境的數據的連續保護必然涉及到交疊保護環境。
機密性機制
數據的機密性可以依賴於所駐留和傳輸的媒體。
數據在傳輸中的機密性 能通過禁止訪問的機制、隱藏數據語義的機制、分散數據的機制。
物理方法保證媒體的數據只能通過特殊的有限設備才能檢測到。
通過路由選擇控制。
通過機密提供機密性。
12.3.5 完整性框架
完整性(Integrity)框架目的是通過組織威脅或探測威脅，保護可能遭到不同方式危害的數據完整性和數據相關屬性完整性。
所謂完整性，就是數據不以未經授權方式 進行改變或損毀的特徵。
幾種分類方式：未授權的數據修改、未授權的數據創建、未授權的數據刪除、未授權的數據插入、未授權的數據重放。
依據是否包括恢復機制分爲具有恢復機制的和不具有恢復機制的。
完整性機制的類型
1、組織對媒體訪問的控制，包括物理的、不受干擾的信息;路由控制;訪問控制。
2、用以探測 對數據或數據項序列的非授權修改的機制。
按照保護強度，完整性機制可以分爲 不作保護;對修改和創建的探測;對修改、創建、刪除、重複的探測;對修改和創建的探測並帶恢復功能;對修改、創建、刪除、重複的探測並帶恢復功能。
12.3.6 抗抵賴框架
抗抵賴(Non-repudiation)服務 包括證據的 生成、驗證、記錄，以及 在解決糾紛時隨即進行的證據恢復和再次驗證。
目的是 提供有關特定事件或行爲的證據。
當涉及消息內容的抗抵賴服務時，爲提供原發證明，必須確認數據原發者身份和數據完整性。
爲提供遞交證明，必須確認接收者身份和數據完整性。
抗抵賴服務提供 在試圖抵賴的事件中 使用的設備：證據生成、證據記錄、驗證生成的證據、證據的恢復和重驗。
抗抵賴由 4個獨立的階段組成：證據生成;證據傳輸、存儲、恢復;證據驗證;解決糾紛。
1、證據生成
捲入事件或行爲中的實體，稱爲證據實體。證據實體可由證據實體、或可能與可信第三方的服務一起生成、或者單獨由可信第三方生成。
3、證據驗證
證據在 使用者的請求下被證據驗證者 驗證。讓證據使用者確信被提供的證據確實是充分的。
12.4 數據庫系統的安全設計
電子政務中所涉及的數據庫 密級更高、實時性更強。
實現 數據庫系統安全的 完整性、保密性、可用性。
安全策略一般爲 用戶管理、存取控制、數據加密、審計跟蹤、攻擊檢測。
12.4.1 數據庫安全設計的評估標準
1985 年，美國國防部頒佈“可信計算機系統評估標準(Trusted Computer System Evaluation Criteria，TCSEC)”橘皮書(簡稱 DoD85)。
1991年，美國國家計算機安全中心(The National Computer Seaurity Center，NCSC)頒佈了“可信計算機評估標準關於可信數據庫管理系統的解釋(Trusted Database Interpretation，TDI)”。
TDI 是 TCSEC 在數據庫管理系統方面的擴充和解釋，從 安全策略、責任、保護、文檔 4個方面進一步描述了每級的安全標準。
按照 TCSEC標準，D類產品 基本沒有安全保護措施，C類產品 只提供了 安全保護措施，B類以上產品 是實行強制存取控制的產品，是真正意義上的安全產品。
12.4.2 數據庫的完整性設計
數據庫的完整性是指數據庫中數據的正確性和相容性。
由各種各樣的完整性約束來保證，因此可以說數據庫完整性設計就是數據庫完整性約束的設計。
通過DBMS或應用程序來實現。
1、數據庫完整性設計原則
1. 根據數據庫完整性約束的類型 確定其實現的系統層次和方式，並提前考慮對系統性能的影響。
一般情況下，靜態約束應 儘量包含在數據庫模式中，動態約束由應用程序實現。
2. 實體完整性約束、參照完整性約束 是關係數據庫最重要的完整性約束，儘量應用。
3. 要慎用 觸發器，一方面性能開銷較大;另一方面，多級觸發不好控制，容易發生錯誤，最好使用 Before 型語句級觸發器。
4. 在需求分析階段就必須制定完整性約束的命名規範。
5. 要根據業務規則 對數據庫完整性進行細緻的測試。
6. 要專職的數據庫設計小組。
7. 應採用合適的 CASE工具 來降低數據庫設計各階段的工作量。
2、數據庫完整性的作用
1. 能夠防止合法用戶使用數據庫時 向數據庫中添加不合語義的數據。
2. 實現業務規則，易於定義，易於理解，而且可以降低應用程序的複雜性，提高應用程序的運行效率。集中管理。
3. 能夠同時兼顧 數據庫的完整性和系統效能。
4. 有助於儘早發現應用軟件的錯誤。
5. 數據庫完整性約束 6類：列級靜態約束、元組級靜態約束、關係級靜態約束、列級動態約束、元組級動態約束、關係級動態約束。
動態約束通常由應用軟件來實現。
3、數據庫完整性設計示例
首先 需要在需求分析階段確定要通過數據庫完整性約束實現的業務規則。
然後 依據整個系統的體系結構和性能要求，遵照數據庫設計方法和應用軟件設計方法，合理選擇每個業務規則的實現方式。
最後 認真測試，排除隱含的約束衝突和性能問題。
基於 DBMS的數據庫完整性設計大體分爲以下幾個階段：
1. 需求分析階段。
2. 概念結構設計階段。
3. 邏輯結構設計階段，就是將概念結構轉換爲某個DBMS所支持的數據模型，並對其進行優化，包括對關係型的規範化。
每種業務規則都可能有好幾種實現方式，應該選擇對數據庫性能影響小的一種，有時需通過實際測試來決定。
12.5 案例：電子商務系統的安全性設計
1、原理介紹
1. 驗證(Authentication)：是否可以獲得授權。
2. 授權(Authorization)：可以使用哪些服務。
3. 審計(Accounting)：記錄用戶使用網絡資源的情況，用戶IP地址、MAC地址掩碼 等。
2、軟件架構設計
RADIUS 軟件架構分爲三個層面：協議邏輯層、業務邏輯層、數據邏輯層。
協議邏輯層 主要實現 RFC框架中的內容，處理網絡通信協議的 建立、通信、停止方面的工作。
相當於一個轉發引擎，起到分發處理的內容分發到不同的協議處理過程中。
業務邏輯進程分爲：認證、計費、授權，三種類型。
數據庫代理池 統一連接數據庫，以減少對數據庫系統的壓力。同時減小了系統對數據庫的依賴性，增強了系統適應數據庫系統的能力。
RADIUS 軟件分層架構的實現：
一是 對軟件風險進行了深入的分析，
二是 可以構建一個或多個重用的構件單元，也可以繼承原來的成果。
RADIUS 的功能：
一是 實際處理大量用戶併發的能力，
二是 軟件架構的可擴展性。
負載均衡是提高 RADIUS軟件性能的有效方法，主要完成以下任務：
1. 解決網絡擁塞問題，就近提供服務。
2. 爲用戶提供更好的訪問質量。
3. 提高服務器響應速度。
4. 提高服務器及其他資源的利用效率。
5. 避免了網絡關鍵部位出現單點失效。
2011年軟考系統架構設計師學習筆記第十三章
系統的可靠性
13.1 軟件可靠性
目前，硬件可靠性測試技術和評估手段日趨成熟，已經得到了業界的認可。
軟件可靠性模型的研究多集中在開發階段、測試階段、評估階段的可靠性模型。
13.1.1 軟件可靠性的定義
可靠性(Reliability)是指產品在規定的條件下和規定的時間內完成規定功能的能力。
按照產品可靠性的形成，分爲固有可靠性、使用可靠性。
固有可靠性是通過設計、製造賦予產品的可靠性。
使用可靠性既受設計、製造的影響，又受使用條件的影響。
軟件與硬件從可靠性角度來看，主要有4個不同點：
1、複雜性，軟件內部的邏輯高度複雜，硬件則相對簡單。
2、物理退化，一個正確的軟件任何時刻均可靠，一個正確的硬件、元器件、系統則可能在某個時刻失效。
3、唯一性，軟件是唯一的，軟件複製不改變軟件本身，硬件不可能完全相同，概率方法在硬件可靠性領域取得巨大成功。
4、版本更新快，軟件版本更新較快，也給軟件可靠性評估帶來較大的難度。
1983年，美國IEEE 對“軟件可靠性”做出了更明確的定義。
1989年，我國國家標準 GB/T-11457也採用了這個定義。
定義：在規定的條件下，在規定的時間內，軟件不引起系統失效的概率。
依然沿用了“產品可靠性”的定義。
1、規定的時間
由於軟件運行的環境與程序路徑選取的隨機性，軟件的失效爲隨機事件，所以運行時間屬於隨機變量。
2、規定的條件
不同的環境條件下的可靠性是不同的，計算機的配置情況、對輸入的要求。
有了明確規定的環境條件，還可以有效地判斷軟件失效的責任在用戶方還是開發放。
3、所要求的功能
軟件可靠性還與規定的任務和功能有關。
要準確度量軟件系統的可靠性，必須先明確它的任務和功能。
4、“軟件可靠性”定義具有如下特點：
1. 用內在的“缺陷” 和 外在的“失效”關係來描述可靠性。
2. 定義使人們對軟件可靠性進行量化評估成爲可能。
3. 用概率的方法描述可靠性是比較科學的。
13.1.2 軟件可靠性的定量描述
軟件的可靠性可以基於 使用條件、規定時間、系統輸入、系統使用、軟件缺陷 等變量構建的數學表達式。
1、規定時間：自然時間、運行時間、執行時間。
使用執行時間來度量軟件的可靠性最爲準確。
2、失效率：把軟件從運行開始，到某一時刻t 爲止，出現失效的概率用 F(t)表示。
F(0)=0，即軟件運行初始時刻失效概率爲0。
F(t)在時間域(0,+無窮大)上是單調遞增的。
F(+無窮大)=1，即失效概率在運行時間不斷增長時 趨向於1，這也意味着任何軟件都存在缺陷。
3、可靠度：在規定的條件下，規定的時間內 不發生失效的概率。
4、失效強度(Failure Intensity)單位時間 軟件系統出現失效的概率。
5、失效率(Failure Rate)又稱 風險函數(Hazard Function)，也可以稱爲條件失效強度。
就是當軟件在 0～t 時刻內 沒有發生失效的條件下，t 時刻軟件系統的失效強度。
公式略。
6、可靠度與失效率之間的換算。
7、平均失效時間(Mean Time to Failure，MTTF)就是軟件運行後，到下一次出現失效的平均時間。更直觀地表明一個軟件的可靠度。
需要對 軟件可靠度 這個反映軟件可靠性的肚量指標作下列補充說明：
1. 需指明它與其他軟件的界限。
2. 軟件失效必須明確定義。
3. 必須假設硬件無故障(失效)和軟件有關變量輸入正確。
5. 必須指明時間基準：自然時間(日曆時間)、運行時間、執行時間(CPU 時間)、其他時間基準。
6. 通常以概率度量，也可以模糊數學中的可能性加以度量。
7. 在時間域上進行，是一種動態度量，也可以是在數據域上，表示成功執行一個回合的概率。
軟件回合是軟件運行最小的、不可分的執行單位。
8. 有時將軟件運行環境簡單地理解爲軟件運行剖面(Operational Profile)。
運行剖面定義了關於軟件可靠性描述中的“規定條件”，測試環境、測試數據 等一系列問題。
13.1.3 可靠性目標
使用 失效強度 表示軟件缺陷對軟件運行的影響程度。
不僅取決於軟件失效發生的概率，還和軟件失效的嚴重程度有很大關係。引出另外一個概念——失效嚴重程度類(Failure Severity Class)。
失效嚴重程度類 就是對用戶具有相同程度影響的失效集合。
對失效嚴重程度的分級 可以按照不同的標準進行，對成本影響、對系統能力的影響 等。
對成本的影響可能包括失效引起的額外運行成本、修復和恢復成本、現有潛在的業務機會的損失等。
對系統能力的影響常常表現爲 關鍵數據的損失、系統異常退出、系統崩潰、導致用戶操作無效等。
可靠性目標是指客戶對軟件性能滿意程度的期望。通常用 可靠度、故障強度、平均失效時間(MTTF)等指標來描述。
建立定量的可靠性指標需要對可靠性、交付時間、成本進行平衡。
13.1.4 可靠性測試的意義
1、軟件失效可能造成災難性的後果。
2、軟件的失效在整個計算機系統失效中的比例較高。
80%和軟件有關。
結構太複雜了，一個較簡單的程序，其所有路徑數量可能是一個天文數字。
3、相比硬件可靠性技術，軟件可靠性技術很不成熟。
4、軟件可靠性問題是造成費用增長的主要原因之一。
5、系統對於軟件的依賴性越來越強。
13.1.5 廣義的可靠性測試與俠義的可靠性測試
廣義的軟件可靠性測試是指爲了最終評價軟件系統的可靠性而運用建模、統計、試驗、分析、和評價等一系列手段對軟件系統實施的一種測試。
俠義的軟件可靠性測試是指爲了獲取可靠性數據，按預先確定的測試用例，在軟件的預期使用環境中，對軟件實施的一種測試。
也叫“軟件可靠性試驗(Software Reliability Test)”，它是面向缺陷的測試，以用戶將要使用的方式來測試軟件，所獲得的測試數據與軟件的實際運行數據比較接近。
可靠性測試是對軟件產品的可靠性進行調查、分析、評價的一種手段。
對檢測出來的失效的分佈、原因、後果 進行分析，並給出糾正建議。
總的來說，可靠性測試的目的可歸納爲以下三個方面：
1、發現軟件系統在 需求、設計、編碼、測試、實施 等方面的 各種缺陷。
2、爲軟件的使用、維護提供可靠性數據。
3、確認軟件是否達到可靠性的定量要求。
13.2 軟件可靠性建模
13.2.1 影響軟件可靠性的因素
軟件可靠性模型(Software Reliability Model)是指 爲預計或估算軟件的可靠性所建立的可靠性框圖和數學模型。
模型將複雜系統的可靠性逐級分解爲簡單系統的可靠性，以便 定量預計、分配、估算、評價複雜系統的可靠性。
影響軟件可靠性的主要因素：缺陷的引入、發現、清除。
缺陷的引入主要取決於軟件產品的特徵和軟件的開發過程特性。
缺陷的發現依靠運行剖面。
缺陷的清除依賴於失效的發現、修復活動、可靠性方面的投入。
影響軟件可靠性的主要因素如下：
1、運行剖面(環境)。
2、軟件規模。
3、軟件內部結構。
4、軟件的開發方法和開發環境。
5、軟件的可靠性投入。人力、資金、資源、時間 等。
早期重視軟件可靠性並採取措施開發出來的軟件，可靠性有明顯的提高
13.2.2 軟件可靠性建模方法
可靠性模型通常由以下幾部分組成：
1、模型假設。模型是實際情況的簡化或規範化，總要包含若干假設。
2、性能度量。軟件可靠性模型的輸出量就是性能度量。
3、參數估計方法。
4、數據要求。
絕大多數模型包含三個共同假設：
1、代表性假設。選取代表軟件實際的運行剖面。
2、獨立性假設。假設認爲軟件失效是獨立發生於不同時刻。
3、相同性假設。認爲所有軟件失效的後果(等級)相同，即建模過程只考慮軟件失效的具體發生時刻，不區分軟件的失效嚴重等級。
如果在進行預測時發現引入了新的錯誤，或修復行爲使新的故障不斷髮生，就應該停止預測。否則，這樣的變化會因爲增加問題的複雜程度而使模型的適用性降低。
好的軟件可靠性模型應該具有如下重要特性：
1、基於可靠性的假設。
2、簡單。
3、計算一些有用的量。
4、給出未來失效行爲的好的映射。
5、可廣泛使用。
13.2.3 軟件的可靠性模型分類
可靠性模型大致可分爲如下10類：
1、種子方法模型。
利用捕獲一再捕獲抽樣技術估計程序中的錯誤數，在程序中預先有意“播種”一些設定錯誤的“種子”，然後根據測試出的原始錯誤和發現的誘導錯誤比例，估計程序中殘留的錯誤數。
優點是簡單易行，缺點是誘導錯誤的“種子”與實際的原始錯誤之間的類比性估量困難。
2、失效率類模型。
3、曲線擬合類模型。
用迴歸分析的方法研究軟件 複雜性、缺陷數、失效率、失效間隔時間，包括參數方法和非參數方法兩種。
4、可靠性增長模型。
5、程序結構分析模型。
通過對每一個節點可靠性、節點間轉換的可靠性和網絡在節點間的轉換概率，得出該持續程序的整體可靠性。
6、輸入域分類模型。
7、執行路徑分析方法模型。
8、非其次泊松過程模型。
NHPP，以軟件測試過程中單位時間的失效次數爲獨立泊松隨機變量，來預測今後軟件的某使用時間點的積累失效次數。
9、馬兒可夫過程模型。
10、貝葉斯模型。
利用失效率的試驗前分佈和當前的測試失效信息，來評估軟件的可靠性。
當軟件可靠性工程師對軟件的開發過程有充分的瞭解，軟件的繼承性比較好時具有良效果的可靠性分析模型。
時間域。
失效數類：失效數是有限的還是無限的。
失效數分佈。
有限類：用時間表示的失效強度的函數形式。
無限類：用經驗期望失效數表示的失效強度的函數形式。
13.2.4 軟件可靠性模型舉例
1、模型假設
JM 模型的基本假設如下：
1. 初始錯誤個數爲一個未知的常數。
2. 發現錯誤立即被完全排除，並且不引入新的錯誤，排除時間忽略不記，因此每次排錯後就要減 1。
3. 失效率剩餘的錯誤個數成正比。
2、函數表達式。
軟件可靠性模型並不成熟，定量分析方法和數學模型要在實踐中不斷加以驗證和修正。
不同類型的軟件，應用方式也有很大區別。
13.2.5 軟件可靠性測試概述
可靠性測試 由可靠性目標的確定、運行剖面的開發、測試用例的設計、測試實施、測試結果的分析 等主要活動組成。
軟件可靠性測試 還必須考慮對軟件開發進度和成本的影響，最好是在受控的自動測試環境下，由專業測試機構完成。
13.2.6 定義軟件運行剖面
弧 用來連接狀態並表示由各種激勵導致的轉換，將轉換概率分配給每個弧。
每類用戶都可能以不同的方式使用系統。
兩種類型分層形式：用戶級分層、用法級分層。
用法級分層依賴於在測試狀態下系統能做什麼。
用戶級分層考慮各種類型的用戶，以及他們如何使用系統。
這些概率估計主要是基於如下幾個方面：
1、從現有系統收集到的數據。
2、與用戶的交談或對用戶進行觀察獲得的信息。
3、原型使用與測試分析的結果。
4、相關領域專家的意見。
13.2.7 可靠性測試的實施
有必要檢查軟件需求與文檔是否一致，檢查軟件開發過程中形成的文檔的準確性、完整性、一致性。
可靠性測試依賴於軟件的可測試性。
爲了獲得更多的可靠數據，應該使用多態計算機同時運行軟件，以增加累計時間。
用時間定義的軟件可靠性數據分爲4類：
1、失效時間數據。
2、失效間隔時間數據。
3、分組時間內的失效數據。
4、分組時間的累計失效數。
這 4類數據可以相互轉化。
測試過程中必須真實地進行記錄，每個測試記錄必須包含如下信息：
1、測試時間。
2、含有測試用例的測試說明或標識。
3、所有與測試有關的測試結果，包括失效數據。
4、測試人員。
測試活動結束後要編寫《軟件可靠性測試報告》具備如下內容：
1、軟件產品標識。
2、測試環境配置(硬件和軟件)。
3、測試依據。
4、測試結果。
5、測試問題。
6、測試時間。
13.3 軟件可靠性評價
13.3.1 軟件可靠性評價概述
估計軟件當前的可靠性，以確認是否可以終止測試併發布軟件，還可以預計軟件要達到相應的可靠性水平所需要的時間和工作量，確認軟件的執行與需求的一致性。
13.3.2 怎樣選擇可靠性模型
可以從以下幾個方面進行比較和選擇：
1、模型假設的適用性。
2、預測的能力與質量。
3、模型輸出值能否滿足可靠性評價需求。
最重要的幾個需要精確估計的可靠性定量指標包括如下內容：
1. 當前的可靠度。
2. 平均失效時間。
3. 故障密度。
4. 期望達到規定可靠性目標的日期。
5. 達到規定的可靠性目標的成本要求。
4、模型使用的簡便性
簡便性一般包含如下三層含義：
1. 模型需要的數據 易於收集，成本不能超過可靠性計劃的預算。
2. 模型應該簡單易懂，測試人員不會花費太多的時間去研究專業的數學理論。
3. 模型應該便於使用。
13.3.3 可靠性數據的收集
面向缺陷的可靠性測試 產生的測試數據經過分析後，可以得到非常有價值的可靠性數據，這部分數據取決於定義的運行剖面和選取的測試用例集。
可靠性數據的收集工作是貫穿整個軟件生命週期的。
可行的一些辦法如下：
1、及早確定所採用的可靠性模型。
2、指定可實施性較強的可靠性數據收集計劃，指定專人負責，按照統一的規範收集記錄可靠性數據。
3、重視軟件測試特別是可靠性測試產生的測試數據的整理和分析。
4、充分利用數據庫來完成可靠性數據的存儲和統計分析。
13.3.4 軟件可靠性的評估和預測
1、判斷是否達到了可靠性目標。
2、如未能達到，要再投入多少時間、多少人力、多少資金。
3、在軟件系統投入實際運行 若干時間後，能否達到交付或部分交付用戶使用的可靠性水平。
沒有失效就無法估計可靠性。
要在模型之外運行一些統計技術和手段對可靠性數據進行分析，作爲可靠性模型的補充、完善、修正。
輔助方法如下：
1、失效數據的圖形分析方法。
1. 積累失效個數圖形。
2. 單位時間段內的失效數的圖形。
3. 失效間隔時間圖形。
2、試探性數據分析技術(Exploratory Data Analysis，EDA)對可靠性分析有用的信息如下：
1. 循環相關。
2. 短期內失效數的急劇上升。
3. 失效數集中的時間段。
13.4 軟件的可靠性設計與管理
13.4.1 軟件可靠性設計
實踐證明，保障軟件可靠性,最有效、最經濟、最重要的手段是 在軟件設計階段採取措施進行可靠性控制。
1、軟件可靠性設計是軟件設計的一部分，必須在軟件的總體設計框架中使用，並且不能與其他設計原則相沖突。
2、軟件可靠性設計在滿足提高軟件質量要求的前提下，以提高和保障軟件可靠性爲最終目標。
3、軟件可靠性設計應確定軟件的可靠性目標，不能無限擴大化，排在功能度、用戶需求、開發費用之後考慮。
容錯設計、檢錯設計、降低複雜度設計 等技術。
1、容錯設計技術
1. 恢復塊設計，一旦文本出現故障，用備份文本加以替換。
2. N版本程序設計，對於相同初始條件和相同輸入的操作結果，實行多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務。
必須注意以下兩方面：
使軟件的需求說明具有完整性和精確性。
設計全過程的不相關性。
3. 冗餘設計
在相同的運行環境中，一套軟件出故障的地方，另外一套也一定會出現故障。
在一套完整的軟件系統之外，設計一種不同路徑、不同算法或不同實現方法的模塊或系統作爲備份。
費用可能接近單個版本軟件開發費用的兩倍，還有可能導致軟件運行時所花費的存儲空間、內存消耗、運行時間有所增加，需要在可靠性要求和額外付出代價之間做出折中。
2、檢錯技術
檢錯技術實現的代價一般低於容錯技術和冗餘技術，但它有一個明顯的缺點，就是不能自動解決故障。
着重考慮幾個要素：檢測對象、檢測延時、實現方式、處理方式。
3、降低複雜度設計
模塊複雜性主要包含模塊內部數據流向和程序長度兩個方面，結構複雜性用不同模塊之間的關聯程度表示。
軟件複雜性是產生軟件缺陷的重要根源。
在設計師就應該考慮降低軟件的複雜性，是提高軟件可靠性的有效方法。
在保證實現軟件功能的基礎上，簡化軟件結構，縮短程序代碼長度，優化軟件數據流向，降低軟件複雜度，從而提高軟件可靠性。
13.4.2 軟件可靠性管理
爲了進一步提高軟件可靠性，又提出軟件可靠性管理的概念，把軟件可靠性活動貫穿於軟件開發的全過程。
各個階段的可靠性活動的目標、計劃、進度、任務、修正措施等。
由於軟件之間的差異較大，下面的每項活動並不是每一個軟件系統的可靠性管理的必須內容，也不是軟件可靠性管理的全部內容
2011年軟考系統架構設計師學習筆記第十四章
基於ODP的架構師實踐
14.1 基於ODP的架構開發過程
系統架構反映了功能在系統系統構件中的分佈、基礎設施相關技術、架構設計模式等，它包含了架構的原則和方法、構件關係與約束，並能支持迭加或增量開發。
以軟件架構爲中心的開發過程是以質量和風險驅動的，最終提供一個穩定、低風險的系統架構，並滿足客戶的需求(包含潛在需求)。
開放分佈進程的參考模型(RM-ODP)是一個ISO標準，定義了分佈系統的重要性質：
開放性、整體性、靈活性、可塑性、聯合性、可操作管理性、優質服務、安全性、透明性。
RM-ODP定義的 5個觀點：
1、企業視點：商業需求和策略、系統的範圍和目的。可能會影響系統中的與企業相關的信息，如組織結構等。
2、信息視點。
3、計算視點。
4、工程視點。
5、技術視點。
每一個觀點有具體的建模目標和系統相關者。
分層子系統視圖提供了一個所有子系統高度抽象的視圖。
14.2 系統構想
14.2.1 系統構想的定義
系統構想是開發人員與用戶之間共同的協議。
按照該協議，開發人員需要在特定的時間內完成系統用戶的需求，系統構想必須簡短而切中要點。
高度概括了業務架構的核心內容。
14.2.2 架構師的作用
系統構想有助於各方明瞭系統的目標和範圍。
確保系統開發的計劃、設計等階段能依次有序地展開。
系統構想階段，架構師合理的介入，有以下好處：
1、有利於使系統架構師本身對系統的看法更加全面、準確。
2、統一系統開發人員對系統的看法。
3、正確確定需求的優先次序。
4、最大程度上提高客戶對設計等過程的參與程度，更好地與客戶溝通。
14.2.3 系統構想面臨的挑戰
架構師對其控制能力之外的因素通常無能爲力，可以通過有效地評估，以及高級經理和架構師之間保持緊密的聯繫克服這些困難。
還必須面對以下幾種情況：
1、很多架構師把架構看成是他們獨自的創造，只要他們認爲合適的就進行修改。
2、有些人不是擁有產品線構想的高級經理，卻總是由這些人決定僱傭誰來做架構師。
14.3 需求分析
14.3.1 架構師的工作
需求一般定義系統的外部行爲和外觀以及用戶信息，而不用設計系統的內部結構。
對需求分析通常考察以下6個方面的內容：
1、系統範圍對象關係圖。
2、用戶接口原型，用戶操作的一個雛形。
3、需求的適用性，該用什麼技術解決，性能怎麼樣，是否與其他需求相重合或矛盾，需求分析應注意需求本身的實用或適用，而不必考慮其實現。
4、確定需求的優先級。
5、爲需求建立功能結構模型，組件圖，實體數據對象圖。
6、使用質量功能分配(Quality Function Deploymen，QFD)發現隱藏質量需求，建立相關質量場景，先期預測需求風險。
有效地捕捉行爲需求的方法是分析用例(Use Case)
用例包含圖和文字描述，符號 簡單、抽象，保證表述需求時簡單性和清晰度。
14.3.2 需求分析的任務
1、需求分析的目的
完整、準確地描述用戶對系統的需求，跟蹤用戶需求的變化，準確地反映到系統架構和設計中，設計和用戶的需求保持一致。
具有決策性、方向性、策略性的作用。
2、需求分析的特點
追求系統需求的完整性、一致性、驗證性。
保持和用戶要求同步，
保持需求分析各側面之間的一致，
保持需求和系統設計間的同步。
14.3.3 需求文檔與架構
每個用例都有一個相關需求的文字描述，定義用例應該和領域專家一起進行，如果沒有領域專家的長期參與，只能是一種“僞分析”。
用例爲定義架構提供了一個系統的領域行爲模型。
界面的外觀、功能、導航同用例緊密相連，有效定義屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，領域專家也始終參與到屏幕定義中去。
需求分析的項目詞彙表，也將在架構規劃中被擴展。
14.4 系統架構設計
系統架構溝通了需求和軟件之間巨大的語義上的鴻溝。
系統架構的第一個任務就是定義這兩個極端之間的映射。
開放分佈式處理(Open Distributed Processing，ODP)包括企業、邏輯信息、計算接口、分佈式工程、技術選擇。
對每個觀點，確認架構需求的一致性是非常重要的。
14.4.1 企業業務架構
企業業務架構從IT角度，對企業的業務結構、企業機構、業務的關係、內部的關係、與外部機構的關係進行整理定義。
包含如下內容：
1、企業的業務和戰略目標，近期、中期、長遠 目標。
2、企業的組織結構。
3、業務的分類。
4、各類業務之間的關係。
5、組織機構與業務的關係。
6、企業與外部機構的關係。
這些業務對象模型標識出系統的關鍵性約束，包括系統目標和重要的系統策略。
策略包含如下三類明確的表達方式：
責任：業務對象必須做什麼。
許可：業務對象可以做什麼。
禁止：業務對象不可以做什麼。
對業務問題進行分析時，要考慮企業業務的發展，如新的服務或產品推出、考慮組織機構的改變等。
所有這些可能的變化(易變場景)都應該提現在企業業務架構中。
通過對企業業務架構的定義，很清楚地知道由於企業業務特點、業務的流程特點、企業的組織機構等原因對IT系統所帶來的自然分塊和各個分塊之間的邊界關係。
企業業務架構的維護是一個長期而反覆的工作。
測試結果報告系統(Test Results Reporting System，TRRS)。
對象約束語言(Object Constraint Language，OCL)來定義企業活動者的這些策略(如 許可、禁止、義務等)。
邏輯信息架構(信息視點)標識出系統必須知道什麼。
強調定義系統狀態的屬性。
開放分佈式處理是一種面向對象的方法，模型包含了關鍵信息的處理，如傳統的對象概念。
軟件架構對象並不是編程的對象，它表示對系統的約束和依賴，這些約束能夠消除把需求翻譯成軟件過程中的許多猜測性工作。
架構師應該把他們的建模集中於有高風險、高複雜性、模糊性的關鍵方面。
14.4.3 計算接口架構
計算接口對系統架構非常有幫助，但是它常常被架構師所忽略。
消除多個開發者和小組的主要設計爭端，這些接口的架構控制對於一個支持變化和控制複雜性的穩定的系統結構來說，是非常重要的。
接口定義語言(IDL)，完全獨立於編程語言和操作系統。
14.4.4 分佈式工程架構
分佈式工程架構定義了底層結構的需求，獨立於所選擇的技術，解決了最複雜的系統策略，包括物理位置、系統規模可變性、通信服務質量。
ODP的一個最大好處是關注點分離。
14.4.5 技術選擇架構
大多數架構是獨立的。
基於對候選者的初始選擇，根據產品價格、培訓要求、維護風險之類的項目因素而反覆進行。
14.5 實現模型
最終用戶和架構師應在一起審查並貫穿於用例，始終來證實需求的有效。
對產品設計的可行性做出準確地評估、論證。
14.6 架構原型
架構原型是很好的需求驗證工具，作爲改進設計的手段，確保與工程約束相一致。
下面是一些架構師可以在架構原型中尋求解答的具體問題：
1、主要組件是否得到了良好的定義?是否恰當?
2、主要組件間的協作是否得到了良好的定義?
3、耦合是否得意最小化?
4、我們能否確定重用的潛在來源?
5、接口定義和各項約束是否可以接受?
6、每個模塊是否能訪問到其所需要的數據?
經過2次或3次迭代之後，架構變得穩定。主要的抽象對象都已找到，子系統和過程都已經完成，所有的接口都已明確定義。
利用架構原型，幾個好處：
1、落實之前，讓團隊成員能自由發表他們自己的看法。
2、統一團隊之間的思想看法，提高系統開發的成功率。
3、對系統內部的結構分析與設計也有幫助。
14.7 項目規劃
項目規劃是通過批准的正式文檔，以它爲基準跟蹤和控制項目，行動方案和資源分配，引導項目實施。
主要作用是將指定規劃的假設和決定批准的範圍、成本、進度 的基線等用正式的文檔記錄保存。
估算是項目規劃的核心。
隨着項目的進展，估算會不斷校正並逐漸地接近實際。
項目管理者通過計劃與規劃的差異，不斷優化和更新計劃策略，使項目按規劃的要求得以實現，計劃的變更是可管理和可受控的。
規劃包括：
1、項目的目的、範圍、目標、對象。
2、軟件生存週期 的選擇。
3、精選的規程、方法、標準。
4、待開發的軟件工作產品。
5、規模估計、軟件項目的工作量和成本估計。
6、關鍵計算機資源的估計;項目的里程碑。
7、風險的識別和評估。
8、工程實施和支持工具計劃。
軟件項目計劃的目標有：軟件估計被文檔化，活動和約定形成文檔，受影響的組和個人認同與軟件項目規劃的約定。
14.8 並行開發
14.8.1 軟件並行開發的內容及意義
提高軟件生產率，改善軟件質量，有效地組織可以重複的資源。
並行開發研究的內容主要如下：
1、軟件過程及其模型。
2、並行分成劃分。
3、並行控制。
4、支持環境。
5、交互機制與集成技術。
14.8.2 並行開發的過程
把軟件系統的開發過程劃分爲若干個可以並行的成分，這個成分稱之爲子開發過程。
子開發過程 = 開發小組 + 軟件對象 + 對軟件對象的開發活動。
並行開發活動，稱爲並行開發系統，實體是個開發小組，實體屬性是被開發的軟件對象，行爲是開發軟件對象的活動。
行爲模塊的劃分是並行開發中的核心問題，模塊獨立性是衡量軟件設計質量的關鍵。
系統劃分方法：
1、基於 Petri網系統模型的動態劃分方法。
2、基於腳本的系統劃分方法。
軟件過程並行控制是一個非常重要的問題。
就是要用正確的方式調度並行操作，避免造成不一致性，使一個操作的執行不受其他系統的干擾。
保證一致性、相容性、正確性、可靠性，手段有 加鎖、時間戳、管程、Petri 網、PV 操作等。
繼承和測試被分爲兩個階段，如果不考慮硬件或軟件的集成，兩個階段並沒有明顯的界限，所以，軟件集成的主要問題是集成測試技術。
14.9 系統轉換
系統轉換是指運用某一種方式由新的系統代替舊的系統的過程，也就是系統設備、數據、人員等方面的轉換。
14.9.1 系統轉換的準備
轉換前，必須認真做好準備。
還需測試試運行這項工作。
注意如下兩個問題：
1、系統試運行工作的代表性。
2、系統試運行中錯誤的修正。
14.9.2 系統轉換的方式
直接轉換、平行轉換、分段轉換、分批轉換。
14.9.3 系統轉換的注意事項
1、大量的基礎數據，錄入工作量很大，應及早準備，儘快完成。
2、應提前做好人員的培訓工作。
3、出現一些局部性的問題，應有足夠的準備，並做好記錄。如果出現致命問題，要重新設計。
14.10 操作與維護
14.10.1 操作與維護的內容
數據管理與維護。
設備管理與維護。
軟件的管理與維護工作。
14.10.2 系統維護與架構
系統架構的好壞，可維護性是一個重要方面，維護人員應參與架構的審評。
可維護性可以定性地定義爲：維護人員 理解、改正、改動、改進的難易程度。
可維護性有如下幾個評價指標：
可理解性。
可測試性。
可修改性。
系統維護工作可以分爲以下4種類型：
更正性維護。
適應性維護。
完善性維護。
預防性維護。
維護人員必須先理解要維護的系統，然後建立一個維護方案。
由於某處修改很可能會影響其他模塊程序，所以考慮的重要問題是修改的影響範圍和波及面的大小。
必須強調的是，維護是對整個系統而言的，必須同時修改涉及的所有文檔。
14.11 系統移植
14.11.1 系統移植的方式
不修改已有的軟件。
修改軟件。
重新編軟件。
14.11.2 系統移植的工作階段劃分
計劃階段。
準備階段，準備轉換所需的材料。
轉換階段。
測試階段。
驗證階段。
使系統移植工作標準化，工具實現自動化。
14.11.3 系統移植工具
系列化、標準化、文檔化，使任何人都能以相同的順序開展工作，提高效率。
