081225 課程回饋

2008/12/25 物件導向(OO)課程後，節錄以下回饋資訊

學習心得：
1. 講師提到的TestCase是我印象最深刻的地方..因為testCase關係也對自我程式的一種防火牆.在寫程式時就先考慮了各種可能的情況.
2. 專案開發時先確定最重要的部份ex:100個需求/20重要/5務必 最重要的5條需求務必要先出來.其他需求則是後面確定後再開發
3. 瞭解從需求訪談至系統上線的全部流程
4. 學習系統分析及系統設計的文件如何製作
5. 上課講的東西聽完是有感覺的，可是有感覺跟會不會是另外一回事，聽完之後覺得會的東西還真是少ㄚ，看來要好好充實自己一下了。
6. 專案開發文件部分，看起來很簡單，自己做發現還真的滿難的，我是覺得一來是要經驗累積，一來真的是要改變看事情的心態，因為我常常會以程式面來看專案，而不是以專案來分析功能
7. 對於程式部分，發現現在新的技術真是多，學完一種可能另一種又出現了，永遠趕不上；而且要把MVC架構表現出來，個人覺得不好實現，一句老話：還是經驗
8. 點醒了心中一些疑慮，讓我恍然大悟，原來就是這樣一回事。之前與同事到客戶那訪談需求時，心中所想的就是：我要怎麼解決問題，而非：問題有哪些，所以心中一直覺得怪怪的、開發的過程中也遇到很多當初訪談時沒有切確問清楚的部份，雖然進度如期，但是一路跌跌撞撞的。觀念與立場釐清之後，相信下一個案子會更順利。
9. 需求訪談的經驗分享讓我覺得受益良多，雖然說大致上知道可能會有哪些問題，但那僅只於技術上的，必須要站在使用者的立場思考，才有可能更深入的去問到使用者的問題；在訪談完分析之後再去列出相依性的的關聯來決定開發的優先順序，讓我覺得這是一個很棒的方法，之後的專案會讓自己以這樣的角度去切入寫出SD。

改善建議：
1. 目前自己還沒有一些想法,但是還滿想知道一些新的技術與應用方式的
2. 希望以我們實際開發的專案來做為教學範例，因為教材的系統範例往往比較簡單
3. 可否提供相關資料的研讀網站或書籍，可以讓我們繼續研讀

學習方向：(近來發現的學習方向，如果學會了，對我們這個團隊應該有幫助)
1. 可以試著使用TestCase方式來達到程式的穩定度.這樣對於整個的品質相信應該會有正面的效果.也減少錯誤發生的機率
2. 我需要養成良好的寫程式的習慣,以及努力學習自我本身coding的能力
3. 學習如何利用tool節省製作文件的effort
4. 學習如何準確分析需求、闡釋需求內容，讓系統從分析至開發階段不會有落差
5. 學習Junit測試工具的使用，這樣因該可以將Bug降到最低
6. 學習UML，至少要看的懂圖示

OOAD CASE [會議室預約管理]

物件導向分析設計，這是多大的題目阿，習慣上，大家可能會從物件導向的概論開始談起...最後才會切到實務，從邏輯推演的角度去看，這樣比較有次序，但，卻不能滿足即時的需要，所以，這裡從案例出發，各位在看簡報之前，請先從自己習慣的方式去設計，待初步設計完成後再對照這份簡報吧！以下是CRRS會議室預約的題目：
1. 有 20 間會議室可供預約
1.1. 基本設備不同
1.2. 可容納人數不同
1.3. 可預約時段為 08:30~20:00, 以 15 分鐘為單位
2. 有 8 套投影機可供運用
2.1. 預約會議室成功且會議室沒有安裝投影機, 才能預約
3. 預約時, 須記錄與會人數、會議主題、 時段、預約者姓名、 部門、職稱、聯絡資訊等
4. 會議室皆被預約時, 使用者可要求加入先進先出的排隊名單
5. 取消預約時, 系統會依先進先出通知排隊者
6. 使用者可查詢會議室使用情形
7. 管理者可調閱會議室使用紀錄&報表

提醒 : 看簡報前務必先自行做設計，最好能用程式碼去驗證自己的設計!!!

Spring MVC

Spring IoC & AOP 基本概念與運作原理, 同時介紹 Spring MVC 的簡單用法



後語：最近 Spring 又發行了新版，有興趣的人可以去下載，有趣的是，Spring 似乎不再是輕量級...這種發展，是否合乎 Spring framework 的初衷？這種發展是宿命？你會採用哪種觀點...

UML Overview

學習 UML 過程中, 免不了要整理這些圖, UML Notations / Diagrams 是溝通的基礎, 即便是簡單的一張圖都代表了許多的意涵, 重點是解讀的人, 大家是否具備相同的認知基礎? 學習 UML Notation 的語意, 就像學了軟體世界的共通語言, 也像學習一般外語, "使用"才是真正的"學會"

這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"



衍生閱讀：敏捷塑模

UML 案例 <3> 元件圖

UML Component Diagram 設計案例

圖 1、電子商務 Component Diagram

圖 1、電子商務 Component Diagram是筆者過往曾經做過的項目(專案)，各位可以猜猜這張圖是在專案執行過程的哪個階段製作的? RA、SA、SD、DEV…哪個階段呢? 答案將在最後的結論當中揭曉。

對很多人來說 Component Diagram 代表的是靜態結構的組成，用來表達的通常是系統、子系統與各個模組之間的關連性，私下跟許多友人探詢後，發現很多人都覺得這類的 UML 圖型較不常用，更意外的是，這麼好用的圖例，很多人根本沒在專案中用過它！這是怎麼一回事？為什麼我每個專案都一定會出現至少一次的圖，卻在其他人的專案中鮮少出現？到底是哪一方面出現了差異？

先解釋一下這張圖好了，圖中有1) 產品結構管理模組、2) 訂單處理模組、3) CRM 資料交換模組、4) 授權處理模組、5) 物流處理模組、6) ERP 資料交換模組等六個模組；每個模組負責的主要功能分別用不同的介面分別定義，例如產品結構管理模組必須具備1) 商品結構定義、2) 替代商品維護、3) 商品資料查詢等三大功能，其他模組也有各自具備的功能，個模組之間的相互串連則透過相依關係去表達，從圖例當中可以看到，訂單處理模組將會使用到產品結構管理模組的商品資料查詢，而物流處理模組則會使用到訂單處理模組所提供的各項功能。

註：由於筆者所使用的免費工具目前尚無法完整表達 UML 2.0 的圖例，所以，採用相依關係，一般而言本相依關係可以換成 UML 2.0 的 Required Interface

從Component Diagram的結構當中，我們可以清楚的了解到各個模組之間的關連性與每一個模組的功能特性，也就是說，這張圖表達了本專案應該要完成的功能與範疇(Scope)，各位讀者如果花一點點時間去看這張圖，大概也可以猜出這個專案到底在做甚麼了吧？這就是筆者堅持要畫這張圖的原因之一，讓第一次專案團隊能對專案範疇有正確的概念，也知道類似的功能要放在哪一個模組裡頭。

另外，這張圖對筆者而言還有另外幾個重點，其中一個重點是適度切割功能，如果系統的功能無法被適度切割，我們怎能確保自己不會迷思在一堆的需求當中呢？就像在一團打結的繩索中抽絲剝繭，這是一個過程，不但能確實釐清專案的各種需求，也是確保專案不致迷航的一盞明燈。

第二個重點是，釐清元件之間關聯性，Component Diagram結構當中的相依關係代表者元間之間的依存度，這樣的依存關係也可以作為開發時程的重要參考依據；例如：物流處理模組需要使用訂單處理模組，訂單處理模組需要使用產品結構管理模組，本例的合理的開發次序是 1) 產品結構管理模組、2) 訂單處理模組、3) 物流處理模組，人力與時程安排便可依此為佐證。

在釐清元件之間關聯性的過程中，還可以協助分析設計人員找到系統可能發生異常的部分，下圖是典型的循環相依案例，從圖例中，我們看到訂單處理模組需要CRM 資料交換模組，CRM 資料交換模組也需要訂單處理模組，如果系統採取這種設計方式將可能導致日後無法抽換其中任何一的模組，因此，設計人員必須解構 & 改進這方面的設計，如此才能提升系統的穩定度並增加日後擴充的彈性。

圖 2、循環相依案例

最後一個要點是其他文章中提到的 “測試優先”，有了功能分割與元件化設計之後，測試也能聚焦，每一個模組都可以有足夠的測試案例去維持該元件的品質，後續整合測試就會相對容易，投入的人力、物力與時間也會比較容易掌握，相對的，客戶將會更加滿意專案的執行成果。

結語

回到文章剛開始的問題，猜猜這張Component Diagram是在專案執行過程的哪個階段製作的? 答案是一開始的企劃階段，企劃階段製作 Component Diagram的好處很多，希望各位透過本文能有所認識，趕快開始善用這張圖吧！

關於適度切割功能這點，筆者的期待是，適度切割功能達到可重用(Reuse)的地步，可重用的概念一直是軟體設計與開發者期待物件導向能帶來的優勢之一，但是我們怎樣找到可以重用的元件呢？

如何解構循環相依？請各位讀者自行思考囉，日後有空再跟各位分享囉。 ^_^

強力推薦：敏捷溯模(Agile Modeling)

UML 案例 <2> 代理人關係

希望用物件表現出“某乙是某甲的代理人”，要怎樣表現其關係呢？

圖一、如何表達某乙是某甲的代理人？

圖二、代理關係(A)

圖二為最安全的表達方式，用簡單的 association 表示出委託人與代理人角色，這樣的表示方法如果用在概念傳達是有效的，但如果是實作的用途則明顯不足，人員與代理關係物件雖然有關聯性，但這樣的關聯要由誰維護？是人員要管理這兩條關聯還是代理關係要維護？亦或是個別管理一組關聯性？如果是個別管理一組，那又是由誰管理委託人？由誰維護代理人？

圖三、代理關係(B)

圖三是利用具方向性的關聯來表達出代理關係，這種表達方式較為精確，除了能夠表達出代理關係的概念之外，也能清楚表示委託人與代理人之間的實作方式。

從實作層面看，委託人(人員)物件必須管理代理關係物件，而代理關係物件必須管理代理人(人員)物件，因此，委託人透過物件之間的關連性推演可以知道其代理人為何者，推演案例：某甲(委託人物件)代理關係物件某乙(代理人物件)。看到圖三的案例後，或許有些讀者會認為這就是表達某乙是某甲的代理人的標準答案，如果是以重新開發與設計的角度去看，也許是不錯的設計方案；請各位想想如果整個情境變成是在既有系統當中增加新的代理人機制，這樣的設計方案會有何種影響？

圖四、代理關係(C)

如果要在既有系統當中增加新的代理人機制，或許我們會採用圖四的案例，委託人與代理人物件都由代理關係去管理，實作過程中可以不用改寫人員物件，也可以達到擴充代理人機制的目標，不但可以增加人員物件重用(Reuse)的次數，也可以降低修改或重新開發程式的成本，可謂一舉數得。

一個問題可以有多種的解決方案，是不是覺得很有趣？還是你一直希望我能提供一個標準答案給你？看過了以上案例後，請各位讀者思考一番，或許你還可以找到更多的解決方案呢！

結語

這篇文章並不是要強調UML或者OOAD，也不希望各位誤以為這裡講的就是標準答案，不同的領域專家或許會有更好的見解！我要強調的是技術解決方案(Technical Solution)是因應需求而生，同樣的需求能衍生出不同的解決方案，有些方案易維護、有些方案可以有效降低建置成本…，了解需求、掌握需求才能提供適切的解決方案。

強力推薦：敏捷溯模(Agile Modeling)

軟體設計思維

彙整這些年來的軟體設計想法, 在這當中有很多觀念, 有些我們都知道了, 但也有些並沒有被大家重視, 整理這些資料主要是希望能有拋轉引玉的效果, 或許, 各位有更多的心得也可以提出來分享 & 討論

1. 本職學能應該掌握哪些?

Programming Skills

Object Oriented Concept

MVC, Model-View-Controller

UML, Unified Modeling Language

Quality Control

2. 進階知識涵蓋層面?

Advanced Programming Skills
Refactoring, ORM, XML ...

GoF Design Patterns

Quality Assurances

3. 提供哪些專業服務?

Concept Abstraction

Business Solutions

Domain Knowledge

強力推薦：敏捷溯模(Agile Modeling)

UML 案例 <1> UseCase

本電子商務用例展示了簡易版的電子商務使用情境，當中可以看到有三個主要的 Actors 分別是 Guest, Administrator 與 Payment GW，這邊特別要說明的是，Payment GW 並不代表特定角色的人，Payment GW 指的是提供金流授權服務的外部系統(例如:信用卡刷卡機)。

另外，就是所謂的 Extension Point ，從圖例當中可以知道，在特定情況下會需要用到擴充的用例，如金流授權處理是信用卡付款方式的擴充。


強力推薦：敏捷溯模(Agile Modeling)