软件架构实践——阅读笔记2

通过对这本书之前的阅读，已经对作者所理解的架构的定义有了一定的认识，下面学习“如何创建架构”。

质量属性是要在架构中得到体现的。在构架商业周期部分，已经学习到商业目的决定了系统构架必须满足的一些质量属性。这些质量属性是高于对系统功能（即对系统能力、服务和行为）的基本要求的。因为功能性和质量属性之间是正交关系，功能性指系统能够完成所期望的工作的能力）所以功能选择将会规定安全性、性能、可用性或易用性的级别。而对于每个质量属性，都可以独立地选择所期望的级别，但是并不是说可以用任何功能实现任何质量属性的所有级别。因为处理复杂的图形图像或对巨大的数据库进行排序在本质上都是非常复杂的，所以不可能会有非常快速的性能。但却可以做到对所选择的任何功能，设计师都将确定每个质量属性的相对级别。在大量可能的结构中，可以通过使用任意一个结构来实现功能性。但是在实际上，如果功能性是系统的唯一需求的话，整个系统就可以是一个根本没有内部结构的单一模块。相反，系统被分解成多个模块，以使其变得可理解，并支持各种其他目的。所以，功能性在很大程度上是独立于结构的。当其他质量属性很重要时，软件构架会限制各结构的功能分配。

没有任何一个质量属性是完全依赖于设计的，它也不完全依赖于实现或部署。满意的结果就是使总体蓝图（构架）以及细节（实现）正确。易用性涉及构架和非构架两个方面。例如，非构架方面包括使用户界面清晰、易用。但是设计细节方面的问题，都是不需要再构架层次上解决的问题。然而，系统是否能为用户提供取消操作、撤销操作或重用以前的数据的能力则属于构架方面的问题。可修改性由划分功能的方式和模块中的编码技巧（非构架方面的）决定。系统性能则是一个既依赖于构架又不完全依赖于构架的质量属性。

所以，在构架设计过程中应考虑到这些质量属性，并在构架层次上进行相应的评估。而对我们所关心的许多质量属性的实现而言，构架有着非常重要的意义。构架提供了实现质量属性的基础，单也必须要关注细节实现，所以构架并不能独自实现质量属性。使一个设计具有可移植性，一个设计具有高性能，一个设计具备可集成性，实现这些质量属性的关键都在于基本的设计决策。我们将这些设计决策称为“战术”，即影响质量属性响应控制的设计决策。我们又把战术的集合称为“构架策略”。而系统设计由决策集合组成，在这些决策中，一些可以帮助控制质量属性响应，而另外一些可以确保系统功能的实现。对于设计师来说，每个战术都是一个设计的选择，所以设计师在实践中所使用的的战术，对于我们来说是需要去学习和借鉴的重要内容。

架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求（质量属性）寻找适当的“战术”。软件属性包括功能属性和质量属性，但是，软件架构（及软件架构设计师）重点关注的是质量属性。因为，在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着决策（对结构的选择），而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。