下载部分中提供的示例设计模板包括九个部分（将在下面进行说明）。第一部分和最后一部分用于在组件与整个门户之间建立联系。在门户项目的早期，确定了任务和组件后，团队负责人将创建一组设计文档，并将其分发给组件所有者。这些组件所有者将使用设计文档来记录组件级的需求、定义组件体系结构、列出测试用例、模拟组件的 UI，诸如此类的工作。他们的文档将随时间而不断改进，并将在其中包含组件的概要设计和详细设计。

此模板是一个起点；请根据您的需要对其进行调整。重要的是，要具备与每个组件、Portlet、服务或门户项目的主要部分关联的设计文档！

介绍部分

第一部分提供组件或组件集的基本介绍。文档的任何读者（如管理人员、团队成员、编码人员、测试人员、营销人员、相关项目团队成员）应能轻松地明白组件的用途及其完成的工作，而不用过于深入功能、需求或技术细节。请将其视为摘要。

可以考虑添加其他一些跟踪性信息，如：

• 文档的当前及上任作者或所有者
• 已进行的更改或更新
• 项目管理人员或客户代表批准或检查日期

需求

再次强调：需求非常重要。无论将其作为用例或用户案例进行记录，都请将需求作为对团队提出要求的客户。这些内容说明组件提供的功能应如何工作以及组件为整个门户提供何种价值。正是由于这个原因，需要将驱动组件的需求与该组件的设计一起记录。

如果需求是在创建设计文档之前收集的，可能会存储在业务分析团队创建的独立文档中。我们建议不要链接或引用另一个文档，而将其从原始文档中复制并粘贴到组件设计文档中，以便将组件的所有信息都存储在同一个位置。需要在您的文档中保存需求和任何用例以及相关的用户界面设计、测试场景和任何其他部分，以便开发人员能方便地进行参考。

组件体系结构

利用这一部分来确定组件的总体体系结构（采用与项目适应的格式）。以下是可以包含的内容的一些示例：

• 关于子系统的主要组件及它们如何交互的关系图
• 依赖关系图，显示组件如何依赖 WebSphere Application Server 内的 API、来自其他组件的服务、数据库或任何 LDAP 交互
• 概要序列关系图或分析模型
• 上下文或组件关系图应列出组件如何与其他组件和整个系统进行交互

详细设计

对于技术专家而言，这是模板的核心。好的详细设计将使用类、序列、组件交互关系图来描述如何实现组件。当然，您所决定要包含的内容取决于所设计的组件类型和可能用于进行文档设计的组织标准。

数据模型

很多组件有自己的数据库表，或依赖于现有数据库模式。这一部分描述组件使用的模式和数据，可以包含：

• 逻辑或物理数据模型
• 任何在组件外进行的相关数据加载或转换。例如，如果需要进行某个 ETL 流程来管理或合并数据，请在此列出该流程。
• 如果要创建任何业务或对象模型或将其用于此组件，也请在此处加以描述。这些可以是专为您的项目创建的或项目使用的行业标准。

用户界面和交互模型

用户界面文档大多数情况下是由信息架构师、人类工程学工程师或图形设计师提供的。可以将组件设计文档提供给担任此类角色的人员，以便他/她添加描述用户流的模型。开发人员可使用这些模型来实现组件。

事实上，有些项目并没有任何信息架构师、人类工程学工程师或图形设计师，因此开发人员必须创建用户界面。不管谁最终创建 Portlet 皮肤设计，都应在设计文档的这一部分进行记录。如果没有任何设计，在这一部分插入一个最终界面的屏幕截图，并附上描述性文本。

不过，用户界面设计实际不应由开发人员负责。在非常简单的情况下可以这样，但设计用户界面所要求的技能与实现界面背后的功能所需的技能并不相同。您的团队应具有信息架构师或用户界面设计师提供服务，担任此类角色的人员可以与客户进行沟通，以理解和建模任务流，并随后设计用户界面。

测试规范

过去，测试是项目中最常被忽略的阶段之一。我们将这一部分包含在设计文档，目的是为了帮助在项目内强制实施一些测试要求。面对所有不同类型的测试类型（如单元测试、功能测试、集成测试、黑盒测试和白盒测试等），可能让人不知所措，不知道应进行哪种类型的测试以及何时进行测试。在大多数项目中，单元测试是计划中的一个常规项；不过，执行不易理解的单元测试却是最难的。随着敏捷方法的出现，对很多项目都可以成功进行单元测试了。

开发人员在开发过程中运行的测试通常称为单元测试，可帮助确保代码的正确性。集成和功能测试在不同组件组合到一起并已可以部署时进行。（很多情况下这不过是确定那些测试如何执行，以及计划何时进行测试。）

功能测试在门户和门户组件的生命周期中非常重要；当对代码进行了更改时，要求进行回归测试。在以后的文章中，我们将集中讨论测试的执行。开发团队务必与质量保证 (QA) 或测试团队密切合作，以确保开发阶段的平稳过渡，并促进对潜在问题的沟通。将代码组件直接抛给测试人员，然后甩手不管，无疑会带来问题，相反，应让测试人员和开发人员时常碰头，以便测试人员编写测试脚本。开发人员将会了解到他们从来没有想到的问题，而这样做将帮助团队成员学习如何彼此进行沟通。

如果您的项目测试要求很多，就可以很容易地完成这一部分。至少应让开发人员在这一部分中包含一些手动编写的测试，他/她将运行这些测试来确保组件按照需求中描述的方式工作。这些测试用例可以非常简单，如一组可以在必要时应用到组件的输入和结果值。请包括失败的用例和通过的条件。此文档不仅可以确保开发人员能更深入地了解组件，还可以提供一组初始工作测试集，以供以后的团队了解和评估组件。

部署指南

即使最简单的组件也有需要采用在部署和配置期间进行的步骤。利用用这一部分来描述如何创建数据源、配置参数和定义部署顺序。尽管开发人员凭直觉就能理解此流程，但可能在将项目投入生产时进行开发和操作交接的过程中丢失这些信息。因此，这一部分的目的在于帮助在项目整个生命周期中捕获此信息。

在任务繁重而时间又紧急的项目中，开发人员经常抱怨没有时间更新文档。开发人员至少需要对组件部署的一些基本信息进行记录。开发团队负责人或构建和部署管理人员需要确保开发人员完成了所需的文档，且其详细程度符合团队的要求。这一部分提供方便团队捕获此信息的机制；不过不能对任何项目的执行情况进行编造或假设。

假定、问题和依赖关系

这一部分向团队成员提供记录关于组件的问题和顾虑的集中位置。其目标是在出现问题时实时地捕获问题。很多团队通过电子邮件报告问题。此方法的问题在于，必须对众多电子邮件进行搜索，才能收集到所有出现的问题。依赖关系是在这一部分列出的另一个内容。例如，很多 Portlet 和组件都具有后端依赖关系，需要对此加以记录，以供将来参考。