730 likes | 856 Views
面向对象设计. 面向对象的一般步骤 Coad&Yourdon 的 OOD 方法. 面向对象设计. 面向对象的一般步骤 Coad&Yourdon 的 OOD 方法. 面向对象设计的一般步骤. 系统设计 将子系统分配到处理器 选择实现数据管理、界面支持和任务管理的设计策略 为系统设计合适的控制机制 复审并考虑权衡 对象设计 在过程级别设计每个操作 定义内部类 为类属性设计内部数据结构. 消息设计 使用对象间的协作和对象 -- 关系模型,设计消息模型 复审 设计模型并在需要时迭代。. 系统设计. 1) 将分析模型划分成子系统
E N D
面向对象设计 • 面向对象的一般步骤 • Coad&Yourdon的OOD方法
面向对象设计 • 面向对象的一般步骤 • Coad&Yourdon的OOD方法
面向对象设计的一般步骤 • 系统设计 • 将子系统分配到处理器 • 选择实现数据管理、界面支持和任务管理的设计策略 • 为系统设计合适的控制机制 • 复审并考虑权衡 • 对象设计 • 在过程级别设计每个操作 • 定义内部类 • 为类属性设计内部数据结构
消息设计 使用对象间的协作和对象--关系模型,设计消息模型 • 复审 设计模型并在需要时迭代。
系统设计 1) 将分析模型划分成子系统 在OO系统设计中,我们把分析模型中紧密相关的类、关系等设计元素包装成子系统。 通常,子系统的所有元素共享某些公共的性质,它们可能都涉及完成相同的功能;它们可能驻留在相同的产品硬件中;或者它们可能管理相同的类和资源。子系统由它们的责任所刻画,即,一个子系统可以通过它提供的服务来标识。在OOD中,这种服务是完成特定功能的一组操作。
子系统的设计准则是: (1) 子系统应具有定义良好的接口,通过接口和系统的其它部分通信; (2) 除了少数的“通信类” 外,子系统中的类应只和该子系统中的其它类协作; (3) 子系统的数量不宜太多; (4) 可以在子系统内部再次划分,以降低复杂性。
2)标识问题本身的并发性,并为子系统分配处理器2)标识问题本身的并发性,并为子系统分配处理器 通过对对象--行为模型的分析,可发现系统的并发性。如果对象(或子系统)不是同时活动的,则它们不需并发处理,此时这些对象(或子系统)可以在同一个处理器上实现。反之,如果对象(或子系统)必须对一些事件同时异步地动作,则它们被视为并发的,此时,可以将并发的子系统分别分配到不同的处理器,或者分配在同一个处理器,而由操作系统提供并发支持。
3) 任务管理设计 Coad和Yourdon提出如下管理并发任务对象的设计策略: (1) 确定任务的类型; (2) 定义协调者任务和关联的对象; (3) 将协调者任务和其它任务集成。 通常可通过了解任务是如何被启动的来确定任务的类型,如事件驱动任务,时钟驱动任务。每个任务应该定义其优先级,并识别关键任务。当有多个任务时还可以考虑增加一个协调者任务,以控制这些任务协同工作。
4) 数据管理设计 通常数据管理设计成层次模式,其目的是将操纵数据结构的低层需求和处理系统属性的高层需求加以分离。 数据管理的设计包括设计系统中各种数据对象的存储方式(如内存数据结构、文件、数据库),以及设计相应的服务,即为要储存的对象增加所需的属性和操作。
5) 资源管理设计 OO系统可利用一系列不同的资源(如磁盘驱动器、处理器、通信线路等外部实体或数据库、对象等抽象资源),很多情况下,子系统同时竞争这些资源,因此要设计一套控制机制和安全机制,以控制对资源的访问,避免对资源使用的冲突。 • 人机界面设计 对大多数应用系统而言,人机界面本身是一个非常重要的子系统。人机界面主要强调人如何命令系统,以及系统如何向人提交信息。它包括窗口、选单、报告的设计。
7) 子系统间的通信 子系统之间可以通过建立客户/服务器连接进行通信,也可以通过端对端(peer to peer)连接进行通信。我们必须确定子系统间的合约(contract),合约提供了一个子系统和另一个子系统交互的方式。 确定合约的设计步骤如下: (1) 列出可以被该子系统的协作者提出的每个请求,按子系统组织这些请求,并把它们定义到一个或多个适当的合约中。务必要标记那些从父类中继承的合约;
(2) 对每个合约标记操作(继承的和私有的),这些操作被请求以实现被该合约蕴含的责任,务必将操作和子系统内的特定类相关联; (3) 每个合约应包含:合约的类型(客户机/服务器或端对端),协作者(合约伙伴的子系统名),类(子系统中支持合约蕴含服务的类名),操作(类中实现服务的操作名),消息格式(实现协作者间交互所需的消息格式); (4) 如果子系统间的交互模式比较复杂,还可以建立子系统协作图。
对象设计 对象设计是为每个类的属性和操作作出详细的设计,并设计连接类与它的协作者之间的消息规约。 1) 对象描述 对象的设计描述可以采取以下形式之一: (1) 协议描述:描述对象的接口,即定义对象可以接收的消息以及当对象接收到消息后完成的相关操作;
(2) 实现描述:描述传送给对象的消息所蕴含的每个操作的实现细节,实现细节包括有关对象私有部分的信息,即关于描述对象属性的数据结构的内部细节和描述操作的过程细节。 对对象的使用者来说,只需要协议描述就够了。 2)设计算法和数据结构 为对象中的属性和操作设计数据结构和实现算法。
设计模式(design patterns) 在许多面向对象系统中,存在一些类和通信对象的重复出现的模式。这些模式求解特定的设计问题,使面向对象设计更灵活,并最终可复用。这些模式帮助设计者复用以前成功的设计,设计者可以把这些模式应用到新的设计中。 一个设计模式通常可用四个信息来描述: 1)模式名 设计模式名应具有实际的含义,它能反映模式的适用性和意图。
2)使模式可被应用所必须存在的环境和条件。2)使模式可被应用所必须存在的环境和条件。 3)设计模式的特征 模式特征指出一些设计的属性,调整这些属性使该模式能适应各种不同的问题。这些属性表示设计的特征,这些特征能被用于检索(通过数据库)以找到合适的模式。 4)应用设计模式的结果(consequences) 对于一个设计模式的使用结果表明设计决策的走向。
面向对象设计 • 面向对象的一般步骤 • Coad&Yourdon的OOD方法
Coad & Yourdon 的OOD方法 Coad & Yourdon的OOA模型由五个层次和五个活动组成。 五个层次是主题层,类及对象层,结构层,属性层和服务层。 五个活动是识别类及对象,识别结构(分类结构和组装结构),识别主题,定义属性(包括实例连接),定义服务(包括消息连接)。 上述这些活动不必顺序进行,分析人员可以用不同的顺序完成这些活动。
Coad & Yourdon的OOD模型由四个部件和四个活动组成。 四个部件是人机交互(界面)部件,问题域部件,任务管理部件,数据管理部件。 四个活动是设计问题域部件,设计人机交互(界面)部件,设计任务管理部件,设计数据管理部件。 在OOD的整个过程中始终贯穿OOA中的五个层次和五个活动,OOA的结果就是OOD的问题域部件,但在OOD中可以改动和增补。
主题层 类及对象层 结构层 属性层 服务层 人机交互部件 HIC 问题域部件 PDC 任务管理部件 TMC 数据管理部件 DMC Coad & Yourdon 的OOD模型 问题域部件 PDC : Problem Domain Component 人机交互部件 HIC : Human Interface Component 任务管理部件TMC : Task Management Component 数据管理部件DMC : Data Management Component
设计问题域部件 OOA的结果就是初始的问题域部件,在OOD中需对其(包括类、属性、服务)增补和调整 • 复用软部件 • 引入新父类,把问题域相关的类关联起来 • 引入新父类,以捕获共性 • 转换继承结构,适应实现的限制 • 调整OOA模型,提高执行速度 • 依据高内聚、低耦合、简单性等设计原则复审
1.复用软部件 • 尽量复用既存的类,即根据问题解决的需要,尽量使用类库或其它来源得到的既存类 • 标明既存类中不需要的属性和操作 • 增加从既存类到应用类之间的一般-特殊关系 • 把应用类中因继承既存类而成为多余的属性和操作标出 • 修改应用类的结构和连接 • 规范系统中的类,将其加入类库,以便复用
2.引入新父类,把问题域相关的类关联起来 • 在设计时,可引进一个根类,把所有与问题域有关的类关联到一起 • 这是一种把同一问题域的某些类组合起来的方法,可以为这些类建立协议(如提供公共操作的协议)
3. 引入新父类,以捕获共性 • 有时,某些特殊类存在一组类似的操作(即服务),此时,应加入一个新父类(即这些特殊类的泛化类),定义这些特殊类所有公共操作的协议(即抽象操作),把操作的实现细节隐藏在特殊类的定义中
4. 转换继承结构,适应实现的限制 • 在OOA阶段建立的OOA模型中可能包含多继承关系,但实现时使用的程序设计语言可能只支持单继承,甚至不支持继承,此时需要将多继承关系转换成单继承或无继承关系 • 多继承模式有两种: • 狭义的菱形 • 广义的菱形
根 人 角色 医生 教授 教授 医生 人 医务角色 教育角色 医学教授 医学教授 狭义菱形 广义菱形
将多继承转换成单继承 • 分解多继承,把多继承分为两个层次,即用一个整体部分结构或一个实例连接进行映射 • 这种方法把若干个特殊类对象模拟成一个一般类对象扮演的一些“角色” • 也可以用一个实例连接来模拟
角色 人 1..m 1 1..m 医生 教授 人 医生 教授 人 医生 教授 1 角色 医学教授
人 医生 教授 医生 教授 人 医学教授 医学教授 • 把多继承的层次结构平铺,成为单继承的层次结构。在这种情况下,类之间的一般-特殊关系不再清晰,同时,有些属性或操作在同层的特殊类中会重复出现。
医生 教授 医学教授 针对无继承语言的调整 • 当使用无继承的程序设计语言时,必须把具有继承关系的类层次结构平铺开来,成为一组类和对象。 • 一般可利用命名惯例,把这些类或对象关联起来。
5.调整OOA模型,提高执行速度 • 提高执行效率和速度是系统设计的主要指标之一。有时,必须改变问题论域的结构以提高效率。 • 合并相互通信频繁的类,以减少消息传递引起的速度损失。 • 在类中增加某些属性(如派生属性),或增加低层的类(如显示基本元素的类),以保存中间结果,避免每次都要重复计算造成速度损失。
6.依据原则复审 • 依据高内聚、低耦合、简单性等设计原则复审,检查对OOA模型的修改的合理性
设计人机交互部件 • 需求分析和设计阶段都要考虑人机交互问题 • 需求分析阶段要确定人机交互所需的属性和外部服务 • 设计阶段要给出有关人机交互的所有系统成分,包括:用户如何操作系统(即菜单);系统如何响应命令;系统显示的信息和报表格式等
设计HIC的策略和步骤 • 对人分类 • 描述人及其任务脚本 • 设计命令层次 • 设计详细的交互 • 继续做原型 • 设计HIC类 • 根据图形用户界面进行设计
1. 对人分类 • 按技能层次分类: 初学者/临时人员/中级水平/高级水平 • 按组织层次分类: 行政人员/办公人员/职员/管理人员/办事员 • 按职能分类: 顾客/职员
2. 描述人及其任务脚本 • 对以上定义的每一类人,列出对以下问题做出的考虑: • 什么人 • 目的 • 特点(年龄、教育水平、限制等) • 关键的成功因素 • 必须/想要 • 喜欢/不喜欢/有偏见 • 熟练程度 • 任务脚本
OOAToolTM中的实例 • 什么人──分析员 • 目的──要求一个工具来辅助分析工作 (摆脱繁重的画图和检查图的工作) • 特点──年龄:42岁; 教育水平:大学毕业; 限制:不喜欢微型打印,小于9个点的打印太小
关键的成功因素──工具应当使有效的分析工作顺利进行;工具不应与正在进行的分析工作冲突;工具应能捕获假设和思想,能适时做出折衷;应能及时给出模型任何部分的文档,这与给出需求同等重要。关键的成功因素──工具应当使有效的分析工作顺利进行;工具不应与正在进行的分析工作冲突;工具应能捕获假设和思想,能适时做出折衷;应能及时给出模型任何部分的文档,这与给出需求同等重要。 • 熟练程度──高级熟悉程度
任务脚本── • 主脚本: • 识别“核心”的类和对象; • 识别“核心”结构; • 在发现了新的属性或操作时随时都可以加进模型中去。 • 检验模型: • 打印模型及其全部文档。
3. 设计命令层 • 研究现行的人机交互活动的内容和准则:这些准则可以是非形式的,如“输入时眼睛不易疲劳”,也可以是正式规定的; • 建立一个初始的命令层:可以有多种形式,如: • 一系列菜单屏幕( Menu Screens) • 一个菜单条(Menu Bar) • 一系列图符(Icons)
细化命令层:考虑以下几个问题。 • 排列命令层次:把使用最频繁的操作放在前面;按照用户工作步骤排列。 • 整体-部分模式:通过逐步分解,找到整体-部分模式,以帮助在命令层中对操作分块。 • 宽度和深度的分块:根据人们短期记忆的“7±2”或“每次记忆3块/每块3项”的特点,把深度尽量限制在三层之内。 • 减少操作步骤:把点取、拖动和键盘操作减到最少,同时,为高水平用户提供操作捷径。
4. 设计详细的交互 • 人机交互设计有若干原则,包括: • 一致性:采用一致的术语、一致的步骤和一致的活动。 • 操作步骤少:减少敲键和鼠标点取的次数,减少完成某件事所需的下拉菜单的距离。 • 不要“哑播放”:每当用户等待系统完成一个活动时,要给出一些反馈信息。
Undo:在操作出现错误时,能恢复或部分恢复原来的状态。Undo:在操作出现错误时,能恢复或部分恢复原来的状态。 • 减少人脑的记忆负担:不应要求人从一个窗口中记忆或写下一些信息而在另一个窗口中使用;需要人按特定次序记忆的东西应当组织得容易记忆。 • 学习的时间和效果:提供联机的帮助信息。 • 趣味性与吸引力(外观与感受):尽量采取图形界面,符合人类习惯.
5. 继续做原型 • 用户界面原型是人机交互设计的重要工作。人需要对提交的人机交互活动进行体验、实地操作,并精炼成一致的模式。 • 使用快速原型工具或应用构造器,对各种命令方式,如菜单、弹出、填充以及快捷命令,做出原型让用户使用,通过用户反馈、修改、演示的迭代,使界面越来越有效。
6. 设计 HIC (人机交互) 类 • 窗口需要进一步细化,通常包括:类窗口、条件窗口、检查窗口、文档窗口、画图窗口、过滤器窗口、模型控制窗口、运行策略窗口、模板窗口等。 • 设计HIC类,首先从组织窗口和部件的人机交互设计开始。
每个类包括窗口的菜单条、下拉菜单、弹出菜单的定义。还要定义用于创建菜单、加亮选择项、引用相应的响应的操作。每个类包括窗口的菜单条、下拉菜单、弹出菜单的定义。还要定义用于创建菜单、加亮选择项、引用相应的响应的操作。 • 每个类负责窗口中信息的实际显示。所有有关物理对话的处理都封装在类的内部。必要时,还要增加在窗口中画图形图符的类、在窗口中选择项目的类、字体控制类、支持剪切和粘贴的类等。与机器有关的操作实现应隐蔽在这些类中。
7. 根据图形用户界面进行设计 • 各图形用户界面的区别:字型、坐标系统和事件。 • 字型:字体、字号、样式可能被限制在某些组合中,或可使用任何组合。 • 坐标系统:原点(左上角或左下角)、支持的显示分辨率及显示维数各不相同。 • 事件:是图形用户界面程序的核心,操作将对事件做出响应。
“传感器监测系统”的菜单结构: File Edit Initialize State Style Add… Off Font … Change … Standby Iconsize … Delete … On