用Rational Rose和UML开发J2EE应用（1）

用Rational Rose和UML开发J2EE应用(一)- -

                                      

前言

　　成功地运用J2EE构建企业应用的关键和所有复杂的软件平台是一样的：有效的需求沟通、制定正确的分析和设计决定，并且识别最佳的实现选择。

　　追求最佳可视化模型的公司可以更快地开发它们的软件，并且建立更高质量的系统。Unified Modeling Language (UML)就是可视模型化的软件工业标准。

在这里，我们将向你介绍如何运用UML和Rational Rose 2001a，它是现今最流行的基于UML的软件模型化和开发工具，可用于开发基于J2EE的企业应用。

　　什么是UML?

　　Unified Modeling Language (UML),是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

　　使用UML作可视化模型主要是为了了解系统的重要细节，以便项目的需求可以清晰地表达、开发出解决方案体系、并且一个选择的实现可以清晰地标识和构造。为达到这个目的，需要丰富的符号来表达模型化的软件系统。UML不但为基本的构造块提供了符号表示，它还提供了方法来表达基本构造块之间的复杂关系。这些关系都以UML框图的形式表示出来。

　　以下就让我们来看一下UML和Rational Rose是如何有助于理解、设计和实现J2EE应用的。

　　理解需求

　　项目失败的原因通常是由于需求没有很好地理解或者进行沟通。我们也可以很容易地理解，无论是口头或者书面的语言，都是不严密的。

　　你可以应用UML用例模型来开发一个精确的模型来表示系统的需求，然后以这些用例为基础来推动系统开发的其它方面。用例的作用就好象是项链上的一条线，它将所有的珍珠绑定在一起。用例在最终的用户和系统需求之间建立起一座桥。它们可用来在功能需求和系统实现本身之间进行回溯。用例也可以作为一个连接点，连接到一个详细的说明需求细节的用例文档。

　　图1展示了一个在线CD商店的部分用例框图，它们是从文本和口头的功能需求中提取出来，然后转为用例。在这个例子中，很明显购买者（由几条线条组成的人物，表示为UML中的角色）可以通过4种方式来使用系统（在UML中以椭圆表示一个用例）。

***********图1********
一个简单的用例图

　　每个用例则通过顺序框图中的一个或者多个场景来精确描述。当然，在需求捕捉和分析的早期阶段，顺序图是相对简单，而且也可能是不完整的。顺序图的这样一个例子如图2所示。在Rational Rose中，要为某个用例创建顺序图，你可以在浏览器中选择它，然后从用例的菜单中选择New>Sequence Diagram。

***********图2************
一个解释付费用例的顺序图

设计一个方案

　　随后的阶段是用例分析，对于内部元素是如何交互来满足系统的功能需求，以及它们是如何相关，这个阶段提供了一个初始的、高级别的定义。这个分析需要进行反复的试验，直到产生满意的解决方案。“Analysis classes（分析类）”的行为通常是通过自然的语言描述的，比较抽象，在这个分析阶段中，它是一个有用的工具。分析类通常都不在软件中实现，虽然我们可以做到这一点，实际上，在总体设计过程中，分析类才会转换为精确定义的设计类和子系统。

　　我们首先要精心地制造顺序图，以便它们可以揭露出系统的内部运作，我们并不是通过展示角色和一个系统的交互来分析系统，而是将系统分解成独立的分析对象。系统的职责被分解到分析级别的对象中，以便可以得到一个更好的顺序图。在这里我们要介绍三种分析对象：

　　．边界对象

　　边界对象代表系统的内部工作和它所处环境之间的交互。它包括有一个用户通过图形界面的交互，与其它角色的交互（例如代表其它系统的角色），和设备的交互等。边界对象将系统的其它部分和外部的相关事物隔离和保护起来。简单地说，每一个角色-用例交互对映射到一个边界对象。

　　. 实体对象

　　实体对象代表系统的重要信息。在一个很长的时间内，它们都是持久和存在的。它们的主要目的是表达和管理系统中的信息。在模型中，系统中的关键概念以实体对象来表现。

　　. 控制对象

　　控制对象是用来模型化系统中的行为的。控制对象并不需要实现这个行为，它可能是与其它对象协作以实现用例的行为。它的想法是为了将行为和模型下层的信息隔离开来，这样在处理以后的改变时就比较容易。

　　UML提供了stereotype符号，它表示为放在一个双角括号中的文本，以便和不同类型的类区别开来。在Rational Rose中，你可以很容易地创建分析类，只需将类的stereotype字段分别修改为<>, <>和<>就可以了。这些都可以作为创建分析级框图的基础。

　　付款用例顺序图的一个更新版本如图3所示，这里系统被分解为分析对象。在这个图中，使用图标来代表边界、控制和实体对象（分别以一个T、带箭头的圆圈和一个带切线的圆表示）。

　　当然，类通常都参与到几个用例中，因此为确保系统的一致性，理解它们的静态关系也是同样重要的。对于捕捉不同结构元素的静态模型，UML类图是很有用的。

　　首先，我们标识和放置用例中所有的类到一个类框图中。我们已经将用例的行为分布到对象中，所以要分析每个类的操作就变得相对简单了。要注意的是，这些是分析的操作，这意味着随着我们不断地进行分析和设计，这些操作将会不断地需要细化。

　　Rational Rose可让你很简单地在顺序图中的分析类上定义新的操作，你只要选择现有的信息，并且在菜单上选择 就可以了（如图3所示）。如果你已经定义了一个类的操作，你可以简单地由列表上选择现有的操作。

****图3：带有分析对象的精确顺序图****

　　这是Rational Rose中的一个典型方法，它可以提高用户的生产力，并且确保整个模型的一致性和质量，另一个类似的有用特性包括有查询模型哪个类和消息是没有解释的（例如在模型中没有映射到真正的类或者操作）。

　　还有一个方面是需要标识每个类的属性。属性代表的信息，可能是其它类需要的，也可能是类自身为履行自己的职责需要的。在这个分析阶段，应将属性标识为普通的类型，例如数字、字符串等。

　　要完成用例的类图，你还需要标识类间的关系。在这个阶段中我们特别感兴趣的关系是关联、依赖和继承。

　　在分析完所有的用例和为每个用例创建类框图后，我们就需要接合各种不同的分析类来得到一个统一的分析模型。这是一个重要的活动，因为我们需要得到一个最小集合的类，并且为了避免在最后的分析模型中出现不必要的冗余。

　　这个阶段的主要任务是标识在用例间重复出现的类或者只有很小改变的类。例如，对于跨用例间拥有类似行为或者表示同样概念的控制类，我们应该将它们合并。拥有同样属性的实体类也应该被合并，它们的行为也合并为一个类。

　　图4展示了一个初步分析级的类框图（这是根据图1的用例得到的）。由于我们现今只是关系类间的关系，所以我们使用Rational Rose的显示过滤能力来过滤掉每个类的细节（通过不勾选Format>Show all attributes和Format>Show all operations就可以了）。

**********图4************
初步分析级的类框图