第五章UM对象图和类图讲义.pptVIP

3 对象图 描述参与一个交互的各个对象在交互过程中某一时刻的状态。 可以被看作是类图在某一时刻的实例。 -*- 分析类：达成目标的第一步 用例分析 -*- 4. 从用例行为中识别分析类 在对象技术中，一个用例的全部行为都是由相应的类来完成的 这些行为必须被分配到类中 分析阶段就是对这个过程的第一次尝试 这是一个从“无”到“有”的跨越 -*- 什么是分析类 分析类代表了“系统中必须具备职责和行为的事物”的早期概念模型 分析类处理主要的功能需求，模型化问题域对象 根据备选构架定义三类分析类 边界类：系统及其参与者的边界 控制类：系统的控制逻辑 实体类：系统使用的信息 -*- 边界类 边界类表示系统与参与者之间的边界 代表系统与环境的交互 是接口和外部事物的中间体 构造型boundary 两类边界类 用户界面类 系统和设备接口类 -*- 示例：识别边界类 每对参与者/用例定义一个边界类 -*- 指南：边界类 关注职责，而不是细节 用户界面类 关注展示给用户的信息 不关注用户界面细节 系统和设备接口类 关注系统必须定义的协议 不关注协议如何实现 -*- 控制类 控制类表示系统的控制逻辑 系统行为的协调器 构造型control 识别控制类 在系统开发早期，为一个用例定义一个控制类，负责该用例的控制逻辑 针对复杂用例，可为备选路径分别定义不同控制类 -*- 示例：识别控制类 通常，每个用例定义一个控制类 随着分析的继续，一个复杂用例的控制类可以发展为多个 -*- 实体类 实体代表了待开发系统的核心概念 实体类提供了另一个理解系统的观点 显示了系统的逻辑数据结构 传统的面向对象方法就是从这个角度进行分析和设计 使用构造型entity 可以从以下中找到实体类 用例事件流(需求) 、业务模型(业务建模) 、词汇表(需求) -*- 识别实体类 分析用例事件流中的名词、名词短语找出系统所需的实体对象，这些名词可能是： 对象、对象的特征和状态 参与者、描述信息、系统之外的 从这些名词、名词短语中进行筛选，抽取出系统对象，并抽象成类 综合考虑在系统中的意义、作用和职责 对于所识别的类进行命名 -*- 指南：名词筛选法识别实体类 名词筛选法识别实体类的基本思路： 将用例文档作为输入，找出文档中的名词或名词性短语，形成了实体类初始候选列表 合并那些含义相同的名词 删除那些系统不需要处理的名词 删除作为参与者的名词 删除与实现相关的名词 删除那些作为其它实体类属性的名词 对剩余的名词，综合考虑它在当前用例以及整个系统中的含义、作用以及职责，并基于此确定合适的名字，作为初始实体类存在 -*- 实体类的其它来源 除了用例文档之外，从与用户和专家进行的访谈中得到的信息，也可作为实体类的来源 系统原始需求书/问题描述 该领域相关文献、专家意见或个人知识 过去的类似系统 在后面的职责分配中可能识别一些新的实体类 实体类的命名要用该领域中最经常使用的名称 -*- 示例：候选实体类 “支付”用例基本路径中的候选实体类 -*- 示例：总结：分析类 -*- 总结：从用例中识别分析类 -*- 实例-旅店预订系统中识别分析类 -*- 实例-旅游申请系统中的分析类 -*- 3. 将用例行为分配给类 面向对象系统是通过对象间的协作实现需求的 需求阶段通过自然语言描述 分析设计阶段采用图形化方式描述协作过程 利用交互图将用例行为分配给分析类 类图和对象图的区别 类图 对象图 类具有三个分栏：名称、属性和操作 对象只有两个分栏：名称和属性 在类的名称分栏中只有类名 对象的名称形式为“对象名：类名”，匿名对象的名称形式为“：类名” 类中列出了操作 对象图中不包含操作，因为对于属于同一个类的对象而言，其操作是相同的 类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义。类代表的是对对象的分类，所以必须说明可以参与关联的对象的数目 对象使用链连接，链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性 类的属性分栏定义了所有属性的特征 对象则只定义了属性的当前值，以用于测试用例或例子中 4 对象图建模技术 识别将要使用的建模机制。 对于各种机制，识别参与协作的类、接口和其他元素，同时识别这些事物之间的关系。 考虑贯穿这个机制的脚本，冻结某一时刻的脚本，并且汇报每个参与这个机制的对象。 按照需要显露出每个这样的对象的状态和属性值，以便理解脚本。 显露出这些对象之间的链，以描述对象之间关联的实例。 5 实例——图书馆管理系统的类图 6.5.1 使用Rational Rose绘制类图的步骤 6.5.2 图书馆管理系统的类图 6.5.1 使用RATIONAL ROSE绘制类图的步骤 1. 创建类图 2. 加入类