Grade System project(with Agile method)

~ 1 ~
目錄
WEEK 1
I. 工序一：探索需求 (Exploring Requirement) p.2
II. 工序二：使用情節 (Scenario) p.4
III. 工序三：驗收測試案例與使用手冊
(Acceptance Test Case & User Mannal) p.9
IV. 第一週內容修正 (Modify Week 1) p.18
V. 第一週雙人開發紀錄 (Pair Programming Week 1) p.19
VI. 第一週結語 (Week 1 Ending) p.20
WEEK 2
I. 工序四：架構設計會議 (CRC Session) p.21
II. 工序五：模擬派工及時程 (Dispatching & Scheduling) p.32
III. 工序六：撰寫單元測試碼 (Unit Test Code) p.33
IV. 第二週內容修正 (Modify Week 2) p.45
V. 第二週雙人開發紀錄 (Pair Programming Week 2) p.47
VI. 第二週結語 (Week 2 Ending) p.54
WEEK 3
I. 工序七：資料結構設計 (Data Structure Design) p.57
II. 工序八：演算法設計 (Algorithm Design) p.62
III. 第三週內容修正 (Modify Week 3) p.82
IV. 第三週雙人開發紀錄 (Pair Programming Week 3) p.84
V. 第三週結語 (Week 3 Ending) p.87
WEEK 4
I. 工序九：按照虛擬碼補上程式碼 (Coding) p.88
II. 工序十：單元及驗收測試 (Unit & Acceptance testing) p.110
III. 工序十一：逆向工程工具 (Reverse Engineering Tool)
IV. 第四週內容修正 (Modify Week 4)
V. 第四週雙人開發紀錄 (Pair Programming Week 4)
VI. 第四週結語 (Week 4 Ending)

~ 2 ~
探索需求
--------Exploring Requirement--------
系統功能
查詢成績(含成績分布查詢)
查詢排名(含全班排名)
更新配分
相關特性
顯示使用者成績(含分布)查詢成績
• 平時測驗一(test1) 平時測驗二 (test2) 平時測驗三 (test3)
• 期中考試(midterm) 期末考試(finalExam)
• 總成績 (totalGrade)
• 成績分布(gradeGraph)
顯示使用者排名(含班排)查詢排名
• 個人排名(rank)
• 全班排名(classRank)
使用者輸入新配分以更新配分更新配分
• 舊配分(test1 test2 test3 midterm finalExam)
• 新配分(newTest1 newTest2 newTest3 newMidterm newFinalExam)

~ 3 ~
限制
• 輸入錯誤ID登入介面
• 輸入錯誤指令
• 確認新配分之指令錯誤
功能介面

~ 4 ~
使用情節
-----------------Scenario-----------------
功能情節 Function Scenarioes
1. 螢幕顯示【登入介面】
使用者指令結束系統
螢幕顯示【系統結束訊息】
使用者輸入 ID
螢幕顯示【系統登入訊息】
螢幕顯示【功能介面(四種功能)】
○1 顯示成績 ○2 顯示排名 ○3 更新配分 ○4 離開選單
使用者指令離開選單
螢幕顯示【登入介面】

~ 5 ~
使用者輸入 ID
螢幕顯示【功能介面】
使用者指令顯示成績
螢幕顯示【該 ID 成績】
螢幕顯示【成績分布請求】
使用者指令否認
使用者輸入 ID
使用者指令顯示成績
螢幕顯示【該 ID 成績】
螢幕顯示【成績分布請求】
使用者指令確認
螢幕顯示【各科成績分布】

~ 6 ~
使用者輸入 ID
使用者指令顯示排名
螢幕顯示【該 ID 排名】
螢幕顯示【全班排名請求】
使用者指令否認
使用者輸入 ID
使用者指令顯示排名
螢幕顯示【該 ID 排名】
螢幕顯示【全班排名請求】
螢幕顯示【全班排名】

~ 7 ~
使用者輸入 ID
使用者指令更新配分
螢幕顯示【舊配分訊息】
使用者輸入新配分資料
螢幕顯示【新配分訊息】
螢幕顯示【新配分確認訊息】

~ 8 ~
例外情節 Exceptional Scenarioes
使用者輸入錯誤 ID
螢幕顯示【ID 錯誤訊息】
使用者輸入 ID
使用者指令錯誤指令
螢幕顯示【指令錯誤訊息】

~ 9 ~
驗收測試案例與使用手冊
--Acceptance Test Case & User Mannal--
Acceptance Test Cases 驗收測試案例
正常案例


~ 15 ~
User Mannel 使用手冊

~ 18 ~
第一週內容修正
------------Modify Week 2------------
經由幾次討論，以及現階段在 java 課程上所學到的方法越來越多，在
我們進行每項工序的過程時，發現之前所決定的內容若改掉某些部份
可以使整個程式變得更加完善，因此我們在每週進度的最後放上修改
內容，以清楚了解修改的部分。
1. 將原成績系統加入兩種功能：顯示全班排名與顯示成績分布圖
我們在排名的部份加上了顯示全班排名的功能，讓使用者也能知
道自己在班上的相對名次，還有我們也加上了個次考試的的成績
分布圖，讓使用者了解自己該次的成績是落在哪一塊範圍內。

~ 19 ~
第一週雙人開發紀錄
------Pair Programming Week 1------
4/6 (六) 也晏家 17:00~20:00
討論需求與想出另外 2 個情節
新增情節: 也晏成績分布子萲全班排名
4/9 (二) G316 14:00~18:00
Driver:也晏 Viewer:子萲
完成探索需求與使用情節草稿
畫出情節架構及程式設計圖
4/10 (三) G315 17:00~21:00
完成驗收測試案例及使用手冊草稿
Driver:子萲 Viewer:也晏
將所有工序排版美化
4/11 (四) G513 19:30~21:00
最終校正與列印

~ 20 ~
第一週結語
-------------Week 1 Ending-------------
選擇夥伴原因?
子萲
因為好友中, 也晏對 Java 程式很熟悉, 他平時也很樂於指導他人, 而且我
們也是讀書夥伴, 跟他一組能讓我吸收到不一樣的思考, 並可以跟自己的想
法做比較, 也能方便溝通及討論作業
也晏
子萲生性隨和, 在報告製作上意見衝突很少, 好問好學的個性, 也對釐清程
式架構有莫大幫助, 藉由這些溝通, 能有效減少作業內容的錯誤, 降低未來
Coding 時出現 Bug 的可能性, 藉由這次作業, 也可以讓雙方對 Pair
programming 的認知與實作, 更加接近真實
遇到什麼困難?
子萲
因為是第一次用這種方法寫程式，所以剛開始很難抓到這個作業的方向
程式架構圖比想像中複雜，因此花了很多時間去理解
偶爾會有埋頭苦幹的狀況，應該適度休息。
也晏
不甚了解敏捷方法，在了解各工序意義上，耗了不少時間，
造成熬夜趕工情況，或有違背 Agile Method 意義，實應反省改進，
課業繁重，Pair programming 的時間安排不易，
範例上或有新知待學，仍須花些時間了解其應用。

~ 21 ~
架構設計會議
--------------CRC Session--------------
CRC Card
/** Header: This class is used to start a grade system */
Main Object
Main method
create an UI UI
Input data Grades
try catch Exceptions
Create a NoSuchIDException NoSuchIDException
create a
NoSuchCommandException

~ 22 ~
/**Header: This class is used to create an user interface */
UI
check ID
check command
create a grade system GradeSystems
create a grade Grades
prompt command
prompt ID
show finish message
show welcome massage

~ 23 ~
/**Header: This class is used to create a grade system */
GradeSystems
show grade Weights
show grade point Grades
show rank Ranks
show class rank Ranks
show weights Weights
update weights Weights
exit

~ 24 ~
/**Header: This class is used to get the data of the grades */
Grades
store ID, name UI
store grades
store total grade
store grade point
compute total grade Weights
show ID, name GradeSystems
show grades GradeSystems
show total grade GradeSystems
show grade point GradeSystems

~ 25 ~
/**Header: This class is used to get the data of the weights */
Weights
store weights GradeSystems
show weights GradeSystems
/**Header: This class is used to get the data of the ranks */
Ranks
compute rank, classRank Grades,Weights
store rank, classRank Grades
show rank, classRank GradeSystems

~ 26 ~
/**Header: This class is used to define a wrong ID exception */
NoSuchIDException Exception
define a NoSuchIDException Main
/**Header:
This class is used to define a wrong command exception */
NoSuchCommandException Exception
define a
Main

~ 27 ~
CRC Headers
Mian Class
UI Class

~ 29 ~
Grades Class
Ranks Class

~ 31 ~
NoSuchIDExceptions
NoSuchCommandExceptions
NoSuchWeightExceptions

~ 32 ~
模擬派工和時程
------Dispatching & Scheduling------
也晏
Main (約2天)
UI (約5天)
GradeSystem (約7天)
子萲
Grades (約7天)
Ranks (約2天)
Weights (約3天)

~ 33 ~
撰寫單元測試碼
------------Unit Test Code------------
Main Class

~ 35 ~
GradeSystem Class (30 min)

~ 44 ~
NoSuchIDExceptions
NoSuchWeightExceptions

~ 45 ~
第二週內容修正
------------Modify Week 2------------
1. 將原 Grades Class 分割為 Grades、Ranks、Weights 三個 Class
範例程式中，計算排名以及配分都是在 Grades Class 裡，在我們進
行 CRC 這個程序時，發現這樣會使得 Grades 的內容太過繁雜，因
此討論過後我們決定將計算排名和配分的部分各自獨立出來為一
個 Class，讓程式的架構更為明確且易於理解。
2. 合併部分 method
原 UI Class 的 promptID()、 promptCommand()兩者內容似乎有所重
複，因此我們將其內容通通合併到 promptID()內，才能符合原意。
此外，由於考慮到印出內容之格式設計，我們將原本獨立出來的
totalGrade()刪除，且將其內容合併到 getGrades()裡，如此比原先的
設計更加簡潔且方便閱讀。

~ 46 ~
3. 將介面改為 GUI 形式呈現
在進行測試碼的撰寫時，正好 java 已經教過 GUI 的設計方法，因
此我們討論過後決定將這支程式的所有介面都改以 GUI 形式呈現，
如此一來除了讓程式執行時有更加簡潔的介面，也省去了原本設
定中會出現的例外狀況(NoSuchCommandException)，降低使用者在
使用上的不便性。
4. 新增 NoSuchWeightException 之例外狀況
由於我們將介面改為 GUI 形式，因此在功能介面上便不會有指令
錯誤的狀況發生，但是我們也考慮到新配分的輸入可能有輸入錯
誤的情況，例如不能輸入數字以外的符號等，此情節在範例程式
中並未提及，因此我們決定將輸入錯誤配分指令列入例外狀況之
一，當使用者輸入內容不符合規範時，系統會顯示出錯誤訊息。

~ 47 ~
第二週雙人開發紀錄
4/16(二)G315 15:00~16:00
討論 CRC Card 並擬出草圖
15:00~15:15
確定所有 class 並寫在白板上
也晏提議: 是否將原 Grades 分割?
子萲回應: 將排名與配分獨立出來如何?
結論:分為 Grades,Ranks,Weights 3 個 class
15:15~15:25
Main, UI, GradeSystems 成員
子萲提問: Main 可以改叫 Test 嗎?
也晏回應: 這不是測試檔，應該盡量避免使
用 Test 等字眼
結論: 不更動 Main 的名稱
也晏提問: 學生檔案是在 Main 放入還是 UI?
子萲回應: 在 Main 吧，因為在 UI 時就要輸
入 ID 了
結論: 判斷應該在 Main 就放入 input data
15:25~15:40
Grades, Ranks, Weights 成員
15:40~16:00
所有 class 及其成員間的關係
子萲提問: 總成績的資料關係是?
也晏回應: 先從 Grades 取得成績，再到
Weights 取得配分計算總成績，
最後到 Ranks 算出排名

~ 48 ~
4/18(二)G316 16:00~17:00
完成 CRC Card
16:00~16:20
確認 Main, UI, GradeSystems
16:20~16:45
確認 Grades, Ranks, Weights
子萲提問: 成員與 Class 間的合作關係?
也晏回應: 與 show 相關－GradeSystems
16:45~17:00
最後確認
4/18(二)G513 19:30~21:00
製作書面報告
19:30~20:00
雙人開發紀錄
20:00~20:30
心得及封面目錄
20:30~21:00 最後校正及列印

~ 49 ~
4/26(五) 也晏家 17:00~21:30
討論 CRC Header 並實作程式及註解
17:00~17:15
分配各個 class 主設計者
也晏提議: 既然回應變動勝於遵循計畫, 那
這次作業我們還是要再想好一點的設定, 先
前作的僅用於參考即可
子萲回應: 嗯嗯
結論:兩人參考先前所做, 再想更好的設定
子萲提議: 我比較想做資料方面的 Class…
也晏回應: 恩, 好, 那就一人一半囉
結論:子萲設計資料方面的 Class(Grades,
Ranks, Weights), 也晏設計功能方面的
Class(Main, UI, GradeSystems)
17:15~17:25
對個人負責的 Classes 參考先
前成果(CRC Cards), 再行構思
17:25~17:55
Main, UI, GradeSystems 實作
Driver: 也晏 Viewer:子萲
也晏提議: 原 CRC Cards 中 UI Class 有
promptID(), promptCommand() 兩者似
乎有所重複, 應該修掉其中一個吧?
子萲回應: 嗯嗯, Coding 時若兩者都呼叫,
感覺就像是程式 prompt ID 又 prompt
Command 一樣, 不符原意
結論:因 ID 個數大於等於 Command(僅 E
一個), 故將 promptCommand() 刪除, 此
部分併入 promptID() 實作
17:55~18:30 晚餐時間

~ 50 ~
18:30~18:50
Main, UI, GradeSystems 註解
18:50~19:00 休息時間
19:00~20:00
Grades, Ranks, Weights 實作
也晏提議: 關於成績分布的 method 名稱…
似乎應該換個名字吧?
子萲回應: (Google), 嗯嗯, 翻不出正確意思
結論:使用 google 翻譯, 得到一個較佳的名
字: GradeGraph, method: getGradeGraph
20:00~21:00
Grades, Ranks, Weights 註解
21:00~21:30 討論下一工序:派工與時程

~ 51 ~
4/30(二) G316 15:00~17:00
完成派工與時程、單元測試碼、開始製作書面報告
15:00~15:20
確認各 Class 負責人, 完成派時
子萲提議: 就照上次分的吧, 這樣不會錯亂
也晏回應: 恩, 好, 那就一樣囉
結論:
子萲負責 Class(Grades, Ranks, Weights),
也晏負責 Class(Main, UI, GradeSystems),
時間由個人思考決定
15:20~16:00
了解並產生單元測試碼
子萲提問:要怎麼產生測試碼啊?
也晏回應:用 JUnit, Eclipse 有, 這樣(操作)
結論:也晏產生測試碼的同時, 使子萲也會使
用 JUnit 產生單元測試碼
16:00~17:00
製作報告
完成派工與時程、單元測試碼的書面報告
5/2(四) 也晏家 20:00~22:00
完成書面報告
20:00~20:30
雙人開發紀錄
20:30~21:00
心得及封面目錄
21:00~22:00 最後校正及列印

~ 52 ~
5/14(二) 也晏家 16:00~21:30
撰寫測試碼
16:00~17:30
撰寫 Grades 測試碼
Driver: 子萲 Viewer: 也晏
子萲提議: 我們原來是把總成績獨立出來一
個 method，要不要把它和其他成績都放在
一起，這樣印出時比較方便
也晏回應: 好啊，那就把它們放一起好了
結論 : 將原來的 getTotalGrade 合併到
getGrades 的 method 裡面
17:30~17:50
撰寫 UI 測試碼
(撰寫 Class UI 的測試碼時)
也晏提議: 既然我們後面有使用視窗的方式
去呈現成績分布，那前面這些訊息要不要也
用視窗來顯示?
子萲回應: 恩恩，那指令也可以用按鈕來呈
現吧
結論: 將 UI 介面改為 GUI 形式呈現
17:50~18:40 晚餐時間
18:40~19:20
撰寫 Ranks, Weights 測試碼
19:20~20:00
撰寫 GradeSystem 測試碼
20:00~20:40 休息時間
20:40~21:00 將單元測試碼內容作最後確認

~ 53 ~
5/16(四) 也晏家 20:00~22:00
製作並完成書面報告
20:00~20:30
雙人開發紀錄及結語
20:30~21:00
單元測試碼及封面目錄
21:00~22:00 最後校正及列印

~ 54 ~
第二週結語
------------Week 2 Ending------------
CRC 撰寫之心得
子萲
雖然一開始花了很多時間去理解 CRC 的定義，但是經過討論後，
也發現這種方式更能釐清每個 class 間的關連，讓整個程式架構
更有連貫性，而經由和也晏的討論，也能更加了解我們這次設計
程式的各種細節，因此我認為架構一個 CRC card 在撰寫程式裡
是重要的一環。
也晏
在這個工序，似乎有更多我們看不懂的專有名詞出現，當然，陳
教授只是來推廣敏捷方法，不能解說得很詳細，老師在這方面也
不多著墨，課本上自然是有它該有的進度，我了解，上了大學是
該好好培養自學能力，對於不懂的，要翻翻書、上網查，不該一
昧向老師請教。
這次作業，我是連 CRC 都不大懂意思，另外還有 CRC Card、
Header 等，都是半信半疑，不過我們還是抓得住一些東西，有
課本、有網路，我們是大學生，有這些，怎麼講我們都應該，要
能夠自行縮短與真意的距離才是。
這次雖然我們都不確定做的對不對，但我很確定: 在我們雙人開
發期間，每次的討論，都已經確實地讓我們的成果更加靠近正確
了。

~ 55 ~
CRC Header、派工時程之心得
子萲
這次把基本的程式碼寫出來，藉由對照之前寫的 CRC card，我
們更能在寫 mehod 時釐清它們與各個 Class 之間的關聯，但是
這同時也是這次所要完成的工序中所遇到的困難。
在撰寫程式碼時，內容跟 CRC 裡寫的又不盡相同，有的 Class
裡的 method 或增或減，在完全整理這些 method 間的關係花
了我們最多時間，不過完成後，藉由測試碼的輔助，也讓我們更
加了解這個專案的設計方向。
也晏
藉由寫出每一個 Data field & Header，對於每個 Class 的特質
與行為有更明確的界定，本次作業延續第二週而補，困難之處不
多，大抵也是工序的實際操作方面，如工序派工與時程，此道工
序以現在的情況，確實不大清楚怎麼實作，在方面也討論了很久，
也向同學、朋友、老師等請教，雖然最後仍然不大清楚，不過總
有個大概的雛型，亦算有所收穫。
此外藉由雙人開發，不斷討論下，對 Class 有更正確的寫作方向，
雖然改了一些舊有的設定，也是為了能讓 Class 的內涵更加適當，
也知道先前的討論並不夠周到，而我相信，這次教的作業也肯定
有錯，而我們將會不斷修改原先某些不恰當的設定，慢慢使城市
高品質。

~ 56 ~
單元測試碼之心得
子萲
在撰寫測試碼的過程中，本來以為只要寫出程式內的 method 等
主要架構就好，但其實是要把每一種可能結果都寫出來，所以必
須在我們原來的程式碼加上不少內容，但也因為這個緣故，我們
在這次的討論中能更加確定各個 method 的內容以及其運用，使
撰寫的過程有更明確的方向。
另外，經由我們的討論，我們決定將這套成績系統改為 GUI 的方
式呈現，如此一來可以省掉一些指令上的錯誤，整體版面也會好
看一些，而每次寫作業時都會再討論到上次的不足而進行修改，
使我們的程式有更好的設定。
也晏
因為本次做出一個重大變動，為了減少 Exception 的發生，特
將程式操作模式改為 GUI，直觀上明顯可以排除不少例外的發生，
卻也代表我們要重新思考 methods 和 data fields 的呈現方
式及相互關係，此處花費不少時間，不過也有所收穫，一是使例
外減少，去除了 NoSuchCommand Class，並將所有指令以
JButton 的方式呈現，二是使本次主題單元測試碼能更加清楚，
在減少大部分 Exception 後，測試碼就比較沒有 Exception 被
丟來丟去，對第一次寫作測試碼的我們比較不好表示的複雜情形。
此外，這次作業確定了 GUI 的呈現方式，往後的變動可能將大
幅減少，對於整個專案的寫作，算是整理出了基礎。

~ 57 ~
資料結構設計
--------Data Structure Design--------
程式碼
962001044 凌宗廷 87 86 98 88 87
ArrayList<String> allIDs = new ArrayList<String>();
ArrayList<String> allNames = new ArrayList<String>();
ArrayList<String> allRanks = new ArrayList<String>();
ArrayList<Double[]> allGrades = new ArrayList<Double[]>();
double test1, test2, test3, midterm, finalExam;
double wTest1, wTest2, wTest3, wMid, wFinal;
double totalGrade;
資料結構圖
Input File

~ 58 ~
All IDs ArrayList<String> allIDs = new ArrayList<String>();
All Names ArrayList<String> allNames = new ArrayList<String>();

~ 60 ~
All Grades ArrayList<Double[]> allGrades = new ArrayList<Double[]>();

~ 61 ~
All Ranks ArrayList<String> allRanks = new ArrayList<String>();

~ 62 ~
演算法設計
-----------Algorithm Design-----------
Main Class
Main method

~ 63 ~
UI Class
UI constructor
promptID method

~ 64 ~
isAnID method
showFinishMsg mehod

~ 65 ~
GradeSystems Class
GradeSystems Constructor

~ 66 ~
promptCommand method
showGrade method

~ 68 ~
showWeight method
showGradeGraph method

~ 69 ~
showClassRanks method
showWelcomeMsg method

~ 70 ~
Grades Class
Grades constructor
getIDName method

~ 71 ~
getGrades method
computeTotalGrade method

~ 72 ~
getGradesGraph method
showGraphT1 method

~ 73 ~
showGraphT2 method
showGraphT3 method

~ 74 ~
showGraphMid method
showGraphFinal method
showGraphTotal method

~ 75 ~
Ranks Class
Ranks constructor
getUserRank method

~ 76 ~
showClassRank method
computeRank method

~ 77 ~
Weights Class
Weights constructor
getWTest1 method
setWTest1 method

~ 78 ~
getWTest2 method
setWTest2 method
getWTest3 method

~ 79 ~
setWTest3 method
getWmid method
setWMid method

~ 80 ~
getWFinal method
setWFinal method

~ 81 ~
NoSuchIDExceptions Class
NoSuchIDExceptions constructor
NoSuchWeightExceptions Class
NoSuchWeightExceptions constructor

~ 82 ~
第三週內容修正
------------Modify Week 3------------
1. 將原本的 get…() 的 method 的名稱改為 show…()
getGraphT1() → showGraphT1()
getGraphMid() → showGraphMid()
getGraphFinal() → showGraphFinal()
getGraphTotal() → showGraphTotal()
getClassRank() → showClassRank()
由於 GUI 的視窗是建立在這些 methods 中，用 show 可能較一般的
get 自然而貼近 method 的功用。
2. 將 showWelcomeMsg() 自 UI 移動到 GradeSystems
showWelcomeMsg 意為“顯示歡迎訊息”，如此考量，此一 method
應置於 GradeSystems 中，且在該 Class 產生物件時即呼叫，較為合
理。

~ 83 ~
3. 將 allGrades 的型態 ArrayList<Integer[]> 改成 ArrayList<Double[]>
雖然 Input file 範例上的數值皆為 Integer，但搭配 Weights 所算出的
totalGrade 卻不一定會是 Integer，如此可能造成排名上的問題，為
了要將 totalGrade 存入 allGrades 中，使其名稱更符合實際內容，在
變數使用上較為簡明，管理也較為方便的考量之下，故將其元素
由 Integer[] 改為 Double[]。
4. 新增顯示成績分布圖的介面
我們原先的設定是只要使用者按下顯示成績分布的卻認按紐時，
便會顯示每一次考試的成績分布圖，但分布圖共有 6 個，如此一
來在顯示上可能會過度冗長，因此我們新增一個介面供使用者選
擇要顯示的成績分布圖，在使用上能更加方便。

~ 84 ~
第三週雙人開發紀錄
5/21(二)G315 15:00~16:30
討論資料結構
15:00~15:30
檢查 Class 的內容
也晏提議：顯示成績分布圖的 method 名稱
用 get 好像不太恰當?
子萲回應：那要用 show 嗎?可是這兩個聽起
來好像沒什什麼差
也晏回應：不，現在是以 GUI 呈現，所以用
Show 會更貼近這些 method 的
目的
結論：將原成績分布與顯示班排的 method
名稱開頭改為 show
15:30~16:00
設計資料結構
子萲提問：總成績是 double，可是原本的成
績型態是設 int，轉換上好像有些
麻煩…
也晏回應：那把變數型態都改為 double 吧
子萲回應：嗯嗯，那 ArrayList 裡也要改掉
結論：將 allGrades 的型態
ArrayList<Integer[]> 改成
ArrayList<Double[]>

~ 85 ~
5/21(二)也晏家 17:00~19:00
畫出資料結構圖
16:00~16:30
Weights & totalGrade
17:00~17:20
input file
17:20~17:50
Grades
17:50~18:15
allIDs & allNames
18:15~18:35
Ranks
5/24(五)也晏家 17:50~21:30
討論演算法
17:50~18:40
檢查 Class 的內容
也晏提議：showWelcomeMsg()應該要放
在 GradeSystem 內會比較好，
可以及時呼叫
子萲回應：嗯嗯，這樣好像比較合理
結論：將 showWelcomeMsg() 自 UI 移動
到 GradeSystems
18:40~19:10 晚餐時間

~ 86 ~
設計演算法
19:10~19:40
Main & UI Classes
19:40~20:25
Grades Class
子萲提問：成績分布圖是要一次顯示所有的
還是要給使用者選擇?
也晏回應：讓使用者選擇吧，這樣分開呼叫
也比較清楚
結論：新增一個介面供使用者選擇要顯示的
成績分布圖(此更改也已將之前的單
元測試碼一起做修正)
20:25~20:55
GradeSystems Class
20:55~21:20
Rank & Weights Class
20:20~21:30
NoSuchIDException &
NoSuchWeightExcetion Class
5/26(四) 也晏家 15:00~18:00
製作並完成書面報告
15:00~16:00
資料結構設計
16:00~17:00
演算法設計
17:00~18:00 最後校正及列印

~ 87 ~
第三週結語
------------Week 3 Ending------------
子萲
最近才剛接觸到 link list 等與資料結構相關的知識，因此一開始
對這個工序有著許多不了解，而我們目前所學到的，也只是很淺
的部份而已，其中有許多東西是需要我們自己去找資料，尋找符
合這個程式的設計方式。
而我們平常所寫的作業，常常是先寫完程式碼才開始打演算法，
但那也僅限於量少的程式，而這個小組作業跟平常出的作業規模
有著很大的差異，若將我們平常寫作業的方式用在這上面必定會
出現不少問題，因此必須先寫完演算法才能釐清每個 Class、每
個 method 間的關係，之後再補上程式碼，才能順利地將程式完
成。
也晏
差不多是最後了，本週的作業為資料結構設計及演算法設計，這
禮拜要將所有 Data 及 Methods 的關係完全了解且確定，才能
確保最後一週的 Coding 不會有 bug，因為前幾週的結果方向
很大，雖然轉圜容易，卻也代表要修正很多地方，壓力不小。
在一開始設計演算法時，我就看到了很多問題，並做了不少修正，
取名、新創 Data fields、Methods 的位置、Methods 的關係
等等皆或有更動。發現在設計演算法時，不單只是修正，更似乎
同時在設計資料結構，Methods 與 Data fields 間的關係在腦
海裡浮浮沉沉，漸而清晰。
本週雖然有點忙，但奠定了下週 Coding 的信心，收穫也不少。

~ 88 ~
補上程式碼
------------------Coding-----------------
Mian Class

~ 109 ~
NoSuchIDException Class

Grade System project(with Agile method)

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (15)

Featured

Featured (20)

Grade System project(with Agile method)