蓁妮在這個星期天的時候，很認真的坐在她的電腦桌前，利用鉛筆手繪了草稿，內容就是蓁妮在廚房裡親了媽媽的臉龐，感謝媽媽幫蓁妮與采潔做了好多美味營養的早餐、晚餐等。雖然媽媽在平常總是擺著臭臭的臉，但是，在蓁妮的心目中，媽媽永遠都是很慈祥、很和藹可親的，這點真的從這張畫作就可以感受到母親在小孩子的心靈中永遠都是美麗、漂亮、溫柔的。
然後，蓁妮利用 Scanner 將草稿掃瞄至電腦內，再以她很擅長的 PhotoImpact 將草稿內諸如頭髮、臉龐、背景等一一轉成物件，再個別去著色處理 (這連我都不會這樣的技巧勒~)。
花了五個多小時，完成她的作品，除了準備在母親節是送給媽媽的賀卡外，同時呢，這張畫作也成為蓁妮代表學校參賽的美術作品呢。 
HSDc. 定於端午節過後的隔一個星期六 (06/14)舉辦為期九週共 54 個小時的系統分析暨實作課程。底下是該課程介紹與課程大綱，相關的課程資訊，亦可參考：
http://www.hsdc.com.tw/course_signup/20080614_sa_sd_to_implement_by_java
【台北場】2008/0６/１４ 起，每週六白天，每次上課為六個小時(AM 9:30~PM 4:30)，共九個星期。
o 預定上課日期：0６/１４, 06/21, 06/28, 07/05, 07/12, 07/19, 07/26, 08/02, 08/08 。
HSDc. 於 2008 年度推出了完整的系統分析、設計至實作的課程，期能協助軟體開發人員在現實的工作中，能瞭解完整的開發流程與各個角色的工作執掌與產出。在基於以架構為中心來建立團隊具共識的整體觀下，能聚焦在適切開發單位的功能點內，快速地從需求分析導出到實作，找出並克服開發過程中，包括溝通、技能與技術等風險因子。而後基於這樣的框架目標內，得以對系統的結構作重整，卻又不至於影響已有的功能前提下，得以對程式碼施以重構的技巧，讓系統更有延展度與彈性。
傳統系統分析與設計的課程，經常是「昧於現實」，將需求分析/結構設計與程式碼實作拉得太遠，而造成軟體設計與實作的不一致。殊不知，所謂的軟體塑模與程式碼的實作必然是軟體系統的一體兩面，在軟體開發過程中，必然是要保持一致性，所以設計是要作精，而不是籠統的文件報告。關於文件，只是利用工具的文件產出功能，將平時已確實所作的設計，產出美輪美奐的文件報表而已。不要為文件而文件，還去加班熬夜，傷了身體，又浪費生命在不必要的地方，實在沒有意義。
還有系統開發與實作也不是「妥於現實」，利用 IDE 工具從 Web/Windows Form 直接連接資料庫的這種開發方式，只是讓軟體人員變得更笨，只要需求變動就導致牽一髮而動全身，系統是不會有任何的延展與彈性的。最起碼的一點設計良心，又能處在國內嚴苛的環境中，對於短線時程的專案，先將系統的命脈—企業邏輯的核心，全給統籌集中在中間層，也就是企業邏輯層—先求有！ 再來才是求好！— 待系統能確實上線，能滿足使用者的需求後，再則老闆與客戶對開發團隊有了信心，肯給予更多的資源—包括人跟錢，團隊的技能也有了增長與更好的溝通默契。外在與內涵的條件均俱足下，就可以專致於對系統結構的重整，並對程式碼施以重構的技巧，而又不會影響既有的功能前提下，讓系統更具可重用性與延展性，甚而轉成產品以服務更多同類型性質的客戶，又能快速的客製化每一個單位的特殊化需求。
基於這樣的理念，我們主張系統分析與設計是要「務實」，不是「昧於現實」，也不是「妥於現實」，而是在現實與理想中找到那一個平衡點。所以課程規劃是分為兩個階段。第一個階段就是捕捉系統功能需求，快速設計，立即產出程式碼。重點就是要瞭解如何作好系統的需求分析與對應到程式碼的實作。本階段需要培訓的技能有物件導向的基礎知識、從使用者角度看待系統時的外部功能分析，抓出適切的功能點開發單位、從畫面、中間層物件到連結資料庫的實作能力等。還有，一定要配套的兩個設計措施，一為撰寫測試案例與功能測試程式碼，實現自動化的測試機制；另一為活用分析類別，先利用中間層的控制類別，集中與控管從畫面與資料庫而來的企業邏輯。 第二個階段就是傳統系統分析所說的 SD(System Design), 傳統是以資料庫的 E-R(Entity-Relation) 分析，在物件導向則是稱為領域模型的建立—包括找出物件與適切的分派責任。這可不是一件容易的事，事實上應該說要具備的抽象能力要相當高，所以為何我們覺得那種 SA->SD->PG 開發流程是不務實的，因為 SD 很難作得好，然後還要 PG 去等該階段的產出，又大部分是不正確，可以說是浪費開發資源與時間。程式碼可以直接反應功能的需求，但不一定要等結構分析，集中在控制控制類別的好處就是，我們可以很容易地對結構作重整、對程式碼作重構，卻又不會影響既有上線的功能。本階段的重點當然就是對所謂結構的分析技能培養，我們會兩種方式，一為從需求抓名詞的傳統方法、另一為揭露出以交易為核心的交易樣式，可以輕易地抓出一大串的企業元件。
總的來說： 作好功能需求分析-> 影響系統能不能做出來 ； 作好結構分析-> 影響系統有沒有彈性
觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次，是我們對於系統分析設計與實作課程的基本原則與態度。修習本次系統分析的學員們，也可以拿到完整的教材、完整案例的 Model 檔與實作程式碼的對應。程式碼是以 Java 再搭配最夯的 JSF/Spring/Hibernate Framework，當然，要直接對應 .NET 的實作程式碼，那也是相當直覺不是難事。我們期能讓學員們上完課後，能以我們所提供的案例，包括設計模型與程式碼，當成範本而可以應用於工作實務上，甚而可以創造所屬自己的 『Pattern』。 HSDc. 軟體開發團隊，關心每一位軟體人員的持續成長．．．。
【課程大綱】．．． 繼續閱讀 »
前一整個星期還真有些累。 上星期六、日 (04/12,13)我們才舉辦了 「活用 UML 三劍客與實作程式碼」的單元課程，然後星期二、三連著兩天在高雄在兩個單位輔導與授課；星期四下午又到我們已輔導一年餘的大型鋼鐵公司洽談新案子合作的開發事宜。然後接近傍晚又過去內湖港墘路某家開發金融的軟體公司授課，直到晚上8:30；星期六又過去「開羅會議中心」照顧一下今年我們首次舉辦的「軟體設計鮮思維」研討會。然後昨日星期天早上也把延續上個星期的單元課程利用案例研討，作個總結。 呼，講課久了，喉嚨會有些沙啞，身體當然也會有些累。今天 (星期一)竟然睡到近中午，不過到也著實補回了身體能量不少。
現在有高鐵，到高雄的確是方便多了。我不用前一天就過去，當天只要坐 7:00 以前的班次，不到九點就可以到高雄左營站了。上星期二我坐捷運到了台北車站，本來是打算搭 7:00 的高鐵班次，沒想到 6:32 到達，然後用現金投錢買自由座的車票，竟然還趕得上 6:36 的班次，所以到左營時也才約 8:10 左右。那天因為 Ringle 是已前一天到達，住在他朋友家，當天是 9:00 約在左營站見面再一起過去輔導的公司，所以我是很輕鬆，就在高鐵內的 StarBuck 坐著看買來的報紙。 本來是想點早餐的，沒想到那個店面沒有，實在差，不得已只好點了個麵包與小杯的焦糖瑪其朵，這樣也要 NT$180， StarBuck 的咖啡真是貴。
星期二那天是到文信路某家我們已過去輔導過三、四次的軟體公司，檢視他們從我們上次輔導後，根據我們的建議所作出的開發產出。下午我還凹 Ringle 請全部參與的人員喝個下午茶，每人一杯咖啡外加蛋糕。輔導或上課時，我總是覺得沒必要太過嚴肅或沈悶，輕鬆一點，輕鬆一點嘛。 晚上結束輔導到我日前從網路訂的商務旅館，在後火車站安寧街附近，有家「住X」的飯店，一看就知道是傳統旅館改型過來的，雖然房間很大，也可以上網，但設施什麼的都很不佳，要洗澡竟然熱水故障吧，洗到了冷水，隔天 Check-out 所附的早餐也只有輕粥及一些小菜，連煮的咖啡都沒有，只附了三合一沖泡咖啡．．． 這類的飯店，以後我是不會再去住宿了。記得上次所訂購的商務旅館，叫做「西悠飯店」 (這次竟然前兩天訂時，房間全客滿，沒有辦法訂)，就真的很棒，設施什麼的都很新，是個相當新穎、名副其實的商務旅館，早餐又很多樣化，中式、西式等的都有，附近的景觀又很棒，上次我住的時候，晚上還出去走走要買晚餐，附近空曠以及許多高雅的建築景觀，讓我印象很深刻，覺得住在這附近，真的會有幸福的感覺。
第二天(星期三) 是到高雄榮總資訊中心上課的，這是我第一次到該地方，覺得好大喔。 早上提早了約 20 分鐘過去，醫療中心一樓真的很熱鬧，好像就是百貨公司的商店街一樣，除了賣吃的，還有「金石堂」書局，甚至也有服飾店，還有專賣玉的店呢。 我在他們的咖啡廳點了杯咖啡，喔，實在相當不好喝，喝了沒幾口就沒喝了。到了中午，才到了榮總附近的 StarBuck，點了杯榛果拿鐵，嗯，好喝多了，下午精神也就跟著清爽。有個小插曲，下午是 Ringle 授課，是直接請他們當場提供案例，然後由我們展現如何從需求分析到程式碼實作，三個小時內就是給它實作出來，這也是我們的原則： 早上分析設計，下午程式碼就要能實現出來。 結果在分析某個需求，Ringle 是認為共有四個使用案例，嘿，我是認為只會有一個，而且是很堅定的認為，Ringle 當下很不以為然，不過我就是很有把握，甚至還底下與旁邊有位很可愛的小妹妹說，放心，回到台北，Ringle 會接受我的論點啦。 不過真的可以知道，我個人與 Ringle 合作那麼久了，對於軟體本質性的道理，都仍在持續學習體會中，光是使用案例，竟然到現在仍會有不同的見解，可見使用案例技術真的是易學難精的。對於該案例，我肯定是會著文來討論的。
星期三晚上從高雄回來，隔天下午是到我們輔導國內某大鋼鐵公司的資訊部開會討論，他們希望能整合 Project Server 與預算系統(客製化)，由我們統籌該整合專案的開發。一般來說，在開發一個整合性的專案，我們會先提出該系統的架構規劃，然後就技術上的一些課題，會利用 Prototype 來找出其中的風險與驗證架構的可行性。所以也談好本星期會再過去，利用 Protype 展示並作更深入的討論。 傍晚約 4:30，是過去內湖那家專作金融的軟體公司作軟體的教育訓練。規模蠻大的，與我們洽談的企業內訓安排在每個星期五，共有 10 來個星期，好像共有 40 多個小時的教育訓練課程。那個與我們時常聯絡的 Marketing 專員，還拍過食品廣告呢，是個很漂亮，也好有禮貌，親和力好好的女孩子。現在我還在用力找，到底是隱藏在哪一個廣告，目前都還沒找到。 :>> 一開始學員們都還蠻拘謹的，不過安排我第一次過去上課，就是要負責炒熱氣氛的。還不錯，我還算是蠻會講一些笑話的，後來整個上課的氣氛就好很多，也有學員們會踴躍發問問題了。
星期六、日連著兩天就是在「開羅會議中心」研討會與單元課程的。 星期六的研討會這次我就沒參加了，我們三年多來共舉辦了有十九次的研討會，就只有這次我沒有上台主講，總是要休息一下的嘛。:P 而星期六晚上，我臨時想了一個案例的主題，從界定系統範圍、找出優先實現的使用案例、設計類別與循序圖，程式實作，準備要授課在隔日的單元課程，所以從晚上開始寫，直到凌晨快 3:00，然後只睡了約五個小時，就過去上課了。上課的時候精神還相當亢奮，但是中午結束後，身體開始逐漸疲累了，下午回來後，先補睡了一個多小時，然後傍晚被我小女兒挖起來，要我玩那個「榮譽勳章—空降神兵」給她看，她可迷的不得了，覺得這個遊戲真是緊張刺激。
然後下個星期呢，又要到高雄過去授課了，也是另一家醫院呢，然後好像也要去羅東，也是醫院耶，最近還真的跟醫院的資訊中心蠻有緣的呢。再來就是要準備我們要在六月初舉辦的系統分析的完整課程，約規劃了 48 個小時，這兩天就會公佈出來了。 其實，我是還蠻喜歡到各個單位輔導上課之類的，可以見識到各個地方或單位的風俗人情，然後看看每個單位他們的問題，怎麼「見招拆招」，也算是有些挑戰性，蠻有趣的。
|
Object-Oriented Methods A Foundation ———————————– 作者／James Martin/James J.Odell /著 出版社／Prentice Hall PTR ISBN／ 013-905597-5 |
內容簡介
This book presents those concepts and techniques that support almost any system development approach–whether it involves computers, people, or machines. It considers object structure, object behavior and more advanced concepts such as composition, structural constraints, rules, using rules and diagrams, meta-modeling, and power types. Shows how to represent OOA constructs–modeling object structure, modeling object behavior, modeling state transitions and event diagrams, scenarios. Outlines considerations for design, discusses object-oriented programming, and considers object-oriented design and 『instant』 CASE. –This text refers to an out of print or unavailable edition of this title.
截至目前為止的書評，我發現到並沒有真正介紹到適合於初學者的軟體入門書籍。大部分所介紹的還是偏向實用性的設計類叢書，即使如 Booch 那本 OOAD，雖然是理論基礎用書，但那本其實難度不低，用字又艱深。事實上，所謂的「物件導向」基礎入門書，要能寫得好，其實非常困難。作者除了觀念要相當透徹外，用字遣詞又要言簡意賅，把複雜的事情簡單的呈現，並不是一件容易的事。不過本次的書評— {Object-Oriented Methtods}，兩位作者均同名為 James 的 Martin and Odell，寫出了絕對會是留名軟體青史的代表性著作。即使許多讀者會恐懼於閱讀原文書籍，但本書的英文用句，真的相當淺顯，不太懂文法也是可以讀起來毫不費力。誠如作者在前言裡所提及適合於本書的讀者程度，並不需要具備任何的前置知識，包括程式語言等。更為誇張的是，他們說書中諸多元素用語，已被用來教導約七歲年齡的孩童。這讓我想起，曾經在某購書網站看到，{UML 精華} 那一本書，適用對象竟然是寫為國小程度，哈，許多軟體人員真的是有夠汗顏的了。(其實那是網站筆誤的)
Martin & Odell 可是 OO軟體業界早期相當具知名度的先驅，他們的著作甚多，Odell 除了是物件導向社群的領導者外，也是 OMG UML 規格制訂的主席；而 Martin 看他寫作的資歷，你真的會嚇一大跳，從 1960 年代開始，我都還沒出生的時候，就已經出書了，至今已發表超過 100 本以上的專業書籍，包括軟體、資料庫、電傳通訊、即時性系統等，所涉獵的專業範圍實在廣泛。至今他除了在知名大學教授外，還仍茲茲不倦地研究與寫作。我真的好是佩服，這才是真正致力於軟體之道的大家啊。
本書共分為六大部分，剛好整整 400 頁，厚薄適中。最後一部份為附錄，除了語法的說明，還有一個訂購系統的分析範例。另外最值得推薦的是附錄D (Toward a Formalization of OO Analysis)，是以論文的型態闡述了關於分類的關係、一般化/特殊化、功能/屬性/角色 等在分析過程中，經常會運用到的基礎技能。
第一章是對泛OO系統的概念性介紹。而在前兩部分章節，則為 基本OO的基礎知識。第一部份(2~11 )介紹物件的結構(structure)、第二部分(12~17)介紹的是物件的行為(behavior)。我覺得第一部份可以精讀，那真的是奠定最為紮實的理論基礎了。例如，我們經常說開發的是所謂的物件導向式系統，好吧，那你能否明確的說明出分析的物件從何而來？ 再問一個更“俗”的，能不能定義出什麼是物件呢？ 嘿，許多軟體人員還會愣住，無法回答出來呢。第二章開宗明義就指出，物件源自於概念(concept)，“An Object is anything to which a concept applies. It is an instance of a concept. (物件是概念可以被應用的任何事物，它是概念所呈現的個體)”。 由此定義也可以得知，“物件”與“個體(instance)”這兩個術語，其實是具同義詞性質的。將“概念(concept)”作為認知的對象時，所產出的“個體(instance)”即為物件。但概念會牽涉到人們對於觀點、角度等認知，而會有不同的體認。例如站在遊客的角度，他所看到在森林裡面的樹木，是一個個的“個體”，會從樹木之外的角度來欣賞樹木的茂盛與宏偉，是一種整體性的認知；但站在植物學家的角度，他要研究組成樹木的結構元素，所以會把樹木分為“樹幹”、“樹枝”、“樹葉”、“樹根” 等多個組成樹木的“物件”，從結構的觀點來研究樹木的內部組成。這同時也就代表了，雖然到處都是物件，但並不是任意地將物件給“塞”入軟體系統內，物件導向的設計，是將問題領域(problem domain)的概念，呈現與對映(mapping)至軟體系統內，那麼，如何正確地捕捉(capture)問題領域的概念成為物件，就成為是軟體設計中，最為重要的技能與素養了。 你可以看看，當你能對這些基礎概念術語有很明確的定義時，你就可以很容易地衍生出諸多看來好像很複雜的呈象，但卻又不會違背這些基本的原則。我常戲說，練好這些軟體蹲馬步的基本功，才真正夠得上是武當名門正派的正宗內功！
當能分辦出 物件與類別的區別後，然後再進而瞭解類別之間普遍的三種關係：關連、整體/局部、一般化/特殊化 。透過關連，我們可以分析類別的相依性(dependency)，以瞭解耦合(coupling)的程度；透過 整體/局部，我們可以封裝(encapsulate)細節，並以整體的服務呈現給 client；透過 一般化/特殊化，我們把相同的部分抽象出一般化類別，而把特殊或需要擴展的行為分別實現在特殊化的類別，而造成所謂多型(polymorphism)的效果(這也是程式語言中常稱之所謂的繼承)。再來論及的是物件的行為面。從對狀態(state)的說明，然後到狀態的轉移，而發生轉移的觸發(trigger)即是所謂的事件(event)。所以當然就會需要瞭解到事件的種類、事件的處理等，而這也是在當今元件化的系統，在動態期間常會需要用到的機制，在設計上也是相當重要的範疇。
第三部分(18~23)是OO進階的介紹，這裡提及到了限制(Constraints)，也就是在類別關係之間如多重性是如何的表示；還有提到了規則(Rules)的表達，是如何呈現在設計圖上。我是覺得這類議題反而比較偏向細節性，倒是不一定要規範如此嚴謹，我是比較主張設計盡量活潑彈性一點，再慢慢地抓出團隊設計的共識即可，至於嚴謹性，倒不如在程式碼驗證即可。
第四部分(24~29)是關於物件導向分析(OOA)的說明。由於這裡涵蓋的議題太過廣泛了，諸如需求面的功能分析、結構面的類別設計、實作面的物件互動等，短短幾個章節不可能詳述清楚的。這裡我也只是大概瀏覽過即可，然後再對上述各個主題，從別的專書中再深入去探究。
第五部分只有一章(30)，主題更是嚴肅，設計與實作的考量。開玩笑，一大堆所謂的物件基本教義派就是“掛”在無法將他們理想中的設計具體化呈現在現實的技術平台上，例如所謂的“O-R (Object-Relation) Mapping”，每種平台的實作都不一樣，那也是要相當去深入研究的；還有諸如交易控管、權限控管、分散式 …等，這些都是在實作上必然要面對的挑戰，10 本書都不一定介紹得完，遑論僅有一章？
本書在 Amazon 也是頗受佳評的四顆半好書，印刷尤為精美，是我目前唯一有著紅與黑的兩色印刷書。除了 UML 設計圖外，還有許多生動有趣的插圖，佐以解釋主題的呈現。最好是不要抱著從“用”的角度來看待此書，那麼你可能會失望，因為它不一定能馬上讓你可以應用在現實的工作上。當你好奇於為什麼主流的程式語言都採用物件導向式的實作機制、為什麼系統分析/設計也強調所謂的 OO 思維，到底 OO 是要協助來解決什麼樣的軟體設計議題 …，還有當你真正有志於從事軟體專業之路時，本書絕對是修習基礎內功的必備聖典。
這一次倒不是要 『批判』 博X來的訂購系統，而是想藉由該資訊系統，來聊聊需求分析的設計議題．．．
我們知道，博X來的訂購系統，存在的最大價值，就是提供客戶「訂購商品」的服務，而為了滿足客戶最終能買到所訂購的商品，所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst)，那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候，妳會分析出 『多少顆』 使用案例呢 (只涉及到上述討論訂購商品的範圍)？
我經常思考這類的需求分析議題，也曾就該問題與其他資深分析師討論，有人認為是兩個，也有人認為是一個，當然也有人認為是三個、四個…等。 好像是見仁見智，沒有所謂標準明確的答案。 我是在想，能否有一種簡易判斷的 『準則』，來決定使用案例是一個或多個呢？ 老實說，從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義，我仍不容易釐出那個準則，所以我是想透過觀察使用案例的行為，來找出那個判斷的原則為何。
先觀察實體書店一般的購物程序：客戶走入書店，瀏覽與選擇欲購買的商品 (書籍)，並放入購物籃內 (拿在手裡也算，代表已準備好欲購買的商品)，並拿到櫃臺，結帳並付款。
所以幾個使用案例呢？ 我肯定是認為一個：《購買商品》，因為客戶來這個系統 (實體書店)的主要目的就是 購買商品，而為了滿足該目的，他必須經常放入購物籃、結帳等程序，而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的，約幾分鐘到幾個小時就可以完成 (＊注意此點)。關於傳統書店使用案例圖的表達，可以參考下圖1。
圖 1、實體書店購買商品的使用案例圖
在使用案例圖的表達上，看起來好像是三個使用案例，其實本質上只有一個：《購買商品》。這裡利用《include》這個 stereo type，只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。
再回到博X來網路訂購系統來看，那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢？ 看起來很像，都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣，放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢？ 當客戶瀏覽商品資訊，若是看到打算購買的商品，就把它放入到購物車內，但是客戶並不需要馬上結帳，他可以等過幾天再決定是否結帳。所以很明顯的觀察到，這是兩個可以在不同時間點個別可以獨立完成的交易 (＊這一點與實體書店不一樣)。 (不過，這兩個交易事件好像又有些關連存在，要 結帳 前必須先有商品 放入購物車，關於此點，留待後述來討論。)
所以，我的觀察與心得是什麼？ 我會以為，若是可以獨立在某個時間點可以完成的交易事件，我會把它就視為是一個使用案例。或者再用更通俗的一句話來說，就是參與者在使用這個系統，從上線到離開的過程，可以 『一氣呵成』 地來完成一個功能案例，該功能案例就可以獨立成為一個使用案例。 所以，博X來訂購系統對於 訂購商品 的主要目標上，會有幾個使用案例？ 我是會把它切為兩個：《訂購商品》與《結帳商品》，參考下圖2。
話說昨日該裝了 CPU 與 顯示卡 散熱裝置，想說除了靜音外，夏天也不會熱爆了。 昨晚我想測測看 PC 內部的溫度情況如何，所以利用 Everest 列出我的電腦的相關資訊。 透過該軟體的「感應器」列表，發現到 CPU 風扇是 650 轉、電源供應器是 1600 轉左右，不錯，真的很安靜。 再看看 CPU 與顯示卡的溫度，CPU 約控制在 40 度以內左右(熱機跑過後才約 46度)，這個數據可以接受，滿意；不過顯示卡的 GPU 約 55度、而真空管則高達 60~65 度，挺高的。當時應該沒改散熱器前就要先測測看，看來這款微星的 8800GTS 的確溫度會太高，都改了散熱還這麼高，那到夏天該怎麼辦？ 有些小傷腦筋~ :-/
不過現階段我玩一些高檔的 Game 都很平順，效果也相當好，屆時要真的再掛掉，就再說吧。 唯一一個數據相當奇怪，我共有三顆硬碟，其中兩顆資料碟(一為 SATA, 另一為 IDE)，溫度約在 3,40 度左右，算是正常，但是我那顆 WD 250GB/16MB, 7200 轉的 SATA 硬碟溫度卻高達 65 度！ 這讓我蠻納悶的，因為這顆是我的系統主力碟，這期間的運轉算是正常，資料讀取存取等也都沒有問題。想說是不是 Everest 弄錯了，所以還特地把機殼打開，然後用風扇全力吹。過了幾分鐘，整體的溫度確實有降下來，該顆硬碟下降約為 60 度左右，所以看來 Everest 並沒有出錯。後來我再上網查了下資料，發現到硬碟正常溫度是在 60 度以內，而一般都約為 3,40 度(我另外兩顆就是)，所以，看來真的不是正常。然後我再作個測試，讓它持續讀寫資料。阿娘喂~ 硬碟的溫度高升到 80 度，嚴重發高燒了，頭腦都快秀逗了，趕緊給電腦整個關機，想說今天一定要趕快去買顆硬碟來取代，趁硬碟還沒壞前，把我許多重要的資料給備份出來。
後來想想，其實真的有些徵兆，硬碟經常都在讀取中，而且讀取的時候聲音還有些大。只能說僥倖，這一顆硬碟要是毀掉，我真的會哭翻，最重要的是我多年來的數位相片檔案，都是蓁妮她們從小到大所拍的照，這可何其珍貴！ 同時也真慚愧，我也懶得備份，想說算蠻信任現今硬碟的穩定度，還有，憑著我職業的嗅覺，若是硬碟壞掉之前我一定可以感覺的到的(從以前都是這樣察覺到壞掉的硬碟)。當然，這壞習慣馬上要改掉，資料的遺失絕對不是開玩笑的。
今天一大早起床就先利用我的 T61 筆電上網查詢要買的硬碟相關資訊。幾年來其實我一直偏好購買 WD 系列，覺得它還蠻穩的。不過原先所看中最近所出的一款單碟 320G, 16MB 緩衝的 SATA2 規格，發現到搜尋時間慢得離譜。而超過 320G 以上的硬碟我不太想考慮，因為我是打算再過一、兩年，整台電腦都要換掉，目前算是過渡期在用而已。從 效能/穩定/噪音比 綜合比較，諸多效能玩家們還蠻給予去年底 Segate 所出的梭魚11代系列的硬碟好評的。第 11 代目前是只出企業等級的，最小是 250GB，就剛剛好與我現在掛掉這顆一樣的容量。這類的硬碟在我家附近是買不到的，所以利用中午又衝到「光華商場」購買。
Kenming's 軟體設計
Kenming's .NET 實作
since 2004.05.11
關於本站授權聲明
