Loading AI tools
軟件架構是有關軟件整體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。軟件架構會包括軟件組件、組件之間的關係，組件特性以及組件間關係的特性[1]。軟件架構可以和建築物的架構相比擬[2]。軟件架構是構建電腦軟件，開發系統以及計劃進行的基礎，可以列出開發團隊需要完成的任務[3]。
軟件架構是在軟件的基礎架構上進行決策，決定後再做修改的代價很大。軟件架構中的決策包括在軟件設計時的一些特殊結構性選項，例如要控制太空船登陸艇的系統需要快速而且可靠，因此需要選擇適合即時計算的語言，而且為了滿足可靠度的需求，程式需要有數個冗餘的複本，各複本運作在不同的硬件上，以便比對各程式的結果。
將軟件架構文件化有助於和專案關係人之間的溝通，在高層設計時就可以提早進行決策，也可以在各專案之間復用設計組件[4]:29–35。
介紹
軟件體系結構是構建電腦軟件實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，軟件架構師或者系統架構師陳述軟件架構以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的、主題、材料和結構的聯絡上來說，軟件架構可以和建築物的架構相比擬。一個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來實施和管理軟件產品的進階設計。軟件架構師定義和設計軟件的模組化，模組之間的互動，用戶介面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。
軟件架構師與客戶商談概念上的事情，與經理商談廣泛的設計問題，與軟件工程師商談創新的結構特性，與程式設計師商談實現技巧，外觀和風格。
軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在物件導向領域中，組件之間的連接通常用介面來實現。
範圍
軟件架構的範圍有許多不同的定義[5]：
- 巨觀系統架構：這是指高階的軟件系統抽象化，其中包括了許多的組件（component），以及描述各模組之間關係的「連接器」（connector）[6]。
- 重要的東西，無論是什麼都可以：這是指軟件架構師需要根據專案判斷，哪些決策對系統以及專案關係人有高度影響[7]。
- 瞭解系統環境的基礎[8]。
- 一些人們認為不容易改變的事物：設計架構是在軟件生命週期一開始就要進行的，軟件架構師需專注在一些「一開始就要正確」的決策，依照這個思路，若有些問題是可逆的，軟件架構上的問題就可以轉換為非架構性的問題[7]。
- 許多的架構設計決策：軟件架構不能只考慮許多的模型及結構，也要考慮造成這些特殊結構的決策，以及背後的原因[9]。此見解引發了大量有關軟件架構知識管理的研究[10]。
在軟件架構、設計、需求工程之間，沒有具體明顯的分界。這些是「一連串意圖的結合」，從高階的設計意向到低階的設計細節[11]:18。
特點
軟件架構有以下這些特點：
眾多的關係人：軟件架構需配合許多的關係人（stakeholder），例如業務經理、部門主管、用戶及運營商。每一個關係人都有各自關注的內容。在設計系統中，如何平衡這些關注，並展示他們所關注的訊息，也是一個重點[4]:29–31。因此，軟件架構中就包括了處理眾多的關注及關係人，因此在本質上就是跨領域的。
關注點分離：架構師降低複雜度的可行方式，就是將驅動設計的各關注分開。架構檔案會呈現相關者關注的所有內容，會以建構的方式表示，另外也會用各相關者關注的角度來描述軟件的架構[12]。這種分開來的說明稱為架構視圖，例如4+1架構視圖。
質素導向：傳統的軟件設計方法（例如傑克遜結構化編程）是依需求的機能以及資料在系統中流動的方式所驅動，不過目前的見解[4]:26–28是軟件系統的架構和其質素屬性（例如故障容許度、向下相容、可擴充性、可靠度、可維護性、可用性、資料安全等）的關係更高。相關者的關注可以轉換為有關這些質素屬性上的需求，一般會稱為非功能性需求、額外功能性需求、行為需求或質素屬性需求。
重覆的風格：軟件架構和建築類似，在處理一些重覆出現的事務時會發展出標準化的作法。標準化作法有許多不同的名稱，其中也有不同程度的抽象化。常見的術語有架構風格[11]:273–277 、tactic[4]:70–72、參考架構[13][14]及架構模式[4]:203–205。
概念完整性：這是佛瑞德·布魯克斯在寫作《人月神話》一書時提及：軟件系統的架構是有關軟件系統該作什麼以及不該作什麼的實體觀點。這些觀點應和軟件的實現分開。架構師的角色是「觀點的看守者」，確認系統中增加的部份是符合此架構，因此可以保有概念完整性[15]:41–50。
認知制約：程式設計師馬爾文·康威在1967年論文發表了康威定律，其中提到一個組織開發的軟件，其架構會反映其組織架構。佛瑞德·布魯克斯在寫作《人月神話》一書時，就在書上時提到此例子，命名為「康威定律」。
動機
軟件架構是複雜系統「在智力上能理解」（intellectually graspable）的抽象[4]:5–6，此抽象有以下的好處：
- 軟件架構是在系統實現之前，分析軟件系統行為的基礎[2]。不需要實際實現系統，就可確認某一軟件系統符合關係人的需求，這在降低成本以及風險減輕上都很有助益[16]。已針對這類的分析開發了許多的技術，例如軟件架構分析方法（SAAM）、架構權衡分析方法（ATAM），或是針對軟件系統以視覺化的方式來呈現。
- 軟件架構是軟件復用以及決策的基礎[2][4]:35。不論是軟件的軟件架構，或是在軟件架構上的個別策略及決策，若關係人在其他系統中也需要類似的屬性或是機能，就可以重覆使用，因此可以減少設計成本，也減少設計錯誤產生的風險。
- 可以在提早就進行會影響系統開發、佈署以及維護的設計決策[4]:31。若要避免時程逾期或是費用超支，提早做出正確的，高影響性的決策非常重要。
- 有助於和關係人之間的溝通，可以產出一個比較符合各方需求的系統[4]:29–31。在有關複雜系統的溝通時，以關係人的觀點來溝通有助於他們瞭解其提出需求和以此產生的設計決策之間的關係。透過架構，可以在系統實現之前（也比較容易調整的時候）就進行設計決策的溝通。
- 有助於風險管理。軟件架構可以減少風險以及失敗的概率[11]:18。
- 可以降低成本。軟件架構是一種管理複雜IT計劃風險以及成本的方式[17]。
歷史
早在1960年代，諸如艾茲格·迪傑斯特拉就已經涉及軟件架構這個概念了。自1990年代以來，部分由於在Rational Software Corporation和Microsoft內部的相關活動，軟件架構這個概念開始越來越流行起來。
卡內基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡內基·梅隆大學的Mary Shaw和David Garlan於1996年寫了一本叫做Software Architecture perspective on an emerging discipline的書，提出了軟件架構中的很多概念，例如軟件組件、連接器、風格等等。加州大學埃爾文分校的軟件研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。
架構活動
開發軟件架構的過程會和許多的活動有關。軟件架構師一般會和專案經理一起工作，和專案關係人討論架構重要需求、設計軟件架構、評估設計、和設計師及專案關係人溝通、撰寫架構設計的檔案等[18]在軟件架構設計中，有四個核心活動，分別是架構分析、架構合成、架構評估和架構演進[19]。這些核心的架構活動會反覆的出現，也會出現在軟件開發生命週期的初始階段，及後續階段。
架構分析（Architectural analysis）是瞭解計劃的系統要運作的環境，以及決定系統的需求。分析活動的輸入或是需求可以來自專案關係人，也可能會包括以下項目：
- 系統運作時，會進行的事務（機能需求）。
- 系統運作時會需要的非機能需求，例如ISO/IEC 25010:2011標準中定義的可靠度、可操作性、效能效率、安全性，和相容性[20]。
- 開發時間相關的非機能需求，例如ISO 25010:2011標準中定義的維護性及移轉性[20]。
- 業務需求以及系統中可能會隨時間變化的環境背景，例如法令、社會、金融、競爭性及技術考量[21]。
分析活動的產出是在軟件系統架構上有相關影響的需求，這些稱為是架構重要需求（architecturally significant requirements）[22]。
架構合成（Architectural synthesis）或架構設計是指產生架構的過程。針對在架構分析時產生的架構重要需求、設計的目前狀態、及評估活動的結構，可以進行設計，也可以針對設計進行改善[19][4]:311–326。
架構評估（Architecture evaluation）是在分析過程中確認現有設計整體（或其部份）滿足各需求程度的程式。架構評估的時機可以在架構設計師進行設計決策中的時候，部份設計已完成時，細節設計完成後，或是系統已架設完成之後。有些分析軟件架構的技術，例如架構權衡分析方法（ATAM）及Tiny Architectural Review Approach（TARA）等[23]。有些可以比較這些技術的框架，例如SARA Report[16]及《架構評審：實務及經驗》（Architecture Reviews: Practice and Experience）[24]。
架構演進（Architecture evolution）是指維護已有的軟件架構並且調整，以符合環境及需求變化的過程。軟件架構提供軟件系統的基本架構，其演進及維護必然會影響軟件基礎架構。因此，架構演進一方面關注的是加入新的功能，另一方面也要維護原有的機能以及系統行為。
架構設計需要關鍵性的支援活動。這些支援活動也和核心的軟件架構過程中一起出現。這些支援活動可以協助軟件架構師進行分析、合成、評估及演進。例如軟件架構師需要在分析階段搜集資訊、進行決策，並且撰寫檔案。這些活動包括知識管理、交流、設計推理、決策以及撰寫檔案。
- 知識管理及交流（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的基本構成包括組件、連接器和組態。
軟件架構的敘述常會整理成視圖模型（view model），如同在建築學中的不同種類的藍圖。每一種視圖會着重一些系統的事務，依循其約定的觀點（viewpoint），觀點是指為了要以特定關係人（stakeholder）及其關注點的角度說明系統架構，因此針對標示、模型、分析技巧的說明方式的規範（ISO/IEC 42010）。觀點不但指定框架的關注點，也指定說明的方式、使用的模型、使用的習慣，以及可以和其他視圖維持一致性的規則。
以下是一些可能的視圖：
- 功能/邏輯視圖
- 代碼視圖
- 開發/結構視圖
- 並列/過程/線程視圖
- 物理/部署視圖
- 用戶動作/反饋視圖
目前已開發了許多描述軟件架構的語言，但是大家對於要用何種的符號集和視圖系統，還沒有達成共識。一些人相信UML將建立軟件架構視圖的標準。
架構框架（architecture framework）可以定義為「特定應用或/及特定群體在敘述架構時的習慣，原則以及實務」[28]（ISO/IEC 42010）。框架一般會用一個或多個視圖或ADL來表示。架構框架的例子有：MODAF、開放組體系結構框架、Kruchten的4+1架構視圖、RM-ODP等。
架構模式是針對在特定情境下軟件架構上的常見問題，通用性，可複用的解決方案。 架構模式也像設計模式一樣有對應的檔案。
架構模式的概念類似傳統的建築，軟件架構風格是有關架構的特定作法，有各自的特徵。
| “ | 架構模式定義：「由許多結構性組織模式形成成的系統家族：其中許多組件以及連結方式的字彙，也有一些彼此組合上的限制。」[29] | ” |
| “ | 架構模式是在設計決策及限制上上可復用的「包裹」，可以應用在一架構上，以產生想要的特性。[30] | ” |
有許多知名的架構模式及風格，舉例如下：
- 黑板
- 主從式架構（二層結構、三層結構、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]等方式就是要利用需求以及架構之間的協同關係。
- 系統架構
- 系統架構一開始是應用在描述系統（包括硬件和軟件）的架構。系統架構主要關注的是軟件和硬件的整合，組成完成，可以正確運作的裝置。系統架構也可能是指更廣義而複雜之系統的架構，可能是技術、社會技術或是純社會的系統。
參考文獻
相關條目
.gif){kind=small}
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
