软件架构
软件架构描述
编辑
主条目：软件架构描述（英语：Software architecture description）
软件架构描述包括建模以及实现其架构的原理以及实务，其中会使用架构描述语言、架构视图及架构框架等。
架构描述语言
编辑
架构描述语言（ADL）用于描述软件的体系架构。现在已有多种架构描述语言，如Wright（由卡内基梅隆大学开发），Acme（由卡内基梅隆大学开发），C2（由UCI开发），Darwin（由伦敦帝国学院开发）。ADL的基本构成包括组件、连接器和配置。
架构视图
编辑
主条目：视图模型（英语：View model）
4+1架构视图
软件架构的叙述常会整理成视图模型（view model），如同在建筑学中的不同种类的蓝图。每一种视图会着重一些系统的事务，依循其约定的观点（viewpoint），观点是指为了要以特定关系人（stakeholder）及其关注点的角度说明系统架构，因此针对标示、模型、分析技巧的说明方式的规范（ISO/IEC 42010（英语：ISO/IEC/IEEE 42010））。观点不但指定框架的关注点，也指定说明的方式、使用的模型、使用的习惯，以及可以和其他视图维持一致性的规则。
以下是一些可能的视图：
功能/逻辑视图
代码视图
开发/结构视图
并行/过程/线程视图
物理/部署视图
用户动作/反馈视图
目前已开发了许多描述软件架构的语言，但是大家对于要用何种的符号集和视图系统，还没有达成共识。一些人相信UML将建立软件架构视图的标准。
架构框架
编辑
架构框架（architecture framework）可以定义为“特定应用或/及特定群体在叙述架构时的习惯，原则以及实务”[28]（ISO/IEC 42010（英语：ISO/IEC 42010））。框架一般会用一个或多个视图或ADL来表示。架构框架的例子有：MODAF（英语：MODAF）、开放组体系结构框架、Kruchten的4+1架构视图、RM-ODP（英语：RM-ODP）等。
架构模式
编辑
主条目：架构模式
架构模式是针对在特定情境下软件架构上的常见问题，通用性，可复用的解决方案。
架构模式也像设计模式一样有对应的文件。
架构模式的概念类似传统的建筑，软件架构风格是有关架构的特定作法，有各自的特征。
“
架构模式定义：“由许多结构性组织模式形成成的系统家族：其中许多组件以及链接方式的字汇，也有一些彼此组合上的限制。”[29]
”
“
架构模式是在设计决策及限制上上可复用的“包裹”，可以应用在一架构上，以产生想要的特性。[30]
”
有许多知名的架构模式及风格，举例如下：
黑板
主从式架构（二层结构、三层结构（英语：Three-tier (computing)）、n-tier（英语：n-tier），云计算会有这类风格）
基于组件的软件工程
数据库中心（英语：Database-centric architecture）
事件驱动（英语：Event-driven architecture）（或隐式调用（英语：Implicit invocation））
抽象化（或多层架构）
微服务
单层系统、单体式应用程序
MVC（Model–view–controller）
点对点网络（P2P）
管道
插件
表现层状态转换（REST）
规则为基础的系统（英语：Rule-based system）
面向服务的体系结构
无共享架构（英语：Shared nothing architecture）
空间为基础的架构（英语：Space-based architecture）
单层系统
有些人将架构模式和架构风格视为是同一件事[31]，有时则是将架构风格视为是架构模式的实例，不过将架构模式和架构风格都是架构师常用的语言，在描述系统类型时“提供共享的语言” [31]或“字汇”[29]。
软件架构和敏捷开发
编辑
主条目：敏捷开发
也有研究者认为软件架构造成太多的早期的大型设计（英语：Big Design Up Front），尤其敏捷开发的提倡者更是如此认为。有许多的方式设计要在早期设计以及敏捷之间作取舍[32]，其中包括敏捷式的动态系统开发方式（英语：dynamic systems development method）（DSDM），其中强制一个“基础”阶段，只要列出“够用的”架构基础即可。《IEEE软件》曾特别探讨敏捷和软件架构之间的关系。
软件架构腐蚀
编辑
软件架构腐蚀（或退化）是指软件系统设计的架构以及实现时实际架构之间的落差[33]。软件架构腐蚀会出现在实现时的决策没有完成达到原先设计的架构，或是有一些违反架构原则或是限制的情形[2]。这种设计架构和实际架构之间的落差有时也会以技术负债的方式表示。
例如，考虑严格抽象化的系统，每一层都只能用往下一层所提供的服务。若代码组件无法遵守此一限制，就违反了架构。若此问题没有修正，此架构违反会让系统架构变成无法分层的架构，在程序理解性、可维护性和发展性都有不良影响。
针对软件架构腐蚀，有提出有许多的处理方法：
“这些方法，包括工具、技术及流程，主要可以分为三大类，设法减小、预防及修复架构腐蚀。在这三大类以下，各方法都可以再细分，反映为了解决侵蚀而采取的高阶策略。例如流程导向架构一致性、架构演进管理、架构设计强化、架构到实现的链接、包括恢复、发现以及调节的自适应及架构恢复技术。”[34]
针对侦测架构违反，有二种主流的技术：反射模型（Reflexion model）和领域特定语言（domain-specific languages）。反射模型技术会比较系统架构师提供的高阶模型，和代码的实现特定领域的语言。领域特定语言则是专注在标示及检查架构上的限制条件。
软件架构恢复
编辑
主条目：软件架构恢复
软件架构恢复（重建，或逆向工程）包括从已有信息（包括程序实现以及已有文件）中找到软件架构的方式以及技巧。若是遇到软件的文件过旧、架构腐蚀（软件的架构和后来的实现及维护不一致），又需要进行决策时，就需要进行软件架构恢复[35]。常见的技巧包括静态程序分析，软件架构恢复也是软件智能实务中的一部分。
软件架构评估
编辑
有数种评估软件架构的方法：软件架构分析方法（SAAM）在在1990年中期提出，是第一个有文件的软件架构评估方法。架构权衡分析方法（英语：architecture tradeoff analysis method）（ATAM）是由软件架构分析方法扩展，是以情境为其基础的评估方法。中间设计的主动评审（Active Reviews for Intermediate Designs）简称ARID，是在软件架构的中间阶段进行评估，不需要完整的软件架构[36]。此方法由美国软件工程研究所（英语：Software Engineering Institute）（SEI）所提出，结合了前面两种方法的观点，以及主动设计评审（active design reviews）的作法[37]。
