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 ）这样的技术鼓励用户在现场快速得到场景， 揭示可能的未来变更。最后，检查这些可能的变更，检查需要为之改动多少元素。对于两个都“和业务相符”的模型，哪个模型受场景影响的点少一些，哪个模型就要好一些。其它很多地方也可以找到压力测试的参数。例如相关产品的结构，变更时是不是可以只改一点就可以了？在评价模型时，这些参数都应该用上。 场景还可以用在很多地方，例如：同用户一起检查需求，为系统提供功能测试的用例。以上所说，就是在建模活动中采用场景的三个理由。