第二章 分析（ANALYSIS）
───────────────────────────────────────
如果有人告訴你，軟體的發展週期有一定的階段劃分，他是個傻瓜。 然而 ....
程式發展週期的九個階段
如我們在第一章中所見，符式已將軟體的設計、實現及維護三者揉合在一起。結果使 所謂的"典型的發展週期"的說法聽起來像是典型的噪音。 然而，任何方法總比沒有方法好，而且某些方法也的確比另一些方法來得有效。下面 是從一些最成功的軟體案例所使用的方法中，所獲得的一個發展週期的平均值：
分析階段（Analysis）
1. 發掘需求（Requirements）及束縛（constraints） 2. 建構出解決方案的概念性模型 3. 概估經費／進度／性能
工程階段（Engineering)
4. 初步的設計 5. 細部的設計 6. 實現
使用階段（Usage）
7. 最佳化 8. 驗証及除錯 9. 維護
本書將針對前六項予以探討，其重點置於分析、設計及實現。 以一個符式的發展計劃來說，這些階段發生在不同的層次上。從計劃的最廣面來看， 這些階段很可能各自需要一個月以上的時間，一個階段跟著一個階段，如同季節的交替。 但是符式程式設計師也將這些相同的階段使用在定義一個字的時候。這時，各階段的 反覆週期就是以分秒計了。 這種藉著快速的反覆週期以發展應用程式的方法稱為"反覆接近法"（Iterative Approach）。
反覆接近法
Kim Harris[1]對這種反覆作為的解釋最有見解。他先從描述科學上的方法開始：
.... 一種永不休止的發現與精製的週期。從研究一個自然系統（natural system） 開始，對它的行為蒐集到一些觀察的結果，然後這些結果被模型化（modeled）以產 生一種關於這個系統的理論。接下來，對這個模型加以分析並預測出一些關於這個 系統的行為，並進行實驗，以比較系統的真實行為與預測行為之間的差異，從而再 重新對自然系統作一番研究，並修改模型。 此一方法的目標是要產生一個模型，它能夠精確地預測出所有這個自然系統的可 被觀測的行為。
然後Harris將此一科學方法應用到軟體發展週期，並以圖2-1為說明：
1. 問題經分析後，以決定解決方案中所需要的功能是哪些。 2. 決定如何藉現有的資源，以達成上述功能。 3. 寫出程式，企圖以此實現此項設計。 4. 該程式經由測試，以決定是否已正確地達到這種功能。
圖2-1 軟體發展週期的反覆作為。摘自Dr. Dobby期刊，〈符式哲理〉一文
Harris補充說：
在符式中發展軟體，首先要設法找出問題的最簡單的解決方案。其做法是先分別地 實現問題中某些選定的部份，並且儘可能忽略那些束縛事項。然後將一項或幾項的束縛 考慮進來，程式再跟著修改。
對這種發展與測試並行的設計模式而言，最好的見證就是進化論。從原生物到蝌蚪、 到人類，每一個物種從古至今一路上，豈不都是由具功能性的，活生生的生命所組成。 造物者並不是一位"由上向下"的設計師。
─────────────────────────────────────
提示 起步時力求簡單。先讓程式跑起來。從中弄清楚你要做的是什麼。逐 漸加繁，以求能符合需求及束縛。不要害怕從頭再來。
─────────────────────────────────────
做計劃的價值（The value of Planning）
在前述的九個階段中，我們在"實現"階段之前竟列出了五個階段。但卻在第一章中 強調，過份地耽溺於計劃的困難與不智。究竟該何去何從？ 其實，不論你使用那種語言來進行一件重大的程式設計，都免不了要有某種程度的計 劃作為。但何種程度才算恰當？
───────────────────────────────────────
許多符式程式設計師都推崇 Dave Johnson 的細密計劃方式。Johnson是賓州 Springhouse城的Moore
Products公司的督察員，該公司專長於工業用儀器及製程控制應 用。Johnson從1978年開始使用符式至今。 他說明他的作法：
和其他使用符式的人比起來，我們所用的可能是較為正統的辦法。但學到這一手確 也吃盡苦頭。我在早年的那種散漫無章的做法總會如影隨形地找上我。
我們用兩件工具來應付新產品：一個功能性規格及一個設計規格。我們的銷售及應 用部門負責提供跟客戶接觸後所得來的功能性規格。
一旦達成了同意從事某一案件的協議，該案件的功能性規格就會轉送到本部門。由此 我們展開設計工作，並做出我們的設計規格。
到此為止，所走的途徑和使用其它語言的人並無不同。但是使用符式，設計行動會 有些不同。使用符式，你不必等你的設計完成了95％才動手去寫程式碼，其實只要 完成約60％就可以進入反覆的程序。
通常的案件多半是在現有產品上做某些功能性的改良。例如我們有一台帶有磁碟機的 終端機，需要某種通信協定去和別的裝置溝通。這個案件包括了協定的設計，提供畫 面顯示及操作員的介面等等，也許需要數月才能完成。功能性規格費時一個月；設計 規格費時一個月；撰寫程式碼要三個月；組合及測試再加一個月。
這是一般的情況。曾經有的案件拖上兩年，但是六、七個月的時間是合理的。
在五年前我們開始使用符式時，情形卻不是這樣。我只要接到一件功能規格，就立刻 動手寫程式碼。我採用"由上向下"與"由下向上"相互交替的辦法，先一般性地定 義一個結構，若有需要，就進入較低的一些階層中，然後帶著更多的結構回來。
採用這種做法的原因是為了能夠展示一些成果，以應付經理人員那邊來的壓力。我們 被打擾得根本沒能記錄下當時的所做所為。而三年以後，可能要在沒有任何文件可供 參考的情形下，回頭修改程式碼。在這種情況下，符式變成了一種不利的東西，因為 她讓我們能夠太早著手進行。讓那些燈光閃個不停，磁碟機嗡嗡叫，固然蠻好玩的。 但是我們卻沒有經歷過那一段支末細節的設計程序。正像我前面所說的，"自由的精 靈"回來找我們算賬了。
如今，對那些新進的程式設計師，我們有一套已建立好的要求：一個完整的設計規格 ，它詳細地定義出所有的符式高階字 --那也原本就是案件中所要做的工作。不再是 讀幾頁規格，處理掉它們，再讀幾頁，再處理它們，等等這樣的情形了。
沒有一個活著的程式設計師喜歡做文件記錄的工作。但是只要能確保設計一定發生在 寫碼之前，我們就能夠在幾年後仍然可以回想起我們所曾經做過的事情。
要在此一提的是，我們在設計階段中會寫出一些程式碼來測試某些想法。這些碼很 可能並非是成品中的一部份。其用意只是要嘗試出我們所可能會採用的設計方式。
───────────────────────────────────────
Johnson忠告我們，要我們在開始寫程式碼之前，先完成設計規格，但初期測試所需 的程式碼除外。下一段訪談也支持這種觀點，卻增加了一些新的理由。
───────────────────────────────────────
John Teleska從1976年獨立執業軟體設計顧問至今，專長於學術研究機構的訂製型
應用軟體。他喜歡提供所謂"現代科技邊緣所能提供的"研究工具。
依我看來，軟體發展週期應分為兩個階段，第一是要確知我了解問題之所在；第二是 實現，包括除錯及驗證等。
在第一階段中，我的目標是一份作業規格。從問題的描述開始，當我繼續向前進行時 ，它就漸漸變成了作業規格。我對問題的了解因而轉化為一個解決方案。這種了解越 多，解決方案就越完整。我所尋求的是終結（closure,即國會中的辯論終結，付諸表 決之意）； 那是一種所有問題的解答都已經被寫在紙上的那種感覺。
我也發現到，在每一個計劃中我用在第一階段的時間總是比較多，多到會引起客戶的 恐慌。這個時間的限制是要看我能說服客戶的程度，讓他們相信發展初期所耗費的時 間是必需的。客戶通常並不知道他們想要做的那件事的規格是怎樣的。他們也沒有 資金 --或許他們並不覺得他們有資金-- 可以花費在建立良好的規格上。我的工作 的一部份就是要告訴他們，若不這樣做，到頭來終必花費更多的時間和金錢。
第一階段也會花費一些時間在可行性的研究上。從規格的撰寫中可以暴露出不確定的 事項。我對不確定事項會儘可能地保持不確定的態度。舉例來說，或許他們想要在一 秒鐘內收集200,000份的樣本，而且要達到某種的精確度。我首先就會要看看他們現 有的設備是否有能力做到這一點。在這種情形下，我就會寫下一大堆的程式碼，來測 試它的可行性。
寫出這種規格的另一個理由是保護我自己。萬一那套應用程式的確是達到了這個規 格，祗是不能盡如客戶之意，則其責任應歸於客戶。若客戶想要更好的，大家就 得重新談判。但我總認為，設計者的責任應該是儘可能地去產生一份規格，從而完 成令客戶滿意的的工作。
有些顧問怕丟掉生意而向客戶的壓力低頭，自限其應花費在規格上的時間。但這種做 法到頭來是沒有人會愉快的。
───────────────────────────────────────
做計劃的極限（The Limitation of Planning）
經驗告訴我們，在著手寫程式碼之前應先將設計工作做完。但是，計劃是有其極限的 。下面的訪談對計劃作為的價值提供了不同的看法。
───────────────────────────────────────
姑且不論Teleska多麼偏好週密計劃過的發展案，他卻也建議，"由上向下"或"由下
向上"兩種途徑的選擇是要視情況而定：
最近，在一個涉及大量介面（interface）工作的案件中，我全部是採用由下向上的 途徑。我迷失在一大疊的資料和描述著相關的作業系統上某些小缺陷的技術性文件 中。多半的時間我都頭昏腦脹，甚至懷疑當初是否該接下這筆生意。直到最後， 我終於讀完了其中的某些重要資料，開始能夠將一些小程式湊合到一起，而讓一些 小事情發生。我繼續著，從下向上，直到我達成了目標。
我內心的那個"由上向下"的觀念被這種程序嚇壞了。但我這樣做而成功的例子實在 很多，令我不能因為學術上的理由（譯註：指的是在學校所教授的那套"由上向下" 的做法）而捨棄它。而這類不是線性思考所能克服的困難階段總是會出現。程式設 計這玩意所使用的直覺似乎遠比我們這一行人所相互告知的為多。
我認為，如果一個應用程式會引發這種迷失之感，我就採用由下向上的辦法；如 果它是我所熟悉的領域，我可能會按照教科書上的那一套來做。
───────────────────────────────────────
下面是另一種看法：
───────────────────────────────────────
我訪問Union Carbide公司的Michael
Starling，當時他正在為兩個應用程式做最後 的潤飾，那是可以由使用者自行改變組合的實驗室自動化及製程控制自動化系統。對此
示範性的實驗工廠，其中的硬體和軟體都是Starling依客戶的需求所設計的；在實驗室 自動化系統上，他也親自為需求定下了規格。
他的這些努力都非常成功。在某一案中，新系統的花費僅及同類系統的20％，安裝及 組合所需時間是以日計，而非以月計。 我請教他對計劃案的管理技巧何在：
這兩個案子都是需要好好地設計的。可是我並未遵照傳統的分析方法。我所採取的是 下列步驟：
首先，我清清楚楚地定義出問題的界限（boundaries）。
其次，我決定那些較小的功能組件，或軟體子系統（subsystem ）應該做些什麼。
最後，我把每一件都做出來，組合在一起，系統就跑起來了。
然後，我問使用者「這合乎你的需求嗎？」。有時答案是否定的，而且竟出乎使用者 和規格設計人員的預料之外。
舉例來說，起初設計者並沒看出，按照原始規格是無法產生令人愉快、人性導向的圖 形畫面的。試用這個交談式畫面的第一個版本後，才發現若使用者任意地設定各種比 例時，會冒出稀奇古怪的圖形。
甚至是在基本繪圖演算法的設計完成了之後，我們才認識到自動比例變更的必要。 我們只好再回頭，對人類如何畫出資料的方法又作了一番分析，才完成了第一階段 的繪圖功能。它能自行估算出適當的ｘ及ｙ座標值，以決定多少才能合得上那張圖。
在那之後我們又認識到，並非所有得到的資料都是實驗室人員所感興趣的，於是我們 又添加了一項伸縮（zoom）功能。
這種反覆作為的方法，其結果是得到更清晰，考慮更週詳的程式碼。我們先建立一 組最基本的目標，並按照使用者已知的需求構建出一個小型的系統。然後將程式設計 師的經驗投入去改良它，並找出使用者當初建立規格時，需要而卻遺忘的是什麼。
新的概念大多並非由使用者發明的，而是經由程式設計師做到的。他們會使新的概念 從使用者那兒冒出來。替問題下定義像是一種雙向的街道。有時候，使用者怎樣也想 像不到，在那麼小的電腦上竟能完成諸如對資料進行數位濾波及信號處理那樣的事。
符式之所以能讓這種途徑行得通，其道理之一在於基本元件的容易測試。這需要對符 式有些經驗才能撿到這種便宜。從傳統環境下出身的人，總是指望坐在桌邊，寫出十 大張的程式碼，坐在打字機前鍵入，然後~FB7;期望~I;它能工作。
總結我的方法： 設法找出使用者所需要的是些什麼，但同時也要認識清楚，那些東 西並不完整。然後我在實現階段中，讓他們也投身到設計工作上，因為他們有使用那 些設備的專家。
等到他們眼見結果誕生，就會興高采烈，因為他們知道自己的概念也溶入其中。
反覆作為的最高價值在於能對真正的問題產生良好的解決方案。它或許不能提供精確 的經費預估。通往解決方案之路得依你的優先次序選擇而定。記住：
良好 快速 便宜
任選兩項就夠了！
───────────────────────────────────────
按Starling的看法，你並不完全清楚你在做什麼，直到你做過它一次。以我的經驗來 說，最好的撰寫應用程式的辦法是寫它兩次。丟掉那份初稿，把它看作是一份經驗罷了。
───────────────────────────────────────
Peter Kogge是IBM公司駐紐約州Federal
System分公司的資深技術師，他說：
我發現，符式語言最大的優點是她容許我很快地做出一個原型的應用程式，而不必去 處理一大堆裝飾門面的功能。而且，雖然經常有很大的限制，卻仍足以寫出..."人 機介面"。
當我建造這個原型時，我是在一種自我設限的情況之下去做的，也就是說，我決不將
原型中的任何一列程式碼用在最後的程式中。這種強迫式的"重新做過"（do-over）
總會得到更簡潔、更雅緻的最後程式，即使這些程式碼是用符式以外的語言寫成時 也一樣。
───────────────────────────────────────
我們的結論呢？ 在符式的環境下，計劃是有其必要，但應保持短小。測試與建造 原型才是發現真正需求的最好途徑。 在此要提醒計劃案經理（project manager）一句話：如果你督導的是任何一個有經 驗的符式程式設計師，你不必擔心他會花太多時間在計劃上。於是下列的提示就出現 兩個版本：
─────────────────────────────────────
提示 對符式的新手來說（帶有"傳統"背景者）：保持分析階段在最小的程度。
對符式的上癮者來說（不帶"傳統"背景者）：只要你受得了，儘可能延後程式碼的 寫作。
─────────────────────────────────────
或如第一章所說：
─────────────────────────────────────
提示 做出能夠因應"變動"的計劃（經由設計出能夠承受變動的元件）。
─────────────────────────────────────
或簡單地說：
─────────────────────────────────────
提示 製做原型（Prototype）。
─────────────────────────────────────
分析階段（The Analysis Phase）
本章從現在起，要討論分析階段。分析是一種有組織的了解並記錄程式中所應該做 的事的方法。 以一個寫給自己用的，在不到一小時內就完成了的某一程式來說，其中的分析階段可 能只佔用250微秒。以另一極端來說，某一案卻要費時好幾年才能完成。對於這樣的案例 ，其分析階段則攸關全案的成敗。 我們曾指出分析階段的三個部份：
1. 發掘需求及束縛 2. 建構出解決方案的概念性模型 3. 概估經費／進度／性能
現將逐條詳述如下：
發掘需求
第一步要決定此一應用程式要做的是什麼。客戶，或想要此一系統之任何人，應該提 供一份"需求規格"。這是一份平實的文件，其中列出成品所要具有的最低性能。
分析師可以經由提出問題、舉行會商、或向使用者發出問卷，得到更進一步的資訊。
發掘束縛
下一步要找出限制因素。速度重要到何種程度？有多少記憶體可供使用？何時交貨？ 不論我們的科技多麼進步，程式設計師總會碰上一些限制。系統的性能免不了會隨時
光遞降。原來是人們夢寐以求的雙密磁碟機，現在已不值一文。我那即將到手的雙面雙密 磁碟機應該會風光一時
--但恐怕也是過眼雲煙。有個傢伙一直向我抱怨，總怪他那10M byte硬碟機礙手礙腳。 每當缺少某種東西時 --這是常有的事--
就勢必有取捨之決定。最好的辦法還是利用 分析階段去看出大部份的限制因素，並決定取捨。
另一方面，你不該在分析階段去考慮其他類型的束縛事項，而應等到進入實現階段時 ，再逐個去考慮他們，那就像揉麵加料一樣，一步一步來。
在分析階段中所要考慮的束縛事項，包括那些可能會影響到總體做法的事物。而能夠 延後考慮的束縛，則是那些能在已經計劃好的軟體設計中，藉著反覆精製的做法而解決
的。 我們前面那些訪問談話中已經說過，若想找出硬體有關的束縛事項，就必須寫出一
些程式碼，以便將它們測試出來。若想找出客戶的束縛事項，只要靠口頭去問問題就能辦 到，當然也可藉著問卷調查。
建構解決方案的概念性模型
所謂概念性模型就是問題的想像中之解決方案。它是對系統大概會如何工作的一種見 解。它是一切需求事項及束縛事項的答案。 若需求被定義成：「可以站立其上，以便於刷天花板的某種東西」，那麼對這個概 念性模型的描述就是「一種可以自由地站在上面的東西（以便你粉刷室中央），帶有幾塊 間隔適當的踏腳板（你才能爬上爬下），而且在靠近頂端要有一塊平板（以便擱放你的 油漆罐）」。 但概念性模型還不能說是一種設計。一種設計是要從描寫一個系統如何"真正地"工 作開始。在設計中，一個梯架的影像應該開始浮現。 符式會使得這二者有些難以分辨，因為所有的定義都是使用較低階層元件的詞集中的 一種概念性的事物（字）所寫出來的。事實上，在本章後半部我們將會使用符式的"虛擬 程式碼"來描述概念性模型的解決方案。 然而，若能分辨其中差異卻是有益無害。概念性模型要比一個設計來得有彈性。讓需 求及束縛事項能夠吻合到一個模型內，要比吻合於一個設計來得容易。
─────────────────────────────────────
提示 先力求構建一個內容充實的模型，再開始設計。
─────────────────────────────────────
所謂分析，它原本就有將"需求的定義"擴張為"概念性模型"的含意在內。這種技巧涉 及到和客戶之間持續不斷的雙向溝通，以充分地描述模型。 如同發展週期的全程，分析最好也採取反覆進行的方式。每個新需求的來臨，總會對 你心中那個模型有所提示。你的工作就是要抱著那些需求和束縛，一直到你編織出一個配 得上那疊鈔票的樣本為止。 圖2-2是分析階段反覆作為之一例。其中最重要的是那最後一步：也就是將形之於文 字的模型展示給客戶看。你要盡一切可用的溝通手段 --圖表、漫畫等等-- 把你所了解的 傳達給客戶，而且要得到必需的回饋。這種做法，就算做它一百次也是值得的。
圖2-2 在分析上的一種反覆接近法
以下三節中，我們要討論如何對概念性模型下定義，以及如何將它形之於文字：
1. 定義介面（Defining the Interfaces ） 2.
定義規則（Defining the Rules） 3. 定義資料結構（Defining the Data Structures）
定義介面（Defining the Interface）
─────────────────────────────────────
提示
首先，也是最重要的，概念性模型應該將系統的介面描述出來。
─────────────────────────────────────
───────────────────────────────────────
Teleska說：
"規格"基本上是與"什麼"（WHAT）相關的。它以最耀眼的形式，描繪出客戶將來會 看到的這套系統 --你不妨稱它為使用手冊。我發現我對人機交互動作（human inter -action）--從外面看來它像什麼--所做的筆記，比如何完成這份工作的筆記所做的 還多。舉例來說，我寫下一大張錯誤動作表，以表示某一特定錯誤出現時所會引發 的事情。真怪，這竟然是在我到達實現階段之前，花費時間最多的部份。
目前我正在設計一件工業用洗濯機的定時器，在這件個案中，使用者介面並不那麼複 雜。複雜的是洗濯機的介面，對於此點，我必須仰賴客戶以及客戶所能提供的文件。
最關緊要的介面是要弄清楚產品的人機介面是什麼。在發展的早期階段，我並不去 分辨何者為硬體，何者為軟體，他們在實現階段中是可以互相易位的。
設計硬體過程和設計軟體過程相類似。我設計硬體的辦法是把它當作一個黑盒子看待 ，面板是輸入和輸出裝置。你也可以同樣地看待軟體。 我運用各種技巧，圖表等等，依照客戶對產品功能的描述，向他們展示輸入輸出會是 何等模樣。但同時，在我心裡，我想像著它們該如何被實現。我是在評估是否能做的 有效率。對我而言，它並不是黑盒子，而是個灰盒子。設計者必須有能力看到這個盒 子的內部。
當我設計一個有不同模組的系統時，我會設法把其間的耦合做到儘可能合理，儘可能 地少。但總是有得有失，因為你總是要和理想妥協的。
關於文件的記載，我用DFD（即資料流程圖，我們在下一節就會討論它），以及其它
表達方法去顯示給客戶看。我儘可能多用圖表，以便澄清我所了解的。但是一旦實 現階段開始，我就很少再使用它們。
───────────────────────────────────────
─────────────────────────────────────
提示 僅早決定錯誤及特例的處理方式，最好在定義介面時就進行。
─────────────────────────────────────
當一個人為自己寫程式碼時，他多半會先將心力投注到程式碼能在正常情況下跑得正 確這一點上，等以後再為錯誤處理（error-handling）發愁不遲。但是，當為別人寫程式 時，錯誤處理這件事就該早點解決掉。這是初寫程式者經常疏忽之處。 在這個階段就要決定錯誤處理的方式之所以重要，其理由在於錯誤的處理方式有它 廣汎的差異性。一個錯誤可能是：
－可以被忽略 －用來設定一個旗標，指出有個錯誤發生了，而程序繼續進行下去 －使應用程式立即停止 －被設計來啟動一個更正程序，以解決問題，並使程式繼續執行
如果不讓錯誤處理的複雜度在早期就被確定下來，可能會與客戶出現嚴重的溝通縫隙 。顯而易見的，這種選擇將會極度地影響應用程式的設計與實現。
─────────────────────────────────────
提示 以想像資料是如何的流通的，以及如何被模型的各部份所運作，來發展此一概念性的 模型。
─────────────────────────────────────
有一套所謂"結構化分析"[2]的規範提供了一些技巧，用來描述介面，使你的 客戶一看就懂。其中之一叫做"資料流程圖"（DFD），為Teleska所提出。 圖2-3可看出其中強調各項資料在流經這個系統中途所發生的事情。圓圈代表 "轉化 區"（transform ），各種功能在此作用於資訊上。箭頭代表轉化區之輸入與輸出。 圖中顯示系統在運作中某一凍結之片刻，它暫時忽略初值設定，迴路結構，及其它 與時間相關的程式設計細節。
圖2-3 資料流程圖一例
一般來說，使用DFD有三項好處：
第一，它簡單而又直截了當。如果你的客戶同意你在資料流程圖中所表達的內容，你就知道你對問題已經有所了解。
第二，它讓你以邏輯上的"什麼"（whats）去思考，而不會讓你受困於那些程序上的"如何"（hows ），這與我們在第一章中所討論的資訊隱藏的哲理是一致的。
第三，它讓你的注意力集中在系統的介面上，以及模組之間的介面上。
符式程式設計師，若非顧慮對客戶的好處，是不會使用DFD的。符式鼓勵你以概念性的模型（譯註：就是"字"）來思考，而且符式隱含地使用資料堆疊，已經使模組間的資
料傳送簡化到你能安心使用的地步。這是因為符式 --若用的得當-- 已趨近於功能化的語言（functional language）。
對任何人來說，只要他和符式有幾天的交情，下列簡單的定義至少已能傳遞DFD所表達的同樣訊息。
: 申請 ( 數量 品名 --)
有庫存嗎? 如果 寫出貨單 否則 再訂貨 然後 ;
: 再訂貨 有授權嗎? 如果 寫訂貨單 然後 ;
: 寫訂貨單 簿記部 拷貝 收貨部 拷貝 廠商 郵寄拷貝 ;
這
是符式的虛擬程式碼。其中並未決定什麼樣的值實際的被傳送到堆疊上，因為那是實現時的細節事項。『申請』的定義中的堆疊註解，是用來說明這個過程開始時所需要的兩項資料而已。
（如果是我在設計這個應用程式，我倒要建議"使用者介面"是一個叫做『需要』的詞，其語法如下：
需要 50 輪軸
『需要』將數量50轉化為堆疊上的一個數值，並將字串"輪軸"轉譯為品名代碼，也放在堆疊上，然後呼叫『申請』。這樣的一個命令應該被定義在最外層。）
───────────────────────────────────────
Johnson對符式虛擬程式碼有他的看法：
IBM使用一種嚴謹的文件記錄PDL程式設計語言（Program Design
Language）。我們 也用，但我們叫它FDL（FORTH Design Language ）。有這些標準也許是值得
的，然而你一旦熟諳了符式語言，符式本身就可以做為設計用的語言。你儘管先撇 開所謂"噪音"的那些字：如 C@，DUP，OVER
等等，僅顯示基本的流程就行了。大多 數的符式使用者都已經非正式地那樣做了，而我們卻是有意的那樣做。
───────────────────────────────────────
有一次訪問符式發明人Moore先生，我問他，在計劃概念性模型時，是否用到任何種 類的圖表，或者他直接鍵入程式碼？他回答說：
概念性模型就是符式。學了那麼多年，我就是那麼想的。
是否也有人能像他這樣想？
我佔了些便宜。我以自己撰寫程式的風格來建出符式，然後別人跟隨著採用。我沒料 到會發生這種事，真是受寵若驚。我之所以感覺佔便宜是因為那是我的風格，而其他 人在模倣它。他們是否也能學會像我一樣的思考？我想是做得到的。畢竟那只不過 是練不練習的問題，而我練習的比別人多。
───────────────────────────────────────
定義規則（Defining the Rules）
你替問題下定義的那番努力，大部份會集中在對介面的描述上。在某些應用中，你也 需要去為應用上的規則（application rules) 下定義。 所有的程式都牽涉到規則。通常，這些規則都很簡單，根本不在乎你如何去詮釋它們 ： 如果有人按下按扭，就讓鈴聲響起。 但在某一些應用中，由於所牽涉的規則是那麼的複雜，就不是一兩句話所能說得清楚 的。有一些常用的正統技巧可以用來幫助你去理解規則，並使它們形諸文字。 這裡有一個例子。我們的需求是要有一個系統，用來計算長途電話的收費。下面是客 戶向我們解釋的費率結構。（這是我編造的；我並不知道電信局到底如何計算他們的費率 ，我只知道他們經常超收。） 收費是依距離（以百英里為單位）以分鐘為計算單位，再加上一個固定費率。固定費 率訂定如下：平日上午8時至下午5時的直接撥號，第一分鐘收費 .30元，後續每分鐘收 費 .20元；每分鐘每百英里之收費為 .12元。平日下午5時至夜間11時直接撥號，第一分 鐘收費 .22元，後續每分鐘收費 .15元；每分鐘每百英里之收費為 .10元。平日夜間11時 以後、週六、週日、或假日的任何時間直接撥號，第一分鐘收費 .12元，後續每分鐘 .09 元；每分鐘每百英里收費 .06元。若經接線生協助，則固定費率不論任何時段，都增收 0.90元。 這番描述是以口語寫成，長篇大論，或許還掩蓋了一些錯誤。 要想把這種系統改建為一個概念性模型，我們就必須以不曖昧又實用的方式去描寫 費率架構。要想清除這種纏結不清，第一步就是要剔除那些不相干的資訊，也就是說， 要遵守"有限制的重複"（limited redundance）的規則。我們只要將這段陳述一分為二 ，就可使它大為改進。首先，這裡有"時段"的規則：
平日上午8時至下午5時通話，按"全額"收費。 平日下午5時至夜間11時通話，按"減額"收費。 平日夜間11時至凌晨8時、週六、週日、或假日的任何時間，均按"低額"收費。
再來就是費率架構本身，它們應該是循著"第一分鐘費率"、"後續分鐘費率"、"距離 費率" 以及"接線費率"來加以敘述。
─────────────────────────────────────
提示 要分離（Factor ）出不同種類的水果。（不要把橘子混在蘋果中）
─────────────────────────────────────
這種像散文似的陳述仍然讀來不易。系統分析師使用一些手段來簡化這些陳述：結構 化英語（structure English），判斷樹（decision
tree），判斷表（decision table ）等等。讓我們一一地分析這些技巧，並且評估它們在符式環境下各自的能耐。
結構化英語（Structured English）
結構化英語就是一種結構化的虛擬程式碼，藉著它們，費率可以陳述如下：
IF full rate
IF direct-dial
IF first-minute
.30 + .12/100miles
ELSE ( add'l- minute)
.20 + .12/100mi les
ENDIF
ELSE ( operator)
IF first-minute
1.20 + .12/100miles
ELSE ( add'l- minute)
.20 + .12/100miles
ENDIF
ENDIF
ELSE ( not-full-rate)
IF lower-rate
IF direct-dial
IF first-minute
.22 + .10/100miles
ELSE ( add'l- minute)
.15 + .10/100miles
ENDIF
ELSE ( operator)
IF first-minute
1.12 + .10/100miles
ELSE ( add'l- minute)
ENDIF
ENDIF
ELSE ( lowest-rate)
IF direct-dial
IF first-minute
.12 + .06/100miles
ELSE ( add'l- minute)
.09 + .06/100miles
ENDIF
ELSE ( operator)
IF first-minute
1.02 + .06/100miles
ELSE ( add'l- minute)
.09 + .06/100miles
ENDIF
ENDIF
ENDIF
這是顯而易見的糟糕。難讀，難維護，也難寫。這些都還可不提，而它在實現階段 中卻一無用處。我根本不想再談它。
判斷樹（The Decision Tree ）
圖2-4將電話收費規則以樹狀判斷的方式表達出來。判斷樹是讓人"沿線下尋"， 以找出某種條件下的結果的最好方法。基於此理，它也就是向客戶做說明時最好用的 表達方式。 但不幸的是，判斷樹卻難以"向上回溯"，以找出結果和產生此一結果之條件間的關 係。這種困難有礙於我們找出問題的簡化之路。其實，第一分鐘以後的收費是與有無接線 生協助無關的，這棵樹卻使此一事實糢糊化。你很難經由此一樹狀結構看出這個事實。
圖2-4 判斷樹之一例
┌第一分鐘 .30 + .12/100哩
┌─直接撥號─┤
│ └後續每分鐘 .20 + .12/100哩
┌─全額─┤
│ │ ┌第一分鐘 1.20 + .12/100哩
│ └─代接線──┤
│ └後續每分鐘 .20 + .12/100哩
│
│ ┌第一分鐘 .22 + .10/100哩
│ ┌─直接撥號─┤
長途電話│ │ └後續每分鐘 .15 + .10/100哩
┼─減額─┤
收費規則│ │ ┌第一分鐘 1.12 + .10/100哩
│ └─代接線──┤
│ └後續每分鐘 .15 + .10/100哩
│
│ ┌第一分鐘 .12 + .06/100哩
│ ┌─直接撥號─┤
│ │ └後續每分鐘 .09 + .06/100哩
└─低額─┤
│ ┌第一分鐘 1.02 + .06/100哩
└─代接線──┤
└後續每分鐘 .09 + .06/100哩
判斷表（The Decision Table）
下面要討論到的判斷表，是一種對程式設計師最有用的、複雜規則的圖表式表達方法，它也可能同樣地適用於客戶。圖2-5所示係將費率結構規則以判斷表的方式表達出來。
圖2-5中有三個次元（dimension ）：費率折扣，是否經由接線生，第一分鐘／後續分鐘費率。
在畫出超過兩個次元的問題時，情況會有點複雜。如我們所見，這個多出來的次元可以被描繪為外次元（outer dimension）裡面的副次元（subdimension）。每一個副次元 的條件都會出現在每個外次元的條件中。我們也將看到，在軟體中，數目再多的次元也能很容易地被處理掉。
圖2-5 判斷表
┌─────────┬─────────┬─────────┐ （外次元）
│ 全 額 │ 減 額 │ 低 額 │--- Z 次元
├────┬────┼────┬────┼────┬────┤
│ 第 一 │ 後 續 │ 第 一 │ 後 續 │ 第 一 │ 後 續 │--- X 次元
│ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │ （副次元）
├────┼────┼────┼────┼────┼────┤
直│ .30 + │ .20 + │ .22 + │ .15 + │ .12 + │ .09 + │
撥│.12/100m│.12/100m│.10/100m│.10/100m│.06/100m│.06/100m│
├────┼────┼────┼────┼────┼────┤
代│ 1.20 + │ .20 + │ 1.12 + │ .15 + │ 1.02 + │ .09 + │
接│.12/100m│.12/100m│.10/100m│.10/100m│.06/100m│.06/100m│
| └────┴────┴────┴────┴────┴────┘
|
Y 次元
在我們說明過的那些技巧中，都需要你分析出哪個條件適用於哪個次元。在這種分解（factoring）的行動中，有兩個規則要遵循：
第一，各個次元的所有元素（elements）必須是互為排斥的。你不能將"第一分鐘"和"直接撥號"放在同一個次元裡，因為它們並不是互斥的。
第二，在各個次元之內，所有的可能性（possibilities ）都必須算計到。譬如若另有一種費率，適用在清晨兩點到兩點零五分，Z次元的元素就要增加，這張表也只好再擴大。
這些判斷表還有另外的優點。它們不但讓客戶讀起來容易，對實現者也好處多多：
~FF;有轉化為程式碼之能力。這對符式特別真實，那是因為判斷表實現的形式已近圖形。
~FF;有向上作邏輯追溯之能力。去發現一個條件，並察看它是由哪些因素所產生的。
~FF;有清晰而生動之表達。對實現者及分析者而言，判斷表是一件更好的理解工具。
與樹狀判斷不同的是，判斷表採用更生動、更有意味的方式，將那些"結果"聚合 在一起。能夠同時看到各種概念展現於紙上，有助於對問題的理解。尤其那些極度複 雜、難以用順序思考的方式所能察覺的問題為然。 舉例來說，圖2-5清晰地指出，後續每分鐘的收費並不會因為是否由接線生代接 而有所不同。帶著這層新的認識，我們可以畫出一份更為簡化的表格，正如圖2-6所示。
圖2-6 簡化後之判斷表
┌─────────┬─────────┬─────────┐
│ 全 額 │ 減 額 │ 低 額 │
├────┬────┼────┬────┼────┬────┤
│ 第 一 │ 後 續 │ 第 一 │ 後 續 │ 第 一 │ 後 續 │
│ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │
├────┼────┼────┼────┼────┼────┤
直│ .30 + │ │ .22 + │ │ .12 + │ │
撥│.12/100m│ │.10/100m│ │.06/100m│ │
├────┤ .20 + ├────┤ .15 + ├────┤ .09 + │
代│ 1.20 + │.12/100m│ 1.12 + │.10/100m│ 1.02 + │.06/100m│
接│.12/100m│ │.10/100m│ │.06/100m│ │
└────┴────┴────┴────┴────┴────┘
一個分析者很容易沉迷在他自己的分析工具中，而把問題給忘了。就如一本結構化分析的書籍所建議的，分析者必須將問題中所有可能的事物徹底的掀出來，直到第 N 級的程度為止（N → ∞）。但是，這種作法不過是增加可供運用的細節而已。身為問題的解決者也必須試著將問題簡化。
───────────────────────────────
提示 你並不真正地了解一個問題，直到你能夠簡化它。
───────────────────────────────
如果分析工作的目標不僅僅在於理解，也要求簡化，那 ... 也許我們還有更多的事 要做。 那經過改良的判斷表（圖2-6）指出，里程費率只和費率是全額、減額或者低額有關 。換句話說，它是隨著表中的這個次元而變。何不將這張表一分為二，拆開來看看會如何 ？這就變成了圖2-7。
圖2-7 分段了的判斷表
┌─────────┬─────────┬─────────┐
│ 全 額 │ 減 額 │ 低 額 │
├────┬────┼────┬────┼────┬────┤
│ 第 一 │ 後 續 │ 第 一 │ 後 續 │ 第 一 │ 後 續 │
│ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │ 分 鐘 │ 每分鐘 │
├────┼────┼────┼────┼────┼────┤
直│ │ │ │ │ │ │
連撥│ .30 │ │ .22 │ │ .12 │ │
線 ├────┤ .20 ├────┤ .15 ├────┤ .09 │
費代│ │ │ │ │ │ │
接│ 1.20 │ │ 1.12 │ │ 1.02 │ │
└────┴────┼────┴────┼────┴────┤
另加 │ │ │
┌─────────┼─────────┼─────────┤
里收│ │ │ │
程費│ .12 / 100m │ .10 / 100m │ .06 / 100m │
└─────────┴─────────┴─────────┘
現在，我們只要藉助於表格的查閱和一番計算，就能得到答案。每分鐘收費的公式可以用一個虛擬的符式定義（pseudoFORTH definition）來解釋：
: 每分鐘費用 ( -- 每分鐘費用) 連線費用 里程費用 + ;
其中『+』號僅在定義中出現一次，不像表中出現九次。
依這種計費原則再往前一步，我們發現（或者你還記得在原始的問題陳述中曾提到），經過接線生僅僅會在收費總額上增加 .90元。根據此點，接線費就不是那三個次元中任一次元的函數。更恰當地說，它應被表示為一種邏輯上的計算；也就是說，一個結合了邏輯與數學的函數：
: ？接線幫助 ( 直接撥號費用 -- 總費用 )
接線生？ 如果 .90 + 然後 ;
（但請記住，此項收費僅作用於第一分鐘。）
如此一來，我們得到了一份更簡化的表格，如圖2-8，也在計算的詮釋上增加了可靠性。我們總算有了一點進展。
圖2-8 沒有接線生因素在內的判斷表
┌──────┬──────┬──────┐
│ 全 額 │ 減 額 │ 低 額 │
├──────┼──────┼──────┤
┌第一分鐘 │ .30 │ .22 │ .12 │
連線費┤ ├──────┼──────┼──────┤
└後續每分鐘│ .20 │ .15 │ .09 │
└──────┼──────┼──────┤
另加 │ │ │
┌──────┼──────┼──────┤
里程費 │ .12/100m │ .10/100m │ .06/100m │
└──────┴──────┴──────┘
且讓我們再回到『每分鐘費用』的定義上：
: 每分鐘費用 ( -- 每分鐘費用) 連線費用 里程費用 + ;
我們要更深入探討連線費與里程費的有關規則。
連線費的計算要看它是第一分鐘或後續時間。由於有兩種收費，或許最簡單的辦法就是將『每分鐘費用』改寫為兩個不同的字。
我們不妨假設已建構了一個元件，它會從表中取得恰當的費率（rate）。其中『第1 分鐘費率』就會得到第一分鐘的費率，『後續分鐘費率』會得到後續分鐘的費率。這兩個 字都會依著時段而自行決定該用全額、減額或低額的費率。
: 第1分鐘費率 ( -- 費率) .. .. .. ;
: 後續分鐘費率 ( -- 費率) .. .. .. ;
現在我們就可以定義一對字，去代替原來的『每分鐘費用』：
: 第一分鐘費用 ( -- 費用) 第1分鐘費率 ？接線幫助 里程費用 + ;
: 後續每分鐘費用 ( -- 費用) 後續分鐘費率 里程費用 + ;
里程收費的規則又如何？ 很簡單。它是費率（每百哩）乘上哩數（以百哩為單位） 。讓我們假定『里程費用』這個定義會從表中取得里程費率並計算：
: 里程費用 ( -- 費用) 百公里數 里程費率 * ;
最後，如果我們知道通話的總分鐘數，
: 分鐘數 ( -- n) .. .. .. ; ( 得到分鐘數 )
就可計算出這次直接撥號電話的用費：
: 全部費用 ( -- 總費用)
第一分鐘費用
分鐘數 1- 後續每分鐘費用 *
+ ;
如今，藉著簡單的表格與邏輯的計算相結合，我們已經詮釋了此一特定問題的規則。 （對此例有以下幾點最後的說明：我們前面所寫的，已經相當接近可執行的符式應
用程式，但它仍然是虛擬程式碼。我們避開了堆疊的運作，而假設「若語意有所指，則 某個值就會自動出現在堆疊以供使用」。
定義資料結構（Defining the Data Structure）
在定義了介面之後，以及（有時是）在定義了規則之後，偶爾你也會需要為某類資料 結構下定義。我們指的並非是資料結構的實現，而僅僅是它們的概念性模型的描述。
如果你正在為圖書館從事圖書索引自動化，在你的分析中有非常大的一部份會和 邏輯上的資料結構相關聯。你必須決定需要儲存一本書的哪些資訊，如書名、作者、標題
等。這些"屬性"將組成一個名為"BOOKS"的"實體"（一組相關連的記錄）。然後你也要
決定，為了使圖書館的使用者能有效率的找到書，還需要哪些資料結構。你或許需要另外
一個實體，以便容納按英文字母排列的作家名錄，以及各作家作品的"屬性指標"等等。
某些束縛事項也會影響到資料結構的概念性模型。在有關索引的例子中，你不但要知 道使用者所需要的資訊是什麼，還要知道他們願意等多久去得到它。
舉例來說，使用者可以向圖書館索取按出版年份排列的標題列表 --譬如他們要找
1900到1910年間女人內衣的一切資料。如果要找的是緊身束腰帶上的鈕扣有關資料，你
就必須以製造年份和品名做為索引。運氣好的話，他們會等上一天，讓你的電腦找遍 全圖書館。
追求簡單性（Achieving Simplicity）
─────────────────────────────────────
提示 保持簡單
─────────────────────────────────────
當你踏出那極重要的第一步去了解你的問題時，切記一句老話：
如果一個問題得到兩個答案，正確的是比較簡單的那一個。
這在軟體設計中特別真實。比較簡單的解決方案比較難被發現。但若一旦發現，它是
• 容易理解 • 容易實現 • 容易驗證及除錯 • 容易維護 • 比較嬌小 • 比較有效率 • 比較有味道
─────────────────────────────────────
Moore是最為大力鼓吹簡單性的人：
你對問題的大小應該有所感覺。該寫多少程式碼才能讓這件事動起來？一張紙？三張 ？我認為這就是一種很有用的設計工具。你需要徹底地去感覺一下，弄清楚到底是雞毛蒜 皮還是天大問題，以及你該付出多少精力和時間。
當一個案子完成後，你回頭檢討說，「我那個解決方案合理嗎？」如果你的解決方案 填滿了6幕，你可能用了大斧頭去砍小蒼蠅。你心中的影像與問題的份量不成比例。
我曾看過一份核子物理程式，裡面有幾十萬行的FORTRAN碼。不論程式碼寫的是什麼 ，說什麼它也不該有幾十萬行。或許那幾位作家將問題過份地一般化(overgeneralized）
了。他們解決了用一個小程式就能完成的大問題。他們違犯了「答案要和問題門當戶對」 的戒律。
───────────────────────────────────────
─────────────────────────────────────
提示
一般性（generality）通常會牽扯到複雜性（complexity）。不要將你的解決方案做
超出需要的一般化（generalize）；而是，要讓它們具有可變性。
─────────────────────────────────────
───────────────────────────────────────
Moore繼續說：
對一個問題，你寫出程式去解決它。做完之後，或許發現其中有什麼不滿意之處，你 大可回頭來過，又得出一個更簡化的方案。
有一門課叫做裝置最佳化 --如何去減少線路中的閘數-- 在其中，你要善加利用能被 忽略不計（don't care）的情況的好處。或許是因為它根本不會發生，或許是你真的 不在乎。但規格多半是那些對程式設計一無所知的人寫的，那位老兄可能費了好大的 精神，才將案中要點一個不漏地寫了出來，就只差沒向您這位程式設計師指出哪些情 況才是真正的重點所在。如果你能回去和他爭論一番，以找出能夠被"忽略"之處， 你就能找出比較簡單的解決方案。
以一個工程上的應用程式為例，譬如一個75噸級的金屬粉末擠型機，工廠想用電腦 去控制那些活門，以代替原來的液壓控制。你從工程師手裡會得到什麼規格？大多 數的情況是感應器會被按放在從電機的觀點看來方便的位置。但現在它們是可以被安 置在別的地方，可是工程師可能忽略了這點。如果你要求解釋，你就可能會更接近 真實的情況，也能更進一步地建構出他們所需要的模型。
另一個例子是伺服裝置上的PID（比例式積分微分）演算法。你有一個做積分的動作 ，另一個微分的動作，第三個使它平滑的動作。你以30％積分，10％微分，或是任 何其它的比例，讓它們揉合在一起。但這不過是種數位濾波的功能而已。在從前類比 式的時代裏，你能夠很方便的將濾波器中的某些功能分出來，並且說：「這一個是積 分器，那一個是微分器。我用一個電容器來做這個，用一個電感器做那個。」
再一次，這位規格製作者又要將他那類比式的解決方案塑造成型。那曾經是電機式的
解決方案的模型，和現在的情況已經是隔著好幾代了。事實上，你能用數位濾波器中 的兩三個係數完全取代它們，而得到更清晰，更簡單，更有效率的解決方案。
───────────────────────────────────────
─────────────────────────────────────
提示 你要在客戶動手解決問題之前，就回到問題原始的狀況，去發掘出可以"忽略不計"的 情況。
─────────────────────────────────────
───────────────────────────────────────
Moore繼續說：
有時候，一時之間還看不出簡化的可能性。有個問題是要伸縮（zooming）一個CAD 系統的數位化圖形顯示。你在螢幕上有張圖，想把它的一小部份放大以便仔細察看。
我習慣於移動游標到我感興趣的那個部位，按著一個按扭，它就開始放大，直到那 個部份放大到我所需要的為止。這就是我常用的辦法，直到有一天，我發現那是愚 蠢的。我根本不需要那麼細緻的放大解析度。
我不再以像素（pixel）為單位去移動游標，而是讓它跳，譬如十個像素一跳。也不 再連續地放大，而是讓它跳著放大。你不能選擇放大倍數，它每次都固定四倍。 那些中間的倍數沒什麼意思。你可以依你的需要，做多少次都行。
將事情做某種程度的量化，你就能更為愜意地工作，更會得到回應，也更為簡單。
───────────────────────────────────────
─────────────────────────────────────
提示 要簡化，就將它量化。
─────────────────────────────────────
───────────────────────────────────────
Moore的結論：
向客戶說「你並不真正地是指這個意思吧」或「如果我把這一頁拿走，換上現在這種 解釋，你不會在意吧？」是有些傲慢。他們會被惱火。他們要你做他們交代你做的 事。
Lafarr Stuart在將符式重新設計時就是這種態度[3]。他不喜歡輸入緩衝器，因 此他在實現符式時就不用它，果然發現他並不真正地需要一個輸入緩衝器。
如果你能改良一個問題，那真正是值得你進入的一種情況。重新去設計這個世界比做 出它來要好玩多了。
───────────────────────────────────────
幹練的程式設計師學到的是機敏，以及在不致於威脅到對方的情形下表達出自己所要 走的途徑：「如果用這個去代替那個，結果會如何？」等等。 簡化問題另有一途是：
─────────────────────────────────────
提示 要簡化，就要讓客戶沒有麻煩。
─────────────────────────────────────
假設你正在設計一個文字處理器的一部份，它會在螢光幕上顯示已經被儲存著的文 件目錄，每行一個。你計劃讓使用者將游標移到任一個檔案上，然後按一個單一字母的 命令，表示要選擇的動作：P表示列印，E表示編輯等等。 讓使用者在螢光幕上隨意移動游標到任意的位置上，初看似乎無關緊要。但這表示， 凡是已經有文字或圖形的部位，都應該要受到保護，免遭覆寫。這隱含著一種"保護區" 的概念，因而需要特殊的處理方法。比較簡單的做法是限制游標在一個特定區域內活動， 也許是用反白（reverse video）的效果，讓使用者看出他所被容許移動的範圍大小。 另外一個例子是，某一個應用程式要求使用者鍵入一個數值的時候。你所常見的應 用程式都不會在你輸入的當時檢查錯誤，直到你按下了Enter鍵，系統才反應一個"無效 數字"（invalid number）的訊息。簡單的辦法 --或許是更容易的作法-- 是在你按鍵的 剎那立刻檢查，不要讓那"非數字"的東西進入。
─────────────────────────────────────
提示 要簡化，就要充分利用那些隨手可得的東西。
─────────────────────────────────────
紐約Long Island的符式程式設計師Michael LaManna建議：
我常藉助於我所能找到的最強大的處理器去設計應用程式。如果有兩個系統供我選擇 ，一台是以68000 CPU為核心，另一台是6809 CPU的，我一定選用68000那一台。 這個處理器的功能是如此強大，許多細小的事都可以由它代為處理，免掉我一一去解 決的麻煩。
到後來，如果我需要重寫應用程式中的某些部份以配合改用較低功能的處理器，也 無所謂了。至少我沒有浪費時間。
───────────────────────────────────────
在此要提醒你：如果你利用一個現成的元件來簡化你的原型，不要讓它影響你的設 計。你並不希望你的設計仰賴於這個元件的內部。
預算及排時程（Budgeting and Scheduling）
在分析階段中的另一件大事是要概估經費。同樣的，這個過程也不是想像中那麼容易 。如果你要在問題解決之後才能了解問題，你又如何能在開頭就知道你要多少時間去解決 它？ 小心地計劃是很重要的，因為事事物物所花費之時間總會超出你所預期的。對於這 一點，我有一套根據或然率而來的理論：
─────────────────────────────────────
提示 在應用程式上增加"兩小時"的工作，其平均時間概略是12小時。
─────────────────────────────────────
我們不妨想像下面這一段情節：你正在撰寫一件大型的應用程式，心中突然一閃，想 要添加某一項很簡單的小玩意進去。你心中一算，大概需要兩小時，於是沒再進一步計劃 ，就開始著手。記住： 那僅僅是兩小時的寫碼時間而已。那份設計時間你沒去算它，因 為你是在工作於應用程式碼中的某一剎那才突然認識到這層需要 --和這個設計。所以， 你估計需要兩小時。 但請考慮下列可能：
1. 你的實現裏有個錯誤，過了兩小時還沒法工作。因此，你花了另外兩小時去重 新寫碼。（小計4） 2. "或者"，在實現之前你認識到，你原始的設計並不管用，你又花兩小時去重新設 計，"這"兩小時要算。再加上兩小時寫碼。（小計4） 3. "或者"，在你認識到這個設計不管用之前已經實現它了。因此你重新設計（又加 兩小時）以及再實現（又加兩小時）。（小計6） 4. "或者"，你已經實現了第一個設計，寫碼，發現錯誤，重新寫碼，發現設計有 瑕疵，重新設計，重新寫碼，在新碼中又發現一個錯誤，又再重新寫碼。 （小計10）
你看出事情像滾雪球嗎？
5. 現在你為這套新玩意做出文件記錄。再滾上兩小時。（小計12） 6. 在你用掉2到12小時為你的新玩意安裝及除錯之餘，突然間發現其中的Y元素爆 掉了。更要命的是，你根本沒概念，不知道其中緣故。花了兩小時去判讀記憶 體的內容，推敲道理何在。終於找到，你又用掉12小時去重新設計Y元素。 （小計26）然後你要將Y元素有關部份再做文件記錄。（小計27）
這樣已經超過3人日（man-days）。如果這些糗事一股腦兒找上你，那準會把你逼 到瘋人院裏去。當然，事情不會那麼糟，但霉運總是跟那些你認為最簡單不過的事 唱對台戲。 你如何改善你對時間需求的判斷？討論這個題目的好書不少，譬如Frederick P. Brooks, Jr所著〈虛構的人-月〉（The Mythical Man-Month）即頗值一讀[4]。我對 這方面的學識無緣置啄，只宜從旁觀察而已。
1. 不要作通盤的猜測，儘量將問題拆開為各個最小件，然後預估各件所需時間。 這種分別預估然後相加之和，一定比全盤概估所得為高。 2. 拆件時（itemizing），要將你熟知之各件和你沒把握的各件截然分開。對於 第二類，不妨給客戶一個金額範圍。 3. 下面是關係到心理學的小訣竅：永遠要讓你的客戶有所選擇。客戶"喜歡"選擇 題。如果你說：「這要花掉閣下六千美金，」客戶很可能會說：「老實說，我只 想花四千塊。」如此一來，你只有接受之一途，否則生意甭談了，該你走路。
其實你原來可以說：「閣下有個選擇：如果用四千塊，我可以讓它走著穿過火 圈；要是閣下有六千塊，我可以讓它跳過那個火圈；如果閣下肯花八千塊，我就 讓它跳著探戈穿過，舞著旗子，灑著紙花，嘴裡還唱著：「威士忌桶滾出來」。
多半的客戶都選擇跳過那個火圈。
─────────────────────────────────────
提示 每件事所需花費的時間都比你想像的要多，當然這也包括思考在內。
─────────────────────────────────────
概念性模型的回顧
在我們反覆分析的轉輪中，最後的盒子上有個標籤是「將模型展示給客戶看」。手握 著本章中說明過的那些工具，這件工作並不難。
在我們將需求規格形之於文字時，請記住，規格就像雪人。目前可能是凝固的，但他
們會移動，會滑溜，天氣熱起來，也會化為烏有。不論你選擇資料流程圖也好，或直接用 符式虛擬碼也好，都要時時記著將"有限的重複"（limited
redundancy）的概念實踐， 早作準備以迎接那融雪日子的來臨。 將已形之於文字的概念性模型展示給客戶看。當客戶終於滿意時，你就已經準備好
向前跨出另一大步：設計。
參考資料：
~T60BY1; 1. Kim Harris, "The FORTH Philosophy", Dr. Dobby's Journal, Vol.6 Iss.9 No. 59 (Sept.81), pp.6-11 2. Victor Weinberg, Structured Analysis, Englewood Cliffs, N.J.:Prentice Hall, Inc. 1980. 3. LaFarr Stuart, "LaFORTH," 1980 FORMAL Proceedings, p.78 4. Frederick P. Brooks, Jr. The Mythical Man-Month, Reading, Massachusetts, Addison-Wesley, 1975.