軟體工程實踐2017第二次作業

github連線：

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

輸入

數獨棋盤題目個數n（0< n <= 1000000）

輸出

隨機生成n個不重複的已解答完畢的數獨棋盤，並輸出到sudoku.txt中。

參考**：

(其實看了這個**以後，我深受影響，把自己的設想都推翻了，總覺得自己的方法不太好，想學習這個方法。我認真理解了這個方法以後，就用了，但是**寫出來就差不多了，我挺害怕被判抄襲的，我不知道學習了這個方法用起來，算不算抄襲(´･_･`))

生成隨機數：在生成隨機數的時候，最開始我不會使用隨機數，就去查資料：

rand()產生的隨機數在每次執行的時候都是與上一次相同的。若要不同,用函式srand()初始化它。可以利用srand((unsigned int)(time(null))的方法，產生不同的隨機數種子，因為每一次執行程式的時間是不同的。

因為是生成多個隨機數獨，所以我把構造數獨的函式放到迴圈裡去生成，結果發現每次產生的數獨都一樣，最開始以為是隨機數的隨機性沒有那麼強，可是這與資料裡說的用time初始化種子每次都不一樣相矛盾。我就去嘗試把隨機生成的不完整數獨輸出檢視，發現每次輸出的數獨並不一樣。以為自己構造方法錯了，可是我覺得這個方法不影響不同數獨的隨機性。

去查了資料發現：

應用在乙個for迴圈中，取到的多個隨機值就基本相同的原因如下：

用系統時間做隨機種子並不保險，如果應用程式在乙個較快的計算機上執行，則該計算機的系統時鐘可能沒有時間在此建構函式的呼叫之間進行更改，random 的不同例項的種子值

原來是srand（）不能放在for迴圈內，應該放到外面初始化種子才不會重複。中途還想要用guid生成隨機數，但是好像在c#中適用，c++用的很少，不太方便的樣子。

使用命令列編譯:由於我沒有windows系統的電腦，自己電腦裝雙系統，又裝vs的話系統很容易崩掉，慘痛教訓，所以我的ide是xcode。作業裡要求的用命令列進行編譯，我是借用別人的電腦進行嘗試和修改的，但是好像不太成功，-c可以編譯，但是好像無法識別後面的數，數目要輸入兩遍（t_t），查了很久資料也不知道怎麼解決。

檢查九宮格內數是否合法：利用bool函式判斷

bool shudu_check(int shudu[9],int x,int y)
//檢驗同一列數是否有重複
for(j=0;j<9;j++)
//檢驗小九宮格內數是否有重複
int x0=(x/3)*3;
int y0=(y/3)*3; //(x0,y0)是(x,y)所屬小九宮格內左上角第一格的座標
for (i = x0; i構造數獨：回溯法，基本思想就是深度優先搜尋（dfs），對不完整隨機數獨每個數進行檢查，數滿足條件就檢查下乙個數，不滿足條件就退回，並把數置0，重新賦予滿足條件的數。
void shudu_generate(int flag)
;    int x, y;
shudu[0][0]=4;
//生成隨機數賦值給九宮格
for(int i=0; i<9; i++)
//回溯法構造數獨
int t=1;
while(flag==1)
else if(shudu_check(shudu,x,y)==true)//合法，檢查下乙個數
}if(t==81)
{shudu_print(shudu);
cout
測試結果截圖
(由於種種原因我借用的windows電腦裡的vs軟體無法生成效能分析報告，好像是缺少乙個專案，但是我下了sp1，還是不行，所以我嘗試著用xcode，但是我好像不太會用)
其實我沒有搞懂效能分析報告，看得有點迷，也不知道該如何下手去修改**(>_
也沒有在網上找到一些教程，更多關於xcode效能測試的教程都是關於ios開發的
只是找到這篇 可能是自己知識儲備太少，我基本看不太懂這個效能分析該如何使用，所以我沒有去優化**，真的不知道怎麼改（t_t）但是我試著去看看執行比較大資料的時候cpu的情況，好像不太樂觀？？cpu佔比有點大是這個意思嗎？我覺得可能還是構造數獨函式消耗最大。
這是剛開始測試num＝1000的情況：
預估耗時
實際耗時
planning
計畫1.5h
3－4h
· estimate
· 估計這個任務需要多少時間
2days
3days
development
開發2h
3h· analysis
· 需求分析 (包括學習新技術)
3-4h
3-4h
· design spec
· 生成設計文件
1h2-3h
· design review
· 設計複審 (和同事審核設計文件)
30mins
1h· coding standard
· **規範 (為目前的開發制定合適的規範)
30mins
30mins
· design
· 具體設計
1h1h
· coding
· 具體編碼
2h3h
· code review
· **複審
30mins
1h· test
· 測試（自我測試，修改**，提交修改）
1h2h
reporting
報告1h
1.5h
· test report
· 測試報告
10mins
1h· size measurement
· 計算工作量－－
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫
1h1.5h
合計由於一些事情，完成作業的時間跨度蠻大的，所以沒有認真的計時，我只是寫了個大概的時間，沒有辦法具體合計出來，請見諒。

軟體工程實踐2017第二次作業

軟體工程實踐2017第二次作業

軟體工程實踐2017第二次作業

軟體工程實踐2017第二次作業

相關推薦