軟體架構描述

编辑

主條目：軟體架構描述（英语：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）等。

架構模式

编辑

主条目：架构模式

架构模式是針對在特定情境下軟體架構上的常見問題，通用性，可複用的解決方案。

架构模式也像设计模式一樣有對應的文件。

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

“

架构模式定義：「由許多結構性組織模式形成成的系統家族：其中許多組件以及連結方式的字彙，也有一些彼此組合上的限制。」[29]

”

“

架构模式是在設計決策及限制上上可復用的「包裹」，可以應用在一架構上，以產生想要的特性。[30]

”

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

黑板

主從式架構（二層結構、三层结构（英语：Three-tier (computing)）、n-tier（英语：n-tier），雲端運算會有這類風格）

基于组件的软件工程

資料庫中心（英语：Database-centric architecture）

事件驅動（英语：Event-driven architecture）（或隐式调用（英语：Implicit invocation））

抽象化（或多层架构）

微服務

单层系统、單體式應用程式

MVC（Model–view–controller）

對等網路（P2P）

管道

插件

表现层状态转换（REST）

規則為基礎的系統（英语：Rule-based system）

面向服务的体系结构

無共享架構（英语：Shared nothing architecture）

空間為基礎的架構（英语：Space-based architecture）

单层系统

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

軟體架構和敏捷開發

编辑

主条目：敏捷開發

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

軟體架構腐蝕

编辑

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

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

針對軟體架構腐蝕，有提出有許多的處理方法：

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

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

軟體架構恢復

编辑

主条目：軟體架構恢復

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

軟體架構評估

编辑

有數種評估軟體架構的方法：軟體架構分析方法（SAAM）在在1990年中期提出，是第一個有文件的軟體架構評估方法。架構權衡分析方法（英语：architecture tradeoff analysis method）（ATAM）是由軟體架構分析方法擴展，是以情境為其基礎的評估方法。中間設計的主動評審（Active Reviews for Intermediate Designs）簡稱ARID，是在軟體架構的中間階段進行評估，不需要完整的軟體架構[36]。此方法由美國軟體工程研究所（英语：Software Engineering Institute）（SEI）所提出，結合了前面兩種方法的觀點，以及主動設計評審（active design reviews）的作法[37]。