有些事情，現在不做！永遠都不會做了～～（單車環島日記）

獨孤木　　2006/05/22

上次我們提到，客戶想的和廠商的作法往往出入很大，好比製造一艘船跟製作一張地圖之間的差異。就是因為每個人看問題都是由不同的角度在思考。

為了減少溝通誤差，所以我們會需要為軟體這種概念上的東西建造適當的模型(model)。就像賣房子的人在賣預售屋的時候，會先畫畫圖，做個比例尺縮小後的模型給你看看，再加上個樣品屋，讓你對於完工後的房子有點概念。

所以當我們在建造各式各樣不同的模型時，我們就稱這種動作叫做塑模(modeling)。當你建造了一個模型出來，你就表達出一種你對系統的認知。透過 modeling，我們可以讓客戶了解，我們交出來的成品，會是什麼樣子的東西。設計人員，也可以將問題應該要怎麼解決，整理出一個清楚的輪廓。並且將問 題分解成我們可以解決的部份。當你在打造模型的時候，就會刺激你去思考，要怎麼樣去解決這個問題。

回顧一下歷史，事實上有蠻多種modeling的方法。歷史上比較重要的主流可以區分成兩大類。一種我們稱他為結構化系統分析 (Structured Analysis)，另一種則是物件導向分析設計(Object Oriented Analysis & Design, OOAD)。

結構化系統分析的概念出現得蠻早的。當時，當軟體公司在為大企業開發一套商用系統的時候，最想要描述的，就是資料的儲存以及流動的方式。客戶基本上都是以 他們的人工作業流程來思考。我要買東西，就是要寫一張請購單，給我老闆批過之後，再交給採購去訪價，然後跟我們一起討論，是要用什麼樣的方式來決定廠商。 然後再經過採購的流程去買東西….。

在這種年代，既然客戶要有一張請購單，那請購單怎麼樣可以放在電腦裡面？這就一定要有人需要建檔。那他要怎麼建檔？建檔之後要存在那邊？接下來又要給那些 主管在電腦上確認？廠商的資料又該由誰建檔？…類似這樣的問題就會一一浮現。所以系統分析師就會把重心放在請購單要有什麼樣的資訊，要怎麼樣在各個部門之 間流動，每個部門要填寫些什麼東西，做些什麼動作，然後這些相關的資料要儲存在電腦的什麼地方。

從這個角度去分析商用系統時，事實上就是在幫所有的資料畫地圖。資料不會從天上掉下來。所以不是別的系統餵給你，就是有那個人要負責敲資料進來，要不就是 會從我們自己的系統中演算出來。只要把這個地圖畫得正確，再設計好每種資料儲存的方法，整個系統的分析設計就初步告一段落了。唯一還沒做的，就剩下怎麼去 分析設計每種不同的功能，要採用什麼樣的方法，來處理它所接收到的資料了。

用這種傳統的結構化系統分析的方式，對於描述商用系統來說，是很直覺的一種開發方式。這就像是在規劃旅遊行程一樣，你畫一張地圖出來，標明各個不同的地點 之間，要參觀些什麼樣的景點，然後從第一個地方，要使用什麼樣的交通工具到第二個景點。只要你把這些都標得很清楚，客戶就可以知道，系統做好之後，會是什 麼樣子。

可是這種方法是不是適用於所有的商用系統呢？當然不是。我們拿現在街頭巷尾到處可見的自動提款機來當例子好了。這通常也是很多物件導向分析設計(OOAD)書籍裡面的標準範例。

自動提款機當然還是會牽涉到資訊的流動。所以如果你要做Structured Analysis，還是有可以modeling的部份。比如說成功地把錢吐出來給你之後，要從你帳戶的餘額裡面把存款扣掉。在你輸入密碼時，要確認帳號密碼。

可是除了這個之外，自動提款機還有很多動作，是你如果單純描述資訊的流動時描述不清楚的。這些動作，是系統需要具備的，它通常是跟系統在遇到各式各樣的狀況時，應該要做什麼樣的回應。這也就是為什麼我們會有所謂的OOAD這樣的方法跑出來。

當我們採用OOAD的方法來看系統時，通常就是要先把一種一種不同的物件把它給區分出來。比如說自動提款機有個吐鈔口，有個小螢幕，有個小鍵盤，裡面有擺錢的小軌道。

所以在做物件導向分析設計時，你會想要把物件給找出來，這會是第一個步驟。接著則是要想想，每個物件，在遇到各式各樣事件發生時，要做些什麼樣的反應。比 如說，吐鈔口如果收到命令要吐錢出來，可是吐鈔口就是打不開，這時候要怎麼辦？裝現金的抽屜櫃裡面，沒有小面額的鈔票又該怎麼辦？跟金資中心連線不通、密 碼輸入三次不對、存款不足、扣款成功…當這些狀況發生時，又該怎麼辦？這台機器的各個物件之間，在遇到各式各樣的狀況時，要怎麼要回應給使用者。這就會是 當你在進行分析設計時，所需要model的重點。

所以這兩種不同的modeling方法，實際上是為了解決不同種類的問題所衍生出來的。有些時候，你需要從一個層面去看問題；有些時候，你需要從另外一個角度去看問題。(待續)