《面向对象分析与设计(4)-分析.ppt》由会员分享，可在线阅读，更多相关《面向对象分析与设计(4)-分析.ppt（65页珍藏版）》请在金锄头文库上搜索。
1、面向对象分析与设计 创建分析模型 面向对象分析的主要工作 用例模型帮助开发团队理解客户对系统的各种功能需求概念模型 静态模型 帮助开发团队理解问题领域的各种概念 各种名词 以及它们之间的各种关系 描述系统的结构特征动态模型描述系统的动态行为特征 这两方面的工作 将帮助开发团队定义问题 也是分析工作的主要内容 分析与设计过程全景 UML在建模中的使用 面向对象分析过程 定义用例 辅助模型 可选 用用例对用户需求进行规范化描述建立类图 基本模型 发现对象 定义对象类识别对象的内部特征识别对象的外部关系建立交互图 状态图和活动图 辅助模型 可选 建立详细说明对模型中的成分进行规范的定义和文字说明可以
2、集中进行 也可分散在各个活动中原型开发结合其他活动反复进行 什么是问题域 问题域 是指一个包含现实世界事物与概念的领域 这些事物和概念与所设计的系统要解决的问题有关 建立概念模型 又称为问题域建模 域建模 也就是找到代表那些事物与概念的 对象 建模OO软件的第一步是澄清问题域 确定核心的抽象概念 目的通过采取确定系统必须处理的核心抽象概念 即在业务建模和需求活动中确定的概念 的措施来进行分析必要性需求和业务建模活动通常会揭示系统必须能够处理的核心概念 与此同时 这些概念也证实了其自身是核心的设计抽象概念 因为已经确认 所以没有必要在用例分析活动中重复确认工作 为了利用现有知识 我们初步确定使用
3、实体分析类 来代表这些以系统常识 诸如需求 词汇表 特别是领域模型或业务对象模型 为基础的核心抽象概念关键抽象的来源需求词汇表领域模型业务对象模型 什么是分析类 它代表问题域中的简洁抽象应该映射到真实世界业务概念分析类的最重要方面是应该使用清晰的和无歧义的方法映射到真实世界业务概念 OO分析师的工作 力求把混淆或不恰当的业务概念澄清为能够形成分析类基础的事物 是OO分析工作困难的原因 OO分析的真正目的是找出现实对象的类 分析类的思想 尽力捕获抽象的本质 忽略实现细节不是从设计角度考虑而产生的类 在具体设计时可能一个分析类被精华为一个或多个设计类在分析中 在创建概念模型时 捕获大场景 分析类的
4、形式名称属性操作 如何产生良好的分析类 名称反映目的 建模问题域的一个特定元素是简洁的抽象 清晰地映射到问题域中的可识别的特征 具有小的 良好定义的职责集合 职责是类与其客户的契约或对于客户的义务职责在语义上是内聚的操作集合每个类大约有3 5个职责高内聚 类的所有特征应该有助于实现其目的低耦合 类应该仅同一小部分其他类协作实现其目的 分析类经验法则 每个类大约3 5个职责 不存在独立的类 当心很多非常小的类当心少数几个非常庞大的类当心 伪类 当心万能类避免深度继承树设计良好的继承层次的本质是继承层次中每个抽象层次应该具有良好定义的目的 OO分析建模核心问题 寻找分析类使用名词 动词分析寻找类使
5、用CRC分析寻找类寻找其他类来源 使用名词 动词分析寻找类 名词 动词分析是分析文本尝试找出类 属性和职责的方法 从名词与名词短语中提取对象与属性从动词与动词短语中提取操作与关联所有格短语通常表明名词应该是属性而不是对象 名词 动词分析过程 第一步 尽可能多地收集相关信息补充需求规格说明用例项目词汇表任何其他信息源 构架 远景文档 名词 动词分析过程 续 第二步 使用非常简单方法分析如下内容 名词名词短语动词动词短语 概念模型建模步骤 找到备选类决定候选类并不是每一个备选类都是合适的候选类 有些名词对于要开发的系统来说并无关紧要 甚至是系统之外的 而有些名词表述的概念则相对较小 适合于某个候选
6、类的属性确定类之间的关联为类添加职责什么是类的职责呢 它包括以下两个主要内容 类所维护的知识 成员变量 类能够执行的行为 成员方法 举例 创建概念模型 一个爱书之人 家里各类书籍已过千册 而平时又时常有朋友外借 因此需要一个个人图书管理系统 该系统应该能够将书籍的基本信息按计算机类 非计算机类分别建档 实现按书名 作者 类别 出版社等关键字的组合查询功能 在使用该系统录入新书籍时系统会自动按规则生成书号 可以修改信息 但不能够删除记录 该系统还应该能够对书籍的外借情况进行记录 可对外借情况列表打印 另外 还希望能够对书籍的购买金额 册数按特定时限进行统计 使用名词 动词法注意 在使用 名词动词
7、法 寻找类的时候 很多团队会在此耗费大量的时间 这样很容易迷失方向 其实我们的主要目的是对问题域建立概要的了解 无需太过咬文嚼字 其它方法 CRC分析 脑力风暴技术过程要求团队成员命名运转在业务领域的事物要求团队陈述该事物的职责要求团队识别可能一起工作的类 概念模型的意义 面向对象的视角使用OO的思想所建立的系统模型就是对问题域的完整 直接的映射 体现了OO思想的关键活动开发团对的需要概念模型的建立 其主要的作用是帮助开发团队能够对问题域有一个全貌式的了解 概念模型的详细程度 模型不是我们要生产的目标产物 而且过程中的一个辅助工作 只要能够利用其帮助团队更好的开发 详细也罢 简约也罢 都是好模
8、型 OO分析总结 用例模型帮助开发团队明白客户想解决什么问题将需求整理归纳成为指导全开发过程的 软件需求规格说明书概念模型帮助开发团队了解客户所处的世界 分析用例 行为分析 用例模型 补充需求 构架描述 用例 分析用例 用例工程师 业务模型 分析类 用例分析 目的确定执行用例事件流的类使用用例实现 将用例行为分配给那些类确定类的职责 属性和关联关系记录构架机制的使用情况角色设计师时机用例分析分两个阶段第一个阶段是 定义备选构架 同时做 构架分析 活动 目标是定义一个备选构架第二个阶段是 分析行为 与 确定设计元素 活动一起做 目标是把用例行为分配到分析类中 行为分析之前 用例建模 获取可靠的需
9、求 我们需要高层的需求文档和用例结构图来确定需求的可靠性 它并不一定完备 但提供了系统的基本全景 如果在分析过程中发现了一些相当新的用例 那说明需求工作没做到位 它作为分析 行为建模 的基础将是不可靠的 确定用例的优先级 我们通常采用迭代的开发模式 每次只针对一个目标用例集展开分析 而不是全线出击 因此需要根据风险 重要性和团队的适应能力综合考虑 为所有的用例确定优先级 那些级别高的用例应当有详细的规格说明 包括基本流和重要的扩展流 它们是分析的基本素材 用例实现中的分析与设计 用例建模对系统外在的行为进行了分解 每个用例情节最终都落实到内部某个对象群体的协作上 而对象群体行为则进一步将必要职
10、责分配到对象个体上 这便是用例实现 并分为用例分析和用例设计两个阶段 为用例实现建模的元素包括 协作图 序列图 以及类图等 用例分析的输入和输出 输入词汇表补充规约用例模型用例规约用例建模指南用例实现 只是识别出来了 还没有开发 软件构架文档边界类 表示用户界面中的窗口设计模型或分析模型输出用例实现分析模型 可选 或设计模型 用例实现 用例实现对用例模型中的每个用例 在设计模型中都有相应的实现提供从分析和设计到需求的可跟踪性用例实现结构用例实现包是组织用例的类和交互图的方式每个用例都对应一个用例实现包可跟踪性图交互图时序图 SequenceDiagrams 动态 协作图 Collaborati
11、onDiagrams 动态 类图 ClassDiagrams 静态 用例分析的步骤 补充用例描述对每个用例实现从用例行为中找出类把用例行为分配到类对每个分析类描述属性和关联描述责任限定分析机制 analysismechanism 确定属性建立分析类之间的关联关系说明分析类之间的事件依赖关系整合分析类 Step1 补充用例描述 用例的描述往往不够查找分析类用户通常不关心系统内部的信息 所以开始时的用例描述是黑盒的为了发现分析类 需要从系统内部的视点对用例进行白盒描述例如 课程注册系统中 学生可能喜欢说 系统显示课程列表 但是这不能说明系统内部是如何实现的 为了给出系统内部是如何工作的 我们要加入
12、 系统从课程目录遗留数据库中取得课程列表 Step2 从用例行为中查找分析类 目的确定一组备选的 能够执行用例行为的分析类分析类分析类代表 系统中具备职责和行为的事物 的初期概念模型 这些概念模型最终将演进为设计模型中的类和子系统分类 根据其担负的职责和表现的行为 边界类 Boundaryclass 接口与系统外部某些事物的媒介 控制类 ControlClass 负责协调用例的行为 实体类 EntityClass 封装了数据以及数据相关的操作 表达领域概念 负责承担系统中需要持久化的信息及其关联的行为 应用逻辑对象 识别分析类 用例的行为最终都要落实到各分析类的职责上 边界类承担的角色 边界类
13、负责系统与外界的通讯和交互 边界对象将系统与其外部环境的变更 与其他系统的接口的变更 用户需求的变更等 分隔开 使这些变更不会对系统的其他部分造成影响 边界类的职责 转换和翻译交互事件 对内 将外界不同格式的事件和信息转换为内部能够识别的格式 并触发控制类对象 或实体对象 来响应它们 对外 则做类似的反向操作 变更对外的表示内容 在内部状态 特别是外界关注的信息 发生变化时 向外部通知或更新表示内容 常见的边界类对象有 用户接口类帮助与用户进行通信的类 通过标准的I O设备提供人机界面 GUI 系统接口类帮助与其他系统进行通信的类 系统 通讯协议 接口 设备接口类或Timer提供对硬件设备的软
14、件接口 识别边界类 用户界面类关注要呈现给用户的信息是什么不要陷入UI的设计细节系统和设备接口类关注必须定义的协议是什么不要关注协议是如何实现的重点关注职责而不是细节 识别边界类 续 每个用例主角都至少有一个边界类查找用户接口类时需要注意可以复用用户界面建模活动期间存在的边界类仅对系统的核心部分建模 不要对GUI中的每个按钮 列表和小部件都建模 分析的目的是要大致了解系统是如何构成的 而不是要设计每一个细枝末节查找系统边界类时注意与现有系统的接口可能已有明确定义 如果是这样 即可从接口定义中直接推导出职责如果已经有一个正式的接口定义 则可对它实施逆向工程 这样就不必在此正式界定它查找设备边界类
15、时注意做用例分析的时候可能需要补充原来没有识别出来的设备主角 相应的也要修改用例的说明 实例 用户界面 边界类 实例 系统接口 边界类 边界类的职责归类 GUI界面边界类承担的职责包括 按要求的格式显示内容 VIEW 文本 表格 图形等控件 输入数据并转换为内部格式 CONTROL 编辑 选择 图形等控件 转换和翻译用户动作并触发响应 CONTROL 菜单 按钮 快捷键 系统接口边界类承担的职责包括 输入 输出数据 并根据协议进行格式转换接收事件并触发响应和向外发送事件 边界类的状态与行为 GUI界面边界类可以拥有状态 并可能对其行为产生如下影响 影响用户操作的执行范围 菜单等的使能与禁用 对
16、话框的打开与关闭 影响对外显示的样式和能力边界类的状态除了受用户操作序列的影响 更多地将为控制类和实体类的状态所控制系统接口边界类的状态将与其支持的协议中规定的交互顺序有关设备接口边界类通常拥有复杂的状态 以便支持与硬件设备的适配逻辑 控制类 作用 负责协调 调度 处理事务并控制系统内部其它对象的行为 用于对一个或几个用例所特有的控制行为进行建模 控制类封装了用例的特有行为控制对象 控制类的实例 通常控制其他对象 因此它们的行为具有协调性质控制类有效地将边界对象与实体对象分开 让系统更能适应其边界内发生的变更控制类还将用例所特有的行为与实体对象分开 使实体对象在用例和系统中具有更高的复用性控制类并不能处理用例需要执行的一切事务 相反 它协调其他用来实施此功能的对象的活动 控制类将工作委派给已被指定负责此项功能的对象 控制类通常被看成一个乐队的指挥 它指挥 控制 参与usecase的其它对象的行为 通知对象什么时候执行以及执行什么 控制类的角色 协调用例的行为 识别控制类 可以首先为每个用例实现确定一个控制类 接着 在确定了更多的用例实现并发现更多的共性后 再对其进行改进将性质不同的控制
