自頂而下的軟件架構分析

 

 

1.   前言

    本身在工做當中常常會遇到須要快速而且完整地瞭解一個軟件系統的事情。原本想寫一寫如何快速瞭解一個系統，但想着想着就想到了軟件的架構。本文以一個軟件業務分析師的視角闡述本人理解的軟件架構。目的是提供一個適用的，易用的方法，幫助業務分析師或軟件架構師系統地，快速的分析和了解軟件系統。若有技術性錯誤，還請各位大牛指正。

2.   軟件架構理解

    首先來了解一下什麼是架構，架構就是爲了組織部件和資源，讓部件及資源發揮單體所沒法發揮的做用，從而實現架構所要達到的戰略目標。（有點相似於一個組織存在的目的，說明世界上許多知識都是通用的，只是應用的場景不一樣）不一樣的架構本質和目的都同樣，甚至架構方法的思想來源都同樣，只是所被組織的部件和資源不同，從而牽引出不一樣的架構形式。例如企業架構就是爲了將企業的人，財，物，流程進行整合，並用IT來實現整合目標，一個軟件的架構也相似，就是將數據，功能，網絡，流程整合，實現軟件的價值。而整合的方法多種多樣，不一樣的方法達到的效果也有差別。架構的目的就是研究如何去整合，協調這些資源，爲品質高的系統奠基基礎。

3.   自頂而下與自底而上

    這裏想說說我爲何推薦自頂而下的分析方法而不推薦自底而上的分析方法。首先解釋一下什麼叫自頂而下，簡單說就是從大到小，從粗到細，例如企業預算的制定：從公司到部門再科室再到成本中心。軟件的自頂而下就是從業務到功能到數據，再到基礎架構。自底而上就是反過來。那麼我爲何推薦自頂而下呢，緣由以下：

1. 從業務的角度（原諒我是個業務分析師吧），一款軟件存在的價值就是業務須要，必須先了解軟件或系統的目標是什麼，才能作進一步分析。
2. 軟件的開發與實施是爲了業務服務，雖然咱們在分析軟件的時候要考慮到技術的侷限性，但應當最大限度地知足業務需求。若是採用自底而上分析，就是在暗中埋下許多技術限制，違背軟件存在的初衷。

4.   自頂而下分析步驟

Step1：戰略及業務

    要想了解一個系統或分析一個系統，首先最重要的就是要了解這個系統存在的價值，是爲了提升客戶滿意度，爲了增長企業利潤，仍是市場發展須要，或是老闆睡了一覺，拍拍腦殼想出一個點子。這決定了這個系統或軟件在企業當中的地位以及高層對這個系統的支持程度。瞭解系統存在的價值及系統實現的目標，能夠幫助架構師把握核心問題，不在之後的分析過程中走彎路。雖然這些看似很虛無飄渺，對系統的開發沒有實質性的幫助，但倒是一個合格的分析師不得不首要考慮的事情。

Step2：系統級分析

    這一步咱們將整個系統做爲個體看待。主要是分析這個系統與現有系統之間的依賴關係，會不會對其它系統產生影響。這樣也能夠初步分析出系統可能會涉及到的外部接口。另外在這一步也要定義出主要的系統功能，沒必要要太細，但不能遺漏主要功能。

Step3：功能分析

    這一步須要分析的內容是最多的，主要包括功能性需求，非功能性需求。功能性需求裏分主要業務功能和數據分析及運營要求。功能性需求能夠是一個模塊實現，也能夠是單一的功能點實現。識別出功能塊後，要分析功能的完備性和功能之間的聯繫。如基礎的用戶管理，權限管理，物流及銷售的訂單管理，倉儲的物料管理，財務的記帳等。

數據分析及運營要求包括基礎數據維護，運營數據的報表及分析。

非功能性需求指的是保證功能的正確性，支持功能更好地發揮做用的需求。包括常見的安全性，易用性，災備，也包括一些系統獨有的如跨域，單點登陸等具體問題。

Step4：數據架構

    分析完功能性需求後，就須要着手設計數據庫表結構。做爲業務分析師，我認爲只要能識別及設計出對業務有主要做用的表結構，包括每一個字段的含義及做用。分析各表之間的關係便可。固然，數據庫表設計是一門專業的知識，要想作得好還得深刻研究。這一步的工做與Step3可同時並行。

Step5：基礎架構

    基礎架構即系統運行的環境，包括網絡，服務器和數據庫系統。通常公司裏基本都有一個固定的架構，經常使用的系統在此基礎上就能夠完成開發。基礎架構是軟件運行的基礎，卻也經常會成爲系統技術的瓶頸。分析及瞭解這些的主要做用就是對系統環境有個大概的瞭解，避免給客戶承諾一些根本實現不了的功能。

5.   總結

    以上內容只給出簡單描述，不涉及具體的技術分析，詳細技術請參考其它資料，雖然內容比較多，但若是可以理清楚，有條理，有針對性地去分析，便可以快速瞭解一個系統。也可以有目的地去分析還未實現的系統。但願本文能夠幫助到系統分析師們。

 

 

2015年5月8日星期五