《实用软件体系结构》学习笔记

本书的目标是向软件架构师提供实用的指南和技术，以更快地得到好的系统结构设计。我们的哲学是不应该致力于设计理想化的系统结构，而是应该仔细地评估和权衡所有技术、市场、人员、成本方面的问题，从而获取一个好的解决方案。

一、软件体系结构术语

系统结构风格或者系统结构模式

参考系统结构或者领域特定的软件系统结构（应用在一个特定领域）

产品线系统结构（应用在一个组织的一组产品）

软件系统结构（应用在软件系统或者产品）

二、4种视图

1、一个软件体系结构有4种截然不同的视图：概念视图、模块视图、执行视图、代码视图。

使用这个4种视图提供了一种设计软件系统结构的系统化方法，帮助架构师设置优先级，分析权衡，并保证没有缺漏。

2、不同视图强调的不同工程关注点：

在概念视图中，问题和解决方案主要通过领域术语来考虑的。对于特定的软件及硬件技术，它们应当是相对独立的。概念视图的工厂关注点包括：

系统如何满足需求？

商用构件怎样组装成整体，怎样在功能层上与系统的其他部分交互？

领域特定的硬件和软件如何融入系统？

功能是如何被分割并进入产品个版本的？

系统如何与之前版本的产品合并？它如何支持未来的版本？

如何支持产品线？

如何将由需求或领域中所做的变动引起的影响最小化？

在模块视图中，概念视图中的构件和连接子被映射为子系统和模块。在这里，架构师强调的是如何用现有的软件平台以及技术实现概念的解决方案。主要的工程关注点有如下几点：

产品是如何映射到软件平台的？

使用了什么样的系统支持或系统服务？具体是在什么地方？

怎么支持测试？

如何降低模块间的依赖性？

如何将模块与子系统的复用最大化？

当商用软件、软件平台或标准发生变动时，采用何种技术在封装产品时可以将它们与产品进行隔离？

执行视图描述模块如何映射到运行时平台说提供的元素，以及这些又如何映射到硬件体系结构。执行视图定义系统的执行时实体及其属性，比如内存使用和硬件分配。对于执行视图，其工程关注点如下：

系统如何满足性能、恢复及重新配置方面的需求？

如何平衡资源的使用（例如：负载平衡）？

如何达到必需的并发、复制及分布，而不过度增加控制算法的复杂度？

如何使运行时平台的改变所引起的影响到达最小？

在代码体系结构视图中，架构师决定执行视图中的执行时实体如何映射到部署构件（例如：可执行构件），决定模块视图中的模块如何映射到源构件，以及部署构件如何从源构件生成。代码视图中重要的工程关注点如下：

如何降低产品升级的时间和费用？

如何管理产品版本及发布？

如何降低构造时间？

需要什么工具支持开发环境？

如何支持集成与测试？

三、全局分析

全局分析是在定义概念、模块、执行和代码系统结构视图之前进行的，并贯穿整个系统结构的设计过程。

全局分析从识别影响体系结构设计的因素来分成3类：组织因素、技术因素、产品因素。

组织因素分成5类：管理；员工技能、兴趣、能力、缺点；过程与开发运行环境；开发进度；开发预算。

技术因素包括：通用和专用的硬件；操作系统、用户界面、设计模式等软件技术；模版和框架等体系结构技术；图像、数据库、数据格式、算法和技术之类的标准。

产品因素是描述了产品的功能需求、用户可见的特征和产品的性能等质量方面的需求。比如：功能特征；用户界面；性能；依赖性；错误监测、报告、修复；服务和价格等。

全局分析是在每一种体系结构设计视图中都要进行的一种行为。在全局分析过程中建立的问题卡片要用在每一个视图设计的核心设计任务中。在进行核心设计任务时，做出的决策应当可以返回到全局分析，以增加和修改因素、问题和策略。

总结策略：

问题	应用策略
进度紧迫	复用内部已有的、领域特性构件 购买而不是建立 使元素容易添加和删除
技能不足	避免使用多线程 封装多进程
通用和领域特定硬件的改变	封装领域特定硬件 封装通用硬件
软件技术的改变	使用标准 为外部构件开发产品特定的接口
资源有限	限制活动线程个数 用动态的内部线程见通信联系
易用增加和删除特性	按关联尺度分离构件和模块 特性封装到分开的构件 分离用户交互模块
易用增加和删除采集过程和算法	为图像处理使用灵活的流水线模块 为采集和图像处理引入构件 分离用户交互模块
高吞吐量	把独立的控制线程映射到进程 使用新增的CPU
实时采集性能	从没有临界时间构件中分离出有临界时间的 为模块行为开发准则 灵活的分配模块到进程 使用单速分析来预言性能 使用共享存储进行流水线阶段之间通信
实现恢复	引入操作的恢复模块 把全部数据放到恢复稳定和容易达到的地方
实现诊断	制定一个错误处理策略 减少错误处理的工作 封装诊断构件 使用标准日志服务
体系结构的完整性	保护模块间的继承 分离公共接口构件
并发的开发工作	从源构件中分离开发构件 保护执行视图 采用阶段开发 通过静态库来发布层
限制可使用的采集图像类型	采用适当的抽象开发一个脱机的探测模拟器 使用一个灵活的建立过程
多样性开发和目标平台	分离和封装依赖目标平台的代码

四、概念体系结构视图

清楚了概念体系结构的结构视图之后，可以推论或预测重要的系统属性。概念视图可以用于：

实用环境及场景。

性能评估。

安全性及可靠性分析。

独立于监测的目标。

理解静态及动态系统配置。

工作量评估（初步；不包括基础设施）。

五、模块体系结构视图

明确了一个模块视图，就开始了对重要系统属性的关注。对模块视图的描述，有以下用途：

管理模块接口。

变化影响分析。

接口约束的一致性检查。

管理配置。

评估成果。

模块体系设计活动

子系统包含0和多个子系统、0和多个模块；模块之间的关系是通过接口来实现的。模块也存在包含关系、使用关系。

六、执行体系结构视图

多个运行时实体；运行时实体依赖于模块；资源平台依赖于硬件资源。

通信机制包括DCOM（分布式构件对象模型）、IPC（进程通信）、RPC（远程过程调用）等。

资源包括地址空间、内存池、定时器、代理、端口等。

执行视图通常由下面人员使用：

架构师，设计系统运行时间的特性，以使得设计符合需求，并能够适应期望的改变。

开发人员，提供正确的实现。

测试人员，他们需要知道系统的运行时间的特性并计划进行测试。

维护人员，决定运行时间平台的改变如何影响系统，或者需求的改变如何影响系统的运行时间特性。

七、代码体系结构视图

代码体系结构视图的应用：

一旦代码体系结构视图被明确地描述出来，它就可以有许多不同的用途：

对于模块视图和执行视图中的元素的可追踪性。

对于特定开发任务所需要的所有构件的透明访问。

构造部分系统。

管理构件的版本和发布。

保持体系结构的设计决策，及时发现违反决策的情况。

代码体系设计活动：

代码组由源代码构件、二进制构件、库、执行（运行时实体）、配置描述等组成。

源代码构件依赖于模块和接口。

代码组依赖于子系统和分层。

八、软件体系架构模式

软件设计的一个核心问题是能否使用重复的体系架构，即能否达到体系架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系架构。基于这个目的，许多学者们开始研究和实践软件体系架构的模式问题。在＜Pattern-Oriented Software Architecture (面向模式的软件体系架构) ＞中首次提出了8种体系结构模式： 层（Layers）、管道和过滤器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。