上個月我在「工研院」授課時,其中一位較為資深的程式開發人員問的問題: 我感覺不到寫好使用案例 (Use Case) 有什麼好處?
別誤會,這位年輕的開發人員並沒有惡意,我也認識他一陣子了。他的確是有感而發,覺得在工作上,從以前透過一般的需求規格書,到現在開發時導入 使用案例 的分析需求技術,但是,他並沒有感受到因為這樣而有加快程式撰寫的速度,反而還覺得縛手綁腳,經常需要受到規範。
這個問題,可比想像得還難以回答。 是為了可以有效保存需求分析的資產? 還是為了系統的彈性 (flexibility)? 前者似乎有道理,但如此對現在正進行的開發專案好像沒有說服力,甚至開發人員還覺得為了要補足這些需求文件,反而拖累了開發的速度;後者的系統彈性問題,我則是很確定與寫得好需求分析文件沒什麼直接的關係,彈性度的考量,與軟體的結構設計 (structure desgin)才是更主要的關鍵。
思考許久,我是以為,寫的好使用案例最直接的關鍵是: 影響到專案開發整個流程的節奏!
以使用案例為導向 (use case driven)的開發模式,我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性,幾乎是偏以需求為優先。而使用案例的分析,其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式,後者的功能模組,耦合性 (coupling) 太重,容易牽一髮而動全身,所以在需求分析階段,會耗費許多時間在分析共用模組的考量;而使用案例,是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例,都可以看待成是系統在某一段期間 (session),可以滿足使用者使用系統的目的。 所以每一個使用案例,是可以個別被獨立開發,也就是說,UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量,則是延宕到結構設計階段再來討論即可。因為在需求分析階段,不用花太多時間在共用議題的考量上,所以可以很快速地實現 (realize)功能需求。
能抓得好與定義得好一個一個的橢圓使用案例,就能以該使用案例為開發單位。 這麼說好了,甚至可以把該使用案例就當成是一個迷你系統,然後來串連出整個開發的程序與產出。 例如,針對一個使用案例,就會設計一個位於中間層 (middleware)的控制型物件 (control object),並從使用案例的敘述 (use case description)中,找出該物件應承擔的行為 (behavior),然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為,就可以知道需求分析是容易並可以無縫式地轉移到實做階段,並快速地界定出程式碼的骨架 (sketletion),再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。
從中間層的控制物件來做為實現使用案例的中心,要提供給使用者操作的畫面,或是再橋接 "web service" 物件,提供給外部系統自動存取,這也是所謂的 SOA (service-oriented architecture)、以需求為導向的架構,都很容易被實現的;而對內就是為了實現使用者交付的需求,需要連結至資料庫或是外部系統,只要再加上所謂的 "DAO (data access object)" 與 "adapter" 助理型的物件,將實際連結的工作,委交給這類助理物件,分門別類、井然有序,是非常容易控管的。
再則,規劃好控制物件的骨架,馬上就應該撰寫測試程式,以確保程式開發的品質。而這類功能性的測試 (functional test)程式,更是可以作為系統驗收的主要依據。 而測試程式的來源為何? 就是測試案例 (test case) 與 測試數據。 而這些仍都是以使用案例為中心,每一個使用案例會撰寫最少兩個以上的測試情節 (scenario),並在其內填上測試的數據與預期的測試結果。
寫好使用案例的好處,族繁不及備載。越大規模的專案,更能感受到開發節奏的順暢度。再加上 "漸進循環 (incremental and iteration)" 的開發模式,會越形容易謀和在系統開發期間,人與事的種種…。
對了,上述的論述,有沒有說服到那位開發人員? 當然是沒有!
為什麼? 若比較是站在局部 (part)個別的角度來看系統開發時,尤其是對程式寫碼人員,寫不寫的好使用案例,對他沒差;只有當站在係以專案整個全局來看時,例如專案經理或軟體架構師,則會有明顯的感受。這也是在我們輔導的過程中,為什麼反而專案經理的接受度就很高的原因了。
那麼到底要如何說服呢? 我從來都不認為需要說服! 這裡我就引用 Martin Fowler 在「UML Distilled」一書中曾經說過的:
「你只能強迫新手們這麼做。過了幾年後,他們會突然恍然大悟,然後腦袋彷彿重生!」