第2章 设 计 体 系
第1章说过，要想做工程化的设计，就必须有一套设计体系。那么本章我们就来看看能不能为IT软件的开发工作构建出一套具有工程学水准的设计体系，并且看看我们是否值得去构建这样的体系。
本章分为三个部分。2.1节从下至上检视整个设计体系，以解释我们为什么应该建立该体系。接下来的2.2节～2.7节，用从上至下的方式来观察这套体系，使大家对设计之中的信息流动情况有所了解。把这套体系中的所有部件都展示出来之后，笔者会在2.8节之中回到本章开头所提出的那个问题上面。最后的2.9节是对本章所做的小结。
2.1 为什么应该建立设计体系
首先，我们从实现设计（implementation design）谈起，实现设计指的就是编程。
编程是一项设计活动。尽管并不是所有的人都同意这个说法，但从笔者自己的编程经历来看，确实如此。刚开始编程的时候，我们会提出一个设计猜想，这通常叫做程序模式。接下来，我们会编写代码来细化这个猜想，并且通过编译、代码检查及测试等手段来进行分析。然而，从第1章的图1-6中可以看出，程序本身并不能代表整个设计，至少对于业解决方案之中的程序来说，是这样的。
https://yqfile.alicdn.com/587baee04ce90231bc4e13e878dfe5f0d11b11d7.png" >
当今的大多数程序都搭建在框架之上。图2-1演示了框架这一概念。
框架的理念是：设定一套骨干代码（skeletal code），其中可以放置各种代码片段（code segment），这些片段用来实现用户所需的功能，而骨干代码，则会把多个代码片段整合起来，并提供一些常用的系统设施，如安全保护、消息传递以及系统管理等。
比如，有很多框架都支持MVC（模型—视图—控制器）模式。该模式的基本思路是将输入交给控制器（controller）去处理，而控制器则会通过模型（model）来访问数据，并且通过视图（view）把数据展示出来。我们为模型、视图及控制器分别编写代码，然后这些代码会插入MVC框架之中。
框架通常由软件厂商所提供。很多制作应用程序开发软件的大型厂商，都有自己的框架，而且通常不止一套，此外，我们还可以找到很多开源的框架。不过，应用程序的开发者需要根据自身的需求，来对厂商所提供的框架进行扩展。对于多层应用程序（multitier application），尤其需要这样做，因为大多数厂商所提供的框架，都位于一台计算机的范围之内。
开发框架的时候，我们可以把程序员必须要完成的工作分成三种：框架本身的开发、功能代码的开发以及常用工具的开发。此处的常用工具是指一些以编程手段实现出来的功能，例如，发送电子邮件、把一系列数据转化成一份PDF文件，以及回报错误等。图2-2演示了这三种编程工作。
https://yqfile.alicdn.com/ffc2ec5cb93644aecc0dcf4223d7699bcaba1c88.png" >
了解上述知识之后，我们现在假设自己是一名程序员，并且需要编写某个新的功能。那么，在开始写代码之前，应该先知道下列四个方面：
用户界面的设计（user interface design）：用户界面的布局、用户输入的内容、程序需要对每项输入所做的处理，以及程序需要输出的显示内容。
数据库的设计（database design）：数据库或者非数据库的文件所具备的结构。
集成设计（integration design）：要发送给其他应用程序的信息（如果有），或是需要从其他应用程序那里接收的信息（如果有）。
技术设计（technical design）：选定自己所要使用的框架和软件，并且设计一些公用的代码，使框架、管理机制和操作机制能够运作得更好。
就这四个方面来说，用户界面的设计、数据库的设计，以及技术设计，在整个设计体系里面的位置，处在实现设计之上。至于集成设计的位置，我们稍后再谈。
上述三种设计，需要由用户界面设计者、数据库设计者以及技术设计者来承担。必须指出的是，这三种设计者说的是三种角色，而未必是三个不同的人。对于小型的应用程序来说，这三种角色完全可以由程序员一个人来扮演。但是要注意，这些设计不应该交错地进行。比如，如果把用户界面交给编写代码的程序员来做，那么这位程序员不应该在每写完一小段代码之后，就去稍微设计一下用户界面，或者说，他不应该等到必须牵涉用户界面的时候，才去设计界面之中的某些内容。这一点是需要加以说明的。在用户界面的设计之中，字体大小、按钮位置以及颜色等外观方面的因素，调整起来较为容易，由于它们不会对代码产生太大影响，因此可以留到项目后期再做决定，然而像界面之间的切换、每个界面所显示的数据，以及每个按钮的功能等问题，则应该作为一个整体来进行设计。把这些内容视为一个整体，可以使我们分析出这套设计方案是否较为完备，并且使我们能够仔细地判断出该方案使用起来是否比较容易。这对于数据库设计和技术设计来说，也是类似的。
笔者这么说，可能有人不同意，因为我们毕竟也可以在编程的时候，发现设计之中的某些问题。没错，有的时候确实是如此。第1章曾经指出，这正是设计的本质特征，也就是说，细节设计总是有可能给宏观设计提供反馈。军事上有句话，叫做“一碰到敌人，计划就全乱了”，但这并不是说根本用不着做计划。相反，计划做得越好，修改起来也就越方便。设计也是这样，把宏观设计做出来之后，可以更好地看到修改该设计方案所引发的后果，于是当我们发现问题时，也就更有可能找到最佳的解决办法。
那么，用户界面、数据库以及技术方面的设计者要想完成其工作，必须知道哪些内容呢？他们需要知道的是：
该应用程序要为企业所做的事情。稍后我们将会详细讲解这一点。笔者把应用程序的功能分成多项任务（task），每项任务都表示某人于某时所做的某件事。因此，设计者需要知道有待实现的任务，以及每项任务所做的事情。
任务所使用的数据表。描述任务的时候如果不谈数据，那么这样的描述通常就没有太大意义。
与用户有关的情况。设计者需要根据用户所要做的事情，以及他们所要查看和更新的内容，对这些用户进行分组。
上面这三项信息是紧密联系在一起的，因此，它们应该放入同一个设计之中。笔者把这种设计叫做情境设计（context design）。
但是，在复杂的集成系统之中，情境设计可能会涵盖多个应用程序及服务，而用户界面的设计，却只会与某一个应用程序或服务相关联。此外，对某个数据库所做的设计，有可能同时要为多个应用程序或服务提供支持。因此，情境设计、用户界面设计以及数据库设计之间，并没有简单的一一对应关系。为此，我们需要用集成设计来展示各个部分之间的信息交换和资源共享情况，以便把应用程序、服务及数据库对情境设计的实现方式描绘出来。
最后，在做技术设计的时候，我们需要知道一些指标，如每小时或每秒钟所需完成的任务数量，以及程序所需达到的可用性目标。
图2-3画出了这6种设计之间的关系，笔者给它起了个很没有创意的名字，叫做六框设计模型（six-box model of design）。
https://yqfile.alicdn.com/ec342ce3d89468d2cdb5e3e14a465a07925edfae.png" >
你可能会问：我们有必要把设计分成这么多种吗？其实这样划分还是有些道理的。首先，数据库设计的输出结果，是数据库模式，而技术设计的主要成果，则是框架代码，换句话说，这两种设计所输出的成果，都是最终产品的一部分。其次，用户界面的设计，是一种轻量级的设计。所谓轻量级，是相对代码实现而言的，因为界面设计之中的某一句话，可以展开成很多行代码。第三，各种设计之间可以复用某些信息。情境设计之中的某些规范，可以不加修改地套用到集成设计上面，而且也可以在用户界面设计之中复用。这与经典的工程设计不同，工程设计是要把集成设计转化为用户界面或数据库的设计，而不是要将其分成用户界面设计与数据库设计这两个组件。
笔者将在接下来的几节之中，由上至下地描述这套模型，从情境设计一直讲到实现。这几节要强调的是各种设计所输出的结果，而不是我们应该如何开发并分析这些设计，那是以后的各章所要谈的话题。
笔者关注的主要是业务应用程序的开发，然而我想了一下之后发现，这个六框模型，其实对于其他类型的IT应用程序来说，也可以适用，只不过有的程序可能不需要进行数据库设计或集成设计。对于某些应用程序来说，六框模型之中的一些组件可能完全用不到，例如，在设计并实现一款文字处理程序的时候，就不需要用到这么多种设计。然而，对于其他一些非业务类的程序来说，尽管其情境设计的做法可能与刚才所说的有很大区别，但笔者仍然觉得这种设计是很有必要的。例如，在设计实时的火箭控制软件时，依然应该进行情境设计，我们需要把各种控制项目及其行为确定下来，同时还要确定改变这些控制项目时所需遵循的规则。对于这种软件来说，用户界面的设计所针对的并不是人类用户，而是一些电子测量设备。此外，实时应用程序的实现，与普通应用程序相比，也有很大差异，因为我们必须在某个精确的时间段内执行某种动作。甚至我们还需要做数据库设计，以确保数据之间的一致性，从而使得该软件能够把近期的状态记录下来。集成设计可能也是需要做的，因为处理操作可能会分布在多个处理单元上面。与实时程序类似，游戏编程之中也可以使用六框模型，只不过此处的情境设计，是指对游戏情节所做的概述，而集成设计，则只会用在多人游戏之中。
现在我们回到商业计算的领域，分别用6节篇幅来讲述早前所说的那6种设计。