今天，我阅读了《软件构架实践》10-12章。
第10章主要讲了软件构架重构，架构重构是一种解释、交互和迭代的过程，涉及许多活动；它并不是自动进行的。它需要反向工程专家和设计师具有相关技能并投入精力（或具备该构架的重要知识的某个人），这在很大程度上是因为在源代码中没有清楚的表示该构架构件。对于层、连接器或可以轻松从源代码文件中挑选出来的构架元素，并没有编程语言构件。很少标记构架模式。相反，我们通过实现中的许多不同的机制实现构架构件，通常是功能、类、文件、对象等集合。
读完这一章，我知道了构架是无形的，我们经常会丢失或在系统的生命周期内发生变化。因此，我们需要采用某些技巧从早期系统中恢复或提取构架。构架和源代码级系统制品之间的映射是复杂的，这使得构架重构称为了一个复杂的过程，使了解该系统的人参与重构过程可以带来很大的好处。
第11章主要介绍了一种构架权衡的分析方法—ATAM，它是评估软件构架系统的一种综合全面的方法。它可以使我们更清楚的认识到质量目标之间的联系—即如何权衡诸多质量目标。AtAM是评估软件的一种健壮的方法。在该方法中，项目决策者和涉众要清晰的阐述一个准确的质量属性需求列表，并说明与实现每个高优先级场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架存在问题的地方。
ATAM不是需求评估。也就是说，基于ATAM的评估不会说明是否系统的所有需求都得到了满足。它只会告诉您在给定的当前设计下是否满足了系统需求；ATAM不是代码评估。因为它是在生命期的早期进行的，因此它没有假定代码已经存在，也不进行代码审查；ATAM不包括实际的系统测试。同样是因为ATAM实在生命期的早期进行的，因此它没有假定的系统存在，也不进行任何类型的实际测试；ATAM不是一种准确的手段，但它识别了构架可能存在的风险和可能存在风险的区域。
第12章介绍了一种成本收益分析方法—CBAM，ATAM揭露了在系统中制定的构架决策，并将它们与商业目标和质量属性响应度量联系起来。CBAM通过获取与这些决策相关的成本和收益，在此基础上进行。给出CBAM评估后的结果后，涉众就可以决定是否使用冗余的硬件、检查点或其他战术来实现系统所希望的可用性。他们可能会选择把有限的资源用在实现其他质量属性上—大概是因为他们相信更高的性能将会实现更好的收益成本比。对于系统创建或升级来说，预算总是有限的，因此从某种意义上来说，我们比较了各个构架的成本收益后来选择构架。
CBAM是一种迭代式的获取过程，它与决策分析框架结合在一起。它采用场景来表示各种质量属性。涉众通过获取效用—响应曲线来理解系统的效用如何随着质量属性的变化而变化，从而对决策进行分析。在达成一致的基础上，该方法允许涉众进行讨论，以在涉众之间进行澄清。设计决策的可跟踪性允许设计过程随着时间的推移而不断得到更新和改进。