如何進行系統(tǒng)分析與設(shè)計-創(chuàng)新互聯(lián)

概述

創(chuàng)新互聯(lián)服務(wù)項目包括卓尼網(wǎng)站建設(shè)、卓尼網(wǎng)站制作、卓尼網(wǎng)頁制作以及卓尼網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，卓尼網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到卓尼省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

首先，系統(tǒng)是什么？根據(jù)《系統(tǒng)架構(gòu)》一書的定義，系統(tǒng)是由一組實體和這些實體之間的關(guān)系所構(gòu)成的集合，其功能要大于這些實體各自的功能之和。對于我們的場景，系統(tǒng)可能是 App、Web 應用、服務(wù)、批處理程序等，也可能是包括所有這些的一個大系統(tǒng)。

隨著互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)的結(jié)合越來越深入，業(yè)務(wù)會越來越復雜。我們該如何設(shè)計我們的系統(tǒng)呢？

從產(chǎn)品到研發(fā)

從產(chǎn)品作出原型，到研發(fā)編程實現(xiàn)，中間有巨大的鴻溝。越復雜的業(yè)務(wù)需求，這條鴻溝就越大。一般而言，我們至少還要有兩個步驟：業(yè)務(wù)分析與架構(gòu)設(shè)計。

業(yè)務(wù)分析，主要處理的是業(yè)務(wù)領(lǐng)域的建模。解決的問題是業(yè)務(wù)上如何實現(xiàn)。然后是技術(shù)與架構(gòu)方面的設(shè)計，主要針對的是技術(shù)實現(xiàn)，解決的問題是技術(shù)上如何實現(xiàn)。這兩個方面是會互相影響的，設(shè)計的時候往往需要來來回回的考慮這兩個方面。甚至系統(tǒng)開發(fā)時也時常會需要調(diào)整模型或者架構(gòu)，當然相應的也需要更新文檔。

基本原則

設(shè)計與分析的過程就是不停的進行抽象和封裝，并且確定各個系統(tǒng)實體的細節(jié)。抽象是指將業(yè)務(wù)抽象為軟件領(lǐng)域的元素（系統(tǒng)、模塊或類）；封裝則是指定義元素的邊界，隱藏實現(xiàn)，開放接口。

相應的，分析與設(shè)計時，最基本的原則就是抽象性和封裝性。當然，我們有 SOLID、DRY、高內(nèi)聚低耦合、設(shè)計模式等各種原則和方法，具體方式本文不詳述了，但最終它們都可以歸類到以上兩點。

業(yè)務(wù)分析

分析方法

業(yè)務(wù)分析是針對業(yè)務(wù)領(lǐng)域的建模，產(chǎn)出就是分析模型。分析模型描述系統(tǒng)的邏輯設(shè)計與結(jié)構(gòu)，一般會包括需求用例、實體模型以及業(yè)務(wù)場景的交互流程、狀態(tài)轉(zhuǎn)換等。分析模型讓非技術(shù)人員能夠理解系統(tǒng)是如何構(gòu)造的，讓技術(shù)人員能夠以此為基礎(chǔ)搭建系統(tǒng)。

分析的過程是不斷迭代的。特別對于復雜的、涉及多個業(yè)務(wù)領(lǐng)域的需求，第一步往往需要在整體系統(tǒng)的層級進行分析，然后將模型劃分到多個子系統(tǒng)，然后再在子系統(tǒng)的層級進行更細節(jié)的分析與建模。

另一方面，分析過程中需要不斷的優(yōu)化和調(diào)整。例如在確定實體的行為細節(jié)時，發(fā)現(xiàn)兩個實體的耦合很高，那么可能需要重新進行抽象，調(diào)整實體的功能范圍。

理清業(yè)務(wù)需求

理清業(yè)務(wù)需求是所有分析與設(shè)計的前提：

確定系統(tǒng)的利益相關(guān)者（Stakeholder）及他們的關(guān)注點。
確定系統(tǒng)的業(yè)務(wù)需求，即「誰」使用該系統(tǒng)「做什么」。
確定系統(tǒng)的功能范圍，即該系統(tǒng)「包含什么」，不包含「什么」。

系統(tǒng)需要滿足利益相關(guān)者的關(guān)注點，所以要確保所有這些關(guān)注點都有涉及到。最重要的利益相關(guān)者當然就是用戶（有時還會細分為不同類型的用戶），此外還應該包括供應商、合作方、運營、銷售、老板甚至政府等等，也同樣包括研發(fā)測試和運維。

具體到系統(tǒng)的用戶，還需要細分到角色，即使有些角色實際可能是同一個人。比如對于門診，可能有護士、顧問或系統(tǒng)管理員等等，可以進行不同的操作。需求范圍簡單話用一個列表即可，復雜的系統(tǒng)可以考慮使用用例圖。

例如，門診預約系統(tǒng)的用例圖可以這樣畫：

角色有醫(yī)生、患者和門診員工。
用例有設(shè)置排班、管理預約以及預約/取消醫(yī)生。

建立實體模型

實體模型是確定系統(tǒng)包含的實體以及它們之間的關(guān)聯(lián)的過程：

理清業(yè)務(wù)概念，統(tǒng)一業(yè)務(wù)詞匯。
抽象業(yè)務(wù)實體，包括事件、人/角色、地點和事物等。
識別實體關(guān)系：繼承、聚合、關(guān)聯(lián)等。

實體模型也叫 ER（Entity-Relation）模型?？梢钥紤]使用四色法建模，一般可以使用類圖或組件圖表示。需要注意的是一定要理清業(yè)務(wù)的概念，統(tǒng)一命名和定義業(yè)務(wù)相關(guān)詞匯，這是進一步溝通的基礎(chǔ)。

例如，預約系統(tǒng)的實體關(guān)系圖可以這樣畫：

分析業(yè)務(wù)場景

場景分析用于確定具體業(yè)務(wù)場景中，各個參與者的交互過程，從而進一步完善分析模型：

分析具體業(yè)務(wù)場景，確定業(yè)務(wù)規(guī)則，梳理業(yè)務(wù)流程。
如果涉及復雜的狀態(tài)轉(zhuǎn)換，需要確定狀態(tài)轉(zhuǎn)換邏輯。
補充和完善實體模型的內(nèi)容描述。

對于一個業(yè)務(wù)場景，參與者可能包括人、內(nèi)部模塊、外部服務(wù)等，這一步需要理清楚整個業(yè)務(wù)過程和規(guī)則。需要注意的是，對于一些次要路徑或者異常路徑，也一定要考慮到。對于業(yè)務(wù)過程和規(guī)則，可以使用普通的流程圖、泳道圖，也可以考慮UML的活動圖，狀態(tài)轉(zhuǎn)換過程則可以通過UML的狀態(tài)圖展示。

對于場景分析中不太確定的需求，或者可能會有技術(shù)難點地方，可以記錄下來，后面確認和驗證。

例如，下面是預約系統(tǒng)的預約狀態(tài)圖。

例如，下面是我們和一家藥品供應商對接的流程圖。

架構(gòu)與技術(shù)設(shè)計

架構(gòu)方法

架構(gòu)設(shè)計不一定要深入到具體的實現(xiàn)細節(jié)，但是應該盡量全面的考慮系統(tǒng)的各個方面。關(guān)鍵是要對項目風險有比較大的把握，這樣才能避免開發(fā)過程出現(xiàn)不可控的問題。具體設(shè)計需要多詳細，是需要設(shè)計者自己去把握度的。

對于暫時無法確定的內(nèi)容，應該在文檔中注明，在開發(fā)過程早期進行試驗和驗證。如果對項目比較關(guān)鍵，可以考慮先行開發(fā)原型來進行驗證。

架構(gòu)設(shè)計常見的是4+1視圖，即邏輯視圖、開發(fā)視圖、過程視圖、物理視圖，再加上場景。另外一種我更喜歡的是視點和視角的方法，如果再加上場景的話，可能會更全面。

確定整體架構(gòu)

首先需要在整體上考慮系統(tǒng)的位置和職責：

確定系統(tǒng)在整個上下文中的位置，與其他系統(tǒng)的關(guān)聯(lián)。
確定系統(tǒng)自身以及各個外部系統(tǒng)的職責。

整體架構(gòu)對應的就是情景視圖。這一步將系統(tǒng)看作一個黑盒，確認系統(tǒng)自己的范圍和職責，相關(guān)的外部系統(tǒng)的職責，以及他們之間的關(guān)聯(lián)。

例如，交易系統(tǒng)的整體架構(gòu)大概是這樣的：

設(shè)計功能模塊

其次需要確定系統(tǒng)內(nèi)部的功能模塊及其職責：

確定系統(tǒng)的模塊劃分。
確定每個模塊的職責以及模塊間的關(guān)聯(lián)。

功能模塊對應的就是功能視圖。這一步需要明確系統(tǒng)的內(nèi)部結(jié)構(gòu)。內(nèi)部模塊劃分主要有基于業(yè)務(wù)功能的劃分，以及基于實現(xiàn)層次的劃分，稍復雜的系統(tǒng)可能會兩者都有。也有一些系統(tǒng)會采用CQRS等架構(gòu)，那么模塊劃分可能會不一樣。功能模塊可以使用UML的組件圖表示。

明確架構(gòu)關(guān)注點

然后需要確定系統(tǒng)架構(gòu)的理念：

理清架構(gòu)設(shè)計需要考慮的關(guān)注點。
確定系統(tǒng)的架構(gòu)設(shè)計上的取舍。

這一步需要考慮各種架構(gòu)視角，主要有(但不限于)以下關(guān)注點：

安全性：身份驗證、權(quán)限控制和授權(quán)、操作日志、安全審計、數(shù)據(jù)一致性等。
性能：響應時間、吞吐量等。
穩(wěn)定性：停機時間、故障恢復、數(shù)據(jù)一致性、數(shù)據(jù)備份等。
擴展性：未來可能的變更，以及如何應對變更。
其他：國際化、易用性、合規(guī)性等。

以上所有的關(guān)注點，和開發(fā)資源、時間、范圍各個方面，往往很難同時滿足，所以必須要明確哪些是關(guān)注的重點，哪些則可以有所妥協(xié)。例如，為了滿足性能要求，可能需要降低數(shù)據(jù)的一致性；為了合規(guī)性，可能不得不花更多開發(fā)時間。

對于未來可能的變更，也一定要考慮到。通常情況下，我們至少要考慮未來半年的架構(gòu)，但可能只實現(xiàn)當前需要的版本，但是確保未來可以很容易的擴展。

一旦確定了關(guān)注的重點，在設(shè)計和開發(fā)的每個過程中，我們都要把這個重點放在心上。

例如，對于訂單系統(tǒng)，因為涉及到錢和交易，數(shù)據(jù)的一致性和可追溯性極其重要。下單和支付的API都必須是冪等的，每一筆收入變動都必須記錄日志，必須有嚴格的核對和對賬。為了安全，每一次API調(diào)用都必須進行權(quán)限驗證。

例如，亞馬遜有個知名的原則，所有的系統(tǒng)間調(diào)用都必須通過定義清楚的 API，不允許共享數(shù)據(jù)庫。這也是一個架構(gòu)原則。

設(shè)計數(shù)據(jù)庫模型

如果分析時有了完善了實體模型，設(shè)計數(shù)據(jù)庫模型就不是什么難事了。開發(fā)完成后，數(shù)據(jù)庫模型應該以數(shù)據(jù)庫為準，架構(gòu)文檔就不需要保留這一部分了。

需要注意的是，數(shù)據(jù)庫模型是實體模型在關(guān)系數(shù)據(jù)庫的實現(xiàn)，但不一定是嚴格的映射。數(shù)據(jù)庫可能會有范式、冗余、一致性、同步、分表分庫方面的考慮，必要時可能會使用非關(guān)系型數(shù)據(jù)庫如ElasticSearch、Cassandra等。

有時候還會涉及到數(shù)據(jù)處理的流程。例如，一張圖片提交后可能需要進行預處理，然后有運營人員進行審核和標記，最后進行發(fā)布。過程中數(shù)據(jù)的保存形式或者狀態(tài)標記可能是不一樣的。

數(shù)據(jù)庫設(shè)計的更多規(guī)范可以參考數(shù)據(jù)庫規(guī)范。

設(shè)計接口

然后就需要確定 API 細節(jié)了。一般我們的服務(wù)的 API 是 JSON 格式 HTTP 形式的請求和回調(diào)。API 可能是接口定義，也可能會有其他接口形式，例如消息隊列等。設(shè)計階段，API 文檔可以通過 Markdown 文檔、RAP 等記錄，開發(fā)完成后可以獨立維護，或者使用 Swagger 和代碼一起維護。

接口設(shè)計需要注意幾點：

接口的設(shè)計應該以系統(tǒng)提供的領(lǐng)域資源或服務(wù)為基礎(chǔ)，同時考慮調(diào)用方的需求。
接口的粒度很重要，太細則調(diào)用方很不方便需要多次調(diào)用，太粗則無法靈活的滿足各種需求，需要仔細權(quán)衡。
接口的設(shè)計也需要從調(diào)用方的角度考慮如何進行調(diào)用。必要的話可以畫流程圖、時序圖、狀態(tài)圖詳細說明調(diào)用順序即狀態(tài)轉(zhuǎn)換等。
接口的文檔一定要清楚的說明調(diào)用接口的方法、前置條件，參數(shù)作用、不同條件的處理、返回接口等。

場景實現(xiàn)

一般情況下，有了業(yè)務(wù)場景分析，有了數(shù)據(jù)庫模型和 API，系統(tǒng)的實現(xiàn)一般是比較簡單了。但可能還會有一些細節(jié)需要進一步考慮實現(xiàn)細節(jié)，以避免風險?？梢钥紤]更細節(jié)的活動圖、時序圖甚至偽代碼。例如：

復雜業(yè)務(wù)場景的詳細設(shè)計，或者復雜算法的實現(xiàn)描述。
離線任務(wù)的執(zhí)行方式、時間和步驟。
非業(yè)務(wù)的一些場景，例如網(wǎng)絡(luò)斷開、緩存失效、第三方系統(tǒng)宕機等。

例如，對于支付系統(tǒng)的微信 Web 支付過程，涉及系統(tǒng)較多，交互比較復雜，可以通過時序圖來定義清楚：

其他考慮

對于我們的后臺系統(tǒng)來說，基本的技術(shù)框架都已確定，可以解決很多基礎(chǔ)的非業(yè)務(wù)需求。不過設(shè)計系統(tǒng)時，也還是需要考慮以下等方面：

通用處理的方式，例如日志、錯誤處理、代碼規(guī)范、單元測試等。
數(shù)據(jù)遷移、同步和回滾方案：對于老系統(tǒng)的重構(gòu)，需要仔細考慮并且提前演練。
系統(tǒng)部署和發(fā)布：如果系統(tǒng)涉及多個子系統(tǒng)，需要考慮系統(tǒng)的部署架構(gòu)。特別是同時涉及到數(shù)據(jù)遷移的，一定要仔細考慮發(fā)布的過程。
系統(tǒng)監(jiān)控和告警：除了常規(guī)的監(jiān)控和告警，是否有特殊的指標需要監(jiān)控？
并發(fā)和數(shù)據(jù)量：如果系統(tǒng)可能面臨對高并發(fā)和大數(shù)據(jù)量的問題， 需要設(shè)計對應的方案，以及相關(guān)的性能測試和壓力測試。
緩存設(shè)計：如果需要使用緩存，除了要考慮緩存的選型、方案，而且要把緩存放到整個系統(tǒng)中去進行設(shè)計。
技術(shù)選型：涉及到新技術(shù)的引入時，則需要仔細分析備用技術(shù)的優(yōu)缺點，選擇最合適的方案。

設(shè)計方法和工具

UML
面向?qū)ο笤O(shè)計（OOAP）
領(lǐng)域驅(qū)動設(shè)計（DDD）
CQRS & Event Sourcing

參考書

分析模式：可復用的對象模型( https://book.douban.com/subject/4832380/ )
軟件系統(tǒng)架構(gòu)：使用視點和視角與利益相關(guān)者合作( https://book.douban.com/subject/24530471/ )
UML和模式應用( https://book.douban.com/subject/1792387/ )
架構(gòu)即未來：現(xiàn)代企業(yè)可擴展的Web架構(gòu)、流程和組織( https://book.douban.com/subject/26765979/ )

文章

從用例分析到方案評審，我們是如何進行業(yè)務(wù)系統(tǒng)設(shè)計的( http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg )
互聯(lián)網(wǎng)公司研發(fā)RD如何撰寫總體設(shè)計與詳細設(shè)計文檔( http://www.10tiao.com/html/249/201412/201657741/1.html )
用UML做好系統(tǒng)分析( http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis )
運用四色建模法進行領(lǐng)域分析( http://www.infoq.com/cn/articles/xh-four-color-modeling )
從“四色建模法”到“限界紙筆建模法”( http://insights.thoughtworkers.org/paper-pen-modeling/ )
淺談我對DDD領(lǐng)域驅(qū)動設(shè)計的理解( http://www.cnblogs.com/netfocus/p/5548025.html )
領(lǐng)域驅(qū)動設(shè)計參考架構(gòu)詳解( http://blog.csdn.net/bluishglc/article/details/6681253 )
領(lǐng)域驅(qū)動設(shè)計和實踐( http://www.infoq.com/cn/articles/cjq-ddd )
我對CQRS/EventSourcing架構(gòu)的思考( http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027 )
架構(gòu)設(shè)計基礎(chǔ)知識整理( https://blog.dreamtobe.cn/2016/03/09/oo_architecture/ )

作者：章燁明，杏仁醫(yī)生CTO。中老年程序員，關(guān)注各種技術(shù)和團隊管理。
出處： https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA

網(wǎng)頁題目：如何進行系統(tǒng)分析與設(shè)計-創(chuàng)新互聯(lián)
分享路徑：http://bm7419.com/article12/cescgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、建站公司、虛擬主機、小程序開發(fā)、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)