軟件體系結構范文

導語：如何才能寫好一篇軟件體系結構，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

關鍵詞：軟件體系結構；重用；模式

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)35-2519-02

A Comprehensive Introduction to the Study of Software Architecture

WANG Qiang

(AnHui Technical College of Mechanical and Electrical Engineering, Wuhu 241000, China)

Abstract: Software architecture is the hotspot in software engineering research. This article discusses about the purpose and current situation of software architecture researching.

Key words: software architecture; reuse; mode

1 引言

隨著計算機技術的發展和應用的不斷深入，軟件系統的規模和復雜度日益增加，在軟件設計過程中人們所面臨的問題不僅僅是考慮軟件系統的功能問題，而是面臨要解決更難處理的可修改性，性能，可靠性等非功能性問題。特別是80年代以來，對軟件適應變更的要求越來越高，所以對軟件整體的設計已經超過了算法和數據結構，成為系統開發關注的主要問題。軟件開發最大的風險來自需求變更，但一蹴而就搞定需求不現實，好的體系結構是易改動的基礎。 能否復用很重要，設計復用比代碼復用更有用更難。因此，研究軟件體系結構研究的能提高軟件生產率和簡化維護。提高軟件生產率的關鍵在于軟件相關部分的復用，而簡化維護的關鍵是減少軟件理解的成本和提高軟件的質量，這就是研究軟件體系結構的目的。

2 軟件體系結構的概念

軟件系統的規模在迅速增大的同時，軟件開發方法也經歷了一系列的變革.在此過程中，軟件體系結構也由最初模糊的概念發展到一個漸趨成熟的技術。

1) 1992年Perry 和Wo1f 在他們早期關于軟件體系結構的論文中指出:軟件體系結構是一組具有一定形式的結構化元素或稱為設計元素組成。

2) 1993年Shaw 和Garlan 認為軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。

3) 1994年Hayes Roth 則認為軟件體系結構是一個抽象的系統規范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系。

4) 1995年Garlan 和Perry 在IEEE 軟件工程學報上又采用如下的定義：軟件體系結構是一個程序各構件的結構、它們之間的相互關系以及進行設計的原則和隨時間進化的指導方針。

5) 1996年Boehm 和他的學生提出，一個軟件體系結構包括一個軟件和系統構件，互聯及約束的集合。

6) 1997年Ctements 和Kazman在《使用軟件體系結構》一書中給出如下的定義：一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。

3 軟件體系結構的現狀

下面介紹幾種常見的體系結構。

模型-視圖-控制結構是交互式應用程序廣泛使用的一種體系結構。它有效地在存儲和展示數據的對象中區分功能模塊以降低它們之間的連接度，這種體系結構將傳統的輸入、處理和輸入模型轉化為圖形顯示的用戶交互模型，或者換一種說法，是多層次的Web商業應用；MVC體系結構具有三個層面：模型（Model）、視圖(View)和控制(Controller)，每個層面有其各自的功能作用。

模型層負責表達和訪問商業數據，執行商業邏輯和操作。也就是說，這一層就是現實生活中功能的軟件模擬；在模型層變化的時候，它將通知視圖層并提供后者訪問自身狀態的能力，同時控制層也可以訪問其功能函數以完成相關的任務。

視圖層負責顯示模型層的內容。它從模型層取得數據并指定這些數據如何被顯示出來。在模型層變化的時候，它將自動更新。另外視圖層也會將用戶的輸入傳送給控制器?？刂茖迂撠煻x應用程序的行為。它可以分派用戶的請求并選擇恰當的視圖以用于顯示，同時它也可以解釋用戶的輸入并將它們映射為模型層可執行的操作；在一個圖形界面中，常見的用戶輸入包括點擊按鈕和菜單選擇。在Web應用中，它包括對Web層的HTTP GET和POST的請求；控制層可以基于用戶的交互和模型層的操作結果來選擇下一個可以顯示的視圖，一個應用程序通常會基于一組相關功能設定一個控制層的模塊，甚至一些應用程序會根據不同的用戶類型具有不同的控制層設定，這主要是由于不同用戶的視圖交互和選擇也是不同的。

在模型層、視圖層和控制層之間劃分責任可以減少代碼的重復度，并使應用程序維護起來更簡單。同時由于數據和商務邏輯的分開，在新的數據源加入和數據顯示變化的時候，數據處理也會變得更簡單。

軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。它反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。按這種方式理解，軟件體系結構風格定義了用于描述系統的術語表和一組指導構件系統的規則。

對軟件體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。例如，如果某人把系統描述為"客戶／服務器"模式，則不必給出設計細節，我們立刻就會明白系統是如何組織和工作的。

下面是Garlan和Shaw對通用體系結構風格的分類：

1) 數據流風格：批處理序列；管道/過濾器

2) 調用/返回風格：主程序/子程序；面向對象風格；層次結構

3) 獨立構件風格：進程通訊；事件系統

4) 虛擬機風格：解釋器；基于規則的系統

5) 倉庫風格：數據庫系統；超文本系統；黑板系統

設計模式使人們可以更簡單方便地復用成功地設計和體系架構。將以證實的技術表述成設計模式也會使新系統開發者更容易理解其設計思路。設計模式幫助你做出有利于系統復用的選擇，避免設計損害了系統復用性。通過提供一個顯示類和對象作用關系以及它們之間潛在聯系的說明規范，設計模式甚至能夠提高已有系統的文檔管理和系統維護的有效性。簡而言之，設計模式可以幫助設計者更快更好地完成系統設計。

一個設計模式描述了對于特定設計問題被驗證的解決方案，它綜合了所有開發者對這個問題所在領域的知識和見解；同時也是對于常見問題的可重用方案，它們一般適用于單個問題，但是組織在一起就可以提供整個企業系統的解決方案。J2EE平臺就用到很多設計模式，列舉如下：

1) 前控制器。

2) 控制器

3) 視圖

4) 視圖幫助

5) 會話面

6) 數據訪問對象

7) 值對象或傳輸對象

8) 截取過濾器

隨著軟件體系結構的不斷發展，出現了一種新型的體系結構即SOA。SOA被稱為軟件體系結構的劃時代革命。

SOA是一種結構模型，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件交互的人為依賴性。SOA的關鍵是“服務”的概念，W3C將服務定義為：“服務提供者完成一組工作，為服務使用者交付所需的最終結果。最終結果通常會使使用者的狀態發生變化，但也可能使提供者的狀態改變，或者雙方都產生變化”。將SOA定義為：“本質上是服務的集合。服務間彼此通信，這種通信可能是簡單的數據傳送，也可能是兩個或更多的服務協調進行某些活動。服務間需要某些方法進行連接。所謂服務就是精確定義、封裝完善、獨立于其他服務所處環境和狀態的函數?！?將SOA定義為：“按需連接資源的系統。在SOA中，資源被作為可通過標準方式訪問的獨立服務，提供給網絡中的其他成員。與傳統的系統結構相比，SOA規定了資源間更為靈活的松散耦合關系?！?Gartner則將SOA描述為：“客戶端/服務器的軟件設計方法，一項應用由軟件服務和軟件服務使用者組成……SOA與大多數通用的客戶端/服務器模型的不同之處，在于它著重強調軟件組件的松散耦合，并使用獨立的標準接口?！?Gartner相信BPM和SOA的結合對所有類型的應用集成都大有助益――“SOA極大的得益于BPM技術和方法論，但是SOA面臨的真正問題是確立正確的企業意識，即：強化戰略化的SOA計劃（針對供應和使用）并鼓勵重用?！彪m然不同廠商或個人對SOA有著不同的理解，但是我們仍然可以從上述的定義中看到SOA的幾個關鍵特性：一種粗粒度、松耦合服務結構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。

4 軟件體系結構存在的不足

盡管軟件體系結構研究領域取得了若干成果，但在應用方面，軟件體系結構仍然有很多可以改進的地方。N. Medvovonic認為，目前對軟件體系結構的理解還僅限于直觀、或當作稀奇事、或當作民間傳說；語義豐富但不嚴謹。體系結構似乎沒有解決實際問題。由此可見，若要有效地指導軟件工程實踐、為軟件開發提供一個好的結構及其設計結構的指導原則，軟件體系結構研究還有若干問題需要解決。比如缺乏統一的軟件體系結構的概念，各種軟件體系結構的不易操作性，ADL繁多，缺乏統一的ADL支持等等。

5 前景展望

目前，軟件體系結構領域研究非?；钴S。隨著研究的不斷深入，軟件復用的層次越來越高，人們在開發新的系統時不必總是重復別人已經創造的東西，而是可在軟件開發中復用已有成果，這樣可以把注意力投入到軟件新增功能上，提高軟件開發效率。

針對軟件體系結構發展趨勢，Clements預測在未來的5~10年內軟件體系結構研究將圍繞如下5個方向展開:體系結構創建與選擇；體系結構表示；體系結構分析；基于體系結構開發；體系結構演化.而Perry在IFIP 2000 年世界計算機大會主題演講中認為，最為重要的3個研究方向是:體系結構風格、體系結構連接件和動態體系結構。

參考文獻：

[1] 王霞俊.淺談軟件體系結構[J].常州輕工職業技術學院學報,2007(1).

[2] 鄧倫丹,羅丹,汪偉.幾種主要的軟件體系結構風格的分析[J].科技信息,2007(32):102.

[3] 孫昌愛,金茂忠,劉超.軟件體系結構研究綜述[J].軟件學報,2002(13)

[4] 秦建超,杜友福,孟珍偉.淺談軟件體系結構科技信息[J],2007(2)

[5] Michale Kircher.面向模式的軟件體系結構[M].1版.北京:機械工業出版社,2005:5-6.

篇2

【 關鍵詞 】 軟件體系結構；瀏覽器引擎

Research of Hybrid Web/Native Software Architecture

Liu Lei Liu Qiang

（Guangdong Certificate Authority Co.， Ltd GuangdongGuangzhou 510100）

【 Abstract 】 Hybrid Web/Native software architecture was proposed to satisfy the complex and variable business need of CA operators. The architecture integrates Web browser engine with native client software. With this architecture， client software owns the full control of hardware， while it is as flexible as a Web application. The UI and business flow of client software can be dynamically modified by Web server side code in real time.

【 Keywords 】 software architecture； browser engine

1 引言

隨著數字證書應用的不斷發展，數字證書運營商對業務靈活性的需求不斷增加。目前主流數字證書客戶端軟件基本屬于純粹的本地客戶端軟件，雖然經過多年的不斷開發完善，功能已經基本成熟、穩定，但是隨著客戶端軟件部署數量的不斷增加以及地域范圍的不斷擴大，當數字證書運營商的業務管理規則需要調整時，客戶端軟件的更新維護成本將會很高。更重要的是，有的業務規則調整之前需要做到所有的本地客戶端軟件都統一更新到一個最新的版本，否則將會導致用戶體驗不一致問題的發生。數字證書運營商迫切需要一種統一、快速、準確控制客戶端軟件功能的技術解決方案。

基于Web的應用雖然具有很高的靈活性以滿足這種需求，但由于主流瀏覽器在安全方面的限制，使得在涉及硬件設備管理的領域，Web應用常常存在各種使用上的困難。以IE瀏覽器為例，雖然可以通過開發ActiveX控件的方式來使得Web頁面具有訪問本地數字證書硬件設備的能力，但是各種不同的IE安全設置和操作系統安全設置常常使得控件無法正常使用，這大大增加了運營商的維護工作量。另一方面，傳統的本地客戶端軟件，雖然具有完全控制硬件設備的權限，但是在靈活性上還遠遠不如像Web頁面那樣可以通過服務器端代碼動態實時為客戶端生成用戶界面和業務流程。

本文提出了一種Web/Native混合軟件體系結構，該體系將Web瀏覽器引擎集成到本地客戶端軟件中，實現了在客戶端軟件中通過HTML、CSS和JavaScript來控制用戶界面和業務流程，底層則可以直接訪問硬件設備，實現對設備的完全控制。

2 體系結構設計

Qt是一套開放源代碼的跨平臺C++開發框架，為了將來客戶端軟件可以順利移植到各種基于嵌入式操作系統的車載或手持移動設備上，選擇Qt作為體系結構的技術實現框架。Web瀏覽器引擎采用了開放源代碼的WebKit，該引擎目前已經被各種商用瀏覽器廣泛使用，例如蘋果Safari、Google Chrome等。

基于Qt和WebKit的Web/Native混合軟件體系結構如圖1所示。最上層的Application層將完全使用網頁開發語言來進行描述（HTML/CSS/JS），可以通過網頁開發工具來進行開發，這使得數量眾多的網頁開發人員可以參與到客戶端軟件開發中，在某種程度上降低了客戶端軟件開發的人力成本。在Application層之下，是WebKit瀏覽器引擎，用于對網頁代碼進行解析。在WebKit之下，則是Qt提供的對網絡、圖形界面等方面的開發庫，這些庫都通過C++代碼來進行調用。在這一層中也包含了各種自行開發的對硬件設備進行控制的庫。

3 JavaScript與本地Qt對象交互機制

將Web頁面與底層開發庫整合起來的核心在于實現JavaScript與本地Qt對象之間的交互機制，本文將對該機制進行詳細描述。

信號和槽（Signal and Slot）機制是Qt機制的核心，用于對象間的通信，也是Qt的一個主要特點。Qt提供了信號和槽機制，當一個信號被觸發，與其連接的槽便會觸發，這是在Qt的預編譯過程中生成moc代碼來實現的。

在圖形用戶界面開發中，當對一個Widget進行操作時，常常需要觸發另一個Widget去處理，也就是實現兩個對象之間的通信。例如，當按下一個按鈕時，希望窗口關閉。

常見的實現機制是使用回調函數。回調函數是調用一個函數指針所指向的函數。如果需要在按下按鈕時，執行某個函數，則需要把指向這個函數的指針作為參數傳入到回調函數中。但采用這樣的機制存在類型安全問題，此外還會增強類之間的耦合性，不利于軟件的擴展和維護。

JavaScript與本地Qt對象的交互分為兩個步驟，如圖2所示：1）將本地Qt對象的信號和JavaScript的slots連接起來；2）通過JavaScript調用本地Qt對象的slots。

在開發中，一個對象只需繼承Qobject，便可使用該機制。信號和槽機制首先是類型安全的，信號和槽的參數必須匹配（槽函數的參數表必須小于或等于信號的參數表）。其次，使用該機制可以降低對象耦合性，在開發一個對象時，不需考慮一個信號發出后需要進行什么操作，也不需考慮誰要連接到這個槽函數，這樣有利于多人合作開發以及將來的代碼復用。信號和槽的連接方法請見圖3所示。

4 對象與Web頁面的整合方式

有兩種方式可以將Qt對象整合到Web頁面中，然后再用QWebView widget來顯示這張Web頁面：方式1 將Qt對象添加到JavaSript的上下文環境中；方式2 創建一個插件，然后通過對象標簽將Qt widgets置入到Web頁面中。

我們選擇了使用方式2，頁面中widgets的公共槽將像普通函數一樣公開給JavaScript函數。widget要能整合到Web頁面中，需要繼承QWebPluginFactory類，并且重新實現plugins方法和create方法。plugins方法用來通知Web頁面該插件可用。但需要創建widgets時，create方法將被調用。例如，當需要將一個名為my-device-control的widget置入頁面的HTML代碼時，可使用如下的對象標簽：

/>

為了創建這個widget，必須激活plugins并且將plugin工廠類通知給QWebPage。在下面的代碼中，DeviceControlFactory在application/my-device-control發出請求時，創建了DeviceControl實例widget。

{

...

QWebSettings：：globalSettings（）->

setAttribute（ QWebSettings：：PluginsEnabled， true）；

webView->page（）->setPluginFactory（ new DeviceControlColorLabelFactory（ this ） ）；

...

}

DeviceControl widget公開了一個名為openDevice（）的公共槽，這樣就可以在JavaSript中像調用普通函數那樣進行調用了，調用代碼如下：

打開設備

5 實現效果

如圖4所示是基于Web/Native結構開發的數字證書客戶端軟件。該客戶端的顯示界面全部采用Web方式實現。界面分為證書功能區、證書消息區、證書展現區。使用純Web的方式很容易實現證書消息區和證書展現區的功能，但是如果不進行一系列瀏覽器安全設置，是無法實現讀取USB Key中的數字證書的，也就無法實現數字證書與服務器消息之間的對應關系。引入Native的方式很好的解決了這個問題，通過Native接口不僅可以在完全無需額外設置的情況下讀取USB Key中的數字證書，還可以實現證書功能區中的修改USB Key密碼、使用USB Key中的私鑰進行文件簽名等功能。

5 結束語

Web/Native混合軟件體系結構通過在傳統C/S結構的客戶端軟件中集成Web瀏覽器引擎，使得客戶端軟件既具有對硬件設備的全面控制能力，又具有與Web應用相同的靈活性。基于該體系結構開發的數字證書客戶端管理軟件將能很好的滿足數字證書運營商越來越復雜多變的業務需求。

參考文獻

[1] 布施曼等著.面向模式的軟件架構（卷4）：分布式計算的模式語言.人民郵電出版社，2010.

[2] 葉偉等著.互聯網時代的軟件革命――SaaS架構設計.電子工業出版社，2009.

[3] 伊斯特等著.C++設計模式――基于Qt 4開源跨平臺開發框架.清華大學電子工業出版社，2007.

[4] Developing hybrid Web/GTK+ rich internet applications. http：///webkit/webkitgtk-fosdem08.pdf.

[5] Federal Information， Web Enabling your Native Apps，http：///webkit/WebEnableYourNativeApp.pdf.

作者簡介：

篇3

關鍵詞:化學抽象機;軟件體系結構信息科學

1概述軟件體系結構是當前軟件工程領域的一個研究熱點,是大型軟件開發中必須解決的核心技術。無數的寫作論文軟件工程實踐證明:一個成功的軟件系統往往都有一個好的軟件體系結構。但是在軟件設計、開發、測試、運行以及升級的各個階段,體系結構都不可避免地會發生變化,如何把運行時適應性機制加到復雜的大規模軟件系統中就成為一個重要的工程問題。然而要通過軟件體系結構的研究實現這一目標,首先必須用某種方式描述動態體系結構。

目前已定義的ADL超過20種,具有代表性的ADL包括C2、Darwin、Rapide、Unicon、Wright、D-ADL和ACME等[1];國內包括XYZ/ADL、ABC/ADL、FRADL和A-ADL等。但這些語言大多注重軟件系統結構靜態特性的描述,而對其動態特性描述不足。PaolaInverardi和AlexxanderLWolf[2]首先將CHAM應用于描述和分析軟件體系結構。他們充分利用CHAM擅長描述系統動態性和并行性的優點,用CHAM形式化方法描述和分析了軟件體系結構動態操作性語義,在軟件體系結構動態特性描述方面進行了有效的擴展,主張用CHAM模型描述軟件體系結構,并例舉描述了編譯器的體系結構,包括順序多階段編譯器和并行、共享存貯庫的多階段編譯器?；贑HAM的體系結構描述,運用重寫技術和結構歸納證明方法,能夠對體系結構的部分行為屬性進行形式化或半形式化的證明。

2化學抽象機化學抽象機CHAM主要用于異步并行計算模型的建模[3],通過將化學反應和抽象機概念有機結合描述系統狀態變化,它將一個系統的狀態看成化學溶液,溶液由分子組成,分子根據一定的反應規則相互反應又引起新的系統狀態變化。溶液中不同分子可按反應規則平行地進行反應,只要各自反應的分子集不重疊。因CHAM在描述系統動態性、并行性方面的優良特性,所以可較好描述異步并行計算模型,尤其擅長描述如λ計算和CCS進程計算模型[4]。一個化學抽象機由一組分子m0,m1,m2…、溶液s0,s1,s2…和變換規則組成,分子是CHAM的基本元素,由一個常數集和操作符集派生而成的句法代數定義;溶液是由有限多個分子的集合,它反映了系統的某種狀態,溶液中的分子根據變換規則進行反應。

變換規則從應用范圍可分為:通用規則,即在整個CHAM中通用的規則;專用規則,適用于某些特定分子的規則。從反應作用可分為:加熱規則,把大分子分解成小分子的規則;冷卻規則,小分子合成大分子的規則。從反應涉及的分子可分為:自反應規則,只有單一分子的狀態變化;互反應規則,反應過程中至少有兩個分子參加反應。本質上,CHAM可看成一種有限狀態機,因此它具有一般狀態機特征,與其他以狀態機為轉換模型的技術相比,CHAM利用化學反應這一隱喻,因此在刻畫系統的動態性特征方面比較自然。CHAM規格說明是一個基于操作的系統框架,這種框架不會把所描述的系統曲解為某種特定的計算模型。CHAM描述不僅可以描述系統靜態特征,還能從系統操作動態性方面進行描述,通過對各單元的描述、引入的轉換規則及項重寫描述和分析體系結構的動態行為,因而可使軟件開發人員很快地了解系統功能和行為,適用于多種層次的用戶。在CHAM中,膜是一種封裝結構,任何溶液可以被看作一個關于其它溶液的單一分子,膜內的溶液可以獨立進化。膜具有半可滲透性,允許某些分子進入和離開,通過膜上的氣孔,可以有選擇地從膜中抽取分子,同時,氣孔的可逆性允許分子被重新吸收到原始溶液中,膜表示了復合構件,實際上提供了一種刻畫系統模塊化的途徑。

3在SA中的應用3.1描述SA。用于描述SA的CHAM可表示成一個三元組CHAM=(M,E,R),其中:3.1.1分子集M={m|m∈MS∨MI},MS={mS1,…,mSn}為穩定狀態分子集,處于穩定狀態的分子不吸收或釋放電子,MI={mi|mi∈{mS(.P)+,(P.)+mS(.P)+,(P.)+mS}∧mS∈MS}為離子狀態分子集,處于離子狀態的分子準備進行吸收或釋放電子操作,其中P={i(e),o(e)}為分子上的操作集,i(e)為吸收電子,o(e)為釋放電子,操作符“.”表示操作順序。3.1.2電子集E={e1,…,ek},分子可根據自反應規則準備進行進行收或釋放電子,當溶液中有兩種互補電子,即一對釋放-吸收電子時,可根據互反應規則進行反應。3.1.3規則集R=RS∪RM,RS={r|r∈{mS1=mI1,…,mSj=mIj}∪{mS1=mS1*,…,mSj=mSj*},mSj∈MS∧mIj∈MI,j=1,2,…}是分子自身從吸收電子到釋放電子的過程或分子復制自身過程規則集,mSj*表示由mSj復制與mSj性質、狀態完全相同的分子,RM={r|r∈{m11,m21,…=m11,m21,…},mij,mij∈MI,i,j=1,2,…}是電子在分子間流動過程的規則集,rp∈RM,rq∈RM,p≠q,若{mp1,…,mpj}∩{mq1,…,mqj}=",則rp,rq可并行反應。3.2描述構件、連接件。用CHAM描述軟件連接件或構件,可表示成一個四元組(MC,ECI,ECO,RC):3.2.1連接件或構件的分子集MC;3.2.2連接件或構件的前置條件,即輸入電子集ECI;3.2.3連接件或構件的后置斷言,即輸出電子集ECO;3.2.4連接件或構件分子集的反應規則集Rc。連接件或構件的分子集反映了連接件或構件的角色集及在角色上進行的輸入輸出操作,相對來說是靜態的,是一種實現上的結構,屬于語法層。輸入電子集是使用該連接器或構件前必須具備的條件,輸出電子集后映的是使用該連接件或構件后的狀態。反應規則集說明了連接件或構件如何運用反應規則從而發生狀態的演變,實質上是連接件或構件的動態行為,是相對動態的,屬于語義層。如管道-過濾器體系結構風格的CHAM描述如下:定義過濾器:MC:PIPE_FILTERECI:readerECO:writerRC1:PIPE_FILTER=PIPE_FILTER.i(reader)RC2:PIPE_FILTER.i(reader)=i(reader).PIPE_FILTER,PIPE_FILTER.o(writer)RC3:PIPE_FILTER.o(writer)=o(writer).PIPE_FILTER定義管道:MC:PIPE_CONNECI:readerECO:writerRC1:PIPE_CONN=PIPE_CONN.i(reader)RC2:PIPE_CONN.i(reader)=i(reader).PIPE_CONN,PIPE_CONN.o(writer)RC3:PIPE_CONN.o(writer)=o(writer).PIPE_CONN由過濾器和管道構造一個系統:SYS_M:PIPE_FILTER,PIPE_CONNSYS_E:reader,writerSYS_R1:PIPE_FILTER.o(writer),PIPE_CONN.i(reader)=o(writ-er).PIPE_FILTER,i(reader).PIPE_CONN

4展望目前基于構件的軟件工程正逐漸成為軟件開發的新趨勢,但是也給基于構件的軟件系統測試帶來了新的問題,而CHAM不僅可用于描述動態軟件體系結構,還可用于測試體系結構,因為CHAM這種對系統狀態變化的描述特別適合于測試系統的行為和功能,Bertolino[5]等人提出從軟件體系結構描述中導出實現層的測試用例,以指導構件系統的集成測試的思想,隨著對CHAM的深入研究,必將有新的應用被提出。

參考文獻

[1]MedvidovicN,TaylorRN,Aclassificationandcomparisonframeworkforsoftwarearchitecturedescriptionlanguages[J].IEEETrans.onSoftwareEngi.,2000,26(1):70-93.

[2]InverardiP,WolfAL.Formalspecificationandanalysisofsoftwarearchitecturesusingthechemicalabstractmachinemodel[J].IEEETrans.onSoftwareEngi.,1995,21(4):373-386.

[3]BerryG.,BoudolG.TheChemicalAbstractMa-chine[J].TheoreticalComputerScience,1992,(96):217-248.

篇4

【關鍵詞】軟件體系結構 構件模型 構件語言 SACM SAJ

【中圖分類號】G642 【文獻標識碼】A 【文章編號】1674-4810（2013）14-0081-01

在軟件開發中，如何提高軟件質量是人們的普遍追求和共同愿望。而提高質量的關鍵問題就是構件技術和軟件體系結構技術。但是，目前在這兩項技術開發中面臨著多方面的挑戰，本文擬對這些問題提出相應的解決方案。

一 基于軟件體系結構的構件模型SACM

第一，構件。SACM構件是能提供相對獨立服務的計算單元，具有規范的接口和顯示的上下文依賴，能夠被第三方組合。就其組成來看，主要包括端口和服務兩個部分，每個端口代表一個交互點，至多有一個請求服務接口和一個提供服務接口。對于構件來說，其服務實現部分由方法體構成，這就降低了構件之間的耦合度，能夠提高構件的復用程度。

第二，構件之間的關系。在SACM中，存在著多種構件，這些構架之間相互聯系，形成了多種多樣的不同的關系，主要有部分-整體關系、泛化關系、連接關系、協作關系。

第三，連接子的引入及其作用。為了更容易地實現映射、對軟件系統屬性進行分析、驗證和跟蹤，提高構件的復用程度，提高軟件系統結構的動態配置、加強低軟件的維護，在SACM構件中有必要引入連接子。就其作用來看，連接子主要發揮通信、轉換、輔助交換、協調控制的作用，對整個軟件系統的運行有著積極的意義。

第四，基于連接子構件組合方法。在SACM構件當中，構件組合方法主要有兩種：基于被動的和基于主動的連接子構件組合方法，不同的方式有各自的優勢，需要根據具體情況選用。

二 面向構件語言SAJ

第一，SAJ語言設計的目的。該語言設計的目的主要包括以下幾個方面：能夠更好地支持面向構件軟件開發、實現從體系結構設計模型到地層代碼的映射。

第二，SAJ語言支持面向構件軟件開發。在進行軟件開發的過程中，為了能夠更好地對面向構件的軟件進行支持，面向構件語言應能夠支持構件的封裝、復用和組合，并支持構件的設計與開發。具體來說，是從以下五個方面來支持面向構件軟件開發的：構件的封裝性、構件組合、面向構件設計原則、設計模式、連接子復用。

第三，SAJ語言的實現。使用Polyglot框架來實現SAJ語言的編譯器，并將編寫的源代碼翻譯成Java代碼，每個端口自動產生一個字段，保存所使用的連接子。由連接子協調構件之間的通信，通過消息截取和消息過濾，有利于解決構件之間不相容的問題。有利于實現日志、數據加密傳輸等服務，并能夠實現各種體系結構風格，具有良好的運用空間。

三 SAJ語言的語法、語義和類型系統

第一，SAJ語言的簡介。對于SAJ語言來說，它的核心是基于RelJ，它是在RelJ的基礎上，添加了構件、端口、連接子、角色等軟件體系結構。

第二，SAJ語言的類型系統。類型是程序設計中項的集合，它們具有共同的性質。對于類型系統，從本質上來說，它是一個類型推導規則的集合，在程序設計中具有重要的作用：檢查類型錯誤、支持語言抽象、優化程序，并支持語言的安全性。

四 豐富構件接口信息

第一，顯示相應的服務關系。顯示描述請求服務和提供服務之間的關系，構件要想為外界服務，就需要從外界得到相應的請求服務。對于現有構件模型來說，請求服務和提供服務之間的關系是固定的。但是在可復用構件的軟件開發中，請求服務和提供服務之間不存在嚴格的依賴關系，往往存在著一些問題與不足，影響正常的服務。因此，有必要顯示請求服務與提供服務之間的關系。此外，從構件復用粒度的角度來說，顯示它們之間的服務也是十分必要的。同時，顯示它們之間的關系，有利于對構件質量進行精確度量、調整與改進，更能靈活適應不同的環境，提高服務質量，更好地滿足軟件開發的實際需要。

第二，描述服務的參數值。在進行軟件開發時，服務的參數值往往會對構件行為產生一定的影響。并且構件開發人員對這個也非常清楚。所以，在接口中增加描述服務的參數值是現實的、必要的。在構件接口中，有提供服務和請求服務，對于它們的參數值描述略有不同。一般是在行為協議中描述參數值，并在構件組合中得到具體應用。

五 結束語

總之，構件模型和面向構件語言有利于解決當前構件技術和軟件體系結構技術所面臨的問題。文中所提出的構件模型SACM和構件語言SAJ，能夠有力地促進構件技術的發展。在今后的實際工作中，仍然有對該相關問題進行進一步深入研究的必要。

參考文獻

[1]岳洋.SMC/ADL：一種層級式構件系統的體系結構描述語言[J].計算機科學，2012（7）

篇5

關鍵詞： 模糊測試； 體系結構分析； 漏洞挖掘； 安全漏洞

中圖分類號： TN711?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）09?0099?04

Abstract： To improve the efficiency of vulnerability mining， the vulnerability mining system Fast Fuzzing based on software architecture analysis was designed and implemented in combination with the advantages of symbolic execution， stain analysis and fuzzing test. This system is composed of architecture analysis， instruction tracing， symbolic execution， stain analysis and dynamic testing. To improve the system efficiency， the traditional technology method was optimized. The experimental results show that the Fast Fuzzing system can effectively detect the security problems in IE8 and IE10， successfully trigger multiple vulnerabilities in IE8 and IE10， which is suitable for the safety testing of common software.

Keywords： fuzzing test； architecture analysis； vulnerability mining； security vulnerability

0 引 言

由于軟件漏洞的高危害性，漏洞挖掘技術已成為計算機領域中的一個研究熱點[1]。一方面，軟件安全研究人員專注于各種流行軟件的安全性分析和測試，以發現這些軟件中的安全問題；另一方面，軟件開發商也積極投入到產品的安全檢測中，以提高軟件的安全性[2]。

近年來，在程序分析和編譯原理等領域的促進下，面向源代碼的漏洞挖掘技術取得了一定成果。然而，該技術仍然存在著許多不足之處：如出于商業利益和商業保護等原因，絕大多數的軟件開發商并不對外提供軟件的源代碼[3]。其次，源代碼層次的漏洞挖掘和分析并不能發現在程序編譯、程序鏈接過程中產生的漏洞問題。此外，軟件中引入的軟件體系結構方法、對外接口的不規范調用，也有可能存在潛在的安全問題[4]。

1 系統需求與目標

現有的符號執行技術主要面臨路徑爆炸、約束求解困難和效率比較低等問題，而本文的設計思想基于符號執行技術和模糊測試技術，同時與軟件體系結構的方法相結合[5]。因此，本系統的設計目標主要包括如下幾點：

（1） 高效率。提高本系統的測試效率，使得系統能夠對待測軟件進行自動化測試，分析軟件運行時的狀態信息，并且能夠準確記錄軟件的異常行為和崩潰信息。

（2） 高適用性。能夠對通用格式的數據進行處理，并且通過反饋式生成測試用例，驅動測試過程的持續運行。

（3） 高代碼覆蓋率。能夠在動態測試時分析測試用例的代碼覆蓋率，盡可能生成不同路徑的測試用例，提高系統測試時的代碼覆蓋率。

2 系統架構設計

為了提高漏洞挖掘的效率，本文在軟件體系結構分析的基礎上，結合了符號執行和污點分析技術，設計和實現了針對二進制程序的漏洞挖掘系統Fast Fuzzing[6]。

Fast Fuzzing漏洞挖掘系統采用離線符號執行和離線污點分析的方法，在PANDA平臺的基礎上實現了上述功能，同時利用STP求解器進行約束求解，生成新的測試用例。另外，還結合了污點分析結果，得到相關的污點信息，從而用于導向型測試用例的生成[7]。在進行動態測試時，Fast Fuzzing系統會計算每次測試用例的代碼覆蓋情況，從而在選擇新的測試用例進行測試時，優先選擇能夠提高代碼覆蓋率的新測試用例。Fast Fuzzing系統架構圖如圖1所示。Fast Fuzzing漏洞挖掘系統主要由指令追蹤模塊、體系結構分析模塊、符號執行模塊、污點分析模塊和測試模塊組成。

3 系統實現

3.1 指令追蹤模塊設計與實現

指令追蹤模塊的主要功能是，記錄測試程序執行時每條指令的地址、上下文信息和內存信息等。該模塊是在動態分析平臺 PANDA下實現的，其作為 PANDA平臺的一個工具模塊 panda_tools。指令追蹤模塊主要有如下三個模塊：

指令追蹤：程序執行過程中能夠動態分析每條指令，記錄指令的具體信息和寄存器信息。指令追蹤功能主要通過注冊PANDA_CB_INSN_TRANSLATE和PANDA_CB_INSN_EXEC兩個回調函數實現。

內存追蹤：程序執行過程中對內存的操作進行有針對性的記錄，包括內存的申請、內存的讀/寫、內存塊大小和數據信息等。內存追蹤方法與指令追蹤類似，通過注冊 [PANDA_CB_VIRT_MEM_READ，PANDA_CB_VIRT_][MEM_WRITE，]PANDA_CB_PHYS_MEM_READ和PANDA_CB_PHYS_MEM_WRITE四個類型的回調函數，分別實現對虛擬地址內存的讀/寫操作和物理地址內存的讀/寫操作的監控。

函數追蹤：程序執行過程中能夠記錄系統函數的調用，同時在提供符號表的情況下，能夠記錄指定函數的調用信息。系統通過 PANDA平臺對指令分析的過程，注 冊了兩個回調函數對其進行處理，類型為PANDA_CB_INSN_TRANSLATE的translate_call back函數和類型為PANDA_CB_INSN_EXEC的exec_callback函數。

3.2 體系結構分析模塊設計與實現

體系結構分析模塊的功能是對最基本的主程序和子程序進行靜態分析，通過對二進制程序進行基本塊劃分，記錄相關的基本塊信息，提取其中的函數調用關系，從而分析程序中的所有路徑，再根據靜態分析時的信息提取出相應路徑的約束關系，用于后續的符號執行中[8]。

體系結構分析模塊是在IDAPro靜態分析工具的基礎上實現的，之后通過模塊實現的插件對IDAPro反匯編結果進行深入的分析，對程序進行基本塊劃分和記錄，同時提取出其中的調用關系。該模塊的基本架構如圖2所示。在體系結構分析模塊中，主要包含基本代碼塊分析、函數調用分析和路徑分析三個部分。

3.3 符號執行模塊設計與實現

符號執行模塊通過分析指令追蹤時的記錄，結合體系結構分析時的路徑關系，將輸入數據符號化表示，生成相應的約束關系；之后，在軌跡重放時，根據程序執行時的上下文環境，更新路徑約束關系，并利用約束求解器進行求解，生成新的測試用例，對程序進行進一步的測試。本系統基于PANDA平臺構建，其底層由QEMU模擬器構建，采用TCG中間語言的方式對指令進行翻譯處理。本文在此基礎上，采用了離線符號執行的方式，根據指令追蹤時的記錄，實現對中間代碼的符號化分析，從而提高符號執行的效率。

符號執行模塊首先在體系結構分析模塊的基礎上，通過對目標軟件的靜態分析，生成軟件內部的函數調用圖，進而推導出軟件中的路徑關系。該模塊的基本流程如圖3所示。

3.4 污點分析模塊設計與實現

污點分析模塊通過指令追蹤時對原始輸入數據的污點標記，分析相關內存信息，記錄污點數據的傳播過程，獲得輸入數據與敏感內存操作的關系，從而生成新的測試用例。

污點分析模塊是在PADNA平臺基礎上實現的，借助于指令追蹤模塊，對目標程序的執行流程進行軌跡記錄，生成相應的軌跡記錄文件。軌跡記錄部分主要針對每條執行過的指令，具體包括指令的地址、指令機器碼和指令運行時寄存器、內存的相關信息。

3.5 動態測試模塊設計與實現

動態測試模塊是在Windows異常處理機制的基礎上，通過執行目標程序捕獲運行時出現的異常信息判斷測試用例是否會引發程序崩潰，再進一步分析崩潰信息，判斷該問題是否是由于軟件自身的安全漏洞而引起的。同時，動態測試模塊的功能還在于能夠不斷生成新的測試用例，對目標程序進行持續的測試。本系統主要是在Windows異常處理平臺下實現了動態測試模塊，主要通過對未執行代碼塊中插入軟件斷點追蹤指令的執行過程，并且對程序運行時的異常情形進行監控。

（1） 處理流程

動態測試模塊采用加載目標程序的方式對目標程序進程測試。同時，在創建目標程序的進程時，通過DLL注入的方式實現對異常信息的監控和對代碼覆蓋率的檢測功能。其具體處理流程如圖4所示。在程序碰到異常情形時，首先通過注入的DLL判斷此處的異常是否是DLL注入時插入的指令造成的，如果是則恢復原先指令，記錄此時的狀態信息，以便分析代碼覆蓋率；否則的話，則認為是程序中存在的安全問題觸發了此類異常，記錄測試用例、此時的寄存器和上下文信息，以便進一步確認該安全問題是一個程序漏洞。

（2） 異常監控

異常監控部分主要包含追蹤路徑初始化、基本代碼塊斷點設置和異常處理函數設置這兩個功能，其具體實現是通過DLL注入的方式對目標程序的執行進程進行監控。

（3） 代碼覆蓋率檢測

在對基本代碼塊進行斷點設置時，根據BBL_INFO結構中的isexecute字段判斷基本代碼塊是否執行。對于已經執行的基本代碼塊，將其記錄在已測試基本代碼塊結構中，然后在程序執行完后，將記錄中的代碼塊與模塊中的所有代碼塊進行比對，算出該模塊中的基本代碼塊代碼覆蓋率。

4 系統測試與分析

4.1 功能測試

（1） 測試方法

針對IE10，初始測試用例大小為21 824 B，指令記錄文件大小為53 323 MB， 共生成了625 369個測試用例，發現了24個異常。針對IE8，初始測試用例大小為21 824 B，指令記錄文件大小為23 954 MB，共生成了405 712個測試用例，發現異常數為31個。通過上述異常分析可以看到，IE8中的異常2和IE10中的異常2信息基本一致，都屬于訪問不可訪問內存錯誤，而其他異常信息也屬于此類錯誤。為測試Fast Fuzzing系統的代碼覆蓋率情況，本測試中對比分析FileFuzz工具對IE8軟件的測試代碼覆蓋率情況，結果如表3所示。

通過上述結果的對比，可以發現Fast Fuzzing相對于傳統的模糊測試工具而言，其在測試時覆蓋的代碼面更廣，能夠對軟件進行更為全面的安全測試。

5 結 論

針對傳統模糊測試方法的不足，本文設計并實現了一種基于軟件體系結構的漏洞挖掘工具，并且結合了混合符號執行技術和細粒度污點分析技術，通過對這兩方法的反饋信息進行深入分析，生成新的測試用例驅動測試流程，從而大大地提高了測試時代碼的覆蓋率和測試效率。

參考文獻

[1] 楊世德，梁光明，余凱.基于ARM嵌入式系統底層漏洞挖掘技術研究[J].現代電子技術，2015，38（18）：94?96.

[2] 蒲石，陳周國，祝世雄.震網病毒分析與防范[J].信息網絡安全，2012（2）：40?43.

[3] 王鐵磊.面向二進制程序的漏洞挖掘關鍵技術研究[D].北京：北京大學，2011.

[4] 陳寶國.美國國家網絡安全戰略解析[J].信息網絡安全，2010（1）：66?68.

[5] BRUMLEY D， POOSANKAM P， SONG D， et al. Automatic patch?based exploit generation is possible： techniques and implications [C]// Proceedings of 2008 IEEE Symposium on Security and Privacy. [S.l.]： IEEE， 2008： 143?157.

[6] BALAKRISHNAN G， REPS T， MELSKI D， et al. What you see is not what you execute [J]. ACM transactions on programming languages and systems， 2010， 32（6）： 202?213.

篇6

關鍵詞 軟件通信體系結構 無線電系統 軟件定義

中圖分類號：TP319 文獻標識碼：A

在現實生活中，軟件定義無線電技術在軍事方面的應用不斷地發展研究，各國為了早日實現軍事化的軟件定義無線電技術，加大了對軟件定義無線電的研究。目前，軟件定義無線電技術已成為未來軍事通信發展的趨勢。①

1 軟件通信體系結構

1.1 硬件體系結構

軟件通信體系中硬件體系結構采用了面向對象技術，通過面向面向對象技術的概念對系統內部的典型模塊進行劃分，要求實際系統一旦實現，必須將其詳細的、完整的接口進行公開。軟件開發人員可以通過公開的接口，對硬件的性能和容量以加載特定的波形，第三方則通過公開的接口，提供系統內部模塊，方便了新技術的插入。

硬件體系結構除了要對所有無線設備系統內部硬件模塊的組成進行定義，還要給出所有無線設備內部硬件的物理屬性。當無線設備系統內部硬件物理屬性符合條件時，這些硬件設備就可以應用到實際平臺硬件模塊，具有統一性，針對所有的通信設備來說都是通用的，實現了硬件模塊設計的實用性與通用性，節約了系統成本。未來無線通信系統發展主要以軟件為主，而現代無線通信系統是由軟件與硬件相結合來實現無線通信的功能。因此，為滿足無線通信系統未來發展的需求，硬件模塊要具有一定的可擴展性，這可以確保在原有硬件模塊基礎上，通過增加新的功能或者在已有的硬件模塊中增加新的硬件模塊來實現新的技術，既保證了硬件模塊統一性，又增加了硬件模塊內在的靈活性，滿足軟件無線電發展的需求。②

1.2 軟件體系結構

在軟件通信體系中軟件與硬件所承擔的功能不同，根據軟件在通信體系中所承擔的功能，可將軟件體系結構由上到下分為應用程序、核心框架、公共對象請求體系中間件和嵌入式實時操作系統四部分。其中核心框架、公共對象請求體系中間件以及嵌入式實時操作系統三部分共同構成了軟件體系結構中的核心內容，也是軟件體系結構中一個通用的軟件平臺。軟件平臺的構成給開發人員和波形的設計帶來了新的要求與限制，有利于實現波形從一個無線通信系統到另一個無線通信系統的移植。

1.3 安全體系結構

軟件通信體系中安全體系結構，為了保證在不同的無線通信系統能夠相互通連與相互操作，是為了確保用戶的信息在傳輸、發送、處理以及存儲過程中的完整性與機密性。在安合體系結構中，整個系統的安全功能是由一個通信保密模塊、紅邊處理器以及黑邊處理器三部分共同來完成的，而非一個邊界分明的安全模塊來單獨完成。③

2 軟件定義無線電系統

軟件定義無線電系統又稱為軟件無線電系統，是一種可以通過軟件進行編輯，實現全部功能的無線電，具有較高的靈活性與通用性。用戶通過軟件無線電系統，對動態修改配置對系統中的網絡裝備與軟件更新設備進行修改，從而獲得更好的服務與性能。軟件定義無線電系統是通過一個簡單的終端設備，運用軟件重配置功能來支持各種不同種類的無線系統與服務的新技術。固定或者移動的軟件定義無線電設備，都能讓用戶通過改變軟件改變接收與發送的特征。移動無線電系統與改變運行模式的軟件定義無線電設備相互通聯，并且能夠同時在多種公共安全頻帶中工作。

軟件定義無線電系統不僅具備基本的無線通信功能，還具有以下三個方面的功能：一是通過軟件定義無線電系統能夠升級系統所裝載的軟件，以此來達到對系統的升級與功能的更新。④二是軟件定義無線電系統可以支持不同電臺系統的相互通聯，達到不同獨立運行的電臺系統能夠互傳信息。三是軟件定義無線電系統主要以軟件為主，解放了硬件通信業務傳輸方式，通過軟件定義無線電系統所裝載不同軟件實現動態配置系統功能。

3 軟件定義無線電的發展

軟件定義無線電技術采用現代化高端軟件進行操縱與控制，具有高自動化程度與較強的擴展能力，打破傳統依賴于硬件發展的通信體系。軟件定義無線電體系的發展是通信領域的第三次革命，經歷了從固定通信到移運通信，模擬通信到數字通信的改革。

軟件定義無線電技術作為現代通信行業新技術，在未來的無線電通信應用中有良好的發展前景，可能成為未來無線電通信技術的支柱。軟件定義無線電技術可以多頻段多模式的手機、衛星通信、智能天線以及蜂窩移動通信系統、無線局域網等各個相關的應用領域。

4 總結

隨著科學技術的不斷發展，軟件定義無線電系統在各個領域中得到了廣泛的應用，無線通信體系朝著通信數字化、智能一體化的發展。由于我國目前無線通信體系硬件水平的有限，導致軟件無線電通信還達不到理想的要求。針對軟件通信體系與軟件定義無線電系統的研究，可以預見，軟件定義無線電技術可能成為未來通信行業發展的核心內容。⑤

注釋

① 范建華，王曉波，李云洲.基于軟件通信體系結構的軟件定義無線電系統[J].通信技術，2011，51（8）：1031-1037.

② 劉獻，張棟嶺，陳涵生.軟件定義無線電及軟件通信體系結構的規范[J].計算機工程，2009，30（1）：95-98.

③ 邱永紅，朱勤.基于軟件通信系統的無線通信系統研究[J].系統工程與電子技術，2009，26（5）621-625.

篇7

關鍵詞：軟件；抽取；需求

信息化產業經過幾十年的發展和建設，正逐步從最初的用于解決局部問題的小型或簡單軟件，向復雜、成體系、網絡化的企業級系統擴展。軟件系統的構成不再只是模塊，越來越多的是功能構件和子系統，使軟件系統成為“系統的系統”，或叫復雜系統。如何構建可擴充、可裁剪、可生長的滿足企業應用的大型軟件系統，已成為軟件業研究的重要課題之一。其中，復雜系統的結構設計是人們最關注的核心問題。

1 軟件設計的需求分析

軟件通常是因需求才進行設計開發，由用戶方從解決業務問題的角度提出，均以專業的術語或事務性的語言描述。高質量、清晰準確的需求描述，可有效約束軟件系統的結構設計和功能定位。邊緣清晰、描述規范的要求，會在一定程度上降低軟件設計和開發的成本，提高軟件質量和開發效率。但是，需求的成長和變化，往往伴隨軟件的整個開發過程，這種現狀使得軟件設計的難度不斷增加，程序開發也從傳統的開發方法向敏捷編程轉化。

用戶基于一定的業務需要提出需求，通常不能直接指導軟件的開發，只有經過軟件設計者的分析提取，通過規范的技術語言描述，形成面向軟件開發者的需求規格說明，才能指導軟件的研制。抽取需求是軟件設計師必須完成的工作，傳統的需求抽取方法一般包括面談、問卷、觀察和業務文檔研究等，這些方法簡單、成本低，對業務邏輯清晰、封閉性較好的需求比較適合，而對復雜且很難封閉的需求，采用傳統的抽取方法，則風險很大。在軟件開發領域，需求抽取方法有原型法、聯合應用開發法和快速應用開發法三種。

1.1 原型法

通過構造軟件演示系統，即根據理解的需求，建立一個快速而粗糙的工作模型，由可視化方法獲得用戶的反饋。

1.2 聯合應用開發法

是將領導、用戶、開發人員、系統設計師等召集起來通過會議的方式，集中所有人的智慧，對要求進行分析抽取。

1.3 快速應用開發法

就是集前兩種方法，加上最優方案的系統研制而進行的一種需求抽取方法，是一種快速軟件開發方法。

以上是目前常被采用的需要抽取方法，但對于系統分析員或系統設計師來說，無論采用哪種方法，都必須面臨提取關鍵需求、判斷需求增長點和發展方向的問題。

2 需求分析對系統體系結構設計的影響

2.1 抽取影響軟件結構的需求，是需求分析的核心

關鍵需求是軟件結構設計的核心，而提取關鍵需求是軟件結構設計師必備的技能。以一個數據錄入軟件為例，一般需要提供一個交互式界面，由用戶鍵入所需數據，提交存儲到文件或數據庫里即可。但用戶要求錄入的數據項，應能隨著業務的不斷變化而進行增加或刪減，可多人同時進行錄入。同時，要求對存儲的數據按照需要的方式進行查詢調閱，甚至進行一定的復合計算或評估分析等。對于這樣的需求，錄入項不斷變化、多人同時操作、存儲要求等都是核心元素，這些元素將直接影響軟件結構的設計。軟件設計應考慮分布式并發機制和大量的數據存儲訪問要求。這些需求均與功能無關，但會影響軟件結構的設計。數據庫訪問相關的軟件，一般采用傳統的C/S結構。當用戶增加到一定量時，該結構會導致數據庫服務器負載加重，甚至系統崩潰。為了適應這種變化，應采用多層結構，將用戶操作與數據存儲進行分離。采用多層結構，不僅可以緩解數據庫服務訪問壓力，還能降低數據庫變化給用戶操作帶來的影響。錄入項的變化需求，潛在地存在著數據項擴充、界面調整等功能要求。一般情況下，完全適應這種變化的軟件很難設計。為此，可把錄入項作為配置要素，界面設計和數據存儲項根據配置項進行定制，應用服務層要在接口設計上考慮數據項的擴充能力。具有這類需求的軟件，一般由界面構造工具、錄入界面、應用服務軟件和數據庫服務器構成。

在抽取關鍵需求的過程中，抽取與業務無關的需求非常重要。“與業務無關”指支撐業務功能運行且與業務處理邏輯無關的功能。傳輸服務是典型的與業務無關的功能，在任意基于網絡運行的軟件中，不可避免的需要信息傳輸功能的支持。抽取與業務無關的需求，需要分析人員有豐富的軟件設計經驗，這種公共需求的抽取，有利于開發過程中軟件的重用，可降低開發成本。

2.2 關注需求中與規模發展相關的因素

軟件設計應用規模的發展速度，是軟件結構設計時應考慮的主要需求之一。規模是考驗軟件支撐能力的主要因素。規模的發展可能是用戶量的膨脹，也可能是數據量的迅猛增長，或兩者都有。軟件能力的成長性設計，通常會使開發付出代價，這是由于一方面在設計初期沒有考慮這種成長性，導致設計失?。涣硪环矫?，雖然考慮了成長性，但由于軟件復雜度的增大，增加了開發成本和風險。因此，對并發和負載的設計，應在設計之前就要給予充分考慮。

2.3 捕捉需求的變化方向

確定需求的增長點是考驗軟件適應能力的關鍵。需求的變化和調整是客觀存在的，軟件設計者分析需求時，應考慮到需求中可能存在的變化點或變化趨勢，以提高軟件的適應能力和成長能力。需求的增長點通常隱含在企業發展和技術發展中，一類是業務發展引起的工作流變化或增長。這種軟件結構應具備新業務處理軟件的集成能力；一類是業務轉向。原有的業務處理軟件不能滿足轉向后的業務處理要求，存在改造、裁剪、新增能力等潛在需求。軟件結構還應具備可裁剪、可擴充的能力，否則將會造成巨大的經濟損失。

抓住需求的變化點，設計合適的體系結構，可增強軟件的生命力。面對需求多變的現實，降低結構的耦合度是有效緩解軟件適應能力的方法之一。但是，降低耦合度一般會帶來效率或系統復雜度的上升。因此，小型軟件選擇這種方法應慎重。（下轉第16頁）（上接第13頁）

綜上所述，設計滿足需求的軟件結構，重點關注的是功能，而設計適應需求變化的軟件結構，關注的往往是非功能性需求，這需要系統設計師除了具備豐富的經驗和敏銳的洞察力外，還應花大量的時間和精力同用戶不斷溝通與交流，從中獲取最需要的需求，以支持軟件整體結構的設計。

參考文獻：

篇8

【關鍵詞】計算機體系 結構軟件模擬技術 分析

雖然軟件模擬技術在計算機體系結構上的應用起步較晚，但是已經取得了一定的成就，在現代處理器或計算機系統設計中，體系結構軟件模擬技術已成為一個不可缺少的環節。盡管如此，軟件模擬技術仍然存在著許多的問題，由于軟件模擬技術的開發工藝比較復雜，還需要花費大量的時間對其進行標準測試，所以為了能夠讓它在計算機體系結構方面的應用能夠達到人們對計算機能力日益增長的需求，需要對計算機體系機構軟件模擬技術進行分析。

1 計算機體系結構軟件模擬技術存在的問題

1.1 軟件模擬技術的開發難度比較大

由于計算機的機構極其復雜，當前如果要將計算機里邊的晶體管和電路全部通過模擬技術實現是不太現實的操作，所以只能采取結構簡化措施，按照一定的層次分配對計算機的體系結構進行簡化。但是在同等情況下，計算機體系結構在簡化之后依舊相當的復雜，不利于軟件模擬技術的開發。所以，為了能夠解決計算機體系結構軟件模擬技術在應用過程中的這一難題，編程人員經過研究發現可以使用C語言當中的功能語言來開發相對應的模擬軟件。這種方式下開發出來的軟件和其它方式開發的軟件相比，具有明顯的優勢，比如在使用過程更不容易出錯，還可以減少對能源資源以及時間的消耗。當前我國在軟件模擬技術開發方面的工作，基本上都是在原本的模擬器基礎上開始的，并沒有嚴格遵守從最開始的步驟出發的要求，由于軟件模擬技術的復雜性，讓許多開發出來的軟件在推廣使用之前受到廣大用戶的質疑。因此在軟件模擬技術的開展工作上，需要加大對軟件設計的力度，以提高軟件運行的準確性。

1.2 模擬器的設計時間長

計算機主機上的一大重要運行程序就是模擬器，在模擬運行系統運行過程的時候，記錄處理器運行的狀態一般都是利用時鐘級別以上的記錄器。在這種狀態下包含大量的數據在當中，在模擬運行速度方面產生了直接的影響。目前我國最快的模擬器運行速度遠遠慢于計算機主機的硬件運行速度，通過軟件模擬技術讓處理器的運行速度不斷提高，為能夠同時提高軟件模擬技術的測試運行性能，相關組織也相應的了測試標準程序，解決因測試耗費的時間過長而引起的低工作效率問題。

1.3 軟件模擬技術中模擬器的運行結果有待提高

當前我們主要把計算機體系結構模擬器開發的主要過程分為三個階段，其一是目標體系的構建，其二是模擬器結構的設計，其三是模擬器的實現。這三個階段中目標體系的構建主要是針對迷你軟件的開發，是它開發過程中的一個重要環節，但是在運行結果方面存在很大的缺陷。第二個階段出現的問題主要體現在它的細節方面，雖然這個過程中能夠對計算機的體系結構目標具有比較明確的理解，但是容易出現細節性的錯誤。綜上所述，軟件模擬技術在測試運行結果的時候需要特別注意一些運行方面的錯誤，避免給模擬器運行的結果帶來嚴重的影響。

2 提高計算機體系結構軟件模擬技術的有效措施

2.1 相應的減少模擬器運行的參數

為了能夠提高計算機的運行速度，可以針對計算機的運行過程是用一些具有代表性的測試參數，并適當對一些模擬器的測試程序進行修改，以減少模擬器運行的參數，提高模擬器運行的測試效果，節約程序測試的使用時間?？梢噪S意選去一些模擬器的運行參數，將它們設置在模擬器設置中，執行的結果為最終結果，如果參數的訊息可以在模擬器中找到對應的結果，則可以將其參數保存，反之則可以進行刪減。通過減少運行參數的方式，不僅提高了運行的速度，還可以減少測試過程的誤差，降低錯誤率，提高軟件模擬技術在計算機體系結構方面的運用。

2.2 減少模擬器運行指令的數量

計算機作為當代社會信息傳播的主要方式之一，在運行過程中需要消耗大量的數據，所以如果要對其運行過程進行全面的模擬，需要在程序中添加大量的運行指令來滿足要求，而這些指令也正是運行耗費大量時間的關鍵所在。所以，為了能夠很好的解決這一弊端，隨著我國科學技術的不斷進步，以及對軟件模擬技術的深入研究，發現如果采用全部的指令來完成軟件的模擬工作是行不通的，但是如果只是采用其中的部分指令，讓這部分指令的運行過程來代替全部指令的運行過程，將讓模擬效果大幅度提高。因此同時也面臨著一個重要難題，在眾多的指令中應該如何取舍才能完美的取代全部指令的運行過程。在做出指令選擇的時候需要了解各指令之間的差異，對它的運行效果有所了解，然后進行篩選，在保證不直接影響模擬效果的前提下，選出具有代表性的指令。當前主要的指令選擇方式有兩種，一個是直接選擇指令，另一個是通過統計學的方式對指令進行選擇。

3 結語

隨著我國信息的傳輸量大幅度提高，對計算機體系結構要求的提出的更高要求，軟件模擬技術被大量的推廣和應用，在計算機的發展過程中起到重要作用，對這項技術進行分析就是為了能夠促進這項技術更好的發展。

參考文獻

[1]李明樹，楊秋松，翟健.軟件過程建模方法研究[J].軟件學報，2009（03）.

[2]許建衛，陳明宇，楊偉，潘曉雷，鄭規，趙健博，孫凝暉.計算機體系結構模擬器技術和發展[J].系統仿真學報， 2009（20）.

[3]王杰生，李舟軍，李夢君.用描述邏輯進行語義Web服務組合[J].軟件學報， 2008（04）.

篇9

中圖分類號：G642

摘要：分析軟件工程專業的崗位需求和知識結構，提出適合地方性應用型高校的軟件工程專業核心課程設置方案和體系結構。關鍵詞：地方高校；軟件工程；課程體系

0 引言

進入21世紀，以互聯網為核心的網絡與應用得到快速發展，信息技術的應用模式發生了巨大變化。在開放、動態、復雜的網絡環境下，靈活、可信、協同的計算資源、數據資源、軟件資源、服務資源等各種信息資源的共享和利用、無處不在的普適計算、主動可信的服務計算，均對軟件工程提出了巨大挑戰。

黃淮學院軟件工程專業是河南省省級特色專業，近年來緊緊圍繞培養“就業能稱職、創業有能力、深造有基礎、發展有后勁”的高素質技術技能型人才的目標定位，積極推進應用型人才培養模式改革，緊扣產業辦專業，牽手企業促學業，強化職業促就業，不斷提升專業價值，全面提高應用型人才培養質量。作為本科層次教育，重視較寬厚的基礎知識的傳授；作為應用型人才的培養定位，重視面向生產、經營、管理實際，面向經濟社會活動實際，培養運用所學知識分析問題、解決問題的能力，同時也要培養學生適應社會的能力、創業發展能力。應用型本科院校課程體系的設計應有其內在的規律與特定的模式?；诖耍P者以黃淮學院為例，對這一問題做如下探討。

1 軟件工程課程體系建設原則

原則1：構建課程體系的重要原則是核心課程體系的構建。核心課程體系的構建不是計算機科學專業課程和軟件工程類課程的簡單堆砌，而是對計算機學科課程進行有效的裁減和調整。對比軟件工程學科和計算機科學技術學科可以看出，計算機科學的主要目標是為解決計算問題尋找有效的、能產生更好性能的途徑；軟件工程的主要目標更注重具體方法和技術的應用，軟件工程除了關注解決軟件問題的理論、原則、方法和技術，還關注軟件質量、軟件過程、項目管理、團隊合作、與用戶/客戶相關的問題，研究的對象是軟件開發過程中的所有活動。軟件工程專業的培養目標是合格的軟件工程師，具有更明確的職業特性。

原則2：應用型本科高校軟件工程專業不是簡單復制211或985高校的課程體系，而要根據培養“就業能稱職、創業有能力、深造有基礎、發展有后勁”的目標，結合實際工作崗位職業需求，基于傳統本科教育與職業教育相互滲透的培養理念，在通才與專才之間尋找平衡點，專業知識體系夠用為主，“軟、硬并重”，以第一課堂為核心，以行業、企業和管理服務崗位對人才知識、能力、素質的具體要求構建課程體系。

原則3：權衡軟件工程專業本科畢業生所應具備知識的深度、廣度和適應性。在大學教育期間，學生應學習的知識大致可以劃分為4個.方面：人文社會科學知識，這是做人之根本；數學知識，這是軟件工程專業的底層基礎；專業知識，是軟件工程學科之特色；相關領域知識，是學生就業之砝碼。知識是基礎，能力是知識的綜合體現。對于軟件工程專業的學生應該著力培養以下能力：專業必備的開發、設計能力，能終身受用的學習能力，培養領導力的處事能力和積累財富的創新能力。在注重學科知識的系統性和嚴謹性基礎上強調實際能力培養的重要性。

2 軟件工程專業課程體系基本構架

黃淮學院軟件工程專業知識體系如圖1所示，該知識體系以人文外語知識和科學基礎知識為基本，軟件工程專業基礎知識為中堅，軟件工程與軟件管理專業知識為塔頂，輔以實踐和頂崗實訓構成軟件工程專業知識體系金字塔。

人文與外語知識包含由教育部統一要求的思想政治類課程、大學英語、專業外語以及創新創意和職業規劃方面的拓展課程；學科基礎知識則涉及數學系列課程、電子基礎課程和計算機科學基礎課程；專業基礎知識和專業技能知識包含程序設計基礎、軟件工程和軟件管理等，具體教學過程中可以涉及部分軟件工具和軟件產品作教學載體。針對軟件行業普遍反映的畢業生獨立解決問題能力不強、責任心差、對問題進行抽象和分析的能力差的問題，設計了如圖2所示的實踐能力漸進培養模式，該模式貫穿在課程教學、實驗、實訓和畢業設計等教學過程中。

3 軟件工程課程系列的設計

黃淮學院軟件工程專業的課程體系既考慮了工程性、技術性、實用性、系統性、綜合性和復合型，又注意到強化基礎在有效解決復雜軟件的構造和應用方面能起到關鍵性作用，采取了根據就業崗位的能力需求進行知識分解，由課程模塊構建系列課程，分階段互動式的課程設置方法。具體安排如圖3所示。

從圖3可以看到基礎知識教學階段共2學年，這樣設計是為了強化學生基礎知識，實現“基礎扎實、學科認知和專業融入”的目標。公共基礎系列課程針對人文與外語知識，學科基礎理論系列課程的啟動從數學基礎課程系列和計算機導論開始，內容貫穿軟件工程所涉及的計算機系統、程序設計語言、軟件工程、網絡技術等專業基礎知識的知識點以及與信息技術有關的社會人文等知識，力求使學生對所學專業有比較深入的了解，樹立專業學習的責任感和自豪感。其中包括高級語言程序設計、程序設計基礎、數據結構和面向對象程序設計，旨在引導學生領會計算思維的同時訓練其編程能力；硬件與網絡系列課程包含數字邏輯、計算機組成原理和計算機網絡，軟件工程系列基礎課程包括操作系統、數據庫系統原理和WEB程序設計，這樣安排力求達到“編程、網絡和應用開發”三位一體的教學目標。

專業技能教學階段共設36周，設計思路是強調對學生工程性、技術性、實用性、系統性、綜合性和復合型能力的培養，實現“熟悉軟件工程技能、樹立系統概念和掌握軟件設計開發技術”3個目標。在這一階段中，綜合考慮主干專業課程和特色課程的設置，基于辦學特色設置若干動態可擴充的課程模塊，全面考慮課程之間的關聯，強調統一設計、統一規劃。所有方向以系統分析與建模、軟件工程、軟件測試技術和嵌入式系統為基礎，學生必須選修WEB程序開發和嵌入式軟件兩個專業方向中的一個課程模塊，WEB程序開發方向設置網站前臺開發技術、數據庫應用技術、軟件框架技術、軟件需求工程和現代軟件開發技術；嵌入式軟件專業方向開設單片機與接口技術、嵌入式Linux程序設計、移動編程技術、手持設備軟件開發和嵌入式系統開發綜合實踐，同時要求至少選修4門任選課以拓展專業知識。

工程實習教學階段開設在第4學年，設計思路是通過具體項目參與真刀真槍的項目訓練，通過畢業設計與論文培養總結概括能力，實現理論與實際結合、技能與職業素質結合的目標。

在軟件工程專業的課程體系設計中還應充分考慮課程間的銜接性、系統性和創新能力培養。教學計劃中通過設置10門設計類課程，加強課內實踐教學，常設性的學生軟件設計比賽如ACM競賽和軟件設計大賽也被引入教學過程中。上述思路形成的課程體系更細化的結構如圖4所示。

4 結語

一個好的軟件工程課程體系應該在一個或若干個應用領域方面體現出自己的特色，為了幫助學生在適當的深度上學習其他應用領域的知識，軟件工程課程體系應該安排相應的支持課程。軟件工程的應用領域如此廣泛，軟件工程課程體系不可能也不應該面面俱到。在相關領導的支持下，黃淮學院軟件工程專業建設已取得了可喜的成果。軟件工程專業在2010被批準為河南省特色專業，2012年批準為河南省專業綜合改革試點專業，每年畢業學生到各大公司進行項目實踐，并推薦部分優秀學生到IBM等業界著名企業實習，獲得各公司的一致好評。這幾年的實踐表明，教學計劃的設計是確保培養目標實現的保障，課程體系的設計是合理安排教學過程的關鍵。學院軟件工程專業的每一位老師在這幾年的教學改革中付出了辛勤的勞動，但回首軟件工程專業取得的進步，大家都感到心情舒暢。高等院校的教學改革是永恒的主題，作為應用型本科院校軟件工程專業的課程體系更應與時俱進，我們一定會在現有基礎上進一步優化軟件工程專業的課程體系，以期獲得更好的結果。

參考文獻：

[1]楊青，劉洪星.軟件工程學科的特征及其課程體系設計原則[J].武漢理工大學學報，2005，27（2）：183-186.

[2]曾永衛，林志剛，楊堯彪.應用型本科院校課程體系頂層設計的探討[J].湖南工程學院學報，2007，17（3）：65-67.

[3]祁文青，紀鵬，馮運仿，等.計算機類應用型本科的人才定位和課程體系[J].黃石理工學院學報，2012，28（1）：60-63.

篇10

關鍵詞：明挖車站；SAP2000；車站結構；板單元；殼單元；風道；

中圖分類號：U231文獻標識碼： A

一．概述

明挖地鐵車站的計算通常采用平面剛架結構模型[1]，在與線路垂直方向截取尺寸，荷載條件不同的截面進行車站橫斷面計算，再沿線路走向截取縱斷面，計算梁柱受力。這種計算方式有著計算模型受力機理清晰，建模簡便，設計保守的優點，但相對于車站三維整體建模，二維模型也有其弊端：首先二維模型對于車站斷面形式變化較少的車站相對簡便，但如果車站斷面形式多樣，尤其是縱斷面需要不止計算一種的情況下，其計算量會非常大，因為其縱斷面，每段梁的荷載需用板帶法進行手動計算再進行進行施加，如果柱跨不均勻，車站寬度變化多，會大大增加建模工作量，而三維整體建模只需建模一次，并且無需手動計算梁單元荷載，所以相對于三維維整體建模，二維模型計算并不一定能做到簡便省時；從受力考慮，二維模型計算沒有考慮板的縱向剛度，即板不能與梁共同承受彎矩，這顯然不合理，會造成梁單元彎矩比實際大，造成經濟浪費；另外由于平面模型自身的局限性，無法模擬側墻風道出入口開洞，盾構開孔，中板開孔等細部計算。因此需要適時考慮應用三維模型計算，減少工作量，提高結構設計的可靠性和經濟性。

二．明挖地鐵車站結構

明挖車站結構不同于地上混凝土框架結構，其頂，中，底板極少采用雙向板肋梁樓蓋與無梁樓蓋結構，但也不同于單向板肋梁樓蓋，通常，延線路方向梁為主梁，在垂直于線路方向的位置，只有設置扶梯吊鉤與車站高度寬度變化等位置才設置次梁，一般只有單方向的主梁；明挖車站沒有基礎，其底板結構即是基礎結構，以溫克爾彈簧的連接方式作用于地基土體；側墻是車站結構的主要承重結構，車站側向土體土壓力作用在側墻上，平衡于頂、中、底板的軸力。車站頂板，底板與側墻連接處通過腋角增強剛度。在整個受力體系中，墻、板結構發揮了重要的作用，這與以梁柱結構為主的地上混凝土框架結構形成了鮮明的對比。在這種情況下，板結構不能簡單的歸為單向板還是雙向板，而是在SAP2000軟件中，通過單元網格劃分，與梁柱體系協同受力。

在SAP2000軟件中可以實現面單元的網絡劃分，通過網絡劃分后的板單元，其邊緣處的梁單元也自動進行劃分并于劃分后的板單元共用節點。根據車站結構體系的特點，面荷載需施加“均布荷載”而不是“均勻分布到框架”，實際計算中，如果采用“均勻分布到框架”的方式施加荷載則結算結構明顯比實際偏小。

三．明挖車站結構在SAP2000有限元軟件在有限元軟件中的實現

3.1 工程概況

本次分析選取蘭州市城市軌道交通1號線一期工程拱星墩站，位于城關區現狀道路東崗東路與焦家灣路丁字路口處，車站沿東崗東路東西方向鋪設。標準段：寬度為20.10~20.70m，總高13.54~14.23m，結構底板埋深約17.36~18.05m；盾構加深段：寬度為30.60m，總高14.87m，結構底板埋深約18.24m。中心里程處結構頂板覆土厚約3.82m。

拱星墩站所處場地地基土自上而下為：地表一般分布有人工填土；其下為全新統的沖積黃土狀土、卵石，底部為下更新統卵石。

3.2主要構件材料及尺寸

1) 材料的選擇須滿足結構強度及耐久性要求，按照《混凝土結構設計規范》[2](GB50010--2010)及《混凝土結構耐久性設計規范》[3]((GB／T50476--2008)要求，主要受力構件材料選取如下：

混凝土：頂、底板和側墻混凝土強度等級為C50，抗滲等級為P12，中板為C35，柱為C50，素混凝土墊層為C20；主筋采用HRB400

2)主要構件尺寸

標準段：頂板厚800mm，中板厚400mm，底板厚900mm。頂、中、底板與內襯墻支座處均設斜托局部加厚

3.2 模型實現

SAP2000是獨立的基于有限元的結構分析和設計程序。它提供了功能強大的交互式用戶界面，帶有很多工具幫助快速和精確創建模型，同時具有分析最復雜工程所需的分析技術[4]。 SAP2000默認情況下有兩個操作窗口，可以在這兩個操作窗口中可以分別設置顯示模式，顯示對象和結構激活、鈍化情況，非常方便，另外與Midas軟件不同，SAP2000可以在劃分單元網絡之后，可對劃分后的單元進行整體指定操作，例如施加荷載，定義截面、邊界條件等，它還可以將劃分精細程度不同的相鄰板單元或實體單元實現變形協調。但在施加漸變荷載方面，SAP2000只能通過定義節點樣式來進行施加，不如Midas操作靈活。

在SAP2000中，板殼對象按照受力特點可以分為三類：膜單元、板單元和殼單元。膜單元只具有平面內的剛度；板單元與膜單元相反，只具有平面外的剛度，承受彎曲力，模擬薄梁或者地基梁等；殼單元的力學行為是膜單元與板單元之和，是真正意義上的殼單元。 墻板結構是明挖車站的受力主體。模型實現過程中的每一個細節，決定模型質量與受力分析的準確性。本次車站所有墻，板結構均采用殼單元進行模擬，并應選擇厚殼。其中，參數“Thickness of Membrane” 用于計算殼元或膜元的面內剛度和用于計算自重和質量(動力)；Thickness of Bending 用于計算板或殼單元的面外剛度，所以本次建模應將這兩個參數應與實際板單元厚度一致[5]。

3.3計算結果

圖3.1 車站整體框架體系基本組合彎矩圖

圖3.2 車站側墻基本組合彎矩圖

圖3.3 車站底板基本組合彎矩圖

圖3.4 車站中板基本組合彎矩圖

圖3.5 車站頂板基本組合彎矩圖

圖3.6 車站盾構端端墻基本組合彎矩圖

表3.1 二維三維模型計算結果對比

構件位置 二維平面計算基本組合彎矩(KN?m) 三維整體計算基本組合彎矩

(KN?m)

頂板標準段（跨中/中柱支座） 653/1071 760/1203

中板標準段（跨中/中柱支座） 95/170 160/250

底板標準段（跨中/中柱支座） 876/1121 1005/1477

側墻（跨中/與底板連接處） 246/970 430/1003

頂縱梁標準段（跨中/支座） 4733/6700 3446/4655

中縱梁標準段（跨中/支座） 1684/1972 892/1302

底縱梁標準段（跨中/支座） 5663/9100 4733/7889

4.結論

通過本次三維模型計算，得出如下結論：

1)通過三維建?？梢酝茢啵瑝?、板結構在明挖車站受力體系中發揮著重要作用，與梁、柱體系協同承擔荷載，三維計算結果表明真實情況下墻，板實際受力略大于二維平面計算結果，各主梁的實際彎矩小于二維平面計算結果。

2)車站與風道連接處，應確保變形縫量測梁的剛度和柱跨的合理性，減小頂板變形。

3)車站盾構擴大段與標準段連接處的底橫梁，跨中位置基本組合彎矩達到8000KN?m以上，應增強底橫梁截面上部配筋。

4)盾構端墻抗震柱兩側和第一層抗震柱之間的區域彎矩很小，建議盾構端墻采取在此類區域減少配筋。

5)車站各側梁，彎矩都處于較低水平，尤其是中板盾構端邊梁與平面計算出入較大。其梁的尺寸和配筋還有優化余地

參考文獻：[1]李興高，張彌．地鐵車站結構內力計算中的問題[J]．都市快軌交通．2005，18(5)：26―30．Li Xinggao，Zhang Mi．Problems in Internal Force Calculation ofMetro Station Structure[J]．Uraban Rapid Rail Transit．2005．18(5)：26―30.

[2] 中華人民共和國住房和城鄉建設部．GB50010--2010混凝土結

構設計規范[s]．北京：中國建筑工業出版社。2010．

[3] 中華人民共和國住房和城鄉建設部．GB／T50476--2008混凝土

結構耐久性設計規范[S]．北京：中國建筑工業出版社．2008．