软件工程第十讲--面向对象分析.pptVIP

第十章 面向对象分析 10.1 面向对象分析的基本过程 10.2 需求陈述 10.3 建立对象模型 10.4 建立动态模型 10.5 建立功能模型 10.6 定义服务 一、面向对象分析（Object-oriented Analysis, OOA） 提取用户需求 理解 表达 验证 建立三个模型 OM DM FM 1. 分析过程 2. 需求陈述（Requirement Statement） 说明What 而不是 How 内容 问题范围 功能需求 性能要求 应用环境 假设条件 【例】ATM系统 【例】ATM系统的需求陈述 3. OM的五个层次 相当于把五张透明胶片(transparencies)叠在一起，每一层显示更多的细节 OM的五个层次 OMT大体顺序 寻找类--对象 识别结构 识别主题 定义属性 建立动态模型 建立功能模型 定义服务 不严格按照顺序 OOA不需要严格遵守自顶向下的原则 4. 建立OM 确定Class--Object 确定关联? 结构层 划分主题 确定属性 识别继承关系 反复修改 建立DM 建立FM 定义服务 （1）确定Class--Object 第1步：列出候选Class--Object（candidates） ? 物理实体 ? 人或组织 ? 要处理的事件 ? 对象间的活动 ? 抽象概念 列出候选Class--Object 列出候选Class--Object （1）确定Class--Object 第2步：去粗取精 （2）确定关联? 结构层 收集 Requirement Statement中的动词词组 根据问题域知识得出关联 筛选删除 已删除的class之间的关联 与问题无关/在实现阶段考虑的关联 反映瞬时事件的关联 三元关联 ? 二元关联 冗余的关联 完善 正名、分解、补漏、标明阶数 （3）划分主题 （4）确立属性 Attribute 不表示 objects 之间的关系，只表示其本质性质 需求陈述中与已确定的objects 有关的名词、形容词可能是属性选择的线索 领域知识和常识有助于确定属性 Attribute不要与链属性、限定词混淆 暂不考虑纯用于实现的 attributes （5）识别继承关系 两种建立继承关系的方式 自底向上（Bottom-up）—— 归纳induction 将具有相同属性的classes向上归纳出父类 自顶向下（Top-down）—— 演绎deduction 将现有classes向下细化出子类（但分析阶段避免过度细化） （6）反复修改 若某class中具有几个独立的功能，则考虑分解为几个classes 对于某class中具有自己特有属性的部分，可考虑将之列为独立存在的class，且是原有class的组成 合并无须分别考虑的若干classes 修改建立OM 5. 建立DM 第一步，是编写典型交互行为的脚本。 第二步，从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象 第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。 最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配 5.1 编写脚本 脚本是指系统在某一执行期间内出现的一系列事件。 脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。 5.2 设想用户界面 用户界面的美观程度、方便程度、易学程度以及效率等等，是用户使用系统时最先感受到的，用户对系统的“第一印象”往往从界面得来，用户界面的好坏往往对用户是否喜欢、是否接受一个系统起很重要的作用。 5.3 画事件跟踪图 为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。 因此首先需要进一步明确事件及事件与对象的关系。 应该仔细分析每个脚本，以便从中提取出所有外部事件。事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等。 从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏了异常事件和出错条件。 传递信息的对象的动作也是事件。 应该把对控制流产生相同效果的那些事件组合在一起作为一类事件，并给它们取一个惟一的名字。 从脚本中提取出各类事件并确定了每类事件的发送对象和接受对象之后，就可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。 5.4 画状态图 状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件。由事件引起的状态改变称为“转换”。 仅考虑事件跟踪图中指向某条竖线的那些箭头线。把这些事件作为状态图中的有向边(即箭头线)，边上标