軟件架構(gòu)如何分層、分模塊

本篇內(nèi)容介紹了“軟件架構(gòu)如何分層、分模塊”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

一、軟件架構(gòu)設(shè)計的生命周期

1. 軟件開發(fā)流程

2. 關(guān)于套路

3. 先僵化，后優(yōu)化，再固化

4. 佛說：知我說法，如筏喻者

二、需求調(diào)研和需求分析

1. 功能需求

2. 質(zhì)量屬性

3. 條件約束

4. 畫用例圖

5. 寫用例描述

6. 確定關(guān)鍵需求

一、軟件架構(gòu)設(shè)計的生命周期

什么是架構(gòu)?如果你問十個人，有可能得到十一種不同的答案;如果去翻一下相關(guān)的書籍，每一本都可能給出不同的定義。

因此，我們沒必要糾結(jié)于那些概念，只要方法對、能完成項(xiàng)目任務(wù)就行，不管黑貓白貓，能抓到耗子的就是好貓!

1. 軟件開發(fā)流程

一個軟件項(xiàng)目，從立項(xiàng)開始到最終的交付，中間經(jīng)歷了諸多環(huán)節(jié)。具體到軟件設(shè)計的生命周期來說，可包括這些階段：需求調(diào)研-需求分析-概要設(shè)計-詳細(xì)設(shè)計-架構(gòu)驗(yàn)證-開發(fā)-單元測試-集成測試。

上面這幾個步驟，仍然是非常粗略的概念。在實(shí)際操作中，其中的每一個步驟又可以細(xì)分為很多具體的執(zhí)行環(huán)節(jié)。

例如：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 需求調(diào)研：應(yīng)該怎么做?用什么方法?有什么指導(dǎo)思想?有什么好的工具?

3. 需求分析：應(yīng)該怎么分析?所有的需求都應(yīng)該被分析嗎?如何找出關(guān)鍵需求?

4. 詳細(xì)設(shè)計：在軟件工程中有什么實(shí)踐性比較好的方法?如何分層?如何分模塊?

以上這些都是軟件設(shè)計的過程中，需要涉及到的問題。那么軟件設(shè)計的最終目標(biāo)是什么呢?就是下面幾個文檔：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 邏輯架構(gòu);

3. 物理架構(gòu);

4. 運(yùn)行架構(gòu);

5. 開發(fā)架構(gòu);

2. 關(guān)于套路

我認(rèn)為，在這個世界上，一切皆有套路，包括任何事情、任何領(lǐng)域、任何行業(yè)。

當(dāng)我們進(jìn)入一個新的領(lǐng)域時，比如：讓你設(shè)計一個車輛調(diào)度系統(tǒng)、機(jī)器人控制系統(tǒng)，或者設(shè)計一個對講機(jī)、一個物聯(lián)網(wǎng)網(wǎng)關(guān)，如果你是這個領(lǐng)域的新人，那么肯定是兩眼一抹黑：我對這個領(lǐng)域完全不懂，怎么設(shè)計啊?

這讓我想起一個小故事：

有一次我剛?cè)肼氁患倚鹿?，接手一位離職同事手里的工作。當(dāng)時執(zhí)行 KPI 考核，bug 直通率(就是一次性把 bug 解決掉的比例，QA 人員不會再把  bug  踢給你)，是一個重要的指標(biāo)。面對系統(tǒng)里那么多的bug，領(lǐng)導(dǎo)問我：這些問題你大概需要多久能解決掉?我說：以前沒接觸過這方面的工作，沒法給出準(zhǔn)確的時間。領(lǐng)導(dǎo)說：沒關(guān)系，你先給我一個具體的時間就行了。當(dāng)時我就懵逼了。

在這個時候，最重要的事情就是，快速把這個領(lǐng)域里的基本的、重要的背景知識了解、掌握。那么應(yīng)該如何做呢?找套路!

不要貪大求全，不要奢望把所有相關(guān)的內(nèi)容都掌握，這是不可能的，尤其是在短時間內(nèi)。我們的目標(biāo)是把活做好，把項(xiàng)目完成。

這個時候，我一般的做法是：找套路!

這么說可能有點(diǎn)虛幻，那么就以軟件開發(fā)中的架構(gòu)設(shè)計來舉例。在軟件工程或者項(xiàng)目管理的書籍、資料中查找下面這些相關(guān)內(nèi)容：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 別人是怎么來設(shè)計架構(gòu)的?

3. 設(shè)計過程中需要哪些步驟?

4. 每一個步驟中，輸入是什么?輸出是什么?

5. 每一個步驟中，需要考慮的點(diǎn)是什么?

6. 有哪些好的軟件工具?

7. 如何與項(xiàng)目的相關(guān)人進(jìn)行溝通(項(xiàng)目經(jīng)理、開發(fā)人員、測試人員、甲方客戶)?

把以上的這些別人的經(jīng)驗(yàn)進(jìn)行梳理，總結(jié)出一套適合自己的“方法論”，然后在具體執(zhí)行的時候按照這個套路一步一步的走，根據(jù)實(shí)際情況適時的動態(tài)調(diào)整，一般來說都能夠順利的推進(jìn)一個項(xiàng)目。

3. 先僵化，后優(yōu)化，再固化

這九個字是華為的掌舵人任正非在引進(jìn)管理體系時提出的，這是一種非常實(shí)用的方法。

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 僵化：站在巨人的肩膀上：處于學(xué)習(xí)初期階段的“削足適履”;

3. 優(yōu)化：掌握自我批判武器：在實(shí)踐中不斷吸收、改良、創(chuàng)新，優(yōu)化自己;

4. 固化：創(chuàng)新是有階段性的、受約束的，如果沒有約束，創(chuàng)新就是雜亂無章、無序的創(chuàng)新，需要像夯土一樣，一層層夯上去，一步步固化階段性的優(yōu)化成果;

對于軟件架構(gòu)設(shè)計，我們也可以按照這樣的步驟走。

第一步就是僵化，也就是按照按照固定的套路走，雖然可能會“落入俗套”，但是至少能保證在正確的道路上，不會走歪，這是最重要事情!

如果被別人認(rèn)為是“落入俗套”了，說明什么?說明別人已經(jīng)認(rèn)為你的做法符合這個領(lǐng)域中最“一般的”的做事流程，也就是相當(dāng)于認(rèn)可你已經(jīng)真正進(jìn)入這個領(lǐng)域了，這是好事情!

作為初學(xué)者，被別人這樣評價，不應(yīng)該覺得自豪嗎?畢竟我們自己心里知道：我就是剛剛進(jìn)入這個領(lǐng)域的小白而已。

4. 佛說：“知我說法，如筏喻者”

我寫這篇文章的目的，主要就是想聊一聊我是如何“僵化”的來進(jìn)行軟件架構(gòu)設(shè)計的。

我們在剛進(jìn)入軟件開發(fā)行業(yè)的時候，每天的工作主要是擼代碼，也許還不夠資格來進(jìn)行整個系統(tǒng)的架構(gòu)設(shè)計。但是這并不妨礙我們自己來主動學(xué)習(xí)，機(jī)會都是留給有準(zhǔn)備的人的，如果有一天，項(xiàng)目組里出現(xiàn)了架構(gòu)設(shè)計的這個坑，那么領(lǐng)導(dǎo)會找哪個蘿卜來填坑呢?

因此，這篇文章主要介紹的就是最初級、最基本的軟件設(shè)計步驟，以及在每一個步驟中使用的指導(dǎo)思想、順手的工具等等。

如果您已經(jīng)是資深軟件設(shè)計工程師，那么可以去喝咖啡、享受人生了，當(dāng)然也可以分享您的方法論，我們相互學(xué)習(xí)!

這些內(nèi)容也不是我自己摸索出來的，而是在項(xiàng)目開發(fā)過程中翻閱書籍、搜索資料、總結(jié)而來的，比較適合我所面對的項(xiàng)目，我也僅僅是知識的搬運(yùn)工。

之前，我主要參考了幾本關(guān)于軟件架構(gòu)設(shè)計的書籍，相互借鑒，總結(jié)出適合我的一套方法。上次搬家，好多書籍丟掉了，只剩下電腦里的零碎筆記了。這篇文章的素材來源，就是這些筆記，當(dāng)然，大部分內(nèi)容都是來源于書本，我只是進(jìn)行了一些取舍、裁剪而已。

《金剛經(jīng)》第六品，如來常說：“汝等比丘，知我說法，如筏喻者;法尚應(yīng)舍，何況 非法?！?/p>

佛法就像渡人過河的木筏，過了河上了岸，就應(yīng)該把木筏丟掉，心中不要再想著木筏。木筏就像佛法，佛法尚且應(yīng)該丟棄，何況不是佛法的東西，你還糾結(jié)他干嘛。

所以，我這里所講的設(shè)計套路，也類似于木筏，用來幫助你在剛開始進(jìn)入軟件架構(gòu)設(shè)計時的一個腳手架。當(dāng)你進(jìn)入到第二個段位“優(yōu)化”時，就可以把這個腳手架扔掉了。

到那個時候，你就可以自信的說一句：“道哥寫的都是寫什么東西啊，小兒科的東西，我需要向更高級的段位去探索”。到了這個時候，我就要衷心的恭喜你了!

二、需求調(diào)研和需求分析

大多數(shù)人都認(rèn)同“需求決定架構(gòu)”，但是需求究竟是“如何決定”架構(gòu)的?這部分就來聊一下我的認(rèn)識。

在立項(xiàng)階段，如果運(yùn)氣比較好，可能會拿到一份文檔《軟件功能需求規(guī)格書》(話說一些日本公司的需求說明書，寫的真的是變態(tài)的詳細(xì))。如果運(yùn)氣不好，什么文檔都沒有，所有的需求全部需要自己來收集、整理。

從狹義上來說，需求就是功能;從廣義上來說，還包括質(zhì)量屬性、條件約束這些非功能需求。

1. 功能需求

功能需求部分是最直觀的，就是我們設(shè)計的軟件需要完成哪些事情。在一個系統(tǒng)中，各個功能之間不可能有清晰的邊界的，每一個小模塊之間通過一定的交互，形成一條一條的“協(xié)作鏈條”來完成指定的功能。

例如下面這張圖，是我之前寫的一篇文章：物聯(lián)網(wǎng)網(wǎng)關(guān)開發(fā)：基于MQTT消息總線的設(shè)計過程(上) 中，不同模塊之間的交互模型，紅色和藍(lán)色部分就是 2  條不同的協(xié)作鏈條。

當(dāng)然了，這幅圖是最終設(shè)計出來的系統(tǒng)架構(gòu)(分層、分模塊)，在得到這幅圖之前，我們首先要把所有的功能需求進(jìn)行收集、整理。

在這個階段，最重要的事情是做什么，而不是怎么做。另外，作為設(shè)計人員，需要經(jīng)常問自己一個問題：掌握的需求全不全?有沒有遺漏?

2. 質(zhì)量屬性

我們可以把質(zhì)量要求，按照不同的階段來進(jìn)行歸類：

開發(fā)階段

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 可重用性，不要做重復(fù)的工作;

3. 靈活、容易擴(kuò)展(想一想發(fā)生的需求變更時開發(fā)人員的心理活動);

4. 容易理解(想想你接手別人的項(xiàng)目時);

5. 方便測試(單元測試、集成測試);

6. 可移植(尤其是嵌入式項(xiàng)目，需要運(yùn)行在不同過的平臺);

運(yùn)行階段

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 系統(tǒng)必須可靠;

3. 性能必須達(dá)到一定要求(吞吐量、響應(yīng)時間等等);

4. 沒有漏洞，系統(tǒng)安全;

5. 伸縮性要好，方便擴(kuò)展部署;

3. 條件約束

約束主要是指一些限制條件，比如：

1. 團(tuán)隊人員的技術(shù)棧情況(如果大家都用C，你就不要選擇C++);

2. 領(lǐng)導(dǎo)給的資源有哪些;

3. 如果利用一些開源軟件，是否存在bug?是否方便二次開發(fā)?

4. 項(xiàng)目開發(fā)周期是多久?

5. 軟件的運(yùn)行平臺有哪些?有什么限制?

4. 畫用例圖

關(guān)于用例圖的概念，我也總結(jié)不好，這里就直接引用百度知道里的定義了：

用例圖是指由參與者(Actor)、用例(Use Case)，邊界以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的視圖。

用例圖(User  Case)是外部用戶(被稱為參與者)所能觀察到的系統(tǒng)功能的模型圖。用例圖是系統(tǒng)的藍(lán)圖。用例圖呈現(xiàn)了一些參與者，一些用例，以及它們之間的關(guān)系，主要用于對系統(tǒng)、子系統(tǒng)或類的功能行為進(jìn)行建模。

其中有幾個概念：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 參與者: 不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。

3. 用例：是對包括變量在內(nèi)的一組動作序列的描述，系統(tǒng)執(zhí)行這些動作，并產(chǎn)生傳遞特定參與者的價值的可觀察結(jié)果。

4. 系統(tǒng)邊界: 是用來表示正在建模系統(tǒng)的邊界。邊界內(nèi)表示系統(tǒng)的組成部分，邊界外表示系統(tǒng)外部。

5. 箭頭: 用來表示參與者和系統(tǒng)通過相互發(fā)送信號或消息進(jìn)行交互的關(guān)聯(lián)關(guān)系。

6. 作用:(1)獲取需求;(2)指導(dǎo)測試;(3)還可在整個過程中的其它工作流起到指導(dǎo)作用。

我從網(wǎng)上找了幾個用例圖，其中的每一個圓圈，都代表一個功能。

通過用例圖，可以一目了然的看到系統(tǒng)提供的所有功能。

5. 寫用例描述

但是用例圖沒有詳細(xì)的描述每一個用例的執(zhí)行過程，也就是說：用例圖從總體上描述了系統(tǒng)的需求，但是沒有描述行為過程。

因此，我們可以對每一個用例，附上一個簡單或詳細(xì)的用例描述，這樣就更加具體的確認(rèn)了這個用例的行為過程。

下面也是從網(wǎng)絡(luò)上找的 2 個用例描述示例，可以看到并沒有統(tǒng)一的格式，需要根據(jù)項(xiàng)目的性質(zhì)進(jìn)行增減。

6. 確定關(guān)鍵需求

假設(shè)我們在不斷的搜集和分析中，盡可能地列出了所有的需求(功能需求、質(zhì)量屬性、條件約束)，下一步需要做什么呢?需求這么多，該從哪一個需求入手呢?

關(guān)鍵需求 = 關(guān)鍵功能 + 關(guān)鍵質(zhì)量。它確定了架構(gòu)的大方向。

首先要明確一點(diǎn)：不可能所有需求都是一律平等。我們要從眾多的用例出找出下面這 3 類需求：

• 關(guān)鍵功能需求：那些涉及到的模塊最多、模塊之間協(xié)作方式最有代表性的功能，篩選出關(guān)鍵功能子集;

• 關(guān)鍵質(zhì)量屬性：在開發(fā)和運(yùn)行階段，哪些質(zhì)量屬性對軟件架構(gòu)的影響比較大，如果質(zhì)量屬性之間存在相互矛盾的地方，應(yīng)該優(yōu)先考慮哪個?

• 高風(fēng)險部分：從技術(shù)難度上考慮，哪些功能在技術(shù)實(shí)現(xiàn)上存在風(fēng)險，需要體驗(yàn)提前進(jìn)行技術(shù)驗(yàn)證?

這 3 類需求就是需要我們重點(diǎn)照顧的需求，也是進(jìn)行下一個步驟(領(lǐng)域建模)的輸入材料。

“軟件架構(gòu)如何分層、分模塊”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！