第二次做業——我的項目實戰

第二次做業——我的項目實戰

本次做業deadline：2017-9-10 23:00PM

0、前言

閱讀了你們對於本課程的目標和規劃以後，想必不少同窗都躍躍欲試，火燒眉毛想要提升自身實踐能力，那麼就從第一個我的項目開始吧，題目要求見下。

一、閱讀

閱讀《構建之法》第一章至第三章的內容，並在下方做業裏體現出閱讀後的成果。特別是第2章中的效能分析及我的軟件開發流程（PSP）。

二、題目描述

背景

數獨介紹：（摘自百度百科）

數獨是源自18世紀瑞士的一種數學遊戲。是一種運用紙、筆進行演算的邏輯遊戲。玩家須要根據9×9盤面上的已知數字，推理出全部剩餘空格的數字，並知足每一行、每一列、每個粗線宮（3*3）內的數字均含1-9，不重複。

數獨盤面是個九宮，每一宮又分爲九個小格。在這八十一格中給出必定的已知數字和解題條件，利用邏輯和推理，在其餘的空格上填入1-9的數字。使1-9每一個數字在每一行、每一列和每一宮中都只出現一次，因此又稱「九宮格」。

---

工具清單

• 編程語言： C/C++/C#
• 編程IDE：推薦使用Visual Studio 2015/2017 社區版，下載也推薦使用國內一些鏡像站點（不是盜版）MSDN,I tell you。
• 效能分析工具：推薦使用 Visual Studio Profiling Tools
• 源代碼管理平臺：Github

---

項目需求

利用程序隨機構造出N個已解答的數獨棋盤 。

輸入

數獨棋盤題目個數N

輸出

隨機生成N個 不重複 的 已解答完畢的 數獨棋盤，並輸出到sudoku.txt中，輸出格式見下輸出示例。

輸入示例

3

輸出示例（輸出文件示例https://files.cnblogs.com/files/easteast/%E7%A4%BA%E4%BE%8B%E8%BE%93%E5%87%BA.rar）

2 6 8 4 7 3 9 5 1
3 4 1 9 6 5 2 7 8
7 9 5 8 1 2 3 6 4
5 7 4 6 2 1 8 3 9
1 3 9 5 4 8 6 2 7
8 2 6 3 9 7 4 1 5
9 1 7 2 8 6 5 4 3
6 8 3 1 5 4 7 9 2
4 5 2 7 3 9 1 8 6

4 5 1 7 8 2 3 6 9
7 8 6 4 9 3 5 2 1
3 9 2 1 5 6 4 8 7
5 2 7 6 4 9 8 1 3
9 6 8 5 3 1 2 7 4
1 3 4 2 7 8 6 9 5
8 1 5 3 6 7 9 4 2
6 7 3 9 2 4 1 5 8
2 4 9 8 1 5 7 3 6

9 5 8 3 6 7 1 2 4
2 3 7 4 5 1 9 6 8
1 4 6 9 2 8 3 5 7
6 1 2 8 7 4 5 9 3
5 7 3 6 1 9 4 8 2
4 8 9 2 3 5 6 7 1
7 2 4 5 9 3 8 1 6
8 9 1 7 4 6 2 3 5
3 6 5 1 8 2 7 4 9

---

測試須知

測試機爲 Windows環境 ，因此提交到Github上的項目均須要創建一個名字爲BIN的文件夾，裏面必須含有可執行文件（以exe爲後綴）與相關的依賴庫，請注意如下兩點：

• 確保可執行文件的名字命名爲 sudoku.exe。
• 確保生成的棋盤文件 sudoku.txt 與可執行文件在同一目錄下，生成文件時請使用 相對路徑 ！

一個示例組織目錄以下所示：

/ SudokuProject(工程名字自行指定便可)
     / main.cpp
     / generator.cpp
/ BIN
     / Lib.dll (exe運行須要的動態連接庫文件，能夠沒有)
     / sudoku.exe
     / sudoku.txt (運行exe後生成的文件)

助教在測試時，將以命令行運行可執行文件的方式進行批量測試，參數及其約定以下：

參數名字	參數意義	用法示例
-c	生成的數獨棋盤的數量	sudoku.exe -c 20

值得一提的是，測試數據中有可能出現錯誤，好比出現 sudoku.exe -c abc 這樣的命令，你的程序須要自行處理錯誤狀況，並給出合適的錯誤提示信息。

---

附加題（選作）

1）如今已經有了一個數獨遊戲的生成器，若是想讓你們都能實際使用它，還須要一個簡單的遊戲界面。爲數獨遊戲的生成器作一個 GUI 界面，並附上一個簡單的使用說明。界面需實現下述功能，會按點給分：

• 生成任意數量的數獨題目並將初始數獨棋局依次顯示。初始數獨棋盤須要挖空，要求爲：99棋盤上挖空很多於30個，很少於60個。每一個33的小棋盤中挖空很多於2個。好比下面這就是一個規範的棋局（5'）

• 用戶能夠在界面上經過點擊或輸入完成數獨題目（3'）
• 用戶完成數獨題目後能夠獲得反饋，知道本身的題目是否作對（2'）

【注意】選擇完成本附加題目的同窗，須要將GUI與數獨遊戲生成器做爲兩個工程開發，後者能夠做爲依賴庫爲前者提供調用接口，但 不能夠把兩個工程直接混在一塊兒 。 GUI相關的部分也須要提供新的可執行文件，放在根目錄的GUIBIN文件夾下。

2）程序的基礎要求是完成一個數獨題目生成程序，但數獨棋局中是要求有獨解性的。因此數獨比賽中爲了保障解題的趣味性與難度，通常會手工構造有惟一解的數獨程序。這種數獨題目的要求以下：

• 在9*9的棋盤中，初始棋盤最少有30個空
• 該數獨題目有且僅有惟一解

如今請你在以前程序的基礎上改進一下，完成上述需求。(10')

【注意】選擇完成本附加題目的同窗，須要將改進版與原版做爲兩個工程開發，後者能夠做爲依賴庫爲前者提供調用接口，但 不能夠把兩個工程直接混在一塊兒 。 改進版相關的部分須要提供新的可執行文件，放在根目錄的GAMEBIN文件夾下。這部分程序的正確性與性能測試獨立於基礎測試，按經過的測試點給分。

輸入

數獨棋盤題目個數N

輸出

隨機生成N個 不重複 的 有惟一解 的數獨棋盤。挖空處用數字0表示，每一個數獨棋盤中至少要有 30 個以上的0。輸出格式見下輸出示例，輸出須要到文件sudoku.txt中。

2 0 0 0 0 0 9 0 1
3 4 0 0 6 0 0 0 0
0 0 0 0 0 0 0 0 0
0 0 0 0 2 0 0 3 0
0 0 9 5 0 8 0 0 7
0 0 6 0 0 0 0 0 0
0 0 0 0 0 0 5 4 0
0 0 0 1 0 0 0 0 0
0 0 0 7 0 9 0 0 0

4 0 0 0 0 0 0 0 0
7 0 6 0 9 0 5 0 0
0 0 0 1 0 0 0 0 0
0 2 0 0 0 0 0 1 3
0 0 0 0 0 0 0 0 0
0 0 0 0 7 8 0 0 0
8 1 0 3 0 0 0 0 0
0 0 0 0 0 0 0 5 0
0 0 0 0 0 0 7 0 6

0 0 0 0 0 7 0 2 0
0 0 0 0 0 0 0 0 0
1 4 6 0 0 0 0 0 0
0 0 0 0 0 0 5 0 0
0 7 3 0 0 9 0 0 0
0 0 0 0 0 0 6 0 1
0 2 0 5 0 0 0 0 0
0 9 0 0 0 0 0 3 0
0 0 0 1 8 0 0 0 0

三、要求與說明

• 分析並理解題目要求，獨立完成整個項目。
• 使用單元測試對項目進行測試，並使用插件查看測試分支覆蓋率等指標。
• 完成項目的首個版本以後，使用 性能分析工具 找出代碼中的性能瓶頸並進行改進。
• 【項目要求】在項目實踐過程當中使用Github管理源代碼，將遵循上述 測試須知 中規範的最新的項目代碼發佈到Github上。

• 【博客要求】按照要求發佈博客，利用在構建之法中學習到的相關內容，結合我的項目的實踐經歷，撰寫解決項目的心路歷程與收穫。

• 結合上次做業的評分總結，在博客中談談你關於 執行力 、 泛泛而談 的理解，好與很差都必須列舉實際例子、數據或推理加以說明。

四、博文規範

將博文發佈到我的博客上，且需包含如下8個內容。

1）在文章開頭給出 Github項目地址 。（1‘）

2）在開始實現程序以前，在下述PSP表格記錄下你 估計 將在程序的各個模塊的開發上 耗費的時間 。（0.5‘）

3）解題思路 描述。即剛開始拿到題目後，如何思考，如何找資料的心路歷程。（3‘）

4）設計實現 過程。設計包括代碼如何組織，好比會有幾個類，幾個函數，他們之間關係如何，關鍵函數是否須要畫出流程圖？（4‘）

5）代碼說明 。展現出項目關鍵代碼，並解釋思路與註釋說明。（5‘）

6）測試運行 。程序必須是可運行的，展現出程序運行的截圖。PS：若是有擴展需求或者更高級的需求，請秀出來，有額外加分。（3‘）

7）記錄在改進程序 性能上所花費的時間 ，描述你 改進的思路 ，並展現一張 性能分析圖 ，並展現你程序中消耗最大的函數。PS：若是採用Visual Studio Community 2015開發，使用C++或者C#語言實現，VS 2015的性能分析工具可自動生成。（3‘）

8）在你實現完程序以後，在下述PSP表格記錄下你在程序的各個模塊上 實際花費的時間 。（0.5‘）

附：PSP 2.1表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
· Estimate	· 估計這個任務須要多少時間
Development	開發
· Analysis	· 需求分析 (包括學習新技術)
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審 (和同事審覈設計文檔)
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)
· Design	· 具體設計
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	· 測試（自我測試，修改代碼，提交修改）
Reporting	報告
· Test Report	· 測試報告
· Size Measurement	· 計算工做量
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃
合計

附：博客參考模板

http://www.cnblogs.com/vertextao/p/7469789.html

五、評分規則

本次我的項目分數由三部分組成，分別是

• （1）博客 —— 40分
  • 20分組成在 博文規範 中
  • 其他20分組成
    • 執行力 、 泛泛而談 的理解 —— 5分
    • 遇到的困難及解決方法 —— 5分
    • 關鍵代碼or設計說明 —— 5分
    • PSP + 學習進度條更新 —— 5分
• （2）程序 —— 40分
  • 5分爲源代碼管理評分，該評分主要經過源代碼管理中的commit註釋信息，增量修改的內容，是否有運行說明等給分。
  • 25分爲正確性評分，正確性測試中輸入範圍限制在 1-1000，要求程序在 60 s 內給出結果，超時則認定運行結果無效。
  • 10分爲性能評分，性能測試中輸入範圍限制在 10000-1000000，沒有時間的最小要求限制。
  • 當程序的正確性評分大於20分時才能夠參與性能評分環節，因此請各位同窗務必保證本身程序的正確性。
  • 性能評分將採起檔級評分制度，助教將根據同窗們的程序跑同一數據耗費的時間長度將程序分爲若干檔，每一檔的同窗獲得的分數爲 10/檔級數。
• （3）【可選】附加題 —— 20分，分數組成已在 附加題 中寫到，附加題不參與總分映射。
• （4）注意事項：
  • 按時間完成並提交 —— 正常評分
  • 晚交一週之內 —— 0分
  • 晚交一週以上或不交 —— 倒扣本次做業分數
  • 抄襲 —— 倒扣 2倍本次做業分數 【 嚴禁代碼與博客等一切形式的抄襲！ 】
• 【說明】
  • 本次做業先按百分制評分（含附加題）
  • 必作部分最後映射分數至 [1, 10] 分
  • 附加題單獨映射到 [0, 2] 分

六、疑惑解疑

如有對題意不清或者有不理解的地方，可在該博客下方留言，或者在微信羣中直接提問。

七、參考

• VS2015安裝與C++單元測試
• 基於C#的單元測試(VS2015)
• VS2015性能分析