軟體架構理解和延伸

天府雲創發表於2017-09-04
架構
軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。
軟體架構是一個系統的草圖。軟體體系結構是構建計算機軟體實踐的基礎。

簡介


定義

軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在物件導向領域中，元件之間的連線通常用介面來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

目標

正如同軟體本身有其要達到的目標一樣，架構設計要達到的目標是什麼呢？一般而言，軟體架構設計要達到如下的目標：
可靠性（Reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。
安全性（Secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。
可伸縮性（SCAlable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。
可定製化（CuSTomizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。
可擴充套件性（Extensible）。在新技術出現的時候，一個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充套件。
可維護性（MAIntainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低技術支援的花費。
客戶體驗（Customer Experience）。軟體系統必須易於使用。
市場時機（Time to Market）。軟體使用者要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

歷史


早在1960年代，諸如E·W·戴克斯特拉就已經涉及軟體架構這個概念了。自1990年代以來，部分由於在 Rational Software Corporation 和Microsoft內部的相關活動，軟體架構這個概念開始越來越流行起來。
卡內基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡內基·梅隆大學的Mary Shaw和David Garlan於1996年寫了一本叫做 Software Architecture perspective on an emerging DIscipline的書，提出了軟體架構中的很多概念，例如軟體元件、聯結器、風格等等。加州大學埃爾文分校的軟體研究院所做的工作則主要集中於架構風格、架構描述語言以及動態架構。
計算機軟體的歷史開始於五十年代，歷史非常短暫，而相比之下建築工程則從石器時代就開始了，人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點，一是建築風格，二是建築模式。獨特的建築風格和恰當選擇的建築模式，可以使得一個建築獨一無二。
軟體與人類的關係是架構師必須面對的核心問題，也是自從軟體進入歷史舞臺之後就出現的問題。與此類似地，自從有了建築以來，建築與人類的關係就一直是建築設計師必須面對的核心問題。英國首相丘吉爾說，我們構造建築物，然後建築物構造我們（We shape our buildings, and afterwards our buildings shape us）。英國下議院的會議廳較狹窄，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側入座。丘吉爾認為，議員們入座的時候自然會選擇與自己政見相同的人同時入座，而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。
在軟體設計界曾經有很多人認為功能是最為重要的，形式必須服從功能。與此類似地，在建築學界，現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從於功能（FORMs follows function）。
幾乎所有的軟體設計理念都可以在浩如煙海的建築學歷史中找到更為遙遠的歷史迴響。最為著名的，當然就是模式理論和XP理論。

相互關係


軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
軟體架構是指在一定的設計原則基礎上，從不同角度對組成系統的各部分進行搭配和安排，形成系統的多個結構而組成架構，它包括該系統的各個元件，元件的外部可見屬性及元件之間的相互關係。元件的外部可見屬性是指其他元件對該元件所做的假設。
從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高階設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，使用者介面風格，對外介面方法，創新的設計特性，以及高層事物的物件操作、邏輯和流程。
是一般而言，軟體系統的架構（ArchitECture）有兩個要素：
它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要資訊。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（TASk-flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。
·建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

種類


根據我們關注的角度不同，可以將架構分成三種：

邏輯架構

軟體系統中元件之間的關係，比如使用者介面，資料庫，外部系統介面，商業邏輯元件，等等。
比如下面就是筆者親身經歷過的一個軟體系統的邏輯架構圖
圖2、一個邏輯架構的例子
從上面這張圖中可以看出，此係統被劃分成三個邏輯層次，即表象層次，商業層次和資料持久層次。每一個層次都含有多個邏輯元件。比如WEB伺服器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。

物理架構

軟體元件是怎樣放到硬體上的。
比如下面這張物理架構圖描述了一個分佈於北京和上海的分散式系統的物理架構，圖中所有的元件都是物理裝置，包括網路分流器、代理伺服器、WEB伺服器、應用伺服器、報表伺服器、整合伺服器、儲存伺服器、主機等等。

系統架構

系統的非功能性特徵，如可擴充套件性、可靠性、強壯性、靈活性、效能等。
系統架構的設計要求架構師具備軟體和硬體的功能和效能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。
此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。
首先，一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴充套件性、可靠性、強壯性、靈活性、效能等做出貢獻，是非常重要的資訊。
其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。
根據作者的經驗，一個基於資料庫的系統架構，有多少個資料表，就會有多少頁的架構設計文件。比如一箇中等的資料庫應用系統通常含有一百個左右的資料表，這樣的一個系統設計通常需要有一百頁左右的架構設計文件。

檢視


我們決定以多種構架檢視來表示軟體構架。每種構架檢視針對於開發流程中的涉眾（例如終端使用者、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。
構架檢視顯示了軟體構架如何分解為構件，以及構件如何由聯結器連線來產生有用的形式 [PW92]，由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。
構架由許多不同的構架檢視來表示，這些檢視本質上是以圖形方式來摘要說明“在構架方面具有重要意義”的模型元素。在 Rational Unified Process 中，您將從一個典型的檢視集開始，該檢視集稱為“4+1 檢視模型”[KRU95]。它包括：
用例檢視：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。
邏輯檢視：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。
實施檢視：包括實施模型及其從模組到包和層的組織形式的概覽。 同時還描述了將邏輯檢視中的包和類向實施檢視中的包和模組分配的情況。它是實施模型的子集。
程式檢視：包括所涉及任務（程式和執行緒）的描述，它們的互動和配置，以及將設計物件和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該檢視。在 Rational Unified Process 中，它是設計模型的子集。
配置檢視：包括對最典型的平臺配置的各種物理節點的描述以及將任務（來自程式檢視）向物理節點分配的情況。只有在分散式系統中才需要該檢視。它是部署模型的一個子集。構架檢視記錄在軟體構架文件中。
您可以構建其他檢視來表達需要特別關注的不同方面：使用者介面檢視、安全檢視、資料檢視等等。對於簡單系統，可以省略 4+1 檢視模型中的一些檢視。

重點


雖然以上檢視可以表示系統的整體設計，但構架只同以下幾個具體方面相關：
模型的結構，即組織模式，例如分層。基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。幾個關鍵場景，它們表示了整個系統的主要控制流程。記錄模組度、可選特徵、產品線狀況的服務。
構架檢視在本質上是整體設計的抽象或簡化，它們通過捨棄具體細節來突出重要的特徵。在考慮以下方面時，這些特徵非常重要。
系統演進，即進入下一個開發週期。在產品線環境下複用構架或構架的一部分。評估補充質量，例如效能、可用性、可移植性和安全性。向團隊或分包商分配開發工作。決定是否包括市售構件。插入範圍更廣的系統。

形式


構架模式

構架模式是解決複雜構架問題的現成形式。構架框架或構架基礎設施（中介軟體）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對於特定的領域：命令和控制、MIS、控制系統等等。

模式示例

[BUS96] 根據構架模式最適用的系統的特徵將其分類，其中一個類別處理更普遍的結構問題。下表顯示了 [BUS96] 中所提供的類別和這些類別所包含的模式。
類別 模式結構 層管道和過濾器黑板分散式系統代理互動系統 模型-檢視-控制器表示-抽象-控制自適應系統反射微核
在“軟體構架簡介”中，David Garlan 和 Mary Shaw 認為軟體構架是有關如下問題的設計層次：“在計算的演算法和資料結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全域性控制結構；通訊、同步和資料訪問的協議；設計元素的功能分配；物理分佈；設計元素的組成；定標與效能；備選設計的選擇。”[GS93]
但構架不僅是結構；IEEE Working Group on Architecture 把其定義為“系統在其環境中的最高層概念”[IEEE98]。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它並不僅注重對內部的考慮，而且還在系統的使用者環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在 Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行互動。
為闡明其含義，下面將詳述其中的兩個；完整說明請參見。模式以下列廣泛使用的形式來表示：
模式名環境問題影響，描述應考慮的不同問題方面解決方案基本原理結果環境示例模式名層
環境需要進行結構分解的大系統。
問題必須處理不同抽象層次的問題的系統。例如：硬體控制問題、常見服務問題和針對於不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題（可能會不一致）。
影響
系統的某些部分應當是可替換的構件中的變化不應波動相似的責任應歸為一組構件大小 -- 複雜構件可能要進行分解解決辦法將系統分成構件組，並使構件組形成層疊結構。使上層只使用下層（決不使用上層）提供的服務。儘量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間層只新增通過構件）。
示例：
1. 通用層
嚴格的分層構架規定設計元素（類、構件、包、子系統）只能使用下層提供的服務， 服務可以包括事件處理、錯誤處理、資料庫訪問等等。 相對於記錄在底層的原始作業系統級呼叫，它包括更明顯的機制。
2. 業務系統層
上圖顯示了另一個分層示例，其中有垂直特定應用層、水平層和基礎設施層。注意：此處的目標是採用非常短的業務“煙囪”並實現各種應用程式間的通用性。 否則，就可能有多個人解決同一問題，從而導致潛在的分歧。
有關該模式的深入討論，請參見指南：分層。
模式名黑板
環境沒有解決問題的確定方法（演算法）或方法不可行的領域。例如 AI 系統、語音識別和監視系統。
問題多個問題解決顧問（知識顧問）必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問，使他們可以評估自己是否可以參與解決方案的查詢併發布其工作結果。
影響
知識顧問參與解決問題的順序不是確定的，這可能取決於問題解決策略
不同顧問的輸入（結果或部分解決方案）可能有不同的表示方式
各顧問並不直接知道對方的存在，但可以評估對方釋出的工作
解決辦法多名知識顧問都可訪問一個稱為“黑板”的共享資料庫。黑板提供監測和更新其內容的介面。控制模組/物件啟用遵循某種策略的顧問。啟用後，顧問檢視黑板，以確定它是否能參與解決問題。如果顧問決定它可以參與，控制物件就可以允許顧問將其部分（或最終）解決方案放置於黑板上。
示例：
以上顯示了使用 UML 建模的結構或靜態檢視。 它將成為引數化協作的一部分，然後會繫結到實參上對模式進行例項化。
構架風格軟體構架（或僅是構架檢視）可以具有名為構架風格的屬性，該屬性減少了可選的形式，並使構架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構件或聯結器作為基本構件來定義。對給定系統，某些樣式可作為構架描述的一部分記錄在構架風格指南（Rational Unified Process 中設計指南文件的一部分）中。樣式在構架的可理解性與完整性方面起著主要的作用。
邏輯檢視：類圖、狀態機和物件圖。程式檢視：類圖與物件圖（包括任務 - 程式與執行緒）。實施檢視：構件圖。部署檢視：配置圖。

設計


描述語言

為了討論和分析軟體構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在 Rational Unified Process 中，軟體構架文件記錄有這種描述。
架構描述語言(ADL)用於描述軟體的體系架構。已有多種架構描述語言，如Wright (由卡內基梅隆大學開發)，Acme (由卡內基梅隆大學開發)，C2 (由UCI開發)， Darwin (由倫敦帝國學院開發)。ADL的基本構成包括元件、聯結器和配置。

檢視

構架
構架檢視的圖形描述稱為構架設計圖。對於以上描述的各種檢視，設計圖由以下統一建模語言圖組成 [UML99]：
邏輯檢視：類圖、狀態圖和物件圖。
程式檢視：類圖與物件圖（包括任務 - 程式與執行緒）。
實施檢視：構件圖。
部署檢視：配置圖。
用例檢視：用例圖描述用例、主角和普通設計類；順序圖描述設計物件及其協作關係。

流程

在 Rational Unified Process 中，構架主要是分析設計工作流程的結果。當專案再次進行此工作流程時，構架將在一次又一次迭代中不斷演化、改進、精煉。由於每次迭代都包括整合和測試，所以在交付產品時，構架就相當強壯了。構架是精化階段各次迭代的重點，構架的基線通常會在此階段結束時確定。

架構師

軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。
這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程式設計師會負責一些架構方面的工作。在一個部門中，最有經驗的專案經理會負責一些架構方面的工作。
但是，越來越多的公司體會到架構工作的重要性，並且在不同的組織層次上設定專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。
[1] 

實踐


實踐中的理解
軟體架構是對軟體系統執行時元素的抽象，軟體系統可能有很多層抽象，或由多重業務流程所組成，每層抽象或每個業務流程都有自己的軟體架構。
軟體架構是平衡的藝術。

1. 軟體架構設計的What & Why

● 啥是軟體架構（Software Architecture）？

軟體架構是指在一定的設計原則基礎上，從不同角度對組成系統的各部分進行搭配和安排，形成系統的多個結構而組成架構，它包括該系統的各個元件，元件的外部可見屬性及元件之間的相互關係。元件的外部可見屬性是指其他元件對該元件所做的假設。

軟體架構設計就是從巨集觀上說明一套軟體系統的組成與特性。

軟體架構設計是一系列有層次的決策 ，比如：功能與展現的決策；技術架構的決策；自主研發還是合作；商業軟體還是開源軟體 。


● 為啥要進行軟體架構設計？

業務需求層出不窮；軟體系統越來越複雜；參與的人越來越多；共性和特殊性的問題越來越多；技術發展日異月新；……


2. 軟體架構師


2.1. 軟體架構師是幹什麼的

介於需求與開發的中間人     良好的溝通能力
能夠統領全域性的大牛 良好的大局觀
能夠將需求轉換為技術     洞悉前沿與市場嗅覺
能夠為軟體研發提供指導     見多識廣的大牛
需要全面思考軟體系統方方面面的問題     縝密地思考問題
能夠攻關和搞定重要技術難題     公司可信賴的支柱


2.2. 架構師的素質

全域性思維 

從業務、市場，到技術實現；

從軟體的過去、現在，到將來；

從外部客戶，到內部研發；

從軟體研發，到硬體部署；

從功能實現，到執行效率  

戰略思維 

在所在行業的發展戰略；

在業務領域的發展戰略；

在技術方向的發展戰略；

在潛在市場的發展戰略。

前瞻思維 

市場趨勢的發展動向；

前沿技術的發展動向；

競爭對手的發展動向；

合作伙伴的發展動向。

抽象思維 

各項業務需求：抽象成功能模組；

各項功能的實現：抽象成軟體架構。 

逆向思維

假如不實現會怎樣？

假如沒搞定會怎樣？

假如沒有它會怎樣？

假如被延期會怎樣？


2.3.  架構師的分類

隨著行業和社會的發展，架構師的定義和分類越來越廣泛和細分，廣泛和細分其實並不矛盾，如果“廣泛”是x軸，“細分”是y軸，則二維座標系x和y軸中間的任一點就是一種架構師類別。但總體來說，或目前來說，集合業界的大致認知，總結如下：

No. 分類 描述
1 解決方案架構師 與客戶探討業務需求，將業務、市場，與技術、產品結合起來，為客戶提供解決他們需求的方案。
2 系統架構師 也稱應用架構師。最終確認和評估系統需求，並將業務轉換為技術，為研發人員制訂核心框架與技術規範 為研發工作澄清技術細節並掃清技術障礙 。
3 平臺架構師 這裡的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另外一個其實是基礎平臺，是專門負責搭建基礎技術平臺；兩者其 實區別蠻大，也經常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，但是金蝶BOSS應用和金蝶中介軟體兩者招聘的物件和技術要求是截然不同的。
4 業務架構師 業務架構其實已經開始脫離技術層面了，但是它要求架構師有跨越多系統的大局觀，去整合和組織不同系統的技術平臺與互動模式。其實這個職位的未來也就是CIO了。
5 網路架構師 過去，我們可能聽的最多的是網路工程師。不錯，一個優秀的網路架構師必須有足夠的網路技術基底，並且它的關注點也是系統的基礎架構。比如說如果搭建並優化叢集環境，如果構建基於雲端計算的系統應用與部署等等。它對於像淘寶、騰訊這樣的網際網路公司是極其重要的。
6 移動架構師 移動網際網路的迅猛發展橫向和縱向都細分出了很多新的職責和崗位，移動架構師的職責和作用日益重要，既要整體和全域性考慮整個前後端的軟體系統架構，又要重點深入移動客戶端的架構設計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發的尺度，另外移動應用的特點，導致移動架構師必須要比傳統系統架構師更加註重非功能性的質量屬性。
7 前端架構師 這也是移動網際網路的迅猛發展而細分出來的新的職責和崗位，這裡的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。
8 ... ...


3.  軟體需求

軟體架構設計中常說需求驅動架構設計，可見需求在整個架構設計中起到了關鍵指引和方向的作用，如果以目標導向為原則，則需求的滿足和實現就是架構設計的終極目標。
OK，在進行架構設計之前，我們先看下軟體需求。

3.1.  軟體需求怎麼來的（軟體需求的過程）

階段

需求階段

說明

什麼人做什麼事

可能產生的文件

客戶方

實施方

客戶方

實施方

1

業務需求

來自客戶的原始需求，背景描述，業務訴求和期望目標。

專案負責人或介面人描述需求或提供客戶方需求文件。

銷售或售前接觸客戶，聽取和記錄需求。

工作說明書（SOW），或邀標書

售前的方案建議書

2

使用者需求

通常是在問題定義的基礎上進行使用者訪談、調查，對使用者使用的場景進行整理，從而建立從使用者角度的需求。

專案負責人或介面人接受訪談和調研。

需求分析師或專案經理等進行需求調研。

 

調研計劃、使用者需求調研提問庫、調研日誌、使用者需求說明書

3

軟體需求

從系統實現的角度描述的需求。開發人員（設計和分析人員）在業務需求、使用者需求的基礎上形成的。

 

需求分析師或專案經理、架構師等討論和細化需求，編寫需求文件

 

SRS（Software Requirement Specification）軟體需求規格說明書

3.2.  軟體需求的分類：

另外，也有McCall軟體質量模型：

注：在架構設計中，對非功能性需求的重視程度，也會影響架構設計的好與劣；但也要平衡過渡設計和適可而止的關係。


4.  軟體架構的過程

業界軟體架構設計的方法論很多，各有各自的應用場景和特點，下文結合ADMEMS（Architecture Design Method has been Extended to Method System）架構設計方法論說明軟體架構的過程：

架構階段

目標

方式方法

現實工作場景

預架構階段

全面理解需求；需求結構化，摒棄“需求列表”，建立二維需求觀（ADMEMS矩陣）。

使用ADMEMS矩陣方法，捋清需求間關係和發現衍生需求。

1、與人：與專案經理、需求分析師等內部需求人員瞭解需求；與客戶瞭解需求（不建議架構師做需求分析師角色）。
2、與物：瞭解《需求規格說明書》等需求文件。"
3、對需求有什麼問題，反饋給售前或銷售，可能會參與拜訪客戶或電話會議。
4、銷售或售前有時會要求提供一個大致的工作量，以便他們初步評估專案可行性。

概念架構

高層元件及其關係

1、初步設計，基於關鍵功能，藉助魯棒圖進行以發現職責為目的的初步設計（不是必須）。
2、高層分割，將複雜系統切分為多個二級系統或多個子系統。
3、考慮非功能需求，採用ADMEMS推薦的目標-場景-決策表。

1、參與內部討論：專案可行性分析、討論，從需求、技術、人力、風險等角度提供建議。
2、專案投標準備：參與投標團隊的技術方案編寫，編寫系統架構章節，解決招標書上技術問題的問答。
3、參與專案講標：作為講標團隊成員參與專案講標，負責技術問答環節的應對。

細化架構

 

5檢視法

在專案概要設計階段，進行架構設計，制定規範和約定，為詳細設計提供指導。

實現

詳細設計
編碼實現

架構設計形成詳細設計文件

在專案實現階段，對開發人員提供規範指引和技術支援。

注：架構設計的過程和內容的不是固定不變的，現實中，比如售前提供解決方案中，很多時候需要架構師提供細化架構中才會深思的邏輯架構、物理架構等，這時候，架構師就需要有螺旋思維和跳躍思維的方式，就像武功中，招式是死的，人是活的，要學會靈活運用。


5.  軟體架構設計的方式方法


5.1.  多檢視法


多檢視方法是業界廣泛認同的一種架構設計思路，包括：
● SEI的3檢視法：
模組檢視、元件-聯結器檢視、分配檢視。
● 西門子的4檢視法：
概念檢視、模組檢視、程式碼檢視、執行檢視。
● RUP的4+1檢視法：
用例檢視、邏輯檢視、開發檢視、程式檢視、物理檢視。
● 聯邦企業架構框架：
技術架構檢視、資訊架構檢視、應用架構檢視、業務架構檢視。
● ……

5.2.  5檢視法


5檢視法分析的意義：

● 全面分析軟體系統方方面面的問題
● 儘早地發現和排除專案風險與不確定因素
● 從不同角度去展現要設計的軟體系統
● 為專案進行中不同的干係人提供指導：
    -- 邏輯架構描述系統功能，並指導系統測試
    -- 開發架構規範軟體的層次及程式碼風格
    -- 資料架構指導資料庫的設計
    -- 執行架構定義了一些關鍵過程的設計
    -- 物理架構明確軟體如何部署與實施

5.3.  5檢視法設計步驟

兩種觀念：

觀念

設計步驟

觀念一

順序進行：

1、邏輯架構。

2、開發架構

3、資料架構

4、執行架構

5、物理架構

觀念二

5個檢視是穿插進行設計的，對複雜系統而言，根本不可能將邏輯檢視設計完了後再考慮其它檢視。

筆者觀念

觀念一和觀念二的情況在現實狀況中都可能存在，要根據具體情況具體分析，但總體而言，5檢視穿插進行思考更有利於思考的全域性性和完整性。

5.4.  如何進行5檢視法的設計

以下5檢視表格中的工具和方法每個架構師或略有差異，以下僅為參考。

5.4.1.  邏輯架構

邏輯架構的重點是考慮軟體功能性需求。

No.

考慮的方面

產出物

工具

說明

1

系統功能劃分為幾個子系統與功能模組？

系統功能樹

樹型結構圖

 

2

向什麼使用者提供什麼樣的功能？

用例模型

UML用例圖

體現使用者和行為

3

每個功能都是怎樣的操作流程與分支？

用例描述

用例描述表

 

含輸入輸出、事件流分析；

不要有介面描述

UML活動圖

進行業務流程分析，包括泳道圖

4

如何通過介面與使用者互動？怎樣互動？

魯棒分析

魯棒圖

通過對“用例描述表”進行原文分析法揀出名詞和動詞

5

應當設計哪些類與介面？怎樣設計？

領域模型

UML類圖

 

6

與哪些外部系統介面？怎樣介面？

介面描述

UML類圖

 

5.4.2.  開發架構

開發架構重點關注的是開發編碼實現方面的問題。

No.

考慮的方面

產出物

工具

說明

1

分層結構設計

分層架構圖（開發架構圖）

各種繪圖工具

好的分層結構支援自動化測試

2

開發技術選項

開發語言

開發框架

開發工具

 

考慮商用產品、開源框架、自研框架

3

模組劃分

原始碼工程；Project目錄結構；

分包(分庫)

 

 

4

開發規範

開發/編碼規範文件；

 

 

5

軟體質量屬性

分析和決策結果

 

考慮執行期和開發期軟體質量屬性，並權衡利弊進行決策。

5.4.3.  資料架構

資料架構不僅僅要考慮開發中涉及到的資料庫，實體模型，也要考慮物理架構中資料儲存的設計。

No.

考慮的方面

產出物

工具

說明

1

資料是集中還是分佈儲存的？如何考慮分散式儲存？

資料架構圖

 

 

2

領域模型到資料庫表的轉換？表結構關係的設計？

邏輯模型

物理模型

ER圖

Power Designer

Visio

 

3

實體如何設計？充血模型和貧血模型？

UML類圖

 

 

4

使用什麼資料庫？關係型還是非關係型？

選型結果

 

 

關係型資料庫

非關係型資料庫（NoSQL）

Oracle（首次發行：1980年）

MySQL（首次發行：1995）

MS SQL Server（首次發行：1989）

PostgreSQL（首次發行：1989）

IBM DB2（首次發行：1983）

Microsoft Access（首次發行：1992）

Sybase ASE（首次發行：1987）

SQLite（首次發行：2000）

…… 

MongoDB（首次發行：2009）

Cassandra（首次發行：2008）

Apache CouchDB

Hbase

Redis

db4o

BaseX

…… 

5.4.4.  執行架構

執行架構關注的不再是全域性而是區域性，著重關注那些關鍵點與難點，常常需要技術攻關與預研。主要考慮控制流、通訊機制、資源爭用、鎖機制、同步非同步、併發、序列，同時也要考慮質量屬性。

No.

考慮的方面

產出物

工具

說明

1

執行：同步vs.非同步；併發vs.序列

考慮開發架構中程式碼的實現。

 

 

2

互動：物件間互動；狀態轉換

考慮開發架構的合理性，到類、到介面、到程式碼。

 

 

3

質量：安全；可靠；可伸縮

考慮開發架構的合理性

 

 

4

效能：響應時間；吞吐量

估算：

線上人數、併發人數；

每秒事務量；

響應時間。

 

 

5.4.5.  物理架構

物理架構主要考慮硬體選擇和拓撲結構，軟體到硬體的對映，軟硬體的相互影響。

 

考慮的方面

產出物

工具

說明

1

網路方面：網路拓撲；網路裝置；安全機制

拓撲圖

安全規範

 

 

2

效能方面：可靠性、可伸縮性

需要什麼樣裝置效能

 

 

3

部署方面：集中式還是分散式；元件部署

部署圖

 

 

 

6.  一個思考，誰驅動了架構設計？

需求驅動了架構設計？

質量屬性了驅動了架構設計（ADD）？

領域驅動了架構設計（DDD）？

風險驅動了架構設計？

質疑驅動了架構設計？

……

到底是誰驅動了架構設計？我們以船舶設計建造為例，來看這些問題：

目標和結果 à

問題 à

回答 à

小結

設計和製造一艘遠洋貨輪，能經歷數月海上顛簸和長途跋涉，並保證貨物的安全和完整，最後能順利抵達目標港口。

我們為什麼要設計和製造這樣的大船？

市場有這個需求；

獲利很豐厚；

解決就業；

……

不管是外部需求還是內部的需求，都是需求。不正是需求驅動嗎？

如何保證貨船能長途航行並經受波濤和風雨？

船要造的結實；

魯棒性

這些不正是質量屬性驅動設計嗎？

引擎設計的強勁；

效能

船的燃料充足；

持續可用性

裝備衛星電話、GPS、雷達等裝置

互操作性

貨物和人員要安全

安全性

船舶設計師怎麼設計這樣的船舶？

現在都會通過計算機進行船舶的CAD和3D模型設計。

是不是佷似領域模型驅動了設計？

造船一定有很多風險吧？

那是，比如訂貨方客戶有時提出改裝船舶的意見（需求變化的風險）；有時某些工藝成品率不穩定（質量風險）；等等。

所有可能的風險點在設計時都要考慮到，做好預案，才能保證架構設計的可行性和靈活性，風險驅動了架構設計。

上面怎麼提了那麼多問題，其實還有很多問題，比如……

嗯，你現在有不少疑問了。

不斷的質疑架構設計中可能存在各種問題，有質疑才有思考，才有解決方案，從而推動架構設計的不斷完善。

總結：

以上幾個方面都能驅動架構設計，並不是零和的規則，而是一個立方體從不同方向看的問題。以上方面有些是指導思想，有些是行動方式，有的兼而有之，闡述方式看似不同，終極目標還是造出大船（實現需求），造出好船（質量屬性），怎麼造（領域模型），造的順利（風險控制），挑不出毛病（架構師自己先質疑問題並解決了）。


7.  軟體架構設計的誤區

● 高開高走落不到實處

● 理想與現實需要折中

● 遺漏關鍵性約束與非功能需求

● 為虛無的未來埋單而過度設計

● 過早做出關鍵性決策

● 客戶說啥就是啥成為醬油哥

● 埋頭幹活兒缺乏前瞻性

● 架構設計還要考慮系統可測性

● 架構設計不要企圖一步到位

對比延伸：怎麼區別軟體架構、系統架構、解決方案架構、企業架構？ - https://www.zhihu.com/question/20308367
參考文獻：《一線架構師實踐指南》&《軟體架構十個技巧及成功團隊具備的氣質》

相關文章