軟體架構
「架構」一詞最早來自建築學，原意為建築物設計和建造的藝術。但是在軟體工程領域，軟體架構不是一個新名詞，只是在早期的著作中人們將軟體架構稱為軟體體系架構。這就是架構的概念。所謂架構，就是人們對一個結構內的元素及元素間關系的一種主觀影射的產物。
系統架構的主要任務是界定系統級的功能與非功能要求、規劃要設計的整體系統的特徵、規劃並設計實現系統級的各項要求的手段，同時利用各種學科技術完成子系統的結構構建。
在系統架構中，由於對軟體越來越深入的依賴，軟體架構的任務也體現出重要的作用。而且系統架構與軟體架構是緊密聯系和相互依賴的。
1997年，Eberhadrt Rechtin 與MarkW Maier 在其論著中，為計算機科學總結了系統架構方面的實踐成果，從而奠定了系統科學和系統架構在計算機科學中的基石：
無論何種系統架構應用領域，目的都是一樣的，即完整地、高一致性的、平衡各種利弊的、有技術和市場前瞻性的設計系統和實施系統。
B. 軟體架構的形式
[BUS96] 根據構架模式最適用的系統的特徵將其分類，其中一個類別處理更普遍的結構問題。下表顯示了 [BUS96] 中所提供的類別和這些類別所包含的模式。
類別 模式結構 層管道和過濾器黑板分布式系統代理交互系統 模型-視圖-控制器表示-抽象-控制自適應系統反射微核
在「軟體構架簡介」中，David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。」[GS93]
但構架不僅是結構；IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」[IEEE98]。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在 Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
為闡明其含義，下面將詳述其中的兩個；完整說明請參見 [BUS96]。模式以下列廣泛使用的形式來表示：
模式名環境問題影響，描述應考慮的不同問題方面解決方案基本原理結果環境示例模式名層
環境需要進行結構分解的大系統。
問題必須處理不同抽象層次的問題的系統。例如：硬體控制問題、常見服務問題和針對於不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題（可能會不一致）。
影響
系統的某些部分應當是可替換的構件中的變化不應波動相似的責任應歸為一組構件大小 -- 復雜構件可能要進行分解解決辦法將系統分成構件組，並使構件組形成層疊結構。使上層只使用下層（決不使用上層）提供的服務。盡量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間層只添加通過構件）。
示例：
1. 通用層
嚴格的分層構架規定設計元素（類、構件、包、子系統）只能使用下層提供的服務， 服務可以包括事件處理、錯誤處理、資料庫訪問等等。 相對於記錄在底層的原始操作系統級調用，它包括更明顯的機制。
2. 業務系統層
上圖顯示了另一個分層示例，其中有垂直特定應用層、水平層和基礎設施層。注意：此處的目標是採用非常短的業務「煙囪」並實現各種應用程序間的通用性。 否則，就可能有多個人解決同一問題，從而導致潛在的分歧。
有關該模式的深入討論，請參見指南：分層。
模式名黑板
環境沒有解決問題的確定方法（演算法）或方法不可行的領域。例如 AI 系統、語音識別和監視系統。
問題多個問題解決顧問（知識顧問）必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問，使他們可以評估自己是否可以參與解決方案的查找並發布其工作結果。
影響
知識顧問參與解決問題的順序不是確定的，這可能取決於問題解決策略
不同顧問的輸入（結果或部分解決方案）可能有不同的表示方式
各顧問並不直接知道對方的存在，但可以評估對方發布的工作
解決辦法多名知識顧問都可訪問一個稱為「黑板」的共享資料庫。黑板提供監測和更新其內容的介面。控制模塊/對象激活遵循某種策略的顧問。激活後，顧問查看黑板，以確定它是否能參與解決問題。如果顧問決定它可以參與，控制對象就可以允許顧問將其部分（或最終）解決方案放置於黑板上。
示例：
以上顯示了使用 UML 建模的結構或靜態視圖。 它將成為參數化協作的一部分，然後會綁定到實參上對模式進行實例化。
構架風格軟體構架（或僅是構架視圖）可以具有名為構架風格的屬性，該屬性減少了可選的形式，並使構架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構件或連接器作為基本構件來定義。對給定系統，某些樣式可作為構架描述的一部分記錄在構架風格指南（Rational Unified Process 中設計指南文檔的一部分）中。樣式在構架的可理解性與完整性方面起著主要的作用。
邏輯視圖：類圖、狀態機和對象圖。進程視圖：類圖與對象圖（包括任務 - 進程與線程）。實施視圖：構件圖。部署視圖：配置圖。
C. 軟體架構有哪些，軟體架構有哪些知識
軟體架構（softwarearchitecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體體系結構是構建計算機軟體實踐的基礎。
D. 系統軟體架構
一、系統總體架構
根據用戶需求完成航空物探資料庫系統概要設計,確定軟體的總體功能,說明軟體的結構,定義軟體的介面,系統運行環境和安全策略。在系統整體構架和需求分析的基礎上構建了整個系統開發的總體架構(圖4-1)。
圖4-1航空物探信息系統架構
二、系統軟體結構
本信息系統採用C/S架構(圖4-2),系統通過區域網和航空物探資料資料庫伺服器(包括Oracle資料庫伺服器和ArcSDE空間資料庫伺服器)連接。資料庫採用大型關系型資料庫Oracle10g作為其後台資料庫,通過ArcSDE對空間數據及其屬性數據進行管理。使用Microsft Visual Studio.NET2003中的C#語言和ESRI的Engine組件來開發信息系統。
三、系統設計
根據航空物探的業務需求、數據安全性、易開發、易維護等要求,將信息系統軟體分成數據採集軟體(C/S)、應用軟體(C/S)兩部分(圖4-3)。
數據採集軟體用於航空物探數據入庫和入庫數據質量控制。應用軟體主要用於提供中心內部的數據查詢統計、數據加工處理等服務。兩個軟體的具體功能在後繼的第六、第七章中詳細論述。
圖4-2 航空物探信息系統軟體結構
圖4-3 信息系統軟體關系圖
E. 常用的軟體架構有那些
1.模塊視圖類型
1)分解風格
2)使用風格
3)分層風格
4)泛化回風格
2.組件連接器類型(C&C)
1)管道過濾器風答格
2)共享數據風格
3)客戶端伺服器風格
4)發布訂閱風格
5)進程通信風格
6)對等通信風格
3.分配視圖類型
1)部署風格
2)實現風格
3)工作任務風格
不知道是不是你想要的結果
F. 軟體構架，架構和框架的區別
結構：程序功能來實現的邏輯自
框架是整個或部分系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法;另一方面也可以說框架是可被應用開發者定製的應用骨架。
框架亦可稱為應用架構，在特定領域基於體系結構的可重用的設計。也可以認為框架是體系結構在特定領域下的應用。框架的例子如MVC。
設計模式 在一定的環境中解決某一問題的方案
構件通常是代碼重用，而設計模式是設計重用，框架則介於兩者之間，部分代碼重用，部分設計重用，有時分析也可重用.
構架是architecture:它是對軟體系統的系統組織，是對構成系統的
構件的介面，行為模式，協作關系等體系問題的決策總和。它不僅涉及
到結構與行為，而且還涉及到系統的使用，功能，性能，適應性，重
用性，可理解性
設計模式比框架更為抽象
設計模式在碰到具體問題後，才能產生代碼；框架已經可以用代碼表示
設計模式是比框架更小的體系結構元素：
框架中可以包括多個設計模式
簡單點說：結構 < 設計模式 < 架構 <框架
結構+演算法=程序(功能代碼塊)
程序與程序之間進行調整=設計模式
多個設計模式相組合(組件)=架構(系統)
G. 軟體架構模式基本概念及三者區別
在做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式：架構模式(Architectural Pattern)、設計模式(Design Pattern)、代碼模式(Coding Pattern)。
架構模式是一個系統的高層次策略，涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框架性結構。
設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行為和它們之間的關系。模式的好壞不會影響到系統的總體布局和總體框架。設計模式定義出子系統或組件的微觀結構。
代碼模式（或成例）是特定的範例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內部、外部的結構或行為的底層細節，但不會影響到一個部件或子系統的中等尺度的結構，更不會影響到系統的總體布局和大尺度框架。
架構模式(Architectural Pattern)
一個架構模式描述軟體系統里的基本的結構組織或綱要。架構模式提供一些事先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。稱之為系統模式。
•MVC模式,一個架構模式常常可以分解成很多個設計模式的聯合使用。MVC模式常常包括調停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、觀察者（Observer）模式等。
•Layers（分層）模式，有時也稱Tiers模式
•Blackboard（黑板）模式
•Broker（中介）模式
•Distributed Process（分散過程）模式
•Microkernel（微核）模式
架構模式常常劃分成如下的幾種：
一、 模塊結構(From Mud to Structure)型。幫助架構師將系統合理劃分，避免形成一個對象的海洋。包括Layers（分層）模式、Blackboard（黑板）模式、Pipes/Filters（管道/過濾器）模式等。
二、分散系統（Distributed Systems）型。為分散式系統提供完整的架構設計，包括像Broker（中介）模式等。
三、人機互動（Interactive Systems）型，支持包含有人機互動介面的系統的架構設計，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
四、Adaptable Systems型，支持應用系統適應技術的變化、軟體功能需求的變化。如Reflection（反射）模式、Microkernel（微核）模式等。
設計模式(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）模式等。
代碼模式(Coding Pattern)
代碼模式（或成例）是較低層次的模式，並與編程語言密切相關。代碼模式描述怎樣利用一個特定的編程語言的特點來實現一個組件的某些特定的方面或關系。
較為著名的代碼模式的例子包括雙檢鎖（Double-Check Locking）模式等
H. 軟體架構和系統架構的區別是什麼
不同的架構方法論，會將架構分為不同視圖，每個視圖側重某一個方面、領域的問題。
比如希賽推的ADMEMS架構體系，分為以下幾種視圖：
1. 數據架構：描述數據的存儲結構、格式等方面。
2. 物理架構：描述機器的物理部署、網路拓撲方面。
3. 運行架構：描述運行期線程、進程間的交互工作機制。
4. 邏輯架構：指如何將代碼分成不同模塊、組件，以及之間的職責分配、交互行為。
5. 開發架構：主要指開發工具的選擇，程序單元的劃分，開發管理規范流程等方面。
例如分為哪些工程、項目，源代碼管理，自動化編譯構建、測試、部署等。
目前國際上運用比較廣泛的是TOGAF架構體系，他把架構分為業務架構、數據架構、應用架構、技術架構等幾個方面。
想詳細的了解這些架構視圖，可以參考這些架構體系相關的書、資料。
另外有很多人無緣無故的抨擊架構概念，不知道是出於調侃還是無知。
埃及的金字塔、神廟的建設，不是幾個平常的泥瓦匠聚在一起就能夠造出來的。
像SAP、Oracle ERP，國內的金蝶等大規模的系統，以及空間站、火箭的控制系統等，沒有系統性的架構方法、規范、流程，結果只能是悲劇。
當規模、復雜度沒有達到一定程度，比如在一些小的團隊、產品中，架構過程可能融入到老闆、經理、組長、資歷較深的一些開發者中，融入在大家的日常工作中，以至於感覺不到架構的存在。
就算遇到一些問題，因規模不大、復雜度不高，也比較容易調整。
當這些前提條件發生變化時，架構的作用和必要性就逐步的體現出來。
總的來說，一說到架構，如果懂軟體，那麼會了解為一個軟體系統，這個軟體設計的組成結構，如哪些是基礎支持組件，哪些是完成A業務，哪些完成B業務……但說道企業架構的時候，就會問，該企業架構的幾個架構如業務架構、數據架構、業務架構、技術架構，以及如何鏈接在一起。
倒覺得，一個企業確實需要這樣的架構，但不要神話它，最主要的是業務如何最終體現到軟體中和流程中。
而採取分離式設計時，最容易的錯誤就是各自為政，集成困難。
那麼以數據為中心的架構設計，會自然提供集成的基礎。
提到過，企業最重要的資產是數據，甚至不是信息，是數據。
企業的業務流程會變，IT系統會變，所需要的信息與知識會變，唯有數據能夠積淀下來。
這有點象自然演進，考古那種，啥都
I. 什麼是軟體架構
當你去了解一個東東的時候，第一步要做的，就應該去知道這個東東的定義，對於軟體架構也是如此，經過網上查詢和書籍的幫助，我大概理清了一個輪廓。
軟體行業是一個熱衷於製造‘名詞’的行業，如果退回15年，估計沒幾個人知道‘軟體架構’是什麼，在上個世紀80年代，隨著軟體開發的規模不斷擴大，軟體開發成為一個行業，初期，隨之而來的是越來越多的軟體項目的失敗，造成項目失敗的原因很多，但主要集中在開發過程，所以軟體工程應運而生，CMMI等流程標准也是一茬接著一茬的冒個不停。
在軟體工程初具規模的時候，軟體開發還是以數據結構+演算法的形式存在，進入20世紀最後10年，隨著面向對象技術、設計模式等在開發過程中的成功應用，軟體架構也走進了大家的視野。
軟體架構在定義上分為‘組成派’和‘決策派’兩大陣營，分別描述如下：
’組成派‘認為軟體架構是將系統描述成計算組件及組件之間的交互
。它有兩個非常明顯的特點：
關注架構實踐的客體——軟體，以軟體本身作為描述對象。
分析了軟體的組成，說明軟體不是一個‘原子’意義上的整體，而是有不同的部分經過特定的介面進行連接組成的一個整體，這對軟體開發來說很重要。
‘決策派’認為
軟體架構包含了一系列的決策
，主要包括：
軟體系統的組織
選擇組成系統的結構元素和它們之間的介面，以及當這些元素相互協作時所體現的行為
用於指導這個系統組織的架構風格：這些元素以及它們的介面、協作和組合
軟體架構並不僅僅關注軟體本身的結構和行為，還注重其他特性：使用、功能性、性能、彈性、重用、可理解、經濟以及技術的限制和權衡等。
‘決策派’有以下兩個顯著的特點：
關注軟體架構中的實體——人，以人的決策為描述對象。
歸納了軟體架構決策的類型，指出架構決策不僅包括關於軟體系統的組織、元素、子系統和架構風格等幾類決策，還包括關於眾多非功能性需求的決策。
按照‘組成派’的觀點，軟體架構關注的是軟體整體的分割和交互，之所以分割，是因為不同的部分在邏輯或物理上相對獨立，通過‘分而治之’的原則進行分割可以更好的理解整個系統，把握用戶的需求，但是雖然整個軟體可以分割成多個模塊或子系統，但是模塊和子系統之間的通信和交互也是很重要的，我想按照這種觀點，架構師的主要任務是將軟體分割成不同的模塊，並定義模塊之間的介面。
按照‘決策派’的觀點，軟體是一個在很多限制下產生的產品，這些限制包括用戶和技術兩方面，用戶方麵包括功能需求、性能需求、硬體需求等，技術方麵包括技術選擇、可擴展性、可重用性、可維護性等。我想按照這中觀點，架構師的主要任務就是作出上述個各種限製作出選擇或決策。《軟體架構設計》 溫昱
J. 什麼是軟體架構
軟體架構
軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用介面_(計算機科學)來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
在「軟體構架簡介」中，David GArlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。」[GS93]
但構架不僅是結構；IEEE Working Group on Architecture 把其定義為「系統在其環境中的最高層概念」[IEEE98]。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在 Rational Unified ProcESs 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。
是一般而言，軟體系統的架構（ArchitECture）有兩個要素：
·它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（TASk-flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
·建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。