【软件工程讲解】OOA的基本过程.ppt

第十章 OOA OOA的基本过程 需求陈述 建立对象模型 建立动态模型 建立功能模型 定义服务 OOA过程 OOA就是抽取和整理用户需求并建立问题域精确模型的过程。该过程可以分为三个步骤： 需求获取 抽象和整理用户需求 建立问题域的精确模型 对象的三要素（三个子模型） 静态结构——对象模型——WHO 交互次序——动态模型——WHEN 数据变换——功能模型——WHAT 对象建模的五个层次 主题层 类与对象层 结构层 属性层 服务层 对象建模的步骤 确定类与对象 对问题域概念的抽象 从需求陈述、招标书等中获取 标识结构，确定类和对象的关系 继承关系——整体与部分 聚合关系——一般与特殊（泛化与特化） 确定属性 识别类与对象所保存的信息 给出各个类与对象之间的实体连接（一对一、一对多等） 定义服务 即识别操作，并根据功能给出各个操作之间的消息连接 划分主题 即识别系统的高层模块或子系统 需求陈述 需求陈述往往是非形式化的、不完整的、不准确的。 需求陈述的内容 “做什么” 问题范围、功能和性能要求、应用环境及假设条件等。 书写需求陈述的要点 语法正确，语义清晰 认识本质，强调重点 完整、准确、有效 例子（P209） 自动取款机（ATM）系统 OOA—建立对象模型 建立OO模型的一般过程： 确定类和对象 确定关联 划分主题 确定属性 识别继承关系 反复修改和复审 确定类与对象 类与对象的发现原则 可感知的物理实体，设备 人、组织角色或组织单元，如医生、财务处 需要记忆的事件，如飞行、演出、访问 对象间的相互作用和操作过程，如购买、纳税等 需要说明的概念，如政策、法规 发挥的作用、地点等 一种非正式的分析方法 把陈述中的名词作为类与对象的候选者 形容词作为确定属性的线索 动词作为服务的候选者 注意需求陈述中隐含的类与对象 确定类与对象（续） 自动取款机（ATM）系统所确定的“类与对象”见P211。 注意需求隐含的类与对象“通讯链路”、“事务日志” 确定类和对象（续） 剔除原则 冗余的 无关的 笼统的 有些名词实际上描述的是其它对象的属性 区分操作、公共服务与类定义的名词和动词 暂缓考虑设计阶段的内容 确定类和对象（续） 类和对象的进一步调整 属性不适合于该类 如汽车有乘客数量属性 属性和服务相同的类 属性和服务相似的类 对同一事物的重复描述 人员和身份证 类的命名 使用标准术语 使用具有确切含义的名词 必要时用名词短语作名词 确定关联 初步确定（P213） 直接提取动词短语得出关联 确定隐含的关联 根据问题域知识确定关联 筛选 （P214） 已删除的类之间的关联 与问题无关或应在实现阶段才考虑的关联 瞬时事件 三元关联 派生关联 进一步完善（P215） 正名——分解——补充——表明阶数 划分主题 定义 主题是一组具有较强联系的类组织在一起而得到的类的集合。 目的 控制复杂性 易读 主题的表示 划分主题（续） 主题的划分的依据 不同主题内的对象间的依赖和交互最小原则。 注意：不是用功能分解方法来确定主题。 对于小型系统可能无须引入主题层。 对于中型系统，由于它所含有的对象较多，一般先识别类与对象和关联，然后再划分主题。 对于大型系统，先由高级分析员粗略地识别类与对象和关联，并初步划分主题，但随着对系统的逐步认识和了解，须进一步修改和精练主题。 ATM系统的主题划分（P216图10.4） 确定属性 初选（分析需求陈述） 需求陈述中的名词词组 形容词表示可枚举的具体属性 根据问题域和实现任务确定属性，请教领域专家。 选择 误把对象当作属性 误把链属性当作属性 误把限定当作属性 误把对象的内部状态当作属性 过于细化 存在不一致的属性 ATM对象模型中的属性（P218） 识别继承关系 目的 利用继承机制共享公共性质 根据归纳关系（一般与特殊）对系统中的类加以组织 建立继承关系的两种方式 自底向上 归纳过程 自顶向下 演绎过程 带有继承关系的ATM对象模型（P219） 反复修改 建模的反复过程 建模过程是一个反复修改、逐步完善的过程。 建模步骤次序因人而异，与经验、能力和实践有关。 与问题规模有关。复杂问题需要领域专家的帮助。 对ATM对象模型的修改 由类“现金兑换卡”分解为“卡权限”和“现金兑换卡” “事务”由“更新”组成 把“分行”与“分行计算机”合并 修改后的ATM对象模型（P221） OOA—建立动态模型 编写脚本（Script) 设想用户界面 画事件跟踪图 画状态图 审查动态模型 编写脚本 脚本（场景 Scenarios、情景） 指系统在某一执行期间的事件序列。 描述用户、外部设备等与系统间的典型交互过程。 编写脚本的目的 对目标系统的行为有更具体的认识 防止对重要的交互步骤的遗漏 保证交互过程的正确性和清晰性 编写脚本所注意的问题 脚