软件架构是什么

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。

软件架构是在软件的基础架构上进行决策，一但决定后，再修改的代价很大。软件架构中的决策包括在软件设计时的一些特殊结构性选项，例如要控制太空船登陆艇的系统需要快速而且可靠,因此需要选择适合实时计算的语言，而且为了满足可靠度的需求，程序需要有数个冗余的复本，各复本运作在不同的硬件上，以便比对各程序的结果。

将软件架构文档化有助于和项目关系人之间的沟通，在高层设计时就可以提早进行决策，也可以在各项目之间复用设计组件。

介绍

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，软件架构师或者系统架构师陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序员商谈实现技巧，外观和风格。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

范围

软件架构的范围有许多不同的定义：

• 巨观系统架构：这是指高端的软件系统抽象化，其中包括了许多的组件（component），以及描述各模块之间关系的“连接器”（connector）。
• 重要的东西，无论是什么都可以：这是指软件架构师需要根据项目判断，哪些决策对系统以及项目关系人有高度影响。
• 了解系统环境的基础。
• 一些人们认为不容易改变的事务：设计架构是在软件生命周期一开始就要进行的，软件架构师需专注在一些“一开始就要正确”的决策，依照这个思路，若有些问题是可逆的，软件架构上的问题就可以转换为非架构性的问题。
• 许多的架构设计决策：软件架构不能只考虑许多的模型及结构，也要考虑造成这些特殊结构的决策，以及背后的原因。此见解引发了大量有关软件架构知识管理的研究。

在软件架构、设计、需求工程之间，没有具体明显的分界。这些是“一连串意图的结合”，从高端的设计意向到低端的设计细节。

特点

软件架构有以下这些特点：

众多的关系人：软件架构需配合许多的关系人（stakeholder），例如业务经理、部门主管、用户及运营商。每一个关系人都有各自关注的内容。在设计系统中，如何平衡这些关注，并展示他们所关注的消息，也是一个重点。因此，软件架构中就包括了处理众多的关注及关系人，因此在本质上就是跨领域的。

关注点分离：架构师降低复杂度的可行方式，就是将驱动设计的各关注分开。架构文件会呈现相关者关注的所有内容，会以建构的方式表示，另外也会用各相关者关注的角度来描述软件的架构。这种分开来的说明称为架构视图，例如 4+1 架构视图。

质量导向：传统的软件设计方法（例如杰克逊结构化编程）是依需求的机能以及资料在系统中流动的方式所驱动，不过目前的见解是软件系统的架构和其质量属性（例如故障容许度、向下兼容、可扩展性、可靠度、可维护性、可用性、资料安全等）的关系更高。相关者的关注可以转换为有关这些质量属性上的需求，一般会称为非功能性需求、额外功能性需求、行为需求或质量属性需求。

重复的风格：软件架构和建筑类似，在处理一些重复出现的事务时会发展出标准化的作法。标准化作法有许多不同的名称，其中也有不同程度的抽象化。常见的术语有架构风格、tactic、参考架构及架构模式。

概念完整性：这是佛瑞德·布鲁克斯在写作《人月神话》一书时提及软件系统的架构是有关软件系统该作什么以及不该作什么的实体观点。这些观点应和软件的实现分开。架构师的角色是“观点的看守者”，确认系统中增加的部分是符合此架构，因此可以保有概念完整性。

认知制约：程序员马尔文·康威在 1967 年论文发表了康威定律，其中提到一个组织开发的软件，其架构会反映其组织架构。佛瑞德·布鲁克斯在写作《人月神话》一书时，就在书上时提到此例子，命名为“康威定律”。

动机

软件架构是复杂系统“在智力上能理解”（intellectually graspable）的抽象，此抽象有以下的好处：

• 软件架构是在系统实现之前，分析软件系统行为的基础。不需要实际实现系统，就可确认某一软件系统符合关系人的需求，这在降低成本以及风险减轻上都很有助益。已针对这类的分析开发了许多的技术，例如软件架构分析方法（SAAM）、架构权衡分析方法（ATAM），或是针对软件系统以可视化的方式来呈现。
• 软件架构是软件复用以及决策的基础。不论是软件的软件架构，或是在软件架构上的个别策略及决策，若关系人在其他系统中也需要类似的属性或是机能，就可以重复使用，因此可以减少设计成本，也减少设计错误产生的风险。
• 可以在提早就进行会影响系统开发、布署以及维护的设计决策。若要避免时程逾期或是费用超支，提早做出正确的，高影响性的决策非常重要。
• 有助于和关系人之间的沟通，可以产出一个比较符合各方需求的系统。在有关复杂系统的沟通时，以关系人的观点来沟通有助于他们了解其提出需求和以此产生的设计决策之间的关系。透过架构，可以在系统实现之前（也比较容易调整的时候）就进行设计决策的沟通。
• 有助于风险管理。软件架构可以减少风险以及失败的几率。
• 可以降低成本。软件架构是一种管理复杂 IT 计划风险以及成本的方式。