寫碼才是確保 UML 分析/設計的信心來源!

這兩天與 Ringle 一同至高雄某家規模蠻大的專案開發公司,從年前兩日的 UML 課程教育,然後年後第三日係以座談的方式,面對面聽取學員們在實際專案開發時,利用 UML 設計時,所遇到的問題,同時並檢驗他們的設計產出是否正確與適當。其實呢,算起來也有半顧問的意味,當場就拿出他們利用 EA 所開發的設計圖,檢驗、評論、說明,然後協助直接修改,甚至轉出程式碼。

我覺得學員們真的很認真,讓我有些訝異,在年前只上過短短的兩天 UML 基本課程後,竟然在一個月的時間,就已經將某一系統的需求訪談記錄建構為使用案例圖,並且還產出系統分析的類別圖與循序圖,就只差程式碼還沒出來而已。

一整天的座談,就針對這些設計產出來 “指指點點”,說明他們在 SA/SD 設計的一些茫點與比較顯明的謬誤。但大致上,我們到蠻給予高度肯定的評價,重點是有沒有 “心” 要做,其它的都還是次要而已。他們專案經理,也非常認真,提問了很多的問題。我發現到,都比較偏向是專案管理面的範疇,諸如設計產出是如何承接、由擔任什麼角色的開發人員負責、該如何 “檢驗” 他們設計的品質 …等等。專案經理重視 “制度”、”製程” 等,那也是當然的,不過,到讓我發現到,一個很明顯的問題:想太多了。 這會導致在分析/設計階段因瞻前顧後,花太多不必要的時間在小細節上,而陷入了「癱瘓(paralysis)」

如同寫文章,越想求完美的人,越不容易動筆。分析/設計 也是如此,就是因為想要 “分析” 更精確、”設計” 得更完美,讓系統開發規格更明確 …這些心理因素的作祟,而導致在某個開發的局部就 “僵住”,好像是動彈不得、陷入瓶頸的感覺。

何以見得? 答案太明顯了:程式碼沒有出來!

傳統 SA/SD/PM 最大最大的一個茫點是,如果沒有開立明確的系統分析與設計的規格,包括 Database Schema,那如何能讓程式人員寫碼呢? 這不就是傳統 “Waterfall(瀑布式)” 開發流程的詬病? 許多軟體公司以為,採用如 RUP 先進、國際標準典範的開發流程,就會從 “瀑布式” 的開發魔咒解套,問題是,當你把 SA/SD 拉長數星期以上的開發,才開始展開 “Implement” 的實做階段。這種方式,如同 “藍皮綠骨”,根本還是 “瀑布”,因為,RUP,甚至是現今必然要嚴謹遵循的開發原則,最重要的一個精髓之一: I&I (Incremental and Iteration),根本沒有確實實踐。

從需求分析、設計、至實做,甚至包含測試,要花多久時間? 我與該公司 PM、系統開發人員說,完成一個使用案例的實現,第一個 Iteration 不能超過三天。 他們聽了覺得挺不可思議的。怎麼可能?

唉,為了證明,所以,又要請出我們的 “呂布” 級戰將 Ringle,將他們系統的一個使用案例,從頭作一個分析,補充上使用案例敘述、設計類別圖,描述循序圖,然後利用 EA 的 “Code generator” 功能產出程式碼框架到 Visual Stuio .Net 的 C# 專案,再補上一些虛擬碼的註解,同時又加上功能測試程式碼。第一個 Iteratin,整個過程,還不到兩小時。

第一個 Iteratin 當然不可能包括完整的屬性與行為細節,那並不是第一個循環要關注的事情。即使資訊不足、流程不明確,一旦確定使用案例的目標(Goal),就應該快速跑過一次 RA/SA/SD/Implement 等開發階段,用最短的時間,完成可以執行的程式碼。如此,最重要的幾個目的就能達成::增進團隊整理信心、建立系統雛形結構、快速取得回饋(Feedback)。:

這麼說好了,確定目標(使用案例)、找出達成目標的手段(分析/設計)、馬上執行與測試(Implement and Test)、問題收集與回饋,這才是 “Iteration” 的真諦。

況且,程式碼是最現實的產物,客戶、老闆眼中一定要看到程式碼,才算 “眼見為憑”。我一直傾向是要在最快的時間內,一確立實作的目標,先經過簡單的設計(Simple Design),就要快速產出可執行的應用程式碼以及功能測試碼,這才能確保軟體分析/設計的信心主要來源。

請記得,世間沒有一開始就是完美的事,分析/設計更是如此。我從來都假設需求不明確、企業流程有問題,但只要經由需求分析確立目標,就可以馬上著手系統分析與設計,當然也就可以立即產出程式碼了。當有個 “框” 之後,再來才是逐步修正細節,包括企業規則與邏輯等。 (當然,也不可能無限上綱,永無止盡的 Iteration。過與不及,均不妥。)

分析/設計,甚至包括程式碼,都只是手段,既然是手段,當然不需要太重視,因為手段會時時視需要調整與修正的。我最重視的是原則,什麼原則呢? “把握當下,泰然面對無常”!

不要從程式語言學習「物件導向」!

許多技術人員係從物件導向程式語言(OOP, Object-Oriented Programming Language)來學習物件導向,從 OOP 的角度來學習物件導向時,經常會把它當作是一種 “技術”,當作 “技術” 時,你會想去 “用” 它,而若當你無法 “應用” 在現實面時,就會覺得 “不好用”、”難用” 、理論無法與現實結合” …等。

把物件導向當作 “技術” 的最大的問題是:你永遠不知道為什麼你要使用物件導向!

幾年前,微軟的 COM 剛盛行時,有些是 “微軟技術代言人” 會在其技術文章裡提及:COM/3-tier/物件導向技術是增進系統效能(Performance)的最佳解決方案;採用上述提及的技術可以加速系統開發。甚至到現在,我仍常聽到:採用 EJB(Enterprise Java Bean) 是實現物件導向的最佳利器、可以讓開發者 “ReUse” 所設計的元件(Component)、節省開發者的開發時間。

嘿,這些 “似是而非” 的論調,幾年前從技術人員口中聽到是如此,現在聽到的還是如此,說真的,我是覺得,還真是一點自我的反思都沒有。我每次對這些技術人員的反駁就是:有什麼方式會比 Client/Server 直接連線至資料庫來處理還要快? 有什麼開發方式會比你使用 Client/Server 拉一拉表單,然後直接至資料庫 “撈” 資料還要便捷? 當然,技術人員的直覺反駁是,Client/Server 無法應付數百人以上同時間的交易處理,是啊,沒錯啊,Client/Server 有些假設點:同時上線使用者不超過 200 人、系統的需求不常變動。

但,重點是,系統效能與你採用 COM/EJB/物件導向有何關係? 那是屬於系統資源(Resource) 的控管處理,諸如 Resource Pooling 的機制、Transaction Management(還包括交易物件的設計)的處理,Database “Performance Tunging”、頻寬的資料傳輸量的處理… 等。

而採用物件導向/COM/EJB 可以節省系統開發? 那更是可笑! 採物件導向可更是耗費開發成本,開發人員每當一想到為什麼要在中間層對物件分門別類,然後實做一個功能要串上好幾個物件的傳遞才能完成工作,一直無法接受這種觀念,如同 Martin Fowler 所提:你永遠無法讓物件導向的新手們瞭解為什麼要採取這種分散式的設計,你只能要求他們如此做,幾年後,他們會突然頓悟,腦袋有如重生一般。所以,採取物件導向可是要花腦筋在軟體設計上,而且若是實做在所謂的實體元件的機制,如 COM+/EJB,那是為了系統分散與交易機制的處理的元件規格,所以,實做上可是更為麻煩,一點也不會減輕開發者的實做的負擔。

所以,為什麼要使用物件導向? 因為,物件導向是一種思維,是一種哲理,是一種典範,甚至是一種生活觀,你需要綜合相當多的知識,蘊化為 “智慧”,來協助你如何應付與應對軟體的 “善變”,並能提供具體的解決方案。嗯,這兩年突然對軟體設計某小一部分的哲理有一些 “頓悟” 後,每當看到許多系統因為粗製濫造而衍生出複雜的表象,眾多人們卻被淹沒在糾纏不清的問題與狀況時,而個人(外加 Ringle) 卻能 “一眼” 看出問題在哪裡,並且可以提出具體的解決方案,嘿,那可真是莫大的成就感與喜悅的呢。

學習物件導向的思維與哲理可是一條漫長之路。對我而言,我個人是已經選擇了這條 “自討苦吃” 之道,這條道路所要學習的廣度與深度,可是與圍棋之道一樣的深奧無比,每一個階段的學習與體悟,會讓你更接近與探索根本道理,但,似乎又永遠無法達到那個 “彼岸”。如同吳清源大師已經快 100 歲,仍舊每天研究圍棋;Ivar Jacobson 已經 80 餘 近 70歲,卻仍茲茲不倦地研究與發表軟體設計的論述一樣,這是終身職志,已經是融入每天的生活,永遠也研究不完的,甚至,還準備帶到下一輩子繼續來「修道」的。 😉

所以,回頭來看物件導向程式語言,OOP 僅是實現(Implement)物件導向的工具,你會想透過 Java, VB.NET 等程式語言來實作如介面(Interface)、繼承(Inheritance)、多型(Polymorphishm) …等設計。但問題是,OOP 無法告訴你 “What” and “Why” 介面、繼承、多型等這類屬於設計的哲理面(philosophy),甚至,也無法告訴你 “What is Object?”、”How to divide the Object?” …,而這些哲理,根本不是為了重覆使用或增進效能,目的旨於,協助人們在面對複雜的現象時,應用 “本來就有” 的智慧哲理,來解決複雜的問題,而 OOP,是讓軟體人員解決問題時,所需使用使用到的 “工具”,它就是工具,就是一種手段而已!

從 OOP 學習物件導向觀念是一種本末倒置的方向,那不會是一個好方法,若勉強說,利用 OOP 來 “驗證” 物件導向的一些設計想法,那到說得過去。那麼,從何處學習物件導向呢? 我這兩年,是透過 “觀察” 生活的週遭環境,逐漸來反思與體悟的。這與我多年來閱讀許多大量其它領域的書籍,除了軟體設計專業書籍外,包括學習類、成功潛能類、企管與專案管理、歷史 …等,實在有莫大的幫助,對短期的軟體技能幫助不多,但對中長期在軟體設計的思考上,會突然在某一個時間點突破而後 “頓悟”,這時再回頭看軟體專業各類的書籍,那可真是遊刃有餘,輕鬆而能感受書中的作者所想表達的觀點與主題。

對初學者,若要更具體一點,要看相關這方面的書籍的話,除了上次介紹過 Grady Booch 的「Object-Oriented Analysis and Design」一書外,國外的一些書籍,例如 James Martin/James J. Odell 合著 「Object-Oriented Methods」 一書,除了內容淺顯易懂、又饒富物件思維之道外,書籍排版與印刷的精美,那更值得典藏的好書。有件事最好避免,國內坊間 OOP 的書籍,有談及物件導向觀念的,最好略過不要看,幫助不大,反而誤導成分居多。

有感而發,既然,Java and .NET 都已經昭然若揭,程式語言確然往物件導向的實做之路,那麼,軟體人員也確實需要俱足物件導向的設計觀念。隨著工具的易學易用,以及網際網路龐大的資料庫,成為實做 “how-to” 的最佳參考來源,使得實做得以更形簡單。那麼,軟體人員更需要將精力擺在物件導向的設計思維,才有可能應對越形複雜的系統,懂得如何以簡御繁。

所以呢,我個人準備把我這幾年的一些心得與體會,儘量利用日常生活面的例子,來解釋物件導向的一些基本觀念與術語,例如,什麼是物件/類別、什麼是介面/多型、什麼是封裝 …等。我會將這些文章另行分類成 “物件基本觀”。對了,有一些議題我會採反問的方式來闡述一些個人的物件觀。例如,若你要問我,EJB 是不是物件導向? 我會說 “不是”;然而 Client/Server 是否是物件導向?,我的答案卻是 “Yes”。 呵呵,先賣個關子,這些是蠻有趣也蠻引起爭議的話題,爾後我會著文說明我的看法與理由的。

軟體的模組化(Modulize)設計應該要徹底實踐!

在上個月看 Discovery 節目時,該節目很有趣,是介紹有史以來,前 10 大受歡迎與戰鬥力強的坦克車。

嗯,還是從二次大戰開始介紹的呢,其中,包括德國的虎式與豹式坦克,都名列上榜,而更為驚人的是,蘇聯的 T34,當時在德蘇大戰中叱吒風雲,令德軍第一次感受到他們的武器不如人,是名列 10 大中的第三名。而至於第二名的坦克,則是活躍於波灣戰爭中,但卻也有令人苦惱的問題,太過龐大與吃油量太重、維修不易等問題。

嗯,這要與我談軟體模組化有何關係呢? 嘿,當我看到榮登 Discovery 第一名排行榜的坦克時,實在驚訝與讚嘆不已。榮登第一名的是:改良過的德國製坦克 — 豹式二代。

話說原來,當時二次大戰中,德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能,而加以參考並改造他們的坦克,當時就有豹式坦克的出現。但是,豹式坦克雖性能優異,且砲火猛烈,但是,太容易故障了,而德國人龜毛完美的性格也反映在該坦克上,加上太多不必要的束縛與修飾,而這些,是在激烈的對戰中,大部分是不需要的。

而今的豹式二代,仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格,但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢?在所有前 10 大坦克中,也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化!

我看了節目的展示,嘴巴合不攏嘴,實在驚訝不已。豹式二代一旦發生故障,維修人員只要拿出筆記型電腦,連結坦克的介面,即可以診斷出坦克的那一部分出了部分,再來呢,不是去拆開出問題的那一部份,而是,整個模組抽出來,就好像診斷出 PC 的顯示卡或記憶體模組出問題後,拔出來,再把新的給置換進去即可。我第一次看到,坦克的模組化設計,也能造成這種 P&P(Plug-and-Play) 的可抽換效果。

回歸軟體,看到好多產品都號稱是 “模組化” 的設計,每次呢,我到世貿軟體應用展,只要問展示販售 “進銷存” 產品的廠商,能否將 “進貨” 模組,與某家或是本來公司內部既有的 “存貨” 系統給 “兜” 在一起呢? 嘿,得到的解決方案就是利用 “資料庫” 來作系統整合。

而以資料庫為整合的解決方案,我就很清楚了,這些號稱是模組化,根本只是在業務層級的邏輯面,卻沒有確實在實體的系統面,達成模組化的設計。若要能達成在實體系統面的模組化設計,必然是首重於介面(Interface)的設計與溝通,至於資料庫,只是各個模組的 “私有倉儲(private storage)” 罷了。以資料庫為主的整合,是屬於 “草本植物” 式的整合,雜草叢生,而根卻早已彼此糾纏不清,剪不斷、理還亂了。

連龐然大物般的坦克車都可以確時達成模組化的設計,怎麼這些軟體產品,談模組化這麼久了,卻仍是用幼稚的資料庫整合方式,而無法確實分隔每個可被抽離與置換的模組,並且可以很容易地利用測試工具找出是那個模組出問題,乾脆就直接把壞的模組給 “抽換” 掉呢?

建構領域概念模型的來源—Y型結構理論

影響軟體資訊系統彈性度的最基本根源在於結構(Structure),而結構的核心又源自於從問題領域(Problem Domain)的專業術語中,擷取其本質(Essential)與彼此之間的關係,所建構的概念模型(Conceptual Model),而後再依此概念模型來制訂更具體規格、與平台相依的軟體模型。

建構問題領域概念模型的參考來源(Source),主要有兩種:

  1. 需求訪談記錄、使用案例(Use Case)敘述等。
  2. 從與領域專家(Domain Expert)的溝通中,擷取問題領域的核心(或稱之本質)。

第一種方式,訪談的對象大都以系統的操作者(Operator)為主,敘述的紀錄中,所擷取的術語,幾乎以名詞為主。E-R(Entity-Relationship) Model 的系統分析者,多數會以此種方式來找出 “Entity”,作為建構 E-R 模型的單元,而類別圖(Class Diagram),也可以此手法來塑模(Modeling)。

此種塑模的方法最重要的關鍵在於:如何紀錄並組織明確、有效的需求敘述,依此建構概念模型,來滿足操作者使用系統的期望。

第二種方式,訪談的對象是以領域專家(Domain Expert)為主要對象。從專家的角度,比較能看到高於一般系統操作者的局部觀點,比較能得到整體性的企業流程(Business Process)與企業邏輯、規則等。系統分析師(SA, System Analyst)則是需具備高度的抽象能力,懂得在與領域專家溝通的過程中,擷取該領域最重要的本質,並以此來建構概念模型。

應用一些軟體設計的抽象技巧與樣式(Pattern),例如 “交易樣式(Transaction Pattern)”,SA 很容易擷取出各領域以交易為核心的術語,例如 “採購”、”註冊”、”看診” …等,均為各領域中,最為核心的交易術語,再以此為延伸,關連此交易的 “人”、”地”、”物” …等。

此種塑模的方法最重要的關鍵在於:SA 需要具備軟體設計的抽象思維,包括對封裝、繼承、介面的正知與正覺。同時並懂得如何與各領域專家溝通的柔軟身段與技巧。

以上兩種的塑模方式,是可以相互互補的。與領域專家的溝通,容易擷取出該領域的核心本質;而從需求訪談的紀錄,可以得到操作者需要的細節。

可以以下圖的 “Y 型結構” 來表達出建構領域概念模型的來源,是源自於以上兩種塑模方式的互補。

Y型結構—建構領域概念模型的來源
圖、Y型結構—建構領域概念模型的來源

ˇ延伸閱讀:
利用 Transaction Pattern 快速捕捉問題領域內的概念物件」。

JavaScript 是爛東西?

下午在某家公司討論架構設計的顧問服務時,與該公司主管會後的閒聊,其中一個話題,就是聊到 JavaScript,我又不假思維的回答:JavaScript 是爛東西。

啊!我亂說話的毛病又犯了… :-/

前兩年,也是在某家軟體公司所承接上億元的案子上,當時我是某家顧問團隊的 Member 之一。在與該公司數十位軟體開發人員的顧問輔導會議上,我也是直接就講出這句話,當然,我會去說明認為爛東西的理由。不過會後,我們團隊其中一位 member 很不高興,認為我不應該如此的批判,還有一個重點,當時,他是負責教授學員們 JavaScript 設計的講師,他說了,如果我對未來會上課的學員直接批判 JavaScript,那他如何教課呢? 是滴~ 不過當年我 “年輕氣盛”,就與他說了,那麼,我們課程互換,他來教授高階設計,我來教授 JavaScript,然後,也允許他直接批判 JavaScript。;)

這是之前的往事了... 想起來還是蠻有趣的一段話題。

對 JavaScript 印象不好的原因,源自於 ASP/JSP 網頁設計的時期,其實,我也很清楚,程式語言本身,那有什麼爛不爛的,會爛的原因是… 程式設計師把它變成爛東西了。 :>>

這怎麼說呢? 我看到好幾位的程式設計師,因為非常不習慣於原來從傳統 Client/Server 的表單設計,因為潮流,公司需要把系統 Web 化,而往 Web 設計時,卻發現到,怎麼以往 Client/Server 的表單很好寫,為何轉到 Web 後,不僅開發工具的缺乏,以往很容易表達如 “Master/Detail”,卻怎麼在 Web 上如此難寫?

舉一個最簡單的例子,Client/Server 的表單設計,當操作人員輸入客戶ID 時,按【TAB】鍵移到下一欄位時,就會自動顯示出客戶姓名。嘿,當時若用 ASP/JSP 來寫這樣的作法,並不是一件容易的事呢。

為什麼? Web 的表單設計,是當操作者填完整個表單的資料後,才會按【Submit】送出至 Web Server 處理,處理後傳回結果,連線就中斷了。所以,Browser/Web Server 的溝通,是屬於 “Stateless(無狀態)” 的方式;相對於 Client/Server,因為表單一直是連線著資料庫,不管你有沒有在用,資料庫就是一直連線著,我把這稱之為 “佔著茅坑不拉屎”。:) 表單與資料庫的持續連線,稱之為 “Stateful”,也正因如此,所以表單要資料處理時,隨時就可以至資料庫 “撈資料”。

“Stateless” 是為了節省系統資源,因為 Web Server 所服務的 Client 是至少以百計以上,不可能讓每個 Client 都一直連線著;”Stateful” 會浪費系統資源,但是可以盡善盡美地來服務 Client,在 MIS 內部,操作者規模在 100 人以內,系統的負荷是不會有問題的,當然就可以這樣作。

結果,許多程式設計師,搞不懂 “Stateless” 與 “Stateful” 的原理,不僅是新手而已,也有很多算是老手級的了,以上剛我所舉的例子,為了能達成輸入客戶 ID 後,就能馬上秀出客戶姓名,竟然就乾脆一次把位於資料庫的客戶資料全部傳到 Browser 內,然後,用 JavaScript 寫個 For-Loop 的迴圈啊,來找出對應 ID 的客戶姓名。

離譜吧? 會犯這種低級錯誤的,還可真不少呢。 除了增加傳輸頻寬的負載外,根本就沒有基本安全性的防護,赤裸裸地將客戶資料全部儲存在 Browser 內。我在輔導 Web 化的專案時,絕對是嚴禁利用 JavaScript 作上述這種事情,甚至,也不容許企業邏輯寫在 JavaScript 內,例如,計算員工薪資,一定是在 Middleware 來負責處理的。

難道,JavaScript 真的是一無是處,是個爛東西? 不然啦~ 我會用 “爛東西” 來凸顯,其實是要提醒,程式設計師,可千萬不能濫用。我們要為 JavaScript 來正名,瞭解它真正的角色與責任。

我最激賞的網頁設計技術,就是微軟所提出的 ASP.NET。在其技術裡,總算找到了為 JavaScript 定位的最好名稱了,就是 “間諜(Spy)”

且聽我道來~

網頁設計的技術,最大的挑戰,就是要能把 Stateless 的現實環境,”模擬” 成具 Stateful 的狀態。也就是說,Web 化的表單,即使還沒按下【Submit】之前,很有可能會根據某某欄位的資料,而即時送至 Web Server 處理,並傳回部分的結果,但請記得,因為表單還沒有完全送出,所以,表單的資料,是需要被保存其狀態的,ASP.NET,簡單的說,就是利用在 Web Server 有個 “State Bag” 的機制來為 Client 儲存尚未【Submit】的表單資料。

那麼,是誰來負責傳送欄位的資料? 當然就是 JavaScript 囉~
UI 的設計,除了 Style 的美感之外,在技術面,最為重要的,就是 UI 元件的狀態與事件(Event)的處理了。仍然舉上述的例子,當輸入客戶ID 後,操作者可能按下【TAB】鍵或是以滑鼠點選移至下一個欄位,這兩種動作,都會觸發了事件,此時,JavaScript 當作 UI 的事件處理者(Event Handler),收到事件後,根據 UI 所設計條件邏輯,來決定是否後送至 Web Server 來處理,再把結果傳回,並秀出在 UI 上。整個後送的過程,操作者完全沒有感覺,可能就是畫面閃了一下,其實就是作一次 “Refresh” 的動作,JavaScript 已經偷偷地把資料後送至 Web Server 處理了。

Javascript 除了可以在 Browser 端,作一些動態的展示呈現效果外,在企業應用系統的 Web 化表單設計,就讓它回歸最單純的角色,UI 事件的處理者,簡單的說,就是 “間諜”。如此,就不會把 Web UI 的設計搞成複雜又糾纏不清,JavaScript 反而會變成 “好東西” 了。 😉

SA 需不需要懂 “領域知識(Domain Knowledge)” ?

我直接先說結論好了,SA 根本不需要懂 “領域知識(Domain Knowledge)” !!

SA 所需要具備的知識與技巧是,如何與領域專家(Domain Expert)溝通,並懂得如何將其領域知識轉化為抽象的軟體模型。

請記得,是與領域專家的溝通與討論,而並非僅是操作系統的操作員(Operator),從操作員所得到的,大部分是零碎片面的需求,卻非是從企業經營的角度來看待整體企業的流程(Business Process)。

專案經理或IT 主管要求 SA 需要研究,或者起碼需要懂一些 Domain Knowledge,這似乎是業界根深蒂固的觀念,正因如此,SA 根本就沒有花太多時間在 “純” 軟體設計的學習與研究上。當然,會有太多的人質疑,若 SA 不懂領域知識,如何能建構最起碼所要求的 E-R Model 呢?畢竟,E-R Model, Class Diagram 的組成單元幾乎是從領域知識的專業術語而來。

這問題的答案,其實說起來,也不難回答,答案就是如前所述: SA 要能具備 “純” 軟體的技能與技術。
那麼,什麼是 “純” 軟體的技術? 答案又是很簡單:抽象(Abstraction)、封裝(Encapsulation)、介面(Interface)與相依性(Dependency)分析的觀念 …等。

以抽象為例,當 SA 懂得抽象的技巧後,會發現到,各類的領域知識,其核心的本質是源自於 “交易(Transaction)”,交易即為事件(Event),會因而延伸出與該交易所串連的人、事、時、地、物等。所以 SA 在與領域專家溝通討論時,就會用心在尋求該領域上的各類交易,以此為核心,逐漸延伸,而能建構出領域的物件模型。

簡單的實際例子,網路購物系統中,訂購(Order)即為重要的交易事件,顧客(人)會下訂購;下訂購的地點(Place)如超商需要被記錄下來;訂購需要出貨,可能會分次出貨,而出貨,又是一個重要的交易事件,它又可能會串連至出貨人員與出貨地點...等。

Peter Coad “Object Models” 一書中,早於 1997 年該書即已揭露出以交易為核心的 “Transaction Pattern”,來指導與協助 SA 以此來建構領域的物件模型。

這很有趣,有別於 SA 以為要經過需求的訪談後,透過需求文件的紀錄,才可能找出 “Entity”,建構領域模型。當 SA 是與真正精通的領域專家溝通時,運用抽象的技巧,反而可以不先需要透過片段局部的需求文件,就可以建構核心的領域模型。

但,問問看,又有幾個 SA 會去看如 Peter Coad 這樣的著書呢? 更為悲哀的是,SA 根本就是花很少的時間在軟體設計的根本學習與思考上,去看各類 Domain 相關的書籍,反而還比較多。說難聽點,我到覺得有點不學無術。

你要問我,SA 有沒有可能成為好的領域專家,說什麼我都不可能相信。

答案又是很簡單,若可以成為專業的領域專家,那根本沒有必要擔任 SA,因為,領域專家的待遇比 SA 好上太多啦。

又,有沒有可能同時很懂領域知識與軟體設計的? 我是聽過幾個自稱兼通的,但,這我更不相信。要專精每一個專業領域,最起碼沒有花上 5~10 年,是不可能成為專家的。請記得啊,軟體設計,也是一門專業的領域,而這一門領域,其門檻絕對不會來得比其它領域還要容易,對工程、管理、邏輯、心理、藝術等等,均需用心研究思考與學習,你還能有其它時間研究其它領域?

有些 SA 可能有心向學於純專業的軟體設計,但,回到現實面,環境卻不許可。

舉一個實際的例子,我一位目前任職於外商軟體公司的朋友,前兩年他去應徵國內某家大型有線寬頻電視的 MIS 部門,該部門的 IT 主管,出的考題,竟然是要我那位朋友寫出人事出缺勤管制系統的企業流程。 這... 我實在很難以想像,這是 IT 主管!! ?

大環境確然不佳,但這仍端賴於 SA 個人目標的選擇。你要往其它的專業領域,例如 ERP,那麼,就應該要用心成為該領域真正的領域專家;或者,你仍情有獨鍾於軟體設計,那麼,就應該用心在軟體設計的思考與學習上,成為真正的軟體專家。你不可能雌雄同體,是 ERP 專家,又是軟體專家,這樣,是違背大自然法則的,一公與一母的感情結晶下,才有可能生出健康活力的寶寶的。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal