跳转到内容

软件架构

本页使用了标题或全文手工转换
维基百科，自由的百科全书
（重定向自軟體架構）


软件开发
核心行动
范式与模式
方法论与框架
支持行为
实践
工具
标准与知识体系

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性[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.wikipedia.org/w/index.php?title=软件架构&oldid=84141585”
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy