上星期參觀「東和鋼鐵」的煉鋼生產過程,收穫頗多。 除了感受到現場工作人員需要忍受酷熱危險的工作環境,而仍是那麼地辛勤工作,不禁敬佩與慚愧,應要能更珍惜自身的工作;另外一個收獲就是,總算看到了我們對「東鋼」設計企業物件類別圖時,一些概念術語中,關於到 "物 (Item)" 的實體呈現。
像在現場上我們就看到以 "捆 (Boundle)" 為單位的鋼材。 可能像長條形的凹型鋼是以三根為一捆,在入庫/出庫(出貨) 時就是以一捆一捆為單位來管理。 在庫存管理時,每一捆都會給一個序號 (serial number),但一根一根的鋼材並不需要為其作追蹤管理,所以並不需要給予編號;若某一捆的某一根鋼材有瑕疵,就是換掉再綁入該捆即可;每一捆的鋼材規格可能會不一樣,可能有 "凹型鋼"、"馬蹄鋼"、"T型鋼" (想像的規格) 等。
所以當時看到已綁成捆的鋼材,我問 Ringle 說 "捆 (Boundle)" 應該是屬於 "特定項目 (Specific Item)" 吧? Ringle 說沒錯,而且在類別設計時,並不需設計一個 "鋼材" 的 特定項目 類別。 所以有趣的一個問題是,當看到一捆有三根鋼材,若共有三捆時要入庫,在庫存管理系統內,會有幾個物件? 答案可不是 3x3=9 個 instances (個體),而是只有三個 instances,而所屬類別就是 "Boundle"。
"Boundle" 的規格 (Specification)資訊紀錄在哪裡呢? 此時自然會有一種 "產品 (Product)" 類型的類別被挖掘出來。 在庫存系統中,會有個 "成品" 的類別被設計出來,並紀錄著各種鋼材等項目的規格資訊。
每一次的出庫、入庫都需要記錄相關的資訊,所以會設計 "入庫"、"出庫" 兩種類別。 而這類型的物件就是所謂以交易為核心 "Transcation Pattern (交易樣式)" 中的交易物件。
再來,若要查詢現在庫存的數量,該找誰問呢? 此時就會有個 "庫存 (Inventory)" 的類別來擔負 "查詢庫存數量" 的責任。 有意思的是,"庫存" 類別在古早以人工來紀錄的時代以來,就是等同於 "帳冊" 的角色,而這在我的認知算是在電腦系統內 "Log" 類型 這樣的一種角色。 不過 Ringle 倒是很肯定的告訴我,是 "Log" 沒錯,而在 "Transaction Pattern" 中,這仍是屬於 "Specific Item" 的類型。
基本上,一個以鋼材物料的庫存系統主要組成結構元素的輪廓就慢慢浮現出來了,先略過 "人 (Role)", "地 (Place)" 的類別設計,一個基本的 UML 概念類別圖 (Conceptual Class Diagram)如下圖:
圖、庫存系統的概念類別圖
另外還有一個值得討論的議題是,入出庫時鋼材數量的增減行為 (behavior),該由那個類別負責? 這一點我與 Ringle 討教(甚而爭執)許久,我一開始是以為交由 "Controller" 這類型的控制物件來取得本次入庫的總數量,再更新庫存既有數量即可;不過,這仍是犯了 "中央集權" 式的物件設計方法,並沒有真正嚴謹地對類別設計作責任分派 (Responsibility)。 Ringle 認為,依據 "Information Expert" 的設計原則,"Boundle" 認識 "成品","成品" 認識 "庫存",所以關於 "新增庫存數量()", "減少庫存數量()" 這兩個行為,當然是交由 "成品" 來負責才是。
當然,任何的設計方法都可以實現出來,也不會是效能的問題考量;設計的好不好,影響到的是結構的彈性度,在於是否能經得起需求變動的震盪。由於我們的設計目標是往 "Business Framework" 的層次,所以在物件責任分派的設計議題上,當然就得相當講究。
我在現場看到綁成好多 "綑" 的鋼材,也看到如倉庫的 "儲區 (Location Area)" 等實體的樣子,再印證 Ringle 為「東鋼」所設計的,關於庫存管理的類別圖,一一地對應與印證,當然就是更為清楚理解了;老實說,雖然 Ringle 是自己人,但我還是真的相當欽佩與驚嘆,他可是沒有具備鋼鐵業任何領域知識 (Domain Knowledge)的,也從來沒有到現場看過實體的事物,就是仍只經由與該資訊部資深經理 (可算是領域專家, Domain Expert)的需求訪談,所設計出來的類別圖,其核心結構幾乎是一抓就切中要題,八九不離十!
我先前也常提及,擔任 需求分析 或 結構分析 的設計師,實在不需要要求具備領域知識 (Domain Knowledge)。幾年來的身體力行,透過已與十數個以上行業的軟體開發輔導,更是印證了這一論點。但是,前提可是需要能與領域專家合作,尤其是要萃取出共用的穩定結構類別時,領域專家可來得是比直接操作電腦系統的 End User 重要太多了。 我也發現到,多年的輔導與訪問過多家軟體公司或較大規模的 IT 資訊部門,好像領域專家都比較是由資訊部門的資深主管所擔任的。 他們絕對都是擁有專業的領域知識,但是,這可是與如何萃取這些領域知識成為軟體的主結構實在是兩回事。
我也常提及,軟體結構的萃取所需具備的技能 (Skill),不是領域知識,也不是程式設計實做的技術;真正要俱足的是抽象 (abstract)的萃取能力! 這可是要透過大量的觀察與思考、不斷的學習、更需擁有柔軟獨立思考的頭腦才行的。 國外大廠如 Microsoft 等,擁有這類柔軟高段抽象能力的人才必然不少,才有可能設計出如 .NET Framework 這類屬於系統層級的框架。 而這是若未能把軟體設計當為熱情與終身職志者,而只把軟體開發看成只要能快速完成短線的專案目標即可,是不容易成為軟體結構設計專家的。
我很希望,能把 Ringle 這方面的天賦再廣泛地推廣,所以我也期許及要求,Rinlge 的第二本書,應該是要回歸到他真正的才能,能將結構分析的想法思維與推理過程,整理成冊,寫成書籍。 當然,如何將 概念→規格層次的類別設計圖,實現在 .NET or J2EE 的平台,如何活用廠商提供 O-R (Object-Relation) Mapping 機制,整個具體實做的程式碼都會供應出來的。 這樣比較務實,也更能直接讓所謂的 SD (System Designer) 更有 Feeling;同時,書本也比較會有機會賣的出去的。 :-)
※ 延伸閱讀:
o {iThome 書評—12} Object Models — Strategies, Patterns, and Applications。