軟件工程結對做業博客

博客項目地址

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	70	30
· Analysis	· 需求分析 (包括學習新技術)	240	160
· Design Spec	· 生成設計文檔	70	30
· Design Review	· 設計複審 (和同事審覈設計文檔)	20	10
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	20	10
· Design	· 具體設計	120	70
· Coding	· 具體編碼	360	480
· Code Review	· 代碼複審	120	60
· Test	· 測試（自我測試，修改代碼，提交修改）	120	160
· Test Report	· 測試報告	120	360(生成測試覆蓋率找了很久)
· Size Measurement	· 計算工做量	40	25
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	40	20
	合計	1340	1415

Information Hiding, Interface Design, Loose Coupling

• information hiding

  信息隱藏，有利於程序編寫過程當中，設計決策相應的改變。經過信息隱藏，防止類或者其他的軟件組件被客戶端所訪問到，提供穩定的接口進行交互。

  • 在結對編程的過程當中，信息隱藏主要經過C++的類的特性來對實現過程當中用到的數據結構等來進行封裝。將相應的數據和方法設置爲private，防止調用的類可以訪問到或者直接應用其中的數據結構。這樣在對相應的算法等內容進行修改的時候，不用進行大範圍的修改。

• interface design

  用戶界面設計，經過用戶界面設計，使得用戶在完成本身的任務時與被設計對象之間的交流盡量地簡單高效，經過圖形設計能夠提升界面的可用性。

  • 咱們的界面設計並無設計圖形界面，僅僅只是按照基本要求提供了相應的命令行調用，在調用過程當中，如果出現相應的錯誤，則輸出相應的錯誤信息進行提醒。

• loose coupling

  鬆耦合，在計算機運算和系統設計中，一個鬆耦合的系統中的每個組件對其餘獨立組件的定義所知甚少或一無所知。子範圍包括類、接口、數據和服務之間的耦合。[1] 鬆耦合是緊耦合的對立面。

  • 鬆耦合這塊主要是經過提供必要的接口進行交互來下降系統的耦合性。其中主程序主要經過調用preprocess類和相應的core類所提供的接口來組合成完整的程序，preprocess類和core類不會相互影響。

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

• 計算模塊的接口主要就是提供兩個要求的接口，其中分別爲

  gen_chain_word(char* words[], int len, char* result[], char head, char tail, bool enable_loop)
  gen_chain_char(char* words[], int len, char* result[], char head, char tail, bool enable_loop)

• 主要實現過程
  • 算法關鍵：將26個字母做爲節點，將每一個單詞做爲邊，進行圖的構建，而後在查找相應的最長路徑過程當中，經過對圖進行相應的dfs遍從來查找。
  • 類：主要的類就是圖相關的類，該類爲WordGraph，其中基本屬性有路徑和節點等相關的結構體
  • 方法：

  Path *LongestPathFrom(char start, bool isWeighted); (用於計算已知起點的最長路徑)
      Path *LongestPathBetween(char start, char end, bool isWeighted);（用於計算已知起點和終點的最長路徑）
      Path *LongestPathTo(char end, bool isWeighted);（用於計算已知終點的最長路徑）
      Path *LongestPath(bool isWeighted); （用於計算圖中最長路徑）
      bool IsCyclic(); (判斷是否含有相應的環)

  UML圖

計算接口方面的性能改進

• dfs是該算法過程當中消耗時間最長的部分，其中剛開始咱們的程序中有部分多餘的搜索，通過改進了以後,可以減小多餘的搜索
  -

契約式設計

契約式設計（英語：Design by Contract，縮寫爲 DbC），一種設計計算機軟件的方法。這種方法要求軟件設計者爲軟件組件定義正式的，精確的而且可驗證的接口，這樣，爲傳統的抽象數據類型又增長了先驗條件、後驗條件和不變式。這種方法的名字裏用到的「契約」或者說「契約」是一種比喻，由於它和商業契約的狀況有點相似。

• 契約式設計可以使得軟件總體的設計更加優秀，同時可以在軟件編寫過程當中幫助調試，生成更加可靠的軟件。
• 可是契約式編程在設計方面所須要投入的時間更多，同時對於編程人員的水平以及對於軟件組件等有清晰的認識。
• 結對編程過程當中，咱們小組主要經過統一對異常的控制來處理相應的先驗條件，好比在處理命令的時候，如果判斷該條命令並不合法，則會拋出相應的異常，增長了命令合法的先驗條件以後，這樣以後的程序就無須處理該種異常的狀況。

計算模塊單元測試展現

TEST_METHOD(TestMethod1)
        {
            TEST_INIT(11, "Algebra", "Apple", "Zoo", "Elephant", "Under", "Fox",
                "Dog", "Moon", "Leaf", "Trick", "Pseudopseudohypoparathyroidism");
            
            GEN_CHAIN_WORD(0, 0, false);
            ASSERT_RESULT_LEN(4);
            ASSERT_RESULT("algebra", 0);
            ASSERT_RESULT("apple", 1);
            ASSERT_RESULT("elephant", 2);
            ASSERT_RESULT("trick", 3);

            GEN_CHAIN_CHAR(0, 0, false);
            ASSERT_RESULT_LEN(2);
            ASSERT_RESULT("pseudopseudohypoparathyroidism", 0);
            ASSERT_RESULT("moon", 1);

            GEN_CHAIN_WORD('e', 0, false);
            ASSERT_RESULT_LEN(2);
            ASSERT_RESULT("elephant", 0);
            ASSERT_RESULT("trick", 1);

            GEN_CHAIN_WORD(0, 't', false);
            ASSERT_RESULT_LEN(3);
            ASSERT_RESULT("algebra", 0);
            ASSERT_RESULT("apple", 1);
            ASSERT_RESULT("elephant", 2);
        }

• 計算模塊的單元測試展現如上圖所示，其中主要用到的方法爲TEST_INIT , ASSERT_RESULT_LEN ， ASSERT_RESULT ， 其中TEST_INIT主要是經過對輸入的單詞進行初始化，存入相應的數據結構之中。ASSERT_RESULT_LEN爲對結果的長度的檢驗。ASSERT_RESULT則是對最後結果的檢測，檢測結果是否爲響應的正確內容。

• 測試覆蓋率圖片
  
  

  一張爲核心計算模塊的覆蓋率測試報告，一張爲命令行程序的覆蓋率測試報告

計算模塊異常處理說明

• 計算模塊中的異常主要能夠分爲對輸入不合法的異常以及輸入單詞中包含單詞環的異常
• 其中針對輸入不合法的異常單元測試以下

// pre.command 異常測試
   TEST_METHOD(TestMethod6) {
       try {
           Preprocess pre;
           int argc = 1;
           char ** argv = new char *[argc];
           argv[0] = new char[10];
           strcpy(argv[0], "Wordlist.exe");
           pre.command(argc, argv);
           Assert::Fail();
       }
       catch (std::exception e) {

       }
   }

• 其中針對輸入單詞中包含單詞環的異常測試以下

// 有環但enable_loop是false，應該拋出異常
   TEST_METHOD(TestMethod1)
   {
       TEST_INIT(7, "gag", "fag", "glitz", "zaf", "jof", "fij", "lkkj");
       Assert::ExpectException<std::exception>([&]
       {
           GEN_CHAIN_WORD(0, 0, false);
       });
   }

界面模塊

界面模塊是咱們組後來推動的內容，主要由個人搭檔編碼。

gui部分主體爲兩個單詞框，其中一個用於輸入，另外一個用於輸出，對於單詞鏈首字母與單詞鏈尾字母等相關內容，在右側經過複選框等內容進行選擇。同時要從文件讀取的話，能夠經過下拉選單實現相應功能。

部分代碼示例以下：

leftLayout = new QVBoxLayout;
rightLayout = new QVBoxLayout;
topRightLayout = new QHBoxLayout;
bottomRightLayout = new QHBoxLayout;
mainLayout = new QHBoxLayout;

// 左邊的輸入輸出框
leftLayout->addWidget(inputLabel);
leftLayout->addWidget(inputTextEdit);
leftLayout->addWidget(outputLabel);
leftLayout->addWidget(outputTextEdit);

// 右上角的單詞數最多和字母數最多單選框
topRightLayout->addWidget(maxLabel);
topRightLayout->addWidget(wordRadioButton);
topRightLayout->addWidget(charRadioButton);

// 右下角查找和導出按鈕
bottomRightLayout->addWidget(findButton);
bottomRightLayout->addWidget(exportButton);

// 右邊佈局
rightLayout->addLayout(topRightLayout);
rightLayout->addLayout(headLayout);
rightLayout->addLayout(tailLayout);
rightLayout->addWidget(loopCheckBox);
rightLayout->addWidget(extractButton);
rightLayout->addLayout(bottomRightLayout);

mainLayout->addLayout(leftLayout);
mainLayout->addLayout(rightLayout);

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

合做小組的學號：16061011，16061152
咱們兩個小組對於dll的使用方式有所不一樣，致使一開始，雙方都不能跑對方的程序，最後咱們各自做出了相應的調整，解決了相應問題。

咱們將對方組的core模塊添加了相應的def文件以後，最後成功運行出了相應的結果。

對方組用咱們組的core模塊之時，程序沒法正確運行，最後咱們將源碼合在一塊兒後找出相應問題並修正，同時在core模塊中添加了相應的去重處理。

結對過程

• 結對過程當中，爲了提升進度，咱們小組首先各自單獨設計相應的模塊，同時完成部分demo編碼，以避免一塊兒結對編程的時候，浪費過多的時間，最後約定了相應的時間，合做開展結對編程，主要是一塊兒推動程序的完成，討論算法的實現，最後一塊兒編寫相應的測試樣例。
• 下圖爲咱們兩人在新主樓結對編程之時所拍下的照片

結對編程的優缺點

• 結對編程的優勢爲兩我的同時編程，可以提升程序編寫的效率，同時，由於兩我的在一塊兒寫代碼，溝通效率高，可以避免覺得溝經過程中，信息傳達錯誤而形成的問題。最後軟件寫好就是一個總體，避免了分工整合以後的調整等問題。

• 缺點就是這樣的編碼方式可能不少同窗不是很習慣，同時兩我的都有本身的想法，須要花費較多的時間達成共識才能夠進行相應的編碼

• 隊友的優勢
  • 能力強，推動了程序的核心算法部分，對我幫助很大
  • 工做積極，老是提早完成相應內容
  • 時間安排合理，使得任務順利完成
• 隊友的缺點
  • 說話聲音稍微有點輕，但不影響交流ε=ε=ε=(~￣▽￣)~
• 隊友對個人評價
  • 優勢：
    • 積極熱情，有責任心
    • 具備批判性思惟
    • 注重細節
  • 缺點：

    • 編碼風格不太一致

      該格式內容的文字表示引用網上相關內容，