軟件架構模式和設計模式(書摘)

 

什麼是架構?

   軟件體系結構通常被稱爲架構,指可以預製和可重構的軟件框架結構。架構尚處在發展期,對於其定義,學術界尚未形成一個統一的意見,而不同角度的視點也會造成軟件體系結構的不同理解,以下是一些主流的標準觀點。
  ANSI/IEEE 610.12-1990軟件工程標準詞彙對於體系結構定義是:“體系架構是以構件、構件之間的關係、構件與環境之間的關係爲內容的某一系統的基本組織結構以及知道上述內容設計與演化的原理(principle)”。
  Mary Shaw和David Garlan認爲軟件體系結構是軟件設計過程中,超越計算中的算法設計和數據結構設計的一個層次。體系結構問題包括各個方面的組織和全局控制結構,通信協議、同步,數據存儲,給設計元素分配特定功能,設計元素的組織,規模和性能,在各設計方案之間進行選擇。Garlan & Shaw模型[1]的基本思想是:軟件體系結構={構件(component),連接件(connector),約束(constrain)}.其中構件可以是一組代碼,如程序的模塊;也可以是一個獨立的程序,如數據庫服務器。連接件可以是過程調用、管道、遠程過程調用(RPC)等,用於表示構件之間的相互作用。約束一般爲對象連接時的規則,或指明構件連接的形式和條件,例如,上層構件可要求下層構件的服務,反之不行;兩對象不得遞規地發送消息;代碼複製遷移的一致性約束;什麼條件下此種連接無效等。
  關於架構的定義還有很多其他觀點,比如Bass定義、Booch & Rumbaugh &Jacobson定義、Perry & Wolf模型[7]、Boehm模型等等,雖然各種定義關鍵架構的角度不同,研究對象也略有側重,但其核心的內容都是軟件系統的結構,其中以Garlan & Shaw模型爲代表,強調了體系結構的基本要素是構件、連接件及其約束(或者連接語義),這些定義大部分是從構造的角度來甚至軟件體系結構,而IEEE的定義不僅強調了系統的基本組成,同時強調了體系結構的環境即和外界的交互。

    什麼是模式?
   模式(Pattern)的概念最早由建築大師Christopher Alexander於二十世紀七十年代提出,應用於建築領域,八十年代中期由Ward Cunningham和Kent Beck將其思想引入到軟件領域,Christopher Alexander將模式分爲三個部分:首先是周境(Context,也可以稱着上下文),指模式在何種狀況下發生作用;其二是動機(System of Forces),意指問題或預期的目標;其三是解決方案(Solution),指平衡各動機或解決所闡述問題的一個構造或配置(Configuration)。他提出,模式是表示周境、動機、解決方案三個方面關係的一個規則,每個模式描述了一個在某種周境下不斷重複發生的問題,以及該問題解決方案的核心所在,模式即是一個事物(thing)又是一個過程(process),不僅描述該事物本身,而且提出了通過怎樣的過程來產生該事物。這一定義已被軟件界廣爲接受。

        架構和模式應該是一個屬於相互涵蓋的過程,但是總體來說Architecture更加關注的是所謂的High-Level Design,而模式關注的重點在於通過經驗提取的“準則或指導方案”在設計中的應用,因此在不同層面考慮問題的時候就形成了不同問題域上的Pattern。模式的目標是,把共通問題中的不變部分和變化部分分離出來。不變的部分,就構成了模式,因此,模式是一個經驗提取的“準則”,並且在一次一次的實踐中得到驗證,在不同的層次有不同的模式,小到語言實現(如Singleton)大到架構。在不同的層面上,模式提供不同層面的指導。根據處理問題的粒度不同,從高到低,模式分爲3個層次:架構模式(Architectural Pattern)、設計模式(Design Pattern)、實現模式(Implementation Pattern).架構模式是模式中的最高層次,描述軟件系統裏的基本的結構組織或綱要,通常提供一組事先定義好的子系統,指定它們的責任,並給出把它們組織在一起的法則和指南。比如,用戶和文件系統安全策略模型,N-層結構,組件對象服務等,我們熟知的MVC結構也屬於架構模式的層次。一個架構模式常常可以分解成很多個設計模式的聯合使用。設計模式是模式中的第二層次,用來處理程序設計中反覆出現的問題。例如,[GOF95][2]總結的23個基本設計模式——Factory Pattern, Observer Pattern等等。實現模式是最低也是最具體的層次,處理具體到編程語言的問題。比如,類名,變量名,函數名的命名規則;異常處理的規則等等。

來自:http://dev.yesky.com/378/2012378.shtml

   由於[GOF95]是論述軟件模式的著作的第一本,也是OO設計理論著作中最流行的一本,因此有些人常常使用設計模式(Design Pattern)一詞來指所有直接處理軟件的架構、設計、程序實現的任何種類的模式。另外一些人則強調要劃分三種不同層次的模式:架構模式(Architectural Pattern)、設計模式(Design Pattern)、成例(Idiom)。成例有時稱爲代碼模式(Coding Pattern)。

  這三者之間的區別在於三種不同的模式存在於它們各自的抽象層次和具體層次上。架構模式是一個系統的高層次策略,涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體佈局和框架性結構。設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行爲和它們之間的關係。模式的好壞不會影響到系統的總體佈局和總體框架。設計模式定義出子系統或組件的微觀結構。代碼模式(或成例)是特定的範例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一箇中等尺度組件的內部、外部的結構或行爲的底層細節,但不會影響到一個部件或子系統的中等尺度的結構,更不會影響到系統的總體佈局和大尺度框架。

  1、代碼模式或成例(Coding Pattern 或 Idiom)
  代碼模式(或成例)是較低層次的模式,並與編程語言密切相關。代碼模式描述怎樣利用一個特定的編程語言的特點來實現一個組件的某些特定的方面或關係。
  較爲著名的代碼模式的例子包括雙檢鎖(Double-Check Locking)模式等。

  2、設計模式(Design Pattern)
  一個設計模式提供一種提煉子系統或軟件系統中的組件的,或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的組件中重複出現的結構,這種結構解決在一定的背景中的具有一般性的設計問題。
  設計模式常常劃分成不同的種類,常見的種類有:
  創建型設計模式,如工廠方法(Factory Method)模式、抽象工廠(Abstract Factory)模式、原型(Prototype)模式、單例(Singleton)模式,建造(Builder)模式等
  結構型設計模式,如合成(Composite)模式、裝飾(Decorator)模式、代理(Proxy)模式、享元(Flyweight)模式、門面(Facade)模式、橋樑(Bridge)模式等
  行爲型模式,如模版方法(Template Method)模式、觀察者(Observer)模式、迭代子(Iterator)模式、責任鏈(Chain of Responsibility)模式、備忘錄(Memento)模式、命令(Command)模式、狀態(State)模式、訪問者(Visitor)模式等等。
        以上是三種經典類型,實際上還有很多其他的類型,比如Fundamental型、Partition型,Relation型等等 
  設計模式在特定的編程語言中實現的時候,常常會用到代碼模式。比如單例(Singleton)模式的實現常常涉及到雙檢鎖(Double-Check Locking)模式等。

  3、架構模式(Architectural Pattern)
  一個架構模式描述軟件系統裏的基本的結構組織或綱要。架構模式提供一些事先定義好的子系統,指定它們的責任,並給出把它們組織在一起的法則和指南。有些作者把這種架構模式叫做系統模式[STELTING02]。
  一個架構模式常常可以分解成很多個設計模式的聯合使用。顯然,MVC模式就是屬於這一種模式。MVC模式常常包括調停者(Mediator)模式、策略(Strategy)模式、合成(Composite)模式、觀察者(Observer)模式等。
  此外,常見的架構模式還有:
  ·Layers(分層)模式,有時也稱Tiers模式
  ·Blackboard(黑板)模式
  ·Broker(中介)模式
  ·Distributed Process(分散過程)模式
  ·Microkernel(微核)模式
  架構模式常常劃分成如下的幾種:
  一)、 From Mud to Structure型。幫助架構師將系統合理劃分,避免形成一個對象的海洋(A sea of objects)。包括Layers(分層)模式、Blackboard(黑板)模式、Pipes/Filters(管道/過濾器)模式等。
  二)、分散系統(Distributed Systems)型。爲分散式系統提供完整的架構設計,包括像Broker(中介)模式等。
  三)、人機互動(Interactive Systems)型,支持包含有人機互動介面的系統的架構設計,例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
  四)、Adaptable Systems型,支持應用系統適應技術的變化、軟件功能需求的變化。如Reflection(反射)模式、Microkernel(微核)模式等。 

來自:http://fanqiang.chinaunix.net/program/project/2005-06-16/3316.shtml

Layers架構模式
  在收集到用戶對軟件的要求之後,架構設計就開始了。架構設計一個主要的目的,就是把系統劃分成爲很多"板塊"。劃分的方式通常有兩種,一種是橫向的劃分,一種是縱向劃分。
  橫向劃分將系統按照商業目的劃分。比如一個書店的管理系統可以劃分成爲進貨、銷售、庫存管理、員工管理等等。
  縱向劃分則不同,它按照抽象層次的高低,將系統劃分成"層",或叫Layer。比如一個公司的內網管理系統通常可以劃分成爲下面的幾個Layer:
  一、網頁,也就是用戶界面,負責顯示數據、接受用戶輸入;
  二、領域層,包括JavaBean或者COM對象、B2B服務等,封裝了必要的商業邏輯,負責根據商業邏輯決定顯示什麼數據、以及如何根據用戶輸入的數據進行計算;
  三、數據庫,負責存儲數據,按照查詢要求提供所存儲的數據。
  四、操作系統層,比如Windows NT或者Solaris等
  五、硬件層,比如SUN E450服務器等
  有人把這種Layer叫做Tier,但是Tier多帶有物理含義,不同的Tier往往位於不同的計算機上,由網絡連接起來,而Layer是純粹邏輯的概念,與物理劃分無關。 
  Layers架構模式的好處是:
  第一、任何一層的變化都可以很好地侷限於這一層,而不會影響到其他各層。
  第二、更容易容納新的技術和變化。Layers架構模式容許任何一層變更所使用的技術

【Kiki】由於我只接觸過這種,其他(Facade架構模式、Mediator架構模式和Interpreter架構模式)就不轉載了。

來自:http://java.ccidnet.com/art/3749/20060511/550769_1.html

1.什麼是模式?
模式,即pattern。其實就是解決某一類問題的方法論。你把解決某類問題的方法總結歸納到理論高度,那就是模式。
Alexander給出的經典定義是:每個模式都描述了一個在我們的環境中不斷出現的問題,然後描述了該問題的解決方案的核心。通過這種方式,你可以無數次地使用那些已有的解決方案,無需在重複相同的工作。
模式有不同的領域,建築領域有建築模式,軟件設計領域也有設計模式。當一個領域逐漸成熟的時候,自然會出現很多模式。
什麼是框架?
框架,即framework。其實就是某種應用的半成品,就是一組組件,供你選用完成你自己的系統。簡單說就是使用別人搭好的舞臺,你來做表演。而且,框架一般是成熟的,不斷升級的軟件。

2.爲什麼要用模式?
因爲模式是一種指導,在一個良好的指導下,有助於你完成任務,有助於你作出一個優良的設計方案,達到事半功倍的效果。而且會得到解決問題的最佳辦法。
爲什麼要用框架?
因爲軟件系統發展到今天已經很複雜了,特別是服務器端軟件,設計到的知識,內容,問題太多。在某些方面使用別人成熟的框架,就相當於讓別人幫你完成一些基礎工作,你只需要集中精力完成系統的業務邏輯設計。而且框架一般是成熟,穩健的,他可以處理系統很多細節問題,比如,事物處理,安全性,數據流控制等問題。還有框架一般都經過很多人使用,所以結構很好,所以擴展性也很好,而且它是不斷升級的,你可以直接享受別人升級代碼帶來的好處。
框架一般處在低層應用平臺(如J2EE)和高層業務邏輯之間的中間層。

 

發佈了39 篇原創文章 · 獲贊 19 · 訪問量 15萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章