目錄git
項目 | 內容 |
---|---|
此次做業屬於哪一個課程 | 軟件工程 |
此次做業的要求在哪 | 結對編程做業 |
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | ||
.Estimate | 估計這個任務須要多少時間 20001970 | ||
Development | 開發 | ||
.Analysis | 需求分析 (包括學習新技術) | 240 | |
.Design Spec | 生成設計文檔 | 180 | |
.Design Review | 設計複審 (和同事審覈設計文檔) | 120 | |
.Coding Standard | 代碼規範 (爲目前的開發制定合適的規範) | 30 | |
.Design | 具體設計 | 200 | |
.Coding | 具體編碼 | 450 | |
.Code Review | 代碼複審 | 240 | |
. Test | 測試(自我測試,修改代碼,提交修改) | 240 | |
Reporting | 報告 | ||
.Test Report | 測試報告 | 180 | |
.Size Measurement | 計算工做量 | 30 | |
·Postmortem & Process Improvement Plan | 過後總結, 並提出過程改進計劃 | 60 | |
Sum | 合計 | 1970 |
Information Hiding, Interface Design, Loose Coupling,指的就是信息隱藏,接口設計,鬆散耦合這幾個方面。
Information Hiding的概念最初由David Parnas在Parnas(1972)中描述,在此以前,Richard Gauthier和Stephen Pont在其1970年出版的「 設計系統程序」一書中對模塊化進行了討論。Information Hiding, Interface Design做爲將任何設備,軟件或硬件劃分爲功能模塊的有效標準。例如,汽車是一種複雜的設備。爲了使汽車的設計,製造和維護合理,將複雜的設備分紅具備隱藏設計決策的特定接口的模塊。經過以這種方式設計汽車,汽車製造商還能夠提供各類選擇,同時仍然具備製造經濟的車輛。Information Hiding, Interface Design提供了靈活性。這種靈活性容許程序員在正常演進期間修改計算機程序的功能,由於計算機程序被改變以更好地適應用戶的須要。當計算機程序設計得很好時,使用信息隱藏原理將源代碼解決方案分解爲模塊,進化變化更容易,由於變化一般是局部變化而不是全局變化。
因此咱們的設計方案主要就是對類的變量進行私有封裝,不讓其暴露出來,其次爲調用私有變量和修改提供特殊的接口。其次就是對每個命令行參數的處理封裝成函數,便於調用,提供標準化的接口。程序員
st=>start: main函數入口 e=>end op=>operation: 處理命令行參數狀態機 cond=>condition: 是否有環? op2=>operation: 拓撲排序及動態規劃(類) op3=>operation: dfs暴力搜索(類) st->op->cond cond(yes)->op3 cond(no)->op2
咱們沒有寫這個正則表達式來匹配全部的命令行參數,由於參數個數較少,組合狀況很少,因此咱們採起了有限狀態機的方式來識別全部的命令選項。而後根據這個圖是否有環調用相應的類去處理。對單詞文本的處理是將輸入的一個個單詞看成圖上的一個個點進行處理,採用鄰接矩陣來儲存邊與邊之間的距離,距離爲被指向單詞的長度
無環類:主要是一個類,運用了拓撲排序和動態規劃的思想,尋找最長路徑。
有環類:這個也是一個類,這部分是我寫的,我主要就是DFS遍歷圖,暴力搜索尋找最長路徑。github
VS自動生成的類圖以下:正則表達式
由圖咱們能夠看出,咱們主要是實現了一個公共接口類,分別在有環和無環類中實現了這個處理-w和-r的函數實現。算法
咱們小組開始沒有對搜索進行優化,因此說有時候進行了大量的無用搜索。咱們主要對這個拓撲排序進行了優化,減小了不少沒必要要的搜索。其次就是在處理-r參數時,咱們先判斷了圖,若是沒有環,仍然調用拓撲排序來作。這樣就減小了不少時間開銷。咱們這個改進大概總共花費了6個小時吧編程
Design by Contract, Code Contract就是指合同化編程,契約式設計。契約式設計就是按照某種規定對一些數據等作出約定,若是超出約定,程序將再也不運行,例如要求輸入的參數必須知足某種條件。契約式設計的核心概念就是前置條件,後置條件和不變式,這種方式的好處是能夠避免不少bug,減小調試的時間,這個咱們大二下OO的JSF要求差很少了。可是這種方式設計起來過於繁瑣,每個函數設計起來費時費力。
因此說,咱們並無採起這種方式,而是採起了函數內檢查的形式。模塊化
沒有封裝成core接口,因此測試很差作。
TEST_METHOD(TestMethod1) { string xx = "test.txt"; ProcessNoRing p = ProcessNoRing(xx); p.init(); p.getWord(xx); Assert::AreEqual(2, p.wordNum); }
函數
-輸入文件不存在oop
例如輸入111.txt,可是在這個目錄下沒有這個文件,會報錯:open file failed!!!性能
-輸入的單詞數量過多
例如輸入五百個以上不一樣的單詞的文件,會報錯:too many words!!!
-輸入了有環的指令但圖中沒有環
報錯:topologicalSort successed! 表示能夠拓撲排序,圖中無環
-輸入了無環的指令但圖中有環
報錯:topologicalSort failed! 表示不能夠拓撲排序,圖中有環
-輸入的首字母有除了字母以外的字符出現
報錯:illegimate input as first char X(表示錯誤的字符)
-輸入的尾字母有除了字母以外的字符出現
報錯:illegimate input as last char X(表示錯誤的字符)
-輸入的某個單詞自身首尾相同
不會報錯,不會自身成環
-輸入單個字母的單詞
不會報錯,視爲正常單詞
這個主要就是運用狀態機的知識來處理這個命令行參數。
主要函數有下面三個
void FirstState(char *argv[]); void SecondState(char *argv[]); void ThirdState(char *argv[]);
這個主要就是識別到-r進入第一個狀態,而後識別到-h或者-t進入第二個狀態,最後-w,-c進入第三個狀態。
在這個過程當中,咱們會把一些參數轉爲bool型變量。
void FirstState(char *argv[]) { if (strcmp(argv[ArgvCnt], "-w") == 0 || strcmp(argv[ArgvCnt], "-c") == 0) { process = strcmp(argv[ArgvCnt], "-w") == 0 ? 0 : 1; ArgvCnt++; ThirdState(argv); } else if (strcmp(argv[ArgvCnt], "-h") == 0 || strcmp(argv[ArgvCnt], "-t") == 0) { ProStart = strcmp(argv[ArgvCnt], "-h") == 0; ProEnd = strcmp(argv[ArgvCnt], "-t") == 0; ArgvCnt++; if (strlen(argv[ArgvCnt]) == 1 && isalpha(argv[ArgvCnt][0])) { StartWord = argv[ArgvCnt][0]; EndWord = argv[ArgvCnt][0]; ArgvCnt++; SecondState(argv); } else { ErrorPrint(argv); } } else { ErrorPrint(argv); } }
部分函數如上所示。
int EnalbleLoop; //是否容許單詞環 (0不容許,1容許) int process; //處理單詞的方式 (0爲單詞數量,1爲單詞字母數) int ProStart; //是否指定首字母(0不指定,1指定) char StartWord; //首字母 int ProEnd; //是否指定尾字母(0不指定,1指定) char EndWord; //尾字母 string fileName; //文件路徑
如上所示,這個界面模塊和計算模塊主要就是經過這幾個全局變量進行對接,命令行的參數已經徹底轉化爲咱們所需的參數,直接調用便可。
咱們整個結對的過程,開始也和大多數人同樣。彼此也有一些不太一致的地方。可是既然選擇了在一塊兒,就只能慢慢去溝通、交流、配合。通過幾回線上線下的討論以後,咱們的觀點也趨於一致,而後就開始了愉快的編程了。咱們主要是我開始編寫命令行參數的識別部分並提供部分接口,而後文政堯就開始寫無環部分單詞鏈的處理,而後我在開始有環單詞鏈的處理,文政堯再進行單元測試,我負責把整個程序封裝好。
結對編程的優勢:
1.可以發現一些人爲bug,並且可以及時修復。
2.對一些複雜算法可以及時討論,找出合理的解決方案。
3.程序版本更新比較及時,沒有滯後感
結對編程的缺點:
1.對兩我的要求比較高,不必定適合本身。
2.比較耗時耗力,並且容易滯後進度,容易處在等的環節。
由於此次沒有作的很好,咱們打算繼續改進。
成員 | 優勢 | 缺點 |
---|---|---|
15005012 左順 | 性格開朗,執行力好,善於思考 | 有時候比較固執,對算法領悟不夠深 |
16061100 文政堯 | 性格開朗,對算法理解比較好,有一些創新想法 | 執行力不是很夠 |
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | ||
.Estimate | 估計這個任務須要多少時間 | 2000 | |
Development | 開發 | ||
.Analysis | 需求分析 (包括學習新技術) | 240 | 250 |
.Design Spec | 生成設計文檔 | 180 | 120 |
.Design Review | 設計複審 (和同事審覈設計文檔) | 120 | 120 |
.Coding Standard | 代碼規範 (爲目前的開發制定合適的規範) | 30 | 30 |
.Design | 具體設計 | 200 | 300 |
.Coding | 具體編碼 | 450 | 500 |
.Code Review | 代碼複審 | 240 | 200 |
. Test | 測試(自我測試,修改代碼,提交修改) | 240 | 260 |
Reporting | 報告 | ||
.Test Report | 測試報告 | 180 | 100 |
.Size Measurement | 計算工做量 | 30 | 20 |
·Postmortem & Process Improvement Plan | 過後總結, 並提出過程改進計劃 | 60 | 30 |
Sum | 合計 | 1970 | 1930 |