UML是一种通用的建模语言,其表达能力相当的强,不仅可以用于软件系统的建模,而且可用于业务建模以及其它非软件系统建模。UML综合了各种面向对象方法与表示法的优点,从提出之日起就受到了广泛的重视并得到了工业界的支持。
本章将按视图、模型元素、图以及公共机制依次介绍UML的构造和基本元素,以使得读者对UML有一个总体了解,其具体细节将在后续章节中详细描述。
2.1 视图
建模方法由建模语言和建模过程两部分构成。其中建模语言是用来表述设计方法的表示法,建模过程是对设计中所应采取的步骤的描述。UML是一种建模语言,它在很大程度上独立于建模过程。在实际建模中,建模人员最好把UML用于以用案驱动的、以体系机构为中心的、迭代的和渐增式的开发过程中。
一般而言,软件系统的体系结构给出了软件系统的组织、组成系统的构造元素及其接口的选择、系统的行为和体系结构风格等信息。也就是说,它不仅关心系统的结构和行为等功能性需求,而且也涉及系统的性能、易理解性、易复用性等非功能性需求。如图2-1所示,UML利用用户模型视图、结构模型视图、行为模型视图、实现模型视图和环境模型视图来描述软件系统的体系结构。其中:
2.2 模型元素
所有包含语义的元素都是模型元素。模型元素可以有名字,每个模型元素有与其类型相符的命名空间。在UML图中,模型元素用其相应的符 来表示。一个模型元素可以出现在多个不同类型的图中,在不同的图中以何种形式出现须遵循一定的UML规则。
图2-3中给出了UML图中最基本的设施。设施是对模型中最具有代表性成分的抽象,关系把设施结合在一起,图则聚合了相关的设施。
关联是一种结构关系,它描述了一组链,链是用来连接对象的。聚合是一种特殊的关联,它描述了整体和部分之间的结构关系。关联除可以具有方向外,也可以带有多重性标注和角色名这类修饰符。
泛化是一种特殊(或一般)关系,特殊元素的对象(子元素)可以替代一般元素(父元素)的对象。这样,子元素就可以共享父元素的结构和行为。
依赖是两个设施之间的语义关系,其中一个设施的变化会影响到另外一个设施的语义,它是一条可带方向的虚线来表示的。
实现是依赖和泛化的组合,通常在接口和实现它们的类或构件之间用到这种关系。
2.3 图
图是一组元素的图形表示,通常是由代表设施的顶点和代表关系的弧所构成的联通图。理论上,图可以包含任何设施及其关系的复合。一个典型的模型应该有多个各种类型的图。UML中包含用案图、类图、对象图、序列图、协作图、状态图、活动图、构件图和部署图9种。
2.3.1 用案图
用案图是用于描述一组用案,参与者以及它们之间的连接关系。一个用案图描述了一组动作序列,每一个序列表示系统的外部设施(系统的参与者)与系统本身的交互。从一个特定参与者的角度看,一个用案完成对其有价值的工作。如图2.5所示,用案图仅仅是从参与者使用系统的角度来描述系统中的信息,即站在系统外部查看系统应该具有什么功能,而并不描述该功能在软件内部是如何实现的。用案可以应用于整个系统,也可以应用于系统的一个部分,包括子系统、单个的类或者接口。通常,用案不仅代表这些元素所期望的行为,而且还可以把这些元素用作开发过程中测试用案的基础。
2.3.3 对象图
对象图是类图的实例,用来描述特定运行时刻一组对象之间的关系。也就是说,对象用于描述交互的静态部分,它由参与协作的有关对象组成。但不包括在对象之间传递的任何消息。
在创建对象图时,建模人员并不需要用单个的对象图来描述系统中的每一个对象。事实上,绝大多数系统中都会包含成百上千的对象。用对象来描述系统的所有对象以及它们之间的关系一般是不太现实的。因此,建模人员可以选择所感兴趣的对象极其之间的关系来描述。
对象图中所使用的符 和类图中使用的符 几乎完全相同,区别仅在于对象图的对象名带有下划线,而且类与类之间关系的所有的实例都要画出来。如图2-7A描述了各个类及它们之间的关系,图2-7B是与它对应的对象图。
序列图中的对象生命线是一条垂直的虚线,它表示一个对象在一段时间内存在。
由于序列图中大多数对象都存在于整个交互过程中,因此这些对象全部排列在图的顶部,它们的生命线从图的顶部画到图的底部。每个对象的下方有一个矩形条,它与对象的生命线重叠,它表示该对象的控制焦点。序列图中的消息可以有序 ,但由于这种图上的消息已经从纵轴上按时间顺序排序,因此消息序 通常予以省略。
2.3.5 协作图
协作图也是一种交互图,它强调收发消息的对象的组织结构。
协作图和序列图是协作的,它们可以互相转换。在多数情况下,协作图主要对单调的、顺序的控制流建模,但它也可以用来对包括迭代和分支在内的复杂控制流进行建模。
一般而言,建模人员可以创建多个协作图,其中一些是主要的,另外一些是可选择的路径或者异常条件。建模人员可以用包来组织这些协作图,并给每个图起一个合适的名字,以便与其它图区别开。图2-9给出了一个典型的协作图:
2.3.7 活动图
活动图是状态图的一种特殊情况,其中几乎所有或大多数状态都处于活动状态,而且几乎所有或者大多数变迁都是由源状态中活动的完成触发的。活动图本质上是一种流程图,它描述了从活动到活动的控制流。
可以把活动图看作是新样的交互图,但交互图观察的是传递消息的对象,而活动图观察到的是对象之间传送的消息。尽管两者在语义上的区别很细微,但它们使用不同的方式来看系统的。图2-11给出了一种典型的活动图。
2.3.9 部署图
部署图用来描述系统运行是进行处理的节点以及在节点上活动的构件的配置。部署图用来对系统的环境模型视图进行建模。在大多数情况下,部署图用来描述系统硬件的扩普结构。
在UML中,建模人员可以用类图来描述系统的静态结构,可以用序列图、协作图、状态图、活动图来描述系统的动态行为,而用部署图来描述软件所执行所需的处理器和设备的拓扑结构。图2-13给出了一个典型的部署图:
2.4.3 扩展机制
由于一种语言即使表达能力再强也难以表示出各种领域中的各种模型在不同时刻所有可能的细微差别,因此,UML提供了扩展机制,使得它可以以受控的方式进行扩展。UML的扩展包括衍型、标记值和约束。
衍型是对UML词汇的扩展,主要用于创建和已有的模型元素相似且针对特定的问题的新种类的模型元素。衍型是用书名 括起来的名字表示的,其位置在其它元素之上。
标记值是对UML元素的语义扩展,主要用于在模型元素的规约中创建新信息。标记值是用花括 括起来的字符串表示的,其位置在其它元素之下。
约束是图UML元素语义的扩展,主要用于增加新的规则或者修改已有的规则。约束是用花括 括起来的字符串表示,并且应该放在所关联的元素附近或者通过依赖关系连接相应的元素。
2.5 小结
本章就视图、模型元素、图以及公共机制依次介绍了一下。
UML中的视图是由用户模型视图、结构模型视图、实现模型视图、行为模型视图和环境模型视图5种视图组成的,它们分别用来描述系统应该具备什么样的功能、静态结构、动态行为、配置以及硬件拓扑结构,其中,用户模型视图是由用案图组成的,结构模型视图由类图和对象图组成,实现模型视图由构件图组成,行为模型视图由状态图、活动图、序列图和协助图组成,环境模型视图由部署图组成。
UML所提供的公共机制使得人们可以为各种图增添一些无法由基本模型元素表示的附加信息。
|