前言：中文期刊網精心挑選了軟件體系結構范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
軟件體系結構范文1
[關鍵詞]軟件工程 開放式數控 集成系統
目前,軟件體系結構(software architecture)已經成為新一代數控技術的研究熱點,許多國家和研究機構在這個領域都開展了深入的研究。已經越來越受到研究者和實踐者的重視,并成為軟件工程的一個重要的研究領域。在軟件開發過程中,軟件體系結構提供系統的高層抽象、支持開發人員之間的交流、支持軟件復用等,因而體系結構的設計在軟件生命周期中起到關鍵作用。體系結構設計本身是一個不斷做出決策的過程,產生大量的推理信息。
一、自動測試系統軟件體系結構
目前通用自動測試系統的軟件體系結構主要依據IEEE的寬域測試環境標準。ABBET將測試系統劃分成5個層次:產品描述層,測試需求/策略層,測試程序層,資源管理層和儀器控制層。并行自動測試系統具有串行自動測試系統的基本特性,其核心測試過程與串行自動測試系統的核心測試過程是一致的,因此,并行自動測試系統的軟件體系結構也采用層次化的體系結構風格。
自動測試系統軟件體系結構與傳統串行自動測試系統的軟件體系結構的不同在于其任務,資源管理層更加復雜。由于多任務的并行執行,在這一層中不僅資源管理的功能需要擴展,以滿足測試資源安全共享的要求,還需要對測試任務進行管理,根據任務過程模型和任務調度模型合理調度任務的執行。
二、開放式數控的軟件體系結構
數控系統是一個具有實時性和多任務性的專用操作系統。從功能來看,系統的任務可以分為管理任務和控制任務兩大類。管理任務主要完成系統資源管理和系統各子任務的調度,負責系統的程序管理、顯示和診斷等子任務;控制任務主要完成數控系統的基本功能,包括譯碼、刀具補償、速度預處理、插補運算和位置控制等子任務。如圖1所示。
資源分時共享主要采用的方法是循環輪流和中斷優先,如圖2所示,系統在完成初始化工作以后自動進入時間分配環中,在環中依次輪流處理各任務,對于系統中一些實時性很強的任務則按優先級排隊,分別放在不同的中斷級別上。
三、COTS軟件系統的軟件體系結構
軟件體系結構是由一些實體和這些實體間的關系所構成的模型,在體系結構觀點中實體是所關心的元素,它們可以是軟件組件、源文件、目標文件、編譯器、平臺等;關系可以用描述連結性、動態行為或者所關心的依賴性的任何其他類型 。體系結構中所使用的特殊的實體和關系取決于建造者試圖傳送的信息。
COTS 軟件系統的開發本質上是集成黑盒軟件組件的問題。這種集成過程是困難的,它容易出錯,需要大量的編碼,難以測試和調試。此外,許多COTS 組件都有高的短暫性,商業組件通常要頻繁升級,這些升級可能沒有增加集成者所希望的功能,或修復集成者所希望的錯誤。存在于先前版本中的關鍵功能可能在隨后的升級版本中被除去。在有些情況下,集成者可能希望用不同供應商的新版本的類似組件替換老組件。在COTS 軟件系統中,體系結構的設計合適與否直接關系到軟件的成功,因為體系結構是系統實現的藍圖,為組件的集成提供了上下文,很大程度上決定了系統的各種性能。在COTS 軟件系統中,體系結構中的實體就是COTS 組件,關系用以描述集成機制。
現今新的技術層出不窮的情況下,準確地把握系統當前的行為,能夠讓開發人員和維護人員盡快地進行技術上的調整,而能保持原有的行為效果不變。這對于節省開銷,保持程序的穩定性都有重大的意義。在今后的研究工作中,將著力于改善方法中對于接口信息的定義形式,使其能提供更強的描述功能。此外,還將嘗試引入一定的動態分析工作,這有助于為我們方法提供對象在動態運行時的變量信息,根據這些信息對對象的行為方式進行更深人的分析。
參考文獻:
[1]Yang Jinlin:Evans n Dynamically Inferring Temporal Proper―ties[C] }Proc.the ACM-SIGPLAN-SIGSOFT Workshop onProgram Analysis for Software Tools and Eng]neering.2004:23―28
[2]Yuan Hai Xie Tao:Automatic Extraction of Abstract―object―state Machines Based on Branch Coverage[C] {Proceedings ofthe 1st International W orkshop on Reverse Engineering To Re―quirements at WCRE 2005(RETR 2005).November 2005:5-11
[3]黃洲 彭鑫 趙文耘:基于依賴性分析的對象行為協議逆向恢復[J].計算機科學,2008,35(8):265―268,276
[4]Tang Mei-huei,Wang Wen-li,Chen Mei小wa.A UML Approachfor So ftware Chang e Modeling.CS.albany.edu
[5]http:∥compilers.as.uclm edu/jtb/jtb-2003
[6]javac~dev.java net
軟件體系結構范文2
關鍵詞：軟件體系結構；描述語言；設計
軟件體系結構開發是大型軟件系統開發的關鍵環節。軟件體系結構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。本文主要從軟件體系結構一些理論知識進行了闡述。
1.軟件體系結構描述語言
軟件體系結構描述在軟件工程師提高軟件系統的描述和理解能力方面起著非常重要的作用，但是現在的描述基本上都比較隨意且非形式化。對體系結構設計進行形式化分析和模擬是非常困難的，同時構架師在完成設計工作時也缺乏相應的支持工具。所謂體系結構描述語言(Axehitecture Deseri Ption Language，ADL)就是指為了解決上述問題，用于描述和推理的形式化語言得以發展。軟件體系結構設計的可理解性和重用性是體系結構描述語言所尋求的。體系結構描述語言刻畫體系結構的概念框架主要通過提供具體的語法來實現，使得系統開發者設計的體系結構能夠更好地被他們所描述，以便與他人進行交流。提供一種規范化的體系結構描述是體系結構描述語言的主要目的，這樣體系結構的自動化分析實現的可能性更大。軟件體系結構還有統一的定義，本文中所提的定義是普遍的一種，那么體系結構描述語言也存在很多定義。目前比較廣泛的認可定義是：ADL是一種為概念體系結構提供描述機制的語言。但這樣的定義太籠統，所以還給出了進一步的要求：ADL必須提供對組件、連接件和體系結構配置的支持，至少組件必須有接口，配置的定義必須和連接件分開。
2.軟件體系結構設計
2.1數據流風格的結構
數據流風格的結構可以很清楚地找到數據流，在數據流路線上，處理過程遵循“自頂向下、逐步求精”的原則。處理過程是不依賴于數據到來的順序，而是依賴于執行過程。批作業序列風格、管道/過濾器風格是最典型的數據流風格。在管道/過濾器風格的軟件體系結構中，每個構件都會存在一組輸入和輸出，輸入的數據流通過內部處理產生輸出數據流。完成這個過程通常通過對輸入流的變換及增量計算來進行，因此，輸出在輸入被完全消費之前就產生了，即 這構件就是過濾器。此風格對于過濾器的獨立的實體比較注重。過濾器進行增量計算過程的順序不能影響一個管道/過濾器網絡輸出的正確性。管道/過濾器風格的體系結構具有以下特點：（1）組件具有良好的隱蔽性和高內聚、低耦合的特點。（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成。（3）支持軟件復用。（4）支持并行執行。
2.2倉庫風格的體系結構
在倉庫風格中，組件有兩種，分別為中央數據結構和獨立組建，前者用于說明當前狀態，后者在中央數據存貯上執行，在系統中，倉庫和外組件間的相互作用會有很大的變化。選取的控制原則產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一個傳統型數據庫；系統中的組件通常包括數據存儲區，以及與這些存儲區進行交流的進程或處理單元，而連接器則是對于存儲區的訪問。這類系統中，主要是通過共享的數據存儲區來完成數據處理進程之間的聯系。另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。黑板系統主要由三部分組成：（1）知識源。知識源是不直接進行通訊的，它是通過黑板來完成之間的交互，知識源主要包含獨立的、與應用程序相關的知識。（2）黑板數據結構。知識源通過不斷地改變黑板數據來解決問題，黑板數據組織的解決問題的數據是按照與應用程序相關的層次來進行的。（3）控制?？刂仆耆珊诎宓臓顟B驅動，黑板狀態的改變決定使用的特定知識?？蓴U充性比較強、模塊間耦合比較松散是倉庫風格構架的顯著優勢。
2.3調用/返回風格的體系結構
在大型軟件開發中，調用/返回風格的體系結構就是其主流風格的體系結構。在此系統中，調用/返回關系較明確，其風格可分為：主-子程序風格，面向對象概念中的對象體系結構風格，層次型系統風格。（1）主-子程序風格體系結構主要在結構化程序設計當中應用，它是一種經典的編程范型。將程序劃分為若干個小片段是此體系的主要目的，大大提高了程序的可更改性。主-子程序體系結構的主程序位于一層，可以再在下面劃分一級子程序，甚至更多，由此可知，其具有一定的層次性。在這里值得注意的是主-子程序體系結構風格是單線程控制的。在相同的時間點上，父親結點控制只有一個孩子的結點的子程序。（2）對象風格的體系結構。抽象數據類型概念對軟件系統有著重要作用，這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的組件是對象，對象是一種被稱作管理者的組件，因為它負責保持資源的完整性(例如實現對屬性，方法的封裝)。對象是通過函數和過程調用來交互的。（3）分層風格的體系結構是將系統組織成一個層次結構，每一層為上層提供服務，并作為下層的客戶端。層之間的連接器（conector）通過決定層間如何交互的協議來定義。由于每一層最多只影響兩層，每層可以用不同的方法實現，為軟件復用提供了強大的支持。
軟件體系結構范文3
信息化時代使計算機得到了大范圍推廣和運用，而在計算機科學技術的發展影響下，軟件體系結構也呈現出日益復雜的趨勢，在軟件設計中，軟件體系結構對軟件有著指導與控制的作用，組件在軟件技術中有著非常重要的影響。本文主要對軟件設計中軟件體系結構與組裝進行研究，討論軟件體系結構與組件的原理與意義，通過其所具備的特點進行分析，探討軟件體系結構與組裝軟件工程在軟件設計與開發中的作用與發展前景。
關鍵詞：
軟件體系結構；組件；軟件工程
近年來，信息化的急速發展使計算機與網絡得到了普及與使用。而在計算機與軟件行業，技術的發展更為迅速，各類應用技術不斷的出現，帶動了行業的發展，但是在發展的同時，還有大量的遺留系統的存在，這在一定程度上影響了現有的軟件系統的發展。在此行業內，計算機技術與軟件技術一直是業內人員所研究的問題，而軟件體系結構與組裝軟件工程在軟件技術中占據著非常重要的地位，其為軟件的設計、開發、應用起到了指導的作用，也為軟件的開發帶來了一定的轉變。
1軟件體系結構與組件技術
大規模工程軟件系統與小規模程序設計存在著根本區別，一條程序語句不足以作為開發單位，而組件必須成為構造軟件的模塊?；诮M件的軟件開發已成為一個熱門研究領域，獲得商業界的關注，并產生了幾個組件互操作性模型。這些模型能幫助實踐者處理越來越復雜的軟件系統。軟件作為一種程序語言的體現者，其具有一定的復雜性，在軟件的開發中，軟件體系結構作為一種控制軟件的手段，其可以在一定程度上解決軟件復雜性所帶來的問題。在軟件體系結構的使用中，可以將軟件之間的相似性、通用性、潛在性都進行整合，利用軟件體系結構可以使軟件的開發與設計有一定的基礎，而不是從零開始摸索與創建，這在一定程度上節約了在軟件程序的開發上所需要應用的時間與成本。為此，體系結構顯式給出軟件系統的結構，將系統中的組件計算與它們之間的交互分離開來，在任何改變影響實現之前，提供了可供管理和分析系統的高級模型。在理論上，軟件體系結構所具備的是對軟件的一種理論性的、完善的組件工程，其核心內容是使組件在設計、配置等方面有更高層次的開發與應用，是為了實現組件理論上開發的定義。它們是用已有的組件來開發復雜系統的兩個不同方面。軟件體系結構是可重用軟件組件的一種自然補充，已有的組件中間件技術是以組件為中心的，著重對外部組件屬性進行標準化；軟件體系結構是以系統為中心的，更強調連接和作為一個整體的系統的屬性。
2復合軟件體系結構要求
2.1允許各個風險承擔者之間對系統進行通信。風險承擔者包括顧客、設計師、管理者、組件開發者、系統集成人員、用戶等等。允許在高于源程序的抽象級上理解系統，對系統進行推理，更接近風險承擔者心目中的系統模型。
2.2減少“問題”空間中的系統需求與“方法”空間中的軟件設計之間的鴻溝。支持重用與應用程序家族，將遺產項目中的成功設計和進化屬性轉換為代碼。
3組件技術協調軟件體系結構
已有的組件中間件技術，如CORBA，ActiveX和JavaBeans，是以組件為中心的，主要關注標準化外部組件屬性—接口、封裝、綁定機制、組件內通信協議及關于運行時環境的期望。相反，軟件體系結構及其風格以系統為中心，集中定義黑盒組件通信的系統，分析最后得到的系統的屬性，產生“膠水”代碼綁定系統組件。組件中間件技術和軟件體系結構都是基于組件的軟件開發的關鍵因素，然而在這兩個領域之間存在著驚人的有限的交互。不同的焦點暗示了跨越這兩個領域之間鴻溝的可能：使用已有的組件中間件技術來實現用體系結構技術建模的系統。
4組件對體系結構的要求
組件的應用受到多方面因素的影響，而軟件體系結構只是其中的一種，而為了保證組件在市場中的價值與應用的成功，其主要的體系結構因素有以下幾種。
4.1多種組件粒度。體系結構底層結構必須既支持小組件，也支持大組件，從簡單的數據結構到大規模的數據庫。然而大多數較大的組件無疑是用較小的組件構造的，較大的組件能夠為設計者提供更有意義的功能封裝。
4.2組件可替換性。在體系結構中，其中的底層結構要保證組件之間的可替代性，在結構中，可以應用與原有的組件等價的組件進行組件之間的替換與刪除。
4.3用多種程序設計語言開發組件。由于不同的程序設計語言具有不同應用領域，再加上新的語言層出不窮，體系結構底層結構必須支持用不同的程序設計語言開發組件。
4.4用戶接口合成。有許多組件并沒有用戶接口，而一些領域和組件具有一成不變的用戶接口。體系結構底層結構必須支持將多個組件用戶接口復合成單個統一的完整的用戶接口。
4.5組件的簡單分布。在軟件體系結構中，體系結構對底層結構的要求是達到其在理想情況的設計下進行簡單的分布，這樣有利于在實際的底層結構封裝與分布的多樣性與簡易性。同時，在市場的要求下，組件的簡單分布可以滿足在使用時所應用的進行相關的組件任務。
5應用軟件體系結構與組件技術的優點
為了促使軟件開發有更良好的基礎，軟件體系結構與組件技術應具有的相應完善的特點來作為軟件開發與維護的指導依據，現舉例分析內核的應用，其主要內容有以下幾點。
5.1精巧的內核。如上文所述，應用軟件是非常復雜且龐大的系統，因此在軟件的開發與維護中要嚴格依據開發標準，而為了節省工作量，應利用精巧的內核作為軟件功能的集成體，從而減少工作的復雜性。在用戶的使用過程中，對計算機功能與軟件的應用并不是都需要軟件程序中的復雜擴展，因此，利用精巧的內核可以在很大程度上簡化用戶的使用操作，方便應用軟件，同時在應用內核時需要依據用戶的需要對內核的拓展內容進行添加，避免出現不必要的程序。
5.2擴展能力。擴展能力是建于內核的基礎上，對內核添加集成式的特性，將擴展集應用于內核中，幫助其增加新的擴展特性，從而在用戶的需求上添加相應的應用軟件的需求。
5.3減少對資源的占用。在應用軟件中，每一種特性都對資源有一定的占用，而利用內核的方式可以減少此類資源的占用率，從而方便使用。組件技術以其眾多的優點正逐漸走入業界人士的眼中，而隨之為軟件體系結構帶來的變革必將會為軟件的整體效能提高、軟件的劃時展帶來新的支持。
6結束語
在現今的信息化時代，軟件工程的應用與發展有著廣闊的前景，同時，軟件工程的發展需要在軟件開發中不斷的探索，追求進步，促使計算機的功能與網絡技術在人們的生產生活中的作用可以達到最大化。軟件的開發與拓展是非常復雜的工程，其發展與創新離不開軟件體系結構的指導與組件技術的應用。在軟件體系結構與組裝軟件工程中還存有一些不足之處需要改進，這就需要技術人員在此行業中不斷的創新與發展，為軟件的開發與使用奠定良好基礎。
參考文獻：
[1]應俊.軟件體系結構和組件軟件工程的分析[J].數字技術與應用,2015(8).
軟件體系結構范文4
關鍵詞： 軟件體系結構定義風格類型
一、什么是軟件體系結構
在所有對于軟件體系結構的定義中，我認為最有代表性的就是Hayes Roth所提出的：“認為軟件體系結構是一個抽象的系統規范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系?！边@樣的定義，我認為從根本上描述了軟件體系結構所要做的事情，是一個很概括的規范化公式。與此同時，在定義各式各樣的“構件”的時候，人們似乎一直在默認Dewayne Perry和A1ex Wo1f的定義，也就是：“軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組組合連接起來?！边@一定義將處理構件、數據構件和連接構件區分了開來，明確了這三者在軟件體系結構中的組件性質，將這三者視為軟件體系結構的標準組成及探討對象。
在此基礎上，反復提到的則是Mary Shaw和David Garlan所提出的：“軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。體系結構問題包括總體組織和全局控制、通訊協議、同步、數據存取，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數據結構之上關于整體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數據存取的協議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現等?！边@樣的定義，我認為進一步地提出了軟件體系結構的地位和所研究內容的具體情況，它提出了一個對于“控制”和“協議”的具體化要求，在以上定義的基礎上強調了軟件體系結構對于構架的調配和規劃功能，細分了軟件體系結構的內容。
除去Kruchten對于軟件體系結構“四個角度”，即概念角度、模塊角度、運行角度、代碼角度的定義，以及Barry Boehm和他的學生提出的關于強調“互聯及約束的集合”的概念之外，還有其他的定義方式。如Bass，Ctements和Kazman在1997年的《使用軟件體系結構》書中提出的：“關于一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。”其強調了“軟件外部的可見特性”，是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。這一定義的特點在于把軟件體系結構提升，或者也可以說是限制在了軟件的“表征特性”上，這使得軟件體系結構有了更緊縮、健康的概念。
我在思考對于軟件體系結構的定義的時候，并沒有一個標準的答案，因為我在拜讀其他名家的定義的時候發現，它們有著很多相似之處，也各自有著突出的特點與不足，這使得我無論是出于尊敬還是出于對自己認識層次的保留，都不愿意給出一個自己所謂的“定義”，但是可以說的是，所謂軟件體系結構，是一種思想方式，也是一種分析方式和控制方式，這種方式的對象，是軟件（廣義）的——主要是創建過程中的—結構和統一規范的建議，其表現形式是構件化的描述體系。這樣的一種理解方式，也就是我上面所提及的在前輩們定義的軟件體系結構中的三個要素：（1）構件性——軟件體系結構由三個構件組成：處理構件、數據構件和連接構件；（2）控制性——軟件體系結構的作用是在“控制”和“協議”層次上；（3）表征性——軟件體系結構的對象，是“軟件外部的可見特性”。
二、常見軟件體系結構風格
所謂軟件體系結構風格是指：“描述某一特定應用領域中系統組織方式的慣用模式?！彼从沉祟I域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。按這種方式理解，軟件體系結構風格是指：“定義了用于描述系統的術語表和一組指導構件系統的規則?！睂浖w系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是采用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。
軟件體系結構風格有很多種，現在我主要分析的是Mary Shaw和David Garlan所提出的五種主要風格類型，也就是：（1）數據流風格，包括批處理序列，管道/過濾器形式等；（2）調用/返回風格，包括主程序/子程序，面向對象風格，分層結構等；（3）獨立組件風格，包括進程通訊，事件系統等；（4）虛擬機風格，包括解釋器，基于規則的系統等；（5）倉庫風格，包括中心數據庫系統，黑板系統等。
這五種風格各有各的特點，也有共同之處，下面我將逐一分析這些風格。
1.數據流風格
這是一種最常見、結構最為簡單的軟件體系結構。在這樣的結構體系下，所有的數據按照流的形式在執行過程中前進，不存在結構的反復和重構。在流動過程中，數據經過序列間的數據處理組件進行處理，然后將處理結果向后傳送，最后進行輸出，這也就是說，最簡單和直接的數據流風格是單向的，沒有返回的流水線系統。但是在實際應用中，并不一定限制數據處理組件的順序，其運算的先后順序不影響最終系統結構的正確性。這種風格很容易用管道/過濾器的形式（見下圖）來解釋。
上圖所表示的就是一個管道/過濾器的形式，我在隨處可見的理論圖的原型基礎上只保留了其中必要的過濾器塊，而用三種不同形式的數據流表示了數據的行進過程，這三種情況分別是單向流水、非順序流水和回流。其中：
表示了一種正向的流水方式，也就是最常見的、最直觀的數據流方式，在這種方式中，正向數據管道引導數據的正向流動，在此時，我們可以將整個的上方三個過濾器所組成的正向通道作為一個完整的“管道”，這是一種廣義的管道。此時，數據從左方，也就是管道的入口處進入，再經過過濾器的處理，最終由“管道”的結尾處流出。
表示了一種打亂（更改）了順序的管道方式，交換了其中兩個過濾器的順序，這樣的結構在實際中是允許的，并且不影響管道/過濾器輸出的正確性。其前提條件是，每個過濾器必須是獨立的實體，它不能與其他的過濾器共享數據，而且一個過濾器不知道它上游和下游的標志。同樣，也可以把這樣的結構視為廣義的“管道”。
軟件體系結構范文5
關鍵詞:可信計算;食品安全;三流一體化;可追溯體系;軟件體系結構
中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)10-2398-03
Research on Software Architecture of Food Safety Traceability System Based on Trust Computing
CAO Ting, WANG Yan-xing
(College of Computer, Beijing University of Technology, Beijing 100124, China)
Abstract: Food safety is currently the focus of attention of the community problems. Food safety is the focus of current social problems concerning people's livelihood and we need to solve it in a timely and secure manner. Currently the existing food safety traceability system only rests on the trale of the information. So the realization of information transmission and circulation of the process that will not be tampering is an urgent problem to resolve. In this paper, taking meat for example, the credibility of the theory is applied to computer software system to work out a third-rate integration of multi-layer software architecture, which opened up a new idea for delivering the information in the food distribution safely and reliably.
Key words: trusted computing; food safety; three flow conformity; traceability system; software architecture
目前中國的肉類生產事故發生頻繁,現狀不容樂觀,從畜禽養殖、屠宰加工到最終消費的整條食物鏈均有涉及。從口蹄疫禽流感到瘦肉精事件,從加工生產病死畜禽到注水肉和毒火腿事件,肉類產品質量安全問題時有發生,從而導致消費者對肉類產品的信心明顯不足[1]。由此可見,建立合理有效的肉類食品安全可追溯體系勢在必行。
目前國內現有的追溯系統或者追溯工程最主要的問題是停留在信息的追溯上,但在食品安全追溯體系中信息的追溯僅僅是一方面,更重要的是保證信息傳遞的可信,也就是信息在傳遞和流通過程中不被篡改,這是食品安全追溯的最關鍵問題。提出三流一體化的體系結構是保證信息的可信傳遞的一個重要途徑,建立功能完善、具有較高復用性的三流一體的食品安全追溯體系結構模型,并對其功能要素和非功能要素進行評估,既解決了信息流通和傳遞過程中的可信度量,又為系統在更大范圍內應用提供了技術保障和理論支持。
1 可信計算對安全機制的保障與完善
1.1 可信計算的定義
各領域的專家分別從提供服務、關鍵要素以及行為目標的角度對可信進行了定義,總體來說,這些定義包含以下共同點[2]:
1)計算機系統所提供的服務是可靠的,而且這種可靠性是可以論證的;
2)目標是滿足客戶的信任,涉及安全性、隱私性、可靠性及商業信譽四個關鍵要素;
3)一個實體是否可信,取決于它是否始終沿著預期的方式(操作或行為)達到既定目標。
1.2 可信計算與安全的關系
可信計算和安全互為補充,相互依賴,可信計算彌補了安全機制根基不牢的缺陷,而安全機制又能夠為可信計算提供輔助支持,使得可信計算在復雜環境下也切實可行,能夠為上層提供服務。因此在設計重要信息系統的安全體系結構時,必須將可信計算和安全緊密結合起來,共同為系統安全服務。
1.3 相關理論模型
1)可信鏈傳遞模型
可信鏈傳遞是從一個可信的主體出發,通過一種可靠的方法(算法)確定主體周邊客體的確切屬性,從而獲知主客體構成的系統功能是安全的[3]。在可信計算平臺中,信任鏈的建立與傳遞涉及到三個基本的概念,一是信任根;二是可信傳遞;三是可信測量[4]。
2)無干擾模型
信息流的無干擾的思想最早在1982年由Goguen和Meseguer提出。其思想可以理解為:如果一個主體s1對另一個主體s2所能看到的和所能做的沒有影響,則稱主體s1對主體s2無干擾[5]。
3)干擾發現機制
所謂干擾發現機制,就是當度量范圍內出現干擾時,干擾發現機制可以及時發現,給出相應的處理,以保證能夠建立食品安全流通可追溯系統的信息環境。
三流一體化的軟件體系結構正是基于以上幾個理論模型提出的,通過建立一體化模型找出或屏蔽干擾,確保這個股食品流通節點處于可信狀態,有效地解決了系統的安全和信息傳遞的可信度量等難題。
2 三流一體的多層軟件體系結構
2.1 三流的定義
所謂三流,就是指物流,信息流和控制流。
物流:指豬肉從豬仔到成為客戶餐桌上的豬肉的過程中相關產品(如豬仔、白條、副產品等等)的流通過程。
信息流:指豬肉在養殖、屠宰加工和銷售各階段的相關屬性信息。包括兩類信息,一類是追溯信息,用于追溯食品的來源;另一類是基本信息,用于記錄生產者、經營者、消費者以及商品本身的具體狀況。
控制流:控制流是在豬肉商品流通環節中對信息實現控制的過程,通過采取適當的控制手段,保證在食品流通過程中每一步操作的合法性,合理性及安全性。
2.2 三流之間的關系
在現有的食品追溯系統當中,通常物流和信息流是彼此獨立的,無法保證在物流的某一環節信息的安全可信、不被篡改。在將要建立的體系結構模型中,通過增加控制流,對物流和信息流的信息在各環節實施監控和管理,既保持了物流和信息流原本形式上的相互獨立性,又增強了三流相互間的內在聯系,使其形成一個整體。
2.3 三流一體化流程的應用案例
本案例從豬的養殖階段出發對三流一體化的含義及特點進行了闡述。物流過程主要包括購買飼料和藥物,豬仔入舍,子豬和育肥豬飼養,豬的出場和運載。這一階段追溯信息的主要載體是豬耳標,控制流包括采購信息管理,飼養信息管理,追溯信息管理,同步監測管理,檢疫臺賬管理,此階段三流一體化流程如圖1所示。
2.4 可信思想在構件設計中的應用與體現
從食品安全可追溯系統的業務需求出發,在養殖、屠宰加工、銷售階段以及連接各階段的中間環節抽象出所需的構件,這些構件同樣遵循三流一體化的思想,可劃分為物流構件,信息流構件和控制流構件,如圖2所示。
控制流構件包括收購臺賬核銷管理、批發臺賬核銷管理、屠宰核銷、零售核銷、身份驗證等。碼的分配與控制為系統提供了信任根――追溯碼,通過核銷算法確保信息在每一階段傳遞的一致性和可控性。系統中一旦出現數據丟失或前后不一致,就會立即做出提示,避免給消費者帶來損害,也就是干擾發現機制原理在此案例中的重要體現。
2.5 基于構件技術的三流一體化軟件體系結構
本系統的設計以多層軟件體系結構作為整體構架[6],包括用戶界面層、業務邏輯層、通用操作層、數據接口層以及數據層[7]。
其中,用戶界面層由界面對象(UI對象)組成,是人機進行交互的接口,對應于用戶的需求,并負責觸發業務事件以啟動業務邏輯;業務邏輯層是應用軟件系統的主體,負責處理所有與業務邏輯和業務規則直接相關的操作;通用操作層為業務邏輯層提供一些常用的功能;數據接口層需要了解數據庫服務器的類型和它的語義接口,屏蔽具體數據庫服務器之間的差異,從而提高應用程序的可移植性和適應性;數據層是應用軟件系統的最底層,負責基礎數據和商業數據的存放和管理,并對這些數據的完整性、一致性提供保證。
肉類食品安全追溯系統的多層軟件體系結構圖如圖3所示[8]。
2.5.1 業務邏輯層信息傳遞的安全性
1)各子系統間核銷
由于本系統包含多個子系統,因此系統間的信息傳遞是否符合可信鏈傳遞模型的要求,是體系結構安全和可信度量一項重要的指標。在養殖和屠宰子系統間的核銷功能是通過耳標信息管理構件和RFID卡信息管理構件實現的,此構件間的信息核對保證信息在兩種狀態間的流通的完整性和一致性。
2)碼的加密和解密
通過參考現有類似產品的追溯碼結構,擬對豬肉食品追溯碼采用全球貿易項目代碼(GTIN)+批號/系列號+源實體參考代碼。 在設計追溯碼的過程中應用較縝密的合理的加密和解密技術,以及必要的斷碼的復原技術,可以排除商品流通過程中被惡意銷毀和篡改,這是無干擾理論在控制流中的重要體現。
2.5.2 數據接口層和數據層的安全性
1)身份認證
所有操作人員訪問系統數據必須經過開機口令、操作系統口令、應用程序口令、數據庫訪問口令檢測,系統根據客戶機的IP地址、操作員工號/口令、帳本/倉庫號等對該用戶的操作進行嚴格的限制。
2)存取權限控制
對數據庫中的數據操作一般有輸入、查詢、編輯、刪除四種情況,按照以上操作類別將用戶劃分為四個權限等級,各操作人員只能對自己權限范圍內的數據進行權限范圍內的操作。
3)結論
基于可信計算思想的食品安全追溯系統多層軟件體系結構這一嶄新課題的提出,必將為發展和完善食品安全可追溯體系提供切實可行的新思路,當然,要把此體系結構完整地實施到現實食品安全可追溯系統中還需要很長的路要走,還必須依賴于人才的培養和經費的支持。
參考文獻:
[1] 伊銘.中國食品流通安全發展現狀研究[J].上海經濟研究,2008(7):62-67.
[2] 沈昌祥,張煥國.信息安全綜述[J].中國科學,2007,37:129-150.
[3] Chen Youlei.Study on trusted computing model and architecture[D].Wuhan:Wuhan University,2006.
[4] 譚良,徐志偉.基于可信計算平臺的信任鏈傳遞研究進展[J].計算機科學,2008,35(10):15-18.
[5] 馬建平,余祥宣,洪帆,等.一個完整的無干擾模型[J].計算機學報,1997,20(11):1034-1037.
[6] 蔡.基于構件的N層體系結構研究與應用[D].北京:中國地質大學,2004.
軟件體系結構范文6
關鍵詞:體系結構;軟件可靠性;分析
中圖分類號:TP311文獻標識碼:A文章編號:1007-9599 (2010) 10-0000-01
Software Reliability Analysis under System structure
Zhang Jian,Ye Feng
(Information Equipment Department of Equipment Command&Technology College,Beijing101416,China)
Abstract:With the global software development industry continues to develop,and the emergence one new model of software testing and application,modeling the software architecture,software reliability can articulate the results of tests,and for the study and improvement of software reliability also has certain promotion significance.
Keywords:Architecture;Software reliability;Analysis
在全球電子信息技術高速發展的時代背景下,軟件研發作為一個新興的產業也經歷了近50年的發展歷程,并逐漸成為現代信息社會構建中的關鍵一環。在現階段軟件項目的研發過程中,不但對于質量、可靠性、穩定性、安全性等技術指標有了更高的要求,而且對于軟件系統失效的容許能力也越來越小,軟件項目研發中必須綜合考慮到多方面的問題與因素。在現行的軟件體系結構下,可靠性是軟件項目質量測試中最為重要的指標,也是軟件項目的固有特性之一。經國內外權威軟件研發機構長期探索與研究表明:在預測或計算軟件系統可靠性時,必須基于軟件體系結構的基礎之上,否則得出的測試往往和實際情況相差甚遠。
一、自動測試系統軟件體系結構的研發與應用
近年來,國內外軟件開發商在強化技術力量與資金投入的同時,也深刻認識到軟件體系結構的改進與完善對于其質量提升的重要性。隨著現代電子信息技術及編程技術的創新發展,越來越多的自動測試系統被開發與應用,并且取得了令人滿意的使用效果。
目前,國內外通用的自動測試系統的軟件體系結構大多建立于IEEE的寬域測試環境標準基礎之上,寬域測試環境標準將自動測試系統劃分成5個層次,即測試程序層、產品描述層、資源管理層、測試需求層及儀器控制層。現在應用的自動測試系統普遍具有串行自動測試系統的基本特性,核心測試過程與串行自動測試系統的核心測試過程是一致的。自動測試系統軟件體系結構與傳統串行自動測試系統的軟件體系結構的不同在于其任務,資源管理層更加復雜。
二、現行軟件可靠性研究中存在的弊端與問題
目前,國內外軟件開發商都適時加大了對于軟件可靠性研究的重視程度,也已取得了很大的成就,但是仍然存在一些弊端與問題仍,如果不能得到及時、有效的解決,必然影響到軟件研發行業的整體發展趨勢與前景。
(一)軟件可靠性的有效性和適用范圍
雖然目前國內外軟件研發行業已經逐步建立了數百種軟件可靠性測試模型,但是普遍具有一定的局限性。因此,從軟件研發行業的長期發展角度而言,可靠性模型的實際應用是否滿足要求、假設是否合理、適用范圍是否廣泛等問題都是必須深入考慮與研究的,如何進一步構建合理、實用的軟件可靠性模型還有待于進一步研究。
(二)軟件系統模塊失效數據的研究
在國內外現階段的軟件可靠性研究中,對于相關程序數據的收集是一項相對較為復雜的工作內容,到目前為止,國內外均未構建專業用于測試軟件可靠性的模型。同時,可用性強、估計精度、以及模型與模型之間差別的數據庫也尚未完全建立。因此,在軟件可靠性分析中,研究失效數據的收集處理系統及其機制,可以將硬件的失效性數據規范的方法應用到軟件的失效數據的研究中,為軟件可靠性的快速預計、設計提供理論依據和實際分析手段。
三、體系結構下軟件可靠性的分析
近年來,世界各國軟件研發行業對于軟件可靠性均給出了不同的定義,但是其基本理念與內容是具有一定共通性的。目前,國際上普遍認可的對于軟件可靠性的定義為:在一段時間內,對于軟件正常運行的概率進行分析與統計,最終得出軟件的平均生命周期與相關質量指標。在現行的軟件體系結構下,軟件可靠性模型對于軟件可靠性的測試起到決定性的作用。軟件可靠性分析中,涉及道德各方面因素相對較多,只有協調好各因素之間的聯系與影響關系,才能更為科學、有效地促進軟件可靠性分析結果的真實性與準確性。
影響軟件可靠性的主要因素
在軟件項目的開發和維護過程中,軟件項目越大、體系結果越復雜,其所消耗的資源也就越多,在軟件設計中引入錯誤的可能性也自然增大。盡管復雜性與軟件中的錯誤數未必呈現出簡單的正比關系,但存在這種正相關趨勢是肯定無疑的。另外,按照軟件的性質和功能,軟件可區分為以下類別:應用軟件、系統軟件、支持軟件、測試軟件及維護軟件,不同的軟件類別對軟件的可靠性要求不同,實現難度自然也就不同。
(二)基于體系結構下的軟件可靠性早期預測模型
通過引入軟件體系結構的方法,本文提出基于體系結構下的軟件可靠性早期預測模型。該模型的建立步驟如下:
1.根據經驗列出所有對該單位開發的軟件的可靠性可能產生影響的因素,并將各方面因素進行綜合分析。
2.對于形式化程度比較高的部分,一般采用自動化工具進行數據采集,也可以采用人工測量計算。
3.對數據進行預處理,主要包括主成分分析、數據標準化處理、特異樣本點的判定和數據歸一化。
4.核函數類型的選擇與所應用的領域有關,經常使用的核函數主要有線性核、多項式核、徑向基函數核等。
5.模型參數和核參數的選擇要根據模型的測試結果,進而得出軟件可靠性的測試結果。
四、結束語
在我國現代IT領域管理方面,逐步認識到軟件質量測試的重要性,并且采取了一系列科學、有效、合理的管理和技術措施,但是現行的措施普遍只限于實施軟件工程的層面,遠沒有達到軟件可靠性工程的深度。因此,國內軟件研發行業必須跟蹤國外軟件可靠性技術的發展,繼續開展和支持軟件可靠性研究。
參考文獻:
[1]馬珊紅,于祥林.基于體系結構下的軟件可靠性綜合模型[J].哈爾濱工業大學學報,2007,11.P15-16
