| 工件：设计 |
 |
 |
|
描述系统的元素，从而能够检查并理解它们，而这些不可能通过阅读源代码的方式进行。 |
| 主要描述 | 此工作产品描述了那些将用于实现系统的元素。它为特定的实现部分进行了可沟通的抽象。 当架构聚焦于接口、模式以及关键决策时，设计为做好实现准备充实了细节，或作为实现的一部分。 此工作产品为检查描述系统的多个静态和动态视图。虽然不同的视图可能聚集于有关系统如何被整合并工作的不同的、看起来互相独立的问题，但它们们应该彼此配合没有冲突。 |
|---|
| 模板 |
|---|
| 不具有的影响 | 实现将因细粒度的、不一致的战术决策，而导致低质量的软件。 |
|---|---|
| 不需要的原因 | 设计通常需要以某种形式进行表达，尽快它可以被源代码或测试捕获，并且没有明显的作为一个独立的工件。当项目已有对架构和设计的良好理解和策略时，你可能不需要进行新的设计。在这些情况中，可以简单的引用某些已有的设计。 |
| 说明选项 | 此工作产品的作者能够分析有关系统结构和行为的关键决策，并能够就此和其它合作者进行沟通，这很重要。同样重要的是，这些决策能够在不同的抽象级别和粒度上进行沟通。设计的某些方面可以在源代码中尽可能的添加额外的注释来表达。但是，更多的设计的抽象表达应该比源代码高一个层次。 更多的抽象描述可以通过不同的表达方式进行表述。可以严格的或非正式的使用UML；这是基于丰富语义的且在工业中广泛使用的符号表示法。也可以使用其他的技术来沟通设计。或者混合应用这些技术。 此过程没有对是使用白板还是使用正式的工具来记录这些描述进行限定。但是，任何描述，无论是正式的还是非正式的，都应该明确的沟通技术决策所呈现的设计。 |
| 核对表 | |
|---|---|
| 概念 | |
| 指南 |
This program and the accompanying materials are made available under the |