【专题】统一建模语言（UML）

1. UML概述

UML是用于系统的可视化建模语言,尽管它常与建模OO软件系统相关联,但由于其内建了大量扩展机制,还可以应用于更多的领域中,如工作流程、业务领域等。

• UML是一种语言：UML在软件领域中的地位与价值就像“1、2、3、+、-、…”等符号在数学领域中的地位一样。它为软件开发人员之间提供了一种用于交流的词汇表，一种用于软件蓝图的标准语言。

• UML是一种可视化语言：UML只是一组图形符号，它的每个符号都有明确语义是一种直观、可视化的语言。

• UML是一种可用于详细描述的语言：UML所建的模型是精确的、无歧义和完整的。因此，适合于对所有重要的分析、设计和实现决策进行详细描述。

• UML是一种构造语言：UML虽然不是一种可视化的编程语言，但其与各种编程语言直接相连，而且有较好的映射关系，这种映射允许进行正向工程、逆向工程。

• UML是一种文档化语言：它适合于建立系统体系结构及其所有的细节文档。

UML的发展历史：

起源与早期发展：

• 20世纪70年代中期：面向对象建模语言最早出现。

• 20世纪80年代末至90年代初：面向对象建模语言迅速发展，数量从不到10种增加到50多种。

• 1994年：Grady Booch、Ivar Jacobson和Jim Rumbaugh开始共同提出UML的构想，旨在统一并提升各种面向对象的建模技术。

• 1995年：完成“统一方法（Unified Method）”0.8版。

• 1996年：Rational公司提出了UML 0.9版本，年底UML已经稳占面向对象技术市场的85%，成为可视化建模语言事实上的工业标准。并且，在美国，截至1996年10月，UML获得了工业界、科技界和应用界的广泛支持，已有七百多个公司表示支持采用UML作为建模语言。

标准化与广泛应用：

• 1997年：UML 1.0版本被OMG（Object Management Group）正式批准成为标准，同年11月，OMG采纳UML 1.1作为基于全面对象技术的标准建模语言。随后，UML 1.2、1.3和1.4版本相继推出。

• 2000年：UML 1.4在语义上添加了动作语义的定义，使得UML规格说明在计算上更加完整。

• 2003年：UML 1.5版本发布。

持续演进与最新版本：

• 2005年：UML 2.0规范形成，定义了许多新语法，特别是元模型的定义。

• 2009年：UML 2.2版本发布。

• 2010年：UML 2.3版本发布。

• 至今：UML已经发展到2.4版本，持续为软件开发领域提供强大的建模支持。

2. UML的结构

2.1 结构概述

构造块：

• UML有3种基本的构造块，分别是事物(thing)、关系(relationship)和图(diagram)。

• 事物是UML中重要的组成部分，关系把事物紧密联系在一起，图是很多有相互关系的事物的组。

公共机制：

• 公共机制是指达到特定目标的公共UML方法，主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制4种。

  规格说明：规格说明是元素语义的文本描述,它是模型真正的核心。 修饰：UML为每一个事物设置了一个简单的记号,还可以通过修饰表达更多的 信息。

  公共分类：包括类元与实体(类元表示概念,实体表示具体的实体)、接口和实现(接口用来定义契约,而实现就是具体的内容)两组公共分类。

  扩展机制：包括约束(添加新规则来扩展事物的语义)、构造型(用于定义新的事物)、标记值(添加新的特殊信息来扩展事物的规格说明)。

规则：

• UML用于描述事物的语义规则分别是为事物、关系和图命名。

• 给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML对系统体系结构的定义是系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说就是指5个系统视图，分别是逻辑视图、进程视图、实现视图、部署视图和用例视图。

• 逻辑视图：以问题域的词汇组成的类和对象集合。

• 进程视图：可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例描述了所设计的并发与同步结构。

• 实现视图：对组成基于系统的物理代码的文件和构件进行建模。

• 部署视图：把构件部署到一组物理的、可计算的结点上,表示软件到硬件的映射及分布结构。

• 用例视图：最基本的需求分析模型。

2.2 事物

UML中的事物也称建模元素，包括结构事物(structural things)、行为事物(behavioral things，动作事物)、分组事物(grouping things)和注释事物(annotational things，注解事物)。这些事物是UML模型中最基本的面向对象的构造块。

结构事物：

结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。总共有7种结构事物，具体如下：

• 类：类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。

• 接口：接口是指类或构件提供特定服务的一组操作的集合。因此,一个接口描述了类或构件的对外的可见的动作。一个接口可以实现类或构件的全部动作,也可以只实现一部分。

• 协作：协作定义了交互的操作,是一些角色和其他元素一起工作,提供一些合作的动作,这些动作比元素的总和要大。因此,协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。

• 用例：用例是描述一系列的动作,这些动作是系统对一个特定角色执行,产生值得注意的结果的值。在模型中用例通常用来组织行为事物。用例是通过协作实现的。

• 活动类：活动类的对象有一个或多个进程或线程。活动类和类很相似,只是它的对象代表的元素的行为和其他的元素是同时存在的。

• 构件：构件是物理上或可替换的系统部分,它实现了一个接口集合。在一个系统中,可能会遇到不同种类的构件。

• 结点：结点是一个物理元素,它在运行时存在,代表一个可计算的资源,通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个结点,但有可能从一个结点转到另一个结点。

行为事物：

行为事物是UML模型中的动态部分。它们是模型的动词,代表时间和空间上的动作。总共有两种主要的行为事物,具体如下所述。

• 交互(内部活动)：交互是由一组对象之间在特定上下文中,为达到特定的目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出包括消息、动作次序(消息产生的动作)、连接(对象之间的连接)等。

• 状态机：状态机由一系列对象的状态组成。交互和状态机是UML模型中最基本的两个动态事物,它们通常和其他的结构事物、主要的类、对象连接在一起。

分组事物：

分组事物是UML模型中组织的部分,可以把它们看成一个盒子,模型可以在其中被分解。UML只有一种分组事物,称为包。包是一种将有组织的元素分组的机制。结构事物行为事物甚至其他的分组事物都有可能放在一个包中。与构件(存在于运行时)不同的是包纯粹是一种概念上的东西,只存在于开发阶段。

注释事物： 注释事物是UML模型的解释部分。

2.3 关系

UML用关系把事物结合在一起,UML中的关系主要有以下4种：

• 依赖(dependencies)

  两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义。

• 关联(association)

  描述一组对象之间连接的结构关系,例如,聚合关系描述了整体和部分间的结构关系。

• 泛化(generalization)

  一般化和特殊化的关系,描述特殊元素的对象可替换一般元素的对象。

• 实现(realization)

  类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约。

用例之间的关系： 两个用例之间的关系可以概括为两种情况。一种是用于重用的包含关系，用构造型<<include>>表示；另一种是用于分离出不同行为的扩展关系，用构造型<<extend>>表示。

• 包含关系：

  当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例很重要的部分功能时，应该使用包含关系来表示它们。

  提取出来的公共用例称为抽象用例。

• 扩展关系：

  如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。

用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例,这被称用例泛化。

类之间的关系：

在建立抽象模型时，很少有类会单独存在，大多数都将会以某种方式彼此通信。因此还需要描述这些类之间的关系。

• 关联关系。

  描述了给定类的单独对象之间语义上的连接。关联提供了不同类之间的对象可以相互作用的连接。其余的关系涉及类元自身的描述,而不是它们的实例。

  在UML中，使用直线表示依赖关系。

  关联关系的表示：

• 依赖关系。

  有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素y的定义的修改，则称元素丫依赖于元素X。

  在UML中，使用带箭头的虚线表示依赖关系。

  依赖关系的表示：

在类中,依赖由各种原因引起。例如,一个类向另一个类发送消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的接口改变,则它发出的何消息都可能不再合法。

• 泛化关系。

  泛化关系描述了一般事物与该事物中的特殊种类之间的关系，即父类与子类之间的关系。

  继承关系是泛化关系的反关系，即子类是从父类继承的，而父类则是子类的泛化。

  在UML中，使用带空心箭头的实线表示泛化关系，箭头指向父类。

  泛化关系的表示：

• 聚合关系。

  聚合是一种特殊形式的关联，它是传递和反对称的。聚合表示类之间的关系是整体与部分的关系。

  例如,一辆轿车包含4个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。

  在UML中，使用一个带空心菱形的实线表示聚合关系，空心菱形指向的是代表“整体”的类。

  聚合关系的表示：

• 组合关系。

  如果聚合关系中的表示“部分”的类的存在与否，与表示“整体”的类有着紧密的关系，如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示这种关系。

  在UML中，使用带有实心菱形的实线表示组合关系。

  组合关系的表示：

• 实现关系。

  将说明和实现联系起来。接口是对行为而非实现的说明，而类则包含实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

  在UML中，实现关系用带有三角箭头的虚线表示。

  实现关系的表示：

• 流关系。

  流关系将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值、状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成(同一个对象的不同版本)和复制(从现有对象创造出一个新的对象)两种。

  在UML中，用带箭头的虚线表示流关系。

  流关系的表示：

2.4 图形

类图(class diagram)：

• 描述一组类、接口、协作和它们之间的关系。在面向对象系统的建模中,最常见的图就是类图。类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图。

对象图(object diagram)：

• 描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样,这些图给出系统的静态设计视图或静态进程视图,但它们是从真实案例或原型案例的角度建立的。

构件图(component diagram)：

• 描述一个封装的类和它的接口,端口.以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图，对于由小的部件构建大的系统来说,构件图是很重要的。构件是类图的变体

组合结构图(composite structure diagram)：

• 播述结构化类(如构件或类)的内部结构,包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。

用例图(usecase diagram)：

• 描述一组用例、参与者(一种特殊的类)及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时非常重要。

顺序图(sequence diagram，序列图)：

• 是一种交互图(interaction diagram)。交互图展现了一种交互,它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

通信图(communication diagram)：

• 也是一种交互图,它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念,但每种图所强调的概念不同.顺序图强调的是时序,通信图则强调消息流经的数据结构。在UM1.X版本中、通信图被称为协作图(cooperation diagram)。

定时图(timingdiagram，计时图)：

• 也是一种交互围,它强调消息跨越不同对象或角色的实际时间,而不仅仅只是关心消息的相对顺序。

状态图(state diagram)：

• 描述一个状态机,它由状态、转移、事件和活动维成。状念图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象行为,这非常有助于对反应式系统建模。

活动图(activily diagram)：

• 将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要,并强调对象间的控制流程。

部署图(deployment diagram)：

• 描述对运行时的处理结点及在其中生存的构件的配置。部署图给出了体系结构的静态部署视图,通意一个结点包含一个或多个部署图。

制品图(artifact diagram)：

• 描述计算机中一个系统的物理结构。制品包括文件数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。

包图(package diagram)：

• 描述由模型本身分解而成的组织单元,以及它们的依赖关系

交互概览图(interaction overview diagram)：

• 是活动图和顺序图的混合物。

3. 用例图

用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果一个用例定义一组用例实例。

• 它确定了一个和系统参与者进行交互、并可由系统执行的动作序列。

• 用例模型描述的是外部参与者(actor)所理解的系统功能。

• 用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。

• 在UML中，用例表示为一个椭圆。

3.1 参与者

参与者代表与系统接口的任何事物(包括其他系统)，它是指代表某一种特定功能的角色，因此参与者是虚拟的概念。

在UML中，用一个小人表示参与者。

可以通过以下问题找到系统的相关参与者：

• 谁是系统的主要用户?

• 谁从系统获得信息?

• 谁向系统提供信息?

• 谁从系统删除信息?

• 谁支付、维护系统?

• 谁管理系统?

• 系统需要与其他哪些系统交互?

• 系统需要操纵哪些硬件?

• 在预设的时间内,有事情自动发生吗?

• 系统从哪里获得信息?

• 谁对系统的特定需求感兴趣?

• 几个人在扮演同样的角色吗?

• 一个人扮演几个不同的角色吗?

• 系统使用外部资源吗?

• 系统用在什么地方?

3.2 用例

用例是对系统行为的动态描述,它可以促进设计人员、开发人员与用户的沟通,理解正确的需求,还可以划分系统与外部实体的界限,是系统设计的起点。

在识别出参与者之后，可以使用下列问题帮助识别用例。

• 每个参与者的任务是什么?

• 有参与者将要创建、存储、修改、删除或读取系统中的信息吗?

• 什么用例会创建、存储、修改、删除或读取这个信息?

• 参与者需要通知系统外部的突然变化吗?

• 需要把系统中正在发生的事情通知参与者吗?

• 什么用例将支持和维护系统?

• 所有的功能需求都对应到用例中了吗?

• 系统需要何种输入输出?输入从何处来?输出到何处?

• 当前运行系统的主要问题是什么?

4. 类图和对象图

在面向对象建模技术中，对象指现实世界中有意义的事物，具有封装性和自治性的特点;而类指具有相同属性和行为的一组对象。

• 类、对象和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统，其类模型和对象模型揭示了系统的结构。

• 在UML中，类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。

对象与人们对客观世界的理解相关，它通常用来描述客观世界中某个具体的事物。而类是对一组具有相同属性，表现相同行为的对象的抽象。因此，对象是类的实例。

在UML中，类的可视化表示为一个划分成3个格子的长方形(下面两个格子可省略)。

• 类的命名：最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语。应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。

• 类的属性：中间的格子包含类的属性，用以描述该类对象的共同特点。UML规定类的属性的语法为:“可见性属性名:类型=默认值(约特性)”。

  • 可见性：包括 Public、Private 和 Protected,分别用十、一、#表示。

  • 类型：表示该属性的种类，它可以是基本数据类型(如整数、实数、布尔型等)，也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。

  • 约束特性：用户对该属性性质一个约束的说明。例如，“(只读)”说明该属性是只读属性。

• 类的操作(Operation)：该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为:“可见性:操作名(参数表):返回类型(约束特性}”。

类图描述了类和类之间的静态关系。定义了类之后,，就可以定义类之间的各种关系了。与数据模型不同，类图不仅显示了信息的结构，同时还描述了系统的行为。类图是面向对象建模中最重要的模型。

UML中对象图与类图具有相同的表示形式,对象图可以看作是类图的一个实例。对象之间的链(Link)是类之间的关联的实例。

5. 交互图

交互图是表示各组对象如何依某种行为进行协作的模型。通常可以使用一个交互图表示和说明一个用例的行为。

在UML中，包括4种不同形式的交互图,分别是顺序图、通信图、定时图和交互概览图。

其中，顺序图强调的是时序，通信图则强调消息流经的数据结构定时图强调消息跨越不同对象或角色的实际时间，交互概览图是活动图和顺序图的混合物。

顺序图和通信图是两种基本的交互图，它们之间没有什么本质不同，只是排版不尽相同而已；定时图和交互概览图是两种特殊的变体。

5.1 顺序图

顺序图用来描述对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。顺序图允许直观地表示出对象的生存期,在生存期内,对象可以对输人消息做出响应,并且可以发送信息。

对象间的通信通过在对象的生命线间画消息表示。消息的箭头指明消息的类型。

• 顺序图中的消息可以是信号、操作调用或类似于C++中的RPC和Java中的RMI。收到消息时接收对象立即开始执行活动,即对象被激活。通过在对象生命线上显示一个细长矩形框表示激活。

• 消息可以用消息名及参数标识,消息也可带有顺序号。消息还可带有条件表达式,表示分支或决定是否发送消息。如果用于表示分支,则每个分支相互排斥,即在某一时刻仅可发送分支中的一个消息。

5.2 通信图（协作图）

通信图强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念,但每种图强调概念的不同视图,顺序图强调时序,通信图强调消息流经的数据结构。

5.3 定时图

如果要表示的交互具有很强的时间特性(例如,现实生活中的电子工程、实时控制等系统中),在UML1.X中是无法有效地表示出来的。而在UML2.0中引人了一种新的交互图来解决这类问题,这就是着重表示定时约束的定时图。

根据UML的定义,定时图实际上是一种特殊形式的顺序图(即一种变化),它与顺序图的区别主要体现在以下几个方面。

• 坐标轴交换了位置,改为从左到右表示时间的推移。

• 用生命线的“凹下凸起”表示状态的变化,每个水平位置代表一种不同的状态,状态的顺序可以有意义,也可以没有意义。

• 生命线可以跟在一根线后面,在这根线上显示一些不同的状态值:

• 可以显示一个度量时间值的标尺,用刻度表示时间间隔。

6. 状态图

状态图用来描述对象状态和事件之间的关系，通常用状态图来措述单个对象的行为它确定了由事件序列引出的状态序列，但并不是所有的类都需要使用状态图来描述它的行为，只有具有重要交互行为的类,才会使用状态图来描述。

• 状态:又称中间状态,用圆角矩形框表示。

• 初始状态:又称初态,用一个黑色的实心圆圈表示。一张状态图中只能有一个初始状态。

• 结束状态:又称终态,在黑色的实心圆圈外面套上一个空心圆。在一张状态图中可能有多个结束状态。

• 状态转移:用箭头说明状态的转移情况,并用文字说明引发这个状态变化的相应事件是什么。

一个状态也可能被细分为多个子状态,那么如果将这些子状态都描绘出来,则这个状态就是复合状态。

状态图适合用于表述在不同用例之间的对象行为,但并不适合于表述包括若干协作的对象行为。通常不会需要对系统中的每一个类绘制相应的状态图,而通常会在业务流程、控制对象、用户界面的设计方面使用状态图。

7. 活动图

活动图用来表示系统中各种活动的次序,它的应用非常广泛,既可用来描述用例的工作流程,也可以用来描述类中某个方法的操作的行为。

• 活动图是由状态图变化而来的,它们各自用于不同的目的。

• 活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中,状态的变迁可能需要事件的触发)。

7.1 基本活动图

活动图与状态图类似,包括初始状态、终止状态,以及中间的活动状态,每个活动之间,也就是一种状态的变迁。在活动图中,还引入了以下几个概念。

• 判定:说明基于某些表达式的选择性路径,在UML中使用菱形表示

• 分叉与结合:由于活动图建模时经常会遇到并发流,因此,在UML中引入了粗实线表示分叉和结合。

7.2 带泳道的活动图

在上图说明的基本活动图中,虽然能够描述系统发生了什么,但无法说明完成这个活动的对象。

针对OOP(Objeet-Oriented Programming,面向对象的程序设计)而言这就意味着活动图没有描述出各个活动由哪个类来完成。要想解决这个问题,可以通过泳道。泳道将活动图的逻辑描述与顺序图、通信图的责任描述结合起来。

在活动图中,对象可以作为活动的输人或输出,对象与活动间的输人/输出关系由虚线箭头表示。如果仅表示对象受到某一活动的影响,则可用不带箭头的虚线连接对象与活动。

在活动图中,可以通过信号的发送和接收标记表示信号的发送和接收;发送和接收标记也可与对象相连,用于表示消息的发送者和接收者。

8. 构件图

对面向对象系统物理方面进行建模,需要使用两种图,分别是构件图和部署图。构件图可以有效地显示一组构件,以及它们之间的关系。构件图中通常包括构件、接口以及各种关系。

通常来说,可以使用构件图完成以下工作。

• 对源代码进行建模。

  构件图可以清晰地表示出各个不同源程序文件之间的关系。

• 对可执行体的发布建模。

• 对物理数据库建模。

  用来表示各种类型的数据库、表之间的关系。

• 对可调整的系统建模。

  例如,对于应用负载均衡、故障恢复等系统的建模。在绘制构件图时,应该注意侧重于描述系统的静态实现视图的一个方面,图形不要过于简化,应该为构件图取一个直观的名称,在绘制时避免产生线的交叉。

9. 部署图

部署图也称实施图,构件图说明构件之间的逻辑关系,而部署图则是在此基础上更进一步,描述系统硬件的物理拓扑结构,以及在此结构上执行的软件。

• 部署图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件,常常用于帮助理解分布式系统。

结点(Node)和连接。

• 结点代表一个物理设备以及其上运行的软件系统,如一台Windows Server 主机、一个 PC 终端、一台打印机、一个传感器等

• 在UML中,使用一个立方体表示一个结点,结点名放在左上角。

• 结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接。

• 通信类型则放在连接旁边的<<>>之间,表示所用的通信协议或网络类型。

构件和接口。

• 在部署图中,构件代表可执行的物理代码模块,如一个可执行程序等。逻辑上它可以与类图中的包或类对应。

• 在面向对象方法中,类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性,称为类和构件的接口界面可以表示为一头是小圆圈的直线。

10. 补充

• 软件体系结构可以通过UML直接进行描述,请说明UML包括哪些图,以及各自的作用是什么。

  软件体系结构可以通过UML（Unified Modeling Language，统一建模语言）进行直观且详细的描述。UML是一种用于描述软件系统结构和行为的图形化语言，它提供了一套统一的符号和规则，帮助软件开发人员、设计师和其他利益相关者进行沟通、交流和理解。UML图主要包括以下几种类型，各自承担着不同的作用：

  一、结构图

  1. 类图（Class Diagram）

     • 作用：描述一组类、接口、协作以及它们之间的关系，是面向对象系统的核心建模工具。类图给出了系统的静态设计视图，活动类的类图则给出了系统的静态进程视图。

  2. 对象图（Object Diagram）

     • 作用：描述对象在某个时刻的状态和关系，是类图的一个实例化表示。对象图展示了在类图中所建立的事物实例的静态快照，更具体地描述了系统中对象的状态和属性，以及对象之间的关联。

  3. 组件图（Component Diagram）

     • 作用：描述一个封装的类和它的接口、端口，以及由内嵌的组件和连接件构成的内部结构。组件图用于表示系统的静态设计实现视图，对于由小的部件构建大的系统来说，组件图是非常重要的。

  4. 部署图（Deployment Diagram）

     • 作用：又称配置图，表示软件系统如何部署到硬件环境中。它展示了软件和硬件的映射关系，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。

  5. 包图（Package Diagram）

     • 作用：描绘系统在包层面上的结构设计，用来表示包和包之间的依赖关系。

  6. 组合结构图（Composite Structure Diagram）

     • 作用：描述结构化类（例如构件或类）的内部结构，包括结构化类与系统其余部分的交互点。它用于画出结构化类的内部内容。

  7. 轮廓图（Profile Diagram）

     • 作用：提供了一种通用的扩展机制，用于为特定域和平台定制UML模型。它用于在特定领域中构建UML模型的概要图。

  二、行为图

  1. 用例图（Use Case Diagram）

     • 作用：描述一组用例、参与者及它们之间的关系，给出系统的静态用例视图。用例图通过展示用户与系统的交互场景来描述功能需求。

  2. 状态图（Statechart Diagram）

     • 作用：描述一个状态机，由状态、转移、事件和活动组成。状态图给出了对象的动态视图，对于接口、类或协作的行为建模非常重要，它强调事件导致的行为，有助于反应式系统建模。

  3. 活动图（Activity Diagram）

     • 作用：记录单个操作、方法或业务流程的逻辑。活动图由一系列活动组成，同时包括了对这些活动的说明，能够表示并发活动的情形。

  三、交互图

  1. 顺序图（Sequence Diagram）

     • 作用：又称时序图，描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图由一组对象构成，每个对象分别带有一条竖线（称作生命线），代表时间轴，时间沿竖线向下延伸。顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。

  2. 协作图（Collaboration Diagram）

     • 作用：用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。

  3. 交互概览图（Interaction Overview Diagram）

     • 作用：是活动图和顺序图的混合物，用于在更高层次上展示系统的交互行为。

  综上所述，UML通过不同类型的图表为软件开发人员提供了一个全面且灵活的建模框架，使他们能够以可视化的方式描述、分析和设计软件系统。

• 在UML的众多图形中,最常用的图形是哪一个?在为同一个软件系统建模的过程中,是否需要将这些图形都要画出来?为什么?

  在UML（统一建模语言）的众多图形中，最常用的图形是类图。类图在面向对象系统的建模中占据了核心地位，它用于描述一组类、接口、协作以及它们之间的关系，给出了系统的静态设计视图。通过类图，开发人员可以清晰地了解系统的类结构、类的属性和方法，以及类之间的继承、实现、依赖等关系。

  在为同一个软件系统建模的过程中，并不需要将这些图形都画出来。原因如下：

  1. 需求与目的：不同的图形适用于不同的建模需求和目的。例如，类图适用于描述系统的静态结构，而活动图则适用于描述系统的动态行为。根据软件系统的具体需求和设计目标，可以选择最适合的图形进行建模。

  2. 工作量与效率：绘制所有的UML图形将耗费大量的时间和精力。在软件开发过程中，时间和资源是有限的，因此需要在保证建模质量的前提下，尽可能提高建模效率。通过选择关键和必要的图形进行建模，可以更有效地利用时间和资源。

  3. 理解与沟通：UML图形的目的是帮助开发人员、设计师和其他利益相关者更好地理解和沟通软件系统的设计和功能。通过选择最能够表达系统关键特性和行为的图形进行建模，可以更有效地传达信息，促进团队成员之间的沟通和协作。

  综上所述，在为软件系统建模时，应根据具体需求和目的选择最合适的UML图形进行建模，而不是盲目地绘制所有的图形。这样可以提高建模效率，更好地利用时间和资源，同时也有助于团队成员之间的理解和沟通。

• 如何使用4层元模型描述体系结构?

  四层元模型是OMG（对象管理组织）指定的UML（统一建模语言）的语言体系结构，用于精确定义一个复杂模型语义的基础。使用四层元模型描述体系结构时，可以遵循以下步骤：

  一、理解四层元模型结构

  四层元模型结构包括：

  1. M0层（模型实例层/信息层）：

     • 由具体的数据实例组成，这些实例是模型层中定义的数据结构的实例化。

     • 代表了系统中的实际数据和信息。

  2. M1层（模型层）：

     • 由元数据组成，这些元数据描述了M0层中的数据实例的结构和语义。

     • 是对M0层数据的抽象和描述，提供了描述信息层的一种“抽象语言”。

  3. M2层（元模型层）：

     • 由元元数据组成，这些元元数据定义了M1层中元数据的结构和语义。

     • 是对M1层元数据的进一步抽象和描述，提供了描述模型层的一种“抽象语言”。

  4. M3层（元元模型层）：

     • 由元元数据的结构和语义描述组成，定义了M2层中元元数据的结构和语义。

     • 是对M2层元元数据的最高层次抽象，为元模型提供可以使用的元素集合，包括类、协作关系、数据类型、常量和约束等。

  二、应用四层元模型描述体系结构

  1. 确定系统的关键元素和关系：

     • 首先，需要确定软件体系结构中的关键元素，如类、接口、组件、节点等，以及它们之间的关系，如继承、实现、依赖、通信等。

  2. 在M0层定义具体的数据实例：

     • 根据系统的需求，在M0层定义具体的数据实例，这些实例是系统中实际存在的数据和信息。

  3. 在M1层定义元数据：

     • 在M1层，为M0层中的数据实例定义元数据，描述它们的结构和语义。这些元数据可以包括类的属性、方法、关系等。

  4. 在M2层定义元模型：

     • 在M2层，为M1层中的元数据定义元模型，描述它们的结构和语义。这些元模型可以包括类元模型、关系元模型、数据类型元模型等。

     • 通过元模型，可以进一步抽象和描述系统的结构和行为，为开发人员提供更高层次的视图。

  5. 在M3层定义元元模型：

     • 在M3层，为M2层中的元模型定义元元模型，描述它们的结构和语义。这些元元模型为元模型提供了可以使用的元素集合和规则。

     • 通过元元模型，可以定义和约束元模型的结构和行为，确保它们的一致性和正确性。

  6. 综合各层描述体系结构：

     • 将M0、M1、M2和M3层的信息综合起来，形成一个完整的体系结构描述。这个描述应该能够清晰地反映系统的结构、行为以及各元素之间的关系。

  三、注意事项

  1. 层次之间的关系：

     • 在四层元模型中，上层模型对下层模型具有定义和约束的作用，而下层模型则是上层模型的实例和子集。这种层次关系有助于保持体系结构的一致性和正确性。

  2. 可扩展性：

     • 四层元模型提供了可扩展的元数据管理方式，允许按需添加新的类型的元数据。这有助于适应不断变化的系统需求和设计。

  3. 抽象程度：

     • 在使用四层元模型描述体系结构时，需要注意各层的抽象程度。适当的抽象程度可以帮助开发人员更好地理解系统的结构和行为，同时避免过于复杂或过于简单的描述。

  通过遵循以上步骤和注意事项，可以使用四层元模型有效地描述软件体系结构，为开发人员提供清晰、一致和可扩展的视图。

原文地址：https://blog.csdn.net/Pqf18064375973/article/details/143849569

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！