依赖是指一个类使用了另一个类，它是一种使用关系，描述了一个事物的规格说明的变化可能会影响到使用它的另一个事物（反之不一定）。最常见的依赖关系是一个类内部中使用到了另一个类的定义。在UML中表示为一条指向被依赖事物的虚线。

　　依赖可以采取多种方式来实现，如以下代码

						
						
						
								internal
								 class
								 DependReturnType
{ 

}

								internal
								class
								DependParameter
{ 

}

								internal
								class
								 DependVarible
{ 

}

								class
								Depend
{

								public
								DependReturnType Test(DependParameter param)
    {
        DependVarible var 
								=
								new
								DependVarible();

								        return
								new
								DependReturnType();
    }
}
						
				

 　　当类之间在概念上有连接关系时，类之间的连接称之为关联，关联是一种结构关系，说明一个事物的对象与另一个事物的对象相联系。给定一个连接两各类的关联，可以从一个类的对象导航到另一个类的对象。
　　一般把关联画为连接相同或者不同的类一条实线。关联可以有方向，即导航。一般不作说明的时候，导航是双向的，不需要在线上标出箭头。大部分情况下导航是单向的，可以加一个箭头表示。

　　关联一般采取全局变量的方式来实现，如以下代码

Code
internalclass Employee
{
publicvoid DoWork()
    { 

    }
}

class Association
{
private Employee myEmployee;

public Employee MyEmployee
    {
get
        {
return myEmployee;
        }
set
        {
            myEmployee = value;
        }
    }

publicvoid DoSomething()
    {
        myEmployee.DoWork();
    }
}

　　依赖和关联都是一个类中使用了另一个类，那它们有什么区别呢？

　　依赖和关联都是两个或多个相对独立的类之间的关系。当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现 为依赖关系；当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。依赖关系表现在局部变量，方法的参数，以及对 静态方法的调用；关联关系是使用实例变量来实现。

　　泛化就是面向对象中的继承。它表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化的关系是从子类指向父类的，与继承或实现的方法相反。

　　代码如下

Code
internalclass Father
{ 
}
internalclass Child : Father
{ 
}
class Generalization
{
publicvoid Test()
    {
        Father father =new Child();
    }
}
　　当对象A被加入到对象B中，成为对象B的组成部分时，对象B和对象A之间为聚合关系。聚合是关联关系的一种，是较强的关联关系，强调的是整体与部分之间的关系。

　　与关联关系一样，聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语法上是没办法区分的，从语义上才能更好的区分两者的区别。

　　聚合用带一个空心菱形（整体的一端）的实线表示。

　　聚合与关联的区别：关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系，而不是聚合关系，因为人不是由自行车组成的。

　　组合是一种特殊的聚合关系，它是一种强类型的聚合，组合中的部分不能脱离整体而独立存在。例如Windows的窗口和窗口上的菜单就是组合关 系。组合中的整体和部分的生命周期一致，即部分必须在组合创建的同时或者之后创建，在组合销毁之前或者同时销毁，部分的生命周期不会超出组合的生命周期。

　　组合是用带实心菱形（整体的一端）的实线来表示。

　　组合与聚合的区别：

• 生命周期的实现上，组成需要负责其部分的创建和销毁，聚合不需要
• 组合中的一个对象在同一时刻只能属于一个组成对象，而聚合的一个部分对象可以被多个整体对象聚合，例如一个学生可以在多个学校就读，而一个菜单在同一时刻只能是某个窗口内的对象。

　　追求最佳可视化模型的公司可以更快地开发它们的软件，并且建立更高质量的系统。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************
一个解释付费用例的顺序图

概述

　　在这个面向对象应用程序开发不断变化的时代，在合理时间内开发和管理高质量应用程序变得越来越困难。为了面对这种挑战，制定出每个公司都能使用的通用对象模型语言，统一建模语言（UML）。UML是信息技术行业的蓝图，是详细描述系统结构的方法。利用这个蓝图，我们越来越容易建立和维护系统，保证系统能适应需求的改变。一个系统的模型建得好，就为满足用户需求、保证系统的稳定性和质量、提高系统的扩展性打下了良好的基础。ROSE是用UML快速开发应用程序的工具之一，它是一个面向对象的建模工具。

UML统一建模语言

　　UML，Unified Modeling Language，统一建模语言，是一种面向对象的建模语言，它的主要作用是帮助我们对软件系统进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。UML通过建立各种类、类之间的关联、类/对象怎样相互配合实现系统的动态行为等成分（这些都称为模型元素）来组建整个模型，刻画客观世界。UML提供了各种图形，比如Use Case图、类图、顺序图、协作图、状态图等，来把这些模型元素及其关系可视化，让人们可以清楚容易的理解模型。我们可以从多个视角来考察模型，从而更加全面的了解模型，这样同一个模型元素可能会出现在多个图中，对应多个图形元素。

　　由视图view，图diagram，模型元素model element和通用机制general mechanism等几个部分组成 .视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示.图是模型元素集的图形表示，通常为弧（关系）和顶点（其他模型元素）相互连接构成的.模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念.通用机制用于表示其它信息，比如注释、模型元素的语义等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户.

　　UML是用来描述模型的，用模型来描述系统的结构或静态特征，以及行为或动态特征。从不同的视角为系统的构架建模，形成系统的不同视图（VIEW）。

　　用例视图(use case view)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图；

　　逻辑视图(logical view)，展现系统的静态或结构组成及特征，也称为结构模型视图(structural model view)或静态视图（static view）；

　　并发视图(concurrent view)，体现了系统的动态或行为特征，也称为行为模型视图（behavioral model view）、动态视图(dynamic view)；

　　组件视图(component view)，体现了系统实现的结构和行为特征，也称为实现模型视图(implementation model view) ；

　　配置视图(deployment view)，体现了系统实现环境的结构和行为特征，也称为环境模型视图（environment model view）或物理视图(physical view)。

建模工具Rose 之游

　　ROSE是美国Rational公司的面向对象建模工具，利用这个工具，我们可以建立用UML描述的软件系统的模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。

　　ROSE是个菜单驱动应用程序，用工具栏帮助使用常用特性。它的界面分为三个部分--Browser窗口、Diagram窗口和Document窗口。Browser窗口用来浏览、创建、删除和修改模型中的模型元素；Diagram窗口用来显示和创作模型的各种图；而Document窗口则是用来显示和书写各个模型元素的文档注释。

Rose界面

　　Rose模型的四个视图是Use Case视图 、Logical视图、Component视图和Deployment视图。每个视图针对不同对象，具有不同用途。Use Case视图包括系统中的所有角色、案例和Use Case图，还包括一些Sequence图和Collaboration图。

Use Case视图

　　Logical视图关注系统如何实现使用案例中提到的功能。它提供系统的详细图形，描述组件间如何关联。除其它内容之外，Logical视图还包括需要的特定类、Class图和State Transition 图。利用这些细节元素，开发人员可以构造系统的详细设计。

Logical视图

　　Component视图包括模型代码库、执行库和其它组件的信息。组件是代码的实际模块。Component视图的主要用户是负责控制代码和编译部署应用程序的人。有些组件是代码库，有些组件是运行组件，如执行文件或动态链接库（DLL）文件。

　　Collaboration图关注系统的部署，可能与系统的逻辑结构不同。整个小组都用Collaboration图了解系统部署，但用户是发布应用程序的人员。

Rose的九种图

　　用例图use case diagram，描述系统功能
　　 类图class diagram，描述系统的静态结构
　　 对象图object diagram，描述系统在某个时刻的静态结构
　　 序列图sequence diagram，按时间顺序描述系统元素间的交互
　　 协作图Collaboration diagram，按照时间和空间顺序描述系统元素间的交互和它们之间的关系
　　 状态图state diagram，描述了系统元素的状态条件和响应
　　 活动图activity diagram，描述了系统元素的活动
　　 组件图component diagram，描述了实现系统的元素的组织
　　 配置图deployment diagram，描述了环境元素的配置，并把实现系统的元素映射到配置上

　　根据它们在不同架构视图的应用，可以把9种图分成：

　　用户模型视图：用例图
　　 结构模型视图：类图、对象图
　　 行为模型视图：序列图、协作图、状态图、活动图（动态图）
　　 实现模型视图：组件图
　　 环境模型视图：配置图