Kenmingの鮮思維

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

圖、庫存系統的概念類別圖

繼續閱讀 »

與其說 Drupal 功能強大有彈性，倒不如說因為有太多玩家為其開發各類功能的模組 (modules)，而使得網站的客製化 (customization) 與個性化大幅提昇。 例如 View, CCK 等重量級的模組，很難想像若不安裝這兩個基礎模組，Drupal 網站該如何運作設定啊。

為了讓網站功能更形強大多樣化，網站管理者往往需要安裝到數十個之多的模組。 說實話， Drupal 的模組設計，個人覺得甚為不欣賞。 雖然它有很大的優點是容易開發，且容易與核心 (kernel) 整合；但模組與模組之間的相依性 (dependency)太重了，會因模組的更換而連動影響到相關連的模組，而導致這些模組所提供的功能並不穩定。更甚者，大版本的更新，如從 4.X, 5.X, 6.X, 7.X 等的升級，所有模組均無法順應升級到下一大版，只能重新安裝支援該版本的模組，這實在相當不合理。

上述是題外話，算是對 Drupal 開發一個小小地抱怨 (當然，更期許的是，Drupal 的結構設計能更形有彈性，那可就相當完美了)。

現在較頭痛的一個問題是，安裝了太多模組後，效能與穩定性往往會被影響到。 以我來說，目前安裝了近 20 個模組，雖然功能尚稱穩定，不過常常會遇到在管理頁安裝某些模組後，就停滯在該網頁運轉許久，然後就出現 空白頁 (Blank Page)，使得我經常需要去資料庫刪除掉該安裝的模組，移除掉該模組檔案，再重新開啟模組管理頁，再重新試著安裝……，實在令人困擾。

這一類的問題，當然就是要透過 Google 找 How-to Solution 了，或者應該是要至 Drupal 的官方網站論壇找尋答案了。 這裡： The White Screen of Death (Completely Blank Page)。 整理了許多引起 Blank page 的可能原因與建議的解決方案。

繼續閱讀 »

今天下午我家小女兒想要到外面騎腳踏車。 媽媽說乾脆先約她的表弟肉羊一同去，也順便到位於新店「達觀鎮」肉羊家去接小荳荳回姥姥家。 本來我老婆她弟弟說就在他家大樓下這邊騎就好了，不過我家 Annie 不高興，堅持就是想到位於公館那邊的「河堤公園」騎單車。 後來倒是想到，從「達觀鎮」開車下山，往中和方向的快速道路下來，有個新開闢的「陽光運動公園」，離家又近。 決定了我們兩家人就開了兩輛車往預定地前往。

開車不到 10 分鐘就到了。 喔，原來就是在「中安便橋」這邊啊，以往我從台北基隆路高架道路開回中和時，必會經過這個便橋；不過今年新店往安坑、中和的高架道路建成，「中安便橋」前兩個月公告關閉，原來就是將這邊給整個闢建為運動公園，以及腳踏車專用步道啊。

陽光公園好像還沒有開放，不過已經是一堆人在這邊休憩、運動了。 這裡有兩個中型的停車場，停車算是挺方便，因為尚未開放，有許多設施其實還沒蓋好，現在也只有臨時擺置的行動廁所；且據園區地圖來看，以後應該會有個咖啡店 (太棒啦)，可以納涼喝飲料，否則現在都沒有任何室內建築，天氣悶熱時實在不好受。

這個公園最重要的，就是腳踏車專用步道了。 可以說是以「中安便橋」為單車起點，可以騎到新店「碧潭橋」耶。 光今天我就看到起碼上百台以上大大小小單車，來回著絡繹不絕。 喔，我家 Annie 相當開心，騎著我原來買的「捷安特摺疊式腳踏車」、肉羊也騎著他爸爸買的折疊單車，一同往便橋頭尾來回騎個不停。

繼續閱讀 »

下午用完午餐稍事休息後，1:30 經理帶著 Ringle, Author 與我 (Cathy 幾個月前已參觀過) 一同到煉鋼廠參觀實際的煉鋼作業流程。

不過，只要進入廠區後，就嚴禁拍照，商業機密的考量，這是必然的防護措施。 所以我只有從辦公大樓這邊，拍了張位於後邊的廢鐵料等棄置場，算是作個紀念。
(*** 仍有機密性問題，故照片仍給移除掉 ***)

每一個進入廠房參觀的標準裝備就是 一頂安全頭盔、工作服、口罩。 不戴口罩可以嗎？ 嘿，當你一進入裡面，連眼睛都可以看得到，空氣佈滿了一堆粉塵，不戴是不可能的。 當天下午很熱，但是，進去後，那可是更為悶熱啊，而且又陰暗、又潮濕、機器切割運轉聲音極為大聲，才沒進去多久，就已經是大汗淋漓了。

沿途參觀，經理真的非常的細心解說。雖然他是資訊部門主管，但可是對其鋼鐵製作的作業流程熟悉的不得了，且幾乎是認識現場工作的工作人員，每到一站，總是會寒暄問好。

呵呵，甚至我與經理聊天掛唬爛，說未來 100 年後的鋼原料應該會從 鐵 轉為 泰坦。 經理還很好奇，認真的詢問泰坦是什麼原料呢？ 我跟他說是那是只有外星球才有的礦石喔，未來太空探測，建立太空採集基地後，就會大量地運回地球煉製，它可是比鑽石還要更堅硬好多倍的礦石原料喔，從泰坦礦精練成的泰坦鋼，是全世界最堅固的鋼材了。 呵呵，為什麼我會知道有泰坦鋼這種東西啊？ 因為，在「魔獸世界」裡面，你學挖礦技能就知道啦，只有在「北裂境」才能挖到的材料呢，採礦時有時還被聯盟的偷襲強奪呢；而且一天只限量可以熔製成一個泰坦鋼耶，相當地昂貴呢。

煉鋼廠內的主要作業程序大概有 熔煉, 精煉, 加鑄, 半成品/成品 加工, 品管, 入/出庫, 出貨等。 包含加鑄的前三個作業區最辛苦了，想想看，要能把廢鐵材料溶解再重新鑄造，溫度可是要高達 1500 度耶。 我們每逛過一個作業區，就一定要進入中控室參觀兼喘口氣，因為實在悶熱戴口罩又難以呼吸勒。 包括 中控、監控系統、MIS 等系統，東鋼可是分了好幾個 Level (應該算是機密問題，不能透漏)，包括機械設備含軟體、外包與自行客製化等應用軟體等，資訊處要忙的事其實還真的不少。

對了，偌大的廠房佈置，每個作業區有不同的設備，我竟然好像似曾相似耶。 是在哪裡看過類似的場景呢？ 哈，原來是去年我玩「空降神兵」，盟軍空降到德軍的一個坦克工廠內，在廠區內要殲滅敵人的一個遊戲任務啦。

我們參觀整整花了有兩個多小時。 在靠出口總算有看到自動販賣機，我一連投了沙士、無糖綠茶，兩瓶灌完才有那個止渴的滿足，實在口真的太渴了。

回來辦公室後，休息一下，再看看 Cathy 的 SA 輔導，也指正了一些問題點，約下午五點多開車回台北了。 回來後，身體髒的難受，迫不急待地洗頭淋浴，整個人才覺得有放鬆、舒服的感覺。

說真的，在剛進入廠區的那個時候，我突然有著很深的感觸。 真的非常尊敬與佩服長期要待在裡面的工作人員，大部分聘請的員工是苗栗在地的客家人，真的是很能刻苦耐勞。 我也覺得慚愧，自己與幾乎所接觸的朋友、客戶等等，都是待在冷氣房的辦公室內，腦力工作，實在輕鬆太多了，如何能比得上要靠勞動且普遍要位居險惡環境的勞工朋友啊！

※ 延伸閱讀：
　o 東和鋼鐵苗栗廠一日行 (1)。

早上 8:40 左右，與 Cathy, Ringle, Arthur 約在南勢角麥當勞這邊，由我開著車，走北二高，到了「後龍交流道」下來。再由 Cathy 喋喋不休、一路指點，轉過西湖鄉，總算抵達到了東和鋼鐵苗栗廠。 因為今天是苗栗廠這邊 MES 系統 (Manufacturing Exceution System) 的 Kick-off Meeting，所以我們顧問團隊的主要成員們都參與了今天的盛會。
(*** 考量機密性問題，廠區內照片不便公開，故仍將之移除 ***)

我們辦了證件，一進來就走進大門不遠，相當獨特建築的辦公大樓內，據經理說當初是委託相當知名的建築設計師建造的。 本以為早上會先參觀廠房，結果走上去到了四樓的辦公室內的小會議室後，Cathy 馬上就迫不急待拿出筆電，開始作需求訪談分析啦。 而 Ringle 與我 不得已只好又走下樓到停車區這邊拿筆電。 呵，看來是經理的一片善意，讓我們能好好的爬樓梯健身。

繼續閱讀 »

讀者 Pogi 很細心地在 「Ringle 即將出版的新書─ UML 協同團隊合作開發」一文中，提出他對閱讀了該書之後所發現的問題。 在此我也特請原作者 Ringle 在此針對所提的問題作回覆。

請問有提供勘誤表回饋網址或mail嗎？

• 43頁：
  一般化關係：是不是應該說明一般、特殊化關係的方向性？
  整體-局部關係：聚合跟組合的圖看起來都是實心的。
• 44頁：
  相依性關係：圖示錯了。
• 45頁：
  圖3-2的內容跟前面訪談結果不一致，特助有說跟住院事件相關的人員：醫生、護士、櫃台人員，但是類別圖卻沒有櫃台人員。

Ringle 的回覆如下：

謝謝你那麼仔細地看這本書，有關您所問的問題，分別說明如下：

1. 43頁：
   一般化關係：是不是應該說明一般、特殊化關係的方向性？
   照您所說的，我會在下一版中加入一個說明：「病床」類別是「非健保病床」與「健保病床」類別的一般化。
   另，聚合的部分應該為實心，這是在校稿時忽略掉了。
2. 相依關係的部分也是一樣的。這幾個部分，主要是由於書籍的美編重新改過了原來的稿子所造成的，不過我在校稿時也沒有發現，謝謝你的指正。
3. 有關類別圖與訪談結果並沒有不一致。「櫃臺人員」主要是屬於「Actor」的性質，並不屬於類別圖中所需關心的問題。
   對於特助來說，他並非軟體設計人員，因此，他只是忠實地說明他所看到的現象，但設計人員應該要針對他的回答加以思考並過濾，而非全盤接收。