简介

软件架构是一个很容易理解的概念，大部分工程师即使仅拥有少量的经验，都能够凭直观感觉理解。但是，它却很难被精确的定义。特别是，很难在设计和架构之间划定清晰的分界线——架构是设计的一个方面，集中于某些特定的特性。

在《An Introduction to Software Architecture》中，David Garlan和Mary Shaw建议，软件架构是设计的某个层面，它关注于：“在计算的算法和数据机构之外；设计和特定的整体系统结构暴露出一种新型的问题。结构性问题包括整体组织和全局控制结构；通讯协议，同步以及数据存取；为设计元素分配功能；物理分布；设计元素组合；可扩展性和性能；以及设计方案的选择。”[GAR93]

但是架构比结构包含的更多；IEEE架构工作组将架构定义为“系统在其环境中的最高级别的概念”[IEP1471]。它还包含了“匹配”系统的完整性，与经济的约束，美学问题，以及风格。它不仅限于一个向内的焦点，还将系统在其用户环境和开发环境中作为一个整体来考虑——向外的焦点。

架构聚焦于整个系统设计中的特定方面，专注于结构、基本要素、关键场景和那些对系统品质产生持久影响的方面，如性能、可靠性、适应性和成本。它还定义了一组架构机制、模式和风格，这些将指导剩余的设计，保证其完整性。

架构用途

架构可用于许多方面：

• 描述系统的基本结构以及指导系统结构的决策，从而保证系统的完整性和可理解性。
• 识别并降低系统风险（通过把架构当做管理中的工件）
• 为开发者提供上下文和指南。通过描述架构决策背后的动机，为开发者构造系统提供上下文和指南，从而使这些决策能够被坚定的执行。架构作为蓝图为开发提供服务。例如，架构可以为数据如何被打包及其如何在系统不同部件中通讯指明约束。这看起来像是一种负担，但是在架构备忘录中的理由可以对其给出解释：在和遗留系统通信时存在显著的瓶颈。系统的其余部分必须遵循这种特定的数据打包样式来适应这个瓶颈。
• 为那些必须维护系统的人们，提供系统的概述，以及对重要技术决策背后动机的理解。没有参与架构决策的团队成员需要理解架构上下文背后的原因，这样他们能够更好的处理系统需要。
• 定义项目结构和团队组织。架构元素是优秀的实现、单元测试、集成、配置管理和文档的单元。它们也可被管理者用于计划项目。

架构描述

为了讲述和讨论软件架构，首先必须定义架构的表示方式，描述架构的重要方面。

以下是一些值得捕获的组成软件架构的信息：

• 架构目标 (参见 Concept：架构目标)
• 引用关键架构需求以及架构如何处理这些需求，包括描述系统重要行为的关键场景 (参见 Concept：架构关键需求)
• 架构约束以及架构如何解决这些约束 (参见 Concept：架构约束)
• 关键抽象 (参见 Concept：Key Abstractions)
• 架构机制 及其在何处应用 (参见 Concept：架构机制).
• 描述划分分区的方法，并描述关键部件。例如，分层 (参见 Guideline：Layering)     
• 描述部署的方法，以及关键组件如何被分配到部署节点。
• 引用架构关键设计元素 (参见 Concept：Component) 
• 重要系统接口 (参见 Guideline：Representing Interfaces to External Systems)
• 重用的资产以及开发后能够重用的资产 (更多信息，参见 Guideline：Software Reuse)
• 开发者在构建系统时必须遵循的指导、决策、约束及其说明。

架构可以包含任何适合于同开发人员沟通应当如何构建系统的信息和引用。

架构表示方式

架构可以有多种形式的表示方法和多个视点，这取决于项目的需要和项目团队的偏好。它并不需要一个正式的文档。架构的本质通常可以通过一系列绘制于白板上的简单图表来沟通；或者是一份决策的清单。架构的说明只需要展示建议的解决方案的本质，传递管理思想，以及主要的构建块，以便更容易的和项目团队及涉众沟通架构。

如果需要更复杂的系统，那么可以从更多的视点来描述一组更全面的视图来表达架构。更多信息，参见 Concept：架构视图与视点.

可以通过简单的隐喻或者通过和预定义的架构风格进行比较来表达架构。这也许是一组描述了系统关键要素各个方面的精确的模型或文档。将其表示为骨架实现是另一种选择-虽然这可能需要进行基线并保证对系统本质的理解随着系统的增长而增长。为项目选择最符合项目需要的媒介来表达架构。

架构模式

架构模式是解决重复出现的架构问题的现成形式。架构框架或架构基础设施（中间件）是可用于构建特定类型架构的一系列组件。许多重要的架构难题应当在框架或基础设施中予以解决，这些难题通常面向特定的领域：命令和控制、管理信息系统、控制系统等。

[BUS96] 根据架构模式的使用范围进行了分类，通过分类处理更一般的结构性问题。下表显示了这些分类及其包含的模式。

参考 [BUS96] ，获取这些模式的完整信息。

架构风格

一个软件架构（或架构视图）可能拥有称为架构风格的属性，风格减少了可供选择的形式，并强制架构拥有一定程度的一致性。风格可以通过一系列模式，或者选择特定的组件或连接器做为基础构建块来进行定义。

架构时机

团队应该期望在项目早期对架构问题花费更多的时间。这将使团队在项目早期减少相关的技术风险，并将使团队更快的减小他们对何时能够交付的估算偏差。以下是需要在早期解决的架构问题示例：

• 组件及其关键接口
• 重要技术选择（平台、语言、架构框架/参考架构等）
• 与外部系统的接口
• 通用服务（持久存储机制、日志机制、垃圾收集等）
• 关键模式 

架构验证

验证架构的最佳方式就是去实现它。进一步信息，参见 Executable Architecture。