软件设计是怎样炼成的（4）——软件设计的“大道理”

摘要：

十几年前刚毕业不久，我从事第一份软件开发的工做，要完成一个项目，但没有任何软件设计的思路，因而请教个人老板。个人老板给了我两种思路：1）先假设软件已经作出来了，想好软件的外在表现，由此倒推软件的实现方法；2）思考程序的数据结构，先设计数据库，而后再搭建软件的上层建筑。老板给了我很大的启发，随着工做的开展，后来我又发现了第3种设计的思路。本文将为你分享三种软件设计的思路：1）由顶而下；2）由底而上；3）由中间到上下。

 

大纲：

1.什么是优秀的设计？
2.优秀的设计能节省项目工做量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感受好才是真的好——用户体验设计
10.持续提高设计水平

 

本文章是系列文章之一，若是你尚未看过以前的文章，建议先看完前面的文章再看本篇，这样效果更好。

 

 

5.软件设计的“大道理”

 

 

5.1 个人第一次商业软件的设计经验

 

1999年刚毕业不久，我从事第一份软件开发工做，当时要负责一个大型桌面软件，但不知道应该如何开展软件设计工做，因而向老板请教。老板也仅仅是年长我几岁，不过公司的核心产品是老板开发的，老板说他其实也没有什么系统的方法，不过有两种思路供我参考：

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

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

 

 

5.2 N层架构是怎么回事？

 

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

 

图5.1 四层架构

 

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

上图表示的意思以下：

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

 

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

“依赖”能够是如下状况之一：

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

 

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

1）表现层如何将数据传递给逻辑层？

2）逻辑层如何将数据传递给数据访问层？
3）数据访问层如何将数据传递给数据库？

 

一般咱们不会这么老土经过一大堆参数来传递层与层之间的数据，一般咱们会将数据装在实体类中，经过实体类来传递数据。因此图5.1能够进一步表示为图5.2：

图5.2 四层架构与实体类

 

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

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

 

 

5.3 “由顶而下”的设计思路

 

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

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

请看下图：

图5.3 由顶而下的设计思路

 

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

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

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

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

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

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

 

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

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

 

 

5.4 “由底而上”的设计思路

 

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

图5.4：由底而上的设计思路

 

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

 

 

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

 

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

 

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

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

若是你遇到这样的情况，你会怎么办呢？能不能按需求变动来处理呢？只有客户愿意付钱，咱们就愿意干！但客户愿意付钱吗？这但是要付推翻重作的钱啊！！

 

最后咱们的领导决定免费重作，领导决定免费重作的缘由是：

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

 

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

图5.5 由中间到上下的设计思路

 

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

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

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

 

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

图5.6 由中间到上下的系统架构

 

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

 

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

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

1）系统将不能充分利用数据库的特性，通常会禁止在数据库中写存储过程、触发器、甚至是视图等，程序的的性能其实会下降；
2）由于不能充分利用数据库自己的特性，因此大部分甚至是所有的业务逻辑只能靠程序搞定，这样其实增长了程序的复杂度和工做量。

 

因此每种设计方法都是有针对性的，都很难作到十全十美，通常只能针对主要矛盾作出一些取舍。

 

 

5.6 小结

 

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

 

 

本文是系列文章的第4篇，要作软件设计师一点都不简单啊，请留意后续文章！

 

若是本文对你有帮助，麻烦点一下“推荐”啦，谢谢！

 

 

 

做者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》做者

软件知识原创基地创办人