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

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

將軟體架構文档化有助於和專案關係人英语Project stakeholder之間的溝通,在高層設計時就可以提早進行決策,也可以在各專案之間復用設計組件[4]:29–35

介绍

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

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

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

範圍

软件架构的範圍有許多不同的定義[5]

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

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

特點

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

眾多的關係人:软件架构需配合許多的關係人(stakeholder),例如業務經理、部門主管、使用者及運營商。每一個關係人都有各自關注的內容。在設計系統中,如何平衡這些關注,並展示他們所關注的訊息,也是一個重點[4]:29–31。因此,軟體架構中就包括了處理眾多的關注及關係人,因此在本質上就是跨領域的。

关注点分离:架構師降低複雜度的可行方式,就是將驅動設計的各关注分開。架構文件會呈現相關者關注的所有內容,會以建構的方式表示,另外也會用各相關者關注的角度來描述軟體的架構[12]。這種分開來的說明稱為架構視圖,例如4+1架構視圖

品質導向:傳統的软件设计方法(例如杰克逊结构化编程)是依需求的機能以及資料在系統中流動的方式所驅動,不過目前的見解[4]:26–28是軟體系統的架構和其品質屬性(例如故障容許度向下兼容可擴充性英语extensibility可靠度可維護性英语maintainability可用性、資料安全等)的關係更高。相關者的關注可以轉換為有關這些品質屬性上的需求,一般會稱為非功能性需求、額外功能性需求、行為需求或品質屬性需求。

重覆的風格:軟體架構和建築類似,在處理一些重覆出現的事務時會發展出標準化的作法。標準化作法有許多不同的名稱,其中也有不同程度的抽象化。常見的術語有架構風格[11]:273–277 、tactic[4]:70–72參考架構英语reference architecture[13][14]架构模式[4]:203–205

概念完整性:這是佛瑞德·布魯克斯在寫作《人月神話》一書時提及:軟體系統的架構是有關軟體系統該作什麼以及不該作什麼的實體觀點。這些觀點應和軟體的實現分開。架構師的角色是「觀點的看守者」,確認系統中增加的部份是符合此架構,因此可以保有概念完整性[15]:41–50

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

動機

软件架构是複雜系統「在智力上能理解」(intellectually graspable)的抽象[4]:5–6,此抽象有以下的好處: