软件架构

架構設計需要關鍵性的支持活動。這些支持活動也和核心的軟體架構過程中一起出現。這些支持活動可以協助軟體架構師進行分析、合成、評估及演進。例如軟體架構師需要在分析階段搜集資訊、進行決策，並且撰寫文件。這些活動包括知識管理、交流、設計推理、決策以及撰寫文件。

• 知識管理及交流（Knowledge management and communication）是發現有關軟體架構設計的重要知識，並且進行管理的活動。軟體架構師不會獨立作業，他們會從各專案關係人身上取得輸入、機能需求及非機能需求、以及設計環境（design context），也產出資訊給各專案關係人。軟體架構資訊是隱性的，保留在專案關係人的心裡。軟體架構管理活動和知識的發現、交流及保存有關。軟體架構設計議題錯綜複雜，並且彼此相關性很強，在設計理解上的知識落差可能就會造成錯誤的軟體架構設計[18][25]
• 設計推理及決策（Design reasoning and decision making）是評估設計決策的活動。此活動是三個軟體架構核心活動的基礎[9][26]。其中包括了蒐集決策環境以及建立關聯性，制訂設決策問題，尋找對策選項，在決策之前在各對策之間取捨。在評估重要架構需求、軟體架構決策、軟體架構分析、合成及評估時，此過程會以不同的決策粒度反覆出現。推理活動的例子包括瞭解品質屬性需求或設計上的影響，針對設計可能產生的問題提問、評估可能的對策選項，以及各對策之間的取捨。
• 撰寫文件（Documentation）是在軟體架構過程中記錄所得設計的活動。软件设计會用不同的視圖來描述，其中經常包括展示系統程式結構的靜態視圖（static view）、展示系統在運行時行為的動態視圖（dynamic view）、展示如何放在要運行硬體的佈署視圖（deployment view）時。Kruchten的4+1架構視圖有建議在針對軟體架構建立文件時，常用的視圖敘述[27]。 Documenting Software Architectures: Views and Beyond有說明在視圖敘述時可以用的標示方式[1]。撰寫文件的例子有撰寫規格、記錄系統設計模型、記錄設計理念、開發架构视角、記錄視圖等。

軟體架構描述包括建模以及實現其架構的原理以及實務，其中會使用架构描述语言、架構視圖及架構框架等。

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

4+1架構視圖

軟體架構的敘述常會整理成視圖模型（view model），如同在建筑学中的不同种类的蓝图。每一種視圖會著重一些系統的事務，依循其約定的觀點（viewpoint），觀點是指為了要以特定關係人（stakeholder）及其關注點的角度說明系統架構，因此針對標示、模型、分析技巧的說明方式的規範（ISO/IEC 42010）。觀點不但指定框架的關注點，也指定說明的方式、使用的模型、使用的習慣，以及可以和其他視圖維持一致性的規則。

以下是一些可能的视图：

• 功能/逻辑视图
• 代码视图
• 开发/结构视图
• 并行/过程/线程视图
• 物理/部署视图
• 用户动作/反馈视图

目前已開發了许多描述软件架构的语言，但是大家對於要用何種的符号集和视图系统，还没有达成共识。一些人相信UML将建立软件架构视图的标准。

架構框架（architecture framework）可以定義為「特定應用或/及特定群體在敘述架構時的習慣，原則以及實務」[28]（ISO/IEC 42010）。框架一般會用一個或多個視圖或ADL來表示。架構框架的例子有：MODAF、开放组体系结构框架、Kruchten的4+1架構視圖、RM-ODP等。

架构模式是針對在特定情境下軟體架構上的常見問題，通用性，可複用的解決方案。 架构模式也像设计模式一樣有對應的文件。

架构模式的概念類似傳統的建築，軟體架构風格是有關架構的特定作法，有各自的特徵。

有許多知名的架构模式及風格，舉例如下：

• 黑板
• 主從式架構（二層結構、三层结构、n-tier，雲端運算會有這類風格）
• 基于组件的软件工程
• 資料庫中心
• 事件驅動（或隐式调用）
• 抽象化（或多层架构）
• 微服務
• 单层系统、單體式應用程式
• MVC（Model–view–controller）
• 對等網路（P2P）
• 管道
• 插件
• 表现层状态转换（REST）
• 規則為基礎的系統
• 面向服务的体系结构
• 無共享架構
• 空間為基礎的架構
• 单层系统

有些人將架构模式和架构風格視為是同一件事[31]，有時則是將架构風格視為是架构模式的實例，不過將架构模式和架构風格都是架構師常用的語言，在描述系統類型時「提供共用的語言」 [31]或「字彙」[29]。

也有研究者認為軟體架構造成太多的早期的大型設計，尤其敏捷開發的提倡者更是如此認為。有許多的方式設計要在早期設計以及敏捷之間作取捨[32]，其中包括敏捷式的動態系統開發方式（DSDM），其中強制一個「基礎」階段，只要列出「夠用的」架構基礎即可。《IEEE软件》曾特別探討敏捷和軟體架構之間的關係。

軟體架構腐蝕（或退化）是指軟體系統設計的架構以及實現時實際架構之間的落差[33]。軟體架構腐蝕會出現在實現時的決策沒有完成達到原先設計的架構，或是有一些違反架構原則或是限制的情形[2]。這種設計架構和實際架構之間的落差有時也會以技术负债的方式表示。

例如，考慮嚴格抽象化的系統，每一層都只能用往下一層所提供的服務。若程式碼元件無法遵守此一限制，就違反了架構。若此問題沒有修正，此架構違反會讓系統架構變成無法分層的架構，在程式理解性、可維護性和發展性都有不良影響。

針對軟體架構腐蝕，有提出有許多的處理方法： 「這些方法，包括工具、技術及流程，主要可以分為三大類，設法減小、預防及修復架構腐蝕。在這三大類以下，各方法都可以再細分，反映為了解決侵蝕而採取的高階策略。例如流程導向架構一致性、架構演進管理、架構設計強化、架構到實現的連結、包括恢復、發現以及調節的自適應及架構恢復技術。」[34]

針對偵測架構違反，有二種主流的技術：反射模型（Reflexion model）和領域特定語言（domain-specific languages）。反射模型技術會比較系統架構師提供的高階模型，和程式碼的實現特定領域的語言。領域特定語言則是專注在標示及檢查架構上的限制條件。

軟體架構恢復（重建，或逆向工程）包括從已有資訊（包括程式實現以及已有文件）中找到軟體架構的方式以及技巧。若是遇到軟體的文件過舊、架構腐蝕（軟體的架構和後來的實現及維護不一致），又需要進行決策時，就需要進行軟體架構恢復[35]。常見的技巧包括靜態程序分析，軟體架構恢復也是軟體智能實務中的一部份。

软件架构是设计的一部份，不過不是所有的設計都和架構有關[1]。實務上，架構師會劃分出軟體架構（架構設計）以及細節設計（非架構設計）的分界。有沒可以符合所有情形的規則或指引，不過仍有許多人設法要將找到分界的固定體系。

依照「內涵/局部性假說」（Intension/Locality Hypothesis）[36]，架構設計和細節設計的分界在於「局部性準則」（Locality Criterion）[36]，此準則認為若滿足此設計的程式可以擴充進一個不是以此設計的程式，則軟體設計屬於架構性（非局部性），這也是軟體設計屬於架構性的唯一條件。

舉例，主從式架構是架構（策略）設計，因為以主從式架構撰寫的程式可以擴充到一個不是主從式架構（例如對等網路節點）的程式裡。

需求工程和軟體架構可以視為是互補的二個方法：軟體架構專注在解空間或是「如何進行」，需求工程專注在問題空間或是「要做什麼」[37]。需求工程會展開需求获取、需求分析、软件需求说明、資料確認、需求可追蹤性及需求管理。需求工程和軟體架構都和專案關係人的關注、需要及期待有關。

在需求工程和軟體架構之間有相當大的重疊，有一個針對五個軟體產業架構方法的研究，結論是：「輸入（目的、限制等）一般定義的不好，要到開始建立架構時才會發現，或是比較深入的瞭解。」以及「大部份的架構關注都以是系統需求來表示，不過其中也包括了強制的設計決策。」[19]。簡單來說，需求的行為會影響解決方案的架構，架構又會產生新的需求[38]。像Twin Peaks model[39]等方式就是要利用需求以及架構之間的協同關係。

计算机系统结构

计算机系统结构是針對電腦系統中的內容結構，是許多硬體元件的組件，例如中央处理器、总线及電腦記憶體。

系統架構

系統架構一開始是應用在描述系統（包括硬體和軟體）的架構。系統架構主要關注的是軟體和硬體的整合，組成完成，可以正確運作的設備。系統架構也可能是指更廣義而複雜之系統的架構，可能是技術、社會技術或是純社會的系統。

企业架构

企业架构是「將企業的理景及策略轉換為高效的企业運作」。企业架构網路，例如开放组体系结构框架（TOGAF）和Zachman框架，會將企業架構分成不同的層。各框架的用語可能不同，但至少都會區分企业層、应用層（或資訊層）及技术層。企业架构會處理各層之間的同步，是用top-down的方式進行。