格式描述
- 课程名称:软件工程1916|W(福州大学)
- 作业要求:项目系统设计与数据库设计
- 团队名称:为了交项目干杯
- GitHub地址:地址
- 作业目标:搭建一个相对公平公正的抽奖系统,根据QQ聊天记录,完成从统计参与抽奖人员颁布抽奖结果的基本流程
团队分工
学号 | 姓名 | 负责工作 | 贡献比例 |
---|---|---|---|
221600123 | 林信康 | 文件初步处理,消息类创建 | 19% |
221600124 | 林梓铭 | 文件初步过滤,代码初步整合 | 19% |
221600125 | 刘杰 | 辅助文件过滤,口令设置 | 18% |
221600127 | 卢成钢 | 抽奖算法的设计,辅助代码整合 | 26% |
221600128 | 王华峰 | GUI设计、代码汇总、博客 | 18% |
github提交日志截图
程序运行截图
程序运行环境
本次实训的环境为windows系统下 Visual Studio 2017,
GUI界面
基础功能实现
消息类Message具有4个成员变量用户名name,账号num,时间time,消息message。
文件处理类FileProcessing负责文件读取。构造函数传入文件路径path。read函数用正则表达式执行读取操作,并存入list中。
Ifnoassistant过滤助教和系统信息和教师:通过正则表达式筛选出符合条件人
InsertQnum向哈希表中插入数据:符合抽奖条件的人才能插进去
GetArray给予客户端调用获得参与获奖的名单:返回符合条件的人的数组
Getnum给予抽奖算法调用的可参与的人数:返回符合抽奖的人数,用于抽奖算法
filter筛选算法:整合以上加另一个同学的算法得出符合条件的人
抽奖发言时段
if (Qtime.CompareTo(Begingtime) >= 0&& Qtime.CompareTo(Endtime)<=0)
return true;
用文件处理提取出当前时间来判断是否符合抽奖时间段只需比较字符串既可
设置参与抽奖关键词,所有发某个关键词的用户可参与,比如:#我要参与换组活动#、#我要红包#、#我爱软工实践#、#我要当学习委员#
Regex regex = new Regex(@"#+w+#");//构造方法里面的参数就是匹配规则
简单的正则表达匹配出字符串和从UI界面读取的口令进行比较
附加功能实现
抽奖过程可以描述为从0~N-1(N为奖券总数)的整数中抽取一个或多个随机整数的过程。除了抽奖算法和抽奖过程需要公开透明外,一个公平的抽奖过程所使用的随机数应具有如下的性质:
1. 随机数的生成过程不需要依赖用户对本网站或者任何第三方平台的信任
2. 事先无法预测
3. 事后公开可查
4. 概率上满足均匀分布
为了保证性质1~3,我们选择使用比特币区块的哈希值来作为我们的随机数种子;性质4只要选取常用的哈希函数即可保证。
假设奖券编号是连续发放的整数。我们的的抽奖算法如下:
选取距离指定时刻(即抽奖时间)最近的被挖出的比特币区块的哈希值作为随机数种子,记作 S。
用 SHA-256 算法计算 S 的的哈希值 H,然后把 截取H的后三位当作十六进制数转换为十进制数L。
W = L % N 为中奖的奖券编号,其中 N 为总奖券数量,%为求余数。
如需抽出 M 个中奖者,则设新种子为 S = H 并且重复 2、3 两步,直到抽出 M 个不重复的中奖者为止。
上述抽奖步骤实际上是用完全公开可验证的方法生成了一个或多个不可控的随机数,其中最重要的随机数种子由比特币区块的性质来保证它满足我们所有的要求。只要知道了我们公布的抽奖时间和发放的奖券总数,任何人都可以在奖券停止发放后计算出一样的伪随机数,从而实现了可验证的公平抽奖结果。
此函数的输入参数分别是:min_n 为奖券编号中最小的(通常我们会把它设成0);max_n 为奖券编号中最大的(取决于参与抽奖的用户数);num_win 为指定的中奖人数;key 为指定的抽奖时间后被挖出的第一个比特币区块的哈希值。
其中的 key 值我们会在开奖后公式,我们是根据比特币区块浏览器确定(https://btc.com)或者大家也可以自己去任何比特币信息查询网站查到相应的区块哈希值。
我们的抽奖结果能保证完全公平吗?
在使用了以上方法生成中奖号码后,暗箱操作的可能性已经大大降低了,但是我们仍然无法完全证明我们的抽奖结果是公平的,原因在于我们无法证明发放的奖券总数的正确性。出于保护用户隐私的目的,我们不能公开每一位参与抽奖的用户的信息,所以理论上来说,我们可以通过增发不存在的奖券来降低用户的中奖概率。为此我们过滤掉了一些教师和助教、不常发言的僵尸用户等。而如果使用聊天记录作为抽奖的依据,那么大家可以通过查询相关的聊天记录来查看奖券情况。如果奖券的发放有什么异常,大家随时都可以发现。
还有一种改变中奖概率的方式,就是自己参与比特币挖矿,如果挖出了区块并且算出自己没有中奖,可以抛弃这个区块不上报,以期待在没有被其他人抢先的情况下下次挖出的区块可以让自己中奖。然而,挖出一个有效比特币区块的奖励是 12.5 BTC,价值约为 50k USD 以上,矿工间竞争激烈也没有人能保证不被其他矿工抢先,所以有点理智的人都不会干这么奇葩的事情。
遇到的困难和解决方法
lxk:在文件读取时上下文不匹配出现错位,改bug花了不少精力。最后多引入了几个标志变量来解决这方面有待改进。
lj:学习c#的正则表达式花费了大量的时间,虽然最总结果能运行,不过省下这时间可以为团队做出更多贡献。
lzm:代码整合时,出现接口不匹配问题,最后匹配一致花了不少时间,下次写代码一定要先商量号接口
lcg:c#爬虫爬取比特币哈希值时,由于手机端热点网络传输与宽带网络传输有差异,导致爬取的哈希值出现了乱码的情况,搞清问题所在却很难具体解决方案,网络上的资料也非常少
whf:第一次进行分开代码训练在整合的时候手忙脚乱不知所措,最后几个人齐心协力花了大量时间才勉强满意。
一句话吐槽
lxk吐槽:如果再多给我10个小时,那么我超级强
lzm吐槽:如果再多给我一次机会,那么我一定好好学github
lj吐槽:如果再来一次,那么我要换老师
lcg吐槽:如果网页不乱码,那么我早就下班了
whf吐槽:如果当初好好学c#,那么我界面画的超好
组员的贡献比例
学号 | 姓名 | 贡献度 |
---|---|---|
221600123 | 林信康 | 18 |
221600124 | 林梓铭 | 18 |
221600125 | 刘杰 | 18 |
221600127 | 卢成钢 | 24 |
221600128 | 王华峰 | 22 |
个人PSP表格
221600123_林信康
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
•Estimate | • 估计这个任务需要多少时间 | 450 | 520 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 60 | 50 |
• Design Review | • 设计复审 | 30 | 40 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
• Design | • 具体设计 | 50 | 60 |
• Coding | • 具体编码 | 50 | 60 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 50 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 610 | 720 |
221600124_林梓铭
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
•Estimate | • 估计这个任务需要多少时间 | 450 | 520 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 60 | 50 |
• Design Review | • 设计复审 | 30 | 40 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
• Design | • 具体设计 | 50 | 60 |
• Coding | • 具体编码 | 50 | 60 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 50 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 460 | 530 |
221600125_刘杰
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
•Estimate | • 估计这个任务需要多少时间 | 450 | 520 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 60 | 50 |
• Design Review | • 设计复审 | 30 | 40 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
• Design | • 具体设计 | 50 | 60 |
• Coding | • 具体编码 | 50 | 60 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 50 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 645 | 710 |
221600127_卢成钢
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
•Estimate | • 估计这个任务需要多少时间 | 450 | 520 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 60 | 50 |
• Design Review | • 设计复审 | 30 | 40 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
• Design | • 具体设计 | 50 | 60 |
• Coding | • 具体编码 | 50 | 60 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 50 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 500 | 650 |
221600128_王华峰
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
•Estimate | • 估计这个任务需要多少时间 | 450 | 520 |
Development | 开发 | ||
• Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
• Design Spec | • 生成设计文档 | 60 | 50 |
• Design Review | • 设计复审 | 30 | 40 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
• Design | • 具体设计 | 50 | 60 |
• Coding | • 具体编码 | 50 | 60 |
• Code Review | • 代码复审 | 40 | 50 |
• Test | • 测试(自我测试,修改代码,提交修改) | 30 | 50 |
Reporting | 报告 | ||
• Test Report | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 10 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 40 |
合计 | 450 | 520 |