架构基础

常常嘴上挂这个架构，还喋喋不休。静下心来，想想到底什么是架构？等的基础问题，有时真能把自己问晕。
今天在查rest资料的时候，看到一篇文章，觉得写得不错。

一个软件架构是一个软件系统在其某个阶段运行时（run-time）所有元素的抽
象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都
有自己的软件架构。

软件架构的核心是抽象原则：通过封装来隐藏系统的一些细节，从而更好地识别和支持系统的属性

现代软件架构的核心是：组件、连接器、数据。组件是在运行时执行某种功能的软件单元。这样的例子有程序、对象、进程、过滤器。
软件架构（software architecture）是软件系统在运行时的抽象，而软件结构（software structure）则是静态源代码的属性.将软件架构和源代码结构分离开来是为了更好的关注软件运行时的特性，这些特性不依赖于一个特定的组件实现.

设计文档是运行时系统的一部分?系统运行起来后，设计文档在软件架构中不扮演任何角色。大楼的图纸烧毁了，但是大楼还在。

对于基于网络的应用而言，数据元素在系统中的位置和移动常常是系统行为唯一至
关重要的决定因素.

组件

一个组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转
换。软件组件就是拥有接口、其接口形式对外表现或者展示的一个具有一定独立功能的软件单元。软件组件必须拥有接口，否则不能成为组件，或者这样的组件是没有任何用处的。



组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。转换的例子包括从二级存储将数据加载到内存、执行一些运算、转换为另外一种格式、使用其他数据来封装等等。每个组件的行为是架构的一部分，能够被其他组件观察到（observed）或看到（discerned）换句话说，组件应该由它为其他组件提供的接口和服务来定义，而不第1章软件架构12由它在接口之后的实现来定义。Parnas 将此定义为其他架构元素能够对该组件作出的一组假设。



连接器



一个连接器是对于组件之间的通讯、协调或者合作进行仲裁的一种抽象机制。

连接器的例子包括共享的表述、远程过程调用、消息传递协议和数据流。

连接器通过将数据元素从它的一个接口转移（transferring）到另一个接口而不改变数据，来支持组件之间的通信。在其内部，一个连接器可以包含一个由组件组成的子系统，为了转移的目的对数据进行某种转换、执行转移、然后做相反的转换并交付与原始数据相同的结果。



传输数据应该是链接器最重要的任务。包括客户有意义的实体数据、组件交互的交互协议数据。对于数据传输方向的选择和目的数据方向的不同，连接器可以对接受的数据进行不同的转换。这个转换应该由连接器内部的组件来完成。



数据



数据是组件通过一个连接器接收或发送的信息元素。数据的例子包括字节序列、消息、编码过的参数、以及序列化过的对象，但是不包括那些永久驻留或隐藏在组件中的信息。

在软件架构中，数据其实是一种流动的消息。在基于网络结构的设计中，数据是最重要的概念。你要选择两种模式：是在远程直接连接组件进行交互，还是将组件传递到本地在本地空间中进行交互。

架构属性
架构属性的例子包括了可以由系统获得的功能属性和非功能属性，例如：进化的相对容易程度、组件的可重用性、效率、动态扩展能力；这些常常被称作品质属性（quality attributes]）

属性是由架构中的一组约束所导致的.架构设计的目标是创建一个包含一组架构属性的架构，这些架构属性形成了系统需求的一个超集。不同架构属性的相对重要性取决于想要得到的系统本身的特性。

架构风格
一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，
以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。

风格是一种用来对架构进行分类和定义它们的公共特征的机制。每一种风格都为组件的交互提供了一种抽象，并且通过忽略架构中其余部分的偶然性细节，来捕获一种交互模式（pattern of interation）的本质特征

明确地说，一种架构风格决定了在此风格的实例中能够使用的组件和连接器的词汇表，以及一组如何能够将它们组合在一起的约束。一种特定的架构可能是由多种架构风格组成的。同样地，能够通过将多种基本风格组合为单个的协作风格来形成一种混合风格。

一些架构风格常常被描述为适合于所有形式的软件的“银弹”式解决方案。然而，一个好的设计师应该选择一种与正在解决的特定问题最为匹配的风格。

为一个基于网络的应用选择正确的架构风格必须要理解该问题领域，因此需要了解应用的通信需求，知道不同的架构风格和它们所导致的特殊问题，并且有能力根据基于网络的通信的特性来预测每种交互风格的敏感度。

在传统的建筑架构中，风格的真正来源是一组应用在设计上的约束，达到或复制一种特定的风格应该是设计者的最低的目标。由于将一组已命名的约束称作一种风格，使得对公共约束的特征进行沟通变得更加容易，我们将架构风格用作一种进行抽象的方法，而不是代表一种个性化的设计。

模式和模式语言

模式是关于一种重要的和重复出现的系统构造.一种模式或由多种模式集成在一起的模式语言能够被看作是实现对象之间的一组预期交互的方法。换句话说，一种模式通过遵循一种固定的设计和实现选择（implementation choices）路径，定义了一个解决问题的过程。

模式包含了一种通用并且重复出现的应用的实现的细节。

Alexander还理解到：事件的模式不能脱离于发生这些事件的空间。Alexander的设计哲学是，识别出目标文化（target culture）中公共的生活模式（pattern of life），确定哪些架构约束对于以下目的是必需的，即，对可以使期望的模式自然地产生的特定空间加以区分。这些模式存在于多个层次的抽象和所有的规模中。



一种架构风格，作为一组协作的约束，应用于一个设计空间，以求促使一个系统出现所期望的架构属性。通过应用一种风格，一个架构师是在区分不同的软件设计空间，希望结果更好地匹配应用中所固有的一些必需满足的先决条件.


软件设计模式比架构风格更加倾向于面向特定的问题.模式倾向于是架构风格中的建造块（Building block）.



一种架构描述语言（ADL)是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言，至少包括以下部分：组件、组件接口、连接器、以及架构配置。

转自：http://blog.sina.com.cn/s/blog_4671e657010009uh.html