標籤: 暫無標籤

架構,jià gòu。人們對一個結構內的元素及元素間關係的一種主觀映射的產物。也可指構築,建造。

1詞語解釋

【名稱】:架構 :
【拼音】:jià gòu  
人們對一個結構內的元素及元素間關係的一種主觀映射的產物。

2詳細解釋

構築 建造
清 查慎行 《立秋後一日遊行宮后苑賜宴恭紀》詩之二:「岩壑不須多架搆,下因流水上因山。」
簡介
(software architecture)是一系列相關的抽象模式,用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段,這些抽象組件被細化為實際的組件,比如具體某個類或者對象。在面向對象領域中,組件之間的連接通常用介面(計算機科學)來實現。 軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標,作為繪圖員畫圖的基礎一樣,一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念,多數工程師(尤其是經驗不多的工程師)會從直覺上來認識它,但要給出精確的定義很困難。特別是,很難明確地區分設計和構架:構架屬於設計的一方面,它集中於某些具體的特徵。
在「軟體構架簡介」中,David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次:「在計算的演算法和數據結構之外,設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構;通信、同步和數據訪問的協議;設計元素的功能分配;物理分佈;設計元素的組成;定標與性能;備選設計的選擇。」【GS93】
但構架不僅是結構;IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」【IEEE98】。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮,而且還在系統的用戶環境和開發環境中對系統進行整體考慮,即同時注重對外部的考慮。
在 Rational Unified Process 中,軟體系統的構架(在某一給定點)是指系統重要構件的組織或結構,這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說,軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化,模塊之間的交互,用戶界面風格,對外介面方法,創新的設計特性,以及高層事物的對象操作、邏輯和流程。
歷史
早在1960年代,諸如E·W·戴克斯特拉就已經涉及軟體架構這個概念了。自1990年代以來,部分由於在 Rational Software Corporation 和Microsoft內部的相關活動,軟體架構這個概念開始越來越流行起來。
卡內基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡內基·梅隆大學的Mary Shaw和David Garlan於1996年寫了一本叫做 Software Architecture perspective on an emerging discipline的書,提出了軟體架構中的很多概念,例如軟體組件、連接器、風格等等。 加州大學埃爾文分校的軟體研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。
計算機軟體的歷史開始於五十年代,歷史非常短暫,而相比之下建築工程則從石器時代就開始了,人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點,一是建築風格,二是建築模式。獨特的建築風格和恰當選擇的建築模式,可以使它成為一個獨一無二的建築。
下面的照片顯示了中美洲古代瑪雅建築,Chichen-Itza大金字塔,九個巨大的石級堆壘而上,九十一級台階(象徵著四季的天數)奪路而出,塔頂的神殿聳入雲天。所有的數字都如日曆般嚴謹,風格雄渾。難以想象這是石器時代的建築物。
圖1、古瑪雅建築

  圖1、古瑪雅建築

圖1位於墨西哥Chichen-Itza(在瑪雅語中chi意為嘴chen意為井)的古瑪雅建築。(攝影:作者)  軟體與人類的關係是架構師必須面對的核心問題,也是自從軟體進入歷史舞台之後就出現的問題。與此類似地,自從有了建築以來,建築與人類的關係就一直是建築設計師必須面對的核心問題。英國首相丘吉爾說,我們構造建築物,然後建築物構造我們(We shape our buildings, and afterwards our buildings shape us)。英國下議院的會議廳較狹窄,無法使所有的下議院議員面向同一個方向入座,而必須分成兩側入座。丘吉爾認為,議員們入座的時候自然會選擇與自己政見相同的人同時入座,而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。
在軟體設計界曾經有很多人認為功能是最為重要的,形式必須服從功能。與此類似地,在建築學界,現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從於功能(Forms follows function)。
幾乎所有的軟體設計理念都可以在浩如煙海的建築學歷史中找到更為遙遠的歷史迴響。最為著名的,當然就是模式理論和XP理論。
種類
根據我們關注的角度不同,可以將架構分成三種:
·邏輯架構、軟體系統中元件之間的關係,比如用戶界面,資料庫,外部系統介面,商業邏輯元件,等等。
圖2、一個邏輯架構的例子

  圖2、一個邏輯架構的例子

圖2 一個邏輯架構的例子 從上面這張圖中可以看出,此系統被劃分成三個邏輯層次,即表象層次,商業層次和數據持久層次。每一個層次都含有多個邏輯元件。比如WEB伺服器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。
·物理架構、軟體元件是怎樣放到硬體上的。
比如下面這張物理架構圖描述了一個分佈於北京和上海的分散式系統的物理架構,圖中所有的元件都是物理設備,包括網路分流器、代理伺服器、WEB伺服器、應用伺服器、報表伺服器、整合伺服器、存儲伺服器。主機等等。
圖3、一個物理架構的例子

  圖3、一個物理架構的例子

圖3 一個物理架構的例子  ·系統架構、系統的非功能性特徵,如可擴展性、可靠性、強壯性、靈活性、性能等。
系統架構的設計要求架構師具備軟體和硬體的功能和性能的過硬知識,這一工作無疑是架構設計工作中最為困難的工作。
此外,從每一個角度上看,都可以看到架構的兩要素:元件劃分和設計決定。
首先,一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上,以及這些元件如何為整個系統的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻,是非常重要的信息。
其次,進行軟體設計需要做出的決定中,必然會包括邏輯結構、物理結構,以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦做出,就很難更改的。
構架視圖
我們決定以多種構架視圖來表示軟體構架。每種構架視圖針對於開發流程中的涉眾(例如最終用戶、設計人員、管理人員、系統工程師、維護人員等)所關注的特定方面。構架視圖顯示了軟體構架如何分解為構件,以及構件如何由連接器連接來產生有用的形式 【PW92】,由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。
構架重點
雖然以上視圖可以表示系統的整體設計,但構架只同以下幾個具體方面相關: 模型的結構,即組織模式,例如分層。
基本元素,即關鍵用例、主類、常用機制等,它們與模型中的各元素相對。
幾個關鍵場景,它們表示了整個系統的主要控制流程。
記錄模塊度、可選特徵、產品線狀況的服務。
構架視圖在本質上是整體設計的抽象或簡化,它們通過捨棄具體細節來突出重要的特徵。在考慮以下方面時,這些特徵非常重要:
系統演進,即進入下一個開發周期。
在產品線環境下復用構架或構架的一部分。
評估補充質量,例如性能、可用性、可移植性和安全性。
向團隊或分包商分配開發工作。
決定是否包括市售構件。
插入範圍更廣的系統。
構架模式示例
【BUS96】 根據構架模式最適用的系統的特徵將其分類,其中一個類別處理更普遍的結構問題。下表顯示了 【BUS96】 中所提供的類別和這些類別所包含的模式。
類別
模式
結構
管道和過濾器

黑板

分散式系統
代理
交互系統
模型-視圖-控制器
表示-抽象-控制

自適應系統
反射
微核

軟體構架是一個容易理解的概念,多數工程師(尤其是經驗不多的工程師)會從直覺上來理解,很難明確地區分設計和構架:構架屬於設計的一方面,它集中於某些具體的特徵。
在「軟體構架簡介」中,David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次:「在計算的演算法和數據結構之外,設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構;通信、同步和數據訪問的協議;設計元素的功能分配;物理分佈;設計元素的組成;定標與性能;備選設計的選擇。」【GS93】
但構架不僅是結構;IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」【IEEE98】。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮,而且還在系統的用戶環境和開發環境中對系統進行整體考慮,即同時注重對外部的考慮。
在 Rational Unified Process 中,軟體系統的構架(在某一給定點)是指系統重要構件的組織或結構,這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
為闡明其含義,下面將詳述其中的兩個;完整說明請參見 【BUS96】。模式以下列廣泛使用的形式來表示:
模式名
環境
問題
影響,描述應考慮的不同問題方面
解決方案
基本原理
結果環境
示例
模式名
環境
需要進行結構分解的大系統。
問題
必須處理不同抽象層次的問題的系統。例如:硬體控制問題、常見服務問題和針對於不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題(可能會不一致)。
影響
系統的某些部分應當是可替換的
構件中的變化不應波動
相似的責任應歸為一組
構件大小 -- 複雜構件可能要進行分解
解決辦法
將系統分成構件組,並使構件組形成層疊結構。使上層只使用下層(決不使用上層)提供的服務。盡量不使用非緊鄰下層提供的服務(不跳層使用服務,除非中間層只添加通過構件)。
示例:
1. 通用層
通用層

  通用層

嚴格的分層構架規定設計元素(類、構件、包、子系統)只能使用下層提供的服務, 服務可以包括事件處理、錯誤處理、資料庫訪問等等。 相對於記錄在底層的原始操作系統級調用,它包括更明顯的機制。
2. 業務系統層
業務系統層

  業務系統層

右圖顯示了另一個分層示例,其中有垂直特定應用層、水平層和基礎設施層。注意:此處的目標是採用非常短的業務「煙囪」並實現各種應用程序間的通用性。 否則,就可能有多個人解決同一問題,從而導致潛在的分歧。
有關該模式的深入討論,請參見指南:分層。
環境
沒有解決問題的確定方法(演算法)或方法不可行的領域。例如 AI 系統、語音識別和監視系統。
問題
多個問題解決顧問(知識顧問)必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問,使他們可以評估自己是否可以參與解決方案的查找併發布其工作結果。
影響
知識顧問參與解決問題的順序不是確定的,這可能取決於問題解決策略
不同顧問的輸入(結果或部分解決方案)可能有不同的表示方式
各顧問並不直接知道對方的存在,但可以評估對方發布的工作
解決辦法
多名知識顧問都可訪問一個稱為「黑板」的共享資料庫。黑板提供監測和更新其內容的介面。控制模塊/對象激活遵循某種策略的顧問。激活后,顧問查看黑板,以確定它是否能參與解決問題。如果顧問決定它可以參與,控制對象就可以允許顧問將其部分(或最終)解決方案放置於黑板上。
示例:
使用 UML 建模的結構或靜態視圖

  使用 UML 建模的結構或靜態視圖

以上顯示了使用 UML 建模的結構或靜態視圖。 它將成為參數化協作的一部分,然後會綁定到實參上對模式進行實例化。
構架風格
軟體構架(或僅是構架視圖)可以具有名為構架風格的屬性,該屬性減少了可選的形式,並使構架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構件或連接器作為基本構件來定義。對給定系統,某些樣式可作為構架描述的一部分記錄在構架風格指南(Rational Unified Process 中設計指南文檔的一部分)中。樣式在構架的可理解性與完整性方面起著主要的作用。
構架設計流程
在 Rational Unified Process 中,構架主要是分析設計工作流程的結果。當項目再次進行此工作流程時,構架將在一次又一次迭代中不斷演化、改進、精鍊。由於每次迭代都包括集成和測試,所以在交付產品時,構架就相當強壯了。構架是精化階段各次迭代的重點,構架的基線通常會在此階段結束時確定。
架構師分類
按照職責的不同,架構師通常分為企業架構師、信息架構師、資料庫架構師、業務架構師、技術架構師、系統架構師等。
上一篇[片霧烈火]    下一篇 [王若琪]

相關評論

同義詞:暫無同義詞