Alistair Cockburn 著（1996 年2 月），袁峰 譯
介紹
首先我要解釋一下為什么會寫這封公開信。這似乎已經成了一種習慣，但這個步驟還是需要的。過去6 年中， 我曾經無數次地在飯店、酒吧、旅店大廳等各種地方以同一種方式度過愉快而漫長的夜晚：和同樣追求真理、光明和智慧的伙伴一起探討面向對象的真諦。現在，我已經可以回答很多當年我遇到的問題。這些同樣的問題也在困擾著我的一位新同事，在一家飯店里，我花了整整一個晚上和他討論這些問題。結果第二天，他的同事又來問這些問題，并建議把我們的談話內容記錄下來，這樣他可以拿去給他的同事看。考慮到還有很多和他的同事一樣詢問這些同樣問題的人，我決定寫下這篇文章。
主要的問題是：
z 為什么只要稍有一點不是嚴格或純面向對象的做法、說法，OO 專家就大驚小怪的？use case 并不是面向對象的，為什么還這么流行？而且，OO 建模似乎和數據建模非常相似？
z 數據建模（data model）得到的模型和對象模型的結構部分會不會很像？流程建模（process model）和對象模型的行為部分呢？
z 業務結構建模中為什么要用use case 和場景（scenario）?
OO 的新手們反復問這些問題，但實際上，只有在日常工作中堅持應用面向對象的思維進行工作，積累一定的經驗，才能得到滿意的答案。為什么只要稍有一點不是嚴格或純面向對象的做法、說法，OO 專家就大驚小怪的？use case 并不是面向對象的，為什么還這么流行？而且，OO 建模似乎和數據建模非常相似？
我想分三步來回答這個問題。
首先，我舉我和Bob（著名的OO 專家）一起工作的例子， 當我們討論OO 的時候，彼此都有一個共識，知道對方擁有面向對象工作的豐富經驗并且是這項技術的堅定支持者。而且，對諸如對象識別（object identity）、多態、數據和行為的封裝、實例職責、繼承等對象技術都是手到擒來。因此，當我說：“明天對程序表單進行數據建模吧”，Bob 不會產生我要會因為關系表而放棄對象這樣的誤解，他知道我指的是在對象模型中體現出來的結構化特性進行建模。他知道我會說些什么，因此我使用或誤用這些術語不會造成什么誤解。但作為一個對象技術的初學者，如果Bob 發現你把數據和行為完全分離開了， 并且沒有使用（ 或者說忽視了）對象識別或者多態等技術， 這時候， 如果你說“ 數據建模”，Bob 會像一堵墻一樣逼近你，直到你明白該怎樣改變。這樣工作幾個月，你會發現，你的模型（以及建模）中漸漸有了對象識別、多態、數據和行為的綁定，這時候再用“ 數據建模”這個詞就不是那么危險了， 但Bob 還可能會擔心你走回到老路上。換句話說， 他對你還不夠信任， 因此，你不得不很小心地使用這些術語。
就算一個對象模型可以分為“結構”和“行為”特性，我們也不會使用“對象建模”和“流程建模” 這種術語，以免引起混淆。事實上，為對象模型的“結構”特性建模可以看成是數據建模的特殊形式，只不過建模的對象不再是表，而是需要捕獲的信息的結構。我們將它稱為“ 概念數據模型”，而不是邏輯數據模型或物理數據模型。第二步，讓我們考慮兩個OO 使用者一起討論的情況。如果其中一個家伙說到“流程建模”這樣的詞，肯定會讓他的拍檔琢磨半天：這家伙是說用標準數據流圖作流程建模嗎？如果這樣的話，以后OO 實現的時候不是相當麻煩了嗎？他是不是指模型的行為特性？是不是說在一個對象內部對流程進行建模？（如果這樣的話，那會很有意思，因為很少有人這么做的。） 通過這個例子我們可以看到，這種談話中使用“ 流程建模” 這種意圖不明的詞實在是太危險了，很容易就將交流變得非常困難。
最后來說use case 和場景的問題，它們都是獲取需求的主要手段，和實現技術無關。其好處是可以為設計時的討論提供內容和范圍。它們不是“面向對象”的，這是事實，它們類似于功能分解，這也是事實，而且這一點嚇壞了很多人，但這些都無所謂。重要的是它們為設計提供了內容，在用來描述內部設計時，它們表現了系統的行為。Flow chart 、交互圖、Petri 網、數據流圖、use case 都可以用來描述系統的行為特性， 但各自用途不同，各有優劣。關鍵是要知道：對象不僅有數據，也有行為， 認識到這一點， 就可以大膽地去考慮怎樣可以更好地捕捉、描述對象內部和對象之間的行為。
數據建模（data model ）得到的模型和對象模型的結構部分會不會很像？流程建模（process model） 和對象模型的行為部分呢？根據我的經驗，數據建模人員可以分為兩種－一種是為存儲的數據建模，而另一種是為系統或組織中的信息建模。這兩者截然不同。前者討論和思考所用的概念通常都很具體，比如說數據表。他們的模型和OO 建模者的模型大相徑庭，而且他們并不愿意看到這些技術之間的相似性。在數據建模社區中，只有討論邏輯數據模型或物理數據模型才不會受到攻擊后者得到的是概念數據模型。根據我的經驗，他們得到的模型和那些有經驗的OO 建模者得到的模型非常相似。他們的工作更加類似于業務人員，而不是邏輯數據建模人員，這種說法可能會有助于理解概念數據模型和邏輯數據模型的區別。
似乎有一套學問可以幫助人們比OO 建模人員更快地得到結果。我多次發現這樣的事實：OO 建模人員花了三四次迭代才得到的模型，實際上和（概念）數據建模人員一個循環得到的模型是一樣的。這個發現使我對數據建模人員充滿了敬佩。事實上，在進行對象設計的時候，我有時就直接去把數據建模人員的產品拷貝過來看看， 從中來看我最后得到的模型大概會是什么樣的。
我曾經召開過數據建模人員和對象建模人員之間的會議。采取的方法是“ 一個聽眾的CRC 會議（CRC sessions for an audience）。四個經驗豐富的OO 設計師坐在長桌一端，業務專家沿著長桌坐下，他們負責回答問題并糾正對業務的誤解。接著是數據建模人員，長桌的另一頭是其它有關人員。總的來說，屋里大概是十幾個人，但談話主要是在四個OO 設計師之間進行。
討論大概一個小時之后，OO 設計師可以得到對象設計的一部分。這時候，咨詢數據建模人員，這個模型和他們已經得到的模型本質上是不是一樣的。他們說，“是的”，重復這個過程兩次以上，每次都詢問數據建模人員同樣的問題，除了使用的符號技術是不同的，例如：他們沒有用繼承，但在同樣的地方有同樣的占位符，在本質上，這個模型和他們的模型沒有什么不同的。接著，我們分成幾個小組，每個小組包括一個業務專家、一個數據建模專家和一個OO 專家，很快就剩下的設計達成一致，找出技術上一些小的不同之處，并且進行排序。一般情況都是這樣的：要么數據建模人員考慮得更加合理，要么OO 建模人員考慮得更加合理，小組要做的是在他們的設計之間進行協調。
從上面的這些經驗可以看到，使用CRC 進行OO 建模得到的模型和概念數據建模得到的結果非常相似。另外，根據經驗，基于邏輯（存儲的信息）的關系建模和OO 建模是不同的。大多數情況下，區別是由于技術的不同導致的，例如，在OO 模型中可以自由地使用繼承和多對多的關系。由于技術上的差異，兩種建模人員之間不能很好地交流，這是最大的困難。
數據建模部分的問題就說這么多吧。
對流程建模而言， 情況卻不一樣了。90 年代初， 涌現出各種方法、計劃、會議和項目，試圖將數據流圖的模型轉變為對象模型。曾經有幾個項目聲稱獲得了成功，但都是后續無音，業界一致的結論是： 這個轉變太困難了。大多數使用數據流圖的建模人員最終都拋棄了這項技術， 投入了對象設計的懷抱（Martin-Odell 和Ptech 小組是著名的例外）。對于流程建模，現階段我的回答是：其模型無法與OO 模型相比較。但這并不是最終的回答，OO 建模人員正在開始進行本質上的流程建模，下一步的發展將會怎樣，我也并不清楚，流程將變成過程那樣（過程編程復活？）， 或者變成數據流圖那樣，還是類似于封裝的對象？
業務結構建模中為什么要用use case 和場景（scenario）?
use case 和場景……
……為討論提供范圍和內容，
……預示內容，包括什么，不包括什么，討論多廣，多深入，什么時候停止，
……為設計的壓力測試提供參數。
我見過一些不使用“場景”的小組，他們建模的時候實際上就是在問題域內作隨機的探險。負責人根本不知道下一個該問什么問題？經常都是憑直覺。一般說來，他們也不知道現在捕獲的信息最后是否真正需要，就算知道也是憑直覺或者瞎蒙。
在一個寂靜的深夜，幾個真正專家級的OO 設計師向我說了心里話：根本就沒有一個有效的規則來指導漂亮的對象設計。其中一位說，“我們有時真的是在毫無目的地討論”， 另一位也相當贊同，“有時候我們就象沒頭的蒼蠅一樣到處亂撞，直到突然把一些好的對象給撞出來。”
使用場景也不能防止盲目的討論和到處撞墻，只是可以為討論提供內容和邊界。我曾經見過有的小組不用場景，長時間在很大的建模范圍內四處亂撞，失去控制。因此，使用場景和use case 的第一個理由就是為建模的努力提供一個范圍。
使用場景的第二個理由是決定需求獲取到什么程度算足夠。
假設現在讓你為一家貨運公司建模。你建模的內容是什么？卡車的購買價值……實際價值……轉售價值……車內顏色……快送單據的數目……旅途的數目和目的地？如果你想要把所有的內容都包括進來，那你將永遠無法結束。除此之外，還有其它的問題：從何處開始，何時結束，包括什么，不包括什么，需要多少細節？ 場景可以回答關于內容的問題，答案是：你需要足以回答場景中所有問題的信息。在結構化模型或完全的對象模型中，如果用一個方框來對應一個場景。然后在瀏覽場景的過程中將涉及到的元素（譯者注：這里的元素， 是比如在OO 的類或對象） 涂成紅色， 會發現最后所有的元素都按某種順序連接起來了（不會有遺漏的元素）。如果對所有的場景都執行這個操作，最后所有的元素都會被涂成紅色。在建模過程中，討論會經常離題，用這種方法可以保證針對當前的需要制定一個邊界，這樣不會跑題太遠。
最后，場景還提供了壓力測試的參數以保證質量。
怎樣比較兩個模型的優劣？ “和業務相符”，這是必要的，但肯定不夠，可能有很多模型都可以“和業務相符”，怎樣來度量這些模型的質量呢？
軟件變更的成本很高，另外，變更越靠后，變更的成本也就越高。（變更成本曲線）。軟件設計的一個目的就是將變更隔離開來，每次變更只需改變一個模塊。這并不是什么時候都能做到的，正如Kent Beck 所說，“如果你可以只改變一個類， 那軟件的質量將得到顯著的提高”。和軟件相比， 業務模型的成本函數并不是很清楚，但將變更影響的范圍降低到最低肯定是應該的。
為了測試變更曲線，需要參數，而場景可以提供這些參數。如果用戶想要“something-or-the-other”，怎么辦？模型中到底需要多少元素？像CRC（class-responsibility-collaborator ）這樣的技術鼓勵用戶在現場快速得到場景， 揭示可能的未來變更。最后，檢查這些可能的變更，檢查需要為之改動多少元素。對于兩個都“和業務相符”的模型，哪個模型受場景影響的點少一些，哪個模型就要好一些。其它很多地方也可以找到壓力測試的參數。例如相關產品的結構，變更時是不是可以只改一點就可以了？在評價模型時，這些參數都應該用上。
場景還可以用在很多地方，例如：同用戶一起檢查需求，為系統提供功能測試的用例。以上所說，就是在建模活動中采用場景的三個理由。
作者的網站：
http://alistair.cockburn.us/