Y16 First Practice(1)──檔案轉換程式

月初時有個檔案轉換程式交給我來開發，系統功能是要能匯入主機電文XML後提供編輯功能，再根據公司的系統框架產出相關的設定檔。這對我來說並沒有什麼難度，但是主管就長期的影響來看希望應用RUP的方式開發，期限就從四週延長為八週。（記得看過沒設計與有設計的開發時程大約是1:3的說法，我應該要求十二週才對的）

雖然之前已經上過RUP的教學課程，也算熟悉UML工具的操作，但是真的動手要做出精確的產出時才發現自己對許多細節的觀念並不清楚。由於平時習慣將需求在腦中直接消化為程式碼，無論是需求階段、SA階段或是SD階段我都不時直接出現完整的class細節；當內容在不應該出現時冒出來，接著就會感覺到有窒礙難行處，這些不適當的內容都經由不斷地討論與調整加以修正。

慢慢領略到RUP的精神，同時也發現我們之前口中所說的專家理論其實是根據許多實作經驗後抽取的精髓。例如以一個Use Case來說，我們可以根據結果的描述直接寫出程式碼跑出符合的結果，但是專家們將之縱向切割為需求、分析、設計、實作等階段，每一階段都有自己的作法與產出傳遞到下一階段，同時在每一階段都平行考慮所有的Use Case一併考慮。只為一個Use Case寫程式碼的同時，時常擔心這些程式碼會不會因為下一個Use Case而有大變動，收集完全部需求後再作考慮不失為一個好方法。

在進行的同時，倒是有兩處令人頭痛的地方，希望在工作完成時能有新的領悟：
●記錄會用很多時間
　需求階段製作每個Use Case的Activity Diagram、每個Activity在分析階段要繪製Class Diagram、到設計階段要再調整，每一個步驟真的都需要很多時間。目前只有我一個人做。
●記錄追溯會用更多時間
　上一階段的一個Class到這個階段可能為了某個原因變成三個Class，這個變化必須填寫追溯表；某個Use Case分析設計使用到一些Class（的Method），要如何記錄這個使用關聯？反過來想，又要如何記錄某個Class（的Method）總共在哪些Use Case內被使用呢？