對軟體體繫結構的認識

標籤：des   style   使用   檔案   資料   os   

 

 

一.軟體體繫結構（架構）

軟體體繫結構的定義

通常，軟體體繫結構通常被稱為架構，指能夠預製和可重構的軟體架構結構。架構尚處在發展期，對於其定義，學術界尚未形成一個統一的意見，而不同角度的視點也會造成軟體體繫結構的不同理解。比方，ANSI/IEEE610.12-1990軟體project標準詞彙對於體繫結構定義是“體系架構是以構件、構件之間的關係、構件與環境之間的關係為內容的某一系統的基主要組織結構以及知道上述內容設計與演化的原理(principle)”；而Garlan&Shaw模型的基本思想是：軟體體繫結構={構件(component),串連件(connector)，約束(constrain)}。
對於軟體項目的開發來說，一個清晰的軟體體繫結構是首要的。傳統的軟體開發過程能夠劃分為從概念到實現的若干個階段，包含問題定義、需求分析、軟體設計、軟體實現及軟體測試等。軟體體繫結構的建立就位於需求分析之後，軟體設計之前。在建立軟體體繫結構時系統設計師主要從結構的角度對整個系統進行分析，選擇恰當的構件（Component）、構件間的相互作用以及它們的約束，最後形成一個系統架構（Framework）以滿足使用者的需求，為軟體設計奠定基礎。

軟體體繫結構風格
軟體體繫結構設計的一個核心問題是是否能使用反覆的體繫結構模式，即是否能達到結構級的軟體重用。也就是說，是否能在不同的軟體體系中，使用同一體繫結構。基於這個目的，學者們開始研究和實踐軟體體繫結構的風格問題。
軟體體繫結構風格是描寫敘述某一特定應用領域系統組織方式的慣用模式。它反映了領域中眾多系統全部的結構和語義特性，並指導怎樣將各個模組和子系統有效地組織成一個完整的系統。對軟體體繫結構風格的研究和實踐促進了對設計的複用，一些經過實踐證明的解決方式也能夠可靠地用於解決新的問題。體繫結構風格的不變部分使不同的系統能夠共用一個實現代碼。僅僅要系統是使用經常使用的、規範的方法來組織，就可使別的設計者非常easy地理解系統結構。
Garlan和Shaw對通用體繫結構風格進行例如以下分類：
（1）資料流風格：批處理序列、管道/過濾器等；
（2）調用/返迴風格：主程式/子程式、物件導向風格、階層等。
（3）獨立構件風格：進程通訊、事件系統等；
（4）虛擬機器風格：解譯器、基於規則的系統等；
（5）倉庫風格：資料庫系統、超文本系統、黑板系統等。
近年來，出現了很多新的體繫結構風格，比如客戶/server（Client/Server）結構、瀏覽器/server（Browser/Server）結構、正交（Orthogonal）結構、三層C/S結構等。

軟體體繫結構的建模研究
研究軟體體繫結構的首要問題是怎樣表示軟體體繫結構，即怎樣對軟體體繫結構建模。依據建模的側重點的不同，能夠將軟體體繫結構的模型分為5種：結構模型、架構模型、動態模型、過程模型和功能模型。當中，最經常使用的是結構模型和動態模型。

研究熱點
當前，體繫結構仍是一個很新的研究領域，其概念還相當模糊。但軟體體繫結構作為軟體project領域中的一個組成部分，已經取得了長足的發展，受到大多數軟體系統設計和研究人員的重視。
軟體體繫結構眼下較活躍的研究方向包含：（1）軟體體繫結構形式基礎的研究；（2）針對軟體體繫結構描寫敘述中特有的問題研究新的專門的進階語言；（3）建立用於度量和評價軟體體繫結構的模型和方法；（4）建立面向專門領域的軟體體繫結構範型庫。（5）把軟體體繫結構從眼下的直覺和經驗狀態過渡到理論。

二．模式
模式（Pattern）的概念最早由建築大師ChristopherAlexander於二十世紀七十年代提出，應用於建築領域，八十年代中期由WardCunningham和KentBeck將其思想引入到軟體領域，ChristopherAlexander將模式分為三個部分：
(1)周境（Context，也能夠稱著上下文）,指模式在何種狀況下發生作用；
(2)動機（SystemofForces）,意指問題或預期的目標；
(3)解決方式（Solution）,指平衡各動機或解決所闡述問題的一個構造或配置（Configuration）。
他提出，模式是表示周境、動機、解決方式三個方面關係的一個規則，每一個模式描寫敘述了一個在某種周境下不斷反覆發生的問題，以及該問題解決方式的核心所在，模式即是一個事物（thing）又是一個過程(process)，不僅描寫敘述該事物本身，並且提出了通過如何的過程來產生該事物。這一定義已被軟體界廣為接受。
軟體模式的應用對軟體開發產生了重大的作用，主要表如今：
（1）軟體模式是人們在長期的設計軟體、管理組織軟體開發等實踐中大量經驗的提煉和抽象，是複用軟體設計方法、過程管理經驗的有力工具。模式相似於拳擊中的組合拳，它提供了一系列軟體開發中的思維套路。如，通過模式的使用，有利於在複雜的系統中產生簡潔、靜止的設計。
(2)軟體模式為我們提供了一套簡潔通用的設計、管理、組織方面的詞彙，同一時候模式也為我們提供了一個描寫敘述抽象事物的規範標準，可大大促進軟體開發過程中人與人之間的交流，而軟體開發中的交流是至關重要的，“軟體項目失敗的原因終雩都可追溯到資訊沒有及時準確地傳遞到應該接收它的人”。

三．架構和模式的關係
架構(Architecture)和模式(Pattern)在當前的軟體開發中常常地被提及，這兩個術語很easy混淆，並且學術界也沒有一個很統一的定義。
架構和模式應該是一個屬於相互涵蓋的過程，可是整體來說Architecture更加關注的是所謂的High-LevelDesign,而模式關注的重點在於通過經驗提取的“準則或指導方案”在設計中的應用，因此在不同層面考慮問題的時候就形成了不同問題域上的Pattern。模式的目標是，把共通問題中的不變部分和變化部分分離出來。不變的部分，就構成了模式，因此，模式是一個經驗提取的“準則”，而且在一次次的實踐中得到驗證，在不同的層次有不同的模式，小到語言實現(如Singleton)大到架構。在不同的層面上，模式提供不同層面的指導。依據處理問題的粒度不同，從高到低，模式分為3個層次：
（1）架構模式(ArchitecturalPattern)、設計模式(DesignPattern)、實現模式(ImplementationPattern).架構模式是模式中的最高層次，描寫敘述軟體系統裡的主要的結構組織或綱要，通常提供一組事先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。比方，使用者和檔案系統安全性原則模型，N-層結構，組件物件服務等，我們熟知的MVC結構也屬於架構模式的層次。一個架構模式經常能夠分解成非常多個設計模式的聯合使用。
（2）設計模式是模式中的第二層次，用來處理常式設計中重複出現的問題。比如，《設計模式--可複用物件導向軟體的基礎》一書中總結的23個基本設計模式——FactoryPattern, ObserverPattern等。
（3）實現模式是最低也是最詳細的層次，處理詳細到程式設計語言的問題。比方，類名，變數名，函數名的命名規則；異常處理的規則等等。
相對於系統分析或者設計模式來說，體繫結構從更高的層面去考慮問題，所以關注的問題就體如今“不變”因素上，比方系統部署中，更加關心應用程式的分層分級設計，而在這個基礎之上提出的部署方案，才是架構考慮的重點。體繫結構關心應用程式模式，更加體如今通過技術去解決這些業務差異帶來的影響，關心是否是分布式應用程式，關心系統分層是怎樣設計，也關心效能和安全，因此在這種情況之下，會考慮叢集，Server Load Balancer，故障遷移等等一系列技術。
總之，希望通過定義的方式來區分架構和模式是不太可能的，由於本來就是互動交叉和提供服務的，它實際上是架構模式，而不是設計模式。在大部份情況下，表現為以下幾個設計模式之中的一個：Strategy模式、Mediator模式、Composite模式、Observer模式。對於熟悉架構設計的系統架構師而言，似乎能夠用例如以下來解釋架構和模式之間的關係：架構是Hight-LevelDesign,著眼於不同業務中共性的解決方式，而模式是GeneralPrinciple(通用原理)。