您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
从UML 2.4 到UML 2.5的规范变化
 
作者:俎涛(火龙果软件工程)
 
  644  次浏览      4 次
2022-6-9
 

说明:本文的图例内容大多自于UML2.4.1和UML2.5.1规范文档,为了提高可读性,部分图例采用了 建模工具EA和iSpace进行了重建。

前言

最近帮助客户建立某个领域的建模语言规范,用到元模型建模。为了参考UML的元模型和MOF(Meta Object Facility),看了UML 2.5.1的规范文档,发现和UML2.4的关于规范的结构完全不同。觉得有必要写一篇文章,介绍一下二者的不同,可以供建模者作为参考。

UML 2.4.1 规范 的构成

记得 UML2.5 以前, UML 的规范都会发布2个文档:

•  UML Infrastructure : UML 基础结构:主要提供 UML 的元模型建模机制。

•  UML Superstructre : UML 上层结构:提供 UML 的各种元素和图的语义说明、外观和元模型机制。

如下是 UML2.4.1 的 2 个规范相关的文档。

 

 

如下是 UML2.4.1 的规范的构成概览图:

下面,对 UML 2.4.1 规范的内容进行摘录解读

UML Infrastructure

UML Infrastructure 由 infrastructure Library 定义,它的目标是 : 

• 定义一个元语言核心,可以重用它来定义各种元模型,包括 UML 、 MOF 和 CWM 。  

• 在体系结构上对齐 UML 、 MOF 和 XMI ,以便完全支持模型交换。  

• 允许通过 profile 定制 UML ,并基于与 UML 相同的元语言核心创建新的语言 ( 语言家族 ) 。

UML Infrastructure 的内容如下图所示:

其中 Core 包建定义了建立其他模型的元模型的 metaclass 和抽象语法。 Profile 提供了从 metaclass 扩展其他建模语言的机制。 Core 包可以作为其他建模语言( UML 、 CWM )的基础,同时也作为 MOF 的基础。

从 Core 包抽取了 MetaClass ,建立了专门用于定义元模型的 MOF 后,又把 MOF 作为定义 UML 的基础。这也就建立了 MDA 的基础。

 

建模是一个从抽象到具体的过程,按照模型的抽象程度,可以分为四个层次:

•  M3: 元元模型,用于建立其他模型的模型。

•  M2 :元模型,用于建立特定领域的模型, UML 处于此层次

•  M1 :特定领域的模型,例如软件模型,业务流程模型

•  M0 :运行时的实例模型。

如下是来自于 UML Infrastructure 的 模型层次示意图:

 

UML Superstructure

UMLSuperstructure 是 UML 规范自身的定义。

UML 的建模概念被分组成语言单元。   语言单元由一组紧密耦合的建模概念组成,这些概念为用户提供了根据特定的范式或形式来表示所研究系统的各个方面的能力。   例如, State Machines 语言单元允许建模人员使用众所周知的状态图形式的变体来指定离散的事件驱动的行为,而 Activities 语言单元提供了基于工作流样例的行为建模。   从用户的角度来看, UML 的这种划分意味着他们只需要关心那些他们认为对他们的模型有必要的语言部分。   如果这些需求随着时间的推移发生变化,可以根据需要向用户的模型库添加更多的语言单位。   因此, UML 用户不需要知道完整的语言才能有效地使用它。  

UML 的建模概念集被划分为能力不断增强的水平层,称为合规性级别。   合规性级别跨越了各种语言单元,尽管有些语言单元只存在于较高层。   顾名思义,每个合规性级别都是一个唯一的合规性点。  

为了简化模型交换,对整个 UML 只定义了四个合规性级别 :  

•  0 级 (L0) 。   这个合规性级别在 UML 基础设施中正式定义。   它包含一个单一的语言单元,用于对大多数流行的面向对象编程语言中遇到的基于 类 的结构进行建模。   因此,它提供了入门级建模能力。   更重要的是,它代表了一个低成本的公共基础,可以作为不同类别建模工具之间互操作性的基础。  

•  1 级 (L1) 。   这个级别增加了新的语言单元,并扩展了 0 级提供的功能。   具体来说,它为 用例、交互、结构、操作和活动 添加了语言单元。

•  2 级 (L2) 。   这个级别扩展了在第 1 级中已经提供的语言单元,并为 部署、状态机建模和概要文件 添加了语言单元。

•  3 级 (L3) 。   这一层代表完整的 UML 。   它扩展了 Level 2 提供的语言单元,并添加了用于建模 信息流、模板 和 模型 打包的新语言单元。

L0 的内容解读

级别 0 由顶级元模型定义,如图 2.1 所示。   在这个模型中, “L0” 最初是一个空包,它只是简单地合并了来自 UML 基础结构的基本包的内容。   然后将这个包合并到 UML 模型中。   包 L0 包含基本的概念,如类、包、数据类型、操作等,从 Basic 合并而来,而 basic 来自于 nfrastructure 。

图 2.1-Level 0 package diagram

L1 的内容解读

L1 是在 L0 级的基础上建立的。从这个模型得到的语言单元集比 L 0 模型所表示的要多很多,如图 2.2 所示。   

 

图 2.2 –Level 1 top-level package merges

 

表 2.3 列出了这个级别的具体包。

表 2.3 - Metamodel packages added in Level 1

Language Unit Metamodel Packages
Actions Actions::BasicActions
Activities Activities::FundamentalActivities
Activities::BasicActivities
Classes Classes::Kernel
Classes::Dependencies
Classes::Interfaces
General Behavior CommonBehaviors::BasicBehaviors
CommonBehaviors::Communications
Structures CompositeStructure::InternalStructures
Interactions Interactions:BasicInteractions
UseCases UseCases

L2 的内容解读

2 级在 1 级的基础上增加了更多的语言单元和扩展。 L2 的内容如下图所示:

图 2.3-Level 2 top-level package merges

 

表 2.4 列出了这个合规性级别所包含的实际语言单元和包。  

表 2.4- Metamodel packages added in Level 2

Language Unit Metamodel Packages
Actions Actions:StructuredActions
Actions::IntermediateActions
Activities Activities::IntermediateActivities
Activities::StructuredActivities
Components Components::BasicComponents

 

Language Unit Metamodel Packages
Deployments Deployments::Artifacts
Deployments::Nodes
General Behavior CommonBehaviors::SimpleTime
Interactions Interactions::Fragments
Profiles AuxilliaryConstructs::Profiles
Structures CompositeStructures::InvocationActions
CompositeStructures::Ports
CompositeStructures::StructuredClasses
State Machines StateMachines::BehaviorStateMachines

 

L3 的内容解读

最后, Level3 ,包含完整的 UML 定义,如图 2.4 所示。  

 

图 2.4- Level 3 top-level package merges

 

其内容如表 2.5 所示  

表 2.5 – Metamodel packages added in Level 3

Language Unit Metamodel Packages
Action Actions::CompleteActions
Activities Activities::CompleteActivities
Activities::CompleteStructuredActivities
Activities::ExtraStructuredActivities
Classes Classes::AssociationClasses
Classes::PowerTypes
Components Components::PackagingComponents
Deployments Deployments::ComponentDeployments
Information Flows AuxilliaryConstructs::InformationFlows
Models AuxilliaryConstructs::Models
State Machines StateMachines::ProtocolStateMachines
Structures CompositeStructures::Collaborations
CompositeStructures::StructuredActivities
Templates AuxilliaryConstructs::Templates

 

UML 2.5.1 规范

UML 2.5 在 UML 2.4.1 的基础上进行了结构性的调整,简化和重新组织了 UML 规范文档。 UML 规范被重新编写,使其 “ 更易于阅读 ” 并且 “ 尽可能减少前向引用 ” 。 如下是 UML 2.5.1的规范封面截图:

在 UML 2.5.1 规范中不再有两个单独的 UML Infrastructure 和 UML SuperStructure 文档, UML 2.5.1 规范是单个文档。四个 UML 合规性级别( L0 、 L1 、 L2 和 L3 )被消除,因为它们在实践中没有用处。 UML 2.5 工具必须支持完整的 UML 规范。信息流、模型和模板不再是辅助的 UML 构造。同时,用例、部署和信息流成为 UML 2.5 中的 “ 补充概念 ” 。

对构造型、状态机和活动进行了一点澄清和修复。协议状态机现在使用 «protocol» 而不是 { protocol } 表示。用例不再一定表达 actor 的需求,这意味着 Use Case 不见得一定由 Actor 发起。

UML 的建模规范

UML 的语法与如何构建、表示和交换 UML 模型有关。  UML 规范从抽象和具体的角度定义了 UML 的语法。   然而, UML 的语法是在 MOF 的框架中指定的,并且为了工具一致性的目的,语法模型的含义在 MOF 核心规范和相关的 XMI 和图交换规范中给出。  

UML 建模构造的一般划分为两个语义类别 :  

•  结构语义定义了关于被建模领域中个体的 UML 结构模型元素的含义,它们仅仅是在某些特定的时间点可能是正确的。  

•  行为语义定义了 UML 行为模型元素的含义,这些元素描述了被建模领域中的个体如何随时间变化。  

在 UML 2.5.1 规范中, UML 的语义区域划分如下:

Figure 6.1 Semantic Areas of UML

UML 语义区域和这些区域的概念描述如下:  

1) Structural Modelling : UML 的结构语义为 UML 的行为语义提供了基础。   这反映了通过结构建模指定的系统状态变化方面的行为语义的概念。  UML 中的结构建模构造是建立在诸如类型、名称空间、关系和依赖等基本概念的公共基础上的。   特定的建模构造包括许多不同类型的分类器 : 数据类型、类、信号、接口和组件,用于建模值和实例的相应构造型,以及用于打包和 profile 的构造型。  

2) Behavioral Modelling : UML 的基本行为语义建立在这个结构基础之上,为行为的执行提供了一个基本的框架。   这种常见的行为语义还处理了可能导致具有相关行为的结构对象之间的通信。   注意,这个框架只处理事件驱动的或离散的行为。   然而, UML 语义并没有规定事件之间的时间长度。   因此,某些事件之间的间隔可以被认为是应用程序所需的最小间隔 ;  例如,在模拟连续行为时。  

•  action 是 UML 中行为的基本单元,用于定义细粒度的行为。   它们的分辨率和表达能力可与传统编程语言中的可执行指令相媲美。  action 可以与任何用于描述详细行为的高级形式一起使用。  UML 中这样的高级行为构造是 StateMachine 、 activity 和 interfaction 。  

3) 补充的建模构造, 它们同时具有结构和行为方面。   这些包括 UseCase 、 Deployment 和 information flow 。

UML2.5.1中对模型元素定义的范式

UML 2.5.1的核心内容是定义各种UML模型元素,所以《UML2.5.1规范》按照模型元素的分类进行结构组织,每种UML模型元素包括如下部分:

•  Summary (摘要):整体介绍

•  Abstract Syntax (抽象语法):描述元素构成的元模型

•  Sematics (语义):元素描述什么样的内容的定义

•  Notation (标记符号):元素的可视化建模外观

•  Examples (示例):引用了元素的建模的示例

如下是 UML 2.5.1 规范的目录截图:

如下是 UML2.5.1 规范中的 activities 的摘要截图

如下是 UML2.5.1 规范中的 activities 的抽象语法定义截图

如下是 UML2.5.1 规范中的 activities 的抽象语义定义截图

如下是 UML2.5.1 规范中的 activity 的标记符号定义截图

如下是 UML2.5.1 规范中的 activity 的建模图例

Standard Profile

Standard Profile (标准扩展)指定了一组预定义的标准构造型( stereotype )。   符合标准的工具应支持 Standard Profile 中的所有 stereotype 。   如下是 UML2.5.1 规范中定义的 Standard Profile 模型:

UML 图的交换( UML Diagram Interchange )

为了在各种 UML 建模工具之间能够正确的进行 UML 图的交换, UML 2.5.1 规范还定义了 UML 图交换的标准。如下是 UML 图交换架构:

可以看出 UML DI 是基于 Diagram Definition (DD) 建立的,而 DD 是 OMG 关于图的交换专门定义的标准 , http://www.omg.org/spec/DD  。

Diagram

UML 2.5.1 规范中 UML 的图的类型有 14 种,分为 结构图和行为图 2 类。

•  结构图显示了对象的静态结构,描述了那些与时间无关的元素。   结构图中的元素表示应用中的有意义的概念,可能包括抽象的、真实世界的和实现的概念。   结构图不显示动态行为的细节(这些在行为图中描述)。   然而,可以显示出结构图中的分类器行为的关系。  

•  行为图显示了系统中对象的动态行为,包括它们的方法、协作、活动和状态历史。   系统的动态行为可以描述为系统随时间发生的一系列变化。

如下是 UML2.5.1 规范中定义的图的类型:

 

图 A.5 The taxonomy of structure and behavior diagrams

 

每个 UML 图中包含的结构在下面的子句中进行了描述。  

1. Activity Diagram - Activities

2. Class Diagram - Structured Classifiers

3. Communication Diagram - Interactions

4. Component Diagram - Structured Classifiers

5. Composite Structure Diagram - Structured Classifiers

6. Deployment diagram - Deployments

7. Interaction Overview Diagram - Interactions

8. Object Diagram - Classification

9. Package Diagram - Packages

10. Profile Diagram - Packages

11. State Machine Diagram - State Machines

12. Sequence Diagram - Interactions

13. Timing Diagram - Interactions

14. Use Case Diagram - Use Cases

请注意。   图的分类为各种主要类型的图提供了逻辑组织。   然而,它并不排除混合不同类型的图类型,例如,可以把结构和行为元素混合到一起建模, ( 例如,显示嵌套在内部结构中的状态机 ) 。   因此,各种图的类型之间的边界并没有被严格地强制执行。

XMI 序列化和模式( XMI Serialization and Schema )

UML 2 模型基于 XMI 2 规范进行序列化,序列化是根据 MOF 2 XMI 映射规范指定的规则进行的。  

作为 OMG 的通用策略, MOF 2 和 UML 2 模型的规范表示是一个 XMI 文件。  UML 2 的 XMI 文档本身由单个 XMI 文档组成。   相关的 XMI 文档可以来指定 StandardProfile 和 UML 图交换模型。   在一个单独的 XMI 文档中指定了 UML 2 和其他规范所依赖的 PrimitiveTypes 。

XMI 允许使用 tag 来定制使用 XMI 生成的模式和文档。如下是部分 XMI 交换的 tag 设置示例:

交换的元素 XMI 交换的 tag 设置
UML2 元模型 tag “ org.omg.xmi.nsPrefix ” 设置为 “ uml ”
PrimitiveTypes model library tag “ org.omg.xmi.nsPrefix ” 设置为 “ primitives ”
StandardProfile tag “ org.omg.xmi.nsPrefix ” 设置为 “ StandardProfile ”
UMLDI metamodel extension tag “ org.omg.xmi.nsPrefix ” 设置为 “ umldi ”

说明:本文的图例内容大多来自 UML 规范中,为了提高可读性,部分图例采用了 建模工具 EA 和 iSpace 进行了重建。

 

后记

希望您读了此文后有所受益.

如果您有经验乐于分享,欢迎投稿给我们,如果您对我们的培训、咨询和工具感兴趣,欢迎了解:

•  建模工具: EA

•  MBSE 平台: iSpace

•  模型 web 浏览工具: WebEA

•  课程: 基于SysML和EA进行系统设计与建模

•  课程: 基于UML和EA进行系统分析设计

•  咨询方案: MBSE( 基于模型的系统工程 )

•  咨询方案: 基于 UML 的模型驱动的开发

•  所有建模有关的课程: http://www.modeler.org.cn/course/index.asp

•  咨询方案: 基于模型的工程管理

如果您希望了解更多信息:

  • 欢迎访问建模者频道 http://modeler.org.cn/
  • 也欢迎直接联系我们 zhgx@uml.net.cn ,010-62670969

作者简介:

俎涛,火龙果软件工程创始人, 2001 年创立了火龙果软件工程, 2004 年创立了 IBM Rational 用户组. 1998 年,曾作为骨干参与国家重点研究课题《面向特定领域基于组件的软件复用》,有幸比较深入的学习和使用的 UML 进行领域建模、提炼可复用组件和架构.在后来的研发项目中,一直采用模型进行分析设计,积累了一些心得和经验.在以往的经历中,最大的感触是汇聚了很多精英人才的软件工程和系统工程领域居然几十年都是一种凌乱迷蒙的状态,从自己的经历所得,觉得清晰的模型,才是拨开工程迷雾的关键所在,所以不断研究和应用各种建模技术,并从自己的工程实践中提炼经验,形成对于自己可持续的方法论,例如《 Nature Model Language- 自然建模语言》《基于模型的三维研发管理》《 iProcess 过程改进方法》《基于模型的需求管理》《模型驱动的架构设计》《基于模型的质量管理》《基于模型的人员能力管理》,目前正在作为产品经理和架构师,进行 MBSE (基于模型的系统工程)平台的研发,希望建立要给基于模型的工程解决方案,后续会不断写些文章,希望能给同行一些借鉴.

 

   
644 次浏览       4
 
相关文章

用户手册:EA Helper
自然语言自动化生成图
使用iSpace进行多人协作建模
基于模型的软件复用(MBSR)
 
相关文档

AUTOSAR_TR_BSW UML模型建模指南
UML时间图建模(基于EA)
UML 模型框架(基于EA)
UML序列图编写规范
 
相关课程

UML+EA+面向对象分析设计
UML + 嵌入式系统分析设计
业务建模与业务分析
基于UML和EA进行系统分析设计

最新活动计划
需求分析师能力培养 7-10 [北京]
基于 UML 和EA进行分析设计 7-22 [北京]
知识图谱建模与应用 7-19 [北京]
用户体验、易用性测试与评估 8-18 [北京]
软件开发过程中的项目管理 8-25 [北京]
微服务开发原理与实战 8-25 [北京]
 
最新文章
iPerson的过程观:要 过程 or 结果
“以人为本”的工程哲学
企业架构、TOGAF与ArchiMate概览
UML 图解:顺序图( sequence diagram )
UML 图解:对象图( class diagram )
最新课程
基于UML和EA进行系统分析设计
UML+EA+面向对象分析设计
基于SysML和EA进行系统设计与建模
UML + 嵌入式系统分析设计
领域驱动的建模与设计
更多...   
成功案例
某电信运营供应商 应用UML进行面向对象分析
烽火通信 UML进行面向对象的分析设计
西门子 UML与嵌入式软件分析设计
航天科工某子公司 从系统到软件的分析、设计
深圳某汽车企业 模型驱动的分析设计
更多...