软件设计的两种主要方法（软件设计是怎样炼成的）

刚毕业不久，我从事第一份软件开发的工作，要完成一个项目，但没有任何软件设计的思路，于是请教我的老板。我的老板给了我两种思路：1）先假设软件已经做出来了，想好软件的外在表现，由此倒推软件的实现方法；2）思考程序的数据结构，先设计数据库，然后再搭建软件的上层建筑。老板给了我很大的启发，随着工作的开展，后来我又发现了第3种设计的思路。本文将为你分享三种软件设计的思路：1）由顶而下；2）由底而上；3）由中间到上下。我从事第一份软件开发工作，当时要负责一个大型桌面软件，但不知道应该如何开展软件设计工作，于是向老板请教。老板也仅仅是年长我几岁，不过公司的核心产品是老板开发的，老板说他其实也没有什么系统的方法，不过有两种思路供我参考：

1）先假设软件已经做出来了，想好软件的外在表现，由此倒推软件的实现方法；2）思考程序的数据结构，先设计数据库，然后再搭建软件的上层建筑。

上述的两种软件设计思路，相信很多有软件设计经验的朋友都能体会到。后来我又体会到第三种的设计思路，后文将会为你分享我对这三种设计思路的一些体会。

N层架构是怎么回事？

这三种设计思路都与软件系统的N层架构有关系，我们以常见的四层架构为例子，请看图：

四层架构

这个是UML的包图（Package Diagram），图中好像文件夹的那个东西就是“包”，包与包之间的虚线箭头表示的是依赖关系。

上图表示的意思如下：

1）四层架构的四层，分别是指：表现层、逻辑层、数据访问层和数据层；2）表现层依赖于逻辑层，逻辑层依赖于数据访问层，数据访问层依赖于数据层。

那“依赖”是什么意思呢？

“依赖”可以是以下情况之一：

1）A需要调用B的方法，则A依赖于B；2）A的方法中某些参数的类型是B，则A依赖于B；3）A的某些方法的返回值类型时B，则A依赖于B。

这样我们大概了解了四层架构是怎么回事了，但我们还会有以下问题：

1）表现层如何将数据传递给逻辑层？2）逻辑层如何将数据传递给数据访问层？3）数据访问层如何将数据传递给数据库？通常我们不会这么老土通过一大堆参数来传递层与层之间的数据，通常我们会将数据装在实体类中，通过实体类来传递数据。所以

四层架构与实体类

补充说明一下什么实体类？

实体类通常是一个只有属性没有方法的类，通常我们会将某一业务对象的数据装在一个实体类中。例如：某请假单实体类，该类可能有请假人姓名、请假起止时间、请假类别和请假事由等属性。

“由顶而下”的设计思路

看了上图你大概就清楚了什么是软件的“顶”？什么是软件的“ 底”？“顶”就是表现层，“底”就是数据层。那么“由顶而下”的设计思路，其实就是先想清楚软件的表现层，然后再思考逻辑层、数据访问层、数据层的实现。

前文我们提到要“需求驱动设计”，这个说法有点笼统，我们需要进一步思考：“什么需求”驱动“什么设计”？

请看下图：

由顶而下的设计思路这是UML的活动图，横线将图分成了上下两部分，上部分是需求分析，下部分回答了“什么需求”驱动“什么设计”的问题。

说明一下：“需求驱动”及横线不是UML图的标准语法，图加上这些非UML元素是为了更好地表达问题。

“需求分析”这个活动有三种工作产品，分别是：

1）用例/用户故事；2）业务流程图；3）业务概念图。

你可以理解为上述三种工作产品是“需求分析”这个活动的“输出”。

“用例/用户故事”和“业务流程图”是“规划界面”这个活动的“输入”；类似，“业务流程图”和“业务概念图”是“设计逻辑层”这个活动的“输入”。其他就不再多解释了，你应该可以看懂这个图了，后续几个图的语法类似，也不再解释了。

上述是对上图语法及表达意思的基本解释，这里再稍微小结一下：

1）分析需求是设计的开始，我们还需要将需求至少分解为三部分：软件要满足的功能（用例/用户故事）、业务流程（业务流程图）、业务概念（业务概念图）三部分；2）设计不同的层时，主要依赖的需求是不太一样的，上述分解的三部分需求对不同的层设计提出了不同的要求。比方说：设计数据库时主要是根据业务概念来设计的，规划界面时主要根据软件需要满足的功能点，还有业务流程来设计。

“由底而上”的设计思路

经过前面的铺垫后，这个“由底而上”的设计思路，相信你一看图就可以懂了。

由底而上的设计思路

这个图也分成了上下两部分，上部分的内容其实和上图是一样的，只是左右顺序不太一样而已。

“由中间到上下”的设计思路

这种设计思路是我从事软件研发工作若干年后才认识的，当时是因为项目出现了特殊状况，为了应对这样的状况而采取的一种设计方法。

案例分享：客户要改SQLServer为Oracle

签订合同时，我们和客户约定的项目技术架构是.net SQLServer，当时客户没有反对，我们就按这样的技术架构完成了系统，并且部署上线。但是不久客户居然提出了这样的要求：要求我们使用Oracle数据库，而不能用SQLServer数据库！我们通常是按照“由底而上”的思路来设计软件的，如果数据库要更换，基本上整个软件就等于重做！

如果你遇到这样的状况，你会怎么办呢？能不能按需求变更来处理呢？只有客户愿意付钱，我们就愿意干！但客户愿意付钱吗？这可是要付推翻重做的钱啊！！

最后我们的领导决定免费重做，领导决定免费重做的原因是：

这是公司的一个核心项目，我们期望这个项目将来能产品化，能持续赚钱。但我们技术选型主要是根据我们当前的技术情况来决定的，没有充分考虑客户的情况。客户是某重要行业的企业单位，单位体制内的所有企业基本都是用Oracle的，但我们选择“视而不见”，选择了我们最熟悉的SQLServer来开发系统，其实迟早是要遇到问题的。客户除了用我们的系统，还会用其他更大型的更重要的系统，客户的其他系统基本上都是使用Oracle数据库的。所以如果我们要在这个客户领域打开市场，将项目做好，就有必要将系统改造为Oracle数据库。

但是我们已经有部分客户使用了我们的基于SQLServer的系统了，将来也有可能会有部分客户要求用SQLServer，所以我们领导决心改造软件的架构，要让我们的软件可以支持SQLServer，也可以支持Oracle！于是我们按照“由中间到上下”的思路，重新打造了软件架构，请看下图：

由中间到上下的设计思路

这个图也分成了上下两部分，上面部分和前面的图内容也是一样的，但下面部分就很不一样了，而且可能比较难理解。

“由中间到上下”基本的思路是这样的：

1）先不考虑表现层，也不考虑数据层；2）先定义实体类和数据层接口；3）接口定义好后，往上可以设计逻辑层和表现层，往下可以设计数据层接口的实现和设计数据库。

按照这样的设计思路做出来的软件架构，应该是这样的：

由中间到上下的系统架构

图中见到数据操作层接口有两种不同的数据库实现，分别是SQLServer和Oracle，如果要考虑第三种数据库，那么再增加一个实现就搞定了，而系统的上层建筑（表现层、逻辑层）不需要改变。

这样的设计方式看上去很酷，是不是应该所有系统都要考虑用这样的方式来打造呢？

不是滴，这样的设计方式是有缺点的：

1）系统将不能充分利用数据库的特性，一般会禁止在数据库中写存储过程、触发器、甚至是视图等，程序的的性能其实会降低；2）因为不能充分利用数据库本身的特性，所以大部分甚至是全部的业务逻辑只能靠程序搞定，这样其实增加了程序的复杂度和工作量。

所以每种设计方法都是有针对性的，都很难做到十全十美，一般只能针对主要矛盾做出一些取舍。

小结

如果系统没有多数据库的要求，我会比较建议你用“由顶而下 由底而上”的设计思路；如果程序需要支持多数据库，那么可能考虑“由中间到上下”。上面介绍的三种设计思路，其实在实际工作中我们往往不会只选其一，往往是结合了多种思路的。不要局限自己的思路，软件设计的可能性是无穷的。

,