-
架構
(計算機術語)
鎖定
- 中文名
- 架構
- 外文名
- Software architecture
- 別 名
- 軟件架構
架構特性
可以動態更新的Active Directory 架構。應用程序可以使用新的屬性和類擴展該架構,並能立刻使用該擴展。通過在Active Directory 中創建或修改存儲在 Active Directory 中的架構對象來完成架構的更新。與Active Directory 中的所有對象一樣,架構對象能訪問控制列表,因此只有授權的用户才可以更改架構。
架構軟件架構
軟件架構(software architecture)是一系列相關的抽象模式,用於指導大型軟件系統各個方面的設計。 軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段,這些抽象組件被細化為實際的組件,比如具體某個類或者對象。在面向對象領域中,組件之間的連接通常用接口(計算機科學)來實現。 軟件體系結構是構建計算機軟件實踐的基礎。與建築師設定建築項目的設計原則和目標,作為繪圖員畫圖的基礎一樣,一個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客户需求的實際系統設計方案的基礎。
軟件構架是一個容易理解的概念,多數工程師(尤其是經驗不多的工程師)會從直覺上來認識它,但要給出精確的定義很困難。特別是,很難明確地區分設計和構架:構架屬於設計的一方面,它集中於某些具體的特徵。
在“軟件構架簡介”中,David Garlan 和 Mary Shaw 認為軟件構架是有關如下問題的設計層次:“在計算的算法和數據結構之外,設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構;通信、同步和數據訪問的協議;設計元素的功能分配;物理分佈;設計元素的組成;定標與性能;備選設計的選擇。”
但構架不僅是結構。IEEE Working Group on Architecture 把其定義為“系統在其環境中的最高層概念”。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮,而且還在系統的用户環境和開發環境中對系統進行整體考慮,即同時注重對外部的考慮。
從和目的、主題、材料和結構的聯繫上來説,軟件架構可以和建築物的架構相比擬。一個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來實施和管理軟件產品的高級設計。軟件架構師定義和設計軟件的模塊化,模塊之間的交互,用户界面風格,對外接口方法,創新的設計特性,以及高層事物的對象操作、邏輯和流程。
1.它是一個軟件系統從整體到部分的最高層次的劃分。一個系統通常是由元件組成的,而這些元件如何形成、相互之間如何發生作用,則是關於這個系統本身結構的重要信息。詳細地説,就是要包括架構元件(Architecture Component)、聯結器(Connector)、任務流(Task-flow)。所謂架構元素,也就是組成系統的核心"磚瓦",而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果,任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
2.建造一個系統所作出的最高層次的、以後難以更改的,商業的和技術的決定。在建造一個系統之前會有很多的重要決定需要事先作出,而一旦系統開始進行詳細設計甚至建造,這些決定就很難更改甚至無法更改。顯然,這樣的決定必定是有關系統設計成敗的最重要決定,必須經過非常慎重的研究和考察。
架構歷史
早在1960年代,諸如E·W·戴克斯特拉就已經涉及軟件架構這個概念了。自1990年代以來,部分由於在 Rational Software Corporation 和Microsoft內部的相關活動,軟件架構這個概念開始越來越流行起來。
卡內基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡內基·梅隆大學的Mary Shaw和David Garlan於1996年寫了一本叫做 Software Architecture perspective on an emerging discipline的書,提出了軟件架構中的很多概念,例如軟件組件、連接器、風格等等。 加州大學埃爾文分校的軟件研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。
計算機軟件的歷史開始於五十年代,歷史非常短暫,而相比之下建築工程則從石器時代就開始了,人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點,一是建築風格,二是建築模式。獨特的建築風格和恰當選擇的建築模式,可以使它成為一個獨一無二的建築。
下面的照片顯示了中美洲古代瑪雅建築,Chichen-Itza大金字塔,九個巨大的石級堆壘而上,九十一級台階(象徵着四季的天數)奪路而出,塔頂的神殿聳入雲天。所有的數字都如日曆般嚴謹,風格雄渾。難以想象這是石器時代的建築物。
圖1位於墨西哥Chichen-Itza(在瑪雅語中chi意為嘴chen意為井)的古瑪雅建築。(攝影:作者) 軟件與人類的關係是架構師必須面對的核心問題,也是自從軟件進入歷史舞台之後就出現的問題。與此類似地,自從有了建築以來,建築與人類的關係就一直是建築設計師必須面對的核心問題。英國首相丘吉爾説,我們構造建築物,然後建築物構造我們(We shape our buildings, and afterwards our buildings shape us)。英國下議院的會議廳較狹窄,無法使所有的下議院議員面向同一個方向入座,而必須分成兩側入座。丘吉爾認為,議員們入座的時候自然會選擇與自己政見相同的人同時入座,而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。
在軟件設計界曾經有很多人認為功能是最為重要的,形式必須服從功能。與此類似地,在建築學界,現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從於功能(Forms follows function)。
架構設計目標
正如同軟件本身有其要達到的目標,軟件架構設計要達到如下的目標:
1.可靠性(Reliable)。軟件系統對於用户的商業經營和管理來説極為重要,因此軟件系統必須非常可靠。
2.安全性(Secure)。軟件系統所承擔的交易的商業價值極高,系統的安全性非常重要。
5.可伸縮 (Extensible)。在新技術出現的時候,一個軟件系統應當允許導入新技術,從而對現有系統進行功能和性能的擴展。
7.客户體驗(Customer Experience)。軟件系統必須易於使用。
8.市場時機(Time to Market)。軟件用户要面臨同業競爭,軟件提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。
架構種類
根據我們關注的角度不同,可以將架構分成三種:
1.邏輯架構、軟件系統中元件之間的關係,比如用户界面,數據庫,外部系統接口,商業邏輯元件,等等。如圖是一個邏輯架構的例子 從上面這張圖中可以看出,此係統被劃分成三個邏輯層次,即表象層次,商業層次和數據持久層次。每一個層次都含有多個邏輯元件。比如WEB服務器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。
此外,從每一個角度上看,都可以看到架構的兩要素:元件劃分和設計決定。首先,一個軟件系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上,以及這些元件如何為整個系統的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻,是非常重要的信息。其次,進行軟件設計需要做出的決定中,必然會包括邏輯結構、物理結構,以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦做出,就很難更改的。為了討論和分析軟件構架,必須首先定義構架表示方式,即描述構架重要方面的方式。在 Rational Unified Process 中,軟件構架文檔記錄有這種描述。
我們決定以多種構架視圖來表示軟件構架。每種構架視圖針對於開發流程中的涉眾(例如最終用户、設計人員、管理人員、系統工程師、維護人員等)所關注的特定方面。構架視圖顯示了軟件構架如何分解為構件,以及構件如何由連接器連接來產生有用的形式 ,由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。
構架由許多不同的構架視圖來表示,這些視圖本質上是以圖形方式來摘要説明“在構架方面具有重要意義”的模型元素。在 Rational Unified Process 中,您將從一個典型的視圖集開始,該視圖集稱為“4+1 視圖模型”。它包括:
進程視圖:包括所涉及任務(進程和線程)的描述,它們的交互和配置,以及將設計對象和類向任務的分配情況。只有在系統具有很高程度的並行時,才需要該視圖。在 Rational Unified Process 中,它是設計模型的子集。
配置視圖:包括對最典型的平台配置的各種物理節點的描述以及將任務(來自進程視圖)向物理節點分配的情況。只有在分佈式系統中才需要該視圖。它是部署模型的一個子集。
基本元素,即關鍵用例、主類、常用機制等,它們與模型中的各元素相對。
幾個關鍵場景,它們表示了整個系統的主要控制流程。
記錄模塊度、可選特徵、產品線狀況的服務。
構架視圖在本質上是整體設計的抽象或簡化,它們通過捨棄具體細節來突出重要的特徵。在考慮以下方面時,這些特徵非常重要:
1.系統演進,即進入下一個開發週期。
2.在產品線環境下複用構架或構架的一部分。
3.評估補充質量,例如性能、可用性、可移植性和安全性。
4.向團隊或分包商分配開發工作。
5.決定是否包括市售構件。
架構構架模式
構架模式是解決複雜構架問題的現成形式。構架框架或構架基礎設施(中間件)是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決,而且通常針對於特定的領域:命令和控制、MIS、控制系統等等。
類別 | 模式 |
結構 | 層 |
管道和過濾器 | |
黑板 | |
分佈式系統 | 代理 |
交互系統 | 模型-視圖-控制器 |
表示-抽象-控制 | |
自適應系統 | 反射 |
微核 |
為闡明其含義,下面將詳述其中的兩個。完整説明請參見 【BUS96】。
模式以下列廣泛使用的形式來表示:模式名、環境、問題、影響,描述應考慮的不同問題方面、解決方案、基本原理、結果環境、示例、模式名層、環境、需要進行結構分解的大系統、問題必須處理不同抽象層次的問題的系統。例如:硬件控制問題、常見服務問題和針對於不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題(可能會不一致)。
示例:
1. 通用層
2. 業務系統層
右圖顯示了另一個分層示例,其中有垂直特定應用層、水平層和基礎設施層。注意:此處的目標是採用非常短的業務“煙囱”並實現各種應用程序間的通用性。 否則,就可能有多個人解決同一問題,從而導致潛在的分歧。
環境:沒有解決問題的確定方法(算法)或方法不可行的領域。例如 AI 系統、語音識別和監視系統。
問題:多個問題解決顧問(知識顧問)必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問,使他們可以評估自己是否可以參與解決方案的查找併發布其工作結果。
影響:知識顧問參與解決問題的順序不是確定的,這可能取決於問題解決策略;不同顧問的輸入(結果或部分解決方案)可能有不同的表示方式;各顧問並不直接知道對方的存在,但可以評估對方發佈的工作
解決辦法:多名知識顧問都可訪問一個稱為“黑板”的共享數據庫。黑板提供監測和更新其內容的接口。控制模塊/對象激活遵循某種策略的顧問。激活後,顧問查看黑板,以確定它是否能參與解決問題。如果顧問決定它可以參與,控制對象就可以允許顧問將其部分(或最終)解決方案放置於黑板上。
示例:
構架風格
軟件構架(或僅是構架視圖)可以具有名為構架風格的屬性,該屬性減少了可選的形式,並使構架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構件或連接器作為基本構件來定義。對給定系統,某些樣式可作為構架描述的一部分記錄在構架風格指南(Rational Unified Process 中設計指南文檔的一部分)中。樣式在構架的可理解性與完整性方面起着主要的作用。
架構構架設計圖
進程視圖:類圖與對象圖(包括任務 - 進程與線程)。
實施視圖:構件圖。
部署視圖:配置圖。
構架設計流程
在 Rational Unified Process 中,構架主要是分析設計工作流程的結果。當項目再次進行此工作流程時,構架將在一次又一次迭代中不斷演化、改進、精煉。由於每次迭代都包括集成和測試,所以在交付產品時,構架就相當強壯了。構架是精化階段各次迭代的重點,構架的基線通常會在此階段結束時確定。
架構架構師
這樣的人就是所謂的架構師(Architect)。在很多公司中,架構師不是一個專門的和正式的職務。通常在一個開發小組中,最有經驗的程序員會負責一些架構方面的工作。在一個部門中,最有經驗的項目經理會負責一些架構方面的工作。
架構師分類