UML建模风格之包图

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

包图包图是在UML中用类似于文件夹的符号表示的模型元素的组合。

系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中。

使用包图可以相关元素归入一个系统。

一个包中可包含附属包、图表或单个元素。

一个"包图"可以是任何一种的UML图组成，通常是UML用例图或UML 类图。

包是一个UML结构，它使得你能够把诸如用例或类之类模型元件组织为组。

包被描述成文件夹，可以应用在任何一种UML图上。

虽然包图并非是正式的UML图，但实际上他们是很有用处的，创建一个包图是为了∶描述你的需求高阶概述。

描述你的设计的高阶概述。

在逻辑上把一个复杂的图模块化。

组织Java源代码。

指南∶类包图创建类包图，以在逻辑上组织你的设计创建UML组件图，以在物理上组织你的设计把子包放置在母包的下面垂直地分层类包图用例包图创建用例包图，以组织你的需求在用例包图上包含角色水平地排列用例包图包包的命名要简单、具有描述性应用包是为了简化图包应该连贯在包上用版型注明架构层避免包间的循环依赖包依赖应该反映内部关系一、类包图1.创建类包图，以在逻辑上组织你的设计图１描述了一个组织成包的UML类图。

除了以下介绍的包原则之外，应用下列的规则来把UML类图组织到包图里：把一个框架的所有类放置在相同的包中。

一般把相同继承层次的类放在相同的包中。

彼此间有聚合或组合关系的类通常放在相同的包中。

彼此合作频繁的类，信息能够通过UML顺序图和UML合作图反映出来的类，通常放在相同的包中。

图1.一个类包图。

2.创建UML组件图，以在物理上组织你的设计。

如果你的组件比较接近技术，例如那些通过Enterprise Java Beans ( EJB)或Visual Basic的组件，你应该优先选择UML组件图来描述物理设计，而不是包图。

图１的版本源自于组件图章节中。

就像你看到的，这个图最适用于物理设计。

永远记住遵循敏捷建模(AM) ( Ambler 2002)的实践－－应用合适的Artifact，为工作挑选最好的模型。

一个大型系统中往往包含了数量庞大的模型元素，如何组织管理这些元素是一个十分重要的问题。

包是一种常规用途的有效的组合机制。

包类似于文件系统中的文件夹或者是目录结构，它是一个容器，用来对模型元素进行分组，并且为这些元素提供一个命名空间。

UML中的一个包直接对应于Java中的一个包。

在Java中，一个包可能含有其他包、类或者同时含有这两者。

进行建模时，通常使用逻辑性的包，用于对模型进行组织。

而包图是由包和包之间的联系组成的，它是维护和控制系统总体结构的重要建模工具。

本章将详细介绍包图的各种概念、表示方法和实例应用。

1．包图的概念1.1包图和包当对大型系统进行建模时，经常需要处理大量的类、借口、构件、节点和图，这时就很有必要将这些元素进行分组，即把那些语义相近并倾向于一起变化的元素组织起来加入同一包中，这样便于理解和处理整个模型。

同时也便于控制包中元素的可见性。

包图是描述包及其关系的图。

与所有UML的其它图一样，包图可以包括注释、约束。

通过各个包与包之间关系的描述，展现出系统的模块与模块之间的关系。

图1是一个包图模型。

包是包图中最重要的概念，它包含了一组模型的元素和图，如图1中的Package A和Package B就是两个包。

Package BPackage A在面向对象软件开发的过程中，类显然是构建整个系统的基本元素。

但是对于大型的软件系统而言，其包含的类将是成百上千，再加上类间的关联关系、多重性等，必然是大大超出了人们对系统的理解和处理能力。

为了便于管理这些类，我们引入了“包”这种分组元素。

在包中可以拥有各种其它元素，包括类、接口、构件、节点、协作、用例，甚至是其它子包或图。

一个元素只能属于一个包。

包的作用是：1）对语义上相关的元素进行分组。

如，把功能相关的用例放在一个包中。

2）提供配置管理单元。

如，以包为单位，对软件进行安装和配置。

3）在设计时，提供并行工作的单元。

如，在设计阶段，多个设计小组，可以同时对几个相互独立包中的类进行详细设计。

UML之包图包图的基本概念: 包图是⽤来描述模型中的包和所包含元素的组织⽅式的图，是维护和控制系统总体结构的重要内容。

包图能够组织许多UML中的元素，不过其最常⽤的⽤途是⽤来组织⽤例图和类图。

包图中包含包元素以及包之间的关系。

与其他图类似，包图中可以创建注解和约束。

包的概念: 包是⽤于把模型组织成层次结构的通⽤机制，它不能执⾏。

包名：包有简单名、路径名包中的元素：包中可以容纳各种⾼级的模型元素，如类和类的关系、状态机、⽤例图、交互、协作等，甚⾄是⼀个完整的UML图。

另外，包中还可以含有包，这被称为包的嵌套。

包元素的可见性：控制包外元素对包内元素的访问权限。

公有（+）：只要当前包被引⼊，包内的公共元素即对引⼊者可见。

保护（#）：仅对当前包的⼦包可见。

私有（-）：仅对该包可见，外部⽆法访问。

另外，如果某元素对于⼀个包是可见的，则它对于嵌套在这个包中的任何包都是可见的。

包的构造型：可以使⽤构造型来描述包的种类。

UML预定义了⼀些构造型，⽤户也可⾃⾏定义新的构造型。

⾼内聚，低耦合：在外部观察包时，可以将内部元素视作⼀个整体，⽅便将多个元素⼀同处理。

包内部的元素应该保证有相似、相同的语义，或者其元素有同时更改和变化的性质。

注：在实际应⽤中，包对包含的元素的作⽤相当于C++和C#中命名空间的概念或Java中的包概念。

和这些概念不同的是，UML包中的内容不限于类和接⼝，包中的元素种类要丰富的多。

元素的分包原则：1）元素不能“狡兔三窟”：树形结构的⼀个节点不能同时拥有两个⽗节点，⼀个元素也不允许在两个包中重复出现。

2）相同包内元素不能重名：包所具有的命名空间的作⽤要求⽤⼀个包中的同种类元素名称必须是唯⼀的。

3）包内元素要紧密联系：分在同⼀个包中的元素应该具有某些相同的性质，即包的⾼内聚性。

4）包与包尽可能保持独⽴：包和包之间需要尽可能减少耦合度，要求包内元素与外部元素有尽可能少的依赖关系。

包的依赖关系：包之间的依赖关系实际上是从⼀个更⾼的层次来描述包内某些元素之间的依赖关系。

UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。

建模可以把在复杂世界的许多重要的细节给抽象出。

许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处。

UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。

而且每个部分都有一个小问题，测试一下你对这个部分的理解。

为什么UML很重要？为了回答这个问题，我们看看建筑行业。

设计师设计出房子。

施工人员使用这个设计来建造房子。

建筑越复杂，设计师和施工人员之间的交流就越重要。

蓝图就成为了这个行业中的设计师和施工人员的必修课。

写软件就好像建造建筑物一样。

系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。

在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。

现在它已经成为了软件行业的一部分了。

UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。

UML被应用到面向对象的问题的解决上。

想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。

一个模型model就是根本问题的抽象。

域domain就是问题所处的真实世界。

模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。

记住把一个对象想象成“活着的”。

对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。

对象的属性的值决定了它的状态state。

类Classes是对象的“蓝图”。

一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。

对象是类的实例instances。

用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。

13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。

在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。

UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。

通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。

在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。

每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。

除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。

其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。

下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。

它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。

用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。

示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。

2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。

它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。

类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。

示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。

UML中的包图介绍及其在软件架构中的应用软件开发过程中，设计和构建一个良好的软件架构是至关重要的。

而在软件架构设计中，UML（统一建模语言）的包图是一个非常有用的工具。

本文将介绍UML中的包图，并探讨其在软件架构中的应用。

1. 包图的概念包图是UML中的一种结构图，用于表示软件系统的组织结构和模块化设计。

它通过将系统划分为不同的包（Package），并显示它们之间的关系，帮助开发人员更好地理解系统的组成部分和模块之间的依赖关系。

2. 包的定义和特点包是一种逻辑组织单元，用于将相关的类、接口、用例等组织在一起。

它具有以下特点：- 包具有层次结构，可以包含其他包，形成包的嵌套关系。

- 包可以表示命名空间，用于解决命名冲突问题。

- 包可以表示模块或子系统，用于实现软件的模块化设计。

3. 包图的元素包图由多个元素组成，包括：- 包（Package）：表示一个包，用于组织相关的类、接口等。

- 类（Class）：表示一个类，用于描述系统中的对象。

- 接口（Interface）：表示一个接口，用于定义类的行为。

- 依赖关系（Dependency）：表示一个包对另一个包的依赖关系。

- 关联关系（Association）：表示包之间的关联关系。

- 泛化关系（Generalization）：表示包之间的继承关系。

4. 包图的使用包图在软件架构设计中有广泛的应用。

它可以帮助开发人员更好地组织和管理软件系统的结构，提高系统的可维护性和可扩展性。

以下是包图在软件架构中的几个常见应用：4.1 模块化设计包图可以将系统划分为不同的模块，每个模块对应一个包。

通过包图，开发人员可以清晰地了解系统的模块划分和模块之间的依赖关系，从而更好地进行模块化设计。

模块化设计可以提高系统的可维护性，降低系统的耦合度，便于开发人员进行并行开发。

4.2 系统组织和管理包图可以帮助开发人员更好地组织和管理系统的结构。

通过包图，开发人员可以清晰地了解系统的组成部分和模块之间的关系，从而更好地进行系统的组织和管理。

UML包图的应用案例UML（Unified Modeling Language）是一种软件工程领域常用的建模语言，它提供了一套标准的符号和图形表示法，用于描述和设计软件系统的结构和行为。

其中，UML包图是一种用于展示系统的层次结构和组织关系的图形表示方法。

在本文中，我们将探讨UML包图的应用案例，并分析其在软件开发过程中的价值。

一、电子商务系统假设我们要开发一个电子商务系统，该系统包含商品管理、订单管理、用户管理等模块。

我们可以使用UML包图来表示系统的整体结构和模块之间的关系。

首先，我们可以创建一个顶层包，命名为“电子商务系统”，用来表示整个系统。

然后，在该包下创建三个子包，分别是“商品管理”、“订单管理”和“用户管理”。

每个子包再进一步细分为更小的包，表示不同的功能模块。

例如，“商品管理”子包可以包含“商品信息管理”、“库存管理”等子包。

通过使用UML包图，我们可以清晰地展示系统的层次结构，帮助开发人员更好地理解和组织代码。

此外，UML包图还可以用于与团队成员和客户进行沟通，让他们更容易理解系统的组成部分和模块之间的关系。

二、学生管理系统另一个应用UML包图的案例是学生管理系统。

假设我们要设计一个学生管理系统，包括学生信息管理、课程管理、成绩管理等模块。

我们可以使用UML包图来表示系统的模块结构和组织关系。

首先，创建一个顶层包，命名为“学生管理系统”，表示整个系统。

然后，在该包下创建三个子包，分别是“学生信息管理”、“课程管理”和“成绩管理”。

每个子包再细分为更小的包，表示不同的功能模块。

例如，“学生信息管理”子包可以包含“学生基本信息管理”、“学生选课管理”等子包。

通过使用UML包图，我们可以清晰地展示学生管理系统的模块结构，帮助开发人员更好地组织和管理代码。

此外，UML包图还可以用于与教师和学生进行沟通，让他们更容易理解系统的组成部分和模块之间的关系。

三、医院管理系统另一个应用UML包图的案例是医院管理系统。

UML包图的逻辑结构与模块划分方法UML（Unified Modeling Language）是一种软件工程中常用的建模语言，用于描述和设计软件系统的结构和行为。

在UML中，包图是一种常见的图形表示方法，用于展示系统的逻辑结构和模块划分。

本文将介绍UML包图的逻辑结构以及一些常用的模块划分方法。

一、UML包图的逻辑结构UML包图是一种层次结构图，用于展示系统中不同模块之间的关系和依赖。

在包图中，使用包（Package）来表示模块，包内可以包含其他包、类、接口等元素。

通过包图，可以清晰地了解系统中各个模块之间的关系，以及模块与外部系统或其他模块的交互方式。

在包图中，可以使用依赖关系（Dependency）、关联关系（Association）、聚合关系（Aggregation）等来表示模块之间的关系。

依赖关系表示一个模块依赖于另一个模块，关联关系表示两个模块之间存在某种关联，聚合关系表示一个模块包含另一个模块。

二、模块划分方法在进行模块划分时，可以根据系统的功能、业务逻辑或者模块的复用性等因素来进行划分。

下面将介绍几种常用的模块划分方法。

1. 功能划分法功能划分法是根据系统的功能来划分模块。

首先，将系统的功能进行分类，然后将每个功能分配给不同的模块。

这种划分方法可以使得每个模块的职责清晰明确，便于开发和维护。

同时，不同的模块之间可以通过接口进行交互，提高了系统的灵活性和可扩展性。

2. 业务逻辑划分法业务逻辑划分法是根据系统的业务逻辑来划分模块。

将系统的业务逻辑进行分析，找出其中的关键业务流程，然后将每个业务流程分配给不同的模块。

这种划分方法可以使得每个模块的功能紧密相关，便于理解和维护。

同时，不同的模块之间可以通过消息传递或者调用关系进行交互，提高了系统的可靠性和可维护性。

3. 模块复用划分法模块复用划分法是根据模块的复用性来划分模块。

首先，将系统中已有的模块进行分析，找出其中具有通用性和可复用性的模块，然后将这些模块独立出来作为基础模块。

A.0、Package Diagram（包图）
包图描述了成包的模型元素的组织结构和包之间的依赖关系，包括包导入和包扩展。

它还提供了相应命名空间的可视化。

B、包之间的关系
B.1、nesting（嵌套）
嵌套连接器是另一种表示一个模型元素包含或嵌套在另一个模型元素中的图形化标记。

它是最适宜用于显示在包图中包的嵌套。

B.2、Package Import（包导入）
包导入关系是从源包指向一个内容被导入的目的包。

源包的命名空间可以访问目的包中所有非私有类。

而目的包不受影响。

目的包的私有成员不能被导入。

这种关系通常在包图中被使用。

B.3、Package Merge（包合并）
在包图中，包合并表示两个包之间的关系，目的包的内容被合并到源包中。

目的包中私有内容不会被合并。

适用于一个包的合并地址，在任何情况下，多个包包含同名元素。

Package Merge合并被合并包中的所有匹配元素，包括关系和行为。

注意到一个包合并基本上是执行概括和重定义所有匹配元素。

但被合并包中独立元素的表述依然存在，不会受到影响。

UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。

一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。

静态图分为：用例图，类图，对象图，包图，构件图，部署图。

动态图分为：状态图，活动图，协作图，序列图。

1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。

2、软件的功能。

从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。

2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。

在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。

各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。

例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。

双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。

使用Rational Rose 进行UML可视化建模以某所大学的《选修课程管理系统》为例来介绍怎样使用Rational Rose 进行UML可视化建模。

一、问题描述：1．教务管理人员将本学期要开设的课程输入教务系统，教师选择教授的课程，打印出选修课程目录表，向学生公布；2．教务管理人员将最终的学生课程表通知学生，将每门选修课的花名册(roster)通知相关教师，将有关收费情况的信息传送到财务管理系统；3．学生到财务部门办理收费手续。

二、利用Rational Rose创建《选修课程管理系统》用例图(Use Case View)1．《选修课程管理系统》中的执行者(Actors)●注册选修课程的学生(Student)；●教授选修课程的教师(Teacher)；●教务管理人员(Register)必须汇总选修课程情况，制作课程表；教务管理人员必须维护关于课程、教师和学生的所有信息；●财务管理系统(Billing System)从本系统中取出收费信息。

2．使用Rational Rose 创建执行者(Actors)图11)右击browser框中的Use Case View包，弹出快捷菜单；2)选择New——Actor项；3)输入执行者的名字；(可用Rename命令更改)3．《选修课程管理系统》中的用例(Use Case)●注册选修课程(学生)；[Register for courses]●选择教授的课程(教师)；[Select course to teach]●索取课程花名册(Roster)(教师)；[Request course roster]●维护课程信息(教务管理人员)；[Maintain course information]●维护教师信息(教务管理人员)；[Maintain teacher information]●维护学生信息(教务管理人员)；[Maintain student information]创建课程目录(教务管理人员)；[Create course catalogue] 4．使用Rational Rose 创建用例(Use Case)图21)右击browser框中的Use Case View包，弹出快捷菜单；2)选择New——Use Case项；3)输入用例的名字；(如出错，可用Rename命令更改)5．使用Rational Rose 创建主用例图(Main Use Case Diagram)1)双击browser框中的Use Case View包中的Main条目，打开主用例图；2)单击选中browser框中的执行者，并将其拖到主用例图中；3)重复第2)步，直到完成所需的工作为止；4)单击选中browser框中的用例，并将其拖到主用例图中；5)重复第4)步，直到完成所需的工作为止；6)在工具条中选择单向关联(Unidirectional Association)图标；7)单击一个执行者，并拖到相应的用例上；或单击一个用例，并拖到相应的执行者上。