软件工程第11章面向对象设计探索.pptVIP

* * * * * * 可以引入一个关联类来保存描述关联性质的信息，关联中的每个连接对应着关联类的一个对象。实现关联对象的方法取决于关联的重数。对于一对一关联来说，关联对象可以与参与关联的任一个对象合并。对于一对多关联来说，关联对象可以与“多”端对象合并。如果是多对多关联，则关联链的性质不可能只与一个参与关联的对象有关，通常用一个独立的关联类来保存描述关联性质的信息，这个类的每个实例表示一条具体的关联链及该链的属性。 * * * * 应该使名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字。不同类中相似服务的名字应该相同。 * * * * * * * * * * * * * * * * 图11.7描绘了上章给出的ATM系统的问题域子系统的结构。 由于在面向对象分析过程中已经对ATM系统做了相当仔细的分析，而且假设所使用的实现环境能完全支持面向对象分析模型的实现，因此，在面向对象设计阶段无须对已有的问题域模型作实质性的修改或扩充。 * * * * 4. 设计人机交互类 人机交互类与所使用的操作系统及编程语言密切相关。例如，在Windows环境下运行的Visual C++语言提供了MFC类库，设计人机交互类时，往往仅需从MFC类库中选出一些适用的类，然后从这些类派生出符合自己需要的类就可以了。 * * * * * 关系数据库管理系统的理论基础是关系代数，它不仅理论基础坚实而且有下列一些主要优点： (1) 提供了各种最基本的数据管理功能(例如，中断恢复，多用户共享，多应用共享，完整性，事务支持等)。 (2) 为多种应用提供了一致的接口。 (3) 标准化的语言(大多数商品化关系数据库管理系统都使用SQL语言)。 但是，为了做到通用与一致，关系数据库管理系统通常都相当复杂，且有下述一些具体缺点，以致限制了这种系统的普遍使用： 扩展的关系数据库管理系统是在关系数据库的基础上，增加了抽象数据类型和继承机制，此外还增加了创建及管理类和对象的通用服务 * * * * 不同的软件系统中，这四个子系统的重要程度和规模可能相差很大: 某些系统仅有3个(甚至少于3个)子系统。 子系统之间的两种交互方式 客户-供应商关系 (Client-supplier) “客户”的子系统调用作为“供应商”的子系统，后者完成某些服务工作并返回结果。使用这种交互方案，作为客户的子系统必须了解作为供应商的子系统的接口，然而后者却无须了解前者的接口，因为任何交互行为都是由前者驱动的。 尽量使用客户-供应商关系。 (2) 平等伙伴关系(peer-to-peer)关系 每个子系统都可能调用其他子系统，因此，每个子系统都必须了解其他子系统的接口。这种组织系统的方案比起客户-供应商方案来，交互更复杂，从而使系统难于理解，容易发生不易察觉的设计错误。 3. 设计(分布式)系统的拓扑结构 由子系统组成完整的系统时，典型的拓扑结构有管道形、树形、星形等。设计者应该采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量。 ATM系统的星型结构实例 设计受具体实现环境的约束: 本项目预计要使用的编程语言 可用的软构件库(主要是类库) 程序员的编程经验。 注意：分析模型为设计奠定了基础, 应尽可能保留。 设计仅需从实现角度对模型做一些补充或修改： 增添、合并或分解类与对象、属性及服务，调整继承关系等。 11.5 设计问题域子系统 1. 调整需求 一是用户需求或外部环境发生了变化； 二是对象分析模型不能完整、准确地反映用户的真实需求。 2. 重用已有的类 重用已有类的典型过程如下： (1) 选择重用最相似的已有类。 (2) 从被重用的已有类派生出问题域类。 (3) 增加或修改问题域类中需要的属性和服务。 (4) 修改与问题域类相关的关联。 3. 增添一般化类以建立协议 一些类需要有一个公共的协议：类似的服务， 共同接口。可以引入一个根类以便建立这个协议。 人机交互子系统设计确定人机交互的细节，包括指定窗口和报表的形式、设计命令层次等。 原型是成功地设计人机交互的常用手段。 11.6 设计人机交互子系统 对象可以并发地工作。 对象可能存在相互制约的顺序执行关系。 设计工作的一项内容就是，确定哪些是必须/可能同时动作的对象，哪些是相互制约的对象。 11.7 设计任务管理子系统 1. 分析并发性 动态模型是分析并发性的主要依据。 对象彼此间不存在(间接/传递)交互则它们可以是并发的。 计算机中用任务(task)/进程(process)实现控制线。 并发行为既可以在不同的处理器上实现，也可以在单处理器上用多任务操作系统实现。 2. 设计任务管理子系统 任务分类: 事件驱动型任务、时钟驱动型任务、优先任务、关键任务和协调任务。