1012 C++ 程式作業二 (due 102/05/23(四) 23:59)：

修車廠管理系統

在前面的作業和實習裡面, 大家學會了

怎樣運用C++函式庫中現成的物件,
怎樣建立單一的類別 (建構元, 解構元, 拷貝建構元, 設定運算子, 檔案序列化, ...)
怎樣結合多個類別來提供一些功能,

在這個作業裡基本上就是讓你綜合運用上述來建立物件化的系統, 結合多個類別的物件來模擬實際世界中系統的運作, 提供自動化的輔助系統, 後續可以提供你練習物件導向技術的基礎平台, 練習繼承與多型的設計方法, 進一步結合資料庫系統或是圖形化介面系統開發應用程式。
還是再一次的提醒你, 不要看同學的 code, 不管助教在 demo 時會不會抓到, 看過以後你很難發現自己寫程式時的瓶頸, 如果考試時出一樣的問題, 只做一小部份的變化, 你很容易就完全沒有辦法寫出來, 浪費了你這一個階段的學習, 助教和我在繳交程式前都會盡力回答每一位同學的問題。

作業說明：

通常客戶開車進到修車廠中, 或是車子被拖入修車廠中, 資深的技師很快地幫你評估需要做怎樣的維修或是哪些項目的保養, 然後根據目前在等候維修的車輛、可用的設備狀況、以及今天上班的技師的數量, 給你一個預估的完修時間以及初步的報價, 由於現在物料控管以及物流系統都很發達, 所以各種車款的各種維修零件都建立了電腦系統, 可以查詢到所需要的物料的價格, 修車廠中對於各種車款的故障狀況以及保養程序也在電腦中建立了標準流程, 所以技師只要鍵入基本的客戶車輛資料, 選擇維修的項目, 程式就可以自動推算出預估的取車時間以及初步的報價, 這個作業就是嘗試建立這樣的一套系統。
由於大家對於物件化的分析與設計並不熟悉, 我們在這個作業裡還是稍微先做一些簡化, 以便你更容易實作需要的類別:

物料的價格、品名、與系統內部編號我們簡化如下表:

物料編號	品名	售價	維修時是否需舉升車體	保固期 (月)
a24	頭燈燈泡	2000	0	12
a25	前燈罩	600	0	12
a26	空氣濾清器	1200	0	12
a31f	前門中控鎖	2600	0	24
...
c01	輪胎	2200	1	6
..

測試資料檔 Parts.txt

其中第一列為檔案中資料的筆數, 其餘資料請參考檔案內說明

每一個物料都是一個物件? 整個物料表格是一個物件? 或者都是物件? 從物件模型化分析的角度來看, 當然都是物件, 但是究竟在你的作業裡要不要把每一種看到的物件包裝成一個類別來實作? 還是可以暫時先不包裝, 需要的時候再修改? 其實是有彈性的, 在後續開發的過程中其實也都可以調整的, 不封裝成物件的話, 就只是存放資料的地方而已, 所有的功能就都散落在各處需要使用這種資料的地方, 就像第一週課程中所談到, 資料除了型態有限制之外, 數值變成沒有任何限制的, 出錯的機率變大, 如果封裝成類別的話, 每一個物件是有適當責任的, 負責管理適當的資料, 管理由這些資料所提供的服務。但是你正在學怎樣寫出物件化的程式, 正在熟悉這些語法, 也許你覺得多寫一個類別是一種負擔, 那其實也不要太過煩惱, 就先按照你看到的來實作, 每一種設計都有優點和缺點, 重點是你看到那些優缺點, 這裡沒有絕對正確的答案, 你需要先嘗試其中一種以後才知道有什麼好處, 有什麼壞處。

維修或是保養項目我們簡化如下表:

維修項目代號	需更換物料				維修時間 (分鐘)	工資
1001	a31f		a32	b01	20	700
...
2001	c01	c02	c03	d02	60	2500
...

測試資料檔 MaintenanceItems.txt

其中第一列為檔案中資料的筆數, 其餘資料請參考檔案內說明

每一個維修項目都是一個物件? 整個維修項目表格是一個物件? 或者都是物件?

日期與時間
客戶把車輛開到保養廠時, 技師評估過以後應會填寫一張維修單, 載明維修的車輛, 維修的項目, 預估的取車時間, 以及報價
這一次的作業裡你可以先假設只有一個技師, 一套維修的設備, 所以所有進廠的車輛都需要排在待修隊伍中一輛一輛地順序維修 (後續你可以進一步設計比較複雜的維修策略, 多種不同的維修項目可以有多組技師同時進行...), 假設給機具和維修技師 10 分鐘的休息時間, 假設實際維修時間是標準維修時間的 80%-120%

a. 系統目前的時間請以 "新客戶到達時輸入的時間" 或是 "查詢維修狀態時輸入的時間" 為準
b. 請注意系統運作時上述兩種輸入的時間值是遞增的 (你可以參考下面的測試資料)
c. 每當系統時間改變時, 請修正/重新估計在隊伍中還沒有維修完的車輛的 "完修時間", 已經修完的車輛的完修時間已經記錄下來, 不會再更改了
d. 每一張維修單的 "預估取車時間" 可以用最多的時間 (120% 標準維修時間) 來估計, 如此實際的取車時間會比預估的時間早

STL queue, 擴充的 iterable_queue, STL deque

使用者介面:

這個程式目標是要在修車廠裡面執行的, 但是在開發的過程中, 我們希望不要用真正的系統時間來測試, 而改用輸入的時間, 下面為測試這個程式時使用者操作的範例:

D:\assign2>garage

Enter today's date: (year, month, day) 2013 5 1

[S]tatus update/[N]ew request? S
Current time? (hour, minute) 9 0

There is no car currently being maintained!

[S]tatus update/[N]ew request? N
Service request time: (hour, minute) 9 20 
License Plate: 8934-NX 
Number of Service Items: 2 
Service Items: 1002 1004
Expected finish time: 2013/05/01 10:44

[S]tatus update/[N]ew request? S
Current time? (hour, minute) 9 30

[0000] 8934-NX, Time requested:  2013/05/01 09:20 ,
                Service requested: 1002, 1004,
                Service started on 2013/05/01 09:20 ,
                Charge=NT7900
   ===> Expected finish time:  2013/05/01 10:44

[S]tatus update/[N]ew request? N
Service request time: (hour, minute) 9 50
License Plate:  1234-AB 
Number of Service Items: 2 
Service Items: 1003 2001
Expected finish time: 2013/05/01 12:30

[S]tatus update/[N]ew request? S
Current time? (hour, minute) 10 10

[0000] 8934-NX, Time requested:  2013/05/01 09:20 ,
                Service requested: 1002, 1004,
                Service started on 2013/05/01 09:20 ,
                Charge=NT7900
   ===> Expected finish time:  2013/05/01 10:44
[0001] 1234-AB, Time requested:  2013/05/01 09:50 ,
                Service requested: 1003, 2001,
                Service not yet started.,
                Charge=NT15600
   ===> Expected finish time:  2013/05/01 12:30

[S]tatus update/[N]ew request? N
Service request time: (hour, minute) 17 20 
License Plate: 4444-RR 
Number of Service Items: 2 
Service Items: 2003 2004
Expected finish time: 2013/05/01 19:14
Sorry, it's too late to accept this request!

[S]tatus update/[N]ew request? S
Current time? (hour, minute) 17 30

[0000] 8934-NX, Time requested:  2013/05/01 09:20 ,
                Service requested: 1002, 1004,
                Service started on 2013/05/01 09:20 ,
                Service finished on 2013/05/01 10:39 ,
                Charge=NT7900
[0001] 1234-AB, Time requested:  2013/05/01 09:50 ,
                Service requested: 1003, 2001,
                Service started on 2013/05/01 10:49 ,
                Service finished on 2013/05/01 12:20 ,
                Charge=NT15600
There is no car currently being maintained!

[S]tatus update/[N]ew request? N
Service request time: (hour, minute) 17 31

紅字部份為使用者輸入的資料, 其他為程式的輸出

系統啟動時先輸入當天的日期, 例如: 2013 5 1

接下來使用者有兩種選擇:

S 代表希望知道目前修車廠中已完修維修單以及 "待修隊伍" 中維修單的資料
N 代表有一輛車進廠維修, 需要產生維修單

如果使用者在產生新維修單時輸入的資料, 得到的預估完修時間超過 17:30, 系統不會接受這一份維修單

如果使用者輸入一個超過 17:30 的時間, 這時車廠已經準備關門, 如果 "待修隊伍" 中沒有維修單了, 系統就結束

範例執行程式, 基本的命令列測試資料如下:

程式要求

讀取資料檔案以及和使用者互動的部份請用 iostream, fstream 函式庫完成
根據上課講義, 希望你的程式滿足下列要求:
1. 去除不需要的指標運算 (能夠使用陣列語法的盡量使用)
2. 使用有意義的變數名稱
3. 不要使用沒有名稱的常數 (例如 int data[100];, 應該要用 int data[DATASIZE];)
4. 程式請務必對齊 (同一層的敘述一定要對齊)
5. 使用比較有限制的結構化語法 (for 迴圈比 while 迴圈好, if 比 goto 好, ...)
6. 使用函式來組織你的程式, 同時讓程式中每一個區塊裡變數盡量減少, 邏輯上沒有關連的程式盡量分到不同的區塊或是不同的函式中, 函式不要太大 (以 30 列為平均值, 不要超過 50 列)
7. 請運用 assert 敘述以及呼叫 stdlib.h 中的 qsort 建立自動測試正確性的程式碼 (至少排序完之後應該可以檢查一下正確性, 原始資料的正確性也可以檢查一下)
8. 另外, 請不要使用全域變數 (global variable) 在函式之間傳遞資料, 這是程序化程式設計的大敵

作業繳交注意事項

請於時限內 (102/05/23(四) 23:59) 上傳程式檔案 (逾時無法上傳, 請預先測試你的帳號與密碼), 上傳網頁
請注意雖然作業的要求好像看過很多次, 可是由於你對於 iostream, fstream, string, vector, deque 不是很熟悉, 所以你還是應該早點開始做, 避免先看到同學的程式, 由於程式功能已經有很多的限制了, 所以如果你先看過別人的程式, 你很難寫出和別人不一樣的東西...
請編輯一個 report.txt (或是 report.doc) 檔案, 說明你的演算法高階的模型, 概念上的作法, 資料結構, 你所完成的功能, UML類別圖, 測試結果,... 以及對於此次作業各個部份的問題? (提出問題時請盡量整理你所知道的, 與你所懷疑的, 你所不認同的..., 如此會比空洞的 "我不懂 xxx?", "yyy 是什麼?" 要容易回答, 相對的你也比較容易得到你想要的答案)
report.txt (或是 report.doc) 中請說明你的心得 (心得可以包括你覺得你獲得的觀念, 你 debug 時發現的問題, 你 debug 的心得, 作業的感想, 你自己覺得比較好或是比較特別的設計...)

回 C++ 程式設計課程首頁

製作日期: 05/09/2013 by 丁培毅 (Pei-yih Ting)
E-mail: pyting@mail.ntou.edu.tw TEL: 02 24622192x6615
海洋大學電機資訊學院資訊工程系 Lagoon