软件架构概述

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

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

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

介绍

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

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

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

范围

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

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

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

特点

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

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

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

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

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

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

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

动机

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

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

历史

早在 1960 年代，诸如艾兹格·迪杰斯特拉就已经涉及软件架构这个概念了。自 1990 年代以来，部分由于在 Rational Software Corporation 和 Microsoft 内部的相关活动，软件架构这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的 Mary Shaw 和 David Garlan 于 1996 年写了一本叫做 Software Architecture perspective on an emerging discipline 的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

架构活动

开发软件架构的过程会和许多的活动有关。软件架构师一般会和项目经理一起工作，和项目关系人讨论架构重要需求、设计软件架构、评估设计、和设计师及项目关系人沟通、撰写架构设计的文件等[18]在软件架构设计中，有四个核心活动，分别是架构分析、架构合成、架构评估和架构演进[19]。这些核心的架构活动会反复的出现，也会出现在软件开发生命周期的初始阶段，及后续阶段。

架构分析（Architectural analysis）是了解计划的系统要运作的环境，以及决定系统的需求。分析活动的输入或是需求可以来自项目关系人，也可能会包括以下项目：

系统运作时，会进行的事务（机能需求）。
系统运作时会需要的非机能需求，例如 ISO/IEC 25010:2011 标准中定义的可靠度、可操作性、性能效率、安全性，和兼容性。
开发时间相关的非机能需求，例如 ISO 25010:2011 标准中定义的维护性及移转性。
业务需求以及系统中可能会随时间变化的环境背景，例如法令、社会、金融、竞争性及技术考量。
分析活动的产出是在软件系统架构上有相关影响的需求，这些称为是架构重要需求（architecturally significant requirements）。

架构合成（Architectural synthesis）或架构设计是指产生架构的过程。针对在架构分析时生的架构重要需求、设计的目前状态、及评估活动的结构，可以进行设计，也可以针对设计进行改善。

架构评估（Architecture evaluation）是在分析过程中确认现有设计整体（或其部分）满足各需求程度的程序。架构评估的时机可以在架构设计师进行设计决策中的时候，部分设计已完成时，细节设计完成后，或是系统已架设完成之后。有些分析软件架构的技术，例如架构权衡分析方法（ATAM）及 Tiny Architectural Review Approach（TARA）等。有些可以比较这些技术的框架，例如 SARA Report 及《架构评审：实务及经验》（Architecture Reviews: Practice and Experience）。

架构演进（Architecture evolution）是指维护已有的软件架构并且调整，以符合环境及需求变化的过程。软件架构提供软件系统的基本架构，其演进及维护必然会影响软件基础架构。因此，架构演进一方面关注的是加入新的功能，另一方面也要维护原有的机能以及系统行为。

架构支持活动

架构设计需要关键性的支持活动。这些支持活动也和核心的软件架构过程中一起出现。这些支持活动可以协助软件架构师进行分析、合成、评估及演进。例如软件架构师需要在分析阶段搜集信息、进行决策，并且撰写文件。这些活动包括知识管理、交流、设计推理、决策以及撰写文件。

知识管理及交流（Knowledge management and communication）是发现有关软件架构设计的重要知识，并且进行管理的活动。软件架构师不会独立作业，他们会从各项目关系人身上获取输入、机能需求及非机能需求、以及设计环境（design context），也产出信息给各项目关系人。软件架构信息是隐性的，保留在项目关系人的心里。软件架构管理活动和知识的发现、交流及保存有关。软件架构设计议题错综复杂，并且彼此相关性很强，在设计理解上的知识落差可能就会造成错误的软件架构设计
设计推理及决策（Design reasoning and decision making）是评估设计决策的活动。此活动是三个软件架构核心活动的基础[9][26]。其中包括了搜集决策环境以及创建关系性，制订设决策问题，查找对策选项，在决策之前在各对策之间取舍。在评估重要架构需求、软件架构决策、软件架构分析、合成及评估时，此过程会以不同的决策粒度反复出现。推理活动的例子包括了解质量属性需求或设计上的影响，针对设计可能产生的问题提问、评估可能的对策选项，以及各对策之间的取舍。
撰写文件（Documentation）是在软件架构过程中记录所得设计的活动。软件设计会用不同的视图来描述，其中经常包括展示系统程序结构的静态视图（static view）、展示系统在运行时行为的动态视图（dynamic view）、展示如何放在要运行硬件的布署视图（deployment view）时。Kruchten 的 4+1 架构视图有建议在针对软件架构创建文件时，常用的视图叙述。 Documenting Software Architectures: Views and Beyond 有说明在视图叙述时可以用的标示方式。撰写文件的例子有撰写规格、记录系统设计模型、记录设计理念、开发架构视角、记录视图等。

软件架构主题

软件架构描述

软件架构描述包括建模以及实现其架构的原理以及实务，其中会使用架构描述语言、架构视图及架构框架等。

架构描述语言

架构描述语言（ADL）用于描述软件的体系架构。现在已有多种架构描述语言，如 Wright（由卡内基梅隆大学开发），Acme（由卡内基梅隆大学开发），C2（由 UCI 开发），Darwin（由伦敦帝国学院开发）。ADL 的基本构成包括组件、连接器和配置。

架构视图

软件架构的叙述常会整理成视图模型（view model），如同在建筑学中的不同种类的蓝图。每一种视图会着重一些系统的事务，依循其约定的观点（viewpoint），观点是指为了要以特定关系人（stakeholder）及其关注点的角度说明系统架构，因此针对标示、模型、分析技巧的说明方式的规范（ISO/IEC 42010）。观点不但指定框架的关注点，也指定说明的方式、使用的模型、使用的习惯，以及可以和其他视图维持一致性的规则。

以下是一些可能的视图：

功能/逻辑视图
代码视图
开发/结构视图
并行/过程/线程视图
物理/部署视图
用户动作/反馈视图
目前已开发了许多描述软件架构的语言，但是大家对于要用何种的符号集和视图系统，还没有达成共识。一些人相信 UML 将创建软件架构视图的标准。

架构框架

架构框架（architecture framework）可以定义为“特定应用或/及特定群体在叙述架构时的习惯，原则以及实务”（ISO/IEC 42010）。框架一般会用一个或多个视图或 ADL 来表示。架构框架的例子有：MODAF、开放组体系结构框架、Kruchten 的 4+1 架构视图、RM-ODP 等。

架构模式

架构模式是针对在特定情境下软件架构上的常见问题，通用性，可复用的解决方案。架构模式也像设计模式一样有对应的文件。

架构模式的概念类似传统的建筑，软件架构风格是有关架构的特定作法，有各自的特征。

架构模式定义：“由许多结构性组织模式形成成的系统家族：其中许多组件以及链接方式的字汇，也有一些彼此组合上的限制。"
架构模式是在设计决策及制上上可复用的“包裹”，可以应用在一架构上，以产生想要的特性。

有许多知名的架构模式及风格，举例如下：

黑板
主从式架构（二层结构、三层结构、n-tier，云计算会有这类风格）
基于组件的软件工程
数据库中心
事件驱动（或隐式调用）
抽象化（或多层架构）
微服务
单层系统、单体式应用程序
MVC（Model–view–controller）
点对点网络（P2P）
管道
插件
表现层状态转换（REST）
规则为基础的系统
面向服务的体系结构
无共享架构
空间为基础的架构
单层系统
有些人将架构模式和架构风格视为是同一件事，有时则是将架构风格视为是架构模式的实例，不过将架构模式和架构风格都是架构师常用的语言，在描述系统类型时“提供共享的语言” 或“字汇”。

软件架构和敏捷开发

也有研究者认为软件架构造成太多的早期的大型设计，尤其敏捷开发的提倡者更是如此认为。有许多的方式设计要在早期设计以及敏捷之间作取舍，其中包括敏捷式的动态系统开发方式（DSDM），其中强制一个“基础”阶段，只要列出“够用的”架构基础即可。《IEEE 软件》曾特别探讨敏捷和软件架构之间的关系。

软件架构腐蚀

软件架构腐蚀（或退化）是指软件系统设计的架构以及实现时实际架构之间的落差[33]。软件架构腐蚀会出现在实现时的决策没有完成达到原先设计的架构，或是有一些违反架构原则或是限制的情形[2]。这种设计架构和实际架构之间的落差有时也会以技术负债的方式表示。

例如，考虑严格抽象化的系统，每一层都只能用往下一层所提供的服务。若代码组件无法遵守此一限制，就违反了架构。若此问题没有修正，此架构违反会让系统架构变成无法分层的架构，在程序理解性、可维护性和发展性都有不良影响。

针对软件架构腐蚀，有提出有许多的处理方法： “这些方法，包括工具、技术及流程，主要可以分为三大类，设法减小、预防及修复架构腐蚀。在这三大类以下，各方法都可以再细分，反映为了解决侵蚀而采取的高端策略。例如流程导向架构一致性、架构演进管理、架构设计强化、架构到实现的链接、包括恢复、发现以及调节的自适应及架构恢复技术。”

针对侦测架构违反，有二种主流的技术：反射模型（Reflexion model）和领域特定语言（domain-specific languages）。反射模型技术会比较系统架构师提供的高端模型，和代码的实现特定领域的语言。领域特定语言则是专注在标示及检查架构上的限制条件。

软件架构恢复

软件架构恢复（重建，或逆向工程）包括从已有信息（包括程序实现以及已有文件）中找到软件架构的方式以及技巧。若是遇到软件的文件过旧、架构腐蚀（软件的架构和后来的实现及维护不一致），又需要进行决策时，就需要进行软件架构恢复[35]。常见的技巧包括静态程序分析，软件架构恢复也是软件智能实务中的一部分。

介绍

范围

特点

动机

历史