1、设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。你必须找到相关的对象，以适当的粒度将它们归类，再定义类的接口和继承层次，建立对象之间的基本关系。你的设计应该对手头的问题有针对性，同时对将来的问题和需求也要有足够的通用性。你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你，要一下子就得到复用性和灵活性好的设计，即使不是不可能的至少也是非常困难的。一个设计在最终完成之前常要被复用好几次，而且每一次都有所修改。有经验的面向对象设计者的确能做出良好的设计，而新手则面对众多选择无从下手，总是求助于以前使用过的非面向对象技术。内行的设计者知道：不是解决任何问题都要从头
2、做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案，他们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此，你会在许多面向对象系统中看到类和相互通信的对象的重复模式。这些模式解决特定的设计问题，使面向对象设计更灵活、优雅，最终复用性更好。它们帮助设计者将新的设计建立在以往工作的基础上，复用以往成功的设计方案。我们都知道设计经验的重要价值。你曾经多少次有过这种感觉你已经解决过了一个问题但就是不能确切知道是在什么地方或怎么解决的？如果你能记起以前问题的细节和怎么解决它的，你就可以复用以前的经验而不需要重新发现它。然而，我们并没有很好记录下可供他人使用的软件设计经验。面向对象软
3、件设计的目的就是将设计经验作为设计模式记录下来。将每一个设计模式系统地命名、解释和评价，展现面向对象系统中重要和重复出现的设计。目标是将设计经验以人们能够有效利用的形式记录下来，将一些最重要的设计模式以编目分类的形式展现出来。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。通过提供一个显式类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快更好地完成系统设计。设
4、计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。1.模式名称（pattern name）一个助记名，它用一两个词来描述模式的问题、解决方案和效果。2.问题(problem)描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。3.解决方案(solution)描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。4.效果(consequences)描述了模式应用的效果及使用
5、模式应权衡的问题。程序设计语言的选择非常重要，它将影响人们理解问题的出发点。我们的设计模式采用了Smalltalk 和C+层的语言特性，这个选择实际上决定了哪些机制可以方便地实现，而哪些则不能。若采用过程式语言，可能就要包括诸如“继承”、“封装”和“多态”的设计模式。相应地，一些特殊的面向对象语言可以直接支持我们的某些模式。怎样描述设计模式呢？图形符号虽然很重要也很有用，却还远远不够，它们只是将设计过程的结果简单记录为类和对象之间的关系。为了达到设计复用，必须同时记录设计产生的决定过程、选择过程和权衡过程。用统一的格式描述设计模式，每一个模式根据模板被分成若干部分。模板具有统一的信息描述结构，
6、有助于更容易地学习、比较和使用设计模式。模式名简洁地描述了模式的本质。一个好的名字非常重要，因为它将成为你的设计词汇表中的一部分。意图是回答问题的简单陈述：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？别名：模式的其他名称。动机：用以说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述。适用性：什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？你怎样识别这些情况？协作：模式的参与者怎样协作以实现它们的职责。效果：模式怎样支持它的目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？
7、实现：实现模式时需要知道的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题。面向对象程序由对象组成，对象包括数据和对数据进行操作的过程，过程通常称为方法或操作。对象在收到客户的请求(或消息)后，执行相应的操作。面向对象设计最困难的部分是将系统分解成对象集合。因为要考虑许多因素：封装、粒度、依赖关系、灵活性、性能、演化、复用等等，它们都影响着系统的分解，并且这些因素通常还是互相冲突的。对象在大小和数目上变化极大。它们能表示下自硬件或上自整个应用的任何事物。对象声明的每一个操作指定操作名、作为参数的对象和返回值，这就是所谓的操作的型构。对象操作所定义的所有操作型构的集合被称为
8、该对象的接口(i n t e r f a c e)。对象接口描述了该对象所能接受的全部请求的集合，任何匹配对象接口中型构的请求都可以发送给该对象。理解对象、接口、类和继承之类的概念对大多数人来说并不难，问题的关键在于如何运用它们写出灵活的、可复用的软件。为了设计适应变化、且具有健壮性的系统，你必须考虑系统在它的生命周期内会发生怎样的变化。一个不考虑系统变化的设计在将来就有可能需要重新设计。这些变化可能是类的重新定义和实现，修改客户和重新测试。重新设计会影响软件系统的许多方面，并且未曾料到的变化总是代价巨大的。1)大致浏览一遍模式特别注意其适用性部分和效果部分，确定它适合你的问题。2)回头研究结
9、构部分、参与者部分和协作部分确保你理解这个模式的类和对象以及它们是怎样关联的。3)看代码示例部分，看看这个模式代码形式的具体例子研究代码将有助于你实现模式。4)选择模式参与者的名字，使它们在应用上下文中有意义设计模式参与者的名字通常过于抽象而不会直接出现在应用中。5)定义类声明它们的接口，建立它们的继承关系，定义代表数据和对象引用的实例变量。识别模式会影响到的你的应用中存在的类，做出相应的修改。6)定义模式中专用于应用的操作名称这里再一次体现出，名字一般依赖于应用。使用与每一个操作相关联的责任和协作作为指导。7)实现执行模式中责任和协作的操作实现部分提供线索指导你进行实现。代码示例部分的例子也
10、能提供帮助。设计模式不能够随意使用。通常通过引入额外的间接层次获得灵活性和可变性的同时，也使设计变得更复杂并/或牺牲了一定的性能。一个设计模式只有当它提供的灵活性是真正需要的时候，才有必要使用。当衡量一个模式的得失时，它的效果部分是最能提供帮助的。可以用三种方法编写软件需求规格说明：用好的结构化和自然语言编写文本型文档。建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以使你在变更请
11、求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。1)序列号最简单的方法是赋予每个需求一个唯一的序列号。2)层次化编码这也许是最常用的方法。3)层次化文本标签基于文本的层次化标签方案来标识单个需求。编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。应牢记以下几点建议：保持语句和段落的简短。采用主动语态的表达方式。编写具有正确的语法、拼写和标点的完整句子。使用的术语与词汇表中所定义的应该一致。需求陈述应该具有一致的样式，例如“系统必须.”或者“用户必须.”，并紧跟一个行为动作和可观察的结果。为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、
12、支持、许多、最新技术、优越的、可接受的和健壮的。避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。质量属性是很难定义的，并且他们经常造成开发者设计的产品和客户满意的产品之间的差异。就像Robert Charette(1990)指出的那样：“真正的现实系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能需求更为重要”。优秀的软件产品反映了这些竞争性质量特性的优化平衡。如果你在需求的获取阶段不去探索客户对质量的期望，那么产品满足了他们的要求，这只能说你很幸运。但更多的可能是客户失望和开发者沮丧。用户总是强调确定他们的功能、行为或需求软件让他们做的事情。除此之外，用户对产品如
13、何良好地运转抱有许多期望。这些特性包括：产品的易用程度如何，执行速度如何，可靠性如何，当发生异常情况时，系统如何处理。这些被称为软件质量属性(或质量因素)的特性是系统非功能（也叫非行为）部分的需求。虽然有许多产品特性可以称为质量属性(Quality Attribute)，但是在许多系统中需要认真考虑的仅是其中的一小部分。如果开发者知道哪些特性对项目的成功至关重要，那么他们就能选择软件工程方法来达到特定的质量目标。根据不同的设计可以把质量属性分类。一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开。另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。
14、那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。对用户最重要的属性对开发者最重要的属性：有效性（availability）可维护性(maintainability)高效性(efficiency)可移植性(p o r t a b i l i t y)灵活性(f l e x i b i l i t y)可重用性(r e u s a b i l i t y)完整性(integrity)可测试性(t e s t a b i l i t y)互操作性(i n t e r o p e r a b i l i t y)可靠性(r e l i a b
15、i l i t y)健壮性(r o b u s t n e s s)可用性(u s a b i l i t y)1)可维护性可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。2)可移植性可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。3)可重用性从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。4)可测试性可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。有时，不可避免地要对一些特定的属性对进行取舍。用户和开发者必须确定哪些属性比其它属性更为重要，并定出优先级。在他们作决策时，要始终
16、遵照那些优先级。软件需求规格说明正确描述了预期的系统行为和特征。从系统需求或其它来源中得到软件需求。需求是完整的和高质量的。所有对需求的看法是一致的。需求为继续进行产品设计、构造和测试提供了足够的基础。需求验证确保了需求符合需求陈述（requirement statement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）并且符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。从需求到项目规划：由于需求定义了项目预期的成果（o u t c o m e），所以
17、你的项目规划、预测和进度安排都必须以软件需求为基础。从需求到设计和编码：需求和设计之间存在差别，但尽量使你的规格说明的具体实现无倾向性。从需求到测试：详尽的需求是系统测试的基础，反过来只能通过测试来判断软件是否满足了需求。从需求到成功 需求管理强调：控制对需求基线的变动。保持项目计划与需求一致。控制单个需求和需求文档的版本情况。管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。跟踪基线中需求的状态。处于更高成熟度级别的组织把具有创造性、训练有素的员工同软件工程和项目管理过程结合起来，组织必须具有在软件开发与管理的六个关键过程域（key process areas，K P
18、A）以展示达到目标的能力。需求管理的目标如下：1)把软件需求建立一个基线供软件工程和管理使用。2)软件计划，产品和活动同软件需求保持一致。开发组织应该定义项目组执行管理他们需求的步骤。考虑选择以下主题：用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。建议、处理、协商、通告新的需求和变更给有关的功能域的方法。如何制定需求基线。将使用的需求状态，并且是谁允许作出的变更。需求状态跟踪和报告过程。分析已建议变动的影响应遵循的步骤。在何种情况下需求变更将会怎样影响项目计划和约定。除了文本，每个功能需求应该有一些相关的信息或称之为属性与之相联系。这些属性在它的预期功能性之外为每个需求建立了一个上下文和背景资料。属性值可以写在一张纸上，存储在一个数据库或需求管理工具中。考虑明确如下的属性：创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据（或信息的出处）需求涉及的子系统 需求涉及的产品版本号 使用的验证方法或接受的测试标准 产品的优先级或重要程度 需求的稳定性在考虑自行开发工具前先调查一下是否有可用的成熟工具。这些工具称为需求管理而不是需求开发工具。这些工具不会帮助你确认未来的客户或者从项目中获得正确的需求。然而，你可以获得许多灵活性，可用来在整个开发期间管理需求的变动，使用需求作为设计、测试、项目管理的基础。
