2008年4月24日 星期四

有一篇文章寫得真好!

關於OOA的
果然薑是老的辣!
!

有某位硬派的老師說SA用txt檔就可以搞定了
我想說我們用jpg 檔(<--數位相機拍白板)就搞定了 更酷

20080428補充

嗯後來看看只有5行的文字不太能表達我要說的是什麼(太混了吧你!!!),來補一下

回憶起在四年前的這個月份,喵尾巴參與了一個大專案
當時它因為發標不順利,開始執行的時間已經比預期 delay 了三個月
但是上包商還是十分有種(拍拍手了不起)的承諾業主會如期交付 噹噹~~~ SA/SD文件
當時我們一天工作平均14~16個小時,可說在各系統(包括自己的)的責任都混沌不明的狀態下趕出一本厚達兩百多頁的報告
用的是神兵利器 rational rose (這玩意神到你裝起來用筆電都會軋軋叫)

不過,在這樣混沌的情況下
應該是先搞清楚你的子系統有些什麼樣的責任
要和其它系統如何介接,這時候怎麼會輪得到rose 這種東西出場?
錄音機、白版和筆記本加上充份的溝通(工程師 <--> PM<--> 使用者)才是王道啊
但是當年也是在交付時限的壓力下,十分神勇的用rose 搞了一些自已都不相信的鬼圖出來
啥咪use case, 繼承,啥咪design pattern 其實一筆一劃都是心虛啊,user 和其它client 怎麼用系統都不知道這些設計怎麼驗證。充其量只能說:「我們盡力滿足上包商的要求」,而不是「我們盡力做了系統分析設計」我記得當時真的很希望沒有人會認真看這東東:因為這種文件最厲害的地方是,即使它圖文並茂,頁數超多,你看很久,死了許多腦細胞還是不會了解它在幹麻(因為連原作者都淪陷了嘛啊哈哈~)。

我要說的是
不是UML不好 而是 「不是有 UML 畫出來的圖就好」
UML 在大系統中的確是可以幫助不同團隊間的溝通,但是個人認為它是輔助了解的工具,而不是SA/SD最終產物。系統分析設計做得好,的確用文字描述也可以達到溝通的效果,只不過沒有圖表那麼賞心悦目罷了;個人覺得,純文字的部份才是決定SA工作品質的關鍵,因為靠它才能見真章啊。到現在為止,我一直在猜,如果把那十幾個系統的系統文件濃縮成每系統三頁的文字檔,審查的人一定能一眼看出我們在鬼扯蛋,而不是對著那厚厚的文件山翻兩個月後挑些不關痛癢的偽審查意見回來。(嘿嘿結果那系統後來在實作階段,開會還是都在吵一些分析時就應該釐清的重點)

嗯回到上面推的文章,它把怎麼做一個OOA model, 怎麼驗證一個 OOA model 都講得很清楚。那是做「真的」SA的具體方法中的一種。

2008年4月23日 星期三

噢~沮喪斃了

最近幾天十分的苦惱 
原因是來自一個審查論文的工作
這篇被交到我手上的論文,說真的只能用淒慘兩字來形容
從立論、建立模型的方法、到拼字、文法都非常有問題,有問題到真的會想敲敲這作者的頭,問他一聲你還好嗎?
要把這篇鬼東西看完,簡直是精神上的酷刑,看了兩頁之後,連再拿起這玩意的勇氣都沒有
tony 老師說要儘量審,儘量看懂
哎我明白這是對投稿者的誠意,也是一個學術工作者敬業的表現
但是哎喲喂,我真想逃跑 
星期天我在百般無奈與無名大火燒起的情形下在這裏留了一篇發洩文,大意是說這篇文章有多差,還有我有多火大之類的
不過後來覺得不能隨便拿情緒丟大家所以就把那篇刪了
可是…可是… 
我真的不甘願把時間花在這種沒事找事的爛東西上
我還有其它更多更該作的事啊...多寫幾個自動測試 多練一下演算法 陪女兒玩一下 都比這個有意義得多 這篇文章的學術貢獻是零,然後還連帶害reviewer 的產能降低 該死的…還有比這更笨的事嗎? 

各位對不起了 我還是亂丟情緒 該死的 因為實在沮喪斃了

2008年4月6日 星期日

高網reading assignment 心得~

這學期修了一科高等網路,這門課蠻精采的,因為老師的學問十分淵博,而且也有王牌貝爾實驗室的實務經驗,所以也能夠透過一些實際上的例子,讓我們將複雜的網路理論、統計及數學和實務上要處理的問題連在一起。

不過像老師是這樣的強者,也是有一些令人傷腦筋的地方,比方說對強者而言,一些基礎的數學與統計是必備知識,上星期出了一篇reading assignment, 喵尾巴一看之下險些沒有昏倒,超多統計和積分的符號,不出幾秒就把acrobat關了,怕影響消化(當時在吃晚飯),並且一面心想強者和弱者真的是差太多了~

不過這篇論文被擺了幾天之後,心裡還是隱隱覺得不安,想說難得修了高網,怎可輕易放過level up 的好機會? 所以再拿起來看,順便複習一些基礎的數學:
這篇文章要解的題目是,假設對於網路 QoS 的要求的Criteria 為end to end delay 對於某一延遲時間t(i.g., 5 sec) 的overdue probability(p) 的話;我們要如何將這樣的要求,allocate 在單一的network component 上? 而不用每一種可能的end to end path都做monitor ?
在這篇文章裏提到的數學武器有下列數種:
(0) 一個path 上關於end to end 的measure 由path 上element 貢獻所得

(1) Convolution
Convolution,這篇論文章的應用是:當有兩個random variable合成的時候,它們的probability distributed function (pdf)會形成何種分布? 答案即是此兩個變數的pdf 的Convolution.
單純用這個方法,配合(0)的定義,解得的解為:
每一個element 的delay 為t/k, 而每個element 的overdue probability 為 1- (1-p)^k。這樣的解簡單,但是太過保守。

(2) Laplace transform 是?
在通信領域中,是指將時間域中的函數轉換成在頻率域中的函數。在時間域中的捲積等於在頻率域中的乘積,可以簡化計算。在這篇文章中是應用重點。(其實是蠻古遠的記憶了,好像大二工程數學有教過嘿,不過全忘光光~)
本篇論文利用queue theory 的model,將interarrival time distribution 及 service time distribution作Laplace transform 之後,會很漂亮(神秘)的得到一個element 上waiting time pdf下限。這時卷積又可以派得上用場,大意是說函數下限的捲積是函數捲積的下限。利用對這個下限值的限制可以反推重要的參數,如,utilization.

(3) Markov inequality
Markov's inequality gives an upper bound for the probability that a non-negative function of a random variable is greater than or equal to some positive constant (– from wikipedia)
它的form 為:
Pr(|X|>=a) <= E(|X|)/a
就是說,如果知道一個random variable 的Mean值,就可以用上面的式子求取這個random variable 大於某正數的機率. 可以直接套來解這個問題。所得的參數為每個element 上的mean delay.

(4) Chebychev inequality
In probability theory, Chebyshev's inequality (also known as Tchebysheff's inequality, Chebyshev's theorem, or the Bienaymé-Chebyshev inequality), named after Pafnuty Chebyshev but first formulated by his friend and colleague Irénée-Jules Bienaymé[1], states that in any data sample or probability distribution, nearly all the values are close to the mean value, and provides a quantitative description of "nearly all" and "close to". (- from wikipedia) (寫到這裏不禁慶幸網路可以讓我們與世界接軌~)
它的form 可以表示如下:
P[X-E(X)>=t] <= 1/(1 + t2/Var(X)) 這是one side 的Chebychev inequality, 就是說如果t > E(X)的話可以這樣用。(t < E(X)的話稍稍做點變化就可以算了。) 如果知道一個random variable 的mean和variance 就可以用上式求取此數大於某值的機率。也可以直接應用來解題。

(5) Normal distribution
如果有k個random variable, 其分佈為normal distribution, 它們線性組合出的數的probability distribution function也為normal distribution. 可以直接套用解題。
由以上五種方法看來,可知要解這個問題,統計的觀念必須要好一點才行…拿出課本K吧!