公理設計理論將設計建立在科學公理、定理和推論的基礎上，由麻省理工學院教授 nam. p. suh 領導的研究小組於 1978 年提出，適用於各種類別的設計活動。軟體設計當然也屬於一類工程設計過程，下面我們就來看一下兩者的關聯。
南方叛軍的大大號戰艦，體型龐大，非常兇悍。已經擊沉了兩艘聯邦**。北方**軍則只派出小小號，一艘非常小，火力也小多的**。
大大號顧名思義，它船體特別的大，但是都是固定炮塔，兩側和首尾有很多門炮。而小小號雖然小，卻有乙個可以旋轉的炮台。
我們可以理解為一條戰艦需要有兩個基礎功能：調整航行方向和調整炮擊方向。
對於大大號，這兩個功能需求是耦合 couple 的，要改變炮擊方向，就需要將船隻轉向。而對於小小號，這兩個功能需求則是解耦合 decouple 的，航行方向與炮擊方向無關，炮擊方向可以獨立調整。
於是小小號一直盡量守在大大號的射擊死角攻擊，而大大號雖然火力猛烈則必須不斷通過改變航線來調整炮擊方向，於是就不斷繞圈。這兩條船打了4個小時，大大號不得不撤退了，小小號獲得了勝利。
由此可見功能之間的解耦十分重要，它增加了便捷性和靈活性。
書中由海戰作為引子，介紹了設計過程中的四個域（domain）：
相鄰域之間的對映，可以看成目標（做什麼？）和手段（怎樣做？）之間的對應關係。設計過程是相鄰域中特徵向量之間對映和轉換過程。
例如，使用者域元素對映到功能域的過程，實際上是將使用者需求轉變成產品功能要素的過程，即產品規劃；功能域向物理域的對映過程是產品的設計過程；從物理域到過程域的對映則可看成「加工產品」的過程。
其中最為重要的是frs（功能需求）到dps（設計引數）的對映，這也是我們軟體開發過程中最長接觸的步驟，需求文件有了，如何進行**設計並實現。
書中以矩陣向量的方式講述了 frs (功能需求) 和 dps (設計引數) 的對映關係，也就是上圖中由 a 變數組成的矩陣代表著 fps 到 dps 的對映。不同的矩陣代表著不同的對映關係，其實我們不需要關心矩陣各個位置的具體值如何計算，只需簡化的了解如果 fp 和 dp 有關聯，則矩陣相應位置上的值為1，否則為0。
比如說小小號上的情況，有兩個功能需要：fr1（調整航向）和fr2（調整開炮方向）；以及兩個設計引數：dp1（船舵）和dp2（旋轉炮塔）
其中轉動船舵的時候，船會轉向，所以a11這裡是x，同時船身上的炮塔也跟著船一起轉向，所以也影響開炮方向fr2，因此a21也是x。 而在旋轉炮塔的時候，不影響船的航行方向，所以a12這裡是0。
所以，基於上邊這個對映矩陣，好的設計應該有兩個特點：
也就是說對映矩陣是乙個對角矩陣，對角線上有值，其他位置都是0。《程式設計師修煉之道》中也提及了類似的思想，也就是正交性一節。那一節的提示是消除無關事務之間的影響，正好和這裡對映矩陣是對角矩陣不謀而合。當對映舉證是對角矩陣時，說明 fr 和 dp 一一對應，不會有交叉影響。當某乙個 fr也就是需求發生變更時，只需要修改乙個dp。
當然對角矩陣屬於比較理想的情況，書中也羅列了一些其他型別的對映矩陣。
其中最差的情況是 frs（功能需求）的數量n，小於 dps(設計引數）的數量m。也就是大大號中的情景：它有兩個功能需求，fr1 調整航向
和fr2 調整開炮方向，但只有乙個dp1 船舵。所以它的對映矩陣如下圖所示。
書中還繼續講解了矩陣分解的知識，也就是對應了需求功能點細分到軟體詳細設計細分等部分的內容，有興趣的小夥伴可以自己去看看。
所以書中最後給出兩個公里：
這不正是軟體設計中經常提及的松耦合和高內聚嘛。模組相互獨立互不影響就是松耦合，最小化資訊量就是不對外暴露過多資訊，也就是高內聚或者資訊隱藏。
我的部落格，歡迎來玩
軟體設計的真諦
假設我們身邊的一切都是用製造材料加以描述的 空調 不是 空調 而是 由金屬和塑料做成的物體 書 不是 書 而是 由纖維和墨做成的物體 溝通時我們也不用 空調 和 書 這樣的詞彙，而是 金屬和塑料做成的物體 和 纖維和墨做成的物體 可以想象大腦在面對這些資訊時會讓我們覺得多麼的痛苦，顯然這樣的事情在現...
軟體設計的思考
trade off 資源限制 人力 空間 時間 最近有幸參與到新的專案設計開發中，結合工程實踐中的經驗與教訓發掘可從資源調配的角度來思考架構設計問題。工程中的軟體設計是什麼？即在 資源有限的條件下，控制成本並作出 資源整合效率最大化的配置的設計。那麼結合計算機系統可從以下幾個關鍵點考慮 1.人力資源...
軟體設計的作用
1.驗證和補充需求。注意 補充的需求，需要重新確認。為什麼會在設計時還要搞需求工作呢？原因是，需求分析人員是從使用者的角度來考慮問題，給出的是使用者直接想要的需求部分，而對於和使用者關係不是很緊密的部分，可能並沒有給出完整的方案 使用者對軟體的主要使用過程比較簡單，但由此而引起的相關處理過程比較複雜...