軟工我的設計（Java）

1、GitHub的網絡地址：https://github.com/qiannai/WC.git

2、PSP圖表：

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
·Planning	·計劃	30	20
· Estimate	· 估計這個任務須要多少時間	30	10
·Development	·開發	1440	760
· Analysis	· 需求分析	60	80
· Design Spec	· 生成設計文檔	30	20
· Design Review	· 設計複審	20	20
· Coding Standard	· 代碼規範	70	110
· Design	· 具體設計	40	20
· Coding	· 具體編碼	750	700
· Code Review	· 代碼複審	20	18
· Test	· 測試（自我測試，修改代碼，提交修改）	200	300
·Reporting	·報告	100	140
· Test Report	· 測試報告	60	50
· Size Measurement	· 計算工做量	20	18
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	40	50
合計		2910	2316

3、解題思路：

1.整體思路：對題目進行需求分析與方法設計，該題目主要是由5個功能組成的[-c|-l|-w|-a|-s|-x]，我的想法是創建類在類中對每個功能進行實現。最後經過WC的主類對全部的功能進行集成。並且對於難度實現進行分塊，因此一期實現[-c|-l|-w]三個功能，由於功能的操做具備必定的類似性；二期逐步實現[-a][-s]功能；其次實現[-w]功能。在功能實現的同時對該功能進行功能測試，保證功能的準確性，在後期調用的過程當中保證返回的數據是正確的。減小查找錯誤位置跟錯誤返工的時間。

2.對於-c，-l，-w三個功能，便是處理文檔路徑輸入後，讀取文件，對文件的字符數行數單詞數計數。經過readLine（）方法讀取文件每一行計算行數。對整個文檔去除掉空格跟換行符則能夠讀出文檔字符數。對於單詞，對於連續一段字母組成則判斷爲一個單詞，對文檔用非字母進行分割，利用正則表達式則能夠判斷是不是連續一段字母，能夠判斷是不是單詞，並對其計數。

3.對於-a功能則是利用正則表達式對讀取的一行作出判斷，在判斷/**/組成的註釋塊時添加標記flag，當讀出是/*作出標記，遇到*/時標記結束，在這段標記過程當中，註釋行加1。

4.對於-s功能，則是將判斷是不是有輸入-s分開，只實現對文檔的遞歸。在這裏又創建了一個類判斷後綴名是否一致，一致則對文檔輸出不然不輸出。文檔的接口爲 文件類型的遞歸文件夾、String類型的含通配符的絕對路徑，還有對輸入的[-c|-l|-w|-a]的Boolean值。對文件路徑調用listFiles（）方法遍歷文件，若是路徑存在且符合則運行不然判斷是不是文件夾，對文件夾進行遞歸調用。運行結果爲輸出爲該通配符下的符合文件的[-c|-l|-w|-a]選擇的方法。

5.對於-x功能，則創建一個類用於可視化。主要是能夠選擇文件，也是擴展了一下，-x功能能夠對文件的[-c|-l|-w|-a]進行選擇，也不是所有輸出。並且-x對-s有覆蓋功能，只要出現-x則-s功能不可用。在可視化類Visual中，添加一個文本框用於輸出結果，一個按鈕調用JFileChooser調用GUI界面，並保存選擇文件的路徑，對路徑下的文件輸出選擇的結果到文本框中。

6.對全部的功能集成到WC類中，須要有一個方法對用戶輸入進行判斷用戶的輸入格式，經過正則表達式判斷格式，並將輸入切割出來，將功能選擇的切割出來，經過構造isChoose（）方法判斷用戶選擇了什麼功能，將路徑切割出來用path保存。用if……else if語句對-x和-s方法分類。-x則調用Visual類，-s則判斷是否路徑輸入是通配符格式仍是非通配符格式。其他的輸入則分爲一類判斷並調用相對應的方法。

4、設計與實現：

主類先對[-x][-s]判斷，[-s]對輸入的路徑的多重判斷，再調用CharCounter和LineCounter類返回各個結果。

5、測試：

一、輸入wc.exe輸出功能介紹

二、創建測試文檔

三、手工一個測試空文件、一個字符文件、一個單詞文件、一行數據文件、一個任意源文件

四、使用-s對輸入絕對路徑處理，而且與通配符比較結果

四、通配符與對行數計數，對整個盤符遞歸查詢

五、使用-x實現基本的Windows GUI 程序操做，支持經過圖形界面選取文件，支持經過圖形界面展示文件的信息

在是不是單一測試仍是遞歸測試下結果都是同樣的。

6、總結：

一開始以爲按照模塊化的開發方式能夠比較好，由於將每一個功能分開來，對每個功能均可以創建一個main函數對該功能進行測試，不過最後的時候，在將全部功能集成到主函數上的時候就出現了很是混亂的狀況，主要是對於模塊化對接口與返回沒有作好規範，結果致使調用得多了出現了很混亂的狀況。因此後面在作代碼優化的時候也是耗費了不少時間，不過每一個功能一開始就作大量的測試，因此集成在一塊兒的時候去考慮最後結果的正確性所花費的時間比較少，不用花費不少時間去判斷結果的正確性。可是此次做業中由於代碼比較不規範形成了不少的時間上的浪費，可見還要學習的東西還有不少。