公理设计:由奇怪海战引发的软件设计思考

前几天看到了一个博客，推荐了《公理设计》一书，还有其相关的文档以及视频。简单了解了一下，增深了一些对软件设计的理解，特此也推荐给大家。

公理设计理论将设计建立在科学公理、定理和推论的基础上，由麻省理工学院教授 Nam. P. Suh 领导的研究小组于 1978 年提出，适用于各种类别的设计活动。软件设计当然也属于一类工程设计过程，下面我们就来看一下两者的关联。

奇怪的海战

首先从1862年11月13日的一场海战讲起。这场海战“标志着蒸汽动力铁甲舰新时代的到来。为了便于理解，我这里对舰船名称进行了修改，想了解的朋友可以百度 U.S.S. Monitor battles C.S.S. Virginia.

南方叛军的大大 战舰，体型庞大，非常凶悍。已经击沉了两艘联邦军舰。北方政府军则只派出小小 ，一艘非常小，火力也小多的军舰。

?书中由海战作为引子，介绍了设计过程中的四个域（Domain）：

• CNs：Customer Needs，客户域，就是客户描述的一大堆自然语言也说不清楚的事情，什么高端大气上档次之类的东西。
• FRs：Functional Requirements，功能域，从 CNs 域到 FRs 域的变换，就是把客户漫无边际的需求翻译成一些可定量的参数，比如战舰控制系统的 FR 是控制航行方向和控制开炮方向。
• DPs：Design Parameters，设计参数，或者叫物理域，实现 FRs 的物理参数，比如航向控制器和炮塔控制器。
• PVs：Process Variables，过程变量，或者叫过程域，是描述实现功能过程中涉及的过程变量。

相邻域之间的映射，可以看成目标（做什么手段（怎样做间的对应关系。设计过程是相邻域中特征向量之间映射和转换过程。

例如，用户域元素映射到功能域的过程，实际上是将用户需求转变成产品功能要素的过程，即产品规划；功能域向物理域的映射过程是产品的设计过程；从物理域到过程域的映射则可看成“加工产品”的过程。

其中最为重要的是FRs（功能需求）到DPs（设计参数）的映射，这也是我们软件开发过程中最长接触的步骤，需求文档有了，如何进行代码设计并实现。

其中转动船舵的时候，船会转向，所以A11这里是X，同时船身上的炮塔也跟着船一起转向，所以也影响开炮方向FR2，因此A21也是X。 而在旋转炮塔的时候，不影响船的航行方向，所以A12这里是0。

好的设计h3>

所以，基于上边这个映射矩阵，好的设计应该有两个特点：

• 首先FRs（功能需求）的数量N，应当等于DPs (设计参数）的数量M。
• 每一个FR（功能需求）与且只与一个DP（设计参数）相互关联。

也就是说映射矩阵是一个对角矩阵，对角线上有值，其他位置都是0。《程序员修炼之道》中也提及了类似的思想，也就是正交性一节。那一节的提示是消除无关事务之间的影响，正好和这里映射矩阵是对角矩阵不谋而合。当映射举证是对角矩阵时，说明 FR 和 DP 一一对应，不会有交叉影响。当某一个 FR也就是需求发生变更时，只需要修改一个DP。

当然对角矩阵属于比较理想的情况，书中也罗列了一些其他类型的映射矩阵。

书中还继续讲解了矩阵分解的知识，也就是对应了需求功能点细分到软件详细设计细分等部分的内容，有兴趣的小伙伴可以自己去看看。

总结

所以书中最后给出两个公里：

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

这不正是软件设计中经常提及的松耦合和高内聚嘛。模块相互独立互不影响就是松耦合，最小化信息量就是不对外暴露过多信息，也就是高内聚或者信息隐藏。

我的博客，欢迎来玩