预构 笔记
来源:互联网 发布:数控如何编程 编辑:程序博客网 时间:2024/06/06 20:06
简介
项目结束时,要进行回顾:
1. 评估开发过程: 学到的经验和教训; 问题的解决方案
2. 评估设计: 设计适合什么样的问题域; 开始应关注什么问题;什么样的需求变化导致系统大幅修改; 是否有更好的方案;
The System in so many words
1. 将 list of requirements变成 user case。 需求也包括 reliability testability deployability and performance
2. user case 包括: 功能描述;错误描述;测试方案
3. 为概念创建清晰的名词
4. 建立原型
5. 查找能用上的已有功能模块
General Development Issues
1. start from big picture( overal archetecture和 business purpose ) 决定要采用的技术
2. 使用接口交互:函数定义包括执行条件和返回结果
3. consistency is simplicity: code style convention; 采用通用设计
4. 对 assumptions and decisions提供注释:问题,假设,策略
Getting the big picture
1. iteractive development
analysis:
重点明白 basic user case,基本概念,概念间的关系(1:n 等)。界面显示和如何实现不重要
使用CRC ( class - responsibility - collaboration)设计类的作用和类间的交互。选取一个用例,从确定的对象开始,通过交谈完成用例的活动,只能要求该类提供某种活动,而不能提供某种信息,当有工作没做时,在类中添加函数或创建新类。
在使用词汇时尽量固守在 问题领域,假设计算机不存在,人怎么解决问题。
一但解决一个会话,开始录音,则这种录音是动态模型,CRC卡片是静态模型
基本步骤:
了解问题域——要解决什么问题
识别用例——由终端用户完成,具有有用结果的任务
创建CRC和动态模型
design:
细节划分:设计属性和函数; 画出class diagram。global planning local designing 在增量开发中这样做
2. 功能性测试
在开始设计时,根据user case设计草案,包括 basic use cases和misuse cases
测试策略可产生更好的设计
向用户进行测试反馈
3. 设计初期就要考虑系统的安全性
A few words on change
1. highly cohesion and loosely coupling高内聚和低耦合
高内聚:是否可用一句话描述类的作用
低耦合:尽量使用 interface和 delegate
2. 尽量不使用函数重载
3. 修改容易混淆的函数:修改名称,使用工厂方法替代构造函数
The First Release
1. 第一次版本发布后,要写总结日志:
- 人与人的交互方式及效果
- 总结改变了的设计方案和原因
- 理解错误
- 运行速度
- 缺少的信息
在小版本发布时有份简单的日志,主要版本发布时有份长的日志
2. 错误处理
具体的错误处理要和用户协商,最终显示给用户的信息应该不包括程序细节
3. 简单重构
需要读入信息的类,有一函数 Load
去处 fat class和 big method
创建合适的包
类、文件、函数、属性有合适的名称
类,函数,属性的位置基本正确
4. 第一次迭代
只包括两个user case
Association and State
对象状态: 状态改变只影响一个函数时使用 switch,影响多个函数时使用state pattern
Interface and Adaptation
1. 得出 User case后要及时和用户交互
2. 查询优化: 构造 ItemConfig对应列表显示信息,使用Item显示该对象详细信息
3. 测试针对接口中的方法,而不是具体实现
4. 拆分接口:如果不同用户访问一个接口的不同函数,则需要拆分接口
5. 使用模板保证类和对象的一致性
Zip code and Interface
1. unwritten code
1. 定义需求
2. 编写测试脚本
3. 查找已有的组件
Sam is expanding
多系统间交互: 1.建立中心数据库存放共享信息,但要考虑同步; 2. 两系统分开存放各自信息,并对外提供可交互接口
与外部系统交互: 1.定义协议和接口 2. log每次访问和输入验证
当想要泛化但现在还没必要时,写在日志中。