12-详细设计
1. 详细设计基础
- 详细设计的出发点:软件详细设计是在软件体系结构设计之后进行,以需求开发的结果(需求规格说明和需求分析模型)和软件体系结构的结果(软件体系结构设计方案与原型)为出发点。
1.1. 什么是详细设计
- 中层设计是对特定的模块的,以及针对特定模块的对象/类的低级设计
1.3. 从需求、体系结构设计到详细设计
1.4.3. 详细设计的输出
2.5. 结构化设计
- 结构化设计的重心:从数据流图到结构图
- 上述转化过程:
- 寻找到输入的最高抽象点和输出的最高抽象点
- 根据输入、输出的最高抽象点,对模块进行划分
- 然后在一次对每个模块寻找最高抽象点,再进行模块分解,从而逐步求精得到树状的结构图
- 详细参考课本(201页)
- 是 public, 是 private
4.1.2. 抽象类之间的关系
- 计算总计需要所有SalesLineItem实例及其小计。而这是只有销售(Sale)知道的
- 这就是为什么Sale是信息专家。
- 因此(通过全部的情况进行开展的)
- 因此,职责分配给3个类别。
4.2. 通过协作创建动态设计模型
4.2.1. 抽象对象之间协作
- 从小到大,将对象的小职责聚合形成大职责;
- 从大到小,将大职责分配给各个小对象。
- 这两种方法,?般是同时运?的,共同来完成对协作的抽象。
- 顺序图
- 可以?顺序图表示对象之间的协作。顺序图是交互图的?种,它表达了对象之间如何通 过消息的传递来完成?较?的职责。
- 包含两部分:对象本身和对象之间的信息流
- 信息分为:图示见课本206页
- 同步消息
- 异步消息
- 同步消息返回
4.2.2. 明确对象的创建
4.2.2.1. 创建者模式
- 问题:谁负责创建某个类的新实例li>
- 解决方案:根据潜在的创建者类与要实例化的类之间的关系,确定哪个类应创建类的实例。
- 问题:谁负责创建对象li>
- 回答:如果有以下情况,则由创建者分配B类创建A类实例的职责:
- B 聚集了 A 对象
- B 包含了 A 对象
- B 记录了 A 的实例
- B 要经常使用 A 对象
- 当 A 的实例被创建,B具有传递给A的初始化数据(也就是 B 是创建 A 的实例这项任务的信息专家)
- 在有选择的地方,更喜欢B聚合或包含A对象
- 创建者模式建议是 Sale
- 合作图是
- Piece的创建(那个关联性最强,就是用哪一个来创建)
- Player/li>
- Boardli>
- Squares的创建:Board创建
- Player的创建:用Game创建(没有大问题)
4.2.3. 控制器
- 问题:如何分配处理系统事件的职责li>
4.2.3.1. 控制方式
- 将处理系统事件消息的职责分配给代表以下选项之一的类:
- 整个组织的业务(立面控制器)。
- 整个系统(外观控制器)。
- 在问题域中真实操作解决问题的人(角色控制器)。
- 自动化解决用例的模块(用例控制器)。
4.2.3.2. 控制者
- 购买项目用例中的系统事件
- 输入部分
- 结束售卖
- 结账
- 谁负责输入
- 控制者有四种处理对象
- 整个系统 Post
- 整个业务 商店
- 在现实生活中活跃在任务中的
- 在系统中机器处理这个部分
- 按了按钮就会直接进行响应
4.2.4. 选择合适的控制风格(重要)
- 集中式控制风格
- 委托式控制风格
- 分散式控制风格
- 都是他在调用别人
- 上图例子:通过一些部分特别的方式读取输入
- 更加分散的设计:进行分发,只负责协调
4.2.4.4. 控制的启发1
- 避免大多数消息都来自单个组件的交互设计。
- 保持组件较小。
- 确保并非仅将全部职责分配给几个组件。
- 确保操作职责与数据职责一致。
4.2.4.5. 委托式控制风格
- 作出决策的对象不只有一个,职责的分解决定了控制对象的层次。
4.2.4.6. 分散式控制风格
- 其特点是拥有许多组件,几乎没有数据,职责也很少。
- 很难理解控制流。
- 组件无法独自完成很多工作,从而增加了耦合。
- 隐藏信息是很难的。
- 内聚性通常很差。
- 很少有模块化原则可以满足。
- 完全靠对象自治的方式来实现自己的职责。
4.2.4.7. 控制启发二
- 避免要求每个组件发送许多消息的交互。
6. 详细设计文档描述和评审
- 设计的信息程度对后继开发人员是否足够给不同人应该差不太多。
7. 第三阶段
- 制品合理性
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!