转载于:www.smth.edu.cn
OO 设计过程：入门
如何设定优先级
Allen Holub
撰稿编辑，JavaWorld
2000 年 7 月
内容：
OO 不是...
定制过程
缺少工具
设计环境
设计和体系结构
结束语
参考资料
关于作者
欢迎阅读本在线课程的第一部分。在本专栏中，我打算让您实际操作，以亲身体验
面向对象 (OO) 的设计和开发过程。与其说本专栏是一个活动，不如说它是一个旅
程，因为需要几个月才能完成整个过程。我们将从需求搜集入手，从分析到设计，
然后完成设计的 Java 实现。到结束时，您将经历开发 OO 程序的全过程，真正地
从开始到结束。我将花很大的篇幅讨论基本理论，但主要重点仍将集中在如何应用
该理论的实际示例上。
下个月我们将正式开始，在此之前，我有一些忠告、意见和评论，这些意见将告诉
您我对设计主题的个人观点和看法。
OO 并非关于结构
首先，就其核心而言，面向对象与派生、类层次结构、UML、Java 技术等毫无关系。
这些是 OO 设计人员用来构成分析、设计和实现的工具，但它们并不是使程序面向对
象的主要部分。当然，随着过程的展开，我将使用面向对象的所有这些结构性部件，
但如果您将实现结构与面向对象等同起来，那么前几篇专栏文章可能特别难以理解。
面向对象的关键概念是建模，所以在动手之前，必须决定建立什么模型。
Adele Goldberg（在 Succeeding with Objects 中，请参阅参考资料）叙述了一位
犹太教教士在新年依始的宗教集会上讲述的故事：
一位教登上一列火车，由于他经常乘坐这辆车，因此列车长认识他。教士伸手到
口袋中掏车票。但没有找到，他开始翻他的行李。列车长阻止了他：“教士，我知
道您肯定有车票。现在别急着找。等找到后再向我出示。”但教士仍在找那张车票。
当列车长再次见到他时，教士说：“你不明白。我知道你相信我有车票，但 -- 我要
去哪里呢？
有太多项目失败就是因为它们没有明确的目标就开始了。OO 过程试图通过首先解决
这个问题来应付这种困境；需要几篇专栏文章才能足以细致地做到那一步，以便继续
进行分析和设计阶段。即，在可以分析之前，要有东西可以分析。
随意定制
下一步，描述的过程是我个人使用的。我并不打算使这些文章成为权威。我的工作方法
类似于 Booch、Rumbaugh 和 Jacobsen 的 RUP（Rational Unified Process，请参阅
参考资料），但我并非有意为之。事情就是那样解决的。我的工作方法还类似于
Kent Beck 的所谓 Extreme Programming（XP，请参阅参考资料），但这只是一种巧合
。
我希望您能够根据自己的需要定制我所用的过程，以使之更可工作。考虑到文学作品十
分缺乏任何过程的实践讨论，因此看起来对任何过程的实践讨论（甚至个人过程的讨论
）
都将十分有益。请不要费时考虑我是“对”还是错，只要记住我所做的只适用我个人，
并且为使之更好地为您工作而变更我所做的方式完全没有错。
工具或工具的缺乏
有关 OO 设计还要指出一点。有人曾告诉我说，他无法进行 OO 设计，因为他支付不起
：
Rose 每客户要 2500 美元，而且显然，没有 Rose 就无法设计。这里所讲的 "Rose" 是
Rational Software 所售的一种 OO CASE（计算机辅助软件工程）工具。（我可能会在
以后的专栏中详述 OO-CASE）。撇开 Rose 既不是最划算、也不是功能最强大，更不是
现有工具中最易使用的事实不说，我常常只用铅笔和纸、而不用任何高科技工具就能有
效工作 - 根本不用计算机。
正如我们要在即将出现的专栏中所见，OO 过程实际上是一种语意分析形式。它与正式的
语言学、而不是传统的过程设计技术有共同之处。我发现，计算机常常阻碍这种分析。
您
在工具上花的时间比实际完成工作所需的时间还要多。更糟的是，很多这些工具（包括
Rose）
都有令人讨厌而又苛刻的许可证管理器，它使您无法在没有通过网络与许可证管理器连
接
的便携式电脑上运行这些工具。当我使用计算机时，我通常使用一个绘图程序 (Visio)
，
而不是 CASE 工具。（这并不是说，我认为 Visio 是用于该目的的极好工具。只不过我
恰
巧有一份而已。我使用自己的模板 - 请参阅参考资料 -- 而不是内置 UML 支持。）
我要说明的观点是设计与工具无关。设计是使您明确对复杂主题的自主想法，它是一种
确保
在开始编码之前尽可能全面考虑问题的方法，并且是与其它程序员就编码进行交流的方
法。
由于在这里交流是真正的核心部分，任何对交流没有帮助的工具实际上都毫无价值。如
果您
单独坐在办公室内，面对基于计算机的 CASE 工具，那么您就不是在交流。
选择 CASE 工具无关紧要。我一般不使用任何工具，即使它们对较大的项目会有所帮助
。其
缺点是它们都会生成极差的代码，所以我不使用这些工具的代码生成或“往返工程”特
性。无论如何，往返工程的观念 --创建设计，生成代码，修改代码，然后将其逆向工程
到“设计”，这是一种根本性错误的观念。设计本身应该是单向过程。先设计，然后根
据设计实现。修改设计，然后实现修改过的设计。大多数这些工具无论如何创建出的设
计都是不正确的，因为它们不能够仅仅通过查看代码就能逆向工程程序的动态行为。
对于我们的目的，相当好的绘图程序和字处理器就已足够。
设计环境和工具
设计始终是一种团体行为。最起码，需要程序员、测试人员、用户（或者完全了解问题
领域的人）、写作很棒的人以及 UI 设计人员。您最好有书记方面的人员：能够记录和
纂写，以及将手写的草图输入到绘图程序等等。您也可以不需要这些，但设计进度会减
慢，因为小组成员不能够集中精力做他们的本职工作。
所有成员必须一起才能有效地工作，而且他们应该始终在一起。设计是专职活动，如果
希望按时间表完成，就应该不要被其他事情打扰。（虚拟合作，可能的话使用白板软件
或类似的。如果需要有效地沟通，要有视频和音频输入，才能使您看到和听到其他人员
。）
可以有的最好设计工具之一是一间专为该用途设计的房间。我的理想工作间是一间令我
心情愉快的房间。它有许多窗户和光线。墙上有可以挂白板的木板。（您可以买 4x8 大
小，类似于 Home Depot 用的三聚氰胺片，如果您愿意可以将它们安在墙上。）不要会
议室 -- 扔掉会议桌和令人不舒适的椅子（我想，这样使会议尽可能短），换上一只舒
适的沙发和几只扶椅。您需要装满食物的冰箱和需要时可以移动的小桌子。使用的主要
设计工具是：白板笔和板擦，还有可以连到联网机器的 LCD 投影仪，所有这些可以使小
组成员共同书写文档。用高分辨率照相机将图像从白板传送到计算机。最理想的是，将
设计室和如 Beck 在其 XP 一书中所述风格的工作室组合起来 - 增加几个工作站群集和
一些人们独处所需的私人空间。
通常，办公室里没有这样的空间，因此您可能得自己设计。取出螺丝刀，拆开小房间，
组合成一个大房间。如果设备人员不喜欢这样，那么就强硬一些。对公司的成功更为重
要的是：生产高质量软件，或支持“正确”办公室应该是什么样子的陈旧观念。
设计和体系结构
Microsoft 所犯的更可恶罪行之一是将动词 "to architect" 引入到英语。设计师设计
房屋，但他们不“建筑”。我提出这个词语误用的原因在于，这种语言的滥用人为地暗
示：房屋设计师和计算机程序设计师从事完全不同的活动。我坚信，无论设计房屋还是
设计软件，设计就是设计。例如，Christopher Alexander -- 房屋设计师 -- 设想了设
计模式的概念（请参阅参考资料中的 A Pattern Language: Towns, Buildings, Const
ruction），而设计模式是当代软件设计的基础。
如果您对一个承包商说：“希望您为我建造一所房屋，它的造价有多少，您是否能完成
？”。那他一定以为您疯了。然而，程序员肯定总在回答同样空泛的问题，而人们也在
问：为什么软件很少按时并在预算内交付。此外，没有承包商愿意在没有某种计划那样
复杂的情况下开工。然而，承包商自己设计的计划通常不会产生如设计师设计的那样好
的房屋。承包商的设计很自然地会简化建造和降低成本，这不一定是您要居住的房屋的
最佳选择。类似地，程序员通常不是最好的程序设计人员，因为他们的侧重点与最终用
户不同。这并不是说，一名优秀的设计师不知道如何建造他所设计的房屋，- 我确信最
好的软件设计师也是最好的程序员 - 而是说，设计和建造是两种不同的活动，不必由同
一人来承担。
设计房屋的第一步是与客户协商，并构想如何使用该房屋。设计师感兴趣的是客户的美
学，当然，他们还会问很多其它问题。有何爱好？（需要为这些爱好专门准备空间吗？
）有宠物吗？要在厨房中准备喂猫的位置吗？）有孩子吗？（他们需要玩耍房间吗？）
要几个玩耍房间？（玩耍房间要多大？）所有这些都影响房屋的设计。如果设计师对将
在房间中发生的活动不熟悉，他们还必须学习这种活动，以达到令人满意的设计。比如
，如果孩子养宠物鱼，那么，设计师还要学习池塘技术 - 不必达到宠物鱼的水准（用设
计行话说，“领域专家”），但至少要达到具有相当知识的普通人水平。请注意，重点
是将如何使用房屋。建造考虑，虽然总在设计师的考虑之内并影响设计，但不是主要的
。
下一步是勾画大量房屋、房间、地面等。这时会有很多更改 -- 改变房间位置和外形、
添加和除去固定设备和墙壁。只有当草图正确反映出客户需求时才可以说定制出一组“
最终”计划，但即使这些计划也并非真正最终的计划。他们被提交给承包商和工程师，
所有这些人都会请求更改，所有这些更改（如果可见，或至少影响成本或进度）都要由
客户同意。只有在这时才开始建造。
计划中的细节级别也有关系。大多数设计工作在开始建造房屋时才开始进行。设计师指
出墙壁伸展方向，但由承包商构想细节 -- 壁骨放置、门窗的加框等。设计师指出电器
开关的位置，而电工则构想如何布线和电气出口的位置。计划指出排水沟和排水管固定
装置，而管道工则构想如何布置管道和连接到总水管和下水道。这不是说，不设计这些
建筑部分 ，而是说，这部分设计由专门人员建造完成。设计工作常常是非正式的 - 随
工作进度现场进行。而且，大部分设计产物，如上面有绘图的纸片或墙壁内壁骨的草图
，都被丢弃，因为在建好之后，它们不再有用。当技术人员需要做的事影响其他技术人
员或整体建筑设计时，还要重新由设计师修改主计划（在征询客户同意之后）。
如果有简单和复杂的方法都可以解决同一问题，只要不影响结构的整体性和美感，则总
是选用简单的方法。但是，有时只有复杂方法可以解决问题。值得注意的是，在建造开
始之前所需的细节程度也决定了结构的复杂度。可以在一张餐巾纸上设计一间狗舍。而
一间房屋则需要更多细节。事实上，一幢摩天大楼里的每一根管道和电缆管都要设计（
尽管有时不设计墙的位置！）。
结束语
以上所述过程基本是与我用来创建软件相同的过程，它也是本专栏将逐一演示的过程。
从下个月开始，我将讲解大量细节，以便可以将细节放在相关环境中讨论。实际上，很
多这些操作都并行发生，我们将在今后几个月中看到。
了解问题领域。
与用户交流，并确定他们的需求和目标。
开发问题说明书。
设计用户界面。
开发用例。
拟出草案静态模型。
在细化静态模型时开发动态模型。
实现。
在逐一进行这些步骤时，我试图描述所发生的整个过程，包括所犯错误和如何修复错误
。结束之后，您将对这种设计过程有完整（和现实）的认识。
参考资料
查看 Adele Goldberg 和 Kenneth Rubi 所著的 Succeeding with Objects: Decision
Frameworks for Project Management，对于要转向 OO 环境的管理人员来说，这是一
本极好的书籍。
Ivar Jacobson、Grady Booch 和 James Rumbaugh 在 The Unified Software Develop
ment Process 一书中讨论了 RUP (Rational Unified Process)。
Kent Beck 在 Extreme Programming Explained: Embrace Change 中讨论了 XP (Extr
eme Programming)。XP 是有争议的，但我想，许多争论是由于人们没有首先阅读他的书
籍而做了 Beck 所说的假设而引起的。如 Grady Booch 在其新的 OO 设计书籍（可在
www.objectmentor.com 中找到 (PDF)）的草稿章节中所述，XP 和 RUP 实际上集成得相
当好。ObjectMentor 网站还有大量有关该主题的有用资料。
可从我的网站的 Goodies 一节获得一份 Visio UML 模板。
在 Christopher Alexander、Sara Ishikawa 和 Murray Silverstein 所著的 A Patte
rn Language: Towns, Buildings, Construction 中阅读更多有关设计和体系结构的内
容。
关于作者
Allen Holub 自 1979 年以来一直在计算机界工作。他在许多杂志上发表过文章（Dr.
Dobb's Journal、Programmers Journal、Byte、MSJ，以及其它杂志），并且他是在线
杂志 JavaWorld 的撰稿编辑。他有八本自己较赞赏的书，其中最新的一本（Taming Ja
va Threads）讲述了 Java 线程的陷阱和缺陷。他一直从事设计和构建面向对象的软件
很长时间了。当了 8 年 C++ 程序员之后，Allen 在 1996 年初放弃了 C++ 而转向 Ja
va 编程。他自 1982 年起一直在自己学校和为加利福利亚大学伯克利分校教编程（先是
C，然后是 C++ 和 MFC，现在教 OO 设计和 Java 编程）。Allen 在 Java 技术和面向
对象方面提供公共课程和内部培训。他也从事面向对象设计的咨询和商业性 Java 编程
。请访问 Allen 的网站 www.holub.com。
(文章推荐人：ywgcat)
|