「軟體架構」軟體架構概述

軟體架構（architecture）是指軟體系統的基本結構以及建立這種結構和系統的規程。每個結構都包含軟體元素、它們之間的關系以及元素和關系的屬性。[1]軟體系統的架構是一個隐喻，類似于建築物的架構。[2]它作為系統和開發項目的藍圖，布置設計團隊需要執行的任務。[3]

軟體架構（architecture）是指做出基本的結構選擇，一旦實作，改變這些選擇的代價是高昂的。軟體架構（architecture）選擇包括軟體設計中可能出現的特定結構選項。例如，控制航天飛機運載火箭的系統要求非常快和非常可靠。是以，需要選擇合适的實時計算語言。此外，為了滿足可靠性的需要，可以選擇有多個備援和獨立生成的程式副本，并在交叉檢查結果的同時在獨立硬體上運作這些副本。

記錄軟體架構有助于利益相關者之間的溝通，捕獲有關進階設計的早期決策，并允許在項目之間重用設計元件。

範圍

對于軟體架構的範圍，人們的看法各不相同：[5]

• 宏觀系統結構：這是指體系結構，它是一個軟體系統的進階抽象，由一組計算元件和描述這些元件之間互動的連接配接器組成。[6]
• 不管是什麼重要的東西：這指的是軟體架構師應該關注那些對系統及其涉衆有重大影響的決策。[7]
• 對了解一個系統在其環境中所處的環境至關重要的東西[8]
• 人們認為很難改變的事情：由于設計架構發生在軟體系統生命周期的開始，是以架構師應該關注那些“必須”在第一時間正确的決策。按照這種思路，一旦建築設計問題的不可逆性能夠被克服，它們就可能變成非建築性的問題
• 一組架構設計決策：軟體體系結構不應僅僅被視為一組模型或結構，而應包括導緻這些特定結構的決策及其背後的理論基礎。[9]這種見解導緻了對軟體體系結構知識管理的大量研究。[10]

軟體架構（architecture）與設計（design）和需求工程（requirement engineering）之間沒有明顯的差別（參見下面的相關字段）。它們都是從高層意圖到底層細節的“意向鍊”的一部分

特點

軟體架構展示了以下内容：

• 利益相關者衆多：軟體系統必須迎合各種利益相關者，如業務經理、所有者、使用者和營運商。這些利益相關者對系統都有自己的關注點。平衡這些關注點并證明它們得到了解決是系統設計的一部分。[4]：29–31這意味着體系結構涉及到處理各種各樣的關注點和涉衆，并且具有多學科性質。
• 關注點分離：架構師降低複雜性的既定方法是分離驅動設計的關注點。架構（Architecture）文檔顯示，所有涉衆關注點都是通過從與各種涉衆關注點相關聯的不同角度模組化和描述架構來解決的。[12]這些單獨的描述稱為架構視圖（例如，請參見4+1架構視圖模型）。
• 品質驅動：經典的軟體設計方法（如Jackson結構化程式設計）是由系統所需的功能和資料流驅動的，但目前的觀點[4]：26-28是軟體系統的架構與其品質屬性（如容錯性、向後相容性）的關系更為密切，可擴充性、可靠性、可維護性、可用性、安全性、可用性和其他此類功能。幹系人關注點通常轉化為對這些品質屬性的需求，這些屬性被不同地稱為非功能需求、額外功能需求、行為需求或品質屬性需求。
• 重複樣式：與建構架構一樣，軟體架構規程已經開發了解決重複問題的标準方法。這些“标準方法”在不同的抽象層次上由不同的名稱來調用。重複性解決方案的常用術語是架構樣式，[11]：273–277政策，[4]：70–72參考架構[13][14]和架構模式。[4]：203–205
• 概念完整性：Fred Brooks在《神話人月》中引入的一個術語，用來表示軟體系統的架構代表了它應該做什麼以及應該如何做的總體構想。這一設想應與實施分開。架構師承擔着“視覺守護者”的角色，確定系統的添加與體系結構一緻，進而保持概念的完整性。[15]：41–50
• 認知限制：計算機程式員Melvin Conway在1967年的一篇論文中首次觀察到，設計系統的組織被限制生成設計，這些設計是這些組織的通信結構的副本。與概念完整性一樣，弗雷德·布魯克斯在其優雅的經典作品《神話人月》（Mythical Man Month）中引用了這篇論文和這一理念，并稱之為“康威定律”（Conway's Law），将其介紹給了更廣泛的讀者

動機

軟體架構（architecture）是複雜系統的“智能可了解”抽象。[4]：5–6該抽象提供了許多好處：

• 它為在系統建構之前對軟體系統的行為進行分析提供了基礎。[2]驗證未來軟體系統是否滿足其利益相關者的需求而無需實際建構它的能力代表了大量的成本節約和風險緩解。[16]已經開發了許多技術來執行此類分析，比如阿塔姆。
• 它為元素和決策的重用提供了基礎。[2][4]：35一個完整的軟體體系結構或其部分，如單個體系結構政策和決策，可以跨多個系統重用，這些系統的涉衆需要相似的品質屬性或功能，進而節省設計成本并降低設計錯誤的風險。
• 它支援影響系統開發、部署和維護壽命的早期設計決策。[4]：31正确地做出早期、高影響的決策對于防止進度和預算超支非常重要。
• 它促進了與涉衆的溝通，有助于建立一個更好地滿足其需求的系統。[4]：29–31從涉衆的角度溝通複雜系統，有助于他們了解所述需求的後果以及基于這些需求的設計決策。體系結構使得在系統實作之前就設計決策進行交流的能力，而這些決策仍然相對容易适應。
• 它有助于風險管理。軟體架構有助于減少風險和失敗的機會
• 它可以降低成本。軟體架構是在複雜的IT項目中管理風險和成本的一種手段

曆史

軟體設計和（民用）建築的比較最早出現在20世紀60年代末，[18] 但是直到20世紀90年代，“軟體體系結構”這個術語才被廣泛使用。[19]計算機科學領域自形成以來就遇到了與複雜性相關的問題。[20]早期的複雜性問題是由開發人員通過選擇正确的資料結構、開發算法和應用關注點分離。雖然“軟體架構”這個術語對業界來說是相對較新的，但自20世紀80年代中期以來，該領域的基本原理就被軟體工程的先驅們零星地應用。早期捕獲和解釋系統的軟體架構的嘗試是不精确和無序的，通常以一組方框圖和折線圖為特征。[21]

軟體體系結構作為一個概念起源于1968年Edsger Dijkstra和70年代早期David Parnas的研究，這些科學家強調軟體系統的結構至關重要，正确的結構至關重要。在20世紀90年代，有一個共同的努力來定義和編纂該學科的基本方面，研究工作集中在建築風格（模式）、建築描述語言、建築文檔和形式方法上

作為一門學科，研究機構在促進軟體體系結構的發展方面發揮了突出的作用。卡内基梅隆大學的Mary Shaw和David Garlan在1996年寫了一本書，名為《軟體架構：對一門新興學科的展望》，該書提倡軟體架構概念，如元件、連接配接器和樣式。加州大學歐文軟體研究所緻力于軟體架構研究，主要針對架構風格、架構描述語言和動态架構。

IEEE 1471-2000《軟體密集型系統體系結構描述推薦規程》是軟體體系結構領域的第一個正式标準。它于2007年被ISO采用為ISO/IEC 42010:2007。2011年11月，IEEE 1471-2000被ISO/IEC/IEEE 42010:2011“系統和軟體工程-架構描述”（由IEEE和ISO聯合釋出）取代

在IEEE 1471中，軟體架構是關于“軟體密集型系統”的架構，定義為“軟體對整個系統的設計、建構、部署和演化産生重要影響的任何系統”，2011年版更進一步，包括了ISO/IEC 15288和ISO/IEC 12207對系統的定義，這些定義不僅包括硬體和軟體，還包括“人、過程、程式、設施、材料和自然發生的實體”。這反映了軟體架構、企業架構和解決方案架構之間的關系。

架構活動

軟體架構師執行的活動有很多。軟體架構師通常與項目經理合作，與幹系人讨論架構上重要的需求，設計軟體架構，評估設計，與設計師和幹系人溝通，記錄體系結構設計等。[23]軟體體系結構設計中有四個核心活動。[24]這些核心體系結構活動是在初始軟體開發生命周期的不同階段以及系統的演化過程中疊代執行的。

• 架構（architecture）分析是了解所提議的系統将在其中運作的環境并确定系統需求的過程。分析活動的輸入或需求可以來自任何數量的涉衆，包括以下項目：

1. 系統運作時将做什麼（功能需求）
2. 系統将如何執行運作時非功能性需求，如可靠性、可操作性、性能效率、安全性、ISO/IEC 25010:2011标準[25]中定義的相容性
3. 開發時非功能性需求，如ISO 25010:2011标準[25]中定義的可維護性和可轉移性
4. 一個系統的業務需求和環境背景可能會随着時間而改變，例如法律、社會、金融、競争和技術問題[26]

• 分析活動的輸出是那些對軟體系統架構有可測量影響的需求，稱為架構上重要的需求
• 架構綜合或設計是創造一個架構的過程。考慮到通過分析确定的架構上的重要需求、設計的目前狀态和任何評估活動的結果，建立并改進了設計。[24][4]：311–326
• 架構（Architecture）評估（evaluation）是确定目前設計或其一部分如何滿足分析期間導出的需求的過程。每當架構師考慮設計決策時，評估就可能發生，評估可能發生在設計的某一部分完成之後，評估可能發生在最終設計完成之後，評估也可能發生在系統建構之後。一些可用的軟體架構（architecture）評估技術包括架構（architecture）權衡分析方法（ATAM）和TARA。[28]比較這些技術的架構在SARA報告[16]和架構評審：實踐和經驗[29]等架構中進行了讨論
• 架構演化是維護和調整現有軟體體系結構以滿足需求和環境變化的過程。由于軟體體系結構提供了軟體系統的基本結構，其演化和維護必然會影響其基本結構。是以，體系結構演進涉及添加新功能以及維護現有功能和系統行為。

架構需要關鍵的支援活動。這些支援活動貫穿于核心軟體架構（architecture）過程。它們包括知識管理和溝通、設計推理和決策以及文檔。

架構支援活動

軟體架構（architecture）支援活動在核心軟體架構（architecture）活動期間執行。這些支援活動幫助軟體架構師進行分析、綜合、評估和演化。例如，架構師必須在分析階段收集知識、做出決策和文檔。

• 知識管理和通信是一種探索和管理知識的行為，對設計軟體體系結構至關重要。軟體架構師不是孤立地工作的。它們從不同的涉衆那裡獲得輸入、功能性和非功能性需求以及設計上下文；并向涉衆提供輸出。軟體架構知識通常是預設的，并保留在涉衆的頭腦中。軟體架構知識管理活動是關于發現、交流和保留知識的活動。由于軟體架構設計問題錯綜複雜且互相依存，設計推理中的知識缺口可能導緻不正确的軟體架構設計。[23][30]知識管理和溝通活動的示例包括搜尋設計模式、原型設計、詢問有經驗的開發人員和架構師，評估類似系統的設計，與其他設計師和利益相關者共享知識，并在wiki頁面中記錄經驗。
• 設計推理與決策是評價設計決策的活動。這項活動是所有三個核心軟體架構活動的基礎。[9][31]它需要收集和關聯決策上下文，制定設計決策問題，尋找解決方案選項，并在做出決策之前評估權衡。當評估重要的體系結構需求和軟體體系結構決策，以及軟體體系結構分析、合成和評估時，此過程在不同的決策粒度級别上發生。推理活動的例子包括了解需求或設計對品質屬性的影響，質疑設計可能引起的問題，評估可能的解決方案選項，以及評估解決方案之間的權衡。
• 文檔是記錄軟體架構（architecture）過程中生成的設計的行為。系統設計使用幾個視圖進行描述，這些視圖通常包括顯示系統代碼結構的靜态視圖、顯示系統在執行期間的操作的動态視圖和顯示系統如何放置在硬體上執行的部署視圖。Kruchten的4+1視圖建議描述用于記錄軟體體系結構的常用視圖；[32]記錄軟體體系結構：views and Beyond描述了視圖描述中可以使用的各種符号。[1]文檔活動的示例正在編寫規範，記錄系統設計模型，記錄設計原理，開發觀點，記錄視圖。

軟體架構主題

軟體架構描述

Main article: Software architecture description

軟體架構描述涉及使用架構描述語言、架構視點和架構架構等機制對架構進行模組化和表示的原則和實踐。

架構描述語言

Main article: Architecture description language

體系結構描述語言（ADL）是用來描述軟體體系結構（ISO/IEC/IEEE 42010）的任何表達方式。自20世紀90年代以來，開發了許多專用ADL，包括AADL（SAE标準）、Wright（由卡内基梅隆開發）、Acme（由卡内基梅隆開發）、xADL（由UCI開發）、Darwin（由倫敦帝國理工學院開發）、DAOP-ADL（由馬拉加大學開發）、SBC-ADL（由國立中山大學開發）和ByADL（意大利拉奎拉大學）。

架構角度

Main article: View model

4+1建築視圖模型。

軟體架構描述通常被組織成視圖，類似于在建築架構中生成的不同類型的藍圖。每個視圖都按照其視點的約定處理一組系統關注點，其中視點是一個規範，描述了要在視圖中使用的符号、模組化和分析技術，該視圖從給定的一組涉衆及其關注點的角度表示所讨論的體系結構（ISO/IEC/IEEE42010）。該視點不僅指定了所建構的關注點（即要解決的關注點），而且還指定了表示、使用的模型類型、使用的約定以及任何保持視圖與其他視圖一緻的一緻性（對應）規則。

架構架構

Main article: Architecture framework

架構（architecture）架構捕獲“描述在特定應用領域和/或利益相關者社群中建立的架構的慣例、原則和實踐”（ISO/IEC/IEEE42010）。架構通常是根據一個或多個視點或adl來實作的。

架構風格和模式

Main article: Architectural pattern

架構模式是一種通用的、可重用的解決方案，用于解決給定上下文中軟體架構中常見的問題。架構模式通常被記錄為軟體設計模式。

“軟體建築風格”是繼傳統建築風格之後的一種特殊的建築方法，其特點是使其引人注目（建築風格）。

體系結構樣式定義：以結構組織模式表示的一系列系統；元件和連接配接器的詞彙表，以及如何組合它們的限制條件。[33]

“體系結構樣式是可重用的設計決策和限制的‘包’，應用于體系結構以獲得所選的理想品質。[34]”

有許多公認的建築模式和風格，其中包括：

• 黑闆
• 用戶端伺服器（2層、3層、n層，雲計算展示了這種風格）
• 基于元件
• 以資料為中心
• 事件驅動（或隐式調用）
• 分層（或多層體系結構）
• 微服務架構
• 整體應用
• 模型視圖控制器（MVC）
• 對等（P2P）
• 管道和過濾器
• 插件
• 反應式體系結構
• 代表性狀态轉移（REST）
• 基于規則
• 服務導向
• 無共享架構
• 天基建築

有些人認為建築模式和建築風格是一樣的，[35]有些人認為風格是模式的專門化。它們的共同點是模式和風格都是建築師使用的習語，它們“提供了一種共同的語言”[35]或“詞彙”[33]來描述系統的類。

軟體架構與靈活開發

Main article: Agile development

也有人擔心軟體架構會導緻太多的大設計，特别是在靈活軟體開發的支援者中。已經開發了許多方法來平衡前期設計和靈活性之間的權衡，[36]包括靈活方法DSDM，DSDM要求在“基礎”階段打下“足夠”的架構基礎。IEEE軟體專門出版了一期專門讨論靈活性和體系結構之間的互動的專刊[37]。

軟體架構侵蝕

軟體架構侵蝕（或稱“衰退”）是指在軟體系統的實作過程中，在軟體系統的計劃架構和實際架構之間觀察到的差距。[38]當實作決策沒有完全實作計劃架構或違反這種架構。[2]計劃架構和實際架構之間的差距有時可以用技術債務的概念來了解。

例如，考慮一個嚴格分層的系統，其中每個層隻能使用它下面的層提供的服務。任何不遵守此限制的源代碼元件都表示違反了體系結構。如果不加以糾正，這種違規行為可能會将體系結構轉換為一個整體塊，進而對可了解性、可維護性和可演化性産生不利影響。

已經提出了各種辦法來解決侵蝕問題。”這些方法，包括工具、技術和過程，主要分為三大類，試圖最小化、防止和修複架構侵蝕。在這些大類中，每一種方法都進一步細分，反映了為解決侵蝕問題而采取的進階别戰略。這些是面向過程的體系結構一緻性、體系結構演化管理、體系結構設計實施、體系結構到實作的連結、自适應和體系結構恢複技術，包括恢複、發現和協調

檢測體系結構沖突有兩種主要技術：反射模型和領域特定語言。反射模型（RM）技術将系統架構師提供的進階模型與源代碼實作進行比較。還有一些特定于領域的語言，重點是指定和檢查體系結構限制。

軟體架構恢複

Main article: Software architecture recovery

軟體架構（architecture）恢複（或重構，或逆向工程）包括從可用資訊（包括其實作和文檔）中揭示軟體系統架構的方法、技術和過程。在面對過時或過時的文檔和架構侵蝕時，架構恢複通常是做出明智決策所必需的：實作和維護決策與設想的架構不同。[40]存在将軟體架構恢複為靜态程式分析的實踐。這是軟體智能實踐課程的一部分。

相關領域

設計

Main article: Software design

架構是設計，但并非所有的設計都是架構。[1]實際上，架構師是在軟體架構（架構設計）和詳細設計（非架構設計）之間劃清界線的人。沒有适合所有情況的規則或準則，盡管有人試圖将這種差別形式化。根據内涵/局部性假設，[41]建築設計和詳細設計之間的差別是由局部性标準定義的，[41]根據局部性标準，關于軟體設計的陳述是非局部的（建築），前提是滿足它的程式可以擴充成不滿足它的程式。例如，客戶機-伺服器樣式是體系結構（戰略性的），因為基于此原則建構的程式可以擴充為非客戶機-伺服器的程式，例如，通過添加對等節點。

需求工程

Main article: Requirements engineering

需求工程和軟體架構可以看作是互補的方法：當軟體架構以“解決方案空間”或“如何”為目标時，需求工程解決“問題空間”或“什麼”。[42]需求工程需要啟發、協商、規範、驗證，要求的檔案和管理。需求工程和軟體架構都圍繞涉衆的關注點、需求和願望。

需求工程（engineering）和軟體架構（architecture）之間存在相當大的重疊，例如，對五種工業軟體架構（architecture）方法的研究表明，“輸入（目标、限制等）通常定義不清，隻有當體系結構開始出現時才能被發現或更好地了解，并且“雖然大多數體系結構關注點被表達為系統上的需求，但它們也可以包括強制性的設計決策”[24]簡而言之，所需的行為影響解決方案體系結構，這反過來又可能引入新的需求。[43]雙峰模型等方法[44]旨在利用需求和體系結構之間的協同關系。

其他類型的“架構”

Main articles: Computer architecture, Systems architecture, and Enterprise architecture

計算機架構

計算機架構以計算機系統的内部結構為目标，以協作硬體元件（如CPU或處理器、總線和記憶體）為基礎。

系統架構

術語系統架構最初應用于由硬體和軟體組成的系統架構。系統體系結構解決的主要問題是将軟體和硬體內建到一個完整、正常工作的裝置中。在另一個共同的（更廣泛的）含義中，這個術語适用于任何複雜系統的架構，這些系統可能具有技術性、社會技術性或社會性。

企業架構

企業架構的目标是“将業務遠景和戰略轉化為有效的企業”[45]企業架構架構，如TOGAF和Zachman架構，通常區分不同的企業架構層。盡管術語因架構而異，但許多術語至少包括業務層、應用程式（或資訊）層和技術層之間的差別。企業架構解決了這些層之間的對齊問題，通常采用自頂向下的方法。

另見

架構模式（計算機科學）

• 反模式
• 屬性驅動設計
• 計算機體系結構
• 分布式資料管理體系結構
• 分布式關系資料庫體系結構
• 系統架構
• 系統設計
• 軟體體系結構分析方法
• 時間觸發系統

本文：http://jiagoushi.pro/wikipedia-software-architecture

讨論：請加入知識星球或者微信圈子【首席架構師圈】

微信公衆号	關注微信公衆号【首席架構師智庫】
微信小号	希望加入的群：架構，雲計算，大資料，資料科學，物聯網，人工智能，安全，全棧開發，DevOps，數字化，産品轉型。
知識星球	向大咖提問，近距離接觸，或者獲得私密分享。	點選加入知識星球【首席架構師圈】
微信圈子	志趣相投的同好交流。	點選加入微信圈子【首席架構師圈】
喜馬拉雅	路上或者車上了解最新黑科技資訊，架構心得。	點選，收聽【智能時刻，架構君和你聊黑科技】
知識星球	認識更多朋友，職場和技術閑聊。	點選加入知識星球【知識和技術】