architecture[軟體結構]

architecture指結構。在EDA的PLD中用於標識結構體。通常情況下它也指軟體結構。

種類

根據我們關注的角度不同，可以將架構分成三種：

1.邏輯架構、軟體系統中元件之間的關係，比如用戶界面、資料庫、外部系統接口、商業邏輯元件等等。

一個邏輯架構的例子

一個物理架構的例子

從上面這張圖中可以看出，此系統被劃分成三個邏輯層次，即表象層次，商業層次和數據持久層次。每一個層次都含有多個邏輯元件。比如WEB伺服器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。

2. 物理架構、軟體元件是怎樣放到硬體上的。　比如下面這張物理架構圖描述了一個分布於北京和上海的分散式系統的物理架構，圖中所有的元件都是物理設備，包括網路分流器、代理伺服器、WEB伺服器、套用伺服器、報表伺服器、整合伺服器、存儲伺服器、主機等等。

3.系統架構、系統的非功能性特徵，如可擴展性、可靠性、強壯性、靈活性、性能等。　系統架構的設計要求架構師具備軟體和硬體的功能和性能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。　此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。 　首先，一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常重要的信息。　其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。　根據作者的經驗，一個基於資料庫的系統架構，有多少個數據表，就會有多少頁的架構設計文檔。比如一個中等的資料庫套用系統通常含有一百個左右的數據表，這樣的一個系統設計通常需要有一百頁左右的架構設計文檔。

構架描述

為了討論和分析軟體構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在 Rational Unified Process 中，軟體構架文檔記錄有這種描述。

構架視圖

我們決定以多種構架視圖來表示軟體構架。每種構架視圖針對於開發流程中的涉眾（例如最終用戶、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。

構架視圖顯示了軟體構架如何分解為構件，以及構件如何由連線器連線來產生有用的形式 【PW92】，由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。典型

視圖集

構架由許多不同的構架視圖來表示，這些視圖本質上是以圖形方式來摘要說明“在構架方面具有重要意義”的模型元素。在 Rational Unified Process 中，您將從一個典型的視圖集開始，該視圖集稱為“4+1 視圖模型”【KRU95】。它包括：

用例視圖：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。

邏輯視圖：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。

實施視圖：包括實施模型及其從模組到包和層的組織形式的概覽。 同時還描述了將邏輯視圖中的包和類向實施視圖中的包和模組分配的情況。它是實施模型的子集。

進程視圖：包括所涉及任務（進程和執行緒）的描述，它們的互動和配置，以及將設計對象和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該視圖。在 Rational Unified Process 中，它是設計模型的子集。

配置視圖：包括對最典型的平台配置的各種物理節點的描述以及將任務（來自進程視圖）向物理節點分配的情況。只有在分散式系統中才需要該視圖。它是部署模型的一個子集。 構架視圖記錄在軟體構架文檔中。您可以構建其他視圖來表達需要特別關注的不同方面：用戶界面視圖、安全視圖、數據視圖等等。對於簡單系統，可以省略 4+1 視圖模型中的一些視圖。

構

構架重點

雖然以上視圖可以表示系統的整體設計，但構架只同以下幾個具體方面相關：

模型的結構，即組織模式，例如分層。 基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。 幾個關鍵場景，它們表示了整個系統的主要控制流程。 記錄模組度、可選特徵、產品線狀況的服務。

構架視圖在本質上是整體設計的抽象或簡化，它們通過捨棄具體細節來突出重要的特徵。在考慮以下方面時，這些特徵非常重要：系統演進，即進入下一個開發周期。 在產品線環境下復用構架或構架的一部分。 評估補充質量，例如性能、可用性、可移植性和安全性。 向團隊或分包商分配開發工作。 決定是否包括市售構件。 插入範圍更廣的系統。

構架模式

構架模式是解決復發構架問題的現成形式。構架框架或構架基礎設施（中間件）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對於特定的領域：命令和控制、MIS、控制系統等等。構架模式示例

【BUS96】 根據構架模式最適用的系統的特徵將其分類，其中一個類別處理更普遍的結構問題。下表顯示了 【BUS96】 中所提供的類別和這些類別所包含的模式。

類別	模式
結構	層
管道和過濾器
黑板
分散式系統	代理
互動系統	模型-視圖-控制器
表示-抽象-控制
自適應系統	反射
微核

相關信息

軟體構架

軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連線則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連線通常用接口_(計算機科學)來實現。

軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

測試軟體架構

軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。

在“軟體構架簡介”中，David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：“在計算的算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協定；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。”

但構架不僅是結構；IEEE Working Group on Architecture 把其定義為“系統在其環境中的最高層概念”【IEEE98】。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。在 Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過接口與不斷減小的構件與接口所組成的構件進行互動。

從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管理軟體產品的高級設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。

是一般而言，軟體系統的架構（Architecture）有兩個要素：

規則架構師的角色

它是一個軟體系統從整體到部分的最高層次的劃分。　一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。　詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。

建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。　在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關係統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

架構師

培養構架師

軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。

這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程式設計師會負責一些架構方面的工作。在一個部門中，最有經驗的項目經理會負責一些架構方面的工作。

但是，越來越多的公司體認到架構工作的重要性，並且在不同的組織層次上設定專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。