前几天看到了一个博客，推荐了《公理设计》一书，还有其相关的文档以及视频。简单了解了一下，增深了一些对软件设计的理解，特此也推荐给大家。 公理设计理论将设计建立在科学公理、定理和推论的基础上，由麻省理工学院教授 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 船舵。所以它的映射矩阵如下图所示。 书中还继续讲解了矩阵分解的知识，也就是对应了需求功能点细分到软件详细设计细分等部分的内容，有兴趣的小伙伴可以自己去看看。 总结 所以书中最后给出两个公里： 独立公理（功能独立性公理) 信息公理（信息量最少公理） 这不正是软件设计中经常提及的松耦合和高内聚嘛。模块相互独立互不影响就是松耦合，最小化信息量就是不对外暴露过多信息，也就是高内聚或者信息隐藏。 我的博客，欢迎来玩 标签: 软件设计 好文要顶 关注我 收藏该文 程序员历小冰 关注 - 0 粉丝 - 0 +加关注 2 0 « 上一篇： 详解 Redis 内存管理机制和实现 posted @ 2019-11-02 22:03 程序员历小冰 阅读(156) 评论(2) 编辑 收藏 评论列表 #1楼 2019-11-03 23:11 牛腩 支持支持 支持(0) 反对(0) #2楼 [楼主] 2019-11-05 19:13 程序员历小冰 @ 牛腩 谢谢 支持(0) 反对(0) 刷新评论刷新页面返回顶部 注册用户登录后才能发表评论，请 登录 或 注册， 访问 网站首页。 【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库 【活动】京东云服务器_云主机低于1折，低价高性能产品备战双11 【推荐】天翼云双十一提前开抢，1核1G云主机3个月仅需59元 【推荐】阿里云双11冰点钜惠，热门产品低至一折等你来抢！ 【福利】个推四大热门移动开发SDK全部免费用一年，限时抢！ 相关博文： · 面向对象软件设计的“开—闭”原则 · 软件设计过程经验谈 之 如何做好领域模型设计 · 《软件设计师要思考那些问题》 · 面向对象软件设计原则（四） —— 包的设计原则 · 软件设计是怎样炼成的（4）——软件设计的“大道理” » 更多推荐... 最新 IT 新闻: · 你们这么冤枉方便面，考虑过方便面的感受吗？ · 曾经是热带地区的波兰出土有1.5亿年历史的海怪化石 · 国行版三星Fold折叠屏手机11月8日上市 售价15999元 · SpaceX拟11日发射第二批星链卫星 还用上二手整流罩 · Facebook又爆隐私丑闻：100多第三方开发者违规访问用户数据 » 更多新闻... 公告 昵称： 程序员历小冰 园龄： 1个月 粉丝： 0 关注： 0 +加关注 < 2019年11月 > 日 一 二 三 四 五 六 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5 6 7 搜索 常用链接 我的随笔 我的评论 我的参与 最新评论 我的标签 我的标签 redis(4) 程序员(1) 工具(1) 软件设计(1) linux(1) 随笔档案 2019年11月(1) 2019年10月(4) 2019年9月(1) 最新评论 1. Re:公理设计-由奇怪海战引发的软件设计思考 @ 牛腩谢谢... --程序员历小冰 2. Re:公理设计-由奇怪海战引发的软件设计思考 支持支持 --牛腩 3. Re:Redis 复制过程详解 --程序员历小冰 4. Re:Redis 复制过程详解 --凛冬至弋 阅读排行榜 1. 一文了解 Redis 内存监控和内存消耗(243) 2. 详解 Redis 内存管理机制和实现(238) 3. Redis 复制过程详解(173) 4. 公理设计-由奇怪海战引发的软件设计思考(157) 5. Redis AOF 持久化详解(91) 评论排行榜 1. Redis 复制过程详解(2) 2. 公理设计-由奇怪海战引发的软件设计思考(2) 推荐排行榜 1. 公理设计-由奇怪海战引发的软件设计思考(2) 2. 详解 Redis 内存https://www.cnblogs.com/remcarpediem/p/11784470.html