上星期參觀「東和鋼鐵」的煉鋼生產過程,收穫頗多。 除了感受到現場工作人員需要忍受酷熱危險的工作環境,而仍是那麼地辛勤工作,不禁敬佩與慚愧,應要能更珍惜自身的工作;另外一個收獲就是,總算看到了我們對「東鋼」設計企業物件類別圖時,一些概念術語中,關於到 "物 (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)如下圖:
圖、庫存系統的概念類別圖