| UML(Unified Modeling Language)伙伴组织于1996年由Rational公司创立。对象管理组织（OMG）于1997年11月采纳了它。此后，UML继续改进，目前最新的版本是UML1.3。 UML是多种方法相互借鉴、相互融合、趋于一致、走向标准化的产物。这样的统一建模语言将为软件开发商及其用户带来诸多便利。美国等计算机技术发达国家已有大量的软件开发组织开始用UML进行系统建模，学习和使用UML已经成为一种潮流。我国软件界对UML也相当关注，许多研究人员和技术人员已在几年前就开始了对UML的学习和研究。 现在有更多的人想学习UML，但由于UML的复杂性，仅通过UML的标准文献和国内目前的关于UML的资料来掌握使用它不是一件轻松的事。对它的使用，关键是要用它简明准确地建立模型。这样，人们就可以从全局把握复杂系统的全貌及其组成间的联系。为了达到这样的目的，本文要阐明UML的要点，并对UML所推荐的软件建模过程RUP（Rational Unified Process）做一简介，以作为一种应用UML的过程指导。 UML的定义有两个主要组成部分：语义和表示法。UML的语义用自然语言描述，表示法定义了UML的可视化标准表示符号，这决定了UML是一种可视化的建模语言。这些图形符号和文字用于建立应用级的模型，在语义上，模型是元模型的实例。此外UML的定义还给出了语法结构的精确规约。对于一般建模者，应重点掌握基本的概念与表示法，并熟练运用它们，建立元模型则是研究方法学的人的研究重点。 要点：对系统的组织 UML是一种可视化的建模语言，对其各建模元素可进行详细说明，并能生成所建模型的文档。使用UML时，要从不同的角度观察系统，为此定义了一个概念“视图”。视图是对系统的模型在某方面的投影，注重于系统的某个方面。每个视图是图的协作，UML定义了9种图。下表是UML中的5种视图，各视图在静态和动态方面表示了系统的模型。 由视图可以定义模型，模型在语义上是闭合的，它从特定的角度（系统的规约或者设计）在一定抽象层次上描述目标系统。可以把视图组织成模型，开发人员可从各视角观察使用模型。 用以描述系统的模型可以是结构性的，强调系统的组织；也可以是行为性的，强调系统的动态方面。例如，RUP有9种模型，分别是业务模型、领域模型、用况模型（也称需求模型）、分析模型、设计模型、过程模型、部署模型、实现模型和测试模型，用于从不同的角度表示系统。 系统是一组反映不同侧面的子系统的集合，为了完成特定的目的要对这些子系统进行组织（在逻辑、功能和物理位置上是高内聚、低耦合的）。 子系统是一组元素的聚集，其中的元素还可以是子系统。它由一组模型从不同的角度进行描述。子系统本身几乎应是独立的，有自己应用的环境，相互间不重叠，它们之间用接口联系。 UML的概念模型 为了理解UML，需要掌握UML的概念模型，这要求学习三个要素：UML的基本构造块、支配这些构造块如何放在一起的规则和一些运用于整个UML的机制，下面逐一予以介绍。 1. 基本构造块 UML中有三种基本构造块，分别是事物、关系和图。 事物分结构事物（包括类、接口、协作、用况、主动类、构件和节点）、行为事物（包括交互和状态机）、分组事物（包）和注释事物（注解）。 UML中有四种关系，分别是依赖、关联、泛化和实现关系。 对于上述两种构造块，通过研读相应的书籍，绝大多数不难掌握，这里就不再赘述。下面对UML中的图的要点进行阐述。 类图 类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。 对象图 对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。 用况图 用况图展现了一组用况、参与者以及它们间的关系。可以用用况图描述系统的静态使用情况。在对系统行为组织和建模方面，用况图的是相当重要的。 交互图 交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用况的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。 顺序图 展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。 协作图 展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。 状态图 展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用况实例的生命周期。 活动图 活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。 高层活动图用于表示需要完成的一些任务，即用于分析用况，理解涉及多个用况的工作流、多线程及并行，显示相互联系的行为整体，还可用于对企业过程建模，对系统的功能建模。低层活动图用于表示类的方法。但活动图不适用于描述动作与对象间的关系，显示对象间的合作以及显示对象在生命周期内的运转情况。 构件图 构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。 部署图 部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统。 UML用于描述事物的语义规则分别是：为事物、关系和图命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。另外，UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素以及不保证模型的完整性，但模型逐步地要达到完整和一致。 3. 机制 有四种在整个语言中一致应用的机制，使得该语言变得较为简单。这四种机制是详细说明、修饰、通用划分和扩展机制。 UML不只是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个详细说明，提供了对构造块的语法和语义的文字叙述。 UML表示法中的每一个元素都有一个基本符号，这些图形符号对元素的最重要的方面提供了可视化表示，对元素的描述还包含其他细节。例如，一个类是否是抽象类，或它的属性和操作是否可见。要把这样的修饰细节加到基本符号上。 在对面向对象的系统建模中，至少有两种通用的划分世界的方法：对类和对象的划分；对接口和实现的划分。UML中的构造块几乎都存在着这样的两分法。 UML是开放的，可用一种受限的方法扩展它。UML的扩展机制包括构造型、标记值和约束。 UML的应用 UML是一种建模语言，不是一种方法，它独立于过程。利于它建模时，可遵循任何类型的建模过程。该建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。本部分阐述RUP如何支持UML的应用。 RUP是以用况为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流（包括5个活动），请参见下图。 1. 初始阶段 本阶段确定所设立的项目是否可行，具体要做如下工作： 对需求有一个大概的了解，确定系统中的大多数角色和用况，但此时的用况是简要的。对给出的系统体系结构的概貌，细化到主要子系统即可。 识别影响项目可行性的风险。 考虑时间、经费、技术、项目规模和效益等因素。 关注业务情况，制订出开发计划。 2. 细化阶段 识别出剩余的大多数用况。对当前迭代的每个用况进行细化，分析用况的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用况。 需求风险 考虑项目的目标是否偏离了用户的需求。为解决需求风险要充分了解用户需求以及各需求的优先度，还应尽量列出所有的用况，至少列出重要的用况，并要建立领域的概念模型。 技术风险 考察所选的技术方案是否可行。建立原型是解决技术风险的一种有效方法。 技能风险 考虑实施项目的人员素质能否胜任项目的要求。 政策风险 考虑政策性的因素对项目的影响。 ● 进行高层分析和设计，并作出结构性决策。 所产生的基线体系结构包括用况列表、领域概念模型和技术平台等。以后的阶段对细化阶段建立的体系结构不能进行过大的变动。 ● 为构造阶段制订计划。 细化阶段完成，意味着已经完成了如下的任务：用况完全细化并被用户接受；完成概念验证；完成类图；开发人员能给出项目估算（可分为精确、人月和无法估算）；基于用况考虑了所有风险（可分为高风险、可能的风险和不可能的风险），并制订了相应的对策和计划；对用况标出优先级（可分为必须先实现、短期内实现和长期实现）。 3. 构造阶段 识别出剩余的用况。每一次迭代开发都针对用况进行分析、设计、编码（如类声明、属性声明、范围声明、函数原型声明和继承的声明等）、测试和集成过程，所得到产品满足项目需求的一个子集。由于细化阶段的软件设计已经完成，这样各项目组可以并发开发。 在代码完成后，要保证其符合标准和设计规则，并要进行质量检查。对于新出现的变化，要通过逆向工具把代码转换为模型，对模型进行修改，再重新产生代码，以保证软件与模型同步。 此阶段要建立类图、交互图和配置图；如一个类具有复杂的生命周期，可绘制状态图；如算法特别复杂，可绘制活动图。 4. 移交阶段 这一阶段完成最后的软件产品和最后的验收测试，并完成用户文档编制以及用户培训等工作。 结束语 可以说，UML对系统模型的表达能力超出了以往任何一种面向对象的分析和设计方法。随之出现的问题是，它的复杂性也超出了以往任何一种方法。由于UML的复杂性，对它的掌握和使用确实不是一件轻松的事。建议对UML掌握和使用本着由简至难的原则，即熟练掌握基本的概念与表示法后，再学习使用UML的更深入部分。UML的三位创始人所著述的《The Unified Modeling language》也是这样组织内容的。关于UML的作者所推荐的过程指导，请阅读他们著述的《The Unified Software Development Process》。此外北京大学也推出了一套青鸟面向对象软件开发规范，其中包括有一套很完整的过程指导。 UML是一种建模语言，不是一种方法，它独立于过程。利于它建模时，可遵循任何类型的建模过程。该建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。本部分阐述RUP如何支持UML的应用。RUP是以用况为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流（包括5个活动），请参见下图。用况驱动旨在为到最终产品为止的每个阶段都可以回溯到用户的真正需求。以体系结构为中心是指关注体系结构模式的开发，以引导后续系统，保证系统的平滑演进。每一次迭代包括迭代计划、迭代评价和一些具体活动。关于核心工作流中的五个活动：需求、分析、设计、实现和测试较好理解，这里不再赘述。下面对RUP的四个阶段要做的工作做一阐述。本阶段确定所设立的项目是否可行，具体要做如下工作：对需求有一个大概的了解，确定系统中的大多数角色和用况，但此时的用况是简要的。对给出的系统体系结构的概貌，细化到主要子系统即可。识别影响项目可行性的风险。考虑时间、经费、技术、项目规模和效益等因素。关注业务情况，制订出开发计划。识别出剩余的大多数用况。对当前迭代的每个用况进行细化，分析用况的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用况。考虑项目的目标是否偏离了用户的需求。为解决需求风险要充分了解用户需求以及各需求的优先度，还应尽量列出所有的用况，至少列出重要的用况，并要建立领域的概念模型。考察所选的技术方案是否可行。建立原型是解决技术风险的一种有效方法。考虑实施项目的人员素质能否胜任项目的要求。考虑政策性的因素对项目的影响。 |
