軟件架構的概念

     我這樣定義軟件架構：軟件系統包含的主要元素、重要約束與關鍵決策，以及它們之間的關係並如何進行協做交互，以知足軟件系統的不一樣涉衆需求。

　　首先說說主要元素。這裏說的元素不但包括接口、類、組件，還應有框架、子系統、獨立程序（如數據庫服務器）、管道、消息等。爲何是主要元素而不是全部元素？1、從需求的角度用戶首先並主要關注核心業務需求的知足，若是核心業務需求不能知足，其它的一切都沒必要講。這就比如去買手機，若是這部手機不能正常通話，就是再美觀、有再多的輔助功能，也不能成其爲手機，也就不會有人購買。軟件架構做爲與客戶等涉衆人員溝通的工具，不能重點關注如何知足這些核心業務需求的要求，也就失去它存在的意義。若是可以有效的把握這些主要的核心業務需求，也就離軟件項目的成功不遠了。2、從軟件項目開發的現實來看，大多數軟件項目都面臨項目工期的壓力，軟件架構工程師必須在必定的時間內決定架構設計方案，不然沒有軟件架構所提供的對技術的足夠指導以及對分工協做的足夠限制，開發設計編碼團隊將面臨項目失敗的風險。因此軟件架構工程師沒有時間對全部元素進行深刻分析。3、人的精力、能力是有限的，若是不能把主要精力和時間花在決定軟件項目成功的核心業務需求上，而是全部軟件需求與元素上，最終致使全部需求與元素都分析了又都不夠深刻，這樣的軟件架構只能是流於形式的軟件架構，對提升軟件的質量不但沒有幫助反而會害軟件項目失敗。

最容易被忽略的多是重要約束。在說明重要約束的重要性前看看這樣一個例子：C/S軟件系統須要實現信息量不大的高併發實時網絡通信，對於大多數有經驗的軟件架構工程師都會摒棄SELECT方式的不管是同步仍是異步、阻塞仍是非阻塞SOCKET通信模式，而會選擇IOCP。但若是軟件系統有一條運行約束：系統必須運行在LINUX下，整個軟件系統的架構都面臨巨大沖擊：LINUX下根本不支持IOCP！必須使用EPOLL。因此，許多約束之中其實隱藏着一些隱含的需求，它經過如下三種路徑影響軟件系統：1、直接制約設計決策。如上面的例子，架構工程師必須直接遵循，並影響關鍵決策。2、引伸並轉化爲功能需求。這種狀況下可能會增長軟件系統的元素，若是在軟件架構中不進行必要的說明，軟件項目的涉衆人員可能會對這些「平白無故忽然冒出來的」元素表示疑惑。3、引伸並轉化爲非功能需求。這種狀況下也可能會影響關鍵決策。

　　能夠這樣講：軟件架構的每個過程當中的每一步工做都是一系列的重要設計決策。但是最難讓人理解是軟件架構如何包含決策？這裏有兩個誤解：一是認爲軟件架構就是RUP的4+1視圖與軟件架構文檔，因此沒法說明這些決策。二是在軟件架構中引入的每個設計模式、框架，其實就表現了一系列決策。因此雖然人們不理解軟件架構如何包含決策，但其實每一位架構工程師都在不自覺的包含決策。我之因此提出是但願在架構過程當中應主動有意識的包含這些關鍵決策。

　　主要元素、重要約束與關鍵決策從局部靜態孤立的說明了軟件系統的組成成份，而它們之間的關係則是說明它們是如何靜態組成一個有機的軟件系統總體的；如何進行協做交互則是從動態的角度說明軟件系統是能進行怎樣的行爲、怎樣知足軟件系統的不一樣涉衆需求。