OO 设计过程 1

OO 设计过程：入门
如何设定优先级

Allen Holub
撰稿编辑，JavaWorld
2000 年 7 月

欢迎阅读本在线课程的第一部分。在本专栏中，我打算让您实际操作，以亲

身体验面向对象 (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 设计人员。您最好有书记方面的人员：能够记录和纂写，以及将手写的草图输入到绘图程序等等。您也可以不需要这些，但设计进度会减慢，因为小组成员不能够集中精力做他们的本职工作。

所有成员必须一起才能有效地工作，而且他们应该始终在一起。设计是专职活动，如果希望按时间表完成，就应该不要被其他事情打扰。（虚拟合作，可能的话使用白板软件或类似的。如果需要有效地沟通，要有视频和音频输入，才能使您看到和听到其他人员。）

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有