結對編程做業

項目	內容
課程	軟件工程（羅傑）
做業要求	結對項目-單詞最長鏈
本次做業的目的	體驗結對編程
本次做業對個人鍛鍊	熟悉結對編程，瞭解結對編程的優勢和缺點
項目github地址	項目地址

項目地址

https://github.com/wlof-2/LongestWordChain/tree/wf_try

預估耗時PSP

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

接口設計方法

• Information Hiding（信息隱藏）

  信息隱藏指在設計和肯定模塊時，使得一個模塊內包含的特定信息（過程或數據），對於不須要這些信息的其餘模塊來講，是不可訪問的。信息隱藏在設計的全部層次上都有很大做用：從用具名常量代替字面常量，到建立數據類型，再到類的設計、子程序的設計以及子系統的設計等等。在咱們的設計中，咱們將程序主要分紅三部分，處理輸入部分，核心計算部分，輸出部分，這三部分除了接口以外，沒有變量上的其它關係。也就是三部分的變量是相互分開的，不會出現一個模塊改變另外一個模塊的變量的狀況。

• Interface Design（接口設計）

  接口設計的六大原則是，單一職責原則， 里氏替換原則， 依賴倒置原則，接口隔離原則，迪米特法則，開閉原則。由於咱們沒有出現類的繼承關係，因此沒有體現里氏替換原則，其它的原則均可以保證，例如接口隔離原則，接口的設計高內聚，能少就少，而後是嚴格按照爲了鏈接而使用接口的原則。不會出現多餘的接口。

• Loose Coupling（鬆散耦合）

  軟件設計中一般用耦合度和內聚度做爲衡量模塊獨立程度的標準。劃分摸塊的一個準則就是高內聚低耦合。 耦合度(Coupling)是對模塊間關聯程度的度量。咱們設計的模塊之間的接口與功能上體現出模塊的獨立性，因此耦合性較低。

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

void Get_num(char* word[], int len, bool Weight);
// 構造圖的模塊
void topologicalSort();
// 拓撲排序模塊
void longestPath(int start, char* word[], bool begin_end, bool Weight);
// 從點start找出最長鏈的模塊
void Every_Path(int chose, char* word[], char end_letter, char start_letter, bool Weight);
// 根據處理輸入的結果，以及接口實現找word list中的最長鏈

int getWord(char *words[], string path);
// 根據路徑path，從文件中讀出 *word[]
void paraAnalysis(int argc, char * argv[], char opt[][5], int & flag_wc, char & head, char & tail, bool & para_loop, string &filePath);
// 根據argc，agrv[], 處理參數，得出輸入參數的類型，
int gen_chain_word(char* words[], int lens, char* result[], char head, char tail, bool enable_loop);
// 處理單詞個數最長的單詞鏈
int gen_chain_char(char* words[], int lens, char* result[], char head, char tail, bool enable_loop);
// 處理字母個數最多的單詞鏈的長度

• 咱們接口主要體如今gen_chain_char 函數與 Every_Path 函數，gen_chain_char 函數將輸入處理完畢，而後傳入參數，表示計算的步驟須要進行哪些計算。這裏主要體現的接口參數是 word(表示單詞鏈)，head(單詞鏈的頭)，tail(單詞鏈的尾)，chose(從 gen_chain 到 Every_Path的選擇參數)。這是最主要的接口設計與實現過程。
• 在計算模塊的內部，咱們也使用了接口。在函數Every_Path 與 函數longestPath 之間，咱們爲了實現函數功能的單調性。因此我進一步在 Every_Path 中，將函數的功能細分。在 Every_Path 中主要是將函數細分，而longest_Path 只實現了從某一個起點開始找出最長鏈。這個設計使模塊內的函數功能更加單一，也提升了函數的複用性。
  ​

計算模塊UML建模

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

算法的考慮：計算的核心部分咱們採用的是拓撲排序加動態規劃的算法。比暴力搜索比起來下降了計算的複雜性。在拓撲排序階段，算法的採用的是類DFS的算法。在動態規劃階段，時間複雜度是O(n)。咱們沒進入下一個點就會存儲到這一點的最長路徑。在考慮有環的算法的時候，咱們想的是對於環，能夠將環切出來，也就是將環的入口鏈與出口鏈分出來，這樣的話在環內計算環的最長鏈，在環外面加上入口最長鏈與出口最長鏈便可。不幸的是，咱們並無實現，還不如直接和其它同窗同樣使用暴力搜索。花了一些時間實現，可是沒有成功。

性能分析

Design by Contract, Code Contract

契約式設計

契約式設計的主要目的是但願程序員可以在設計程序時明確地規定一個模塊單元（具體到面向對象，就是一個類的實例）在調用某個操做先後應當屬於何種狀態。在我看來Design by contract不是一種編程範型，它是一種設計風格，一種語法規範，甚至是個商標（是的，Bertrand Meyer註冊了這麼個商標）。

• 優勢：
  契約式設計每一方都期待從契約中得到利益，同時也要接受一些義務。一般，一方視爲義務的對另外一方來講是權利。契約文檔要清楚地寫明雙方的權利與義務。因此契約式設計在結對編程中發揮重要的做用。負責兩個模塊的人同時爲另外一我的負責，完成本身的任務的時候同時至關於行使本身的權力，可以藉助外力的方式使雙方的程序鏈接的更加緊密。使程序的耦合度更低。

• 缺點:
  不是全部的編程語言都支持契約式設計。

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

因爲用VS的單元測試出現了一些問題，一直都沒法運行測試程序。因此咱們就採用了運行測試的方法，構造好測試樣例後，不斷重複運行程序，與預期效果比對，從而達到測試效果，下面是部分測試的截圖和樣例：

命令行測試實例

• 例子一：
• 例子二：

計算模塊部分異常處理說明

• 我所作的是判斷是否有環，在不應出現環的狀況下不該該有環，這裏上面是無環的狀況，改爲有環的時候就會報錯。判斷是否有環，我採用的是在拓撲排序的時候，若是已經訪問的點不在棧中，而且又一次被訪問到，說明有環。
• 文本文件爲空，傳進去的單詞數組爲空，會報告異常錯誤，並結束程序。

命令行模塊設計過程

命令行模塊採用argc, char *argv[]兩個參數做爲命令行輸入的接受單元，其中argc代表輸入參數的個數（包括程序名），argv是一個字符型的指針數組，存儲具體輸入的參數。因爲這兩個本就是main函數的參數，因此咱們能夠在調試的時候，構造控制檯輸入。在咱們處理輸入的時候，這兩個參數十分獨立，因此調試完以後，在命令行直接分開就能夠執行了。

命令行模塊與計算模塊的對接

開始調試的時候，咱們先經過控制檯輸入argc 與 argv。也就是模擬了命令行執行的參數哦，因此直接在命令行運行時，運行的參數會直接傳到輸入處理模塊，而後傳到計算模塊。與計算模塊的對接就是經過處理輸入模塊來建立接口完成的。

結對編程過程

下課後在空教室內進行結對編程，我擔任代碼寫手。完成計算部分與鏈接接口。吳光輝爲領航員。

結對總結

​ 結對編程優勢不少，能夠大大減小bug。同時結對編程必須保證代碼的耦合度較低，這樣作測試就會簡單，並且能夠保證單元模塊的bug較少。結對編程還能夠互相學習，在編程的過程當中能夠互相發現問題。對整個項目有更好的理解。結對編程缺點我本身感受就是十分依賴結對雙方之間的溝通與交流。還有就是雙方的計劃於在實施以前的想法。咱們就是在實施以前交流的太少了，致使後面我寫的時候，他等着，他寫的時候，我等着，沒有利用好一塊兒寫的時候，相互發現bug，相互提問的優點。致使整個項目一拖再拖。

成員	優勢	缺點
吳光輝	認真；執行力強；總體意識好	討論的不夠及時
吳楓	善於思考；有耐心debug；善於溝通	不夠仔細

P表格

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