CTO也糊塗的常用術語（01）

• 2019 年 10 月 6 日
• 筆記

功能模組、業務架構、需求分析、用戶需求、系統分析、功能設計、詳細設計、文檔、業務、技術……很多被隨口使用的名詞，其實是含糊甚至錯誤的。

到底含糊在哪裡，錯誤在哪裡，不僅僅是新手軟體開發人員糊塗，許多入行多年的老手也一樣。雖然很多老手功成名就，掛著CTO、總架構師等研發線的最高頭銜，但是心裡對這些概念也是一團漿糊。

可能有的人會說，不會吧，這些牛人帶團隊做出了成功的系統，怎麼會不清楚呢，只不過表達出來和你的表達不同而已吧？我只能很誠懇地再說一遍：很多「牛人」真的不清楚。當然，搞不清楚不妨礙做出讓公司賺錢的系統，就像有的人不了解人體運行機制憑感覺也活到了一百歲。您也可以說「做出過成功的系統就行了唄，管他清楚不清楚呢！」，對對對，您說的都對，但不清楚也還是不清楚。

我先說一下我在《軟體方法》一書中對軟體建模工作流的劃分：

1. 業務建模——描述所研究組織內部各系統（人肉系統、電腦系統……）如何協作，使得組織可以為其他組織提供有價值的服務。

2. 需求——描述為了解決組織的問題，所研究系統必須具有的表現——功能和性能。

3. 分析——提煉為了滿足功能需求，所研究系統需要封裝的核心域機制。

4. 設計——為了滿足品質需求和設計約束，核心域機制如何映射到選定平台上實現。

以上四個工作流的名稱使用了傳統術語，也有一定的模糊性（特別是業務建模）。其實我覺得更貼切的名稱是組織建模、需求建模、核心域建模、實現。如果您覺得業務建模、需求、分析、設計不好，改成阿豬、阿狗、阿雞、阿鴨也無所謂。關鍵是要了解劃分的依據，一個是研究範圍，一個是研究內容。如圖1：

圖1 不同工作流的研究範圍和內容

再說一下核心域和非核心域的概念。一個軟體系統封裝了若干領域的知識，其中一個領域的知識代表了系統的核心競爭力，是系統和其他系統區分的關鍵所在。這個領域稱為"核心域"，其他領域稱為"非核心域"。更通俗的說法是"業務"和"技術"，但使用"核心域"和"非核心域"更嚴謹。核心域不一定是物流、醫療、金融等非電腦領域，也可以是電腦和軟體領域。圖2展示了不同系統的核心域和非核心域概念：

圖2 不同系統的核心域、非核心域概念

好，根據以上的知識，我們來逐一剖析這些術語，可能有好幾十個。

術語01：功能模組

評價：「功能」屬於模糊術語，「模組」屬於模糊術語，「功能模組」屬於錯誤術語。

功能（Function）。當我們說起這個詞的時候，研究對象一般是系統。對於組織，一般說「組織的服務」，對於類，一般說「類的操作」。所以，「功能」屬於「需求」的範疇（功能需求），描述系統作為一個整體為其他系統提供的服務，把其他系統給它的輸入變成其他系統所需要的輸出。

但是，「功能需求」仍然不夠精確。例如，以自助櫃員機（ATM）為研究對象，「取現金」是「功能」，「登錄」也是功能，「計算手續費」也是「功能」，到底「功能」有多大？用例的術語要嚴謹得多。「取現金」是一個用例，「登錄」是用例中的一個回合，「計算手續費」是一個步驟。

模組（Module）。當我們說起這個詞的時候，研究對象一般是系統。模組表示系統的一個組成部分，屬於「分析」和「設計」的範疇。這個詞也是模糊的。這個模組是一個控制項？一個類？若干個類形成的組件？

如果說「功能」和「模組」是模糊的，那麼「功能模組」就是錯誤的，這個詞混淆了系統外部和內部的區別，需求和設計的區別。

「功能」是系統對外提供的服務，「模組」是系統的內部結構。連起來說「功能模組」，意味著在意識里認為「功能」和「模組」有直接的映射關係，甚至認為「模組」是屬於某個「功能」的模組，是為了完成某個「功能」而存在的。

這樣的認識是錯誤的。如圖3所示，完成某個「功能」需要若干「模組」的協作，而某個「模組」也會參與完成若干「功能」，例如可以看出「模組6」被反覆使用了很多次。如果將「功能」和「模組」直接映射，系統內部將出現大量冗餘。

圖3 「功能」和「模組」的映射是多對多的

人體就是一個系統，基本功能有走路、跳躍、吃飯等，但是設計人體結構時，不能從外部直接映射到內部，得到人體由「走路模組」、「跳躍模組」、「吃飯模組」組成。人體的「模組」是五官四肢和內臟，還有最關鍵的——「大腦」。不管是走路、跳躍還是吃飯或者將來發展出更多的「功能」，都由這些「模組」協作完成。

術語02：業務架構

評價：「業務」屬於模糊術語，「架構」屬於模糊術語，「業務架構」屬於模糊術語。

（待續）