201871010118-唐敬博 实验二 个人项目—《西北师范大学学生疫情上报系统》项目报告
作者:互联网
项目 |
内容 |
课程班级博客链接 |
<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 |
标签:文件,背包,子类,西北师范大学,唐敬博,201871010118,KP,设计,父类 来源: https://www.cnblogs.com/2360689227t/p/14600643.html