摘要

统一建模语言（Unified Modeling Language，UML）的目的是提供一种不受语言约束和不受平台约束的建模符号。UML工具是通用的，因为UML是基础。本文是一种UML基本概念初级读物，同时提供了对建模目的的理解。这不意味着它是入门指导手册，但是它提供了许多链接，在合适的位置，把我们引导到一些优秀的教材，向我们介绍使用NetBeans IDE中UML功能的步骤。

有些工程师在开始编码之前没有时间对项目进行建模，有些工程师没有考虑在编码之前创建系统的模型。本文就是针对这些工程师们编写的。本文提供了一些方法和策略，能帮助您更加有效，并能尽可能地节省时间。本文中的信息甚至能让我们能够挑战传统，“我们没有时间做好，但是总是有时间重做”。

简介

在咖啡店，当想到“一段令人激动”的软件片段时，您激动地抓过一片纸巾，在上面勾画，使自己的思路更加明晰。这些图像就像一些鸡爪的划痕，只有您自己才能了解它们的含义。

但是它对您来说确实是有意义的：这些鸡爪划痕是一个想法的说明，可能要再花费两年的时间才能实现。您创建的是一个尚未发展完全的模型。在想象中，方框代表一种元素，而圆圈、三角以及直线则代表另一种元素。在纸巾的背后发明了一种建模语言。如果能够编译和运行纸巾，您可能会成功实现您的想法。但这是不可能的。如果再花费两个月的时间教会计算机每个纸巾对象所代表的含义，如何为每个对象生成源代码，则编译纸巾是有可能的。

经过25年的纸巾建模，创建了几种非常好的建模语言。世界已经进入统一建模语言（UML）时代。建模器收集所有的纸巾，并统一每种对象的定义以及对象间的关系。特定语言的编程人员使用这种统一建模语言，启动开发模板为不同的对象创建代码。现在，只要在作为UML一部分的纸巾上勾画对象，就可以对纸巾进行编译。

“为什么要建模？”，这是个很好的问题！在本文中，提供了两种供考虑的答案：将它们想象成UML用例。第一个答案，在“编译纸巾”部分，重点放在那些在白板或者咖啡店纸巾上勾画想法的工程师身上。本节的目的是：介绍项目计划阶段建模的优点。该部分多处链接的教材将介绍执行建模的详细情况。

“为什么选用模型”问题的第二个答案，在“他们在想什么”一节中，重点放在那些曾因处理300000行代码并对其进行维护和修复错误而倍受困扰的工程师。他很高兴地看到程序的原作者了解封装，但是仍然看不到封装是如何结合在一起的。您也希望见到系统的图示，了解程序原作者的想法。这是UML工具的一种通用用例。有效地分析代码，创建一个模型（称为“逆向工程”），利用该模型可以创建图示。

下表列出了可以在许多地方在线找到的不同类型的UML图示，为方便起见，将它们归纳于此。单击缩略图，查看某特定图示的样本。

用例图

主要由参与者和用例构成。用例图示帮助捕捉功能需求。这永远是启动一个项目的好图示。

组件图

主要由主要系统组件和它们的关系构成。这意味着是一种高级的复杂系统观查图示。无论是在头脑中、在纸巾上，或者是使用UML工具，已经为每一个已经处理的项目创建了该图示。

类图

主要由类、接口及其关系组成。类和接口很容易理解，但关系可能有些复杂。在您知道系统中有哪些组件后，接下来自然是绘制组成组件的类图。

活动图

主要由活动和决定构成。这些图示基本上是流程图和数据流图表，该图示用来获取常规的代码流。

协作图

主要由对象和消息构成。该图示将重点放在对象之间的通信，类似于程序表。

部署图

主要由服务器等部署元素以及它们的关系构成。这是系统的逻辑剖析图。

程序图

主要由对象（带生命线）和调用消息构成。程序图示描述系统中调用的顺序，以及不同对象的创建。

状态图

主要由状态、转换、事件，以及动作构成。很少需要状态图示，除非逻辑非常复杂。

编译“纸巾”

回到咖啡店纸巾上的想法。您需要为团队或者老板描述一个解决方案。因此您必须将想法从纸巾上转录到白板上，于是您将所有的同事叫到房间中，向他们介绍自己的想法。没有哪种软件工具能够替代白板前的谈话，但是如果不得不将图像发送出办公室，一般不赞成邮寄白板的宝丽来图片，或者发送白板的数字照片。白板无助于简化记录想法以便以后参考。虽然您可能不愿意，但是您必须找到UML工具，并创建描述想法的模型。

虽然模型只是模型元素及其关系的一个集合，但可以将这些元素分组形成图示。这些图示优于所有元素之和，因为它们提供模型的各种视图。不同的视图可用来告知应用程序是如何构成的。用于可视化模型的图示类型取决于您的问题。

开始工作时，可能会挑选创建“用例图示”。这是一个好的观察图示，它可确定别项目的主要组件。虽然可以将“用例图示”做得跟需要的一样复杂，但是它实际上仅有两个主要部分：“参与者”和“用例”。“参与者”代表一个将与系统进行交互的实体。实体可能是与程序进行交互的“客户”或者“银行出纳员”，参与者甚至可以是第三方库，或者是一个硬件。“用例”的主要想法是显示这些参与者能够与程序交互。例如，银行出纳员可能“存钱”或者“取钱”。在这种情况下，“存钱”和“取钱”是“用例”。没有与“参与者”或者“用例”直接相关的代码，但是这些交互揭示了对项目中某些组件的需求。

想一想虽然在计划过程中常常跳过用例，但任何编程员都明白，最终都会进行用例分析。想一想通过项目要求的内容减少不必要功能的执行并忘记其它功能。创建一个“用例”图示可以很好地揭示遗漏点。图示不能防止添加不必要的功能，但是它至少能够告知不需要它们。所以，第一步是完成一个用例分析，并创建“用例”图示。 教材向我们介绍创建一个“用例”图示的过程。

完成用例分析和图示后，自然得出了系统组件的框架。不管是在纸巾上，还是使用一种UML工具，在开发成功系统的过程中，不能跳过这一步。正式创建“组件”图示的优点是它能够帮助定义组成组件的类和接口。如果完成了“用例”图示教材，可以见到分析有多重要。从教材结束的“用例”图示中，一些必要的组件变得明显了：“客户”组件、“帐户”组件，以及“数据库”组件。用协作和程序表可以进一步定义组件之间的交互。这些组件代表系统的可交付部分。您的老板、您的客户都必须同意这些组件。组件达成一致后，设计师和编程员才去确定其他不确定的目标。设定组件后，可以开始更细致的结构性工作。

通过创建“类图示”，启动更精细的设计。此外，现成的教材将介绍创建“类图示”的详细情况。如果努力创建“用例”和精确的“组件”图示，可能试图坐下来并开始编码。但是记住上次曾经做的，以后不得不重新创建接口和超级类，因为在开始编码时，没有见到必要的关系。

当创建“类”图示时，必须将所有部分组合在一起，反应需要接口、超类，以及整个设计方案的地方。所以，这些图示的优点在于，在您编写类之前，能揭示遗传结构，并见到正在重复编写的相同方法。

使用NetBeans UML工具向“类图示”添加另一个大的方面，即设计方案。如果您知道系统的某些组件将采用一个或几个设计方案，可在画布上简单的拖放图案，创建基本组件。更好的是，工具能够正确地创建它，不用去记设计方案的实际结构。NetBeans UML添加包提供现成的Gang of Four (GoF) 和Enterprise Java Beans (EJB)设计方案。如果经常使用一个定制的设计方案，可以将其保存，以备将来使用。

好消息是这些努力没有白费。 如果使用了NetBeans UML添加包，单击一个按钮便可以将“类”图示转换成Java源代码。甚至可以为如何生成代码设置选项：页眉、注释、可变位移，以及其他格式。这些设置甚至包括向所有生成文件添加版权信息。在开发周期中，独立的代码生成应该使这一步更有价值。因此，首先创建模型，使用工具生成所有基本的代码是值得的。

每种图式都有这样那样的形式。差异在于，使用UML工具进行图解的人在完成图示时可以显示他们的计划。可能会用纸巾清理溢出的饮料，然后扔掉。每一个生思熟虑的项目将拥有某种形式的“用例”图示、“组件”图示，以及“类”图示，它们在结束咖啡店的“想象”后可以生存更长时间。

他们在想什么？

UML只是一种建模语言，并且独立于任何编码语言。因此，正像UML可以转换成编码语言一样，编码语言也可以转换成UML。该过程被称作“逆向工程”。该过程有很多种用法，但是最普通的是查看代码的结构：对象是什么，这些对象是如何联系的？代码图示能够揭示设计方案和其他在阅读代码时可能不十分明显的复杂性。“入门指导”教材使用NetBeans UML 工具，请参阅 Reverse Engineering Java Applications 或者Flash Reverse Engineering Demo。

虽然本文不是教材，如果使用NetBeans进行逆向工程，几个步骤不会起什么作用。使用免费的“Java代码库”开始。逆向构建该代码库的第一步是创建一个NetBeans“Java Project with Existing Sources”。NetBeans中的向导将帮助您实现这一过程。创建项目后，将菜单项目添加至项目，对其进行逆向工程处理。即便是大的项目，该过程也只需花费几个月。完成时，在项目树中出现UML项目。

现在可以很好地操作项目。可以使用生成的模型元素创建图示。如果需要对图示进行修改，那么进行修改并重新生成代码（被称作“正向工程”）。可以替换模型的代码，或者将其保存在其他地方。注意这些功能的作用。可以使用模型自身开发代码。这种灵活性能够保留模型的所有可视能力和报表能力，同时还能编译和运行代码。它真正做到了两全其美。如果喜欢键入代码，而不是使用图示进行创建，您也完全可以做到。当经理要求查看代码时，对代码进行逆向工程，更新模型并带着图示参加会议。

虽然逆向工程是一个非常有用的、帮助理解传承代码工具，它还是不能解决所有问题。例如，不能在使用逆向工程创建的模型中勾画用例。不要希望这样做能有任何结果，因为代码包含用例需要的不同层次信息。其他在逆向工程模型进行创建没有意义的图示是“组件”、“活动”、“协作”、“状态”，以及“部署”。但是，因为已知了类元素和关系，所以可以迅速创建这些图示，然后推导出后续问题的答案。用例是什么？部署结构是什么？主要的组件是什么？仅需提供与图示相关的丢失信息，以获得一个充分开发的模型。

总结

UML是一种语言。虽然UML中存在大的工具，它仍然是个语言。如果不理解语言的结构，工具中的设计方案只会困扰我们。为了使语言“统一”，UML已经包含了大量的功能。这种庞大的尺寸使UML工具变得笨重和难于使用。Sun Microsystems公司提供了一种类，来学习面向对象分析和设计上下文中的UML。使用对UML中不同元素上下文的理解，模型会呈现很高的实用性和效率。如果使用错误的元素创建模型，模型不会转换成代码。

不论是设计师还是编程员，在任何比“HelloWorld”复杂得多的项目中，建模是必要的一步。例如，有些建模语言将事物转换成类似数据库的设计，如果您的时间只够用来学习一种建模语言，那还是学习业界建模标准的UML吧。NetBeans UML 添加包等UML工具已经深深地融入进来，以至于建模再也不是周期的浪费，或者是编程开始后翻来覆去的学术练习。工具能够真正帮助实现编程，使我们在咖啡店也能开始设计。