第8章面向对象设计精选文档.ppt

《第8章面向对象设计精选文档.ppt》由会员分享，可在线阅读，更多相关《第8章面向对象设计精选文档.ppt（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第8章 面向对象设计本讲稿第一页，共二十六页教学重点教学重点掌握通过统一建模语言进行面向对象掌握通过统一建模语言进行面向对象分析分析理解设计活动包括的四个方面理解设计活动包括的四个方面掌握面向对象设计的基本原则掌握面向对象设计的基本原则能够将分析模型转变为设计模型能够将分析模型转变为设计模型本讲稿第二页，共二十六页8.1 面向对象分析面向对象分析8.1.1 优化用例模型优化用例模型 为了文件管理以及用户阅读，我们还会生成参与者词汇为了文件管理以及用户阅读，我们还会生成参与者词汇表、用例词汇表和用例描述表。表、用例词汇表和用例描述表。表表8-1 8-1 参与者词汇表参与者词汇表编号词汇同义词描述

2、表表8-2 8-2 用例词汇表用例词汇表编号用例名称用例描述参与者本讲稿第三页，共二十六页表表8-3 8-3 用例描述表的高层版本用例描述表的高层版本作者：作者：_ 日期：日期：_ 版本：版本：_用例名称 用例类型：业务需求：系统分析 用例ID优先权来源主要业务参与者其他业务参与者其他有利益的关联人员描述本讲稿第四页，共二十六页表表8-4 用例描述表的扩展版本用例描述表的扩展版本 作者：作者：_ 日期：日期：_ 版本：版本：_用例名称用例类型：业务需求：系统分析：用例ID优先权来源主要业务参与者其他业务参与者其他有利益的关联人员描述前置条件触发器典型事件过程参与者动作系统响应替代事件过程结论后

3、置条件业务规则实现约束和说明假设开放问题本讲稿第五页，共二十六页为了进行对象建模，需要将业务需求用例模型转为了进行对象建模，需要将业务需求用例模型转换成分析用例模型。换成分析用例模型。1确定、定义并记录新的参与者确定、定义并记录新的参与者2确定、定义并记录新的用例确定、定义并记录新的用例3确定任何复用的可能性确定任何复用的可能性4细化用例模型图细化用例模型图5记录系统分析用例描述记录系统分析用例描述6记录抽象用例描述和扩展用例描述记录抽象用例描述和扩展用例描述本讲稿第六页，共二十六页表表8-5 8-5 抽象抽象/扩展用例描述表的版本扩展用例描述表的版本 作者：作者：_ 日期：日期：_ 版本：版

4、本：_用例名称抽象：扩展：用例ID优先权来源参与者描述前置条件典型事件过程替代事件过程后置条件本讲稿第七页，共二十六页绘制建模活动图绘制建模活动图绘制系统顺序图绘制系统顺序图确定业务对象确定业务对象组织对象及其关系组织对象及其关系本讲稿第八页，共二十六页1确定多重性和关联关系确定多重性和关联关系表表8-6 8-6 矩阵法矩阵法对象/类01对象/类02对象/类03对象/类01X对象/类02X对象/类03XX2确定泛化关系确定泛化关系3确定聚合确定聚合/组合关系组合关系4准备类图准备类图本讲稿第九页，共二十六页8.2 从分析到设计从分析到设计从面向对象分析对问题域的分析结果出发，从问题域、人机从面

5、向对象分析对问题域的分析结果出发，从问题域、人机交互、任务管理和数据管理四个部分出发，针对实现的要求交互、任务管理和数据管理四个部分出发，针对实现的要求进行必要的增补和调整。进行必要的增补和调整。图图8.1 8.1 面向对象设计的四个部分面向对象设计的四个部分本讲稿第十页，共二十六页8.3 面向对象设计面向对象设计8.3.1 问题域部分的设计问题域部分的设计在进行问题域部分进行设计时，至少从以下四个方面来对在进行问题域部分进行设计时，至少从以下四个方面来对分析模型进行增补修改：分析模型进行增补修改：增加一般类增加一般类实现复用实现复用提高性能提高性能完善细节完善细节 本讲稿第十一页，共二十六页

6、8.3.2 人机交互部分的设计人机交互部分的设计对人的分类与描述对人的分类与描述设计命令层设计命令层为了细化命令层，要考虑排列、整体部分组为了细化命令层，要考虑排列、整体部分组合、宽度与深度的对比、减少操作步骤等问题。合、宽度与深度的对比、减少操作步骤等问题。不断原型化不断原型化设计人机交互部分的类设计人机交互部分的类在很大程度上依赖于所选用的图形用户界面，在很大程度上依赖于所选用的图形用户界面，如如X Window、Motif、Windows、Presentation Manager、MacApp或或Smalltalk 本讲稿第十二页，共二十六页8.3.3 任务管理部分的设计任务管理部分的设

7、计识别事件驱动任务；识别事件驱动任务；识别时钟驱动任务；识别时钟驱动任务；识别优先任务和关键任务；识别优先任务和关键任务；识别协调者；识别协调者；审查每个任务；审查每个任务；定义每个任务定义每个任务本讲稿第十三页，共二十六页8.3.4 数据管理部分的设计数据管理部分的设计 1.如果用文件系统实现对象的存储，那么在分析与如果用文件系统实现对象的存储，那么在分析与设计阶段为应用系统识别、定义的对象，在实现时将被设计阶段为应用系统识别、定义的对象，在实现时将被表示成文件中的数据。表示成文件中的数据。2.关系数据库存储对象的方式是将对象的属性存关系数据库存储对象的方式是将对象的属性存储在数据库中的二维

8、表中，表中的列存储对象的简单储在数据库中的二维表中，表中的列存储对象的简单属性，对于对象的复杂属性，可以将其分解为简单属属性，对于对象的复杂属性，可以将其分解为简单属性，并在其他二维表中存储。性，并在其他二维表中存储。本讲稿第十四页，共二十六页表表8-7 8-7 不同的数据管理系统的讨论不同的数据管理系统的讨论数据管理方法文件系统数据库系统关系数据库系统面向对象数据库系统基本概念与原理文件系统一般是操作系统中的一个组成部分。它采用标准、统一的方法对外部存储器中的文件（数据）进行管理，提供存储、检索、更新、共享和保护功能。在文件系统的支持下，应用程序不必直接操纵物理存储设备而实现数据的管理。数据

9、库技术是信息系统中的重要技术组成和应用部分。数据库是在计算机中长期存储、组织、管理和共享的数据集合。数据库先后出现过层次数据模型、网络数据模型、关系数据模型和面向对象的数据模型等。其中，关系数据库是目前使用最为广泛的数据库，面向对象的数据库则是面向对象在数据库领域的扩展和应用。用二维表表示各种数据。列称作属性，行称作元组，整个表成为一个关系。一个二维表既可以用来存放实体本身的特征及其属性，也可以存放实体之间的关系。表与表之间也定义了相应的操作。必须具有两个特征：首先必须是面向对象的，即支持对象、类、继承、封装、多态；其次，必须是数据库系统应有的特征和功能，即必须提供数据定义与操纵语言、数据库维

10、护、事务运行管理等功能。成熟程度比较成熟比较成熟不太成熟价格低廉（通常不需要单独购买）根据规模选择，价格可高可低价格昂贵技术上的优点几乎可以存储任何类型的数据。在数据存取、数据共享、完整性、故障恢复和事务处理等方面有很强的能力。非常适合需保存、管理大量数据的应用系统的需要，而且数据访问方法已标准化(SQL标准)，开发接口也基本统一。系统开发的各个阶段从系统分析、系统设计到系统实现由于采用统一的方法，如果数据管理也采用面向对象的数据库系统，则整个过程不存在表示的不一致和技术的差异。技术上的缺陷操作低级，需要精确控制文件中的各项数据，而且不同人员可以设计自己的文件格式，造成文件的种类繁多，互相之间

11、不兼容，而且数据的完整性、共享等方面的功能存在缺陷。数据模式的限制较多，例如，数据库中的表必须至少是第一范式，即表中每个属性必须是原子的，不能有内部结构。而在面向对象中，对象的属性可以是原子的，也可以是结构的和对象的，因此需要进行转换才能完成存储对象的数据。本身技术尚不成熟，且具体的面向对象的数据库系统之间存在较大的差异，满足面向对象的数据模型的程度不一。本讲稿第十五页，共二十六页8.4 面向对象设计原则面向对象设计原则8.4.1 开放封闭原则开放封闭原则一个模块在扩展性方面应该是开放的，而在更改性方面一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量

12、考虑接口应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。封装机制、抽象机制和多态技术。图图8.2 8.2 开放封闭原则示例开放封闭原则示例本讲稿第十六页，共二十六页8.4.2 单一职责原则单一职责原则一个类应该有且仅有一个职责。一个类应该有且仅有一个职责。类的职责类的职责:指引起该类变化的原因。如果一个类有一个指引起该类变化的原因。如果一个类有一个以上的职责，就会有多个不同原因引起该类变化，即耦合了以上的职责，就会有多个不同原因引起该类变化，即耦合了多个互补相关的职责，将会降低类的内聚性。多个互补相关的职责，将会降低类的内聚性。图图8.3 8.3 单一职责原则

13、示例单一职责原则示例本讲稿第十七页，共二十六页8.4.3 Liskov替换原则替换原则由由Liskov于于1987年提出。年提出。子类应当可以替换父类，并且能够出现在父类出现的任子类应当可以替换父类，并且能够出现在父类出现的任何地方。何地方。图图8.4 Liskov替替换换原原则则示例示例 应该尽量把类B设计为抽象类或接口类，让C类继承B，并实现操作A和B。运行时，类C实例替换B，这样即可进行新类的扩展，同时无须对类A进行修改。本讲稿第十八页，共二十六页图图8.5 违违反替反替换换原原则则的示例的示例 图图8.6 改改进进后的示例后的示例本讲稿第十九页，共二十六页8.4.4 依赖倒置原则依赖倒

14、置原则高层模块不应该依赖于低层模块，二者都应该依赖于抽象；高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。具体做法是将高层需要的服务声明为抽象接口，高层使用这具体做法是将高层需要的服务声明为抽象接口，高层使用这些接口，低层模块实现这些接口，使得高层不再依赖于低层，些接口，低层模块实现这些接口，使得高层不再依赖于低层，而是依赖于抽象接口，同样低层也依赖于抽象接口。而是依赖于抽象接口，同样低层也依赖于抽象接口。本讲稿第二十页，共二十六页图图8.7 不成熟的模型不成熟的模型 图图8.8 应应用依用依赖赖倒置原倒置

15、原则则的示例的示例 本讲稿第二十一页，共二十六页8.4.5 接口隔离原则接口隔离原则用来解决用来解决“肥胖的肥胖的”接口所具有的缺点。接口所具有的缺点。如果一个类（或接口类）不具备高内聚性，就表示该类具有如果一个类（或接口类）不具备高内聚性，就表示该类具有“胖胖”的接口。的接口。一个接口被隔离成多组方法后，可能存在这样的类，它们需要用到一个接口被隔离成多组方法后，可能存在这样的类，它们需要用到两组方法或者更多，要实现这样的客户程序可以采用委托模式或多两组方法或者更多，要实现这样的客户程序可以采用委托模式或多继承模式。继承模式。本讲稿第二十二页，共二十六页8.5 面向对象设计过程面向对象设计过程

16、8.5.1 精炼用例模型精炼用例模型1将分析用例转换成设计用例将分析用例转换成设计用例2修改用例模型图和其他文档以反映新用例修改用例模型图和其他文档以反映新用例本讲稿第二十三页，共二十六页表表8-8 8-8 设计用例描述表设计用例描述表 作者：作者：_ 日期：日期：_ 版本：版本：_ 用例名称用例类型：业务需求：系统分析：系统设计：用例ID优先权来源主要业务参与者其他业务参与者其他有利益的关联人员描述前置条件触发器典型事件过程参与者动作系统响应替代事件过程结论后置条件业务规则实现约束和说明假设开放问题本讲稿第二十四页，共二十六页8.5.2 建模支持用例情境的类交互、行为建模支持用例情境的类交互、行为和状态和状态1确定并分类用例设计类确定并分类用例设计类实体类实体类接口类接口类控制类控制类 2确定类属性确定类属性3确定类操作和责任确定类操作和责任4建模对象状态建模对象状态本讲稿第二十五页，共二十六页8.5.3 修改对象模型以反映实现环境修改对象模型以反映实现环境1添加对象及其相关添加对象及其相关向图中添加设计对象。向图中添加设计对象。向设计对象中添加属性和属性类型。向设计对象中添加属性和属性类型。添加属性可见性，即公共的添加属性可见性，即公共的(+)、保护的、保护的(#)和私有的和私有的(-)。2添加操作及其相关添加操作及其相关3添加导航能力添加导航能力本讲稿第二十六页，共二十六页