軟工網絡16我的做業2——WordCount

Deadline：

2018-9-17 22:00PM，以博客提交至班級博客時間爲準
要求參考來自：https://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html；
https://edu.cnblogs.com/campus/buaa/BUAASummerSETraining/homework/2013；
https://edu.cnblogs.com/campus/fzu/FZUSoftwareEngineering1816W/homework/2085 。

1. 實現一個可以對文本文件中的單詞的詞頻進行統計的控制檯程序。
2. 進行單元測試、迴歸測試、效能測試，在實現上述程序的過程當中使用相關的工具。
3. 進行我的軟件過程（PSP）的實踐，逐步記錄本身在每一個軟件工程環節花費的時間。
4. 使用源代碼管理系統 (碼雲)。

---

Task1：編碼要求

1. Fork 碼雲項目 https://gitee.com/SE-net16/PersonalProject-C；
   https://gitee.com/SE-net16/PersonalProject-Java 到本身的倉庫，在本身的碼雲倉庫中新建一個學號命名的文件夾。
2. 在開始實現程序以前，在PSP表格[附錄1]記錄下你估計在程序開發各個步驟上耗費的時間，在你實現程序以後，在PSP表格記錄下你在程序的各個模塊上實際花費的時間。
3. 使用C++或者Java語言實現，C++請使用Visual Studio Community 2017進行開發，Java請使用，運行環境爲64-bit Windows 10。
4. 編寫的代碼遵照代碼規範
   • http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html
   • https://google.github.io/styleguide/javaguide.html
5. 使用碼雲來管理源代碼和測試用例，代碼有進展即簽入碼雲。簽入記錄不合理的項目會被助教抽查詢問項目細節。
6. 使用單元測試對項目進行測試，並使用插件查看測試分支覆蓋率等指標；並寫出至少10個測試用例確保你的程序可以正確處理各類狀況。
7. 在完成我的項目後，請正確發起一個Pull Request，並確保本身的代碼最終成功簽入到 https://gitee.com/SE-net16/PersonalProject-C；
   https://gitee.com/SE-net16/PersonalProject-Java 中。（若是成功簽入會在原始項目主頁看到本身學號爲名的文件夾）

Task2：博客要求

1. 在文章開頭給出博客做業要求地址，碼雲項目地址。
2. 給出我的的PSP表格。
3. 解題思路描述。即剛開始拿到題目後，如何思考，如何找資料的過程。
4. 設計實現過程。設計包括代碼如何組織，好比會有幾個類，幾個函數，他們之間關係如何，關鍵函數是否須要畫出流程圖？單元測試是怎麼設計的？
5. 代碼說明。展現出項目關鍵代碼，並解釋思路與註釋說明。
6. 結合在構建之法中學習到的相關內容與我的項目的實踐經歷，撰寫解決項目的心路歷程與收穫。

Task3：WordCount 項目要求

實現一個統計程序，它能正確統計程序文件中的字符數、單詞數、行數，以及還具有其餘擴展功能，並可以快速地處理多個文件。

第一步：基本功能要求

輸入文件名以命令行參數傳入。例如咱們在命令行窗口(cmd)中輸入：

//C語言類
wordCount.exe input.txt
//Java語言
java wordCount input.txt

則會統計input.txt中的如下幾個指標

• 統計文件的字符數：
  - 只須要統計Ascii碼，漢字不需考慮
  - 空格，水平製表符，換行符，均算字符
  - 統計文件的單詞總數，單詞：以4個英文字母開頭，跟上字母數字符號，單詞以分隔符分割，不區分大小寫。
  - 英文字母：A-Z，a-z
  - 字母數字符號：A-Z，a-z，0-9
  - 分割符：空格，非字母數字符號
  - 例：file123是一個單詞，1file不是一個單詞。file，File和FILE是同一個單詞
• 統計文件的有效行數：任何包含非空白字符的行，都須要統計。
• 統計文件中各單詞的出現次數，最終只輸出頻率最高的10個。頻率相同的單詞，優先輸出字典序靠前的單詞。
• 按照字典序輸出到文件result.txt：例如，windows95，windows98和windows2000同時出現時，則先輸出windows2000
  • 輸出的單詞統一爲小寫格式

• 輸出的格式爲

  characters: number
  words: number
  lines: number
  <word1>: number
  <word2>: number
  ...

第二步：接口封裝

在寫了一些代碼開胃以後，你們都完成了一份知足基本功能的代碼。
你們的代碼都各有特點，若是如今咱們要把這個功能放到不一樣的環境中去（例如，命令行，Windows圖形界面程序，網頁程序，手機App），就會碰到困難：代碼散落在各個函數中，很難剝離出來做爲一個獨立的模塊運行以知足不一樣的需求。
同時咱們也看到，不一樣的代碼解決不一樣層面的問題：

1. 有些是計算數據的（例如統計單詞）
2. 有些是控制輸入的（例如scanf，cin，圖形界面的輸入字段）
3. 有些是數據可視化的（例如printf，cout，println，DrawText）
4. 有些則更爲特殊，是架構相關的（例如main函數，並非全部的程序都須要某個特定格式的main）

這些代碼的種類不一樣，混雜在一塊兒對於後期的維護擴展很不友好，因此它們的組織結構就須要精心的整理和優化。
咱們但願把基本功能裏的：

1. 統計字符數
2. 統計單詞數
3. 統計最多的10個單詞及其詞頻

這三個功能獨立出來，成爲一個獨立的模塊(class library, DLL, 或其它)，這樣的話，命令行和GUI的程序都能使用同一份代碼。爲了方便起見，咱們稱之爲計算核心"Core模塊"，這個模塊至少能夠在幾個地方使用：

1. 命令行測試程序使用
2. 在單元測試框架下使用
3. 與數據可視化部分結合使用

把計算核心在單元測試框架中作過完備的測試後，咱們就能夠在算法層級保證了這個模塊的正確性。
但咱們知道軟件並不是只有計算核心，實際的軟件是交付給最終用戶的軟件，除了計算核心外，還須要有必定的界面和必要的輔助功能。
這個Core模塊和使用它的其餘模塊之間則要經過必定的API來交流。
API應該怎麼設計呢？
爲了方便起見，咱們能夠從下面的最簡單的接口開始（僅舉例，你的代碼裏可能沒有這個函數）：

int countChar(File *file)
這個函數表示輸出一個文件指針，返回這個文件的字符數。
假設咱們用Core封裝了這個接口，那麼咱們的測試程序能夠是這樣：

File *in = fopen("input.txt","r");
int count = 100;
Assert(countChar(in) == count);

固然，這樣的測試程序並不充分，但願你們測試時不要像這樣偷懶。

第三步：錯誤處理並設計單元測試

如今咱們封裝了接口，咱們要對咱們的代碼進行正確性驗證。
另外一方面咱們都知道健壯性對於軟件來講是很是必要的，請各位使用單元測試對項目進行測試，並使用插件查看測試分支覆蓋率等指標；另外，請準備至少10個測試用例確保你的程序可以正確處理各類狀況，而且不會崩潰。
對待錯誤的輸入，可以儘量精確報錯（就像編譯器同樣）。
你能夠有「容錯性」的出錯設計，但必須輸出必要的提示或說明。

第四步：效能分析

如今咱們已經有了一個基礎的詞頻統計軟件，若是它經過了足夠多的單元測試，那它可能也已是一個比較完善的詞頻統計軟件了。可是一個軟件光正確了還不夠，還須要有必定的性能。
那麼，如何讓軟件又快又好地執行呢？那就須要咱們找到執行消耗時間最久的模塊，而後不斷地優化改進它。那麼，如何知道哪些語句是軟件的時間瓶頸呢，這就須要用到效能分析。

使用 Visual Studio 進行 C++ 效能分析：https://docs.microsoft.com/en-us/visualstudio/profiling/beginners-guide-to-performance-profiling
使用 JProfiler 進行 Java 效能分析：http://www.javashuo.com/article/p-urvgxxxt-hn.html

關於效能分析的更多資料，能夠查看：http://www.cnblogs.com/xinz/archive/2011/11/20/2255809.html

參照「效能測試、分析、改進，再效能測試」的流程，找出關鍵模塊消耗最大的函數，而後分析一下：該如何改進這個程序？
值得注意的一點是，效能分析只在真正有性能問題時纔會有顯著結果。也就是說，學員在進行效能分析時，可能統計一個只有100行的文件並看不出來有什麼差別，也看不出來哪裏消耗最大。此時可使用更大的參數試試，好比統計一個有1000,000行的文件，再使用效能分析工具測試消耗時間最多的模塊，再進行改進。

Task4：測試須知

組織目錄

助教在測試時，將運行自動測試程序編譯源文件並運行，進行批量測試，所以請保證項目的組織目錄符合要求.

Java

對於使用Java語言的項目有如下兩點要求：

【以學號爲名的文件夾中】的目錄下必須有src文件夾

1. 在src目錄下必須有名爲Main.java文件，且Main.java中包含 public static void main(String[] args) 方法
2. 一個Java項目的示例組織目錄以下所示：

201621123000(文件夾名字爲學號，這裏以學號201621123000爲例)
|- src
  |- Main.java(主程序，能夠從命令行接收參數)
  |- lib.java(包含其它自定義函數，能夠有多個，對名字不作要求)

C++

對於使用C++語言的項目有如下兩點要求：
【以學號爲名的文件夾中】的目錄下必須有src文件夾，在src文件夾中是可在VS2017下編譯運行的解決方案，解決方案的名字必須爲 WordCount，一個C++工程示例組織目錄以下所示：

201621123000(文件夾名字爲學號，這裏以學號201621123000爲例)
|- src
   |- WordCount.sln
   |- WordCount
       |- stdafx.cpp
       |- stdafx.h
       |- WordCount.cpp
       |- WordCount.vcxproj

評分基準

博客評分

本次博客做業總分 20分，由如下部分組成：

1. 在文章開頭給出本身的碼雲項目地址。（1'）
2. 在開始實現程序以前，在下述PSP表格記錄下你估計將在程序的各個模塊的開發上耗費的時間。（0.5'）
3. 計算模塊接口的設計與實現過程。 設計包括代碼如何組織，好比會有幾個類，幾個函數，他們之間關係如何，關鍵函數是否須要畫出流程圖？說明你的算法的關鍵（沒必要列出源代碼），以及獨到之處。（8'）
4. 計算模塊接口部分的性能改進。 記錄在改進計算模塊性能上所花費的時間，描述你改進的思路。（3'）
5. 計算模塊部分單元測試展現。 展現出項目部分單元測試代碼，並說明測試的函數，構造測試數據的思路。並將單元測試獲得的測試覆蓋率截圖，發表在博客中。（4'）
6. 計算模塊部分異常處理說明。 在博客中詳細介紹每種異常的設計目標。每種異常都要選擇一個單元測試樣例發佈在博客中，並指明錯誤對應的場景。（3'）
7. 在你實現完程序以後，在附錄提供的PSP表格記錄下你在程序的各個模塊上實際花費的時間。（0.5'）

程序評分

本次程序做業總分40分，由如下部分組成：

1. 正確性（30'）
2. 性能（10'）

• 當程序的正確性評分大於25分時才能夠參與性能評分環節，因此請各位同窗務必保證本身程序的正確性。
• 性能評分將採起檔級評分制度，助教將根據同窗們的程序跑同一數據耗費的時間長度將程序分爲若干檔，每一檔的同窗獲得的分數爲 10/檔級數。

注：

• 如能積極響應助教和老師的反饋並在評論2天內作出相應修改，會在已有評分上有必定加分，但原則上得到分數不超過本次做業總分。
• 如對分數有意見，只給一次向助教申訴的機會
• 遲交一週扣實際分數的一半
• 遲交兩週或以上，不給分
• 抄襲倒扣分

【附錄】

附錄1——PSP模板

PSP模版表格以下，第3列和第4列分別對應第2列條目的估計時間和真實時間，模版表格裏的時間只是示意。

PSP2.1	我的開發流程	預估耗費時間（分鐘）	實際耗費時間（分鐘）
Planning	計劃	8	6
· Estimate	明確需求和其餘相關因素，估計每一個階段的時間成本	8	6
Development	開發	82	88
· Analysis	需求分析 (包括學習新技術)	6	10
· Design Spec	生成設計文檔	5	6
· Design Review	設計複審	4	6
· Coding Standard	代碼規範	3	3
· Design	具體設計	10	12
· Coding	具體編碼	36	21
· Code Review	代碼複審	7	9
· Test	測試（自我測試，修改代碼，提交修改）	13	21
Reporting	報告	9	6
·	測試報告	3	2
·	計算工做量	2	1
·	並提出過程改進計劃	3	3

附錄2——單元測試

1. 請根據本身以往積累的測試經驗，在編碼完成以後，提交產品以前，設計測試用例，並編寫單元測試，對本身的項目進行測試。
   • 首先，至少應採用白盒測試用例設計方法來設計測試用例，其餘測試方法不限。
   • 其次，要設計至少10個測試用例，確保你的程序可以正確處理各類狀況。
   • 最後，結合測試評估的要求，對本身的測試設計進行評價，這些測試用例能知足該程序測試的要求嗎？
2. 另外一個重要的措施是要把單元測試自動化，這樣每一個人都能很容易地運行它，而且可使單元測試天天都運行。每一個人均可以隨時在本身的機器上運行。團隊通常是在每日構建中運行單元測試的，這樣每一個單元測試的錯誤就能及時被發現並獲得修改。
3. 推薦閱讀鄒欣老師關於單元測試和迴歸測試
4. 參考：
   • 單元測試之JUnit篇
   • Java單元測試之覆蓋率統計eclemma

附錄3——Git操做

1. Java培訓文檔
2. C++培訓文檔