接續 分析與設計02-企業需求
上面提到了 , 有些項目是在進行系統分析與設計時 , 必須要一併考慮進去的
例如 如何降低系統維護人力的這個要求
有些系統常常只考慮正常狀況 , 但是如果發生了異常狀況 , 則可能會需要大量的人力來進行後續的處理與作業 ,
又或者是說到了 Server 的Cluster 配置 , 這裡面就會牽扯到兩台或是多台Server 之間 , 關於 Web Session 的共用(或者是同步)等等.在進行系統設計時必須要稍微注意一下
舉例來說 , 有某廠商在設計排程程式時 , 根本沒有考慮Cluster的狀態 , 結果我們一問他們 ,
在Cluster 環境下 , 是不是會各跑各的(2台 Server上的相同工作各自執行) ,
結果廠商就說兩邊都會起來執行(有些工作是只應該被執行一次的 , 而不是兩次的)
或者是檔案的產生 , 因為有2 台Server就必須要考慮 ,
如果user由Server1 切到 Server2時 , Server2可能取不到剛剛 Server1上面的檔案 , 而導致失敗.
當然聰明的人馬上就會想到要將Server1 與 Server2 的檔案存取點是 mount 一個共用的Server3上的Share 路徑.這樣做也沒有問題.
只是這些其實是要再設計的時候就考慮進去的,因為這些細節會影響到日後各項細項的工作.
2007年2月12日 星期一
分析與設計02-企業需求
在面對企業內部需求 , 有些系統就必須要考慮到十分周詳與長遠
例如 , 企業上會有些要求 , 例如 , 系統維護人力必須要低 , Down Time 要短 , 還是 Fail over 等等
因應這些需求 , 就會有一些配套的解決方式 ,
例如: Fail over 跟 Down time 的需求就會有 Cluster 或者是 Load Balance 等等解決方案
而系統維護人力要低 , 則必須要從分析跟設計開始著手 , 搭配一些自動化的監控軟體.
這裡面必須要提出來談的是,千萬不要一開始就看所謂的監控log file 這樣的問題點入手 ,
那根本不是有企業等級眼光的人員提出來的 ,
我看過某家公司的某些人員一開始提監控就是提監控 log file , 而不是先提系統該如何被監控 , 哪些事件是要由哪些角色來進行處理 , 這個只能說他們是小孩子在開大車
為何這樣說呢 ? 大型企業一般來說 , 可能會把 IT 的人員角色切的很細 , 管理 Database 的人員 , 管理 AP Server 的人員 , 管理網路的人員 , 管理應用系統的人員.
而大型企業的系統的 log , 有可能一天就是幾千條 , 甚至上萬條紀錄 , 如果你一開始就只是去談 log 的監控而不是由 log 的上游看起 , 那我只能告訴你 , 那是垃圾 , 垃圾進 , 垃圾出.
不相信嗎? 去看一下企業內部的相關管理系統的人員,他們一天可能會收到上百封由監控系統發出alert email ,
你猜猜看那些人員會怎麼看這些mail ,
答案是直接略過 , 為什麼 ?
理由1: alert 太多了 , 所以分不出來 , 那些是真正重要的 , 哪些是不重要的
理由2: alert 沒有足夠明確的訊息 , 管理Database 的人員(或者是管Server的人)不知道要如何進行下一步的處理 , 那些可能只有系統的維護人員才會了解
所以當你要開始規劃公司的監控機制之前 , 請先從系統最上游開始分析 , 要求系統在分析設計時 , 就要把那些錯誤 , 是必需要由哪些角色去處理 , 跟做什麼的全部釐清 , 甚至要把log 也拆離出來 , 商業作業的log跟系統錯誤的log 要切出來.
我看過某公司的某個Enterprise Architect 在規劃監控機制時 , 連腦子動都不動的 , 就談 log file 的監控 , 似乎以為有監控 log file 就能滿足企業的需要 , 結果明明上游(會產生log file 的系統)就是攪和在一起 ,
要記住 不要為了 XX 而 XX.
在這裡來說就是:不要為了監控而監控.要記住監控真正的原意是什麼.
如果你的上游完全沒有訂出事件的類型,錯誤的情況,處理的方式,甚至是切出log 那麼就會發生 , AP Server 管理人員一天會收到 幾百封的mail , 裡面可能是 JDBC Exception , File not found 各式各樣的問題 , 但是管理人員根本沒有辦法去處理.
結果這樣監控的結果等於就是有跟沒有是一樣的.
要記住 不要為了 XX 而 XX.
不要為了 UML 而 UML 了
不要為了 CMM 而 CMM
不要為了 PM 而 PM
分析與設計01-錯誤案例解析
在進行系統分析與設計時 , 沒有經驗或是沒有動腦的SA/SD 常常會給出錯誤的分析與設計結果
為何說是分析與設計 , 而不單提分析或是單提設計呢 ?
因為常常有很多人以為分析人員可以不需要了解技術 , 不需要了解實作 , 所以常常搞了一堆不會寫程式的人來當 SA ,
可是要記住 , SD 的上游 是SA 的產出 , 當 SA 的產出就是錯誤的時候 , 你就不要期望 SD 的產出會是對的
所以以下的解說,會把 SA/SD 等等混在一起解說
案例1: Web 應用系統的設計 - 長時間的批次作業
使用情境:
在企業環境下 , 可能有某些作業是需要'長時間的且是大量資料處理的作業項目 , 這些作業有一種是由排程自動定時啟動執行(不需要人工介入 , 去啟動) , 另一類則是需要由人工介入 , 來啟動.
原始需求分析:
在web 系統 , 某某頁面,由操作人員輸入"起始年月","結束年月",然後按下"開始轉檔作業"按鈕.
轉檔作業執行結束後,頁面顯示轉檔作業執行成功.
解說:
這上面的需求有幾個盲點,
盲點1: 這是web系統
盲點2: 轉檔作業的需要時間
盲點3:轉檔作業的結束狀態與結果
盲點4: 轉檔作業的過程狀態與監控
首先是web 系統的問題 , web 系統一般來說會有 session timeout 的設定 , 避免有人員連入系統之後 , 一直沒有登出而佔用系統的資源.
而需求上是使用者直接由Web頁面輸入資料,按下按鈕之後,然後系統直接轉檔,轉檔完成後,就直接顯示結果在頁面上.(這是同步作業的樣式 , 但是錯 , 這個需求應該要轉成非同步作業的樣式)
這樣的做法在 desktop 的應用程式可行 , 但是在Web 應用程式上卻是大錯特錯 , 理由是很有可能會因為 session timeout 而結束轉檔作業, 有人會說 那把 session timeout 調長一點 , 例如 24 小時(那肯定是大外行的人會這樣說) , 有哪一個人會真的需要掛在系統上 24 小時的 , 如果設成這樣 , 不如將 session 設成永不 timeout , (那為何要設計 session timeout 呢 ? , 就是要避免系統資源的浪費 , 希望系統在相同的硬體架構下可以服務更多的使用者)
第二是轉檔作業的時間,可能需要一次整批處理幾百萬筆的資料,不太可能在30分鐘內處理完成,可能需要幾個鐘頭才能處理完成.
第三是轉檔作業執行結束,轉檔不見得一定會成功,如果失敗了要如何處理?
這個也是大外行的分析跟設計人員常犯的錯誤 ,
他們都會只考慮作業一定會成功 , 而不考慮如果發生錯誤要如何進行錯誤處理與錯誤回覆
所以如果你問他們如果發生錯誤 , 頁面會如何顯示時 , 他們就答不出來,
如果發生錯誤時 , 轉檔的資料是否會 Rollback 還是會部分寫入 , 他們可能也會答不出來 ,
我的建議解: 請將上述的需求由同步處理 轉成 非同步處理的樣式
需求:
在web 系統 , 某某頁面,由操作人員輸入"起始年月","結束年月",然後按下"開始轉檔作業"按鈕.(頁面會將需求轉成排入批次作業 , 並取得處理批號 , 這裡就是要轉成非同步處理 , 而不是直接進行作業然後等到作業處理完成後 , 才回應結果)
頁面回應 轉檔作業處理批號.
另有批次處理監控頁面,顯示批次處理作業的處理批號,起始時間 , 結束時間 , 目前處理狀態(啟動/處理中/結束) , 結束狀態(成功/失敗) , 結束狀態備註(失敗原因) , 處理筆數 , 啟動人員代碼 , 系統代碼 , 作業代碼.
系統背端會有一服務程式每隔 10 min(閒距可以調整) 去監控批次處理作業的狀態,
如果有發現到批次處理作業沒有結束時間 , 但是起始時間已經超過 4 小時者 , 則需要發警訊(Email) 給系統維護人員進行檢視 , 看看是否該批次作業已經當掉 , 需要重新執行或是進行其他補救動作等等
補充說明:
還有很多更細節的需求 , 例如系統需要根據起始年月 , 結束年月到資料庫的某某 table 去取什麼資料 , 做處理 , 或是要對起始年月 , 結束年月進行輸入資料的檢核等等 , 這些就不用特別標示出來談 , 因為這些是更基本的.
有的沒經驗或是沒有動腦想的分析設計人員真的會做出如上例的原始需求分析,
而且他們還沒有意識到哪裡有錯誤,反正這樣也能執行,然後就Coding , 結果就會是慘不忍睹 ,
這些是我在公司的外包廠商碰到的經驗 , 他們還會理直氣壯的告訴你 , Session Timeout 設長一點(反正就是要你改公司的Server 設定來配合他們的程式)
為何說是分析與設計 , 而不單提分析或是單提設計呢 ?
因為常常有很多人以為分析人員可以不需要了解技術 , 不需要了解實作 , 所以常常搞了一堆不會寫程式的人來當 SA ,
可是要記住 , SD 的上游 是SA 的產出 , 當 SA 的產出就是錯誤的時候 , 你就不要期望 SD 的產出會是對的
所以以下的解說,會把 SA/SD 等等混在一起解說
案例1: Web 應用系統的設計 - 長時間的批次作業
使用情境:
在企業環境下 , 可能有某些作業是需要'長時間的且是大量資料處理的作業項目 , 這些作業有一種是由排程自動定時啟動執行(不需要人工介入 , 去啟動) , 另一類則是需要由人工介入 , 來啟動.
原始需求分析:
在web 系統 , 某某頁面,由操作人員輸入"起始年月","結束年月",然後按下"開始轉檔作業"按鈕.
轉檔作業執行結束後,頁面顯示轉檔作業執行成功.
解說:
這上面的需求有幾個盲點,
盲點1: 這是web系統
盲點2: 轉檔作業的需要時間
盲點3:轉檔作業的結束狀態與結果
盲點4: 轉檔作業的過程狀態與監控
首先是web 系統的問題 , web 系統一般來說會有 session timeout 的設定 , 避免有人員連入系統之後 , 一直沒有登出而佔用系統的資源.
而需求上是使用者直接由Web頁面輸入資料,按下按鈕之後,然後系統直接轉檔,轉檔完成後,就直接顯示結果在頁面上.(這是同步作業的樣式 , 但是錯 , 這個需求應該要轉成非同步作業的樣式)
這樣的做法在 desktop 的應用程式可行 , 但是在Web 應用程式上卻是大錯特錯 , 理由是很有可能會因為 session timeout 而結束轉檔作業, 有人會說 那把 session timeout 調長一點 , 例如 24 小時(那肯定是大外行的人會這樣說) , 有哪一個人會真的需要掛在系統上 24 小時的 , 如果設成這樣 , 不如將 session 設成永不 timeout , (那為何要設計 session timeout 呢 ? , 就是要避免系統資源的浪費 , 希望系統在相同的硬體架構下可以服務更多的使用者)
第二是轉檔作業的時間,可能需要一次整批處理幾百萬筆的資料,不太可能在30分鐘內處理完成,可能需要幾個鐘頭才能處理完成.
第三是轉檔作業執行結束,轉檔不見得一定會成功,如果失敗了要如何處理?
這個也是大外行的分析跟設計人員常犯的錯誤 ,
他們都會只考慮作業一定會成功 , 而不考慮如果發生錯誤要如何進行錯誤處理與錯誤回覆
所以如果你問他們如果發生錯誤 , 頁面會如何顯示時 , 他們就答不出來,
如果發生錯誤時 , 轉檔的資料是否會 Rollback 還是會部分寫入 , 他們可能也會答不出來 ,
我的建議解: 請將上述的需求由同步處理 轉成 非同步處理的樣式
需求:
在web 系統 , 某某頁面,由操作人員輸入"起始年月","結束年月",然後按下"開始轉檔作業"按鈕.(頁面會將需求轉成排入批次作業 , 並取得處理批號 , 這裡就是要轉成非同步處理 , 而不是直接進行作業然後等到作業處理完成後 , 才回應結果)
頁面回應 轉檔作業處理批號.
另有批次處理監控頁面,顯示批次處理作業的處理批號,起始時間 , 結束時間 , 目前處理狀態(啟動/處理中/結束) , 結束狀態(成功/失敗) , 結束狀態備註(失敗原因) , 處理筆數 , 啟動人員代碼 , 系統代碼 , 作業代碼.
系統背端會有一服務程式每隔 10 min(閒距可以調整) 去監控批次處理作業的狀態,
如果有發現到批次處理作業沒有結束時間 , 但是起始時間已經超過 4 小時者 , 則需要發警訊(Email) 給系統維護人員進行檢視 , 看看是否該批次作業已經當掉 , 需要重新執行或是進行其他補救動作等等
補充說明:
還有很多更細節的需求 , 例如系統需要根據起始年月 , 結束年月到資料庫的某某 table 去取什麼資料 , 做處理 , 或是要對起始年月 , 結束年月進行輸入資料的檢核等等 , 這些就不用特別標示出來談 , 因為這些是更基本的.
有的沒經驗或是沒有動腦想的分析設計人員真的會做出如上例的原始需求分析,
而且他們還沒有意識到哪裡有錯誤,反正這樣也能執行,然後就Coding , 結果就會是慘不忍睹 ,
這些是我在公司的外包廠商碰到的經驗 , 他們還會理直氣壯的告訴你 , Session Timeout 設長一點(反正就是要你改公司的Server 設定來配合他們的程式)
2007年2月3日 星期六
除錯心法5
心法10: 不要忘記檢查環境的基本設定-1: 日期時間
有時候軟體系統執行不正常 , 不是因為程式的問題 , 而是因為環境設定的不正確
舉例來說 ,
有些人可能會去調整 Server 的時間設定 , 例如把時間往前調或是往後調 ,
這些設定可能會導致 Server 上的軟體運作不正常 ,
特別是在Cluster 架構下 , 你又只異動其中一台Server
或者是在J2EE Server 環境下 ,
舉例來說 , Tomcat Server 會根據 jsp 檔的修改日期時間 , 來決定要不要重新將jsp 編譯
很久之前 , 有同事去異動了Server上的時間 . 然後當他不斷的去修改 jsp , 卻發現jsp執行的結果 , 一直是舊的jsp頁面執行結果 , 查了很久,才發現是有人異動了Server上的時間 , 導致 Server 檢查jsp 的日期時間時 , 認為 jsp 是不須重新編譯的情況 , 結果不論同事怎麼修改 jsp 就是不會有更新的結果出來
心法11: 不要忘記檢查環境的基本設定-2: Client 的 IE 的編碼設定
之前有發生過 User 來反應 , 他看到系統的頁面 , 是一片空白 ,我們的頁面輸出是big5,
原先以為是系統有問題 , 但是跟其他人的機器一比對,其他人的執行結果都正常 ,
發現只有他的會這樣
去檢查了他的 IE 設定 , 發現他把編碼設定成 UTF-8 , 結果導致頁面出現一片空白
2007年1月8日 星期一
工具介紹-Paros
工具介紹-Paros
Paros 是使用 Java 開發的工具 (可以從 Source Forge 網站下載)
它可以充當 proxy , 並且顯示 瀏覽器與網站中間的 http request & response 的詳細內容
(這個對於要除錯 網站程式 或者是要學習 http 通訊協定是很有用的)
除此之外可以充當簡易版的網站弱點掃描工具
<<我在撰寫 WEB 程式特別是 ExtJS 在除錯時 , 特別有用 , 可以看到到底是因為後端沒有把資料傳回來 , 還是因為前端的 SCRIPT 寫錯>>
此工具啟動後的預設位置為 localhost , port 為 8080
所以 IE 的 proxy 要設定為 localhost , 8080 port
注意事項:
IE 的Proxy 預設值是給 區域網路使用的(如果你是在公司透過區域網路上網 , 此項目就是了)
但是如果你是在家中透過 ADSL 撥接上網 , 則需要設定的 Proxy 是要修改 ADSL 連線的設定的 Proxy 才會有用
2006年11月14日 星期二
閱讀-網路小說
閱讀-網路小說
有一陣子迷上了 , 一些玄幻小說
如: "飄邈之旅" , 或者是像 "誅仙"
這些小說有出實體書 , 可以到租書店去租 .
但是除此之外 , 有些小說可以從網站上找到 , 更新的速度很快 , 幾乎每天都會有一章節的更新 ,
但是除此之外 , 有些小說可以從網站上找到 , 更新的速度很快 , 幾乎每天都會有一章節的更新 ,
最多的是大陸人寫的小說 , 簡單來說有不少 YY 小說 ,
有些寫的不錯 , 有些寫的就還好 ,
看多了大陸人寫的小說 , 唯一的好處是閱讀簡體字的能力增加了 ,
除此之外 , 也觀察到了大陸人的一些特點 ,
有很多小說裡面的情節 , 以下說明是個人觀察心得 , 不是要評判大陸同胞什麼... ,
所以有看的不順眼的千萬不要來打筆仗...
(1)仍然崇尚特權(不論是白道特權 , 黑道特權 , 富豪特權) ,
反正主角總要認識個特權人士來當主角的靠山 , 雖然都要描述主角不愛特權 , 但是總會有那麼讓特權人士出場的機會 , 秀秀主角有多少靠山 , 而主角又能淡然處之 ,
表面上是不崇尚特權 , 但是實際上卻是以跟特權有關係為榮...
(2)起家的第一桶金 , 有 90% 的機會是以不法手段取得
你可以看到有不少篇小說 , 主角很有商業頭腦 , 但是他們要起家的第一桶金, 可能是靠勒索 , 可能是靠搶劫 , 反正你會看到 在主角靠不法手段取得第一桶金後 , 他們的生財大業就容易的多了...
[初次看到這些情節 , 讓我這個在台灣土生土長的人有點無法想像 , 雖然是 YY 小說 ,
如果只有一個作者這樣寫就算了 , 但是不只一個作者寫出類似
需要靠不法手段去取得第一桶金的故事 ,
那就反映出大陸的人與我們這裡的人的認知真的差很多]
(3)民族主義風強盛
有不少小說 , 都會描述到大陸的未來 , 是世界第一 , 世界第一強國 等等 , 這也沒什麼不對 ,
經濟第一 , 科技第一 , .... ,
接著就要開始仇日 , 馬來西亞 , 美國都是仇視對象 , 不過很奇怪的是韓國不在裡面 ,
韓國把 中秋節 , 端午節 , 中醫 都拿去申請世界文化遺產 , 可是卻沒有看到大陸同胞對這些事件說話
說實在話 , 有些小說 寫的還不錯 , 可是突然把民族主義硬掛上去時 , 那個小說就有點變味了 ,
上面是幾個我覺得比較特殊的地方
(4) 其他比較常見的就是 小說主角的設定強度的問題 , 比較容易看的出來可能是剛開始寫作的作者容易犯這種錯誤 ,
有些主角一開始出場就是很強 , 這樣的小說很容易成為太監文 ,
舉例來說 , 如果主角一開始的強度就是可以毀滅地球 , 接著當主角需要碰到比較強的對手時 , 對手可能就要能毀滅太陽系 , 然後如果主角可以成長並且打敗對手 ,
那麼第二個對手的強度可能就要能毀滅銀河系 ,
那個第三個對手的強度可能就要會毀滅宇宙 ,
主角在碰到三個對手後幾乎就沒的玩了 (因為宇宙都毀滅了 , 還玩個屁)...
[所以我說這類文章容易變成太監文的原因就是在此]
好歹也得像漫畫 七龍珠的悟空 一樣是逐步成長的 , 而不是一出場就是超級賽亞人3 ,
那漫畫應該很快就結束了吧...
(5) 另外像校園生活就一定要安排校園惡霸出現
惡霸可能還要跟特權掛在一起 , 例如一些高官
這些大概是比較奇怪的地方 ,
當然也有不少小說不錯
像 臭小子鬧官場 就不錯 , 是以杜撰的歷史與國家當作背景
其他的還蠻多的 ,
另外連上大陸網站看小說要注意的是 , 很多站台有毒 , 所以要小心再小心
2006年11月1日 星期三
OOAD-導入 J2EE 質疑與解說
其實談到 OOAD 很多人的見解都不同 , 像我們公司裡面一堆 微軟派(VB + ASP)的 ,
在先前我們導 J2EE 時 , 有引用了一些Framework(Struts) 或是樣式(MVC) ,
最常碰到的質疑
質疑1: Java (J2EE)寫系統真難用 , 一個功能要分成很多個Class 跟頁面才能完成
解說:
當你將Web 系統使用MVC 觀念並且導入 Struts Framework 時 , 沒錯一個功能是要分成很多個Class 跟頁面才能完成 (但是這些增加的工作 , 有他背後的效益在 , 例如較易維護修改等等)
而質疑的人 , 常常是寫ASP的 ,寫ASP 的沒有引用所謂的MVC 觀念來開發 , 所以相關的檔案數就會比較少 , 有沒有看過把 輸入畫面 , 處理頁面 , 錯誤處理頁面 , 重導頁面通通寫在一個 asp 檔的沒有 ,
檔案數只有一個 , 可是有比較好維護嗎???
如果用ASP 開發時 也導入了 MVC 的樣式 , 那麼它的檔案數也會變的多起來 ,
這個跟你用什麼語言沒關係 , 而是你用了哪些樣式(Patterns)
可是質疑的人根本就不懂 , 他只單純的認為J2EE 就是難用...
可他不知 , MS 系列的開發 , 一旦也導入了相關的設計樣式時 , 也一樣不太好用...
質疑2: Java(J2EE) 是 OO 導向 , 很難學 , 很難用
解說: 看起來好像如此(當時 .Net Frame work 1.0 還沒推廣) , 許多玩VB 的同事質疑 ,
但是今天 .Net 2.0 已經都出來了 , 即便是VB 到了 VB.Net
你也不能以VB 的玩法去寫VB.Net , 而且 .Net 幾乎都是 OO 導向 ,
(還要再找藉口嗎 ? 當作是自己不想要會的理由嗎 ?)
或許可以問問那些提質疑的人 , 是不是改成 .Net 他們就有把握可以做的出來???
注意: 我不是說 .Net 不好 , 爭論 J2EE 或是 .Net 那個比較好 , 並沒有意義
(你個人喜歡用什麼就用什麼 ,
但是就企業來說 , 必須要有一個大方向在 , 用的東西太多太雜 , 只是增加維護人力罷了 ,
一個維護人力又要會 AS400 又要會 .Net 又要會 J2EE , 又要會 #X&$# , 又要會#X%$ ,
苦的是維護人員 , 出包了是整個IT 部門要負責
選 J2EE 或是 .NET 都可以 ,
但是如果有公司是兩邊都選的 , 只是苦了那些維護的人 ,
明明本職技能就差了 , 還要都摸一點 , 結果更是什麼都不會...)
我自己也熟MS的東西 也實際開發過相關的系統 , 對於MS 或是 J2EE 我都可以玩 ,
(沒有一定要偏好哪一種)
J2EE 或 Net 或是 OO 都只是他們的藉口罷了 , 不會的永遠不會...
訂閱:
文章 (Atom)