软件架构 软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软体组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。 软件架构是在软体的基础架构上进行决策，决定后再做修改的代价很大。软件架构中的决策包括在软体设计时的一些特殊结构性选项，例如要控制太空船登陆艇的系统需要快速而且可靠，因此需要选择适合实时计算的语言，而且为了满足可靠度的需求，程式需要有数个冗余的复本，各复本运作在不同的硬体上，以便比对各程式的结果。 将软体架构文档化有助于和之间的沟通，在高层设计时就可以提早进行决策，也可以在各专案之间复用设计组件:29–35。 介绍. 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，或者系统架构师陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。 软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序员商谈实现技巧，外观和风格。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。 范围. 软件架构的范围有许多不同的定义： 在软体架构、设计、需求工程之间，没有具体明显的分界。这些是「一连串意图的结合」，从高阶的设计意向到低阶的设计细节:18。 特点. 软件架构有以下这些特点： 众多的关系人：软件架构需配合许多的关系人（stakeholder），例如业务经理、部门主管、使用者及运营商。每一个关系人都有各自关注的内容。在设计系统中，如何平衡这些关注，并展示他们所关注的讯息，也是一个重点:29–31。因此，软体架构中就包括了处理众多的关注及关系人，因此在本质上就是跨领域的。 关注点分离：架构师降低复杂度的可行方式，就是将驱动设计的各关注分开。架构文件会呈现相关者关注的所有内容，会以建构的方式表示，另外也会用各相关者关注的角度来描述软体的架构。这种分开来的说明称为架构视图，例如4+1架构视图。 品质导向：传统的软件设计方法（例如杰克逊结构化编程）是依需求的机能以及资料在系统中流动的方式所驱动，不过目前的见解:26–28是软体系统的架构和其品质属性（例如故障容许度、向下兼容、可扩充性、可靠度、、可用性、资料安全等）的关系更高。相关者的关注可以转换为有关这些品质属性上的需求，一般会称为非功能性需求、额外功能性需求、行为需求或品质属性需求。 重复的风格：软体架构和建筑类似，在处理一些重复出现的事务时会发展出标准化的作法。标准化作法有许多不同的名称，其中也有不同程度的抽象化。常见的术语有架构风格:273–277 、tactic:70–72、及架构模式:203–205。 概念完整性：这是佛瑞德·布鲁克斯在写作《人月神话》一书时提及：软体系统的架构是有关软体系统该作什么以及不该作什么的实体观点。这些观点应和软体的实现分开。架构师的角色是「观点的看守者」，确认系统中增加的部份是符合此架构，因此可以保有概念完整性:41–50。 认知制约：程式设计师马尔文·康威在1967年论文发表了康威定律，其中提到一个组织开发的软体，其架构会反映其组织架构。佛瑞德·布鲁克斯在写作《人月神话》一书时，就在书上时提到此例子，命名为「康威定律」。 动机. 软件架构是复杂系统「在智力上能理解」（intellectually graspable）的抽象:5–6，此抽象有以下的好处： 历史. 早在1960年代，诸如艾兹格·迪杰斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在和Microsoft内部的相关活动，软件架构这个概念开始越来越流行起来。 卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做"Software Architecture perspective on an emerging discipline"的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。 架构活动. 开发软体架构的过程会和许多的活动有关。软体架构师一般会和专案经理一起工作，和专案关系人讨论架构重要需求、设计软体架构、评估设计、和设计师及专案关系人沟通、撰写架构设计的文件等在软体架构设计中，有四个核心活动，分别是架构分析、架构合成、架构评估和架构演进。这些核心的架构活动会反复的出现，也会出现在软体开发生命周期的初始阶段，及后续阶段。 架构分析（Architectural analysis）是了解计划的系统要运作的环境，以及决定系统的需求。分析活动的输入或是需求可以来自专案关系人，也可能会包括以下项目： 分析活动的产出是在软体系统架构上有相关影响的需求，这些称为是架构重要需求（architecturally significant requirements）。 架构合成（Architectural synthesis）或架构设计是指产生架构的过程。针对在架构分析时产生的架构重要需求、设计的目前状态、及评估活动的结构，可以进行设计，也可以针对设计进行改善:311–326。 架构评估（Architecture evaluation）是在分析过程中确认现有设计整体（或其部份）满足各需求程度的程序。架构评估的时机可以在架构设计师进行设计决策中的时候，部份设计已完成时，细节设计完成后，或是系统已架设完成之后。有些分析软体架构的技术，例如（ATAM）及Tiny Architectural Review Approach（TARA）等。有些可以比较这些技术的框架，例如SARA Report及《架构评审：实务及经验》（Architecture Reviews: Practice and Experience）。 架构演进（Architecture evolution）是指维护已有的软体架构并且调整，以符合环境及需求变化的过程。软体架构提供软体系统的基本架构，其演进及维护必然会影响软体基础架构。因此，架构演进一方面关注的是加入新的功能，另一方面也要维护原有的机能以及系统行为。 架构支持活动. 架构设计需要关键性的支持活动。这些支持活动也和核心的软体架构过程中一起出现。这些支持活动可以协助软体架构师进行分析、合成、评估及演进。例如软体架构师需要在分析阶段搜集资讯、进行决策，并且撰写文件。这些活动包括知识管理、交流、设计推理、决策以及撰写文件。 软体架构主题. 软体架构描述. 软体架构描述包括建模以及实现其架构的原理以及实务，其中会使用架构描述语言、架构视图及架构框架等。 架构描述语言. 架构描述语言（ADL）用于描述软件的体系架构。现在已有多种架构描述语言，如Wright（由卡内基梅隆大学开发），Acme（由卡内基梅隆大学开发），C2（由UCI开发），Darwin（由伦敦帝国学院开发）。ADL的基本构成包括组件、连接器和配置。 架构视图. 软体架构的叙述常会整理成视图模型（view model），如同在建筑学中的不同种类的蓝图。每一种视图会著重一些系统的事务，依循其约定的观点（viewpoint），观点是指为了要以特定关系人（stakeholder）及其关注点的角度说明系统架构，因此针对标示、模型、分析技巧的说明方式的规范（）。观点不但指定框架的关注点，也指定说明的方式、使用的模型、使用的习惯，以及可以和其他视图维持一致性的规则。 以下是一些可能的视图： 目前已开发了许多描述软件架构的语言，但是大家对于要用何种的符号集和视图系统，还没有达成共识。一些人相信UML将建立软件架构视图的标准。 架构框架. 架构框架（architecture framework）可以定义为「特定应用或/及特定群体在叙述架构时的习惯，原则以及实务」（）。框架一般会用一个或多个视图或ADL来表示。架构框架的例子有：、开放组体系结构框架、Kruchten的4+1架构视图、等。 架构模式. 架构模式是针对在特定情境下软体架构上的常见问题，通用性，可复用的解决方案。 架构模式也像设计模式一样有对应的文件。 架构模式的概念类似传统的建筑，软体架构风格是有关架构的特定作法，有各自的特征。 有许多知名的架构模式及风格，举例如下： 有些人将架构模式和架构风格视为是同一件事，有时则是将架构风格视为是架构模式的实例，不过将架构模式和架构风格都是架构师常用的语言，在描述系统类型时「提供共用的语言」 或「字汇」。 软体架构和敏捷开发. 也有研究者认为软体架构造成太多的，尤其敏捷开发的提倡者更是如此认为。有许多的方式设计要在早期设计以及敏捷之间作取舍，其中包括敏捷式的（DSDM），其中强制一个「基础」阶段，只要列出「够用的」架构基础即可。《IEEE软件》曾特别探讨敏捷和软体架构之间的关系。 软体架构腐蚀. 软体架构腐蚀（或退化）是指软体系统设计的架构以及实现时实际架构之间的落差。软体架构腐蚀会出现在实现时的决策没有完成达到原先设计的架构，或是有一些违反架构原则或是限制的情形。这种设计架构和实际架构之间的落差有时也会以技术负债的方式表示。 例如，考虑严格抽象化的系统，每一层都只能用往下一层所提供的服务。若程式码元件无法遵守此一限制，就违反了架构。若此问题没有修正，此架构违反会让系统架构变成无法分层的架构，在程式理解性、可维护性和发展性都有不良影响。 针对软体架构腐蚀，有提出有许多的处理方法： 「这些方法，包括工具、技术及流程，主要可以分为三大类，设法减小、预防及修复架构腐蚀。在这三大类以下，各方法都可以再细分，反映为了解决侵蚀而采取的高阶策略。例如流程导向架构一致性、架构演进管理、架构设计强化、架构到实现的连结、包括恢复、发现以及调节的自适应及架构恢复技术。」 针对侦测架构违反，有二种主流的技术：反射模型（Reflexion model）和领域特定语言（domain-specific languages）。反射模型技术会比较系统架构师提供的高阶模型，和程式码的实现特定领域的语言。领域特定语言则是专注在标示及检查架构上的限制条件。 软体架构恢复. 软体架构恢复（重建，或逆向工程）包括从已有资讯（包括程式实现以及已有文件）中找到软体架构的方式以及技巧。若是遇到软体的文件过旧、架构腐蚀（软体的架构和后来的实现及维护不一致），又需要进行决策时，就需要进行软体架构恢复。常见的技巧包括静态程序分析，软体架构恢复也是软体智能实务中的一部份。 相关领域. 设计. 软件架构是设计的一部份，不过不是所有的设计都和架构有关。实务上，架构师会划分出软体架构（架构设计）以及细节设计（非架构设计）的分界。有没可以符合所有情形的规则或指引，不过仍有许多人设法要将找到分界的固定体系。 依照「内涵/局部性假说」（Intension/Locality Hypothesis），架构设计和细节设计的分界在于「局部性准则」（Locality Criterion），此准则认为若满足此设计的程式可以扩充进一个不是以此设计的程式，则软体设计属于架构性（非局部性），这也是软体设计属于架构性的唯一条件。 举例，主从式架构是架构（策略）设计，因为以主从式架构撰写的程式可以扩充到一个不是主从式架构（例如对等网路节点）的程式里。 需求工程. 需求工程和软体架构可以视为是互补的二个方法：软体架构专注在或是「如何进行」，需求工程专注在或是「要做什么」。需求工程会展开需求获取、需求分析、软件需求说明、、需求可追踪性及需求管理。需求工程和软体架构都和专案关系人的关注、需要及期待有关。 在需求工程和软体架构之间有相当大的重叠，有一个针对五个软体产业架构方法的研究，结论是：「输入（目的、限制等）一般定义的不好，要到开始建立架构时才会发现，或是比较深入的了解。」以及「大部份的架构关注都以是系统需求来表示，不过其中也包括了强制的设计决策。」。简单来说，需求的行为会影响解决方案的架构，架构又会产生新的需求。像Twin Peaks model等方式就是要利用需求以及架构之间的协同关系。 计算机系统结构是针对电脑系统中的内容结构，是许多硬体元件的组件，例如中央处理器、总线及电脑记忆体。 系统架构一开始是应用在描述系统（包括硬体和软体）的架构。系统架构主要关注的是软体和硬体的整合，组成完成，可以正确运作的设备。系统架构也可能是指更广义而复杂之系统的架构，可能是技术、或是纯社会的系统。 企业架构是「将企业的理景及策略转换为高效的企业运作」。企业架构，例如开放组体系结构框架（TOGAF）和Zachman框架，会将企业架构分成不同的层。各框架的用语可能不同，但至少都会区分企业层、应用层（或资讯层）及技术层。企业架构会处理各层之间的同步，是用top-down的方式进行。 参考文献. 来源.