需求分析師在需求調研分析工作中經常會用到各種分析方法，但對各種建模方法沒有體系化的認識，經常講概念混淆。本文從常用的結構化分析方法和麪向對象分析方法着手，對各種建模方法進行梳理，幫助理解其含義及作用。
1. 建模概述
1.1. 什麼是建模？
建模就是採用表格化、圖形化、公式化的方式，將系統的構成及其構成間的關係呈現給人們的一種技術方法。[1]可能是因爲軟件本身的不可見，使得軟件的建模也顯得抽象，但在平常生活中，建模隨處可見，比如蓋房子，需要畫圖紙，畫圖紙就是建模的過程，而圖紙就是建模產出的模型。在樓盤預售時，房子都還沒建好，地產商會先做個縮小版的原型出來，甚至做個樣板房讓顧客有直觀的感受，這個也是建模。當房子賣出去了，屋主需要裝修了，找裝修公司設計，設計師根據屋主需要設計一套圖紙，甚至細到水電的走線，這些也是建模。因此將開發軟件比作蓋房子，其建模過程就相當於繪製圖紙的過程。
可以說對軟件系統進行建模的目的是幫助我們按照實際情況或按我們需求的樣式對系統進行可視化；提供一種詳細說明系統的結構或行爲的方法；給出一個知道系統構造的模板；對我們所作出的決策進行文檔化。[2]
1.2 建模演變歷程
軟件建模並不是從來就有的，而是隨着軟件工程的發展而不斷演變。主要經過了三個階段。
第一階段：程序=數據結構+算法
出現於20世紀50~60年代，軟件開發主要解決的是科學計算問題，Fortran語言是其代表。其建模關鍵點是選擇合適的數據結構和算法。
第二階段：結構化分析方法
出現於20世紀60~70年代，將解決一些與數據處理相關的問題，例如計費等。COBOL、C語言是其代表。其建模關鍵點有兩方面，一是確定有哪些數據，格式是什麼，如何存儲，主要通過E/R模型表達；二是確定數據的加工、處理過程，主要通過DFD（數據流圖）表達。
第三階段：面向對象分析方法
出現於20世紀80~90年代，信息系統覆蓋了更多業務過程，數據不再是唯一的視角，事（業務流程）、人的視角越來越重要，因此加入更多這方面的建模工具。[2]
目前結構化分析方法和麪向對象分析方法仍廣泛應用。
2. 結構化分析方法
結構化分析方法（Structured Analysis，簡稱SA）是將待解決的問題看做一個系統，從而用系統科學的思想方法（抽象、分解、模塊化）來分析和解決問題，並基於功能分解設計系統結構，通過不斷把複雜的處理逐層分解來簡化問題，其最核心思想是自頂向下的分解。
結構化分析方法模型如下圖所示：
● 數據字典是模型的核心，是關於數據的信息集合，也就是對數據流圖中包含的所有元素定義的集合。對於數據流圖中出現的所有被命名的圖形元素加以定義，使得每個圖形元素的名字都有確切的解釋。
● 實體關係圖（ER圖）：描述數據對象間的關係，用於數據建模。
● 數據流圖（DFD圖）：描述了數據流在系統中流動的過程，以及對數據流進行變換的功能，用於功能建模。
● 狀態遷移圖（STD圖）：描述了對外部事件的響應方式，表示了系統的各種行爲模式（稱爲狀態）以及在狀態間進行變遷的方式，用於行爲建模。
可見，結構化分析方法包含3層建模，數據建模、功能建模以及行爲建模。
2.1 數據建模——ER圖
數據模型是爲了把用戶的數據要求清晰明確地表達出來所建立的一個概念性的模型，也稱爲概念模型，因此數據建模也稱爲概念建模。概念性模型是一種面向問題的數據模型，是按照用戶的觀點來對數據和信息進行建模。它描述了從用戶角度看到的數據，也反映了用戶的現實環境。
數據建模的目標是爲了明確下列與數據處理相關的特定問題：
● 系統處理哪些主要的數據對象？
● 每個數據對象的組成如何？
● 哪些屬性描述了這些數據對象？
● 這些數據對象當前位於何處？
● 數據對象之間的關係？
● 數據對象和變換它們的處理之間有哪些關係？
數據模型常用ER圖表示，ER圖也稱實體關係圖(Entity Relationship Diagram)，提供了表示實體類型、屬性和聯繫的方法。用矩形表示實體型，矩形框內寫明實體名；用橢圓表示實體的屬性，並用無向邊將其與相應的實體型連接起來；用菱形表示實體型之間的聯繫，在菱形框內寫明聯繫名，並用無向邊分別與有關實體型連接起來，同時在無向邊旁標上聯繫的類型（1:1,1:n或m:n）。ER圖示例如下圖所示，具體繪製方法不做詳細說明。
另外，對於設計方面的數據建模包括概念建模、邏輯建模和物理建模，而需求分析中的數據建模相當於設計中第一階段的概念建模。由於是設計方面的建模方法，這裏不再說明，詳細信息可網上查找“詳解數據建模的三個階段”。
2.2 功能建模——DFD圖
當數據或信息“流”過信息系統時將會被系統的功能所處理、加工活變換，再將處理或變換後的數據從系統中輸出，DFD圖從數據傳遞和加工角度，以圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程。而功能建模正是通過DFD圖將系統所需實現的功能繪製出來的過程。
DFD圖的基本組成包括數據流、加工、數據存儲和外部實體。通常用箭頭標誌數據流，用圓或橢圓表示加工，用雙槓表示數據存儲，用方框表示外部實體，即數據的源點或終點。DFD圖示例如下圖所示。
2.3 行爲建模——STD圖
STD圖（State Transition Diagram）用於描述系統或對象的狀態，以及導致系統或對象狀態發生改變的事件，從而描述系統的行爲。它指明瞭作爲特定事件的結果（狀態），在狀態中包含可能執行的行爲。
STD圖中，用圓圈表示可得到的系統狀態，用箭頭表示從一種狀態向另一種狀態的遷移，在箭頭上要寫上導致遷移的信號或事件的名稱。STD圖示例如下圖所示。
3 面向對象分析方法
面向對象方法是從內部結構上模擬客觀世界 ,其基本思想認爲對象是對現實世界客觀實體的描述 ,均由其屬性和相關操作組成 ,是系統描述的基本單位。面向對象方法更強調運用人類在日常的邏輯思維中經常採用的思想方法和原則 ,例如抽象、分類、繼承、聚合、封裝等 ,這使得軟件開發者能更有效地思考問題 ,並以其他人也能看得懂的方式把自己的認識表達出來。
面向對象方法包括面向對象需求分析（OOA）、面向對象設計（OOD）、面向對象編程（OOP）。而面向對象分析方法主要經過3個建模過程，包括結構建模、行爲建模和功能建模，3中建模均採用統一建模語言 UML (Unified Modeling Language)。
根據UML2.0標準，一共定義了13種不同的圖，其功能各有不同，而OOA主要使用到其中的5種，分別是類圖、活動圖、用例圖、構件圖和部署圖。
3.1 結構建模
結構建模也叫領域建模或概念建模，是對業務或系統的某個時刻或某段時間內的狀態進行系統化描述，一般使用結構型的UML圖進行結構建模。結構建模所表示的內容一般是靜態的，在一段時間內是不會變化的。如用類圖表示業務及業務之間的關係，用部署圖、構件圖表示系統的部署及架構設計。
類圖示例如下圖所示：
構件圖如下圖所示：
部署圖如下圖所示：
3.2 行爲建模
行爲建模是系統化地分析業務活動及業務流程的過程，一般使用行爲型的UML圖進行結構建模。行爲建模表達的是某段時間內事情是如何發展的，這些發展最後會達到怎樣的效果。
業務流程分爲生產性流程、管理性流程和支持性流程。生產性流程是流程中最重要的部分，是企業/組織價值體現的核心；管理性流程是對生產性流程的管控，通常是有管理層發現的，對一些質量、效率進行監督的控制性流程；支持性流程是對生產性流程的一種補充，通常是由協作部門、本部門員工執行的工作。如果拿軟件開發過程來比喻的話，需求分析、軟件設計、軟件編碼、軟件測試是生產性流程；項目管理、質量保證是管理性流程；而文檔配置等屬於支持性流程。通常生產性流程是最容易標識的，而管理性流程和支持性流程比較容易忽略，因此在需求分析時要特別注意。[2]
活動圖示例如下圖所示：
3.3 功能建模
功能建模是在結構建模和行爲建模的基礎上，識別出通過系統實現的部分，一般使用UML用例圖表現，描述系統應具有的功能，用於實現用戶的日常需要。
另外，在用例圖的基礎上通過原型工具製作出可視化原型也屬於功能建模的範疇，通過原型用戶能更直觀地感知即將開發出來的系統的模樣，更好地引出客戶需求，同時避免後期需求變更。目前一般採用Axure原型工具製作系統或功能原型。
用例圖示例如下圖所示：
4 結束語
可以看出結構化分析方法和麪向對象分析方法有相同的地方，那就是都需要先理清業務概念及其關係，雖然SA稱爲數據建模，而OOA稱爲結構建模，但本質是相同的。不同的地方在於SA更偏向對數據流的分析，而OOA更偏向對對象行爲的分析，而且在現階段OOA的應用更爲廣泛，但不得不說的是，無論SA還是OOA都只是需求分析的方法，關鍵還是在於使用它們的需求分析師。
參考文獻：
[1]軟件需求十步走 新一代軟件需求工程實踐指南_楊巨龍，周永利編著_北京：電子工業出版社
[2]軟件需求最佳實踐：SERU過程框架原理與應用