结对项目--第二次作业
| 姓名 | 学号 | 班级 |
|---|---|---|
| 晓晖 | 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 | 国庆没了。。。 |