7领域建模.pptVIP

* 两个类之间存在多种关联 注意：两个类可能会有多种关联。 如飞机和机场的关系，飞往与飞自关联截然不同 必须为关联取名，明确关联意义 * 关联角色 关联的一每端称为角色（Role） 角色有如下选项： 多重性表达式 名称 导航 * 多重性 多重性定义了某个时刻类A有多少个实例可以和类B的一个实例关联 多重性的值和建模者及软件开发者的关注角度有关 如Person和Company之间有关Works for关联，Person实例为一个还是多个Company工作取决于语境 * 关联终端角色名 使用动词为关联命名，加上类在此关联上的角色名，可以更为明确二者间的关联关系 对于同一类的两个对象之间的关联，终端名是必须的 * 利用关联列表寻找关联 常见关联列表 P115 A是交易B的交易 A是交易B相关的角色 …. * 示例：POS部分领域模型 * Monopoly * 最终的候选类 ATM 读卡器 现金取款口 收据打印机 问候语 银行卡 主菜单 账户 金融事务 存款事务 查询事务 转账事务 主要的类： ATM 读卡器 收据打印机 存款事务 查询事务 转账事务 账户 现金取款口 * ATM主要类的关联 * 3、属性 确定概念类的属性是有助于分析 记录的属性必须是满足当前场景的信息需求 如处理销售用例中，票据通常有日期，店名和地址，及收银员ID等 * 导出属性表示 有些属性，是重要必须的，但可由其他信息导出 在属性名称前加“/”符号 * 关注领域模型属性的数据类型 大部分属性类型应该是“简单”的数据类型 不应该是复杂的领域概念 * 定义新的数据类型类（Value Object） 有些属性相对复杂，但也只是用于记录信息，不承担领域责任 开始往往建模为数字或字符串 准则 由不同的小节组成：电话号码、地址、人名 具有与相关的操作，数据需要解析或校验： 具有其他属性：促销价格 单位的数量： 具有以上性质的一个或多个类型的抽象 * * 避免数据库建模概念 引入外键! * 对数量和单位建模 考虑数量的价格或重量单位 如果软件是面向国际市场的，则需要对这些数量进行处理。 * POS系统中的属性 * Monopoly * ATM类的属性 * 没有唯一正确的领域模型 所有模型都是对试图要理解的领域近似 利用对象图，使用场景验证模型的正确 迭代和演化式开发领域模型 通过若干迭代对领域模型进行增量式演进,不必过早的试图捕获所有可能的概念类和联系 * 用例场景测试过程 * 面向对象分析与设计 领域模型 * OO主要步骤 * 领域模型 领域模型使得分析自然过渡到类图建模 领域建模的工作是：发现那些表示与问题领域相关的事物和概念的对象，并用图形表示出问题域里对象静态模型 主要描述： 领域对象或概念类 概念类之间的关联 概念类的主要属性 CRC建模方法适用于领域建模 * POS部分领域模型 请考虑某一销售场景! * 什么是领域模型 领域模型对领域内的概念或对象的可视化表示 应用UML的类图表示 用于表示领域的重要抽象、领域词汇和领域的内容信息 重点：关注的是现实世界领域中事物的可视化 * 画家写生 建筑模型 * 领域模型定义 领域模型是对领域内的概念类或现实世界中对象的可视化表示 用图形方式表示领域模型更容易理解 领域模型不是数据模型，含义更广 领域模型不是软件业务对象图 * 领域模型不是软件业务对象图 下面元素不适合领域模型 软件制品 职责或方法 * 领域模型中的概念类 领域模型描述问题域里的概念类及其关系 概念类包含三方面内容 符号 内涵 外延 * 为什么需要领域模型 理解业务领域的关键概念和词汇 减小现实世界系统与OO软件模型表示差异 * 创建领域模型的步骤 从用例文本中寻找 寻找概念类 重用和修改现有的模型 使用分类列表 确定名词短语 用UML中的类图表示 为类添加关联和属性 * 1、寻找概念类 三种方法 重用和修改现有的模型 使用分类列表 确定名词短语 方法1：重用和修改现有的模型 许多领域已经存在领域模型和数据模型，可供参考 Matin Fowler的《分析模式》中的一些分析模式 * 分析模式：组织的内部结构 一般情况 存在部门直接上下级关系以及区域附属管理方式 分析模式 Martin Fowler 组织（Organization）结构 * 方法2：使用分类列表 预先制作概念类候选列表，供创建领域模型参考 P104 方法3：确定名词短语（最主要手段） 其他需求文档（词汇表），领域专家 用例是最主要的来源之一 从用例文本出发，检索出所有名词或名词短语，分析筛选。 * 注意： 自然对象 概念实体 同样概念有多种名词表示，依据系统原意