有一篇文章寫得真好!

關於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的具體方法中的一種。