UML 概述

 

• UML统一建模语言

     1997年OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。它目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划，就像建筑工人多年来所使用的建筑设计图一样。UML符号集只是一种语言而不是一种方法学。这点很重要，因为语言与方法学不同，它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。既然UML不是一种方法学，它就不需要任何正式的工作产品。而且它还提供了多种类型的模型描述图，当在某种给定的方法学中使用这些图时，它使得开发中的应用程序的更易理解。通过把标准的UML图放进您的工作产品中，精通UML的人员就更加容易加入您的项目并迅速进入角色。

     最常用的UML图包括：用例图、类图、序列图、状态图、活动图、组件图和部署图。

• 模型驱动开发

     “模型驱动”开发（MDD）方式，已经显示出了它们从根本性上提高软件质量和开发生产力方面的潜力。与传统的方法相比，这种方式是基于较高层次上的抽象和自动化。

     解决这一难题的方法是通过一个或多个自动的模型转换器将一个模型与它相应的软件实现从形式上连接起来。也许这方面最好和最成功的例子就是编译器，它能够将一个高级语言程序解释成一个与之相当的机器语言的执行程序。这种情况下，模型就是这个高级语言程序，隐藏了潜在的计算技术特性上的相关细节。

     在抽象性和自动化抽象性与自动化操作强有力的结合后，所产生的潜能已经导致新的建模技术和相关发展方法的出现,正如所提及的模型驱动开发。MDD的定义特征是，此模型已经成为软件设计的主要工具，它把许多注意力从相关的程序代码上转移开。它们为不同的自动化和半自动化的方法提供服务，这种方法源于代码和相关的模型。与传统的编码相比较，目前在MDD中使用自动化操作的程度不同于从简单框架代码到完全自动的产生代码。很明显地，自动化程度越高，模型越精确，MDD的优越性就更突出。

• 语言单元

语言单元 目的 动作 (基础) 细粒度动作的建模 活动 数据和控制流行为建模 类 (基础) 基本结构的建模 组件 组件技术的复杂结构建模 部署 部署建模 通用行为 (基础)公共行为语义基础和时间建模 信息流 抽象数据流建模 交互 内部对象行为建模 建模 模型组织 Profiles 语言定制化 状态机 事件驱动行为建模 结构 复杂的结构建模 模板 模式建模 用例 非正式的行为需求建模

• UML分类

• • 静态图

     静态图主要描述类、对象、数据结构以及他们之间的关系，从而展现软件元素间那些不变的逻辑结构。

• • 动态图

     动态图主要展现了软件实体在运行过程中是如何变化的，其中描述了运行流程或者实体改变状态的方式。

• • 物理图

     物理图主要展示了软件实体不变的物理结构，其中描述了文件、库、二进制文件、数据库文件等物理实体间的关系。

• 类图

     类图表示不同的实体如何彼此相关。

     类图显示了系统的静态结构，类图可用于表示逻辑类，逻辑类通常就是业务人员所谈及的事物种类。类图还可用于表示实现类，实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一些相同的类。然而，实现类图不会使用相同的属性来描述，因为它很可能具有对诸如Vector和HashMap这种事物的引用。

     类在类图上使用包含三个部分的矩形来描述，如图所示，最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作方法。

 

     对于下图，您应该使用带有顶点指向父类的箭头的线段来绘制继承关系，并且箭头应该是一个完全的三角形；如果两个类都彼此知道对方，则应该使用实线来表示关联关系；如果只有其中一个类知道该关联关系，则使用开箭头表示。

     我们同时看到了继承关系和两个关联关系。CDSalesReport类继承自Report类。一个CDSalesReport类与一个CD类关联，但是CD类并不知道关于CDSalesReport类的任何信息。CD类和Band类都彼此知道对方，两个类彼此都可以与一个或者多个对方类相关联。

 

• 序列图

     序列图显示具体用例的详细流程。

     它几乎是自描述的，并且显示了流程中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。

     序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。

     序列图的绘制非常简单。横跨图的顶部，每个框表示每个类的实例对象。在框中，类实例名称和类名称之间用空格/冒号/空格来分隔。如果某个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息/方法的名称放在连线上面。对于某些特别重要的消息，您可以绘制一条具有指向发起类实例的开箭头的虚线，将返回值标注在虚线上。

 

• 状态图

     状态图表示某个类所处的不同状态和该类的状态转换信息。

     有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图。只对在系统活动期间具有三个或更多潜在状态的类进行状态图描述。

     如图所示，状态图的符号集包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。要绘制状态图，首先绘制起点和一条指向该类的初始状态的转换线段。状态本身可以在图上的任意位置绘制，然后只需使用状态转换线条将它们连接起来。

 

• 活动图

     活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。

     活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。活动图最适合用于对较高级别的过程建模，比如公司当前业务如何运作等。

     活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形来表示的。活动可以通过转换线段连接到其他活动，或者连接到判断点，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点。作为一种选择，活动可以分组为泳道，泳道用于表示实际执行活动的对象。

 

• 组件图

     组件图提供系统的物理视图。

     它的用途是显示系统中的软件对其他软件组件的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次上显示。

 

• 部署图

     部署图表示该软件系统如何部署到硬件环境中。

     它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。

     部署图中的符号包括组件图中所使用的符号元素，另外还增加了几个符号，包括节点的概念。一个节点可以代表一台物理机器，或代表一个虚拟机器节点。要对节点进行建模，只需绘制一个三维立方体，节点的名称位于立方体的顶部。所使用的命名约定与序列图中相同：[实例名称] : [实例类型]。

• 符号
• • 框架元件

     框架元件用于作为许多其他的图元件的一个基础，但是大多数人第一次接触框架元件的情况，是作为图的图形化边界。当为图提供图形化边界时，一个框架元件为图的标签提供一致的位置。在 UML 图中框架元件是可选择的；图的标签被放在左上角，在我将调用框架的“namebox”中，一种卷角长方形，而且实际的 UML 图在较大的封闭长方形内部定义。

     除了提供一个图形化边框之外，用于图中的框架元件也有描述交互的重要的功能, 例如序列图。在序列图上一个序列接收和发送消息（又称交互），能通过连接消息和框架元件边界，建立模型。