[工学]OOD习题课教务系统ooa部分.pptVIP

用况的关联关系 Include 多个用例中，如有相同的公共部分， 则，为了提高复用性，可以将其提取出来，形成另一个用例 Extend “UseCaseA 和 UseCaseC 知道 UseCaseB 的存在， 而 UseCaseB 根本不知道有 UseCaseA 和 UseCaseC）； ! 注意方向 以下几种情况可以用到extend关联: (1) A part of a use case that is optional system behavior (2) A subflow is executed only under certain conditions (3) A set of behavior segments that may be inserted in a base use case UseCaseA 不知道 UseCaseB 和 UseCaseC 的存在，但 UseCaseB 和 UseCaseC 却是知道 UseCaseA 并且知道如何在 UseCaseA 中作扩展的。 * 确定系统边界 发现参与者 定义用况 发现对象 定义类 定义对象 的特征 定义对象 间的关系 原型开发 建立模型规约 建立需求模型 建立基本模型 建立包图 建立顺序图 其他 建立辅助模型 OOA过程 We are here 人员： 组织： 物品： 抽象事物： 事件： 文件： ...... 学生（本科生、研究生） 、教师、教务员 院系、教务办公室 null 课程、成绩、科研成果 注册、选课、登录成绩、添加课程信息 etc. 成绩数据、课程信息、选课名单… ...... 问题域 学生 本科生 研究生 教师 和 教务员 课程 选课记录 成绩记录 学生 本科生 研究生 教师 和 教务员 课程 选课记录 成绩记录 系统用户 学生 本科生 研究生 教师 和 教务员 课程 选课记录 成绩记录 精化 (refinement) 第一个类： 系统用户 三个派生类 教师 学生 教务员 一般 – 特殊 关系 建立课程类、成绩类 以及 关联 建立课程类、成绩类 以及 关联 整体 – 部分 关系 建立课程类、成绩类 以及 关联 建立课程类、成绩类 以及 关联 call call call call call call 加入了 调用依赖 没有完成的类，包括教师、教务员等 call call call call call call 耦合 （低耦合为好） 减少一个对象发出和接收的消息的数目 如果耦合程度较高 - 考虑合并 内聚（高内聚为好） 类内聚：属性和服务是高内聚的，描述对象本身责任的 一般-特殊 内聚：特殊类应该真正地描述了一般类的特化 其他标准： 模型的可读性、易理解性 在同一个层次中，除非不得已，类的数量尽量不要过多或过少 7 + 2 原则 灵活性 可重用性 公认的优雅风格 设计模式（Design Pattern） * 确定系统边界 发现参与者 定义用况 发现对象 定义类 定义对象 的特征 定义对象 间的关系 原型开发 建立模型规约 建立需求模型 建立基本模型 建立包图 建立顺序图 其他 建立辅助模型 OOA过程 We are here 新建课表 登记成绩记录 需求模型 用况图 use case diagram 分析 与 设计 发现对象、确定类 发现对象关系、确定关联 精化 辅助模型 时序图 等 弄清楚要做什么 充分捕获需求、细致完成用况图 避免过度设计 (KISS) 注意设计类图的几个原则 高内聚，低耦合 灵活性，易扩展性…… Design Pattern Any Questions ? * 确定系统边界 发现参与者 定义用况 发现对象 定义类 定义对象 的特征 定义对象 间的关系 原型开发 建立模型规约 建立需求模型 建立基本模型 建立包图 建立顺序图 其他 建立辅助模型 OOA过程 基本模型：类图 模 型 规 约 需求模型： 用况图 辅助模型： 包图 顺序图 …… 对象层 特征层 关系层 * OOD模型 ——从两个侧面来描述 人机交互部分 数据接口部分 控制驱动部分 问题域 部分 从一个侧面观察： OOD模型包括几个主要部分？ 一个核心加三个外围 需 求 模 型 辅 助 模 型 类 图 模 型 规 约 从另一侧面观察： OOD模型每个部分 如何用OO概念表达？ 采用与OOA相同的概念及 模型组织方式 提取三个参与者共通的部分 抽象出“用户” （factor out）