OO 設計過程：驗證分析

OO 設計過程：驗證分析
原型與模型的差異以及二者的重要性

Allen Holub
首席技術官，NetReliance
2000 年 12 月
來自IBM DW站點


既然我們已經定義并細化了問題陳述，現在要為我們的教育軟件構建一個模型。

本文是 OO 設計過程系列中的第四篇文章。前三篇是： 

入門 
開始設計軟件 
細化問題定義 

這個月，我將通過創建一個模型來從問題陳述階段轉向解決方案階段，并將該模型部署到用戶社區（我 7 歲大的兒子）。

修改 
在紙上定義好問題之后，下一步是確保問題定義是正確的�？梢允褂脦追N方法來這樣做（模型、UI 原型以及其它方法），我將在本月和下個月分別講解。請記住，正如您閱讀這些文章所感覺的那樣，雜志上的文章一般都是連續的，但實際上，這些活動中的很多活動都并行發生。例如，我在創建 UI 的同時還在細化模型；我將使用通過用例分析發現的信息來改進 UI，并且，在進行 UI 方面工作的同時，還會找出用例分析中的缺陷。同樣，當開始進行模型方面的工作時，我還會不可避免地發現初始問題陳述中的缺陷，并回過頭來修正它們。設計過程不是一種有序的、循序漸進的過程，您不能在進行到下一步之前完成上一步的所有工作。而且，還要經常重新修改那些您認為已經完成了的工作，并用在目前正在進行的工作中發現的信息來更新它。

經常性的反復修改正是設計過程的一部分，并且必須這樣做。對于設計文檔來說，變成“過時的”實在是很容易，因為它不是象這樣來更新的。對于在一年之后才能看到代碼的程序維護人員來說，設計文檔是必需的。雖然我認為，只要仔細編寫代碼（仔細選擇變量和方法名，具有良好結構等等），代碼本身也可以提供足夠的文檔信息，但是我不同意 Kent Beck 和那些“極端編程”人員的看法：不應該費力去使設計文檔與實際代碼保持同步，因為繁忙的程序員沒時間這樣做。

既然設計過程如此不穩定，我喜歡盡可能多地將它記錄下來。Stravinsky 在創作 Rite of Spring 時將整篇樂譜放在公寓的墻上，以便可以從總體上觀看作品。對于軟件設計，這也是個好主意。

例如，我不喜歡使用 OO CASE 工具，因為它將設計文檔隱藏在計算機內部，我看不到它們，我更喜歡用大量的白板，并在上面留下足夠大的空間，以便隨時使用。50 碼長的白色簡易紙卷也是不錯的選擇。只有在設計過程變得相對穩定時，我才會考慮將設計移至 CASE 工具中進行，并且，我不會使用任何不允許輕易打印出整個設計的 CASE 工具，因為，那樣我就無法將設計樣圖粘回到墻上了。

模擬解決方案 
“修改”過程中的第一步是確保問題是值得解決的。我通常用模型來回答這個問題。

“原型”和“模型”之間有一個重要區別。以航空業為例，波音 777“原型”是一架功能齊全的飛機。除了在設計過程完成之后會有新機型取代它之外，它就是波音公司出售的飛機。實際上，原型是一個被部分構建的程序，而不是在測試之后即被丟棄的廢品。與波音 777 一樣，您使用原型程序作為設計思路的試驗臺。如果設計思路有效，則在原型中保留該思路。也就是說，原型是最終程序的部分構建版本（通常是最終程序的一部分）。必須仔細設計和組織原型；這是您設計的成品程序。這種類型的開發－逐步細化原型，直到生產出成品為止－通常稱為“遞增式細化”。

但在目前，我不需要原型。我需要的是模型。我想看看，為孩子設計的銀行的總體思路是否有意義；我還不想構建實際的應用。模型是用管道粘膠、口香糖、紙夾和油漆等制成的試驗品，用于測試那些目前還不想實現的概念。波音公司可能也模擬了 777 坐艙，以了解是否可以從駕駛員座椅觸及所有的開關。他們可能用膠合板和其它現有飛機的座椅進行試驗。相反，原型坐艙的大小與實際坐艙相同，有完整的電子線路，其中有真正的設備、座椅和開關�？赡軙�將它掛在計算機飛行模擬器、而不是一架飛機上，但是，如果愿意的話，也可以將它放在飛機中。

原型的另一個特點是，它為在設計期間出現的重要問題提供答案。例如，通�；卮稹笆欠裼凶銐虻膸�寬來做 X？”這樣的問題的唯一答案就是模擬做 "X" 那部分程序的原型（或者至少是與網絡相關的程序部分）。如果不創建實際代碼（也就是說，如果以人工方式模擬問題），實際上就回答不了這個問題。實際版本與模擬版本的行為可能不同。

因此，我在 Excel 中為“阿倫銀行”實現了一個模型。在模型中，銀行只是一個簡單的電子表格，每一行記錄一天的交易�？梢酝ㄟ^在電子表格的適當單元內輸入存款額來存款，并可以在另一個單元中看到當前余額和累計利息。對于實際的程序來說，這可能是一個糟糕的 UI，但是，這當然只是一個模型而已。

將模型提交給實際用戶 
然后，我使用這個模型在我 7 歲的兒子菲利普身上嘗試這個概念。試驗獲得了驚人的成功。首先，菲利普自己想出了復利的概念。


我說：“那么，在這個月末，你就可以取出最先存入的美元，還有銀行為保存你的錢而付給你的五分硬幣�！�

他說：“那么，下個月，我得到的錢要超過五分硬幣，因為我現在在銀行中有更多的錢，是嗎？” 

很明顯，他喜歡這種不工作就可以賺錢的主意。證據就是，在幾個月使用 Excel 模型的試驗期內，菲利普沒有取出一分錢。太棒了。

這個模型確實反映出有兩處需要改進。事實上，菲利普經常詢問他的帳戶里還有多少錢。模型過程的一個具體效果就是如下修改“問題陳述”，以反映新的需求：


重要的一點是：孩子們應該能看到每天的利息累計，每月發布一次利息信息是不夠的。因此，銀行每天都要計算復利，并且每天發布復利信息。存折要顯示每天的發布信息，即使那天沒有其它交易也要這樣做。這樣，即使沒有存款，孩子們也可以看到利息是如何累計的。存折中還突出顯示存款期間獲得的總利息。 

第二個問題是在模型使用了一段時間之后才出現的。菲利普最終取出一筆錢去買一張他看中的 Pokemon 卡，但是他還缺大概一美元�！熬拖胥y行一樣”，我答應借給他這些錢。也就是說，我將按他存款利息的兩倍來收取他的貸款利息。這種額外的損失足以使他放棄取款（因此，我教他如何省錢的主要目的確實達到了），但是，我確實認為，將來有貸款的能力將很方便。因此，需要再次向問題陳述中添加內容：


孩子應該可以從銀行借錢，但是這個過程也應該模擬實際的銀行。貸款利率應該足夠高（例如，是存款利率的兩倍），以表明借錢是昂貴的，并且銀行應該要求，每隔固定、相對短的時間（外面的銀行是幾個月一償還）就償還。孩子可以用存款來自動償還。還是那樣，因為練習的目的是要教孩子如何管錢，所以，銀行必須可以為孩子顯示貸款結算表，以使他們清楚地知道貸款要花費多少。另外，存折應該突出顯示自動扣款，以顯示減少的本金和所付的利息。如果未及時還款，父母將使銀行對孩子施以罰款。


銀行用“簡單”利息的方法計算貸款利息－在每個還款期間，用當前未還清的本金乘以當前利率，從而計算出應付的利息。還款之后所剩的任何錢都可以用來減少本金。孩子應該可以在任何時候，通過在貸款帳戶中進行額外付款（或比平時多付款）來減少本金。


計算還款的標準公式為： rate /= 1200; // Adjust rate to per-month
tmp = pow( 1.0 + rate, (double) number_of_periods );
return( (tmp * present_value * rate) / (tmp - 1.0) );


其中，rate 是年利率（即，如果年利率是 11.5%，rate 就是 11.5）。

無用功能 
我之所以沒有添加第二個功能是因為菲利普實際上沒有貸款，因此，我無法確定是否需要實現貸款功能。實現那些用不到的特性是沒有意義的。事實上，那是很多現有程序的一大問題：它們有大量可能需要的特性，但實際上，沒有人使用這些特性。這種“無用功能”除了在每一方面都使程序更昂貴之外，不做任何事：花更多錢去構建，花更多時間去構建，并且，因為公司必須收回構造成本，它還會向用戶收取更高的費用。

金玉良言是：


程序應該只實現那些最終用戶實際使用的功能，不要多也不要少。 

然而，總體設計應該足夠靈活，以便以后可以輕易添加新特性。

至于目前這個程序，我決定先不添加貸款功能，以便盡快將程序推向市場。然而，我將盡快提出一個以后可以輕易添加該功能的設計方案。

用戶、市場營銷和銷售 
關于模型要指出的最后一點是：Jacob Nielse 曾寫到（抱歉，我記不起其出處），為兩名用戶演示原型的效果是為一名用戶演示的效果的兩倍，但是為三名用戶演示的效果只是為一名用戶演示的效果的 2.5 倍。為三名以上的用戶演示是浪費時間。

使一名最終用戶實際成為設計小組的成員是必需的，這樣，不僅能幫助進行產品定義，還可以在設計和實現的整個過程中不斷提出反饋意見。有兩名用戶就更好了，但是，第二名用戶不必在現場，只需檢查所設計的原型和模型即可。事實上，如果第二名用戶不十分熟悉整個設計過程可能更好，這樣，他／她提出的意見才更新奇和更公正。

如果沒有真正的最終用戶，如果愿意，還可以使用市場營銷（不是銷售）部門中的人員（用戶代表）。區分市場營銷和銷售是很重要的。一個好的市場營銷部門的主要目的是調研。市場營銷是試圖想出現實世界中做實際工作的人們真正需要什么樣的程序的過程。他們用調查、面談等方法來實現這點�！吧虡I發展”和市場營銷的概念密不可分。實際上，正式的問題陳述是市場營銷檔案，但必須由市場營銷和技術小組協作指定，以確�？梢约皶r完成程序。傳統的特性與推向市場的時間之間的權衡是市場營銷的決定。

另一方面，銷售部門的工作是銷售現有產品。銷售部門絕對沒有規劃商業運作的權利，并且永遠不應該被允許直接與技術方聯系。銷售人員應該向市場營銷人員建議新特性，然后，市場營銷人員驗證該特性對于用戶社區是否確實有價值。如果這些特性確實有價值，市場營銷人員將隨后與技術方協作，以將該特性添加到設計中，并最終添加到程序中。順便提一句，不管添加特性有多困難，程序員都必須添加由市場營銷人員指定的特性。市場營銷人員需要提出產品占據市場所需的最小特性集。如果沒有那些特性集，產品就不會成功。不允許程序員僅僅因為添加一個特性不方便就怠工，并妨礙公司的成功。

當設計方向由銷售人員、而不是市場營銷人員決定時，就完全出錯了－很多人都經歷過這種錯誤。某個客戶打電話來請求一個新特性，銷售人員隨后將之變成“我的天哪，我們昨天就應該有這個特性”的請求。然后，一些不幸的程序員將會被強制停止有用的工作，并著手添加這個新的特性。三天以后，同樣的事情再度發生，然后，添加第一個特性的要求被取消，取而代之的是一些新的“現在就要做出來”的特性。最終結果是什么也完不成。如果奇跡般地生產出一個有功能的程序，這個程序可能不會做任何有用的事。僅僅因為一名客戶要求某一特性就添加該特性或修改設計是完全錯誤的；那樣做的時候，您正冒著將您的軟件公司變成只有一名客戶的客戶軟件作坊的風險。真正的問題是：這個特性會對更廣泛的社區有用嗎？這就是一個市場營銷問題。

這就是模型 
關于模型，已經講了很多。下個月，我們將從用例分析和 UI 設計開始。

參考資料 

Extreme Programming Explained: Embrace Change（閱讀：Addison Wesley，2000；ISBN 0-201-61641-6）中描述了 Kent Beck 的“極端編程”。 
要想看到模型與原型的真正區別，請查看有關如何建造波音 777 的 PBS 文檔：21st Century Jet: The Building of the 777。 
Usability Engineering（San Francisco：Morgan Kaufmann Publishers，1993；ISBN 0-12-518406-9）中描述了 Jacob Nielsen 有關原型可用性的思想。