建站
咨詢
售后
建站咨詢
新聞中心
- 一、前言
- 二、需求調(diào)研和需求分析
- 1. 用例圖
- 2. 用例描述
- 三、概要設計
- 1. 針對關鍵用例，畫出魯棒圖
- 2. 對魯棒圖中的模塊進行歸類，劃分出子系統(tǒng)
- 四、詳細設計
- 1. 邏輯架構
- 2. 運行架構
- 3. 開發(fā)架構
- 五、架構驗證
- 1. 系統(tǒng)框架
- 2. 技術瓶頸
- 六、總結
一、前言
在上一篇文章中，我們主要聊了：在嵌入式系統(tǒng)的應用程序架構設計中，應該從哪些方面來進行需求整理和分析，文章鏈接：都說軟件架構要分層、分模塊，具體應該怎么做之一。
這篇文章，我們繼續(xù)聊一下在概要設計、詳細設計階段，我們應該做什么工作?用什么工具或手段來做?輸出結果是什么?
按照慣例，為了內(nèi)容描述的方便，我會用一個物聯(lián)網(wǎng)網(wǎng)關的設計過程，把所有的內(nèi)容串接在一起。如果小伙伴對于網(wǎng)關不太了解，請滑到文章底部的推薦閱讀列表，其中有幾篇文章是關于網(wǎng)關功能介紹的。
二、需求調(diào)研和需求分析
1. 用例圖
上篇文章說到，在進行需求調(diào)研和需求分析的時候，用例圖是非常非常好用的一個工具。通過用例圖，我們可以把一個系統(tǒng)中需要完成的所有功能，從粗粒度上一目了然的呈現(xiàn)出來。
下面這張圖，是網(wǎng)關的用例圖(這里畫的用例還不完全)：
2. 用例描述
用例圖僅僅是描述了系統(tǒng)具有的功能，但是并沒有描述每一個用例的行為，也就是執(zhí)行過程。
在上一篇文章中說到，我們不需要對每一個用例進行分析，而是需要在這些用例中，找出那些關鍵用例，然后對這些關鍵用例寫出用例描述，因為關鍵用例才是系統(tǒng)架構的決定因素。
那么又出現(xiàn)一個問題了：如果把所有的用例，按照重要程度進行優(yōu)先級排序，那么從上到下應該選取多少個、或者說百分之多少的關鍵用例呢?這個就要看整個系統(tǒng)的復雜度了，30%不嫌少，50%不嫌多，根據(jù)你的時間自由把握。
以上圖網(wǎng)關中的用例圖來說，我認為：添加設備、刪除設備、控制設備、規(guī)則配置、規(guī)則觸發(fā)這幾個用例比較關鍵，因此，我就針對這幾個用例寫用例描述。
(1)添加設備用例描述
其中有 2 點注意的地方：
在事件流中，我們是把網(wǎng)關作為一個黑盒進行描述的，因為我們是在進行需求分析，而不是在進行設計，因此，不需要考慮網(wǎng)關內(nèi)部的執(zhí)行流程;
紅色部分都是一個執(zhí)行主體，這個主體可以是一個人、一個界面、一個設備、一個系統(tǒng)等等;
事件流可以用文字來描述(就像圖中這樣)，也可以畫一個序列圖來展現(xiàn)這個過程，就像下面這樣(這里沒有詳細描述出更細的執(zhí)行過程，主要以示意性為主):
(2) 刪除設備用例描述
(3) 控制設備用例描述
(4) 規(guī)則配置用例描述
(5) 規(guī)則觸發(fā)用例描述
三、概要設計
可以把概要設計理解成一個粗略、抽象的架構圖，用來體現(xiàn)高層組件，以及它們之間的聯(lián)系。那么應該怎么做，才能得到這樣的一張架構圖呢?
我們現(xiàn)在的掌握的材料就是：用例圖和(關鍵用例的)用例描述，而且在用例描述的基本事件流中，把要設計的系統(tǒng)當做一個黑盒子進行描述。
現(xiàn)在我們需要做的事情，就是打開這個黑盒子，進入其中內(nèi)部，從執(zhí)行過程上來分析：需要哪些模塊完成什么動作。
注意，這是我們的目的。要達成這個目的，使用魯棒圖這個工具。
也就是說，我們現(xiàn)在需要通過魯棒圖這個工具，去拆解用例描述中的事件流，把系統(tǒng)內(nèi)部的、為了完成這個用例所需要的參與元素，全部都找出來，并標注它們之間的關系。
1. 對每個關鍵用例的用例描述，畫出魯棒圖
先說一下容易混淆的概念：魯棒性，也稱作健壯性，是指程序在運行過程中，即使出現(xiàn)了一些錯誤的狀況，也已讓能夠順利的執(zhí)行下去。它描述的是程序的容錯性。
魯棒圖是指：用圖形建模的方式，來描述一個用例描述是否正確、是否完善。
主要通過 3 種元素：邊界對象，控制對象和實體對象，來畫出一個用例描述中，待設計的系統(tǒng)內(nèi)部各功能模塊之間的交互關系。
邊界對象：在系統(tǒng)內(nèi)部，需要與外界進行交互的元素。它負責接收外部的輸入、向外部輸出內(nèi)部的處理結果;
控制對象：描述動態(tài)的控制行為，強調(diào)從一個執(zhí)行環(huán)節(jié)進入另一個執(zhí)行環(huán)節(jié);
實體對象：對一個信息內(nèi)容進行描述，比如：網(wǎng)關中的一個設備描述信息、一條規(guī)則配置信息等;
關于邊界對象，在 Web 類項目中，可能比較好理解，就是與用戶、外部系統(tǒng)所交互的界面。但是在嵌入式系統(tǒng)中，大部分情況下是沒有界面的，但是我們只要抓住一個根本的東西：接收外部的輸入、向外部輸出數(shù)據(jù)。
我們這里就簡單畫一下添加設備、控制設備和規(guī)則觸發(fā)，這 3 個用例描述對應的魯棒圖(先忽略這幾張圖中的顏色)：
添加設備：
控制設備：
規(guī)則觸發(fā)：
關于添加規(guī)則的執(zhí)行過程中，大部分工作是在手機 APP 上完成的(選擇源設備--觸發(fā)條件--目標設備)，網(wǎng)關中只是把配置好的這條規(guī)則存儲一下而已，沒有其他過多的操作。
規(guī)則中更重要的部分是規(guī)則觸發(fā)的處理，例如：當紅外設備(源設備)檢測到人體時，如果當前處于布防狀態(tài)(觸發(fā)條件)，就啟動聲光個報警器(目標設備)，因此下面這張圖是描述執(zhí)行一條規(guī)則的執(zhí)行過程，這個過程的執(zhí)行鏈條比較長，能把很多的模塊串接起來。
2. 對魯棒圖中的模塊進行歸類，歸納出子系統(tǒng)
假設我們現(xiàn)在把所有關鍵用例的魯棒圖都畫出來了，下一步的動作就是對這些模塊進行分類。上面幾張圖中，有些模塊被標記了不同的顏色，相同的顏色表示它們是屬于一類的。
黃色部分的模塊都是與無線通訊相關的，那么這些模塊就可以歸類為無線通信管理子系統(tǒng);
綠色部分的模塊都是與設備相關的，那么它們就歸類為設備管理子系統(tǒng);
藍色部分的模塊都是與規(guī)則相關的，那么它們就歸類為規(guī)則管理子系統(tǒng);
繼續(xù)找出其他的子系統(tǒng)。。。
最終，我們把這些子系統(tǒng)(或者稱之為功能組)畫到一張圖中如下：
這張圖就從上層組件的視角，把整個系統(tǒng)劃分為幾個子系統(tǒng)，每一個子系統(tǒng)都是一個獨立的、可以交付的實體模塊。
這張圖的作用還是挺大的，可以用于向領導進行匯報(領導才沒有時間看詳細的設計)，也可以用于產(chǎn)品說明書中的技術架構描述部分，還可以用于團隊成員分工，因為每一部分都是一個獨立的單位，與其他子系統(tǒng)之間的耦合性，從靜態(tài)和動態(tài)兩方面都隔離開來了(待會在后面的開發(fā)架構設計中進行說明)。
這些子系統(tǒng)之間是需要通信的，因此，在畫出這個設計圖之后，我們還需要做出下面的幾個決策：
使用的技術棧：開發(fā)語言 C，進程之間的通信方式：消息總線;
并發(fā)：每個子系統(tǒng)以進程為執(zhí)行單位運行在系統(tǒng)中，通過 MQTT 消息總線的C語言實現(xiàn) mosquitto 庫，來接入到總線系統(tǒng)上;
系統(tǒng)不支持二次開發(fā);
四、詳細設計
在上面的概要設計圖中，已經(jīng)把所有的功能模塊劃分到不同的子系統(tǒng)中，也可以稱之為功能組。下一步的工作，就是把每一個功能組中的內(nèi)部對象、需要完成的功能、交互流程找出來，具體來說，就是要分析出系統(tǒng)的邏輯架構、運行架構和開發(fā)架構。
1. 邏輯架構
邏輯架構就是把每一個子系統(tǒng)再分為粒度更細的功能塊，如果想粒度更細的話，也可以拆解到類這個級別。此外，還需要定義好各模塊之間的交互接口。
根據(jù)上面的描述，我們已經(jīng)決定把各子系統(tǒng)設計為一個獨立的進程，各進程之間通過消息總線進行數(shù)據(jù)交互，而這個消息總線，是基于 topic 主題來進行消息路由的，因此，下面就要設計好每一個進程需要處理哪些數(shù)據(jù)交互：
- 入口：對其他哪些模塊的請求進行響應;
- 出口：為了完成自己的工作，需要依賴其他哪些模塊提供服務;
一句話總結：就是找出每一個模塊，為了完成自己的工作，需要與其他哪些單元模塊之間進行交互?交互的接口(函數(shù)、方法或者協(xié)議)是什么?
那么怎么來找到這些對象和接口呢?用序列圖或者類圖來完成。下面是控制設備的一個簡單序列圖：
圖中的每一個箭頭，都代表一個接口，對于這個網(wǎng)關來說，就代表處理的一個 topic 主題。
如果用類圖來分析，對于面向對象的開發(fā)語言來說，可能會更容易理解，比如：可以明確的定義出每一個對象的屬性，私有函數(shù)，共有函數(shù)，并且能夠清晰的構建出對象之間的關系。
2. 運行架構
運行架構描述的是每一個執(zhí)行單元的動態(tài)狀態(tài)、執(zhí)行時的控制流程，需要考慮的重點是：系統(tǒng)是否安全?性能是否滿足質(zhì)量要求?可擴展性如何?
具體到網(wǎng)關來說，每一個子系統(tǒng)是以進程為執(zhí)行單位的，每個進程通過一個第三方的附件(也就是動態(tài)庫)，掛接到消息總線上，如下圖所示：
系統(tǒng)的并發(fā)性，是通過多進程來實現(xiàn);系統(tǒng)的安全性，主要通過消息總線的安全機制來管理。
比如在開發(fā)階段，消息總線允許系統(tǒng)外的其他客戶端接入，這樣就可以在 PC 機上寫一個調(diào)試程序，接入到總線中，可以監(jiān)聽所有的數(shù)據(jù)，此時數(shù)據(jù)可以不加密，全部是 human readable 的;但是在項目 release 階段，那么就關閉這個權限，PC 機上的客戶端就不能接入總線，并且總線中所有數(shù)據(jù)的需要加密、壓縮，進一步提高系統(tǒng)的安全性。
3. 開發(fā)架構
作為以擼代碼為主力的我們來說，開發(fā)架構就容易理解了，無非就是定義好項目結構、編譯流程、測試步驟等等。
具體來說，我們可以從下面幾方面來做出規(guī)定：
- 并行開發(fā)：每個子系統(tǒng)是一個獨立的進程，因此可以劃分為一個獨立的項目，提高開發(fā)效率;
- 第三方庫：作為基礎的公共模塊來使用(SSL加密、消息總線接入、通信協(xié)議解析);
- 代碼安全：每位開發(fā)人員只能有權限拿到自己負責的代碼，只有管理員有權限獲取所有代碼;
- 代碼管控：使用 git、svn 等工具進行代碼版本的管理;
- 集成編譯：使用 Jenkins + git module 功能，自動拉取所有的子系統(tǒng)代碼，自動編譯。如果需要自動部署的話，也可以使用腳本來實現(xiàn)。
五、架構驗證
終于來到最后一個環(huán)節(jié)了，其實項目經(jīng)歷多了，以上設計出來的架構，是否能滿足需求中提出的功能和質(zhì)量要求，我們在心中已經(jīng)大概知道答案了。
為了保險起見，我們還是需要對其中的某些關鍵部分進行驗證。這個驗證過程是有價值的，或者說可以把這個驗證過程所得到的成果，作為正式的代碼進行提交。
驗證的大方向有 2 點：系統(tǒng)的框架是否合理、穩(wěn)定;一些技術瓶頸是否可以搞定。如果這兩部分都沒問題，那后面就可以大膽的往前走了。
六、總結
經(jīng)過 2 篇文章的介紹，我基本上把自己在平常工作中，對應用程序架構設計的這個思考過程描述了一遍。
佛經(jīng)里說了：渡人就像幫助一個人過河，過了河上了岸，就應該把乘坐的木筏丟掉，心中不要再想著木筏。
這篇文章介紹的設計流程，也是一個套路而已。這個套路在面對一個新領域、新項目時，就像一個腳手架一樣，告訴我們這一步該做什么，下一步該做什么，應該使用什么樣的工具。
在僵化的運用這個套路之后，你可以繼續(xù)改造、優(yōu)化，然后丟掉這個套路，從而形成適合你自己的套路，從此走向思考致富的道路!
祝你好運!
本文轉載自微信公眾號「IOT物聯(lián)網(wǎng)小鎮(zhèn)」，可以通過以下二維碼關注。轉載本文請聯(lián)系IOT物聯(lián)網(wǎng)小鎮(zhèn)公眾號。
分享文章：都說軟件架構要分層、分模塊，具體應該怎么做之二
分享網(wǎng)址：http://m.5511xx.com/article/cdpoiic.html
