Round 6: Enters matrix

目前為止，我的例子只有一個class，vector。接下來，我將讓例子裡有兩個class。我仍取材自簡單的線性代數運算。

問題P2：寫一個程式，提示使用者輸入兩個分別存放一個矩陣M與一個向量v的檔案的名稱，其中矩陣M代表一個線性轉換。請計算對向量v施以該轉換所得之向量u。

u= Mv

並將u輸出到第三個使用者指定名稱的檔案。提示使用者可重複執行或結束程式。

限制：你必須儘量使用為inner product所開發的vector類別及相關函數，並在必要時增加相關函數。

U步驟：

問題P2要求的檔案輸入輸出均有C++ library可供使用，且牽涉的計算不複雜，所以我暫時將不分解成數個更小的問題。當然，如同前5輪U-D-C-L，我們後續仍有可能提出改善的sub-problem。

你可能要問我，為什麼不在一開始(round 1)的時候就把問題P2一併提出來？你的疑問很合理，我的確可以在一開始就一併提出向量內積與線性轉換等二個問題。即便如此，我並不需要一次面對二個不同的問題；因為這二個問題彼此間的邊界(boundary)相當清楚，分開來解是合理的做法。同時，因為解線性轉換問題時須使用向量內積，故這個解題順序仍屬合理。

除此之外，現實世界中，客戶追加需求是相當常見的情形。追加的需求，當然需要站在既有的基礎上，正像前述問題限制我們必須儘量重複使用(reuse)為inner product所開發的vector類別及相關函數。問題P2中，線性轉換u = Mv的算法，u的分量為M相同位置的列向量(row vector)與v的內積。

D步驟：

我們需要針對matrix運算與測試、線性轉換主程式建立相關專案。

由於問題要求重複使用且我們也可能需要修改或新增inner product所開發的code，在專案的安排上，我們需要繼續讓
project inner product、 project vector test維持在開發中的狀態。雖然問題P2並未要求與 inner product有關係，由於vector可能有所變動，所以project inner product需要連帶被編譯、執行以確保其正確性。

列出工作如下：

T13 設計 vector在檔案中的儲存格式，編寫讀/寫檔案函數。

T14 測試vector讀/寫檔案函數。

T15 設計matrix在檔案中的儲存格式，編寫讀/寫檔案函數。

T16 測試matrix讀/寫檔案函數。

T17 編寫 matrix類別，含data members 與 member functions。

T18 測試matrix類別。

T19 編寫線性轉換函數。

T20 測試線性轉換函數。

T21 編寫main函數。

C步驟：
先做哪個task？基於round 5結果，我們有vector test專案，因此可以先顯選擇範圍限制在處理T13(先寫 vector讀寫檔函數)或T14(先寫 vector讀寫檔函數單元測試)。 

我採取 測試先行(test first)策略，先選擇T14。好處有二：

• 當unit test code完成時，已初步完成vector讀寫檔函數的函數原型設計。
• 當unit test執行無誤時，你知道已初步完成vector讀寫檔函數的函數的實作。

T14與T13完成後，編譯、執行inner product project，確認無誤。這個動作為inner product project進行迴歸測試(Regression testing)：原有的inner product 執行已達預期狀況，但它使用的class vector與函數變動了，我們需重新加以確認。

(學習課題：ifstream, ofstream, fstream)

接著，完成matrix相關測試、類別與函數，仍採測試先行，依序執行T18、T17、T16、T15。在此之前，我們仿照先前vector的做法，建立matrix test專案。

下篇繼續。

© Y C Cheng, 2013. All rights reserved.