面向對象設計的敏捷化方法

面向對象設計的敏捷化方法

原文標題：如果你做了優秀的OO設計，一定要讓它保持簡單

原文出處：
http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-ootools.html
http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-ootools-p2.html
　

以前我的一個學生曾經這么說：“我是不可能做面向對象設計的，因為我沒有錢�！蔽液荏@訝，就問他為什么會這樣想，原來，他認為要做OO設計的話，必須先有Rational Rose，而這個軟件很昂貴，當時每套要2500美元。在他的思想里，如果沒有Rational Rose，設計是不可能完成的。遺憾的是，類似的荒唐想法已經廣泛傳播開了。已經有很多人認為，OO是一個需要高技術工具支撐的高技術方法，而與此同時，花了很高代價買來的工具實際上很可能被高高擱起，至少在很大程度上沒有得到充分利用。

基于以上問題，在本文中我將對不同的OO設計工具進行考察，看一看這些工具是如何工作的，也看一看為什么我會認為它們沒有用。然后，我還將介紹我的工作方式，并試圖說明其有效性。至少，對我來說是很有效的。假如你能提出不同意見，也非常歡迎。

工具不會引導你工作
每一種成功的OO設計，大體上都遵循著這樣的過程：

• 學習問題域知識（例如會計、課程安排等）

• 進行近距離的咨詢，和實際用戶交流，編寫待解決問題描述，盡可能準確地描述用戶的問題，這和任何領域級的解決方案 是一樣的。該文檔不涉及計算機程序方面的內容。

• 進行一次正式的use-case分析，由此我確定用于解決客戶問題的工作任務，同樣的也要和一個實際存在的最終用戶近距離地 合作。典型的情況是，我為每一個比較難表述的use case創建一個UML活動圖（UML就是一種將軟件圖例化的符號表述語言）。

• 建立動態模型，把系統中的對象，以及這些對象之間的信息傳遞描述出來，這樣，一個特定的use case就已經完成了。我采用UML的順序圖來實現。

• 與此同時，我在靜態模型圖上捕捉有用的信息。請注意：我并不先做靜態模型（類圖），以前有過很多次，我在開始做動態模型時就做好靜態模型，但最后會因為毫無用處而不得不 放棄。所以我不會再這樣浪費時間。

• 上述步驟一般會產生2-3組use case，然后我開始編程，并且根據需要修補模型。
• 此后，我繼續為另一個use case進行工作，并對設計和代碼進行重構，以適應新的use case的需要。

當今的所有設計工具都無法在以上過程中給你引導。在很大程度上可以說，這些工具所做的并不象它們的價格所暗示的那么好。Rational Rose就是一個典型，它甚至并不支持完整的UML全集。

正相工程（Round-trip engineering）的先天性缺陷
這些工具在代碼自動生成方面，其實是毫無意義的。幾乎所有的OO設計工具都遵循了正相工程的設想，當你開始在設計工具中用UML進行工作時，你創建了兩種核心的 模型：靜態模型和動態模型。靜態模型表示了設計中的類，類之間的關系，以及類的屬性和方法；動態模型則用一大堆圖描述了軟件運行時執行各種任務的系統對象。

當你完成了模型以后，你會點擊一個“魔術”按鈕，工具很快就生成了相關的代碼。但是，這些代碼并不是很好，究其原因有兩個方面。第一，在很多工具里，雖然創建了類定義框架，但其中的方法太過簡化，甚至是空的，而動態模型 則被忽略了；第二，沒有一個工具能完全支持UML。UML是一種優秀的語言，能鼓勵設計者進行即時創作，同時，大多數實際的設計內容是包含在文字說明里的，而設計工具將完全忽略這些說明。

結果，你開始在所生成的代碼基礎上進行堆砌工作，而這些代碼看起來已經和原始設計毫不相干了，其實你已經拋棄了原來的設計。很多年的教訓告訴我，沒有設計的編程將 大大延長整個開發過程的時間，并且埋下了更多的Bug。

現在再來看看反相工程。打開你的工具，點擊“魔術”按鈕，導入代碼，理論上講，它會重新構造設計，使之和代碼相吻合。這樣的反相工程還是一些存在問題。雖然工具能生成新的類圖，但是不會更新動態模型。由于動態模型才是設計的核心，所以你的設計會變得沒有意義，除非你返回并手工更新模型，但實際上很少有人這么做。

正相工程使得編程人員完全忽略設計而只是一味地編程，然后，又通過反相工程從代碼中生成設計圖。在這樣的做法下，編程人員不會再進行設計，他們所做的就只是堆砌代碼，然后生成一大堆圖形，但是，這并不是設計。

然而，設計實際上一個需要反復迭代的過程，隨著開發和編程的進行，設計還需要作出相應的調整。在調整時，你應該先從設計的調整開始，然后再將代碼對照設計來進行重構。為了做到這一點，你必須在工具里對整個軟件進行完整的定義。而當你點擊“魔術”按鈕時，所生成的只是完成功能的程序，而整個過程成了反相工程的一次性工具。

CASE工具
CASE (Computer-Aided Software Engineering) 工具以Rational Rose為典型，將正相工程作為產品的核心。但是，正相工程并不是對任何事情都很有效，許多開發人員只是把Rose作為昂貴的制圖工具。對于其它的類似工具，我個人認為至少有3種是值得考慮的，盡管我沒有使用過其中的任何一種：

• 免費的開源項目產品ArgoUML工具，用Java編寫，能夠很好地表達UML圖形。最近的版本已開始對你的設計過程進行引導。雖然只是沾了 點邊，但這是一個很好的開始。
  　
• Embarcadero的GDPro，以前由Advanced Software進行推廣，雖然仍有不足，但已經為針對同一個軟件進行團隊設計合作提供了很好的支持。例如，當自動鎖定的類和一個動態模型圖中的對象相關聯時，設計者將不能check out該動態模型圖。
  　
• TogetherSoft的Together ControlCenter沒有提供反相工程，這樣也就回避了反相工程的缺陷問題。代碼和設計可以同時顯示在屏幕上，當你修改其中的一個時，另一個會相應地自動修改。不過，Together ControlCenter并不能很好支持開發團隊 的協同。
  　
• 我還要簡短地提及Microsoft的Visio。Visio是一個制圖程序，能把UML圖很漂亮地表現出來。但是它的界面很拙劣地模仿了Rational Rose。Visio所附帶的大量UML圖元模板比其內置的UML支持功能要好的多。

在白板上工作的唯一困難是如何捕獲白板上留下的信息。白板打印工具確實存在，但非常昂貴，很笨拙，而且太小。它可以跟蹤筆在白板上的運行，捕獲筆的按 下和釋放，并傳輸到電腦里。其它的白板工具的工作原理和龐大的掌上記事本很相似。但是，這些工具還是有局限性，要知道，設計可能同時在幾個辦公室里進行，設計的思想可能會記錄 在餐巾紙上，或者別的什么小紙片上，等等。你大概不可能把一個300磅的白板處理工具搬到餐廳里去吧。

怎么做才有效？
那么，究竟怎么做才最為有效呢。如何把捕捉到的信息輸送到電腦，再通過圖片方式放到文檔里，而不需要把它們轉化為某種UML工具的圖形文件呢？

我推薦的解決之道如下：

1. 一個數碼相機
2. 一個有趣的軟件產品，Pixid公司的Whiteboard Photo

電子圖片的缺點是，經常不能和軟件文檔相互協調一致。為了彌補這一點，Whiteboard Photo對數碼照片進行處理，使之更為適用。 但是，有時候一圖勝千言。

下圖是一個典型的白板的照片。

圖1：典型的白板作圖

圖2：再看另一個圖例。

圖2：另一個白板圖的照片

下圖是whiteboard Photo對圖1的改進

圖3. Whiteboard Photo對圖1的轉換結果

下圖是whiteboard Photo工具對圖2的改進

圖4. Whiteboard Photo對圖2照片的處理結果

這是一個有趣的工具，用于將白板照片進行凈化處理，我只需要敲一下鍵盤Ctrl-L。軟件就能自動找到并去除白板邊緣，自動糾正拍照時的扭曲，以及因為拍攝角度 所帶來的斜度，并能去除閃光燈產生的反光。該工具還能識別出筆的線條，識別出手寫體并加以優化，于是，我可以在白板上勾畫，然后制作出具備文檔質量的圖形 ，而不再把時間花在CASE工具上了。

保持簡單
根據我的經驗，當你做OO設計時，技術含量越低的工具效率越是好用。它們更快，更容易使用，在需要合作的環境里也能方便地提供交流。你可以看到，如果將白板 、數碼相機，以及處理圖片的工具（例如Whiteboard Photo），組合起來，就能為設計帶來很實用的工作機制了。

資源

　
• 免費，開源的設計工具ArgoUML:http://argouml.tigris.org/
  　
• Embarcadero's GDPro:http://www.embarcadero.com
  　
• TogetherSoft: http://www.togethersoft.com
  　
• Microsoft Visio: http://www.microsoft.com/office/visio/default.htm
  　
• 本文所提到的Pixid Whiteboard Photo：http://www.pixid.com/home.html
  　
• Allen Holub的個人網站：http://www.holub.com/goodies/goodies.html

[譯后記]

本文的翻譯帶有翻譯交流性質，所以在這里贅述幾局。

本文采用意譯，并為中文閱讀習慣做了充分的調整，個人英文俗語和部分艱澀的短語已被省略，希望這無傷原文的優秀內涵。原文的目的之一是推薦一種為系統設計師制作的圖形處理工具Whiteboard Photo，本人在翻譯過程中，在語言引導方面做了修改，以更好地突出本文如標題所示的主要目的。

翻譯時我確實也產生過一種沖動，想發明一種新的白板工具，它本身不是普通的白板，只當按下按鈕時，才讀取板上的信息，即手工圖形和注解，然后自動生成圖形文件�；蛘�，多找些變通的辦法。

本文的觀點其實就是，越簡單的設計效率越高，復雜的工具只能使效率降低。用白板筆勾畫，自然比鼠標要好多了，我的思路非但不會被切斷，而且會隨著筆的勾畫而發展。

多年以前，我也曾經常應用白板工具，在項目布置會上，在方案討論會上，在模型設計時，等等。等做筆記的女孩交給我會議紀要時，我常發現，還不如把當時白板上畫的照搬下來好呢。后來才知道，在白板上討論，甚至建模，用數碼相機拍攝，導入電腦，再打印出來，貼在四周墻上，實際上這是典型的Agile/XP方法。----本文雖然簡短，但可謂是這種面向對象設計的敏捷方法的介紹，因此我特地修改了文章的標題，雖然大了些，但能達到“嘩眾取寵”的些許效果吧。

實際上白板工具也是有更多的不足的。例如，在大的項目里，你很難通過白板這樣的簡單工具來全程建模。編程時需要做的修改，同樣是要手工更新設計。這時，你無法對電子圖片進行方便的修改，而Rose這樣的對象工具修改的效率顯然更高些，等等。對于工具引導你的設計工作，要做到這一點，工具必然會非常復雜而死板，那么還不如不引導來得靈活。

（全文完）