第6章设计阶段 设计是运用专业知识针对确定的目标，提出具体解决方法的阶段。在设计阶 段，需要在各种解决办法中进行权衡，以确定最为合理的方案。因此，设计是一 个决策过程。在许多工程领域，如机械设计、电子设计、建筑设计行业，有着许 多设计规范、设计指南和计算公式，然而，在软件设计领域，目前似乎依然主要 依靠个人的经验和技艺进行决策，这就使得不同的人完成的软件设计有很大差别， 从而造成软件设计结果很难重用，软件的质量也很难保证。我们希望软件设计也 能够有系统化的、科学的方法，目的是遵照这一套方法，不同的人可以设计出差 别不大的系统，只有这样，设计的质量才能得到保证。 面向对象提供了一套从分析、设计、实现到测试的方法学。通过面向对象分 析已经建立了功能模型，对象模型和动态模型，在设计阶段，我们依然运用面向 对象方法，对类的定义进行细化，并将类组织成组件、子系统。由于分析阶段和 设计阶段都采用了对象模型，设计阶段的对象模型受到了分析阶段的对象模型的 直接启发，因此开展起来相对自然。然而，在设计阶段依然有许多决策是必须在 这个阶段做出的，例如整个系统需要分解成哪些子系统、整个软件的控制结构是 怎样的。本章中将围绕设计中的内容、方法、涉及到的模型和文档模板展开介绍。 值得指出的是，以面向对象的方式设计软件，与现实中创办一个企业、管理 一个企业有类似之处。作为软件设计者，要安排每一个软件对象的职责，确定它 们的交互方式，使得软件世界井然有序，运转高效；而作为企业的管理者，要安 排每一个人员的工作，确定他们之间的合作方式，使整个企业内责任明晰。保持 一个机构（无论是软件对象组成的机构，还是人组成的机构）高效运转的诀窍有 许多相似的原则，比如说，在一个企业中要使每一个人的职责比较明晰，不能把 过杂的责任分给一个人，在软件对象上，也是如此。因此，用管理好一个企业的 思维去考虑软件设计，是一个值得借鉴的思路。 6.1设计阶段的主要内容 设计阶段需要在不同层次上进行决策。我们把这种决策分为两个层次：系统 设计层和对象设计层
第 6 章 设计阶段 设计是运用专业知识针对确定的目标，提出具体解决方法的阶段。在设计阶 段，需要在各种解决办法中进行权衡，以确定最为合理的方案。因此，设计是一 个决策过程。在许多工程领域，如机械设计、电子设计、建筑设计行业，有着许 多设计规范、设计指南和计算公式，然而，在软件设计领域，目前似乎依然主要 依靠个人的经验和技艺进行决策，这就使得不同的人完成的软件设计有很大差别， 从而造成软件设计结果很难重用，软件的质量也很难保证。我们希望软件设计也 能够有系统化的、科学的方法，目的是遵照这一套方法，不同的人可以设计出差 别不大的系统，只有这样，设计的质量才能得到保证。 面向对象提供了一套从分析、设计、实现到测试的方法学。通过面向对象分 析已经建立了功能模型，对象模型和动态模型，在设计阶段，我们依然运用面向 对象方法，对类的定义进行细化，并将类组织成组件、子系统。由于分析阶段和 设计阶段都采用了对象模型，设计阶段的对象模型受到了分析阶段的对象模型的 直接启发，因此开展起来相对自然。然而，在设计阶段依然有许多决策是必须在 这个阶段做出的，例如整个系统需要分解成哪些子系统、整个软件的控制结构是 怎样的。本章中将围绕设计中的内容、方法、涉及到的模型和文档模板展开介绍。 值得指出的是，以面向对象的方式设计软件，与现实中创办一个企业、管理 一个企业有类似之处。作为软件设计者，要安排每一个软件对象的职责，确定它 们的交互方式，使得软件世界井然有序，运转高效；而作为企业的管理者，要安 排每一个人员的工作，确定他们之间的合作方式，使整个企业内责任明晰。保持 一个机构（无论是软件对象组成的机构，还是人组成的机构）高效运转的诀窍有 许多相似的原则，比如说，在一个企业中要使每一个人的职责比较明晰，不能把 过杂的责任分给一个人，在软件对象上，也是如此。因此，用管理好一个企业的 思维去考虑软件设计，是一个值得借鉴的思路。 6.1 设计阶段的主要内容 设计阶段需要在不同层次上进行决策。我们把这种决策分为两个层次：系统 设计层和对象设计层
1.系统设计 系统设计是有关系统总体构成的决定。对于一个具有一定复杂度的系统，我 们一般而言需要把它分解为子系统，以此来增加各个子系统的可重用性，降低开 发难度，也使得各个团队可以并行开发。 随着技术的发展，出现了具有不同结构特征的系统框架范型，包括Wb系统、 客户/服务器系统、对等系统等。我们可以按照这些系统架构去进行系统设计， 划分子系统的构成，确定各个子系统的接口。同时，目前也出现了许多中间件、 软件框架，开发系统时可以利用这些中间件、软件框架从而降低开发难度，提高 开发效率。使用成熟的中间件、软件框架进行开发也有助于提高系统的质量。 在系统设计时，要考虑系统的各种设计目标、与其他系统的集成、将来的维 护需求、技术风险等因素。这些设计目标有时候可能会相互冲突，我们需要在设 计中对这些设计目标进行权衡，做出合理的决策。 2.对象设计 在系统设计的基础上，我们需要进一步确定涉及到的软件对象，每个软件类 (此处也称为设计类)的属性、方法的详细定义，软件对象之间的具体交互形式。 我们从分析阶段的对象模型中获得启发，从中把软件中要实现的对应类抽取出来， 再参考分析阶段的动态模型，构造设计阶段的动态模型，并添加必要的类。由于 软件自有其独特之处，考虑到软件的可理解性、性能、未来的可重用性、重用已 有类或者子系统等因素，得到细化后的对象模型、动态模型，给软件实现以直接 的指导。在设计时，要灵活运用设计原则，一方面要考虑未来可能的变化，强调 架构的灵活性，另一方面，也要避免过于复杂的设计。 3.运行设计 随着软件系统的功能越来越复杂，性能要求越来越高，现代软件涉及到多进 程、多线程的越来越多。运行设计就是设计进程、线程和它们的运行关系，并把 设计元素分配到进程、线程中去。 4.实现设计 软件需要通过开发工具，编写代码，并经过编译形成可执行文件。我们需要 定义开发过程中采用的工具，需要编写的文件以及它们的依赖关系。同时，也需 要定义编译以后生成的组件以及它们的依赖关系
1. 系统设计 系统设计是有关系统总体构成的决定。对于一个具有一定复杂度的系统，我 们一般而言需要把它分解为子系统，以此来增加各个子系统的可重用性，降低开 发难度，也使得各个团队可以并行开发。 随着技术的发展，出现了具有不同结构特征的系统框架范型，包括 Web 系统、 客户/服务器系统、对等系统等。我们可以按照这些系统架构去进行系统设计， 划分子系统的构成，确定各个子系统的接口。同时，目前也出现了许多中间件、 软件框架，开发系统时可以利用这些中间件、软件框架从而降低开发难度，提高 开发效率。使用成熟的中间件、软件框架进行开发也有助于提高系统的质量。 在系统设计时，要考虑系统的各种设计目标、与其他系统的集成、将来的维 护需求、技术风险等因素。这些设计目标有时候可能会相互冲突，我们需要在设 计中对这些设计目标进行权衡，做出合理的决策。 2. 对象设计 在系统设计的基础上，我们需要进一步确定涉及到的软件对象，每个软件类 （此处也称为设计类）的属性、方法的详细定义，软件对象之间的具体交互形式。 我们从分析阶段的对象模型中获得启发，从中把软件中要实现的对应类抽取出来， 再参考分析阶段的动态模型，构造设计阶段的动态模型，并添加必要的类。由于 软件自有其独特之处，考虑到软件的可理解性、性能、未来的可重用性、重用已 有类或者子系统等因素，得到细化后的对象模型、动态模型，给软件实现以直接 的指导。在设计时，要灵活运用设计原则，一方面要考虑未来可能的变化，强调 架构的灵活性，另一方面，也要避免过于复杂的设计。 3. 运行设计 随着软件系统的功能越来越复杂，性能要求越来越高，现代软件涉及到多进 程、多线程的越来越多。运行设计就是设计进程、线程和它们的运行关系，并把 设计元素分配到进程、线程中去。 4. 实现设计 软件需要通过开发工具，编写代码，并经过编译形成可执行文件。我们需要 定义开发过程中采用的工具，需要编写的文件以及它们的依赖关系。同时，也需 要定义编译以后生成的组件以及它们的依赖关系
5.软硬件部署设计 软件最终需要部署到硬件上才能得到运行。因此，硬件平台配置（包括计算 机的配置、网络的配置、各种专门硬件如存储系统、各种外设如打印机等)，软 件各个部分以什么样的形式分布在硬件系统上也是需要在设计阶段确定的。 6.数据管理设计 软件系统中都会涉及到数据的管理问题。尽管面向对象系统中已经把数据和 操作封装在一起，我们依然需要考虑数据持久化的问题。数据持久化是指数据的 保存。究竞采用何种数据保存的方式，以及具体的数据保存格式会对数据的访问 效率产生根本性的影响。 7.其他设计问题 软件设计中还要针对设计目标进行针对性的考虑。例如针对安全性，就有许 多方面需要考虑，包括访问控制、数据安全、防攻击等，针对可靠性，包括防错、 容错等。 我们将在本章中对这些设计步骤进行逐一介绍。需要指出的是软件设计是一 个迭代的过程，也就是说，它并非是沿着系统设计、对象设计、运行设计、实现 设计、软硬件部署设计、数据管理设计、其它设计这样一个线性过程，而是这些 步骤的交错迭代过程。 设计阶段的主要交付物包括： 1) 软件设计模型 2) 软件架构文档 6.2.软件设计的原则 无论是机械设计、建筑设计和电子设计中，都有一套设计原则，这些设计原 则应该贯彻在所有的设计实践中。软件设计也不例外。然而，相对而言，在机械 行业、建筑行业、电子行业都有比较成熟而详细的设计指南，软件行业仅仅有一 些设计原则，而且这些设计原则还比较抽象。 在本节中，我们介绍的设计原则，不仅适用于子系统层次，也适合于对象层 次。有些原则在分析阶段中就己经得到应用，这是为了与在软件中应用此原则一 致起来
5. 软硬件部署设计 软件最终需要部署到硬件上才能得到运行。因此，硬件平台配置（包括计算 机的配置、网络的配置、各种专门硬件如存储系统、各种外设如打印机等），软 件各个部分以什么样的形式分布在硬件系统上也是需要在设计阶段确定的。 6. 数据管理设计 软件系统中都会涉及到数据的管理问题。尽管面向对象系统中已经把数据和 操作封装在一起，我们依然需要考虑数据持久化的问题。数据持久化是指数据的 保存。究竟采用何种数据保存的方式，以及具体的数据保存格式会对数据的访问 效率产生根本性的影响。 7. 其他设计问题 软件设计中还要针对设计目标进行针对性的考虑。例如针对安全性，就有许 多方面需要考虑，包括访问控制、数据安全、防攻击等，针对可靠性，包括防错、 容错等。 我们将在本章中对这些设计步骤进行逐一介绍。需要指出的是软件设计是一 个迭代的过程，也就是说，它并非是沿着系统设计、对象设计、运行设计、实现 设计、软硬件部署设计、数据管理设计、其它设计这样一个线性过程，而是这些 步骤的交错迭代过程。 设计阶段的主要交付物包括： 1） 软件设计模型 2） 软件架构文档 6.2. 软件设计的原则 无论是机械设计、建筑设计和电子设计中，都有一套设计原则，这些设计原 则应该贯彻在所有的设计实践中。软件设计也不例外。然而，相对而言，在机械 行业、建筑行业、电子行业都有比较成熟而详细的设计指南，软件行业仅仅有一 些设计原则，而且这些设计原则还比较抽象。 在本节中，我们介绍的设计原则，不仅适用于子系统层次，也适合于对象层 次。有些原则在分析阶段中就已经得到应用，这是为了与在软件中应用此原则一 致起来
1.高内聚、低耦合原则 这是软件设计中最基本的原则。通过将功能相关的责任分配给一个类，实现 了类的高内聚，通过将功能相关的类组织成子系统，实现了子系统的高内聚。而 在类与类之间、子系统与子系统之间，使它们之间的交互尽量少，实现了低耦合。 高内聚、低耦合的原则是软件设计中的根本原则，其他原则都是依据此原则派生 而来。我们在分析阶段已经对此原则进行了介绍，在此就不再进一步展开。 2.“模型-视图”相分离原则 模型视图分离原则是高内聚、低耦合原则的一个应用。“模型”代表的是依据 领域类确定的设计类，它是从业务逻辑中抽取而来的，相对稳定。“视图”对应的 是人机接口。显然，不同用户对人机接口有不同的要求，修改意见也比较集中于 人机接口部分。通过模型视图的分离，使得人机接口的修改不影响模型对应的设 计类，从而提高了系统的可维护性。 3.关注点分离原则 关注点分离原则强调软件元素应该具有互不相关的目的。也就是说，一个元 素承担的职责比较专一，它不会去承担应该由另一个元素承担的职责。关注点的 分离是通过明确边界来达成的。边界是任何逻辑或者物理的限制，它能给一组特 定的职责划定界限。关注点分离的目标是使各个软件元素各司其职，从而形成一 个具有良好秩序的系统。 将关注点分离原则应用于软件设计有许多的好处。首先，每一个软件元素的 目的单一会使得整个系统更易于维护，提高了可维护性后，系统整体也会变得更 加稳定；由软件元素专注于单一目标所形成的解耦，使得在它其它系统中的复用 变得容易。关注点分离也是现实世界中组织管理的一个理念，它使得团队责任明 确。 4.重用的原则 在成熟的工业中，部件（系统）可重用是大规模生产的前提。例如在机械行 业、电子行业中，各个零部件具有高度的可重用性、互换性。软件行业需要向成 熟工业学习，首先就是要学习可重用性。以往的可重用的软件部件，有的可以不 加修改直接使用，有的进行修改后就可以再用，从而大大提高了生产效率，同时， 可重用的软件元素经过了严格的质量保证，重用它们有助于提高整个软件产品的 质量。所以在软件设计过程中，始终要考虑重用性的问题：一方面，需要考虑可
1. 高内聚、低耦合原则 这是软件设计中最基本的原则。通过将功能相关的责任分配给一个类，实现 了类的高内聚，通过将功能相关的类组织成子系统，实现了子系统的高内聚。而 在类与类之间、子系统与子系统之间，使它们之间的交互尽量少，实现了低耦合。 高内聚、低耦合的原则是软件设计中的根本原则，其他原则都是依据此原则派生 而来。我们在分析阶段已经对此原则进行了介绍，在此就不再进一步展开。 2. “模型-视图”相分离原则 模型视图分离原则是高内聚、低耦合原则的一个应用。“模型”代表的是依据 领域类确定的设计类，它是从业务逻辑中抽取而来的，相对稳定。“视图”对应的 是人机接口。显然，不同用户对人机接口有不同的要求，修改意见也比较集中于 人机接口部分。通过模型视图的分离，使得人机接口的修改不影响模型对应的设 计类，从而提高了系统的可维护性。 3. 关注点分离原则 关注点分离原则强调软件元素应该具有互不相关的目的。也就是说，一个元 素承担的职责比较专一，它不会去承担应该由另一个元素承担的职责。关注点的 分离是通过明确边界来达成的。边界是任何逻辑或者物理的限制，它能给一组特 定的职责划定界限。关注点分离的目标是使各个软件元素各司其职，从而形成一 个具有良好秩序的系统。 将关注点分离原则应用于软件设计有许多的好处。首先，每一个软件元素的 目的单一会使得整个系统更易于维护，提高了可维护性后，系统整体也会变得更 加稳定；由软件元素专注于单一目标所形成的解耦，使得在它其它系统中的复用 变得容易。关注点分离也是现实世界中组织管理的一个理念，它使得团队责任明 确。 4. 重用的原则 在成熟的工业中，部件（系统）可重用是大规模生产的前提。例如在机械行 业、电子行业中，各个零部件具有高度的可重用性、互换性。软件行业需要向成 熟工业学习，首先就是要学习可重用性。以往的可重用的软件部件，有的可以不 加修改直接使用，有的进行修改后就可以再用，从而大大提高了生产效率，同时， 可重用的软件元素经过了严格的质量保证，重用它们有助于提高整个软件产品的 质量。所以在软件设计过程中，始终要考虑重用性的问题：一方面，需要考虑可
以重用哪些现成的元素，从而能够改进开发，另一方面，需要考虑正在开发的软 件如何提高可重用性，以利于后续的开发。 可重用的软件元素不仅包括程序（如子系统、组件、类库、代码等）、也可 以是测试用例、设计文档、设计过程、标准，甚至是设计知识。6.3节中我们将 对此进行更为详细的阐述。 6.3从可重用软件单元到可重用设计知识 典型的可重用的软件元素包括类库、框架、中间件，而典型的可重用的软件 设计知识就是设计模式。 6.3.1类库 类库(Class Library)是类的集合，一般的类库用以解决一系列常见编程任 务（包括诸如字符串管理、数据收集、数据库连接以及文件访问等任务），也有 针对不同开发任务的类库（如语音处理，图像处理，算法等）。围绕各种程序设 计语言，都有大量的类库，从而形成了一个开发语言的生态环境。可以说类库的 丰富程度是决定一个语言是否得到广泛应用的重要要素。 6.3.2软件框架 虽然通过类的重用可以提高开发效率，但是这种重用在实践中存在着一些不 足：(1)目前的类库日趋其庞大以致于使用人员难以掌握：(2)大多数类的粒 度还太小，人们不得不将多个类的对象组合起来并作为一个整体来使用。这就使 得人们逐渐追求更大规模的软件重用。 软件框架(Software Framework),可以指的是为了实现某个业界标准或完 成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范 所要求的基础功能的软件产品，我们此处用的是第二个含义。 软件框架是面向某领域的、可复用的“半成品”软件，它实现了该领域的共 性部分，并提供一系列定义良好的“可变点”以保证灵活性和可扩展性。 所谓软件框架中的“可变点”有以下四种情况： (1)模板参数化：软件框架提供代码自动生成工具，该工具根据用户设置的参
以重用哪些现成的元素，从而能够改进开发，另一方面，需要考虑正在开发的软 件如何提高可重用性，以利于后续的开发。 可重用的软件元素不仅包括程序（如子系统、组件、类库、代码等）、也可 以是测试用例、设计文档、设计过程、标准，甚至是设计知识。6.3 节中我们将 对此进行更为详细的阐述。 6.3 从可重用软件单元到可重用设计知识 典型的可重用的软件元素包括类库、框架、中间件，而典型的可重用的软件 设计知识就是设计模式。 6.3.1 类库 类库（Class Library）是类的集合，一般的类库用以解决一系列常见编程任 务（包括诸如字符串管理、数据收集、数据库连接以及文件访问等任务），也有 针对不同开发任务的类库（如语音处理，图像处理，算法等）。围绕各种程序设 计语言，都有大量的类库，从而形成了一个开发语言的生态环境。可以说类库的 丰富程度是决定一个语言是否得到广泛应用的重要要素。 6.3.2 软件框架 虽然通过类的重用可以提高开发效率，但是这种重用在实践中存在着一些不 足：（1）目前的类库日趋其庞大以致于使用人员难以掌握；（2）大多数类的粒 度还太小，人们不得不将多个类的对象组合起来并作为一个整体来使用。这就使 得人们逐渐追求更大规模的软件重用。 软件框架（Software Framework），可以指的是为了实现某个业界标准或完 成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范 所要求的基础功能的软件产品，我们此处用的是第二个含义。 软件框架是面向某领域的、可复用的“半成品”软件，它实现了该领域的共 性部分，并提供一系列定义良好的“可变点”以保证灵活性和可扩展性。 所谓软件框架中的“可变点”有以下四种情况： （1）模板参数化：软件框架提供代码自动生成工具，该工具根据用户设置的参
数自动生成所需的代码： (2)继承和多态：通过面向对象中的子类继承和重载，在子类中加入新的功能 或改变父类的行为： (3)动态绑定：在运行时刻动态绑定所需的对象服务，这可以通过一些软件设 计模式实现： (4)构件替换：通过替换框架中可插拔的构件来加入业务特定的功能。 使用软件框架进行开发，开发者只需要关注那些需要自己实现的部分，软件 框架将会主动调用用户开发的软件组件，从而实现软件的功能。 软件框架有很多种，按其应用的范围可分为： (1)系统基础设施框架：用于简化系统级软件的开发，如操作系统、用户界面、 语言处理等。开发框架的例子如struts1,struts2,hibernate,spring,ibatis, Lucene等。 (2)企业应用框架：用于各类应用领域，如电信、制造业、金融等。如Apache OFBz就是一个较全面的企业软件框架。 6.3.3中间件 中间件(middleware)也是可重用软件。中间间位于操作系统、网络和数据库 之上，应用软件的下层，作用是为处于上层的应用软件提供运行与开发的环境， 帮助用户灵活、高效地开发和集成复杂的应用软件。 中间件一般是分布式的软件，在网络通信功能的基础上，提供了应用之间的 互操作能力。中间件向应用提供的服务一般具有标准的程序接口和协议，同时应 该具备跨平台的能力，就是说针对不同的操作系统和硬件平台，需要有符合接口 和协议规范的多种实现。 目前中间件可以分为以下类型： 1)数据库中间件 数据库中间件在所有的中间件中是应用最广泛，技术最成熟的一种。ODBC 就是一种典型的、相对简单而又广泛使用的数据库中间件，它允许应用程序和本 地或者异地的数据库进行通信，并提供了一系列的面向应用程序的接口API。在 使用时，只要在ODBC中添加一个数据源，然后就可以直接在自己的应用程序中 使用这个数据源，而不用关心目标数据库的实现原理、实现机制。 2)远程过程调用中间件(RPC,Remote Procedure Call) 远程过程调用被广泛应用于客户/服务器架构中，使得程序员就像调用本地
数自动生成所需的代码； （2）继承和多态：通过面向对象中的子类继承和重载，在子类中加入新的功能 或改变父类的行为； （3）动态绑定：在运行时刻动态绑定所需的对象服务，这可以通过一些软件设 计模式实现； （4）构件替换：通过替换框架中可插拔的构件来加入业务特定的功能 。 使用软件框架进行开发，开发者只需要关注那些需要自己实现的部分，软件 框架将会主动调用用户开发的软件组件，从而实现软件的功能。 软件框架有很多种，按其应用的范围可分为： （1）系统基础设施框架：用于简化系统级软件的开发，如操作系统、用户界面、 语言处理等。开发框架的例子如 struts1，struts2，hibernate，spring，ibatis， Lucene 等。 （2）企业应用框架：用于各类应用领域，如电信、制造业、金融等。如 Apache OFBiz 就是一个较全面的企业软件框架。 6.3.3 中间件 中间件(middleware)也是可重用软件。中间间位于操作系统、网络和数据库 之上，应用软件的下层，作用是为处于上层的应用软件提供运行与开发的环境， 帮助用户灵活、高效地开发和集成复杂的应用软件。 中间件一般是分布式的软件，在网络通信功能的基础上，提供了应用之间的 互操作能力。中间件向应用提供的服务一般具有标准的程序接口和协议，同时应 该具备跨平台的能力，就是说针对不同的操作系统和硬件平台，需要有符合接口 和协议规范的多种实现。 目前中间件可以分为以下类型： 1）数据库中间件 数据库中间件在所有的中间件中是应用最广泛，技术最成熟的一种。ODBC 就是一种典型的、相对简单而又广泛使用的数据库中间件，它允许应用程序和本 地或者异地的数据库进行通信，并提供了一系列的面向应用程序的接口 API。在 使用时，只要在 ODBC 中添加一个数据源，然后就可以直接在自己的应用程序中 使用这个数据源，而不用关心目标数据库的实现原理、实现机制。 2）远程过程调用中间件（RPC, Remote Procedure Call） 远程过程调用被广泛应用于客户/服务器架构中，使得程序员就像调用本地
过程一样在程序中调用远程过程，然后将运行结果返回给本地程序。远程过程调 用具有跨平台性，也就是说它的调用可以跨不同操作系统平台，程序员在编程时 并不需要考虑这些细节。远程过程调用采用的是同步通信方式，对于比较小型的 简单应用比较适合。但是对于一些大型的应用，这种方式不一定适合，同时在一 些复杂应用中，需要考虑网络或者系统故障，处理并发操作、缓冲、流量控制以 及进程同步等问题，这些是远程过程调用中间件所无法满足的。 3)基于对象请求代理(ORB,Object Request Broker)的中间件 对象请求代理是是和编程语言无关的面向对象的RPC应用。从管理和封装 的模式上看，对象请求代理和远过程调用类似，不过对象请求代理可以包含比远 过程调用和消息中间件更复杂的信息，并且可以适用于非结构化的或者非关系型 的数据。 4)面向消息中间件(MOM,Message Oriented Middleware) 消息中间件适用于需要在多个进程之间进行可靠的数据传送的分布式环境。 它的优点在于能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻 都可以将消息进行传送或者存储转发。消息中间件不会占用大量的网络带宽，可 以跟踪事务，并且通过将事务存储到磁盘上实现网络故障时系统的恢复。 5)事务处理中间件(TPM,Transaction Processing Monitor) 事务处理中间件是针对复杂环境下分布式应用的速度和可靠性要求而实现 的。它给程序员提供了一个事务处理的API,程序员可以使用这个程序接口编写 高速而且可靠的分布式应用程序。事务处理中间件常见的功能包括全局事务协调、 事务的分布式两段提交、资源管理器支持、故障恢复、高可靠性、网络负载平衡 等等。 6)服务中间件 随着Web服务技术的应用和普及，出现了针对Web服务的中间件软件，其 中最具有代表性的是服务总线，它是传统中间件技术与XML、Wb服务等技术 结合的产物。它消除了不同应用之间的技术差异，实现了不同服务之间的通信和 整合。从功能上看，服务总线提供了事件驱动的处理模式，以及分布式的运行管 理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提 供一系列的标准接口
过程一样在程序中调用远程过程，然后将运行结果返回给本地程序。远程过程调 用具有跨平台性，也就是说它的调用可以跨不同操作系统平台，程序员在编程时 并不需要考虑这些细节。远程过程调用采用的是同步通信方式，对于比较小型的 简单应用比较适合。但是对于一些大型的应用，这种方式不一定适合，同时在一 些复杂应用中，需要考虑网络或者系统故障，处理并发操作、缓冲、流量控制以 及进程同步等问题，这些是远程过程调用中间件所无法满足的。 3）基于对象请求代理（ORB，Object Request Broker）的中间件 对象请求代理是是和编程语言无关的面向对象的 RPC 应用。从管理和封装 的模式上看，对象请求代理和远过程调用类似，不过对象请求代理可以包含比远 过程调用和消息中间件更复杂的信息，并且可以适用于非结构化的或者非关系型 的数据。 4）面向消息中间件（MOM，Message Oriented Middleware） 消息中间件适用于需要在多个进程之间进行可靠的数据传送的分布式环境。 它的优点在于能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻 都可以将消息进行传送或者存储转发。消息中间件不会占用大量的网络带宽，可 以跟踪事务，并且通过将事务存储到磁盘上实现网络故障时系统的恢复。。 5）事务处理中间件（TPM，Transaction Processing Monitor） 事务处理中间件是针对复杂环境下分布式应用的速度和可靠性要求而实现 的。它给程序员提供了一个事务处理的 API，程序员可以使用这个程序接口编写 高速而且可靠的分布式应用程序。事务处理中间件常见的功能包括全局事务协调、 事务的分布式两段提交、资源管理器支持、故障恢复、高可靠性、网络负载平衡 等等。 6) 服务中间件 随着 Web 服务技术的应用和普及，出现了针对 Web 服务的中间件软件，其 中最具有代表性的是服务总线，它是传统中间件技术与 XML、Web 服务等技术 结合的产物。它消除了不同应用之间的技术差异，实现了不同服务之间的通信和 整合。从功能上看，服务总线提供了事件驱动的处理模式，以及分布式的运行管 理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提 供一系列的标准接口
6.3.4设计模式 针对特定的设计问题，大家总结了一些成功的设计方法，为大家所共享，这 就是设计模式。设计模式是一个问题和方案对，即针对什么问题，提供什么方案， 这个方案有何优缺点都加以明确化。 设计模式有许多。我们可以把它归为三类，即结构模式、行为模型和创建模 式。结构模式用来降低类之间的耦合性，通常采用引入抽象类或者接口以实现未 来的可扩展性：行为模式将算法或者功能实现进行合理分配，使得整体控制流程 中的某一个步骤的功能实现能够动态替换或者改变：创建模式将复杂的对象生成 过程进行了抽象，使得那些需要依据外界的配置条件决定生成一组对象的操作对 软件其他部分透明。 图6-1列出了按照此三种分类的常见的设计模式。 Pattern Creational Structural Pattern Pattern Behavioral Pattern Abstract Builder Factory Pattern Command Observer Strategy Adapter Bridge Facade Proxy Composite 图6-1设计模式的分类 6.4系统设计 系统设计是围绕设计目标确定合理的系统构成和总体工作机制的过程。在总 体设计中，也需要考虑系统实现的成本、时间、风险和质量因素。以下为典型的 系统设计过程： 1.确定设计目标：根据用户的需求或者市场的需求确定设计目标，这些设计目 标通常是依据非功能需求而定的
6.3.4 设计模式 针对特定的设计问题，大家总结了一些成功的设计方法，为大家所共享，这 就是设计模式。设计模式是一个问题和方案对，即针对什么问题，提供什么方案， 这个方案有何优缺点都加以明确化。 设计模式有许多。我们可以把它归为三类，即结构模式、行为模型和创建模 式。结构模式用来降低类之间的耦合性，通常采用引入抽象类或者接口以实现未 来的可扩展性；行为模式将算法或者功能实现进行合理分配，使得整体控制流程 中的某一个步骤的功能实现能够动态替换或者改变；创建模式将复杂的对象生成 过程进行了抽象，使得那些需要依据外界的配置条件决定生成一组对象的操作对 软件其他部分透明。 图 6-1 列出了按照此三种分类的常见的设计模式。 图 6-1 设计模式的分类 6.4 系统设计 系统设计是围绕设计目标确定合理的系统构成和总体工作机制的过程。在总 体设计中，也需要考虑系统实现的成本、时间、风险和质量因素。以下为典型的 系统设计过程: 1. 确定设计目标：根据用户的需求或者市场的需求确定设计目标，这些设计目 标通常是依据非功能需求而定的
2.确定子系统的分解结构：确定系统分为哪些子系统，各个子系统向外提供的 接口，各个子系统之间是如何实现交互的。 6.4.1系统设计中的概念 6.4.1.1系统分解的概念 系统分解中涉及到以下概念： (1)子系统：子系统包含了一组紧密相关的类产生的对象。子系统一般具有定 义良好的接口，因此具有整体的可替换性。 (2)服务：是由子系统提供的具有共同目标的一组相关的操作。 (3)子系统接口：经过完整定义的一组相关的接口。 系统分解就是定义具有良好接口的子系统的过程。 从大的角度看，系统分解有两种模式，即分层(Layer)和拆分(Partition)。 所谓“层”，也是一个子系统，该子系统向上层提供接口，同时利用下层系统 的接口。分层体系结构使得各层有清晰的责任，并保持了实现上的独立性。因而， 分层体系结构是目前的一种主流结构。典型的三层结构系统中各层为： ●用户界面层：提供与用户交互的接口。用户界面层采用与U设计相关的技 术进行构造。 ●应用逻辑和领域对象层：根据分析阶段得到的对象模型、动态模型而开发的 软件对象模型，它们之间的协作能够实现业务功能： 技术服务层：提供一些通用的对象或者子系统，负责与数据库、日志、网络 等打交道，一般是与应用没有直接关系。在这一部分，我们经常会使用一些 己有的类库、中间件甚至软件框架。 拆分是将系统从垂直的角度分成耦合度小的几个子系统，在多数情况下，拆 分是按照功能进行的。 6.4.1.2系统架构模式 系统架构模式是几种具有代表性的架构，在确定系统结构时，可以选用某种 具有代表性的系统架构模式，根据它们，确定具体的结构方式
2. 确定子系统的分解结构：确定系统分为哪些子系统，各个子系统向外提供的 接口，各个子系统之间是如何实现交互的。 6.4.1 系统设计中的概念 6.4.1.1 系统分解的概念 系统分解中涉及到以下概念： （1） 子系统：子系统包含了一组紧密相关的类产生的对象。子系统一般具有定 义良好的接口，因此具有整体的可替换性。 （2） 服务：是由子系统提供的具有共同目标的一组相关的操作。 （3） 子系统接口：经过完整定义的一组相关的接口。 系统分解就是定义具有良好接口的子系统的过程。 从大的角度看，系统分解有两种模式，即分层（Layer）和拆分（Partition）。 所谓“层”，也是一个子系统，该子系统向上层提供接口，同时利用下层系统 的接口。分层体系结构使得各层有清晰的责任，并保持了实现上的独立性。因而， 分层体系结构是目前的一种主流结构。典型的三层结构系统中各层为： 用户界面层：提供与用户交互的接口。用户界面层采用与 UI 设计相关的技 术进行构造。 应用逻辑和领域对象层：根据分析阶段得到的对象模型、动态模型而开发的 软件对象模型，它们之间的协作能够实现业务功能； 技术服务层：提供一些通用的对象或者子系统，负责与数据库、日志、网络 等打交道，一般是与应用没有直接关系。在这一部分，我们经常会使用一些 已有的类库、中间件甚至软件框架。 拆分是将系统从垂直的角度分成耦合度小的几个子系统，在多数情况下，拆 分是按照功能进行的。 6.4.1.2 系统架构模式 系统架构模式是几种具有代表性的架构，在确定系统结构时，可以选用某种 具有代表性的系统架构模式，根据它们，确定具体的结构方式
1.客户/服务器模式(Client/Server,C/S) 客户机/服务器结构是软件系统中最常见的一种。客户端向服务器方发送请求， 服务器方根据接收到的请求向客户返回结果。这种模式随着数据库服务器的成熟 而得到了流行，并且随着技术的发展，出现了许多不同的形态。 (1)两层C/S结构 该模式是最具代表性的客户/服务器模式，也简称为“胖客户端”模式。在 实际的系统设计中，该类结构主要是指前台客户端+后台数据库管理系统。 (2)三层C/S结构与B/S结构 在三层C/S结构中，其前台界面送往后台的请求中，先经过业务逻辑层处理， 再进行数据库存取操作，前台界面与业务逻辑层之间可以采用TCP/IP协议，自 定义的消息机制、基于RPC编程来实现、基于Java RMI,或者基于中间件如消 息中间件来实现通信。 当前台采用Web页面、页面与Web服务器采用HTTP协议通信时，这就是 流行的B/S(Brower/Server,浏览器/服务器)模式。 (3)多层C/S结构 多层C/S结构一般是指三层以上的结构，在实践中主要是三层与四层，四层 即前台界面（如浏览器）、Wb服务器、中间件（或应用服务器）及数据库服务 器，多层客户机/服务器模式主要用于较有规模的企业信息系统建设。 2.模型视图控制器模式(Model,,View and Controller,MVC) MVC既是一种架构模式也是一种设计模式，MVC可以带来更好的软件结构和 代码重用。 在MVC中，将软件中处理输入、输出和处理功能的部分分开，使用MVC的 软件被分成三个核心部件：模型、视图和控制器。 (1)视图 视图是用户看到并与之交互的界面。例如，在Wb程序中，视图就是浏览 器中用户看到的页面。随着技术的发展，各种新型的用户交互形式不断出现，例 如语音接口，三维接口等，如何处理应用程序的界面变得越来越有挑战性。在 MVC中，一个程序可以有多个视图，在视图中不包含处理逻辑。 (2)模型 模型表示企业数据和业务逻辑。在MVC的三个部件中，模型是最核心的部 分。在面向对象的软件模式中，模型部分与具体的数据格式（返回给前端的结果） 无关，这样一个模型能为多个视图提供数据
1. 客户/服务器模式（Client/Server，C/S） 客户机/服务器结构是软件系统中最常见的一种。客户端向服务器方发送请求， 服务器方根据接收到的请求向客户返回结果。这种模式随着数据库服务器的成熟 而得到了流行，并且随着技术的发展，出现了许多不同的形态。 （1）两层 C/S 结构 该模式是最具代表性的客户/服务器模式，也简称为 “胖客户端”模式。在 实际的系统设计中，该类结构主要是指前台客户端+后台数据库管理系统。 （2）三层 C/S 结构与 B/S 结构 在三层 C/S 结构中，其前台界面送往后台的请求中，先经过业务逻辑层处理， 再进行数据库存取操作，前台界面与业务逻辑层之间可以采用 TCP/IP 协议，自 定义的消息机制、基于 RPC 编程来实现、基于 Java RMI，或者基于中间件如消 息中间件来实现通信。 当前台采用 Web 页面、页面与 Web 服务器采用 HTTP 协议通信时，这就是 流行的 B/S（Brower/Server，浏览器/服务器）模式。 （3）多层 C/S 结构 多层 C/S 结构一般是指三层以上的结构，在实践中主要是三层与四层，四层 即前台界面（如浏览器）、Web 服务器、中间件（或应用服务器）及数据库服务 器， 多层客户机／服务器模式主要用于较有规模的企业信息系统建设。 2. 模型视图控制器模式（Model, View and Controller, MVC） MVC 既是一种架构模式也是一种设计模式，MVC 可以带来更好的软件结构和 代码重用。 在 MVC 中，将软件中处理输入、输出和处理功能的部分分开，使用 MVC 的 软件被分成三个核心部件：模型、视图和控制器。 （1）视图 视图是用户看到并与之交互的界面。例如，在 Web 程序中，视图就是浏览 器中用户看到的页面。随着技术的发展，各种新型的用户交互形式不断出现，例 如语音接口，三维接口等，如何处理应用程序的界面变得越来越有挑战性。在 MVC 中，一个程序可以有多个视图，在视图中不包含处理逻辑。 （2）模型 模型表示企业数据和业务逻辑。在 MVC 的三个部件中，模型是最核心的部 分。在面向对象的软件模式中，模型部分与具体的数据格式（返回给前端的结果） 无关，这样一个模型能为多个视图提供数据