業務分析與設計的方法

現在，用戶的需求越來越複雜，變化也越來越快，如果仍然通過需求管理、需求跟蹤等管理方式來約束和減少頻繁變更需求對軟件開發帶來的衝擊，則會導致軟件開發流程變得僵硬，程序員更加疲憊。

另外，用戶的需求通常來自某個專業領域，比如法律、財務或電子商務等，每個特定的需求又有其特別複雜之處，所以幾乎沒有人能夠第一時間抓住這些專業領域的需求本質。因此，用戶的需求在歷經幾次演變之後變得面目全非，每一個“加工製造環節”都認為自己在做“正確的事”。在現實工作中，這樣的局面一再上演，比如，產品經理在宣講產品需求文檔（Product Requirement Document，PRD）時，需要將專業名詞使用通俗的業務語言“翻譯”給業務人員，還要使用技術語言“翻譯”給開發人員，這就很容易導致各方得到的信息不對等，業務人員的理解和技術人員的理解可能不一致。

因此，聰明的工程師們引入了靈活多變的面向對象分析與設計（OOAD）方法。面向對象分析與設計方法對複雜需求的解決方法是：讓建模專家進行需求分析，並在需求和需求之間建立關係。

注意：面向對象分析與設計被拆分為系統分析和系統設計兩部分，還專門有“系統分析師”和“系統設計師”兩種職稱考試。這樣拆分的結果就是對需求分析的結果無法直接進行設計和編程，而能夠運行的代碼不匹配需求，導致客戶在運行軟件後才發現很多功能不是自己想要的，而且軟件不能快速跟上需求的變化。

雖然面向對象分析與設計的思想帶給分析與設計很大的靈活性，也對軟件開發產生了前所未有的影響，但有一定的局限性：面向對象分析與設計主要關注微觀層次的抽象，比如類和對象實例等；對每個問題域通常都需要創建單獨的用例分析模型，項目或產品的大方向在許多情況下變得很模糊，很難全局把控系統的總目標，所以這樣的系統分析與設計方式存在很大的風險。

面向對象分析與設計的局限性，催生了面向服務分析與設計（SOAD）方法，它有效地彌補了面向對象分析與設計的局限性。同時，面向服務的架構（Service-Oriented Architecture，SOA）也走進了大眾的視野並很快流行起來。

面向服務分析與設計並不是一種全新的分析與設計方式，只不過是從不同的抽象角度去設計一種業務模型。面向對象分析與設計可以說是一種自底向頂的設計方式，雖然面向對象的方法比起面向過程的方法有了很大的改進，但是在面對複雜的市場需求時，面向對象分析與設計就顯得捉襟見肘了，此時就需要從更高的層次分解市場需求，面向服務分析與設計應運而生。在做面向服務分析與設計時會採用自頂向底的設計方法，首先要分離出業務流程和服務，然後細化對象。面向對象分析與設計與面向服務分析與設計的抽象關係如圖3.16所示。

圖3.16

那麼，面向服務分析與設計就是最好的了嗎？它又有什麼局限性呢？

眾所周知，軟件開發的流程通常為需求、分析、設計、開發、測試和交付。不管是在面向對象分析與設計中還是在面向服務分析與設計中，對系統分析和設計都是分開的、割裂的，即分析人員從領域中收集基本的業務概念，系統設計人員再將基本的業務概念映射為相應的編程工具的構造組件。在這個過程中，由於分析模型和設計模型不同，在分析和設計之間形成一條鴻溝，如圖3.17所示。

圖3.17

2004 年，著名建模專家 Eric Evans 出版了其最具影響力的著名書籍 Domain Driven-Design architecture，其中提出的領域驅動設計（DDD）方法打破了分析和設計割裂的狀態，並給出了領域模型的概念，拋棄了將分析與設計分開的做法，使用統一的模型來滿足分析與設計的需求，使系統開發能夠更加靈活、快速地響應需求的變化。

注意：DevOps 的出現又進一步填平了開發和部署之間的鴻溝，值得注意的是，任何新技術或概念都不是人們憑空想象出來的，都是為了解決人們在生活和工作中遇到的問題。架構師也需要具備發現系統中的問題並給出相應解決方案的能力。

系統分析與設計的三個發展階段

下面講講系統分析與設計的三個發展階段。

面向數據驅動分析與設計

面向數據驅動分析與設計可以說是系統分析與設計的第一階段。

軟件設計總是從設計數據庫及其字段開始的，這一階段的特徵就是圍繞數據庫編程，應用系統是典型的兩層架構，分為展示層和數據庫層。該階段的典型技術為Delphi和VB等，如圖3.18所示。

圖3.18

這種面向數據驅動分析與設計的方法導致了過程化的編程思維，因為數據庫結構由DBA設計後交由程序員編寫大量的SQL語句實現，而SQL語句執行是有先後順序的，所以程序員大多形成了面向過程的思維方式，長此以往形成了習慣就難以改變。

面向過程（Procedure Oriented）是一種思維方式，在面對一個問題時，我們通常先關註解決這個問題的步驟，即過程。比如對於如何將大象裝入冰箱這個問題，我們想到的步驟是：第1步，打開冰箱；第2步，裝入大象；第3步，關上冰箱。這就是典型的面向過程的思維方式，雖然這樣可以更加直接、有效地解決問題，但是面對更複雜的問題時，解決問題的過程會變得非常複雜和難以理解。

同樣，面向數據驅動分析與設計有以下明顯缺點。

◎ 不能迅速、有效、全面地認識和反映需求，在這種分析與設計思維中，世界不僅由簡單的關係數據組成，還使用關係數據庫反映現實需求，這不符合人類的自然思維，是一種扭曲的分析方法。

◎ 系統的性能很難提升，容易導致軟件運行時的負載集中在數據庫端，使系統變成集中式和高風險的大型單體模式（Monolithic），喪失分布式集群處理能力。

◎ 面向對象的編程語言和關係型數據庫本身是矛盾的，因為關係型數據庫分析與設計本身是面向過程的（這一矛盾在當今的實現中依然存在，不過在領域驅動設計中已有解決方案）。

面向對象和服務分析與設計

隨着系統的複雜度越來越高，面向數據驅動分析與設計所存在問題也越來越明顯，因此產生了具有劃時代意義的面向對象和服務分析與設計的方法，應用系統也變成了經典的三層架構：展示層、業務邏輯層和數據訪問層，如圖3.19所示。

圖3.19

此時出現獨立進行分析與設計的兩個階段，系統分析與設計開始上升到一個更高的層次，擁有自己的一套科學且藝術的方法論，但也帶來了一個致命的缺點：分析階段和設計階段不能很好地銜接，出現了難以逾越的鴻溝，因為分析人員負責從需求領域中收集基本概念，而設計人員負責指明一組能在項目中適應編程工具構造的組件，這些組件必須能夠在目標環境下有效執行，並能夠正確解決應用程序出現的問題。

可以看到，分析階段和設計階段的目標並不一致：分析人員只關注需求分析，並不關注是否適合設計或者能否導出適合設計的分析結果；設計人員發現分析結果過於簡單，無法進行編碼實現。於是，分析階段和設計階段無法對接，導致整個項目無法順利進行，以失敗告終。

另外，在分析階段和設計階段雖然都使用了UML，但是UML不是思想方法，只是一種分析與設計工具。假若將UML類比為CAD繪圖軟件，那麼會CAD的繪圖員就是建築師嗎？顯然不是。所以，UML不是銀彈，更不等價於分析與設計方法。

面向問題域分析與設計

問題域模型有一個流行的名字：領域模型，是對現實世界或領域中的對象的可視化表示，可分為概念模型、領域對象模型和分析對象模型。

Eric Evans 在 2004 年 發 表 了 Domain-Driven Design-TacklingComplexity in the Heart of Software的論文，主題便是領域驅動設計，還提出領域模型的分層架構，將整個系統劃分為基礎設施層、領域層、應用層和用戶接口層，如圖3.20所示。

圖3.20

領域建模是一種藝術，融合了分析階段和設計階段，目的是使複雜的軟件快速應付變化。領域模型同時適用於分析原型和程序設計，如果一個模型在實現時不具備可行性，就需要重新尋找新的模型，如果該模型沒有忠實表達領域的關鍵概念，則也必須重新尋找新的模型。所以，領域建模的過程把分析階段和設計階段變成了單個循環階段，把分析與設計緊密聯繫起來，使領域建模專家不再只關注需求概念的收集，也關注程序代碼的設計與實現。3.5～3.7節將介紹面向對象分析與設計、面向服務分析與設計和領域驅動設計的詳細用法。