结对项目--第二次作业
姓名 | 学号 | 班级 |
---|---|---|
晓晖 | 235 | k |
钦泽 | 232 | z |
链接:
设计api接口:
public interface allocate {
public void Input$Parse(int depnums,int stunums);//读入与处理json数据
public List<String>[] allocateStu(int depnums , int stunums,readJson r)//实现分配
public void outtotxt(List<String>[] dep , Map<Integer,Map<String,String>> departments)//输出
}
内部实现设计(类图):
匹配算法设计:
部门活动时间申请者不可请假超过2次;
按志愿分配,志愿有五个,可不填,优先分配第一志愿、第二志愿以此类推;若第一志愿部门被分配人数已达到或超过可接收人数上限,则不进行第二轮分配,以此类推;
若在某轮次超过部门可接收人数上线,则按权值淘汰,如兴趣和部门匹配一个权值+1,请假一次权值-1;若出现权值为4应被淘汰,淘汰人数有一人,但权值为4的人有2人类似的情况,采用随机淘汰。
测试数据生成:
两个json数组,students和departments,students中含有学号,志愿,某志愿部门活动时间请假次数(这个想法是部门提前确定活动时间,然后学生填申请表的时候以按钮的形式选择是否要请假)
departments中含有部门号,部门可接收人数上线,部门的特点(和学生兴趣匹配)。
参考数据如下:
{
"students": [
{
"number_of_leave": "[2]",
"student_no": "021804021",
"applications_department": "[D001]",
"tags": "[study, music]"
}
],
"departments": [
{
"department_no": "D001",
"member_limit": 13,
"tags": "[basketball, study, film]"
}
]
}
评价自己的算法:
评价算法的时候先吐槽下自己的编程风格,别拿着题就做好不好,又不是刷leetcode,下次拿到这种要整合进项目的功能的实现的时候,先画uml图好不好,这模块化思想严重的编程风格。。。看着自己都难受,当然这次把map,set,list等容器都用得手顺了,也不错。。。
基本还勉强做了到公平和合理吧,部门的事我不太懂,至于志愿为主的分配方式参考的是福大的高考招生分配方式;大方向我认为没错,细节还可以再优化,实现起来非常简单是优点。但是有点死板了。在想会不会部门自己设置权值然后全不按照权值淘汰比较好。
关键代码解释:
存取json解析后的数据,json两层内用嵌套的hashmap,key用学号和部门号,某些需要三层的存在新的hashmap上。
private Map<String,Map<String,String>> students = new HashMap<String,Map<String,String>>() ;
最重要的分配是按志愿分配,基本上做的就是遍历map然后读取志愿(假设当前是第一轮),如果请假没有超过两次,则存入部门号对应的list。
for(Map.Entry<String, List<String>> entry : r.getStudentsApplications_department().entrySet())
{
if(entry.getValue()!=null&&entry.getValue().size()>i)
{
List<String> temp = entry.getValue();
int j=Integer.parseInt(temp.get(i).replaceAll("D", ""));
if(Integer.parseInt(r.getStudentsNumber_of_leave().get(entry.getKey()).get(i))<2)
{
if(flag[j]==false)
{
dep1[j].add(entry.getKey());
}
}
}
}
运行及测试结果展示
{
"admitted": [
{
"member": "[281704887, 071801590, 051804297, 021701098, 081601088, 301702852, 191602318, 061602540, 071803492, 301503594, 231804432, 061804762, 101504058, 251804029]",
"department_no": "D001"
},
{
"member": "[151701348, 111604145]",
"department_no": "D002"
},
{
"admitted": [
{
"member": "[261804155, 191702610, 231503195, 231703323]",
"department_no": "D001"
},
{
"member": "[131501362, 121801993, 261601930, 101504851, 111804998, 091702420, 211803469, 241602552, 011501572, 051701493, 101601775]",
"department_no": "D002"
},
{
"admitted": [
{
"member": "[261802571, 081702481, 221803611, 101502116, 161601728, 091503497, 291802997, 171604700, 161501780, 171804673, 151603587, 061503789]",
"department_no": "D001"
},
{
"member": "[261504938, 051602615, 201604139, 021802744, 061601211, 171604742, 241703750, 261803870, 101804707]",
"department_no": "D002"
},
{
"admitted": [
{
"member": "[181701035, 101503560, 061602490, 191701170, 131702320, 011802041, 101604515, 031703677, 291601353, 061602760]",
"department_no": "D001"
},
{
"member": "[181802659, 211701954, 161602285, 071701555, 021502729, 181504020]",
"department_no": "D002"
},
效能分析:
好险我写的代码耦合度及其的低,调用只有get一点readjson里的属性,这样没有枪没有炮我能自己造呀。哈哈哈哈.jpg
以s5000,d100为例子
各方法运行时间,单位纳秒:
这是存下来的调用关系。。再写个方法分析一下。。
左边是caller,callee是readjson中的get方法。
遇到的困难及解决方法:
1、修改的时候被自己原始代码恶心到了,解决就是人肉跑了一遍,收获就是下次编码一定一定要先好好设计。
2、这个出于好奇,想给json的输出排序。解决方法就是在群里问,然后助教和范飞龙老师给出了实现方案,尤其范飞龙老师还讲了具体的操作,不要太开心(:。收获嘛,好奇宝宝加皮实加脸皮厚真是个好品格。
对队友的评价:
优点:我在看算法课呢,明年就秋招了,菜鸡也得挣扎几下了。哈?你已经做完结对编程的作业了?6666。。。给大佬递茶.jpg
缺点 : 卧槽,什么鬼,全程用String操作,异教徒啊你,请自行反编译String操作好不好,请大声跟我念StirngBuilder、StringBuffer,StringBuilder、StringBuffer...;卧槽,什么鬼,谁告诉你学号是顺序的,请大声更我念Random,Random,Random...;卧槽,什么鬼,你学生兴趣重复了,请大声跟我念Set,Set,Set...;卧槽,算了我自己写过吧。。。。
PSP:
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 10 |
· Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
Development | 开发 | ||
· Analysis | · 需求分析 (包括学习新技术) | 80 | 140 |
· Design Spec | · 生成设计文档 | ||
· Design Review | · 设计复审 (和同事审核设计文档) | ||
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
· Design | · 具体设计 | 0 | 0 |
· Coding | · 具体编码 | 60 | 120 |
· Code Review | · 代码复审 | 20 | 20 |
· Test | · 测试(自我测试,修改代码,提交修改) | 60 | 120 |
Reporting | 报告 | 30 | 60 |
· Test Report | · 测试报告 | ||
· Size Measurement | · 计算工作量 | ||
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 60 |
合计 | 150 | 270 |
学习进度条:
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 600 | 600 | 22 | 22 | 和javaio死磕了一边 |
2 | 1000 | 1600 | 26 | 48 | xml解析与nabcd |
34 | 4322 | 5932 | 100 | 148 | 国庆没了。。。 |