资源预览内容
第1页 / 共29页
第2页 / 共29页
第3页 / 共29页
第4页 / 共29页
第5页 / 共29页
第6页 / 共29页
第7页 / 共29页
第8页 / 共29页
第9页 / 共29页
第10页 / 共29页
亲,该文档总共29页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
面向对象的设计方法面向对象的设计方法1. 设计用例实现方案2. 设计技术支撑方案3. 设计用户界面4. 精化设计模型概述概述lOOA、OOD模型过渡平滑l分析以问题为中心,设计面向计算机实现。lOOD使得从问题空间到解空间的变换直观合理。lOOD更自然地遵循抽象、信息隐藏、模块化原则。lOOD完成信息和处理的双重模块化。lOOA、OOD、OOP阶段间反复迭代基于基于UML的的OOD概述概述l分析模型:顶层架构图、用例与用例图、领域概念模型。l设计模型:体系结构图(包图)、交互图、类图、状态图、活动图等。l任务:针对分析模型用例,设计用UML交互图表示的实现方案。设计技术支撑设施。非业务需求的一部分,但却为多种业务需求的实现提供公共服务,如:数据的持久存储服务、安全控制服务、远程访问服务等。设计用户界面。针对分析模型中的领域概念模型,以及第(2)、第(3)两个步骤引进的新类,完整、精确地确定每个类的属性、操作,完整地标示类之间的关系。设计过程:设计过程:1 设计用例实现方案设计用例实现方案l用例实现方案用交互图描述,交互图包括:顺序图、协作图l顺序图:描述对象之间动态的交互关系,着重表现对象间消息传递的时间顺序。例:下页图元素:对象、时间、生命线、生命终结、活跃期、消息(序号、条件表达式)、迭代标记*、描述信息等。UML消息的四种类型:简单消息简单消息:以一种简单、抽象的函数表示对象之间的信息传递,不考虑通信过程的内部细节。简单消息在UML顺序图中用普通的有向箭头表示。同步消息同步消息:消息源发出消息后必须等待消息处理过程完毕并返回处理结果后,消息源才可继续执行后续操作。前面所述的自调用消息应该是同步的。一般来讲同步消息的表示图元与简单消息相同,这表明UML在缺省情形下认为简单消息即为同步消息。异步消息异步消息:消息源发出消息后不必等待消息处理过程的返回,即可继续执行自己的后续操作。异步消息主要用于描述实时系统中的并发行为。异步消息在UML顺序图中用一种特别的单向箭头表示。返回消息返回消息: 表示前面发送的消息的处理过程完结之后的返回结果。返回消息应该是同步的。在许多情况下,可以隐藏返回消息,但也可显式标出返回消息以示强调。返回消息用虚线有向箭头表示,l协作图:描述相互合作的对象间的交互关系和链接关系,强调交互对象间的静态链接关系。例:见下页图元素:对象、链接、消息1 设计用例实现方案设计用例实现方案1 设计用例实现方案设计用例实现方案提取边界类、实体提取边界类、实体类和控制类类和控制类l边界类:用于描述目标软件系统与外部环境间的交互,功能:界面控制:界面控制:包括输入数据的格式及内容转换,输出结果的呈现,软件运行过程中界面的变化与切换等。外部接口:外部接口:实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨越目标软件系统边界的通信协议。环境隔离:环境隔离:将目标软件系统与操作系统、数据库管理系统、应用服务器中间件等环境软件进行交互的功能与特性封装于边界类之中,使目标软件系统的其余部分尽可能地独立于环境软件。l实体类:表示目标软件系统中具有持久意义的信息项及其操作。l控制类:完成用例任务的责任承担者,协调、控制其它类共同完成用例规定的功能或行为。l提取方法:一般执行者与用例之间的一种通信连接对应一个边界类;实体类主要来源于领域概念模型,在用例描述中也有;一般而言,一个用例通常对应一个控制类,也可能多个用例共享一个控制类或不设独立控制类的情况。1 设计用例实现方案设计用例实现方案构造交互图构造交互图l用例描述中,事件流中的事件直接对应于交互图中的消息,事件的顺序体现为交互图中的时序l用分离的交互图分别表示事件流和每个备选事件流l顺序图的布局规则:l协作图的布局规则:1 设计用例实现方案设计用例实现方案精化类图精化类图l利用交互图精化分析模型中的类图交互图中,对每个类的对象都规定了它必须响应的消息(对应类的操作)以及对象之间的消息传递通道(对应类间的连接关系) 。方法/操作:原则上,每个类都应有一个操作来响应交互图中每个类都应有一个操作来响应交互图中指向其对象的那条消息。指向其对象的那条消息。设计人员应尽量使用已有操作来响应新消息,并尽量使用已存在的连接路径作为消息传递通道。属性:类的操作完成消息响应责任的能力来源于两方面的知识:类本身具有的信息(属性),其它类的协助。2 设计技术支撑方案设计技术支撑方案l应用功能往往都需要一组技术支撑机制为其提供服务。l技术支撑方案是整个目标软件系统中全局性的公共技术平台。l技术支撑方案应具有良好的稳定性、开放性、可扩充性。l技术支撑方案的设计一方面取决于目标软件系统对公共技术服务的需求,另一方面取决于设计人员对软件技术手段的把握和选取。2 设计技术支撑方案设计技术支撑方案数据持久存储服务数据持久存储服务l目的:将目标软件系统中依赖于系统运行环境的数据存取部分与其它部分相分离。l数据持久存储服务的设计包括:定义数据格式定义数据存取操作2 设计技术支撑方案设计技术支撑方案并发与同步控制服务并发与同步控制服务l目的:将目标软件系统中依赖于系统运行环境的并发与同步控制部分和其他部分相分离。l功能:进程/线程的定义与启动、终止、状态查询、同步点设置及其在同步点的信息交换等。3 设计用户界面设计用户界面l用户界面设计的策略和步骤:熟悉用户并对用户分类。按用户类别分析用户工作流程与习惯。设计并优化命令系统。设计用户界面的各种细节。增加用户界面专用的类与对象。利用快速原型演示,改进界面设计。为人机交互部分构造原型,是界面设计的基本技术之一。4 精化设计模型精化设计模型l精化的任务:以顶层架构图为基础,精化目标软件系统的体系结构。精化类之间的关系。精化类的属性和操作。针对具有明显状态转换特征的类,设计状态图。(画图)针对比较复杂的类方法,设计活动图。 (画图)4 精化设计模型精化设计模型精化体系结构精化体系结构l目的:寻找一种理想的包划分方案,使得每个包中直接包含的类的数量规模适中,包的边界清晰、自然,并且包间的耦合度较低。l类间耦合:从高到低 :继承关系、构成关系、聚合关系、关联关系、依赖关系、两个类的对象受同一执行者变化的影响。l包的合并和分拆的目标:强内聚,松耦合l完全排除包间的依赖关系既无必要,也不合理。但是以下原则要尽量遵守:避免包间的循环依赖关系在层次结构中,位于较低层次的通用包不应当依赖于较高层次中的专用包。在层次结构中,较高层次的包可以依赖于较低层次的包,但此种依赖应尽量在相邻的层次间发生。如果针对某些子系统专门划分了接口包和实现包,那么,其他与该子系统相关的包只能依赖于接口包,不能依赖于实现包4 精化设计模型精化设计模型精化类间关系精化类间关系l详细研究类之间的关系: (一)判定类之间的关系是UML的依赖、关联、聚合或构成关系之一; (二)确定连接方向及数量关系; (三)根据软件重用及结构简洁、清晰的要求优化类的之间的关系。 关联类:关联关系本身具有属性和操作,如下图UML的依赖、聚合和构成关系的方向性很明显。对关联关系,进一的依赖、聚合和构成关系的方向性很明显。对关联关系,进一步考虑对象间的数量对应关系及对象在关联中扮演的角色。步考虑对象间的数量对应关系及对象在关联中扮演的角色。如下如下图图面向重用的类结构调整:抽取公共父类,如下图面向重用的类结构调整:抽取公共父类,如下图如果不允许修改被重用的类,如果不允许修改被重用的类,类之间建类之间建立单向的委托,立单向的委托,如下如下图图利用继承关系精化设计模型:引入父类多继承化解为单继承,如下图:按“强内聚、松耦合”、简单性、自然性等原则优化4 精化设计模型精化设计模型精化类的属性和操作精化类的属性和操作l属性的描述内容:名称、类型、初始值、取值范围、属性说明(后三项可选)l操作的描述内容:名称、参数表(参数名称及类型)、返回值类型、功能描述l属性和操作的作用范围:public, protected, private,原则:尽量缩小作用范围,属性不宜公开l设计模型精化的例子:如下 图4 精化设计模型精化设计模型精化类的属性和操作精化类的属性和操作4 精化设计模型精化设计模型设计状态图设计状态图l状态图适于表示跨越多个用例的单个对象的行为。l只需针对有明显的状态特征并且具有比较复杂的状态-事件-响应行为的类设计状态图。l如下图4 精化设计模型精化设计模型设计活动图设计活动图l活动图适于表示用例中的事件流和过程,也可以表示复杂的算法以及并发处理的进程。l针对比较复杂的处理过程并且比较重要的方法设计活动图,如果需要强调处理过程中的并行性,可使用活动图。
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号