架構之:軟體架構漫談

簡介

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

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

什麼是架構

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

随着硬體技術的成熟，能夠處理的任務越來越多，為了處理這麼多的任務，程式設計語言也從面向過程轉變為面向對象，進而更好的适應任務的發展。軟體越來複雜，要處理的任務越來越多，最終導緻了系統架構的産生。

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

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

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

架構的關鍵設計原則

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

1. 關注點分離原則

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

1. 單一責任原則

系統的每個子產品都應負一個特定的責任，這有助于使用者清楚地了解系統。它還有助于元件與其他元件的內建。

1. 最少知識原理

任何元件或對象都不應該擷取其他元件的内部細節。這種方法避免了互相依賴，并提高可維護性。

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

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

1. 不要重複功能

“不重複功能”指的是不要重複元件的功能，一個邏輯的實作，隻應該存在于一段代碼中。如果有多處代碼的拷貝，那麼在邏輯發生變化的時候，功能的重複會使其難以實施更改，降低清晰度并引入潛在的不一緻之處。

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

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

1. 定義不同層之間的通信協定

要對部署方案和生産環境有完整的了解，進而制定出或者使用合适的通信協定。

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

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

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

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

1. 設計異常和異常處理機制

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

1. 命名約定

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

架構的描述

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

UML

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

UML是可視化的模組化語言，裡面包含很多元件，這些元件通過不同的方式關聯，進而形成了完整的UML圖。盡管通常使用UML對軟體系統進行模組化，但它并不局限于此範圍。UML也被用于模組化非軟體系統，例如制造單元中的流程。

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

結構圖表示系統的靜态元件。 這些靜态元件由類，接口，對象，元件和節點表示。結構圖包含下面幾個部分：

1. 類圖： 表示面向對象系統中的各個類和他們間的關系。
2. 對象圖：對象圖表示的是運作時的對象和他們的關系。
3. 元件圖：元件圖描述的是系統中的所有元件、接口和他們的互動關系。
4. 複合結構：描述元件的内部結構，包括所有類，元件的接口等。
5. 包：包主要是包含類和其他的包。
6. 部署圖：部署圖是一組節點及其關系。 這些節點是部署元件的實體實體。

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

1. 用例圖：描述功能及其内部/外部控制器之間的關系。 這些控制器被稱為參與者。
2. 活動圖：描述系統中的控制流。 它由活動和連結組成。 該流可以是順序的，并發的或分支的。
3. 狀态圖：表示系統的事件驅動狀态更改。 它描述了類，接口等的狀态變化。
4. 序列圖：可視化系統中執行特定功能的順序。
5. 組合活動圖和序列圖以提供系統和業務流程的控制流概述。

架構視圖

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

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

它包含了4個基本的視圖，分别是：

1. 邏輯視圖或概念視圖-它描述了設計的對象模型。    
   2.  流程視圖-描述了系統的活動，包括并發和同步。     
   3. 實體視圖-它描述了軟體到硬體的映射并反映了其分布式關系。   
   4.  開發視圖-它描述了環境開發中軟體的靜态組織和結構。      

最後的+1視圖表示的是為最終使用者或客戶添加一個稱為方案視圖或用例視圖的視圖。它和其他的4個視圖是一緻的，是以被稱為+1 視圖。

ADL

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

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

總結

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

本文已收錄于 http://www.flydean.com/06-software-architecture/

最通俗的解讀，最深刻的幹貨，最簡潔的教程，衆多你不知道的小技巧等你來發現！

歡迎關注我的公衆号:「程式那些事」,懂技術，更懂你！