軟體架構是有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計。軟體架構會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性。軟體架構可以和建築物的架構相比擬。軟體架構是構建電腦軟體，開發系統以及計劃進行的基礎，可以列出開發團隊需要完成的任務。

軟體架構是在軟體的基礎架構上進行決策，決定後再做修改的代價很大。軟體架構中的決策包括在軟體設計時的一些特殊結構性選項，例如要控制太空船登陸艇的系統需要快速而且可靠，因此需要選擇適合即時計算的語言，而且為了滿足可靠度的需求，程式需要有數個冗餘的複本，各複本運作在不同的硬體上，以便比對各程式的結果。

將軟體架構文件化有助於和專案關係人之間的溝通，在高層設計時就可以提早進行決策，也可以在各專案之間復用設計組件。



介紹

軟體體系結構是構建電腦軟體實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，軟體架構師或者系統架構師陳述軟體架構以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的進階設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，使用者介面風格，對外介面方法，創新的設計特性，以及高層事物的物件操作、邏輯和流程。

軟體架構師與客戶商談概念上的事情，與經理商談廣泛的設計問題，與軟體工程師商談創新的結構特性，與程式設計師商談實現技巧，外觀和風格。

軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者物件。在物件導向領域中，組件之間的連接通常用介面來實現。



範圍

軟體架構的範圍有許多不同的定義：


* 巨觀系統架構：這是指高階的軟體系統抽象化，其中包括了許多的組件（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_ 的書，提出了軟體架構中的很多概念，例如軟體組件、連接器、風格等等。加州大學埃爾文分校的軟體研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。



架構活動

開發軟體架構的過程會和許多的活動有關。軟體架構師一般會和專案經理一起工作，和專案關係人討論架構重要需求、設計軟體架構、評估設計、和設計師及專案關係人溝通、撰寫架構設計的檔案等在軟體架構設計中，有四個核心活動，分別是架構分析、架構合成、架構評估和架構演進。這些核心的架構活動會反覆的出現，也會出現在軟體開發生命週期的初始階段，及後續階段。

架構分析（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）是評估設計決策的活動。此活動是三個軟體架構核心活動的基礎。其中包括了蒐集決策環境以及建立關聯性，制訂設決策問題，尋找對策選項，在決策之前在各對策之間取捨。在評估重要架構需求、軟體架構決策、軟體架構分析、合成及評估時，此過程會以不同的決策粒度反覆出現。推理活動的例子包括瞭解品質屬性需求或設計上的影響，針對設計可能產生的問題提問、評估可能的對策選項，以及各對策之間的取捨。

* 撰寫檔案（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 軟體》曾特別探討敏捷和軟體架構之間的關係。

軟體架構腐蝕

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

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

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

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

軟體架構恢復

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



相關領域

設計

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

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

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

需求工程

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

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

其他種類的架構

電腦系統結構
: 電腦系統結構是針對電腦系統中的內容結構，是許多硬體元件的組件，例如中央處理器、匯流排及電腦記憶體。

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

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



參考文獻

參照

來源



相關條目


* 軟體工程

* 可用性工程

* 軟體架構分析方法

* 軟體智能

* ArchiMate

* 架構模式

* 反面模式

* 屬性驅動設計

* C4 模型

* 電腦系統結構

* 分散式資料管理架構

* 分散式關聯資料庫架構（DRDA）

* 系統架構

* 系統設計

* 時間觸發系統

* 軟體架構師

* 系統架構師