項目 | 內容 |
---|---|
做業屬於哪一個課程 | 北航軟件工程 |
做業要求 | 做業要求 |
課程目標 | 鍛鍊合做能力,編程能力 |
這個做業如何幫助我實現目標 | 和partner合做完成做業 |
項目地址git
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) |
---|---|---|
Planning | 計劃 | |
·Estimate | ·估計這個任務須要多長時間 | 45 |
Development | 開發 | |
·Analysis | ·需求分析(包括學習新技術) | 240 |
·Design Sepc | ·生成設計文檔 | 60 |
·Design Review | ·設計複審 | 30 |
·Coding Standard | ·代碼規範(爲目前的開發制定合適的規範) | 40 |
·Design | ·具體設計 | 180 |
·Coding | ·具體編碼 | 720 |
·Coding Review | ·代碼複審 | 180 |
·Test | ·測試 | 120 |
Reporting | 報告 | |
·Test Report | ·測試報告 | 60 |
·Size Measurement | ·計算工做量 | 30 |
·Postmortem & Process Improvement Plan | ·過後總結,並提出過程改進計劃 | 60 |
合計 | 1765 |
· wiki中對information hiding的解釋爲:github
In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed算法
·對於Interface Design的解釋爲:編程
Interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goals (user-centered design).編程語言
·對於Loose Coupling的解釋爲:函數
A loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services.性能
· 由此不難看出,這三個方法是不相同的,因爲在以前的學習過程當中,沒有對接口進行過詳細的設計和實現,所以這部分對咱們來講比較困難。良好的接口是須要高內聚,低耦合的,這個強調了封裝的原則:獨立、低耦合。咱們在設計過程當中,將不一樣函數進行了封裝,使用了少許的全局變量,保證了高聚合的特性。按照題目要求,主要分紅兩個模塊,最長單詞量和最多單詞數量的模塊。可是生成的dll因爲時間關係,並無和其餘人進行交換測試。單元測試
設計過程以下:
學習
· 算法大體思路:最長單詞鏈的根本即爲,有限連通圖(無環)中的最長路徑。獲得的單詞鏈,須要知足前一個單詞的尾等於後一個單詞的頭,所以使用拓撲排序算法,能夠獲得一個序列。這個序列的特色是,越在後面序列的單詞,其組成的單詞鏈越長。在此就不贅述,代碼中有所體現。所以序列最後的單詞,一定是最長單詞鏈中的最後一個單詞,依次找到它的前驅便可。而最多單詞鏈,便是在拓撲排序的基礎上加上動態規劃的思想,比較相鄰的兩條鏈長度,取較長的一條,和下一條繼續比較。
· 獨到之處:以前有使用過DFS算法實現-w和-c的功能,結果是若是測試數據較大的時候,運行時間超過300s,明顯不符合要求。在進行深刻學習後,採用了拓撲排序的方法,運行速度大大提升,而且準確率也有所提高。測試
· UML圖以下:
因爲Core的UML生成失敗,這裏僅展現主要算法的UML圖:
· 性能圖以下(這裏貼出佔用cpu最多的一部分):
· 因爲須要從文件中讀取單詞,而且判斷單詞之間的分隔,大寫單詞轉化成小寫等,所以迭代層數較多,函數調用次數也多,cpu佔用率更多。在優化了最長單詞鏈的算法後,只須要進行一次拓撲排序就能夠找出最長鏈,而-t和-h要求並不會再次執行計算函數,只是加上了限制條件,所以反而cpu佔用率不高。
· 優勢:因爲在動手寫代碼前,對方法的參數、前提條件、後續狀態進行設計,所以保證了代碼的效率和質量
· 缺點:在以前的面向對象課中,老師有讓使用過這種方法。可是須要驗證設計的正確性,而且對語言格式有必定的要求,在此基礎上可能會浪費時間,同時一些編程語言可能不兼容。
· 在設計接口時,對接口的前提條件進行了設計和約束,保證了函數在調用過程當中的獨立性。
· 因爲在實現過程當中,出現了比預期更多的問題,花費了大量時間,單元測試未良好完成。
異常1 同時有-w -c參數
· 即命令行輸入
Wordlist -w -c absolute_path_of_word_list
· 處理方法:此時程序會中斷,而且在控制檯輸出中報錯
異常2 單詞中含有非法字符
char *test[] = {"eng_neer", "sof2ware", "up2you"};
try{
int len = 3;
char ** results;
int re;
re = gen_chain_word(test, len, results, 0, 0, false);
}
· 處理方法:原本在預想上是想容錯,而後將單詞分隔開,可是因爲傳入的參數規定了長度,所以只能中斷,拋出異常
· 命令行部分的代碼以下:
· 其中top表明 -t需求中的字母,hop表明-h需求中的字母,cpath爲絕對路徑
· 在一開始實現代碼基本功能的時候,並無使用命令行輸入,而是使用了控制檯輸入輸出,這樣的好處是,在模塊設計和debug過程當中,特別的直觀方便。缺點卻在於,在實現了全部功能後,再進行命令行模塊的實現,須要改動大量的代碼,在此基礎上,有可能會產生一些錯誤,致使算法失效。最後在對接的過程當中,確實出現了問題,花費了不少時間。
· 最後的對接方式,採用了函數調用來對接,以下圖:
· 經過一個judge函數引導,來調用不一樣的計算模塊解決了直接調用Core中的計算模塊不兼容的問題。
· 結對的過程有些坎坷,一開始因爲partner的課程比較重,因此前期的最長鏈工做基本由我獨立完成,他幫助我測試,並找出程序問題。可是在他有了空餘時間後,咱們交換了身份,他來對最多單詞數量進行主要的把控,我來進行測試。通過角色的互換,有了不一樣角度去看待程序中出現的問題,所以咱們發現了不少細節上的錯誤,而且逐漸適應了對方的風格,互相學習,共同進步。我認爲整體過程是比較成功的,這也讓咱們學會了在團隊做業中,如何互相適應,磨合在一塊兒,取得更好的效果。
· 結對編程優勢:1. 角色互換、減輕壓力;2. 從不一樣角度看待問題更加全面;3. 學會合做、互相學習進步
· 結對編程缺點:1. 交換身份須要理解對方目前階段的思路,花費時間;2. 若是是不熟悉的兩人,磨合時間長,效率低
· partner優勢: 1. 作事效率高; 2. 夠肝(真佩服), 有毅力; 3. 按時完成工做
· partner缺點: 代碼不夠整潔。。
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | ||
·Estimate | ·估計這個任務須要多長時間 | 45 | 60 |
Development | 開發 | ||
·Analysis | ·需求分析(包括學習新技術) | 240 | 120 |
·Design Sepc | ·生成設計文檔 | 60 | 30 |
·Design Review | ·設計複審 | 30 | 10 |
·Coding Standard | ·代碼規範(爲目前的開發制定合適的規範) | 40 | 20 |
·Design | ·具體設計 | 180 | 480 |
·Coding | ·具體編碼 | 720 | 720 |
·Coding Review | ·代碼複審 | 180 | 300 |
·Test | ·測試 | 120 | 720 |
Reporting | 報告 | ||
·Test Report | ·測試報告 | 60 | 45 |
·Size Measurement | ·計算工做量 | 30 | 10 |
·Postmortem & Process Improvement Plan | ·過後總結,並提出過程改進計劃 | 60 | 20 |
合計 | 1765 | 2535 |