軟件架構視圖
方法指導過程，過程包含步驟。
所謂軟件架構就是關於如何構建軟件的一些最重要的設計的決策，這些決策往往是圍繞將系統分爲哪些部分、各部分之間如何交互展開的。不同的涉衆看待軟件架構的視角是不同的。軟件架構是抽象的概念，所以在軟件架構概念與實踐之間，似乎存在某種“鴻溝”——即缺失某種概念，而這種概念可以“鏈接”軟件架構的概念和實際的開發實際的需要，爲不同涉衆理解和交流架構提供更專一的視角。爲了在軟件架構純概念和實踐之間搭起一座橋樑，可以引入軟件架構視圖的概念。軟件架構師應當時時牢記：爲用戶而設計，不僅滿足用戶要求的功能，也要達到用戶期望的質量。架構師也必須爲客戶而設計，適合的纔是最好的。架構師還應該爲開發人員而設計，關注軟件的“開發期質量屬性”（可擴展性、可移植性、易理解性和易測試性等非功能需求，都是屬於軟件開發期質量屬性），爲開發人員而設計。軟件越來越複雜，單兵作戰已經不再是普遍的軟件開發方式，取而代之的是團隊開發，而團隊開發又反過來使軟件開發更加複雜，因爲現在不僅僅要面臨技術複雜性的問題了，還有管理複雜性的問題。軟件架構從大局着手，就技術方面的重大問題做出決策，構造一個由粗粒度模塊組成的解決方案，從而可以把不同模塊分配給不同小組分頭開發。另一方面，軟件架構設計方案規定了各模塊之間如何交互的機制和接口，在開發小組之間起到“溝通橋樑”和“合作契約”的作用。配置管理員應該能夠從軟件架構方案中瞭解到開發出來的軟件以什麼樣的目錄結構存在，以及編譯過後的軟件目標模塊放到哪個目錄等決定，並以此作爲制定配置管理基本方案的基礎。所以，架構師應該爲項目相關不同的角色而設計。軟件架構師必須做到內外兼修、各層並重。只有這樣，軟件架構才能和它“包含了關於如何構建軟件的一些最重要的設計決策”的“地位”相符。
一個軟件架構視圖是對與從某一視角或某一點上看到的系統所作出的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了與此方面無關的實體。軟件架構的每個視圖分別關注不同的方面，針對不同的目標和用戶。軟件架構師應當提供不同的軟件架構視圖，以便交流和傳遞設計思想。每個軟件架構視圖關注軟件架構不同的方面，使問題得以清晰和簡化，利於軟件架構師完成架構設計的工作。項目不同角色觀察軟件架構的視角各不相同，每個視角涉及的需求和技術也不盡相同，所以將軟件架構視圖用作軟件歸檔的手段是順利成章的：但更爲重要的是，軟件架構視圖可以被相對獨立地分析和設計，這就使得軟件架構師可以暫時撇開其他問題、專注於特定問題進行深入的分析和設計。
最常用的兩種架構視圖：邏輯架構視圖和物理架構視圖。當觀察和描述事物大局的時候，邏輯架構和物理架構是最常用的角度。軟件邏輯架構設計的三大核心任務：識別功能塊；規劃功能塊的接口；明確功能塊之間的使用關係和使用機制。軟件的邏輯架構是架構設計思維的重要方法。用例技術已經成爲捕獲功能需求的事實標準，所以邏輯架構的設計往往是從用例分析開始的。基於用例的分析方法使邏輯架構的設計變得比較有序——通過對每個關鍵用例的分析，從邏輯上將用例實現爲一組功能塊的特定組合，最後綜合這些用例分析成果，得到整個軟件系統的邏輯架構。物理架構可以反映出軟件系統運行時的組織情況。“物理元素”就進程、線程以及作爲類的運行時實例的對象等，而進程調度、線程同步、進程或線程通信等則進一步反映物理架構的動態行爲。物理層和分別有關，通過將一個整體的軟件系統劃分爲不同的物理層次，可以把它部署到分別在不同位置的多臺計算機上，從而爲遠程訪問和負載均衡等問題提供了手段。物理層是大粒度的物理單元，它最終是由粒度更小的組件、模塊和進程等單元組成。邏輯架構和物理架構是軟件架構設計的重要方面。邏輯架構致力於將軟件系統分解成不同的邏輯單元，並規定這些邏輯單元之間的交互接口和交互機制。物理架構則更重視軟件系統運行時的動態結構，以及組成軟件系統的目標程序如何部署到硬件上。邏輯架構中關於職責劃分的決策，體現爲層、子系統和模塊等的劃分決定，從靜態視角爲詳細設計和編程實現提供切實的指導；有了分解就必然產生協作，邏輯架構還規定了不同邏輯單元之間的交互接口和交互機制，而編程工作必須實現這些接口和機制。所謂交互機制，就是指不同軟件單元之間的交互手段。交互機制可以是本地方法調用、基於RMI的遠程方法調用、異步消息等。至於物理架構，它關注的是軟件系統在計算機中運行期間的情況。軟件的物理架構關注“目標程序及其依賴的運行庫和系統軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等需求。物理層作爲組成軟件系統的物理單元，最終又要映射到具體的硬件，這也是物理架構設計要考慮的，對於分佈式軟件系統的設計而言尤其不可或缺。
不同的視圖支持不同的目標和用途。
軟件架構師有許多工作要做：
- 要滿足性能、持續可用性等方面的需求，架構師必須深入研究軟件系統運行期間的情況、制定相應的設計決策，這些需求被稱爲軟件的“運行期質量屬性”；
- 而要滿足可擴展性、可重用性等方面的需求，則要求架構師深入研究軟件系統開發期間的情況，制定相應的設計決策，這些需求被稱爲軟件“開發期質量屬性”；
- 約束是一類特殊的需求，帶有一定強制性，架構師制定的架構決策必須滿足這些限制；
- 爲了滿足功能需求，架構師必須規劃組成軟件系統的所有模塊，爲他們分配不同職責，使這些模塊可以通過協作完成功能需求。
架構師必須明確區分功能需求、約束、運行期質量屬性和開發期質量屬性等不同種類的需求。
架構設計的5視圖方法包括：邏輯架構、開發架構、運行架構、物理架構、數據架構。邏輯架構關注功能，它們可能是邏輯層、功能模塊和類等。開發架構關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件。運行架構關注進程、線程、對象等運行時概念，以及相關的併發、同步、通信等問題。物理架構關注“目標程序及其依賴的運行庫和系統軟件”最終如何安裝和部署到物理機器上，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。數據架構關注持久化數據的存儲方案，不僅包括實體及實體關係的數據存儲格式，還可能包括數據傳遞、數據複製和數據同步等策略。
邏輯架構的設計着重考慮功能需求，系統應當向用戶提供什麼樣的服務。邏輯架構的關注點主要是行爲或職責的劃分。邏輯架構的靜態方面關注抽象職責的劃分，其動態方面關注承擔不同職責的邏輯單元之間的交互。開發機構的設計着重考慮開發週期質量屬性，例如可用性、可擴展性、易理解性和易測試性等。開發架構的關注點是在軟件開發環境中軟件模塊的實際組織方式。運行架構的設計着重考慮運行期質量屬性，例如性能、可伸縮性、持續可用性和安全性等。運行架構的關注點是系統的併發與同步等問題，這勢必涉及到進程和線程等技術。運行架構的靜態方面關注軟件的運行時單元結構，其動態方面則關注運行時單元之間的交互機制。物理架構的設計着重考慮“安裝和部署需求”，另外物理架構還應關注相關的可靠性、可伸縮性、持續可用性、性能和安全性等方面。數據架構的設計着重考慮“數據需求”。數據架構的關注點是持久化數據的組織、數據傳輸、數據複製和數據同步等策略。
五種架構視圖，反映的是同一個軟件系統的不同設計方面，它們最終合在一起纔是完整的架構設計方案，所以不同的架構視圖之間勢必有相互支撐的關係。所謂保持架構視圖之間的同步，就是保證不同視圖之間是相互解釋而不是相互矛盾的。如果需要，可以引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策。另外，約束是必須遵守和考慮到的，每個架構設計視圖都應該注意這一點。五種不同的元素撐起了不同的思維空間，從而使每個架構視圖重點覆蓋不同種類的需求。
概念架構和實際架構
實際的軟件架構設計過程是，一般應先進行概念性架構的設計，把最關鍵的設計要素和交互機制確定下來，然後再考慮具體技術的運用，設計出實際架構。概念性架構是對系統設計的最初構想。概念性架構沒有嚴格的定義，而且也不應該過於嚴格的定義。概念性架構包括一些高層次的設計選擇，對未來軟件系統的質量和功能都起着關鍵影響。複雜系統的設計往往不能一蹴而就，而概念性架構就是最初的架構設計成果。
經典的分層架構的層指邏輯層（Layer），而現在的分佈式應用的分層架構是指物理層（Tier）。邏輯層是一種功能和職責的組織單元，而物理層要求功能和責任的高聚合性，只不過往往是通過多個邏輯層映射到一個物理層這種方式實現的。
雖然概念性架構都跳不出“架構=組件+交互”的基本定義，但它們描述架構的具體方式還是差異很大的：有的重視邏輯層，有的重視物理層，有的通過隱喻表明機制，有的看上去似乎就是一些設計元素的組合。不同的概念性架構圖中，“連接”所代表的含義千差萬別：有的是依賴方向，有的是控制方向，有的是數據流向。由於概念架構的高度抽象性，使得同屬一類的許多軟件產品的概念性架構是趨同的。概念性架構非常相似，實際架構卻可能有很大的差異。概念性架構往往和具體技術的運用、具體平臺的選擇無關，而實際架構非常關心這些問題。實際的架構設計方案應該兼顧不同的架構設計視圖。概念性架構所包含的高層設計決策終究不會跳出如下多種架構視圖的範圍——邏輯架構、物理架構、開發架構、數據架構和運行架構。而實際架構必須設計到可以指導開發的程度。但務實地來講，概念性架構經常從邏輯架構和物理架構的角度制定高層設計決策。
概念性架構是不可直接實現的。概念性架構和實際架構的一些區別，主要涉及到開發人員最關心的點：
接口如何定義；
子系統如何劃分；
各子系統或模塊之間的如何進行交互；
共同點：概念性架構和實際架構都滿足軟件架構的概念——無論是“架構=組件+交互”，還是“架構=重要的決策集”。
分層架構往往是我們架構思維的開始，在“分層”的基礎上如何深入，細化設計，如何調整往往是架構設計的關鍵。
概念性架構往往和具體技術的運用和具體平臺的選擇無關，而實際架構則非常關係這些問題，概念性架構並不規定要採用OO技術，但設計實際架構時往往要考慮如何充分利用OO技術來實現概念性架構。從概念性架構到實際架構，先設計概念性架構，構思關鍵問題的解決策略；再進行實際架構設計，以保證爲開發提供足夠的指導和限制。
