Fundamentals of Software Architecture：An Engineering Approach学习笔记
目錄
1、總覽
2、介紹
2.1 定義
2.2 架構師要求
2.3 軟件架構定理
3、架構思維
4、模塊化
?4.1 定義
4.2 衡量模塊化
?4.2.1 內聚性測量
4.2.2 耦合性測量
4.2.3 關聯性(共生性)
5、定義架構特征
5.1 三標準
5.2 運營類架構特征
?5.3 結構型架構特征
5.4 交叉/橫切類架構特征
6、識別架構特征
7、測量和治理架構特征
8、架構特征范圍
9、基于組件思維
9.1 組件范圍
9.2 架構師角色
9.3 開發(fā)者角色
9.4 組件識別流程
9.5 組件設計
10、分層架構
10.1 拓撲
10.2 架構特征
11、Pipeline架構樣式
11.1 拓撲
11.2 架構特征
12、微內核架構樣式
?12.1 拓撲
12.2 架構特征
13、基于服務的架構樣式
?13.1 拓撲
13.2 拓撲變體
13.3 架構特征
14、事件驅動架構樣式
14.1 拓撲
14.2 基于請求與基于事件的選擇
14.3 架構特征
15、基于空間架構樣式
15.1 拓撲
15.2 復制緩存與分布式緩存的選擇
15.3 架構特征
16、編排驅動的面向服務架構樣式
16.1 拓撲
16.2 架構特征
17、微服務架構樣式
17.1 拓撲
17.2 架構特征
18、選擇合適的架構樣式
18.1 考慮因子
18.2 決策
19、架構決策
19.1 反模式
19.2 架構重點
19.3 架構決策記錄
20、分析架構風險
20.1 風險矩陣
20.2 風險風暴
21、圖表化和演示架構
21.1 圖表化
21.1.1 工具
21.1.2 圖表繪制標準
21.1.3?圖表指導原則?
21.2 演示
22、使團隊高效
22.1 團隊邊界
22.2 架構師個性
22.3 檢查清單
22.4 提供指導
23、談判和領導技能?
23.1 談判
23.2 領導
24、發(fā)展職業(yè)道路
?24.1 20分鐘規(guī)則
24.2 技術雷達
24.3 使用社交媒體
24.4 臨別贈言
1、總覽
?
2、介紹
2.1 定義
由系統(tǒng)結構、架構特征、架構決策和設計原則組成?
2.2 架構師要求
2.3 軟件架構定理
?
3、架構思維
?
4、模塊化
?4.1 定義
標準部件或者獨立單元集中的每一個可以用于構建更加復雜的結構。模塊化用來相關代碼的邏輯分組，在面向對象語言上是一組類，在結構化或者函數語言中，是一組函數。
4.2 衡量模塊化
?4.2.1 內聚性測量
是通過LCOM（方法上缺乏內聚）即未通過共享字段共享的方法集的總和，其計算公式為
其中|P|是在方法沒有訪問公共字段時+1,|Q|是在方法分享一個公共字段是-1?
另一種公式是
4.2.2 耦合性測量
?
?抽象度計算公式?
表示抽象元素，如接口或者抽象類，表示具體的元素如非抽象類?
不穩(wěn)定性計算公式
表示出度耦合，表示入度耦合?
主序列距離計算公式?
其中A表示抽象度，I表示不穩(wěn)定性?
?從抽象度來分析，右上角的過度抽象，屬于無用區(qū)，左下角具體類過多，難以維護，屬于痛苦區(qū)
4.2.3 關聯性(共生性)
分為兩類，靜態(tài)關聯和動態(tài)關聯
關聯屬性有如下
?強度由強到弱關系為
?地區(qū)指的是關聯是在模塊間還是模塊內
程度指的是關聯的影響大小。
使用關聯來改善系統(tǒng)模塊化的原則?
- 通過將系統(tǒng)分解為封裝元件，最大限度地減少整體關聯
- 最小化任何跨越封裝邊界的剩余關聯
- 最大化封裝邊界內的關聯
關聯相關建議
- 程度規(guī)則：將強形式的關聯轉為弱形式的關聯
- 地區(qū)規(guī)則：隨著軟件元素距離增加，使用弱形式的關聯
5、定義架構特征
5.1 三標準
5.2 運營類架構特征
?
?5.3 結構型架構特征
5.4 交叉/橫切類架構特征
6、識別架構特征
從三方面：領域關注點，需求，隱式領域知識
領域關注點與架構特征關系
| 領域關注點 | 架構特征 |
| 合并收購 | Interoperability, scalability, adaptability, extensibility |
| 上市時間 | Agility, testablity, deployability |
| 用戶滿意度 | Performance, availability, fault tolerance, testability, deployability, agility, security |
| 競爭優(yōu)勢 | Agility, testability, deployability, scalability, availability, fault tolerance, |
| 時間和預算 | Simplicity, feasibility |
7、測量和治理架構特征
?測量架構特征分為三類：運營類測量，結構型測量，過程測量 (軟件開發(fā)過程)
適度度函數：為某些架構特征或者架構特征組合提供客觀完整性評估的任何機制。是許多現有工具的新視角。架構特性的驗證技術隨特性的不同而變化。驗證技術包括指標，監(jiān)控，單元測試及混沌工程
8、架構特征范圍
屬于量子范圍
9、基于組件思維
9.1 組件范圍
9.2 架構師角色
9.3 開發(fā)者角色
9.4 組件識別流程
?
9.5 組件設計
?
10、分層架構
10.1 拓撲
10.2 架構特征
11、Pipeline架構樣式
11.1 拓撲
?
11.2 架構特征
?
12、微內核架構樣式
?12.1 拓撲
12.2 架構特征
?
13、基于服務的架構樣式
?13.1 拓撲
13.2 拓撲變體
?用戶接口拆分
單體數據庫拆分
13.3 架構特征
?
14、事件驅動架構樣式
14.1 拓撲
?分兩種形式：broker和medicator
broker拓撲為
broker拓撲的權衡
| 優(yōu)勢 | 劣勢 |
| 高度解耦的事件處理器 | 工作流控制? |
| 高可擴展性 | 錯誤處理 |
| 高響應性 | 可恢復性 |
| 高性能 | 重啟能力 |
| 高容錯性 | 數據一致性 |
?medicator拓撲為
?medicator拓撲權衡
| 優(yōu)勢 | 劣勢 |
| 工作流控制? | 事件處理器的更多耦合 |
| 錯誤處理 | 較低的可伸縮性 |
| 可恢復性 | 低性能 |
| 重啟能力 | 低容錯性 |
| 更好的數據一致性 | 復雜工作流建模 |
14.2 基于請求與基于事件的選擇
基于事件模型的權衡
| 與基于請求相比的優(yōu)勢 | 權衡 |
| 更好地響應動態(tài)用戶內容 | 只支持最終一致性 |
| 更好的可擴展性和彈性 | 對處理流程的控制較少 |
| 更好的敏捷性和變更管理 | 事件流結果的不確定性 |
| 更好的適應性和可擴展性 | 難以測試和調試 |
| 更好的響應能力和性能 | |
| 更好的實時決策 | |
| 對態(tài)勢感知的更好反應 |
14.3 架構特征
15、基于空間架構樣式
15.1 拓撲
15.2 復制緩存與分布式緩存的選擇
| 選擇標準 | 復制緩存 | 分布式緩存? |
| 優(yōu)化 | 性能 | 一致性 |
| 緩存大小 | 小（<100 MB） | 大（>500 MB） |
| 數據類型 | 相對不變動的 | 高度動態(tài) |
| 更新頻率 | 相對低 | 高更新率 |
| 容錯 | 高 | 低 |
15.3 架構特征
16、編排驅動的面向服務架構樣式
16.1 拓撲
16.2 架構特征
?
17、微服務架構樣式
17.1 拓撲
17.2 架構特征
?
18、選擇合適的架構樣式
18.1 考慮因子
18.2 決策
?
19、架構決策
19.1 反模式
19.2 架構重點
?
19.3 架構決策記錄
?
20、分析架構風險
20.1 風險矩陣
20.2 風險風暴
21、圖表化和演示架構
21.1 圖表化
21.1.1 工具
21.1.2 圖表繪制標準
?
ArchiMate核心框架?
由業(yè)務、應用和技術元素定義的核心的方面和層可以組織為九個單元的框架?
方面和層
ArchiMate語言的主要概念和關系可以看成一個框架。它將企業(yè)架構分為業(yè)務層、應用層和技術層
在每一層中，都考慮了三個方面：表現行為的活動元素，內部結構和定義使用或交流信息的元素。
方面
圖層
高層使用低層提供的服務。業(yè)務層向外部客戶提供產品和服務，這些產品和服務由業(yè)務參與者執(zhí)行的業(yè)務流程實現。應用層通過（軟件）應用實現的應用服務支持業(yè)務層。技術層提供運行應用程序所需的基礎設施服務（例如處理、存儲和通信服務），由計算機和通信硬件和系統(tǒng)軟件實現。?
ArchiMate完整框架
完整的 ArchiMate 語言為核心框架添加了多個層和一個方面。物理元素被添加到技術層，用于對物理設施和設備、分配網絡和材料進行建模。此外，還添加了一個額外的動機方面以及實現和遷移元素?
21.1.3?圖表指導原則?
21.2 演示
?
22、使團隊高效
22.1 團隊邊界
22.2 架構師個性
?
22.3 檢查清單
22.4 提供指導
?
23、談判和領導技能?
23.1 談判
與業(yè)務利益相關者談判
- 利用語法和流行語更好地了解情況?
- 在開始談判之前，收集盡可能多的信息
- 當所有其他方法都失敗時，按照成本和時間來陳述
- 利用“分而治之”規(guī)則來限定需求
與其他架構師談判
- 永遠記住，演示戰(zhàn)勝了討論
- 避免在談判中過于爭辯或過于私人化。冷靜的領導加上清晰簡潔的推理，總能贏得談判
與開發(fā)人員談判
- 當說服開發(fā)人員采用架構決策或執(zhí)行特定任務時，請?zhí)峁├碛?#xff0c;而不是“從高層指揮”
- 如果開發(fā)人員不同意某個決定，讓他們自己得出解決方案?
23.2 領導
?
架構中的4C
與開發(fā)團隊整合：
- 請?zhí)崆霸儐枙h議程，以幫助確定你是否需要參加會議?
24、發(fā)展職業(yè)道路
?24.1 20分鐘規(guī)則
早晨20分鐘用于學習新技能等
24.2 技術雷達
?
24.3 使用社交媒體
?
24.4 臨別贈言
?
?
參考資料：
https://www.cnblogs.com/uml-tool/articles/15512630.html
ArchiMate? Specification | The Open Group Website
總結
以上是生活随笔為你收集整理的Fundamentals of Software Architecture：An Engineering Approach学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 科学技术创新杂志科学技术创新杂志社科学技
- 下一篇： WebView清除缓存