目錄

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 開發者角色

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、發展職業道路

?24.1 20分鐘規則

24.2 技術雷達

24.3 使用社交媒體

24.4 臨別贈言

---

1、總覽

?

2、介紹

2.1 定義

由系統結構、架構特征、架構決策和設計原則組成?

2.2 架構師要求

2.3 軟件架構定理

?

3、架構思維

?

4、模塊化

?4.1 定義

標準部件或者獨立單元集中的每一個可以用于構建更加復雜的結構。模塊化用來相關代碼的邏輯分組，在面向對象語言上是一組類，在結構化或者函數語言中，是一組函數。

4.2 衡量模塊化

?4.2.1 內聚性測量

是通過LCOM（方法上缺乏內聚）即未通過共享字段共享的方法集的總和，其計算公式為

其中|P|是在方法沒有訪問公共字段時+1,|Q|是在方法分享一個公共字段是-1?

另一種公式是

4.2.2 耦合性測量

?

?抽象度計算公式?

表示抽象元素，如接口或者抽象類，表示具體的元素如非抽象類?

不穩定性計算公式

表示出度耦合，表示入度耦合?

主序列距離計算公式?

其中A表示抽象度，I表示不穩定性?

?從抽象度來分析，右上角的過度抽象，屬于無用區，左下角具體類過多，難以維護，屬于痛苦區

4.2.3 關聯性(共生性)

分為兩類，靜態關聯和動態關聯

關聯屬性有如下

?強度由強到弱關系為

?地區指的是關聯是在模塊間還是模塊內

程度指的是關聯的影響大小。

使用關聯來改善系統模塊化的原則?

• 通過將系統分解為封裝元件，最大限度地減少整體關聯
• 最小化任何跨越封裝邊界的剩余關聯
• 最大化封裝邊界內的關聯

關聯相關建議

• 程度規則：將強形式的關聯轉為弱形式的關聯
• 地區規則：隨著軟件元素距離增加，使用弱形式的關聯

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
競爭優勢	Agility, testability, deployability, scalability, availability, fault tolerance,
時間和預算	Simplicity, feasibility

7、測量和治理架構特征

?測量架構特征分為三類：運營類測量，結構型測量，過程測量 (軟件開發過程)

適度度函數：為某些架構特征或者架構特征組合提供客觀完整性評估的任何機制。是許多現有工具的新視角。架構特性的驗證技術隨特性的不同而變化。驗證技術包括指標，監控，單元測試及混沌工程

8、架構特征范圍

屬于量子范圍

9、基于組件思維

9.1 組件范圍

9.2 架構師角色

9.3 開發者角色

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拓撲的權衡

優勢	劣勢
高度解耦的事件處理器	工作流控制?
高可擴展性	錯誤處理
高響應性	可恢復性
高性能	重啟能力
高容錯性	數據一致性

?medicator拓撲為

?medicator拓撲權衡

優勢	劣勢
工作流控制?	事件處理器的更多耦合
錯誤處理	較低的可伸縮性
可恢復性	低性能
重啟能力	低容錯性
更好的數據一致性	復雜工作流建模

14.2 基于請求與基于事件的選擇

基于事件模型的權衡

與基于請求相比的優勢	權衡
更好地響應動態用戶內容	只支持最終一致性
更好的可擴展性和彈性	對處理流程的控制較少
更好的敏捷性和變更管理	事件流結果的不確定性
更好的適應性和可擴展性	難以測試和調試
更好的響應能力和性能
更好的實時決策
對態勢感知的更好反應

14.3 架構特征

15、基于空間架構樣式

15.1 拓撲

15.2 復制緩存與分布式緩存的選擇

選擇標準	復制緩存	分布式緩存?
優化	性能	一致性
緩存大小	小（<100 MB）	大（>500 MB）
數據類型	相對不變動的	高度動態
更新頻率	相對低	高更新率
容錯	高	低

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核心框架?

由業務、應用和技術元素定義的核心的方面和層可以組織為九個單元的框架?

方面和層

ArchiMate語言的主要概念和關系可以看成一個框架。它將企業架構分為業務層、應用層和技術層

在每一層中，都考慮了三個方面：表現行為的活動元素，內部結構和定義使用或交流信息的元素。

方面

所述活性結構方面表示結構的概念（即顯示實際行為的業務演員，應用程序組件，和設備，即，活動的“主題”）。

所述行為方面表示由演員執行的行為（進程，函數，事件和服務）。行為概念被分配給結構概念，以顯示誰或什么顯示了行為。

所述被動結構方面（信息）表示在其上執行的行為的對象。這些通常是業務層的信息對象和應用層的數據對象，但它們也可以用來表示物理對象。?

圖層

高層使用低層提供的服務。業務層向外部客戶提供產品和服務，這些產品和服務由業務參與者執行的業務流程實現。應用層通過（軟件）應用實現的應用服務支持業務層。技術層提供運行應用程序所需的基礎設施服務（例如處理、存儲和通信服務），由計算機和通信硬件和系統軟件實現。?

ArchiMate完整框架

完整的 ArchiMate 語言為核心框架添加了多個層和一個方面。物理元素被添加到技術層，用于對物理設施和設備、分配網絡和材料進行建模。此外，還添加了一個額外的動機方面以及實現和遷移元素?

21.1.3?圖表指導原則?

21.2 演示

?

22、使團隊高效

22.1 團隊邊界

22.2 架構師個性

?

22.3 檢查清單

22.4 提供指導

?

23、談判和領導技能?

23.1 談判

與業務利益相關者談判

• 利用語法和流行語更好地了解情況?
• 在開始談判之前，收集盡可能多的信息
• 當所有其他方法都失敗時，按照成本和時間來陳述
• 利用“分而治之”規則來限定需求

與其他架構師談判

• 永遠記住，演示戰勝了討論
• 避免在談判中過于爭辯或過于私人化。冷靜的領導加上清晰簡潔的推理，總能贏得談判

與開發人員談判

• 當說服開發人員采用架構決策或執行特定任務時，請提供理由，而不是“從高層指揮”
• 如果開發人員不同意某個決定，讓他們自己得出解決方案?

23.2 領導

?

架構中的4C

與開發團隊整合：

• 請提前詢問會議議程，以幫助確定你是否需要參加會議?

24、發展職業道路

?24.1 20分鐘規則

早晨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学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。