解析軟件架構概念

組合派：軟件系統的架構將系統描述為計算組件及組件之間的交互。
決策派：架構是一系列重要決策的集合，這些決策與以下內容有關：軟件的組織，構成系統的結構元素及其接口的選擇，這些元素在相互協作中明確表現出的行為，這些結構元素和行為元素進一步組合所構成的更大規模的子系統，以及指導這一組織--包括這些元素及其接口、它們的協作和它們的組合--架構風格。

如：伴隨著對軟件系統的依次分解，軟件架構師應當不斷做出決策，例如需要劃分成哪些模塊、每個模塊的職責為何、每個模塊的接口如何定義、模塊間采用何種交互機制、如何滿足約束和質量屬性需求、如何適應可能發生的變化等等。

子系統、框架與架構

框架與架構的區別：框架是軟件，架構不是。
框架是一種特殊的軟件，它并不能提供完整的解決方案，而是為你構建解決方案提供良好的基礎。框架中的服務可以被最終應用系統直接使用，而框架中的擴展點是供開發人員定制的'可變化點'。
軟件架構不是軟件，而是關于軟件如何設計的重要決策。涉及到如何將軟件系統分解成不同的部分、各部分之間的靜態結構關系和動態交互關系等。
框架和架構的關系
1. 為了盡早驗證架構設計，或者出于支持產品線開發的目的，可以將關鍵的通用機制甚至整個架構以框架的方式進行實現。
2. 業界可能存在大量可供重用的框架，這些框架或者已經實現了軟件架構所需的重要架構機制，或者為未來系統的某個子系統提供了可擴展的半成品，所以最終的軟件架構可以借助這些框架來擴展。

框架和架構技術的出現，都是為了解決系統的復雜性而采取"分而治之"思維的結果--先大局后局部，就出現了架構；先通用后專用，就出現了框架。架構是問題的抽象解決方案，它關注大局而忽略細節；而框架是通用的半成品，還必須根據具體需求進一步定制開發才能變成應用系統

軟件架構的作用

錯誤守恒定律：在一個大型系統內仍然存在的錯誤數目和已經修改的錯誤數目成正比。也就是說，一個缺陷充斥的系統將始終是一個缺陷充斥的系統。

軟件架構視圖

多重軟件架構視圖之所以必不可少，是因為各類涉眾（用戶、客戶、開發人員、測試人員、維護人員、其他人員）需要從各自的角度理解和使用架構。另一方面，每個軟件架構視圖關注軟件架構不同的方面，使問題得以清晰化和簡化，利于軟件架構師完成架構設計工作，這也是"分而治之"的思想。
可簡單分為邏輯架構和物理架構。邏輯元素一般指某種級別的功能模塊。邏輯架構設計的三大核心任務：
識別功能模塊
規劃功能塊的接口
明確功能塊之間的使用關系和使用機制

多視圖架構設計可以幫助架構師完成下述工作：
1、 要滿足性能、持續可用性等方面的需求，架構師必須深入研究軟件系統運行期間的情況、制定相應的設計決策，這些需求被稱為軟件的"運行期質量屬性"。
2、 而要滿足可擴展性、可重用性等方面的需求，則要求架構師深入研究軟件系統開發期間的情況、制定相應的設計決策，這些需求被稱為軟件的"開發期質量屬性"
3、 約束是一類特殊的需求，帶有一定強制性，架構師制定的架構決策必須滿足這些限制
4、 為了滿足功能需求，架構師必須規劃組成軟件系統的所有模塊，為他們分配不同職責，使這些模塊可以通過協作完成功能需求

軟件架構要設計到什么程度

我不會認為Coding和Designing是對立的。問題在于，那些設計人員的設計往往是高來高去的扯淡，脫離實際情況，二者的矛盾就必然存在。
分而治之有兩種方式，一種是"按問題的深度分而治之"，如接口和實現分離（如分層結構）；一種是"按問題的廣度分而治之"，如把系統分為不同的子系統。
高來高去架構設計的問題和對策：
問題：遺漏了對團隊某些角色的指導。對策：針對遺漏的架構視圖進行設計
問題：不夠深入。對策：設計決策須細化到和技術相關的層面
問題：只用了分層架構的分層概念來進行職責劃分，沒有明確層次之間的交互接口和交互機制。對策：明確它們。

理解軟件工程概念模型

模型就是抽象，就是有意識地忽略事物的某些特征，識別出關鍵元素。抽象帶來的好處就是能夠反映模型中元素之間的關系，清楚把握大局。

《軟件工程--技術、方法與環境》一書中，有一個極為精簡的軟件工程概念模型：?

?

該模型可以用一句話概括：軟件工程是（目標，方法，活動）三元組。它體現了目標-方法-活動的3維正交關系：

? 任何目標，都要依照特定方法，由特定活動實現；
? 任何方法，都是指導特定活動，來完成某種目標；
? 任何活動，都由特定方法指導，來完成某種目標。

一個簡單的PM Tool案例
該案例貫穿了該書很多章節，這里截取了一小段，對于理解如果進行架構設計實踐有一定幫助：http://book.csdn.net/bookfiles/383/10038314312.shtml ------------------------------------------------------- 書名：軟件架構設計 作者：溫昱著 來源：電子工業出版社 出版時間：2007年05月 ISBN:9787121039461 定價：45元 1.5? PM Tool案例：領會軟件架構概念 為了有助于領會軟件架構的概念，我們引入一個名為“PM Tool”的案例。PM Tool是一個項目管理系統，提供項目計劃、任務管理和資源管理等功能。本節希望結合案例來討論軟件架構，為讀者理解軟件架構的概念帶來實感。 1.5.1? 案例故事 PM Tool有一項名為“查看甘特圖”的需求，用戶要求“能夠以甘特圖方式查看任務的起始時間、結束時間、任務承擔者等信息”。經過分析我們不難發現，PM Tool至少應提供兩種查看任務計劃的方式：一種是以表格的方式將任務名稱、開始時間等信息列出，另一種是采用甘特圖。如圖1-6所示。 圖1-6? PM Tool至少要提供兩種查看任務計劃的方式 任務是如何計劃的？又具體分配給哪些項目成員？這些信息和PM Tool采用何種方式來展現應當是沒有關系的。根據此分析，我們立即想到采用MVC架構，將業務邏輯和展現邏輯分開，如圖1-7所示。 圖1-7? 和具體技術無關的架構方案 上面的架構設計，還處于“和具體技術無關”的層面。我們必須考慮更多的實際開發中要涉及到的技術問題，從而不斷細化架構方案，這樣才能為開發人員提供更多的指導和限制，也才能真正降低后續開發中的重大技術風險。 對于PM Tool要顯示甘特圖而言，“甘特圖繪制包”是自行開發的，還是采用的第三方SDK，就是一個很重要的技術問題。考慮如下： 一方面，用戶根本不關心“甘特圖繪制包”的問題，他們只在乎自己的需求是否得到了滿足；而項目工期是很緊的，自行開發“甘特圖繪制包”勢必增加其他工作的壓力，為什么不采用第三方SDK呢？ 另一方面，短期內決定采用的第三方“甘特圖繪制包”可能并不是最優的，所以并不希望PM Tool“綁死”在特定“甘特圖繪制包”上。 基于以上分析，架構師會決定：采用第三方SDK，但會自主定義“甘特圖繪制接口”將SDK隔離。如圖1-8所示。 圖1-8? 和技術相關的架構方案 有的讀者應該已經看出來了，上述設計中采用了Adapter設計模式。

適配器（Adapter）模式 關鍵字：已存在/不可預見? 復用 支持變化：由于Adapter提供了一層“間接”，使得我們可以復用一個接口不符合我們需求的已存在的類，也可以使一個類（Adaptee）在發生不可預見的變化時，僅僅影響Adapter而不影響Adapter的客戶類。 結構：

1.5.2? 軟件架構概念的體現 有關PM Tool的案例故事先講到這兒，雖然其中僅涉及到架構設計方案的一小部分，但仍然可以體現軟件架構的概念——對組成派和決策派的架構概念都有體現。 先說組成派的架構概念，它強調軟件架構包含了“計算組件及組件之間的交互”。組件體現在哪里呢？ 在圖1-7所展示的設計中，“業務層”和“展現層”就是兩個組件；當然，這兩個組件粒度很粗，并且完全是黑盒。 到了圖1-8所展示的設計中，黑盒雖然沒有完全變成白盒，但支持MVC協作機制的一部分關鍵類已經明確——PrgMgtModel、GanttChart和GanttChartImpl都是粒度較細的組件，可以說，“業務層”和“展現層”兩個組件在某種程度上已從黑盒變成了灰盒，從而能提供更具體的開發指導。 那么，軟件架構概念中所說的“交互”體現在哪里呢？ 對于圖1-7所展示的設計，“業務層”和“展現層”兩個粗粒度組件之間的交互為：展現層從業務層“讀取數據”。 “讀取數據”這一交互到了圖1-8的設計依然存在，但此職責已經“具體落實”成了“GanttChartImpl從PrgMgtModel讀取數據”。另外，圖1-8的設計中，兩個“調用”關系也是軟件架構的概念中“交互”的具體例子。 由此看來，組成派軟件架構概念完全是對架構設計方案的忠實概括，只不過有一點兒抽象罷了。 再看看決策派的架構概念，它歸納了架構決策的類型，指出架構決策不僅包括關于軟件系統的組織、元素、子系統、架構風格等的幾類決策，還包括關于眾多非功能需求的決策。圖1-7所展示的設計那么簡單，也包含了設計決策嗎？是的，業務層和展現層分離，體現了架構概念中的“軟件系統的組織”決策，這一設計決策早已得到了業界的普遍認同。 下面再舉個例子，來說明軟件架構中的設計決策是如何支持“使用、功能性、性能、彈性、重用、可理解性、經濟和技術的限制及權衡，以及美學等”非功能需求的。僅以“彈性”為例吧。為了防止PM Tool“綁死”在特定甘特圖繪制包上，架構設計之時作了如下決策（參見圖1-8）：引入自主定義的GanttChart接口，讓實現該接口的GanttChartImpl轉而調用第三方SDK（其實就是Adapter設計模式）。這樣一來，架構就有了彈性——當發現功能更強大的甘特圖程序包時（或決定直接調用Java 2D自行開發甘特圖繪制部分時），可以方便地僅更改GanttChartImpl，而其他組件不用更改（如圖1-9所示）。 圖1-9? 軟件架構如何具有彈性 1.5.3? 重要結論 通過上述分析，我們高興地看到：組成派和決策派軟件架構概念并不矛盾，它們只不過是所站的角度不同罷了；在具體的軟件架構實踐中，總是同時體現著這兩“派”的架構概念。 1.6? 總結與強調 不積跬步，無以至千里。本章僅是一小步，討論軟件架構的基本概念。雖然本書旨在系統地說明軟件架構設計的方法與過程，但首先闡明軟件架構的概念是大有裨益的，也是非常必要的。 軟件架構概念是多樣的。雖然軟件架構的概念至今依然沒有統一，但作為軟件架構師，我們不能“揣著手兒”等待，將軟件架構的概念總體上分為組成派和決策派，有利于我們理解軟件架構概念的精髓。 本章還通過“用案例說話”的方式，說明了兩個架構概念流派雖然角度不同，但卻相輔相成。我們既應從“架構＝組件＋交互”的觀點中獲益，又應運用“架構＝重要決策集”的實踐經驗，這一點對于軟件業界的實踐者（而不僅僅是理論研究者）尤其重要。

轉載于:https://blog.51cto.com/liweibird/225543

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的什么是“软件架构设计”（推荐）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。