软件架构

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，開發系統以及計劃進行的基础，可以列出開發團隊需要完成的任務。

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

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

介绍
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，或者系统架构师陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序员商谈实现技巧，外观和风格。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

範圍
软件架构的範圍有許多不同的定義：

• 巨觀系統架構：這是指高階的軟體系統抽象化，其中包括了許多的組件（component），以及描述各模組之間關係的「連接器」（connector）。
• 重要的東西，無論是什麼都可以：這是指軟體架構師需要根據專案判斷，哪些決策對系統以及專案關係人有高度影響。
• 瞭解系統環境的基礎。
• 一些人們認為不容易改變的事物：設計架構是在軟體生命週期一開始就要進行的，軟體架構師需專注在一些「一開始就要正確」的決策，依照這個思路，若有些問題是可逆的，軟體架構上的問題就可以轉換為非架構性的問題。此見解引發了大量有關軟體架構知识管理的研究。

在軟體架構、設計、需求工程之間，沒有具體明顯的分界。這些是「一連串意圖的結合」，從高階的設計意向到低階的設計細節。

特點
软件架构有以下這些特點：

眾多的關係人：软件架构需配合許多的關係人（stakeholder），例如業務經理、部門主管、使用者及運營商。每一個關係人都有各自關注的內容。在設計系統中，如何平衡這些關注，並展示他們所關注的訊息，也是一個重點。這種分開來的說明稱為架構視圖，例如4+1架構視圖。

品質導向：傳統的软件设计方法（例如杰克逊结构化编程）是依需求的機能以及資料在系統中流動的方式所驅動，不過目前的見解及架构模式。

認知制約：程式設計師马尔文·康威在1967年論文發表了康威定律，其中提到一個組織開發的軟體，其架構會反映其組織架構。佛瑞德·布魯克斯在寫作《人月神話》一書時，就在書上時提到此例子，命名為「康威定律」。

動機
软件架构是複雜系統「在智力上能理解」（intellectually graspable）的抽象。已針對這類的分析開發了許多的技術，例如軟體架構分析方法（SAAM）、（ATAM），或是針對軟體系統以視覺化的方式來呈現。

• 软件架构是軟體復用以及決策的基礎。

历史
早在1960年代，诸如艾茲格·迪傑斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在和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）或架構設計是指產生架構的過程。針對在架構分析時產生的架構重要需求、設計的目前狀態、及評估活動的結構，可以進行設計，也可以針對設計進行改善。有些可以比較這些技術的框架，例如SARA Report。

架構演進（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來表示。架構框架的例子有：、开放组体系结构框架、Kruchten的4+1架構視圖、等。

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

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

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

• 黑板
• 主從式架構（二層結構、、，雲端運算會有這類風格）
• 基于组件的软件工程

*

• （或）
• 抽象化（或多层架构）
• 微服務
• 单层系统、單體式應用程式
• MVC（Model–view–controller）
• 對等網路（P2P）
• 管道
• 插件
• 表现层状态转换（REST）

*

• 面向服务的体系结构

*
*

• 单层系统

有些人將架构模式和架构風格視為是同一件事，有時則是將架构風格視為是架构模式的實例，不過將架构模式和架构風格都是架構師常用的語言，在描述系統類型時「提供共用的語言」 ，其中包括敏捷式的（DSDM），其中強制一個「基礎」階段，只要列出「夠用的」架構基礎即可。《IEEE软件》曾特別探討敏捷和軟體架構之間的關係。

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

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

軟體架構恢復
軟體架構恢復（重建，或逆向工程）包括從已有資訊（包括程式實現以及已有文件）中找到軟體架構的方式以及技巧。若是遇到軟體的文件過舊、架構腐蝕（軟體的架構和後來的實現及維護不一致），又需要進行決策時，就需要進行軟體架構恢復。常見的技巧包括靜態程序分析，軟體架構恢復也是軟體智能實務中的一部份。
軟體架構評估
有數種評估軟體架構的方法：軟體架構分析方法（SAAM）在在1990年中期提出，是第一個有文件的軟體架構評估方法，在1990年中期提出，一開始提出的目的是分析系統的可修改性，但也可用在測試任何非機能性的領域。（ATAM）是由軟體架構分析方法擴展，是以情境為其基礎的評估方法。中間設計的主動評審（Active Reviews for Intermediate Designs）簡稱ARID，是在軟體架構的中間階段進行評估，不需要完整的軟體架構。此方法由（SEI）所提出，結合了前面兩種方法的觀點，以及主動設計評審（active design reviews）的作法。

相關領域
設計
软件架构是设计的一部份，不過不是所有的設計都和架構有關，架構設計和細節設計的分界在於「局部性準則」（Locality Criterion）。需求工程會展開需求获取、需求分析、软件需求说明、、需求可追蹤性及需求管理。需求工程和軟體架構都和專案關係人的關注、需要及期待有關。

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

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

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

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

参考文献
引用
来源

• Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice. Addison Wesley, Reading 1998 ISBN 0-201-19930-0（gives a good overview of architectural concepts）
• Philippe Kruchten: Architectural Blueprints - the 4+1 View Model of Software Architecture. In: IEEE Software. 12 (6) November 1995, pp. 42-50 (also available online at the [http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf Rational website] （PDF））
• James O. Coplien: Multi-Paradigm Design in C++. Addison Wesley, Reading 1998 ISBN 0-201-82467-1（outlines all reasonable design approaches possible in C++, which is a particularly rich language but difficult for beginners）

相關條目

• 软件工程

*

• 軟體架構分析方法
• 軟體智-{}-能
• ArchiMate
• 架构模式
• 反面模式

*

• C4模型
• 计算机系统结构

*

• （DRDA）
• 系統架構
• 系統設計

*
*

• 系统架构师