05将设计映射为代码.pptVIP

POS可见性设计 发送信息，需要可见性的保证 可见性 可见性包含4层 属性可见 参数可见 局部可见 全局可见 由常见到不常见 属性可见 参数可见 局部可见 B为A方法内的局部对象 创建局部实例 将方法调用返回的对象分配给局部变量 全局可见 B对于A来说是全局的 只要A，B存在，则这种可见性就存在 映射代码 从DCD创建类定义 从交互图映射方法 P267，映射得到Register方法 结合Register的DCD enterItem方法 代码中的集合类 makeLineItem方法 实现顺序 将设计映射为代码 用例实现 用例实现描述某用例基于协作对象如何在设计模型中实现 用例 ? 系统事件? SSD ? 操作契约? 交互图? DCD 系统操作 makeNewSale是根据SSD得到的 每个主要交互图都从进入领域层控制器对象的系统操作开始 窗口对象或GUI对象或Web控制对象 SSD中的系统操作作为起始信息进入Domain层 如果使用通信图，则每一个子系统都需要一个起始信息 SD一样 每一个图都有一个系统操作 设计makeNewSale 选择控制器类 如果只有几个系统操作，fa?ade 控制器就能满足要求 使用Register作为控制器类 创建new Sale Register create Sale Sale create SalesLineItem 实际上Sale创建一个集合，用来存储所有的SalesLineItem子项 设计makeNewSale 创建者或控制器模式 创建者模式创建Sale 创建者模式Sale创建一个集合这个集合中存储有SalesLineItem实例 创建位置位于sale实例的构造函数中 设计enterItem 操作契约：P238 设计enterItem 选择控制器类 显示item的描述和价格（此时忽略） Create SalesLineItem 找到一个ProductDescription ProductCatalog的可见性 如果某对象A要发送信息到另外一个对象B，A必须拥有对B的可见性 数据库设计 设计enterItem 控制器 信息专家 创建者 在List中增加SalesLineItem实例 部分DFD 设计sale.getTotal 设计makePayment 操作契约makePayment P244 设计makePayment 设计makePayment Store负责获知增加Sale，Store的职责较少的时候，可以接受 SalesLedger负责获知增加Sale，专门设立底账类，来避免Store的功能过于繁杂。 设计makePayment 实例为s，并且在2，2.1中被作为参数引用 设计makePayment 计算余额 谁对余额有认知职责？ Payment和Sale都知道部分信息 Payment对于Sale是可见的，而Sale对Payment是不可见的 尽管可以增加Sale对Payment的可见性，但是增加了耦合度 选择Sale作为计算余额并不会增加耦合，选择Payment计算余额则会增加耦合。所以，选择Sale作为余额计算的类 设计余额计算 起始信息 起始信息是初始化系统操作 所有的系统操作考虑完以后，再考虑起始信息 创建领域对象，以支持用例的执行 一个合适的起始对象，能够创建其他的对象 综上，最后创建起始信息 创建起始领域对象 设计Store.create() Create: Store，Register，ProductCatalog，ProductDescription 关联： ProductCatalog与ProductDescription Store与ProductCatalog Store与Register Register与ProductCatalog Store.Create() 传递pc给Register，使得Register可以看到ProductCatalog *表达信息重复传输 大富翁 两个系统操作： 起始 打游戏 游戏部分： 选择控制器类 选择外观控制器 创建控制器类 MGame 游戏循环算法 术语： 轮次：游戏者掷骰子 回合：所有游戏者掷骰子一轮 游戏循环伪代码： 控制游戏循环 完成职责所需信息：P252 谁负责每一轮？ 完成职责所需信息：P253 精化轮次 轮次中需要考虑： 计算骰子的两面值的和 计算新的方格位置 将棋子从旧方格移动到新方格 与以上相关的类： Player 可见性问题： Player必须对上述的对象可见。 轮次： 命令查询分离原则 执行动作，返回数据查询分开 玩游戏的静态设计 起始用例