统一建模语言UML简介

无双

　　软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言(UML:Unified Modeling Language)的出现。在世界范围内,至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。采用UML作为我国统一的建模语言是完全必要的:首先,过去数十种面向对象的建模语言都是相互独立的,而UML可以消除一些潜在的不必要的差异,以免用户混淆;其次,通过统一语义和符号表示,能够稳定我国的面向对象技术市场,使项目根植于一个成熟的标准建模语言,从而可以大大拓宽所研制与开发的软件系统的适用范围,并大大提高其灵活程度。

　　统一建模语言（UML）是用来对软件密集系统进行描述、构造、视化和文档编制的一种语言。

　　首先，也是最重要的一点，统一建模语言融合了Booch、OMT和OOSE方法中的概念，它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。

　　其次，统一建模语言扩展了现有方法的应用范围。特别值得一提的是，UML的开发者们把并行分布式系统的建模作为UML的设计目标，也就是说，UML具有处理这类问题的能力。

　　第三，统一建模语言是标准的建模语言，而不是一个标准的开发流程。虽然UML的应用必然以系统的开发流程为背景，但根据我们的经验，不同的组织，不同的应用领域需要不同的开发过程。举个例子来说，开发错综复杂的软件是非常有趣的工作，但开发这种软件与构造严格实时的航空电子系统是大不一样的，后者是性命攸关的大事。因此我们首先把精力集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这些语义的形象化的表达）。虽然UML的开发者们将继续倡导从用例驱动到体系结构为中心最后反复改进、不断添加的软件开发过程，但实际上设计标准的开发流程并不是非常必要的。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

标准建模语言UML的内容

　　首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。

　　作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

　　(1) UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

　　(2) UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

　　标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

　　·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。

　　·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

　　·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。

　　·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。

　　·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

　　配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

　　从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

无双

Java 建模：UML 工作簿，第 1 部分
xuwanhong 转贴 (参与分：13928，专家分：340)   发表：2002-9-3 下午1:16   版本：1.0   阅读：729次


序列图简介
Granville Miller (rmiller@togethersoft.com)
顾问，TogetherSoft
2001 年 5 月

Granville Miller 在其新专栏的第一部分中介绍了“统一建模语言”(UML) 的一个构件：序列图。在整个设计过程中都会用到序列图，此图用于演示系统执行时参与者与对象之间的内部交互。让我们跟着 Granville 一起创建其中一个图，我们将使用一个贷款处理应用程序作为示例。



统一建模语言 (UML) 是用于建立面向对象系统模型的标准标记法。在 1995 到 1997 年之间，UML 登上了面向对象编程社区的舞台，而且在 1997 年后期受到了对象管理组织 (OMG) 的认可。虽然它最初颇受争议 -- 因为它是在一片支持和反对声中提出的 -- 但 UML 以后却成为系统标记法的行业标准。UML 的当前版本是 1.4，而且它将不断发展以满足面向对象开发人员的需要。（有关 UML 历史的详细信息，请参阅参考资料。）

UML 可能难以学习，主要因为它试图为相当广泛的情况提供建模标记法。每种建模标记法都采用一种图，而目前在 UML 规范中有九种图。幸好，学习 UML 可以是一个渐进过程；每次可以只学习一种图，首次试用时不必包含图中非常复杂的东西。

在本专栏中，我将教您逐步学习基于 Java 应用程序开发的 UML 设计和标记法。我将以逻辑（可能是另人愉快的）方式介绍 UML 框架和其它建模技术的基础知识，您将通过建立现实示例的模型来学习实际操作。在第一部分中，我们使用贷款处理应用程序作为示例，从建立序列图开始。请注意，假设您熟悉 Java 语言，而且掌握了面向对象方法和术语的基础知识。本专栏将简要说明面向对象的概念，但不会进行深入讨论。

关于序列图

关于参与者角色
参与者角色有助于发现和标识可以参与到用例方案中的参与者。一个参与者在一个用例和多个用例中可以有多个角色。目前，已经将四种不同的参与者角色标识成 UML 的增强或传统角色：启动程序、服务器、接收方和代理。因为可以在序列图中反映参与者角色，所以您应该熟悉它们的功能。

启动程序是设置行动中某个系统行为的外部实体。启动程序可以请求服务或生成事件。在显示参与者的序列图中，启动程序启动了行动中的序列。
外部服务器角色为其它角色提供服务。服务器通过在外部提供功能或信息来帮助系统实现其目标。许多包含了操作系统的外部系统都是服务器角色。服务器会接收消息，但也许不会生成消息。
接收方角色接收来自系统的信息。它们以消极方式提供服务。因此，它们可能不会向系统提供值，但会想其它参与者提供值。接收方的一个示例就是数据仓库或外部备份系统。接收方通常接收来自系统中对象的消息，但一般不会生成消息。
代理是代表另一个参与者执行操作的参与者。代理的一个示例就是代表顾客租借录影带的音像店职员。

UML 没有排斥任何特殊的软件开发方法或过程；它只不过标准化了标记法的格式。然而，许多开发方法都合并了 UML。Rational 统一过程 (RUP) 就是这样一种方法；另一种方法是功能驱动的开发 (FDD)。由于其直观性和通用性，UML 序列图已成为这些过程的前端建模活动的一部分。序列图用于建立以下内容的模型：
用例方案
框架中的协议
子系统
类
方法逻辑



以下是上述每个功能的简要说明。

用例方案
对于示例应用程序，我们将使用序列图来建立单个用例方案的模型。用例是由参与者与应用程序交互为实现某个指定目标而执行的单个任务。参与者可以是与应用程序交互、在应用程序外部的任何最终用户、组织或系统。（要了解四种参与者角色，请参阅关于参与者角色；如需关于用例方案的深入讨论，请参阅参考资料。）

框架中的协议
协议位于框架及其称作集合体的可交换组件之间。了解框架必需的交互有助于开发新的集合体。序列图通常用于记录这些交互。

子系统
大的项目被分解成更小且易管理的部分，称作子系统。子系统之间的接口关于将它们集成成为更大的整体（即，系统）是至关重要的。序列图用于指定子系统边界上的类之间的交互。

类
某些类（如 Socket 和 InetAddress）需要一个复杂的方法调用序列，以便正确交互。这些序列组成了用于与这样的某个类或一组类交互的协议。序列图可用于描述类或一组相互作用的类的使用，因而描述了交互所需的协议。

方法逻辑
序列图在记录方法逻辑方面非常优秀。实际上，只要给出了 Java 方法，某些 CASE 工具会自动生成一个序列图。序列图可用于设计未来方法或记录现有方法的流程。

关于示例应用程序
我们将在示例贷款处理应用程序的帮助下学习序列图。因为本专栏的重点在于建模，而不是方法，我们要直接讨论建立图，所以我们不会注重于应用程序的细节。我们为贷款处理应用程序绘制的基本功能如下：

用例：提交贷款请求

申请人通过因特网完成并向银行提交贷款申请。
系统确认贷款申请的信息，检查它是否正确以及信息是否尽可能完整。
系统向外部商业资信咨询机构转发贷款请求，以获取该申请人的信用报告。
系统根据所返回的信用报告计算申请人的信用积分。



入门
创建序列图的第一步是确定该图是否表示与外部或内部实体的交互。如果正在建立用例方案的模型，那么序列图通常表示与外部实体的交互。如果正在建立框架中协议的模型，那么此图也许表示内部或外部交互。子系统图、类图和个别方法逻辑图通常只表示内部实体。无论是哪种情况，将要建模的交互类型决定了序列图中的第一个（最左边的）元素。

与外部实体的交互表示参与者是交互的一部分。内部交互可能由参与者启动（如果子系统用例是交互的基础），但它更可能是由叫作 Sender 的普通类启动的。如果参与者启动了交互，那么参与者将归入启动程序类别，这是四种常见参与者角色之一（有关详细信息，请参阅关于参与者角色）。

我们将关注为贷款处理应用程序（以上概述的提交贷款请求用例）的方案建立图。请注意当申请人完成在线贷款申请并在因特网上提交它时序列图的变化。在这个方案中，申请人在系统外部，因此用参与者来表示他。我们首先将参与者 Applicant 添加到序列图，如图 1 所示。

图 1. 添加申请人


添加参与者
一旦交互的启动程序就位，下一步就是添加它在方案的过程中将与之交互的对象。这些对象的名称应该反映出类或实例的行为。（类或实例的选择给出了与序列图截然不同的含义，但我将把这两者之间差异保留到下次讨论。）

对于示例方案，我们将添加两个类：LoanApplication 和 LoanRequest。当申请贷款时，需要提交贷款申请。它包含了关于申请人和期望贷款金额的信息。贷款请求是银行向商业资信咨询机构发送的关于接受贷款申请的表单。它包含了来自贷款申请的一些信息，以及获取关于申请人的信用历史记录信息的请求。图 2 中显示了将这两个类添加到序列图中。

图 2. 添加两个交互类


连接各点 -- 虚线
对于大多数软件开发人员来说，序列图是直观的。它们将对象和参与者（横轴）映射到时间（纵轴）。消息连接了对象，当消息发生时，它们沿着纵轴从一个对象移动到另一个对象。这些消息被连接到从对象或参与者底部的中间延伸出的竖直虚线。这条线被称作 生命线。

在横轴上，我们用被称作调用箭头或消息箭头的箭头来表示消息。消息箭头从发送方（尾）指向接收方（头）。这些箭头用于捕捉系统的动态行为。调用通常始于左边，向右边移动。即，交互中的初始箭头通常来自左边。当创建类的新实例时，我们绘制的箭头都指向类自身，而不是生命线。我们方案中的第一步是创建新的贷款申请，因此我们在 Applicant 和 LoanApplication 之间画出箭头。由于用 Java 创建新实例涉及到调用构造器，因此我们将这个箭头标上构造器名称，可能的话，还要标上变量。

我们仍处于软件开发生命周期中的分析阶段，因此我们要仅可能多地包含分析信息。我们的一个商务分析员提到我们把创建新贷款申请的操作称作“完成贷款申请”。如果我们要在构造过程中使这个序列图保持为真，那么可以将 complete 实现成公用方法，它将调用 LoanApplication 构造器，如图 3 所示。

图 3. 创建 LoanApplication


建立某个活动的图
但类或实例接收到消息时，它会在接收对象的生命线上创建一个框；这个框称作 活动。活动表示接收方的方法中的控制权流向。当消息导致创建了一个对象时，第一个活动表示构造器的逻辑。随后的消息将导致创建新的活动。

但接收到消息时，接收对象可以依次将消息发送到它自身或其它对象。这由箭头的尾巴显示，它表示箭头源于活动，而终止于新的活动。但对象调用自身时，新的活动将放到旧活动之上。

在此方案中，申请人与贷款申请交互两次，第一次是完成它，而第二次是提交它。当 LoanApplication 接收到 submit 消息时，它会通过将 validate 消息发送到自身来验证它自己。如果有效，则它会创建要发送到商业资信咨询机构的新 LoanRequest。图 4 显示了 LoanApplication 的验证过程。

图 4. 确认 LoanApplication


箭头文件：表示时间流逝
我们使用斜向箭头来表示消息发送和接收之间的真实时间的流逝。这种标记法用于显示非基本调用。非基本调用的示例是经由 CORBA 或 RMI 进行的方法调用，或是在网络上发送的消息。

在此示例中，商业资信咨询机构是一个外部系统，它是具有服务器角色的参与者（有关详细信息，请参阅关于参与者角色）。服务器通常不生成消息，但会有发送给它们的消息 -- 在本例中是由信用检查器发送的信用报告的请求。信用检查器代表了商业资信咨询机构。它跟踪请求并将请求转发给商业资信咨询机构，跟踪并接收响应，此外就是建立贷款处理应用程序和商业资信咨询机构之间的连接。商业资信咨询机构将接收请求，并根据它自己的时间表处理请求。我们使用斜向箭头表示这段时间的流逝，如以下的图 5 所示。

在活动的结尾，返回到调用程序的结果是隐式的。然而，在某些情况下，您可能希望返回是显式的。显式返回调用由虚线箭头表示，该箭头的尾巴是接收方，头是发送方。显式返回箭头通常由调用返回的值标记。对于此示例，我们已经在 CreditBureau 和 CreditChecker 之间添加了显式箭头。这个箭头可以是带标签的 CreditReport，因为它是从 requestCreditReport 方法返回的对象。

图 5. 获取 CreditReport


下一步
我在本文开头已经提到过，序列图用于描述系统运行时的内部行为。在本文中，我已经介绍了通过建立对象间交互的模型来构建序列图的第一步。在下一部分中，我将介绍两种序列图（常规和实例），并使用根据简单的 Java 方法绘制的示例说明条件逻辑在序列图中的角色。到时候见！

参考资料

单击本文顶部或底部的“讨论”参加关于本文的讨论论坛。


Martin Fowler（ UML Distilled 的作者）提供了 UML 早期历史的 内幕。


Fowler 的“ 为什么使用 UML”进一步说明了开发周期中对标准化标记法的需要（Software Development Online，2000 年 3 月）。


如果您想要认真学习 UML，那么应该从三个朋友（Booch、Jacobson、Rumbaugh）撰写的原文开始： 统一建模语言用户指南（Addison Wesley Object Technology Series，1998）。


接下来应该学习的基本读物是 OMG 的统一建模语言规范（2001 年 2 月时的版本是版本 1.4）。


Rational 的 UML 资源页面提供了关于 UML、RUP 的信息以及其它内容。


有关序列图和 UML 的额外信息，请参阅 "建立带有样式的 UML 序列图"，由 Scott W. Ambler 著（developerWorks，2001 年 2 月）。


Allen Holub 在他有关面向对象设计过程的系列中提供了 用例方案的深入说明（developerWorks，2001 年 1 月）。


如果要更深入地研究用例建模，请参阅 Frank Armour 和 Granville Miller 合著的 "Advanced Use Case Modeling, Volume I: Software Systems"（Addison-Wesley，2001）。


如需关于功能驱动的开发和 Rational 统一过程的优秀读物，请参阅 Peter Coad、Eric Lefebvre、Jeff DeLuca 合著的 Java Modeling in Color with UML（Prentice Hall，1999）。


关于 RUP 的另一本好书是 Philippe Kruchten 撰写的 The Rational Unified Process: An Introduction（Addison Wesley，2000）。


请阅读 OCL，它是 UML 的表达式语言。


IBM 和其它一些业界领先者创建了 XMI，一种新的开放业界标准，它将一些基于 Web 的用于编辑、确认和共享文档格式等 XML 标准的优点和 UML 的优点结合了起来。


关于作者
Granville 加入面向对象社区已有 13 年了。他是高级用例建模 (Advanced Use Case Modeling) 系列的合著者，并在全世界范围的各种面向对象技术会议中介绍过教程。他的面向对象开发的实践方法来自于他在多家公司供职的经验，其中包括从处于创业阶段的公司到相当成熟的软件业巨擘在内的各种公司。

他目前正在教授有关灵活过程、方法和 Java 技术的研习班、教程和课程，同时还在辅导和帮助实现一些积极的项目。可以通过 rmiller@togethersoft.com 与 Granville 联系