結對項目-數獨程序擴展

時間 2019-11-30

標籤項目數獨程序擴展简体版

原文原文鏈接

GitHub地址：
Step1~3: https://github.com/Aria-K-Alethia/SE-Sudoku-Pair
Step4: https://github.com/Aria-K-Alethia/SE-Sudoku-Pair/tree/dev-combine
Step5: https://github.com/Aria-K-Alethia/SE-Sudoku-Pair/tree/dev-product （用戶體驗測試請使用此版本）
git

接口設計說明

咱們將求解與生成的功能封裝爲dll文件，只給出頭文件供用戶參考，而不提供具體實現細節。這樣的封裝有效避免了用戶誤操做致使的功能性問題，減輕用戶負擔。github

計算模塊接口的設計與實現過程

咱們主要的算法邏輯都集中在Sudoku這個類當中。算法

數獨求解的部分咱們使用回溯的思想進行解決。回溯方法traceBackSolve()對第i行第j列元素及其後方（先向右，到最右則折返換行）空格進行求解，每次求解嘗試從1到9，檢測1到9每一個數字是否適合在此格子中填入（行、列、宮不重複），並在嘗試中遞歸調用traceBackSolve()方法，從而驗證每次嘗試的正確性。求解數獨的接口solve()方法負責調用traceBackSolve()方法進行求解，並作一二維數組的轉換。編程
在生成數獨接口generate(int number, int lower, int upper, bool unique, int result[][])中，咱們採用先生成終盤，再從終盤中挖空的形式進行數獨生成。首先調用generateCompleteN()這個已經實現的生成終盤方法，獲得number個終盤，再使用digHoles()方法進行挖空。挖空策略一共有兩種，一種爲從頭數獨第一個數開始，一種爲隨機選擇。隨機挖空因爲速度較快，但容易出現挖出來的盤有多解的狀況，咱們只在unique爲假的狀況下使用它。unique爲真時，採用順序挖空的策略，以從左到右，從上到下的順序進行挖空，每次挖空以後，將原始數字用1到9中其餘數字進行替換，並調用solve()對數獨進行求解，若能解出，則證實此空不能挖，不然可挖，繼續向後挖空。數組
第二個生成數獨接口二generate(int number, int mode, int result[][LEN*LEN])中，咱們利用了第一個generate()方法，根據mode獲得相應的up和down傳入generate()，即可獲得結果。框架

UML圖

計算模塊接口部分的性能改進

參數-c

下圖展現了生成1000000個完整數獨的性能分析
函數

因爲此次繼承了我上次的代碼，因此代碼自己已經被優化過。
5.272秒，幾乎全部的時間都花費在回溯遞歸上，速度已經能夠接受。
一個可能的優化是在判斷重複的時候使用位操做。佈局

參數-s

下圖展現瞭解1000個數獨時候的性能分析：
性能

首先注意到checksolve花費較長時間，這個函數原來使用了3×9的時間來判斷，注意到這個方法的下界是1×9，遂更改了實現方式：單元測試

int row, col;
    row = getBlock(i);
    col = getBlock(j);
    for (int a = 1; a <= LEN; ++a) {
        if ((board[i][a] == k + '0') || (board[a][j] == k + '0') 
                || (board[row + ((a - 1) / 3)][col + ((a - 1) % 3)] == k + '0'))
            return false;
    }

不過，這是常數級別的優化，因此效果不好，改進以後再次性能分析發現效果微弱。
一個可能的改進是使用bitmap來優化。

參數-n

直接在-u模式下測試，因爲當r的參數的值變大的時候生成10000個解的時間幾乎不可接受，因此選擇較低的數值，下圖是指令-n 10000 -r 25~55的效能分析：

24秒
熱路徑主要集中於solve函數，判斷緣由仍是因爲遞歸時形成的指數級增加的函數調用，在不更改現有結構的狀況下已經很難改進。

改進效能花費了30分鐘。

契約式編程的優缺點

優勢：
使用者和被調用者地位平等，雙方必須彼此履行義務，才能夠行駛權利。調用者必須提供正確的參數，被調用者必須保證正確的結果和調用者要求的不變性。雙方都有必須履行的義務，也有使用的權利，這樣就保證了雙方代碼的質量，提升了軟件工程的效率和質量。
缺點：
對於程序語言有必定的要求，契約式編程須要一種機制來驗證契約的成立與否；契約式編程並未被標準化，所以項目之間的定義和修改各不同，給代碼形成很大混亂。

計算模塊部分單元測試展現

solve()方法

測試思路：給出一個題目，和答案對比。

ret = sudoku.solve(puzzle, temp);
Assert::AreEqual(ret, true);
for (int i = 0; i < 81; ++i) {
    Assert::AreEqual(temp[i], solution[i]);
}

generate()方法

測試思路：對-r指令，首先在生成以後用solve函數測試是否可解，而後計算遊戲中的空的個數，判斷是否知足要求；對-u指令，在-r的基礎之上用回溯法求出解的個數，若是個數大於1，則出錯，測試-m的時候也是相似的方式。
下面是測試-n 10 -r lower~upper -u 的部分代碼：

sudoku.generate(10, lower, upper, true, result);
for (int i = 0; i < number; ++i) {
    Assert::AreEqual(sudoku.solve(result[i], solution), true);
    int solutionNumber = sudoku.countSolutionNumber(result[i], 2);
    Assert::AreEqual(solutionNumber, 1);
    int count = 0;
    for (int j = 0; j < 81; ++j) {
        if (result[i][j] == 0) count++;
    }
    Assert::AreEqual(count <= upper && count >= lower, true);
}

測試異常

測試思路：設置一個bool型變量exceptionThrown（初始值爲false）以及異常的條件，只要catch到異常，就將exceptionThrown設置爲true，而後進行斷言。
下面是測試SudokuCountException的代碼：

bool exceptionThrown = false;
try { // Test first SudokuCountException
    sudoku.generate(-1, 1, result);
}
catch (SudokuCountException& e) {
    exceptionThrown = true;
    e.what();
}
Assert::IsTrue(exceptionThrown);

這裏generate方法生成的數獨個數不能是負數，因此會拋出異常。

測試輸入參數的分析

測試思路：用strcpy_s初始化argv，設置argc，而後進行調用相關方法進行分析和斷言。
下面是測試指令-n 1000 -m 2的代碼：

InputHandler* input;
strcpy_s(argv[3], length, "-n");
strcpy_s(argv[4], length, "1000");
strcpy_s(argv[1], length, "-m");
strcpy_s(argv[2], length, "2");
argc = 5;
input = new InputHandler(argc, argv);
input->analyze();
Assert::AreEqual(input->getMode(), 'n');
Assert::AreEqual(input->getNumber(), 1000);
Assert::AreEqual(input->getHardness(), 2);
delete input;

這裏打亂了參數的順序，其餘參數的組合也是用相似的方法來測試的。

參數解析魯棒性測試

咱們的program中，參數錯誤的狀況下會直接報錯而後退出，同時輸入分析在完成以後通常不會改變，因此咱們直接在控制檯中進行了測試，主要看是否有相應的輸出，錯誤種類參看下圖：

Error Code	異常說明	錯誤提示
1	參數數量不正確	bad number of parameters.
2	參數模式錯誤	bad instruction.expect -c or -s or -n
3	-c指令的數字範圍錯誤	bad number of instruction -c
4	-s指令找不到文件	bad file name
5	-s指令的puzzle.txt中的數獨格式錯誤	bad file format
6	-s指令的puzzle.txt中的數獨不可解	bad file can not solve the sudoku
9	-r指令後的數字範圍有錯誤	the range of -r must in [20,55]
10	-m指令後的模式有錯誤	the range of -m must be 1,2 or 3
11	11 -m指令與-u或-r指令同時出現	-u or -r can not be used with -m
12	c指令的參數範圍錯誤	the number of -c must in [1,1000000]
13	-n指令的參數範圍錯誤	the number of -n must in [1,10000]
14	-n指令的參數類型錯誤	the parameter of -n must be a integer
18	-n不能單獨使用	parameter -n cann't be used without other parameters

其中code不連續是由於有的code替換成了exception。

一些測試情景能夠參考下圖：

單元測試覆蓋率分析

總的覆蓋率約爲94%
沒有測到的代碼主要是Output相關的代碼，已經在7.5節進行了說明。

異常處理說明

SudokuCountException：處理兩個generate()方法的參數number超出1~10000範圍的異常
單元測試：

int result[1][81];
bool exceptionThrown = false;
try { // Test first SudokuCountException
    sudoku.generate(-1, 1, result);
}
catch (SudokuCountException& e) {
    exceptionThrown = true;
    e.what();
}
Assert::IsTrue(exceptionThrown);

LowerUpperException：處理generate()方法參數lower與upper不合法狀況：lower > upper；lower < 20；upper > 55
單元測試：

//test LowerUpperException,case 1
        exceptionThrown = false;
        try {
            sudoku.generate(1, 1, 50, true, result);
        }
        catch (LowerUpperException& e) {
            exceptionThrown = true;
            e.what();
        }
        Assert::IsTrue(exceptionThrown);
        //test LowerUpperException,case 2
        exceptionThrown = false;
        try {
            sudoku.generate(1, 20, 56, true, result);
        }
        catch (LowerUpperException& e) {
            exceptionThrown = true;
            e.what();
        }
        Assert::IsTrue(exceptionThrown);
        //test LowerUpperException,case 3
        exceptionThrown = false;
        try {
            sudoku.generate(1, 50, 1, true, result);
        }
        catch (LowerUpperException& e) {
            exceptionThrown = true;
            e.what();
        }
        Assert::IsTrue(exceptionThrown);

ModeRangeException：處理generate()方法模式參數超過[1,3]區間範圍
單元測試：

//test ModeRangeException
exceptionThrown = false;

try {
    sudoku.generate(1, -1, result);
}
catch (ModeRangeException& e) {
    exceptionThrown = true;
    e.what();
}
Assert::IsTrue(exceptionThrown);

界面詳細設計

風格：

界面風格採用QSS文件統一修改。QSS代碼改自csdn博客做者一去、二三裏的黑色炫酷風格。
基本風格見下圖
Hint按鈕風格：

QPushButton#blueButton {
        color: white;
}
QPushButton#blueButton:enabled {
        background: rgb(0, 165, 235);
        color: white;
}
QPushButton#blueButton:!enabled {
        background: gray;
        color: rgb(200, 200, 200);
}
QPushButton#blueButton:enabled:hover {
        background: rgb(0, 180, 255);
}
QPushButton#blueButton:enabled:pressed {
        background: rgb(0, 140, 215);
}

數獨棋盤單元格風格（普通格、角落格、宮邊緣格）：

QPushButton#puzzleButton {
    border-width: 1px;
    border-style: solid;
    border-radius: 0;
}
QPushButton#puzzleButtonTLCorner {
        border-radius: 0;
    border-top-left-radius: 4px;
    border-width: 1px;
        border-style: solid;
}
QPushButton#puzzleButtonTRCorner {
    border-radius: 0;
    border-top-right-radius: 4px;
        border-width: 1px;
        border-style: solid;
}
QPushButton#puzzleButtonBLCorner {
    border-radius: 0;
    border-bottom-left-radius: 4px;
        border-width: 1px;
        border-style: solid;
}
QPushButton#puzzleButtonBRCorner {
    border-radius: 0;
    border-bottom-right-radius: 4px;
        border-width: 1px;
        border-style: solid;
}
QPushButton#puzzleButtonRE {
    border-radius: 0;
    border-width: 1px;
    border-right-width: 3px;
        border-style: solid;
}
QPushButton#puzzleButtonBE {
    border-radius: 0;
        border-width: 1px;
    border-bottom-width: 3px;
        border-style: solid;
}
QPushButton#puzzleButtonBRE {
    border-radius: 0;
        border-width: 1px;
        border-right-width:3px;
    border-bottom-width: 3px;
    border-style: solid;
}

小結：界面風格不是咱們在設計UI時最先考慮的部分，原本打算風格只進行簡單修改，只用setStyleSheet()方法來設計界面風格。不事後來發現自帶的界面實在太醜，因而決定借鑑已有的風格，針對項目要求進行調整，最終效果還算不錯。

佈局

佈局設計採用純代碼的設計，使用Layout進行對齊。
歡迎、幫助與選擇難度界面統一使用QVBoxLayout對控件進行對齊
效果見下圖
遊戲界面採用Layout嵌套Layout的形式進行佈局管理。咱們先設計了一個mainLayout做爲最外層Layout,將其餘Layout豎直放入mainLayout。
其餘Layout見下圖
爲保持數獨棋盤排列的緊密，在棋盤周圍加了spacer把棋盤上的格子擠壓到一塊兒，且能保持形狀。
爲保證比例的美觀，遊戲窗體被強制固定，沒法進行縮小與放大。

小結： 設計佈局過程有些小曲折，一開始因爲沒有經驗，不知道該如何用代碼該出想要的佈局效果，也想過不使用代碼修改佈局，直接在界面上拖拽。但考慮到代碼的靈活性，仍是決定使用代碼，放棄了拖拽設計（下次有機會作UI，但願嘗試下拖拽設計和代碼設計結合的形式）。好在有博客和Qt官方文檔的支持，仍是成功學會了Qt的佈局設計，作出了當前這個效果。

界面模塊與計算模塊的對接

generate()方法

主要在開始新遊戲的時候使用，首先用generate中生成數獨遊戲，而後再轉換成QString顯示在界面的button上，部分代碼以下：

int result[10][LEN*LEN];
    sudoku->generate(10, degOfDifficulty, result);
    QString temp;
    QString vac("");
    for (int i = 0; i < LEN; ++i) {
        for (int j = 0; j < LEN; ++j) {
            if (result[target][i*LEN + j] == 0) {
                tableClickable[i][j] = true;
                puzzleButtons[i][j]->setText(vac);
                puzzleButtons[i][j]->setEnabled(true);
                puzzleButtons[i][j]->setCheckable(true); // Able to be checked
            }
            else {
                tableClickable[i][j] = false;
                puzzleButtons[i][j]->setText(temp.setNum(result[target][i*LEN + j]));
                puzzleButtons[i][j]->setEnabled(false); // Unable to be editted
            }
        }
    }

對於已經有數字的位置，則設置按鈕不可用，一個樣例的盤面以下：

solve()方法

主要用在提示功能上，首先判斷是否可解，若是可解則在相應的位置上給出提示，不可解則給出相應的提示，部分代碼以下：

if (sudoku->solve(board, solution)) {
        puzzleButtons[currentX][currentY]->setText(QString::number(solution[currentX*LEN + currentY]));
        puzzleButtons[currentX][currentY]->setChecked(false); // Set button unchecked
        checkGame();
    } else {
        QMessageBox::information(this, tr("Bad Sudoku"), tr("Can not give a hint.The current Sudoku\
 is not valid\nPlease check the row,rolumn or 3x3 block to correct it."));
    }

描述結對的過程

咱們結對的過程整體來講算是不錯的，成功完成了基本功能要求與附加的Step四、Step5。咱們的大部分工做在國慶期間完成，那段時間嚴格遵照結對編程規範，一人敲代碼，另外一人在一旁幫助審覈代碼與提供思路，每一小時進行工做交換，每次交換都把代碼push到Github上，記錄這一步工做的結果。咱們用了三天時間實現了邏輯部分的完善與測試，並搭建起了UI的三個頁面框架，整體效率還算不錯。期間也遇到過找不着源頭的bug，費了咱們很多時間，不過好在是兩我的協力查資料、想辦法，最終仍是解決了問題。國慶事後因爲兩人的時間不太能湊得上，咱們便將工做分工，一人主攻功能，一人主攻界面，一步步推動項目並達到預期目標。
如下爲咱們二人結對編程時的照片。

結對編程的優缺點以及兩人各自優缺點

結對編程優缺點

優勢：
- 互相幫助，互相教對方，可能獲得能力上的互補。
- 實時複審，加強代碼質量，並有效的減小bug。
- 下降學習成本。一邊編程，一邊共享知識和經驗，有效地在實踐中進行學習。
- 共同討論，可能更快更有效地解決問題
缺點：
- 對於有不一樣習慣的編程人員，能夠在起工做會產生麻煩。
- 須要精力高度集中，容易產生疲勞。
- 不合適的溝通會致使團隊的不和諧，下降效率。
- 結對編程可能出現思惟趨同，致使有些bug久久找不出來。
- 若對工做領域十分熟悉，結對編程可能會下降效率。

隊員優缺點

15061119
- 優勢：
  1.極高的編碼效率
  2.專一於解決每一個問題
  3.充滿責任心與工做熱情
- 缺點：
  1.編碼風格不太統一
15061104
- 優勢：
  1.能理解支持partner
  2.能力較強
  3.解決了我一直苦惱的設計問題
- 缺點：
  1.某種程度上，欠缺一些積極性

跨組合做出現的問題

合做小組學號：
15061111
15061129

問題1：dll生成的環境不一樣

問題描述
咱們組的dll在64位下生成，而合做小組的是在32位下生成的，這樣致使模塊不可調用。
解決方案
從新生成了64位的dll，問題解決。

問題2：接口名不一樣

問題描述
咱們合做小組的接口爲：

SODUCORE_API void generate_m(int number, int mode, int **result);
SODUCORE_API void generate_r(int number, int lower, int upper, bool unique, int **result);
SODUCORE_API bool solve_s(int *puzzle, int *solution);

而咱們本身的接口爲：

void generate(int number, int lower, int upper, bool unique, int result[][LEN*LEN]);
void generate(int number, int mode, int result[][LEN*LEN]);
bool solve(int puzzle[], int solution[]);

這就致使改變計算模塊以後須要更名字。

解決方案
把相應接口的名稱更換便可

問題3：參數規格不一樣

問題描述
注意到在13.2.2的雙方的接口中，咱們組定義result位二維數組，而合做小組定義爲二維指針，這就致使參數錯誤。
解決方案
將result轉換位二維指針便可。

軟件發佈階段

用戶反饋
1. 發現一個排名系統的bug
2. 每次填入一個數字，想要當即修改得再次點擊空格
3. Readme未添加支持的平臺
解決方案
1. 已更新軟件，修復了bug
2. 將每次填入數字就彈起空格，改成用戶點其餘空格時彈起空格
3. Readme中添加平臺說明與運行說明

PSP表格

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

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。