面向对象设计的敏捷化方法

面向对象设计的敏捷化方法

原文标题：如果你做了优秀的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这样的对象工具修改的效率显然更高些，等等。对于工具引导你的设计工作，要做到这一点，工具必然会非常复杂而死板，那么还不如不引导来得灵活。

（全文完）