摘要：

大纲：

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

6.规划系统骨架——架构设计

6.5 逐步拆解架构设计
需求驱动设计 有这样的一句话：不以结婚为目的的谈恋爱是耍流氓！ 这句话与软件设计有什么关系呢关系呢！因为有另外这样的一句话：不以解决需求为目的软件设计就是耍流氓！ 所以如果不想被人家说你耍流氓，你需要了解需求，需要“需求驱动”地思考设计问题。
前文我们从需求中发现了四个设计点，一起来回顾一下： 1）用例图中提到，员工可以通过移动设备提出请假或外出申请，领导可以及时收到审批的提醒。那么我们应该如何设计“即时了解”和“及时收到提醒”呢方案可能有：短信提醒、邮件提醒、或者两者同时提醒。 2）需求中要求员工可以通过移动设备提出申请，领导也可以通过移动设备完成审批要思考，为什么需要移动设备完成这些工作呢情况下才需要通过移动设备完成这些工作呢的解决方案是怎样呢短信、手机上 ，还是通过手机的APP来搞定 3）请假申请和审批流程，跟流程相关的都可以扯到“工作流”。工作流可以是一个很“恐怖”的话题，你打算做一个”死”的工作流，“半死不活”的工作流，还是“全活”的工作流呢 你打算从零开始做，还是买一个工作流引擎呢span> 4）权限要做成重用已经是有一定难度的，同时还需要考虑与工作流的结合，还要考虑工作流也可以做成重用，难度很高啊！那到底要不要考虑做成重用，并且权限和工作流能结合起来呢
补充说明一下工作流：1）死的工作流：就是代码写死的（hard code），数据库设计也是死的，流程或表单有任何变化，都可能需要改代码和数据库设计。 2）半死不活的工作流：部分地方写死，部分地方是灵活的，能适应部分需求变化。 3）全活的工作流：代码和数据库设计等都是灵活的，能基本适应流程及表单的变化，不需要修改代码或数据库设计，只要配置一下就可以搞定。 没有任何工作流技术积累的情况下，要做到“全活的工作流”是很高难度的，一般不要在当前项目中就定下这样的设计目标，基本是实现不了的。可以分阶段来做，先写“死”，然后“半死不活”，最后才追求“全活”。
初步架构设计（第一层拆解） 我们再次回顾一下，什么才是优秀的设计 我在前文中提到，一个优秀的设计应该具备以下特点：

1）优秀的设计都是需求驱动的，不熟悉需求就做出来的设计是不靠谱的；
2）优秀的设计应该是当前团队能理解能实现的，太超前的设计项目团队做不出来，这个设计只能是摆设；
3）优秀的设计应充分考虑当前各种限制条件，适当做出平衡，能保证达成项目的目标：
4）优秀的设计能尽量降低项目的整体工作量，让整个项目更加可控。

我们尝试一下，尽量按上述标准来完成这个设计吧！

图6.10 更多的更具体的设计问题
图6.10与图6.9的区别就是多了黄色的部分，请思考这三个问题： 1）权限设置的UI如何考虑
用户管理、权限管理的UI可考虑设计成可重用的。
界面可以是独立的，也可以“嵌入”到别的系统中。
2）工作流如何设计
还需要对工作流进行进一步的抽象。
考虑清楚工作流的对外接口。
考虑清楚数据库设计。
3）图形定义客户端软件如何设计
图形平台自主开发，还是利用第三方的
数据如何保存到DB中
除了上述这些问题和思考，还会有更多的其他问题，软件设计是充满挑战的工作！
设计初期的问题可能比较朦胧比较大，但随着设计的深入，问题会越来越多，问题也会越来越具体。有时候你会觉得怎么越深入设计，发现的问题越多，这是正常现象，而且是好事！如果没有发现问题，这往往不是真的没有问题了，而是我们 不具备发现问题的能力了，这是相当可怕的，要小心留意不可轻敌噢！
图6.6后我们连续进行了多步的设计拆解，这里小结一下： 1）系统需要开发什么软件和数据库等，这些是第一次对系统各部分的拆分，姑且这叫”第一层的拆解“，接下来需要继续拆解。 2）继续拆解时可参考分层架构，但需要拆分得更加具体，不要犯”放之四海而皆准“的毛病。这个层次的拆解，姑且叫“第二层的拆解”。 3）除了规划好内部各部分的关系，还需要规划内部的各部分与外部之间的关系。 4）在拆解的过程中，问题会越来越多，也会越来越细，这是正常现象，也是好现象。 5）拆解过程中也可能会发现之前初步架构设计中不合理或遗漏的地方，请马上调整；有时候甚至会发现之前的设计完全不对，那么就要有勇气推翻重做。 6）“第二层的的拆解”结果有可能是组件（Component）、代码包、某个分层等等，可能是“物理分拆”也可能是“逻辑分拆”。那么 “第二层的拆解”要多细才合适呢很难有固定的标准，给一个简单标准作为参考：如果再拆解下去下一步的拆解就到类了，那么就可以认为目前的拆解粒度比较合适了。细化到类的拆解，可以在模块设计（详细设计）中再进一步考虑。
说明一下“物理分拆”和“逻辑分拆”： 物理分拆： 物理分拆就是物理上是独立的部分，有可能是exe、dll、数据库文件等。图6.6中将系统分拆为5部分，分别是Web Application、流程定义用的客户端软件以及三个数据库，这就是物理分拆；我们对Web Applicationi继续分拆时，图6.8中的日历控件是物理分拆，这个控件将通过二进制的方式供程序其他部分调用，而这个控件将来也可以供其他系统使用。 逻辑分拆：代码包、某个分层这些往往是逻辑分拆，物理上它们不会编译成单独的一部分，而是被整体编译进软件当中。
“第二层拆解”的目的除了更加方便我们设计出系统，另外一个重要目的就是做系统的重用设计。如果是“物理分拆”，就可以做到二进制重用；如果是“逻辑分拆”，那么只能做到源代码重用。这些重用不仅仅为当前软件服务，还可以为将来及其他软件服务。

6.7 架构设计小结
架构设计是高难度、高技术含量的活，我觉得很难写出一本秘籍，你看了后就能应对大部分软件的架构设计。如果我们不精通业务，不精通技术，没有丰富的设计经验，很多设计我们将会束手无策。
小结一下分布式系统的架构设计要点，单机系统也可以参考： 1）我们的系统大部分会涉及到多个客户端及服务器，我们需要思考我们的系统需要怎样的客户端及服务器，思考这些设备上面需要安装怎样的操作系统、平台、软件等，思考这些设备需要怎样的硬件配置，如CPU、内存、硬盘大小等等。
2）我们需要思考这些客户端及服务器之间的物理联系方式，例如：是局域 方式、互联 ，还是两者都支持TTP或是HTTPS。
4）思考系统需要开发什么软件和数据库等，这些是第一次对系统各部分的拆分，姑且这叫”第一层的拆解“。
5）继续拆解时可参考分层架构，但需要拆分得更加具体，不要犯”放之四海而皆准“的毛病。这个层次的拆解，姑且叫“第二层的拆解”。
6）除了规划好内部各部分的关系，还需要规划内部的各部分与外部之间的关系。
7）在拆解的过程中，问题会越来越多，也会越来越细，这是正常现象，也是好现象。
8）拆解过程中也可能会发现之前初步架构设计中不合理或遗漏的地方，请马上调整；有时候甚至会发现之前的设计完全不对，那么就要有勇气推翻重做。
9）“第二层的的拆解”结果有可能是组件（Component）、代码包、某个分层等等，可能是“物理分拆”也可能是“逻辑分拆”。那么“第二层的拆解”要多细才合适呢很难有固定的标准，给一个简单标准作为参考：如果再拆解下去下一步的拆解就到类了，那么就可以认为目前的拆解粒度比较合适了。细化到类的拆解，可以在模块设计（详细设计）中再进一步考虑。

软件架构设计博大精深，上述仅仅是一些规律的简单总结，希望对你能有一点点帮助。

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

软件研发管理资深顾问

CMMI首席专家

www.umlonline.org创办人