李彤博士精选版.pptVIP

抽象与逐步求精原则 针对某个事物的宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至得到能用程序语言描述的算法实现为止。因为求精的每一步都是用更为详细的描述代替上一层次的抽象描述，所以在整个面向对象设计过程中产生的具有不同详细程度的各种描述组成了系统的层次结构。层次结构的上一层是下一层的抽象，下一层是上一层的求精。由于对象、类是组织程序的基本单元，因此在过程求精的同时自然伴随着对象和类的求精。无论是过程还是对象，每个求精步骤都蕴含着某些设计决策，因此设计人员必须掌握一些基本的准则和各种可能的候选方法。 模块化与信息隐藏原则 软件体系结构就体现了模块化思想，把软件划分为可独立命名和访问的构件，每个构件称为一个模块。当把所有模块组装到一起时则获得了满足问题需要的一个解。下面的标准可以用来评价所采用的设计方法的效果，并能体现最终系统中模块划分的有效性以及模块化系统的能力。 模块可分解性、模块可组装性、模块可理解性、模块连续性、模块保护。 内聚与耦合原则 为了提高模块化设计的有效性，很显然每个模块应该相对独立，其功能应该相对单一，而模块之间的接口应该尽可能简单，这可以用内聚和耦合这两个概念来刻画。软件的模块化设计应追求高内聚，低耦合。关于高内聚、低耦合的要求与结构化设计要求基本一致。 面向对象设计过程 1. 问题域设计 2. 用户界面设计 3. 驱动控制设计 4. 数据模型设计 5. 类设计 6. 部署模型设计 8.2　问题域设计 问题域模型所包含的对象都是与问题域有关的。从这个意义上讲，它和面向对象分析模型所涉及的问题范畴是一致的。但是二者属于不同的抽象层次。面向对象分析模型忽略了系统的实现条件，只考虑问题域，因此抽象层次较高。面向对象设计模型中的问题域模型则是按选定的实现条件对面向对象分析模型进行具体化，因此抽象层次低于面向对象分析模型。 对问题域模型的补充或修改 1. 完善用例图 2. 完善类细节 3. 修改或补充时序图、活动态、状态图等 4. 调整需求 5. 重用已有的类 6. 把问题域类组合在一起 7. 增添一般类以建立协议 8. 调整继承层次 9. 对多态性的调整 10. 提高性能 完善用例图 随着对待开发系统问题域和系统责任的了解，软件工程师对用例的理解也变得更加清晰。因此，需要在设计阶段重新复审在需求分析阶段获取的用例，并对用例进行适当的修改、添加或归并。 完善类细节 面向对象设计过程需要在面向对象分析过程的基础上细化和补充前一阶段的成果。在面向对象设计阶段设计人员针对类图需要完成如下工作： 1) 针对问题域部分的每个类检查它是否具备了表达问题域所需的所有属性和服务。凡是缺少的都应当补充完备。 2) 针对类的每一个属性和服务，检查它对于设计阶段而言的定义是否完整。 3) 针对类之间的关联，审查是否表达了类之间的所有关系。 完善后的类图 依赖 聚合 泛化 关联 消息传递 修改或补充时序图、活动态、状态图 由于增加了交易类，因此ATM系统的时序图、活动图和状态图均需要做出相应的修改，以反映设计的结果。 增加了交易类的时序图 调整需求 有两种情况会导致修改通过面向对象分析所确定的系统需求：一是用户需求或外部环境发生变化；二是分析员对问题域理解不透彻或缺乏领域专家帮助，以致面向对象分析模型不能完整、准确地反映用户的真实需求。无论出现上述哪种情况，通常都只需简单地修改面向对象分析结果，然后再把这些修改反映到问题域子系统中。 重用已有的类 代码重用从设计阶段开始，在研究面向对象分析结果时就应该寻找使用已有类的方法。若因为没有合适的类可以重用而确实需要创建新的类，则在设计这些新类时，必须考虑到将来的可重用性。 重用已有的类 1) 选择有可能被重用的已有类，标出这些候选类中对本问题无用的属性和服务，尽量重用那些能使无用的属性和服务降到最低程度的类。 2) 在被重用的已有类和问题域类之间添加泛化关系（即从被重用的已有类派生出问题域类）。 3) 标出问题域类中从已有类继承来的属性和服务，现在已经无须在问题域类内定义它们了。 4) 修改与问题域类相关的关联，必要时改为与被重用的已有类相关的关联。 把问题域类组合在一起 在面向对象设计过程中，设计者往往通过引入一个根类而把问题域类组合在一起。事实上，这是在没有更先进的组合机制可用时才采用的一种组合方法。此外，这样的根类还可以用来建立协议。 增添一般类以建立协议 在设计过程中常常发现，一些具体类需要有一个公共的协议，也就是说，它们都需要定义一组类似的服务（很可能还需要相应的属性）。在这种情况下可以引入一个附加类（例如，根类），以便建立这个协议（即命名公共服务集合，这些服务在