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 开发者角色

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语言的主要概念和关系可以看成一个框架。它将企业架构分为业务层、应用层和技术层

在每一层中，都考虑了三个方面：表现行为的活动元素，内部结构和定义使用或交流信息的元素。

方面

1. 所述活性结构方面表示结构的概念（即显示实际行为的业务演员，应用程序组件，和设备，即，活动的“主题”）。
2. 所述行为方面表示由演员执行的行为（进程，函数，事件和服务）。行为概念被分配给结构概念，以显示谁或什么显示了行为。
3. 所述被动结构方面（信息）表示在其上执行的行为的对象。这些通常是业务层的信息对象和应用层的数据对象，但它们也可以用来表示物理对象。 

图层

高层使用低层提供的服务。业务层向外部客户提供产品和服务，这些产品和服务由业务参与者执行的业务流程实现。应用层通过（软件）应用实现的应用服务支持业务层。技术层提供运行应用程序所需的基础设施服务（例如处理、存储和通信服务），由计算机和通信硬件和系统软件实现。 

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