格式描述


团队分工

学号 姓名 负责工作
221600123 林信康 文件初步处理,消息类创建
221600124 林梓铭 文件初步过滤,代码初步整合
221600125 刘杰 辅助文件过滤,口令设置
221600127 卢成钢 抽奖算法的设计,辅助代码整合
221600128 王华峰 GUI设计、代码汇总、博客

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

团队作业第六次-团队Github实战训练的更多相关文章

  1. 团队作业第六次—团队Github实战训练

    作业描述 课程 软件工程1916|W(福州大学) 团队名称 修!咻咻! 作业要求 团队作业第六次-团队Github实战训练 团队目标 搭建一个相对公平公正的抽奖系统,根据QQ聊天记录,完成从统计参与抽 ...

  2. 团队作业第六次——团队Github实战训练

    作业格式 课程名称:软件工程1916|W(福州大学) 作业要求:团队作业第六次-团队Github实战训练 团队名称:葫芦娃队 作业目标:确定和分析选题,绘制评审表 github地址:https://g ...

  3. 团队作业第六次—团队Github实战训练(追光的人)

    所属课程 软件工程1916 作业要求 团队作业第六次-团队Github实战训练 团队名称 追光的人 作业目标 搭建一个相对公平公正的抽奖系统,根据QQ聊天记录,完成从统计参与抽奖人员颁布抽奖结果的基本 ...

  4. 团队Github实战训练

    班级:软件工程1916|W 作业:团队Github实战训练 团队名称:SkyReach Github地址:Github地址 贡献比例表 队员学号 队员姓名 此次活动任务 贡献比例 221600106 ...

  5. bug终结者 团队作业第六、七周

    bug终结者 团队作业第六.七周 作业要求:团队作业第六.七周 博客编辑:20162322 朱娅霖 一.修改<需求规格说明书> <需求规格说明书>2.0版(即初稿) <需 ...

  6. 团队作业八——第二次团队冲刺(Beta版本)第7天&项目汇总

    项目汇总 第一天:http://www.cnblogs.com/newteam6/p/6879383.html 第二天:http://www.cnblogs.com/newteam6/p/688078 ...

  7. 团队作业八——第二次团队冲刺(Beta版本)第6天

    团队作业八--第二次团队冲刺(Beta版本)第6天 一.每个人的工作 (1) 昨天已完成的工作 简单模式逻辑代码涉及与相关功能的具体实现 (2) 今天计划完成的工作 修改完善注册登录内容界面,编辑错题 ...

  8. 团队作业八——第二次团队冲刺(Beta版本)第5天

    团队作业八--第二次团队冲刺(Beta版本)第5天 一.每个人的工作 (1) 昨天已完成的工作 完成界面跳转界面. (2) 今天计划完成的工作 简单模式逻辑代码涉及与相关功能的具体实现 (3) 工作中 ...

  9. 团队作业八——第二次团队冲刺(Beta版本)第4天

    团队作业八--第二次团队冲刺(Beta版本)第4天 一.每个人的工作 (1) 昨天已完成的工作 做一下用户注册的功能和登录功能. (2) 今天计划完成的工作 完成界面跳转 (3) 工作中遇到的困难 界 ...

随机推荐

  1. Mysql数据库引擎介绍--转载

    引用博文链接:https:/www.cnblogs.com/zhangjinghe/p/7599988.html MYSQL数据库引擎区别详解 数据库引擎介绍 MySQL数据库引擎取决于MySQL在安 ...

  2. CentOS配置svn

    参考: https://www.cnblogs.com/taohaijun/p/7172939.html 1.检查已安装版本  rpm -qa subversion 卸载旧版本SVN yum remo ...

  3. jmeter学习记录--05--Beanshell2

    学习beanshell时有不少的例子.遇到不少问题.在此记录下. 测试实例列表 A1:使用Beanshell请求作为测试请求 一个打包的Jar包,直接对其内的方法进行测试. 第一步:将接口jar包要放 ...

  4. JS中的事件委托(事件代理)

    一步一步来说说事件委托(或者有的资料叫事件代理) js中事件冒泡我们知道,子元素身上的事件会冒泡到父元素身上. 事件代理就是,本来加在子元素身上的事件,加在了其父级身上. 那就产生了问题:父级那么多子 ...

  5. C# 使用CsvHelper读取.csv文件

    1,先到包管理器下载 安装CsvHelper. 2,创建一个与csv文件字段名称相同的类 public class SurveyInfoModel { public string DIST_CD { ...

  6. 常用的前端相关chrome插件

    前面的话 本文将详细介绍笔者在开发中常用的一些chrome插件 字符编码 前端开发时,经常出现乱码的情况.但是,新版本的chrome浏览器已经没有更改字符编码的设置选择,这时就要用到set chara ...

  7. 内部yum仓库制作

    有些安装收到网络隔离(申请一个到DMZ区的通行证很困难) 使用yum的命令工具,在有网络环境下同步我们的yum仓库,并用http服务器代理和制作repo源进行内部安装. 实操: [root@maste ...

  8. 【12】Django 中间件

     前戏 我们在前面的课程中已经学会了给视图函数加装饰器来判断是用户是否登录,把没有登录的用户请求跳转到登录页面.我们通过给几个特定视图函数加装饰器实现了这个需求.但是以后添加的视图函数可能也需要加上装 ...

  9. Java PDF转图片

    maven依赖: <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbo ...

  10. C语言中结构体内存对齐

    先写一个小程序: #include<stdio.h> struct student  {    int a;   char k;   short m; }; int main() { st ...