|
项目 |
内容 |
|
课程班级博客链接 |
<https://www.cnblogs.com/nwnu-daizh/p/14552393.html> |
|
这个作业要求链接 |
<https://www.cnblogs.com/nwnu-daizh/p/14552393.html> |
|
我的课程学习目标 |
<1.掌握软件项目个人开发流程 |
|
这个作业在哪些方面帮助我实现学习目标 |
<1.熟悉并掌握GitHub与Eclipse的连接 |
|
项目Github的仓库链接地址 |
<填写地址> |
任务1的作业点评链接（3分）
1，https://www.cnblogs.com/ws-t/p/14552466.html
2，https://www.cnblogs.com/sxy19991214/p/14552437.html
3，https://www.cnblogs.com/20000910090X/p/14542227.html
作为任务3的项目实施过程文字资料，请完整包含下面7个部分：
1. 需求分析，即使老师已经给出了题目，也要对题目的需求做分析。（5分）
背包问题（Knapsack Problem，KP）是NP Complete问题，也是一个经典的组合优化问题，有着广泛而重要的应用背景。{0-1}背包问题（{0-1 }Knapsack Problem，{0-1}KP）是最基本的KP问题形式，在此之前，学习过{0-1}背包问题的动态规划算法以及回溯法，本实验中任务3-1要求读取所给TXT文件的有效D{0-1}KP数据，任务3-1是将其读取的有效数据以重量为横轴、价值为纵轴的数据散点图，任务3-3要求对一组D{0-1}KP数据按项集第三项的价值:重量比进行非递增排序，即递减排序，任务3-4是选择动态规划算法、回溯算法求解指定D{0-1} KP数据的最优解和求解时间（以秒为单位），任务3-5是将任务3-4中计算所得最优解、求解时间和解向量可保存为txt文件或导出EXCEL文件。
2. 功能设计，获得题目需求后，要对项目做功能设计，但题目需求是项目的基本功能要求，自己思考和调研会有超出题目要求的需求，甚至你的奇思妙想会设计出特色的功能。因此，功能会有：
基本功能：
（1）可正确读入实验数据文件的有效D{0-1}KP数据；
（2）能够绘制任意一组D{0-1}KP数据以重量为横轴、价值为纵轴的数据散点图；
（3）能够对一组D{0-1}KP数据按项集第三项的价值:重量比进行非递增排序；
（4）用户能够自主选择动态规划算法、回溯算法求解指定D{0-1} KP数据的最优解和求解时间（以秒为单位）；
（5）任意一组D{0-1} KP数据的最优解、求解时间和解向量可保存为txt文件或导出EXCEL文件。
3. 设计实现，设计包括你会有哪些类，这些类分别负责什么功能，他们之间的关系怎样？你会设计哪些重要的函数，关键的函数是否需要画出流程图？函数之间的逻辑关系如何？（10分）
（1）ReadTheFil类 ：通过文件路径来创建文件实例，把FileInputStream实例 传递到 BufferedInputStream，目的是能快速读取文件，最后，使用available检查是不是读到了文件末尾。
（2）ScatterDiagram类 ：创建二维数组data存储profit价值和height重量，以重量为横轴、价值为纵轴，建立直角坐标系画出散点图。
（3）WeightRatio类 ：分别定义int类型数组profit和weight数组将价值和重量存储，因为所给数据全部为int型，再定义比值ratio为double类型，再将其int类型数组强制转换为double进行比值运算，最后运
用冒泡排序将比值进行降序排序。
（4）Time类 ：使用动态规划算法：在0/1背包问题中，物品i或者被装入背包，或者不被装入背包，设xi表示物品i装入背包的情况，则当xi=0时，表示物品i没有被装入背包，xi=1时，表示物品i被装入背包。
6. 总结：你设计的程序如何实现软件设计的“模块化”原则。（5分）
1. 单一职责原则：
类的职能要单一：
遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险
2. 里氏替换原则：
子类对象可以替换父类对象。子类不要增加父类没有的约束。这样会导致父类有些方法不能用。从而不能真正的实现 ： 子类对象可以替换父类对象，如果子类重写了父类已实现的方法，那么子类调用的父类的方法就完全没用了，从而不是真正意义上的继承。
3. 依赖倒置原则：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
4.接口隔离原则：
在设计接口的时候，给每一个接口设计不多不少的方法，因为，如果设计的方法多了，当某个类通过接口来依赖某个类的时候，被依赖的那个类要实现的方法太多了，会造成那个类中大量的代码冗余，不可过少的原因是，接口太多，会让设计变复杂，且不便于管理。
5.迪米特原则：
低耦合，高内聚，即类A与类B，如果没必要依赖吗，则代码尽量不要耦合，如果这两个类要产生通信，则创建一个中间的通信类C去与这两个类进行交互。但是这样的通信类要适量。
6.开闭原则：
对实现封闭，对扩展开放。即当一个一个方法需要增加其他的功能，或者代码需要重构的时候，要扩展软件的行为，尽量不要去修改已有的代码。用抽象构建框架，方法的实现来扩展细节。
7. 展示PSP，这个环节重要的是让自己看到自己的估计和实际消耗时间，哪个环节耗时最多，哪个环节估计和实践相差巨大？为什么？（5分）
| PSP | 任务内容 | 计划共完成需要的时间(min) | 实际完成需要的时间(min) |
|---|---|---|---|
| Planning | 计划 | 8 | 15 |
| Estimate | 估计这个任务需要多少时间，并规划大致工作步骤 | 8 | 15 |
| Development | 开发 | 168 | 291 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 25 |
| Design Spec | 生成设计文档 | 15 | 25 |
| Design Review | 设计复审 (和同事审核设计文档) | 10 | 16 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 3 | 5 |
| Design | 具体设计 | 35 | 40 |
| Coding | 具体编码 | 45 | 90 |
| Code Review | 代码复审 | 10 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 60 |
| Reporting | 报告 | 9 | 11 |
| Test Report | 测试报告 | 3 | 5 |
| Size Measuremen | 计算工作量 | 3 | 2 |
| Postmortem & Process Improvement Plan | 事后总结 ,并提出过程改进计划 | 3 | 4 |