面向对象的概念面向对象的开发过程面向对象分析与模型化面

面向对象的概念面向对象的开发过程面向对象分析与模型化面内容摘要：

query date, expiration agreement, plimentary subscription date, expired distributorpublisher review daleted, plimentary annual subscription price plimentary subscription subscription article deleted department, accounting associated site constituent copies department, corporate author continued subscription direct subscription author, contributing contributing author discount, subscription … …  对于任一有用的应用论域资源， PFA可能会产生一个长长的概念的清单。  许多被标识出的概念因与目标软件无关而被丢弃，但其它的则会成为 OOA模型的成份，包括对象。  将 PFA清单转换为 OOA／ OOD工作表格。 列出对各个概念的理解和选择，这将有助于对象的选出。 Small Bytes 订阅系统 OOA ／ OOD 工作表格 条 目 (0) (1) (2) (3) (4) (5) (6) (7) (8) 注 释 ACCEPTION SUBSCRI P TION SUBSCRIPTION 的属性 ACCOMPANIED PA Y MENT 对 payment 的不同类型不加 以区分 ACCOUNTING DEPAR T MENT 已超出 SBSS 的应用论域 ACTUAL EXPIRATION DATE SUBSCRIPTION 的属性 ADDITIONAL SU B SCRIPTION SUBSCRIPTION 的可能属 性 , 或可能是派生类型 基 类型结构 ARTICLE ASSOCIATED SITE SITE 的属性 AUTHOR ..................... (0) 不适用 , 可能无关 , 超出指定系统的环境 (4) 可能描述对象的服务 (1) 可能的对象－类 (5) 与实现相关 , 可能是属于问题论域部分的条目 (2) 可能是派生类型－基类型结构的一部分 (6) 可能是属于人机交互部分的条目 包括泛化－特化结构和整体－部分结构 (7) 可能是属于任务管理部分的条目 (3) 可能描述对象－类的属性或实例关系 (8) 可能是属于数据管理部分的条目 标识结构  面向对象分析的下一步工作是 标识结构。 典型的结构有两种：  一般化 特殊化结构 （ GenSpec结构 ）  整体 部分结构 （ WholePart结构 ） 一般化 特殊化结构 整体 部分结构  以特殊化的视点来看，一个 GenSpec结构 可以看作是“ is a”或“ is a kind of”结构。 例如， a Truck Vehicle is a Vehicle a Truck Vehicle is a kind of Vehicle  在 GenSpec结构 中，使用 继承 将较一般化的属性和服务放在一般化的类和对象中。  从整体的视点来看，一个 WholePart结构 可看作一个“ has a”或“ is a part of”结构。 例如， Vehicle has a Engine Engine is a part of Vehicle  其中， Vehicle是整体对象， Engine是局部对象。 标识 GenSpec结构的方法和策略  对于每一个类和对象， 将它看作是一个一般化的类 ，对它的所有特殊情况，考虑以下问题：  它是否在问题论域中。  它是否在系统的职责内。  继承性是否存在。  它是否能够符合选择类和对象的标准。  同样地， 把每一个类和对象置于特殊化对象的地位 ，对于它所有的一般化情形，考虑上述 4个问题。  检查以前在相同或类似问题论域中面向对象分析的结果，看是否有可直接复用的 GenSpec结构。  如果一个一般化对象可能有多个特殊化对象，应当先考虑 最简单的特殊化对象 和 最复杂的特殊化对象 ，然后再考虑中间其他的特殊化对象。 标识 WholePart结构的方法和策略  应当寻找什么  总体 部分 （ AssemblyParts）关联，如 飞机 发动机 之间的关系。  包容 内含 （ ContainerContent）关联，如 飞机 飞行员 之间的关系。  收集 成员 （ CollectionMembers）关联，如 机构 职员 之间的关系。  将每一个类 看作是一个 Whole类 ，对它的所有可能 Parts情况，考虑以下问题：  它是否在问题论域中。  它是否在系统的职责内。  它是否代表一个以上的状态值。  若不是，是否将它变为 Whole中的一个属性。  它是否提供问题论域中有用的抽象。  同样地， 把每一个类置于 Part 的地位 ，对于它所有的 Whole情形，考虑上述 5个问题。  检查以前在相同或类似问题论域中面向对象分析的结果，看是否有可直接复用的 WholeParts结构。 标识属性  下一个层次称为属性层，对前面已识别的类和对象做进一步的说明。 在这里， 对象所保存的信息称为它的属性。  类的属性 所描述的是 状态信息 ，每个实例的属性值 表达了 该实例的状态值。 标识属性的方法和策略  找出属性  将属性安放到适当的位置  找出实例连接  检查特殊情况  描述属性  考虑取值范围、极限值、缺省值、建立和存取权限、精确度、是否会受到其他属性值等。 属性层 实例连接关系的标识 定义服务  对象收到消息后所能执行的操作称为它可提供的服务。  对每个对象和结构的 增加 、 修改 、删除 、 选择 等服务 有时是隐含的 ，在图中不标出，但在存储类和对象有关信息的对象库中有定义。  其它服务则必须显式地在图中画出。 服务层 定义服务的方法和策略  找出每一个对象的所有状态，在各种状态需要做的工作。 利用状态迁移图；  找出必要的操作。  建立消息连接。  描述服务：利用状态转换图、脚本和事件追踪图，描述服务的功能。 消息连接的标识  两个对象之间可能存在着 由于通信需要而形成的关系 ，这称为 消息连接。  消息连接表示从一个对象发送消息到另一个对象，由那个对象完成某些处理。 它们在图中用箭头表示，方向从发消息的对象指向收消息的对象。 找出消息连接的方法及策略  对于每一个对象，执行：  查询该对象需要哪些对象的服务，从该对象画一箭头到哪个对象；  查询哪个对象需要该对象的服务，从那个对象画一箭头到该对象；  循消息连接找到下一个对象，重复以上步骤。 识别主题  主题可以看成是高层的模块或子系统。  对于面向对象分析模型， 主题表示此模型的整体框架。 可以是一 个 层次结构。  通过对主题的识别，可以让人们能够比较清晰地了解大而复杂的模型。 编辑管理的主题 识别主题  将 每一种结构 （包括 整体 部分结构 、和 一般化 特殊化结构 ） 中最上层的类提升成为主题 ；  将各不属于任何结构的类提升主题 ；  检查在相同或类似的问题论域中以前做面向对象分析的结果，看是否有可直接复用的主题。 面向对象设计 （ OOD）  面向对象设计继续做面向对象分析阶段的工作，建立软件的结构。  主要工作分为两个阶段：  高层设计  类设计 高层设计  高层设计阶段开发系统的结构，即构造应用软件的总体模型。  高层设计阶段 标识在计算机环境中进行问题解决工作所需要的概念 ，并增加了一批需要的类。  这些类包括那些可使应用软件与系统的外部世界交互的类。  此阶段的输出是 适合应用软件要求的类 、 类间的关系 、 应用的子系统视图规格说明。 高层设计模型 高层设计的特点  高层设计可以表征为 标识和定义模块的过程。  模块可以是一个单个的类，也可以是由一些类组合成的子系统。  定义过程是职责驱动的。  类接口的协议如同“合同” ：需方提出的请求必须列在协议表中，供方则必须提供所有协议的服务。 高层设计应遵循的原则  应使得在子系统的各个高层部件之间的通信量达到最小；  子系统应当把那些成组的类打包，形成高度的内聚；  逻辑功能分组，提供一个一个单元，识别并定位问题事件； 类设计  类与具有概念封装的子系统十分类似。  每个子系统都可以被当做一个类来实现 ，这个类聚集它的部件，提供了一组操作。  类和子系统的结构是正交的， 一个单个类的实例可能是不止一个子系统的一部分。  高层设计和类设计这两个阶段是 相对封闭 的。  应用软件中的每一个事物都是一个对象 ，包括应用软件自身在内 !  两个阶段是连接的。  应用软件的设计是大类的设计，这种类设计考察应用软件所期望的每一个行为，并利用这些行为形成应用类的界面。 Coad 与 Yourdon 高层设计方法  Coad 与 Yourdon 在设计阶段中继续采用分析阶段中提到的五个层次。  在设计阶段中，这五个层次用于建立系统的四个组成成份。  问题论域部分  人机交互部分  任务管理部分  数据管理部分 问题论域部分  问题论域部分 包括与应用问题直接有关的所有类和对象。  识别和定义这些类和对象的工作在 OOA中已经开始 ，在 OOA阶段得到的有关应用的概念模型描述了我们要解决的问题。  在 OOD阶段，应当继续 OOA阶段的工作， 对在 OOA中得到的结果进行改进和增补。 问题论域部分的设计  在 OOA阶段得到的概念模型描述了要解决的问题  在 OOD阶段，继续 OOA阶段的工作，对在 OOA中得到的结果进行改进和增补。  对 OOA模型中的某些类与对象、结构、属性、操作进行组合与分解。  要考虑对时间与空间的折衷、内存管理、开发人员的变更、以及类的调整等。  根据问题解决的需要，把从类库或其它来源得到的既存类增加到问题解决方案中去。  标明既存类中不需要的属性和操作，  增加从既存类到应用类之间的一般化 特殊化的关系。  把应用类中因继承既存类而成为多余的属性和操作标出。  修改应用类的结构和连接。  在设计时， 从类库中引进一个根类，做为包容类，把所有与问题论域有关的类关联到一起，建立类的层次。  把同一问题论域的一些类集合起来，存于类库中。 3. 加入一般化类以建立类间协议  有时，某些特殊类要求一组类似的服务。  此时，应加入一个一般化的类，定义为所有这些特殊类共用的一组服务名，这些服务都是虚函数。  在特殊类中定义其实现。 4. 调整继承支持级别  在 OOA阶段建立的 对象模型中可能包括有多继承关系 ，但实现时使用的程序设计语言可能只有单继承，甚至没有继承机制，这样就需对分析的结果进行修改。  多继承模式有两种：  狭义的菱形  广义的菱形 针对单继承语言的调整  把特殊类的对象看做是一个一般类对象所扮演的角色，通过实例连接把多继承的层次结构转换为单继承的层次结构。  把多继承的层次结构平铺，成为单继承的层次结构。 在这种情况下，有些属性或操作在同层的特殊类中会重复出现。 针对无继承语言的调整  当使用无继承的程序设计语言时，必须把具有继承关系的类层次结构平铺开来，成为一组类和对象。  一般可利用命名惯例，把这些类或对象关联起来。 5. 改进性能  提高执行效率和速度是系统设计的主要指标之一。 有时， 必须改变问题论域的结构以提高效率。  如果类之间经常需要传送大量消息，可合并相关的。