软件架构基本概念

       软件架构，也叫软件体系结构，这两种叫法都是从Architecture这个词翻译而来，是软件工程研究的一个分支，由于软件工程较传统工业来说是一个较为年轻的行业，而且发展势头非常迅猛，所以架构也一直处于前行摸索阶段，但是笔者发现传统的架构知识或者理论很难被应用并且现在谈起架构可能更多的偏向于某种技术的应用，另外还有一个现象就是有些公司有架构师的岗位，却不知道架构师的明确职责与任务，甚至有些企业会怀疑架构师的价值，那么架构到底是怎么回事？架构师又该是什么样的？其实，我也说不好，毕竟一个科学的的行业或者技术研究分支不是某个人能随随便便下定义的，那么要想明白这些，找出原因只能是通过静下心来好好去了解去学习架构的历史，出现背景以及各家定义。

     现在架构在软件行业有广泛的应用，但是关于软件架构却没有明确公认的定义，各专家组织等都给出了关于软件架构的定义。但总体的思想来说就是把架构理解为构件的组合或者对一系列决策的处理安排。此篇简单的先给出决策派关于软件架构的几个关键定义（参考书名：《Software Architecture: Foundations、Theory、and Practice》作者： R. N. Taylor、N. Medvidovic、E. M. Dashofy，此系列博文基本都参考此书翻译，穿插一些自己的理解与说明，由于本人水平有限，有翻译不准确或者错误的地方希望大家多多包涵或者指正），以此为框架，逐步展开学习软件架构的相关知识，。

   软件架构（software architecture）：是对系统作出的一系列重要决策的集合。

   设计决策：包含系统开发的各个方面。

        系统的结构：如系统的架构相关元素应该如何被组织。

        功能行为：如系统数据处理，存储，可视化应该按照严格的顺序进行。

        非功能属性：如系统的性能，可用性，可靠性等方面。

       系统具体的实现：如采用何种语言，哪个开发库等。

   软件参考架构（ reference architecture）：是可同时应用于多个相关系统的重要决策的集合，通常在一个应用领域中有明确定义的变化点。

   规范性架构（ prescriptive architecture）：在软件系统工程的任意时刻t，架构师针对架构设计做出的决策集P，这些决策反应了系统架构师的意图，所有的这些设计决策最终组成了系统的规范性架构。

   描述性架构（descriptive architecture ）：任意的决策P敲定精炼并实现的制品A，所有在A中主要的设计决策D的集合就构成了系统的描述性架构。[详细介绍]

   架构降级（architectural degradation）：系统规范性架构和规范性架构之间的差异导致的结局。[详细介绍]

 

   架构漂移（Architectural drift ）：架构降级的一种现象，指引入系统的描述性架构中的主要设计决策并未包含在系统的规范性架构中。[详细介绍]

   架构侵蚀（Architectural erosion）：架构降级的一种现象，指引入系统描述性架构中的主要设计决策和系统的规范性架构相违背。[详细介绍]

   架构透视（architectural perspective）：突出架构的一些方面，忽略架构的另一些东西，是一个架构设计决策的非空集。

   组件（component）：软件组件是一个架构的实体，(1)它封装了系统功能或者数据的子集，(2)通过明确定义的接口限制对子集的访问，(3)而且显式的定义了其所需的执行上下文的依赖。

   连接件（connector）：一种架构元素，其任务是影响和调节组件之间的交互。

   架构配置（configuration）：一个软件架构中组件和连接件特定关联的集合。[详细介绍]

 

   架构风格（ architectural style）：架构风格是一个命名的架构设计决策的集合，（1）适用于给定开发环境的上下文（2）约束特定于该上下文中特定系统的架构设计决策，（3）并在结果系统中表现出好的特性与品质。

 

   架构模式（architectural pattern ）：架构模式是一个已命名的架构设计决策，这些设计决策适用于反复出现的设计问题，参数化来考虑不同问题的上下文环境。[架构风格与架构模式]

  架构模型（architectural models）：用来捕获组成系统部分或者全部决策的制品，架构模型是那些设计决策的具体化和文档化。是建模活动的结果。

  架构建模符号：一种捕获设计决策的语言或方法。

  架构恢复（Architectural recovery）：是从实现工件中确定软件架构的过程。