網站地圖 原創論文網,覆蓋經濟,法律,醫學,建筑,藝術等800余專業,提供60萬篇論文資料免費參考
主要服務:論文發表、論文修改服務,覆蓋專業有:經濟、法律、體育、建筑、土木、管理、英語、藝術、計算機、生物、通訊、社會、文學、農業、企業

軟件架構核心技術探究

來源:原創論文網 添加時間:2018-01-11

  軟件在人類社會活動中發揮著不可估量的作用,軟件工程旨在研究軟件系統架構、開發、運行、維護、演化的創新方法以提高效率和質量[1].軟件并非開發商為客戶提供的第一樣東西,但它的好壞會直接影響客戶的感受。無論公司大小,對軟件的依賴程度都在急劇增加。不管公司關注的戰略重點是什么,軟件架構已經成為一種能力,掌握得好將極大提升公司的實力和水平,否則會嚴重削弱項目或系統構建[2].本文通過視圖幫助架構師解決軟件架構的關鍵問題,從而使其概念具有可操作性。
  
  1 軟件架構概述
  
  以往軟件架構所關注的核心問題是系統的復雜性,然而今天許多系統具有與摩天大樓媲美的復雜性。因此,軟件設計問題超出了算法和數據結構,設計和指定整個系統結構就是軟件架構級別的設計。很明顯,復雜性是軟件架構必須解決的一個關鍵問題[3].主要體現在兩方面:①知識難駕馭,如構建系統的復雜性、規模、依賴關系和采用技術等;②管理難駕馭,如構建系統的組織和流程、參與構建系統的人數、項目的依賴關系、外包、地理分布的團隊等[4].
  
  分解系統可以解決復雜性問題,但是怎么分片?好的分解滿足組件之間松散耦合的原則,通過干凈接口,合理地將其劃分為可單獨處理的獨立部分以簡化問題。該結構必須支持系統所需的功能或服務。因此,必須考慮系統的動態行為,還要有必要的基礎設施支持這些服務[5].
  
  如何將切片結合在一起是界面與各個部分之間的關系問題。保持系統完整性的同時,也需要保證這些切片組成的系統具有良好適應性。這些品質或特性對系統具有分散或系統性影響,因此是交叉分割的關注點。這不是一個孤立的問題,因為分解是由其它問題驅動的,無論怎樣分割,多個部分都必須合作解決這些關注點。為了有效地解決跨部門關切的問題,必須首先在范圍更廣的層面上處理問題。許多系統質量(非功能性要求或服務級協議)具有這種性質,包括性能、安全性和互操作性要求。例如,為了使圖像更加復雜,可能會與系統質量發生沖突,因此要考慮到系統質量的相對優先級,必須在備選方案之間權衡。架構的另一個關鍵是方案能否適應環境,這關系到一致性與和諧,也是業務戰略和用戶目標一致的問題。
  
  架構不僅要適應原有系統的環境,不破壞以往投資的價值,而且應該對已經被證明有效的東西進行規格化,避免不必要的重復。除整合經驗教訓外,還應該識別與利用系統內部及跨系統復用。此外,應該預見趨勢和可能的未來情景[6].
  
  2 架構決策核心問題
  
  這需要從廣泛范圍或系統的角度進行。任何于狹義局部進行的決策,都不是架構。架構決策即使不對整個系統,至少對系統的不同部分會產生影響,因此需要從全局視角考慮這種影響,并作出必要的權衡[7].
  
  例如,對于單個應用程序,組件設計者作出的任何決策都應該服從架構。如果架構的范圍是一組應用程序,則任何與單個應用程序相關的決策都應該服從系統架構。那些對系統影響不大的決策不是架構。所以,架構決策應該關注高影響、高優先級且與業務策略緊密結合的領域,如表1所示。
  
  基于軟件架構所涉及的核心問題,架構決策包含:優先級設置、分解與合成、屬性特別是交叉切割關注點、適應環境和完整性。
  
  2.1 優先級設置
  
  在設計大型復雜系統時,關鍵要把重點放在明確的事情上,這樣就可以把注意力集中在高優先級領域,從而可以合理地作出取舍,并且在商定的優先事項上作出合理的決策。架構師需要負責系統技術方面的優先級設置。這是一個高度戰略化過程,涉及:①業務,包括業務策略和方向、核心競爭力和資源;②市場,包括客戶、競爭對手、供應商;③渠道技術,包括趨勢和機會;④約束,包括現有技術投資、現存系統挑戰和系統成功障礙、系統開發和業務[8].
  
  2.2 分解與組合
  
  軟件架構的基礎是系統結構,即系統的主要結構元素或組件以及它們的相互關系。在分離特定的關注點時,必須確保系統的功能或服務可由協作中的組件交付。因此對于每個組件的職責要有一致的假設;還必須文檔化,形成適當的上下文,以便相對獨立地開發;能在不了解內部構件的情況下使用組件。這些是組件的外部可見屬性。
  
  2.3 屬性與交叉分割
  
  系統分解針對一些關注點進行特定分解,以便能夠獨立處理。不同的分區選擇傾向于隔離不同的關注點。交叉分割會影響系統的各個部分,因此必須將協作組件集合在一起,以正確地處理每一個關注點。例如,性能通常需要在架構所允許的交互模式下加以考慮,而不僅僅是優化各部分的性能。有些關注點,比如互操作性,需要關注特定架構,并且設計一種解決機制。該機制可以被設計為一組協作組件,集中于解決交叉分割關注點。例如,接口可置于非核心內聚集的組件上。
  
  2.4 系統適應上下文
  
  系統適應上下文的關鍵技術是與外部系統的互操作性、一致性和接口。然而,適合開發機構的文化和功能,也是架構決策和選擇的考慮因素。
  
  2.5 完整性
  
  完整性是指應具有統一的整體設計、形式或結構,無論片大小都是一致的。此外,還包括內部平衡、兼容性和各部分之間的和諧,以及適應環境與目標[9].
  
  首先,在高層結構設計時,需要為系統創建完整概念,確保組件、屬性和關系能夠加入并為完整性打下基礎。這里有一個關鍵的角色,即視覺、架構風格、原則和概念為高層結構到詳細設計提供一致方法。其次,一些決策雖然與高層結構無關,但與架構的完整性有關,也要認定屬于架構。然而,系統完整性為架構師打開了一扇門,讓他們作出了本應該是組件設計和實現者應該作的決策。因此,簡約架構精神應該得到發揚。
  
  2.6 簡約架構
  
  可以應用3個原則實現簡約架構:①若決策是在一個較窄的范圍內進行,則交給負責該范圍的團隊;②只在重大結構性需求上強調架構決策,包括戰略目標、重要且獨特的服務以及系統性或對系統有交互影響的特質與屬性;③當決策被引入時,應該就它們對組織采用架構的整體能力所產生的影響進行評估。一個決策可能會解決一個高度關注的問題,若它會導致架構被破壞,那么將其放在一邊。作為簡約架構規程的一部分,每個決策都該有一個合理理由和說明。決策應該在全局范圍內進行優化,但在局部可能是次優的[2].因此那些只有局部視野的人必須理解任何局部優化對整個系統的影響[10].
  
  另外,提供基本原則允許在架構上進行檢查和平衡,在不犧牲高優先架構需求的情況下,可以更好地實現重大需求,并且可以合理地與架構決策相沖突。
  
  3 架構決策框架
  
  架構決策實際上處于不同的抽象級別。核心關注點是架構的結構元素和它們的外部屬性及關系。然而,還有更高層次的決策可以指導與約束系統分解和結構化決策,也有一些低級的決策指導與約束下一個級別的設計和實現。這在圖1所示的軟件架構分層模型中得到了體現。模型提供了高度有效的關注點分離方法,幫助架構師組織決策過程,為行動提供定位。它由模型、描述、解釋等組成,通過捕獲架構決策,幫助相關人員對架構進行可視化,并了解如何處理關注點。架構描述指導系統的創建。
  
  3.1 元架構
  
  這是一組高層決策,它強調影響系統的完整性和結構,但其本身不是系統結構。通過風格、組合或交互模式、原則和哲學,元架構規定某些結構性選擇,并指導選擇決策和權衡取舍。通過反復選擇跨架構的通信或協調機制,確保方法一致,從而簡化架構。這種方法也可以幫助找到對系統有用的隱喻或組織概念。它還可以幫助考慮系統應該具備的質量,甚至幫助選擇需要的組件,最終使架構更加生動和易理解[11].
  
  3.2 架構的3個級別
  
  這是分層決策模型的核心,也是架構活動的中心。通過設置系統優先級和約束,確保系統能實現目標和需求。該工作由元架構中的決策提供信息和約束,使用不同的視圖增強架構的可理解性,并單獨關注特定的關注點。架構由概念、邏輯和執行3個級別組成,如圖2所示。
  
  (1)概念架構。確定系統的高級組件以及之間的關系,在不關注細節的情況下,注意力集中在系統的適當分解上。此外,還提供一種用于架構與非技術人員之間的通信工具,由架構圖(無接口細節)和組件的非正式規范組成。
  
  (2)邏輯架構。在邏輯架構中,組件的外部屬性通過定義良好的接口和組件規范實現精確定義,并詳細描述關鍵的架構機制。它提供一份詳細的藍圖,使組件開發者和用戶可以相對獨立地工作。它包含詳細的架構圖、組件和接口規范以及組件協作圖,還有關于機制、原理等的解釋。
  
  (3)執行架構。它是為分布式或并發系統創建的。流程視圖是組件到物理系統過程的映射,關注的重點是吞吐量和可伸縮性等問題。部署視圖是執行系統中組件到物理系統節點的映射。
  
  3.3 架構的結構與行為視圖
  
  結構和行為視圖對于思考和表示架構都很重要。如果接受架構是由組件組成的系統高層結構、組件的相互關系和外部屬性,則結構視圖是其核心。它由架構圖(原型UML類圖)、組件和接口規格組成。
  
  將系統分解為組件并設計接口,在設計解決關鍵交叉分割關注點的機制時,行為視圖和它的組件協作或序列圖(固定的UML序列和協作圖)可以幫助理解這個過程[12-13].
  
  結構和行為視圖都適用于概念、邏輯和執行這三級架構。它們之間的關系如表2所示。
  
  4 架構指導方針
  
  為了保持系統的完整性或解決分割關注點, 架構師可以指導或約束架構決策集的底層設計與實現。也即合理地幫助設計和開發者應用架構并注意問題的正確特征,這樣他們的決策就是明確的。
  
  一般來說,除非有嚴格的架構理由限制設計和開發者自由發揮,否則應避免使用規定。
  
  (1)通信架構決策。除非記住、接受和理解,否則架構決策是無能為力的。架構文檔的主要目標是記錄決策過程。為了達到目標,文檔必須完整且明確。
  
  (2)通信架構。為了達成目標,還必須考慮每個相關人員需要知道什么,以及如何更好地向他們傳達必要的信息。
  
  (3)架構驅動。雖然不是體系結構的一部分,但是塑造架構的驅動因素對于明確和分享是很重要的。它們包括:架構遠景,即架構的期望狀態;架構需求,即相關人員目標和架構功能需求,以及系統質量和約束;假設、勢力和趨勢,即當前業務、市場和技術環境的斷言以及架構規劃的范圍。
  
  (4)構架視圖。圖1和表2展示了一組標準化視圖。這些是指導決策時的有用東西,所提供的思考工具幫助決策和選擇。它們也是架構規范的基礎,是抽象、特異和精確性選擇級別中的完整架構決策集。
  
  (5)架構文檔。有了架構驅動和各種視圖等原始資料,也就可以針對不同的人員編寫文檔和報告。文檔包括所有架構規格書、管理概要和組件文檔。
  
  (6)管理概要。為了易于管理,需要創建一個高層次概要,包括遠景、業務驅動、架構圖及將業務策略與技術策略聯系起來的基本方法。
  
  (7)組件文檔。對于每個組件所有者,最好提供一個系統級視圖、組件和接口規范,以及組件協作圖。
  
  5 結語
  
  本文討論了軟件架構的重點以及如何表達軟件架構。但是,世界上所有的文檔和演示都是不夠的,除非軟件架構是好的、技術上是合理的,能清晰地表明它是符合關鍵利益相關者的需求和目標,并且能成功地用于開發具有戰略優勢的系統。

  參考文獻:

  [1] 劉璘,周明輝,尹剛.大數據時代軟件工程專題前言[J].軟件學報,2017,28(6):1327-1329.
  [2] TNO, EINDHOVEN.Resources for software and systems architects[EB/OL].
  [3] 白金.軟件架構模式在信息系統開發中的應用分析[J].通信世界,2017(5):249-250.
  [4] 王志剛,高磊.軟件發布規劃遺傳算法探討[J].軟件導刊,2016,15(11):56-58.
  [5] 王煒,陳未如.軟件架構切片在軟件可靠性評估中的應用[J].微計算機信息,2008,28(1):290-292.
  [6] FEA PRACTICE GUIDANCE. Federal segment architecture methodology (FSAM) practitioner’s training version 1.0.[EB/OL].
  [7] 李衛華, 傅曉東.可拓創新軟件體系結構研究[J]. 廣東工業大學學報,2016,34(2):2-5.
  [8] 楊波,于茜,張偉,等.GitHub開源軟件開發過程中影響因素的相關性分析[J].軟件學報,2017,28(6):1330-1342.
  [9] 林巴斯.軟件構架實踐[M].北京:清華大學出版社,2002.
  [10] 王志剛,高磊.軟件發布規劃的遺傳算法實現與解釋[J].現代計算機,2016(12):3-6.
  [11] 俞析蒙.基于驗證的軟件架構演化分析與評估[D].南京:東南大學,2015.
  [12] 王智超,王敏,熊燕.軟件架構設計之多視角分析[J].現代計算機,2014(10):35-37.
  [13] NORMAN HENDRICH, HANNES BISTRY, 張建偉.助老服務機器人系統設計及軟件架構[J]. Engineering, 2015(1):26-34.

重要提示:轉載本站信息須注明來源:原創論文網,具體權責及聲明請參閱網站聲明。
閱讀提示:請自行判斷信息的真實性及觀點的正誤,本站概不負責。
天津快乐10分查询结果