摘要: 本文为Rest论文的第一章节软件架构学习总结，该章从Rest论文的背景出发，先引入了一些软件架构的概念术语，然后定义了一套自洽的软件架构术语，文中出现的很多人(Perry、Wolf、Shaw、Garlan)都是最早从事软件体系结构研究的
正文:
软件架构
一个系统的软件体系结构是由组件(构件)集合、组件(构件)之间的交互、连接器以及互相结合的约束限制和描述来组成的。服务器、数据库、某层次架构的层等都算是所属架构的组件实例
抽象原则(核心)
通过封装隐藏内部源码实现的细节，架构的设计与源代码结构的设计关系应该是相互分离的
架构元素(Elements)
作者将软件架构定义为一些架构元素(组件、连接器和数据)的配置，这些元素之间的关系受到约束，以获得所期待的一组架构属性。
作者认为软件架构不应该包括基础原理这块，虽然基础原理可以影响到一个架构的开发，但是一个架构一旦建成，它将脱离其所基于的基本原理而独立存在。就好像一个大楼建成后蓝图和计划被烧毁了但是楼并不会倒塌。
组件(Components)
组件在Perry和Wolf的定义中属于处理元素，也即是执行数据转换的元素，Garlan和Shaw将组件简单描述为执行计算的元素，作者试图更加精确的将组件和连接器区分开来：组件是软件指令和内部状态的抽象单元，通过其接口提供数据的转换能力(包括数据的计算、转换、封装等)
组件的定义应该由其提供的接口和服务来定义而不是隐藏在该接口之后的实现来定义
连接器(Connectors)
连接器在Perry和Wolf定位中属于连接元素，也即是将架构的不同部分结合在一起的粘合剂
**example:**远程过程调用、消息传递协议、数据流
通过例子可以看出来其连接器其实是来支持组件之间的通信，其内部可能也是通过组件对数据的转换、移交、反转换来达到通信的目的，然而从架构层面可以忽略这些细节
数据(Data)
数据是组件通过连接器接收或发送的信息元素
在对架构做评估时候，一定要去考虑数据元素，一种是直接与组件进行交互，第二种是将组件转化为一个数据元素通过网络进行传输，然后进行反转换得到一个能够在本地与之交互的组件
配置(Configurations)
配置是在系统运行期间的组件、连接器和数据之间的架构关系的结构
Abowd等人将架构的描述定义为：组件可以定义为计算的所在地，连接器定义为组件之间的交互，配置定义为相互交互的组件和连接器的集合
架构属性(Properties)
架构属性比较抽象，举个例子：组件的可重用率、效率、扩展性等非功能属性和具体的功能属性都属于架构属性
架构设计的目标是创建了一个包含一组架构属性的架构，不同架构属性的相对重要性取决于所期待的系统的本身特性
架构风格(Styles)
架构风格是一种机制，用来对架构进行分类并且定义它们的公共特征，并约束了架构元素的角色和功能以及元素之间的关系
”风格“常用于描述个性化，使用风格来描述架构约束常常令人迷惑，Loerke将风格描述为挑剔者对过去架构的观点，Loerke认为在传统的建筑架构设计中风格的真正来源是一组应用于设计之上的约束，达到或复制一种特定的风格应该是设计者的最低目标。这样将架构设计的约束称为一种更为抽象的风格表达变的更加容易。可以认为一种架构风格是一组相互协作的架构约束，给它取了个名字罢了
Perry和Wolf认为一种架构风格封装了关于架构元素(组件、连接器、数据)的重要决策，强调元素之间关系的约束
Garlan和Shaw认为一种架构风格决定了在此架构风格的架构中能够使用哪些组件和连接器
作者认为他们对架构风格的定义比较狭隘，原因是他们将架构看作是形式化的描述，而不是正在运行的系统
虽然一些架构风格常常被描述为适合所有软件的”银弹”式解决方案，但是一个好的设计者应该去选择最为匹配的架构风格。选择一个正确的架构风格需要去理解应用的领域，通信的需求，预测每种交互风格对基于网络通信的特性的敏感度
模式与模式语言(Patterns and Pattern Lang)
在Java这种OOP编程语言领域，一种设计模式被定义为一种重要的和重复出现的系统构造，而一种模式语言是一个模式的系统
模式的设计空间包括了如java的类继承和接口组合或者更高层次的设计，这个设计空间应该是在架构风格(约束)之下，促使系统出现所期待的架构属性
视图(Views)
架构视图常常特定于应用，并且基于应用而千变万化，而视图的种类更是多种多样
Perry和Wolf描述了三种重要的软件架构视图：
处理视图
侧重于流经组件的数据流
数据视图
侧重于处理的流程，而不是连接器
连接视图
侧重于组件之间的关系和通信状态
