架構之:軟體架構漫談

　　簡介

　　每一個程式設計師心中都有個架構師的夢想，架構是如此的重要，以至於每個程式設計師都在談架構，彷彿沒有架構的軟體是沒有靈魂的，不想做架構師的程式設計師不是一個好的碼農一樣。

　　那麼架構到底是什麼呢？架構是怎麼得到的呢？今天本文將會從自身的經驗來闡述一下對架構的看法。

　　什麼是架構

　　在軟體發展的初期是沒有架構而言的。從最早的組合語言到過程語言，他們處理的是一個個任務，為此編制了一個個的函式來執行對應的任務。這時候的軟體程式語言還是過程語言，所以談不上架構。

　　隨著硬體技術的成熟，能夠處理的任務越來越多，為了處理這麼多的任務，程式語言也從程式導向轉變為物件導向，從而更好的適應任務的發展。軟體越來複雜，要處理的任務越來越多，最終導致了系統架構的產生。

　　架構是在複雜軟體結構中產生的，它的任務就是讓這些複雜軟體中的任務能夠互相協作從而來完成共同的任務。當然這是從軟體的目標來說的。如果再考慮軟體的實現和擴充套件性，那麼好的架構需要讓系統可讀性和可擴充套件性更強，給未來留出一定的空間。如果從可靠性和可用性來講，好的架構還需要保證系統高可用和容錯性。

　　我們要注意的是，架構並不是空想而來的，它的基石在於編寫的程式。所以架構需要跟程式緊密結合才能產生活力。

　　系統的架構主要描述的是系統的主要元件和這些元件之間的關係和他們如何進行互動。

　　架構的關鍵設計原則

　　為了最大程度的降低成本，滿足功能需求，並最大程度的提高系統結構的可擴充套件性和可用性，我們需要考慮下面幾個關鍵的設計原則：

　　1. 關注點分離原則

　　將系統的元件按照特定的功能進行劃分，從而是元件的功能之間沒有重複。從而保證高內聚力和低耦合度。這種方法避免了系統元件之間的相互依賴性，有助於簡化系統。

　　單一責任原則

　　系統的每個模組都應負一個特定的責任，這有助於使用者清楚地瞭解系統。它還有助於元件與其他元件的整合。

　　最少知識原理

　　任何元件或物件都不應該獲取其他元件的內部細節。這種方法避免了相互依賴，並提高可維護性。

　　最大限度地減少前期的大型設計

　　如果應用程式的需求不清楚，則最大程度地減少前期的大型設計。從小的原型出發，在探索中確認好需求。避免後期因為需求變動導致的巨大重構工作量。

　　不要重複功能

　　“不重複功能”指的是不要重複元件的功能，一個邏輯的實現，只應該存在於一段程式碼中。如果有多處程式碼的複製，那麼在邏輯發生變化的時候，功能的重複會使其難以實施更改，降低清晰度並引入潛在的不一致之處。

　　重用功能時要優先考慮組合而不是繼承

　　繼承會在子類和父類之間建立依賴關係，因此會阻止子類的自由使用。相反，組合提供了很大的自由度並減少了繼承層次結構。

　　定義不同層之間的通訊協議

　　要對部署方案和生產環境有完整的瞭解，從而制定出或者使用合適的通訊協議。

　　定義元件之間互動的資料格式

　　各種元件將透過資料格式相互互動。最好統一資料格式，從而使應用程式易於實現，擴充套件和維護。透過使用相同的資料格式，以便各個元件在相互通訊時無需對資料進行編碼/解碼。它減少了處理開銷。

　　系統服務元件應該是抽象的

　　與安全性，通訊或系統服務（例如日誌記錄，概要檔案和配置）相關的程式碼應在單獨的元件中抽象出來。請勿將此程式碼與業務邏輯混合使用，這樣擴充套件設計和維護將會變得容易。

　　設計異常和異常處理機制

　　預先定義異常，有助於元件以優雅的方式管理錯誤或意外情況。最好在整個系統中使用相同的異常處理機制。

　　命名約定

　　命名約定應事先定義。它們提供了一個一致的模型，可以幫助使用者輕鬆理解系統。團隊成員更容易驗證其他人編寫的程式碼，因此會增加可維護性。

　　架構的描述

　　既然架構這麼重要，我們可以使用什麼樣的手段才能夠描述架構中的元件、元件之間的聯絡和他們的互動呢？業界也探討了很多方法。這裡我們也來介紹幾種方法。

　　UML

　　UML大家應該都很熟悉了，它的全稱是統一建模語言，它是一種圖形語言。UML1.0規範是在1997年1月由物件管理組（OMG）提出的。它用作軟體需求分析和設計文件的標準，這些文件是開發軟體的基礎。

　　UML是視覺化的建模語言，裡面包含很多元件，這些元件透過不同的方式關聯，從而形成了完整的UML圖。儘管通常使用UML對軟體系統進行建模，但它並不侷限於此範圍。UML也被用於建模非軟體系統，例如製造單元中的流程。

　　UML主要分成兩大類別：結構圖和行為圖。

　　結構圖表示系統的靜態元件。 這些靜態元件由類，介面，物件，元件和節點表示。結構圖包含下面幾個部分：

　　類圖： 表示物件導向系統中的各個類和他們間的關係。

　　物件圖：物件圖表示的是執行時的物件和他們的關係。

　　元件圖：元件圖描述的是系統中的所有元件、介面和他們的互動關係。

　　複合結構：描述元件的內部結構，包括所有類，元件的介面等。

　　包：包主要是包含類和其他的包。

　　部署圖：部署圖是一組節點及其關係。 這些節點是部署元件的物理實體。

　　行為圖表示的是系統中可能出現的動作，行為圖可以包含下面幾種：

　　用例圖：描述功能及其內部/外部控制器之間的關係。 這些控制器被稱為參與者。

　　活動圖：描述系統中的控制流。 它由活動和連結組成。 該流可以是順序的，併發的或分支的。

　　狀態圖：表示系統的事件驅動狀態更改。 它描述了類，介面等的狀態變化。

　　序列圖：視覺化系統中執行特定功能的順序。

　　組合活動圖和序列圖以提供系統和業務流程的控制流概述。

　　架構檢視

　　檢視是從一組相關關注點的角度對整個系統的表示。它用於從不同的利益相關者（例如終端使用者，開發人員，專案經理和測試人員）的角度描述系統。這裡給大家介紹一個叫做4 + 1的檢視模式。

　　4 + 1檢視模型是由Philippe Kruchten發明的。該模型基於對多個檢視和併發檢視的使用來描述軟體密集型系統的體系結構。它是一個多檢視模型，解決了系統的不同功能和關注點。它使軟體設計文件標準化，並使所有利益相關者易於理解設計。

　　它包含了4個基本的檢視，分別是：

　　1. 邏輯檢視或概念檢視-它描述了設計的物件模型。

　　2.  流程檢視-描述了系統的活動，包括併發和同步。

　　3. 物理檢視-它描述了軟體到硬體的對映並反映了其分散式關係。

　　4.  開發檢視-它描述了環境開發中軟體的靜態組織和結構。

　　最後的+1檢視表示的是為終端使用者或客戶新增一個稱為方案檢視或用例檢視的檢視。它和其他的4個檢視是一致的，所以被稱為+1 檢視。

　　ADL

　　架構描述語言ADL是一種語言，提供用於定義軟體體系結構的語法和語義。它是一種註釋規範，提供了用於對軟體系統的概念體系結構進行建模的功能，這與系統的實現有所不同。

　　架構描述語言是一種形式化的規範語言，它描述諸如程式，執行緒，資料和子程式之類的軟體功能，以及諸如處理器，裝置，匯流排和記憶體之類的硬體元件。

　　總結

　　今天的架構漫談就講到這裡，有不住之處還希望大家多多指正。後續會給大家介紹幾種常見的架構模式。希望大家能夠喜歡。