公理設計-由奇怪海戰引起的軟件設計思考

前幾天看到了一個博客，推薦了《公理設計》一書，還有其相關的文檔以及視頻。簡單瞭解了一下，增深了一些對軟件設計的理解，特此也推薦給你們。

公理設計理論將設計創建在科學公理、定理和推論的基礎上，由麻省理工學院教授 Nam. P. Suh 領導的研究小組於 1978 年提出，適用於各類類別的設計活動。軟件設計固然也屬於一類工程設計過程，下面咱們就來看一下二者的關聯。

奇怪的海戰

首先從1862年11月13日的一場海戰講起。這場海戰「標誌着蒸汽動力鐵甲艦新時代的到來。爲了便於理解，我這裏對艦船名稱進行了修改，想了解的朋友能夠百度 U.S.S. Monitor battles C.S.S. Virginia.

南方叛軍的大大號戰艦，體型龐大，很是兇悍。已經擊沉了兩艘聯邦軍艦。北方政府軍則只派出小小號，一艘很是小，火力也小多的軍艦。

大大號顧名思義，它船體特別的大，可是都是固定炮塔，兩側和首尾有不少門炮。而小小號雖然小，卻有一個能夠旋轉的炮臺。

咱們能夠理解爲一條戰艦須要有兩個基礎功能：調整航行方向和調整炮擊方向。

對於大大號，這兩個功能需求是耦合 couple 的，要改變炮擊方向，就須要將船隻轉向。而對於小小號，這兩個功能需求則是解耦合 decouple 的，航行方向與炮擊方向無關，炮擊方向能夠獨立調整。

因而小小號一直儘可能守在大大號的射擊死角攻擊，而大大號雖然火力猛烈則必須不斷經過改變航線來調整炮擊方向，因而就不斷繞圈。這兩條船打了4個小時，大大號不得不撤退了，小小號得到了勝利。

因而可知功能之間的解耦十分重要，它增長了便捷性和靈活性。

工科生最愛的映射矩陣

​書中由海戰做爲引子，介紹了設計過程當中的四個域（Domain）：

• CNs：Customer Needs，客戶域，就是客戶描述的一大堆天然語言也說不清楚的事情，什麼高端大氣上檔次之類的東西。
• FRs：Functional Requirements，功能域，從 CNs 域到 FRs 域的變換，就是把客戶漫無邊際的需求翻譯成一些可定量的參數，好比戰艦控制系統的 FR 是控制航行方向和控制開炮方向。
• DPs：Design Parameters，設計參數，或者叫物理域，實現 FRs 的物理參數，好比航向控制器和炮塔控制器。
• PVs：Process Variables，過程變量，或者叫過程域，是描述實現功能過程當中涉及的過程變量。

相鄰域之間的映射，能夠當作目標（作什麼？）和手段（怎樣作？）之間的對應關係。設計過程是相鄰域中特徵向量之間映射和轉換過程。

例如，用戶域元素映射到功能域的過程，其實是將用戶需求轉變成產品功能要素的過程，即產品規劃；功能域向物理域的映射過程是產品的設計過程；從物理域到過程域的映射則可當作「加工產品」的過程。

其中最爲重要的是FRs（功能需求）到DPs（設計參數）的映射，這也是咱們軟件開發過程當中最長接觸的步驟，需求文檔有了，如何進行代碼設計並實現。

書中以矩陣向量的方式講述了 FRs (功能需求) 和 DPs (設計參數) 的映射關係，也就是上圖中由 A 變量組成的矩陣表明着 FPs 到 DPs 的映射。不一樣的矩陣表明着不一樣的映射關係，其實咱們不須要關心矩陣各個位置的具體值如何計算，只需簡化的瞭解若是 FP 和 DP 有關聯，則矩陣相應位置上的值爲1，不然爲0。

好比說小小號上的狀況，有兩個功能須要：FR1（調整航向）和FR2（調整開炮方向）；以及兩個設計參數：DP1（船舵）和DP2（旋轉炮塔）

其中轉動船舵的時候，船會轉向，因此A11這裏是X，同時船身上的炮塔也跟着船一塊兒轉向，因此也影響開炮方向FR2，所以A21也是X。 而在旋轉炮塔的時候，不影響船的航行方向，因此A12這裏是0。

好的設計？

因此，基於上邊這個映射矩陣，好的設計應該有兩個特色：

• 首先FRs（功能需求）的數量N，應當等於DPs (設計參數）的數量M。
• 每個FR（功能需求）與且只與一個DP（設計參數）相互關聯。

也就是說映射矩陣是一個對角矩陣，對角線上有值，其餘位置都是0。《程序員修煉之道》中也說起了相似的思想，也就是正交性一節。那一節的提示是消除無關事務之間的影響，正好和這裏映射矩陣是對角矩陣不謀而合。當映射舉證是對角矩陣時，說明 FR 和 DP 一一對應，不會有交叉影響。當某一個 FR也就是需求發生變動時，只須要修改一個DP。

固然對角矩陣屬於比較理想的狀況，書中也羅列了一些其餘類型的映射矩陣。

其中最差的狀況是 FRs（功能需求）的數量N，小於 DPs(設計參數）的數量M。也就是大大號中的情景：它有兩個功能需求，FR1 調整航向
和FR2 調整開炮方向，但只有一個DP1 船舵。因此它的映射矩陣以下圖所示。

書中還繼續講解了矩陣分解的知識，也就是對應了需求功能點細分到軟件詳細設計細分等部分的內容，有興趣的小夥伴能夠本身去看看。

總結

因此書中最後給出兩個千米：

• 獨立公理（功能獨立性公理)
• 信息公理（信息量最少公理）

這不正是軟件設計中常常說起的鬆耦合和高內聚嘛。模塊相互獨立互不影響就是鬆耦合，最小化信息量就是不對外暴露過多信息，也就是高內聚或者信息隱藏。

個人博客，歡迎來玩