團隊作業第六次—團隊Github實戰訓練

作業描述

所屬課程	軟件工程1916|W（福州大學）
作業要求	團隊作業第六次—團隊Github實戰訓練
團隊名稱	待就業六人組
作業目標	搭建一個相對公平公正的抽獎系統，根據QQ聊天記錄，完成從統計參與抽獎人員頒布抽獎結果的基本流程。
項目文檔	項目在線文檔
在線抽獎	項目在線展示
項目地址	Github

服務器最近不穩定，如果出現異常情況，請聯系待就業六人組小組成員

一、組員職責分工&組員貢獻比例

成員	職責	貢獻比例
XRK	Web前端、博客編寫	22%
Yellye	Web前端	16%
黎煥明	聊天記錄處理、聊天記錄分析	15%
Litm	提取用戶表	17%
oirving	提取獎項表、獎項條件表	16%
supermingjun	過濾&中獎算法、程序整合、接口&數據字典文檔編寫，服務器部署，博客撰寫	14%

二、GitHub提交日志截圖

三、程序運行截圖

• 設置抽獎事件、文案、規則

• 輸入校驗

• 查看抽獎結果

• 聊天記錄分析
  使用Anaconda中的繪圖工具可分別統計得到按小時和日的活躍發言統計圖以及高頻詞匯圖，具體可視化圖如下：

四、程序運行環境

• 編程語言
  • 前端：HTML、JavaScript
  • 后端：Java、python3.5
• Apache Tomcat 8.0
• MySQL 5.5
• 瀏覽器
  • Google Chrome 版本73.0.3683.103(正式版本) （64位）
  • Firefox Quantum 66.0.3(64位)
• IDE
  • intellij idea
  • eclipse

五、GUI界面

• 抽獎設置

• 抽獎結果查看

• 數據挖掘結果

六、基礎功能實現

• 實現完整GUI界面——JSP代碼

• 設置抽獎事件、文案、規則

• 導出抽獎結果（抽獎話題、中獎人員、對應獎項）,有bug，暫未實現

• 抽獎算法設計思路

  • 篩選活躍用戶
    采用算法：perception感知器算法
    單層感知器是指只有一層處理單元的感知器。其拓撲結構如圖所示，其中輸入層也稱感知層，有n個神經節點，這些節點只負責引入外部信息，每一個節點接收一個輸入信號，n個輸入信號構成輸入列向量X。輸出層也稱為處理層，有m個神經元節點，每個節點均有信息處理能力，m個節點向外部輸出信息，構成輸出列向量O。兩層之間的連接權值用權值列向量Wj表示，m個權向量構成單層感知器的權值矩陣W。

perception感知器是單輸出感知器，不難看出，單節點感知器實際上就是一個M-P神經元模型，采用符號轉移函數。

設輸入向量X=(x1,x2,x3)T,則3個輸入分量在幾何上構成一個三維空間。節點j 的輸出為：

由以下方程確定的平面成為三維輸人樣本空間上的一個分界平面：

平面上方的樣本neti>0,從而使輸出為1;平面下方的樣本netj<0,從而使輸出為一1。同樣，由感知器權值和闊值確定的平面方程規定了分界平面在樣本空間的方向與位置，從而也確定了如何將輸入樣本分為兩類。假如分界平面的初始位置不能將兩類樣本正確分開，改變權值和闊值即改變了分界平面的方向與位置，因此總可以將其調整到正確分類的位置。

基於perception算法，我們用粗糙的數據集訓練了一個粗糙的模型，對用戶活躍度進行判定。算法輸入輸出如下：

input：用戶的總活躍天數、最大連續活躍天數、有效發言數	
output：1（活躍用戶）、-1（不活躍用戶）

• Fisher–Yates隨機置換算法抽獎

  Fisher–Yates隨機置亂算法也被稱做高納德置亂算法，通俗說就是生成一個有限集合的隨機排列。Fisher-Yates隨機置亂算法是無偏的，所以每個排列都是等可能的，使用的Fisher-Yates隨機置亂算法是相當有效的，需要的時間正比於要隨機置亂的數，不需要額為的存儲空間開銷。

算法流程：

1. 根據過濾條件，從數據庫抽取有抽獎資格的用戶：

（1）不過濾：只要在抽獎時間段發布過抽獎關鍵詞的用戶均可參加抽獎
（2）普通過濾：過濾掉助教和老師用戶，過濾掉潛水用戶（聊天只發抽獎關鍵詞）
（3）深度過濾：過濾活躍度低於x的用戶

2.由perception算法將有抽獎資格的用戶分成活躍和非活躍兩類，給與不同的權重，例如活躍權重為2，非活躍為1，設置一個String數組a，存儲抽獎資格用戶的用戶id，每個用戶在這個數組的元素個數等於權重數：

例如一個id為666的活躍用戶，他在a數組中有兩個元素a[x]="666"，a[y]="666"；

調用Fisher–Yates隨機置換算法，將a數組置亂。

for i 從n-1到1
j <—隨機整數(0 =< j <= i)
交換a[i]和a[j]
end

3.根據獎項數量為k，就取前k個元素，按獎項順序得獎，若出現已經獲獎的用戶，則順延至k+1的用戶獲獎，以此類推。

七、附加功能實現

• 支持對聊天記錄進行分析與挖掘
  活躍期：從圖中分析可以得到，大部分同學發言都喜歡在晚上22點，這時候正是同學們思維活躍期，活躍日期主要是3號，可能這一天發生着某些特別的事。
  高頻詞匯：二手群非常喜歡喜歡發圖片以及“帶價出”、“xx價格出”等，任務群大多交流一些和計算機知識相關的內容，例如網站開發、java作業等。

PlusA

PlusB

八、遇到的困難以及解決辦法

• XRK

  • 遇到的問題：在本次實訓中，我負責的是把前端表單轉換成json格式，利用post請求把數據發送到后台，以及通過異步回調，將后台的數據展現到前端界面中。雖然之前學過HTML和JavaScript，但是並不怎么涉及到異步傳輸的問題，所以在這上面卡了很久。
  • 解決的辦法：最終完成了這樣功能，離不開互聯網的幫助。通過網上查詢相關的例子和其他人的博文講解來學習。

• Yellye

  • 遇到的問題：此次作業我負責的是前端，主要是界面顯示。在設置獎項方面，開始的設想是像微博一樣固定只能設置三個獎項，但后來還是決定給用戶自己設置獎項數目的自由，所以在動態增刪表格並獲取輸入的數據這邊花了一些時間。雖然學過JavaScript但是很久沒練習太生疏了，說明技術還是得多練。
  • 解決方法：感謝科技，感謝互聯網，感謝樂於分享自己學習成果的大牛們！

• 黎煥明

  • 遇到的問題：1. emoj不能存進數據庫. 2. 讀取文件編碼錯誤（不同ide造成）.
  • 解決辦法：1. 設置表結構可存emoji. 2. 更改編碼.

• Litm

  • 遇到的問題：前端的請求參數是json，后端處理接收數據的時候格式變掉了，修改了好長時間。但是還是沒有找到原因。還有編碼問題，第一次這樣協同合作，問題還是很多的。
  • 解決的辦法：參數問題，就是百度查找，修改嘗試。編碼問題，不斷修改嘗試。經過這一次學習到了很多，第一次這樣協同編碼出問題是很正常的，希望之后會越來越好。

• oirving

  • 遇到的問題：我本次做的是把聊天記錄表轉換成的用戶表，提取其中的信息並匯總，都是涉及一些數據的操作，沒有特別難的點；最影響我進度的就是各成員的軟件版本沒有統一，我用的又是MacBook跟大家的系統不太一樣，所以很多東西從GitHub上pull下來后不能直接使用，需要調試很久，非常影響進度。

  • 解決辦法：首先這個問題是每人電腦的差異，客觀存在的問題，要把每個成員的軟件版本都統一太麻煩了，所以我選擇了用他們的電腦pull下來在他們的電腦寫代碼，實在是花費了太多時間去配置參數，拖不起啊。自己能力也需要加強，意識到了工程能力的差距。

• supermingjun

  • 遇到的問題：在創建倉庫的時候，沒有把基本的DAO層和POJO層的代碼統一，時間又比較緊，導致后面隊友集中pull的時候merge出現了很多的沖突。
  • 解決辦法：查看沖突的位置，解決沖突。吸取教訓，以后一定要實現規划好。

九、PSP表格（六合一）

PSP2.1	Personal Software Process Stages	XRK (預估耗時（分鍾）/實際耗時（分鍾)	Yellye (預估耗時（分鍾）/實際耗時（分鍾)	黎煥明 (預估耗時（分鍾）/實際耗時（分鍾)	Litm (預估耗時（分鍾）/實際耗時（分鍾)	oirving (預估耗時（分鍾）/實際耗時（分鍾)	supermingjun (預估耗時（分鍾）/實際耗時（分鍾)
Planning	計划
• Estimate	• 估計這個任務需要多少時間	30/30	30/30	40/40	80/80	30/30	50/50
Development	開發
• Analysis	• 需求分析 (包括學習新技術)	240/360	60/90	50/70	30/40	60/100	80/60
• Design Spec	• 生成設計文檔						40/60
• Design Review	• 設計復審
• Coding Standard	• 代碼規范 (為目前的開發制定合適的規范)						40/30
• Design	• 具體設計	120/180	120/130	70/80	90/110	100/120	120/80
• Coding	• 具體編碼	360/540	240/450	260/560	200/550	240/500	360/480
• Code Review	• 代碼復審	120/180	150/200	60/80	60/120	100/120	40/90
• Test	• 測試（自我測試，修改代碼，提交修改）	160/180	60/100	50/80	60/150	60/80	50/80
Reporting	報告
• Test Report	• 測試報告
• Size Measurement	• 計算工作量
• Postmortem & Process Improvement Plan	• 事后總結, 並提出過程改進計划
	合計	1030/1470	660/1000	530/910	520/1150	520/980	780/930