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 驗收測試案例

正常案例

~ 10 ~

~ 11 ~

~ 12 ~

~ 13 ~

~ 14 ~

例外案例

~ 15 ~

User Mannel 使用手冊

~ 16 ~

~ 17 ~

~ 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 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

NoSuchCommandException Main

~ 27 ~

CRC Headers

Mian Class

UI Class

~ 28 ~

GradeSystem Class

~ 29 ~

Grades Class

Ranks Class

~ 30 ~

Weights 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

~ 34 ~

UI Class (20 min)

~ 35 ~

GradeSystem Class (30 min)

~ 36 ~

~ 37 ~

Grades Class (40 min)

~ 38 ~

~ 39 ~

~ 40 ~

~ 41 ~

Ranks Class (10 min)

~ 42 ~

Weights Class (20 min)

~ 43 ~

~ 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 ~

第二週雙人開發紀錄 ------Pair Programming Week 2------ 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>();

~ 59 ~

Weights

Total Grade

~ 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

~ 67 ~

showRank 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 ~

第三週雙人開發紀錄 ------Pair Programming Week 3------

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

~ 89 ~

UI Class

~ 90 ~

~ 91 ~

~ 92 ~

GradeSystem Class

~ 93 ~

~ 94 ~

~ 95 ~

~ 96 ~

~ 97 ~

~ 98 ~

~ 99 ~

~ 100 ~

Grades Class

~ 101 ~

~ 102 ~

~ 103 ~

~ 104 ~

~ 105 ~

~ 106 ~

Ranks Class

~ 107 ~

~ 108 ~

Weights Class

~ 109 ~

NoSuchIDException Class

grade system project(with agile method)

Education