複製鏈接
請複製以下鏈接發送給好友

體系結構

鎖定
體系結構,包括一組部件以及部件之間的聯繫。自1964年G. Amdahl首次提出體系結構這個概念,人們對計算機系統開始有了統一而清晰的認識,為從此以後計算機系統的設計與開發奠定了良好的基礎。近四十年來, 體系結構學科得到了長足的發展, 其內涵和外延得到了極大的豐富。特別是網絡計算技術的發展,使得網絡計算體系結構成為當今一種主要的計算模式結構。
微電子技術的飛速發展使芯片級體系結構研究成為一個挑戰性課題。體系結構與系統軟件,應用軟件,程序設計語言的緊密結合與相互作用也使今天的計算機與以往有很大的不同,並觸發了大量的前沿技術、相關產品開發與基礎研究課題。
中文名
體系結構
外文名
Computer Architecture
分    類
虛擬機,包括解釋器、規則基系統
出現原由
方法和概念來對系統的整體結構
特    點
過濾器之間是相互獨立的

體系結構分類

體系結構風格有9大類:
1. 數據流系統,包括順序批處理、管道和過濾器;
2. 調用-返回系統,包括主程序和子程序、面向對象系統、層次結構
3. 獨立部件,包括通信進程、事件隱式調用
4.虛擬機,包括解釋器、規則基系統;
5. 以數據為中心的系統(庫),包括數據庫、超文本系統黑板系統
6. 特殊領域風格;例如過程控制、模擬器;
7. 特殊結構的風格,例如分佈式處理、狀態轉移系統;
8. 不同風格合成建立的異構結構;
9. 最初始、最基本的主程序/子程序 [1] 

體系結構出現原由

在傳統的程序設計領域中,人們使用流程圖來表達系統的基本功能和實現的具體邏輯,但是,流程圖實際上僅僅是源程序的圖形化表示,無法給系統的分析和開發者提供更多的信息,所以沒有在實際的系統開發過程中得到廣泛的應用。
隨着軟件系統的規模和複雜性的增加,對軟件系統的整體結構(數據和控制的邏輯)進行分析和描述成為大型系統開發的一個不可缺少的重要部分,顯然,使用流程圖是無法達到這個目標的,我們必須使用新的方法和概念來對系統的整體結構進行把握。

體系結構系統分析

系統分析實際上包括兩個階段的工作,首先是需求的分析,也就是説,劃分出系統和環境之間的界面,將所研究(或者是將要開發)的系統和周圍的環境分離,這就是從使用者的觀點,將整個系統作為一個整體來考察。其次是系統的設計,根據系統的整體功能和數據,參考實際的物理系統或者類似的系統,設計實際運行的軟件系統,這一步驟實際上就是體系結構的分析和確定。
從系統工程的觀點看來,任何複雜的系統都是由相對簡單的,在當前所分析的系統層次是原始的基本元素(雖然在更進一步的分析中,這些元素可能具有非常複雜的內部結構)組成的,這些基本元素之間存在複雜的相互作用。所以,軟件系統的分析和設計的基本任務是:確立系統中的基本元素(完成系統的功能所必不可少的成分);確定這些元素之間相互作用的方式(這就是系統的體系結構) [2] 

體系結構結構範式

體系結構管道和過濾器

每個組件具有輸入和輸出的集合,從流中讀出數據作為輸入,產生輸出數據的流。整個系統可以看成多個過濾器複合形成的數據處理組件。
過濾器A
過濾器B
過濾器C
管道
特點:
  • 過濾器之間是相互獨立的(不能共享狀態),其中一個過濾器的操作和行為不能影響另外過濾器的操作和行為,流的傳送沒有副作用。
  • 過濾器對所輸入流的來源和輸出流的去向不關心,不需要知道流的來源和流的去向,來源和去向對於過濾器的數據處理沒有任何影響。
  • 過濾和流的傳送可以是併發的,可以同時有多個流的傳送存在於系統之中。
實例:
一個最著名的實例是unix的shell編程,多個對數據進行處理的程序(組件)通過管道聯結起來,產生總和的效果;還有傳統的編譯器源代碼經過詞法分析語法分析中間代碼生成目標代碼生成等步驟生成輸出的目標代碼。
優點:
  • 整個系統的功能是多個過濾器作用的總和,這樣可以簡化系統的分析和設計,可以經過需求的分析之後將整個系統作為一個過濾器處理,然後再逐步的細化成為多個相互連接的過濾器。
  • 支持組件的重用,同一個過濾器可以多次出現在系統的不同位置。
  • 易於維護和增強,過濾器可以被替換,可以增加新的過濾器到系統中而不改變原有的過濾器,不改變原來系統的基本功能。
  • 本質上的併發性支持,這種體系結構由於本質上是與各個獨立的過濾器的狀態無關的,與並行的流的通過次序也是無關的,所以併發是一個基本的體系結構自然具有的特性。
缺點:
  • 由於過濾器之間本質上是獨立的,所以設計者必須獨立考慮每一個過濾器的輸入、處理和輸出的過程,對於過濾器邏輯上的共同點和相互關係無法在設計中加以體現。
  • 由於這種體系的批處理特性,所以不適合開發和用户交互的應用程序。
  • 系統的多個處理流之間的共同特性無法提取、多個過濾器之間的共同特性也無法提取,所以增加了設計的複雜性。

體系結構面向對象的體系

在這種體系中,數據和數據上的操作被封裝成抽象數據類型或者對象。系統由大量的對象組成,在物理上,對象之間通過函數或者過程調用相互作用;在邏輯上,對象之間通過集成、複合等方式實現設計的複用。
對象D
對象B
對象A
對象E
對象C
對象調用
對象調用
對象調用
類A
類B
類C
類G
對象A
對象E
類F
複合
繼承
特點:
面向對象系統分析和設計的資料已經太多,這裏就不再詳細説明了。
優點:
由於封裝,實現了靈活性和擴充性,隱藏了實現的細節,提高代碼的質量;
使用繼承和多態、提高了軟件的可重用性。
缺點:
最主要的缺點是,由於對象之間的交互是通過明確的對象函數調用進行的,所以當一個對象需要實現一個特定功能的時候,必須知道哪一個對象提供這種服務,這就降低了系統的靈活性。管道和過濾器模型不需要明確指明數據的來源和去向 [3] 

體系結構事件驅動的體系

對象E
對象E
對象E
事件分發的總線
事件的創建
事件接收者的註冊的創建
對象E
這是面向對象和數據抽象體系的一種變形,系統同樣是由大量的對象組成的,但是對象之間的交互不是通過明確指明對象的函數或者過程調用進行的,相反,系統提供事件的創建和發佈的機制,對象產生事件,一個或者多個對象通過向系統註冊關注這個事件並由此觸發出相應的行為或者產生新的事件。
實例:
一個最著名的例子是GUI的模型,鼠標、鍵盤或者其他輸入設備產生各種事件,窗口、程序或者其他對象有這些事件所觸發,產生新的事件、進行數據處理或者其他操作。
優點:
用於函數和過程的調用調用不需要指明特定的對象,所以系統具有非常好的靈活性和擴展性,新的組件只需要向系統的事件處理部分註冊就可以立刻加入系統中,同樣,老的組件也可以方便的從系統中刪除。對於動態性要求特別高的系統,特別是如果需要在運行時對系統進行擴充,應該採用該結構。
缺點:
由於函數調用是通過事件發送進行的,所以,發出事件的對象不能確認是否有對象處理了這個事件、是否是期望的對象處理了這個事件、是否獲得期望的結果,同樣也無法控制事件發生的次序,系統的邏輯和時序的正確性必須通過複雜的時序邏輯和前後條件的斷言加以保證。

體系結構分層次的體系

將系統功能和組件分成不同的功能層次,一般而言,只有最上層的組件和功能可以被系統外的使用者訪問,只有相鄰的層次之間才能夠有函數調用
下面是一個基本的商務處理系統的層次結構
用户界面層
事務邏輯層
核心層
實例:
顯然,ISO的OSI(開放系統互連)參考模型是最著名的層次模型的例子,通過將開放系統的功能和組件劃分成7個層次,定義清晰的(很多時候是過於複雜的)層次之間的接口,實現複雜的互操作性
優點:
  • 系統的開發和設計可以逐步的分層次的進行,從底層的簡單的功能逐步建立高層的複雜和抽象的功能。
  • 靈活性和擴展性,由於相鄰層次之間通過清晰的接口交互,所以特定的層次可以被替換和增強,甚至可以增加新的層次。
缺點:
  • 不是所有的系統都可以分解成為清楚的層次
  • 劃分清晰、邏輯上一致的層次是非常困難的(OSI的失敗和TCP/IP的成功説明了這一點)
  • 嚴格的層次調用結構會降低系統的性能。

體系結構知識庫體系

使用一箇中心數據結構表示系統的當前狀態,一組相互獨立的組件在中心數據庫上進行操作。如果組件負責對中心數據進行選擇、處理,這種體系就是傳統的數據庫模型;如果中心數據結構自主的引發一系列的行為,則這種體系可以看成一個黑板模型。
中心數據庫(知識庫)
客户組件A
客户組件B
客户組件C
實例:
大量的傳統數據庫應用程序實際上就是這一體系的具體實例。在很多研究系統中,使用的基於知識庫的黑板模型,實際上也是這種體系
優點:
以數據為中心的體系結構,可以自然的表示大量的數據和事務處理的邏輯,適合表達以數據為重新的應用程序。
缺點:
只有很少一部分簡單的數據庫存儲應用可以完全採用這種體系結構表示,在大量實際的商業應用中,完成師傅處理和其他邏輯的應用程序必須採用其他的體系結構表達

體系結構解釋器體系

用户
如果應用程序的邏輯非常複雜,例如,AutoCAD的各種繪圖指令,而且,用户可能以非常複雜的方式使用這個系統,一個較好的體系就是提供面向領域的一組指令(語言),系統解釋這種語言,產生相應的行為,用户使用這種指令(語言)完成複雜的操作。
使用虛擬機語言描述的業務邏輯
虛擬機解釋器
完成實際操作任務的基本指令
實際的問題領域
實例:
大量的開發工具、二次開發工具體現了這一思想:微軟在其產品中大量使用的Visual Basic for Application,以及在AutoDesk產品中大量使用的AutoLisp語言,實際上就是給用户提供了一種面向領域的語言,然後核心解釋執行這一語言的指令和指令序列。從而擴充產品的功能,方便用户按照自己的需要定製系統。
優點:
非常好的擴展性,用户可以實現對軟件系統的二次開發。
缺點:
軟件開發複雜,特別是這種指令集的設計非常困難。
是否可以採用一種成熟的語言作為二次開發的基礎(例如,基於Java)

體系結構開發觀點

在實際開發過程中,簡單的判斷某一個具體的應用應該採取何種體系結構是非常困難的,簡單的管道、過濾器體系已經非常少見,面向對象的思想已經融合在幾乎所有的體系結構之中,而層次化的思想同樣也被廣泛使用,所以,一個基本的系統分析方法應該是功能和複雜性的分解,也就是説,從橫向分解(分模塊、子系統),縱向分解中得到系統的基本組件(分類、分層次的功能和對象)。然後根據問題領域的特性選擇系統的行為模式(具體的體系結構)。

體系結構常見結構

體系結構嚴格的層次結構

(系統可以清楚的分解成為不同的功能層次,例如基本的圖形庫,提供不同層次的繪圖接口) 這種體系結構適合於系統的功能相對簡單,並且可以按照複雜的程度、抽象的程度、和硬件平台的關係等方面的特性加以分層的軟件中。

體系結構事件驅動的體系

互操作性、特別是異構環境下的互操作性要求非常高的情況下,可以採用這種體系,當整個系統中存在大量的併發的,相互之間沒有邏輯聯繫的組件的時候(例如操作系統或者圖形用户界面)可以使用這種體系結構。現代軟件技術中微軟的COM和ISO的CORBA實際上都是這種體系結構的例子。

體系結構知識庫的體系

以大量數據為核心的系統採用這種體系,一些人工智能的應用同樣需要這種體系結構,面向對象的知識庫是這種體系結構的一個發展方向。將面向對象和層次化的思想引入知識庫系統中,將得到一種非常強大的體系結構。

體系結構基於解釋器的體系

如果應用系統和用户的交互非常複雜,採用這種體系結構是最適合的方案,只有將系統的基本操作以指令的形式提供給用户,同時,提供一種簡單明瞭的語法和基本的數據操作、處理的功能,才能得到功能最強大、最靈活、具有最佳擴充新的應用系統;一個非常合適的例子是瀏覽器,一開始,瀏覽器只是簡單的下載和顯示HTML的頁面,隨着用户對界面交互要求的發展,開發出javascript,提供一種語言和基本的界面元素操縱的指令來得到擴充性和強大的功能。
絕大多數實際運行的系統都是上面幾種體系結構的複合:在系統的某些部分採用一種體系結構而在其他的部分採用另外的體系,我們可以將複合幾種基本體系結構的系統稱作複合體繫結構。在實際的系統分析和設計中,可能首先將整個系統作為一個功能體進行分析和權衡,得到適宜的、最上層的體系結構,如果該體系結構中的元素較為複雜,可以繼續進行分解,得到某一部分的,局部的體系。
分析的層次應該在可以清晰的使用簡單的功能和界面描述表達結束,這樣,可以將我們在分析和設計的這一階段將焦點集中在系統的總體結構上,而避免引入和所使用的語言、實現所具體需要的技術等實現的細節上。

體系結構微處理器

體系結構(architecture)規定了處理器的功能性行為,是處理器設計的規範。
微體系結構(microarchitecture)是體系結構的具體設計,即處理器實現。
某種體系結構在其生命週期內可以有多種邏輯實現。比如,Intel的IA-32架構,也稱為“x86”架構,是一種設計規範。基於該規範下的產品包括包括Intel 8086、80186、80286、80386以及80486等。
中科院計算所的龍芯CPU,是我國具有自主知識產權的第一款CPU。其兼容MIPS指令集,意思就是説:在滿足MIPS規範下開發出的新的具體邏輯實現。即一種新的處理器實現 [1] 
參考資料
  • 1.    孫昌愛, 金茂忠, 劉超. 軟件體系結構研究綜述[J]. 軟件學報, 2002, 13(7):1228-1237.
  • 2.    梅宏, 申峻嶸. 軟件體系結構研究進展[J]. 軟件學報, 2006, 17(6):1257-1275.
  • 3.    沈蘇彬, 範曲立, 宗平,等. 物聯網的體系結構與相關技術研究[J]. 南京郵電大學學報(自然科學版), 2009, 29(6):1-11.